EV Charger Fault Reporting: The Incident Data Operators Need Before a Reset

Start with the operating context.

Capture the exact message before interpreting it: code source, full wording, timestamp and time zone, charger and connector identity, session or transaction ID, vehicle model and approximate state of charge, connector standard, authorization method, operating state and visible external condition. For OCPP 1.6, preserve StatusNotification status, errorCode, info, vendorId and vendorErrorCode when present. OCPP 2.0.1 uses component-oriented NotifyEvent data instead of the OCPP 1.6 errorCode field. Never merge these with a charger-screen code or vehicle DTC from another manufacturer.

Good commercial charging decisions connect vehicle use, site conditions and the operator's intended service. The selected equipment can then be reviewed against the final technical, commercial and destination-market requirements.

Planning checklist.

• Immediate danger signs and whether the equipment must be isolated
• Exact code system, message, timestamp, charger, connector and session identity
• Vehicle, connector, authorization, network and environmental context
• Responsible team, evidence package and model-specific service documentation

Use an evidence ladder instead of one vague description.

1. Safety state: record smoke, fire, arcing, burning smell, abnormal heat, exposed conductors, collision damage or water ingress first. If any are present or uncertain, keep people away and escalate before collecting more data.
2. Exact user-visible symptom: preserve the complete screen or app wording and language without converting it into a guessed OCPP category.
3. Protocol evidence: for OCPP 1.6, retain status, errorCode and optional vendor fields. For OCPP 2.0.1, retain the event timestamp, component, variable, actual value, techCode and techInfo when implemented.
4. Asset and session context: charger model, firmware, station/connector identity, timestamp and time zone, session reference, vehicle model/year, state of charge, connector standard and authorization method.
5. Sequence and ownership: state what happened before and after the fault, which safe actions were attempted, whether it repeats, and which party owns the next evidence or service action.

Why regional or vendor codes need their own label.

Idaho National Laboratory's ChargeX work proposes Minimum Required Error Codes for the North American charging ecosystem. Its OCPP 1.6 examples place the CX... value in vendorErrorCode with an identified vendorId; OCPP 2.0.1 examples use techCode within event data. These proposed regional codes are useful context, but they are not an extra set of universal OCPP 1.6 errorCode values. Keep the field name, source and version attached to every code.

A generated brief must not invent completed actions.

Consider a desk-based example: an operator has a screen message and a station ID, but does not know whether the area has been secured or who received the escalation. A polished report that says “area isolated” turns an unfinished task into an apparent fact. Keep observations, required actions and confirmed completion separate.

1. Observed: retain the original message, its source and the available asset/session context. Write “unknown” for missing facts; do not guess a time zone or convert a screen code into a protocol category.
2. Required: assign the appropriate safety or service response without claiming it has happened. Smoke, fire, arcing, burning smell, abnormal heat, exposed conductors, collision damage or water ingress take priority: keep people away and contact the operator and local emergency services.
3. Confirmed: the responsible team records what it actually completed and when, in its controlled support record. A browser form cannot verify isolation, inspection, repair or restoration.

The incident brief builder now defaults danger and code source to unknown. Danger or unconfirmed safety produces escalation guidance before required-field validation, without a copyable report. Once no listed signs are reported and the privacy check is completed, the output is still a draft requiring review—not equipment clearance. Editing an answer removes the old output so an outdated report cannot be copied accidentally.

No one should approach a hazard, recreate a fault, reset equipment or open a cabinet to fill an evidence gap. Collect only existing, safe and authorized observations. Use the OCPP category reference only when the code system is established; it does not diagnose the failed component.

Three timestamps do not automatically make a proven sequence.

Illustrative desk-based example, not a customer case: a driver note says 14:32 with no time zone, a station record shows 14:31 UTC+01:00, and the backend records receipt at 13:36 UTC. The last two labels are five minutes apart after conversion, but that alone does not prove a five-minute outage or transmission delay: clock accuracy, record identity and the driver's time reference still need review.

1. Quote each clock separately: in the main time field, identify the primary observation and mark an unknown zone explicitly. Put each additional record on its own line in Notes, with its source and whether it describes an event, an observation or receipt.
2. Preserve the originals: keep the recorded time and zone beside any calculated conversion. If the offset or clock accuracy is unknown, say so rather than silently sorting records into an apparent cause-and-effect chain.
3. Check coverage: OCA explains that transaction messages can be buffered during offline operation; not all other message types have the same coverage, and behavior differs by protocol version and configuration. A gap in received records alone does not prove equipment was safe, idle or fault-free.
4. Assign the open question: ask the authorized operator to review existing clock, connection and record evidence. Do not reset, reconnect, recreate a fault or change configuration to complete this worksheet.

Example Notes entries, kept as separate lines:

• Driver observation: 14:32; zone unknown; original note retained.
• Station event: 14:31 UTC+01:00; clock accuracy unverified.
• Backend receipt: 13:36 UTC; event-to-receipt relationship under review.

The incident brief builder now preserves Notes line breaks in its preview and copied text. It does not reorder records, convert time zones or validate a timeline. Resetting or editing the form removes the previous report and copy button. Already copied material cannot be recalled: mark corrections clearly in the controlled support record. This workflow is our evidence-handling example, not an OCA timing requirement or diagnosis.

Correcting a connector ID after the report was copied

Editing the browser form clears its preview, but it cannot recall an earlier copy or update a report already sent. Make a correction visible to the receiving team rather than silently replacing an identifier. OCA distinguishes reports about a station from those about a specific connector; the identity attached to the evidence matters.

A fictional correction with an explicit scope

An operator copied a draft for station TEST-01 with connector 1. An authorized reviewer then checked an existing asset mapping and the matching session record and established that the reported event belongs to connector 2. This example assumes that review actually happened. If the mapping is still uncertain, record it as unresolved instead of making the substitution. Do not send commands or create another charging session to discover the correct identity.

1. Retain the correction trail: in the controlled support record, identify the earlier draft or case and preserve what it said. Record the corrected field, its previous and new values, the review evidence and the actual reviewer/time. Do not rewrite original device messages.
2. Regenerate deliberately: change Connector / EVSE ID to the verified value, then explain the amendment in Notes. Review the new preview and copy it explicitly. The builder does not number revisions, compare them, verify the mapping or update an existing clipboard automatically.
3. Notify the actual recipient: if the old version was sent, use the approved support channel to identify it and provide the correction. Record acknowledgement only when received. If it was only copied, do not claim it reached a support team.

Example Notes for the corrected draft

• Amendment to earlier TEST-01 draft: connector field changed from 1 to 2.
• Basis: existing asset mapping and matching session record reviewed by the operator.
• Scope: identifier correction only; code meaning, cause, repair and safety status not established by this change.
• Earlier copy may still exist; recipient notification and acknowledgement not yet recorded.

These are fictional entries, not facts to paste into a real incident. Use only confirmed evidence, the actual review time and permitted case references; keep sensitive source attachments in the authorized system. A privacy checkbox does not redact them for you. Keep screen text, vehicle DTCs, OCPP errorCode and vendor or technical fields separately labelled.

This amendment workflow is our coordination guidance, not an OCA-mandated versioning procedure. A corrected ID does not authorize a restart or release equipment for use. The danger and privacy checks still apply to the new draft. For smoke, fire, arcing, burning smell, abnormal heat, exposed conductors, collision damage or water ingress, keep people away and contact the operator and local emergency services. Do not approach to collect evidence. Electrical diagnosis belongs to qualified personnel; no force, energized work or protective bypass is authorized.

Prepare and review the corrected incident draft ↗

Sanitize the brief before it leaves the operator's system.

Use the minimum identifiers necessary for the authorized service team. Remove card numbers, security codes, passwords, access tokens, personal IDs and full VINs. Attach external-condition photographs and backend logs only when collection and sharing are safe, permitted and relevant. The browser tool does not transmit the form automatically; the operator decides whether and where to copy it.

Copying a brief is not a completed handoff.

The incident brief builder formats the facts you enter. It does not send a message, open a support ticket or check whether anyone has received the report. Its copy button confirms a clipboard operation only. A draft can be ready to share while the receiving team still has no record of it.

Consider a fictional desk handover: an operator copies a charger report before leaving a shift. A colleague sees the draft and assumes it has reached the equipment supplier. Neither person has checked an approved support channel or a case reference. The missing fact is not another fault code; it is whether the report was actually sent and acknowledged. Do not fill that gap with an assumption.

1. Draft: review the exact source wording, asset and connector identifiers, original time zones and missing facts. Remove unnecessary personal identifiers, full VINs, payment data, passwords and access tokens. The privacy checkbox is a manual confirmation, not automatic redaction.
2. Copied: the text is on the clipboard after a successful copy operation. It has not been sent by this tool. If copying fails, select the text manually; do not mark the handoff complete.
3. Sent: use the operator’s approved support channel and authorized recipient. In that controlled system, record the actual send time and time zone, recipient or receiving team, and case reference if one exists. A sent record alone does not establish that a person has reviewed it.
4. Acknowledged: record the receiving team’s actual acknowledgement and any agreed next owner or follow-up. If receipt is unconfirmed, say so and follow the operator’s escalation process. Acknowledgement is not a root-cause diagnosis, completed repair or permission to return equipment to service.

Keep support-system references and attachments in the authorized channel; do not publish private case links or credentials in a community post. A missing acknowledgement is not evidence of a charger defect and does not justify a reset, repeat charging attempt or physical intervention.

This checklist is original coordination guidance, not an OCA-mandated ticket workflow or response-time promise. OCA’s uptime paper explains why charging-chain evidence may come from different parties; it does not make this browser tool a support integration. Electrical diagnosis belongs to qualified personnel using the exact equipment documentation. If there is smoke, fire, arcing, a burning smell, abnormal heat, exposed conductors, collision damage or water ingress, keep people away and contact the site operator and local emergency services.

How this applies to a commercial charging project.

Xiaochong provides a browser-based incident brief builder for preparing a local draft. Copying exports text to the clipboard, not to a support team; sending and acknowledgement must be recorded through the operator’s approved support process. The company can also discuss EVSE analyzer configurations, English technical documentation, test guidance, OCPP integration, commissioning and maintenance support for selected projects. Root-cause diagnosis and repair remain model- and site-specific.

Images and portfolio references are a useful starting point, but final technical data, dimensions, protection rating, certification, payment integration and delivery terms should be confirmed for the selected model and destination market.

Common buyer questions.

Primary technical sources.

OCA reporting guidance rechecked October 23, 2026, especially section 4.1.3 on station/connector scope and standard versus vendor fields. INL and OSHA remain background from the earlier review. The amendment workflow is original operator guidance, not certification or a manufacturer repair procedure. Product-specific instructions and local requirements control the final action.

• Open Charge Alliance — Improving Uptime Monitoring with OCPP v1.3 ↗
• Idaho National Laboratory / ChargeX — Minimum Required Error Codes ↗
• OSHA 29 CFR 1910.334 — Use of electrical equipment ↗