1. Lectures on Model Checking Stolen from lectures of Tom Henzinger - EE219C (CS294)

2. A specific model-checking problem is defined by I |= S “implementation” (system model) “specification” (system property) “satisfies”, “implements”, “refines” (satisfaction relation) more detailedmore abstract

3. Model-checking problem I |= S system modelsystem property satisfaction relation

4. While the choice of system model is important for ease of modeling in a given situation, the only thing that is important for model checking is that the system model can be translated into some form of state-transition graph.

5. State-transition graph Q set of states{q 1,q 2,q 3 } A set of atomic observations{a,b,c,d}   Q  Q transition relation q 1  q 2 [ ]: Q  2 A observation function [q 1 ] = {a, b} set of observations

6. a a,bb q1q1 q3q3 q2q2 State-transition graph

7. The translation from a system description to a state-transition graph usually involves an exponential blow-up !!! e.g., n boolean variables  2 n states “state-explosion problem.” State-transition graphs are not necessarily finite-state, but if not, they are not easy to deal with.

8. Model-checking problem I |= S system modelsystem property satisfaction relation

9. Three important decisions when choosing system properties: 1operational vs. declarative: automata vs. logic 2may vs. must: branching vs. linear time 3prohibiting bad vs. desiring good behavior: safety vs. liveness The three decisions are orthogonal, and they lead to substantially different model-checking problems.

10. Safety vs. liveness Safety: something “bad” will never happen Liveness: something “good” will happen (but we don’t know when)

11. Safety vs. liveness for state-transition graphs Safety: those properties whose violation always has a finite witness (“if something bad happens on an infinite run, then it happens already on some finite prefix”) Liveness: those properties whose violation never has a finite witness (“no matter what happens along a finite run, something good could still happen later”) We can have an infinite witness by a trace that has a loop

12. a a,bb q1q1 q3q3 q2q2 Run: q 1  q 3  q 1  q 3  q 1  q 2  q 2  Trace: a  b  a  b  a  a,b  a,b  Runs and Traces

13. State-transition graph S = ( Q, A, , [] ) Finite runs:finRuns(S)  Q * Infinite runs: infRuns(S)  Q  Finite traces:finTraces(S)  (2 A ) * Infinite traces: infTraces(S)  (2 A ) 

14. Safety: the properties that can be checked on finRuns Liveness: the properties that cannot be checked on finRuns This is much easier. (they need to be checked on infRuns)

15. Example: Mutual exclusion It cannot happen that both processes are in their critical sections simultaneously. Safety

16. Example: Bounded overtaking Whenever process P1 wants to enter the critical section, then process P2 gets to enter at most once before process P1 gets to enter. Safety

17. Example: Starvation freedom Whenever process P1 wants to enter the critical section, provided process P2 never stays in the critical section forever, P1 gets to enter eventually. Liveness

18. a a,bb q1q1 q3q3 q2q2 infRuns  finRuns

19. a a,bb q1q1 q3q3 q2q2 infRuns  finRuns  * closure * finite branching

20. For state-transition graphs, all properties are safety properties !

21. Example: Starvation freedom Whenever process P1 wants to enter the critical section, provided process P2 never stays in the critical section forever, P1 gets to enter eventually. Liveness

22. a a,bb q1q1 q3q3 q2q2 Fairness constraint: the green transition cannot be ignored forever

23. a a,bb q1q1 q3q3 q2q2 Without fairness: infRuns = q 1 (q 3 q 1 ) * q 2   (q 1 q 3 )  With fairness: infRuns = q 1 (q 3 q 1 ) * q 2 

24. Two important types of fairness 1 Weak (Buchi) fairness: a specified set of transitions cannot be enabled forever without being taken 2 Strong (Streett) fairness: a specified set of transitions cannot be enabled infinitely often without being taken

25. a a,bb q1 q3q2 Strong fairness

26. a a,b q1 q2 Weak fairness

27. Fair state-transition graph S = ( Q, A, , [], WF, SF) WF set of weakly fair actions SF set of strongly fair actions where each action is a subset of 

28. Weak fairness comes from modeling concurrency loop x:=0 end loop.loop x:=1 end loop. || x=0x=1 Weakly fair action

29. Strong fairness comes from modeling choice Strongly fair action loop m: n: x:=0 | x:=1 end loop. pc=n x=0 pc=n x=1 pc=m x=0 pc=m x=1

30. Weak fairness is sufficient for asynchronous models (“no process waits forever if it can move”). Strong fairness is necessary for modeling synchronous interaction (rendezvous). Strong fairness makes model checking more difficult.

31. Fairness changes only infRuns, not finRuns.  Fairness can be ignored for checking safety properties.

32. The vast majority of properties to be verified are safety. While nobody will ever observe the violation of a true liveness property, fairness is a useful abstraction that turns complicated safety into simple liveness. Two remarks

33. Three important decisions when choosing system properties: 1operational vs. declarative: automata vs. logic 2may vs. must: branching vs. linear time 3prohibiting bad vs. desiring good behavior: safety vs. liveness The three decisions are orthogonal, and they lead to substantially different model-checking problems.

34. Branching vs. linear time Branching time: something may (or may not) happen (e.g., every req may be followed by grant) Linear time: something must (or must not) happen (e.g., every req must be followed by grant)

35. One is rarely interested in may properties, but certain may properties are easy to model check, and they imply interesting must properties. (This is because unlike must properties, which refer only to observations, may properties can refer to states.)

36. Fair state-transition graph S = ( Q, A, , [], WF, SF ) Finite runs:finRuns(S)  Q * Infinite runs: infRuns(S)  Q  Finite traces:finTraces(S)  (2 A ) * Infinite traces: infTraces(S)  (2 A ) 

37. Linear time: the properties that can be checked on infTraces Branching time: the properties that cannot be checked on infTraces

38. LinearBranching Safety finTracesfinRuns LivenessinfTracesinfRuns

39. a a aa a bbcc Same traces {aab, aac} {aab, aac} Different runs {q 0 q 1 q 3, q 0 q 2 q 4 }, {q 0 q 1 q 3, q 0 q 1 q 4 } q0q0 q0q0 q2q2 q1q1 q1q1 q4q4 q4q4 q3q3 q3q3

40. Observation a may occur. || It is not the case that a must not occur. Linear

41. We may reach an a from which we must not reach a b. Branching

42. a a aa a bbcc Same traces, different runs q0q0 q0q0 q2q2 q1q1 q1q1 q4q4 q4q4 q3q3 q3q3

43. Linear time is conceptually simpler than branching time (words vs. trees). Branching time is often computationally more efficient. (Because branching-time algorithms can work with given states, whereas linear-time algorithms often need to “guess” sets of possible states.)

44. Three important decisions when choosing system properties: 1operational vs. declarative: automata vs. logic 2may vs. must: branching vs. linear time 3prohibiting bad vs. desiring good behavior: safety vs. liveness The three decisions are orthogonal, and they lead to substantially different model-checking problems.

45. LinearBranching Safety STL LivenessLTL CTL Logics LTL linear temporal logic STL safe temporal logic CTL computational tree logic mustmay finite infinite

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

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

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

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

50. STL Model ( K, q ) state-transition graph (Kripke structure) state of K

51. STL Semantics (K,q) |= aiff 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 q 0,..., q n s.t. 1. q = q 0  q 1 ...  q n 2. for all 0  i < n, (K,q i ) |=  3. (K,q n ) |= 

52.   EX exists next    =    AX forall next  U EUexists until    = true  U  EFexists eventually    =     AGforall always  W  =  ( (  )  U (    )) AW forall waiting-for (forall weak-until) Defined modalities

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

54. Important safety properties: mutex protocol Invariance    (pc1=in  pc2=in) Sequencing   ( pc1=req  (pc2  in)  W (pc2=in)  W (pc2  in)  W (pc1=in))

55. Branching properties Deadlock freedom     true Possibility   (a    b)   (pc1=req    (pc1=in))

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

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

58. CTL Model ( K, q ) fair state-transition graphstate of K

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

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

61. Important liveness property Response   (a    b)   (pc1=req    (pc1=in))

62. If only universal properties are of interest, why not omit the path quantifiers?

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

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

65. LTL Model infinite trace t = t 0 t 1 t 2... (sequence of observations)

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

67. LTL Semantics t |= aiff a  t 0 t |=    iff t |=  and t |=  t |=  iff not t |=  t |=   iff t 1 t 2... |=  t |=  U  iff exists n  0 s.t. 1. for all 0  i < n, t i t i+1... |=  2. t n t n+1... |= 

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

69. Summary of modalities STL          U  W CTLall of the above and      W  U LTL    U W

70. Important properties Invariance  asafety   (pc1=in  pc2=in) Sequencing a W b W c W dsafety  (pc1=req  (pc2  in) W (pc2=in) W (pc2  in) W (pc1=in)) Response  (a   b)liveness  (pc1=req   (pc1=in))

71. Composed modalities  ainfinitely often a  aalmost always a

72. Where did fairness go ?

73. 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 )

74. Starvation freedom, corrected  (pc2=in   (pc2=out))   (pc1=req   (pc1=in))

75. CTL cannot express fairness   a      a   b      b b aa q0q0 q1q1 q2q2

76. 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.)

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

78. Automata Safety:finite automata Liveness:omega automata Linear:language containment Branching:simulation relation

79. Automata Safety:finite automata Liveness:omega automata Linear:language containment for word automata Branching:language containment for tree automata

80. Specification Automata Syntax, given a set A of atomic observations: Sfinite set of states S 0  Sset of initial states   S  S transition relation  : S  PL(A) where the formulas of PL are  ::= a |    |   for a  A

81. Language L(M) of specification automaton M = (S, S 0, ,  ) : finite trace t 0,..., t n  L(M) iff there exists a finite run s 0  s 1 ...  s n of M such that for all 0  i  n, t i |=  (s i )

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

83. Invariance specification automaton pc1  in  pc2  in

84. One-bounded overtaking specification automaton pc1=out pc1=req  pc2  in pc1=req  pc2=in pc1=in pc1=req  pc2  in

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

86. 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)

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

88. 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) = 

89. Invariance monitor automaton pc1  in  pc2  in pc1 = in  pc2 = in ERROR

90. One-bounded overtaking monitor automaton pc1=out pc1=req  pc2  in pc1=req  pc2=in pc1=in pc1=req  pc2  in pc1=req  pc2=in ERROR

91. Specification automatonMonitor 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.”

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

93. (K,q) |= B M iff there exists a simulation relation R  Q  S s.t. (q,s)  R for some initial state s of M Branching semantics of specification automata: simulation states of K states of M AND

94. R  Q  S is a simulation relation iff (q,s)  R implies 1.[q] |=  (s) 2.for all q’ s.t. q  q’, exists s’ s.t. s  s’ and (q’,s’)  R. [Milner 1974]

95. a a cc bc q |= L bb true

96. a a cc bc q |= B bb true observations  (s) [q] |=  (s) and for all (q,s)  R, for all q’ s.t. q  q’, exists s’ s.t. s  s’ and (q’,s’)  R. ?

97. (K,q) |= L MM language contains (K,q) : exponential check (K,q) |= B MM simulates (K,q) : quadratic check   X involves only traces (hence linear !) involves states (hence branching !)

98. In practice, simulation is usually the “right” notion. (If there is language containment, but not simulation, this is usually accidental, not by design.)

99. -safety & liveness (infinite runs !) -specification vs. monitor automata -linear (language containment) vs. branching (simulation) semantics We discuss only the linear specification case. Omega Automata

100. Specification Omega Automata Syntax as for finite automata, in addition one of the following acceptance conditions: Buchi:BA  S coBuchi:CA  S Streett:SA  2 S  2 S Rabin:RA  2 S  2 S

101. Language L(M) of specification omega-automaton M = (S, S 0, , , A ) : infinite trace t 0, t 1,...  L(M) iff there exists an infinite run s 0  s 1 ... of M such that 1. s 0  s 1 ... satisfies A 2. for all i  0, t i |=  (s i )

102. Let Inf(s) = { p | p = s i for infinitely many i }. (set of states that occur infinitely often) The infinite run s satisfies the acceptance condition A iff Buchi:Inf(s)  BA   coBuchi:Inf(s)  CA Streett:for all (l,r)  SA, if Inf(s)  l   then Inf(s)  r   Rabin:for some (l,r)  RA, Inf(s)  l =  and Inf(s)  r  

103. finite:  FA Buchi:  BA coBuchi:  CA Streett:  (  l   r) Rabin:  (   l   r)

104. (K,q) |= L M iff L(K,q)  L(M) Linear semantics of specification omega automata: omega-language containment infinite traces

105. Response specification automaton :  (a   b) assuming (a  b) = false a bb b aa s1s1 s2s2 s3s3 s0s0 Here  (s) is  (s)= [(a  b) = false] Buchi condition { s 0, s 3 } Note: Buchi condition takes of fairness

106. Response monitor automaton :  (a   b) assuming (a  b) = false a bb s1s1 s2s2 Buchi condition { s 2 } s0s0 true

107. a aa s0s0 s1s1 Buchi condition { s 0 } No coBuchi condition  a Streett condition { ({s 0,s 1 }, {s 0 }) } Rabin condition { ( , {s 0 }) }

108. a aa s0s0 s1s1 No Buchi condition coBuchi condition { s 0 }  a Streett condition { ({s 1 },  ) } Rabin condition { ({s 1 }, {s 0,s 1 }) }

109. a aa s0s0 s1s1 Buchi condition { s 2 }  a a s2s2

110. -Buchi and coBuchi automata cannot be determinized (i.e. exists an ND Buchi with a language not given by any deterministic Buchi) -Streett and Rabin automata can be determinized (i.e. for every ND Streett, there is a deterministic Streett with the same language.) nondeterministic Buchi = deterministic Streett = deterministic Rabin = nondeterministic Streett = nondeterministic Rabin = omega-regular [Buchi 1960]

111. Omega automata are strictly more expressive than LTL. Omega-automata:omega-regular languages LTL: counter-free omega-regular languages 

112. Omega automata:omega-regular languages = second-order theory of monadic predicates & successor = omega-regular expressions LTL: counter-free omega-regular languages = first-order theory of monadic predicates & successor = star-free omega-regular expressions  Can convert an LTL formula into an omega (ND -Buchi) automaton using the “tableau” construction

113. Structure of the Omega-Regular Languages Streett = Rabin Buchi coBuchi FinitecoFinite what is coFinite

114. Structure of the Omega-Regular Languages Streett = Rabin Buchi coBuchi FinitecoFinite counter-free

115. Model-checking problem I |= S system model: state-transition graph system property: -safety v. weak v. strong fairness -logic v. spec v. monitor automata -linear v. branching

116. Model-checking problem I |= S system model: state-transition graph system property: -safety v. weak v. strong fairness -logic v. spec v. monitor automata -linear v. branching easiest harder hard

117. Model-Checking Algorithms = Graph Algorithms

118. 1Safety: -solve: STL (  U model checking), finite monitors (  emptiness) -algorithm: reachability (linear) 2Eventuality under weak fairness: -solve: weakly fair CTL (   model checking), Buchi monitors (  emptiness) -algorithm: strongly connected components (linear) 3Liveness: -solve: strongly fair CTL, Streett monitors (  (    ) emptiness) -algorithm: recursively nested SCCs (quadratic)

119. From specification automata to monitor automata: determinization (exponential) + complementation (easy) From LTL to monitor automata: complementation (easy) + tableau construction (exponential)