3. Host Hardware Environment

Traffic signal timing parameters do not exist in a vacuum. To be useful, they must be installed in hardware operational on the street. The Signal Timing Process must produce results that can be installed on the street. This implies that a review of the development of the local controller and a review of how it operates in a system environment is useful in understanding how the signal timing process can be improved.

This section begins with a description of the development of the traffic controller. This is followed by a description of the basic timing parameters used by the controller. The next section describes how the controller operates in a system environment. The section concludes with a brief discussion of how NTCIP may impact the signal timing process in the future.

3.1 Traffic Signal Controller Development

Before examining the signal timing process itself, it is useful to define the hardware which will be the host for the results of the process. By the 1950's, traffic controllers had evolved into two distinct platforms, fixed-time and actuated. The fixed-time controller was an electro-mechanical device that switched the signal power circuits with a cam shaft. The actuated controller was an analog device that used several timing circuits to decide to advance to the next phase. The typical controller had four basic timing circuits per phase:

Initial,
Vehicle Extension,
Maximum, and
Yellow.

The controller supported either two or three phase operation. Between 1950 and 1970, many different variations of this basic design were produced. The most complex was the Automatic 1022, Volume Density controller. This device was a two-phase controller that used many additional circuits to determine the duration of each phase than the four timing circuits noted above. This device was important because it defined two functions that are common in today's controllers, gap reduction and variable initial.

Two developments during the 1970s significantly impacted the practices and equipment used today: the development of the Model 170 controller; and the publishing of the National Electrical Manufacturers Association (NEMA) TS1 Specification. The Model 170 was defined when California Department of Transportation (Caltrans) and the New York Department of Transportation (NYSDOT) developed a detailed hardware specification. In a parallel effort, a group of vendors under the auspices of NEMA drafted a standard specification commonly referred to as TS1. This specification defined the function and electrical characteristics for the pins on the three connectors designated as A, B, and C connectors. TS1 defined a controller capable of providing isolated actuated control. These developments are important today because together they defined the standard traffic control parameters that must be used in the signal timing process.

Hardware development continued into the 1980s, with a new NEMA standard, TS2, which defined a controller unit, a malfunction management unit, terminals and facilities, detectors, load switches, flashers, and cabinets. Although this standard defined a major hardware advance, there was no significant change in the controller timing operation.

In the 1990s, Carnegie-Mellon University performed a software and hardware development effort for Caltrans in cooperation with the Federal Highway Administration. The original hardware concept was to use a 6U VMEbus, which would have made a controller twice as tall as a 170. The software was object-oriented, following a process-control algorithm that allowed the user to connect inputs, outputs, and processes graphically. The software concept was never implemented, but the hardware ideas became the basis for the 2070. The development of the 2070 was lead by the Joint Committee on the ATC. The 2070 was based on an "open-architecture" concept. Open architecture means that the interfaces, both hardware and software, are publicly available and managed by responsible and responsive agencies. While the 2070 is another step forward in hardware design, there was still no change in the signal timing parameters

There are four hardware platforms in common use today: the NEMA TS1 controllers; NEMA TS2 controllers; the Model 170 controllers; and the 2070 controllers. These hardware platforms are distinct, but all four use the same set of signal timing parameters.

Controllers are frequently classified by hardware specification; NEMA TS1, NEMA TS2, Type 170, and 2070. They are also classified by their functional operation; fixed-time, semi-actuated, fully-actuated, and volume-density. For the purposes of analyzing the signal timing process, the hardware types are important only to the extent that they support the six functional categories:

1. Full-Actuated – Isolated
2. Full-Actuated – Coordinated
3. Semi-Actuated – Isolated
4. Semi-Actuated – Coordinated
5. Fixed-Time – Isolated
6. Fixed-Time – Coordinated

The distinction between isolated and coordinated is significant since the same timing parameter; Cycle Length for example, could have a different optimum value depending on whether the controller was operating as an isolated intersection or as part of a system. When the intersection is isolated, the Cycle Length generally is calculated based on minimizing intersection delay using Webster's Equation. When the intersection is operating as a part of a system, the Cycle Length is usually selected based on system factors. Because modern controllers can be used in any of the six modes noted above, the signal timing procedure must be able to accommodate all of these modes. The primary distinction is between isolated and coordinated. With coordinated operation, the controller uses all of the settings required for isolated operation plus a number of parameters that are related to coordinated operation. The signal timing process must consider all of the parameters used by a modern controller.

3.2 Basic Timing Parameters

As noted above, the basic timing parameters are essentially the same for four types of controllers. There are subtle differences between different software implementations, for example, the NEMA controllers define the Force-off function as a "per ring" function while other implementations define the Force-off function as a "per phase" function. This distinction has little importance to the Traffic Engineer who is responsible for developing new Traffic Signal Plans. These differences, however, are very important when the results of a signal timing optimization process are implemented in a particular controller.

The Basic Timing parameters are described below derived from paraphrasing the definitions from the NEMA Standards Publication No. TS-2.

Minimum Green – The first timed portion of the Green Interval which may be set in consideration of the storage of vehicles between the phase detector(s) and the stop line.

Passage Time (Vehicle Interval, Gap) – This parameter extends the Green Interval for each vehicle actuation up to the Maximum Green. It begins timing when the vehicle actuation is removed. This extension period is subject to termination by the Maximum Extension timer or a Force Off.

Maximum Green – This time setting defines the maximum length of time that a phase can be green in the presence of a conflicting call. If there is no conflicting call, it will be reset until an opposing call occurs.

Yellow Change – This interval follows the green interval of each phase. The Yellow Change controls the duration of the yellow period for that phase.

Red Clearance – This interval follows the yellow interval of each phase. The Red Clearance controls the duration of the red period for that phase.

Walk – This parameter controls the length of time that the walk signal is displayed.

Pedestrian Clearance – This parameter controls the duration that the Flashing Don't Walk is displayed.

Time-Before-Reduction – This period begins when the phase is Green and there is a serviceable call on a conflicting phase. When this period is completed, the linear reduction of the Passage Time begins.

Time-To-Reduce – This period begins when the Time-Before-Reduction ends and controls the linear rate of reduction until the Minimum Gap is achieved.

Minimum Gap – Like the Passage Time, this parameter extends the Green Interval by the Minimum Gap time for each vehicle actuation up to the Maximum Green. It begins timing when the vehicle actuation is removed. This extension period is subject to termination by the Maximum or a Force Off.

Added Initial – This interval times concurrently with the minimum green interval, and is increased by each vehicle actuation received during the initial period. The initial green time portion is the greater of the minimum green or added initial intervals. The Added Initial cannot exceed the Maximum Initial.

Maximum Initial – This is the maximum period of time for which the Added Initial can extend the initial green period. The Maximum Initial can not be less than the Minimum Green.

3.3 Coordination Timing Parameters

While virtually all actuated controllers support the basic parameters as described above, the parameters associated with coordinated operation are implemented with more variations. In general terms, there are three basic parameters that when taken together define a coordinated traffic signal plan. These parameters are Cycle Length, Offset, and Split. As with many things is the real world, the concepts may be simple, but invariably, the execution can be quite complex. For example, when the Force-off is defined as a "per-phase" function, then the phase Force-offs and Offset completely define a timing plan. Other idiosyncrasies are discussed below within the context of the three basic parameters: Cycle, Offset, and Split. We begin with the definitions.

Cycle Length – This is the total time to complete one sequence of signalization around an intersection. In an actuated controller unit, a complete cycle is dependent on the presence of calls on all phases. In a pre-timed controller unit, it is a complete sequence of signal indications.

Offset – This is the time relationship, expressed in seconds, between the starting point of the first coordinated phase Green and a system reference point. The first coordinated phase is that which occurs first within the concurrent group of phases containing the coordinated phase(s) when there are constant calls on all phases.

Split – This is the segment of the cycle length allocated to each phase usually expressed in seconds. In an actuated controller unit, split is the total time in the cycle allocated to a phase including Yellow and Red times.

The problems related to the coordination parameters stem from their development history. With the basic parameters, suppliers had to conform to either NEMA or Model 170 specifications that defined these parameters. For the coordinated operation, there was no standard. Each supplier had to develop their own approach. Cycle, Offset and Split are straightforward and most suppliers provided solutions that are similar to one another. For example, one system could express the Offset in seconds while another may express the Offset in percent of the Cycle. This is generally not a problem, however, since one expression can readily be converted to the other.

Although entering and downloading the data itself may be simple, understanding the function of each parameter may be somewhat more complex. In Figure 5, we illustrate some of the issues involved with the offset.

Figure 5. Offset Issues.

Most Traffic Engineers consider the beginning of "Main Street Green" as the offset reference point. This is noted in Figure 5 as the TE Offset. The controller, however, uses the end of "Main Street Green" (Phases 2 and 6) as the Offset reference point. In the illustration, this is calculated by adding the Phase 6 Green time to the TE Offset. If the intersection has an actuated pedestrian phase, yet another offset reference must be used to assure that there is sufficient time for the pedestrian clearance phases. This is noted as "Offset, Ped Considerations" in the illustration. Each controller manufacturer and software supplier deals with these parameters in a slightly different way which leads to the traffic system Tower of Babel.

3.4 NTCIP

Like Esperanto, a language that was designed to facilitate communication among people of different lands and cultures, the National Transportation Communications for ITS Protocol (NTCIP) promises to provide a commonality among systems. Recent developments with NTCIP have set the stage for the next step in the evolution of intersection traffic control. These developments will have a significant impact on the signal timing process.

Any advancement in the algorithms used within signal controller must be sensitive to emerging standards within the industry. The National Transportation Communications for ITS Protocol is being developed as a vast family of protocol components that have, or will have established, interface standards between traffic management systems and their associated field devices. Traffic signal systems were the initial inspiration for NTCIP, and also the most difficult to fully implement. Three major definitions are either approved or are nearing final development: Actuated Signal Control (ASC), Field Management Stations (FMS), and Signal Control and Priority (SCP). The ASC standard is currently published, and early deployments have revealed needed changes and supplemental components that are now being developed. The FMS standard is one of those components without which ASC cannot be implemented in signal systems with distributed architecture. SCP is also a supplemental standard providing interface standards for functions that most agencies need. A non-signal standard that is nevertheless critical to this effort is the Traffic Sensor Systems (TSS) standard, which is complete and has been adopted.

How does innovation fit into NTCIP? As with all standards, NTCIP seeks to define common interfaces to achieve interoperability with other kinds of devices and interchangeability with other brands of signal controllers. Interchangeability requires that the semantics of signal controller settings be fixed, so that they mean the same things across the industry. Of course, fixing those settings also fixes how they work, and on the face of it this leaves little room for new algorithms. For example, NTCIP data objects have been defined to communicate all the conventional gap-acceptance parameters, including extension times, volume-density settings, minimum and maximum green times, and so on. No objects exist, for example, to define queue length or delay, even within the TSS objects, though these parameters may prove central to new algorithms based on new detection capabilities.

But the framers of NTCIP were careful to avoid prohibiting future innovation, and have provided the ability of software providers to use data objects of their own definition to provide special features not available across the industry. The goal of NTCIP is to define interface standards, not operational standards, and its scope is therefore limited to currently and widely available functionality. While NTCIP holds great promise for the future, it is important to recognize that for most users, the signal timing process must be operable with legacy equipment – the hardware that is currently deployed and is likely to remain in service for many years to come.

3.5 Universal Traffic Data Format

While the development of NTCIP in large part has been a task spearheaded by the public sector, there have been other developments in the private section that provide a common denominator among the various simulation and optimization programs. One of the most important of these is the Universal Traffic Data Format currently used by the Trafficware Corporation. A significant recent development that not only has expedited data input to the models; but also has facilitated transferring the optimized results to the traffic control systems. The Universal Traffic Data Format (UTDF) is an open standard data format specification for traffic signal and traffic related data for intersections that has been promoted by Trafficware, the developers of Synchro. UTDF can be used to efficiently transfer data between traffic software packages. UTDF can also be used to share data between software and traffic signal controller hardware. UTDF contains the ability to store multiple volume counts and timing plans for multiple intersections. This allows for a structured method of storing large amounts of traffic data.

There are six file formats specified by the UTDF:

• VOLUME stores volume counts
• TIMING stores timing plan information that varies by time of day
• PHASING stores timing plan information that doesn't change
• TIMOFDAY stores a weekly schedule of when to use timing plans
• LAYOUT stores intersection locations and connections
• LANES stores lane and fixed information

With automatic data collection through detectors, the VOLUME table can be quite large. With 100 intersections generating 96 counts a day for 30 days, the VOLUME table can have 288,000 records. The other tables are relatively small. In most cases these tables will contain less then 10,000 records and 500K of data. Efficient storage of this data is not as critical as having a well-defined specification.

UTDF has been used in a number of hardware related developments:

• Existing detectors can be used to provide traffic counts and be stored in UTDF.
• A library of timing plans can be stored in UTDF and uploaded to the controller on demand.
• A generation 1.5 traffic control system can be developed that automatically performs the above steps in conjunction with the analysis software in real time.

UTDF allows data to be shared between otherwise incompatible software packages. It is anticipated that many software developers will support UTDF. In this scenario data is entered once and then used by all the software together. It is possible for planning departments to store traffic counts for various scenarios and use them for capacity analysis as well as other purposes. With UTDF compatible software it could be possible for planners to completely automate traffic impact studies for future development and roadway improvements.

Text files are easy for end users to edit with any text editor such as Windows Notepad. The column aligned format is provided for compatibility with Turning Movement Count (TMC) files and for easy editing with text editors. The comma-delimited text files (CSV) can also easily be viewed and edited by spreadsheets such or Microsoft Excel. The user or software developer is free to choose the most convenient format.

3.6 Hardware Environment Summary

As we noted at the beginning of this section, signal timing plans do not exist in a vacuum. To be effective, the abstract signal optimization results must be translated to the specific parameters that are used by today's controllers. Several observations related to the hardware environment are noted below.

1. The signal timing parameters used in existing hardware are different from the values generated by the various optimization programs. Because each existing system uses slightly different coordination parameters, it is not practical to provide an interface for every existing system. However, most manufacturers recognize this problem and have addressed it generally by providing an interface to a third party software package. Synchro is the one most frequently noted.
2. As legacy equipment is replaced by new systems based on NTCIP, many of the impediments to a universal interface will disappear and it is likely that the ability to install optimization results in new systems will be greatly enhanced.