Build intelligent transportation systems with the Traffic Management Data Dictionary standard

IBM's Intelligent Transportation product, building on the IBM Intelligent Operations Center, is a valuable tool to help cities manage traffic with visibility and transparency of the transportation network. A critical integration point of IBM Intelligent Transportation is the gathering of traffic and event data from other traffic center systems and field devices based on the increasingly popular Traffic Management Data Dictionary (TMDD) standard. This article gives an overview of the TMDD standard and explains how these standards are used in IBM's new IBM Intelligent Transportation product. For traffic centers that have not implemented TMDD, this article introduces a publicly available asset to help cities and IBM business partners implement it. In this article, learn about the TMDD standard and how the new Traffic Management Owner Center Simulator helps with implementation, including how to integrate with IBM's IBM Intelligent Transportation.


Mr. Christopher M. Laffoon (, Software Engineer, IBM

Christopher M Laffoon author photoChris is an industry solution standards engineer in the Transportation and Education industries. He has valuable development experience with various industry messaging standards (including TMDD and DATEXII), XML, XML Schema, and JavaTM technologies.

Dr. Magda Mourad (, Distinguished Chief IT Architect, IBM

Photo of Magda MouradDr. Magda Mourad is a Certified Distinguished Chief IT Architect with IBM Software Group’s Industry Solutions team. She is the architect of IBM Intelligent Transportation product. She joined IBM in 1989 as a Research Scientist at the T.J. Watson Research Center, where she became a Manager then CTO of the Digital Media business unit in 2005. She also went on two international assignments in Europe and the Middle East. She is currently chairing the IEEE working group that developed a Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies.

15 July 2011

Editor's note: This article will be updated to include information on where you can download the Traffic Management Owner Center Simulator when the Simulator is available.


The growing Intelligent Transportation Systems (ITS) industry is becoming increasingly important across the globe as cities try to reduce congestion, reduce emissions, and offer better services to citizens. In the ITS industry, open standards play a critical role in helping government organizations to:

  • Save on costs when integrating solutions
  • Reduce the risks of building and procuring new systems that can solve problems
  • Build a common platform to enable future innovation

There are plenty of ITS standards worldwide; the challenge is to select the standards that will have market penetration and widespread success. Two important standards that are gaining traction in the United States and across the world are: the US National ITS Architecture and the Traffic Management Data Dictionary standard. In this article, explore how these standards are used in IBM's new IBM Intelligent Transportation product. Additionally, learn how the Traffic Management Owner Center Simulator, a valuable new asset, helps you design and implement systems based on these standards.

US National ITS Architecture

The United States Department of Transportation defined a common framework, called the US National ITS Architecture, that logically and physically describes ITS. The common framework helps practitioners, engineers, and product developers to plan, define, and integrate intelligent transportation systems.

The National ITS Architecture describes ITS as interrelated systems that work together to deliver transportation services.

  • Subsystems, which are individual pieces of the overall ITS, perform specific functions, such as managing traffic, providing traveler information, or responding to emergencies. Subsystems can be associated with particular organizations, such as departments of transportation, information service providers, or public safety agencies. Subsystems include center systems, field components, vehicle equipment, and traveler devices that participate in ITS. Figure 1 shows an example.
  • Information flows define information that is exchanged between subsystems, such as traffic information, incident information, or surveillance and sensor control data. They depict ITS integration by illustrating the information links between subsystems. In ITS, integration is both technical and institutional. The system interfaces that are defined require cooperation and shared responsibilities by the owners and operators of each participating system using standards protocols (such as TMDD).
  • The physical architecture of the National ITS Architecture partitions the functions defined by the logical architecture into classes, and, at a lower level, subsystems, based on the functional similarity of the process specifications and where the functions are performed. A high-level representation of the physical architecture is shown in Figure 1.
Figure 1. ITS high-level architecture
Diagram showing the various components of the architecture including fields, centers, and vehicles.

In the physical architecture there are 21 subsystems, which are distributed among four classes: Traveler, Center, Roadside, and Vehicle. The 21 subsystems represent a partitioning of functions intended to capture all anticipated subsystem boundaries for the present and years into the future.

The IBM Smarter Planet initiative is introducing new products, including IBM Intelligent Transportation v1.0, that are conforming to the National ITS architectural subsystems and information flow definitions. The next section provides an overview of IBM Intelligent Transportation.

IBM Intelligent Transportation

IBM Intelligent Transportation conforms to the National ITS Architecture, and follows the ITS common structure for the design of an intelligent transportation systems framework. The IBM Intelligent Transportation architectural design was developed around this framework. IBM Intelligent Transportation is tailored to meet the needs of the end user while maintaining the benefits of a common architecture.

"Center" subsystems deal with the functions typically assigned to public or private administrative, management, or planning agencies. IBM Intelligent Transportation implements the center subsystems highlighted in green in Figure 2, which include roadway information and reporting, traffic management, archived data management, and core services (such as administration, authentication, and authorization).

Figure 2. IBM IBM Intelligent Transportation high-level architecture
IBM IBM Intelligent Transportation High Level Architecture Diagram

Traffic Management

The Traffic Management subsystem consists of traffic surveillance and managing events or incidents.

Traffic surveillance
Processes traffic data and provides basic traffic and incident management services through the Roadside and other subsystems. All pre-processed data about vehicles passing through the surface street and freeway network is collected by processes. The data is then sent to processes that distribute it to other facilities and load it into the current and long-term data stores. The data in these stores, plus weather and incident data, is used by processes to produce an analysis. (In future releases, a predictive model of future traffic conditions will be produced.) The results of this process, and the data stored by processes, are available for display by traffic operations personnel and the media.

The processes that make up the Provide Traffic Surveillance facility within the Manage Traffic function:

  • Store and manage processed traffic data
  • Display and output traffic data
  • Exchange data with other traffic centers
  • Analyze, correlate, and report traffic data
Manage events/incidents
Provides the processes that make up the Manage Incidents facility within the Manage Traffic function. These processes manage the classification of incidents and implement responses when they actually occur. The facility will:
  • Store, manage, and categorize traffic events static data
  • Provide operator interfaces for events
  • Provide traffic data analysis for traffic events
  • Review and manage events data

The events management processes divide events, or incidents, into three types: possible, predicted, and current data. For example, planned events could include special events, sports events, and maintenance and construction activities. Current incidents might include traffic accidents, natural disasters, and incidents caused by the effects of the weather.

Archived Data Management

The Archived Data Management subsystem collects, archives, manages, and distributes data generated from ITS sources for use in: transportation administration, policy evaluation, safety, planning, performance monitoring, program assessment, operations, and research applications. Key services of the Archived Data Management subsystem include:

  • Manage archive data administrator interface
  • Manage Roadside data collection
  • Get archive data
  • Store and manage archive traffic data
  • Analyze archive
  • Prepare reporting inputs

Traffic Management Data Dictionary standard

A second important, and popular, open standard in the ITS industry is the TMDD standard from the Institute of Transportation Engineers (ITE). The TMDD standard is in alignment with the US National ITS Architecture, so it uses the same logical and physical concepts in its data model and messaging specifications. TMDD v3, released in 2008, defines the data concepts for traffic data, traffic metadata, traffic network devices, events, and archival data. TMDD also defines a set of messaging patterns, called dialogs, that can be used in center-to-center (C2C) communication to transfer this type of traffic management data from one system to another.

Though TMDD doesn't specify a particular format for traffic management data or communication protocols, the emerging traffic data format and protocol is the NTCIP 2306 "Application Profile for XML in ITS Center to Center Communications" specification. This specification defines how the XML should be formed and also defines a common Simple Object Access Protocol (SOAP) over HTTP communication profile that can be leveraged across various ITS standards. To support the NTCIP 2306 way of using the TMDD specification, ITE published a set of XML schemas and a base WSDL file to give implementers a starting point for building interoperable systems.

In the C2C pattern of communication, TMDD defines the abstract interface between an Owner Center and an External Center. The Owner Center is the organization or system that is capturing and processing the raw traffic and event data from the field (and thus owns that information). The External Center is the organization or system that is interested in receiving traffic and event data from the Owner Center, as shown in Figure 3.

Figure 3. External Traffic Management Center communications environment (source: TMDD standard documentation)
Flow chart starting with ec operator moving with center-to-center messages moving to oc or tmc operator.

The message exchanges, or TMDD dialogs in this case, between an External Center and an Owner Center are built on three generic patterns: request-response, subscription, and publication dialogs. Figure 4 shows the request-response dialog.

Figure 4. Generic TMDD request-response dialog
Flow chart with external center on left and owner center on right with msg request and responses going back and forth.

Figure 5 shows the subscription dialog.

Figure 5. Generic TMDD subscription dialog
Flow chart with external center on left and owner center on right with msg_subscription and msg_confirmationreceipts going back and forth.

The publication dialog is shown in Figure 6.

Figure 6. Generic TMDD publication dialog
Flow chart with owner center on left and external center on right with msg_publicationupdates and msg_confirmationreceipts going back and forth.

An important thing to understand about TMDD, or about any standard, is how it views the physical world that it is trying to model. Other traffic management standards or ad hoc traffic data models will have an implicit perspective on the physical traffic network, so you need to understand each of these views for comparison and mapping.

TMDD views the traffic world in two primary abstract concepts: nodes and links. Nodes are arbitrary points along a road. Links are arbitrary parts of a road between two nodes, typically going in one direction of a roadway. Figure 7 shows how TMDD nodes and links map to a physical road network.

Figure 7. Example TMDD road network with links, nodes, and detectors
Map showing nodes, links, and traffic detectors, which supply info such as node inventory, node status, link inventory, and link status.

More information about the TMDD specification, including the specific messages, dialogs, and data concepts supported by the standard, is in the two volumes of the TMDD v3 specification published by the ITE.

IBM Intelligent Transportation implementation of the TMDD standard

The IBM Intelligent Transportation product supports interfacing with Traffic Management Centers and Advanced Traffic Management Systems (ATMS) using the TMDD standard. In the context of the two TMDD abstract entities, IBM Intelligent Transportation fills the role of the External Center. Using the TMDD standard's dialogs and the NTCIP 2306 SOAP/HTTP application profile, IBM Intelligent Transportation can connect to multiple Owner Centers to:

  • Establish communication
  • Request traffic and event data to be stored in the hub
  • Establish a longer-term communication using subscriptions

The IBM Intelligent Transportation Information Center has details about the TMDD dialogs and messages IBM Intelligent Transportation supports, which are the majority of the traffic, event, and device data objects and dialogs, both in a subscription-publication and request-response pattern of message exchange. The data that's communicated between various Owner Centers and IBM Intelligent Transportation (the External Center in this case) is intended to be real-time current information on the status of devices, the traffic network, and the latest events information. Figure 8 shows how the IBM Intelligent Transportation architecture supports the different components of TMDD standards.

Figure 8. IBM Intelligent Transportation architecture support for TMDD standards
Flow chart with the Owner Center and pieces on the left talking with dialogs to the External center on the right.

Requirements for implementing the TMDD standard to connect Traffic Centers

For ATMS that already support TMDD v3 and NTCIP 2306 communication, integrating with IBM Intelligent Transportation is fairly straightforward. The task is well documented in the TMDD specification and in the IBM Intelligent Transportation Information Center. Because the TMDD specification is just starting to gain traction, many traffic centers and systems won't support this standardized interface out of the box. Many cities and traffic centers don't have existing ATMS systems or capabilities. To tap into the capabilities of the IBM Intelligent Transportation product, implementers will need to build a TMDD Owner Center interface connected to existing systems (or possibly build from the ground up).

The following list outlines the high-level requirements, based on the TMDD specification, to be designed and implemented by a TMDD Owner Center to support communications to a TMDD External Center. The list is based on the understanding of how IBM Intelligent Transportation implements the TMDD specification, though the requirements can be applied to many different External Centers.

The Owner Center should:

  • Handle basic Connection Management dialogs.
  • Be able to receive Request and Subscription dialogs for all supported TMDD data objects.
  • Store and manage subscriptions created or deleted through Subscription dialogs to know which endpoints, frequency, and types of messages and data feeds should be sent to the External Center.
  • Send out request publications based on stored subscriptions, with specified parameters, after receiving a new subscription request for that particular data object.
  • Keep count of publications sent and the latest timestamp.
  • Support subscriptions and requests from multiple External Centers.
  • Respond back with appropriate error messages for application errors, unsupported data objects, and request message problems.
  • Support receiving of XML messages using NTCIP 2306 based SOAP/HTTP communication profile.
  • Send XML messages using NTCIP 2306 based SOAP/HTTP communication profile.

Traffic Management Owner Center Simulator

The Traffic Management Owner Center Simulator helps transportation agencies, software vendors, and others build a TMDD-compliant Owner Center to communicate with the IBM Intelligent Transportation product. The Traffic Management Owner Center Simulator is a valuable asset for testing integration with IBM Intelligent Transportation using TMDD. It also provides a starting point to design and implement a full TMDD Owner Center. This asset could potentially be used to build a production-level simulator between existing ATMS systems (or field devices) and the IBM Intelligent Transportation product.

The Traffic Management Owner Center Simulator takes existing historical data, represented in a file structure, and simulates that data as current traffic and event data as it responds to TMDD requests and subscriptions. An internal, independent clock, called the simulator clock, can be started and stopped at any time and can be run at various speeds. For example, the simulator clock allows the simulation of a week's worth of traffic data in just an hour or two. Though it isn't the best mechanism to load historical data into IBM Intelligent Transportation, the Traffic Management Owner Center Simulator does provide a very good mechanism to test the data and functions of IBM Intelligent Transportation in a testing or development environment.

Architecture and design

Figure 9 shows how the Traffic Management Owner Center Simulator is used as a J2EE enterprise application to be run on WebSphere Application Server v7.0.

Figure 9. Traffic Management Owner Center Simulator high-level design
Flowchart with administrator entering the data and then the owner center adapter outputting simulation data.

The major components of the simulator include:

TMDD Service Provider
A web module that receives SOAP messages from the TMDD External Center and, depending on whether it's a subscription message or a data request, passes the message to the Data Request Handler or Subscription Manager, respectively.

The TMDD Service Provider receives responses from the Data Request Handler and Subscription Manager synchronously and will send them back to the TMDD External Center.

Data Gatherer
A Java component that processes the inventory or data request message. It then interfaces with the Data Access Interface component to gather and assemble the information needed to respond to the request given.
Subscription Handler
A Java component that stores an internal list of all the subscriptions that are in place for each TMDD External Center. It processes new subscriptions and subscription cancellations received by the TMDD Service Provider.

The Subscription Handler runs a separate thread that, at a predetermined time frequency, will check if there are any publications that need to be sent to External Centers based on the active subscriptions. If a publication needs to be sent, this manager will send the subscription details to the Publication Handler to initiate the publication process.

Publication Handler
A Java component that receives notifications from the Subscription Manager when publications or updates need to be sent to an External Center. The Publication Handler interacts with the Data Gatherer component to get the latest information needed for that update and compile, in an update message, and finally sends this to the TMDD Service Client (passing the correct URL needed to the client).
Simulator Controller
A Java component that keeps track of the simulated time and its mapping to current time. The Simulator Controller also contains the logic and parameters related to how fast the simulated data is executed (2x as fast, 10x as fast, regular speed) and whether this data should be repeated (or time just stopped after being processed).
Data Access Utility
A Java component that is the primary interface to the simulated data. Upon each request for data from the Publication Handler or Data Request Handler, this component asks the Simulator Controller for the latest information about the simulated time. Then, it accesses the simulated data stored in the file system to find the appropriate details for the simulated time specified. For some of the data files, it will load the data dynamically based on the file name and timestamps.
Simulator Web Admin
A Java component that interfaces with the Simulator Controller to change the parameters related to how the simulator runs (speed, repeating). It can be used by an administrator to start, stop, or restart the simulator. This interface also allows an administrator to view all of the active subscriptions.
Simulation Data
The file system that stores the actual simulation data needed throughout this simulator adapter. The exact format of the data is defined by the sample directory provided with the simulator and by the XML schema defining the XML file contents. This data will be read and managed by the Data Access Utility.

The components outlined above enable the Traffic Management Owner Center Simulator to implement all of the requirements for being a full Owner Center. Table 1 has more details about which TMDD data objects are supported by the adapter and which dialogs are used to communicate those objects.

Table 1. TMDD data objects supported in the adapter, and necessary dialogs
TMDD data objectRequest / Response dialogsSubscription dialogPublish dialog
Center Active Verification DlCenterActiveVerificationRequest DlCenterActiveVerificationSubscription DlCenterActiveVerificationUpdate
Organization Information DlOrganizationInformationRequest DlOrganizationInformationSubscription DlOrganizationInformationUpdate
Full Event Update DlFullEventUpdateRequest DlFullEventUpdateSubscription DlFullEventUpdateUpdate
Event Index DlEventIndexRequest DlEventIndexSubscription DlEventIndexUpdate
Node Inventory DlNodeInventoryRequest DlTrafficNetworkInformationSubscription DlNodeInventoryUpdate
Node Status DlNodeStatusRequest DlTrafficNetworkInformationSubscription DlNodeStatusUpdate
Link Inventory DlLinkInventoryRequest DlTrafficNetworkInformationSubscription DlLinkInventoryUpdate
Link Status DlLinkStatusRequest DlTrafficNetworkInformationSubscription DlLinkStatusUpdate
Traffic Detector Inventory DlDetectorInventoryRequest DlDeviceInformationSubscription DlDetectorInventoryUpdate
Traffic Detector Status DlDetectorStatusRequest DlDeviceInformationSubscription DlDetectorStatusUpdate
Traffic Detector Data DlDetectorDataRequest DlDetectorDataSubscription DlDetectorDataUpdate
CCTV Inventory DlCCTVInventoryRequest DlDeviceInformationSubscription DlCCTVInventoryUpdate
CCTV Status DlCCTVStatusRequest DlDeviceInformationSubscription DlCCTVStatusUpdate
Gate Inventory DlGateInventoryRequest DlDeviceInformationSubscription DlGateInventoryUpdate
Gate Status DlGateStatusRequest DlDeviceInformationSubscription DlGateStatusUpdate
Intersection Signal Inventory DlIntersectionSignalInventoryRequest DlDeviceInformationSubscription DlIntersectionSignalInventoryUpdate
Intersection Signal Status DlIntersectionSignalStatusRequest DlDeviceInformationSubscription DlIntersectionSignalInventoryUpdate
Ramp Meter Inventory DlRampMeterInventoryRequest DlDeviceInformationSubscription DlRampMeterInventoryUpdate
Ramp Meter Status DlRampMeterStatusRequest DlDeviceInformationSubscription DlRampMeterStatusUpdate
LCS Inventory DlLCSInventoryRequest DlDeviceInformationSubscription DlLCSInventoryUpdate
LCS Status DlLCSStatusRequest DlDeviceInformationSubscription DlLCSStatusUpdate
DMS Inventory DlDMSInventoryRequest DlDeviceInformationSubscription DlDMSInventoryUpdate
DMS Status DlDMSStatusRequest DlDeviceInformationSubscription DlDMSStatusUpdate

Using the Traffic Management Owner Center Simulator to integrate with IBM Intelligent Transportation

Using the Traffic Management Owner Center Simulator to integrate traffic and event data with IBM Intelligent Transportation is an involved topic that is outside the scope of this article. Read the developerWorks article "Integrate traffic data with IBM Intelligent Transportation using a traffic data gateway" to learn how to convert non-TMDD traffic data into a format the Simulator can understand and read in order to get the data into IBM Intelligent Transportation.


In this article, you learned how the US National ITS Architecture and the TMDD standard are gaining prominence worldwide. The IBM Intelligent Transportation Management implementation of the TMDD standard was also covered. The article introduced a valuable new asset, the Traffic Management Owner Center Simulator, to help cities and IBM business partners implement TMDD.



Get products and technologies

  • Try out IBM software for free. Download a trial version, log into an online trial, work with a product in a sandbox environment, or access it through the cloud. Choose from over 100 IBM product trials.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into developerWorks

ArticleTitle=Build intelligent transportation systems with the Traffic Management Data Dictionary standard