From field report to firmware: how a charger issue becomes a fix

Most EV charger reliability content stops at the marketing claim: the charger is tested, the firmware is updated, everything is fine.

The more useful question for anyone buying a connected product that will be on their wall for a decade is different. When something does go wrong, what actually happens next? How does a single customer's bad night become a change in the software running on every charger in the field?

This is that process, written down.

Quick answer: how does a charger issue become a firmware fix?

A reported issue becomes a firmware fix by being identified against a specific unit, reproduced as a repeatable test scenario, corrected in software, verified against automated hardware-in-the-loop testing, and then released in stages with the original reporting site monitored to confirm the behaviour has changed.

The engineering is rarely the slow part. Reproducing the problem reliably is.

Stage one: the report has to be attached to a real unit

A support conversation that begins "my charger did not charge last night" is not yet actionable. The same sentence covers a schedule that had not opened, a vehicle that stayed asleep, a load-management pause, a connectivity drop and a genuine firmware defect.

What turns it into something an engineer can work with is identity. Which unit, on which hardware revision, running which firmware version, installed when, on what kind of supply, with what connectivity route.

This is the unglamorous reason PlugStream Passport exists. Every charger carries its own record — model, serial, install history, warranty position — so a support conversation starts from a known unit rather than a description of one. On commercial estates, PlugStream Sentinel adds the site-level view: what else was happening on that site, at that time, across other chargers.

The practical test of any charger brand's support is whether they can answer "which firmware was that unit running at 02:00 on Tuesday?" without asking the customer to go and look.

Stage two: reproduce it, or you have not understood it

A fix written against a theory is a guess. The step that separates real engineering from plausible engineering is reproducing the fault on demand.

That is harder than it sounds, because the interesting charging failures are timing failures. A vehicle that sleeps after forty minutes but not after twenty. A schedule that opens at the same moment a load-management signal arrives. A network drop midway through a session start. These are not conditions you can wait around for on a bench.

Our automated hardware-in-the-loop rigs exist for this. Real EVSE boards under full serial and power control, Control Pilot emulation for the vehicle side, virtual OCPP chargepoints across OCPP 1.6, 2.0.1 and 2.1, and an orchestrator that can run named scenarios around the clock.

Once a field report is reproduced on a rig, something important changes: it stops being an anecdote and becomes a named test. It can be re-run at any time, by anyone, in a minute rather than a night.

Stage three: the fix, and the test that outlives it

The code change is usually small. The valuable artefact is the scenario that now sits permanently in the test matrix.

This is where the industry's incentives get interesting. Adding a test for the bug you just fixed costs time today and produces nothing a customer can see. Skipping it costs nothing today. The difference only shows up eighteen months later, when a change in an unrelated area quietly reintroduces the same failure and nobody notices until customers do.

A regression suite is essentially a record of every mistake a product has made, preserved so it cannot make them twice. A charger platform with a growing named-scenario library gets steadily harder to break. One without gets steadily easier.

Stage four: release in stages, not all at once

An update that is wrong everywhere at once is worse than the bug it fixed.

Sensible release practice for connected hardware means the same things it means for any deployed system: release in stages, watch what the field reports back, keep the ability to hold a rollout, and expect the update process itself to be resilient. Chargers live on domestic Wi-Fi, in metal enclosures, at the end of long garden cable runs, sometimes on 4G. Interruption is normal, and the update path has to assume it.

Timing matters too. A firmware update should never land in the middle of a charging session, and it should not consume the off-peak window a customer is paying for. Waiting for the charger to be idle is not a limitation, it is the requirement.

Our Product Security Update Policy sets out the formal commitment: a minimum five-year security update period from first installation for both the PlugStream 7 and PlugStream 22 families, covering firmware, cloud service and configuration changes for chargers in a supported configuration.

That is worth checking against any charger you are considering. A connected product without a stated update period is a connected product with an undefined end date.

Stage five: confirm it actually worked

The last step is the one most often skipped: going back to the site that reported the problem and confirming the behaviour has genuinely changed.

Not "the fix was released". Not "no further reports received". Confirming that the specific site, with the specific vehicle and specific conditions, now behaves the way it should.

Charger Readiness helps here, because charger-side state is visible rather than inferred. If a site reported repeated missed overnight windows, the useful evidence is that subsequent windows started as expected — not that nobody complained again.

What this means for buyers

Reliability in connected hardware is not a property of the box on the wall. It is a property of the loop around it: identify, reproduce, fix, test, release, verify.

Questions worth asking any charger supplier, ours included:

• What is your minimum firmware and security update period, in writing?
• How do you identify which firmware a specific installed unit is running?
• Can you reproduce a reported charging fault, or do you rely on it happening again?
• Are updates staged, and can a rollout be held?
• What happens to a charger that has been offline for six months?
• Who supports the product if the platform behind it changes hands?

The answers separate a charger that is sold from a charger that is supported.

What we get wrong, and what we are still building

Being straight about the limits: not every reported issue is reproducible, some depend on vehicle firmware we do not control, and site conditions can be genuinely unique. Automated testing covers the behaviours PlugStream can control and observe, which is a real boundary rather than a marketing one.

We are continuing to grow the named-scenario library, widen OCPP coverage across versions, and improve how much useful site context reaches support before a customer has to explain it.

Related PlugStream guidance

Read the testing story in depth: Automated 24/7 hardware-in-the-loop rigs.

Then review PlugStream Passport for per-charger identity, Charger Readiness for charger-side visibility, PlugStream Sentinel for managed site support and the Product Security Update Policy for our formal update commitment.