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.
Figure 1: Dual Banking features
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.
Figure 2: Software Update while vehicle is running
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.
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.
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.
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.
Figure 3: Software Synchronization
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.
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.
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.
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.
Sr. Solution Architect
Connect with us
KPIT Technologies is a global partner to the automotive and Mobility ecosystem for making software-defined vehicles a reality. It is a leading independent software development and integration partner helping mobility leapfrog towards a clean, smart, and safe future. With 10000+ automobelievers across the globe specializing in embedded software, AI, and digital solutions, KPIT accelerates its clients’ implementation of next-generation technologies for the future mobility roadmap. With engineering centers in Europe, the USA, Japan, China, Thailand, and India, KPIT works with leaders in automotive and Mobility and is present where the ecosystem is transforming.
Rajiv Gandhi Infotech Park,
Hinjawadi, Pune – 411057
Phone: +91 20 6770 6000
Frankfurter Ring 105b,80807
Phone: +49 89 3229 9660
Fax: +49 89 3229 9669 99
KPIT and KPIT logo are registered trademarks | © Copyright KPIT for 2018-2021
|cookielawinfo-checbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|