Pilot Sites Embrace Over-the-Air Support Networks for Software/Firmware Updates

Over-the-air (OTA) technology allows software and firmware updates to be rolled out to a connected vehicle (CV) remotely and eliminates the need to require a technician to physically install them in the vehicle. Such implementation is expected to be a game-changer for future CV deployers’ vehicle fleet management. Enabling OTA updates was particularly critical for all three CV Pilot sites’ deployment concepts due to 1) the number of vehicles involved in the projects and 2) the need to update software and application parameters during the operational phase. Many of the Pilot participant vehicles (e.g., taxis, buses, semi-trucks) have schedule and operational constraints that restrict them from coming into the maintenance shop for manual software updates. The sites thus performed extensive research, design and testing of their individual OTA mechanisms to accommodate these needs.

Participant vehicles of the New York City Department of Transportation (NYCDOT) CV Pilot are revenue generating or commercial fleet vehicles that are expensive to “touch” because it means taking the vehicle out of service to a maintenance facility, which is not practical. To address this, the NYCDOT Pilot procured and developed OTA processes to update CV software and operating parameters for the vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I) and pedestrian applications. The NYC CV pilot has the added restriction that only Dedicated Short-Range Communications (DSRC) is supported by the vehicles and CV infrastructure; thus, all OTA updates use only the DSRC infrastructure installed for the project. To support these firmware updates, the deployed NYC CV infrastructure includes OTA firmware updates using a subset of roadside units (RSUs) strategically placed at 36 “support” locations, including airports and terminal facilities frequently visited by fleet vehicles and where the vehicles will be parked for a sufficient amount of time to support firmware downloads.

The firmware update process for the after-market safety devices (ASDs) is initiated by the Traffic Management Center (TMC) device management subsystem. The device management subsystem will send out Wave Service Advertisements (WSAs) over a control channel to the ASDs through select RSUs. WSAs notify a device when a new firmware update is available, so that an update can be initiated once the vehicle is at a support location. Once the ASD “hears” an RSU that supports updates, it is directed to a specific service channel to receive the update.  The updates use a network coding broadcast technique that supports downloading to a large number of vehicles at the same time; the design also supports a download on request for those vehicles that may have been out of service or otherwise unavailable when the update was initially made available.  This overall technique allows the “mass downloading” of updates to a large number of vehicles while still supporting “stray” updates later; further, the vehicle population is divided into groups such that the downloads can be targeted to specific vehicles or groups of vehicles for testing, specific vendors or versions of the ASD, or specific fleets.  Verification of the updates is performed by the ASD firmware vendor and the update is provided to the TMC by the vendor with the appropriate signature. The TMC manages all updates which allows NYC to test and evaluate updates before mass distribution.

The Tampa Hillsborough Expressway Authority (THEA) Pilot is unique in that it is the only CV Pilot deployment site to utilize volunteer drivers of privately-owned vehicles. THEA looked to incorporate OTA updates into their pilot so that they would not need to inconvenience their participants by requiring them to bring in their vehicles for service whenever application software required updating. THEA deployed additional RSUs not previously considered in the deployment plan along the Reversible Express Lanes (REL) for OTA file broadcast and data log transfer purposes. Downtown RSUs also broadcast firmware updates to cover buses and streetcars. These dedicated RSUs are able to leverage normally unused DSRC channels in addition to providing more bandwidth.  THEA is able to successfully update OBUs at high speeds estimated at up to 65 miles per hour on the REL.  The OTA broadcast is capable of broadcasting separate updates: one to “test” vehicles (aka Friend of the Pilot) and the other to participant vehicles, buses, and streetcars.

THEA overcame two main challenges when developing the OTA mechanisms. First, due to the unlikelihood of an onboard unit (OBU) being within radio range for the amount of time needed to download the full 100 MB+ firmware file, THEA decided to break up the files into packets that fit into the size limit of a DSRC / WAVE message frame (1400 bytes). Since each OBU must receive all packets in order to be able to reconstruct the entire firmware image sent, THEA applied a special encoding scheme for the packet broadcast that allowed a single OBU to reconstruct the entire file following receipt of the proper number of file packets. Second, due to multiple OBU vendors, recipient OBUs needed the ability to filter packets relevant to a particular vendor. To account for this, THEA designed the RSUs to send out each vendors’ packets to a User Datagram Protocol (UDP) port that is unique to that vendor, with the unique port numbers being announced as part of the OTA WSA service info. As the OBUs travel through the deployment area, the devices collect the packets of firmware from the dedicated RSUs to reconstruct the entire firmware file. When the download is completed (typically after a few passes), the firmware is automatically installed by the vehicle. THEA recently conducted a test to successfully upload data from multiple cars traveling at a high rate of speed, in this case, 40 mph. THEA and its partners were excited to learn that the system can reliably upload and collect data that will help improve safety, enhance traffic flow and help evaluate the effectiveness of CV technology.


Illustration of multiple files broadcasting from multiple vendors (Source: THEA)


The Wyoming Department of Transportation (WYDOT) project focuses on Wyoming’s 402-mile stretch of Interstate 80 and the semi-trucks that frequent this route – making it by far the largest deployment area of the three Pilots. Such a wide spanning deployment area made it difficult to establish a home base for maintenance, necessitating capabilities for automated, OTA software updates. The Wyoming Pilot’s OTA updates are performed as they are released by the vendors and are carefully managed to help maintain system integrity. Firmware images are downloaded to the OBU as the vehicles drive by the RSUs on the I-80 corridor using a restartable secure copy process.  This is helpful as firmware updates are about 28 MBs, which is still too large to download during a single interaction with an RSU at highway speed.  When all data for an entire firmware image are downloaded, the OBU prompts the user on the Human Machine Interface (HMI) to install the new firmware upon the next system startup. HMI updates will be uploaded directly to the Google Play Store, where they will be downloaded automatically once the HMI connects to the internet. Similarly, after receiving a new RSU firmware version from its vendors, WYDOT bench-tests the new firmware and, if it passes, the firmware is then tested on a subset of test RSUs. After testing is completed and approved, the new firmware is marked as the latest version to be broadcast and pushed to the Operational Data Environment (ODE) for dispersal to all RSUs along I-80.


Wyoming Pilot (Source: WYDOT)

Over-the-air updates from RSUs to OBUs in the Wyoming Pilot (Source: WYDOT)


These standardized over-the-air update procedures allow each of the CV Pilots to efficiently update all or a subset of their vehicles to meet both device manufacturer recommendations and their own custom configurations. Software and firmware updates are a vital part of the CV infrastructure and the CV Pilot’s implementation and lessons learned will provide key guidance for future deployers.