Maude Model Checker: Decidability of Propositional LTL and Model Checking in Maude - Prof., Study notes of Computer Science

Download Maude Model Checker: Decidability of Propositional LTL and Model Checking in Maude - Prof. and more Study notes Computer Science in PDF only on Docsity! Program Verification: Lecture 25 José Meseguer Computer Science Department University of Illinois at Urbana-Champaign 1 Decidability of Propositional LTL It is well-known that, for any computable Kripke structure A = (A,→A, L), any state a ∈ A such that the set ReachA(a) = {x ∈ A | ∃π ∈ Path(A) ∃n ∈ IN s.t. π(0) = a∧π(n) = x} of states reachable from a in A is finite, and any LTL formula ϕ ∈ LTL(AP ), where L : A −→ P(AP ), there is a decision procedure that can effectively decide the satisfaction relation, A, a |=LTL ϕ. Furthermore, if A, a 6|=LTL ϕ, the decision procedure will exhibit a counterexample, that is, a path not satisfying ϕ. 2 The Maude Model Checker (II) K(R, k)Π, [t] |= ϕ. By applying the general LTL decidability results to our Kripke structure K(R, k)Π, this satisfaction relation becomes decidable if two conditions hold: 1. The set of states in TΣ/E,k that are reachable from [t] by rewriting is finite. 2. The rewrite theory R = (Σ, E, φ, R) specified by M plus the equations D defining the predicates Π are such that: 5 The Maude Model Checker (III) • both E and E ∪ D are (ground) Church-Rosser and terminating, perhaps modulo some axioms A, and • R is (ground) coherent relative to E (again, perhaps modulo some axioms A). Under these assumptions, both the state predicates Π and the transition relation →1 R are computable and, given the finite reachability assumption, we can then settle the above satisfaction problem using a model checking procedure. Specifically, Maude uses an on-the-fly LTL model checking procedure of the style described by Clark, Grumberg, and Peled. 6 The Maude Model Checker (III) The basis of this procedure is the following. Each LTL formula ϕ has an associated Büchi automaton Bϕ whose acceptance ω-language is exactly that of the behaviors satisfying ϕ. We can then reduce the satisfaction problem K(R, k)Π, [t] |= ϕ to the emptiness problem of the language accepted by the synchronous product of B¬ϕ and (the Büchi automaton associated to) (K(R, k)Π, [t]). The formula ϕ is satisfied iff such a language is empty. The model checking procedure checks emptiness by looking for a counterexample, that is, an infinite computation belonging to the language recognized by the synchronous product. 7 op _\/_ : PE-Formula PE-Formula -> PE-Formula [ctor ditto] . op _\/_ : PU-Formula PU-Formula -> PU-Formula [ctor ditto] . op _\/_ : PureFormula PureFormula -> PureFormula [ctor ditto] . op O_ : PE-Formula -> PE-Formula [ctor ditto] . op O_ : PU-Formula -> PU-Formula [ctor ditto] . op O_ : PureFormula -> PureFormula [ctor ditto] . op _U_ : PE-Formula PE-Formula -> PE-Formula [ctor ditto] . op _U_ : PU-Formula PU-Formula -> PU-Formula [ctor ditto] . op _U_ : PureFormula PureFormula -> PureFormula [ctor ditto] . op _U_ : TrueFormula Formula -> PE-Formula [ctor ditto] . op _U_ : TrueFormula PU-Formula -> PureFormula [ctor ditto] . op _R_ : PE-Formula PE-Formula -> PE-Formula [ctor ditto] . op _R_ : PU-Formula PU-Formula -> PU-Formula [ctor ditto] . op _R_ : PureFormula PureFormula -> PureFormula [ctor ditto] . op _R_ : FalseFormula Formula -> PU-Formula [ctor ditto] . op _R_ : FalseFormula PE-Formula -> PureFormula [ctor ditto] . vars p q r s : Formula . var pe : PE-Formula . var pu : PU-Formula . var pr : PureFormula . 10 *** Rules 1, 2 and 3; each with its dual. eq (p U r) /\ (q U r) = (p /\ q) U r . eq (p R r) \/ (q R r) = (p \/ q) R r . eq (p U q) \/ (p U r) = p U (q \/ r) . eq (p R q) /\ (p R r) = p R (q /\ r) . eq True U (p U q) = True U q . eq False R (p R q) = False R q . *** Rules 4 and 5 do most of the work. eq p U pe = pe . eq p R pu = pu . *** An extra rule in the same style. eq O pr = pr . *** We also use the rules from: *** Fabio Somenzi and Roderick Bloem, *** "Efficient Buchi Automata from LTL Formulae", *** p247-263, CAV 2000, LNCS 1633. *** that are not subsumed by the previous system. 11 *** Four pairs of duals. eq O p /\ O q = O (p /\ q) . eq O p \/ O q = O (p \/ q) . eq O p U O q = O (p U q) . eq O p R O q = O (p R q) . eq True U O p = O (True U p) . eq False R O p = O (False R p) . eq (False R (True U p)) \/ (False R (True U q)) = False R (True U (p \/ q)) . eq (True U (False R p)) /\ (True U (False R q)) = True U (False R (p /\ q)) . *** <= relation on formula op _<=_ : Formula Formula -> Bool [prec 75] . eq p <= p = true . eq False <= p = true . eq p <= True = true . ceq p <= (q /\ r) = true if (p <= q) /\ (p <= r) . ceq p <= (q \/ r) = true if p <= q . 12 The Maude Model Checker (VII) The module MODEL-CHECKER is as follows. fmod MODEL-CHECKER is protecting QID . protecting SATISFACTION . protecting LTL . subsort Prop < Formula . *** transitions and results sorts RuleName Transition TransitionList ModelCheckResult . subsort Qid < RuleName . subsort Transition < TransitionList . subsort Bool < ModelCheckResult . ops unlabeled deadlock : -> RuleName . op {_,_} : State RuleName -> Transition [ctor] . op nil : -> TransitionList [ctor] . op __ : TransitionList TransitionList -> TransitionList [ctor assoc id: nil] . op counterexample : TransitionList TransitionList -> ModelCheckResult [ctor] . op modelCheck : State Formula ~> ModelCheckResult [special ( ... )] . endfm 15 The Maude Model Checker (VIII) Its key operator is modelCheck (whose special attribute has been omitted here), which takes a state and an LTL formula and returns either the Boolean true if the formula is satisfied, or a counterexample when it is not satisfied. Let us illustrate the use of this operator with our MUTEX example. Following the pattern described above, we can define the module mod MUTEX-CHECK is including MUTEX-PREDS . including MODEL-CHECKER . including LTL-SIMPLIFIER . ops initial1 initial2 : -> Conf . eq initial1 = $ [a,wait] [b,wait] . eq initial2 = * [a,wait] [b,wait] . endm 16 The Maude Model Checker (X) We are then ready to model check different LTL properties of MUTEX. The first obvious property to check is mutual exclusion: Maude> red modelCheck(initial1,[] ~(crit(a) /\ crit(b))) . reduce in MUTEX-CHECK : modelCheck(initial1, []~ (crit(a) /\ crit(b))) . rewrites: 18 in 10ms cpu (10ms real) (1800 rewrites/second) result Bool: true Maude> red modelCheck(initial2,[] ~(crit(a) /\ crit(b))) . reduce in MUTEX-CHECK : modelCheck(initial2, []~ (crit(a) /\ crit(b))) . rewrites: 12 in 0ms cpu (0ms real) (~ rewrites/second) result Bool: true 17 The Maude Model Checker (XIII) Of course, not all properties are true. Therefore, instead of a success we can get a counterexample showing why a property fails. Suppose that we want to check whether, beginning in the state initial1, process b will always be waiting. We then get the counterexample: Maude> red modelCheck(initial1,[] wait(b)) . reduce in MUTEX-CHECK : modelCheck(initial1, []wait(b)) . rewrites: 14 in 10ms cpu (10ms real) (1400 rewrites/second) result ModelCheckResult: counterexample({$ [a,wait] [b,wait],’a-enter} {[a,critical] [b,wait],’a-exit} {* [a,wait] [b,wait],’b-enter}, {[a,wait] [b,critical],’b-exit} {$ [a,wait] [b,wait],’a-enter} {[a,critical] [b,wait],’a-exit} {* [a,wait] [b,wait],’b-enter}) 20 The Maude Model Checker (XIV) The main counterexample term constructors are: op {_,_} : State RuleName -> Transition . op nil : -> TransitionList [ctor] . op __ : TransitionList TransitionList -> TransitionList [ctor assoc id: nil] op counterexample : TransitionList TransitionList -> ModelCheckResult [ctor] A counterexample is a pair consisting of two lists of transitions: the first is a finite path beginning in the initial state, and the second describes a loop. This is because, if an LTL formula ϕ is not satisfied by a finite Kripke structure, it is always possible to find a counterexample for ϕ having the form of a path of transitions followed by a cycle. Note that each transition is represented as a pair, consisting of a state and the label of the rule applied to reach the next state. 21 Model Checking TOK-RING Consider the following TOK-RING module, (fth NZNAT* is protecting NAT . op * : -> NzNat . endfth) (fmod NAT/{N :: NZNAT*} is sort Nat/{N} . op ‘[_‘] : Nat -> Nat/{N} . op _+_ : Nat/{N} Nat/{N} -> Nat/{N} . op _*_ : Nat/{N} Nat/{N} -> Nat/{N} . vars I J : Nat . ceq [I] = [I rem *] if I >= * . eq [I] + [J] = [I + J] . eq [I] * [J] = [I * J] . endfm) 22 Model Checking TOK-RING (III) (omod CHECK-TOK-RING{N :: NZNAT*} is inc TOK-RING{N} . inc MODEL-CHECKER . subsort Configuration < State . op inCrit : Nat/{N} -> Prop . op twoInCrit : -> Prop . var I : Nat . vars X Y : Nat/{N} . var C : Configuration . var F : Formula . eq < X : Proc | mode : critical > C |= inCrit(X) = true . eq < X : Proc | mode : critical > < Y : Proc | mode : critical > C |= twoInCrit = true . 25 op guaranteedReentrance : -> Formula . op allProcessesReenter : Nat -> Formula . op nextIter_ : Formula -> Formula . op nextIterAux : Nat Formula -> Formula . ceq guaranteedReentrance = allProcessesReenter(I) if s(I) := * . eq allProcessesReenter(s(I)) = (<> inCrit([s(I)])) /\ [] (inCrit([s(I)]) -> (nextIter inCrit([s(I)]))) /\ allProcessesReenter(I) . eq allProcessesReenter(0) = (<> inCrit([0])) /\ [] (inCrit([0]) -> (nextIter inCrit([0]))) . eq nextIter F = nextIterAux(2 * *, F) . eq nextIterAux(s I, F) = O nextIterAux(I, F) . eq nextIterAux(0, F) = F . endom) 26 Model Checking TOK-RING (IV) We cannot model check these properties directly in their parameterized form. However, for each nozero value n we can check the corresponding instance of these properties. For example, for n = 5 we define in Full Maude the view, (view 5 from NZNAT* to NAT is op * to term 5 . endv) Then we can model check the mutual exclusion property for 5 processes as follows: (red in CHECK-TOK-RING{5} : modelCheck(init,[] ~ twoInCrit) .) result Bool : true 27