How do you test ISO 15118-20 Plug & Charge and bidirectional charging on an EVSE?

ISO 15118-20:2022 specifies EV–EVSE communication, including bidirectional sequence requirements. Amendment 1:2026 is published and adds service and security changes. State the base edition and agreed amendment before selecting cases. [1] ISO 15118-20:2022 [2] ISO 15118-20:2022/Amd 1:2026

1. Create a service matrix. List the implemented energy-transfer services, authentication modes, control modes and transfer directions. Associate each with firmware and the released library configuration.
2. Prepare controlled credentials. Use a test credential environment with recorded trust anchors, certificate validity and device time. Keep production credentials out of diagnostic data.
3. Verify negotiation and authorisation. Run the intended service and authentication path first. Capture service selection, security outcome and the transition to the allowed charging state.
4. Test failure paths independently. Use supported invalid/expired credentials, unsupported service requests and interrupted sessions as separate cases. Verify the expected rejection or recovery and absence of unintended energy transfer.
5. Test each supported direction. For bidirectional transfer, verify sign conventions, negotiated limits and measured direction using suitable source/sink equipment. Include a controlled stop and a fresh session.

123

1. 1Test requirement: selected case, PICS and PIXIT.
2. 2Device state: live CP values in the status bar.
3. 3Result workflow: Test Procedure; no verdict is visible in this capture.

Practical tip. Store the service-selection trace and a non-secret fingerprint of the test credential set with each result. Redact private keys and customer identifiers before sharing diagnostics.

Define the supported service before testing it

Separate the communication version from the individual service you intend to exercise. Record the negotiated profile, authentication mode, intended energy-transfer direction and the counterpart role. Include the software and test-library release that implements the selected cases. A normal charging session proves that session under those conditions; it does not establish every Plug & Charge or bidirectional function. Build the acceptance matrix around the services required by the project, then mark unsupported or untested items explicitly. This keeps a broad protocol label from becoming a wider conformity statement than the available evidence supports.

Control the credential and environment conditions

For authentication cases, keep the certificate and trust configuration with the test recipe. Distinguish a protocol failure from an unavailable supporting service or a different trust setup. Record the initial conditions, the expected successful path and the agreed rejection behaviour for the selected case. Use suitable test credentials and preserve the relevant certificate identities and configuration without publishing secrets in a report. Repeat the baseline when the environment changes. That comparison helps show whether a different result comes from the charging implementation, the configured credentials or another dependency in the authentication path.

Evaluate direction changes at the electrical interface

For bidirectional cases, specify the power equipment and the quantities the test will measure as well as the messages it will observe. Confirm that the configured setup supports the intended direction and operating conditions. An accepted communication request and a measured energy-transfer response are separate observations. Link them on the time base used for evaluation. State the applicable requirement and decision rule for each case rather than assigning one verdict to the entire bidirectional feature. Keep interface, power and library boundaries visible in the result so that a communication test is not interpreted as a complete grid or installation assessment.

Example: a service is offered but not selected

In an illustrative investigation, the station offers an expected service but the counterpart does not select it. Compare service negotiation, authentication state and the configured profile before testing electrical power behaviour. Re-run an unchanged baseline, then vary the single negotiation or credential condition justified by the diagnosis. Once the service is selected, evaluate its subsequent sequence and measured response separately. Retain the messages that establish the offered and selected services in the report. This example defines a diagnostic question; it does not provide normative timeout values, certify a credential infrastructure or establish support for every ISO 15118-20 option.