Vehicle OTA updates move signed software packages from a backend campaign system, over a secure channel, to an in-vehicle orchestrator that flashes individual ECUs under strict preconditions. UNECE R156 requires manufacturers to operate a certified Software Update Management System: identify type-approval-relevant software, assess each update's safety and approval impact, and inform users.
Key takeaways
- SOTA replaces application software; FOTA rewrites ECU firmware, and FOTA is the hard one.
- The real problem is the vehicle-wide software baseline, not the transfer.
- R156 requires a certified process (SUMS), RXSWIN identification, impact assessment, user information.
- Validate baseline-to-baseline transitions, not individual ECU flashes.
What is the difference between SOTA and FOTA, and why is FOTA the hard one?
SOTA updates application-layer software on a capable compute node — infotainment apps, navigation data, configuration. FOTA rewrites firmware on an embedded ECU, including code that drives actuators. SOTA is forgiving; FOTA is not.
- Memory. A body ECU may hold a few hundred kilobytes of flash, with no room for a second image.
- Mechanics. UDS reprogramming — session, erase, transfer, verify, reset — leaves no valid application if interrupted mid-erase, and CAN flashing is slow.
- Recovery. If the bootloader survives you retry. If not, the vehicle goes to a dealer, which at scale is recall-shaped.
Flash budget and power-fail robustness cannot be retrofitted over the air, so FOTA is a sourcing decision.
How does the OTA update chain work?
Four stages: backend, transport, orchestrator, ECU. Each must know what the next can accept, or a package that is valid in the backend fails in the field.
- Campaign management. The backend models the fleet — hardware, installed versions, eligible target baselines — and builds targeting rules, rollout rings and halt criteria. That model must be accurate, and dealer flashes and replacement parts change vehicles silently.
- Secure transport. Packages are signed at the source and verified in the vehicle, not just sent over an encrypted channel. You also need defenses against version rollback and mix-and-match attacks that deliver valid images in an invalid combination — an OTA backend is cybersecurity infrastructure.
- In-vehicle orchestrator. One node, a compute unit or central gateway, verifies the package, checks preconditions, sequences targets and reports status. In AUTOSAR Adaptive this is the Update and Configuration Management role.
- Per-ECU flashing. Targets are flashed over UDS via DoIP or CAN. Ordering is the hard part: some ECUs must go first because of interface changes, and some pairs must never sit mismatched. The vehicle enforces that graph locally.
How do A/B partitioning and rollback work?
A/B partitioning gives an ECU two firmware banks. The new image goes to the inactive bank while the active one keeps running; a reboot switches the pointer, and a failed boot flips it back.
The cost is double the flash, so A/B is common on compute nodes and rare on cheap microcontrollers. Single-bank flashing means longer downtime and an unrecoverable power-loss window. Rollback is not free at vehicle level: reverting one ECU can produce a combination nobody validated.
What preconditions and safe-state requirements apply?
An update must not start, or continue, in a state where failure is dangerous.
- Stationary, in park, parking brake applied; immobilized for higher-risk updates.
- Energy above a threshold covering worst-case flash duration plus margin.
- Explicit driver consent: what changes, how long, what is unavailable meanwhile.
- Defined behavior for interruption — driver returns, power drops, connection fails.
R156's intent is direct: updates must execute safely, users must be informed, and if driving during an update would be unsafe, the vehicle must not be drivable.
Why is the software baseline the real engineering problem?
Delivering bytes is solved. Knowing which ECU software versions sit in a vehicle, and whether that combination was ever validated, is not.
Multiply hundreds of ECUs by model years, variants and service actions and the permutations are unmanageable. A vehicle built on baseline 3.1 may now be 3.1 plus an ECU on 2.8 from a warranty part. Refuse the combinatorics.
- Define a small set of approved vehicle-wide baselines — a validated version vector across the ECU set, not independent component releases.
- Permit only baseline-to-baseline transitions.
- Make configuration identity readable from the vehicle on demand.
- Force convergence: every campaign should cut the number of distinct baselines in the field.
That discipline is what keeps a software-defined vehicle maintainable.
What does UNECE R156 require?
R156 governs approval of vehicles with regard to software updates. Its requirement is process, not product: the manufacturer must have a Software Update Management System certified by an approval authority and applied to the type being approved. It must:
- Record hardware and software configurations and identify which software is type-approval relevant.
- Declare a software identifier (RXSWIN) for it, readable from the vehicle and protected against modification.
- Assess before release whether an update affects a type approval, changes functionality, or affects safety, and address the approval before deploying one that does.
- Execute updates safely: integrity and authenticity protection, precondition checks, a defined failure response, and traceability including supplier interfaces.
- Inform users of purpose, functional changes, duration, required actions and outcome.
R156 applies through the UNECE 1958 Agreement; the EU made it mandatory for new vehicle types first, then all new registrations. The United States regulates differently, so global programs generally build to UNECE requirements.
How RXSWIN ties software to the approval
The Regulation X Software Identification Number is what binds the regulated software in a vehicle back to the approval that covers it. If an update changes covered software, the manufacturer either keeps the identifier valid because the change sits within approved scope, or updates it and handles the consequence.
How does R155 relate?
R155 is the security counterpart, requiring a certified Cyber Security Management System covering risk and threat management across the lifecycle; ISO/SAE 21434 is the standard most manufacturers use to demonstrate one. R156 assumes R155: the guarantees that make an update trustworthy come from the security process.
How do you validate an update across the fleet's software permutations?
Validate transitions between approved baselines, keep the baseline count small enough to test, and scope against real installed configurations, not build records.
- Cover permutations virtually. Virtual ECUs and SIL exercise version combinations and interruption scenarios in parallel.
- Prove the flash on silicon. Bench racks and HIL validate timing, bus load and bootloader behavior under power loss.
- Test failure deliberately. Cut power during erase, drop the connection, roll back, confirm a drivable end state. An untested rollback path is not one.
- Stage the rollout. Canary cohort, then widening rings with halt criteria and someone authorized to stop.
AUTOSAR Classic and Adaptive targets flash differently and need separate coverage.
Which update types carry which risk?
Grade updates by consequence, or heavyweight process makes routine ones uneconomic.
| Update type | Risk if it fails | Downtime | Validation burden |
|---|---|---|---|
| Infotainment app or map data | Degraded feature | Minutes, background | Low: app regression |
| Configuration or parameter change | Silent change to regulated behavior | Minutes, background | Medium: full regression on the affected function |
| Comfort or body ECU firmware | Dead function, dealer recovery | Minutes to tens of minutes, vehicle stationary | Medium: flash path plus regression |
| HPC, OS, hypervisor, middleware | Cascading; orchestrator in scope | Tens of minutes, vehicle stationary | High: full baseline regression |
| ADAS, chassis or powertrain firmware | Direct safety consequence | Tens of minutes, vehicle stationary | Very high: safety and regulatory assessment |
| Bootloader or key material | Bricking, no OTA recovery | Stationary, vehicle immobilized | Very high: service-only or staged |
Downtime is program-specific, driven by image size, bus bandwidth, and bootloader design.
The last three rows most likely touch an RXSWIN and trigger an approval assessment.
Frequently asked questions
What is the difference between SOTA and FOTA?
SOTA (software over the air) updates application-layer software on a capable compute node — infotainment apps, navigation data, configuration. FOTA (firmware over the air) replaces the firmware image on an embedded ECU, including code that drives actuators. FOTA is harder because embedded ECUs have limited flash, slower buses, strict power requirements during flashing, and a real risk of being left unusable if the process is interrupted.
What is a Software Update Management System under UNECE R156?
A SUMS is the documented set of processes a manufacturer uses to manage software updates across the vehicle lifecycle, assessed and certified by an approval authority. It covers recording vehicle software and hardware configurations, identifying type-approval-relevant software, assessing each update's impact on safety and approval, executing updates safely, informing users, and maintaining traceability including supplier interfaces.
What is RXSWIN?
RXSWIN stands for Regulation X Software Identification Number. It is the identifier a manufacturer declares for software relevant to a particular UN regulation, linking that software to the vehicle's type approval. It must be readable from the vehicle and protected against unauthorized modification. When an update changes covered software, the manufacturer determines whether the change stays within approved scope or requires the approval to be addressed.
How does A/B partitioning enable rollback?
A/B partitioning gives an ECU two firmware banks. The update is written to the inactive bank while the active one keeps running, then a reboot switches which bank is active. If the new image fails to boot or fails a health check, the system reverts to the previous bank. Downtime shrinks to a reboot. The cost is roughly double the flash memory, which is why it is rare on low-cost microcontrollers.
Can a vehicle be driven during an over-the-air update?
For low-risk updates touching only application software on a non-critical node, often yes — the download runs in the background and activation happens later. For firmware updates to ECUs involved in driving functions, no. The vehicle must be stationary with preconditions met: parked, adequate energy supply, driver informed. R156's intent is explicit that if driving during an update would be unsafe, the vehicle must not be drivable while it runs.
How do UNECE R155 and R156 relate?
R155 covers cybersecurity and requires a certified Cyber Security Management System; ISO/SAE 21434 is the engineering standard commonly used to demonstrate one. R156 covers software updates and requires a certified Software Update Management System. They are complementary: R156 depends on the integrity and authenticity guarantees the security process provides, and most manufacturers manage both under one governance structure.
How do you test an update across an existing fleet's software permutations?
Constrain the problem first. Define a small set of approved vehicle-wide baselines and permit only baseline-to-baseline transitions, so you test defined paths rather than an open permutation space. Then cover version combinations and interruption scenarios in virtual and SIL environments, prove the flashing path on hardware benches and HIL, deliberately test failure and rollback, and stage the rollout through canary cohorts with predefined halt criteria.
GEMMACON works on the parts of OTA that decide whether a campaign is safe to run: baseline and configuration management, update orchestration across mixed ECU stacks, and the validation strategy that proves a transition before it reaches customer vehicles. If you are building an update path that has to satisfy both a release schedule and an approval authority, get in touch.
