ISO 15118-20 is the latest edition in the ISO 15118 standard series, a future-proof communication standard for charging electric vehicles (EVs). The ISO/IEC Joint Working Group started developing it in late 2015 and focused on adding new features that didn’t make it into ISO 15118-2. Additionally, we eliminated limitations found while implementing ISO 15118-2 across various market vendors. ISO 15118-20 sets out to become the standard that serves all use cases to support the full range of EVs, be it cars, motor bikes, trucks, buses, ships, and airplanes. Yes, even airplanes. Let’s dive into the most important new features we can expect with the new version of this future-proof communication standard – along with a rough timeline for its market introduction.
ISO 15118-2 specifies messages the EV and charging station exchange to control an AC and DC charging session. Moreover, this standard also supports smart charging functionalities and the user-convenient and secure Plug & Charge feature. ISO 15118-20 is an extension of ISO 15118-2, which additionally supports wireless power transfer (WPT). Each of these services can be offered using bidirectional power transfer (BPT) and an automatic connection device (ACD), which are both explained below.
Here is what you can expect in this guide:
- Bidirectional Power Transfer (BPT, also referred to as V2G)
- Automated Connection Device (ACD)
- Wireless Power Transfer (WPT)
- Dynamic Mode (for Ancillary Services)
- Multiplexed Communication
- Enforced Data Security
- Multi-Contract Handling and Managing Personalized E-Mobility Contracts
- Publication Timeline for ISO 15118-20
- Incompatibility Between ISO 15118-2 and ISO 15118-20
- V2G Clarity’s Implementation Roadmap
Bidirectional Power Transfer (BPT, aka. V2G)
The idea behind Vehicle-to-Grid (V2G) is, as its name suggests, the ability for EVs to provide some energy from its traction battery to the grid when needed as the vehicle is connected to a charging station. The concept is probably as old as Willet Kempton’s first paper on V2G back in 2001, titled “Vehicle-to-grid power: battery, hybrid, and fuel cell vehicles as resources for distributed electric power in California”. Mr. Kempton is considered the father of V2G and I remember reading many of his papers on e-mobility and V2G back in my Ph.D. days in 2009. Fast forward to 2014, where I published my Ph.D. thesis (in German only) to address solutions on two key challenges in the EV space:
- Integrate an EV into a smart home’s energy management system using the ISO-15118-2 standard as a guideline.
- Charge the EV when green energy is available (e.g. through solar panels on the roof) and use the stored energy in the EV’s battery to power the home when needed. The major part of my work took place in a research project called iZEUS.
As you see, V2G is not a new concept and the research on this topic is nearing its 20-year anniversary. The industry finally seems to pick up on this idea, as more and more EV models are introduced to the market, EV sales are growing worldwide, and we are experiencing a significant increase in solar and wind power all over the world – all great preconditions for a successful introduction of V2G-enabled EVs to the market. Recently, both Tesla and GM announced the release of million-mile batteries to the market. Another recent article reported that Tesla secretly introduced a V2G feature in their EVs. This gained momentum is all the more reason why V2G applications should be available in the market even sooner than later, as battery degradation will be even less of an issue than discussed today.
In April 2019, I published an article titled “How Does ISO 15118 Support Vehicle-to-Grid?”. You’ll find more information on how exactly ISO 15118-20 will enable V2G, specifically for the AC charging use case, through various messages and data fields. A few details and naming conventions may be subject to change as we (the members of the ISO and IEC standardization bodies) are still finalizing the specification. Building upon the topics discussed in this article are the technical characteristics of reverse power transfer (aka. BPT) systems, which can be defined with the help of the two parameters introduced in ISO 15118-20: BPTChannel and GeneratorMode.
The BPTChannel parameter is used to make a distinction between single and dual-channel architectures. In the former, a single meter is used for energy flows. In the latter, two separate meters are used for the two opposite energy flows. Consequently, two switches are used and turned on/off depending on the current flow direction.
The GeneratorMode parameter indicates if the system (EV + EV Supply Equipment) operates as a grid following generator (only injecting active and reactive power) or as a grid forming generator, which is able to control the voltage and frequency of the network.
The energy transfer modes AC, DC, and WPT, together with the possibility of bidirectional power transfer and using automated connection devices, yields in a total of 12 possible services offered in ISO 15118-20 so far: AC (1), DC (2), WPT (3), AC_ACD (4), DC_ACD (5), WPT_ACD (6), AC_BPT (7), DC_BPT (8), WPT_BPT (9), AC_ACD_BPT (10), DC_ACD_BPT (11), WPT_ACD_BPT (12). Note that these details may be subject to change until ISO 15118-20 is published.
Automated Connection Device (ACD)
ISO 15118-20 defines ACD as “components supporting the automatic connection and disconnection process for conductive energy transfer between an EV and an EV supply equipment (EVSE)”. The EVSE is basically the device inside a charging station that manages the power flow. One use case of an ACD device would be charging an electric bus using a pantograph, which is an apparatus mounted on the roof of the bus to collect power through contact with an overhead line. In fact, this specific use case is the first one specified in ISO 15118-20, Siemens took the lead in writing down the technical requirements.
Wireless Power Transfer (WPT)
Wireless charging improves the convenience of charging one’s car. Imagine, all you have to do is to steer your EV above a ground pad, then your EV will automatically start to communicate with a device on the ground, steer you towards the perfect parking position for maximum efficiency during power transfer, and start the charging process. You don’t even have to plug in a charging cable. This has the potential to take the user-convenience of Plug & Charge to a whole new level.
For WPT systems, the IEC 61980 series “Electric vehicle wireless power transfer (WPT) systems” is in charge of defining the “General requirements” (IEC 61980-1, aka. Part 1) as well as the “Specific requirements for communication between EV and infrastructure” (IEC 61980-2, aka. Part 2). However, Part 2 refers to ISO 15118-20 for the details on how to transmit all necessary data between the EV and the infrastructure.
This interdependency between IEC 61980 and ISO 15118-20 has caused slight complications as the group within the IEC 61980 standardization body did not yet finally agree on architectural designs and communication methods for wireless power transfer. This necessitates ISO 15118-20 to provide a rather basic framework to allow implementing these WPT use cases. Eventually, we might end up with more generic parameters in the messages related to vehicle positioning and pairing, to allow for ongoing changes in the IEC 61980 spec while ISO 15118-20 is already being released as an international standard.
Meanwhile, ISO 15118-20 will support wireless power transfer, however, we may need to wait for IEC 61980 to finalize their specification and have vendors first introduce WPT solutions to the market, before we can rely on best practices and introduce a second edition of ISO 15118-20 with more detailed parameters for WPT messages.
Dynamic Mode (for Ancillary Services)
ISO 15118-20 introduces a new “Dynamic” control mode next to the already existing “Scheduled” mode (using charging schedules) in ISO 15118-2. Basically, a distinction is made between two main situations: (a) the EV is in charge of ensuring the mobility needs (Scheduled control mode), or (b) ensuring the mobility needs is delegated to an off-board system, which is the charging station (Dynamic control mode):
- Scheduled: The EV and the charging station negotiate a power profile based on the information exchanged with the ChargeParameterDiscovery request and response messages. In this control mode, the EV is responsible for computing a charging profile compliant with the user’s mobility needs – for example how much energy is needed to fully charge the EV’s battery and when the driver needs to leave the charging station – and the charging station’s power limits.
- Dynamic: The control is fully delegated to an off-board system (“off-board” means not inside the EV) and requires no negotiations. The EV sends across the same charging-related parameters to the charging station as in Scheduled mode. But in Dynamic mode, the station responds only with single power set points to the EV without any pricing information or power forecast in the form of a proposed charging schedule, and the EV has to abide by these set points. The off-board system in charge of the control is responsible for ensuring that the user’s mobility needs will be satisfied. This control mode is particularly useful if a fast response mechanism is needed to provide grid services, such as frequency control.
Aside from the regular message flow, where each message is identified with one specific payload type, a multiplexed communication makes use of newly introduced payload types to enable the exchange of certain messages in parallel to the predefined flow control of messages – also known as a state machine. These messages are related to service renegotiation (e.g. changing from charging to discharging energy), system status messages necessary for the ACD use case, exchanging metering information, or parking assistance messages.
For example, while exchanging the DC_ChargeLoop request and response messages during a DC charging session, if either the EV or the charging station would like to change the charging profile (amount of power used over time), they can trigger a scheduled renegotiation without interrupting the existing charging message exchange. The scheduled renegotiation takes place in a parallel side stream with a different payload type. This is especially an advantage for the DC charging process. The original ISO 15118-2 charging process needs to be interrupted because contactors need to be opened and closed during a renegotiation of a charging schedule – something we’d want to avoid.
Enforced Data Security
In ISO 15118, data security is enabled both on the transport layer and the application layer. Transport Layer Security (TLS) 1.2 and above is used to encrypt the communication channel on the transport layer. On the application layer, XML-based digital signatures and X.509v3 certificates are used to verify the authenticity of the sender and the integrity of some of the exchanged messages.
However, for ISO 15118-2, TLS is only mandatory in case the Plug & Charge identification mechanism is used. TLS is optional for EIM (External Identification Means). EIM refers to all authentication types that require additional user effort, like holding an RFID card to the charging station’s RFID reader or using a smartphone app to authenticate and authorize EV charging at a station. The fact that TLS is made optional isn’t a good decision in my opinion, but it was likely pushed for by some standardization members to lower the initial implementation effort.
Luckily, with ISO 15118-20, TLS is mandatory for all use cases and all identification mechanisms, meaning no more security loopholes.
Multi-Contract Handling and Managing Personalized E-Mobility Contracts
The original design thinking behind ISO 15118-2 was for an EV to identify itself to the charging station on behalf of the user with one single contract certificate. Think of it as more of an EV-specific authentication token than a driver-specific token. The certificate used to identify and authorize the charging process is called the “contract certificate”. This certificate is issued by a mobility operator (MO, ISO 15118 jargon) who offers the EV owner an e-mobility contract to enable the Plug & Charge feature. The term MO is often used interchangeably with the term “e-mobility service provider” (EMSP or EMP).
Over the years, the members of the standardization body realized that supporting only one contract certificate as an identification token at any given time comes with its own limitations. Allowing more than one contract certificate makes it possible, for example, to use one dedicated contract certificate for (free) charging at the employer’s premises and another one for charging at the private wallbox at home.
The requirements are now defined in ISO 15118-20 for the smooth installation and use of multiple contract certificates.
At best, the user should not have to worry about choosing the right e-mobility contract depending on the location. Geo-fencing methods could be applied to make intelligent pre-selections for the vehicle driver, however these are beyond the scope of ISO 15118-20.
Publication Timeline for ISO 15118-20
ISO 15118-20 was set to be published in 2020. However, given that many new features were introduced, which required ongoing technical discussions to precisely define the necessary requirements, the newly anticipated publication date of the final International Standard (IS) has yet to be finalised. It all depends on the amount of time we need to resolve all remaining open issues, and we are aiming at a target date in the second half of 2021. International standardization requires the input from many stakeholders across the globe and across various industries, but will be well worth its weight in gold once it is published.
There are various stages of an ISO standard, starting with a Committee Draft (CD) and ending with an IS. The first publicly available version is usually the Draft International Standard (DIS). However, much of the technical details can change between the DIS and the following stage, which is the Final Draft International Standard (FDIS). The FDIS marks a technology freeze from which point on only editorial changes are allowed before publishing the IS.
Currently, the members of the ISO 15118-20 standardization body are preparing a document which we consider as being close to an FDIS. Once that’s ready, we’ll have a few months to thoroughly review the document and provide comments. After the commenting phase is closed, we’ll address all comments in regular weekly web meetings and decide upon sensible solutions and requirements. The result of this stage will be the FDIS, whose publication date is also yet unclear. It all depends on the number of comments received. But again, if I would have to guess, I would expect to submit the FDIS to the ISO early next year with the goal of ISO publishing the FDIS in summer, as it takes a few months for them to publish. This is neither an officially published timeline nor a guarantee from my side, just an estimation based on current knowledge.
Once you can get your hands on the FDIS, you can start implementing ISO 15118-20 freely, without concern of technical changes before the IS is published.
Incompatibility Between ISO 15118-2 and ISO 15118-20
I mentioned in this article that ISO 15118-20 is based on ISO 15118-2. This is where the similarity ends, as they are not compatible to one another, i.e. an ISO 15118-20 compliant charging station won’t be able to set up a communication session with an ISO 15118-2 compliant EV, and vice versa.
There are simply too many differences between those two versions, including different message names, new data types and fields, an array of new messages, and a change in the state machine that defines the message sequence. As a result, XML Schema Definition (XSD) files that are used to encode and decode messages when exchanged between the EV and charging station have also changed.
You’ll still recognize a lot of ISO 15118-2 in ISO 15118-20, so you won’t have to throw away your code base completely, but it’s still a big effort implementing all of ISO 15118-20. On the other hand, no-one will implement this new standard completely. Given the array of features this future-proof standard offers, each EV and charging station manufacturer will pick the features they deem relevant for their product. You can view ISO 15118-20 as a powerful framework of tools from which you pick the elements that are most useful for your business case.
On the bright side, the hardware requirements remain the same. You still need a HomePlug Green PHY compliant modem for both EV and charging station to enable the power line communication. The cryptography does not change either, apart from ditching a less secure cipher suite for a more secure one, which will likely not affect the necessary CPU power. You should, however, reserve more memory on the EV side to be able to store a few more contract certificates (see the section regarding multi-contract handling above).
V2G Clarity’s Implementation Roadmap
My involvement with ISO 15118 dates back to 2010, when I first became an active member of the standardization body, committing my resources to it ever since. Those of you who are interested in an ISO 15118 software stack probably already know RISE V2G, the open source implementation of ISO 15118-2.
I believe that access to e-mobility technology must be as easy and frictionless as possible, which is why I have dedicated my work to educating companies across the globe on ISO 15118, including the ISO 15118 Manual, online courses, and on-site training. There’s even a free online course to get you up and running with RISE V2G in under an hour.
I decided that V2G Clarity will remain on this path and also provide ISO 15118-20 open source, again published under the MIT license – the most liberal license that is compatible even for commercial purposes. This time, we’ll move away from Java and instead implement ISO 15118-20 in Python, but it doesn’t end there. The plan is to have the whole suite of ISO 15118 standards, including ISO 15118-2, ISO 15118-3, ISO 15118-8, and ISO 15118-20, implemented in Python. A fully-fledged, turnkey software library for both the EV and the charging station that is properly tested and documented. I might call this project RISE V2G 2.0, but haven’t yet fully decided. It’s a huge project but it represents our dedication to global sustainability and is aligned with our mission of open innovation and helping the e-mobility industry thrive.
The work on ISO 15118-20 will probably start in July this year. I can’t really say when exactly we’ll have a first stable version published, but I assume it could be by Summer 2021.
I’ll end on this note: which feature are you primarily looking forward to implementing in your product? Let me know in the comments or shoot me an email, I’d love to hear your feedback.