1 / 67

Four Lectures on Model Checking

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

velmac
Télécharger la présentation

Four Lectures on Model Checking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Four Lectures on Model Checking Tom Henzinger University of California, Berkeley

  2. 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

  3. Model-checking problem I|=S system model system property satisfaction relation

  4. 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.

  5. Logics Linear Branching Safety STL LivenessLTLCTL

  6. Automata Safety: finite automata Liveness: omega automata Linear: language containment Branching: simulation

  7. Automata Safety: finite automata Liveness: omega automata Linear: language containment for word automata Branching: language containment for tree automata

  8. 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

  9. 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

  10. 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)

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

  12. 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) = 

  13. 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

  14. 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]

  15. Branching semantics of specification automata, alternative definition: trace-tree containment (K,q) |=B M iff T(K,q)  T(M) finite trace trees

  16. 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)

  17. 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].

  18. 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 !)

  19. In practice, simulation is usually the “right” notion. (If there is language containment, but not simulation, this is usually accidental, not by design.)

  20. Omega Automata -safety & liveness (infinite runs !) -specification vs. monitor automata -linear (language containment) vs. branching (simulation) semantics

  21. 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

  22. 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)

  23. 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  

  24. finite:  FA Buchi:  BA coBuchi:  CA Streett:  (l  r) Rabin:  (l  r)

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

  26. Response specification automaton :  (a  b) assuming (a  b) = false s1 a b s2 s0 b a s3 Buchi condition { s0, s3 }

  27. Response monitor automaton :  (a  b) assuming (a  b) = false true a b s0 s1 s2 Buchi condition { s2 }

  28.  a a a s1 s0 Buchi condition { s0 } No coBuchi condition Streett condition { ({s0,s1}, {s0}) } Rabin condition { (, {s0}) }

  29.  a a a s1 s0 No Buchi condition coBuchi condition { s0 } Streett condition { ({s1}, ) } Rabin condition { ({s1}, {s0,s1}) }

  30.  a a a s1 s0 a s2 Buchi condition { s2 }

  31. -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]

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

  33. 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 

  34. 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)

  35. Structure of the Omega-Regular Languages Streett = Rabin Buchi coFinite Finite coBuchi

  36. Structure of the Omega-Regular Languages Streett = Rabin Buchi coFinite Finite coBuchi counter-free

  37. Structure of the Counter-free Omega-Regular Languages finite boolean combinations of  and     

  38. 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.

  39. finite boolean combinations of  and  weakly fair evty. safety     strongly fair eventuality

  40. 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]

  41. 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).

  42. |=B a a b b b c c c d d d

  43. a |=B a b c b c d d d d

  44. 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

  45. 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

  46. Model-Checking Algorithms = Graph Algorithms

  47. 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)

  48. From specification automata to monitor automata: determinization (exponential) + complementation (easy) From LTL to monitor automata: complementation (easy) + tableau construction (exponential)

  49. 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)

  50. Six Algorithms • Reachability • Strongly connected components • Recursively nested SCCs • Tableau construction • Relation refinement • Buchi games • Streett games • Streett determinization

More Related