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.)

Cover image for A304b: Specifying Requirements for Field Management Stations - Part 1 Object Definitions for Signal System Masters (SSM) Based on NTCIP 1210 Standard. Please see the Extended Text Description 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 of NTCIP 1210 contains incorrect references, which shall be interpreted with the following corrections for this procurement:

This image contains table data - please see the Extended Text Description below for details.

(Extended Text Description: This table contains the following data:

Predicate Section


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:

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 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 Configure Event Logging Service The SSM shall support at least:
  • ___ (1..255) event classes
  • ___ (1..255) event types
  • ___ (1..255) events per class
The SSM shall support monitoring the following objects for the event log (list as many as needed):
  • _____________,
  • _____________
The SSM shall support the following modes of event monitoring (strike out any that do not apply):
  • on-change
  • greater than
  • less than
  • hysteresis
  • periodic
  • bitwise ‘and’
2.5 Features  
2.5.1 Manage SSM Configure Cycle Timers and Unit Backup Time Determine SSLs Currently Connected The SSM shall support at least ___ (8..255) SSLs. Determine Pattern Selection Capabilities The SSM shall support at least ___ (1..253) patterns for each section. Determine SSM Section Characteristics The SSM shall support at least ___ (1..16) sections. Implement Plan Based on Timebase Schedule Configure SSM Schedule The SSM shall support at least:
  • ___ (1..255) timebase table entries
  • ___ (1..255) day plans
  • ___ (1..255) events per day plan
  • ___ (1..255) Actions in the action table
  • ___ (1..255) events per action
___ (1..255) events in the daylight savings table Configure Traffic Responsive Mode Assign System Detectors The SSM shall support at least ___ (1..255) system detectors. Configure Threshold Selection Configure Detector Grouping The SSM shall support at least ___ (1..255) detectors per group. Configure Cycle Thresholds The SSM shall support at least ___ (3..255) cycle threshold levels. 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. Configure Signature Selection 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 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

Systems Engineering

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

7. Study Questions

1. Which of the following is not a major group of requirements in NTCIP 1210?

  1. Collect System Detector Data
  2. Manage SSM Configuration
  3. Monitor the SSM Operation
  4. Backwards Compatibility Requirements

2. Where is a list of additional specifications to consider for NTCIP 1210 deployments?

  1. In the User Needs Section of the standard
  2. In the Requirements Section of the standard
  3. In the Participant Student Supplement
  4. A and B

3. When should a requirement with a conformance “Threshold:M” be selected?

Predicate Section
  1. Only when User Need is selected
  2. Always
  3. Only when Requirement is selected
  4. Only when Requirement is selected

4. What does the following table mean?

Func Req’t Reference Functional Requirement Dialog Reference Object Reference Object Assign System Detectors 4.2.1 5.12.1 maxSensorSources sensorSourceIntersection sensorSourceDetNumber sensorSourceVolumeFactor sensorSourceOccWeighting
  1. All of the objects must be supported
  2. At least one of the objects must be supported
  3. All of the objects must be supported, if the requirement is supported
  4. 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?

  1. Any of thirteen standardized messages
  2. Any of thirteen user-defined messages
  3. Any message clearly defined in the specification
  4. Virtually any packeterized message

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

  1. There is an unmet need that justifies the added cost
  2. The existing system uses a non-standard design
  3. You want to use your specification to favor a specific vendor
  4. The standard solution is overly complex for your simple needs