OCPP 1.6 vs OCPP 2.0.1: Key differences for EV charging, CSMS, and charger firmware

I have been working at ChargeLab for the past four years, beginning with joining the team to implement our CSMS (Charging Station Management System) for OCPP 1.6. In 2024, we added support for OCPP 2.0.1 to to be compatible with modern hardware that could take advantage of it. With a large and growing fleet of commercial chargers running on our CSMS, we have gained valuable insights into how the two versions of OCPP behave differently, as well as the pros and cons of implementing each version—from both the charger firmware and CSMS perspectives. 

Charging Start Methods

Both OCPP versions support multiple ways an EV driver can start a charging session: RFID / Card, Remote start via app, Plug-and-charge, plug first, authorize first then plug in, local authorization, auto-start. However, the level of support and the workflow can be very different between the two versions of OCPP. Let’s take a look at this simple aspect of the “Plug-In first” use case and compare the two protocol versions.

OCPP 1.6 Plug-In first

OCPP 1.6 does not include an explicit message for “cable plugged in.” Plug-in detection is inferred indirectly using StatusNotification messages statuses (Preparing, Charging,
SuspendedEV, SuspendedEVSE and Finishing) or even worse, with vendor-specific interpretations. This leads to inconsistent behavior across charger vendors. In our ChargeLab CSMS, we have seen charge stations that immediately send a StartTransaction request right after the EV is plugged-in without authorization; or different vendors interpret the Preparing status differently: Preparing can mean “waiting for RFID” or “cable plugged in but EV not ready” or “internal check before session start.” Because of this vague interpretation, CSMS implementations are left guessing the true meaning of these status transitions.

OCPP 2.0.1 Plug-In first

OCPP 2.0.1 introduces a new TransactionEvent which carries with it a “TriggerReason”.  This value can be set to “CablePluggedIn” with clearly defined transaction lifecycle. This makes the plug-in-first flow more predictable and interoperable, and thus eliminates the ambiguity.  

Architecture of the Device Model

One of the major differences we noticed when implementing both versions is the architecture of the Device Model. OCPP 1.6 uses a flat structure with a simple model of the charger and its connectors. In contrast, OCPP 2.0.1 requires the charger to maintain a hierarchical device model consisting of Station > EVSE > Connector. EVSE stands for electric vehicle supply equipment. A charging station has at least one EVSE, but it may have more. Let’s take a look at some examples of how the implementation could differ for charger firmware.

OCPP 1.6

OCPP 2.0.1

OCPP 2.0.1 allows the CSMS to better inform drivers when a free connector is available because it is able to make the distinction between connectors on independent supplies vs a single supply.  With OCPP 1.6 it was necessary to build this model independently from manufacture information obtained through other channels.  Finding reliable information about specific device models or configurations was not always easy.

Many other aspects of the physical device and its configuration are available from the OCPP 2.0.1 device model.  This includes things like temperature sensors and cooling systems, station lighting, and display capabilities.

You can dive in to how this is implemented in charger firmware with the open-source OpenOCPP project, which is an open source implementation for OCPP 2.0.1 and 1.6.  The hierarchical device model does make the implementation a bit more complex, but the benefits are worth it.

The new device model gives operators deeper insight and granular control - operators can read, write, and monitor every setting with precise structure and metadata. And they can diagnose issues faster, adjust configurations remotely, and manage complex sites more reliably, all with consistent behavior across different charger models and manufacturers.

Other noticeable differences

Offline support

OCPP 1.6 allows defining a “whitelist” of RFID tags that a charger can store locally. The specification has no clear requirement for charger connectivity retry and timeout behaviors, no standardized way to flag partial or corrupted offline data, and no clear fallback behaviors when local lists (like allow lists) become outdated. On the other hand, OCPP 2.0.1 has much richer offline support for local authorization with complex IdToken types, IDs with metadata, more refined local list updates, etc. Therefore, it can expire offline entries, support multiple authorization and Plug-and-charge in offline mode. The newer version also defined clear rules for buffering and upload events upon reconnection.

ISO 15118 plug-and-charge

OCPP 1.6 was designed before ISO 15118 Plug & Charge (PnC) and therefore has no support for contract certificate handling and identity management. On the other hand, OCPP 2.0.1 adds support for Plug & Charge through the 15118 PnC extension profile. The newer version has full certification management, structured identity and IdToken definition, and PnC-specific trigger reasons that can be mapped directly to ISO 15118 steps.

Summary

The above examples clearly illustrate some of the major differences of how the two versions of OCPP handle various functionalities. OCPP 1.6 was released in 2015 and has since been widely implemented across EV chargers and CSMS globally. OCPP 2.0.1 was released in 2020, and adoption is growing, especially for newer charging networks and chargers. However, the adaptation is slower relative to 1.6 because the infrastructure and ecosystem built around 1.6 are very large, and many legacy deployments remain. Complexities around charger firmware and CSMS implementation are a major reason for slow adoption of OCPP 2.0.1: the new version has increased complexity driven by features like the Device Model, mTLS security, and ISO 15118 integration. Companies will need to decide which version of the protocol to adopt based on their needs and what the two versions could provide.