What should OCPP testing prove?

OCPP testing should prove three things. Conformance testing checks whether an implementation follows the specification. Interoperability testing checks whether a particular charger and CPMS work together. Project acceptance testing checks whether the finished setup does what the operator needs.

 

A successful WebSocket connection is a start. Nothing more. It does not prove that authorisation, transactions, remote commands, security, offline operation or smart charging work correctly.

Define the exact system under test

Freeze the configuration before testing. Record the charger model, firmware, CPMS release, OCPP version, security profile, endpoint, network route and enabled functions. Agree optional OCPP features instead of assuming them.

 

Use production-like credentials and certificate rules without exposing live secrets. Keep the configuration and logs with the results, so later firmware or CPMS releases can be tested against the same baseline.

Run OCPP conformance tests

The Open Charge Alliance Compliance Test Tool (OCTT) runs predefined conformance tests for OCPP 1.6 and OCPP 2.0.1 charging stations, software stacks and management systems. When it tests a charger, OCTT acts as the management system, and vice versa.

 

OCTT can expose message, validation and sequence errors. It is not a general charger or CPMS simulator, and an internal run does not produce an independent OCPP certificate. Formal OCPP certification uses official tests through an approved laboratory.

Test the real charger and CPMS together

Connect the charger, firmware and CPMS release chosen for the project. Capture charger and backend logs so timing, retries and rejected requests can be traced from both sides.

 

OCPP Plugfests let implementations test against several partners. The deployment still needs its own bilateral test because configuration, optional functions and operating rules differ.

How this applies to amina charging stations

amina’s OCPP documentation says implemented features are checked with OCTT, internal automation, field testing and regression tests. The CSMS integration guide covers production provisioning of the endpoint, certificates and charger identity. Confirm that the selected CSMS accepts the serial number, the endpoint and certificates are correct, and the charger reaches its connected state. Read live configuration values, especially when an order has customer-specific provisioning.

Test complete charging and operating scenarios

Build tests around real operations, not isolated messages. At minimum, cover:

  • boot, heartbeat, time synchronisation and status changes;
  • local and remote authorisation, including rejected credentials;
  • session start, meter values, final energy totals and CPMS records;
  • remote start, stop, reset, connector release and configuration changes where supported;
  • firmware and diagnostic-log workflows where required;
  • smart-charging profiles, limits and schedule changes where required;
  • maximum-current settings, authorisation defaults and offline rules against the ordered configuration;
  • multiple connectors or EVSEs, where applicable; and
  • reboot and recovery during an active or interrupted session.

Test security, connectivity and failure behaviour

Repeat key tests with a wrong password, an untrusted or expired certificate, an incorrect clock and a broken network connection. Test CPMS outages, reconnects, queued messages, duplicate events and unexpected message order.

 

Confirm what the charger may do offline, how long it retains data, which local authorisation rules apply and what happens at storage or retry limits. The amina authentication guide lists the settings and defaults to test. Recovery should not lose or duplicate billable session data.

Test CPMS performance at representative scale

One charger cannot prove fleet capacity. Use simulated chargers for concurrent connections, bursts of meter values and commands, and mass reconnection after an outage. Monitor response time, WebSocket stability, queues, database load and alerts against the planned fleet size.

Set acceptance criteria before rollout

Each test needs an expected result, evidence, severity and owner. Decide which failures block deployment and which documented limits are acceptable. Retest fixes and run a controlled site pilot before wider rollout.

 

The handover should record tested versions, supported functions, credential and certificate ownership, logs, known exceptions, offline rules and rollback. Repeat the critical tests after changes to firmware, CPMS releases, security settings or network design.