model checking lecture 2 tom henzinger

Download Model Checking Lecture 2 Tom Henzinger

Post on 02-Jan-2016




1 download

Embed Size (px)


Model Checking Lecture 2 Tom Henzinger. Model-Checking Problem. I |= S. System model. System property. System model: State-transition graph. q1. a. b. a,b. q2. q3. StatesQ = { q1, q2, q3 } Atomic observations A = { a, b } Transition relation   Q  Q - PowerPoint PPT Presentation


  • Model CheckingLecture 2Tom Henzinger

  • Model-Checking ProblemI |= SSystem modelSystem property

  • aa,bbq1q3q2System model: State-transition graphStatesQ = { q1, q2, q3 }Atomic observations A = { a, b }Transition relation Q QObservation function[ ] : Q 2A

  • Run: sequence of states q1, q2Observation: set of atomic observationsTrace: sequence of observations {a}, {a,b}

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

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

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

  • 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

  • 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. modelsobservationsstate-transition graph (Kripke structure)

  • STL Syntax ::= a | | | | U boolean variable (atomic observation)boolean operatorsmodal operators

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

  • 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 q0, ..., qn s.t. 1. q = q0 q1 ... qn 2. for all 0 i < n, (K,qi) |= 3. (K,qn) |=

  • EX exists next = AX forall nextU EUexists until = true U EFexists eventually = AGforall always

    W = ( () U ( )) AW forall waiting-for (forall weak-until)Defined modalities

  • Important safety propertiesInvariance a

    Sequencing a W b W c W d = a W (b W (c W d))

  • Important safety properties: mutex protocolInvariance (in_cs1 in_cs2)

    Sequencing ( req_cs1 in_cs2 W in_cs2 W in_cs2 W in_cs1 )

  • Branching propertiesDeadlock freedom truePossibility (a b) (req_cs1 in_cs1)

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

  • CTL Syntax ::= a | | | | U |

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

  • 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) |=

  • EG exists always = AF forall eventually

    W = ( U ) ( ) U = ( W ) ()Defined modalities

  • Important liveness propertyResponse (a b)

    (req_cs1 in_cs1)

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

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

  • LTL Syntax ::= a | | | | U

  • LTL Modelinfinite trace t = t0 t1 t2 ...

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

  • LTL Semanticst |= aiff a t0t |= 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 ... |=

  • X nextU U until = true U Feventually = G always W = ( U ) W waiting-for (weak-until)Defined modalities

  • Important propertiesInvariance 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)

  • Composed modalities ainfinitely often a aalmost always a

  • Where did fairness go ?

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

  • Starvation freedom, corrected (in_cs2 out_cs2) (req_cs1 in_cs1)

  • CTL cannot express fairness a a b bbaaq0q1q2

  • LTL cannot express branchingPossibility (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.)

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

  • Specification AutomataSyntax, given a set A of atomic observations:Sfinite set of statesS0 Sset of initial states S S transition relation: S PL(A) where the formulas of PL are ::= a | | for a A

  • Language L(M) of specification automaton M = (S, S0, , ) :finite trace t0, ..., tn L(M) iffthere exists a finite run s0 s1 ... sn of Msuch that for all 0 i n, ti |= (si)

  • (K,q) |=L M iff L(K,q) L(M)

    Linear semantics of specification automata:language containmentstate-transition graphstate of Kspecification automaton finite traces

  • Invariance specification automaton in_cs1 in_cs2

  • Starvation freedom specification automatonout_cs1req_cs1in_cs2req_cs1in_cs2in_cs1req_cs1in_cs2

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

  • Checking language containment between finite automata is PSPACE-complete ! L(K,q) L(M) iffL(K,q) complement( L(M) ) = involves determinization (subset construction)

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

  • Monitor AutomataSyntax:same as specification automata, except also set E S of error statesSemantics: define L(M) s.t. runs must end in error states (K,q) |=C M iff L(K,q) L(M) =

  • Invariance monitor automaton in_cs1 in_cs2in_cs1 in_cs2

  • Starvation freedom monitor automatonout_cs1req_cs1in_cs2req_cs1in_cs2in_cs1req_cs1in_cs2req_cs1in_cs2

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

  • Main problem with deterministic specifications and monitor automata:not suitable for stepwise refinement / abstraction S1 |= S2 |= S3refines

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

  • (K,q) |=B M iffthere exists a simulation relation R Q S s.t. (q,s) R for some initial state s of MBranching semantics of specification automata:simulationstates of Kstates of M

  • R Q S is a simulation relationiff(q,s) R implies[q] |= (s)for all q s.t. q q , exists s s.t. s s and (q,s) R.[Milner 1974]

  • (K,q) |=L MM language contains (K,q) :exponential check

    (K,q) |=B MM simulates (K,q) :quadratic check Xinvolves only traces (hence linear !)involves states (hence branching !)

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

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

  • -specification vs. monitor automata-linear (language containment) vs. branching (simulation) semanticsWe discuss only the linear specification case.

  • Specification Omega-AutomataSyntax as for finite automata, in addition one of the following acceptance conditions: Buchi:BA ScoBuchi:CA S Streett:SA 2S 2SRabin:RA 2S 2S

  • Language L(M) of specification omega-automaton M = (S, S0, , , A ) :infinite trace t0, t1, ... L(M) iffthere exists an infinite run s0 s1 ... of Msuch that 1. s0 s1 ... satisfies A 2. for all i 0, ti |= (si)

  • Let Inf(s) = { p | p = si for infinitely many i }.The infinite run s satisfies the acceptance condition AiffBuchi:Inf(s) BA coBuchi:Inf(s) CAStreett:for all (l,r) SA, if Inf(s) l then Inf(s) r Rabin:for


View more >