OCPP 1.6 vs 2.0.1: What Really Changed

Why the jump matters

OCPP 1.6 was released in 2015 and became the dominant protocol for EV charging infrastructure worldwide. OCPP 2.0.1, published in 2020, is not an incremental update — it is a ground-up redesign that addresses the structural limitations of 1.6: flat configuration keys, a binary transaction model, weak security primitives, and no native support for smart charging automation.

If you are building a new CSMS integration today, 2.0.1 is the correct target. If you maintain a 1.6 fleet, the information below will tell you exactly what breaks and what stays the same.

Message renames & replacements

The table below maps every message that was renamed, replaced, or split across the two versions. Messages not listed here have the same name and largely the same behaviour in both versions.

Payload-level changes

TransactionEvent replaces StartTransaction + StopTransaction

In OCPP 1.6, a transaction requires two separate messages: StartTransaction at the start of a session and StopTransaction at the end. In OCPP 2.0.1, both are unified into TransactionEvent, which uses an eventType field to signal the lifecycle phase: Started, Updated, or Ended.

BootNotification payload restructured

The flat 1.6 payload becomes a nested structure in 2.0.1. Vendor name max length doubles from 20 to 50 characters. The new reason field is required in 2.0.1. See the BootNotification guide for the full side-by-side comparison.

Authentication & IdToken

One of the most impactful structural changes for RFID-heavy deployments is the evolution of the authorization token.

Configuration → Variables

OCPP 1.6 manages Charge Point settings through flat key-value pairs using GetConfiguration and ChangeConfiguration. OCPP 2.0.1 replaces this with a component/variable hierarchy accessed via GetVariables and SetVariables.

The variable system is more expressive but significantly more verbose. Batch operations are now native — you can get or set multiple variables in a single message — and each variable in a SetVariables response carries its own acceptance status (Accepted, Rejected, NotSupported, etc.).

Security profile

OCPP 1.6 left security largely to the implementer. OCPP 2.0.1 defines three mandatory security profiles, each building on the previous (Open Charge Alliance, 2020):

New in 2.0.1 only

These messages and capabilities have no equivalent in OCPP 1.6:

Migration tips

1. Run both versions in parallel. Most production CSMSes support 1.6 and 2.0.1 simultaneously. Route Charge Points by the OCPP version declared in their WebSocket subprotocol header (ocpp1.6 vs ocpp2.0.1). Migrate hardware incrementally.
2. Map IdTag to IdToken early. Your authorization database stores tokens as strings today. Design the IdToken object wrapper and the type mapping before writing any 2.0.1 transaction code — it touches every Authorize, StartTransaction, and local list operation.
3. Audit your configuration key usage. Build an explicit map of every GetConfiguration / ChangeConfiguration call in your CSMS and find the corresponding 2.0.1 component/variable name. The OCA published a compatibility appendix that covers the most common standard configuration keys.
4. Test BootNotification first. It is the entry point for every session. Validate both the 2.0.1 request payload (nested chargingStation, mandatory reason) and the response handling in the 2.0.1 Validator before touching transactions.
5. Plan for TransactionEvent's seqNo. Every TransactionEvent carries a sequence number. Missed events must be retransmitted in order. Your Charge Point firmware needs a persistent queue if it reconnects mid-transaction.