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
