Dual Banking for Seamless SOTA updates - KPIT
Dual Banking for Seamless SOTA updates

Introduction

Automotive feature upgrades are essential in the wake of autonomous and connected cars. The SOTA (Software Over the Air) update is going to be the default for bugfixes, enhancements and new features. Dual Banking is inevitable for a better customer experience in such a scenario. For Dual Banking the memory requirement for updateable software components is 2X compared to usual in an ECU. This memory is divided into two equal partition and called Bank-A and Bank-B. Out of the two banks, one will be active and other one will be inactive at any point of time. The new software will be downloaded into inactive memory bank continuously. After successful software update, the new software can be executed by switching the memory bank. The features of Dual Banking are shown here.

Dual Banking features
Figure 1: Dual Banking features

Background Programming

While the vehicle is running i.e. software is being executed from the active bank, the new software updates can be received by the Telematic Control Unit (TCU) in the vehicle and then downloaded into inactive memory bank of the target ECU. This is called background programming and there is no down-time of the vehicle due to software update. Typically, the software is digitally signed and downloaded to target the ECU to avoid un-authenticated software update. Vehicle diagnostics is also possible during background programming.

Software Update while vehicle is running
Figure 2: Software Update while vehicle is running

Partial Software Download

With the partial software download feature, all the software components of an ECU need not be downloaded during every software update. Only the modified software component can be downloaded individually to reduce overall software update duration and wireless data cost associated with it.

Pause-Resume Cancel

During background programming, the software update can be paused when the ECU/server goes offline and can be resumed or cancelled later when it is up. This helps to reduce overall software update duration and data cost. The paused/cancelled software update will not have any impact on the ECU since the software update is done into inactive memory bank.

Software Commit/Rollback

After successful software update, the updated software will be executed from the downloaded memory bank in the next vehicle startup. The customer can use the updated software for few trial runs and then commit whether he is satisfied with the performance of the updated software. After committing it, the active memory bank becomes inactive and trial run memory bank become active. If the customer is not satisfied with the performance of the updated software, then the customer can choose to rollback to previous version of the software just by switching the memory bank, so that the customer is not impacted by new software update.

Software Synchronization

Once the software update is committed/rolled back or even cancelled, the software from the active bank is copied into inactive bank while the vehicle is running. This is called Software Synchronization and it is useful to keep both memory banks of the ECU with valid software. If the software in the active memory bank is corrupted due to any reason, then the software from the inactive bank can be used. In this case, the active bank becomes inactive and the inactive bank becomes active and the software from the new active memory bank will be executed. This helps to avoid ECU failure and keep the vehicle running.

Software Synchronization
Figure 3: Software Synchronization

Foreground Programming

In service stations, the ECU can be re-programmed through OBD (On Board Diagnostics) to update bootloader for bugfixes, enhancements and new features. This helps to keep the vehicle with better capability for SOTA updates on the road. Also, it is always possible to update application software components through this foreground programming.

Re-locatable Software Support

If the target microcontroller in the ECU supports logical address remapping to physical address, the ECU software can be built using logical address which can be executed from any bank. This helps in faster memory bank switching whenever there is a new software update and thereby eliminating possible vehicle startup delay after new software update.

Software Authentication

The SOTA update is vulnerable for attacks by hacker. To avoid un-authenticated software updates, the ECU software shall be signed digitally using signature algorithms such as ECDSA/RSA/others. During the software update, the ECU will calculate the hash and verify the signature of the downloaded software using public key/certificate stored in the ECU. The downloaded software will be treated as valid if the signature verification succeeds. This secure download of the software helps to avoid programming of un-authenticated software and thereby vehicle downtime.

Conclusion

It is evident that the Dual Banking greatly helps to improve the customer experience with the features explained above. It also helps the manufactures to avoid vehicle recalls reg. software updates and avoid associated costs. Easy maintenance, software updates and enhancement are helping to improve vehicle safety and performance. This results in better customer experience with zero down-time of vehicles for software updates. KPIT’s knowledge on Dual Banking solutions is already in implemented in customer programs.

Related Articles

A car is the most complex software-driven gadget

A car is the most complex software-driven gadget

Becoming the Global No.1 Software Integration Partner – by Kishor Patil KPIT

Becoming the Global No.1 Software Integration Partner – by Kishor Patil KPIT

Your feedback form has been submitted successfully!