An In-Vehicle Distributed Technique for Remote Programming of Vehicles' Embedded Software 2005-01-0313

From time to time vehicles need to have their software modules updated for various reasons, such as the introduction of new features in vehicles, the need for changing the navigation map, the need for fine tuning various features of the vehicles, and many others. The software in a vehicle's electronic control unit (ECU) can be updated either at a service station or remotely via wireless links. Remote software update has many advantages: it can save consumers valuable time by not requiring them to bring their vehicles to service stations; software in multiple vehicles can be updated in parallel to save auto companies time and money; software in all recall vehicles can be updated in a timely manner, and so on.

There are two main issues related to the remote software update operation. One issue is the bandwidth required for the update operation, and the other issue is the security of the communication links. In another paper we addressed the security issue of the communication links. The cost of bandwidth can be reduced significantly by taking care of multiple vehicles in parallel (multicast process) rather than taking care of one vehicle at a time (unicast process). We explained the multicast update process in a different paper.

Programming an ECU's embedded software requires erasing the ECU's flash memory and then reprogramming the ECU. Erasing the flash memory requires some time, during which the wireless link will remain idle. However, if the wireless link is released while the ECU is erasing its flash memory, then it will take some time to reestablish the link between the vehicle and the remote server. Thus, some bandwidth will be wasted one way or the other. This paper presents an in-vehicle distributed technique to reduce the latency of the remote software update process as well as save the bandwidth of the wireless links.

Every ECU in a vehicle has some RAM buffers to accept blocks of code from an external device before the code is actually written into the ECU's flash memory. If the code size is larger than the total buffer size, then the code is sent to the ECU in several steps. At every step, a part of the entire code is sent to the ECU. Each part of the code is first saved in the RAM buffer, and then it is written to the ECU's flash memory. This process is continued until the entire code is written into the ECU's flash memory. During this process of software update, the link between the external device and the vehicle remains idle for a significant amount of time, which is not acceptable if the external device is a remote unit connected to the vehicle by a wireless link. In this paper, we propose to use the RAM buffers of as many ECUs as we need to keep the entire code that needs to be updated in a particular ECU. This means that first, the code will be distributed among RAM buffers of several ECUs and then the code will be written into the flash memory of a particular ECU. The advantage of this technique is that if the total size of all the buffers of all the ECUs together is larger than the size of the code that needs to be updated, then the link between the external device and the vehicle will not be idle. As a result, the performance of the communication system can be improved. This paper presents a detailed description of the in-vehicle distributed algorithm and compares its performance with that of a non-distributed software update algorithm.