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