Real-Time System Management Information Program Data Exchange Format Specification — Implementation Guidance
4. System Design Reference
It may be useful for the reader to have DXFS Section 4 Design Reference and Annex B – RTM available. At this point in the process, an implementer has identified the requirements for DXFS information interchange. This section will discuss and demonstrate how to use the RTM to identify DXFS data concepts.
This section describes how to trace into and select the design references contained in other standards, namely TMDD, SIRI, TCIP, and OASIS CAP.
4.1 Background
4.1.1 Standards Referenced by the DXFS
The DXFS contains references to data concepts defined in TMDD Volume II, SIRI, TCIP, and OASIS CAP. Table 11 below lists the standards referenced by the RTSMIP DXFS.
Table 11. Information Level Standards Referenced by the RTSMIP DXFS – “DXFS Information Level Standards.”
| DXFS Functional Area |
Standard |
Description of Standard |
| Traffic Management |
TMDD |
The Traffic Management Data Dictionary (TMDD) provides for information and control exchanges related to real-time roadway and traffic information, incidents, construction, and roadway weather. |
| Transit Management |
TCIP |
The Transit Communications Interface Profile (TCIP) covers transit communications between centers, and centers and transit vehicles. TCIP provides traveler information on real-time transit vehicle location, and predicted transit vehicle arrival/departure. |
| Transit Management |
SIRI |
The Service Interface for Real time Information covers transit communications between centers, and centers transit vehicles. SIRI provides traveler information on real-time transit vehicle location, predicted transit vehicle arrival/departure, and predicted transit trip travel time. |
| National Weather Service Weather Alerts |
OASIS CAP |
The Common Alerting Protocol (CAP) is a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. CAP allows a consistent warning message to be disseminated simultaneously over many different warning systems, thus increasing warning effectiveness while simplifying the warning task (Common Alerting Protocol, V. 1.1, OASIS Standard CAP-V1.1, OASIS, October 2005, p.1.). |
These standards define the information content of messages exchanged between systems and are collectively referred to hereafter as the DXFS Information Level Standards. As is described in Section 6 of this Implementation Guidance, information level standards specify the data structure and semantics of information and control exchanges.
The reader may note that two standards are listed under the functional area for Transit Management. At this time, two standards for communication of real time transit information are being deployed in the U.S. During the DXFS development design phase, U.S. DOT in coordination with transit operators involved in the development of the DXFS, decided to support both SIRI and TCIP.
From the perspective of DXFS, the key difference between SIRI and TCIP is that SIRI is better suited to handle predicted trip travel time, whereas TCIP does not handle trip travel time.
4.1.1.1 AASHTO/ITE Traffic Management Data Dictionary
The Traffic Management Data Dictionary covers management center communications related to traffic management operations. It is subdivided into the following areas:
- Center Connection Management.
- Center Entity Naming and Identification.
- Security Data.
- Manage Center Entities.
- Provide Information on Organization and Contacts.
- Events Information Sharing (e.g., incidents, construction, and planned events).
- Roadway Network Data (e.g., speed, volume, location, routes, stop points, device and incident location).
- Traffic Device Inventory, Status and Control.
- Roadway Weather.
- Archived Data.
4.1.1.2 APTA Transit Communications Interface Profile
There are several standards that support transit information in the U.S. including APTA’s Transit Communications Interface Profiles (TCIP). TCIP is closely coupled with the SAE J2354 ATIS standard and its family of standards. Implementing one of these standards necessitates the application of several SAE standards. TCIP may be more integrated with general non-public transport related trip planning; however, it has not been deployed in a widespread manner yet. Both standards can be implemented using a prescribed set of message request/response pairs as defined in NTCIP 2306. TCIP does not have a specified transport layer; it does specify the use of ASN.1 or XML as the encoding format.
The APTA TCIP, being a standard for transit information, contains data concepts for transit vehicle location, passenger loading, and transit schedule information (route, trip, direction/headsign, stop, and timepoint data).
TCIP provides building blocks for interfaces for several business areas:
- Common Public Transport.
- Scheduling.
- Passenger Information.
- Transit Signal Priority.
- Control Center.
- Onboard Systems.
- Spatial Referencing.
- Fare Collection.
4.1.1.3 SIRI – Service Interface for Real Time Information
The Service Interface for Real Time Information (SIRI) is a European Union (EU) standard with numerous European deployments (particularly internal to European public transport trip planner applications), and several U.S. deployments. SIRI is implemented using a prescribed set of message request/response pairs. Messages are encoded in XML and transported using web services. A proposal was promoted to use HTTP and REST as queries, and may help reduce the bandwidth needed by an XML web service.
SIRI is contained in 3 parts:
- Part 1: Context and framework 2012-01.
- Part 2: Communications infrastructure, 2012-01.
- Part 3: Functional service interfaces, 2012-01.
According to the SIRI Handbook, SIRI aims to incorporate the best of various national and proprietary standards from across Europe and deliver these as web services using a modern XML schema. The services assume a standard conceptual model for the data to be exchanged, based on the CEN Transmodel data reference model. Element names and data structures are based on this model. SIRI was developed for bus data, but can be used just as well for other modes of transport such as rail and air.
4.1.1.4 OASIS CAP – National Weather Service
The Common Alerting Protocol (CAP) provides an open, non-proprietary digital message format for all types of alerts and notifications. It does not address any particular application or telecommunications method. The CAP format is compatible with emerging techniques, such as Web services, as well as existing formats including the Specific Area Message Encoding (SAME) used for the United States’ National Oceanic and Atmospheric Administration (NOAA) Weather Radio and the Emergency Alert System (EAS), while offering enhanced capabilities that include:
- Flexible geographic targeting using latitude/longitude shapes and other geospatial representations in three dimensions.
- Multilingual and multi-audience messaging.
- Phased and delayed effective times and expirations.
- Enhanced message update and cancellation features.
- Template support for framing complete and effective warning messages.
- Compatible with digital encryption and signature capability.
- Facility for digital images and audio. (DXFS Annex A – is contained in a separate volume, p. 4.)
4.1.2 Requirements Traceability Matrix
The DXFS document includes a Requirements Traceability Matrix (RTM) that describes the design for fulfilling a functional requirement supported by the DXFS. The purpose of the RTM is to link each functional requirement, as presented in Section 3 of the DXFS document, with the data concepts that fulfills that functional requirement. The definition of each data concept type can be found in Section 4.1.2.2 below. The design for each functional requirement consists of a dialog, one or more messages, and one or more data frames or data elements per message.
The purpose of the RTM is to define, in a standardized manner, how the DXFS is to be implemented so that all systems can fulfill a functional requirement the same way. Only by fulfilling the requirement the same way can interoperability be achieved.
Each functional requirement supported by the DXFS appears in one of the four RTMs provided in Annex B – RTM, which is contained in a separate volume, of the DXFS document. An RTM is provided for the purposes of tracing a requirement to its design elements (data concepts). This section provides 4 Requirements Traceability Matrices, one for each of the standards (TMDD, SIRI, TCIP and OASIS CAP), whose design elements and data concepts are used to fulfill one of more requirements of the RTSMIP-DXFS. The columns of the RTM are described below
Requirements ID and Requirement: The RTMs contain columns titled Requirement ID, and Requirement, which reference a RTSMIP-DXFS requirement. The Requirement ID is the paragraph identifier as shown in Section 3 of the DXFS document, and the Requirement is the paragraph title.
Data Concept Type (DC Type): A column in the RTM describes the data concept type (design) that fulfills a particular requirement. Data concept types are described below:
- Dialog. A dialog data concept describes the sequence or conditions for information exchanges between a center and other centers. The dialog rows are shaded and shown in bold to help the reader identify where a sequence of messages, accompanying data-frames and data-elements begins.
- Message. A data concept to describe the message sent between an external center to an owner center. An owner center owns and/or operates the resources gathering and distributing real time transportation data.
- Data-frame. A data concept to describe a portion of a message that may contain other data-frames and data-elements.
- Data-element. A data concept that cannot be broken down into smaller units. A data-element is generally a text string, number, or enumeration, with a set of value and/or size constraints.
4.1.2.1 Data Concept Instance Name, Data Concept ID, and Data Concept Class Name
The data concept name, data concept identifier, and data concept class name columns are used to identify the design element in one of the 4 standards documents referenced by the RTSMIP-DXFS: TMDD Volume II, SIRI, TCIP, or OASIS CAP. As a point of clarification, the Data Concept ID is a look-up reference to allow easy navigation into the referenced standard, and is usually a paragraph identifier. The TMDD, for example, is structured such that a paragraph in the design volume references a generic type name, e.g., 3.4.14.32 Link-speed-limit. The ‘3.4.14.32’ is the Data Concept ID, and the ‘Link-speed-limit’ is the Data Concept Class Name. Several data concepts, or instances, may be of class, or type, Link-speed-limit. For example, speed-limit, and speed-average are both of class Link-speed-limit. Because a message may contain several data concept instances of a particular class, the RTM shows the data concept instance name. Several data concept instances may be included in a TMDD message that is are of class Link-speed-limit. For example, the LinkStatusMsg (Link Status Message) contains speed-limit and speed-average.
4.1.2.2 RTM Column Name
The RTM also contains a comment column to capture any additional information that the author may feel benefit the reader. These comments are specific to how the design can be implemented to fulfill the requirement the author feels may benefit a reader.
4.1.3 Instructions for Completing the RTM
To find the DXFS design content for a functional requirement, first search for the user need that is being satisfied. All the user needs satisfied by the DXFS are defined within Section 2.5 of the DXFS document. Each user need or group of user needs is shaded to help the reader identify where the requirements and design elements that satisfy those user needs begin and end. Next, search for the requirement identification number and functional requirement under the Requirement ID and Requirement columns. Each requirement is sorted by the type of data concept that will be implemented to fulfill the requirement. This mapping is categorized as one of four types:
- Dialog. A requirement to describe the sequence or conditions for information exchanges across an interface.
- Request Message/Subscription Message. A requirement to describe the message sent from an external center to an owner center. In the case of a subscription, the external center will send a subscription message. The subscription message is identical to a request message, but contains additional information to establish the subscription.
- Response Message/Publication Message. A requirement to describe the message sent from an owner center to an external center. In the case of a publication, the owner center will send a publication message. The publication message is identical to a response message, but contains additional information to manage the publication.
- Error Message. A requirement to describe the error report message.
To the right of each requirement is the data concept type. For requirements that are fulfilled by a data concept type of dialog, the dialog defines the sequence or conditions for the information exchanges that must occur across an interface to fulfill that functional requirement. The data concept name, identification number, and class identify the specific dialog in the appropriate referenced standard.
For all other data concept types, the name, identification number, and class identify the design elements that are referenced or used by the dialog to fulfill that functional requirement.
4.2 System Design Reference Guidance
The objective of this step in the process is to select the design concepts for a project based on the requirements selected for the project. The RTM contains columns that identify the sections of standards’ design (data concepts) that satisfy the DXFS requirements. To make finding the particular requirements easy when tracing from the DXFS NRTM to the DXFS RTM, a row has been inserted between sections of the RTM to identify the user needs that are satisfied by the set of requirements listed in the rows below.
The following steps are suggested to use the RTM to identify design data concepts that will be mandatory as part of a deployed system.
- Identify the section of the RTM that corresponds with the requirements identified from the NRTM that are project-relevant.
- Identify the requirements that are mandatory from the filled-in tailored NRTM.
- Identify the rows that contain a reference to the mandatory requirements, and cross out/delete those rows that are not project-relevant for the deployment.
- Identify the data concepts that are mandatory for the deployment.
Most of the requirements in the DXFS map to a single set of data concepts and the above steps can be used to uniquely identify the set of data concepts. In the area of transit related needs and requirements the user of the DXFS must make a decision regarding whether to specify TCIP or SIRI. This decision is left up to the deployer, but the following additional guidance should be considered in making the choice:
- Neither standard covers all of the requirements defined in the DXFS, so perform steps 2 through 4 for both the TCIP table and the SIRI table in Appendix B and determine which standard better addresses the set of requirements selected.
- In areas where both standards address a requirement, there may be differences in the way the requirement is addressed that should be considered. For example in defining data concepts to address the user need UN 2.5.6.3 Predicted Bus or Train Arrival/Departure times is selected (and the related requirements), TCIP provides a stop based arrival/ departure time, while SIRI is capable of providing a route based arrival/ departure time. Selection of one standard over the other will depend on which of these concepts the agency would like to deploy.
Another consideration is whether the agency has experience deploying interfaces using TCIP or SIRI.
4.3 System Design Reference Example
This section provides an example of how to identify and select design concepts, using the four steps identified above. Table 12 below shows the page in the RTM that contains the section for the user need 2.5.2.2 Travel Time Data for Roads.
The following steps are suggested to use the RTM to identify design data concepts that will be mandatory as part of a deployed system.
- Identify the section of the RTM that corresponds with the requirements identified from the NRTM that are project-relevant. The section covering UN 2.5.2.2 is shown below.
Table 12. Line of the RTM that Corresponds to One Requirement.
| RTSMIP-DXFS Requirement ID |
Requirement |
DC Type |
TMDD Vol II DC Instance Name |
TMDD Vol II DC ID |
TMDD Vol II DC Class Name |
| 3.5.3.3.2.1 |
Send Link Status Information Upon Request |
dialog |
dlLinkStatusRequest |
3.1.13.2 |
dlLinkStatusRequest |
Note: Dialogs for:
- UN 2.5.2.1 Speed Data for Roads.
- UN 2.5.2.2 Travel Time Data for Roads.
- UN 2.5.2.3 Speed Data for Public Traveler Information Providers.
- UN 2.5.2.4 Travel Time Data for Public Traveler Information Providers.
- UN 2.5.2.5 Travel Time Data for Parties who Create Value added Information Products.
- UN 2.5.7.1 Roadway Network and Device Information.
- Identify the requirements that are mandatory from the filled-in tailored NRTM. From the example in the previous section, requirement 3.5.3.2.1 was selected as shown below, but the next two requirements were not.
Table 13. Rows for Mandatory Requirements.
| Requirement Type |
Req ID |
Requirement |
Conformance |
Support |
| Dialogs for Link Based Information |
3.5.3.3.2.1 |
Send Link Status Information Upon Request |
M |
Yes |
| Dialogs for Link Based Information |
3.5.3.3.2.2 |
Publish Link Status Information |
Subscription:O |
No |
| Dialogs for Link Based Information |
3.5.3.3.2.3 |
Subscribe to Link Status Information |
Subscription:O |
No |
Note: UN ID: 2.5.2.2
User Need: Travel Time Data for Roads
- Identify the rows that contain a reference to the mandatory requirements, and cross out/delete those rows that are not project-relevant for the deployment. For this example the rows corresponding to requirements 3.5.3.3.2.2 and 3.5.3.3.2.3 are crossed since those requirements were not selected, as shown below.
Table 14. Rows Containing a Reference to the Mandatory Requirement.
| RTSMIP-DXFS Requirement ID |
Requirement |
DC Type |
TMDD Vol II DC Instance Name |
TMDD Vol II DC ID |
TMDD Vol II DC Class Name |
| 3.5.3.3.2.1 |
Send Link Status Information Upon Request |
dialog |
dlLinkStatusRequest |
3.1.13.2 |
dlLinkStatusRequest |
3.5.3.3.2.2 |
Publish Link Status Information |
dialog |
dlLinkStatusUpdate |
3.1.34.2 |
dlLinkStatusUpdate |
3.5.3.3.2.3 |
Subscribe to Link Status Information |
dialog |
dlTrafficNetworkInformationSubscription |
3.1.19.1 |
dlTrafficNetworkInformationSubscription |
Note: Dialogs for:
- UN 2.5.2.1 Speed Data for Roads.
- UN 2.5.2.2 Travel Time Data for Roads.
- UN 2.5.2.3 Speed Data for Public Traveler Information Providers.
- UN 2.5.2.4 Travel Time Data for Public Traveler Information Providers.
- UN 2.5.2.5 Travel Time Data for Parties who Create Value added Information Products.
- UN 2.5.7.1 Roadway Network and Device Information.
- Identify the data concepts that are mandatory for the deployment. For the example, continue editing the RTM section for the rest of the mandatory requirements. Table 15 below shows the RTM tailored to identify project-relevant design (i.e., those data concepts from the standards within the scope of the project) that fulfill the requirements identified in the tailored NRTM. Data concepts (dialogs and message content) that are not indicated as mandatory in the NRTM, have been crossed out in the tailored RTM.
Table 15. RTM for TMDD Design Reference before Tailoring
 |
RTSMIP-DXFS Requirement ID |
Requirement |
DC Type |
TMDD Vol II DC Instance Name |
TMDD Vol II DC ID |
TMDD Vol II DC Class Name |
|
3.5.3.3.2.1 |
Send Link Status Information Upon Request |
dialog |
dlLinkStatusRequest |
3.1.13.2 |
dlLinkStatusRequest |
|
3.5.3.3.2.2 |
Publish Link Status Information |
dialog |
dlLinkStatusUpdate |
3.1.34.2 |
dlLinkStatusUpdate |
|
3.5.3.3.2.3 |
Subscribe to Link Status Information |
dialog |
dlTrafficNetworkInformationSubscription |
3.1.19.1 |
dlTrafficNetworkInformationSubscription |
| Request Message |
3.5.3.3.2.4 |
Contents of the Link Status Request |
message |
trafficNetworkInformationRequestMsg |
3.2.19.1 |
trafficNetworkInformationRequestMsg |
| Request Message |
3.5.3.1.1 |
Contents of the Traffic Network Information Request |
message |
trafficNetworkInformationRequestMsg |
3.2.19.1 |
trafficNetworkInformationRequestMsg |
| Request Message |
3.5.3.1.1 |
Contents of the Traffic Network Information Request |
data-frame |
TrafficNetworkInformationRequest |
3.3.20.1 |
TrafficNetworkInformationRequest |
| Request Message |
3.5.3.1.1.1 |
Required Traffic Network Information Request Content |
data-frame |
organization-requesting |
3.3.16.3 |
OrganizationInformation |
| Request Message |
3.5.3.1.1.1 |
Required Traffic Network Information Request Content |
data-element |
network-information-type |
3.4.20.2 |
Transportation-network-information-type |
| Request Message |
3.5.3.1.1.2.1 |
Authentication |
data-frame |
authentication |
3.3.3.1 |
Authentication |
| Request Message |
3.5.3.1.1.2.1.1 |
Operator Identifier |
data-element |
operator-id |
3.4.16.8 |
Organization-resource-identifier |
| Request Message |
3.5.3.1.1.2.2 |
Roadway Network Identifier |
data-element |
network-identifiers |
3.4.20.1 |
Transportation-network-identifier |
| Request Message |
3.5.3.1.1.2.3 |
Traffic Network Identifier |
data-element |
roadway-network-id-list |
3.4.20.1 |
Transportation-network-identifier |
| Response Message |
3.5.3.3.2.5 |
Contents of the Link Status Information |
message |
linkStatusMsg |
3.2.13.2 |
linkStatusMsg |
| Response Message |
3.5.3.3.2.5.1 |
Required Link Status Information Content |
data-element |
link-id |
3.4.20.1 |
Transportation-network-identifier |
| Response Message |
3.5.3.3.2.5.1 |
Required Link Status Information Content |
data-element |
link-status |
3.4.14.34 |
Link-status |
| Response Message |
3.5.3.3.2.5.1 |
Required Link Status Information Content |
data-element |
network-id |
3.4.20.1 |
Transportation-network-identifier |
| Response Message |
3.5.3.3.2.5.1 |
Required Link Status Information Content |
data-frame |
organization-information |
3.3.16.3 |
OrganizationInformation |
| Response Message |
3.5.3.3.2.5.2.1 |
Restrictions |
data-frame |
restrictions |
3.3.16.5 |
Restrictions |
| Response Message |
3.5.3.3.2.5.2.2 |
Link Name |
data-element |
link-name |
3.4.21.1 |
Transportation-network-name |
| Response Message |
3.5.3.3.2.5.2.3 |
Link Direction |
data-element |
link-direction |
3.4.14.9 |
Link-direction |
| Response Message |
3.5.3.3.2.5.2.4 |
Link Travel Time |
data-element |
travel-time |
3.4.14.37 |
Link-travel-time |
| Response Message |
3.5.3.3.2.5.2.5 |
Link Average Speed |
data-element |
speed-average |
3.4.14.31 |
Link-speed-average |
| Response Message |
3.5.3.3.2.5.2.6 |
Link Estimated Speed |
data-element |
speed-vehicle-estimated |
3.4.8.43 |
Event-speed-vehicle-estimated |
| Response Message |
3.5.3.3.2.5.2.7 |
Link Speed Limit |
data-element |
speed-limit |
3.4.14.32 |
Link-speed-limit |
| Response Message |
3.5.3.3.2.5.2.8 |
Link Current Advisory Speed |
data-element |
advisory-speed-limit |
3.4.14.32 |
Link-speed-limit |
| Response Message |
3.5.3.3.2.5.2.9 |
Link Truck Speed Limit |
data-element |
truck-speed-limit |
3.4.14.32 |
Link-speed-limit |
| Response Message |
3.5.3.3.2.5.2.10 |
Speed Limit Units |
data-element |
speed-limit-units |
3.4.14.33 |
Link-speed-limit-units |
| Response Message |
3.5.3.3.2.5.2.11 |
Status Date and Time Change Information |
data-frame |
last-update-time |
3.3.10.1 |
DateTimeZone |
| Error Report Message |
3.4.4.1 |
Contents of theError Report |
message |
errorReportMsg |
3.2.3.3 |
errorReportMsg |
| Error Report Message |
3.4.4.1.1 |
Required Error Report Contents |
data-frame |
errorReport |
3.3.3.4 |
ErrorReport |
| Error Report Message |
3.4.4.1.1 |
Required Error Report Contents |
data-element |
error-code |
3.4.3.1 |
Error-report-code |
| Error Report Message |
3.4.4.1.1 |
Required Error Report Contents |
data-element |
error-text |
3.6.6.15 |
c2c:InformationalText |
| Error Report Message |
3.4.4.1.2.1 |
Restrictions |
data-frame |
restriction |
3.3.16.5 |
Restrictions |
| Error Report Message |
3.4.4.1.2.1 |
Restrictions |
data-element |
organization-information-forwarding-restrictions |
3.4.16.5 |
organization-information-forwarding-restrictions |
Note: Dialogs for:
- UN 2.5.2.1 Speed Data for Roads.
- UN 2.5.2.2 Travel Time Data for Roads.
- UN 2.5.2.3 Speed Data for Public Traveler Information Providers.
- UN 2.5.2.4 Travel Time Data for Public Traveler Information Providers.
- UN 2.5.2.5 Travel Time Data for Parties who Create Value added Information Products.
- UN 2.5.7.1 Roadway Network and Device Information.
