Skip to content
Start testing
Protocol

OCPP 1.6 testing

Validate widely deployed OCPP 1.6 charger fleets with virtual charge points, transaction coverage, and repeatable CSMS regression testing.
Start your testingBook technical demo
The workspace's OCPP 1.6 message log with BootNotification.conf selected, answered Accepted, and the wire frame [3, …, {status: Accepted, interval: 300}].
The workspace's OCPP 1.6 message log with BootNotification.conf selected, answered Accepted, and the wire frame [3, …, {status: Accepted, interval: 300}].

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

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.

Message coverage

All 39 OCPP 1.6 operations by feature profile, each covered by the virtual charger's action catalog. 28 come from the OCPP 1.6 specification and 11 from its security extension.

sent by the charger to the Central System sent by the Central System to the charger sent either way

Core

  • sent by the charger to the Central System: Authorize
  • sent by the charger to the Central System: BootNotification
  • sent by the Central System to the charger: ChangeAvailability
  • sent by the Central System to the charger: ChangeConfiguration
  • sent by the Central System to the charger: ClearCache
  • sent either way: DataTransfer
  • sent by the Central System to the charger: GetConfiguration
  • sent by the charger to the Central System: Heartbeat
  • sent by the charger to the Central System: MeterValues
  • sent by the Central System to the charger: RemoteStartTransaction
  • sent by the Central System to the charger: RemoteStopTransaction
  • sent by the Central System to the charger: Reset
  • sent by the charger to the Central System: StartTransaction
  • sent by the charger to the Central System: StatusNotification
  • sent by the charger to the Central System: StopTransaction
  • sent by the Central System to the charger: UnlockConnector

Firmware management

  • sent by the charger to the Central System: DiagnosticsStatusNotification
  • sent by the charger to the Central System: FirmwareStatusNotification
  • sent by the Central System to the charger: GetDiagnostics
  • sent by the Central System to the charger: UpdateFirmware

Local auth list management

  • sent by the Central System to the charger: GetLocalListVersion
  • sent by the Central System to the charger: SendLocalList

Reservation

  • sent by the Central System to the charger: CancelReservation
  • sent by the Central System to the charger: ReserveNow

Smart charging

  • sent by the Central System to the charger: ClearChargingProfile
  • sent by the Central System to the charger: GetCompositeSchedule
  • sent by the Central System to the charger: SetChargingProfile

Remote trigger

  • sent by the Central System to the charger: TriggerMessage

Security (1.6 security extension)

  • sent by the Central System to the charger: CertificateSigned
  • sent by the Central System to the charger: DeleteCertificate
  • sent by the Central System to the charger: ExtendedTriggerMessage
  • sent by the Central System to the charger: GetInstalledCertificateIds
  • sent by the Central System to the charger: GetLog
  • sent by the Central System to the charger: InstallCertificate
  • sent by the charger to the Central System: LogStatusNotification
  • sent by the charger to the Central System: SecurityEventNotification
  • sent by the charger to the Central System: SignCertificate
  • sent by the charger to the Central System: SignedFirmwareStatusNotification
  • sent by the Central System to the charger: SignedUpdateFirmware

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.

  1. Boot

    1. Charge point → CSMS

      BootNotification.req

    2. CSMS → Charge point · response

      BootNotification.conf

      (Accepted, interval=300)

  2. Authorize

    1. Charge point → CSMS

      Authorize.req

    2. CSMS → Charge point · response

      Authorize.conf

  3. Transaction

    1. Charge point → CSMS

      StartTransaction.req

    2. CSMS → Charge point · response

      StartTransaction.conf

      (transactionId)

  4. Meter values

    1. Charge point → CSMS

      MeterValues.req

    2. CSMS → Charge point · response

      MeterValues.conf

  5. Stop

    1. Charge point → CSMS

      StopTransaction.req

    2. CSMS → Charge point · response

      StopTransaction.conf

Raw frames
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

What the workspace asserts

The states and enum values an OCPP 1.6 frame is validated against, taken from the OCA OCPP 1.6 JSON schemas.

ChargePointStatusStatusNotification.req status

  1. Available
  2. Preparing
  3. Charging
  4. Finishing

    back to Available

Chargingto and fromSuspendedEVSuspendedEVSE

AlsoReservedUnavailableFaulted

Each change arrives as a StatusNotification.req for one connector; connector 0 reports the whole charge point.

  • RegistrationStatus

    Field
    BootNotification.conf status
    Values
    AcceptedPendingRejected

  • AuthorizationStatus

    Field
    IdTagInfo status
    Values
    AcceptedBlockedExpiredInvalidConcurrentTx

  • Reason

    Field
    StopTransaction.req reason
    Values
    EmergencyStopEVDisconnectedHardResetLocalOtherPowerLossRebootRemoteSoftResetUnlockCommandDeAuthorized

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

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