ChargeLink Native

EVCC Role Guide

In the EVCC role ChargeLink is the vehicle-side communication controller. It discovers the SECC through SDP or connects directly to a known IPv6 address and TCP port, negotiates the application protocol, runs the session with a simulated battery, and records every frame. This page covers what the EVCC can do and, equally important, what it cannot.

Capabilities at a glance

UseCommandPeerNotes
Validate configurationevcc start --dry-runnone 
Local EVCC-to-EVSE exchangeevcc local-loopback-smokeChargeLink EVSE in the same process over ::1Stops after service discovery by design
Probe a real SECC's transport and mutual TLSevcc tls-handshake-probeany SECCTransport and TLS only
Full ISO 15118-20 DC EIM sessionevcc activate-profile with the EV case files from the packageChargeLink SECC or third-party SECC accepting TLS 1.3 mutualRequires the EV case files (see below)
ISO 15118-2 DC EIM and DIN 70121 DC sessions with the ChargeLink SECCiso2-evcc, din-evccprofiles iso15118_2_dc_eim_evcc, din70121_dc_evccStandards-encoded one-session vehicle roles against the ChargeLink SECC (engineering lanes; see the ISO 15118-2 and DIN 70121 runbooks). The evcc start reference profiles for these protocols transmit ChargeLink's typed framing, which a real SECC does not decode.
Deterministic paired simulationsim paired, sim iso20-scenario, sim legacy-scenarioin-process twin 
Managed SIL pair over real loopback networkingintegration sil-smoke (gRPC)in-server 

Backends and battery models

chargelink --runtime-root "$Data\runtime" --artifact-root "$Data\artifacts" --json evcc backends
chargelink --runtime-root "$Data\runtime" --artifact-root "$Data\artifacts" --json evcc battery-models
chargelink --runtime-root "$Data\runtime" --artifact-root "$Data\artifacts" --json evcc profiles

Backends accepted by evcc start: native, loopback, direct-tcp. The other names listed (external-hlc, external-evcc-smoke, external-evcc-ipv6-regression, local-executable-loopback) identify the dedicated commands evcc external-smoke, evcc external-regression-pack and evcc local-loopback-smoke. There is no ethernet backend; using it fails with CL-CONFIG-001.

Battery modelBehaviourInputs
constant_power_reference (default)Charges at the requested power until the target SoC--battery-capacity-kwh (77), --initial-soc-pct (32), --target-soc-pct (80), --requested-power-kw (150), --battery-step-seconds (30)
ramp_referenceTapers requested power near the target SoC

Both models are simulation references only; they do not model cell chemistry or thermal behaviour.

Discovery: SDP or direct TCP

  • SDP (standard flow). --use-sdp --interface-index N on activate-profile, or the default transport mode of evcc start. The EVCC multicasts an SDP request to ff02::1 on UDP 15118 through the given interface and connects to the address and port in the response.
  • Direct TCP. --peer-ipv6 fe80::...%N --tcp-port P without --use-sdp on activate-profile (on evcc start add --no-sdp). Bypasses discovery; useful to isolate transport problems. Add --probe-peer to TCP-probe first and --connect-timeout-ms (default 250) for slow links.

The zone index after % is always the index of the adapter on this machine. Copying the peer's own zone index produces "unreachable network".

Transport and TLS probe

chargelink --runtime-root "$Data\runtime" --artifact-root "$Data\artifacts" --json evcc tls-handshake-probe `
  --protocol iso15118-20 --profile-id iso15118_20_dc_evcc_reference `
  --peer-ipv6 'fe80::<SECC>%' + $IfIndex --tcp-port 50118 --connect-timeout-ms 1000 `
  --tls --tls-cert "$Pki\vehicle-chain.pem" --tls-key "$Pki\vehicle-key.pem" --tls-cafile "$Pki\v2g-root-ca.pem" --require-ca `
  --tls-server-name chargelink-secc.local

The probe connects, completes the TLS 1.3 handshake, waits a bounded settlement time and closes. It sends no SDP, no V2GTP and no EXI. The status field reports what the SECC decided; the process exit code only reports whether the probe itself ran. Negative probes (untrusted vehicle certificate, untrusted root, missing client certificate) are the fastest way to prove the SECC's certificate policy.

Live ISO 15118-20 DC EIM session

The live session runs the 14-step DC EIM vector with real SDP, TLS 1.3 mutual authentication, V2GTP and standards-encoded EXI. The EVCC refuses to run without two files that name every operating value explicitly; both are delivered in the package's pc2\cases folder, and their EV values are test values, not a vehicle implementation.

  1. Set CHARGELINK_ISO20_LIVE_SEMANTIC_CASE to an EV case JSON, for example pc2\cases\nominal.json (vehicle identity and electrical parameters).
  2. Set CHARGELINK_ISO20_FULL_WIRE_SESSION_MANIFEST to the full-wire session manifest pc2\cases\full-wire-session-manifest.json.
  3. Run evcc activate-profile with profile iso15118_20_dc_evcc_reference, TLS material and --max-steps 14.

The exact command lines are in the ISO 15118-20 runbook. The live case file contains: evcc_id (ISO 15118-20 Annex C format with check digit), present/precharge/target voltage, target current, power, EV maximum and minimum power, current and voltage, profile duration, maximum supporting points, tolerances, emergency safe limits, precharge and charge-loop timeouts. Any non-positive electrical value or an invalid EVCCID check digit is rejected before the first packet is sent.

Local loopback smoke

chargelink --runtime-root "$Data\runtime" --artifact-root "$Data\artifacts" --json evcc local-loopback-policy
chargelink --runtime-root "$Data\runtime" --artifact-root "$Data\artifacts" --json evcc local-loopback-smoke --protocol iso15118-20 --profile-id iso15118_20_dc `
  --peer-ipv6 '::1' --tcp-port 50118 --max-steps 6

Runs an EVCC and an EVSE inside one process. Expected result: SessionSetup and ServiceDiscovery processed, six EVCC steps, artifacts with EXI captures. This is the fastest installation health check and the recommended first step in every support case.

External simulator harness

evcc external-smoke starts a third-party EVCC simulator process you name with --simulator-command and --simulator-arg, waits for it, and records the outcome against the given peer. evcc external-regression-pack runs the standards-oriented IPv6 regression set (--profile-set standards-ipv6-core, an optional diagnostic IPv4 case). Both are engineering harnesses for integrating an external simulator into your evidence flow.

Lifecycle

chargelink --runtime-root "$Data\runtime" --artifact-root "$Data\artifacts" --json evcc status
chargelink --runtime-root "$Data\runtime" --artifact-root "$Data\artifacts" --json evcc list-state
chargelink --runtime-root "$Data\runtime" --artifact-root "$Data\artifacts" --json evcc stop
chargelink --runtime-root "$Data\runtime" --artifact-root "$Data\artifacts" --json runtime list --role evcc

The EVCC uses the same session directory layout and role lock (active\evcc.lock.json) as the EVSE. One EVCC session per runtime root.

Evidence produced by the EVCC

session.json (backend, peer, port, TLS, protocol stack, status), summary.json (required versus observed states), protocol_session.json (executed steps, battery snapshot), protocol_summary.json (sdp/tcp/tls/v2gtp observed flags), expected_sequence.json and observed_live_sequence.json, conformance_traceability.json (blocked claims), diagnostics.json (missing states and operator action), traces\evcc-loopback.jsonl, traces\live-v2gtp-frames.jsonl, evcc_message_trace.jsonl, manifest.json. Certificate and key paths are recorded in protocol_session.json; key material is never copied.