Blog
OTA Updates for Embedded Systems
August 6, 2026
Reflashing an ECU over a wired diagnostic connection — UDS over CAN, a service port, a bench programmer — has been the standard update path in embedded systems for decades. It's predictable: the technician is physically present, the connection is stable, and if something goes wrong, there's a person standing there to intervene. Over-the-air (OTA) updates remove that person and that stable link, and in doing so change nearly every assumption a wired reflash process depends on.
For teams adding OTA capability to a product that already supports wired reflashing, the temptation is to treat OTA as "the same update, just over a different transport." That's a mistake. The transport is the smallest part of the difference — connectivity reliability, update size, security exposure, and failure recovery all need to be rethought for a channel where nobody is watching the process happen.
| Aspect | Wired Reflashing | OTA Update |
|---|---|---|
| Human present during update | Typically yes — technician, bench operator | No — update runs unattended, often while the device is in normal use |
| Connection stability | High — direct cable, controlled environment | Variable — cellular, Wi-Fi, or satellite link can drop mid-transfer |
| Update trigger | Manually initiated | Scheduled, remotely triggered, or policy-based |
| Physical access required | Yes | No |
| Immediate operator feedback on failure | Yes — operator sees the error, retries on the spot | No — device must self-diagnose and recover, or report back asynchronously |
| Typical bandwidth | High (CAN, USB, Ethernet — often >500 kbps effective) | Often constrained (cellular data caps, shared Wi-Fi, intermittent satellite) |
That last row — no one watching — is the design constraint that shapes everything else. A wired reflash that fails halfway through gets caught and retried by the person doing it. An OTA update that fails halfway through, on a device that's now unreachable or bricked, is a field failure with no operator present to recover it.
Wired reflashing assumes the connection stays up for the duration of the transfer. OTA cannot make that assumption:
This is where OTA architecture diverges most sharply from wired reflashing at the bootloader level.
| Aspect | Wired Reflash Recovery | OTA Recovery |
|---|---|---|
| Typical fallback on failure | Operator retries manually, often immediately | Device must autonomously detect failure and recover without intervention |
| Bank/partition strategy | Single-bank overwrite is sometimes acceptable, since a bad flash can be corrected on the spot | A/B (dual-bank) partitioning is close to mandatory — the previous known-good image must remain bootable |
| Watchdog/boot-loop protection | Less critical — operator notices a non-booting device immediately | Critical — the bootloader must detect repeated boot failures and roll back automatically before the device becomes a field brick |
| Reporting failure | Visible on the tool/bench immediately | Must be logged and reported back over the same (possibly unreliable) network link once connectivity resumes |
| Acceptable risk of a failed unit | Low impact — it's on a bench or in a shop | Can mean a fleet-wide unreachable device, sometimes in a safety-relevant system |
This is why dual-bank (A/B) update architecture — staging the new image in an inactive bank, verifying it, and only then switching the boot pointer, with automatic rollback if the new image fails to boot cleanly — is close to a baseline requirement for OTA, even in products where a single-bank wired reflash was previously good enough. If your team already has a dual-bank bootloader in place for wired updates, most of that groundwork carries over directly to OTA; if not, OTA is usually the point where it stops being optional.
A wired reflash requires physical access to the vehicle or device. An OTA update path is reachable, in principle, from anywhere the device has network connectivity — which is a categorically different threat model.
Wired reflashing is typically an infrequent, full-image operation performed during service or manufacturing. OTA changes the economics of how often and how much gets updated:
Not everything changes. The core bootloader mechanics — image verification, staging, and the commit/rollback logic described in our flash bootloader guide — are largely transport-agnostic. A well-designed bootloader doesn't need to know or care whether the new image arrived over UDS/CAN or over a cellular OTA agent; it just needs a validated image staged in the inactive bank. That separation of concerns — transport layer handles getting the bytes to the device, bootloader handles verifying and safely applying them — is what makes it possible to support both wired and OTA update paths from the same underlying bootloader architecture, rather than maintaining two entirely separate update mechanisms.
Simma Software's flash bootloaders are built around exactly this separation: deterministic, hard real-time protocol stacks for the transport side (UDS, CAN, J1939, LIN, CANopen, and more) paired with a bootloader architecture designed for safe, verifiable updates regardless of how the new image arrives. Because our stacks run at roughly 2% CPU utilization while sustaining ~8,000 CAN frames/sec, the verification and staging overhead an OTA-capable bootloader needs doesn't come at the cost of the real-time performance the rest of the application depends on — and the same dual-bank, signature-verified update logic that supports wired UDS reflashing extends naturally to an OTA-connected gateway or telematics module feeding new images into the same staging process.
Most do, at least for manufacturing, initial provisioning, and recovery scenarios where a device has lost network connectivity or is in a state OTA can't reach (e.g., a bricked bootloader). OTA typically supplements wired reflashing rather than fully replacing it.
It's not universally required, but UNECE R156 requires an auditable software update management system for approved vehicle types, and OTA is increasingly the primary update path OEMs plan around for that system, particularly for telematics-connected vehicles.
With a properly implemented dual-bank bootloader, a power loss during the download or staging phase leaves the previous known-good image untouched and bootable, since the new image isn't committed until it has been fully received and verified. Power loss during the brief bank-switch/commit operation itself is the highest-risk window, which is why that operation is kept as short and atomic as possible in a well-designed bootloader.
Delta (differential) update techniques, which transmit only the binary difference between the currently running firmware and the new version rather than the full image, are the most common approach — significantly reducing transfer size and cost compared to sending a complete firmware image over a metered connection.
No — OTA broadly refers to any wireless update path, which can include cellular, Wi-Fi, Bluetooth, or even a local wireless gateway that itself received the update via another connection. The wired-vs-OTA distinction is about the absence of a physical, direct connection and an attending operator, not the specific wireless technology used.