Module 12 - A321a

A321a: Understanding User Needs for Traffic Management Systems Based on TMDD v3.0 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:

Slide 1: ITS Welcome - 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 Shelley Row, P.E., PTOE - Director - ITS Joint Program Office

Shelley Row, P.E., PTOE

Director

ITS Joint Program Office

Shelley.Row@dot.gov

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

(Extended Text Description: Slide 2: 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 June 3, 2011. At the top of the page it shows the RITA logo with the text Research and Innovative Technology Administration - Intelligent Transportation Systems. Below the main site banner, it shows the main navigation menu with the following items: About RITA, Communities of Interest, Contact Us, Press Room, RITA Offices, Site Map, and a Search button. Below the main navigation menu, it shows a sub-navigation menu with the following items: About Us, T3 Webinars, ITS Peer-to-Peer, Resources, Local ITS PCB and Testimonials. Beneath the sub-navigation menu, the page is sub-titled "ITS Professional Capacity Building Program" and is divided into sub-sections such as "Welcome to ITS Professional Building", "News", "ITS Technical Assistance" and "Scheduled 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 Shelley Row):

"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 Shelley Row the 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 you.

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 for participating and we hope you find this module helpful."

 

Slide 3:

A321a - Understanding User Needs for Traffic Management Systems Based on TMDD v3.0 Standard

 

Slide 4:

Target Audience

 

Slide 5:

Instructor

Slide 5:  Headshot of Instructor - Raman K Patel, Ph.D., P.E., President, RK Patel Associates, Inc.

Raman K Patel, Ph.D., P.E.

President
RK Patel Associates, Inc.
New York, NY, USA

 

Slide 6:

Curriculum Path (SEP)

Slide 6:  Curriculum Path (SEP) Flowchart.  Please see the Extended Text Description below.

(Extended Text Description: Curriculum Path (SEP): A graphical illustration indicating the sequence of training modules for the standards that include Systems Engineering Process content. 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. The first box is labeled “I101 Using ITS Standards: An Overview.” An arrow from this box connects it to a highlighted 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 “A321a Understanding User Needs for Traffic Managent Systems Based on TMDD v3 Standard” (highlighted in purple) Finally, an arrow from this box connects it to a box labeled “Specifying Requirements A311b-A321b.”)

 

Slide 7:

Curriculum Path (Non-SEP)

Slide 7:  Curriculum Path (Non-SEP) Flowchart.  Please see the Extended Text Description below.

(Extended Text Description: Slide 7: (Curriculum Path (Non-SEP): A graphical illustration indicating the sequence of training modules for the standards that do not include Systems Engineering Process content. 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. The first box is labeled “I101 Using ITS Standards: An Overview.” An arrow from this box connects it to a highlighted box labeled “A101 Introduction to Acquiring Standards-based ITS Systems,” representing this module. 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 highlighted and labeled “A202 How to Identify and Write Standards-based ITS User Needs.” 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 located at the start of the next line labeled “A203 Writing Standards-based ITS System Requirements.” An arrow from this box connects it to a box labeled “A3xxa Understanding User Needs Based on NTCIP 12xx vxx.” Finally, an arrow from this box connects it to a box labeled “A3xxb Specifying Requirements Based on NTCIP 12xx vxx.” The last two boxes contain an asterisk indicating that they are expected to be included in the Year 2 training modules.)

 

Slide 8:

Recommended Prerequisites

 

Slide 9:

Recommended Prerequisites (cont.)

Basic knowledge of the following areas is helpful:

 

Slide 10:

Learning Objectives

  1. Describe what problem TMDD is addressing
  2. Identify regional operational and planning needs (specific to TMDD) for common system interface to support interagency communications

 

Slide 11:

Learning Objectives (cont.)

  1. Discuss the TMDD v3.0 standard structure and the content
  2. Understand the role of NRTM and learn how to use it to select user needs and link them to requirements
  3. Identify a requirement of institutional arrangement for implementing a system interface

 

Slide 12:

Learning Objective #1

What is the Traffic Management Data Dictionary (TMDD)?

 

Slide 13:

Learning Objective #1

Centers

Slide 13:  Centers.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: This graphic shows two buildings and two separate arrows pointing to each other to convey their definitions. The building on the left is called External Center that desires information and the building on the right is called Owner Center that provides information and has direct control of field devices. Over the two arrows in the center appears a text box that says Center-to-Center communications (C2C).)

 

Slide 14:

Learning Objective #1

Interoperability

" The ability of two or more systems or components to exchange information and to use the information that has been exchanged" -IEEE Std 610

 

Slide 15:

 

Slide 15: Activity. A placeholder graphic of a hand typing on a computer keyboard indicating an activity.

 

Slide 16:

Learning Objective #1

Why do centers desire to communicate with each other?

Type your response in the chat pod

 

Slide 17:

Learning Objective #1

Before Standardization

Each Center Requires Multiple Proprietary Interfaces

Slide 17: Before Standardization.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: This graphic shows five buildings of different shape with four set of colored bidirectional arrows going into a cloud that connects all of them. The set of colored arrows depicts that if any center wants to communicate with others, they all require multiple interfaces-one for each colored arrow - without standardization. The point is that centers will need multiple interfaces that are proprietary if standardization is not used.)

 

Slide 18:

Learning Objective #1

After Standardization

Each Center Requires One Standard-based Interface

Slide 18:  After Standardization.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: This graphic is the same as in the previous slide, but centers are now only shown with one color arrow pointing to cloud, meaning that with standardization, centers only require one interface that is common to all centers.)

 

Slide 19:

Learning Objective #1

What is a System Interface?

"a system interface is a shared boundary across which information is passed"

Slide 19:  What is a System interface?  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: This slide has a large square blue background box. On the left side inside this box a circle with text Center System appears, next to circle which a vertical rectangular box with text system interface appears. This conveys that both share a boundary. Into and out of system interface box, one set of separate arrows that shows message in and message out connects to outside world. Another set appears bellow to show that more than one messages flow in and out of system interface that makes boundary with the center system. Finally, a broken square border appears over system interface and messages in-out to show that together they make a boundary with the center system to provide capability of messaging. The entire graphic conveys system interface definition.)

 

Slide 20:

Learning Objective #1

System Interface Implementation

Slide 20:  System Interface Implementation.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: This slide provides real world photos of two TMCs: one on left is a photo of TRASCOM center and one on right is NYC Joint TMC. Both centers are shown with system interface on side of photos and two separate arrows flow between these TMC to show that they have a common system interfaces that communicate information to each other. This information exchange then is used to manage assets and other entities, manage information, monitor status and control devices. The slide graphics have made a point that these real-world center operations use common system interface to carry out operations in real-time and improve their efficiency.)

SI Uses:

 

Slide 21:

Learning Objective #1

Procuring System Interface

Specification Components Supplied by TMDD v3 standard

Slide 21:  Procuring System Interface.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: A graphical illustration introduces three circles marked with user needs, requirements and design concepts. The first circle marked as user needs has a curved arrow coming from the second circle marked requirements, and arrow going out to requirements. This depicts that both user needs and requirements are related to each other. Similarly design is connected with requirements with two arrows. Near each circle, text description appears for user needs, requirements and design concepts. Thus, with text and circles we stress that three components make up a specification. Incidentally three circles have different color shades to show that they are distinct components.)

 

Slide 22:

Summary of Learning Objective 1

What Problem is TMDD Addressing?

 

Slide 23:

Slide 23: Activity. A placeholder graphic of a hand typing on a computer keyboard indicating an activity.

 

Slide 24:

Learning Objective #2

What operational needs will a TMC have for information from another center?

Type your response in the chat pod

 

Slide 25:

Learning Objective #2

Operational Environment

Slide 25:  Operational Environment.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: A vertical stack of eight rectangular text boxes lists eight categories of user needs that are present in a typical operational environment. Next to the stack is graphic that shows an External Center (EC) with operator is communicating with a TMC with operator and link in between two canters. The list of Categories of User Needs on the left includes the following, from top to bottom: Connection Management, Support Authentication-Restrictions, Provide Information on Organization (all three highlighted), Share Event Information, Provide Roadway Network, Provide control of Devices, Share Data for Archving, Accept Null Values.)

 

Slide 26:

Learning Objective #2

Example
2.3.1 Need for Connection Management

2.3.1.1 Verify Connection Active
Centers need to verify that a connection with another center is alive or active.

2.3.1.2 Need to Support Requests

Slide 26:  2.3.1 Need for Connection Management.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: This examples show a graphic in the middle with two centers with separate arrows shown in between. The meaning conveyed is that centers communicate to meet user needs. In this example the user need is to management connection between two systems.)

2.3.1.3 Need to Support Subscriptions

2.3.1.4 Need to Support Error Handling

 

Slide 27:

Learning Objective #2

Example
2.3.4 Need to Share Event Information

2.3.4.6 Need for Current Event Information
External centers need to obtain current event information from owner centers such as a description, location, severity, and status of the event.

Slide 27: Example - 2.3.4 Need to Share Event Information.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: This is the same graphic that is in Slide 26 but the user need is to share event information.)

2.3.4.7 Need for Planned Event Information
.....need to obtain planning information.....

 

Slide 28:

Learning Objective #2

Example
2.3.5 Need to Provide Roadway Network Data

Slide 28.  Example - 2.3.5 Need to Provide Roadway Network Data.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: User need is to provide roadway network data. The graphic shows a center at top and one at bottom of the with a road network diagram in between lies the stadium. The roadway has a DMS located near the center at lower end. Motorists are traveling to the stadium, so travel time on a DMS shows 15 minutes from the center at lower end.)

 

Slide 29:

Learning Objective #2

Example
2.3.6.4 Need to Share DMS Status and Control

2.3.6.4.4 Need to Display a Message on a Remote DMS
Centers need to request that a specific message be displayed on a DMS controlled by another center.

Slide 29:  Example - 2.3.6.4 Need to Share DMS Status and Control.  Please see the Extended Text Description below.

(Extended Text Desciption: Relevant descriptive information provided by author for this figure: This graphic is the same as Slide 26, with two centers with separate arrows shown in between, except user need is to share DMS status.)

 

Slide 30:

Learning Objective #2

Example
2.3.7 Need to Share Data for Archiving

2.3.7.1 Need for Traffic Monitoring Data
Centers exchange traffic monitoring data, such as volume, occupancy, and speed for archival purposes.

 

Data collection for planning and research needs

Slide 30:  Example - 2.3.7 Need to Share Data for Archiving.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: This graphic is the same as the graphic in Slide 29, except user need is to provide data for archiving. It also includes a map underneath the arrows connectiong the two sides of the figure, indicating the monitoring of traffic volumes.)

Monitoring traffic volumes on another agency's roadway

 

Slide 31:

Learning Objective #2

Illustration

How centers share and use current information

Slide 31: How centers share and use current information. Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: In this graphical layout a transit center is shown on left side of the slide and a TMC is shown on the right side. A bus with the driver is shown below transit center. This layout is designed to show how centers share current information and use it to meet their operational need. A roadway section is passing through both jurisdictions on which an incident occurs near TMC where a CCTV camera is also located to verify conditions.

The point of this illustration is that the transit center request information on current condition of the roadway link so that it may decide to inform its bus drivers and perhaps take alternate route to avoid prolong congestion.

Upon Transit is center’s request, the TMC verifies current conditions on the route with CCTV, and then TMC responds with current information. Transit center then passes that information to the bus drivers, and presumably advises them to avoid congested route. This is done in real-time.)

 

Slide 32:

Learning Objective #2

Illustration

How centers share field devices?

Slide 32:  Illustration:  How centers share field devices?  Pleaase see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: : Something similar to above C2C concept in Slide 31 is taking place in this illustration as well, except in this case the purpose is different and more involved. The layout calls a requesting center shown on the left TMC A and the owning center-TMC B on the right. TMC B has a DMS on the roadway link in its jurisdiction NB. (In our example on the slide the roadway is designated as North-South, TMC B on north end, TMC A on south end). The illustration now begins with a request from TMC A on left in whose jurisdiction on the same roadway, an incident occurred and it was felt that if TMC B on right places a warning message that read “Major ACCIDENT 5 MI I-87 NB ALT RT EXIT 9” ahead of the event site near TMC A, motorists will be well-advised to Exit 9 which is way before event location. Point is made that motorists have a clear warning of a major accident on NB direction five miles ahead and they may decide to exit early North Bound, thus avoiding congested areas for a prolong period.)


Slide 33:

Summary of Learning Objective 2

Operational Needs

1. Reviewed operational and planning needs to support interagency communications

 

Slide 34:

Learning Objective #2

Summary

Operational Needs (cont.)

2. User needs categories:

2.3.1 Connection management
2.3.2 Support Authentication-Restrictions
2.3.3 Provide information on organizations
2.3.4 Share event information
2.3.5 Provide roadway network data
2.3.6 Provide control of devices
2.3.7 Share data for archiving
2.3.8 Accept null values

 

Slide 35:

Learning Objective #3

Volume I

Concept of Operations and Requirements

What is to be done?

Section 1 Document Introduction
Section 2 User Needs
Section 3 Requirements
Section 4 Traceability to National ITS Architecture
Section 5 NRTM (pages 174-295)

 

Slide 36:

Learning Objective #3

Volume II-Design Content

How is it to be done?

Section 1 Document Introduction
Section 2 TMDD Dialogs and Messages
Section 3 TMDD ISO 14817 ASN.1 and XML Data Concepts Definitions
Section 4 Requirement Traceability Matrix (RTM) (pages 58-635)

ASN.1 and XML are Data Encoding Formats

 

Slide 37:

Learning Objective #3

Availability of Standardized Definitions by TMDD v3.0 standard

Slide 37:  Availability of Standardized Definitions by TMDD v3.0 standard.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: There are three boxes in this slide. Boxes reads inventory of definitions supplied by the TMDD v3 standard: 126 user needs in first box, 134 requirements in second box. Last box has 600 design concepts, further broken down as 124 dialogs, 85 messages, 187 data frames and 207 data elements. An arrow flows from data concepts box to text that reads, system interface design.)

 

Slide 38:

Learning Objective #3

Understanding Relationship through NRTM and RTM

Slide 38:  Understanding Relationship through NRTM and RTM.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: The graphical layout has three boxes on first level, First box reads user needs, second reads requirements and third reads data concepts.

Second level shown few spaces below has two boxes: NRTM and other RTM separated by spaces. A solid line from input side of NRTM connects to User Needs box above and a solid line connects output side of NRTM to line Requirements box. NRTM thus depicts relationship between requirements and user needs. It shows that requirements exist because of user needs.

A second relationship is shown same way between Requirements and design concepts thru RTM box. This means that RTM connect every requirement to data concepts to be used for that requirement. So, this slide solidly depicts that: NRTM is a relationship between user needs and requirements and RTM is a relationship between requirements and design concepts. )

 

Slide 39:

Summary of Learning Objective 3

TMDD Structure

 

Slide 40:

Learning Objective #3

Summary

TMDD Structure (cont.)

 

Slide 41:

Learning Objective #4

Where are User Needs located on "V"?

NRTM

Slide 41: Where User Needs are located on V.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: A graphic of the systems engineering process (SEP) is shown. 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 regional architecture, needs assessment, concept selection, 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, detailed design, and software hardware and field installation. At this point the steps begin to ascend the right side of the V with unit device testing, subsystem verification, system verification and deployment, system validation, and operations and maintenance. At this point the steps are on the right “wing” of the V with changes and upgrades and retirement/replacement.

The following arrows supplement the figure:

Finally, major steps are separated by a barrier that is labeled “document approval.”

The slide has a circle drawn over high level design and detailed design and an arrow attached to a circle that is pointing to a side graphic shown with a title page of standards. This illustration shows that standards are located at high level and detailed design level of SEP life cycle. )


Slide 42:

Learning Objective #4

Parts of NRTM

What needs to be done - Details-specifics

User Needs - Requirements

UN ID

User Need

UN Selected

Req. ID

Req.

Conformance

Support

Other Req.

 

 

 

 

 

 

 

 

(Additional Formatting Notes for this slide: "What needs to be done" and "User Needs" are positioned over the first three columns on the table above. "Details-specifics" and "Requirements" are positioned above "Req. ID", "Req.", "Conformance", "Support", and "Other Req." Additional Notes from the Author: The graphic illustrates parts of NRTM, which is a table. In this slide a table with two rows and eight columns is shown. First row has headings for columns: UN ID, User need, UN selected, requirement ID, requirement, conformance, support and last column reads other requirement. The second row in this chart is empty, which will be filled-in by user at project level, for each user need.)

NRTM Structure has 8 Columns with Multiple Rows

 

Slide 43:

Learning Objective #4

NRTM Content

UN ID

User Need

UN Selected

Req. ID

Req.

Conformance

Support

Other Req.

2.3.6.4.5

YES

3.3.6.1.4.2

M

YES

(Additional Notes from the Author: Relevant descriptive information provided by author for this figure: The same layout is used as above in previous slide, except second row is now filled-in to show content nature. First column has entry 2.3.6.4.5, third column has YES, fourth column has entry 3.3.6.1.4.2 and conformance column has M, meaning Mandatory, followed by YES in support column.)

For Mandatory (M) requirements stated in the standard, project must select YES only.

For Optional requirements (O), project decides if the requirement will be used.

 

Slide 44:

Learning Objective #4

NRTM Role

 

Slide 45:

Slide 45: Activity. A placeholder graphic of a hand typing on a computer keyboard indicating an activity.

 

Slide 46:

Learning Objective #4

Who do you think benefits from use of NRTM?

Type your response in the chat pod

 

Slide 47:

Learning Objective #4

Beneficiaries of NRTM

Slide 47:  Beneficiaries of RTM.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: There are four text boxes connected with a thin line. Starting with clockwise, there are requirements (The Specification Writer), risk management (The Integrator), capabilities (The Supplier) and interoperability (The User). Party concerned with each of this discussion point is shown in the parenthesis.)

 

Slide 48:

Learning Objective #4

Ensuring Interoperability

Slide 48: Ensuring Interoperability. Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: The graphic on this slide include two centers with two separate arrows showing in-out process, next to which a table appears. One headed arrow to table is shown from each center. The arrows from centers rest with two rows of the table’s first column. This column shows user need 1 in first row and nth in the second row. This means that a subset of user needs from 1 to n is to be included in the specification by both centers to achieve interoperability. In summary for the slide, we must recognize that user needs are the first step to achieve interoperability and centers must include same set of user needs for this purpose.)

 

Slide 49:

Learning Objective #4

Understanding Mandatory User Needs

To conform to the standard, Mandatory user needs must be selected-YES

UN ID

User Need

UN Selected

2.3.1.1

Verify Connection Active

YES

2.3.1.2

Request Needs to Support

YES

2.3.1.4

Need to Support Error Handling

YES

2.3.5.1.1

Need for Node Inventory

YES

2.3.5.1.2

Need for Link Inventory

YES

2.3.8

Need to Accept Null Values

YES

Ref. page 174, Volume I, Table 4, 4th Column UN Selected

(Additional Notes from the Author: A table with three columns and six rows outlines selected YES, all mandatory user needs. )

 

Slide 50:

Learning Objective #4

Understanding Optional User Needs

Select optional needs based on the project's operational needs

UN ID

User Need

UN Selected

2.3.1.3

Need to Support Subscriptions

Yes

2.3.4.2

Need to Correlate an Event with Another Event

Yes

2.3.4.5

Need to Provide Multilingual Event Descriptions

Yes

2.3.4.6

Need for Current Event Information

Yes

2.3.6.1.3

Need to Share Detector Status

Yes

(Additional Notes from the Author: A table with three column and five rows outlines all optional user needs selected YES. )

 

Slide 51:

Learning Objective #4

Example

Centers must select same set of user needs for interoperability

Slide 51:  Example:  Centers must select same set of user needs for interoperability.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: This examples show a graphic with two centers with arrows from each going to other. The center that owns a DMS is shown on the right, with an arrow going to a DMS. The requesting center is on the left desiring to have a new message go on the DMS. The point of 2.3.6.4.4 user need is that for interoperability - this capability to request posting a message - both centers must select this user needs in their project NRTM. )

 

Slide 52:

Learning Objective #4

Preparing Project NRTM

Slide 52:  Preparing Project NRTM.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: Same as Slide 38, Understanding Relationship thru NRTM and RTM. It also shows arrows flowing from User Needs to Requirements to Design concepts. NRTM and RTM graphic tables are empty. We need to learn to fill NRTM in this course. )

 

Slide 53:

Learning Objective #4

Preparing a Project NRTM

Step 1 Section 2 Volume I Page 22

Match project's operational need to User Need ID number and corresponding text description. This action determines if this UN is desired in your system

Example

2.3.6.4.5 Need to Verify DMS Control Status
The center that sends a request to display a specific message on a DMS operated by another center needs to confirm if the message was displayed. Possible statuses include that the message request was implemented, was queued, or was rejected.

DMS supports congestion (traffic) management

 

Slide 54:

Learning Objective #4

Preparing a Project NRTM (cont.)

Step 2
User Need Part
Write UN ID, UN and Select YES

Step 3
Requirements Part
Go to Section 5, Volume I, page 174, Table 4 to read allocated requirements

UN ID

User Need

UN Selected

Req. ID

Req.

Conformance

Support

Other Req.

2.3.6.4.5

Need to Verify DMS Control Status

YES

3.3.6.1.4.2

M

YES

(Additional Notes from the Author: Step 2 and 3 are shown above the table shown. The table is same as one in Slide 43, NRTM Content)

 

Slide 55:

Learning Objective #4

Project NRTM (Partially Populated)

Step 4
Find 2.3.6.4.5 on page 224
Read ten listed Req. in 4th column

10 requirements are allocated to a user need

UN ID

User Need

UN Selected

Req. ID

Requirement

Conformance

Support

Other Req.

2.3.6.4.5

Need to Verify DMS Control Status

YES

3.3.6.1.4.2

M

Yes

3.3.6.1.4.2.1

M

Yes

3.3.6.1.4.2.2.1

O

Yes

3.3.6.1.4.2.2.2

O

Yes

3.3.6.1.4.2.2.3

O

Yes

3.3.6.1.4.2.2.4

O

Yes

3.3.6.1.5.1

M

Yes

3.3.6.1.5.2

M

Yes

3.3.6.1.5.3

M

Yes

3.3.6.5.4

M

Yes

(Additional Formatting Notes for this Slide: The statement "10 requirements are allocated to a user need" appears directly over the columns, "Req. ID", "Requirement", "Conformance", "Support", and "Other Req.".) Additional Notes from the Author: Project NRTM (Partially Filled): Step 4 is shown with the same table as above, Slide 54. Last five columns on requirements are populated. NRTM is now shaping up with information in it.)

 

Slide 56:

Summary of Learning Objective 4

 

Slide 57:

Learning Objective #5

Pre-Arrangement

Slide 57:  Pre-arrangement.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: The slide shows three centers, one on left and two on the right. They appear as triangle with arrows flowing out from each to others. Two of them operate 24/7, and one 9-5 M-F. This graphic adds a message that centers must agree ahead to make C2C process to work.)

 

Slide 58:

Slide 58: Activity. A placeholder graphic of a hand typing on a computer keyboard indicating an activity.

 

Slide 59:

Learning Objective #5

Name some pre-arrangements before a system interface is implemented

Type your response in the chat pod

 

Slide 60:

Learning Objective #5

Types of Agreements

Memorandum of Understanding (MOU)

Example: Florida DOT District Four

Purpose: This......MOU.....provides the framework to promote a collaborative effort to
.....promote coordinated decision-making and information sharing in planning, design, deployment, operations,.......
Maximize communications between and among the network of traffic management centers.......

Source: www.smartsunguide.com/pdf/MOU.doc

 

Slide 61:

Learning Objective #5

Types of Agreements

Operational Agreement Covers:

 

Slide 62:

Learning Objective #5

Example: Agreement

Slide 62:  Example:  Agreement. Starnet - Sacramento Area Council of Governments logo

7 Formal Agreements
The Sacramento Region ITS Partnership Memorandum of Understanding for Participation in the Regional ITS Deployment Strategy, although not a binding agreement, provides a framework for cooperation between key STARNET stakeholders, especially for sharing of regional funds.

Source: http://www.fhwa.dot.gov/cadiv/segb/files/starnet/starnetstake.htm

 

Slide 63:

Learning Objective #5

Example

Puget Sound Regional Council

Slide 63:  Puget Sound Regional Council.  Please see the Extended Text Description below.

(Extended Text Description: Slide 63: This is an exerpt from the Puget Sound Regional Council. Here it references the listing of the following information:

4.6 Incident Management - 38
4.7 Data Archiving - 39
4.8 ITS Backbone - 40
4.9 Regional Multi-Modal Traveler Information Center (RMTIC) - 41
- 4.9.1 RMTIC Concept - 41
- 4.9.2 RMTIC Information - 41

4.10 Local Link to CVISN - 41
4.11 Railroad Operations Coordination - 42

The following listed items are boxed:
5 Agreements Between Organizations - 44

- 5.1 Existing, Planned and Potential Agreements - 44
- 5.2 Elements of an Agreement - 48)

Source: psrc.org/assets/543/regarch.pdf

 

Slide 64:

Learning Objective #5

TMDD's Relationships to Architecture

Slide 64:  TMDD's Relationships to Architecture.  Please see the Extended Text Description below.

(Extended Text Description: Relevant descriptive information provided by author for this figure: The slide shows a graphic with 12 boxes. Solid lines are connecting these boxes to indicate data flows identified by the Architecture and supported by the TMDD v3 partially, which include boxes labeled: Information Service Provider*, Event Promoter, Maintenance and Construction Operations*, Weather Service*, Surface Transportation Weather Service, Emergency Management, Toll Administration*, Transit Management*, Archive Data Management*, and Media. TMC can support six data flows to other centers with an asterisk. There is a thin oval shown over External Traffic Management Center and Traffic Management Center.)


Slide 65:

Learning Objective #5

Example of TMDD's Support

Slide 65:  Example of TMDD's Support.  Please see the Extended Text Description below.


(Extended Text Description: Relevant descriptive information provided by author for this figure: Based on the previous slide discussion, this slide has graphic that illustrates a market package set up with three boxes shown vertically. One on left is titled Information Service Provider or ISP, Traffic Management Center in the middle and Roadway Subsystem on the right. ISP and TMC have two arrows between them and cover C2C data flows. TMC and Roadway have two data flows between them and one from roadway to TMC, together all three serve C2F needs. )

 

Slide 66:

Learning Objective #5

Related C2C Standards

SI Implementation Requires:

1. TMDD v3 standard:

2. Application Protocol:

Slide 67:

Slide 67: Case Study. A placeholder graphic of a hand typing on a computer keyboard indicating an activity.

 

Slide 68:

Case Study

TMC-A has 24/7 traffic management operations, which includes 50 traffic signals, 7 DMSs, and 15 CCTV cameras, and has received approval from FHWA to develop an ITS project to add a system interface capability to exchange information with the adjoining TMC B.

Both TMCs have agreed to coordinate traffic management in the region and share event information and field devices.

A system interface is to be procured soon. What Next?

 

Slide 69:

Slide 69: Activity. A placeholder graphic of a hand typing on a computer keyboard indicating an activity.

 

Slide 70:

Please type in response in the chat room

1. The project will be guided by the SEP to develop the system interface desired by the TMCs.

2. The TMDDv3.0 standard will be used to develop the system interface for both TMCs.

3. In this case study the Owning Center is TMC A and the External Center is TMC B.

 

Slide 71:

Please type in response in the chat room

4. Which tool will you use to map the operational need? NRTM

5. How do we go about preparing project user needs? PrepareProject NRTM

6. Both TMCs must prepare a specification common with same set of user needs, requirements and data concepts to achieve off-the-shelf interoperability.

 

Slide 72:

Case Study Exercise

7. The overall Operational Need driving this development can be stated as traffic (congestion) management

8. The standardized user needs definitions can be found in TMDD v3.0 standard, Volume I Section 2

9. Information exchange related user needs are: roadway network, event sharing , device sharing, and data archiving. Additional four are related to network authentication management etc.

 

Slide 73:

Case Study Exercise (Cont.)

10. What pre-arrangement should TMCs have in place for implementation of the SI? MOU-SOPs-Agreement

11. NTCIP 2306-C2C XML is selected as a common protocol to support the system interface.

 

Slide 74:

What did we learned today?

 

Slide 75:

What did we learned today? (cont.)

 

Slide 76:

Next Steps:

Module A321b

Specifying Requirements for Traffic Management Systems Based on TMDD v3 Standard

 

Slide 77:

Where to Find More Information

 

Slide 78:

Slide 78: Questions. A placeholder graphic of a light bulb indicating questions.