Yael-background-abstractionRefinment

Model Checking, AbstractionRefinement, and Their
Implementation
Based on slides by:
Orna Grumberg
Presented by: Yael Meller
June 2008
1
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*
2
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
3
Possible solution
Replacing the system model by a smaller
one (less states and transitions) that
still preserves properties of interest



Modular verification
Symmetry
Abstraction
4
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 |= 
5
Equivalence of models
M1
2
3
b
M1  M2
1
a
5
c
b
d
1’
4
2’
6
d
3’
d
b
M2
a
4’
b
5’
c
6’
c
H={ (1,1’), (2,4’), (4,2’), (3,5’), (3,6’), (5,3’), (6,3’) }
a
b
a
b
b
a
6
Preorder between models
M1  M2
M1
M2
wait
wait
coin
coin
coke
pepsi
coin
coke
pepsi
7
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
8
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.
9
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
10
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
M
Concrete model

Mh
Abstract model
11
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
12
Existential Abstraction
Given an abstraction function h : S  Sh, the
concrete states are grouped and mapped into
abstract states :
Mh
M ≤ Mh
h
h
h
M
13
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)
14
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
15
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 ]
Lh is as before
Notation:
Mr – reduced (exact)
Mh - approximated
16
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
17
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
18
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
19
The concrete model
x=0
x=1
x=-1
x=2
x=-2
x=3
Abstraction 1
Abstraction 2
a0
a–
aeven
aodd
a+
20
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]
21
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 }
22
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 }
23
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 }
24
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 ] 25
Computing Rh (same example)

Program with one statement:
( (b1,b2,b3) , (b’1,b’2,b’3) )
x := x+1
 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 ]
26
Traffic Light Example
Property:
 =AG AF ¬ (state=red)
Abstraction function h
maps green, yellow to
go.
red
green
red
M |=   Mh |= 
go
yellow
M
Mh
27
Traffic Light Example (Cont)
If the abstract model invalidates a specification, the
actual model may still satisfy the specification.
red
red
 Property:
 =AG AF (state=red)
go
 M |=  but Mh |= 
Mh
 Spurious Counterexample:
green
yellow
M
red,go,go, ...
28
CounterExample-Guided
Abstraction-Refinement
(CEGAR)
29
The CEGAR Methodology
M and 
generate initial
abstraction
Mh
Mh
|= 
model check
Mh
refinement
Th
is spurious
|= 
generate
counterexample Th
Th
check spurious
counterexample
stop
Th is not spurious
30
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
31
Example
init(x) := 0
next(x) := case
reset=TRUE : 0;
x < y : x + 1;
x = y : 0;
else : x;
esac;
init(y) := 1;
next(y) := case
esac;
reset=TRUE : 0;
x=y  ¬ y=2 : y + 1;
x = y : 0;
else : y;
 = AF x=y
AP = { reset=TRUE, x<y, x=y, y=2 }
32
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?
33
Path Counterexample
Assume that we have four abstract states
{1,2,3}   {4,5,6}  
{7,8,9}   {10,11,12}  
Abstract counterexample Th= , , , 




Th is not spurious, therefore, M |= 
34
Spurious Path Counterexample
failure state
Th is spurious
The concrete states mapped
to the failure state are
partitioned into 3 sets
states
dead-end
reachable
yes
out edges
no
bad
no
yes
irrelevant
no
no
35
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.
36
Refining the abstraction

Refinement separates dead-end states
from bad states, thus, eliminating the
spurious transition from Si-1 to Si
37
The CEGAR Methodology
M and 
generate initial
abstraction
Mh
Mh
|= 
model check
Mh
refinement
Th
is spurious
|= 
generate
counterexample Th
Th
check spurious
counterexample
stop
Th is not spurious
38
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
39
THE END
40