counterexample-guided abstraction refinement
DESCRIPTION
Counterexample-Guided Abstraction Refinement. By Edmund Clarke, Orna Grumberg, Somesh Jha, Yuan Lu, and Helmut Veith Presented by Yunho Kim Provable Software Lab, KAIST. TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: A A A A A A A A A. Introduction - PowerPoint PPT PresentationTRANSCRIPT
Counterexample-Guided Abstraction Refinement
By Edmund Clarke, Orna Grumberg, Somesh Jha, Yuan Lu, and Helmut Veith
Presented by Yunho KimProvable Software Lab, KAIST
Contents
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 2/30
• Introduction
• Notations
• The abstraction-refinement framework–Generating the initial abstraction–Model checking the abstract model–Refining the abstraction
• Experimental results and conclusion
• The state explosion problem is a major difficulty in applying model checking to large systems
• Abstraction technique reduces a set of equivalent states to one abstract state
• Model checking an abstract model has less time and memory requirements than doing a concrete model
Introduction(1/3)
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 3/30
• Can model checking an abstract model guarantee the correctness of the concrete model?
• Existential abstraction guarantee the following with a given specification Á
• However, existential abstraction may generate spurious counterexamples
Introduction(2/3)
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 4/30
cM j= Á ) M j= Á
cM 2 Á ; M 2 Á
Introduction(3/3)
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 5/30
• Overview of counterexample-guided abstraction refinement
Building new abstract model
Modelchecking
Abstraction refinement
Spuri-ous?
Concrete model MSpec φ
Spurious Coun-terexample
φ false +
counterexam-ple
φ true
φ
Today’s focus:
cMAbstract model
Contents
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 6/30
• Introduction
• Notations
• The abstraction-refinement framework–Generating the initial abstraction–Model checking the abstract model–Refining the abstraction
• Conclusion
Notations
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 7/30
• A program P has a finite set of variables V = {v1, ,vn} , where each variable vi has an associated finite domain Dvi
• The set of all possible states for program P is Dv1 £ £ Dvn denoted by D
• Example– A example program EP has a set of variables V = {v1, v2}– v1 has domain Dv1 = {0, 1} and v2 has Dv2 = {0, 1, 2}– The set of all possible states for for EP is {0, 1} £ {0, 1,
2} • (0, 0), (0, 1), (0, 2), (1, 0), (1, 1), (1, 2)
Notations
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 8/30
• Expressions are built from variables in V, con-stants in Dvi, and function symbol – E.g. v1 + 3
• Atomic formulas are constructed from expres-sions and relation symbols– E.g. v1 + 3 < 5
• Predicates are composed of atomic formulas using :, Æ, Ç – E.g. (v1 + 3 < 5) Ç :(v2 + 4 > 7)
• Given predicate p, Atoms(p) is the set of atomic formulas occurring in it.– E.g Atoms(p) = {v1 + 3 < 5, v2 + 4 > 7}
where p is (v1 + 3 < 5) Ç :(v2 + 4 > 7)
Notations
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 9/30
• Let p be a predicate containing variables from V, and d = (d1, , dn) 2 D
• Then, d ² p when the predicate obtained by replac-ing each vi by the constant di evaluates true
• Example– A given predicate p is (v1 + 3 < 5) Ç :(v2 + 4 > 7) where
v1 has domain Dv1 = {0, 1, 2} and v2 has Dv2 = {0, 1, 2, 3, 4}
– (0, 1) ² p , (2, 4) 2 p
Notations
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 10/30
• Each variable vi has an associated transition block– A program P consists of variables and their transition
blocks• Transition block defines both the initial value and
the transition relation for the variable vi
• Bi, transition block for vi • Ii µ Dvi • Each condition is a predicate• is an expression• Semantics of case is that find
the least j such that is true and assign the value of the ex-pression to vi in the next state
• Atoms(Bi) = 15 j 5 k Atoms( )• Atoms(P) = Atoms(Á) [
Atoms(Bi)
C ji
A ji
C ji
A ji
C ji
Notations
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 11/30
• Transition block example.• A program P has a V = {x, y} and Dx = Dy = {0, 1,
2}
• Atoms(P) = Atoms(Bx) [ Atoms(By) = {x < y, x = y} [ {x = y, y = 2} = {x < y, x = y, y = 2}
0,0x, y 0,1 1,21,1 0,2 2,2
Notations
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 12/30
• Each program P corresponds to a labeled Kripke structure M = (S, I, R, L)– S = D, is a set of states– I µ S, is a set of initial states– R µ S £ S is a transition relation– L : S ! 2Atoms(P) , L(d) = {f 2 Atoms(P) | d ² f}– L maps a state to a set of predicates whose elements
evaluate true in the state
Notations
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 13/30
• Example• P has a V = {x, y} and Dx = Dy = {0, 1, 2}• Atoms(P) = {x < y, x = y, y = 2}
• M = (S, I, R, L)– S = D = {0, 1, 2} £ {0, 1, 2}– I = {(0, 1)}– R = {((0,1),(1,1)),((1,1),(0,2)),((0,2),(1,2)),((1,2),(2,2)),((2,2),
(0,0)),((0,0),(0,1))}– L(0,1)=L(0,2)=L(1,2)={x<y}, L(1,1)=L(0,0)={x=y},
L(2,2)={x=y, y=2}– I describe only reachable states from initial state.
{x=y}
x, y
{x<y}
{x<y}
{x=y}
{x<y}
{x=y,
y=2}
Notations
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 14/30
• An abstract function h is a onto function from con-crete domain D to abstract domain
• The abstract Kripke structure is de-fined as follows– is the abstract domain – iff where – iff
where –
bDh : D ! bD
cM = (bS; bI ; bR; bL)bS bDbd 2 bI
9d19d2(h(d1) = bd1 ^h(d2) = bd2 ^(d1;d2) 2 R)9d(h(d) = bd^d 2 I )
( bd1; bd2) 2 bR
bL(bd) = Sh(d)=bd L(d)
bd2 bD ^d 2 D
bd1; bd2 2 bD ^d1;d2 2 D
Notations
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 15/30
• Example• M = (S, I, R, L)
– S = D = {0, 1, 2} £ {0, 1, 2}– I = {(0, 1)}– R = {((0,1),(1,1)),((1,1),(0,2)),((0,2),(1,2)),((1,2),(2,2)),((2,2),
(0,0)),((0,0),(0,1))}– L(0,1)=L(0,2)=L(1,2)={x<y}, L(1,1)=L(0,0)={x=y},
L(2,2)={x=y, y=2}– I describe only reachable states from initial state.
• Abstraction function h– h(0,0)=h(1,1)=0, h(0,1)=1, h(0,2)=h(1,2)=2, h(1,0)=h(2,0)=h(2,1)=3, h(2,2)=4
• – = {0, 1, 2, 3, 4}– = {1}– = {(1,0),(0,2),(2,2),(2,4),(4,0),(0,1)}–
1{x<y}
0{x=y}
2{x<y}
4{x=y,
y=2}
cM = (bS; bI ; bR; bL)bSbIbR
bL(0) = fx = yg; bL(1) = bL(2) = fx < yg;bL(3) = fg; bL(4) = fx = y;y = 2g
Contents
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 16/30
• Introduction
• Notations
• The abstraction-refinement framework–Generating the initial abstraction–Model checking the abstract model–Refining the abstraction
• Conclusion
Overview
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 17/30
• Overview of counterexample-guided abstraction refinement
Building new abstract model
Modelchecking
Abstraction refinement
Spuri-ous?
Concrete model MSpec φ
Spurious Coun-terexample
φ false +
counterexam-ple
φ true
φ
Today’s focus:
cMAbstract model
Initial Abstraction
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 18/30
• Initial abstraction is based on formula cluster
• Given an atomic formula f, let var(f) be the set of variables appearing in f– E.g var(x=y) = {x, y}– Generally, for any syntactic entity X, var(X) is the set of
variables appearing in X
• Formula cluster is a equivalence class of an atomic formula f denoted by [f]– – For any two formulas from the formula cluster, they share
at least one variable.f1 ´ I f 2 i f f var(f 1) \ var(f 2) 6= ;
Initial Abstraction
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 19/30
• The formula cluster induces a variable cluster– iff vi and vj appear in atomic formulas in the
same formula cluster – The equivalence classes of are variables clusters
• Example– FC1 = {v1 > 3, v1 = v2}, FC2 = {v3 < 4, v3 + v4 = v5}
VC1 = {v1, v2}, VC2 = {v3, v4, v5}
vi ´ V vj
´ V
Initial Abstraction
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 20/30
• Let {FC1, , FCm} be the set of formula clusters and {VC1, , VCm} be the corresponding variables clusters
• Construct initial abstraction h = (h1, , hm)– Initial abstraction is based on formula clusters– For each hi, set DVCi
= v 2 VCi Dv
• For each VCi = {vi1, , vik
}, hi is defined on DVCi
• Two values are in the same equivalence class if they cannot be distinguished by atomic formulas in the FCi
hi (di ;¢¢¢;dk) = hi (e1;¢¢¢;ek) i f f8f 2 F Ci ;(d1;¢¢¢;dk) j= f , (e1;¢¢¢;ek) j= f
Initial Abstraction
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 21/30
• Example• P has a V = {x, y} and Dx = Dy = {0, 1, 2}• Atoms(P) = {x < y, x = y, y = 2}• FC1 = {x < y, x = y, y = 2}, VC1 = {x, y}
• Abstraction function h0 = {(0,0),(1,1)}, FC1 evaluates {F, T, F} 1 = {(0,1)}, FC1 evaluates {T, F, F}2 = {(0,2),(1,2)}, FC1 evaluates {T, F, T}3 = {(1,0), (2,0), (2,1)}, FC1 evaluates {F, F, F}4 = {(2,2)}, FC1 evaluates {F, T, T}
Initial Abstraction
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 22/30
• Example• M = (S, I, R, L)
– S = D = {0, 1, 2} £ {0, 1, 2}– I = {(0, 1)}– R = {((0,1),(1,1)),((1,1),(0,2)),((0,2),(1,2)),((1,2),(2,2)),((2,2),
(0,0)),((0,0),(0,1))}– L(0,1)=L(0,2)=L(1,2)={x<y}, L(1,1)=L(0,0)={x=y},
L(2,2)={x=y, y=2}– I describe only reachable states from initial state.
• Abstraction function h– h(0,0)=h(1,1)=0, h(0,1)=1, h(0,2)=h(1,2)=2, h(1,0)=h(2,0)=h(2,1)=3, h(2,2)=4
• – = {0, 1, 2, 3, 4}– = {1}– = {(1,0),(0,2),(2,2),(2,4),(4,0),(0,1)}–
{x<y}
{x=y,x<y}
{x<y}
{x=y,
y=2}
cM = (bS; bI ; bR; bL)bSbIbR
bL(0) = fx = yg; bL(1) = bL(2) = fx < yg;bL(3) = fg; bL(4) = fx = y;y = 2g
Model Checking
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 23/30
• If the abstract model satisfies the given require-ments, then the original model also satisfies the given requirements.
• We focus on the checking whether the counterex-ample is spurious or not.
Model Checking
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 24/30
• Counterexample is a path from to
• The concrete paths from are given by the follow-ing expression– Starting state s1 should be an element of the set of initial states– There is a relation from s1 to s2, s2 to s3, , sn-1 to sn– Each state si should be abstracted to
• The algorithm to compute– Let – where R is transition
relation in M• Img(Si-1, R) = {s’ | s 2 Si-1 Æ (s, s’) 2 R}
– If Sn ; then the counterexample is real
bT =< bs1;¢¢¢;csn > bs1 csn
bT
h¡ 1( bT) = f< s1;¢¢¢;sn > j V ni=1 h(si ) = bsi ^I (s1) ^V n¡ 1
i=1 R(si ;si+1)gf
bsi
h¡ 1( bT)S1 = h¡ 1( bs1) \ I
f or 1< i · n;Si := I mg(Si ¡ 1;R) \ h¡ 1(bsi )
bT
Model Checking
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 25/30
• Example• A program p has a variable v and Dv = {1, 12} • The abstract function is defined as follows
• The abstract domain
• In this model, is spruious?
h : D ! bDh(x) = b(x ¡ 1)=3c+1
bD = fb1;b2;b3;b4g
bT =< b1;b2;b3;b4>
3
1
2
3
4
5
6
7
8
9
10
11
12
b1 b2 b3 b4
Model Checking
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 26/30
• S1 = {1,2,3}• S2 = {4,5,6}• S3 = {9}• S4 = ;
• In this model, is spurious!
3
1
2
3
4
5
6
7
8
9
10
11
12
b1 b2 b3 b4
bT =< b1;b2;b3;b4>
Refining the Abstraction
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 27/30
• If concrete model does not admit the counterex-ample
, then we refine the abstraction func-tion h so that new model does not allow
• Since is spurious, there exists a such that and Si is reachable
from with 1 < i · n– Si is reachable, however, there is no transition from Si to
bT =< bs1;¢¢¢;csn >
bT =< bs1;¢¢¢;csn > Si µ h¡ 1(bsi )
h¡ 1( bs1) \ II mg(Si ;R) \ h¡ 1( dsi+1) = ;
h¡ 1( dsi+1) = ;
bT
Refining the Abstraction
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 28/30
• So we partition into three subsets Si,0, Si,1, Si,x – Si,0 = Si
• Reachable but dead states– Si,1 =
• Not reachable but has next transition– Si,x=
• New abstraction function h’ should not allow one abstract state to contain both Si,0 and Si,1
h¡ 1(bsi )
f s 2 h¡ 1(bsi )j9s02 h¡ 1( dsi+1):(s;s0) 2 R)g
h¡ 1(bsi )n(Si ;0 [ Si ;1)Si,x
Si,1
Si,0
h¡ 1(bsi )h¡ 1( dsi ¡ 1) h¡ 1( dsi+1)
Experimental Results
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 29/30
• Comparison between cone of influence and CE-GAR– #var: # of symbolic variables– #prop: # of verification properties
– #COI and #ABS denote the number of abstracted sym-bolic variables in each abstraction
– |TR|: # of BDD nodes for transition relation– |MC|: # of additional BDD nodes used during verification
References
Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST 30/30
• Counterexample-Guided Abstraction Refinementby Edmund Clarke, Orna Grumberg, Somesh Jha, Yuan Lu, and Helmut Veithin Computer-Aided Verification, volume 1855 of LNCS, pages 154-169, Springer Verlag, 2000