LTL Model Checking (Ch. 4 LN)

1. LTL Model Checking(Ch. 4 LN) WishnuPrasetya wishnu@cs.uu.nl www.cs.uu.nl/docs/vakken/pv

2. Overview • This pack : • Abstract model of programs • Temporal properties • Verification (via model checking) algorithm • Concurrency

3. 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” • Belong to the class of modal logics • Brought to Computer Science by Pnueli, 1977.

4. 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. • 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. 0 1

5. 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

6. Program compositions can be modeled by operations over FSA • We assume actions to be atomic. • M1 ; M2 • connect “terminal states” of M1 to M2’s initial states. • M1M2 • only do executions that are possible in both • M1 || M2 • model parallel execution of M1 and M2

7. Intersection c • Not something you typically do in real programs • A useful concept for verification  later. (0,0) 0 0  a a a (1,1) 1 1

8. Parallel composition c • Suppose 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 nkstates. 0 0 || a b 1 1

9. Parallel composition with synchronized actions c • Suppose we require that any action a  1  2 has to be executed together (synchronizedly) by both automata. 0 0 a a 1 1

10. Let’saddlabels Consider these set of “labels”, Prop = { isOdd x, x>0 }. The labeling is describebythisfunction 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.

11. Kripke Structure • A finite automaton ( S, s0, R, Prop, V ) • S : the set of possible states, with s0 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.

12. Prop • It 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.

13. Execution • An execution is a path through your automaton. • Let’s 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. • We’ll often use the term execution and abstract execution interchangbly.

14. Example 0 { isOdd x } { isOdd x, x>0 } 1 Exec. : 0 0 1 1 ... Abs-exec: {isOdd x} , {isOdd x}, {isOdd x, x>0}, {isOdd x, x>0} , ...

15. g f f f f g f f f f f f LTL, informalmeaning f // always f Xg// next f fUg// f holds until g

16. You can combine operators • ( p (true Uq )) // whenever p holds, eventually q will hold • pU ( qUr) • true U p// eventually stabilizing to p • true U p// eventually p will hold infinitely many often

17. Syntax •  ::= p// atomic proposition from Prop |  |  /\  | X |  U  • Derived operators: •  \/  =  (  /\ ) •    =  \/  •  ,  , W , … • Interpreted over abstract executions.

18. Defining the meaning of temporal formulas • First we’lldefinethemeaningwrtto a single abstract execution. Let  besuchanexecution: • ,i |==  •  |==  = ,0 |==  • IfP is a Kripkestructure,P |==  means that  holds on all abstract executions of P

19. Meaning • Let  be an (abstract) execution. • ,i |== p = p  (i) // p  Prop • ,i |==  = not (,i |== ) • ,i |== /\ = ,i |==  and ,i |== 

20. Meaning • ,i |== X = ,i+1 |==  • ,i |==  U  = there is a jisuchthat ,j |== andforallh, ih<j, we have ,h |== .

21. Example 0 { isOdd x } { isOdd x, x>0 } 1 Consider  : {isOdd x} , {isOdd x}, {isOdd x, x>0}, {isOdd x, x>0} , ... • |== isOdd xUx>0 • Is this a valid property of the FSA?

22. Derived operators • Eventualy  = true U  • Always  =  • Weak until  W  =  \/ ( U ) • Release  R  =  W ( /\ )

23. f f f f g f f f f f f f f f f f f f f f f g,f Some derived operators <> f// eventually f fWg// weak until gRf// releases

24. Past operators • Useful, e.g. to say: if P is doingsomethingwithx, thenit must have asked a permissionto do so. • “previous”,i |== Y =  holds in theprevious state • “since” ,i |==  S  = ,j |==  forsome j  i, andforall j<k  i we have ,j |==  • Unfortunately, notsupportedby SPIN.

25. Ok, 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)

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) = {  |  |==  }

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) = 

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 ...? a q1 a b q2 b

29. Buchi Automaton “ababa”  not an infinite “ababab…”  accepted “abbbb…”  not accepted! • Pass an acceptance state infinitely many times. • Examples a q1 a b q2 b

30. Expressing temporal formulas as Buchi Use pow(Prop) as the alphabet  of arrow-labels. Example: Xp ( = Xp) We’ll take Prop = { p } Indirectly saying that p is false.  {p}  {p}  {p} We can drop this, since we only need to (fully) cover accepted sentences.

31. To make the drawing less verbose... Xp, using Prop = {p}  * * So we have 4 subsets. Stands for all subsets of Prop that do not contain p; thus implying “p does not hold”. Xp, using Prop = {p,q} p p * * Stands for all subsets of Prop that contain p; thus implying “p holds”. p

32. Always and Eventually p []p p <>p * * p <>[]p * p

33. Until pUq : q * p q pUXq : * * p

34. Not Until Formula:  ( p Uq ) Note first these properties: (pUq) = p /\ qW p /\ q (pWq) = p /\ qU p /\ q(also generally when p,qare LTL formulas) = qW p /\ q = qU p /\ q p,q pq *

35. Generalized Buchi Automaton []<>p /\ []<>q p q 2 0 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.

36. Difficult cases • How about nested formulas like: (Xp) U q ( pUq ) UrTheir 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.

37. Check list • How 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) = 

38. Label on state or label on arrow... a a b c generate the same sentences b c b c c b d e generate the same sentences d e

39. Converting Kripke to Buchi 0 { isOdd x } Single accepting set F, containing all states. { isOdd x, x>0 } z 1 { isOdd x } { isOdd x } 0 { isOdd x, x>0 } Generatethesame (infinite) sentences! 1 { isOdd x, x>0 }

40. Computing intersection The Buchi version of Kripke M  • Rather than directly checking: L(BM)  L(B) = We check:L(BM B) =  We already discuss this! Execution over such an intersection is also called a “lock-step” execution.

41. Intersection • Two buchi automata A and Bover the same alphabet • The set of states are respectively SA and SB. • starting at respectively s0A and s0B. • Single accepting set, respectively FA and FB. • FA is assumed to be SA • A  B can be thought as defining lock-step execution of both: • The states : SA  SB, starting at (s0A,s0B) • 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  FB.

42. Constructing Intersection, example p : isOdd xq : x>0 BM: { p,q } { p } 0 1 { p } BM B<>q : B<>q: q a (1,a) (0,a) { p } { p }

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 C’s initial state to an accepting state f , followed by a cycle back to f .

44. Approaches • View 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 BM.

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 “state assertions”. DFS(u) { if (u visited) return ; visited.add(u) ; for (snext(u)) DFS(s) ; }

46. Example 0 4 1 2 3

47. Adding cycle detection DFS(u) {if (u visited) return ; visited.add(u) ; foreach (snext(u)) { if (u  accept) {visited2 =  ;checkCycle (u,s) ;} DFS(s) ; } }

48. checkCycle is another DFS checkCycle(root,s) { if (s = root) throw CycleFound ; if ( s visited2 ) return ; visited2.add(s) ; foreach (tnext(s)) checkCycle(root, t) ; } Can be extended to keep track of the path leading to the cycle  counter example. See Lecture Notes.

49. Example 0 1 2 3 checkCycle(1,2) the node currentlybeingprocessed root

50. Tweak: lazy model checking • Remember that automaton to explore is C = BM B • In particular, BM can huge if M = P1 || 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) ?