Smarter city data model standards landscape, Part 2: Transportation

Learn about data model standards for smarter cities. Information exchange is challenging among city agencies, regardless of city size. The proliferation of different vendor solutions deployed across agency and departmental boundaries is the root of the problem. The solution is defining a common, standards-based smarter city data model that determines how information is structured and what it represents on a semantic level. This article focuses on the core concepts and standards that are common in the smarter city transportation domain.


Arnaud Le Hors (, Senior Software Engineer, IBM

Photo of Arnaud Le HorsArnaud Le Hors, a member of IBM software standards group, is responsible for driving the coordination of several IBM standards activities from a strategic and technical point of view. Arnaud has been working on open standards for 15 years, both as a staff member of the X Consortium and W3C. He has been involved in every aspect of the standards development process, including technical, strategic, political, and legal, both internal and external to an SDO and to a company like IBM. Arnaud was involved in the development of standards such as HTML and XML and one of the lead architects for Xerces, the XML parser developed by the Apache Software Foundation.

John Meegan (, Senior Technical Consultant, IBM

John Meegan is a senior member of the IBM Software Group Strategy and Technology group where he is currently focused on standards efforts for IBM's smarter city and cloud initiatives. Before his standards work, he spent several years developing the IBM Software Group open source strategy, working with both customers and industry consultants to communicate and refine the strategy. He also spent several years in the Software Group Strategy organization, where he contributed to the formulation of the initial IBM web application server strategy, leading to the eventual launch of the IBM WebSphere product family. He received a Bachelor of Arts (BA) degree in Computer Science from Columbia University.

Keith Wells (, Senior Software Engineer, IBM

Keith Wells photoKeith Wells, a developer on the Software Standards team, has enjoyed opportunities to actively develop code, demos, tactics and strategies with many standards over the past ten years. Keith is technically curious and feels passion and excitement developing interesting and practical products as well as collaborating with people who also have diverse skills.

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.

Viswanath Srikanth (, Senior Software Engineer, IBM

Sri author photoSri is an industry solution standards leader for the Transportation Industry and Smarter Commerce in IBM. He is an active member at transportation standards organizations including Open Travel Alliance working on creating standardized service models for core functions such as reservation and ticketing. Sri has previously co-chaired technical reports from industry consortia on the subject of applying service-oriented architecture into industries such as Hotel, Retail, and Education.

17 January 2012

Also available in Chinese


Smarter city initiatives are creating opportunities for savings, efficiency, and progress by making the world more interconnected, instrumented, and intelligent. Information exchange is a huge challenge among city agencies. This series of articles explores standards relevant to data modeling for a smarter city solution. The solution is defining a common, standards-based smarter city data model that determines how information is structured and what it represents on a semantic level. Part 1: Core focused on core concepts common across multiple smarter city domains: transportation, public safety, and water.

Target audience

This article is intended for anyone who wants to understand the standards related to smarter city modeling, and even more specifically for:

  • Solution architects, engineers, or researchers defining product and solution requirements and mid- to long-term technical and strategic direction.
  • Executives in charge of defining standards strategy around smarter city solutions, especially in the transportation domain.

This article, which builds upon the core concepts, focuses on common concepts across the smarter city transportation domain. It provides a reference for the transportation standards relevant to data modeling for smarter city solutions (see Standards index). Recommendations for leveraging existing standards are also included.

In Part 1, the planned roadwork scenario involved a smarter city transportation agency coordinating a planned road repair with other smarter city domains that it could affect. Because the activities are coordinated:

  • Schedules and work activities are optimized,
  • Disruption to citizens is minimized by city agencies, and
  • Time needed for individual repairs is reduced, potentially decreasing total costs to the city.

This article expands the planned roadwork scenario by exploring the impacts to a traveler trying to navigate from point A to point B when a planned road repair blocks a route.

IBM Smarter Cities

As we mentioned in Part 1, The IBM Smarter Cities initiative is based on the premise that the world is becoming interconnected, instrumented, and intelligent, and this provides an opportunity for new savings, efficiency, and progress. Underneath this premise lies the foundation of standards.

Standards are key for:

  • Interoperability
  • Data representation and exchange
  • Aggregation
  • Virtualization
  • Flexibility

While it's possible to develop ad hoc solutions, these limit long-term impact.

Cities are inherently heterogeneous with different vendor solutions deployed across agencies and departments. As a result, cross-agency collaboration and information exchange are challenges. IBM Smarter Cities solutions need to enable and facilitate exchange, triage, and selection of pertinent information across agencies in a structured manner with a standards-based data model.

Data models define how information is structured and what it represents on a semantic level. For instance, a data model for an accident report would:

  • Define the contents.
  • Set the structure of the contents.
  • Set relationships to other information.

It might identify the location of the accident, for example, and provide representational data using a postal address, geographic coordinates, or some other location system.

For an agency to process and correctly interpret information provided by another agency, it needs to understand the underlying data model. Each agency typically uses its own data model designed to address its specific needs within the constraints imposed by legacy systems.

Reconciliation of the disparity in the data models is vital. Defining a common smarter city data model simplifies the translation process because it confines the mapping to and from agency specific models. Smarter city solutions should consider and use various standards to help define and leverage a common data model.

A transportation data model based on standards can provide services for real-time information, communication, and incident management to government agencies and casual travelers. Such a data model can:

  • Alleviate traffic congestion.
  • Provide up-to-date information services.
  • Reroute traffic as needed when roadway accidents, obstructions, or conditions curtail normal conditions.

Transportation scenario: Trip planner

Walking through an end-to-end flow of a typical city scenario can identify key concepts and relationships for a smarter city information model. A scenario also provides solid context for positioning existing standards and identifying standards gaps. The trip planner scenario highlights several concepts common in a smarter city transportation solution. The intent of this section is to be illustrative, not exhaustive.

Brief description

A traveler who lives in a large city wants to efficiently travel from point A to point B using the available transportation. There are several possibilities in the city: at least two different bus routes, a metro route, or the traveler's personal vehicle. The traveler also has many route options to choose from on any given day. Travelers may choose different routes based on the:

  • Location of a particular bus in the current route (for example, how long will the traveler have to wait to get on the transportation).
  • Traffic conditions for the bus route on the road network (how long will it take to travel once on the bus).
  • Metro line incidents that may increase the duration of the trip.
  • Traffic conditions on the route the traveler might take with a personal vehicle.

The city offers a trip planner service whereby travelers can virtually view the current conditions and duration of travel from point A to point B. The service helps the traveler choose the best mode of transport by calculating the estimated time for the trip with a recommendation for the quickest route. The trip planner service tracks key data elements from multiple sources, including transit operators, road sensors, or other service providers.

Basic flow of events

The traveler wants to travel from point A to point B in the immediate future and requires the duration of time for the trip.

  1. The traveler initiates the city's trip planner service to determine the most efficient route for a given time.
  2. The traveler selects the origin and destination locations and the desired start time.
  3. The trip planner service displays route choices and transportation modes sorted by duration, from least amount of time to greatest.

    In the planned roadwork scenario in Part 1, the transportation agency coordinated with other agencies for a planned repair at a busy city intersection with an estimated duration of one week. The trip planner factors the road repair into its suggested routes in this scenario.

  4. The traveler selects a route to see more details.
  5. The trip planner service displays data about that route, including: the mode of transportation, route, start time (delay time), estimated time of arrival (ETA), and estimated duration for the trip. The service also provides notations about current delays along the route.

Key model concepts

Multi-modal trip planning, especially with public modes of transit, requires gathering key data elements from operators of different modes that make up a trip. The data elements include: schedule information, stops data, information about delays on specific routes, and any rerouting information. Operators frequently maintain this data in their own formats. Using the data in an easily comparable way requires the use of standards. Two popular standards for public transit are the Transit Communications Interface Profile (TCIP) standard in the U.S. and SIRI in Europe (which is now gaining traction in the U.S.).

Traffic management centers (each with their area of jurisdiction) typically supply data on current road conditions, which they must do for both public and private options. This data needs to be available in a standardized way to ensure that road sensor data from the sensor network and data from the different traffic management centers are delivered against a standardized model. The Traffic Management Data Dictionary (TMDD) and DATEX II are two of the more popular standards for delivering current road conditions data.

Making data available in a standardized format could be in the domain of operators and traffic management centers, or it could be delegated to service providers. Service providers could also apply suitable algorithms to the data to provide a complete trip planning service.

The model concepts that are fundamental to the trip planner scenario described above are: traveler, route, location, vehicle, time schedule, stop point, delay information, road conditions, and trip. There are strong relationships amongst many of these concepts. The applicability of existing standards, and the extent of standards gaps, varies significantly for each concept.

The core model concepts described in Part 1 are still valid in the transportation domain. We reiterate them here and add the key transportation model concepts in bold type.

  • Definition: A group of persons organized for a particular purpose
  • Examples: Police department, public housing department, bus department, transportation agency, water agency, electric utility
  • Key attributes: Name, type of organization, description, identification, web site
  • Key relationships: Organizations (parent-child), assets, location
  • Standards assessment: National Information Exchange Model (NIEM): NIEM-Core (nc:)OrganizationType, UCore (Universal Core) organization, TMDD organization, DATEX II
  • Definition: A warning or alarm for an imminent event
  • Examples: Road repair advisory
  • Key attributes: Sender, description, urgency, severity, certainty, onset time, location, supporting resources
  • Key relationships: Sender (organization or person), location, incident, work orders
  • Standards assessment: The Common Alerting Protocol (CAP) has extensive support for the alert concept. The UCore Event, TMDD event, DATEX II Situations, and ATIS concepts are also applicable.
  • Definition: An occurrence or an event that may require a response
  • Examples: Road repair, automobile accident, water main bursting, criminal activity
  • Key attributes: Date and time of the incident, description, ID
  • Key relationships: Location, alerts, work orders, owner (organization or person)
  • Standards assessment: IEEE Incident Management message sets, NIEM:nc:IncidentType, CAP:alert:incidents, UCore Event, TMDD event, SOA Ontology Event, DATEX II situations
  • Definition: A human being, an individual
  • Examples: James, Bob, Sally
  • Key attributes: Full name, given name, family name, gender, date of birth, place of birth, citizenship, country of birth
  • Key relationships: Employer, location, address, organization, role (such as operator, supervisor, responder, analyst, asset manager)
  • Standards assessment: NIEM:nc:PersonType, UCore Person, SOA Ontology Human Actor, ATIS Traveler
  • Definition: A tangible object that can be tracked over time
  • Examples: Road, water pipe, electric capacitor, bus, building
  • Key attributes: Description, ID
  • Key relationships: Organization, person, manufacturer, location, work order, incident
  • Standards assessment: NIEM:ip: AssetType, UCore Entity, NTCIP for transportation related field devices, TCIP Vehicle, SIRI
Work order
  • Definition: An order to do some work; to fix, repair, or replace
  • Examples: Road repair, utility maintenance on a main valve, re-routing of buses
  • Key attributes: Description, ID, comment, priority, status, location, start date/time, stop date/time
  • Key relationships: Work steps, work orders (parent-child), incident, alert, organization, maintenance history, specification, person, assets
  • Standards assessment: No relevant standards identified at this time.
Process and procedure
  • Definition: A series of actions to accomplish a goal
  • Examples: Road repair notification and coordination
  • Key attributes: Process document
  • Key relationships: Process steps, work orders, incident, alert, organization, person, assets
  • Standards assessment: SOA Ontology Process
Key Performance Indicator
  • Definition: A measurement or criteria to assay the condition or performance of a person, process, or thing
  • Examples: Response time, time to closure, cost to city, savings to city, impact to city services
  • Key attributes: Description, metrics, thresholds
  • Key relationships: KPI (parent-child), organization, incident, alert, process and procedure, asset
  • Standards assessment: No relevant standards identified at this time.
  • Definition: A geographic place, point, position, or area identified by its coordinates in an earth based coordinate system, name, or address
  • Examples: Road repair location: city intersection, water pipe location
  • Key attributes: Geographic coordinates, postal address, time stamp
  • Key relationships: Person, organization, asset, incident, alert
  • Standards assessment: NIEM:nc:LocationType, UCore Location, Geography Markup Language (GML) Point, OpenLS Location, DATEX II TPEG (Transport Protocol Experts Group [TPEG] transmits information about multi-modal traffic and travel see Resources), Location Referencing Management Systems (LRMS), TCIP, ATIS, and TMDD
  • Definition: Measuring system used to sequence events, to compare the durations of events and the intervals between them, and to quantify rates of change such as the motions of objects
  • Examples: Start time, end time
  • Key attributes: Years, months, weeks, days, hours, minutes, seconds, milliseconds
  • Key relationships: Duration
  • Standards assessment: NIEM:nc:DateTime, TMDD DateTime, W3C DateTimeDescription,

Transportation key concepts

The following are key model concepts specific to transportation.

Delay information
  • Definition: The information about a delay associated with a particular stop along a transit route
  • Examples: Ten minute delay at a bus stop on route 42; 30 minute delay at a ferry port
  • Key attributes: Schedule time, delay time, estimated delay time
  • Key relationships: Schedule, stop point, route, vehicle
  • Standards assessment: TCIP PISchedAdherenceOffSched, TMDDLinkStatus, DATEX II TrafficDelay
Road conditions
  • Definition: The state of a road as it pertains to traffic conditions and incidents
  • Examples: Heavy traffic, road closures, road repair, traffic incidents
  • Key attributes: Name, state, location of condition, description
  • Key relationships: Road network, trip guidance, vehicle
  • Standards assessment: IEEEIM 1512, ATIS Traveler Information, TMDD LinkStatus, TMDD Events, DATEX II Situations, DATEX II MeasurementSiteRecord, NTCIP
Road network
  • Definition: A set of streets, roads, and highways usually constrained to a geographic area
  • Examples: Streets in downtown New York, U.S. interstates
  • Key attributes: Name, direction, road, intersections
  • Key relationships: Road conditions, route, trip
  • Standards assessment: TMDD RoadNetwork, DATEX II Location, TCIP
  • Definition: A sequence of stop points of a vehicle according to a time schedule
  • Examples: New York City bus route M42
  • Key attributes: Name, distance, description, direction, turns
  • Key relationships: Stop points, road network, vehicle, time schedule
  • Standards assessment: TCIP Route, TCIPTrip, ATIS, SIRI
Stop point
  • Definition: A public transit stop
  • Examples: New York City Lincoln Center stop
  • Key attributes: Name, geolocation
  • Key relationships: Time schedule, route, trip, vehicle
  • Standards assessment: TCIP Stop point, SIRI
Time schedule
  • Definition: Time information about a vehicle's schedule for a route
  • Examples: Metro schedule, bus schedule
  • Key attributes: Time, schedule
  • Key relationships: Stop point, route, vehicle
  • Standards assessment: TCIP Schedule, SIRI, ATIS
  • Definition: A person who uses a vehicle to get from one place to another
  • Examples: Harry, Fred, Sally
  • Key attributes: Name
  • Key relationships: Trip, trip guidance
  • Standards assessment: ATIS Traveler Information
  • Definition: Includes a sequence of routes and roads for a traveler to get from one place to another
  • Examples: Trip across town, trip to mall
  • Key attributes: Name, starting place, destination, itinerary
  • Key relationships: Traveler, trip plan, routes, road network, vehicle
  • Standards assessment: ATIS Route, SIRI
Trip plan
  • Definition: Suggested plan for efficiently traveling from one place to another
  • Examples: Take metro from Washington, DC to the Capitol Mall
  • Key attributes: Name, total time, distance, total cost
  • Key relationships: Trip, traveler, road conditions
  • Standards assessment: ATIS Trip Guidance
  • Definition: A conveyance to move a person from one place to another
  • Examples: Car, bus, train, boat, bicycle
  • Key attributes: Name, mode of transit
  • Key relationships: Traveler, road network, route, trip
  • Standards assessment: TCIP Vehicle, SIRI

Standards inventory

This section describes existing standards that are pertinent to smarter city modeling. We include other relevant standards, and recommendations on how to leverage the standards. See Resources for the list of recommended standards from the National Incident Management System (NIMS).

National ITS Architecture

The National Intelligent Transportation Systems (ITS) Architecture, developed by the U.S. Department of Transportation, provides a common framework for planning, defining, and integrating ITS. (See Resources.) It defines:

  • The functions that must be performed by subsystems.
  • Where the functions reside (in the field, traffic management center, in vehicle).
  • The interfaces and architecture flows to and from the subsystems.
  • The communications requirements for the architecture flows.

The National ITS Architecture is a mature product that reflects the contributions of a broad cross-section of the ITS community: transportation practitioners, systems engineers, system developers, and technology specialists.

A major goal of the National ITS Architecture is to define the key interfaces for standardization. See Resources for a complete list of ITS standards endorsed by the National ITS Architecture.

There are ITS standards for many of the architecture flows. Within the framework of the National ITS Architecture:

  • Standards developers can identify standards that will meet their users' needs.
  • Planners can integrate regional ITS elements using the ITS standards and achieve interoperability goals.
  • Deployers can select the ITS standards that reduce risk to their deployment and thus help manage costs and schedules.

Four of the eight standards highlighted in the National ITS Architecture (NTCIP, TMDD, ATIS, and IEEE IM) are particularly relevant to the public safety focus of the initial smarter city modeling effort.

National Transportation Communication for ITS Protocol (NTCIP)

NTCIP defines a family of general-purpose communications protocols, and transportation-specific data dictionaries and message sets, that support most types of computer systems and field devices used in transportation management. (See Resources.) Applications for NTCIP are generally divided into two categories:

Center to field (C2F)
This category involves devices at the roadside communicating with management software on a central computer. For the C2F domain, NTCIP has a set of data dictionaries, called the NTCIP 1200 series of standards, that define the information content between a management center and a field device (or other center). There are thirteen data dictionaries, including: object definitions for dynamic message signs, CCTV camera control, ramp meter control, transportation sensor systems, and more. The data element definitions include syntax, allowable ranges, and valid sequences for transmitting data elements.
Center to center (C2C)
This category involves computer-to-computer communications. The computers can be in the same room, in management centers operated by adjacent agencies, or across the country. NTCIP references four standards that define data dictionaries.
  • TMDD: This is a joint standard of the Institute of Transportation Engineers (ITE) and the American Association of State Highway and Transportation Officials (AASHTO) that facilitates communication of traffic management information between cooperating centers.
  • ATIS: The message sets for Advanced Traveler Information Systems, SAE J2354, is a standard of the Society of Automotive Engineers that enables the traveling public to manage their trips and make informed decisions on trip details.
  • TCIP: This is an American Public Transit Association (APTA) standard that allows transit agencies and suppliers to create standardized, tailored interfaces.
  • IM: The Incident Management (IM) IEEE 1512 is a series of standards for communications between transportation and emergency management centers.

Traffic Management Data Dictionary (TMDD)

TMDD standards support center-to-center communications as part of the regional deployment of ITS so centers can cooperatively manage a corridor, arterial, incident mitigation, an event, and so forth. The TMDD provides the dialogs, message sets, data frames, and data elements to manage the shared use of these devices and the regional sharing of data and incident management responsibility. As a result, the TMDD standards often reference elements of the NTCIP standards but deal with the devices at a higher level of abstraction. Refer to TMDD and Message Sets for External Traffic Management Center Communications (MS/ETMCC) for details. (See Resources.)

Using TMDD, centers can exchange information about their traffic conditions, device locations and conditions, and both planned (construction) and unplanned (accidents) events. They can also exchange weather information among themselves and with a weather clearinghouse for their region. With this exchange, agencies can observe the signal timing of adjacent agencies (systems) and evaluate the effectiveness of their timing plans. The TMDD standard supports cooperative use of all of the ITS devices by allowing one center to discover what devices are available and where they are located. The C2C exchanges allow one center to control another center's devices (with appropriate privileges).

The core TMDD data concepts include: OwnerCenter, ExternalCenter, Device, DateTime, Dynamic Message Sign, Event, Generic, Organization, and RoadNetwork.

Advanced Traveler Information Systems (ATIS)

This standard, SAE J2354, Message Set for Advanced Traveler Information System (ATIS), provides the messages and data elements that are exchanged among traveler information providers (data providers) and travelers (data consumers). (See Resources.) The messages within this standard address all stages of travel (informational, pre-trip, and en route), all types of travelers (drivers, passengers, personal devices, computers, other servers), all categories of information, and all platforms for delivery of information (in-vehicle, portable devices, kiosks). ATIS supports XML-based versions of each entry and reuse of data elements from other functional area data dictionaries, such as TMDD.

The standard provides two basic types of ATIS depending whether or not the traveler interacts with the traveler information provider. One-way communication of traveler information includes predefined information broadcast to travelers, such as radio and TV broadcasts and some web pages. Two-way, transactional traveler information includes all means whereby the traveler makes specific, personalized requests and receives customized information.

The messages defined in this standard are divided into seven major groupings of ATIS applications; message sequencing for each type of message (dialogs) is also included:

  • Traveler information: Traffic, incidents, events, weather, environmental conditions, public transit schedules
  • Trip guidance: Route plan to a specific destination, including the mode of transportation, points of interest, and so on
  • Directory services: Electronic Yellow Pages, possibly location-based
  • Parking: Parking lot and space availability
  • Settings: Traveler's personal preferences for format and content of traveler information
  • Mayday: Emergency information, including requests for assistance and vehicle information
  • Reduced bandwidth: Streamlined version of certain data elements to accommodate bandwidth restricted media

IEEE Incident Management (IM) Working Group

With the increase in travel worldwide, ITS are vital to safety, protecting the environment, and relieving traffic congestion. To guarantee smooth operations, standardization of a common method for ITS components to communicate with one another is key.

The IEEE 1512® Family of standards are incident management and traffic incident related message sets. (See Resources.) They provide incident management message sets common to traffic management, public safety, and hazardous materials incident response activities. Traffic incident management involves managing available resources of various disciplines to mitigate an incident in an efficient and appropriate manner. Standard message sets reduce duplication of messages among organizations and help providers interact more effectively and efficiently.

The core IM data concepts for which separate standards have been defined include: common incident management message sets for use by emergency management centers, traffic management, public safety, hazardous materials, and entities external to centers.


The last decade has seen big investment in Europe in both traffic control and information centers. There has also been a quantum shift in the monitoring of the trans-European transport network (TEN-T). Collecting information is only part of the story; data needs to be exchanged both with other centers and with those developing pan-European services provided directly to road users. DATEX II has become the reference for all applications requiring access to dynamic traffic and travel related information in Europe. (See Resources.) DATEX II is intended to become a multi-part, technical specification maintained by CEN Technical Committee 278 (Road Transport and Traffic Telematics).

Information exchanged with DATEX II systems is composed of different basic elements:

  • Traffic elements: Abnormal traffic, accidents, obstructions, conditions
  • Operator actions: Traffic control, roadworks, roadside assistance, sign settings
  • Impacts: Information on lane availability and delays
  • Non-road event information: Transit service information, road operator service disruption, car parks
  • Elaborated data: Derived or computed data, such as travel times or traffic status
  • Measured data: Direct measurement data from equipment or outstations, such as traffic and weather measurements

The basic elements can be exchanged individually or grouped. For exchanges, the notion of publication is used. There are four main publications:

  • Situation publication: A traffic or travel situation comprising one or more traffic or travel circumstances linked by one or more causal relationships and which apply to related locations
  • Elaborated data publication: Used to send periodically elaborated data derived by a traffic center relating to specified locations
  • Measured data publication: Used to send periodically measured data derived from equipment at specific measurement sites
  • Traffic view publication: Snapshot of what happens on one itinerary, in one direction, at a given time

The DATEX II data model, defined in the Unified Modeling Language (UML), is extensive and includes other, more detailed entities that elaborate on the basic elements and publications above. The DATEX II v2.0 Data Dictionary (see Resources) has a complete list of DATEX II concepts. Tools are provided to serialize model content to XML and XML schema.

Service Interface for Real Time Information (SIRI)

SIRI, a standard sponsored by the European Committee for Standardization (CEN), is for the exchange of real-time information about public transportation services and vehicles. (See Resources.)

Increasingly, public transportation services are using software systems to provide widely accessible and reliable information about passengers and operations. Public transportation services use these systems to set schedules, coordinate departures and arrivals, issue tickets or receipts, report delays or stoppages, and manage vehicles and personnel. Some data elements of interest include:

  • DestinationName
  • VehicleRef
  • ExpectedArrivalTime
  • AimedArrivalTime
  • VehicleActivity
  • ConnectionLink
  • JourneyPatternInfo
  • VehicleJourney
  • VehicleJourneyInfo
  • ServiceInfo
  • ProgressInfo
  • ArrivalInfo
  • DepartureInfo
  • VehicleAtStop

The following are some of the SIRI services.

Production Timetable (PT) service
Provides expected operational data for a public transportation network for a specified day in the near future.
Estimated Timetable (ET) service
Provides information about a public transportation network for a period within the current day, usually detailing the differences between the expected and actual timetables. Includes cancellations, journey additions, and detours.
Stop services (Stop Timetable (ST) and Stop Monitoring (SM))
Provide data for arrivals and departures for particular stops within a specific and imminent time period.
Vehicle Monitoring (VM) service
Provides current location and status, scheduled and expected arrival times, and historical data for a particular public transportation vehicle.
Connection protection services (Connection Timetable (CT) and Connection Monitoring (CM))
Provide information to transportation operators about arrival and departure times for vehicles in the public transportation network that connect passengers with other public transportation.
General Messaging (GM) service
Provides an exchange format for sharing travel news and advice.


As smarter city data model implementations progress, you should take the following steps to ensure consistency with the critical standards specified in this article:

  • Foremost, use the core concepts in Part 1: Core as the foundation for extending the smarter city transportation concepts in a transportation domain data model.
  • Leverage the standards in Standards inventory to help identify and model smarter city transportation concepts.
  • Design data models to carry the information necessary for an adequate mapping to and from these standards where appropriate. (Leveraging these standards does not mean designing the smarter city data model as a patchwork of these standards.)
  • Take into account all attributes and relationships where multiple standards define the same entity, such as traveler, route, schedules, and location.
  • If similarly named entities exist in multiple standards but are significantly different, consider defining separate concepts for the entities.
  • Ensure that your smarter city transportation model is able to consume and emit entities and concepts for all standards defined in section 2 of this document.
  • Add key concepts and entities defined by the standards in this article to the smarter city glossary with proper attribution.
  • As smarter city models evolve and standards gaps are identified, consider engaging appropriate standards bodies to assist and address these gaps.


Standards will play an important role in the development of transportation data models for smarter cities. This article identified several critical standards applicable to transportation concepts that you should leverage when developing the data model and the smarter city data model core concepts. Future articles, extending into other domains, will evaluate additional standards for inclusion in smarter city data models.

Standards index

Information about the standards in the following table is not exhaustive. Send any additional information to the authors for future revision.

Standard Examples of supported concepts Current deployments
Advanced Traveler Information Systems (ATIS), SAE 2354 Messages defined for traveler information, trip guidance, parking, Mayday (emergency information) International standard (SAE) with traction in North America

Gaining momentum in the US; Nebraska, Washington and Minnesota planning support. See Washington State Department of Transportation Advanced Traveler Information Systems Business Plan for details.

DATEX II Traffic elements, operator actions, impacts, non-road event information, elaborated data, and measured data European standard

Version I deployed in several European countries. DATEX II deployment appears to be gaining momentum in several European countries. See DATEX Deployments for details.

IEEE 1512 Common incident management message sets for use by emergency management centers, traffic management, public safety, hazardous materials, and entities external to centers International standard

Early deployments include Washington D.C., NYC, and Milwaukee. See 1512 Public Safety Early Deployment Projects for details.

National Transportation Communication for ITS Protocol (NTCIP) 1200 Series Currently thirteen data dictionaries defined, including object definitions for: dynamic message signs, CCTV camera control, ramp meter control, transportation sensor systems U.S. specific standard

According to NTCIP web site, several cities and states in the U.S. have NTCIP projects underway. See NTCIP Deployment: Projects for details.

Service Interface for Real Time Information (SIRI) Information exchange of real-time information about public transportation services and vehicles European specific standard

Based on best practises of various national and proprietary standards from across Europe.

Traffic Management Data Dictionary (TMDD) OwnerCenter, ExternalCenter, Device, DateTime, Dynamic Message Sign, Event, Generic, Organization, and RoadNetwork International standard (ITE and AASHTO) with traction in North America

In early stages of deployment in the US. TMDD is backed by US DoT and multiple vendors (Transcom, Siemens). Multiple state DoTs are planning to move to TMDD in their next rev (including Florida and Utah). See "A Report to the ITS Standards Community ITS Standards Testing Program, For TMDD and Related Standards as Deployed by the Utah Department of Transportation" for TMDD testing details from the Utah DoT.





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 Open source on developerWorks

Zone=Open source
ArticleTitle=Smarter city data model standards landscape, Part 2: Transportation