Office of Operations
21st Century Operations Using 21st Century Technologies
Table of Contents

Real-Time System Management Information Program Data Exchange Format Specification — Implementation Guidance

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.

Figure 2 is a context diagram describing the systems involved in the collection and dissemination of travel and traffic conditions. Flows are indicated between agencies and providers, with flow distinctions of subject Data Exchange Format Specification (DXFS) flows and other flows.

Figure 2. Diagram. RTSMIP Context Diagram.
(Source: Consensus Systems Technologies.)

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

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

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:

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