CSEP590 – Model Checking and Software Verification University of Washington Department of Computer Science and Engineering Summer 2003.

Slides:



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

The Quest for Correctness Joseph Sifakis VERIMAG Laboratory 2nd Sogeti Testing Academy April 29th 2009.
Copyright 2000 Cadence Design Systems. Permission is granted to reproduce without modification. Introduction An overview of formal methods for hardware.
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Automatic Verification Book: Chapter 6. How can we check the model? The model is a graph. The specification should refer the the graph representation.
Auto-Generation of Test Cases for Infinite States Reactive Systems Based on Symbolic Execution and Formula Rewriting Donghuo Chen School of Computer Science.
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.
Algorithmic Software Verification VII. Computation tree logic and bisimulations.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
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.
Planning based on Model Checking Dept. of Information Systems and Applied CS Bamberg University Seminar Paper Svetlana Balinova.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
ECE Synthesis & Verification - L271 ECE 697B (667) Spring 2006 Synthesis and Verification of Digital Systems Model Checking basics.
Model Checking I What are LTL and CTL?. and or dreq q0 dack q0bar.
Timed Automata.
Efficient Reachability Analysis for Verification of Asynchronous Systems Nishant Sinha.
Verification of Hybrid Systems An Assessment of Current Techniques Holly Bowen.
Chair of Software Engineering Software Verification Stephan van Staden Lecture 10: Model Checking.
SYMBOLIC MODEL CHECKING: STATES AND BEYOND J.R. Burch E.M. Clarke K.L. McMillan D. L. Dill L. J. Hwang Presented by Rehana Begam.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Software Reliability CIS 640 Adapted from the lecture notes by Doron Pelel (
1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture 05.
Demonstration Of SPIN By Mitra Purandare
Tele Design of Reactive Systems Summer 2001 Prof. Dr. Stefan Leue Institute for Computer Science Albert-Ludwigs-Universität Freiburg
Model Checking. Used in studying behaviors of reactive systems Typically involves three steps: Create a finite state model (FSM) of the system design.
Lecture 4&5: Model Checking: A quick introduction Professor Aditya Ghose Director, Decision Systems Lab School of IT and Computer Science University of.
Algorithms and Problem Solving. Learn about problem solving skills Explore the algorithmic approach for problem solving Learn about algorithm development.
Embedded Systems Laboratory Department of Computer and Information Science Linköping University Sweden Formal Verification and Model Checking Traian Pop.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
CS 267: Automated Verification Lecture 13: Bounded Model Checking Instructor: Tevfik Bultan.
Formal verification Marco A. Peña Universitat Politècnica de Catalunya.
Formal Verification of SpecC Programs using Predicate Abstraction Himanshu Jain Daniel Kroening Edmund Clarke Carnegie Mellon University.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 4: SMT-based Bounded Model Checking of Concurrent Software.
MCAI 2.0 Model Checking in Ten Minutes Edmund Clarke School of Computer Science Carnegie Mellon University.
Grand Challenge Problem: Model Check Concurrent Software Edmund M. Clarke Department of Computer Science Carnegie Mellon University.
Lecture 1: Model Checking
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
CS6133 Software Specification and Verification
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
1 CSEP590 – Model Checking and Automated Verification Lecture outline for August 6, 2003.
Recognizing safety and liveness Presented by Qian Huang.
- 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Validation - Formal verification -
Model Checking Overview Edmund M. Clarke, Jr. School of Computer Science Carnegie Mellon University Pittsburgh, PA
Verification & Validation By: Amir Masoud Gharehbaghi
CSCI1600: Embedded and Real Time Software Lecture 28: Verification I Steven Reiss, Fall 2015.
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.
Program Correctness. The designer of a distributed system has the responsibility of certifying the correctness of the system before users start using.
CS357 Lecture 13: Symbolic model checking without BDDs Alex Aiken David Dill 1.
Bounded Model Checking A. Biere, A. Cimatti, E. Clarke, Y. Zhu, Symbolic Model Checking without BDDs, TACAS’99 Presented by Daniel Choi Provable Software.
From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic Analysis Elsa L Gunter NJIT.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
CS5270 Lecture 41 Timed Automata I CS 5270 Lecture 4.
Survey on the Formal Verification Dept. of Nuclear and Quantum Engineering NICIEL Myung Jun Song.
Complexity of Compositional Model Checking of Computation Tree Logic on Simple Structures Krishnendu Chatterjee Pallab Dasgupta P.P. Chakrabarti IWDC 2004,
Presentation Title 2/4/2018 Software Verification using Predicate Abstraction and Iterative Refinement: Part Bug Catching: Automated Program Verification.
Basic concepts of Model Checking
Algorithms and Problem Solving
Formal methods: Lecture
Formal Methods: Model Checkers and Theorem Provers
CIS 842: Specification and Verification of Reactive Systems
Automatic Verification
Automatic Verification of Industrial Designs
CSCI1600: Embedded and Real Time Software
Algorithms and Problem Solving
10 Design Verification and Test
Presentation transcript:

CSEP590 – Model Checking and Software Verification University of Washington Department of Computer Science and Engineering Summer 2003

Administration Instructor David Richardson Office: Sieg C112 Office hours: After class on Wed. TA Evan Wellbourne Office: ?? Office hours: TBD

Administration(2) Class Time Wednesday, 6:30-9:20pm EE1-037 (this may change…) Format 80 min lecture, 20 min break, 80 min lecture, 10 min open questions. Web: Be sure to signup for the csep590 mailing list (see web for details)

Course Work Your grade will be based on the following Weekly homework assignments (some may be biweekly and more project-based) Final Exam (last day of class) Other?? A few paper reviews

What is Model Checking? Unfortunately, no…. This kind of model??

What is Model Checking?(2) Model checking is an automatic verification technique for finite state concurrent systems. Set of components that execute together Developed independently by Clarke and Emerson and by Queille and Sifakis in early 1980’s. Protocols (digital circuits, more recently software) modeled as state-transition systems. Specifications are a formula f in propositional temporal logic. Verification procedure: exhaustive (but efficient) search of the state space of the design to see if model satisfies f.

A Small Example Consider a system: simple microwave oven States of the system correspond to values of 3 boolean variables: Either door is closed or not closed Either microwave is running or it is stopped Either the food in the microwave is warm or it is cold

A Small Example(2) Model microwave as a simple transition system ~running ~closed ~hot running closed ~hot running closed hot ~running closed hot

A Small Example(3) Using Temporal Logic, one can say Specification: microwave doesn’t heat the food up until the door is closed => ~hot holds until closed Formula f = (~hot) U closed Given f and model, model checking can return whether or not the model satisfies f If not, a counterexample is returned, showing a path of execution whereby the system fails to satisfy the formula

A Small Example(4) Clearly, this example is too basic to be of any use However, the general idea remains the same

Advantages of Model Checking No proofs (as with theorem provers or proof checkers) Procedure is completely automatic. Fast (linear in size of model and in size of specification) Counterexamples Partial specifications allowed Logic is very expressive: allows for easy modeling of real-world protocols

Disadvantages of Model Checking State explosion: if modeled system has many components that can transition in parallel. => number of states can grow exponentially with number of processes (size of system) Data paths Variables in the model can take on a potentially infinite number of values

Can this problem be fixed? Much work has been done recently 1987: Ken McMillan developed a symbolic model checking approach where the system was represented using Binary Decision Diagrams Data structure for representing boolean functions Concise representations for transition systems, fast manipulation Good for synchronous systems Partial Order Reduction: reduce number of states that must be explicitly enumerated Good for asynchronous systems Other techniques (we’ll see some later in course)

Today’s Model Checkers Can handle systems with between 100 and 300 state variables Systems with reachable states have been checked! Using appropriate abstraction techniques, systems with an essentially unbounded number of states can be checked

A Brief History of Automatic Verification Goal: automatic verification of systems In the beginning….there were just input-output systems Correctness: partial correctness + termination Semantics: input-output relation Specification language: propositional logic

History(2) In the late 1960’s – Reactive systems Don’t compute anything React to user input, don’t terminate (event loop) Termination can be bad! - Deadlock Correctness: safety + progress + fairness +… Semantics: Kripke Structures, transition systems (~automata) Specification language: temporal logic

History(3) Temporal logic Formalized in early 20 th Century Primitives: always, sometimes, until, since… 1977: Pnueli decides to use temporal logic as a specification language System satisfying a property corresponds to Kripke structure being a model of temporal formula

History(4) How automate? Given a reactive system S and a temporal formula f, give an algorithm to determine if S satisfies f. Late 1970’s, early 1980’s: reduced to proof systems Give a proof system for checking validity in the logic Extract from S a set of formulas F Prove that F  f is valid using proof system Doesn’t work, too expensive.

History(5) Early 1980’s: reduction to model checking problem Construct Kripke structure K of S Check if K is a model of f As we saw, the problem is state explosion (but people are making it better all the time)

History(6) 1990’s – present Industrial applications Success in hardware verification Groups in all major companies (IBM, Lucent, Intel, Microsoft, Motorola, Siemens…) Many commercial and non-commercial tools Extensions into software systems!! (holy grail) As leading professionals in top industries, this topic should hopefully be interesting to you

History(7) A few success stories 1992 – SMV system at CMU used to verify the IEEE Future+ cache coherence protocol Found actual errors in an IEEE standard! 1995 – Concurrency Workbench analyzed active structural control system to make buildings more resistent to earthquakes Timing error found that could cause controller to worsen, NOT dampen vibrations experienced during an earthquake And there are many, many others for hardware and protocol verification

Software Verification Why is this so freaking hard?? Data Asynchronous behavior Hmmm, this smells a lot like the halting problem….? Nonetheless, we’ll examine it in the course

Software Verification(2) What is being done? Use partial order reduction to reduce the number of states that are generated Used by VeriSoft Applications to Java Use static analysis to extract a finite state synchronization skeleton from the program, model check the result Bandera – Kansas State Java PathFinder – NASA Ames Slam Project (Bebop) - Microsoft