Firmware Over-the-Air: Managing Updates Across a Live Fleet
Updating software on a device nobody can plug in is a different discipline from updating a phone. Getting OTA firmware management wrong at scale is expensive in ways that are hard to reverse.
A phone that fails a software update sits on a desk until someone notices. A meter that fails a firmware update sits in a wall cavity or an underground pit, unattended, for however long it takes someone to realise it's gone dark — if it's even recoverable at that point. Over-the-air firmware management for a metering estate carries a version of every risk a normal software rollout carries, with the safety net removed.
The constraints are also unusually tight: many devices update over bandwidth-limited, battery-powered connections, where the update itself consumes power the device wasn't necessarily designed to spend often. Getting the process right is as much about discipline and staging as it is about the update mechanism itself.
This briefing sets out how to manage OTA firmware safely across a live fleet, and the risks worth naming before the first campaign goes out.
Staged, never fleet-wide first
Figure 1. Each stage is a checkpoint, not a formality — a failure caught at 0.1% costs almost nothing to fix; the same failure caught at 100% is a field recovery programme.
Six risk points worth naming
No rollback path for a remote device
A failed update with no physical access can permanently strand a unit.
The update process itself drains battery
Frequent or oversized updates consume power budget allocated for years of normal operation.
Bandwidth-constrained bearers extend exposure
A push over LPWAN can take far longer than over cellular, leaving devices mid-update for longer.
Unsigned or unverified firmware accepted
An update mechanism without strong authentication is a direct path for a compromised firmware image.
Scheduling collides with critical operations
A push during a billing read window or a grid event adds risk at exactly the wrong moment.
No fleet segmentation strategy
Pushing to the whole estate at once removes the ability to catch a bad release before it's everywhere.
Updating with discipline
Always stage through a canary batch first
However time-pressured the fix feels.
Design and test a genuine rollback path
Before it's needed, not after a failed update.
Budget the update process into the power and bandwidth plan
Treat it as a real operational cost, not a free action.
Require signed, verified firmware images
As a hard requirement, not a configurable option.
Schedule campaigns around critical operational windows
Not just around convenience.
A firmware update on an unattended, battery-powered device at the edge of the network has to work the first time, or fail in a way that's recoverable. Staging, verification and rollback aren't precautions on top of the update mechanism — for a metering estate, they're the mechanism.
How a read moves across the estate
HOVER OR TAP A STAGE TO EXPAND TECHNICAL SPECS
Chris Gales
Chris Gales leads CEHG. He converts complex technical and commercial choices into clear decisions and dependable outcomes for utilities running connected device estates at scale.
He writes these field notes from the practice — on bearer migration, smart metering architecture, procurement and operations — to help estates start counting down early.