Over-the-air updates get mentioned constantly as a software-defined vehicle capability, but shipping one update safely to one test vehicle is a very different problem from running automotive fota and SOTA campaigns across an entire production fleet, where a failed update can leave a safety-relevant ECU unusable in a customer's driveway. This article covers what that real update architecture actually involves: the difference between software and firmware updates, how a campaign is staged and rolled out, how rollback protects against a failed flash, and the regulatory framework now mandating a lot of this discipline outright.
SOTA, software-over-the-air, updates application-layer software running on a vehicle's higher-level compute platforms — infotainment features, navigation data, telematics applications — generally with lower risk if an update goes wrong. Automotive fota, firmware-over-the-air, instead updates the low-level firmware running directly on an ECU, including safety-relevant ones like braking or powertrain controllers, where a failed or corrupted update can leave the ECU non-functional rather than just running an older feature set. The distinction matters architecturally because FOTA update of vehicle ECUs demands a far more conservative update and rollback strategy than SOTA does, and a vehicle's OTA architecture generally has to support both update classes with meaningfully different risk controls rather than treating every update the same way.
An OTA update for a production fleet is never pushed to every vehicle at once; campaign management stages the rollout deliberately, starting with a small cohort of vehicles and expanding only once telemetry confirms the update is behaving as expected in the field. Campaign management has to account for vehicle variant, hardware revision, and current software state, since a fleet running years of production accumulates real heterogeneity, and an update campaign that assumes a uniform fleet will fail against vehicles it was never actually validated for. Automotive FOTA campaign management also needs the ability to pause or halt a rollout mid-campaign the moment field telemetry flags a problem, before the update reaches the rest of the fleet.
A/B partitioning keeps two complete, bootable copies of an ECU's firmware on separate storage partitions, applying an update to the inactive partition while the vehicle keeps running on the known-good active one, then switching over only after the new partition validates successfully. If the new partition fails to boot correctly or fails a post-update health check, the ECU falls back to the previous known-good partition automatically, without requiring a service visit to recover a bricked ECU. This A/B and rollback architecture is what makes FOTA update of vehicle ECUs viable for safety-relevant systems at all — without it, any single failed update in the field turns into a stranded vehicle and a costly recovery, which is not a risk a safety-relevant OTA architecture can accept at fleet scale.
Modern vehicles run dozens of interdependent ECUs, and updating one in isolation without accounting for the others it communicates with can leave a vehicle in an inconsistent state where two ECUs expect incompatible message formats or software versions from each other mid-update. Update sequencing has to define which ECUs update in what order, how the vehicle behaves — and whether it can still be safely driven — mid-campaign while some ECUs are updated and others aren't yet, and how the whole sequence is validated as complete before the vehicle is considered successfully updated. Getting this sequencing wrong is one of the more common real-world causes of an OTA campaign that looks fine in isolated ECU testing and then fails against the actual interconnected vehicle.
What is secure fota? is FOTA architecture designed with the assumption that an update package could be intercepted, tampered with, or spoofed by an attacker somewhere between the backend server and the vehicle, and engineered specifically to prevent that from resulting in malicious code running on a vehicle's ECU. Secure fota services combine cryptographic signing and verification of every update package, an encrypted and authenticated communication channel between the vehicle and the update server, and secure boot validation on the ECU itself confirming that only correctly-signed firmware is ever allowed to run. Secure FOTA services are not optional hardening layered on top of a working update system after the fact; they're a core requirement of any OTA architecture that touches a safety-relevant or security-relevant ECU.
UN Regulation No. 156 formalizes much of what secure FOTA services already aim to deliver, requiring vehicle manufacturers to demonstrate a documented software update management system covering how updates are developed, validated, deployed, and tracked across a vehicle's service life, with particular scrutiny on updates affecting type-approved, safety-relevant systems. Our piece on UN R155 and R156 regulatory mandates covers this compliance framework in depth; for an automotive FOTA architecture, R156 effectively turns campaign management, A/B rollback, and secure update signing from good engineering practice into a regulatory requirement a vehicle program has to demonstrate compliance against before it can be type-approved in markets that enforce the regulation.
Automotive OTA and FOTA architecture is one of the core technical building blocks any software-defined vehicle depends on, alongside the compute and domain architecture described in our piece on software-defined vehicle architecture, and it builds directly on the update-resilience groundwork covered in building resilient embedded systems for next-gen vehicles, where OTA updates first appear as a keyword without the dedicated depth this article provides.
Embien Technologies engineers automotive fota architecture — SOTA and FOTA update of vehicle ECUs, campaign management, A/B partitioning and rollback, and secure FOTA services aligned to UN R156 compliance. To discuss automotive FOTA or campaign management architecture for a software-defined vehicle program, reach out to Embien's engineering team.
Embien's Digital Transformation Services connect embedded systems, cloud platforms, and connected products to support software updates, intelligent automation, and scalable digital operations.
Explore how software-defined vehicle architectures enable software updates, connected vehicle functions, and continuous feature enhancements throughout the vehicle lifecycle.
A case study on implementing a UDS client for an Android automotive cluster, enabling remote diagnostics and firmware-over-the-air updates.