300 likes | 447 Views
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
E N D
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.: AAAAAAAAA
Introduction • Notations • The abstraction-refinement framework • Generating the initial abstraction • Model checking the abstract model • Refining the abstraction • Experimental results and conclusion Contents Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
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
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
Overview of counterexample-guided abstraction refinement Introduction(3/3) Concrete model M Abstract model Building new abstract model Model checking φ true Spec φ φ Abstraction refinement φ false + Spurious? Spurious Counterexample counterexample Today’s focus: Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
Introduction • Notations • The abstraction-refinement framework • Generating the initial abstraction • Model checking the abstract model • Refining the abstraction • Conclusion Contents Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
A program Phas 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 forEP 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
Expressions are built from variables in V, constants in Dvi, and function symbol • E.g. v1 + 3 • Atomic formulas are constructed from expressions 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.gAtoms(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
Let p be a predicate containing variables from V, and d = (d1, , dn) 2D • Then, d²p when the predicate obtained by replacing 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) 2p Notations Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
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 Notations • 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 expression to viin the next state • Atoms(Bi) = 15 j 5 kAtoms( ) • Atoms(P) = Atoms(Á) [Atoms(Bi) Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
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} Notations x, y 0,1 1,1 0,2 1,2 2,2 0,0 Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
Each program P corresponds to a labeled Kripke structureM = (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) = {f2Atoms(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
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. Notations x, y {x<y} {x=y} {x=y} {x<y} {x=y, y=2} {x<y} Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
An abstract function h is a onto function from concrete domain D to abstract domain • The abstract Kripke structure is defined as follows • is the abstract domain • iff where • iff where Notations Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
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)} Notations 1 {x<y} 0 {x=y} 2 {x<y} 4 {x=y, y=2} Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
Introduction • Notations • The abstraction-refinement framework • Generating the initial abstraction • Model checking the abstract model • Refining the abstraction • Conclusion Contents Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
Overview of counterexample-guided abstraction refinement Overview Concrete model M Abstract model Building new abstract model Model checking φ true Spec φ φ Abstraction refinement φ false + Spurious? Spurious Counterexample counterexample Today’s focus: Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
Initial abstraction is based on formula cluster • Given an atomic formula f, let var(f) be the set of variables appearing in f • E.gvar(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. Initial Abstraction Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
The formula cluster induces a variable cluster • iffvi 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} Initial Abstraction Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
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= v2VCiDv • 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 Initial Abstraction Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
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 h 0 = {(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
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)} Initial Abstraction {x<y} {x=y,x<y} {x<y} {x=y, y=2} Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
If the abstract model satisfies the given requirements, then the original model also satisfies the given requirements. • We focus on the checking whether the counterexample is spurious or not. Model Checking Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
Counterexample is a path from to • The concrete paths from are given by the following 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 statesishould be abstracted to • The algorithm to compute • Let • where R is transition relation in M • Img(Si-1, R) = {s’ | s2Si-1Æ (s, s’) 2R} • If Sn; then the counterexample is real Model Checking Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
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? Model Checking 3 1 4 7 10 2 5 8 11 3 6 9 12 Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
S1 = {1,2,3} S2 = {4,5,6} S3 = {9} S4 = ; In this model, is spurious! Model Checking 3 1 4 7 10 2 5 8 11 3 6 9 12 Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
If concrete model does not admit the counterexample , then we refine the abstraction function 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 Refining the Abstraction Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
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 Refining the Abstraction Si,x Si,1 Si,0 Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
Comparison between cone of influence and CEGAR • #var: # of symbolic variables • #prop: # of verification properties • #COI and #ABS denote the number of abstracted symbolic variables in each abstraction • |TR|: # of BDD nodes for transition relation • |MC|: # of additional BDD nodes used during verification Experimental Results Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST
Counterexample-Guided Abstraction Refinement by Edmund Clarke, OrnaGrumberg, SomeshJha, Yuan Lu, and Helmut Veith in Computer-Aided Verification, volume 1855 of LNCS, pages 154-169, Springer Verlag, 2000 References Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST