Shin Hong, KAIST17 th April,2007 1/33 Provable Software Laboratory, CS KAIST.

Slides:



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

Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
1 Reasoning with Promela Safety properties bad things do not happen can check by inspecting finite behaviours Liveness properties good things do eventually.
The SPIN System. What is SPIN? Model-checker. Based on automata theory. Allows LTL or automata specification Efficient (on-the-fly model checking, partial.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Partial Order Reduction: Main Idea
1 Model checking. 2 And now... the system How do we model a reactive system with an automaton ? It is convenient to model systems with Transition systems.
CS 290C: Formal Models for Web Software Lecture 3: Verification of Navigation Models with the Spin Model Checker Instructor: Tevfik Bultan.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
PROTOCOL VERIFICATION & PROTOCOL VALIDATION. Protocol Verification Communication Protocols should be checked for correctness, robustness and performance,
CS6133 Software Specification and Verification
UPPAAL Introduction Chien-Liang Chen.
Formal verification in SPIN Karthikeyan Bhargavan, Davor Obradovic CIS573, Fall 1999.
/ PSWLAB P ROMELA Semantics from “THE SPIN MODEL CHECKER” by G. J. Holzmann Presented by Hong,Shin 5 th Oct :021PROMELA Semantics.
Frederico Araujo CS6362 – Fall 2010 The SPIN Model Checker.
CS 267: Automated Verification Lecture 10: Nested Depth First Search, Counter- Example Generation Revisited, Bit-State Hashing, On-The-Fly Model Checking.
1 Temporal Claims A temporal claim is defined in Promela by the syntax: never { … body … } never is a keyword, like proctype. The body is the same as for.
SPIN Verification System The Model Checker SPIN By Gerard J. Holzmann Comp 587 – 12/2/09 Eduardo Borjas – Omer Azmon ☐ ☐
S. Ramesh Model-Checking Distributed Software S. Ramesh IIT Bombay.
The Spin Model Checker Promela Introduction Nguyen Tuan Duc Shogo Sawai.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
1 Spin Model Checker Samaneh Navabpour Electrical and Computer Engineering Department University of Waterloo SE-464 Summer 2011.
Spin Tutorial (some verification options). Assertion is always executable and has no other effect on the state of the system than to change the local.
Temporal Logic Model- checking with SPIN COMP6004 Stéphane Lo Presti Part 4: Specifications.
Model Checking. Used in studying behaviors of reactive systems Typically involves three steps: Create a finite state model (FSM) of the system design.
1 Carnegie Mellon UniversitySPINFlavio Lerda SPIN An explicit state model checker.
On-the-fly Model Checking from Interval Logic Specifications Manuel I. Capel & Miguel J. Hornos Dept. Lenguajes y Sistemas Informáticos Universidad de.
Review of the automata-theoretic approach to model-checking.
Automata and Formal Lanugages Büchi Automata and Model Checking Ralf Möller based on slides by Chang-Beom Choi Provable Software Lab, KAIST.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
CS 290C: Formal Models for Web Software Lecture 4: Model Checking Navigation Models with Spin Instructor: Tevfik Bultan.
The Model Checker SPIN Written by Gerard J. Holzmann Presented by Chris Jensen.
LTL – model checking Jonas Kongslund Peter Mechlenborg Christian Plesner Kristian Støvring Sørensen.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 4: SMT-based Bounded Model Checking of Concurrent Software.
1 Carnegie Mellon UniversitySPINFlavio Lerda Bug Catching SPIN An explicit state model checker.
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
Regular Model Checking Ahmed Bouajjani,Benget Jonsson, Marcus Nillson and Tayssir Touili Moran Ben Tulila
Correctness requirements. Basic Types of Claims Basic assertions End-state labels Progress-state labels Accept-state labels Never claims Trace assertions.
Scientific Computing By: Fatima Hallak To: Dr. Guy Tel-Zur.
Korea Advanced Institute of Science and Technology The Spin Model Checker - Advanced Features Moonzoo Kim CS Dept. KAIST.
CS6133 Software Specification and Verification
Survey on Trace Analyzer (2) Hong, Shin /34Survey on Trace Analyzer (2) KAIST.
Sept COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 15 More Advanced Program Properties: Temporal logic and jSpin John Gurd,
MODEL CHECKING WITH SPIN MODELING AND VERIFICATION WITH SPIN ANDREA ORLANDINI – ISTC (CNR) TexPoint fonts used in EMF. Read the TexPoint manual before.
1 CSEP590 – Model Checking and Automated Verification Lecture outline for August 6, 2003.
Temporal Logic Model-checking with SPIN
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Constraints Assisted Modeling and Validation Presented in CS294-5 (Spring 2007) Thomas Huining Feng Based on: [1]Constraints Assisted Modeling and Validation.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
/ PSWLAB S PIN Search Optimization from “THE SPIN MODEL CHECKER” by G. Holzmann Presented by Hong,Shin 23 th Nov SPIN Search.
Lecture 4 Introduction to Promela. Promela and Spin Promela - process meta language G. Holzmann, Bell Labs (Lucent) C-like language + concurrency dyamic.
1 Temporal logic. 2 Prop. logic: model and reason about static situations. Example: Are there truth values that can be assigned to x,y simultaneously.
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
About Alternating Automata Daniel Choi Provable Software Laboratory KAIST.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
Symbolic Model Checking of Software Nishant Sinha with Edmund Clarke, Flavio Lerda, Michael Theobald Carnegie Mellon University.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Model Checking Lecture 2. Model-Checking Problem I |= S System modelSystem property.
Model Checking Lecture 2 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
Formal verification in SPIN
CSE 503 – Software Engineering
Automatic Verification
The Spin Model Checker - Advanced Features
Recognizing Safety and Liveness
An explicit state model checker
A Refinement Calculus for Promela
Translating Linear Temporal Logic into Büchi Automata
COMP60621 Designing for Parallelism
The Spin Model Checker - Advanced Features
CSE 503 – Software Engineering
Presentation transcript:

Shin Hong, KAIST17 th April,2007 1/33 Provable Software Laboratory, CS KAIST

Contents  Introduction  PROMELA  Linear Temporal Logic  Automata-theoretic software verification  Example : Simple Elevator Provable Software Laboratory, CS KAIST /33 2

 SPIN is a software system to verify asynchronous process system model. 3 Provable Software Laboratory, CS KAIST /33

Introduction  Software have taken big portion of system.  These software should fulfill its responsibility. Failure of System Software might be a disaster. 4 Provable Software Laboratory, CS KAIST /33

Introduction  To avoid software system failure,  We want to prove correctness of a system software. → Verification of software is needed. 5 Provable Software Laboratory, CS KAIST /33

Introduction  Testing  Operate the program in some representative situation and verify whether it behaves as expected.  Dictum of Dijkstra “ Program testing can be used to show the presence of bugs, but never to show their absence. ”  Model Checking  Describing a system as an FSM and verifying whether the system’s behavior satisfies the desired properties. 6 Provable Software Laboratory, CS KAIST /33

Peterson’s mutex Provable Software Laboratory, CS KAIST / processes 3 processes 4 processes erson/index.html

Introduction  We want to prove correctness of system software.  Concurrency → concurrent software may involve asynchrony. → Extremely complex.  Embedded System → Completeness of verification is needed.  Model checking is more suitable for verification of system software. 8 Provable Software Laboratory, CS KAIST /33

Introduction  Model Checking  Requirements System ↓ modeling languages ↓  Requirements properties System model Model Checking (State Exploration) Okay Counterexample Satisfied Not satisfied 9 Provable Software Laboratory, CS KAIST /33

Introduction  Model Checking  Requirements System ↓  Requirements properties System model Model Checking (State Exploration) Okay Counterexample Satisfied Not satisfied State Explosion 10 Provable Software Laboratory, CS KAIST /33

Introduction  SPIN is designed to provide  An intuitive, program-like notation for specifying design choices unambiguously without implementation detail.  Powerful, concise, notation for expressing general correctness requirements.  Scalability : Reduce limitation of problem size, machine memory size, maximum runtime. 11 Provable Software Laboratory, CS KAIST /33

Introduction  Model Checker SPIN  Requirements System Linear Temporal Logic PROMELA ↓ Linear Temporal Logic ↓ PROMELA  Requirements properties System model Model Checking (State Exploration) Okay Counterexample Satisfied Not satisfied On-the-fly verification Negative Claim Algorithms 12 Provable Software Laboratory, CS KAIST /33

PROMELA (1/5)  Process Meta Language  Describes the behavior of systems of potentially interacting processes.  Processes, Objects, Message channels 13 Provable Software Laboratory, CS KAIST /33

PROMELA (2/5)  Process  Is instantiations of ‘proctype’  defines behavior of system.  is consisted of declaration+statements  Data Object  Basic data types : bool, byte, mtype, pid, int, etc.  Two levels of scope only : Global and Process local  Data structure using ‘typedef’  Array 14 Provable Software Laboratory, CS KAIST /33

PROMELA (3/5)  Message channels  model the exchange of data between processes  declared by ‘chan’. Provable Software Laboratory, CS KAIST /33 15

PROMELA (4/5)  Statements  Assignments and Expressions  Deterministic steps  Non-deterministic steps  Selection  Repetition  I/O  Communication  Message channel Provable Software Laboratory, CS KAIST /33 16

PROMELA (5/5) chan STDIN ; proctype Euclid(int x, y){ do :: (x > y) -> x = x – y :: (x y = y – x :: (x == y) -> goto done do ; done: printf(“answer: %d\n”, x) } init { int a, b ; STDIN?a ; STDIN?b; run Euclid(a,b)} Provable Software Laboratory, CS KAIST /33 17 Message channel & Standard Input Creating process Repetition Selection Standard output Declaration of data objects Communication through channel Instantiate a proctype

Automata-Theoretic Software Verification Linear Temporal Logic (1/3)  Fixed set of atomic formulas and temporal connectives.  Syntax Φ ::= T | F | p | ! Φ | Φ^ Φ | Φ ∨ Φ | X Φ| ΦU Φ 18 Provable Software Laboratory, CS KAIST /33

Automata-Theoretic Software Verification Linear Temporal Logic (2/3) an infinite word ξ=x 0 x 1 … over alphabet P(Prop) ξ |= qiff q ∈ x0,for q ∈ P, ξ |= ¬ Φ iff not ξ |= Φ, ξ |= Φ 1 ^ Φ 2 iff ξ |= Φ 1 and ξ |= Φ 2 ξ |= Φ 1 ∨ Φ 2 iff ξ |= Φ 1 or ξ |= Φ 2 ξ |= XΦiff ξ 1 |= Φ ξ |= Φ 1 UΦ 2 iff there is an i≥0 s.t. ξ i |= Φ 1 and ξ j |= Φ 1 for all 0 ≤ j < i 19 Provable Software Laboratory, CS KAIST /33

Automata-Theoretic Software Verification Linear Temporal Logic (3/3)  Safety Property  Liveness Property 20 Provable Software Laboratory, CS KAIST /33

Automata-Theoretic Software Verification Finite State Program  P = (Q, q 0, R, V)  Q : a finite set of states.  q 0 : initial state  R ⊆ Q X Q : accessibility relation, allowing non-determinism. Assume that R is total so that a terminate d execution as repeating forever its last st ate.  V : Q → P (Prop) 21 Provable Software Laboratory, CS KAIST /33

Automata-Theoretic Software Verification Büchi automaton A generalized Büchi automaton A = (Σ, Q, Q 0, ρ, F) where  Σ: alphabet  Q : a finite set of states,  Q 0 ⊆ Q : initial states  ρ ⊆ Q X Σ X Q :transition relation  F ⊆ P(P(Q)) : a set of sets of accepting states. An accepting execution σ is an execution such that for each acceptance set F i ∈ F, there exists at least one state q ∈ F i that appears infinitely often in σ. 22 Provable Software Laboratory, CS KAIST /33

Automata-Theoretic Software Verification A finite state program P=(W,w 0, →,V) can be viewed as a Büchi automaton A p =(∑,W,{w 0 }, ρ,W) where ∑=P(Prop) s’ ∈ ρ(s,a) iff s → s’ and a=V(s)  Any infinite run of the automaton is accepting 23 Provable Software Laboratory, CS KAIST /33

Automata-Theoretic Software Verification  Global reachability graph : Asynchronous product of processes  Requirement properties Provable Software Laboratory, CS KAIST 24/34

Automata-Theoretic Software Verification  For a finite-state program P and LTL formula Ψ,  There exists a B ü chi automaton A Ψ that accept exactly the computations satisfying ψ.  The verification problem is to verify that all infinite words accepted by the automaton A P satisfy the formula Ψ.  L ω (A P ) ⊆ L ω (A Ψ ) ~ L ω (A P ) ∩ L ω (A Ψ ) = φ 25 Provable Software Laboratory, CS KAIST /33

Automata-Theoretic Software Verification L ω (A) = L ω (A 1 ) ∩ L ω (A 2 ) let A 1 =(Σ,Q 1,Q 0 1,ρ 1,F 1 ),A2=(Σ,Q 2, Q 0 2,ρ 2,F 2 ) Let A=(Σ,Q 1,Q 0,ρ,F) where Q=Q 1 XQ 2 X{1,2}, Q0=Q 0 1 XQ 0 2 X{1},F=F 1 XS 2 X{1} (s’, t’, j) ∈ ρ((s,t,i),a) if s’ ∈ ρ 1 (s,a), t’ ∈ ρ 2 (s,a)and i=j unless i=1 and s ∈ F 1, in which case j=2 or i=2 and t ∈ F 2, in which case j=1. The acceptance condition guarantee that both tracks visit accepting state infinitely often if and only if it goes infinitely often through F 1 XS 2 X{1}. 26 Provable Software Laboratory, CS KAIST /33

Simple Elevator  3 floor, 1 elevator  The elevator goes up until 3 rd floor and then goes down until 1 st floor.  Each floor has its door to elevator. Each door may open when elevator is at the same floor. Provable Software Laboratory, CS KAIST / rd floor 2 nd floor 1 st floor Elevator door3 door2 door1 from “System and Software Verification” by B’erard et al

Simple Elevator  3 floor, 1 elevator  The elevator goes up until 3 rd floor and then goes down until 1 st floor.  Each floor has its door to elevator. Each door may open when elevator is at the same floor. Provable Software Laboratory, CS KAIST / rd floor 2 nd floor 1 st floor Elevator door3 door1 door2

Simple Elevator  3 floor, 1 elevator  The elevator goes up until 3 rd floor and then goes down until 1 st floor.  Each floor has its door to elevator. Each door may open when elevator is at the same floor. Provable Software Laboratory, CS KAIST / rd floor 2 nd floor 1 st floor Elevator door2 door1 door3

Simple Elevator::C #define OPENED 1 #define CLOSED 1 sem_t openclosedoor[3] ; static byte whatfloor ; static byte doorisopen[3] ; void door(byte floor) { while(1) { sem_acquire(openclosedoor[floor-1]) ; doorisopen[floor-1] = OPENED ; doorisopen[floor-1] = CLOSED ; sem_release(openclosedoor[floor-1]) ; } Provable Software Laboratory, CS KAIST /33 30 void elevator() { byte floor = 1 ; while(1) { if ((rand() % 2) == 0) { if (floor != 3) floor++ ; else if (floor != 1) floor-- ; } else { sem_release(openclosedoor[floor-1]) ; sem_acquire(openclosedoor[floor-1]) ; }

Simple Elevator::C void main() { int i ;byte * temp ;pid_t pid ; sem_init(openclosedoor[0], 0) ; sem_init(openclosedoor[1], 0) ; sem_init(openclosedoor[2], 0) ; for (i = 0 ; i < 3 ; i++) { temp = (byte *)malloc(sizeof(byte)) ; *temp = i ; pid = thread_create(door, temp) ; thread_join(pid) ; } Provable Software Laboratory, CS KAIST /33 31

Simple Elevator::PROMELA bit doorisopen[3] ; chan openclosedoor=[0] of {byte, bit} proctype door(byte i) { do :: openclosedoor?eval(i), 1 ; doorisopen[i-1] = 1 ; doorisopen[i-1] = 0 ; openclosedoor!i,0 od } Provable Software Laboratory, CS KAIST /33 32 proctype elevator() { byte floor = 1 ; do :: (floor != 3) -> floor++ :: (floor != 1) -> floor— :: openclosedoor!floor,1 ; openclosedoor?eval(floor),0; do } init { atomic{ run door(1) ; run door(2) ; run door(3) ; run elevator() ; }

Simple Elevator ::Verification  assert( doorisopen[i-1]&&!doorisopen[i%3]&&!doorisopen[(i+1)%3]); #define open1 doorisopen[0]#define open2 doorisopen[1] #define open3 doorisopen[2]#define close1 !doorisopen[0] #define close2 !doorisopen[1]#define close3 !doorisopen[2]  [](open1 -> X closed1)  [](open2 -> X closed2)  [](open3 -> X closed3)  <>(open1 || open2 || open3) Provable Software Laboratory, CS KAIST /33 33

Further Reading  ω-language  Partial order reduction  Memory management technique in SPIN Provable Software Laboratory, CS KAIST /33 34

References [1] The Model Checker SPIN, G.J.Holzmann. [2] The SPIN model checker, G.J.Holzmann. [3] Systems and Software Verification, Berard et al. [4] Simple On-the-fly automatic verification of Linear temporal logic, Vardi et al. [5] An Automata-Theoretic Approach to Linear Temporal Logic, M.Y.Vardi. [6] Moonzoo Kim’s lecture notes on CS750 Fall2006, CS KAIST. Provable Software Laboratory, CS KAIST /33 35

Discussion Provable Software Laboratory, CS KAIST /33 36