Reprogrammable onboard modules have been in automotive use for more than a quarter century. But as electronic controls inhabit virtually every system today, anyone with a late-model vehicle knows that at some point, one or more of its electronic control systems will need to be "reflashed" with new software—often more than once.

In fact, even where the problem may be all-mechanical, including bearing knock, it can be ameliorated by new software for the engine computer.

While some of the reflashes are for customer satisfaction items, such as the air conditioning system that won't maintain set temperature, an increasing number are safety related. At best, perhaps 70% of the urgent notifications  of a safety recall bring the customer into the dealership, and both government and industry are looking  for ways to bring  it as close to 100% as possible.

With autonomous driving on the horizon, the security and safety aspects create a new urgency for the ability to perform updates on a timeline that doesn't wait for the leisurely pace of a service appointment at the dealership.

Tesla success with OTA 

Tesla's recent use of over-the-air (OTA) reprogramming has been successful, but this emergent OEM has a comparatively small owner base and that makes vehicle identification a simpler task. The typical Tesla reflash takes 45 minutes, but because the vehicles are electric drive, they can be reprogrammed during a recharge. Vehicles powered by gasoline and diesel engines face the more difficult issue of assessing battery state of charge to ensure it is high enough to complete the reflash.

Some automotive reflashes  require so much time (perhaps more than a day) that presently the only way they can be made is with the car in a shop, using a proprietary factory tool or an SAE J2534 "Pass-Thru." Such reprogramming also includes use of a dedicated battery charger made for the specific purpose, so it produces a "clean" current flow that is free of electrical noise ("ripple') that could cause the operation to fail. 

Because the carmakers are responsible for updates, they may start to install capacitors to smooth out the ripples from the charging  system, making OTAs more feasible.

A related factor is available bandwidth, which could be subject to considerable change over a cellular network. That's why Tesla recommends its updates be performed with WiFi. Additionally, the OEM would have to design updates for piecemeal reflashing, so they can be installed incrementally as the system and needed battery capacity are available.

This issue goes beyond the need of a single module. Many updates are lengthy because of the design of the data bus in which it is installed. The update itself may apply for just the one module, but other modules on the bus may need to know about it, whether because there are new messages they must recognize, or know to ignore.

All suppliers of infotainment/ onboard communications and WiFi are working with car makers to develop systems with OTA reprogramming function comparable to Tesla, but the larger and more diverse the vehicle base, the more complex the task. There have been reports that several makers will begin to do some OTA this year.

Security is No. 1 issue 

Russ Christensen, Director of Automotive Solutions Architecture for Wind River, a systems supplier in this area, said the No. 1 issue  has become security. It begins at each end (the source of the update at one, likely a cloud server, and the car's infotainment system at the other) so each is talking to a known authority.  In the car that authority usually would be the telematics/gateway module.

The key to security is in the architecture, he said, telling Automotive Engineering that presently such appendages as the smartphone and watch, and keyless entry, hitherto not so considered, can be "threat vectors" into the car.  He added that the CAN bus (Controller Area Network) was not designed for encryption, although there are some strategies for accomplishing that.

Also required is a way to get an authenticated payload (the updated software) to the car and having an electronic "place" to hold it, Christensen said. A manifest comes down with all updates; the car says okay, a signature comes from the cloud and the car validates it.  The first update is then discharged to the ECU.  Which raises this issue: if the installation fails, the system needs to be able to activate a "restore" function to get the system back to original setting.

If there are three updates in the manifest, and the failure occurs during the third, there may need to be a removal function, so the system reflashes back to the original state.

"None of this is hard," Christensen noted. "We just need the vehicle design to be able to do it." He cited the example of an  "atomic update," where all updates must be installed at once or none should be.

Bypassing owner OK 

Christenson cited banking industry money transfers as an example of the way installations must be executed with secure protocols, where a scheduled data transfer must be completed instantaneously, or the entire transaction goes back to its previous state.

When there is an urgent safety update, the comparatively slow pace that includes owner evaluation and approval may need a work-around. There might be have to be a provision for abrogating authorization, although that would be a last resort for an OEM.

A critical aspect of the entire challenge of OTA updating is identifying the vehicle configuration.  Many OEMs right now do not have software configuration matrixes at a sufficient level of confidence to always be certain of the right software for all vehicles.

"The manufacturer can't even rely on the VIN once the car has left the assembly line," Christensen said, and certainly not if a module has been replaced.