DeVoe and Wall Dynamic Objects for Smarter Pedestrian Control Submitted by Dustin DeVoe Electrical Engineering Student Department of Electrical and Computer Engineering University of Idaho PO 441023 Moscow, ID 83843-1023 devo0710@vandals.uidaho.edu Richard W. Wall, P.E. Professor National Institute for Advanced Transportation Technology Department of Electrical and Computer Engineering PO 441023 University of Idaho Moscow, ID 83843-1023 208.885.7226 rwall@uidaho.edu Word count: Number of figures: Number of tables: Total word count: 4990 8 (2000 words) 1 (250 words) 7240 Submitted for presentation at the 87th Annual Meeting of the Transportation Research Board, January 13-17, 2008 and for publication in Transportation Research Record, the Journal of the Transportation Research Board. DeVoe and Wall Abstract: Traffic controllers contain real-time information that can be used for making countdown pedestrian signal operation safer and more accurate. This paper describes a system that uses low cost microcontrollers with Ethernet capability to extract real-time timer and status data from a NEMA TS2 Type-2 controller using UDP datagrams of NTCIP objects. A description of how the MIB objects are generated includes a sequence of instructions needed to communicate the controls. The operations of a TS2 traffic controller are analyzed based upon network loading and traffic controller response time. DeVoe and Wall INTRODUCTION The fundamental means for controlling traffic signal lights is and has been since its inception over 60 years ago to have dedicated wires for controlling signal lights and detecting vehicles and pedestrians in a binary fashion.[1] In 2006, we presented a networked architecture for controlling traffic signal lights based on the IEEE 1451 architecture that results in the ability to exchange more complex information than simple binary states of indication and detection. [2,3] The IEEE 1451 smart signal standard was initially chosen because it supported plug and play capability thus potentially simplifying intersection signal installations and upgrades. A path to integration was presented in 2007 that demonstrated how the IEEE 1451 based signals and detectors can be integrated with modern TS2 controllers.[4] Since the networked signals and detectors now contain innate intelligence, we refer to the system as “smart signals” The purpose of this paper is to describe how NTCIP dynamic objects can be generated in the TS2 controller to extract control and state information for operations of the traffic system. Ideally the data needed from the traffic controller would be generated using simple network management (SNMP) object traps that automatically send the data out over the Ethernet port. However, since this feature was not available in the TS2 controller we used, the management information base (MIB) objects were requested on regular time intervals by the smart signals controller. This paper is meant to serve as a guide for others who would have like needs for information contained in the traffic controller. The MIB data can be requested by a particular device for a single purpose or rebroadcasted to a network of devices. SNMP can also be used to modify traffic controller operations thus reconfiguring controller timing and registering requests for service. BACKGROUND The concept of “Smart signals” uses distributed processing concepts for controlling signals and acquiring service requests from pedestrian buttons, vehicle loop detectors, and special service sensors. The information between the smart devices and the traffic controllers communicated between devices that correspond using internet network technology. This is in contrast to conventional methods used for traffic control were signals and sensors used dedicated wires routed from the controller cabinet. The goal of this new approach was to lower construction cost by reducing the number of wires that are required for signalized intersections and permit for new devices by allowing increased complexity of information exchanged between the controller and the signals or detectors. System Architecture Derived from comments from practitioners and reviewers, we have moved our focus to communicating National Transportation Communications for ITS Protocol (NTCIP) for communications between the smart signal devices and the TS2 traffic controller. The architecture the NTCIP based smart signals system shown in FIGURE 1 includes a system safety critical monitor that implements the malfunction management unit (MMU) functions for the networked devices. The performance monitor is for development and testing to verify signal timing and display correctness. The discussion of the operations of these devices is topics for future papers. For the implementation using dynamic user data gram (UDP) objects, a smart signals controller shown in FIGURE 1 sends a single byte packet to the TS2 controller to cause the controller respond with the dynamic object data. The smart signals controller then rebroadcasts this packet to all smart signal devices. 1 DeVoe and Wall Smart Signals Network Architecture WAN Maintenance Laptop Smart Ped Signal Smart Ped Signal Smart Ped Signal Ethernet over Power Line Wire Ethernet Ped Smart Signal Controller Smart Ped Signal SafetyCritical Monitor System Performance Monitor New Traffic Cabinet Hardware TS1 Traffic Controller Cabinet Conventional Traffic Cabinet Hardware Existing Signal Hardware Load Switch MMU/ Conflict Monitor FIGURE 1 TS2 traffic controller integration with smart signal devices Software Architecture National Transportation Communications for ITS Protocol (NTCIP) In the past, each manufacturer of microprocessor based traffic control devices and software either developed or adopted a different, proprietary protocol for data communications. This required extensive integration projects to incorporate different systems from different manufacturers and to communicate between systems operated by adjacent agencies. NTCIP provides common standards for protocols that can be used by all manufacturers and system developers to help ease control network assimilation. A communications protocol defines a set of rules for messaging and how to encode the data contained in those messages for transmission between electronic devices. A protocol is not much different than a human language in that letters of the alphabet or characters represent bits of data and a word is similar to an encoded set of data. The NTCIP establishes the rules that allow bytes, characters, and strings to be organized into messages that are understandable by other NTCIP compliant devices. NTCIP is a family of communications standards for transmitting data and messages between microcomputer controlled devices used in Intelligent Transportation Systems (ITS). An example of such a system is a computer at traffic control center monitoring and controlling the operation of microprocessorbased roadside controllers at signalized intersections. The computer may send instructions to the traffic signal controllers to change signal timings as traffic conditions change and the intersection controllers send status and traffic flow information to the computer.[5] Basics of Simple Network Management Protocol Since the initial development in 1988, the Simple Network Management protocol has developed into the de facto standard for internetwork management. NTCIP recognized the wide use of SNMP and adopted the protocol as a communication standard for use in the ITS industry due to the flexibility it 2 DeVoe and Wall provides management stations to define their own message content and the simplicity of the protocol. Even though there were concerns about the large amount of encoding overhead, it was decided that the protocol provided a core set of functionality and that companion protocols could be developed to reduce these large overhead issues. SNMP is typically applied to managing network devices. Network management systems contain two primary elements: a manager and agents. The manager represents the traffic controller in NTCIP. Agents can be a transit management center, a dynamic message sign along a roadway, a simple personal computer, or a microprocessor in the hands of an engineer. Henceforth we will refer to the manager as the traffic controller since it serves that function in our system. Contained within the traffic controller are managed objects, or variables, that contain parameters that directly relate to the current operation of the intersection. These objects are arranged in a virtual information database, called a management information base, or MIB. SNMP allows managers to communicate their MIB to agents for the purpose of accessing these objects. In the Manager/Agent paradigm for network management, managed network objects must be logically accessible. Logical accessibility means that management information must be stored somewhere and therefore, that information must be retrievable and modifiable. SNMP actually provides the means for retrieval and modification by using a get-set paradigm to exchange individual pieces of data. Each piece of data stored within a device that is accessible via the SNMP protocol is called an object. Objects are organized hierarchically within the MIB as per the rules set in the Structure of Management Information (SMI) protocol. The SMI organizes, names, and describes information so that logical access can occur. The SMI states that each managed object must have a name, syntax, and an encoding. The name, an object identifier (OID), uniquely identifies the object. The syntax defines the data type, such as an integer or a string of octets. The encoding describes how the information associated with the managed objects is serialized for transmission between machines. The syntax used for SNMP is the Abstract Syntax Notation One, (ASN.1).[6] The encoding used for SNMP is the Basic Encoding Rules, BER. Definition of the MIB conforms to the SMI given in RFC 1155. The Latest Internet MIB is given in RFC 1213 sometimes called the MIB-II. [7] Traffic controller manufacturers compile their MIB using standardized tools, for example Wind River's WindManage MIB Compiler. NTCIP standards 1201 and 1202 contain definitions of standardized objects using ASN.1 notation. [8,9] Proprietary objects must be defined by the manufacturer, but are still defined and compiled in the same standardized manner. The successful completion of a MIB compilation results in generating a text file, which provides links to the OIDs of all addressable objects, contained within the traffic controller. The text file will be referred to as “OidNamesOut.txt” in this report, as such a file was provided by Econolite Control Products Inc. Each OID is written as a sequence of decimal digits separated by periods. This sequence is generally around 17 bytes long when encoded. An object instance is identified by appending the instance number to this base object identifier. Thus, each instance of data within the device has a unique number associated with it. SNMP is based on the manager/agent model. SNMP is referred to as "simple" because the agent requires minimal software. Most of the processing power and the data storage reside on the management system, while a complementary subset of those functions resides in the managed system. SNMP includes a limited set of management commands and responses. The management system issues Get, GetNext, and Set messages to retrieve single or multiple object variables or to establish the value of a single variable. The traffic controller sends a response message to complete the Get, GetNext or Set. It is also possible that the traffic controller provide an unsolicited SNMP message driven by an internal event known as a trap. Simple Transportation Management Protocol (STMP) and Dynamic Objects The NTCIP committee developed the STMP application layer protocol for reduced bandwidth applications. STMP uses a similar get/set paradigm to that of SNMP without the overhead of object identifiers and error codes. The content of every data packet requires each protocol entity to have prior 3 DeVoe and Wall knowledge of the configuration of that message. Every message is built from a user defined structure of variables known as a dynamic object. The process of building a dynamic object is a runtime operation that requires SNMP and a list of object identifiers included in the MIB. NTCIP dictates that up to 13 dynamic objects can be defined within the traffic controlling device. [10] MATERIALS AND METHODS Hardware To the extent possible, the hardware used for this investigation is based upon standard industry products to meet MUTCD requirements and is organized as shown in FIGURE 1. Equipment inside the traffic controller cabinet includes the traffic controller, a smart signals controller, a safety critical monitor, a system performance monitor, and an Ethernet router. We used an Econolite model ASC3-2100 that is a NEMA TS2 Type 2 traffic controller.[11] This controller was modified by the manufacturer in support of this research to provide a custom NTCIP MIB object for accessing the pedestrian timing and will be discussed later in this paper. The two monitors and the smart signals controller are proprietary microcontroller units that use a Rabbit Semiconductor RCM 3000 series microprocessor with a 10 Mbps Ethernet controller.[12] The operations of two monitor units used for safe-fail operations and system testing are beyond the scope of this paper. A router is needed to communicate with the ASC 3 traffic controller to initiate data retrieval and setting controller objects. The controller also broadcasts the controller object data to all smart signals devices. For our work, we use a Linksys WRT 54G [13] router that connects the networked devices inside the traffic controller cabinet with the Ethernet over power line network for accessing the pedestrian signals. Equipment outside the cabinet consists of four Econolite 12 inch polycarbonate pedestrian signals[14] that were customized as shown in FIGURE 2 to interface with the smart signals network using Netgear HDX101 200 Mbps Ethernet over Power line adaptors.[15] The proprietary controller is based upon a Rabbit Semiconductor RCM 3000 series microprocessor with 10 Mbps Ethernet controller. The pedestrian button uses the Campbell Company DCC H Frame with the 4 EVR 120 piezo electric pressure button for the mechanical design.[16] Custom electronics based upon the Cypress PSoC CY8C29443 processor [17] uses conventional bi-direction asynchronous communications between the pedestrian button and the pedestrian signal controller. 120 VAC - 60 hz Power Bus AC Power Supply 18 VDC EoPL Modem CAT 5 Proprietary Controller WAIT WALK Push Button FIGURE 2 Pedestrian signal and button modified for smart signals operation 4 DeVoe and Wall Communications User Datagram Protocol (UDP) For this project we choose the UDP/IP Internet Transport Profile for system communications, as defined in NTCIP 2022. This incorporates placing the data stream into an UDP datagram and then placing the UDP datagram into an IP packet. The standard is not specific to dynamic objects or SNMP. FIGURE 3 illustrates examples of the data that makes up both SNMP and STMP type packets within the UDP/IP transport profile as captured by a standard network sniffer such as Wire Shark. The quad octet IP address, for example 192.168.1.5, defines the location of a device on a network, similar to a street address. Because message arbitration could clutter network communication lines given only one communication channel, the Internet protocol standard provides up to 65535 channels, known as ports, for devices to communicate [17]. You can imagine these ports to behave much like roadways providing multiple routes of access to a street address. For example, most webpage’s use port 80 for transmission to an internet browser. For STMP communications, the NTCIP standard specifies that all communications be directed on port 501. Whereas SNMP typically uses port 161, it is possible to use other open ports. For illustrations of this refer back to FIGURE 3 taking notice of the source and destination port for each type of message. In reference to the highlighted regions contained in the network datagram captures of FIGURE 3, the size difference between SNMP and STMP protocols becomes evident. The size of our single OID SNMP get-request is 42 bytes, while in comparison the STMP message contains just one byte and requests five objects. The SNMP get-response for a single OID is 43 bytes and the STMP is seven bytes because one of the five objects is an integer. 5 DeVoe and Wall FIGURE 3: Network Captures of SNMP and STMP Packets The flow graph seen in FIGURE 4 demonstrates the communications for the dynamic object data within the smart pedestrian signal network. The device initiating the dynamic object request is IP address 192.168.1.101 and the traffic controller is 192.168.1.5. Once the response is receive by the device initiating the request, it is rebroadcast to all nodes on that network using IP address 255.255.255.255 on a new unique port where the pedestrian devices are listening. The broadcast port for the data is arbitrary, it is however critical that the pedestrian devices are listening to that port. FIGURE 4: Flow Graph for Dynamic Objects in Smart Signal Network The Packet Selection The formation of the dynamic object for this project is critical to the service capabilities of the smart pedestrian signals. Currently the devices provide the intersection with pedestrian phase states, realtime accurate countdown timing, and a call for service worst-case countdown for pedestrian crossing 6 DeVoe and Wall requests. The following objects listed in TABLE 1, were selected from NTCIP 1202 along with a custom object developed by Econolite for the ASC3. TABLE 1 ASC3 custom object list. Object Name Description CustomPedTimer * phaseStatusGroupPedCalls phaseStatusGroupPedClears phaseStatusGroupWalks phaseStatusGroupVehCalls phaseStatusGroupPhaseNexts phaseWalk phasePedestrianClear phaseMaximum1 phaseYellowChange phaseOptions In tenth of seconds for any phase in walk or ped clear Ones hot for phase with initiated PedCall Ones hot for phase in pedestrian clear status Ones hot for phase in pedestrian walk status Ones hot for phase with vehicle detector call Ones hot for phase to be called next after completion of current Phase walk duration in seconds (8 phases) Phase flashing hand duration in seconds (8 phases) Phase Maximum Duration (8 phases) Transition timing between phase changes (8 phases) Contains flags that define phase operation (8 phases) *Custom Object developed by Econolite NTCIP objects are organized into two groups. In all, the dynamic object that we are generating is comprised of 46 different objects. Some objects are polled for all of group 1 or eight phases. We selected eight phases as a first step because most implementations will only require group 1 objects. Future development will employ both group 1 and 2. Employing Dynamic Objects Configuring a Dynamic Object: The following SNMP commands must be sent to the controller by the client to create a dynamic object. 1. 2. 3. 4. 5. Set(int) dynObjectConfigStatus invalid(3) Set(int) dynamaicObjectConfigStatus underCreation(2) Set(string) dynObjectConfigOwwner “SmartPed” Set(OID) dynObjectVariable Object Identifier Set(int) dynObjectConfigStatus Valid(1) It is assumed that the reader is familiar with the process involved in SNMP messaging. The diagram uses the term “Set” as an abbreviation for an SNMP Set operation followed by the variable type in square brackets which is to be used in the formation of the SNMP PDU (Packet Data Unit). The normal text represents the object name. The object has a corresponding object identifier which can be found in the OidMibOut.txt file provided by your traffic controller manufacturer upon compilation of their MIB. Items in parenthesis represent the actual value instead of the preceding state as defined in the NTCIP standard. Because this is an important concept to grasp we included some generic C code in Listing 1 to put into practice the generation of dynamic object number 4, which in this case will include 3 objects. The code does not demonstrate how SNMP packets are formed, but similar functions can be commonly found in freely available SNMP libraries. Listing 1. Generic C Code for FIGURE 2 #define dynObjectConfigStatus “1.3.6.1.4.1.1206.4.1.3.3.1.1.2” //Integer type #define dynObjConfigOwner “1.3.6.1.4.1.1206.4.1.3.3.1.1.1” //String type #define dynObjectVariable “1.3.6.1.4.1.1206.4.1.3.1.1.3” //OID String type 7 DeVoe and Wall #define INVALID 3 #define UNDERCREATION 2 #define VALID 1 #define DYNAMIC_OBJECT_NUM 4 // The following array makes up the variables to be defined in the // dynamic object for group 1 const char* OIDS_FOR_DYN_OBJ[] {“1.3.6.1.4.1.1206.4.2.1.1.5.1.7.1”, // phaseStatusGroupPedCalls “1.3.6.1.4.1.1206.4.2.1.1.4.1.6.1”, //phaseStatusGroupPedClears “1.3.6.1.4.1.1206.4.2.1.1.4.1.7.1”}; // phaseStatusGroupWalks Void main() { SetDynObjInvalid(); SetDynObjConfigMode(); SetDynObjOwner(); SetDynObjVariables(); } Void SetDynObjInvalid() { // Setup SNMP message CreateSNMPMsg(dynObjectConfigStatus, tempSNMP); // Add identifier of 4 for dynamic object number 4 AppendSNMP(DYNAMIC_OBJECT_NUM, tempSNMP); // Add value of to SNMP msg to clear previous values AppendSNMP(INVALID, tempSNMP); //Send Msg SendSNMP(tempSNMP); return; } Void SetDynObjConfigMode() { // Setup SNMP message CreateSNMPMsg(dynObjectConfigStatus, tempSNMP); // Add identifier of 4 for dynamic object number 4 AppendSNMP(DYNAMIC_OBJECT_NUM, tempSNMP); // Add value of to SNMP msg to set to configuration mode AppendSNMP(UNDERCREATION, tempSNMP); //Send Msg SendSNMP(tempSNMP); return; } Void SetDynObjOwner() { // Setup SNMP message CreateSNMPMsg(dynObjConfigOwner, tempSNMP); // Add identifier of 4 for dynamic object number 4 AppendSNMP(DYNAMIC_OBJECT_NUM, tempSNMP); // Add owner of dynamic object as “SmartPed” AppendSNMP(“SmartPed”, tempSNMP); //Send Msg SendSNMP(tempSNMP); return; } Void SetDynObjVariables() { for( int num = 1; num <= OID_NUM; num++) { // Setup SNMP message CreateSNMPMsg(dynObjectVariable, tempSNMP); // Add identifier of 4 for dynamic object number 4 AppendSNMP(DYNAMIC_OBJECT_NUM, tempSNMP); 8 DeVoe and Wall // Add identifier for which dynamic object variable (num) starting with 1 up to # // of OIDs AppendSNMP(num, tempSNMP); // Add value of to SNMP msg to clear previous values AppendSNMP(OIDS_FOR_DYN_OBJ[num], tempSNMP); //Send Msg SendSNMP(tempSNMP); } //end for loop once Number of OIDs has been reached return; } Retrieving a Dynamic Object A device can retrieve a dynamic object by sending one byte of data within a UDP message. Transportation management protocol defines all dynamic object get requests to comprise of the hexadecimal value 0x80 masked with the number of the dynamic object. [18] See the highlighted section contained in the network capture of a STMP request in FIGURE 5a. The data preceding the STMP get request is constructs for IP and UDP overhead. The “0x81” stmp-get for dynamic object #1 command will cause the traffic controller to generate an STMP-GetResponse-PDU shown in FIGURE 5b. (a) (b) FIGURE 5 Network datagram capture of (a) Dynamic Object Get Request and (b) Dynamic Object Get Response The data fields are decoded as follows: first the response header C1 stmp-get-response for dynamic object #1 This is follower by the information field of: 14 variable 1 = phasePedestrianClear.2 (phase 2)= 20 seconds for flashing hand 02 variable 2 = phaseStatusGroupPedCalls.1 (group 1) = Call on Phase 2 00 12 variable 3 = CustomPedTimer.1 = 1.8 seconds for walk countdown 02 variable 4 = phaseStatusGroupPedClears.1 (group 1) = Phase 2 has flashing hand 00 variable 5 = phaseStatusGroupWalks.1 (group 1) = No phase is in walk Following the message in FIGURE 5b is 11 bytes of unusable data. This is not common and can be attributed to the older custom firmware installed on our traffic controller. Because the UDP header information does not define this as data, it should be excluded when decoded. We assume the error relates to the minimum UDP message size defined within the traffic controller software. 9 DeVoe and Wall RESULTS AND ANALYSIS Message Timing: SNMP NTCIP 1103 defines an SNMP request as timed-out if from the time a request is received and responded to exceeds 100ms plus 1ms for each byte contained in the variable-binding field (OID and data), unless otherwise specified by a communication standard. We will use this reference as we look at SNMP responses from the ASC3 traffic controller. The timing test results shown in FIGURE 6 were generated by polling the traffic controller with two separate SNMP requests every 200ms. One message contained two OIDs with a variable-binding of 44 bytes. The second message included three OIDs with a variable-binding of 67ms. We should expect the peak response time to be less than 167ms. Statical analysis of the controller response data of FIGURE 6 shows that the average is 7.032ms, the peak is 170.7ms and the minimum is 0.852ms. FIGURE 6 Response Time for Traffic Controller SNMP GetResponse Message Timing: STMP NTCIP 1103 defines an STMP request as timed-out if from the time a request is received and responded to exceeds 100ms plus 1ms for each byte contained in the variable-binding field (STMP header plus data), unless otherwise specified by a communication standard. We will use this reference as we look at SNMP responses from the ASC3 traffic controller. The timing test results shown in FIGURE 8, were generated by polling the traffic controller with a dynamic object every 225ms. The dynamic object was constructed to the peak response time to be less than 157ms. Statical analysis of the controller response data of FIGURE 7 shows that the average is 1.86ms, the peak is 12.085ms and the minimum is 1.162ms. 10 DeVoe and Wall FIGURE 7 Dynamic Object Request at a Rate of 225ms A 200ms interval was also tested requesting the same dynamic object. The results, shown in FIGURE 8, illustrate a linear escallation in response delay approaching the 157ms timeout barrier. Further testing was conducted by polling the traffic controller overnight and capturing the a small sample period the next day. Statical analysis of the controller response data of FIGURE 8 shows that the average is 56.79ms, the peak is 132.1ms and the minimum is 0.413ms. FIGURE 8 Dynamic Object Request at a Rate of 200ms 11 DeVoe and Wall Advantages and Disadvantages of STMP When comparing the timing and object information, using dynamic objects has significant advantages. The reduced processing for protocol overhead was evident when comparing FIGURE 7 and 8. The SNMP protocol overhead seemed to cause erratic response delays within the traffic controller. In a time critical environment, such as our smart pedestrian signals, SNMP would need to provide a more consistent reply. In addition, the average response generated for all 46 objects contained within STMP took 5.172ms less time than the three objects within SNMP. STMP proved to be a much more efficient means for extracting our specified pedestrian information from the traffic controller. The disadvantages of dynamic objects are few, but message integrity and abnormal timing shall be considered. Part of the intial testing of dynamic objects yielded inconsistent data because of a lack of knowledge for the obects contained in the STMP response. The receiving agent must have prior knowledge of the object size because it is not encoded within the message. Response delay was also an issue. The abnormal behavior of the traffic controller at a 200ms polling period was reason for concern. It can be concluded from the results seen in FIGURE 8 that instances where a dynamic object is polled at period less than 225ms for an extended period of time will result in an increasing response delay. Future Work Through out our development of smart signals concepts, we seriously consider feedback from a diverse group of traffic industry practitioners. In a effort to resolve ther concerns we have identified the following topic for further research. Time Sync Integration – In the configuration of this experiment, all signal nodes provided no transaction determinism with the use of UDP. Research is underway for using IEEE 1588 Time Sync Protocol to reduce non-determinism, packet collisions, and coordinate transitions by using a common synchronized clock. TDMA, or time division multiple access, is applied to provide each node with a specified time slot to communicate with the master coordinating device. Because the coordinating device can determine which devices are synchronized, it then acts as a distributed control malfunction management unit. MMU Managed communications o Runtime reconfiguration – Currently relies on static dynamic object. In the future iterations it would be useful to have a configuration webpage that allows for additional configuration of dynamic objects and the managed nodes. o Intersection fault modes – It may be necessary for the device to fail to specific modes, possibly putting the intersection in flash or passing remote communications to an alternate signal on the same phase. Alternate Traffic Controllers – Although this experiment works well with the Econolite ASC3, in order to achieve industry adaptation, the system should be tested on other (Ethernet enabled) TS2 type traffic controllers that conform to NTCIP standards. Traps - The NTCIP draft standard 1103 v2.01b is the first to include traps for STMP. Traps would be useful for only updating signals when parameters vital for pedestrian control (change or transition) within the traffic controller. Traps have been established to allow a managed device to preemptively transmit a message (transmit an unsolicited message) to a management station based on a monitored change of state within the managed device. 12 DeVoe and Wall CONCLUSION This is an efficient method for distributing signal control information to pedestrian traffic signals. Low end microprocessor based devices are readily able to communicate using NTCIP. Both SNMP and STMP objects were investigated and we believe this method will drastically improve the service for the widest variety of users, who to this point have been neglected. STMP has definite performance advantages over SNMP for managing real-time control. It is apparent form testing the ASC 3 controller than there are limitations on how frequently dynamic objects can be requested. It is our belief that such limitations would not be experienced if SNMP or STMP traps are used. ACKNOWLEDGMENT Funding provided to the National Institute of Advanced Transportation Technology (NIATT) by the U. S. Department of Transportation, Research and Innovative Technology Administration, Grant No. DTRS98-G-0027. Equipment and engineering support was provided by Econolite Control Products, Inc. 3360 East La Palma Ave. Anaheim, CA, 92806 and Campbell Company, 221 W 37th St., Ste. C, Boise, ID, 83704. REFERENCES 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Sessions, Gordon M. (1971). Traffic devices: historical aspects thereof. Washington: Institute of Traffic Engineers, 27-28. Wall, R.W. and A. Huska*, “Design Platform for Plug-and-Play IEEE 1451 Traffic Signal,” The 31st Annual IEEE Industrial Electronics Conference, Raleigh, NC, Nov 6-10, 2005, Paper No. RD-001973. Wall , R.W., A. Huska*, and D. Bullock, “Application of Plug and Play Distributed Signal Technology to Traffic Signals,” Transportation Research Board 2006 Annual Meeting, Washington D.C., January 22-26, 2006, Paper No. 06-2728. Wall, R.W., T. Urbanik, D. Bullock, S. Allen*, M. Busby*, D. DeVoe*, A. Huska*, T. Rallens* “Distributed Traffic Signal Control: Improving Pedestrian Control as A First Step”, Transportation Research Board 2007 Annual Meeting, Washington D.C. January 21-25, 2007, Paper No. 07-0989. NTCIP 9001: The NTCIP Guide version 3.02b. Washington, D.C.: ASSHTO / ITE / NEMA, 2002. ASN.1 – Communications between Heterogeneous systems, Olivier Dubuisson, Morgan Kaufman Publishers, September 2000, ISBN 0-12-6333361-0. Available in electronic form at http://www.oss.com/asn1/dubuisson.html. Accessed last on 7/31/2007. Cisco Systems, Inc. Simple Network Management Protocol. 12 October 2006. 20 7 2007 http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/snmp.htm#wp1020557. Last accesses on 7/31/2007. NTCIP 1202: Object Definitions for Actuated Traffic Signal Controller Units (ASC) version 1.07b. Washington, D.C.: AASHTO / ITE / NEMA, 2005 NTCIP 2022: Internet (TCP/IP and UDP/IP) Transport Profile version 1.05. Washington, D.C.: AASHTO / ITE / NEMA, 2001 NTCIP 1103: Transportation Management Protocols (TMP) version 2.10b. Washington, D.C.: AASHTO / ITE / NEMA, 2006. Econolite Control Products, Inc. , 3365 East LaPalama, Anaheim, CA 92806-2856, http://www.econolite.com/pdf/controllers/asc3.pdf. Last accesses on 7/31/2007 Rabbit Semiconductor, 2900 Spafford Street Davis, California 95618-6809, http://www.rabbitsemiconductor.com/products/rcm3000/rcm3000.pdf. Last accessed 7/31/2007. Last accessed on 7/31/2007. Linksys 121 Theory Drive, Irvine, CA 92617 http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLayout&cid=1149562 300349&pagename=Linksys%2FCommon%2FVisitorWrapper. Last accessed on 7/31/2007. 13 DeVoe and Wall 14. Econolite Control Products, Inc. , 3365 East LaPalama, Anaheim, CA 92806-2856 http://www.econolite.com/docs/signals/signals_12inch_pedestrian_polycarbonate_data_sheet.pdf. Last accesses on 7/31/2007 15. Netgear Inc., 4500 Great America Parkway, Santa Clara, California 95054, http://www.netgear.com/Products/PowerlineNetworking/PowerlineEthernetAdapters/HDX101.aspx. Last accessed on 7/31/2007. 16. Campbell Company, PMB #331, 967 E. Park Center Blvd. Boise, ID, 83704 http://www.pedsafety.com/Piezo_Nonmoving.php. Last accessed on 7/31/2007. 17. Cypress MicroSystems, Inc., 2700 162 nd Street, Lynwood, WA. 98037, http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID =209&PageID=215&gid=13&fid=24&category=All . Last accessed on 7/31/2007. 18. Held, Gilbert, The ABCs of IP addressing. Boca Raton, FL: Auerbach Publications, 2002, ISBN 0-84931463-01 1 14