ISO 15118 Manual - V2G Clarity

ISO 15118 Manual

Proven, Comprehensive, Easy to Understand.

ISO 15118 Manual cover


The ISO 15118 Manual is for beginner and experts alike, being in-depth and comprehensible at the same time. 

You will be guided through all the steps that are necessary to carry out a complete charging session between an electric vehicle and a charging station, focussing on the convenient Plug & Charge feature.

Document structure ISO 15118


Learn about the ISO 15118 document family as well as IEC 62196 and IEC 61851 (including PWM signaling) on which ISO 15118 relies for the complete charging process to be carried out.

Get an overview of a typical ISO 15118 charging procedure for AC and DC charging with regards to the necessary messages to be exchanged. Delve right into the use cases related to these charging procedures.

Digital signature explained


Fully understand the mechanisms applied on transport layer and on application layer to secure the communication between EV and charging station with regards to confidentiality, integrity and authenticity: Elliptic curve cryptography, ECDH key agreement, ECDSA signatures, X.509 certificates, Public-Key-Infrastructures (PKI), TLS handshake, OCSP, ...

Detailed examples of creating and verifying XML-based digital signatures on the basis of an AuthorizationRequest and CertificateInstallationResponse message.

PKI structure ISO 15118


Public-Key-Infrastructures (PKIs) are a system for the creation, storage, distribution and revocation of digital certificates. You will learn about the motivations behind creating the ISO 15118 specific PKI structure, the different types of certificates to be applied as well as the non-functional PKI requirements coming with it.

AC message sequence til CertificateUpdate


The convenience feature Plug&Charge which enables an extremely user-friendly charging experience is based on the authentication and authorization through a digital contract certificate. This contract certificate as well as the corresponding private key need to be installed into the EV by means of a provisioning process.

You will be guided through the complete certificate installation process - one of the most challenging parts of ISO 15118 - step by step.

AuthorizationRequest signature


After the provisioning process has been completed, the EV is able to authenticate and authorize itself by using the newly installed contract certificate - without any further interaction needed by the user.

I will show you how this procedure is carried out, how replay attacks are avoided and what messages are exchanged during this communication phase.

PMaxSchedule, SalesTariff and ChargingSchedule


The EV and the charging station exchange some charging parameters and technical restrictions for the charging process before the charging loop can be entered.

You will also learn about the concept of renegotiating a charging schedule and influencing the charging process through so-called PMaxSchedules and SalesTariffs, information which can reflect the current grid situation.

DC charging session example


This masterclass on ISO 15118 finishes with an extensive chapter that will run you through a complete exemplary DC charging session.

This includes code listings of real request and response messages exchanged between an EV, a charging station and an IT backend which operates the charging station using the Open Charge Point Protocol (OCPP) - currently a world-wide commonly used communication protocol between charging stations and managing IT backend systems.



Finally, we will take a look into the future and see what will change with edition 2 of ISO 15118 and what new features will be introduced, such as wireless charging and communication or bi-directional power transfer.

As you see, the book covers a lot of ground, providing you with all the information you need to master the Vehicle-2-Grid communication technology.

Ready to get into it?


You might have a common question. One that I get asked often is: Which companies are already working on an implementation of ISO 15118 and when can we expect those ISO 15118-compliant electric vehicles and charging stations to enter the market?

After recently attending five out of the six International ISO 15118 Interoperability and Conformance Testing Symposia, I have analyzed the data gathered from these events and will use it to answer this question.

This e-book gives you the perfect foundation. But to become a real V2G Master,
you'll  need to fully understand Plug & Charge.


Free Extract

Convince yourself before you buy

ISO 15118 Manual preview

You get free lifetime updates - be it errors corrected, or new sections added. You don't want to miss out on that unique offer.

Get an extract from each chapter to see the quality and in-depth information you'll get in the full e-book. This e-book definitely helps you grow your expertise and positioning in the e-mobility market.

Just subscribe to the V2G Clarity Newsletter to stay up-to-date on communication standards in the e-mobility sector as well as industry happenings, and gain access to my free e-book extract.


Errata and Updates

Your feedback is highly appreciated and needed to keep this manual at its position as THE standard reference on ISO 15118.

If you spot an error somewhere in the ebook or do not understand a passage, please let me know.

The first version has been published in February 2017.

As paragraphs might be rewritten or sections added upon updating the ISO 15118 Manual, the respective page or section which the first column refers to might have changed in the new version. 

Section (Page)

Errata / Addenda

Manual updated

3.11 (59-73)
  • Rewrote small sections of section 3.11.1 for a better understanding
  • Replaced figures 3.8 and 3.9 with corrected updates
  • Added sub-chapter 3.11.3 "Pitfalls with Signatures in Java Implementations"
  • Added sub-chapter 3.11.4 "Which Private Keys to Use for Signatures"
August 14, 2017
10 (156 - 170)A completely new chapter 10 has been added with a market overview on current ISO 15118 implementations for electric vehicles and charging stations. The data is gathered from the past three ISO 15118 Testing Symposia.July 26, 2017
3.11 (59 ff.)
  • Deleted the “id” attributes in the “Reference” elements of the Signature header examples as they are not needed (and may especially not be equal to the IDs given in the body elements).
  • A hint is given that you should take care to use the exact same strings for EXI transformation and canonicalization as given in the header examples. Otherwise you will get different EXI byte streams and thus different signature values, which will lead to failed signature verifications.
  • A hint is given that ECDSA already includes the hashing operation before signing the hash with the provided private key. Hashing may not be done as an extra step before executing ECDSA on an EXI byte stream (Annex J of ISO 15118-2 sounds a bit confusing here). Figure 3.8 and 3.9 have therefore been updated for more clarity.
  • The reader is made aware that ECDSA is using random values when creating a signature, thus every signature operation, even if done with the exact same input, will always lead to different signature values. This might be confusing but is a security feature of ECDSA.
July 26, 2017
3.7 (56)More information is given on the public key attached to an X.509 certificate and how this public key is constructed.July 26, 2017
1.5 (23)Link to errata page was not correct any more.July 26, 2017
3.3 (52)Deleted the following sentence in the section about the ECDH key exchange as it is not correct:
"The ephemeral public key is calculated based on the static public key of the to-be-updated contract certificate respectively OEM provisioning certificate."
July 26, 2017
5.3 (81)

Corrected the steps of the mobility operator (MO) for encrypting the private key of the contract certificate which needs to be installed in the electric vehicle.


The MO encrypts the private key by

  1. computing a so-called DHpublickey (ephemeral Diffie-Hellman public parameter) from the OEM provisioning certificate’s public key as input for the ECDH protocol,
  2. applying this ECDH protocol to generate a shared secret which then serves as input to a key derivation function in order to derive the 128 bit session key, and
  3. using this symmetric session key for applying the AES-CBC-128 symmetric cipher on the contract certificate’s private key.


The MO encrypts the private key by

  1. generating an ephemeral key pair from the ECC domain parameters of the named curve "secp256r1" (the public key part is the above mentioned DHpublickey),
  2. generating a shared secret which is computed using the domain parameters of the named curve "secp256r1", the private key part of the ephemeral key pair generated in the previous step, and the OEM provisioning certificate’s public key,
  3. using this shared secret as input for an agreed-upon key derivation function in order to derive the 128 bit session key, and
  4. using this symmetric session key for applying the AES-CBC-128 symmetric block cipher on the contract certificate’s private key.

The MO needs to delete this ephemeral key pair as soon as the private key belonging to the contract certificate has been encrypted and the DHpublickey has been sent to the CPS along with other contract data for signature purposes.

July 26, 2017
2.4 (42)Caption for figure 2.10 "DC message sequence" was missing.June 9, 2017
3.1 (48)Explained Elliptic Curve Cryptography (ECC) in more detail and corrected the following sentence: "The '256' in that named curve indicates that the keys must be 256 bits long.".
As a public ECC key represents a point on an elliptic curve with X and Y coordinates, it encompasses two 256 bit values.
June 9, 2017
8 (109)Added information on the format of the "vendorId" in OCPP (Open Charge Point Protocol) DataTransfer.req call messages. Corrected the format of vendorId in example messages.June 9, 2017
8.2 (123-126)As Nikos Papadopoulos (Allego) - thanks! -  pointed out, there was an error on page 124 (step 4 of section 8.2) stating that a SHA-256 would produce a 256 bytes hash. But since SHA-256 generates hashes of 256 bits length, we get 256 bits for the issuerNameHash and issuerKeyHash. Furthermore, steps 3 to 6 of the sequence diagram regarding the communication steps from PaymentDetailsReq to CableCheckRes have been rewritten. Reason: Not only the contract certificate itself but the entire contract certificate chain needs to be checked with an OCSP request for a positive authorization. More information has been added for clarification. June 9, 2017
Annex A (158 ff)Certificate profiles needed a little update:

The Domain Component of the EVSE Leaf Cert must be set to "CPO".
The Domain Component of the Leaf Prov Cert must be set to "CPS".
The Domain Component of the OEM Prov Cert Cert must be set to "OEM".
The Domain Component of the Priv. Env. SECC Cert must be set to "PE" (according to upcoming Edition 2 of ISO 15118-2).
June 9, 2017