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 Standard

HTML of the PowerPoint Presentation

(Note: This document has been converted from a PowerPoint presentation 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.)

Slide 1:

(Extended Text Description: Slide 1: Welcome - Graphic image of introductory slide. A large dark blue rectangle with a wide, light grid pattern at the top half and bands of dark and lighter blue bands below. There is a white square ITS logo box with words “Standards ITS Training” in green and blue on the middle left side. The word “Welcome” in white is to the right of the logo. Under the logo box are the words “RITA Intelligent Transportation Systems Joint Program Office.”)

Slide 2:

A304a:

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

Slide 3:

Slide 4:

Instructor

Kenneth L. Vaughn, P.E.

President

Trevilon Corporation Herndon, VA, USA

Slide 5:

Target Audience

• Traffic engineering staff
• Traffic Management Center (TMC)/operations staff
• System developers
• Private and public sector users including manufacturers

Slide 6:

Recommended Prerequisite(s)

• I101: Using ITS Standards an Overview
• A101: Introduction to Acquiring Standards-based ITS Systems
• A102: Introduction to User Needs Identification
• A201: Details on Acquiring Standards-based ITS Systems
• C101: Introduction to the Communications Protocols and Their Uses in ITS Applications

Slide 7:

Curriculum Path (SEP)

(Extended Text Description: A graphical illustration indicating the sequence of training modules that lead up to and follow this course. Each module is represented by a box with the name of the module in it and an arrow showing the logical flow of the modules and the current module highlighted. This slide focuses on the modules that lead up to the current course. The first box is labeled “I101 Using ITS Standards: An Overview.” An arrow from this box connects it to a box labeled “A101 Introduction to Acquiring Standards-based ITS Systems.” An arrow from this box connects it to a box labeled “A102 Introduction to User Needs Identification.” An arrow from this box connects it to a box located at the start of the next line labeled “A201 Details on Acquiring Standards-based ITS Systems.” An arrow from this box connects it to a box labeled “C101 Intro. To Comm. Protocols and Their Use in ITS Applications.” This is followed by arrows connected two more boxes with grayed out text that are explained on the following slides. The next box, which represents the current course, now has its text displayed as “A304a Understanding User Needs for Field Management Stations – Part 1 Object Definitions for Signal System Masters Based on NTCIP 1210 Standard.” This is connected to one additional box with grayed out text, as "A304b Specifying Requirements for FMS –Part 1 Object Definitions for Signal System Masters Based on NTCIP 1210 Standard." )

Slide 8:

Learning Objectives

1. Review the structure of the NTCIP 1210 Standard
2. Identify specific Field Management Station (FMS) user needs within the context of Signal System Master (SSM)
3. Use the Protocol Requirements List (PRL) to select the user needs and link to requirements
4. Explain how the PRL table of the NTCIP 1210 Standard integrates into the FMS Specification

Slide 9:

Learning Objective #1 — Review the structure of the NTCIP 1210 standard

• Purpose of the standard
• Location of user needs and standards on systems engineering "V" diagram
• Identify components of the standard

Slide 10:

Learning Objective #1

History of NTCIP 1210

Version 1: v01.53 is the "ballot ready version."

• It contains known design flaws and is not yet ready for deployment - look for an update.
• User needs and requirements are not expected to change.
• Specification process should not change.
  

Slide 11:

Learning Objective #1

NTCIP Family

NTCIP: A family of standards for ITS

• Information level standards - Data to be exchanged
• Underlying standards - How data is exchanged

Slide 12:

Learning Objective #1

NTCIP Family

(Extended Text Description: A graphic of the communication levels of the NTCIP standards. The bottom level is the Plant Level and includes boxes for Dial-up, Fiber, Coax, Wireless, Twisted Pair, and Leased Line. The next higher level is called the Subnetwork Level and includes PPP, Ethernet, and PMPP. The next level is called the Transport Level and includes TCP/IP, UDP/IP, and T2/NULL. The next level is called the Application Level and includes C2C XML, DATEX, FTP, TFTP, SNMP, and STMP. The next level is called the Information Level and includes C2C Messages, Files, Data Objects, and Dynamic Objects. These boxes are connected to an overarching box also in the Information Level labeled Functional Area Data Dictionaries with the left hand side identifying C2C Data Dictionaries and the right hand side labeled NTCIP Data Dictionaries. The NTCIP Data Dictionaries is highlighted with a circle indicating that it is the subject of the NTCIP 1210 standard. )

Source: NTCIP 9001v04, Page 12, Figure 4

Slide 13:

Learning Objective #1

What is NTCIP 1210?

• Defines a communications interface standard
  • Between SSM and monitoring (e.g., central) systems
    • An SSM is one type of FMS
  • Closely related to Actuated Signal Controllers
  • NTCIP 1202
• Includes Systems Engineering Process (SEP) content
  • User needs, requirements, and design elements

Slide 14:

Learning Objective #1

Structure of the Standard

Overview

• Defines user needs supported by the standard
  • E.g., Implement Plan Based on Timebase Schedule
• Defines functional requirements supported by the standard
  • E.g., Synchronize SSM Clock with Traffic Management System (TMS)
• Defines a single design for each requirement
  • Supports interoperability

Slide 15:

Learning Objective #1

Structure of the Standard

Location in SEP

(Extended Text Description: A graphic of the systems engineering process (SEP). The main graphic of the SEP is a V-shaped diagram with some additional horizontal “wings” on the left and right side of the top of the V. Starting from the left “wing” the steps are project planning and systems engineering management planning. At this point the steps begin to descend the left side of the V with concept of operations, system requirements, high-level design, subsystem requirements, detailed design,(grey-out animation here) and software coding / hardware fabrication. At this point the steps begin to ascend the right side of the V with unit testing, subsystem integration, subsystem verification, system integration, system verification, initial deployment, system validation, and operations and maintenance. Finally, the right “wing” includes a step for changes and upgrades. A small slice of the high-level design, subsystem requirements, and detailed design boxes have been shaded indicating that they are the subject of the NTCIP 1210 standard.)

Slide 16:

Learning Objective #1

Structure of the Standard

Outline

• Section 1: General
• Section 2: Concept of Operations (ConOps)
• Section 3: Functional Requirements
• Section 4: Dialog Specifications
• Section 5: Signal System Master Object Definitions
• Section 6: SSM Block Object Definitions
• Annex A: Requirements Traceability Matrix
• Annex B: SSM Device and Information Profile
• Annex C: SSM Control Hierarchy

Slide 17:

Learning Objective #1

Advantages of NTCIP 1210

Follows the Systems Engineering Process and yields the following benefits when procuring SSMs:

• Ease of use
• Easy to specify
• Easy to test
• Supports interoperability
• Provides drop-in user needs

Slide 18:

Slide 19:

Learning Objective #1

What is the purpose of the Systems Engineering Process?

Answer Choices

1. It provides a structured and reproducible approach to specifying a system.
2. It provides a structured and reproducible approach to testing a system.
3. It provides checkpoints at various stages of development to ensure the system will deliver what is needed.
4. All of the above.

Slide 20:

Learning Objective #1

Review of answers

a) Reproducible approach to specifying a system
This answer is incomplete because the SEP includes testing and validation checkpoints.

b) Reproducible approach to testing a system
This answer is incomplete because the SEP includes specifying and validation checkpoints.

c) Checkpoints at various stages of development
This answer is incomplete because the SEP includes specifying and testing the system.

d) All of the above
The SEP provides a reproducible approach for specifying and testing a system and provides checkpoints to ensure user needs are fulfilled.

Slide 21:

Summary of Learning Objective #1

NTCIP 1210 was developed using the Systems Engineering Process and contains:

• User needs
• Functional requirements
• Protocol Requirements List (traceability)
• Dialogs
• Object definitions
• Requirements Traceability Matrix (more traceability)

Slide 22:

Learning Objective #2 — Identify specific FMS user needs for an SSM

• NTCIP 1210 ConOps: architecture, architectural needs, and operational needs
• Introduce components of a Signal System Master (SSM) system

Slide 23:

Learning Objective #2

NTCIP 1210

Concept of Operations

• Focuses on the system and its users
• Considers the life cycle of the system
• Defines the user needs supported by the standard
• Provides an operational context for the system

Slide 24:

Learning Objective #2

NTCIP 1210

Problem Statement

• Agencies are required to efficiently manage system-wide traffic flow.
• There are competing definitions of efficient flow:
  • Minimizing delays, stops, and/or travel times
  • Maximizing throughput
  • Minimizing emissions
• There are competing algorithms to optimize these measures.
• Traffic data changes in real-time.
• Signal System Locals (SSLs) and SSMs are located throughout the city and need to be managed remotely.

Slide 25:

Learning Objective #2

NTCIP 1210

Typical Architecture

(Extended Text Description: A copy of Figure 3 from NTCIP 1210 page 13. It represents the typical physical architecture of a NTCIP 1210 deployment. It shows a traffic management system and a field computer on the left side, each with their own connection to a signal system master, located in the center-left of the diagram. The master is then connected to a signal system local on the center-right of the diagram, which is then connected to a signal head on the right side of the diagram. The communication links to the left of the signal system master, which connect to the traffic management system and field computer, are both highlighted as being the focus area of NTCIP 1210. The communication link joining the signal system master and the signal system local is highlighted (with a round red circle animation) as being the subject of NTCIP 1202. )

Typical physical architecture for NTCIP 1210

Source: NTCIP 1210, Fig. 3, Pg: 13

Slide 26:

Learning Objective #2

NTCIP 1210

Architecture Alternatives

Two common designs

• Remote signal system
  • E.g., dial-up operation
• Hierarchical distributed signal system
  • Always-on connection, but pattern selection is still performed in regional SSMs

Slide 27:

Learning Objective #2

NTCIP 1210

Architectural Needs

Provide live data (Mandatory - 'M')

• Data retrieval
• Commands
• The basic capabilities to exchange data when connected

Slide 28:

Learning Objective #2

NTCIP 1210 Architectural Needs

Provide off-line logged data (M)

• Addressing operational environments without always-on connections (e.g., dial-up locations)
• Monitoring exceptional conditions
• Logging is important for situations without communications or when recording field information

Slide 29:

Learning Objective #2

NTCIP 1210

Architectural Needs

Connect communication networks (M)

• The TMS often needs to connect to the SSL
• The SSM sits between the TMS and SSL
• The SSM needs to seamlessly connect the two

(Extended Text Description: A copy of figure from Slide 25, which represents the typical physical architecture of a NTCIP 1210 deployment. It shows a traffic management system and a field computer on the left side, each with their own connection to a signal system master, located in the center-left of the diagram. The master is then connected to a signal system local on the center-right of the diagram, which is then connected to a signal head on the right side of the diagram. A circle highlights the signal system master (SSM) and all of its communication links in order to stress the fact that the SSM is required to provide a seamless link across the connected devices.)

Source: NTCIP 1210, Figure 3, Page 13

Slide 30:

Learning Objective #2

NTCIP 1210

Architectural Needs

Support legacy communication networks (Optional -

• The connection to the SSM may be very low speed.
• NTCIP offers options to increase bandwidth efficiency.
• Most modern systems are designed with high-speed connections to the SSM.

Slide 31:

Learning Objective #2

NTCIP 1210

Operational Needs (Features)

Operational needs are called "features."

• Relate to the informational needs of the users
• Divided into two major categories
  • Manage SSM
  • Manage SSL

Slide 32:

Learning Objective #2

NTCIP 1210

Manage SSM Features

• Configure cycle timers and unit backup time
• Manage system timing plans
• Monitor system operations

Slide 33:

Learning Objective #2

NTCIP 1210

Cycle Timers and Backup Time

Configure cycle timers and unit backup time (M)

• Determine capabilities of an SSM
• Configure the SSM network of SSLs
• Configure a sync pulse for SSLs

Slide 34:

Learning Objective #2

NTCIP 1210

Manage System Timing Plans

Manage system timing plans includes several sub-features:

1. Manage section definition set
2. Implement a manually selected plan
3. Implement plan based on TMS command
4. Implement plan based on timebase schedule
5. Implement plan responsively based on traffic conditions
6. Configure plan selection mode schedule
7. Synchronize clocks of SSLs
8. Configure cycle length by plan

Slide 35:

Learning Objective #2

NTCIP 1210

Manage System Timing Plans

1. Manage section definition set (M)

• Allows a TMS operator to assign an SSL to a section
• Each section is timed as a coordinated system

Slide 36:

Learning Objective #2

NTCIP 1210

Manage System Timing Plans

2. Implement a manually selected plan (M)

• Allows a Traffic Management System (TMS) operator to manually override plan selection
• Stays in effect until changed

Slide 37:

Learning Objective #2

NTCIP 1210

Manage System Timing Plans

3. Implement plan based on TMS command (M)

• Allows automatically-generated TMS plan selection
  • Could be time-based
  • Could be algorithmic
• SSM will override if communication is lost

Slide 38:

Learning Objective #2

NTCIP 1210

Manage System Timing Plans

4. Implement plan based on timebase schedule (M)

• Allows the TMS to automatically select the plan based on time-of-day
• Allows for different schedules by day-of-week and holidays
• Useful when traffic patterns are predictable

Slide 39:

Learning Objective #2

NTCIP 1210

Manage System Timing Plans

5. Implement plan responsively based on traffic conditions

Configure traffic responsive mode (M)

• Allows selection of algorithm
  • Must support threshold and/or signature selection
• Allows configuration of features common to both algorithms
• Each algorithm allows selection among a wide variety of plans with different cycles, splits, and offsets

Slide 40:

Learning Objective #2

NTCIP 1210

Manage System Timing Plans

5. Implement plan responsively based on traffic conditions

Configure threshold selection (O*)

• Plan selection is based on weighted system detector readings as they cross upper and lower thresholds
• System detectors are grouped into 9 groups that jointly determine cycle, split, and offset parameters

* Optional, but either this or the next feature must be selected.

Slide 41:

Learning Objective #2

NTCIP 1210

Manage System Timing Plans

5. Implement plan responsively based on traffic conditions

Configure signature selection (O*)

• Plan selection is based on how closely current conditions match a defined signature of system detector readings.

* Optional, but either this or the previous feature must be selected.

Slide 42:

Learning Objective #2

NTCIP 1210

Manage System Timing Plans

6. Configure plan selection mode schedule (M)

• Allows the SSM to use traffic responsive plan selection according to a defined schedule
• Allows user to force plan selection during certain times (e.g., known peak periods) while allowing more responsive operation at other times

Slide 43:

Learning Objective #2

NTCIP 1210

Manage System Timing Plans

7. Synchronize clocks of SSLs (M)

• Allows an SSM to synchronize the time-of-day clocks in each connected SSL (either by schedule or manually)
• Provides each SSL with its own common reference point when timing its own signal operations
• Alternative to using a sync-pulse

Slide 44:

Learning Objective #2

NTCIP 1210

Manage System Timing Plans

8. Configure cycle length by plan (SyncPulse:M)

• Allows each plan to be associated with a cycle length
• The SSM can then generate a sync pulse so that all signals have a common reference point every cycle
• An alternative to synchronizing clocks
  • Generally used with older equipment that do not have accurate clocks
  • Only required if specification requires use of sync pulses

Slide 45:

Learning Objective #2

NTCIP 1210

Monitor System Operation

• Monitoring system operation includes:
  1. Managing alarms:
     1. Loss of control of SSLs
     2. Failed system detectors
     3. Other SSL alarms
     4. Forward SSM alarms and events
  2. Manage System Display Data
  3. Monitor Traffic Conditions

Slide 46:

Learning Objective #2

NTCIP 1210

Monitor System Operation

1.a. Loss of control of SSLs (M)

• Allows the TMS to monitor the number of SSLs that are not actively communicating with the SSM
• Allows the SSM to return control to SSLs if too many SSLs stop communicating

Slide 47:

Learning Objective #2

NTCIP 1210

Monitor System Operation

1.b. Failed system detectors (M)

• Allows the SSM to terminate traffic responsive operation if the number of working system detectors fall below a defined level

Slide 48:

Learning Objective #2

NTCIP 1210

Monitor System Operation

1.c. Other SSL alarms (M)

• Allows the SSM to relay other SSL alarms to the TMS, such as:
  • Local flash
  • Malfunction Management Unit (MMU) flash
  • Coordination failures
  • Stop time
  • Low battery
  • Power restart

Slide 49:

Learning Objective #2

NTCIP 1210

Monitor System Operation

1.d. Forward SSM alarms and events (M)

• User can configure SSM to monitor any parameter and report when this parameter meets user-defined conditions

Slide 50:

Learning Objective #2

NTCIP 1210

Monitor System Operation

2. Manage system display data (M)

• Allows a TMS operator to monitor data needed to ensure the proper, efficient operation of the system
  • Fault information
  • Current configuration and status of SSM
  • Certain status information for each SSL

Slide 51:

Learning Objective #2

NTCIP 1210

Monitor System Operation

3. Monitor traffic conditions (M)

• Allows collection of volume and occupancy data summarized over a period of time
• Can be used to determine when new timing plans might be needed

Slide 52:

Learning Objective #2

NTCIP 1210

Manage Signal System Locals (SSLs)

• Manage SSLs (Optional, but really Mandatory)
  • Allows communications with an SSL.
  • Data to be exchanged is dependent on type of SSL.
  • Data is defined in an SSL specific standard (e.g., NTCIP 1202).
  • The Standard labels this as optional, but the entire design is required per architectural requirements.

Slide 53:

Slide 54:

Learning Objective #2

Which user need allows the SSM to instantly notify the user of unusual traffic conditions?

Answer Choices

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. User need is not supported by the standard

Slide 55:

Learning Objective #2

Review of answers

a) 2.4.1 Provide Live Data
Incorrect; an SSM will only provide live data in direct response to a request.

b) 2.4.2 Provide Off-line Logged Data
Incorrect; an SSM will only provide the logged data in direct response to a request.

c) 2.5.1.3.1.4 Forward SSM Alarms and Events
Incorrect; an SSM will only provide this data in direct response to a request.

d) User need is not supported by the standard
Correct; if this is a true need, the project will need to define how this should be achieved.

Slide 56:

Summary of Learning Objective #2

Operational needs supported include:

• Configure cycle timers
• Manage system timing plans
• Monitor system operation
• Manage SSLs

Slide 57:

Learning Objective #3 — Use Protocol Requirements List (PRL) to select user eds and link to requirements

• Learn how to:
  • Indicate which requirements are to be implemented for a project.
  • Check for conformance to NTCIP 1210.
  • Indicate the capabilities of an implementation.
  • Check the interoperability with another implementation.

Slide 58:

Learning Objective #3

Protocol Requirements List

Definition

• A table that maps user needs to requirements
• Can be used to:
  • Select requirements for a project
  • Assist deployments by providing a checklist
  • Identify capabilities supported by an implementation
  • Compare two implementations for interoperability

Slide 59:

Learning Objective #3

Protocol Requirements List

Selecting User Needs

• User Need ID references a precise clause in standard
• Conformance identifies mandatory or optional
  • "O" = Optional
  • ".1" = Part of first option group
  • "(1..*)" = One or more options from group required
• Agency selects value under Project Requirement column

User Need ID	User Need	FR ID	Functional Requirement	Conformance	Project Requirement	Additional Project Requirements
2.5.1.2.5.2	Configure Threshold Selection			O.1 (1..*)	Yes / No / NA

Slide 60:

Slide 61:

Learning Objective #3

Scenario for Quiz Questions

Sample Project to Deploy SSMs

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

• Regional masters to control normal operations
• To be able to monitor detailed operations of local controllers when needed
• Time-of-day pattern selection
• Signature selection for traffic responsive operation
• Instant notification of unusual traffic conditions

Slide 62:

Learning Objective #3

Which of the following user needs does not need to be selected for our scenario?

See Student Supplement for PRL

Answer Choices

	User Need ID	User Need	FR ID	Functional Requirement	Conformance	Project Requirement	Additional Project Requirements
a)	2.5.1.2.4	Implement Plan Based on Timebase Schedule			M	Yes
b)	2.5.1.2.5.1	Configure Traffic Responsive Mode			M	Yes
c)	2.5.1.2.5.2	Configure Threshold Selection			O.1 (1..*)	Yes / No
d)	2.5.1.2.5.3	Configure Signature Selection			O.1 (1..*)	Yes / No

Slide 63:

Learning Objective #3

Review of answers

a) 2.5.1.2.4: Implement Plan Based on Timebase Schedule
Incorrect; this user need is needed for time-of-day pattern selection and is mandatory.

b) 2.5.1.2.5.1: Configure Traffic Responsive Mode
Incorrect; this user need is mandatory.

c) 2.5.1.2.5.2: Configure Threshold Selection
Correct! This user need is a part of the first option group and can be omitted if 2.5.1.2.5.3 is selected.

d) 2.5.1.2.5.3: Configure Signature Selection
Incorrect; while this is part of an option group, it is needed to support signature selection.

Slide 64:

Learning Objective #3

Which of the following user needs does not need to be selected for our scenario?

See Student Supplement for PRL

Answer Choices

	User Need ID	User Need	FR ID	Functional Requirement	Conformance	Project Requirement	Additional Project Requirements
a)	2.4.1	Provide Live Data			M	Yes
b)	2.4.2	Provide Off-line Logged Data			M	Yes
c)	2.4.4	Support Legacy Communication Networks			O	Yes / No
d)	2.5.1.3.2	Manage System Display Data			M	Yes

Slide 65:

Learning Objective #3

Review of answers

a) 2.4.1: Provide Live Data
Incorrect; this user need is mandatory.

b) 2.4.2: Provide Off-line Logged Data
Incorrect; this user need is mandatory.

c) 2.4.4: Support Legacy Communication Networks
Correct! This optional user need is not necessary for the project's stated goals.

d) 2.5.1.3.2: Manage System Display Data
Incorrect; this user need is mandatory.

Slide 66:

Learning Objective #3

Protocol Requirements List

Traceability to Requirements

• User needs describe what features the device needs to support and why.
• Functional requirements refine the user needs into detailed, measurable specifications.
• Within the PRL, the relationships between user needs and functional requirements are standardized.
  • User needs justify and explain requirements
  • Requirements refine needs to measurable concepts
  • Promotes interoperability

Slide 67:

Learning Objective #3

Protocol Requirements List

Traceability to Requirements

• Functional Requirements Identifier (FR ID)
• Functional Requirement

User Need ID	User Need	FR ID	Functional Requirement	Conformance	Project Requirement	Additional Project Requirements
2.5.1.2.5.2	Configure Threshold Selection			O.1 (1..*)	Yes / No
		3.4.1.2	Configure Detector Grouping	M	Yes
		3.4.3.5.3.5	Configure Queue Detector Override Thresholds	O	Yes / No

Slide 68:

Learning Objective #3

Protocol Requirements List

Conformance

• Predicate - The user needs applies only if a condition or feature is supported.
• Predicates are defined in Clause 3.2.3.2.
• Threshold is defined to be user need 2.5.1.2.5.1.

User Need ID	User Need	FR ID	Functional Requirement	Conformance	Project Requirement	Additional Project Requirements
		3.4.4.1.4.2	Failed System Detectors for Threshold Selection of Timing Plans	Threshold: M	Yes / NA

Slide 69:

Learning Objective #3

Protocol Requirements List

Conformance

• Built-in predicate between needs and requirements
• "Configure Queue Detector Override Thresholds" is only applicable if "Configure Threshold Selection" is selected

User Need ID	User Need	FR ID	Functional Requirement	Conformance	Project Requirement	Additional Project Requirements
2.5.1.2.5.2	Configure Threshold Selection			O.1 (1..*)	Yes / No
		3.4.1.2	Configure Detector Grouping	M	Yes
		3.4.3.5.3.5	Configure Queue Detector Override Thresholds	O	Yes / No

Slide 70:

Learning Objective #3

Protocol Requirements List

Conformance

• Mandatory vs. Optional
  • If a user need is not selected, its associated requirements are not necessary, unless they are required by another user need selection.

User Need ID	User Need	FR ID	Functional Requirement	Conformance	Project Requirement	Additional Project Requirements
2.4.3	Connect Communication Networks			M	Yes
		3.3.1.6	Explore SSL Data by the TMS	M	Yes
2.5.2	Manage SSLs			O	Yes t No
		3.3.1.6	Explore SSL Data by the TMS	M	Yes

Slide 71:

Learning Objective #3

Protocol Requirements List

Additional Project Requirements

• Used to enter additional notes and requirements
  • E.g., Defining performance ranges and sizes of data tables
• Used to provide further details about an implementation

User Need ID	User Need	FR ID	Functional Requirement	Conformance	Project Requirement	Additional Project Requirements
2.4.1	Provide Live Data			M	Yes
		3.3.1.2	Deliver Data to the TMS	M	Yes	The Response Start Time for all requests shall be not greater than ______ milliseconds (Default 2000).

Slide 72:

Slide 73:

Learning Objective #3

Scenario for Quiz Questions

Sample Project to Deploy SSMs

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

• Regional masters to control normal operations
• To be able to monitor detailed operations of local controllers when needed
• Time-of-day pattern selection
• Signature selection for traffic responsive operation
• Instant notification of unusual traffic conditions

Slide 74:

Learning Objective #3

Should the following user need be selected for our project?

See Student Supplement for PRL

User Need ID	User Need	FR ID	Functional Requirement	Conformance	Project Requirement	Additional Project Requirements
2.5.1.1	Configure Cycle Timers and Unit Backup Time			M	Yes

a) Yes

b) No

Slide 75:

Learning Objective #3

Review of answers

a) Yes
Correct! The "Configure Cycle Timers and Unit Backup Time" user need is mandatory.

b) No
This user need is mandatory and should always be selected.

Slide 76:

Learning Objective #3

Should the following user need be

selected for our project?

See Student Supplement for PRL

User Need ID	User Need	FR ID	Functional Requirement	Conformance	Project Requirement	Additional Project Requirements
2.5.1.2.5.2	Configure Threshold Selection			O.1 (1..*)	Yes / No

a) Yes

b) No

Slide 77:

Learning Objective #3

Review of answers

a) Yes
Incorrect. The "Configure Threshold Selection" user need is optional and is not required since it does not support traffic pattern signature capabilities, which is the stated focus of the project.

b) No
Correct! This user need is not needed to fulfill the stated project capabilities.

Slide 78:

Learning Objective #3

Should the following user need be

selected for our project?

See Student Supplement for PRL

User Need ID	User Need	FR ID	Functional Requirement	Conformance	Project Requirement	Additional Project Requirements
2.5.1.2.5.3	Configure Signature Selection			O.1 (1..*)	Yes / No

a) Yes

b) No

Slide 79:

Learning Objective #3

Review of answers

a) Yes
Correct! The "Configure Signature Selection" user need is needed to fulfill the stated project requirements.

b) No
Incorrect. This user need is necessary to fulfill the traffic pattern signature capabilities, which is the stated focus of the project.

Slide 80:

Learning Objective #3

Protocol Requirements List

Agency's PRL

An agency's completed PRL is useful.

• Specifies the needs and requirements for a project
• Requirements map to an interoperable design
• Becomes part of plans, specifications, and estimates (PS&E) package
• A vendor may "exceed the specification"
  • Support features not selected
  • Allows vendor to bid on more projects with a single model
• Can be used as a checklist during development
• Serves as the basis of selecting test procedures

Slide 81:

Learning Objective #3

Protocol Requirements List

Vendors' PRLs

Vendors can complete PRLs to describe their products.

• Quickly tells agencies which features are supported by the product
• Agency can archive with project documentation

Slide 82:

Learning Objective #3

Protocol Requirements List

Interoperability

PRLs can be used to check for degree of interoperability

• For a feature to work, both the management system and the device must support the feature.

Slide 83:

Summary of Learning Objective #3

The PRL:

• Links user needs and requirements
• Allows selection of user needs and requirements
• Provides a checklist of features to consider
• Provides a listing of features supported by an implementation
• Provides a useful way to compare products for interoperability

Slide 84:

Learning Objective #4

Explain how the PRL table of the NTCIP 1210 standard integrates into an FMS specification.

Slide 85:

Learning Objective #4

Integrating a PRL into a Specification

Part of Interface Specification

• A completed PRL defines the data requirements for the NTCIP interface.
• When combined with the communication specification (See Module C101), it forms an interface specification.
• A deployment may need multiple interface specifications.
  • Management systems that support multiple devices
  • May need support for legacy protocol

Slide 86:

Learning Objective #4

Integrating a PRL into a Specification

Consistency

• The interface specification must be consistent with the remainder of the specification.
• Interface requires ability to synchronize clocks
  • Implies existence of clock in SSM
  • Requires software logic for SSM to periodically synchronize clocks

(Extended Text Description: A graphic illustration of three partially overlapping circles - two on top and one on the bottom of equal size - related to integrating a PRL into a specification. A red circle (top left) labeled "Hardware Specification" intersects with a yellow circle (top right) labeled "Interface Specification," which both intersect with a blue circle (bottom center) labeled "Software Specification." The overlap symbolizes that each of these specifications are likely to cover topics that relate to other portions of the specifications and that care must be taken to avoid any conflict between these distinct sections of the overall procurement package.)

Slide 87:

Learning Objective #4

Integrating a PRL into a Specification

Sample Text

• The PRL should be properly introduced within the specification.
• A copyright disclaimer should appear with the PRL.
• Additional requirements are needed for NTCIP 1210.
  • NTCIP 1210 fails to identify all of the necessary "Additional Project Requirements" such as number of intersections that must be supported.
• See Student Supplement for sample text.

Slide 88:

Slide 89:

Learning Objective #4

Which of the following statements is false?

Answer Choices

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.

Slide 90:

Learning Objective #4

Review of answers

a) A vendor may support features not selected.
They may be provided if they are not explicitly prohibited and certain rules are followed.

b) The PRL forms a complete interface specification.
Correct, the PRL must first be coupled with a communication specification.

c) A deployment may support multiple interfaces.
The system may need to support legacy interfaces or other device types.

d) Interface must be consistent with hardware and software.
All interface portions must be consistent with all other parts of the specification.

Slide 91:

Summary of Learning Objective #4

The PRL:

• Should be included in specification
• Should not conflict with other portions of the specification
• Should be supplemented with additional text per the Student Supplement

Slide 92:

What We Have Learned

1. NTCIP 1210 defines the concept of operations and user needs for Signal System Masters.
2. NTCIP 1210 follows the SEP approach.
3. There are four major categories of SSM user needs.
   1. Configure Cycle Timers
   2. Manage System Timing Plans
   3. Monitor System Operation
   4. Manage SSLs
4. A Protocol Requirements List is used to link user needs to functional requirements.
5. A completed PRL should be integrated into the project specifications.

Slide 93:

Resources

• NTCIP 1210 v01.53
  • Field Management Stations - Part 1: Object Definitions for Signal System Masters
  • www.ntcip.org
• NTCIP 9001
  • The NTCIP Guide
  • www.ntcip.org
• IEEE 1362
  • IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document
  • www.ieee.org

Slide 94:

Slide 95:

Next Course Module

A304b: Specifying Requirements for Field Management Stations - Part 1: Object Definitions for Signal System Masters (SSM) Based on NTCIP 1210 Standard

• Reviews the requirements contained in the standard
• Shows relationships between requirements and design
• Shows how to select and refine requirements using PRL
• The final module in the SSM procurement path