Module 24 - A304a

A304a: Understanding User Needs for Field Management Stations (FMS) - Part 1: Object Definitions for Signal System Masters 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 A304a: Understanding User Needs for Field Management Stations (FMS) - Part 1: Object Definitions for Signal System Masters 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 “A304a: Understanding User Needs for Field Management Stations (FMS) - Part 1: Object Definitions for Signal System Masters 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.)

A304a: Understanding User Needs for Field Management Stations - Part 1 Object Definitions for Signal System Masters (SSM) Based on NTCIP 1210 Standard

Table of Contents

Introduction/Purpose - 2

SSM User Needs - 2

Sample Specification Text - 3

Reference to Other Standards - 8

Glossary - 8

References - 9

Study Questions - 9

Module Description

This module is a part of the acquisition curriculum path with I101, A101, A102, A201, and C101 being the prerequisites and A304b, Specifying Requirements for Field Management Stations - Part 1 Object Definitions for Signal System Masters Based on NTCIP 1210 Standard, following this module. The logical next step for the participant after taking A304a and A304b is to consider modules in the testing life cycle, which are 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 a Signal System Master (SSM). A SSM is a type of Field Management Station (FMS) that is used to manage traffic signal controllers.

SSM user need 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 (ConOps) 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 can be included in procurement specifications.

2. SSM User Needs

The following table is derived from NTCIP 1210.

2.1. NTCIP 1210 User Needs

User Need ID

User Need

FR ID

Functional Req't

Conformance

Project Requirement

Additional Project Requirements

2.4

Architectural Needs

2.4.1

Provide Live Data

M

Yes

2.4.2

Provide Off-Line Logged Data

M

Yes

2.4.3

Connect Communications Networks

M

Yes

2.4.4

Support Legacy Communications Networks

O

Yes / No

2.5

Features

2.5.1

Manage SSM

2.5.1.1

Configure Cycle Timers and Unit Backup Time

M

Yes

2.5.1.2

Manage System Timing Plans

M

Yes

2.5.1.2.1

Manage Section Definition Set

M

Yes

2.5.1.2.2

Implement a Manually Selected Plan

M

Yes

2.5.1.2.3

Implement Plan based On TMS Command

M

Yes

2.5.1.2.4

Implement Plan based On Timebase Schedule

M

Yes

2.5.1.2.5

Implement Plan Responsively Based On Traffic Conditions

2.5.1.2.5.1

Configure Traffic Responsive Mode

M

Yes

2.5.1.2.5.2

Configure Threshold Selection

O.1 (1..*)

Yes / No

2.5.1.2.5.3

Configure Signature Selection

O.1 (1..*)

Yes / No

2.5.1.2.6

Configure Plan Selection Mode

M

Yes

2.5.1.2.7

Synchronize Clocks of SSLs

M

Yes

2.5.1.2.8

Configure Cycle Length by Plan

M

Yes

2.5.1.3

Monitor System Operation

2.5.1.3.1

Manage Alarms

M

Yes

2.5.1.3.1.1

Loss of Control of SSLs

M

Yes

2.5.1.3.1.2

Failed System Detectors

M

Yes

2.5.1.3.1.3

Other Alarms Within a SSL

M

Yes

2.5.1.3.1.4

Forward SSM Alarms and Events

M

Yes

2.5.1.3.2

Manage System Display Data

M

Yes

The Response Start Time for all requests shall be not greater than ______ milliseconds (Default 2000).

2.5.1.3.3

Monitor Traffic Conditions

M

Yes

2.5.2

Manage SSLs

O

Yes / No

3. Sample Specification Text

The following text should be considered when inserting NTCIP wording into a procurement specification.

S.1. PRL

The SSM shall conform to NTCIP 1210 and to the items selected in the following Protocol Requirements List (PRL).

<< Insert completed PRL here >>

S.2. Object Ranges

The SSM shall support all values for all supported NTCIP objects, except as indicated within the PRL and this supplement.

S.3. Response Time

The SSM shall fully process all requests in accordance with NTCIP 1103 v02, including updating the value in the database and initiating the transmission of the proper response, within_milliseconds of receiving the last byte of the request.

S.4. Access Levels

The SSM shall support at least_(communityNamesMax = 1..255) access levels in addition to the administrator access level.

S.5. Event Log

a. Support a Number of Event Classes

The SSM shall support at least_(maxEventClasses = 1..255) event classes.

b. Support a Number of Event Types to Monitor

The SSM shall support monitoring at least_(maxEventLogConfigs = 1..65535) types of events simultaneously.

c. Support Monitoring of Event Types

The SSM shall support the following selected event types: (User to select)

i. On-change events

ii. Greater-than events

iii. Less-than events

iv. Hysteresis events

v. Periodic events

vi. Bit-flag events

d. Support Event Monitoring on Any Data

The SSM shall allow a management station to configure any event type to monitor any object instance supported by the device within the logical rules of the type of event.

e. Support a Number of Events to Store

The SSM shall support storing at least_(maxEventLogSize = 1..65535) events in the event log.

S.6. Commands

a. Number of Command Types

The SSM shall support at least_(maxTmpMsg = 4..255) command types.

NOTE: A command type is an NTCIP (get or set) message that can be sent from the SSM to one or more SSLs. It is used to synchronize one or more parameters in the SSL that are paired with parameters in the SSM. This allows the TMS (or algorithms internal to the SSM) to indirectly set parameters in the SSL or to retrieve values from the SSL.

b. Number of Commands

The SSM shall support a total of at least_(maxCommands = 1..65535) commands. The commands shall be evenly divided among the sections supported by the SSL (e.g., an SSL that is required to support 8 sections and 256 commands will support exactly 32 commands per section).

NOTE: A command configures the more generic command type to be specific to an intersection. This allows a command type to be defined once and repeatedly referenced for multiple intersections.

c. Number of OID Pairs

The SSM shall support at least_(maxMessageOidPairs = 1..255) OID Pairs.

NOTE: An OID Pair is a pairing of an SSL parameter with an SSM parameter. This is used with commands to synchronize the two values. Thus, this number should be an estimate of the number of distinct data values the user wishes to retrieve from each local signal controller.

d. Number of Variables per Command

The SSM shall support at least_(maxTmpMsgVar = 16..255) variables per command.

NOTE: This number should accommodate the maximum number of discrete data values that the system designer plans to exchange between the SSM and the SSL.

S.7. Support a Number of Routed Messages

The SSM shall support the management of at least_(maxMsgRouted = 1..255) simultaneous messages routed from the TMS to the SSLs.

NOTE: A routed message is a fully formed Point-to-Multi-Point Protocol (PMPP) message that the TMS downloads to the SSM to route to a specific intersection.

S.8. Number of Sections

The SSM shall support at least_(maxSections = 1..16) sections.

S.9. Number of SSLs

The SSM shall support at least_(maxIntersections = 8..255) SSLs.

S.10. Number of System Detectors

The SSM shall support at least_(maxSensorSources = 1..255) system detectors.

S.11. Number of Patterns

The SSM shall support at least_(maxSsmPatterns = 1..253) patterns.

NOTE: A pattern is a timing pattern for a section.

S.12. Timebase Schedule

a. Number of Timebase Schedule Entries

The SSM shall support at least_(maxTimeBaseScheduleEntries = 1..65535) entries into the timebase schedule.

NOTE: The timebase schedule allows the user to define which day plan to run based on month, day-of-week, and day-of-month.

b. Number of Day Plans

The SSM shall support at least_(maxDayPlans = 1..255) day plans.

NOTE: A day plan is a list of actions that are to occur during a day (e.g., selection of traffic responsive mode).

c. Number of Day Plan Events

The SSM shall support at least_(maxDayPlanEvents = 1..255) day plan events.

NOTE: A day plan event is the call to implement a certain action at a specified time during a day.

d. Number of Timebase Actions

The SSM shall support at least_(maxTimebaseSsmActions = 1..255) timebase actions.

NOTE: A timebase action is the type of action that is called by a day plan event for a SSM; it can implement a specified type of coordination algorithm on each defined section. A given action may be defined once, but called multiple times from the same and/or different day plans.

e. Number of Timebase Action Tasks

The SSM shall support at least_(maxTimebaseSsmActionTasks = 1..255) timebase action tasks.

NOTE: A timebase action task assigns a coordination algorithm to one section. It is implemented when called by a timebase action.

f. Number of Daylight Saving Entries

The SSM shall support at least_(maxDaylightSavingEntries = 1..100) daylight saving entries.

NOTE: Each daylight saving entry is a pair of a start and end to daylight savings. Most deployments will only require one entry.

S.13. Threshold Parameters

Only needed if Configure Threshold Selection (User Need 2.5.1.2.5.2) is selected.

a. Number of Detectors per Detector Group

The SSM shall support at least_(maxDetectorsPerGroup = 8..255) system detectors for each Detector Group.

b. Number of Levels in Cycle Threshold Channel

The SSM shall support at least_(maxLevelsCycle = 3..255) levels in the Cycle Threshold Computational Channel.

c. Number of Levels in Split Threshold Channel

The SSM shall support at least_(maxLevelsSplit = 3..255) levels in the Split Threshold Computational Channel.

d. Number of Levels in Offset Threshold Channel

The SSM shall support at least_(maxLevelsOffset = 3..255) levels in the Offset Threshold Computational Channel.

S.14. Signature Parameters

Only needed if Configure Signature Selection (User Need 2.5.1.2.5.3) is selected. a. Number of Signatures

The SSM shall support at least_(maxSignatures = 1..65535) signatures for every section.

b. Number of Signature Detectors

The SSM shall support at least_(maxSignatureDetectors = 8..255) detectors for every section.

S.15. Communications Profile

NTCIP communications shall operate over the following communications stack:

See Modules for details

C101: Introduction to the Communications Protocols and Their Uses in ITS Applications

C201: Introduction to the Simple Network Management Protocol (SNMP) and its Applications in the Field Devices Based on NTCIP Standards

4. Reference to Other Standards

Field Management Systems

Systems Engineering

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.

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

The presentation for this module includes a sample scenario and several quiz questions, which are presented here for easy reference. The answers to the questions are provided in the on-line presentation.

Questions

  1. What is the purpose of the Systems Engineering Process?
    1. It provides a structured and reproducible approach to specifying a system.
    2. It provides a structured and reproducible approach to specifying a system.
    3. It provides checkpoints at various stages of development to ensure that the system will deliver what is needed.
    4. All of the above
  2. Which user need allows the SSM to instantly notify the user of unusual traffic conditions?
    1. 2.4.1 Provide Live Data
    2. 2.4.2 Provide Off-line Logged Data
    3. 2.5.1.3.1.4 Forward SSM Alarms and Events
    4. This user need is not supported by the standard.

Scenario

Suburbanville wants to upgrade its old closed loop system so that it supports ITS standards. They want:

  1. Which of the following user needs does not need to be selected for our scenario?
    1. 2.5.1.2.4 Implement Plan Based on Timebase Schedule
    2. 2.5.1.2.5.1 Configure Traffic Responsive Mode
    3. 2.5.1.2.5.2 Configure Threshold Selection
    4. 2.5.1.2.5.3 Configure Signature Selection
  2. Which of the following user needs does not need to be selected for our scenario?
    1. 2.4.1 Provide Live Data
    2. 2.4.2 Provide Off-line Logged Data
    3. 2.4.4 Support Legacy Communication Networks
    4. 2.5.1.3.2 Manage System Display Data
  3. Should the following user need be selected for our project? 2.5.1.1 Configure Cycle Timers and Unit Backup Time
    1. Yes
    2. No
  4. Should the following user need be selected for our project?
    2.5.1.2.5.2 Configure Threshold Selection
    1. Yes
    2. No
  5. Should the following user need be selected for our project?
    2.5.1.2.5.3 Configure Signature Selection
    1. Yes
    2. No
  6. Which of the following statements is false?
    1. A vendor may support features not selected in the PRL.
    2. The PRL forms a complete interface specification.
    3. A deployment may support multiple interface specifications.
    4. This interface specification must be consistent with the hardware and software specifications.