Skip to content
Protocol

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. Before shipping CSMS 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.

Last reviewed

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

  • ABB / EVBox / Wallbox

    Coverage
    Core OCPP 1.6 transaction and status coverage
    Typical validation
    Onboarding, status notifications, meter values, and remote commands.

  • Alfen / Tritium / Kempower

    Coverage
    Mixed-fleet OCPP 1.6 regression paths
    Typical validation
    Heartbeat timing, reconnect behavior, session closure, and operational commands.

  • Legacy AC fleet profiles

    Coverage
    High-confidence compatibility testing
    Typical validation
    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

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.

Start your testingBook technical demo