Simulator roles: EVSE, EVCC, and bench-linked execution
The fastest way to understand ChargeLink is to separate what is under test from what ChargeLink is simulating.
Key concepts
EVCC: the vehicle communication controller. In a real vehicle this is the communication side of the car.
EVSE / SECC: the charger-side communication controller and charging equipment behavior.
HIL: hardware-in-the-loop. The software session is linked to contactors, power controls, sensors, locks, cooling, and safety signals.
Bench proof: repeatable evidence captured from an instrumented bench, not only from the protocol trace.
When you run chargelink evse ...
ChargeLink behaves like the charger or SECC.
The EVCC side is external: a native ChargeLink EVCC reference profile, Josev, EVerest, or real vehicle hardware.
This is the main path for customer EVCC validation because the vehicle side is the system under test.
When you run chargelink evcc ...
ChargeLink behaves like the vehicle side, either natively or through an external adapter contract.
This is useful for loopback testing, backend adapter proof, differential testing, and lab automation.
It is especially helpful when you want to prove that a charger profile or campaign behaves correctly before bringing in an external EVCC.
When you run chargelink hil ... or chargelink capture mcs ...
You move from protocol-only testing to bench-linked execution.
The runtime still matters, but control actions, telemetry, interlocks, cooling, safe-stop handling, and evidence manifests become first-class outputs.
This is where MCS and claim-safe hardware evidence live.
How newcomers should choose a mode
Goal |
Recommended starting point |
|---|---|
Learn the product and inspect artifacts |
Start with |
Debug a charger profile or loopback session |
Use |
Run packaged protocol cases |
Use |
Prepare a release or customer bundle |
Use |
Prove hardware behavior |
Use |