Skip to main content

New functionalities in OCPP2.0

OCPP 2.0 introduces new functionalities compared to OCPP 1.6 [OCPP1.6].

Due to improvements and new features, OCPP 2.0 is not backward compatible with OCPP 1.6 [OCPP1.6] or OCPP 1.5 [OCPP1.5].

Device Management​

Device Management (also known as Device Model) is a long awaited feature especially welcomed by CSOs who manage a network of (complex) charging stations (from different vendors). It provides the following functionality:

  • Inventory reporting
  • Improved error and state reporting
  • Improved configuration
  • Customizable Monitoring

This all should help CSOs to reduce the costs of operating a Charging Station network.

Charging Station Manufacturers are free to decide themselves how much details about a Charging Station they want to publish via Device Management: for example, they can decide what can be monitored, and what not.

Improvements for better handling of large amounts of transactions​

With the growing of the EV charging market, the number of Charging Stations and transactions that the CSMS needs to manage also grows. The structure and method for reporting transaction is unified in OCPP 2.0. In OCPP 1.x, the reporting of transaction data is split over the messages StartTransaction, StopTransaction, MeterValue and StatusNotification. With the market progressing towards more enhanced scheduling, a need is born for more sophisticated handling of transaction data. All the StartTransaction, StopTransaction, and transaction related MeterValue and StatusNotification messages are replaced by 'TransactionEvent'. The StatusNotification message still exists, but only for non-transaction related status notifications about connector availability.

Data reduction​

With the introduction of JSON over Websockets in OCPP 1.6 [OCPP1.6] a great reduction of mobile data cost can be achieved. With OCPP 2.0, support for WebSocket Compression is introduced, which reduces the amount of data even more.

Improvements regarding cyber security​

The following improvements have been added to harden OCPP against cyber attacks:

  • Security profiles (3 levels) for Charging Station and/or CSMS authentication and Communication Security
  • Key management for Client-Side certificates
  • Secure firmware updates
  • Security event log

Extended Smart Charging​

In OCPP 2.0 Smart Charging functionality has been extended (compared to OCPP 1.6 [OCPP1.6]) to support:

  • Direct Smart Charging inputs from an Energy Management System (EMS) to a Charging Station
  • Improved Smart Charging with a local controller
  • Support for integrated smart charging of the CSMS, Charging Station and EV ([ISO15118-1]).

Support for ISO 15118​

The ISO 15118 standard [ISO15118-1] is a newer protocol for EVSE to EV communication, compared to IEC 61851 [IEC61851-1].

ISO 15118 allows a lot of new features and more secure communication between EVSE and EV. OCPP 2.0 supports the ISO 15118 standard, the newly added features are:

  • Plug & Charge
  • Smart Charging including input from the EV

Improvements for customer experience​

More authorization options​

OCPP 1.x was designed (mainly) for Charging Stations that authorize an EV driver via an RFID card/token. If other authorization systems or a mix of systems are used, the CSMS needs to know what system is used for which authorization. OCPP 2.0 has been extended to support things like: 15118 Plug & Charge [ISO15118-1], Payment Terminals, local mechanical key, Smart-phones, etc.

Display Messages​

This provides Charging Station Operators with the possibility to configure - from the CSMS - a message on a Charging Station to be displayed to EV drivers. Messages can be transaction related or global.

EV Driver preferred languages​

To be able to show messages to an EV driver in a language the driver understands best, OCPP 2.0 provides the possibility to send the language preference of a driver to a Charging Station.

Tariff and Costs​

OCPP 2.0 allows Charging Stations 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.

Transport Protocols: OCPP-J Improvements​

Simple Message routing​

A description has been added on how to create a simple solution for OCPP message routing in, for example, a Local Controller. This is defined in Part 4, Section 6: OCPP Routing.

No SOAP Support​

OCPP 2.0 no longer supports SOAP as a transport protocol. This decision was taken by the OCA members, who believe that the protocol does no longer lend itself for constrained computing resources that many Charging Stations operate under. The verbosity of the protocol could lead to slower performance and requires a higher bandwidth, which, in many cases, leads to higher cellular costs. SOAP is also difficult to support when communication is via local site networking.

Minor changes/extensions​

Renamed messages​

In the OCPP 1.x series, the names of all messages were kept unchanged for backward compatibility, even though some message names were found to be confusing or misleading in practice. In OCPP 2.0 message names have been changed, where appropriate, to improve clarity and understanding.

Example: RemoteStartTransaction.req: a lot of implementers though it meant the Charging Station should start the transaction, but in fact it is a request to try to start a transaction. However, for example, if no cable is plugged in, no transaction can be started.

Since the message was always intended to be a request, it has been changed to a more logical name: RequestStartTransactionRequest.

TransactionId Identification & Message Sequencing​

In OCPP 2.0, transaction identifiers are generated by the Charging Station, to facilitate offline charging sessions, in contrast to OCPP 1.x, where transaction identifiers were generated at the CSMS and sent to the Charging Station. In addition, all messages relating to a transaction are assigned incremental sequence numbering, to facilitate transaction data completeness checking at the CSMS.

Extended enumerations​

Many enumerations have been extended to support more use cases, provide more options etc.

Offline Transaction Event Indication​

Charging Stations can optionally indicate in transaction messages that a transaction event occurred while the Charging Station was Offline. This can assist a CSMS with the processing of transactions.

Personal message​

Message that can be shown to the EV Driver and can be used for tariff information, user greetings and for indicating why a driver is not authorized to charge. When a driver uses an authorization method (RFID for example) and the CSMS does not authorize the driver to start charging, this field can thus contain additional reasons to provide the driver with a meaningful explanation why (s)he is not allowed to charge.