For our readers who would like to get introduced to the concept of Flash Bootloaders in Automotive, we would recommend you to read this blog- Understanding what is a Flash Bootloader and the Nuances of an Automotive ECU Reprogramming
When Automotive Electronics was in its nascent stage, software engineers had not fully utilized the capabilities of a Flash Bootloader software.
The Embedded Software Engineers, during Automotive Product Development, were more focused on the features and functions of the software.
The need for firmware or application update was not mission-critical, due to not-so-complex features and systems.
Fast-forward to the era of Connected Cars, Infotainment, ADAS and Telematics applications, and the need for frequent software updates can’t be understated. And who empowers these software updates? It is your modest Flash Bootloader Software!
The complexity of the automotive applications has also meant that one type of Flash Bootloader solution is not the best fit for all the business use-cases.
Chances of memory corruption and security threats has paved the way for development of flash bootloader solutions that differ based on their technology architecture, security measures and connectivity features.
Before we discuss these special types of flash Bootloader, let’s first establish their need in the context of changing automotive electronics landscape. Every scenario will be followed up by the type of Bootloader, which is designed to mitigate the mentioned challenge.
Why Use Different Types of Bootloaders? The Scenarios and the Solutions
Reprogramming of the Control Units Software can get tricky at times.
The software image (file that contains the updated version) may be large in size, or there may be a chance of flash drive corrupting the memory. There is also a possibility that the communication channel may not be secure enough, to support the re-programming.
We will shed lights on all these scenarios and issues that required flash bootloaders to be developed specifically to address them. Let’s find out one scenario at a time!
Scenario 1: An Instance of Memory Corruption by the Flash Driver
The Flash Bootloader comprises of several device drivers and software modules for flashing the Automotive Control Unit. One of them is flash driver.
These drivers act as a liaison between the memory location and the external tool for ECU flashing.
Due to certain malfunctions, the flash drivers can corrupt the memory locations of the Flash Bootloader.
If such a scenario arises, the automotive control unit may not accept the updates or run into other troubles. After all, the Bootloader is the first module to run, when ignition is turned on.
One of the major reasons to consider this scenario while designing the Flash Bootloader is the need for compliance with ISO 26262 Standard for functional safety.
In order to comply with ASIL B and above, your automotive ECU Bootloader should be designed in a way that the issue of memory corruption is completely mitigated.
Solution: A Bootloader with External Flash Driver
The solution for this issue is to ensure that your Flash Bootloader design doesn’t have an integrated Flash driver.
Instead, the flash driver is loaded inside the Flash Bootloader, only when the ECU reprogramming command is sent by the external flashing tool.
- Request for re-programming comes from the external ECU flashing tool
- Flash driver (A small binary file) from the external tool gets downloaded to the Bootloader’s RAM
- Read and Write function is performed by the Bootloader to flash the ECU
- After the re-programming is completed, the flash driver is deleted from the RAM of the Bootloader
In terms of ASIL compliance, this type of Bootloader can be seen as a safety mechanism put in place to avoid the hazards of memory corruption and the risks associated with it.
Interestingly, such mechanism does not lead to any substantial increase in the cost of the Bootloader.
Also, there isn’t any substantial increase in the Bootloader development time.
However, the factor that needs to be considered here is the compatibility of the microcontroller platform with the external flash driver. If certain Microcontroller does not support the flash driver, then your team may need to write some additional drivers.
The ECU flashing time, on the other hand, is rather improved. This is because the code that is usually executed from the flash memory (in a standard Bootloader), is now being triggered by the RAM, which is faster.
Scenario 2: Security Threats in ECU Reprogramming
The external ECU flashing tool communicates with the Bootloader over CAN bus. Hence, it is highly likely that the communication can be hacked and the entire ECU be re-produced.
Some more serious security threats can be:
- Alteration of the firmware image that is being updated
- Reverse engineering of the firmware
- Loading of the unauthorized firmware version in the ECU
Not only the vehicle can malfunction due to this, but serious implications can follow and the reputation of the OEM may get adversely affected.
One of the most feasible way of mitigating such risk is to deploy security checks before the software update file is sent to the Bootloader.
Such safety mechanisms also help in making a Bootloader comply with ISO 26262 mandated Automotive Safety and Integrity Level (ASIL).
Solution: Encryption-Decryption Enabled Bootloader
Here, the idea is to encrypt the software update file before transmitting to the Bootloader via CAN. The encryption will be performed by the ECU flashing tool.
Once the Bootloader receives the encrypted file, the decryption algorithm will kick in. Post the decryption, the regular sequence of ECU flashing will be performed.
These bootloaders are based on Cryptographic algorithms. They serve the dual purpose of protecting the privacy of the firmware update file and verifying the code integrity.
-
- Encryption-Decryption Algorithm: The encryption algorithm resides in the flashing tool and the decryption algorithm sits in the Bootloader Application. This algorithm may be symmetric or asymmetric, depending on the level of security required.
Symmetric algorithm deploys the same key for both encrypting and decrypting the message, while asymmetric algorithm uses public and private keys. In both cases, these algorithms are quite robust and tough to hack.
- Protocol-level Security Measures: Security threats such as firmware alteration (downgrading), encryption key alteration, upgrade interruption etc. are not handled by the encrypt-decryption algorithms. Protocol-level measures are required to handle them efficiently.To ensure the correct and complete packet has been received by the Bootloader, packet fields are checked at the protocol-level and matched with the packet received by the Bootloader.If there is any discrepancy, the packet is not accepted and connection is aborted.
Scenario 3: Flash Bootloader Application Update
So far in the blog, we have discussed only about the ECU application update using the Bootloader. However, the Bootloader application may itself require some software update time to time.
There may be a bug-fixes in the new release of the Bootloader Software or new features may have to be added. The Bootloader software block is tasked with the upgrade of the application block only and there is no provision for it to upgrade itself.
To enable such updates, we need Flash Bootloaders with a defined functionality that can update the Bootloader Application.
Solution: Bootloaders with Primary and Secondary Blocks
These specialized Bootloader solutions have a separate block for the purpose called the secondary block. The role of secondary Bootloader is limited to updating the Bootloader application.
Bootloader with Secondary Block
Following is the sequence of Flash Bootloader Application update:
- The external Flash Tool for the ECU (Electronic Control Unit) sends an update command to the Bootloader; Primary Bootloader receives it
- If the update is for the Bootloader application, the control is shifted to Secondary Bootloader
- The Secondary Bootloader erases the primary Bootloader and writes the new firmware package
- New application is verified and control is again shifted to the Primary Bootloader
Scenario 4: Remote Firmware Upgrade
There are more than several hundreds of ECU applications, which run inside the vehicle. Imagine taking the vehicle to the service station for updating all such applications. It will be a nightmare for the customers and even for the OEMs.
They will need to increase the number of service stations and also add more people to their workforce. So what’s the solution?
Solution: Bootloader with Firmware Over-The-Air Update (FOTA)
A Bootloader with the capability to receive firmware over the Ethernet. Such bootloaders are equipped with a FOTA module that receives, verifies and execute the update over the air.
Scenario 5: Automotive ECU Application Gets Corrupted
At ignition, the Bootloader checks the integrity of the control unit application using the Check-sum calculation and other methods.
If any discrepancy is found, the application is not run and the process is aborted. For critical applications such as Electronic Stability Program or ABS, failure of application execution can cause serious malfunctions.
A smart Bootloader can help to mitigate such critical issues. Let’s see how.
Solution: Bootloader with a Golden Image (Clone Image)
There is a golden or clone image of the application stored in the Bootloader, as an auxiliary application block.
And Finally, the Standard Bootloader!
When such scenarios need not be taken into picture, our good old Flash Bootloader fits the bill easily. This standard Bootloader consists of the Bootloader Block and the Application Block.
Upon each ignition, the control will shift to the Flash Bootloader block and it will check for an update. If no update is found, the control will move to the application block.
If the update package is available, the Flash Bootloader will erase the application block, read and write the new software package and verify the application. If everything is good, the control will shift to application block.
Conclusion
Apart from these Flash Bootloader types, other variants may also be developed. Technology architecture of two variants can also be combined to create a third variant. For instance, a flash Bootloader software may have both encryption-decryption capabilities and FOTA capabilities. Likewise, Flash Bootloaders with other hybrid architectures can also be designed, depending on your business use-case.
