ISO 15118 Manual

Proven, Comprehensive, Easy to Understand.

ISO 15118 Manual cover


The ISO 15118 Manual is an eBook for beginners and experts alike. Both in-depth and clear at the same time, the eBook is geared toward building a foundational and overarching understanding of ISO 15118 and expanding on its numerous characteristics. 

The eBook will also guide you through all the necessary steps to implement charging sessions between electric vehicles and charging stations, with a focus on the convenient Plug & Charge feature.

Document structure ISO 15118


In this section, you will not only learn about the ISO 15118 family of standards, but also the IEC 62196 and the IEC 61851. The ISO 15118 relies on these specifications to carry out complete charging processes.

Get an overview of a typical ISO 15118 charging procedure for AC and DC charging with regards to messages that are necessary to be exchanged. Here, we'll delve into use cases related to these charging procedures.

Digital signature explained


Fully understand the mechanisms applied on the transport and application layer that secure the communication between EVs and charging stations with regards to confidentiality, integrity, and authenticity. We'll go over Elliptic Curve Cryptography, ECDH Key Agreement, ECDSA signatures, X.509 certificates, Public Key Infrastructures (PKI), Transport Layer Security (TLS) Handshake protocol, Online Certificate Status Protool (OCSP), and more.

This chapter also includes detailed examples of creating and verifying XML-based digital signatures on the basis of Authorization Requests and Certificate Installation Response messages.

PKI structure ISO 15118


Public Key Infrastructures (PKIs) are a system for the creation, storage, distribution, revocation, and use of digital certificates. You will learn about the motivations behind creating the ISO 15118 specific PKI structure, the different types of certificates to apply, and the non-functional PKI requirements that are also involved in this process.

AC message sequence til CertificateUpdate


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

Here, you will be guided step-by-step through the complete certificate installation process - one of the most challenging elements of ISO 15118.

AuthorizationRequest signature


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

I will walk you through carrying out this procedure, how so-called replay attacks by a malicious third party are avoided, and which messages need to be exchanged during the communication phase.

PMaxSchedule, SalesTariff and ChargingSchedule


The EV and the charging station exchange specific parameters and technical restrictions before the charging loop can be entered. Here, we will dive into this process.

You will also learn about the concept of renegotiating a charging schedule and influencing the charging process through parameters called PMaxSchedules and SalesTariffs, figures that can reflect the current grid situation.

DC charging session example


The masterclass finishes with an extensive chapter that runs 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 the backend IT system that operates the charging station using the Open Charge Point Protocol (OCPP). This is a world-wide and commonly-used communication protocol between charging stations and backend IT systems.



In conclusion, we'll look toward the future of ISO 15118 and foreshadow changes that will come with its highly anticipated second edition. This chapter will jump into ISO 15118 Edition 2 and expand on which new features we can expect - including wireless charging, wireless communication, and bi-directional power transfer.

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

Ready to get your copy?


One question I am often asked is: Which companies are already working on an implementation of ISO 15118 and when can we expect those ISO 15118-compliant EVs and charging stations to enter the market?

After recently attending five out of the six International CCS & ISO 15118 Testing Symposia, I have analyzed data gathered from these events and will answer this question in detail.

Free Extract

Get a Sneak Peek into the eBook

ISO 15118 Manual preview

Sign up for my V2G Clarity Newsletter and get a free extract from each chapter to see the quality and in-depth information you'll receive in the full e-book.

You'll also gain access to free lifetime updates - including up-to-date information on communication standards and industry happenings, and more.  

Get ready to grow your expertise and positioning in the e-mobility market. Don't miss this opportunity to get ahead of a fast-evolving industry!


Errata and Updates

Your feedback is highly appreciated and needed for this manual to hold its spot 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 was published in February 2017.

As paragraphs and sections have been rewritten and added while updating the ISO 15118 Manual, the respective page number in the first column may have changed slightly. 

Section (Page)

Errata / Addenda

Manual updated

2.1 (25)Updated table 2.1 "Document structure of ISO 15118 and current stages"June 2, 2018
2.1 (27)Updated figure 2.2 "Vehicle-to-grid communication document overview" to add ISO 15118-9. Also added information regarding ISO 15118-9 in the respective section.June 2, 2018
2.2 (30)Updated figure 2.5 "Vehicle inlet and DC charging connector according to the Combined Charging System (CCS) specification". The order of the pin assignment for CP, PP, L1, L2, L3, and N was illustrated incorrectly. Also, added figure 2.6 "Type 2 AC charging connector according to the Combined Charging System (CCS) specification".June 2, 2018
2.5 (43)Provided clarification why exactly the XSD file for SupportedAppProtocolReq and -Res messages is detached from the other XSD files.June 2, 2018
5.5 (92)Added section 5.5 "The Size of a CertificateInstallationRes". This section explains how to calculate the maximum possible size of such a message. Valuable information for allocating memory in the EVCC.June 2, 2018
7.1 (101)Added explanation for parameter "DepartureTime" of the message "ChargeParameterDiscoveryReq", clarifying how to interpret this value if set to 0 or not provided at all.June 2, 2018
3.2 (49)Added section 3.2 "Encoding Formats Base64 and DER". This section clearly explains how Base64 encoding works and why we use Base64 and DER encoding within ISO 15118. This provides valuable information, especially for non-computer scientists.October 2, 2017
3.8 (56)Added some paragraphs with the headline "Why to use the 04 prefix for uncompressed public keys". This explains the difference between compressed and uncompressed public keys, their visual representation on an elliptic curve and why uncompressed public keys are used in ISO 15118.October 2, 2017
3.12.4 (73-74)Updated this section entitled with "Pitfalls with Signatures And XML Namespaces" to make clear that the SalesTariff of ChargeParameterDiscoveryRes is using a different namespace (urn:iso:15118:2:2013:MsgDataTypes) - if being signed - than the parameters of CertificateInstallationRes and CertificateUdpateRes (there you need to use the namespace urn:iso:15118:2:2013:MsgBody). Also elaborated more clearly about how EXI codecs work with regards to using schema-informed grammars and encoding schema-deviant information.October 2, 2017
4 (79)Added a short paragraph stating that the EVSE Leaf Certificate of figure 4.1 is slightly misleading as it should be named SECC Certificate. We don't need a certificate for every EVSE installed in a charging station. In fact, we only need a certificate for the SECC that establishes the trust relationship with the EVCC during the TLS handshake and at the same time may control one or several EVSEs within a charging station.October 2, 2017
5.1 (85-87)The section on „TLS Handshake“ has been updated (figure as well as corresponding text with TLS handshake steps) to take into account all the necessary steps (8 more steps introduced) that are enforced by the OCSP multi stapling request (TLS extension status_request_v2).
Also added information about the trusted_ca_keys TLS extension which is used to transmit the list of V2G root CA certificates installed in the EV.
October 2, 2017
5.2 (88)Added a short paragraph that elaborates on the use of the parameter ListOfRootCertificateIDs.October 2, 2017
7.5 (115)Added a paragraph that explains how the renegotiation of a charging profile influences the energy flow in AC (no interruption) and DC charging (interruption).October 2, 2017
8.2 (134)Step 6 of the sequence diagram has been updated to explain the handling of an OCSP response when checking the contract certificate chain delivered with the PaymentDetailsReq message.October 2, 2017
Bibliography (185)Updated the reference to the VDE Regulation "Handling of certificates for electric vehicles, charging infrastructure and backend systems within the framework of ISO 15118" that has been published in September 2017.October 2, 2017
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 no longer needed (and may 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. Although potentially confusing, this 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 no longer 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 that 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-key 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 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