Protocol

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.conf

Supported 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.

Start your testing Book technical demo

What is OCPP 1.6 testing?

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.