ISO 15118 Manual – V2G Clarity

Reduce Complexity with
the ISO 15118 Manual

An e-book for beginners and experts alike. Reduces the steep learning curve of ISO 15118 by providing a comprehensive and easy-to-understand access to the Vehicle-to-Grid communication protocol. Written by one of the few co-authors of ISO 15118, this e-book has fast become standard literature in the industry. 

Join the club of happy customers. 
ave time and money and avoid common mistakes with the easy-to-understand ISO 15118 Manual. 

ABB / Bosch / Daimler / Honda /  Porsche / Shell / Tritium

Take a Guided Tour



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.


The Basics / Fundamentals

In this section, you will not only learn about the ISO 15118 family of standards and the protocols defined therein, 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.


Security Concept

Fully understand the Plug & Charge security 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.


Certificate Concept

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.


Certificate Provisioning

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.


Authentication & Authorization

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.


Charging Schedules & Renegotiation

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.


Outlook on Edition 2

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.


Market Overview on Implementations

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.


Take Your Expertise to the Next Level

Join the club of innovators who already placed their trust into the ISO 15118 Manual: ABB, Audi, Bosch, Daimler,, Hubject, MHP, Phoenix Contact, Shell, Tritium, and many more.

  • Single user
  • Multiple users


(excl. VAT)
  • Saves you many days of tiresome trial and error
  • Helps you to really understand ISO 15118
  • Free updates delivered to your inbox
  • Q&A style web meeting with the author (60 mins)


Are you interested in copies for your colleagues or students?

We offer company-wide licenses
as well as licenses for academic libraries.

  • Train your team on this future-proof technology
  • Provide access to students of e-mobility tech
  • Ensure updates for each employee / student
  • Unlimited number of copies included in purchase

Want to Try Before You Buy?

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

Provide your name and email address to get it delivered to your inbox.

Updates to the E-Book

Your feedback is highly appreciated and needed for this manual to remain THE standard reference on ISO 15118. If you encounter an error in the eBook or do not understand a passage, please let me know. Updates to the eBook are automatically delivered to your inbox for free once you purchased a copy.

Section (Page) Update Updated on
2.1 (25-27) Updated some paragraphs, table 2.1 (document structure of ISO 15118 and current stages), and figure 2.2 (ISO 15118 document overview). Update now also contains reference to new ISO 15118-20. 2019-06-19
7.4 (112) Added a paragraph explaining why the field “ChargingProfile” of PowerDeliveryRequest is optional. This leads to implementations in which the EV never sends a CharingProfile, although the EV is always supposed to send a CharingProfile each time it wants to start charging. 2019-06-19
8.1 (125 – 126)
  • Line 33 of Listing 18 (ServiceDiscoveryRes message)
    → Service name must be “Certificate”, cannot be “Contract certificate installation/update” (as defined in table 105 of ISO 15118-2)
  • Line 22 – 27 in Listing 18 (ServiceDiscoveryRes message)
    → It doesn’t make sense to mix AC and DC as supported energy transfer modes. It’s either AC or DC, depending on which cable is plugged into EV and charging station.
  • Line 17 and 23 of Listing 20 (ServiceDetailRes message)
    → The Parameter name must be “Service” (cannot be “Certificate Update” or “Certificate Installation”; the string value tells whether it’s installation or update)
2.1 (25) Updated table 2.1 “Document structure of ISO 15118 and current stages” 2018-06-02
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. 2018-06-02
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”. 2018-06-02
2.5 (43) Provided clarification why exactly the XSD file for SupportedAppProtocolReq and -Res messages is detached from the other XSD files. 2018-06-02
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. 2018-06-02
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. 2018-06-02
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. 2017-10-02
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. 2017-10-02
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. 2017-10-02
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. 2017-10-02
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. 2017-10-02
5.2 (88) Added a short paragraph that elaborates on the use of the parameter ListOfRootCertificateIDs. 2017-10-02
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). 2017-10-02
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. 2017-10-02
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. 2017-10-02
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”
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. 2017-07-26
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.
3.7 (56) More information is given on the public key attached to an X.509 certificate and how this public key is constructed. 2017-07-26
1.5 (23) Link to errata page was not correct any more. 2017-07-26
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.” 2017-07-26
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.
2.4 (42) Caption for figure 2.10 “DC message sequence” was missing. 2017-06-09
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. 2017-06-09
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. 2017-06-09
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. 2017-06-09
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). 2017-06-09

This website uses cookies to ensure you get the best experience on our website. More about privacy.