Module 32 - A315b

A315b: Understanding Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 Standard Part 1 of 2

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 A315b: Understanding Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 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 "A315b: Understanding Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 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.)

 

A315b: Understanding Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 Standard Part 1 of 2

 

Table of Contents

Introduction/Purpose - 2

Example Specification Text - 2

Glossary - 24

References - 25

Study Questions - 25


Module Description

This module is part of the non-SE path, thus students must learn how to specify requirements based on well-written user needs specific to the ASC Standard, which is addressed in A315a: Understanding User Needs for Actuated Traffic Signal Controllers Based on NTCIP 1202 Standard. This module addresses the next step of the systems life cycle, which is to develop well-formed requirements specific to the ASC Standard.

 

1. Introduction/Purpose

The purpose of this module is to teach the students how to identify and develop well-formed requirements specific to the NTCIP 1202 v02 ASC Standard, which does not contain requirements.

The focus of this module is to assist technical staff in developing requirements and design details for specifying an ASC system that meets identified user needs in an interoperable fashion. This module will continue to provide participants with information on how to identify the appropriate use of the NTCIP 1202 Standard and acquire an ASC based on what the user is seeking to accomplish as identified by the user needs and from requirements. This module assumes that the participant, having taken A315a, understands the interdependency of NTCIP 1202 objects to the architecture and functionality of NEMA TS2. The module then builds upon that understanding, the application of NTCIP 1202 Standard to develop well-formed requirements and design details based on the identified needs to meet ASC controller functions.

 

2. Example Interface Specification Text

The following text provides examples of text that might appear in a procurement specification using the examples discussed in the presentation. The reader should be aware that this is far from a full specification; it merely provides some examples with many gaps in information, but it provides the reader with the feel that an NTCIP interface specification should have, including identifying the major components that should be contained within such a specification.

Note that the sample text includes all user needs and requirements from existing NTCIP standards for other devices that may be easily adapted for ASCs. Any modifications made to the standardized text are shown with strikeouts and underlines. Each clause also contains a citation to indicate where the text came from. This should give the reader a high level of confidence that we are maintaining a high degree of consistency with approved standards.

Clauses without any text reflect placeholders that were defined in the presentation. These would need to be detailed along with many other details before using this specification.

 

2.1. User Needs

The user needs are presented as informational background to give better insight into the intent of the requirements.

 

2.1.1. Architectural User Needs

2.1.1.1. Live Data Exchange

The typical operational environment allows the management system to monitor and control the DMS ASC by issuing requests (e.g., requests to access information, alter information, or control the signcontroller). In this environment, the DMS ASC responds to requests from the management station immediately (e.g., through the provision of live data, success/failure notices of information alteration, or success/failure of the command).

NTCIP 1203 v03 Clause 2.4.2.1 with revisions shown

2.1.1.2. Logged Data Exchange

Some operational environments do not have always-on connections (e.g., dial-up links). In such environments, a transportation system operator may wish to define conditions under which data is placed into a log, which can then be uploaded at a later time. For example, the operator may wish to maintain a log of all error conditions. maintain a log of all messages posted on the sign, regardless of which management station or algorithm posted the message.

NTCIP 1203 v03 Clause 2.4.2.2 with revisions shown

2.1.1.3. Support Legacy Communications Networks

Associated with the previous need is that aAgencies may need to use SSMASC’s within existing communications networks. Therefore, the SSM ASC needs to provide for the efficiencies needed by old low- speed communications, and to support those same efficiencies used by SSLs.

NTCIP 1210 v01 Clause 2.4.4 with revisions shown

2.1.2. Configure User Needs

2.1.2.1. Safely Configure Signal for Intersection Layout

The agency needs a signal controller that can be safely configured to control any intersection within its jurisdiction, including those with atypical layouts.

This will result in lower overall maintenance costs for the Maintenance Division. However, the operators must still be able to control every intersection, including 6-legged intersections. In addition, due to the safety critical nature of this information coupled with the static nature of the information, this process should require the presence of a field technician to verify any change.

A315a Slide 67

2.1.3. Control User Needs

2.1.3.1. Manually Control Selection of Timing Pattern

The Agency needs to be able to adjust intersection timing to accommodate the dynamic demands on the signal while also providing “green waves” for smooth and efficient traffic flow.

The pattern will typically be selected from a predefined list by the central system based on network conditions, but the local controller needs to be able to default to a specified schedule if any problems occur with receiving these commands and field personnel should be able to override these commands. The controller should allow for storage of sufficient patterns for all of these purposes.

A315b Slide 19

2.1.3.2. Support a Timing Pattern Schedule

This feature enables the operator to configure the ASC DMS to activate messages timing patterns at a future time (“scheduling”). The operator can indicate a series of times at which an associated message timing pattern will be activated. The associated message timing pattern can be any message timing pattern stored in the sign controller ASC, including a blank message.

NTCIP 1203 v03 Clause 2.5.2.3.5 with revisions shown

2.1.4. Monitor User Needs

2.1.4.1. Monitor Signal Configuration

<<TBD>>

2.1.4.2. Monitor Signal Timing

The agency needs a signal controller that will allow the management system to monitor the status of each signal indication with a one second resolution so that the agency has a way to remotely verify that the traffic signal is operating as expected.

A315a Slide 68

2.1.4.3. Monitor Timing Pattern Selection

<<TBD>>

2.1.4.4. Monitor Signal Diagnostics

<<TBD>>

2.1.4.5. Determine Device Identity

This feature allows the operator to determine basic information about the ASC, DMS, such as the type, technology, manufacturer, model, and version number of the DMSASC. It includes the ability to access information about both hardware and software elements of the ASC. DMS.

NTCIP 1203 v03 Clause 2.5.1.1 with revisions shown

2.1.5. Backwards Compatibility User Needs

2.1.5.1. Manufacturer X Model 1

Operators need the central system to work with Manufacturer X Model 1 controllers that are currently deployed, as these are too costly to update.

A315a Slide 82

2.2. Requirements

A component claiming compliance to this specification shall fulfill all of the requirements defined in this specification according to the designs defined in the Requirements Traceability Matrix.

2.2.1. Configure Requirements

2.2.1.1. Configure a Timing Pattern

When requested by the Operator, the central system shall configure the ASC with timing pattern information subject to ASC-imposed validation rules.

A315b Slide 33 with revisions as suggested on subsequent slides

2.2.1.2. Configure Timing Pattern Selection Logic

<<TBD>>

2.2.1.3. Configure Logging Service

The central system shall configure the ASC with event logging service information, including configuration of the event classes and event types to log.

Derived from NTCIP 1203 v03 Clause 3.4.2.2

2.2.1.4. Configure Timing Pattern Transition Mechanism

<<TBD>>

2.2.1.5. Configure Access

When requested by the Administrator, the central system shall configure the ASC with access settings for all access levels. The ASC shall support at least ______ access level(s) in addition to the administrator access level.

Derived from NTCIP 1203 v03 Clause 3.4.4.2

2.2.1.6. Set Time

The central system shall configure the ASC with the current coordinated universal time to the nearest second.

Derived from NTCIP 1203 v03 Clause H.2.2.1.

2.2.1.7. Set Time Zone

The central system shall configure the ASC with time zone information.

Derived from NTCIP 1203 v03 Clause H.2.2.2.

2.2.1.8. Set Daylight Savings Operations

The central system shall configure the ASC so that it knows whether or not to apply day light savings time adjustments when determining local time.

Derived from NTCIP 1203 v03 Clause H.2.2.3.

2.2.1.9. Define a Schedule

The central system shall configure the ASC with daily schedules of actions with a time resolution of one minute; the rules for selecting a daily schedule to run shall allow schedule configuration up to a year in advance.

Derived from NTCIP 1203 v03 Clause 3.5.2.3.4.2

2.2.2. Control Requirements

2.2.2.1. Activate Timing Pattern Remotely

<<TBD>>

2.2.2.2. Activate a Timing Pattern per a Schedule

<<TBD>>

2.2.2.3. Override Timing Pattern

<<TBD>>

2.2.2.4. Clear Log

The central system shall clear the ASC of log entries of a given event class that are less than or equal to a given time.

Derived from NTCIP 1203 v03 Clause 3.4.2.4

2.2.3. Monitor Requirements

2.2.3.1. Verify Current Time

The central system shall monitor the ASC to determine the current time settings.

Derived from NTCIP 1203 v03 Clause H.2.2.4.

2.2.3.2. Determine Current Configuration of Logging Service

The central system shall monitor the ASC to determine the current configuration of the event logging service, including the classes and types of events that are currently configured.

Derived from NTCIP 1203 v03 Clause 3.4.2.1

2.2.3.3. Retrieve Logged Data

The central system shall monitor the ASC to discover any logged events.

Derived from NTCIP 1203 v03 Clause 3.4.2.3

2.2.3.4. Determine Capabilities of Logging Service

The central system shall monitor the ASC to determine the capabilities of the event logging service, including the number of classes, number of event types, and number of events that can be supported.

Derived from NTCIP 1203 v03 Clause 3.4.2.5

2.2.3.5. Determine Total Number of Events

The central system shall monitor the ASC to determine the total number of logged events since power up.

Derived from NTCIP 1203 v03 Clause 3.4.2.6

2.2.3.6. Retrieve a Schedule

The central system shall monitor the ASC to determine the current configuration of the schedule.

Derived from NTCIP 1203 v03 Clause 3.5.2.3.4.1

2.2.3.7. Determine Maximum Number of Schedules

The central system shall monitor the ASC to determine the maximum number of schedules and day plans supported.

Derived from NTCIP 1203 v03 Clause H.2.3.1

2.2.3.8. Monitor Current Schedule

The central system shall monitor the ASC to determine which schedule entry has been selected.

Derived from NTCIP 1203 v03 Clause H.2.3.2.

2.2.3.9. Monitor Timing Pattern Configuration

<<TBD>>

2.2.3.10. Monitor Current Timing Pattern

The central system shall monitor the ASC to determine which timing pattern is currently active.

A315b Slide 34

2.2.3.11. Monitor Last Timing Pattern Requested

<<TBD>>

2.2.3.12. Monitor Source of Last Timing Pattern

<<TBD>>

2.2.3.13. Monitor Transition Mechanism Selected

<<TBD>>

2.2.3.14. Monitor Timing Pattern Schedule

<<TBD>>

2.2.3.15. Determine Current Access Settings

When requested by the administrator, the central system shall monitor the ASC to determine the current access settings.

Derived from NTCIP 1203 v03 Clause 3.4.4.1

2.2.3.16. Determine Device Component Information

The central system shall monitor the ASC to determine identification information for each module contained in the device including:

  1. An indication of the type of device
  2. The manufacturer of the module
  3. The model number or firmware reference of the module
  4. The version of the module
  5. An indication of whether it is a software or hardware module

Derived from NTCIP 1203 v03 Clause H.2.1

2.2.3.17. Determine Supported Standards

The central system shall monitor the ASC to determine the supported NTCIP standards.

Derived from NTCIP 1203 v03 Clause H.2.4

2.2.4. Supplemental Requirements

To claim compliance to this specification, a component shall support the full range of all objects referenced in the Requirements Traceability Matrix (Clause 2.5), except as ranges are explicitly defined in the following clauses.

2.2.4.1. Support at Least 32 Timing Patterns

The component shall support at least 32 timing patterns and 32 splits.

2.2.4.2. Support a Number of Day Selection Patterns

The device shall support at least _____ day selection pattern(s).

Derived from NTCIP 1203 v03 Clause H.2.5.1

2.2.4.3. Support a Number of Day Plan Events

The device shall support at least _______ day plan events per day plan.

Derived from NTCIP 1203 v03 Clause H.2.5.2

2.2.4.4. Support a Number of Day Plans

The device shall support at least _____ day plan(s).

Derived from NTCIP 1203 v03 Clause H.2.5.3

2.2.4.5. Support a Number of Actions

The ASC shall support at least _____ actions.

Derived from NTCIP 1203 v03 Clause 3.6.10.1

2.2.4.6. Support the Activate Timing Pattern Action for the Scheduler

The ASC shall allow the scheduler to be configured to activate any timing pattern supported by the ASC and currently valid.

Derived from NTCIP 1203 v03 Clause 3.6.10.2

2.2.4.7. Perform Actions at Scheduled Times

The ASC shall perform the actions configured in the scheduler at the times identified.

Derived from NTCIP 1203 v03 Clause 3.6.10.3

2.2.4.8. Maximum Response Time for Requests

The ASC shall process all requests in accordance with all of the rules of the relevant base standards (i.e., NTCIP 1103 v01 and NTCIP 2303:2001), including updating the value in the database and initiating the transmission of the appropriate response (assuming that the ASC has permission to transmit) within the Maximum Response Time. The Maximum Response Time shall be 100 milliseconds. The Maximum Response Time is measured as the time between the receipt of the last byte of the request and the transmission of the first byte of the response.

Derived from NTCIP 1204 v03 Clause 3.6.21

2.2.4.9. Record and Timestamp Events

The device shall support the capability to record configured event types with timestamps, in a local log (log contained in the device controller), upon request by the user and/or the management station.

NTCIP 1203 v03 Clause H.2.6.1

2.2.4.10. Support a Number of Event Classes

The device shall support at least _________ event class(es).

Derived from NTCIP 1203 v03 Clause H.2.6.2

2.2.4.11. Support a Number of Event Types to Monitor

The device shall support at least ________ event type(s).

Derived from NTCIP 1203 v03 Clause H.2.6.3

2.2.4.12. Support Monitoring of Event Types

Supplemental requirements for monitoring types of events are provided in the following subsections.

NTCIP 1203 v03 Clause H.2.6.4

2.2.4.12.1. Support On-Change Events

The device shall allow any event type configuration to monitor data for changes in value.

NTCIP 1203 v03 Clause H.2.6.4.1

2.2.4.12.2. Support Greater Than Events

The device shall allow any event type configuration to monitor data for values exceeding a defined threshold for a period of time.

NTCIP 1203 v03 Clause H.2.6.4.2

2.2.4.12.3. Support Less Than Events

The device shall allow any event type configuration to monitor data for values falling below a defined threshold for a period of time.

NTCIP 1203 v03 Clause H.2.6.4.3

2.2.4.12.4. Support Hysteresis Events

The device shall allow any event type configuration to monitor data for values exceeding an upper limit or dropping below a lower limit.

NTCIP 1203 v03 Clause H.2.6.4.4

2.2.4.12.5. Support Periodic Events

The device shall allow any event type configuration to monitor data on a periodic basis.

NTCIP 1203 v03 Clause H.2.6.4.5

2.2.4.12.6. Support Bit-flag Events

The device shall allow any event type configuration to monitor one or more bits of a value becoming true (e.g., obtaining a value of one).

NTCIP 1203 v03 Clause H.2.6.4.6

2.2.4.12.7. Support Event Monitoring on Any Data

The device shall allow a management station to configure any event type to monitor any piece of data supported by the device within the logical rules of the type of event (e.g., ASCII strings should not be monitored with greater than or less than conditions).

NTCIP 1203 v03 Clause H.2.6.4.7

2.2.4.13. Support a Number of Events to Store in Log

The device shall support at least _________ event(s) in the log.

Derived from NTCIP 1203 v03 Clause H.2.7

2.2.5. Architectural Requirements

2.2.5.1. Retrieve Data

The central system shall retrieve data from the ASC.

Derived from NTCIP 1203 v03 Clause 3.4.1.1

2.2.5.2. Deliver Data

The central system shall deliver data (e.g., configuration data, commands, etc.) to the ASC.

Derived from NTCIP 1203 v03 Clause 3.4.1.2

2.2.5.3. Explore Data

The central system shall dynamically discover what data and data instances are supported by the ASC.

Derived from NTCIP 1203 v03 Clause 3.4.1.3

2.2.5.4. Configure Block Objects

The central system shall configure the ASC by utilizing standard block objects.

Derived from NTCIP 1210 v01 Clause 3.3.1.9.1

2.2.5.5. Retrieve Block Objects

The central system shall retrieve ASC configuration data by utilizing standard block objects.

Derived from NTCIP 1210 v01 Clause 3.3.1.9.2

2.2.5.6. Retrieve Block Status

The central system shall retrieve the status of block transactions.

Derived from NTCIP 1210 v01 Clause 3.3.1.9.3

2.2.5.7. Support STMP

The central system shall support the STMP for communications.

Derived from NTCIP 1210 v01 Clause 3.3.1.9.4

2.2.5.1. ASC Conformance

The ASC shall properly respond to all requests that conform to the requirements defined in this document.

 

2.3. Dialogs

Dialogs are not intended to contradict the object definitions in any way; rather they further refine these definitions to ensure any NTCIP component claiming compliance to this specification will interoperate as intended. While the standard allows manufacturers to place some restrictions on objects, those restrictions may not interfere with these dialogs.

The rules for these dialog definitions shall be the rules defined in the list numbered a) through k) in NTCIP 1203 v03 Section 4, prior to Clause 4.1, except that the formal definition of object types are provided in NTCIP 1202 v02 and NTCIP 1201 v03.

2.3.1. Configure a Timing Pattern

The dialog for a management station to configure a timing pattern shall be as follows:

  1. (Precondition) The management station shall confirm that the signal controller supports the desired splits, phases, and patterns.
  2. For each enabled phase, the management station shall repeat Step 3.
  3. The management station shall SET the following objects to the desired values:
    1. splitTime.x.y
    2. splitMode.x.y
    3. splitCoordPhase.x.y

where x = splitNumber and y = phaseNumber.

  1. The management station shall SET the following objects to the desired values:
    1. patternCycleTime.z
    2. patternOffsetTime.z
    3. patternSplitNumber.z
    4. patternSequenceNumber.z

where z = patternNumber

Figure 1 provides a summary of this dialog.

This figure shows the sample dialog for configuring a timing pattern. Please see the Extended Text Description below.

(Extended Text Description: This figure shows the sample dialog for configuring a timing pattern. It is depicted by a UML sequence diagram between a "ManagementStation" and an "Agent". The dialog starts with a precondition of "Verify that the ASC supports the desired splits, offsets, phases, and patterns". This is then followed with a box labeled "Repeat for each phase" that contains the "ManagementStation" sending a "Set(splitTime.x.y, splitMode.x.y, splitCoordPhase.x.y)" message to the "Agent" and the "Agent" sending an unlabeled response message to the "ManagementStation". After the "Repeat for each phase" box, the sequence continues with the "ManagementStation" sending a "Set(patternCycleTime.z, patternOffsetTime.z, patternSplitNumber.z, patternSequenceNumber.z)" message to the "Agent" and the "Agent" sending an unlabeled response message to the "ManagementStation". At the bottom of the figure, there is a note indicating that x equals "splitNumber", y equals "splitPhase", and z equals "patternNumber".)

Figure 1

 

2.4. User Needs to Requirements Traceability

To claim compliance to this specification, the component shall fulfill all user needs and requirements identified in Table 1 according to the design presented in Table 2. A component may offer additional features, as long as they are conformant with the requirements of the NTCIP standards referenced by this specification.

References shown in Table 1 and Table 2 are clause numbers of this document, unless otherwise specified.

Table 1: User Needs to Requirements Traceability

User Need Reference User Need Requirement Reference Requirement
2.1.1 Architectural User Needs
2.1.1.1 Live Data Exchange
    2.2.5.1 Retrieve Data
    2.2.5.2 Deliver Data
    2.2.5.3 Explore Data
    2.2.4.8 Maximum Response Time for Requests
    2.2.3.15 Determine Current Access Settings
    2.2.1.5 Configure Access
2.1.1.2 Logged Data Exchange
    2.2.1.6 Set Time
    2.2.1.7 Set Time Zone
    2.2.1.8 Set Daylight Savings Operations
    2.2.3.1 Verify Current Time
    2.2.3.2 Determine Current Configuration of Logging Service
    2.2.1.3 Configure Logging Service
    2.2.3.3 Retrieve Logged Data
    2.2.2.4 Clear Log
    2.2.3.4 Determine Capabilities of Logging Service
    2.2.3.5 Determine Total Number of Events
    2.2.4.9 Record and Timestamp Events
    2.2.4.10 Support a Number of Event Classes
    2.2.4.11 Support a Number of Event Types to Monitor
    2.2.4.12.1 Support On-Change Events
    2.2.4.12.2 Support Greater Than Events
    2.2.4.12.3 Support Less Than Events
    2.2.4.12.4 Support Hysteresis Events
    2.2.4.12.5 Support Periodic Events
    2.2.4.12.6 Support Bit-flag Events
    2.2.4.12.7 Support Event Monitoring on Any Data
    2.2.4.13 Support a Number of Events to Store in Log
2.1.1.3 Support Legacy Communication Networks
    2.2.5.4 Configure Block Objects
    2.2.5.5 Retrieve Block Objects
    2.2.5.6 Retrieve Block Status
    2.2.5.7 Support STMP
2.1.2 Configure User Needs
2.1.2.1 Safely Configure Signal for Intersection Layout
2.1.3 Control User Needs
2.1.3.1 Manually Control Selection of Timing Pattern
    2.2.1.1 Configure a Timing Pattern
    2.2.4.1 Support at Least 32 Timing Patterns
    2.2.1.2 Configure Timing Pattern Selection Logic
    2.2.2.1 Activate Timing Pattern Remotely
    2.2.2.3 Override Timing Pattern
    2.2.1.4 Configure Timing Pattern Transition Mechanism
    2.2.3.9 Monitor Timing Pattern Configuration
    2.2.3.10 Monitor Current Timing Pattern
    2.2.3.11 Monitor Last Timing Pattern Requested
    2.2.3.12 Monitor Source of Last Timing Pattern
    2.2.3.13 Monitor Transition Mechanism Selected
2.1.3.2 Support a Timing Pattern Schedule
    2.2.4.1 Support at Least 32 Timing Patterns
    2.2.1.2 Configure Timing Pattern Selection Logic
    2.2.2.2 Activate a Timing Pattern per a Schedule
    2.2.3.6 Retrieve a Schedule
    2.2.1.9 Define a Schedule
    2.2.1.6 Set Time
    2.2.1.7 Set Time Zone
    2.2.1.8 Set Daylight Savings Operations
    2.2.3.1 Verify Current Time
    2.2.3.7 Determine Maximum Number of Schedules
    2.2.3.8 Monitor Current Schedule
    2.2.4.2 Support a Number of Day Selection Patterns
    2.2.4.3 Support a Number of Day Plan Events
    2.2.4.4 Support a Number of Day Plans
    2.2.4.5 Support a Number of Actions
    2.2.4.6 Support the Activate Timing Pattern Action for the Scheduler
    2.2.4.7 Perform Actions at Scheduled Times
    2.2.1.4 Configure Timing Pattern Transition Mechanism
    2.2.3.9 Monitor Timing Pattern Configuration
    2.2.3.10 Monitor Current Timing Pattern
    2.2.3.11 Monitor Last Timing Pattern Requested
    2.2.3.12 Monitor Source of Last Timing Pattern
    2.2.3.13 Monitor Transition Mechanism Selected
    2.2.3.14 Monitor Timing Pattern Schedule
2.1.4 Monitor User Needs
2.1.4.1 Monitor Signal Coordination
2.1.4.2 Monitor Signal Timing
2.1.4.3 Monitor Timing Pattern Selection
2.1.4.4 Monitor Signal Diagnostics
2.1.4.5 Determine Device Identity
    2.2.3.16 Determine Device Component Information
    2.2.3.17 Determine Supported Standards
2.1.5 Backwards Compatibility User Needs
2.1.5.1 Manufacturer X Model 1

 

2.5. Requirements Traceability Matrix

In order for a component to claim compliance to a requirement, it shall implement the all objects and dialogs traced from that requirement as shown in Table 2.

<< Shaded cells still need to be filled in along with adding rows for additional requirements. >>

Table 2: Requirements Traceability Matrix

Req't Reference Requirement Dialog Reference Object Reference Object
2.2.1.1 Configure a Timing Pattern 2.3.1 NTCIP 1202 v02 Clause 2.5.7.1 patternNumber
NTCIP 1202 v02 Clause 2.5.7.2 patternCycleTime
NTCIP 1202 v02 Clause 2.5.7.3 patternOffsetTime
NTCIP 1202 v02 Clause 2.5.7.4 patternSplitNumber
NTCIP 1202 v02 Clause 2.5.7.5 patternSequenceNumber
NTCIP 1202 v02 Clause 2.5.9.1 splitNumber
NTCIP 1202 v02 Clause 2.5.9.2 splitPhase
NTCIP 1202 v02 Clause 2.5.9.3 splitTime
NTCIP 1202 v02 Clause 2.5.9.4 splitMode
NTCIP 1202 v02 Clause 2.5.9.5 splitCoordPhase
2.2.1.2 Configure Timing Pattern Selection Logic      
2.2.1.3 Configure Logging Service NTCIP 1203 v03 Clause H.3.1.2 NTCIP 1103 v02 Clause A.7.3.1 eventClassNumber
NTCIP 1103 v02 Clause A.7.3.2 eventClassLimit
NTCIP 1103 v02 Clause A.7.3.4 eventClassDescription
NTCIP 1103 v02 Clause A.7.3.3 eventClassClearTime
NTCIP 1103 v02 Clause A.7.5.1 eventConfigID
NTCIP 1103 v02 Clause A.7.5.2 eventConfigClass
NTCIP 1103 v02 Clause A.7.5.3 eventConfigMode
NTCIP 1103 v02 Clause A.7.5.4 eventConfigCompareValue
NTCIP 1103 v02 Clause A.7.5.5 eventConfigCompareValue2
NTCIP 1103 v02 Clause A.7.5.6 eventConfigCompareOID
NTCIP 1103 v02 Clause A.7.5.7 eventConfigLogOID
NTCIP 1103 v02 Clause A.7.5.8 eventConfigAction
NTCIP 1103 v02 Clause A.7.5.9 eventConfigStatus
2.2.1.4 Configure Timing Pattern Transition Mechanism      
2.2.1.5 Configure Access NTCIP 1203 v03 Clause G.3 NTCIP 1103 v02 A.8.1 communityNameAdmin
NTCIP 1103 v02 A.8.2 communityNamesMax
NTCIP 1103 v02 A.8.3.1 communityNameIndex
NTCIP 1103 v02 A.8.3.2 communityNameUser
NTCIP 1103 v02 A.8.3.3 communityNameAccessMask
2.2.1.6 Set Time NTCIP 1203 v03 Clause G.3 NTCIP 1201 v03 2.4.1 globalTime
2.2.1.7 Set Time Zone NTCIP 1203 v03 Clause G.3 NTCIP 1201 v03 2.4.5 globalLocalTimeDifferential
2.2.1.8 Set Daylight Savings Operations NTCIP 1203 v03 Clause G.3 NTCIP 1201 v03 2.4.8.2.1 dstEntryNumber
NTCIP 1201 v03 2.4.8.2.2 dstBeginMonth
NTCIP 1201 v03 2.4.8.2.3 dstBeginOccurrences
NTCIP 1201 v03 2.4.8.2.4 dstBeginDayOfWeek
NTCIP 1201 v03 2.4.8.2.5 dstBeginDayOfMonth
NTCIP 1201 v03 2.4.8.2.6 dstBeginSecondsToTransition
NTCIP 1201 v03 2.4.8.2.7 dstEndMonth
NTCIP 1201 v03 2.4.8.2.8 dstEndOccurrences
NTCIP 1201 v03 2.4.8.2.9 dstEndDayOfWeek
NTCIP 1201 v03 2.4.8.2.10 dstEndDayOfMonth
NTCIP 1201 v03 2.4.8.2.11 dstEndSecondsToTransition
NTCIP 1201 v03 2.4.8.2.12 dstSecondsToAdjust
2.2.1.9 Define a Schedule <<TBD>> NTCIP 1201 v03 2.4.3.2.1 timeBaseScheduleNumber
NTCIP 1201 v03 2.4.3.2.2 timeBaseScheduleMonth
NTCIP 1201 v03 2.4.3.2.3 timeBaseScheduleDay
NTCIP 1201 v03 2.4.3.2.4 timeBaseScheduleDate
NTCIP 1201 v03 2.4.3.2.5 timeBaseScheduleDayPlan
NTCIP 1201 v03 2.4.3.3.1 dayPlanNumber
NTCIP 1201 v03 2.4.3.3.2 dayPlanEventNumber
NTCIP 1201 v03 2.4.3.3.3 dayPlanHour
NTCIP 1201 v03 2.4.3.3.4 dayPlanMinute
NTCIP 1201 v03 2.4.3.3.5 dayPlanActionNumberOID
NTCIP 1202 v02 2.6.3.1 timebaseAscActionNumber
NTCIP 1202 v02 2.6.3.2 timebaseAscPattern
NTCIP 1202 v02 2.6.3.3 timebaseAscAuxillaryFunction
NTCIP 1202 v02 2.6.3.4 timebaseAscSpecialFunction
2.2.2.1 Activate Timing Pattern Remotely      
2.2.2.2 Activate a Timing Pattern per a Schedule      
2.2.2.3 Override Timing Pattern      
2.2.2.7 Clear Log NTCIP 1203 v03 Clause G.3 NTCIP 1103 v02 Clause A.7.3.3 eventClassClearTime
2.2.3.1 Verify Current Time NTCIP 1203 v03 Clause G.1 NTCIP 1201 v03 Clause 2.4.1 globalTime
NTCIP 1201 v03 Clause 2.4.6 controllerStandardTimeZone
NTCIP 1201 v03 Clause 2.4.8.1 maxDaylightSavingEntries
NTCIP 1201 v03 Clause 2.4.8.2.1 dstEntryNumber
NTCIP 1201 v03 Clause 2.4.8.2.2 dstBeginMonth
NTCIP 1201 v03 Clause 2.4.8.2.3 dstBeginOccurrences
NTCIP 1201 v03 Clause 2.4.8.2.4 dstBeginDayOfWeek
NTCIP 1201 v03 Clause 2.4.8.2.5 dstBeginDayOfMonth
NTCIP 1201 v03 Clause 2.4.8.2.6 dstBeginSecondsToTransition
NTCIP 1201 v03 Clause 2.4.8.2.7 dstEndMonth
NTCIP 1201 v03 Clause 2.4.8.2.8 dstEndOccurrences
NTCIP 1201 v03 Clause 2.4.8.2.9 dstEndDayOfWeek
NTCIP 1201 v03 Clause 2.4.8.2.10 dstEndDayOfMonth
NTCIP 1201 v03 Clause 2.4.8.2.11 dstEndSecondsToTransition
NTCIP 1201 v03 Clause 2.4.8.2.12 dstSecondsToAdjust
NTCIP 1201 v03 Clause 2.4.7 controllerLocalTime
2.2.3.2 Determine Current Configuration of Logging Service NTCIP 1203 v03 Clause H.3.1.1 NTCIP 1103 v02 Clause A.7.3.1 eventClassNumber
NTCIP 1103 v02 Clause A.7.3.2 eventClassLimit
NTCIP 1103 v02 Clause A.7.3.4 eventClassDescription
NTCIP 1103 v02 Clause A.7.3.3 eventClassClearTime
NTCIP 1103 v02 Clause A.7.5.1 eventConfigID
NTCIP 1103 v02 Clause A.7.5.2 eventConfigClass
NTCIP 1103 v02 Clause A.7.5.3 eventConfigMode
NTCIP 1103 v02 Clause A.7.5.4 eventConfigCompareValue
NTCIP 1103 v02 Clause A.7.5.5 eventConfigCompareValue2
NTCIP 1103 v02 Clause A.7.5.6 eventConfigCompareOID
NTCIP 1103 v02 Clause A.7.5.7 eventConfigLogOID
NTCIP 1103 v02 Clause A.7.5.8 eventConfigAction
NTCIP 1103 v02 Clause A.7.5.9 eventConfigStatus
2.2.3.3 Retrieve Logged Data NTCIP 1203 v03 Clause H.3.1.1 NTCIP 1103 v02 Clause A.7.3.5 eventClassNumRowsInLog
NTCIP 1103 v02 Clause A.7.3.6 eventClassNumEvents
NTCIP 1103 v02 Clause A.7.7.1 eventLogClass
NTCIP 1103 v02 Clause A.7.7.2 eventLogNumber
NTCIP 1103 v02 Clause A.7.7.3 eventLogID
NTCIP 1103 v02 Clause A.7.7.4 eventLogTime
NTCIP 1103 v02 Clause A.7.7.5 eventLogValue
2.2.3.4 Determine Capabilities of Logging Service NTCIP 1203 v03 Clause G.1 NTCIP 1103 v02 Clause A.7.2 maxEventClasses
NTCIP 1103 v02 Clause A.7.4 maxEventLogConfigs
NTCIP 1103 v02 Clause A.7.6 maxEventLogSize
2.2.3.5 Determine Total Number of Events NTCIP 1203 v03 Clause G.1 NTCIP 1103 v02 Clause A.7.8 numEvents
2.2.3.6 Retrieve a Schedule NTCIP 1203 v03 Clause G.1 NTCIP 1201 v03 2.4.3.2.1 timeBaseScheduleNumber
NTCIP 1201 v03 2.4.3.2.2 timeBaseScheduleMonth
NTCIP 1201 v03 2.4.3.2.3 timeBaseScheduleDay
NTCIP 1201 v03 2.4.3.2.4 timeBaseScheduleDate
NTCIP 1201 v03 2.4.3.2.5 timeBaseScheduleDayPlan
NTCIP 1201 v03 2.4.3.3.1 dayPlanNumber
NTCIP 1201 v03 2.4.3.3.2 dayPlanEventNumber
NTCIP 1201 v03 2.4.3.3.3 dayPlanHour
NTCIP 1201 v03 2.4.3.3.4 dayPlanMinute
NTCIP 1201 v03 2.4.3.3.5 dayPlanActionNumberOID
NTCIP 1202 v02 2.6.3.1 timebaseAscActionNumber
NTCIP 1202 v02 2.6.3.2 timebaseAscPattern
NTCIP 1202 v02 2.6.3.3 timebaseAscAuxillaryFunction
NTCIP 1202 v02 2.6.3.4 timebaseAscSpecialFunction
2.2.3.7 Determine Maximum Number of Schedules NTCIP 1203 v03 Clause G.1 NTCIP 1201 v03 2.4.3.1 maxTimeBaseScheduleEntries
NTCIP 1201 v03 2.4.4.1 maxDayPlans
NTCIP 1201 v03 2.4.4.2 maxDayPlanEvents
NTCIP 1202 v02 2.6.2 maxTimebaseAscActions
2.2.3.8 Monitor Current Schedule NTCIP 1203 v03 Clause G.1 NTCIP 1201 v03 Clause 2.4.4.5 timeBaseScheduleTableStatus
NTCIP 1201 v03 Clause 2.4.4.4 dayPlanStatus
2.2.23.9 Monitor Timing Pattern Configuration      
2.2.3.10 Monitor Current Timing Pattern NTCIP 1203 v03 Clause G.1 NTCIP 1202 v02 coordPatternStatus
2.2.3.11 Monitor Last Timing Pattern Requested      
2.2.3.12 Monitor Source of Last Timing Pattern      
2.2.3.13 Monitor Transition Mechanism Selected      
2.2.3.14 Monitor Timing Pattern Schedule      
2.2.3.15 Determine Current Access Settings NTCIP 1203 v03 Clause G.1 NTCIP 1103 v02 A.8.1 communityNameAdmin
NTCIP 1103 v02 A.8.2 communityNamesMax
NTCIP 1103 v02 A.8.3.1 communityNameIndex
NTCIP 1103 v02 A.8.3.2 communityNameUser
NTCIP 1103 v02 A.8.3.3 communityNameAccessMask
2.2.3.16 Determine Device Component Information NTCIP 1203 v03 Clause H.3.3 NTCIP 1201 v03 2.2.2 globalMaxModules
NTCIP 1201 v03 2.2.3.1 moduleNumber
NTCIP 1201 v03 2.2.3.2 moduleDeviceNode
NTCIP 1201 v03 2.2.3.3 moduleMake
NTCIP 1201 v03 2.2.3.4 moduleModel
NTCIP 1201 v03 2.2.3.5 moduleVersion
NTCIP 1201 v03 2.2.3.6 moduleType
2.2.3.17 Determine Supported Standards NTCIP 1203 v03 Clause G.1 NTCIP 1201 v03 2.2.4 controllerBaseStandards

2.6. Terms

2.6.1. Validation Rules

Validation rules are rules to ensure that the current set of timing parameters is internally consistent. They are applied before moving the set of timing parameters from a temporary buffer into normal memory space.

2.7. Application Level

The component shall conform to NTCIP 2301 as an RFC 1157 SNMP managed agent <<or replace with management station>>.

2.8. Transport Level

<<TBD>>

2.9. Subnet Level

<<TBD>>

 

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

 

4. References

Actuated Traffic Signal Controllers

NTCIP

Systems Engineering

 

5. Study Questions

1. Which of the following statements is NOT true?

  1. User needs are used in a top-down approach to identify requirements
  2. You should read every SEP-based standard in order to get ideas for requirements
  3. Conformance Groups (CGs) are used in a bottom-up approach to identify requirements
  4. You may discover overlaps in requirements from different user needs

 

2. Why should dialogs be defined in a procurement specification?

  1. Devices are more likely to conform with the standard
  2. Devices are more likely to interoperate with the central system
  3. Devices are more likely to be interchangeable with other devices using the same procurement
  4. Devices are likely to be less expensive

 

3. Which is NOT a benefit of traceability tables?

  1. They clearly identify the objects associated with a requirement
  2. They reference the relevant clauses where items are defined
  3. They explain the steps required in a test procedure
  4. They provide traceability back to the user need

 

4. Which of the following statements are true?

  1. The interface specification is the most important part of a procurement
  2. An interface specification should contain or reference dialogs
  3. An interface specification must define the communications stack
  4. A central system should only support one interface