Model Checking of Software
description
Transcript of Model Checking of Software
![Page 1: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/1.jpg)
1
Model Checking of Software
Mooly Sagiv
(Contributions from Orna Grumberg
and Eran Yahav)
![Page 2: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/2.jpg)
2
What is model checking?
c-000157-mp-000001.jpg
![Page 3: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/3.jpg)
3
What is software model checking?
Program
Model CheckerProperty
Yes No/Erroneous Input
![Page 4: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/4.jpg)
4
Model CheckerMutual exclusion
Yes
P1: while (1) do {wait(turn==1);
CR1; turn =0;
}
P0: while (1) do {wait(turn==0);
CR0; turn =1;
}
![Page 5: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/5.jpg)
5
MC
No null dereferences
typedef struct element {
int value; struct element next;
} Elements
void main() {
Elements y;
…
search(7, y);
bool search( int value, Elements head)
{
Elements elem = head;while ( head != NULL ) {
if (elem val == value)
return TRUE;
elem = elem next;
} return FALSE; }
head,y elem1 2 3 NULL
NO
![Page 6: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/6.jpg)
6
Specification Challenge
• How does one specify what the application software is supposed to do?
• Different correctness notions
• Can be very difficult and impossible on a real application
• Software is constantly modified
![Page 7: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/7.jpg)
7
Toward Realistic Specification
• Partial– Only addresses certain aspects
• Can be wrong• Different formalisms
– Executable
– Declarative• First order logic
• Temporal logic
• Some mechanisms for modularity
![Page 8: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/8.jpg)
8
Model Checking Challenges
It is not decidable even to check properties such as absence of NULL
dereferences
![Page 9: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/9.jpg)
9
Coping with Undecidablity(Classical Theorem Proving Approach)
• Allow user interaction– Specify loop invariants
• The model checker need not terminate on all programs
• Manually write proofs of certain parts
![Page 10: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/10.jpg)
10
Coping with Undecidablity(Classical MC Approach)
• Extract a finite state machine that conservatively describes program behavior (model)
• Specify the property using a formula in propositional temporal logic
• Automatically check that the model satisfy the formula
• Refine the model when spurious counter examples occur
![Page 11: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/11.jpg)
11
Classical MC Approach ProgramHigh level specification
Yes No/Erroneous Input
Front-End
temporal propotional formula
Model
Model Checker
![Page 12: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/12.jpg)
12
Mutual exclusionl1: while (1) do {
NC1:wait(turn==1); CR1: turn =0;
}
l0: while (1) do {NC0: wait(turn==0);
CR0: turn =1; }
Front-End(pc0=CR0 pc1=CR1)
l0,l1turn=0
l0,NC1turn=0
NC0, NC1turn=0
NC0,l1turn=0
CR0,NC1turn=0
CR0,l1turn=0
l0,l1turn=1
NC0,l1turn=1
NC0, NC1turn=1
l0,NC1turn=1
NC0,CR1turn=1
l0,CR1turn=1
![Page 13: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/13.jpg)
13
Accessibilityl1: while (1) do {
NC1:wait(turn==1); CR1: turn =0;
}
l0: while (1) do {NC0: wait(turn==0);
CR0: turn =1; }
Front-End pc0=CR0 pc1=CR1
l0,l1turn=0
l0,NC1turn=0
NC0, NC1turn=0
NC0,l1turn=0
CR0,NC1turn=0
CR0,l1turn=0
l0,l1turn=1
NC0,l1turn=1
NC0, NC1turn=1
l0,NC1turn=1
NC0,CR1turn=1
l0,CR1turn=1
![Page 14: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/14.jpg)
14
No null dereferences
typedef struct element {
int value; struct element next;
} Elements
void main() {
Elements y;
…
l1: search(7, y);
bool search( int value, Elements head)
{
l2: Elements elem = head;
l3: while ( head != NULL ) {
l4: if (elem val == value)
l5: return TRUE;
l6: elem = elem next;
}
l7: return FALSE;
}
(pc=l4 pc=l6 elem
l3e,h
l4e,h
l5e,h
l6e,h
l3e=,h
l7e=,h=
l3e=,h=
![Page 15: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/15.jpg)
15
Coping with Undecidablity(Abstract Interpretation)
• Define operational semantics of the program• Safety properties can be defined a program
condition• Liveness properties require trace semantics• Collecting semantics define the set of states• Abstract states conservatively represent many
concrete states• Use an abstract interpretation algorithm to provide
a sound solution– Finite number of explored abstract states
![Page 16: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/16.jpg)
16
How to give a presentation
• What to say and how to say it
• Getting through the audience
• Visual aids
![Page 17: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/17.jpg)
17
What to say and how to say it
• Communicate the Key Ideas• Don’t get bogged down in Details
– The best talk make you read the paper
• Structure your talk• Use Top-Down approach
– Introduction– Body– [Technicalities]– The Conclusion
Use Examples
![Page 18: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/18.jpg)
18
Introduction
• Define the problem
• Motivate the audience
• Introduce terminology
• Discuss earlier work
• Emphasize the contributions
• [Provide a road map]
Use Examples
![Page 19: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/19.jpg)
19
The body
• Abstract the major results
• Explain the significance of the results
• Explain the main techniques
• Use enlightening examples
• Demonstrations are welcome
![Page 20: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/20.jpg)
20
[Technicalities]
• Expert only part
• Show something really interesting beyond the paper/tool
![Page 21: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/21.jpg)
21
The Conclusion
• Hindsight is clearer than Foresight
• Give open problems/further work
• Indicate that your talk is over
![Page 22: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/22.jpg)
22
Know your audience
• Background
![Page 23: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/23.jpg)
23
Getting through the Audience
• Use Repetitions
• Remind, don’t assume
• Don’t over-run
• Maintain Eye Contact
• Control your voice
• Control your motion
• Take care of your appearance
![Page 24: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/24.jpg)
24
Visual Aids
• PowerPoint transparencies
• Don’t overload transparencies
• Don’t use too many transparencies
• Use Overlays Properly
• Use Color Effectively
• Use Pictures and Tables
• The blackboard can be used too
![Page 25: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/25.jpg)
25
Don’t overload transparencies
• The input of the program can be arbitrary.
• Let x be a prime number, i.e., all the numbers z<x do not divide x. y be the next prime number, i.e., etc.
• Arbitrary input• Prime number x
– The next prime y
![Page 26: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/26.jpg)
26
Use overlays (im)properly
• Item 1– Item 1.1– Item 1.2
• Item 2– Item 2.1
• Item 2.1.1
![Page 27: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/27.jpg)
27
Use colors properly
• Item 1
• Item 2
• Item 3
![Page 28: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/28.jpg)
28
Model Checking, Abstractionsand Reductions
Orna GrumbergComputer Science Department
Technion
Haifa, Israel
![Page 29: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/29.jpg)
29
Program verification
Given a program and a specification,
does the program satisfy the specification?
Not decidable!
We restrict the problem to a decidable one:
• Finite-state reactive systems
• Propositional temporal logics
![Page 30: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/30.jpg)
30
Model Checking
An efficient procedure that receives
• Description of a finite-state system (model)
• Property written as a formula of propositional temporal logic
It returns yes, if the system has the property
It returns no + counterexample, otherwise
![Page 31: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/31.jpg)
31
Finite state systems
• hardware designs
• Communication protocols
• High level description of non finite state systems
![Page 32: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/32.jpg)
32
Properties in temporal logic
• mutual exclusion: always ( cs1 cs2)
• non starvation: always (request eventually grant)
• communication protocols: ( get-message) until send-message
![Page 33: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/33.jpg)
33
Model of a system Kripke structure / transition system
a,b a
ab,c
c
a,c a,bb
![Page 34: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/34.jpg)
34
M=<S, I, R, L>
• S - Set of states.
• I S - Initial states.
• R S x S - Total transition relation.
• L: S 2AP - Labeling function.
AP – Set of atomic propositions
Model of systems
![Page 35: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/35.jpg)
35
=s0s1s2... is a path in M from s iff
s = s0 and for every i0: (si,si+1)R
![Page 36: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/36.jpg)
36
Propositional temporal logicIn Negation Normal FormAP – a set of atomic propositionsTemporal operators:GpFpXppUq Path quantifiers: A for all path E there exists a path
![Page 37: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/37.jpg)
37
Computation Tree Logic(CTL)
CTL operator:path quantifier + temporal operator
Literals: p , p for pAPBoolean operators: f g , f g
Universal formulas: AX f, A(f U g), AG f , AF fExistential formulas: EX f, E(f U g), EG f , EF f
![Page 38: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/38.jpg)
38
Semantics for CTL• For pAP:
s |= p p L(s) s |= p p L(s)
• s |= fg s |= f and s |= g
• s |= fg s |= f or s |= g
• s |= EXf =s0s1... from s: s1 |= f
• s |= E(f Ug) =s0s1... from s
j0 [ sj |= g and i : 0 i j [si |= f ] ]
• s |= EGf =s0s1... from s i 0: si |= f
![Page 39: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/39.jpg)
39
Linear Temporal logic (LTL)
Formulas are of the form Af ,
where f can include
any nesting of temporal operators
but no path quantifiers
![Page 40: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/40.jpg)
40
CTL*Includes LTL and CTL and more
ACTL*, ACTL (LTL)Universal fragments of CTL*, CTL
ECTL*, ECTLExistential fragment of CTL*, CTL
![Page 41: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/41.jpg)
41
Example formulas CTL formulas:
• mutual exclusion: AG ( cs1 cs2)
• non starvation: AG (request AF grant)
• “sanity” check: EF request
LTL formulas:
• fairness: A(GF enabled GF executed)
• A(x=a y=b XXXX z=a+b)
![Page 42: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/42.jpg)
42
Property types
Universal Existential
Safety AGp EGp
Liveness AFp EFp
![Page 43: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/43.jpg)
43
Property types (cont.)
Combination of universal safety
and existential liveness:
“along every possible execution, in every state there is a possible continuation that will eventually reach a reset state”
AG EF reset
![Page 44: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/44.jpg)
44
Model Checking M |= f
[Clarke, Emerson, Sistla 83] • The Model Checking algorithm works iteratively
on subformulas of f , from simpler subformulas to more complex ones
• When checking subformula g of f we assume that all subformulas of g have already been checked
• For subformula g, the algorithm returns
the set of states that satisfy g ( Sg ) • The algorithm has time complexity: O( |M| |f| )
![Page 45: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/45.jpg)
45
Model checking f = EF g Given a model M= < S, I, R, L >
and Sg the sets of states satisfying g in M
procedure CheckEF (Sg )
Q := emptyset; Q’ := Sg ;while Q Q’ do Q := Q’; Q’ := Q { s | s' [ R(s,s’) Q(s’) ] }end while
Sf := Q ; return(Sf )
![Page 46: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/46.jpg)
46
g
g
g
f
f
f
f
f
f
f
Example: f = EF g
![Page 47: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/47.jpg)
47
Model checking f = EG g CheckEG gets M= < S, I, R, L > and Sg
and returns Sf
procedure CheckEG (Sg)
Q := S ; Q’ := Sg ;
while Q Q’ do
Q := Q’;
Q’ := Q { s | s' [ R(s,s’) Q(s’) ] }
end while
Sf := Q ; return(Sf )
![Page 48: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/48.jpg)
48
g
g
g
g
g
g
Example: f = EG g
![Page 49: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/49.jpg)
49
Symbolic model checking[Burch, Clarke, McMillan, Dill 1990]
If the model is given explicitly (e.g. by adjacent
matrix) then only systems with about ten Boolean
variables (~1000 states) can be handled
Symbolic model checking uses
Binary Decision Diagrams ( BDDs )
to represent the model and sets of states. It can handle
systems with hundreds of Boolean variables.
![Page 50: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/50.jpg)
50
Binary decision diagrams (BDDs) [Bryant 86]
• Data structure for representing Boolean functions
• Often concise in memory
• Canonical representation
• Boolean operations on BDDs can be done in polynomial time in the BDD size
![Page 51: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/51.jpg)
51
BDDs in model checking
• Every set A can be represented by its characteristic function 1 if uA fA(u) = 0 if u A
• If the elements of A are encoded by sequences over {0,1}n then fA is a Boolean function and can be represented by a BDD
![Page 52: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/52.jpg)
52
• Assume that states in model M are encoded by {0,1}n and described by Boolean variables v1...vn
• Sf can be represented by a BDD over v1...vn
• R (a set of pairs of states (s,s’) ) can be represented by a BDD over v1...vn v1’...vn’
![Page 53: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/53.jpg)
53
a
b
c
10
c
1 1
bc
1 1
b
cc
b
0 11 0
a
b
cc
1 1 10
c c c
BDD for f(a,b,c) = (a b ) c
Decision tree
a
b
c
10
BDD
![Page 54: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/54.jpg)
54
State explosion problem
• Hardware designs are extremely large: > 106 registers
• state of the art symbolic model checking can handle medium size designs effectively:a few hundreds of Boolean variables
Other solutions for the state explosion problem are needed!
![Page 55: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/55.jpg)
55
Possible solutionReplacing the system model by a smaller one
(less states and transitions) that still preserves
properties of interest
• Modular verification
• Symmetry
• Abstraction
![Page 56: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/56.jpg)
56
We define:
equivalence between models that strongly preserves CTL*
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 |=
![Page 57: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/57.jpg)
57
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
![Page 58: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/58.jpg)
58
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 : p AP: s2 |= p s1 |= p
s2 |= p s1 |= p
t1 [ (s1,t1) R1 t2 [ (s2,t2) R2 (t1,t2) H ] ]
Notation: s1 s2
![Page 59: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/59.jpg)
59
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
![Page 60: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/60.jpg)
60
Bisimulation relation [Park]
For models M1 and M2, H S1 x S2 is a bisimulation
iff for every (s1, s2 ) H :
p AP : p L(s2) p 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
![Page 61: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/61.jpg)
61
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 and
for every s2 I2 there is s1 I1 s.t. (s1, s2 ) H
Notation: M1 M2
![Page 62: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/62.jpg)
62
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
![Page 63: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/63.jpg)
63
M1 M2
Simulation preorder
M1 M2
wait
coin coin
pepsicoke
wait
coin
coke pepsi
![Page 64: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/64.jpg)
64
M1 M2
a
b
cdd dc
a
bb
M1 M2
![Page 65: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/65.jpg)
65
M1 M2
a
b
cdd dc
a
bb
M1 M2 and M1 M2 but not M1 M2
![Page 66: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/66.jpg)
66
(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 |=
![Page 67: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/67.jpg)
67
Abstractions
• They are 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
![Page 68: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/68.jpg)
68
Data abstraction
Abstracts data information while still enabling
to partially check properties referring to data
E. Clarke, O. Grumberg, D. Long.
Model checking and abstraction,TOPLAS, Vol. 16, No. 5, Sept. 1994
![Page 69: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/69.jpg)
69
Data AbstractionGiven a program P with variables x1,...xn , each over domain D,the concrete model of P is defined over states
(d1,...,dn) D...D Choosing• abstract domain A• Abstraction mapping (surjection) h: D A
we get an abstract model over abstract states (a1,...,an) A...A
![Page 70: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/70.jpg)
70
ExampleGiven a program P with variable x over the integers
Abstraction 1:
A1 = { a–, a0, a+ }
a+ if d>0
h1(d) = a0 if d=0
a– if d<0
Abstraction 2:
A2 = { aeven, aodd }
h2(d) = if even( |d| ) then aeven else aodd
![Page 71: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/71.jpg)
71
Labeling by abstract atomic propositions
We assume that the states of the concrete model M
of P are labeled by abstract atomic propositions
of the form (xA = a) for a A
(xA means that we refer to the abstract value of x)
for s = (d1,...,dn)
L(s) = { (xiA = ai) | h(di) = ai }
![Page 72: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/72.jpg)
72
State equivalence
Given M, A, h : D A
h((d1,...,dn)) = (h(d1),...,h(dn)) States s,s’ in S are equivalent (s ~ s’) iff h(s) = h(s’)
An abstract state (a1,...,an) represents the
equivalence class of states (d1,...,dn) such that
h((d1,...,dn)) = (a1,...,an)
![Page 73: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/73.jpg)
73
Reduced abstract modelExistential abstraction
Given M, A, h : D A
the reduced model Mr = ( Sr, Ir, Rr, Lr ) is
Sr = A ... A
sr Ir s I : h(s) = sr
(sr,tr) Rr
s,t [h(s) = sr h(t) = tr (s,t)R]
For sr = (a1,...,an), Lr(sr) = { (xiA = ai) | i = 1, ..., n }
![Page 74: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/74.jpg)
74
h h h
Existential Abstraction
M
Mr
M < Mr
![Page 75: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/75.jpg)
75
Theorem:
Mr M by the simulation preorder
Corollary:
For every ACTL* formula :
If Mr |= then M |=
![Page 76: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/76.jpg)
76
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
![Page 77: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/77.jpg)
77
The concrete model
x=0 x=1x=-1
x=-2 x=3
x=2
aeven aodd
Abstraction 2
xA= a0
xA= a+xA= a–
Abstraction 1
![Page 78: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/78.jpg)
78
Representing M by first-order formulas
In order to show how to construct Mr
from the program text,
we assume that the program is given
by first order formulas I (X) and R (X, X’ ) where
X=(x1,...xn) and X'=(x1’,...xn’)
![Page 79: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/79.jpg)
79
Representing M by first-order formulas (cont)
I (X) and R (X, X’) describe the
model M=(S, I, R, L) as follows:
Let s=(d1,...dn), s’=(d1’,...,dn’)
s I I [xidi] = true
(s, s’) R R [xi di, xi’ di’ ] = true
![Page 80: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/80.jpg)
80
Representing a program by formulas: example
statement: k: x:=e k’
Formula R : pc=k x’=e pc’=k’
statement: k: if x=0 then k1: x:=1 else k2: x:=x+1 k’
Formula R:( 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’)
![Page 81: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/81.jpg)
81
Given a formula over variables x1, ...,xk
[] (x1A, ..., xk
A) =
x1,...,xk ( h(x1)= x1A ... h(xk)= xk
A (x1, ...,xk) )
Let I (X) and R (X, X’) be the formulas describing M.
Then [I (X) ] and [R (X, X’)] describe Mr
Note: [I (X) ] and [R (X, X’)] are formulas over abstract variables
![Page 82: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/82.jpg)
82
Problem:
Given [I (X) ] and [R (X, X’)],
in order to determine if sr Ir, we need to find
a state s I (a satisfying assignment for I (X))
so that h(s) = sr.
Similarly, for (sr, tr) Rr we look for
a satisfying assignment for R (X, X’)
This is a difficult task due to the size and complexity
of the two formulas
![Page 83: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/83.jpg)
83
Simplifying the formulasFor in negation normal form over basic predicates
pi and pi, T() simplifies [] by “pushing” the existential quantifiers inward:
T(pi(x1,...xn)) = [pi](x1A,...xn
A)
T(pi(x1,...xn)) = [pi](x1A,...xn
A)
T(1 2) = T(1) T(2)
T(1 2) = T(1) T(2) T(x) = xA T() T(x) = xA T()
![Page 84: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/84.jpg)
84
Approximation model
Theorem: [] T() In particular, [I ] T(I ) and [R ] T(R )
Corollary:
The approximation model Ma,defined by T(I ) and T(R ) satisfies:
Ma Mr M by the simulation preorder
![Page 85: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/85.jpg)
85
Approximation 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
![Page 86: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/86.jpg)
86
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
![Page 87: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/87.jpg)
87
Abstract predicates provided by the user: Example
statement: x := y+zpredicate p(x’,y,z): x’ = y+z
A = {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 )
![Page 88: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/88.jpg)
88
Useful abstractionsModulo an integer m
Abstraction: h(i) = i mod m
Properties of modulo:
((i mod m) + (j mod m)) mod m = i + j mod m
((i mod m) - (j mod m)) mod m = i - j mod m
((i mod m) (j mod m)) mod m = i j mod m
Specification:
AG( waiting req (in1 mod m = i ) (in2 mod m = j )
A(ack U ( ack (overflow
(output mod m = i + j mod m)))))
![Page 89: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/89.jpg)
89
Useful abstractionslogarithm
Abstraction: h(i) = log2(i+1)
(smallest number of bits to represent i>0 )
Specification: AG ( waiting req ( h(in1) + h(in2) 16)
A (ack U ( ack overflow)))
AG ( waiting req ( h(in1) + h(in2) 18)
A (ack U ( ack overflow)))
![Page 90: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/90.jpg)
90
Counterexample-guided refinement
Goal:• To produce abstraction automatically• To use counter example in order to refine
the abstraction
E. Clarke, O. Grumberg, S. Jha, Y. Lu, and H. Veith. Counterexample-guided abstraction Refinement, CAV’00
![Page 91: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/91.jpg)
91
Traffic Light Example
red
yellow
green
M
Property: =AG AF ¬ (state=red)
Abstraction function h maps green, yellow to go.
red
go
Mh
Mh |= M |=
![Page 92: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/92.jpg)
92
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
yellow
green
red
go
M Mh Spurious Counterexample:
red,go,go, ...
![Page 93: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/93.jpg)
93
Our Abstraction Methodology
Th is not spuriouscheck spurious
counterexample
Th
stop
Mh |=
generatecounterexample Th
Mh |=
model check
Mh
generate initialabstraction
M and
refinement
This spurious
![Page 94: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/94.jpg)
94
Generating the Initial Abstraction
Basic Idea
• Extract atomic formulas from control flow
• Group formulas into formula clusters
• Generate abstraction for each cluster
Intuition : We consider the correlation between variables only when they appear in control flow.
![Page 95: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/95.jpg)
95
Formula Cluster 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;
FC1 = { , , }, FC2 = { }
reset=TRUE reset=TRUEx < y y=2x=y
x = yx = y
VC1 = {x, y}, VC2 = {reset}
x < yx = y y=2
reset=TRUE reset=TRUE
reset=TRUE
x < y x=yx = yx = y
y=2
![Page 96: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/96.jpg)
96
Assume x, y { 0, 1, 2 } reset { true, false }
Formulas in FC1 cannot distinguish{x=0,y=0} and {x=1,y=1},therefore, {x=0,y=0} and {x=1,y=1}have the same effect on the control flow
Initial abstraction: h(0,0) = h(1,1) =
![Page 97: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/97.jpg)
97
Valuations { 0,1,2} { 0,1,2} of (x,y) are partitioned into five equivalence classes:
h1(0,0) = h1(1,1) = h1(0,1) = h1(0,2) = h1(1,2) = h1(1,0) = h1(2,0) = h1(2,0) = h1(2,2) =
Valuations {true, false} of resethave two equivalence classes:
h2(true) = true h2(false) = false
![Page 98: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/98.jpg)
98
Programs and specificationsatoms(P) is the set of conditions in the program P and
atomic formulas in the specification . atoms(P) are
defined over program variables.
Example: x+3<y
is an ACTL* formula over atoms(P)
A state s in the model of P is labeled
with f atoms(P) iff s |= f
![Page 99: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/99.jpg)
99
Initial abstraction
Let {FC1,…,FCm} be a set of formula clusters
Let {VC1,…,VCm} be a set of variable clusters
The initial abstraction h=(h1,…,hm) is defined by
hi(d1…dk) = hi(e1…ek)
iff for all fFCi ,
(d1…dk) |= f (e1…ek) |= f
![Page 100: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/100.jpg)
100
Model Check The Abstract Model
Given a generated abstraction function h,
• Mh is built by using existential abstraction
• If not (Mh |= ), then the model checker generates a
counterexample trace (Th)
• Current model checkers generate paths or loops.
• Question : is Th spurious?
![Page 101: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/101.jpg)
101
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,
![Page 102: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/102.jpg)
102
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
![Page 103: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/103.jpg)
103
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.
![Page 104: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/104.jpg)
104
General Refinement Problem• The optimal refinement is hard to find• Coarser refinements are safer
• the refined abstract machine is still small
• Theorem: Finding the coarsest refinement is NP-hard.
• Heuristic : Treat all the irrelevant states as bad states
• in practice, this works very well
![Page 105: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/105.jpg)
105
Loop Counterexample
length of loop = 4
![Page 106: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/106.jpg)
106
Loop Counterexample (cont)
Important observations
• The size of a concrete loop may be different from the abstract loop
• An abstract loop may correspond to several concrete loops
• Naïve unwinding may be exponential
![Page 107: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/107.jpg)
107
Spurious Loop Counterexample
S1 S2
Restrict original model M to S1 S2, i.e., K = M (S1 S2), then
There is a loop counterexample if and only if
K |= EG TRUE
![Page 108: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/108.jpg)
108
Spurious Loop Counterexample
• If an abstract loop counterexample is spurious, loop unwinding will reach empty set
• Let Tunwind be the unwound loop by |S1| times.
• Theorem: The loop counterexample is spurious iff Tunwind is spurious.
Use refinement algorithm for path counterexample!
![Page 109: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/109.jpg)
109
Completeness
• Our methodology refines the abstraction until either the property is proved or counterexamples are found
• Theorem: Given a model M and an ACTL* specification whose counterexample is either path or loop, our algorithm will find a model Ma
such that
Ma |= M |=
![Page 110: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/110.jpg)
110
Experiment : Fujitsu Design
The multimedia processor is very complicated
• Description includes 61,500 lines of Verilog code
• Manual abstraction by Fujitsu engineers reduces the code to 10,600 lines with 500 registers
• We translated this abstracted code into 9,500 lines of
SMV code
![Page 111: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/111.jpg)
111
Experiment (cont.)
We tried to verify this using state-of-art model checkers
• NuSMV+COI cannnot verify the design
• Bwolen Yang’s SMV cannot verify the design
• Our approach abstracted 144 symbolic variables, used 3 refinement steps, and found a bug
![Page 112: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/112.jpg)
112
Abstract Interpretation
We show how abstractions preserving temporal
logics can be defined within the framework of
abstract interpretation
D. Dams, R. Gerth, O. Grumberg,
Abstract interpretation of reactive systems, TOPLAS Vol. 19, No. 2, March 1997.
![Page 113: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/113.jpg)
113
Abstract interpretation (cont.)
We define abstractions that preserve:– Existential properties (ECTL*)– Universal properties (ACTL*)– Both (CTL*)
We define:• Canonical abstraction that preserves
maximum number of temporal properties• Approximations
![Page 114: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/114.jpg)
114
Abstract interpretation (cont.)
Using abstract interpretation we can obtain
abstract models which are more precise
(and therefore preserve more properties)
than the existential abstraction presented
before
![Page 115: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/115.jpg)
115
The Abstract Interpretation Framework
• Developed by Cousot & Cousot for compiler optimization
• Constructs an abstract model directly from the program text
• Classical abstract interpretationspreserve properties of states. Here we are interested in properties of computations
![Page 116: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/116.jpg)
116
Model
M = ( S, I, R, L ) where S, I, R – as before
Lit = AP { p | p AP }L : S 2Lit - labeling function so thatp L(s) p L(s) and p L(s) p L(s)
But not required: p L(s) p L(s)
![Page 117: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/117.jpg)
117
Galois connection( : C A, : A C) is a Galois connectionfrom (C, ) to (A, ) iff and are total and monotonic• for all c C, ( (c)) c• for all a A, ( (a)) a
If on A is defined by: a a’ (a) (a’)
then for all a, ( (a)) =a and(, ) is a Galois insertion
![Page 118: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/118.jpg)
118
For the partially ordered sets (C, ) and (A, ): the concrete and abstract domains
a a’ - a is more precise than a’ a’ approximates ac c’ - c is more precise than c’ c’ approximates c
: CA maps each c to its most precise (least) abstraction
: A C maps each a to the most general (greatest) c that is abstracted by a
![Page 119: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/119.jpg)
119
Our abstract InterpretationFor model M with state set S
• Choose an abstract domain SA
– SA must contain the top element T
• Define:
abstraction mapping : 2S SA
concretization mapping : SA 2S
We use Galois insertion
![Page 120: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/120.jpg)
120
RemarksFor every set of concrete states C S, ((C) ) C. Therefore, for every C there is an abstract state a
with (a) C. In particular, SA must containa “top” state T so that ( T ) = S.
Not necessarily, for every set C there is a different abstract state a.
For example : SA = { T } with ( T ) = S and for every C S, (C) = T is a correct abstraction (even though meaningless)
![Page 121: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/121.jpg)
121
ExampleAbstract states:A = { grt_5, leq_5, T }(grt_5 ) = {s S | s(x) > 5 }(leq_5 ) = {s S | s(x) 5 }
The set {s S | s(x) > 6 } could be mapped to either grt_5 or T, but grt_5 is more precise, and therefore a better choice
{s S | s(x) >0 } must be mapped to T
![Page 122: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/122.jpg)
122
Relation transformers
Given sets A and B and a relation R A x B,
the relations R , R 2A x 2B are defined
R = {(X,Y) | xX yY R(x,y)}
R= {(X,Y) | xX yY R(x,y) }
![Page 123: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/123.jpg)
123
If R is a transition relation
R(X,Y) iff there exists some state in X that makes a transition to some state in Y
R (X,Y) iff every state in X makes a transition to some state in Y
![Page 124: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/124.jpg)
124
Goal
Given a set of abstract states SA, to construct
the most precise model MA = (SA, IA, RA, LA)
such that for every CTL* formula and
abstract state a SA,
MA, a |= M, (a) |=
![Page 125: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/125.jpg)
125
LA
For p Lit :
p LA(a) s (a): p L(s)
Note: it is possible that p LA(a) and p LA(a)
The definition guarantees for every p Lit :
a |= p (a) |= p
![Page 126: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/126.jpg)
126
IA
IA = { ( s ) | s I }
( ( s ) means ({s}) )
Guarantees that MA |= M |=
Explanation:
MA |= aIA: MA, a |=
aIA: M, (a) |= sI : M, s |= M |=
![Page 127: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/127.jpg)
127
More on IAAn alternative definition: IA = (I) is less precise.
Example:
M |= A(p AX q ) but not ( MA |= A(p AX q ) )
pp
q q
s1 s2a12
q q
M MA
![Page 128: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/128.jpg)
128
RA
We define two abstract transition relations:
RA preserves ACTL*
RE preserves ECTL*
Putting them together in the same
model will preserve full CTL*
![Page 129: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/129.jpg)
129
RA
In order to preserve ACTL* we may add
more transitions, but never lose one.
Possible definition:
RA (a, b) R ((a), (b))
![Page 130: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/130.jpg)
130
RA (cont.)A more precise definition:
adds less transitions to more precise abstract states
RA(a, b)
Y S [ (Y)=b Y is a minimal set that satisfies R ((a), Y)]
Note: Y is always a singleton
![Page 131: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/131.jpg)
131
RA (cont.)
p,q p,q p
s1
s3
s2
s5s4
a12 |= AX (pq)a12
a4 a35a345
p,q p
T
(s1)=(s2)=a12 (s3)=(s5)=a35 (s4)=a4
![Page 132: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/132.jpg)
132
RE
In order to preserve ECTL* we
may eliminate some transitions,
but never add non-real ones.
Possible definition:
RE (a, b) R ((a), (b))
![Page 133: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/133.jpg)
133
RE (cont.)A more precise definition:
keeps more transitions to
more precise abstract states
RE(a, b)
Y S [(Y)=b [Y is a minimal set that satisfies R ((a), Y)]
![Page 134: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/134.jpg)
134
RA and RE
• Because of minimality, not necessarily RE RA
• Minimality is not necessary for correctness of abstraction. We will later give it up in orderto compute abstract models more easily.
p
q q
s1 s2
a12
q q
p
s4s3 a3 a4
a34
![Page 135: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/135.jpg)
135
Mixed model
MA = (SA, IA, RA, RE, LA)
A-path is a path over RA-transitionsE-path is a path over RE-transitions
MA, a |= AX f b [ (a,b) RA MA, b |= f ]
MA, a |= EX f b [ (a,b) RE MA, b |= f ]
![Page 136: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/136.jpg)
136
Model checking on mixed models
CTL model checking works iteratively, from
simpler subformulas to more complex ones.
Each subformula will be checked on either RA
or RE, according to the main operator of the
formulaa1 |=AX EXp
p p
a1
![Page 137: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/137.jpg)
137
We have constructed MA, which given SA,, is the
best model satisfying for every in CTL*
MA |= M |=
If not ( MA |= ) then we can check whether
MA |= .
If neither holds then SA is too coarse to give the
answer.
![Page 138: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/138.jpg)
138
Approximations
As in other abstractions:
• We would like to construct the abstraction directly from the program text
• Best abstraction is too difficult to compute
• We therefore construct approximation to the abstraction
![Page 139: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/139.jpg)
139
HA SA SA is defined over mixed abstract models,
each with state set SA
Mixed simulation is similar to simulation, except that
the condition on (s1, s2) H saying that
s2 has “more” successors than s1 is replaced for
(a1, a2) HA by
• a2 has “more” A-successors than a1
• a2 has “less” E-successors than a1
Mixed simulation
![Page 140: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/140.jpg)
140
a1
p p q
a2
q p p p
a2 a1 by the mixed simulation
a2 |= AXp a1 |= AXp
a2 |= Exq a1 |=EXq
![Page 141: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/141.jpg)
141
Theorem:If A’ and A’’ are mixed models andA’’ A’ by the mixed simulationthen for every CTL* formula A’’ |= A’ |=
Corollary:
If A MA by the mixed simulationthen A |= M |=
![Page 142: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/142.jpg)
142
Computing abstraction from the program text
Assume a program that repeatedly computes
a set of transitions:
{ ci(x) ti(x,x') | i J }.
Being in state s, it chooses nondeterministically
a transition i for which ci(s) is true.
The transition results in state s' for which
ti(s, s') is true.
![Page 143: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/143.jpg)
143
ciA(a) s (a): ci(s)
tiA(a, b) Y S [(Y)=b
Y is a minimal set that satisfies ti ((a), Y)]
ciE(a) s (a): ci(s)
tiE(a, b) Y S [(Y)=b
Y is a minimal set that satisfies ti ((a), Y)]
![Page 144: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/144.jpg)
144
Approximation for RA and RE
R'A = { (a,b) | iJ: ciA(a) ti
A(a, b) }
R'E = { (a,b) | iJ: ciE(a) ti
E(a, b) }
Example
Program: { x=4 x' := x/4 }
SA = { even, odd, T }
RA = { (even, odd), (T, odd) }
R'A = { (even, odd), (T, odd), (even, even) }
![Page 145: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/145.jpg)
145
ExampleProgram: { even(x) x' := x/2
even(x) x' := x+1 }
SA = { even, odd, T }RE = { (even, odd) }R'E = { (even, odd ), (even, T) }
Lemma• RA R'A
• For all a, b SA [ R'E(a,b) b'' b [ RE(a, b'') ]]
![Page 146: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/146.jpg)
146
Further approximation
Give up minimality in the definition of
tiA and ti
E :
Replace transition (a, b) by transition (a, b')
with b b' by the mixed simulation.
• Easier to compute from the program text.• Still preserves (possibly less) CTL* formulas.
![Page 147: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/147.jpg)
147
State-of-the-art Abstraction
Abstract interpretation (Cousot & Cousot 77, Loiseaux & Graf & Sifakis & Bouajjani & Bensalem 95,Graf 94)
(Bi)-simulation reduction (Bouajjani & Fernandez & Halbwachs 90,Lee & Yannakakis 92, Fisler & Vardi 98,Bustan & Grumberg 00)
Formula-dependent equivalence(Aziz & Singhal & Shiple & Sangiovanni-Vincentelli 94)
Compositional minimization(Aziz & Singhal & Swamy & Brayton 94)
![Page 148: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/148.jpg)
148
State-of-the-art Abstraction (Cont)
Uninterpreted functions (Burch & Dill 94, Berzin & Biere & Clarke & Zhu 98, Bryant & German & Velve 99)
Abstraction and refinement (Dams & Gerth & Grumberg 93, Kurshan94, Balarin & Sangiovanni-Vincentelli 93, Lind-Nielsen & Andersen 99)
Predicate abstraction and Theorem proving(Das & Dill & Park 99, Graf & Saidi 97, Uribe 99)
![Page 149: Model Checking of Software](https://reader030.fdocuments.us/reader030/viewer/2022013101/56815750550346895dc4f401/html5/thumbnails/149.jpg)
149
The End