ISO 15118-20 is not an update of ISO 15118-2. It is a second application layer with its own message set, its own security rules and new energy-transfer services, running on the same cable, the same power-line link and the same TCP/IP stack. A charger that must serve both generations runs two protocol stacks. A vehicle team that must pass both tests twice. This guide walks through the protocol the way a test engineer meets it: in the order the messages arrive.
What ISO 15118-20 is
ISO 15118 is the family of standards for the high-level communication between an electric vehicle and the charging station. The vehicle side is the EVCC (electric vehicle communication controller), the station side the SECC (supply equipment communication controller). Part 20, published in 2022 and amended in 2026, defines the "2nd generation network layer and application layer requirements". The parts you meet on a DC bench:
| Part | What it covers | Where you meet it |
|---|---|---|
| ISO 15118-1 | Use cases and general requirements | Reading, not testing |
| ISO 15118-2 | First-generation application layer (2014) | Installed base, AFIR from January 2026, NACS/J3400 |
| ISO 15118-3 | Physical and data link layer: HomePlug Green PHY, SLAC | Needs a modem; hardware bench |
| ISO 15118-20 | Second-generation application layer (2022, Amd 1 2026) | This guide |
| ISO 15118-4, -5 | Conformance tests for -2 and -3 | Accredited laboratories, pre-compliance |
| ISO 15118-21, ISO/PAS 15118-23 | Conformance test identifiers for -20 (DC; AC in progress) | Campaign planning |
The common connector family is CCS (Combined Charging System), but the protocol does not care about the plug: SAE J3400 (NACS) carries the same DIN 70121 and ISO 15118 traffic, and the Megawatt Charging System uses ISO 15118-20 over 10BASE-T1S Ethernet instead of power-line communication.
Why a second generation exists
- Bidirectional power transfer (BPT). Discharging the vehicle into a building or the grid needs limits, setpoints and schedules in both directions. ISO 15118-2 had none of this.
- Security is no longer optional. TLS 1.3 with mutual authentication is mandatory, older algorithms are removed, and the certificate profile is fixed in Annex B. Both sides present certificates; a vehicle without a valid certificate does not get a session.
- Dynamic control. Besides Scheduled mode, where the vehicle follows a negotiated schedule, Dynamic mode lets the station send single setpoints that the vehicle follows, which is how most smart-charging back-ends want to work.
- More than one contract. Plug & Charge can carry several contract certificates at once.
- New energy-transfer services. Wireless power transfer and automated connection devices (bus pantographs) have their own services; Amendment 1 (July 2026) adds the MCS service and an AC distributed-energy-resource service.
Two dates drive demand for this knowledge in Europe. Under the Alternative Fuels Infrastructure Regulation (AFIR), newly installed publicly accessible charging points must support ISO 15118-2 from 8 January 2026, and ISO 15118-20 from 1 January 2027. Sources differ on whether the 2027 rule reaches DC points or only Mode 3 AC points; read the regulation text for your case rather than a vendor summary, including this one.
The stack underneath, and where a software bench starts
The order on a real cable: the station drives the control pilot at a 5 % duty cycle to announce that digital communication is available. The vehicle's modem runs SLAC (signal level attenuation characterisation) to pair with the right station and join its logical network. Both sides take IPv6 link-local addresses. The vehicle multicasts an SDP request; the station answers with its address, port and whether TLS is required. The vehicle opens TCP, then TLS, and the application layer begins with SupportedAppProtocol. From there on, every message is an EXI-encoded XML document wrapped in a V2GTP frame.
For a test engineer the dashed line matters more than the layer names. Above it, a SECC or an EVCC is a program that listens on or connects to a port. That is what makes a software bench possible, and it is also why a software bench cannot say anything about SLAC, cable attenuation or pilot timing.
A DC session, message by message
ISO 15118-20 DC with external identification (EIM: the driver authorises with an app or a card, not with a certificate) is the sequence most teams test first. Each row is a request from the vehicle and a response from the station.
| # | Message pair | What is decided | What a tester watches |
|---|---|---|---|
| 1 | SupportedAppProtocol | Which protocol and schema version both sides speak | A -2-only station answers with the -2 namespace; the fallback path |
| 2 | SessionSetup | Session ID, EVCCID, EVSEID | Resumed vs new session; time stamp sanity |
| 3 | AuthorizationSetup | Which authorisation services the station offers (EIM, PnC) | Certificate installation offered or not |
| 4 | Authorization | The driver is authorised (EIM) or the contract certificate is accepted (PnC) | Processing = Ongoing loops and their timeout |
| 5 | ServiceDiscovery · ServiceDetail · ServiceSelection | DC, DC_BPT, AC …; the parameter set (connector, control mode, mobility needs, pricing) | Scheduled or Dynamic is chosen here, by the vehicle, from what the station offers |
| 6 | DC_ChargeParameterDiscovery | Vehicle limits (voltage, current, power) and station limits | Limits that make later targets impossible |
| 7 | ScheduleExchange | Scheduled: the schedule(s); Dynamic: departure time, energy requests | Renegotiation later in the loop |
| 8 | DC_CableCheck | Station performs the isolation test; vehicle waits | Result and duration; on a software bench the result comes from the plant model |
| 9 | DC_PreCharge | Station brings its output to the vehicle's present battery voltage before the contactors close | Voltage error at contactor closing |
| 10 | PowerDelivery (Start) | Vehicle asks for power; station closes contactors | State transitions and their timeouts |
| 11 | DC_ChargeLoop (repeated) | Targets and limits each way, present values, status flags | Setpoint tracking, pause requests, renegotiation triggers |
| 12 | PowerDelivery (Stop) | Charging stops; current to zero | Ordering: current first, then contactors |
| 13 | DC_WeldingDetection | Vehicle checks that its contactors opened | Voltage decay as seen by the vehicle |
| 14 | SessionStop | Session ends or pauses | Pause vs terminate, and what a resume must look like |
The standard attaches a timeout to every request, a performance time to every response, and a sequence timer to the whole exchange. Most failures a bench finds in the first week are not protocol errors but timing: a response that arrives after the vehicle gave up, or a CableCheck that takes longer than the vehicle will wait. A trace with time stamps on both sides is therefore the first artefact worth keeping.
Scheduled versus Dynamic control
In Scheduled mode the station offers one or more schedules in ScheduleExchange, the vehicle picks one and then drives the charging loop itself within the limits of that schedule. In Dynamic mode the vehicle states its needs (departure time, energy requests) and the station sends a single target per loop message, which the vehicle follows. The vehicle chooses the mode during service selection, from the modes the station offers. Renegotiation of a schedule is initiated by the vehicle during the loop. The difference shows up in what a test must prove: setpoint tracking and ramp behaviour in Dynamic mode, schedule adherence and renegotiation handling in Scheduled mode.
Security: TLS 1.3 and the certificate profile
ISO 15118-20 requires TLS 1.3 with mutual authentication. Both sides present certificate chains that follow the Annex B profile, and the handshake is limited to a short list of cipher suites and named groups. A practical consequence: a peer that offers only a P-256 curve is refused before any V2G message is exchanged, which looks like a network problem until you read the TLS alert. There are no session tickets and no resumption in the profile. Behind the certificates stands a public-key infrastructure with a V2G root, operator sub-CAs and leaf certificates for each station; for test work, free non-productive PKIs exist, including one with an ISO 15118-20 root.
What "testing ISO 15118-20" can mean
Five statements are often collapsed into "we support ISO 15118-20". Keeping them apart is what makes a report reviewable:
- Implementation coverage: which messages and behaviours the software implements.
- Executable test coverage: which test-case identifiers from ISO 15118-21 or ISO/PAS 15118-23 have an execution binding on your bench.
- Live-stack readiness: which lanes have run against a real peer or a plant.
- Interoperability evidence: recorded sessions with named external devices.
- Formal conformance: an accredited laboratory's result under the applicable certification scheme.
A software bench delivers the first three and, with a real device on the other side, the fourth. Nobody but an accredited laboratory delivers the fifth. Laboratories accredited for full ISO 15118-20 conformance are few and booked months ahead, which is the practical argument for doing the first four well before the slot.
How this is done with ChargeLink
ChargeLink runs the ISO 15118-20 DC EIM session in both roles: as the charger (SECC) against a vehicle under test, or as the vehicle (EVCC) against a charger under test, in Scheduled and Dynamic control, with TLS 1.3 mutual authentication and the Annex B certificate profile. The protocol stack is real: SDP, TCP, TLS 1.3, V2GTP and a native EXI codec, not a scripted message list. On the qualified bench the charger side is coupled to a plant model running in NI VeriStand 2024 through an FMI 2.0 FMU, so CableCheck, PreCharge voltages and the charge loop are computed from simulated measurements at 500 Hz rather than replayed (how the VeriStand bench is built).
Every run produces a message sequence chart, a time-stamped trace and an evidence manifest with a SHA-256 hash per file, so a result can be reviewed, replayed and compared with a golden reference run. The command line prints JSON and stable exit codes for CI; a versioned gRPC API drives it from a test controller. The first golden reference run is a software-only ISO 15118-20 DC session on one PC, which is how an installation is proved before anything is connected (how the charger or the vehicle is simulated).
Frequently asked
Is ISO 15118-20 backwards compatible with ISO 15118-2?
No. The two application layers are different protocols that share the lower layers. A charger that must serve both generations runs two stacks and lets the vehicle choose through SupportedAppProtocol.
Does a -2 charger need new hardware for -20?
Often yes. TLS 1.3, larger certificate chains and the bidirectional message handling need more processing and memory than many first-generation controllers have. The protocol itself does not say so; the market does.
Can I test ISO 15118-20 without a power-line modem?
Yes, for everything above the link layer. SDP, TCP, TLS 1.3, V2GTP, EXI and the whole message sequence run over ordinary Ethernet between two PCs or on one PC. SLAC and the control pilot need hardware.
What is the difference between EIM and Plug & Charge?
With external identification (EIM) the driver authorises outside the protocol, with an app, a card or free charging. With Plug & Charge the vehicle presents a contract certificate inside the session and the station validates it through the PKI.
Does a software bench prove conformance?
No. It produces engineering evidence and conformance-readiness results. Formal conformance is an accredited laboratory's result under the applicable scheme.