Design & Implementation of Traffic Light Control System using Real Time Structured Analysis and Design

Analysis and Design of Traffic Lights Control System by Design and Analysis of Real-Time Systems (DARTS) MethodologyEndang DjuanaElectronics Computer Lab

Electrical Engineering Department

Trisakti UniversityAbstractThe real-time nature of an application can lead to an unreliable and unpredictable behavior. A well defined methodology is needed to ensure that reliability and predictability of real time systems aimed at safety and fault tolerance requirements are met. The Real Time Structured Analysis and Design method is one of the standards to use to approach solving a design problem in a real time domain. This report aims at providing the readers with a walk through experience in one of well known example: the Traffic Lights Control System. System decomposition using Data Flow Diagrams is applied to produce the system structure, State Transition Diagrams is produced to get the dynamic view of the system, and Task Architecture Diagrams is used to show the mapping between systems component and concurrent processes. A simple Scheduling Analysis and some discussion on safety and fault tolerance are produced. Due to space the notes on implementation is beyond the scope of this report. Keywords

Real time Structured Analysis and Design, Real Time Scheduling Theory

Introduction

This paper is a summary of the project report of designing a traffic lights control system as part of Real Time System Design course during authors study period at Computer Systems Engineering Department RMIT University. The project was aiming at the walk through process of designing a real time system application and to demonstrate an implementation.

The system is to control the traffic light at a number of intersections, such as in the Central Business District of Melbourne. The lights at each intersection will have a local controller, which is capable of operating autonomously in the event of loss communication with the central controller.

The central control room will monitor the traffic lights and can display the status of individual intersections, and the traffic flows at them. The central controller also normally acts to synchronize the lights at successive intersections in a straight line, assuming that the roads form a simple grid, to smooth the flow of traffic.

The central control room may also send override commands to the individual intersections, e.g. to provide a clear path for emergency vehicles.

The possible light sequence patterns based on given problem description include:

Fixed timing (timing set by central controller)

Night/emergency sequence (flashing yellow)

Autonomous (react to local car sensor (flow) and pedestrian sensor (button)

Priority sequence (give priority to traffic in one direction)

The methodology applied here to produce the design is Real Time Structured Analysis and Design. In this methodology the steps involved are producing Problem Statements, System Decomposition using Context Diagram and Data Flow Diagram (DFD), System Flow Analysis using State Transition Diagram, System Task Analysis using Task Architecture Diagram, Implementation Framework and Testing. In this project we also applied Real Time Scheduling Analysis (generalized utilization bound and completion time theorem) and a Discussion on Safety and Fault Tolerance.The implementation framework chosen in this project was a Sequential Programming Language with a Real Time Operating System support. QNX Real-Time UNIX Operating System and Watcom C/C++ programming environment was used to implement the software modules of this Traffic Lights Control Systems. The hardware implementation was outside of the scope of this project. Problem StatementsThe set of intersections presented here is the four intersections along Latrobe Street in Melbourne from Queen St. to Russel St. Traffic lights installed at each intersection are as follow:

We need to pay more attention to the Latrobe and Swanston St intersection since theres tram line involved which increase the number of traffic lights while all the other intersections have the same set of traffic lights. The condition in two types of intersection will be shown below.

Light Sequence

There are 4 different lights: normal traffic light (TL), pedestrian crossing light (PL), turn arrow light (AL) and tram light (TrL). Traffic light will have light sequence of red, green, yellow and back to red. Pedestrian light will have red, green, red blinking and back to red. Arrow light and tram light, in LaTrobe St. and Swanston St, will have red, green, yellow, and back to red.

The red light means stop, green light means go, yellow means transition (ready to stop). Red blinking means warning for the pedestrian not to start crossing or finish up crossing soon.

In each intersection there are 4 traffic lights which are working in pair (TL N-S and E-W in fig. 2). These two pairs will be synchronized as a final safety requirement, so that TL N-S and E-W pair cannot show same color light at the same time.

There are 8 pedestrian lights with a group of 4 will cater for one direction so that there are 2 groups: PL 12/34 and 14/23 and the same thing applied for the pedestrian buttons (PB), PB 12/34 and 14/23.

Pedestrian light will stay at red state (idle) until some pedestrian press the button which will send a crossing request to the local control system. The crossing request will be processed depends on sequence of the traffic light. The pedestrian light on the same direction will turn green at the same time the traffic light changes from red to green.

Coordination

Each intersection will have one local control system. The local control system is the one that actually controls the operation of traffic lights, pedestrian lights, pedestrian buttons, and traffic sensors in each intersection.

The central control system is monitoring the situation in each intersection and the mode of execution of the local control system. The central control system can change the mode of local control system by overriding the mode. The central control room operator will rely on the video camera to monitor the situation in each intersection. In case of traffic congestion or accident, the central control system can override the mode to accommodate the situation.

In the event of lost communication the local controller will work autonomously, and stay in the current execution mode until the communication restored or the authority manually changes the operation mode.

While working autonomously, there is still flexibility in execution mode allowed by reacting to traffic sensor that will change the mode of execution based on high traffic condition detected in one direction. The possibilities for the mode are normal mode (fixed timing) and high-traffic mode (priority timing).

In case of detecting central control overriding mode while executing any mode in local control, the highest priority will be served for the overriding mode.

The Solution Process

Strategies1. Decide on which scenario to start with the exercise. The decision to go for the four intersections along Latrobe Street, from Queen St to Russell St, is based on the reason that it is more familiar location since we went pass the spot day by day.

2. Conduct survay on the spot. After deciding on this spot we went to look at it and took note mainly on different traffic lights exist in particular intersection, and mainly on the behavior of all the traffic lights sequences. We noticed that among four intersections, the intersection of Latrobe St and Swanston St had more complex arrangement than the others with turn arrow lights and tram lights beside standard traffic lights and pedestrian lights.

3. Start analysing the intersection with standard traffic light arrangement to come out with basic design. We drew rough sketches on situation at one intersection, restated the problem and make assumption for analyzing this particular intersection.

Formal Methods4. Use Real Time Structured Analysis and Design explained in class. We followed the steps from case study of designing elevator control system to come out with Data Flow Diagram, State Transition Diagram, Task Architecture Diagram and Software Architecture Diagram

Computer Assistances5. Implement the behavior of the system in one intersection, starting with traffic light in one direction N-S only, than synchronize the sequence with E-W traffic light, add pedestrian button and pedestrian light, and finally we construct the behavior with the traffic sensor. We implement in one single program using standard C to get familiar with the sequence, because it is easier to migrate to multi-process program in QNX

6. Try to implement the sequence in Borland C/C++ graphic mode so we got a better understanding about the right behavior. 7. Implement multi processes in QNX, for one intersection. Simulate the idea and testing the behavior in the program. Test the concurrent processes.System Decomposition

The aim of the system decomposition stage is to identify different sub systems or modules and their interaction in producing a working system in the present of input, output and environment. It is a well known methodology in designing a computer system, known as divide and conquer or step wise refinement. The process aimed to identify the flow of information among different subsystems in which we can identify the mechanism and establish conditions for processing information. In this project we employ Real Time Structured Analysis and Design, stems from Structured Analysis and Design. The system context diagram aims to produce a view of the system as a black-box and the interaction with the environments. It is used mainly to identify input and output modules and information they are exchanging with our system. The real time nature of the systems

In the context of real time application there are some considerations in regards to the real time nature of the problem, namely a real time system needs to have a predictable and reliable behavior. It has a timely requirement in the sense that its result or action need to happen in certain time deadline. Outside that time requirement, the result were not only late but incorrect.

Some timing requirements are leading to catastrophic consequences if their deadline passed. Things like boiler control can create disaster if it did not stop boiling after certain deadline. Such requirement leads to a hard real time system. If the consequences were not leading to catastrophic but only annoyance the system is part o soft real time system.

The other built in nature of a real time application is concurrent processes. A real time application consists of potentially different processes which executes concurrently and operating on potentially shared resources. It happens mainly because this type of system normally handles many physical inputs from outside world and triggers many outputs to different devices. This nature leads to the need to synchronize access to a shared resource, which leads to implementation framework to guard shared resources such as semaphore, message passing and queues or shared memory.

State Transition Diagram

State transition is critical to understand the behavior of the system. State transition diagram were used to capture the order of events and what action needed to handle the events. If the system decomposition leads to the structure of the application, state transition diagram leads to the dynamic view of the application. It also shows standard of correctness to test against when the implementation is completed.

Task Architecture Diagram

Based on the structure and the dynamic view of the system, we tried to organize all the system components in group of task or processes. One process is represented with the parallel shape containing the sequence to perform whenever the inputs arrived and the output to produce. In this diagram we also decide what type of message communication interface between processes. There are basically two types of inter process communication regardless of their implementation, a loosely coupled and tightly coupled communication.

A loosely coupled communication is needed when we dont need to wait on the reply of one request before each process continues their execution. This type of communication normally implemented as a message queue, where the producer of the message can send a request and the consumer of the message will service the request based on the order of the arrival. In our application the request from a pedestrian pressing a button is considered as loosely coupled request.

A tightly coupled communication, on the other hand, is needed whenever we need to wait on the reply of one request before each process can continue with their execution. The implementation of this type of communication is normally in the form of shared memory resources such as semaphore. In certain case we do not need to wait on a reply as soon as the other party has released its lock to a shared resource. In our application we want to make sure whenever there is a change of mode of operation, it is completed before the other process can resume execution.

Response Time Specification

The worst case scenario for one intersection:

a) Pedestrian button interrupts arrive with a maximum frequency of 1 times a second, which gives a minimum inter arrival time of 1 second. Assume that some person is impatient or playing around with the button. For one intersection there are 8 pedestrian buttons that could be pressed. This worst-case scenario assumes that all 8 buttons are being pressed within 8 seconds.

b) Sensor input interrupts arrive with a minimum inter arrival time of 10 second, according to the technical specification. Assume that the sensor is set for heavy traffic condition. For one intersection there are 4 sensors that could sense cars coming from 4 directions. This worst case has 4 sensors sensing heavy traffic within 40 seconds.

c) Manual control key interrupts arrive within a minimum inter arrival time of 5 minutes. Assume that in the case of emergency vehicle passes, the police can manually turn the key to alert state then walk to the center of the intersection. After directing the traffic, the police can walk back and turn the key back to normal again.

Event Sequences

a) Pedestrian crossing request sequence (period = Ta)

1) Monitor Pedestrian Button receives and processes interrupt

2) Monitor Pedestrian Button sends Crossing Request Message

3) Sequence Controller receives messages and checks the current state of the main traffic light sequences to determine whether the Pedestrian Light sequence should be executed or wait for the state transition. b) Manual control key turned sequence (Tc)

1) Monitor Manual Control Key receives and processes interrupt

2) Monitor Manual Control Key sends execution mode to the Set Light Sequence

3) Set Light Sequence apply the execution mode

c) Sensing heavy traffic in one direction event sequence (period = Tb)

1) Monitor Sensor Input and Set Mode receives and processes interrupt

2) Monitor Sensor Input and Set Mode sends Setting Mode Request Message

3) Sequence Controller receives messages and checks the current state of the main traffic light sequences. It will apply the new execution mode on the beginning of next sequence.

4) Sequence Controller sends execution mode to the Set Light Sequence

5) Set Light Sequence apply the execution mode

Priority Assignments

TaskCPU time CnPeriod TnUtilisation UnAssigned Priority

a) Pedestrian Crossing Request Sequence

Monitor Pedestrian Button0.0410.041

Sequence Controller0.2010.153

b) Manual Control Key Turned Sequence

Monitor Manual Control Key0.043000.000135

Set Light Sequence0.083000.000274

c) Sensing Heavy Traffic Event Sequence

Monitor Sensor Input & Set Mode 0.04100.0042

Sequence Controller0.20100.023

Set Light Sequence0.08100.0084

Assumption: that whenever manual key turned, there always a police standing in the center of the intersection to direct the traffic, so that it is safe to assign the highest priority to Manual Control Key tasks.

Scheduling Analysis

Total utilization for this scenario is 0.4 < 0.69. But since the rate monotonic priorities are violated it is necessary to carry out a more detailed analysis for each event sequence using the generalized utilization bound theorem and generalized completion time theorem.

Generalized Real Time Scheduling

Pedestrian Crossing Request Sequence

The tasks in the sequence are Monitor Pedestrian Button and Sequence Controller with the period of this sequence = Ta = 1 sec.

Analysing the four factors:

Execution time for tasks in event sequence: 0.04 sec for Monitor Pedestrian Button followed by 0.20 sec for Sequence Controller make up to total execution time Ca = 0.24 sec. Utilization = Ca/Ta = 0.24.

Preemption by higher priority tasks with shorter periods. There are no such tasks as this is the shortest period task.

Preemption by higher priority tasks with longer periods

There are three tasks in this category, the Manual Control Key, the Set Light Sequence (b) and the Sequence Controller (c). They can preempt Sequence Controller (a) and Monitor Pedestrian Button with total preemption time Pa = 0.04 + 0.08 + 0.20 = 0.32. Preemption Utilization = Pa/Ta = 0.32.

Blocking by lower priority tasks. There are no such tasks.

Total utilization: 0.56 < 0.69

Manual Control Key Turned Sequence

The tasks in the sequence are Monitor Control Key and Set Light Sequence with the period of this sequence = Tb = 300 sec.

Analysing the four factors:

Execution time for tasks in event sequence: 0.04 sec for Monitor Control Key followed by 0.08 sec for Set Light Sequence make up to total execution time Cb = 0.12 sec. Utilization = Cb/Tb = 0.0004.

Preemption by higher priority tasks with shorter periods. There are no such tasks as this is the highest priority task.

Preemption by higher priority tasks with longer periods. There are no such tasks as this is the highest priority task.

Blocking by lower priority tasks

The Sequence Controller (c) can potentially preempt the Set Light Sequence (b) with total worst blocking time Bb = 0.20 sec. Blocking utilization = Bb/Tb = 0.00067.

Total utilization: 0.00107 < 0.69

Sensing Heavy Traffic Event Sequence

The tasks in the sequence are Monitor Sensor Input & Set Mode, Sequence Controller and Set Light Sequence with the period of this sequence = Tc = 10 sec.

Analysing the four factors:

Execution time for tasks in event sequence: 0.04 sec for Monitor Sensor Input & Set Mode followed by 0.20 sec for Sequence Controller, followed by 0.08 sec for Set Light Sequence make up to total execution time Cb = 0.32 sec. Utilization = Cb/Tb = 0.032.

Preemption by higher priority tasks with shorter periods. There are no such tasks as this is the highest priority task.

Preemption by higher priority tasks with longer periods

The Monitor Control Key and Set Light Sequence may preempt the tasks in this sequence with the total preemption time of Pc = 0.04 + 0.08 = 0.12 sec. Preemption utilization = Pc/Tc = 0.012.

Blocking by lower priority tasks. There are no such tasks.

Total utilization = 0.032 + 0.012 = 0.044 < 0.69.Reflections

Things learned in the exercise:

How to decompose the problem in analyzing and designing real time applications

How to capture the flow of information in the applications by using data flow diagram

How to identify concurrent processes involved in the applications

How to achieve deterministic behavior by analyzing the state been gone through by the applications

How to achieve predictable response and performance by doing the scheduling analysis

Suggestions

Use of Methodology

The use of object oriented analysis and design to get a better view of the system, how all the entities in the system interact, and we can have a clear view of the role of each entity. Better encapsulation and modularity. The state diagram used in this RTSA is also employed in OO Techniques while the DFD is also employed to provide functional model for the system

Other benefit is OO model will help to communicate better the design idea to other people and help them to easily involve with the design. Based on our experience, we found it hard to get other people to understand our design using data flow diagram that is more implementation specific.

During the design process, when we sought suggestion from other students inside or outside these DS739 groups, we found that it is not easy to communicate the design using data flow diagram before they can finally understand the idea.

However, we followed the steps given in the case study. All suggestions to design came from discussion during the tutorial time. One example is when we are discussing how the main traffic light sequence deals with incoming sensor requests can be applied in the state diagram.

Safety and Fault Tolerance Discussion

Fail-Safe State

The correct sequence of the lights is the most important thing that ensures the safety of driver and the pedestrian on the road. If the sequences go out of control or if faults happen to the local controller all the sequence in that intersection should stay in alert that is the blinking yellow. In case of local controller fault while the communication is still up then the central controller can order this alert sequence. In case of the communication is also down the system will rely on circuit switch to run this alert sequence.

Hardware Redundancy

To ensure fault tolerance we suggest that the system employ hardware redundancy for the local controller, the primary and secondary controller. Whenever the primary controller fault is detected, the hardware system will quickly switch to the secondary controller but it will stay on the same state without sudden changes to the sequence. The reason we suggest hardware redundancy is that it will produce quick response and it will easily maintain the same sequence.

Safety Software Design

To ensure predictable software behavior we suggest that the designer should follow the specification and methodology very carefully.

References1. Buttazo, Giorgio., 1997, Hard Real-Time Computing Systems, Kulwer Academic Publisher2. Gomma, Hassan., 1992, Software Design Methods for Concurrent and Real-Time Systems, Addison-Wesley

EMBED Visio.Drawing.5

EMBED Visio.Drawing.5

EMBED Visio.Drawing.5

EMBED Visio.Drawing.5

EMBED Visio.Drawing.5

EMBED Visio.Drawing.5

EMBED Visio.Drawing.5

EMBED Visio.Drawing.5

EMBED Visio.Drawing.5

EMBED Visio.Drawing.5

EMBED Visio.Drawing.5

_1004775562.vsd

_1004776062.vsd

_1004790211.vsd

_1004799034.vsd

_1004776195.vsd

_1004775606.vsd

_1004775244.vsd

_1004775498.vsd

_1004775277.vsd

_1004775138.vsd

_1004775196.vsd