1

Model Checking, Abstraction-Refinement, and Their

Implementation

Orna Grumberg

Verification seminarMarch 2006

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

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

Possible solutionReplacing the system model by a

smaller one (less states and transitions) that still preserves properties of interest

• Modular verification• Symmetry• Abstraction

6

We define: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 |=

7

The simulation preorder [Milner]

Given two models M1 = (S1,I1,R1,L1), M2 = (S2,I2,R2,L2)

H S1 x S2 is a simulation iff

for every (s1, s2 ) H :

• s1 and s2 satisfy the same propositions

• For every successor t1 of s1 there is a successor t2 of s2 such that (t1,t2) H

Notation: s1 s2

8

The simulation preorder [Milner]

Given two models M1 = (S1,I1,R1,L1), M2 = (S2,I2,R2,L2)

H S1 x S2 is a simulation iff

for every (s1, s2 ) H :

• L(s1) = L(s2)

t1 [ (s1,t1) R1 t2 [ (s2,t2) R2 (t1,t2) H ] ]

Notation: s1 s2

9

Simulation preorder (cont.)

H S1 x S2 is a simulation from M1

to M2 iff

H is a simulation and for every s1 I1 there is s2 I2 s.t. (s1,

s2) H

Notation: M1 M2

10

Bisimulation relation [Park]

For models M1 and M2, H S1 x S2 is a bisimulation

iff for every (s1, s2 ) H :

• L(s2) = L(s1) t1 [ (s1,t1) R1 t2 [ (s2,t2) R2 (t1,t2) H ] ]

t2 [(s2,t2) R2 t1 [(s1,t1) R1 (t1,t2) H ]]

Notation: s1 s2

11

Bisimulation relation (cont.)

H S1 x S2 is a Bisimulation between M1 and M2

iff H is a bisimulation and for every s1 I1 there is s2 I2 s.t. (s1, s2 ) H

andfor every s2 I2 there is s1 I1 s.t. (s1, s2 )

H

Notation: M1 M2

12

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

a b aab

b

Bisimulation equivalence

M1 M2

ab b

d dc

14

3 6

2

5

M1a

b b

c cd

1’

2’

3’

4’

5’ 6’

M2

13

M1 M2

Simulation preorder

M1 M2

wait

coin coin

pepsicoke

wait

coin

coke pepsi

14

M1 M2

a

b

cdd dc

a

bb

M1 M2

15

M1 M2

a

b

cdd dc

a

bb

M1 M2 and M1 M2 but not M1 M2

16

(bi)simulation and logic preservation

Theorem:If M1 M2 then for every CTL* formula ,

M1 |= M2 |=

If M2 M1 then for every ACTL* formula ,

M2 |= M1 |=

Holds also for -calculus and its universal fragment

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

Abstraction

• Removes or simplifies details• Removes entire componentsthat are irrelevant to the propertyunder consideration, thus reducing # of states

Manual abstraction requires great creativity.

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

• 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

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

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

23

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

24

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

25

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

26

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

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

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

29

The concrete modelx=0 x=1

x=-1

x=-2 x=3

x=2

aeven aodd

Abstraction 2

a0

a+a–

Abstraction 1

30

Types of Abstraction (Sh, 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

Depending on h and the size of M, Mh (I.e. Ih, Rh ) can be built using:

BDDs or

SAT solver or

Theorem prover

We later demonstrate such constructions

for specific types of abstractions

32

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

33

• Labeling of concrete states:

L(s) = { Pi | s |= Pi }

34

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 }

35

Example

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

36

Sh { 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)

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 ]

37

Computing Rh (same example)

• Program with one statement: x := x+1

38

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

39

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

Rh is computed according to the formula above, using BDD operations

40

Computing Rh 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: |Sh|x|Sh| applications

41

Computing Rh with SAT or Theorem Prover (example cont.)

• Given Sh = (1,0,0) th = (0,0,0)

• To determine if (sh, th) Rh , check:

xyx’y’ [ h((x,y)) = (1,0,0) h((x’,y’)) = (0,0,0)

((x,y),(x’y’))R ] xyx’y’ [ P1(x,y) P2(x,y) P3(x,y) x’=x+1 y’=y

P1(x’,y’) P2(x’,y’) P3(x’,y’) ]

42

• Using BDDs, Rh is computed based on the concrete model M

• Using SAT or Theorem prover, Rh can be viewed as computed directly from the program text

• We later show a more direct construction from the program text

43

Approximation

• For BDDs:Approximate the computation of Rh

For SAT and theorem prover:

• In case of check failure for a pair (sh,th), include the pair in Rh

44

Data Abstraction

• Given a program over variables v1,…vn where vi is over a domain Di

• Program states (concrete) S = D1 x…x Dn

Choose for each vi:• an abstract domain Ai

• hi : Di Ai

Sh = A1 x…x An

45

AP = { viA

=a | a Ai , i=1,…n }

where viA refers to the abstract value of vi

• h : S Sh is defined:h ((d1,…,dn)) = (a1,…,an) where ai = hi(di)

• L ((d1,…,dn)) ={ viA

=ai | hi(di) = ai , i=1,…,n }

• Lh ((a1,…,an)) ={ viA

=ai | i=1,…,n }

As before: L(s) = Lh (h(s))

46

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

whereV=( v1,...,vn ) and V'=( v1’,...,vn’ )

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

Representing a program by formulas: example (cont)

program: k: if x=0 then k1: x:=1 else k2: x:=x+1 k’

Formula R (x, pc, x’, pc’):( pc=k x=0 x’=x pc’ = k1) ( pc=k x 0 x’=x pc’ = k2) ( pc=k1 x’=1 pc’=k’) ( pc=k2 x’=x+1 pc’=k’)

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=(d1,...dn), s’=(d1’,...,dn’)

s I I [vidi] = true

(s, s’) R R [vi di, vi’ di’ ] = true

50

Notation:For a formula over variables v1, ...,vk [] (v1

A, ..., vkA) =

v1,...,vk ( h(v1)= v1A ... h(vk)= vk

A

(v1, ...,vk) )

Note: [I (V) ] and [R (V, V’)] are formulas over abstract variables

[I (V)] and [R (V, V’)] represent Mr

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 Mr

52

Problem:Given [I (V) ] and [R (V, V’ )],

in order to determine if sr Ir, we need to find a state s I (a satisfying assignment for I(V)) so that h(s) = sr

Similarly, for (sr, tr) Rr 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

Simplifying the formulas

For in negation normal form over basic predicates pi and pi, T() simplifies [] by “pushing” the existential quantifiers inward:

T(pi(v1,...,vn)) = [pi](v1A,...,vn

A)

T(pi(v1,...,vn)) = [pi](v1A,...,vn

A)

T(1 2) = T(1) T(2)

T(1 2) = T(1) T(2) (*)

(*) does not preserve equivalence

54

Approximated model

Theorem: [] T() In particular, [I ] T(I ) and [R ] T(R )

Corollary:The approximation model Mh,defined by T(I ) and T(R ) satisfies:Mh Mr M by the simulation preorder

55

Approximated model (cont.)

• Defined over the same set of abstract states as Mr

• Easier to compute since existential quantifiers are applied to simpler formulas

• Less precise: has more initial states an more transitions than Mr

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 [pi] and [pi] for every basic action (assignment or condition) in the program

57

Abstract predicates provided

by the user: Examplestatement: x := y+zpredicate p(x’,y,z): x’ = y+zA = {aeven, aodd }

[p](x’A,yA,zA) = { (aeven, aodd, aodd),

(aeven, aeven, aeven), (aodd, aodd, aeven), (aodd, aeven, aodd) }

[p](aeven, aodd, aodd) iff

x’,y,z ( h(x’) = aeven h(y) = aodd h(z)= aodd x’=y+z )

58

Logic preservation Theorem

Theorem If is an ACTL/ACTL* specification over AP, then

Mh |= M |=

However, the reverse may not be

valid.

59

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

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

red

green

yellow

red

go

M Mh Spurious Counterexample:

red,go,go, ...

61

CounterExample-Guided Abstraction-Refinement (CEGAR)

62

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

63

Refinement versus approximation

Remark:Refinement builds new Sh and h,

then recomputes Rh and Ih (exact or approximated)

Approximation uses the same Sh and h and just adds more transitions and initial states

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 Ri (V, vi’ )

• h is held as a BDD over concrete and abstract states

CEGAR can also be implemented with SAT or Theorem Prover

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

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

reset=TRUE reset=TRUEx < y x=y

x = yx = yy=2

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

67

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?

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

Path Counterexample

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

70

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

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

Computing a Concrete Counterexample from an Abstract

oneLet T = (a1,…an) be a path abstract

counterexampleh-1(a) = { s | h(s) = a }

The set of concrete counterexamples corresponding to T:

h-1(T) = { (s1,…sn) | i h(si)=ai I(s1)

iR(si,si+1) }

73

BDD-based computation of h-1(a1),…, h-1(an)

S1 = h-1(a1) I

For i = 2,…,n do Si = Image(Si-1) h-1(ai)

if Si= then

dead-end := Si-1

return(i-1, dead-end)print (“counterexample exists”) Return (S1,…,Sn)

74

Computing a concrete counterexample

from S1,…,Sn

tn = choose (Sn)

For i = n-1 to 1

ti = choose ( predecessors(ti+1) Si )

Return ( (t1,…,tn) )

75

Remark:

• If h(si) = ai then for every atomic formula f, si |= f a |= f

• In particular, if an |= p then sn |= p

• Therefore, if (a1,…an) is an abstract counterexample then (s1,…sn) is a concrete counterexample

76

Refining the abstraction

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

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 Ri (V, vi’)

• h is held as BDD over concrete and abstract states

Can also be implemented with SAT or Theorem Prover

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

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: : 2S -> Sh

: Sh -> 2S

80

THE END

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

• 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

• 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