Module 32 - A315b Part 1

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

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:

This slide contains a graphic with the word “Welcome” in large letters. ITS Training Standards “WELCOME” slide, with reference to the U.S. Department of Transportation Office of Assistant Secretary for Research and Technology

Slide 2:

This slide contains a graphic with the word “Welcome” in large letters, photo of Kenneth Leonard, Director ITS Joint Program Office - Ken.Leonard@dot.gov - and on the bottom is a screeshot of the ITS JPO website - www.its.dot.gov/pcb

Slide 3:

Module A315b Part 1:

Specifying Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 v03 Standard

Part 1 of 2

Author's relevant description: The title slide shows photo of a 2070 traffic signal controller.

Updated June 2020

Slide 4:

Instructor

Photo of Kenneth L. Vaughn, President, Trevilon LLC

Kenneth L. Vaughn

President

Trevilon LLC

Slide 5:

Learning Objectives

Slide 6:

Learning Objective 1

Slide 7:

Identify NTCIP 1202 v03 Standard Requirements

Overview

Slide 8:

Scope of NTCIP 1202 v03

This slide provides a graphical overview of ASC connected equipment. The ASC (represented by a 2070 controller) is shown in the upper middle. On the left, the ASC is connected by red lines to both a Traffic Management Center (represented by a photograph of a traffic management center operations floor) and a maintenance laptop (represented by a laptop icon). On the right, the ASC is connected by a red line to a Connected Vehicle Roadside Unit (RSU, represented by a photograph of a field controller cabinet). Underneath the ASC, the 2070 is connected with a dashed blue line to a photograph of a signal cabinet with an open door to show all of the connections that occur within the cabinet. Below the image of the cabinet, a dashed blue line connects graphics of four items to depict items that the cabinet is connected to and include, from left to right: a pedestrian push button, a radar vehicle detector, a vehicle signal head, and a pedestrian signal head. Underneath the RSU, there is blue dashed line connecting a Wi-Fi router that is labeled Short Range Wireless Radio to reflect a DSRC or similar radio. This radio unit is shown to be emitting waves via blue dashed lines to a car (representing general vehicles), a bus (representing priority and preemption), and a pedestrian, each represented by icons. The car, bus, and pedestrian are also shown to be emitting radio waves back to the Wi-Fi router. A legend explains that the red lines are within scope of NTCIP 1202 v03 while the blue dashed lines are not.

Slide 9:

Scope of NTCIP 1202 v03

Changes since v02

A computer graphic that includes a representation of a person that is displaying the word “New” on a starry background.

Slide 10:

What Is a Requirement?

Goal for Requirements

A statement that identifies a system, product or process characteristic or constraint, which is unambiguous, clear, unique, consistent, stand-alone (not-grouped), and verifiable, and is deemed necessary for stakeholder acceptability

- INCOSE 2010

A photograph of a person that is pointing to a word that has been overlaid on the graphic. The word is “definition”.

Slide 11:

What Is a Requirement?

Goal for Requirements

A statement that identifies a system, product or process characteristic or constraint, which is unambiguous, clear, unique, consistent, stand-alone (not-grouped), and verifiable, and is deemed necessary for stakeholder acceptability

- INCOSE 2010

Types of Requirements in NTCIP 1202 v03

Slide 12:

Structure of NTCIP 1202 v03

Please see Extended Text Description below:

(Extended Text Description: This slide contains a bullet list as indicated below:

Outline

To the right of the bullet list is a legend that groups the bullet list items into the following categories:

Functional ("What") Requirements - (Section 3)
Design ("How") Requirements - (Sections 4-7)
Traceability Requirements - (Section 3 - includes Protocol Requirements List (PRL) and Annex A)
Other text - (Sections 1-2 and Annex B)

)

Slide 13:

Structure of NTCIP 1202 v03

Please see Extended Text Description below:

(Extended Text Description: This slide contains a bullet list as indicated below:

Outline

To the right of the bullet list is a legend that groups the bullet list items into the following categories:

Functional ("What") Requirements - (Annex H)
Design ("How") Requirements - (Annexes F-G, Annex H dialogs, and Annex I)
Traceability Requirements - None
Other text - (Annexes C-E)

)

Slide 14:

Structure of NTCIP 1202 v03

Traceability Requirements

At the bottom of this slide are four colored boxes connected by lines. On the left is a grey box labeled “User Need”. It has an orange arrow, labeled “PRL”, pointing to the right to a green box labeled “Functional Requirement”. The green box then has two orange arrows pointing to the right; these arrows are labeled “RTM”. The upper arrow points to a blue box labeled “Dialog” and the lower arrow points to a blue box labeled “Object”.

Slide 15:

Organization of Functional Requirements

At the bottom of this slide are two grey boxes and five green boxes that are connected by orange lines. The grey boxes are shown to represent user needs while the green boxes are shown to represent functional requirements as in Slide #14. The orange lines between these boxes are labeled “PRL”. The top grey box is labeled “2.5.2.1.10 Manage Timing Pattern Scheduler” and is connected by orange arrows to four green boxes labeled “3.5.2.1.10.1.1 Configure Timebase Pattern Synchronization Time”, “H..1.1.5.1 Configure Time”, “H.1.1.5.2 Configure Time Zone”, and “H.1.1.5.3 Configure Daylight Savings Mode”. The bottom grey box is labeled “2.6.4 Log User Access” and is connected by orange arrows to four green boxes labeled “H..1.1.5.1 Configure Time”, “H.1.1.5.2 Configure Time Zone”, “H.1.1.5.3 Configure Daylight Savings Mode”, and “H.1.3.1.2 Configure Event Logging Service”. Three of these green boxes are the same as connected to the top grey box showing that there is a many-to-many relationship between user needs and requirements.

Slide 16:

Organization of Functional Requirements

Slide 17:

Organization of Functional Requirements

Slide 18:

Organization of Design Requirements

Requirements Traceability Matrix (RTM)

At the bottom of this slide is one blue box on the left, two green boxes in the middle, and two blue boxes on the right. The boxes have connections via orange lines. The blue box on the left is shown to represent a dialog, the middle green boxes are shown to represent functional requirements, and the blue boxes on the right are shown to represent objects (i.e., the same color code as in Slide #14). The orange lines between these boxes are labeled “RTM”. the blue boxes indicate design-level elements. The top green box is labeled “Configure Vehicle Phase Minimum Green Time” and is connected on the left to the blue box labeled “Generic Configure Table Row”. On the right the green box is connected to both blue boxes, which are labeled “phaseNumber” and “phaseMinimumGreen”. The bottom green box is labeled “Configure Transit Phase Minimum Green Time” and has the exact same connections as does the top green box. This indicates that while every functional requirement is only associated with one standardized dialog, a standardized dialog can be associated with multiple functional requirements. Further the lines to the objects indicate a many-to-many relationship between functional requirements and objects.

Slide 19:

Organization of Design Requirements

Slide 20:

General Format for Functional Requirements

[Localization] [Actor] [Action] [Target] [Constraint]

Slide 21:

Sample Functional Requirement

[Localization] [Actor] [Action] [Target] [Constraint]

Upon request from a management station, the ASC shall store the minimum amount of time the Green indication is to be displayed for a phase in seconds, between 0 and 255 seconds.

- NTCIP 1202 v03, 3.5.2.1.2.1.2

This slide shows the same image that was shown on Slide #18, but the top green box is circled with an arrow pointing to the requirement text that is presented on the slide. This indicates that the text on the slide is the standard’s text for this functional requirement. The different slides highlight different part of the requirement text.

Slide 22:

Sample Functional Requirement

[Localization] [Actor] [Action] [Target] [Constraint]

Upon request from a management station, the ASC shall store the minimum amount of time the Green indication is to be displayed for a phase in seconds, between 0 and 255 seconds.

- NTCIP 1202 v03, 3.5.2.1.2.1.2

This slide shows the same image that was shown on Slide #18, but the top green box is circled with an arrow pointing to the requirement text that is presented on the slide. This indicates that the text on the slide is the standard’s text for this functional requirement. The different slides highlight different part of the requirement text.

Slide 23:

Sample Functional Requirement

[Localization] [Actor] [Action] [Target] [Constraint]

Upon request from a management station, the ASC shall store the minimum amount of time the Green indication is to be displayed for a phase in seconds, between 0 and 255 seconds.

- NTCIP 1202 v03, 3.5.2.1.2.1.2

This slide shows the same image that was shown on Slide #18, but the top green box is circled with an arrow pointing to the requirement text that is presented on the slide. This indicates that the text on the slide is the standard’s text for this functional requirement. The different slides highlight different part of the requirement text.

Slide 24:

Sample Functional Requirement

[Localization] [Actor] [Action] [Target] [Constraint]

Upon request from a management station, the ASC shall store the minimum amount of time the Green indication is to be displayed for a phase in seconds, between 0 and 255 seconds.

- NTCIP 1202 v03, 3.5.2.1.2.1.2

This slide shows the same image that was shown on Slide #18, but the top green box is circled with an arrow pointing to the requirement text that is presented on the slide. This indicates that the text on the slide is the standard’s text for this functional requirement. The different slides highlight different part of the requirement text.

Slide 25:

Sample Functional Requirement

[Localization] [Actor] [Action] [Target] [Constraint]

Upon request from a management station, the ASC shall store the minimum amount of time the Green indication is to be displayed for a phase in seconds, between 0 and 255 seconds.

- NTCIP 1202 v03, 3.5.2.1.2.1.2

This slide shows the same image that was shown on Slide #18, but the top green box is circled with an arrow pointing to the requirement text that is presented on the slide. This indicates that the text on the slide is the standard’s text for this functional requirement. The different slides highlight different part of the requirement text.

Slide 26:

Structure of Requirements

Sample Object

phaseMinimumGreen OBJECT-TYPE

SYNTAX INTEGER (0..255)

ACCESS read-write

STATUS mandatory

DESCRIPTION "<Definition> Phase Minimum Green Parameter in seconds (NEMA TS 2 range: 1-255 sec). The first timed portion of the Green interval which may be set in consideration of the storage of vehicles between the zone of detection for the approach vehicle detector(s) and the stop line.

<Object Identifier>1.3.6.1.4.1.1.1206.4.2.1.1.2.1.4

<Unit> second"

REFERENCE "NEMA TS 2 Clause 3.5.3.1 and 3.5.3.2.1.a.(1)"

::= {phaseEntry 4}

This slide shows the same image that was shown on Slide #18, but the blue box on the right, labeled “phaseMinimumGreen” is circled with an arrow pointing to the text that is presented on the slide. This indicates that the text on the slide is the standard’s text for this object.

Slide 27:

Structure of Requirements

Sample Dialog

Please see Extended Text Description below:

(Extended Text Description: This slide contains the following text, along with a diagram at the bottom plus several overlay arrows. The main body text is as follows:

The standardized dialog for a management station to configure a table row shall be as follows:

  1. (Precondition) The management station shall be aware of which row in the table is to be configured.
  2. For the specified row, the management station shall SET all objects (to their desired values) referenced by the specific dialog that references this generic dialog, except for the index object(s).

– NTCIP 1202 v03, H.2.7

Author's relevant description: Below the text, this slide shows the same image that was shown on Slide #18, but the blue box on the left, labeled "Generic Configure Table Row", is circled with an arrow pointing to a UML sequence diagram that shows a management station sending a "SET(phaseMinimumGreen.2 = 4)" request to a controller. Above this diagram is the text from the standard that explains the dialog.

As the presenter discusses the slide, we see that the "phaseNumber" box is an index object that specifies a row in the table. In this example, we refer to Phase 2, which is the "2" in the "phaseMinimumGreen.2" in the sequence diagram. We then see that the standard says that the SET request will be for all objects except for index objects. So, the phaseNumber is shown to be an index object and phaseMinimumGreen is included as an object in the SET request. Finally, we see that the SET request sets the object to the desired value; in this example, we assign a number of 4.)

Slide 28:

Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.

Slide 29:

Question

Which of the following is missing from NTCIP 1202 v03?

Answer Choices

  1. User needs
  2. Functional requirements
  3. Test procedures
  4. All of the above

Slide 30:

Review of Answers

A small graphical red and yellow X representing incorrect.a) User needs
Incorrect. NTCIP 1202 v03 added user needs.

A small graphical red and yellow X representing incorrect.b) Functional requirements
Incorrect. NTCIP 1202 v03 added functional requirements.

A small graphical green and yellow check mark representing correct.c) Test procedures
Correct! While NTCIP 1202 v03 includes an Annex C for test procedures, it is empty and left as future work.

A small graphical red and yellow X representing incorrect.d) All of the above
Incorrect. NTCIP 1202 v03 includes both user needs and requirements.

Slide 31:

Learning Objective 2

Slide 32:

Purpose and Benefits of the RTM

Overview

Slide 33:

Understand Interoperability and Interchangeability

Interoperability

Degree to which two or more systems, products or components can exchange information and use the information that has been exchanged

- ISO/IEC 25010:2011

In the lower left of this slide is a photograph of a man that is pointing to a word that has been overlaid on the graphic. The word is “definition”. In the lower right, there is an ASC (represented by a 2070 controller) connected to a Traffic Management Center (represented by a photograph of a traffic management center operations floor) with a two-headed arrow labeled “Information”.

Slide 34:

Understand Interoperability and Interchangeability

Interoperability and NTCIP

Degree to which two or more systems, products or components can exchange information

NTCIP standardizes dialogs and protocols

In the middle right of this slide is the same UML diagram that was on Slide #27. It shows a management station sending a “SET (phaseMinimumGreen.2 = 4)” request to a controller. To the left of this figure is the text “NTCIP standardizes dialogs and protocols” At the bottom of the slide we see the text of the object definition that was discussed on Slide #26.

and use the information that has been exchanged

NTCIP standardizes data to be exchanged

phaseMinimumGreen OBJECT-TYPE SYNTAX

INTEGER (0. .255)

ACCESS read-write

STATUS mandatory

DESCRIPTION "<Definition> Phase Minimum Green Parameter in seconds (NEMA TS 2 range: 1-255 sec). The first timed portion of the Green interval which may be set in consideration of the storage of vehicles between the zone of detection for the approach vehicle detector(s) and the stop line.

<0bject Identifier>l.3.6.1.4.1.1.1206.4.2.1.1.2.1.4

<Unit> second"

REFERENCE "NEMA TS 2 Clause 3.5.3.1 and 3.5.3.2.1.a.(1)"

::= {phaseEntry 4}

Slide 35:

Understand Interoperability and Interchangeability

Interchangeability

Ability of one product, process or service to be used in place of another to fulfill the same requirements.

- ISO/IEC Guide 2:2004

In the lower left of this slide is a photograph of a man that is pointing to a word that has been overlaid on the graphic. The word is “definition”. In the lower right, there is a signal cabinet with its door open. Inside, we see that the signal controller is actually a GIF image and every couple of seconds the graphic changes from a black 2070 controller to a reddish orange ATC controller.

Slide 36:

Understand Interoperability and Interchangeability

Interchangeability

Ability of one product, process or service to be used in place of another to fulfill the same requirements.

Please see Extended Text Description below:

(Extended Text Description: This slide contains the following bullet list with some overlays:

As the presenter is talking, we see lines appear from the "Functional" and "Performance" bullet items to the text: "At least partially within scope of NTCIP 1202 v03 "Interoperability Requirements" to the right.)

Slide 37:

Understand Interoperability and Interchangeability

Roles in Data Exchanges

Interoperability entails systems exchanging information

At the bottom of this slide, there is an ASC (represented by a 2070 controller) connected to a Traffic Management Center (represented by a photograph of a traffic management center operations floor) with a two-headed arrow labeled “Information”.

Slide 38:

Understand Interoperability and Interchangeability

Roles in Data Exchanges

A product can fulfill both roles, e.g., a signal controller might:

At the bottom of this slide, there is an ASC (represented by a 2070 controller) connected to 1) a Traffic Management System (represented by a photograph of a traffic management center operations floor) on the left of the ASC and 2) an RSU on the right of the ASC. We also see that the RSU is connected to the TMS as well. Both connector ends at the TMS (i.e., one from the ASC and one from the RSU) are labeled “Manager”. The connector ends at the opposite sides of these lines (i.e., at the ASC and RSU) are both labeled “Agent”. The labels of “Manager” and “Agent” on the connection between the ASC and the RSU rotate back and forth to indicate that one has to be defined in each role but the standard supports either approach.

Slide 39:

NTCIP Interchangeability (for Interoperability)

Combining definitions for interoperability and interchangeability, we get:

Degree to which one product can be used in place of another to exchange information and use the information that has been exchanged.

At the bottom of this slide, there is an ASC (represented by a 2070 controller) connected to a Traffic Management Center (represented by a photograph of a traffic management center operations floor) with a two-headed arrow labeled “Information”. However, after a couple of seconds we realize that the ASC graphic is actually a GIF that alternates between a black 2070 and a reddish orange ATC every few seconds.

Slide 40:

Project-Level NTCIP Interchangeability

Ability of one product to be used in place of another to exchange and use the information required for a specific project

At the bottom of this slide, there is an ASC (represented by a 2070 controller) connected to a Traffic Management Center (represented by a photograph of a traffic management center operations floor) with a two-headed arrow labeled “Information”. However, after a couple of seconds we realize that the ASC graphic is actually a GIF that alternates between a black 2070 and a reddish orange ATC every few seconds.

Slide 41:

Obtain Interoperability and Interchangeability

Conformance

Adherence of an implementation to the requirements of one or more specific standards or technical specifications

- ISO/IEC 10641:1993

A photograph of a person that is pointing to a word that has been overlaid on the graphic. The word is “definition”.

Slide 42:

Obtain Interoperability and Interchangeability

Compliance

Doing what has been asked or ordered, as required by rule or law

- IEEE 730-2014

A photograph of a person that is pointing to a word that has been overlaid on the graphic. The word is “definition”.

Slide 43:

Obtain Interoperability and Interchangeability

Comparing PRLs

Various Types of PRLs

Slide 44:

Obtain Interoperability and Interchangeability

Project PRL Identifies Options Required for a Project

UN ID User Need FR ID Func Req't Conform Support Add'l Spec.
2.5.2.1.2 Manage Phase Configurations M [Yes]
3.5.2.1.2.1.1 Enable/Disable Phase M [Yes]
3.5.2.1.2.1.2 Configure Vehicle Phase Minimum Green Time M [Yes]
3.5.2.1.2.1.4 Configure Vehicle Phase Maximum Green Times M [Yes]
3.5.2.1.2.1.5 Configure Vehicle Phase Third Maximum Green Times O < [Yes] / No
2.5.2.1.3 Manage Coordination Configurations [Yes] / No
3.5.2.1.3.6.1 Configure Coordination Point - First Phase Green Begin O.10 (1..*) Yes / [No]
3.5.2.1.3.6.2 Configure Coordination Point - First Phase Green End O.10 (1..*) [Yes] / No

Selected sampling of PRL items from NTCIP 1202 v03 - [Please note for HTML 508 version of this table: Items in brackets are selected.]

Slide 45:

Obtain Interoperability and Interchangeability

PRL Defines "What"

Graphical text with the word What

By itself, project PRL only identifies

Project PRL provides the foundation for interchangeability

Slide 46:

Obtain Interoperability and Interchangeability

RTM Defines "How"

Graphical text with the word How

RTM defines design details for each functional requirement

Slide 47:

Obtain Interoperability and Interchangeability

Comparing PRLs

Products that comply with the same project specification are:

  • Interoperable, if they fulfill opposite roles
  • Interchangeable, if they fulfill the same role(s)

Project Specification includes:

  • >Project PRL
    • Filled-out PRL from standard
    • Any Supplemental PRL
  • Project RTM
    • Standard RTM
    • Any supplemental RTM
  • Additional materials

Slide 48:

Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.

Slide 49:

Question

What does a Project PRL identify? Answer Choices

  1. The functional requirements for a project
  2. The objects to be supported for a project
  3. The testing requirements for a project
  4. All of the above

Slide 50:

Review of Answers

A small graphical green and yellow check mark representing correct.a) The requirements for a project
Correct! The Project PRL identifies which functional requirements are required for a device within a project.

A small graphical red and yellow X representing incorrect.b) The objects to be supported for a project
Incorrect. Objects to be supported are identified in the RTM.

A small graphical red and yellow X representing incorrect.c) The testing requirements for a project
Incorrect. Testing requirements are not a part of the PRL.

A small graphical red and yellow X representing incorrect.d) All of the above
Incorrect. The PRL does not identify objects or test requirements.

Slide 51:

Learning Objective 3

Slide 52:

Prepare a Project-Level RTM

Overview

Slide 53:

Understanding the Standard RTM

Slide 54:

Trace Requirements with RTM

Please see Extended Text Description below:

(Extended Text Description: This slide contains a table as shown below, with additional overlays:

FR ID Functional Requirement Dialog ID Object ID Object Name Additional Specifications
3.5.2 Manage Signal Operations Management Requirements
3.5.2.1 Manage Signal Configuration Requirements
3.5.2.1.2 Manage Phase Configuration Requirements
3.5.2.1.2.1 Configure Phases Requirements
3.5.2.1.2.1.2 Configure Vehicle Phase Minimum Green Time H.2.7
5.2.2 phaseTable
5.2.2.1 phaseNumber
5.2.2.4 phaseMinimumGreen

Overlays: This slide depicts a sample from the RTM, which is a table that has six columns and the sample shows eight rows plus the title row. The top four rows are shaded in increasingly lighter shades of grey with the darkest at top. These four rows are highlighted with a blue box with a line leading to an explanation of "Shaded rows indicate groups of functional requirements as organized in the text.")

Slide 55:

Trace Requirements with RTM

Please see Extended Text Description below:

(Extended Text Description: This slide contains a table as shown below, with additional overlays:

FR ID Functional Requirement Dialog ID Object ID Object Name Additional Specifications
3.5.2 Manage Signal Operations Management Requirements
3.5.2.1 Manage Signal Configuration Requirements
3.5.2.1.2 Manage Phase Configuration Requirements
3.5.2.1.2.1 Configure Phases Requirements
3.5.2.1.2.1.2 Configure Vehicle Phase Minimum Green Time H.2.7
5.2.2 phaseTable
5.2.2.1 phaseNumber
5.2.2.4 phaseMinimumGreen

Overlays: This slide depicts the same sample from the RTM as shown on Slide #54, but the blue box and associated text has been removed. This slide shows descriptions for each of the first three columns. The first is explained to be the "Functional requirement section number"; the second is explained to be the "Functional requirement section title", and the third is explained to be the "Section number of one dialog per FR" (functional requirement).)

Slide 56:

Trace Requirements with RTM

Please see Extended Text Description below:

(Extended Text Description: This slide contains a table as shown below, with additional overlays:

FR ID Functional Requirement Dialog ID Object ID Object Name Additional Specifications
3.5.2 Manage Signal Operations Management Requirements
3.5.2.1 Manage Signal Configuration Requirements
3.5.2.1.2 Manage Phase Configuration Requirements
3.5.2.1.2.1 Configure Phases Requirements
3.5.2.1.2.1.2 Configure Vehicle Phase Minimum Green Time H.2.7
5.2.2 phaseTable
5.2.2.1 phaseNumber
5.2.2.4 phaseMinimumGreen

Overlays: This slide depicts the same sample from the RTM as shown on Slide #54, but the blue box and associated text has been removed. A separate blue box is shown highlighting the first three columns of the last three rows that are empty. Text explains that "an empty functional requirement indicates row belongs to the previous functional requirement" and that this traces the functional requirement to an object. As the instructor continues to talk, the blue box is replaced with arrows from the functional requirement to the dialog and three objects listed. This slide then shows descriptions for each of the last three columns. Column four is explained to be the "Section number for each included object"; column five is explained to be the "Name of each included object", and the last column is explained to be "Any additional specifications".)

Slide 57:

Trace Requirements with RTM

Please see Extended Text Description below:

(Extended Text Description: This slide contains two tables as shown below, with additional overlays as the instructor discusses the slide:

FR ID Functional Requirement Dialog ID Object ID Object Name Additional Specifications
3.5.2.1.2.1.2 Configure Vehicle Phase Minimum Green Time H.2.7
5.2.2 phaseTable
5.2.2.1 phaseNumber
5.2.2.4 phaseMinimumGreen
# Walk Pad Clear Min Green Passage Max 1 Max 2 Yellow Red Clear
2 4 7 4 5.0 60 80 4.0 0.5
4 4 15 4 3.0 20 20 3.0 0.5

Overlays: This slide depicts the same sample from the RTM as shown on the previous slides, but the shaded heading rows have been removed so that the table takes up less space and that it now shows a single functional requirement ("Configure Vehicle Phase Minimum Green Time") and its associated three objects and dialog. As the instructor talks, we see animation show that the dialog traces to the UML sequence diagram from Slide #27. The next animation sequence reveals that the first object ("phaseTable") points to a table containing a lot of configuration values for different phases. The next animation sequence reveals that the second object ("phaseNumber") refers to the index of the table that is used to point to a specific row in the table; and that this row number is used to identify a specific instance of a columnar object. The next animation sequence shows that the third object ("phaseMinimumGreen") refers to the "minimum green" column of the table and that it serves as the base of the object instance to be exchanged. Thus, the name "phaseMinimumGreen.2" refers to the value of phaseMinimumGreen for the row in the Phase Table where the phaseNumber is 2. The final animation sequence on the slide shows that the value stored within the phaseMinimumGreen column of the Phase 2 row of the Phase Table is the number 4 and this is the value to which phaseMinimumGreen.2 is being set in the sequence diagram.)

Slide 58:

Trace Requirements with RTM

Please see Extended Text Description below:

(Extended Text Description: This slide contains a table as shown below, with additional overlays:

FR ID Functional Requirement Dialog ID Object ID Object Name Additional Specifications
3.5.2.1.2.1.2 Enable/Disable Phase 4.2.2
5.2.2 phaseTable
5.2.2.1 phaseNumber
5.2.2.21 phaseOptions Bit 0

Below the table is the text:

phaseOptions OBJECT-TYPE

Bit 0: Enabled Phase
Bit 1: Automatic Flash Entry Phase
Bit 2: Automatic Flash Exit Phase
Bit 3: Non Actuated 1
Bit 4: Non Actuated 2
etc.

Overlays: This slide depicts another sample from the RTM where one of the rows has a value in the "Additional Specifications" column. The Functional Requirement is "Enable/Disable Phase" and it is based on dialog 4.2.2. It is traced to three objects, "phaseTable", "phaseNumber", and "phaseOptions". The row with phaseOptions has the text "Bit 0" in the "Additional Specifications" column. At the top of this column, it is explained that the column "refines the information on the row", and at the bottom there is an arrow that points to the definition of the object where Bit 0 is defined to be the "Enabled Phase" bit and other bits serve different purposes.)

Slide 59:

Trace Requirements with RTM

Standardized Dialogs

Author's relevant description: This slide depicts Figure 8 from NTCIP 1202, which is a UML sequence diagram that represents a relatively complex dialog defined by the standard containing 9 distinct requests from the management station.

Slide 60:

Trace Requirements with RTM

Standardized Dialogs vs Conforming Behavior

Standard defines "standardized dialogs"

Slide 61:

Supplementing the RTM, if Needed

Project Dialogs

An implementation may have special dialog requirements

Procurement should specify any custom dialogs and associated performance requirements to ensure proper interoperability

Slide 62:

Referencing the RTM

Slide 63:

Benefits of RTM to Stakeholders

Author's relevant description: A picture of a customer handing a credit card to a clerk at a point-of-sale terminal. The graphic is intended to represent procurement.

Procuring agency

Author's relevant description: A photograph of the operations floor of the traffic management center

Operations personnel

Slide 64:

Benefits of RTM to Stakeholders

Author's relevant description: A picture of a woman at a laptop with two large displays and is intended to represent a computer programmer

System developers

Author's relevant description: A photograph of the 2070 controller

Manufacturers/vendors

Author's relevant description: An image of a laptop computer where six human figures are playing tug-of-war into and out of the laptop’s monitor; there is a seventh human figure connecting an Ethernet cable to the laptop

Conformance testers

Slide 65:

Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.

Slide 66:

Question

What does the dialog column in the following table mean?

FR ID Functional Requirement Dialog ID Object ID Object Name Additional Specifications
3.5.2.1.2.1.2 Configure Vehicle Phase Minimum Green Time H.2.7
5.2.2 phaseTable
5.2.2.1 phaseNumber
5.2.2.4 phaseMinimumGreen
  1. The dialog is the only way to exchange the objects
  2. The dialog defines operations that are prohibited
  3. The dialog provides a baseline reference for testing
  4. All of the above

Slide 67:

Review of Answers

A small graphical red and yellow X representing incorrect.a) The dialog is the only way to exchange the objects
Incorrect. SNMP provides flexibility in exchanging objects.

A small graphical red and yellow X representing incorrect.b) The dialog defines operations that are prohibited
Incorrect. The dialog does not define operations that are prohibited.

A small graphical green and yellow check mark representing correct.c) The dialog provides a baseline reference for testing
Correct! The dialog provides a baseline that can be used to develop test procedures.

A small graphical red and yellow X representing incorrect.d) All of the above
Incorrect. Answers a and b are not true.

Slide 68:

Learning Objective 4

Slide 69:

Prepare an ASC Specification

Overview

Slide 70:

Potential Issues with a Specification

Example Issues

Cause Possible Result
Not identifying user needs Compliant system that does not meet needs
Inadequate specification of functional requirements
Inadequate specification of system dialogs Inconsistent behavior of the system
Not clearly identifying custom features Inability to support custom needs
Inadequate specification of communications stack Non-interoperable system
Inadequate testing Anomalies occurring after vendor has been paid
Copying someone else's specification System that does not meet user needs

Slide 71:

Interface Specification Checklist

Select User Needs and Requirements

Checklist icon used to indicate a process that is being laid out sequentially.

Two items from the Slide 76 checklist “Project PRL” and “RTM (by reference)”

Slide 72:

Interface Specification Checklist

Define any custom items

Add supplements to PRL and RTM to address any customizations

Checklist icon used to indicate a process that is being laid out sequentially.

two items from the Slide 76 checklist “Custom dialogs” and “Custom extensions”

Slide 73:

Interface Specification Checklist

Specify Complete Communications Stack

The body of this slide contains 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 1202 standard.

Source: NTCIP 9001v04, Page 12, Figure 4

One item from the Slide 76 checklist “Communication stack specifications”

Slide 74:

Interface Specification Checklist

Define Testing Requirements

Checklist icon used to indicate a process that is being laid out sequentially.

One item from the Slide 76 checklist “Testing/acceptance requirements

Slide 75:

Interface Specification Checklist

Develop Your Own Specifications

Checklist icon used to indicate a process that is being laid out sequentially.

One item from the Slide 76 checklist “Don’t blindly copy specifications”

Slide 76:

Interface Specification Checklist

This slide summarizes the seven items discussed in a checkpoint list: “Project PRL” - “RTM (by reference)” - “Custom dialogs” - “Custom extensions” - “Communication stack specifications” - “Testing/acceptance requirements” - “Don’t blindly copy specifications”

Slide 77:

Complete Specification Package

Example

This slide includes a Venn diagram of three overlapping circles, labeled “Hardware Spec”, “Software Spec” and “Interface Spec”. The Hardware Spec includes the following list of items: functional, performance, structural, mechanical, electrical, environmental, and testing/acceptance. The Software Spec includes the following list of items: functional, performance, and testing/acceptance. The Interface Spec includes the following list of items: project PRL, RTM (by reference), custom dialogs, custom extensions, communication stack, and testing/acceptance.

Slide 78:

Interface Specification Checklist

Specification Might Be Complex

Checklist icon used to indicate a process that is being laid out sequentially.

Slide 79:

Interface Specification Checklist

Contractual Requirements

This slide displays the Systems Engineering “Vee” Diagram, which shows a V-shaped diagram in gradated blue with some additional horizontal extensions on the left and right side of the top of the V shape. Each section is separated with dark blue lines. There is a key at the lower right showing the blue separator lines, and designating them as “Document/Approval.” The left horizontal extension is labeled as “Lifecycle Processes” and include the sections “Regional Architecture” (separated by a white space) to the second section labeled “Feasibility Study / Concept Exploration.” At this point the sections begin to descend the left side of the V with “Concept of Operations,” “System Requirements,” “High-level Design,” “Detailed Design,” and “Software / Hardware Development Field Installation” at the bottom juncture of the V shape. Underneath the bottom point of the V shape are the words “Implementation” then “Development Processes” and a long thin arrow pointing to the right labeled “Time Line.” There is a long thin diagonal arrow pointing down along the left side of the V labeled “Decomposition and Definition.” From the bottom point of the V, the sections begin to ascend up the right side of the V with “Unit/Device Testing,” “Subsystem Verification,” “System Verification & Deployment,” “System Validation,” and “Operations and Maintenance.” There is a long thin arrow pointing up along the right side of the V shaped labeled “Integration and Recomposition.” At this point the sections on the right “wing” of the V are labeled with “Changes and Upgrades” and (white space) “Retirement/Replacement.” Between the V shape there are a series of black dashed arrows connecting the related sections on each left/right side of the V shape. The first arrow (top) is labeled “System Validation Plan” and connects “Concept of Operations” on the left and “System Validation” on the right. The second arrow is labeled “System Verification Plan (System Acceptance)” and connects “System Requirements” on the left and “System Verification & Deployment” on the right. The third arrow is labeled “Subsystem Verification Plan (Subsystem Acceptance)” and connects “High-Level Design” on the left and “Subsystem Verification” on the right. The last arrow (at the bottom) is labeled “Unit/Device Test Plan” and connects “Detailed Design” on the left and “Unit/Device Testing” on the right.

Slide 80:

Interface Specification Checklist

Remember

This slide contains a box with two cells. The top cell is labeled “Additional Specifications” and there is one row below with the text “The ASC shall support at least ____ phases”. The intent is to provide a simple example of what is required to be completed for the “Additional Specifications” of the PRL.

Checklist icon used to indicate a process that is being laid out sequentially.

Slide 81:

Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.

Slide 82:

Question

Which of the following is typically not part of the interface specifications?

Answer Choices

  1. Project PRL
  2. Testing requirements
  3. Environmental requirements
  4. Communications stack

Slide 83:

Review of Answers

A small graphical red and yellow X representing incorrect.a) Project PRL
Incorrect. The interface specification should include the project PRL.

A small graphical red and yellow X representing incorrect.b) Testing requirements
Incorrect. The interface specification should include testing/acceptance requirements.

A small graphical green and yellow check mark representing correct.c) Environmental requirements
Correct! Environmental requirements are typically not included in an interface specification.

A small graphical red and yellow X representing incorrect.d) Communications stack
Incorrect. The communications stack should be specified in the interface specification.

Slide 84:

Module Summary

Slide 85:

Next Course Module

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

Part 2 of 2

Concepts taught in next module (Learning Objectives):

  1. Manage Special Considerations for NTCIP 1202 v03
  2. Incorporate Requirements Not Supported by Standardized Objects

Slide 86:

Thank you for completing this module. Feedback

Please use the Feedback link below to provide us with your thoughts and comments about the value of the training.

Thank you!

↑ Return to top