Module 20: Application of Arterial Management/Transit Signal Priority Standards

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 20: Application of Arterial Management/Transit Signal Priority Standards

Table of Contents

Module Description - 2

Introduction/Purpose - 2

Samples/Examples - 2

Reference to Other Standards - 8

Case Studies - 8

Glossary - 8

References - 12

Study Questions - 13

Icon Guide - 14

1. Module Description

Transit managers look at transit signal priority (TSP) as a potential tool to improve schedule adherence and service reliability, and increase transit vehicle efficiency with minimal negative impacts to the full traffic network operations. Module 20 builds on previously developed two-part Arterial Management and Transit Signal Priority transit standards training modules (modules 8 and 9). Module 20 provides additional details on the standards that support signal control priority and how to use those standards to develop, specify, and test a TSP implementation.

2. Introduction/Purpose

As mentioned above, transit signal priority (TSP) is implemented in order to improve reliability, mobility, and safety on our roadways. 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.

Module 20, Application of Arterial Management and Transit Signal Priority Standards is a continuation of a series of modules on ITS standards for arterial management and transit signal priority. Module 8, Arterial Management and Transit Signal Priority Part 1 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. Module 9, Arterial Management Part 2 provides detailed information on how to identify and use applicable standards to procure and operate a SCP system following a systems engineering process. Module 20 provides additional details on the standards that support signal control priority and how to use those standards to develop, specify and test a TSP implementation. In addition, the module will present several case studies on how different agencies implemented their TSP projects. These case studies discuss some of the constraints that those implementations faced, the architecture that was selected to implement TSP, how the appropriate standards were used in those implementations and how testing was performed. This module will provide a case on how transit signal priority was implemented in a connected vehicle environment.

3. Samples/Examples

This section contains an example that traces to specific user needs, Determine Priority Request Criteria and Monitor the PRS, to the requirements that satisfies those user needs. The first table in this example, Table 1. Example PRL, identifies the traces between the user needs with the requirements selected to satisfy the user needs. The next table, Table 2. Example RTM, traces those selected requirements with the (standard) design that will fulfill those requirements. Finally, Table 3. Example Requirements to Test Case Traceability Table, traces the same selected requirements to the test cases that must be performed to verify that the requirement is fulfilled.

Portions of an example test design specification, test case specifications and test procedure specifications are also provided.

Visit www.ntcip.org for information on electronic copies of the MIBs, PRLs, and RTMs.

From NTCIP 1211 v02, Table 1 depicts a Protocol Requirements List (PRL) for User Needs 2.5.1.2, Determine Priority Request Criteria, and 2.5.1.3, Monitor the PRS only. For an actual project implementation, the complete PRL should be completed. Recall that the PRL traces a user need with the requirements that satisfy the user need, and can be used to indicate what features and requirements have been selected for the procurement specification. Table 1 indicates that user need 2.5.1.2 is to be supported to conform to the standard, so Yes is circled to indicate it is to be supported. Requirements 3.5.1.3.1, 3.5.1.3.2, and 3.5.1.3.3 are all mandatory and thus are also selected to satisfy user need 2.5.1.2. User need 2.5.1.3 is optional, but in this example, it is selected to be supported, and thus requirement 3.5.1.4, which is mandatory to satisfy user need 2.5.1.2 is also selected.

Table 1. Example PRL

Protocol Requirements List (PRL)
User Need ID	User Need	FR ID	Functional Requirement	Conformance	Support	Additional Specifications
2.5.1.2	Determine Priority Request Criteria			M	Yes
		3.5.1.3.1	Retrieve Priority Request Settings	M	Yes
		3.5.1.3.2	Retrieve Reservice Period for a Vehicle Class	M	Yes
		3.5.1.3.3	Retrieve Priority Request Time To Live Value	M	Yes
2.5.1.3	Monitor the PRS			O	Yes / No
		3.5.1.4 Monitor the Status of the PRS		M	Yes

This completed PRL can be used to indicate the items to be tested in a Test Design Specification. For this example, user need 2.5.1.3, Monitor the PRS, is an optional user need requirement but is selected for this implementation and thus should be included as a test item.

Based on the requirements selected, Table 2 depicts the (standard) design that will fulfill each requirement according to the NTCIP 1211 v02. For example, to fulfill requirement 3.5.1.3.1, the component/system must support dialog G.1 (SNMP GET) and support 5.1.27 prsProgramData.

Table 2. Example RTM

Requirements Traceability Matrix (RTM)
FR ID	Functional Requirement	Dialog ID	Object ID	Object Name	Additional Specifications
3.5.1.3	Retrieve Priority Request Server Settings
3.5.1.3.1	Retrieve Priority Request Settings
		G.1
			5.1.2.7	prsProgramData
3.5.1.3.2	Retrieve Reservice Period for a Vehicle Class
		G.1
			5.1.1.5	priorityRequestReserviceClass1Time
			5.1.1.6	priorityRequestReserviceClass2Time
			5.1.1.7	priorityRequestReserviceClass3Time
			5.1.1.8	priorityRequestReserviceClass4Time
			5.1.1.9	priorityRequestReserviceClass5Time
			5.1.1.10	priorityRequestReserviceClass6Time
			5.1.1.11	priorityRequestReserviceClass7Time
			5.1.1.12	priorityRequestReserviceClass8Time
			5.1.1.13	priorityRequestReserviceClass9Time
			5.1.1.14	priorityRequestReserviceClass10Time
3.5.1.3.3	Retrieve Priority Request Time To Live Value
		G.1
			5.1.1.3	priorityRequestTimeToLiveValue
3.5.1.4	Monitor the Status of the PRS
		G.1
			5.1.1.1	priorityRequestTable
			5.1.1.1.6	priorityRequestServiceStrategyNumber
			5.1.1.1.9	priorityRequestStatusInPRS
			5.1.1.1.12	priorityRequestTimeOfServiceDesiredInPRS
			5.1.1.1.13	priorityRequestTimeOfEstimatedDepartureInPRS
			5.1.1.2	prsBusy

Based on the requirements selected in Table 1, develop a Requirements to Test Case Traceability Table (RTCTT). The RTCTT defines every functional requirement in the procurement specification and the test case(s) that verifies that the requirement is fulfilled. If a requirement traces to more than one test case, all test cases that the requirement traces to must be passed to fulfill the requirement.

An example RTCTT is shown in Table 3. In this example, test case IDs C.1.3.3.1 AND C.1.3.3.2 must be successfully performed to verify that Requirement 3.5.1.3.3, Retrieve Priority Request Time To Live Value has been fulfilled.

Table 3. Example Requirements to Test Case Traceability Table

Req ID (Vol. I)	Requirement	Test Case ID	Test Case Title
3.5.1.3.1	Retrieve Priority Request Settings
		C.1.3.1	TC-Retrieve Priority Request Settings
3.5.1.3.2	Retrieve Reservice Period for a Vehicle Class
		C.1.3.2	TC-Retrieve Reservice Period
3.5.1.3.3	Retrieve Priority Request Time To Live Value
		C.1.3.3.1	TC-Retrieve Priority Request TTL Value-No Error
		C.1.3.3.2	TC-Retrieve Priority Request TTL Value-Error
3.5.1.4	Monitor the Status of the PRS
		C.1.4.1	TC-PRS Status-NoError
		C.1.4.2	TC-PRS Status-Error

The example RTCTT can then become part of a Test Design Specification (See ITS Standards Training Module 9: T201: How to Write a Test Plan, for an explanation of a Test Design Specification). An example Test Design Specification is shown in Table 4.

Table 4. Example Test Design Specification

Test Design Specification
ID: TD-PRS-01		Title: Manage the PRS
Approach Refinement:		Automated test scripts will be used Communications configuration tables
Features to be Tested			Test Identification
ID	Title		ID Title
3.5.1.3.1	Retrieve Priority Request Settings
			C.1.3.1 TC-Retrieve Priority Request Settings
3.5.1.3.2	Retrieve Reservice Period for a Vehicle Class
			C.1.3.2 TC-Retrieve Reservice Period
3.5.1.3.3	Retrieve Priority Request Time To Live Value
			C.1.3.3.1 TC-Retrieve Priority Request TTL Value-No Error
			C.1.3.3.2 TC-Retrieve Priority Request TTL Value-Error
3.5.1.4	Monitor the Status of the PRS
			C.1.4.1 TC-PRS Status-NoError
			C.1.4.2 TC-PRS Status-Error
Feature Pass-Fail Criteria			This test design is passed if: 1) all test cases are passed; and 2) the data content of dialog responses are verified to be correct against the NTCIP 1211 v02.24.

An example Test Case Specification is provided in Table 5.

Table 5. Example Test Case Specification

Test Case Specification
ID: C.1.4.1	Title: TC-PRS Status-NoError
Test Items	REQ 3.5.1.4 - Monitor the Status of the PRS
Input Specifications	TCI-PRS-04 - Monitor the PRS Status (No Error)
Output Specifications	TCO-PRS-04 - Monitor the PRS Status (No Error) Perform TPS-PRS-04
Environmental Needs	No additional needs outside of those specified in the test plan
Special Procedure Requirements	None
Intercase Dependencies	None

Table 6. Example Test Procedure Specification

Test Procedure Specification
ID: TPS-PRS-04		Title: Monitor the PRS Status
Purpose		This test procedure verifies that the PRS allows a management station to determine the status of the PRS and that the dialog is implemented correctly. It tests when a management stations sends a GET is sent to a PRS, that the PRS responds with the proper objects.
Special Requirements		None
Preconditions
None.
Step	Test Procedure		Results	References
1	CONFIGURE: Determine the number of priority requests required by the specification (PRL 3.6.2.1). RECORD this information as: >>Required_Priority_Requests
2	FOR EACH value, N, from 1 to Required_Priority_Requests, perform Steps 2.1 through 2.13.
2.1	GET the following object(s): » priorityRequestServiceStrategyNum ber.N » priorityRequestStatusInPRS.N » priorityRequestTimeOfServiceDesiredInPRS.N » priorityRequestTimeOfEstimatedDepartureInPRS.N
2.2	VERIFY that the RESPONSE VALUE for priorityRequestServiceStrategyNumber.N is greater than or equal to 0.		Pass / Fail	Section 5.1.1.1.6
2.3	VERIFY that the RESPONSE VALUE for priorityRequestServiceStrategyNumber.N is less than or equal to 255.		Pass / Fail	Section 5.1.1.1.6
2.4	VERIFY that the RESPONSE VALUE for priorityRequestServiceStrategyNumber.N is APPROPRIATE.		Pass / Fail	Section 5.1.1.1.6
2.5	VERIFY that the RESPONSE VALUE for priorityRequestStatusInPRS.N is greater than or equal to 1.		Pass / Fail	Section 5.1.1.1.9
2.6	VERIFY that the RESPONSE VALUE for priorityRequestStatusInPRS.N is greater than or equal to 15.		Pass / Fail	Section 5.1.1.1.9
2.7	VERIFY that the RESPONSE VALUE for priorityRequestStatusInPRS.N is APPROPRIATE.		Pass / Fail	Section 5.1.1.1.9
2.8	VERIFY that the RESPONSE VALUE for priorityRequestTimeOfServiceDesiredInPRS.N is greater than or equal to 0.		Pass / Fail	Section 5.1.1.1.12
2.9	VERIFY that the RESPONSE VALUE for priorityRequestTimeOfServiceDesiredInPRS.N is greater than or equal to 4294967295.		Pass / Fail	Section 5.1.1.1.12
2.10	VERIFY that the RESPONSE VALUE for priorityRequestTimeOfServiceDesiredInPRS.N is APPROPRIATE.		Pass / Fail	Section 5.1.1.1.13
2.11	VERIFY that the RESPONSE VALUE for priorityRequestTimeOfEstimatedDepartureInPRS.N is greater than or equal to 0.		Pass / Fail	Section 5.1.1.1.13
2.12	VERIFY that the RESPONSE VALUE for priorityRequestTimeOfEstimatedDepartureInPRS.N is greater than or equal to 4294967295.		Pass / Fail	Section 5.1.1.1.13
2.13	VERIFY that the RESPONSE VALUE for priorityRequestTimeOfEstimatedDepartureInPRS.N is APPROPRIATE.		Pass / Fail	Section 5.1.1.1.12
3	GET the following object(s): >>prsBusy.0		Pass / Fail	(PRL 3.6.2.1)
4	VERIFY that the RESPONSE VALUE for prsBusy is APPROPRIATE.		Pass / Fail	Section 5.1.1.2
Test Procedure Results
Tested By: Test Date:				Pass / Fail
Test Notes:

4. Reference to Other Standards

• NTCIP 9001 Version v04, National Transportation Communications for ITS Protocol, The NTCIP Guide. Washington, DC: AASHTO/ITE/NEMA, July 2009.
• NTCIP 9012 Version 01.27, NTCIP Testing Guide for Users. Washington, DC: AASHTO/ITE/NEMA, 2009.
• NTCIP 1211 Version v02.24, National Transportation Communications for ITS Protocol, Object Definitions for Signal Control and Prioritization (SCP) v02.24. Washington, DC: AASHTO/ITE/NEMA, September 2014.
• APTA TCIP-S-001 4.1.0, APTA Transit Communications Interface Profiles. Washington, DC: American Public Transportation Association. http://www.aptatcip.com/- content is no longer available.
• SAE J2735_201603, Dedicated Short Range Communications (DSRC) Message Set Dictionary. SAE International, March 2016. http://standards.sae.org/j2735 201603/- content is no longer available.
• IEEE 829-2008 - IEEE Standard for Software and System Test Documentation. New York, NY: IEEE, July 18, 2008. https://standards.ieee.org/ieee/829/3787/

5. Case Studies

Transit Signal Priority (TSP): A Planning and Implementation Handbook. Washington, DC: ITS America, May 2005.

http://nacto.org/docs/usdg/transit signal priority handbook smith.pdf- content is no longer available.

6. 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.
National Transportation Communications for ITS Protocol	A family of standards that provides both the rules for communicating (called protocols) and the vocabulary (called objects) necessary to allow electronic traffic control equipment from different manufacturers to operate with each other as a system.
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 a DMS or can be used by a manufacturer to document the features supported by their 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 the requirements to the corresponding dialogs and objects.
Reservice	Support for consecutive priority service requests of the same type.
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.
Standards	Set of criteria, guidelines, and best practices.
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)
Test Case	Documentation specifying inputs, predicted results, and a set of execution conditions for a test item. [IEEE Std 829-2008]
Test Design Specification	Documentation specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests. [IEEE Std 829-2008]
Test Documentation	Documentation describing plans for, or results of, the testing of a system or component. Types include test case specification, test incident report, test log, test plan, test procedure, and test plan.
Test Item	A software of system item that is an object of testing. [IEEE Std 829-2008]
Test Log	A chronological record of relevant details about the execution of tests.
Test Plan	A document describing the scope, approach, resources, and schedule of intended test activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. [IEEE Std 829-2008]
Test Procedure	Documentation that specifies a sequence of actions for the execution of a test. [IEEE Std 829-2008]
Test Summary Report	A document summarizing testing activities and results. It also contains an evaluation of the corresponding test items.
Transit Communications Interface Profiles	Standardizes data exchange to promote interoperability between transit system components.
Transit Signal Priority	A subset of Signal Control Priority focusing on transit fleet vehicles.
User Needs	The original basis for building a system. What is the system needed for? Systems provide functions, such as mobility for example.
Validation	Confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled. [ISO 9000: 2000]
Verification	Confirmation, through the provision of objective evidence, that specified requirements have been fulfilled. [ISO 9000:2000]

Acronyms

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

RTCTT - Requirements to Test Case Traceability Table

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

7. References

• "Building Quality Intelligent Transportation Systems Through Systems Engineering" prepared for Intelligent Transportation Systems. Joint Program Office U.S. Department of Transportation by Mitretek Systems, Inc., FHWA-OP-02-046, April 2002. Available online at: http://ntl.bts.gov/lib/jpodocs/repts te/13620.html.- content is no longer available. Accessed March 23, 2011.
• Li, Y., Koonce, P., Li, M., Zhou, K., Li, Y., et al., Transit Signal Priority Research Tools. U.S. Department of Transportation, Federal Transit Administration, May 2008. http://www.dot.ca.gov/newtech/researchreports/reports/2008/tsp research tools final report.pdf- content is no longer available.
• Systems Engineering Guidebook for Intelligent Transportation Systems Version 3.0. U.S. Department of Transportation, Federal Highway Administration, California Division. November 2009. https://www.fhwa.dot.gov/cadiv/segb/
• Systems Engineering Handbook - A Guide for System Life Cycle Processes and Activities, Version 3.2. Seattle, WA: INCOSE, 2010.

Chicago, IL

• Regional Transportation Authority Mapping and Statistics: Transit Signal Priority: http://www.rtams.org/rtams/transitSignalPriority.jsp.- content is no longer avaiable. Accessed July 25, 2016.
• URS Corporation, Concept of Operations for the Regional Transit Signal Priority Implementation Program (RTSPIP), Version 1.3. Minneapolis, MN: URS Corporation, April 29, 2013. http://www.rtams.org/pdf/planning/TSP/TSP%20ConOps%20Version%20L3.pdf- content is no longer available.
• URS Corporation, Technical System Requirements for the Regional Transit Signal Priority Implementation Program (RTSPIP), Version 2.4. Minneapolis, MN: URS Corporation, May 8, 2014. http://www.rtams.org/pdf/planning/TSP/FINAL%20Technical%20System%20Requirements Vers ion%202%204.pdf- content is no longer available.

King County (Seattle), WA

• Toone, John, King County Metro RapidRide ITS: Technology Review and Lessons Learned. Portland, OR: Presentation at the APTS Spring 2015 ITS Best Practices Workshop, April 2015. http://www.apta.com/mc/its/previous/2015-april/presentations/Presentations/King%20County%20Metro%20RapidRide%20ITS%20Technology%20Review%20and%20Lessons%20Learned%20-%20John%20Toone.pdf- content is no longer available.
• Toone, John, King County Metro RapidRide: Transit Signal Priority in a Connected Vehicles Environment. Washington, DC: Presentation at the Transportation Research Board, Traffic Signal Systems Committee (AHB25), Summer Meeting 2013. http://www.signalsystems.org.vt.edu/documents/July2013AnnualMeeting/Toone Metro TSP T RB2013.pdf- content is no longer available.

Multi-Modal Intelligent Traffic Signal Systems (MMITSS)

• University of Arizona, et al., MMITSS Final ConOps - Concept of Operations, Version 3.1 (Updated Final Submission), December 4, 2012. http://www.cts.virginia.edu/wp-content/uploads/2014/05/Task2.3. CONOPS 6 Final Revised.pdf- content is no longer available.
• University of Arizona, et al., Multi-Modal Intelligent Traffic Signal System - Final System Requirements Document V4.0, March 7, 2012. http://www.cts.virginia.edu/wp-content/uploads/2014/05/Task3. SyRS 4 PostSubmittal V3.pdf- content is no longer available.
• University of Arizona, et al., Multi-Modal Intelligent Traffic Signal System - System Design Version 1.1, June 16, 2015.
• Multi-Modal Intelligent Traffic Signal System (MMITSS) Impacts Assessment - Final Report. US Department of Transportation, FHWA-JPO-15-238, August 19, 2015.

New York City, NY

• Rausch, Robert, Deployment of Transit Signal Priority Without the Costly Local Infrastructure. Orlando, FL: Presentation at the 18^th ITS World Congress, 18^th October 2011.
• TransCore. NYC ITS Case Study. https://www.transcore.com/sites/default/files/NYC Case%20Study.pdf.- content is no longer available. Accessed July 25, 2016.
• Rausch, Robert, Transit Signal Priority: US Standards and Implementation. Presentation. Date and time unknown.

Professional Capacity Building (PCB) Modules on Arterial Management and Transit Signal Priority

• 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 StandardsTraining/Modules.aspx?Year1Transit=1&ModuleID=63#mod63
• Module 9: Arterial Management and Transit Signal Priority: Specifying Requirements for Signal Control Priority (SCP) Based on NTCIP 1211 Standard, Part 2 of 2. StandardsTraining/Modules.aspx?Year1Transit=1&ModuleID=64#mod64

PCB Modules on TCIP and Integrated Corridor Management (ICM)

• Module 3: Transit Communications Interface Profiles (TCIP), Part 1 of 2: Introduction to the Standard and Transit Architectures. StandardsTraining/Modules.aspx?Year1Transit=1&ModuleID=58#mod58
• Module 4: Transit Communications Interface Profiles (TCIP), Part 2 of 2: Structure and Elements of TCIP—Accessing TCIP via TIRCE and TCIP Tools. StandardsTraining/Modules.aspx?Year1Transit=1&ModuleID=59#mod59

PCB Modules on ITS Standards Testing

• Module 5: T101: Introduction to ITS Standards Testing. StandardsTraining/Modules.aspx?ModuleID=15#mod15
• Module 9: T201: How to Write a Test Plan StandardsTraining/Modules.aspx?ModuleID=19#mod19
• Module 13: T202: Overview of Test Design Specification, Test Cases, and Test Procedures StandardsTraining/Modules.aspx?ModuleID=30#mod30
• Module 41. T203: Part 1 of 2: How to Develop Test Cases for an ITS Standards-based Test Plan StandardsTraining/Modules.aspx?ModuleID=69#mod69
• Module 46. T203: Part 2 of 2: How to Develop Test Cases for an ITS Standards-based Test Plan StandardsTraining/Modules.aspx?ModuleID=73#mod73
• Module 47: T204: Part 1 of 2: How to Develop Test Procedures for an ITS Standards-based Test Plan StandardsTraining/Modules.aspx?ModuleID=78#mod78
• Module 48: T204: Part 2 of 2: How to Develop Test Procedures for an ITS Standards-based Test Plan StandardsTraining/Modules.aspx?ModuleID=79#mod79

PCB Modules on Connected Vehicles

• Connected Vehicles 101 - Introduction https://www.its.dot.gov/pcb/documents/Connected Vehicles 101.pdf- content is no longer available.
• Connected Vehicles 102 - Applications and Planning for Implementation https://www.its.dot.gov/pcb/documents/Connected Vehicles 102.pdf- content is no longer available.
• Module 11: Transit and the Connected Vehicle Environment/Emerging Technologies, Applications, and Future Platforms StandardsTraining/Modules.aspx?Year1Transit=1&ModuleID=66#mod66
• Module 43: Vehicle-to-Infrastructure (V2I) ITS Standards for Project Managers StandardsTraining/Modules.aspx?ModuleID=68#mod68

8. Study Questions

To include the quiz/poll questions and answer choices as presented in the PowerPoint slide to allow students to either follow along with the recording or refer to the quiz at a later date in the supplement.

1. Which of the following is NOT a reason to perform testing?

1. To identify bugs or errors so they can be corrected
2. To verify the system fulfills the requirements of the specification
3. To validate the right system was built
4. To check a box that we did it

2. Which ITS standard defines the messages and data elements for a connected vehicle environment?

1. NTCIP 1211 v02
2. SAE J2735
3. TCIP
4. NTCIP 1103

3. Which of the below is not a benefit of using TSP in ICM?

1. Decrease travel times
2. Improve travel time reliability
3. Improve the quality of transit data collected
4. Improve the throughput and use of transit capacity

4. How can the ITS standards be used in TSP implementations?

1. Extensions to an ITS standard can be used to satisfy a need not supported by the ITS standards
2. NTCIP 1211 v02, TCIP and SAE J2735 must be used in TSP implementations to conform to TSP standards
3. All messages and objects defined in the standard must be used to conform
4. An implementation is allowed to support only one of the system architectures defined in the standard

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.