Consider the example of an electronic control unit (ECU) using traditional static embedded software. Bootloader is a software component used both to initiate the boot up of the ECU main software, including copying the software into RAM, and to perform any checks on the software before boot-up. The bootloader is also responsible for software update, receiving, checking and writing the updated software into memory, usually Flash memory. Hence, the term Flash Bootloader is also commonly used.
Are the same bootloaders used in development and production?
Commonly the same bootloader may be used in development of vehicles and the associated ECUs and in normal production, with protections to ensure that production ECUs have many capabilities of development or engineering bootloaders deactivated. During vehicle development it is often desirable to remove security mechanisms of production bootloaders to enable rapid deployment of development software.
Secure bootloader
Increasingly all bootloaders are required to be secure. However, traditionally this has been a distinction, usually implemented to protect functionality concerned with security, safety and sometimes performance.
Bootloaders commonly check the software memory of the ECU at bootup and received software prior to a software update and in memory after.
Mechanisms commonly include:
- Authentication of the software received and/or present in memory at boot time, often using a hash of the software binary to check correctness generated from a secure compilation process of officially released software versions.
- Authentication of the sender using a seed and key, protections of secure data within the ECU using secured memory and memory maps to define accessible/rewriteable areas.
Dual bootloader
Some implementations of bootloaders are in two parts, hence the term dual bootloader. In this case, the primary bootloader is non-updateable, as part of securing the bootloader. This is concerned with booting up of the module and update of the secondary bootloader. The secondary bootloader can be updated, via a secured process, enabling modifications to the software update process, for example, memory map, allowing these to normally be locked. This type of bootloader is less common now due to new methods of securing the update process using onboard secure hardware, for example, HSM (Hardware Secure Module).
Note, this term is like dual boot, where two-boot blocks, or full memories are available, allowing an update to take place on the unused version whilst one version is active. This requires extra memory in each ECU supporting this method of update.
Capital Embedded Bootloader
Capital Embedded Bootloader supports reliable ECU updates during development, in vehicle production, and during the life of the vehicle, via connected diagnostics tools or over-the-air methodologies. The standardized ISO 14229 UDS protocol is used over a range of common vehicle network buses, Ethernet, CAN/CAN-FD, LIN, FlexRay, and it is also possible to use other methods such as the ASAM calibration protocols. Cybersecurity is a key aspect of the software update flow and features enabling software authentication, and secure boot options are part of the solution. To satisfy OEM (original equipment manufacturers) and MCU specific requirements, wide support is available for a broad range of ECU projects.
What is the difference between OTA and FOTA?
OTA (over the air) update, or FOTA (firmware over the air), is a method to achieve the reception of new software for an embedded device, for example, automotive ECU, in a remote fashion, not via directly connected service tool in a workshop. This may require some onboard diagnostic tester capability in a coordinating ECU and/or recovery and self-test abilities in the bootloader itself.