Also referred to as Firmware Over-The-Air (FOTA) or simply Over-The-Air (OTA) updates, both terms are used interchangeably throughout this article to mean the same thing. The following topics are covered in this article:

1. What is OTA ?

2. FOTA ECO system for the vehicles

3. What is FOTA packaging

4. How FOTA is applied in Automotive domain

5. Double Banking

6. Multi OTA Architecture in vehicle

7. OTA Security

What is FOTA ?

FOTA is a method to update software, configuration, provisioning, etc., in a device wirelessly. A centralized location (server) can trigger updates to all devices at the same time.

Assume you have a critical bug fix or feature update for your devices, and you have millions of devices deployed in the field and want to update the software on all devices at once. This is where FOTA becomes useful, as it allows you to update all devices without having physical access to them.

Typically, when a software update needs to be performed, you need to bring your device to a specific location and use the required tools to physically connect and update the software. Consider the same scenario in the automotive industry, where millions of vehicles are running on the road. Bringing each vehicle to a repair shop or workshop to update new software involves a huge cost (labor cost) and time.

When FOTA is in place, you do not need to bring the vehicle to a repair shop. Instead, vehicles continue to remain with the owner, but the software is updated seamlessly over the air with the owner’s consent.

FOTA ECO System for the vehicle

OTA solves a bigger problem. Therefore, it comes with a higher setup cost (one-time). It requires the following components to be set up to enable the complete vehicle ecosystem.

1. Reprogramming Center

2. TCU/DCM

3. MNO (Mobile Network Operator)

Reprogramming Center

This is the place where all the software (SW) packages are stored. SW packages are created in a specific format that the device can understand. This is usually done by a company (Tier-1) that produces the software.

The Reprogramming Center is capable of maintaining multiple SW packages for the same device. Moreover, this is a common server that can be used for multiple products. From an automotive OTA point of view, there are well-established players that provide this service. A few examples are Redbend, Innopath, Airbiquity, etc.

In order to communicate with Reprogramming Center, protocols are defined by server which should be followed by TCU/DCM. Some of the well known server protocols are OMADM, UPTANE, LWM2M.

Refer to following pages if you require more details about server protocols.

OMADM:

https://en.wikipedia.org/wiki/OMA_Device_Management

UPTANE:

https://uptane.org/

LWM2M:

https://www.openmobilealliance.org/specifications/lwm2m

TCU/DCM

This is an important ECU in the vehicle that acts as a point of entry. Network connectivity is the key mechanism for any device (in the vehicle context, an ECU) to communicate with the Reprogramming Center.
The TCU/DCM is the primary ECU in the vehicle that has connectivity to the outside world. It is equipped with Wi‑Fi or 4G/5G connectivity, which is used to communicate with the Reprogramming Center. Additionally, the IVI system can also perform OTA updates using Wi‑Fi.

MNO (Mobile Network Operator)

For the TCU/DCM to have network connectivity (4G/5G), there must be a contract established with an MNO to provide connectivity. This service is typically a three-party agreement between the ECU manufacturer (Tier‑1), the OEM (car manufacturer), and the MNO.

FOTA Packaging

Software must be packaged in a format that the device can understand before installation. There
are two types of packaging available:

1. Full Package

2. Delta Package

Full Package

A full package is a standard software update package containing the complete set of images
without compression or reduction techniques. This includes kernel, file system, and configuration
bundled together. The disadvantage is increased size, leading to higher download time and cost

The main disadvantage of this approach is time and cost. Since it packages the full image without any reduction technique, it occupies a large size, which may require more cost (for data usage) and time (to download the package). The delta package is introduced to solve this problem

Delta Package

A delta package contains only the difference between the existing version(base version) and the new version

A delta package is created by finding the difference between the base version and the new version of a particular software image (for easy understanding, assume a Linux patch file; it only captures the differences). As a result, the image size will be very small.

A differential package cannot be created just like a patch file. Instead, it requires special tools that apply mathematical algorithms to generate an efficient and correct delta image. There are open-source tools available to achieve this (e.g., xDelta), and it is also provided by major vendors such as Redbend and Airbiquity.

The main problem with delta packages is maintainability. Assume you have three different software versions, namely A, B, and C. You need to maintain differential (or delta) images between A → B, B → C, and A → C. Refer to the example below. All combinations are required because devices in the field can have any software version.

If you want to update incrementally,

If you want to update directly to desired version

Assume the number of software versions grows over time (e.g., from 10 to 100). This creates a major challenge in maintaining multiple packages. However, delta packaging solves a larger problem, so maintaining multiple software packages is manageable within the Reprogramming Center

FOTA in Automotive Domain

Overall FOTA process in vehicle is illustrated in below picture.

Press enter or click to view image in full size

In simple terms, overall process contains 7 steps

1. FOTA Trigger

2. Software Determination

3. Package Download

4. Verification of the package

5. Update Confirmation

6. Update/Installation

7. Update Notification

FOTA Trigger

FOTA Trigger is the first step to start FOTA. Initially, a FOTA campaign will be created in the Reprogramming Center when new software is available. Once the campaign is created, the trigger can be initiated either via SMS/MQTT, or it can be achieved through periodic scanning (e.g., the ECU periodically checks with the Reprogramming Center).

Typically, urgent updates are triggered from the Reprogramming Center via SMS/MQTT to the target ECU, so that the target ECU can begin the update immediately. Otherwise, the target ECU periodically (e.g., every 1 week) checks with the Reprogramming Center to determine whether any update is available.

Software Determination

Once the FOTA process is triggered, the target ECU tries to determine which software needs to be updated. Typically, the target ECU shares its current software version with the Reprogramming Center, and the center can determine whether the ECU software is outdated and requires an update. Alternatively, the Reprogramming Center can broadcast the newer software version to the target ECU, and the ECU determines whether an update is required or not.

In short, software versions are exchanged between the Reprogramming Center and the target ECU, and the target software version determination is achieved in this step.

Package Download

Once the software version is negotiated, the next step is to download the actual package from the Reprogramming Center. The software package can be full or delta, depending on the FOTA campaign created. Package download happens either via Wi‑Fi or cellular (4G/5G) using the HTTPS protocol. HTTP is suitable for large packages.

If a well‑established player is engaged as the Reprogramming Center, the software required to download the package (also called the download client or download manager) is provided by the vendor (e.g., Redbend or Airbiquity). This download manager will implement the server communication protocols (example OMADM, UPTANE, LWM2M or custom). The Tier‑1 supplier only needs to integrate the download client into the device and provide internet connectivity (Wi‑Fi or cellular). This reduces software integration time.

Verification of the Package

Once the package is downloaded, the integrity of the package needs to be verified at the target ECU. A standard signature verification algorithm can be used to verify the integrity of the package. Before package verification, the package needs to be uncompressed or decrypted.

A separate article will be created to cover FOTA security in detail. Stay tuned for my next blog.

Update Confirmation

Once the package is downloaded and verified, the update can be started. However, before that, user consent (from the driver or owner) must be obtained because the vehicle may not be usable during the update/installation process.

There are some critical updates (e.g., safety-related bug fixes) that may be applied silently without user consent, to avoid the risk of delays in applying important fixes.

Typically, an audio prompt is played through the vehicle speaker when the user stops the car (after ignition OFF), or a prompt is displayed on the vehicle’s main screen. The user can accept or decline the software update by pressing the buttons displayed on the screen.

Update/Installation

Now, everything is set to begin the actual update. Typically, the update happens after the user parks the vehicle (either after ignition OFF or sometime during the night) so that the user will not drive the vehicle.

In the case of FOTA for mobile phones, user operations are entirely blocked to prevent any disturbance during the update. However, vehicle operations cannot be blocked during a FOTA update. That is why off-hours (e.g., ignition OFF or midnight) are chosen to avoid user interference with the FOTA process.

If the software installation is disturbed, the device may not boot up anymore, which may cause bigger problems in the vehicle (e.g., the TCU not booting may lead to the unavailability of emergency calls).

The above-mentioned problem (disturbance during installation) is applicable to any ECU. Since this is a serious issue, an alternative solution is available to prevent this from happening. This is achieved through double banking. Refer to the section below to learn more about double banking.

If the package is a full image, the software can be directly written into memory (NAND/eMMC). If it is a delta package, a dedicated delta update engine should run in the ECU to reconstruct the actual image using the downloaded delta package and the base software available in the device. Open-source engines such as xDelta can be used freely. Again, if a well-established FOTA server is used, the vendor will also provide this update engine.

Update Notification

Once the installation is completed, the update notification needs to be sent to the user and the Reprogramming Center. The update can either be successful or a failure. The actual status is communicated to the center to reflect the real situation. Based on this, the Reprogramming Center decides the next steps.

This summarizes the entire FOTA procedure in the vehicle.

Double Banking

As mentioned in the update/installation section, there is a well-known problem that can cause serious issues. Assuming a critical ECU update is in progress and somehow the software update is disturbed (e.g., low voltage causing a power loss), this can lead to the software in the ECU becoming corrupted, and the ECU may no longer boot. Eventually, FOTA may cause a bigger problem than its original intent. This can be solved by using the double banking method.

Press enter or click to view image in full size

Refer to the simple representation of double banking above. Basically, two partitions (or banks) are available for each image (e.g., Linux kernel). One is the active bank in which the current software is running, and the other is the inactive bank, which serves as a backup.

When a software update/installation happens, it is always performed on the inactive bank without disturbing the active bank. This ensures that any disturbance during the update does not impact the active bank in which the software is currently running.

Once the installation is successfully completed, a bank swap from inactive to active takes place. This means the current active bank becomes the inactive bank (for the next update), and the current inactive bank becomes the active bank.

If the installation fails for any reason, only the inactive bank is affected. A rollback mechanism is triggered to recover the inactive bank content by copying data from the active bank.

This approach completely solves the problem but comes with an additional memory requirement. For example, if the entire partition content is 200 MB, then an additional 200 MB (for the inactive bank) needs to be allocated in memory (NAND or eMMC).

Multi OTA Architecture

A separate article will be created to cover this. I will place the link once it is available.

FOTA Security

A separate article will be created to cover FOTA security in detail. Stay tuned for my next blog.

Conclusion

FOTA enables efficient and scalable software updates in modern vehicles. While it introduces
challenges such as maintainability and reliability, techniques like delta updates and double banking
address these issues. As vehicles become more software-driven, FOTA systems will continue to
play a critical role.

I hope you have gained good insight into FOTA. Please feel free to comment if you need further clarification

Originally published at http://mohduvaisc65a59c72d.wordpress.com on June 18, 2026.