1

Model Checking, Abstraction-Refinement,

and Their ImplementationBased on slides by:

Orna Grumberg

Presented by: Yael MellerJune 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

H={ (1,1’), (2,4’), (4,2’), (3,5’), (3,6’), (5,3’), (6,3’) }

a b aab

b

Equivalence of modelsM1 M2M1

ab b

d dc

14

3 6

2

5

ab b

c cd

1’

2’

3’

4’

5’ 6’

M2

7

M1 M2

Preorder between modelsM1 M2

wait

coin coin

pepsicoke

wait

coin

coke pepsi

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 componentsthat are irrelevant to the propertyunder 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 Mh based on a concrete (full) model M of the system

Goal: constructing Mh directly from the program text P

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

Mh

Given an abstraction function h : S Sh, the concrete states are grouped and mapped into abstract states :

h h h

M ≤ Mh

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 sI : 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 sI : h(s) = sh

(sh,th) Rh

s,t [ h(s) = sh h(t) = th (s,t)R ]

Lh is as before

Notation: Mr – reduced (exact) Mh - approximated

17

Logic preservation

Mh (exact or approximated) has less states but more behaviors: Mh M therefore:

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

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:Sh1 = { a–, a0, a+ }

a+ if s(x)>0

h1(s) = a0 if s(x)=0

a– if s(x)<0Abstraction 2:Sh2 = { aeven, aodd }

h2(s) = if even( |s(x)| ) then aeven else aodd

20

The concrete modelx=0 x=1

x=-1

x=-2 x=3

x=2

aeven aodd

Abstraction 2a0

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 Pi is a first-order atomic formula over V

Examples: 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 1jk : [ s |= Pj sh |= Bj ]

Lh(sh) = { Pj | sh |= Bj }

24

ExampleProgram over natural variables x, yAP = { P1, P2, P3 } where

P1 = x≤1 , P2 = x>y , P3 = y=2AP = { 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

Traffic Light Example

red

green

yellow

M

Property: =AG AF ¬ (state=red)

Abstraction function h maps green, yellow to go.

red

go

Mh

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

red

green

yellow

red

go

M Mh Spurious Counterexample:

red,go,go, ...

29

CounterExample-Guided Abstraction-Refinement (CEGAR)

30

The CEGAR Methodology

Th is not spuriouscheck spurious

counterexample

Th

stop

Mh |=

generatecounterexample Th

Mh |=

model check

Mh

generate initialabstraction

M and

refinement

This 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) := 0next(x) := case

: 0; : x + 1; : 0;else : x;

esac;

init(y) := 1;next(y) := case

: 0; ¬ : y + 1; : 0;else : y;

esac;

reset=TRUE reset=TRUEx < y y=2x=y

x = yx = y

= AF x=yAP = { reset=TRUE, x<y, x=y, y=2 }

33

Model Check The Abstract Model

Given the abstract model Mh

If Mh | , then the model checker

generates a counterexample trace (Th)

Most current model checkers generate paths or loops

Question : is Th spurious?

34

Path CounterexampleAssume that we have four abstract states {1,2,3} {4,5,6} {7,8,9} {10,11,12}

Abstract counterexample Th= , , ,

therefore, M |= Th is not spurious,

35

Spurious Path Counterexample

Th is spurious

failure state The concrete states mapped to the failure state are partitioned into 3 sets

dead-end bad irrelevantyes no nono yes no

statesreachableout edges

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

The CEGAR Methodology

Th is not spuriouscheck spurious

counterexample

Th

stop

Mh |=

generatecounterexample Th

Mh |=

model check

Mh

generate initialabstraction

M and

refinement

This 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