Module 42 - A315b Part 2

A315b Part 2: Specifying Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 v03 Standard Part 2 of 2

HTML of the Student Supplement

(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)

---

A315b Part 2 of 2: Specifying Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 v03 Standard

Table of Contents

Module Description - 2

Introduction/Purpose - 2

Deep Dive Topics - 3

Communications Loading - 3

Types of ASCs in Service - 4

Extensions to the Standard - 10

Exception Reporting - 10

References to Other Standards - 10

Case Study: Anaheim - 11

Glossary - 11

References - 13

Study Questions - 13

1. Module Description

NTCIP 1202 v03, Object Definitions for Actuated Signal Controllers (ASC), was recently updated and published. This standard defines objects to allow transportation professionals to monitor, configure, and control traffic signal controllers. Version 3 of the standard was developed using a Systems Engineering Process (SEP) and contains user needs, requirements, and design content. The SEP allows transportation managers and specification writers to more easily prepare a Procurement Requirements List (PRL) for ASC procurement specifications.

The purpose of this updated module is to incorporate necessary changes made by the updated NTCIP standard v03 (from v02), and assist technical staff in writing unambiguous, complete, and well-written requirements based on NTCIP 1202 v03. This module provides participants with information on how to identify the appropriate use of the NTCIP 1202 v03 and acquire a traffic signal control system based on what the user is seeking to accomplish.

This module is part of the SEP path. In A315a: Understanding User Needs for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 Standard, students learned how to select standardized user needs and requirements using the PRL. In this module, students will gain a better understanding of how a project PRL can be used to improve interoperability and the issues that agencies should consider when deploying actuated traffic signal controllers. The module is provided in two parts, Part 1 and Part 2.

Part 1 focuses on the standardized ASC requirements and introduces the design content (dialogs, objects, and other references and/or special project requirements if any) using tools and resources in the Standard such as the PRL, the Requirements Traceability Matrix (RTM), the Management Information Base (MIB) and the SEP. Part 1 will provide participants with information on how to understand the scope of the NTCIP 1202 v03 Standard, identify the appropriate use of the Standard to acquire an ASC system, and how to prepare (tailor) their ASC project specification.

Part 2 focuses on additional considerations when specifying NTCIP 1202 v03 and the unique aspects of the NTCIP 1202 device standard when compared to other NTCIP device standards. Part 2 also discusses how to define extensions to address user needs and requirements that are not supported by the NTCIP 1202 v03 standard.

The logical next step for the participant is to consider modules in the testing lifecycle, which are T101, T201, and T202; and T203 Parts 1 and 2, and T204, which lead up to the T315 module: Applying your Test Plan to the NTCIP 1202 ASC Standard.

2. Introduction/Purpose

The focus of this module is to assist technical staff in developing specifications for an ASC system that meets identified user needs in an interoperable fashion. This module assumes that the participant, having taken A315a, understands the structure and use of the standard PRL to produce a project-level PRL that identifies the needs and requirements for a specific project. It also assumes that the participant has taken A315b Part 1 and understands how the project PRL traces to requirements and how it fits into a procurement specification.

Part 2 of this module builds upon that understanding to describe the special issues that agencies should consider when procuring and deploying ASC equipment.

3. Deep Dive Topics

This section is included to provide a deeper dive into additional topics beyond those included within the limited time constraints of the module. These topics are identified to avoid adverse effects on project delivery and system performance if not handled properly by ASC Requirements.

3.1. Communications Loading

Historically, ASCs communicated via dedicated agency-owned circuits; leased, dedicated phone lines; or dial-up phone lines. In many cases, the agency-owned and leased lines would be multi-dropped such that up to eight ASCs would share a single communications channel. The dynamics of this type of line limited data rates to 1200 bps, even as late as the 2000's. This low data rate largely precluded the use of mainstream protocols, like the Simple Network Management Protocol (SNMP), and resulted in the development of a custom protocol designed for the Intelligent Transportation Systems (ITS) industry known as the Simple Transportation Management Protocol (STMP).

Beginning in the mid-1990s, the desire to obtain video from the field changed the communications environment and cities began to modernize their communications infrastructure. Modern network ports, such as Ethernet, began appearing on ASCs, vastly increasing the data rates available. However, the costs involved in replacing an installed communications infrastructure with new fiber was costly. For decades, it was difficult to justify the cost of replacing the 1200 bps infrastructure when it continued to provide the base functionality that users expected.

In the late 2000's, the trade-off analysis began to change. Costs for alternative communication technologies especially wireless technologies decreased, while the total cost of ownership for maintaining an aging 1200 bps system that required custom protocols (e.g., STMP) increased. (See call out box.)

Total Cost of Ownership for Legacy Communications

The total lifecycle costs of ownership for legacy communications has to consider several factors, including the following:

• Cost of maintenance associated with an aging infrastructure, including:
  • Cabling
  • Modems
• Costs of supporting specialized protocols to support the low data rate communications
  • Increased controller costs
  • Increased integration costs
  • Increased testing and debugging costs
  • Extra, customized training for maintenance staff
  • Escalating prices as the market supporting the legacy technology dwindles
• Increased cybersecurity risks associated with exchanging safety-of-life information without any authentication
• Opportunity costs due to inability to provide functionality requiring significant data transfer (e.g., travel time data, connected vehicle data, still images, video, etc.)
• Inability to deploy a connected vehicle environment due to cybersecurity and data transfer limitations of system resulting in the following issues:
  • Increased institutional risks for not deploying safety-of-life technologies in a timely manner
  • Inability to realize the reduction in societal costs offered by the efficiency services offered by a connected vehicle environment

3.2. Types of ASCs in Service

While there is not an industry-accepted definition of "types" of ASCs, this training module relies upon two industry reports:

• "AASHTO Connected Vehicle Infrastructure Deployment Analysis" (USDOT, 2011)
• "How Locals Need to Prepare for the Future of V2V/V2I Connected Vehicles" (MNDOT, 2019)

The United States Department of Transportation (USDOT) report provides a holistic look at the state of ASCs across the country, whereas the Minnesota Department of Transportation (MNDOT) report provides a much more recent snapshot for one specific state. However, the two reports seem to present a consistent and reasonably positive assessment regarding the direction of ASC deployments across the country.

The USDOT report surveyed ASC manufacturers in 2011 to determine the readiness of in-service ASCs to support Connected Vehicle (CV) applications in terms of performance, without regard to manufacturer, owner/operator or age of equipment. The 307,000 controllers estimated to be in service in 2011 were split into the nine types, based on the following four performance factors:

• Computational speed needed for signal control and CV software applications
• Communications from ASC to Central Station and from ASC to roadside equipment
• Software Operating System required for 3^rd party CV software application
• Compatibility with API standard used to share ASC resources among software applications

Table 1: Types of Controllers in Service in the US in 2011

Controller Type	Speed	Comm	OS	API	In service
ATC 5.2b	Yes	Yes	Yes	Yes	8,000
Model 2070LX	Yes	Yes	Yes	Yes	0
Model 2070E	Yes	Yes	Yes	No	0
Model 2070L	Yes	Yes	Yes	No	52,000
NEMA, Modern	Yes	Yes	33%	No	36,000
NEMA, Legacy	No	Adaptor	Yes	No	91,000
Type 170, Modern	Yes	Yes	No	No	12,000
Type 170, Legacy	No	Adaptor	No	No	102,000
Electromechanical & Other	No	No	No	No	6,000

Total: 307,000

As can be seen in Table 1, only three differences exist among the listed types. For the purpose of this training module, we have consolidated the types into the following:

• Emerging ASCs: > 60 million instructions per second (MIPS), Linux operating system (OS), application programming interface (API) compatibility and separate networks for Central and Roadside Equipment,
  • ATC 5.2b, which was the current version of ATC5201 when the FHWA report was written
  • Model 2070 LX, which references ATC5201 v5.2b, plus special provisions
• Modern ASCs: 4-60 MIPS, OS, no API compatibility, network for Central and Roadside Equipment
  • Model 2070E compliant to ATC5202 at this writing
  • Model 2070L
  • NEMA TS-2 ASCs that include Ethernet
  • Type 170 ASCs that include Ethernet
• Legacy ASCs: < 4 MIPS, no standard OS, no API compatibility and no network communications,
  • NEMA TS-2 and NEMA TS-1 ASCs without Ethernet
  • Type 170 ASCs without Ethernet
  • Electromechanical and other non-standard ASC types

From a functional perspective, these ASC types can be characterized as follows:

• Emerging ASCs have the computational speed and the network communications performance necessary to send, receive, interpret, and store standardized objects using mainstream protocols. ASCs that conform to ATC 5201v6 (the current version of the ATC 5201 standard, which was passed in 2018) or later provide processing speeds of at least 500 MIPS and should be fully capable of a range of CV applications. These devices will minimize testing and integration costs due to their generic and standardized interface. When considering the purchase of new hardware, these total cost of ownership benefits should be contrasted against the cost of upgrading to ASC 5201.
• Modern ASCs have the network communications necessary to send and receive standardized objects using mainstream protocols but may not have the computational speed to reliably handle a busy Ethernet communications channel while running signal control and/or other CV applications. This may require additional hardware collocated with the ASC to minimize the processing load. Incidences of Modern ASC being overwhelmed by network communications are known. Again, the total cost of ownership should be considered when writing requirements.
• Legacy ASCs have neither the network communications necessary to send and receive standardized objects using mainstream protocols nor the computational speed to interpret complex requests. Dialogs of non-standardized objects and other customized solutions are typically used to overcome the Legacy ASC limitations. This customization creates additional costs for development and testing that should be considered when writing requirements. The cost to replace Legacy ASCs may be less expensive.

The survey described in Table 1 was conducted in 2011; however, it appears that few, if any, legacy ASCs have been sold in the past nine years. Based on the controller replacement trends experienced within the industry, it is estimated that the percentage of legacy controllers in use have been steadily declining as shown in Figure 1, a figure originally developed as a projection for the first version of this training course.

Red: Legacy ASCs unable to support full NTCIP and connected vehicles

Blue: Replacement ASCs that support NTCIP and are technologically able to support connected vehicle applications

Green: Total installed base of ASCs

Figure 1: Types of Controllers in Service in the US: 2011-2018

As further evidence of this trend, MNDOT conducted a statewide assessment of their signal controllers in 2019. Their results, provided in Table 2, indicate that only about 5 percent of their controllers fall into the legacy category, while perhaps as many as 35 percent would be considered emerging. This analysis seems to lend credence to the predictions contained in Figure 1 and suggests that technologies, such as the STMP, that were designed for legacy equipment should be avoided when possible.

Table 2: Types of Controllers in Service in the Minnesota in 2019

	MnDOT	County Totals	City Totals	Statewide
ASC/2S-2100 (NEMA TS2 Type 2)	51.6%	57.6%	5.4°%	36.1%
ASC/2S-1000 (NEMA TS2 Type 1)	0.0%	7.3%	0.0°%	2.7%
ASC/2M-1000 (NEMA TS2 Type 1)	0.0%	0.1%	0.2%	0.1%
ASC/3-2100 (NEMA TS2 Type 2)	45.5%	29.1%	6.6%	24.6%
ASC/3-1000 (NEMA TS2 Type 1)	0.1%	2.8%	0.0%	1.1%
ASC-8000 (NEMA TS1)	0.4%	2.7%	1.1%	1.5%
DELTA 3 (Standards Unknown)	0.1%	0.0%	0.0%	0.0%
EAGLE EPAC-300 (NEMA TS1)	1.0%	0.1%	1.3%	0.8%
EAGLE M52 (NEMA TS2 Type 2)	0.0%	0.0%	0.3%	0.1%
170	0.0%	0.0%	5.2%	2.0%
PEEK	0.0%	0.0%	1.9%	0.7%
Siemens	0.0%	0.0%	76.3%	29.3%
Under Construction	0.0%	0.0%	0.1%	0.0%
Unknown	1.2%	0.2%	1.7%	1.0%
Total Signals	671	983	1029	2683

3.3. ASC Clock Coordination

When writing ASC requirements, be sure to consider the coordination and connected vehicle applications to be used and how the selected control strategy affects the ASC clock coordination from both a precision and accuracy perspective.

Signal coordination requires that adjacent signals provide green indications for the coordinated movements within a few seconds of the intended time (i.e., the coordinated signals must operate precisely with one another within a few seconds) requirements. Further, to properly respond to planned time-of-day operational changes, the signals need to have an accurate time within a few minutes.

By comparison, connected vehicle applications, including the Signal Phase and Timing (SPaT) message of the Connected Vehicle Traffic Signal System, requires a precise (50 millisecond) coordination between the signal and each approaching CV. Technologically, this is achieved by the Roadside Equipment Intersection Management functional object¹ converting the phase change information from local (i.e., signal controller) time into a time synchronized with the Global Navigation Satellite System (GNSS).² This also results in a very accurate time (50 milliseconds) as a by-product.

¹ The Roadside Equipment Intersection Management function object is defined in the Architecture Reference for Cooperative and Intelligent Transportation (ARC-IT), which can be found at https://local.iteris.com/arc-it/index.html.

² Americans often use the term "GPS." The Global Positioning System (GPS) was the original GNSS. While GPS provides a global system that has been made available for commercial use since the 1980s, it was deployed by and continues to be operated and maintained by the U.S. military, which reserves the right to alter the accuracy of signals when necessary to protect U.S. interests. As a result, other countries/regions have established their own systems. GNSS is the term used to generically reference any of these systems.

The performance of various time-synchronization technologies supported by the NTCIP 1202 v03 standard are as follows:

• Power line service frequency: This technology is based on the ASC tracking the frequency of the alternating current from the power line. Within the US, 60 cycles should theoretically correspond to one (1) second. However, the service frequency will drift above or below 60 Hz and over short terms this variation can be as high as a second a minute. As long as all ASCs are connected to the same power circuit and are all using this same synchronization technique, the ASCs will sense the same frequency and will remain very precise with one another. ASCs on different power circuits (which is the typical scenario) should use an external mechanism to synchronize the start point of each traffic signal cycle (e.g., the traditional sync-pulse). Over a period of a day, the time may drift by a considerable amount (e.g., a minute or more). As a result, the time should be externally coordinated at least once a day. If the signal is to be coordinated with signals using other synchronization techniques, the sync-pulse will need to be based on the other time sources.
• Crystal oscillator: Each ASC has its own internal clock that will drift slightly differently due to temperature and other factors. The crystal oscillator frequency is very accurate over the short term, but the slight inaccuracy accumulates continuously. After years of continuous operation, the clock may drift by minutes or hours among ASCs. Using this design, signals generally do not require a sync-pulse per cycle but should be synchronized with a central source roughly once-a-day to prevent drifting by more than a couple of seconds from adjacent signals.
• GNSS: With this technology, the ASC is attached to a GNSS receiver that includes a very accurate timestamp with no drift, but with a slight latency delay through the receiver. With this design, signals do not require any other external synchronization.

NTCIP includes a method to send the time to each ASC from central, but transmission delays through the communications network can be a few seconds, depending on the network design.

The clock coordination method will vary depending upon the following control strategy requirements:

• Time Base Coordination (Green Wave): Constrains the clock source to service frequency, GNSS or broadcast so that each ASC on the corridor retains the same inaccuracy. Each ASC may vary slightly from actual time, but the same variance in each ASC will maintain the green wave progression timing.
• DC service: Constrains the clock to GNSS, crystal, or broadcast. Portable intersections, work zones, and solar-powered applications are typically powered by DC and lack the 60 Hz service frequency used for the ASC time base.
• Solo intersections: Constrains the clock to GNSS, crystal, or service frequency. Intersections lacking backhaul communications to a central station will not be synchronized by a time broadcast from the central station.

3.4. Extensions to the Standard

NTCIP 1202 v03 defines user needs and features for variety of signal controller features; however more experimental features are not yet standardized. These include the following:

• Traffic responsive and adaptive signal control algorithms: There are a variety of responsive and adaptive algorithms that are more experimental and have not yet been widely deployed enough to justify standardization
• CV-related applications: The industry has identified numerous connected vehicle applications that can be used to improve signal timing, promote better traffic management and/or traffic planning, and enhance traveler safety and mobility. However, the data interfaces for these applications are still experimental and have not yet been standardized

If your deployment wishes to use these features, it will need to develop an extension to the standards that define the data to be exchanged and project budgets should be developed in consideration of the specialized testing and integration efforts that will be required to implement these features.

3.5. Exception Reporting

Many traffic management systems are designed to allow central systems to monitor the detailed operation of traffic signals. This data can be used to run simulations and to perform analysis to optimize operations. Historically, this has resulted in many systems being designed to report the status of the signal (e.g., which phases are green) every second. However, agencies are discovering that there are alternate approaches to achieving their objectives.

Exception reporting is the NTCIP feature that allows an ASC to be configured to automatically report when user-defined conditions change in the field. For example, an ASC can be configured to report the new status of each signal phase whenever the status of any phase changes to green. This would typically result in six exception reports for a traditional eight-phase signal every cycle (i.e., assuming two phases turn green simultaneously when crossing a barrier); by comparison, reporting the status of every phase every second might require 120 messages (assuming a 120 second cycle). This can significantly reduce overhead on the communications network.

In addition, the exception reporting feature has a generic design that allows for the configuration of many other items of interest. For example, an ASC might also be configured to report when its cabinet door is opened or when other anomalous events occur.

4. Reference to Other Standards

• NTCIP, NTCIP 1103: Transportation Management Protocols (TMP) v03.52, NTCIP Joint Committee. December 2016
• International Organization for Standardization (ISO), ISO 15784-2:2015 Intelligent Transport Systems (ITS) - Data exchange involving roadside modules communication - Part 2: Centre to field device communication using SNMP, ISO TC 204. 2015
• ISO, ISO 20684 Intelligent transport systems Roadside modules SNMP data interface (all parts), ISO TC 204
• Institute of Transportation Engineers, ATC5201 Advanced Transportation Controller (ATC) Standard v06A.36. ATC Joint Committee, January 2020.
• Institute of Transportation Engineers, ATC 5202 Model 2070 Controller Standard v03.04 ATC Joint Committee, January 2013.
• Institute of Transportation Engineers, Advanced Transportation Controller (ATC) Cabinet Standard v02.02. ATC Joint Committee, March 2019.
• National Electrical Manufacturers Association, NEMA Standards Publication TS 2-2016 v03.07 Traffic Controller Assemblies with NTCIP Requirements. NEMA, 2016

5. Case Study: Anaheim

The City of Anaheim, California and the USDOT are funding a project that will develop test procedures for NTCIP 1202v03. The project was awarded March 2020 and expected to conclude by December 2021. It will involve the following:

• Development of test procedures for all requirements contained within NTCIP 1202 v03
• Testing of three vendors according to the developed test procedures
• Provision of software that performs the test procedures

The project is entitled NTCIP 1202 Standard Testing Project and has been assigned the account number 276-421-N849-4809 by the City.

6. Glossary

To include additional descriptions/acronyms used primarily in the module. List out in alphabetical order.

Term	Definition
Agency Specification	A document that has been prepared by an agency to define requirements for a subject item or process when procured by the agency.
API	Application Program Interface
ASC	Actuated Traffic Signal Controller
ATC	Advanced Transportation Controller
Compliance	A condition that exists when an item meets all of the requirements of an agency specification.
Concept of Operations	A document that describes the purpose for a system project, including a description of the current and proposed system, as well as key user needs that the new system is required to address.
Conformance	A condition that exists when an item meets all of the mandatory requirements as defined by a standard. It can be measured on the standard as a whole, which means that it meets all mandatory (and applicable conditional) requirements of the standard or on a feature level (i.e., it conforms to feature X as defined in section X.X.X), which means that it meets all mandatory (and applicable conditional) requirements of the feature.
CV	Connected Vehicle
DC	Direct Current
FLOPS	Floating Point Operations Per Second
GNSS	Global Navigation Satellite System; a generic term for what is often called Global Positioning System within the US.
Hz	Hertz
IP	Internet Protocol
ISO	International Organization for Standardization
ITE	Institute of Transportation Engineers
ITS	Intelligent Transportation Systems
MIB	Management Information Base
MIPS	Millions of Instructions Per Second
MNDOT	Minnesota Department of Transportation
Modem	Modulator / Demodulator
NEMA	National Electrical Manufacturers Association
NTCIP	National Transportation Communications for ITS Protocol
OS	Operating System
PRL	Protocol Requirements List
RTM	Requirements Traceability Matrix
SEP	Systems Engineering Process
SNMP	Simple Network Management Protocol
SPAT	Signal Phase and Timing
STMP	Simple Transportation Management Protocol
TMP	Transportation Management Protocols
USDOT	United States Department of Transportation
V2I	Vehicle to Infrastructure
V2V	Vehicle to Vehicle

7. References

• Minnesota Department of Transportation, How Locals Need to Prepare for the Future of V2V/V2I Connected Vehicles, MN/RC 2019-35, August 2019
• Federal Highway Administration, AASHTO Connected Vehicle Infrastructure Deployment Analysis, FHWA-JPO-11-090, June 17, 2011
• California Department of Transportation, Transportation Electrical Equipment Specification. Caltrans, March 12, 2009
• US Department of Transportation, Systems Engineering for Intelligent Transportation Systems, USDOT, January 2007
• NTCIP, NTCIP 1202 v03 Object Definitions for Actuated Signal Controllers (ASC) Interface, NTCIP Joint Committee, May 2019, https://www.ntcip.org/wp-content/uploads/2019/07/NTCIP-1202v0328A.pdf
• NTCIP, NTCIP 9001 NTCIP Guide, NTCIP Joint Committee, July 2009.

8. Study Questions

1. Which of the below is a waning technology that is not recommended for most new deployments?

1. Exception reporting
2. Block objects
3. STMP
4. None of the above

2. Which of the following most accurately expresses the state of connected vehicle (CV) support in the standard?

1. Does not address any CV functionality
2. Does not define sufficient security for CVs
3. Defines a secure solution for intersection maps
4. Defines a secure solution for signal timing

3. Which of the following is NOT true regarding an extension based on an open solution?

1. Documentation is made public
2. Cost of initial deployment may be higher
3. Delivered product needs to be tested against requirements
4. Likely to result in vendor lock-in

4. Which of the below is an appropriate way to test an ASC for conformance to NTCIP 1202 v03?

1. Using test procedures contained in Annex C of the standard
2. Using Anaheim test procedures (when available)
3. Connecting to system and see if it works
4. Trusting the vendor

9. Icon Guide

The following icons are used throughout the module to visually indicate the corresponding learning concept listed out below, and/or to highlight a specific point in the training material.

1) Background information: General knowledge that is available elsewhere and is outside the module being presented. This will be used primarily in the beginning of slide set when reviewing information readers are expected to already know.

2) Tools/Applications: An industry-specific item a person would use to accomplish a specific task and applying that tool to fit your need.

3) Remember: Used when referencing something already discussed in the module that is necessary to recount.

4) Refer to Student Supplement: Items or information that are further explained/detailed in the Student Supplement.

5) Example: Can be real-world (case study), hypothetical, a sample of a table, etc.

6) Checklist: Use to indicate a process that is being laid out sequentially.

↑ Return to top