Testing OCPI and OCPP connectivity

OCPP: charger to CPMS

OCPP conformance testing should cover the full session lifecycle, not just the happy path. A minimum sequence:

1. Boot and handshake. BootNotification is accepted, and the charger correctly applies any configuration pushed in response.
2. Authorization. Both remote-start and card/tag-present flows succeed, including a deliberately invalid tag to confirm rejection is handled cleanly.
3. Transaction lifecycle. StartTransaction, MeterValues at the configured interval, and StopTransaction all report consistent, non-zero energy figures that reconcile with a physical meter reading.
4. Fault handling. Simulate a connector fault mid-session and confirm the charger reports StatusNotification correctly and the CPMS reacts (alerting, session termination) rather than showing a stale "charging" state.
5. Connectivity loss. Disconnect backhaul mid-session, confirm offline authorization/local behaviour, then reconnect and confirm the CPMS reconciles the session rather than losing it.
6. Firmware and configuration push. Confirm a remote configuration change and firmware update both complete without corrupting session state on unrelated connectors.

Test against the specific OCPP version the CPMS speaks (1.6J and 2.0.1 are not interchangeable in practice) and log raw message exchanges during testing — a passed test with no message log is not reproducible when a fault reappears in production months later.

OCPI: CPO to EMSP roaming

OCPI testing needs to be validated from both directions of the roaming relationship:

• Location and status sync. Confirm the EMSP's view of site availability matches the CPO's actual real-time status, including after a connector goes offline — sync lag here is a leading cause of driver complaints on roamed sessions.
• Tariff propagation. Confirm the price shown to a roaming driver before starting a session matches what is actually billed, including time-of-use and idle fee components.
• CDR (Charge Detail Record) accuracy. Reconcile a sample of CDRs against the CPO's own metering data before going live with a new roaming partner — mismatches here become billing disputes.
• Session commands. Remote start/stop initiated by the EMSP correctly reaches the physical charger and reflects real state, not just an acknowledgement at the API layer.

A note on "conformant" claims

Passing an automated conformance test suite is necessary but not sufficient. It validates message structure and sequencing; it does not validate that a charger behaves correctly under the connectivity and load conditions of a specific deployment. Site-level testing after conformance testing is not redundant — it is the step that actually determines whether a charger will hold up in production.