Module 16 - A321b
A321b: Specifying Requirements for Traffic Management Systems Based on TMDD v3.0 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 “A321b - Specifying Requirements for Traffic Management Systems Based on TMDD v3.0 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.)
A321b - Specifying Requirements for Traffic Management Systems Based on TMDD v3.0 Standard
Table of Contents
Introduction - 2
Example of Areas of Operational Needs Covered by TMDD - 3
System Interface - 5
Source of User Needs, Requirements, and Data Concepts - 6
Preparing System-Interface Specifications - 17
Sample Requirements Traceability Matrix (RTM) - 21
Application-Level Protocols - 22
What if a Requirement is not found in the TMDD Standard? - 25
Extensions - 26
References - 27
This supplement provides additional information on the materials covered in Module A321b Specifying Requirements for Traffic Management Data Dictionary (TMDD) v3.0 Standard. This document aids further in amplifying the discussion issues covered in the course. A321a, the first course on the TMDD v3.0 standard focused on the TMDD user needs. This course focuses on requirements related to the TMDD standard.
(Extended Text Description: Relevant description as provided by author: Figure 1 Role of TMDD in System Interface Specification: The figure is a slide with title: How is TMDD deployed? Three text boxes are shown below it. First box is: Traffic management operational environment, second is TMDD v3.0 sta ndard and last one is System interface specification. Next to these boxes a text reads: All centers must use same specification and two arrows point to two TMCs. One on left is a photo of a TMC with system interface and one on right is External Center a box with a system interface in front. Tow arrows flows from each other to suggest information exchange. )
Figure 1: Role of TMDD in System Interface Specification
The TMDD is an information level standard. This dictionary serves the traffic management area of intelligent transportation systems (ITS). It supplies building blocks or design materials from which a system interface is designed. As shown in Figure 1, the TMDD standard supplies standardized definitions of user needs and their requirements and associated design data concepts from which a system interface is designed. These standardized data concepts are dialogs messages, data frames, and data elements. The standard has complied definitions. Specification writers must only modify their needs for a local project. The TMDD standard enables a system-interface design that meets interoperability needs of a traffic management environment. The system interface, a software product, serves the needs of traffic management in the center to center (C2C) context. The reader is directed to the reference section for C2C case studies relevant to the course discussion topics: user needs, requirements, and specification for C2C system interface . (See final report: http://www.aztech.org/docs/c2c/az-c2c-conops.pdf).
Example of Areas of Operational Needs Covered by TMDD
Centers typically have operational needs in the four key areas to exchange information. These four areas are selected out of eight covered by the standard, as shown in Figure 2, because they describe how interconnected center-to-center (C2C) operational context supports traffic management functions.
(Extended Text Description: Relevant description as provided by author: Figure 2 Key Areas of Operational Needs Covered by TMDD: The figure show a small map of a roadway network around which four text boxes are shown. One on topside reads: Describe Roadway Networks. One on right of the map reads: Data Collection. The bottom one reads: Device Control and the one on left of the map reads; Event Sharing. )
Figure 2: Key Areas of Operational Needs Covered by TMDD
(Other four areas related to network administration)
The above discussion can also be summarized in a C2C context in the following manner:
The IEEE Std. 610, Glossary of Software Engineering Terminology defines a system interface as “a shared boundary across which information is passed.”
As shown in Figure 3 by the RED vertical bar, a system interface creates a boundary with a local system at the TMC. This boundary allows information across, with the local traffic management system, and to the outside world, which could be a TMC or emergency management.
(Extended Text Description: Relevant description as provided by author: Figure 3 System Interface: same as Figure 1, except only pictures of TMCs are shown. )
Figure 3: System Interface
To achieve the above objective, users have to first write a specification to procure and develop a system interface. A system interface is NOT a commercial off-the-shelf (COTS) software product. It is a customized software entity; not one size fits all.
This is illustrated in Figure 4 in terms of how messages are sent and responses are received through a system interface. These messages are created using TMDD-supplied standardized data concepts definitions. Recognizing that project needs are different both in scale and user needs from place to place, system interfaces must be developed to meet local needs. As a result of a variance in local needs, the development of the system interface (complexities) varies from place to place.
(Extended Text Description: Relevant description as provided by author: Figure 4 Messages thru an 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.)
Figure 4: Messages thru an Interface
For example, a small city TMC may just have an operational need for only a traffic controller’s related function exchanges with a neighboring jurisdiction to coordinate signal timing strategy at boundaries, and messages will be limited to such tasks only, while a statewide TMC may need to perform a range of ATMS functions that will require support for a large number of messages.
As shown in Figure 5, 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 as provided by author: Figure 5 TMDD Standard Organization: Standardized Definitions: There are three boxes in this slide. Boxes reads inventory of definitions supplied by the TMDD v3 standard: "124 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 with a 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.")
Figure 5: TMDD Standard Organization
The user should view this diagram with the NRTM and RTM in mind as tools to prepare a project specification and “building materials” available in order to design system interfaces with. Notice the large inventory of definitions compiled by the standard available for any situation a user wishes to address. (This conceptual representation is indicative of a “shopping cart” analogy; take what you need.)
As shown in Figure 5, NRTM is the only way to select standard-supplied user needs and tailoring requirements that satisfy the selected user needs. (A requirement is a condition or capability, “solidly” expressed in “shall” language. Requirements link us to the next step—design content.) Similarly, only RTM necessary specific-design concepts (solutions) that fulfill the requirements are selected. As shown in the figure, there are no direct links between user needs and requirements. Thus, the TMDD standard has ensured traceability in both forward and backward direction of the development process, in addition to providing for standardized definitions of user needs, requirements, and design concepts.
Data is a representation of facts, concepts, or instructions in a formalized manner suitable for communication, interpretation, or processing by human or by automatic means. TMDD data concepts support the four areas discussed earlier.
As shown in Figure 6, TMDD data concepts include dialogs to start a conversation, messages to request something and receive responses (pertaining to a function or event information or data), and data frames and data elements are used to construct messages.
TMDD has also introduced some flexibility of representing data concepts in two standards-based formats: ASN.1 and XML. The user needs to choose only one format; they cannot be mixed. Also, to achieve interoperability, centers must choose the same format-based data concepts in their system interface specification and design.
A dialog describes a sequence of message exchanges between two entities such as shown in Figure 6 as an external center (EC) talking to an owning center (a TMC) (just as in a conversation between two people).
For example, a request-response dialog would include two messages being shared between an EC and a TMC to accomplish information sharing.
The first message would include the request for information, followed by a message containing the information (response).
(Extended Text Description: Relevant description as provided by author: Figure 6 A Representation of the TMDD Data Concepts: A graphic is shown with two circles marked as EC on left and OC on right. Tow arrows flow from each other and is marked as dialog. A slanted arrow then flows from dialog to a box below marked Messages. An arrow flows from messages to another box below marked Data Frames and an arrow from data frames to Data element is shown. )
Figure 6: A Representation of the TMDD Data Concepts
Some dialogs are simple and include one or two exchanges, while complex dialogs would include a larger number of steps and alterations of sequence steps based on some criteria (for example, special error handling). Simple dialogs can handle a wide variety of situations or a project may define complex dialogs to meet its special project requirements.
Generic dialogs (Figures 7, 8, and 9) and interface dialogs can be described using the Unified Modeling Language (UML) sequence diagrams as shown below. The examples in this section illustrate how the UML-based diagrams can help in displaying operations and message inputs/outputs. However, users can devise their own project-specific implementation sequence diagrams using UML.
Message patterns are the building blocks of dialogs. The TMDD standard v3.0 has provided for two basic message patterns:
The TMDD v3.0 standard has listed three generic dialogs for referencing by the RTM to the 124 customized device classes and other classes dialogs in the RTM; most of these dialogs are designed to facilitate request/response patterns to support operational needs.
Types of Generic Dialogs
How are Dialogs Referenced in the RTM?
As shown in the referencing table, one of the three generic dialogs is referenced in the project RTM (third column) by the project-selected dialogs (last column in RTM as a standard clause and listed in Section 3 of Volume II). As shown in the table below, an external center had a need to verify CCTV control status, which determined the requirement identified in the second column, which in turn referenced the generic dialog 2.4.1 to carry out the interface dialog 188.8.131.52 listed in Volume II.
TMDD Generic Request-Response Dialog 2.4.1
The request-response dialog supports the sending of an information or control message initiated by an external center followed by a response by the owner center upon request. Upon error, the owner center returns an error message.
(Extended Text Description: Relevant description as provided by author: Figure 7 Sequence Diagram of Request/Response Generic Message: 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.)
Figure 7: Sequence Diagram of Request/Response Generic Message
TMDD Generic Subscription Dialog 2.4.2
The subscription dialog, initiated by an EC and accepted by an OC, is mandatory for generation of information updates from an OC to an EC. Upon subscription for information updates by an EC, the OC shall provide a confirmation receipt.
Upon error, the OC shall return an error message.
(Extended Text Description: Relevant description as provided by author: Figure 8 Sequence Diagram of Subscription Generic Message: Generic Request-Response Dialog 2.4.2: Same as above Figure 7, except it explains subscription generic dialog.)
Figure 8: Sequence Diagram of Subscription Generic
TMDD Generic Publication Dialog 2.4.3
Upon acceptance of a subscription dialog, an OC shall provide information updates to an EC. Upon error, the EC shall return an error message.
(Extended Text Description: Relevant description as provided by author: Figure 9 Sequence Diagram of Publication Generic Message: Same as above Figure 8, except it explains publication generic dialog.)
9: Sequence Diagram
of Publication Generic Message
An Example of How TMDD v3.0 standard Supplied Data Definitions are Used
(Box 1, 2, and 3 Determines “What” We Need Part-Volume I)
BOX 1: A user (operational need) determines
that there is need to share DMS Status and Control to support agency’s traffic
(Extended Text Description: Relevant description as provided by author: BOX 1: An Example of How TMDD v3 standard Supplied Data Definitions are Used (Box 1, 2 and 3 Determines “What” we Need Part-Volume I). The box starts with a title page of TMDD standard volume I followed by a Table of content image with page number followed by 184.108.40.206 Need to Share DMS Status and Control. A curvy arrow points from page 21 to 220.127.116.11. The box thus demonstrates how to find a user need. )
BOX 2: UN 18.104.22.168 has outlined several User Needs to meet operational needs, pick those that your project needs: As an example, we picked 22.214.171.124.4 after reading definition and mapping to the project on hand.
(Extended Text Description: Relevant description as provided by author for BOX 2 and BOX3: BOX 2: UN 126.96.36.199 has outlined several User Needs to meet operational needs, pick those that your project needs: As an example, we picked 188.8.131.52.4 after reading definition and mapping to the project on hand. Text details on 184.108.40.206 are provided as an example, the specific text is not essential to understand, except for the following comments: After fixing 220.127.116.11.4, a five digit unique UN ID number, both Navigation and Tracing is possible in all TMDD documentation and NRTM and RTM. (Something like using a PRL and RTM concepts in NTCIP device standards). Recall from A202 module, UN ID is unique. UN expresses major capability. YES. The UN ID, UN and YES point to the example in BOX 3 collumns UN ID, User Need and UN Selected, respectively.
BOX 3: User Needs are ‘Housed’ in NRTM by UN ID Number in the First Column and are associated to Requirements by 4th Column: this is “hardwired”-fixed. Major Capability: Need to Display a Message on a Remote DMS. NRTM image of page where 18.104.22.168.4 is entered is taken from the standard with details. Arrows from parts of NRTM points to NRTM image to stress parts. An arrow from bottom points to Yes/NO support column from a text box. BOX 3: User Needs are ‘Housed’ in NRTM by UN ID Number in the First Column and are associated to Requirements by 4th Column: this is hardwired-fixed. The example is captioned with the following text: Major Capability: Need to Display a Message on a Remote DMS. Under the example, a text box points to the Conformance column with the following text: "User will select those optional requirements considered needed by selecting YES for conformance, in addition to all Mandatory one stated above. For example, if a center does not want to know which operator at the other center is making this request, operator identifier above is not selected.)" The text "operator identifier" has an arrow pointing to the Support column of the example. An additional text box has the following text: "NOTE: This window view is taken from the TMDD NRTM on page 224. When you, the user, prepare a project NRTM, the list above will shrink to just a few requirements allocated to this user need. In above view, there 20 requirements, 8 are Mandatory, you are left with 12-you may not need all 12.")
(Extended Text Description: Relevant description as provided by author: BOX 4: Entering Volume II to Use Design Solutions to Meet Requirements. Image of title page of Volume II is provided at top and listing of Design solutions 3.1.6 and 3.2.6 Dialog is shown. )
Volume II Design content should lead us to these Dialogs and Messages used in Information Exchanges.
Additional data concepts linked to these messages are also provided but we will not discuss them in detail.
3.1.6 DMS Class Dialogs - 57
3.2.6 DMS Class Messages - 156
BOX 5: "USING" the Dialog 22.214.171.124 on page 57, Volume II, to Meet Project
Requirements Selected in Box 3 (We have selected XML representation of DCs, but ASN.1 is also available)
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.
126.96.36.199.1.2 DIAL OG REFERENCE
See Clause 2.4.1 Generic Request-Response Dialog
188.8.131.52.4 XML REPRESENTA TION
BOX 6: "USING" the Message 184.108.40.206 on page 156, Volume II, to Meet Project Requirements Selected in Box 3
The information content necessary to request a control action of an owner center's dynamic message sign.
220.127.116.11.3 XML REPRESENTATION
<xs: element name= "dMSControlRequestMsg" type=" DMS Control Request" />
BOX 7: Project RTM (Partially filled): we will repeat this until all requirements are included in the project RTM with linked data concepts
Generic dialog 2.4.1 indicates that the dialog is conducted with Request/Response Pattern
(Additional note for this table: The item "2.4.1" in the Dialog column has an arrow pointing to the text above the table, which reads: "Generic dialog 2.4.1 indicates that the dialog is conducted with Request/Response Pattern")
Preparing System-Interface Specifications
This section expands on the course discussion on how to prepare project specifications using the TMDD standard. The section 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).
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 the type of system being procured) and perhaps agency to agency, in general from the user-needs standpoint, the following components should be considered and included in a specification document:
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 in Figure 10 outlines four key steps for preparing the TMDD-based system interface specification. These steps are occurring in the SEP life cycle. Each step is explained in detail.
Applicable TMDD standard sections are identified in each step and mapped to the stages. 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.
Step 1: Regional ITS Architecture (See Figure 10)
Readers may recall that the market packages developed by the ITS architecture collect several different subsystems (including equipment packages and 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 a selected number of relevant market packages to C2C needs.
As a first step toward 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 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 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, and so forth 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 concept of operations (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 dictating how system requirements will emerge in the next phase, during which a system-interfaces design will be done. Only clearly stated user needs using NRTM will ensure that; if users miss them, the result can be an “imperfect” system interface.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 independently of the notion 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” statements.
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 knowledgeable experts in the field. All requirements were carefully elicited, analyzed, validated, and documented. Most of these requirements are listed as “optional,” allowing users to make the selection for a project. A small number of requirements are 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 (this is analogous to selecting building materials for 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 he or she has not already done so), and using the RTM as shown in the box, select appropriate data concepts from Volume II.
The sample RTM below illustrates the requirements needed 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. If such a capability is needed in an implementation, a risk to interoperability could result. In general, adding data concepts from other domain standards not already included in the TMDD could compromise interoperability. Users should take care in such scenarios and prepare accordingly during the implementation process and testing phase.
Mapping the TMDD Standard
The following four steps will guide the user in mapping project-level user needs for specification preparation:
(Extended Text Description: Relevant description as provided by author: Figure 10 Life Cycle Process: 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. There are four steps shown in the figure. Step 1 has an arrow pointing to regional Architecture stage shown on the Vee diagram. Step 2 has an arrow going to Concept of operation stage. Similarly from the bottom of the Vee diagram, Step 3 has arrow going to Requirements stage on Vee and Step 4 to High level design stage. Thus four steps are linked to SEP life cycle process. Each step has a text description in it. )
Figure 10: Life Cycle Process
Sample Requirements Traceability Matrix (RTM)
The power of the RTM is apparent from the above discussion. Thus, using the project RTM, there are three benefits: a specification writer can specify which system interface design content is to be implemented in a project specification (not leaving it to guesswork); the system implementer can use the RTM as a vigorous checklist to reduce the risk of failure to conform to the project specification; and, in some cases, a user may benefit from checking with other jurisdictions on potential interoperability issues during separate implementations.
(Exhibit illustrates how requirements (in Volume I) are traced to data concepts (in Volume II) through RTM)
Notes: The Dialog column indicates the name of the dialog and represents the highest- level information element defined in Section 2 of Volume II. There are three generic dialogs developed by TMDD (see Volume I, Sections 2.4.1, 2.4.2, and 2.4.3).The Standards Clause Column references a clause in either Volume II Section 3 or an external standard containing the definition of the data concept (e.g. command and control of a NTCIP field device such as a DMS will be referenced to the NTCIP standard).
TMDD is a high level information source, 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 7, as an information-level data dictionary standard, the TMDD standard defines the content, syntax, and semantics of message exchanges between center-based systems, but it does not define the mechanism of encoding and transporting a message between centers.
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:
As shown in Figure 11, for the traffic management system interface implementation the following standards are required:
(Extended Text Description: Relevant description as provided by author: Figure 11 TMDD Implementation: 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 11: TMDD Implementation
(Please refer to TMDD v3.0 Guide for details on each setup)
The specification writers desiring to procure a TMDD-based C2C system interface must prepare a project-specific specification using one of the following two types of implementations (note that they cannot be mixed):C2C XML-based Implementation Requirements
DATEX-based Implementation Requirements
The specification writers and the system developers should be aware that at the application level, AP-DATEX and AP-C2C XML are not interoperable (they cannot be mixed). The C2C-DATEX is a fixed connection-based approach to information exchange. The C2C XML is a Web services-based (Internet-based) approach to information exchange. Both are distinct in design constructs and therefore only one application-level standard should be chosen. Two or more centers desiring interoperability (an ability to “talk” to each other in real time) must implement a common system interface specification to achieve this objective.
The TMDD v3.0 Guide discusses dialogs, followed by data concepts in ASN.1 representation and data concepts in XML representation and briefly reviews the two application-level protocols used in the TMDD-based C2C system interface implementation.
TMDD states the following conformance requirements (Ref. Volume I, Section 1.6, page 6):
The TMDD defines data concepts. The following defines TMDD conformance:
NOTE: The user of this standard is advised that “conformance” to this standard should not be confused with “compliance” to a specification. This standard is as broad as possible to allow a very simple implementation to be “conformant” to this standard. A specification will need to identify the requirements of a particular project and needs to require the support of those requirements. A specification writer is advised to match the requirements of a project with the corresponding standardized requirements defined in this standard to achieve interoperability. This means that functions and requirements defined as “optional” in this standard might need to be selected in a specification (in effect, made “mandatory”).
Off-the-shelf interoperability and interchangeability can only be obtained through well-documented features broadly supported by the industry as a whole. Designing a system that uses features not defined in a standard or not typically deployed in combination with one another will inhibit the goals of interoperability and interchangeability, especially if the documentation of these features is not available for distribution to system integrators.
What if a Requirement is not Found in the TMDD Standard?
Example of a Potential Situation
A hypothetical situation 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?”
In general, “extensions” to a TMDD-conformant implementation are discouraged because they break interoperability (the reason 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 your system manager for the project for issues related to interoperability as well.
Extensions (Ref. Volume II, Section 1.6.1)
“The TMDD allows for specific project implementations to “extend” or add new data concepts to the implementation. It is recognized that the standard does not define standardized data concepts for every possible user need that can exist between two centers. Thus, there could be special features or requirements in the implementation that are not supported by the standard. If such features are present, then the systems developer or integrator would need to determine precisely how these features are to be supported without conflicting with the standardized implementations.
“Extensions” to a TMDD-compliant implementation are discouraged because they break interoperability. However, the standards organizations recognize the need to satisfy functional requirements not supported by this standard. To support these additional requirements, project implementations are allowed to “extend” the standard by defining new data elements, data frames, or data messages outside this TMDD standard.
To maintain conformance to this standard, the following rules for “extending” the TMDD standard must be met:
Subject Area Guides
Center to Center Case Studies (Deployments)
Systems Engineering Guides/Standards Information