Traffic Light Controller Examples in SMV Himanshu Jain Bug catching (Fall 2007)

Slides:



Advertisements
Similar presentations
Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
Advertisements

Chapter 7 - Resource Access Protocols (Critical Sections) Protocols: No Preemptions During Critical Sections Once a job enters a critical section, it cannot.
Introduction to SMV Part 2
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Practice Session 7 Synchronization Liveness Deadlock Starvation Livelock Guarded Methods Model Thread Timing Busy Wait Sleep and Check Wait and Notify.
 Read about Therac-25 at  [  [
1 MODULE name (parameters) “Ontology” “Program” “Properties” The NuSMV language A module can contain modules Top level: parameters less module Lower level.
Model Checking I What are LTL and CTL?. and or dreq q0 dack q0bar.
Process Synchronization Continued 7.2 The Critical-Section Problem.
Mutual Exclusion By Shiran Mizrahi. Critical Section class Counter { private int value = 1; //counter starts at one public Counter(int c) { //constructor.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
5.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 5: CPU Scheduling.
1 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:
Model Checking Inputs: A design (in some HDL) and a property (in some temporal logic) Outputs: Decision about whether or not the property always holds.
CS 267: Automated Verification Lecture 7: SMV Symbolic Model Checker, Partitioned Transition Systems, Counter-example Generation in Symbolic Model Checking.
Model Checking I What are LTL and CTL?. and or dreq q0 dack q0bar D D.
© 2011 Carnegie Mellon University Introduction to SMV Part 2 Arie Gurfinkel (SEI/CMU) based on material by Prof. Clarke and others.
Shared Memory Coordination We will be looking at process coordination using shared memory and busy waiting. –So we don't send messages but read and write.
Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.
SMV Examples Bug Catching in 2006 Fall Oct. 24, 2006.
6: Process Synchronization 1 1 PROCESS SYNCHRONIZATION I This is about getting processes to coordinate with each other. How do processes work with resources.
Lecture 4&5: Model Checking: A quick introduction Professor Aditya Ghose Director, Decision Systems Lab School of IT and Computer Science University of.
1 Using Cadence SMV to verify temporal properties of finite-state machines : Intro to Model Checking October 9, 2008.
Synchronization Principles. Race Conditions Race Conditions: An Example spooler directory out in 4 7 somefile.txt list.c scores.txt Process.
Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.
Predicate Abstraction for Software and Hardware Verification Himanshu Jain Model checking seminar April 22, 2005.
1 Sharing Objects – Ch. 3 Visibility What is the source of the issue? Volatile Dekker’s algorithm Publication and Escape Thread Confinement Immutability.
© 2004 Pearson Addison-Wesley. All rights reserved5-1 Iterations/ Loops The while Statement Other Repetition Statements.
Bash Shell Scripting 10 Second Guide Common environment variables PATH - Sets the search path for any executable command. Similar to the PATH variable.
1 Race Conditions/Mutual Exclusion Segment of code of a process where a shared resource is accessed (changing global variables, writing files etc) is called.
1 Thread Synchronization: Too Much Milk. 2 Implementing Critical Sections in Software Hard The following example will demonstrate the difficulty of providing.
1 Introduction to SMV and Model Checking Mostly by: Ken McMillan Cadence Berkeley Labs Small parts by: Brandon Eames ISIS/Vanderbilt.
The Critical Section Problem
SMV TUTORIAL – Part I Eriko Nurvitadhi Note: content of these slides are from “Getting started with SMV” by K. L. McMillan, Refer to this document.
CS6133 Software Specification and Verification
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
2/19/20031 Introduction to SMV. 2/19/20032 Useful Links CMU Model checking homepage SMV windows version
A brief history of model checking Ken McMillan Cadence Berkeley Labs
1 Example: traffic light controller Guarantee no collisions Guarantee eventual service E S N.
CSC321 Concurrent Programming: §5 Monitors 1 Section 5 Monitors.
CCR Deadlock By: Laura Weiland April 30, Project Description Implement a module to the Train Operating System (TOS) that manages the deadlock problem.
1 A Balanced Introduction to Computer Science, 2/E David Reed, Creighton University ©2008 Pearson Prentice Hall ISBN Chapter 13 Conditional.
CIS 842: Specification and Verification of Reactive Systems Lecture INTRO-Examples: Simple BIR-Lite Examples Copyright 2004, Matt Dwyer, John Hatcliff,
Operating Systems CMPSC 473 Mutual Exclusion Lecture 11: October 5, 2010 Instructor: Bhuvan Urgaonkar.
Review while loops Control variables Example Infinite loop
Monitors and Blocking Synchronization Dalia Cohn Alperovich Based on “The Art of Multiprocessor Programming” by Herlihy & Shavit, chapter 8.
VIS Technology Transfer Course Session 7 Fairness Constraints and Monitors Serdar Tasiran.
Rensselaer Polytechnic Institute CSCI-4210 – Operating Systems David Goldschmidt, Ph.D.
A Tree Based Algorithm fro Distributed Mutual Exclusion Addy Gronquist 11/19/2003.
Automated Composition and Analysis. Web Services: Design and Analysis2 Automated Composition Given a specification of the composite service, find individual.
A Balanced Introduction to Computer Science, 3/E David Reed, Creighton University ©2011 Pearson Prentice Hall ISBN Chapter 13 Conditional.
CGS 3763 Operating Systems Concepts Spring 2013 Dan C. Marinescu Office: HEC 304 Office hours: M-Wd 11: :30 AM.
Program Correctness. The designer of a distributed system has the responsibility of certifying the correctness of the system before users start using.
Synchronization CSCI 3753 Operating Systems Spring 2005 Prof. Rick Han.
Semaphores Chapter 6. Semaphores are a simple, but successful and widely used, construct.
Learning Javascript From Mr Saem
Synchronization Questions answered in this lecture: Why is synchronization necessary? What are race conditions, critical sections, and atomic operations?
Reasoning About Code.
Modeling Mutual Exclusion Algorithms
Module 4 Loops.
Lecture 2 Part 2 Process Synchronization
Semaphores Chapter 6.
Introduction to SMV 2/19/2003.
Process/Thread Synchronization (Part 2)
Lecture 9: SMV: An Introduction
Operating Systems {week 10}
Fast-Track UiPath Developer Module 6: Invoke Code and Invoke Method
Presentation transcript:

Traffic Light Controller Examples in SMV Himanshu Jain Bug catching (Fall 2007)

1 Plan for today  Modeling Traffic Light Controller in SMV  Properties to Check  Four different SMV models for traffic light controller

2 N S W Scenario

3 N S W   No turning

4 N S W Binary traffic lights

5 N S W Safety Property This should not happen

6 N S W Safety Property This should not happen

7 N S W Liveness Property When will the stupid light become green again

8 N S W Liveness Property Thank God! Traffic in each direction must be served

9 Let’s see how to model all this in SMV

10 N S W SMV variables N-go=0 S-go=0 W-go=1 Three Boolean variables track the status of lights

11 N S W SMV variables Three Boolean variables sense the traffic in each direction N-sense =1 S-sense =1 W-sense =0 These variables are called N, Sy, W in the code I will show you

12 Properties we would like to check  Mutual exclusion  SPEC AG !(W-Go & (N-Go | S-Go))  Liveness in North direction  SPEC AG(N-sense & !N-Go -> AF N-Go)  Similar liveness properties for south and west

13 Properties we would like to check  No strict sequencing  We don’t want the traffic lights to give turns to each other (if there is no need for it)  For example, if there is no traffic on west lane, we do not want W-go becoming 1 periodically  We can specify such properties atleast partially  AG(W-Go -> A[W-Go U (!W-Go & A[!W-Go U (N-Go | S-Go)])])  See code other such properties  We want these properties to FAIL

14 N S W SMV modules North module will control South module will control West module will control Main module will -Initialize variables -Start north, south, west modules

15 N S W What if north light is always green and there is always traffic in north direction

16 Fairness Constraints  What if north light is always green and there is always traffic in north direction  We will avoid such scenarios by means of fairness constraints  FAIRNESS running & !(N-Go & N-sense)  On an infinite execution, there are infinite number of states where either north light is not green or there is no traffic in north direction  Similar, fairness constraints for south and west directions

17 Now we look at some concrete implementations

18 Some more variables  To ensure mutual exclusion  We will have two Boolean variables  NS-Lock: denotes locking of north/south lane  EW-Lock: denotes locking of west lane  To remember that there is traffic on a lane  Boolean variables: N-Req, S-Req, W-Req  If N-sense becomes 1, then N-Req is set to true  Similarly, for others….

19 Traffic1.smv MODULE main VAR N : boolean; --senses traffic going along north Sy : boolean; --senses traffic going along south W : boolean; --senses traffic going westward N-Req : boolean; --rememebers that there is traffic along north that needs to go S-Req : boolean; --rememebers that there is traffic along south that needs to go W-Req : boolean; --rememebers that there is traffic along west that needs to go N-Go : boolean; --north direction green light on S-Go : boolean; --south direction green light on W-Go : boolean; --west direction green light on NS-Lock : boolean; --north/south lane locked EW-Lock : boolean; --east/west lane locked north : process north1(NS-Lock, EW-Lock, N-Req, N-Go,N,S-Go); south : process south1(NS-Lock,EW-Lock,S-Req,S-Go,Sy,N-Go); west : process west1(NS-Lock,EW-Lock,W-Req,W-Go,W); ASSIGN init(NS-Lock) := 0; init(Sy) := 0; init(W) := 0; init(W-Req) := 0; …………………..OTHER INITIALIZATIONS

20 MODULE north(NS-Lock, EW-Lock, N-Req, N-Go,N,S-Go) VAR state : {idle, entering, critical, exiting}; ASSIGN init(state) := idle; next(state) := case state = idle : case N-Req = 1 : entering; 1 : state; esac; state = entering & !EW-Lock : critical; state = critical & !N : exiting; state = exiting : idle; 1 : state; esac; next(NS-Lock) := case state = entering & !EW-Lock : 1 ; state = exiting & !S-Go : 0; 1 : NS-Lock; esac; next(N-Req) := case !N-Req & N : 1; state = exiting : 0; 1 : N-Req; esac; next(N-Go) := case state = critical : 1; state = exiting : 0; 1 : N-Go; esac; -- non-deterministically chose N next(N) := {0,1}; FAIRNESS running & !(N-Go & N)

21 Module south is similar Module west1 is a little different Everything seems ok! Let us run a model checker

22 Mutual exclusion fails (Counterexample) 1. All variables zero 2. N-sense=1 (North module executed) 3. S-sense=1 (South module executed) 4. S-Req=1 5. south.state=entering 6. S-sense=0, NS-Lock=1, south.state=critical 7. S-sense=1,S-go=1,south.state=exiting 8. N-Req=1 9. north.state=entering 10. north.state=critical 11. S-Req=0, S-Go=0, NS-Lock=0, south.state=idle 12. W=1 13. W-Req=1 14. west.state=entering 15. EW-lock=1, west.state=critical 16. W-Go=1 17. N-Go=1 One module is executing at each step

23 Mutual exclusion fails (Counterexample) 1. All variables zero 2. N-sense=1 (North module executed) 3. S-sense=1 (South module executed) 4. S-Req=1 5. south.state=entering 6. S-sense=0, NS-Lock=1, south.state=critical 7. S-sense=1,S-go=1,south.state=exiting 8. N-Req=1 9. north.state=entering 10. north.state=critical 11. S-Req=0, S-Go=0, NS-Lock=0, south.state=idle 12. W=1 13. W-Req=1 14. west.state=entering 15. EW-lock=1, west.state=critical 16. W-Go=1 17. N-Go=1 One module is executing at each step Even though north.state is critical the NS-lock is released

24 Mutual exclusion fails (Counterexample) 1. All variables zero 2. N-sense=1 (North module executed) 3. S-sense=1 (South module executed) 4. S-Req=1 5. south.state=entering 6. S-sense=0, NS-Lock=1, south.state=critical 7. S-sense=1,S-go=1,south.state=exiting 8. N-Req=1 9. north.state=entering 10. north.state=critical 11. S-Req=0, S-Go=0, NS-Lock=0, south.state=idle 12. W=1 13. W-Req=1 14. west.state=entering 15. EW-lock=1, west.state=critical 16. W-Go=1 17. N-Go=1 One module is executing at each step One problem is the one-step difference Between North.state=critical and N-Go=1

25 MODULE north(NS-Lock, EW-Lock, N-Req, N-Go,N,S-Go) VAR state : {idle, entering, critical, exiting}; ASSIGN init(state) := idle; next(state) := case state = idle : case N-Req = 1 : entering; 1 : state; esac; state = entering & !EW-Lock : critical; state = critical & !N : exiting; state = exiting : idle; 1 : state; esac; next(NS-Lock) := case state = entering & !EW-Lock : 1 ; state = exiting & !S-Go : 0; 1 : NS-Lock; esac; next(N-Req) := case !N-Req & N : 1; state = exiting : 0; 1 : N-Req; esac; next(N-Go) := case state = critical : 1; state = exiting : 0; 1 : N-Go; esac; -- non-deterministically chose N next(N) := {0,1}; FAIRNESS running & !(N-Go & N)

26 This problem is fixed in traffic2.smv next(N-Go) := case state = entering & !EW-Lock : 1; --change here state = exiting : 0; 1 : N-Go; esac; next(state) := case state = idle : case N-Req = 1 : entering; 1 : state; esac; state = entering & !EW-Lock : critical; state = critical & !N : exiting; state = exiting : idle; 1 : state; esac;

27 Model checking traffic2.smv  Mutual exclusion property is satisfied  Liveness property for North direction fails  AG ((N & !N-Go) -> AF N-Go) is false

28 Counterexample for liveness property contains a loop North.state=entering S-sense=1, W-sense=1 EW-lock=1 west.state = critical W-Go=1 NS-lock=1 south.state = critical S-Go=1

29 Counterexample for liveness property contains a loop North.state=entering S-sense=1, W-sense=1 EW-lock=1 west.state = critical W-Go=1 NS-lock=1 south.state = critical S-Go=1 North module given a chance to execute here. But it is of no use 

30 Ensuring liveness requires more work  This is in traffic3.smv  Introduce a Boolean variable called turn  Give turn to others (if I have just exited the critical section)  turn = {nst, ewt}

31 MODULE north1(NS-Lock, EW-Lock, N-Req, N-Go,N,S-Go,S-Req,E-Req,turn) VAR state : {idle, entering, critical, exiting}; ASSIGN init(state) := idle; next(state) := case state = idle & N-Req = 1 : entering; state = entering & !EW-Lock & (!E-Req | turn=nst): critical; state = critical & !N : exiting; state = exiting : idle; 1 : state; esac; next(turn) := case state=exiting & turn=nst & !S-Req : ewt; 1 : turn; esac; Similar code in south and west modules

32 Model check again  Mutual exclusion holds  What about liveness properties  In north direction?  In south direction?  In west direction?

33 Model check again  Mutual exclusion holds  What about liveness properties  In north direction? HOLDS  In south direction? HOLDS  In west direction? FAILS 

34 Traffic4.smv  Two more variables to distinguish between north and south completion  ndone and sdone  When north module exits critical section ndone is set to 1  Similarly for south module and sdone  When west module exits both sdone and ndone are set to 0

35 MODULE north1(NS-Lock, EW-Lock, N-Req, N-Go,N,S-Go,S-Req,E- Req,turn,ndone,sdone) VAR state : {idle, entering, critical, exiting}; ASSIGN next(state) := case state = idle & N-Req = 1 : entering; state = entering & !EW-Lock & (!E-Req | turn=nst): critical; state = critical & !N : exiting; state = exiting : idle; 1 : state; esac; next(turn) := case state=exiting & turn=nst & (!S-Req | (sdone & E-Req)): ewt; 1 : turn; esac; next(ndone) := case state=exiting : 1; 1 : ndone; esac;

36 Hurray!  Mutual exclusion holds  Liveness for all three directions holds  Strict sequencing does not hold  That is what we want

37 Think about  How to allow north, south, east, west traffic  How to model turns  Instead of writing code for four modules have a generic module  Instantitate it with four times. Once for each direction  Ensure properties without changing fairness constraints We will make the SMV code and slides available

38 QUESTIONS