Case Study : System-Level Design of a 4-Way Traffic Intersection

TABLE OF CONTENTS

  1. Problem Statement
    Purpose : Setup problem.
    Topics : Terminology; sample intersection; system framework and boundary.

  2. Part 1. Goals, Scenarios, and User Requirements
    Purpose : Create system requirements.
    Topics : Goals and scenarios; initial use cases and activity diagrams; system-level requirements; use-case/task interaction matrices; traceability.

  3. Part 1. Simplified Models of System Behavior
    Purpose : Explain behavior for overall system and sub-system elements.
    Topics : Typical behavior for driving activities; sequencing of the traffic lights.

  4. Part 1. Simplified Models of System Structure
    Purpose : Explain overall system structure.
    Topics : Develop class hierarchy diagram for serialized intersection system.

  5. Part 1. Creating the Logical Design
    Purpose : Develop those elements of the problem that are logical in nature.
    Topics : Signal timing and signal phasing;

  6. Part 1. Evaluation and Ranking of System-Level Design Alternatives
    Purpose : Explain .....
    Topics : .....

  7. Part 1. Creating the Physical Design
    Purpose : Create framework for evaluation of physical design alternatives.
    Topics : Models for traffic demand; measures of effectivenss for traffic throughput; synthesis of design alternatives (control system and roadway); performance assessment.

  8. Part 1. System Optimization and Tradeoff Analysis
    Purpose : Explain .....
    Topics : .....

  9. Part 1. Testing, Verification and Validation
    Purpose : Explain .....
    Topics : .....

  10. Parts 2 and 3. Generalizing the Problem Domain
    Purpose : Develop major extensions to the intersection model.
    Topics : Hierarchy of intersection control strategies; multi-level analysis of transportation networks.

  11. Conclusions and Future Work

  12. References and Web Resources


Problem Statement
[Traffic Intersection]

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:

  1. We will develop a use-case model for traffic behavior at the interesection. The key steps involve identification of: (1) the actors and system boundaries, (2) the use cases, (3) information flows between the actors and the use cases, and (3) potential dependencies among the use cases.

  2. Develop one or more class hierarchies for this problem, and indicate how they will communicate. My suggestion is that you create one class hierarchy for the intersection and traffic lights, and a second hierarchy for the vehicle(s) and driver(s).

  3. Develop one or more functional flow block diagrams (FFBDs) for the behavior of cars arriving at the intersection.

  4. What is the connection between your class hierarchy(s) and FFBDs?

  5. Demonstrate by example how your class hierarchy can be modified and reused for a slightly different scenario.

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.


Part 1. Goals, Scenarios, and User Requirements

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:

  1. Safety: when the pedestrian is crossing the street, no car
  2. Perceivable: the information of when to walk and when to stop is perceivable to the pedestrian.
  3. Comfortable: the allowable time for walk is long enough to cross

User 2: Driver

Requirements:

  1. Safety: the number of conflicting points is as small as possible.
  2. Perceivable: the signals are perceivable and clear to the driver.
  3. Comfortable: the allowable time for walk is long enough to cross the street.

User 3: Signal System

Requirements:

  1. Safety: the system has the least possibility of traffic accidents.

  2. Efficiency: The capacity of the intersection is maximized.

  3. Economy: The total investment of this system is minimized.

  4. Advanced requirement*:

    1. Environmental consideration: air pollution, vibrations pollution, light pollution.
    2. Regional consideration: the influence to the up flow traffic and down low traffic.

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:

  1. Driver's Action: Go straight ahead, turn left or turn right.

  2. Driver Activities: Watch the traffic lights, the traffic in other lanes and the pedestrians, etc.

  3. System Functionality: Cycle length and phase setting.

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.
Use Case
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

  1. The traffic control system should minimize the likelihood of collisions within the intersection.
  2. Time phasing of the traffic lights should be reasonable for all directions and pedestrians.
  3. Drivers and pedestrians should perceive traffic before action

5.2. Performance Requirements

  1. The timing for each phase should be long enough for cleaning the queue of traffic.
  2. The computed capability should be optimal.

5.3. Compatibility Requirements

  1. The setting of phase should be compatible with the traffic volume.
  2. The setting of traffic light should be compatible with traffic volume.
  3. The sign system should be compatible with the traffic volume and law.
  4. The control design should according to the current traffic law.
  5. The users should be aware of the traffic law.
  6. The control design should be compatible with the sign system.
  7. The control design should be compatible with the road geometries.
  8. The LOS of the designed intersection can't below grade f.

Traceability

The following summarizes the pathway from use cases to scenarios, to individual requirements.

Use Case

Scenario

Req. No.

Description

Cycle length setting

 

Scenario 1.1

Req. 5.1.1

Control system should avoid collision in the intersection

Req. 5.2.2

The computed capability should be optimal

Scenario 2.2

Req. 5.3.2

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:

  1. Generally, individual use cases are described by multiple scenarios, which in turn are represented by even more requirements.
  2. A single requirement can participate in the implementation of more than one use case (see, for example, requirement 5.1.1).

During the logical and physical stages of design, individual requirements will be traced onto elements of the system behavior and system structure.


Part 1. Simplified Models of System Behavior

System has the following main subsystems:

  1. Controller System
  2. Controller Interface (Traffic Light)
  3. Intersection
  4. User System (Cars and pedestrians)

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

  1. Left turning vehicles conflict with opposing through traffic as well as with pedestrian,
  2. Right turning vehicles conflict with pedestrians

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

  1. Traffic Light Control Systems

  2. Driver Activities

Traceability of Requirements to Attributes of System Behavior

Insert material soon .....


Part 1. Simplified Models of System Structure

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

  1. Traffic Light Attributes
    No of traffic light signal boxes
    No of lights (red, green, amber, turning) on each signal box
    Orientation of traffic lights
    Traffic light geometry
    Energy consumption
    Mean time-to-failure for the lights
    Maintenance costs

  2. Environmental Attributes

  3. Driver Attributes
    Age, License
    Reaction time

Points to note are as follows:

Traceability of Requirements to Attributes of System Structure

Insert material soon .....


Part 1. Creating the Logical Design

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

  1. Start-up lost times,
  2. Phase change intervals increase
  3. Minimum phase duration requirements have to be met

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:

  1. Two-Phase Signal Operation

    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).

  2. Three-Phase Signal Operation

    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.

  3. Four-Phase Signal Operation

    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 .....


Part 1. Evaluation and Ranking of System Design Alternatives

Measures of Effectiveness

According to the analysis of system goals we can define our measure of system effectives in the following aspects:

  1. Safety: the total accident per year, the accident related cost per year, the number of deaths caused by the accident per year?
  2. Capacity: level of service of the intersection, the average delay per vehicle, the peak-hour capacity,?
  3. Economy: the construction cost, maintenance cost, etc.
  4. Other considerations: noise pollution, sound pollution, vibration pollution, land use impact,?

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.


Part 1. Creating the Physical Design

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


Part 1. System Optimization and Tradeoff Analysis


Parts 2 and 3. Generalizing the Problem Domain for System Reuse

Hierarchy of Intersection Control Strategies

Multi-Level Analysis of Transportation Networks


Conclusions and Future Work

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.


References and Web Resources

Systems Engineering and Traffic Engineering

  1. Austin M.A. and Frankpitt B.A., “System Engineering Principles: Lecture notes for ENSE 621 and ENPM 641”, 1998.
  2. Austin M.A., “System Engineering Requirements, Design and Trade-off Analysis: Lecture notes for ENSE 622 and ENPM 642”, 2002.
  3. Berry D.S., "Notes on Traffic Engineering," Unpublished. Northwestern University, Evanston, Ill, 1978.
  4. William R. McShane, Roger P. Roess, “Traffic Engineering”, Prentice Hall, 1990.
  5. Papacostas C.S., Prevedouros P.D., "Transportation Engineering & Planning", Prentice Hall, 2001.
  6. Traffic Control Systems Handbook", US Department of Transportation, Federal Highway Administration, 1996.

Traffic Light Design

  1. Piper S., "LED Traffic Signals get the Green Light," Forefront, College of Engineering, University of California, Berkeley, Fall Semester 2002, pp. 6.
  2. Lamb A., "Simplicity in the design of a Traffic Light Controller," See http:.....

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.