Model Checking Lecture 2 Tom Henzinger

1. Model Checking Lecture 2 Tom Henzinger

2. Model-Checking Problem I |= S System model System property

3. System model: State-transition graph q1 a b a,b q2 q3 States Q = { q1, q2, q3 } Atomic observationsA = { a, b } Transition relation   Q  Q Observation function [ ] : Q  2A

4. Run: sequence of states q1, q2 Observation: set of atomic observations Trace: sequence of observations {a}, {a,b}

5. System property: 2x2x2 choices -safety (finite runs) vs. liveness (infinite runs) -linear time (traces) vs. branching time (runs) -logic (declarative) vs. automata (executable)

6. STL (Safe Temporal Logic) -safety (only finite runs) -branching (runs, not traces) -logic

7. Defining a logic • Syntax: • What are the formulas? • 2. Semantics: • What are the models? • Does model M satisfy formula  ? M |= 

8. Propositional logics: 1. boolean variables (a,b) & boolean operators (,) 2. model = truth-value assignment for variables Propositional modal (e.g. temporal) logics: 1. ... & modal operators (,) 2. model = set of (e.g. temporally) related prop. models

9. Propositional logics: 1. boolean variables (a,b) & boolean operators (,) 2. model = truth-value assignment for variables Propositional modal (e.g. temporal) logics: 1. ... & modal operators (,) 2. model = set of (e.g. temporally) related prop. models observations state-transition graph (“Kripke structure”)

10. STL Syntax  ::= a |    |   |   |  U  boolean operators boolean variable (atomic observation) modal operators

11. STL Model ( K, q ) state-transition graph state of K

12. STL Semantics (K,q) |= a iff a  [q] (K,q) |=    iff (K,q) |=  and (K,q) |=  (K,q) |=  iff not (K,q) |=  (K,q) |=   iff exists q’ s.t. q  q’ and (K,q’) |=  (K,q) |=  U  iff exist q0, ..., qn s.t. 1. q = q0  q1  ...  qn 2. for all 0  i < n, (K,qi) |=  3. (K,qn) |= 

13. Defined modalities •  EX exists next •   =  AX forall next • U EU exists until •   = true U  EF exists eventually •   =    AG forall always • W =  ( () U (  )) AW forall waiting-for (forall weak-until)

14. Important safety properties Invariance  a Sequencing a W b W c W d = a W (b W (c W d))

15. Important safety properties: mutex protocol Invariance   (in_cs1  in_cs2) Sequencing  ( req_cs1  in_cs2 W in_cs2 W in_cs2 W in_cs1 )

16. Branching properties Deadlock freedom   true Possibility  (a   b)  (req_cs1   in_cs1)

17. CTL (Computation Tree Logic) -safety & liveness -branching time -logic [Clarke & Emerson; Queille & Sifakis 1981]

18. CTL Syntax  ::= a |    |   |   |  U  | 

19. CTL Model ( K, q ) fair state-transition graph state of K

20. CTL Semantics (K,q) |=   iff exist q0, q1, ... s.t. 1. q = q0  q1  ... is an infinite fair run 2. for all i  0, (K,qi) |= 

21. Defined modalities •  EG exists always •   =  AF forall eventually • W = ( U )  ( ) • U  = ( W )  ()

22. Important liveness property Response  (a   b)  (req_cs1   in_cs1)

23. If only universial properties are of interest, why not omit the path quantifiers?

24. LTL (Linear Temporal Logic) -safety & liveness -linear time -logic [Pnueli 1977; Lichtenstein & Pnueli 1982]

25. LTL Syntax  ::= a |    |   |   |  U 

26. LTL Model infinite trace t = t0 t1 t2 ...

27. Language of deadlock-free state-transition graph K at state q : L(K,q) ... set of infinite traces of K starting at q (K,q) |=  iff for all t  L(K,q), t |=  (K,q) |=  iff exists t  L(K,q), t |= 

28. LTL Semantics t |= a iff a  t0 t |=    iff t |=  and t |=  t |=  iff not t |=  t |=   iff t1 t2 ... |=  t |=  U  iff exists n  0 s.t. 1. for all 0  i < n, ti ti+1 ... |=  2. tn tn+1 ... |= 

29. Defined modalities •  X next • U U until •   = true U  F eventually •   =    G always • W = ( U )   W waiting-for (weak-until)

30. Important properties Invariance  a   (in_cs1  in_cs2) Sequencing a W b W c W d  ( req_cs1  in_cs2 W in_cs2 W in_cs2 W in_cs1 ) Response  (a   b)  (req_cs1   in_cs1)

31. Composed modalities  a infinitely often a  a almost always a

32. Where did fairness go ?

33. Unlike in CTL, fairness can be expressed in LTL ! So there is no need for fairness in the model. Weak (Buchi) fairness :   (enabled   taken )  (enabled  taken) Strong (Streett) fairness : (  enabled )  (  taken )

34. Starvation freedom, corrected  (in_cs2  out_cs2)  (req_cs1   in_cs1)

35. CTL cannot express fairness  a    a  b    b q1 q0 q2 a a b

36. LTL cannot express branching Possibility  (a   b) So, LTL and CTL are incomparable. (There are branching logics that can express fairness, e.g. CTL* = CTL + LTL, but they lose the computational attractiveness of CTL.)

37. Finite Automata -safety (no infinite runs) -linear or branching time -automata (not logic)

38. Specification Automata Syntax, given a set A of atomic observations: • S finite set of states • S0 S set of initial states •  S  S transition relation • : S  PL(A) where the formulas of PL are  ::= a |    |   for a  A

39. Language L(M) of specification automaton M = (S, S0, ,  ) : finite trace t0, ..., tn L(M) iff there exists a finite run s0  s1  ...  sn of M such that for all 0  i  n, ti |= (si)

40. Linear semantics of specification automata: language containment (K,q) |=L M iff L(K,q)  L(M) state-transition graph state of K specification automaton finite traces

41. Invariance specification automaton • in_cs1  • in_cs2

42. Starvation freedom specification automaton req_cs1  in_cs2 req_cs1  in_cs2 out_cs1 req_cs1  in_cs2 in_cs1

43. Automata are more expressive than logic, because temporal logic cannot count : a true This cannot be expressed in LTL. (How about a   (a  a) ?)

44. Checking language containment between finite automata is PSPACE-complete ! L(K,q)  L(M) iff L(K,q)  complement( L(M) ) =  involves determinization (subset construction)

45. In practice: 1. require deterministic specification automata 2. use monitor automata 3. use branching semantics

46. Monitor Automata Syntax: same as specification automata, except also set E  S of error states Semantics: define L(M) s.t. runs must end in error states (K,q) |=C M iff L(K,q)  L(M) = 

47. Invariance monitor automaton • in_cs1  • in_cs2 in_cs1  in_cs2

48. Starvation freedom monitor automaton req_cs1  in_cs2 req_cs1  in_cs2 out_cs1 req_cs1  in_cs2 req_cs1  in_cs2 in_cs1

49. Specification automaton Monitor automaton M complement(M) -describe correct traces -describe error traces -check language containment -check emptiness (linear): (exponential) reachability of error states “All safety verification is reachability checking.”

50. Main problem with deterministic specifications and monitor automata: not suitable for stepwise refinement / abstraction S1 |= S2 |= S3 “refines”