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. But OCPP 2.0.1 is the present and future: new hardware ships with 2.0.1 support, and serious 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. Here 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 concept of an EVSE — Electric Vehicle Supply Equipment, the physical charging point that may have one or more connectors — does not exist at the protocol level. This mismatch caused inconsistencies in deployments where chargers had multiple connectors per outlet.
OCPP 2.0.1 introduces a three-level hierarchy: ChargingStation → EVSE → Connector. Status, transactions, and availability are all tracked at the EVSE level. This matches how real hardware works and eliminates a class of ambiguity that plagued 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 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, not optional extensions.
What this means for CSMS testing
If your CSMS supports both OCPP 1.6 and 2.0.1 — which most production systems must — you need to test 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.
SimIt 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 — no configuration change required beyond that.
Create a free SimIt account and test your CSMS against both OCPP versions today.