670 likes | 685 Views
Four Lectures on Model Checking. Tom Henzinger University of California, Berkeley. Four Lectures on Model Checking: Lecture III. 1 Eight model-checking problems: logic vs. automata , linear vs. branching , safety vs. liveness
E N D
Four Lectures on Model Checking Tom Henzinger University of California, Berkeley
Four Lectures on Model Checking: Lecture III 1 Eight model-checking problems: logic vs. automata, linear vs. branching, safety vs. liveness 2 Finite-state systems: six graph algorithms for model checking 3 Infinite-state systems: from graph algorithms to symbolic algorithms
Model-checking problem I|=S system model system property satisfaction relation
Three important decisions when choosing system properties: • operational vs. declarative: automata vs. logic • may vs. must: branching vs. linear time • prohibiting bad vs. desiring good behavior: safety vs. liveness The three decisions are orthogonal, and they lead to substantially different model-checking problems.
Logics Linear Branching Safety STL LivenessLTLCTL
Automata Safety: finite automata Liveness: omega automata Linear: language containment Branching: simulation
Automata Safety: finite automata Liveness: omega automata Linear: language containment for word automata Branching: language containment for tree automata
Specification Automata Syntax, given a set A of atomic observations: • S finite set of states • S0 S set of initial states • S S transition relation • : S PL(A) where the formulas of PL are ::= a | | for a A
Linear semantics of specification automata: language containment (K,q) |=L M iff L(K,q) L(M) state-transition graph state of K specification automaton finite traces
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) =
Branching semantics of specification automata: simulation states of K (K,q) |=B M 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 • [q] |= (s) • for all q’ s.t. q q’ , exists s’ s.t. s s’ and (q’,s’) R. [Milner 1974]
Branching semantics of specification automata, alternative definition: trace-tree containment (K,q) |=B M iff T(K,q) T(M) finite trace trees
Branching semantics of specification automata, alternative definition: game model vs. specification (K,q) |=B M iff there exists a winning strategy of M against (K,q)
Strategy G of M against (K,q): function from finite runs of K that start in q to states of M such that - G() S0 - if G(q0…qn) = s and G(q0…qn+1) = s', then s s'. G is winning if - if G(q0…qn) = s, then [qn] = [s].
involves only traces (hence linear !) (K,q) |=L M M language contains (K,q) : exponential check (K,q) |=B M M simulates (K,q) : quadratic check X 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.)
Omega Automata -safety & liveness (infinite runs !) -specification vs. monitor automata -linear (language containment) vs. branching (simulation) semantics
Specification Omega Automata Syntax as for finite automata, in addition one of the following acceptance conditions: Buchi: BA S coBuchi: CA S Streett: SA 2S 2S Rabin: RA 2S 2S
Language L(M) of specification omega-automaton M = (S, S0, , , A ) : infinite trace t0, t1, ... L(M) iff there exists an infinite run s0 s1 ... of M such that 1. s0 s1 ... 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 coBuchi: 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
finite: FA Buchi: BA coBuchi: 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 s1 a b s2 s0 b a s3 Buchi condition { s0, s3 }
Response monitor automaton : (a b) assuming (a b) = false true a b s0 s1 s2 Buchi condition { s2 }
a a a s1 s0 Buchi condition { s0 } No coBuchi condition Streett condition { ({s0,s1}, {s0}) } Rabin condition { (, {s0}) }
a a a s1 s0 No Buchi condition coBuchi condition { s0 } Streett condition { ({s1}, ) } Rabin condition { ({s1}, {s0,s1}) }
a a a s1 s0 a s2 Buchi condition { s2 }
-Buchi and coBuchi 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 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
a true (p) ( p p (p p) (p a)) (p) ( p(0) p(1) (t) (p(t) p(t+2)) (t) (p(t) a(t))) (a; true)
Structure of the Omega-Regular Languages Streett = Rabin Buchi coFinite Finite coBuchi
Structure of the Omega-Regular Languages Streett = Rabin Buchi coFinite Finite coBuchi counter-free
Structure of the Counter-free Omega-Regular Languages finite 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.
finite boolean combinations of and weakly fair evty. safety strongly fair eventuality
Branching semantics of specification omega automata: infinite trace-tree containment (K,q) |=L M iff L(K,q) L(M) infinite trace trees ["Fair simulation"; H, Kupferman, Rajamani 1997]
Branching semantics of specification omega automata, alternative definition: game model vs. specification (K,q) |=B M iff there exists a winning strategy of M against (K,q). Strategy G is winning if - [G(q0…qn)] = [qn] - for all infinite fair runs q0q1… of K, G(q0) G(q0q1) G(q0q1q2) … L(M).
|=B a a b b b c c c d d d
a |=B a b c b c d d d d
Model-checking problem I|=S system model: state-transition graph system property: -safety v. weak v. strong fairness -logic v. spec v. monitor automata -linear v. branching
Model-checking problem I|= S system model: state-transition graph system property: -safety v. weak v. strong fairness -logic v. spec v. monitor automata -linear v. branching easiestharderhard
Safety: • -solve: STL (U model checking), finite monitors ( emptiness) • -algorithm: reachability (linear) • Eventuality under weak fairness: • -solve: weakly fair CTL ( model checking), Buchi monitors ( emptiness) • -algorithm: strongly connected components (linear) • Liveness: • -solve: strongly fair CTL, Streett monitors ( () emptiness) • -algorithm: recursively nested SCCs (quadratic)
From specification automata to monitor automata: determinization (exponential) + complementation (easy) From LTL to monitor automata: complementation (easy) + tableau construction (exponential)
B1 Simulation: relation refinement (quadratic) B2 Weakly fair simulation: Buchi game (quadratic) B3 Strongly fair simulation: Streett game (quadratic in structures, exponential in fairness constraints)
Six Algorithms • Reachability • Strongly connected components • Recursively nested SCCs • Tableau construction • Relation refinement • Buchi games • Streett games • Streett determinization