OCPP 1.6 Testing
Validate widely deployed OCPP 1.6 charger fleets with virtual charge points, transaction coverage, and repeatable CSMS 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. Teams typically need to validate charger registration, authorization, transaction start and stop flows, meter value reporting, connector status changes, and remote commands before rolling out CSMS changes to real hardware.
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
- CSMS 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 CSMS teams need to validate first.
Charge point -> CSMS: BootNotification.req
CSMS -> Charge point: BootNotification.conf (Accepted, interval=300)
Charge point -> CSMS: Authorize.req
CSMS -> Charge point: Authorize.conf
Charge point -> CSMS: StartTransaction.req
CSMS -> Charge point: StartTransaction.conf (transactionId)
Charge point -> CSMS: MeterValues.req
CSMS -> Charge point: MeterValues.conf
Charge point -> CSMS: StopTransaction.req
CSMS -> 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
CSMS 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 CSMS 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 CSMS without waiting on hardware.