OCPP Profile Drift: Why “OCPP-Compatible” Isn’t Enough for CMS Migration

The core of OCPP 1.6J is a small message set: boot notification, heartbeat, authorize, start and stop transaction, status notification, meter values, and a handful of remote commands. The spec defines those messages, and most compliant systems handle them.

The problem is the room the spec leaves, and vendors use it. Implementations extend the protocol with proprietary data types, vendor-specific configuration keys, and boot behaviour that is valid but not identical between products. Two conformant systems can both be correct and still disagree.

That is the mental shift for a migration:

The outgoing CMS learned to live with a charger’s particular extensions. The incoming one has not. Everything below is a place that dialect diverges.

Config keys look settled until you move platforms. Three common offenders:

There is a second trap underneath these: config keys are not uniformly writable. Some are read-only, some write-only, some vendor-locked. A key you assume you can set from the new backend may simply not change. A plan that assumes every relevant key is readable and settable tends to discover the locked ones during cutover rather than before it.

• HeartbeatInterval. The charger and CMS can hold different assumptions about who owns the timing and how a changed interval propagates. A charger heartbeating on a schedule the backend does not expect can read as intermittently offline while being perfectly healthy.
• MinimumStatusDuration. Some vendors extend or reinterpret how long a status must hold before it is reported, which changes what the CMS sees during fast transitions.
• Boot-time authorization cache. Whether a charger trusts a cached token list at startup, and for how long, is not handled identically across firmware families.

On paper the state machine is portable: Available, Preparing, Charging, SuspendedEV, SuspendedEVSE, Finishing, Faulted. The states match. What differs is the moment a transition fires, and that timing is where a CMS builds its assumptions.

Preparing to Charging. Some chargers report Charging when the contactor closes. Others wait until the meter registers real energy flow. A backend tuned to one behaviour can misread the other as a stalled or premature session.

SuspendedEV versus SuspendedEVSE. These two states describe who paused the session, the vehicle or the equipment. In real firmware they are sometimes swapped or applied inconsistently. A CMS that makes billing or fault decisions based on which side suspended the session draws the wrong conclusion when the states arrive reversed.

None of this trips a conformance test, which is exactly why it survives to the migration bench. The state names travel. The timing and semantics behind them do not.

OCPP error codes look standardized until you ask two platforms what they do with one.

When you migrate, the error vocabulary carries over but the interpretation does not. A charger that was “fine” under the old platform’s error handling can start generating field visits under the new one’s. Mapping how the target CMS reacts to each error your fleet actually produces is part of the migration, not an afterthought.

• GroundFailure. One CMS treats it as a transient condition worth a retry. Another flags the whole charger and schedules a truck roll. Same code, very different operational cost.
• OverCurrent. A momentary protective trip, or a sign of real hardware trouble? Platforms weight it differently.
• PowerMeterFailure. May block billing on one system, be logged and tolerated on another.
• InternalError. The catch-all firmware reaches for when nothing else fits. Its meaning depends entirely on the vendor that emitted it.

Before any charger in a wave goes live, we run OCPP conformance testing against the target CMS, per model and per firmware family. Two units of the same model on different firmware can drift from each other, so the test matrix is built around what is actually installed.

A note on tooling. The OCPP Compliance Testing Tool (OCTT) covers a lot: it checks that a system handles the standard message set and follows required behaviour. What it does not fully cover is the interaction between a specific charger’s extensions and a specific backend’s interpretation under real conditions.

That gap is why real-world traffic replay matters: driving the target CMS with the message patterns a charger actually produces, at the volume it produces them, surfaces the disagreements a clean conformance run leaves hidden.

Rent a lab charger of each model you run and put it through this against the target CMS. Keep the results; the migration plan writes itself around what actually passed.

Run it per model. A migration built on what these eight items proved beats one built on what a datasheet promised. If you want this bench pass run against your fleet’s models and firmware, that is part of our EV charger CMS migration process.

• Boot sequence: boots, registers, and reaches Available without manual intervention.
• StatusNotification set: walk every transition; confirm the CMS reads each state and its timing.
• Authorization cache: behaviour at boot with a cached token list, and whether the new platform populates it.
• Remote start/stop: both commands work, and the resulting session records are complete.
• MeterValues sanity: values arrive, at the expected interval, in units the CMS reads correctly.
• Firmware update: the target platform can deliver an update to this model without bricking it.
• Config key list: pull the full list; note which keys are read-only, write-only, or vendor-locked.
• Error reporting: trigger the faults you can safely trigger; record how the CMS classifies each.