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 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
15
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
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 1jk : [ 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
© Copyright 2026 Paperzz