Real-Time System Management Information Program Data Exchange Format Specification

2. Concept of Operations

This section describes the Concept of Operations (ConOps) for the DXFS. A ConOps describes the ways a proposed system will be used from the users’ perspective. The ConOps is one of the first key outputs of the systems engineering process and forms the basis for the definition of requirements. The ConOps stage of the systems engineering process is used to ensure that the system developers document a thorough understanding of the users’ needs.

The ConOps provides the reader with a detailed description of the scope of the DXFS, the user needs which the DXFS will address, and the operational scenarios that consider the center to center interfaces that will be a part of the DXFS.

Readers will find this section useful for understanding the type of information that will be a part of the DXFS. It serves as the starting point in the procurement and specification process. Procurers and specification writers, such as the transportation agencies, can become familiar with each capability addressed by the DXFS and determine whether that capability is appropriate for their implementation. If it is, then their implementation will require the capability and all of the mandatory requirements related to that capability.

2.1 Introduction

A concept of operations describes a proposed system from the users’ perspective. Typically, a concept of operations is used on a project to ensure that the system developers understand the users’ needs. Within the RTSMIP effort, the concept of operations documents the scope of the DXFS, and presents a user’s view of the program. The concept of operations also serves as the starting point for agencies to select those features that may be appropriate for a specific procurement that will use the DXFS.

The concept of operations starts with a discussion of the background surrounding the development of the DXFS, the objectives of the DXFS, and the current situation and issues that have led to the need to deploy systems within the scope of the standard and to the development of the standard itself. This discussion permits both potential users and system developers to understand the situation.

The concept of operations then documents key aspects of the proposed system, including:

Reference Physical Architecture (Section 2.3) – The reference physical architecture defines the overall context of the proposed system and defines which specific interfaces are addressed.
Architectural Needs (Section 2.4) – The architectural needs discuss issues and needs relative to the system architecture. Because the RTSMIP does not define any particular system architecture, this section is not used.
Features (Section 2.5) – The features identify and describe the various functions that users may want the system to perform. These features are derived from the high level user needs identified in the problem statement but are refined and organized into a more manageable structure that forms the basis of the traceability table contained in Section 3 (Functional Requirements).

Architectural needs and features are collectively called “user needs”. In Section 3, these user needs are traced to the various functional requirements of the RTSMIP environment. Basic systems engineering requires that:

Each user need traces to one or more functional requirement(s).
Each functional requirement derives from at least one user need.

This traceability is shown in the Needs to Requirements Traceability Matrix (NRTM) in Section 3.3.3.

The DXFS is intended to support a broad range of prospective implementations. Within the NRTM, each user need and requirement is identified as mandatory, optional, or conditional, and users of this standard may complete the NRTM to clearly define unique aspects of their implementation. Within the DXFS, items marked mandatory are those that relate to the most basic functionality of providing real time traffic, transit, or traveler information. For specific implementations, the user identifies those optional or conditional needs appropriate for a specific implementation.

The concept of operations concludes by:

Describing the extent to which policies or constraints relative to the operational environment have a direct impact on the implementation of this standard (Section 2.7).
Providing a description of how the interfaces to be described in the DXFS relate to the National ITS Architecture (Section 2.8).
Presenting operational scenarios that demonstrate how a proposed system that is part of an RTSMIP and uses the DXFS should operate and interact with its users under a various sets of specific circumstances (Section 2.9).

2.2 Background, Objectives, and Current System or Situation

This section provides a discussion of the background that lead to the creation of the DXFS, the objectives of the DXFS, and an overview of the current situation regarding real time traveler information.

2.2.1 Background

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, technology-dependent application, or business model for collecting, processing and disseminating information.

Additional information about Section 1201 is available on the FHWA Operations web site.

Section 1201 also 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 this DXFS to facilitate the development of interoperable real-time traffic and travel information between public agencies, with other public agencies, and with private entities.

2.2.2 Objectives of the DXFS

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 has been 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.

2.2.3 Description of the Current Situation

The current situation regarding collection, processing, and dissemination of real time information is summarized below.

2.2.3.1 Data Collection

Collection of real time data is occurring at almost all transportation agencies. The primary difference between agencies is the scope of the collection. Almost every agency collects freeway speed data. In most cases this is done using agency field equipment, but a subset of agencies purchase the speed data from private companies. Most state agencies have speed collection capabilities on the freeways near the major urban areas of the state, while many have collection capabilities throughout interurban corridors. What is less common is the collection of real time speed data for major arterials, although this is becoming more common, and is included in many regional ITS architectures as a planned capability.

Regarding the collection of incident information, most transportation agencies have a network of CCTV cameras monitored at some center facility that they use to identify and classify incidents which are then entered into a software system at the center where they then track the status of the incident as it is cleared. Another major (and sometimes primary) source of incident information is via data feed from the CAD systems of public safety centers such as PSAPs.

Construction related road or lane closure information is primarily entered manually by transportation agency personnel into software systems. One common issue that was identified during the stakeholder interviews was that this data entry is often not done in a timely fashion, particularly as construction plans change.

Road weather data is collected from a network of environmental sensor stations. Located primarily in states that experience ice and snow, these sensors provide general environmental information as well as pavement (and subpavement) data. In some cases the data is collected by private organizations and provided to the transportation agencies.

Real time data collection for transit agencies consists primarily of vehicle location information. The deployment of AVL systems is widespread for large and medium transit agencies. In most cases the transit agency receives the AVL data directly from transit vehicles through wireless communications links, but in some cases a third party collects the data and provides real-time location information to the agency.

2.2.3.2 Data Processing

Transportation agencies perform a wide array of processing on the real time data collected. From the standpoint of the RTSMIP, one of the primary outputs of the data processing is to create travel time information, which is disseminated to travelers. Each state or region has its own approach to creating travel times as the outputs are highly dependent on the freeway network, the locations of the DMS, and the availability of real time data. As discussed below under the Information Dissemination section, additional processing of the speed data is used to create various summary information to create maps or other web/smartphone based outputs. Incident, road or lane closure information, or hazardous weather information is also put into useful forms as described below.

Transit agencies typically process their bus location data to create next bus arrival information for dissemination to travelers or other agencies.

2.2.3.3 Information Dissemination

The dissemination of real time traffic and travel information is done for two primary purposes:

Providing information directly to travelers so that they can make better travel decisions.
Providing information to other agencies and third party providers so that they can make better decisions operating and maintaining the transportation network.

Providing information to travelers is currently occurring to some extent in every state and metropolitan region. Information is currently provided directly to travelers on the network via DMS or HAR. The former is now very widely deployed, although the amount of real time data provided varies widely from state to state. Many states, including Illinois, Washington, California, and Virginia display travel times for various freeway segments. In addition other information, such as average speed data (which is currently displayed by Georgia DOT in the Atlanta area), is put onto the DMS. Incident and road/lane closure information is also displayed in almost all locations possessing DMS or HAR. Weather related information, primarily where hazardous conditions can exist, is the primary output to travelers resulting from the collection of road weather data.

Another aspect of real time information to travelers is web/smartphone based information. In the past decade this has gone from being primarily static or dynamic web pages (originally viewed on personal computers, but increasingly viewed on smart phones or other mobile devices) to include various social media outlets such as Twitter. The full web pages often contain travel time data, average speed data, or a color coded zoomable map of the region showing the traffic congestion. In addition, incidents and road or lane closures are most commonly displayed. The social media outlets, with their short messages tend to focus on incidents, road closures, or hazardous weather conditions.

In the case of transit, bus locations along with next bus arrival times are the most common types of information provided. At the roadside the next bus information is provided via displays at transit stops. Because travelers need this information during their trips, providing information via mobile web or social networking has become commonplace with large (and some medium) size transit agencies.

Dissemination of real time information to other agencies and third party providers is occurring in only a few states and regions. The usual approach to this type of information sharing is to provide a data feed of link based speed or travel time data that can be subscribed to by traveler information providers or third party providers and further processed or used as an input to applications. A somewhat more common occurrence is to provide incident, road or lane closure, or hazardous weather conditions information as a data feed to peer transportation or public safety agencies. In the case of transit agencies, the provision of a data feed of real time bus locations is happening in many (but by no means most) of the large and medium size agencies. These data streams are used by third party providers as inputs to smartphone applications that travelers access via mobile web.

2.2.4 Stakeholders

This section describes the Stakeholders who will create, process, and use the real time information that makes up the RTSMIP. The complete set of stakeholders includes:

Transportation Agencies. This type of stakeholder represents the staff at Transportation Agencies which include traffic operations agencies and maintenance operations at any level of government (e.g., state or city). These agencies acquire real time data, process it, and provide it to other stakeholders, including travelers, public safety agencies, travel information providers, third party providers and peer transportation agencies. Transportation agencies may have traveler information responsibilities, but they also have clear traffic or maintenance operations responsibilities.
Transit Agencies. This type of stakeholder has a primary role of providing public transportation services to a region, including fixed route and/or demand response services. They have an additional role of providing transit information to travelers, travel information providers and third party providers.
Public safety. This type of stakeholder represents the center staff of providers of emergency services, including public safety providers. Examples include the dispatch function for law enforcement, fire department, and emergency services, as well as the staff for public safety answering points and public safety/operations centers.
Public Traveler Information Providers. This type of stakeholder represents the staff at agencies whose primary function is to provide traveler information. In general these providers do not collect the data traffic or transit data directly, but obtain data feeds from transportation and transit agencies. An example of this type of stakeholder is MTC in the Bay Area which operates the TravInfo system.
Private Third Party Providers. This type of stakeholder represents private companies or individuals that use the information collected and processed by the transportation and transit agencies to develop customized traveler information products. Examples are the companies that create smart phone applications driven by data feeds from a transportation and/or transit agency.
Private Data Collection Organizations. This type of stakeholder represents private companies that collect their own traffic or transit data (or aggregate it from other sources such as probe data from private fleet operators) and provide this data for a fee to the transportation or transit agencies (as well as other customers).
Other Public Agencies. This type of stakeholder represents public agencies that may be a source or destination of real time data. Examples of this type of stakeholder are the National Weather Service, which may provide weather information to transportation agencies or may receive the same from the agency. Additional examples of this type of stakeholder are the National Park Service or military bases.
Travelers. This type of stakeholder is the traveling public who uses traveler information in its many forms and from the many providers of the information.

2.3 Reference Physical Architecture

As defined in Section 1201 and in Title 23 CFR 511, the RTSMIP should include the capability to monitor travel and traffic conditions and provide that information to travelers and other users of the information. As described in the rule, section 511.309 defines the minimum information categories for traffic and travel conditions to be made available by real-time information programs:

Construction activities that impact travel conditions, particularly lane and roadway closures.
Roadway or lane-blocking traffic incident information.
Roadway weather observations.
Travel times or speeds for limited access roadways in metropolitan areas.

Further, the rule goes on to list requirements on the timeliness and accuracy of the information. Title 23 CFR 511 requires construction activities, roadway or lane-blocking incidents, and roadway weather observations be delivered with 20 minutes of the observed event; highway-segment travel times are not required at the statewide level. For designated metropolitan statistical areas with populations greater than one million, 23 CFR 511 requires a timeliness of 10 minutes for delivery of construction activities and highway-segment travel times, and 20 minutes for roadway weather observation updates. The requirement for travel time information in metropolitan areas only applies to roads of the interstate system and limited-access roads designated as routes of significance. Criteria for selecting routes of significance were defined in the draft rule (23 CFR Part 11, Federal Register Volume 74, No. 9, January 14, 2009) as follows: “States shall select routes of significance based on various factors relating to roadway safety (e.g., crash rate, routes affected by environmental events), public safety (e.g., routes used for evacuations), economic productivity, severity of congestion, frequency of congestion, and utility of the highway to serve as a diversion route for congestion locations.” Selection criteria for routes of significance include frequent congestion, use as a diversion route, and susceptibility for other mobility and safety-limiting impacts. Minimum service quality levels required by Title 23 CFR 511, which define performance constraints for the system, are summarized in Table 3.

Table 3. Minimum Service Quality Levels.
Category of Information	Timelines – Interstate Highways (Statewide)	Timelines – Limited Access Roadways In Metropolitan Areas^a	Availability	Accuracy
Construction activities^b	20 minutes	10 minutes	90%	85%
Roadway or lane-blocking incidents^c	20 minutes	10 minutes	90%	85%
Roadway weather observations^d	20 minutes	20 minutes	90%	85%
Travel time/speed information^e	N/A	10 minutes	90%	85%

^a Designated Metropolitan Statistical Areas (greater than one million population). Metropolitan areas means the geographic areas designated as Metropolitan Statistical Areas by the Office of Management and Budget in the Executive Office of the President with a population exceeding 1,000,000 inhabitants (Sec. 511.303).
^bThe timeliness for the availability of information about full construction activities that close or reopen roadways or lanes will be x minutes or less from the time of the closure or reopening. Short-term or intermittent lane closures of limited duration that are less than the required reporting times are not included as a minimum requirement under this section (Sec. 511.309).
^cThe timeliness for the availability of information related to roadway or lane-blocking traffic incidents will be x minutes or less from the time that the incident is verified (Sec. 511.309).
^dThe timeliness for the availability of information about hazardous driving conditions and roadway or lane closures or blockages because of adverse weather conditions will be 20 minutes or less from the time the hazardous conditions, blockage, or closure is observed (Sec. 511.309).
^e The timeliness for the availability of travel time information along limited access roadway segments within Metropolitan Areas will be 10 minutes or less from the time that the travel time calculation is completed (Sec. 511.309).

While the rule directly addresses only the four areas shown above, it does indirectly consider the contributions of public safety agencies and transit agencies to the provision of travel conditions information. Section 511.311 c) says “The establishment, or the enhancement, of a real-time information program should include participation from the following agencies: Highway agencies; public safety agencies (e.g., police, fire, emergency/medical); transit operators; and other operating agencies necessary to sustain mobility through the region and/or the metropolitan area.” In addition, section 511.311 d), which is titled Update of Regional ITS Architecture says that “All States and regions that have created a Regional ITS Architecture in accordance with Section 940 in Title 23 CFR shall evaluate their Regional ITS Architectures to determine whether the Regional ITS Architectures explicitly address real-time highway and transit information needs and the methods needed to meet such needs. Traffic and travel conditions monitoring needs for all Interstate system highways shall be considered. If necessary, the Regional ITS Architectures shall be updated to address coverage, monitoring systems, data fusion and archiving, and accessibility to highway and transit information for other States and for value added information product providers.”

Based on these descriptions of the RTSMIP from the rule, a context diagram of the systems that would be involved in the collection and dissemination of travel and traffic conditions is shown in Figure 1. The solid lines in the figure represent those interfaces that are the subject of the DXFS. The dashed lines represent additional interfaces that will be discussed in this ConOps as part of the overall description of the RTSMIP.

Figure 1. Diagram. RTSMIP Context Diagram.

(Source: Consensus Systems Technologies.)

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

The following subsections provide an overview of the aspects of the system addressed by each box in the Context Diagram.

2.3.1 Transportation Agency Systems

Transportation agency systems represent the field devices and center based systems that transportation agencies use to collect traffic, incident, construction, and weather data, process it, and use it to manage the transportation network and provide traveler information to travelers either directly at the roadway (e.g., with DMS/HAR) or through web based outputs.

2.3.2 Transit Agency Systems

Transit agency systems represent the center based systems that transit agencies use to monitor the locations of their transit vehicles. They also represent the systems that use that information to determine the arrival or departure times of the vehicles. The vehicle location information can come from transit agency operated systems, or from a private data collection organization.

2.3.3 Peer Transportation Agency Systems

Peer transportation agency systems represent the center based systems that state, regional, or municipal transportation agencies use to manage traffic in their jurisdictions.

2.3.4 Public Safety Agency Systems

Public safety agency systems represent the center based systems that public safety agencies use to dispatch emergency vehicles, enter incident information, and share information with other agencies.

2.3.5 Private Data Collection Organization Systems

Private data collection organization systems represent the field equipment and center based systems used to collect either traffic or transit data. This data is provided to transportation or transit agencies for a fee. The data may be collected from probe based information or from other types of sensors.

2.3.6 Travelers

Travelers are one of the end users of the real time traveler information. They receive this information through a variety of devices including computers, smart phones, or even in-vehicle devices. In some cases they receive the information without the use of any of their devices, receiving information directly from systems such as DMS.

2.3.7 Public Traveler Information Provider Systems

Public traveler information provider systems represent those publically owned or operated center based systems that develop traveler information outputs. Public traveler information providers may collect their own data, but usually obtain most or all of the data from transportation or transit agencies.

2.3.8 Private Third Party Providers Systems

Private third party providers have computer based systems that use data streams obtained from transportation agencies, transit agencies, or from public traveler information providers to create value added products that are used by travelers.

2.3.9 Other Public Agencies Systems

Other public agency systems represent those center based systems of agencies who do not have transportation as their primary function, but who provide or receive real time information. The receipt of weather forecasts from the National Weather Service is an example of the interface with these types of systems.

2.4 Architectural Needs

Due to the nature of the RTSMIP (defining a program for real time data exchange), no specific architectural needs are defined in the DXFS.

2.5 Features

2.5.1 Introduction to User Needs

The user needs provide an expression of the end users’ operational needs that can be met by information that is used by agencies to support an RTSMIP.

The following criteria were used as the basis for documenting well-written needs:

Uniquely Identifiable. Each need must be uniquely identified (i.e., each need shall be assigned a unique number and title).
Major Desired Capability (MDC). Each need must express a major desired capability in the system, regardless of whether the capability exists in the current system or situation or is a gap.
Solution Free. Each need must be solution free, thus giving designers flexibility and latitude to produce the best feasible solution.
Capture Rationale. Each need must capture the rationale or intent as to why the capability is needed in the system.

The RTSMIP User Needs defined in this DXFS are organized around the four areas described in Rule 23 CFR 511:

Travel Time.
Incident Information.
Construction Information.
Weather Information.

Three additional areas of user needs are included in the DXFS as shown below:

Transit information, which is not directly covered by the Rule, but is considered to be a part of the broader RTSMIP.
Roadway Network, which describes the need that agencies or organizations receiving the information have in order to properly understand the information described in the Rule 23 CFR 511 areas.
Connection – coming from the TMDD standard, this need is essential for providing the basic connection management functions essential for receiving information relating to any of the other needs.

2.5.2 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. This capability is intended to support Integrated Corridor Management and other Advanced Traffic Management strategies, which could include variable speed limits, lane control devices, and ramp metering on limited access roads and adaptive traffic signal control on arterials.

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). This capability is intended to provide a key real time output to travelers regarding travel on roads. This capability to provide traveler information can also be expressed as average speed over some section of roadway as defined by the transportation agency.

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. This capability is intended to give traveler information providers access to speed data that will allow them to provide the data to travelers as part of regional maps and also allow traveler information providers to calculate travel times.

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. This capability is intended to allow public traveler information providers access to travel time data that they can then provide to travelers and other transportation agencies.

2.5.2.5 Travel Time Data for Parties who Create 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). This capability is intended to support sharing of travel time data with private sector entities that may develop applications or other products that use the information.

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. The capability is also intended to provide similar information to travel information providers for use in their traveler information systems and to other parties who develop applications or other products that use the information.

2.5.3 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. This capability is intended to allow transportation agencies to use the information to develop real time response to incidents and alternate route strategies. The agencies can also use the information to support the dispatch of other response services (e.g., Service Patrols).

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). This capability is intended to allow transportation agencies to inform travelers about incidents.

2.5.3.3 Incident Information from Transportation Agencies for Public Safety Centers

Public Safety Centers need to receive incident information from transportation agencies. This capability is intended to allow public safety agencies to improve their ability to respond to and manage incidents.

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. This capability is intended to support regional incident response since incidents on the roadway managed by one agency can impact the traffic on roadways managed by other agencies. In addition transit agencies may recognize and report on incidents for roadways on which the transit agency buses operate.

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. This capability is intended to allow transit agencies to improve the operations of their transit system. Incidents have a negative impact on transit operations, delaying passengers and potentially requiring rerouting of the transit vehicles.

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. This capability is intended to allow public traveler information providers to identify the incident location and backups relating to the incidents, which is a key output of their traveler information.

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). This capability is intended to support sharing of incident information (including road or lane closures) with private sector entities that may develop applications or other products that use the information.

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). This capability is intended to provide important non real time information to travelers. Planned events include road/lane closures due to planned construction or special events.

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. This capability is intended to provide important non real time information to other agencies. In addition, public traveler information providers need to distribute planned event information to private third party providers.

2.5.4 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). This capability is intended to allow transportation agencies to provide information directly to travelers about road and lane closures, which are the key aspects of construction activities affecting travel.

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. This capability is intended to provide transportation agencies with up to date information about road and lane closures due to construction activities.

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. This capability is intended to allow sharing of construction information relating to road or lane closures with agencies or other parties that can use it to support management of their road networks or to support applications or other products that are intended for travelers use.

2.5.5 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). This capability is intended to provide transportation agencies with the raw or aggregated sensor data that are the key source of information the transportation agencies use to determine that there are adverse conditions on the roadways that will affect travelers.

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. This capability is intended to provide transportation agencies with the raw or aggregated sensor data that are the key source of information the transportation agencies use to determine the weather related maintenance activities needed to keep the road network open and safe.

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. This is a future capability that will be supported by enhanced capabilities to forecast road weather.

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).This capability is intended to support sharing road weather information affecting travel with agencies or other parties external to the transportation agency. The external agencies would include other transportation agencies in the same region, or who manage adjacent transportation networks.

2.5.6 Transit Information User Needs

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. This capability is intended to provide a key transit system output, real time bus location to the travelers using the system and to external agencies or other parties who can use the information.

2.5.6.1 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. This capability allows travelers to receive information from various sources regarding the passenger loading of the transit vehicles they intend to use.

2.5.6.2 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. This capability is intended to provide both travelers and external agencies, travel information providers or other parties with information key to the use of the transit system. In order to support this real time user need, the agencies and organizations receiving the information need static information such as routes and bus stop locations.

2.5.7 Roadway Network Information Needs

2.5.7.1 Roadway Network and Device Information

In order 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. While the focus of RTSMIP is on real time information exchange, in order for the exchange to be meaningful to the receiving center, that center must have a complete and up to date definition of the network, including the definition of points, links, routes, and an inventory of ESS devices.

2.5.8 Connection Management User Needs

The following sections describe the needs for connection management – verifying that a connection is alive, which is a fundamental need relevant to providing real time data

Centers need to verify that a connection with another center is alive or active. If the from one center to another.

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.6 Security

Due to the nature of the RTSMIP, security needs are not defined by the DXFS.

2.7 Operational Policies and Constraints

It is expected that the operational policies and constraints in an RTSMIP will be similar to the existing operational policies and constraints discussed in Section 2.2 above, with the exception that:

The data exchange communication format specifications will be documented for the data that agencies choose to exchange, eliminating the need to reach “regional agreement” on those data exchange format specifications.
There will be minimum requirements for traffic and travel conditions and requirements on the timeliness and accuracy of the information made available by the RTSMIP.

The collection, distribution and use of real time transportation system information must operate within the framework of existing policies and constraints that exist at the public agencies and other entities that participate in the RTSMIP.

Variability of policies: The public agencies as a group generally operate independently, and the actual policies and constraints affecting specific agencies will vary based on the specific state, regional and municipal policy environments. Differences exist on specific agency policies for creating:

Operational dependencies on data from other entities (especially on private sector entities).
Supplying data to other entities (either public or private sector entities).
Fiscal constraints.
Licensing constraints on the use of private data.

Operational dependencies on data from other entities: While some public agencies have procured data from private sector sources (e.g., the I-95 Corridor Coalition and their well know relationship with INRIX), other agencies have resisted a dependency on private sources of data because of concerns that the supplier may failing financially, causing the supply of data to suddenly halt.

Managing risk associated with supplying data to other entities: Some agencies have historically resisted sharing detailed operational data with the public (or with private sector information service providers that would use the data in products used by the public) because of liability concerns regarding any defects or perceived defects in the data they supply. Other agencies have decided (sometimes reversing a past policy) to make operational data freely and openly available to application developers (e.g., see the TRANSCOM Data Feed, the MTA developers resources) or the MTC developer resources.

Fiscal constraints to implement an RTSMIP: Public agencies may have investments in systems that don’t follow all the requirements of an RTSMIP (when it’s ready for deployment) or will have no such systems at all. Funds to deploy (or replace or upgrade existing systems for) an RTSMIP at the agency level may have to compete with other transportation projects. The idea that sharing agency collected information (at some agency expense) will sufficiently further the transportation safety and efficiency goals of the agency may not be universally accepted.

Licensing constraints on the use of privately supplied data: Public agencies may purchase transportation information collected by private entities. These arrangements generally included negotiated licensing restrictions on the use and distribution of the purchased information. These licensing constraints are unique to each individual arrangement. For example, information purchased by an agency may in some cases be used in a public agency website providing traveler information, but may not be included in a free data feed that might be used by other information service providers to develop other traveler information services for revenue (by sale or advertising).

2.8 Relationship to the National ITS Architecture

The Physical Architecture of the National ITS Architecture is defined by Entities, Interfaces, and Service Packages. The following section provides a mapping of the proposed system against these concepts of the National ITS Architecture (Version 7.0). This mapping will be useful in placing the interfaces defined by the DXFS into the context of regional ITS architectures.

2.8.1 Entities

Using the context diagram of Figure 1, based upon the system description the following is the mapping to the National ITS Architecture shown in Table 4.

Table 4. Mapping to National ITS Architecture Entities.
RTSMIP Element	National ITS Architecture Entity
Transportation Agency Systems	Traffic Management Subsystem (TMS)
Transit Agency Systems	Transit Management System (TMS)
Peer Transportation Agency Systems	Other Traffic Management
Public Safety Agency Systems	Emergency Management Subsystem (EM)
Private Data Collection Organization Systems	Information Service Provider Subsystem (ISPS) Surface Transportation Weather Service Other Transit Management
Travelers	Personal Information Access Subsystem (PIAS) Vehicle Subsystem (VS)
Public Traveler information Provider Systems	Information Service Provider Subsystem (ISPS)
Private Third Party Provider Systems	Information Service Provider Subsystem (ISPS)
Other Public Agency Systems	Weather Service Emergency Management Subsystem (EM)

2.8.2 Interfaces

The following discussion of interfaces will use the context diagram of Figure 1 as the basis for the development of the how the key DXFS interfaces would be mapped to the National ITS Architecture interfaces (defined as source entity, destination entity and architecture flow).

2.8.2.1 Private Data Collection Organization Systems to Transportation Agency Systems

This interface corresponds to two interfaces as shown in Table 5, mapping to the following architecture flows:

Table 5. Private Data Collection Organization to Transportation Agency Interface.
Source Entity	Destination Entity	Architecture Flow
ISPS	TMS	Road network traffic probe data
Surface Transportation Weather Service	TMS	Environmental conditions data
Surface Transportation Weather Service	TMS	Transportation weather information

Road network traffic probe data – Aggregated route usage, travel times, and other aggregated data collected from probe vehicles that can be used to estimate current traffic conditions.

Environmental conditions data – Current road conditions (e.g., surface temperature, subsurface temperature, moisture, icing, treatment status) and surface weather conditions (e.g., air temperature, wind speed, precipitation, visibility) as measured and reported by fixed and/or mobile environmental sensors and aggregated by the data collector. Attributes relating to the data collection (and aggregation) are also included.

Transportation weather information – Current and forecast road conditions and weather information (e.g., surface condition, flooding, wind advisories, visibility, etc.) associated with the transportation network. This information is of a resolution, timeliness, and accuracy to be useful in transportation decision making.

Private Data Collection Organization Systems to Transit Agency Systems

This interface, which describes the provision of AVL data from a private data collection system to the transit agency, is not directly addressed in the National ITS Architecture, but its closest mapping is the Other Transit Management to TRMS interface with the following architecture flow:

Transit service coordination – Schedule coordination information shared between local/regional transit organizations. (Note, while the definition of the architecture flow does not appear to cover AVL data, closer inspection of the underlying data flows of the Logical Architecture show that information to be present on this architecture flow).

Transportation Agency Systems to Peer Transportation Agency Systems

This interface corresponds to two interfaces as shown in Table 6, mapping to the following architecture flows:

Table 6. Transportation Agency to Peer Transportation Agency.
Source Entity	Destination Entity	Architecture Flow
TMS	Other Traffic Management	Road network conditions
TMS	Other Traffic Management	Incident information
Other Traffic Management	TMS	Road network conditions
Other Traffic Management	TMS	Incident information
MCMS	TMS	Maint and constr work plans
MCMS	TMS	Road weather information

Road network conditions – Current and forecasted traffic information, road and weather conditions, and other road network status. Either raw data, processed data, or some combination of both may be provided by this architecture flow. Information on diversions and alternate routes, closures, and special traffic restrictions (lane/shoulder use, weight restrictions, width restrictions, HOV requirements) in effect is included along with a definition of the links, nodes, and routes that make up the road network.

Incident information – Notification of existence of incident and expected severity, location, time and nature of incident. As additional information is gathered and the incident evolves, updated incident information is provided. Incidents include any event that impacts transportation system operation ranging from routine incidents (e.g., disabled vehicle at the side of the road) through large-scale natural or human-caused disasters that involve loss of life, injuries, extensive property damage, and multi-jurisdictional response. This also includes special events, closures, and other planned events that may impact the transportation system.

Maint and constr work plans – Future construction and maintenance work schedules and activities including anticipated closures with anticipated impact to the roadway, alternate routes, anticipated delays, closure times, and durations.

Road weather information – Road conditions and weather information that are made available by road maintenance operations to other transportation system operators.

2.8.2.4 Transportation Agency Systems to Public Safety Agency Systems

This interface corresponds to the TMS to EM interface and maps to the following architecture flow (which is bi directional):

2.8.2.5 Transportation Agency Systems to Public Traveler information Provider Systems

This interface corresponds to two interfaces as shown in Table 7, mapping to the following architecture flows:

Table 7. Transportation Agency to Public Traveler Information Provider.
Source Entity	Destination Entity	Architecture Flow
TMS	ISPS	Road network conditions
TMS	ISPS	Incident information
MCMS	ISPS	Maint and constr work plans
MCMS	ISPS	Road weather information

2.8.2.6 Transportation Agency Systems to Private Third Party Provider Systems

This interface corresponds to two interfaces from the National ITS Architecture as shown in Table 8, mapping to the following architecture flows:

Table 8. Transportation Agency to Private Third Party Provider.
Source Entity	Destination Entity	Architecture Flow
TMS	ISPS	Road network conditions
TMS	ISPS	Incident information
MCMS	ISPS	Maint and constr work plans
MCMS	ISPS	Road weather information

2.8.2.7 Transportation Agency Systems to Transit Agency Systems

This interface corresponds to the TMS to TRMS interface and maps to the following architecture flow: incident information.

2.8.2.8 Transit Agency Systems to Public Traveler Information Provider Systems

This interface corresponds to the TRMS to ISP interface and maps to the following architecture flow:

Transit schedule adherence information – Dynamic transit schedule adherence and transit vehicle location information.

2.8.2.9 Transit Agency Systems to Private Third Party Provider Systems

This interface corresponds to the TRMS to ISP interface and maps to the following architecture flow: transit schedule adherence information.

2.8.2.10 Public Traveler Information Provider Systems to Private Third Party Provider Systems

This interface corresponds to the ISP to Other ISP interface and maps to the architecture flows shown in Table 9:

Table 9. Public Traveler Information Provider to Private Third Party Provider.
Source Entity	Destination Entity	Architecture Flow
ISPS	Other ISPS	Road network conditions
ISPS	Other ISPS	Incident information
ISPS	Other ISPS	Transit service information

Transit service information – Transit service information including routes, schedules, and fare information as well as dynamic transit schedule adherence and transit vehicle location information.

2.8.2.11 Transportation Agency Systems to Travelers

This interface corresponds to the two interfaces shown in Table 10 and maps to the following architecture flows:

Table 10. Transportation Agency to Travelers.
Source Entity	Destination Entity	Architecture Flow
ISPS	PIAS	Broadcast traveler information
ISPS	PIAS	Interactive traveler information
RS	VS	Broadcast traveler information

Broadcast traveler information – General traveler information that contains traffic and road conditions, link travel times, incidents, advisories, restrictions, transit service information, weather information, parking information, and other related traveler information.

Interactive traveler information – Traveler information provided in response to a traveler request. The provided information includes traffic and road conditions, advisories, incidents, payment information, transit services, parking information, weather information, and other travel-related data updates and confirmations.

2.8.2.12 Public Traveler Information Provider Systems to Travelers

This interface corresponds to the ISP to PIAS interface and maps to the architecture flows shown in Table 11:

Table 11. Public Traveler Information Provider to Travelers.
Source Entity	Destination Entity	Architecture Flow
ISPS	PIAS	Broadcast traveler information
ISPS	PIAS	Interactive traveler information

The interfaces from Private Third Party Provider Systems to Travelers is identical to the Public Traveler Information Provider Systems to Travelers (from a National ITS Architecture mapping standpoint).

2.8.2.13 Transportation Agency Systems to Other Public Agency Systems:

The interface from Transportation Agency Systems to Other Public Agency Systems is addressed by the TMS (and MCMS) to Weather Service and to EM interfaces (from a National ITS Architecture Standpoint).

Table 12. Transportation Agency to Other Public Agency.
Source Entity	Destination Entity	Architecture Flow
Weather Service	TMS	Road network conditions
TMS	EM	Incident information
EM	TMS	Incident information
MCMS	Weather Service	Road weather information
MCMS	Weather Service	Environmental conditions data

2.8.2.14 Other Public Agency to Transportation Agency Systems

The interface from Other Public Agency Systems to Transportation Agency Systems is addressed by the Weather Service or EM to TMS or MCMS interfaces (from a National ITS Architecture Standpoint).

Table 13. Other Public Agency to Transportation Agency.
Source Entity	Destination Entity	Architecture Flow
EM	TMS	Incident information
Weather Service	TMS	Qualified environmental conditions data
Weather Service	TMS	Weather information

Qualified environmental conditions data – Current road conditions (e.g., surface temperature, subsurface temperature, moisture, icing, treatment status) and surface weather conditions (e.g., air temperature, wind speed, precipitation, visibility) that has had quality checks performed on it and has been formatted and consolidated by the Clarus system. Attributes relating to the data collection (and aggregation) are also included.

Weather information – Accumulated forecasted and current weather data (e.g., temperature, pressure, wind speed, wind direction, humidity, precipitation, visibility, light conditions, etc.).

2.9 Operational Scenarios

2.9.1 Introduction to Operational Scenarios

Operational scenarios provide the overview of the system processes. They comprise the steps taken as actors accomplish tasks and pass information to another actor. These operational scenarios represent only a subset of the total possible. They also include the rationales and user needs described earlier. 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 this concept of operations. Rather this concept of operations focuses on the center to center interfaces that are used for the collection and distribution of data.

The format that describes the operational scenario is defined as follows:

Operational Scenario Name. Title and identification of the Operational Scenario.
Description. A short paragraph that describes the operational scenario and its general flow of events.
Actors Involved. The actors who participate in the operational scenario.
Initiator (actor). The actor who initiates the scenario is explicitly identified.
Prerequisites. Information that is needed to implement the operational scenario.
Flow of Events. The typical flow of events that occurs as part of the operational scenario.
Alternative Scenarios. These are the exception and special cases that characterize alternative information or information flows to meet the Operational Scenario.
User Needs. The user needs that are addressed by the Operational Scenario.

2.9.1.1 Actor Definitions

Actors are people or subsystems that interact within the system. In the RTSMIP environment, they are agencies or organizations that are involved in the collection and use of real time information. Actors also represent the external users who may interact with the systems operated by the primary actors, for example, travelers.

Table 14 lists the actors, their primary role, and the related stakeholders who apply to the actor category.

Table 14. Actor Definitions and Associated Stakeholders.
Actor	Description/Role	Stakeholder Examples
Transportation Agencies	Transportation agencies are responsible for managing the road network, either highway or arterials. They collect traffic, incident, and weather data, either with their own field equipment, or by purchasing the data from private data collection organizations). They are also responsible for providing traveler information through roadside devices or through web based means.	State DOT, Municipal DOT or DPW, such as Ohio or Arizona DOT.
Transit Agencies	Agencies that operate public transit service operating over the road network. May include busses as well as trains that share right-of-way with roads (light rail).	Regional Bus System such as King County Transit or MTA New York City Transit.
Public Safety Agencies	Agencies that provide public safety answering points (PSAPs) and provide the first response to incidents that occur on the road network.	Police Department, Fire Department, EMS, PSAPs.
Private Data Collection Organizations	Private companies or organizations that collect travel data (e.g., speed data) or road weather data, which they provide to transportation agencies. This also includes companies that collect transit vehicle AVL data and provide it to transit agencies.
Travelers	Traveling public – the primary end user of traveler information in its many forms.	Motorists and Transit Passengers.
Public Traveler Information Providers	Public providers of traveler information or other traveler services. These agencies usually do not collect the travel and traffic conditions data themselves, but obtain their data from transportation or transit agencies. They perform data processing to create a regional (or statewide) traveler information view that travelers can access through web based means.	Regional Transportation Agencies such as TRANSCOM in the New York City area or MTC in the San Francisco Bay Area.
Private Third Party Providers	Private companies or organizations that use real time information to create traveler information products such as smart phone applications. This would also include the media, who provide real time traveler information to their listeners/viewers (in the case of radio/television) as part of their overall news and entertainment efforts.	Smartphone Application Developers, radio/TV stations.
Other Public Agencies	Public agencies that do not have a primary transportation role, but still have a need to obtain or provide various real time information.	National Weather Service, National Park Service, U.S. Military

2.9.2 Managing the Surface Transportation System Using Real Time Information

Table 15. Operational Scenario – Using Real Time Information.
Operational Scenario Element	Description
Operational Scenario Name:	Managing the surface transportation system using real time information.
Description:	Using real time information such as vehicle speeds, incident information, lane closures, and road weather information to manage and operate the transportation network.
Actors Involved:	Transportation agencies, Private Data Collections Organizations, Public Safety Agencies.
Initiator (actor):	Transportation agencies.
Prerequisites:	Availability of information about the road network.
Flow of Events:	The transportation agency collects real time information from the following sources: Link speed data from peer transportation agencies. Incident information from (or combined from) one or more public safety agencies (e.g., local PSAP 9-1-1 call-taker agencies) or from peer transportation agencies. Lane or road closure information from peer transportation agencies. Road weather data from peer transportation agencies. The transportation agency collects real time information from the following sources: Link speed data from peer transportation agencies. Incident information from (or combined from) one or more public safety agencies (e.g., local PSAP 9-1-1 call-taker agencies) or from peer transportation agencies. Lane or road closure information from peer transportation agencies. Road weather data from peer transportation agencies. The transportation agency uses the real time information to manage highway traffic flow through adjustment of: Ramp meter timing. Variable speed limits. Lane control devices. (Note that communication with the traveling public is illustrated in the Section 2.9.4 scenario.)
Alternative scenarios:	Alternative 1: Data Collection from private data collection organizations or other public agencies. As an alternate data collection method, transportation agencies may get real time information for speed or road weather conditions from Private Data Collection Organizations instead of the transportation agency equipment. The Private Data Collection Organization aggregates data collected and provides it to the transportation agency. Road weather data may also be obtained from other public agencies such as the National Weather Service. In many cases agencies may use both this alternative and the basic scenario. Alternative 2: Managing arterial networks using real time data. In an alternative to step 2 above, arterial traffic flow can also be managed by adjusting the timing of the traffic signal control systems. Alternative 3: Data provided from Transportation Agency internal sources. An alternative data collection scenario (that involves internal agency interfaces only) is to collect the following data from agency owned field devices-link speed data, incident information and road weather sensor data. A second internal interface for data is data on road or lane closure due to construction which is obtained from transportation agency construction staff (usually through an agency internal interface or system).
User Needs:	2.5.2.1 Speed Data for Roads. 2.5.3.1 Incident Information from Public Safety for Network Management. 2.5.3.4 Incident Information from Peer Transportation Agencies. 2.5.4.2 Construction Information for Road Management.

2.9.3 Maintaining the Surface Transportation System Using Real Time Road Weather Information

Table 16. Operational Scenario – Using Real Time Weather Information.
Operational Scenario Element	Description
Operational Scenario Name:	Maintaining the surface transportation system using real time road weather information.
Description:	Transportation agencies use road weather information to support maintenance of the roadway network.
Actors Involved:	Transportation agencies, Private Data Collections Organizations, and Other Public Agencies.
Initiator (actor):	Transportation agencies.
Prerequisites:	Availability of road weather data for the road network.
Flow of Events:	The transportation agency collects real time weather data/ information from the following sources: Peer Transportation Agencies. Private Data Collection Organizations. Other Public Agencies (e.g., NWS). The data received may be raw sensor data or aggregated data collected and provided to the transportation agency. The weather information is used to direct maintenance crews to respond to a weather event, either proactively or retroactively. Maintenance vehicles can be dispatched to deposit surface treatments on roadways ahead of a snow or ice storm. Maintenance vehicles can be dispatched to plow and deposit surface treatments on roadways after a snow or ice storm.
Alternative scenarios:	Alternative 1: Data Collection using Transportation Agency Devices. An alternative data collection scenario (that involves internal agency interfaces only) is to collect road weather sensor data from agency owned field devices. In most cases agencies may use both this alternative and the basic scenario for data collection.
User Needs:	2.5.5 Road Weather Environmental Conditions Data for Maintenance Operations. 2.5.5.3 Receive Forecasts of Upcoming Adverse Weather Related Conditions.

2.9.4 Share Information with the Traveling Public

Table 17. Operational Scenario – Sharing Information with Traveling Public.
Operational Scenario Element	Description
Operational Scenario Name:	Share information with the traveling public.
Description:	Dissemination of information such as vehicle speeds, incident information, lane closures to the general public.
Actors Involved:	Transportation Agencies, Transit Agencies, Private Data Collection Organizations, Travelers, Public Traveler Information Providers, Public Safety Agencies.
Initiator (actor):	Transportation Agencies.
Prerequisites:	Availability of information about the road network.
Flow of Events:	The transportation agency collects real time information from the following sources: Link speed or travel time data from peer transportation agencies. Incident information from one or more public safety agencies (e.g., local PSAP 9-1-1 call-taker agencies) or from peer transportation agencies. Lane or road closure information from peer transportation agencies. Road weather data from peer transportation agencies or Other Public Agencies. The transportation agency compiles information for travelers: Travel time and delays. Location of incidents and extent of traffic impacts. Road or lane closures and detours. Severe weather information. Information is delivered to travelers via roadside devices: DMS – Display information to motorists. HAR – Read information to motorists. Connected Vehicle Roadside Units. Information is updated as additional real time data becomes available. As incidents are resolved and delays clear, alerts are removed.
Alternative scenarios:	Alternative 1: Transit Information for Travelers. An alternative scenario is providing transit information to travelers. In this scenario the transit agency collects real time vehicle location information from AVL systems. Information is prepared to be disseminated to travelers: Delay and service change information. Next arrival/departure at a given stop. Travel time information. Information is delivered to travelers: Transit agency website or smartphone applications. DMS at transit stops. Telephone information system. Alternative 2: Traveler Information Service. In this alternative scenario, information is disseminated to travelers via a traveler information service (often known as 5-1-1). Information can be obtained in several ways: Visiting a website or using a smartphone application to obtain real time travel information in either a map or list format. Calling 5-1-1 from a mobile or landline phone and using a series of voice or touch-tone keypad prompts to obtain audible travel information. Alternative 3: Public Traveler Information Provider. Roadway and transit information may be disseminated to travelers via a Traveler Information Provider instead of a Transportation or Transit Agency. The flow of events is the same.
User Needs:	2.5.2.2 Travel Time Data for Roads. 2.5.2.3 Speed Data for Public Traveler Information Providers. 2.5.2.6 Transit Vehicle Travel Time. 2.5.3.2 Incident Information from Public Safety for Traveler Information. 2.5.3.8 Planned Event Information for Traveler Information. 2.5.4.1 Construction Information for Traveler Information. 2.5.5.1 Road Weather Environmental Conditions Data to support Traveler Information. 2.5.5.3 Receive Forecasts of Upcoming Adverse Weather Related Conditions. 2.5.6.1 Real Time Bus Locations. 2.5.6.2 Real Time Transit Passenger Loading. 2.5.6.3 Predicted Bus of Train Arrival/Departure Times.

2.9.5 Share Information with State and Local Government Agencies

Table 18. Operational Scenario – Sharing Information with State and Local Government Agencies
Operational Scenario Element	Description
Operational Scenario Name:	Share information with state and local government agencies.
Description:	Sharing real time information with peer transportation agencies and public safety agencies.
Actors Involved:	Transportation Agencies, Public Safety Agencies, Transit Agencies.
Initiator (actor):	Transportation Agencies.
Prerequisites:	Availability of real time information for the road network, data sharing agreements.
Flow of Events:	The transportation agency collects real time information from the following sources: Link speed data from agency owned field devices, private data collection organizations, and/or from peer transportation agencies Incident information from Public Safety agencies or from agency owned CCTV. Lane or road closure information from peer transportation agencies or from transportation agency construction staff Road weather data from private data collection organizations, other public agencies, peer transportation agencies, or from agency owned sensor The transportation agency sends collected data in real time to peer transportation agencies that have data sharing agreements. The agency also sends data about planned events and construction. The peer transportation agency uses this data to manage its network of limited access and arterial roadways as a result of conditions in the jurisdiction of the agency submitting data.
Alternative scenarios:	Alternative 1: Sharing Real Time Information with Public Safety Agencies. In event 2, real time transportation information is shared with public safety agencies that have a real time information sharing agreement. The agency also sends information about planned events and construction. In event 3, the information from the transportation agency is used by public safety agencies to dispatch first responders to the scene of an incident. It is also used to assist first responders in using the most efficient route to reach the scene of an incident and to manage the incident on scene. Alternative 2: Sharing Real Time Information with Transit Agencies. In event 2, real time transportation information is shared with transit agencies that have a real time information sharing agreement. The agency also sends information about planned events and construction. Sharing can be from transportation agency or from public traveler information provider. In event 3, the information is used by the transit agency to adjust transit service as a result of current conditions.
User Needs:	2.5.3.3 Incident Information from Transportation Agencies for Public Safety. 2.5.3.5 Incident Information for Transit Agencies. 2.5.3.9 Planned Event Information for Peer Transportation Agencies and Other Parties. 2.5.4.3 Construction Information for Peer Transportation Agencies and Other Parties. 2.5.5.5 Road Weather Information for Peer Transportation Agencies and Other Parties.

2.9.6 Share Information with Public Traveler Information Providers

Table 19. Operational Scenario – Sharing Information with Public Traveler Information Providers.
Operational Scenario Element	Description
Operational Scenario Name:	Share information with public traveler information providers.
Description:	Sharing real time information with regional public traveler information providers.
Actors Involved:	Transportation Agencies, Public Traveler Information Providers.
Initiator (actor):	Transportation Agencies.
Prerequisites:	Availability of real time information for the road network, information sharing agreements.
Flow of Events:	The transportation agency collects real time data from the following sources: Link speed data from agency owned field devices and/or from peer transportation agencies. Incident information from Public safety agencies or from agency owned CCTV. Lane or road closure information from transportation agency construction staff. Road weather data from agency owned sensors, private data collection organizations, or other public agencies. The transportation agency sends collected information in real time to a public traveler information provider that it has an information sharing agreement with. The agency also sends information about planned events and construction. The traveler information agency or public traveler information provider redistributes real time information and planned event and construction information to transportation agencies that it has agreements with. It will also output the information to the public.
Alternative scenarios:	None.
User Needs:	2.5.2.3 Speed Data for Public Traveler Information Providers. 2.5.2.4 Travel Time Data for Public Traveler Information Providers. 2.5.3.6 Incident Information for Public Traveler Information Providers. 2.5.3.8 Planned Event Information for Traveler Information. 2.5.3.9 Planned Event Information for Peer Transportation Agencies and Other Parties. 2.5.4.3 Construction Information for Peer Transportation Agencies and Other Parties. 2.5.5.3 Receive Forecasts of Upcoming Adverse Weather Related Conditions. 2.5.5.5 Road Weather Information for Peer Transportation Agencies and Other Parties.

2.9.7 Share Information with Private Third Party Providers

Table 20. Operational Scenario – Sharing Information with Private Third Party Providers.
Operational Scenario Element	Description
Operational Scenario Name:	Share information with private third party providers.
Description:	Sharing real time information with private third party providers who create applications to inform the traveling public of current conditions.
Actors Involved:	Transportation Agencies, Transit Agencies, Traveler Information Providers, Private Third Party Providers.
Initiator (actor):	Transportation Agencies, Public Traveler Information Providers.
Prerequisites:	Availability of real time information for the road network, information sharing agreements.
Flow of Events:	The transportation agency collects real time information from the following sources: Link speed data from agency owned field devices or from peer transportation agencies. Incident information from Public safety agencies or from agency owned CCTV. Lane or road closure information from transportation agency construction staff. Road weather data from agency owned sensors. The transportation agency aggregates transportation real time information that is suitable to be released to the public. This may include speed and travel time information, incident information, construction information, and weather forecasts and conditions information. Additionally, information about planned events and planned construction may be included. The transportation agency provider distributes a data feed of real time information and planned event and construction information to third party providers. The private third party provider disseminates relevant information to the traveling public via a web, mobile application, or other media. The application may have a very limited scope (e.g., just providing construction information), or may be very broad in scope (e.g., providing total situational awareness of regional traffic conditions).
AlternativeScenarios:	Alternative 1: Information from Traveler information Providers. Information to private third party providers is provided by public traveler information provider instead of transportation agencies. Alternative 2: Information from Transit Agencies. Information to private third party providers is provided by transit agencies instead of transportation agencies. In the case of event 1, the transit agency collects transit vehicle information to support distribution of information. In event 2, the transit agency aggregates the raw data to create data streams that can be provided to other agencies. Events 3 and 4 unfold as described above.
User Needs:	2.5.2.5 Travel Time Data for Parties who Create Value added Information Products. 2.5.2.6 Transit Vehicle Travel Time. 2.5.3.7 Incident Information for Parties who Create Value Added Information Products. 2.5.4.3 Construction Information for Peer Transportation Agencies and Other Parties. 2.5.5.4 Provide Forecasts of Upcoming Adverse Weather Related Conditions. 2.5.5.5 Road Weather Information for Peer Transportation Agencies and Other Parties. 2.5.6.1 Real Time Bus Locations. 2.5.6.3 Real Time Bus or Train Arrival/Departure Times.

previous | next

Real-Time System Management Information Program Data Exchange Format Specification 2. Concept of Operations