I work on EV-charger operations for a utility subsidiary in Thailand. For a long time our DC fast chargers failed in ways the OCPP status codes never explained: the car is plugged in, the screen says "connecting", and then the session just ends. The charger reports nothing wrong.
So we started listening to the conversation itself. A DC charging session is a dialogue between the car and the charger over the charging cable: first SLAC pairing of the power-line modems (ISO 15118-3), then the DIN 70121 / ISO 15118-2 message exchange that negotiates parameters, checks isolation, pre-charges and finally delivers current. Capture that PLC/V2G traffic and you can see exactly where a session dies and which side ended it.
This post is about what those captures showed, and the open-source tool that came out of it: EV Charger Fault Detection AI (MIT).
The data
The captures come from EGAT's DC charging fleet: 212 stations, 40,542 charging sessions, 44,198 packet captures. A pipeline decodes each capture with TShark and the dsV2Gshark dissector, splits it into charging sessions and turns every session into a stream of 33 features. The 41 GB of session data can't be published, but the pipeline, the labelling rules, the tests and every result file are in the repository.
What actually fails
Of 5,986 labelled fault sessions across all 212 stations:
| Fault family | Sessions | Share |
|---|---|---|
| No Power Delivered | 1,691 | 28.2% |
| Protocol Failed | 1,401 | 23.4% |
| SLAC Failure | 1,161 | 19.4% |
| Session Abort | 1,009 | 16.9% |
| EV Error | 435 | 7.3% |
| EVSE Fault | 270 | 4.5% |
| Comm Freeze | 19 | 0.3% |
About 4 in 10 "charger faults" are communication problems (a failed DIN 70121 / ISO 15118-2 exchange, or SLAC pairing that never completes), not broken hardware. That changes what a technician should check before driving to the site.
Five detectors, one hold-out
We built five detector architectures and scored them on the same held-out split: 8,820 sessions (1,326 fault, 7,494 normal) from 45 stations the models never saw.
| Detector | Idea | Score | Recall | False alarms |
|---|---|---|---|---|
| Traditional AI | fleet-tuned rules + XGBoost + Isolation Forest | 69.6 | 82.5% | 24.5% |
| Agentic AI | goal-driven agent with per-station memory | 66.9 | 85.1% | 31.0% |
| Multi-Agent | five specialist agents with a coordinator | 60.2 | 70.1% | 25.0% |
| AI Agent | tool-using agent with an evidence board | 46.4 | 49.3% | 35.0% |
| RL / DQN | policy trained on the replay, no rule layer | 39.2 | 18.5% | 5.6% |
Score = 50·recall + 30·(1 − false-alarm rate) + 20·earliness. A fault counts as caught when the first alert comes no later than 10 s after it.
Three lessons
1. The standard helps, but not evenly. In an ablation on an earlier snapshot of the data, adding a rule layer indexed against the 773 normative requirements of ISO 15118-2 lifted the evidence-fusing agents (AI Agent +6.6, Multi-Agent +6.2) but barely moved Traditional AI (+1.1). The RL arm moved by exactly 0.0, which is the control that shows the harness doesn't leak.
2. SLAC lives outside part 2. SLAC failures are invisible to an ISO 15118-2 rule book, because PLC matching is defined in ISO 15118-3. One rule measured off the wire, a CM_SLAC_MATCH.REQ left unanswered while the session has no V2G traffic (healthy matches answer in about 7 ms), recovered 72–87% of that fault family for +0.1–0.2 percentage points of false alarms.
3. Label quality mattered more than the standard. Requiring positive evidence for "session abort" removed 141 false "faults" that were really captures ending at a ring-buffer boundary. That was 20% of all faults, and the change alone reordered the leaderboard.
The tool our technicians use
The Windows app, iMPS Fault Detection, is in the repository and on the releases page. Open a .pcap of a DC session and it shows the verdict, the fault family, the packet-level evidence (for example goal 'dialog OK' failed: FAILED_SequenceError), the probable cause with the related standard and protocol phase, and which side stopped the session. Wireshark/TShark and the dissector are bundled and the analysis runs offline.
The app runs the Agentic AI detector rather than the top scorer, because it has the highest recall and returns evidence and a probable cause with every alert, which is what a technician needs on site. It is in use at 220 stations, and operators outside our company have started using it too.
Try it, or help
- Windows installer: latest release (the offline installer is about 231 MB and needs no internet).
- Research code:
ev_charger_ai/has the packet-to-session pipeline, the 33-feature tracker, the ISO 15118-2 and SLAC rule layers, the five detectors and the benchmark harness. A PyPI package,ev-charger-ai, is being prepared. - Docs: the README is in English, Thai, Japanese and Chinese.
- First issues: make the test suite pass in a single pytest run (good first issue) and run the pipeline on Linux or macOS (help wanted).
The most useful thing you could send me is an interoperability report from a charger brand or car we haven't seen. Please don't attach captures that contain vehicle identifiers, station names or locations to a public issue; describe them instead.
Repository: https://github.com/SukritJaAIproject/EV_Charger_Fault_Detection_AI
