Transcript 2-Valued and 3-Valued AbstractionRefinement Frameworks for Model Checking Orna Grumberg Technion Haifa, Israel Tutorials at ATVA, 2009

2-Valued and 3-Valued AbstractionRefinement Frameworks for Model Checking
Orna Grumberg
Technion
Haifa, Israel
Tutorials at ATVA, 2009
1
Outline
• 2-valued Abstraction
– CounterExample-Guided AbstractionRefinement (CEGAR)
• 3-Valued Abstraction
– Three-Valued abstraction-Refinement (TVAR)
2
Why (formal) verification?
• safety-critical applications: Bugs are unacceptable!
– Air-traffic controllers
– Medical equipment
– Cars
• Bugs found in later stages of design are expensive, e.g.
Intel’s Pentium bug in floating-point division
• Hardware and software systems grow in size and complexity:
Subtle errors are hard to find by testing
• Pressure to reduce time-to-market
Automated tools for formal verification are needed
3
Model Checking
An efficient procedure that receives:
 A finite-state model describing a system
 A temporal logic formula describing a property
It returns
yes, if the system has the property
no + Counterexample, otherwise
[EC81,QS82]
4
Model Checking

Emerging as an industrial standard tool for
verification of hardware designs: Intel,
IBM, Cadence, …

Recently applied successfully also for
software verification: SLAM (Microsoft),
Java PathFinder and SPIN (NASA), BLAST
(EPFL), CBMC (Oxford),…
5
Model of a system
Kripke structure / transition system
a,b
a
a
b,c
b
a,c
a,b
c
6
Temporal Logics
• Temporal Logics
– Express properties of event orderings in time
• Linear Time
–
–
–
Every moment has a unique successor
Infinite sequences (words)
Linear Time Temporal Logic (LTL)
• Branching Time
–
–
–
Every moment has several successors
Infinite tree
Computation Tree Logic (CTL)
7
Propositional temporal logic
In Negation Normal Form
AP – a set of atomic propositions
Temporal operators:
Gp
Fp
Xp
pUq
Path quantifiers: A for all path
E there exists a path
8
Branching-time Temporal Logics
CTL*, -calculus - powerful branching-time
logics, containing both CTL and LTL
ACTL / ACTL* / A-calculus
The universal fragments of the logics, with
only universal path quantifiers
9
Main limitation of Model Checking
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
10
Solutions to the state explosion problem
Small models replace the full, concrete model:
• Abstraction
• Compositional verification
• Partial order reduction
• Symmetry
11
Abstraction-Refinement
• Abstraction: removes or simplifies details
that are irrelevant to the property under
consideration, thus reducing the number of
states
• Refinement might be needed
12
• Manual abstraction requires
– great creativity and
– close familiarity with the checked system
• Goal:
– Automatically construct an abstract model
– Automatically refine it, if necessary
13
2-valued CounterExample-Guided
Abstraction Refinement (CEGAR)
For ACTL*
[CGJLV00]
14
Abstraction preserving ACTL/ACTL*
Existential Abstraction:
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
15
Existential Abstraction
Given an abstraction function h : S  SA, the
concrete states are grouped and mapped into
abstract states :
MA
MC  MA
h
h
h
MC
16
Existential Abstraction (cont.)
Given an abstraction function h : S  SA, the
concrete states are grouped and mapped into
abstract states :
p
MA
h
MC
p
p
p
p
h
AP = {p}
p
h
p p p
p
p
17
Widely used Abstractions (SA, h)

For Hardware:
Localization reduction: each variable either keeps
its concrete behavior or is fully abstracted (has
free behavior) [Kurshan94]

For Software:
Predicate abstraction: concrete states are
grouped together according to the set of
predicates they satisfy [GS97,SS99]
19
Logic preservation Theorem

Theorem MC  MA, therefore for every
ACTL* formula ,
MA |=   MC |= 

However, the reverse may not be valid.
20
Traffic Light Example
Property:
 =AG AF ¬ (state=red)
Abstraction function h
maps green, yellow to
go.
red
green
red
MC |= 
 MA |=

go
yellow
MC
MA
21
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
 MC |=  but MA |= 
MA
 Spurious Counterexample:
green
yellow
MC
red,go,go, ...
22
The CEGAR Methodology
M and 
generate initial
abstraction
MA
MA |= 
model check
MA |= 
refinement
TA
is spurious
generate
counterexample TA
TA
check spurious
counterexample
stop
TA is not spurious
23
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
24
Counterexamples
• For AGp it is a finite path to a state
satisfying p
• For AFp it is an infinite path represented
by a lasso (finite path+loop), where all
states satisfy p
25
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 |= 
26
Remark:
•  and {10, 11, 12} are labeled the same
– If  satisfies p then 10, 11, 12 also
satisfy p
Therefore, (1, 4, 9, 12) is a concrete
path counterexample
27
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
28
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.
29
Automatic Refinement
If the counterexample is spurious
• Find a splitting criterion that separates
the bad states from the dead-end states
in the failure state
• Apply the splitting criterion to splitting
either only the failure state or all states
– Faster convergence of the CEGAR loop
– Faster growing abstract models
30
Checking for Spurious Path Counterexample
• T = (a1,…an) - a path abstract
counterexample
h-1(a) = { s | h(s) = a }
31
Checking for Spurious Path Counterexample
(cont.)
The set of concrete counterexamples
corresponding to T = (a1,…an) :
h-1(T) = { (s1,…sn) | i h(si)=ai  I(s1) 
iR(si,si+1) }
Is h-1(T) empty?
32
Checking for Spurious Path Counterexample
dead-end

Th is spurious
33
Refining the abstraction
• Refinement separates dead-end states
from bad states, thus, eliminates the
spurious transition from ai-1 to ai
34
Three-Valued Abstraction Refinement
(TVAR)
for Full CTL*
[SG03,GLLS05]
Thanks to Sharon Shoham for the slides on TVAR
38
Goal:
Logic preservation for CTL*
Theorem
If MA is an abstraction of MC then for every CTL*
formula ,
MA |=   MC |= 
MA |   MC | 
• But sometimes [MA |=  ] = don’t know
39
Abstract Models for CTL*
• Two transition relations
[LT88]
• Kripke Modal Transition System (KMTS)
• M = (S, S0, Rmust, Rmay, L)
– Rmust: an under-approximation
– Rmay: an over-approximation
– Rmust ⊆ Rmay
40
Abstract Models for CTL* (cont.)
Labeling function :
• L: S→ 2Literals
• Literals = AP ⋃ {p | pAP }
• At most one of p and p is in L(s).
– Concrete: exactly one of p and p is in L(s).
– KMTS: possibly none of them is in L(s).
41
Abstract Models for CTL* (cont.)
Labeling of abstract states
¬p
MA
p

MC
¬p
¬p
¬p

p
¬p

p
p
p
43
Abstract Models for CTL* (cont.)
must:
may: under
over
approximation
()
()
must and may transitions:
MA
MC



44
3-Valued Semantics
• Universal properties (A) :
- Truth is examined along all may-successors
- Falsity is shown by a single must-successor
• Existential properties (E) :
- Truth is shown by a single must-successor
- Falsity is examined along all may-successors
45
3-Valued Framework
tt, ff are
definite
• Additional truth value:  (indefinite)
• Abstraction preserves both truth and
falsity
• (abstract) sa represents (concrete) sc:
–  is true in sa⇒  is true in sc
–  is false in sa ⇒  is false in sc
–  is  in sa ⇒ the value of  in sc is unknown
[BG99]
46
The TVAR Methodology
M and 
generate initial
abstraction
MA
refinement
model check
[MA |=3 ] = tt,ff
[MA |= 3 ] = 
find and analyze
failure node
stop
47
3-Valued Model Checking:
Example
M:
s p, q
p, q t
 = AXp EXq
48
M:
MC graph
s p, q
 = AXp EXq
(s, AXpEXq)
(s, AXp)
(s, p)
(t, p)
p, q t
(s, EXq)
(s, q)
(t, q)
49
tt
ff
Coloring the MC graph
⊥
7
5
s p, q
p, q t
 = AXp EXq
(s, AXpEXq)
(s, AXp)
M:
6
(s, EXq)
(s, p)
(t, p)
(s, q)
(t, q)
1
2
3
4
reason for unknown:
may-son
- not enough to verify
- prevents refutation
50
Abstraction-Refinement
• Traditional abstraction-refinement is
designed for 2-valued abstractions:
– True holds in the concrete model.
– False may be a false alarm.
⇒ Refinement is needed when the result is
false and is based on a counterexample
analysis.
51
3-Valued Model Checking Results
• tt and ff are definite: hold in the
concrete model as well.
• ⊥ is indefinite
⇒ Refinement is needed.
52
Refinement
• As for the case of 2-values, done by
splitting abstract states
MA
MC



53
Refinement
• Identify a failure state: a state sa for
which some subformula  is  in sa
– Done during model checking
• Split sa so that
– an indefinite atomic proposition becomes
definite (true or false), or
– A may transition becomes a must transition
or disappears
54
Refinement (cont.)
• Uses the colored MC graph
• Find a failure node nf:
– a node colored  whereas none of its sons was
colored  at the time it got colored.
– the point where certainty was lost
• purpose: change the
 color of nf .
Refinement is reduced to separating subsets
of the concrete states represented by nf.
55
Example
tt
ff
M:
s p, q
⊥
7
p, q t
 = AXp EXq
(s, AXpEXq)
failure
5
(s, AXp)
6
(s, EXq)
(s, p)
(t, p)
(s, q)
(t, q)
1
2
3
4
reason for failure:
may-son
- not enough to verify
- prevents refutation
56
Example (cont.)
(s, EXq)
(t, q)
concrete states that have a son corresponding to the
may-edge are separated from the rest
M
MC
s

t

57
Example (cont.)
7
5
M:
M’:
s1 p,p,qq
 =p,AXp
q EXq
s2
(s1, AXpEXq)
(s1, AXp)
p,p, qq tt
 = AXp EXq
6
(s1, EXq)
(s2, p)
(t, p)
(s2, q)
(t, q)
1
2
3
4
58
tt
ff
Example (cont.)
M’:
s1 p, q
⊥
7
5
s2 p, q
(s1, AXpEXq)
(s1, AXp)
p, q t
 = AXp EXq
6
(s1, EXq)
(s2, p)
(t, p)
(s2, q)
(t, q)
1
2
3
4
59
Completeness
• Our methodology refines the abstraction
until a definite result is received.
• For finite concrete models iterating the
abstraction-refinement process is
guaranteed to terminate, given any CTL
formula.
60
Incremental Abstraction-Refinement
No reason to split states for which MC
results are definite during refinement.
• After each iteration remember the nodes
colored by definite colors.
• Prune the refined MC graph in sub-nodes of
remembered nodes.
[ (sa, ) is a sub-node of (sa’, ’) if =’ and (sa)⊆’(sa’) ]
• Color such nodes by their previous colors.
61
Example
62
Example (cont.)
Refined MC-graph
63
Example (cont.)
64
Example (cont.)
Refined MC-graph
…
65
Conclusion
We presented two frameworks, CEGAR and
TVAR, for abstraction-refinement in model
checking:
• Properties preserved:
– CEGAR: ACTL*
– TVAR: Full CTL*
• Refinement eliminates
– CEGAR: Counterexamples
– TVAR: indefinite results ()
67
Conclusion (cont.)
The TVAR framework requires
• Different abstract models (Rmust, Rmay)
– Rmust is harder to compute
• Adapted model checking
• Gives benefits in preciseness and
scalability
68
Thank You
69