The set of standard OCPP error codes is small relative to the number of things that can go wrong in a charger. Manufacturers therefore map many internal conditions onto each code, and they do not map them the same way.
The consequence is that the same code from two brands means two different things, and a platform treating codes as a common language across a mixed fleet will draw wrong conclusions confidently.
Why the standard set is not enough
The codes describe broad categories: a ground fault, an over-current, a communication problem, an internal error. A charger has dozens of distinguishable failure conditions and must compress them into that vocabulary.
Compression loses the detail that makes a fault actionable. Knowing there was an internal error tells a technician nothing about what to bring to site.
Where the useful information lives
Most manufacturers provide vendor-specific error information alongside the standard code, and that is usually where the actionable detail is: a subsystem, a specific condition, sometimes a documented code that maps to a service action.
A platform that stores only the standard code discards it. Retaining the vendor field, even without understanding it, means the information is available when someone eventually needs it.
The mixed fleet problem
Once a network runs more than one brand, cross-fleet fault analysis becomes unreliable. Counting occurrences of a code across brands produces a number that means nothing, because the underlying conditions differ.
The workable approach is to normalise per brand into your own taxonomy rather than to treat the standard codes as already normalised. That is work, and it is the work that makes fleet-level diagnosis possible.
Build your own taxonomy
- Define the categories your operation actually acts on: site visit required, remote reset likely to resolve, vehicle-side, ignore.
- Map each brand's codes and vendor information onto those categories.
- Keep the raw code and vendor field alongside the mapped category, always.
- Revisit the mapping when firmware changes, because the mapping can change with it.
Faults that are not faults
A significant share of reported faults require no action. A vehicle that stopped drawing, a session ended by the driver, a brief communication interruption that recovered. Presenting these to an operations team alongside genuine faults trains people to ignore alerts.
Filtering them out is more valuable than detecting more faults, and it is the first thing to build rather than the last.
Sequence matters more than the individual code
One error code is a data point. A pattern, such as the same code recurring on one connector at the same time each day, is a diagnosis. Storing the sequence with timestamps rather than only the current state is what makes that visible.
This is the same reason status transitions matter more than status. The information is in the change, not the snapshot.
What to ask a charger vendor
A vendor who can answer these has thought about how their product is operated. Many cannot, which is itself worth knowing before you buy a fleet of them.
- Which internal conditions map onto each standard code.
- Whether vendor-specific error information is provided, and whether it is documented.
- Whether the mapping is stable across firmware versions.
- Which faults are self-clearing and which require intervention.