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
Introduction/Purpose - 2
Additional Specifications - 2
Reference to Other Standards - 8
Glossary - 8
References - 9
Study Questions - 10
Module Description
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.
1. Introduction/Purpose
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.
1. Predicates
The predicate table shown in Clause 3.2.3.2 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:
| Predicate | Section |
|---|---|
| SyncPulse | 2.5.1.2.8 |
| Threshold |
2.5.1.2.5.2 |
| Signature |
2.5.1.2.5.3 |
)
2. Conformance
The “Conformance” column of the PRL contains a circular reference, which shall be interpreted with the following corrections for the purposes of this procurement:
- Requirement 3.4.2.2.4.1 (Configure Cycle Timer Reference) under User Need 2.5.1.1 (Configure Cycle Timers and Unit Backup Time) shall be changed from “O” (optional) to “SyncPulse:M” (mandatory if SyncPulse has been selected).
- Requirement 3.4.2.2.4.2 (Determine Cycle Timer Capability) under User Need 2.5.1.1 (Configure Cycle Timers and Unit Backup Time) shall be changed from “O” (optional) to “SyncPulse:M” (mandatory if SyncPulse has been selected).
- User Need 2.5.1.2.8 (Configure Cycle Length by Plan) shall be changed from “SyncPulse:M” (mandatory if SyncPulse has been selected, which is a circular reference) to “O” (optional).
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:
The time between the receipt of the last byte of the request and the start of the transmission of the first byte of the response.
4. PRL
<<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. >>
| User Need ID | User Need | Functional Requirement ID | Functional Requirement | Additional Specifications |
|---|---|---|---|---|
| 2.4 | Architectural Needs | |||
| 2.4.1 | Provide Live Data | |||
| 3.3.3.2 | Configure Access | The SSM shall support at least ___ (1..255) access levels in addition to the administrator access level. | ||
| 2.4.2 | Provide Off-Line Logged Data | |||
| 3.3.2.2 | Configure Event Logging Service |
The SSM shall support at least:
|
||
| 2.5 | Features | |||
| 2.5.1 | Manage SSM | |||
| 2.5.1.1 | Configure Cycle Timers and Unit Backup Time | |||
| 3.4.2.2.1 | Determine SSLs Currently Connected | The SSM shall support at least ___ (8..255) SSLs. | ||
| 3.4.2.2.2 | Determine Pattern Selection Capabilities | The SSM shall support at least ___ (1..253) patterns for each section. | ||
| 3.4.2.2.3 | Determine SSM Section Characteristics | The SSM shall support at least ___ (1..16) sections. | ||
| 2.5.1.2.4 | Implement Plan Based on Timebase Schedule | |||
| 3.4.3.4 | Configure SSM Schedule |
The SSM shall support at least:
|
||
| 2.5.1.2.5.1 | Configure Traffic Responsive Mode | |||
| 3.4.1.1 | Assign System Detectors | The SSM shall support at least ___ (1..255) system detectors. | ||
| 2.5.1.2.5.2 | Configure Threshold Selection | |||
| 3.4.1.2 | Configure Detector Grouping | The SSM shall support at least ___ (1..255) detectors per group. | ||
| 3.4.3.5.3.2 | Configure Cycle Thresholds | The SSM shall support at least ___ (3..255) cycle threshold levels. | ||
| 3.4.3.5.3.3 | Configure Split Thresholds | The SSM shall support at least ___ (3..255) split threshold levels. The SSM shall support at least ___ (3..255) offset threshold levels. | ||
| 2.5.1.2.5.3 | Configure Signature Selection | |||
| 3.4.3.5.4.1 | Configure Signature Parameters | The SSM shall support at least ___ (1..65535) signatures. The SSM shall support at least ___ (8..255) signature detectors. | ||
6. Routing
<<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 SSM shall store into this object the complete PMPP Frame Information field of ALL responses from the SSL defined in sslNumber when sslNumber is not zero. As such, they may be a SNMP, SFMP, or STMP message.
The phrase "ALL responses" in this definition shall be interpreted to mean:
The most recent packet received from the SSL that may contain a response to the sslCommand when considering Transport Level information. In the case of Transportation Transport Profile, the Transport Level information shall include the Application Identifier (AID) and any port numbers present, as defined in NTCIP 2201 Clause 2.2.4. If the AID indicates an embedded STMP packet without any header (i.e., parsing method 3), the AID byte shall also be further analyzed according to the rules of STMP to determine if the packet may be a response to the sslCommand.
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 3.3.1.6 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:
- 5.7.1 maxMsgRouted
- 5.7.2.1.1 sslMessageRoutedNumber
- 5.7.2.1.2 sslCommand
- 5.7.2.1.3 sslCommandTimestamp
- 5.7.2.1.4 sslNumber
- 5.7.2.1.5 sslCommandFrequency
- 5.7.2.1.6 sslResponse
- 5.7.2.1.7 sslResponseTimestamp
- 5.7.2.1.8 sslResponseSequence
- 5.7.2.1.9 sslResponseStatus
3. Reference to Other Standards
Field Management Systems
- NTCIP 1210 Version v01.53, National Transportation Communications for ITS Protocol, Field Management Stations – Part 1: Object Definitions for Signal System Masters, AASHTO/ITE/NEMA, v01.53, October 2010.
- NTCIP 9001 Version v04, National Transportation Communications for ITS Protocol, The NTCIP Guide, AASHTO/ITE/NEMA, July 2009.
Systems Engineering
- IEEE Std 1233-1998, IEEE Guide for Developing System Requirements Specifications, IEEE, 1998.
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.
5. Glossary
To include additional descriptions/abbrs used primarily in the module.
| 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. |
| Dialogs | A sequence of information or message exchanges. |
| Interoperability | The ability of two or more systems or components to exchange information and use the information that has been exchanged (IEEE Std. 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology). |
| Section | A group of SSLs under the same logical control and on the same physical channel. |
| SSL | Signal System Local |
| SSM | Signal System Master |
| TMS | Traffic Management System |
6. References
Systems Engineering
- Systems Engineering Guidebook for Intelligent Transportation Systems Version 3.0, United States Department of Transportation, November 2009.
- 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. Accessed March 23, 2011.
7. Study Questions
1. Which of the following is not a major group of requirements in NTCIP 1210?
- Collect System Detector Data
- Manage SSM Configuration
- Monitor the SSM Operation
- Backwards Compatibility Requirements
2. Where is a list of additional specifications to consider for NTCIP 1210 deployments?
- In the User Needs Section of the standard
- In the Requirements Section of the standard
- In the Participant Student Supplement
- A and B
3. When should a requirement with a conformance “Threshold:M” be selected?
| Predicate | Section |
|---|---|
| SyncPulse | 2.5.1.2.8 |
| Threshold | 2.5.1.2.5.2 |
| Signature | 2.5.1.2.5.3 |
- Only when User Need 2.5.1.2.5.2 is selected
- Always
- Only when Requirement 3.4.4.1.4.2 is selected
- Only when Requirement 3.4.3.5.3.5 is selected
4. What does the following table mean?
| Func Req’t Reference | Functional Requirement | Dialog Reference | Object Reference | Object |
|---|---|---|---|---|
| 3.4.1.1 | Assign System Detectors | 4.2.1 | 5.12.1 | maxSensorSources |
| 5.12.2.1.2 | sensorSourceIntersection | |||
| 5.12.2.1.3 | sensorSourceDetNumber | |||
| 5.12.2.1.7 | sensorSourceVolumeFactor | |||
| 5.12.2.1.11 | sensorSourceOccWeighting |
- All of the objects must be supported
- At least one of the objects must be supported
- All of the objects must be supported, if the requirement is supported
- At least one of the objects must be supported, if the requirement is supported
5. What types of messages does the standard allow to be sent to the SSL using the sslComand feature?
- Any of thirteen standardized messages
- Any of thirteen user-defined messages
- Any message clearly defined in the specification
- Virtually any packeterized message
6. Which of the following is the best reason to extend a standard?
- There is an unmet need that justifies the added cost
- The existing system uses a non-standard design
- You want to use your specification to favor a specific vendor
- The standard solution is overly complex for your simple needs