Module 12 - A321a

A321a: Understanding User Needs for Traffic Management Systems Based on TMDD v3 Standard

HTML of the Student Supplement

(Note: This document has been converted from the Student Supplement 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.)

(Extended Text Description: Large graphic cover page with dark blue background with the title in white letters “A321a Understanding User Needs for Traffic Management Systems Based on TMDD v3 Standard.” At the middle left is the “Standards ITS Training” logo with a white box and letters in blue and green. The words “Student Supplement” and “RITA Intelligent Transportation Systems Joint Program Office” in white lettering are directly underneath the logo. Three light blue lines move diagonally across the middle of the blue background.)

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

Table of Contents

Traffic Management Operational Environment - 2

Conceptual Representation of a System Interface - 5

Introduction to the TMDD v3.0 Standard - 8

Structure of the TMDD v3 Standard - 17

User Needs Defined by the TMDD v3.0 Standard - 19

Preparing System Interface Specification - 26

References - 32

Traffic Management Operational Environment

To understand the potential uses of a C2C interface, one must first understand the operational context in which it would function.

(Extended Text Description: Relevant description information provided by author for this figure: Conceptual Representation of Operational Environment: A graphic shows an External Center (EC) with operator is communicating with a TMC with operator and link between two centers-C2C. Next to the TMC is a box that contains a list of field devices, in individual text boxes. The boxes are labeled the following: Actuated Signal Controller (ASC), Field Master (FM), Data Collection & Monitoring (DCM), Traffic Sensor Stations (TSS), Electrical Lighting Management Systems (ELMS), CCTV Cameras & Switches, Dynamic Message Signs (DMS), Environmental Sensor Stations, and Signal Control Priority. The entire diagram is conveying components of a conceptual operational environment. This Figure supports message of the Slide #25 in PPT presentation.)

NTCIP C2F Standards facilitate remote Command/Control functions

Figure 1: Conceptual Representation of Operational Environment

The concept of operations of traffic management is highly dependent on the command and control of the field devices and coordinated response to manage traffic flow conditions and resulting events on the regional transportation network. The traffic management concept of operations, when one emerges across the jurisdictional boundaries, aids both the traveling public, customers, and operators of the road networks who are concerned with safe and efficient operations of networks in the region. Regional traffic management activities such as congestion or incident management are dependent on interagency coordination in real-time. This impacts their customers—the traveling public and their need for travel information about the current conditions in the region. This in turn requires information exchanges within the C2C operational environment.

A modern Traffic Management Center (TMC) facility has become a focal point for agency operations—it houses the central system hardware and software, including operators and maintenance personnel; follows policies and procedures and other entities; carries out internal agency coordination; performs command and control of the field devices; and maintains coordination with the neighboring centers through the exchange of information in real-time as shown in Figure 1.

These centers often have different computer systems and software platforms, data formats, and databases, making system-to-system communication difficult, if not impossible to achieve. The TMDD-based C2C system interface is independent of all of these issues. It is effectively used to combine information from multiple centers; it allows operational staff to utilize assets across jurisdictions to improve operations; and it allows data to be fused and provided to centers across jurisdictions. (During the development of the TMDD v3.0 standard, users had stressed such needs to be supported by the C2C system interface).

Figure 1 depicts a conceptual view of an operational environment in which operators from a variety of diverse centers may use the TMDD-based system interface to request and receive information from a TMC about a field device or service (typically part of the ATMS) while also allowing them to contribute to the TMC.

In the above exhibit, an external center can be a public safety agency or another transportation center that may seek or provide information that is valuable to another center's operations. Such external centers often desire system-to-system communication to exchange information in real-time (compared to manual process) to coordinate their responses in a regional setting. As stated earlier, the types of information exchanged may include incident event information and control and command of the field devices, such as altering traffic signal timing or displaying a new message on a DMS.

In recent years, centers have also become more aware of the value added by the availability of real-time information (e.g. regional 511 and road weather services) and the benefit of mutual agreements that actively encourage the sharing of each other's ITS resources to improve response to an emergency or event in the region. For example, better incident detection and notification in real-time can engage appropriate public safety resources, provide more rapid medical care to save lives and minimize injury consequences, and reduce transportation infrastructure disruptions, as well as avoid secondary accidents. Better road situation information made available to all parties simultaneously also helps in the overall management of roadway incidents. In such an operational environment, multiple (and diverse) centers work effectively due to the smooth integration of information-ITS technologies and procedures.

The TMDD-based C2C system interface plays a key role in the above operational context by supporting the following to:

• Facilitate Remote Command and Control of Field Devices: For example, as shown in Exhibit 1, a neighboring EC (through prior arrangements) may be able to remotely control certain traffic devices that belong to another jurisdiction during after-hours or when a TMC may be closed, or at other times may "command" to take some action. Although such occurrences may not be common, during a major emergency such as a natural disaster in the region, such a need may arise.
• Share/Exchange Event Information: Information exchange is key to improved operational coordination and collaboration in the regional context. For example, within a C2C operational environment, the TMC and public safety external center often have information that is valuable to each other's operations. These centers often desire system-to-system communication to exchange information that will help them coordinate responses to transportation conditions that have regional impacts. The types of information may include incident event information or traffic congestion levels during a planned event.
• Provide Coordinated Response to Transportation Conditions: For example, a local traffic incident may have an impact on a region that necessitates a change in current signal timing on an arterial passing through multi-jurisdictions. In such a case, all TMCs in the region will attempt to coordinate a pre-planned or new response pattern.
• Share Roadway Network Data: For example, participating centers can make available to each other information on their roadway network, such as nodes, links, and routes. Centers can exchange route travel time with other centers, which in turn may be provided to travelers and other public organizations to help them plan routes. Other uses may include collecting transportation data for planning and research purposes (archiving).

Figure 2 illustrates how four areas of operation needs are served and the example in Figure 3 depicts how information about an event is being shared by the operation centers. Please also note that centers use such information to serve an overall "operational need", traffic flow management and or congestion management and to provide travel information.

(Extended Text Description: Relevant description information provided by author for this figure: Key Areas of Operational Needs: a graphic with a map in the middle and four text boxes around: Event Sharing on left, Data Collection on right, and describe Road Network on top side and Device Control at bottom. These four areas are key operational needs.)

Figure 2: Key Areas of Operational Needs

(Extended Text Description: Relevant description 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.)

Figure 3: Center to Center Event Information Exchange

Conceptual Representation of a System Interface

(Extended Text Description: Relevant description information provided by author for this figure: Conceptual Representation of System Interface: A graphic shows two boxes: EC on left and TMC on right. Both boxes have inside: Applications, database and user interface, to represent local system. A system interface is shown on the side creating a boundary with local system. Same is done for TMC, a system interface facing local system. EC and TMC are shown exchanging messages with two arrows. )

Figure 4: Conceptual Representation of System Interface

Figure 4 shows a conceptual representation of a system interface (SI). It shows that SI is a separate entity from the native applications that may exist and clearly SI is the one that handles messages across (conversation). Furthermore, this is done in a protocol-independent manner, meaning user can deploy either currently preferred XML application protocol or somewhat older DATEX protocol or any other in the future.

Thus, we learn here that agencies seeking interoperability among centers/systems must have a common SI and implement the same protocol to conduct information exchange.

System Interface Specification

Figure 5 shows three logical steps that make up a system interface specification; user needs, requirements, and design concepts. They in turn drive the system interface development, an agency's ultimate goal (additional factors may exist and form part of the specification). User must recognize that "all needs" solely exist to support operations. Conversely, if user needs don't support operations, they are not needed, and hence should not be included in a specification.

(Extended Text Description: Relevant description information provided by author for this figure: System Interface Specification: a graphic shows User Needs first then requirements and ends in Design Concepts. These three make up system interface specification. A separate box below shows system interface development step.)

Figure 5: System Interface Specification

A Requirement is a condition or capability, "solidly" expressed in "shall" language. Requirements link us to the next step, design content. We stop here for specification items. Next stage is system development stage, which is part of the local ITS project, a system interface will emerge with "construction" using TMDD design content (which contains data concepts...)

(Extended Text Description: Relevant description information provided by author for this figure: Overall Context of TMDD Deployment: A graphic with three text boxes shows logical steps to how TMDD is deployed: First text box is Traffic Management Operational Environment, second is TMDD v3 and last one is System Interface specification. Below two centers are shown, one on left is a TMC with SI and on right another one with External Center.)

Figure 6: Overall Context of TMDD Deployment

Quick Summary

The TMDD itself is not an interface or software. We have a task to write an unambiguous specification based on the TMDD v3 standard to get an interoperable system interface, which is additional software that works with a native system. Figure 6 outlines related topics from which a TMDD-based system interface emerges.

This course and others in the PCB series have provided an opportunity to explore ITS standards with an emphasis on how to identify and write user needs, requirements and design elements for a specification. The following sections will help us to understand underlying issues.

Introduction to TMDD v3.0 Standard

Need for a Standard-based System Interface

In recent years, a significant number of ITS standards have been developed and public sector agencies have deployed ITS systems based on such standards. However, prior to the standardization, agencies either had no interfaces at centers and performed communications tasks manually or had to opt for costly proprietary solutions, which required multiple interfaces as shown in Figure 7. Both situations are depicted in the following figures.

As shown in Figure 8 a TMDD-based interface installed at participating centers alleviate that situation. With TMDD v3.0 standard, agencies can develop a common interface based on their local traffic management needs and conduct real-time communications among centers.

(Extended Text Description: Relevant description 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.)

Figure 7: Centers without a Common Interface

(Extended Text Description: Relevant description information provided by author for this figure: This graphic is the same as in the previous figure, 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.)

Figure 8: Centers with a Common Interface

The Purpose of the TMDD v3 Standard

The overall purpose of the TMDD is to aid in system interface development. The specific purpose of the TMDD Standard for Traffic Management Center-to-Center Communications is to assist users in the procurement process by describing the potential user needs, establishing requirements, and tracing them to data content for system interface to facilitate information exchanges among centers. Consistent with the systems engineering approach, the TMDD standard aims at providing standards-based design content, high-level definitions in a protocol-independent manner, with which a system interface specification can be prepared. As the title of the standard implies, the focus is placed on the operational needs of traffic management within the C2C context. (The reader should also note that the TMDD is not an application-specific data dictionary).

Readers are further directed to read the Abstract on TMDD located at end of this document to gain insight on the purpose of the TMDD standard.

The Scope of the TMDD v3 Standard

The scope of the TMDD standard covers user needs, requirements, data concepts, and certain selected architecture data flows to enable C2C communications and for requesting specific action such as command and control of any of the ITS field devices. The TMDD standard supports:

1. A request for road network data (information) and conditions including roadway network inventory and status on nodes, links, and routes.
2. Sharing event information, event management, and other functions performed by the TMC.
3. A request to control and sharing of ITS field devices such as Dynamic Message Signs (DMS), Close Circuit TV (CCTV) Cameras, and Actuated Signal Controllers (ASC), etc.
4. Sharing data for archival purposes for traffic monitoring, roadway characteristics, and event data. Data collection and data fusion across deployment boundaries is a big benefit for regional planning, integration, and operations use (e.g. 511).

TMDD v3.0 Relationship to ITS Architecture

The TMDD standard supports the National ITS Architecture system perspective of centers or subsystems as shown in Figure 9, and identifies and describes the services that may be provided by a traffic management subsystem to external center subsystems by tracing architecture flows (information flows) and corresponding user needs and requirements. The types of centers supported by the TMDD standard include TMCs in adjacent regions or statewide centers (External TMCs), transit dispatching centers, emergency management/public safety 911 centers, maintenance/construction operations centers, and rail operating centers. These centers are different from each other in many aspects: for example, they deploy different equipment and software platforms, collect data and store data in different formats, and conduct different operations.

(Extended Text Description: Types Operational Centers Defined by the National ITS Architecture: A graphic with 10 boxes, five on each row shows up to represent operational center. First box is Traffic management, followed on first row by Emergency management, Toll Administration, Commercial Vehicle Administration, and Maintenance and construction Management being the last box. Second row boxes start with Information Service Provider, Emission Management, Transit Management, Fleet and Freight, and last one is archive Data Management.)

Figure 9: Types of Operational Centers Defined by the National ITS Architecture

(Source: National ITS Architecture v6.1, ITS Architecture 2008)

In addition, media, weather services, surface transportation weather services, and event promoters receive data from the TMC, and the TMC also receives data from some of them. As a common language, the TMDD supports C2C communications to improve coordination and collaboration with information exchanges in real-time. Conversely, without the TMDD standard, C2C communications will remain manual, resulting in a decreased coordination in regional traffic operations and limiting potential opportunities for collaboration.

TMDD v3.0 Relationship to other Standards

Although the main purpose of the TMDD standard is to support traffic management applications, TMDD concepts definitions are reusable across all ITS functional areas, such as emergency management, transit, and travel information for communications needs. The TMDD data concepts can be used with other ITS standards such as the Institute of Electrical and Electronic Engineers (IEEE) 1512 family of emergency management standards, Transit Communications Interface Profiles (TCIP), and the Society of Automotive Engineers (SAE) J2354 message sets for Advanced Traveler Information System (ATIS).

TMDD's Relationship to NTCIP C2C Standards

TMDD is a language, not an interface itself or a communication protocol. As a high-level information-level standard, the TMDD is used to develop a system interface, a software entity. As shown in Figure 4, as an information level data dictionary standard, the TMDD standard defines the content, syntax, and semantics of messages exchanges between center-based systems, but it does not define the mechanism of encoding and transporting a message between centers.

[Users should also note that there are separate dictionaries standards for other functional areas such as IEEE 1512 (emergency management), ATIS (traveler information), and TCIP (transit).]

NTCIP is a communication application level protocol designed to transport a message to the other end independent of the content. The NTCIP family of standards has developed two common protocols:

• NTCIP 2306 C2C-XML is based on the XML data representation and rules of message encoding and transport of the W3C (World Wide Web Consortium) Web Services Architecture, and also provides a way to define dialogs, based on the Web Services Definition Language (WSDL). (This is currently a preferred protocol).
• The NTCIP 2304 C2C-DATEX application profile takes the ASN.1 data representation, encodes it with a companion encoding standard (BER), and moves the information from center to center. (This was an earlier protocol, not much in use).

As shown in Figure 10, for the traffic management system interface implementation the following standards are required:

1. As a Language-Dictionary: TMDD Standard v3.0
2. As an Application Profile: NTCIP C2C (One of the two protocols available)

(Extended Text Description: Relevant description information provided by author for this figure: TMDD Implementations: A graphic shows TMDD Implementation in a top box. Underneath it are rows with two boxes. First row text boxes are ISO 14817-ASN.1 Data Concepts and XML Schema Data concepts. Bottom row right side has NTCIP 23o4 AP-DATEX-ASN.1 and NTCIP 2306 XML on right. )

Figure 10: TMDD Implementations

TMDD Standard v3.0 Development

As shown in Figure 11 the development of the TMDD v3.0 was driven by the application of the systems engineering process, committee consensus, and discussion with working focus groups and peer evaluations, including deployments efforts. Two key objectives of the development were to correct deficiencies identified with the earlier version and to incorporate lessons learned from deployments that utilized previous TMDD Version 2.1. The lessons learned and feedback received from C2C deployments are incorporated, including additional areas of scope and unresolved issues from the earlier version.

The standard includes data elements and message sets from the Clarus initiative (Clarus is Latin for "clear") to develop and demonstrate an integrated surface transportation weather observing, forecasting, and data management system. In addition the Archived Data User Service (ADUS) to enable transportation agencies to retain ITS-generated data and make them available for analysis is also supported. A large number of agencies provided significant feedback and participated in development work and reported defects in the previous version of the TMDD standard and had expressed new needs arising from their implementations. The TMDD v3.0 considered this feedback and incorporated modifications to the extent possible.

(Extended Text Description: Relevant description information provided by author for this figure: TMDD Development: A box contains text. Inside six boxes list activities in each box. Operational user needs workshop, SDO JC, SEP Project Management, Normative references and SE consultant, and ISO 14817 shown. A second text box lists the following organizations in a bulleted list: ITE, AASHTO, FHWA, State/Local Public Agencies, Systems Engineering Consultants, System Developers, Researchers, Private Sector Suppliers, and Other SDOs (SAE, IEEE,...) )

Figure 11: TMDD Development

In addition, the TMDD effort utilized the ISO 14817 standard (to replace the previously use of IEEE 1488 and 1489 standards) for data concepts and the development process was conducted as per the systems engineering guidelines.

Backward Compatibility

IEEE Standard Glossary of Software Engineering Terminology defines compatibility as an ability of two or more systems or components to perform their required functions while sharing the same hardware or software environment.

The reader should note that there are sufficient reasons to state that the TMDD v3.0 is not backward compatible with the previous version. The developers also determined that there were not many v2 based implementation in the field that would require backward compatibility and opted to improve the content of the new standard, a number of changes to the messages have been made. The revisions included some general redefinitions of elements that caused significant differences between two versions. Some of the changes with the greatest impact (from a backward compatibility standpoint) are:

• The development of generic device messages that are then configured for individual devices.
• The creation of a general device objects identifier, which replaced numerous identical (but uniquely named) ID data concepts in TMDD v 2.1.
• TMDD v3.0 dialogs that are based on the ISO 14827 (TMDD v 2.1 used IEEE standards).

TMDD and Interoperability

The TMDD standard plays a constructive role in providing standardized definitions of data concepts to facilitate design of a common system interface to serve C2C operational needs. This system interface design based on user needs replaces costly proprietary solutions. With TMDD-based system interface, centers can now compose consistent messages to carry out dialogs in a prescribed way. If two or more centers implement the same subset of user needs and requirements in a common specification, the resulting system interface can provide interoperability.

Centers from different functional areas desiring interoperability with TMCs must have a TMDD-based system interface specification and a common application level protocol. In addition, for messages to arrive at the destination as intended ("bits and bytes on the wire"), common transport level and sub-network level protocols must be deployed at both ends to complete the communication process. For additional information readers are directed to the TMDD v3.0 Guide.

Pre-conditions for Achieving Interoperability: To ensure interoperability, the parties involved in the sharing of information shall participate in the development of the system interface specification. Interoperability is attained only if multiple networked systems implement the same protocols, dialogs, messages, and data content definitions, i.e., they implement the same system interface specification (including user needs/requirements). For example, at the application level, AP-DATEX and AP-C2C XML are not interoperable. Therefore, only one application level standard can be chosen.

[The transport level contains the TCP/IP standard. The TCP/IP has been described as the "Swiss Army Knife" of communications. It is the glue between systems on a network and the network infrastructure. In the subnetwork and plant levels, hardware and electronics may exist for connecting disparate communications media. For example, 700 MHz and 800 MHz systems will not communicate with each other, nor will PCS communicate with cellular telephones. Therefore, for a connection between any two units, one subnetwork standard must be chosen for each communication link, and that subnetwork standard must provide capabilities to interface with the plant level used.]

What if a need is not found in the TMDD standard?

The following is a hypothetical situation that has created a new ConOps that was not addressed by the TMDD and necessitated a definition of a new user need, as well as corresponding requirements and data concepts.

"We have a concept of operations that is unfolding in our region. We are thinking about introducing variable congestion pricing on our High Occupancy Vehicle (HOV) facilities and if that happens, a TMC may manage the facilities with a variable pricing scheme imposed by yet another regional center, and they may need to "talk" to each other in real time to communicate pricing schemes. This need is not included in the current standard. What should we do?"

The response to such a situation can be to extend the standard if needed by the following rules stated in Exhibit 2-11 in TMDD v3.0 Guide.

However, in general, "Extensions" to a TMDD conformant implementation are discouraged because they break interoperability (the reason why the TMDD standard was created). However, it is recognized that the TMDD standard does not satisfy every possible user need that can exist between two centers. Therefore, it allows for specific project implementations to "extend" or add new needs, requirements, and data concepts (dialogs, messages, etc.) to the implementation. To support these additional requirements, project implementations are allowed to "extend" the standard by defining new data elements, data frames, or data messages outside the TMDD standard. (Please consult TMDD v3 Guide for full discussion on this topic).

TMDD Standardized Data Concepts

Data is a representation of facts, concept, or instructions in a formalized manner suitable for communication, interpretation, or processing by human or by automatic means. Various Data concepts are shown the side figure. (see TMDD v3 Guide for details).

As shown in the box, TMDD data concepts includes dialogs that start a conversation, messages pertain to a function or information and data frames and data elements are used to construct fixed messages. These data concepts support the four areas discussed below. Data concepts in the TMDD v3 standards are developed in two formats: ASN.1 and XML. Users need to choose only one format and both cannot be mixed. Also for interoperability, centers must choose same format-based data concepts in system interface design.

(Extended Text Description: This figure is a box labeled Data Concepts with four text boxes, which read, from top to bottom: "Dialogs" with an arrow pointing to "Messages" with an arrow pointing to "Dara Frames" with an arrow pointing to "Data Elements". Each arrow is pointed diagonally progressively to the the right and down to the next text box.)

Support for User Needs Areas

TMDD enables interoperability (the ability of two or more systems or components to exchange information and use the information that has been exchanged). TMDD accomplishes this task by supplying raw materials (data concepts) from which a system interface can emerge to perform information exchange tasks shown in the box. Thus with TMDD-based solutions, one can also expect to achieve the full potential of the ITS capabilities and assets located across boundaries in an interoperable manner. For example, a seamless data exchange would make it possible for an emergency services vehicle to notify a traffic management center to trigger a change in the timing of the traffic signals on the path to a hospital, in order to assist the responding ambulance.

The TMDD standard's contribution to strengthen interoperability achievements can be summarized in the following three ways:

• TMDD standard accounts for typical needs of neighboring centers related to ITS devices, event management, and other functions performed by the TMC.
• TMDD data concepts are reusable by other functional areas to support domain specific-needs. Thus TMDD effort has avoided confusion among application areas.
• TMDD standard can be integrated with other ITS standards such as NTCIP and IEEE 1512 families.

(Extended Text Description: This figure shows five text boxes stacked on top of each other, which read, from top to bottom: "TMDD Addresses Needs for:" with an arrow leading to the four text boxes below, which read, "Providing Road Network Data", "Sharing Event", "Providing Shared Control of Devices", and "Sharing Data for Archiving.")

Structure of the TMDD v3.0 Standard The TMDD v3.0 Standard Organization

As shown in Figure 12, Volume I and Volume II together make up the TMDD v3.0 standard. The standard documentation organization follows this sequence—User Needs-Requirements-Data Concept—and guides the reader through specification preparation for the system interface consistent with the systems engineering approach. In this layout, Volume I deals with addressing a known C2C problem, and Volume II provides for solution content that a separate design phase of the project will use.

(Extended Text Description: Relevant description information provided by author for this figure:  TMDD Standard Organization: Same as slide # 38, with addition of Volume I shown above User Needs and Requirements and Volume II shown above Design concepts. 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. )

Figure 12: TMDD Standard Organization

The readers should view the NRTM and RTM as tools in preparation for a project specification that is requirements-centric to system interface design. As shown in Figure 4, NRTM is the only way to select standard-supplied user needs and tailoring requirements that satisfy the selected user needs. Similarly only through RTM necessary specific-design concepts (solutions) that fulfill the requirements are selected. As shown in Figure 4, there are no direct links between user needs and requirements. Thus, the TMDD standard has ensured traceability in both forward and backward direction of development process, in addition to providing for standardized definitions of user needs, requirements and design concepts.

Prior to the NRTM review, users should have already firmly established their ConOps directed operational needs in consultation with the concerned stakeholders using the SEP. The resulting operational needs of the local project will be mapped to those in the standard through the NRTM. This step ensures that the TMDD-based specification work begins with the local project-centric approach to user needs and not necessarily dictated by the broadly-based standard.

TMDD v3.0 Standard Sections

Figure 13 shows how various sections are organized for each of the two volumes of the TMDD v3.0 standard. Users are advised to refer to each Volume with a section number as a pair (e.g. Volume I, Section 3) for clarity and to avoid using page numbers altogether in the specification. Also be advised that each User Need has been provided with a unique ID number and each requirement(s) has an ID number, both listed in the NRTM. Each data concept is referred to by the standard clause and relates to requirements in the RTM. Users must adhere to columns provided in the standard while preparing their project-specific NRTM and RTM.

Volume I

Concept of Operations and

Section	Section Title (Purpose)
Section 1	Documentation Introduction (General Information, Organization)
Section 2	Concept of Operations for TMC to Center Communications (Listing of User Needs: event sharing, sharing of devices, control and status, sharing data for archiving)
Section 3	Requirements (Listing of Requirements to match with the above needs, from which the users will prepare their local project specification)
Section 4	Traceability to National ITS Architecture (Mapping to ITS Architecture Flows)
Section 5	Needs to Requirements Traceability Matrix (NRTM) (Checklist to verify needs/requirement combination)

Volume II

Design Content

Section	Section Title (Purpose)
Section 1	Documentation Introduction (shows relationship between Volume I and II)
Section 2	TMDD Interface Dialogs and Messages (Basic information on dialogs and lists Generic TMDD Dialogs, information on ASN.1, Object Identifiers, and XML)
Section 3	TMDD ISO 14817 ASN.1 and XML Data Concept Definitions (Lists related Data Concepts: Dialogs, Messages, Data Frames, Data Elements)
Section 4	Requirements Traceability Matrix (RTM) The RTM traces Requirements defined in Volume I to each Data Concept defined in Volume II. Also note that data concepts fulfill intended function of each requirement in Volume I.

(Extended Text Description: Figure 13: TMDD Standard Sections: Two text boxes are shown one for Volume I on the left has five sections listed and volume II on the right side has listed four sections.)

Figure 13: TMDD Standard Sections

User Needs

[User needs describe one or more system features and the intent of the said need in addressing a user problem or responsibility. Requirements describe what information is and how these operations are exchanged with external center (EC) subsystems through a communications interface. The requirements also describe what functionality is supported across the interface. (TMDD v3 Standard)

As shown in the table Volume-I, Section 2 of the TMDD standard describes 126 user needs to support the operational environment. Project-specific operational needs must be mapped to these user needs in the standard. To aid in this process, users can read high level definitions of the standard user needs, and align them with project's operational need. For example, an external center may be only interested in sharing information about an event such as a road crash should examine 11 user needs outlined in the standard to decide which of them satisfy project's operational needs. Centers that desire to exchange information with each other must select same subset of user needs.

Additionally, user is required to select six mandatory user needs listed above as stipulated by the standard. A specification that does not include mandatory needs will be considered non-conformant and may result in breaking interoperability (agencies desiring interoperability among centers must select a common set of user needs to drive the development of a common system interface).

A full list of user needs defined by the TMDD v3 standard is provided in the following section.

#	Need	Total	Volume I Section
1	Need for Connection Management	4	2.3.1
2	Need for Authentication and Restrictions	4	2.3.2
3	Need to Provide Information on organization, Centers and Contacts	1	2.3.3
4	Need to Share Event Information	11	2.3.4
5	Need to Provide Roadway Network Data, includes sub-needs	11	2.3.5
6	Need to Share Control of Devices (Inventory, Status and Control of Detectors, CCTV, Video Switch, DMS, ESS, Gate Control, HAR, Lane Control, Ramp Meters, Traffic Signal Control	87	2.3.6
7	Need to Share Data for Archiving	7	2.3.7
8	Need to Accept Null Values	1	2.3.8
Mandatory User Needs (M) S Verify Connection Active (UN ID 2.3.1.1) S Request Need to Support (UN ID 2.3.1.2) S Need to Support Error Handling (UN ID 2.3.1.4) S Need for Node Inventory (UN ID 2.3.5.1.1) S Need for Link Inventory (UN ID 2.3.5.1.2) S Need to Accept Null Values (UN ID 2.3.8)

User Needs Defined by the TMDD v3.0 Standard

(Source: Based on TMDD v3.0 standard, Volume I, Table of Contents)

2.3 Needs - 12

2.3.1 Need for Connection Management - 12

2.3.1.1 Verify Connection Active - 12
2.3.1.2 Need to Support Requests - 12
2.3.1.3 Need to Support Subscriptions - 12
2.3.1.4 Need to Support Error Handling - 12

2.3.2 Need to Support Authentication and Restrictions - 13

2.3.2.1 Need to Specify Restrictions - 13
2.3.2.2 Need to Authenticate the Source of Messages - 13

2.3.3 Need to Provide Information on Organizations. Centers, and Contacts - 13

2 3.4 Need to Share Event Information - 13

2.3.4.1 Need For An Index of Events - 14
2.3.4.2 Need to Correlate an Event with Another Event - 14
2.3.4.3 Need to Provide Free Form Event Descriptions - 14
2.3.4.4 Need to Provide Free Form Event Names - 14
2.3.4.5 Need to Provide Multilingual Event Descriptions - 14
2.3.4.6 Need for Current Event Information - 14
2.3 4.7 Need for Planned Event Information - 14
2.3.4.8 Need for Fore cast Event Information - 15
2.3.4.9 Need to Share the Log of a Current Event - 15
2.3.4.10 Need to Reference a URL - 15
2.3.4.11 Need to Filter Events - 15

2.3.4.11.1 Need to Filter Event Recaps - 15
2.3.4.11.2 Need to Filter Event Updates - 15

2.3.5 Need to Provide Roadway Network Data - 15

2.3.5.1 Need for Roadway Network Inventory - 16

2.3.5.1.1 Need for Node Inventory - 16
2.3 5.1.2 Need for Link Inventory - 16
2.3.5.1.3 Need for Route Inventory - 16

2.3.5.2 Need to Share Node, Link and Route Status - 16

2.3.5.2.1 Need to Share Node State - 16
2.3.5.2.2 Need to Share Link State - 16
2 3.5 2.3 Need to Share Route State - 16

2 3.5.3 Need to Share Link Data - 16
2.3.5.4 Need to Share Route Data - 16
2.3.5.5 Needto Maintain English Units - 17

2.3.6 Need to Provide Control of Devices - 17

2.3.6.1.1 Need to Share Detector Inventory - 18
2.3.6.1.2 Need Updated Detector Inventory - 1B
2.3.6.1.3 Needto Share Detector Status - 18
2.3.6.1.4 Need for Detector Metadata - 18
2.3.6.1.5 Need for Detector Data Correlation - 1 8
2.3.6.1.6 Need for Detector Data Sharing - 18
2.3 6.1.7 Need for Detector History - 18

2.3.6.2 Need to Share CCTV Camera Status and Control - 19

2.3.6.2.1 Need to Share CCTVDevice Inventory - 19
2.3.6.2.2 Needto Share Updated CCTVDevice Inventory - 19
2.3.6.2.3 Need to Share CCTVDevice Status - 19
2.3.5.2.4 Need to Control a Remote CCTV Device - 19
2.3.6 2 5 Need to Verify CCTV Control Status - 20
2.3.6.2.6 Need to Cancel CCTV Control Requests - 20

2.3.6 3 Need to Share Video Switch Status and Control - 20

2.3.6.3.1 Need to Share Video Switch Inventory - 20
2.3.6.3 2 Need to Share Updated Video Switch Inventory - 20
2.3.6.3.3 Need to Share Video Switch Status - 20
2.3-5.3.4 Need to Control a Remote Video Switch - 21
2.3.6.3.5 Need to Verify Video Switch Control Status - 21
2.3.6.3.6 Need to Cancel Video Switch Control Requests - 21

2.3.6.4 Need to Share DMS Status and Control - 21

2.3.6 4 1 Need to Share DMS Inventory - 21
2.3.6.4.2 Need to Share Updated DMS Inventory - 21
2.3.6.4.3 Need to Share DMS Status - 21
2.3.5.4.4 Need to Display a Message on a Remote DMS - 22
2.3.6.4.5 Need to Verify DMS Control Status - 22
2.3.6.4.6 Need to View DMS Message Queue - 22
2.3.6 4 7 Need to Cancel DMS Message Requests - 22
2.3.6.4.8 Need to Share DMS Message Appearance - 22
2.3.6.4.9 Need to Share DMS Message Inventory - 22
2.3.6 4.10 Need to Share DMS Font Table - 23

2.3.6.5 Need to Share Environment Sensor Data - 23

2.3.6.5.1 Need to Share ESS Inventory - 23
2.3.6.5.2 Need to Share Updated ESS Inventory - 23
2.3.6.5.3 Need to Share ESS Device Status - 23
2.3.6.5.4 Need to Share ESS Environmental Observations - 24
2.3.6.5.5 Need to Share ESS Environmental Observation Metadata - 24
2.3.6.5.6 Need to Receive a Qualified ESS Report - 24
2.3.6.5.7 Need to Share ESS Organizational Metadata - 24

2.3.6.6 Need to Share Lane Closure Gate Control - 24

2.3.6.6.1 Need to Share Gate Inventory - 24
2.3.6.6.2 Need to Share Updated Gate Inventory - 24
2.3.5.6.3 Need to Share Gate Status - 25
2.3 6.6.4 Need to Control a Remote Gate Control Device - 25
2.3.6.6.5 Need to Verify Gate Control Request Status - 25
2 3.6 6 6 Need to Cancel Gate Control Device Requests - 25
2.3.6.6.7 Need to Share Gate Control Schedule - 25

2.3.6.7 Need to Share Highway Advisory Radio (HAR) Status and Control - 25

2.3.6.7.1 Need to Share HAR Inventory - 25
2.3.6.7.2 Need to Share Updated HAR Inventory - 26
2 3.6 7 3 Need to Share HAR Device Status - 26
2.3.6.7.4 Need to Control a Remote HAR Device - 26
2 3.6 7 5 Need to Verify HAR Control Request Status - 26
2.3.6.7.6 Need to View HAR Message Queue - 26
2.3.6.7.7 Need to Cancel HAR Control Requests - 26
2.3.6.7.8 Need to Share HAR Schedule - 26
2.3.6.7.9 Need to Share HAR Messages - 27

2.3.6.8 Need to Share Lane Control and Status - 27

2.3.6.8.1 Need to Share Controllable Lanes Inventory - 27
2.3.6.8.2 Need to Share Updated Controllable Lanes Inventory - 27
2.3.5.8.3 Need to Share Controllable Lanes Status - 27
2.3.6.6.4 Need to Control a Remote Lane Control Device - 27
2.3.6.8.5 Need to Verify Lane Control Device Control Status - 27
2.3.6.8.6 Need to Cancel Lane Control Device Control Requests - 28
2.3.6.8.7 Need to Share Controllable Lanes Schedule - 28

2.3.6.9 Need to Share Ramp Meter Status and Control - 28

2.3.6.9.1 Need to Share Ramp Meter Inventory - 28
2.3.6.9.2 Need to Share Updated Ramp Meter Inventory - 28
2.3.6.9.3 Need to Share Ramp Meter Status - 28
2.3 6.9.4 Need to Control a Remote Ramp Meter Device - 28
2.3.6.9.5 Need to Verify Ramp Meter Control Request Status - 29
2.3-5.9.6 Need to Cancel Ramp Meter Control Requests - 29
2.3.6.9.7 Need to View Ramp Metering Plan Queue - 29
2.3.5.9.8 Need to Share Ramp Metering Schedule - 29
2.3.6.9.9 Need to Share Ramp Metering Plans - 29

2.3.6.10 Need to Share Traffic Signal Control and Status - 29

2.3 6.10.1 Need to Share Signal System Inventory - 29
2.3.6.10.2 Need to Share Updated Signal System Inventory - 30
2.3.6.10.3 Need to Share Intersection Status - 30
2 3.6 10.4 Need to Control a Remote Traffic Signal Controller - 30
2.3.6.10.5 Need to Verify Traffic Signal Controller Control Request Status - 30
2.3.6.10.6 Need to View Traffic Signal Controller Plan Queue - 30
2.3.6.10.7 Need to Cancel Traffic Signal Controller Control Requests - 30
2.3.6.10.8 Need to Share Controller Timing Patterns - 30
2.3.6.10.9 Need to Filter Controller Timing Patterns - 31
2.3.6.10.10 Need to Share Controller Schedule - 31
2.3.6.10.11 Need to Share Turning Movement and Intersection Data - 31
2.3.5.10.12 Need to Share Time Synchronization Information - 31
2.3.6.10.13 Need to Monitor Signal Operations - 31
2.3.6.10.14 Need to Share Section Status - 31
2.3.6.10.15 Need to Control a Section - 31
2.3.6.10.16 Need to Verify Section Plan Status - 32
2.3 6.10.17 Need to View Section Plan Queue - 32
2.3.6.10.1 S Need to Cancel Traffic Signal Section Control Requests - 32
2.3.6.10.19 Need to Share Section Timing Pattern Schedule - 32

2.3.7 Need to Share Data for Archiving - 32

2.3.7.1 Need for Traffic Monitoring Data - 32

2.3.7.1.1 Need for Direct Measurements of Traffic Flow and Conditions - 32
2.3.7.1.2 Need for Original Source Data for Traffic Monitoring Measurements - 32
2 3.7 1.3 Need for Processed Traffic Monitoring Data - 33
2.3.7.1.4 Need for Data Collection System Metadata - 33
2-3.7.1.5 Need for Processing Documentation Metadata - 33
2.3.7.1.6 Need for Roadway Characteristics Data - 33
2.3.7.1.7 Need for Event Data - 33

2.3.8 Need to Accept Null Values - 33

Note: each of the above listed user needs is listed in the table format called NRTM discussed in the following section. All user needs are described in Section 2, Volume I.

Needs to Requirements Traceability Matrix (NRTM)

An operational need arises from a project ConOps, as illustrated in the box: Need to Verify CCTV Control Status (Section 2.3.6.2.5) as an example. The need states a desire of the external centers to know if the camera images are currently available or not and its justification.

Need to Verify CCTV Control Status

The center that sends a control request for a CCTV device operated by another center needs to verify the status of the control request. The status may be that the request was implemented, was queued, or was rejected.

As shown in the table below, using the NRTM (Volume I, Section 5) will enable the user to match the operational need to the first column and select UN ID 2.3.6.2.5 with YES in the second column. (This completes the N part of the NRTM).

At this point, the NRTM traces to 10 requirements, displaying the Requirement ID in the third column with the tile in the fourth column. (This is the R part of the NRTM). The TMDD standard states at least six are mandatory.

Sample Needs to Requirements Traceability Matrix (NRTM)

UN ID User Need 2.3.6.2.5 Need to Verify CCTV Control Status	UN Selected	Requirement ID	Requirement	Conformance	Support	Other Requirements
	Yes / No	3.3.6.1.4.2	Contents of Device Control Request Response	M	Yes
		3.3.6.1.4.2.1	Required Device Control Response Content	M	Yes
		3.3.6.1.4.2.2.1	Operator Identifier	O	Yes / No
		3.3.6.1.4.2.2.2	Operator Lock Identifier	O	Yes / No
		3.3.6.1.4.2.2.3	Owner Center Organization	O	Yes / No
		3.3.6.1.4.2.2.4	Operator Last Revised Date and Time	O	Yes / No
		3.3.6.1.5.1	Send Device Control Status Upon Request	M	Yes
		3.3.6.1.5.2	Contents of the Device Control Status Request	M	Yes
		3.3.6.1.5.3	Contents of Device Control Status Response	M	Yes
		3.3.6.3.4	Request CCTV Control Status	M	Yes

Note: In this Exhibit, only one need is illustrated. When a user completes a project-specific NRTM, the user will select multiple user needs (UN IDs) from the first column, which maps to the allocated requirements: M-Mandatory O-Optional.

The remaining four requirements are marked as O and are left to the local project to decide if they are to be selected and should be marked appropriately in the Support column of the NRTM; once these are selected, they are mandatory and form (along with the other six mandatory requirements) the project implementation specification relating to this particular user need (Need to Verify CCTV Control Status in this example). When all 10 requirements are determined, the R part of the NRTM is completed. In the last column of the project NRTM, users may decide to place notes to further certify the specification.

From this illustration, we can see the critical use of the NRTM as intended by the TMDD standard consistent with the system engineering approach, where only user needs drive the requirements. The NRTM is provided by the TMDD standard to guide users at several levels:

• A specification writer uses the NRTM columns to ensure how requirements are to be implemented in a project-specific implementation.
• A protocol implementer uses the NRTM as a checklist to reduce the risk of failure to conform to the standard through oversight.
• An ITS project management uses the NRTM to ensure that the communication capabilities with associated centers are met.

Those who are concerned with the interoperability among agencies must also ensure that User Needs to support desired functions (and requirements that satisfy those user needs) are selected in their specification. For example, if a regional TMC of a state desires to share CCTV information with a city TMC in the region, both must select this user need to achieve interoperability. The NRTM helps both agencies to compare and select their needs. In general, by working together they should develop a "common" specification or exchange of each other's specifications.

Preparing System Interface Specification

Introduction

This chapter expands on the course discussion on how to prepare project specifications using the TMDD standard. The chapter outlines four key steps at the ConOps stage of the SEP and content of the two volumes of the TMDD standard needed to prepare a system interface specification. Please note that a system interface specification is a document that contains complete definitions of the data concepts (dialogs, messages, data frames, and data elements) for the system interface and mapping of the requirements (with the use of RTM).

Specification Considerations

Students may recall detailed discussion in modules A101 and A201 on the acquisition process to procure a system that is based on the ITS standards. Acquisition process documentation includes a complete, consistent, and correct statement on what is desired from the system being procured.

A project specification document (regardless of its title) achieves that purpose in which an agency outlines services desired from a TMDD v3.0 standard-based system interface. This information may be provided in a section in the procurement document.

While the nature of documentation may vary from project to project (based on type of system being procured) and perhaps agency to agency, in general, from the user needs stand point, following components should be considered and included in a specification document:

1. A general background of the project, problem definition, and ConOps/operational needs
2. A populated NRTM for the project: developed by mapping operational needs to those in TMDD

Additional considerations beyond these two are not discussed here but will be required in a full procurement document. An agency desiring to proceed with acquisition of a system interface must begin with the above steps in consultation with their system support consultant.

The "V" diagram shown in Figure 6 outlines four steps for preparing the TMDD-based, system interface specification. The "V" Model shows us where these steps are occurring in the SEP life cycle. Each step is explained in details followed by the "V" diagram.

Applicable TMDD standard sections are identified in each step and mapped to the stages SEP. Users should be guided by these steps to prepare a project specific specification. NRTM and RTM tools provided by the TMDD standard must be used.

Mapping TMDD Standard to "V" Model Steps

Figure 14 shows four steps to guide the user in mapping project level user needs for specification preparation. Each step is linked to pertinent portion of the standard.

(Extended Text Description: Relevant description 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:

• 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.
• A downward arrow on the left side of the V that indicates that these steps deal with decomposition and definition.
• An upward arrow on the right side of the V that indicates that these steps deal with integration and recomposition.
• A horizontal arrow near the bottom of the center of the V that connects the detailed design step to the unit testing step.
• A horizontal arrow a little higher that connects the subsystem requirements step with the subsystem verification step.
• A horizontal arrow a little higher that connects the system requirements step with the system verification step.
• 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 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.

Above the SEP V diagram Step 1 and Step 2 are listed in text boxes, below SEP Vee two more text boxes list Step 3 and Step 4.)

Figure 14: System Life Cycle Process

Step-1: Regional ITS Architecture

Readers may recall that the market packages developed by the ITS Architecture collect several different subsystems (including equipment packages, terminators) and architecture flows (information flows between subsystems) to provide the desired service. To implement architecture flows between subsystems (centers), the TMDD standard has provided traceability to the National ITS Architecture selected number of relevant market packages to C2C needs.

As a first step towards preparation for the system interface specification, the reader is advised to also review the work done by the TMDD standard to support communications needs arising from regional ITS architecture market packages, and architecture flows. Architecture flows originating from the traffic management center to other centers and the corresponding user needs and requirements are discussed in the Volume I, Section 4.

The specification writing process should first check with local regional architecture market package C2C needs and then select appropriate architecture flows and related user needs as per Section 4, Volume I. The market packages (partial list) supported by the TMDD standard include: Network Surveillance, Traffic Information Dissemination, Regional Traffic Operations, Traffic Incident Management, Road Weather Data Collection, Roadway Maintenance and Construction, ITS Data Mart, Emergency Call-Taking and Dispatch, Emergency Routing, Disaster Response and Recovery and Broadcast Traveler Information. In all cases, the TMDD standard supports not the entire market package but a subset of the interfaces.

Step-2: Selecting User Needs with NRTM

Begin with Operational Needs: Users should be able to identify potential user needs by observing the C2C operational scenarios. Operational scenarios define the sequence of activities to be performed to satisfy user needs as well as the information flows between entities, both during normal operations and in emergency situations. For example, the operational scenario may include the procedures on how public safety agencies make requests for event information, road network data, device status and inventory, etc. from a TMC. In a C2C context, the need to communicate with others and/or request and receive information also varies. For example, at some agencies the C2C context may only have a need for sharing DMS messages and/or CCTV control while operating within the freeway environment. At another place, local agencies may be only interested or need the C2C system interface for traffic signals operations.

The TMDD standard lists a broad range of user needs of which local agencies may need only a small subset based on their ConOps. At this step of the SEP, people who will use the intended system interface or will be affected by its use must be engaged in selecting user needs for their specific project. This is critical because user needs set the tone for the project by clearly defining "what will be needed to support an operational problem solution" and dictate "how" system requirements will emerge in the next phase with which a system interfaces design is done. Only clearly stated user needs using NRTM will ensure that; if users miss them, an "imperfect" system interface can result if these needs are not identified.

Step-3: Tailoring Requirements with NRTM

In the previous step, the first three columns of the NRTM identified and described a unique user need. By doing so, the user had in essence answered the question: "What needs to be done to address a problem in a ConOps?" This was done independent of the question: "How it will be done?"

In Step-3, the last four columns of the same NRTM associated requirements are traced to satisfy that unique need. In the SEP methodology, determination on requirements is critical for system interface design. All system requirements are therefore written in the form of "shall" language.

Users should be advised that the TMDD standard has traced (allocated) 134 requirements to 125 different user needs. This outcome was a result of a collaborative effort by the knowledgeable experts in the field. All requirements were carefully elicited, analyzed, validated, and documented. Most of these requirements are listed as "optional," allowing user to make the selection for a project. A small number of requirements are thus determined by the experts to be essential to satisfy certain user needs and are made "mandatory." To conform to the TMDD standard, mandatory requirements must be included in the specification.

Step-4: Selecting Data Concepts Using RTM

At the high level design stage in the SEP, we are faced with selecting data concepts, dialogs, messages, data frames, and data elements, to complete the system interface specification (analogues to selecting building materials for a construction work). The TMDD standard provides representation of data concepts in both ASN.1 based and XML based formats. At this stage, the user must elect one (if it not already done so) and using the RTM as shown in the box and select appropriate data concepts from Volume-II.

A sample RTM below illustrates the requirements related to display a DMS message remotely. The generic dialog (2.4.1) carries out a request/response message pattern for DMS control with two messages. Users should also note that in a given project certain requirements may also trace to other ITS standards for data concepts as shown in this example (to NTCIP 1203 standard supplied data element will be necessary for Beacon control). If such a capability is needed in an implementation, risk to interoperability could result. In general adding data concepts from other domain standards not already included in the TMDD could break interoperability. Users should take care in such issues and prepare accordingly during implementation process and testing phase.

Selection of TMDD Data Concepts Using RTM: DMS Example

(Extended Text Description: This figure shows the following table below, with arrows from "2.4.1" of the third row of the Dialog column pointing to "message" of the fourth row of the Data Concept Type column and "message" of the seventh row of the Data Concept Type column:

Requirement ID	Requirement Title	Dialogue	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		OrganizationInformation	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

)

Example: Selecting a User Need

Why a user need should be selected: Example - "Need to Share DMS Status Information"

Operational Need: In order to coordinate its own efforts in the region, a center may find it necessary to monitor the status of various traffic devices that are managed by another center to monitor traffic conditions and the state of the network, and to provide traveler information. In such a situation, data that should be accessible for each device include communications status, operational status (e.g., working, not available) and current operational state information, which results in user need shown below.

2.3.6.4.3 Need to Share DMS Status

How User Need should be selected? Through use of NRTM (Volume I, Section 5)

UN ID	User Need	UN Selected	Requirement ID	Requirement	Conformance	Support	Other Requirements
2.3.6.4.3	Need to Share DMS Status	Yes

Once the operational need is identified as the above need suggests, the user should go to the NRTM to identify the User Need ID in the first column, and select Yes in the second column. This User Need appears on page 222 in Volume I of the TMDD standard.

The other four columns (shown in pink) in the NRTM relate to the next steps, which are requirements-related. (Readers please note that the actual NRTM in the standard is not color coded).

Example of Potential User Needs for C2C Context

The following table provides a sample list of potential user needs to support a range of operational contexts. In any of these situations, users are very likely to combine various ITS devices and actions for their C2C information exchanges. For example, a freeway management system may include CCTV, HAR, ramp meters, and planned events. The NRTM will guide users in selecting user needs and ensuing requirements.

C2C Operational Context	UN ID	User Need Title
Need to Manage Assets
Provide inventory sharing for: Traffic network Closed circuit television cameras and switches Dynamic message signs Environmental sensor stations Lane closure gates and swing bridges Highway advisory radio and low power FM stations Lane control signals Ramp meters Traffic detectors Traffic signals Provide information on agencies, centers, systems, and users	2.3.3	Need to Provide Information on Organization, Centers and Contacts
	2.3.5	Need to Provide Network Data
	2.3.5.1	Need for Roadway Network Inventory
	2.3.5.2	Need to share Nodes, Link and Route Status
	2.3.5.3	Need to share Link Data
	2.3.5.4	Need to share Route Data
Need to Manage Information
Events (planned, current, or forecast) and supporting network data Traffic, weather and road conditions Operational status of devices	2.3.4	Need to Share Information
Need to Control Traffic Control Devices
Closed circuit television (CCTV) cameras Video switches Dynamic message signs (DMS) Environmental sensor stations (ESS) Lane closure gates Highway advisory radio (HAR) Lane control signals Ramp meters (RM) Actuated Signal Controllers (ASC)	2.3.6	Need to Provide Control of Devices
	2.3.6.1	Need to Share Detector Data
	2.3.6.2	Need to Share CCTV Camera Status and Control
	2.3.6.3	Need to Share Video switch Status and Control
	2.3.6.4	Need to Share DMS Status and Control
	2.3.6.5	Need to Share Environmental Sensor Data
	2.3.6.6	Need to Share Lane Closure Gate Control
	2.3.6.7	Need to Share HAR Status and Control
	2.3.6.8	Need to Share Lane Control Status
	2.3.6.9	Need to Ramp Meter Status and Control
	2.3.6.10	Need to Share Traffic Signal Control and Status
Need to Archive Data
Traffic monitoring data, traffic flow and conditions, data collection, roadway characteristics, and event data	2.3.7	Need to Share Data for Archiving

References

1. TMDD v3.0 Standard Documentation (Volume I and II) available at:

a. https://www.ite.org/tripgenappendices/

b. To download PDF files of the TMDD v3.0 Standard Volume I and II, click on the shopping cart symbol in the last column at http://www.ite.org/standards/distribution.asp

2. ISO/FDIS 14817:2002(E), Transport information and control systems — Requirements for an ITS/TICS central data registry and ITS/TICS data dictionaries, v2.0,2007. http://www.iso.org/iso/catalogue detail?csnumber=36030

3. IEEE Standard Glossary of Software Engineering Terminology, IEEE 610.12-1990, http://www.idi.ntnu.no/grupper/su/publ/ese/ieee-se-glossary-610.12-1990.pdf

Subject Area Guides

4. Guide to Traffic Management Data Dictionary (TMDD) Standard v3.0 for Traffic Management Center-to-Center Communications, Final Draft (soon to be published), ITE TMDD JC, https://www.ite.org/tripgenappendices/

5. NTCIP Guide, Information Report 9001, http://ntcip.org

Center to Center Field Case Studies (Deployments)

6. AZ Tech C2C Interface Specification and ConOps Plan www.aztech.org/docs/c2c/az-c2c-spec.pdf

7. Developing and Using a Concept of Operations in Traffic Management System-FHWA, 2005, Handbook http://tmcpfs.ops.fhwa.dot.gov/cfprojects/uploaded_files/conops_tms_handbook.pdf

8. Deschutes County ITS Plan; User Needs Assessment, Oregon DOT and DKS Associates, Inc. http://www.oregon.gov/ODOT/HWY/ITS/PDFs/Bend/ExecutiveSummaryFinal.pdf?ga=t

Systems Engineering Guides/Standards Information

9. Systems Engineering for ITS-An Introduction for Transportation Professionals, FHWA: http://ops.fhwa.dot.gov/publications/seitsguide/seguide.pdf

10. Systems Engineering Guidebook, Caltrans and FHWA, February 2005.

11. http://www.dot.ca.gov/newtech/docs/se guidebook ver1-12 14 05.pdf

12. Systems Engineering Handbook, International Council on Systems Engineering (INCOSE), v3.2, 2010. http://www.incose.org

13. USDOT, RITA, ITS-JPO, http://www.its.dot.gov/index.htm (Fact sheets)

14. USDOT, FHWA, Operations, http://ops.fhwa.dot.gov

15. USDOT Standards Program, http://www.standards.its.dot.gov/

16. USDOT, FHWA, Freeway Operations and Management http://ops.fhwa.dot.gov/freewaymgmt/frwy ops.htm

Pre-Arrangement Information Sharing Agreements and MOUs by Centers

17. Memorandum of understanding for traffic incident management team within Florida department of transportation district four www.smartsunguide.com/pdf/MOU.doc

18. STAERNET Stakeholders Cooperation Plan, Sacramento Area Council of Governments https://www.fhwa.dot.gov/cadiv/segb/files/starnet/starnetstake.htm

19. Fontana/Ontario Advanced Traffic Management Information System(ATMIS) Concept of Operations, 2000

tmcpfs.ops.fhwa.dot.gov/.../Ontario%20CA%20concept%20of%20ops.doc Standards Development Organizations (SDOs) Web sites

Information Topic	Web link (ctrl+click to follow link)	Organization
C2C-TMDD	www.ite.org/standards/TMDD/	ITE
C2C -NTCIP	www.ntcip.org/library/documents	NEMA
C2C DATEX-part 2	https://www.iso.org/standard/41362.html	ISO
ITS (NTCIP) Field	www.ntcip.org/library/documents	NEMA Devices
ATC Controller	www.ite.org/standards/atc/	ITE