OCPP Interoperability Testing Services

Coverage

• Boot, registration and configuration exchange
• Heartbeat, connection loss and reconnection behaviour
• Full transaction lifecycle, including concurrent and interrupted sessions
• Meter values: units, contexts, intervals and billing usability
• Remote start, stop, reset and unlock, verified at the charger rather than at the protocol layer
• Firmware management, including status reporting through to completion
• Availability, reservation and smart charging profiles where in scope
• Failure recovery: charger restart, platform restart, clock divergence

Negative and interrupted cases

The tests that matter are the ones where something goes wrong mid-sequence. Pull the network during an active transaction. Restart the charger with a session open. Send a command the charger will refuse. What each side does next is the behaviour that determines whether a deployed fleet is billable.

Evidence

Each case produces a recorded message exchange, retained against the firmware and platform versions tested. That evidence is what lets a later dispute be settled by reading rather than by argument, and what makes a regression run meaningful after either side releases.

For procurement

A vendor claim of OCPP support is a starting position. Testing against your intended platform, before award rather than after deployment, converts that claim into something you can rely on. This is the same work run earlier in the commercial process.

What it does not do

Interoperability testing is not certification, and it does not assert conformance on behalf of any body. It reports observed behaviour between two specific implementations at specific versions, which is a narrower and more useful claim.

What interoperability testing is really for

Compliance testing asks whether an implementation follows the specification. Interoperability testing asks whether two specific systems work together. Passing the first tells you very little about the second, and buyers routinely assume otherwise.

We have seen a charger sold as OCPP compliant fail to work with the platform its owner had already committed to. The gap was not non-compliance. It was that compliance and interoperability are different questions, and only one of them had been asked.

• Which platform, at which release, not which OCPP version
• The message set your operation actually depends on, including the ones that only matter when something goes wrong
• Behaviour on reconnect, on a lost backend and on a partially completed transaction, because that is where implementations diverge
• Firmware update over the air, tested end to end, since it is the mechanism you will need when anything else turns out to be wrong

How we work with you on this

Test results are only useful if the people who have to act on them understand what was tested and what was not. So the test plan is agreed with your team before anything runs, and the findings come with what we did not cover.

We will also tell you when testing is not the right spend. If the answer is already visible from the architecture, a test programme confirms it expensively.

The two situations this is for

Almost every engagement here is one of two cases, and both are about a specific pairing rather than about compliance in the abstract.

1. 1

   Testing someone else's charger against your platform

   You are considering hardware from a vendor you have not used, or you have already bought it. The question is whether it actually works with the management system you run, at the release you run, doing the things your operation depends on.

2. 2

   Changing platform, and retesting what you own

   You are moving to a different CMS. Every charger in the fleet now faces a backend it has never spoken to, and the units that will misbehave are not predictable from their datasheets. Retesting before the migration is far cheaper than discovering it during one.

Both are answered the same way: against the named platform and release, with the message set that matters to you, including the failure paths.

How we work with you

The checklist is built jointly before anything runs, and it is the artefact the whole engagement hangs on.

1. 1

   We draft it against your operation

   What your fleet does, what your platform does, and which behaviours would actually hurt if they failed. A generic conformance list tests things no site depends on and misses the ones that matter.

2. 2

   You add to it

   Your engineers know the cases that have bitten you before. Those go in, and they are frequently the most valuable items on the list.

3. 3

   We run it, every time

   The same checklist across every unit and every platform in scope, so results are comparable rather than anecdotal.

4. 4

   You keep it

   The checklist is yours afterwards. It becomes your acceptance test for the next vendor and the next migration, which is worth more than any single test report.