Unlike the cars of yesteryear, software-defined vehicles have introduced the age of ECU consolidation.
The number of ECUs in vehicles is shrinking; the vehicle architecture is transitioning from Domain to Zonal E/E Architecture.
A major driver behind the collective confidence in this transition is automotive over-the-air (OTA) updates and an OEMs ability to manage its delivery.
Without automotive OTA updates, the Zonal Control Units & Central Computing Devices in SDV architecture would be complex nodes, with limited lifecycle revenue potential & remote diagnostics capability.
Through this article, we deep-dive into the finer details of automotive OTA update management.
What are Automotive Over-The-Air (OTA) Updates?
Wireless firmware or software update delivered to the vehicle through cellular or Wi-Fi networks is known as automotive OTA updates.
The mechanisms through which OEMs deliver these updates to the telematics gateway unit / central computing device is known as OTA update orchestration.
There are three types of OTA updates in automotives:
- Firmware Over-The-Air (FOTA) Updates
- Software Over-The-Air (SOTA) Updates
- Configuration Over-The-Air (COTA) Updates
| FOTA | SOTA | COTA |
|---|---|---|
| FOTA is nothing but a remote software-management technology for embedded systems, which facilitates wireless firmware upgrade on a device. | SOTA is the wireless update of the application-layer software running on a higher-level compute platform. | COTA updates refer to the wireless updates of the configuration parameters of zonal ECUs. These updates are lightweight when compared to FOTA or SOTA updates. |
| FOTA upgrade involves firmware bug fixes, improving the automotive ECU’s functionality, and replacing older firmware version with an updated version (for either fixing an issue or to add a new software feature). | SOTA updates are delivered to in-vehicle Infotainment, IVI maps, ADAS perception models, telematics apps, Linux/Android/QNX containers. | COTA updates include configuration of country specific settings such as ambient lighting rules, UI layout and more. |
| Failed updates have strong functional safety implications. | SOTA updates are often hot-deployable – i.e., the system can be updated live, while its running. This makes SOTA updates less safety critical. | COTA updates are not risk-free by default. Configuration parameters touching ADAS thresholds, powertrain calibration, or regional compliance settings can affect type-approval-relevant vehicle behaviour. This makes them subject to UN R156 impact assessment regardless of their update size. |
Breaking Down Automotive OTA Update Management
As the automotive industry transitions, most cars still utilise 100+ ECUs. This makes modern vehicle a complex, multi-ECU system. The number of ECUs is expected to reduce to fewer than 10 high-performance nodes by 2030.
So:
- What changes in the way ECUs work in software-defined vehicles?
- How are automotive FOTA, SOTA, COTA updates delivered and managed?
- A car is made of ECUs from multiple vendors, how do OEMs manage their OTA updates?
Find out in the upcoming sections:
The Evolved Role of ECUs in SDVs
Engine Control Units (ECUs) in SDVs act as smart localized nodes. They function as:
- Sensor data collectors — gathering raw inputs from the physical environment around them and sending it to the zonal controller or central computing device.
- Local actuator controllers — directly controlling hardware like door locks, lights, and braking modules
- Compute off-loaders — passing complex processing workloads up to a small number of powerful Central Compute Units.
In zonal or centralized architecture, edge ECUs handle localized sensing and actuation at the bottom, zone controllers aggregate and route in the middle, and the Central Compute Unit makes cross-domain decisions at the top.
Factory Flash to Over-the-Air Updates: How a Vehicle Enters the OTA Ecosystem
Before a vehicle leaves the factory, it goes through an End of Line (EOL) programming station.
This is where the vehicle’s identity and software baseline are established. The TCU receives its initial firmware flash. Then,
- Vehicle Identification Number (VIN) is mapped to the TCU’s unique device identity in the OTA backend
- OTA subscription and connectivity plans are provisioned
- Cloud connectivity check confirms the TCU can reach the OTA server
This EOL flash is the vehicle’s first and only wired update; every update after this point happens over-the-air.
Once the vehicle reaches the end customer, it becomes a live node on the OTA network.
The OTA backend knows its VIN, its software versions across every ECU, and its connectivity status.
The vehicle is now remotely manageable for the rest of its operational life.
How Automotive OTA Updates Are Orchestrated Across Multiple ECUs
Multi-ECU OTA update orchestration is the coordinated update of several ECUs in one vehicle, treated as a single transaction.
The key touchpoints essential to orchestrate OTA updates are:
- OTA Update Gateway Device & Device side OTA components
- Cloud-native OTA Backend
- OEM OTA Dashboard
An OTA Orchestrator in the vehicle receives a campaign from the cloud.
The campaign will describe N components with target versions, dependencies, sequence and pre/post-conditions.
It then:
- Authenticates and verifies the campaign (signature, certificate chain).
- Pre-validates vehicle state (HW PN, SW PN, current versions, fuel/SoC, ignition) and manages user consent.
- Cache firmware bundles on persistent storage.
- Downloads bundles (often resumable, deltas).
- Sequences flashing across ECUs over CAN/CAN-FD/Ethernet using UDS (ISO 14229) + ISO 14229-5 (UDSonIP) or DoIP (ISO 13400).
- Post-validates each ECU (version read, CRC, self-test).
- Performs rollback if any step fails, then publishes per-component and campaign-level status to the cloud.
The OTA update orchestrator is the only entity that talks to the cloud; all other ECUs are slaves driven via UDS diagnostic services such as:
| Code | Function | Responsibility during OTA |
|---|---|---|
| 0x10 | Diagnostic session control | Open programming session |
| 0x27 | Security access | Authenticate |
| 0x34 | Request download | Declare incoming OTA firmware |
| 0x36 | Transfer data | Transfer firmware data blocks |
| 0x37 | Request transfer exit | Close transfer |
| 0x31 | Routine control | Verify checksum & Activate firmware |
What’s inside an Automotive OTA Update Orchestrator?
OTA Update orchestrators are gateway devices that handle the planning, coordination and control the software update process in a secure manner.
These devices contain the primary software and hardware partitions that handle automotive OTA update mechanisms.
In vehicles built on domain architecture, telematics control units (TCUs) were the go-to gateway devices.
With the industry transitioning towards zonal and central compute devices, the role of TCU has progressively reduced to just the connectivity gateway.
In this scenario, the role of OTA update orchestration moves onto the central high-performance computer (HPC).
For this blog, let’s consider the TCU as the orchestrator of automotive OTA updates. It consists of the following partitions; each assigned a specific OTA role and set of responsibilities.
| Partition | Role in OTA | Responsibility |
|---|---|---|
| Modem | OTA Client – Cloud facing partition | · Manages cellular connection (4G/5G).
· Maintains secure channel to OTA backend. Authenticates with server. · Receives incoming update packages |
| Vehicle Interface Controller | OTA Master – Vehicle facing partition | · VIC receives updates packages from the modem.
· If available, the VIC updates the TCU firmware. · Drives all downstream ECU updates by using UDS diagnostic services. |
Automotive OTA Updates in Domain & Zonal Architecture: The Difference
The vehicle E/E architecture can determine OTA update complexity.
From the table below, understand how the shift in EE architecture – from domain to zonal impacts automotive OTA management.
| Domain-based Architecture | Zonal Architecture | |
|---|---|---|
| Components | Functional ECUs for Powertrain, body, Infotainment – each with a domain controller | Zonal Controllers based on physical position (front-left, rear-right, etc) connected to a central high-performance computer (HPC) |
| OTA Master | One per domain or central gateway | Central HPC – One state machine, rollback manager and source of truth for OTA campaign management |
| Comm. Network | CAN/CAN-FD per domain with Ethernet backbone | Automotive Ethernet enables direct device addressing, gigabit transfer speeds, and native DoIP support. This eliminates the frame-by-frame CAN transfer problem entirely. |
| Sequencing | OTA master orchestrates its own ECUs | HPC orchestrates OTA, zonal controllers are responsible for protocol translation |
| OTA Challenges | Managing many isolated trust boundaries, keys & certificates | Bandwidth concentrated on HPC |
| Trend | Phasing out | The go-to SDV standard |
Most vehicles on the road today, and a significant portion of vehicles in production are still domain architectures.
The shift to zonal is happening but it is a 5–10-year transition across the industry.
An OTA platform that only works cleanly on zonal architectures, is not deployable across most vehicles in the field today.
So, OEMs SUMS must handle both – OTA for zonal and domain architecture.
Multi-Supplier ECU Management: How OEMs Standardise and Scale OTA Updates
A common scenario OEMs face is updating multiple domain ECUs supplied by different tier-1 vendors under one coordinated campaign.
How do OEMs position themselves to deliver OTA updates to ECUs made by multiple suppliers?
- Common Diagnostic Abstraction – OEMs either follow the Herstellerinitative Software (HIS) flash specification or build a custom one on top of it. This rulebook consists of information the UDS services that ECU must support, opening doors to standardized interface for OTA update delivery.
- Signed OTA Release – Tier-1s deliver firmware as cryptographically signed binaries – private keys. The OEM adds the signed binary to the OTA campaign and signs it with its own private key. The ECU before initiating the flash verifies the both tier-1 and OEM private keys.
- (ODX) and Packaged Diagnostic exchange (PDX) – ODX is an XML-based ASAM standard under ISO 22901. PDX is the compressed ZIP archive of multiple ODX files. The ODX file is a complete documentation on how to interact and reprogram an ECU. Without this file, the OTA orchestrator will need custom integration codes for every single ECU.
- Hardware-in-Loop (HIL) Qualification – Before launching the OTA campaign, the OEM qualifies the update bundle by performing HIL regression testing. Using this, they validate update sequences, inter-ECU dependencies, rollback behaviour and more.
- Hardware and Software Compatibility Mapping – The OEM maintains a compatibility database in a PLM or Software Fleet Management (SWFM) tool. This helps map every valid Hardware Part Number (HW PN) to Software Part Number (SW PN) combination per vehicle variant. Before targeting a VIN, the campaign system queries this database and automatically excludes incompatible vehicles.
- OTA Readiness as a Contractual Obligation – OEMs mandate OTA readiness contractually. Every Tier-1 ECU must support: a ; resume-after-power-loss so interrupted flashing continues from the last confirmed block; dual-bank memory preserving existing firmware while new firmware is written; a defined flash time window; and diagnostic version read support for post-flash version confirmation.
- The OTA Update Management Platform – The OTA backend aggregates Tier-1 firmware deliveries, computes campaigns per VIN, manages staged rollout scheduling, and tracks per-ECU outcomes fleet-wide. OEMs either build this in-house or deploy an established platform.
Best Practices to Sequence Automotive OTA Updates
OTA update sequencing enables OEMs to reduce update risks and coordinate multi-ECU campaigns.
Here are some of the best practices to deliver an automotive OTA update:
- Map ECU-to-ECU dependencies as one ECU may depend on data, diagnostics or security behaviour of another ECU.
- Check the software/firmware version, digital signatures, power & ignition state and compatibility as updating non-ready ECUs can brick the vehicle.
- Update more isolated ECUs first. Updating central or zonal nodes first can affect vehicle communication paths and amplify failure, if any.
- Update two ECUs that rely on each other’ signals or interfaces in a single window as it is unsafe for the vehicle to operate with mismatched software contracts between communicating ECUs.
- Perform a clean restart at the end of downloading the OTA update as repeated reboots can lead to partial activation or problematic recovery of the update.
- Validate if each ECU is flashed correctly and is in ready to operate state.
- Employ Rollback Mechanism, Dual Banking, A/B Partitioning as safety nets.
- By default, only start the update installation when the vehicle is parked, ignition off vehicle battery conditions to avoid voltage drops that could interrupt OTA update flashing.
OTA Update Campaign Management Platforms – The Cloud-based OTA Backend
The OTA campaign platform i.e., the OEM OTA dashboard is the visible layer of a software update management solution.
This interface is where OEM engineering teams, fleet managers and program managers interact with the system and orchestrate OTA update rollout.
Embitel’s OTA firmware update accelerator consists of the cloud-side OTA backend stack and an OTA dashboard. Using this, OEMs can quickly develop a custom software update management system.
The OEM OTA dashboard enables real-time visibility to track & enable the following:
| Parameter | Details |
|---|---|
| OTA Targeting | Define the vehicles that receive the update. Select VINs based on vehicle model, variant, region, hardware part number, current software version, or any combination of these. |
| OTA Package Preparation | Assemble the update bundle. Enables OEMs to take update binaries from tier-1s and bundles them into a signed OTA package. These packages can contain both, full or delta updates. |
| Update Rollout Progress | Track overall percentage of target fleet updated, in-progress, pending or failed. |
| Update Timeline | Planned vs Actual rollout implementation |
| Update Failure rates | Alerts the user if the failure rate cross threshold |
| Consent Management | Handle user notifications and consent workflows |
| Comparative Analytics | Analyse update parameters across campaigns to spot recurring failure patterns. Compare OTA campaign outcomes per-VIN & per-ECU. |
| Staged Deployment | Manually promote a campaign from canary group to full fleet once success metrics are met |
| Pause & Halt updates | Stop campaign mid-rollout if any signs of failure appear |
| Rollback Initiation | Trigger fleet-wide or segment wide rollback to last good state |
| OTA scheduling | Set OTA update windows around vehicle usage patterns |
| Audit Logs | Extract logs on campaign approver, date of flashing and rollout batch |
| Role-based Access Management | Engineering, quality and program management teams access relevant modules with needing backed access |
Delta OTA Compression for Automotives: Sending Less, Updating More
Delta OTA updates come into the picture when OEMs need to update only a part of the existing firmware image of an ECU.
This concept allows OEMs to ship only the difference between the old firmware and the new firmware, instead of the full image.
By delivering delta OTA updates, OEMs prevent the unnecessary transmission of a ginormous amount of unchanged code.
This in turn, saves the cost associated with cellular data transmission and reduces the bandwidth required for an update window.
Here are some of the algorithms used to create delta patch files:
For MCU-based ECUs (Powertrain, Body Control, Gateway)
Algorithms such as bsdiff/bspatch take up large RAM bandwidth and processing headroom. It holds both – the old firmware & new firmware file in the RAM simultaneously to generate the patch.
Vendor proprietary delta engines such as Harman’s RED BAND, Aurora Labs, Excelforce and open-source algorithms like xdelta3.
For Linux & Android based Systems (IVI, Digital Cockpit, Central Compute)
Higher-compute platforms running embedded Linux or Android Automotive OS use a different class of tools entirely.
Frameworks like RAUC, SWUpdate, and OSTree handle delta updates at the operating system level. Their functions include:
- pushing a patch,
- partition switching integrity checks,
- automatic rollback if something goes wrong
Safeguarding Automotive OTA Updates: UN R156
OEMs that deliver in automotives in United Kingdom (UK), Europe (EU), South Korea, Japan, and Australia must certify their organizational processes that govern how OTA updates are planned, deployed and recorded.
The United Nations Regulatory Mandate that governs these processes is UNECE WP.29 R156.
OEMs must ensure that automotive OTA updates delivered do not change any type-approval relevant vehicle behaviour. Every updated must be logged and be accessible to regulators on demand.
Type approval relevant vehicle behaviour includes:
- Environmental Impact Parameters: Emissions, Energy Consumption & Noise
- Safety Parameters: Braking behaviour, Electronic Stability Control, Structural Readiness for Crashes and Pedestrian Protection
- Software & Electronic Parameters: Electromagnetic Compatibility (EMC), ADAS, Cybersecurity & Software Updates
- Visibility & Lighting: Headlight behaviour & Field of view.
Other major markets for the automotive industry such as United States, China, and India. OEMs in these markets must comply with the respective country’s type-approval requirements.
| Countries | Alternatives to UN R156 |
|---|---|
| US | OEMs operating in the US follow R156 for their EU vehicles and apply similar practices domestically; but it is not legally required. |
| China | GB 44496-2024 – Unlike UNECE, do not mention CSMS and SUMS certificates. China also requires update records to be stored for at least 10 years after a vehicle type is discontinued. |
| India | AIS-189 & AIS-190 – AIS framework outlines SUMS requirements for vehicular systems, drafted and adopted from UN R155/R156, and will be released in 2027. |
Artificial Intelligence (AI) in Automotive OTA Update Management
The boom in AI supported technologies has enabled a series of smart functionalities to manage automotive OTA updates, such as:
- Automated decision making for staged OTA rollouts.
- Detect post-update anomalies to catch silent regressions.
- Delta optimization of firmware images.
- Group failed OTA update installations by signature so engineering teams can resolve the common issue.
- Predict the right time to rollout OTA updates based on driving patterns.
- Generate release notes, and changelog summery for owners.
Machine learning can analyse, recommend, and monitor — but under UN R156, the release decision and the type approval impact assessment must be reviewed and signed by a named human.
Accountability cannot be delegated to an algorithm.
The Window to Build Your OTA Architecture Is Closing: Here Is Why It Matters Now
The technical complexity in setting up and delivering OTA updates is real.
Multi-ECU orchestration across domain and zonal architecture, delta update management at scale, Uptane-compliance, R156 audit trials & multi-tier-1 supplier coordination – each OEM has a different requirement for the above.
Executing these OTA requirements requires an architecture that was designed specifically keeping OEM specifications in mind.
OEMs & Tier-1s that move early on this will hold a structural advantage. Not just with compliance & control on data but in their ability to:
- Monetise the vehicle post-sale
- Respond to field issues faster
- Extend relationship with the customer well beyond the point of purchase
Embitel’s Role in Automotive OTA Update Management
At Embitel, we accelerate the end-to-end development of Automotive OTA Update Management systems.
Our engineering team has delivered a variety of custom OTA solutions, such as:
- Bootloader development
- ECU Firmware
- Vehicle-side components for OTA update orchestration
- Cloud campaign management platforms (OTA Backend)
- Multi-tenant fleet platforms
Here’s an example of a custom OTA update management solution we developed for a leading two-wheeler OEM.
If your OTA programme is still in planning, now is the right time to get the architecture right.
If it is already in development and hitting walls, we have overcome most of them before.
Talk to our team and get a headstart in developing a custom, scalable and compliant automotive OTA software update management solution.
