Every Charger Is Reporting an Error. Why Is the Answer Still So Hard to Find?
At 9:40 on Wednesday morning, I parked our company test vehicle beside the site office, put on my high-visibility vest, and picked up my tablet from the passenger seat.
The public charging site had been operating for several years.
The chargers closest to the entrance had been installed during the first phase. The next row arrived with an expansion two years later. The newest units at the far end had been added only last year.
Three phases. Three brands.
To a driver, they were all simply EV chargers. To me, they meant three service manuals, three sets of error codes, and three different technical support contacts.
That morning’s job was just a routine inspection.
I worked my way along the bays, checking the screens, cables, emergency-stop buttons, and air intake vents. Most of the chargers appeared green on my tablet. There was no widespread outage and no obvious critical alarm.
When I reached a unit in the middle row, I brought the test vehicle over, connected the charging cable, and started a session with our test card.
The screen confirmed that authorization had succeeded.
The progress symbol completed one circle, then another. The charging session that should have followed never began. Power remained at zero.
A few seconds later, the screen returned to its opening page:
“Charging failed. Please try again.”
I disconnected the cable and tried once more.
The result was the same.
It was not a dramatic failure. There was no smoke, no alarming sound, and no sudden loss of power. I simply stood beside the vehicle, watching the screen reset, with a familiar sense of exhaustion beginning to settle in.
I knew that what came next might not yet be repair work.
It would be translation.
The Backend Wasn’t Empty
I opened the CPO backend and found the failed charging attempt.
The charger was online.
Its network connection was normal.
Authorization had been completed.
The backend had also received a fault record, including the time, charger identity, connector status, and a vendor-defined error entry.
The problem was not that the charger had failed to report anything. Nor was the backend completely blind to what had happened.
The problem was that I first had to understand how this particular manufacturer defined the error.
I copied the error description into our internal knowledge base. There was no exact match. A second search returned maintenance records for an older software version. Only after opening the manufacturer’s service manual did I find a description that appeared relevant to the situation.
The record pointed towards an abnormal connection or locking status, but it could not tell me exactly where the problem had originated.
That reminded me of another site I had visited the previous month.
The charger there came from a different manufacturer. From the driver’s perspective, the symptoms had been almost identical: the cable was connected, authorization succeeded, but charging never began.
However, that charger had reported the incident under a different fault name. Its service manual also recommended a completely different starting point for the investigation.
On another occasion, a similar failed session had appeared as a timeout during charging preparation.
These incidents may have looked alike, but that did not mean they shared the same root cause. The problem could have come from the vehicle, the charger, or the exchange of status information between them.
That was exactly what made the job frustrating.
With equipment from different manufacturers, I not only had to diagnose the failure. I first had to understand how each manufacturer chose to name and record it.
The Same Symptom, a Different Investigation
I returned to the vehicle, rested the tablet against the steering wheel, and began working through the process.
First, I checked the charger model and software version.
Then I confirmed that I was using the correct service documentation.
Next, I reviewed the backend records around the time of the failure, looking for status changes and related warnings. I also searched earlier work orders for comparable incidents.
A search for “connector lock” returned one group of records. “Locking timeout” returned another. When I used the terminology preferred by a different manufacturer, the results changed again.
Some of these records might have described the same underlying problem. Others might merely have produced a similar symptom. I could not safely combine them or rely on experience alone.
Eventually, I organized the device information,现场 observations, and backend records and submitted them to the manufacturer’s technical support team.
They soon sent back a troubleshooting guide and asked me to verify a series of items according to the charger version.
Some of the required information was readily available in the backend. Other items required further examination of device records or another on-site test. I moved between the service manual, previous work orders, and backend pages, checking each item in turn.
More than twenty minutes had passed.
The fault had not become more serious.
But the actual repair had barely begun.
The Error Exists—But Everyone Speaks a Different Language
This is the problem CharIN is seeking to address through Unified Error Codes.
Modern chargers can generally detect faults and send related information to a backend system. However, different manufacturers may use different names, identifiers, and descriptions for those faults.
For a CPO operating equipment from multiple vendors, every additional brand can also mean another “fault dictionary.”
CharIN describes this as fragmentation in charging diagnostics. It creates additional integration and operational work for CPOs and charging management platforms, and it can force maintenance teams to spend more time establishing what an error actually means before diagnosing it. The issue is explained in greater detail in the CharIN Unified Error Codes project manifesto.
Unifying error codes does not simply mean replacing every manufacturer’s number with a new universal number.
The more important objective is to help vehicles, chargers, and backend systems describe a problem more consistently and provide the basic context needed to investigate it.
Engineers will still need to inspect equipment. They may still need support from the manufacturer. But they should not have to begin every investigation by learning a new error language.
Why Is a Pilot Still Necessary?
CharIN is preparing a Unified Error Codes pilot planned for 2027.
According to CharIN, the pilot will examine how fault information can travel from the EV to the EVSE and then to the CPO backend. It will test whether that information remains consistent, understandable, and useful after passing through different devices and systems. More information is available through CharIN’s official LinkedIn page.
It may not sound like a dramatic industry breakthrough.
It does not increase charging power or reduce charging time. It simply attempts to help the vehicle, charger, and backend speak a language they can all understand when something goes wrong.
For the engineer standing at the charging site, however, that could make a practical difference:
Similar incidents could be found more quickly.
An error could make it clearer which supporting information should be checked.
Historical cases from different charger brands could become easier to compare.
Unified error codes will not perform the repair automatically. But they could allow the real investigation to begin sooner.
Back at the Charger That Wouldn’t Start
After receiving the manufacturer’s troubleshooting guide, I checked the site conditions again and gathered the additional information required for the next step.
The investigation had to continue.
A unified error code cannot repair a mechanical component, and it cannot replace engineering judgement. Complex failures will still require experience, measurements, and physical inspection.
But if the vehicle, charger, and CPO backend can use more consistent fault definitions, I may no longer need to spend so much time establishing whether different systems are describing the same problem.
For a small site operating chargers from a single manufacturer, the difference may not be immediately visible.
But when a CPO manages multiple generations of equipment across dozens of models and brands, every new diagnostic “dialect” eventually becomes another mapping table, another service manual, another work-order process, and another conversation with a supplier.
An additional twenty minutes for one charger may not seem significant.
When the same work is repeated across thousands of chargers, it stops being a question of one engineer’s patience.
It becomes a question of repair time, network uptime, and drivers’ trust in public charging infrastructure.
Before leaving the site, I recorded the symptoms, charger status, and next steps in the work order. Then I placed an out-of-service notice on the charger.
As I walked away from the bay, I looked back at it.
The charger had not remained silent.
It had already reported an error.
We simply still needed a dictionary written specifically for that charger to understand what it was trying to tell us.
Note: The opening scenario is a dramatized composite based on common public charging-network operations. It does not refer to a specific CPO, charger brand, or actual fault event.