Intelligent Traffic Signal Control: Adding Pedestrians to the System
Prepared for presentation at the 2007 Annual Meeting of the Transportation Research Board and for publication in the Transportation Research Record
Prepared by
Richard Wall, University of Idaho
Tom Urbanik, University of Tennessee
Darcy Bullock, PurdueUniversity
Steve Allen,University of Idaho
Michael Busby,University of Idaho
Dustin DeVoe,University of Idaho
Andrew Huska,University of Idaho
Tyson Rallens,University of Idaho
October 17, 2006
Abstract
Traffic signal systems are currently centralized in the sense that virtually all intelligence resides in the cabinet, except for some “smart” sensors. This architecture limits the ability of deploying a distributed system of intelligence where both sensors and display devices can communicate with each other. In order for systems of the future to expand there capabilities, a need exists for a distributed control architecture at signalized intersections. This paper reports on the demonstration of a distributed traffic signal control system to improve the operation of countdown pedestrian signals.
1. Introduction
Intelligent Transportation Systems (ITS) have evolved from Intelligent Vehicle Highway Systems which had it roots in the 1960’s [Wolkomir 86]. However, one could argue that the overall concept has yet to mature, especially in regards to non-vehicle based transportation [GAO 1994]. This paper has the goal of improving non-motorized traveler interaction with traffic control systems. We believe our vision for improved non-motorized traveler service through improved distributed control systems is consistent with the ITS architecture, evolving NTCIP standards, and recent research.
2. Background
Modern traffic control systems use a distributed architecture with central management software, on-street masters, and local intersection controllers. However, the local intersection control remains centralized in a single cabinet. This centralized architecture has evolved from the early ad-hoc microprocessor deployment of the 1970’s [Quinlan 89]. In the 1980’s a group of vendors organized and drafted a standard specification commonly referred to as TS1 [Nema 89]. That specification defined the operation and electrical pins on the A, B, and C connectors for a controller capable of providing isolated actuated control.
The NEMA TS1 standard was based upon the philosophy that controllers would provide a basic set of features and standard electrical connectors. Manufacturers would compete based upon the hardware and software they provided inside the controllers. The NEMA TS1 standard was very successful for isolated actuated intersection control, but lacked sufficient detail necessary for implementing more advanced features such as coordinated-actuated operation and preemption. Individual vendors supplemented the standard by providing the complement of features necessary for deploying coordinated-actuated traffic signal systems. The 1989 NEMA specification was updated (NEMA TS2) to provide coordinated-actuated operation, preemption, and an optional serial bus that would simplify cabinet wiring [NEMA 1992].
There have been several small updates to the 1992 specification over the last 14 years. However, no equipment vendor has implemented enhancements to the NEMA serial protocol to either provide enhanced data objects, or distribute some of the control to devices outside of the traffic signal cabinet [Bullock96, Bullock 99]. Furthermore, it is clear that traffic signal systems could benefit from including enhanced sensors that could provide more sophisticated information then contact closures [Bentzen 2000, Urbanik 2006].
For example, a recent NCHRP project developed a scheduling based construct for movement through an intersection [Urbanik 2006]. This construct builds on NTCIP 1211 that recognizes the concept of a smart traffic signal logical process called Priority Request Server. This logical process accounts for a scheduling construct to accommodate the multiple requests for service, their specific characteristics, and their priorities.
The smart control system requires a number of distributed processes to accommodate all the functionality necessary to exchange information between the traveler and the control system. However, in the short-term, it is necessary to make incremental improvements on the existing control system. One area in need of improvement is the communication link between the pedestrian indication and the control system. The current system is a simple set of outputs: on, flashing, and off [NEMA 89, NEMA 92].
In order to make a modest improvement in the pedestrian display, a countdown timer, it is necessary for the countdown timer to “learn” the duration of the pedestrian clearance interval [Markowitz 2006]. This inhibits its ability to adjust to changing conditions, like a longer clearance for mobility-impaired pedestrians. We therefore chose the countdown pedestrian signal to demonstrate the capability and advantages of increased complex communications, controls and signals because of inherent existing problems. Present technology used for countdown pedestrian signals makes these systems error prone whenever signal timing changes. Three major improvements were desired: correct functional performance, improved reliability, and increased accessibility for pedestrians. The results achieved for pedestrian signals are readily projected to traffic control in general.
3. System Design
The distributed intelligent traffic signal technology that we implemented is based upon concepts of the IEEE 1451 standard for plug and play (PnP) smarts sensor networks. Preliminary investigation in using IEEE 1451 for smart traffic signals used a scale model of an eight phase actuated intersections [Wall 2005]. IEEE 1451 compliant transducer electronic data sheets (TEDS) for smart traffic signals and detectors were developed and the system performance was assessed. [Wall 2006] The objective for a full-scale implementation is to make a drop-in replacement for existing pedestrian signals using distributed control technology that addresses the existing issues with countdown times.
As previously noted, correct countdown pedestrian signal operation requires that the countdown timer know the period of the pedestrian clearance interval. It is not sufficient for the countdown timer to know the pedestrian clearance interval only at the start of the phase to maintain accuracy for instances of preemption. Since the traffic controller determines this time, the only way for the countdown time to always operate correctly is for the traffic controller to communicate this time to the countdown timer in a real-time manner. We accomplished this by extracting the timer value from a TS2 traffic controller using the Ethernet port and translating the information for distribution to the smart sensors and detectors.
The system described below accomplishes the design objectives for cost effective correct functional performance, improved reliability, and increased accessibility for pedestrians. The system block diagram shown in Figure 1 was constructed and tested at the University of Idaho Department of Electrical and Computer Engineering in April 2006. This information centric system is functionally divided into two Ethernet networked distributed subsystems: a system to communicate with the traffic controller and a system to communicate with the distributed smart sensors and smart detectors. The two subsystems tie together using a set of translator/bridge processors that convert the data passed between the two network systems.
The smart devices consists a smart walk-wait display, a countdown display and a closed-loop pedestrian call button. The display devices featured individual LED management allowing dynamic signaling and display failure detection. The embedded intelligence enables autonomous fail-safe operations in the event of communications or detectable internal failure.
The system also consists of two laptops computers for PnP smart device and traffic controller management. The wiring of PnP smart signals and detectors is in effect accomplished in software using the user interface laptop. The home base laptop shown in Figure 1 is used for system testing during development to simulate incoming requests for signal-timing plan changes from a city's traffic department. This computer was also used to implement preemption and setup the timing plans in the traffic controller.
Figure 1. System block diagram for a IEEE 1451 compliant smart countdown pedestrian signal and pedestrian call button.
Systems Communications
Countdown timing and walk/wait indication state information is polled from the traffic controller by the translator controller and is passed to the PnP network controller that distributes this information to the PnP smart signals. The service request information from the smart pedestrian call button uses the same route but in reverse.In our implementation, the bridge node consists of two microprocessors, a translator and a PnP processor, operating in a master-slave configuration to connect the two Ethernet networks. Network communications with the traffic controller uses Simple Network Management Protocol (SNMP) while all other network communications uses TCP/IP where each network node is assigned a unique local IP address. In theory, the two networks could use a common network hub or switch. They are shown as two independent networks in Figure 1to emphasize the use of Ethernet over power line for communications with the signals and detectors. Every smart signal and detector as well as the translator and bridge processors operate as a network node. It is advisable that a router be used between the intersection network and the wide area network (WAN) and reasonable to connect it to the traffic controller – translator controller network. .
Translator Controller to Traffic Controller Communication
The primary function of the translator controller is to provide an interface between the traffic signal controller and the PnP traffic devices. We used Econolite’s ASC/3 2100 series NEMA Type 2 traffic controller that follows the NTCIP standard. Data is exchanged between the translator and the ASC/3 traffic controller using SNMP packets consisting of management information base (MIB) codes as defined in the NTCIP standard. The translator uses the 1201 and 1202 MIB standard objects to send and retrieve data from the traffic controller as shown in Table I. [NTCIP 1201] [NTCIP 1202] This table includes one object from the 1201 standard, which is the current local time. The local time is used to keep the time recorded on the bridge accurate from the perspective of the traffic controller. The other objects come from the 1202 standard which are used to set and retrieve phase data.
Table I. MIB Objects used for pedestrian walk/wait state and timing information.
Standard / Object ID / Table Entries1201 / 1.3.6.1.4.1.1206.4.2.6.3.6.0 / Global Time
1202 / 1.3.6.1.4.1.1206.4.2.1.1.1.0 / Maximum number of phases
1202 / 1.3.6.1.4.1.1206.4.2.1.1.3.0 / Maximum number of phase groups
1202 / 1.3.6.1.4.1.1206.4.2.1.1.5.1 / VehCall, PedCall
1202 / 1.3.6.1.4.1.1206.4.2.1.1.4.1 / Red; Yellow; Green; PedClear; PedCall; PhasesOn; NextPhase
1202 / 1.3.6.1.4.1.1206.4.2.1.1.2.1 / Walk; PedClear; MinGreen; Startup; Options; Ring
.
In support of this project, Econolite created a custom version of the ACS/3 firmware to process objects for the pedestrian timing data that was missing from the off-the-shelf ASC/3 controller. The custom object keeps track of the timing of the current phase and the state of the Pedestrian crossing in each phase.
A WEB based configuration program that is hosted by the traffic controller processor that allows mapping of the MIB variables to specific devices using a laptop computer. If a node’s power-settings, phase, or safety critical data is changed, then the bridge node sends the new data to the PnP controller. The management control also has the ability to install or remove nodes from the intersection. An example of this WEB page is shown in Figure 2. Using WEB based control that is hosted on the translation microprocessor allows any laptop with a WEB browser and Ethernet port to be used and alleviates the need for special application software on the user interface laptop.
Figure 2. Status WEB page hosted by the translator microprocessor.
PnP Controller to Translator Communication
Three categories of messages are sent from the translator controller to the PnP controller: a configuration packet, a traffic state packet, and a keep-alive packet. The PnP controller error messages and detector trips data are sent to the ASC/3 controller via the translator processor. The PnP controller communicates with the with the translator controller using a high-speed 8 bit bidirectional parallel data port using a master-slave mailbox data exchange structure supported by the RCM 3000 Rabbit Microprocessor processors used for all embedded nodes.
PnP Controller to PnP Device Communication
The PnP controller communicates with all PnP devices on the PnP network using two types of messages: configuration packets and state update packets. The configuration packets are unicast messages used to notify individual nodes of changes in their configuration that originate from the webpage or from the translator processor. Each configuration packet specifies a setting for the node’s phase, power mode, and whether or not the data is safety-critical.
State-update packets are multicast to all nodes in the network by the PnP controller every time it receives new state information from the translator controller. After sending a state update, the PnP controller waits until all safety critical nodes in the system respond to the update before sending another broadcast message acknowledging the commanded state. This type of message is called an “implement packet” that instructs the nodes to change state instantly upon receipt of the message.
There are also three broadcast messages that do not contain traffic signal state information. There are heartbeat messages that simply indicate that the PnP device is still functioning. There is a message indicating that the PnP controller has detected a critical error in the intersection and instructs all of the nodes to transition into a safe-fail mode. The PnP controller sends out a message when initializing to instruct all nodes on the network to transmit their electronic descriptions back so that the PnP controller can determine which nodes are connected.
The PnP controller periodically interrogates the status of each smart device. If the PnP controller receives an error message from a smart device or if a node does not respond in the appointed time window, the PnP controller passes that error message back to the translator controller to have that data saved in a log file. The error log is accessed from interface laptop through the WEB page hosted by the translation controller.
Systems Hardware
The RCM3000 series was used for all PnP smart sensor designs. The system consists of two Ethernet networks each requiring a network switch or hub, a data bridge and two PnP networks nodes. When using Ethernet over power line modems, no hub or switch is required for the PnP network. The bridge consisting of independent translator and PnP processors is needed because the RCM 3000 processors can only host one Ethernet port. Since our design used a separated network, two processors are required. The functionality of the two processors was allocated to level the processing burden for improved response performance.
Pedestrian Signal
The display configuration of the new smart countdown and walk-wait signal shown in Figure 3 and Figure 4. They are designed that allowed individual LED control and monitoring and variable display intensity. The countdown timer display consisted of two LED matrices each consisting of an eight by 16 LED array for each matrix. With individual LED control, a wide range of characters and symbols can be displayed for pedestrian information. These smart signals were able to detect and send alarms back to the controller in the event of a signal failure. By having control of each individual LED in the display permits displaying symbols other than conventional numbers thus allowing additional information to be conveyed to the pedestrians.
The contrast of the LEDs is controlled by the pulse width modulation (PWM) output of the microprocessor. Possible uses of variable intensity control include adaptively reducing energy requirements, increasing LED longevity, and reducing light pollution or interference. The PnP feature of the smart signal technology makes it possible for the signal to have electronic descriptions of the signals capability and performance characteristics.
Figure 3. LED placement for the PED Countdown timer /
Figure 4. LED placement for the PED Countdown timer
The smart PnP pedestrian call button provides feedback from the controller to acknowledge when request for service is registered in the traffic controller. It is anticipated that this visual or audio display of this feedback will discourage physical abuse of the call button and to encourage pedestrians to wait for the walk indication in lieu of making a hazardous and illegal attempt to cross the street. The smart pedestrian call button is also equipped with remote request for use by people who are blind or who are physically handicapped and have difficulty locating or accessing the call button. As such, the system is able to differentiate between needs of pedestrian requesting service. The acknowledgment feedback feature is available for the remote wireless pedestrian button as well.
The smart pedestrian signal is drop-in-replaceable since no additional wires are required between the traffic controller cabinet and the pedestrian signal if Ethernet over power line technology is utilized. The wires needed for supply power for electronics and display are also used for network communications. Although the system was tersted using 10MB Ethernet over power line modems, 200MB modems have since become commercially available at the time of this writing.
4. Results
The system was successfully demonstrated at the University of Idaho 2006 Engineering Expo. With very strict control over the network information flow, the whole system worked with no failures. The smart signal system countdown timer accurately displays the crossing time remaining during normal operations and when signal timing changes. The remaining clearance interval is also correctly displayed when the traffic controller is preempted. There were no observable differences in the walk/wait displays when compared to conventional units operating simultaneously on the same traffic controller while the conventional pedestrian operated correctly. Differences were observable when the traffic controller was preempted and when phase timing was forced to change. The variable illumination level can save significant energy costs.