Model Checking Lecture 2 Tom Henzinger

Download Model Checking Lecture 2 Tom Henzinger

Post on 02-Jan-2016

29 views

Category:

Documents

1 download

Embed Size (px)

DESCRIPTION

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

TRANSCRIPT

<ul><li><p>Model CheckingLecture 2Tom Henzinger </p></li><li><p>Model-Checking ProblemI |= SSystem modelSystem property</p></li><li><p>aa,bbq1q3q2System model: State-transition graphStatesQ = { q1, q2, q3 }Atomic observations A = { a, b }Transition relation Q QObservation function[ ] : Q 2A</p></li><li><p>Run: sequence of states q1, q2Observation: set of atomic observationsTrace: sequence of observations {a}, {a,b}</p></li><li><p> -safety (finite runs) vs. liveness (infinite runs) -linear time (traces) vs. branching time (runs)-logic (declarative) vs. automata (executable)System property: 2x2x2 choices</p></li><li><p>STL (Safe Temporal Logic)-safety (only finite runs)-branching (runs, not traces)-logic</p></li><li><p>Defining a logicSyntax: What are the formulas?2. Semantics: What are the models? Does model M satisfy formula ?M |= </p></li><li><p>Propositional logics: 1. boolean variables (a,b) &amp; boolean operators (,) 2. model = truth-value assignment for variables</p><p>Propositional modal (e.g. temporal) logics: 1. ... &amp; modal operators (,) 2. model = set of (e.g. temporally) related prop. models</p></li><li><p>Propositional logics: 1. boolean variables (a,b) &amp; boolean operators (,) 2. model = truth-value assignment for variables</p><p>Propositional modal (e.g. temporal) logics: 1. ... &amp; modal operators (,) 2. model = set of (e.g. temporally) related prop. modelsobservationsstate-transition graph (Kripke structure)</p></li><li><p>STL Syntax ::= a | | | | U boolean variable (atomic observation)boolean operatorsmodal operators</p></li><li><p>STL Model( K, q )state-transition graph state of K</p></li><li><p>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 &lt; n, (K,qi) |= 3. (K,qn) |= </p></li><li><p> EX exists next = AX forall nextU EUexists until = true U EFexists eventually = AGforall always</p><p>W = ( () U ( )) AW forall waiting-for (forall weak-until)Defined modalities</p></li><li><p>Important safety propertiesInvariance a</p><p>Sequencing a W b W c W d = a W (b W (c W d))</p></li><li><p>Important safety properties: mutex protocolInvariance (in_cs1 in_cs2)</p><p>Sequencing ( req_cs1 in_cs2 W in_cs2 W in_cs2 W in_cs1 ) </p></li><li><p>Branching propertiesDeadlock freedom truePossibility (a b) (req_cs1 in_cs1)</p></li><li><p>CTL (Computation Tree Logic)-safety &amp; liveness-branching time-logic[Clarke &amp; Emerson; Queille &amp; Sifakis 1981]</p></li><li><p>CTL Syntax ::= a | | | | U | </p></li><li><p>CTL Model( K, q )fair state-transition graph state of K</p></li><li><p>CTL Semantics</p><p> (K,q) |= iff exist q0, q1, ... s.t. 1. q = q0 q1 ... is an infinite fair run 2. for all i 0, (K,qi) |= </p></li><li><p> EG exists always = AF forall eventually</p><p> W = ( U ) ( ) U = ( W ) ()Defined modalities</p></li><li><p>Important liveness propertyResponse (a b)</p><p> (req_cs1 in_cs1)</p></li><li><p>If only universial properties are of interest,why not omit the path quantifiers?</p></li><li><p>LTL (Linear Temporal Logic)-safety &amp; liveness-linear time-logic[Pnueli 1977; Lichtenstein &amp; Pnueli 1982]</p></li><li><p>LTL Syntax ::= a | | | | U </p></li><li><p>LTL Modelinfinite trace t = t0 t1 t2 ...</p></li><li><p>(K,q) |= iff for all t L(K,q), t |= (K,q) |= iff exists t L(K,q), t |= </p><p>Language of deadlock-free state-transition graph K at state q :L(K,q) ... set of infinite traces of K starting at q</p></li><li><p>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 &lt; n, ti ti+1 ... |= 2. tn tn+1 ... |= </p></li><li><p> X nextU U until = true U Feventually = G always W = ( U ) W waiting-for (weak-until)Defined modalities</p></li><li><p>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)</p></li><li><p>Composed modalities ainfinitely often a aalmost always a</p></li><li><p>Where did fairness go ?</p></li><li><p>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)</p><p>Strong (Streett) fairness :( enabled ) ( taken )</p></li><li><p>Starvation freedom, corrected (in_cs2 out_cs2) (req_cs1 in_cs1)</p></li><li><p>CTL cannot express fairness a a b bbaaq0q1q2</p></li><li><p>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.) </p></li><li><p>Finite Automata-safety (no infinite runs)-linear or branching time-automata (not logic)</p></li><li><p>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</p></li><li><p>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)</p></li><li><p>(K,q) |=L M iff L(K,q) L(M)</p><p>Linear semantics of specification automata:language containmentstate-transition graphstate of Kspecification automaton finite traces</p></li><li><p>Invariance specification automaton in_cs1 in_cs2</p></li><li><p>Starvation freedom specification automatonout_cs1req_cs1in_cs2req_cs1in_cs2in_cs1req_cs1in_cs2</p></li><li><p>Automata are more expressive than logic, because temporal logic cannot count :This cannot be expressed in LTL.(How about a (a a) ?)atrue</p></li><li><p>Checking language containment between finite automata is PSPACE-complete ! L(K,q) L(M) iffL(K,q) complement( L(M) ) = involves determinization (subset construction)</p></li><li><p>In practice: 1. require deterministic specification automata 2. use monitor automata 3. use branching semantics</p></li><li><p>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) = </p></li><li><p>Invariance monitor automaton in_cs1 in_cs2in_cs1 in_cs2</p></li><li><p>Starvation freedom monitor automatonout_cs1req_cs1in_cs2req_cs1in_cs2in_cs1req_cs1in_cs2req_cs1in_cs2</p></li><li><p>Specification automatonMonitor automaton</p><p> M complement(M)</p><p>-describe correct traces-describe error traces-check language containment-check emptiness (linear): (exponential) reachability of error states All safety verification is reachability checking.</p></li><li><p>Main problem with deterministic specifications and monitor automata:not suitable for stepwise refinement / abstraction S1 |= S2 |= S3refines</p></li><li><p>In practice: 1. require deterministic specification automata 2. use monitor automata 3. use branching semantics</p></li><li><p>(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</p></li><li><p>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]</p></li><li><p>(K,q) |=L MM language contains (K,q) :exponential check</p><p>(K,q) |=B MM simulates (K,q) :quadratic check Xinvolves only traces (hence linear !)involves states (hence branching !)</p></li><li><p>In practice, simulation is usually the right notion.(If there is language containment, but not simulation, this is usually accidental, not by design.)</p></li><li><p>Finite Omega-Automata-safety &amp; liveness (infinite runs !)-linear or branching time-automata (not logic)</p></li><li><p>-specification vs. monitor automata-linear (language containment) vs. branching (simulation) semanticsWe discuss only the linear specification case.</p></li><li><p>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</p></li><li><p>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)</p></li><li><p>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 some (l,r) RA, Inf(s) l = and Inf(s) r </p></li><li><p>Buchi: BAcoBuchi: CAStreett: (l r)Rabin: (l r)</p></li><li><p>(K,q) |=L M iff L(K,q) L(M)</p><p>Linear semantics of specification omega-automata:omega-language containmentinfinite traces</p></li><li><p>Response specification automaton : (a b) assuming (a b) = falseabbas1s2s3s0Buchi condition { s0, s3 }</p></li><li><p>aas0s1Buchi condition { s0 }No coBuchi condition aStreett condition { ({s0,s1}, {s0}) }Rabin condition { (,{s0}) }</p></li><li><p>aas0s1No Buchi conditioncoBuchi condition { s0 } aStreett condition { ({s1}, ) }Rabin condition { ({s1}, {s0,s1}) }</p></li><li><p>aas0s1Buchi condition { s2 } aas2</p></li><li><p>-Buchi and coBuchi automata cannot be determinized-Streett and Rabin automata can be determinizednondeterministic Buchi =deterministic Streett = deterministic Rabin =nondeterministic Streett = nondeterministic Rabin =omega-regular [Buchi 1960]</p></li><li><p>Omega-automaton determinization is even harder (conceptually, at least) than finite-automaton determinization [Safra 1989].</p><p>So monitor automata and simulation are particularly important.</p></li><li><p>Omega-automata are strictly more expressive than LTLOmega-automata:omega-regular languages</p><p>LTL: counter-free omega-regular languages</p></li><li><p>Omega-automata:omega-regular languages = second-order theory of monadic predicates &amp; successor = omega-regular expressions </p><p>LTL: counter-free omega-regular languages = first-order theory of monadic predicates &amp; successor = star-free omega-regular expressions </p></li><li><p>Structure of the omega-regular languagesStreett = Rabin BuchicoBuchiFinitecoFinite</p></li><li><p>Structure of the counter-free omega-regular languagespositive boolean combinations of and </p></li><li><p>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. </p></li><li><p>positive boolean combinations of and safetyweak fairstrong fairresponse</p></li></ul>