LTL – model checking Jonas Kongslund Peter Mechlenborg Christian Plesner Kristian Støvring Sørensen

Overview System Model Büchi automaton (A sys ) Negation of property PLTL-formula (  ) Normal-form formula Graph Generalised Büchi automaton Büchi automaton (A  ) Product automaton (A sys  A  ) State space Checking emptiness Yes!No! Model checker

Büchi Automata Def.: Labelled Büchi Automaton

Büchi Automata 2 Def.: Run of a LBA

Büchi Automata 3 Example: Σ={a,b,c,d,e} {a,d}{b} {c} (a|d)(bc + ) ω

Büchi Automata 4 For each PLTL formula φ one can construct an LBA A φ s.t. L ω (A φ ) is the sequences of sets of atomic propositions that satisfy φ. Let Σ=2 AP where AP is the set of atomic propositions.

Büchi Automata 5 Def.: Generalised LBA

Getting Normal Eliminate F and G operators Make negations adjacent to atomic propositions Example: LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty?

Past operators do not add any expressive power to LTL Why are they useful? Past operators are not easy expressed with future operators Getting Normal 2 LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty?

Past operators does not add any expressive power to LTL Why are they useful? Past operators are not easy to translate to normal form Possible exponential blowup Getting Normal 3 LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty?

Normal Form → GLBA LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty? Overall idea: A node in the graph represents a state, an edge represent a step forward in time. Each node contains formulas that must be true at this time; view these formulas as proof obligations: Atomic propositions: check for contradictions Conjunctions: check both clauses Disjunctions: split into two nodes and allow a nondeterministic choice Next: Push proof obligation to the successors Until and its evil twin: unfold recursively on demand

Accept states 1 LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty? Definition of strict p U q: Sooner or later, q must happen! {{q}, {p, q}}Ø {{p}, {p, q}} (Remember, every run is accepted, since the set of accept sets is empty)

Accept states 2 LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty? Definition of strict p U q: Sooner or later, q must happen! {{q}, {p, q}}Ø {{p}, {p, q}} Problem: The automaton accepts p ω !

Accept states 3 LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty? Definition of strict p U q: Sooner or later, q must happen! {{q}, {p, q}}Ø {{p}, {p, q}} Solution: Insert accept states to break the cycle (not needed for U).

Un-generalizing GLBAs 1 LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty? The generated automaton may have more than one set of accept states (one for each ‘until’ in the original formula):

Un-generalizing GLBAs 2 LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty? Duplicate automaton. When leaving an accept state, jump to next automaton. Keep only one set of accept states.

Un-generalizing GLBAs 3 LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty? Duplicate automaton. When leaving an accept state, jump to next automaton. Keep only one set of accept states.

Un-generalizing GLBAs 4 LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty? Duplicate automaton. When leaving an accept state, jump to next automaton. Keep only one set of accept states.

Un-generalizing GLBAs 5 LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty? Duplicate automaton. When leaving an accept state, jump to next automaton. Keep only one set of accept states.

Combining the two LBAs 1 LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty? Wanted: an automaton accepting the intersection of the two languages: x

Combining the two LBAs 2 LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty? By the ordinary DFA product construction: Problem: Requires accept states to be visited at the same time.

Combining the two LBAs 3 LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty? Solution: Use a GLBA with two accept sets, then reduce to an LBA.

The emptiness problem LTL → Normal Form → GLBA → LBA → LBA × LBA → Empty? How do we do it? Find an appropriate cycle in the LBA – if no such cycle exists, the language is empty. Why does this work? Theorem 17. Seriously, why? In order for the language to be non-empty, there must be an infinite run of the automaton that visits an accept state infinitely often. This means that there has to be a reachable cycle containing an accept state.

Overview System Model Büchi automaton (A sys ) Negation of property PLTL-formula (  ) Normal-form formula Graph Generalised Büchi automaton Büchi automaton (A  ) Product automaton (A sys  A  ) State space Checking emptiness Yes!No! Model checker

The state space Example int i; proctype P1(){ do ::true -> atomic(if::(i i=i+1 fi) od } proctype P2(){ do ::true -> atomic(if::(i!=2) -> i=2 ::else -> i=0 fi) od } init{i=0; run(P1); run(P2);}

The state space 2 A state –all global vars. –local vars. and program counter in all processes State space: all possible simulations from the initial state State space must be finite

The state space 3 i=0 i=1i=2 P1 and P2 enabled P2 enabled

Convert states to proposition tables –Get all propositions from the LTL expression –In each state Change the lable to the set of all satisfied propositions State space → LBA

Propositions: p:= (i <= 0) q:= (i == 1) r:= (i >= 2) State space → LBA 2 i=0 i=1i=2 p q r

State space → LBA 3 Make all paths infinite Make all states accepting –Product is now normal DFA product

The rest Is in chapter 5

References G. J. Holzmann: An improved protocol reachability analysis technique. O. Lichtenstein, A. Pnueli: The glory of the past. R. Gerth et al.: Simple on-the-fly automatic verification of linear temporal logic. K. Etessami, G. J. Holzmann: Optimizing Büchi automata. A. M. Mikkelsen: On-the-fly model checking in Design/CPN. G. J. Holzmann: The model checker SPIN.

Exercises Exercises 8, 9, 10 (s 3 should be s 2 ), 12 Derive the semantics of U from the semantics of U, and give an intuitive explanation.