Module 16 - A321b

A321b: Specifying Requirements 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:

A321b

Specifying Requirements for Traffic Management Systems Based on TMDD v3.0 Standard

 

Slide 4:

Target Audience

 

Slide 5:

Instructor

Photo of the instructor-Raman Patel

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

President

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

 

Slide 6:

Curriculum Path (SEP)

Curriculum Path (SEP). Please see the Extended Text Description below.

(Extended Text Description: 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,” 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 labeled “A3xxa Understanding User Needs for NTCIP 12xx vxx.” Finally, an arrow from this box connects it to a box labeled “A3xxb Specifying Requirements for NTCIP 12xx vxx.”)

 

Slide 7:

Curriculum Path (Non-SEP)

Curriculum Path (Non-SEP). Please see the Extended Text Description below.

(Extended Text Description: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 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. Discuss continuity with the TMDD user needs module Module A321a:

2. Understanding requirements

3. How to use Requirements Traceability Matrix (RTM) to specify standardized design concepts

 

Slide 11:

Learning Objectives (cont.)

4. Discuss the use of requirements from the NRTM and RTM in the specification

5. How to extend TMDD v3.0 standard

6. Introduce the TMDD v3.0 Guide as a resource

 

Slide 12:

Learning Objective #1

Review of Module A321a

Key Areas

  1. TMDD v3.0 standard supports system interface development for Center-to-Center Communications.
  2. Structure provides definitions of user needs, requirements, and data concepts for specification.
  3. Covers operational needs in 8 categories.
  4. Teaches how to develop Needs to Requirements Traceability Matrix (NRTM) for a project.

 

Slide 13:

Learning Objective #1

What is a System Interface?

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

What is a System Interface? Please see the Extended Text Description below.

(Extended Text Description: What is a System Interface? 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 14:

Learning Objective #1

System Interface (SI) Implementation

System Interface (SI) Implementation. Please see the Extended Text Description below.

(Extended Text Description: How a System Interface is Implemented? 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 15:

Learning Objective #1

System Interface Components

System Interface Components. Please see the Extended Text Description below.

(Extended Text Description:A graphical illustration introduces three circles marked with user needs, requirements and design. 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. 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. The text blurb "Description of what the interface must do to support operations (address problem-situation) appears on the left next to the User Needs circle. The text blurbe "Written in "shall" language, specific requirements to satisfy user needs (funcationality) is under the first blurb. A final text blurb "Only standard-supplied design data concepts are used to fulfill requirements (each requirement is "designed").)

 

Slide 16:

Learning Objective #1

User Needs and Requirements Supported

  1. Connection Management
  2. Support Authentication and Restrictions
  3. Provide Information on Organization
  4. Event Information Sharing
  5. Provide Roadway Network
  6. Provide Devices Inventory, Status, and Control
  7. Share Data for Archiving
  8. Accept Null Values

Defined in TMDD v3 Volume I

 

Slide 17:

Learning Objective #1

TMDD v3.0 Standardized Definitions

TMDD v3.0 Standardized Definitions. Please see the Extended Text Description below.

(Extended Text Description: Standardized Definitions: There are three boxes in this slide. Boxes reads inventory of definitions supplied by the TMDD v3 standard: "126 User Needs" in first light blue box with a lower small light blue box linked with a line "NRTM" to "134 Requirements" in second yellow box with lower yellow box "RTM" linked witha line to the last box (Volume I).  Last box (Volume II) has "600 Data Concepts", further broken down in a vertical series of purple boxes 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 18:

Learning Objective #1

Preparing NRTM for the Project

Select User Needs from Section 2, Volume I based on the project's operational needs

Example: Need to verify DMS status control

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

Mandatory

YES

Contents of Device Control Request Response

Allocate requirements as per the NRTM on page 174, Volume I

 

Slide 19:

Learning Objective #1

Achieving "Off-the-Shelf" Interoperability

Emphasis

 

Slide 20:

Summary of Learning Objective #1

Summary of Learning Objective #1. Please see the Extended Text Description below.

(Extended Text Description: Summary of LO#1:  Below the two bullets a graphic with two buildings is shown with arrow from each going to other. This shows that the two centers are communicating to each other and to reinforce that a text box on top of arrows is placed. The text reads as: Center to Center (C2C) Communications.)

 

Slide 21:

Summary of LO #1 (cont.)

Summary of LO #1 (cont.). Please see the Extended Text Description below.

(Extended Text Description: Summary of LO#1 (cont.):  The slide conveys that Module A321a teaches how to prepare NRTM and Module A321b teaches how to prepare project RTM. To illustrate this graphical layout is shown with 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 22:

Learning Objective #2

Life Cycle Process

Where do Requirements/Data Concepts fit?

Life Cycle Process. Please see the Extended Text Description below.

(Extended Text Description: Life Cycle Process - 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: 1) A time line at the bottom of the figure indicating that all steps proceed over time with the steps forming the V overlapping one another. 2) A downward arrow on the left side of the V that indicates that these steps deal with decomposition and definition. 3) An upward arrow on the right side of the V that indicates that these steps deal with integration and recomposition. 4) A horizontal arrow near the bottom of the center of the V that connects the detailed design step to the unit testing step. 5) A horizontal arrow a little higher that connects the subsystem requirements step with the subsystem verification step. 6) A horizontal arrow a little higher that connects the system requirements step with the system verification step. 7) A horizontal arrow near the top of the V that connects the concept of operations step with the system validation step. Finally, major steps are separated by a barrier that is labeled “document approval.” The main point of this slide is to show where requirements and data concepts fit on Vee diagram. To achieve that objective, the graphic shows Requirements pointing with an arrow to System Requirements stage on the Vee diagram and Data Concepts points to detailed design stage of the Vee diagram.)

 

Slide 23:

Learning Objective #2

Understanding Requirements

 

Slide 24:

Learning Objective #2

Example: Structure of a Requirement

Req. ID 3.3.6.1.5.1 (Volume I)

Req. Title Send DMS Control Response Upon Request

Description An owner center shall respond to an authorized external center requesting remote control of a DMS via a one-time control request with a message containing the status of the request.

 

Slide 25:

Learning Objective #2

Classification of Requirements

Both must be included in the project specification

 

Slide 26:

Learning Objective #2

Example: How Requirements are Allocated

10 requirements are allocated to one user need

UN ID

User Need

UN Selected

Req. ID

Require -ment

Conformance

Support

Other Req.

2.3.6.4.5

Need to Verify DMS Control Status

YES

3.3.6.1.4.2

Yes

3.3.6.1.4.2.1

Yes

3.3.6.1.4.2.2.1

Yes

3.3.6.1.4.2.2.2

Yes

3.3.6.1.4.2.2.3

Yes

3.3.6.1.4.2.2.4

Yes

3.3.6.1.5.1

Yes

3.3.6.1.5.2

Yes

3.3.6.1.5.3

Yes

3.3.6.5.4

Yes

Note: Project NRTM references Support column with YES

 

Slide 27:

Learning Objective #2

Example (cont.)

Requirements shown in column 5

3.3.6.1.4.2 Contents of Device Control Request Response (M)

An owner center shall send a device control request response to an external center.

3.3.6.1.4.2.1 Required Device Control Response Content (M)
3.3.6.1.4.2.2.1 Operator Identifier (O)
3.3.6.1.4.2.2.2 Operator Lock Identifier (O)
3.3.6.1.4.2.2.3 Owner Center Organization (O)
3.3.6.1.4.2.2.4 Operator Last Revised Date and Time (O)
3.3.6.1.5.1 Send Device Control Status Upon Request (M)
3.3.6.1.5.2 Contents of the Device Control Status Request (M)
3.3.6.1.5.3 Contents of Device Control Status Response (M)
3.3.6.5.4 Request DMS Control Status (M)

 

Slide 28:

Learning Objective #2

How is a Requirement Implemented?

Each requirements is fulfilled with a single design using data concepts from the RTM

  1. Standard provides a separate data concept for each requirement
  2. Project uses only data concept linked to the selected requirement

 

Slide 29:

Learning Objective #2

Understanding Data Concepts (DCs)

Types of Data Concepts

1. Dialogs

2. Messages

3. Data Frames

4. Data Elements

Understanding Data Concepts. Please see the Extended Text Description below.

(Extended Text Description: Understanding Data Concepts: The slide lists four data concepts on the left. On the right side a graphical box is shown. The box is labeled as 600 Data Concepts. A breakdown of these 600 DCs is represented with four small text boxes separated by arrows pointing to the next text box. The first text box is 124 dialogs, which is followed by 87 Messages box, which then points to a third text box called 187 Data Frames. This is followed by arrow pointing to the last box called 207 Data Elements.)

 

Slide 30:

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

 

Slide 31:

Learning Objective #2

What determines requirements for a system interface project?

Type your response in the chat room

 

Slide 32:

Learning Objective #2

Discuss

Do we select all 134 requirements? No

Do we select only mandatory ones? No

Do we select based on the project's needs? Yes

 

Slide 33:

Learning Objective #2

Example: Share Control of Devices

2.3.6.2 Need to Verify a DMS Control Status

Req. ID

3.3.6.1.4.2

Contents of Device Control Request Response

M

3.3.6.1.4.2.1

Required Device Control Response Content

M

3.3.6.1.4.2.2.1

Operator Identifier

O

3.3.6.1.4.2.2.2

Operator Lock Identifier

O

3.3.6.1.4.2.2.3

Owner Center Organization

O

3.3.6.1.4.2.2.4

Operator Last Revised Date and Time

O

3.3.6.1.5.1

Send Device Control Status Upon Request

M

3.3.6.1.5.2

Contents of the Device Control Status Request

M

3.3.6.1.5.3

Contents of Device Control Status Response

M

3.3.6.5.4

Request DMS Control Status

M

M-Mandatory O-Optional

 

Slide 34:

Summary of Learning Objective #2

 

Slide 35:

Learning Objective #3

Requirements Traceability Matrix (RTM)

Volume I Volume II

Section 3 Section 3

Requirement ID

Requirement Title

Dialog

Data Concept Name

DC Type

Standard Clause

 

Slide 36:

Learning Objective #3

RTM Provides a Design Solution for Each Requirement. Please see the Extended Text Description below.

(Extended Text Description: Relevant description as provided by author: RTM Provides a Design Solution for Each Requirement: The RTM view captured from the actual standard is shown with six columns and filled-in rows with requirements and their associated data concepts. A green border is placed over last four columns that relate to DCs and an arrow from the title of the slide points to the border. This means that design solution resides inside this green border portion.)

 

Slide 37:

Learning Objective #3

Data Concepts Representation

Data Encoding Formats

Note:

 

Slide 38:

Learning Objective #3

Example

Data Element in ASN.1 Representation

DEFINITION: Current volume for the link expressed in vehicles per hour.

link-volume ITS-DATA-ELEMENT ::= { DESCRIPTIVE-NAME "Link.Link-volume:rt" ASN-NAME "Link-volume"
ASN-OBJECT-IDENTIFIER { tmddDataElements 181 }
DEFINITION "Current volume for the link expressed in vehicles per hour."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
DATA-CONCEPT-TYPE data-element STANDARD "TMDD"
DATA-TYPE " Link-volume ::= INTEGER (1..100000) ii
FORMAT "ASN.1 encoding"
UNIT-OF-MEASURE "vehicles per hour" VALID-VALUE-RULE "see the ASN.1 DATA-TYPE"
}
"
}

 

Slide 39:

Learning Objective #3

Example

Data Element in XML Representation

DEFINITION: Current volume for the link expressed in vehicles per hour.

<xs:simpleType name="Link-volume">

<xs:restriction base="xs:unsignedInt">

<xs:minInclusive value="1"/>

<xs:maxInclusive value="100000"/>

</xs:restriction>

</xs:simpleType>

 

Slide 40:

Learning Objective #3

Forward/Backward Traceability with RTM

Forward-Backward Traceability with RTM. Please see the Extended Text Description below.

(Extended Text Description: Forward/Backward Traceability with RTM: Graphic shown in this slide is same as one in slide #17, except statistics are not shown and data concepts box conveys relationship among DCs with small arrows from dialogs to messages and from messages to data frames and from data frames to data elements. A backward arrow from RTM box points to Requirements on left and a forward arrow points to DC box on the right. This arrangement conveys that every requirement is traced in both directions during development process.)

 

Slide 41:

Beneficiaries of RTM

The specification writer

The user

The system integrator

The supplier

 

Slide 42:

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

 

Slide 43:

Learning Objective #3

What Are the Key Functions of a Project RTM?

Type your response in the chat room

 

Slide 44:

Learning Objective #3

Summarize RTM Functions

 

Slide 45:

Learning Objective #3

Summarize Conditions for Interoperability

Type your response in the chat room

 

Slide 46:

Learning Objective #3

Summary of

Conditions for C2C Interoperability

  1. Use project NRTM to choose the same set of user needs and associated requirements.
  2. Use project RTM to use the standardized design concepts (solutions).
  3. Use a common communication protocol .

Concerned centers must adhere to these conditions.

 

Slide 47:

Learning Objective #4

From Requirements to Data Concepts Using RTM

From Requirements to Data Concepts Using RTM. Please see the Extended Text Description below.

(Extended Text Description: Relevant information as provided by author: From Requirements to Data Concepts Using RTM: The Vee diagram shown on this slide is same as one in Slide 22 Life Cycle Process. Two steps are shown in text form, one requirements that points to system requirements on Vee and data concepts, a second step text points to high level and detailed design stages. Both slides, 21 and this 44, convey the same meaning.)

 

Slide 48:

Learning Objective #4

Data Concepts Organization: Dialog-Message-Data Frame-Data Element

Example of CCTV Requirements Traced to DCs

Example of CCTV Requirements Traced to DCs. Please see the Extended Text Description below.

(Extended Text Description: Relevant information as provided by author: Data concepts Organization: Dialogs, Messages, Data Frames and Data Elements: The RTM table graphic is shown with six columns and 12 rows for requirements and their associated DCs. The columns from left to right are: Requirement ID, Requirement Title, Dialog, Data Concept Name, DC Type and Standard Clause. Dialog Column shows an oval over entry 2.4.1, 2.4.2 and 2.4.3 beginning with row 2, 3 and 4. These dialogs are generic and serve requirements.  A small circle is placed in DC Type column to highlight that they (2.4.1 to 2.4.3) are dialogs.)

 

Slide 49:

Learning Objective #4

Generic Dialogs

Dialogs Describe a Sequence of Messages

Generic Dialogs. Please see the Extended Text Description below.

(Extended Text Description: Generic Dialogs: A graphic of two buildings shown here is same as one in slide 19. The word dialog is shown over the arrow. Three dialogs are listed below the graphic.)

 

Slide 50:

Learning Objective #4

Generic Dialog 2.4.1 Request-Response

M-Mandatory

Sequence Diagram. Please see the Extended Text Description below.

(Extended Text Description: Relevant information as provided by author: Generic Request-Response Dialog 2.4.1: Request-Response dialog sequence diagram is shown to the right of a text that describes what this generic dialog means. The graphic shows External Center on left and Owning Center on the right and a vertical rectangular is shown under OC in which all arrows end or originate. There are light vertical lines under each center top to down. A request message with an arrow from EC to OC is shown and another arrow from OC to EC is shown for response message. Similarly a set of arrows are shown further bellow for error, where a owner center returns an error messages to EC.)

 

Slide 51:

Learning Objective #4

Generic Dialog 2.4.2

Subscription

Sequence Diagram. Please see the Extended Text Description below.

(Extended Text Description: Relevant information as provided by author: Generic Request-Response Dialog 2.4.2: Same as above slide #50, except it explains subscription generic dialog.)

 

Slide 52:

Learning Objective #4

Generic Dialog 2.4.3

(publication message is same as a response)

Sequence Diagram. Please see the Extended Text Description below.

(Extended Text Description: Relevant information as provided by author: Same as above slide#51, except it explains publication generic dialog.)

 

Slide 53:

Learning Objective #4

Illustration of 2.4.1 Dialog

Display a New Message on a DMS

Display a New Message on a DMS. Please see the Extended Text Description below.

(Extended Text Description: Illustration: EC is requesting to display a new message on a remote DMS: Same graphic shown in slide 20 is shown here with a text dlDMSControlRequest over the arrows. A separate arrow from the Owning Center on right points to a DMS sign below that displays a three line message: Major Accident, 15 MI NB, ALT  I-10 WB. The intent is show how an EC can request to display a message on remote DMS.)

 

Slide 54:

Learning Objective #4

Example of a Partially Populated RTM

Display a Message on a Remote DMS

dlDMSControlRequest

Requirement ID

Requirement Title

Dialog

Data Concept Name

Data Concept Type

Standard Clause

3.3.6.1.4.1

Contents of Device Control Request Header

DeviceControlRequestHeader

data-frame

3.3.5.2

3.3.6.1.4.1.1

Required Device Control Request Header Content

Organizationlnformation

data-frame

3.3.17.3

3.3.6.5.3.1

Send DMS Control Response Upon Request

2.4.1

dlDMSControlRequest

dialog

3.1.6.1

3.3.6.5.3.2

Contents of DMS Control Request

dMSControlRequestMsg

message

3.2.6.1

3.3.6.5.3.2.1

Required DMS Control Request Content

DeviceControlRequestHeader

data-frame

3.3.5.2

3.3.6.5.3.2.2.1

Beacon Control

ntcip:DmsMessageBeacon

data-element

NTCIP
1203:5.6.8.6

3.3.6.5.3.3

Contents of DMS Control Response

deviceControlResponseMsg

message

3.2.5.2

Selection of Data Concepts Using RTM: DMS Example-Exhibit 3.6

(Source: TMDD v3.0 Guide Based on TMDD v3.0 standard)

 

Slide 55:

Learning Objective #4

Example: Dialog Traces to a Requirement

Volume II

Requirement ID

Requirement Title

Dialog

Data Concept Name

Data Concept Type

Standard Clause

3.3.6.5.3.1

Send DMS Control Response Upon Request

2.4.1

dlDMSControlRequest

dialog

3.1.6.1

 

Slide 56:

Learning Objective #4

Example: Messages Traces to a Dialog

Volume II

Requirement ID

Requirement Title

Dialog

Data Concept Name

Data Concept Type

Standard Clause

3.3.6.5.3.1

Send DMS Control Response Upon Request

2.4.1

dlDMSControlRequest

dialog

3.1.6.1

DEFINITION
A request-response dialog that allows an EC to request an OC to perform a control action on an OC DMS.

3.1.6.1 XML REPRESENTATION
<operation xmlns=M http://schemas.xmlsoap.org/wsdl/M
name="DlDMSControlRequest">
<input message="tns:MSG_DMSControlRequest"/>
<output message="tns:MSG_DeviceControlResponse"/> <fault
name="errorReport" message=,,tns:MSG_ErrorReport7></operation>

 

Slide 57:

Learning Objective #4

Tracing Messages

in ASN.1 Representation

3.1.6.1.3 ASN.1 REPRESENTATION
dlDMSControlRequest ITS-INTERFACE-DIALOGUE ::= {
DESCRIPTIVE-NAME ,ExternalCenter<-DlDMSControlRequest->OwnerCenter, ASN-NAME ,DlDMSControlRequest,
ASN-OBJECT-IDENTIFIER { tmddDialogs 22 } URL "R-R.gif"
DEFINITION "A request-response dialog that allows an external center to request an owner center to perform a control action on an owner center's dynamic message sign." DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"} ARCHITECTURE-REFERENCE { "traffic control coordination"
}
ARCHITECTURE-NAME {"U.S. National ITS Architecture"}
ARCHITECTURE-VERSION {"6.0"}
DATA-CONCEPT-TYPE interface-dialogue
STANDARD "TMDD" REFERENCED-MESSAGES {
{ tmddMessages 22 }, -- Input { tmddMessages 18 }, -- Output
{ tmddMessages 10 } -- Fault
}
REFERENCED-OBJECT-CLASSES {
{ tmddObjectClasses ownerCenter(18) },
{ tmddObjectClasses externalCenter(9) }
}
}

 

Slide 58:

Learning Objective #4

Verification of Requirements

  1. Requirements are complete
  2. Requirements are traced to DCs through RTM

 

Slide 59:

Learning Objective #4

Verification of Requirements (cont.)

  1. Requirements are met at all stages
  2. System verification and acceptance

Verification of Requirements (cont.). Please see the Extended Text Description below.

(Extended Text Description: Relevant information as provided by author: Verification of Requirements (cont.): same as Slide #22 Vee graphic details. On the right side of the Vee leg, text shows how user needs are facilitating at Validation stage and second text box shows how requirements are used at system Verification stage on Vee diagram. "Declare Victory" you have built the right thing...user needs are met" in yellow box and blue arrow pointing to "System Validation." "you have built the thing right...requirements are met" in lower yellow box with blue arrow pointing to "System Verification Deployment.")

 

Slide 60:

Learning Objective #4

Achieving Off-the-Shelf Interoperability

 

Slide 61:

Learning Objective #4

Information on Standards

Standards for System Interface Implementation

 

Slide 62:

Summary of Learning Objective #4

 

Slide 63:

Learning Objective #5

Extending TMDD Standard

Example: Student Supplement page 26

 

Slide 64:

Learning Objective #5

Conformance

 

Slide 65:

Learning Objective #6

What is the Purpose of the Guide?

 

Slide 66:

Learning Objective #6

Key Questions Addressed by the Guide

Question

Guide

TMDD Standard

Chapter

Section

Volume

Section

1

What is the purpose of this guide?

1

1.1

-

-

2

What is the scope of the TMDD Standard v3.0?

1

1.2

I

1.1

3

What are the key parts of the standard?

2

2.2

I

1.8

4

Is TMDD v3.0 backward compatible?

1

1.9

I

1.7

5

What are the conditions for conformance to the TMDD standard?

2

2.7

I

1.6

6

What is conformance? How is it different than compliance?

2

2.7

I

1.6

7

What if my needs are not met by the TMDD?

2

2.8

I

1.6.1

8

Which additional standards do I need to implement TMDD?

4

4.2.1-4.2.2

I

1.2

9

How can I prepare my specification for C2C system interface?

4

4.3

I

2,3

10

How does TMDD trace to the National ITS Architecture?

4

4.3.1

I

4

11

Where can I find TMDD design content?

4

4.3.5

II

2,3,4

12

Where can I find information on other ITS standards?

Ref. Tables

-

-

-

13

How was the TMDD standard developed?

1

1.8

I

-

14

How can I get TMDD v3.0 standard files?

References

II

2.0

 

Slide 67:

What Have We Learned?

Learning Objective #1

Continuity with A321a

Standard Structure. Please see the Extended Text Description below.

(Extended Text Description: Standard Structure: with graphic from slide #15. The text on the left states: Standard Structure: Volume I: ConOps/user needs; Requirements; NRTM. Volume II: Data Concepts; RTM.)

 

Slide 68:

What Have We Learned? (cont.)

Learning Objective #1

Continuity with A321a

 

Slide 69:

What Have We Learned? (cont.)

Learning Objective #2

Using NRTM:

 

Slide 70:

What Have We Learned? (cont.)

Learning Objective #3

Using RTM:

 

Slide 71:

What Have We Learned? (cont.)

Learning Objective #3,4

 

Slide 72:

What Have We Learned? (cont.)

Learning Objective #5

Learning Objective #6

 

Slide 73:

Learning Objective #6

Recommended References

  1. A321b Student Supplement
  2. TMDD v3.0 Guide, July 2011 http://www.ite.org/standards/distribution.asp
  3. The NTCIP Guide v04, October 2008 http://ntcip.org/library/documents/
  4. Systems Engineering Guidebook for ITS FHWA-Caltrans, v3.0 2009 http://www.fhwa.dot.gov/cadiv/segb/files/segbversion3.pdf
  5. Systems Engineering for Intelligent Transportation Systems, FHWA, 2007 http://ops.fhwa.dot.gov/publications/seitsguide/index.htm

 

Slide 74:

Learning Objective #6

TMDD Sequence

 

Slide 75:

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

Questions to Consider

  1. Which matrix standardizes relationships between requirements and design concepts?
  2. What are the minimum conditions to achieve interoperability using TMDD v3.0 standard?