Content uploaded by Paul Klapwijk
Author content
All content in this area was uploaded by Paul Klapwijk on Jan 18, 2021
Content may be subject to copyright.
Content uploaded by Paul Klapwijk
Author content
All content in this area was uploaded by Paul Klapwijk on Jan 18, 2021
Content may be subject to copyright.
REPORT
EV RELATED PROTOCOL STUDY
When to use which protocol? A use case based
approach.
18-01-2017
Version 0.8
* From xkcd.com (http://xkcd.com/927/)
2
Executive summary
Based on its practical experience, ElaadNL has come across many different protocols within the
Electrical Vehicle (EV) domain. The interaction supported by these protocols consists of
exchanging information ranging from authorization identifications (ID) to charge point locations,
but also of sending commands for charging control. In this study, a selection of protocols
encountered by ElaadNL is discussed. These protocols and the relation to the different roles in
the EV market are visualized in the figure below:
In the figure above many protocols are shown, even multiple occurrences of the same protocol
between different roles are visible. At different locations, the use of different combinations of
protocols were found, including a number of different protocols for similar functionality. From
ElaadNL’s role as a knowledge and innovation center in the field of EV charging, this study aims
to give more insight in a set of protocols that is currently in use in Europe and to clarify their
relationship to the electricity grid. This study addresses the question which (set of) protocol(s) is
best applicable for which functionality in different types of situations. To be able to do this, this
study also identifies for each of these protocols which functionalities it supports and how it
scores on interoperability, maturity, market adoption and openness.
This study has led to the following summary of use cases supported by the different protocols
1
:
1
O → Operating Charge Point using 61850-90-8: only the basics
Smart Charging in OCHP: only OCHPdirect and only basics
Smart Charging in eMIP: only 1 OEM (so only 1 car brand)
3
The protocol score on the properties of interoperability, maturity, market adoption and openness
is summarized in the following overview:
This study also confirms that many combinations of protocols are possible, a number of which
are discussed in this study. No combination of protocols is considered a “silver bullet” for all
current and future situations. However, some main conclusions that can be drawn are that:
• the next step for roaming protocols seems to be the addition / extension of smart
charging functionality.
• a choice is to be made whether point-to-point protocols or a clearing house type of
communication is to be pursued, or perhaps both.
• an important smart charging aspect of 15118 is the retrieval of the state of charge. In
some cases, this information can also be retrieved via OEM platforms but only through
specific, non-standardized interfaces. For the short term a next step in the protocols
related to smart charging, could be the addition of connections to different OEM
platforms for getting this state of charge using an open standard.
When looking at the current state of the protocols under consideration, it is recommended to put
more work in the smart charging aspects of the existing roaming protocols and to take a next
step in roaming platforms (e.g. connecting, merging). In order to accelerate the adoption of
smart charging, the state of charge and time of departure are crucial pieces of information. For
getting the state of charge it is recommended to focus on open protocols to include OEMs in the
EV domain. In the longer term, the ISO / IEC 15118 protocol seems to be an alternative for this,
this protocol however does not seem to be implemented in the short term. The first EV’s with
ISO / IEC 15118 basic functionality (“plug & charge”) are expected in mid-2018.
When the time of departure is needed, communication with the EV user might be necessary,
either directly or via the EV (ISO / IEC 15118). A new protocol could be of use here, but this
choice is left to the commercial parties in the EV market. If a protocol is desirable, an “open”
4
protocol should be preferred to avoid lack of adoption due to interoperability issues. When
purely looking at protocols, communicating grid limits or dynamic prices is already possible.
However, current legislation in most countries is not yet prepared for dynamic pricing or setting
grid limits from a power system operator. It is recommended that this legislation is changed
(perhaps even equalized) to make it possible to utilize the flexibility EVs have to offer to the
energy transition.
5
Contents
1. Introduction ......................................................................................................................... 9
1.1 General ........................................................................................................................ 9
1.2 Intended audience ....................................................................................................... 9
1.3 Versions......................................................................................................................10
1.4 Definitions / abbreviations ...........................................................................................11
2. Research questions ...........................................................................................................13
3. Scope ................................................................................................................................13
4. Approach ...........................................................................................................................16
4.1 Use case based approach ..........................................................................................16
4.1.1 Introduction ..........................................................................................................16
4.1.2 Reading guide .....................................................................................................16
4.1.3 Example ..............................................................................................................16
4.1.4 High level use cases ............................................................................................17
4.2 Limitations to the approach .........................................................................................18
4.3 Interoperability ............................................................................................................19
4.4 Market adoption ..........................................................................................................19
4.5 Maturity .......................................................................................................................19
4.6 Openness ...................................................................................................................19
4.7 Scoring EV related protocols .......................................................................................20
5. Protocol analysis ................................................................................................................21
5.1 Smart Charging ...........................................................................................................22
5.1.1 Open Smart Charging Protocol (OSCP) ...............................................................23
5.1.2 OpenADR 2.0 ......................................................................................................25
5.1.3 Open Charge Point Interface protocol (OCPI v0.4) ..............................................29
5.1.4 IEEE 2030.5 (IEEE Adoption of Smart Energy Profile 2.0 / SEP2) .......................31
5.1.5 Smart charging protocols overlap ........................................................................36
5.2 Central System – Charge Point ...................................................................................38
5.2.1 Open Charge Point Protocol (OCPP) ...................................................................39
5.2.2 IEC 61850-90-8 ...................................................................................................42
5.2.3 Central system – charge point protocol overlap ...................................................43
5.3 Roaming .....................................................................................................................45
5.3.1 Open Clearing House Protocol (OCHP) ...............................................................46
5.3.2 Open Charge Point Interface protocol (OCPI 2.1) ................................................49
6
5.3.3 Open InterCharge Protocol (OICP) ......................................................................53
5.3.4 eMobility Inter-Operation Protocol(eMIP) .............................................................55
5.3.5 Roaming protocols ...............................................................................................59
5.4 EV – Charge Point ......................................................................................................61
5.4.1 IEC 61851-1 ........................................................................................................62
5.4.2 ISO / IEC 15118...................................................................................................63
5.4.3 EV – Charge Point protocols overlap ...................................................................67
6. Protocol discussion ............................................................................................................68
6.1 Overview .....................................................................................................................69
6.2 EMSP – CPO communication .....................................................................................70
6.3 EV charging ................................................................................................................72
6.4 Smart Charging ...........................................................................................................73
6.5 Protocol relevance for smart grid from a DSO perspective ..........................................76
6.6 Relation to home charging ..........................................................................................77
7. Conclusion and recommendations .....................................................................................79
7.1 Conclusion ..................................................................................................................79
7.2 Recommendations ......................................................................................................80
Literature ..................................................................................................................................83
Protocol documentation .........................................................................................................83
Other context related documents ...........................................................................................83
Websites of protocol authors / publishers ..............................................................................84
Appendix A: Future plans per protocol ....................................................................................... 0
Appendix B: Protocol use case table .......................................................................................... 2
© ElaadNL, 2016
This document is created by ElaadNL and is intended for providing information about a number of EV
related protocols. It is encouraged to use this information freely where needed. However, when the
information from this document is used, it is highly appreciated when ElaadNL is mentioned as / referred
to as the (original) author.
7
List of figures
FIGURE 1: DISTRIBUTION OF THE PROTOCOLS IN THIS STUDY 15
FIGURE 2: EXAMPLE USE CASE MODEL EXCERPT OF OCPP 17
FIGURE 3: USE CASE OVERVIEW OF OSCP PROTOCOL 24
FIGURE 4: USE CASE OVERVIEW OF OPENADR PROTOCOL 27
FIGURE 5: USE CASE OVERVIEW OF OCPI V0.4 PROTOCOL 31
FIGURE 6: USE CASE OVERVIEW OF IEEE 2030.5 PROTOCOL 35
FIGURE 7: USE CASE OVERVIEW OF OCPP PROTOCOL 40
FIGURE 8: TRAFFIC LIGHT CONCEPT (FROM [CCE2012] ) 44
FIGURE 9: USE CASE OVERVIEW OF OCHP PROTOCOL (EXCL. OCHPDIRECT) 47
FIGURE 10: USE CASE OVERVIEW OF OCHPDIRECT PROTOCOL 48
FIGURE 11: USE CASE OVERVIEW OF OCPI 2.1 PROTOCOL 52
FIGURE 12: USE CASE OVERVIEW OF OICP 2.1 PROTOCOL 54
FIGURE 13: USE CASE OVERVIEW OF EMIP PROTOCOL 57
FIGURE 14: SCHEMATIC COMPARISON OF ROAMING PROTOCOLS 60
FIGURE 15: USE CASE OVERVIEW OF ISO / IEC 15118 PROTOCOL 66
FIGURE 16: OVERVIEW OF PROTOCOLS AND MARKET ROLES 69
FIGURE 17: MORE COMPLEX VIEW OF PROTOCOLS 70
FIGURE 18: POINT-TO-POINT SETUP VS. CLEARING HOUSE SETUP 71
FIGURE 19: MULTIPLE CLEARING HOUSES SETUP 71
FIGURE 20: BASIC EV CHARGING 72
FIGURE 21: CONNECTED CAR MODEL 73
FIGURE 22: SMART CHARGING USING GIREVE PLATFORM 75
FIGURE 23: SMART CHARGING USING ISO / IEC 15118 75
FIGURE 24: SMART CHARGING BASED ON ISO / IEC 15118 WITH MINIMIZED ROLE OF EMSP 76
FIGURE 25: EXAMPLE SETUP INCLUDING (B/H)EMS 77
List of tables
TABLE 1: HIGH LEVEL VIEW ON SMART CHARGING PROTOCOLS ............................................................................... 36
TABLE 2: HIGH LEVEL VIEW ON EV ROAMING PROTOCOLS ........................................................................................ 59
TABLE 3: OVERVIEW OF PROTOCOL FUNCTIONALITIES .............................................................................................. 79
TABLE 4: OVERVIEW OF MATURITY, INTEROPERABILITY AND MARKET ADOPTION .................................................. 79
TABLE 5: FUTURE PLANS PER PROTOCOL ..................................................................................................................... 0
8
List of reviewers
The following people have reviewed this document. All the reviewers come from the EV domain
/ utility industry. OEMs are not extensively consulted (yet):
No.
Name of reviewer
Company
Protocol specialism
1
Claus Amtrup Andersen
Eurisco
IEC 61850-90-8
2
Rolf Bienert
OpenADR Alliance
OpenADR
3
Harm van den Brink
ElaadNL
OCHP
4
Max Dern
smartlab
OCHP
eMIP
5
Lonneke Driessen-Mutters
ElaadNL
General review
6
Christian Hahn
Hubject
OICP
7
Leon Huijsdens
ICT Group
OSCP
OCPP
OCPI v0.4
OCPI 2.1
8
Robert de Leeuw
iHomer
OCPI v0.4
OCPI 2.1
OCPP
9
James Mater
QualityLogic
OpenADR
IEEE 2030.5
10
Brendan McMahon
ESB
OCPP
11
Patrick Rademakers
Symeon
General review
12
Jean-Marc Rives
GIREVE
eMIP
13
Jens Schmutzler
TU Dortmund University
IEC 61850-90-8
ISO / IEC 15118
14
Simon Schilling
wiedergruen.com
OCHP
OCPI
OICP
15
Richard Scholer
FCA
IEEE 2030.5
16
Mourad Tiguercha
Trialog
IEC 61850-90-8
17
Arjan Wargers
ElaadNL
General review
18
Klaas van Zuuren
ElaadNL
OCPP
IEC 61851-1
9
1. INTRODUCTION
1.1 General
This study presents a discussion of a selection of Electric Vehicle (EV) related communication
protocols
2
and a comparison based on the functionality that is supported by those protocols.
One of the goals of the discussion is to provide information about the functionality of the
protocols. Based on the list of functionalities per protocol, an analysis is done on how protocols
can be used in conjunction with each other and / or perhaps how protocols overlap. This is to
provide information that can be used by others, for example for enabling standard
harmonization or enabling grid and system interoperability. In some cases different
combinations of protocols can be used to reach the same goal. Another aim of this study is to
make clear which of these combinations are possible and would currently make the most sense.
Although this study is not limited to distribution system operator (DSO) protocols, especially on
the smart charging protocols, the primary view of their applications and use will be from a DSO
perspective.
The comparison will not go into the details of the messages or data fields of the protocols, but
will stay on the level of supported functionalities. This study is not meant to judge or criticize
protocols. The analysis in this protocol study will compare the functionality but is not intended as
a value judgment on the quality aspects of the protocols.
This report has been reviewed by a number of protocol experts (for some protocols even the
original authors) to make sure the functionalities mentioned in this report are correct. As input
we used the latest versions of the protocols, as they were available at the time of writing. See
chapter 3 for the protocols in scope, including the versions used. Functionalities that are
planned for new releases are not considered in this report.
1.2 Intended audience
This document is intended for people that have some prior knowledge of the EV domain, for
example decision makers with some knowledge of EV / Smart Charging or people that already
have knowledge of one or more protocols and need more clarity in the large amount of other
protocols that are currently available. Besides providing clarity, this document also aims to
provide context for the different protocols and how these can be used in conjunction with each
other. When starting in the EV domain, it is recommended to first get a global overview of the
EV domain and terminology. For a proper understanding of this study, such knowledge is
required and assumed.
2
The term protocol is used in a broad way in this study. So for example OpenADR specifies a datamodel including
transport and security mechanisms. However, combined with the xsd’s, this can be used to communicate and in this
study this will be referred to as a “communication protocol” or simply “protocol”.
10
1.3 Versions
Version
Date
Author
Remarks
0.1
9/7/2016
Patrick Rademakers
Paul Klapwijk
First draft
0.2
9/19/2016
Paul Klapwijk
• Processed the Review comments of Jonel
Timbergen.
• Elaborated chapters 1-4.
0.3
10/04/2016
Paul Klapwijk
• Version for review Patrick Rademakers
0.4
10/28/2016
Paul Klapwijk
• Version after review Patrick Rademakers &
Lonneke Driessen
0.5
11/10/2016
Paul Klapwijk,
Lonneke Driessen
• Version after review Arjan Wargers and
incorporating information from J2847/1
0.6
14/12/2016
Paul Klapwijk,
Lonneke Driessen
• Version after (partial) review of:
o Patrick Rademakers
o Claus Amtrup Andersen
o Robert de Leeuw
o Richard Scholer
o James Mater
o Harm van den Brink
o Léon Huijsdens
o Klaas van Zuuren
o Max Dern
o Mourad Tiguercha
o Jean-Marc Rives
o Rolf Bienert
0.7
02/01/2017
Paul Klapwijk,
Lonneke Driessen
• Version after review of:
o Rolf Bienert
o Max Dern
o Klaas van Zuuren
o Robert de Leeuw
o Richard Scholer
o James Mater
• Added pictures by Marcel Nahapiet
• Added tables by Shapeshifter.nl
0.8
18/01/2017
Paul Klapwijk,
Lonneke Driessen
• Version after review Simon Schilling
• Added some input from IEC discussion.
• End review by Arjan Wargers
0.9
19/01/2017
Paul Klapwijk,
Lonneke Driessen
• Added cover by Shapeshifter.nl
1.0
20/01/2017
Paul Klapwijk,
Lonneke Driessen
Version 1.0
1.1
24/01/2017
Paul Klapwijk,
Lonneke Driessen
Minor changes
11
1.4 Definitions / abbreviations
Term
Definition
BRP
Balance Responsible Party
Clearing
Clearing is a term from the finance industry. In the EV market it refers to the
process of exchanging information such as transaction information (“CDRs”) for
billing (“settling”) and roaming purposes.
Clearing House
A Clearing House is an institution or system that facilitates (automatic) clearing.
Connector
A Connector is an independently operated and managed electrical outlet on an
EVSE.
CPO
Charge Point Operator. Party that operates and maintains charge points.
DER
Distributed Energy Resources. “Distributed energy [..] is generated or stored by
a variety of small, grid-connected devices referred to as distributed energy
resources. DER systems typically use renewable energy sources, including
small hydro, biomass, biogas, solar power, wind power, and geothermal power,
and increasingly play an important role for the electric power distribution
system”3.
DR
Demand / Response. This refers to “changes in electric usage by demand-side
resources from their normal consumption patterns in response to changes in
the price of electricity over time, or to incentive payments designed to induce
lower electricity use at times of high wholesale market prices or when system
reliability is jeopardized4.” See paragraph 6.4 for a further explanation of the
relation to EV and smart charging.
DSO
Distribution System Operator. A netoperator or gridoperator.
eMIP
eMobility Inter-Operation Protocol
EMSP / eMSP
E-Mobility Service Provider. Party that handles all communication and billing
towards EV users. These roles of EMSP and CPO are not separated in all
markets, in some countries these roles are filled in by the same party. However,
this distinction is still relevant for enabling customers of party to use a charge
point of another party.
ESI
Energy Service Interface
EV
Electric Vehicles that have battery energy storage (sometimes referred to as
Battery Electric Vehicle, BEV). This includes PHEV (Plugin Hybrid EV).
EVSE
Electrical Vehicle Supply Equipment. The logical unit in a Charge Point that
supplies electric energy via a Connector for charging. An EVSE can have one
or multiple Connector(s).
Flexibility
Within the energy system this refers to the property that indicates to what extent
adjusting generation and / or consumption patterns in reaction to an external
signal (e.g. price signal) is possible.
Within the EV domain flexibility more or less equals smart charging.
3
https://en.wikipedia.org/wiki/Distributed_generation
4
https://www.ferc.gov/industries/electric/indus-act/demand-response/dem-res-adv-metering.asp
12
IEEE 2030.5
The IEEE adoption of Smart Energy Application Profile 2.0 (SEP 2)
IP
Intellectual Property
OCHP
Open Clearing House Protocol
OCPI
Open Charge Point Interface
OCPP
Open Charge Point Protocol
OEM
Original Equipment Manufacturer. Refers to EV manufacturers.
OICP
Open InterCharge Protocol
OpenADR
Open Automated Demand Response
OSCP
Open Smart Charging Protocol
PEV
Plugin Electric Vehicle
PV
Photovoltaics. This “covers the conversion of light into electricity using
semiconducting materials that exhibit the photovoltaic effect, a phenomenon
studied in physics, photochemistry, and electrochemistry. A typical photovoltaic
system employs solar panels, each comprising a number of solar cells, which
generate electrical power."5
Roaming
In the telecom industry roaming is the ability of users to make us of their
phones/subscriptions beyond the limits of the network of their provider of
choice. It also covers the agreements between providers to make this possible.
In the EV domain roaming is very similar: this is what allows EV drivers charge
their EV at charging stations that are not part of the charging network of their
CPO using the same identification.
SEP
Smart Energy Profile
Smart Charging
According to [CCE2012] and [EUEL2015] the definition of smart charging is
when charging an EV can be externally controlled (i.e. “altered by external
events”), “allowing for adaptive charging habits, providing the EV with the ability
to integrate into the whole power system in a grid- and user-friendly way. Smart
charging must facilitate the security (reliability) of supply and while meeting the
mobility constraints and requirements of the user.”
TSO
Transmission System Operator
5
https://en.wikipedia.org/wiki/Photovoltaics
13
2. RESEARCH QUESTIONS
This study aims to answer a number of research questions. The first question is targeted at the
functionality of the protocols, to give an overview of these and what these can be used for.
Besides describing functionality, it is also useful to have a look at the maturity of the protocols
and whether or not these are already used in the market. This leads to the following research
question:
1. What functionalities are supported by the EV related protocols within the scope of this
document (see chapter 3)?
Sub question: How do these protocols score on the following properties:
a. Interoperability?
b. Maturity?
c. Market adoption?
d. Openness?
Besides providing information, another aspect is how the protocols can be used and how the
protocols can be used in conjunction with each other. This leads to the second research
question:
2. In various situation
6
what set of protocols is best applicable for what end-to-end
functionality?
Finally, it is also important to determine how relevant the protocols are from a smart grid
perspective. Since EVs can charge with relatively high power compared to other residential
loads on Low Voltage (LV) level, possibly at the same time period at a specific LV cable, this
can lead to new challenges for DSOs. This is because at many locations the current electricity
grid is not prepared for / suitable for high EV adoption and the large power demand of these
EVs (demanded simultaneous at a relatively short period of time). This leads to the final (sub)
question:
Which of the protocols are useful in managing the grid operational impacts of high
penetration of EV charging?
3. SCOPE
As indicated in the introduction, this study discusses a selection of Electric Vehicle (EV) related
protocols. ElaadNL bases this selection on the practical market experience
7
that it has
accumulated over the past years, the protocols that it has encountered in the EV market and
pilot projects that have been executed by ElaadNL and partners. Additionally, this study tries to
make clear which combinations of protocols are possible to serve specific use cases (such as
“smart charging”) and to what extent protocols are similar and/or overlap.
6
Situation in this case refers to for example the traffic light concept as referred to by, for example, the Smart Grid Coordination
Group (CEN-CENELEC-ETSI, 2012).
7
Primarily in Europe.
14
The scope of this document concerns the following protocols:
Protocol
Version
Author / Maintainer
Year of publ.
PART I: Smart Charging
Open Smart Charging Protocol (OSCP)
1.0
Open Charge Alliance
2015
OpenADR 2.0
1.1
Lawrence Berkeley
National Laboratory and
OASIS Energy
Interoperation Technical
Committee.
2015
Open Charge Point Interface (OCPI)
0.48
eViolin
2014
IEEE 2030.5 / Smart Energy Profile (SEP)9
2.0
IEEE
2013
PART II: Central System – Charge Point
OCPP
1.6
Open Charge Alliance
2016
IEC 61850-90-8
n.a.
IEC
2015
PART III: Roaming
Open Clearing House Protocol (OCHP)
1.4
Smartlab, ElaadNL
2016
Open Charge Point Interface (OCPI)
2.1
Nationaal Kennisplatform
Laadinfrastructuur(NKL)
2016
Open InterCharge Protocol (OICP)
2.1
Hubject
2013-2016
eMobility Inter-Operation Protocol (eMIP)
0.7.4
GIREVE
2016
PART IV: EV – Charge Point
IEC 61851-1
N.a.
IEC
2010
ISO / IEC 15118
N.a.
ISO / IEC
2013/2014
For each of these protocols an overview of the supported use cases will be described. Please
see the description of the chosen approach in chapter 4. Each protocol is described in a
separate paragraph which includes sections describing the maturity, interoperability, market
adoption and openness of the protocols.
The communication protocols are divided in 4 parts. This division is primarily based on the
different roles and systems in the market and how the protocols are positioned between these
8
Although this is an older version of the OCPI protocol, it is included in the overview, due to the fact that it is still widely used within
the EV market. It is also often referred to as draft v4 or even 1.0 draft 4.
9
This protocol is officially referred to as IEEE 2030.5.
15
roles and systems. From an ElaadNL perspective, the DSO side of the EV domain, and
therefore smart charging, is particularly interesting. However, smart charging and EV
penetration also depend on the rest of the EV chain. Therefore these parts are also part of the
practical research at ElaadNL and thus part of this study. Due to the fact that some protocols
are quite generic, these might fit in more than one “part”. This is visualized in Figure 1.
Figure 1: Distribution of the protocols in this study
10
10
As you can see in the figure, IEC 61850-90-8 can be positioned both in the smart charging section as well as the
EVSE <> CPO section. The choice was made to describe it in the EVSE <> CPO section.
16
4. APPROACH
4.1 Use case based approach
4.1.1 Introduction
As already indicated in the introduction of this document, the approach chosen for creating an
overview of the protocols in scope, is an approach based on functionalities. Describing the
functionality supported by the protocols is done by looking at the use cases that are supported
by these protocols. Usually in software development, use cases are used to systematically and
exhaustively describe the functionality of a system that can be further detailed in scenarios. In
this study use cases are not used to describe systems, but functionalities that are supported by
a protocol. Furthermore, the use case model is elaborated with more high-level use cases (like
“Billing” and “Roaming”). The use case based approach can be considered a bottom up
approach, which provides a, to some extent, systematic way to perform a neutral comparison.
4.1.2 Reading guide
This document is aimed at multiple audiences. For some of the more extensive protocols, the
use case based approach will lead to large diagrams. Therefore, for each protocol a use case
diagram is created, including a short summary of the main functionality. When reading this
document, it should be kept in mind that the diagrams are only for expert readers or people that
want to know more details on a specific protocol (exact functionalities, what role can execute
what functionality etc.). When reading this study to get an overview of the available protocols
and main functionalities, the diagrams can be skipped and the summaries should suffice. After
each “part” of the document, a separate chapter is added to discuss and compare the protocols
including overlap.
4.1.3 Example
To clarify the approach, this is illustrated by the following example:
Figure 2, which is an excerpt from the OCPP use case diagram, shows that the actor CPO can
use the OCPP protocol to “Execute Smart Charging commands” (which results in an information
flow to a charge point). This use case is “typed” as an OCPP use case (marked with <<OCPP
Use Case>>). However, to be able to derive overlapping or complementary protocols, the use
case model is extended to higher level use cases. The diagram indicates that “executing Smart
Charging commands” is part of “Schedule based charging”. This is a more specific type of
“Managing power consumption of a charge point”, which in turn is a more specific type of
“Decreasing / increasing power consumption of individual devices”.
17
Figure 2: example use case model excerpt of OCPP
These last 2 use cases are marked as “Multiple protocol” use cases, which indicates that these
use cases are also (partly) covered by other protocols (in this specific case: OpenADR, OCPI
and OCHP). Overlapping or complementing functionality is not easily visible by looking at the
different diagrams. Therefore an overview of the use cases and the protocols that are applicable
for these use cases is added in Appendix B: Protocol use case table.
On a higher level a number of Use cases are defined, such as “Billing”, “Operate Charge Point”,
“Roaming”, “Smart Charging”, etc. Finally an overview of use cases will be made, including the
protocols that are applicable for these use cases. Furthermore, overlap between protocols will
become visible and also examples will be given of sets of protocols that can be used to fulfill a
high-level use case.
4.1.4 High level use cases
The high level use cases that are considered in this study are the following:
Use case
Definition
Authorize charging session
In this study this involves allowing a token /
identification to charge at a charge point.
uc Exa mple excerpt from OCPP
CPO
«OCPP Use Case»
Exec ute Smart
Charging commands
Charge Point
«Mul tipl e protoc...
Schedule based
charging
«High level use...
Smart Charging
«Mul tipl e protoc...
Decrease/ increase
power consumption
of individua l devic es
«Mul tipl e protoc...
Manage power
consumption of
Charge Point
«High level use...
Manage grid
«include»
«include»
Smart ch arging schedu les / comm ands
«flo w»
18
Billing
The standard definition for billing is “the process
of sending an invoice to customers for goods or
services”11. In this study this mainly involves
exchanging Charge Detail Records (CDR’s).
EV charging
In this study this refers to the actual charging
(energy flowing), not the administrative process
surrounding it.
Handle registration
In this study this involves handling communication
registrations / subscriptions. In some protocols
this happens manually, in some protocols
automatically. In case this is part of the protocol
and thus a possibility to do this automatically, this
is described with this use case.
Manage grid
In this study this refers to being able to control a
charge point, both the amount of capacity that is
demanded from the grid as well as other factors.
Operate charge point
In this study this involves being able to operate a
charge point from a back office. This includes
upgrading firmware, setting a charge point to
available or unavailable / reserved / error,
configuring charge points and repairing faults.
Provide charge point information
In this study this involves providing information
about a charge point. This can be both static (e.g.
location) as well as dynamic (availability)
information.
Reservation
In this study this involves functionality that is
needed for an EV user to reserve a charge point.
Roaming
In this study this involves exchanging information
(primarily authorization) to enable EV users to
charge using 1 token at different charge points of
different EMSPs and CPOs
Smart Charging
In this study this involves all forms of smart
charging (for whatever reason), ranging from
simply being able to stop / restart charging during
a charging session to schedule based charging.
4.2 Limitations to the approach
As with every approach, our approach as described in 4.1 also has some drawbacks. The main
drawback is that this approach is not perfectly applicable for all protocols. Some of the protocols
discussed are quite generic while other protocols are developed for a very specific situation /
use case. This makes it somewhat harder to compare different types of protocols, however, it
seems the best way to have a systematic and neutral comparison.
Another drawback concerns the different granularity of the protocol messages. To prevent
getting lost in minor details, the use case model is based on use cases / terminology that
sometimes unavoidably abstracts away some of the message details. Despite these limitations,
11
See for example Wikipedia.
19
we consider a use case based approach as the most neutral and exhaustive way to describe
the protocols and the best way to do a comparison study. This avoids the limitation of not
implemented parts of protocols in systems or environment specific use of a protocol.
4.3 Interoperability
Interoperability is considered on different levels. Besides technical interoperability, syntax and
semantics, another level of interoperability is considered: expected / desired behavior. If
behavior is specified in more detail, this usually means that interoperability is higher. However,
this usually also means that a protocol is less generic, which makes it less applicable in other
environments than it was originally intended for. Other factors that influence the interoperability
is how clear the specification is, the amount of optional elements
12
, the possibility to implement
one functionality in multiple ways and the availability of “interop events”. The focus will be less
on the commissioning part of protocols, but more on the effort when “replacing” the other side.
The factors mentioned here, will together determine the interoperability score.
4.4 Market adoption
Market adoption is based on the current number of users, companies or countries that use the
protocol. This will give an impression of the market adoption, but since the markets for EV and
flexibility are currently emerging / in development, it is not possible to use extensive statistics
and number of users / countries / companies to give a detailed overview of the market adoption
of protocols. Many protocols in this study are “open” (see below) and do not (yet) have
certification in place, which means that it is not always known to the authors of a protocol
whoever is actually using their protocol. Therefore, this score will be based more on experience
and estimations than hard numbers.
4.5 Maturity
As with market adoption, the maturity of a protocol is hard to determine in detail. In this study,
the score will be based on: number of releases, time in use, market adoption, certification
possibility (at an official test laboratory), availability of a testing tool (dedicated / specific),
availability / detail of the (test) specification and the possibility to implement only basic / relevant
parts.
4.6 Openness
For scoring the protocols on the property “openness”, we assess whether the standard has
been developed by an accredited standards organization, whether it is subject to intellectual
12
Please note that optional elements do not necessarily mean that a protocol is multi interpretable / has a lack of
precision.
20
property
13
(IP) licensing and/or royalties or other implementation/usage restrictions and whether
the specification is publically accessible at no (or minimal) cost.
4.7 Scoring EV related protocols
In this study, scoring the different properties of the protocols is done on a (very) low / medium /
high scale. This scale is used while taking into account the maturity of the EV domain. This
means that a “high” score on, for example, “maturity” is not to be compared to the maturity of
standards like the WiFi standard. This would limit the scale due to the fact that the EV market is
still an upcoming market. A “high score” should thus be interpreted as a “high score within the
EV domain”.
13
To the knowledge of the author and reviewers.
21
5. PROTOCOL ANALYSIS
This chapter gives an overview of the different protocols. This chapter is divided in 4 parts:
1. Smart Charging
2. Central System – Charge Point
3. Roaming
4. EV – Charge Point
Each protocol will be described in a number of sections, containing an introduction, a use case
overview and paragraphs about maturity, interoperability, market adoption and openness.
Every part will cover at least 2 protocols and will be concluded with a paragraph about the
overview of the differences between the protocols and the overlap (if any).
22
5.1 Smart Charging
“WHEN CHARGING, AN EV CAN BE EXTERNALLY CONTROLLED (I.E. “ALTERED BY EXTERNAL
EVENTS”), ALLOWING FOR ADAPTIVE CHARGING HABITS, PROVIDING THE EV WITH THE
ABILITY TO INTEGRATE INTO THE WHOLE POWER SYSTEM IN A GRID- AND USER-FRIENDLY
WAY.
SMART CHARGING MUST FACILITATE THE SECURITY (RELIABILITY) OF SUPPLY AND WHILE
MEETING THE MOBILITY CONSTRAINTS AND REQUIREMENTS OF THE USER.”
[EUEL2015]
23
5.1.1 Open Smart Charging Protocol (OSCP)
Introduction
The Open Smart Charging Protocol communicates forecasts of the available capacity of the
electricity grid to other systems. This protocol has first been created by Dutch DSO Enexis and
EMSP
14
/ CPO GreenFlux but has been transferred for further development to the Open Charge
Alliance.
The protocol is based on a budgetary system where client systems can indicate their needs to a
central system, which guards against overuse of the grid by handing out budgets per cable. If a
system requires more it can request more, if it requires less it can hand back part of its budget,
to be available for other systems.
OSCP has no direct relationship with charge points, the protocol is by design more generic. It
can, in principle, be used for allocation of capacity in general (energy, bandwidth, euro’s etc.)
from a higher level system to a lower level system. However, the naming is quite DSO specific.
The exact reason why a client system manages power is out of scope of the protocol.
Use cases supported by OSCP
Figure 3 illustrates the use cases that are supported by OSCP. The use cases supported by
OSCP are currently quite specific for the scenario where a DSO manages grid capacity by
distributing capacity forecasts i.e. to either EMSP’s or CPO’s. The high-level use cases as listed
in paragraph 4.1.4 supported by OSCP are:
• Smart charging (capacity based)
• Manage grid
In more detail, it includes:
• Handing out capacity budgets
• Managing grid capacity using these budgets
• Smart charging by communicating capacity forecasts
14
See 1.4 for the definition of EMSP and the relation to a CPO.
24
Figure 3: Use case overview of OSCP protocol
Maturity
The current OSCP version is 1.0 and dates from 2015-04-09. This is the first public version of
the protocol. The level of detail of the specification is moderate, no test specification is
available. Furthermore, the specification does not mention whether or not all parts of the
standard are to be implemented, although this is suggested by the (behavior) scenario which is
explained in the specification. No plans for new versions / releases from the Open Charge
Alliance are known. Currently certification is not possible, no testing tool is available.
Based on the above, the maturity if the protocol is classified as low.
Interoperability
The protocol describes a quite specific use case including the prescribed behavior of the actors
that are involved. The messages are defined in a strict WSDL (schema). It is not specified which
messages are mandatory and which are not. The interoperability between parties on a technical
uc OSCP
DSO
«OSCP Use Ca...
Send Capac ity
Forecasts
«OSCP Use Ca...
Request Capacity
Forecast
«OSCP Use Ca...
Request capacity /
Indicate ne eds
«OSCP Use Ca...
Send Aggregated
Usage
Manage grid
capac ity by
communicating
cable capacity
forecasts
«Hig h le vel use...
Manage grid
«OSCP Use Ca...
Send DSO
Heartbeats
«OSCP Use Ca...
Hand out capacity
"budgets"
Influence grid usage
Peak shaving
«Hig h le vel use...
Smart Charging
«Mu lti ple prot o...
Exchange metering
data
eMSP / CPO
«include»
«include»
«include»
«include»
«include»
«include»
«include»
25
level is high, the behavior level it is classified as medium / high. The overall interoperability is
classified as high.
Market adoption
OSCP version 1.0 is in use at fewer then ten locations in the Netherlands for smart charging
based on available capacity (for a combination of building and parking garage). No active
development takes place. It is currently used at 2 DSO’s in the Netherlands and (at least) one
CPO. Several parties have shown interest in the protocol, but no other locations are known
where OSCP is actively used.
The market adoption is therefore classified as low
Openness
The OSCP protocol is publically available at no cost from the website of the Open Charge
Alliance, containing no IP besides the copyright by the Open Charge Alliance (since OCA is the
author). However, OCA is not considered an accredited standards organization. The openness
is therefore classified as medium.
5.1.2 OpenADR 2.0
Introduction
The Open Automated Demand Response standard is a (dynamic) Demand Response protocol,
developed by the United States (U.S.) Department of Energy’s Lawrence Berkeley National
Laboratory (LBNL) since 2002, formally published, as a standard by the international standards
development organization, the Organization for the Advancement of Structured Information
Standards (OASIS) Energy Interoperation Technical Committee and maintained by the
OpenADR Alliance. The OpenADR Alliance (US-based) has members from all over the world,
including grid companies, research institutes and commercial component and infrastructure
companies. According to the specification, “the development of [..] OpenADR began in 2002
following the California electricity crisis”.
As the name implies, the protocol is aimed at automating demand response communication, it
supports a system and / or device to change power consumption or production of demand-side
resources. This can, for example, be done based on grid needs, either by means of tariff and /
or incentives or emergency signals that are intended to balance demand to sustainable supply.
Use cases supported by OpenADR
In Figure 4 (see next page) the use cases that are supported by OpenADR are visualized. The
high-level use cases as listed in paragraph 4.1.4 that are supported by this protocol are:
• Handle registrations (registering a virtual end node at a virtual top node
15
)
• Manage grid
15
The terminology in OpenADR is generic. Publishers of information are called virtual top nodes (VTN), subscribers
to information are virtual end nodes (VEN). There could be any amount of VTN/VEN pairs based on market needs.
26
• Smart charging
In more detail it can also be used for
• Sending price and load control signal, which can be used for decreasing / increasing
power consumption of individual devices, which is a form of managing a (smart) grid.
• Sending reports. In the EV context this can for example be standardized metering data
from a charge point (for example for monitoring and validating performance), charge
levels (in case of V2G), use times for forecasts etc.
27
Figure 4: Use case overview of OpenADR protocol
uc OpenADR
«Mul tiple proto...
(De)register
Distribute dynamic
prices
«Mul tiple proto...
Set resource
ava ilability
«Open ADR Use...
Distribute DR ev ent
Virtual Top Node
Virtual End Node
«Open ADR Use...
Receiv e DR ev ents
«Open ADR Use...
Respond to DR
eve nt
«Open ADR Use...
Send Ev ent Signal
«Open ADR Use...
Send simple signal
«Open ADR Use...
Send elec tricity
price signa l
«Open ADR Use...
Send energy price
signal
«Open ADR Use...
Send demand
charge si gnal
«Open ADR Use...
Send customer bi d
lev el signal
«Open ADR Use...
Send charging
dispatch signal
«Open ADR Use...
Send load dispa tch
signal
«Open ADR Use...
Send load control
signal
«Open ADR Use...
Handle VEN
registrations
«Open ADR Use...
Send Report
«Open ADR Use...
Send data report
«Open ADR Use...
Send metadata
report
«Open ADR Use...
Receiv e report
«Open ADR Use...
Send Opt-In / Opt-
Out schedules
«Open ADR Use...
Receiv e / proces s
Opt-In / Opt-Out
schedules
Influence grid usa ge
«High level u se...
Manage grid
«High Level Us...
Handle registra tion
«Mul tiple protocols»
Decrease/ increase
power c onsumption of
individua l devic es
«High level u se...
Smart Charging
«Open ADR Use Ca...
Manage grid capacity
by communicating
price / loa d control
signals
«Mul tiple proto...
Demand Response /
load control
«Mul tiple proto...
Exchange m etering
data
«include»
«include»
«include»
«include»
«flow»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«flow»
«include»
«include»
«include»
«include»
«flow»
28
Maturity
The current version of the OpenADR 2.0b standard is 1.1 (with minor updates to the version 1.0
published in 2013). The OpenADR Alliance, which was formed in 2010, supports the
management of a formal standard published by OASIS. The OpenADR standard is divided into
several “profiles” (A and B, where the A profile is a sub-set of B profile, hence “2.0a” and “2.0b”)
and does not only describe the messages in the protocol, but also provides registration, the
transport protocol and security. The specification defines which parts of the standard are to be
implemented to be OpenADR compliant. There are (members only) on-site interop tests in an
authorized OpenADR Alliance test lab or other suitable facility. Furthermore members can
purchase an Alliance testing tool that is identical to the test harness used by the authorized
certification test labs to complete the certification testing.
Based on the above, the maturity of the protocol is classified as high.
Interoperability
The OpenADR alliance organizes interoperability test events, provides a testing tool and
certification. Testing and certification includes a number of mandatory cases that are tested and
certified to ensure that any client can communicate when installed and enrolled. This means
that the technical interoperability (both syntax as well as semantics) is high.
The protocol is quite generic (due to the nature of DR programs), which means that it can be
used in a wide range of areas. Since the DR program message content is an outcome of a
specific implementation, this genericity makes it impossible to describe the exact signal content
and behavior for interoperability with every program. To limit the variability of the implementation
scenarios, the OpenADR Alliance has published A “DR Program Guide” that sets out to
harmonize the programs and add additional certification options. Basic EV charging is
considered. On the behavior level the interoperability is therefore classified as medium.
Market adoption
According to the website, the alliance has 130 member companies and the database of
OpenADR certified products contains over 100 products. The standard has been adopted for
use in the US, South Korea, Japan, and Canada and is under consideration in Europe and
elsewhere in the world. Based on this, the market adoption of OpenADR is medium / high.
Openness
The OpenADR protocol specification profiles A and B are publicly available at no cost from the
website of the OpenADR Alliance. The standard does not have any IP associated with it. The
alliance is not considered an accredited standards organization but the OpenADR 2.0 A and B
profiles are based on a standard called Energy Interoperation that has been formally adopted as
an international standard by the OASIS standards organization. In addition, the IEC has
approved the OpenADR 2.0b specification as a “Publicly Available Specification” (PAS) as a
basis for a new IEC commission standard to be developed.
The openness is therefore classified as high.
29
5.1.3 Open Charge Point Interface protocol (OCPI v0.4)
Introduction
The Open Charge Point Interface protocol is designed for exchanging information about charge
points. The protocol is for exchanging information between the market roles of Charge Point
Operator and e-Mobility Service Provider. These roles are not separated in all markets. In some
countries these roles are filled in by one party. However, these split up roles are still relevant for
enabling customers of one party to use a charge point of another party (“roaming”).
The OCPI protocol originates from the Dutch EV market, where, starting in 2009, a number of
CPOs and EMSPs (collaborating under the name eViolin) together with ElaadNL, created a first
version of a protocol for exchanging information concerning charge points. Eventually in 2014
this resulted in the development of OCPI. Version 0.4 (also called “draft v4” and “1.0 draft 4”) is
an old version of the OCPI protocol. However, despite being far from perfect / finished, is in use
at several market parties within the Dutch energy market. For this reason it is also taken into
account in this study. This version is not compatible in any way with the newer version 2.1
discussed later in this study (total redesign).
Use cases supported by OCPI
In Figure 5 the use cases which are supported by OCPI are visualized. The high-level use
cases as listed in paragraph 4.1.4 that are supported by this protocol are aimed at a
combination of smart charging and roaming:
• Providing charge point information
• Reservation
• Smart charging
• Authorizing charging sessions
• Roaming
In more detail:
• Providing charge point information concerns information about location and tariff.
• Information that can be exchanged concerns smart charging, reservations and
authorization tokens.
Maturity
The version 0.4 of the OCPI protocol is a draft version that was not really “finished” before it was
taken into use. The level of detail of the specification is low, no test specification is available.
Furthermore, the specification does not mention whether or not all parts of the standard are to
be implemented. Newer versions of the protocol are being developed within "NKL Nederland", a
Dutch cooperation of organizations involved in public charging. Certification is not possible. No
testing tool is available.
30
Based on the above, the maturity if this version of the protocol is classified as very low
16
.
Interoperability
Due to the low maturity of the protocol, the interoperability is very low. To enable communication
between 2 systems using OCPI v0.4, several additional bilateral details have to be decided on.
Market adoption
The version of the OCPI protocol under consideration is only in use by a number of Dutch
market parties. The market adoption of the protocol is therefore considered as low.
Openness
The OCPI v0.4 protocol is not publically available from the website of NKL Nederland. Copies of
the protocol specification however do circulate and the protocol can be used no cost, it contains
no IP. NKL Nederland is not considered an accredited standards organization.
The openness is therefore classified as low.
16
Development by NKL has resulted in version 2.0 (1.0 was skipped).
31
Figure 5: Use case overview of OCPI v0.4 protocol
5.1.4 IEEE 2030.5 (IEEE Adoption of Smart Energy Profile 2.0 /
SEP2)
Introduction
The IEEE 2030.5 protocol (the IEEE adoption of Smart Energy Application Profile 2.0 / SEP2) is
a protocol aimed primarily at in house smart grid solutions, also called “home energy
management” via internet enabled devices (both wired as well as wireless). The protocol is
uc OCPI dra ft v4
Prov ide information
about Charge Point
av ailability, pricing
«OCPI dra ft v4 ...
Publish cha rge
point status
information ev ents
eMSP
«Mul tipl e proto...
Reserv e a cha rge
point for a driv er
(administrativ ely)
«OCPI dra ft v4 ...
Request sma rt
charging for a
driver
«Mul tipl e proto...
Inform driv er of
actual s ession
costs CPO
«Mul tipl e proto...
Prov ide charge
point location
information
«Mul tipl e proto...
Reserv ation of
charge point
(administrativ ely)
«Mul tipl e proto...
Prov ide actual
usage a nd billing
information
«Mul tipl e proto...
Decrease/ increase
power consumption
of individua l
dev ices
«Mul tipl e proto...
Authorize charging
session
«High level use...
Prov ide charge
point information
Communicate
charging sc hedule
«OCPI dra ft v4 ...
Subscribe to charge
point information
«Mul tipl e proto...
Manage power
consumption of
Charge Point
«OCPI dra ft v4 ...
Authorize and store
subscription
«High Level Us...
Roaming
«High level use...
Smart Charging
«High level use...
Reserv ation
«Mul tipl e proto...
Prov ide token
information
«Mul tipl e proto...
Receiv e (and
cache) toke n
information
«OCPI dra ft v4 ...
Subscribe to sub-
set of charge points
«include»
«include»
«include»
«include»
«include»
«include»
«include»
Charge P oint i nformati on
«include»
subscription
«flo w»
«include»
«include»
«include»
«include»
32
based on the IEC 61968 common information model and the IEC 61850 information model for
DER. The protocol originates from the ZigBee Alliance and is a successor to the Zigbee Smart
Energy Protocol V1. In 2012, the Consortium for SEP 2 Interoperability (CSEP) was formed by
the WiFi, ZigBee, HomePlug and Bluetooth Alliances to specify certification requirements. The
Consortium was disbanded in early 2016 (see for more details).
In 2013 the protocol has become a standard within the IEEE.
Use cases supported by IEEE 2030.5
The IEEE 2030.5 protocol is a broad protocol and describes a number of functionalities and also
gives hints for which types of devices / systems this functionality is meant. In Figure 6 a
complete overview of the (sets of) use cases is given, which are called “function sets” in IEEE
2030.5. To avoid misunderstandings when comparing with other protocols in this study, the
terminology of IEEE 2030.5 is not adopted in the diagram.
The IEEE 2030.5 protocol is focused on communication from the utility to an Energy Service
Interface (ESI). This ESI, in a house is the utility Trust Source that the EV would communicate
with. The ESI could also be the Energy Management System (EMS) for a home to one or more
EVSEs and other home loads, or any public EVSEs for smart/optimized charging of multiple
EVs connected to multiple EVSEs.
According to the specification, the following sets of use cases could be applicable for electric
vehicles. Part of this is based on the J2847/1 specification, which describes “Communication for
Smart Charging of Plug-in Electric Vehicles using Smart Energy Profile 2.0”:
• Demand Response / Load Control. The specification refers to “devices that support load
control”. This could be interpreted as EVs (or a combination of charge point and EV).
According to the [SMC-SEP2013] specification this is primarily targeted at the smart
charging use case “Direct Load Control Programs”.
• Exchanging metering data. Translated to EV, this functionality could be used for
exchanging metering data between charge point and CPO. According to [SMC-
SEP2013], this can be applicable in any smart charging use case, but is required for the
use case “Time-Of-Use (TOU) Rates / Tariffs / Programs (Load Shifting)”
• Providing tariff information (in the IEEE 2030.5 specification this is called “Pricing”). This
is used in three use cases:
o “Time-Of-Use” (months / years ahead)
o “Critical Peak Pricing” (day ahead) and
o “Real Time Pricing” (minutes ahead).
• Sending text messages. This functionality for sending text messages can be used for
“text messaging display devices”. Translated to the EV domain, this could be used for
charge points that have a display.
• Providing actual usage and billing information. This concerns providing consumption,
costs or cost / consumption targets from a service provider to an end device. For EV this
could be from EMSP / CPO to charge point (for example for “real time pricing”).
• Prepayment, this functionality concerns delivery of a service based upon outstanding
credit or debt. In case of EV charging this could be prepaid charging at a charge point.
• Energy flow reservation. This functionality if targeted at devices that use large amounts
of energy (PEV’s and EVSEs are explicitly mentioned). This could be used by DSOs as
33
an input for managing capacity in the grid (“Optimized Energy Transfer Program”). Since
this is different from the reservation definition as used in this study, the terminology is
not “Reservation” as the function set is called in the IEEE 2030.5 specification.
The vehicle would send initial information to the utility on Time Charge Is Needed (TCIN)
or when the vehicle is expected to be used the next time. This can be combined with
Demand Response / Load Control and Pricing function sets to determine an optimum
(use energy at lower price and only use an amount within the limit at that site).
• Manage DER. This functionality concerns both generation as well as storage. Electric
vehicles are mentioned here explicitly as an example of storage.
Besides these functionalities, separate documentation is available which describes how IEEE
2030.5 can be used for smart charging PEVs.
This results in the high-level use cases as listed in paragraph 4.1.4:
• Smart charging
• Manage grid
• Handle registrations
Maturity
The IEEE 2030.5 protocol is standardized within the IEEE. The protocol is divided in several
“function sets” and not only describes the messages in the protocol, but also has an extensive
description of registration, discovery, the transport protocol and security. Furthermore, the
specification contains sequence diagrams including message examples for a number of use
cases.
The specification itself does not mention which parts of the standard are to be implemented for
certification. The CSEP consortium qualified a set of test tools to implement certification of
devices to the “CSEP Version 1.0 Test Specification” (in December 2013). The consortium was
disbanded in early 2016. The test tools are available and used in an IEEE 2030.5 Conformance
Test Program by two Nationally Recognized Testing Laboratories in the US and Korea (NTRL)
1718
.
Based on the above, the maturity of the protocol is classified as high.
Interoperability
The IEEE 2030.5 protocol is an IP-based protocol that is independent of the underlying physical
transport. It uses the IEC 61968 data model for most of its semantics. The protocol adopts the
IEC 61850-7-420 logical node classes for DER components and anticipated extensions to IEEE
2030.5 are intended to be made consistent with IEC 61850 extensions for DER. It consists of an
xml schema and a description how messages are to be sent, including message examples.
CSEP conducted dozens of industry interop events for IEEE 2030.5 devices as a follow-on to
17
Both NRTL’s, QualityLogic and UL and TTA (Korea), are internationally recognized.
18
Negotiations are in process to establish the first formal industry IEEE 2030.5 certification program with a focus on
DER applications.
34
multiple events conducted by the Zigbee Alliance. This makes the technical interoperability
(both syntax as well as semantics) high.
The protocol is quite broad and the function sets are defined in a generic way (client can be a
thermostat, but also a PEV) which means that it can be used in a wide range of areas. This
genericity makes it impossible to describe exact behavior. On this level the interoperability is
therefore classified as medium.
Based on the above, the interoperability of the protocol is classified as medium / high.
Market adoption
Multiple companies and research organizations in the US and Korea have developed or are
developing IEEE 2030.5 implementations for research and demonstration purposes. There are
several commercial quality implementations and robust test and certification test tools available
in the market. Two test labs are offering an IEEE 2030.5 Conformance Test program and an
industry certification program is in development. However, the current implementations of IEEE
2030.5 are used in research projects and, to our knowledge, no production implementations
currently exist. The pricing and Demand Response / Load Control function sets have been used
in the Smart Energy Profile 1.x protocol (predecessor of IEEE 2030.5) for decades by utilities for
load control using SEP1.x.
Based on the above, the market adoption is classified as low.
Openness
The IEEE 2030.5 protocol is publically available from the website of IEEE. The protocol can be
bought at limited costs, it contains no IP. IEEE is considered an accredited standards
organization.
The openness is therefore classified as high.
35
Figure 6: Use case overview of IEEE 2030.5 protocol
uc IEEE 2030.5
«High level use...
Billing
«Mu ltipl e proto...
Excha nge meteri ng
data
«High Level Us...
Handle regis tration
«IEEE 2030.5 ...
Prepayment
«IEEE 2030.5 ...
Manage DER
SEP c lient / serv er
«IEEE 2030.5 ...
Energy flow
reserva tion
«Mu ltipl e proto...
Prov ide actual
usage a nd billing
information
«Mu ltipl e proto...
Prov ide tariff
information
«Mu ltipl e proto...
Schedule based
charging
«Mu ltipl e proto...
Demand Response /
load control
«High level use...
Manage grid
«High level use...
Smart Charging
«IEEE 2030.5 ...
Discov ery
«IEEE 2030.5 ...
Sending text
messages «include»
«include»
depends on
«include»
Expecte d power usage
«include»
«include»
depends on
«include»
36
5.1.5 Smart charging protocols overlap
When considering the protocols in paragraph 5.1, the functionality that links them for EV, is the
smart charging functionality. However, the protocols under consideration are quite different,
which becomes clear when looking at the supported use cases on a high level (Table 1).
Table 1: High level view on smart charging protocols
The use cases supported by OCPI draft v4 are not only aimed at smart charging, but also at
roaming. In this sense the protocol is broader than the OpenADR and OSCP protocols.
However, it is a draft protocol, which is not described fully and is completely revised in the follow
up version, which means that it is not useful to include it in the comparison of the other smart
charging protocols. When new versions of OCPI will support smart charging again (version 2.1
does not, see chapter 5.3.2), it seems more appropriate to include the protocol in the
comparison again.
When looking at OSCP, IEEE 2030.5 and OpenADR, it is clear that OpenADR is more mature.
OpenADR also seems to have the highest market adoption. OpenADR and IEEE 2030.5 can be
applied in a much broader range of demand response scenarios than OSCP, whereas OSCP is
specifically for 1 situation. OSCP is only targeted at forecasting capacity (“capacity based smart
charging”). IEEE 2030.5 is broader than OpenADR, even when primarily focusing on electric
vehicles, the set of functionalities is larger than in the OpenADR set. OpenADR supports
(among others) price signals and load control signals. The other IEEE 2030.5 functionalities,
primarily aimed at communication with in home devices are out of scope of this study.
The specific nature of OSCP combined with the explicit description of the behavior in the
specification, makes it easier to implement. The more generic nature of OpenADR gives rise for
needing additional specifications when the protocol is applied in a specific scenario / market
situation. When looking at the messages it seems that it might be possible to translate OSCP
messages in OpenADR messages, but again: without additional behavior specifications it does
not seem to be a ready alternative for the current implementations.
37
When looking at the smart charging protocols under consideration, these could be interesting
from the point of view of a DSO. However, dynamic pricing or setting grid limits can only be
done when this is legally binding. Currently this is not the case in most markets, legislation is not
yet prepared for this. In most countries however the opportunity exists for research and
experimenting. This offers the possibility to explore applying the protocols discussed in this
paragraph.
38
5.2 Central System – Charge Point
39
5.2.1 Open Charge Point Protocol (OCPP)
Introduction
The Open Charge Point Protocol (OCPP) has been designed and developed to standardize the
communications between an EV charge point (also known as a charging station or charging
equipment) and a central system, which is used for operating and managing charge points. The
communication protocol is open and freely available to ensure the possibility of switching from
charging network without necessarily replacing all the charging stations or significant
programming, including their interoperability and access for electric grid services. The protocol
is intended to exchange information related to transactions and for operating a charge point
including maintenance. The version under consideration (1.6) can also be used for schedule-
based EV charging.
OCPP started out as an initiative of ElaadNL, a collaborative foundation created by a number of
Dutch grid operators and the first version was published in 2009. In the beginning of 2014
development and maintenance of the protocol has been transferred to the Open Charge
Alliance (OCA). The OCA has an international board of directors, and widespread global
membership that including grid companies, research institutes, charge point manufacturers and
commercial software and hardware companies. The OCPP has become the de facto open
standard for charger to network communications in many countries, including in Europe and
parts of the U.S. The OCPP version 1.6 that has been developed by the OCA, was made
available to the formal standards development organization, OASIS, as the basis for the
development of the next version (2.0). The OASIS OCPP technical committee had over 60
members from over 8 countries supporting its formal standardization until the committee was
closed by OASIS
19
.
Use cases supported by OCPP
In Figure 7 (see next page) the use cases that are supported by OCPP are visualized. The high-
level use cases as listed in paragraph 4.1.4 that are supported by this version of the protocol
are:
• Authorize charging session
• Billing
• Manage grid
• Operate Charge Point
• Reservation
• Smart Charging
Besides the main functionality of operating a charge point, in more detail the protocol can (also)
be used:
• Technically reserving a charge point (i.e. sending a reservation message to a charge
point)
• Collecting transaction information for billing purposes
19
See https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ocpp
40
Figure 7: Use case overview of OCPP protocol
uc OCPP
«OCPP Use Ca...
Check authorization
CPO
Collect transac tion
information (billing)
«OCPP Use Ca...
Execute S mart
Charging
commands
Maintenance of
Charge Point
«Mul tiple proto...
Manage pow er
consumption of
Charge Point
«High l evel u se...
Operate Charge
Point
«Mul tiple proto...
Schedule bas ed
charging
«Mul tiple protocols»
Decrease/ increase
power c onsumption of
individual devic es
«OCPP Use Ca...
Configure charge
point
«OCPP Use Ca...
Send rese t charge
point message
«OCPP Use Ca...
Start / stop
transaction
Charge Point
«OCPP Use Ca...
Maintain loc al
authorization list
«Mul tiple proto...
Reserv e charge
point (technically)
«OCPP Use Ca...
Trigger message
from charge point
«OCPP Use Ca...
Manage c harge
point firmware
«OCPP Use Ca...
Charge point
diagnostics
«OCPP Use Ca...
Data transfer
Manage c harge
point avai lability
«OCPP Use Ca...
Set charge point
ava ilability
«OCPP Use Ca...
Collect metering
data from charge
point
«High L evel Us...
Authorize charging
session
«Mul tiple proto...
Remote start / stop
transaction
«OCPP Use Ca...
Send Unlock
connector command
«OCPP Use Ca...
Validate
authorization
«High l evel u se...
Billing
«High l evel u se...
Reserv ation
«Mul tiple proto...
Set resource
ava ilability
«High l evel u se...
Smart Charging
«Mul tiple pr...
Exchange
metering data
«High l evel u se...
Manage gri d
«include»
«include»
«include»
«include»
«include»
Transactio n inform ation
«include»
«include»
«include»
Meterval ues
Reset comma nd
Trigg er
Firmware
Remote start / stop comman ds
«include»
«include»
«include»
«include»
«include»
Smart cha rging schedu les / comma nds
«include»
«include»
«include»
«include»
Configu ration
«include»
Data
Diagno stics logging
Avail abil ity
«include»
«include»
Unlock comm and
41
Maturity
Many parties have extensively used OCPP over recent years. Version 1.6 is the third “real”
release of the protocol – the previous releases of OCPP were 1.2 and 1.5. The protocol has
been further developed while it was also being used in practice and has been enhanced both
technically as well as functionally over the years. The 1.6 version of OCPP is developed within
the Open Charge Alliance. The specification is divided in "profiles". These profiles include
firmware management, smart charging and reservation. A testing tool is offered by the OCA,
which can be used to determine whether the implementation of a central system or charge point
is correct. This testing tool can play the role of both charge point as well as central system. The
technical level of detail of the OCPP specification is high, no separate test specification is
available (testing tool specification does specify test scenarios). Currently certification of the
protocol is not available. Based on the above, the maturity of the protocol is classified as high.
Interoperability
The OCPP protocol is a strict protocol. It does not only describe messages, but also the related
behavior of the central system and charge point is included in the protocol. Furthermore, the
protocol also defines scenario’s, such as booting a charge point, and the sequence of
messages that is to be used in that scenario. This “strictness” combined with the testing tool to
validate implementations, makes the protocol highly interoperable: a correctly implemented
central system and a correctly implemented charge point will usually integrate without many
problems (if any).
Market adoption
The market adoption of OCPP is high. It has been downloaded over 10.000 times in 91
countries and used on 6 continents. The Open Charge Alliance which was responsible for
creating the protocol consists of over 65 parties. Despite the fact that OCPP is not (yet) a formal
de jure standard, it is the only non-proprietary standard that supports this key domain for EV
charging and has been deployed by many vendors globally. Therefore the market adoption of
the protocol is classified as high.
Openness
The OCPP protocol is publically available at no cost from the website of the Open Charge
Alliance, without licensing / royalty obligations or usage restriction. It is made available under
the Creative Commons Attribution-NoDerivatives 4.0 International Public License (with no other
intellectual property assertions). The Open Charge Alliance is not considered an accredited
standards organization. Development of successor versions of the protocol were attempted to
be carried on through OASIS, which is an accredited standards organization, until the
committee was closed by OASIS.
Based on the absence of intellectual property constraints and free public access of the
standard, the openness is classified as Medium / high.
42
5.2.2 IEC 61850-90-8
Introduction
The IEC 61850-90-8 document is not a protocol in itself. It is a technical report which describes
an object model for electric mobility. The main purpose of IEC 61850-90-8 is to model E-mobility
into IEC61850-7-420 ed. 2, for the integration with other DER types like PV, wind, etc. for a high
level of safety and interoperability. This will be withdrawn by IEC when this process is finalized.
It models Electric Vehicles as a specific form of Distributed Energy Resource according to the
paradigms defined in IEC 61850. The idea is to create a “logical node” model for EV. In this way
IEC 61850-90-8 can be used as a protocol: the report itself only describes the object model, but
since it defines an object model "in the IEC 61850 way", the properties of the data in this model
can be "read" and "set" using the standard messaging protocols for IEC 61850 (i.e. the MMS
protocol). Typical use for the standard is getting and setting instantaneous (so no historical)
values. In case of remote devices, this boils down to determining the status / state of a device
and to determine what kind of device it is (what components, manufacturer of the components
etc.). When dynamic properties are defined in the model, such as charging speed, these can
also be changed by sending an MMS message to the charge point. Using the protocol in this
way, a charge point can be externally controlled.
Use cases supported by IEC 61850-90-8
As discussed in the introduction, IEC 61850-90-8 can be considered as a protocol to control a
charge point for both AC as well as (high power) DC charging. However, since it is only
described as an object model, no direct use cases can be derived from the specification, except
for smart charging. For this reason and because no open charge point implementations of the
protocol are known, no use case diagram is added in this study, but only a textual description is
given of the “possible” use cases.
The use case smart charging is described in the specification as “optimized charging with
scheduling from the secondary actor / at EV”. Furthermore, a local reservation scheme is
explicitly defined, which makes it suitable for reservation of power (not to be confused with
reservations of a charge point for a user). Other possible use cases are managing the grid by
adjusting the power (used by charge points) by setting the charging speed. Part of the
properties in 61850-90-8 make it possible to do the basics of operating a charge point, but the
lack of firmware upgrade functionality etc, makes the protocol in itself not suitable for operating
a charge point. To have a complete set, this should be mixed with other standards. Billing is out
of scope of the model. Protocol security is not in the 61850-90-8 specification itself, but is
described separately in the IEC 62351 specification. This involves security of the protocol itself,
not the functionality related to, for example, authorizing a user at a charge point.
Maturity
The model is available as an IEC technical report, however, no existing real life charge point
implementation based on the protocol is known. The messages that are sent using 61850 via
the MMS protocol can be certified in general, so this also applies to 61850-90-8.
43
Based on the above, the maturity of the protocol is classified as medium.
Interoperability
The interoperability of the protocol is low. The model is defined in a strict manner, but no
relation to behavior is available. This means that no description is available of what behavior is
expected when setting a specific parameter.
Market adoption
No existing real life charge point implementation based on the protocol is known, so despite the
market adoption of other parts of the 61850 standard, this is classified as low.
Openness
The IEC 61850-90-8 specification is publically available at limited cost from the website of the
IEC, containing no IP other than the copyright by IEC. The IEC is considered an accredited
standards organization.
The openness is therefore classified as high.
5.2.3 Central system – charge point protocol overlap
Both OCPP and IEC 61850-90-8 can be used to control a charge point. Where OCPP has
become a de facto standard, IEC 61850-90-8 could also be used to execute a number of
functionalities supported by OCPP. However, due to the fact that OCPP is in use at many
companies, IEC 61850-90-8 is not in use and does not define behavior, it is difficult to compare
the protocols. However, due to the nature and history of the IEC 61850 protocol, it seems more
suitable for direct control of a charge point by a grid operator than for operating a charge point.
The relatively large amount of electric energy that is required for charging EV’s can lead to
problems in the electricity grid in areas where the grid is not scaled for EV. The two variables
that are of concern here are voltage and power. For the variable Voltage maximum and
minimum limits are defined for a DSO (usually by law). For power, of course, the physical limits
of the electricity grid apply (the maximum amount of power before breakers in substations trip).
In the Sustainable Processes report by the Smart Grid Coordination Group [CCE2012], the
traffic light concept is used as a framework to consider how interaction should take place within
the EV market in different states of the grid. As the word "traffic light" implies, 3 situations are
distinguished: a green, yellow and red situation. These situations are schematically presented in
Figure 8 (from [CCE2012] ). The green area basically means that the market is operating freely,
yellow refers to the temporary situation when the DSO actively engages in the market to keep
the grid / system from becoming unstable. Red refers to the temporary situation when the DSO
needs to take control of the market in specific areas due to grid constraints.
44
Figure 8: Traffic light concept (from [CCE2012] )
In the green and yellow situation, OCPP can operate as normal. In case of a yellow situation the
DSO could be involved in the market using one of the smart charging protocols (see paragraphs
5.1.1 to 5.1.4). In this scenario, the OCPP protocol can be used for setting charging limits or to
stop charging.
However, in the red situation, some DSO’s want to take control by directly setting limits on the
charge point. This seems the most appropriate application of the IEC 61850-90-8 protocol,
since the IEC 61850 protocol in general is the conventional way for DSO’s to take control of
remote devices in the network.
45
5.3 Roaming
IN THE TELECOM INDUSTRY “ROAMING” IS THE ABILITY OF USERS TO MAKE USE OF THEIR
PHONES/SUBSCRIPTIONS BEYOND THE LIMITS OF THE NETWORK OF THEIR PROVIDER OF
CHOICE. IT ALSO COVERS THE AGREEMENTS BETWEEN PROVIDERS TO MAKE THIS
POSSIBLE. IN THE EV DOMAIN ROAMING IS VERY SIMILAR: THIS IS WHAT ALLOWS EV
DRIVERS CHARGE THEIR EV AT CHARGING STATIONS THAT ARE NOT PART OF THE
CHARGING NETWORK OF THEIR CPO USING THE SAME IDENTIFICATION
46
5.3.1 Open Clearing House Protocol (OCHP)
Introduction
The Open Clearing House Protocol (OCHP) is a protocol which is meant for exchanging
authorization data, charging transaction and charge point information data for roaming. The
protocol consists of 2 parts:
1. A part that is specifically for communication between market parties and an EV clearing
house
2. A part that is for peer to peer communication between market parties, this is called
OCHPdirect
The protocol is currently used with the e-clearing.net clearing house platform, which is operated
by smartlab Innovationsgesellschaft mbH and owned by both smartlab and ElaadNL on an
equal shares basis (non-profit). The version under consideration is 1.4.
Use cases supported by OCHP
In Figure 9 and (see next pages) the use cases that are supported by OCHP are visualized.
Due to the size of the diagram, separate diagrams for OCHP and for OCHPdirect are included.
The high-level use cases as listed in paragraph 4.1.4 that are supported by this protocol are all
aimed at roaming:
• Authorizing charging sessions
• Billing
• Providing charge point information
• Reservation
• Roaming
• Smart Charging (only in OCHPdirect, in a basic / lean form)
In more detail, it also includes:
• Remote Control of Charge Point (only in OCHPdirect). This includes setting limits, but
this is not targeted at dynamic Smart Charging (yet).
• Providing tariff information
• Providing Charge Detail Records for billing
• Providing charging session information (only in OCHPdirect)
Maturity
Over the last 3 years, every year a new version of the protocol was released (most recently
OCHP 1.4 & OCHPdirect 0.2 in Q4/2016). Since the protocol has been in active use for those
years by a number of parties, practical experience has been included in the development. The
protocol is maintained within e-clearing.net. Currently, certification is not possible and no
dedicated / specific testing tool is available. However, before a party gets access to the
productive environment of the clearing house, first a complete implementation test is executed
(including correctness checks), which can be considered a “quasi-certification”.
The maturity of the protocol is qualified as high.
47
Figure 9: Use case overview of OCHP protocol (excl. OCHPdirect)
20
20
OCHP also identifies the roles of POI consumer and Parking Spot Operator (to provide parking spot live data). In
this study these roles are gathered under the roles of EMSP and CPO respectively.
uc OCHP (excl. OCHP-Direct part)
«Mult iple proto...
Upload (own)
authorisation data
«Mult iple proto...
Update (own)
authorisation data
«Mult iple proto...
Download full lis t of
roaming
authorisation data
«OCHP Use Ca...
Download updates
in roaming
authorisation data
«Mult iple proto...
Exchange of
Authorisation Data
CPO
ClearingHouse
«High L evel Us...
Authorize charging
session
«Mult iple proto...
Upload Charge Data
Records
«OCHP Use Ca...
Process Cha rge
Data Records
«Mult iple proto...
Download CDR
«OCHP Use Ca...
Approve CDR
«OCHP Use Ca...
Revise CDR
«OCHP Use Ca...
Reject CDR
«Mult iple proto...
Upload (own)
charge point
information
«Mult iple proto...
Download charge
point information
«Mult iple proto...
Exchange ra w
billing (charging)
data
«Mult iple proto...
Exchange of Charge
Point Information
«OCHP Us...
Update Tariff
Information
«Mult iple proto...
Upload Tariff
Information
«Mult iple proto...
Download Tariff
Information
«OCHP Use ...
Exchange of Tariff
Information
«Mult iple proto...
Request the CHS to
authorize one single
token for roaming
«Mult iple proto...
Exchange of
Parking Spot
Information
«Mult iple proto...
Update the liv e
status of stations
«Mult iple proto...
Download liv e
status information
«Mult iple prot...
Single
Authorization
Requests
«Mult iple proto...
Live s tatus
interface
«High L evel Us...
Roaming
«High l ev...
Billing
«High l evel use...
Provide charge
point information
«Mult iple pr...
Provide tariff
information
«Mult iple pro...
Provide Charge
Detail Records
«Mult iple proto...
Provide charge
point location
information
eMSP
«Mult iple proto...
Provide token
information
«Mult iple proto...
Receiv e (and
cache) token
information
«OCHP Use Ca...
Set tariff restrictions
(e.g. maxEner gy,
maxDuration)
«flow»
«flow»
«flow»
«flow»
«include»
«include»
«include»
«include»
«flow»
«include»
«flow»
«include»
«include»
«flow»
«include»
«include»
«flow»
«flow»
«flow»
«include»
«include»
«include»
«flow»
«include»
«include»
«include»
«include»
«include»
«include»
«flow»
«include»
«include»
«flow»
«flow»
«include»
«include»
depends on
«include»
«include»
«flow»
«include»
«flow»
«flow»
«flow»
«flow»
48
Figure 10: Use case overview of OCHPdirect protocol
uc OCHPdirect
CPO
ClearingHouse
«High level u se...
Provi de charge
point information
«Mul tiple proto...
Provi de charge
point location
information
«Mul tiple proto...
Remote start / stop
transaction
«Mul tiple proto...
Request current liv e
status
«OCHPdirect U...
Send Charging
ev ent
«Mul tiple proto...
Remote Control of
Charge Point
«OCHPdirect U...
Set (own) interface
definition
«OCHPdirect U...
Get roaming
partners interface
definitions
eMSP
«OCHPdirect U...
Report a data or
compatibility
discrepanc y
«OCHPdirect U...
Select a charge
point
«OCHPdirect U...
Control (a selected)
charge point
«OCHPdirect U...
Release a selected
charge point
«Mul tiple proto...
Provi de charging
sessi on information
«OCHPdirect U...
Request charging
process i nformation
for a customer
«Mul tiple proto...
Control charge
points
«High level u se...
Reserv ation
«Mul tiple proto...
Exchange endpoints
«Mul tiple proto...
Send remote
commands to
location / EVS E
«Mul tiple protoc...
Reserv e a charge
point for a drive r
(administrativ ely)
«Mul tiple proto...
Reserv ation of
charge point
(administrativ ely)
«High level u se...
Smart Charging
«Mul tiple proto...
Manage power
consumption of
Charge Point
«include»
«flo w»
«flo w»
«flo w»
«include»
«flo w»
«include»
«flo w»
«flo w»
«include»
«include»
«flo w»
«include»
depends on
«include»
«flo w»
«include»
«include»
«include»
«flo w»
«include»
«flo w»
«flo w»
«include»
49
Interoperability
The OHCP is a strict protocol. It does not only describe messages, but also the related behavior
of the CPO’s and the clearing house. Furthermore, the more elaborate use cases are explained
in more detail. This “strictness” makes the protocol highly interoperable: a correctly implemented
system using OCHP and a correctly implemented clearing house will usually integrate without
many problems (if any). For OCHPdirect a similar strictness is applicable.
Market adoption
Currently 24 market parties in Europe are using the platform, including the OCHP, which covers
a number of countries within Europe including Germany, France, Austria, Netherlands, Belgium
and England. Within this region the market adoption can be classified as high. However, when
looking at the market adoption over the world, the overall market adoption is classified as
medium / high.
Openness
The OCHP is publically available at no cost from the website of e-clearing.net. It is made
available under the MIT license. Stakeholders and users are encouraged to take an active role
in the further development of the protocol and the platform, with yearly workshops to collect
feedback and requirements. E-clearing.net is not considered an accredited standards
organization. There is a public repository on Github for development, issue tracking and
collaboration.
The openness is therefore classified as medium.
5.3.2 Open Charge Point Interface protocol (OCPI 2.1)
Introduction
The Open Charge Point Interface protocol is designed for exchanging information about charge
points. The protocol is for exchanging information between the market roles of Charge Point
Operator and e-Mobility Service Provider. These roles are not separated in all markets. In some
countries or regions these roles are filled in by one party.
The OCPI protocol originates from the Dutch EV market, where, starting in 2009, a number of
CPOs and EMSPs (collaborating under the name eViolin) together with ElaadNL, created a first
version of a protocol for exchanging information concerning charge points. Eventually in 2014
this resulted in the development of OCPI. Version 2.1 was published in 2016. The Netherlands
Knowledge Platform for Charging Infrastructure (NKL) facilitates and coordinates this project to
guarantee progress and ensure development and results.
50
Use cases supported by OCPI 2.1
In Figure 11 (see next page) the use cases that are supported by OCPI are visualized. The
high-level use cases as listed in paragraph 4.1.4 that are supported by this protocol are aimed
at roaming:
• Authorizing charging sessions
• Billing
• Providing charge point information
21
• Reservation
• Roaming
• Handle registrations
In more detail, it includes:
• Providing both session information as well as location information.
• Sending remote commands among which reservation commands.
• Providing Charge Detail Records for billing purposes
• Providing tariff information
• Authorizing charging sessions by exchanging tokens
Maturity
The 2.1 version currently has a low market adoption, so not much experience with the protocol
is available. The level of detail of the specification is high, no test specification is available. A
concrete plan for a new version / release from "NKL Nederland", the organization that is further
developing the protocol, is available. Currently certification is not possible. No testing tool is
available. The number of parties that is currently implementing the protocol is < 10.
Based on the above, the maturity of the protocol is classified as low / unknown.
Interoperability
The OCPI protocol is a strict protocol, which makes the interoperability high. It not only describe
the protocol messages in much detail, but also the transport layer including error codes etc. are
described. Since the protocol is peer-to-peer and primarily for exchanging information (and
some commands), not much protocol related behavior is applicable.
Based on the above, the interoperability of the protocol is classified as high.
21
Actually, the protocol can be used to provide information about “EVSE’s” and not about “charge points”. However,
for being able to compare the protocols, this term is used. In detail: EVSE is the logical unit in a charge point that
supplies electric energy via a Connector for charging. An EVSE can have one or multiple Connectors (single physical
outlets).
51
Market adoption
Due to the fact that OCPI is an emerging protocol, without a large driving organization, no
detailed information about the users of the protocol are available. Based on the market adoption
in the Netherlands, where the protocol emerged but the 2.1 version is not yet implemented at
the important market parties, the current market adoption is classified as low.
Openness
The OCPI version 2.1 protocol is publically available at no cost from the website of NKL
Nederland. It is made available under the Creative Commons Attribution-NoDerivatives 4.0
International Public License. NKL Nederland is not considered an accredited standards
organization. Development takes place via an open GitHub page, anyone can contribute.
The openness is therefore classified as high.
52
Figure 11: Use case overview of OCPI 2.1 protocol
uc OCPI 2.1
«Mul tiple proto...
(De)register
«OCPI 2.1 Use ...
Handle OCPI
Registration
«High L evel Us...
Handle registration
eMSP
CPO
«OCPI 2.1 Use ...
Exchange v ersions
«Mul tiple proto...
Exchange e ndpoints
«Mul tiple proto...
Provide charge
point location
information
«Mul tiple proto...
Provide charging
session i nformation
«Mul tiple proto...
Provide Charge
Detail Records
«Mul tiple proto...
Provide tariff
information
«Mul tiple proto...
Provide token
information
«Mul tiple proto...
Receiv e (and
cache) token
information
«Mul tiple proto...
Send remote
commands to
location / EVS E
«Mul tiple proto...
Provide actual
usage and bill ing
information
«Mul tiple proto...
Inform drive r of
actual se ssion
costs
«High L evel Us...
Authorize charging
session
«Mul tiple proto...
Reserv ation of
charge point
(administrativ ely)
«Mul tiple proto...
Remote start / stop
transaction
«OCPP Use Ca...
Send Unlock
connector command
«High l evel u se...
Billing
«High l evel u se...
Provide charge
point information
«High l evel u se...
Reserv ation
«High L evel Us...
Roaming
«Mul tiple proto...
Reserv e a charge
point for a drive r
(administrativ ely)
depends on
depends on
«include»
«flow»
«include»
«flow»
«include»
«flow»
«include»
depends on
«flow»
«include»
«include»
«include»
«flow»
«flow»
«include»
«flow»
«include»
«flow»
53
5.3.3 Open InterCharge Protocol (OICP)
Introduction
The Open InterCharge Protocol (OICP) is a roaming protocol created by Hubject in 2013, which
can be used to communicate with the Hubject B2B Service Platform. This platform enables
exchanging roaming messages between an EMSP and a CPO. Since 2016 the protocol
consists of 2 parts that together create the protocol: a separate part for the EMSP and a
separate part for the CPO. The version under consideration is 2.1.
Use cases supported by OICP
In Figure 12 (see next page) the use cases that are supported by OICP are visualized. The
high-level use cases as listed in paragraph 4.1.4 that are supported by this protocol are aimed
at roaming:
• Authorizing charging sessions
• Billing
• Providing charge point information
• Reservation
• Roaming
In more detail, it includes:
• Providing Charge Detail Records for billing purposes
• Providing both session information as well as location information
• Reserving charge points
• Sending remote start / stop commands
Maturity
Over the last 2 years, multiple new versions of the protocol have been released. Hubject
actively manages the API Releases. One release is supported for a maximum of 2 years. Which
leads to two active versions at once and a higher reliability for implementation partners. The
protocol is in active use for those years by a number of parties. According to the specification, it
is “the most widely implemented communication standard between European EMSP and CPO
systems”. No testing tool is available. Certification can be done, which is called the “Check
eRoaming system“. This is a certification of Hubject-compatibility for both charge points as well
as customer management systems. Certification is done by means of end-to-end testing (audit).
According to the specification, a new version of the protocol is released every year during spring
/ summer and will become productive October 1st, a protocol version is supported for 2 years.
Based on the above, the maturity of the protocol is classified as high.
54
Figure 12: Use case overview of OICP 2.1 protocol
Interoperability
The OICP protocol is a strict protocol. It does not only describe messages, but also the related
behavior of the clearing house and the EMSP end CPO roles are included in the protocol. This
“strictness” makes the protocol highly interoperable: a correctly implemented system using
OICP and a correctly implemented clearing house will usually integrate without many problems
(if any).
uc OICP
CPO
«High Level Us...
Authorize charging
session
«Mul tiple proto...
Request the CHS to
authorize one single
token for roaming
«Mul tiple proto...
Single Authorization
Requests
ClearingHouse eM SP
«Mul tiple proto...
Remote start / stop
transaction
«Mul tiple proto...
Provi de Charge
Detail Records
«Mul tiple proto...
Reserv e a char ge
point for a drive r
(administrativ ely)
«Mul tiple proto...
Download cha rge
point information
«Mul tiple proto...
Upload (own)
charge point
information
«OICP Use Case»
Remove (own)
charge point
information
«Mul tiple proto...
Update the liv e
status of stations
«Mul tiple proto...
Provi de token
information
«Mul tiple proto...
Download CDR
«Mul tiple proto...
Upload (own)
authorisation data
«OICP Use Case»
Remove (own)
authorisation data
«Mul tiple proto...
Download liv e
status information
«OICP Use Case»
Request liv e status
information for
specific chargepoint
«High level u se...
Provi de charge
point information
«Mul tiple proto...
Exchange of Charge
Point Information
«Mul tiple proto...
Exchange of
Authorisation Data
«High Level Us...
Roaming
«High level u se...
Billing «Multi ple p roto...
Exchange raw
billing (charging)
data
«Mul tiple proto...
Live status
interface
«Mul tiple proto...
Provi de charge
point location
information
«High level u se...
Reserv ation
«Mul tiple proto...
Reserv ation of
charge point
(administrativ ely)
«Mul tiple proto...
Update (own)
authorisation data
«flow»
«flow»
«include»
«flow»
Charge Deta il Record s, Authorizati on reque sts,
Status in formatio n, Charge p oint reservatio n
«flow»
«flow»
«include»
«flow»
«include»
depends on
«include»
«flow»
«flow»
«include»
«flow»
«include»
«include»
«include»
«flow»
«flow»
«include»
«flow»
«include»
«flow»
Charge po int reservatio n, Remote start / stop
comma nds, Status info rmation
«include»
«include»
«flow»
«include»
«include»
«include»
«include»
«flow»«flow»
«include»
«flow»
«include»
55
Market adoption
According to the specification, it is “the most widely implemented communication standard
between European EMSP and CPO systems”. It is not the only clearing house in Europe (see
also chapter 5.3.1 and 5.3.4), but it is used by the largest number of B2B customers in Europe
(currently more than 240 partners). The market adaption is therefore classified as high.
Openness
The OICP protocol is publically available at no cost from the website of Hubject, containing no
IP except for copyright by Hubject, which is not considered an accredited standards
organization.
The openness is therefore classified as medium.
5.3.4 eMobility Inter-Operation Protocol(eMIP)
Introduction
The eMobility Interoperation Protocol (eMIP) is provided by the GIREVE organization. The main
objective of GIREVE is: “open access to vehicle charging stations”. The eMIP protocol targets
the following goals (from the specification):
• Enabling roaming of charging services by providing a charge authorisation and a data
clearing house API.
• Providing access to a comprehensive charging point database.
• Providing smart charging features
GIREVE is founded by EDF, Renault, ERDF, CNR and Caisse des Dépôts. The initiative started
in 2012, aimed at roaming. In 2014 a cooperation with the Hubject platform was announced.
Use cases supported by eMIP
In (see next page) the use cases that are supported by eMIP are visualized. The high-level use
cases as listed in paragraph 4.1.4 that are supported by this protocol are aimed at roaming:
• Authorizing charging sessions
22
• Billing
• Providing charge point information
22
In more detail: real-time local + remote authorization and whitelists exchanges.
56
• Roaming
• Smart charging
In more detail, it includes:
• Providing Charge Detail Records for billing purposes
23
• Providing charge point information incl. tariff and parking spot information (static and
dynamic)23
• Smart charging functionality (→ open to any OEM, currently connected to one OEM)
• Retrieving list of EVSE's located in a given area and fulfilling a set of criteria (i.e. “search
functionality”)
• Sending event reports and remote commands (emergencystop, stop, suspend and
restart)
Maturity
The current version of the protocol is 0.7.4. No information about other versions is available.
Currently certification by Gireve is possible and is required for a connection to the Gireve
platform. No specific / dedicated testing tool is available, however SOAPUI mock services are
available for both CPO and EMSP related services. Furthermore, testing environments are
available for partners that intend to connect to the Gireve platform.
Based on the above, the maturity is classified as high.
Interoperability
The eMIP protocol does not only describe messages, but also the related behavior of the
clearing house and the EMSP and CPO roles are included in the protocol. Approximately 70%-
80% of the fields in the protocol are mandatory except for the charge point search functionality.
A correctly implemented system using eMIP and a correctly implemented clearing house are
therefore expected to integrate without many problems. eMIP is compatible with eMI3 / ISO way
of identifying business objects.
Therefore the interoperability is classified as high.
Market adoption
Gireve is not the only platform with clearing house functionality in Europe (see also chapter
5.3.1 and 5.3.3). The main market for Gireve is France. The EV charging infrastructure
deployment is in progress in France and the number of EVSE connected (to CPO’s connected)
to Gireve follows this ramp up. Gireve is also (directly) connected to European CPO’s for POI
information. No exact information on the number of involved parties / participants is available,
but this number appears to be relatively small when compared to the other roaming protocols.
The market adaption is therefore classified as medium.
23
Both push / pull mechanism
57
Figure 13: Use case overview of eMIP protocol
Openness
The eMIP protocol is not publically available from the website of Gireve. According to the
specification and license agreement, the protocol is the “exclusive property of GIREVE in
accordance with the provisions of the Code of the intellectual property”. Although the eMIP
protocol is an asset of Gireve (IP), a license is granted to any operator (that demands) for free.
uc eMIP
CPO eMSP
«Multi ple p roto...
Upload (own)
charge point
information «eMIP Use Case»
Upload charge point
information per
hierarchical level
(charging pool, station,
EVSE, connector)
«eMIP Use Case»
Request charge point
information per hierarchic al
level (charging pool, station,
EVSE, connector)
«Multi ple p roto...
Download Tariff
Information
«Multi ple p roto...
Upload Tariff
Information
«Multi ple p roto...
Exchange of
Parking Spot
Information
«Multi ple p roto...
Update the live
status of stations
«Multi ple p roto...
Request current liv e
status
«eMIP Use Case»
Update the live status of
stations per hierarc hical
level (charging pool, station,
EVSE, connector)
«eMIP Use Case»
Request current liv e status
per hierarchic al lev el
(charging pool, station,
EVSE, connector)
«High l evel use...
Provide c harge
point information
«Multi ple p roto...
Exchange of Charge
Point Information
Data aggregator
«eMIP Use Case»
Retrieve l ist of EVSE's
located in a giv en area and
fulfilling a set of criteria
ClearingHouse
«Multi ple p roto...
Request the CHS to
authorize one single
token for roaming
«Multi ple p roto...
Single Authorization
Requests
«Multi ple p roto...
Provide toke n
information
«Multi ple p roto...
Upload (own)
authorisation data
«Multi ple p roto...
Download full list of
roaming
authorisation data
«Multi ple p roto...
Exchange of
Authorisation Data
«High Le vel Us...
Roaming
«High Le vel Us...
Authorize charging
session
«Multi ple p roto...
Upload Charge Data
Records
«Multi ple p roto...
Download CDR
«Multi ple p roto...
Provide Charge
Detail Records
«eMIP Use Case»
Send heartbeats to
CHS
«Multi ple p roto...
Remote Control of
Charge Point
«eMIP Use Case»
Remote (emergency)
stop, suspend,
restart charging
«eMIP Use Case»
Report remote
(emergency) stop,
suspend, restart
charging
«High l evel use...
Billing
OEM
«eMIP Use Case»
Get current ve hicle
status
«eMIP Use Case»
Request charge
needs
«eMIP Use Case»
Provide c harge
need
«High l evel use...
Smart Charging
«15118 Use Ca...
(Provide) Charging
details
«Multi ple p roto...
Provide c harge
point location
information
«flow»
Heartbeat
«include»
«include»
«include»
«flow»
«include»
«flow»
«include»
«flow»
«flow»
«flow»
«include»
«include»
«include»
«include»
«flow»
«include»
depends on
«flow»
Current vehicl e status
«flow»
«include»
«include»
«flow»
«flow»
«flow»
«include»
Current vehicl e status
«include»
«flow»
«include»
«include»
«flow»
«include»
depends on
Charge Poi nt info rmation
«flow»
«include»
«include»
depends on
«flow»
58
Based on this license, the operator can use the eMIP protocol, to do “what it wants” and non-
exclusively to access the Gireve platform.
Gireve is not considered an accredited standards organization.
Based on the above, the openness is classified as low / medium.
59
5.3.5 Roaming protocols
The roaming protocols OCPI, OICP 2.1, eMIP and OCHP have a quite some overlap. When
looking at a high level, the only differences are that eMIP and OCHP support smart charging
and that OCPI also supports handling registrations. This last functionality is, as will be explained
below, logically.
Table 2: High level view on EV roaming protocols
However, when looking in more detail, the following differences exist:
• The main difference is the different communication setup between the protocol users:
the OCHP, eMIP and OICP protocols are used to communicate via a clearing house.
The OCPI 2.1 protocol and the OCHPdirect protocol are used directly between parties
as a peer-to-peer protocol. The main advantage of a clearing house is that only one
connection is to be established to the clearing house and not a connection per partner.
In a peer-to-peer setup, n partners means 𝑛 (𝑛−1)
2 connections (for example, 10 partners,
means 10x9/2 = 45 connections). The main advantage of a peer-to-peer setup means
that it has no dependency of 1 platform (“single point of failure”). Its peer-to-peer setup
also explains the fact that OCPI has possibilities for registrations.
• Another difference is that the communication between OCHP parties is asynchronous
(parties can upload / download files), OCPI is a synchronous protocol: a request is
directly answered by a synchronous response. In the Hubject and GIREVE platform for
which OICP and eMIP are used, both patterns exist for different messages.
• When looking in more detail, not all functionalities overlap. Some notable differences
are the following:
o OCHP has separate steps (approve / reject / revise) for exchanging CDRs
o OCHP and OCPI can be used for exchanging tariff information, OCHP supports
setting tariff restrictions.
o OCHP and eMIP explicitly support exchanging parking spot information.
o OCPI supports exchanging version information (to support multiple protocol
versions). Again the need for such a feature is larger due to the peer-to-peer
setup.
60
o eMIP, OCPI and OCHP (Direct) support both live status information as well as
session information. OICP only supports status info which includes live status
information (slightly different implementation).
• When including the platforms that are used in combination with the protocols, OCPI (no
CHS) and OCHP offer the possibility to choose with whom roaming will take place,
instead of roaming with all platform users.
• The GIREVE platform as a separate charge point repository.
• eMIP is the only roaming protocol that has no reservation functionality (yet), but does
have support for smart charging. Part of the smart charging process as it is defined by
the protocol depends on the current EV status. According the specification, this is
requested at an OEM of the EV (Renault is one of the founders). The older version of the
OCPI protocol (0.4) also included smart charging, but this functionality was removed in
version 2.1 (and is on the roadmap for a newer version again).
• OCHPdirect supports a primitive form of smart charging.
The main differences are visualized in Figure 14.
Figure 14: Schematic comparison of roaming protocols
Currently a pilot is executed to couple the different platforms (for POI information). The objective
of this pilot is to show that it is possible to couple the platforms. The PanEuropean eRoaming
Initiative between Hubject, Gireve and e-clearing.net aims at providing a first pilot
implementation of “interroaming” by Q3/2017 covering the basic POI, authorization and CDR
exchange services across all three platforms.
61
5.4 EV – Charge Point
62
5.4.1 IEC 61851-1
Introduction
The IEC 61851-1 edition 2 is a standard published in 2010, which concerns basic charging. It is
an official IEC standard, created by the “IEC technical committee 69 (TC69): Electric road
vehicles and electric industrial trucks”. The 2010 edition replaces the first edition from 2001,
Edition 3 is under development.
Use cases supported by IEC 61851-1
The IEC 61851-1 describes 4 modes for EV charging. In short, these modes refer to:
• Mode 1: basic AC charging to a maximum of 16A / 1x250V / 3x480V.
• Mode 2: basic AC charging to a maximum of 32A / 1x250V / 3x480V including some
additional features, such as standardized socket-outlets, power and protective earth
conductors together with a control pilot function and system of personnel protection
against electric shock.
• Mode 3: AC charging with basic signaling ( Pilot control function) where the control pilot
function extends to control equipment in the charge point, gaining the ability to activate /
deactivate the power flow and set charging rate limits.
• Mode 4: charging using an off-board charger and high level communication (Powerline
or CAN).
When looking at the high level use cases as listed in paragraph 4.1.4, this boils down to only EV
charging. Besides this, when smart charging an EV, mode 3 charging is often used to set /
change upper limits on charging speed during charging. In most current setups this is used for
smart charging based on external control signals. So for completeness, the high level use case
smart charging is also considered applicable, although this is basically only refers to adjusting
charging speed during charging.
Maturity
The IEC 61851-1 standard from 2010 is the second edition of the protocol. It is currently the
standard for EV charging in Europe. It can be tested and certified at different certification / test
laboratories.
Based on the above, the maturity of the protocol is classified as high.
63
Interoperability
The IEC 61851-1 standard describes EV charging in detail. Based on the experience with the
protocol, the interoperability of the protocol is classified as high.
Market adoption
IEC 61851-1 is currently the standard for EV charging in Europe. This means that many
thousands of charge points and every EV supports the standard. Based on this, the market
adoption of the protocol is classified as high.
Openness
The IEC 61851-1 standard is publically available at limited costs from the website IEC,
containing no IP other than the copyright by IEC on using the standard. The IEC is considered
an accredited standards organization.
The openness is therefore classified as high.
5.4.2 ISO / IEC 15118
Introduction
The ISO / IEC 15118 protocol specifies a communication standard between a charge point and
an EV. The ISO/IEC Joint Working Group 15118 for the Vehicle-to-Grid Communication
Interface (V2G CI) was founded in 2009. In this specification a more advanced form of
communication is described, also referred to as High Level Communication (HLC). This
enables EV’s to communication information (for example how full the battery is) to a charge
point, without intervention of the EV user (autonomously) in a more advanced way.
The ISO / IEC 15118 standard currently consists of several parts, which describe the protocol
on different levels of the OSI reference model (ISO/IEC 7498-).
• Part 1: Describes the use cases and basic definitions
24
• Part 2: Describes the network and application protocol requirements24
• Part 3: Describes the physical layer and data link layer.
• Part 4: Describes Network and application protocol conformance test
• Part 5: Describes physical and data link layer conformance tests
• Part 8: Physical layer and data link layer requirements for wireless communication
Use cases supported by ISO / IEC 15118
24
second edition currently under development
64
In Figure 15 (see next page) the use cases that are supported by ISO / IEC 15118 are
visualized. The high-level use cases as listed in paragraph 4.1.4 that are supported by this
protocol are aimed at EV charging:
• Authorizing charging sessions
• Smart Charging
• EV charging
• Reservation
In more detail, this includes:
• Schedule based charging, with schedules from both external sources as well as the EV.
• Certificate handling.
• Value added services, only one of these could be reservation.
Maturity
The 15118 protocol is not in use in many charge points and EV’s yet, so no extensive
experience with the protocol is available. The protocol is defined in detail on the different levels,
in many details. All currently available EVs that are equipped with the Combined Charging
System (CCS) have the ISO 15118 or DIN SPEC 70121 implemented in their controllers
25
.
Furthermore, according to a directive of the European Commission each newly installed DC fast
charger in Europe has to be equipped with CCS and hence with ISO 15118 / DIN SPEC 70121.
Based on the above, the maturity of the protocol is classified as medium.
The conformance tests for the protocol are described in part 4 and 5 of the protocol. No official
testing and certification is available, although conformance testing is executed by some
research institutes.
Interoperability
The protocol is defined in detail on the different ISO levels. It clearly describes both the use
cases as well as the technical details of the protocol. This combination makes the
interoperability high (potentially).
Market adoption
The market adoption of the ISO / IEC 15118 standard is currently still low, but is expected to
grow in the coming years. No official implementations in EV’s are currently available, although
many car manufacturers are “working on it”. Some charge point manufacturers have
implementations and open source implementations are available (see also the section about
maturity).
25
DIN SPEC 70121 is a pre-standard based on the ISO 15118 with only a few differences in the message set.
65
Openness
The ISO/ IEC 15118 protocol is available at limited cost from the website of ISO, containing no
IP other than the copyright by ISO. ISO and IEC are both considered accredited standards
organizations.
The openness is therefore classified as high.
66
Figure 15: Use case overview of ISO / IEC 15118 protocol
uc ISO 1511 8
Start of the charging
process
EV-charge point
communication
setup
Certificate Handling
Identification,
authorization and
authentication
Target setting and
Charging
scheduling
Charging controlling
and re-scheduling
Value-added
servic es
End-of-charging
process
Start of the charging
process w ith forced
HLC
Start of the charging
process w ith
concurrent IEC 6185 1-1
and HLC
Certificate update
Certificate install
Authorization using
Contract Certificates
performed at the EVSE
Authorization using
Contract Certificates
performed with help of
SA
Authorization at EVSE
using external
credentials performe d
at the EVSE
Authorization at EVSE
using external
credentials performe d
with help of SA
AC charging with
load leve lling based
on High Level
Communication
Optimized charging
with scheduling to
secondary actor
Optimized charging
with scheduling a t
EV
DC charging with
load leve lling based
on High Level
Communication
Resume to
Authorized Charge
Schedule
Value added
servic es
(Provide) Charging
details
Charging loop
Charging loop with
metering
information
exchange
Charging loop with
interrupt from the
SECC
Charging loop with
interrupt from the
EVCC or user
Reactive power
compensation
Vehicle to grid
support
Included in the use
cases of ISO 15118-1,
however, these are not
part of the current
revision of the ISO
15118-2 specification.
Charge Point
EV
Authorize charging
session
Schedule base d
charging
Smart Charging
Manage pow er
consumption of
Charge Point
Reserve charge
point (technically) Reserva tion
EV charging
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
67
5.4.3 EV – Charge Point protocols overlap
Basic communication between charge point and EV for charging can be done using the IEC
61851-1 protocol (which is even mandatory according to regulation). This standard is only
targeted at EV charging. The ISO / IEC 15118 can be considered the next step in charge point –
EV communication: using the 15118 protocol, it is not necessary anymore to communicate high
level information either by the EV user (via an app) or the EV in non-standard way (which
means not interoperable); this is part of the protocol. Although both protocols can be used in a
smart charging chain, the ISO / IEC 15118 protocol is far more advanced, since it supports
“High Level Communication”.
However, when looking at market adoption, the 61851-1 standard has a very high market
adoption whereas no implementations of the ISO / IEC 15118 protocol are known (other than
pilot projects)
26
.
26
More input from OEMs concerning future plans is needed here to make a better comparison.
68
6. PROTOCOL DISCUSSION
69
6.1 Overview
In Figure 16 the different roles and protocols in scope for this study are visualized. Some of the
protocols are easy to position, since those are made for a specific purpose. These are drawn
with solid lined. Other protocols, such as IEEE 2030.5 and OpenADR are more broad / generic
protocols, which makes them suitable for use at multiple places in the EV market chain. This is
visualized with dotted lines.
In the discussion in this chapter, the assumption is that some kind of control of a charge point is
possible. In the first part of this chapter we focus primarily on charging on public ground, not on
in house charging “behind” the electricity meter. This architecture is discussed briefly in
paragraph 6.6. In this architecture a lot of functionalities from the protocols described in this
study might not be required, for example roaming and authentication.
Figure 16: overview of protocols and market roles
An important note to be made is that the reader should realize that these are roles, not
companies. The same role might be filled by many different companies (competitive market). At
the same time, some of the roles might be filled in by the same company. Reality will be more
complex or perhaps less obvious than the model suggests.
In Figure 17, this complexity is visualized and the role of OEM is also added to the figure.
Currently no open standards / protocols are available to communicate with the OEM within the
EV market chain. The rightmost role of the DSO role is replaced by the combination of DSO,
TSO (Transmission System Operator) and BRP (Balance Responsible Party).
70
Figure 17: More complex view of protocols
Another addition to the figure is the EV user. There are a lot of ways available for
communicating with the EV driver, such as through the EV (ISO / IEC 15118), apps, websites,
helpdesks, manuals, on-site way of working stickers etc. but currently none of those is
standardized. This also depends on the existing role model / market model in the specific
country, region or continent. However, at many locations no communication to the user is
available, other than the beeps (and displays) on charge points.
Furthermore, the party that communicates with an EV user is not necessarily the same in every
location. EV users may sometimes even be “forced” to use different apps (e.g. a generic app for
finding charge points, a CPO or EMSP app for starting EV charging).
6.2 EMSP – CPO communication
Currently the communication between the EMSP and CPO roles has 2 types: point-to-point
communication and communication via clearing houses (see Figure 18). Within liberalized
energy markets, clearing houses are a common solution, once a market is more mature. When
many parties participate in a market, point-to-point communication usually becomes difficult to
control and a step towards a hub / clearing house is made . This is now happening in the EV
market, mostly on national and / or regional level. A hub provides an efficient means of
cooperation. The development speed depends on the cooperative nature of the parties involved
and governmental influence. In the situation that parties are intrinsically motivated, the mutual
connection to a hub is smoother with less hurdles. Besides the ICT-system also the
(compulsory) business rules involved in connecting to a hub (and other parties connected to this
hub) play an important role in the organic growth of parties connected to a hub.
A centralized vs decentralized solution can also be viewed as a “wave”. Current developments
in the Internet of Things (IoT) and blockchain tend to decentralized solutions again.
71
Figure 18: Point-to-point setup vs. clearing house setup
The main focus of the communication between EMSP and CPO is roaming, functionality for
smart charging is only available in the eMIP protocol and OCHPdirect as already indicated in
chapter 5.3.5. This functionality was available in the old version of the point-to-point protocol
OCPI, but was removed in the 2.0 version (and is planned to be reintroduced in a newer version
again). Therefore, the next step for the roaming protocols seems to be the addition / extension
of smart charging functionality. One may wonder whether the intermediate step via a point-to-
point protocol is necessary or that the focus should directly be on the clearing house type of
communication. One drawback of adding smart charging to the clearing houses, is that currently
multiple clearing houses exist. These should either communicate with each other or market
parties should be able to connect to multiple platforms (see Figure 19). Having multiple
connections is of course not the aim of using a clearing house, but it would at least limit the
amount of connections
27
.
Figure 19: Multiple clearing houses setup
27
Currently an initiative is under development to use the OCPI protocol for communication to the eclearing.net platform.
72
Using a point-to-point OCPI solution makes it easy to enable roaming with only a small selection
of parties. Extending it with smart charging only seems a solution for the short term. When
connections to OEM’s are considered necessary for smart charging (see 6.4 for more details on
the relation between OEM’s and smart charging), this would also imply that all OEM’s should
provide open API’s for market parties. This would make the number of connections between
parties within the EV market even larger.
6.3 EV charging
In this study EV charging refers to charging an EV at a charge point. After some form of
identification and authorization, the EV gets charged without any external imposed limits /
schedules (sometimes called “dumb charging”). If the EV user is not a direct customer of the
party that validates the authorization credentials (usually a CPO), some form checking the
authorization at other parties is required. This process, usually referred to as “roaming”, is also
considered part of EV charging in this study. Currently the maturity in the EV domain has
evolved to a level that charging without roaming is not considered as a serious option anymore.
Charging without roaming (“ad-hoc charging”) is therefore not discussed in this document.
A commonly used EV charging setup in (continental) Europe, is visualized in Figure 20. No input
from the DSO is taken into account, so only IEC 61851-1, OCPP and one of the roaming
protocols is used.
Figure 20: Basic EV charging
When using ISO / IEC 15118, authorization can be done using contract certificates between the
EV and the charge point. This means that it is not required to validate the authorization token at
the CPO (and EMSP). As a consequence, the connection to the EMSP is only necessary for
73
billing purposes (and for charge point information if applicable). This is also known as plug-and-
charge.
As indicated in 6.1, currently no open standards / protocols are available for the OEM to
communicate with the EV market chain. Currently more and more cars (not just EVs) are being
equipped with a communication module to communicate with the OEM, for example for
communicating battery status, updating car software or for reporting emergencies when the
airbag is activated. A possible future scenario is that this communication module in the car will
be used for communication with the EV market chain. This model, called the “Connected Car
model”, could mean that EVs communicate directly with the EMSP and part of the current
protocol functionality from EV via CPO to EMSP is replaced by this direct channel. For example,
information concerning battery status, preferred time of departure and authorization could be
communicated via this channel. This model is visualized in Figure 21.
Figure 21: Connected Car model
6.4 Smart Charging
According to [CCE2012] and [EUEL2015] the definition of smart charging is when charging an
EV can be externally controlled (i.e. “altered by external events”), “allowing for adaptive
charging habits, providing the EV with the ability to integrate into the whole power system in a
grid- and user-friendly way. Smart charging must facilitate the security (reliability) of supply
while meeting the mobility constraints and requirements of the user.”
Smart charging can be based on the input from the 3 stakeholders for which it can be an
opportunity:
1. Customers
2. Power system
3. Society
74
When looking at the protocols under consideration not many customer inputs are directly visible.
Input from the EV user can for example be “renewable energy only” or “I want to be charged for
75 % at 16.00h”. A number of EV related pilots in the Netherlands have shown that price is a
very important factor on the EV user side. This means that from the protocols in this study,
tariffing information is an important input for smart charging. Another important input could be a
desired charging schedule from an EV user. However, this type of smart charging messages is
currently only available in OCPI v0.4.
To maximize customer convenience, smart charging of EVs depends on two important pieces of
information: the battery status (full / empty), usually referred to as the “state of charge” (SoC)
and the planned time of departure (ToD) of the EV user. In the discussion in this chapter, the
SoC will be used with a broader definition than in some protocols: this is not only the battery
percentage left, but it is assumed that it also implies that the battery size is known. When only
using these variables, the implicit assumption is that the EV user wants a full battery. If not,
another variable, energy amount requested” should also be taken into account. Many of the
current smart charging solutions depend on this information and have different (non-
standardized) ways of acquiring this information. Some implementations ignore this information,
others may want to use it and use a best-guess if no information is available.
The second stakeholder is the power system or the role responsible for it. Inputs from the power
system can be, for example, available capacity which usually comes from a DSO. In this study a
number of protocols related to these inputs have been discussed in the smart charging chapter:
OpenADR, IEEE 2030.5 and OSCP. Both OpenADR and IEEE 2030.5 have specific “demand
response” functionality, which boils down to 1 “sending” system that sends out requests to
adjust the power usage to which receivers can respond. The purpose of this is better matching
demand (consumption) and supply of energy. An example application for demand response is
to prevent problems in the grid.
The stakeholder society is primarily related to adapt charging based on the availability of
renewable energy (see also [EUEL2015]). This is not directly visible in the protocols under
consideration. However, this information could be incorporated in the price of charging and
therefore indirectly in the tariff structures of the protocols.
When looking at the protocols from the perspective of smart charging the first notable
observation is that when looking at the roaming platform protocols, only the Gireve platform in
combination with the eMIP protocol has support for smart charging. This platform can get the
SoC from the EV in case it is a Renault. The platform has a connection to the OEM platform.
This setup is visualized in Figure 22. Please note that that DSO signals are currently only used
in pilot setups and these are not yet legally enforced. Whether these are to be sent to the EMSP
or CPO role, is not fixed. Therefore, two lines are drawn, from DSO to both CPO as well as
EMSP.
75
Figure 22: Smart charging using Gireve platform
This means that currently in this setup only one brand of EV’s can be smart charged efficiently
by using the SoC (i.e. Renault). This looks like a second step in the protocols related to smart
charging: besides exchanging smart charging messages between EMSP and CPO, the addition
of connections to OEM platforms for getting the SoC.
In the future the SoC (and perhaps the ToD as well), may be acquired from an EV using the ISO
/ IEC 15118 protocol. However, this has a dependency of both the charge point as well as the
EV. Currently the market adoption is still low, so in the short term, this cannot be used. Once the
ISO / IEC 15118 protocol is implemented (including the SoC functionality), a logical combination
is visualized in Figure 23.
Figure 23: Smart charging using ISO / IEC 15118
76
This figure implies that part of the input for smart charging is to be communicated from the DSO
on the right side and the EV on the left side to either the CPO or the EMSP. The ISO / IEC
15118 protocol also supports scheduling at the EV side, which means that the EV is able to
communicate a charging schedule. One of the future scenarios therefore is that both the SoC
and ToD information all come from the EV and the role of the EMSP is minimized to just
handling billing. The CPO could be made responsible for scheduling based on the EV input and
the grid limits from the DSO.
Please note that all figures implicitly assume that the required information can be sent using the
OCPP protocol. Currently this is not yet possible for the ISO / IEC 15118 scenario.
Figure 24: Smart charging based on ISO / IEC 15118 with minimized role of EMSP
6.5 Protocol relevance for smart grid from a DSO perspective
From a DSO perspective electric vehicles are a heavy load on the electricity grid. In some
countries this is expected to lead to capacity problems in the coming years, once the number of
EVs starts growing. From a DSO perspective it is therefore important that the protocols within
the EV domain have some kind of possibility to make sure that the network will not break down.
This could be done by informing market parties about the grid. Another possibility for the DSO is
to take over control. This means that all protocols that support some form of smart charging that
include a DSO role, are relevant. When looking at the protocols in this study, most of these are
in some way related to smart charging. However, the fact that the DSO can use, for example,
OpenADR or OSCP to send signals to market parties is not enough. Grid stability cannot be
ensured if parties are free to ignore the signals meant to protect the grid. The market will require
some form of regulation to enforce this.
The only protocols that are currently not directly relevant from a DSO perspective, are the
roaming protocols without smart charging functionality. These impact the grid, but offer no way
77
of influencing. That is why they are irrelevant to DSO in the controlling sense, but are still
indirectly relevant because of their impact on the grid.
When looking at smart grids in general, the IEEE 2030.5 protocol also adds functionality for in
house devices. The relevance of this is limited, since most in house devices do not use much
energy when compared to an EV. Furthermore, most devices do not have much flexibility
compared to EVs: for most in house devices it is not an option to postpone the electricity usage.
Experiments using smart washing machines have been executed in the Netherlands in the
context of behavioral research. For this type of applications IEEE 2030.5 could be considered
relevant.
6.6 Relation to home charging
The choice of protocols (except for the IEEE 2030.5 protocol) in this study implicitly has the
assumption that the use of a Home or Building Energy Management Systems, (B/H)EMS, for
controlling a charge point is excluded. If a charge point is not connected to the outside world,
but only to an EMS, no direct control of charging is possible. Furthermore, since it might be
located in house (i.e. in a parking garage), perhaps no authentication is required. This means
that a lot of functionalities from the protocols described in this study are not necessary: parts of
OCPP for authorization are not needed, roaming is not applicable and if the charge point is
behind the home meter, billing might also not be applicable. As indicated in the beginning of this
document, this study is primarily based on European experiences at ElaadNL. If a (B/H)EMS is
taken into account, an example setup is shown in the figure below.
Figure 25: Example setup including (B/H)EMS
78
It is recommended to do more research on (B/H)EMS to incorporate these into the existing EV
charging and smart charging chains that currently operative in Europe.
79
7. CONCLUSION AND RECOMMENDATIONS
7.1 Conclusion
Research question 1: This question concerns the functionalities supported by the EV related
protocols within the scope of this study. This question has been addressed in the chapters 5.1,
5.2, 5.3 and 5.4. The main functionalities are summarized in Table 3.
Table 3: Overview of protocol functionalities
28
The aspects of interoperability, maturity and market adoption have been added as separate
paragraphs. These results are summarized in Table 4.
Table 4: Overview of maturity, interoperability and market adoption
28
O → Operating Charge Point using 61850-90-8: only the basics
Smart Charging in OCHP: only OCHPdirect and only basics
Smart Charging in eMIP: only 1 OEM (so only 1 car brand)
80
Research question 2: This question concerns which set of protocols is best applicable for
which functionality in different types of situations. Due to the overlap between protocols, it is
very difficult to say what protocol can be used in which situation: many combinations are
possible and the exact requirements, which could include future ambitions, determine what
protocol set should be used. In the chapters 5.1.5, 5.2.3 and 5.3.5 some guidance on the
applicability of the protocols is given. Chapter 6 describes a number of possible protocol
combinations for EV charging and smart charging.
However, a number of (main) conclusions can be drawn in this study:
• Roaming:
o The next step for the roaming protocols seems to be the addition / extension of
smart charging functionality. This is currently only available in the eMIP protocol.
o A choice is to be made whether both point-to-point protocols or a clearing house
type of communication is to be pursued for roaming.
o A next step could be to connect multiple clearing house platforms.
• Smart Charging:
o In the future, the State of Charge (and perhaps the Time of Departure as well),
can be acquired from an EV using the ISO / IEC 15118 protocol.
o For the short term (while waiting for wide scale adoption of ISO / IEC 15118) a
second step in the protocols related to smart charging, could be the addition of
connections to different OEM platforms for getting the SoC.
• Communication to the EV user is necessary for providing information, but could also be
used to collect information (e.g. time of departure). Currently however, none of the
protocols under consideration are aimed at the EV user.
A sub question of research question 2 concerns the protocol relevance for smart grid from a
DSO perspective. This question is addressed in paragraph 6.5. There we conclude that most of
the protocols are relevant either directly or indirectly.
7.2 Recommendations
Based on this study the following recommendation are made:
1. Put more work in the smart charging aspects of the existing roaming protocols. The
functionality is currently far from serving one European market and is therefore not ready
to enable smart grids throughout Europe.
2. Set a next step in roaming platforms. Some options are connecting the different
platforms or merge platforms together. However, this is viewed from a technical
perspective. It is recommended to also analyze the political and commercial interests,
which may turn out to more predominant than the technical solution. Ultimately the
81
technical solutions will have to adapt to the limitations imposed by politics and
commerce. At the same time, a technical solution may take into account that political
and commercial interests are not a constant.
3. Referring to the previous point, it is recommended to start a separate study on this topic,
perhaps looking from a more broad perspective:
a. Creating a proposal for a long term architecture vision concerning point to point
solutions and clearing houses. This could for example be that we will end up with
a hybrid model.
b. Setting up a roadmap that would make a gradual growth to the proposed solution
possible.
c. Making suggestions for increasing the chance of acceptance of the solution.
4. To accelerate the adoption of smart charging in a user friendly way, the state of charge
and time of departure are of importance. The state of charge will become available when
using the ISO / IEC 15118 protocol. Based on the expectations of the market penetration
of this protocol, it is recommended to temporarily get the state of charge from the OEMs,
perhaps via roaming platforms, to prevent rapid growth in connection between parties in
the EV market. Alternatively a clearing house-like centralized system that offers a
standard SoC interface to other systems could be investigated. This could abstract from
vendor specific APIs. Again commercial interests should be taken into account here.
5. Protocols for communicating grid limits or dynamic pricing are already available.
However, current legislation in most countries is not yet prepared for dynamic pricing or
setting grid limits from a DSO. It is recommended that this legislation is changed to make
it possible to utilize the flexibility that EVs offer.
6. Based on the maturity of the different smart charging protocols it should be explored
whether the specific use case supported by the OSCP protocol can also be covered by
OpenADR or IEEE 2030.5 messages, with an additional behavior specification /
implementation guide.
7. In Europe little / no experience with Energy Management Systems is available. It is
recommended to include an EMS in new pilot projects. A possible candidate for this
could be IEEE 2030.5. However, as mentioned earlier, to our knowledge, no production
implementations currently exist.
8. The impact of power system operator control signals (e.g. 61850-90-8) in case of a
critical situation in the electricity grid, is to be further investigated due to its impact on the
rest of the EV chain. This impact can be on for example billing, but also on charge point
operation (prevent false positive for charge point malfunctioning).
9. When looking at the protocols under consideration, it should be explored whether it is
useful to extend / develop protocols that are more closely targeted at EV user
communication. This could be directly explored, but also indirectly by creating an
overview that EV user related datastructures / fields / elements are currently used in the
different protocols.
10. Referring to 9, in general it is recommended to explore datamodels / datastructures that
are used in the different protocols for improved interoperability when using combinations
of protocols.
82
11. Additional criteria could be added to compare protocols, such as scalability, the extent to
which protocols are “similar” or “compatible” to other protocols in the EV chain (e.g.
similar datamodel etc.).
12. Add a number of additional protocols to this comparison, such as: DIN SPEC 70121,
CHAdeMO, ECHONET-Lite and IEC 61851-24.
13. In the previous chapter the roles of DSO, TSO and BRP were briefly addressed. A next
step could be to explore the current and future relation / dependency between these
roles in more detail, specifically in relation to EV.
14. To have better insight which protocol combinations will become more likely in the near
future, it is recommended to get more input from OEMs about future plans.
83
LITERATURE
Protocol documentation
[OpenADR2015]: OpenADR ALLIANCE: OpenADR 2.0 Profile Specification B Profile, 2015
[OCPI2016]: EVIOLIN: Open Charge Point Interface 2.1, 2016
[OCPI2014]: EVIOLIN: OCPI, NDR & CDR Interface 1.0 (DRAFT v4), 2014
[eMIP-SC2015]: GIREVE-JMR: eMIP Protocol Implementation Guide - Smart Charge, 2015
[OICP-CPO2016]: HUBJECT: Open InterCharge Protocol for Charge Point Operators Version
2.1, 2016
[OICP-EMSP2016]: HUBJECT: Open InterCharge Protocol for Emobility Service Provider
Version 2.1, 2016
[IEC-61850-2015]: IEC: IEC 61850-90-8 TR:Communication networks and systems for power
utility automation - Part 90-8: Object model for electric mobility, 2015
[ISO-IEC15118-2-2014]: ISO-IEC: ISO 15118-2: Road vehicles - Vehicle-to-Grid
Communication Interface - Part 2: Network and application protocol requirements, 2014
[ISO-IEC15118-1-2013]: ISO-IEC: ISO 15118-1: Road vehicles - Vehicle to grid communication
interface - Part 1: General information and use-case definition, 2013
[OCPP2015]: Open Charge Alliance (OCA): Open Charge Point Protocol 1.6, 2015
[OSCP2015]: Open Charge Alliance (OCA): Open Smart Charging Protocol 1.0, 2015
[eMIP2016]: RIVES, J.-M.: eMIP Protocol Protocol Description, 2016
[OCHP2016]: SMARTLAB, ELAADNL: OCHP: Open Clearing House Protocol, 2016
[SEP2-2013] IEEE, IEEE Adoption of Smart Energy Profile 2.0 Application Protocol Standard,
2013.
[SMC-SEP2013] SAE, Communication for Smart Charging of Plug-in Electric Vehicles using
Smart Energy Profile 2.0, 2013
Other context related documents
[CCE2012] Smart Grid Coordination Group - Sustainable Processes, CEN-CENELEC-ETSI,
2012.
[EUEL2015] Eurelectric, Smart charging: steering the charge, driving the change, 2015
84
Websites of protocol authors / publishers
Protocol
Website
Open Smart Charging Protocol (OSCP)
www.openchargealliance.org
OpenADR
https://www.oasis-
open.org/committees/energyinterop/ and
http://www.openadr.org/
Open Charge Point Interface (OCPI)
http://en.nklnederland.nl/
https://github.com/ocpi
Smart Energy Profile (SEP)29
http://www.ieee.org/
OCPP
www.openchargealliance.org
IEC 61850(90-8)
http://www.iec.ch/
Open Clearing House Protocol (OCHP)
http://www.ochp.eu/
Open Charge Point Interface (OCPI)
http://en.nklnederland.nl/
Open InterCharge Protocol (OICP)
https://www.hubject.com/
eMobility Inter-Operation Protocol (eMIP)
http://www.gireve.com/
IEC 61851-1
http://www.iec.ch/
ISO / IEC 15118
http://www.iso.org/ & http://www.iec.ch/
29
This protocol is sometimes referred to as 2030.5.
APPENDIX A: FUTURE PLANS PER PROTOCOL
A number of reviewers of this document, gave feedback that included remarks like "we are working on functionality X in the next version". I have not
taken these functionalities into account for this version to make a fair comparison. However, this information is relevant, so the table below gives an
overview of the future plans per protocol:
Table 5: Future plans per protocol
Protocol
Functionality
Version
Due (estimated)
Remarks
OpenADR 2.0B
Distributed Energy Resource management
functions
1.2
Q3 2017
Plan is to add signal types to enable further
DER related functions. Further, an addendum
document will contain Transactive Energy
messages (e.g. energy bidding, etc.)
IEEE 2030.5
Smart inverter management
N.a.
Expected to “go to ballot” in
early 2017.
An update that will incorporate new
capabilities required by the state of California
for smart inverter management
OCPP
• Security enhancements
• ISO / IEC 15118 support
• Support for external smart charging
control signals
• Device model
• Tariffing and pricing
T.b.d.
2017
OCPI
• Bug fixes
• Smart charging
2.1.1 and
2.2
2017
1
• Better connection with roaming hubs
• Multiple languages
• Tariffing
• Correcting CDRs
• Charge point groups
• Enabling module based
implementations
• Support for virtual operators and
service providers (including navigation
service providers)
• Module for supporting data collection
for data analysis purposes
2
APPENDIX B: PROTOCOL USE CASE TABLE
Below you will find a complete overview of the detailed use cases supported by the protocols in this document, as also visualized in the protocol use
case diagrams:
Protocol
Smart charging
CS <> CP
Roaming
EV <> CP
OSCP
OpenADR
OCPI v0.4
IEEE 2030.5
OCPP
IEC61850-90-8
OCHP
OCPI 2.1
OICP
eMIP
IEC 61851-1
IEC 15118
Use cases
(De)register
●
●
(Provide) Charging details
●
AC charging with load levelling based on
High Level Communication
●
Approve CDR
●
Authorization at EVSE using ext.
credentials performed at the EVSE
●
Authorization at EVSE using ext.
credentials performed with help of SA
●
Authorization using Contract Certificates
performed at the EVSE
●
Authorization using Contract Certificates
performed with help of SA
●
Authorize and store subscription
●
Authorize charging session
●
●
●
●
●
●
●
Billing
●
●
●
●
●
Certificate Handling
●
Certificate install
●
3
Certificate update
●
Charge point diagnostics
●
Charging controlling and re-scheduling
●
Charging loop
●
Charging loop with interrupt from the
EVCC or user
●
Charging loop with interrupt from the
SECC
●
Charging loop with metering information
exchange
●
Check authorization
●
Collect metering data from charge point
●
Collect transaction information (billing)
●
Communicate charging schedule
●
●
Communicate grid conditions
●
Configure charge point
●
Control (a selected) charge point
●
Control charge points
●
●
Data transfer
●
DC charging with load levelling based on
High Level Communication
●
Decrease/ increase power consumption
of individual devices
●
●
●
Demand Response / load control
●
Discovery
●
4
Distribute DR event
●
Distribute dynamic prices
●
Download CDR
●
●
●
Download charge point information
●
●
Download full list of roaming
authorisation data
●
●
Download live status information
●
●
Download Tariff Information
●
●
Download updates in roaming
authorisation data
●
End-of-charging process
●
Energy flow reservation
●
EV charging
●
●
EV-charge point communication setup
●
Exchange endpoints
●
●
Exchange of Authorisation Data
●
●
●
Exchange of Charge Point Information
●
●
●
Exchange of Parking Spot Information
●
●
Exchange of Tariff Information
●
Exchange raw billing (charging) data
●
●
Exchange versions
●
Exchanging metering data
●
●
●
●
Execute Smart Charging commands
●
Get current vehicle status
●
5
Get roaming partners interface
definitions
●
Hand out capacity "budgets"
●
Handle OCPI Registration
●
Handle registration
●
●
●
Handle VEN registrations
●
Identification, authorization and
authentication
●
Influence grid usage
●
●
Inform driver of actual session costs
●
●
Live status interface
●
●
Maintain local authorization list
●
Maintenance of Charge Point
●
Manage charge point availability
●
Manage charge point firmware
●
Manage DER
●
Manage grid capacity by communicating
cable capacity forecasts
●
Manage grid capacity by communicating
price signals
●
Manage grid
●
●
●
●
●
Manage power consumption of Charge
Point
●
●
●
●
Operate Charge Point
●
○
Optimized charging with scheduling at EV
●
6
Optimized charging with scheduling to
secondary actor
●
Prepayment
●
Process Charge Data Records
●
Provide actual usage and billing
information
●
●
●
Provide Charge Detail Records
●
●
●
●
Provide charge need
●
Provide charge point information
●
●
●
●
●
Provide charge point location
information
●
●
●
●
Provide charging session information
●
●
Provide information about Charge Point
availability, pricing
●
Provide tariff information
●
●
●
Provide token information
●
●
●
●
●
Reactive power compensation
●
Receive (and cache) token information
●
●
●
Receive / process Opt-In / Opt-Out
schedules
●
Receive DR events
●
Receive report
●
Reject CDR
●
Release a selected charge point
●
Remote (emergency) stop, suspend,
restart charging
●
7
Remote Control of Charge Point
●
●
Remote start / stop transaction
●
●
●
●
Remove (own) authorisation data
●
Remove (own) charge point information
●
Report a data or compatibility
discrepancy
●
Report remote (emergency) stop,
suspend, restart charging
●
Request capacity / Indicate needs
●
Request Capacity Forecast
●
Request charge needs
●
Request charge point information per
hierarchical level
(charging pool, station, EVSE, connector)
●
Request charging process information for
a customer
●
Request current live status
●
●
Request current live status per
hierarchical level
(charging pool, station, EVSE, connector)
●
Request smart charging for a driver
●
Request the CHS to authorize one single
token for roaming
●
●
●
Reservation
●
●
●
●
●
●
Reservation of charge point
(administratively)
●
●
●
●
Reserve a charge point for a driver
●
●
●
●
8
(administratively)
Reserve charge point (technically)
●
●
Respond to DR event
●
Resume to Authorized Charge Schedule
●
Retrieve list of EVSE's located in a given
area and fulfilling a set of criteria
●
Revise CDR
●
Roaming
●
●
●
●
●
Schedule based charging
●
●
●
Select a charge point
●
Send Aggregated Usage
●
Send Capacity Forecasts
●
Send charging dispatch signal
●
Send Charging event
●
Send customer bid level signal
●
Send data report
●
Send demand charge signal
●
Send DSO Heartbeats
●
Send electricity price signal
●
Send energy price signal
●
Send Event Signal
●
Send heartbeats to CHS
●
Send load control signal
●
Send load dispatch signal
●
9
Send metadata report
●
Send Opt-In / Opt-Out schedules
●
Send remote commands to location /
EVSE
●
●
Send Report
●
Send reset charge point message
●
Send simple signal
●
Send Unlock connector command
●
Sending text messages
●
Set (own) interface definition
●
Set charge point availability
●
Set resource availability
●
●
Set tariff restrictions (e.g. maxEnergy,
maxDuration)
●
Single Authorization Requests
●
●
●
Smart Charging
●
●
●
●
●
●
○
○
●
●
Start / stop transaction
●
Start of the charging process
●
●
Start of the charging process with
concurrent IEC 61851-1 and HLC
●
Start of the charging process with forced
HLC
●
Subscribe to charge point information
●
Subscribe to sub-set of charge points
●
Target setting and Charging scheduling
●
10
Trigger message from charge point
●
Update (own) authorisation data
●
●
Update Tariff Information
●
Update the live status of stations
●
●
●
Update the live status of stations per
hierarchical
level (charging pool, station, EVSE,
connector)
●
Upload (own) authorisation data
●
●
●
Upload (own) charge point information
●
●
●
Upload Charge Data Records
●
●
Upload charge point information per
hierarchical
level (charging pool, station, EVSE,
connector)
●
Upload Tariff Information
●
●
Validate authorization
●
Value-added services
●
Vehicle to grid support
○
