OCPP 1.6 remains the most widely deployed version of the protocol. Most chargers in the field today speak 1.6, and most CSMS systems were built against it. OCPP 2.0.1 is where things are heading: new hardware ships with 2.0.1 support, and established CSMS vendors are either already supporting it or actively adding it.

If you are building or testing a CSMS, you will need to support both. What follows is what changed and why it matters.

The device model: connectors become EVSEs

The most significant change in 2.0.1 is the device model. In OCPP 1.6, a charging station has connectors numbered from 1. The EVSE (Electric Vehicle Supply Equipment, the physical charging point that may have one or more connectors) does not exist at the protocol level. That mismatch caused inconsistencies in deployments where chargers had multiple connectors per outlet.

OCPP 2.0.1 introduces a three-level hierarchy: ChargingStation, then EVSE, then Connector. Status, transactions, and availability are all tracked at the EVSE level. This matches how real hardware works and removes a class of ambiguity that caused trouble in 1.6 deployments.

Transaction messages

In OCPP 1.6, a charging session involves three separate messages: StartTransaction, MeterValues, and StopTransaction. Each carries a subset of session data, and the CSMS must correlate them using transaction IDs.

OCPP 2.0.1 replaces all three with a single message: TransactionEvent. It carries an event type (Started, Updated, or Ended), the transaction ID, current meter data, and trigger reason in one unified structure. Session tracking on the CSMS side becomes considerably simpler.

Security

OCPP 1.6 has no built-in security model. Most deployments use a shared secret in the WebSocket URL or an HTTP Basic Auth header, both of which are fragile and difficult to rotate at scale.

OCPP 2.0.1 defines a formal security framework with three profiles: HTTP Basic Auth over TLS (Profile 1), CSMS-managed client certificates (Profile 2), and full mutual TLS (Profile 3). These are part of the core specification rather than optional extensions.

What this means for CSMS testing

Most production systems have to support both OCPP 1.6 and 2.0.1, which means testing both. The transaction lifecycle, device model, and authorization flows differ enough that a bug in one version will not necessarily surface when testing the other.

SimItNow supports both versions natively. You can run the same test scenario against your CSMS in either protocol version by specifying the version on station create, with no other configuration change.

Create a free SimItNow account and test your CSMS against both OCPP versions.