Over-the-air update depends on partition layout, bootloader design, signing infrastructure and rollback capability — none of which can be added to a fleet that has already shipped without a physical intervention. It is the clearest example of a decision that costs almost nothing in week three and is close to impossible in year two.
Enough flash for two application images, or a scheme that can install into the space available without a window in which a power loss bricks the device. This is a bill-of-materials decision as much as a software one, and it is made when the flash part is chosen.
Immutable first-stage code that can select between images, verify a signature and fall back. It is the one component that cannot itself be updated safely, so it is written conservatively and reviewed hard.
Keys generated, stored and used in a process that will still be operable and still be defensible in year eight. A signing key on a departed engineer's laptop is a product that can no longer be updated.
How the device reports what it runs, and which combinations of firmware, configuration and platform schema are permitted. Without this a staged rollout has nothing to stage on.
A defined trigger and a defined path back. Automatic on a boot-loop or a health-check failure, because a device that cannot phone home cannot be told to revert.
Canary group first, monitored against explicit signals, then progressive expansion. A bad release should reach fifty devices, not fifty thousand.
Power loss mid-write. The single most common way to brick a fleet. A dual-image scheme with atomic switchover removes it; a single-image in-place update does not, however careful the code is.
The partially-successful rollout. Sixty per cent of devices take the update and forty per cent do not, because they were asleep, out of coverage or on a battery too low to risk it. The fleet is now running two versions indefinitely, and the platform has to be correct for both.
The update that works and then does not. A release that boots fine and fails four days later under a condition the canary group did not encounter. This is why the monitoring window matters as much as the canary size.
The unreachable device. A unit that missed several releases and is now too far behind to take the current one. A migration path from any shipped version, not just the previous one, is worth designing early.
| Scheme | Flash cost | Power-loss safe | Typical fit |
|---|---|---|---|
| Dual image (A/B) | Two full application slots | Yes, with atomic switchover | Anything that can afford the flash; the default choice |
| Image plus recovery | One slot plus a minimal recovery image | Yes, with a degraded recovery path | Cost-constrained devices where two full slots do not fit |
| Delta or differential | Smaller transfers, dual slots still needed | Yes | Constrained links where transfer size, not flash, is the limit |
| In-place single image | Lowest | No | Avoid in fielded products; acceptable only with physical recovery access |
Because it depends on flash partition layout, bootloader design and signing infrastructure that are fixed at the hardware and first-firmware stage. Adding a safe update path to devices already in the field generally requires physically reaching them.
The device holds two application slots. A new image is written to the inactive slot, verified, and then activated by an atomic switch. If it fails to boot or fails a health check, the bootloader reverts to the previous slot. Power loss during the write leaves the running image untouched.
Large enough to encounter the conditions that matter and small enough that a failure is recoverable — often one to five per cent of a fleet, weighted toward variety of environment rather than raw count. The monitoring window matters as much as the size, because some failures appear days later.
Written for engineers. Share it with one.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.