KopherV2G: ISO 15118 / DIN 70121 V2G software stack
KopherV2G vehicle-side EVCC core with ISO 15118 / DIN, EXI and session control, integrated through Kopher AUTOSAR, proprietary or third-party AUTOSAR platforms.
Quick Facts
Product summary
KopherV2G is KopherBit’s vehicle-side EVCC communication core. It integrates DIN SPEC 70121, ISO 15118-2 and ISO 15118-20 session state machines, message parsing, EXI, SDP and V2GTP, with connections to target communication and security services.
Three deployment paths
| Path | Components | Integration scope |
|---|---|---|
| Kopher AUTOSAR | KopherSAR + KopherV2G | Kopher BSW, KCU EVCC or reference hardware |
| Non-AUTOSAR / proprietary | KopherV2G + adapters | OS, network, time, storage and crypto |
| Third-party AUTOSAR | KopherV2G + integration adapter | Existing SoAd, TcpIp, TLS, KeyM, CSM, CryIf and Crypto Driver |
AUTOSAR architecture and responsibilities
The vehicle V2G Application coordinates BMS, OBC, VCU and charging policy through the RTE / V2G API. KopherV2G runs in BSW / middleware and handles protocol and session logic. Communication passes through SoAd, TcpIp / TLS and EthIf / driver to the PLC modem.
TLS uses KeyM certificate services and CSM cryptographic jobs routed through CryIf to a Crypto Driver. HSM / HSE key protection and algorithm support depend on the actual hardware, driver and configuration. An AUTOSAR platform does not automatically provide the TLS capabilities required by ISO 15118-20.
EcuC PDU IDs and SoAd / TcpIp settings describe configuration bindings, outside the runtime packet path. SLAC is a PLC link-pairing procedure and should be distinguished from the physical modem.
Discovery and secure sessions
- Establish CP / PLC pairing and IPv6 link-local addressing. Link-local addressing does not require DHCP.
- EVCC sends an SDP request by IPv6 multicast to ff02::1 on UDP port 15118. SECC returns its endpoint. SDP does not assign the EVCC address.
- EVCC establishes TCP / TLS to the returned SECC IPv6 address and service port, then exchanges SupportedAppProtocol.
- The selected protocol and EIM / PnC branch determine session setup, service selection, authorization, power negotiation, charging loops and stop.
ISO 15118-20 requires TLS 1.3 for EIM and PnC. ISO 15118-2 PnC uses TLS 1.2. Security policies must be matched to the protocol version.
| V2GTP payload | Purpose |
|---|---|
| 0x9000 / 0x9001 | SDP request / response |
| 0x8001 | SupportedAppProtocol; also ISO 15118-2 / DIN EXI messages |
| 0x8002 | ISO 15118-20 common messages |
| 0x8004 | ISO 15118-20 DC messages |
This is the subset used in a DC example, not a complete ISO 15118-20 payload catalog. Stage counts vary with protocol, service and conditional branches.
Delivery and acceptance
Delivery can include the protocol core, platform adapter, vehicle API, reference configuration, integration guide, test cases and traces. Acceptance aligns protocol messages, BMS / OBC / VCU state and controller I/O, including faults, stop and recovery.
KCU EVCC provides a dedicated EVCC hardware path. KCU GEN2 integrates charging communication into VCU or energy-management applications; PLC and charging interfaces depend on the hardware configuration. The project agreement defines source / binary rights, adaptation, support and third-party licenses.
FAQ
Is the product scope EVCC or SECC?
This page describes vehicle-side EVCC delivery. SECC / charger-side requirements need separate confirmation; shared protocols do not establish equivalent deliverables for both roles.
Does ISO 15118-20 imply every bidirectional charging scenario is implemented?
Bidirectional power transfer also requires the selected service, EVSE, power hardware and vehicle policy. Confirm MCS, WPT and V2L support and acceptance individually instead of inferring them from the protocol name.
Explore the KopherV2G product and architecture
References
Need a production VCU platform?
Explore KopherBit Vehicle Control Unit platforms and engineering services for commercial EV programs.