ChargeLink
DEP docs ↗Developed byDEVlink

ChargeLink User Documentation

ChargeLink is an EV charging communication test platform. It plays one side of a charging session so that you can test the other side: your vehicle, EVCC or on-board charger, or your charger or SECC. It speaks ISO 15118-20, MCS (ISO 15118-20 over 10BASE-T1S), ISO 15118-2, DIN 70121 and IEC 61851-23/-24 System A (CHAdeMO), records tamper-evident evidence of every session, and exposes everything through one command-line tool and a gRPC API.

One application, one role per session. In a session ChargeLink is either the charger (EVSE/SECC), with your vehicle, EVCC or on-board charger as the device under test (DUT), or the vehicle (EV/EVCC), with your charger or SECC as the DUT. The main use is ISO 15118-20 DC charging with external identification (EIM) in both roles, in Scheduled and Dynamic control mode, with an optional NI VeriStand 2024 plant model as the simulated power stage. ChargeLink results are engineering evidence, not certification; see Capability Boundaries.

This manual is written for operators, test engineers, integration engineers and administrators who receive the installed ChargeLink customer package. Normal operation does not require any developer tooling.

Documented version. CLI syntax on this site matches chargelink version 0.5.0 (Integration API chargelink.integration.v1 version 1.8.0). Run chargelink --version and compare before you copy a command into a controlled procedure. See the Release and Version Matrix.

New user? Follow this path

Recommended path for a new ChargeLink Native workstation 1Overviewwhat is in the package 2Install and activateextract · data roots · license 3First DUT sessionrole · adapter · TLS · run 4First 60 minutessupportable baseline 5Bench preflightNIC · IPv6 · ports · PKI 6Protocol runbooklive session · evidence Steps 1, 2 and 4 need no device under test. Steps 3, 5 and 6 need the adapter to your DUT and, for ISO 15118‑20, TLS material.
The six steps of a new workstation. Each page on this path ends with a sign-off table.
  1. Product Overview — what the product does, which role it plays against your DUT, and what is in the package.
  2. Install and Activate — place the package, create the data directories, activate the license.
  3. First Session with Your Device Under Test — choose the role, connect your DUT and run one session.
  4. First 60 Minutes — leave the workstation in a supportable, documented state.
  5. Environment and Bench Preflight — check the NIC, IPv6, ports, certificates or CAN adapter before you connect a DUT.
  6. Select a Protocol — pick the runbook for ISO 15118-20, MCS, ISO 15118-2, DIN 70121 or IEC 61851-23/-24 System A (CHAdeMO).
  7. Golden Reference Runs — keep a known-good baseline for upgrades and troubleshooting.

Choose by task

I want to...Start with...
Install a new PCInstall and Activate → First 60 Minutes
Test my vehicle, EVCC or on-board chargerChargeLink as Charger → protocol runbook
Test my charger or SECCChargeLink as Vehicle → protocol runbook
Run ISO 15118-20 / MCS / ISO 15118-2 / DIN 70121 / CHAdeMOISO 15118-20, MCS, ISO 15118-2, DIN 70121, IEC 61851-23/-24 System A (CHAdeMO)
Set up TLS certificatesTLS and PKI
Check an installation, run a demo or a CI regression without a DUTSelf-test without a device under test
Plan and run protocol test campaignsTest Workflow → Test Package Catalog
Reproduce a result without hardwareDeterministic Simulation and Replay
Understand traces, manifests, reportsTrace, Evidence and Reports
Automate ChargeLink from another programgRPC Integration API → API Reference
Set up the NI VeriStand bench from the packageSet Up the VeriStand Bench
Run sessions on the VeriStand bench and read the resultNI VeriStand Bench
Fix a failureTroubleshooting
Open a support caseSupport Escalation
Check what ChargeLink does and its limitsCapability Boundaries
Look up exact CLI syntaxComplete CLI Reference

Command convention

Examples use Windows PowerShell 5.1 or later and call chargelink from PATH (Install and Activate, step 2). Every command passes the two data roots explicitly; most pages begin with this block, which defines the paths the examples use:

$CL   = 'C:\ChargeLink\<VERSION>\charger\bin\chargelink.exe'
$Data = 'C:\ChargeLinkData'

chargelink --runtime-root "$Data\runtime" --artifact-root "$Data\artifacts" --json license status

The kit has a charger\ and a vehicle\ folder. Both folders contain the same chargelink.exe, so the ChargeLink PC runs either role from either copy.

Why every command carries the roots: without --runtime-root and --artifact-root, ChargeLink writes its state to a .chargelink folder inside the current working directory. Two shells started in different folders would then see different sessions and different evidence. Passing the same roots on every command avoids that; the global options may be written before or after the subcommand. The license store is derived from the runtime root: with the roots above, the activated license lives in C:\ChargeLinkData\licenses.

Values shown as <LIKE_THIS> are placeholders and must be replaced. Profile IDs and package IDs are release-specific; chargelink --json profile list and chargelink --json conformance packages list on the installed machine are the final authority.

How this manual is organised

  1. Why am I doing this? — purpose and prerequisites of each task.
  2. What exactly do I do? — copy/paste commands with expected results.
  3. What do I do when it fails? — checkpoints, failure isolation and support evidence.

Every capability page states its claim boundary: what a passing result proves and what it does not prove. ChargeLink produces engineering and conformance-readiness evidence; it does not issue accredited certification. See Standards and Claim Boundaries.

HomeTop