IoT Platform / OTA Updates
OTA firmware updates
you can stage, watch and undo
Signed images, rollouts that widen one ring at a time, per-device update state with reason codes on failure, and a rollback path that works even when the device has already lost its link. Built for fleets on metered cellular and unreliable connections.
The Risk
A firmware push is the
only way to break everything at once.
Every other failure in a connected product is bounded. A bad server deploy is reverted in minutes. A bad batch of hardware affects one lot. A firmware image sent to a whole fleet at once can put every unit into a state you cannot reach over the network, and the recovery is a truck to every site.
That is why the platform treats an update as a controlled release rather than a push. Firmware is published, signed, and bound to compatible variants. A rollout targets a small group first, sits there long enough for problems to surface, and only widens when the numbers say it should. Every device reports where it got to and why it stopped.
The device side has to cooperate for any of this to work. The embedded update agent, secure boot chain, and flash layout are engineered alongside the platform, which is covered in detail on our OTA firmware update system engineering page. This page is about what happens once thousands of those devices are in the field and a release has to reach all of them.
Staged Rollouts
Widen one ring at a time.
Stop at the first sign of trouble.
Targeting uses the same grouping the registry already holds, so a stage is a query rather than a hand-built device list. Each stage has an entry gate and a soak period before the next one opens.
A few reachable units first
Real install conditions
A boundary that isolates blame
Converge as devices check in
Halt or revert on failure
Publish and Sign
The build is signed, given a version, and recorded against the variants it is compatible with. Compatibility is enforced by the platform, so a build for revision C can never be offered to a revision A unit.
Canary Ring
A handful of tagged units take the update first. These are usually devices your own team can physically reach. If the image bricks something, it bricks something you can put on a bench.
One Lot
Widen to a single manufacturing lot. This is the first test against real installation conditions, real radio quality, and real power behaviour rather than a lab bench.
One Variant or Region
Expand along a boundary that isolates blame. If failure rate climbs at this stage, the boundary tells you whether the problem is hardware revision, network operator, or environment.
Full Fleet
The remaining devices converge on the target version as they check in. Units that are offline stay pending and take the update whenever they next reconnect.
Gates between stages
Minimum soak time before the next stage opens
Failure rate ceiling per stage, breached means automatic halt
Post-update health check before a device counts as confirmed
Reboot loop detection across the target group
Connectivity regression check against the pre-update baseline
Manual approval required to widen beyond the canary ring
Tell us your flash layout, your link budget, and your fleet size. We will tell you what a safe rollout looks like.
Book a Technical Session →Rollback
Four ways back
from a bad build.
Rollback has to work at both ends. A device that has already lost network cannot wait for an operator, and an operator cannot wait for ten thousand devices to notice something is wrong on their own.
- Bootloader keeps the previous image
- Device reverts if a health check fails
- Operator can halt a rollout mid-stage
- Previous version re-targeted as a deployment
- Failed units quarantined from new rollouts
- Blast radius stops at the open stage
Device-Side Revert
The bootloader keeps the previous image. If the new firmware does not confirm itself healthy inside a set window, the device reverts on the next reset without anyone touching it. This is what protects a unit that has already lost network.
Platform Halt
An operator stops the rollout mid-stage. Devices that have not started downloading never get the image. Devices mid-transfer abandon it. The blast radius stops at whatever stage was open.
Targeted Downgrade
The previous version is re-targeted to the affected group and deployed with the same staging, tracking, and verification as any other release. A downgrade is a deployment, so it gets the same discipline.
Quarantine
Devices that failed the update are tagged and excluded from further rollouts until someone has looked at them. This stops a small number of unhealthy units silently absorbing every future release attempt.
Update Tracking
Six states per device.
A reason code on every failure.
A percentage complete tells you nothing about why a rollout has stalled. State per device with a failure reason tells you whether one unit has a flash problem or a whole variant cannot verify the signature.
Illustrative confirmed rate across a staged rollout.
Pending
Assigned a target version, has not started. Offline devices sit here until they check in.
Downloading
Transfer in progress, chunked and resumable. Progress percentage reported per device.
Verifying
Signature and integrity checked on the device before anything is written to the active bank.
Applying
Image written and the device reset into the new build. The shortest and riskiest window.
Confirmed
New firmware booted, checked in, and passed its post-update health check. Only now does the rollout count it.
Failed
Stopped with a reason code: transfer timeout, signature mismatch, flash write error, boot failure, or health check failure.
Operators work this in the S3Suite firmware and OTA module, where a deployment shows progress per stage, per lot, and per serial, and a failed unit links straight to its device history and support record.
Field Constraints
Real devices update
on bad connections.
OTA on a desk over Wi-Fi is straightforward. OTA on a battery device in a basement on a metered cellular plan is where the engineering is. These are the constraints the update path is designed around.
Metered Bandwidth
On a cellular plan every megabyte of firmware is a real cost multiplied by fleet size. Delta images against the version a device is actually running cut that sharply, and the platform picks the right patch per device rather than shipping one image to everyone.
Intermittent Links
Devices in basements, lift shafts, and rural sites drop mid-transfer as a matter of routine. Chunked, resumable transfers with per-chunk integrity checks mean a dropped link costs seconds, not a restart.
Constrained Flash
Not every device has room for two full images. Where dual-bank is not possible, the update path uses a smaller recovery image that can always pull a working build, so a failed update leaves a device that can be rescued remotely.
Power and Duty Cycle
Battery devices cannot hold a radio open for a long download. Transfers are scheduled into wake windows, spread across several cycles, and abandoned safely if the power budget will not cover a complete write.
Devices That Must Not Interrupt
A charge point mid-session or a lift in service should not reset. The update agent asks the application whether now is safe and waits for an idle window rather than forcing the reboot.
Server Load at Fleet Scale
Ten thousand devices told to update at the same instant will take down whatever is serving the image. Rollouts are rate limited and jittered, so the transfer load is spread rather than arriving as one spike.
FAQ
OTA questions
worth settling early.
A staged rollout releases new firmware to a small group first, waits, checks the result, then widens. Typically a canary tag of a few units, then one lot, then one variant, then the fleet. It matters because a bad image pushed to every unit at once can take an entire fleet offline, and there is no way to reach devices that no longer boot.
Related
Go deeper.
Ship firmware without
holding your breath.
Whether you need an update path designed into a new product or a safer rollout process for a fleet already in the field, the first conversation is technical.