Over-the-air update is the capability that determines whether a deployed fleet can be maintained or must be visited. It is also the capability most likely to take a fleet offline if it is designed carelessly.
The design question is not how to deliver a new image. It is what happens when delivery, verification or execution fails on a unit at a site nobody can reach quickly.
Dual images and rollback
The safe arrangement holds a working image while a new one is written, and only switches once the new image has been verified and has demonstrated it can run. If it cannot, the bootloader returns to the known-good image without intervention.
This constrains flash sizing, which is why OTA is a hardware decision as much as a software one and is difficult to add to a design that did not plan for it.
Verify before executing, not after
An image must be authenticated and its integrity checked before it is allowed to run. Verification after boot is too late: by then unverified code has already executed.
Signing gives that guarantee, and it moves the security problem to the signing key, which is where it belongs and where it must be protected accordingly.
Key custody is the hard part
This is the part of OTA design most often left undrafted, and the consequences of getting it wrong are the most severe of anything in the update path.
- Who holds the signing key, and where.
- How access to signing is controlled and logged.
- What happens if the key is compromised, and whether the fleet can accept a new one.
- Whether a customer taking a technology transfer receives signing capability, and under what terms.
Stage the rollout
Updating an entire fleet at once means a defective release affects everything simultaneously. Staged rollout, starting with a small group and expanding once they demonstrate stability, contains the damage.
Sizing the first group so a failure is recoverable, and defining what stability means before starting, are the two decisions that make staging useful rather than ceremonial.
Never update mid-session
An update applied while a vehicle is charging risks interrupting a session and losing the transaction record. The update mechanism must defer until the connector is idle, and must handle a vehicle connecting while an update is pending.
On a busy site a charger may not be idle for a long time, which means the mechanism also needs a policy for how long it waits and what it does then.
Interrupted downloads and power loss
Connectivity fails mid-download and power fails mid-write. Both must leave the charger running its existing image, with the partial download discarded rather than treated as complete.
The test that matters is deliberately cutting power at several points during an update and confirming the unit still boots. It is easy to run and rarely run.
Version tracking across the fleet
Fleets accumulate versions. Units offline during a rollout, replaced under warranty or commissioned from old stock end up on builds nobody is tracking, which makes fault patterns unreadable.
Reporting the running version, and reconciling what is deployed against what was intended, is part of the update system rather than a separate reporting concern.