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 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


£ 410
(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
Read more

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