Four Lectures on Model Checking

1. Four Lectures on Model Checking Tom Henzinger University of California, Berkeley

2. Four Lectures on Model Checking: Lecture II 1 Eight model-checking problems: logic vs. automata, linear vs. branching, safety vs. liveness 2 Finite-state systems: six graph algorithms for model checking 3 Infinite-state systems: from graph algorithms to symbolic algorithms

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

4. Model-checking problem I|=S system model system property satisfaction relation

5. Important decisions when choosing a system model -variable-based vs. event-based -interleaving vs. true concurrency -synchronous vs. asynchronous interaction -clocked vs. speed-independent progress -etc.

6. Particular combinations of choices yield CSP Petri nets I/O automata Reactive modules Abstract state machines etc.

7. 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 fair state-transition graph.

8. The translation from a system description to a state-transition graph usually involves an exponential blow-up !!! e.g., n boolean variables  2n states This is called the “state-explosion problem.”

9. State-transition graph • Q set of states • A set of atomic observation •  Q  Q transition relation [ ]: Q  2A observation function

10. q1 a a,b b q2 q3 Run: q1 q3  q1  q3  q1  state sequence Trace:a  b  a  b  a  observation sequence

11. 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 

12. Two types of fairness 1 Weak (Buchi) fairness: an action cannot be enabled forever without being taken 2 Strong (Streett) fairness: an action cannot be enabled infinitely often without being taken

13. Weak fairness is sufficient for modeling progress in 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.

14. Finite runs: finRuns(S)  Q* Infinite runs: infRuns(S)  Q Finite traces: finTraces(S)  (2A)* Infinite traces: infTraces(S)  (2A)

15. Model-checking problem I|=S system model system property satisfaction relation

16. Three important decisions when choosing system properties: • operational vs. declarative: automata vs. logic • may vs. must: branching vs. linear time • prohibiting bad vs. desiring good behavior: safety vs. liveness

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

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

19. Safety: the properties that can be checked on finRuns Liveness: the properties that cannot be checked on finRuns

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

21. Two remarks 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.

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

23. Branching time: may properties Linear time: must properties One is rarely interested in may properties, but certain may properties are easy to model check, and they imply interesting must properties.

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

25. Linear time: the properties that can be checked on infTraces Branching time: the properties that cannot be checked on infTraces They need to be checked either on infRuns or on trace trees.

26. Linear Branching Safety finTraces finRuns Liveness infTraces infRuns

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

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

29. Logics Linear Branching Safety STL LivenessLTLCTL

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

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

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

33. 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) |= 

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

35. Example: mutex protocol Invariance   (pc1=in  pc2=in) Sequencing  ( pc1=req  (pc2in)W (pc2=in) W (pc2in) W (pc1=in)) Deadlock freedom   true

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

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

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

39. 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) |= 

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

41. Example: mutex protocol Response  (a   b)  (pc1=req   (pc1=in))

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

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

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

45. LTL Model infinite trace t = t0 t1 t2 ... (sequence of observations)

46. 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 |= 

47. 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 ... |= 

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

49. Summary of modalities STL     U W CTL all of the above and  W U LTL   U W

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