Real-Time System Management 

Information Program Data Exchange 

Format Specification 

Implementation Guidance

August 2013
Produced by DTFH61-06-D-00004 Real-Time System Management Information Program 

Data Exchange Format Specification Implementation and Guidance 

U.S. Department of Transportation

Notice

This document is disseminated under the sponsorship of the U.S. 

Department of Transportation in the interest of information exchange. 

The U.S. Government assumes no liability for the use of the information 

contained in this document.

The U.S. Government does not endorse products or manufacturers. 

Trademarks or manufacturers’ names appear in this report only because 

they are considered essential to the objective of the document.

Quality Assurance Statement 

The Federal Highway Administration (FHWA) provides high-quality 

information to serve Government, industry, and the public in a manner 

that promotes public understanding. Standards and policies are used to 

ensure and maximize the quality, objectivity, utility, and integrity of its 

information. FHWA periodically reviews quality issues and adjusts its 

programs and processes to ensure continuous quality improvement.
Technical Report Documentation Page

1. Report No.

FHWA-HOP-13-046

2. Government Accession No. 3. Recipient’s Catalog No.

4. Title and Subtitle

Real-Time System Management Information Program Data Exchange 

Format Specification 

Implementation Guidance

5. Report Date

August 2013

6. Performing Organization Code

7. Author(s)

Consensus Systems Technologies (“ConSysTec”) and Cambridge 

Systematics, Inc.

8. Performing Organization Report No.

9. Performing Organization Name And Address

Consensus Systems Technologies Cambridge Systematics, Inc.

17 Miller Avenue / POB 517 4800 Hampden Lane, Suite 800

Shenorock, NY 10587 Bethesda, MD 20814

10. Work Unit No. (TRAIS)

11. Contract or Grant No.

DTFH61-06-D-00004

12. Sponsoring Agency Name and Address

U.S. Department of Transportation

Federal Highway Administration

Office of Operations

1200 New Jersey Ave., SE

Washington, DC 20590

13. Type of Report and Period Covered

14. Sponsoring Agency Code

HOP

15. Supplementary Notes

The Government GTM on this work was Robert Rupert.

16. Abstract

Section 1201 of SAFETEA-LU, published in August 2005, instructed the Secretary of Transportation to establish 

a real-time system management information program to provide, in all states, the capability to monitor, in realtime, the traffic and travel conditions of the major highways of the United States and to share that information to 

improve the security of the surface transportation system, to address congestion problems, to support improved 

response to weather events and surface transportation incidents, and facilitate national and regional highway 

traveler information.

In response to these requirements, U.S. Code of Federal Regulations (CFR) 23 Part 511 was developed. Title 23 

CFR Part 511 requires each state to establish and operate a Real-Time System Management Information Program 

(RTSMIP) capable of gathering and making available the data for traffic and travel conditions. However, Title 23 

CFR 511 does not require the dissemination of real-time information in any particular manner, only that the states 

make the information available. It also does not require states to apply any particular technology, technologydependent application, or business model for collecting, processing and disseminating information. As a result, 

development of a Data Exchange Format Specification (DXFS) and implementation guidance was initiated to 

support the need of states for a specification that satisfies the essential elements of the rule.

In 2011, U.S. DOT began development of the Data Exchange Format Specification (DXFS) to facilitate the 

development of interoperable real-time traffic and travel information between public agencies, with other public 

agencies, and with private entities. The DXFS has been developed to assist users to specify and then develop an 

RTSMIP implementation.

17. Key Words

DXFS, RTSMIP, real-time information

18. Distribution Statement

No restrictions.

19. Security Classif. (of this report)

Unclassified

20. Security Classif. (of this page)

Unclassified

21. No. of Pages

80

22. Price

N/A

Form DOT F 1700.7 (8-72) Reproduction of completed page authorized

iii

TABLE OF CONTENTS

EXECUTIVE SUMMARY...........................................................................................................1

REAL-TIME SYSTEM MANAGEMENT INFORMATION PROGRAM (RTSMIP) 1

DATA EXCHANGE FORMAT SPECIFICATION (DXFS) .......................................... 1

USERS OF THE DXFS ....................................................................................................... 2

1. INTRODUCTION ................................................................................................................3

1.1 BACKGROUND ......................................................................................................... 3

1.2 DATA EXCHANGE FORMAT SPECIFICATION (DXFS) ................................. 4

1.2.1 Objectives of the DXFS.................................................................4

1.2.2 Scope of the DXFS.........................................................................4

1.3 SCOPE OF THE DXFS IMPLEMENTATION GUIDE ........................................ 5

1.4 USERS OF THE DXFS IMPLEMENTATION GUIDE......................................... 5

1.5 DOCUMENT ORGANIZATION AND USE........................................................... 5

2. USER NEEDS IDENTIFICATION ....................................................................................9

2.1 BACKGROUND ......................................................................................................... 9

2.1.1 User Needs Organization............................................................10

2.2 USER NEEDS SELECTION GUIDANCE ............................................................ 13

2.3 USER NEEDS SELECTION EXAMPLE .............................................................. 14

3. REQUIREMENTS IDENTIFICATION ..........................................................................15

3.1 BACKGROUND ....................................................................................................... 15

3.1.1 Needs to Requirements Traceability Matrix (NRTM) ............15

3.1.2 Using the NRTM to Specify a DXFS System Interface ...........16

3.2 REQUIREMENTS SELECTION GUIDANCE .................................................... 17

3.3 REQUIREMENTS SELECTION EXAMPLE ...................................................... 19

4. SYSTEM DESIGN REFERENCE....................................................................................27

4.1 BACKGROUND ....................................................................................................... 27

4.1.1 Standards Referenced by the DXFS..........................................27

4.1.2 Requirements Traceability Matrix............................................30

4.1.3 Instructions for Completing the RTM ......................................31

4.2 SYSTEM DESIGN REFERENCE GUIDANCE ................................................... 32

4.3 SYSTEM DESIGN REFERENCE EXAMPLE..................................................... 33

5. IMPLEMENTATION ISSUES .........................................................................................41
iv

5.1 A COMMUNICATIONS FRAMEWORK FOR DXFS........................................ 41

5.2 ACHIEVING INTEROPERABILITY ................................................................... 43

5.3 COMMUNICATIONS DIALOGS RELATED TECHNOLOGIES.................... 44

5.3.1 The Application Level: Defining Message Patterns, Message 

Encoding, and Message Transport .......................................................44

5.4 INTEGRATING LEGACY SYSTEMS.................................................................. 47

5.4.1 Interfacing Systems that Do Not Support TCIP/IP.................47

5.4.2 Handling Unavailable or Missing Data.....................................48

6. TESTING.............................................................................................................................49

6.1 INTRODUCTION..................................................................................................... 49

6.1.1 DXFS Conformance ....................................................................50

6.1.2 Compliance with a DXFS Project Specification.......................50

6.1.3 Test Phases...................................................................................50

6.2 TEST DOCUMENTATION .................................................................................... 51

6.2.1 Standards that Support Test Documentation...........................51

6.2.2 Example Test Documentation Framework for a DXFS 

Implementation.......................................................................................52

6.3 TEST PLAN .............................................................................................................. 55

6.4 TEST DESIGN SPECIFICATIONS....................................................................... 57

6.5 TEST CASE SPECIFICATIONS............................................................................ 58

6.5.1 Example Requirements to Test Case Traceability Matrix 

(RTCTM).................................................................................................59

6.5.2 Example Test Case Specification ...............................................60

6.6 TEST PROCEDURE SPECIFICATIONS............................................................. 64

6.6.1 Example Test Procedure Specification......................................65

6.7 TEST REPORTS ...................................................................................................... 66

6.8 SUMMARY ............................................................................................................... 66

APPENDIX A. LIST OF ACRONYMS....................................................................................67

APPENDIX B. ACKNOWLEDGMENTS................................................................................69
v

LIST OF TABLES

Table 1. Conformance Symbols.................................................................................................... 16

Table 2. Predicate Notation........................................................................................................... 17

Table 3. Project Relevant User Needs. ......................................................................................... 19

Table 4. Dialogs for Link Based Information............................................................................... 19

Table 5. Request Message............................................................................................................. 20

Table 6. Request Message............................................................................................................. 20

Table 7. Error Report Message. .................................................................................................... 20

Table 8. Response Message. ......................................................................................................... 21

Table 9. NRTM Prior to Tailoring................................................................................................ 22

Table 10. NRTM with Tailoring of Project-Relevant Requirements. .......................................... 24

Table 11. Information Level Standards Referenced by the RTSMIP DXFS – “DXFS Information 

Level Standards.”.......................................................................................................................... 27

Table 12. Line of the RTM that Corresponds to One Requirement.............................................. 33

Table 13. Rows for Mandatory Requirements.............................................................................. 34

Table 14. Rows Containing a Reference to the Mandatory Requirement. ................................... 34

Table 15. RTM for TMDD Design Reference before Tailoring................................................... 36

Table 16. Example Portion of a Test Design Specification.......................................................... 58

Table 17. Example Requirements to Test Case Traceability Matrix............................................ 59

Table 18. Example Test Case Specification. ................................................................................ 60

Table 19. Example Test Case Input Specification........................................................................ 62

Table 20. Example Test Case Output Specification. .................................................................... 63

Table 21. Example Test Procedure Specification. ........................................................................ 65

vii

LIST OF FIGURES

Figure 1. Diagram. Suggested Process for using the DXFS........................................................... 7

Figure 2. Diagram. RTSMIP Context Diagram.............................................................................. 9

Figure 3. Diagram. A Communications Framework for the RTSMIP DXFS. ............................. 42

Figure 4. Diagram. IEEE 829-1998-based Test Documentation Framework for the 

RTSMIP DXFS............................................................................................................................. 53

Figure 5. Message. Example trafficNetworkInformationRequestMsg Request Message Test Case 

Data File........................................................................................................................................ 62

Figure 6. Message. Example linkStatusInformationMsg Response Message Test Case 

Data File........................................................................................................................................ 64

1

EXECUTIVE SUMMARY

REAL-TIME SYSTEM MANAGEMENT INFORMATION PROGRAM (RTSMIP)

Section 1201 of the Safe, Accountable, Flexible, Efficient Transportation Equity Act: A Legacy 

for Users (SAFETEA-LU), published in August 2005, instructed the Secretary of Transportation

to “... establish a real-time system management information program (RTSMIP) to provide, in

all states, the capability to monitor, in real-time, the traffic and travel conditions of the major

highways of the United States and to share that information to improve the security of the surface 

transportation system, to address congestion problems, to support improved response to weather 

events and surface transportation incidents, and facilitate national and regional highway traveler 

information.” Additional information about Section 1201 is available at 

http://www.ops.fhwa.dot.gov/1201/.(1)

In response to these requirements, U.S. Code of Federal Regulations (CFR) 23 Part 511 was 

developed. Title 23 CFR Part 511 requires each state to establish and operate a Real-Time 

System Management Information Program (RTSMIP) as part of its Intelligent Transportation 

System (ITS) capable of gathering and making available the data for traffic and travel conditions.

However, Title 23 CFR 511 does not require the dissemination of real-time information in any 

particular manner, only that the states make the information available. It also does not require 

states to apply any particular technology, technology-dependent application, or business model 

for collecting, processing and disseminating information. As a result, development of a Data 

Exchange Format Specification (DXFS) and implementation guidance was initiated to support 

the need of states for a specification that satisfies the essential elements of the rule.

DATA EXCHANGE FORMAT SPECIFICATION (DXFS)

In 2011, U.S. DOT began development of the Data Exchange Format Specification (DXFS) to 

facilitate the development of interoperable real-time traffic and travel information between 

public agencies, with other public agencies, and with private entities.

A primary objective of the DXFS is to establish a standards-based specification of key RTSMIP 

interfaces. To align with the objective the scope of the DXFS is the set of interfaces used to send 

traffic, transit, transportation-related weather, and traveler information from one agency to 

another. The provision of this data directly to travelers is not part of the scope of the 

specification. While the DXFS covers all the information defined in Rule 23 CFR 511, the scope 

of the DXFS has been expanded beyond the information defined in the rule to include transit 

information and additional traffic information that is relevant to the exchange of data between 

agencies (and other parties). The DXFS is a specification that can be used to define the 

information exchanges across a system-to-system interface, thus providing interoperability of 

 

(1) Real-Time System Management Information Program – FHWA Operations, 

http://www.ops.fhwa.dot.gov/1201/.
2

systems that implement the DXFS. The DXFS does not specify communication protocols, but it 

does refer to existing standardized protocols that can be used for transferring the data.

USERS OF THE DXFS

The DXFS has been developed to assist the following groups of users to specify and then 

develop an RTSMIP implementation:

• Transportation Agencies. This group includes state DOTs and regional transportation 

related organizations (e.g., a municipal DOT or Public Works or a transit agency) that are 

developing systems that implement aspects of the RTSMIP.

• Public Safety Agencies. This group includes state, county, or local public safety agencies 

that develop systems that support RTSMIP.

• Traveler Information Organizations (Public or Private). This group includes providers of 

traveler information whether public or private that are involved in the development of 

systems that support RTSMIP.

• Development Contractors. This group includes contractors who have been hired by 

transportation or public safety agencies to develop procurement packages that would specify 

aspects of RTSMIP, or contractors who have been selected to perform the development of 

RTSMIP related projects.
3

1. INTRODUCTION

1.1 BACKGROUND

This document is a guide on how to use the Data Exchange Format Specification (DXFS) for 

specifying implementation of Real-Time System Management Information Program (RTSMIP) 

at a state or regional level. The background below explains the context under which RTSMIPs 

are developed. The following section explains the nature and scope of the DXFS.

Section 1201 of the Safe, Accountable, Flexible, Efficient Transportation Equity Act: A Legacy 

for Users (SAFETEA-LU), published in August 2005, instructed the Secretary of Transportation

to “... establish a real-time system management information program (RTSMIP) to provide, in

all states, the capability to monitor, in real-time, the traffic and travel conditions of the major

highways of the United States and to share that information to improve the security of the surface 

transportation system, to address congestion problems, to support improved response to weather 

events and surface transportation incidents, and facilitate national and regional highway traveler 

information.”

A Final Rule was published on November 8, 2010, establishing the provisions and parameters for 

the Real-Time System Management Information Program to be established by State DOTs, other 

responsible agencies, and partnerships with other commercial entities. The Program is to be 

established on all Interstate routes within 4 years (November 8, 2014) and on other significant 

roadways as identified by the States and local agencies within 6 years (November 8, 2016).

In response to these requirements, U.S. Code of Federal Regulations (CFR) 23 Part 511 was 

developed. 23 CFR Part 511 requires each state to establish and operate a RTSMIP as part of its 

Intelligent Transportation System (ITS). Title 23 CFR 511 does not require the dissemination of 

real-time information in any particular manner, only that the states make the information 

available. It also does not require states to apply any particular technology, technologydependent application, or business model for collecting, processing and disseminating 

information. As a result, development of a DXFS and implementation guidance was initiated to 

support the need of states for a specification that satisfies the essential elements of the rule.

Title 23 CFR 511 requires that real-time information programs be capable of gathering and 

making available the data for traffic and travel conditions.

The DXFS specification and additional information about Section 1201 is available at 

http://www.ops.fhwa.dot.gov/1201/.(2)

It is recommended that this document be used side-by-side or with a copy of the DXFS 

specification handily available.

 

(2) Real-Time System Management Information Program – FHWA Operations, 

http://www.ops.fhwa.dot.gov/1201/.
4

1.2 DATA EXCHANGE FORMAT SPECIFICATION (DXFS)

1.2.1 Objectives of the DXFS

Section 1201 required the Secretary to establish data exchange formats to ensure that the data 

provided by highway and transit monitoring systems, including statewide incident reporting 

systems, can readily be exchanged across jurisdictional boundaries; facilitating nationwide 

availability of information. In 2011, U.S. DOT began development of the Data Exchange Format 

Specification (DXFS) to facilitate the development of interoperable real-time traffic and travel 

information between public agencies, with other public agencies, and with private entities.

The objective of the DXFS is to create a standards-based definition of key RTSMIP interfaces.

This approach addresses three major issues that threaten center to center exchanges of real-time 

information:

• More than one standard (as well as proprietary solutions) may exist to encode and define the 

same information. For example incident information could be defined by data concepts from 

Traffic Management Data Dictionary (TMDD) or from IEEE 1512- Standard for Common 

Incident Management Message Sets for use by Emergency Management Centers. An 

agreement must be reached between each pair of agencies or regionally as to what encoding, 

meaning (derivation), and logical relationships are to be used to describe the information for 

information exchanges to be effective.

• Each agency may have its own goals and objectives for the data it collects, and the data 

quality attributes (metadata) will likely be adjusted to meet the intended local uses of the 

data. Data with inadequate quality attributes may be of little or no value to agencies in other 

regions. There is no agency/entity expectation as to data quality received from other entities, 

nor is there a uniformly accepted method for representing data quality (metadata).

• There may be competing methods for communicating encoded transportation information 

between entities. While today structured implementations of XML are popular over the 

Internet, there are still organizations that have substantial investments in ASN.1.

The RTSMIP DXFS was developed to eliminate all the above uncertainties and thus measurably 

accelerate the investment in and deployment of ITS systems that can share real-time traffic and 

travel conditions information effectively between public entities, or between public and private 

entities. The RTSMIP DXFS has been developed with consideration of the many stakeholders’

independent goals and objectives. A systems engineering process of verification and especially 

validation at each key stage of the RTSMIP DXFS development was employed to achieve this 

stakeholder focused result.

1.2.2 Scope of the DXFS

The DXFS is a detailed specification of the key interfaces defined as part of the RTSMIP (which 

are discussed in Section 2.3). The DXFS is not a new ITS standard; rather it is a specification of 

existing ITS standards that can address a set of user needs which support a RTSMIP. For 

example the existing ITS standard Traffic Management Data Dictionary (TMDD) is specified by 

the DXFS to address many of the needs/ requirements relevant to providing RTSMIP. As 
5

discussed in the previous section, the DXFS is meant to remove uncertainty regarding which 

standard to apply to a specific interface, facilitating national interoperability in providing data to 

support RTSMIP.

The Scope of the DXFS is the set of interfaces used to send traffic, transit, and traveler 

information from one agency to another. The provision of this data directly to travelers is not 

part of the scope of the specification. While the DXFS covers all the information defined in Rule 

23 CFR 511, the scope of the DXFS has been expanded beyond the information defined in the 

rule to include transit information and additional traffic information that is relevant to the 

exchange of data between agencies (and other parties). The DXFS is an information level 

specification, meaning that it defines a set of data concepts (dialogs, messages, data frames and 

data elements) that can be used to exchange data on an interface. The DXFS does not specify 

communication protocols, but it does refer to existing standardized protocols that can be used for 

transferring the data.

1.3 SCOPE OF THE DXFS IMPLEMENTATION GUIDE

The objective of the DXFS Implementation Guide is to provide guidance to public agencies and 

private organizations on how to use the DXFS. This document provides a guide to using the 

DXFS to specify an implementation. The intent of the Guide is to provide recommendations for 

how to move toward full implementation of Data Exchange Formats.

1.4 USERS OF THE DXFS IMPLEMENTATION GUIDE

The DXFS Implementation Guide has been developed to assist the following groups of users in 

specifying and then developing an RTSMIP implementation:

• Transportation agency. This group includes state DOTs and regional transportation related 

organizations (e.g., a municipal DOT or Public Works or a transit agency) that are 

developing systems that implement aspects of the RTSMIP.

• Public safety agency. This group includes state, county, or local public safety agencies that

develop systems that support RTSMIP.

• Traveler information organizations (public or private). This group includes providers of 

traveler information whether public or private that are involved in the development of 

systems that support RTSMIP.

• Development contractors. This group includes contractors who have been hired by a 

transportation or public safety agencies to develop procurement packages that would specify 

aspects of RTSMIP, or contractors who have been selected to perform the development of 

RTSMIP related projects.

1.5 DOCUMENT ORGANIZATION AND USE

This document is organized into 6 sections. 
6

• Section 1: Introduction. This section provides introductory and background information 

about SAFETEA-LU Section 1201, the Real Time System Management Information

Program (RTSMIP), and the Data Exchange Format Specification (DXFS). 

• Section 2: User Needs Identification. This section provides summary background 

information from the Concept of Operations in the DXFS document as well as summary of 

user needs from the DXFS Concept of Operations. It also starts an example that is followed 

throughout the remaining sections of the guidance document to describe how to tailor the 

DXFS to satisfy regional needs from user needs identification to testing.

• Section 3: Requirements Identification. This section provides summary background 

information from the Requirements section of the DXFS document. This section next 

provides guidance on how to use the Needs to Requirements Traceability Matrix to identify 

requirements from DXFS to define information exchanges between centers, including private 

agencies. Finally the example is continued the with mapping of needs to requirements.

• Section 4: System Design Reference. This section provides summary background 

information from the Design Reference section of the DXFS document. The section next 

provides guidance on how to trace into and document the design sections of existing 

standards to build DXFS dialogs and messages. Finally, the example is continued with the 

mapping of requirements to design concepts.

• Section 5: Implementation Issues. This section discusses the two key center-to-center 

standards, NTCIP 2304 and NTCIP 2306, used to describe how to encode and transport 

information messages, and provides a discussion of technical issues relevant to deployment 

of a DXFS-based system interface.

• Section 6: Testing. This section provides guidance on DXFS system interface testing, and 

includes information on how to develop test documentation. This section also completes an 

example started in Section 3.

The goal of this implementation guide is to explain the suggested process the user should follow 

in using the DXFS. The suggested process, which will be expanded upon in each of the 

following sections is shown in Figure 1.
7

Figure 1. Diagram. Suggested Process for using the DXFS.

(Source: Consensus Systems Technologies.)

9

2. USER NEEDS IDENTIFICATION

User Needs are the entry point to using the DXFS to create a tailored DXFS within a region for 

the purposes of defining real-time transportation information exchange among transportation 

agencies and with the private sector.

2.1 BACKGROUND

The DXFS has been developed using a systems engineering process. The first step in the process 

was to develop a concept of operations that “provides the reader with a detailed description of 

the scope of the RTSMIP, the user needs which the RTSMIP will address, and the operational 

scenarios that consider the center to center interfaces that will be a part of RTSMIP.”

In addition to the user needs, which are discussed below, the ConOps provides useful context 

regarding how the DXFS supports the deployment of an RTSMIP. The ConOps contains 

discussion of the Stakeholders who will create, process, and use the real time information that 

makes up the RTSMIP.

Figure 2 shows the context diagram from the ConOps that describes the systems that would be 

involved in the collection and dissemination of travel and traffic conditions.

Peer Transportation 

Agency Systems

Public Safety 

Agency Systems

Other Public 

Agency Systems

Transportation Travelers

Agency Systems 

Public Traveler Information 

Provider Systems

Private Data Collection 

Organization Systems

Transit Agency 

Systems Private Third-Party Systems

Figure Key

Interfaces that will be the subject of the DXFS

Additional interfaces discussed in ConOps

Figure 2. Diagram. RTSMIP Context Diagram.

(Source: Consensus Systems Technologies.)
10

The solid lines in the figure represent those interfaces that will become the subject of the Data 

Exchange Format Specification (DXFS), which will be the output of this project. The dashed 

lines represent additional interfaces that will be discussed in this ConOps as part of the overall 

description of the RTSMIP.

Finally the ConOps contains a set operational scenarios which provide an overview of the system 

processes. They comprise the sequence of steps taken as actors (users, stakeholders) to 

accomplish tasks and pass information to another actor. These operational scenarios represent 

only a subset of the total possible, but the set included in the DXFS cover all the DXFS User 

Needs. The operational scenarios also provide the rationale for the user need from an operational 

perspective. While the collection of real time data by transportation or transit agencies and the 

data distribution to travelers may involve internal interfaces (e.g., collection of speed data from 

agency owned field devices), these internal interfaces are not the focus of the operational 

scenarios. Rather the operational scenarios focus on the center to center interfaces that are used 

for the collection and distribution of data to satisfy user needs.

2.1.1 User Needs Organization

The DXFS User Needs are organized around the four areas described in Title 23 CFR 511, with 

two additional areas; one to address transit related information that is not directly covered by the 

CFR and to cover road network information, which is needed to address the other need 

categories. The six need categories are:

• Travel Time.

• Incident Information.

• Construction Information.

• Weather Information.

• Transit Information.

• Road Network Information.

The sections below summarize the user needs identified in the DXFS ConOps. Each section 

heading below is followed by a bullet-list containing the user need identifier (paragraph in the 

DXFS) and user need title in bold, followed by the user need text.

2.1.1.1 Travel Time User Needs:

• 2.5.2.1 Speed Data for Roads. Transportation agencies need to receive speed data on roads 

(both limited access and arterials) so the transportation agency can manage the road network 

in order to reduce recurring and non-recurring congestion. 

• 2.5.2.2 Travel Time Data for Roads. Transportation agencies need to receive travel time 

data on roads (limited access and arterials) in order to provide this information to travelers 

through roadway devices (e.g., DMS, HAR, and Connected Vehicle RSUs) and through 

traveler information outlets (e.g., 511, websites, social media).

• 2.5.2.3 Speed Data for Public Traveler Information Providers. Traveler information 

providers need to receive speed data on limited access or arterial roads in order to provide 

this information to travelers.
11

• 2.5.2.4 Travel Time Data for Public Traveler Information Providers. Traveler 

information providers need to receive travel time data on limited access or arterial roads.

• 2.5.2.5 Travel Time Data for Parties who Create Value added Information Products.

Transportation agencies and public traveler information providers need to make travel time 

data available to other parties who deliver value-added information products (e.g., third 

party providers).

• 2.5.2.6 Transit Vehicle Travel Time. Transit Agencies need to provide transit vehicle travel 

times to travelers, travel information providers and other parties. This capability is intended 

to provide transit users with the travel times they can expect to experience as they use 

the system.

2.1.1.2 Incident Information User Needs:

• 2.5.3.1 Incident Information from Public Safety for Network Management.

Transportation agencies need to receive incident information from public safety centers to 

support management of the network. Incident information includes lane or road closures.

• 2.5.3.2 Incident Information from Public Safety for Traveler Information.

Transportation agencies need to receive incident information from public safety to provide 

information regarding the incident to travelers via roadway devices (e.g., DMS, HAR, and 

Connected Vehicle RSUs) and through traveler information outlets (e.g., 511, websites, 

social media).

• 2.5.3.3 Incident Information from Transportation Agencies for Public Safety Centers.

Public Safety Centers need to receive incident information from transportation agencies.

• 2.5.3.4 Incident Information from Peer Transportation Agencies. Transportation agencies 

need to receive incident information from peer transportation agencies, including transit 

agencies, regarding incidents on the networks managed by the peer transportation agency or 

operated on in the case of a transit agency to support regional incident management.

• 2.5.3.5 Incident Information for Transit Agencies. Transit agencies need to receive 

information on incidents so they can reroute or inform passengers of delays if necessary.

• 2.5.3.6 Incident Information for Public Traveler Information Providers. Public Traveler 

information providers need to receive incident information on the road network in order to 

create traveler information outputs for use by travelers or transportation agencies.

• 2.5.3.7 Incident Information for Parties who Create Value added Information Products.

Transportation agencies and public traveler information providers need to make incident 

information available to other parties who deliver value-added information products (e.g.,

private third party providers).

• 2.5.3.8 Planned Event Information for Traveler Information. Transportation agencies 

need to receive planned event information in order to provide this information to travelers 

through roadway devices (e.g., DMS, HAR, and Connected Vehicle RSUs) and through 

traveler information outlets (e.g., 511, websites, social media).

• 2.5.3.9 Planned Event Information for Peer Transportation Agencies and Other Parties.

Transportation agencies need to distribute planned event information to peer transportation 

agencies, public traveler information providers, and private third parties.
12

2.1.1.3 Construction Information User Needs:

• 2.5.4.1 Construction Information for Traveler Information. Transportation agencies need 

to receive construction information relating to current road or lane closures due to 

construction in order to provide this information to travelers through roadway devices (e.g.,

DMS, HAR, or Connected Vehicle RSUs) and through traveler information outlets (e.g., 511, 

websites, social media). 

• 2.5.4.2 Construction Information for Road Management. Transportation agencies need to 

receive construction information relating to current road or lane closures due to construction 

in order to implement road management and rerouting strategies.

• 2.5.4.3 Construction Information for Peer Transportation Agencies and Other Parties.

Transportation agencies need to provide information relating to current road or lane closures 

due to construction to peer transportation agencies, public traveler information providers, 

private third party providers and other agencies. The information can include road 

restrictions.

2.1.1.4 Weather Information User Needs:

• 2.5.5.1 Road Weather Environmental Conditions Data to support Traveler 

Information. Transportation agencies need to collect road weather environmental conditions 

data in order to create weather related traveler information to provide to travelers via 

roadway devices (e.g., DMS, HAR, and Connected Vehicle RSUs) and through traveler 

information outlets (e.g., 511, websites, social media).

• 2.5.5.2 Road Weather Environmental Conditions Data for Maintenance Operations.

Transportation agencies need to collect road weather environmental conditions data to 

perform weather related maintenance operations such as roadway treatment and snow 

removal.

• 2.5.5.3 Receive Forecasts of Upcoming Adverse Weather Related Conditions.

Transportation agencies need to receive forecasts of upcoming adverse weather related 

conditions (e.g., ice, snow, fog, heavy rain) in order to provide information to travelers via 

roadway devices (e.g., DMS, HAR, and Connected Vehicle RSUs) and through traveler 

information outlets (e.g., 511, websites, social media). The forecasts are also needed for 

maintenance operations.

• 2.5.5.4 Provide Forecasts of Upcoming Adverse Weather Related Conditions.

Transportation agencies need to send forecasts of upcoming adverse weather related 

conditions (e.g., ice, snow, fog, heavy rain) to peer transportation agencies, public traveler 

information providers, private third parties, and other agencies to support their traveler 

information services or other operations.

• 2.5.5.5 Road Weather Information for Peer Transportation Agencies and Other Parties.

Transportation agencies need to provide information about road weather (typically collected 

from an environmental sensor station or road weather information system) which might 

restrict or adversely affect travel to peer transportation agencies, public traveler information 

providers, private third parties and other public agencies (e.g., National Weather Service).
13

2.1.1.5 Transit Information User Needs:

• 2.5.6.1 Real Time Bus Locations. Transit agencies need to share real time bus locations 

with peer transportation/transit agencies, public traveler information providers, private third 

party providers, and travelers.

• 2.5.6.2 Real Time Transit Passenger Loading. Transit agencies need to share real time 

transit vehicle passenger loading with peer transit agencies, public traveler information 

providers and private third parties.

• 2.5.6.3 Predicted Bus or Train Arrival/Departure Times. Transit agencies need to share 

predicted bus or train arrival or departure times with peer transit agencies, public traveler 

information providers, and private third party providers.

2.1.1.6 Roadway Network Information User Needs:

• 2.5.7.1 Roadway Network and Device Information. To understand and interpret real time 

information relating to travel times, incidents, construction based road closures, and road 

weather information, the agencies or organizations receiving the information need to have a 

complete definition of the road network relevant to the information received.

2.1.1.7 Connection Management User Needs:

• 2.5.8.1 Verify Connection Active. Centers need to verify that a connection with another 

center is alive or active. If the connection between centers is alive then the information 

between centers is flowing and C2C functionality is working.

• 2.5.8.2 Need to Support Requests. Centers need to respond to requests for information or 

changes to information.

• 2.5.8.3 Need to Support Subscriptions. Centers need to publish information to other centers 

that have subscribed to receive the information. External centers do not have the ability to 

determine when information at an owner center has been collected or updated. But by 

subscribing to information (or information updates), the external center can receive updated 

information at regular intervals or when the information is updated.

2.2 USER NEEDS SELECTION GUIDANCE

This section provides guidance on how to begin the process of using the DXFS for specifying a 

real time information interface. User needs provide the primary initial entry point into the DXFS.

The first step in using the DXFS is to define which of the 27 user needs are provided by the set 

of interfaces being defined. Refer to the ConOps Section of the DXFS for the complete list of the 

user needs. Each is defined as a single capability for implementation. Any number of these 

capabilities may be independently selected for implementation, with one exception. The user 

need 2.5.7.1 Roadway Network and Device Information is a need that should be selected if any 

of the user needs in the following areas are selected:
14

• Travel Time.

• Incident Information.

• Construction Information.

• Weather Information.

This is because network (or device) information is essential to interpreting the information 

referenced by the other needs. In addition, the connection user needs must be selected (the only 

option is whether to select both request and subscription or just one of the needs, depending on 

the implementation).

2.3 USER NEEDS SELECTION EXAMPLE

This guidance document contains a “how to” example that will run throughout this document 

across the various phases of DXFS implementation, starting with User Needs identification and 

ending with Testing.

The user need Travel Time Data for Roads, with user needs identifier 2.5.2.2, will be traced to 

show how to use the information in the DXFS to develop a tailored specification. The user needs 

identifier is taken from the paragraph number used in the DXFS ConOps. (Note that a complete 

consideration of this example would also include the need for Roadway Network and Device 

Information, but to simplify the example this need is not included.) 

In subsequent sections of this guidance document, this user need will be used to identify 

requirements that satisfy this user need, design that fulfill the requirements, and test 

documentation that will verify the implementation of requirements, and validate the user needs in 

the deployed system interface.
15

3. REQUIREMENTS IDENTIFICATION

It may be useful for the reader to have DXFS Section 3 Functional Requirements and Annex A –

NRTM available. At this point in the process, an implementer has identified the user needs for 

DXFS information interchange. This section will discuss and demonstrate how to use the NRTM 

to identify DXFS system interface requirements.

3.1 BACKGROUND

The DXFS systems requirements (DXFS Section 3) define the formal requirements that satisfy 

all DXFS user needs. This is achieved through the development of a Needs to Requirements 

Traceability Matrix (NRTM) that traces each user need to one or more requirements.

The functional requirements are presented in two broad categories as follows:

• Data Exchange and Operational Environmental Requirements. These requirements 

define the required behavior of the system in exchanging data across the communications 

interface based upon the features identified in this document. These requirements are found 

in Sections 3.5 and 3.6 of the DXFS

• Architectural Requirements. In the context of the DXFS, these requirements define

management of the interface connections between centers. They cover connection 

management, error handling, and the two basic methods of making connections (e.g.,

request/response and subscription/publication). These requirements are found in Section 3.4 

of the DXFS).

3.1.1 Needs to Requirements Traceability Matrix (NRTM)

The Needs to Requirements Traceability Matrix (NRTM) presented in DXFS Annex A,(3)

maps 

the user needs defined in DXFS Section 2 to the requirements defined in DXFS Section 3. The 

DXFS NRTM lists each user need to be addressed by the DXFS, followed immediately by the 

requirement(s) that supports (and traces to) that user need. The table can be used by:

• A user or specification writer to indicate which requirements are to be implemented in a 

project-specific implementation.

• The interface implementer, as a checklist to reduce the risk of failure to conform to the 

standard through oversight.

• The supplier and user, as a detailed indication of the capabilities of the implementation.

• The user, as a basis for initially checking the potential interoperability with 

another implementation.

 

(3) DXFS Annex A – is contained in a separate volume.
16

3.1.2 Using the NRTM to Specify a DXFS System Interface

The DXFS is a system interface specification used to define information exchanges between a 

center and other centers. For each user need, the DXFS identifies the set of requirements that 

relate to that user need. All Mandatory requirements must be selected in order to satisfy the user 

need. Depending on the deployment some (or all, or none) of the optional requirements will 

be selected.

The NRTM contains the following columns: User Need ID and User Needs columns, 

Requirement Type, Requirement ID, Requirement, Conformance, and Support.

3.1.2.1 User Need ID and User Needs Column

The user needs are defined within the DXFS Section 2. The NRTM is based upon the user needs 

defined within Section 2 and includes the paragraph number and user need title.

3.1.2.2 Requirement Type, Requirement ID, and Requirement Columns

The requirements are defined within DXFS Section 3. The NRTM traces from a user need to one 

or more DXFS requirements. The requirement type, requirement ID (Section 3 paragraph 

number), and requirement title are indicated within these columns.

3.1.2.3 Conformance Column

The following notations and symbols are used to indicate status and conditional status in the 

NRTM within this standard. Not all of these notations and symbols are necessarily used within 

this standard.

3.1.2.4 Conformance Symbols

The following symbols are used to indicate status in the NRTM table:

Table 1. Conformance Symbols.

Symbol Value

M Mandatory – This requirement(s) is required to support the specified user 

need

M.# Support of every item of the group labeled by the same numeral # is 

required, but only one is active at a time

O Optional - This requirement may be included in support of the specified 

user need

O.# (range) Part of an option group. Support of the number of items indicated by the 
17

Table 1. Conformance Symbols.

Symbol Value

‘(range)’ is required from all options labeled with the same numeral #

N/A Not-applicable (i.e. logically impossible in the scope of the standard)

The O.# (range) notation is used to show a set of selectable options (e.g., O.2 (1..*) would 

indicate that one or more of the option group 2 options must be implemented).

Much of the DXFS NRTM is based upon the Needs to Requirements Traceability Matrix (NRTM) 

from TMDD Volume 1 (meaning that the conformance indication for requirements equals that given 

in TMDD). In some cases the entry in the DXFS NRTM is different due to the specific user need.

For example user need 2.5.2.2 Travel Time Data for Roads will have requirement 3.5.3.3.2.5.2.4 

Link Travel Time as M*, while in TMDD this requirement is O. Where the conformance 

requirement differs from TMDD the entry in the DXFS NRTM will be indicated with a “*”. 

Conditional Status Notification: Table 2 describes entries for the predicate notation that may 

be used.

Table 2. Predicate Notation.

Symbol Value

<predicate>: This notation introduces a single item that is conditional on the <predicate>.

<predicate>:: This notation introduces a table or a group of tables, all of which are conditional 

on the <predicate>.

(predicate) This notation introduces the first occurrence of the predicate either in the NRTM 

or in that specific user need. The feature associated with this notation is the base 

feature for all options that have this predicate in their conformance column.

The <predicate>: notation means that the status following it applies only when the NRTM states 

that the feature or features identified by the predicate are supported. In the simplest case, 

<predicate> is the identifying tag of a single NRTM item. When the group predicate is true then 

the associated section shall be completed. The symbol <predicate> also may be a Boolean 

expression composed of several indices – .AND., .OR., and .NOT. are used to indicate the 

Boolean logical operations.

3.2 REQUIREMENTS SELECTION GUIDANCE

The objective of this step is to select the requirements for a project, based on the user needs 

selected for the project. The selection of requirements is performed by filling out the NRTM for 
18

the project. The NRTM contains a column that identifies user needs and a corresponding column 

that identifies requirements that are mapped to a user need. The NRTM is used both as a 

traceability matrix and as a way to specify which requirements will be mandatory for a specific 

deployment. To make finding a particular need easy in the NRTM, the row that contains the user 

needs identifier (UN ID) and title is highlighted. The rows that follow then are a set of minimum 

requirements (some mandatory, some optional) that satisfy the need. Note that once an optional 

requirement is selected for a deployment, it then becomes mandatory for that individual 

deployment. The following steps may be used to fill out the NRTM for a specific project:

1. Identify the section of the NRTM that contains the User Need(s) identified as being 

project-relevant.

2. Within that section, identify the requirements that are mandatory to support the user need(s).

Mandatory requirements contain the indicator ‘M’ in the Conformance column. An M* (M 

with an asterisk is a requirement that is Optional in one the standards supporting the DXFS 

(TMDD, SIRI, TCIP, or OASIS CAP), but which is Mandatory to support the user need as 

written for the DXFS. For example, travel time is optional in the TMDD Link Status 

Message, but is Mandatory in DXFS to allow travel time to be reported and to satisfy User 

Need 2.5.2.2 Travel Time Data for Roads. All mandatory requirements relating to a need 

must be selected if the need is selected. The requirements under each user need are organize 

by the type of design they support. For example:

• The requirements to support Dialogs.

• The requirements to support Request Messages, Response Messages, or Error 

Report Messages.

3. Identify those optional requirements that will be necessary to support the deployment.

Selecting these will make them mandatory for the deployment. In general, if a requirement is 

optional in DXFS and mandatory in the deployment then highlight, circle, or box, the word 

‘Yes’ in the Support column. At this point the dialogs and information content of messages 

has been identified:

• The dialogs of the DXFS have been written such that the wording for the requirement 

adheres to the following pattern:

- Request-Response dialogs is “Send [Information or Control Message] Upon Request.

- Publication dialogs is “Publish [Information].”

- Subscription dialogs is “Subscribe [Information].”

• If the deployment will only include request-response dialogs, then only the requirement that 

reads “Send Link Status Information Upon Request” needs to be selected.

• If the deployment will use subscription-publication dialogs, then the requirements to “Publish 

Link Status Information” and “Subscribe Link Status Information” are selected.

• A project deployer may want to support all three of these dialog types. If so, the project 

deployer selects all three of the requirements relating to dialogs.
19

3.3 REQUIREMENTS SELECTION EXAMPLE

This section provides an example of how to select requirements, using the three steps identified 

above. Note Table 3 below shows the relevant page in the NRTM that contains the user need for 

the example.

1. Identify the portion of the NRTM that contains the User Need(s) identified as being projectrelevant. For this example the relevant user need is 2.5.2.2 Travel Time Data for Roads. The 

top row of Table 3 lists the User Need, the need for which we want to identify requirements 

(repeated below). Reviewing the NRTM, there are two sections of the requirements relating 

to the need. One set of requirements relates to link based travel times and one set of 

requirements relates to route based travel times. Consider in this example that the 

deployment will implement just a link based travel time. The outputs below are based on that 

assumption.

Table 3. Project Relevant User Needs.

UN ID User Need Reqmt Type Req ID Requirement Conformance Support

2.5.2.2 Travel Time Data for Roads Optional Yes/No

2. Identify the requirements that are mandatory to support the user need. For each mandatory 

requirement indicate Yes in the Support Column (as shown below). Mandatory requirements 

contain the indicator ‘M’ in the Conformance column. An M* (M with an asterisk is a 

requirements that is Optional in one of the standards supporting the DXFS (TMDD, SIRI, 

TCIP, or OASIS CAP) that is Mandatory for the DXFS. For example, travel time is optional 

in the TMDD Link Status Message, but is Mandatory in DXFS to allow travel time to be 

reported and to satisfy User Need 2.5.2.2 Travel Time Data for Roads.

Table 4. Dialogs for Link Based Information.

3.5.3.3.2.1 Send Link Status Information Upon Request M Yes / No / NA

For each user need there are four portions of the requirements to consider for Mandatory 

requirements:

• The requirements to support Dialogs.

− Requirement 3.5.3.3.2.1 Send Link Status Information Upon Request, a dialog, is 

required. (shown above).

• The requirements to support Request Messages.
20

− For the example, the following three requirements are mandatory and Yes should be 

selected in the Support column.

Table 5. Request Message.

3.5.3.3.2.4 Contents of the Link Status Request M Yes

3.5.3.1.1 Contents of the Traffic Network Information Request M Yes

3.5.3.1.1.1 Required Traffic Network Information Request Content M Yes

• The requirements to support Response Messages.

− For the example, the following three requirements are mandatory. Note the third 

requirement is one of those with the M* mentioned above.

Table 6. Request Message.

3.5.3.3.2.5 Contents of the Link Status Information M Yes

3.5.3.3.2.5.1 Required Link Status Information Content M Yes

3.5.3.3.2.5.2.4 Link Travel Time M* Yes / No

• The requirements to support Error Report Messages.

− For the example, the following two requirements are mandatory.

Table 7. Error Report Message.

3.4.4.1 Contents of the Error Report M Yes

3.4.4.1.1 Required Error Report Contents M Yes

3. Identify those optional requirements that are needed for the deployment. If the requirement is 

needed for the deployment, then for that deployment the Yes in the Support column should 

be selected. For the example, if the deployment is expected to provide link name along with 

the link travel time, then the following Optional requirement must be selected as indicated 

with the text ‘Yes’, highlighted from the Support column:
21

Table 8. Response Message.

3.5.3.3.2.5.2.2 Link Name O Yes / No / NA

Table 9 below shows the completed project-specific NRTM for link based travel time as tailored 

to identify project-relevant requirements. In this example, the Support column indicates the 

selection of an optional requirement indicated as mandatory for a specific implementation.
22

Table 9. NRTM Prior to Tailoring.

Reqmt 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/No/NA

Dialogs for Link Based Information 3.5.3.3.2.2 Publish Link Status Information Subscription:O Yes/No/NA

Dialogs for Link Based Information 3.5.3.3.2.3 Subscribe to Link Status Information Subscription:O Yes/No/NA

Request Message 3.5.3.3.2.4 Contents of the Link Status Request M Yes

Request Message 3.5.3.1.1 Contents of the Traffic Network Information 

Request

M Yes

Request Message 3.5.3.1.1.1 Required Traffic Network Information 

Request Content

M Yes

Request Message 3.5.3.1.1.2.1 Authentication O Yes/No

Request Message 3.5.3.1.1.2.1.1 Operator Identifier O Yes/No

Request Message 3.5.3.1.1.2.2 Roadway Network Identifier O Yes/No

Request Message 3.5.3.1.1.2.3 Traffic Network Identifier O Yes/No

Response Message 3.5.3.3.2.5 Contents of the Link Status Information M Yes

Response Message 3.5.3.3.2.5.1 Required Link Status Information Content M Yes

Response Message 3.5.3.3.2.5.2.1 Restrictions O Yes/No

Response Message 3.5.3.3.2.5.2.2 Link Name O Yes/No

Response Message 3.5.3.3.2.5.2.3 Link Direction O Yes/No
23

Table 9. NRTM Prior to Tailoring.

Reqmt Type Req ID Requirement Conformance Support

Response Message 3.5.3.3.2.5.2.4 Link Travel Time M* Yes/No

Response Message 3.5.3.3.2.5.2.11 Status Date and Time Change Information O Yes/No

Error Report Message 3.4.4.1 Contents of the Error Report M Yes

Error Report Message 3.4.4.1.1 Required Error Report Contents M Yes

Error Report Message 3.4.4.1.2.1 Restrictions O Yes / No

Note: UN ID: 2.5.2.2

User Need: Travel Time Data for Roads
24

Table 10. NRTM with Tailoring of Project-Relevant Requirements.

Reqmt 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 / No / NA

Dialogs for Link Based Information 3.5.3.3.2.2 Publish Link Status Information Subscription:O Yes / No / NA

Dialogs for Link Based Information 3.5.3.3.2.3 Subscribe to Link Status Information Subscription:O Yes / No / NA

Request Message 3.5.3.3.2.4 Contents of the Link Status Request M Yes

Request Message 3.5.3.1.1 Contents of the Traffic Network Information 

Request

M Yes

Request Message 3.5.3.1.1.1 Required Traffic Network Information 

Request Content

M Yes

Request Message 3.5.3.1.1.2.1 Authentication O Yes / No

Request Message 3.5.3.1.1.2.1.1 Operator Identifier O Yes / No

Request Message 3.5.3.1.1.2.2 Roadway Network Identifier O Yes / No

Request Message 3.5.3.1.1.2.3 Traffic Network Identifier O Yes / No

Response Message 3.5.3.3.2.5 Contents of the Link Status Information M Yes

Response Message 3.5.3.3.2.5.1 Required Link Status Information Content M Yes

Response Message 3.5.3.3.2.5.2.1 Restrictions O Yes / No

Response Message 3.5.3.3.2.5.2.2 Link Name O Yes / No
25

Table 10. NRTM with Tailoring of Project-Relevant Requirements.

Reqmt Type Req ID Requirement Conformance Support

Response Message 3.5.3.3.2.5.2.3 Link Direction O Yes / No

Response Message 3.5.3.3.2.5.2.4 Link Travel Time M* Yes / No

Response Message 3.5.3.3.2.5.2.11 Status Date and Time Change Information O Yes / No

Error Report Message 3.4.4.1 Contents of the Error Report M Yes

Error Report Message 3.4.4.1.1 Required Error Report Contents M Yes

Error Report Message 3.4.4.1.2.1 Restrictions O Yes / No

Note: UN ID: 2.5.2.2

User Need: Travel Time Data for Roads

27

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 and 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.

a

a Common Alerting Protocol, V. 1.1, OASIS Standard CAP-V1.1, OASIS, October 2005, p.1.
28

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).
29

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.
30

• 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.

(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 dataframes and data-elements.

 

(4)

Ibid., p. 4.
31

• 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.
32

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.

1. Identify the section of the RTM that corresponds with the requirements identified from the 

NRTM that are project-relevant.

2. Identify the requirements that are mandatory from the filled-in tailored NRTM.

3. 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.

4. 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.
33

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.

1. 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.

RTSMIPDXFS

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.

2. 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. 
34

Table 13. Rows for Mandatory Requirements.

Reqmt 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 / No / NA

Dialogs for Link 

Based Information

3.5.3.3.2.2 Publish Link Status 

Information

Subscription:O Yes / No / NA

Dialogs for Link 

Based Information

3.5.3.3.2.3 Subscribe to Link Status 

Information

Subscription:O Yes / No / NA

Note: UN ID: 2.5.2.2

User Need: Travel Time Data for Roads

3. 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 dlTrafficNetworkInfo

rmationSubscription

3.1.19.1 dlTrafficNetworkInfo

rmationSubscription

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.
35

4. 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.
36

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 dlTrafficNetworkInfor

mationSubscription

3.1.19.1 dlTrafficNetworkInform

ationSubscription

Request 

Message

3.5.3.3.2.4 Contents of the Link 

Status Request

message trafficNetworkInformati

onRequestMsg

3.2.19.1 trafficNetworkInformati

onRequestMsg

Request 

Message

3.5.3.1.1 Contents of the 

Traffic Network 

Information Request

message trafficNetworkInformati

onRequestMsg

3.2.19.1 trafficNetworkInformati

onRequestMsg

Request 

Message

3.5.3.1.1 Contents of the 

Traffic Network 

Information Request

data-frame TrafficNetworkInforma

tionRequest

3.3.20.1 TrafficNetworkInformat

ionRequest

Request 

Message

3.5.3.1.1.1 Required Traffic 

Network 

Information Request 

Content

data-frame organization-requesting 3.3.16.3 OrganizationInformation
37

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

Request 

Message

3.5.3.1.1.1 Required Traffic 

Network 

Information Request 

Content

data-element network-informationtype3.4.20.2 Transportation-networkinformation-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-resourceidentifier

Request 

Message

3.5.3.1.1.2.2 Roadway Network 

Identifier

data-element network-identifiers 3.4.20.1 Transportation-networkidentifier

Request 

Message

3.5.3.1.1.2.3 Traffic Network 

Identifier

data-element roadway-network-id-list 3.4.20.1 Transportation-networkidentifier

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-networkidentifier

Response

Message

3.5.3.3.2.5.1 Required Link 

Status Information 

Content

data-element link-status 3.4.14.34 Link-status
38

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

Response 

Message

3.5.3.3.2.5.1 Required Link 

Status Information 

Content

data-element network-id 3.4.20.1 Transportation-networkidentifier

Response 

Message

3.5.3.3.2.5.1 Required Link 

Status Information 

Content

data-frame organizationinformation3.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-networkname

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-vehicleestimated

Response 

Message

3.5.3.3.2.5.2.7 Link Speed Limit data-element speed-limit 3.4.14.32 Link-speed-limit
39

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

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 the 

Error 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

dataelementerror-code 3.4.3.1 Error-report-code

Error Report 

Message

3.4.4.1.1 Required Error 

Report Contents

dataelementerror-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
40

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

Error Report 

Message

3.4.4.1.2.1 Restrictions dataelementorganizationinformationforwarding-restrictions3.4.16.5 organizationinformationforwarding-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.
41

5. IMPLEMENTATION ISSUES

At this point in the process, an implementer has identified the data concepts necessary for DXFS 

information interchange. This section provides a discussion of additional standards that should 

be identified in a DXFS-based implementation, plus a technical discussion of issues related to 

the transport of data concepts across a system interface.

Implementation is the process of translating a design into hardware and software components, or 

both.

(5)

The first part of this chapter section will focus on documentation of the software 

engineering environment (software implementation and test) of the system interface. The topic of 

software implementation is outside the scope of this guide, and no attempt is made to show any 

coding examples. Software engineers should refer to the actual standard (e.g., NTCIP 2306 or 

NTCIP 2304) for additional information. The second part of this chapter section will focus on 

technical issues that need to be considered in a system interface design and implementation. This 

part includes a discussion of communications concepts that relate to the deployment of DXFS 

system interfaces. 

5.1 A COMMUNICATIONS FRAMEWORK FOR DXFS

An example communications framework diagram showing the interrelationship of the key 

communications standards that would be used in a deployment is shown below.

 

(5) IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, 

IEEE, September 28, 1990, p. 38.
42

Wireless Fiber Coax Twisted Pair Telco Line

cdma2000 Wi-Fi

Wi-Max

Private

Wireless

Network

Cellular, PCS SONET

ATM FDDI Ethernet SLIP PPP

HTTP

HTTPS

XML SOAP

GZIP

TMDD

Wide Area Wireless Wireline

Information 

Level

Application 

Level

Transport 

Level

Plant 

Level

Subnetwork 

Level

FTP

V Series Modem

TCP

IP

DATEX

ASN.1

OER

NTCIP 2306 NTCIP 2304

NTCIP 2306

Dialogs

NTCIP 2304

Dialogs

Traffic 

Management

TCIP SIRI* OASIS CAP*

Transit 

Management

National Weather 

Service Bulletins

Transit 

Management

* SIRI and OASIS CAP would require 

development of an ASN.1 schema to use the 

NTCIP 2304 standard.

Figure 3. Diagram. A Communications Framework for the RTSMIP DXFS.

(Source: Based on: NTCIP 9001 version v04, The NTCIP Guide, AASHTO / ITE / NEMA, July 2009, p. 12.)
43

The diagram above is based on the NTCIP Framework,

(6)

which provides a common reference 

for the concept of a communications framework, and for definition of the communications levels 

defined below.

Each of the Communications Framework levels is described:

• Information Level Standards. Information-level standards define information content 

exchanges, and include dialog, message, and data element definitions.

• Application Level Standards. Application standards define the rules and procedures for 

exchanging information data.

• Transport Level Standards. Transport standards define the rules and procedures for 

exchanging the application data between point A and point X on a network, including any 

necessary routing, message disassembly or reassembly, and network management functions.

• Subnetwork Level Standards. Subnetwork standards define the rules and procedures for 

exchanging data between two adjacent devices over some communications media. This is 

equivalent to the rules used to exchange data over a cellular link versus the rules used to 

exchange data over a twisted pair copper wire.

• Plant Level Standards. The Plant Level is shown in the framework only as a means of 

providing a point of reference. The Plant Level includes the communications infrastructure 

over which communications standards are to be used and will have a direct impact on the 

selection of an appropriate Subnetwork Level for use over the selected communications 

infrastructure. The ITS standards do not prescribe any one media type over another.

The communications framework presents alternatives for deployment. Other standards might be 

applicable for a given level, but these represent a starting point to ease communications 

architecture and design. The objective is to give project developers a head start in understanding 

which standards to specify and implement in developing a ITS communications solution.

5.2 ACHIEVING INTEROPERABILITY

Interoperability is the ability of two or more systems or components to exchange information and 

to use the information that has been exchanged.

(7)

Interoperability is attained only if multiple networked systems implement the same protocols, 

dialogs, messages, and data content definitions, i.e., they implement the same system interface 

specification. Also, important is that deployers implement the same version of the standards.

The bottom 4 layers of the Communications Framework (Plant, Subnetwork, Transport, and 

Application) will provide two systems only compatibility, but not interoperability. It is adding in 

 

(6) NTCIP 9001 version v04, The NTCIP Guide, AASHTO / ITE / NEMA, July 2009, p. 12. 

(7) Ibid., p. 42.
44

the Information level that allows two systems to exchange information and use the information 

exchanged, the key to interoperability.

At the information level, some standards support backward compatibility, such that a current 

version of the standard and a previous version may interoperate. However, if the standard does 

not provide a statement that backward compatibility is supported, then deployers will need to 

agree on a particular version of the standard to implement.

At the information level, deployers will need to agree on which information level standards to 

implement. For example, for transit management, TCIP and SIRI are not interoperable. Or, 

roadway weather described in TMDD is not interoperable with OASIS CAP weather alerts.

These examples do not interoperate because interoperability relies on both centers implementing 

the same data concepts (dialogs, messages, and specific content of messages). TCIP and SIRI do 

not share a common set of data concepts, as does not TMDD and OASIS CAP. Therefore, 

deployers must agree on which specific information level standards and which data concepts 

shall be implemented. 

The reader should note that there are two paths an implementation may take within the 

application level to connect the information level to the transport level. Within the application 

level, NTCIP 2304 (AP-DATEX) and NTCIP 2306 (AP-C2C XML), do not interoperate.

Therefore, when building a DXFS interface deployers should consider which path to take: only 

one application level standard is typically selected for an implementation. 

The transport level contains the TCP/IP standard. The TCP/IP has been described as the “Swiss 

Army Knife” of communications. It is an essential ingredient of interoperability that “glues”

systems across an inter-network, or network-to-network infrastructure.

In the subnetwork and plant levels, to achieve interoperability, the connections between 

software, hardware, and electronics must exist to create a communications link between two 

systems. A few examples to illustrate systems that lack interoperability at the subnetwork follow:

A 700 MHz radio system and a 800 MHz radio system will not communicate with each other, 

nor will PCS communicate with cellular telephones, nor GSM and CDMA cellular phone. 

Therefore, for a connection between any two units, one subnetwork standard must be chosen for 

each communication link, and that subnetwork standard must also provide a bridge to the plant 

level used.

5.3 COMMUNICATIONS DIALOGS RELATED TECHNOLOGIES

5.3.1 The Application Level: Defining Message Patterns, Message Encoding, and Message 

Transport

The information level standards referenced by the DXFS define dialogs, messages, data frames, 

and data elements. These information level standards also provide standardized XML schemas 

that define the structure and content of messages. And two informational standards, TMDD and 

TCIP, also provide ASN.1 schemas.
45

The application level standards define the mechanism of encoding and transport of messages 

between centers. Two NTCIP standards have been developed for center-to-center 

communications: Application Profile NTCIP 2304 (AP-DATEX), and Application Profile 

NTCIP 2306 (AP-C2CXML). 

A brief introduction to NTCIP 2304 and NTCIP 2306 follows in the sections below. For readers 

interested in a discussion about the differences potential advantages of implementing either 

NTCIP 2304 or NTCIP 2306 are directed to read NTCIP 9001 NTCIP Guide, and/or both NTCIP 

2304 and NTCIP 2306.

5.3.1.1 NTCIP 2304 Overview

The NTCIP 2304 is formally entitled Application Profile for DATEX-ASN (AP-DATEX). 

NTCIP 2304 references the ISO 14827 standard, which defines the rules for message exchanges, 

encoding, and transport for ASN.1-based communications definitions. NTCIP 2304 is based on 

the assumption that two centers are always connected. Therefore, common dialogs for 

connecting, logging in, and disconnecting are defined and required. Once connected, two centers 

share information using a request-response message pattern or subscription-publication pattern.

A number of ITS implementations projects are currently using the AP-DATEX protocols to 

transport XML data files.

5.3.1.2 NTCIP 2306 Overview

The NTCIP 2306 is formally entitled Application Profile for XML Message Encoding and 

Transport in ITS Center-to-Center Communications.

NTCIP 2306 - AP-C2CXML is based on the rules of message encoding and transport of the 

W3C’s (World Wide Web Consortium) Web Services Architecture. NTCIP 2306 provides a 

way to define messages (using XML Schema) and dialogs (using the Web Services 

Definition Language). 

The NTCIP 2306 provides a way to specify Web Services Definition Language (WSDL) for the 

following combinations of message encoding and transport:

• Simple Object Access Protocol (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 request-response and subscription-publication message patterns.

• XML over HTTP. Using XML-encoded messages over the HTTP, centers will be able to 

describe and deploy interfaces that support the request-response (by HTTP POST) and 

request-only message patterns (HTTP GET). HTTP POST is suitable for the exchange of 

messages (request-response), and HTTP GET is suitable for the request of an XML 

document by name.

• XML over FTP. Using the File Transfer Protocol (FTP), centers will be able to describe 

interfaces that support XML document requests by name.
46

5.3.1.3 NCTIP 2306 – XML Direct

In addition, the NTCIP 2306 provides a one-way pattern used to access a file by name. Together, 

the one-way message pattern and FTP or HTTP define the XMLDirect approach, a simple 

technique for file exchange.

5.3.1.4 Message Patterns

Message patterns are the building blocks of dialogs. Three types of basic or simple dialogs can 

handle a wide variety of situations, or a project may define complex dialogs to satisfy their 

special project requirements. The three basic building blocks of dialogs, or message patterns, are 

as follows:

• One-way. A concept intended for bulk data transfer. This messaging pattern implements a 

request of an XML file by name. As FTP and HTTP have a built-in mechanism for 

requesting a file by name, there is no need to develop a specific message for this type of 

request. The one-way response is an XML-encoded file.

• Request-Response. This message pattern supports the sending of a message followed by a 

response. This pattern implements a synchronous pattern of message communications.

• Subscription-Publication. This message pattern supports a subscriber application 

performing an initial request-response to set up future asynchronous responses from an 

information publisher application.

Both NTCIP 2304 and NTCIP 2306 provide the request-response and subscription-publication 

message patterns. The one-way pattern is a development of NTCIP 2306.

5.3.1.5 Message Encoding

Message encoding defines the bit-byte representation of message information content (also 

called encoding). Messages are encoded into the bit-byte representation prior to the start of 

network transfer regardless of how the information is represented in the originating and 

destination systems. The message encoding formats of NTCIP 2306 and NTCIP 2304 are 

as follows:

• NTCIP 2306 specifies two information encoding formats: XML and SOAP, both standards of 

the W3C, and an encoding format for compression, GZip, a standard of the IETF.

• NTCIP 2304 specifies information encoding of ASN.1. These include BER (Basic Encoding 

Rules) and the NTCIP 1102 Octet Encoding Rules (OER) standard. In addition, projects have 

been encoding message content as XML.

5.3.1.6 Message Transport

The term message transport as it applies to the application level of standards should not be 

confused with the term as it applies to the communications framework, i.e., TCP/IP. From the 

application-level perspective, the message transport used in the message transfer is typically a 

TCP/IP application. A TCP/IP application is a well-known socket-based application as defined 
47

by the IANA Well Known Port Numbers (HTTP/FTP). The message transport mechanisms 

(TCP/IP applications) used in NTCIP 2304 and NTCIP 2306 are described as follows:

• NTCIP 2306 describes two message transport mechanisms: HTTP and FTP, both standards 

of the IETF.

• NTCIP 2304 specifies a transport mechanism based on the TCP Socket API. Clients and 

servers exchange messages in DATEX over TCP Socket 355.

5.3.1.7 Developing NTCIP 2304 Specifications

The following tasks are necessary to develop an NTCIP 2304-based dialog specification:

1. Determine the dialogs that fulfill the project requirements. One approach is to document the 

dialogs using UML sequence diagrams.

2. Select an encoding format (BER, OER, XML, or SOAP).

3. Use the transport format TCP/IP.

4. Select the ASN.1 data concept definitions from the information level standard that fulfill the 

project system interface requirements.

5.4 INTEGRATING LEGACY SYSTEMS

This section addresses special considerations and approaches for developing a DXFS system 

interface to a legacy system, including:

a) Interfaces for systems that do not support TCP/IP.

b) How to handle the situation of unavailable (or missing) data. Two cases will be cited:

1) The system does not have the capability to collect the data.

2) The system can collect the data, but the data is unavailable to be sent in a message. 

5.4.1 Interfacing Systems that Do Not Support TCIP/IP

TCP/IP is a data communications standard that is available on a wide variety of systems.

Systems that need to provide an interface to external systems could benefit by providing TCP/IP 

connectivity. If your system does not support TCP/IP the deployers should consider purchasing 

equipment to modernize the legacy systems interface to other centers.

Several options are available to deployers implementing TCP/IP over serial lines and/or dial-up 

connections.

• The first point is that NTCIP 2306 provides a mechanism for transfer of information using 

the file transfer protocol (FTP). FTP can be used over a dial-up connection.

• And, second, the Point-to-Point Protocol (PPP) and Serial Line Internet Protocol (SLIP) are 

protocols for implementing TCP/IP over a serial connection (including dial-up).
48

5.4.2 Handling Unavailable or Missing Data

While the situation of handling unavailable or missing data is handled in TMDD, it is not 

expressly defined how to handle these situation in TCIP, SIRI, and OASIS CAP. Therefore, the 

DXFS addresses the issue of what happens when there is no data to support a required data 

element This section deals with how to encode mandatory data elements that do not have data 

available – i.e., those data elements that are mandatory in the information level standard, as well 

as those optional elements that have been deemed mandatory based on the specification. Lastly,

the DXFS defines a null data element as a mandatory data element that contains a null value (i.e., 

no data).

5.4.2.1 Null Data Element Encoding in ASN.1

ASN.1 defines a mechanism, the NULL type, for encoding of null data values. Therefore, there 

is no need to tailor the ASN.1 definition.

5.4.2.2 Null Data Element Encoding in XML

For XML, the approach suggested by the TMDD Standard is to return an error message in cases 

where a system has missing information in a message.
49

6. TESTING

6.1 INTRODUCTION

A system engineering process is recommended for implementation and testing of a DXFS 

interface to ensure that: 1) the system satisfies all user needs; 2) requirements are verified 

resulting in a system free of defects; and 3) the system interface is built on time and on budget.

Significant cost savings can be realized from building a system without having to continually rework the system to satisfy new user needs and requirements. The up-front effort in defining user 

needs and requirements can also lead to significant savings in time in re-working of the system 

during latter stages of system development. 

The DXFS has been developed using a systems engineering process, described below:

• The first step in the process, described in Section 2 of this report, was to develop a concept of 

operations that provides the reader with a detailed description of the scope of the RTSMIP, 

the user needs which the RTSMIP will address, and the operational scenarios that consider 

the center to center interfaces that will be a part of RTSMIP.

• The second step, described in Section 3, demonstrated the process of elicitation of 

requirements that satisfy the user needs in the concept of operations.

• The third step, described in Section 4, demonstrated the selection of design elements

from existing system interface standards that fulfill the requirements.

• Section 5 of this report dealt with implementation issues to identify additional 

material (outside of the scope of the DXFS) necessary to develop a complete system 

interface specification.

• Lastly, this section describes testing.

The focus of this section is on development of test documentation to test system interface 

specification compliance. During the test phase, the system interface implementation is tested 

against the requirements specified for the project. A complete treatment of the topic of software 

testing is beyond the scope of this guide, and hence, no attempt is made to show a complete 

test example.

Field experience from system interface testing (such as testing a TMDD implementation) yields 

2 major issues that are not currently being addressed during system interface testing:

1. Lack of boundary testing. Boundary testing is intended to test that the content of messages is 

correct and complete. This includes testing that data values are within stated value ranges, 

that enumeration values are properly selected from the standardized list of choices, and data 

values conform with field length.

2. Proprietary design. Proprietary designs are being implemented that supplants the 

national standard thus leading to non-interoperability of systems and non-conformance 

with standards.
50

6.1.1 DXFS Conformance

One of the goals of Section 1201 was to realize national interoperability of systems providing 

real time information. To be conformant with the DXFS, a system implementation must be 

conformant with the underlying standards (TMDD, TCIP, SIRI, and OASIS CAP) upon which 

the DXFS is based. A system that does not conform with one or more of the standards is not 

conformant with the DXFS.

6.1.2 Compliance with a DXFS Project Specification

Tailoring the DXFS for a specific project was described in Sections 2 through 4 of this report.

The end-result is a specification of requirements and design tailored to satisfy specific project 

needs for a RTSMIP implementation. The NRTM was designed to allow a project to develop a 

needs-based specification.

To test a DXFS system interface, the interface must be isolated from the hardware and central 

system software. Testing focuses on the compliance with the requirements and the system 

interface specification and not the operations(s) the implementation is attempting to support via 

the interface software implementation. Testing will verify compliance with the specification 

requirements and ensure that the dialogs and data content of message exchanges are 

implemented correctly.

Testing compliance with a DXFS project specification can be summarized in three steps:

1. Write test documentation. (Test documentation is described with examples in this section of 

the report.)

2. Conduct tests in accordance with the test documentation and document the test results. 

3. When all pass/fail items are passed, the implementation is compliant with a projectspecific DXFS. 

6.1.3 Test Phases

A system can be thought of as being composed of many sub units. The system testing described 

in this section follows the path of system development, and is described in 4 phases as follows:

• Unit Test. Conducted to verify that a particular sub unit of the system is complete and fulfills 

all the requirements allocated to the sub unit.

• Integration Test. Conducted to verify that the sub units of the system, when integrated, will 

work together and will fulfill all system level requirements.

• System Acceptance Test. Conducted after system installation and commissioning, and 

verifies the system is ready for operation.

• Periodic Maintenance Test. This test phase is designed to allow the system to be 

periodically tested to ensure all system functions are operating properly.
51

6.2 TEST DOCUMENTATION

Test documentation is a key element of a testing program. Test documentation includes test 

plans, test designs, test cases, test procedures, and test reports. Test documentation may be 

developed by the vendor, the agency, a test laboratory, a consultant, or perhaps it is based on test 

documentation used developed by another agency as part of its compliance their qualified 

products program. Testing is conducted by a combination of vendor, agency, and possibly an 

independent laboratory to verify that an ITS system complies with the agency’s specification.

Developing agency test documentation can take a significant amount of time and require 

coordination of many parties. It is recommended that test plan development begin after system 

interface requirements have been completed and approved. Test design and development and or 

test case developments can begin after agency specification requirements have been approved 

and signed-off. Test Plan execution occurs throughout implementation. Test reports document 

test plan execution. Test documentation, as outlined, ensures that testing is thoroughly 

documented. In addition, test designs, test cases, and test procedures should be regularly 

reviewed based on past experience and results.

6.2.1 Standards that Support Test Documentation

As in previous sections, this section relies on existing standards to define the content and 

processes for test documentation. The IEEE Std 829-1998-1998, IEEE Standard for Software and 

System Test Documentation, hereafter referred to as IEEE Std 829-1998, provides a 

comprehensive overview of the processes and documentation for testing. 

IEEE Std 829-1998-1998 specifies the form and content of an individual test document, but it 

does not specify a required set. The documents outlined in IEEE Std 829-1998 cover test 

planning, test specification, and test reporting. IEEE Std 829-1998 provides the 

following overview.

6.2.1.1 Test Plan

The test plan prescribes the scope, approach, resources, and schedule of the testing activities. It 

identifies the items to be tested, the features to be tested, the testing tasks to be performed, the 

personnel responsible for each task, and the risks associated with the plan.

(8)

6.2.1.2 Test Specifications

Test specifications are covered by three document types:

(9)

 

(8) IEEE Std 829-1998-1998, IEEE Standard for Software and System Test Documentation, 

IEEE, 16 September 1998, p. iii.

(9) Ibid.
52

a) A test design specification refines the test approach and identifies the features to be covered 

by the design and its associated tests. It also identifies requirements, test cases, and test 

procedures necessary to accomplish the testing and specifies the feature pass-fail criteria.

b) A test case specification documents the actual values used for input along with the 

anticipated outputs. A test case also identifies constraints on the test procedures resulting 

from use of that specific test case. Test cases are separated from test designs to allow for use 

in more than one design and to allow for reuse in other situations.

c) A test procedure specification identifies all steps required to operate the system and exercise 

the specified test cases in order to implement the associated test design. 

6.2.1.3 Test Reports

Test reporting is covered by four document types:

(10)

a) A test item transmittal report identifies the test items being transmitted for testing in the 

event that separate development and test groups are involved or in the event that a formal 

beginning of test execution is desired.

b) A test log is used by the test team to record what occurred during test execution.

c) A test incident report describes any event that occurs during the test execution which requires 

further investigation.

d) A test summary report summarizes the testing activities associated with the execution of test 

plan specifications. The test summary report can summarize key results captured in the test 

logs and test incident reports.

6.2.2 Example Test Documentation Framework for a DXFS Implementation

The IEEE standards that cover system engineering must be tailored to address the specific needs 

for a particular system engineering process, project plan, project life cycle development process, 

and specific part of the system being tested. Figure 4 provides a diagram showing an example of 

tailoring IEEE Std 829-1998 to support system interface testing.

 

(10) Ibid.
53

Test Plan

Test Plan Execution

(Process)

Master Test Plan (Organized by test phase)

Unit 

Test

Integration

Test

Periodic

Maintenance Test

System 

Acceptance Test

Test Case 

Specification

Test Design

Unit Test

Test Design

Integ. Test

Test Design

Syst. Acceptance

Test Case

001

Test Case

003

Test Case

004

Test Case

N

Test Procedure

001

Test Procedure

002

Test Case

002

Test Reports Test Logs Test Incident Reports

Test Plan Execution Summary Report

Test Design

Specifications

Test Procedure

Specification

Test Design

Periodic Mtce.

Test Execution

Figure 4. Diagram. IEEE 829-1998-based Test Documentation Framework for the RTSMIP DXFS.

(Source: IEEE.)
54

At the top of Figure 4. are the test plans for a DXFS system interface. The diagram shows a 

master test plan that includes IEEE Std 829-1998 test plan information for each test phase (unit 

test, integration, system acceptance, and maintenance). For example, a separate section of the 

master test plan will be developed for unit testing.

A test design specification will identify the user needs being validated, plus the set of 

requirements that satisfy those user need(s), and the list of associated test cases that will verify 

implementation of the requirements in the system interface. 

Test cases may be reused across test designs as long as the test case input and output 

specifications are the same. For example, a test case may be created to test that an error report 

message is properly transmitted across the system interface.

A test case will identify the test case input specification(s) that identify the valid values to be 

contained in a message that will result in a positive or negative test. For example, a positive test 

case will be designed to generate a message where all the contained data concepts will pass the 

valid value rule/ criteria (e.g., whether the data concept contains a value from an enumerated list; 

or whether the data concept contain a value that is within the value range that is specified in the 

valid value rule; or whether a string is a specified length). A separate test case, with a different test 

input specification may test that the system properly reports an error message (negative test case).

The test case developer may also want to identify a test output specification that describes the valid 

value rules for each data concept in a message (positive test case). In this case, each data concept will 

be individually verified as to whether the criteria for valid values is fulfilled, and whether the entire 

message (a collection of data concepts) satisfies all valid value criteria for all data concepts in the 

message. (See Table 20 and Figure 6 for a positive test case output specification.)

A test case will also identify which test procedure(s) are necessary to verify that the requirements 

associated with the test case are verified. A test procedure may be used across multiple test cases.

While the test case describes the inputs and outputs of the test to be executed, the test procedure 

identifies the steps to be taken to verify the requirements identified in a test case. The test 

procedure also contains entries that should be noted at test time: tester(s), date and time of test, 

and notes/comments. 

After the test plan and test specifications have been developed, the tester executes the test plan, 

keeping a test log and recording anomalies in a test incident report. The test logs and test incident 

reports are then used to generate a test plan summary report.

One key purpose of the testing and the results documented in the test summary report is: 1) to 

verify that a contractor has fulfilled all the requirements in the system interface specification, and 

2) to validate that all user needs are satisfied.
55

6.3 TEST PLAN

A test plan is a document describing the scope, approach, resources, and schedule of intended 

testing activities.(11)

Either a test plan should be developed that covers just the system interface, or if a test plan exists 

for the project, a test item that represents the system interface should be created. The system 

interface test plan identifies test items (in this case, the system interface), the features to be tested 

(in this case, the requirements to be tested), the testing tasks, who will perform do each task, and 

any risks requiring contingency planning. According to IEEE Std 829-1998 provides a template 

for the contents, the following elements should be included in a test plan and it includes:

a) Test Plan Identifier. This is a unique name and number for each test plan.

b) Introduction. Should include references to all relevant documents, for example, the system 

interface needs, requirements, specification, and design.

c) Test Items. This is a description of the software item to be tested. In our case, this will be the 

system interface.

d) Features to be Tested. The features to be tested are the requirements. This section could 

reference the RTM, which in turn would provide a list of requirements to be tested.

e) Features Not to be Tested. This section might not apply, but it would include a list of 

features, for example, requirements that will not be tested and why not.

f) Approach. This section describes the overall approach to testing: who does it, what the main 

activities, techniques and tools used for each major group of features are. It will explain how 

to decide that all the features have been tested. IEEE 829-1998 also says that this section 

(and not the Schedule section) is the place to identify constraints, including deadlines, and 

the availability of people and test items.(12)

It is worth considering a phased approach to testing to reduce the cost and risk of testing. 

Phases might include: 

• Unit Test Phase.

• Integration Test Phase.

• System Acceptance Phase.

• Periodic Maintenance Test Phase.

For example, start with a smaller number of test units (e.g., dialogs) initially, and then add 

more units. This phased testing approach helps in isolating problems (what piece of the 

system is at fault). The phased approach also allows for multiple iterations for correcting 

errors encountered, thus reducing risk and helping find defects (one of the reasons why 

testing is conducted). One way to handle the phased approach is through the use of one test 

 

(11)

Ibid., p. 2

(12) Cem Kaner, Jack Falk, Hung Nguyen, Testing Computer Software, John Wiley & Sons, 2nd 

Edition, April 12, 1999, p. 247-248.
56

design specification for each phase. The approach section will also include an overview of 

logistics, test equipment (projectors, protocol analyzers, vendor equipment, test software, 

tables, and chairs), and equipment to be tested. The approach of doing incremental testing 

will help to isolate defects in the system and in turn allow proper verification and validation.

g) Item Pass-Fail Criteria. Criteria for determining whether the test item, in this case, the 

system interface software, has passed or failed a test.

h) Suspension Criteria and Resumption Requirements. Identifies anything that could cause 

the test to be stopped. It describes the rules for stopping and restarting a test. One benefit of 

having these rules is the result of shortened testing cycles, because a test does not have to 

start all over again if it is stopped in the middle. This clause should include how and when 

regression testing (retesting of previously tested elements) will be performed.

i) Test Deliverables. This is a list of all the test documentation that will be written for the test.

j) Testing Tasks. Identifies the planned activities required for testing. This section of the test 

plan may include the following items:

1) Task Number. A unique identifier for a testing task.

2) Task Name. A unique name or title for the test task.

3) Predecessor Tasks. Identifies test task interdependencies.

4) Responsibility. Identifies who needs to be present to conduct the test task.

k) Special Skills. Identifies any special items and/or resources required to conduct the test task.

l) Environmental Needs. Describes the configuration, necessary hardware, software, testing tools, 

supplies, lab facilities, centers, and reference documentation. Include a diagram showing the set up 

for the testing: locations and positioning of equipment, people, tables, chairs, and projection systems 

(so that everyone participating in the testing can see what is happening). Also include a list of 

equipment, equipment description, and equipment purpose to accompany the diagram.

m) Responsibilities. Names the groups and/or individual persons responsible for managing, designing, 

preparing, executing, witnessing, checking, controlling the environment in the laboratory, obtaining 

the equipment and supplies, setting up equipment and software, writing reports, and approving (who 

will sign the approval sheet).

(13)

n) Staffing and Training Needs. For each phase of testing (unit test, integration test, system acceptance 

test, and periodic maintenance test) this section of the test plan should describe who needs to be trained 

and for what purpose. It should begin with a description of staff, identifying who shall be available 

versus who shall participate full-time. It could also identify a meeting with all parties involved to let 

them know what the testing process will be.

o) Schedule. This is a list of milestones and a timeline of when all resources and people will be needed.

It could include a reference to the approach section for test tasks and add start and stop dates and 

times.

p) Risks and Contingencies. Identifies significant risks to the testing plus contingency plans. This 

section includes risks to schedule, potential impact on cost, technical risks, and what to do if the 

situation occurs.

q) Approvals. Lists the personnel who shall approve the plan and spaces for their signatures.

 

(13) Ibid., p. 248.
57

Developing a test plan can take a significant amount of time and require coordination of many 

parties. It is recommended that test plan development begin after the system interface 

requirements have been completed and approved.

6.4 TEST DESIGN SPECIFICATIONS

A test design specification is a document that specifies the details of the test approach for a 

feature or combination of features and identifies associated tests. According to IEEE Std 829-

1998, a test design specification contains the following features:

a) Test Design Specification Identifier. A unique identifier for the test design specification.

b) Features to be Tested. List of requirements to be tested.

c) Approach Refinements. Expands upon the approach described in the test plan. It is 

recommended that a purpose in the approach be added. 

d) Test Identification. A list and brief description of the test cases associated with this 

test design.

e) Feature Pass-Fail Criteria. Explains how the tester will decide whether a feature under test 

has passed the test.

The purpose of the test design is to identify which test cases verify which requirements in the 

system interface. Though the diagram in Figure 4 shows a separate test design document for each 

test phase, a typical implementation will bundle the test design information with the test plan 

information, organized by test phase.

An example portion of a test design specification is shown in Table 16.
58

Table 16. Example Portion of a Test Design Specification.

Requirement 

ID Requirement Title Test Case ID

Test Case 

Title

3.5.3.3.2.1 Send Link Status Information Upon Request TC001

[List additional 

test cases here.]

Link Status 

RequestResponse 

Dialog 

Verification

3.5.3.3.2.4 Contents of the Link Status Request

3.5.3.1.1 Contents of the Traffic Network Information 

Request

3.5.3.1.1.1 Required Traffic Network Information 

Request Content

3.5.3.3.2.5 Contents of the Link Status Information

3.5.3.3.2.5.1 Required Link Status Information Content

3.5.3.3.2.5.2.4 Link Travel Time

Note: ID: TD001: Link Status Request Dialog and Request and Response Message Data 

Content Verification

User Need: 2.5.2.2 Travel Time Data for Roads

Feature Pass-Fail Criteria: This test design is passed when: 1) the dialogs 

represented in TC001 completes round trip communication, and 2) the data content of 

dialog requests and responses are verified correct against the referenced input and

output specifications.

6.5 TEST CASE SPECIFICATIONS

A test case specification is a document that specifies the inputs, predicted results, and set of 

execution conditions on a test. Test case specification development can begin after the system 

interface requirements are approved.

A test case specification includes the following elements:

a) Test Case Specification Identifier. A unique identifier for the test case specification. A title 

is also strongly recommended so the tester can quickly grasp the nature of the test case.

b) Test Items. Identifies the requirements being verified by this test case. The mapping of 

requirements to test cases will be documented in the requirements to test case 

traceability matrix.

c) Input Specification. Description of input data values, range of values, names of files, or 

names of memory-resident areas containing test values.

d) Output Specification. Description of expected output values and tolerances for each data 

concept, error messages, and expected response times.

e) Environmental Needs. List of special requirements, equipment, skills, hardware, software, 

facilities, and staff. This clause also describes any environmental needs that are different (or 

require additional resources) from what is described in the test plan or test design specification.

f) Special Procedural Requirements. List of special procedures for startup, setup, and analysis.
59

g) Intercase Dependencies. A list of test cases to perform before this one, and contingency if the 

dependent case fails. This clause allows an ordering of test case execution to be developed.

Several test cases might be needed to determine that a requirement is fully satisfied, but at least 

one test case for each requirement shall be defined. The traceability matrix, RTCTM, is used in 

matching test cases to requirements. Some methodologies recommend creating at least two test 

cases for each requirement. One of them should perform positive testing of a requirement and the 

other should perform negative testing (e.g., testing for invalid values or conditions). Written test 

cases should include a description of the functions to be tested and the preparation required to 

ensure that the test can be conducted.

The test case should consider for positive test cases, boundary conditions, and error handling.

For example, when testing boundary conditions, if the specifications state that valid values for 

vehicle speed is 0 to 65 miles per hour, use test values of 0, 65, and 66 miles per hours to verify 

that each test value is properly transmitted (or not) across the system interface.

What characterizes a formal, written test case is that there is a known input and an expected 

output, which is worked out before the test is executed. The known input should test a 

precondition, and the expected output should test a post-condition.

6.5.1 Example Requirements to Test Case Traceability Matrix (RTCTM)

The purpose of the RTCTM to verify that the test cases capture testing of all of the system 

interface requirements at least once.

The RTCTM (test case matrix) contains a Requirement Identifier, Requirement Title, Test Case 

ID, and Test Title. An example RTCTM is shown in Table 17.

Table 17. Example Requirements to Test Case Traceability Matrix.

Requirement 

ID Requirement Title Test Case ID

Test Case 

Title

3.5.3.3.2.1 Send Link Status Information Upon Request TC001 Link Status 

RequestResponse 

Dialog 

Verification 

3.5.3.3.2.4 Contents of the Link Status Request

3.5.3.1.1 Contents of the Traffic Network Information 

Request

3.5.3.1.1.1 Required Traffic Network Information 

Request Content

3.5.3.3.2.5 Contents of the Link Status Information

3.5.3.3.2.5.1 Required Link Status Information Content

3.5.3.3.2.5.2.4 Link Travel Time
60

6.5.2 Example Test Case Specification

The test case descriptions presented in this section test the requirements for a specific dialog, 

dialog messages, and message content in a single test case. This combination ensures that all the 

requirements that together comprise a dialog, dialog messages, and message content are tested at 

least once. The process for testing of system interface compliance then is accomplished through 

a careful systematic testing of all of the dialogs that comprise a system interface. An example 

test case specification is shown in Table 18.

Table 18. Example Test Case Specification.

Purpose: To verify system interface implements (positive test case) requirements for: 

1) Link Status Request-Response Dialog message exchange

2) Contents of the Link Status Request Message

3) Contents of the Link Status Information Message 

Description: The test case verifies that the dialog, request message content, and response 

message content are correct by sending a request message (verified to be 

correct) across the system interface, and verification that the response 

message is correct. Input and output specifications are provided to verify the 

request and response message are correct per the requirements for the request 

and response message. 

Test Items: 3.5.3.3.2.1 – Send Link Status Information Upon Request

3.5.3.3.2.4 – Contents of the Link Status Request

3.5.3.1.1 – Contents of the Traffic Network Information Request

3.5.3.1.1.1 – Required Traffic Network Information Request Content

3.5.3.3.2.5 – Contents of the Link Status Information

3.5.3.3.2.5.1 – Required Link Status Information Content

3.5.3.3.2.5.2.4 – Link Travel Time

Input 

Specification:

TCIS001 - LinkStatusRequest (Positive Test Case)

Output 

Specification:

TCOS001 - LinkStatusInformation (Positive Test Case)

Environmental 

Needs:

No additional needs outside of those specified in the test plan.

Test 

Procedure(s):

TP001: Link Status Request-Response Dialog Verification (Positive Test 

Case)
61

Table 18. Example Test Case Specification.

Pass/Fail Pass/Fail is determined upon verification of the following:

1) A LinkStatusInformation message is returned upon sending of a 

LinkStatusRequest Message. (Pass/Fail)

2) The structure and content of the LinkStatusRequest is verified to be 

correct. A test input specification is provided. See TCIS001 -

LinkStatusRequest (Positive Test Case). (Pass/Fail)

3) The structure and content of the LinkStatusInformation is verified to be 

correct. A test output specification is provided. See TCOS001 -

LinkStatusInformation (Positive Test Case). (Pass/Fail)

Tester/Reviewer B.C.

Special 

Procedure 

Requirements:

None

Intercase 

Dependencies:

None

Note: ID: TC001

Title: Link Status Request-Response Dialog Verification (Positive Test Case)

6.5.2.1 Example Input and Output Specifications

The test case above references Input and Output Specifications. These specifications provide a 

basis for verification that the content and structure of messages used or generated during testing 

are correct (per the requirements).

Test case data can be developed by creating a table showing the data variables defined in the 

project-specific XML schema. The constraints on the data values contained in messages are 

composed of the valid value rules for the data elements contained in a message. Data elements 

are typically constrained by:

• Enumerated lists.

• Value range.

• Size.

Test case data has been prepared for positive test case data – i.e., test cases expected to pass. A 

test case data input specification table is shown in Table 19.
62

Table 19. Example Test Case Input Specification.

Data Concept Name (Variable)

Data Concept 

Type Value Domain Pass-Fail

trafficNetworkInformationRequestMsg Message Pass/Fail

- organization-requesting Data Frame Pass/Fail

- organization-id Data Element IA5String (SIZE(1..32)) Pass/Fail

- organization-name Data Element IA5String (SIZE(1..128)) Pass/Fail

- network-information-type Data Element 1 = “node inventory”

2 = “node status”

3 = “link inventory”

4 = “link status”

5 = “route inventory”

6 = “route status”

7 = “network inventory”

Pass/Fail

Note: ID: TCIS001

Title: LinkStatusRequest (Positive Test Case)

Figure 5 shows a trafficNetworkInformationRequestMsg request message. The XML is 

an example of test case data that would pass all criteria (all pass-fails) identified in the 

input specification.

Figure 5. Message. Example trafficNetworkInformationRequestMsg 

Request Message Test Case Data File.

A test case data output specification table is shown in Table 20. 

<trafficNetworkInformationRequestMsg>

<organization-requesting>

<organization-id>2</organization-id>

<organization-name>NYSDOT R8</organization-name>

</organization-requesting>

<network-information-type>4</network-information-type>

</trafficNetworkInformationRequestMsg>
63

Table 20. Example Test Case Output Specification.

Data Concept Name (Variable)

Data Concept 

Type Value Domain Pass-Fail

linkStatusMsg Message Pass/Fail

- link-status-item Data Frame Pass/Fail

- organization-information Data Frame Pass/Fail

- organization-id Data Element IA5String (SIZE(1..32)) Pass/Fail

- organization-name Data Element IA5String (SIZE(1..128)) Pass/Fail

- link-status-list Data Frame Pass/Fail

- link Data Frame Pass/Fail

- network-id Data Element IA5String (SIZE(1..32)) Pass/Fail

- link-id Data Element IA5String (SIZE(1..32)) Pass/Fail

- link-name Data Element IA5String (SIZE(1..128)) Pass/Fail

- link-status Data Element 1 = “no determination”

2 = “open”

3 = “restricted”

4 = “closed”

Pass/Fail

- travel-time Data Element INTEGER (0..65535), 

units=seconds

Pass/Fail

Note: ID: TCOS001

Title: LinkStatusInformation (Positive Test Case)

Figure 6 shows a linkStatusInformationMsg response message. The XML is an example of test 

case data that would pass all criteria (all pass-fails) identified in the output specification.
64

Figure 6. Message. Example linkStatusInformationMsg 

Response Message Test Case Data File

6.6 TEST PROCEDURE SPECIFICATIONS

A test procedure specification is a document that specifies a sequence of actions for the execution of 

a test. The test procedures test the implementation of the requirement. Test procedure specification 

development can begin after the test cases and design are completed and approved.

A test procedure specification includes the following elements:

• Test Procedure Specification Identifier. This is a unique identifier for a test procedure.

• Purpose. Describes what the procedure is for.

• Special Requirements. List of prerequisite procedures, special test skills, and 

environmental needs.

• Procedure Steps. Includes a list of the steps. IEEE Std 829-1998 describes the following key 

words, as applicable, that should be used in describing procedure steps:

− Log. Special methods or formats for logging results and observations.

− Setup. Preparation for execution of the procedure.

− Start. How to begin execution of the procedure.

− Proceed. Actions necessary during program execution. 

− Measure. How test measurements (e.g., response times) are made.

− Shut down. How to suspend testing in the face of an unscheduled event.

<linkStatusMsg>

<link-status-item>

<organization-information>

<organization-id>1</organization-id>

<organization-name>NYSDOT R11</organization-name>

</organization-information>

<link-status-list>

<link>

<network-id>000001</network-id>

<link-id>A12345</link-id>

<link-name>I-87>/link-name>

<link-status>2</link-status>

<travel-time>60</travel-time>

</link>

</link-status-list>

</link-status-item>

</linkStatusMsg>
65

− Restart. Where and how to restart any test step after a shut down of the test.

− Stop. How to bring test execution to an orderly halt.

− Wrap up. How to restore the test environment to its original state.

− Contingencies. What to do in the case of an anomalous event.

(14)

6.6.1 Example Test Procedure Specification

Table 21 shows an example of the test procedure for the Link Status Request-Response dialog 

and includes the purpose, preconditions, and procedure steps.

Table 21. Example Test Procedure Specification.

Purpose: This test procedure verifies that the Link Status Request-Response dialog of 

an Owner Center system interface is implemented properly. It tests that when 

a correctly formatted trafficNetworkInformationRequestMsg request message 

is sent to an owner center, that the owner center responds with an

linkStatusMsg response message.

Start 

Date/Time:

10:15 am, June 12, 2013

End Date/Time: 10:30 am, June 12, 2013

Special 

Requirements:

None

Preconditions: 1. Verify that the XML Request Message is valid against Project XML 

Schema.

2. Verify that the WSDL for the Dialog to be tested is correct.

Procedure 

Steps:

1. Start HTTP Client

2. Load XML Request Information Message File

3. Send XML Request Message to Owner Center

4. Receive XML Response Message from Owner Center

5. Log XML Incident Description Response Message to a File

6. Verify that the Saved Incident Description Response File is SOAP XML 

(encoding is SOAP)

6. Verify that the Saved Incident Description Response File validates against 

the Project XML Schema. Using an XML schema tool, verify the XML 

message content against the value domains described in the test case input 

and output specifications.

Test 

Identification

TC001 – Link Status Request-Response Dialog Verification (Positive Test Case)

TC002 – [continue with additional test case specifications here]

 

(14) Cem Kaner, Jack Falk, Hung Nguyen, Testing Computer Software, John Wiley & Sons, 2nd

Edition, April 12, 1999, p. 250.
66

Table 21. Example Test Procedure Specification.

Feature 

Pass-Fail

Passed

Tester(s) Initials B.C.

Notes: 1.

Note: ID: TP001

Title: Link Status Request-Response Dialog Verification (Positive Test Case)

6.7 TEST REPORTS

This section provides a short summary of the test reports outlined in IEEE Std. 829-1998:

a) Test Log. The purpose of the test log is to document the events and outcomes (pass/fails) 

encountered during the test. The test log is a chronological record of the execution of the test 

including persons present and roles, procedure results, and any anomalies encountered.

b) Test Incident Report. The purpose of the test incident report is to record anomalies 

encountered during testing (sequence of events that led to the anomaly) to provide 

information to analyst that may need to identify the causes of system errors. This report 

documents any event that occurs during testing that required further investigation. It records 

expected versus actual results, procedure and procedure step, and attempts to repeat the test.

It should also record any potential impacts on further testing activities.

c) Test Summary Report. The purpose of the test summary report is to provide documentation on 

status for a test phase. The ability to move onto a new phase in the project may be predicated on 

satisfactory completion of a test phase. This report would be provided after the completion of a 

test phase, for example, all the tests defined in a test design specification.

The reader is asked to review Section 9 Test log, Section 10 Test incident report, and Section 11 

Test summary report of IEEE Std 829-1998 for additional information.

6.8 SUMMARY

This section provided guidance on system interface compliance testing. Key points included:

a) Take a phased approach to testing. Also, use an incremental approach to test base 

functionality first and more advanced features next. This will facilitate isolation and 

correction of defects.

b) Testing performs verification and validation and helps find defects in software.

c) Testing isolates system interface defects (for example, incorrect sequences of message 

exchanges or incorrectly formed messages) versus defects in the system elements 

(applications, databases, etc.) that use or generate the information that is exchanged across 

the system interface.

d) The cost of testing needs to be considered vis-à-vis the potential reduced cost during the 

operations and maintenance phase. The cost of testing needs to be considered vis-à-vis the 

potential reduced cost during the operations and maintenance phase. The cost to fix a bug during 

testing is much less than the cost to fix the same bug of a system that has already been deployed.
67

APPENDIX A. LIST OF ACRONYMS

AASHTO American Association of State Highway Transportation Officials

AP-C2C XML Application Profile for XML Message Encoding and Transport in ITS Center 

to Center Communications

AP-DATEX Application Profile for DATEX-ASN

APTA American Public Transportation Association

ASN.1 Abstract Syntax Notation One

ATIS Advanced Traveler Information System

BER Basic Encoding Rules

CAD Computer Aided Dispatch

CAP Common Alerting Protocol

CCTV Closed Circuit TeleVision

CEN European Committee for Standardization 

(French: Comite Europeen de Normalisation)

CFR Code of Federal Regulations

ConOps Concept of Operations

DMS Dynamic Message Signs

DOT Department of Transportation

DXFS Data Exchange Format Specification

EAS Emergency Alert System

EU European Union

FTP File Transfer Protocol

HAR Highway Advisory Radio

HTTP HyperText Transfer Protocol

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

ISO International Organization for Standardization

ITE Institute of Transportation Engineers

ITS Intelligent Transportation Systems

LRMS Location Referencing Message Specification

NOAA National Oceanic and Atmospheric Administration

NRTM Needs to Requirements Traceability Matrix

NTCIP National Transportation Communications for ITS Protocol

OASIS Organization for the Advancement of Structured Information Standards

OER Octet Encoding Rules

PRL Protocol Requirements List

PSAP Public Safety Answering Point

REST Representational State Transfer

RSUs RoadSide Units

RTCTM Requirements to Test Case Traceability Matrix

RTM Requirements Traceability Matrix

RTSMIP Real-Time System Management Information Program

SAE Society of Automotive Engineers

SAFETEA-LU Safe, Accountable, Flexible, Efficient Transportation Equity Act: 

A Legacy for Users
68

SAME Specific Area Message Encoding

SIRI Service Interface for Real time Information

SOAP Simple Object Access Protocol

TCIP Transit Communications Interface Profile

TCIP/IP Transmission Control Protocol/Internet Protocol

TMDD Traffic Management Data Dictionary

WSDL Web Services Description Language

XML eXtensible Markup Language
69

APPENDIX B. ACKNOWLEDGMENTS

The project team wishes to acknowledge Tom Stout, FHWA (retired), who was instrumental in 

guiding the development of the RTSMIP DXFS, as well as the numerous public and private 

sector transportation professionals from traffic, roadway weather, and transit agencies and 

authorities across the country, who gave of their time to validate and verify the RTSMIP DXFS 

needs, requirements, and design.
U.S. Department of Transportation

Federal Highway Administration

Office of Operations

1200 New Jersey Avenue, SE

Washington, DC 20590

www.ops.fhwa.dot.gov

August 2013

FHWA-HOP-13-046