zevOS

01Operations

Firmware across a mixed fleet: roll out by cohort, never by unit

Firmware fixes faults and creates them. The discipline that separates a controlled upgrade from a network-wide outage is cohorts, baselines and a way back.

FOzevOS Field Operations · Customer operations
15 April 2026 · 2 min read

Every charging network eventually discovers that it is running eleven firmware versions across four vendors, that nobody knows which units are on which, and that the vendor’s answer to a reported bug is "upgrade to the latest". Firmware drift is not a hygiene problem. It is the reason two identical chargers behave differently, and it makes every other diagnosis harder.

Know your baseline before you need it

The minimum useful state is a list: every charger, its model, its current firmware version, and the date it was last updated. OCPP gives you the version on boot, so this is a reporting job rather than an inventory job — but it only works if the platform stores what the charger reported rather than what someone typed into a spreadsheet at commissioning.

From that list, define a baseline per model: the version you have tested and are willing to run. Anything below it is a planned upgrade. Anything above it is an unplanned one, which usually means a vendor pushed an update through their own channel — worth knowing about immediately.

Cohorts, in this order

  1. 01One unit on a bench or a low-traffic site. Run a full session on it. Check meter values, fault reporting and remote commands still behave.
  2. 02One site, all units. This catches interactions between units sharing a load-managed supply — the failure mode a single bench unit cannot show you.
  3. 03Ten to twenty percent of the fleet, spread across site types. Hold for a week and watch fault rates and failed session rates against the untouched remainder.
  4. 04The rest, in batches, never all at once.

Windows and the sessions you will interrupt

A firmware update takes a charger out of service for anywhere between two and forty minutes, and some units reboot more than once. Schedule against the site’s own demand profile, not a network-wide "overnight" assumption — a residential society charges overnight and a corridor site does not.

Set the units unavailable before the update rather than letting a driver plug into a charger that is about to reboot. It costs a few minutes of availability and prevents a support ticket that reads "it stopped charging and did not tell me why".

The way back

Ask the vendor, before the first rollout, whether the previous version can be reinstalled and what it takes. For a surprising number of units the answer is "not remotely", which changes the risk calculation entirely and is worth knowing before you have upgraded eight hundred chargers rather than after.

Where rollback is not possible, the cohort discipline is not a nice-to-have. It is the only protection you have.

firmwaremaintenancerisk

Get the next one by email

One email a month. Operations notes, unit economics and policy changes that affect your tariff.