TABLE OF CONTENTS
The purpose of this case study is to develop a series of systems model for traffic passing through a 4-way intersection. We want to explore and understand the extent to which this problem can be cast in a systems engineering framework -- use cases, requirements, models of system behavior, system structure, traceability, and evaluation, ranking and trade-off of system-level design concerns.
This document is a work in progress!
Part One
In part one , we design an object-oriented model of cars passing through a 4-way intersection controled by traffic lights. The adjacent figure shows the layout of road lanes, queues of cars and traffic lights. The object model should capture the relationship among the various components in the problem (i.e., the system structure) and the behaviors that can be simulated (i.e., the system behavior).
To keep the complexity of development in check, we will assume that arrangement of traffic lights and road lanes is fixed, as shown in the adjacent figure, and that the lights switch from red to green to amber in a regular repetitive pattern. Moreover, we assume that driver behavior is constrained by the road rules (keep this part really simple) and the desire to avoid vehicle collisions.
The case study will evolve as follows:
Part Two
Then in part two of the case study, the problem will be generalized to "control of traffic for a 4-way traffic intersection." Viable solutions include "no control" (i.e., driver behavior is guided by rules of the road), use of "give way" and "stop signs", and of course traffic lights. Families of potential solutions will be organized into class hierarchies.
The key question to be addressed is as follows: How should the expanded problem domain be organized so that: (1) A designer can freely switch among strategies for intersection control; and (2) Cause-and-effect relationships can be easily understood. This framework could form the basis for a "product line" simulation tool for transporation networks.
Part Three
Here we look into the future -- how can the requirements/engineering models in Parts 1 and 2 be applied to a complete transportation network?
To keep the size and complexity of the analysis in check, it would seem that a multi-level analysis is needed. At the intersection level (i.e., parts 1 and 2) behavior of individual vehicles in lanes might seem appropriate. This may still hold true for small traffic networks (e.g., traffic along a highway).
But what about a complete metropolitan area, like Washington DC? How do you create simplified models of behavior and structure at the intersection level that can be combined into a larger transportation network, and yet, remain faithful to the lower-level system behavior? Is there a way to freely switch between multiple levels of modeling fidelity?
Terminology
Terminologies are the first thing we should define before start the project. Because of the complexity of the intersection control system, terms can bring us better understanding of the properties.
A Sample Intersection
When considering about an intersection, we should consider the following subsystems:
To design the systems model for traffic passing through a 4-way intersection, the core in this project is how to design the control system so that the drivers and pedestrians can perceive precise and reliable information, with maximized system capacity and safety.
Since this project is addressed on the logical design, it?s necessary to
clarify the response system between road user and control system and the
design concerns of control system. There are 7 kinds of basic control system
for an intersection.
i) No control ii) Guide signing only iii) Guide and warning signing iv) Yield control v) Stop Control vi) Signalization vii) Police officer
Considering the real world situation, we only discuss four cases in our system.
System Framework and Boundary
The traffic intersection system can be conveniently thought of as the composition of three loosely coupled systems.
Figure 1. Interaction diagram for the component sub-systems
The sub-systems are:
On the surface of it, this problem looks really simple. But it isn't -- writing a behavior diagrams to cover every possible scenario would be too much work!
This framework also suggests that at the intersection level, the problem components -- driver activities; interaction with the other traffic and the control system -- might be modeled as a network of loosely coupled finite state machines. System-level modeling parameters would include: (1) traffic demand; and (2) suitable metrics for traffic throughput.
Goals and Scenarios
Goals 1. The traffic intersection functionality must allow drivers to pass through the intersection safely.
Goals 2. The system must be efficient.
Goals 3. The system must be economic.
Goals 4. The system must be compatible with traffic law.
Goals 5. The system must be feasible.
Use Cases
The Actors and System Boundaries
Recall that an actor is anything that interfaces with the system externally. Assuming that the system structure is composed of the traffic interesection together with the traffic lights, then the actors for our system are:
Actor (1) : Car/Driver
Here we are simplifying the problem by ignoring the presence of pedestrians.
Another valid viewpoint is that traffic flow through the intersection simply needs to be controlled, in which case, the traffic lights can become a second actor that we will simply call:
Actor (2) : Signal System
Under normal working operations, the traffic lights will fullfil the
role of signal system. However, should the signal system fail (e.g., due
to a lightening storm), then control of traffic flow might be
handled by ``rules of the road'' for an uncontrolled intersection,
or perhaps a policeman.
Identify Actors
Define Users
User 1: Pedestrians
Requirements:
User 2: Driver
Requirements:
User 3: Signal System
Requirements:
Initial Use Case Modeling
The use cases represent system goals or system functions.
Since we consider the safety, efficiency and economy of the system, the behavior of driver drives through an intersection can be divided into 3 parts:
Our initial use case diagram has five actors and nine use cases.
Figure 2. Initial Use Case Diagram
The driver, other traffic, pedestrian and other obstacles, and traffic lights are all external systems.
Figure 3. Simplified Driver Use Case/Activity Diagtram
Baseline (Textual) Use Cases
The use cases represent system goals (or system functions). Generally speaking, drivers want to pass through the intersection -- going straight ahead, or turning left or right -- without colliding into another car (or pedestrian). To avoid collisions and obey the road rules, drivers also need to: (1) Watch the traffic lights; (2) Watch traffic travelling in the same direction; and (3) Watch for oncoming traffic. To avoid collisions and obey the road rules, drivers should also watch out for pedestrians and other unexpected obstacles. Finally, the purpose of the signaling system is to alternate direction of allowable traffic flow at reasonable intervals of time.
Functionality of the Traffic Lights
Use Case (1): Cycle length setting.
Use Case (2): Phase setting.
Functionality of a Driver
Use case (3): Watch the traffic lights.
Use Case (4): Watch traffic traveling in the same direction.
Use Case (5): Watch for oncoming traffic.
Use Case (6): Watch out for pedestrians and other unexpected obstacles.
Use cases 3 through 6 can be represented in a single activity diagram!
Figure 4. Driver Judgement Activity Diagtram
Use Case (7): Drive straight ahead.
Figure 5. Activity Diagram for Driving Straight through the Intersection
Use Case (8): Turn right.
Figure 6. Activity Diagram for Turning Right at the Intersection
Use Case (9): Turn left.
Figure 7. Activity Diagram for Turning Left at the Intersection
Relationships Among Use Cases
Figure 8. Dependencies Among the Use Cases
Dependencies Among Use Cases. Use cases 1, 2, and 3 employ indirectly use cases 4, 5 and 6.
For the vast majority of traffic intersections, operation of the signal system will be unaffected by the presesence/lack of traffic at the intersection. For those cases where traffic flow is light, permissible behavior is governed by ``rules of the road.''
Use Case/Task Interaction Matrix
The following table summarizes the dependecies among use cases.
*Column Sends. Row receives. |
| ||||||||
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | |
Use Case 1. Cycle Length Setting. | 1 | ||||||||
Use Case 2. Phase Setting. | X | 2 | |||||||
Use Case 3. Watch the traffic light. | X | 3 | |||||||
Use Case 4. Watch the traffic light in the same direction. | X | 4 | |||||||
Use Case 5. Watch for oncoming traffic. | X | X | 5 | ||||||
Use Case 6. Watch for pedestrians and other unexpected vehicles. | X | 6 | |||||||
Use Case 7. Drive straight ahead. | X | 7 | |||||||
Use Case 8. Turn right. | X | X | 8 | ||||||
Use Case 9. Turn left. | X | X | 9 |
Table 1. Use Case/Task Interaction Matrix.
Note. We need to check that the use case/task interaction matrix is consistent with the "use case relationship diagram".
System Requirements
5.1. Safety Requirements
5.2. Performance Requirements
5.3. Compatibility Requirements
Traceability
The following summarizes the pathway from use cases to scenarios, to individual requirements.
Description
|
|||
Cycle length setting |
Scenario
1.1 |
Req.
5.1 |
Control system should avoid collision in the intersection |
Req.
5.2 |
The computed capability should be optimal | ||
Scenario
2.2 |
Req.
5.3 |
The setting of traffic light should be compatible with traffic volume | |
Phase Setting | Scenario 1.2 | Req. 5.1.2 | Time phasing should be reasonable for all directions and pedestrians |
Scenario 2.1 | Req. 5.2.1 | The timing for each phase should be long enough for cleaning the queue | |
Watch the traffic light | Scenario 4.2 | Req. 5.1.3 | Drivers and pedestrians should perceive traffic before action |
Req. 5.3.5 | The users should be aware of the traffic law | ||
Watch traffic traveling in the same direction | Scenario 4.3 | Req. 5.3.5 | The users should be aware of the traffic law |
Watch for oncoming traffic | Scenario 1.3 | Req. 2.3.5 | The users should be aware of the traffic law |
Drive straight ahead/Turn right/Turn left | Scenario 2.1 | Req. 5.3.2 | The setting of traffic light should be compatible with traffic volume |
Scenario 1.1 | Req. 5.1.1 | Control system should avoid collision in the intersection | |
Req. 5.1.2 | Time phasing should be reasonable for all directions and pedestrians |
Table 2. Traceability from Use Cases to Requirements.
This table shows two effects:
During the logical and physical stages of design, individual requirements will be traced onto elements of the system behavior and system structure.
System has the following main subsystems:
The overall system behavior is defined by the time-dependent behavior of the system's loosely coupled components (i.e., traffic lights; drivers).
Driver Behavior
At a high level of abstraction, the driver behavior can be encapsulated by a combination of activities.
Figure 9. Simplified Model of System Behavior
By "driver action" we simply mean one of:
Flows of Information
Information flows from the Car/Driver to the individual use cases for traffic direction (right, left, straight ahead). Information also flows from use cases 4, 5, and 6 to the Car/Driver.
Information also flows from the signaling system to the use cases for allowable traffic behavior (turn left or right; straight ahead), which in turn, is forwarded to the appropriate car/driver.
Traffic Light Control System Behavior.
Behavior of the traffic light control system is defined by the phasing and cycle of the traffic lights, as well as provision for abnormal behaviors. Together, the "phasing and cycle" of the control system constitute the "signal timing" for the taffic lights.
Signal Phasing
Signal phasing is concerned with the design of the sequence of traffic light control service, which in turn, affects movements of both vehicles and pedestrians being served at a signalized intersection. Phasing precedes all other signal timing steps.
The objective of phasing is the minimization of the potential hazards arising from the conflicts of vehicular and pedestrian movements, while maintaining the efficiency of flow through the intersection. Typical conflicts are
Cycle Length
Then the cycle length is estimated and green times are allocated to each phase according to the relative magnitude of traffic flows served in each phase. Cycle lengths should be designed to avoid substantial delays, traffic congestion within the intersection, and the endangerment of pedestrians.
Two possibilities for cycling are:
In countries where gasoline is expensive (i.e., most of Europe), some drivers turn their cars off at a red light. The amber light is a warning to turn their vehicles back on.
Certain constraints must be checked to ensure the safe and efficient processing of vehicles and pedestrians at an intersection.
Environment Behavior.
Even over extended periods of time the "rules and regulations" for driving are likely to remain constant. As the traffic demand increases (due, perhaps, to an increase in population), roadways will be enhanced to better control traffic flow. This study ignores these long-term effect.
Attributes of System Behavior/Performance
Traceability of Requirements to Attributes of System Behavior
Insert material soon .....
The signalized intersection system includes four main subsystems: traffic lights, environment, driver. However, the whole system can only work under the coordination of user, environment and facilities.
Figure 10. Simplified Model of System Structure
The attributes for each part of the class hierarchy will be determined, in part, by mappings of system behavior onto system structure.
Attributes of System Structure
Points to note are as follows:
Traceability of Requirements to Attributes of System Structure
Insert material soon .....
Logical Design for the Roadway
Insert material soon .....
Synthesis (Generation) of Design Alternatives
Increasing the number of phases in the control system operation promotes safety but hinders efficiency because it results in increasing delays. Delay increases because
The following figure shows two, three and four phase signal operation
Figure 11. Examples of Two, Three, and Four-Phase Signal Operation (Papacostas, pg. 202)
The attributes of two, three and four-phase signal operation are as follows:
This mode of operation is appropriate for intersections with low pedestrian volumes, low-to-moderate turning volumes, and vehicle arrivals with an adequate number of sufficiently long gaps that permit left-turning vehicles to be served within the "green time" allocated to the phase (Papacostas, pg. 202).
The three-phase operation is appropriate when one of the conditions for two-phase operation is violated. i.e., high volume of pedestrians; high left-turning volume on one of the two intersecting streets.
A four-phase operation is preferred when there are heavy volumes of left-turning traffic on both intersecting streets,
Actuated controllers are able to modify the cycle length as well as the durations of of green to better serve the actual demand. The flexibility of these systems results in more efficient service of traffic and and in the minimization of delays. Actuated controllers perform best at isolated locations and during off-peak times.
Example of Four-Phase Signal Behavior
The following figure illustrates the operation of a four-phase scheme under actuated control.
Figure 12. Typical Four-Phase Operation of an Interesection with Actuated Signal Control (Papacostas, pg. 205)
Traceability -- Pathways of Behavior in the Logical Design
Insert material soon .....
Measures of Effectiveness
According to the analysis of system goals we can define our measure of system effectives in the following aspects:
The effectiveness measures are listed in the following table.
|
Goals |
Weight |
Measures |
Weight |
Sub-measures |
Weight |
System |
Safety |
0.3 |
Death
Rate |
0.3 |
|
|
Accident
rate |
0.4 |
|
|
|||
Accident
related cost |
0.3 |
|
|
|||
Capability |
0.3 |
Level
of Service |
0.4 |
|
|
|
Average
Delay |
0.4 |
|
|
|||
Peak-hour
capacity |
0.2 |
|
|
|||
Economy |
0.2 |
Construction
Cost |
0.4 |
|
|
|
Maintenance
Cost |
0.6 |
|
|
|||
Other |
0.2 |
Environment
Impact |
0.5 |
Sound
Pollution |
0.4 |
|
Light
Pollution |
0.3 |
|||||
Air
pollution |
0.3 |
|||||
Land
use Impact |
0.5 |
|
|
Table 3. Measures of Effectiveness and Weightings for System Goals
The difficulty in the trade-off process is that the measures are in different scales, and it’s difficult to unify them to one unit so that we can find the optimal alternative easily. However, we can use the concept of “weight” to compare the importance of these measures. Here, we list the proposed weight for each measure, but a more reasonable and precise decision of weights need further discussion
Ranking Design Alternatives
With the consideration of available budgets and technician, even the possible land use constraints. The best alternatives should be some design plan with the maximum evaluation value.
We introduce a ranking system in this evaluation process, which is described as below:
Then the formulation can be:
However, with concern about safety, we should apply some ‘minmax’ criterion into the trade-off procedure, e.g. suppose for each traffic condition the total ranking result is shown as the following table.
|
Heavy
Traffic |
Medium
Traffic |
Light
Traffic |
Alternative
1 |
1 |
2 |
3 |
Alternative
2 |
3 |
1 |
2 |
Alternative
3 |
4 |
3 |
1 |
Alternative
4 |
2 |
4 |
4 |
Then if we apply the "minmax" criterion here, we will choose alternative 1 or alternative under the assumption that all these 3 events happen with same probability.
If we assign the possibility as below:
Event |
Heavy Traffic
|
Medium Traffic
|
Light Traffic |
Probability |
0.3 |
0.5 |
0.2 |
Then we should choose alternative 1, because it has less possibility to be the worse case. If we apply maxmax, then we should choose alternative 2.
Model for Traffic Demand
The key steps are:
Measures of Effectiveness for Traffic Throughput
Synthesis of Design Alternatives (Traffic Control Systems and Roadway)
Capacity and Performance Assessment for Design Alternatives
Hierarchy of Intersection Control Strategies
Multi-Level Analysis of Transportation Networks
A traffic system is a typical "system of system?" [Image]. In this project, we can learn how to planning and analyze a complex system with the systematic, integrated process, find the inner relation between each components and design the system.
In a signal control intersection, the actors are far more than the driver himself, depends on the degree of complexity, much more actors interact with the system externally, such as signal system, pedestrians, other traffic, even roadway law and vehicle itself.
The decision of actors depends on the scale and depth of the system design. However, after fix the scale and depth of the problem, it?s become much easier to write down the goals and scenarios, user cases and system behavior, however, with the consideration of accordance all the time. Comparatively, the logical design is the most difficult part of this project. It shows the core of our understanding of the system design, and a clear and brief explanation is difficult to achieve. Also, trade-off system is another key point that is difficult to fulfill because of the lack of quantitative measures.
The system we designed actually is simplified to some extend. More extension can be done with the consideration of control method choice, signal setting details with system behavior, more specifications on user cases, etc.
We are glad to see our improvement in the system design of signalized intersection, but, without doubt, there?s a lot of space for us to explore for a more precise and more concrete system design.
Systems Engineering and Traffic Engineering
Traffic Light Design
Initially developed by Saini Yang and Masoud Hamedi, May 2002.
Modified by Mark Austin, July-November 2002
Copyright © 2002, Saini Yang, Masoud Hamedi, and Mark Austin. University of Maryland.