Introduction to Model Checking. Debdeep Mukhopadhyay IIT Madras

Similar documents
Finite-State Model Checking

SMV the Symbolic Model Verifier. Example: the alternating bit protocol. LTL Linear Time temporal Logic

CTL Model checking. 1. finite number of processes, each having a finite number of finite-valued variables. Model-Checking

Temporal Logic. Stavros Tripakis University of California, Berkeley. We have designed a system. We want to check that it is correct.

Model Checking. Boris Feigin March 9, University College London

Model Checking with CTL. Presented by Jason Simas

Chapter 6: Computation Tree Logic

Automata-Theoretic Model Checking of Reactive Systems

Model for reactive systems/software

MODEL CHECKING. Arie Gurfinkel

Temporal & Modal Logic. Acronyms. Contents. Temporal Logic Overview Classification PLTL Syntax Semantics Identities. Concurrency Model Checking

Models. Lecture 25: Model Checking. Example. Semantics. Meanings with respect to model and path through future...

Chapter 4: Computation tree logic

Chapter 5: Linear Temporal Logic

Verification. Arijit Mondal. Dept. of Computer Science & Engineering Indian Institute of Technology Patna

Model Checking: An Introduction

Guest lecturer: Prof. Mark Reynolds, The University of Western Australia

The State Explosion Problem

Model Checking. Temporal Logic. Fifth International Symposium in Programming, volume. of concurrent systems in CESAR. In Proceedings of the

Linear-Time Logic. Hao Zheng

FAIRNESS FOR INFINITE STATE SYSTEMS

What is Temporal Logic? The Basic Paradigm. The Idea of Temporal Logic. Formulas

Alan Bundy. Automated Reasoning LTL Model Checking

FORMAL METHODS LECTURE III: LINEAR TEMPORAL LOGIC

Model Checking I. What are LTL and CTL? dack. and. dreq. and. q0bar

Verification Using Temporal Logic

Model Checking I. What are LTL and CTL? dack. and. dreq. and. q0bar

Abstractions and Decision Procedures for Effective Software Model Checking

FORMAL METHODS LECTURE IV: COMPUTATION TREE LOGIC (CTL)

Computer-Aided Program Design

Probabilistic Model Checking Michaelmas Term Dr. Dave Parker. Department of Computer Science University of Oxford

ESE601: Hybrid Systems. Introduction to verification

Temporal Logic. M φ. Outline. Why not standard logic? What is temporal logic? LTL CTL* CTL Fairness. Ralf Huuck. Kripke Structure

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

Overview. overview / 357

Modal and Temporal Logics

Double Header. Model Checking. Model Checking. Overarching Plan. Take-Home Message. Spoiler Space. Topic: (Generic) Model Checking

An Introduction to Temporal Logics

NPTEL Phase-II Video course on. Design Verification and Test of. Dr. Santosh Biswas Dr. Jatindra Kumar Deka IIT Guwahati

Verifying Temporal Properties of Reactive Systems: A STeP Tutorial *

Lecture Notes on Software Model Checking

Computation Tree Logic

Lecture 16: Computation Tree Logic (CTL)

Using Patterns and Composite Propositions to Automate the Generation of LTL Specifications

Digital Systems. Validation, verification. R. Pacalet January 4, 2018

Computation Tree Logic (CTL) & Basic Model Checking Algorithms

Model checking (III)

3-Valued Abstraction-Refinement

Linear Temporal Logic and Büchi Automata

Computation Tree Logic

Temporal logics and explicit-state model checking. Pierre Wolper Université de Liège

Temporal Logic and Fair Discrete Systems

T Reactive Systems: Temporal Logic LTL

CS256/Winter 2009 Lecture #1. Zohar Manna. Instructor: Zohar Manna Office hours: by appointment

Homework 2: Temporal logic

PSL Model Checking and Run-time Verification via Testers

Lecture Notes on Emptiness Checking, LTL Büchi Automata

Linear Temporal Logic (LTL)

Semantic Equivalences and the. Verification of Infinite-State Systems 1 c 2004 Richard Mayr

Bilateral Proofs of Safety and Progress Properties of Concurrent Programs (Working Draft)

Model checking the basic modalities of CTL with Description Logic

The algorithmic analysis of hybrid system

From Liveness to Promptness

Timo Latvala. February 4, 2004

Linear Temporal Logic (LTL)

Helsinki University of Technology Laboratory for Theoretical Computer Science Research Reports 66

CS256/Winter 2009 Lecture #6. Zohar Manna

Safety and Liveness Properties

Logic in Automatic Verification

Introduction to Temporal Logic. The purpose of temporal logics is to specify properties of dynamic systems. These can be either

Using Patterns and Composite Propositions to Automate the Generation of Complex LTL Specifications

Generating Linear Temporal Logic Formulas for Pattern-Based Specifications

The assertional versus Tarskian methods

Introduction. Pedro Cabalar. Department of Computer Science University of Corunna, SPAIN 2013/2014

Computation Tree Logic

Characterizing Fault-Tolerant Systems by Means of Simulation Relations

Symbolic Trajectory Evaluation (STE): Orna Grumberg Technion, Israel

Topics in Verification AZADEH FARZAN FALL 2017

LTL and CTL. Lecture Notes by Dhananjay Raju

Linear-time Temporal Logic

Introducing Proof 1. hsn.uk.net. Contents

Model Checking & Program Analysis

LTL Model Checking. Wishnu Prasetya.

p,egp AFp EFp ... p,agp

Correctness of Concurrent Programs

Failure Diagnosis of Discrete Event Systems With Linear-Time Temporal Logic Specifications

Model checking, verification of CTL. One must verify or expel... doubts, and convert them into the certainty of YES [Thomas Carlyle]

arxiv: v1 [cs.dc] 3 Oct 2011

Summary. Computation Tree logic Vs. LTL. CTL at a glance. KM,s =! iff for every path " starting at s KM," =! COMPUTATION TREE LOGIC (CTL)

PSPACE-completeness of LTL/CTL model checking

CTL, the branching-time temporal logic

CS256/Spring 2008 Lecture #11 Zohar Manna. Beyond Temporal Logics

In recent years CTL and LTL logics have been used with considerable industrial success.

Chapter 4: Classical Propositional Semantics

Lecture 2: Symbolic Model Checking With SAT

Formal Verification. Lecture 1: Introduction to Model Checking and Temporal Logic¹

First-order resolution for CTL

Hardy s Paradox. Chapter Introduction

Theoretical Foundations of the UML

Transcription:

Introduction to Model Checking Debdeep Mukhopadhyay IIT Madras

How good can you fight bugs?

Comprising of three parts Formal Verification techniques consist of three parts: 1. A framework for modeling systems some kind of specification language 2. A specification language for describing the properties to be verified 3. A verification method for establishing if the description of the system satisfies the specification

Proof-based verification The system description is a set of formula Γ in a suitable logic The specification is another formula ϕ The verification method is finding a proof that Γ ϕ means deduction It typically needs the user guidance and expertise

Model-based verification The system is represented by a model M for an appropriate logic The specification is again represented by a formula ϕ The verification method consist of computing whether a model M satisfies ϕ Msatisfies ϕ : M ϕ The computation is usually automatic for finite models

Degree of automation From fully automated to fully manual

Full- vs. property-verification The specification may describe a single property of the system, or it may describe its full behavior (expensive).

Intended domain of application Hardware, software Sequential, concurrent Reactive, terminating Reactive: reacts to its environment, and is not meant to terminate (e.g. operating systems, embedded systems, computer hardware)

Pre- vs. post-development Verification is of greater advantage if introduced early in system development

Model checking Model checking is an automatic, modelbased, property-verification approach It is intended to be used for concurrent and reactive systems The purpose of a reactive system is not necessarily to obtain a final result, but to maintain some interaction with its environment

Temporal Logic (cont.) In model checking: The models M are transition systems The properties φ are formulas in temporal logic Model checking steps: 1. Model the system using the description language of a model checker : M 2. Code the property using the specification language of the model checker : φ 3. Run the model checker with the inputs M and φ

Model checker based on satisfaction p F q φ yes Model Checker no M Error Trace

Linear vs. Branching Linear-time logics think of time as a set of paths path is a sequence of time instances Branching time logics represent time as a tree it is rooted at the present moment and branches out into the future Many logics were suggested during last years that fit into one of above categories We study LTL in linear time logics and CTL in branching time logics

Linear vs. Branching (cont.) Linear Time Every moment has a unique successor Infinite sequences (words) Linear Time Temporal Logic (LTL) Branching Time Every moment has several successors Infinite tree Computation Tree Logic (CTL)

Propositional Linear Temporal Logic Express properties of Reactive Systems interactive, nonterminating For PLTL, a model is an infinite state sequence σ = s 0 s1,, s Temporal operators 2 Globally : G p at t iff p for all t t. pp pp ppppppp... G p...

Temporal operators... Future : F p at t iff p for some t t. pp pp pp F p... Until : p U q at t iff q for some t t and p in the range [ t, t ) pp pp pp pppq p U q... Next-time : X p at t iff p at t+1

Examples Liveness: if input, then eventually output G (input F output) atomic props Strong fairness: infinitely send implies infinitely recv. GF send GF recv infinitely often

Recap: What is a model? Atoms: Atomic formulas (such as p. q, r, ). These atoms stand for atomic facts which may be true for a system. e,g Printer crypto-6 is working Process encipher is suspended Content of the register key is the integer value 6

Model A Model is a transition system. A transition system M=(S,,L) is a set of states S endowed with a transition relation (a binary relation on S), such that every state s from S, has some successor state s which is also from S. Thus s s Also associated with each state is a set of atomic propositions which are true at that state, described by a labeling function, L

Example S = {s 0, s 1, s 2 } s 0 p,q q q,r s 1 s 2 transitions = s 0 s 1, s 1 s 1, s 2 s 1, s 2 s 0, s 0 s 2 L(s 0 ) = {p,q} L(s 1 ) = {q} L(s 2 ) = {q,r}

Example N1,N2 turn=0 PATH T1,N2 turn=1 N1,T2 turn=2 C1,N2 turn=1 T1,T2 turn=1 T1,T2 turn=2 N1,C2 turn=2 C1,T2 turn=1 T1,C2 turn=2 N = noncritical, T = trying, C = critical

Propositional temporal logic In Negation Normal Form AP a set of atomic propositions Temporal operators: Gp Fp Xp puq Path quantifiers: A for all path E there exists a path

Not Until (puq) Whenever q occurs there must be a nonoccurrence of p before. pp pp pp p U q... pppq pp pp pp pppq (p U q)

Explanation i j p q: = i[( Π = q) ( j< i, Π = p)] i j ( p q): = i[ ( Π = q) ( j< i, Π = p)] i j := i[( Π = q) ( j< i, Π = p)]

Some Finer Points on p U q Until demands that q does hold in some future state i,e Fq It does not say anything about what happens after q occurs contrary to English Language: I smoked until 22 Means p= I smoke was true till q= I am 22 became true. Also after q= I am 22, p= I smoke does not occur In LTL, means p U (G p Λ q)

Two more terms Weak Until (pwq): Like puq except q need not occur. Release (prq): p is released by q. It means that q occurs entirely or it occurs till p occurs. Note than unlike until q occurs also at the time instant when p is asserted.

Operator precedence Unary operators including negation have strongest precedence p U q is parsed as ( p) U q rather than (p U q) Temporal binary operators have stronger precedence than non-temporal binary operators p q U r is parsed as: p (q U r) The precedence over propositional logic is as usual First do the AND then the ORs and XORs finally the IMPLIES and EQUIVALENCEs.

Example The parse tree of Fp Gq p W r according to precedence rules W F G p r p q

More of Until What is not puq? We have seen that. Here is another expression for that. ( p q) = q ( p q) G q

Intuitive Explanation ( p q) = ( q ( p q)) Fq Fq is straight-forward Let q occur => Fq t 1 t 2 t 3 q=1 p=0 q=0 Let t 3 be the first time interval when q is true. q=1 Let us contradict the equation, that is puq does not hold. Then, there is a time instant t=t 2, when p=0. Obviously q=0, as t 2 <t 3 But by RHS, if ( q ( p q)) then at time t=t 1, q=0 => q=1 But, t 1 <t 3 and hence we have a violation that t 3 is the first time when q=1. Thus, there is a contradiction and puq does hold. The equivalence follows.

Release Release R is dual of U; that is: p R q ( p U q) p must remain true up to and including the moment when q becomes true (if there is one); p releases q Thus, prq= Gq V [q U (p Λ q)] = [F q Λ (q U (p Λ q)] = [ p U q]

Weak Until φ W ψ : Weak Until is related to the Until with the difference that it does not require that ψ is eventually hold Essentially φ W ψ is a short form for writing φ U ψ Gφ

LTL satisfaction by a system Suppose M = ( S,, L) is a model, s S, and φ an LTL formula We write M, s φ if for every execution path п of M starting at s, we have п φ Sometimes M, s φ is abbreviated as s φ

Example p,q s 0 1. M, s 0 X q 2. M, s 0 G (p r) s 2 q,r q s 1 3. M, s 1 G q s 2 s 0 q,r p,q q s 1 4. M, s 0 p U q s 2 s 0 s 2 q s 1 s 1 q,r p,q q,r q

Practical patterns of specifications It is impossible to get to a state where started holds, but ready does not hold G (started ready) For any state, if a request occurs, then it will eventually be acknowledged G (requested F acknowledged) Whatever happens, a certain process will eventually be permanently deadlocked F G deadlock

Some practical patterns (cont.) A certain process is enabled infinitely often on every computation path G F enabled In other words, in a path of the system there must never be a point at which the condition enabled becomes false and stays false forever If a process is enabled infinitely often, then it runs infinitely often G F enabled G F running

Practical patterns(contd.) An upwards travelling lift at the 2 nd floor does not change its direction when it has passengers wishing to go to the 5 th floor: G(floor2 Λ directionup Λ ButtonPressed5 (directionup U floor5)

LTL weakness The features which assert the existence of a path are not (directly) expressible in LTL This problem can be solved by: checking whether all paths satisfy the negation of the required property A positive answer to this is a negative answer to our original question and vice versa. But properties which mix universal and existential path quantifiers cannot in general be expressed in LTL

LTL Weakness: Examples LTL cannot express these features: From any state it is possible to get to a restart state (i.e., there is a path from all states to a state satisfying restart) The lift can remain idle on the third floor with its door closed (i.e., from all states if there is path to a state in which it is on the third floor, there is a path along which it stays there) LTL cannot assert these because existential and universal logics are mixed. However, CTL can express these properties

Model checking example: Mutual exclusion The mutual exclusion problem (mutex) Avoiding the simultaneous access to some kind of resources by the critical sections of concurrent processes The problem is to find a protocol for determining which process is allowed to enter its critical section

Expected Properties Safety: Only one process is in its critical section at any time. Liveness: Whenever any process requests to enter its critical section, it will eventually be permitted to do so. Non-blocking: A process can always request to enter its critical section. No strict sequencing: Processes need not enter their critical section in strict sequence.

Modeling mutex Consider each process to be either: in its non-critical state n trying to enter the critical section t or in critical section c Each individual process has this cycle: n t c n t c n The processes phases are interleaved

2 process mutex The processes are asynchronous interleaved one of the processes makes a transition while the other remains in its current state s 0 n 1 n 2 t 1 n 2 s 1 s 5 n 1 t 2 s 3 s c 1 n t 1 t 2 n 1 c 2 s 2 6 2 s 4 c 1 t 2 t 1 c 2 s 7

Checking the properties Safety: G (c 1 c 2 ) This formula is satisfied in all states Liveness: G (t 1 F c 1 ) This formula is not satisfied in the initial state! s 0 s 1 s 3 s 7 s 1 s 3 s 7

Checking the properties Non-blocking: Consider process 1. We wish to check the following property: for every states satisfying n 1 there exists a state which satisfies t 1 This property cannot be expressed in LTL

Checking the properties No strict sequencing: Processes should not enter their critical section in a strict sequence. There should be at least one path where strict sequencing does not hold But LTL cannot express the logic there exists. Instead not of there exists is for all. Thus we can say that the following property s: in all paths there is a strict sequencing If the answer is no there is no strict sequence.

No Strict Sequencing c 1 and c 2 need not alternate Desired scenario: Process 1 acquires critical section (c 1 ) Process 1 releases the critical section ( c 1 ) Process 2 does not enter the critical section ( c 2 ) Process 1 regains access to the critical section (c 1 )

No Strict Sequencing There exists at least one path with no strict sequencing: c 1 c 1 c 1 c 1 c 2 c 2 c 2 c 1 Or, in all paths there is strict sequencing: Time Anytime we have c 1 state, the condn persists, or it ends with a non-c 1 state and in that case there is no further c 1 unless and until we obtain a c 2 state. Gc [ cw( c cwc)] 1 1 1 1 2 c 1 c 1 c 1 c 1 c 1 c 1 c 2 c 1 c 1 c 1 c 1 Time

Evaluation of the Protocol Safety property is satisfied. c 1 and c 2 do not become one at the same time in any state. s 0 n 1 n 2 Live-ness property is violated. Follow the path marked in red. Processor 1 tries to enter the critical section but fails. t 1 n 2 s 1 s 5 n 1 t 2 s 3 s c 1 n t 1 t 2 n 1 c 2 s 2 6 2 s 4 c 1 t 2 t 1 c 2 s 7

Evaluation of the Protocol Non-blocking: Observe all states where n 1 is high. All of them should have at least one path where t 1 is high in the next clock cycle. s 0 n 1 n 2 The property thus have to look for both for all and there exists logic and thus cannot be expressed in LTL. t 1 n 2 s 1 s 5 n 1 t 2 s 3 s c 1 n t 1 t 2 n 1 c 2 s 2 6 2 s 4 c 1 t 2 t 1 c 2 s 7

No-strict sequencing Path marked in red shows that all paths are sequencing is false. Thus, no strict sequencing is maintained. s 0 n 1 n 2 Note that since we are using LTL, we have negated the property: there exists a path with no strict sequencing t 1 n 2 s 1 s 5 n 1 t 2 s 3 s c 1 n t 1 t 2 n 1 c 2 s 2 6 2 s 4 c 1 t 2 t 1 c 2 s 7

Solution s 0 n 1 n 2 t 1 n 2 s 1 s 5 n 1 t 2 s 3 s 3 s c 1 n t 1 t 2 t n 1 c 2 1 t 2 2 s 6 2 s 4 c 1 t 2 t 1 c 2 s 7 All the four properties are satisfied s 3 and s 3 now expresses which process was requesting for the critical section early. Thus the live-ness problem is solved.

The SMV model checker New Symbolic Model Verifier Provides a language for describing the models. The properties are written as LTL (or CTL) formulas. It produces an output whether the specifications hold true, or a trace to show why the specification is false.