wwwcsuunl docs vakken pv LTL Model Checking Ch 4 LN Overview This pack Abstract model of programs Temporal properties Verification via model checking algorithm Concurrency ID: 780320
Download The PPT/PDF document "Wishnu Prasetya wishnu@cs.uu.nl" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Wishnu Prasetya wishnu@cs.uu.nlwww.cs.uu.nl/docs/vakken/pv
LTL Model Checking
(Ch. 4 LN)
Slide2OverviewThis pack :Abstract model of programsTemporal propertiesVerification (via model checking) algorithmConcurrency 2
Slide3Run-time propertiesHoare triple : express what should hold when the program terminates.Many programs are supposed to work continuouslyThey should be “safe”They should not dead lockNo process should starveLinear Temporal Logic (LTL)Originally designed by philosophers to study the way that time is used in natural language arguments
Based on a number of operators to express relation over time: “next”, “always”, “eventually”
Belong to the class of modal logics
Brought to Computer Science by
Pnueli
, 1977.
3
Slide4Finite State Automaton/MachineAbstraction of a real programChoicesWhat information do we want to put in the states?In the arrows?How to model execution? a path through the FSA, staring at an initial state. Does it have to be finite?Do we need a concept of “acceptance” ? These choices influence what you can express, and how you can verify properties over executions.4
0
1
Slide5FSADescribed by (S, I, , R)S : the set of possible statesI S : set of possible initial states : set of labels, to decorate the arrows. They model possible actions.
R
:
S
pow
(S), the arrowsR(s,a) is the set of possible next-states of a if executed on snon-deterministic
5
Slide6Program compositions can be modeled by operations over FSAWe assume actions to be atomic.M1 ; M2connect “terminal states” of M1 to M2’s initial states.M1 M2only do executions that are possible in bothM
1
||
M
2
model parallel execution of
M1 and M26
Slide7IntersectionNot something you typically do in real programsA useful concept for verification later.70
1
0
1
a
a
(0,0)
(1,1)
a
c
Slide8Parallel compositionSuppose M1 and M2 has no common action.Their parallel composition is basically the “full product” of M1 and M2 .So,if each component has n number of states, constructing || over k components produces an automaton with nk
states.
8
0
1
0
1
a
b
c
||
Slide9Parallel composition with synchronized actionsSuppose we require that any action a 1 2 has to be executed together (synchronizedly) by both automata.9
0
1
0
1
a
a
c
Slide10Let’s add labels10Consider these set of “labels”,
Prop
= { isOdd
x
,
x
>0 }. The labeling is describe by this function V:
V
(0) = { isOdd
x
}
V
(1) = { isOdd
x, x
>0 }
0
1
So far, the only things we know about the states is that they differ from each other. Let’s extend the available information with propositions.
Slide11Kripke StructureA finite automaton ( S, s0, R, Prop, V )
S
: the set of possible states, with
s
0
the initial state.
R : Spow(S), the arrowsR(s) is the set of possible next-states from snon-deterministic
Prop
: set of
atomic
propositions
abstractly modeling state properties.
V
:
S
pow(Prop), labeling function
a
V
(s) means a holds in s, else it does
not
hold.
No concept of accepting states.
11
Slide12PropIt consists of atomic propositions. We’ll require them to be non-contradictive. That is, for any subset Q of Prop : /\Q /\ /\{p | p∈Prop /\
p
Q
}
is
satisfiable. Else you may get inconsistent labeling.This is the case if they are independent of each other.Example:Prop = { x>0 ,
y
>0 } is ok.
Prop
= {
x
>0 ,
x
>1 } is not ok. E.g. the subset { x>1 } is inconsistent.
12
Slide13ExecutionAn execution is a path through your automaton.Let’s focus on properties of infinite executionsAll executions are assumed infiniteExtend each “terminal” state (states with no successor) in the original Krikpe with a stuttering loop.
This induces an ‘
abstract
’ execution: Nat
pow
(Prop)infinite sequence of
the
set of propositions
that hold along that path.
We’ll often use the term execution and abstract execution interchangbly.
13
Slide14Example
14
0
1
Exec. : 0 0 1 1 ...
Abs-exec: {isOdd
x
} , {isOdd
x
}, {isOdd
x
,
x
>0}, {isOdd
x
,
x
>0} , ...
{ isOdd
x
}
{ isOdd
x
,
x
>0 }
Slide15LTL, informal meaning15
f
// always
f
X
g
// next
f
f
U
g
//
f
holds
until
g
f
f
f
f
f
f
f
f
f
f
g
g
Slide16You can combine operators( p (true U q )) // whenever p holds, eventually q will holdp
U
(
q
U
r) true U p
// eventually stabilizing to p
true
U
p
// eventually p will hold infinitely many often
16
Slide17Syntax ::= p // atomic proposition from Prop | |
/\
|
X
| U Derived operators:
\/ = ( /\ )
= \/
,
, W , …
Interpreted over abstract executions.
17
Slide18Defining the meaning of temporal formulasFirst we’ll define the meaning wrt to a single abstract execution. Let
be
such
an
execution: ,i |==
|== = ,0 |==
If
P
is a
Kripke
structure
,
P
|== means
that
holds
on
all
abstract
executions
of
P
18
Slide19MeaningLet be an (abstract) execution.,i |== p = p (i) // p
Prop
,
i
|== =
not (,i |== ),i |== /\ = ,i |==
and
,
i
|==
19
Slide20Meaning,i |== X = ,i+1 |==
,
i
|==
U
=
there is a ji such
that
,
j
|==
and
for
all
h
,
i
h
<
j
, we have ,
h
|== .
20
Slide21Example21Consider : {isOdd x} , {isOdd x}, {isOdd x, x>0}, {isOdd x, x>0} , ...
|== isOdd
x
U
x>0Is this a valid property of the FSA?
0
1
{ isOdd
x
}
{ isOdd
x
,
x
>0 }
Slide22Derived operatorsEventualy = true U Always =
Weak until
W
=
\/ (
U )Release R = W
( /\ )
22
Slide23Some derived operators23<> f // eventually
f
f
W
g
// weak until
g
R
f
// releases
f
f
g,f
f
f
f
f
f
f
g
f
f
f
f
f
f
f
f
f
f
f
f
Slide24Past operatorsUseful, e.g. to say: if P is doing something with
x,
then
it
must have asked a permission to do
so
.
“
previous
”
,
i
|==
Y
=
holds
in
the
previous
state
“
since
”
,
i
|==
S
= ,
j
|==
for
some
j i,
and
for all
j<k i we have ,j |==
Unfortunately, not
supported
by SPIN.
24
Slide25Ok, so how can I verify M |== ?We can’t directly check all executions infinite (in two dimensions).Try to prove it directly using the definitions? We’ll take a look another strategy…First, let’s view abstract executions as sentences.
View
M
as a sentence-generator. Define:
L(
M
) = {
| is an abs-exec of
M
}
these are sentences over
pow
(Prop)
25
Slide26Representing as an automaton …Let be the temporal formula we want to verify.Suppose we can construct automaton B that ‘accepts’ exactly those infinite sentences over pow
(
Prop
) for which holds.
So
B
is such that :
L(
B
) = { | |== }
26
Slide27Re-express as a language problemWell, M |== iffThere is no L(M) where does not hold.
In other words, there is no L(
M
) that will be accepted by L(
B
). So:
M
|==
iff
L(
M
) L(
B
) =
27
Slide28Automaton with “acceptance”So far, all paths are accepted. What if we only want to accept some of them?Add acceptance states.Accepted sentence: “aba” and “aa” is accepted
“
bb
” is
not
accepted.
But this is for finite sentences. For infinite ...?28
a
b
q
1
q
2
a
b
Slide29Buchi Automaton“ababa” not an infinite“ababab…” accepted
“
abbbb
…” not accepted!
Pass an acceptance state infinitely many times.
Examples
29
a
b
q
1
q
2
a
b
Slide30Expressing temporal formulas as Buchi
We’ll take
Prop
= {
p
}
{
p
}
{
p
}
Use
pow
(
Prop
) as the alphabet
of arrow-labels.
Example:
X
p
( =
X
p
)
Indirectly saying that p is false.
We can drop this, since we only need to (fully) cover accepted sentences.
{
p
}
30
Slide31To make the drawing less verbose...31Xp, using Prop = {p}
*
*
X
p
, using
Prop
= {
p,q
}
*
*
p
Stands for all subsets of Prop that do not contain p; thus implying “p does not hold”.
Stands for all subsets of Prop that contain p; thus implying “p holds”.
p
So we have 4 subsets.
p
Slide32Always and Eventually32<>p
p
*
*
[]
p
p
<>[]
p
p
p
*
Slide33Until33p U q :
p
*
q
p
U
X
q
:
p
*
q
*
Slide34Not Until34Formula: ( p U q )
p,q
*
p
q
Note first these properties:
(
p
U
q
) =
p
/\
q
W
p
/\
q
(
p
W
q
) =
p
/\
q
U
p
/\
q
(also generally when
p,q
are LTL formulas)
=
q
W
p
/\
q
=
q
U
p
/\
q
Slide35Generalized Buchi Automaton35[]<>p /\ []<>q
0
2
q
p
*
1
*
*
Sets
of accepting states:
F
= { {1} , {2} }
which is different than just F = { 1, 2 } in an ordinary Buchi.
Every GBA can be converted to BA.
Slide36Difficult casesHow about nested formulas like: (Xp) U q ( p U q ) U
r
Their Buchi is not trivial to construct.
Still, any LTL formula can be converted to a Buchi. SPIN implements an automated conversion algorithm; unfortunately it is quite complicated.
36
Slide37Check listHow to construct B ? Buchi
We still have a mismatch, because
M
is a
Kripke
structure!
Fortunately, we can easily convert it to a Buchi.We still have to construct the intersection.We still to figure out a way to check emptiness.
M
|==
iff
L(
M
) L(
B
) =
37
Slide38Label on state or label on arrow...38a
b
c
a
b
c
b
c
b
d
e
d
e
c
generate the same sentences
generate the same sentences
Slide39Converting Kripke to Buchi390
1
{
isOdd
x }
{
isOdd
x, x>0 }
z
{
isOdd
x }
{
isOdd
x, x>0 }
Generate
the
same
(
infinite
)
sentences
!
Single accepting set F, containing all states.
0
1
{ isOdd
x
}
{ isOdd
x
,
x
>0 }
Slide40Computing intersectionRather than directly checking: L(BM) L(B) =
We check:
L(
B
M
B) =
The Buchi version of Kripke M
We already discuss this! Execution over such an intersection is also called a “lock-step” execution.
40
Slide41IntersectionTwo buchi automata A and B over the same alphabetThe set of states are respectively SA and SB. starting at respectively s0A and s0B
.
Single accepting set, respectively
F
A
and
FB.FA is assumed to be SAA B can be thought as defining lock-step execution of both:The states : SA S
B
, starting at (
s0
A
,
s0
B
)
Can make a transition only if A and B can both make the corresponding transition.A single acceptance set F; (
s,t
) is accepting if
t
F
B
.
41
Slide42Constructing Intersection, example01
{
p
}
{
p
}
{
p,q
}
p
: isOdd
x
q
:
x
>0
B
M
:
B
<>
q
:
a
q
42
(0,a)
{
p
}
B
M
B
<>q
:
(1,a)
{
p
}
Slide43Verification Sufficient to have an algorithm to check if L(C) = , for the intersection-automaton C.
So, it comes down to a cycle finding in a finite graph! Solvable.
The path leading to such a cycle also acts as your counter example!
L(
C
)
iff
there is a finite path from
C
’s initial state to an accepting state
f
, followed by a cycle back to
f
.
43
Slide44ApproachesView C = BM B as a directed graph. Approach 1 :Calculate all strongly connected component (SCCs) of C (e.g. with Tarjan) .
Check if there is an SCC containing an accepting state, reachable from
C
’s initial state.
Approach 2, based on Depth First Search (DFS); can be made
lazy
:the full graph is constructed as-we-go, as you search for a cycle.Importantly, if M represents a parallel composition P1 || P2 || ... , this means that we can lazily construct B
M
.
44
Slide45DFS-approach (SPIN)DFS is a way to traverse a graph :
This will visit all reachable nodes. You can already use this to check “state assertions”.
DFS(
u
) {
if
(
u
visited
)
return
;
visited
.
add
(
u
) ;
for
(
s
next
(
u
)) DFS
(s)
;
}
45
Slide46Example012
3
46
4
Slide47Adding cycle detectionDFS(u) { if (u visited
)
return
;
visited
.add(u) ; for each (s
next
(
u
)) {
if (
u
accept
) {
visited2
= ;
checkCycle (u,s) ;
}
DFS(
s
)
;
}
}
47
Slide48checkCycle is another DFScheckCycle(root,s) { if (s = root) throw CycleFound ;
if
(
s
visited2 ) return ; visited2.add(
s
) ;
for
each
(
t
next(
s
))
checkCycle(root,
t
) ;
}
48
Can be extended to keep track of the path leading to the cycle
counter example.
See Lecture Notes.
Slide49Example012
3
checkCycle(1,2)
49
the node
currently
being
processed
root
Slide50Tweak: lazy model checkingRemember that automaton to explore is C = BM BIn particular, BM
can huge if
M
=
P
1
|| P2 || ...Can we construct C lazily?Benefit : if a cycle is found (verification fails), effort is not wasted to first construct the full
C.
Of course if
turns out to be valid, then C will in the end fully constructed.
How to deal with concrete states (rather than abstract states a la
Kripke
) ?
50
Slide51Lazily constructing the intersectionAssume first that P is just a single process.Only need to change this in the DFS : for each (s next
(
u
)) ….
if
(u accept)Each state of C is of type S
M
S
.
To check (
s
1
,
s
2
)
next
C
(
u
1
,u
2
), we check if there is a label
L
, such that:
s
1
next
M
(
u
1
,
L
) /\ s2
next(u2
,L))
(u
1,u2
)
accept
C
u
2
accept
51
“
next
” of the intersection automaton
C
=
B
M
B
Slide52Dealing with concrete states52Consider a concrete program Prg : var x = 0 , y = 0 ; repeat (x := x+1 mod 3)
⟨ x=0, y=0 ⟩
⟨ x=1, y=0 ⟩
⟨ x=2, y=0 ⟩
A concrete state of
Prg
is a vector ⟨
x,y
⟩
FSM
Prg
representing the program, in terms of concrete states:
Given a concrete state s and a predicate p, let
eval
(
p,s
) denote the value of p when evaluated on s (so it is either true or false).
So, to check if there is a successor of
s
such that a label
L
⊆
Prop
holds, we check instead, if there is an (atomic) transition 𝛼 in
Prg
such that for all
p
∈
L
,
eval
(
p
,𝛼(
s
)) is true, and for all
q∉L
,
eval
(q,𝛼(s)) is false.
x := x +1
x := x +1
x := x +1
adding a fake initial state
Slide53Dealing with concrete statesSo, if M is a program with concrete states, e.g. checking this in the DFS: (s1,s2) nextC(
u
1
,u
2
)
comes down to checking if there is an atomic transition 𝛼 of M and a label L
of
B
such that
s
2
next
(
u
2
,
L
)), and :
for all propositions
p∈
L
,
eval
(p, 𝛼(
u
1
)) = true
for all propositions
q∈Prop
/L,
eval
(q, 𝛼(
u
1
)) = false
53
Slide54What if M = P1 || P2 || ... ?We discussed the parallel composition of FSAs, e.g. : oo || oo
Note that here and represent actions.
Literally applying such parallel composition on
Buchi
automata makes less sense because the labels are properties rather than actions.
54
Slide55Example constructing P1 || P2 In the above example, we explicitly construct the concrete state FSM of P1 || P2 We can instead construct P1 || P2 lazily as we construct the intersection automaton with B
55
Consider a concrete program
Prg
=
P1 || P2 : var
x = 0 , y = 0 ;
P
1
:
repeat
(x := x+1
mod
3)P2 : (x≠2) ; y := 2
⟨ x=0, y=0 ⟩
⟨ x=1, y=0 ⟩
⟨ x=2, y=0 ⟩
⟨ x=0, y=0 ⟩
⟨ x=1, y=0 ⟩
⟨ x=2, y=0 ⟩
⟨ x=0, y=2 ⟩
⟨ x=1, y=2 ⟩
⟨ x=2, y=2 ⟩
⟨ x=0, y=0 ⟩
⟨ x=1, y=0 ⟩
P
1
:
P
2
:
P
1
||
P
2
⟨ x=1, y=2 ⟩
⟨ x=0, y=2 ⟩
Slide56What if M = P1 || P2 ?E.g. checking this in the DFS: (s1
,
s
2
)
next
C(u1,u2)
now comes down to checking if
there is an atomic transition 𝛼
of either
P
1
or
P
2
, and a label
L
of
B
such that
s
2
next
(
u
2
,
L
)), and :
for all propositions
p∈
L
,
eval
(p, 𝛼(
u
1)) = truefor all propositions q∈Prop
/L, eval(q, 𝛼(u1
)) = false
56
Slide57FairnessConsider this concurrent system :Is it possible that print
x
is ignored forever?
You may want to assume some concept of fairness. There are various possibilities. Importantly, it has to be reasonable.
Weak fairness
: any action that is persistently enabled will eventually be executed.
Strong fairness : any action that is kept recurrently enabled (but not necessarily persistently enabled) will eventually be executed.
Imposing fairness mean: when verifying
M
|==
, we only need to verify
wrt
fair executions of M.
A
fair execution
: an execution respecting the assumed fairness condition.
P
{
while
true
do
x:=(x+1)%3
}
Q
{ (
x
==0) ; print
x
}
||
57
execution blocks if false
Slide58Verifying properties under fairnessIf a fairness assumption can be expressed with some LTL formula F, we can instead verify M |== F → No need for a special algorithm!E.g. weak fairness on the red arrow:((pq)
(
p
q
))
Strong fairness on the blue arrow:((pq) (p
q
))
58
0
1
{ p }
{ p,q}
2
Slide59ConclusionWe can use FSAs to abstractly model concurrent programs.We can use LTL to express run-time properties: safety and progress.The model checking algorithm is thorough.Rather than FSAs with atomic predicates, you can imagine letting the FSAs to have concrete states.You can then model check real programs.The FSAs could be very large, but we can bound the input domains, and the depth of the search, bounded model checking.Combination with testing: to construct an execution so that M behaves as
, model-check this:
L(
B
M
B) = 59