Module 32 - A315b

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

Welcome - Graphic image of introductory slide. Please see the Extended Text Description below.

(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:

Welcome

Head shot photo of Ken Leonard, Director - ITS Joint Program Office

Ken Leonard, Director

ITS Joint Program Office

Ken.Leonard@dot.gov

Screen capture snapshot of RITA website - for illustration only - see the extended text description below.

(Extended Text Description: Intro Slide: Screen capture snapshot of RITA website - for illustration only. Below this image is a link to the current website: http://www.pcb.its.dot.gov - this screen capture snapshot shows an example from the RITA website from April 2013. At the top of the page it shows the RITA logo with the text U.S. Department of Transportation Research and Innovative Technology Administration - Intelligent Transportation Systems Joint Program Office - ITS Professional Capacity Building Program/Advanced ITS Education. Below the main site banner, it shows the main navigation menu with the following items: About, ITS Training, Knowledge Exchange, Technology Transfer, ITS in Academics, and Media Library. Below the main navigation menu, the page shows various content of the website, including a graphic image of professionals seated in a room during a training program. A text overlay has the text Welcome to ITS Professional Capacity Building. Additional content on the page includes a box entitled What's New and sections entitled Available E-Training (free), Free ITS Training and T3 Webinars. Again, this image serves for illustration only. The current website link is: http://www.pcb.its.dot.gov)

www.pcb.its.dot.gov

(Note: There is additional text attached to this slide that includes the following introductory information from Ken Leonard):

"ITS Standards can make your life easier. Your procurements will go more smoothly and you'll encourage competition, but only if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for acquiring and testing standards-based ITS systems.

I am Ken Leonard, director of the ITS Joint Program Office for USDOT and I want to welcome you to our newly redesigned ITS standards training program of which this module is a part. We are pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this new approach to training that combines web based modules with instructor interaction to bring the latest in ITS learning to busy professionals like yourself.

This combined approach allows interested professionals to schedule training at your convenience, without the need to travel. After you complete this training, we hope that you will tell colleagues and customers about the latest ITS standards and encourage them to take advantage of the archived version of the webinars.

ITS Standards training is one of the first offerings of our updated Professional Capacity Training Program. Through the PCB program we prepare professionals to adopt proven and emerging ITS technologies that will make surface transportation safer, smarter and greener which improves livability for us all. You can find information on additional modules and training programs on our web site www.pcb.its.dot.gov

Please help us make even more improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you again for participating and we hope you find this module helpful."

 

Slide 3:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

 

Slide 4:

A315b:

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

 

Slide 5:

Instructor

Head shot photo of Kenneth L. Vaughn, P.E. - President - Trevilon LLC - Magnolia, TX, USA

Kenneth L. Vaughn, P.E.
President
Trevilon LLC
Magnolia, TX, USA

 

Slide 6:

Target Audience

 

Slide 7:

Recommended Prerequisite(s)

 

Slide 8:

Recommended Prerequisites Continued

 

Slide 9:

Curriculum Path (Non-SEP)

A graphical illustration indicating the sequence of training modules that lead up to and follow this course. Please see the Extended Text Description below.

(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 labeled "A201 Details on Acquiring Standards-based ITS Systems." An arrow from this box connects it to a box located at the start of the next line and labeled "A202 Identifying and Writing User Needs When ITS Standards Do Not Have SEP Content." An arrow from this box connects it to a box labeled "A103 Introduction to ITS Standards Requirements Development." An arrow from this box connects it to a box labeled "A203 Writing Requirements When ITS Standards Do Not Have SEP Content." An arrow from this box connects it to a box labeled "C101 Intro. To Comm. Protocols and Their Use in ITS Applications." An arrow from this box connects it to a box, which is located at the start of the next line and labeled "A315a Understanding User Needs for ASC Based on NTCIP 1202 Standard." An arrow from this box connects it to a highlighted box designating this module labeled "A315b Understanding Requirements for ASC Based on NTCIP 1202 Standard (Part 1)." An arrow from this box connects it to a grayed out box, which represents the next course, labeled "A315b Understanding Requirements for ASC Based on NTCIP 1202 Standard (Part 1)." Finally, An arrow from this box connects it to a grayed out box labeled "T315 Applying Your Test Plan for ASC Based on NTCIP 1202 Standard.")

 

Slide 10:

Learning Objectives

  1. Learn how to develop requirements using the NTCIP 1202 v02 standard
  2. Achieve interoperability and interchangeability
  3. Understand traceability
  4. Develop the specification
  5. Manage special issues for ASC
  6. Incorporate requirements not supported by standardized objects

 

Slide 11:

Learning Objective #1 - Learn How to Develop Requirements

 

Slide 12:

Learning Objective #1

Learn How to Develop Requirements

Review the Structure of NTCIP 1202 v02

Section 1: General Section 2: Object Definitions Section 3: Block Object Definitions Annex A: Information Profile Annex B: Consistency Checks Annex C: Concept of Operations Annex D: Deprecated Objects

 

Slide 13:

Learning Objective #1

What is Missing from NTCIP 1202 v02

SEP Information

 

Slide 14:

Learning Objective #1

How Do We Identify Requirements?

Discover Requirements from Various Sources

Images associated with different sources for requirements. Please see the Extended Text Description below.

(Extended Text Description: Images associated with different sources for requirements. On the left is a box labeled "PCB Module A315a ASC User Needs" pointing to "User Needs". To the right of that is an image of an NTCIP standard labeled "SEP-Based Standards" pointing to "Available Content". To the right of that is an NTCIP standard labeled "NTCIP 1202 v02 Annex A" pointing to "Conformance Groups and Objects". To the right of that is an image of a traffic management center connected to a actuated traffic signal controller, with the label "Config., Control, & Monitoring Analysis".)

 

Slide 15:

Learning Objective #1

Learn How to Develop Requirements

Identify from User Needs

 

Slide 16:

Learning Objective #1

Learn How to Develop Requirements

Identify from User Needs

User Need ID User Need RID Requirement
2.1.1 Architectural User Needs
2.1.1.1 Live Data Exchange
2.1.1.2 Logged Data Exchange
2.1.1.3 Support Legacy Communication Networks
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 Control Selection of Timing Pattern
  #.# Subject of this module
2.1.4 Monitor User Needs
2.1.4.1 Monitor Signal Configuration
2.1.4.2 Monitor Signal Timing
2.1.4.3 Monitor Timing Pattern Selection
2.1.4.4 Monitor Signal Diagnostics

 

Slide 17:

Learning Objective #1

Learn How to Develop Requirements

Control Selection of Timing Pattern

Requirements

 

Slide 18:

Learning Objective #1

Learn How to Develop Requirements

Revise User Need

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.

 

Slide 19:

Learning Objective #1

Learn How to Develop Requirements

Identify Requirements from User Needs

Control selection of timing pattern

 

Slide 20:

Learning Objective #1

Learn How to Develop Requirements

Identify from SEP-based Standards

Try not to reinvent the wheel

 

Slide 21:

Learning Objective #1

Learn How to Develop Requirements

Identify from SEP-based Standards

 

Slide 22:

Learning Objective #1

Learn How to Develop Requirements

Common User Need - Logged Data Exchange

Traced Requirements per NTCIP 1203v03 PRL

 

Slide 23:

Learning Objective #1

Learn How to Develop Requirements

Common Requirement Set - Support Schedule

Requirements for Schedule Messages for Display in NTCIP 1203v03 PRL (DMS)

 

Slide 24:

Learning Objective #1

Learn How to Develop Requirements

Identify from Conformance Groups

 

Slide 25:

Learning Objective #1

Learn How to Develop Requirements

Identify from Conformance Groups

Clause Name
2.5 Coordination Conformance Group
2.5.2 coordCorrectionMode
  Other(1)
  Dwell (2)
  Shortway (3)
  AddOnly (4)

 

Slide 26:

Learning Objective #1

Learn How to Develop Requirements

Identify from Conformance Groups

Control selection of timing pattern

 

Slide 27:

Learning Objective #1

Learn How to Develop Requirements

Identify from 3 Perspectives

 

Slide 28:

Learning Objective #1

Learn How to Develop Requirements

Identify from 3 Perspectives

Control Selection of Timing Pattern

 

Slide 29:

Learning Objective #1

Learn How to Develop Requirements

Only Define Real Requirements

 

Slide 30:

Learning Objective #1

Importance of Considering All Sources

An Incomplete Specification

 

Slide 31:

Learning Objective #1

Learn How to Develop Requirements

Criteria for Well-Written Requirements

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

 

Slide 32:

Learning Objective #1

Criteria for Well-Written Requirements

Context Diagram for Actor

A graphic depicting the connection between a central system, as depicted by a control center, and an ASC. Please see the Extended Text Description below.

(Extended Text Description: A graphic depicting the connection between a central system, as depicted by a control center, and an ASC. There is one line in each direction connecting these two images. The one going from the central system to the ASC is labeled "Request" and the other is labeled "Response.")

 

Slide 33:

Learning Objective #1

Learn How to Develop Requirements

Criteria for Well-Written Requirements

 

Slide 34:

Learning Objective #1

Learn How to Develop Requirements

Requirement from NTCIP 1203

Set Time: The central system shall configure the ASC with the current coordinated universal time (UTC) to the nearest second.

 

Slide 35:

Learning Objective #1

Learn How to Develop Requirements

Requirement from User Need

Monitor Current Timing Pattern: The central system shall monitor the ASC to determine which timing pattern is currently active.

 

Slide 36:

Learning Objective #1

Learn How to Develop Requirements

Requirement from User Need

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.

 

Slide 37:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

 

Slide 38:

Learning Objective #1

Which of the following statements is NOT true?

Answer Choices

  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

 

Slide 39:

Learning Objective #1

Review of Answers

A small graphical red and yellow X representing incorrect.a) User needs are used in a top-down approach
True! This is the traditional systems engineering approach to defining requirements.

A small graphical green and yellow check mark representing correct.b) Read every SEP-based standard to get ideas
False. You should reference SEP-based standards when you think they may be of benefit.

A small graphical red and yellow X representing incorrect.c) CGs are used in a bottom-up approach
True! Reverse engineering allows you to benefit from a known solution.

A small graphical red and yellow X representing incorrect.d) There may be overlaps in requirements
True! Harmonization of this issue is a later topic.

 

Slide 40:

Summary of Learning Objective # 1

Learn How to Develop Requirements

 

Slide 41:

Learning Objective # 2 - Achieve Interoperability and Interchangeability

 

Slide 42:

Learning Objective #2

Achieve Interoperability/Interchangeability Interoperability

The ability of two or more systems or components to exchange information and to use the information that has been exchanged

ISO/IEC 24765:2010 Systems and Software Engineering - Vocabulary

 

Slide 43:

Learning Objective #2

Achieve Interoperability/Interchangeability Interchangeability

A condition which exists when two or more items possess such functional and physical characteristics as to be equivalent in performance and durability, and are capable of being exchanged one for the other without alteration of the items themselves, or adjoining items, except for adjustment, and without selection for fit and performance.

Nat'l Telecommunications & Information Admin.

US Department of Commerce

 

Slide 44:

Learning Objective #2

Achieve Interoperability/Interchangeability

Rules for exchanging information:

Rules for using the information:

 

Slide 45:

Learning Objective #2

Achieve Interoperability/Interchangeability Basic SNMP Dialogs and Messages

A slide showing the three standard SNMP dialogs. Please see the Extended Text Description below.

(Extended Text Description: A slide showing the three standard SNMP dialogs. In the upper left is the "GET" dialog, depicted by a UML sequence diagram with a "ManagementStation" sending a "Get(objectlist)" message to an "Agent" followed by the "Agent" sending a "Response(objectList)" message to the "ManagementStation". In the upper right is the "SET" dialog, depicted by a UML sequence diagram with a "ManagementStation" sending a "Set(objectlist)" message to an "Agent" followed by the "Agent" sending a "Response(objectList)" message to the "ManagementStation". In the lower center is the "GET-NEXT" dialog, depicted by a UML sequence diagram with a "ManagementStation" sending a "GetNextobjectlist)" message to an "Agent" followed by the "Agent" sending a "Response(objectList)" message to the "ManagementStation".)

 

Slide 46:

Learning Objective #2

Achieve Interoperability/Interchangeability Monitor Current Timing Pattern

Find Objects

 

Slide 47:

Learning Objective #2

Achieve Interoperability/Interchangeability Monitor Current Timing Pattern

Find Objects

Table for COORDINATION CONFORMANCE GROUP. Please see the Extended Text Description below.

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

COORDINATION CONFORMANCE GROUP
NTCIP 1202 Clause Object Name Object Type Object Status Object Support Allowed Values Supported Values
  phaseOmitted(7) -- --- Yes/No --- ---
  2.5.9.5
2.5.10
2.5.11
splitCoordPhase
coordPatternStatus
localFreeStatus
P
S
S
2.5:M
2.5:M
2.5:M
Yes
Yes
Yes
0-1
0-255
1-11
 
2.5.12
2.5.13
2.5.14
coordCycleStatus
coordSyncSlatus
systemPatternControl
S
S
C
2.5:M
2.5:M
2.5:M
Yes
Yes
Yes
0-510
0-510
0-255
 
2.5.15 systemSyncControl C 2.5:M Yes 0-255  

Also please note that in this slide, the text 2.5.10 and coordPatternStatus are underlined in green.)

NTCIP 1202v02 Page 140

 

Slide 48:

Learning Objective #2

Achieve Interoperability/Interchangeability Monitor Current Timing Pattern

Find Objects

Achieve Interoperability/Interchangeability Monitor Current Timing Pattern. Please see the Extended Text Description below.

(Extended Text Description: This figure contains the following text:

coordPatternStatus OBJECT-TYPE
SYNTAX INTEGER (0..255)
ACCESS read-only
STATUS optional
DESCRIPTION

"<Definition> This object defines the running coordination pattern/mode in the device. The possible values are:

Value Description
0 Not used
1-253 Pattern - indicates the currently running pattern
254 Free - indicates Free operation without coordination
255 Flash - indicates Automatic Flash without coordination

<DescriptiveName> NTCIP-1202LLASC.coordPatternStatus
<DataConceptType> Data Element"
::= { coord 10 }

Please note that in this slide, the following text is underlined in green: coordPatternStatus, SYNTAX INTEGER (0..255), ACCESS read-only, STATUS optional, then there is a green line descending from DESCRIPTION down to ::= { coord 10 }.)

NTCIP 1202v02 Page 66

 

Slide 49:

Learning Objective #2

Achieve Interoperability/Interchangeability Monitor Current Timing Pattern

Dialog Definition

"The management station shall GET coordPatternStatus.0"

A slide showing the sample dialog for monitoring current timing pattern. Please see the Extended Text Description below.

(Extended Text Description: A slide showing the sample dialog for monitoring current timing pattern. It is depicted by a UML sequence diagram between a "ManagementStation" and an "Agent". The dialog starts with the "ManagementStation" sending a "Get(coordPatternStatus.0)" message to the "Agent". This is followed by the "Agent" sending an unlabeled response message to the "ManagementStation".)

 

Slide 50:

Learning Objective #2

Achieve Interoperability/Interchangeability Dialog for a Referenced Requirement

Set Time

 

Slide 51:

Learning Objective #2

Achieve Interoperability/Interchangeability Configure a Timing Pattern

Coordination Conformance Group

Clause Object Name
2.5 Coordination Conformance Group
2.5.7 patternTable
2.5.7.1 patternNumber
2.5.7.2 patternCycleTime
2.5.7.3 patternOffseetTime
2.5.7.4 patternSplitNumber
2.5.7.5 patternSequenceNumber
2.5.9 splitTable
2.5.9.1 splitNumber
2.5.9.2 splitPhase
2.5.9.3 splitTime
2.5.9.4 splitMode
2.5.9.5 splitCoordPhase

 

Slide 52:

Learning Objective #2

Achieve Interoperability/Interchangeability Configure a Timing Pattern

A slide showing the sample dialog for configuring a timing pattern. Please see the Extended Text Description below.

(Extended Text Description: A slide showing 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".)

 

Slide 53:

Learning Objective #2

Achieve Interoperability/Interchangeability Configure a Timing Pattern

  1. (Precondition) The management station shall confirm that the signal controller supports the desired splits, phases, and patterns.
  2. For each enabled phase, 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

 

Slide 54:

Learning Objective #2

Achieve Interoperability/Interchangeability Configure a Timing Pattern

  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

 

Slide 55:

Learning Objective #2

Achieve Interoperability/Interchangeability What are the Implications?

 

Slide 56:

Learning Objective #2

Achieve Interoperability/Interchangeability What are the Implications?

 

Slide 57:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

 

Slide 58:

Learning Objective #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

 

Slide 59:

Learning Objective #2

Review of Answers

A small graphical red and yellow X representing incorrect.a) Likely to conform to the standard
False. The dialog will be separate from the standard and will not affect conformance.

A small graphical green and yellow check mark representing correct.b) Likely to interoperate with the central system
True! Dialogs promote a common expectation on how objects are to be exchanged.

A small graphical green and yellow check mark representing correct.c) Likely to be interchangeable with other devices using the same procurement
True! Dialogs promote a common expectation on how objects are to be exchanged.

A small graphical red and yellow X representing incorrect.d) Likely to be less expensive
False. Additional specifications will likely mean added costs for the controller, but integration costs should significantly decrease.

 

Slide 60:

Summary of Learning Objective # 2

Achieve Interoperability and Interchangeability

 

Slide 61:

Learning Objective # 3 - Understand Traceability

 

Slide 62:

Learning Objective #3

Understand Traceability

Needs to Requirements

UN ID User Need RID Requirement
2.1.1 Architectural User Needs
2.1.1.1 Live Data Exchange
2.1.1.2 Logged Data Exchange
2.1.1.3 Support Legacy Communication Networks
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 Control Selection of Timing Pattern
    See module A315b
2.1.4 Monitor User Needs
2.1.4.1 Monitor Signal Configuration
2.1.4.2 Monitor Signal Timing
2.1.4.3 Monitor Timing Pattern Selection
2.1.4.4 Monitor Signal Diagnostics

 

Slide 63:

Learning Objective #3

Understand Traceability

Needs to Requirements

UN ID User Need RID Requirement
2.1.3.1 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.2 Activate a Timing Pattern per a Schedule
  2.2.2.3 Override Timing Pattern
  2.2.3.6 Retrieve a Schedule
  2.2.2.8 Define a Schedule
  NTCIP 1203v03 H.2.2.1 Set Time
  NTCIP 1203v03 H.2.2.2 Set Time Zone
  NTCIP 1203v03 H.2.2.3 Set Daylight Savings Mode
  NTCIP 1203v03 H.2.2.4 Verify Current Time
  ... ...

 

Slide 64:

Learning Objective #3

Understand Traceability

Contrast Needs-to-Requirements and PRL

 

Slide 65:

Learning Objective #3

Understand Traceability

Requirements to Design

RID Requirement Dialog Object ID Object

 

Slide 66:

Learning Objective #3

Understand Traceability

Requirements to Design

This slide includes a graphic indicating the monitor current timing pattern dialog. Please see the Extended Text Description below.

(Extended Text Description: This slide includes a graphic indicating the monitor current timing pattern dialog. It is depicted by a UML sequence diagram between a "ManagementStation" and an "Agent". The dialog starts with the "ManagementStation" sending a "Get(coordPatternStatus.0)" message to the "Agent". This is followed by the "Agent" sending an unlabeled response message to the "ManagementStation".)

RID Requirement Dialog Object ID Object
2.2.3.10 Monitor Current Timing Pattern NTCIP 1203 G.1 NTCIP 1202 2.5.10 coordPatternStatus

 

Slide 67:

Learning Objective #3

Understand Traceability

Complex Example - Configure a Timing Pattern

This slide contains the same image from slide 52. Please see the Extended Text Description below.

(Extended Text Description: This slide contains the same image from slide 52. It 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".)

 

Slide 68:

Learning Objective #3

Understand Traceability

Requirements to Design

RID Requirement Dialog Object ID Object
R1.1 Configure a Timing Pattern 2.3.1 NTCIP 1202 2.5.7.1 patternNumber
NTCIP 1202 2.5.7.2 patternCycleTime
NTCIP 1202 2.5.7.3 patternOffsetTime
NTCIP 1202 2.5.7.4 patternSplitNumber
NTCIP 1202 2.5.7.5 patternSequenceNumber
NTCIP 1202 2.5.9.1 splitNumber
NTCIP 1202 2.5.9.2 splitPhase
NTCIP 1202 2.5.9.3 splitTime
NTCIP 1202 2.5.9.4 splitMode
NTCIP 1202 2.5.9.5 splitCoordPhase

 

Slide 69:

Learning Objective #3

Understand Traceability

Benefits of Traceability

 

Slide 70:

Learning Objective #3

Understand Traceability

Scope of the Effort Requires Special Tools

 

Slide 71:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

 

Slide 72:

Learning Objective #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

 

Slide 73:

Learning Objective #3

Review of Answers

A small graphical red and yellow X representing incorrect.a) Clearly identify the objects
True! The traceability tables list each object required for each requirement.

A small graphical red and yellow X representing incorrect.b) Provide references to relevant clauses
True! Each item is associated with a reference to the clause where the item is defined.

A small graphical green and yellow check mark representing correct.c) Explain steps required in a test procedure
False. Traceability tables do not address steps within a test procedure

A small graphical red and yellow X representing incorrect.d) Provide traceability back to the user need
True! A user can trace from object to user need in either direction.

 

Slide 74:

Summary of Learning Objective # 3

Understand Traceability

 

Slide 75:

Learning Objective # 4 - Develop the Specification

 

Slide 76:

Learning Objective #4

Develop the Specification

Consistency

Three overlapping circles. Please see the Extended Text Description below.

(Extended Text Description: Three overlapping circles. One is labeled "Hardware Specification" the next is labeled "Software Specification" and the final one is labeled "Interface 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 77:

Learning Objective #4

Develop the Specification

Multiple Interface Specifications

 

Slide 78:

Learning Objective #4

Develop the Specification

Complete Interface Specification for ASC

A graphic of the communication levels of the NTCIP standards. Please see the Extended Text Description below.

(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 this module; the lower levels are labeled as "Subject of C101".)

Source: NTCIP 9001v04, Page 12, Figure 4

 

Slide 79:

Learning Objective #4

Develop the Specification

Interface Specification

 

Slide 80:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

 

Slide 81:

Learning Objective #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

 

Slide 82:

Learning Objective #4

Review of Answers

A small graphical red and yellow X representing incorrect.a) Most important part of a procurement
False. The schedule, budget, hardware, and software specifications are all important.

A small graphical green and yellow check mark representing correct.b) Should contain or reference dialogs
True! In order to achieve interoperability, the dialogs should be explicit.

A small graphical green and yellow check mark representing correct.c) Should define the communications stack
True! The communications stack defines over what medium components will communicate.

A small graphical red and yellow X representing incorrect.d) Central system should only support one interface
False. Most central systems will need to support at least one interface per device type.

 

Slide 83:

Summary of Learning Objective # 4

Develop the Specification

 

Slide 84:

What We Have Learned

  1. Requirements can be identified from user needs, SEP-based standards, conformance groups, and the three (3) perspectives.
  2. Well-written requirements clearly identify the actor, action and target.
  3. Dialogs define rules on how to exchange information while objects define the meaning of the information; both must be defined to achieve interoperability.
  4. Traceability tables allow a user to quickly determine why a design feature is included.
  5. An interface specification should reference standards whenever possible rather than copying their content.

 

Slide 85:

Resources

 

Slide 86:

Questions? A placeholder graphic image with word Questions? at the top, and an image of a lit light bulb on the lower right side.

 

Slide 87:

Next Course Module

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