There is a lot of talk about software revolutionizing the automotive industry and the conversation is growing because of how software management will impact the whole business of recalls. The outrageous amount of good money going after bad is the reason why car manufacturers and Tier 1 suppliers are looking for an optimized and alternative way to reduce the amount of time it takes to deliver a software update, reducing the cost associated with recalls and improving customer satisfaction. If the same method for performing automotive software updates in production, at the dealer, or at home continue, so will the inefficiencies that are causing car manufacturers to pay hundreds of millions of dollars every year.
When doing a software update either over-the-air or via a cable, one goal is to deliver the smallest update package possible, reducing update time and cost. There are several methods to reduce the update file size but the two most notable are compression and delta (differential) updates – only sending the code that is different between the old software that needs to be updated and the updated software.
With both technologies the goal is to reduce the number of bytes that are being delivered to:
- Reduce the download time – The new software needs to quickly get to the car’s gateway (e.g., head-unit) in order to start the update process
- Decrease the amount of needed memory – After the new version is delivered, there needs to be room to store it before the update is started
- Decrease the transport time between the gateway and the target ECU – In case of ECU update, the new version needs to go through the CAN/LIM/NOST bus, which is limited in bandwidth
- Reduce the update time – The update time depends in some cases on the amount of changes that exist in the new version
There are tests conducted by leading automotive companies and scientific research that show in detail the comparison between compression solutions and delta update technologies.
Vector, an embedded software testing company, worked with Red Bend on a proof-of-concept testing the efficiency of the delta technology. Vector chose an NXP chipset that is common in ECUs – such as the powertrain – and connected it to vFlash via the CAN bus. The vFlash functions as the off-board tester for managing the reflash process. Vector ran an ECU reflash three times – one with a software full image, one with a compressed image and the third with using Red Bend’s delta technology combined with Vector’s bootloader.
The efficiency of the delta technology is much greater than any compression technology (LZ77 in this case) (Figure 1). Using compression, the file went from 4.1 MB to 2.5 MB. Using delta technology, the file went down to 128 KB. There are interesting results that also support delta technology when comparing programming time associated with different processes and technologies. For the full download, programming time was 215 seconds; compression and pipelining was 124 seconds; in comparison, a delta program time was 63 seconds.
Dr. Ralf Schmidgall in his thesis "Automotive Embedded Systems Software Reprogramming" analyzed the methods of reducing the size of the version when doing software updates. In Table 1, Dr. Schmidgall summarizes the results of a theoretical case study to compare the approaches.
The delta technology results in a much smaller file than any method of compression, and the impact on the update time is dramatic, even if the speed of the CAN bus is increased to 1,000 Kbps also in this case the advantages of delta is clear.
In his summary Dr. Schmidgall wrote, "Differential file update provides the best theoretical results of all researched approaches ... If the increase of ECU software sizes continues in the future, this approach might be the only sustainable one to solve the problem of increasing reprogramming times" (Figure 2).
Red Bend Software