Model Checking Lecture 2. Three important decisions when choosing system properties: 1automata vs. logic 2branching vs. linear time 3safety vs. liveness.

Slides:



Advertisements
Similar presentations
1 Verification by Model Checking. 2 Part 1 : Motivation.
Advertisements

Model Checking Lecture 4. Outline 1 Specifications: logic vs. automata, linear vs. branching, safety vs. liveness 2 Graph algorithms for model checking.
Model Checking Lecture 1.
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.
Avoiding Determinization Orna Kupferman Hebrew University Joint work with Moshe Vardi.
1 Reasoning with Promela Safety properties bad things do not happen can check by inspecting finite behaviours Liveness properties good things do eventually.
Model Checking and Testing combined
Black Box Checking Book: Chapter 9 Model Checking Finite state description of a system B. LTL formula. Translate into an automaton P. Check whether L(B)
Automatic Verification Book: Chapter 6. How can we check the model? The model is a graph. The specification should refer the the graph representation.
Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
CS 267: Automated Verification Lecture 2: Linear vs. Branching time. Temporal Logics: CTL, CTL*. CTL model checking algorithm. Counter-example generation.
Algorithmic Software Verification VII. Computation tree logic and bisimulations.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Part 3: Safety and liveness
1 Model checking. 2 And now... the system How do we model a reactive system with an automaton ? It is convenient to model systems with Transition systems.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
Temporal Logic and the NuSMV Model Checker CS 680 Formal Methods Jeremy Johnson.
CS6133 Software Specification and Verification
Model Checking Inputs: A design (in some HDL) and a property (in some temporal logic) Outputs: Decision about whether or not the property always holds.
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.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Digitaalsüsteemide verifitseerimise kursus1 Formal verification: Property checking Property checking.
1 Temporal Logic u Classical logic:  Good for describing static conditions u Temporal logic:  Adds temporal operators  Describe how static conditions.
CSE 555 Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd University of Petroleum & Minerals Credits: Dr. Abdul Waheed.
Temporal Logic Model- checking with SPIN COMP6004 Stéphane Lo Presti Part 4: Specifications.
Witness and Counterexample Li Tan Oct. 15, 2002.
Review of the automata-theoretic approach to model-checking.
ESE601: Hybrid Systems Introduction to verification Spring 2006.
Witness and Counterexample Li Tan Oct. 15, 2002.
Automata and Formal Lanugages Büchi Automata and Model Checking Ralf Möller based on slides by Chang-Beom Choi Provable Software Lab, KAIST.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
LTL – model checking Jonas Kongslund Peter Mechlenborg Christian Plesner Kristian Støvring Sørensen.
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.
1 Temporal Logic-Overview FM Temporal Logic u Classical logic: Good for describing static conditions u Temporal logic: Adds temporal operators Describe.
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.
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.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: LTL Model Checking Copyright , Matt Dwyer, John Hatcliff,
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)
Lecture 5 1 CSP tools for verification of Sec Prot Overview of the lecture The Casper interface Refinement checking and FDR Model checking Theorem proving.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
1 CSEP590 – Model Checking and Automated Verification Lecture outline for July 9, 2003.
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.
From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic Analysis Elsa L Gunter NJIT.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
Model Checking Lecture 1: Specification Tom Henzinger.
6/12/20161 a.a.2015/2016 Prof. Anna Labella Formal Methods in software development.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Model Checking Lecture 2. Model-Checking Problem I |= S System modelSystem property.
CS5270 Lecture 41 Timed Automata I CS 5270 Lecture 4.
Model Checking Lecture 2 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
Four Lectures on Model Checking Tom Henzinger University of California, Berkeley.
Formal methods: Lecture
SS 2017 Software Verification LTL monitoring
Automatic Verification
Alternating tree Automata and Parity games
CSEP590 – Model Checking and Automated Verification
Formal Methods in software development
Finite-Trace Linear Temporal Logic: Coinductive Completeness
Translating Linear Temporal Logic into Büchi Automata
Introduction to verification
Formal Methods in software development
Model Checking Graph Grammars
Presentation transcript:

Model Checking Lecture 2

Three important decisions when choosing system properties: 1automata vs. logic 2branching vs. linear time 3safety vs. liveness The three decisions are orthogonal, and they lead to substantially different model-checking problems.

If only universal properties are of interest, why not omit the path quantifiers?

LTL (Linear Temporal Logic) -safety & liveness -linear time [Pnueli 1977; Lichtenstein & Pnueli 1982]

LTL Syntax ::= a | | | | U

LTL Model infinite trace t = t 0 t 1 t 2... (sequence of observations)

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

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

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

Summary of modalities STL U W CTLall of the above and W U LTL U W

Important properties Invariance asafety (pc1=in pc2=in) Sequencing a W b W c W dsafety (pc1=req (pc2 in) W (pc2=in) W (pc2 in) W (pc1=in)) Response (a b)liveness (pc1=req (pc1=in))

Composed modalities ainfinitely often a aalmost 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 (pc2=in (pc2=out)) (pc1=req (pc1=in))

CTL cannot express fairness a a b b b aa q0q0 q1q1 q2q2

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

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

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

Language L(M) of specification automaton M = (S, S 0,, ) : infinite trace t 0, t 1,... L(M) iff there exists a infinite run s 0 s 1... of M such that for all 0 i, t i |= (s i )

(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 infinite traces

finite trace t 0,..., t n L fin (M) iff there exists a finite run s 0 s 1... s n of M such that for all 0 i n, t i |= (s i ) L fin (K,q) = set of finite traces of K starting at q L fin (M) defined as follows:

(K,q) |= L M iff L(K,q) L(M) iff L fin (K,q) L fin (M) Proof requires three facts: - K is deadlock-free - every state in K has a transition from it - M is finite-branching: - number of transitions from a state in M is bounded - Konigs lemma - A finite-branching infinite tree has an infinite path

(K,q) |= L M iff L fin (K,q) L fin (M) To verify (K,q) |= L M, check finitary trace-containment

Invariance specification automaton pc1 in pc2 in

One-bounded overtaking specification automaton pc1=out pc1=req pc2 in pc1=req pc2=in pc1=in pc1=req pc2 in

Automata are more expressive than logic, because temporal logic cannot count : This cannot be expressed in LTL. (How about a (a a) ?) atrue Let A = { a }

aa a aaaa a aaaa

aa a aaaa a aa atrue aa

aa a aaaa a aa a (a a) aa

aa a aaaa a aaaa In fact, no LTL formula with at most two occurrences of can distinguish between the two traces. Proof?

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. use monitor automata 2. use simulation as a sufficient condition

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 pc1 in pc2 in pc1 = in pc2 = in ERROR

One-bounded overtaking monitor automaton pc1=out pc1=req pc2 in pc1=req pc2=in pc1=in pc1=req pc2 in pc1=req pc2=in ERROR

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

In practice: 1. use monitor automata 2. use simulation as sufficient condition

(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]

a a c bc q |= L b true

a a c bc q |= B b true

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

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

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

Specification Omega Automata Syntax as for finite automata, in addition an acceptance condition: Buchi:BA S

Language L(M) of specification omega-automaton M = (S, S 0,,, BA ) : 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 BA 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 BA iff Buchi:Inf(s) BA

(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 a s1s1 s2s2 s3s3 s0s0 Buchi condition { s 0, s 3 }

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

a a s0s0 s1s1 Buchi condition { s 0 } a

a a s0s0 s1s1 Buchi condition { s 2 } a a s2s2

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

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)