Part I. Principles and Techniques

Similar documents
Systems and Software Verification

Formal Methods in Software Engineering

Finite-State Model Checking

The State Explosion Problem

MODEL CHECKING. Arie Gurfinkel

Alan Bundy. Automated Reasoning LTL Model Checking

Automata-based Verification - III

Timed Automata. Chapter Clocks and clock constraints Clock variables and clock constraints

Formal Verification of Mobile Network Protocols

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

Abstractions and Decision Procedures for Effective Software Model Checking

Introduction to Model Checking. Debdeep Mukhopadhyay IIT Madras

Automata-based Verification - III

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

Computer-Aided Program Design

EECS 144/244: Fundamental Algorithms for System Modeling, Analysis, and Optimization

Formal Verification Techniques. Riccardo Sisto, Politecnico di Torino

Model Checking: An Introduction

Chapter 3: Linear temporal logic

7. Queueing Systems. 8. Petri nets vs. State Automata

Sanjit A. Seshia EECS, UC Berkeley

Lecture 2 Automata Theory

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

Symmetry Reductions. A. Prasad Sistla University Of Illinois at Chicago

Stéphane Lafortune. August 2006

Model Checking. Boris Feigin March 9, University College London

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

Models for Efficient Timed Verification

A Brief Introduction to Model Checking

Timo Latvala. March 7, 2004

DES. 4. Petri Nets. Introduction. Different Classes of Petri Net. Petri net properties. Analysis of Petri net models

Automata-Theoretic LTL Model-Checking

Synthesis weakness of standard approach. Rational Synthesis

Communication in Petri nets

Model for reactive systems/software

Analysis and Optimization of Discrete Event Systems using Petri Nets

Lecture 2 Automata Theory

Discrete Event Systems Exam

Flat counter automata almost everywhere!

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

Software Verification

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

An Introduction to Hybrid Systems Modeling

CISC 4090 Theory of Computation

An introduction to Uppaal and Timed Automata MVP5 1

Model Checking, Theorem Proving, and Abstract Interpretation: The Convergence of Formal Verification Technologies

Automata-Theoretic Model Checking of Reactive Systems

BOOLEAN ALGEBRA INTRODUCTION SUBSETS

Let us first give some intuitive idea about a state of a system and state transitions before describing finite automata.

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

Automata, Logic and Games: Theory and Application

Logic Model Checking

Deterministic (DFA) There is a fixed number of states and we can only be in one state at a time

Today s Lecture. Lecture 4: Formal SE. Some Important Points. Formal Software Engineering. Introduction to Formal Software Engineering

Algorithmic verification


Modeling Concurrent Systems

On the Design of Adaptive Supervisors for Discrete Event Systems

UNIT-I. Strings, Alphabets, Language and Operations

Control Synthesis of Discrete Manufacturing Systems using Timed Finite Automata

A Scalable Jointree Algorithm for Diagnosability

Bridging the Gap between Reactive Synthesis and Supervisory Control

T Reactive Systems: Temporal Logic LTL

Property Checking of Safety- Critical Systems Mathematical Foundations and Concrete Algorithms

The algorithmic analysis of hybrid system

Linear-Time Logic. Hao Zheng

Directed Topology and Concurrency Theory.

Embedded Systems 2. REVIEW: Actor models. A system is a function that accepts an input signal and yields an output signal.

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

Our Problem. Model. Clock Synchronization. Global Predicate Detection and Event Ordering

Automatic Synthesis of Distributed Protocols

Introduction to Computers & Programming

Final Exam /614 Bug Catching: Automated Program Verification Matt Fredrikson André Platzer. December 17, 2017

From Sequential Circuits to Real Computers

Sri vidya college of engineering and technology

Model Checking & Program Analysis

State-Space Exploration. Stavros Tripakis University of California, Berkeley

Uses of finite automata

chapter 12 MORE MATRIX ALGEBRA 12.1 Systems of Linear Equations GOALS

Lecture 4 Event Systems

Complexity Metrics for Spreadsheet Models

Author: Vivek Kulkarni ( )

LTL Model Checking. Wishnu Prasetya.

Lecture Notes On THEORY OF COMPUTATION MODULE -1 UNIT - 2

A Simplified Approach for Testing Real-Time Systems Based on Action Refinement

Computation Tree Logic

A Sample State Machine

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

Let s now begin to formalize our analysis of sequential machines Powerful methods for designing machines for System control Pattern recognition Etc.

for System Modeling, Analysis, and Optimization

A brief history of model checking. Ken McMillan Cadence Berkeley Labs

Testing with model checkers: A survey

Solutions. CS 2800 Fall 2017 Final exam Friday, December 8. NetID: 1. Modular arithmetic [9 pts]

Computation Tree Logic (CTL) & Basic Model Checking Algorithms

Methods for the specification and verification of business processes MPB (6 cfu, 295AA)

n CS 160 or CS122 n Sets and Functions n Propositions and Predicates n Inference Rules n Proof Techniques n Program Verification n CS 161

Clocks in Asynchronous Systems

CS:4330 Theory of Computation Spring Regular Languages. Finite Automata and Regular Expressions. Haniel Barbosa

Büchi Automata and Linear Temporal Logic

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

Transcription:

Introduction to Formal Methods Part I. Principles and Techniques Lecturer: JUNBEOM YOO jbyoo@konkuk.ac.kr

Introduction Text System and Software Verification : Model-Checking Techniques and Tools In this book, you will find enough theory to be able to assess the relevance of the various tools, to understand the reasons behind their limitations and strengths, and to choose the approach currently best suited for your verification task. Part I : Principles and Techniques Part II : Specifying with Temporal Logic Part III : Some Tools Konkuk University 2

Chapter 1. utomata Model checking consists in verifying i some properties of the model of a system. Modeling of a system is difficult No universal method exists to model a system Best performed by qualified engineers This chapter describes a general model which serves as abasis. Organization of Chapter 1 Introductory Examples Few Definitions Printer Manager Few More Variables Synchronized Product Synchronization by Messaging Passing Synchronization by Shared Variables Konkuk University 3

1.11 Introductory Examples (Finite) i utomata Best suited for verification by model checking techniques machine evolving from one state to another under the action of transitions Graphical representation 03:58 03:59 04:00 n automate model of a digital watch (24x60=1440 states) Konkuk University 4

dec 0 1 inc dec inc inc dec 2 c3 : a module 3 counter Konkuk University 5

digicode door lock example Controls the opening of office doors The door opens upon the keying in of the correct character sequence, irrespective of any possible incorrect initial attempts. ssumes 3 keys, B, and C Correct key sequence : B B, C B 1 2 3 4 C B, C Konkuk University 6

Two fundamental notations execution sequence of states describing one possible evolution of the system Ex. 1121, 12234, 112312234 3 different executions execution tree set of all possible executions of the system in the form of a tree Ex. 1 11, 12 111, 112, 121, 122, 123 1111, 1112, 1121, 1122, 1123, 1211, 1212, 1221, 1222, 1223, 1231, 1234 1 1 2 1 2 1 2 3 1 2 1 2 3 Konkuk 1 University 2 1 2 3 1 4 7

We associate with each automaton state a number of elementary properties which we know are satisfies, since our goal is to verify system model properties. Properties Elementary property (atomic) Proposition ssociated with each state t True or False in a given state Complicated property Expressed using elementary properties Depends on the logic we use Konkuk University 8

For example, P : an has just been keyed in P B : an B has just been keyed in P C : an C has just been keyed in pred 2 : the proceeding state in an execution is 2 pred 3 : the proceeding state in an execution is 3 Properties of the system to verify 1. If the door opens, then, B, were the last three letters keyed in, in that order. 2. Keying in any sequence of letters ending in B opens the door. Let s prove the properties with the propositions P B P P pred 2 pred 3 Konkuk University 9

1.2 Few Definition n automaton is a tuple = < Q, E, T, q 0, l > in which h Q : a finite set of states E : the finite set of transition labels T Q x E ⅹ Q :thesetoftransitions transitions q 0 : the initial state of the automaton l : the mapping each state with associated sets of properties which hold in it Prop = {P 1, P 2, } : a set of elementary propositions Konkuk University 10

= < Q, E, T, q 0, l > Q = {1, 2, 3, 4} E = {, B, C} T = {(1 (1,,2), (1,B,1), B 1) (1,C,1), C 1) (2,,2), (2,B,3), (2,C,1), (3,,4), (3,B,1), (3,C,1) } q 0 = 1 P B P P pred 2 pred 3 l = 1 ø 2 {P } 3 {P B, pred 2 } 4 {P, pred 3 } The digicode with its atomic propositions B, C 1 C 2 P B 3 pred 2 P B 4 pred 3 P B, CKonkuk University 11

Formal definitions of automaton s behavior a path of automaton : sequence σ, finite or infinite, of transitions which follows each other B Ex. 3 1 2 2 a length of apathσ σ : σ σ s potentially infinite number of transitions: σ N {ω} a partial execution of : path starting from the initial state q 0 B Ex. 1 2 2 3 a complete execution of : n execution which is maximal. Infinite or deadlock a reachable state : state is said to be reachable, if a state appears in the execution tree of the automaton, in other words, if there exists at least one execution in which it appears. Konkuk University 12

1.3 Printer Manager printer shared by two users end 0 R R B end B Propositions W = Waiting P = Printing now R = Rest for now req req B 6 beg beg B P W R B 1 2 7 R R W B P B R B req B req end B end 4 W W beg B 3 W W beg 5 P P P B W B W B req B req Konkuk University 13

= < Q, E, T, q 0, l > Q = {0, 1, 2, 3, 4, 5, 6, 7} E = {req, req B, beg, beg B, end, end B } T = { (0,req,1), (0,req B,2), (1,req B,3), (1,beg,6), (2,req,3), (2,beg B,7), (3,beg,5), (3,beg B,4), (4,end B,1), (5,end,2), (6,end,0), (6,req B,5), (7,end B,0), (7,req,4) } q 0 = 0 l = 0 {R, R B }, 1 {W, R B } 2 {R, W B }, 3 {W, W B } 4 {W, P B }, 5 {P, W B } 6 {P, R B }, 7 {R, P B } Konkuk University 14

Properties of the printer manager to verify 1. We would undoubtedly wish to prove that any printing operation is preceded by a print request. In any execution, any state in which P holds is preceded by a state in which the proposition W holds. 2. Similarly, we would like to check that any print request is ultimately satisfied. ( fairness property) In any execution, any state in which W holds is followed by a state in which the proposition P holds. Model checking techniques allow us to prove automatically that Property 1 is TRUE, and Property 2 is FLSE, for example 0 1 3 4 1 3 4 1 3 4 1 3 4 1 (counterexample) Konkuk University 15

1.4 Few More Variables It is often convenient to let automata manipulate state variables. Control : states + transitions Data : variables (assumes finite number of values) n automaton interacts with variables in two ways: ssignments Guards Konkuk University 16

if ctr < 3 B, C ctr := ctr + 1 if ctr < 3 ctr := ctr + 1 if ctr < 3 (guard) B, C (transition label) l) ctr := ctr + 1 (assignment) ctr := 0 if ctr = 3 B, C ctr := ctr + 1 1 2 3 4 if ctr < 3 C ctr := ctr + 1 err B if ctr = 3, C ctr := ctr + 1 if ctr = 3 B, C ctr := ctr + 1 The digicode with guarded transitions No more than 3 mistakes!!! Konkuk University 17

It is often necessary, in order to apply model checking methods, to unfold the behaviors of an automaton with variables into a state graph in which the possible transitions appear and the configurations are clear marked. Unfolded automaton = Transition system has global states transitions are no longer guarded no assignments on the transitions Konkuk University 18

Unfolding B,C B,C BC B,C 1 ctr=0 1 ctr=1 1 ctr=2 1 ctr=3 B,C 2 B 3 ctr=0 ctr=0 C C C 2 ctr=1 2 ctr=2 2 ctr=3, C B,C B B,C B BC B,C B B,C 3 ctr=1 3 ctr=2 3 ctr=3 4 ctr=0 4 ctr=1 4 ctr=2 4 ctr=3 The digicode with error counting (Unfolded automaton) err ctr=4 Konkuk University 19

1.5 Synchronized Product Real-life lif programs or systems are often composed of modules or subsystems. Modules/Components (composition) Overall system Component automata t (synchronization) Global l automaton t utomata t for an overall system Often has so many global states Impossible to construct it directly (State explosion problem) Two composition ways With synchronization Without synchronization Konkuk University 20

n example without synchronization system made up of three counters (modulo 2, 3, 4) They do not interact with each other Global automaton = Cartesian product of three independent automata C3 C2 103 1,0,3 113 1,1,3 123 1,2,3 C4 0,0,3 0,1,3 0,2,3 1,0,2 1,1,2 1,2,2 0,0,2 0,1,2 0,2,2 1,0,1 1,1,1 1,2,1 2*3*4 = 24 states 3*3*3-1 = 26 transitions per a state (Inc, Dec, -) 24 * 26 = 624 transitions 0,0,1, 0,1,1 021 0,2,1 1,0,0 1,1,0 1,2,0 000 0,0,0 010 0,1,0 0,2,0 Konkuk University 21

n example with synchronization number of ways depending on the nature of the problem Ex. llowing only inc, inc, inc and dec, dec, dec (24*2=48 transitions) Ex. llowing updates in only one counter at a time (24*3*2=144 transitions) Synchronized product way to formally express synchronizing options Synchronized product = Component automata + Synchronized set 1 ⅹ 2 ⅹ ⅹ n : Component automata t = < Q, E, T, q 0, l > Q = Q 1 ⅹ Q 2 ⅹ ⅹ Q n E = ( E i {-} ) 1 i n T = ((q 1,., q n ), (e 1,, e n ), (q 1,, q n )) for all i, (e i = - and q i = q i ) or (e i - and (q i, e i, q i ) T i ) q 0 = (q 0,1,, q 0,n ) l((q 1,, q n )) = l i (q i ) 1 i n Sync ( E i {-} ) : Synchronized set 1 i n Konkuk University 22

n example with synchronization Ex. llowing only inc, inc, inc and dec, dec, dec (24*2=48 transitions) Strongly coupled version of modular counters Sync = { (inc, inc, inc), (dec, dec, dec) } T = ((q 1,., q n ), (e 1,, e n ), (q 1,, q n )) (e 1,, e n ) Sync (e i = - and q i = q i ) or (e i - and (q i, e i, q i ) T i ) 1,0,3 1,1,3 1,2,3 0,0,2 0,1,2 0,2,2 1,0,1 1,1,1 1,2,1 12 states 12 transitions (inc, inc, inc) (dec, dec, dec) coupl ccc 0,0,0 0,1,1 0,2,0 Konkuk University 23

Reachable states Reachability depends on the synchronization constraints dec dec dec dec dec 1,2,3 inc 0,1,2 inc 1,0,1 inc 0,2,0 inc 1,1,3 inc 0,0,2 dec inc inc dec inc inc inc inc inc 0,0,0 dec 1,1,1 dec 0,2,2 dec 1,0,3 dec 0,1,0 dec 1,2,1 coupl Rearranged automaton ccc modulo 12 counter Reachability graph Obtained by deleting non-reachable states t Many tools to construct R.G. of synchronized product of automata Reachability is a difficult problem State explosion problem Konkuk University 24

1.6 Synchronization with Message Passing Message passing framework special case of synchronized product!m : Emitting a message?m : Reception of the message Only the transition in which!m and?m pairs are executed simultaneously is permitted. Synchronous communication Control/command system synchronous communication i Communication protocol (using channel/buffer) Konkuk University 25

Smallish elevator Synchronous communication (message passing) One cabin Three doors (one per floor) One controller No requests from the three floors The controller?down The cabin?up free2!close_2!open_2 on2!down 2->0?up?up 0 1 2?down?down!close_1!up!down!down?close_i?open_i free1!open_1!up on1!down!up C?open_i?close_i The i th door O!close_0 0->2 free0 on0!open_0!up Konkuk University 26

n automaton t for the smallish elevator example Obtained as the synchronized product of the five automata (door 0, door 1, door 2, cabin, controller) Sync = { (?open_1, -, -, -,!open_1), (?close_1, -, -, -,!close_1), (-,?open_2, -, -,!open_2), (-,?close_2, -, -,!close_2), (-, -,?open_3, -,!open_3), (-, -,?close_3, -,!clsoe_3), (-, -, -,?down,!down), (-, -, -,?up,!up) } Properties to check (P1) The door on a given floor cannot open while the cabin is on a different floor. (P2) The cabin cannot move while one of the door is open. Model checker Can build the synchronized product of the 5 automata. Can check automatically whether properties hold or not. Konkuk University 27

1.7 Synchronization by Shared Variables nother way to have components communicate with each other Share a certain number of variables llow variables to be shared by several automata Ex. The printer manager in Chapter 1.3 Problem: fairness property is not satisfied Konkuk University 28

The printer manager synchronized with a shared variable Shared variable: turn Fairness property: ny print request is ultimately satisfied. No state of the form (y, t, -) is reachable. TRUE in the model. But, this model forbids either user from printing i twice in a row. The user x if turn=, print turn:=b y x, z print y, z The user B turn:= turn:=b z if turn=b, print B turn:= t x, t B print B x, z B Konkuk University 29

Printer manager : complete version with 3 variables [by Peterson] r : a request from user r B : a request from user B turn : to settle conflicts Satisfies all our properties The user r := true 1 2 The user B r B := true 1 2 r := false if turn =, print turn:=b r B := false if turn = B, print B turn:= 4 3 4 3 if r B = false print if r B false, print if r = false, print B = < Q, E, T, q 0, l > ⅹB Q = ⅹ B ⅹ r ⅹ r B ⅹ turn 4 ⅹ 4 ⅹ 2 ⅹ 2 ⅹ 2 = 128 states (only 128 reachable states) Konkuk University 30