Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Model Checking, Abstraction- Refinement, and Their Implementation Orna Grumberg Verification seminar March 2006.

Similar presentations


Presentation on theme: "1 Model Checking, Abstraction- Refinement, and Their Implementation Orna Grumberg Verification seminar March 2006."— Presentation transcript:

1 1 Model Checking, Abstraction- Refinement, and Their Implementation Orna Grumberg Verification seminar March 2006

2 2 CTL* Allows any combination of temporal operators and path quantifiers More expressive than LTL or CTL ACTL / ACTL* The universal fragments of CTL/CTL* with only universal path quantifiers  -calculus: More expressive than CTL*

3 3 Model Checking An efficient procedure that receives:  A finite-state model M, describing a system  A temporal logic formula , describing a property It returns yes, M |=  no + Counterexample, otherwise

4 4 Main limitation: The state explosion problem: Model checking is efficient in time but suffers from high space requirements: The number of states in the system model grows exponentially with  the number of variables  the number of components in the system

5 5 Possible solution Replacing the system model by a smaller one (less states and transitions) that still preserves properties of interest Modular verification Symmetry Abstraction

6 6 We define: equivalence between models that strongly preserves CTL* (  -calculus) If M 1  M 2 then for every CTL* formula , M 1 |=   M 2 |=  preorder on models that weakly preserves ACTL* If M 2  M 1 then for every ACTL* formula , M 2 |=   M 1 |= 

7 7 The simulation preorder [Milner] Given two models M 1 = (S 1,I 1,R 1,L 1 ), M 2 = (S 2,I 2,R 2,L 2 ) H  S 1 x S 2 is a simulation iff for every (s 1, s 2 )  H : s 1 and s 2 satisfy the same propositions For every successor t 1 of s 1 there is a successor t 2 of s 2 such that (t 1,t 2 )  H Notation: s 1  s 2

8 8 The simulation preorder [Milner] Given two models M 1 = (S 1,I 1,R 1,L 1 ), M 2 = (S 2,I 2,R 2,L 2 ) H  S 1 x S 2 is a simulation iff for every (s 1, s 2 )  H : L(s 1 ) = L(s 2 )  t 1 [ (s 1,t 1 )  R 1   t 2 [ (s 2,t 2 )  R 2  (t 1,t 2 )  H ] ] Notation: s 1  s 2

9 9 Simulation preorder (cont.) H  S 1 x S 2 is a simulation from M 1 to M 2 iff H is a simulation and for every s 1  I 1 there is s 2  I 2 s.t. (s 1, s 2 )  H Notation: M 1  M 2

10 10 Bisimulation relation [Park] For models M 1 and M 2, H  S 1 x S 2 is a bisimulation iff for every (s 1, s 2 )  H : L(s 2 ) = L(s 1 )  t 1 [ (s 1,t 1 )  R 1   t 2 [ (s 2,t 2 )  R 2  (t 1,t 2 )  H ] ]  t 2 [(s 2,t 2 )  R 2   t 1 [(s 1,t 1 )  R 1  (t 1,t 2 )  H ]] Notation: s 1  s 2

11 11 Bisimulation relation (cont.) H  S 1 x S 2 is a Bisimulation between M 1 and M 2 iff H is a bisimulation and for every s 1  I 1 there is s 2  I 2 s.t. (s 1, s 2 )  H and for every s 2  I 2 there is s 1  I 1 s.t. (s 1, s 2 )  H Notation: M 1  M 2

12 12 H={ (1,1’), (2,4’), (4,2’), (3,5’), (3,6’), (5,3’), (6,3’) } ab aa b b Bisimulation equivalence M 1  M 2 a bb ddc 1 4 3 6 2 5 M1M1 a bb ccd 1’1’ 2’2’ 3’3’ 4’4’ 5’5’ 6’6’ M2M2

13 13 M1M1 M2M2 Simulation preorder M 1  M 2 wait coin pepsicoke wait coin cokepepsi

14 14 M1M1 M2M2 a b cdddc a bb M 1  M 2

15 15 M1M1 M2M2 a b cdd dc a bb M 1  M 2 and M 1  M 2 but not M 1  M 2

16 16 (bi)simulation and logic preservation Theorem: If M 1  M 2 then for every CTL* formula , M 1 |=   M 2 |=  If M 2  M 1 then for every ACTL* formula , M 2 |=   M 1 |=  Holds also for  -calculus and its universal fragment

17 17 Abstraction One of the most useful ways to fight the state explosion problem They should preserve properties of interest: properties that hold for the abstract model should hold for the concrete model Abstractions should be constructed directly from the program

18 18 Abstraction Removes or simplifies details Removes entire components that are irrelevant to the property under consideration, thus reducing # of states Manual abstraction requires great creativity.

19 19 Outline for abstraction Define an abstract model that preserves the checked property Consider different types of abstractions Automatically construct an abstract model –Different constructions for different types Automatically refine it, if the abstraction is not detailed enough

20 20 We first define an abstract model M h based on a concrete (full) model M of the system Goal: constructing M h directly from the program text P M MhMh  Concrete model Abstract model

21 21 Abstraction preserving ACTL/ACTL* We use Existential Abstraction in which the abstract model is an over-approximation of the concrete model: –The abstract model has more behaviors –But no concrete behavior is lost Every ACTL/ACTL* property true in the abstract model is also true in the concrete model

22 22 Existential Abstraction M MhMh Given an abstraction function h : S  S h, the concrete states are grouped and mapped into abstract states : hhh M < M h

23 23 How to define an abstract model: Given M and , choose S h - a set of abstract states AP – a set of atomic propositions that label concrete and abstract states h : S  S h - a mapping from S on S h that satisfies: h(s) = h(t) only if L(s)=L(t)

24 24 The abstract model M h = ( S h, I h, R h, L h ) s h  I h   s  I : h(s) = s h (s h,t h )  R h   s,t [ h(s) = s h  h(t) = t h  (s,t)  R ] L h (s h ) = L(s) for some s where h(s) = s h This is an exact abstraction

25 25 An approximated abstraction (an approximation ) s h  I h   s  I : h(s) = s h (s h,t h )  R h   s,t [ h(s) = s h  h(t) = t h  (s,t)  R ] L h is as before Notation: M r – reduced (exact) M h - approximated

26 26 Logic preservation M h (exact or approximated) has less states but more behaviors: M h  M therefore:  Theorem If  is an ACTL/ACTL* specification over AP, then M h |=   M |= 

27 27 Example Program with one variable x over the integers Initially x may be either 0 or 1 At any step, x may non-deterministically either decrease or increase by 1

28 28 Example (cont.) Abstraction 1: S h1 = { a –, a 0, a + } a + if s(x)>0 h 1 (s) = a 0 if s(x)=0 a – if s(x)<0 Abstraction 2: S h2 = { a even, a odd } h 2 (s) = if even( |s(x)| ) then a even else a odd

29 29 The concrete model x=0x=1 x=-1 x=-2x=3 x=2 a even a odd Abstraction 2 a0a0 a+a+ a–a– Abstraction 1

30 30 Types of Abstraction (S h, h)  Localization reduction: each variable either keeps its concrete behavior or is fully abstracted (has free behavior) [Kurshan94]  Predicate abstraction: concrete states are grouped together according to the set of predicates they satisfy [GS97,SS99]  Data abstraction: the domain of each variable is abstracted into a small abstract domain [CGL94,LONG94]

31 31 Depending on h and the size of M, M h (I.e. I h, R h ) can be built using:  BDDs or  SAT solver or  Theorem prover We later demonstrate such constructions for specific types of abstractions

32 32 Predicate abstraction Given a program over variables V Predicate P i is a first-order atomic formula over V Examples: x+y < z 2, x=5 Choose: AP = { P 1,…,P k } that includes – the atomic formulas in the property  and – conditions in if, while statements of the program

33 33 Labeling of concrete states: L(s) = { P i | s |= P i }

34 34 Abstract model Abstract states are defined over Boolean variables { B 1,...,B k }: S h  { 0,1 } k h(s) = s h  for all 1  j  k : [ s |= P j  s h |= B j ] L h (s h ) = { P j | s h |= B j }

35 35 Example Program over natural variables x, y AP = { P 1, P 2, P 3 } where P 1 = x≤1, P 2 = x>y, P 3 = y=2 AP = { x≤1, x>y, y=2 } L((0,0)) = L((1,1)) = L(0,1)) = { P 1 } L((0,2)) = L((1,2)) = { P 1, P 3 } L((2,0)) = { P 2 }

36 36 S h  { 0,1 } 3 h((0,0)) = L((1,1)) = L(0,1)) = (1,0,0) h((0,2)) = L((1,2)) = (1,0,1) h((2,0)) = (0,1,0) No concrete state is mapped to (1,1,1) L h ((1,0,0)) = { P 1 } L h ((1,0,1)) = { P 1, P 3 } The concrete state and its abstract state are labeled identically (s h,t h )  R h   s,t [ h(s) = s h  h(t) = t h  (s,t)  R ]

37 37 Computing R h (same example) Program with one statement: x := x+1

38 38 ( (b 1,b 2,b 3 ), (b’ 1,b’ 2,b’ 3 ) )  R h   xyx’y’ [ P 1 (x,y)  b 1  P 2 (x,y)  b 2  P 3 (x,y)  b 3  x’=x+1  y’=y  P 1 ( x’,y’ )  b’ 1  P 2 ( x’,y’ )  b’ 2  P 3 ( x’,y’ )  b’ 3 ]

39 39 Computing R h using BDDs If the program is over finite, relatively small domains, use BDDs We need BDDs for: the concrete transition relation R (possibly partitioned) the abstraction mapping h R h is computed according to the formula above, using BDD operations

40 40 Computing R h using SAT or Theorem Prover If the program is over finite, relatively large domains, use SAT If the program is over infinite domains, use theorem prover Theorem prover and SAT solve the problem for each pair of states separately: |S h |x|S h | applications

41 41 Computing R h with SAT or Theorem Prover (example cont.) Given S h = (1,0,0) t h = (0,0,0) To determine if (s h, t h )  R h, check:  xyx’y’ [ h((x,y)) = (1,0,0)  h((x’,y’)) = (0,0,0)  ((x,y),(x’y’))  R ]   xyx’y’ [ P 1 (x,y)  P 2 (x,y)  P 3 (x,y)  x’=x+1  y’=y   P 1 (x’,y’)  P 2 (x’,y’)  P 3 (x’,y’) ]

42 42 Using BDDs, R h is computed based on the concrete model M Using SAT or Theorem prover, R h can be viewed as computed directly from the program text We later show a more direct construction from the program text

43 43 Approximation For BDDs: Approximate the computation of R h For SAT and theorem prover: In case of check failure for a pair (s h,t h ), include the pair in R h

44 44 Data Abstraction Given a program over variables v 1,…v n where v i is over a domain D i Program states (concrete) S = D 1 x…x D n Choose for each v i : an abstract domain A i h i : D i  A i S h = A 1 x…x A n

45 45 AP = { v i A =a | a  A i, i=1,…n } where v i A refers to the abstract value of v i h : S  S h is defined: h ((d 1,…,d n )) = (a 1,…,a n ) where a i = h i (d i ) L ((d 1,…,d n )) ={ v i A =a i | h i (d i ) = a i, i=1,…,n } L h ((a 1,…,a n )) ={ v i A =a i | i=1,…,n } As before: L(s) = L h (h(s))

46 46 Constructing M h from program text we assume that the program is given by first order formulas I ( V ) – describing the initial states R ( V, V’ ) – describing the transition relation where V =( v 1,...,v n ) and V' =( v 1 ’,...,v n ’ )

47 47 Representing a program by formulas: example program: k: x:=e k’ Formula R(x, pc, x’, pc’) : pc=k  x’=e  pc’=k’

48 48 Representing a program by formulas: example (cont) program: k: if x=0 then k 1 : x:=1 else k 2 : x:=x+1 k’ Formula R (x, pc, x’, pc’) : ( pc=k  x=0  x’=x  pc’ = k 1 )  ( pc=k  x  0  x’=x  pc’ = k 2 )  ( pc=k 1  x’=1  pc’=k’)  ( pc=k 2  x’=x+1  pc’=k’)

49 49 What does it mean for a formula to represent a model M? I ( V ) and R ( V, V ’) represent (describe) the model M=(S, I, R, L) as follows: Let s=(d 1,...d n ), s’=(d 1 ’,...,d n ’) s  I  I [v i  d i ] = true (s, s’)  R  R [v i  d i, v i ’  d i ’ ] = true

50 50 Notation: For a formula  over variables v 1,...,v k [  ] (v 1 A,..., v k A ) =  v 1,...,v k ( h(v 1 )= v 1 A ...  h(v k )= v k A   (v 1,...,v k ) ) Note: [ I ( V ) ] and [ R ( V, V ’)] are formulas over abstract variables [ I ( V )] and [ R ( V, V ’)] represent M r

51 51 Given first order formulas I ( V ) and R ( V, V ’), representing the “program text”, we can construct [ I ( V )] and [ R ( V, V ’)], representing M r

52 52 Problem: Given [ I ( V ) ] and [ R ( V, V ’ )], in order to determine if s r  I r, we need to find a state s  I (a satisfying assignment for I ( V )) so that h(s) = s r Similarly, for (s r, t r )  R r we look for a satisfying assignment for R ( V, V ’) This is a difficult task due to the size and complexity of the two formulas

53 53 Simplifying the formulas For  in negation normal form over basic predicates p i and  p i, T (  ) simplifies [  ] by “pushing” the existential quantifiers inward: T (p i (v 1,...,v n )) = [p i ](v 1 A,...,v n A ) T (  p i (v 1,...,v n )) = [  p i ](v 1 A,...,v n A ) T (  1   2 ) = T (  1 )  T (  2 ) T (  1   2 ) = T (  1 )  T (  2 ) (*) (*) does not preserve equivalence

54 54 Approximated model Theorem: [  ]  T (  ) In particular, [ I ]  T ( I ) and [ R ]  T ( R ) Corollary: The approximation model M h, defined by T ( I ) and T ( R ) satisfies: M h  M r  M by the simulation preorder

55 55 Approximated model (cont.) Defined over the same set of abstract states as M r Easier to compute since existential quantifiers are applied to simpler formulas Less precise: has more initial states an more transitions than M r

56 56 Computing approximation model from the text No need to construct formulas. The approximation model can be constructed directly from the program text The user should provide abstract predicates [p i ] and [  p i ] for every basic action (assignment or condition) in the program

57 57 Abstract predicates provided by the user: Example statement: x := y+z predicate p(x’,y,z): x’ = y+z A = {a even, a odd } [p](x’ A,y A,z A ) = { (a even, a odd, a odd ), (a even, a even, a even ), (a odd, a odd, a even ), (a odd, a even, a odd ) } [p](a even, a odd, a odd ) iff  x’,y,z ( h(x’) = a even  h(y) = a odd  h(z)= a odd  x’=y+z )

58 58 Logic preservation Theorem  Theorem If  is an ACTL/ACTL* specification over AP, then M h |=   M |=   However, the reverse may not be valid.

59 59 Traffic Light Example red green yellow M Property:  = AG AF ¬ (state=red) Abstraction function h maps green, yellow to go. red go MhMh M h |=  M |=  

60 60 Traffic Light Example (Cont) If the abstract model invalidates a specification, the actual model may still satisfy the specification.  Property:  = AG AF (state=red)  M |=  but M h |=  red green yellow red go M MhMh  Spurious Counterexample :  red,go,go,... 

61 61 CounterExample-Guided Abstraction-Refinement (CEGAR)

62 62 The CEGAR Methodology T h is not spurious check spurious counterexample ThTh stop M h |=  generate counterexample T h M h |=  model check MhMh generate initial abstraction M and  refinement ThTh is spurious

63 63 Refinement versus approximation Remark: Refinement builds new S h and h, then recomputes R h and I h (exact or approximated) Approximation uses the same S h and h and just adds more transitions and initial states

64 64 Assumptions for BDD-based implementation The concrete model M is finite but too big to directly apply model checking on R and I can be held as BDDs in memory, R possibly partitioned: R(V,V’) =  i R i (V, v i ’ ) h is held as a BDD over concrete and abstract states CEGAR can also be implemented with SAT or Theorem Prover

65 65 Generating the Initial Abstraction  If we use predicate abstraction then predicates are extracted from the program’s control flow and the checked property  If we use localization reduction then the unabstracted variables are those appearing in the predicates above

66 66 Example init(x) := 0 next(x) := case : 0; : x + 1; : 0; else : x; esac; init(y) := 1; next(y) := case : 0;  ¬ : y + 1; : 0; else : y; esac; reset=TRUE x < yy=2x=y reset=TRUE x < yx=y y=2  = AF x=y AP = { reset=TRUE, x<y, x=y, y=2 }

67 67 Model Check The Abstract Model Given the abstract model M h  If M h |  , then the model checker generates a counterexample trace (T h )  Most current model checkers generate paths or loops  Question : is T h spurious?

68 68 Counterexamples For AGp it is a path to a state satisfying  p For AFp it is a infinite path represented by a path+loop, where all states satisfy  p On the other hand, For EFp we need to return the whole computation tree (the whole model)

69 69 Path Counterexample Assume that we have four abstract states {1,2,3}   {4,5,6}   {7,8,9}   {10,11,12}   Abstract counterexample T h = , , ,     therefore, M |=  T h is not spurious,

70 70 Spurious Path Counterexample T h is spurious failure state The concrete states mapped to the failure state are partitioned into 3 sets

71 71 Refining The Abstraction  Goal : refine h so that the dead-end states and bad states do not belong to the same abstract state.  For this example, two possible solutions.

72 72 Computing a Concrete Counterexample from an Abstract one Let T = (a 1,…a n ) be a path abstract counterexample h -1 (a) = { s | h(s) = a } The set of concrete counterexamples corresponding to T: h -1 (T) = { (s 1,…s n ) |  i h(s i )=a i  I(s 1 )   i R(s i,s i+1 ) }

73 73 BDD-based computation of h -1 (a 1 ),…, h -1 (a n ) S 1 = h -1 (a 1 )  I For i = 2,…,n do S i = Image(S i-1 )  h -1 (a i ) if S i =  then dead-end := S i-1 return(i-1, dead-end) print (“counterexample exists”) Return (S 1,…,S n )

74 74 Computing a concrete counterexample from S 1,…,S n t n = choose (S n ) For i = n-1 to 1 t i = choose ( predecessors(t i+1 )  S i ) Return ( (t 1,…,t n ) )

75 75 Remark: If h(s i ) = a i then for every atomic formula f, s i |= f  a |= f In particular, if a n |=  p then s n |=  p Therefore, if (a 1,…a n ) is an abstract counterexample then (s 1,…s n ) is a concrete counterexample

76 76 Refining the abstraction Refinement separates dead-end states from bad states, thus, eliminating the spurious transition from S i-1 to S i

77 77 Implementing CEGAR With BDDs: The concrete model M is finite but too big to directly apply model checking on R and I can be held as BDDs in memory, R possibly partitioned: R(V,V’) =  i R i (V, v i ’) h is held as BDD over concrete and abstract states Can also be implemented with SAT or Theorem Prover

78 78 Conclusion We defined several types of abstractions We showed how to extract them from the concrete model or from the program text We presented the CEGAR framework for abstraction-refinement We considered several possible implementations

79 79 More on abstraction 3-valued and even multi-valued abstraction Static analysis for computing abstract models directly from program text Abstract interpretation: Instead of h:  : 2 S -> S h  : S h -> 2 S

80 80 THE END

81 81 BDDs: R. E. Bryant, Graph-based Algorithms for Boolean Function Manipulation, IEEE transactions on Computers, 1986 BDD-based model checking: J.R. Burch, E.M. Clarke, K.L. McMillan, D.L. Dill, L.J. Hwang, Symbolic Model Checking: 10^20 States and Beyond, LICS’90 SAT-based Bounded model checking: Symbolic model checking using SAT procedures instead of BDDs, A. Biere, A. Cimatti, E. M. Clarke, M. Fujita, Y. Zhu, DAC'99

82 82 Existential abstraction + data abstraction: E. M. Clarke, O. Grumberg, D. E. Long, Model Checking and Abstraction, TOPLAS, 1994. Localization reduction: R. P. Kurshan, Computer-Aided Verification of coordinating processes – the automata theoretic approach, 1994

83 83 Predicate abstraction: S. Graf and H. Saidi, Construction of abstract state graphs with PVS, CAV’97 H. Saidi and N. Shankar, Abstract and Model Check while you Prove, CAV’99 BDD-based CEGAR: Clarke, Grumberg, Jha, Lu, Veith, Counterexample-guided Abstraction Refinement, CAV2000, JACM2003


Download ppt "1 Model Checking, Abstraction- Refinement, and Their Implementation Orna Grumberg Verification seminar March 2006."

Similar presentations


Ads by Google