Supporting vehicle-to-grid with ISO 15118, and what does it mean?

‍

‍

Imagine your electric vehicle being more than just a means of transportation from point A to point B. What if it could be part of a green energy revolution — a new trend that emerges from the ever-growing number of renewable energy sources being installed across the globe and the fast-growing number of electric vehicles (EVs) that enter the market. The challenge with these renewables is that the available energy they produce highly depends on weather conditions. It is not uncommon for renewables to provide more power at certain times than the electric grid can accommodate at the same time.

This is where your EV comes into play. Why not use your EV's battery to temporarily store the excessive renewable energy and provide it back to the grid when needed — all while earning some money for providing that service to grid operators? After all, an EV is parked for 23 hours per day on average.

This idea is commonly referred to as vehicle-to-grid (V2G) and it’s not entirely new. There are already numerous projects around the world that experiment with V2G services provided by electric vehicles. The Mobility House, a solution provider for vehicle-to-grid services, has collected and categorised data on (ongoing) V2G projects across the globe, as illustrated in the map below.

‍

‍

At the time of writing this article, only those EVs that are equipped with the Japanese CHAdeMO standard (Nissan, Mitsubishi, and Kia) are capable of feeding energy back to the electric grid.

But this is about to change.

With ISO 15118-20, the newest part of the industry-approved ISO 15118 standard, vehicle-to-grid features have finally arrived. In this article, we’ll walk you through the current draft of ISO 15118-20 and show you how it enables vehicle-to-grid through a set of messages that need to be exchanged between the EV and charging station.

Four steps to initiate vehicle-to-grid support

We’ll only touch on those messages which carry the relevant V2G-related information necessary to control the process of reverse power flow. Let’s get started.

1. Check for available charging services

The EV needs to send a ServiceDiscovery request message to the charging station to ask which charging and identification services the station offers. Charging services include alternating current (AC), direct current (DC), wireless power transfer (WPT), and what is called “automatic connection device” (ACD). The first ACD use case that has been specified so far is charging buses for public transport via pantographs.

Furthermore, ISO 15118-20 allows the EV and charging station to engage into a bidirectional power transfer (BPT). This means that the EV is able to charge and discharge energy during a V2G communication session. BPT is currently only available for AC and DC.

Let’s assume the EV will select a BPT service for AC charging.

2. Mutually exchange charging limits

Further down in the sequence of messages, the EV and charging station will exchange their corresponding technical limits for the bidirectional power flow, using a ChargeParameterDiscovery request and response message pair. Let’s take this message pair as a concrete example to help you maneuver the nested data structure and find the data relevant for the bidirectional energy transfer. This will give you a good understanding of how ISO 15118 works to achieve vehicle-to-grid services.

The image below shows an excerpt from the XML Schema Definition (XSD) file which defines the structure of this ChargeParameterDiscovery request.

‍

XML (Extensible Markup Language) is a machine-readable and human-readable industry standard used to define the sound structure of messages and data types. Think of XSD files as the “grammar rules” to which each message must comply.

Tools like Altova XMLSpy or Oxygen XML Editor make it easy to view and edit XSD files and focus in on the nested data elements. Once you unfold the structure of the ChargeParameterDiscovery request message, you’ll see that all the relevant parameters for bidirectional energy flow are placed in the field BPT_AC_CPDReqEnergyTransferMode. This data element sounds rather cryptic, so let’s walk through its interpretation: The EV ...

• … uses the ChargeParameterDiscovery Request (CPDReq) to inform the charging station that it wants to ….
• … use a BPT service that enables it to charge and discharge energy during this V2G communication session,
• … thereby choosing AC charging as one of the EnergyTransferModes offered by the charging station.

As you can see, this data element contains information about the maximum and minimum power (Watts) and current (Ampere) limits for discharging, which are specific for the BPT use case.

The charging-related parameters (min. and max. charge current, max. charge power, and max. voltage) are inherited from the more generic data type AC_CPDReqEnergyTransferMode.

Furthermore, for all charging and discharging services (AC, DC, ACD, and WPT), the EV needs to provide the same set of information about the following:

• the amount of energy the EV needs to charge (EVTargetEnergyRequest, may have been set by the driver),
  
• the maximum amount of energy needed for a fully charged battery (EVMaximumEnergyRequest), and
• the minimum amount of energy that needs to be charged instantly (EVMinimumEnergyRequest).
  

The EVTargetEnergyRequest can be less than or equal to EVMaximumEnergyRequest. Both values include the energy needed for auxiliary devices, such as the air conditioning used to preheat or cool down the passenger cabin.

If the EV's residual driving range (given in kWh = energy) is lower than a specific minimum driving range set by the user (e.g. for emergency rides to the closest hospital), then EVMinimumEnergyRequest will be positive. If this value is negative, then the EV can start by discharging energy.

This is why BPT_AC_CPDReqEnergyTransferMode inherits these common values from the data type CPDReqEnergyTransferMode. As you can see, ISO 15118-20 tries to group common data elements in parent data structures to avoid repetition wherever possible.

The equivalent data element in the ChargeParameterDiscovery response message is called BPT_AC_CPDResEnergyTransferMode (note the ‘Res’ instead of ‘Req’), as shown in the image below. Here, you see that the charging station (called ‘EVSE’ for ‘Electric Vehicle Supply Equipment’ in ISO 15118) informs the EV of the following:

• the maximum current available at the charging station for charging and discharging energy,
• the nominal voltage, and
• the nominal frequency of the grid.

‍

The charging station can also propose a specific charging or discharging schedule to the EV to influence its charging behaviour (called ScheduleList), but we won’t go down that rabbit hole today. Stay tuned for a blog post on it later.

3. Calculate and send a power profile to the charging station

After having exchanged the technical limits for charging and discharging, the EV can calculate a power profile. The structure of this data is similar to the charging and discharging schedule, which the charging station can propose to the EV in the ChargeParameterDiscovery response. Think of this profile as an ordered list of entries where each entry consists of a duration and a power value. All these entries together form a graph that illustrates a power curve over time. A power value can either be positive, where it will indicate a period of charging energy, or it can be negative, where it will indicate a period of discharging energy. This allows the charging station to plan ahead for the amount of power it will need to provide at each point in time, as long as the EV is connected to the station.

4. Control the charging process in the charging loop

As soon as the power flow starts, the EV and charging station will continuously exchange AC_BidirectionalControl request/response message pairs. The request message contains the same data fields the EV previously sent with the data field BPT_AC_CPDReqEnergyTransferMode. However, it needs to make sure that the values of each of those elements don’t exceed the corresponding static limits defined in ChargeParameterDiscovery. For example: during the charging loop, the EV cannot discharge with a higher power value than it had previously committed to with the ChargeParameterDiscovery request.

The AC_BidirectionalControl request/response message pair also enables the exchange of certain parameters that will help the EV to comply with the local grid code. This is why we see two more data fields in the AC_BidirectionalControl request message. They are:

• EVPresentActivePower
• EVPresentReactivePower

These values serve as important feedback for the charging station, which provides the set-points for these values in the AC_BidirectionalControl response. Here, we see three important grid parameters:

• EVSETargetFrequency
• EVSETargetActivePower
• EVSETargetReactivePower

These values set the ground rules for the EV regarding how to behave as a grid-friendly distributed energy resource when feeding energy back into the grid. This way, the charging station can react upon the actual situation in the grid and demand that the EV provide potential ancillary services.

For more information about grid codes, ancillary services, and a video explaining the terms active and reactive power, head over to the V2G Clarity Knowledge Base and check out the article “What Are Vehicle-to-Grid Services?”.

‍

When will EVs with vehicle-to-grid functionality enter the market?

At the time of writing this article, only those EVs that are equipped with the Japanese CHAdeMO standard (Nissan, Mitsubishi, and Kia) are capable of feeding energy back to the electric grid. Whether or not CHAdeMO will survive in view of the fast, worldwide adoption of the more future-proof ISO 15118 technology is something only the future can tell.

The first generation of ISO 15118-enabled EVs will enter the market in 2019 (e.g. Audi e-tron, Porsche Taycan, smart electric drive since 2017) but they will not support reverse power flow… yet. However, we can expect to see EVs that support V2G via ISO 15118 with the following generation of EVs. This is anticipated within three to five years. ISO 15118-20, the facilitator for this vehicle-to-grid technology, might be released as an international standard (IS) by Q1/2020 or Q2/2020. As with every new international standard, the first implementations will prove whether or not this conceptual approach to providing V2G services for AC charging is already covering all real-life demands on the grid (and whether or not it'll comply to new technical guidelines like EN 50549).

Use cases will eventually determine if bidirectional power flow will be more the case for AC or for DC charging stations. Based on the assumption that EV manufacturers tend to avoid any additional costs that are not absolutely needed in their point of view, it may be more likely to see DC charging stations that offer reverse power flow to the grid. DC chargers do not necessarily have to be high-power chargers (HPCs), which is mainly what is available today. As the costs for DC chargers decrease over time, we may find more and more DC home chargers on the market.

With regards to the use cases, it can be assumed that reverse power flow will primarily be offered at locations where the EV will be connected to the charging station for a longer period of time, such as at home or in an office parking space. This leaves enough time to provide ancillary services if necessary and guarantee that the driver will have a sufficiently charged EV to reach his or her destination.

DISCLAIMER:
The presented message structures are subject to change as technical changes may occur until ISO 15118-20 will be released as an international standard in summer 2020.

Update September 2019:
I gave a talk at the be.connected conference 2019 in Munich during which I presented a few slides relating to this blog post. You can download the presentation here. Simply click on the title: "Vehicle-to-Grid Services for Both AC and DC Charging – Meet ISO 15118-20".

‍