Presentation is loading. Please wait.

Presentation is loading. Please wait.

Counterexample-Guided Abstraction Refinement By Edmund Clarke, Orna Grumberg, Somesh Jha, Yuan Lu, and Helmut Veith Presented by Yunho Kim Provable Software.

Published byPierce Lewis Modified over 7 years ago

Similar presentations

Presentation on theme: "Counterexample-Guided Abstraction Refinement By Edmund Clarke, Orna Grumberg, Somesh Jha, Yuan Lu, and Helmut Veith Presented by Yunho Kim Provable Software."— 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.: A A A AA A A A A

2 Contents Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST2/30 Introduction Notations The abstraction-refinement framework – Generating the initial abstraction – Model checking the abstract model – Refining the abstraction Experimental results and conclusion

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, KAIST3/30

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, KAIST4/30

5 Introduction(3/3) Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST5/30 Overview of counterexample-guided abstraction refinement Building new abstract model Model checking Abstraction refinement Spurious? Concrete model M Spec φ Spurious Counterexample φ false + counterexample φ true φ Today’s focus: Abstract model

6 Contents Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST6/30 Introduction Notations The abstraction-refinement framework – Generating the initial abstraction – Model checking the abstract model – Refining the abstraction Conclusion

7 Notations Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST7/30 A program P has a finite set of variables V = { v 1, , v n }, where each variable v i has an associated finite domain Dv i The set of all possible states for program P is Dv 1 £  £ Dv n denoted by D Example – A example program EP has a set of variables V = { v 1, v 2 } – v 1 has domain Dv 1 = {0, 1} and v 2 has Dv 2 = {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)

8 Notations Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST8/30 Expressions are built from variables in V, constants in Dv i, and function symbol – E.g. v 1 + 3 Atomic formulas are constructed from expressions and relation symbols – E.g. v 1 + 3 < 5 Predicates are composed of atomic formulas using :, Æ, Ç – E.g. ( v 1 + 3 7) Given predicate p, Atoms ( p ) is the set of atomic formulas occurring in it. – E.g Atoms ( p ) = { v 1 + 3 7} where p is ( v 1 + 3 7)

9 Notations Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST9/30 Let p be a predicate containing variables from V, and d = ( d 1, , d n ) 2 D Then, d ² p when the predicate obtained by replacing each v i by the constant d i evaluates true Example – A given predicate p is ( v 1 + 3 7) where v 1 has domain Dv 1 = {0, 1, 2} and v 2 has Dv 2 = {0, 1, 2, 3, 4} – (0, 1) ² p, (2, 4) 2 p

10 Notations Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST10/30 Each variable v i 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 v i B i, transition block for v i I i µ Dv i 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 v i in the next state Atoms ( B i ) =  1 5 j 5 k Atoms ( ) Atoms ( P ) = Atoms ( Á ) [  Atoms ( B i )

11 Notations Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST11/30 Transition block example. A program P has a V = { x, y } and D x = D y = {0, 1, 2} Atoms (P) = Atoms ( B x ) [ Atoms ( B y ) = { x < y, x = y } [ { x = y, y = 2 } = { x < y, x = y, y = 2 } 0,0 x, y 0,11,21,10,22,2

12 Notations Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST12/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 ! 2 Atoms ( 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

13 Notations Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST13/30 Example P has a V = { x, y } and D x = D y = {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} {x=y}{x=y} {x<y}{x<y} { x = y, y =2}

14 Notations Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST14/30 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 –

15 Notations Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST15/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}1{x<y} 0{x=y}0{x=y} 2{x<y}2{x<y} 4 { x = y, y =2}

16 Contents Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST16/30 Introduction Notations The abstraction-refinement framework – Generating the initial abstraction – Model checking the abstract model – Refining the abstraction Conclusion

17 Overview Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST17/30 Overview of counterexample-guided abstraction refinement Building new abstract model Model checking Abstraction refinement Spurious? Concrete model M Spec φ Spurious Counterexample φ false + counterexample φ true φ Today’s focus: Abstract model

18 Initial Abstraction Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST18/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.

19 Initial Abstraction Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST19/30 The formula cluster induces a variable cluster – iff v i and v j appear in atomic formulas in the same formula cluster – The equivalence classes of are variables clusters Example – FC1 = { v 1 > 3, v 1 = v 2 }, FC 2 = { v 3 < 4, v 3 + v 4 = v 5 } VC1 = { v 1, v 2 }, VC2 = { v 3, v 4, v 5 }

20 Initial Abstraction Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST20/30 Let { FC 1, , FC m } be the set of formula clusters and { VC 1, , VC m } be the corresponding variables clusters Construct initial abstraction h = ( h 1, , h m ) – Initial abstraction is based on formula clusters – For each h i, set D VC i =   v 2 VCi D v For each VC i = { v i 1, , v i k }, h i is defined on D VC i Two values are in the same equivalence class if they cannot be distinguished by atomic formulas in the FC i

21 Initial Abstraction Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST21/30 Example P has a V = { x, y } and D x = D y = {0, 1, 2} Atoms ( P ) = { x < y, x = y, y = 2 } FC 1 = { x < y, x = y, y = 2 }, VC 1 = { x, y } Abstraction function h 0 = {(0,0),(1,1)}, FC 1 evaluates {F, T, F} 1 = {(0,1)}, FC 1 evaluates {T, F, F} 2 = {(0,2),(1,2)}, FC 1 evaluates {T, F, T} 3 = {(1,0), (2,0), (2,1)}, FC 1 evaluates {F, F, F} 4 = {(2,2)}, FC 1 evaluates {F, T, T}

22 Initial Abstraction Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST22/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}{x<y} { x = y, y =2}

23 Model Checking Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST23/30 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.

24 Model Checking Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST24/30 Counterexample is a path from to The concrete paths from are given by the following expression – Starting state s 1 should be an element of the set of initial states – There is a relation from s 1 to s 2, s 2 to s 3, , s n-1 to s n – Each state s i should be abstracted to The algorithm to compute – Let – where R is transition relation in M Img ( S i - 1, R ) = { s ’ | s 2 S i - 1 Æ ( s, s ’ ) 2 R } – If S n  ; then the counterexample is real

25 Model Checking Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST25/30 Example A program p has a variable v and D v = {1,  12} The abstract function is defined as follows The abstract domain In this model, is spruious? 3 1 2 3 4 5 6 7 8 9 10 11 12

26 Model Checking Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST26/30 S 1 = {1,2,3} S 2 = {4,5,6} S 3 = {9} S 4 = ; In this model, is spurious! 3 1 2 3 4 5 6 7 8 9 10 11 12

27 Refining the Abstraction Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST27/30 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 S i is reachable from with 1 < i · n – S i is reachable, however, there is no transition from S i to

28 Refining the Abstraction Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST28/30 So we partition into three subsets S i, 0, S i, 1, S i, x – S i, 0 = S i Reachable but dead states – S i, 1 = Not reachable but has next transition – S i, x = New abstraction function h ’ should not allow one abstract state to contain both S i, 0 and S i, 1 Si,xSi,x Si,1Si,1 Si,0Si,0

29 Experimental Results Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST29/30 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

30 References Counterexample-Guided Abstraction Refinement, Yunho Kim, Provable Software Lab, KAIST30/30 Counterexample-Guided Abstraction Refinement by Edmund Clarke, Orna Grumberg, Somesh Jha, Yuan Lu, and Helmut Veith in Computer-Aided Verification, volume 1855 of LNCS, pages 154-169, Springer Verlag, 2000

Download ppt "Counterexample-Guided Abstraction Refinement By Edmund Clarke, Orna Grumberg, Somesh Jha, Yuan Lu, and Helmut Veith Presented by Yunho Kim Provable Software."

Similar presentations

Model Checking Base on Interoplation

Model Checking Base on Interoplation
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?

Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Completeness and Expressiveness

Completeness and Expressiveness
Abstraction in Model Checking Nishant Sinha. Model Checking Given a: –Finite transition system M –A temporal property p The model checking problem: –Does.

Abstraction in Model Checking Nishant Sinha. Model Checking Given a: –Finite transition system M –A temporal property p The model checking problem: –Does.
B ϋ CHIS MONADIC SECOND ORDER LOGIC Verification Seminar V.Sowjanya Lakshmi ( Subhasree M.

B ϋ CHIS MONADIC SECOND ORDER LOGIC Verification Seminar V.Sowjanya Lakshmi ( Subhasree M.
10 October 2006 Foundations of Logic and Constraint Programming 1 Unification ­An overview Need for Unification Ranked alfabeths and terms. Substitutions.

10 October 2006 Foundations of Logic and Constraint Programming 1 Unification ­An overview Need for Unification Ranked alfabeths and terms. Substitutions.
CS 267: Automated Verification Lecture 2: Linear vs. Branching time. Temporal Logics: CTL, CTL*. CTL model checking algorithm. Counter-example generation.

CS 267: Automated Verification Lecture 2: Linear vs. Branching time. Temporal Logics: CTL, CTL*. CTL model checking algorithm. Counter-example generation.
Algorithmic Software Verification VII. Computation tree logic and bisimulations.

Algorithmic Software Verification VII. Computation tree logic and bisimulations.
1 Model checking. 2 And now... the system How do we model a reactive system with an automaton ? It is convenient to model systems with Transition systems.

1 Model checking. 2 And now... the system How do we model a reactive system with an automaton ? It is convenient to model systems with Transition systems.
An Introduction to the Model Verifier verds Wenhui Zhang September 15 th, 2010.

An Introduction to the Model Verifier verds Wenhui Zhang September 15 th, 2010.
ECE 667 - Synthesis & Verification - L271 ECE 697B (667) Spring 2006 Synthesis and Verification of Digital Systems Model Checking basics.

ECE Synthesis & Verification - L271 ECE 697B (667) Spring 2006 Synthesis and Verification of Digital Systems Model Checking basics.
Hybrid Systems Presented by: Arnab De Anand S. An Intuitive Introduction to Hybrid Systems Discrete program with an analog environment. What does it mean?

Hybrid Systems Presented by: Arnab De Anand S. An Intuitive Introduction to Hybrid Systems Discrete program with an analog environment. What does it mean?
Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 13.

Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
CS 267: Automated Verification Lecture 7: SMV Symbolic Model Checker, Partitioned Transition Systems, Counter-example Generation in Symbolic Model Checking.

CS 267: Automated Verification Lecture 7: SMV Symbolic Model Checker, Partitioned Transition Systems, Counter-example Generation in Symbolic Model Checking.
By Claudia Fiorini, Enrico Martinelli, Fabio Massacci

By Claudia Fiorini, Enrico Martinelli, Fabio Massacci
Review of topics Final exam : -May 2nd to May 7 th - Projects due on May 7th.

Review of topics Final exam : -May 2nd to May 7 th - Projects due on May 7th.
1/22 Programs : Semantics and Verification Charngki PSWLAB Programs: Semantics and Verification Mordechai Ben-Ari Mathematical Logic for Computer.

1/22 Programs : Semantics and Verification Charngki PSWLAB Programs: Semantics and Verification Mordechai Ben-Ari Mathematical Logic for Computer.
The Software Model Checker BLAST by Dirk Beyer, Thomas A. Henzinger, Ranjit Jhala and Rupak Majumdar Presented by Yunho Kim Provable Software Lab, KAIST.

The Software Model Checker BLAST by Dirk Beyer, Thomas A. Henzinger, Ranjit Jhala and Rupak Majumdar Presented by Yunho Kim Provable Software Lab, KAIST.
Probabilistic CEGAR* Björn Wachter Joint work with Holger Hermanns, Lijun Zhang TexPoint fonts used in EMF. Read the TexPoint manual before you delete.

Probabilistic CEGAR* Björn Wachter Joint work with Holger Hermanns, Lijun Zhang TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
Using Statically Computed Invariants Inside the Predicate Abstraction and Refinement Loop Himanshu Jain Franjo Ivančić Aarti Gupta Ilya Shlyakhter Chao.

Using Statically Computed Invariants Inside the Predicate Abstraction and Refinement Loop Himanshu Jain Franjo Ivančić Aarti Gupta Ilya Shlyakhter Chao.

Similar presentations

Ads by Google