APPLICATION OF PLUG-AND-PLAY DISTRIBUTED SIGNAL TECHNOLOGY TO TRAFFIC SIGNALS

Transcription

1 APPLICATION OF PLUG-AND-PLAY DISTRIBUTED SIGNAL TECHNOLOGY TO TRAFFIC SIGNALS FINAL REPORT JANUARY 2006 KLK241 NIATT Report Number N06-01 Prepared for OFFICE OF UNIVERSITY RESEARCH AND EDUCATION U.S. DEPARTMENT OF TRANSPORTATION Prepared by NATIONAL INSTITUTE FOR ADVANCED TRANSPORTATION TECHNOLOGY UNIVERSITY OF IDAHO Richard W. Wall, Andrew Huska; Darcy Bullock

2 DISCLAIMER The contents of this report reflect the views of the authors, who are responsible for the facts and the accuracy of the information presented herein. This document is disseminated under the sponsorship of the Department of Transportation, University Transportation Centers Program, in the interest of information exchange. The U.S. Government assumes no liability for the contents or use thereof.

3 1. Report No. 2. Government Accession No. 3. Recipient s Catalog No. 4. Title and Subtitle Application of Plug-and-Play Distributed Author(s) Richard W. Wall, Andrew Huska; Darcy Bullock 9. Performing Organization Name and Address National Institute for Advanced Transportation Technology University of Idaho PO Box ; 115 Engineering Physics Building Moscow, ID Sponsoring Agency Name and Address US Department of Transportation Research and Special Programs Administration th Street SW Washington, DC Supplementary Notes: 5. Report Date January Performing Organization Code KLK Performing Organization Report No. N Work Unit No. (TRAIS) 11. Contract or Grant No. DTRS98-G Type of Report and Period Covered Final Report: August 2004-August Sponsoring Agency Code USDOT/RSPA/DIR 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-andplay distributed sensor 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 countdown 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. 17. Key Words Communication and control; intersection elements; networks; detectors; signals 18. Distribution Statement Unrestricted; Document is available to the public through the National Technical Information Service; Springfield, VT. 19. Security Classif. (of this report) Unclassified 20. Security Classif. (of this page) Unclassified 21. No. of Pages Price Form DOT F (8-72) Reproduction of completed page authorized

4 TABLE OF CONTENTS EXECUTIVE SUMMARY... 1 APPROACH AND METHODOLOGY... 2 Purpose of Research Project... 5 IEEE1451 Overview... 7 Network Capable Application Processor... 9 Smart Transducer Interface Module Transducer Independent Interface Transducer Electronic Data Sheet Demonstration System Demonstration Intersection Demonstration Microprocessors Demonstration Traffic Controller Time Performance Future Research CONCLUSION REFERENCES Application of Plug-and-Play Distributed i

5 EXECUTIVE SUMMARY 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-lay distributed sensor 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 countdown 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. Application of Plug-and-Play Distributed 1

6 APPROACH AND METHODOLOGY 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 controllers 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 has yet to gain widespread acceptance, much less support hardware infrastructure that would facilitate broader use and innovation. 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 Application of Plug-and-Play Distributed 2

7 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 industry for improvements to 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. Application of Plug-and-Play Distributed 3

8 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 realestate, 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 beyond the prototype stage. Application of Plug-and-Play Distributed 4

9 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 pedestrians 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: 1. Define a process for generating an electronic description of the behavior of existing traffic signals and sensors. 2. Develop a working prototype to measure performance and demonstrate functionality and adaptive 3. Determine the operating performance of plug-and-play (PnP) traffic signals and sensors implemented as a distributed network. Assumptions: 1. Traffic signals will use LED arrays that allow individual LED control to facilitate dynamic symbol generation. 2. Network communications will be provided by CAT5 Ethernet cables or Ethernet over broadband power line carrier (BPL). 3. Technicians will be adequately trained and have the appropriate tools to properly maintain the controllers. Limitations: 1. Safe-fail Operations: Conflict monitoring and other safe-fail operations are discussed in the section about future research below. 2. Device reliability: There is a concern that distribution electronics in various signals and sensors around an intersection will reduce reliability and increase maintenance costs. Although weather tends to be the source of most of the concerns, device failure Application of Plug-and-Play Distributed 5

10 rates are also a concern. 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. 3. Standards a. No attempt was made at this point in the research to apply NTCIP standards to the distributed sensor network (DSN). We presuppose that electronic descriptions will be included in NTCIP standards at the appropriate time and by the appropriate organization. b. Experiments with dynamic signal configurations did not consider current constraints imposed concerning the types of symbols that are permissible ((10)). We assume if a new symbol other than a ball or arrow has merit to improve controllability or safety, it will be accepted through the normal procedures for modifying the existing standards Furthermore, we did not consider regulations about using a single red, yellow, or green signal to display multiple symbols such as an arrow or ball at different times. Application of Plug-and-Play Distributed 6

11 IEEE1451 Overview To achieve the goal of electronically describing signal and sensor behavior, IEEE1451 was employed ((5)). IEEE 1451 standard developed for PnP smart sensors are composed of seven specific standards as shown in Figure 2 Conceptual layout of a retrofitted PnP traffic control network. Table 1. 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. Application of Plug-and-Play Distributed 7

12 Figure 2 Conceptual layout of a retrofitted PnP traffic control network. Table 1 Definitions of IEEE 1451 Subparts Subpart Description Date of Adoption P Defines basic IEEE 1451 structure, data protocols, and formats. Proposed Defines the NCAP information model that provides an object-oriented 1999 abstraction between a transducer and a network. This allows a transducer to be independent of the network type Defines the digital transducer independent interface (TII) for connecting 1997 transducers to microprocessors. Describes a transducer electronic data sheet (TEDS) and transducer data format. Defines an electrical interface, read and write logic functions to access the TEDS Defines a Transducer Bus Interface Module TBIM, which is a standard digital interface that can connect multiple physically separated transducers in a multidrop configuration Application of Plug-and-Play Distributed 8

13 Defines a standard interface that will allow analog transducers to operate 2004 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. P Addresses wireless communications between the NCAP and a transducer Proposed with a TEDS. P Defines a protocol using CAN for the network. Proposed 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 IEEE Application of Plug-and-Play Distributed 9

14 6 standards, although this demonstration traffic controller system currently uses only the 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. Application of Plug-and-Play Distributed 10

15 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 IEEE standard ((6)). The IEEE 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. Table 2 describes 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. Application of Plug-and-Play Distributed 11

16 Table 3 shows an example Channel TEDS definition. Table 2 Information Organization of a TEDS TEDS Type Meta TEDS Channel TEDS Meta- Identification TEDS Calibration TEDS Channel- Identification TEDS End-User s Application- Specific TEDS Generic Extensions TEDS TEDS Function 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. 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. 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. 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. 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. 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. Allows an option for the future extension to the TEDS described above. This option is available for use by industry and standards organizations. Application of Plug-and-Play Distributed 12

17 Table 3 Example ChannelTEDS Definition of a Pedestrian Countdown Indicator Field Abbreviated Name Value Comments 1 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, Units of seconds 128, 128, 128, 135, 128, 128, 128, Lower Range Limit 0 Zero is the minimum number of seconds 11 Upper Range Limit 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, Physical units of series origin, not applicable here 128, 128, 128, 128, 128, 128, 128, 128, Update Time Max seconds between trigger and channel ack 22 Write Setup Time Max seconds between write frame and trigger 23 Read Setup Time Max seconds between read frame and trigger 24 Sample Period Min seconds between trigger and read frame 25 Warm-up Time Max seconds to stabilize after power up 26 Total Hold-off Time Max time STIM will hold off a serial transfer 27 Timing Correction Offset in seconds trigger ack and actual sample/update 28 Trigger Accuracy Accuracy in seconds of timing correction 29 Event Seq Options 0 Not applicable 30 TEDS Checksum Will be calculated by program Application of Plug-and-Play Distributed 13

18 Demonstration System Demonstration Intersection A circuit board was developed that represents a four-approach intersection (Fig. 4). Each approach has a three-color traffic signal, a vehicle detector, pedestrian walk/wait signs on both sides of the approach, pedestrian call buttons on both sides, and pedestrian countdown timers on both sides. The model created represents the actual traffic control configuration shown in Figure 5. Figure 4 Demonstration System Signal Display Board Application of Plug-and-Play Distributed 14

19 Figure 5 Traffic Control Configuration Modeled in Demonstration System The traffic signals on the demonstration system are unique; each color consists of a 25-LED array in which every LED is individually controlled allowing it to display arrows, balls, or any other shape. The signal can be programmed to flash or remain on, and it can report its state back if needed. The vehicle detector is simply a toggle switch attached to a software counter for this basic demonstration; it can be reset, disabled, and polled for its vehicle count. The pedestrian walk/wait light operates in the typical fashion, but the pedestrian timer is directly programmed with a start-time by the controller so the timer does not need to learn the proper duration with possible errors. The pedestrian button latches the event when it is pressed, and it can be set, reset, polled, or disabled by the controller. Each approach is controlled by one STIM and NCAP that are on a separate circuit board mounted underneath the demonstration intersection. In this circuit board demonstration, the TEDS are stored in a removable memory chip that is separate from the sensor control hardware. The contents of this memory chip describe both the hardware that is connected its capabilities. Application of Plug-and-Play Distributed 15

20 We demonstrate the PnP capability by moving the non-volatile memory IC containing the TEDS from one STIM processor to another. When the TEDS only describes some of the intersection sensors or signals, the other sensors are unknown to the traffic controller and hence unavailable for inputs or outputs. In practice, most of the traffic control devices will have their own STIM and TEDS and will be integrated into the smart traffic control devices by manufacturers. In this manner, the traffic controller will reconfigure itself whenever a device is connected to or removed from the network. Demonstration Microprocessors The processor used for this demonstration system is a multi-purpose 8-bit microcontroller core. The chosen processor modules were used in this system to realize the NCAP because of the pre-installed Ethernet connection and on-board 10BaseT TCP/IP stack. This processor module operates at 29MHz, has 1MByte of memory and six serial ports. For this system, four NCAP processors are connected to each other using a standard Ethernet hub. The STIMs for this system were constructed using similar, lower-memory, non-ethernet-equipped processors. The memory available on these two microcontrollers exceeded the requirements for the NCAP by approximately 800 percent and the STIM by 300 percent. The network controller can send a command packet to the NCAP over TCP, wait for the NCAP to process the packet and receive data from the STIM, and receive a reply packet via a new TCP connection in approximately 30 ms. Sending a data packet without waiting for processing or a reply connection takes about 6 ms. These measurements were taken with no attempt to optimize or maximize any software, network or TII performance. Processor speed for the NCAP and STIM was sufficient for this proof of concept demonstration, but using faster devices would increase network responsiveness. However, this demonstrates that minimal hardware requirements are needed to enable smart sensor devices. Demonstration Traffic Controller An Ethernet-enabled PC is also connected to the hub and acts as the traffic controller. A basic PnP traffic controller was written that provides the capabilities to connect to an NCAP Application of Plug-and-Play Distributed 16

21 using TCP and send a message, and to establish a server that continuously listens for incoming TCP connections from NCAPs and receive messages. The traffic controller graphical user interface is shown in Figure 6. Messages that the controller can send include requests for STIM transducer descriptions, requests for STIM transducer channel data, and requests for the NCAP to report the operational status of the STIM. The controller can also send messages to set data values for any of the STIM channels. Messages that the controller can receive include STIM transducer descriptions, transducer data and STIM status information. A number of selection boxes in the program allow a user to choose what data to send to each transducer channel. Figure 6 Screenshot of PnP Traffic Controller Software When the traffic controller receives a STIM description message and decodes it to determine what the capabilities of the STIM are, the controller then enables the selection boxes that Application of Plug-and-Play Distributed 17

22 represent the transducers described by the description. The traffic controller software also includes a demonstration mode that operates the demonstration intersection. The demonstration system is programmed essentially as an actuated single ring controller with pedestrian indications to function as follows: 1. The intersection initially has red balls in four directions and wait signs for all pedestrian crossings. 2. The steady state mode of operation displays green balls, red left-arrows, red pedestrian wait lights, and pedestrian timers displaying 0 for sections one and two. Sections three and four have red balls, green pedestrian walk lights, and blank pedestrian timers. The vehicle detectors for sections three and four and the pedestrian call buttons for one and two are active. 3. When a pedestrian button in section one or two is pushed or a vehicle is detected in section three or four, a new phase begins. The pedestrian timers in sections three and four begin to count down from nine to zero, at which time the walk light changes to a wait light. Approximately five seconds after the countdown begins, the traffic signals for section one and two display yellow balls and red left-arrows, and after a few seconds they display red balls. After a one second all-hold period, the section one and two pedestrians have ten seconds to cross, and the section three and four vehicles have ten seconds to drive after which the intersection cycles back to the steady state mode. Time Performance One consideration in determining the suitability of this technology is to examine the amount of bandwidth required to meet the specifications set by the ATC standard. The type 2070 controller uses SDLC communications operating at kbps (8). The ATC standard also specifies that all outputs will be asserted within a 100 µs window. Inputs are to be sampled 1000 times per second ± 100 µs. For the basis of comparison, we use the command output (message type 55) that is capable of setting nine outputs with three eight-bit bytes with the maximum specified message time is 410 µs. Application of Plug-and-Play Distributed 18

23 The IEEE 1451 NCAP and STIM processors use a 29 MHz 8-bit microcontroller. The NCAP uses a 10base T 10 Mbps Ethernet controller (IEEE 802.3), in part to match the speed of the 14 MB broad band power line carrier (BPL) used for some tests in lieu of an Ethernet hub and CAT 5 cable. Measurements on the network show that it requires approximately 930 µs of processing time and 3.5 µs for each data byte as expressed by Eq. 1. send _ time = (3.5 numberof packetbytes+ 930) µ s (1) The time to send an 88-byte packet used in this demonstration is ms resulting in a minimum of ms disparity for each signal that is required to change. Hence for an intersection consisting of five traffic signal heads and four pedestrian signals, the minimum amount of signal disparity is the number of signals minus one times the send time calculated by Eq. 1. For this example, the disparity from the first signal to the last is 9.9 ms. Clearly this does not meet the ATC specifications and is a topic for future research. Since the ATC standard does not specify the input signal persistence, we assume that all inputs will be asserted for at least one millisecond to correspond to the 1000 Hz sampling requirement. This requirement is met using STIM processors with interrupt capability. Timing measurements on the IEEE 1451 demonstration system show that 20 ms are required to communicate the new status to the NCAP. Future Research Our continuing investigation focuses on two critical issues that impede the application of PNP technology in traffic controls. The first critical issue is the safe-fail operation of a distributed control environment. This research includes but is not limited to conflict monitoring and malfunction management. Some initial considerations we are considering are redundant parallel systems that include power, networks, NCAP and STIM processors. Since each signal will be equipped with processing capability, temporal conflicts due to network timing may be resolved by using advanced state timing where signals are told to transition to Application of Plug-and-Play Distributed 19

24 a new state at a specific time in the future. This will require processors to be operating on the same time reference. The second area of research is the integration of the PnP DSN into existing ATC traffic controller schemes as a replacement for the signals wires as illustrated in Figure 7. This includes using Ethernet over BPL that has already been proven by the current research project to be effective and economical. BPL devices that operate at 14 Mbps are commercially available and cost less than $50 per unit. The advantage of BPL devices is that existing signal wires can be used for power and Ethernet communications. Computer ATC Controller Cabinet Traffic Management System EIA 485 Serial Bus 2 Serial Bus 1 SIU SIU AMU AMU CMU Serial Bus 3 Power Distribution Assembly Input Files Output Files Existing Loop Detectors Existing Signals Heads Translation Module NCAP Power Line Carrier Network NCAP Demonstration PnP System Adaptive Signal Controller STIM Adaptive Signal FIGURE 7 Proposed Integration of PnP DSN Technology into Existing Traffic Controllers Application of Plug-and-Play Distributed 20

25 CONCLUSION PnP DSN traffic signals can support dynamic signaling to facilitate temporal requirements for traffic control, thus providing better real-time traffic control that can result in safer and faster traffic flow. The PnP DSN technology base on the IEEE 1451 standard can reduce installation and maintenance costs. Electronic descriptions in the smart transducer modules provided by the smart transducers simplify signal and sensor replacement and or upgrades. Network communications minimize the number of wires required between the traffic controller and signals or sensors. A distributed environment can eliminate the need for load switches, thus significantly reducing the size of the traffic controller cabinet or eliminate it altogether. Although the system overall speed was less than originally hoped for using low cost microprocessors, the desired performance is still obtainable with faster hardware and / or software. The experienced with this investigation identified focus areas for future research. Application of Plug-and-Play Distributed 21

26 REFERENCES (1) National Electrical Manufacturers Association, Standards Publication No. TS 1, Washington, DC, (2) National Electrical Manufacturers Association, Standards Publication No. TS 2, Washington, DC, (3) Advanced Transportation Control Standards, Joint Committee on Advanced Transportation Controller, Ver. 1.0, Oct. 11, 2002, pp (4) Bullock, D., C. Schwehm, and J. Broemmelsiek, Distributed Sensing and Control Technology for Intelligent Civil Infrastructure Systems, Microcomputers in Civil Engineering, No. 11 (1996) pp (5) Bullock, D., A. Harvey, and C. Messer, Deployment of Fiber-Optic Lane Use Identification Signs Using a Distributed Control Architecture, Computer-Aided Civil and Infrastructure Engineering, 14 (1999) pp (6) IEEE Standard , IEEE Standard for a Smart Transducer Interface for Sensors and Actuators Network Capable Processor (NCAP) Information Model, IEEE Standards Board, June (7) IEEE Standard , IEEE Standard for a Smart Transducer Interface for Sensors and Actuators Transducer to Microprocessor Communication Protocols and Transducer Electronic Data Sheet (TEDS) Format, IEEE Standards Board, September (8) Advanced Transportation Controller (ATC) Standard Specification for the Type 2070 Controller, Joint AASHTO / ITE / NEMA Standards Publication, V02.03, March 12, 2004, pp (9) Bullock, D. Implementation Vision for Distributed Control of Traffic Signal Subsystems, Transportation Research Record, #1554, TRB, National Research Council, Washington, DC, pp , (10) Manual on Uniform Traffic Control Devices, Federal Highway Administration, U.S. Department of Transportation, Washington, D.C., Application of Plug-and-Play Distributed 22