Model Checking, Abstraction-Refinement, and Their Implementation

1. Model Checking, Abstraction-Refinement, and Their Implementation Based on slides by: Orna Grumberg Presented by: Yael Meller June 2008

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. 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 Main Limitation: The state explosion problem

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

5. Definitions equivalence between models that strongly preserves CTL* (-calculus): If M1  M2 then for every CTL*formula , M1|=   M2|=  preorder on models that weakly preserves ACTL*: If M2  M1 then for every ACTL*formula , M2|=  M1|= 

6. M2 1’ a 4’ 2’ b b 1 a 6’ 4 3’ 5’ 2 d c c b b 6 3 5 c d d b a b a a b Equivalence of models M1  M2 M1 H={ (1,1’), (2,4’), (4,2’), (3,5’), (3,6’), (5,3’), (6,3’) }

7. wait wait coin coin coin coke pepsi coke pepsi Preorder between models M1  M2 M1 M2

8. Abstraction • One of the most useful ways tofightthe state explosion problem • They should preserveproperties of interest: properties that hold for the abstract model should hold for the concrete model • Abstractions should be constructeddirectly fromthe program

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

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

11. Outline for abstraction (cont.) • We first define an abstract model Mh based on a concrete (full) model M of the system • Goal: constructing Mh directly from the program text P  Mh M Abstract model Concrete model

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

13. h h h Existential Abstraction Given an abstraction function h : S Sh, the concrete states are grouped and mapped into abstract states : Mh M ≤ Mh M

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

15. How to define an abstract model: The abstract model Mh = ( Sh, Ih, Rh, Lh ) • sh IhsI : h(s) = sh • (sh,th)  Rh s,t [ h(s) = sh h(t) = th (s,t)R ] • Lh(sh) = L(s) for some s where h(s) = sh This is an exact abstraction

16. An approximated abstraction(an approximation ) • sh IhsI : h(s) = sh • (sh,th)  Rh s,t [ h(s) = sh h(t) = th (s,t)R ] • Lhis as before Notation: Mr– reduced (exact) Mh - approximated

17. Logic preservation • Mh (exact or approximated) has less states but more behaviors: Mh  Mtherefore: • Theorem If  is an ACTL/ACTL* specification over AP, then Mh|=  M|= However, the reverse may not be valid

18. Abstraction example Program with one variable x over the integers Initiallyx may be either 0 or 1 At any step, x may non-deterministically either decrease or increase by 1

19. Abstraction example (cont.) Abstraction 1: Sh1 = { a–, a0, a+ } a+ if s(x)>0 h1(s) = a0 if s(x)=0 a– if s(x)<0 Abstraction 2: Sh2 = { aeven,aodd } h2(s) = if even( |s(x)| ) then aeven else aodd

20. x=0 x=1 aeven aodd x=-1 x=2 x=-2 x=3 Abstraction 1 Abstraction 2 a0 a+ a– The concrete model

21. Types of Abstraction • 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]

22. Predicate abstraction • Given a program over variables V • Predicate Pi is a first-order atomic formula over VExamples: x+y < z2 , x=5 • Choose: AP = { P1,…,Pk } that includes • the atomic formulas in the property  and • conditions in if, while statements of the program • Labeling of concrete states:L(s) = { Pi | s |= Pi }

23. Abstract model • Abstract states are defined over Boolean variables { B1,...,Bk }:Sh { 0,1 }k • h(s) = sh  for all 1jk : [ s |= Pj  sh |= Bj ] • Lh(sh) = { Pj | sh |= Bj }

24. Example Program over natural variables x, y AP = { P1, P2, P3 } where P1 = x≤1 , P2 = x>y , P3 = y=2 AP = { x≤1 , x>y , y=2 } L((0,0)) = L((1,1)) = L(0,1)) = { P1 } L((0,2)) = L((1,2)) = { P1, P3 } L((2,0)) = { P2 }

25. Example (cont.) Sh { 0,1 }3 h((0,0)) = h((1,1)) = h(0,1)) = (1,0,0) h((0,2)) = h((1,2)) = (1,0,1) h((2,0)) = (0,1,0) No concrete state is mapped to (1,1,1) Lh((1,0,0)) = { P1 } Lh((1,0,1)) = { P1, P3 } The concrete state and its abstract state are labeled identically (sh,th)  Rh s,t [ h(s) = sh h(t) = th (s,t)R ]

26. Computing Rh (same example) • Program with one statement: x := x+1 ( (b1,b2,b3) , (b’1,b’2,b’3) ) Rh xyx’y’ [ P1(x,y)  b1 P2(x,y)  b2 P3(x,y)  b3 x’=x+1  y’=y  P1( x’,y’ )  b’1 P2( x’,y’ )  b’2 P3( x’,y’ )  b’3 ]

27. Abstraction functionh mapsgreen,yellowtogo. red go Mh Traffic Light Example • Property: • =AGAF¬(state=red) red M |=   green Mh |=  yellow M

28. M |= butMh |=  Traffic Light Example (Cont) If the abstract model invalidates a specification, the actual model may still satisfy the specification. • Property: • =AG AF (state=red) red red green go yellow • SpuriousCounterexample: • red,go,go, ... Mh M

29. CounterExample-Guided Abstraction-Refinement (CEGAR)

30. M and  generateinitial abstraction Mh Mh|=  model check Mh|= generate counterexample Th stop refinement Th Th check spurious counterexample Th is not spurious is spurious The CEGAR Methodology

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

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

33. Model Check The Abstract Model Given the abstract model Mh • IfMh |, then the model checker generates a counterexample trace (Th) • Most current model checkers generate paths or loops • Question : is Th spurious?

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

35. failure state Spurious Path Counterexample Th is spurious The concrete states mapped to the failure state are partitioned into 3 sets

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

37. Refining the abstraction • Refinement separates dead-end states from bad states, thus, eliminating the spurious transition from Si-1 to Si

38. M and  generateinitial abstraction Mh Mh|=  model check Mh|= generate counterexample Th stop refinement Th Th check spurious counterexample Th is not spurious is spurious The CEGAR Methodology

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

40. THE END