ITS Transit Standards Professional Capacity Building Program

Module 9: Arterial Management and Transit Signal Priority: Specifying Requirements for Signal Control Priority (SCP) Based on NTCIP 1211 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.)

Module 9: Arterial Management and Transit Signal Priority: Specifying Requirements for Signal Control Priority (SCP) Based on NTCIP 1211 Standard, Part 2 of 2

Table of Contents

Introduction/Purpose - 2

Basic Overview - 2

Samples/Examples - 2

Reference to Other Standards - 4

Case Studies - 5

Glossary - 5

References - 7

Study Questions - 8

Module Description

This module is the second of two modules introducing Intelligent Transportation Systems (ITS) Transit Standards for improving transit service along arterials, with a focus on transit signal priority. The first part of this two-part module is Module 8: Arterial Management and Transit Signal Priority: Understanding User Needs for Signal Control Priority (SCP) Based on NTCIP 1211 Standard, Part 1 of 2.

1. Introduction/Purpose

Transit managers are looking at transit signal priority as a potential tool to improve schedule adherence, improve transit vehicle efficiency, make transit service more reliable, and improve transit vehicle travel times with minimal negative impacts to normal traffic operations. Signal Control Priority (SCP) is an operational strategy that provides preferential treatment (priority) to facilitate the movement of fleet vehicles, such as transit, emergency service, and commercial fleets, through signalized intersections.

This module (Arterial Management and Transit Signal Priority: Specifying Requirements for Signal Control Priority (SCP) Based on the NTCIP 1211 Standard) is the second of a two-module set in arterial management. The first module provides the background for understanding the standards that facilitate arterial management by describing how an SCP system works, introducing the capabilities offered by an SCP system, and identifying the role of standards in an SCP system.

This module builds on the content of Module 8 and provides participants with detailed information on how to identify and use applicable ITS standards to procure and operate a signal control priority system following a systems engineering process. This module focuses on using the NTCIP 1211 -Object Definitions for Signal Control and Prioritization Standard and assists the user in specifying the requirements of an SCP system using the tools (Protocol Requirements List, Requirements Traceability Matrix) provided within the standard. The participant will also be introduced to how information is exchanged between the components of the SCP system using the NTCIP 1211 standard and how to specify features that are not supported by the NTCIP 1211 standard for its SCP procurement.

This module also continues the development of the case study introduced in Module 8, demonstrating how to specify requirements based on the architecture and features that were selected in Module 8 using the tools (PRL, RTM) provided in the NTCIP 1211 standard. The case study also demonstrates how the PRL table integrates into the procurement specification.

2. Samples/Examples

The following is a complete list of the requirements identified in NTCIP 1211 v02.

3.4 Architectural Requirements

3.4.1 Support Communications From Multiple Entities

3.4.1.1 Provide Data

3.4.1.2 Receive Data

3.4.1.3 Explore Data

3.5 Data Exchange and Operational Environment Requirements

3.5.1 Interface - Management Station to PRS

3.5.1.1 Set Reservice Period

3.5.1.2 Set Time To Live Period

3.5.1.3 Retrieve Priority Request Server Settings

3.5.1.3.1 Retrieve Priority Request Settings

3.5.1.3.2 Retrieve Reservice Period for a Vehicle Class

3.5.1.3.3 Retrieve Priority Request Time To Live Value

3.5.1.4 Monitor the Status of the PRS

3.5.2 Interface - Management Station to CO

3.5.2.1 Configure the CO

3.5.2.1.1 Set Priority Strategy Configuration

3.5.2.1.2 Define Default Coordination Pattern

3.5.2.1.3 Define Maximum Priority Strategies Supported

3.5.2.1.4 Define Maximum Service Requests To Consider

3.5.2.2 Retrieve Priority Strategy Configuration

3.5.2.2.1 Retrieve Priority Strategy Settings

3.5.2.2.2 Retrieve Priority Strategies

3.5.2.2.3 Retrieve Priority Splits

3.5.2.2.4 Retrieve Default Coordination Pattern

3.5.2.2.5 Retrieve Maximum Priority Strategies Supported

3.5.2.2.6 Retrieve Maximum Service Requests to Consider

3.5.2.3 Monitor the Status of the CO

3.5.3 Interface - PRG to PRS

3.5.3.1 Receive Priority Requests

3.5.3.1.1 Initiate a Priority Request

3.5.3.1.2 Send a Priority Request Update

3.5.3.1.3 Send a Cancel Priority Request

3.5.3.1.4 Send a Clear Priority Request

3.5.3.1.5 Initiate a Priority Request - NTCIP 1211 v01

3.5.3.1.6 Send a Priority Request Update - NTCIP 1211 v01 3.5.3.2 Receive Priority Request Status

3.5.4 Interface - PRS to CO

3.5.4.1 Exchange Service Request

3.5.4.2 Exchange Service Request Status

3.6 Supplemental Non-Communications Requirements

3.6.1 Response Time for Requests

3.6.2 Process Priority Requests

3.6.2.1 Support Multiple Priority Requests

3.6.2.2 Clear Expired Priority Requests

3.6.2.3 Support Multiple Priority Requests - NTCIP 1211 v01

3.6.3 Process Service Requests

3. Reference to Other Standards

4. Case Studies

Actual case studies can be found in Transit Signal Priority (TSP): A Planning and Implementation Handbook: ITS America, May 2005. https://nacto.org/docs/usdg/transit_signal_priority_handbook_smith.pdf

5. Glossary

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.
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.
Coordinator A logical device or program/routine that provides coordination. An integral part of a Traffic Signal Controller.
Dialogs A sequence of information or message exchanges.
Interchangeability A condition that exists when two or more items possess such functional and physical characteristics as to be equivalent in performance and durability and are capable of being exchanged one for the other without alteration of the items themselves, or adjoining items, except for adjustment and without selection for fit and performance.
Interoperability The ability of two or more systems or components to exchange information and use the information that has been exchanged.
Management Station Defined as a computing platform that manages NTCIP field components, such as a PRS or a CO. A management station may be a traffic management center or a maintenance laptop that a field technician may use on a trip to visit the component.
Preemption Per NTCIP 1202:2005, the transfer of the normal control (operation) of traffic signals to a special signal control mode for the purpose of servicing railroad crossings, emergency vehicle passage, mass transit vehicle passage, and other special tasks, the control of which requires terminating normal traffic control to provide the service needs of the special task.
Priority The preferential treatment of one vehicle class (such as a transit vehicle, emergency service vehicle, or a commercial fleet vehicle) over another vehicle class at a signalized intersection without causing the traffic signal controllers to drop from coordinated operations. Note: Priority may be accomplished by a number of methods, including changing the beginning and end times of greens on identified phases, changing the phase sequence, or inclusion of special phases, without interrupting the general timing relationship between specific green indications at adjacent intersections.
Priority Request The information that describes a need for priority service based upon user-defined criteria (such as the number of minutes behind schedule, vehicle occupancy levels, vehicle class, etc.). Note: A priority request is sent from a Priority Request Generator to a Priority Request Server.
Priority Request Generator A logical or physical entity that initiates a priority request.
Priority Request Server A logical or physical entity that manages and prioritizes one or more service requests.
Protocol Requirements List A table mapping user needs with their associated requirements. This table allows procurement personnel to specify the desired features of dynamic message signs (DMS) or it can be used by a manufacturer to document the features supported by its implementation.
Requirement A condition or capability needed by a user to solve a problem or achieve an objective.
Requirements Traceability Matrix A table that links requirements to the corresponding dialogs and objects.
Service Request The information that describes a priority service to be processed by the Coordinator within a Traffic Signal Controller. Note: A service request is sent between a Priority Request Server and a Traffic Signal Controller.
Signal Control Priority An operational strategy that provides preferential treatment (priority) to facilitate the movement of fleet vehicles through signalized intersections.
Systems Engineering An interdisciplinary approach and means to enable the realization of successful systems (INCOSE). An interdisciplinary collaborative approach to derive, evolve, and verify a life cycle balanced system solution that satisfies customer expectations and meets public acceptability (IEEE).
Transit Signal Priority A subset of Signal Control Priority focusing on transit fleet vehicles.

AASHTO - American Association of State Highway and Transportation Officials
APTA - American Public Transportation Association
CAD/AVL - Computer Aided Dispatching/Automatic Vehicle Location
CO - Coordinator
ITE - Institute of Transportation Engineers
ITS - Intelligent Transportation Systems
MIB - Management Information Base
NEMA - National Electrical Manufacturers Association
NTCIP - National Transportation Communications for ITS Protocol
OID - Object IDentifier
PRL - Protocol Requirements List
PRG - Priority Request Generator
PRS - Priority Request Server
PTV - Public Transit Vehicle
RTM - Requirements Traceability Matrix
SCP - Signal Control Priority
SNMP - Simple Network Management Protocol
TCIP - Transit Communications Interface Profiles
TMC - Traffic Management Center
TMDD - Traffic Management Data Dictionary
TSP - Transit Signal Priority

6. References

Transit Signal Priority

Systems Engineering

7. Study Questions

1. What can the PRL NOT be used for?

  1. Specify the standard
  2. Map user needs to requirements
  3. Identify the user needs supported by the standard
  4. Identify the most qualified vendor

2. Which of the following elements is NOT a purpose of the PRL?

  1. Associate user needs with requirements
  2. Specify the requirements for a specific project
  3. Determine which objects to use
  4. Determine the minimum requirements for conformance

3. Which of the following are not part of the RTM?

  1. User needs supported by the standard
  2. Requirements supported by the standard
  3. Standardized dialogs to fulfill requirements
  4. Data objects to fulfill requirements

4. What does the following table mean?

  1. To fulfill 3.5.2.2.3, use all objects
  2. To fulfill 3.5.2.2.3, use one of the objects
  3. To fulfill 3.5.2.2.3, use dialog G.1 and all objects
  4. To fulfill 3.5.2.2.3, use dialog G.1 and one object

5. Which of the following is a reason to extend a standard?

  1. There is an unmet need that justifies the added cost
  2. The existing system uses a nonstandard design
  3. To develop a specification to favor a specific vendor
  4. The standardized solution is too complex