Field infrastructure footprint analysis

2.3.Connected Vehicle Data Needs and Standards

1. Infrastructure Data Message Standards: the BSM

The SAE J2735 message standard describes a variety of messages generally associated with connected vehicle applications. However, while the standard does include roadway alert and probe data message types, most of the recent development effort in the standard has been devoted to the Basic Safety Message Part One (BSM-1). Recently the BSM has assumed the role of providing “probe data” as well as fulfilling its vehicle-to-vehicle safety role. This message provides reasonable knowledge of a vehicle’s kinematic state to other vehicles within range of that vehicle’s DSRC radio. Other than providing a small amount of data about the recent past path of the vehicle (i.e., the path of the prior few seconds), the message content is specific to the current location of the vehicle at the time of transmission and it is oriented specifically toward safety. As such, it does not provide any insight into road conditions or vehicle behaviors at other prior locations. It is specific to the transmission and collection point.

Additional messages, specifically the BSM Part Two and the probe vehicle data message have been proposed, but details of the content of these messages is still not well defined, and the conditions under which this data will be delivered, if at all, are unknown. This issue is discussed at some length in the report “Vehicle Information Exchange Needs for Mobility Applications Exchange” which identifies the significant limitations of using the BSM message for infrastructure applications.

Recommendation: Revise the system operational concept to explicitly include the collection and delivery of probe data, and develop next generation probe data messages and collection protocols with heavy involvement of AASHTO stakeholders to assure the collected data is useful and relevant. This effort needs to also consider Gaps 27 and 28 which deal with the motivations and value chains so that there is a clear motivation for car makers to include this functionality. In effect, the rationale should be that the AASHTO stakeholders will install and maintain the infrastructure elements of the system, which benefits the vehicle users and facilitates V2V safety in exchange for providing probe data.

2. Infrastructure Data Message Standards: Extensibility

In addition to the general uncertainty about whether specific data will be available or not, the J2735 standard is somewhat rigid about data structures and tends to package the data into fairly large and somewhat application-specific elements. For example, the BSM Part Two may contain many data elements whereas the receiver may only be interested in one or two of those elements. This is both inefficient from a communications perspective and is inflexible for implementers who may or may not be motivated to provide all assumed data elements. While suppliers may provide data when they understand where the data is going and how it will be used, they are unlikely to supply data elements if it is not clearly useful to somebody.

In addition, these messages are not easily adapted to support data elements that are not yet identified but may become interesting in the future. One of the great strengths of the Internet is that the underlying protocol assumes nothing about the types of data that are being transmitted. This protocol, initially envisioned to support email and small file exchanges, has enabled developers to support voice, video, gaming, and a virtually unlimited array of other applications. While there has been no effort specifically to curtail future expansion, the current approach has been to define message sets that support all projected future needs, even though there is relatively little certainty that these needs can be anticipated accurately

Recommendation: In addition to known application-specific messages, such as the BSM, extend and/or revise the messaging standards to support data objects rather than application specific sets of data. For example, SPaT is effectively a time-based statement of the pass-ability of specific pathways through an intersection, and as such is only marginally different from a closed lane or other lane-specific alert. This more abstract and general approach would separate the message definitions from the user applications and would provide for a much wider and more diverse set of applications.

3. Location-based Warning in the Map Linkage Structure

The current messaging scheme treats warnings and advisories as independent from maps that may provide context for those warnings (e.g., curve speed advisories, intersection warnings, etc.). Typically the map data necessary to understand the warning includes localized geometric data for a particular localized section of roadway.

Since, in this scheme, the warning is delivered separately from the map there is a finite possibility that the vehicle may not have the required map when it receives the message. Assuring that the vehicle does have every map for every message thus adds complexity to the deployment of an application, because the system has two messages instead of one, and the deployer must consider how to efficiently deliver the map, and how to assure that the map version is up-to-date, while the user developer must guess as to how long to retain such map data.

Recommendation: Review warning applications and messages to determine if the map data needed to make use of the warning message can be included in the warning message itself. If so, consider revising the message standards to support this.

4. Map Database Assumptions

There are various approaches to referencing road hazard information to the actual as built road. All of these generally rely on some sort of road description or map. However, the source of the map data is subject to a wide range of opinions. Some implementers assume that commercial maps will be available, while others assume that if the data is necessary in order to use the data, then it should be provided by the same jurisdiction providing the road hazard information. The first approach is simple, but it risks issues from both map availability and inconsistency between the location reference of the hazard and the location reference and accuracy of the map. This inconsistency is especially likely since there are many map makers, and there are few standards for map accuracy and content. The second approach requires that the map data associated with the messages be provided in a timely manner, and it means that practitioners must be concerned with generating this data. Either way works, but since the vehicle will travel through multiple jurisdictions, whichever is used must be consistent. If one jurisdiction provides map data while another assumes that it is commercially available, then implementation of the system must include the complexity of both approaches. The lack of consistency about which source to use introduces a great deal of uncertainty and interdependency across the implemented community, a substantial portion of which is based on speculation about what the commercial map makers may or may not do.