A connected-vehicle fleet needs over-the-air firmware updates. What must the architecture guarantee, and why is this unlike a server deployment?

Why it is unlike a server deployment

A failed update on a vehicle is not a rollback — it is a recovery vehicle. A server that fails to start is replaced automatically; a device that fails to start is physically inaccessible, in a customer's possession, and possibly unable to receive a corrective update at all.

The failure is expensive, physical and not reversible remotely, which changes every design decision.

What the architecture must guarantee

• An A/B partition scheme: the update is written to the inactive partition, verified, and activated on the next start. A failure to boot falls back to the previous partition automatically, without any network or human involvement.
• Cryptographic verification before installation, so a corrupted or substituted image is not applied.
• Resumable download over an intermittent connection, since the vehicle will lose connectivity mid-transfer and restarting from zero is unacceptable on a metered link.
• Preconditions checked on the device: sufficient battery, not in use, not in motion. The device must refuse an unsafe update regardless of what the server instructed, because the server does not know the physical state.
• Staged rollout by cohort with automated halt conditions, since a bad update reaching an entire fleet is the failure mode that ends companies — and the rollout must be halted on device-reported health rather than on server-side metrics.
• A recovery path that does not require the primary update mechanism, since the thing that broke may be the thing you would use to fix it.

The staging that matters most

Internal fleet, then a small customer cohort, then progressive expansion — with a soak between stages long enough for problems that do not appear immediately. Battery behaviour, thermal effects and interactions with usage patterns take days to surface, and the soak is what gets compressed under pressure.

The observability requirement

Device-reported health after the update, not just successful installation. A device that installed and is behaving badly reports success to a naive system — and the difference between install success and post-update health is the whole safety signal.