Module 25 - A304b
A304b: Specifying Requirements for Field Management Stations - Part 1 Object Definitions for Signal System Masters (SSM) Based on NTCIP 1210 Standard
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.)
(Extended Text Description: Large graphic cover page with dark blue background with the title in white letters "A304b: Specifying Requirements for Field Management Stations - Part 1 Object Definitions for Signal System Masters (SSM) Based on NTCIP 1210 Standard." At the middle left is the "Standards ITS Training" logo with a white box and letters in blue and green. The words "Student Supplement" and "RITA Intelligent Transportation Systems Joint Program Office" in white lettering are directly underneath the logo. Three light blue lines move diagonally across the middle of the blue background.)
A304b: Specifying Requirements for Field Management Stations -Part 1: Object Definitions for Signal System Masters (SSM) Based on NTCIP 1210 Standard
Table of Contents
This is the final module of the acquisition curriculum path to procure Signal System Masters (SSM) with I101, A101, A102, A201, C101, and A304a being the prerequisites. The logical next step for the participant after taking this module is to consider modules in the testing life cycle—T101, T201, and T202—which lead up to the potential T304 Applying Your Test Plan to the NTCIP 1210 SSM Standard.
This module provides participants with information on how to identify their user needs for an SSM. An SSM is a type of Field Management Station (FMS) that is used to manage traffic signal controllers.
Signal System Master user need and requirement identification is based on what the user is seeking to accomplish; this task has been simplified with the introduction of a standardized Concept of Operations as documented in NTCIP 1210, which follows the Systems Engineering Process (SEP). This document provides the user with a Protocol Requirements List (PRL), which provides an easy checklist of all user needs and requirements and can be included in procurement specifications.
2. Additional Specifications
NTCIP 1210 is a version 1 standard that contains a number of known potential issues. We identify each of these in the following clauses and offer sample specification wording that may be used to work around these issues. Notes to the preparer of the specification are shown in italics and are offset by chevrons (“<<” and “>>”). The normal text in each clause represents the sample wording that could be included in a specification to address the issue.
NOTE: The sample specification text provided in this supplement does not have any formal standing and has not gone through the formal industry peer-review process required for standardization. The text is merely offered for your consideration.
The predicate table shown in Clause 22.214.171.124 of NTCIP 1210 contains incorrect references, which shall be interpreted with the following corrections for this procurement:
(Extended Text Description: This table contains the following data:
The “Conformance” column of the PRL contains a circular reference, which shall be interpreted with the following corrections for the purposes of this procurement:
3. Response Time
<<NTCIP 1210 references the phrase "Response Start Time" in several locations, including the PRL, but the term is never formally defined in the standard. In order to avoid any potential issues with this ambiguity, the following clause can be added to a specification.>>
For the purposes of this specification, the phrase "Response Start Time" in NTCIP 1210 shall be interpreted to have the same meaning as "Response Time" in NTCIP 1103, namely:
<<As stated on Slide 41 in the presentation, the specification should contain a filled out version of the PRL. The text below provides an introduction for this purpose.>>
The SSM shall conform to NTCIP 1210 and to the items selected in the following Protocol Requirements List (PRL).
<< Insert the standard PRL as contained in NTCIP 1210 with the appropriate options in the “Support” column selected and all blanks in the “Additional Specifications” column filled in. >>
5. Range Specifications
<<The standard allows implementations to sub-range any object. This could result in a potential issue if an implementation fails to support a value that the agency expects to use. This can be addressed in the specification with a general statement that requires support of all standardized values, except as noted in explicit range specifications. The range specifications could be shown in the filled out PRL above or in a separate table as shown below. In either case, a general statement would be needed as follows: >>
The SSM shall support all standardized values for all supported control and parameter objects and all appropriate values for all supported status objects, except as indicated within the following compressed version of the PRL that only shows rows where range specifications apply.
<< Rows that do not apply to your procurement in the following table can be deleted. All blanks should be filled in based on project needs. >>
<<As discussed in the presentation, the "PMPP Routing" feature defined in NTCIP 1210 has a potential issue in that the SSM may overwrite responses to an SSL command before the TMS is able to retrieve the response. We offer three possible work-around that you may wish to consider to resolve this potential issue below.>>
2.6.1. IP Routing
<<The first defined work-around is to use IP routing; users should be aware that this requires more bandwidth, but it avoids using the "PMPP Routing" feature.>>
The SSM shall support IP-based routing as defined in NTCIP 2202.
2.6.2. Command Routing
<<The second defined work-around is to use the command routing feature. Filling out the PRL will automatically require support of this feature, but it will only support commands for setting time, setting sync control, setting timing patterns, setting special functions, getting status, and getting volume and occupancy (as selected in the PRL). If you need additional commands (e.g., uploading and downloading database), you will need to support another work-around.>>
2.6.3. Refined Interpretation
<<The third work-around offered for consideration is to refine the interpretation of the "PMPP Routing" feature. NTCIP defines two transport level standards, the Internet Transport Profile (ITP), and Transportation Transport Profile (TTP). If ITP is used, the "PMPP Routing" feature is not needed; messages can be routed directly using IP. However, if TTP is used, the "PMPP Routing" feature is needed and we need to resolve the potential issue of the response being overwritten.
Our proposed work-around is to require the SSM to parse the TTP header and only store incoming packets that the TTP header indicates may be a response to the associated command. As long as the TMS properly uses the command field, the sslResponse should only contain valid responses to the associated command.>>
<<The following could be used in procurements for SSMs>>
The SSM shall support the Transportation Transport Profile (TTP) as defined in NTCIP 2201.
NTCIP 1210 defines sslResponse as follows:
The phrase "ALL responses" in this definition shall be interpreted to mean:
The sslNumber shall be interpreted as written, meaning that the sslNumber shall indicate the intersectionNumber of the SSL for the first 62 intersections and sslNUmber 63 will mean all intersections on all subnet connections. Any SSL with an intersectionNumber greater than 62 shall be unreachable with PMPP Routing except for broadcast commands.
<<The following could be used in procurements for TMSs controlling SSMs>>
When setting the value of sslCommand, the TMS shall use the Transportation Transport Profile (TTP) encapsulation method 2 (i.e., including port numbers), as defined in NTCIP 1201 Clause 2.2.3, unless the command is a STMP GetRequest. The lower order byte of the source port number shall equal the row number of the command (i.e., sslMsgRoutedNumber) and the destination port number shall be the port number for the destination protocol in the SSL. STMP GetRequests may use either encapsulation method 1 or encapsulation method 2.
The TMS shall not attempt to use PMPP Routing for any SSL with an assigned intersectionNumber greater than 62.
7. Requirements Traceability
<<The RTM contains several references to Groups of objects. For example, Requirement 126.96.36.199 Explore SSL Data by the TMS is traced to the "5.7 Group." This is not formally defined anywhere and may result in an ambiguity. To resolve this potential issue, the following text could be added to a specification:>>
Any Object Reference in the RTM that indicates a "Group" shall be interpreted as if the Group reference was replaced with a listing of all accessible objects that are defined in the referenced clause and all recursive sub clauses. For example, the Object Reference for "5.7 Group" shall be interpreted to include formal references to all objects defined in clauses:
3. Reference to Other Standards
Field Management Systems
4. Case Studies
There are no known current deployments of NTCIP 1210. Those deploying this standard should work closely with industry experts, as the first attempt to deploy any standard is likely to reveal issues that should be coordinated with the standards efforts.
To include additional descriptions/abbrs used primarily in the module.
7. Study Questions
1. Which of the following is not a major group of requirements in NTCIP 1210?
2. Where is a list of additional specifications to consider for NTCIP 1210 deployments?
3. When should a requirement with a conformance “Threshold:M” be selected?
4. What does the following table mean?
5. What types of messages does the standard allow to be sent to the SSL using the sslComand feature?
6. Which of the following is the best reason to extend a standard?