Most HIL laboratories already own NI VeriStand. What they do not own is a charging communication stack that can sit next to it and ask the plant model for voltages, currents and an isolation result at the moments the protocol needs them. This guide describes one way to build that bench: a charger (SECC) coupled to a VeriStand plant on one PC, a vehicle (EVCC) on a second PC, and an ISO 15118-20 DC session running between them over an ordinary Ethernet link. It is written from the bench ChargeLink ships for, and it says plainly what is simulated.
Why VeriStand for a charging bench
Three reasons come up in every programme. The laboratory's plant models, I/O and operator habits are already in VeriStand, so the charging controller becomes one more unit under test rather than a separate island. A deterministic real-time plant is what makes PreCharge and the charge loop meaningful: the voltage the charger reports must come from a model that reacts to the vehicle's targets, not from a replayed trace. And a VeriStand workspace gives the operator one place to watch contactors, present values and safety flags while the protocol runs.
What VeriStand does not give you is the protocol itself. SDP, TLS 1.3, V2GTP, EXI and the ISO 15118-20 state machine are an application-layer problem; they run in a separate process that talks to the plant through channels. The rest of this guide is about that coupling.
The two-PC layout
The split matters for two reasons. The protocol runs over a real network link with real IPv6 neighbour discovery, SDP and a TLS handshake, so the network-side behaviour is not a loopback shortcut. And the plant stays under VeriStand's clock: the engine runs at 500 Hz, the model steps at 1 ms, and the protocol process never touches model ports directly, only the user channels mapped to them.
The same layout works with a vehicle under test in place of the simulated vehicle. The charger side listens for an external EVCC on the link; which devices can complete a session is a matter for evaluation, not for a web page.
What the plant model contains
The plant is an FMI 2.0 co-simulation FMU of the DC power stage, the vehicle battery and the safety inputs. Its channels fall into six groups, and the group names are the vocabulary you use when you read a session's evidence:
| Group | Written by the charger stack | Reported by the model |
|---|---|---|
| Session state | session active, protocol ready, authorisation accepted, charge loop active, stop requested | — |
| Vehicle | target voltage, target current (from the vehicle's requests) | battery voltage, battery current, state of charge |
| Charger | voltage command, current command, power enable, contactor command, precharge command | present voltage, present current, present power, contactor closed, precharge complete, output ready |
| Safety | interlock closed, emergency stop, isolation valid (simulated inputs) | fault active |
| Fault injection | isolation fault, contactor fault, voltage deviation, current deviation, forced communication loss, reset | — |
| Command and sample identity | command age, sequence, epoch, checksums | sample sequence, accepted command, actual command age, checksums |
The last group is easy to overlook and is the one a reviewer will ask about. Every command frame carries a sequence number, an epoch and checksums, and every sample reports which command it applied and how old that command was. A stale or corrupted exchange is therefore visible in the evidence, not hidden inside a plausible-looking voltage. The checksums detect corruption; they do not authenticate anyone.
Six parameters (vehicle and charger maximum voltage, current and power) keep the model's start values and are not mapped. Ten of the plant channels are also exposed as canonical signals over the gRPC API, for example the vehicle's target voltage and the charger's present current, so a test controller can read them without knowing VeriStand channel paths.
How a DC session flows through the bench
- Discovery and handshake. The vehicle finds the charger with SDP on the link, opens TCP and completes a mutual TLS 1.3 handshake with ISO 15118-20 Annex B certificates. No channel moves yet.
- Negotiation. SupportedAppProtocol, SessionSetup, authorisation with external identification, service discovery and selection, DC charge-parameter discovery and schedule exchange. The charger's limits come from a runtime profile; the vehicle's from its case file.
- CableCheck. The charger asks the plant for an isolation result. On this bench the result is a simulated safety input; the message timing is real, the measurement is not.
- PreCharge. The vehicle's target voltage is written to the plant as a command frame; the model ramps the output; the present voltage comes back in the source frame and is encoded into the response. The vehicle sees the charger approach its battery voltage the way a real power stage would, at the model's pace.
- PowerDelivery and the charge loop. Contactors close in the model, and every charge-loop exchange carries the vehicle's targets down and the model's present values up. State of charge rises in the battery model. Each step is gated by the safety inputs and by the age of the last command.
- Stop, welding detection, session end. Current to zero, contactors open in the model, the vehicle checks the decay, the session stops. The owner host writes the session result and the evidence bundle into the run folder.
In an automated session the whole sequence runs from one script on each PC. In a manual session the operator sends the same steps as commands (apply safe start-up, start session, start the listener for an external vehicle, reset plant, shut down) and can read a status snapshot of the plant between them.
Timing: what 500 Hz means here
The VeriStand engine rate is 500 Hz with a 50 Hz data rate; the model steps at 1 ms; the broker that moves frames between the charger stack and the user channels runs on a 25 ms cycle. The VeriStand loops are pinned to dedicated logical processors so that other load on the PC does not disturb them. This is a software-in-the-loop timing profile: it is deterministic enough for repeatable PreCharge and charge-loop behaviour and for the protocol's timeouts, and it is not a claim about the latency of a physical power stage. Treat the 25 ms frame cycle as the resolution at which the plant can react to a protocol event, and plan test cases that depend on faster plant reactions for a different bench level.
Fault injection on the plant side
The fault-injection channels are the reason to couple a protocol stack to a plant rather than to a script. With them a test can make the isolation check fail during CableCheck, hold a contactor open when PowerDelivery asks for it, offset the present voltage during PreCharge, offset the current during the charge loop, or cut the communication path and watch both sides time out. Each case produces a trace in which the protocol's reaction is visible next to the plant's state, and a reset channel returns the plant to its safe start-up profile between cases. Combined with the vehicle-side case files (a nominal session and an emergency transition), this gives a small but honest fault matrix for a first campaign.
Safety authority on a simulated bench
Even with nothing physical attached, the bench keeps the habit that matters later: the protocol process never owns the plant. An owner host applies a safe start-up state before anything runs, supervises the safety inputs and the command age at every step, drives the plant to its safe state on a fault, and is the only component that writes to the user channels. When the same architecture is extended with real I/O, the safety controller and the power electronics keep physical authority and the simulator still only asks.
Setting it up
The set-up is a one-time, five-stage procedure per bench. Nothing is built in VeriStand: the system definition, the plant model and all 44 mappings are delivered and deployed by the owner host for every session.
- Check PC1. NI VeriStand 2024 installed and licensed on a Windows 11 PC with at least 13 logical processors (three are reserved for the VeriStand loops), the .NET runtime for the owner host, the C++ runtime, 20 GB of disk for run folders. The manual lists the hashes of the NI files the bench was verified with; a different NI build is recorded, not assumed.
- Unpack and verify. Every file in the package is checked against a SHA-256 manifest before first use, and the executable's signature is checked.
- TLS material. Either your own ISO 15118-20 Annex B chains and keys, or an engineering bench PKI generated once on PC1 and marked as engineering-only in every certificate subject. The package contains no certificate and no key.
- Firewall and bench configuration. Three inbound rules on the link adapter only (SDP on UDP, TLS on TCP, ICMPv6 for diagnostics); then a script records the adapter, its link-local address, the TLS files and the NI folder, and a validate-only run renders and checks a session configuration without starting anything.
- PC2 and the link. The vehicle side needs only Windows, PowerShell and the C++ runtime. It gets its TLS files, and a probe-only start confirms it can reach the charger before the first session.
After that, a session is one script on PC1 and one on PC2. The run folder holds the rendered configuration, the trace, the session result and the evidence manifest with a hash per file.
What to watch during a session
Three views are enough for most debugging. The VeriStand workspace, for the plant: present voltage and current, contactor and precharge state, the safety flags and the fault-injection channels. The message sequence chart or the trace, for the protocol: which request is outstanding and how long it took. And the operator status channels, for the bench itself: engine running, broker connected, gRPC healthy, session running, last error code, heartbeat. When a session fails, the first question is which of the three stopped moving first.
How this is done with ChargeLink
Everything above describes the bench ChargeLink ships for. ChargeLink runs the charger side of a full ISO 15118-20 DC session with external identification, plant-coupled on NI VeriStand 2024, in Scheduled and Dynamic control, with mutual TLS 1.3 and the Annex B profile; the vehicle side runs as the ChargeLink EVCC on the second PC or as an external vehicle on the link. The package delivers the VeriStand system definition, the FMI 2.0 plant FMU, the channel contracts, the operator scripts, the runtime profile and the case files; you provide NI VeriStand, the runtimes, the PCs, the link and the TLS material. Every run leaves a manifest with a SHA-256 hash per file, a time-stamped trace and a printable result, and the gRPC API exposes the ten canonical plant signals to a test controller.
Frequently asked
Do I have to build anything in VeriStand?
No. The system definition, the plant model and all channel mappings are delivered ready to deploy. You install NI VeriStand and the runtimes, verify the package, create TLS material, record the bench configuration once, and run sessions from scripts. You can open the system definition in System Explorer to inspect it; saving it from there changes its hash and must be recorded.
Is real charging hardware involved?
No. The DC power stage, battery, contactors, isolation result and safety inputs are simulated by the plant model in VeriStand. No power-line communication, control pilot or power electronics is part of the bench.
Can the simulated vehicle be replaced by my own EVCC?
The charger side listens for an external vehicle over the dedicated link, so an EVCC under test can take the place of the simulated vehicle. Whether a given device can run a full session is confirmed during a scoped technical evaluation.
Can I add NI I/O for the control pilot or CAN later?
The architecture keeps the plant under VeriStand and the protocol in a separate process precisely so that I/O can be added on the VeriStand side. Which I/O, and when, is not part of the delivered package and is discussed per project.
Why two PCs and not one?
One PC with a loopback pair is enough for software regression and is how a first session is proved. Two PCs put the protocol on a real link with real neighbour discovery, SDP and TLS, and keep the VeriStand loops on dedicated processors away from the vehicle process.