1 / 30

Counterexample-Guided Abstraction Refinement

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

maren
Download Presentation

Counterexample-Guided Abstraction Refinement

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

  29. 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

  30. 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

More Related