"Simulation" covers three different things in charging communication, and they are worth keeping apart: a symbolic walk through the message sequence without a network, a real protocol exchange between two processes on one PC, and a real exchange between a simulator and a device under test over a cable. Each answers a different question. The mistake is to use the first as evidence for the third.
Why simulate the other side at all
An EVCC team cannot bring a DC charger into the office, and when it finally gets bench time, the charger is shared, slow to reconfigure and unsafe to drive into fault states on purpose. A charger team has the mirror problem: vehicles arrive late, each one is a different implementation, and none of them will time out at exactly the moment you want to test. A simulator that plays the missing role lets both teams run the sequence daily, inject the faults the standard anticipates, and keep a trace of every run. It also moves most of the debugging to before the first interoperability session, when the device under test still has an engineer sitting next to it.
What a simulator cannot do is tell you how the device behaves with a real counterpart. The five levels of evidence from the ISO 15118-20 guide apply: implementation coverage, executable test coverage, live-stack readiness, interoperability evidence, formal conformance. A simulator gives you the first three and prepares the fourth.
Three topologies
| Topology | What is real | What it proves | Typical use |
|---|---|---|---|
| One PC, loopback | TCP on the IPv6 loopback, V2GTP framing, EXI encoding, both roles in one or two processes | The installation, the stack and the profiles work on this machine | First session, CI regression, reproducing a sequence from a support case |
| Two PCs, dedicated link | IPv6 neighbour discovery, SDP multicast, the TLS 1.3 handshake, timing across a real adapter | The bench network and certificates work; sessions are repeatable at wall-clock timing | The qualified SIL bench; the charger coupled to a plant model |
| Simulator and device under test | One side is the customer's EVCC or SECC | Live-stack readiness and, when recorded with the device's identity, interoperability evidence | Development, pre-compliance, supplier acceptance |
A fourth mode sits beside these: a deterministic paired simulation that runs both roles as twins inside one process without sockets and writes a symbolic transcript of the message families and state transitions with a hash. The same scenario with the same seed produces the same transcript on any machine, which makes it the right tool for regression gates and for attaching a compact reproducer to a defect report. It records no wire bytes and proves nothing about a physical peer; it proves that the sequencing is stable.
What the simulated side needs to know
A simulated vehicle needs a battery: capacity, initial and target state of charge, the power it asks for, and a model of how those change per step. Two reference models are common: constant power until the target state of charge, and a ramp that tapers near the target. Neither models cell chemistry or temperature, and a guide that says otherwise about a software bench is overselling. A simulated charger needs limits: maximum voltage, current and power, the control modes it offers, and the schedule or setpoints it will send.
For the DC part of the sequence the charger also needs measurements. CableCheck wants an isolation result, PreCharge wants the output voltage to approach the battery voltage, and every charge-loop response reports present voltage, current and power. On a one-PC bench those come from a reference responder or a simple model. On a plant-coupled bench they come from a real-time model of the power stage and battery, which is what makes PreCharge and the loop behave like a charger instead of like a script. The NI VeriStand bench guide describes that coupling.
A first session, in the order that works
Whatever tool you use, the order below finds environmental problems before they look like protocol defects.
- Prove the installation without sockets. A self-check of the runtime and a profile listing, then a dry-run start of the charger role that validates the profile and prints the exact listener and vehicle commands for each protocol. Nothing listens yet.
- Loopback exchange on one PC. A vehicle and a charger over the loopback address with real TCP, V2GTP and EXI. On the ChargeLink bench this run stops after service discovery by design: it proves transport, framing and codec, not the charge loop.
- Deterministic simulation and replay. A paired simulation of a full DC sequence (session setup, schedule exchange, PreCharge, charge loop, stop) with a transcript hash, then a replay that must reproduce the same hash. If this fails, the installation changed.
- The automation surface. Start the local gRPC API, check its health and capabilities, and run a session through it. From here a test controller can drive the bench without a human at the keyboard.
- Preflight for a real link. Record the software identity, pick the bench adapter (not the Wi-Fi, VPN or virtual adapter with the lowest index), confirm IPv6 is bound and a link-local address is preferred, check that nothing else owns the SDP and V2GTP ports, and validate certificates. A live preflight writes an artefact and still starts no listener.
- A full session over the link. The charger listens for an external vehicle; the vehicle discovers it through SDP or connects to a known address and port. For ISO 15118-20 the handshake is mutual TLS 1.3, so both sides need their certificate chains before any V2G message.
The three things that fail first
- The adapter and the zone index. Link-local IPv6 addresses carry a zone index after the percent sign, and it is always the index of the adapter on the machine that uses the address. Copying the peer's zone index yields "unreachable network". A wrong adapter yields silence.
- Ports and the firewall. SDP uses UDP port 15118 and the charger advertises a TCP port for V2GTP. A firewall that filters inbound UDP on the bench adapter blocks discovery; a stale listener that still owns the TCP port blocks the session. Check both before reading a single trace.
- Certificates. ISO 15118-20 refuses a peer before any V2G message if the chain does not validate or if the handshake offers no acceptable named group. A TLS handshake probe that sends no SDP, V2GTP or EXI, and its negative variants (untrusted vehicle certificate, untrusted root, missing client certificate), are the fastest way to prove a charger's certificate policy and to separate network problems from PKI problems.
Reading the result
A useful simulator leaves four artefacts per run: a message sequence chart or an ordered list of the request and response pairs with time stamps on both sides, the EXI captures, a JSON-lines trace, and a report with a verdict and a statement of what the run does and does not claim. The chart answers "where did it stop"; the time stamps answer "who was late"; the captures answer "what exactly was sent"; the claim statement answers the reviewer. Keep all four with the configuration that produced them.
Open-source and commercial options, honestly
Several open-source projects implement ISO 15118-20 and are worth knowing. EVerest (Linux Foundation Energy) is a full charger stack with ISO 15118-2 and -20 modules, built for charging stations rather than for test benches. Josev Community (Switch) and the EcoG iso15118 package are Python implementations of -2 and -20 that can start both roles; eVDriveFlow (EDF R&D) is a Python -20 implementation with TLS 1.3. The OpenChargingCloud projects provide a C# vehicle simulator and a conformance and interoperability test suite. pyPLC is the tool for the layer below: sniffing and driving the power-line link with cheap adapters. Their -20 coverage, licences and maintenance differ and change; read each repository before relying on it.
A commercial Windows tool earns its place when a team needs both roles with one procedure, a fault matrix and repeatability runs instead of hand-edited scripts, evidence that a reviewer accepts, coupling to a real-time plant, and someone to call. It does not make the open-source stacks wrong, and a good bench uses an independent stack as a second opinion.
How this is done with ChargeLink
ChargeLink plays either side of an ISO 15118-20 DC session with external identification: the charger as a listener for a ChargeLink or external vehicle, the vehicle against a ChargeLink or external charger that accepts mutual TLS 1.3. All three topologies above are supported from the same executable: a loopback exchange and a managed SIL pair on one PC, the two-PC bench with the charger coupled to an NI VeriStand plant model, and sessions against a device under test. The deterministic paired simulation walks the DC sequence without sockets and replays to the same transcript hash. The command line prints JSON and stable exit codes; a local gRPC API with a per-start access token exposes sessions and signals to a test controller. Every run writes EXI captures, a JSON-lines trace, a report and a manifest with a hash per file.
Frequently asked
Can I simulate ISO 15118-20 on one PC?
Yes. A charger and a vehicle can run on the IPv6 loopback interface of one PC with real TCP, V2GTP framing and EXI encoding, and a deterministic paired simulation can walk a full DC sequence without sockets. A full session over a real link needs a second PC or a device under test.
Is a simulated session proof of interoperability?
No. A session between two simulators proves the stack and the bench. Interoperability evidence is a recorded session with a named external device, and formal conformance is an accredited laboratory's result.
Do I need a power-line modem?
Not for the application layer. SDP, TCP, TLS 1.3, V2GTP and EXI run over ordinary Ethernet. SLAC and the control pilot need a modem or a hardware-in-the-loop charging interface and are not part of a software bench.
Can the simulator run without a licence for a first look?
The first-session tutorial in the ChargeLink manual needs no charging equipment, no licence and no administrator rights. Live protocol sessions are licensed; the evaluation agrees the scope.
Which side should I simulate first?
The side you do not build. An EVCC team simulates the charger; a charger team simulates the vehicle. Teams that build both start with the loopback pair and move one role to a second PC as soon as the certificates work.