ISO 15118 Plug and Charge Integration for OBC Programmes

ISO 15118 Plug and Charge is integrated through the vehicle communication controller and charging interface, not through the battery’s internal CAN network. An OBC programme must define the EVCC-to-SECC interface, certificate lifecycle, protocol scope, and test responsibilities before hardware and software are frozen.

What does Plug and Charge add to an OBC programme?

Plug and Charge uses ISO 15118 communication between the vehicle communication controller, known as the EVCC, and the supply equipment communication controller, known as the SECC. The vehicle can identify the charging contract and request authorisation after the connector is inserted, without relying on a separate card or mobile application. ISO 15118-20 defines communication between the EV and EVSE through IP-based communication and supports charging-control functions beyond basic energy transfer.[6]

For an OBC supplier, this does not mean placing all ISO 15118 logic inside the power-conversion stage. The OBC controls AC energy conversion and normally exchanges charging limits, voltage, current, contactor status, and fault states with the vehicle control system. The EVCC handles the external charging protocol, while a vehicle-level controller coordinates requests, battery limits, safety conditions, and the OBC.

The exact partition depends on the OEM electrical architecture. Grapcharger should receive an interface specification identifying which functions belong to the OBC, EVCC, vehicle control unit, battery-management system, and charging connector assembly. Without that allocation, suppliers may duplicate state machines or expose internal battery signals directly to the external protocol.

Which vehicle-side blocks must be defined?

A typical architecture contains the charging inlet, the control-pilot and power-line communication path, an EVCC, the OBC, the battery-management system, a vehicle control unit, and the telematics or backend interface used for certificate services. The EVCC establishes the external communication session. The OBC remains responsible for controlled AC power conversion and must accept only validated, vehicle-authorised operating commands.

The connector and communication path require attention to signal integrity, wake-up behaviour, isolation, grounding, and transitions between connected, charging, interruption, and disconnect states. The EVCC may be integrated into an OBC, charging-control unit, or gateway, but the programme must define diagnostic ownership and software update responsibility if the functions are combined.

Internal CAN, CAN FD, Ethernet, or another vehicle network may carry the EVCC’s approved charging request to the OBC. That internal message is not itself ISO 15118. It is an implementation interface between vehicle subsystems and should use authentication, timeout handling, plausibility checks, and safe fallback states appropriate to the vehicle architecture.

How should certificate handling be assigned?

Plug and Charge depends on a certificate chain and trust model rather than only a charging-current handshake. The vehicle may contain a contract certificate representing the charging service relationship. The charging equipment validates the relevant certificate and uses its own trust configuration to determine whether the session can proceed.[9] ISO 15118-20 introduces broader security behaviour, including mutual authentication and additional certificate-related requirements compared with earlier implementations.[4]

The vehicle programme must decide who operates the certificate-management function. Possible owners include the OEM, an eMobility service provider, a contract-certificate provider, a secure vehicle gateway, or a dedicated backend service. Responsibility should cover certificate issuance, secure installation, renewal, replacement, revocation, storage, audit records, and recovery after a failed update.

Certificates and private keys should be protected by an approved secure element, hardware security module, or equivalent vehicle security architecture where required by the programme. The OBC supplier must not assume that certificate files can be stored in ordinary application memory. The interface specification should define key-generation location, access permissions, diagnostic restrictions, manufacturing provisioning, and end-of-life deletion.

Contract-certificate handling also requires operational decisions. The vehicle may be delivered without a customer contract, receive credentials during commissioning, or support multiple certificates. ISO 15118-20 is associated with storage of multiple charging certificates, but the supported behaviour must be confirmed against the selected profile, backend, and target charging networks.[8]

Which ISO 15118 versions and security modes should the programme support?

ISO 15118-2 and ISO 15118-20 should be treated as separate implementation scopes. They are not interchangeable software labels: the message sets, security expectations, negotiation behaviour, and feature coverage must be defined for the vehicle and target infrastructure. Some deployments require support for more than one version, which can require separate protocol stacks or carefully specified negotiation behaviour.[4]

ISO 15118-2 provides the established foundation for wired charging and Plug and Charge. ISO 15118-20 expands the communication framework and includes functions such as bidirectional power-transfer messaging, wireless-charging communication, and additional control possibilities.[6] A programme should not claim support for every feature simply because an ISO 15118-20 stack is present.

Define the supported charging modes, authentication methods, TLS versions, cipher suites, certificate profiles, timing limits, error handling, and fallback to alternative charging communication. Security configuration is a major interoperability issue, particularly when infrastructure has different TLS, certificate, or protocol-negotiation assumptions.[7]

What should be tested before vehicle integration?

Testing should begin with component and software-integration tests, then progress through a communication bench, hardware-in-the-loop setup, charging-station interoperability tests, and vehicle-level validation. The test environment must emulate both EVCC and SECC behaviour, including valid sessions, malformed messages, invalid certificates, interrupted communication, delayed responses, connector removal, and charging-station faults.

ISO 15118-21 defines common test cases for EVCCs and SECCs implementing ISO 15118-20, including session establishment, interruption and re-establishment, authentication, service discovery, termination, error handling, and timing behaviour.[2] For ISO 15118-2 implementations, ISO 15118-4 conformance testing is relevant to network and application protocol behaviour.[10]

Do not limit testing to successful authorisation. The OBC must enter a safe state if the EVCC sends an invalid charging request, loses communication, receives a certificate failure, or reports battery conditions that no longer permit energy transfer. Test evidence should link each external protocol event to the internal EVCC-to-OBC message, OBC state, contactor command, measured electrical response, diagnostic code, and recovery action.

Interoperability testing should include the charging stations and backend services expected in the target regions. A passing protocol test does not guarantee successful certificate provisioning or commercial authorisation. The programme should therefore maintain a test matrix for protocol version, AC charging mode, authentication mode, certificate state, network condition, and infrastructure implementation.

Who owns each part of the integration?

The OEM owns the vehicle requirements, market deployment assumptions, cybersecurity policy, backend relationships, and final system acceptance. The EVCC or charging-control supplier owns the external protocol implementation when that function is outsourced. The OBC supplier owns power-conversion behaviour, internal control interfaces, diagnostics, and safe response to authorised charging commands.

The battery supplier must define usable energy, voltage, current, temperature, isolation, and charging-limit signals, but should not be made responsible for the external Plug and Charge session unless explicitly contracted. The connector supplier owns the mechanical and electrical interface within its scope, including communication-path requirements defined by the vehicle design. The CPO or eMobility service provider owns charging-station and contract-authorisation services.

What should an OEM include in the supplier specification?

The request for quotation should identify the target ISO 15118 editions, mandatory and optional services, supported charging modes, authentication fallback, certificate ownership, security requirements, diagnostic access, software-update method, and target charging networks. It should also state whether the supplier is delivering an EVCC, an OBC with an integrated EVCC, an interface-only OBC, or a complete charging-control subsystem.

Define all internal signals in a controlled interface document. Include signal units, scaling, validity, timeout, default values, update rates, authority rules, and fault reactions. The interface should make clear whether the EVCC may request power directly or whether the vehicle control unit must approve every request based on BMS limits and safety state.

Require a traceability package rather than a declaration of compatibility. The package should include requirements coverage, software version identification, test logs, certificate-lifecycle results, known interoperability limitations, cybersecurity assumptions, and change-control rules. Ask the supplier to identify which behaviours depend on the charging station or backend and cannot be validated on an isolated vehicle bench.

Before design freeze, agree the support boundary in writing. If a customer needs both ISO 15118-2 and ISO 15118-20, or expects future bidirectional charging, the hardware security, memory, processing, isolation, and software-update capacity should be reviewed early. Exact implementation capability depends on the selected controller and vehicle architecture; check the datasheet and integration specification.