Weather Applications and Products Enabled Through Vehicle Infrastructure Integration (VII)

4. Technical Background

VII ARCHITECTURE, PROBE MESSAGE PROCESSES AND THEIR IMPACT ON VII-ENABLED DATA

This report discusses the feasibility of using VII data to construct and improve weather-related applications and products. The details and complexities of the VII architecture and probe message processes are not discussed here in detail, but it should be noted that the possibility of using vehicle data for road weather products will depend on the final VII architecture and probe message processes design. For continuity, a synopsis of relevant components of the architecture and probe message processes is provided; however, the reader is encouraged to consult the documents that are referenced in this section of the report for further information. Details associated with the VII architecture and probe message processes are still evolving.

4.1 VII Architecture

The VII program is a cooperative effort involving the U.S. Department of Transportation (USDOT), automobile manufacturers, the American Association of State Highway and Transportation Officials (AASHTO), and several state departments of transportation. Together these stakeholders are working to define, develop, and deploy a nationwide system that would enable vehicle-to-vehicle and vehicle-to-infrastructure communications through dedicated short range radio technology (DSRC-wireless radio communication at 5.9 GHz) (7). For some time, it has been realized that such a system would support the development and implementation of critical safety applications such as intersection violation, hazardous weather warnings, hazardous pavement condition warnings, lane departure, curve speed warning, and collision notification warnings. Other examples of applications that could be supported by the VII framework include signal timing optimization, traffic and congestion measurements, and electronic toll payments. Although these applications are less critical compared to safety applications, they would contribute to improving mobility and efficiency.

The VII concept is based on the idea of using vehicles as probes. As vehicles traverse the nation's roadways, they will measure and collect a variety of information ranging from on-board diagnostics (e.g., emission system status) to measurements of the environment (e.g., air temperature). When a VII-enabled vehicle comes within range of the roadside receiver, selected data elements will be wirelessly transmitted to the roadside, routed to the VII network, and made available to data subscribers. Vehicles will also exchange critical safety information when they are within range of one another. This process of information delivery and exchange will enable the development and deployment of safety and mobility related applications as well as new commercial applications. A critical component in the application development process is understanding how vehicle data elements are produced, stored, and transmitted from the vehicle to the infrastructure.

Figure 4.1 shows the three primary elements that make up the VII system architecture: On Board Equipment (OBE), Roadside Equipment (RSE), and the VII Network. It is envisioned that each VII-enabled vehicle will be equipped with OBE that includes an On-Board Unit (OBU - which is a DSRC transceiver), application processors, GPS system, human machine interface, and vehicle services interface (9). The OBU is responsible for communications between the vehicle and RSE, as well as vehicle-to-vehicle communications. Vehicle probe messages stored on the vehicle are transmitted to RSEs and other vehicles via the OBU. The OBU is also capable of receiving messages from the infrastructure and other vehicles. An important aspect of the VII communication model is that vehicle-to-vehicle and vehicle-to-roadside communication is not continuous. A vehicle (i.e. its OBU) will only communicate with a roadside unit or another vehicle if it is within range. The vehicle-to-roadside and vehicle-to-vehicle transmission range will be approximately 300-400 ft (91-122 m), depending upon the FCC power restrictions (9,10).

FIGURE 4.1. Representation of VII Network Architecture (courtesy of Booz Allen Hamilton)

Similar to the OBE, several components make up the RSE: a transceiver, an input/output controller, a router for VII network access, a GPS receiver, and application processor. Most importantly, the transceiver, or Roadside Unit (RSU), can transmit to and receive data from vehicles within its range (9). In many cases, RSEs will be located at intersections to take advantage of signal controller electronics and provide situational monitoring for local safety applications. Currently, it is estimated that over 450,000 RSEs will need to be deployed to obtain national network coverage.

An example of rural RSE coverage showing RSE locations at national highway system intersections and interstate interchanges is supplied in Figure 4.2. In terms of mature nationwide RSE deployment, a distance of 10 miles will separate RSEs in rural areas, while RSEs will be spaced every 0.6 miles in urban areas². In order to adhere to the 10 mile spacing requirement in rural areas, additional RSEs will need to be deployed beyond what is presented in Figure 4.2. Nonetheless, Figure 4.2 demonstrates the fact that the coverage in the eastern portion of the United States will be more comprehensive when compared to the Great Plains and Rocky Mountain states. Furthermore, RSE density will be proportional to population density; this will have implications on the quality and quantity of observations available in urban and rural settings.

FIGURE 4.2. Potential rural RSE deployment based on national highway system intersections and interstate interchanges. (12)

The VII Network, which includes network access points (NAPs) for the delivery of data to and from RSEs, is characterized in Figure 4.1. The network will also serve to route data to the appropriate data subscribers via service delivery nodes (SDNs). Data flowing through the VII Network will be classified as public or private; thus, applications created from these data can also be seen as public or private. Data that are passed between vehicles and to automobile manufacturers will be considered private, and they will not be available to the general public. In addition, data exchanged between vehicles and some commercial service providers will also be classified as private. All other data will be available to subscribing users such as traffic operation personnel (TOCs), maintenance managers, dispatch operators, etc.

As previously indicated, bi-directional data flow will exist in the system. For example, public messages that relate to safety may be sent through the network to a specific RSE, and the roadside unit will broadcast this information to vehicles within its range of communication.

4.2 Probe Message Processes

In this section, a high-level description of current ideas and concepts for processing probe messages is presented for reference. A probe message is a specific message that is transmitted from a vehicle to an RSE. The methodology for collecting and transmitting probe data to and from vehicles is still being developed by VII program participants, so concept refinements are anticipated.

According to the current thinking, probe data collected by vehicles will be categorized into two groups: periodic and event-driven. Periodic data represent elements that are routinely available for collection. Outside air temperature and vehicle speed are two examples of periodic data. In contrast, data resulting from anti-lock brakes or stability control activation are examples of event driven data elements. Information associated with these systems is available on an irregular, event driven basis.

Vehicles have the potential to provide an inordinate amount of data to the VII network; however, the use of DSRC as the conduit for data transmission does put some constraints on the system. To make effective use of VII communication bandwidth and ensure that the system will not be overburdened with data transmission issues, standardized processes for data collection, prioritization and transmission are being defined.

By the current definition, a snapshot is a collection of vehicle data elements (e.g. temperature, wiper, and light settings) valid at a specific time. The concept is that a maximum of 30 snapshots will be stored on a vehicle at any one time; however, this number is subject to change. Snapshots can be generated in three ways: periodically, event triggered or by vehicle starts and stops (10,11). Periodic generation will occur at prescribed intervals based on the speed of a vehicle as it moves between RSEs. A vehicle traveling at 60 mph or greater will generate snapshots every 20 seconds, while a vehicle traveling at 20 mph or less will generate snapshots every 4 seconds. Interpolation is used to determine the snapshot interval when the vehicle speed is between 20 and 60 mph (10,11). These thresholds were selected in an attempt to evenly distribute snapshots between RSEs. A change in the status of some vehicle systems or surpassing a predetermined threshold associated with certain data elements will initiate an event-triggered snapshot. For example, changes in the traction control system status (e.g. "off" to "on") will result in a snapshot. Finally, when a vehicle begins moving or comes to a stop³, a snapshot will be generated. Independent of what method results in a snapshot, all available vehicle data elements will be included in the snapshot.

As noted earlier, the on-vehicle snapshot storage capacity will be limited. Event-triggered and start/stop snapshots will take precedence over periodically generated snapshots. In some situations, it is likely that periodic snapshots will be deleted from the on-board buffer in favor of event-triggered or start/stop snapshots. Additionally, the buffer space available for periodically generated snapshots will depend on the number of event-triggered and start/stop snapshots occupying the buffer space. The storage of periodic snapshots is based on a first in/first out methodology. If the buffer is full of periodic snapshots and another periodic snapshot is generated, the oldest snapshot in the buffer will be erased to make room for the new snapshot. Conversely, no event-triggered or start/stop snapshots will be erased (unless the buffer is full of these types of snapshots) until the vehicle is in range of an RSE and the data are transmitted to the RSE. If the buffer is limited to 30 snapshots and there are 13 event-generated snapshots, then there will be space for 17 periodic snapshots. Once the buffer is full and another event or start/stop snapshot is generated, the oldest periodic snapshot will be erased.

Generally, weather-related applications and products utilize observations that can be linked to known platforms and sensors. This will not be the case for VII data. No identifying information related to the vehicle or the vehicle's operator will be transmitted as part of a snapshot. Under the current design, the only descriptive information related to the origin of a snapshot will be a vehicle type data element and a temporary identifier (ID). Vehicle type will be used to define the class of the vehicle (e.g. passenger car, bus, truck, etc.) (9). No data concerning the make and model of the vehicle will be made available. A random temporary ID will be linked to the snapshots. This ID will be updated when the vehicle first comes within range of an RSE, and it will be regenerated after 120 seconds or 0.62 miles (1 km), which ever comes first (11).

Other aspects of the probe message processes that will influence the creation of applications and products include the proposed practice of restricting snapshot generation for the first 1640 feet (500 meters) after a vehicle is started, and the proposed standard of deleting all snapshots when the vehicle is turned off (11).

4.3 Implications of Probe Data Collection and Dissemination Processes

The manner in which vehicle data elements are generated, stored, transmitted, and disseminated to product developers will affect the types and quality of products that can benefit from VII-enabled data. This section highlights how the currently envisioned RSE deployment and probe message processes may influence data availability and the development of weather-related products.

A depiction of RSE deployment in rural regions is presented in Figure 4.2. As discussed, the current probe message processes were constructed under the assumption that rural RSE spacing would be 10 miles; therefore, it is likely that some of the RSE gaps displayed in the figure will be reduced. Nonetheless, the VII infrastructure deployment will not occur overnight; it will take several years before reaching a state in which RSEs are located at 10-mile intervals in rural areas and 0.6 miles apart in urban areas. In some situations, data will be lost. For example, in a rural environment where the RSEs may be widely spaced, vehicle data will likely be clumped around RSEs as older data will be eliminated from the on-board data buffer. This design result means that users of the vehicle data should not expect the data to be evenly spaced along roadways, particularly in rural areas. This factor could very well determine what kinds of weather-related applications could be produced using vehicle data, as well as the accuracy of some VII-enabled products. The meteorological community has long relied upon stationary surface observations (e.g. ASOS) with relatively coarse spatial resolution. VII will provide data that would fill in these gaps, but the possibility of data clustering around RSEs would limit the usefulness of these data in some applications.

The loss of data will not only be an issue in rural regions, but it will be concern in urban areas as well. In terms of weather-related data elements, it will be important to maximize the spatial distribution of data between RSEs. Though event-triggered and start/stop snapshots could supply vital information concerning atmospheric and road conditions, collections of periodic snapshots gathered from vehicles will contain data over a larger domain, thus providing more detail about the spatial variations of particular variables. A vehicle encounter with a heavily congested roadway could result in the generation of both periodic and start/stop snapshots. It is possible that previously collected periodic snapshots contained in the buffer could be deleted before an OBU has the opportunity to transmit data to an RSU. In some cases, the deleted snapshots will not only provide data over a greater stretch of roadway, but they may contain more accurate measurements of certain parameters than the more recent snapshots gathered while the vehicle is in heavy traffic (e.g. temperature [see discussion in section 5.1]).

Restricting the initial generation of snapshots until the vehicle has traveled 1640 feet after the vehicle's engine is started, as well as deleting the on-board buffer when the vehicle engine is turned off, will result in the loss of data. Protecting the privacy of the vehicle operator is a high priority, and these probe message strategies may help to ensure that an individual cannot be tracked to a location such as their home or office. However, there may be instances when these strategies restrict data element production or cause data to be purged. For example, there will be times when an individual stops at a store to buy groceries or a gas station to refuel. When the vehicle's engine is turned off, all of the data stored in the on-board buffer will be lost. When the vehicle resumes its trip, it will not produce probe data for another 1640 feet, even if the vehicle encounters an icy intersection and an ABS event occurs. In these types of situations, data that could be used in the analysis and diagnosis of weather and road condition hazards will be lost. Another factor that may result in the loss of data is the fact that a vehicle will only transmit one set of snapshots from the onboard buffer while in range of an RSU. Thus, if additional snapshots are collected while the vehicle is still within range of the same RSU, they will not be transmitted until the vehicle comes into range of another RSU. Not only could this delay the transmission of critical data, but it could also lead to data loss under certain situations (e.g. high traffic). Overall, the potential for data loss will be more critical in rural environments as compared to urban areas, as urban corridors will have a large enough number of reporting vehicles to compensate for such data losses.

Meteorological applications are generally constructed with a great deal of knowledge about the stations from which data are obtained. Not only does an application developer have information about the location and time of the observations, but metadata containing information about the station, including its unique identifier, can be obtained in most instances. This will not be the case with VII-enabled data, and this will present several challenges for developers. The level of maintenance from one vehicle to the next varies greatly; therefore, there will be times when bad data from a malfunctioning vehicle sensor will be transmitted to RSEs and sent on to the VII network. There will not be a way to track this vehicle in an effort to filter out the bad data. The vehicle will repeatedly send erroneous data to the network until the vehicle owner has the vehicle serviced, which may still not ensure that the problem is caught and corrected. For this reason, it will be necessary to have effective quality checking procedures in place for VII data. One method of ensuring data quality is through a Weather Data Translator (see section 8). Knowing the type and location of on-board sensors and the make and model of the vehicle would also aid developers in recognizing vehicles that may contribute biased data to the VII network. Sensor type and location data, along with vehicle make and model data, would help ensure the general quality of VII data.

A summary of the VII architecture and probe message processes, as currently envisioned, has been presented in preceding sections. It is evident that the way data will flow within the VII infrastructure will have a significant influence on the utility of VII data and product development. Changes in the expected VII framework will alter some of the issues that have been described herein; therefore, it is imperative that product developers monitor the VII deployment process and make a note of architecture and probe message modifications, as these will affect the application and product development process.