Charging Communication with ISO 15118 (July 2022)

We believe that sharing knowledge and helping others in the e-mobility industry to innovate is the way forward – for all of us. Because by working together, we’ll get there quicker. So we decided to kick off this year with our new webinar series, Switch to Clarity, a place to share our expertise with you.

Welcome to episode two of our Switch to Clarity webinar series, What’s new in ISO 15118-20, where our Switch engineers André and Shalin joined me to shed light on the new features introduced with ISO 15118-20.

In this informative webinar, you also meet Plug & Charge specialist Steffen Rhinow from Hubject. Steffen discussed the implications of ISO 15118-20 on existing Plug & Charge implementations and told us more about their new Open Plug & Charge Protocol.

Here’s the recording of our webinar from March 25, 2022, for you to watch.

Q&A around ISO 15118-20

We dedicated the last 15 minutes of the webinar to questions.

Below, we’ve linked the questions to the timestamps in the video and elaborated our answers in more detail. If there are any other specific questions you would like us to answer, shoot me an email at marc@switch-ev.com.

Q: Is there an up-to-date database of vehicles that support ISO 15118, including -20?

A: The short answer is no. There is no such list or database available. The good news is that we can give you some insights based on public announcements and insider industry news.

EV manufacturers have only recently started to announce their support of ISO 15118-2, released as an international standard back in 2014. The first time we heard of a car manufacturer’s plan to support Plug & Charge, one of the key drivers for adopting ISO 15118, was back in 2018. During Hubject’s Intercharge Network Conference (ICNC 20), they used a Smart Electric Drive to showcase this convenient feature. However, it seems that this proof of concept never made it into series production.

Porsche was the first to announce support for Plug & Charge for its series production cars back in August 2020. During Hubject’s ICNC 21 in September 2021, Hubject used a Porsche Taycan to demonstrate Plug & Charge at an Alpitronic HPC charging station.

Here’s a list of EV makes and models and associated news articles that support the fact that these vehicles already do or will support ISO 15118-2 with Plug & Charge. This is by no means an exhaustive list.

When will ISO 15118-20 be picked up?

ISO 15118-20 FDIS (Final Draft International Standard) was recently published at the end of February. You can purchase it online at Beuth publishing house.

An FDIS is a technical feature freeze. This means that only editorial changes are possible between the FDIS and IS (International Standard). It's safe to start implementing the new standard based on this draft, and there will be no more technical changes. ISO 15118-20 is the underlying communication technology to enable bidirectional power transfer for AC and DC (Combined Charging System – CCS).

We don’t know exactly when EV manufacturers will pick up ISO 15118-20. What we do know is that bidirectional power flow, commonly referred to as V2G (Vehicle-to-Grid) seems to be the most anticipated feature. V2G has slightly different challenges than Vehicle-to-Home (V2H) or Vehicle-to-Building (V2B). Our best guess is that we’ll see the first EVs in the mass market with V2H / V2B / V2G support by 2024 –– and I believe VW, Renault, Hyundai and Sono Motors will be among them.

Reading tips

have a look at the “Smart charging and vehicle-to-grid” section in our article on The four key ingredients for a thriving e-mobility ecosystem. There, we linked Robert Llewellyn’s Fully Charged YouTube video (watch below) on a sizeable Vehicle-to-Grid project in Utrecht (The Netherlands)
the video comprises a car park with 2160 solar panels powering 250 EVs. You’ll find some fascinating hints towards Renault, Hyundai, and Sono Motors doing V2G with Type 2 AC. I know Renault has been the driving force behind standardising V2G for AC within the ISO 15118-20 working group
Hyundai also recently published a PR with more information about their V2X strategy
in Germany, there’s the research project ‘Bidirectional charging management – BDL’ launched in 2019. In July 2021, they started the field trial with 50 BMW i3s converted for V2G, using the CCS for DC charging.
‍

Robert Llewellyn’s Fully Charged video on a Vehicle-to-Grid project in Utrecht

Honda is also participating in V2X research projects, deploying 50 Honda e for the V2X Suisse project in Switzerland. As DC CCS chargers are part of the story, Honda must indeed have plans to adopt ISO 15118-20. Last but not least, Ford prominently launched its F-150 Lightning, an electrified version of the popular pick-up truck in the U.S. Here is an insightful video from the State of Charge YouTube channel that addresses 15 questions around Ford F-150 Lightning’s Intelligent Backup Power charger. Whether or not Ford uses an early version of ISO 15118-20 for their V2H charging technology is unclear.

Given that Ford already supports ISO 15118-2 with Plug & Charge in its Mach-E models at the Electrify America charging network, one can only assume that they already dug into an early version of the new ISO 15118-20 FDIS for the F-150 Lightning.

In summary on this question:

this background is a snapshot of the current V2G landscape, as opposed to a complete list of all ongoing ISO 15118-20 based V2G projects. It shows you where the industry is heading
there are enough indications to assume that 2024 will be the year of V2G for both AC (Type 1 / Type 2) and DC (CCS)
given that the majority of EV manufacturers currently seem to favour DC V2G over AC V2G (aside from Renault, Hyundai, and Sono Motors), I believe that we may predominantly see DC V2G in the market within the coming years. One could also argue that DC V2G will be the favoured solution for big batteries and high power charging stations (eg fleet charging). In contrast, AC V2G will be the preferred solution for the home charging scenario.

Q: For EV makers in the market, would it be possible to implement ISO 15118-20 (at least BPT) without changing existing charger hardware (supporting DIN SPEC 70121, ISO 15118-2, Basic Charging etc.)?

A: This very much depends on the existing hardware in place. To answer this question thoroughly, let’s look at what your EV and charger need to have in place to support both ISO 15118-2 and -20.

HomePlug Green PHY modem
This device enables power line communication via the charging cable connecting the EV and the charger. Both sides need a transceiver to modulate the digital signals (ISO 15118 messages) onto the analogue medium, ie the wire inside the charging cable. SLAC (Signal Level Attenuation Characterisation), a protocol further specified in ISO 15118-3, enables the EV and charger to set up a digital communication link using power line communication.

This technology is similar to the devices you plug into your socket at home to extend the WiFi across different rooms.

Memory space
ISO 15118-2 introduces Plug & Charge, the most user-convenient and secure way of starting the charging process at a charging station. You simply plug in the cable, and that’s it. No need for any RFID cards or smartphone apps. This technology is underpinned by an ecosystem called Public Key Infrastructure (PKI). A PKI is based on a set of digital certificates, and in the context of e-mobility used to authenticate an EV towards a charger and vice versa. The certificates used in ISO 15118-2 can be up to 800 bytes. Both the EV and charger need to have enough memory space to store the necessary certificate chains (up to four certificates in a certificate chain, including the root certificate).
‍
ISO 15118-20 even allows for certificates of 1600 bytes, and certificate chains can contain up to five certificates, including the root (-> max. 8 kB in total). You also need to be aware that ISO 15118-2 and -20 are not compatible with each other. This means that an EV that only "speaks" ISO 15118-20 cannot charge at a charger that only supports ISO 15118-2, and vice versa. You need to account for the memory necessary to host the codebase to implement both protocols.

Secure storage of digital certificates and keys
Certificates and associated private keys must be stored in a secure space in both the EV and charger. One way to achieve that is a hardware security module, or HSM for short. These HSMs ensure that no unauthorised third party can access the digital certificates and private keys stored.

CPU power to support encrypted communication
Both ISO 15118-2 and -20 require TLS for encrypted communication (TLS 1.2 in -2, TLS 1.3 in -20) and digital certificates and signatures to ensure the authenticity and integrity of the exchanged messages. Creating and verifying digital signatures are relatively expensive cryptographic operations in terms of CPU power. Given that each ISO 15118 message is assigned a timeout (eg the EV expects a response to its request within two seconds), it’s best to ensure your communication controller can handle the tasks before running into a timeout. Otherwise, it’s game over, and the communication session terminates.

Bidirectional on-board charger for AC
‍Last but not least, your EV needs to have a bi-directional onboard charger in place in case of AC charging and feeding energy back to the grid.

Q: How are things going with the (open source) release of Josev?‍

A: We'll be sharing an update on this in our pre-launch webinar on May 3rd. We'll be telling you more about our Josev Community edition. Sign up here to register.

‍Q: Is there any plan to extend bidirectional charging to V2L and V2H? And V2V?

A: It’s probably a good idea to briefly explain what these terms mean before I answer this question.

V2L
Vehicle-to-Load (V2L) allows your EV to act as an external power source to power several (low power) electrical devices like camping equipment or appliances. The EV would be equipped with an outlet different from a Type 1 / Type 2 (AC) or CCS outlet to connect your devices.

V2H / V2B
In a Vehicle-to-Home (V2H) or Vehicle-to-Building (V2B) scenario, the EV can power a home or an office building, for example, to not only reduce the energy bill but to reduce demand on the local grid. Here, we’re talking about a closed electric ecosystem, which is not the same as V2G (Vehicle-to-Grid), as the energy stored in the EV’s battery is not fed back into the electricity network (the grid).

‍V2V
‍With Vehicle-to-Vehicle (V2V), the idea is that one vehicle can power another vehicle, eg to help out a stranded EV that didn’t make it to the next charging station on time.

‍V2X
This is Vehicle-to-everything and is often used in the e-mobility industry as a collective term for V2H, V2B and V2G. ISO 15118-20 addresses explicitly the V2H / V2B and V2G scenarios. The protocol describes the necessary exchange of messages between an EV and a charging station connected to a home, office building or the grid. It’s not the right fit for V2L or V2V use cases.

Q: Does ISO 15118-20 enable V2G for street charging, and will it seamlessly identify the owner of the power via Plug & Charge?

A: ISO 15118 is a communication standard that specifies the “language” of the EV and charging station for exchanging the relevant information to charge the EV’s battery. In the case of ISO 15118-20, we now also have the means to use the EV as a power bank on wheels to feed energy back to a home, building or the grid whenever necessary. Where this charging or discharging process is happening is entirely independent of the protocol. This can be street, home, fleet, or workplace charging - the opportunities are limitless.

Identifying a vehicle via Plug & Charge

the identification of a vehicle is based on a digital certificate called a “contract certificate”
the contract certificate stores an identification token called e-mobility account ID (EMAID), which is linked to an energy contract
the EMAID is essentially the billing account for the electricity delivered to an EV
have a look at this knowledge base article for more information on Plug & Charge.

Q: Which side should present the pricing information to the user before the charge begins, the EVCC (car's infotainment?) or SECC (charger's screen or an app)?

A: The ISO 15118 standard provides the means to transmit pricing information. It’s then up to the EV and charger manufacturer to make use of and visualise this information as they see fit. It’s very much a business decision; there’s no clear answer.

Putting myself in the shoes of an EV driver, I would expect the EV charger’s display to show me how much the charging process will cost before I start charging my EV. And inside the EV, I’d like to see a history of all charging sessions and the tariffs that applied, including the total costs.

Absolute pricing

As mentioned during the webinar, ISO 15118-20 provides an extensive set of pricing information using a data structure called “absolute pricing”. Absolute pricing means that both the charge point operator (CPO) and the mobility service provider (MSP, the company offering the electricity contract for your EV) can get quite sophisticated with their tariff structure. For example, they could set a session fee, a kWh-based energy fee, a peak power price, an overstay fee, and country-specific tax rules.

However, the current roaming protocols, such as OICP (Hubject’s Open InterCharge Protocol) and OCPI (Open Charge Point Interface) still need to catch up with that level of sophistication to enable CPOs and MSPs to exchange this rich pricing information.

‍Q: How difficult it is to incorporate the BPT feature into a product that is defined on ISO 15118-2?

A: There are means to extend or create a slightly proprietary version of ISO 15118-2 while still complying with the official specification. We explain this further in our ISO 15118 Basic training, organised by CharIN Academy. The short answer is that you’d have to use the “minor version” field in the Supported App Protocol (SAP) Request. The SAP Request is a message the EV sends to the charging station at the beginning of a charging session to agree on a mutually supported communication protocol.

If the charging station understands this “minor version”, which means a “minor deviation from the official standard”, it can properly process the added functionality. This way, you could, for example, add data fields to existing messages or create completely new messages using a different payload type. The payload type is an instruction for the receiving party (EV or charger) on how to interpret the incoming data. If the charger does not understand how to interpret the minor version, it would simply ignore anything that is not compliant with the official ISO 15118-2 standard.

That said, implementing a proprietary version that deviates from the official standard raises interoperability issues. This only works if you control the environment and can make sure that both EV and charging station understand any added functionality, like in a fleet charging scenario.

‍Q: If the EVSE supports only part 2 and installs a new contract certificate in the EV, and this EV when connected to EVSE supports only part 20, will it invalidate/not accept the contract certificate saved in the EV?

A: Great question. Here’s how best to describe how it would work

Agreeing to the same communication protocol

at the beginning of the charging session, the EV and charging station will agree upon the mutually supported communication protocol using the message pair Supported App Protocol Request / Response
this message pair allows the EV to set a priority to signalise its preference in case it supports more than one communication protocol
the charging station will then choose the communication protocol it supports. If it can “speak” more than one language –– ie support more than one protocol listed in the EV’s Supported App Protocol Request –– then it will choose the one with the highest priority
for example, let’s assume the EV supports the following protocols and assigns the priorities as listed below. Note that the lower the priority number the higher the priority, ie priority “1” is higher than priority “2”.
- DIN SPEC 70121: Priority = 3
- ISO 15118-2: Priority = 2
- ISO 15118-20: Priority = 1
let’s further assume that the charging station supports the following protocols:
- ISO 15118-2
- ISO 15118-20
in this scenario, the charging station would tell the EV to continue with ISO 15118-20 because both sides support this protocol and the EV prefers -20 over -2, ie it assigned a higher priority to ISO 15118-20 than to ISO 15118-2
once the mutually supported “language” is clear, both sides will use the contract certificate that was issued for the corresponding ISO 15118 version (-2 or -20)
in other words: if both sides agreed to use ISO 15118-20, then they wouldn’t use an ISO 15118-2 contract certificate, and vice versa.

When the same communication protocol is not supported

if the EV and the charging station do not support the same communication protocol, then the only way to charge the EV is by falling back to analogue communication
in this case, the charging station tells the EV the available amperage to charge its battery using a pulse width modulation (PWM) signal, given as a nominal “duty cycle” in the range of 10% to 96%
the higher the duty cycle, the higher the available amperage (and therefore charging power). The specifics of the PWM signal are explained in the IEC 61851-1 standard.

Q: How does Open Smart Charging Protocol (OSCP) live with OCPP 2.0.1? Non-retrocompatible or symbiotically?

A: OSCP is a protocol developed by the Open Charge Alliance, and you can read more about it here. We have not yet heard of any live deployments of this OSCP protocol other than pilot implementations. We’ll certainly be tracking developments as they occur.

‍

Click image to download the presented slide deck

‍

Abbreviations

AC = Alternating Current
ACDP = Automated Connection Device for Pantograph charging
BPT = Bidirectional Power Transfer
CPO = Charge Point Operator
CCS = Combined Charging System
DC = Direct Current
FDIS = Final Draft International Standard
HSM = Hardware Security Module
IS = International Standard
MSP = Mobility Service Provider
OCPI = Open Charge Point Interface
OICP = Open Intercharge Protocol (Hubject)
OSCP = Open Smart Charging Protocol
PKI = Public Key Infrastructure
PWM = Pulse Width Modulation
SAP = Supported App Protocol
SLAC = Signal Level Attenuation Characterisation
TLS = Transport Layer Security
V2B = Vehicle-to-Building
V2G = Vehicle-to-Grid
V2H = Vehicle-to-Home
V2L = Vehicle-to-Load
V2G = Vehicle-to-Vehicle
V2X = Vehicle-to-Everything

Marc Mültin

Marc, the Founder and CEO of Switch, has over 13 years of experience in the e-mobility space and holds a PhD in Computer Science. He is the leading global expert and co-author of international EV communication standards (ISO 15118 & OCPP 2.0.1) that underpin the Switch platform.

— Connect with

Marc Mültin