CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.

Slides:



Advertisements
Similar presentations
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.
Advertisements

Model Checking Lecture 2. Three important decisions when choosing system properties: 1automata vs. logic 2branching vs. linear time 3safety vs. liveness.
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.
CS 267: Automated Verification Lecture 2: Linear vs. Branching time. Temporal Logics: CTL, CTL*. CTL model checking algorithm. Counter-example generation.
Partial Order Reduction: Main Idea
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.
CS 290C: Formal Models for Web Software Lecture 3: Verification of Navigation Models with the Spin Model Checker Instructor: Tevfik Bultan.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
An Introduction to the Model Verifier verds Wenhui Zhang September 15 th, 2010.
Timed Automata.
/ PSWLAB P ROMELA Semantics from “THE SPIN MODEL CHECKER” by G. J. Holzmann Presented by Hong,Shin 5 th Oct :021PROMELA Semantics.
תרגול 9 META LABELS. Basic types of claims State properties.
Frederico Araujo CS6362 – Fall 2010 The SPIN Model Checker.
CS 267: Automated Verification Lecture 10: Nested Depth First Search, Counter- Example Generation Revisited, Bit-State Hashing, On-The-Fly Model Checking.
PSWLAB S PIN Search Algorithm from “THE SPIN MODEL CHECKER” by G Holzmann Presented by Hong,Shin 9 th Nov SPIN Search Algorithm.
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.
CS 267: Automated Verification Lecture 7: SMV Symbolic Model Checker, Partitioned Transition Systems, Counter-example Generation in Symbolic Model Checking.
S. Ramesh Model-Checking Distributed Software S. Ramesh IIT Bombay.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
1 Spin Model Checker Samaneh Navabpour Electrical and Computer Engineering Department University of Waterloo SE-464 Summer 2011.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Spin Tutorial (some verification options). Assertion is always executable and has no other effect on the state of the system than to change the local.
© 2011 Carnegie Mellon University SPIN: Part Bug Catching: Automated Program Verification and Testing Sagar Chaki November 2, 2011.
1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture # 11.
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.
1 Carnegie Mellon UniversitySPINFlavio Lerda SPIN An explicit state model checker.
Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.
Review of the automata-theoretic approach to model-checking.
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.
CS 290C: Formal Models for Web Software Lecture 4: Model Checking Navigation Models with Spin Instructor: Tevfik Bultan.
The Model Checker SPIN Written by Gerard J. Holzmann Presented by Chris Jensen.
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.
CS 290C: Formal Models for Web Software Lecture 18: Verification of Data Driven Web Applications Instructor: Tevfik Bultan.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 4: SMT-based Bounded Model Checking of Concurrent Software.
1 Carnegie Mellon UniversitySPINFlavio Lerda Bug Catching SPIN An explicit state model checker.
Model Checking and Related Techniques
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
Wishnu Prasetya Model Checking with SPIN A Bit More about SPIN.
Correctness requirements. Basic Types of Claims Basic assertions End-state labels Progress-state labels Accept-state labels Never claims Trace assertions.
Basics of automata theory
Model Checking Lecture 3 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
Scientific Computing By: Fatima Hallak To: Dr. Guy Tel-Zur.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: Sequencing Properties Copyright , Matt Dwyer, John Hatcliff,
CS6133 Software Specification and Verification
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: LTL Model Checking Copyright , Matt Dwyer, John Hatcliff,
Concurrency. A process is a program executing on a virtual computer Processor speed and multiplexing of shared resources are ignored Order of thread execution.
MODEL CHECKING WITH SPIN MODELING AND VERIFICATION WITH SPIN ANDREA ORLANDINI – ISTC (CNR) TexPoint fonts used in EMF. Read the TexPoint manual before.
Copyright , Doron Peled and Cesare Tinelli. These notes are based on a set of lecture notes originally developed by Doron Peled at the University.
1 CSEP590 – Model Checking and Automated Verification Lecture outline for August 6, 2003.
Temporal Logic Model-checking with SPIN
Constraints Assisted Modeling and Validation Presented in CS294-5 (Spring 2007) Thomas Huining Feng Based on: [1]Constraints Assisted Modeling and Validation.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
/ PSWLAB S PIN Search Optimization from “THE SPIN MODEL CHECKER” by G. Holzmann Presented by Hong,Shin 23 th Nov SPIN Search.
Lecture 4 Introduction to Promela. Promela and Spin Promela - process meta language G. Holzmann, Bell Labs (Lucent) C-like language + concurrency dyamic.
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
Variants of LTL Query Checking Hana ChocklerArie Gurfinkel Ofer Strichman IBM Research SEI Technion Technion - Israel Institute of Technology.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Automatic Verification
An explicit state model checker
Linear Time Properties
COMP60621 Designing for Parallelism
Presentation transcript:

CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan

LTL Properties  Büchi automata [Vardi and Wolper LICS 86] Büchi automata: Finite state automata that accept infinite strings –The better known variant of finite state automata accept finite strings (used in lexical analysis for example) A Büchi automaton accepts a string when the corresponding run visits an accepting state infinitely often –Note that an infinite run never ends, so we cannot say that an accepting run ends at an accepting state LTL properties can be translated to Büchi automata –The automaton accepts a path if and only if the path satisfies the corresponding LTL property

LTL Properties  Büchi automata G p p pp true F p p pp true G (F p) p The size of the property automaton can be exponential in the size of the LTL formula (recall the complexity of LTL model checking) pp pp p

Büchi Automata: Language Emptiness Check Given a Buchi automaton, one interesting question is: –Is the language accepted by the automaton empty? i.e., does it accept any string? A Büchi automaton accepts a string when the corresponding run visits an accepting state infinitely often To check emptiness: –Look for a cycle which contains an accepting state and is reachable from the initial state Find a strongly connected component that contains an accepting state, and is reachable from the initial state –If no such cycle can be found the language accepted by the automaton is empty

LTL Model Checking Generate the property automaton from the negated LTL property Generate the product of the property automaton and the transition system Show that there is no accepting cycle in the product automaton (check language emptiness) –i.e., show that the intersection of the paths generated by the transition system and the paths accepted by the (negated) property automaton is empty If there is a cycle, it corresponds to a counterexample behavior that demonstrates the bug

LTL Model Checking Example G q Each state is labeled with the propositions that hold in that state Example transition system Property to be verified Negation of the property  G q  F  q Property automaton for the negated property q qq true p,q qp {q},{p,q} , {p} ,{p},{q}, {p,q} 12 Equivalently

Transition System to Buchi Automaton Translation Each state is labeled with the propositions that hold in that state Example transition systemCorresponding Buchi automaton {p,q} {p} {q} {p,q} {q} i 1 23 p,q qp

{p,q} {p} {q} {p,q} {q} {q},{p,q} , {p} ,{p},{q}, {p,q} Product automaton {p,q} {p} {q} {p,q} 1,1 2,1 3,1 4,2 {q} 3,2 {p} Buchi automaton for the transition system (every state is accepting) Property Automaton Accepting cycle: (1,1), (2,1), (3,1), ((4,2), (3,2))  Corresponds to a counter-example path for the property G q

SPIN [Holzmann 91, TSE 97] Explicit state model checker Finite state Temporal logic: LTL Input language: PROMELA –Asynchronous processes –Shared variables –Message passing through (bounded) communication channels –Variables: boolean, char, integer (bounded), arrays (fixed size) –Structured data types

SPIN Verification in SPIN Uses the LTL model checking approach Constructs the product automaton on-the-fly –It is possible to find an accepting cycle (i.e. a counter- example) without constructing the whole state space Uses a nested depth-first search algorithm to look for an accepting cycle Uses various heuristics to improve the efficiency of the nested depth first search: –partial order reduction –state compression

Example Mutual Exclusion Protocol Process 1: while (true) { out: a := true; turn := true; wait: await (b = false or turn = false); cs: a := false; } || Process 2: while (true) { out: b := true; turn := false; wait: await (a = false or turn); cs: b := false; } Two concurrently executing processes are trying to enter a critical section without violating mutual exclusion

Example Mutual Exclusion Protocol in Promela #define cs1 #define cs2 #define wait1 #define wait2 #define true 1 #define false 0 bool a; bool b; bool turn; proctype process1() { out: a = true; turn = true; wait: (b == false || turn == false); cs: a = false; goto out; } proctype process2() { out: b = true; turn = false; wait: (a == false || turn == true); cs: b = false; goto out; } init { run process1(); run process2() }

Property automaton generation % spin -f "! [] (! (cs1 && cs2))“ never { /* ! [] (! (cs1 && cs2)) */ T0_init: if :: ((cs1) && (cs2)) -> goto accept_all :: (1) -> goto T0_init fi; accept_all: skip } % spin -f "!([](wait1 -> <>(cs1)))“ never { /* !([](wait1 -> <>(cs1))) */ T0_init: if :: ( !((cs1)) && (wait1) ) -> goto accept_S4 :: (1) -> goto T0_init fi; accept_S4: if :: (! ((cs1))) -> goto accept_S4 fi; } Concatanate the generated never claims to the end of the specification file Input formula “[]” means G “<>” means F “spin –f” option generates a Buchi automaton for the input LTL formula

SPIN “spin –a mutex.spin” generates a C program “pan.c” from the specification file –This C program implements the on-the-fly nested-depth first search algorithm –You compile “pan.c” and run it to the model checking Spin generates a counter-example trace if it finds out that a property is violated

%mutex -a warning: for p.o. reduction to be valid the never claim must be stutter-invariant (never claims generated from LTL formulae are stutter-invariant) (Spin Version October 2005) + Partial Order Reduction Full statespace search for: never claim + assertion violations + (if within scope of claim) acceptance cycles + (fairness disabled) invalid end states - (disabled by never claim) State-vector 28 byte, depth reached 33, errors: 0 22 states, stored 15 states, matched 37 transitions (= stored+matched) 0 atomic steps hash conflicts: 0 (resolved) memory usage (Mbyte) unreached in proctype process1 line 18, state 6, "-end-" (1 of 6 states) unreached in proctype process2 line 27, state 6, "-end-" (1 of 6 states) unreached in proctype :init: (0 of 3 states)

Automata Theoretic LTL Model Checking Input: A transition system T and an LTL property f Translate the transition system T to a Buchi automaton A T Negate the LTL property and translate the negated property  f to a Buchi automaton A  f Check if the intersection of the languages accepted by A T and A  f is empty –Is L(A T )  L(A  f ) =  ? –If L(A T )  L(A  f )  , then the transition system T violates the property f

Automata Theoretic LTL Model Checking Note that –L(A T )  L(A  f ) =  if and only if L(A T )  L(A f ) By negating the property f we are converting language subsumption check to language intersection followed by language emptiness check Given the Buchi automata A T and A  f we will construct a product automaton A T  A  f such that – L(A T  A  f ) = L(A T )  L(A  f ) So all we have to do is to check if the language accepted by the Buchi automaton A T  A  f is empty

Buchi Automata A Buchi automaton is a tuple A = ( , Q, , Q 0, F) where  is a finite alphabet Q is a finite set of states   Q    Q is the transition relation Q 0  Q is the set of initial states F  Q is the set of accepting states A Buchi automaton A recognizes a language which consists of infinite words over the alphabet  L(A)      denotes the set of infinite words over the alphabet 

Buchi Automaton Given an infinite word w    where w = a 0, a 1, a 2, … a run r of the automaton A over w is an infinite sequence of automaton states r = q 0, q 1, q 2, … where q 0  Q 0 and for all i  0, (q i,a i,q i+1 )   Given a run r, let inf(r)  Q be the set of automata states that appear in r infinitely many times A run r is an accepting run if and only if inf(r)  F   i.e., a run is an accepting run if some accepting states appear in r infinitely many times

Transition System to Buchi Automaton Translation Given a transition system T = (S, I, R) a set of atomic propositions AP and a labeling function L : S  AP  {true, false} the corresponding Buchi automaton A T = (  T, Q T,  T, Q 0T, F T )  T = 2 AP an alphabet symbol corresponds to a set of atomic propositions Q T = S  {i}i is a new state which is not in S Q oT = {i}i is the only initial state F T = S  {i}all states of A T are accepting states  T is defined as follows: (s,a,s’)   iff either (s,s’)  R and p  a iff L(s’,p) = true or s=i and s’  I and p  a iff L(s’,p) = true

Transition System to Buchi Automaton Translation Each state is labeled with the propositions that hold in that state Example transition systemCorresponding Buchi automaton {p,q} {p} {q} {p,q} {q} i 1 23 p,q qp

Generalized Buchi Automaton A generalized Buchi automaton is a tuple A = ( , Q, , Q 0, F) where  is a finite alphabet Q is a finite set of states   Q    Q is the transition relation Q 0  Q is the set of initial states F  2 Q is sets of accepting states i.e., F = {F 1, F 2, …, F k } where F i  Q for 1  i  k Given a generalized Buchi automaton A, a run r is an accepting run if and only if –for all 1  i  k, inf(r)  F i   This is different than the standard definition

Buchi Automata Product Given A 1 = ( , Q 1,  1, Q 01, F 1 ) and A 2 = ( , Q 2,  2, Q 02, F 2 ) the product automaton A 1  A 2 = ( , Q, , Q 0, F) is defined as: Q = Q 1  Q 2 Q 0 = Q 01  Q 02 F = {F 1  Q 2, Q 1  F 2 }(a generalized Buchi automaton)  is defined as follows: ((q 1,q 2 ),a,(q 1 ’,q 2 ’))   iff (q 1,a,q 1 ’)   1 and (q 2,a,q 2 ’)   2 Based on the above construction, we get L(A 1  A 2 ) = L(A 1 )  L(A 2 )

Buchi automaton 1 {p,q} {p} {q} {p,q} {q} {q},{p,q} , {p} ,{p},{q}, {p,q} Buchi automaton Product automaton {p,q} {p} {q} {p,q} 1,1 2,1 3,1 4,2 {q} 3,2 {p} Example from the Last Lecture is a Special Case Since all the states in the automaton 1 is accepting, only the accepting states of automaton 2 decide the accepting states of the product automaton

Buchi Automata Product Example ab r1 r2 b a ba q1 q2 a b L(R) = (b * a)  Automaton RAutomaton Q L(Q) = (a * b)  r1,q1 Automaton R  Q L(R  Q) = L(R)  L(Q) r2,q1 r1,q2r2,q2 F = { {(r1,q1), (r1,q2)}, {(r1,q1), (r2,q1)} } b b b b a a a a

Generalized to Standard Buchi Automata Conversion Given a generalized Buchi automaton A = ( , Q, , Q 0, F) where F = {F 1, F 2, …, F k } it is equivalent to standard Buchi automaton A’ = ( , Q’,  ’, Q 0 ’, F’) where Q’ = Q  {1, 2, …, k} Q 0 ’ = Q 0  {1} F’ = F 1  {1}  ’ is defined as follows: ((q 1, i), a, (q 2, j))   ’ iff (q 1,a,q 2 )   and j=i if q 1  F i j=(i mod k) + 1 if q 1  F i Based on the above construction we have L(A’) = L(A) Keep a counter. When the counter is i look only for the accepting states in F i. When you see a state from F i, increment the counter (mod k). When the counter makes one round, you have seen an accepting state from all F i s.

Example (Cont’d) q1 A generalized Buchi automaton G q2 q3q4 F = { {q1, q3}, {q1, q2} } b b b b a a a a q1,1 q2,1 q3,1 q4,1 q1,2 q2,2 q3,2 q4,2 b b b a aab b a a b a a F = { (q1,1), (q3,1)} b a b A standard Buchi automaton S where L(S) = L(G)