01Kopher AUTOSAR
KopherSAR BSW integration
Target platformKCU EVCC / reference hardware
Use Kopher AUTOSAR BSW with KCU EVCC or reference hardware as an integrated platform.
Back to / Embedded Systems
Vehicle-Side V2G Stack
KopherV2G
Released Version 0.1.0
A vehicle-side EVCC core for ISO 15118 / DIN protocols, EXI and charging state machines, with Kopher AUTOSAR, proprietary and third-party AUTOSAR integration paths.
One communication core, three deployment paths
KopherV2G brings DIN SPEC 70121, ISO 15118-2 and ISO 15118-20 session logic, message parsing and EXI into a vehicle-side EVCC core. Choose the integration path for your ECU platform while keeping a consistent vehicle application interface.
Choose integration for your ECU platform
02Non-AUTOSAR / proprietary
Platform adapters
Target platformExisting OS / network / security
Connect existing OS, networking, timers, storage and security services. Select third-party components against the target BOM and licenses.
03Third-party AUTOSAR
AUTOSAR integration adapter
Target platformCustomer SoAd / TcpIp / TLS / Crypto
Reuse customer SoAd, TcpIp, TLS and Crypto services, with bindings matched to the BSW release and interface capabilities.
Protocol modules and shared EVCC runtime
| Protocol | Product scope and flow |
|---|---|
| DIN SPEC 70121 | DC baseline flow with a shared vehicle application integration boundary. |
| ISO 15118-2 | Charging sessions, EIM / PnC branches and applicable certificate flows. |
| ISO 15118-20 | Updated sessions and DC charge-loop model; TLS 1.3 with project-selected services. |
How the runtime handles a message
Decode → Validate → Time → Decide → Recover: parse messages and EXI, check sequence and timers, correlate vehicle state, then advance or recover.
Vehicle integration
BMS / OBC / VCU supply SoC, charging permission, voltage/current limits and status. The application owns charging policy and physical actions.
Confirm protocol versions, AC/DC, EIM/PnC and bidirectional services at project kickoff. Stage counts are not conformance or certification claims.
Vehicle application and protocol services
AUTOSAR Classic integration example: charging policy stays in the application, while KopherV2G protocol services run below the RTE in BSW / middleware. Bindings depend on the target platform.
V2G Application
Charging policy, charging permission and BMS / OBC / VCU coordination
RTE / V2G Application API
BSW / MIDDLEWAREKopherV2G Protocol Services
- Session state machines & timers
- Message parsing & V2G data model
- EXI encoding / decoding
- SDP / V2GTP
Communication path
- SoAd
- TcpIp + TLS
- EthIf / Eth Driver
- PLC modem / physical link
Security service path
- KeyM: certificates & key management
- CSM: cryptographic jobs
- CryIf → Crypto Driver
- HSM / HSE or target software implementation
EVSE / SECC · IPv6 / TCP / TLS
Module and configuration reference
| Integration point | Configuration / responsibility |
|---|---|
| EcuC / PDU | PDU definitions and ID binding configure module relationships. |
| SoAd | SDP/APP routes, PduRoute/SocketRoute, SoConGroup and socket lifecycle. |
| TcpIp / TLS | UDP/TCP, IPv6 LocalAddr, TCPIP_CTRL, TLS/TLS_GROUP; SDP supplies the TCP endpoint. |
| EthIf / driver | Network controller, MII/QCA7K and PLC driver binding. |
| KeyM / CSM / CryIf | Certificate chain and key metadata; sign/verify/KDF/MAC/key-exchange jobs; driver routing. |
Configuration & bindings：EcuC PDU IDs, SoAd routes / socket groups, TcpIp controllers, timers and Crypto references define module bindings. EcuC is outside the runtime packet path.
TLS uses KeyM certificate services and CSM cryptographic jobs. Verify key protection and algorithm support against the target hardware and driver. SLAC establishes PLC link pairing. Responsibilities across the modem and driver depend on the platform.
SECC discovery and the charging session
An ISO 15118-20 DC example showing messages, transport and integration outcomes. The sequence varies with services, authorization and error branches.
Vehicle EVCC ↔ Charger SECCISO 15118-20 · DC
-
01Discover
Runtime / integration outcomeff02::1, UDP 15118; obtain SECC IPv6, port and security/transport settings. SDP does not assign the EVCC IP.
-
02Connect
Runtime / integration outcomeConnect to the SDP endpoint and negotiate the protocol. Part 20 uses TLS 1.3 for both EIM and PnC.
-
03Session / authorization
Runtime / integration outcomeEstablish the session, select services and authorize. Vehicle policy determines charging permission.
-
04Transfer
Runtime / integration outcomeCheck message timing, vehicle state and charging limits. The message family determines the payload type.
-
05Stop / recover
Runtime / integration outcomeCorrelate stop reasons, timeouts, faults and recovery with BMS/OBC/VCU state and controller I/O.
Deliverables and acceptance evidence
The delivered integration package
Software package, Vehicle API, EcuC PDU definitions, SoAd/TcpIp bindings, platform adapters, TLS/certificate and Crypto hooks, reference configuration, integration guide, test cases and message traces.
Define → Configure → Integrate → Prove
Requirements and vehicle policy → signal/network/security configuration → runtime and controller API adaptation → EVSE, bench/HIL, traces and project acceptance.
| Deliverable | Scope | Acceptance evidence |
|---|---|---|
| Protocol core | DIN / ISO state machines, SDP, V2GTP, EXI | Protocol trace and flow review |
| Platform adapter | Network, timers, storage, security and PDU / socket configuration | Target integration tests |
| Vehicle integration | BMS / OBC / VCU, CP / PP, PLC / SLAC | Bench / HIL and I/O evidence |
| PnC security | Certificates, KeyM / CSM, keys and provisioning | Certificate-chain and target security tests |
| Interoperability | Target EVSE / SECC, faults, stop and recovery | Session traces and project acceptance |
| Hardware platform | KCU EVCC / KCU GEN2 | On-target test |
Acceptance aligns protocol traces, vehicle state and controller behavior. Evidence for selected EVSE configurations has a different scope from full conformance or certification.
Delivery can include the software package, reference configuration, integration guide, test cases and traces. The project agreement and BOM define source or binary rights, target adaptation, support and third-party licenses.
Choose the target hardware
| Platform | Hardware and use case |
|---|---|
| KCU EVCC ↗ | NXP S32K344 Cortex-M7; QCA7006AQ PLC; CAN0/1/2, CAN FD and wake-up; CP/PP and protected outputs. Combines KopherV2G, UDS and vehicle applications for dedicated CCS EVCC programs. |
| KCU GEN2 ↗ | AURIX TC387, four TriCore cores / 300 MHz, 10 MB Flash; 4 × CAN/CAN FD, LIN, Ethernet, analog/digital/frequency/power I/O; 9–36 V. For VCU, energy management and domain control; PLC depends on configuration. |
GEN2 PLC and charging interfaces depend on the hardware configuration. Bidirectional power transfer also requires compatible power hardware, vehicle policy and EVSE support.
Read the KopherV2G technical guide →
Engineering guide · v1.1
Download the engineering guide
Review deployment choices, AUTOSAR architecture, charging sessions, security services, vehicle interfaces and acceptance evidence with your engineering team.