Application of Plug and Play Distributed Sensor Network Technology to Traffic Signals
Submitted by:
Dr. Richard W. Wall, P.E.
Associate Professor
National Institute for Advanced Transportation Technology
Department of Electrical and Computer Engineering
PO 441023
University of Idaho
Moscow, ID83843-1023
208.885.7226
208.885.7579 (FAX)
Andrew Huska, E.I.T.
Graduate Research Assistant
Department of Electrical and Computer Engineering
PO 441023
University of Idaho
Moscow, ID83843-1023
208.661.9242
208.885.7579 (FAX)
Darcy Bullock, P.E.
Professor
School of Civil Engineering
PurdueUniversity
550 Stadium Mall Drive
West Lafayette, IN47907
Word count:4693
Number of figures:7 (1750 words)
Number of tables:3 (750 words)
Total word count:7193
Submitted for presentation at the 85th Annual Meeting of the Transportation Research Board, January 22-26, 2005 and for publication in Transportation Research Record, the Journal of the Transportation Research Board.
29 October 2005
Abstract
Modern signalized intersections require the installation of several hundred dedicated conductors to each traffic signal head, pedestrian indication, pedestrian button, loop detector, and other auxiliary devices. No intelligence is distributed outside of the signal cabinet. A demonstration system was built to explore the applicability of plug and play distributed sensor network technology to traffic signals. This technology, using the IEEE1451 standard, would facilitate the deployment of intelligent traffic signal infrastructure. This paper discusses an open architecture prototype based on 10baseT Ethernet communications connecting a simulated traffic controller to four nodes consisting of a single traffic signal and eight count down pedestrian signals. Included electronic data sheets describe signals and sensors that adhere to the IEEE 1451 standard and demonstrate the plug and play capability. A laptop PC simulates a simple semi-actuated traffic controller algorithm and provides network diagnostics. Areas for further research are identified.
BACKGROUND
The rapid advancement of the microprocessor in the 1970s and intense competition led to many developments in traffic controllers (e.g. alternative phase sequences and new detector operating modes). A variety of vendors rapidly entered and exited the traffic control field in the 1970s. So many changes prompted a group of vendors to come together in the 1980s to draft a standard specification commonly referred to as TS1 (1). 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 on the philosophy that controllers would provide a basic set of features and standard 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. This introduced further incompatibility and procurement issues, particularly when government agencies later needed to upgrade existing signal systems and had to solicit competitive bids. In the late 1980s, the NEMA TS1 specification was updated (NEMA TS2) to provide coordinated-actuated operation, preemption, and an optional serial bus that was designed to simplify cabinet wiring (2). Unfortunately, the serial bus was proprietary to the traffic control industry and the standard has not facilitated the inclusion of new sensing devices.
Regardless of the capability of the processors used in present day traffic controllers, they are information bound since the architecture uses a central processor and one wire per output for signals or input for sensors. The information density is constrained to a single symbol per display. Signals are further constrained to the configurations as installed and require extensive manpower and possibly traffic disruption to modify. Signals cannot be easily changed from ball signals to arrow signals to adapt to emergency, construction, or special activity events. In order to add control for additional phases of traffic movement today, additional control signals must routed from the traffic control cabinet to the new signal or sensor.
For example, there is interest in the countdown pedestrian signals; however current installations are drop-in replacement for conventional pedestrian signals. Due to the limited information available to the pedestrian signal, the new countdown pedestrian signals must “learn” when to initiate the countdown sequence by observing the adjacent green phase interval. Any changes due to time-of-day signal timing result in an inaccurate countdown, potentially stranding pedestrians in the middle of the intersection.
Typically a NEMA type controller cabinet such as the one shown in Figure 1 includes the controller, conflict monitor, loop detectors, load switches, and cable terminations (1), (2). Connectors and cabling require space and are expensive to manufacture, install, and maintain. The 2070 type controllers reduced much of the cabling requirements between the controller and the load switches and loop detectors by using the serial I/O similar to NEMA TS2 Type 1 Cabinets (2), (3). However, the requirements for space to accommodate load heads and loop detectors do little to reduce the size of the controller cabinet.
Figure 1 Typical Traffic Controller Installation
A typical controller cabinet installation has little aesthetic value regardless of age and represents a liability from the perspective of vandalism or traffic accidents. Depending upon the number of load switches and loop detectors needed for a specific intersection, a traffic controller cabinet may occupy considerable space on an urban street corner with scarce real-estate, making the location the cabinet problematic due to its physical size.
Some efforts have been made to develop more intelligent traffic signal control components and distribute those components around the intersection (4), (5), (9). However, the lack of mature standards and viable field-hardened building blocks has impeded any advancement of products beyond the prototype stage, with the exception of devices from a European traffic control manufacturer (13).
The following sectionsdescribea distributed plug-n-play vision based upon the IEEE1451 family of standard. Subsequent sections tabulateperformance data and detail areas for further development.
PURPOSE OF RESEARCH PROJECT
An important objective for this project was to improve the adaptability and functionality of traffic controllers while reducing its physical size of the controller cabinet and the number of wires needed for signals and sensors. By providing more information to pedestrian and drivers, the ambiguity of intent displayed by today’s limited signal states can be reduced, thus increasing both the safety and effectiveness of the intersection (1), (4). To achieve this objective, we defined the following goals:
- Introduce a process for defining an electronic description of the behavior of traffic signals and sensors.
- Develop a working prototype to measure performance and demonstrate functionality and adaptive capability.
- Determine the operating performance of Plug and Play (PnP) traffic signals and sensors implemented as a distributed network.
Assumptions:
- Network communications will be provided by CAT5 Ethernet cables or Ethernet over broadband power line carrier (BPL).
- Technicians will be adequately trained and have the appropriate tools to properly maintain the controllers.
- We presuppose that electronic descriptions will be included in NTCIP standards at the appropriate time and by the appropriate organization. No attempt was made at this point in the research to apply NTCIP standards to the distributed sensor network (DSN).
Limitations
Reliable operation of the traffic control system is of utmost concern. Two levels of operation exist in a system such as this: information exchange and hardware. Information exchange encompasses the robust operation of software and delivery of data in a network. This research fully understands the need for dependable information exchange as it relates to safe-fail operation of the traffic control system and realizes the need for a conflict monitoring system that is compatible with the distributed nature of the network. These topics are beyond the scope of this exploratory research but are addressed in the FUTURE RESEARCH section below.
Robust hardware operation is also beyond the scope of this research, but is briefly addressed. There is a concern that distribution of electronics in various devices around an intersection will reduce reliability and increase maintenance costs. Although weather tends to be the source of most concern, device failure rates are also anissue. However, sensitive electronics are already being deployed in the field with acceptable failure rates, and careful engineering judgment should always be exercised when deploying any such device.
There are three exposure points for traffic signals: direct lightning strike of the electronics;power supply transients caused by load switching or external lightning strikes; and transients introduced to network communications connections. Proper equipment fabrication and installation grounding practices can reduce exposure for the first scenario. The second and third scenarios are topics of continuing investigation and development (14). Best practices for proper grounding of traffic signals will have to be addressed to minimized component failures and risk to persons working on the equipment. Furthermore, others have addressed the issues of system reliability, fault tolerance, and redundancy in great detail (11). This previous work can be directly and transparently applied to our system (12).
IEEE1451 Overview
To achieve the goal of electronically describing signal and sensor behavior, IEEE1451 was employed (5). The IEEE 1451 standard developed for PnP smart sensors is composed of seven subparts as shown in Table1. Figures 2 and 3 represent the implementation of IEEE1415 to traffic controls for this research. The Network Capable Application Processor (NCAP) acts as an interface between the Smart Transducer Interface Module (STIM) and the network. The STIM is the interface for a signal or sensor that allows it to function as a PnP smart sensor. The NCAP allows one STIM to be used with any type of sensor network. Communication between STIMs is managed completely by the NCAPs. An NCAP and STIM are connected via a standardized connection called the Transducer Independent Interface (TII).Since NCAPs require few unique features, they are inexpensive to build for any type of network while the more expensive STIMs are universally compatible.Although the NCAP and STIM are logically independent, they could be implemented on a single processor. This would cause a STIM to lose network independence, but the economic benefits could be greater.
Table1 Definitions of IEEE 1451 Subparts
Subpart / Description / Date of AdoptionP1451.0 / Defines basic IEEE 1451 structure, data protocols, and formats. / Proposed
1451.1 / Defines the NCAP information model that provides an object-oriented abstraction between a transducer and a network. This allows a transducer to be independent of the network type. / 1999
1451.2 / (i.)Defines the digital transducer independent interface (TII) for connecting transducers to microprocessors.
(ii.)Describes a transducer electronic data sheet (TEDS) and transducer data format.
(iii.)Defines an electrical interface, read and write logic functions to access the TEDS. / 1997
1451.3 / Defines a Transducer Bus Interface Module TBIM, which is a standard digital interface that can connect multiple physically separated transducers in a multidrop configuration. / 2003
1451.4 / Defines a standard interface that will allow analog transducers to operate in a mixed-signal mode. By this, the transducer starts up in a digital signal communication mode for self-identification and control purposes, and then it switches to analog signal mode for operational purposes. / 2004
P1451.5 / Addresses wireless communications between the NCAP and a transducer with a TEDS. / Proposed
P1451.6 / Defines a protocol using CAN for the network. / Proposed
Figure2 Conceptual layout of a retrofitted PnP traffic control network.
Figure 3 Detail view of an "Intelligent, Network-enabled Traffic Control Device" block.
Network Capable Application Processor
The NCAP is the bridge between the chosen type of network and a STIM with smart control devices (6). The NCAP can also be used to preprocess data coming from the STIM. A fully compliant NCAP can be used with devices designed around one or more of the IEEE1451.2-6 standards, although this demonstration traffic controller system currently uses only the 1451.2 standard (7). For this reason, the main network controller (in this case, traffic controller) does not access STIMs directly but sends high-level commands to an NCAP that translates the message and communicates with each type of STIM appropriately. The main network controller is essentially a STIM itself.
Smart Transducer Interface Module
A STIM manages sensors and signals and allows them to act as smart control devices.A sensor or signal (collectively called transducers) delivers or receives its data to/from the STIM that formats, and if necessary, preprocesses the data. The STIM contains an electronic description of the transducer's behavior transducer that is called a Transducer Electronic Data Sheet (TEDS).The TEDS stores a variety of information including a human readable description of the sensor, a description of the physical units represented by the transducer’s data, valid data ranges, calibration capabilities, and timing specifications.
Transducer Independent Interface
The TII is the standardized communication interface between the NCAP and STIM. There is a different TII definition for each IEEE1451.2-6 standard (6). The IEEE1451.2 TII consists of a synchronous serial communications channel, power and ground, and control and status lines. The TII also defines a communication protocol. Only the NCAP can initiate a serial transfer, but the STIM can request a transfer by the interrupting the NCAP. This allows the smart sensors to push data to the network controller rather than simply being polled. The NCAP can also trigger the STIM to initiate sending a new data value to an output device or gathers data from an input device.
Transducer Electronic Data Sheet
A TEDS, as shown in Figure 3, is stored in a STIM and electronically describes the hardware and operation of transducer(s) connected to the STIM. There is one TEDS per STIM regardless of the number of channels, but there can be many sub-parts to the TEDS. See Table2 for a description of the TEDS sections. Only the MetaTEDS and the Channel TEDS are required for a STIM to operate properly. There must be a Channel TEDS for every transducer attached to the STIM, but there is only one MetaTEDS. Table3 shows an example Channel TEDS definition.
Table2 Information Organization of a TEDS
TEDS Type / TEDS FunctionMeta TEDS / Contains the mandatory machine-readable data that describes the entire STIM. The data may include information such as the revision of the IEEE standard, version of the TEDS, number of channels, and timing restriction.
Channel TEDS / Contains the mandatory machine-readable data that describe each transducer channel in the STIM. The data may include information such as the transducer type, calibration model, physical units, limits range, data format, and the timing restriction for the relevant transducer channel.
Meta-Identification TEDS / Provides the optional human-readable (Text/ASCII) data for the overall STIM. Data may include information such as manufacturer’s name, model number, serial number, version codes, date codes, and product description.
Calibration TEDS / Contains the optional machine-readable data when a correction engine is used in the STIM. The data may include information such as the calibration coefficients, intervals, date, and time for each transducer channel that requires calibration.
Channel-Identification TEDS / Provides the optional human-readable data similar to Meta-Identification TEDS, except that it is for an individual channel. This data is used when a STIM is built with multi-channel transducers from different manufacturers.
End-User’s Application-Specific TEDS / Provides the additional human-readable data not covered by the specific TEDS described above. The data may include information such as the location of the STIM and the contact information for technical inquiry.
Generic Extensions TEDS / Allows an option for the future extension to the TEDS described above. This option is available for use by industry and standards organizations.
Table3 Example ChannelTEDS Definition of a Pedestrian Countdown Indicator
Field / Abbreviated Name / Value / Comments1 / ChannelTEDS Len / Will be calculated by program
2 / Calibration Key / CAL_NONE / No calibration information needed or provided
3 / Calib TEDS Ext Key / 0 / No calibration extension implemented in STIM
4 / Data Fields Ext Key / 0 / No data field extension implemented in STIM
5 / Industry TEDS Ext / 0 / No TEDS extension implemented in STIM
6 / EndUsersAppTEDS / 0 / No End Users Application Specific TEDS for channel
7 / Writeable TEDS Len / 0 / There are no writable TEDS areas for this chan
8 / Channel Type Key / TRANSDUCER / General transducer is attached to channel
9 / Physical Units / UNITS_PRODUCT, 128, 128, 128, 128, 135, 128, 128, 128, 128 / Units of seconds
10 / LowerRange Limit / 0 / Zero is the minimum number of seconds
11 / UpperRange Limit / 255 / 255 seconds is the maximum
12 / Data Max Uncertainty / 0 / In the same physical units of the data
13 / Self-test Key / 0 / No self-test function needed or provided
14 / Channel Data Model / 0 / n-byte integer
15 / Chan Data Model Len / 1 / 1 byte long data
16 / Data Model Sgnf Bits / 8 / All 8 bits of the byte are needed
17 / Chan Data Repetitions / 0 / No data repetitions
18 / Series Origin / NaN (not a number) / Not defined because data repetitions = 0
19 / Series Increment / NaN / Not defined because data repetitions = 0
20 / Series Units / UNITS_DIGITAL_DATA, 128, 128, 128, 128, 128, 128, 128, 128, 128 / Physical units of series origin, not applicable here
21 / Update Time / 0.100 / Max seconds between trigger and channel ack
22 / Write Setup Time / 0.001 / Max seconds between write frame and trigger
23 / Read Setup Time / 0.001 / Max seconds between read frame and trigger
24 / Sample Period / 0.001 / Min seconds between trigger and read frame
25 / Warm-up Time / 0.001 / Max seconds to stabilize after power up
26 / Total Hold-off Time / 0.010 / Max time STIM will hold off a serial transfer
27 / Timing Correction / 0.001 / Offset in seconds trigger ack and actual sample/update
28 / Trigger Accuracy / 0.001 / Accuracy in seconds of timing correction
29 / Event Seq Options / 0 / Not applicable
30 / TEDS Checksum / Will be calculated by program
Demonstration System