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:


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:

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:

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:

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

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.

Author's relevant description: Processor Capability Timeline: This chart shows a 2012 projection of the percentage of controller deployments from 2011 through 2020 that was developed as a part of the previous version of this course. In 2011, there were just over 300,000 signal controllers in the US and roughly 200,000 of these were in need of replacement to support connected vehicle applications (i.e., legacy controllers) while 100,000 of the controllers were technologically ready. The three lines (total, in need of replacement, and technologically-ready) continue across in a mostly linear fashion until 2018 when there are a total of roughly 340,000 controllers, all of which are shown as technologically-ready. The table is supplemented by text indicating that, at least in Minnesota, in 2019, that this projection has been largely validated as there are only 5% of legacy controllers remaining.

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 object1 converting the phase change information from local (i.e., signal controller) time into a time synchronized with the Global Navigation Satellite System (GNSS).2 This also results in a very accurate time (50 milliseconds) as a by-product.

1 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

2 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:

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:

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:

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


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:

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


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.

Background information icon indicates general knowledge that is available elsewhere and is outside the module being presented.

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

Tools/Applications icon. 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.

Remember icon. 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.

Supplement icon indicating 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.

Example icon. 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.

Checklist icon used to indicate a process that is being laid out sequentially.

↑ Return to top