Split ISO/DIN capabilities

[premultiply]

Refs #31807

What & why

The single iso151182 device capability lumped three distinct EV charging communication protocols into one
tag. This PR splits it into three explicit tags and reframes the capability documentation from wire-protocol
names to the features evcc actually derives from each protocol:

• iso15118-2 — ISO 15118-2
• iso15118-20 — ISO 15118-20
• din70121 — DIN 70121

Motivation (from review feedback): a user doesn't care which protocol a charger speaks on the wire — they care
what evcc gains from it (reading SoC, identifying the vehicle, …). The three protocols genuinely derive
different evcc-relevant capabilities, so keeping them separate is meaningful, and the docs should describe the
derived capability rather than the acronym.

This description doubles as background material so the capability docs / external documentation can be written
from it.

---

Background: the three protocols

All three are High-Level Communication (HLC) protocols that run as HomePlug Green PHY power-line
communication over the Control Pilot line, on top of the basic IEC 61851-1 signalling. They differ in scope and
in what vehicle data they expose.

	DIN 70121	ISO 15118-2	ISO 15118-20
Role	DC predecessor of ISO 15118-2	1st-generation HLC	2nd-generation HLC (2022)
Connector scope	DC only (CCS)	AC + DC	AC + DC
Security	none (no TLS)	optional TLS 1.2	mandatory TLS 1.3

They coexist via dual-stack: the shared SupportedAppProtocol handshake negotiates the highest protocol both
sides support and falls back (−20 → −2 → DIN 70121).

---

Derived evcc capabilities (what each tag actually means)

Derived capability	DIN 70121	ISO 15118-2	ISO 15118-20
SoC readout	✅ continuous, DC (EVRESSSOC)	✅ DC only — ❌ not over AC	✅ AC + DC, continuous (DisplayParameters.PresentSOC)
Battery capacity / energy	⚠️ EVEnergyCapacity (optional)	⚠️ optional, DC only	✅ BatteryEnergyCapacity + Min/Target/Max SoC
Vehicle identification	✅ EVCCID / MAC (Autocharge)	✅ EVCCID / MAC (Autocharge)	✅ EVCCID / MAC (Autocharge)
Power/current control loop	✅ DC current loop	✅ DC loop; AC via EVSEMaxCurrent (single scalar)	✅ AC + DC, per-phase, Dynamic-mode setpoints
Bidirectional / V2X	❌	❌	✅ BPT (AC/DC → V2G/V2H/V2L)

1. State of charge (the primary evcc benefit)

The charger obtains the connected vehicle's SoC and hands it to evcc — no vehicle/cloud integration needed. It
is transmitted continuously during the session (in the repeating charge-loop message), as an integer percentage.

Important AC/DC nuance: ISO 15118-2 transmits SoC only for DC charging — the standard defines no SoC
field for AC sessions. Therefore a plain AC wallbox speaking ISO 15118-2 gets no SoC. Some AC wallboxes
(e.g. openWB Pro, using Bender CC613 / chargebyte / Hardy Barth controllers) work around this with a DC
handshake trick: at plug-in they briefly signal a DIN 70121 DC connection, read the SoC (and whatever battery
fields the car exposes) over that channel, tear it down, and then charge normally via IEC 61851-1 AC PWM. This
yields a one-time SoC at plug-in, not a continuously updated value. ISO 15118-20 fixes this — it carries SoC
natively over AC.

2. Vehicle identification — via EVCCID / MAC (Autocharge)

All three protocols carry the EVCCID (the EV communication controller's MAC address) in SessionSetupReq.
This is the practically usable vehicle identifier — exactly what "Autocharge" uses — and it works the same
across DIN 70121, ISO 15118-2 and ISO 15118-20.

• Caveat: it only works when the vehicle uses a stable, fixed MAC (OEM best practice: EVCCID = fixed,
  non-duplicated MAC). Vehicles that randomise their MAC for privacy cannot be identified this way.
• Plug & Charge / contract certificates are not relevant here: ISO 15118-2/-20 Plug & Charge yields a
  billing/contract identity (eMAID), not a vehicle identity, and requires a full V2G-PKI backend with
  provisioned certificates (rare in the field). It is an authorization/billing mechanism with no practical
  vehicle-identification use for evcc, so it is intentionally left out of the "identify" framing.

3. Power / current control loop during charging

Whether the protocol offers a practically usable closed-loop power/current regulation during the session:

Communication form	Practical control loop?
IEC 61851-1 PWM (AC baseline — every AC charger)	✅ Yes — Control Pilot duty cycle, continuous ≈6–80 A. At least 5 s response time. This is what is mainly used to control AC charging.
DIN 70121 (DC)	✅ Yes — CurrentDemand loop, EVSE sets the max current/power limit each ~150–200 ms; the EV follows
ISO 15118-2 — DC	✅ Yes — same CurrentDemand loop
ISO 15118-2 — AC	✅ Yes — ChargingStatusRes carries an optional EVSEMaxCurrent (PhysicalValueType) that the EVSE may vary on every response cycle without renegotiation. Single scalar (no per-phase); SECC response budget 1,5 s
ISO 15118-20 — AC + DC	✅ Yes — Dynamic control mode: per-loop EVSETargetActivePower setpoint, no renegotiation; genuine per-phase limits (_L2/_L3); BPT can command discharge

Two distinct mechanisms must not be confused:

• EVSEMaxCurrent in ChargingStatusRes — an instantaneous physical ceiling, freely changeable per cycle,
  no renegotiation, session not interrupted.
• EVSENotification = ReNegotiation — the schedule/tariff path (new SAScheduleList/PMaxSchedule via
  ChargeParameterDiscovery). Only this one is the "coarse, slow" route.

Takeaway: ISO 15118-2 does provide a usable dynamic AC current limit — finer in value resolution than
the PWM duty cycle and adjustable without touching it. Two caveats keep it from being categorically superior:
it is a single scalar applied per phase, exactly like the PWM (ISO 15118-2 has no per-phase fields —
per-phase _L2/_L3 arrive only with ISO 15118-20), and the standard mandates no minimum cadence (the SECC
is allowed 1,5 s to answer ChargingStatusRes, versus 25 ms for DC CurrentDemandRes), nor any deadline for
the EV to comply. Note also that PWM does not necessarily disappear: 5 % duty cycle is required for AC
Plug & Charge and for DC, but per [V2G2-853] "if an EVSE receives positive authorization information from an
EIM the EVSE shall apply a nominal duty cycle" — in AC + EIM the EV applies the smaller of the PWM and
EVSEMaxCurrent limits.

4. Battery capacity / energy

Optional fields (EVEnergyCapacity, EVEnergyRequest, FullSOC, BulkSOC in −2/DIN; BatteryEnergyCapacity
and Min/Target/Max-SoC in −20). In −2/DIN these are optional and frequently left empty by real vehicles, so a
charger cannot rely on them. −20 makes these first-class and reference-clear.

Note — computing SoC from energy fields is not a viable substitute. One might try
SoC ≈ (EVEnergyCapacity − EVEnergyRequest) / EVEnergyCapacity. In practice this is unsound: both fields are
optional (often 0/empty), EVEnergyRequest may target the driver's SoC target rather than "full" and may
include charging losses/preconditioning (error of tens of %), the capacity reference (gross vs usable) is
unspecified, and both are sent only once at session start (never refreshed). On DC the direct EVRESSSOC
is mandatory anyway; on AC the capacity field doesn't exist. No production project does this.

5. Bidirectional charging (V2X)

Only ISO 15118-20 supports bidirectional power transfer (BPT) — AC-BPT and DC-BPT enabling V2G/V2H/V2L, with
Scheduled and Dynamic control modes. DIN 70121 and ISO 15118-2 are charge-only. This is −20's headline addition
and is forward-looking for evcc.

---

References

Standards/technical sources used to compile the background above:

• Typhoon-HIL protocol references — DIN 70121,
  ISO 15118-2,
  ISO 15118-20
• CharIN — ISO 15118-20 DC-BPT interoperability guide
• Fastned — Autocharge whitepaper ·
  EVgo — vehicle OEM interoperability best practices (EVCCID = fixed MAC)
• Wikipedia — ISO 15118 ·
  evcc — ISO 15118 docs

[poohnet]

As #31446 has been merged, the WARP4 template has to be changed now as well.

[andig]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Resolved in a9f43e7 (merged latest master and fixed the conflict) with a follow-up compatibility fix in 6e81aa6.

[poohnet]

According to @rtrbt din70121 should be added as well:

BTW if #31468 is merged first, the capabilities have to be changed: WARP4 implements both iso15118-2 and din70121 (and later iso15118-20, but this will still take a while)

[naltatis]

@premultiply can you phrase this from a user/feature perspective (identify, soc, ...).

[andig]

Wofür brauchen wir das denn überhaupt also was würde ein Anwender mit der Information machen? Für evcc relevant ist das m.E. nur, wenn wir daraus evcc Fähigkeiten ableiten. Welche wären das jeweils (also z.B. SoC auslesen)?

[premultiply]

Ausgangspunkt: "iso151182" als einziges Capability-Tag ist sehr ungenau bzw. unzureichend.

Zu diskutieren ist natürlich ob man dies wie hier vorgeschlagen (weiter) anhand der gewählten aber nicht weniger für den gemeinen Anwender nicht so geläufigen Spec-Namen oder anderer Tags macht.

Ich habe Claude mal gezielt recherchieren lassen und die PR-Beschreibung aktualisiert.
Durchaus lesenswert als die gewünschte technische Hintergrundinformation über die jeweiligen Fähigkeiten der Protokolle/Spezifikationen.

[naltatis]

Important AC/DC nuance: ISO 15118-2 transmits SoC only for DC charging — the standard defines no SoC
field for AC sessions. Therefore a plain AC wallbox speaking ISO 15118-2 gets no SoC. Some AC wallboxes
(e.g. openWB Pro, using Bender CC613 / chargebyte / Hardy Barth controllers) work around this with a DC
handshake trick: at plug-in they briefly signal a DIN 70121 DC connection, read the SoC (and whatever battery
fields the car exposes) over that channel, tear it down, and then charge normally via IEC 61851-1 AC PWM. This
yields a one-time SoC at plug-in, not a continuously updated value.

Interesting. Hier passiert ja auch ein Mix an Standards. Spricht für mich auf jeden Fall dafür, dass wir hier auf die Feature-Ebene bei den Capabilities gehen sollten. Also sowas wie initialSoc, continuousSoc ...
Mit welchem Verfahren die Wallbox das dann mit dem Fahrzeug rausbekommt ist aus Nutzersicht (vmtl. sogar aus evcc-Sicht) ja Nebensache.

[andig]

Ausgangspunkt: "iso151182" als einziges Capability-Tag ist sehr ungenau bzw. unzureichend.

Aber unzureichend wofür? Warum sollte uns das interessieren? Wir spezifizieren hier ja kein WB Datasheet? ich würde gerne nur Dinge dokumentieren, die wirklich für uns relevant sind.

[DerAndereAndi]

Not practical — the ChargingStatus loop carries no setpoint; changing power requires a full renegotiation (coarse, slow). The real AC limiter remains the PWM

and

Takeaway: on AC, the real power regulation is always the IEC 61851-1 PWM duty cycle — which every AC
charger does. So "dynamic power control" is not a distinguishing benefit of the iso15118-2 / din70121
tags. The only genuinely new control capability in this family is ISO 15118-20's Dynamic mode + BPT
(real-time setpoints and bidirectional charging).

are not correct.

During HLC, the PWM is set to 5% and stops encoding a limit — the current limit in ChargingStatusRes replaces it, enabling per-phase limits and sub-second updates without touching the PWM. ISO 15118-2's AC control is strictly finer than PWM: PWM encodes one scalar value for all phases, while the V2G message can express per-phase limits and change them every response cycle without interrupting the session.

[premultiply]

Thanks — you're right on the main point, and I've corrected the PR description.

ChargingStatusRes does carry a limit; I had wrongly conflated it with the renegotiation path:

<!-- V2G_CI_MsgBody.xsd, ChargingStatusResType -->
<xs:element name="EVSEMaxCurrent" type="v2gci_t:PhysicalValueType" minOccurs="0"/>

So the EVSE can vary EVSEMaxCurrent on every response cycle, without renegotiation and without touching the
PWM. EVSENotification=ReNegotiation is the separate schedule/tariff path. That's fixed in the description.

On three of the supporting points I'd push back, though:

Per-phase limits — I did not find yet how ISO 15118-2 supports them.

EVSEMaxCurrent seems to be a single scalar PhysicalValueType in both ChargingStatusResType and
AC_EVSEChargeParameterType. ISO 15118-2 describes it as "maximum line current per phase" — the same
semantics as IEC 61851-1 Table A.8, "the duty cycle value indicates the current limit per each phase". Both are
one scalar applied to all three phases, so I read −2 as giving no per-phase expressiveness over PWM; per-phase
looks like a −20 addition. Happy to be corrected if you have a −2 reference.

5 % duty cycle — mandatory for AC PnC and for DC, but for AC + EIM [V2G2-853] says: "If an EVSE receives
positive authorization information from an EIM the EVSE shall apply a nominal duty cycle." And IEC 61851-1
Table A.8: with digital communication established and PWM between 8 % and 97 %, the maximum current is the
lower of the PWM and the digital value. So in AC + EIM — the common evcc case — the PWM keeps encoding a limit
and min() applies.

Sub-second updates — V2G_SECC_Msg_Performance_Time(ChargingStatusRes) is 1,5 s, against 25 ms for DC
CurrentDemandRes, and there is no minimum cadence and no deadline for the EV to comply with a changed
EVSEMaxCurrent (PWM at least has the explicit 5 s in IEC 61851-1). Achievable in implementations, but not
guaranteed by the standard.

Net: ISO 15118-2 AC control is finer in value resolution and adjustable without touching the PWM — a real
advantage I had wrongly denied. But per-phase expressiveness looks identical to PWM, and the timing isn't
guaranteed. Does that match your reading?

[DerAndereAndi]

• Per Phase control is possible with -2 AND VAS (Value Added Services which for some implementations also support providing SoC) or plain -20
• 5% duty cycle: it stays at 5% to keep keep ISO15118 active otherwise it will fall back to PWM and stop the ISO15118 connection. Same for AC + EIM.
• Minimum is 1.5s, correct. My sub-second was incorrect.

So in form of capabilities, -2 only provides a basis which some vendors extend using VAS (e.g. Porsche and VW to different degrees)