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 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 |= 

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

7 M1M1 M2M2 Preorder between models M 1  M 2 wait coin pepsicoke wait coin cokepepsi

8 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

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 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 Outline for abstraction (cont.)

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

14 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) = t only if L(s)=L(t)

15 How to define an abstract model: 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

16 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

17 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 |=  However, the reverse may not be valid

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

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

20 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

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 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 Labeling of concrete states: L(s) = { P i | s |= P i }

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

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

25 Example (cont.) S h  { 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) 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 ]

26 Computing R h (same example) Program with one statement: x := x+1 ( (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 ]

27 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 |=  

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

29 CounterExample-Guided Abstraction-Refinement (CEGAR)

30 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

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 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  = AF x=y AP = { reset=TRUE, x<y, x=y, y=2 }

33 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?

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

35 Spurious Path Counterexample T h is spurious failure state 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 S i-1 to S i

38 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

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