Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:

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.
Translating from logic to automata Book: Chapter 6.
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.
Two algorithms for checking emptiness. How to check for emptiness? Is L (A) = ; ? Need to check if there exists an accepting computation (passes through.
CS 267: Automated Verification Lecture 2: Linear vs. Branching time. Temporal Logics: CTL, CTL*. CTL model checking algorithm. Counter-example generation.
M ODEL CHECKING -Vasvi Kakkad University of Sydney.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Partial Order Reduction: Main Idea
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.
CS 290C: Formal Models for Web Software Lecture 3: Verification of Navigation Models with the Spin Model Checker Instructor: Tevfik Bultan.
ECE Synthesis & Verification - L271 ECE 697B (667) Spring 2006 Synthesis and Verification of Digital Systems Model Checking basics.
PROTOCOL VERIFICATION & PROTOCOL VALIDATION. Protocol Verification Communication Protocols should be checked for correctness, robustness and performance,
Temporal Logic and the NuSMV Model Checker CS 680 Formal Methods Jeremy Johnson.
1 1 CDT314 FABER Formal Languages, Automata and Models of Computation Lecture 3 School of Innovation, Design and Engineering Mälardalen University 2012.
Timed Automata.
1 Partial Order Reduction. 2 Basic idea P1P1 P2P2 P3P3 a1a1 a2a2 a3a3 a1a1 a1a1 a2a2 a2a2 a2a2 a2a2 a3a3 a3a3 a3a3 a3a3 a1a1 a1a1 3 independent processes.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
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.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Software Reliability CIS 640 Adapted from the lecture notes by Doron Pelel (
1 Introduction to Computability Theory Lecture12: Decidable Languages Prof. Amos Israeli.
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.
1 Carnegie Mellon UniversitySPINFlavio Lerda SPIN An explicit state model checker.
Temporal Logic and Model Checking. Reactive Systems We often classify systems into two types: Transformational: functions from inputs available at the.
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.
1 Completeness and Complexity of Bounded 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.
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 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.
Linear and Branching Time Safety, Liveness, and Fairness
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: Sequencing Properties Copyright , Matt Dwyer, John Hatcliff,
Automatic Verification of Finite-State Concurrent Systems Using Temporal Logic Specifications 1.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: LTL Model Checking Copyright , Matt Dwyer, John Hatcliff,
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Copyright , Doron Peled and Cesare Tinelli. These notes are based on a set of lecture notes originally developed by Doron Peled at the University.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Memory-Efficient Algorithms for the Verification of Temporal Properties C. Courcoubetis Inst. Of Comp. Sci. FORTH, Crete, Greece M. Verdi IBM Almaden P.
Recognizing safety and liveness Presented by Qian Huang.
Verification & Validation By: Amir Masoud Gharehbaghi
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Translating from logic to automata (Book: Chapter 6)
1 CSEP590 – Model Checking and Automated Verification Lecture outline for July 9, 2003.
CS357 Lecture 13: Symbolic model checking without BDDs Alex Aiken David Dill 1.
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.
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.
Model Checking Lecture 2 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
15-820A 1 LTL Model Checking A Flavio Lerda.
Formal Methods: Model Checkers and Theorem Provers
Automatic Verification
An explicit state model checker
Presentation transcript:

Automatic Verification Book: Chapter 6

What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive: theorem proving Practical view: automated systematic debugging VERY good at finding errors!

How can we check the model? The model is a graph. The specification should refer to the graph representation. Apply graph theory algorithms.

What properties can we check? Invariants: a property that need to hold in each state. Deadlock detection: can we reach a state where the program is blocked? Dead code: does the program have parts that are never executed.

How to perform the checking? Apply a search strategy (Depth first search, Breadth first search). Check states/transitions during the search. If property does not hold, report counter example!

If it is so good, is this all we need? Model checking works only for finite state systems. Would not work with Unconstrained integers. Unbounded message queues. General data structures: queues trees stacks Parametric algorithms and systems.

The state space explosion Need to represent the state space of a program in the computer memory. Each state can be as big as the entire memory! Many states: Each integer variable has 2^32 possibilities. Two such variables have 2^64 possibilities. In concurrent protocols, the number of states usually grows exponentially with the number of processes.

If it is so constrained, is it of any use? Many protocols are finite state. Many programs or procedure are finite state in nature. Can use abstraction techniques. Sometimes it is possible to decompose a program, and prove part of it by model checking and part by theorem proving. Many techniques to reduce the state space explosion (BDDs, Partial Order Reduction).

Depth First Search Program DFS For each s such that Init(s) dfs(s) end DFS Procedure dfs(s) for each s’ such that R(s,s’) do If new(s’) then dfs(s’) end dfs.

Start from an initial state q3 q4 q2 q1 q5 q1 Stack: Hash table:

Continue with a successor q3 q4 q2 q1 q5 q1 q2 q1 q2 Stack: Hash table:

One successor of q2. q3 q4 q2 q1 q5 q1 q2 q4 q1 q2 q4 Stack: Hash table:

Backtrack to q2 (no new successors for q4). q3 q4 q2 q1 q5 q1 q2 q4 q1 q2 Stack: Hash table:

Backtracked to q1 q3 q4 q2 q1 q5 q1 q2 q4 q1 Stack: Hash table:

Second successor to q1. q3 q4 q2 q1 q5 q1 q2 q4 q3 q1 q3 Stack: Hash table:

Backtrack again to q1. q3 q4 q2 q1 q5 q1 q2 q4 q3 q1 Stack: Hash table:

How can we check properties with DFS? Invariants: check that all reachable states satisfy the invariant property. If not, show a path from an initial state to a bad state. Deadlocks: check whether a state where no process can continue is reached. Dead code: as you progress with the DFS, mark all the transitions that are executed at least once.

[] ¬ (PC0=CR0/\PC1=CR1) is an invariant! Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 NC0,L1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,L1 Turn=1 L0,CR1 Turn=1 NC0,CR1 Turn=1 L0,NC1 Turn=1 NC0,NC1 Turn=1 NC0,L1 Turn=1 L0,L1

Want to do more! Want to check more properties. Want to have a uniform algorithm to deal with all kinds of properties. This is done by writing specification is temporal logics. Temporal logic specification can be translated into graphs (finite automata).

[](Turn=0 --> <>Turn=1) Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 NC0,L1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,L1 Turn=1 L0,CR1 Turn=1 NC0,CR1 Turn=1 L0,NC1 Turn=1 NC0,NC1 Turn=1 NC0,L1 Turn=1 L0,L1

Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 NC0,L1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,L1 Turn=1 L0,CR1 Turn=1 NC0,CR1 Turn=1 L0,NC1 Turn=1 NC0,NC1 Turn=1 NC0,L1 Turn=1 L0,L1 init

Turn=0 L0,L1 Turn=1 L0,L1 init Add an additional initial node. Propositions are attached to incoming nodes. All nodes are accepting. Turn=1 L0,L1 Turn=0 L0,L1

Correctness condition We want to find a correctness condition for a model to satisfy a specification. Language of a model: L(Model) Language of a specification: L(Spec). We need: L(Model)  L(Spec).

Correctness All sequences Sequences satisfying Spec Program executions

How to prove correctness? Show that L(Model)  L(Spec). Equivalently: ______ Show that L(Model)  L(Spec) = Ø. Also: can obtain L(Spec) by translating from LTL!

What do we need to know? How to intersect two automata? How to complement an automaton? How to translate from LTL to an automaton?

Intersecting two automata A1= and A2= Each state is a pair (x,y): a state x from S1 and a state y from S1. Initial states: x is from I1 and y is from I2. Accepting states: x is from F1. ((x,y) a (x’,y’)) is a transition if (x,a,x’) is in  1, and (y,a,y’) is in  2.

Example A B CT0 T1 A A B,C S0 S1 States: (S0,T0), (S0,T1), (S1,T0), (S1,T1). Accepting: (S0,T0), (S0,T1). Initial: (S0,T0).

A B CT0 T1 A A B,C S0 S1 S0,T0 S0,T1 S1,T1 S1,T0 B B A C A C

How to check for emptiness? S0,T0 S0,T1 S1,T1 S1,T0 B B A C A C

Emptiness... Need to check if there exists an accepting run (passes through an accepting state infinitely often).

Finding accepting runs If there is an accepting run, then at least one accepting state repeats on it forever. This state appears on a cycle. So, find a reachable accepting state on a cycle.

Equivalently... A strongly connected component: a set of nodes where each node is reachable by a path from each other node. Find a reachable strongly connected component with an accepting node.

How to complement? Complementation is hard! Can ask for the negated property (the sequences that should never occur). Can translate from LTL formula  to automaton A, and complement A. But: can translate ¬  into an automaton directly!

From LTL to automata “always eventually p”: []<>p “always p until q”: [](pUq) Exponential blow-up Formulas are usually small p q p\/q p true

Model Checking under Fairness Express the fairness as a property φ. To prove a property ψ under fairness, model check φ  ψ. Fair (φ) Bad (¬ψ)Program Counter example

[](Turn=0 --> <>Turn=1) Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 NC0,L1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,L1 Turn=1 L0,CR1 Turn=1 NC0,CR1 Turn=1 L0,NC1 Turn=1 NC0,NC1 Turn=1 NC0,L1 Turn=1 L0,L1

Model Checking under Fairness Specialize model checking. For weak process fairness: search for a reachable strongly connected component, where for each process P either it contains on occurrence of a transition from P, or it contains a state where P is disabled.