Linear Temporal Logic. Model Checking and. Based on slides developed by Natasha Sharygina. Carnegie Mellon University.

Similar documents
Formal Verification by Model Checking

Formal Verification by Model Checking

Model checking Timber program. Paweł Pietrzak

Lecture1: Symbolic Model Checking with BDDs. Edmund M. Clarke, Jr. Computer Science Department Carnegie Mellon University Pittsburgh, PA 15213

Sérgio Campos, Edmund Clarke

Tool demonstration: Spin

System Correctness. EEC 421/521: Software Engineering. System Correctness. The Problem at Hand. A system is correct when it meets its requirements

Distributed Systems Programming (F21DS1) Formal Verification

Double Header. Two Lectures. Flying Boxes. Some Key Players: Model Checking Software Model Checking SLAM and BLAST

Design and Analysis of Distributed Interacting Systems

Model Checking with Automata An Overview

Formal Methods for Software Development

Formal Methods in Software Engineering. Lecture 07

THE MODEL CHECKER SPIN

Computer Lab 1: Model Checking and Logic Synthesis using Spin (lab)

The Spin Model Checker : Part I/II

Algorithmic Verification. Algorithmic Verification. Model checking. Algorithmic verification. The software crisis (and hardware as well)

INF672 Protocol Safety and Verification. Karthik Bhargavan Xavier Rival Thomas Clausen

The SPIN Model Checker

Lecture 1: Model Checking. Edmund Clarke School of Computer Science Carnegie Mellon University

Software Engineering using Formal Methods

T Reactive Systems: Kripke Structures and Automata

Design of Internet Protocols:

Model-Checking Concurrent Systems. The Model Checker Spin. The Model Checker Spin. Wolfgang Schreiner

Research Collection. Formal background and algorithms. Other Conference Item. ETH Library. Author(s): Biere, Armin. Publication Date: 2001

SPIN part 2. Verification with LTL. Jaime Ramos. Departamento de Matemática, Técnico, ULisboa

More on Verification and Model Checking

Computer Aided Verification 2015 The SPIN model checker

Patrick Trentin Formal Methods Lab Class, March 03, 2017

4/6/2011. Model Checking. Encoding test specifications. Model Checking. Encoding test specifications. Model Checking CS 4271

Distributed Systems Programming (F21DS1) SPIN: Formal Analysis II

Formal Specification and Verification

Lecture 3 SPIN and Promela

Promela and SPIN. Mads Dam Dept. Microelectronics and Information Technology Royal Institute of Technology, KTH. Promela and SPIN

Model-Checking Concurrent Systems

Timo Latvala. January 28, 2004

Model Checking. Dragana Cvijanovic

Formal Specification and Verification

Model Checking with Abstract State Matching

Software Engineering using Formal Methods

Software Model Checking: Theory and Practice

What is SPIN(Simple Promela Interpreter) Material About SPIN. Elements of Promela. Basic Variables and Types. Typical Structure of Promela Model

Network Protocol Design and Evaluation

Applications of Formal Verification

Introduction to Linear-Time Temporal Logic. CSE 814 Introduction to LTL

CSC2108: Automated Verification Assignment 1 - Solutions

Patrick Trentin Formal Methods Lab Class, Feb 26, 2016

The Design of a Distributed Model Checking Algorithm for Spin

Applications of Formal Verification

A Theory of Consistency for Modular Synchronous Systems

Applications of Formal Verification

The Maude LTL Model Checker and Its Implementation

What is SPIN(Simple Promela Interpreter) Elements of Promela. Material About SPIN. Basic Variables and Types. Typical Structure of Promela Model

Network Protocol Design and Evaluation

The ComFoRT Reasoning Framework

Copyright 2008 CS655 System Modeling and Analysis. Korea Advanced Institute of Science and Technology

Automated Reasoning. Model Checking with SPIN (II)

WHEN concurrent processes share a resource such as a file

The SPIN Model Checker

SPIN: Introduction and Examples

Introduction to Model Checking

Model Checking. Automatic Verification Model Checking. Process A Process B. when not possible (not AI).

INF5140: Specification and Verification of Parallel Systems

Distributed Systems Programming (F21DS1) SPIN: Formal Analysis I

LTL Reasoning: How It Works

CS477 Formal Software Development Methods / 32

COMP 763. Eugene Syriani. Ph.D. Student in the Modelling, Simulation and Design Lab School of Computer Science. McGill University

SPIN, PETERSON AND BAKERY LOCKS

CS477 Formal Software Development Methods / 39

Introduction to Software Verification

Multi-Threaded System int x, y, r; int *p, *q, *z; int **a; EEC 421/521: Software Engineering. Thread Interleaving SPIN. Model Checking using SPIN

Software Model Checking. From Programs to Kripke Structures

Building Graphical Promela Models using UPPAAL GUI

Introduction In Practice State Explosion Problem Infinity and Uncomputability Techniques References. Model Checking. Toryn Qwyllyn Klassen

Property Specifications

Automatic Verification of Finite State Concurrent Systems

Verifying IP-Core based System-On-Chip Designs

SPIN: Part /614 Bug Catching: Automated Program Verification. Sagar Chaki November 12, Carnegie Mellon University

Formal modelling and verification in UPPAAL

Overview. Discrete Event Systems - Verification of Finite Automata. What can finite automata be used for? What can finite automata be used for?

Despite some help from modeling tools such as UML, the problem of ensuring the quality of. 1 of :30 AM

Computer Lab 1: Model Checking and Logic Synthesis using Spin (lab)

FORMAL METHODS IN NETWORKING COMPUTER SCIENCE 598D, SPRING 2010 PRINCETON UNIVERSITY LIGHTWEIGHT MODELING IN PROMELA/SPIN AND ALLOY

Lecture 2: Symbolic Model Checking With SAT

The Spin Model Checker : Part I. Moonzoo Kim KAIST

Tutorial on Model Checking Modelling and Verification in Computer Science

Scenario Graphs Applied to Security (Summary Paper)

Model checking and timed CTL

A Tutorial on Model Checker SPIN

A Verification Approach for GALS Integration of Synchronous Components

A Case Study for CTL Model Update

Having a BLAST with SLAM

The UPPAAL Model Checker. Julián Proenza Systems, Robotics and Vision Group. UIB. SPAIN

Using Spin to Help Teach Concurrent Programming

Reducing Fair Stuttering Refinement of Transaction Systems

Verification of Intelligent Software

Proving Dekker with SPIN and PROMELA

Monitoring Interfaces for Faults

Mapping of UML Diagrams to Extended Petri Nets for Formal Verification

On Nested Depth First Search

Transcription:

Model Checking and Linear Temporal Logic Jonathan Aldrich Carnegie Mellon University Based on slides developed by Natasha Sharygina 17-654: Analysis of Software Artifacts 1

Formal Verification by Model Checking Domain: Continuously operating concurrent systems (e.g. operating systems, hardware controllers and network protocols) Ongoing, reactive semantics Non-terminating, infinite computations Manifest non-determinism Instrument: Temporal logic [Pnueli 77] is a formalism for reasoning about behavior of reactive systems 2

Motivation: What can be Verified? Architecture Will these two components interact properly? Allen and Garlan: Wright system checks architectures for deadlock Code Am I using this component correctly? Microsoft s Static Driver Verifier ensures complex device driver rules are followed Substantially reduced Windows blue screens Is my code safe Will it avoid error conditions? Will it be responsive, eventually accepting the next input? Security Is the protocol I m using secure Model checking has found defects in security protocols 3

Temporal Logic Model Checking [Clarke,Emerson 81][Queille,Sifakis 82] Systems are modeled by finite state machines Properties are written in propositional temporal logic Verification procedure is an exhaustive search of the state space of the design Diagnostic counterexamples 4

Temporal Logic Model Checking Finite State Machine Preprocessor Property Model Checker True or Counterexample 5

What is Model Checking? Does model M satisfy a property P? (written M = P) What is M? What is P? What is satisfy? 6

What is M? Example Program: State Transition Diagram precondition: numtickets > 0 reserved = false; while (true) { getquery(); if (numtickets > 0 &&!reserved) reserved = true; if (numtickets > 0 && reserved) { reserved = false; numtickets--; } } nt=3, r=false nt=2, r=false nt=1, r=false nt=0, r=false nt=3, r=true nt=2, r=true nt=1, r=true nt=0, r=true 7

What is M? Example Program: State Transition Diagram precondition: numtickets > 0 reserved = false; while (true) { getquery(); if (numtickets > 0 &&!reserved) reserved = true; if (numtickets > 0 && reserved) { reserved = false; numtickets--; } } nt=3, r=false nt=2, r=false nt=1, r=false nt=0, r=false nt=3, r=true nt=2, r=true nt=1, r=true 8

What is M? Example Program: precondition: numtickets > 0 reserved = false; while (true) { getquery(); if (numtickets > 0 &&!reserved) reserved = true; if (numtickets > 0 && reserved) { reserved = false; numtickets--; } } What is interesting about this? Are tickets available? a Is a ticket reserved? r nt=2, r=false nt=1, r=false nt=0, r=false nt=2, r=true nt=1, r=true 9

What is M? Example Program: precondition: numtickets > 0 reserved = false; while (true) { getquery(); if (numtickets > 0 &&!reserved) reserved = true; if (numtickets > 0 && reserved) { reserved = false; numtickets--; } } What is interesting about this? Are tickets available? a Is a ticket reserved? r a!r a r nt=2, r=false a!r a r!a!r nt=1, r=false nt=0, r=false nt=2, r=true nt=1, r=true 10

What is M? Abstracted Program: fewer states precondition: available == true reserved = false; while (true) { getquery(); if (available &&!reserved) reserved = true; if (available && reserved) { reserved = false; available =?; } } 11

What is M? Abstracted Program: fewer states precondition: available == true reserved = false; while (true) { getquery(); if (available &&!reserved) reserved = true; if (available && reserved) { reserved = false; available =?; } } a!r a r!a!r State Transition Graph or Kripke Model 12!a r

What is M? Abstracted Program: fewer states precondition: available == true reserved = false; while (true) { getquery(); if (available &&!reserved) reserved = true; if (available && reserved) { reserved = false; available =?; } } a!r a r!a!r State Transition Graph or Kripke Model 13

What is M? State: valuations to all variables concrete state: (numtickets=5, reserved=false) abstract state: (a=true, r=false) Initial states: subset of states a!r Arcs: transitions between states Atomic Propositions: a: numtickets > 0 r: reserved = true a r!a!r State Transition Graph or Kripke Model 14

Kripke structure: What is M? M = S, S 0, R, L 15

What is M? M = S, S 0, R, L Kripke structure: S finite set of states 16

What is M? M = S, S 0, R, L Kripke structure: S finite set of states S 0 S set of initial states 17

What is M? M = S, S 0, R, L Kripke structure: S finite set of states S 0 S set of initial states R S S set of arcs 18

What is M? M = S, S 0, R, L a!r Kripke structure: S finite set of states S 0 S set of initial states R S S set of arcs L : S 2 AP mapping from states to a set of atomic propositions a r!a!r 19

Model of Computation a b b c c State Transition Graph Computation Traces Unwind State Graph to obtain traces. A trace is an infinite sequence of states. The semantics of a FSM is a set of traces. 20

Model of Computation a b a b b c c State Transition Graph Computation Traces Unwind State Graph to obtain traces. A trace is an infinite sequence of states. The semantics of a FSM is a set of traces. 21

Model of Computation a b a b b c b c c State Transition Graph Computation Traces Unwind State Graph to obtain traces. A trace is an infinite sequence of states. The semantics of a FSM is a set of traces. 22

Model of Computation a b a b b c b c c a b State Transition Graph Computation Traces Unwind State Graph to obtain traces. A trace is an infinite sequence of states. The semantics of a FSM is a set of traces. 23

Model of Computation a b a b a b b c b c b c c a b c State Transition Graph Computation Traces Unwind State Graph to obtain traces. A trace is an infinite sequence of states. The semantics of a FSM is a set of traces. 24

Model of Computation a b a b a b a b b c b c c b c c a b c c State Transition Graph Computation Traces Unwind State Graph to obtain traces. A trace is an infinite sequence of states. The semantics of a FSM is a set of traces. 25

Model of Computation a b a b b c c b c c a b c c State Transition Graph Infinite Computation Tree Represent all traces with an infinite computation tree 26

What is P? Different kinds of temporal logics Syntax: What are the formulas in the logic? Semantics: What does it mean for model M to satisfy formula P? Formulas: - Atomic propositions: properties of states - Temporal Logic Specifications: properties of traces. 27

Computation Tree Logics Examples: Safety (mutual exclusion): no two processes can be at a critical section at the same time Liveness (absence of starvation): every request will be eventually granted Temporal logics differ according to how they handle branching in the underlying computation tree. Our Focus In a linear temporal logic (LTL), operators are provided for describing system behavior along a single computation path. In a branching-time logic (CTL), the temporal operators quantify over the paths that are possible from a given state. 28

The Logic LTL Linear Time Logic (LTL) [Pnueli 77]: logic of temporal sequences. α: α holds in the current state α Xα: α holds in the next state α Fγ: γ holds eventually γ Gλ: λ holds from now on λ λ λ λ (α Uβ): α holds untilβholds α α β 29

Typical LTL Formulas G (Req F Ack): whenever Request occurs, it will be eventually Acknowledged. G (DeviceEnabled): DeviceEnabled always holds on every computation path. G (F Restart): Fairness: from any state one will eventually get to a Restart state. I.e. Restart states occur infinitely often. G (Reset F Restart): whenever the reset button is pressed one will eventually get to the Restart state. 30

LTL Conventions G is sometimes written F is sometimes written 31

Notation A path π in M is an infinite sequence of states s 0, s 1, such that for every i 0, (s i, s i+1 ) R π i denotes the suffix of π starting at s i M, π f means that f holds along path π in the Kripke structure M 32

p Semantics of LTL Formulas M, π p π=s p L(s) 33

p Semantics of LTL Formulas M, π p π=s p L(s) M, π g M, π g M, π g 1 g 2 M, π g 1 M, π g 2 M, π g 1 g 2 M, π g 1 M, π g 2 34

p g Semantics of LTL Formulas M, π p π=s p L(s) M, π g M, π g M, π g 1 g 2 M, π g 1 M, π g 2 M, π g 1 g 2 M, π g 1 M, π g 2 M, π X g M, π 1 g 35

p g g Semantics of LTL Formulas M, π p π=s p L(s) M, π g M, π g M, π g 1 g 2 M, π g 1 M, π g 2 M, π g 1 g 2 M, π g 1 M, π g 2 M, π X g M, π 1 g M, π F g k 0 M, π k g 36

p g g g Semantics of LTL Formulas M, π p π=s p L(s) M, π g M, π g M, π g 1 g 2 M, π g 1 M, π g 2 M, π g 1 g 2 M, π g 1 M, π g 2 M, π X g M, π 1 g g M, π F g k 0 M, π k g g g M, π G g k 0 M, π k g 37

p Semantics of LTL Formulas M, π p π=s p L(s) g M, π g M, π g M, π g 1 g 2 M, π g 1 M, π g 2 M, π g 1 g 2 M, π g 1 M, π g 2 M, π X g M, π 1 g g M, π F g k 0 M, π k g g g g 1 g 1 g 2 g g M, π G g k 0 M, π k g M, π g 1 U g 2 k 0 M, π k g 2 0 j<k M, π j g 1 38

p Semantics of LTL Formulas M, π p π=s p L(s) g M, π g M, π g M, π g 1 g 2 M, π g 1 M, π g 2 M, π g 1 g 2 M, π g 1 M, π g 2 M, π X g M, π 1 g g M, π F g k 0 M, π k g g g g 1 g 1 g 2 g g M, π G g k 0 M, π k g M, π g 1 U g 2 k 0 M, π k g 2 0 j<k M, π j g 1 g2 must eventually hold semantics of until in English are potentially unclear that s why we have a formal definition 39

Practice Writing Properties If the door is locked, it will not open until someone unlocks it assume atomic predicates locked, unlocked, open If you press ctrl-c, you will get a command line prompt The saw will not run unless the safety guard is engaged 40

Practice Writing Properties If the door is locked, it will not open until someone unlocks it assume atomic predicates locked, unlocked, open G (locked ( open U unlocked)) If you press ctrl-c, you will get a command line prompt G (ctrlc F prompt) The saw will not run unless the safety guard is engaged G ( safety running) 41

LTL Model Checking Example Pressing Start will eventually ~ Start result in heat ~ Close ~ Heat ~ Error Start ~ Close ~ Heat Error ~ Start Close ~ Heat ~ Error Start Close ~ Heat Error Start Close ~ Heat ~ Error ~ Start Close Heat ~ Error Start Close Heat ~ Error 42

LTL Model Checking Example Pressing Start will eventually result in heat G(Start FHeat) ~ Start ~ Close ~ Heat ~ Error Start ~ Close ~ Heat Error ~ Start Close ~ Heat ~ Error Start Close ~ Heat Error Start Close ~ Heat ~ Error ~ Start Close Heat ~ Error Start Close Heat ~ Error 43

LTL Model Checking f (primitive formula) Just check the properties of the current state X f Verify f holds in all successors of the current state G f Find all reachable states from the current state, and ensure f holds in all of them use depth-first or breadth-first search f U g Do a depth-first search from the current state. Stop when you get to a g or you loop back on an already visited state. Signal an error if you hit a state where f is false before you stop. F f Harder. Intuition: look for a path from the current state that loops back on itself, such that f is false on every state in the path. If no such path is found, the formula is true. Reality: use Büchi automata 44

LTL Model Checking Example Pressing Start will eventually result in heat G(Start FHeat) ~ Start ~ Close ~ Heat ~ Error Start ~ Close ~ Heat Error ~ Start Close ~ Heat ~ Error Start Close ~ Heat Error Start Close ~ Heat ~ Error ~ Start Close Heat ~ Error Start Close Heat ~ Error 45

LTL Model Checking Example The oven doesn t heat up until ~ Start the door is closed. ~ Close ~ Heat ~ Error Start ~ Close ~ Heat Error ~ Start Close ~ Heat ~ Error Start Close ~ Heat Error Start Close ~ Heat ~ Error ~ Start Close Heat ~ Error Start Close Heat ~ Error 46

LTL Model Checking Example The oven doesn t heat up until the door is closed. ( Heat) U Close ( Heat) W Close G ( not Closed => not Heat ) ~ Start ~ Close ~ Heat ~ Error Start ~ Close ~ Heat Error ~ Start Close ~ Heat ~ Error Start Close ~ Heat Error Start Close ~ Heat ~ Error ~ Start Close Heat ~ Error Start Close Heat ~ Error 47

Efficient Algorithms for LTL Model Checking Use Büchi automata Beyond the scope of this course Canonical reference on Model Checking: Edmund Clarke, Orna Grumberg, and Doron A. Peled. Model Checking. MIT Press, 1999. 48

SPIN: The Promela Language PROcess MEta LAnguage Asynchronous composition of independent processes Communication using channels and global variables Non-deterministic choices and interleavings 49

Mutual Exclusion Peterson s solution to the mutual exclusion problem flag 0 =1 turn=1 flag 0 =0 flag 1!= 0 && turn!= 0 flag 1 == 0 turn == 0 Critical Section 50

bool turn; Mutual Exclusion in SPIN bool flag[2]; proctype mutex0() { again: flag[0] = 1; turn = 1; flag 0 =1 (flag[1] == 0 turn == 0); /* critical section */ flag[0] = 0; goto again; } turn=1 flag 1!= 0 && turn!= 0 flag 1 == 0 turn == 0 flag 0 =0 Critical Section 51

bool turn; bool flag[2]; proctype mutex0() { Mutual Exclusion in SPIN guard: Cannot go past this point until the condition is true again: flag[0] = 1; turn = 1; flag 0 =1 (flag[1] == 0 turn == 0); /* critical section */ flag[0] = 0; goto again; } turn=1 flag 0 =0 flag 1!= 0 && turn!= 0 flag 1 == 0 turn == 0 Critical Section 52

Mutual Exclusion in SPIN bool turn, flag[2]; active [2] proctype user() { assert(_pid == 0 pid == 1); again: flag[_pid] = 1; turn = 1 - _pid; (flag[1 - _pid] == 0 turn == _pid); /* critical section */ flag[_pid] = 0; goto again; } 53

Mutual Exclusion in SPIN bool turn, flag[2]; Active process: automatically creates instances of processes active [2] proctype user() { assert(_pid == 0 pid == 1); again: flag[_pid] = 1; turn = 1 - _pid; (flag[1 - _pid] == 0 turn == _pid); /* critical section */ flag[_pid] = 0; goto again; } 54

Mutual Exclusion in SPIN bool turn, flag[2]; active [2] proctype user() { assert(_pid == 0 pid == 1); _pid: Identifier of the process again: flag[_pid] = 1; turn = 1 - _pid; (flag[1 - _pid] == 0 turn == _pid); /* critical section */ flag[_pid] = 0; goto again; } 55

Mutual Exclusion in SPIN bool turn, flag[2]; active [2] proctype user() { assert(_pid == 0 pid == 1); again: flag[_pid] = 1; turn = 1 - _pid; (flag[1 - _pid] == 0 turn == _pid); assert: Checks that there are only at most two instances with identifiers 0 and 1 /* critical section */ flag[_pid] = 0; goto again; } 56

Mutual Exclusion in SPIN bool turn, flag[2]; byte ncrit; active [2] proctype user() { ncrit: Counts the number of Process in the critical section assert(_pid == 0 pid == 1); again: flag[_pid] = 1; turn = 1 - _pid; (flag[1 - _pid] == 0 turn == _pid); ncrit++; assert(ncrit == 1); /* critical section */ ncrit--; flag[_pid] = 0; goto again; } 57

Mutual Exclusion in SPIN bool turn, flag[2]; byte ncrit; active [2] proctype user() { assert(_pid == 0 pid == 1); again: flag[_pid] = 1; turn = 1 - _pid; (flag[1 - _pid] == 0 turn == _pid); ncrit++; assert(ncrit == 1); /* critical section */ } ncrit--; flag[_pid] = 0; goto again; assert: Checks that there are always at most one process in the critical section 58

Mutual Exclusion in SPIN bool turn, flag[2]; bool critical[2]; LTL Properties: #define critical1 critical[1] active [2] proctype user() The processes are never both in the critical section { assert(_pid == 0 pid == 1); again: flag[_pid] = 1; turn = 1 - _pid; (flag[1 - _pid] == 0 turn == _pid); No matter what happens, a process will eventually get to a critical section critical[_pid] = 1; /* critical section */ critical[_pid] = 0; flag[_pid] = 0; Once process 0 raises its flag, it will eventually get into the critical section goto again; } 59

Mutual Exclusion in SPIN bool turn, flag[2]; bool critical[2]; LTL Properties: #define critical1 critical[1] active [2] proctype user() The processes are never both in the critical section { assert(_pid == 0 pid == 1); again: G (critical[0] == 0 critical[1] == 0) [] (!critical0!critical1) flag[_pid] = 1; turn = 1 - _pid; (flag[1 - _pid] == 0 turn == _pid); No matter what happens, a process will eventually get to a critical section critical[_pid] = 1; /* critical section */ F critical[0] <> critical0 critical[_pid] = 0; flag[_pid] = 0; Once process 0 raises its flag, it will eventually get into the critical section } goto again; G (turn -> F critical0) [] (turn -> <> critical0) 60

Mutual Exclusion in SPIN bool turn, flag[2]; bool critical[2]; LTL Properties: #define critical1 critical[1] active [2] proctype user() The processes are never both in the critical section { assert(_pid == 0 pid == 1); again: G (critical[0] == 0 critical[1] == 0) [] (!critical0!critical1) flag[_pid] = 1; turn = 1 - _pid; (flag[1 - _pid] == 0 turn == _pid); critical[_pid] = 1; /* critical section */ critical[_pid] = 0; flag[_pid] = 0; * caveat: can t use array indexes in SPIN LTL properties--have to duplicate code ** caveat: can t use next (X) due to SPIN limitations ***caveat: SPIN accepts a never property rather than an always property, so LTL formulas should be negated before passing them to SPIN. goto again; } 61

State Space Explosion Problem: Size of the state graph can be exponential in size of the program (both in the number of the program variables and the number of program components) M = M 1 M n If each M i has just 2 local states, potentially 2 n global states Research Directions: State space reduction 62

Model Checking Performance Model Checkers today can routinely handle systems with between 100 and 300 state variables. Systems with 10 120 reachable states have been checked. By using appropriate abstraction techniques, systems with an essentially unlimited number of states can be checked. 63

Notable Examples IEEE Scalable Coherent Interface In 1992 Dill s group at Stanford used Murphi to find several errors, ranging from uninitialized variables to subtle logical errors IEEE Futurebus In 1992 Clarke s group at CMU found previously undetected design errors PowerScale multiprocessor (processor, memory controller, and bus arbiter) was verified by Verimag researchers using CAESAR toolbox Lucent telecom. protocols were verified by FormalCheck errors leading to lost transitions were identified PowerPC 620 Microprocessor was verified by Motorola s Verdict model checker. 64

The Grand Challenge: Model Check Software Extract finite state machines from programs written in conventional programming languages Use a finite state programming language: executable design specifications (Statecharts, xuml, etc.). Unroll the state machine obtained from the executable of the program. 65

The Grand Challenge: Model Check Software Use a combination of the state space reduction techniques to avoid generating too many states. Verisoft (Bell Labs) FormalCheck/xUML (UT Austin, Bell Labs) ComFoRT (CMU/SEI) Use static analysis to extract a finite state skeleton from a program. Model check the result. Bandera Kansas State Java PathFinder NASA Ames SLAM/Bebop - Microsoft 66

Bonus: Computation Tree Logic (CTL) 67

Computation Tree Logics Formulas are constructed from path quantifiers and temporal operators: 1. Path Quantifiers: A for every path E there exists a path 2. Temporal Operator: Xα -α holds next time Fα -αholds sometime in the future Gα -α holds globally in the future α Uβ -α holds until β holds LTL: start with an A and then use only Temporal Operators 68

The Logic CTL In a branching-time logic (CTL), the temporal operators quantify over the paths that are possible from a given state (s 0 ). Requires each temporal operator (X, F, G, and U) to be preceded by a path quantifier (A or E). c c c c c c c c c M, s 0 AG c M, s 0 AF c c c c c M, s 0 EF c M, s 0 EG c 69

Typical CTL Formulas EF (Started Ready): it is possible to get to a state where Started holds but Ready does not hold. AG (Req AF Ack): whenever Request occurs, it will be eventually Acknowledged. AG (DeviceEnabled): DeviceEnabled always holds on every computation path. AG (EF Restart): from any state it is possible to get to the Restart state. 70

AG(EF p) cannot be expressed in LTL Trivia Reset property: from every state it is possible to get to p But there might be paths where you never get to p Different from A(GF p) Along each possible path, for each state in the path, there is a future state where p holds Counterexample: ababab a b p 71

A(FG p) cannot be expressed in CTL Trivia Along all paths, one eventually reaches a point where p always holds from then on But at some points in some paths where p always holds, there might be a diverging path where p does not hold Different from AF(AG p) Along each possible path there exists a state such that p always holds from then on Counterexample: the path that stays in s 0 s 0 p s 1 s 2 b p 72

Linear vs. branching-time logics some advantages of LTL some advantages of BT logics LTL properties are preserved under abstraction : i.e., if M approximates a more complex model M, by introducing more paths, then M ψ M ψ counterexamples for LTL are simpler: consisting of single executions (rather than trees). The automata-theoretic approach to LTL model checking is simpler (no tree automata involved). anecdotally, it seems most properties people are interested in are linear-time properties. BT allows expression of some useful properties like reset. CTL, a limited fragment of the more complete BT logic CTL*, can be model checked in time linear in the formula size (as well as in the transition system). But formulas are usually far smaller than system models, so this isn t as important as it may first seem. Some BT logics, like µ-calculus and CTL, are well-suited for the kind of fixed-point computation scheme used in symbolic model checking. 73

Formulas over States and Paths State formulas Describe a property of a state in a model M If p AP, then p is a state formula If f and g are state formulas, then f, f g and f g are state formulas If f is a path formula, then E f and A f are state formulas Path formulas Describe a property of an infinite path through a model M If f is a state formula, then f is also a path formula If f and g are path formulas, then f, f g, f g, X f, F f, G f, and f U g are path formulas 74

Notation A path π in M is an infinite sequence of states s 0, s 1, such that for every i 0, (s i, s i+1 ) R π i denotes the suffix of π starting at s i If f is a state formula, M, s f means that f holds at state s in the Kripke structure M If f is a path formula, M, π f means that f holds along path π in the Kripke structure M 75

Semantics of Formulas M, s p p L(s) M, s f M, s f M, s f 1 f 2 M, s f 1 M, s f 2 M, s f 1 f 2 M, s f 1 M, s f 2 M, s E g 1 π=s M, π g 1 M, s A g 1 π=s M, π g 1 M, π f π=s M, s f M, π g M, π g M, π g 1 g 2 M, π g 1 M, π g 2 M, π g 1 g 2 M, π g 1 M, π g 2 M, π X g M, π 1 g M, π F g k 0 M, π k g M, π G g k 0 M, π k g M, π g 1 U g 2 k 0 M, π k g 2 0 j<k M, π j g 1 76

Bonus: Example 77

An Example mtype = { NONCRITICAL, TRYING, CRITICAL }; show mtype state[2]; proctype process(int id) { beginning: noncritical: state[id] = NONCRITICAL; if :: goto noncritical; :: true; fi; trying: state[id] = TRYING; if :: goto trying; :: true; fi; critical: state[id] = CRITICAL; if :: goto critical; :: true; fi; goto beginning;} init { run process(0); run process(1); } NC T C 78

An Example mtype = { NONCRITICAL, TRYING, CRITICAL }; show mtype state[2]; proctype process(int id) { beginning: noncritical: state[id] = NONCRITICAL; if :: goto noncritical; :: true; fi; trying: state[id] = TRYING; if :: goto trying; :: true; fi; critical: state[id] = CRITICAL; if :: goto critical; :: true; fi; goto beginning;} init { run process(0); run process(1); } 79

An Example mtype = { NONCRITICAL, TRYING, CRITICAL }; show mtype state[2]; proctype process(int id) { beginning: noncritical: state[id] = NONCRITICAL; if :: goto noncritical; :: true; fi; trying: state[id] = TRYING; if :: goto trying; :: true; fi; critical: state[id] = CRITICAL; if :: goto critical; :: true; fi; goto beginning;} init { run process(0); run process(1); } 80

An Example mtype = { NONCRITICAL, TRYING, CRITICAL }; show mtype state[2]; proctype process(int id) { beginning: noncritical: state[id] = NONCRITICAL; if :: goto noncritical; :: true; fi; trying: state[id] = TRYING; if :: goto trying; :: true; fi; critical: state[id] = CRITICAL; if :: goto critical; :: true; fi; goto beginning;} init { run process(0); run process(1); } 81

An Example mtype = { NONCRITICAL, TRYING, CRITICAL }; show mtype state[2]; proctype process(int id) { beginning: noncritical: state[id] = NONCRITICAL; if :: goto noncritical; :: true; fi; trying: state[id] = TRYING; if :: goto trying; :: true; fi; critical: state[id] = CRITICAL; if :: goto critical; :: true; fi; goto beginning;} init { run process(0); run process(1); } 82

An Example mtype = { NONCRITICAL, TRYING, CRITICAL }; show mtype state[2]; proctype process(int id) { beginning: noncritical: state[id] = NONCRITICAL; if :: goto noncritical; :: true; fi; trying: state[id] = TRYING; if :: goto trying; :: true; fi; critical: state[id] = CRITICAL; if :: goto critical; :: true; fi; goto beginning;} init { run process(0); run process(1); } NC T C 83

Enabled Statements A statement needs to be enabled for the process to be scheduled. bool a, b; proctype p1() { a = true; a & b; a = false; } proctype p2() { b = false; a & b; b = true; } init { a = false; b = false; run p1(); run p2(); } 84

Enabled Statements A statement needs to be enabled for the process to be scheduled. bool a, b; These statements are enabled proctype p1() only if both a and b are true. { a = true; a & b; a = false; } proctype p2() { b = false; a & b; b = true; } init { a = false; b = false; run p1(); run p2(); } 85

Enabled Statements A statement needs to be enabled for the process to be scheduled. bool a, b; proctype p1() { a = true; a & b; a = false; } proctype p2() { b = false; a & b; b = true; } These statements are enabled only if both a and b are true. In this case b is always false and therefore there is a deadlock. init { a = false; b = false; run p1(); run p2(); } 86

Other constructs Do loops do :: count = count + 1; :: count = count - 1; :: (count == 0) -> break od 87

Other constructs Do loops Communication over channels proctype sender(chan out) { int x; if ::x=0; ::x=1; fi } out! x; 88

Other constructs Do loops Communication over channels Assertions proctype receiver(chan in) { int value; in? value; assert(value == 0 value == 1) } 89

Other constructs Do loops Communication over channels Assertions Atomic Steps int value; proctype increment() { atomic { x = value; x = x + 1; value = x; } } 90