National Transportation Communications for ITS Protocol (NTCIP) GUIDE DRAFT

Transcription

1 National Transportation Communications for ITS Protocol (NTCIP) GUIDE Prepared by The NTCIP Joint Standards Committee DRAFT March 3, 1997

2 TABLE OF CONTENTS INTRODUCTION...I ABOUT THIS DOCUMENT... II CHAPTER 1: WHAT IS THE NTCIP?... 1 WHAT TRANSPORTATION MANAGEMENT SYSTEMS CAN USE THE NTCIP?... 1 HOW THE NTCIP WAS DEVELOPED... 2 CURRENT NTCIP ACTIVITIES AND HOW YOU CAN HELP... 3 OTHER SOURCES OF INFORMATION ABOUT THE NTCIP... 3 CHAPTER 2: HOW THE NTCIP MAY BE USED... 1 WHY THE NTCIP SHOULD BE SPECIFIED IN ALL PURCHASES... 1 Avoid Early Obsolescence... 1 Provide Choice of Vendor... 1 Provide Interjurisdictional Coordination... 2 Use One Communications Network for All Devices... 2 TYPES OF SYSTEMS SUPPORTED BY THE NTCIP... 2 Types of Devices Supported... 2 System Configurations Supported... 3 Types of Data Links Supported... 3 Types of Messaging Strategies Supported... 4 Signal System Functions Supported... 4 CHOOSING NTCIP OPTIONS... 5 Protocol Profiles... 5 Conformance Level... 6 Optional Objects... 6 Object Value Ranges... 6 Physical Interface... 7 Maximum Address... 7 Maximum Packet Size... 7 DESIGNING SYSTEMS WITH THE NTCIP... 7 Retrofitting Existing Systems with the NTCIP... 7 The NTCIP in New Systems... 8 Changes Over Time... 8 OTHER CONSIDERATIONS... 9 Competition, Proprietary Interests, and Confidentiality... 9 Agency-Specified Features Software and Hardware Implications of NTCIP Options Delivery Schedule HOW TO INCLUDE THE NTCIP IN PROCUREMENT SPECIFICATIONS Checklist of Items to Consider Sample Language for Procurement Specifications FREQUENTLY ASKED QUESTIONS CHAPTER 3 SUMMARY TECHNICAL DESCRIPTION... 1 ABOUT THIS CHAPTER... 1 THE NTCIP DATABASE... 1 ENCODING THE NTCIP DATABASE FOR TRANSMISSION... 6 THE NTCIP AND THE ISO SEVEN-LAYER MODEL... 8 The Application Layer - Using STMF... 8 The Presentation, Session, Transport, and Network Layers... 10

3 The Data Link Layer for Class B The Physical Layer CALIFORNIA ASSEMBLY BILL 3418 AND NTCIP CREATION OF NEW MIB MODULES AND ADDING OBJECTS TO DRAFT MIBS SUMMARY CHAPTER 4: SYSTEMS AND SOFTWARE DEVELOPERS GUIDE... 1 CENTRAL SYSTEM SOFTWARE IMPLEMENTATIONS... 2 Caltrans... 2 Washington State Department of Transportation... 3 FHWA... 3 NTCIP Exerciser... 3 SIGNAL CONTROLLER... 3 Caltrans... 3 FHWA... 4 VARIABLE MESSAGE SIGNS... 4 WSDOT... 4 FHWA... 4 OTHER DEVICES... 4 I-95 Corridor... 5 RECOMMENDED REFERENCES... 5 WORLD WIDE WEB... 5 NTCIP JOINT STANDARDS COMMITTEE... 5 CALTRANS... 6 NEMA TECHNICAL COMMITTEE... 6 ORGANIZATIONS PLANNING DEPLOYMENT OF NTCIP... 6 BOOKS AND OTHER SOURCES... 7 RFC DOCUMENTS... 7 COMMON DEVELOPMENT PITFALLS... 8 Protocol-Related Issues... 8 Bit and Byte Order... 8 Extended Addresses... 8 Maximum Duration Between Successive Bytes... 9 Response Time... 9 Control Byte... 9 Frame Handling CRC Algorithm Invalid Frame STMP Message Type Byte Length Values for Variable Message Fields Carriers Number of Devices on a Channel MIB ISSUES NTCIP BYTE STREAM EXAMPLES Introduction Definition of a Dynamic Object Formal Specification for Dynamic Objects Configuration of Dynamic Objects Dynamic Object Definition (dynobjdef) Examples Configuring a Dynamic Object...15 STMP Set Request from NEMA...18 STMP Set Response from NEMA...20 STMP Set Request from Root...20

4 STMP Set Response From Root...21 STMP Dynamic Object Get Request...21 Explanation of the Event Log...21 STMP Dynamic Object Get Response...23 STMP Dynamic Object Get-Next Request...23 STMP Dynamic Object Set Request-No Reply...24 STMP Dynamic Object Error Response...24 Other Nondynamic Examples STMP Get Request from NEMA...25 STMP Get Response from NEMA...26 STMP Get-Next Request from NEMA...26 Conclusion CHAPTER 5 PROCEDURES FOR MAINTAINING AND MODIFING THE STANDARD... 1 APPENDIX A ACRONYMS... 1 APPENDIX B - GLOSSARY... 6 APPENDIX C - RECOMMENDED ASC OBJECT RANGES... ERROR! BOOKMARK NOT DEFINED. APPENDIX D - ITE ARTICLE... 18

5 Introduction This document is a starting point for learning about the National Transportation Communications for ITS Protocol (NTCIP). This document is not a part of the NTCIP standard: it provides an overview and explanation of the NTCIP and guidance to those using the NTCIP. It is not necessary to first read the formal NTCIP standards documents, nor to have the standards documents as a reference. Information about the formal standards and other documents and sources of information related to the NTCIP are found later in this document. The NTCIP is a family of standard communications protocols used for data transmission within and between Intelligent Transportation Systems, (ITS). The standard covers both the "how" and "what" of data communications, that is, both the transmission rules and the format and meaning of standardized messages transmitted using those rules. Where possible, the NTCIP is based on existing standards in the telecommunications and computer industries. The NTCIP aims to do for transportation systems what the Internet has done for communications between generalpurpose computers: it will help enable interoperability and interchangeability between devices and between systems from different manufacturers. It can provide more choice, more flexibility, and the ability to coordinate the operation of adjacent devices and systems. The NTCIP family of protocols is continually expanding to address additional needs. The initial standard provides protocols for real-time communications between a master or computer and such field devices as traffic signal controllers, environmental sensor stations, dynamic message signs, highway advisory radio, closed - circuit television cameras, and freeway ramp meters. Work is under way on additional protocols for applications such as computer-to-computer or center-to-center data exchange, communications within transit management systems, and communications with and between moving vehicles. The NTCIP and related standards are intended to eventually provide a comprehensive family of communications protocols covering all ITS applications. ABOUT THIS DOCUMENT The document is divided into chapters, each of which deals with a different topic and is directed at a different audience. It is recommended that the reader review Chapter 1 first; then the reader should move directly to whichever chapter deals with the topic of interest. Each chapter stands alone it is not necessary to read preceding chapters. The chapters are as follows: Chapter 1 - What Is the NTCIP? This chapter is intended for all readers and provides a brief description of the NTCIP. Chapter 2 - How the NTCIP May Be Used. This chapter explains what devices and situations the initial NTCIP standard may be used for, the benefits of using it, and advice on how to write procurement specifications for systems incorporating the NTCIP standard. Chapter 2 is intended for people responsible for purchasing or specifying ITSrelated equipment and systems (e.g., transportation engineers in public agencies that own or operate ITS systems or who work as consultants for those agencies would benefit from reading this chapter). Chapter 3 - Summary Technical Description. This chapter is intended for engineers and technicians who want to understand how the NTCIP works without having to read all the detailed specifications that comprise the formal standards documents. It describes the structure of the NTCIP including the different classes of protocols, the different layers of the protocol stack, the message frame format, dynamic messages, the way in which devices and i

6 device specific messages are referenced using registered path names following the Internet's addressing structure, and how data elements are defined using Abstract Syntax Notation. It also contains answers to frequently asked questions concerning the technical details of the standard. Chapter 4 - System and Software Developers Guide. This chapter is intended for system and software developers responsible for implementing transportation management systems using the NTCIP. It contains "tips and traps" advice for software developers and sample source code. Chapter 5 - Procedures for Maintaining and Modifying the Standard. This chapter is not written at this time. The standard maintenance procedures are still in development. A supplement to this document will be published when the procedure is finalized. The supplement will explain the process for having new ideas reviewed and accepted for inclusion in future versions of the standard. Appendix A - Acronyms Appendix B - Glossary Appendix C - NTCIP Articles Appearing in the Institute of Transportation Engineers (ITE) Journal This document is updated from time to time to reflect the latest version of the NTCIP and the current version of each available document related to the NTCIP. To see whether this is the current version of this document, check the NTCIP home page on the World Wide Web at ii

7 Chapter 1: What Is the NTCIP? The National Transportation Communications for ITS Protocol (NTCIP) is a standard for transmitting data and messages between electronic devices used in Intelligent Transportation System, (ITS). An example of such a system is a computer at city hall monitoring and directing the operation of microprocessor-based controllers (effectively roadside computers) at traffic signals in a city. The computer regularly sends instructions to the traffic signal controllers to change timings as traffic conditions change and, the controllers send traffic flow and status information to the computer. In another example, two transit management systems (computers) exchange real-time information about the location of transit vehicles bound for a shared timed-transfer center, so each system knows instantly whether one vehicle is running significantly behind schedule and is unable to make the scheduled transfer time. Passengers can also be notified automatically, and the local traffic management center can be automatically requested to provide priority for the delayed transit vehicle at traffic signals. A communications protocol is a set of rules for how messages are coded and transmitted between electronic devices. The equipment at each end of a data transmission must use the same protocol to successfully communicate. It is a bit like human languages that have an alphabet, vocabulary, and grammar used by everyone speaking that language. Before the NTCIP was developed, each vendor of electronic devices and software used in transportation management systems adopted a different protocol for data communications. This made it very difficult to mix equipment and software from different vendors in the same system and to communicate between systems operated by adjacent agencies. The NTCIP provides a common standard that can be used by all vendors and systems developers. WHAT TRANSPORTATION MANAGEMENT SYSTEMS CAN USE THE NTCIP? The NTCIP is comprehensive and flexible; it actually defines several different protocols. For example, it provides a protocol that can be used with traditional equipment and communications infrastructures and others that are designed for use with new and emerging technologies. The NTCIP will eventually cover most types of devices and systems used in ITS, including systems for managing traffic and transit operations, traveler information, and multimodal systems integration. Initially, traffic signal management systems are a major application for the NTCIP. The NTCIP can be used with all types of traffic signal controllers, including National Electrical Manufacturers Association (NEMA) controllers, the Model 170 controller and variations thereon, and the Model 2070 and similar advanced controllers. The NTCIP can be used in all types of signal systems, including central control (second-by-second control), two-level distributed systems (no field masters), and three-level distributed systems (closed-loop systems with field masters). The current version of the NTCIP supports communications between controllers and field masters or computers. Field controllers can operate traffic signals, dynamic message signs, closed-circuit television cameras, ramp meters, environmental sensors, and other devices. The initial NTCIP protocol development effort focused on a standard for traditional direct communications between a master and multiple field devices sharing a communications cable or channel and low-speed communications such as 1,200 baud. This is the most common type of system used today. A standard protocol suited to this application ("Class B") was developed and has been published by NEMA. Standard messages ("objects") that can be transmitted using the Class B protocol are being defined for the following field devices: Global objects (common to all devices and will be published early in 1997) Actuated signal controllers (object set is defined and will be published early in 1997) 1

8 Dynamic message signs (publication expected in mid) Environmental sensor stations (publication expected in mid) Highway advisory radio (publication expected in mid) Freeway ramp meters (publication expected in mid) Video camera control (publication expected later in 1997) Traffic sensor stations (publication expected later in 1997). In addition to the Class B protocol, other protocols are being developed as follows: Class A - similar to Class B but able to be routed through intermediate devices Class B - basic protocol for use on low bandwidth communications channels Class C - similar to Class A but able to transfer files efficiently Class E - designed for center-to-center data exchange. The Class A and C protocols provide features not available in the Class B protocol, but the added functionality also adds overhead that increases the message delivery time significantly unless higher bandwidth channels are used. Class B is a "stripped down" protocol that provides basic services for multiple devices on a low-bandwidth channel. The same messages can be sent using any of the Class A, B, or C protocols, but both ends of the transmission must support the same protocol. A device may support multiple protocols. Chapter 2 more fully describes the different applications of the NTCIP, the benefits of using this standard, and guidelines for including NTCIP in procurement specifications. The technical details of the different protocols are described fully in Chapter 3. HOW THE NTCIP WAS DEVELOPED In 1992, in response to frequent requests for standardization from the users of traffic signal controllers, NEMA began discussions on the development of a common communications protocol for traffic signal systems. To encourage and broaden the process, the Federal Highway Administration (FHWA) sponsored a symposium in May 1993 to bring users from around the country together with manufacturers and software developers for both NEMA and Model 170 controllers. Over the next two and a half years, a NEMA working committee, with representatives from all types of traffic signal controller and signal system developers, held open meetings every few months to produce in December 1995 the first version of the NTCIP. That version defined a standard protocol for traffic signal systems. In February 1995, FHWA convened another symposium to review progress and to discuss further development of the NTCIP. The meeting revealed widespread support for the NTCIP and a desire to extend its scope to cover transportation management devices other than traffic signals. An NTCIP steering committee was established with representatives of users, designers, and developers of all types of ITS and including members from the public, private, and academic sectors. The committee convened in May 1995 and met every 6 weeks or so. In a further effort to speed the development of ITS standards, FHWA in late 1995 solicited proposals from standards development organizations interested in contracting with the Federal Government to develop ITS standards. Five organizations were selected to receive up to $5 million of initial funding. In September 1996, a consortium comprising of the American Association of State Highway Transportation Officials, ITE, and NEMA was awarded funds to jointly plan, oversee, and execute further development of the NTCIP. The NTCIP steering committee was renamed the NTCIP Joint Standards Committee and expanded to include six representatives from each of the three organizations. 2

9 Activities undertaken by the NTCIP Joint Standards Committee include the following: Planning and overseeing further development of the NTCIP Forming working groups to develop additional elements of the NTCIP Guiding the use of FHWA funds for contract services in support of the NTCIP Guiding the development of a "protocol exerciser" for testing NTCIP implementations Coordinating with related ITS and communications standards development efforts in the United States and internationally Writing this NTCIP guide Other outreach and promotional activities, including ITE Journal articles, the NTCIP web site, and various presentations and demonstrations. CURRENT NTCIP ACTIVITIES AND HOW YOU CAN HELP The NTCIP is continually being enhanced and expanded. Work is under way to add protocols or standard message definitions for more field devices, transit facilities, and center-to-center data exchange. Most of this work is performed by volunteers from the ITS community. Assistance and input is needed and welcomed from everyone. The following are some ways that you can help advance the NTCIP: Contact the NTCIP Joint Standards Committee chairman, Ed Seymour (phone: , fax: , ejs@tamu.edu) if you want to join a working group developing any of the NTCIP elements. If you just want to review and comment on documents prepared by a working group, monitor the activities of each group via the NTCIP Web site ( and download or ask for documents available for review. Use the NTCIP in projects and provide feedback on implementation experience. Specify that all new equipment and systems be NTCIP compatible, even if not needed immediately, so that the population of devices in the field will be compatible as quickly as possible. OTHER SOURCES OF INFORMATION ABOUT THE NTCIP The following are some further sources of information about the NTCIP: The Class B protocol technical specifications have been published by NEMA as documents TS 3.2 (National Transportation Communications for ITS Protocol - Simple Transportation Management Framework) and TS 3

10 3.3 (National Transportation Communications for ITS Protocol Class B Profile). These documents and an overview document (TS 3.1) are available from NEMA at The NTCIP home page on the World Wide Web ( provides historical and current information about the standards development activities, including downloadable files of technical papers and draft standards for review. The Standards Activities column in the ITE Journal provides highlights of NTCIP activities. The NTCIP coordinator at NEMA in Arlington, Virginia, is Bruce Schopp, and he is available to answer questions or refer you to others who can help. Contact him by telephone at , fax at , or at (bru_schopp@nema.org). 4

11 Chapter 2: How the NTCIP May be Used This chapter is intended for those responsible for the procurement of ITS equipment, including traffic signals and other transportation management systems. It describes how the National Transportation Communications for ITS Protocol (NTCIP) benefits users, the different types of transportation management systems that the NTCIP supports, how to choose between the various options available in the NTCIP, issues to consider in system design, how to incorporate the NTCIP in specifications for equipment procurement contracts, answers to questions frequently asked by users, and sources of further information for users. This document is updated from time to time to reflect changes in the NTCIP. To see whether this is the current version of this document, check the NTCIP home page on the World Wide Web at or contact the NTCIP coordinator, Bruce Schopp, at NEMA (phone , fax , WHY THE NTCIP SHOULD BE SPECIFIED IN ALL PURCHASES The NTCIP offers increased flexibility and choice for agencies operating transportation management systems. It removes barriers to interjurisdictional coordination and allows equipment of different types and manufacturers to be mixed on the same communications line. For these reasons, operating agencies will benefit from specifying that the NTCIP be included in all future purchases and upgrades, even if the NTCIP is not planned to be used initially. Avoid Early Obsolescence Even though it may not be practical to retrofit NTCIP support in some old equipment, most vendors will offer NTCIP support in current and future products. It is possible to operate a mixture of NTCIP and non-ntcip devices in the same system, although not on the same communications line. Alternatively, equipment may continue to use a current protocol even though it also supports NTCIP. In either case, an operating agency can ensure that its equipment remains useful and compatible long into the future by requiring NTCIP support in all future purchases and upgrades of transportation management systems, including purchases of individual masters and controllers for any type of traffic control, monitoring, or traveler information device. Buying a field device, such as a signal controller or sign controller, or a field master or central control system that has no software available to support the NTCIP, is like buying an incompatible computer that has no software available to access the Internet. Even if purchasers do not use the Internet now, they surely will during the lifetime of the computer. Provide Choice of Vendor Once an agency has a master or computer system that includes support for the NTCIP, it can purchase field devices or software from any manufacturer offering NTCIP-compatible products, and they will communicate with that master. Only products from the same vendor will be able to fully use the features within the master or controller that are manufacturer specific, but basic functionality will be available regardless of the manufacturer. To gain the full benefit of a particular manufacturer's unique features, and for other reasons such as ease of maintenance, many agencies will likely continue to standardize on a single vendor. However, the NTCIP will make it easier for such an agency to gradually change its controllers and other field devices from one vendor to another in the future as part of a switch to a new vendor for the entire system. 1

12 Provide Interjurisdictional Coordination In traffic signal systems in particular, it will be very useful for an agency to be able to communicate with and implement, at least, basic monitoring and signal coordination functions for adjacent controllers that are owned by other agencies and may be from a different vendor. Furthermore, such "foreign" controllers can be added on to an existing communications channel and mixed with different types of controllers on the same line. Future enhancements to the NTCIP will address system-to-system links. This will solve the problem of two masters needing to communicate with each other for the purpose of coordination and monitoring of devices operated by adjacent jurisdictions. Use One Communications Network for All Devices The NTCIP also allows a master to communicate with a mixture of device types on the same communications channel. For example, with the addition of appropriate application software in the master, a variable message sign could be installed near a signalized intersection, and the master could communicate with the sign controller using the communications channel already in place for the traffic signal controller. The communications network is usually the most expensive component of a transportation management system. The NTCIP ensures maximum flexibility in future use of that major investment. TYPES OF SYSTEMS SUPPORTED BY THE NTCIP Types of Devices Supported The NTCIP defines a family of general-purpose protocols that support all types of devices used in transportation management systems. The initial NTCIP standard also defines device-specific application-level objects, or messages, for traffic signals. Work is underway to add object definitions for dynamic message signs, closed-circuit television (CCTV) camera control, ramp meters, vehicle detection/count stations, highway advisory radio, environmental sensors, and other devices. The underlying layers of the basic communications protocols in the NTCIP can support communications for almost any type of field device. The standard also includes a set of objects, or messages, specific to each type of device. For example, CCTV camera control requires a message such as "Pan right x degrees," which is not needed for other devices. Messages that are common to most device types, such as "Set date and time," have been placed in a set of global messages. The device type-specific messages, combined with the global messages and the underlying layers of the NTCIP (which are also common to all devices), define a complete protocol for each device. 2

13 Since all devices use the same fundamental protocol, different types of devices can be mixed on the same communications channel. For example, a variable message sign could be inserted between two different types of traffic signals in a daisychain of devices on the same communications line, as illustrated in Figure 1. Furthermore, communications software developed for one type of device can be used with little change for other devices. The NTCIP is independent of the hardware used. For example, the NTCIP can be used directly with any type of traffic signal controller. It does not matter if the signal controller follows the National Electrical Manufacturers Association (NEMA) TS-1 standard, TS-2 standard, the Model 170 standard, the Model 2070 standard, or no standard at all, so long as its software implements typical North American phasing and timing logic. Some different messages would need to be defined for controllers that embody European, Australian, or Japanese controller logic. Additional messages can be defined by a controller or software vendor to address any features unique to that vendor. Figure 2.1 Communications with Different Devices System Configurations Supported One of the fundamental principles of the NTCIP is that it is independent of the way in which a transportation management system is configured. For example, the NTCIP can be used in any of the typical traffic signal system configurations, including these: Central control (e.g., Urban Traffic Control System (UTCS)) Two-level distributed control (e.g., interconnected time base without field masters) Three-level distributed control (e.g., typical "closed-loop" systems). The initial version of the NTCIP assumes that all field devices will communicate with a master of some kind. That master may be a central computer, a field master, or another field device (e.g., a device controller that acts as a master as well as a local controller). Future extensions to the NTCIP will add support for intermediate management stations and for contention-based peer-to-peer communications in which devices can report an event or exception at any time without having to wait to be polled. Types of Data Links Supported The NTCIP can be used over almost any type of direct communications link. Examples of different types of communications media that could be used include twisted pair, coaxial cable, optical fiber, and radio (e.g., narrow band, spread spectrum, microwave). It does not matter whether the communications media is agency owned, leased, or dial-up. Any data transmission rate could be used, from say 300 bits per second to many megabits per second, if the devices support those speeds. It does not matter whether the communications configuration uses concentrating hubs or multiplexers to combine multiple channels on trunk links. 3

14 The only requirement is that the time of transmission, and any turnaround delay time in transmission devices such as modems, be reasonably small and consistent. The protocol is based on polling, and the master cannot wait indefinitely for a response message. If the time between when the last byte of a message leaves the master and the first byte of the response arrives at the master is too long (e.g., half a second), it will not be possible to poll many devices on the same channel within 1 or 2 seconds, which is a typical polling cycle for many traffic signal systems. The NTCIP can be used with both half- and full-duplex circuits. As discussed below, the NTCIP Class B protocol is designed for use with slower communications links, such as 1,200 baud. However, it involves some more overhead than most of the proprietary protocols in use today, and it may not be possible to maintain the same polling cycle time with the same number of controllers per channel and the same baud rate. Types of Messaging Strategies Supported The initial version of the NTCIP is based exclusively on polling as a messaging strategy. This messaging strategy is used almost universally in the industry today. Polling involves the masters sending a request message addressed to a particular device, and that devices sending back a response message. The field device can speak only when spoken to. The NTCIP also allows the master to broadcast messages to all field devices on a channel simultaneously. The protocol includes support for future "trap" messages, which are event-driven messages sent by the field device at the next poll. This will enable a field device to report unusual events and faults when they occur without having to send complete status information at every poll. The NTCIP allows the use of "dynamic" messages that may combine several shorter messages for efficient communications. This enables a system to use custom combinations of data in messages, smaller messages with less overhead, and messages suited to particular needs, while still using standard message components and still allowing communication with any NTCIP- compliant device. Dynamic messages can be as short as 8 bytes, including the opening and closing flags. Poll-only messages from the master can be as small as 6 bytes. Planned enhancements to the NTCIP include support for peer-to-peer communications and an event-driven messaging strategy as an alternative to polling. Peer-to-peer options within the NTCIP would be used for communications between computers (e.g., computers in different traffic management centers) on a wide area network, for direct communications between local controllers, and for event-driven communications between computers and field devices. Applications for these capabilities include data exchange and coordination between jurisdictions, traffic signals that interact locally to optimize coordination without having to use a common background cycle length, and the ability to economically use commercial switched-packet networks for communications between a computer and field devices. Signal System Functions Supported The initial version of the NTCIP provides messages directly supporting the most common functions and features of traffic signal systems, including the following: Setting controller clocks Uploading traffic volumes and occupancy Instructing controllers to change to a particular coordination pattern Monitoring such signal status as phase color, phase demand, and detector status Monitoring the controller for faults and alarm conditions 4

15 Checking and changing settings in the controller database. These and other supported functions cover most of the features common to modern traffic signal systems, including dynamic map displays of groups of signals and dynamic graphic displays of individual intersections. Most controller software incorporates some unique features and parameters. Some of these may require special messages to be defined. This can be done by the software or controller vendor using a standard procedure defined within the NTCIP and described below. This enables the standard to evolve and accommodate innovation and advances in traffic control systems. CHOOSING NTCIP OPTIONS The NTCIP has been designed to be very flexible, so as to support the wide variety of current and future configurations and features of modern transportation management systems. The NTCIP incorporates several options that a system designer can choose from. Protocol Profiles The NTCIP will soon define two alternative protocol "profiles" suitable for field devices as described in the Institute of Transportation Engineers papers appended to this document. A system designer will be able to specify that equipment or software support Class A Profile, the Class B Profile, or both. The Class B profile defines a simple connectionless protocol that is very efficient in terms of minimum overhead, but can be used only for point-to-multipoint communications. The Class A profile is an enhanced connectionless protocol that supports full network addressing and message routing, and therefore can be used in any network configuration. Class A enables messages to be routed via intermediate devices, such as a field master or communications hub. Class B requires the communicating devices to be directly connected with no intermediate devices (although other devices can share the same communications channel). The added flexibility of Class A comes at the price of extra overhead that increases the transmission time. In general, Class A is intended for high-speed communications links where message routing is needed such as between a computer and next-generation controllers (e.g., the Model 2070 controller) via a communications hub, or for low-speed indirect communications links where frequent real-time transmissions are not needed. Figure 2 illustrates an application. 5

16 The Class B profile is intended for typical low-speed (e.g., 1,200 to 4,800 baud) direct communications with the current generation of field controllers. A master that supports both profiles can communicate on the same communications channel with controllers that use either profile. Therefore, it is generally useful for masters to support both profiles. A field master or communications hub may also communicate with controllers using Class B and with a central computer using Class A. The contents of the messages sent are the same regardless of whether the Class A or Class B profile is used. They are just different ways of transmitting the same information. Conformance Level There are two conformance levels to choose between, regardless of which class profile is used. A system designer must specify one or the other. Conformance Level 1 is a subset of Level 2. The difference between the two conformance levels is that Level 2 adds support for the Simple Network Management Protocol, including global Internet objects. Figure 2.2 Example of Class A Communications Conformance Level 1 provides basic functionality suitable for most applications. Conformance Level 2, which is a superset of Level 1, provides exactly the same functionality as Level 1 and adds the option to use additional security features such as passwords and multilevel access control for individual messages. If such additional features are used, the message transmission time will be increased and is, therefore, usually not practical for use with low-speed communications links. Optional Objects The NTCIP defines groups of objects (messages) that are optional and can be included or excluded from a procurement specification. It is generally advisable to require support for all optional objects, even if not needed initially. However, prospective vendors should be consulted to ensure that specification of such objects will not incur significant additional cost or delay. Object Value Ranges The NTCIP does not specify the range of valid values for each object. This can be left to the vendor, but the range for some objects, such as phase yellow time, may be important for failsafe operation. A suggested value range for objects has been provided as an appendix to this Guide. This appendix may be referenced in a procurement specification. Modification to specific object ranges can be included in the specification if needed. 6

17 Physical Interface The NTCIP requires either RS-232 or FSK modem for the interface to the physical communications link. Additional interfaces may also be provided as needed. An RS-232 interface provides maximum flexibility, including the use of an external FSK modem. An internal FSK modem avoids the need for an external modem but may preclude the use of other transmission schemes, unless the device also has an RS-232 port. The important thing is that compatible modems or other transmission equipment are provided at both ends of each communications link. Maximum Address The NTCIP specifies that at least 62 devices are addressable on one communications channel. This is normally sufficient. However, the system designer may specify a larger number if needed. Use of a larger number will add 1 more byte to all messages and increase message transmission time a little. In practice, polling cycle time considerations usually limit the practical maximum number of devices on a channel to considerably less than 62. Maximum Packet Size The NTCIP specifies that the device support packet sizes of up to 515 bytes. This is normally sufficient. However, the system designer may specify a larger maximum packet size if needed. Use of larger packets will increase the time that the system needs to allow for message transmission. DESIGNING SYSTEMS WITH THE NTCIP Retrofitting Existing Systems with the NTCIP It may not be feasible to modify old versions of controllers or controller software to make them NTCIP compatible. If such controllers or software cannot be upgraded or replaced, traffic control systems that continue to make use of older equipment or older software versions will likely have to continue using the protocols unique to communications with those devices. However, current version controllers and software within the system can be modified to use the NTCIP, and all future versions should be NTCIP compatible. NTCIP-compliant traffic signal controllers satisfy the requirements of California's AB 3418 legislation, which requires a standard protocol in all new and upgraded controllers. However, the AB 3418 protocol does not provide NTCIP compliance and provides only very limited functionality. The AB 3418 protocol is a small subset of the NTCIP. NTCIP and non-ntcip devices cannot be mixed on the same communications channel. Therefore all devices sharing a channel must be upgraded simultaneously. A master that communicates with both NTCIP and non-ntcip devices will need to use a different communications port for NTCIP devices and for non-ntcip devices, and will need to support both protocols. In traditional closed-loop signal systems, the most likely and simplest solution is to limit each field master to one protocol. Only field masters with NTCIP-compatible controllers would be upgraded to support NTCIP. This avoids the need for field masters to simultaneously support two protocols on two separate ports. In closed-loop traffic signal systems, the central computer could communicate with field masters using a different protocol than that used by the field master to communicate with controllers. The central computer could also use different protocols to communicate with different field masters, even using the same communications port, assuming that communications are with only one field master at a time. As with the controller and the field master, the central computer 7

18 software will need to be modified to add support for the NTCIP protocol if the NTCIP is to be used for communications with field masters. Any upgrade of an existing system to add support for the NTCIP is probably best designed in consultation with the system vendor. Each vendor will likely adopt an upgrade strategy that is most efficient for the majority of its customers. If a particular customer wants a unique arrangement, that customer will probably have to pay the full cost of the software modifications, whereas the cost of the general solution will be spread among many customers. One approach to the introduction of the NTCIP is to operate two totally separate systems-one NTCIP and one non- NTCIP-during a transition period. Field devices can gradually be switched over from one to the other as they are replaced or their software is upgraded. This may be the only choice if the current system is quite old and upgrading it for NTCIP is not practical. Such a transition would logically be done as part of a general system upgrade. Even if a system continues to use a proprietary protocol, new controllers and masters, or new software packages, it should include NTCIP support as an option. Some vendors will support both their existing protocols and the NTCIP in the same software package. Others will require a change of software to switch from one protocol to the other. Regardless of how it is done, the owning agency should ensure that NTCIP support is available for future use even if it is not needed immediately. This will maximize the useful life of the new equipment and enable introduction of the NTCIP at any time in the future without further upgrades. It also maximizes options and competition when choosing new equipment, since different vendors' equipment can be mixed if needed. As discussed above, the NTCIP Class B protocol may involve more overhead than the existing proprietary protocol, and it may not be possible to maintain the same polling cycle time with the same number of controllers per channel and the same baud rate. This issue can be critical for signal systems, such as UTCS, that use second-by-second central control, and may require use of a higher baud rate or additional communications channels. Two masters, or one master supporting both the proprietary protocol and the NTCIP can be used to gradually transition to an all-ntcip system as controllers (and communications equipment, if necessary) are upgraded over time. The NTCIP in New Systems An agency that is able to "start from scratch" with all new controllers, or all new software, can implement the NTCIP for an entire system very easily. It is then unnecessary to accommodate a mixture of NTCIP and non-ntcip devices. From an operating agency's point of view, it is only necessary to specify the NTCIP options to be used for communications in the new system. One of the powerful features of the NTCIP standard is the ability for a master to communicate with different types of controllers or controller software packages. This feature is often needed when one or two controllers within a group of closely spaced signals is owned by a different jurisdiction. Even if one agency is implementing a totally new system, it may still have a need to communicate with different controllers owned by another agency. Therefore, even if a new system is designed to use the Class A profile for all communications, the master should still have the ability to use Class B communications for other agencies' controllers. Changes Over Time Competition between controller and software vendors leads to innovation and unique features and functions. The vendors respond to customer feedback and continually improve their product to better meet user needs. The NTCIP recognizes that such innovation is desirable and must be accommodated within the communications standard. Hence the NTCIP provides for manufacturer-specific management information base (MIB) modules, which can be created by a vendor (or 8

19 an agency) at any time to define new features and the associated unique messages. MIB modules are described in detail in another chapter. An agency wanting additional features may define its own MIB module and include it in the specifications for new equipment or software. These additional MIB modules are extensions to the NTCIP. Agencies purchasing new equipment or software should specify that all manufacturer-specific MIB modules be supplied on a disk so that support for the additional features can be implemented in the management system. Over time, as multiple vendors come to offer effectively the same feature, many such innovations will become "standard" and no longer offer a competitive edge to one supplier. Then the feature can be added to the set of standard messages within NTCIP rather than remaining manufacturer specific. Additional MIB modules are one way in which the NTCIP will be continually enhanced over time. Agencies may want to upgrade their systems from time to time to take advantage of such enhancements. Another source of change in the NTCIP over time will be the addition of more protocol profiles, which will tend to address specialty applications and will have less impact on existing systems. The profiles will be of interest to agencies starting new systems, linking with adjacent agency systems, or wishing to use commercial communications networks. Current controller and master software will have to be modified to support the NTCIP. Most vendors of traffic signal systems (and many vendors of others devices such as CCTV camera controllers and variable message signs) have indicated an intent to make those software modifications, at least for future product versions. The cost of software modification will be small on a per unit basis. Most vendors are expected to continue to offer their current proprietary protocol as an alternative to NTCIP, or for use in mixed systems, at least for several more years. However, vendors will not want to support two different protocols indefinitely and may drop the old protocol from future products. To avoid being left with an unsupported and incompatible communications protocol, users can ensure that all future purchases include support for the NTCIP and that proprietary protocols are replaced with the NTCIP as soon as possible. OTHER CONSIDERATIONS Competition, Proprietary Interests, and Confidentiality Agencies responsible for traffic management are best served if they can choose between multiple competing vendors for all elements of traffic management systems. Vendors will always compete on the basis of price and support, but competition in system functionality is also desirable to continually advance the state of the art through innovation. A vendor will not invest in research and development of new functions if the results cannot be kept proprietary to that company to ensure that a marketing advantage accrues from the development effort. As discussed above, the NTCIP allows for manufacturer-specific MIB modules to address the need for proprietary features. It is unrealistic to expect vendors to openly publish documentation, including MIBs, that reveal the workings of proprietary developments. A procurement specification that requires disclosure of proprietary MIB modules to competitors may result in either no conforming proposals or significantly higher priced proposals. As already noted, it may be reasonable to require disclosure of proprietary MIB modules to a systems integrator. However, the procuring agency needs to provide assurance that the information will be kept confidential by all involved parties and that it will not be used except as allowed for in the contract. If an agency is concerned about the "one-supplier" limitation of proprietary features, it can always choose to limit its system to use only nonproprietary NTCIP elements (except for some necessary manufacturer-specific information). This 9

20 can be done in either of two ways. The first option is for the agency to specify use of only the current NTCIP standard objects, with no unnecessary manufacturer-specific extensions allowed. This will ensure that equipment from all vendors complying with the NTCIP will be compatible and usable in the system without modification. However, this fails to take advantage of any extended functionality, and may exclude some systems that use proprietary features in such a way that they cannot be "switched off" to revert to a generic standard NTCIP implementation. The second option is to allow vendors to offer the NTCIP standard objects plus any nonstandard objects the vendor is able and willing to provide open documentation for, including MIB modules that can be given to any vendor to facilitate integration of other vendor's equipment. This option will likely result in the availability of additional features and functionality on which the user may become dependent. However, full use of those features with third-party equipment may not be feasible without some additional systems integration effort and, therefore, cost. This option may also exclude some systems that use proprietary features in such a way that they cannot be "switched off" to limit the operation to only those features for which the vendor is prepared to reveal documentation to competitors. Agency-Specified Features An operating agency may choose to develop its own extensions to the NTCIP and require that vendor proposals include support for these extensions. Unless the agency represents a large market in itself, or other agencies adopt the same extensions, the number of vendors able and willing to add the additional features may be severely limited, and the system cost (initial and maintenance) may be significantly increased by the need to add and support such custom features. Agency-specific extensions may be necessary for totally new and unique features developed and implemented within an agency. Agency-specific extensions are not recommended for minor features or as custom replacements for NTCIP standard objects, the only purpose of which is to implement the standard feature in a "better" way. It is conceivable that a group of customers (preferably with the cooperation of vendors) could collaborate to define a set of NTCIP extensions (experimental MIB modules), which they all include in their standard specifications. Such extensions may become a de facto standard by virtue of the market represented by those customers and would likely quickly be added to the NTCIP standard objects. Such a process may be used as a way to expedite updates to the NTCIP standard without having to wait for the formal NTCIP revision procedures. However, it will be successful in this regard only if a broad cross-section of customers and vendors are included in the development of the experimental MIB modules. Development of significant numbers of specific extensions by individual large agencies or a limited group of agencies will probably result in the proliferation of multiple "standards" and will defeat the basic intent of the NTCIP. Any attempt by agencies to specify NTCIP extensions must also take into account the time required for vendors to develop the custom features as well as the level of support that can be expected in the future if the extension does not become a part of the NTCIP standard. An agency may find itself with a unique version of software that is no longer actively supported, is supported only at additional cost, and is likely to not be available from other vendors. The feature is also likely to not be available in systems operated by neighboring agencies with which shared communications may be desirable in the future. In general, agencies are encouraged to work together and with vendors to cooperatively evolve the NTCIP to address the needs of everyone. This process will inevitably involve compromise but in the long run will ensure an enduring and effective standard, the benefits of which will outweigh any short-term limitations. 10