From OCPP Logs to Field-Ready EV Charger Diagnostics

EV charger logs are rich, noisy, and frustratingly indirect. A failed charging attempt may include authorization messages, connector status changes, meter readings, retries, missing responses, vendor-specific fault codes, and a transaction lifecycle that only makes sense after reconstruction.

The logs can usually tell us what happened. Field operations need something harder: why it happened, whether it affected charging, whether it is station-side or external, and what a technician should do next.

Our first instinct was to treat this as a language problem. We gave noisy OCPP logs to an LLM and asked for a diagnosis. The summaries were useful. But for repair decisions, useful was not enough. We needed repeatable, evidence-backed conclusions that could survive field use.

That pushed us toward a different architecture: deterministic diagnosis first, bounded AI second.

Why OCPP Logs Are Hard to Diagnose

Many networked EV chargers communicate with a backend system using the Open Charge Point Protocol, or OCPP. OCPP gives charging stations and central management systems a common way to exchange operational messages: heartbeats, connector status updates, transaction starts and stops, meter readings, remote commands, configuration changes, and diagnostics.

That common protocol shape is valuable, but it does not make diagnosis simple.

A single user-visible symptom, such as “charging failed to start,” can come from payment authorization, network connectivity, a connector latch issue, charger firmware behavior, a power module fault, or vehicle-side communication. The evidence is distributed across time. One log line is rarely enough.

Vendor fault codes add another layer. OCPP defines standard message types, but charger manufacturers often add proprietary diagnostic codes. Those codes may appear as numbers, hex values, text labels, or vendor-specific payloads, and the same physical problem can be described differently across manufacturers. Without grounded vendor context, a plausible explanation may still be the wrong repair action.

That is the real gap: the person fixing the charger usually does not need a raw log dump. They need a repair decision that explains what was observed, why it matters, and what to inspect first.

Why We Tried an LLM First

The LLM-first prototype was valuable because it proved that raw OCPP logs could be translated into something operators could understand. An LLM could summarize long sessions, highlight suspicious events, and turn protocol chatter into plain language.

But diagnosis is not the same as summarization.

An LLM could notice that charging failed after a connector fault, but still miss the operational evidence that matters: whether the transaction lifecycle was broken, whether the station rebooted mid-session, whether the fault repeated across sessions, or whether the vendor code had a documented repair action. It could produce a plausible explanation, but plausibility is not enough when the output may trigger a truck roll.

We also ran into a practical systems constraint: many failures did not need an LLM at all. Rules, lookups, and state transitions could explain them faster and more consistently.

The prototype taught us the real requirement: operators did not need prettier logs. They needed evidence, confidence, impact, and action.

Deterministic Evidence First

The architecture that emerged was less like a chatbot and more like an evidence pipeline. Instead of asking an LLM to infer everything from raw logs, the system first extracts what it can know directly.

%%{init: {
  "theme": "base",
  "themeVariables": {
    "fontFamily": "Inter, ui-sans-serif, system-ui, sans-serif",
    "fontSize": "15px",
    "primaryTextColor": "#0f172a",
    "lineColor": "#475569",
    "edgeLabelBackground": "#ffffff",
    "clusterBkg": "#f8fafc",
    "clusterBorder": "#cbd5e1"
  },
  "flowchart": {
    "curve": "basis",
    "htmlLabels": true,
    "rankSpacing": 35
  }
}}%%
flowchart TB
    accTitle: From raw OCPP logs to field-ready technician guidance
    accDescr: Raw OCPP logs pass through deterministic protocol interpretation, validation, vendor fault-code matching, and evidence ranking. The evidence can produce technician guidance directly or use bounded AI assistance for clearer language.

    LOGS["Raw OCPP<br/>logs"]
    DET["Deterministic analysis<br/><br/>Protocol parsing + session reconstruction<br/>State + transaction validation<br/>Vendor fault-code matching"]
    EVIDENCE["Ranked evidence<br/>packet"]
    AI["Bounded AI assistance<br/>clarity + consolidation"]
    BRIEF["Field-ready<br/>technician brief"]

    LOGS --> DET --> EVIDENCE
    EVIDENCE -->|direct guidance| BRIEF
    EVIDENCE -.->|when useful| AI
    AI -.->|language only| BRIEF

    classDef input fill:#e8f1f5,color:#12365a,stroke:#4f789d,stroke-width:1.5px;
    classDef process fill:#ffffff,color:#0f172a,stroke:#94a3b8,stroke-width:1px;
    classDef evidence fill:#ecfeff,color:#164e63,stroke:#0891b2,stroke-width:2px;
    classDef optional fill:#f8fafc,color:#475569,stroke:#94a3b8,stroke-width:1px,stroke-dasharray:5 4;
    classDef output fill:#ecfeff,color:#164e63,stroke:#0891b2,stroke-width:2px;

    class LOGS input;
    class DET process;
    class EVIDENCE evidence;
    class AI optional;
    class BRIEF output;

Protocol parsing turns raw logs into structured OCPP messages. Session reconstruction asks whether the message sequence represents a successful charging session or a failed attempt. State and transaction validation look for consistency problems: suspicious connector transitions, starts without stops, stops without starts, duplicate active transactions, missing responses, or metering data that appears outside a valid session.

These are not language problems. They are protocol and state problems.

Vendor fault-code matching then adds manufacturer context. We rank matches by how well they are grounded in documentation and observed protocol evidence. Documented vendor matches carry the most weight. Similar-looking errors can help investigation, but they are not enough on their own to produce a high-confidence repair recommendation.

The goal is not to maximize findings. The goal is to identify the finding that should change what someone does next.

Semantic Similarity Is Not Diagnosis

We also experimented with semantic search for vendor-code matching. The idea was reasonable: vendor documentation uses inconsistent language, and similar physical faults can be described differently across manufacturers.

In practice, the results were not good enough for this workflow. Many charger faults share words like “timeout,” “connector,” “communication,” or “power” while requiring very different field actions. A semantic match could look plausible while pointing to the wrong repair path.

So we stopped treating semantic search as diagnostic evidence by itself. It could still help surface candidates during investigation, but exact vendor documentation, normalized code matching, protocol evidence, session impact, and state-machine findings carried more weight.

Turning Evidence into Repair Guidance

After the system identifies evidence, the important question is not “how many issues did we find?” It is “which findings should change what someone does?”

Some signals are station-side repair candidates. Some explain the incident but do not require station work, such as vehicle behavior or user-triggered stops. Some are transient and should be monitored for recurrence. The system scores findings along operational dimensions: whether charging was affected, whether the issue appears station-side or external, whether remote recovery is plausible, whether onsite work is justified, and how strong the evidence is.

The final output is not a raw error list. It is a compact repair brief: what was observed, why it matters, whether charging was affected, what the technician should inspect first, and how to verify the station is healthy afterward.

Across several days of logs, a connector repeatedly moved into and out of a faulted state. Viewed individually, the events were ambiguous: generic errors, power-electronics self-checks, and failed charging attempts. A later fault included humidity, isolation, and DC pilot-line warnings. By analyzing the complete timeline, Synergize connected these signals into a testable hypothesis: moisture may have been degrading electrical isolation, triggering protection faults and preventing charging. It recommended temporarily taking the connector out of service, inspecting and drying its connector and seals, and verifying insulation resistance before returning it to service.

This is where AI can add value, but it is not required for every diagnosis. The deterministic pipeline produces the evidence packet: what happened, which sessions were affected, which vendor documentation matched, which state or transaction rules were violated, and how confident the system is. When that evidence is sufficient, the system can produce technician guidance directly. When ambiguity remains—or clearer communication would help—AI can consolidate related symptoms and translate the grounded evidence into clearer operator or contractor language.

The LLM became a language and synthesis layer, not the diagnostic authority.

The Broader Lesson

In technical conversations, people often get stuck on whether to use an LLM or not. That framing is too narrow. The better question is which parts of the problem need repeatable evidence, and which parts benefit from flexible reasoning or communication.

The lesson was not that LLMs do not belong in infrastructure diagnostics. They do. But they belong behind evidence. Protocol parsers, state machines, transaction checks, vendor documentation, and confidence gates should establish what the system knows. AI can help explain that knowledge, connect ambiguous symptoms, and turn it into usable repair guidance. For physical infrastructure, the bar is not “sounds right.” The bar is repeatable, evidence-backed, and useful to the person doing the repair.