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

Slides:



Advertisements
Similar presentations
Model Checking Lecture 1.
Advertisements

Model Checking Lecture 3. Specification Automata Syntax, given a set A of atomic observations: Sfinite set of states S 0 Sset of initial states S S transition.
Model Checking Lecture 2. Three important decisions when choosing system properties: 1automata vs. logic 2branching vs. linear time 3safety vs. liveness.
CS 267: Automated Verification Lecture 2: Linear vs. Branching time. Temporal Logics: CTL, CTL*. CTL model checking algorithm. Counter-example generation.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Part 3: Safety and liveness
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
1 1 CDT314 FABER Formal Languages, Automata and Models of Computation Lecture 3 School of Innovation, Design and Engineering Mälardalen University 2012.
Determinization of Büchi Automata
CS 267: Automated Verification Lecture 10: Nested Depth First Search, Counter- Example Generation Revisited, Bit-State Hashing, On-The-Fly Model Checking.
1 Temporal Claims A temporal claim is defined in Promela by the syntax: never { … body … } never is a keyword, like proctype. The body is the same as for.
 Dr. Vered Gafni 1 LTL Decidability Enables consistency check, but also base for verification.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Review of topics Final exam : -May 2nd to May 7 th - Projects due on May 7th.
Finite Automata Great Theoretical Ideas In Computer Science Anupam Gupta Danny Sleator CS Fall 2010 Lecture 20Oct 28, 2010Carnegie Mellon University.
1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture # 11.
Games, Times, and Probabilities: Value Iteration in Verification and Control Krishnendu Chatterjee Tom Henzinger.
Witness and Counterexample Li Tan Oct. 15, 2002.
A temporal logic for calls and returns P. Madhusudan University of Pennsylvania Joint work with Rajeev Alur and Kousha Etessami Talk at HCES 2004, Philadelphia.
Review of the automata-theoretic approach to model-checking.
ESE601: Hybrid Systems Introduction to verification Spring 2006.
1 Completeness and Complexity of Bounded Model Checking.
Witness and Counterexample Li Tan Oct. 15, 2002.
Flavio Lerda 1 LTL Model Checking Flavio Lerda. 2 LTL Model Checking LTL –Subset of CTL* of the form: A f where f is a path formula LTL model checking.
Quantitative Languages Krishnendu Chatterjee, UCSC Laurent Doyen, EPFL Tom Henzinger, EPFL CSL 2008.
Solving Games Without Determinization Nir Piterman École Polytechnique Fédéral de Lausanne (EPFL) Switzerland Joint work with Thomas A. Henzinger.
1 Carnegie Mellon UniversitySPINFlavio Lerda Bug Catching SPIN An explicit state model checker.
15-820A 1 LTL to Büchi Automata Flavio Lerda A 2 LTL to Büchi Automata LTL Formulas Subset of CTL* –Distinct from CTL AFG p  LTL  f  CTL. f.
Regular Model Checking Ahmed Bouajjani,Benget Jonsson, Marcus Nillson and Tayssir Touili Moran Ben Tulila
Institute for Applied Information Processing and Communications 1 Karin Greimel Semmering, Open Implication.
Model Checking Lecture 4 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
Basics of automata theory
Model Checking Lecture 3 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
Languages of nested trees Swarat Chaudhuri University of Pennsylvania (with Rajeev Alur and P. Madhusudan)
DECIDABILITY OF PRESBURGER ARITHMETIC USING FINITE AUTOMATA Presented by : Shubha Jain Reference : Paper by Alexandre Boudet and Hubert Comon.
Automatic Structures Bakhadyr Khoussainov Computer Science Department The University of Auckland, New Zealand.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: LTL Model Checking Copyright , Matt Dwyer, John Hatcliff,
Orna Kupferman Hebrew University Formal Verification -- Deciding the Undecidable.
Avoiding Determinization Orna Kupferman Hebrew University Joint work with Moshe Vardi.
Copyright , Doron Peled and Cesare Tinelli. These notes are based on a set of lecture notes originally developed by Doron Peled at the University.
Four Lectures on Model Checking Tom Henzinger University of California, Berkeley.
Lectures on Model Checking Stolen from lectures of Tom Henzinger - EE219C (CS294)
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
LTL Model Checking 张文辉
Overview of course CS598MP Spring’05. Modeling FSM, PDA Emptiness of PDA Games on FSMs Binary Decision Diagrams CTL bisimulations Mu-calculus Model-check.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Strings Basic data type in computational biology A string is an ordered succession of characters or symbols from a finite set called an alphabet Sequence.
1 CSEP590 – Model Checking and Automated Verification Lecture outline for July 9, 2003.
1 Temporal logic. 2 Prop. logic: model and reason about static situations. Example: Are there truth values that can be assigned to x,y simultaneously.
Model Checking Lecture 1. Model checking, narrowly interpreted: Decision procedures for checking if a given Kripke structure is a model for a given formula.
Variants of LTL Query Checking Hana ChocklerArie Gurfinkel Ofer Strichman IBM Research SEI Technion Technion - Israel Institute of Technology.
About Alternating Automata Daniel Choi Provable Software Laboratory KAIST.
Space Complexity. Reminder: P, NP classes P is the class of problems that can be solved with algorithms that runs in polynomial time NP is the class of.
Model Checking Lecture 1: Specification Tom Henzinger.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Model Checking Lecture 2. Model-Checking Problem I |= S System modelSystem property.
Model Checking Lecture 2 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
15-820A 1 LTL Model Checking A Flavio Lerda.
CIS 842: Specification and Verification of Reactive Systems
SS 2017 Software Verification LTL monitoring
Automatic Verification
Program Synthesis is a Game
Jaya Krishna, M.Tech, Assistant Professor
Alternating tree Automata and Parity games
CSEP590 – Model Checking and Automated Verification
Translating Linear Temporal Logic into Büchi Automata
Introduction to verification
Formal Methods in software development
Instructor: Aaron Roth
Presentation transcript:

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 modelsystem property satisfaction relation

Three important decisions when choosing system properties: 1operational vs. declarative: automata vs. logic 2may vs. must: branching vs. linear time 3prohibiting bad vs. desiring good behavior: safety vs. liveness The three decisions are orthogonal, and they lead to substantially different model-checking problems.

LinearBranching Safety STL LivenessLTL CTL Logics

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: Sfinite set of states S 0  Sset of initial states   S  S transition relation  : S  PL(A) where the formulas of PL are  ::= a |    |   for a  A

(K,q) |= L M iff L(K,q)  L(M) Linear semantics of specification automata: language containment 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) = 

(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 Branching semantics of specification automata: simulation states of K 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]

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(  )  S 0 - if G(q 0 …q n ) = s and G(q 0 …q n+1 ) = s', then s  s'. G is winning if - if G(q 0 …q n ) = s, then [q n ] = [s].

(K,q) |= L MM language contains (K,q) : exponential check (K,q) |= B MM simulates (K,q) : quadratic check   X involves only traces (hence linear !) 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.)

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

Specification Omega Automata Syntax as for finite automata, in addition one of the following acceptance conditions: Buchi:BA  S coBuchi:CA  S Streett:SA  2 S  2 S Rabin:RA  2 S  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, t i |=  (s i )

Let Inf(s) = { p | p = s i 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)

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

Response specification automaton :  (a   b) assuming (a  b) = false a bb b aa s1s1 s2s2 s3s3 s0s0 Buchi condition { s 0, s 3 }

Response monitor automaton :  (a   b) assuming (a  b) = false a bb s1s1 s2s2 Buchi condition { s 2 } s0s0 true

a aa s0s0 s1s1 Buchi condition { s 0 } No coBuchi condition  a Streett condition { ({s 0,s 1 }, {s 0 }) } Rabin condition { ( , {s 0 }) }

a aa s0s0 s1s1 No Buchi condition coBuchi condition { s 0 }  a Streett condition { ({s 1 },  ) } Rabin condition { ({s 1 }, {s 0,s 1 }) }

a aa s0s0 s1s1 Buchi condition { s 2 }  a a s2s2

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

atrue (  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 coBuchi FinitecoFinite

Structure of the Omega-Regular Languages Streett = Rabin Buchi coBuchi FinitecoFinite 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  safety weakly fair evty. strongly fair eventuality

(K,q) |= L M iff L(K,q)  L(M) Branching semantics of specification omega automata: infinite trace-tree containment 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(q 0 …q n )] = [q n ] - for all infinite fair runs q 0 q 1 … of K, G(q 0 ) G(q 0 q 1 ) G(q 0 q 1 q 2 ) …  L(M).

a d b c a d b c d b c |= B

a d bc a d b d c 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 easiest harder hard

Model-Checking Algorithms = Graph Algorithms

1Safety: -solve: STL (  U model checking), finite monitors (  emptiness) -algorithm: reachability (linear) 2Eventuality under weak fairness: -solve: weakly fair CTL (   model checking), Buchi monitors (  emptiness) -algorithm: strongly connected components (linear) 3Liveness: -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 1Reachability 2Strongly connected components 3Recursively nested SCCs 4Tableau construction 5Relation refinement 6Buchi games 7Streett games 8Streett determinization

Finite Emptiness Given: finite automaton (S, S 0, , , FA) Find: is there a path from a state in S 0 to a state in FA ? Solution: depth-first or breadth-first search

Application 1:STL model checking Application 2:finite monitors

Buchi Emptiness Given: Buchi automaton (S, S 0, , , BA) Find: is there an infinite path from a state in S 0 that visits some state in BA infinitely often ? Solution: 1. Compute SCC graph by depth-first search 2. Mark SCC C as fair iff C  BA   3. Check if some fair SCC is reachable from S 0

Application 1:CTL model checking over weakly-fair transition graphs (note: really need multiBuchi) Application 2:Buchi monitors

Streett Emptiness Given: Streett automaton (S, S 0, , , SA) Find: is there an infinite path from a state in S 0 that satisfies all Streett conditions (l,r) in SA ? Solution: check if S 0  RecSCC (S, , SA)  

function RecSCC (S, , SA) : X :=  for each C  SCC (S,  ) do F :=  if  C   then for each (l,r)  SA do if C  r   then F := F  (l,r) else C := C \ l if F = SA then X := X  pre * (C) else X := X  RecSCC (C,  C, F) return X

Complexity n number of states m number of transitions snumber of Streett pairs Reachability:O(n+m) SCC:O(n+m) RecSCC:O((n+m) · s 2 )

Application 1:CTL model checking over strongly-fair transition graphs Application 2:Streett monitors

Tableau Construction Given: LTL formula  Find: Buchi automaton M  such that L(M  ) = L(  ) [Fischer & Ladner 1975; Manna & Wolper 1982] monitors subformulas of 

Fischer-Ladner Closure of a Formula Sub (a)= { a } Sub (  )={  }  Sub (  )  Sub (  ) Sub (  )={  }  Sub (  ) Sub (   )={   }  Sub (  ) Sub (  U  )={  U ,  (  U  ) }  Sub (  )  Sub (  ) | Sub (  ) | = O(|  |)

s  Sub (  ) is consistent iff -if (  )  Sub (  ) then (  )  s iff   s and   s -if (  )  Sub (  ) then (  )  s iff   s -if (  U  )  Sub (  ) then (  U  )  s iff either   s or   s and  (  U  )  s

Tableau M  = (S, S 0, , , BA) S...set of consistent subsets of Sub (  ) s  S 0 iff   s s  t iff for all (   )  Sub (  ), (   )  s iff   t  (s)... conjunction of atomic observations in s and negated atomic observations not in s For each (  U  )  Sub (  ), BA contains { s |   s or (  U  )  s }

 = (  a) U (  b) ,    a,  a ,    a, a   b, b,  b

 = (  a) U (  b) ,    a,  a ,    a, a   b, b,  b   a,  a  b, b,  b   a, a  b, b,  b  b, b,  b

 = (  a) U (  b) ,    a,  a ,    a, a   b, b,  b   a,  a  b, b,  b   a, a  b, b,  b  b, b,  b  a,  a  b, b,  b  a, a  b, b,  b

 = (  a) U (  b) ,    a,  a ,    a, a   b, b,  b   a,  a  b, b,  b   a, a  b, b,  b  b, b,  b  a,  a  b, b,  b  a, a  b, b,  b

Size of M  is O(2 |  | ). CTL model checking:linear / quadratic LTL model checking:PSPACE-complete