Network Capable Application Processor (NCAP) – the … · Web viewDefines an electrical interface, read and write logic functions to access the TEDS. 1997 1451.3 Defines a Transducer

Wall, Huska and Bullock 1/16

Application of Plug and Play Distributed Sensor Network Technology to Traffic Signals

Submitted by:

Dr. Richard W. Wall, P.E.Associate ProfessorNational Institute for Advanced Transportation TechnologyDepartment of Electrical and Computer EngineeringPO 441023University of IdahoMoscow, ID 83843-1023208.885.7226208.885.7579 (FAX)[email protected]

Andrew Huska, E.I.T.Graduate Research AssistantDepartment of Electrical and Computer EngineeringPO 441023University of IdahoMoscow, ID 83843-1023208.661.9242208.885.7579 (FAX)[email protected]

Darcy Bullock, P.E.ProfessorSchool of Civil EngineeringPurdue University550 Stadium Mall DriveWest Lafayette, IN [email protected]

Word count: 4693Number 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 sections describe a distributed plug-n-play vision based upon the IEEE1451 family of standard. Subsequent sections tabulate performance 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:

1. Introduce a process for defining an electronic description of the behavior of traffic signals and sensors.

2. Develop a working prototype to measure performance and demonstrate functionality and adaptive capability.

3. Determine the operating performance of Plug and Play (PnP) traffic signals and sensors implemented as a distributed network.

Assumptions:


1. Network communications will be provided by CAT5 Ethernet cables or Ethernet over broadband power line carrier (BPL).

2. Technicians will be adequately trained and have the appropriate tools to properly maintain the controllers.

3. 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 an issue. 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 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.


TABLE 1 Definitions of IEEE 1451 Subparts

Subpart Description Date of Adoption

P1451.0 Defines basic IEEE 1451 structure, data protocols, and formats. Proposed1451.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

FIGURE 2 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 ModuleA 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 InterfaceThe 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 SheetA 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 Table 2 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. Table 3 shows an example Channel TEDS definition.

TABLE 2 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.

TABLE 3 Example ChannelTEDS Definition of a Pedestrian Countdown Indicator

Field Abbreviated Name Value Comments1 ChannelTEDS Len Will be calculated by program2 Calibration Key CAL_NONE No calibration information needed or provided3 Calib TEDS Ext Key 0 No calibration extension implemented in STIM4 Data Fields Ext Key 0 No data field extension implemented in STIM5 Industry TEDS Ext 0 No TEDS extension implemented in STIM6 EndUsersAppTEDS 0 No End Users Application Specific TEDS for

channel7 Writeable TEDS Len 0 There are no writable TEDS areas for this chan8 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 Lower Range Limit 0 Zero is the minimum number of seconds11 Upper Range Limit 255 255 seconds is the maximum12 Data Max Uncertainty 0 In the same physical units of the data13 Self-test Key 0 No self-test function needed or provided14 Channel Data Model 0 n-byte integer15 Chan Data Model Len 1 1 byte long data16 Data Model Sgnf Bits 8 All 8 bits of the byte are needed17 Chan Data Repetitions 0 No data repetitions18 Series Origin NaN (not a number) Not defined because data repetitions = 019 Series Increment NaN Not defined because data repetitions = 020 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 ack22 Write Setup Time 0.001 Max seconds between write frame and trigger23 Read Setup Time 0.001 Max seconds between read frame and trigger24 Sample Period 0.001 Min seconds between trigger and read frame25 Warm-up Time 0.001 Max seconds to stabilize after power up26 Total Hold-off Time 0.010 Max time STIM will hold off a serial transfer27 Timing Correction 0.001 Offset in seconds trigger ack and actual

sample/update28 Trigger Accuracy 0.001 Accuracy in seconds of timing correction29 Event Seq Options 0 Not applicable30 TEDS Checksum Will be calculated by program

DEMONSTRATION SYSTEM

Demonstration IntersectionA circuit board was developed that represents a four-approach intersection. Each approach has a three-color traffic signal (Figure 4a), a vehicle detector (Figure 4b), pedestrian walk/wait signs on both sides of the approach (Figure 4c), pedestrian call buttons on both sides (Figure 4d), and pedestrian countdown timers on both sides (Figure 4e). The model created represents the actual traffic control configuration shown in Figure 5.


FIGURE 4 Demonstration System Signal Display Board


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 and its capabilities.

The PnP concept used here is very similar to the PnP used on all personal computers. 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 ControllerAn Ethernet-enabled PC is also connected to the hub and acts as the traffic controller. A basic plug-and-play traffic controller was written which provides the capabilities to connect to an NCAP 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. 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 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.

FIGURE 6 Screenshot of PnP Traffic Controller Software

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 614.4 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.

The IEEE 1451 NCAP and STIM processors use a 29 MHz 8-bit microcontroller. The NCAP uses a 10baseT 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.

(1)


The time to send an 88-byte packet used in this demonstration is 1.238 ms resulting in a minimum of 1.238 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.

Low cost hardware was originally chosen for use in the proof-of-concept for this project and was used for the remainder of the research due to availability. However, there are currently a number of devices available that could be used to increase usable network bandwidth by five to 100 times.

FUTURE RESEARCH

Our continuing investigation focuses on two critical issues that impede the application of this 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 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.


FIGURE 7 Proposed Integration of PnP DSN Technology into Existing Traffic Controllers

CONCLUSION

PnP DSN traffic signals can support dynamic signage to facilitate temporal requirements for traffic control, thus providing better real-time traffic control that can result in safer and faster traffic flow. 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 experience with this investigation identified focus areas for future research.

ACKNOWLEDGMENT

Funding provided by the United States of America Department of Transportation, Research and Special Programs Administration, Grant No. DTRS98-G-0027.

REFERENCES

1. National Electrical Manufacturers Association, Standards Publication No. TS 1, Washington, DC, 1989.


2. National Electrical Manufacturers Association, Standards Publication No. TS 2, Washington, DC, 1992.

3. Advanced Transportation Control Standards”, Joint Committee on Advanced Transportation Controller, Ver. 1.0, Oct. 11, 2002, pp. 6-7.

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. 77-86.

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.231-238.

6. IEEE Standard 1451.1-1999, “IEEE Standard for a Smart Transducer Interface for Sensors and Actuators – Network Capable Processor (NCAP) Information Model”, IEEE Standards Board, June 1999.

7. IEEE Standard 1451.2-1997, “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 1997.

8. “Advanced Transportation Controller (ATC) Standard Specification for the Type 2070 Controller", Joint AASHTO / ITE / NEMA Standards Publication, V02.03, March 12, 2004, pp 77-80.

9. 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.

10. Manual on Uniform Traffic Control Devices, Federal Highway Administration, U.S. Department of Transportation, Washington, D.C., 2003.

11. Handermann, Franz, "Fail-Safe, Fault-Tolerant", The Online Industral Ethernet Book, Issue 28, September 2005.

12. Short, Daniel, "Control Room Design with Redundant Ethernet", The Online Industrial Ethernet Book, Issue 28, September 2005.

13. Siemens Traffic Control, http://www.siemenstraffic.com/d/auth.rpl?m=cat&catid=2, Accessed October 20, 2005

14. Paul Haake, "Protecting Mission Critical Electronics", Maintenance Technology, http://www.mt-online.com/articles/05-01amt.cfm?pf=1, Accessed October 24, 2005.

Documents

Network Capable Application Processor (NCAP) – the … · Web viewDefines an electrical interface, read and write logic functions to access the TEDS. 1997 1451.3 Defines a Transducer