OCPP 1.6 Testing
Validate widely deployed OCPP 1.6 charger fleets with virtual charge points, transaction coverage, and repeatable CPMS regression testing.
What is OCPP 1.6 testing?
OCPP 1.6 testing focuses on the version still used across a large share of deployed EV chargers. Before shipping CPMS changes to real hardware, teams validate charger registration, authorization, and transaction start and stop flows. They also check meter value reporting, connector status changes, and remote commands.
Supported modules and flows
- BootNotification, Heartbeat, StatusNotification, Authorize, MeterValues, and transaction lifecycle messages.
- Remote operations such as RemoteStartTransaction, RemoteStopTransaction, Reset, and ChangeConfiguration.
- Connector state handling across preparing, charging, suspended, finishing, unavailable, and faulted states.
- JSON-over-WebSocket workflows used by most deployed OCPP 1.6 charger fleets.
Best for
- CPMS teams supporting large installed fleets of legacy and mixed-generation chargers.
- Regression testing after backend changes that affect onboarding, authorization, or transactions.
- Compatibility work where vendor quirks and edge cases need to be reproduced quickly.
Example OCPP 1.6 transaction flow
A typical OCPP 1.6 session starts with charger registration, then moves through authorization, transaction start, periodic meter values, and transaction stop. This is the core path most CPMS teams need to validate first.
Charge point -> CPMS: BootNotification.req
CPMS -> Charge point: BootNotification.conf (Accepted, interval=300)
Charge point -> CPMS: Authorize.req
CPMS -> Charge point: Authorize.conf
Charge point -> CPMS: StartTransaction.req
CPMS -> Charge point: StartTransaction.conf (transactionId)
Charge point -> CPMS: MeterValues.req
CPMS -> Charge point: MeterValues.conf
Charge point -> CPMS: StopTransaction.req
CPMS -> Charge point: StopTransaction.confSupported vendor profiles
Teams typically use OCPP 1.6 testing for the most widely deployed charger families and for backend paths that still rely on classic transaction and status flows.
| Profile | Coverage | Typical validation |
|---|---|---|
| ABB / EVBox / Wallbox | Core OCPP 1.6 transaction and status coverage | Onboarding, status notifications, meter values, and remote commands. |
| Alfen / Tritium / Kempower | Mixed-fleet OCPP 1.6 regression paths | Heartbeat timing, reconnect behavior, session closure, and operational commands. |
| Legacy AC fleet profiles | High-confidence compatibility testing | BootNotification, Authorize, StartTransaction, StopTransaction, and ChangeConfiguration. |
What to test
- BootNotification, heartbeat, and reconnect handling.
- Authorize, StartTransaction, StopTransaction, and MeterValues coverage.
- Connector status transitions such as Available, Preparing, Charging, and Faulted.
- Remote commands like RemoteStartTransaction, RemoteStopTransaction, Reset, and ChangeConfiguration.
Common scenarios
CPMS release regression
Run repeatable charger sessions against your backend before releasing updates that affect onboarding, transactions, or status processing.
Vendor compatibility
Simulate different charger behaviors and edge cases without maintaining a physical lab for every vendor profile.
Load validation
Check how your CPMS handles many concurrent OCPP 1.6 connections, heartbeats, and transaction events under realistic traffic.
Related resources
Start validating OCPP 1.6 flows before production
Launch virtual charge points, reproduce real charger behavior, and test your CPMS without waiting on hardware.