OTA Updates for Embedded Systems

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.

The Core Difference: Presence vs. Absence of a Human in the Loop

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.

Connectivity: Designing for an Unreliable Link

Wired reflashing assumes the connection stays up for the duration of the transfer. OTA cannot make that assumption:

Interruption is normal, not exceptional. A vehicle can drive out of cellular coverage mid-download; a Wi-Fi-connected industrial device can lose its access point. The update process needs to pause and resume rather than treat every disconnect as a failure requiring restart from zero.
Chunked, resumable transfer. OTA payloads are typically broken into resumable segments with their own integrity checks, so an interrupted transfer can resume from the last successfully received chunk rather than re-downloading the entire image.
Bandwidth and data cost constraints. Cellular-connected devices often have metered data plans; OTA payload size directly affects both transfer time and operating cost in a way a wired connection on a shop floor never has to consider. Delta/differential updates (transmitting only the bytes that changed from the previous version) are far more common in OTA architectures for this reason.
Scheduling around usage. Many OTA systems delay the actual firmware swap-over until the device is idle, parked, or otherwise safe to interrupt — a decision wired reflashing doesn't need to make because the technician already chose to take the device offline.

Reliability: No One to Catch a Failed Update

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.

Security: A Fundamentally Larger Attack Surface

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.

Authentication of the update source. OTA firmware must be cryptographically signed and verified before being applied, for the same reasons and by largely the same mechanism covered in our guide on code signing for embedded firmware — but OTA raises the stakes, since an attacker doesn't need physical proximity to attempt to push a malicious image.
Transport security. The update channel itself (TLS for cellular/Wi-Fi-connected devices, or an equivalent secured protocol) needs to protect the payload in transit, separate from the firmware signature that protects its authenticity.
Server-side attack surface. OTA introduces a backend — the update/campaign management server — as a new component that itself must be secured, monitored, and access-controlled, since compromising the server can compromise every device that trusts it.
Fleet-scale blast radius. A compromised wired reflash tool affects however many units a technician can physically reach. A compromised OTA campaign can push a malicious or broken image to an entire fleet simultaneously, which is exactly the scenario UNECE R156's software update management system requirements are designed to prevent.

Update Size and Frequency

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:

Full image vs. delta updates. Sending a complete firmware image over a metered cellular connection to a large fleet is expensive at scale; differential/delta update techniques that transmit only changed bytes are common in OTA specifically to control cost and transfer time.
Update frequency expectations. Because OTA removes the friction of scheduling a service visit, products with OTA capability tend to ship updates more frequently — which raises the bar on how well-tested and how safely rollback-capable each individual update needs to be, since there are more of them.
Campaign management. OTA at fleet scale typically involves staged rollouts (a small percentage of devices first, then wider deployment) to catch problems before they reach the full fleet — a concept that has no real equivalent in one-at-a-time wired reflashing.

What Carries Over from Wired Reflashing

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.

How Simma Software Fits In

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.

Frequently Asked Questions

Do OTA-capable devices still need wired reflashing support?

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.

Is OTA update capability required for automotive ECUs?

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.

What happens if power is lost during an OTA update?

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.

How is OTA update size typically reduced for constrained connections?

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.

Does OTA update capability require a cellular modem?

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.

Blog