Wishnu Prasetya [email protected] www.cs.uu.nl/docs/vakken/pv LTL
Model Checking
Slide 2
Overview This pack : Abstract model of programs Temporal
properties Verification (via model checking) algorithm Concurrency
2
Slide 3
Finite State Automaton/Machine Abstraction of a real program
Choices What 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. Additionally: 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. 3 0 0 1
1
Slide 4
FSA Described by (S, I, , R) S : the set of possible states I S
: set of possible initial states : set of labels, to decorate the
arrows. They model possible actions. R : S pow(S), the arrows
R(s,a) is the set of possible next-states of a if executed on s
non-deterministic 4
Slide 5
Program compositions can be modeled by operations over FSA M 1
; M 2 connect terminal states of M 1 to M 2 s initial states. M 1
|| M 2 Parallel composition M 1 M 2 Only do executions that are
possible in both 5
Slide 6
Example Actions are atomic; M 1 and M 2 has no common action.
Their parallel composition is basically the full product over the
component automata. To note: if each component has n number of
states, constructing || over k components explode to n k states. 6
0 0 1 1 0 0 1 1 a b c
Slide 7
Parallel composition with synchronized actions Any action a 1 2
has to be executed together by both automata. 7 0 0 1 1 0 0 1 1 a a
c
Slide 8
Intersection Not something you do in real programs A useful
concept for verification later. 8 0 0 1 1 0 0 1 1 a a (0,0) (1,1) a
c
Slide 9
Kripke Structure A finite automaton ( S, s 0, R, Prop, V ) S :
the set of possible states, with s 0 the initial state. R : S
pow(S), the arrows R(s) is the set of possible next-states from s
non-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. 9
Slide 10
Prop It consists of atomic propositions. Well require them to
be non-contradictive. That is, for any subset Q of Prop : (/\Q) /\
(/\{ p | 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. 10
Slide 11
Example 11 With Prop = { isOdd x, x>0 } V(0) = { isOdd x } V
(1) = { isOdd x, x>0 } So, which properties hold in state 0? 0 0
1 1
Slide 12
Execution An execution is a path through your automaton. Lets
focus on properties of infinite executions All executions are
assumed infinite Extend 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. Well often use
the term execution and abstract execution interchangbly. 12
Run-time properties Hoare triple : express what should hold
when the program terminates. Many programs are supposed to work
continuously They should be safe They should not dead lock No
process should starve Linear 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 Brought to
Computer Science by Pnueli, 1977. 14
Slide 15
Informal meaning 15 f // always f X f // next f f U g // f
holds until g f f f f f f f f f f g f
Slide 16
Quite expressive ( p (true U q )) // whenever p holds,
eventually q will hold p U ( q U r) true U p // eventually
stabilizing to p true U p // eventually p will hold infinitely many
often 16
Slide 17
Syntax ::= p // atomic proposition from Prop | | /\ | X | U
Derived operators: \/ = ( /\ ) = \/ , , W, Interpreted over
abstract executions. 17
Slide 18
Defining the meaning of temporal formulas First well 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 abs. executions of P 18
Slide 19
Meaning Let be an (abstract) execution. ,i |== p= p (i)// p
Prop ,i |== = not ( ,i |== ) ,i |== /\ = ,i |== and ,i |== 19
Slide 20
Meaning ,i |== X = ,i+1 |== ,i |== U = there is a j i such that
,j |== and for all h, i h
Example 21 Consider : {isOdd x}, {isOdd x}, {isOdd x, x>0},
{isOdd x, x>0},... |== isOdd x U x>0 Is this a valid property
of the FSA? 0 0 1 1 { isOdd x } { isOdd x, x>0 }
Slide 22
Derived operators Eventualy = true U Always = Weak until W = \/
( U ) Release R = W ( /\ ) 22
Slide 23
Some derived operators 23 f // eventually f f W g // weak until
g R f // releases f f g,f ff f f f f g f f f f f f ffffff
Slide 24
Past operators Useful, 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 = held in the
past, and since that to now holds Unfortunately, not supported by
SPIN. 24
Slide 25
Ok, so how can I verify M |== ? We cant directly check all
executions infinite (in two dimensions). Try to prove it directly
using the definitions? Well take a look another strategy First,
lets 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
Slide 26
Representing 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
Slide 27
Re-express as a language problem Well, M |== iff There 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
Slide 28
Automaton 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 q1q1 q2q2 a
b
Slide 29
Buchi Automaton abab not an infinite ababab accepted abbbb not
accepted! Pass an acceptance state infinitely many times. Examples
29 a b q1q1 q2q2 a b
Slide 30
Expressing temporal formulas as Buchi Well take Prop = { p }
{p}{p} {p}{p} Use pow(Prop) as the alphabet of arrow-labels.
Example: Xp ( = X p) Indirectly saying that p is false. We can drop
this, since we only need to (fully) cover accepted sentences.
{p}{p} 30
Slide 31
To make the drawing less verbose... 31 Xp, using Prop = {p} * *
Xp, using Prop = {p,q} * * pp 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. pp So we
have 4 subsets. pp
Slide 32
Always and Eventually 32 p pp * * []p pp []p pp pp *
Slide 33
Until 33 p U q : pp * qq p U Xq : pp * qq *
Slide 34
Not Until 34 Formula: ( p U q ) p,q * pqpq 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
Slide 35
Generalized Buchi Automaton 35 []p /\ []q 0 2 pp qq * 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.
Slide 36
Difficult cases How 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
Slide 37
Check list 1.How to construct B ? Buchi 2.We still have a
mismatch, because M is a Kripke structure! Fortunately, we can
easily convert it to a Buchi. 3.We still have to construct the
intersection. 4.We still to figure out a way to check emptiness. M
|== iff L(M) L(B ) = 37
Slide 38
Label on state or label on arrow... 38 a a b b c c a b c b c b
b d d e e d e c c generate the same sentences
Slide 39
Converting Kripke to Buchi 39 0 1 { isOdd x } { isOdd x, x>0
} z { isOdd x } { isOdd x, x>0 } Generate the same inf.
sentences! Single accepting set F, containing all states. 0 0 1 1 {
isOdd x } { isOdd x, x>0 }
Slide 40
Computing intersection Rather than directly checking: L(B M )
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
Slide 41
Intersection Two buchi automata A and B over the same alphabet
The set of states are respectively S A and S B. starting at
respectively s0 A and s0 B. Single accepting set, respectively F A
and F B. F A is assumed to be S A A B can be thought as defining
lock-step execution of both: The states : S A 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
Slide 42
Constructing Intersection, example 0 1 { p } { p,q } p : isOdd
x q : x>0 AP:AP: A q : a qq 42 (0,a) { p } A p A q : (1,a) { p
}
Slide 43
Verification 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 Cs initial state to an accepting state f, followed by a
cycle back to f. 43
Slide 44
Approaches View C = A P A as a directed graph. Approach 1 :
1.Calculate all strongly connected component (SCCs) of C (e.g. with
Tarjan). 2.Check if there is an SCC containing an accepting state,
reachable from Cs 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. If M = M 1 || M 2 ||..., this
means that we can lazily construct M. 44
Slide 45
DFS-approach (SPIN) DFS is a way to traverse a graph : This
will visit all reachable nodes. You can already use this to check
assertions. DFS(u) { if (u visited) return ; visited.add(u) ; for
(s next(u)) DFS(s) ; } 45
Slide 46
Example 0 1 2 3 46 4 4
Slide 47
Adding cycle detection DFS(u) { if (u visited) return ;
visited.add(u) ; for each (s next(u)) { if (u accept) { visited2 =
; checkCycle (u,s) ; } DFS(s ) ; } 47
Slide 48
checkCycle is another DFS checkCycle(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.
Slide 49
Example 0 1 2 3 checkCycle(1,2) 49 the node currently being
processed root
Slide 50
Tweak: lazy model checking Remember that automaton to explore
is C = B M B In particular, B M can huge if M = M 1 || M 2 ||...
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. Question: dont we get this for free in e.g.
Haskell? 50
Slide 51
Lazily constructing the intersection Assume first that M is
just a single process. Only need to change this : for each (s
next(u)) . if (u accept) Each state of C is of type S M S . (s 1,s
2 ) next C (u 1,u 2 ) ( lab:: s 1 next M (u 1,lab) /\ s 2 next (u
2,lab)) (u 1,u 2 ) accept C u 2 accept 51
Slide 52
Dealing with concrete states A concrete state: a vector of
values of prog. variables Recall: (s 1,s 2 ) next C (u 1,u 2 ) (
lab:: s 1 next M (u 1,lab) /\ s 2 next (u 2,lab)) Suppose u 1 is a
concrete state, it means we are checking: if there is an (atomic)
action of M that can be executed on u 1 leading to s 1 and all
propositions in lab hold in u 1 52
Slide 53
What if M = M 1 || M 2 ||... ? Parallel composition was define
over structures like this: o o || o o Parallel composition of
Kripke structures or Buchis as we defined them does not really
making sense. E.g., what does this mean? {p} {p} || {q} 53
Slide 54
What if M = M 1 || M 2 ||... ? Recall: (s 1,s 2 ) next C (u 1,u
2 ) ( lab:: s 1 next M (u 1,lab) /\ s 2 next (u 2,lab)) Suppose u 1
is a concrete state of M 1 || M 2 ||... Check: if there is an
atomic action of some M k that can be executed on u 1 leading to s
1 and all propositions in lab hold in u 1 54
Slide 55
Fairness Consider this concurrent system : Is it possible that
print x is ignored forever? We may want to assume some concept of
fairness; you can think of some 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 } ||
55 execution blocks if false
Slide 56
Verifying properties under fairness We dont have anything in
the FSA itself to express fairness. But we can express it with LTL.
E.g. weak fairness on the red arrows: ((p q) (p q)) ((p q) (p q))
Strong fairness on the blue arrow: ( (p q) ( p q)) To verify a
given property , we now verify fair , where fair is the LTL
expressing your fairness assumption. 56 0 0 1 1 { p } { p,q} 2
2
Slide 57
Conclusion We 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 ) = 57