Research and Implementation of OCPP 1.6 Protocol [608508]

Research and Implementation of OCPP 1.6 Protocol
Chaoyue Zhao1,a, Xiangdong You2,b,*
1Beijing University of Posts and Telecommunications ,
School of Information and Telecommunication Engineering, No.10 Tucheng Road(West) , Beijing, China
2Beijing University of Posts and Telecommunications ,
School of Information and Telecommunication Engineering, No.10 Tucheng Road(West) , Beijing,
China
a18811396149@ 163.com, [anonimizat]
Keywords: New E nergy, Electric Vehicle, Charge Point, OCPP 1.6.
Abstract : With the development of new energy vehicles in technology and i ndustry, as well as the
government ’s financial incentives and related policies’ support , the new energy vehicles are
constantly popularization and development , especially electric vehicles. More and more people
choose electric vehicles as their travel tool s. However , the charging facilities are imperfect , non-
standard and charging standards are not unified. There is no unified communication protocol
between the various charging pile manufacturers, which makes the charging pile difficult to
popularize. These factors restrict the development of new energy vehicles, especially electric
vehicles. The emergence of OCPP 1.6 standardization provides a practical and effective solution for
the integrati on and globalization of charging protocol .
1. Introduction
After the financial crisis , the world ’s major countries regard the development of electric vehicle
industry as their national strategy , and the development of new industries becomes an important
way to alleviate the energy crisis[1]. China surpasses the United States and become the world ’s
largest electric car country in production and sales in 2015. As a clean energy means of transport,
electric vehicles has been more and more popular of all ages wi th its low fuel prices and security.
However, the real restriction on the electric car is the construction of charging pile and the convenience of charging. The standardization and uniformization of the charging pile protocol, the
interconnection communication between the equipments and the data communication between the
charging pile manufacturers are the core problems to realize the rapid laying and use of the charging pile. The OCPP 1.6(Open Charging Protocol) proposed by the Open Charging Alliance (OCA) has
been applied to more than 40, 000 charging facilities in 49 countries, it has become a global standard. This paper studied the OCPP 1.6 and simulated the transmission of the message specified by the protocol.
2. About OCPP 1.6
2.1. What is OCPP (Open Charg e Point Protocol )
The Open Charging Alliance (OCA) is an international affiliate organization that includ ing
leadi
ng and business leaders in the public and private areas of electric vehicle infrastructure . The
goal of the Open Charging Alliance is to promote the development and application of the charging protocol for electric vehicle charging facilities through cooperation, education , testing and
certification , and to promote the industry standard of the relevant agreements . Open Charge Point
Protocol (OCP P) is an open communication standard introduced by the Open Charging Alliance . It
is mainly used to solve the difficulties of communication between private charging networks . OCPP
supports communication between the Charge Point and the supplier ’s central m anagement system .
2nd International Conference on Machinery, Electronics and Control Simulation (MECS 2017)
Copyright © 2017, the Authors. Published by Atlantis Press.
This is an open access article under the CC BY-NC license (http://creativecommons.org/licenses/by-nc/4.0/).
Advances in Engineering Research, volume 138
814

OCPP has been used in more than 40, 000 charging facilities in 49 countries , but at present, the
State Grid, the Southern Power Grid, TELD, the Austrian Group and many other domestic charging
equipment manufacturers and operators using th e 104 agreement as the basis for their agreement. It
is difficult to be in line with the international conventions.
2.2. What is OCPP 1. 6
OCPP 1 .6 is based on OCPP 1.5. OCPP 1 .5 has been widely used in the world since 2012, and
many suppliers have applied th e OCPP 1 .5 standard in their products . These application experiences
have been added to OCPP 1.6. A total of 19 companies have contributed their operating experience
to OCPP1 .6.
2.3. The Differences between OCPP 1. 6 And OCPP 1. 5
OCPP 1 .6 introduces new feat ures to accommodate the market: Smart Charging , OCPP using
JSON over Websockets, better diagnostics possibilities(Reason) , more Charge Point Statuses and
TriggerMessage. OCPP 1 .6 is based on OCPP 1.5, with some new features and a lot of textual
improvements, clarifications and fixes for all known ambiguities . Due to improvements and new
features, OCPP 1 .6 is not backward compatible with OCPP 1.5.
2.4. Smart Charging Use Cases
According to the OCPP 1.6, the charging system can be divided into two main parts , the Central
System and the Charge Point . A Charge Point can have multiple connectors to connect with
multiple electric vehicles . The main function of the protocol is to realize the information
communication between the Central System and the Charge Point , so that the status and
corresponding parameters of each transaction of the Charge Point are under the control of the
Central System.
There may be many different uses for smart charging . The following three typical kinds of smart
charging will be used to illustrate the possible behavior of smart charging[2].
2.4.1. Load Balancing U se Case Topology
The Load Balancing use case is about internal load balancing within the Charge Point, the
Charge Point controls the charging schedule per connector . The Charge Point is co nfigured with a
fixed limit, for example the maximum current of the connection to the grid.
The optional charging schedule field minChargingRate may be used by the Charge Point to
optimize the power distribution between the connectors. The parameter informs the Charge Point
that charging below minChargingRate is inefficient, giving the possibility to select another
balancing strategy[2].
The topology is shown in Figure 1.

Figure 1 Load balancing Smart Charging topology.
Advances in Engineering Research, volume 138
815

2.4.2. Central Smart Charging
With Cen tral smart charging the constraints on the charging schedule, per transaction, are
determined by the Central System. The Central System uses these schedules to stay within limits
imposed by any external system. The Central System directly controls the limits on the connectors
of the Charge Points[2].
Central smart charging assumes that charge limits are controlled by the Central System. The
Central System receives a capacity forecast from the grid operator(DSO) or another source in one
form or another and calculates charging schedules for some or all charging transactions, details of
which are out of scope of this specification.
The topology is shown in Figure 2.

Figure 2 Central Smart Charging topology.
2.4.3. Local Smart Charging
The Local Smart Charging us e case describes a use case in which smart charging enabled Charge
Points have charging limits controlled locally by a Local Controller, not the Central System. The
use case for local smart charging is about limiting the amount of power that can be used by a group
of Charge Points, to a certain maximum. A typical use would be a number of Charge Points in a parking garage where the rating of the connection to the grid is less than the sum the ratings of the
Charge Points. Another application might be that the Local Controller receives information about the availability of power from a DSO or a local smart grid node.
Local smart charging assumes the existence of a Local Controller to control a group of Charge
Points. The Local Controller is a logical component. It may be implemented either as a separate
physical component or as part of a ‘master ’ Charge Point controlling a number of other Charge
Points. The Local Control implements the OCPP protocol and is a proxy for the group members ’
OCPP messages, and mayo r may not have any connectors of its own.
In the case of local smart charging the Local Controller imposes charging limits on a Charge
Point. These limits may be changed dynamically during the charging process in order to keep the
power consumption of the group of Charge Points within the group limits. The group limits may be
preconfigured in the Local Controller or may have been configured by the Central System.
The topology is shown in Figure 3.
Advances in Engineering Research, volume 138
816

Figure 3 Local Smart Charging topology.
2.5. Introduction to Related Transmission Parameters
This part will introduce the transfer function and related parameters defined in the OCPP 1.6.
In OCPP 1.6, the Central System and the Charge Point need to transmit and receive messages to
each other, that is, send the request messages and confirm messages. Since the transmission of messages is mutual, all messages can be divided into two types, that is, messages sent by the Central System and messages sent by the Charge Point
[3]. The Central System sends a message to
obtai n the current state information or the control action of the Charge Point[4]. The message sent by
the Charge Point is more about information about the beginning and end of the transaction and heartbeat, sample value and other data related to the business. The following are the Charge Point
request and the Central System request.
2.5.1. Charge Point Request: Heartbeat.req
A Charge Point sends a heartbeat after a configurable time interval t o let the Central System
know that a Charge Point is still connected. The C harge Point will send a Heartbeat.req request,
which does not contain any parameters. Upon receipt of this request, the Central System will return a Heartbeat.conf(currenttime) confirmation message indicating that the Central System has received a heartbeat request and has responded. This response carries a parameter named currenttime that indicates the time of receipt of the request and confirmation. It is a data of the DateTime type defined in the protocol. The transmission diagram is as Figure 4.

Figur e 4 Sequence diagram:Heartbeat .
2.5.2. Central System Request: ReserveNow.req
A Central System can issue a ReserveNow.req to a Charge Point to reserve a connector for use
by a specific idTag.
To request a reservation the Central System send a ReserveNow.req PDU (Protocol Data Unit) to
a Charge Point. The Central System may specify a connector to be reserved. Upon receipt of a
ReserveNow.req PDU, the Charge Point shall respond with a ReserveNow.conf PDU. It carries a
parameter named status. The optional values are: Accepted, Faulted, Occupied, Rejected,
Unavailable.The transmission diagram is as Figure 5.
Advances in Engineering Research, volume 138
817

Figure 5 Sequence diagram: Reserve Now .
3. The T echnology U sed T o Implement OCPP 1.6
Through the OCPP1.6 protocol reading and research, I set up a web server so that the Central
System and Charge Point can communicate with each other.The key technologies used in this
project are Jsp(dynamic web technology), MySQL, HTML+CSS technology, JavaScript technology and Maven(project management tool).
4. Protocol Message Delivery Demonstration
4.1. Project D eployment
First of all, this article refers to a specific implementation of a server on the Internet. A client-
side code was written to implement the message transfer between the Charge Point and the Central
System. The process of building a server is as follows.
●First download the project code from GitHub at the following address:
https://github.com/RWTH- i5-IDSG/steve
.
●Create a database named stevedb in the local database.
●In the steve -master folder, execute “shift+right mouse” to run the DOS command window,
enter “mvn compile” to compil project. ●Enter “mvn package” to generate the target directory, compile and test the code and generate a test report.
●After all the commands are run, execute the following command in the DOS command window
to execute the jar package:Java -jar target/steve -2.1.0.jar.
4.2. Service Terminal Page
4.2.1. Login Page
This page mainly implements the administrator’ s login so the administrator can monitor the
Charge Point ’s information and state, and control the Central System to send messages to the
Charge Point. The screenshot is as Figure 6.

Figure 6 Login page .
4.2.2. User Registration Page
The user registration page is used to register information about these users w ho can use the
Charge P oint. Once the users’ information is registered, the Central System can activate the
charging service by authorizing the authentication after the Charge Point initiates the authentication request to the Central System, and the author ized user can carry out the charging activities. The
screenshot is as Figure 7.
Advances in Engineering Research, volume 138
818

Figure 7 User r egistration page .
4.2.3. Charge Point Registration Page
The id of the Charge Point is the only and special identity of the Charge Point. This page
completes the regi stration of the Charge Point and uniquely identifies its id so that the Central
System can control the Charge Point accurately. This page also contains information such as Charge
Point’s location and etc . The screenshot is as Figure 8.

Figure 8 Charge Point registration page .
4.2.4. Charge Point Overview Page
The Charge Point overview page lists the charging information and the last heartbeat request
time. The screenshot is as Figure 9.

Figure 9 Charge Point overview page .
Advances in Engineering Research, volume 138
819

4.2.5. Charge Point Status Information Overview Page
This page intuitively lists the number of users , the number of charging points, the activities of
the reserved business and the number of ongoing business, charging interface s, heartbeat s and other
information . This page facilitates the overal l control of the administrator. The screenshot is as Figure
10.

Figure 10 Charge P oint status information overview page.
4.3. Send Heartbeat Request
The figure below shows the SoapUI client sending a heartbeat to the server and the server
receiving the heartbeat. The port that server receives the message is:
http://localhost:8080/steve/services/CentralSystemServiceOCPP15.
The screenshot is as Figure 11.

Figure 11 Send H eartbeat r equest .
After the soap message is sent successfully, the Central System will receive the message
displayed in the Charge Point status page, as shown in the Figure 12.

Figure 12 Receive Heartbeat request.
4.4. Send ReserveNow Request
The sengding message page is shown as follow:
Advances in Engineering Research, volume 138
820

Figure 13 Send ReserveNow request.
The Central System wants to send a ReserveNow request to the No.1 connector on the No.1
Charge Point, with the expiration date set as Expire Date. When the ReserveNow request is not
processed when the request exceeds the time limit, the ReserveNow request will expire.
When t he message is sent, the message’ s status becomes waiting, waiting for the response
message.The screenshot is as follow.

Figure 14 ReserveNow request ’s status.
Once the ReserveNow request is accepted, the client returns a status field according to the s tatus
of the connector. The following figure indicats that the reservation was successful and a connector was reserved.

Figure 15 Reserv eNow request sent successfully .
5. Conclusions
This paper introduces the role and function of the OCPP 1.6 and its effect on the development of
the Charge Point . It also briefly describes the process of building the server and the key
technologies needed. Then, based on the server, this paper i mplemented the message transmission
defined by the protocol. Completed the expec ted objectives of this paper.
Acknowledgements
Firstly, I would like to express my sincere gratitude to my supervisor, XiangDong You, for his
instructive advice and useful suggestions on my thesis. I am also indebted to all my friends for their direct and indirect help to me, special thanks should go to them for their comments on the project
and the thesis.
References
[1] Cristina Alcaraz, Javier Lopez, Stephen Wolthusen (20 17) OCPP Protocol: Security Threats and
Challenges . IEEE Transactions on Smart Grid , 2, 1-1.
Advances in Engineering Research, volume 138
821

[2] Open Charge Allianc (2015) Open Charge Point Protocol 1.6.
[3] Á.Rodríguez- Serrano, A.Torralba, E.Rodríguez -Valencia, J.Tarifa- Galisteo (201 3) A
communication system from EV to EV Service Provider based on OCPP over a wireless network .
IEEE, 10, 5434-5438.
[4] Jens Schmutzler, Claus Amtrup Andersen, Christian Wietfeld (2013 ) Evaluation of OCPP and
IEC 61850 for Smart Charging Electric Vehicles . Electric Vehicle Symposium and Exhibition , 10,
1-12.
[5] T. Parker , D. Naberezhnykh (201 3) Charging point strategies for electric com mercial vehicles .
Hybrid and Electric Vehicles Conference, 10, 1-4.
Advances in Engineering Research, volume 138
822