**Publication of Interim Guidance on the**

**Information Sharing Specifications and**

**Data Exchange Formats for the**

**Real-Time System Management Information Program**

Comments submitted to:

US Department of Transportation

Federal Highway Administration

Docket No. FHWA-2007-28969

By:

Melanie Crotty, Director, Traveler Coordination and Information

Metropolitan Transportation Commission

San Francisco Bay Area

February 12, 2008

**Introduction**

The Metropolitan Transportation Commission (MTC), the nine-county San
Francisco Bay Area's Metropolitan Planning Organization (MPO),
appreciates the opportunity to submit comments to the FHWA on the
contents of the interim guidance for information exchange under the
Real-Time Information Program (RTIP). As the MPO, MTC's comments are
from a regional perspective. MTC is responsible for the Regional
Transportation Plan, the Regional ITS Architecture, the 511 Traveler
Information Program, TransLink^®^ (a smart card for transit fare
payment), FasTrak^®^ (electronic toll payment) and other regional
operational programs. Through our 511 Program, MTC has developed
significant experience collecting, fusing and disseminating traffic and
transit information.

**Overarching Comments**

MTC believes some guidance on data sharing obligations would be helpful,
and in fact is a greater imperative than the suggested guidance for
interfaces specific to the RTIP. MTC is working with various transit
agencies to create a regional clearinghouse for transit data. The
clearinghouse serves as the regional database for a trip planner and a
real-time transit information service. At this time, one of our biggest
challenges is to get transit agencies to share their data. Some
recognize the benefits of sharing information to improve transit
connectivity for transit customers, but others take a more competitive
viewpoint when it comes to data sharing. With respect to traffic data,
the California Department of Transportation (DOT) has real-time data on
their freeways provided by traffic.com that is not available to 511. It
would be valuable if there were a federal requirement that service
information (including real-time data) from public transportation
providers (e.g. transit agencies and DOTs) be shared with 511 service
providers.

Until we can resolve this issue, much of the details around standard
interface requirements and data exchange formats will be lower priority
for MTC. The first step should be to guarantee the most important data
is available. The second then would be a consistent technical
definition. That said, we will try to provide comments on some of the
details.

The RTIP is to be created in concert with the updates of the regional
ITS Architectures as they are maintained. However, the regional ITS
Architecture already has ITS standards delineated as part of the
regional systems integration. The RTIP will establish data exchange
formats, but it is not clear what the impacts are for what has already
been created in the regional ITS Architectures in terms of ITS standards
deployment.

For the data exchange formats, it is not clear what the ultimate vision
is for the control of the data flow and maintaining data feeds between
agencies. From a regional perspective, MTC gathers data from different
sources in different formats and retains the responsibility for ensuring
that agencies and private entities have continuous access to the data as
it is available. The level of effort to maintain access to the data can
be a daunting and costly undertaking. It is not as simple as a common
data exchange format, but it must include integration and operational
support in order to make sure the data flow is continuous and exchanged
in real-time (or as close to real-time as possible).

Since it is not clear how the data exchange formats are to be
implemented other than identifying the data objects, messages and
dialogues, there must be provisions for technical guidance and oversight
by the FHWA in the proper development and implementation of the ITS
standards. It is our experience that simply developing data formats to a
common standard including messages and dialogues is not enough. There
needs to be a clear path to take the data formats, messages and
dialogues and integrate them into each of the affected agency systems,
i.e., developing the interfaces necessary for real-time information
exchange.

A large concern for MTC as a regional entity is the level of effort that
will be necessary to plan, design and implement the RTIP. Since there
are many existing systems in the San Francisco Bay Area with existing
data interfaces between them, adding another level of data exchange
requirements can be a significant effort. It is not clear how the FHWA
plans to roll out the RTIP including providing technical support and
funding for systems planning, design, integration, on-going maintenance
and management of the source data and newly developed interfaces.

The reference document states that an agency will establish a connection
to the data source and retrieve the information needed. Given the data
is supposed to be real-time data, it is not clear what the
responsibilities are to keep the source data updated such that it can be
considered real-time. For instance, transit schedule adherence is
proposed to be handled through estimating a transit vehicle's delay at a
stop. Depending on how often that information is retrieved and made
available for the RTIP, the information could be off by several minutes.

Below are some questions MTC developed for USDOT consideration:

1.  Is the RTIP going to supersede the use of ITS standards in the
    regional Architectures?

2.  What are the impacts of the RTIP on what has already been created in
    the regional ITS Architectures for ITS standards deployment?

3.  What is FHWA's definition of "real-time" when used in the context of
    data exchange under this RTIP?

4.  How are the data exchange formats to be implemented as this
    reference document appears only to identify required data elements,
    messages and dialogues?

5.  How does the FHWA plan on rolling out the RTIP including provisions
    for providing technical support and funding for systems planning,
    design, integration, on-going maintenance and management of the
    source data and newly developed interfaces?

6.  Who will be responsible for keeping the source data updated such
    that it can be considered real-time?

7.  Who will be responsible for controlling the distribution of the data
    and maintaining its accuracy?

8.  What stipulations or considerations will be given to existing
    systems that already have well defined data formats and are
    currently exchanging real-time information?

9.  What is FHWA's expectation of the implementing agencies in terms of
    implementing the ITS standards indicated in the reference document
    that are revised and/or updated?

10. Is the primary intent of the RTIP to mandate the implementation of
    the ITS Standards for existing and future systems or just future
    systems?

11. How will updates to the standards be handled and what are the
    expectations for meeting them?

**Questions Asked in the Reference Document**

The following are the question asked in the reference document (in
italics) with MTC's responses following each question.

1.  *What guidance would facilitate the application of data exchange
    formats in your organization?*

> It is our opinion that guidance on the approach to implementing the
> overall RTIP is needed including the extent to which agencies are to
> plan and design their systems around the RTIP and the organization(s)
> who will be providing the oversight and approval of the RTIP
> implementation.
>
> Technical guidance is also needed for agencies in order to decipher
> the data formats including messages and dialogues such that there is
> no misinterpretation of how to implement them. However, the extent of
> this guidance may change should an agency rely on self-certification
> (see question 8 below).

2.  *Does the reference document provide adequate detail on the nature
    of interoperability to be attained through application of the data
    exchange formats?*

> While the reference document provides a good starting point with the
> functional specifications, there are many more details involved in the
> development of data exchange formats beyond the messages and
> dialogues. Based on the reference document, the intent of the RTIP
> appears to be to require agencies to develop their data formats based
> on a common standard. Based on our experience, there are many details
> that will need to be worked out on how the data is actually exchanged
> between different systems, and we feel that agencies need latitude and
> flexibility on the development of these details in order to ensure
> that the data is made available and can be maintained. MTC has
> successful experience in collecting and providing real-time
> information and must have the flexibility in developing the details
> and implementing a real-time data exchange system under this RTIP.

3.  *Does your organization make use of the ATIS--01 Broadcast Traveler
    Information Market Package defined in the National ITS
    Architecture?*

> MTC, as a regional entity responsible for the regional ITS
> Architecture and the Bay Area's 511 Program has implemented parts of
> this market package. The figure below illustrates the tailored market
> package for the 511 Program in the San Francisco Bay Area.

![](media/image1.wmf){width="5.999305555555556in"
height="4.752083333333333in"}

*Source: Bay Area Regional ITS Architecture, 2007*

4.  *What is a reasonable interval between publications of new versions
    of the data exchange formats?*

> At a minimum, the same number of years as the regional ITS
> Architecture updates in order to achieve consistency. Since the
> architecture should contain regional integration projects including
> center-to-center systems, it is more practical to tie the standards
> updates with the updates to the regional Architecture. This will also
> serve to build in the development and rollout of the standards
> together with the identified ITS projects for the region.

5.  *Is there sufficient detail in the ''Functional Area/Requirement
    Description?'' If not, how much further requirement description
    would be required?\
    *

> The Functional Specification Descriptions are at a high level and seem
> to provide enough detail on the general information to be exchanged.
> While this is adequate for the planning level of the RTIP, there will
> need to be more guidance from FHWA as systems begin to move into
> design and implementation. However, we feel that this guidance must be
> balanced with allowing agencies latitude and flexibility on the
> implementation and certification of their systems. Based on our
> experience, for a real-time data exchange system to be successful,
> there has to be the requirement first that agencies must share their
> data, and then from there the data formats and interface
> specifications can be developed. Having the flexibility to develop the
> details of the interfaces will be very important to MTC.

6.  *Many of the requirements map to messages that have optional
    elements. Should there be changes to the identification of the
    optional elements, which would change the nature of the message as
    defined by the Standard Development Organization?\
    *

> This depends on the overall goals of the RTIP. If these optional
> elements are stipulated in the message standards that are needed to
> fulfill the functional specifications, then these optional elements
> need to be called out as mandatory elements in the RTIP. This is an
> example of the level of detail that is necessary for the development
> of the functional specifications.

7.  *Does your organization make use of the ITS Standards that are
    referenced in the data exchange formats?*

> To date, MTC has only implemented the TMDD referenced standard in the
> Bay Area. This includes an on-going Interim Center-to-Center System
> that will implement a small subset of the TMDD for message signs, ramp
> metering and traffic control information.

8.  *Would independent certification or self-certification be more
    effective for validating the application of the data exchange
    formats?*

> Either approach could work if resourced appropriately. MTC would
> prefer to self certify the verification and validation of the data
> exchange formats, but expectations need to be commensurate with the
> amount of federal funds made available for this effort. If no funds
> are made available, the self-certification process should be very
> modest.

9.  *Do the data exchange formats relate to the operational practices of
    your organization?*

> The data exchange formats indicated in the reference document are not
> currently implemented in any of the regional systems under MTC's
> control. However, for the most part, the functional specifications
> indicated relate to the operational practices of the regional systems
> in the Bay Area. This includes the exchange of real-time information
> on freeway and transit conditions, real-time freeway travel times and
> transit departures, freeway incidents and closures, maintenance
> activities and severe weather conditions. Other areas of service
> including parking and emergency management are provided, but are not
> delivered in real-time as the functional specifications stipulates.

**Detailed Comments on the Functional Specification Descriptions**

The following comments are related to the specific functional
specifications in the reference document.

> *Requirement Nos. 0.3.2, 1.5.1.1 and 1.5.2.1*
>
> The reference document identified tailored interfaces based on a set
> of criteria which includes "Remove request flows". However, the
> above-mentioned requirements call for information to be provided "upon
> request". The implementation of these standards should be based on a
> publish/subscribe model and information should be provided based on an
> accepted subscription by a publishing agency (agency with the source
> data).
>
> *Transit Management*
>
> There should be an analysis of the implications of the Transit
> Cooperative Interface Profile (TCIP) standards (Transit ITS Standards)
> on the RTIP. The Transit ITS standards have identified working group
> areas including Scheduling and Incident Management.
>
> *Requirement Nos. 1.8 and 3.2*
>
> The functional specifications do not include transit vehicle
> predictions (arrivals or departures) but instead there is a reference
> to how many minutes a transit vehicle will be delayed at a stop point
> or time point.
>
> Typically, real-time transit arrival/departure systems generate
> predictions of transit vehicle arrivals or departures at a stop and
> the predictions are continuously updated. It is only through gathering
> data on the *actual arrival time* of a transit vehicle at a stop that
> the actual schedule adherence can be determined. Thus, it may be more
> effective to provide real-time transit prediction information and the
> transit agency schedule information as the source data and from these
> twp pieces of information, the schedule adherence for a point in time
> can be estimated.
>
> *Requirement No. 3.5*
>
> This functional specification should only include the data on
> real-time arrival/departure predictions. This is typically how
> real-time transit information systems operate. If they are able to
> provide "... data related to how many minutes a transit vehicle will
> be delayed at a stop point ..." then they should have real-time
> transit predictions available.
>
> *Requirement Nos. 1.5.1 and 1.5.1.1*
>
> It is not clear what the difference is between 1.5.1. and 1.5.1.1.
> Based on the mapping table, 1.5.1.1 is a decomposition of 1.5.1, but
> the only difference is providing the data upon request which should be
> changed to " ... published upon acceptance of a subscription".
>
> *Requirement Nos. 1.5.2 and 1.5.2.1*
>
> It is not clear what the difference is between 1.5.2. and 1.5.2.1.
> Based on the mapping table, 1.5.2.1 is a decomposition of 1.5.2, but
> the only difference is providing the data upon request which should be
> changed to " ... published upon acceptance of a subscription".
>
> *Requirement Nos. 1.11 and 1.12*
>
> The mapping table does not indicate a dialogue or message for either
> environmental conditions (1.11) or air quality information (1.12).
>
> *Requirement Nos. 1.13.4.1 and 1.13.4.3*
>
> One functional specification (1.13.4.1) states to provide information
> on shelters during an evacuation and the other (1.13.4.3) states to
> provide information on available shelters during an evacuation. It is
> not clear if the first specification is to provide information on all
> shelters whether they are available or not. This needs clarification.
> A suggestion is to only require the data for "available shelters" as
> information on shelters that are not available during an evacuation is
> not useful.
>
> *Requirement Nos. 1.13.6, 1.13.6.1, 1.13.6.2*
>
> These requirements should be analyzed against the TCIP set of
> standards.
>
> *Requirement Nos. 1.13.8, 1.13.8.1, 1.13.8.2, 1.13.8.3 and 1.13.8.4*
>
> These functional specifications should also provide the roadway
> segments affected.
>
> *Requirement Nos. 2.1.1 through 2.1.5*
>
> These functional specifications should also provide the roadway
> segments affected.
>
> *Requirement Nos. 2.1.7 through 2.1.8*
>
> These functional specifications should also provide the roadway
> segments affected.
>
> *Requirement Nos. 6.1.4.1 and 6.1.4.3*
>
> One functional specification (6.1.4.1) states to provide information
> on shelters during an evacuation and the other (6.1.4.3) states to
> provide information on available shelters during an evacuation. It is
> not clear if the first specification is to provide information on all
> shelters whether they are available or not. This needs clarification.
> A suggestion is to only require the data for "available shelters" as
> information on shelters that are not available during an evacuation is
> not useful.
>
> *Requirement Nos. 6.1.6, 6.1.6.1 and 6.1.6.2*
>
> These requirements should be analyzed against the TCIP set of
> standards.
>
> *Requirement Nos. 6.1.8, 6.1.8.1, 6.1.8.2, 6.1.8.3 and 6.1.8.4*
>
> These functional specifications should also provide the roadway
> segments affected.