Logic Model Checking

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

Network Protocol Design and Evaluation

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

Lecture 3 SPIN and Promela

The Spin Model Checker : Part I. Moonzoo Kim KAIST

The SPIN Model Checker

Spin: Overview of PROMELA

The Spin Model Checker : Part I/II

Computer Aided Verification 2015 The SPIN model checker

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

Design and Analysis of Distributed Interacting Systems

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

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

Logic Model Checking

The SPIN Model Checker

Spin: Overview of PROMELA

Software Engineering using Formal Methods

Formal Specification and Verification

CS477 Formal Software Development Methods / 39

Software Engineering using Formal Methods

Applications of Formal Verification

T Parallel and Distributed Systems (4 ECTS)

Applications of Formal Verification

INF5140: Specification and Verification of Parallel Systems

CS477 Formal Software Development Methods / 32

Applications of Formal Verification

EMBEDDED C CODE 17. SPIN Version 4 supports the inclusion of embedded C code into PROMELA models through the following fiv e new primitives:

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

SPIN: Introduction and Examples

Building Graphical Promela Models using UPPAAL GUI

MP 6 Modeling in Promela and SPIN

THE MODEL CHECKER SPIN

Patrick Trentin Formal Methods Lab Class, March 03, 2017

Design of Internet Protocols:

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

Patrick Trentin Formal Methods Lab Class, Feb 26, 2016

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

Tool demonstration: Spin

Introduction to Model Checking

T Parallel and Distributed Systems (4 ECTS)

Formal Methods for Software Development

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

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

Network Protocol Design and Evaluation

A Tutorial on Model Checker SPIN

Formal Methods for Software Development

Model-Checking Concurrent Systems

SPIN. Carla Ferreira.

Automated Reasoning. Model Checking with SPIN (II)

Model Requirements and JAVA Programs MVP 2 1

Distributed Systems Programming F29NM1 2. Promela I. Andrew Ireland. School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh

SWEN-220 Mathematical Models of Software. Concurrency in SPIN Interleaving

Formal Verification by Model Checking

Formal Specification and Verification

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

TOWARDS AUTOMATED VERIFICATION OF WEB SERVICES

Proving Dekker with SPIN and PROMELA

A Verification Approach for GALS Integration of Synchronous Components

Distributed Systems Programming (F21DS1) SPIN: Formal Analysis I

Application of Formal Verification to Software Security

Distributed Systems Programming (F21DS1) SPIN: Formal Analysis II

Model checking Timber program. Paweł Pietrzak

Distributed Systems Programming (F21DS1) SPIN: Simple Promela INterpreter

Modeling a Cache Coherence Protocol with the Guarded Action Language

Hello World. Slides mostly a reproduction of Theo C. Ruys SPIN Beginners Tutorial April 23, Hello() print "Hello"

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

The Design of a Distributed Model Checking Algorithm for Spin

Using Spin to Help Teach Concurrent Programming

transformation of PROMELA models into Channel Systems,

LTL Reasoning: How It Works

Mapping of UML Diagrams to Extended Petri Nets for Formal Verification

Formal Semantics. Prof. Clarkson Fall Today s music: Down to Earth by Peter Gabriel from the WALL-E soundtrack

Using Model Checking with Symbolic Execution for the Verification of Data-Dependent Properties of MPI-Based Parallel Scientific Software

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

On Nested Depth First Search

Directed Model Checking for PROMELA with Relaxation-Based Distance Functions

Lexical Analysis. Introduction

SPIN, PETERSON AND BAKERY LOCKS

Chapter 8. Statement-Level Control Structures

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

these developments has been in the field of formal methods. Such methods, typically given by a

SWEN-220 Mathematical Models of Software. Process Synchronization Critical Section & Semaphores

TRIAL-EXAM Software Engineering using Formal Methods TDA293 (TDA292) / DIT270. Only dictionaries may be used. Other aids are not allowed!

Mosig M1 - PLSCD Written exam

Lexical Considerations

Testing Concurrent Programs: Model Checking SPIN. Bengt Jonsson

Material: Specification and Reasoning. Book: Logic in Computer Science, M.Huth, M.Ryan, Cambridge University Press. Lectures mondays here,

Shared Variables and Interference

Ch 9: Control flow. Sequencers. Jumps. Jumps

Lexical Considerations

Formal Modeling for Persistence Checking of Signal Transition Graph Specification with Promela

Principles of Protocol Design MVP 10A 1

Decision Making and Loops

Lexical Analysis. Lecture 3. January 10, 2018

CSE 307: Principles of Programming Languages

Advanced features of Functional Programming (Haskell)

Expression and Operator

To Store or Not To Store

Principles of Protocol Design. MVP10 plan. What is a protocol? Typical SPIN applications. The three parts of a protocol description

User-defined Functions. Conditional Expressions in Scheme

Transcription:

Logic Model Checking Lecture Notes 14:18 Caltech 118 January-March 2006 Course Text: The Spin Model Checker: Primer and Reference Manual Addison-Wesley 2003, ISBN 0-321-22862-6, 608 pgs.

Logic Model Checking [14 of 18] 2 Promela semantics A B chan x = [0] of bit ; chan y = [0] of bit ; active proctype A() x!0 unless y!0 active proctype B() y?0 unless x?0 what precisely does this mean? what are the possible executions? x!0 y!0 stop y?0 x?0 stop red arrows take priority over white arrows... two rendezvous handshakes seem possible: y!0 <-> y?0 and x!0 <-> x?0 can you tell which can happen without running Spin...? if you use this method and get a different answer from the Spin simulator and the Spin verifier, which answer is right?

the semantics of Promela proctypes and automata Logic Model Checking [14 of 18] 3 active proctype not_euclid() S: if :: x == y -> assert(x!= y); goto L :: x > y -> L: x = x - y :: x < y -> y = y - x fi; E: printf( %d\n, x) x==y assert x=x-y start S: L: x>y y=y-x x<y a Spin model defines a system of: states and state transformers (transitions) state is maintained in sets of process counters (control flow states) local and global variables and message channels E: stop printf( %d\n,x) ;, ->, if-fi, do-od, goto, etc. are only used to define the transition structure (not the state transformers themselves) the only state transformers are the basic statements: assignment, (expr), printf, assert, send, receive

the semantics of Promela proctypes and automata Logic Model Checking [14 of 18] 4 active proctype not_euclid() S: if :: x == y -> assert(x!= y); goto L :: x > y -> L: x = x - y :: x < y -> y = y - x fi; E: printf( %d\n, x) x==y assert x=x-y start S: L: x>y y=y-x x<y a Spin model defines a system of: states and state transformers (transitions) state is maintained in sets of process counters (control flow states) local and global variables and message channels E: stop printf( %d\n,x) ;, ->, if-fi, do-od, goto, etc. are only used to define the transition structure (not the state transformers themselves) the only state transformers are the basic statements: assignment, (expr), printf, assert, send, receive

Logic Model Checking [14 of 18] 5 operational model to define the semantics of the modeling language, we can define an operational model in terms of states and state transformers (transitions) we have to define what a global system state is we have to define what a state transition is i.e., how the next-state relation is defined global system states are defined in terms of a small number of primitive objects: we have to define: variables, messages, message channels, and processes state transitions are defined with the help of basic statements that label transitions the alphabet of the underlying automata there are only 6 types of labels in the alphabet: assignment, condition, etc. we have to define: transitions, transition selection, and transition execution

Logic Model Checking [14 of 18] 6 transitions L 1 assignment statement assert statement condition statement printf statement send statement receive statement given an arbitrary global state of the system, determine the set of possible immediate successor states this means determining 3 things: 1. statement executability rules 2. statement selection rules 3. the effect of a statement execution L i s s? we only have to define single-step semantics to define the full language L n the 3 parts of the semantics definition are defined over 4 types of objects: 1. variables 2. messages 3. message channels 4. processes we ll define these first

operational model variables, messages, channels, processes, transitions, global states Logic Model Checking [14 of 18] 7 a promela variable is defined by a five-tuple name,scope,domain,inival,curval domain: e.g., -2 15..2 15-1 name scope: global inival x: 2 short x=2, y=1; active proctype not_euclid() S: if :: x > y -> L: x = x - y :: x < y -> y = y - x :: x == y -> assert(x!= y); goto L fi; E: printf( %d\n, x) curval of x at S: 2 curval of x at E: 1

operational model variables, messages, channels, processes, transitions, global states Logic Model Checking [14 of 18] 8 a message is a finite, ordered set of variables (messages are stored in channels defined next) mtype = req, resp, ack ; chan q = [2] of mtype, bit ; active proctype not_very_useful() bit p; do :: q?req,p -> q!resp,p :: q?resp,p -> q!ack,1-p :: q?ack,_ :: timeout -> break od place names for values held in message channel: slot 1.field 1 slot 1.field 2 domains: mtype bit parallel value assignment

Logic Model Checking [14 of 18] 9 operational model variables, messages, channels, processes, transitions, global states a message channel is defined by a 3-tuple ch_id, nslots, contents chan q = [2] of mtype, bit ; a ch_id is an integer 1..MAXQ that can be stored in a variable (ch_id s <= 0 or > MAXQ do not correspond to any instantiated channel, so the default initial value of a chan variable 0 is not a valid ch_id) an ordered set of messages maximally with nslots elements: slot 1.field 1, slot 1.field 2, slot 2.field 1, slot 2.field 2 channels always have global scope but variables of type chan are either local or global, (so, ch_id s are always meaningful when passed from one process to another)

Logic Model Checking [14 of 18] 10 channel scope chan r = [0] of chan ; r global objects C1 global variable r holds the ch_id of C1 C1 never disappears active proctype A() chan q = [0] of int ; r!q; q?100 active proctype B() chan s; r?s; s!100 in the initial system state r, q, s, C1, and C2 all exist r points to C1, q points to C2 q local objects s C2 local variable q in A holds the ch_id of C2 (a global object) C2 is created when A() is instantiated it disappears when A() disappears local variable s in B is initialized to 0 (not a valid ch_id) it is set to C2 in the receive from r == C1 C2 is a globally visible object with a limited lifetime...

Logic Model Checking [14 of 18] 11 operational model variables, messages, channels, processes, transitions, global states a process is defined by a six-tuple pid, lvars, lstates, inistate, curstate, transitions the current state process instantiation number the initial state a finite set of integers defining local proc states a finite set of transitions (to be defined) between elements of lstates finite set of local variables process p p.curstate p.pid etc.

Logic Model Checking [14 of 18] 12 operational model variables, messages, channels, processes, transitions, global states a transition is defined by a seven-tuple tri_id, source-state, target-state, cond, effect, priority, rv (x<y) nil x<y predefined system variables that are used to define the semantics of unless and rendezvous condition and effect are defined for each basic statement, and they are typically defined on variable and channel values, possibly also on process states transition t: t.source t.target t.cond t.effect etc.

Logic Model Checking [14 of 18] 13 operational model variables, messages, channels, processes, transitions, global states a global state is defined by a eight-tuple gvars, procs, chans, exclusive, handshake, timeout, else, stutter a finite set of global variables a finite set of processes a finite set of message channels predefined integer system variables that are used to define the semantics of atomic, d_step, and rendezvous the global system state is called the system state vector for stutter extension rule predefined Boolean system variables

Logic Model Checking [14 of 18] 14 one-step semantics assignment statement assert statement condition statement printf statement send statement receive statement L 1 s s? L n L i given an arbitrary global state of the system, determine the set of possible immediate successor states we ve defined the only 4 types of objects that hold state: 1. variables 2. messages 3. channels and 4. processes to define a one-step semantics, we have to define 3 more things: 1. transition executability rules 2. transition selection rules 3. the effect of transition we do so by defining an algorithm: an implementation-independent semantics interpretation engine for Spin

Logic Model Checking [14 of 18] 15 defining the next-state relation the Promela semantics engine global states s, s processes p, p transitions t, t E a set of pairs p,t to be defined the easy part: state updating 1 while ((E = executable(s))!= ) 2 3 for-some (process p and transition t) from E 4 s' = apply(t.effect, s) 5 6 if (handshake == 0) 7 s = s' 8 p.curstate = t.target 9 else 10 /* try to complete rv handshake */ 11 E' = executable(s') 12 /* if E' is, s is unchanged */ 13 14 for-some (process p and transition t') from E' 15 s = apply(t'.effect, s') 16 p.curstate = t.target 17 p'.curstate = t'.target 18 handshake = 0 19 20 21 23 while (stutter) s = s /* stutter extension rule */

executability rules the hard part: transition selection global states s, s processes p, p transitions t, t 1 Set 2 executable(state s) 3 new Set E 4 new Set e 5 6 E = 7 timeout = false 8 AllProcs: 9 29 30 31 if (E == and exclusive!= 0) 32 exclusive = 0 33 goto AllProcs 34 35 if (E == and timeout == false) 36 timeout = true 37 goto AllProcs 38 39 40 return E /* executable transitions */ 41 9 for each active process p 10 if (exclusive == 0 11 or exclusive == p.pid) 12 for u from high to low /* priority */ 13 e = ; else = false 14 OneProc: for each transition t in p.trans 15 if (t.source == p.curstate 16 and t.prty == u 17 and (handshake == 0 18 or handshake == t.rv) 19 and eval(t.cond) == true) 20 add (p,t) to set e 21 22 if (e!= ) 23 add all elements of e to E 24 continue break /* on to next process */ 25 else if (else == false) 26 else = true 27 goto OneProc 28 /* else lower the priority */ 29 next: extensions for timeout, else rendezvous, atomic, unless, stutter Logic Model Checking [14 of 18] 16

Logic Model Checking [14 of 18] 17 executability rules the hard part: transition selection global states s, s processes p, p transitions t, t 1 Set 2 executable(state s) 3 new Set E 4 new Set e 5 6 E = 7 timeout = false 8 AllProcs: 9 29 30 31 if (E == and exclusive!= 0) 32 exclusive = 0 33 goto AllProcs 34 35 if (E == and timeout == false) 36 timeout = true 37 goto AllProcs 38 39 40 return E /* executable transitions */ 41 9 for each active process p 10 if (exclusive == 0 11 or exclusive == p.pid) 12 for u from high to low /* priority */ 13 e = ; else = false 14 OneProc: for each transition t in p.trans 15 if (t.source == p.curstate 16 and t.prty == u 17 and (handshake == 0 18 or handshake == t.rv) 19 and eval(t.cond) == true) 20 add (p,t) to set e 21 22 if (e!= ) 23 add all elements of e to E 24 continue break /* on to next process */ 25 else if (else == false) 26 else = true 27 goto OneProc 28 /* else lower the priority */ 29 next: extension for else

Logic Model Checking [14 of 18] 18 executability rules the hard part: transition selection global states s, s processes p, p transitions t, t 1 Set 2 executable(state s) 3 new Set E 4 new Set e 5 6 E = 7 timeout = false 8 AllProcs: 9 29 30 31 if (E == and exclusive!= 0) 32 exclusive = 0 33 goto AllProcs 34 35 if (E == and timeout == false) 36 timeout = true 37 goto AllProcs 38 39 40 return E /* executable transitions */ 41 9 for each active process p 10 if (exclusive == 0 11 or exclusive == p.pid) 12 for u from high to low /* priority */ 13 e = ; else = false 14 OneProc: for each transition t in p.trans 15 if (t.source == p.curstate 16 and t.prty == u 17 and (handshake == 0 18 or handshake == t.rv) 19 and eval(t.cond) == true) 20 add (p,t) to set e 21 22 if (e!= ) 23 add all elements of e to E 24 continue break /* on to next process */ 25 else if (else == false) 26 else = true 27 goto OneProc 28 /* else lower the priority */ 29 next: extension for rendezvous semantics

Logic Model Checking [14 of 18] 19 adding semantics for rendezvous 1:2 the predefined variable handshake global states s, s processes p, p transitions t, t 1 while ((E = executable(s))!= ) 2 3 for-some (process p and transition t) from E 4 s' = apply(t.effect, s) 5 6 if (handshake == 0) 7 s = s' 8 p.curstate = t.target 9 else 10 /* try to complete a rv handshake */ 11 E' = executable(s') 12 /* if E' is, s is unchanged */ 13 can set handshake 14 for-some (process p and transition t') from E' 15 s = apply(t'.effect, s') 16 p.curstate = t.target 17 p'.curstate = t'.target 19 18 handshake = 0 20 21 22 while (stutter) s = s /* stutter extension rule */

Logic Model Checking [14 of 18] 20 adding semantics for rendezvous 2:2 the predefined variable handshake global states s, s processes p, p transitions t, t 1 Set 2 executable(state s) 3 new Set E 4 new Set e 5 6 E = 7 timeout = false 8 AllProcs: 9 29 30 31 if (E == and exclusive!= 0) 32 exclusive = 0 33 goto AllProcs 34 35 if (E == and timeout == false) 36 timeout = true 37 goto AllProcs 38 39 40 return E /* executable transitions */ 41 9 for each active process p 10 if (exclusive == 0 11 or exclusive == p.pid) 12 for u from high to low /* priority */ 13 e = ; else = false 14 OneProc: for each transition t in p.trans 15 if (t.source == p.curstate 16 and t.prty == u 17 and (handshake == 0 18 or handshake == t.rv) 19 and eval(t.cond) == true) 20 add (p,t) to set e 21 22 if (e!= ) 23 add all elements of e to E 24 break /* on to next process */ 25 else if (else == false) 26 else = true 27 goto OneProc 28 /* else lower the priority */ 29 next: extensions for atomic and d_step sequences

adding semantics for atomic sequences the predefined variable exclusive Logic Model Checking [14 of 18] 21 global states s, s processes p, p transitions t, t 1 Set 2 executable(state s) 3 new Set E 4 new Set e 5 6 E = 7 timeout = false 8 AllProcs: 9 29 30 31 if (E == and exclusive!= 0) 32 exclusive = 0 33 goto AllProcs 34 35 if (E == and timeout == false) 36 timeout = true 37 goto AllProcs 38 39 40 return E /* executable transitions */ 41 9 for each active process p 10 if (exclusive == 0 11 or exclusive == p.pid) 12 for u from high to low /* priority */ 13 e = ; else = false 14 OneProc: for each transition t in p.trans 15 if (t.source == p.curstate 16 and t.prty == u 17 and (handshake == 0 18 or handshake == t.rv) 19 and eval(t.cond) == true) 20 add (p,t) to set e 21 22 if (e!= ) 23 add all elements of e to E 24 break /* on to next process */ 25 else if (else == false) 26 else = true 27 goto OneProc 28 /* else lower the priority */ 29 next: extension for unless sequences

adding semantics for unless statement priority levels Logic Model Checking [14 of 18] 22 global states s, s processes p, p transitions t, t 1 Set 2 executable(state s) 3 new Set E 4 new Set e 5 6 E = 7 timeout = false 8 AllProcs: 9 29 30 31 if (E == and exclusive!= 0) 32 exclusive = 0 33 goto AllProcs 34 35 if (E == and timeout == false) 36 timeout = true 37 goto AllProcs 38 39 40 return E /* executable transitions */ 41 9 for each active process p 10 if (exclusive == 0 11 or exclusive == p.pid) 12 for u from high to low /* priority */ 13 e = ; else = false 14 OneProc: for each transition t in p.trans 15 if (t.source == p.curstate 16 and t.prty == u 17 and (handshake == 0 18 or handshake == t.rv) 19 and eval(t.cond) == true) 20 add (p,t) to set e 21 22 if (e!= ) 23 add all elements of e to E 24 break /* on to next process */ 25 else if (else == false) 26 else = true 27 goto OneProc 28 /* else lower the priority */ 29 next: adding the stutter extension rule

Logic Model Checking [14 of 18] 23 the stutter extension rule global states s, s processes p, p transitions t, t 1 while ((E = executable(s))!= ) 2 3 for some (process p and transition t) from E 4 s' = apply(t.effect, s) 5 6 if (handshake == 0) 7 s = s' 8 p.curstate = t.target 9 else 10 /* try to complete rv handshake */ 11 E' = executable(s') 12 /* if E' is, s is unchanged */ 13 14 for some (process p and transition t') from E' 15 s = apply(t'.effect, s') 16 p.curstate = t.target 17 p'.curstate = t'.target 18 handshake = 0 19 break 20 21 22 while (stutter) s = s /* stutter extension rule */

Logic Model Checking [14 of 18] 24 example 1:3 using the semantics engine chan x = [0] of bit ; chan y = [0] of bit ; active proctype A() x?0 unless y!0 active proctype B() y?0 unless x!0 x?0 y!0 end unless escapes have higher priority y?0 x!0 end handshake=1 x!0 y!0 x?0 y?0 handshake=2 Q: what is the combined system behavior? A: a non-deterministic selection between x!0;x?0 and y!0;y?0 end

Logic Model Checking [14 of 18] 25 example 2:3 using the semantics engine chan x = [0] of bit ; chan y = [0] of bit ; active proctype A() x!0 unless y!0 x!0 y!0 unless escapes have higher priority y?0 x?0 active proctype B() y?0 unless x?0 y!0 y?0 end handshake=2 end Q: what is the combined system behavior? is it x!0;x?0 or y!0;y?0? A: only y!0;y?0 can happen end

Logic Model Checking [14 of 18] 26 example 3:3 using the semantics engine chan x = [0] of bit ; chan y = [0] of bit ; active proctype A() x!0 unless y?0 x!0 y?0 unless escapes have higher priority y!0 x?0 active proctype B() y!0 unless x?0 handshake=1 x!0 y!0 end end Q: what is the combined system behavior? is it x!0;x?0 or y!0;y?0 handshake=2? x?0 end y?0 A: a non-deterministic selection between x!0;x?0 and y!0;y?0

Logic Model Checking [14 of 18] 27 compare chan x = [0] of bit ; chan y = [0] of bit ; active proctype A() x!0 unless y?0 active proctype B() y!0 unless x?0 chan x = [0] of bit ; chan y = [0] of bit ; active proctype A() x?0 unless y!0 active proctype B() y?0 unless x!0 x!0 y!0 x!0 y!0 x?0 y?0 x?0 y?0 end same global behavior but for very different reasons... end

Logic Model Checking [14 of 18] 28 what about never claims, etc.? meta-semantics correctness properties do not define new behavior, they just monitor it and complain bitterly when interesting things are seen a verification engine can make pronouncements on properties of behavior this is at a higher level of semantics: it interprets the goodness or badness of a behavior instead of defining the behavior itself a never claim is designed to select those behaviors that could possibly lead to interesting behavior the distinction between good and bad, interesting and uninteresting is a meta-statement about behavior: not part of the behavior itself, and therefore not part of the operational semantics...