How to implement basic charging with OCPP 2.0 | Open Charge Point Protocol

“What is OCPP 2.0 and why should I care to implement it, when there is a well proven OCPP 1.6? ”. OCPP 2.0 looks huge ; should I implement all of them at one go? Or is it possible to get started with minimal set of messages & use cases for a basic charging?

These were the frequently asked questions whenever I talk about OCPP2.0. Open Charge Alliance website, as well the official specifications have answers for everything; however for those who don’t have time to read everything, this post may give a quick start.

What is OCPP 2.0 ?

The Open Charge Point Protocol (OCPP) is the industry-supported de facto standard for communication between a Charging station and a Charging station Management System (CSMS). The OCPP protocol has become more advanced and with every new revision new functionalities and options are added.

In April 2018, the Open Charge Alliance launched the OCPP2.0 which is far superior to all its predecessors OCPP1.x versions, with 16 Functional Blocks and 116 use cases.

Why should you implement OCPP 2.0 ? | New functionalities

OCPP 2.0 introduces new functionalities compared to its predecessor OCPP 1.6 . Below are some key improvements/ new functionalities; but what you need to keep in mind is that due to the different architecture set-up, the OCPP 2.0 is not backward compatible with previous versions such as OCPP 1.6 or OCPP 1.5.

1. Introduction of device management:

This new feature will be useful for charge point operators (CPO) who manage a network of multiple charging station s from different vendors. It enables Inventory reporting, Improved error and state reporting, Improved configuration and Customizable Monitoring of charging station install base.

2. Better handling of large amounts of transactions:

This functionality will also be much of help to charge point operators who manage large number of charging station s and transactions.

In OCPP 1.6, the reporting of transaction data is split over the messages as StartTransaction, StopTransaction, MeterValue and StatusNotification. But in OCPP2.0, all these messages are replaced by one message 'TransactionEvent’. This enables more sophisticated handling of transaction data.

PS: TheStatusNotification message still exists, but only for non-transaction related status notifications about connector availability.

3. Cost savings in GSM data (& handling)

OCPP1.6 is already saves a lot of data when comparing with OCPP1.5 or SOAP transactions; Additionally in OCPP 2.0, WebSocket Compression is also newly introduced. This would reduce even more mobile data costs.

4. Improved cyber security

In addition to secure firmware updates and Security event logging, security profiles (Level-3) for Charging station and/or CSMS authentication, Communication Security, Key management for Client-Side certificates are also added in OCPP2.0

5. Extended Smart Charging

OCPP2.0 enables direct smart charging input from an Energy Management System (EMS) to the Charging station – enabling easy smart home integrations. It also provides possibility of seamless smart charging integration between CPO back office (CSMS) , Charge point (EVSE) & Electric Vehicle (EV).

6. Native support for ISO 15118

OCPP 2.0 supports the ISO 15118 - a newer protocol for EVSE to EV communication. ISO 15118 standards’ Plug & Charge and Smart Charging including input from the EV are easier to implement with OCPP 2.0

7. More authorization options

OCPP 1.6 was designed (mainly) for Charging station s that authorize an EV driver via an RFID card/token ; OCPP 1.6 back offices can’t (directly) identify which mode of authorization was used. However, OCPP 2.0 allows multiple authorization modes such as: 15118 Plug & Charge, Payment Terminals, local mechanical key, Smart-phones, etc.

8. Display messages on Charging stations

OCPP 2.0 enables Charging station Operators with the possibility to send (from the CSMS) a message on a Charging station to be displayed to EV drivers.

This for example will enable Charging station s to show the applicable tariff/price before an EV driver starts charging, to show the running total cost during a charging transaction and/or to show the final total cost after the transaction is finished. OCPP 2.0 also provides the possibility to send the language preference of a driver to a Charging station .

How to implement a basic charging with OCPP 2.0

The OCPP protocol describes many use cases and messages. There are 16 Functional Blocks with one or more use cases in each of them. Out of these only a minimal set of messages may be sufficient to implement a basic Charging with OCPP 2.0. The table below lists messages that are typically implemented to deliver basic functionality for an OCPP managed charging station .

Note: Purpose of this list is only to guide developers to get started with OCPP 2.0; this list does not make you full OCPP 2.0 compliant. To become OCPP 2.0 "certified:, all the messages/ functionalities defined in the Part 5 of the specification.

#	Functionality	Messages
1	Booting a Charging station	BootNotification
2	Configuring a Charging station	Set Variables, Get Variables and GetReportBase (respond correctly to requests with reportBase = ConfigurationInventory, FullInventory, Summary Inventory).
3	Resetting a Charging station	Reset
4	Authorization options	Authorize
5	Transaction mechanism	Transaction Event
6	Availability	Only Change Availability and Status Notification.
7	Monitoring Events	A basic implementation of the Notify Event message to be used to report operational state changes and problem/error conditions of the Charging station , e.g. for Lock Failure. Also used for reporting built-in monitoring events.
8	Sending transaction related Meter values	Transaction Event
9	DataTransfer	Any OCPP implementations should at least be able to reject any request for Data Transfer if no (special) fun

Booting, Configuration and Resetting a Charging station :

Booting, configuring and resetting of the Charging station Functionalities goes under the “Provisioning” Functional block of OCPP 2.0. This Functional Block depicts every one of the functionalities that assistance a CPO arrangement their Charging station s, enabling them to validate certifications and recover setup data from these Charging station s over a system. Also, it comprises of the capacity to make changes to the Charging System configuration, as well.

There are 12 use cases which gone under this functional block, among them are– Cold Boot Charging station , Cold Boot Charging station - Pending, Cold Boot Charging station Rejected, Offline Behavior Idle Charging station , Set Variables, Get Variables, Get Base Report, Reset -Without Ongoing Transaction and Reset-With Ongoing Transaction – are the mandatory use cases for the essential execution of OCPP 2.0.

Authorization options:

This functionality comes under the Authorization Functional block of OCPP 2.0, This functional block describes all the authorization-related functionalities, it contains different ways of authorizing a user (online and/or offline), the AuthorizeRequest message handling, and the Authorization Cache functionality, etc. When a user wishes to unplug the electric vehicle from the Charging station , the Charging station needs to verify that the user is either the one that initiated the charging or that the user is in the same group and thus allowed to terminate the charging.

Once authorized, the Charging station informs the CSMS that the charging has been stopped. This functional block has 16 Use Cases in which any one of these – EV Driver Authorization using RFID, Authorization using a start button and Authorization using PIN-code are mandatory for the basic implementation. 

Transaction mechanism:

This functionality comes under Transactions Functional block of OCPP 2.0 and it describes the OCPP transaction related functionalities. Transactions can be started or stopped on the Charging station with only one active transaction on an EVSE, at a time.

This functional block has 15 use cases – Start Transaction Options, Start Transaction-Cable Plugin First, Start TransactionIdToken First, Start Transaction-Id not Accepted, Stop Transaction Options, Transaction locally stopped by IdToken, Transaction stopped while Charging station is offline one of when cable disconnected on EV-side: Stop Transaction and When cable disconnected on EV-side: Suspend Transaction, Connection Loss During Transaction, Inform CSMS of an Offline Occurred Transaction and Transaction related message not accepted by CSMS are mandatory for basic implementation. 

Availability:

This functionality goes under Availability Functional block of OCPP 2.0. It indicates how the Charging station can educate the CSMS of its present accessibility for beginning new exchanges. It is vital for the CSO to know whether a Charging station is accessible for EVs to be charged, with the goal that they can advise EV drivers whether the Charging station is accessible for use.

Therefore, the Charging station ought to consistently send any status changes of itself or any of its EVSEs to the CSMS. This transaction status is exceptionally helpful for an EV Driver when he encounters issues amid charging. At the point when a blame is recognized by the Charging station it can communicate something specific telling the CSMS about the fault.

At the point when the CSO needs the Charging station to never again begin new exchanges, it can change the accessibility. For instance: they have to do upkeep on the Charging station , and hence they don't need the Charging station to be being used. The CSO can likewise change the accessibility for at least one EVSEs.

For instance: A client calls, whining about a broken EVSE on the Charging station . The CSO would then be able to set the Connector to inaccessible, making it impossible for an EV Driver to utilize that Connector. Clearly, with a direction from the CSMS it is likewise conceivable to make the Charging station or a Connector accessible once more.

This functional block has 5 use cases, out of which 4 of the use cases are a mandatory, they are - Status Notification, Change Availability EVSE, Change Availability Charging station and Lock Failure. 

Sending transaction related Meter values:

This functionality comes under Metering Functional block of OCPP 2.0. It describes the functionality that enables a Charging station to send periodic, possibly clock-aligned Meter Values. Extensive metering data relating to transactions can be recorded and transmitted in different ways depending on its intended purpose. This Functional Block has 3 use cases in which Sending transaction related Meter Values is the MUST Use Case to Implement basic OCPP 2.0.

Hope this article has given some idea to get started with OCPP 2.0. You may download the official OCPP2.0 specification, which details all the required info any developer would need. Please reach out, in case if you still miss anything. I shall retry to clarify or will connect to the experts at least.