1 2-Valued and 3-Valued Abstraction- Refinement Frameworks for Model Checking Orna Grumberg Technion Haifa, Israel Tutorials at ATVA, 2009

2 Outline 2-valued Abstraction –CounterExample-Guided Abstraction- Refinement (CEGAR) 3-Valued Abstraction –Three-Valued abstraction-Refinement (TVAR)

3 Why (formal) verification? safety-critical applications: Bugs are unacceptable! –Air-traffic controllers –Medical equipment –Cars Bugs found in later stages of design are expensive, e.g. Intel’s Pentium bug in floating-point division Hardware and software systems grow in size and complexity: Subtle errors are hard to find by testing Pressure to reduce time-to-market Automated tools for formal verification are needed

4 Model Checking An efficient procedure that receives:  A finite-state model describing a system  A temporal logic formula describing a property It returns yes, if the system has the property no + Counterexample, otherwise [EC81,QS82]

5 Model Checking  Emerging as an industrial standard tool for verification of hardware designs: Intel, IBM, Cadence, …  Recently applied successfully also for software verification: SLAM (Microsoft), Java PathFinder and SPIN (NASA), BLAST (EPFL), CBMC (Oxford),…

6 Model of a system Kripke structure / transition system a,ba a b,c c a,c a,b b

7 Temporal Logics Linear Time –Every moment has a unique successor –Infinite sequences (words) –Linear Time Temporal Logic (LTL) Branching Time –Every moment has several successors –Infinite tree –Computation Tree Logic (CTL) Temporal Logics – Express properties of event orderings in time

8 Propositional temporal logic In Negation Normal Form AP – a set of atomic propositions Temporal operators: Gp Fp Xp pUq Path quantifiers: A for all path E there exists a path

9 Branching-time Temporal Logics CTL*,  -calculus - powerful branching-time logics, containing both CTL and LTL ACTL / ACTL* / A  -calculus The universal fragments of the logics, with only universal path quantifiers

10 Main limitation of Model Checking 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

11 Solutions to the state explosion problem Small models replace the full, concrete model: Abstraction Compositional verification Partial order reduction Symmetry

12 Abstraction-Refinement Abstraction: removes or simplifies details that are irrelevant to the property under consideration, thus reducing the number of states Refinement might be needed

13 Manual abstraction requires –great creativity and –close familiarity with the checked system Goal: –Automatically construct an abstract model –Automatically refine it, if necessary

14 2-valued CounterExample-Guided Abstraction Refinement (CEGAR) For ACTL* [CGJLV00]

15 Abstraction preserving ACTL/ACTL* Existential Abstraction: 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

16 Existential Abstraction MCMC MAMA Given an abstraction function h : S  S A, the concrete states are grouped and mapped into abstract states : hhh M C  M A

17 MCMC MAMA hhh Existential Abstraction (cont.) p p p p p pp AP = {p} p pp pp pp Given an abstraction function h : S  S A, the concrete states are grouped and mapped into abstract states : p

18 Labeling of abstract states The abstraction function h : S  S A is chosen so that: If h(s) = h(t) = s A then L(s) = L(t) L A (s A ) = L(s)

19 Widely used Abstractions (S A, h)  For Hardware: Localization reduction: each variable either keeps its concrete behavior or is fully abstracted (has free behavior) [Kurshan94]  For Software: Predicate abstraction: concrete states are grouped together according to the set of predicates they satisfy [GS97,SS99]

20 Logic preservation Theorem  Theorem M C  M A, therefore for every ACTL* formula , M A |=   M C |=   However, the reverse may not be valid.

21 Traffic Light Example red green yellow MCMC Property:  = AG AF ¬ (state=red) Abstraction function h maps green, yellow to go. red go MAMA M A |=  M C |=  

22 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 C |=  but M A |=  red green yellow red go MCMC MAMA  Spurious Counterexample :  red,go,go,... 

23 The CEGAR Methodology T A is not spurious check spurious counterexample TATA stop M A |=  generate counterexample T A M A |=  model check MAMA generate initial abstraction M and  refinement TATA is spurious

24 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

25 Counterexamples For AGp it is a finite path to a state satisfying  p For AFp it is an infinite path represented by a lasso (finite path+loop), where all states satisfy  p

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

27 Remark:  and {10, 11, 12} are labeled the same –If  satisfies  p then 10, 11, 12 also satisfy  p Therefore, (1, 4, 9, 12) is a concrete path counterexample

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

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

30 Automatic Refinement If the counterexample is spurious Find a splitting criterion that separates the bad states from the dead-end states in the failure state Apply the splitting criterion to splitting either only the failure state or all states –Faster convergence of the CEGAR loop –Faster growing abstract models

31 Checking for Spurious Path Counterexample T = (a 1,…a n ) - a path abstract counterexample h -1 (a) = { s | h(s) = a }

32 Checking for Spurious Path Counterexample (cont.) The set of concrete counterexamples corresponding to T = (a 1,…a n ) : h -1 (T) = { (s 1,…s n ) |  i h(s i )=a i  I(s 1 )   i R(s i,s i+1 ) } Is h -1 (T) empty?

33 Checking for Spurious Path Counterexample T h is spurious dead-end 

34 Refining the abstraction Refinement separates dead-end states from bad states, thus, eliminates the spurious transition from a i-1 to a i

35 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 = successors(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 )

36 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 ) )

37 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

38 Three-Valued Abstraction Refinement (TVAR) for Full CTL* [SG03,GLLS05] Thanks to Sharon Shoham for the slides on TVAR

39 Goal: Logic preservation for CTL* Theorem If M A is an abstraction of M C then for every CTL* formula , M A |=   M C |=  M A |    M C |   But sometimes [M A |=  ] = don’t know

40 Abstract Models for CTL* Two transition relations [LT88] Kripke Modal Transition System (KMTS) M = (S, S 0, Rmust, Rmay, L) –Rmust: an under - approximation –Rmay: an over - approximation –Rmust ⊆ Rmay

41 Abstract Models for CTL* (cont.) Labeling function : L: S → 2 Literals Literals = AP ⋃ {  p | p  AP } At most one of p and  p is in L(s). –Concrete: exactly one of p and  p is in L(s). –KMTS: possibly none of them is in L(s).

42 Abstract Models for CTL (cont.) Concrete Kripke structure M C = (S C, S 0C, R C, L C ) Set of abstract states S A Concretization function  : S A → 2 Sc Abstract KMTS M A = (S A, S 0A, Rmust, Rmay, L A )

43 MCMC MAMA Labeling of abstract states  Abstract Models for CTL* (cont.) p p p p p ¬p¬p ¬p¬p ¬p¬p ¬p¬p ¬p¬p

44 MCMC MAMA must and may transitions:  Abstract Models for CTL* (cont.) must: under approximation (  ) may: over approximation (  )

Valued Semantics Universal properties ( A  ) : - Truth is examined along all may-successors - Falsity is shown by a single must-successor EExistential properties ( E  ) : - Truth is shown by a single must-successor - Falsity is examined along all may-successors

Valued Framework Additional truth value:  (indefinite) Abstraction preserves both truth and falsity (abstract) s a represents (concrete) s c : –  is true in s a ⇒  is true in s c –  is false in s a ⇒  is false in s c –  is  in s a ⇒ the value of  in s c is unknown [BG99] tt, ff are definite

47 The TVAR Methodology stop [M A |= 3  ] = tt,ff find and analyze failure node [M A |= 3  ] =  model check MAMA generate initial abstraction M and  refinement

48 3-Valued Model Checking: Example  = AXp  EXq M: p,  q st p, q

49 MC graph (s, AXp  EXq) (s, AXp) (s, p)(t, q) (s, EXq) (s, q)(t, p)  = AXp  EXq M: p,  q st p, q

50 Coloring the MC graph (s, AXp  EXq) (s, AXp) (s, p)(t, q) (s, EXq) (s, q)(t, p)  = AXp  EXq M: p,  q st p, q reason for unknown: may - son - not enough to verify - prevents refutation ff tt ⊥

51 Abstraction - Refinement Traditional abstraction - refinement is designed for 2 - valued abstractions: –True holds in the concrete model. –False may be a false alarm. ⇒ Refinement is needed when the result is false and is based on a counterexample analysis.

52 3-Valued Model Checking Results tt and ff are definite: hold in the concrete model as well. ⊥ is indefinite ⇒ Refinement is needed.

53 MCMC MAMA As for the case of 2-values, done by splitting abstract states  Refinement

54 Refinement Identify a failure state: a state s a for which some subformula  is  in s a –Done during model checking Split s a so that –an indefinite atomic proposition becomes definite (true or false), or –A may transition becomes a must transition or disappears

55 Refinement (cont.) Uses the colored MC graph Find a failure node n f : –a node colored  whereas none of its sons was colored  at the time it got colored. –the point where certainty was lost purpose: change the  color of n f. Refinement is reduced to separating subsets of the concrete states represented by n f.

56 Example (s, AXp  EXq) (s, AXp) (s, p)(t, q) failure (s, EXq) (s, q)(t, p)  = AXp  EXq M: p,  q st p, q reason for failure: may - son - not enough to verify - prevents refutation ff tt ⊥

57 M st MCMC  concrete states that have a son corresponding to the may-edge are separated from the rest (t, q) (s, EXq) Example (cont.)

58 Example (cont.)  = AXp  EXq M: p,  q st p, q  = AXp  EXq M’: p,  q s1s1 t p, q p,  q s2s2 (s 1, AXp  EXq) (s 1, AXp) (s 2, p)(t, q) (s 1, EXq) (s 2, q)(t, p)

59 (s 1, AXp  EXq) (s 1, AXp) (s 2, p)(t, q) (s 1, EXq) (s 2, q)(t, p) ff tt ⊥  = AXp  EXq M’: p,  q s1s1 t p, q p,  q s2s2 Example (cont.)

60 Completeness Our methodology refines the abstraction until a definite result is received. For finite concrete models iterating the abstraction - refinement process is guaranteed to terminate, given any CTL formula.

61 Incremental Abstraction - Refinement No reason to split states for which MC results are definite during refinement. After each iteration remember the nodes colored by definite colors. Prune the refined MC graph in sub - nodes of remembered nodes. [ (s a,  ) is a sub - node of (s a ’,  ’) if  =  ’ and  (s a ) ⊆  ’(s a ’) ] Color such nodes by their previous colors.

62 Example

63 Example (cont.) Refined MC - graph

64 Example (cont.)

65 Example (cont.) Refined MC - graph …

66 Conclusion We presented two frameworks for abstraction-refinement in model checking: CTL Model Checking for abstract models –2-valued semantics: as for concrete models –3 - valued semantics: using MC-graph Refinement eliminating –Counterexamples, in the 2-valued case –indefinite results, in the 3-valued case Incremental abstraction - refinement –Called lazy abstraction in the 2-valued case

67 Conclusion We presented two frameworks, CEGAR and TVAR, for abstraction-refinement in model checking: Properties preserved: –CEGAR: ACTL* –TVAR: Full CTL* Refinement eliminates –CEGAR: Counterexamples –TVAR: indefinite results (  )

68 Conclusion (cont.) The TVAR framework requires Different abstract models (Rmust, Rmay) –Rmust is harder to compute Adapted model checking Gives benefits in preciseness and scalability

69 Thank You