An Information Report by the TMDD Steering Committee of ITE and AASHTO
Guide to
Traffic Management Data Dictionary
(TMDD) Standard v3.0 for
Traffic Management Center-to-Center
Communications
Published July 11, 2011
Published by
Institute of Transportation Engineers (ITE)
1627 Eye Street, NW, Suite 600
Washington, DC 20006
American Association of State Highway and Transportation Officials (AASHTO)
444 North Capitol Street, NW, Suite 249
Washington, DC 20001
© Copyright 2011AASHTO/ITE All rights reserved.
TMDD standard v03 Guide
July 11, 2011
Disclaimer
The Traffic Management Data Dictionary (TMDD) was revised in 2008 by the TMDD
steering committee and formally adopted by AASHTO and ITE, and published on
November 12, 2008.
The Steering Committee has provided a process for requesting updates and revisions to
the current standard. Thus, when implementing systems, users of this standard need to
be aware that changes may have occurred since publication of the standards they are
using. Likewise, users who find problems with the TMDD standard are encouraged to
bring their issue(s) to the immediate attention of the TMDD steering committee for
resolution, clarification, and possible modification to the standard. When noting issues,
users are asked to highlight the specific section/pages in question, describe the issue,
and recommend a solution.
The TMDD steering committee anticipates that there will likely be some changes to the
current standards, especially during the first few years after approval. Readers are
encouraged
to
visit
the
ITE
Web
site
pertaining
to
TMDD
at
http://www.ite.org/standards/TMDD/ for documentation.
Copyrights
© Copyright 2011 by the Institute of Transportation Engineers (ITE) and the American
Association of State Highway and Transportation Officials (AASHTO). All intellectual
property rights are reserved, except as described as follows, by the copyright owners
under the laws of the United States of America, the Universal Copyright Convention, the
Berne Convention and the International and Pan American Copyright Conventions.
Permission to freely reproduce, distribute and/or translate into other languages is granted provided that (1) this copyright notice appears on the front of the document, (2) “©
2006 ITE and AASHTO” appears on every page of the text, and (3) the text is not edited
or used out of context.
TMDD is the trademark of ITE and AASHTO.
ii
TMDD standard v03 Guide
July 11, 2011
Acknowledgments
The efforts to develop this guide are being led by the TMDD steering committee. At the
time of preparing this guide, the steering committee members who guided the development of this updated guide include the following:
TMDD Steering Committee Membership (July 2011)
AASHTO-American Association of State Highway and Transportation Officials
ITE-Institute of Transportation Engineers
Organization
Representing
Name
Morgan Balogh
Dr. Steven W. Dellenback
Richard Dye
Washington State Department of Transportation
Southwest Research Institute
AASHTO
ITE
Dave Gardner
Dr. Joel Markowitz
Curt Pape
Dr. Raman K. Patel
Sanjay Patel
Robert Rausch, Chair
Dr. Edward J. Seymour
Stan Slavin
Maryland Department of Transportation
Colorado Department of Transportation
Metropolitan Transportation Commission
No organizational affiliation
RK Patel Associates, Inc.
TRANSCOM
TransCore
Texas Transportation Institute (TTI)
California Department of Transportation
(Caltrans)
AASHTO
AASHTO
ITE
AASHTO
ITE
ITE
ITE
ITE
AASHTO
John Whited
Iowa Department of Transportation
AASHTO
In addition to the many volunteer efforts, recognition is also given to those organizations
that supported the TMDD effort by providing guidance, comments, supporting staff participation, and/or funding for the effort:
•
•
•
•
•
•
•
•
California Department of Transportation
(Caltrans)
Federal Highway Administration (FHWA)
Georgia Department of Transportation
Indiana Department of Transportation
Metropolitan Transit Authority of Harris
County (Houston Metro)
Metropolitan Transportation Commission
(San Francisco Bay Area)
Minnesota Department of Transportation
•
•
•
•
•
•
●
New York State Department of Transportation
Telvent (Formerly PB Farradyne, Parsons
Brinckerhoff)
Southwest Research Institute
Texas Department of Transportation
Texas Transportation Institute (TTI)
TransCore
Virginia Transportation Research Council
Washington State Department of Transportation
Acknowledgment is also given to several individuals who provided particular assistance
in reviewing and/or providing material for inclusion in this effort: Patrick Chan, Dr. Steve
Dellenback, Jeff Brummond, Stan Slavin, John Whited, Blake Christie, Manny Insignares, Siva Narla, Patrick Powell, Robert Rausch, Dr. Edward Seymour, and Warren
Tighe. This updated guide introduces the TMDD Standard for Traffic Management Center-to-Center Communications v3.0 and was prepared under a contract with Dr. Raman
K. Patel (RK Patel Associates, Inc.) with guidance from the steering committee.
iii
TMDD standard v03 Guide
July 11, 2011
CONTENT
CHAPTER 1 INTRODUCTION
1
1.1 PURPOSE OF THE GUIDE
1.2 TARGET AUDIENCE FOR THIS GUIDE
1.3 THE PURPOSE OF THE TMDD STANDARD
1.4 THE SCOPE OF THE TMDD STANDARD
1.5 DATA CONCEPTS DEFINITIONS
1.6 SYSTEM INTERFACE SUPPORTS TRAFFIC MANAGEMENT
1.7 TMDD STANDARD V3.0 DEVELOPMENT
1.8 BACKWARD COMPATIBILITY
1.9 TMDD AND INTEROPERABILITY
1.10 GUIDE ORGANIZATION
1.11 KEY QUESTIONS WITH INFORMATION REFERENCES
CHAPTER 2 TMDD STANDARD STRUCTURE
2.1 CHAPTER PURPOSE
2.2 STANDARD ORGANIZATION
2.3 TMDD V3.0 STANDARD SECTIONS
2.4 USER NEEDS
2.5 REQUIREMENTS
2.6 NEEDS TO REQUIREMENTS TRACEABILITY MATRIX (NRTM)
2.7 REQUIREMENTS TRACEABILITY MATRIX (RTM)
2.8 CONDITIONS FOR CONFORMANCE TO THE TMDD STANDARD
2.9 WHAT IF A NEED IS NOT FOUND IN THE TMDD STANDARD?
2.10 CHAPTER SUMMARY
1
1
1
2
4
5
7
8
9
9
10
11
11
11
12
13
14
15
16
18
18
20
CHAPTER 3 WRITING SYSTEM INTERFACE SPECIFICATION USING
TMDD
21
3.1 CHAPTER PURPOSE
3.2 METHODOLOGY FOR WRITING SYSTEM INTERFACE SPECIFICATION
3.3 MAPPING TMDD STANDARD TO V MODEL STEPS
3.4 CHAPTER SUMMARY
CHAPTER 4 TMDD IMPLEMENTATION
4.1 CHAPTER PURPOSE
4.2 TMDD IMPLEMENTATION
4.3 UNDERSTANDING DIALOGS
4.4 UNDERSTANDING ASN.1 DATA CONCEPTS
4.5 UNDERSTANDING C2C XML DATA CONCEPTS
4.6 APPLICATION LEVEL PROTOCOLS
4.7 CHAPTER SUMMARY
iii
21
21
22
29
30
30
30
31
36
39
44
45
TMDD standard v03 Guide
July 11, 2011
REFERENCES
46
INFORMATION SOURCES FOR CENTER-TO-CENTER COMMUNICATION
50
FUNCTIONAL AREA STANDARDS
51
WEB LINKS TO ITS STANDARDS INFORMATION
52
APPENDIX-A APPLICATION PROFILES FOR CENTER-TO-CENTER
58
APPENDIX-B BASICS OF CENTER -TO-CENTER-COMMUNICATIONS
62 iv
TMDD standard v03 Guide
July 11, 2011
LIST OF EXHIBITS
Exhibit 1-1:
Exhibit 1-2:
Exhibit 1-3:
Exhibit 1-4:
Exhibit 1-5:
Exhibit 1-6:
Exhibit 2-1:
Exhibit 2-2:
Exhibit 2-3:
Exhibit 2-4:
Exhibit 2-5:
Exhibit 2-6:
Exhibit 2-7:
Exhibit 2-8:
Exhibit 2-9:
Exhibit 2-10:
Exhibit 2-11:
Exhibit 3-1:
Exhibit 3-2:
Exhibit 3-3:
Exhibit 3-4:
Exhibit 3-5:
Exhibit 3-6:
Exhibit 4-1:
Exhibit 4-2:
Exhibit 4-3:
Exhibit 4-4:
Exhibit 4-5:
Exhibit 4-6:
Exhibit 4-7:
Exhibit 4-8:
Exhibit 4-9:
Exhibit 4-10:
Exhibit 4-11:
Exhibit 4-12:
Exhibit 4-13:
Exhibit A-1
Exhibit A-2
Exhibit A-3:
Exhibit A-4:
Exhibit A-5:
Exhibit B-1:
Exhibit B-2:
Exhibit B-3:
Exhibit B-4:
Exhibit B-5:
Exhibit B-6:
Exhibit B-7:
Exhibit B-8:
Types Operational Centers Defined by the National ITS Architecture…………………...2
System Interface Concept………………………………………………………………....3
Data Concepts…………………………………………………………………………......4
Potential Applications of the TMDD………………………………………………….......5
Conceptual Representation of Operational Environment………………………………….6
Key Questions with Information References…………………………………………….10
TMDD Standard Organization…………………………………………………………...11
TMDD Standard Sections………………………………………………………………..12
User Needs Identified by the TMDD……………………………………………………12
Role of NRTM…………………………………………………………………………...13
Requirements Determined by the TMDD………………………………………………..14
Illustration of an Operational Need………………………………………………………15
Sample Needs to Requirements Traceability Matrix (NRTM)…………………………..15
Role of RTM……………………………………………………………………………..16
Sample Requirements Traceability Matrix (RTM) ……………………………………...17
Conditions for Conformance to the TMDD Standard……………………………………18
Rules for Extending the TMDD Standard ……………………………………………….19
Mapping of TMDD Standard Sections to the SEP "V" Model…………………………..22
Selecting a User Need……………………………………………………………………24
Sample List of Potential User Needs for C2C Context…………………………………..25
Requirements to Display a Message on a Remote DMS………………………………...27
Selecting Data Concepts Using RTM……………………………………………………28
Selection of Data Concepts Using RTM: DMS Example………………………………..28
Referencing a Generic Dialog in RTM…………………………………………………..32
Generic Request-Response Dialog……………………………………………………….33
Generic Subscription Dialog……………………………………………………………..34
Generic Publication Update Dialog………………………………………………………35
ISO 14817 Data Concepts Framework…………………………………………………...36
Example of ASN.1 Representation of a TMDD Dialog Construct………………………37
Examples of a ASN.1 Message, Data Frame and Data Element Constructs…………….38
Example of Encoding using XML Schema………………………………………………40
SOAP Request-Response Messages……………………………………………………...41
Example of a XML Dialog……………………………………………………………….41
Example of a XML Message……………………………………………………………..42
Example of a XML Data-Frame………………………………………………………….42
Example of a XML Data Element………………………………………………………..43
TMDD Implementation…………………………………………………………………..50
Center-to-Center Communications Approach Comparisons……………………………..51
SOAP Framework………………………………………………………………………..57
Protocols Stack…………………………………………………………………………..57
XML Messaging Using SOAP..........................................................................................58
Communications Categories in ITS Applications………………………………………..61
C2C Functions……………………………………………………………………………62
NTCIP Framework……………………………………………………………………….64
NTCIP C2C………………………………………………………………………………64
Summary of TMDD Application Profile Specific Content………………………………65
Naming Conventions Used by C2C……………………………………………………...66
Communications Categories in Multiple Domain Applications…………………………67
National ITS Architecture (v6.1) Relationship to Standards…………………………….68
v
TMDD standard v03 Guide
July 11, 2011
LIST OF ACRONYMES
AASHTO
American Association of State Highway and Transportation Officials
ADUS
Archived Data User Service
AP
Application Profile
API
Applications Program Interface
APTA
American Public Transportation Association
ASC
Actuated Signal Controller
ASN.1
Abstract Syntax Notation One
ASTM
American Society of Testing and Materials
ATIS
Advanced Traveler Information System
ATMS
Advanced Traffic Management System
BER
Basic Encoding Rules
C2C
Center-to-Center
C2F
Center-to-Field
CARS
Conditional Acquisition Reporting System
CCTV
Closed Circuit Television
CORBA
Common Object Request Broker Architecture
DATEX
Data Exchange
DMS
DSRC
Dynamic Message Sign
Dedicated Short Range Communications
EC
External Center
ESS
Environmental Sensor Station
FADD
Functional Area Data Dictionary
FHWA
Federal Highway Administration
FTP
File Transfer Protocol
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
HTTPS
Secure Hypertext Transfer Protocol
IEN
Information Exchange Network
IM
Incident Management or Traffic Incident Management (TIM)
IP
Internet Protocol
IEEE
Institute of Electrical and Electronic Engineers
IITS
International Traveler Information System
vi
TMDD standard v03 Guide
July 11, 2011
ISO
International Organization for Standardization
ITE
Institute of Transportation Engineers
ITS
Intelligent Transportation Systems
LRMS
Location Referencing Messages Specification
NEMA
National Equipment Manufacturers Association
NRTM
Needs to Requirements Traceability Matrix
NTCIP
National Transportation Communication for ITS Protocol
OID
Object Identifier
OER
Octet Encoding Rules
PRL
Profile Requirements List
RIITS
Regional Integration of Intelligent Transportation Systems
RTM
Requirements Traceability Matrix
SAE
Society of Automotive Engineers
SDOs
Standards Development Organizations
SI
System Interface
SOAP
Simple Object Access Protocol
TCP/IP
Transmission Control Protocol and the Internet Protocol
TRANSCOM Transportation Operations Coordinating Committee
TICS
Transport Information and Control Systems
TIM
Traffic Incident Management
TMC
Traffic Management Center
TMDD
Transportation Management Data Dictionary
UDDI
Universal Description, Discovery and Integration
UML
Unified Modeling Language
UN ID
User Need Identification (Number)
URI
Universal Resource Identifier
URL
Uniform Resource Locator
WAVE
Wireless Access in Vehicular Environments
W3C
World Wide Web Consortium
WSDL
Web Services Description Language
XML
eXtensible Markup Language
vii
TMDD standard v03 Guide
July 11, 2011
CHAPTER 1
INTRODUCTION
1.1 Purpose of the Guide
The purpose of this guide is to summarize the contents of the Traffic Management Data Dictionary Standard for Traffic Management Center-to-Center Communications standard v3.0 and explain in a simplified way how to use it for new and existing systems.
After reading the guide, potential users should understand the Center-to-Center Communications
(C2C) operational context, what is in the TMDD standard documentation, and how to specify the
design content based on user needs and requirements for the C2C system interface (SI).
1.2 Target Audience for this Guide
This information guide is prepared as a “TMDD Primer” with the following types of audience in
mind:
•
•
•
•
Public agency personnel who are new to the TMDD standard, may have not been exposed to or be experienced with the TMDD, and desire to learn how to apply C2C
standards;
Regional system designers/stakeholders attempting to develop plans for a regional
traffic management program;
Systems developers and consultants who may be aware of the previous TMDD standards but wish to update their knowledgebase on current TMDD v3.0; and
Transportation professionals and system developers who are engaged in the Advanced Traffic Management System (ATMS).
After reading the guide, potential users should understand the C2C operational context, what is in
the TMDD standard documentation, and how to use the material to prepare a specification for the
system interface (SI) using the Systems Engineering Process (SEP). This guide makes no attempt
to advise readers on how to develop and implement a system interface including application level
protocols, and it is not meant to be an instructional document. Those issues are left to the
individual implementation.
1.3 The Purpose of the TMDD Standard
The 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
1
TMDD standard v03 Guide
July 11, 2011
exchanges among centers. Consistent with the systems engineering approach, the TMDD
standard aims at providing standards-based, 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).
1.4 The Scope of the TMDD 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).
The TMDD standard supports the National ITS Architecture system perspective of subsystems as
shown in Exhibit 1-1, 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.
Traffic
Management
Emergency
Management
Toll
Administration
Commercial
Vehicle
Administration
Maintenance &
Construction
Management
Information
Service
Provider
Emissions
Management
Transit
Management
Fleet and
Freight
Management
Archive Data
Management
Exhibit 1-1: Types Operational Centers Defined by the National ITS Architecture
(Source: National ITS Architecture v6.1, ITS Architecture 2008)
2
TMDD standard v03 Guide
July 11, 2011
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.
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 dictionary standard, 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.
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).
1.5 What is a Center-to-Center System Interface?
The IEEE Standard Glossary of Software Engineering Terminology (IEEE 610 Standard, Ref.4)
defines an interface as a shared boundary across which information is passed. As shown in
Exhibit 1-2, a shared boundary integrated with the local system applications is termed as a
system interface. Typically an SI can be integrated with the Application Programming Interface
(API) of the Advanced Traffic Management System (ATMS), allowing communication to and
from the TMC or an application.
External Center (EC)
“Inventory Request”
“Inventory Response”
System Interface
System Interface
Applications
Database
User Interface
Owner Center (TMC)
C2C Communications
Exhibit 1-2: System Interface Concept
3
Applications
Database
User Interface
TMDD standard v03 Guide
July 11, 2011
As shown in Exhibit 1-2, a system interface is a separate entity from the applications, database,
servers, user interface, and operating software/hardware platform. A system interface is coded
software that is concerned with the local system’s functions. It requests/receives information
though a sequence of messages exchanges (dialogs) or it simply publishes information.
For the above concept to materialize, both centers must first prepare project specification using
the TMDD standard v3.0 to develop the system interfaces. For example, as shown in Exhibit 1-2,
an operator at an External Center (EC) may initiate a dialog with an “Inventory Request”
message to a neighboring TMC (owner center), which presumably has that information in the
TMC’s traffic management system (both centers are aware what that message means to each
other since they both use the TMDD v3.0 standard). The system interface at the TMC will
receive the “Inventory Request” message, and through the local traffic management system, it
will obtain the inventory (information). The inventory information is sent as an “Inventory
Response” message to the EC, thus completing the sequence of information exchange (called a
dialog). Information thus received from the owner center is used by the requesting center to
make decisions to improve their own local operation, fulfilling C2C communications needs.
Summary Point: A system interface is a separate system entity from the local applications and
application databases, and it is created using TMDD-based project specification. Therefore, the term
“system interface” standardizes only the sequence of information exchanges (dialogs) between centers.
The TMDD itself is not a system interface, but as a dictionary standard it supports the creation of a
system interface for C2C communications.
The next section briefly introduces the data concepts definitions used in the TMDD standard.
1.6 Data Concept Definitions
The ISO 14817 standard defines the term data concept as any of a group of data dictionary structures defined in this International Standard (i.e., object class, property, value domain, data element concept, data element, data frame, message, interface dialogue, association) referring to
abstractions or things in the natural world that can be identified with explicit boundaries and
meaning, and whose properties and behavior all follow the same rules (Ref 2).
The TMDD v3.0 standard has provided a large number of concept definitions under the Design Content, which is organized by design construct and
then by relevant information type as follows:
• Dialogs are logical (temporal) sequences of messages put together to
conduct a “conversation” between centers. They aid in completing a
C2C transaction.
• Messages are groupings of data elements designed to convey information in an unambiguous manner (e.g. several data elements are
grouped to form an event message to support specific request for in-
Data Concepts
Dialogs
Messages
Data Frames
Data Elements
Exhibit 1-3:
Data Concepts
4
TMDD standard v03 Guide
July 11, 2011
formation and sharing of resources supplied by the centers. Messages are analogues to “sentences” used in the English language.
• Data frames are a structured grouping of data elements primarily for the purpose of referring to a group with a single name. Data elements are used to convey (represent) the information as per the specific requirements. A data element is a formal definition and representation of a single unit of information (e.g. a fact) with a unique value at any point in
time about something of interest (e.g. a person, event, or place. They are analogous to
“words” as defined in the English language dictionary).
The reader should also note, as shown in Exhibit 1-3: Data Concepts in Section 1.6, data concepts maintain a hierarchical relationship to each other to carry out a dialogue between two centers.
1.7 System Interface Supports Traffic Management
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. Potential areas where coordination is
required and where use of the TMDD standard may
help are listed in Exhibit 1-4. Local agencies can
add their own ConOps needs to this list during the
user needs assessment process.
Potential Applications of the TMDD
¾ Coordinating traffic signals across jurisdictional boundaries, e.g. countywide arterial.
¾ Providing traffic signal priority for selected
transit vehicles, e.g., buses behind schedule.
¾ Providing real-time traffic or incident information to a shared traveler information center
(511).
¾ Monitoring traffic volumes on another agency’s roadway, collecting data for planning and
research use (archiving).
¾ Coordinating the operation of a freeway ramp
meter with an adjacent traffic signal.
¾ Posting a warning message on another agency’s dynamic message sign (DMS) to alert
motorists.
Exhibit 1-4: Potential Applications
of the TMDD
A modern TMC facility has become a focal point for agency operations, and 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 Exhibit 1-5.
5
TMDD standard v03 Guide
July 11, 2011
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 (Ref.3).
Exhibit 1-5 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 operations. Services received from each environment are
typically negotiated and can be expanded as operations demand.
Command/Control of Field Devices
System Interface
Center-to-Field Devices
External
Center (EC)
TMC
Center-toCenter
Messages
Actuated Signal
Controller (ASC)
CCTV Cameras &
Switches
Field Master (FM)
Dynamic Message
Signs (DMS)
Data Collection &
Monitoring (DCM)
Traffic Sensor
Stations (TSS)
EC
Operator
TMC
Operator
Electrical Lighting
Management
Systems (ELMS)
Environmental
Sensor Stations
(ESS)
Signal Control
Priority (SCP)
NTCIP C2F Standards facilitate remote Command/ Control functions
(Visit www.ntcip.org for above device standards information)
Exhibit 1-5: Conceptual Representation of Operational Environment
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 realtime (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 Dynamic Message Sign (DMS).
6
TMDD standard v03 Guide
July 11, 2011
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 others’ 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.
In the above operational context, the TMDD-based C2C system interface plays a key role by
supporting the following to:
• Facilitate Remote Command and Control of Field Devices: For example, as shown in
Exhibit 1-5, 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 “take command” to perform 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 systemto-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).
1.8 TMDD Standard v3.0 Development
The development of TMDD Version 3.0 (published in November 2008, Ref.1) was driven by the
application of the systems engineering process (SEP), committee consensus, and discussion with
working focus groups and peer evaluations, including deployments efforts. Two key objectives
7
TMDD standard v03 Guide
July 11, 2011
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 (Ref.3).
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, and the Archived Data User Service (ADUS) that enables transportation
agencies to retain ITS-generated data and make them available for analysis.
The agencies that provided significant feedback and participated in the development work
included the New York metropolitan area regional architecture by TRANSCOM (Transportation
Operations Coordinating Committee), C2C infrastructure by the Texas Department of
Transportation, Smart SunGuide by the Florida Department of Transportation, Condition
Acquisition and Reporting System (CARS) deployed in New England States, Los Angeles
County Information Exchange Network (IEN), Caltrans-Regional Integration of Intelligent
Transportation Systems (RIITS), Los Angeles Department of Transportation, New York State
Information Exchange Network, and Arizona State’s C2C AzTech. These systems had reported
defects in the previous version of the TMDD standard and had expressed new needs arising from
their implementations. The new version considered this feedback and incorporated modifications
to the extent possible (Ref.3).
In addition, the TMDD effort utilized the ISO 14817 standard (to replace the previously use of
IEEE 1488 and 1489 standards) for data concepts (Ref.2) and the development process was
conducted as per the systems engineering guidelines (Ref.4). Finally, the effort addressed
unresolved issues from the earlier versions and was harmonized with other standards. Readers
interested in the full details on the historical background and documents on the TMDD
development, including agency reports on their experiences on C2C implementations, are
directed to visit http://www.ite.org/standards/tmdd/. (Ref.3)
1.9 Backward Compatibility
IEEE Standard Glossary of Software Engineering Terminology (IEEE 610 standard, Ref.4)
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 v 3.0 is not
backward compatible with the previous version. Due to the desire to improve the content of the
new standard, a number of changes to the messages have been made. 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) data concepts in TMDD v 2.1.
8
TMDD standard v03 Guide
July 11, 2011
•
TMDD v3.0 dialogs are based on the ISO 14827, while the TMDD v 2.1 used IEEE
standards.
It is beyond the scope of this guide to offer a suggestion on how to migrate from an old version
of the TMDD to the new one, as such decisions will be made by an individual implementation
effort.
1.10 TMDD and Interoperability
IEEE Standard Glossary of Software Engineering Terminology (IEEE 610 standard, Ref.4) defines interoperability as the ability of two or more systems or components to exchange information and to use the information that has been exchanged.
If two or more centers desire to acquire interoperability, the TMDD standard can play a constructive role to facilitate a system interface design. This can happen by specifying standardized defined data concepts that eliminates ambiguity by defining messages and dialogs. As an information level common dictionary (language), centers can now compose such unambiguous and
consistent C2C messages (messages that makes sense at both ends) to carry out dialogs in a prescribed way. Interoperability is possible if both centers implement the same sets of user needs
and requirements that satisfy those needs through a common specification. The TMDD standard
only provides interoperability for the elements that are mandatory as stated in the standard. To
ensure that centers using the TMDD are interoperable across the optional elements of the standard requires that the specific regional stakeholders meet to determine which optional elements
need to be made mandatory.
Centers from different functional areas desiring interoperability with TMCs must have a TMDDbased system interface specification and a common application level protocol. In addition, for
messages to arrive at destination as intended (“bits and bytes on the wire”), common transport
level and subnetwork level protocols must be deployed at both ends to complete the communication process. For additional information readers are directed to the NTCIP framework in Appendix-A.
1.11 Guide Organization
Keeping the above types of audience in mind, the guide is organized in four chapters as follows:
•
Chapter 1 prepares the reader by providing the background on the C2C context, introducing the definition of the C2C system interface and operational environment. A
brief discussion of the TMDD development effort and backward compatibility issue is
provided. A list of key questions with information references to this guide and TMDD
documentation is provided at the end of the chapter.
•
Chapter 2 introduces the TMDD standard and its structure and explains where to find
information in the TMDD documentation. This chapter explains the critical role of the
NRTM in identifying user needs and the role of the RTM in tracing requirements to
data concepts for defining a local project specification.
9
TMDD standard v03 Guide
July 11, 2011
•
Chapter 3 explains how to prepare a project-specific system interface specification using the Systems Engineering Process (SEP). In this chapter, use of the NRTM and
RTM is stressed to tailoring specific requirements leading to the system interface design content.
•
Chapter 4 discusses two types of TMDD implementation: DATEX-ASN.1 based and
C2C XML. Data concept examples are provided and underlying application level protocols are introduced.
•
Appendix-A provides an overview of the Application Level Protocols, and AppendixB provides basics of the C2C communications and related TMDD issues.
Readers are urged to download and use TMDD standard Volume I and II and digital design content files available at http://www.ite.org/standards/TMDD/ (See Ref.1). Sources of the information on ITS functional area standards and NTCIP family of communications standards are
provided in the list on the Web links in this guide. The guide recommends that users consult the
Systems Engineering for ITS by FHWA to familiarize themselves with the SEP.
(http://ops.fhwa.dot.gov/publications/seitsguide/seguide.pdf). Exhibit 1-6 is organized to help
users locate pertinent sections of their interest in this guide and the TMDD standard volumes.
1.12 Key Questions with Information References
Exhibit 1-6: Key Questions with Information References
Question 1 2 3 4 5 6 7 8 9 10 11 12 13 14 What is the purpose of this guide? What is the scope of the TMDD Standard v3.0? What are the key parts of the standard? Is TMDD v3.0 backward compatible? What are the conditions for conformance to the TMDD standard? What is conformance? How is it different than compliance? What if my needs are not met by the TMDD? Which additional standards do I need to implement TMDD? How can I prepare my specification for C2C system interface? How does TMDD trace to the National ITS Architecture? Where can I find TMDD design content? Where can I find information on other ITS standards? How was the TMDD standard developed? How can I get TMDD v3.0 standard files? 10
Guide Chapter Section 1 1.1 1 1.2 2 2.2 1 1.9 2 2.7 TMDD Standard Volume Section ‐ ‐ I 1.1 I 1.8 I 1.7 I 1.6 2 2.7 I 1.6 2 4 2.8 4.2.1‐4.2.2 I I 1.6.1 1.2 4 4.3 I 2,3 4 4.3.1 I 4 II ‐ 2,3,4 ‐ 4 4.3.5 Ref. ‐ Tables 1 1.8 References I ‐ II 2.0 TMDD standard v03 Guide
July 11, 2011
CHAPTER 2
TMDD STANDARD STRUCTURE
2.1 Chapter Purpose
The purpose of this chapter is to summarize the structure of the TMDD standard to aid the reader
in navigating the complex documentation of the standard. The focus is placed on the key components so that the readers can quickly understand the TMDD standard’s intended approach to
developing the specification for a system interface that meets local project objectives.
2.2 Standard Organization
As shown in Exhibit 2-1, Volume I and Volume II together make up the TMDD v3.0 standard.
The standard documentation organization follows this sequence—User Needs-RequirementsData 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.
Volume I
Concept of Operations and
Requirements
User Needs
Volume II
Design Content
Data Concepts
Requirements
Dialogs
Messages
RTM
NRTM
Data Frames
Data Elements
Exhibit 2-1: TMDD Standard Organization
The readers are urged to note that the NRTM and RTM are central to the requirements-centric
approach to system interface design used by the TMDD standard. As shown in the exhibit above,
during the project procurement process the standard supports the project specification
preparation with: first identifying user needs though the NRTM, then tailoring requirements that
satisfy the selected user needs, and finally identifying design concepts that fulfill the
11
TMDD standard v03 Guide
July 11, 2011
requirements.
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 determine which user needs should be selected from
the NRTM. This step ensures that specification work begins with the local project-centric
approach to user needs and not necessarily dictated by the standard, which is very broad-based.
2.3 TMDD v3.0 Standard Sections
Exhibit 2-2 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
Requirements
Volume II
Design Content
Section
Section Title (Purpose)
Section 1
Documentation Introduction (General
Information, Organization)
Section 1
Section 2
Concept of Operations for TMC to
Center Communications (Listing of
Section 2
Section
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
Section Title (Purpose)
Documentation Introduction
(shows relationship between Volume I
and II)
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.
needs/requirement combination)
Exhibit 2-2: TMDD Standard Sections
The following sections summarizes User Needs, Requirements, NRTM and RTM.
12
TMDD standard v03 Guide
July 11, 2011
2.4 User Needs
As the title of Volume I of the TMDD standard suggests (Concept of Operations and Requirements), Section 2 describes approximately 124 needs to support the operational environment.
These needs are stated in Exhibit 2-3.
As shown in Exhibit 2-3, the
standard lists a large number of
the potential needs from which #
a user may be able to satisfy
project-specific
operational 1
2
needs.
3
For example, an external center may be interested only in
sharing information about an
event such as a road crash or a
planned stadium event from a
TMC, thus a small number of
operational needs may be identified for the project. Needs
vary from project to project;
therefore it is critical to identify project-specific operational
needs early-on in the procurement phase. This process
should also involve those who
are affected by the C2C system
interface design.
4
5
6
7
8
Exhibit 2-3: Needs Identified by the TMDD Standard
Need
Total
Volume I
Section
Need for Connection Management
Need for Authentication and Restrictions
Need to Provide Information on organization, Centers and Contacts
Need to Share Event Information
Need to Provide Roadway Network Data
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
Need to Share Data for Archiving
Need to Accept Null Values
4
2
1
2.3.1
2.3.2
2.3.3
11
9
87
2.3.4
2.3.5
2.3.6
7
1
2.3.7
2.3.8
Mandatory User Needs (M)
9
9
9
9
9
9
Verify Connection Active (UN ID 2.3.1.1)
Request Need to Support (UN ID 2.3.1.2)
Need to Support Error Handling (UN ID 2.3.1.4)
Need for Node Inventory (UN ID 2.3.5.1.1)
Need for Link Inventory (UN ID 2.3.5.1.2)
Need to Accept Null Values (UN ID 2.3.8)
For example, in one jurisdiction multiple agencies may desire to exchange information with each
other or different jurisdictions may also be affected. In such cases, all agencies must select user
needs that affect each other. At the end of this step, a subset of project-specific user needs should
result.
Readers should be aware of a small number of user needs shown in the above
exhibit which are mandatory 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).
User Needs
NRTM
Requirements
With the project-specific user needs, the specification preparer should turn to
the NRTM (Volume I, Section 5) to evaluate which requirements are to be
included in the project specification through use of the NRTM as shown in
13
Exhibit 2-4:
Role of NRTM
TMDD standard v03 Guide
July 11, 2011
Exhibit 2-4. The next section discusses requirements, followed by a section
discussing the NRTM.
2.5 Requirements
Written in the “shall” language, format requirements firmly describe what information is and
how it is exchanged with external center (EC) subsystems through a system interface. The
requirements also describe what functionality is supported across the system interface.
Simply stated, each of these requirements specifies the next level of capability needed by the
user to satisfy one or more user needs. Therefore specification preparers and system developers
must pay close attention to selecting needs and tailoring requirements from the TMDD, which
will determine the data concepts defined in the RTM. A detailed discussion on the use of the
RTM is provided later in the Guide.
As shown in Exhibit 2-5, the
TMDD standard has defined 134
requirements (Volume I, Section
3) for the eight areas of the user
needs identified in the previous
section. Only a subset of these
requirements listed in Exhibit 2-4
needs to be evaluated using the
NRTM
for
the
project
specification, including required
mandatory requirements. The
TMDD standard classifies all
requirements as Mandatory (M)
or Optional (O) as shown in the
NRTM conformance column.
Exhibit 2-5: Requirements Determined by the TMDD
#
Requirements
Total
1
2
3
Connection Management
Authentication and Restrictions
Provide Information on organization,
Centers and Contacts
Share Event Information
Provide Roadway Network Data
Share Control of Devices (Inventory, Status
9
3
7
Volume I
Section 3
3.3.1
3.3.2
3.3.3
27
7
76
3.3.4
3.3.5
3.3.6
4
1
3.3.7
3.3.8
4
5
6
and Control of Detectors, CCTV, Video Switch,
DMS, ESS, Gate Control, HAR, Lane Control,
Ramp Meters, Traffic Signal Control
7
8
Share Data for Archiving
Accept Null Values
This classification is based on whether a particular requirement is determined to be a necessary
component to satisfy the user need(s) to which it traces. If the requirement is determined to be
necessary to support the corresponding user need, that requirement is classified as a mandatory
requirement. If the requirement is determined to support the user need but is not essential, that
requirement is classified as an optional requirement.
As a part of the implementation, some optional requirements (associated with the user need) may
be selected by the project. Once these are selected, they form (along with all the mandatory
requirements) the project implementation specification. The project outcome will be affected by
this since the design solution is affected by the selection of the optional requirement(s). These
optional requirements are now made mandatory for the project specification.
14
TMDD standard v03 Guide
July 11, 2011
2.6 Needs to Requirements Traceability Matrix (NRTM)
An operational need arises from a project ConOps,
as illustrated in Exhibit 2-6: Need to Verify CCTV
Control Status (Section 2.3.6.2.5). The need states
the external center’s desire to know if the camera
images are currently available or the status.
As shown in Exhibit 2-7, 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 second column. (This
completes the N part of the NRTM).
Exhibit 2-6:
Illustration of an Operational Need
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.
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.
Exhibit 2-7: Sample Needs to Requirements Traceability Matrix (NRTM)
UN ID
User Need 2.3.6.2.5
UN
Selected
Yes /
Requirement ID
Requirement
Conformance
Support
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
3.3.6.1.5.2
Contents of the Device Control Status
Request
M
3.3.6.1.5.3
Contents of Device Control Status
Response
M
3.3.6.3.4
Request CCTV Control Status
M
Other
Requirements
No
Need to Verify CCTV
Control Status
Yes
Yes
Yes
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;
15
TMDD standard v03 Guide
July 11, 2011
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.
2.7 Requirements Traceability Matrix (RTM)
As shown in Exhibit 2-8, using the RTM (Volume II, Section 4)
requirements are traced to the data concepts. The 135 requirements and subrequirements described in Volume I, Section 3 are traced to the data
concepts in Volume II, Section 3 through the use of the RTM.
Exhibit 2-9 illustrates how requirements are traced to the data concepts. At
this point, the RTM answers the question, “How will a system interface be
designed?”
Using the RTM as shown in Exhibit 2-9, 15 requirements and subrequirements are traced to: 1 “generic request-response” dialog (2.4.1, third
column), which will require 3 messages shown in fifth column, 5 dataframes and 6 data- elements to form messages, all shown as data types in
the fifth column.
Requirements
RTM
Data Concepts
Exhibit 2-8:
Role of RTM
In our example, one user need evaluated to 15 requirements, which in turn traced to 15 data
concepts. This shows how the TMDD standard’s intended use of both the NRTM and RTM
together can help the user to write project specification by tailoring the process.
16
TMDD standard v03 Guide
July 11, 2011
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 guess work); 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 2-9: Sample Requirements Traceability Matrix (RTM)
(Exhibit illustrates how requirements (in Volume-I) are traced to Data Concepts (in Volume-II) through RTM)
Requirement
ID
(Volume-I)
Requirement title
Dialog
See Note
Data Concept Name
Volume
II
Data
Concept
Type
Standards
Clause
See Note
Volume II
3.3.6.1.4.2
Contents of Device Control Request
Response
deviceControlResponseMsg
message
3.2.5.2
3.3.6.1.4.2.1
Required Device Control Response
Content
OrganizationInformation
data-frame
3.3.17.3
3.3.6.1.4.2.1
Required Device Control Response Content
DeviceControlResponse
data-frame
3.3.5.3
3.3.6.1.4.2.1
Required Device Control Response Content
Organization-resource-identifier
data-element
3.4.16.8
3.3.6.1.4.2.1
Required Device Control Response Content
Device-acknowledge-control
data-element
3.4.5.2
3.3.6.1.4.2.2.1
Operator Identifier
Organization-resource-identifier
data-element
3.4.16.8
3.3.6.1.4.2.2.2
Operator Lock Identifier
Organization-resource-identifier
data-element
3.4.16.8
3.3.6.1.4.2.2.3
Owner Center Organization
OrganizationInformation
data-frame
3.3.17.3
3.3.6.1.4.2.2.4
Operator Last Revised Date and Time
Organization-resource-name
data-element
3.4.16.9
3.3.6.1.5.1
Send Device Control Status Upon Request
dlDeviceControlStatusRequest
dialog
3.1.5.2
3.3.6.1.5.2
Contents of the Device Control Status
Request
OrganizationInformation
data-frame
3.3.17.3
3.3.6.1.5.2
Contents of the Device Control Status
Request
DeviceControlStatusRequest
data-frame
3.3.5.5
3.3.6.1.5.2
Contents of the Device Control Status
Request
Organization-resource-identifier
data-element
3.4.16.8
3.3.6.1.5.3
Contents of Device Control Status
Response
deviceControlResponseMsg
message
3.2.5.2
3.3.6.3.4
Request CCTV Control Status
deviceControlStatusRequestMsg
message
3.2.5.3
2.4.1
Notes: The Dialog column indicates the name of the dialog and represents the highest level information element defined in
Section 2 of the Volume II. There are three generic dialogs developed by TMDD (see Volume I, Section 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.
17
TMDD standard v03 Guide
July 11, 2011
2.8 Conditions for Conformance to the TMDD Standard
The TMDD standard is based on a wide range of requirements at a national level, all of which
may not be relevant to a project. A specification will identify the requirements of a particular
project to meet relevant needs. As shown in Exhibit 2-10 below, a specification writer is guided
by the RTM to match the requirements of a project with the corresponding requirements to select
data concepts. This means that requirements defined as “optional” in the TMDD standard might
need to be selected in a project specification, thus making them “mandatory” for that project.
Exhibit 2-10: Conditions for Conformance to the TMDD Standard
Conformance to the TMDD Standard v3.0
•
To claim conformance to the TMDD standard, an implementation shall support all of the Mandatory and optional user needs defined by the standard. (See Volume I; Section 5 NRTM, Third
Column.)
•
To claim conformance to a user need defined in the TMDD standard, an implementation shall
conform to all of the Mandatory and any selected optional requirements for all project user
needs (mandatory and selected optional) that trace to the subject user needs in the Needs to
Requirements Traceability Matrix (See Volume I; NRTM, Sixth Column.)
•
To claim conformance to a requirement defined in this standard, an implementation shall satisfy the requirement by using all of the dialogs and other data concepts (messages, data frames
and data elements) traced to the subject requirement in the Requirements Traceability Matrix
(See Volume II; RTM.)
The user of this standard is further advised that “conformance” to the TMDD standard should not
be confused with “compliance” to a project-specification. Off-the-shelf interoperability and
interchangeability (ability to interchange system components or parts) can only be obtained
through well documented features broadly supported by the industry as a whole. Designing a
system that uses features that are not defined in a standard or are not typically deployed in
combination with one another will inhibit the goals of interoperability, especially if the
documentation of these features is not available for distribution to the system integrators.
2.9 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
18
TMDD standard v03 Guide
July 11, 2011
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.
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. (This guide encourages users to contact ITE to share any extensions they have
developed so that they can be included in next version of the TMDD standard and properly
examined by the experts. The contact person at ITE is: Siva Narla, [email protected] or (202) 7850060 x119). In an attempt to define new user needs and ensuing requirements, users are advised
to follow attributes stated in systems engineering guides (also refer to Guide for Implementing
IEEE standard 1512).
Exhibit 2-11: Rules for Extending the TMDD Standard
Rules for “Extending” the TMDD standard
(For a detailed discussion see TMDD Volume I, Section 1.6.1)
•
•
•
•
•
•
•
•
•
The implementation may NOT completely replace a partially incomplete feature of the standard
with a complete custom feature.
An extension cannot reuse an existing name or identifier already defined by the standard. (Each
data concept has a unique ID in the TMDD.)
Extending a data element to support additional enumerations is allowed if the enumerations are
clearly and uniquely defined.
Extending the range of an existing data element requires that the data element be renamed.
If an implementation has a different interpretation of the meaning of a data element or how the
data element is to be used as defined by this standard, a new data element is to be created.
If a new data element is added to a message defined by this standard, that data element shall be
marked as OPTIONAL (O).
Any extensions shall be documented by the owning agency (ies) and/or the systems integrator, either in the XML schema or in ASN.1 notation.
If extensions are made to a message defined by the standard, that data message shall be renamed
to prevent confusion or ambiguity for the purposes of interoperability.
An implementation must ignore any attributes or elements in a valid Management Information
Base (MIB), schema, or whatever format that it does not recognize. This ‘must ignore’ rule applies only to the attribute or element and does not apply for any descendants of the attribute or
element.
19
TMDD standard v03 Guide
July 11, 2011
2.10 Chapter Summary
This chapter discussed the structure of the TMDD standard v3.0 and outlined sections of the
documentation: User Needs, Requirements, NRTM, and RTM. The chapter illustrated use of the
NRTM and RTM to identify user needs and trace requirements that satisfy selected used needs,
and then showed how requirements can be fulfilled by tracing them to the data concepts spelled
out by the standard. Consistent with the TMDD standard organization sequence—User NeedsRequirements-Data Concept—this chapter has provided guidance on their use in the specification
preparation for the system interface. The chapter also discussed conditions for conformance to
the TMDD standard and provided a suggestion on what to do if a user need is not addressed by
the standard. The next chapter will expand upon the concepts discussed in this chapter and guide
the users in the process of preparing a project specification.
20
TMDD standard v03 Guide
July 11, 2011
CHAPTER 3
WRITING SYSTEM INTERFACE SPECIFICATION
USING TMDD
3.1 Chapter Purpose
The previous two chapters have provided sufficient details on the TMDD standard and structure.
In this chapter, a SEP life cycle methodology is discussed to prepare a project-specific system
interface specification.
3.2 Methodology for Writing System Interface Specification
In recent years, ITS projects are being developed and systems are built using a structured methodology called the systems engineering process (SEP) using a V Model. This methodology has
been used effectively in the development of the National ITS Architecture, regional architectures, TMDD standard, and other ITS standards. Recent USDOT rules also require users to deploy SEP for ITS projects. (Readers are directed to two SEP references that may be helpful in
transportation applications: Systems Engineering for Transportation Professionals by FHWA
and the Systems Engineering Guidebook by Caltrans.)
The TMDD standard v3.0 (see Ref.1) was developed and structured using SEP steps with a focus
on the C2C ConOps context needs and requirements leading to the corresponding data concepts
(design content) for the system interface. The effort examined anticipated operational needs with
feedback from diverse groups of C2C stakeholders. As a result, the TMDD v3.0 standard has
made available to users a broad catalog of needs, requirements, and data concepts. Using steps
outlined in this chapter, a user should be able to select user needs, tailor requirements, and identify the data concepts associated with the project requirements in preparing a C2C system interface
specification. This is similar to a reader picking the necessary ingredients (TMDD needs and requirements) for his/her own “recipe” (system interface) and placing them in the “shopping cart”
(specification).
The reader is advised that the SEP methodology described in this chapter does not deal with the
application level protocols and project conformance statement necessary to complete the project
specification. Appendix-A provides details on protocol issues.
21
TMDD standard v03 Guide
July 11, 2011
3.3 Mapping TMDD Standard to V Model Steps
Exhibit 3-1 outlines four key steps considered necessary by this guide for preparing the TMDDbased, project-specific system interface specification. The V Model shows us where these steps
are occurring in the SEP. Applicable TMDD sections are identified in four steps and mapped to
the stages or phases of the V Model as shown in the exhibit below. Users should be guided by
these four steps to prepare project specific specification, using NRTM and RTM tools provided
by the TMDD standard. These steps are further explained in details below.
System Interface Project Specification Steps
STEP-1: Go to TMDD standard Volume I, Section 4, pages
156-170 on TMDD support to your ITS Architecture market
Packages, architecture flows.
STEP-2: Using the NRTM (pages 174-295 in the TMDD
Standard Volume I, Section 5), select the user needs that address
your operational needs. The user need description provided in
the ConOps (pages 9-33 in TMDD Standard Volume 1) will help
to better understand the intent and capability of the user needs.
STEP-3: Using the NRTM (pages 174-295 in the TMDD
Standard Volume I), select from the list of associated
requirements those that will satisfy the selected user needs.
STEP-4: Go to RTM (pages 580-635 in the TMDD Standard
Volume II. Section 4), use data concepts for design elected
requirements.
Operations
and
Maintenance
Feasibility Study
Regional
/ Concept
Architecture(s)
Exploration
System Validation Plan
System
Requirements
Project
Scoping
Project
Design
Project
Construction
System Verification Plan
(System Acceptance)
High-Level
Design
Subsystem
Verification Plan
(Subsystem Acceptance)
System
Verification &
Deployment
Subsystem
Verification
Unit / Device
Test Plan
Unit / Device
Detailed
Testing
Design
Software / Hardware
Development
Field Installation
and
Re
com
pos
itio
n
n
itio
efin
dD
an
on
siti
po
com
De
Project
Initiation
Retirement/
Replacement
System
Validation
Inte
gra
tion
Concept of
Operations
Changes
and
Upgrades
Project
Construction
Document/Approval
Time Line
Exhibit 3-1: Mapping of TMDD Standard Sections to the SEP "V" Model
Source: V diagram adopted from U.S. Department of Transportation, Systems Engineering for ITS
22
TMDD standard v03 Guide
July 11, 2011
Step-1: Regional ITS Architecture
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 a User Need Using NRTM
Using C2C operational scenarios as tools to help the user see what operational steps are needed
for a given operation, users should be able to identify potential needs. 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” and dictate “how” system requirements
will emerge in the next phase with which a system interfaces design is done. Only clearly stated
user needs will find their way into “design” using NRTM; if users miss them, developers will not
23
TMDD standard v03 Guide
July 11, 2011
fill in the voids. An “imperfect” system interface can result if these needs are not identified.
Exhibit 3-2 shows an example of how to go about selecting user needs to meet specific ConOps
context. The example illustrates a DMS operational need from the TMDD standard (125 user
needs in all are described) and using the NRTM to identify the User Need by its ID.
Exhibit 3-2: 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
2.3.6.4.3 Need to
Share DMS
Status
UN
Selected
Requirement
ID
Requirement
Conformance
Support
Other
Requirements
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).
Having been exposed to the above example of a DMS operation user need selection, the reader
should think of different operational contexts that may dictate the selection of other user needs.
Exhibit 3-3 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.
24
TMDD standard v03 Guide
July 11, 2011
Exhibit 3-3: Sample List of Potential User Needs for C2C Context
(If your application is listed here, use Step-2 to carry on next steps in selecting UN)
Step-2: Go to NRTM, Volume I, Section 5
C2C Operational Context
UN ID
User Need Title
Need to Manage Assets
Need to Provide Information on Organi2.3.3
Provide inventory sharing for:
zation, Centers and Contacts
• Traffic network
Need to Provide Network Data
• Closed circuit television cameras and switches 2.3.5
• Dynamic message signs
Need for Roadway Network
2.3.5.1
• Environmental sensor stations
Inventory
• Lane closure gates and swing bridges
Need to share Nodes, Link and Route
• Highway advisory radio and low power FM
2.3.5.2
Status
stations
Need to share Link Data
2.3.5.3
• Lane control signals
Need to share Route Data
• Ramp meters
2.3.5.4
• Traffic detectors
• Traffic signals
• Provide information on agencies, centers,
Systems, and users
Need to Manage Information
Need to Share Information
2.3.4
• Events (planned, current, or forecast) and supporting network data
• Traffic, weather and road conditions
• Operational status of devices
Need to Control Traffic Control Devices
Need to Provide Control of Devices
2.3.6
• Closed circuit television (CCTV) cameras
• Video switches
Need to Share Detector Data
2.3.6.1
Need to Share CCTV Camera Status and
• Dynamic message signs (DMS)
2.3.6.2
Control
• Environmental sensor stations (ESS)
Need to Share Video switch Status and
2.3.6.3
• Lane closure gates
Control
• Highway advisory radio (HAR)
Need to Share DMS Status and Control
2.3.6.4
• Lane control signals
Need to Share Environmental Sensor
2.3.6.5
Data
• Ramp meters (RM)
Need to Share Lane Closure Gate Control
2.3.6.6
• Actuated Signal Controllers (ASC)
Need to Share HAR Status and Control
2.3.6.7
Need to Share Lane Control Status
2.3.6.8
Need to Ramp Meter Status and Control
2.3.6.9
Need to Share Traffic Signal Control and
2.3.6.10
Status
•
Need to Archive Data
Traffic monitoring data, traffic flow and condi- 2.3.7
tions, data collection, roadway characteristics,
and event data
25
Need to Share Data for Archiving
TMDD standard v03 Guide
July 11, 2011
Step-3: Tailoring Requirements Using the 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.
At this stage in the SEP, users can feel confidence knowing that the TMDD standard has carefully constructed and allocated 134 requirements to 124 different user needs. This was done in
close collaboration with the knowledgeable experts in the field and carefully elicited, analyzed,
validated, and documented requirements. The TMDD standard has classified most of the listed
requirements as “optional,” largely to allow the user to select options for additional information
they need in their operation; however, some requirements are determined to be essential (by a
collective judgment of the technical system experts in the field) to satisfy corresponding needs
and are therefore made “mandatory.” To conform to the TMDD standard, mandatory requirements must be fulfilled by the specification.
From the detailed listing of requirements shown in the Exhibit 3-4, users can see how a unique
user need allocates multiple requirements and sub-requirements; some of them are mandatory to
conform to the TMDD v3.0 standard, and some are optional which a local project will decide. If
the optional requirements are selected by the project, they become necessary to “comply” with
the contractual specification. Such decisions are to be considered at this stage in the SEP.
26
TMDD standard v03 Guide
July 11, 2011
Exhibit 3-4 Requirements to Display a Message on a Remote DMS
UN ID 2.3.6.4.4 Need to Display a Message on a Remote DMS 3.3.6.1.4.1 Contents of Device Control Request Header (Mandatory)
An external center shall send a device control request header to an owner center. (There are seven sub
requirements also)
3.3.6.1.4.1.1 Required Device Control Request Header Content
The device control request header sent to an owner center shall include:
a. Unique identifier of the requesting organization;
b. Username of the requesting operator;
c. Password of the requesting operator;
d. Unique identifier of the device; and
e. Unique sequence number generated by the external center identifying the control request
within the external center (this sequence number shall be returned to the requesting client in any response to the control request).
3.3.6.1.4.2 Contents of Device Control Request Response (Mandatory)
An owner center shall send a device control request response to an external center.
3.3.6.1.4.2.1 Required Device Control Response Content (Mandatory)
The device control request response sent from an owner center to an external center shall include:
a. Unique identifier of the owner organization;
b. Unique identifier of the device;
c. Unique sequence number generated by the external center identifying the control request
within the external center; and
Status of the request (requested change completed, request rejected - invalid command,
request rejected - insufficient privileges and request queued - not implemented, device is
locked).
3.3.6.5.3.1 Send DMS Control Response Upon Request (Mandatory)
An owner center shall respond to an authorized external center requesting remote control of a DMS
via a one-time control request
with a message containing the status of the request.
3.3.6.5.3.2 Contents of DMS Control Request (Mandatory)
An external center shall send a DMS control request to an owner center
3.3.6.5.3.2.1Required DMS Control Request Content (Mandatory)
The DMS control request sent from an external center to an owner center shall include:
a. Generic device control request header information (See Section 3.3.6.1.4.1); and
b. Message requested in MULTI language; or
c. Message number being requested.
3.3.6.5.3.2.2.1Beacon Control (Optional)
The external center shall indicate if the beacon is to be enabled or disabled as part of the DMS
control request.
3.3.6.5.3.3 Contents of DMS Control Response (Mandatory)
The requirements for the DMS control response from an owner center to an external center are found in
Section 3.3.6.1.4.2, “Contents of Device Control Request Response.”
27
TMDD standard v03 Guide
July 11, 2011
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).
Requirements
RTM
Data Concepts
Dialogs
The reader may recall that in Chapter 3 of this guide, we discussed two types of TMDD representation of data concepts
available to implement system interface: ASN.1 based and XML
based. At this stage, the user must elect one (if it not already
done) and using the RTM as shown in Exhibit 3-5 select appropriate data concepts from Volume-II.
Messages
Data Frames
Data Elements
Exhibit 3-6 illustrates how the requirements to display a message
on a remote DMS are traced to the data concepts through the use
of the RTM (not all requirements are listed).
Exhibit 3-5: Selecting
Data Concepts Using RTM
All mandatory data concepts are shown as bolded in the Exhibit. In this example, a generic dialog 2.4.1 is referenced to conduct a request/response message pattern for DMS control. Two
messages are used.
Users should also be aware that certain requirements trace to other ITS standards for data
concepts as shown in this example NTCIP 1203 standard supplied data element will be necessary
for Beacon control. If such a capability is needed in an implementation, risk to interoperability
will result. In general adding data concepts from other domain standards not already included in
the TMDD will break interoperability. Users are advised to be aware of such issues and prepare
accordingly.
Exhibit: 3-6 Selection of Data Concepts Using RTM: DMS Example
(Source: Based on TMDD v3.0 standard)
Requirement
ID
3.3.6.1.4.1
3.3.6.1.4.1.1
Requirement
Title
Data Concept
Name
Data Concept
Type
Standard
Clause
Contents of Device Control
Request Header
DeviceControlRequestHeader
data-frame
3.3.5.2
Required Device Control
Request Header Content
OrganizationInformation
data-frame
3.3.17.3
dlDMSControlRequest
dialog
3.1.6.1
dMSControlRequestMsg
message
3.2.6.1
Required DMS Control Request
Content
DeviceControlRequestHeader
data-frame
3.3.5.2
Beacon Control
ntcip:DmsMessageBeacon
data-element
NTCIP
1203:5.6.8.6
Contents of DMS Control
Response
deviceControlResponseMsg
message
3.2.5.2
3.3.6.5.3.1
Send DMS Control Response
Upon Request
3.3.6.5.3.2
Contents of DMS Control
Request
3.3.6.5.3.2.1
3.3.6.5.3.2.2.1
3.3.6.5.3.3
Dialogue
2.4.1
28
TMDD standard v03 Guide
July 11, 2011
3.4 Chapter Summary
This chapter developed four steps to guide users in preparing a project-specific specification using TMDD at each stage of the SEP using the V Model. Each step explained what the specification writer should do at each stage of the SEP (user needs, requirements, and detailed design).
The chapter amplified central themes of the TMDD standard by explaining first how to use the
NRTM to identify user needs, then how to trace to the requirements that satisfy those user needs
(problem definition), and finally how to use the RTM to traces requirements to the data concepts
spelled out in standard (solution content). Using the NRTM and RTM as tools provided by the
TMDD standard, the user will be comfortable in ensuring the success of the resulting system interface design development process.
29
TMDD standard v03 Guide
July 11, 2011
CHAPTER 4
TMDD IMPLEMENTATION
4.1 Chapter Purpose
The previous chapter discussed project specification preparation steps using the SEP V Model.
This chapter discusses two types of TMDD implementations using structured data concepts. The
chapter provides examples to assist readers in understanding functions served by each type of
data concept. The chapter also presents a brief discussion on application level protocols used in
conjunction with the TMDD to prepare a project-specific specification. (Additional information
is also provided in Appendix-A).
4.2 TMDD Implementation
The specification writers desiring to procure a TMDD-based C2C system interface will be required to prepare a project-specific specification using one of the following two types of implementations (note that they cannot be mixed):
4.2.1 DATEX-based Implementation Requirements
1.
2.
3.
4.
5.
6.
7.
8.
Data Concepts: Generic Dialogs
Data Concepts: Messages, Data Frames and Data elements in ASN.1 representation
Application Level Protocol: NTCIP 2304 AP-DATEX-ASN.1
Encoding: ASN.1 (or XML)
Transport: TCP/IP or UDP/IP
Naming Conventions for Centers/Organizations: NTCIP 1104
Project Conformance Statement
Other local project requirements
4.2.2 C2C XML based Implementation Requirements
1.
2.
3.
4.
5.
6.
7.
Data Concepts: Generic Dialogs
Data Concepts: Messages, Data Frames and Data Elements in XML
Application Level Protocol: NTCIP 2306 AP-C2C-XML
Encoding: XML or SOAP
Transport: HTTP
Naming Conventions for Centers/Organizations: NTCIP 1104
Project conformance Statement
8. Other local project requirements
30
TMDD standard v03 Guide
July 11, 2011
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 exchanges. The C2C XML is a Web Services-based (Internet-based) approach to information exchanges. 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) with each other must implement a common system interface specification to achieve this objective.
In the following sections we will discuss dialogs, followed by data concepts in ASN.1 representation and data concepts in XML representation, and briefly review the two applications level
protocols used in the TMDD-based C2C system interface implementation.
4.3 Understanding Dialogs
A dialog describes a sequence of message exchanges between two entities (just as in a
conversation between two people). For example, a request-response dialog would include two
messages being shared between an external center (EC) and an owner center (TMC) to
accomplish information sharing. The first message would include the request for information,
followed by a message containing the information (response).
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.
Dialogs can be described using the Unified Modeling Language (UML) Sequence Diagrams. 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:
•
Request-Response. This message pattern supports the sending of a message followed by
a response. For simplicity's sake, this pattern is typically implemented in a purely synchronous fashion, which holds a connection open and waits until the response is delivered
or the timeout period expires. (However, request-response may also be implemented
asynchronously, with a response being returned at some unknown later time.) Both application level protocols listed in the previous section support this request-response message
pattern which will be discussed later in this section.
•
Subscription-Publication. This message pattern supports a subscriber application performing an initial request-response to set up future asynchronous publications from an in-
31
TMDD standard v03 Guide
July 11, 2011
formation publisher application. Both application level protocols also support the subscription-publication message pattern, which will be discussed later in this section.
As shown in Exhibit 4-1 below, one of the three generic dialogs developed by the TMDD
standard will be 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 Exhibit 4-1, 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 3.1.5.2 listed in Volume II.
Exhibit 4-1: Referencing a Generic Dialog in RTM
Requirement
ID
(Volume-I)
Requirement title
3.3.6.1.5.1
Send Device Control Status Upon
Request
Dialog
See Note
Volume
II
2.4.1
32
Data Concept Name
Data
Concept
Type
Standards
Clause
See Note
Volume II
dlDeviceControlStatusRequest
dialog
3.1.5.2
TMDD standard v03 Guide
July 11, 2011
4.3.1 Generic Request-Response Dialog
Description: 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. (See Exhibit 4-2)
Sequence Diagram:
Exhibit 4-2: Generic Request-Response Dialog
(This dialog is listed as Section 2.4.1, Volume II)
33
TMDD standard v03 Guide
July 11, 2011
4.3.2 Generic Subscription Dialog
Description: 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. (See exhibit 4-3)
Sequence Diagram:
Exhibit 4-3: Generic Subscription Dialog
(This dialog is listed as Section 2.4.2, Volume II)
34
TMDD standard v03 Guide
July 11, 2011
4.3.3 Generic Publication Update Dialog
Description: Upon acceptance of a subscription dialog, an OC shall provide information updates
to an EC. Upon error, the EC shall return an error message. (See Exhibit 4-4)
Sequence diagram:
Owner Center
External Center
DL_PublicationUpdate()
MSG_PublicationUpdate
MSG_ConfirmationReceipt
The following shows the
sequence of messages upon
error.
DL_PublicationUpdate()
MSG_PublicationUpdate
MSG_ErrorReport
Exhibit 4-4: Generic Publication Update Dialog
(This dialog is listed as Section 2.4.3, Volume II)
35
TMDD standard v03 Guide
July 11, 2011
4.4 Understanding ASN.1 Data Concepts
The TMDD standard utilizes ASN.1 based Data Concepts to construct fixed messages, which are
then communicated among centers upon establishing an authenticated connection. The properties
and behavior of these fundamental constructs all follow the same set of rules, thus eliminating
ambiguities. These data concepts are graphically illustrated in Exhibit 4-5 with their relationship
to each other.
Understanding ASN.1 Data Concepts
Data concepts can be viewed as “building materials” for construction of a users-defined system interface to
accomplish “conversations” among centers. As seen from the layout below, ASN.1 data concepts form interface
dialogues using messages that are constructed using data elements.
A dialog is a temporal
sequence of messages,
including variants, among
two or more system
components that are used
to accomplish a
service/observable result.
Data Element Concept consists of
a class and a property (which is
the characteristic of a class used to
group and differentiate individual
objects.)
A message is a structured
grouping of data elements
and/or data frames.
Data Frame is a structured grouping of
data elements primarily for the purpose of
referring to a group with a single name to
efficiently reuse such groups of data
elements that commonly appear together in
a message specification.
Data Element is a formalized
representation of some
information (i.e., a property; e.g.,
a fact, proposition, or an
observation) about an object class
(e.g. a person, place, process,
concept, association, state, or
event), with an explicit value
domain.
Object Class, Property and Value Domain is
description of objects that share the same
properties, relationships, and semantics within
a given domain of discourse about which there
is a need to represent some information, e.g.
vehicle class.
Exhibit 4-5: ISO 14817 Data Concepts Framework
(Source: Based on ISO 14817)
As the information in the above Exhibit shows, a dialog is a final step in moving messages in
defined sequences to a receiving center system, which in turn responds accordingly. The mes-
36
TMDD standard v03 Guide
July 11, 2011
sages are very high level conversations, which are carefully crafted using a particular set of data
elements or data frames. ASN.1 data concepts and their relationships to each other are illustrated
in the following examples.
Exhibit 4-6 shows a request-response dialog to allow an external center (e.g. an emergency management center) to request a TMC (owner center) to perform a control action on a CCTV owned
by the TMC. This “need” will be satisfied by the dialog using pre-selected messages for a particular field device, in this case a CCTV camera.
Exhibit 4-6: Example of ASN.1 Representation of a TMDD Dialog Construct
ASN.1 Representation of a TMDD Dialog Construct
Name of Dialog, dlCCTVControlRequest, Section 3.1.2.1.3, Volume-II
dlCCTVControlRequest ITS-INTERFACE-DIALOGUE ::= {
DESCRIPTIVE-NAME "ExternalCenter<-DlCCTVControlRequest->OwnerCenter"
ASN-NAME "DlCCTVControlRequest"
Dialog has an Unique
ASN-OBJECT-IDENTIFIER {tmddDialogs 5}
OID in INTERNET tree
URL "R-R.gif"
DEFINITION "A request-response dialog that allows
an external center to request an owner center
Supports Traffic
to perform a control action on an owner center's CCTV."
Management
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
ARCHITECTURE-REFERENCE {"traffic control coordination"}
ARCHITECTURE-NAME {"U.S. National ITS Architecture"}
Supports Architecture
ARCHITECTURE-VERSION {"6.0"}
Data Flow
DATA-CONCEPT-TYPE interface-dialogue
STANDARD "TMDD"
REFERENCED-MESSAGES {
Requires messages #5,
{ tmddMessages 5 }, -- Input
18, 10
{ tmddMessages 18 }, -- Output
{ tmddMessages 10 } -- Fault
}
REFERENCED-OBJECT-CLASSES {
An object class representing
{ tmddObjectClasses ownerCenter(18) },
an external center system
{ tmddObjectClasses externalCenter(9) }
(9) and owner center (18)
}
interface consisting of the
}
dialogs and message content.
Exhibit 4-7 shows a construct of an ASN.1 message that is based on the above definitions: “The
information content necessary to request a control action of an owner center's CCTV camera”- that uses data frames and data elements as discussed in the above Exhibit. Note that a message may use more than one data frame or data element to reach out to a particular entity or action desired. Readers should note that this message is structured, and it is a unique representation in ITS domains. The reference hierarchy starts with a dialog, then a message, then data
frames, and finally a data element reference, which will have an attribute value to trigger a desired action.
37
TMDD standard v03 Guide
July 11, 2011
Exhibit 4-7:
ASN.1 Representation of a TMDD Message, Data Frame, and Data Element Constructs
ASN.1 Representation of a TMDD Message Construct
Name of message, CCTVControlRequestMsg , Section 3.2.2.1.2, Volume-II
Description The information content necessary to request a control action of an owner center's CCTV camera ASN.1 REPRESENTATION
cCTVControlRequestMsg ITS-MESSAGE ::= {
DESCRIPTIVE-NAME "cCTVControlRequestMsg:message"
ASN-NAME "cCTVControlRequestMsg"
ASN-OBJECT-IDENTIFIER { tmddMessages 5 }
DEFINITION
"The information content necessary to
request a control action of an owner center's CCTV camera."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
ARCHITECTURE-REFERENCE {
"traffic control coordination"
}
ARCHITECTURE-NAME {"U.S. National ITS Architecture"}
ARCHITECTURE-VERSION {"6.0"}
DATA-CONCEPT-TYPE message
STANDARD "TMDD"
META-DATA-SOURCE direct
PRIORITY "routine"
FREQUENCY-OR-MESSAGE-MODE "on demand"
REFERENCED-DATA-FRAMES {
{ tmddDataFrames 6 }
}
DATA-TYPE "
CCTVControlRequestMsg::= CCTVControlRequest
"
}
Messages has an Unique
OID in INTERNET tree
Supports Traffic
Management
Supports Architecture
Data Flow
This messages references
dataframes #6
ASN.1 Representation of a TMDD Data Element Construct
Name of DE, CCTVRequest Command, Section 3.4.3. 2, Volume-II
ASN.1 Representation of a TMDD Data Frame Construct
Name of DF, CCTVControl Request Section 3.3.2. 2, Volume-II
cCTVControlRequest ITS-DATA-FRAME ::= {
DESCRIPTIVE-NAME "CCTVControlRequest:frame"
ASN-NAME "CCTVControlRequest"
ASN-OBJECT-IDENTIFIER { tmddDataFrames 6 }
DEFINITION "The information content necessary to request
a control action of an owner center's CCTV camera."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
DATA-CONCEPT-TYPE data-frame
STANDARD "TMDD"
REFERENCED-DATA-FRAMES {
{ tmddDataFrames 24 },
{ tmddDataFrames 5 }
}
REFERENCED-DATA-ELEMENTS {
{ tmddDataElements 6 }
}
DATA-TYPE "
CCTVControlRequest ::= SEQUENCE {
device-control-request-header DeviceControlRequestHeader,
cctv-request-command Cctv-request-command,
cctv-command-parameters CCTVControlDetails,
...
}
"
}
38
cctv-request-command ITS-DATA-ELEMENT ::= {
DESCRIPTIVE-NAME "CCTV.Cctv-request-command:cd"
ASN-NAME "Cctv-request-command"
ASN-OBJECT-IDENTIFIER { tmddDataElements 6 }
DEFINITION "A code representing a CCTV command."
DESCRIPTIVE-NAME-CONTEXT {"Manage Traffic"}
DATA-CONCEPT-TYPE data-element
STANDARD "TMDD"
DATA-TYPE "
Cctv-request-command ::= ENUMERATED {
preset (1),
jog-positioning (2),
direction (3),
focus (4),
manual-iris (5),
wiper-on-off (6),
lock-for-the-camera (7),
pan (8),
tilt (9),
zoom (10),
text-overlay (11),
switch-one-input-to-one-output (12),
...}"
FORMAT "ASN.1 encoding"
UNIT-OF-MEASURE ""
VALID-VALUE-RULE "see the ASN.1 DATA-TYPE"
}
TMDD standard v03 Guide
July 11, 2011
4.5 Understanding C2C XML Data Concepts
In this section and the next, we will review the C2C XML data concepts, using the SOAP-based
message encoding and transport mechanism to implement the TMDD.
C2C XML implementation includes the following:
• For Data Elements: XML Schema for defining data elements, XML is encoded as
Unicode text. (TMDD and all other functional areas dictionaries such as IEEE 1512 are
based on the XML schema as per SAE J2630 standard).
• For Dialogs: Web Services Description Language (WSDL) for interface dialog definition
(as per NTCIP 2306 C2C XML). WSDL is an XML-based language for locating and describing Web services offered by centers.
Readers should note that the NTCIP 2306 C2C XML (includes WSDL specification) is
required to support the TMDD request-response and subscription-publication message
patterns and includes subscription types for: oneTime, periodic and onChange, corresponding to the TMDD single, periodic and event-driven subscription types. The appropriate standards clauses that should be used to specify message patterns (dialogs) for
TMDD are included in the RTM (TMDD standards, Section 4.0, Volume-II.)
In addition to the above, if data concepts from other standards are required such as
LRMS, NTCIP, or SAE’s ITIS, they should be referenced in the project-specific RTM in
the Standards Clauses column.
• For Messages: SOAP (Simple Object Access Protocol) encoded messages transport over
HTTP for the World Wide Web Consortium (W3C) approach. It supports the requestresponse and subscription-publication message patterns. (Readers are directed to the
NTCIP 2306 C2C XML standard at http://www.ntcip.org/library/ for detailed discussion
on the approach to SOAP and WSDL concepts).
Each of these components is briefly introduced below. Additional information is also provided in
Appendix-A.
4.5.1 XML Schema and Terminology
XML, the Extensible Markup Language, is a standard of the W3C. XML is a means by which
one computer can encode some information (data) so that another computer receiving that
encoded information will be able to understand its contents and act on that content (e.g. process
the information, display the information to a human, store the information in a database, issue a
command to a field device, etc.). Unlike most computer encoding standards such as Basic
Encoding Rules (BER) to achieve serialization of data, there is no single set of encoding rules for
39
TMDD standard v03 Guide
July 11, 2011
XML. Instead, XML encoding rules are customized for different applications. Furthermore,
XML encoding rules include a mechanism for identifying each element of an XML document or
message.
Once information is described (encoded) using XML, it is called a document. An XML
document is comprised primarily of elements as shown in the Exhibit 4-9 example. An element
is delimited by tags. Usually, a tag is comprised of the name of the element it delimits, enclosed
between a pair of angle brackets (“<” and “>”). Tags usually come in pairs – a start-tag and an
end-tag. The element name in the start and end tag are identical except that the latter has a
forward slash (“/”) at its beginning. A start-tag may optionally include attributes of the
element. An attribute name is followed by an equal sign and a value for that attribute. The
content of an element is the text that appears between its start-tag and its end-tag. Elements may
be nested – the content of an element can include other elements. Nesting allows for complex
information structures. In the example shown in Exhibit 4-8, nesting is used to show that an
element (a piece of information) called “SignalController” is made up of other elements
(HardwareType, FirmwareType, FirmwareVersion, Group, and Detector), and that Detector
information in turn is comprised of other elements (HardwareType, Lane, Dimensions), and that
Dimension information in turn is comprised of still other elements (Width, Length). The level of
nesting may continue to any depth.
This example describes a traffic signal controller,
number 45, owned by the city of Utopia. It is a Wiz
<SignalController ‘ID “45”’ Owner=”City of Utopia”>
<HardwareType>Wiz Bang 250</HardwareType>
<FirmwareType>Independent</FirmwareType>
<FirmwareVersion>1.5</FirmwareVersion>
<Group>5</Group>
<Detector ID=23>
<HardwareType>InductiveLoop</HardwareType>
<Lane>2</Lane>
<Dimensions>
<Width Units=”cm”>240</Width>
<Length Units=”cm”>600</Length>
</Dimensions>
</Detector>
</SignalController>
Bang 250 controller with Independent firmware,
version 1.5. It is a member of signal group 5. It is
associated with one detector, which is an inductive
loop in lane 2, with dimensions of 240 by 600
centimeters. Notice that the encoded information is
comprised of English-language characters, or text.
This is different from many encoding schemes that
encode to a binary format. Both sending and
receiving applications must use the same tags and tag
hierarchy to interpret the content of messages. Tag
names and hierarchy are defined in an XML Schema.
Exhibit 4-8: Example of Encoding using XML Schema
The encoding rules, or grammar, for a particular application are usually defined using an XML
Schema. This is a definition of the items that make up XML, such as the set of allowable tags
(e.g. element types), attributes of each element type (if any), default values (if any), and how
elements can be nested (data structure). A message or document describing a traffic signal could
use a different XML than a message or document describing an incident. If referenced to, the
XML schema language. An XML schema is extensible. Additional element types can be added
40
TMDD standard v03 Guide
July 11, 2011
at any time in the future without invalidating earlier versions of the schema. The XML standard
requires software that reads and interprets an XML document (called an XML parser) to ignore
any tags (and elements thus delimited) that are not included in the version of the schema
currently used by that parser. The eXtensible style sheet language (XSL) can be used to enable
a computer to automatically translate the information content of an XML document into another
formatted document (must be in text format) including XML.
4.5.2 TMDD Dialog in XML Representation
WSDL is a specification that allows centers to specify the basic format of a request to their
systems. The TMDD standard Volume II, Section 3, has provided dialogs based on the WSDL
specification as per NTCIP 2306 standard. Exhibit 4-9 illustrates a SOAP encoded requestresponse pattern that allows an external center to request an owner center to perform a particular
action indicated in the messages. (Appendix-A provides detail descriptions of both WSDL and
SOAP).
SOAP Encoded
request message
Owner
Center
External
Center
SOAP Encoded
response message
Exhibit 4-9: SOAP Request-Response Messages
(Source: NTCIP 2306 standard)
Exhibit 4-10 illustrates a dialog in XML representation using the WSDL specification. Each
dialog has a section number (e.g.3.1.2.14). There are 122 TMDD dialogs compiled in Section
3.1, Volume II to choose from. The message pattern (dialog) is SOAP-encoded as indicated in
the previous exhibit.
Name of Dialog
Definition of Dialog
XML Schema
3.1.2.14 DlCCTVControlRequest
A request-response dialog that allows an external center to request an owner center to perform a control
action on an owner center's CCTV.
<operation xmlns="http://schemas.xmlsoap.org/wsdl/"
name="DlCCTVControlRequest">
<input message="tns:MSG_CCTVControlRequest"/>
<output message="tns:MSG_DeviceControlResponse"/>
<fault name="errorReport" message="tns:MSG_ErrorReport"/>
</operation>
Exhibit 4-10: Example of a XML Dialog
41
TMDD standard v03 Guide
July 11, 2011
4.5.3 TMDD Message in XML Representation
Exhibit 4-11 illustrates a TMDD message structured with an XML Schema defined by the SAE
J2630 standard (which is also being used by other functional area standards such as IEEE 1512,
APTA TCIP). This message requests a control action of an owner center's CCTV camera. A full
range of XML messages are compiled in Section 3.2, Volume II.
Name of Message
Definition of Message
XML Schema
3.2.2.1.3 CCTVControlRequestMsg
The information content necessary to request a control
action of an owner center's CCTV camera.
<xs:element name="cCTVControlRequestMsg"
type="CCTVControlRequest"/>
Exhibit 4-11: Example of a XML Message
4.5.4 TMDD Data Frame in XML Representation
Section 3.3 of the TMDD Volume II provides a range of data frames that support messages that
meet requirements. Exhibit 4-12 illustrates how required related data frames or data elements
together can support the TMDD message. In this case the cctv-request-command will actually
trigger the associated “parameter” in the data frame CCTVControlDetails, which is defined in
section 3.3.2.1.3 of Volume II.
3.3.2.2.3 CCTVControlRequest
Name of Data-Frame
Definition of Data-Frame
XML Schema
The information content necessary to request a control
action of an owner center's CCTV camera.
<xs:complexType name="CCTVControlRequest">
<xs:sequence>
<xs:element name="device-controlrequest-header" type="DeviceControlRequestHeader"/>
<xs:element name="cctv-request-command"
type="Cctv-request-command"/>
<xs:element name="cctv-commandparameters" type="CCTVControlDetails"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
Exhibit 4-12: Example of a XML Data-Frame
42
TMDD standard v03 Guide
July 11, 2011
4.5.5 TMDD Data Element in XML Representation
Exhibit 4-13 illustrates how an XML based data element specifies the enumeration value of a
parameter to be controlled. A data element is a final data concepts action in hierarchy that starts
with a dialog. Section 3.4 of Volume II lists data elements for devices, event class, and other data
elements needed to meet requirements.
Name of
Data-Frame
Definition
A code representing
a CCTV command
XML Schema
3.4.2.3.3 Cctv-request-command
<xs:simpleType name="Cctv-request-command">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:unsignedInt">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="12"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="preset"/>
<xs:enumeration value="jog positioning"/>
<xs:enumeration value="direction"/>
<xs:enumeration value="focus"/>
<xs:enumeration value="manual iris"/>
<xs:enumeration value="wiper on off"/>
<xs:enumeration value="lock for the
camera"/>
<xs:enumeration value="pan"/>
<xs:enumeration value="tilt"/>
<xs:enumeration value="zoom"/>
<xs:enumeration value="text overlay"/>
<xs:enumeration value="switch one input to
one output"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="insert-extensionvalues-here"/>
</xs:restriction>
Exhibit 4-13: Example of a XML Data Element
43
TMDD standard v03 Guide
July 11, 2011
4.6 Application Level Protocols
The TMDD standard can be deployed with either of the following two application level
protocols:
• NTCIP 2304 AP-DATEX
• NTCIP 2306 C2C XML
Each is briefly introduced below. Detailed discussion is provided in Appendix-A. Users should
determine which protocol is going to be used for the system interface as early as possible in the
procurement process with due consideration given to other ITS applications in the region. Users
should also closely examine interoperability requirements at the application level, where protocols cannot be mixed if interoperability is desired. (The current trend in the United States appears
to be towards XML for various reasons, including its widespread use in the industry and attractiveness of easier implementation. At this point no formal survey on the deployments is reported).
4.6.1 NTCIP 2304 - Application Profile for DATEX-ASN (AP-DATEX)
Data Encoding and Transport Using DATEX
As an informational level standard, TMDD only specifies the format and structure of message
content and the sequence of message exchanges. TMDD data concepts accomplish this task with
ASN.1 representation as discussed above. The task of encoding and transporting TMDD
messages is performed by an application level communication protocol, which has its own
format and associated dialogs.
The NTCIP 2304 DATEX-ASN supports the TMDD request-response and subscriptionpublication message patterns to fulfill C2C concept of operation needs as discussed below.
Readers should also note that the appropriate NTCIP 2304 clauses that should be used to specify
message patterns for TMDD are included in the RTM in Volume II. NTCIP 2304 also references
ISO standard 14827-2, 2005 specification of the DATEX-ASN subscription modes and requires
a companion ISO 8825-1 Basic Encoding Rules (BER) to convert abstract syntax of data to
machine readable transfer syntax. (DATEX-ASN also supports NTCIP 1102 Octet Encoding
Rules (OER), a U.S. standard designed to accommodate low bandwidth mediums for command
and control of field devices such as a traffic controller.)
One center may request another center to send a particular type of data in several manners to suit
its operational needs. To minimize network bandwidth or data storage required, the center may
elect to subscribe to data in the following ways:
Single transfer: Send data just once, e.g. inventory of DMS located on a particular route.
Periodic transfer: Send data at set intervals, e.g. every hour on the hour or once in the a.m. peak
44
TMDD standard v03 Guide
July 11, 2011
periods or once in the p.m. peak periods, e.g. signal timing plans generally change for directional
traffic in a.m. or p.m. for an arterial passing through multiple jurisdictions. Another example
could be current incident data.
Event-driven transfer: Centers have a reason to share event information in order to impart
situational awareness and to facilitate the coordination of activities and resources. Event
information can include incidents, obstructions, traffic conditions, weather conditions, etc. Based
on the usefulness of such data, a center may desire constant updates on virtually all entities (e.g.
a traveler information system), or may only desire status information for selected entities upon
request (e.g. a geographically remote center may only be interested in major status changes or
major events, or the center may only be able to handle a certain amount of data). For example, a
center wants to be automatically notified of new incidents as they occur, to retrieve traffic
volume and traffic signal status data for the roadways adjacent to the incident, and sometimes to
request the other center to change its signal timing plan or post a particular message on a nearby
DMS.
4.6.2 NTCIP 2306 C2C XML
The NTCIP 2306 standard requires the following four standards by the World Wide Web Consortium (W3C) that are applicable to C2C XML implementation:
•
•
•
•
XML Schema 1.0
Web Services Description Language (WSDL 1.1)
Simple Object Access Protocol (SOAP 1.1)
Hypertext Transfer Protocol (HTTP 1.1)
Each of these four standards is discussed in detail in Appendix-A, and the requirements for each
is provided in the NTCIP 2306. A general overview is also provided in the NTCIP 9010.
4.7 Chapter Summary
This chapter discussed in detail the TMDD data concepts to fulfill requirements of a system
interface design. It outlined components necessary to implement DATEX and C2C XML
approaches. In both cases, the chapter provided detailed definitions of underlying data concepts.
Examples of ASN.1 and XML based data constructs for dialogs, messages, data frames and data
elements will help readers with their selection process. The chapter also introduced application
level protocol standards developed by the NTCIP effort and their use with the TMDD to
complete implementation.
45
TMDD standard v03 Guide
July 11, 2011
REFERENCES
1. TMDD V3.0 Standard Documentation is listed at http://www.ite.org/standards/TMDD/.
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://distribution.ite.org/process.asp
Also, TMDD Electronic Design Files are available in zip files as XML and WSDL and as
XMLSpy output (a registered trademark of Altova). The electronic design files of the
TMDD are normative to the standard. These electronic design files contain the source design
of the TMDD used in developing Volume II. These electronic files have been verified using
software tools to be correct ASN.1, WSDL and XML Schema syntax. A description of each
TMDD electronic design file is included below:
File
ctrl+click
Format
Description
md5sum
Zip File Containing the ISO 14817 and TMDD Data Type ASN Modules in ASN Format
ISO14817M1.asn
ASN.1
Contains the ISO 14817 meta attribute schema.
f70c900ddcee49055470f7b8
174a99da
TMDDM1.asn
ASN.1
Contains the ISO 14817 meta attributes for TMDD object class data concepts.
337f0774b94c8d48cd88178
8a6742c0b
TMDDM4.asn
ASN.1
Contains the ISO 14817 meta attributes for TMDD message, data frame, and data element data
concepts.
a1064a554d61e422f0d0c09
6302decba
TMDDM5.asn
ASN.1
Contains the ISO 14817 meta attributes for dialog data concepts.
08fb109c9c95f939e2049820
b124cc5c
TMDD.asn
ASN.1
Contains the ASN.1 definitions of TMDD messages, data frames, and data elements. This file
contains the ASN.1 definitions used in the DATA-TYPE meta attribute of the tmdd-iso14817m4.asn file
6b78fc1bb7bb4ad1b48c701
286b14ad9
TMDD.xsd
XML
Schema
http://www.ite.org/standards/TMDD/TMDDv3.0%20ASN%20Output
s%20‐%20Final.zip 081b4fa192ff16ba51b26d6c
cd39a893
TMDD.wsdl
WSDL
Contains the WSDL definitions of TMDD dialogs. b4cc84c6be2f5b429667c2e5
ab32ebb7
Contains the XML Schema definitions of TMDD messages, data frames, and data elements.
http://www.ite.org/standards/TMDD/TMDDv3.0%20wsdl%20schem
as%20‐%20Final.zip
Note: The last column md5sum is a check sum that may be used by an implementer to verify that they have acquired
the same TMDD electronic design files as used by Volume II.
2.
3.
4.
5.
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
Participants’ Presentation Reports, TMDD v3.0 User Workshop (September 26, 2006)
http://www.ite.org/TMDD/workshop/
Systems Engineering Handbook, International Council on Systems Engineering (INCOSE),
2007. http://www.incose.org/ProductsPubs/products/sehandbook.aspx
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.
46
TMDD standard v03 Guide
July 11, 2011
Information Sources for Center-to Center Communications
Management &Operations (M&O) Guides:
1. Management and Operations of Intelligent Transportation Systems, ITE, 1999
2. Transportation System Management and Operations, Action Kit, ITE, 2005
3. M&O /ITS Council, Resources List, ITE, http://www.ite.org/councils/ITS/default.asp
4. An Annotated Outline for a Traffic Management Center Operations Manual
M&O/ITS Council, ITE, http://www.ite.org/bookstore/ir107.pdf
5. Sharing Information between Public Safety and Transportation Agencies for Traffic
Incident Management, NCHRP Report 520, TRB, 2004. http://www.trb.org/Main/Home.aspx
M&O Manuals/Handbooks
6. Handbook for Developing TMC Operation Manual, http://tmcpfs.ops.fhwa.dot.gov
7. Freeway Management & Operations Handbook,
http://ops.fhwa.dot.gov/freewaymgmt/publications/frwy_mgmt_handbook/report_info.htm
8. Traffic Incident Management Handbook, http://ntl.bts.gov/lib/jpodocs/rept_mis/13286.pdf
National ITS Architecture Guides:
9. National ITS Architecture v6.1, 2009, http://www.iteris.com/itsarch/index.htm
10. Regional ITS Architecture, http://www.ops.fhwa.dot.gov/its_arch_imp/guidance.htm
11. Architecture Case Studies, Please contact Local FHWA/FTA office/Web search
Systems Engineering Guides
12. Systems Engineering for ITS-An Introduction for Transportation Professionals, FHWA:
http://ops.fhwa.dot.gov/publications/seitsguide/seguide.pdf
13. Systems Engineering Guidebook, Caltrans and FHWA, February 2005.
http://www.dot.ca.gov/newtech/docs/se_guidebook_ver1-12_14_05.pdf or
http://www.fhwa.dot.gov/cadiv/segb/files/segbversion2.pdf
14. Systems Engineering Handbook, International Council on Systems Engineering (INCOSE),
2007. http://www.incose.org/ProductsPubs/products/sehandbook.aspx
ITS Standards Guides
15. NTCIP Guide, information report 9001
http://www.ntcip.org/library/standards/default.asp?documents=yes&qreport=no&standard=9001
16. TMDD Guide v2.0, 2005, http://www.ite.org/TMDD/
17. Guide for Implementing IEEE 1512 using a Systems Engineering Process, 2008
http://standards.ieee.org/standardspress/titles/1512guide.pdf
Additional Websites for Related Information
18. USDOT, RITA, ITS- JPO, http://www.its.dot.gov/index.htm
19. USDOT, FHWA, Operations, http://ops.fhwa.dot.gov/
20. USDOT, FHWA, Freeway Operations and Management,
http://ops.fhwa.dot.gov/freewaymgmt/frwy_ops.htm
21. List of TMC Links, http://tmcinfo.blogspot.com/
22. TMC and other Practical Information, http://tmcpfs.ops.fhwa.dot.gov/index.cfm
23. USDOT Standards Program, http://www.standards.its.dot.gov/
47
TMDD standard v03 Guide
July 11, 2011
Functional Area Standards
DISCLAIMER: This list is not meant to be a complete survey of the currently available ITS standards and titles in the table
may not match as many standards are going through revisions. For detailed updated information on these standards, please visit
the Web sites provided in this table and also at the end of the guide.
Functional Area
Traffic Management
SDO: ITE and AASHTO
http://www.ite.org/
Focus is on traffic management applications
Incident Management
SDO: IEEE
http://www.ieee.org/portal/site
Focus is on incident management, public
safety applications, including emergency
management
Traveler Information
SDO: SAE
http://www.sae.org/
Focus is on traveler information
Transit Management
SDO: APTA
http://www.standards.its.dot.gov/StdsSumm
ary.asp?ID=411
Focus is on public transit applications
Archive Data User Service
SDO: ASTM
http://www.astm.org/
Focus is on planning data
World Wide WEB Consortium (W3C)
Traffic Management
SDO: NEMA, ITE and AASHTO
http://www.ntcip.org/
Standard Content
Standards for Traffic Management
Center-to-Center Communications
Standard Number
TMDD Standard
v3.0
Common Incident Management Message
Sets and Data Dictionary
1512.BASE
Traffic Incident Management Message Sets
1512.1
Public Safety Incident Management
Message Sets / Police / Fire / EMS
1512.2
Hazardous Material Incident Management
Message Sets / Commercial Vehicles
1512.3
Standard for Common Traffic Incident
Management Message Sets for Use in
Entities External to Centers
Data dictionary for Advanced Traveler
Information System (ATIS)
1512.4
SAE J2353
Message Set for ATIS
SAE J2354
Mayday
SAE J2313
Reduced Bandwidth
SAE J2369
Strings and Look-Up Table Messages
Location Referencing Message
Specification (LRMS)
ITIS- International Traveler Information
Converting ATIS Messages Standards
from ASN.1 to XML
APTA Standard for Transit Communications Interface Profiles, a single standard
that addresses 9 business areas.
SAE J2540
SAE J2266
SAE J 2540-2
SAE-J 2630
APTA TCIP-S-001
Version 001 3.0.3
Standards for the Archiving and Retrieval
ITS-Generated Data
ASTM E2259-03a
XML Schema for Part 1:Structure
C2C Naming Convention Specification
W3C
NTCIP 1104
48
TMDD standard v03 Guide
July 11, 2011
Web Links to ITS Standards Information
Information Topic
Web link (ctrl+click to follow link)
Organization
C2C Standards
C2C-TMDD
www.ite.org/tmdd
ITE
C2C -NTCIP
www.ntcip.org/library/documents
NEMA
C2C DATEX-part 2
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalog ISO
ue_detail.htm?csnumber=41362
C2F Standards
ITS (NTCIP) Field
Devices
www.ntcip.org/library/documents
NEMA
ATC Controller
http://www.ite.org/standards/atc/
ITE
Functional Area Standards
Standards Status
http://www.standards.its.dot.gov/default.asp
FHWA
Emergency
Management/TIM
http://grouper.ieee.org/groups/scc32/imwg/guide.pdf
IEEE
Traveler Information
http://www.sae.org/servlets/index
SAE
DSRC Standards
http://www.astm.org/, http://www.standards.its.dot.gov/
ASTM
http://www.leearmstrong.com/Dsrc/DSRCHomeset.htm
ITS Architecture
Standards Required
http://www.iteris.com/itsarch/
http://www.iteris.com/itsarch/html/standard/standard.htm
ITERIS
http://www.ite.org/education/clearinghouse/
Call ITE at 202-289-0222
ITE
Standards Training
Overview, C2C, DMS
and ATC/ASC
49
TMDD standard v03 Guide
July 11, 2011
APPENDIX-A
APPLICATION LEVEL PROFILES FOR CENTER-TO-CENTER
Purpose of this Appendix
This appendix provides additional information on the application level protocols that will be necessary to complete the TMDD-based implementation for the C2C system interface as shown in Exhibit
A-1.
TMDD-based C2C system interface can be implemented using the DATEX-based approach that uses
ASN.1 data concepts and the XML-SOAP-based approach with data concepts in XML representation. Both approaches will also require use of the application level protocols made available by the
NTCIP family of standards as shown in Exhibit A-1.
A summary of both approaches is also provided in table A-1 for general understanding of components. This discussion is followed by an overview of the NTCIP 2304 C2C AP-DATEX-ASN and
the NTCIP 2306 C2C XML application level profiles. Readers should also note that the C2C XML
approach is based on the Internet technology under Web services, and it is becoming a preferred way
of providing transportation information.
TMDD Implementation
DATEX-ASN .1 based
Implementation
C2C -XML based
Implementation
ISO 14817-ASN.1 Standard Data Concepts
Dialogs-Messages-Data Frames and
Data Elements
XML-Schema Data Concepts
Dialogs-Messages-Data Frames and
Data Elements
NTCIP 2306 AP-C2C- XML
Rules for Encoding of XML
Dialogs with WSDL
SOAP Encoded Messages
NTCIP 2304 AP-DATEX-ASN.1
Rules for Encoding of ASN.1
Dialogs and Messages
Exhibit A-1 TMDD Implementation
50
TMDD standard v03 Guide
July 11, 2011
Exhibit A-2 Center-to-Center Communications Approach Comparisons
(Source: NTCIP 9010)
Communications
Protocol
Data Dictionaries
DATEX-ASN
W3C-based XML
XML Direct Protocol
Protocol
Functional Area Data Dictionaries (TMDD, TCIP, ATIS, IM, ADUS, etc.)
Message Dialogs
ASN.1 Dialogs
Rules for Defining
Messages
ASN.1 (Abstract Syntax
Notation) e.g. MS-ETMCC,
TCIP, ATIS, IM, etc.
Encoding Rules For
Data Transmission
Application Protocol
(handshaking,
message framing,
etc.)
OER (Octet Encoding Rules)
Support Services
DATEX-ASN supports a
robust subscription-based
service and administrative
messages
Transport Protocol
TCP/IP
An approach based on WSDL (Web Services
Description Language) will be developed
XML Schema Language
SAE ASN.1 to XML Encoding Rules
XML is encoded as Unicode text
Functional area XML Schemas define valid tags
SOAP (Simple
XML Direct - FTP and
Object Access
HTTP for file retrieval
Protocol) over HTTP only.
for the W3C
Approach.
The WS-I’s Basic
None identified.
Profile defines a
mechanism to
support subscriptionbased messaging
DATEX-ASN ISO 14827
Note: DATEX-ASN stands for Data Exchange Using ASN.1 (ISO 14827 Part1 and 2)
51
TMDD standard v03 Guide
July 11, 2011
Overview of the NTCIP 2304 - Application Profile for DATEXASN (AP-DATEX)
General
Readers are directed to the NTCIP 2304 standard for full details on requirements. In this section, only brief discussion on key concepts is provided.
Introduction
In this approach to C2C implementation, centers serving different functional areas such as traveler
information or incident management can utilize messages and understand content without ambiguity
because all concerned parties have agreed on the use of harmonized TMDD messages. These fixed
messages are constructed using functional area data dictionary elements and are stored by centers. A
data packet containing the DATEX Protocol header, as per ISO 14827-1, along with the message is
transmitted using an Internet transport mechanism such as the TCP/IP protocols. DATEX protocol is
encoded using NTCIP 1102 Base Standard called Octet Encoding Rules (OER). Centers must log on
and be authenticated to exchange information that contains fixed messages.
DATEX is developed specifically for ITS applications and is not widely deployed in the United
States. This protocol was pioneered in Europe. Those readers who are accustomed to previous versions of the TMDD standard terminology should note that the newly revised TMDD v3.0 standard is
based on the ISO 14817 data concept structure.
TMDD is a functional level data dictionary for traffic management user service. This dictionary covers the most basic needs of traffic management. There is as a separate dictionary for traveler information systems, incident management, and transit. However, TMDD data elements and messages are
also utilized by other centers and not duplicated by other own application standards.
DATEX has been adopted by ISO as an international standard. DATEX is based on the following:
• ISO Standard 14827 – Parts I and II
ISO 14827 consists of the following parts, under the general title Transport Information
and Control Systems (TICS) – Data interfaces between centers for Transport Information
and Control Systems:
Part 1: Message Definition Requirements defines how to define end-application messages that are to be exchanged between centers for TICS. This definition has been designed
to be relatively generic to the selected protocol (e.g., DATEX-ASN, CORBA, etc.).
Part 2: DATEX-ASN, ISO 14827-2 provides the specification of the Data Exchange protocol in ASN.1 (DATEX-ASN) used to exchange data between central systems.
52
TMDD standard v03 Guide
July 11, 2011
• NTCIP 2304 – Application Profile defines ISO 14827 options to be used in the United
States. It provides users a Profile Requirements List (PRL) used in the system design.
Operational Features of DATEX
DATEX application begins with a desire by a center to communicate with another center known to
each other. When both entities have logged on, DATEX will utilize standard messages (already
known to both sides) in a series of conversations or dialogs.
A requesting center will initiate a request for one time or periodic information to a responding center, which will generate a response using fixed messages. DATEX will transport those messages and
response using a combination of TCP/IP and DATEX packets.
Socket Concept in DATEX
DATEX is a tightly coupled protocol application that utilizes a TCP (Transmission Control Protocol)
based connection-oriented exchange (both centers must log-on and maintain connection). Both entities and centers by convention are assigned Port 355 to deploy DATEX in a point to point connect
with an IP (Internet Protocol) address. Under a socket mechanism, two processes agree on the same
communication protocol (DATEX) and exchange their IP addresses and port; they can communicate
by reading and writing on their own socket, like using a simple file. DATEX guarantees the message
delivery or produces an error.
Uniqueness of DATEX
DATEX is a unique protocol to the transportation industry, and its use is not widely made in transportation applications. There is a lack of development tools and lack of mass market. It also requires
manual reconfiguration.
Deployment Experiences
There are few C2C deployments in the United States based on DATEX and some of the old implementation has also migrated to XML. Experience in implementing DATEX is thus very limited. In
recent years, integrators have turned to XML approach for ITS applications such as C2C communications and regional traveler information systems.
Users are also directed to the NTCIP Guide, NTCIP 9001 v04 for further discussion on DATEX and
XML comparison.
53
TMDD standard v03 Guide
July 11, 2011
Overview of the NTCIP-2306 Application Profile for XML in
ITS Center to Center Communications (AP-C2C XML)
Background
Readers are advised to refer to two documents published by the NTCIP family of standards on the
C2C XML for details on concepts, examples, and specification:
•
NTCIP-9010 XML in ITS Center-to-Center Communications provides comprehensive information on SOAP and XML, and recommends two approaches to C2C XML: XML Direct
for simple file transfer and XML-SOAP for more complex needs.
•
NTCIP 2306 Application Profile for XML Message Encoding and Transport in ITS C2C
Communications provides a set of rules defining how the actual SOAP standard is to be used
in the realm of ITS. The NTCIP 2306 C2C XML is supported with two mechanisms to implement TMDD:
¾ WSDL/SOAP: This solution supports request/response and subscription services, where
a center can make a one-time request to another center that results in a standard message
being sent automatically whenever data changes. It also supports commands, or action
requests, being sent to another center. In this example, messages sent in response to a
subscription are supplier initiated (the center providing the data initiates the exchange),
while commands sent in the other direction are consumer initiated. The various data
frames found in message sets to support different styles and content for subscriptions fits
well with this paradigm.
¾ XML Direct: This allows a center to offer information to other centers by simply making
it available as an XML file (document) at a known Web address. The file contains one or
more TMDD messages encoded using XML. The center providing the information updates this file either periodically or when data changes (e.g., a new event occurs). Other
centers retrieve the file using plain HTTP or File Transfer Protocol (FTP) whenever they
need such information, or retrieve it regularly in order to monitor it for changes. All such
exchanges are always data consumer-initiated. Using XML Direct, a center (data provider) can make information available, and other centers can retrieve it using relatively simple software services. This represents a significant cost saving for centers that do not
need to support complex messaging. It is suitable for many legacy practices found in deployments today.
Why use XML for C2C?
The appeal of the XML approach to C2C communications is attributed to at least the following:
54
TMDD standard v03 Guide
July 11, 2011
•
•
•
•
•
In recent years, XML has acquired a wide support from IT vendors (software tools). Webbased communications are very broadly supported in the general computing and information
technology industry (some would say, the “Internet is here to stay”).
XML is everywhere: XML has received broad public sector agency and ITS vendor support.
Also within transportation agencies information technology departments have adopted XML
platform for multiple services.
XML schema and general approach has good definitions and implementation support for data
elements, messages, dialogs and underlying transport protocols.
The Internet is expanding commercial web services with XML and related protocols in a
common format.
On the challenges side, XML is text based encoding and bandwidth oriented; however, from
a C2C perspective such issues (including latency) are not found to be formidable.
Applicable NTCIP 2306 Standards
NTCIP 2306 standard requires the following four standards by the World Wide Web Consortium
(W3C) that are applicable to C2C XML implementation:
•
•
•
•
XML Schema 1.0
Web Services Description Language (WSDL 1.1)
Simple Object Access Protocol (SOAP 1.1)
Hypertext Transfer Protocol (HTTP 1.1)
Each of these four standards is briefly discussed below details on requirements for each is also provided in NTCIP 2306 and general overview in NTCIP 9010 documents).
XML Schema
As a software and hardware independent tool to carry information, Extensible Markup Language
(XML) is designed to structure, store, and transport (carry) data. (Hypertext Markup Language
(HTML) on the other hand is designed to display data). XML encoded information is a plain text
comprised of English-language characters, or text.
This is different from many encoding schemes that encode to a binary format. XML is selfdescriptive and employs user defined tags. Both sending and receiving applications must use the
same tags and tag hierarchy to interpret the content of messages. Tag names and hierarchy are defined in an XML Schema. (TMDD and other ITS functional areas deploy XML Schema as per SAE
J2630 standard). XML Schema is becoming the preferred method of defining the grammar for an
XML document type, replacing the original method called Document Type Definition (DTD).
The following terminology used in XML Schema is highlighted:
55
TMDD standard v03 Guide
July 11, 2011
• Document: Once information is described (encoded) using XML, it is called a document.
An XML document is comprised primarily of elements.
• Element: An element is delimited by tags. Usually, a tag is comprised of the name of the
element it delimits, enclosed between a pair of angle brackets (“<” and “>”). Tags usually
come in pairs—a start-tag and an end-tag. The element name in the start and end tag are
identical except that the latter has a forward slash (“/”) at its beginning. A start-tag may
optionally include attributes of the element. An attribute name is followed by an equal sign
and a value for that attribute.
• Content: The content of an element is the text that appears between its start-tag and its endtag. Elements may be nested—the content of an element can include other elements. Nesting
allows for complex information structures. In the above example, nesting is used to show
that an element (a piece of information) called “dmsInventory” is made up of other elements
(organization information, device-id etc.). The level of nesting may continue to any depth.
• Extensible: An XML schema is extensible, that is additional element types can be added at
any time in the future without invalidating earlier versions of the schema.
• XML parser: the XML standard requires software that reads and interprets an XML
document (called an) to ignore any tags (and elements thus delimited) that are not included in
the version of the schema currently used by that parser.
• The eXtensible style sheet language (XSL): XSL can be used to enable a computer to
automatically translate the information content of an XML document into another formatted
document (must be in text format), including XML.
• Encoding: Unlike most computer encoding standards (e.g., Basic Encoding Rules-BER used
in DATEX or HTML used for Web pages) there is no single set of encoding rules for XML.
Instead, XML encoding rules are customized for different applications. For ITS applications,
XML schema developed by SAE J2630 has been agreed upon by the SDOs.
WSDL
A Web service is traditionally defined by the W3C as "a software system designed to support
interoperable machine-to-machine interaction over a network.” It has an interface described in a
machine-processable format (specifically Web Services Description Language WSDL). Other
systems interact with the Web service in a manner prescribed by its description using SOAP
messages, typically conveyed using HTTP with an XML serialization in conjunction with other
Web-related standards." (http://www.w3.org/TR/ws-gloss/).
ITS standards developing organizations (SDOs) have seized the vast resources of the Internet technologies to access transportation information from a center to another point within the infrastructure.
The Internet infrastructure contains telecommunications mediums (at plant level), communications
protocols (at subnet and transport levels), and Web resources (at center system operation term level),
and it allows access on a 24/7 basis without human intervention. Thus it is considered an interoperable network of networks. In this context of the Internet, a Web service enables a center to make information (about any ITS applications) it has to whoever wants it (other centers or external centers)
in real time or near real time.
56
TMDD standard v03 Guide
July 11, 2011
Exhibit A-3: SOAP Framework
For a Web service to occur, the “providing” center publishes a
SOAP Message
Web Services Description Language (WSDL) document that
contains rules or standards to be followed by the “requesting
SOAP Envelope
center.” WSDL uses XML format for describing network services as a set of endpoints operating on messages containing
SOAP Header
either document-oriented or procedure-oriented information. In
essence, WSDL describes: what the service does (description),
Header Block
how to use it (method signatures), and where to find the service.
WSDL describes the service point, or exposes it to outside users. It helps ensure interoperability at the service description
layer) a big concern of the C2C operations. The NTCIP 2306
SOAP Body
C2C XML contains WSDL format for XML over HTTP and
also for FTP.
POT-Plain Old Telephone Service
Body Block
SOAP
SOAP is a lightweight (simple) XML-based simple communication protocol for exchanging structured information between
distributed applications over native Web protocols, such as
HTTP. SOAP specifies the format that XML messages should
use (in the case of ITS by referring the XML schemas of each
standard); the way in which they should be processed; a set of
encoding rules for standard and application-defined data types;
and a convention for representing remote procedure calls and
responses. Exhibit A-3 shows how SOAP acts as wrapper of
messages with just a header and a body of messages. SOAP only has request-response and notification interaction. The side bar
shows how other protocols work together to deliver messages
across wire lines (POT-Plain Old Telephone Service) or wireless mechanisms.
Exhibit A-4: Protocols Stack
Standard
API
Standard
user
interface
SOAP
Standard
network
protocol
HTML
XML
HTTP
TCP/IP
Ethernet
POTS
Wireless
From an ITS-centric point of view, SOAP represents the flavor of XML used to bind the messages
developed by SDOs into specific service points on the Web and the associate messages together to
form complete dialogs. The messages themselves, the ones found in TMDD, ATIS, TCIP and IM, are
already well defined in XML by the concerned SDOs and expressed in schema files today. SOAP
does not revise or change that, it simply binds them together for use in onward journey. Since the
SOAP says nothing about the content of the message, the sender and the receiver must understand the
message for themselves. In ITS functional areas, this is an important criterion for interoperability.
It should be also noted that SOAP and WSDL are often discussed as if they were the same “package.”
(WSDL relates to dialogs, while SOAP relates to messages). Without SOAP, different ITS deployments would expose the same messages in differing and incompatible ways. SOAP/WSDL binding
will minimize exchange problems. The C2C context operations strive to achieve interoperability
57
TMDD standard v03 Guide
July 11, 2011
among centers and this common format of SOAP/WSDL binding is step in right direction for all ITS
functional areas.
HTTP
Exhibit A-4 and A-5 illustrates where and how HTTP is deployed. HTTP is a request/response
standard typically used in client-server computing. The client is an application (e.g. Web browser)
on the computer used by an end-user; the server is an application running on the computer hosting
the web site. For ITS deployments, the NTCIP 2306 provides for the following three sub profiles.
• Operations are called using
SOAP/XML
• Results are returned using
SOAP/XML
• Operations are described by
WSDL in XML
• HTTP is a ‘mailman’ for
messages.
HTTP
HTTP
For example, an external center may request a status of a traffic accident on a highway from a TMC in a
different jurisdiction in the region. For such a dialog to take place, both centers must adopt similar set up
Exhibit-A-5 XML Messaging Using SOAP
1. SOAP over HTTP. Using SOAP encoded messages over the hypertext transfer protocol
(HTTP), centers will be able to describe and deploy center interfaces that support the requestresponse and subscription-publication message patterns.
2. XML over HTTP. Using XML encoded messages over the HTTP, centers will be able to
describe and deploy interfaces that support the request-response (via HTTP POST) and requestonly message patterns (HTTP GET). HTTP POST is suitable for the exchange of messages
(request-response), while the HTTP GET is suitable for the request of an XML document by
name.
3. XML over FTP. Using the file transfer protocol (FTP), centers will be able to describe
interfaces that support XML document requests by name.
58
TMDD standard v03 Guide
July 11, 2011
APPENDIX-B
BASICS OF CENTER-TO-CENTER COMMUNICATIONS
Purpose of this Appendix
It was determined during the preparation of this guide that certain basic definitions and basic concepts used in the C2C context are useful in gaining insight into the system interface design for C2C.
Due to various reasons, this information was not presented in the main body of the guide. This additional information is retained to serve as an unedited tutorial.
Background
How do two centers with different systems, functions, and ownerships communicate with each other
in real-time without human intervention?
Historically, system operators have relied mostly on means such as verbal communication with telephone calls, backed up by fax messages and mobile devices, including proprietary system-based solutions that used non-standardized data in the local traffic management systems. Such methods, although practical and useful, limit agencies’ efforts to improve transportation services across region in
real time.
However, in recent years, the Standards Development Organizations (SDOs) and U.S. Department of
Transportation efforts have produced a range of Intelligent Transportation Standards (ITS) standards
to facilitate communications capabilities needed to enhance interagency coordination and to promote
collaboration.
The answer to the opening question above lies in the topics addressed in this guide. It has focused on
the center-to-center (C2C) context and discussed TMDD toolkit and related standards that help in
achieving capability for C2C communications in real-time using a C2C system interface.
In this appendix some additional useful information is presented in no particular order.
Terminology Used in C2C Communications
The following definitions are presented in the C2C context:
• Data: A representation of facts, concept, or instructions in a formalized manner suitable for
communication, interpretation, or processing by human or by automatic means.
59
TMDD standard v03 Guide
July 11, 2011
• Metadata: meta (pronounced MEH-tah in the U.S) means an underlying definition or description) attributes of data concepts to be used in a functional area data dictionary such as
the TMDD. ISO 14187 is a meta standard.
• Information: The meaning that is currently assigned to data by means of conventions applied to those data.
• Communications: Information transfer among users or processors according to agreed conventions and a branch of technology concerned with the representation, transfer, interpretation and processing of data among persons, places and machines. Further, the meaning assigned to the data must be preserved during these operations.
•
Data Dictionaries: an organized and constructed (electronic data base) compilation of descriptions of data concepts that provides a consistent means for documenting, storing and retrieving the syntactical form (i.e., representational form) and the meaning and connotation of
each data concept (ISO 14817).
For example, TMDD for traffic management, TCIP for transit applications, IEEE 1512 for
emergency management and SAE J2454 for ATIS are some of the data dictionaries that are
deployed in the ITS domain areas.
Definition of Advanced Traffic Management System (ATMS)
The IEEE 1512 Base standard defines ATMS as: the hardware and software decision support system
that provides the traffic management center its operational functionality. An ATMS system typically
manages field devices, collects multiple formats and types of data, generates automated response
plans, and manages the dissemination of information to interested parties. In a local Intelligent
Transportation System (ITS) network environment, the ATMS is an intelligent node and often is the
central node for ITS functions. (Note: traffic management is a major subsystem identified by the National ITS Architecture, and TMC is a focal point of ATMS operations).
Definition of Center
The TMDD standard defines a center as a connection point on a network capable of exchanging
messages with other centers. More practically, a center can range in complexity from large multicomputer environments to a simple laptop, and may be associated with a similar wide range or span
of command and control in any given local government agreement or incident deployment.
The terminology used to describe a center, as an entity engaged in the C2C information exchange
process, is defined as:
• Traffic Management Center (TMC): A center or central facility (focal point) charged with
operational tasks managed through a system or subsystems. A TMC has traffic management
60
TMDD standard v03 Guide
July 11, 2011
related information that usually relates to road network, field devices and resources, and current event information of interest to other TMCs or centers.
• Owner Center: An owner center is a center, such as a TMC, that provides information developed or stored within it (e.g. event information) to another center and/or has direct control
of field devices. In the context of the most common dialogs used by this standard, the owner
center publishes information or provides responses to a request from an external center.
• External Center (EC): An external center is a unique combination of an organization name
and center name that request information from another center (a TMC for example).
Communications Standards Categories
Standards development organizations (SDOs) have addressed the ITS communications needs in two
categories—C2C and C2F—and have produced standards for both as shown in Exhibit B-1.
C2C
TMC
C2F
Transit Dispatch Center
Exhibit B-1 Communications Categories in ITS Applications
Center-to-Field (C2F) communications protocol standards are used to facilitate remotely control
and maintain the operation of the transportation devices installed in the field (roadways). A common
protocol means that the field devices are interoperable between vendors (depending on the design of
the central system).
For example, the NTCIP 1203 DMS standard brings a common protocol to the table to support
command and control of the DMS from multiple vendors and allows the display of messages to inform motorists on current traffic conditions on a particular highway.
Please note that this guide does not deal with C2F standards and the reader is directed to the NTCIP
Guide for that domain (Reference document # 9001 is available at www.ntcip.org).
61
TMDD standard v03 Guide
July 11, 2011
Center-to-Center (C2C) communications standards are used to exchange information between various types of operations centers (systems) responsible for managing transportation services within a
region.
For example, a center may request information about a location or status of a device located in an
adjoining jurisdiction using C2C communications. The information exchange among centers is carried out by the interface supported with one of the Applications Profiles: AP-DATEX or by AP-C2C
XML.
Role of the TMDD Standard
Exhibit B-2:
C2C Functions
What does the TMDD standard provide?
A fair question to which there is a short answer: interoperability
among agencies. This remains an ultimate objective of the C2C and
on a larger scale, a national priority. (In recent years we have
painfully recognized that although expensive computer systems are
built with good intentions, in times of need, they are not able to “talk
to each other.” This is opposite of interoperability).
TMDD Addresses Needs for:
Providing Road
Network Data
Sharing Event
Information
As previously defined, interoperability is defined as the ability of
two or more systems or components to exchange information and
use the information that has been exchanged. The recent U.S.
transportation policy and especially the regional ITS architecture
efforts around the United States have placed a significant stress on
agencies to aim for regional interoperability. Modern TMC central
systems integration efforts aim at system to system interoperability
and operational interoperability among agencies (e.g. standard
operating procedures).
Providing Shared
Control of Devices
Sharing
Data for Archiving
For the day-to-day concept of operations needs, interoperability is key in achieving the full potential
of the ITS capabilities and assets located across boundaries.
For example, a seamless data exchange would allow 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 data has developed data concepts based on such anticipated needs arising from
real-world operational scenarios. This operational focus has resulted in ability to carry out request/response conversations (dialogs) using appropriate messages across jurisdictional and system
boundaries. This is what the TMDD brings to the table.
The TMDD standard’s contribution to strengthen interoperability achievements can be summarized
in the following three ways:
62
TMDD standard v03 Guide
July 11, 2011
•
•
•
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.
C2C Benefits
The key potential benefits resulting from the C2C system interface deployment are:
•
•
•
•
•
•
•
•
•
•
•
Improved regional integration and resulting interoperability
Improved collaboration and cooperation between jurisdictions
Ability to provide event information to other centers
Ability to provide traffic and travel data to other centers
Improved coordination of operations within the defined C2C network
Capability to remote control and monitoring of traffic control devices
Support Integrated Corridor Management and other ITS projects needs
Support data collection across domains and applications
Decreased emergency response time, which reduces the impact to traffic and reduces the
number of secondary crashes
Cost savings to emergency responders as the response equipment is better organized
Improved response across jurisdictions provided by the real-time information exchanges, including reduced delays as traffic signals are optimized across jurisdictional boundaries
All of the above benefits result in reduced delay and improved mobility for the traveler in a
seamless manner.
NTCIP Framework
When discussing either C2C or C2F communications, it is helpful to view a full stack of the ITS
standards along with the supporting lower layer Internet standards as seen in Exhibit B-2 NTCIP
Framework.
The NTCIP Framework is organized to show the content of the functional area information standards
such as TMDD, and processing at various levels of the communication stack, including commonly
used communications protocols standards. These information level standards represent the domainspecific functionality of the environment to be implemented (such as traffic management by TMDD)
and define the meaning of data and messages. These information level standards are above the traditional ISO seven-layer model.
63
TMDD standard v03 Guide
July 11, 2011
Functional Area Data Dictionaries
Information
Level
C2C Data Dictionaries (TMDD, ATIS, TCIP, IM)
C2C Messages
Application
Level
Transport
Level
Subnetwork
Level
Plant
Level
C2C XML (2306)
FTP (2303)
Data Objects
TFTP (2302)
Fiber
Coax
Dynamic Objects
SNMP (2301)
STMP (2301)
T2/NULL (2201)
UDP/IP (2202)
Ethernet (2104)
PPP (2103)
Dial-Up Telco
Files
DATEX (2304)
TCP/IP (2202)
NTCIP Data Dictionaries (1200 Series)
PMPP (2101 & 2102)
Wireless
Twisted Pair
Leased Line
Exhibit-B-3 NTCIP Framework
(Source: NTCIP 9001 v4.04 Information Report-Guide, http://www.ntcip.org/library
Note small number shown in Exhibit is ITS standards document numbers)
TMDD’s Relationship to NTCIP C2C Standards
The C2C system interface development for the traffic management
functional area rests on two key standards, as shown in Exhibit B4):
Exhibit B-4 TMDD’s
Relationship to NTCIP
C2C System Interface
1. Language-Dictionary: TMDD Standard v3.0
2. Application Profile: NTCIP C2C
As shown in Exhibit B-3, as information level data dictionary
standard, the TMDD standard (other separate dictionaries standards
include, IEEE 1612, ATIS, and TCIP) 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.
TMDD
v3.0
NTCIP
C2C
NTCIP
2304
NTCIP
2306M
Thus TMDD is a language, not an interface itself. Once the TMDD data content is designed
(dialogs-messages) and encoded the exchange is done through application level common protocol to
64
TMDD standard v03 Guide
July 11, 2011
centers as shown in the last two boxes in Exhibit B-3.
The NTCIP framework achieves this objective of providing a common protocol in two ways:
• 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.
• Another application profile, NTCIP 2306 C2CXML 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).
Thus the developers are presented with flexible approach to choose TMDD data concepts contain
(either ASN.1 or XML based) with a matching application profile as summarized in Exhibit B-5.
Exhibit B-5 Summary of TMDD Application Profile Specific Content
Application
Profile
AP-DATEX
(NTCIP 2304)
Data Concept
Representation
ASN.1
Comment
ISO 14817 provides a general specification of data concepts using ASN.1,
and specific examples of ASN.1 representations for data element, data
frame, and message.
AP-C2CXML
XML Schema
XML Schema is used to define data elements, data frames, and messages.
(NTCIP 2306)
and WSDL
The SAE-J2630 rules for translation of ASN.1 to XML will be used to
develop the resulting TMDD XML Schema.
WSDL (Web Services Description Language) will be used to describe the
TMDD Dialogs.
(Readers interested in details on application profiles are directed to consult Appendix-A)
C2C Naming Conventions Used by C2C
C2C naming conventions deals with the question: How do we know who is what and where on a
communication network? Which Entity or Class is referenced?
As shown in exhibit B-6, the C2C naming conventions are an orderly way to deal with such things
on a communication network. A communication is defined as a collection of interconnected equipment that provides a data communication service for devices caked nodes, often computers attached
to the equipment.
The NTCIP 1104 is a specification standard that provides a mechanism for naming C2C object names
uniquely. That standard requires C2C object (entity) names to comprise seven parts: country ID,
state ID, owner ID (Agency Name), center ID, entity kind, entity type and entity instance, as follows.
The example shown in the box illustrates this specification. (Note: the current NTCIP 1104 v1.09
65
TMDD standard v03 Guide
July 11, 2011
has changed Entity name to Object Name in the above discussion). Each part of the name is a variable-length character string, and a slash character separates the parts.
Exhibit B-6 Naming Conventions Used by C2C
Entity Name = {CountryID}/{StateID}/{OwnerID}/{CenterID}/{EntityKind}/{EntityType}/{EntityInstance}
US/CT/CDOT-D1/Bridgeport_Ops_Center/Device/DMS/CMS12_i95NB-jeffrey
In this example name, the owner has chosen to form the ObjectInstance part by combining the type of
dynamic message sign (in this case a changeable message sign – could have been a portable message sign
or a blank-out sign for example), the agency’s numerical number for this CMS (in this case #12), and the
sign’s location (in this case northbound Interstate 95 near Jeffrey Road).
The sign number alone, the location alone, or any other not-too-long and locally unique (for that device
type) string would also be a valid choice for the ObjectInstance part. Entity or object kinds include Device,
Event, Center, Vehicle and Person. Device entity types include CCTV Camera, Dynamic Message Sign,
Environmental Sensor Station, Lane Closure Gate, Highway Advisory Radio, Ramp Meter, Traffic Detector
and Traffic Signal.
ITS Deployments with C2C and C2F Standards
In the past decade or so, the accelerated efforts by the FHWA oversight program and the various
SDOs in consultation with the user community have resulted in three coordinated and generally
consistent outcomes: ITS architecture, ITS standards, and ITS deployment program. These elements
are structured to serve the domain-specific applications and use common ITS standards to address
the real-world applications. (Readers are reminded that these elements are taken together to build a
successful ITS application within a project or program). A reference point in the ITS deployments
to the National ITS Architecture and common standards have now emerged. The system implementers are further aided by the SEP to guide them in maintaining the operational needs throughout
the project life-cycle process.
The SDOs have taken great care in accommodating in a flexible manner the diverse needs of the different types of centers. For example, ITE and AASHTO efforts have resulted in the TMDD standard
that now can be integrated into regional ITS deployments. Similarly, as shown in Exhibit B-7, multiple ITS functional areas use domain specific data dictionaries and import additional data elements
and messages from each other to complete their regional C2C system interfaces.
For example, an advanced traveler information system (ATIS) service provider (External Center)
must also use part of the TMDD interface to receive real-time information from a freeway management system (TMC) in the region. Similarly a statewide 511 system will interface with regional systems with a TMDD interface in C2C communications environment to receive real-time travel information. Another example in Exhibit B-7 shows that with a prior agreement, a transit dispatch center
66
TMDD standard v03 Guide
July 11, 2011
may communicate to a TMC for requesting a traffic signal priority for their buses or may request
traffic flow information on a particular roadway. To this end, both centers must use TMDD for massages and also C2C protocol.
EC
EC
TMC
EC
Exhibit B-7 Communications Categories in Multiple Domain Applications
(Source: NTCIP 9001 v04 Guide)
67
TMDD standard v03 Guide
July 11, 2011
Functional Area Data Dictionaries and the National ITS
Architecture
The TMDD standard and other domain-specific standards are the result of the U.S. DOT ITS
Standards program that promotes the use of the standards for achieving interoperability, including
the IEEE 1609 Family of Standards for Wireless Access in Vehicular Environments (WAVE)
currently under development (See Exhibit B-8). The TMDD standard serves the needs to support the
necessary data exchanges between these centers. These specialized data dictionary standards provide
the rules for developing and defining domain-specific data concepts used in the ITS. Applications
that use such data dictionaries allow unambiguous data transfer (and its interpretation) between and
among the various ITS functional areas (e.g. traffic management, traveler information, and transit
management). They also enable the reuse of data concepts developed by a single functional area by
all other ITS functional areas.
ATIS
Standards
TMDD
Standard
IEEE 1512
Standards
TCIP
Standards
NTCIP C2F
Communications
Protocols
NTCIP C2F
Devices
Objects
WAVE Standards
DSRC Standards
68