Advanced Diagnostics for OCPP

As the complexity and criticality of electric vehicle (EV) charging infrastructure increases, the need for robust and transparent diagnostic capabilities in charging stations and other OCPP enabled devices becomes paramount. Currently, the Open Charge Point Protocol (OCPP) lacks a standardized mechanism to explicitly define, trigger, and monitor e.g. self and integration tests within its device model and message set. This gap leads to proprietary extensions, inconsistent implementations, and reduced interoperability across manufacturers and management systems on top of the specified generic device model reporting, diagnostic and logging mechanisms.

An explicit diagnostics model, tightly integrated into the OCPP device model and messsage framework, would enable charging station operators to reliably enumerate, parameterize, and execute a wide range of diagnostics — ranging from simple software integrity self checks, over complex hardware validation routines to integration tests within the charging station operator network. By describing available tests, their required parameters, operational constraints, intermediate reports, and expected outcomes in a machine-readable and discoverable manner, operators gain better tools for remote maintenance, troubleshooting, and regulatory compliance.

Importantly, self tests should not only be accessible for manual execution by human operators or for periodic automated routines, but also be available to intelligent software agents and AI-based diagnostic systems. Such agents can proactively trigger or sequence self tests in response to anomalies, performance degradation, or security incidents, enabling more effective root cause analysis and faster problem resolution within the charging infrastructure.

Moreover, standardized test models support automation of periodic health checks, real-time fault isolation, and evidence-based reporting for quality assurance and cybersecurity audits. It also facilitates seamless backend integration, future-proofing OCPP deployments against evolving reliability and safety requirements in critical infrastructure like the upcoming European Network and Information Systems 2 (NIS2) Directive. Therefore, the introduction of a formal self test model in OCPP and related protocols is essential for improving the transparency, resilience, and maintainability of EV charging networks.

Scope

This subchapter provides a differentiation between various diagnostic test types that can be performed by charging stations and other OCPP devices. By clearly outlining the purpose and scope of each test type, this section ensures consistent terminology and lays the foundation for advanced diagnostics and automated monitoring of the entire charging infrastructure.

Current State of the Art

This chapter gives a short overview which kind of diagnostic functions are already available within the current OCPP v2.1 version.

GetBaseReport

GetReport

GetLog

LogStatusNotification

TriggerMessage

Note: OCPP 2.1 introduces extendable types to include e.g. "SelfTest" or "HealthCheck" as triggerable messages, but (optional) parameters on triggers are missing.

EventNotification

Diagnostic Control

New Diagnostic Control requests provide a standardized mechanism to remotely read and manipulate the internal state of components such as charging stations. This extension is designed specifically to support advanced testing, simulation, and validation workflows during development, deployment, or maintenance.

It enables simulation of physical interactions, like the swiping of an RFID card, entirely through software. This allows triggering of typical sequences like RFID UID detection, authorization, and initiation of a charging session without requiring physical presence or hardware interaction.

Beyond behavioral simulation, Diagnostic Control may also permit direct manipulation of internal system state, including the setting of Device Model Variables that are normally read-only under standard OCPP access control policies. This allows validation of edge cases, failure modes, or system behavior under specific manipulated conditions that would otherwise be difficult or impossible to reproduce.

Unlike traditional OCPP requests, Diagnostic Control requests are not part of the normal operational interface, but instead serve as diagnostic and testing tools. These requests and their corresponding responses follow the same message structure as regular OCPP operations. However, they are distinguished by the strong requirement for digital signatures, verifiably issued by an entity that holds explicit Diagnostic Control access rights.

This cryptographic enforcement ensures that only authorized diagnostic tools or operators can issue such requests. As a result, it is considered safe and compliant to keep this interface active even in production environments, since misuse by unauthorized parties is effectively prevented through cryptographic validation.

GetExecutingEnvironment

This request returns information about the executing environment of the software under test. Especially when an embedded software is run within an emulator or a multi-user operating system and it hangs within an endless loop or crashed in unexpected ways, it is usefull to find out more details about its executing environment. By this for example the process identifiction might be retrieved to be able to kill -9 and to restart the process. Also alternative ways to initiate a hard restart or to download a memory image might be exposed.

OCPP v1.6

GetExecutingEnvironmentRequest:

GetExecutingEnvironmentResponse:

The response can contain any data the executing environment wants to share with the user that optionally signed the request. This also means, that different users might see different information. It is good practise to describe the collection of data via a JSON-LinkedData (JSON-LD) @context property.

OCPP v2.x

GetExecutingEnvironmentRequest:

GetExecutingEnvironmentResponse:

The response can contain any data the executing environment wants to share with the user that optionally signed the request. This also means, that different users might see different information. It is good practise to describe the collection of data via a JSON-LinkedData (JSON-LD) @context property.

AdjustTimeScale

This request is a diagnostic extension to OCPP that enables external test tools or validation frameworks to temporarily alter the rate at which simulated time progresses within a charging station or associated components. This feature is particularly valuable in testing scenarios that depend on elapsed time, such as the automatic stop of a charging session after a specified duration, authorization timeouts, or inactivity handling. By accelerating or decelerating the passage of time for internal logic, long-running tests can be executed significantly faster, or timers can be frozen for controlled debugging.

The request specifies a timeScale value, which is a positive decimal number representing the multiplier applied to simulated time. A value of 1.0 indicates normal time progression, while a value of 2.0 causes internal time to progress twice as fast as real time. A value of 0.5 slows time down by half, and a value of 0.0 effectively pauses all time-based logic in the affected domain. To prevent unintended permanent changes, the request may optionally include a duration parameter (in seconds), after which the time scale automatically reverts to the normal value of 1.0.

This request is intended solely for testing and validation purposes in non-production environments. Charging stations operating in production mode may reject this request unless explicitly configured to permit it under controlled conditions. The response to such a request includes a status field indicating whether the operation was accepted, rejected, or not supported, and may optionally return the actually applied time scale, which might be capped or adjusted internally for implementation or safety reasons.

OCPP v1.6

AdjustTimeScaleRequest:

AdjustTimeScaleResponse:

OCPP v2.x

AdjustTimeScaleRequest:

AdjustTimeScaleResponse:

TimeTravel

This request enables controlled manipulation of the system clock on a charging station or related component. Unlike the AdjustTimeScale request, which affects only the relative flow of internal time, TimeTravel allows the system to temporarily jump forward or backward in time, for example to simulate behavior under certificate expiration, daylight saving changes, authorization token expiry, dynamic tariff changes, or to validate metrological timestamp boundaries. Optionally, it may also define a duration, after which the system clock reverts to the original (real) time source. If no duration is specified, the simulated time remains active until explicitly reset or overridden by a subsequent request.

This request is intended solely for testing and validation purposes in non-production environments. Charging stations operating in production mode may reject this request unless explicitly configured to permit it under controlled conditions.

OCPP v1.6

TimeTravelRequest:

TimeTravelResponse:

OCPP v2.x

TimeTravelRequest:

TimeTravelResponse:

Charging Station Diagnostics

SetErrorState

This request simulates an Error State within the entire charging station or within one of its EVSEs. When the charging station for example detects an upstream grid supply anomaly like undervoltage, overvoltage, or a phase failure, is must log, report and propagate this error state to one or more of its EVSEs. These EVSEs can then enter a PowerQualityError or GridFault state and signal the reduced-availability or fault indication via the Control Pilot (CP) to the EV. As a consequence, the charging process may be paused, limited, or aborted, depending on the error severity and the EV's response strategy.

OCPP v1.6

SetErrorStateRequest:

SetErrorStateResponse:

OCPP v2.x

SetErrorStateRequest:

SetErrorStateResponse:

SwipeRFIDCard

This request simulates the swiping of an RFID card triggering RFID UID detection, authorization, and maybe the start of a charging session without requiring physical presence or hardware interaction. The same mechanism can also be used to terminate an active charging session, either by simulating the swipe of the same RFID card used to initiate the session, or by simulating a swipe of another card that belongs to the same authorization group.

OCPP v1.6

SwipeRFIDCardRequest:

SwipeRFIDCardResponse:

OCPP v2.x

SwipeRFIDCardRequest:

SwipeRFIDCardResponse:

SetResidualCurrent (ToDo)

Detects AC/DC leakage currents (e.g., ground faults) by comparing incoming/outgoing current; trips power if imbalance exceeds thresholds (e.g., 6mA DC or 30mA AC). Types: A (AC + pulsating DC), B (full AC/DC including smooth DC). Often paired with RDC-DD for DC monitoring.

(see also: IEC 62955)

SetInsulationResistor (ToDo)

An Insulation Monitoring Device (IMD) monitors the insulation resistance between the electrical system (e.g., DC lines) and ground to detect faults like short circuits or degradation that could lead to electric shocks or fires.

(see also: IEC 62955)

SetTemperature (ToDo)

Monitors charging station and/or ambient temperatures to prevent overheating.

SetDoorOpen (ToDo)

Some charging station manufacturers have a simple "door open" sensor.

SetIntrusionDetection (ToDo)

Some charging station manufacturers have some sort of "Intrusion Detection", that disables the charging station until explicitly "unlocked" by service personal.

CCS Diagnostics

The following messages define diagnostics for the Combined Charging System (CCS).

AttachCable

This request simulates the connection of a detached charging cable to the EVSE socket of an AC charging station.

The request includes a Proximity Pilot (PP) resistor value, which represents the EV driver's AC charging cable maximum permissible current according to IEC 61851-1 and IEC 62196-2. This resistor is physically located within the plug between PP and PE. The EVSE uses a voltage divider to detect the maximum allowed current of the cable by placing a voltage (typically +5 V) on the PP line via a pull-up resistor. The EVSE then reads the resulting voltage and infers the PP resistor value. The following lookup table translates the resistor value to the maximum allowed current.

Even when to charging cable is first connected to the EV and afterwards to an EVSE socket of a charging station, the attachment of this cable does not imply that an EV will be detected.

OCPP v1.6

AttachCableRequest:

AttachCableResponse:

OCPP v2.x

AttachCableRequest:

AttachCableResponse:

GetPWMValue

This request retrieves the current value of the Pulse Width Modulation (PWM) signal generated by the EVSE's Control Pilot. The PWM duty cycle represents the maximum allowable charging current as defined by IEC 61851-1 and is used by the EV to determine the upper limit of the energy it may draw from the EVSE. Reading this value allows diagnostic systems to verify the dynamic current limits being communicated by the charging station to the vehicle in real-time, which is essential for safe and standards-compliant operation.

OCPP v1.6

GetPWMValueRequest:

GetPWMValueResponse:

OCPP v2.x

OCPP v2.x might prefer setting up a Device Model reporting.

GetPWMValueRequest:

GetPWMValueResponse:

SetCPVoltage

IEC 61851-1 defines charging states called: A, B, C, D, E, F. They indicate whether the vehicle is connected, ready to charge, charging, or in a fault state.

The EV communicates its charging intend to the EVSE by modifying the voltage on the Control Pilot (CP) pin. Voltages are measured between the CP line and protective earth (PE) with a typical ±0.5 V tolerance.

For AC charging a Pulse Width Modulation (PWM) signal within the states B, C, and D indicates the maximum current the EVSE can supply. The duty cycle of the PWM correlates to the available current.

DC charging a high-level digital communication according to DIN 70121, ISO 15118-2 or ISO 15118-20 is used.

The following table shows all legal transitions between EV Charge Pilot states.

  +-----+     Plug-In      +-----+    Contactor Close    +-----+
  |  A  | ---------------> |  B  | --------------------> | C/D |
  +-----+                  +-----+     Supply Energy     +-----+
     ^                       | ^                            |
     |        Unplug         | |      Pause Charging        |
     +-----------------------+ +----------------------------+

OCPP v1.6

SetCPVoltageRequest:

SetCPVoltageResponse:

OCPP v2.x

SetCPVoltageRequest:

SetCPVoltageResponse:

SendEVMessage

This message sends an ISO 15118 data structure, as if they would be send by an electric vehicle.

This method uses the OCPP v2.1 SEND message type, therefore there will be no direct response to this message. Nevertheless, when the the charging station can not parse this message, an error message might be send.

Text Message Format

The ISO 15118 message can be encoded as JSON, when only the processing of the messages shall be tested, or as Efficient XML(EXI) or even Ethernet frames, when lower layer parsing shall also be tested.

SendEVMessage (text):

Binary Message Format

A more efficient way of sending binary data is to make use of HTTP WebSocket binary frames.

SendEVMessage (binary):

MCS Diagnostics

The following messages define diagnostics for the Megawatt Charging System (MCS). This new system is conceptually similar to the old Combined Charging System (CCS), but instead of Pulse Wide Modulation (PWM) and Power LAN Communication (PLC) it uses Single-Pair Ethernet (Multi-Drop 10BASE-T1S, IEEE 802.3cg / IEEE 802.3-2022) to communicate with the EV (ISO 15118-10) and possible other auxiliary devices between EVSE and EV. Those devices can be e.g. micro controllers, temperature, and coolant flow sensors within the charging plug and cable.

Due to the extreme voltages and currents involved, both IEC 61851-23-3 and SAE J3271 mandate rigorous monitoring of errors (state E) and faults (state F) such as cooling system failures, overtemperature, or unexpected cable disconnections. To ensure compliance, test procedures must explicitly validate system behavior in these failure scenarios. This includes verifying the correct transition into state E/F and ensuring that any hazardous conditions immediately trigger safe shutdown procedures, physical interlocks, and remote fault notifications.

Given these requirements, the use of OCPP v2.1+ is strongly recommended as it provides Charging Station Operators (CSOs) a detailed device model and real-time event stream architecture, which is required for safety, compliance, and operational continuity of critical infrastructure.

SetCEVoltage

The Charge Enable (CE) pin replaces the Charge Pilot (CP) pin of CCS, but has a similar approach to signal the current charging state (A, B, C, D, E, F) of the electric vehicle via discrete voltage levels. The voltage is measured between Charge Enable and the Protective Earth (PE), with a typical tolerance of ±0.5 volt.

The following table shows all legal transitions between EV Charge Enable states.

  +-----+     Plug-In      +-----+    Contactor Close    +-----+
  |  A  | ---------------> |  B  | --------------------> | C/D |
  +-----+                  +-----+     Supply Energy     +-----+
     ^                       | ^                            |
     |        Unplug         | |      Pause Charging        |
     +-----------------------+ +----------------------------+

SetCEVoltageRequest:

SetCEVoltageResponse:

SetIDVoltage

The Insertion Detection (ID) pin detects, whether a cable is plugged into an electric vehicle or not. The exact voltage levels are not standardized, just a value range is specified. Most implementations use +5V or +12V.

SetIDVoltageRequest:

SetIDVoltageResponse:

SendSPEMessage

This message sends an ISO 15118 or IEC 61851-23-3 data structure over the Single-Pair Ethernet (10BASE-T1S), as if they would be send by the electric vehicle or other embedded electronics, e.g. within the charging cable. As multi-drop 10BASE-T1S is a half-duplex protocol the EVSE is specified as dedicated "bus master" which coordinates the Physical Layer Collision Avoidance (PLCA) on the communication bus.

After the ID-Pin confirms the EVSE-to-EV connection and the EV signals state B via the Charge Enable-Pin, the EVSE provides auxiliary power to the cable’s communication module(s) and sends a discovery message via 10BASE-T1S to identify connected devices (IEC 61851-23-3).

Alternatively the auxiliary power can be always on, to monitor whether the charging cable "still exists". This helps to detect "cable theft", a common costly problem for Charging Station Operators (CSOs) worldwide.

According to ISO 15118-20 and IEC 61851-23-3 IPv6 with Link-Local Addressing must be used for the 10BASE-T1S communication, aligning it with automotive Ethernet standards. There is a dedicated 10BASE-T1S network per EVSE. Charging stations with multiple EVSEs have to support IPv6 Link-Local Routing with additional ethernet/EVSE device information.

The standards also define, the EVSE (SECC) as the initiator of the Single-Pair Ethernet communication, with cable electronics and EV (EVCC) only responding to EVSE requests. Yet, during charging states C or D, the EV and cable continuously monitor and report conditions like coolant temperature, flow rate, or electrical faults. If a fault is detected, e.g., coolant leak or overheating, the EV or cable sends an unsolicited alert, triggering a transition to fault state E or F. The microcontrollers use dedicated time slots for this kind of urgent communication.

Currently the cable communication is not yet standardized, but such a cable information might look like this:

{
  "cableId":           "MCS-3000A-LC-001",
  "cableCertificate":  "0x00...",
  "maxVoltage":         1250,
  "maxCurrent":         3000,
  "coolingType":       "liquid",
  "coolantStatus":     "operational",
  "temperature":        25.5
}

Text Message Format

The ISO 15118 message can be encoded as JSON, when only the processing of the messages shall be tested, or as Efficient XML(EXI) or even Ethernet frames, when lower layer parsing shall also be tested.

SendSPEMessage (text):

Binary Message Format

A more efficient way of sending binary data is to make use of HTTP WebSocket binary frames.

SendSPEMessage (binary):

Diagnostic Monitoring

Diagnostic Monitoring shall allow e.g. CPOs to monitor the communication of for example a charging station with internal and external connected devices like the electric vehicle (ISO 15118 communication), energy meters (Modbus RTU/TCP/UDP), time servers (NTP/NTS) and so on.

Important for efficient monitoring and to avoid an overload of the charging station to CSMS connection are monitoring filters and the ability to support more than one monitor for each device or communciation flow.

GetDiagnosticMonitorDevices

This request will return a list of all devices or communication flows, that support Diagnostic Monitoring and their mandatory and optional configuration parameters.

GetDiagnosticMonitorDevicesRequest:

GetDiagnosticMonitorDevicesResponse:

MonitoringDevice:

ToDo: Would a mapping to the device model make sense?

SetupDiagnosticMonitor

This message sends some ISO 15118 data structure as if they would be send by an electric vehicle. Maybe JSON encoding, as this is for testing anyway. Maybe also EXI when also lower layer decoding shall be tested.

SetupDiagnosticMonitorRequest:

SetupDiagnosticMonitorResponse:

DisableDiagnosticMonitor

DisableDiagnosticMonitorRequest:

DisableDiagnosticMonitorResponse:

Diagnostic Tools

Diagnostic Tools are small asynchronous applications running e.g. on the charging station for self- and integration testing and diagnoses. They follow the concept of AI applications using the Model Context Protocol (MCP) and thus might not only return a single response, but also multiple intermediary responses or status updates.

These tools might be very vendor specific and AI agents should be able to consume then without requiring external tool specifications. Therefore all tools provide their own extensive meta data about their input and output data formats.

Ping

Send one or multiple ICMP echo request to the specified DNS name or IP address. Optional with the Record Route extension.

Traceroute

Trace the IP route to the specified DNS name or IP address using the traceroute approach.

TestCSMSNetworking

This tool will test whether the network configuration to access a CSMS is complete, free of contradictions, report TLS parameters and test whether the tools can successfully log into the (new) CSMS. This will in particular avoid costly downtimes caused by CSMS migrations which often fail because of unexpected configuration or network issues.

TestNetworkTimeSecure

This tool will test whether the configured Network Time Secure time server are configured correctly (complete, free of contradictions) and the time server can be reached. The last response will also include the NTP/NTS time information received.