Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Model Checking Lecture 2. Model-Checking Problem I |= S System modelSystem property."— Presentation transcript:

1 Model Checking Lecture 2

2 Model-Checking Problem I |= S System modelSystem property

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

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

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

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

7 Defining a logic 1.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 variable (atomic observation) boolean operators modal operators

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

12 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 ) |= 

13   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

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 Models = Kripke Structures

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

20 Computation Tree Logic, CTL Clarke & Emerson 1980 Syntax

21 CTL, Derived Operators... p pp AF p... p EF p possible inevitable ”exists eventually” or ”reachable” ”exists globally”

22 CTL, Derived Operators pp p... AG p pppp p p... EG p p always potentially always for all paths next ”forall globally” or ”invariantly” ”forall eventually”

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

24 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 ) |= 

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

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

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

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

29 LTL Syntax  ::= a |    |   |   |  U 

30 LTL Model infinite trace t = t 0 t 1 t 2...

31 (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

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

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

34 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)

35 Composed modalities  ainfinitely often a  aalmost always a

36 Where did fairness go ?

37 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 )

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

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

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

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

42 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

43 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 )

44 (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

45 Invariance specification automaton  in_cs1   in_cs2

46 Starvation freedom specification automaton out_cs1 req_cs1   in_cs2 req_cs1  in_cs2 in_cs1 req_cs1   in_cs2

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

48 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)

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

50 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) = 

51 Invariance monitor automaton  in_cs1   in_cs2 in_cs1  in_cs2

52 Starvation freedom monitor automaton out_cs1 req_cs1   in_cs2 req_cs1  in_cs2 in_cs1 req_cs1   in_cs2 req_cs1  in_cs2

53 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.”

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

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

56 (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

57 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]

58 (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 !)

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

60 Finite Omega-Automata -safety & liveness (infinite runs !) -linear or branching time -automata (not logic)

61 -specification vs. monitor automata -linear (language containment) vs. branching (simulation) semantics We discuss only the linear specification case.

62 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

63 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 )

64 Let Inf(s) = { p | p = s i for infinitely many i }. 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  

65 Buchi:  BA coBuchi:  CA Streett:  (  l   r) Rabin:  (   l   r)

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

67 Response specification automaton :  (a   b) assuming (a  b) = false a bb b aa s1s1 s2s2 s3s3 s0s0 Buchi condition { s 0, s 3 }

68 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 }) }

69 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 }) }

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

71 -Buchi and coBuchi automata cannot be determinized -Streett and Rabin automata can be determinized nondeterministic Buchi = deterministic Streett = deterministic Rabin = nondeterministic Streett = nondeterministic Rabin = omega-regular [Buchi 1960]

72 Omega-automaton determinization is even harder (conceptually, at least) than finite- automaton determinization [Safra 1989]. So monitor automata and simulation are particularly important.

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

74 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 

75 Structure of the omega-regular languages Streett = Rabin Buchi coBuchi FinitecoFinite

76 Structure of the counter-free omega-regular languages    positive boolean combinations of  and 

77 The location of a linear-time property in the Borel hierarchy indicates how hard (theoretically as well as conceptually) the corresponding model-checking problem is.

78    positive boolean combinations of  and  safety weak fair strong fair response


Download ppt "Model Checking Lecture 2. Model-Checking Problem I |= S System modelSystem property."

Similar presentations


Ads by Google