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.
I am convinced that this e-book will help to introduce new experts to the topic in a faster and more efficient way."
There aren’t many experts that have deep knowledge about the ISO/IEC 15118 and DIN SPEC 70121, but Marc is definitely one of the few."
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, has.to.be, Hubject, MHP, Phoenix Contact, Shell, Tritium, and many more.
- Single User
-  Multiple Users
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)||
|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|
|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.)||
|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|
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 …
The MO encrypts the private key by …
|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|