Pourquoi « conforme OCPP » ne signifie pas interopérable

An operator buys chargers from three vendors, because procurement found a better price on the second tranche and a third supplier could deliver faster. All three are OCPP 1.6J certified. On paper, the depot is standardized.

Then the details start to surface. MeterValues arrive at different intervals with different measurand sets. One vendor resets the transaction ID after a reboot, so sessions get double-counted. Load management that works perfectly on vendor A silently under-delivers on vendor B. Nobody notices until a truck leaves the yard at 40% state of charge and the dispatcher has to re-plan the route mid-shift.

This is not a story about bad hardware. It is a story about the gap between conformance and interoperability. A certificate says a charger can complete a defined set of message exchanges in a lab. It does not say the charger will behave the same way as the unit parked next to it, under real load, on a congested network, with three charging profiles stacked on top of each other.

This article is a field guide to where OCPP leaves room for interpretation, what breaks as a result, and how to test for it during commissioning instead of discovering it in production.

What certification actually proves

Third-party certification validates a snapshot: a specific firmware build, against a specific test suite, in a controlled environment. Three things limit how much that snapshot is worth in the field.

Optional features stay optional. Large parts of OCPP are conditional. A charger can be fully certified while implementing only a subset of smart charging functionality. Certification tells you the implemented parts work. It does not tell you which parts exist.

Firmware moves faster than audits. By the time a unit is installed, it has usually shipped several firmware revisions past the version that was certified. Regressions in smart charging behavior are common and rarely documented in release notes.

Compliance is a two-sided problem. The backend can be just as loose with the spec as the charger. When both sides are approximately compliant in different directions, troubleshooting becomes an argument rather than a diagnosis. If you are still building your baseline understanding of the protocol, our guide to setting up and troubleshooting OCPP chargers covers the fundamentals this article builds on.

One correction to a common assumption: Chinese manufacturers are not systematically worse than European or North American ones. Across our own testing, incomplete smart charging implementations show up at every price point and in every region, including from well-known Tier 1 OEMs.

Where implementations diverge

These are the failure modes we see most often in multi-vendor depots. Handling them is the job of your OCPP-compliant charging software and the OCPP server underneath it — not something you can fix in procurement alone.

Partial smart charging profile support

The most frequent gap. Many chargers implement TxProfile and TxDefaultProfile but not ChargingStationMaxProfile (or ChargePointMaxProfile in 1.6). Session-level limits work; site-level limits do not. As a rough rule of thumb, expect roughly half of the smart charging surface to be missing on any given unit until you have proven otherwise.

Profile stacking and priority handling

OCPP defines how profiles at different stack levels combine and which one wins. Firmware frequently gets this wrong: it applies the most recently received profile instead of the highest-priority one, ignores stack levels entirely, or drops a lower-level profile when a higher one expires. In a depot running a baseline site limit plus dynamic per-session limits, this is the difference between a controlled ramp and a breaker trip.

Silent acceptance

The failure mode that costs the most time. A CSMS sends SetChargingProfile. The charger replies Accepted. The internal controller then ignores the limit, rounds the setpoint to arbitrary steps, or fails to apply it because the value was expressed in watts rather than amps. From the backend's point of view everything succeeded. From the transformer's point of view nothing did.

Scope mismatch

ChargingStationMaxProfile requires connectorId = 0 (or evseId = 0) to express a station-wide limit. Flawed firmware accepts the same profile on connectorId = 1 — and then applies the entire station limit to that single connector while leaving the others uncapped. The result is one throttled vehicle and an unbounded site load.

MeterValues configuration drift

Sampled interval, aligned interval, and the configured measurand set vary by vendor and often reset after a firmware update. If your energy management logic assumes a 30-second Power.Active.Import sample and one vendor delivers 300-second Energy.Active.Import.Register only, your control loop is running on stale data and your billing records are inconsistent.

Reconnect and transaction state after network loss

What happens when the WebSocket drops mid-session is where implementations diverge hardest. Some chargers resume the transaction with the same ID and buffered meter values. Some start a new transaction. Some reset the transaction counter after a reboot and collide with IDs already in the backend. Some resume charging at full power, discarding the profile that was active before the disconnect.

ChangeConfiguration key support variance

Vendors support different key sets, use different names for equivalent behavior, and return Accepted for keys they do not implement. Configuration you believe you have pushed to a fleet may exist on only part of it. Normalizing this is what our hardware configuration for OCPP chargers tooling exists to do — one configuration intent, translated per model and verified by read-back rather than trusted on the response code.

Security gaps

Outdated TLS versions, expired or self-signed certificates, and plaintext fallbacks are still common. In a multi-tenant hub, that means session and identification data can be captured on the local network. Security is rarely part of the interoperability conversation and should be.

The OCPP 2.0.1 and 2.1 complexity gap

OCPP 1.6J quality has improved measurably year over year. OCPP 2.0.1 has not caught up, and 2.1 raises the bar again.

Where 1.6 asked a charger to handle a modest message set, 2.0.1 introduces a hierarchical device model and well over 60 message types. OCPP 2.1 extends that further with bidirectional charging and V2X, dynamic tariff structures, and richer smart charging semantics. Every added abstraction is another place for firmware to diverge.

Expect a learning period comparable to the one 1.6J went through. Treat any OCPP 2.0.1 or 2.1 claim as a starting point for testing, not as a specification you can build a commissioning schedule around.

Regulatory timelines and firmware maturity

AFIR in Europe and NEVI in the United States both require open, smart-capable infrastructure with real-time data transparency, and both attach deadlines to it. The direction is right, and the industry is broadly moving with it. It also means a lot of protocol development is happening against fixed dates rather than on a schedule set by the engineering work.

Certification against a deadline is a narrower target than robustness across every deployment scenario. Conformance suites test defined message exchanges under controlled conditions. A depot with 40 trucks, a 1.2 MW grid connection, and setpoints that move every few minutes exercises paths those suites were never designed to reach. Firmware can satisfy the first and still surprise you in the second — not because anyone cut corners, but because the validation environment and the operating environment are genuinely different problems.

For a buyer the practical implication is the same either way: treat regulatory compliance and field reliability as two separate questions, and verify the second yourself.

What this costs the site owner

Commissioning delays. The most common consequence. Software go-live slips while you wait on a vendor firmware fix, which can take days or weeks — and sometimes arrives with a new regression.

Features you paid for but cannot use. Load management and energy management depend on chargers actually honoring setpoints. If a unit does not react to commands, or follows a profile intermittently, peak shaving and depot scheduling degrade to static allocation. The economics of the site change with it.

Multi-week troubleshooting. Root cause is rarely obvious. Time goes into proving where the fault sits, then into convincing the responsible party that it is theirs. Both halves are slow.

Normalizing behavior instead of assuming compliance

Certifications and audits cannot solve this, because firmware and software versions change constantly. The durable fix is architectural: critical systems — EMS, energy management, payment — must be built on the assumption that OCPP will not be followed.

In practice that means the backend:

• Verifies effect, not acknowledgement. After sending a profile, confirm the delivered power actually moved by reading meter values, and re-issue or fall back if it did not.
• Maintains a per-model behavior profile: which profile types are supported, which units the charger honors, how it behaves on reconnect, which configuration keys are real.
• Degrades safely. If a charger cannot be trusted to hold a limit, its headroom must be reserved statically so one non-compliant unit cannot consume the whole site's margin.
• Keeps the operator informed fast, so escalation happens in hours rather than after a missed departure.

Two side effects follow. Sites stay stable in spite of imperfect hardware, and OEMs get concrete, reproducible evidence of where their firmware diverges, which is the only pressure that reliably moves the standard forward.

Catching a rejected — or silently ignored — profile

Detection has to be automatic, because the failure is invisible by design. Hardware diagnostics watches command-to-effect: profile sent, setpoint expected, power actually delivered, deviation flagged. Charger logging and audit preserves the full message trace, so when you open a ticket you send the OEM a timestamped exchange showing Accepted followed by no change in delivered power — not a description of a problem.

That distinction matters more than it sounds. Automated escalation with a reproducible log turns a three-week argument into a bug report.

Testing before you accept the site

Do this at commissioning, on every model and every firmware version, not on a sample.

1. Site-level limit. Send ChargingStationMaxProfile at evseId/connectorId = 0. Confirm the aggregate site load drops and that the limit is not misapplied to a single connector.
2. Stacking. Apply a site profile plus a session profile at different stack levels. Verify the correct one governs, and that behavior is correct when the higher-priority profile expires.
3. Units. Test the same limit expressed in amps and in watts. Confirm the charger honors both, or document which one it actually implements.
4. Granularity. Step the setpoint down in small increments and record what the charger delivers. Note the real rounding behavior and the minimum enforceable step.
5. Network loss. Drop the connection mid-session for 30 seconds, five minutes, and 30 minutes. Check transaction ID continuity, buffered meter values, and whether the active profile survives the reconnect.
6. Reboot. Power-cycle mid-session. Look specifically for transaction ID resets and lost profiles.
7. Configuration read-back. Push configuration keys, then read them back. Do not trust Accepted.
8. MeterValues. Verify interval and measurand set against what your EMS requires — then verify again after any firmware update.
9. Security. Confirm TLS version and certificate validity on every unit.

Our charger commissioning support service runs this sequence as part of site acceptance, and the guide to commissioning and testing EV charging hubs walks through the wider process it sits inside.

Get the procurement terms right

L'interopérabilité coûte moins cher à acquérir qu'à déboguer.

• Intégrez le comportement OCPP dans vos SLA, assortis de pénalités financières en cas de défaillances spécifiques et vérifiables — types de profils non pris en charge, acceptation silencieuse, erreurs de périmètre — tant pour les fabricants de matériel que pour les fournisseurs de logiciels.
• Ne considérez pas la certification tierce comme une preuve. Un certificat de type DEKRA est un minimum, et un minimum très bas. Demandez des références clients exploitant des dépôts comparables et interrogez-les sur les problèmes rencontrés.
• Demandez qui détient les mises à jour du firmware et comment le code est déployé en production. Un fournisseur sans processus de publication réel, sans environnement de staging et sans suite de tests de régression introduira des régressions sur votre site. Cette question permet de mieux prédire la qualité sur le terrain que n'importe quelle fiche technique.
• Exigez des modèles pré-testés dans la mesure du possible. Partir d'une liste de bornes de recharge testées avec Ampcontrol élimine toute une catégorie de mauvaises surprises, et nos conseils sur le choix des bornes pour une flotte mixte expliquent comment mettre cela en balance avec le prix et les délais de livraison.

Ce que nous avons appris de 45 marques

Ampcontrol a testé plus de 45 marques de bornes de recharge et environ 100 modèles. Deux conclusions s'imposent systématiquement.

La qualité de l'OCPP 1.6J s'améliore réellement d'année en année. La prise en charge de la recharge intelligente est plus étendue et plus fiable qu'il y a trois ans, et les lacunes les plus critiques se sont réduites.

L'OCPP 2.0.1 en est là où l'OCPP 1.6J se situait il y a quelques années pour la plupart des fabricants, et la version 2.1 prolongera cette courbe. Prévoyez une période d'apprentissage.

La leçon pratique reste inchangée. « Conforme OCPP » est un point de départ pour une discussion, pas une garantie d'interopérabilité. Testez lors de la mise en service, exigez des SLA comportementaux et utilisez un backend qui anticipe les défaillances du protocole pour maintenir le site opérationnel quoi qu'il arrive.

Vous planifiez un dépôt multi-fournisseurs ou vous essayez de déboguer une installation qui ne fournit pas la gestion de charge spécifiée ? Contactez l'équipe Ampcontrol.

‍