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

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

Post on 05-Jan-2016

212 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

<ul><li><p>Lectures on Model CheckingStolen from lectures of Tom Henzinger - EE219C (CS294)</p></li><li><p>A specific model-checking problem is defined by I |= Simplementation (system model)specification (system property)satisfies, implements, refines (satisfaction relation)more detailedmore abstract</p></li><li><p>Model-checking problemI |= Ssystem modelsystem propertysatisfaction relation</p></li><li><p>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.</p></li><li><p>State-transition graphQ set of states{q1,q2,q3}A set of atomic observations{a,b,c,d} Q Q transition relation q1 q2[ ]: Q 2A observation function [q1] = {a, b}</p><p>set of observations</p></li><li><p>aa,bbq1q3q2State-transition graph</p></li><li><p>The translation from a system description to a state-transition graph usually involves an exponential blow-up !!!e.g., n boolean variables 2n statesstate-explosion problem.State-transition graphs are not necessarily finite-state, but if not, they are not easy to deal with.</p></li><li><p>Model-checking problemI |= Ssystem modelsystem propertysatisfaction relation</p></li><li><p>Three important decisions when choosing system properties:operational vs. declarative: automata vs. logicmay vs. must: branching vs. linear timeprohibiting bad vs. desiring good behavior: safety vs. livenessThe three decisions are orthogonal, and they lead to substantially different model-checking problems. </p></li><li><p>Safety vs. livenessSafety: something bad will never happenLiveness: something good will happen (but we dont know when)</p></li><li><p>Safety vs. liveness for state-transition graphsSafety: 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</p></li><li><p>aa,bbq1q3q2Run: q1 q3 q1 q3 q1 q2 q2 Trace: a b a b a a,b a,b </p><p>Runs and Traces</p></li><li><p>State-transition graph S = ( Q, A, , [] )Finite runs:finRuns(S) Q*Infinite runs: infRuns(S) Q</p><p>Finite traces:finTraces(S) (2A)*Infinite traces: infTraces(S) (2A)</p></li><li><p>Safety: the properties that can be checked on finRunsLiveness: the properties that cannot be checked on finRuns (they need to be checked on infRuns)</p></li><li><p>Example: Mutual exclusionIt cannot happen that both processes are in their critical sections simultaneously.Safety</p></li><li><p>Example: Bounded overtakingWhenever process P1 wants to enter the critical section, then process P2 gets to enter at most once before process P1 gets to enter.Safety</p></li><li><p>Example: Starvation freedomWhenever process P1 wants to enter the critical section, provided process P2 never stays in the critical section forever, P1 gets to enter eventually.Liveness</p></li><li><p>aa,bbq1q3q2infRuns finRuns</p></li><li><p>aa,bbq1q3q2infRuns finRuns* closure *finite branching</p></li><li><p>For state-transition graphs, all properties are safety properties !</p></li><li><p>Example: Starvation freedomWhenever process P1 wants to enter the critical section, provided process P2 never stays in the critical section forever, P1 gets to enter eventually.Liveness</p></li><li><p>aa,bbq1q3q2Fairness constraint:the green transition cannot be ignored forever</p></li><li><p>aa,bbq1q3q2Without fairness: infRuns = q1 (q3 q1)* q2 (q1 q3)With fairness: infRuns = q1 (q3 q1)* q2</p></li><li><p>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 </p></li><li><p>aa,bbq1q3q2Strong fairness</p></li><li><p>aa,bq1q2Weak fairness</p></li><li><p>Fair state-transition graph S = ( Q, A, , [], WF, SF)WF set of weakly fair actionsSF set of strongly fair actions</p><p>where each action is a subset of </p></li><li><p>Weak fairness comes from modeling concurrencyloop x:=0 end loop.loop x:=1 end loop.||x=0x=1Weakly fair action Weakly fair action</p></li><li><p>Strong fairness comes from modeling choiceStrongly fair action Strongly fair actionloop m: n: x:=0 | x:=1 end loop.pc=n x=0pc=n x=1pc=m x=0pc=m x=1</p></li><li><p>Weak fairness is sufficient for asynchronous models (no process waits forever if it can move). </p><p>Strong fairness is necessary for modeling synchronous interaction (rendezvous).Strong fairness makes model checking more difficult. </p></li><li><p>Fairness changes only infRuns, not finRuns.Fairness can be ignored for checking safety properties.</p></li><li><p>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</p></li><li><p>Three important decisions when choosing system properties:operational vs. declarative: automata vs. logicmay vs. must: branching vs. linear timeprohibiting bad vs. desiring good behavior: safety vs. livenessThe three decisions are orthogonal, and they lead to substantially different model-checking problems. </p></li><li><p>Branching vs. linear timeBranching 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) </p></li><li><p>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.)</p></li><li><p>Fair state-transition graph S = ( Q, A, , [], WF, SF )Finite runs:finRuns(S) Q*Infinite runs: infRuns(S) Q</p><p>Finite traces:finTraces(S) (2A)*Infinite traces: infTraces(S) (2A)</p></li><li><p>Linear time: the properties that can be checked on infTracesBranching time: the properties that cannot be checked on infTraces</p></li><li><p>LinearBranchingSafety finTracesfinRunsLivenessinfTracesinfRuns</p></li><li><p>aaaaabbccSame traces {aab, aac} {aab, aac} Different runs {q0 q1 q3, q0 q2 q4}, {q0 q1 q3, q0 q1 q4}q0q0q2q1q1q4q4q3q3</p></li><li><p>Observation a may occur.||It is not the case that a must not occur. Linear</p></li><li><p>We may reach an a from which we must not reach a b .Branching</p></li><li><p>aaaaabbccSame traces, different runs q0q0q2q1q1q4q4q3q3</p></li><li><p>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.)</p></li><li><p>Three important decisions when choosing system properties:operational vs. declarative: automata vs. logicmay vs. must: branching vs. linear timeprohibiting bad vs. desiring good behavior: safety vs. livenessThe three decisions are orthogonal, and they lead to substantially different model-checking problems. </p></li><li><p>LinearBranchingSafety STLLivenessLTL CTLLogicsLTL linear temporal logicSTL safe temporal logicCTL computational tree logicmustmayfiniteinfinite</p></li><li><p>STL (Safe Temporal Logic)-safety (only finite runs)-branching (runs, not traces)</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 (PL): 1. boolean variables (a,b) &amp; boolean operators (,) 2. model = truth-value assignment for variables</p><p>Propositional modal (e.g., temporal) logics: 1. PL + modal operators (,) 2. model = set of (e.g., temporally) related prop. modelsobservationsstate-transition graph (Kripke structure)atomic observations</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 (Kripke structure) 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 (pc1=in pc2=in)</p><p>Sequencing ( pc1=req (pc2in) W (pc2=in) W (pc2in) W (pc1=in)) </p></li><li><p>Branching propertiesDeadlock freedom truePossibility (a b) (pc1=req (pc1=in))</p></li><li><p>CTL (Computation Tree Logic)-safety &amp; liveness-branching time[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> (pc1=req (pc1=in))</p></li><li><p>If only universal properties are of interest,why not omit the path quantifiers?</p></li><li><p>LTL (Linear Temporal Logic)-safety &amp; liveness-linear time[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 ... (sequence of observations)</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>Summary of modalitiesSTL U WCTLall of the above and W ULTL U W </p></li><li><p>Important propertiesInvariance asafety (pc1=in pc2=in)</p><p>Sequencing a W b W c W dsafety (pc1=req (pc2in) W (pc2=in) W (pc2in) W (pc1=in))</p><p>Response (a b)liveness (pc1=req (pc1=in))</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 (pc2=in (pc2=out)) (pc1=req (pc1=in))</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> -safety (finite runs) vs. liveness (infinite runs) -linear time (traces) vs. branching time (runs)-logic (declarative) vs. automata (operational)System property: 2x2x2 choices</p></li><li><p>AutomataSafety:finite automataLiveness:omega automataLinear:language containment Branching:simulation relation</p></li><li><p>AutomataSafety:finite automataLiveness:omega automataLinear:language containment for word automataBranching:language containment for tree automata</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 pc1 in pc2 in</p></li><li><p>One-bounded overtaking specification automatonpc1=outpc1=req pc2inpc1=req pc2=inpc1=inpc1=reqpc2in</p></li><li><p>Automata are more expressive than logic (LTL), because temporal logic cannot count :This cannot be expressed in LTL.atrue(How about a (a a) ?)</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 automatonpc1 in pc2 in pc1 = in pc2 = inERROR</p></li><li><p>One-bounded overtaking monitor automatonpc1=outpc1=reqpc2inpc1=reqpc2=inpc1=inpc1=reqpc2inpc1=reqpc2=inERROR</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>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 MAND</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>aacbcq|=Lbtruetruetrue</p></li><li><p>aacbcq|=B btruetruetrueobservationsf(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.?</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...</p></li></ul>