OCPP integration testing is the engineering stage where a new charger model is connected to a test CSMS — a charge station management system — and run through the full message lifecycle before it is released: boot and registration, authorization, a complete transaction with meter values, status and fault reporting, remote commands, and recovery after a dropped connection. It is how a manufacturer proves a model implements OCPP, rather than simply listing it.
Key Takeaways
- Integration testing validates a charger model’s OCPP behaviour against a test CSMS before release.
- The sequence covers registration, authorization, a full transaction, remote commands and offline recovery.
- Keep the traces and session records: they are the evidence behind an “OCPP compliant” claim.
- Buyers who source hardware should ask which platforms a model was tested against — in writing.
Integration Testing Is Not Commissioning
Commissioning happens on site, with a model that is already proven: an installer points the station at the operator’s live platform, runs one test session, and hands the site over. Integration testing happens earlier, during development and pre-production, and its subject is the model itself. A sound model can still be commissioned badly at one site — but a model that never passed integration testing will fail the same way at every site it ships to.
The Test Sequence
A disciplined run works through the conversation between charger and CSMS in the order a real session produces it:
- Connect and register. The charger boots, identifies itself to the CSMS, and holds the connection with heartbeats at the agreed interval.
- Authorize both ways. A valid credential starts a session; an invalid one is rejected cleanly, and both outcomes are visible in the platform.
- Run a full transaction. Start, meter values flowing during the session, stop — and a complete, consistent transaction record at the end.
- Report status and faults. Plug events, errors and availability changes reach the CSMS as they happen, not at the next heartbeat.
- Take remote commands. Remote start and stop, reset, configuration changes and a firmware update offer are acknowledged and carried out.
- Break the connection. Drop the network mid-session, restore it, and confirm the session record survives and the offline behaviour matches the specification.
What Passing Looks Like — and What to Keep
| Test area | Passing behaviour | Evidence to file |
|---|---|---|
| Connection and boot | Charger registers, stays registered, reconnects without flooding the platform | Message trace and CSMS log |
| Authorization | Valid and invalid credentials handled correctly | Test case results |
| Transaction lifecycle | Complete start-to-stop record with plausible meter values | Exported session record |
| Remote operations | Commands executed and confirmed back to the CSMS | Message trace |
| Offline and recovery | Sessions stored during an outage and forwarded afterwards | Disconnect-test notes |
| Firmware and configuration | Update applied and the new version reported | Version record, before and after |
The Faults It Catches Before Your Customers Do
The failures integration testing exists to find are unglamorous: a message field formatted in a way one CSMS accepts and another rejects, meter values in the wrong unit, clock and timezone errors that scramble session records, and reconnect loops that hammer a platform every time a site router restarts. Each one is cheap to fix at a test bench. The same fault found after launch means a firmware campaign across an installed fleet — and a platform operator who stops specifying your model.
If You Source Models Instead of Building Them
A brand that buys its hardware can still demand this evidence. Ask the factory which CSMS platforms the model was integration-tested against, and ask for the test summary before the first order. EVDANCE’s two platform models state OCPP 1.6J in their listings: the EV-AC03201T dual-connector AC station and the EV-RHDC30K-L compact DC charger. Treat the pairing with your own platform as a written confirmation before a rollout depends on it — via the OEM and private-label program or by contacting the team with your platform details.
Frequently Asked Questions
Is integration testing the same as commissioning a charger on site?
No. Commissioning points a proven model at one operator’s live platform and proves that site works. Integration testing proves the model itself speaks OCPP correctly, message by message, before any site depends on it.
Who should run it — the charger maker or the platform?
The maker’s engineering team runs the model against a test CSMS during development. Before a rollout, the pairing is then confirmed with the specific platform the operator will run, because two correct implementations can still disagree on details.
Does passing integration testing make a charger OCPP certified?
No. It produces pairing and behaviour evidence from testing. Certification is a separate, formal route under the protocol alliance’s program — a different claim, with different paperwork.
Related Reading
- OCPP Explained: What Charge Point Operators Need From EV Charger Hardware
- Smart Charging and Time-of-Use Tariffs: How Scheduling Cuts EV Charging Costs
- How an OEM EV Charger Project Works, Step by Step
- OEM and Private-Label EV Chargers: A Complete Guide for Brands
