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, Purdue University
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 nonmotorized 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 coordinatedactuated 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.
Draft #9: July 26, 2006
1
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
Draft #9: July 26, 2006
2
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 closedloop 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.
User Interface Laptop
PED
Signal
Unit
Bridge/
Controller
CAT 5 Ethernet
Ethernet on Powerline
Ped call button
with wireless
transreceiver
Home Base Laptop
Remote wireless
Ped call button
Advanced
Controler System
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
Draft #9: July 26, 2006
3
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 1 to 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
1201
1202
1202
1202
1202
1202
Object ID
1.3.6.1.4.1.1206.4.2.6.3.6.0
1.3.6.1.4.1.1206.4.2.1.1.1.0
1.3.6.1.4.1.1206.4.2.1.1.3.0
Table Entries
Global Time
Maximum number of phases
Maximum number of phase
groups
1.3.6.1.4.1.1206.4.2.1.1.5.1 VehCall, PedCall
1.3.6.1.4.1.1206.4.2.1.1.4.1 Red; Yellow; Green; PedClear;
PedCall; PhasesOn; NextPhase
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 offthe-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
Draft #9: July 26, 2006
4
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
Draft #9: July 26, 2006
5
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
Draft #9: July 26, 2006
6
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.
Draft #9: July 26, 2006
7
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.
Only a smart pedestrian call button was implemented. This gave the conventional
pedestrian signal the same call reference as the smart PnP pedestrian signal. Testing of
inputs from a conventional call button was simulated using the home base laptop. Table
II provides details of hardware costs of the demonstration system.
Table II. Cost breakdown of demonstration smart traffic system hardware.
Pedestrian call button with RF transceiver for remote operation
Wireless remote pedestrian call button
Smart countdown pedestrian signal
Smart Walk/Wait signal
Network and bridge
$620
$43
$1,370
$1,150
$900
Problems did surface during testing resulting from limitations of the 10MB Ethernet
controllers. When using the 10MB Ethernet over power line modems, occasionally a data
packet would be dropped because of excessive delays. This problem is exacerbated when
multiple nodes power up or reboot simultaneously. The result is that only one node will
be configured with the hub and the other will time out and require re-booting. When
direct wire CAT 5 Ethernet cable is used instead of the Ethernet over power line modems,
the network speed would increase sufficiently resulting in minimal delays in transmitting
messages from the PnP Controller and each node thus eliminating the problem.
The bridge has to request multiple large SNMP packets of information and then filter
them to retrieve the correct information. There is considerable wasted time in retrieving
information that has no use for the PnP system. A possible solution is to update the traffic
controller firmware to be capable of sending more precise information in one SNMP
packet.
4. Conclusion
The project successfully developed proof-of-concept prototypes for a distributedsignal-network of PnP traffic signal devices. TS2 traffic controllers with minor
modifications can support but conventional and smart PnP traffic signal devices. The
continuation of research for implementing IEEE 1451 in signalized intersections
demonstrated network communication over power line carrier, traffic controller
Draft #9: July 26, 2006
8
integration, single microcontroller IEEE 1451 operation, and improvements in accuracy
and intersection services. Prototype IEEE 1451 compliant devices developed include a
bridge controller for communication with traffic controller variable intensity pedestrian
crossing and countdown signals, and pedestrian crossing button with wireless button.
Hosting a webpage for the maintenance of the PnP system does not require additional
hardware or specialized software to be installed on laptop computers. Testing of the PnP
network makes it reasonable to anticipate that recent advances in Ethernet over power
line technology will resolve the issues addressed in the results above.
Draft #9: July 26, 2006
9
References
1. “Transportation Infrastructure, Benefits of Traffic Control Signal Systems Are Not Being
Fully Realized,” GAO/RCED-94-105, Report to the Chairman, Committee on Energy and
Commerce, House of Representatives, United States General Accounting Office,
Washington, DC, March 1994.
2. Wolkomir, R., “A High-Tech Attack on Traffic Jams Helps Motorists Go with the Flow, “
Smithsonian, Vol. 17, No. 1, pp. 42-51, April 1986.
3. National Electrical Manufacturers Association, Standards Publication No. TS 1,
Washington, DC, 1989.
4. Quinlan, T., “Evaluation of Computer Hardware and High-Level Language Software for
Field Traffic Control,” Technical Report, California Department of Transportation,
Sacrament, CA 1989.
5. National Electrical Manufacturers Association, Standards Publication No. TS 2,
Washington, DC, 1992.
6. Bullock, D. “Implementation Vision for Distributed Control of Traffic Signal SubSystems,”
Transportation Research Record, #1554, TRB, National Research Council, Washington,
DC, pp. 43-47, 1996.
7. Bullock, D., A. Harvey, and C. Messer, “Deployment of Fiber Optic Lane Use Indication
Signs Using a Distributed Control Architecture,” Computer-Aided Civil and Infrastructure
Engineering, Blackwell, Vol. 14, No., pp.249-256, 1999.
8. Urbanik, T, D. Bullock, L. Head, D. Gettman,. R. Campbell, M. Ablett, Ed Smaglik, S.
Beaird, J. Yohe, S. Quayle, ”Traffic Signal State Transition Logic Using Enhanced Sensor
Information, NCHRP 3-66 Final Report, NAS TRB, 2006.
9. Simple Network Management Protocol,
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/snmp.htm, last accessed on
7/12/2006.
10. Bentzen, B.L., J.M. Barlow, and L. Franck,”Addressing Barriers to Blind Pedestrians at
Signalized, Intersetions, Institute of Transportation Engineers Journal, pp.32-35 September
2000.
11. Markowitz, F., S. Sciortino, F.J. Lucero, B.M. Yee, “Pedestrian Countdown Signals:
Experience with an Extensive Pilot Installation,” Institute of Transportation Engineers
Journal, pp.43-48, January 2006.
12. Wall, R. W. and A. Huska, “Design Platform for Plug-and-Play IEEE 1451 Traffic Signal,”
Accepted for the 31st Annual IEEE Industrial Electronics Conference, Raleigh, NC, Nov 610, 2005, Paper No. RD-001973.
13. Wall, R. W., A. Huska, and D. Bullock, “Application of Plug and Play Distributed Signal
Technology to Traffic Signals,” Accepted for presentation at the Transportation Research
Board 2006 Annual Meeting, Washington D.C., January 22-26, 2006, Paper No. 06-2728.
14. NTCIP 1201 Global Object Definitions v02.26, AASHTO, 44 North Capitol St., N.W. Suite
249, Washington DC, 2001, December 20, 2002
15. NTCIP 1202:1966 Amendment 1 Object Definitions for Actuated Traffic Signal Controller
Units, Draft version 01.06, AASHTO, 44 North Capitol St., N.W. Suite 249, Washington DC,
2001, October 19, 1999
Draft #9: July 26, 2006
10