Model Checking Lecture 2 ModelChecking Problem I S

Model Checking Lecture 2

Model-Checking Problem I |= S System model System property

System model: State-transition graph q 1 a, b a b q 2 q 3 States Q = { q 1, q 2, q 3 } Atomic observations A = { a, b } Transition relation Q Q Observation function [ ] : Q 2 A

Run: sequence of states q 1, q 2 Observation: set of atomic observations Trace: sequence of observations {a}, {a, b}

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

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

Defining a logic 1. Syntax: 2. What are the formulas? 3. 2. Semantics: 4. What are the models? 5. 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. models observations state-transition graph (“Kripke structure”)

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

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

STL Semantics (K, q) |= a iff a [q] (K, q) |= iff (K, q) |= and (K, q) |= iff not (K, q) |= iff exists q’ s. t. q q’ and (K, q’) |= (K, q) |= U iff exist q 0, . . . , qn s. t. 1. q = q 0 q 1 . . . qn 2. for all 0 i < n, 3. (K, qn) |= (K, qi) |=

Defined modalities EX exists next = AX forall next U EU exists until = true U EF exists eventually = AG forall always W = ( ( ) U ( )) AW forall waiting-for (forall weak-until)

Important safety properties Invariance a Sequencing a W b W c W d = a W (b W (c W d))

Important safety properties: mutex protocol Invariance (in_cs 1 in_cs 2) Sequencing ( req_cs 1 in_cs 2 W in_cs 1 )

Branching properties Deadlock freedom true Possibility (a b) (req_cs 1 in_cs 1)

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

CTL Models = Kripke Structures

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

Computation Tree Logic, CTL Clarke & Emerson 1980 Syntax

CTL, Derived Operators possible inevitable ” ly l a u ent ” v e sts hable i x e ” c a e r or ” AF p EF p s st ”exi lly” a b glo p p. . . . . p

CTL, Derived Operators potentially always for all paths next AG p ” lly a b o gl l ly” l t a n r a p ”fo nvari i or ” p EG p e l ev l a r o ”f ly l a u nt ” p p p . . . p

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

CTL Semantics (K, q) |= iff exist q 0, q 1, . . . s. t. 1. q = q 0 q 1 . . . is an infinite fair run 2. for all i 0, (K, qi) |=

Defined modalities EG exists always = AF forall eventually W = ( U ) ( ) U = ( W ) ( )

Important liveness property Response (a b) (req_cs 1 in_cs 1)

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 Model infinite trace t = t 0 t 1 t 2. . .

Language of deadlock-free state-transition graph K at state q : L(K, q). . . set of infinite traces of K starting at q (K, q) |= iff for all t L(K, q), t |= (K, q) |= iff exists t L(K, q), t |=

LTL Semantics t |= a iff a t 0 t |= iff t |= and t |= iff not t |= iff t 1 t 2. . . |= t |= U iff exists n 0 s. t. 1. for all 0 i < n, ti ti+1. . . |= 2. tn tn+1. . . |=

Defined modalities X next U U until = true U F eventually = G always W = ( U ) W waiting-for (weak-until)

Important properties Invariance a (in_cs 1 in_cs 2) Sequencing a. Wb. Wc. Wd ( req_cs 1 in_cs 2 W in_cs 1 ) Response (a b) (req_cs 1 in_cs 1)

Composed modalities a infinitely often a a almost 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_cs 2 out_cs 2) (req_cs 1 in_cs 1)

CTL cannot express fairness q 0 a a a b b b q 1 a q 2

LTL cannot express branching Possibility (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 Automata Syntax, given a set A of atomic observations: S finite set of states S 0 S set 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, S 0, , ) : finite trace t 0, . . . , tn L(M) iff there exists a finite run s 0 s 1 . . . sn of M such that for all 0 i n, ti |= (si)

Linear semantics of specification automata: language containment (K, q) |=L M state-transition graph state of K iff L(K, q) L(M) specification automaton finite traces

Invariance specification automaton in_cs 1 in_cs 2

Starvation freedom specification automaton req_cs 1 in_cs 2 out_cs 1 in_cs 1 req_cs 1 in_cs 2

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

Checking language containment between finite automata is PSPACE-complete ! L(K, q) L(M) iff L(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 Automata Syntax: same as specification automata, except also set E S of error states Semantics: 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_cs 1 in_cs 2 in_cs 1 in_cs 2

Starvation freedom monitor automaton req_cs 1 in_cs 2 out_cs 1 in_cs 1 req_cs 1 in_cs 2

Specification automaton M Monitor automaton complement(M) -describe correct traces -describe error traces -check language containment (exponential) -check emptiness (linear): reachability of error states “All safety verification is reachability checking. ”

Main problem with deterministic specifications and monitor automata: not suitable for stepwise refinement / abstraction S 1 |= S 2 |= S 3 “refines”

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

Branching semantics of specification automata: simulation (K, q) |=B M states of K iff there exists a simulation relation R Q S s. t. (q, s) R for some initial state s of M states of M

R Q S is a simulation relation iff (q, s) R implies 1. [q] |= (s) 2. for all q’ s. t. q q’ , exists s’ s. t. s s’ and (q’, s’) R. [Milner 1974]

involves only traces (hence linear !) (K, q) |=L M M language contains (K, q) : exponential check (K, q) |=B M X M simulates (K, q) : quadratic check 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) semantics We discuss only the linear specification case.

Specification Omega-Automata Syntax as for finite automata, in addition one of the following acceptance conditions: Buchi: BA S co. Buchi: CA S Streett: SA 2 S Rabin: RA 2 S

Language L(M) of specification omega-automaton M = (S, S 0, , , A ) : infinite trace t 0, t 1, . . . L(M) iff there exists an infinite run s 0 s 1 . . . of M such that 1. s 0 s 1 . . . 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 A iff Buchi: Inf(s) BA co. Buchi: Inf(s) CA Streett: 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

Buchi: BA co. Buchi: CA Streett: ( l r) Rabin: ( l r)

Linear semantics of specification omega-automata: omega-language containment (K, q) |=L M iff L(K, q) L(M) infinite traces

Response specification automaton : (a b) assuming (a b) = false s 1 a b a b s 2 s 0 s 3 Buchi condition { s 0, s 3 }

a a s 0 a s 1 Buchi condition { s 0 } Streett condition { ({s 0, s 1}, {s 0}) } No co. Buchi condition Rabin condition { ( , {s 0}) }

a a s 0 a s 1 No Buchi condition Streett condition { ({s 1}, ) } co. Buchi condition { s 0 } Rabin condition { ({s 1}, {s 0, s 1}) }

a a a s 0 s 1 a s 2 Buchi condition { s 2 }

-Buchi and co. Buchi automata cannot be determinized -Streett and Rabin automata can be determinized nondeterministic Buchi = deterministic Streett = deterministic Rabin = nondeterministic Streett = nondeterministic Rabin = omega-regular [Buchi 1960]

Omega-automaton determinization is even harder (conceptually, at least) than finiteautomaton determinization [Safra 1989]. So monitor automata and simulation are particularly important.

Omega-automata are strictly more expressive than LTL Omega-automata: omega-regular languages LTL: counter-free omega-regular languages

Omega-automata: omega-regular languages = second-order theory of monadic predicates & successor = omega-regular expressions LTL: counter-free omega-regular languages = first-order theory of monadic predicates & successor = star-free omega-regular expressions

Structure of the omega-regular languages Streett = Rabin Buchi co. Finite co. Buchi

Structure of the counter-free omega-regular languages positive boolean combinations of and

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.

positive boolean combinations of and weak fair response strong fair safety