Skip to content
Start testing
Protocol

OCPP 2.0.1 testing

Validate modern OCPP 2.0.1 workflows for smart charging, security, device management, and richer transaction handling before rolling them into production fleets.
Start your testingBook technical demo
The workspace's OCPP 2.0.1 message log: one transaction as TransactionEventRequest Started, Updated, Ended with seqNo 0, 1, 2; the Updated frame is open with triggerReason MeterValuePeriodic and chargingState Charging.
The workspace's OCPP 2.0.1 message log: one transaction as TransactionEventRequest Started, Updated, Ended with seqNo 0, 1, 2; the Updated frame is open with triggerReason MeterValuePeriodic and chargingState Charging.

What is OCPP 2.0.1 testing?

OCPP 2.0.1 testing covers the newer version of the protocol used for advanced charger and CSMS capabilities. Teams validate TransactionEvent handling, charging profiles, and device model behavior. They also check security-profile requirements and the broader message set introduced in OCPP 2.0.1.

Last reviewed

Best for

  • Teams onboarding newer charger models with stronger security and smart charging requirements.
  • Platforms preparing for ISO 15118-adjacent and advanced energy-management workflows.
  • Mixed-fleet backends that need to support both OCPP 1.6 and OCPP 2.0.1 cleanly.

Message coverage

All 64 OCPP 2.0.1 operations by functional block, each covered by the virtual charger's action catalog.

sent by the charger to the CSMS sent by the CSMS to the charger sent either way

Security

  • sent by the CSMS to the charger: CertificateSigned
  • sent by the CSMS to the charger: CustomerInformation
  • sent by the CSMS to the charger: DeleteCertificate
  • sent by the CSMS to the charger: GetInstalledCertificateIds
  • sent by the CSMS to the charger: InstallCertificate
  • sent by the charger to the CSMS: NotifyCustomerInformation
  • sent by the charger to the CSMS: SecurityEventNotification
  • sent by the charger to the CSMS: SignCertificate

Provisioning

  • sent by the charger to the CSMS: BootNotification
  • sent by the CSMS to the charger: GetBaseReport
  • sent by the CSMS to the charger: GetReport
  • sent by the CSMS to the charger: GetVariables
  • sent by the charger to the CSMS: Heartbeat
  • sent by the charger to the CSMS: NotifyReport
  • sent by the CSMS to the charger: Reset
  • sent by the CSMS to the charger: SetNetworkProfile
  • sent by the CSMS to the charger: SetVariables

Authorization

  • sent by the charger to the CSMS: Authorize

Local authorization list

  • sent by the CSMS to the charger: ClearCache
  • sent by the CSMS to the charger: GetLocalListVersion
  • sent by the CSMS to the charger: SendLocalList

Transactions

  • sent by the CSMS to the charger: GetTransactionStatus
  • sent by the charger to the CSMS: TransactionEvent

Remote control

  • sent by the CSMS to the charger: RequestStartTransaction
  • sent by the CSMS to the charger: RequestStopTransaction
  • sent by the CSMS to the charger: TriggerMessage
  • sent by the CSMS to the charger: UnlockConnector

Availability

  • sent by the CSMS to the charger: ChangeAvailability
  • sent by the charger to the CSMS: StatusNotification

Reservation

  • sent by the CSMS to the charger: CancelReservation
  • sent by the charger to the CSMS: ReservationStatusUpdate
  • sent by the CSMS to the charger: ReserveNow

Tariff and cost

  • sent by the CSMS to the charger: CostUpdated

Metering

  • sent by the charger to the CSMS: MeterValues

Smart charging

  • sent by the CSMS to the charger: ClearChargingProfile
  • sent by the charger to the CSMS: ClearedChargingLimit
  • sent by the CSMS to the charger: GetChargingProfiles
  • sent by the CSMS to the charger: GetCompositeSchedule
  • sent by the charger to the CSMS: NotifyChargingLimit
  • sent by the charger to the CSMS: NotifyEVChargingNeeds
  • sent by the charger to the CSMS: NotifyEVChargingSchedule
  • sent by the charger to the CSMS: ReportChargingProfiles
  • sent by the CSMS to the charger: SetChargingProfile

Firmware management

  • sent by the charger to the CSMS: FirmwareStatusNotification
  • sent by the CSMS to the charger: PublishFirmware
  • sent by the charger to the CSMS: PublishFirmwareStatusNotification
  • sent by the CSMS to the charger: UnpublishFirmware
  • sent by the CSMS to the charger: UpdateFirmware

ISO 15118 certificate management

  • sent by the charger to the CSMS: Get15118EVCertificate
  • sent by the charger to the CSMS: GetCertificateStatus

Diagnostics

  • sent by the CSMS to the charger: ClearVariableMonitoring
  • sent by the CSMS to the charger: GetLog
  • sent by the CSMS to the charger: GetMonitoringReport
  • sent by the charger to the CSMS: LogStatusNotification
  • sent by the charger to the CSMS: NotifyEvent
  • sent by the charger to the CSMS: NotifyMonitoringReport
  • sent by the CSMS to the charger: SetMonitoringBase
  • sent by the CSMS to the charger: SetMonitoringLevel
  • sent by the CSMS to the charger: SetVariableMonitoring

Display message

  • sent by the CSMS to the charger: ClearDisplayMessage
  • sent by the CSMS to the charger: GetDisplayMessages
  • sent by the charger to the CSMS: NotifyDisplayMessages
  • sent by the CSMS to the charger: SetDisplayMessage

Data transfer

  • sent either way: DataTransfer

Example OCPP 2.0.1 transaction flow

OCPP 2.0.1 replaces the older start and stop model with TransactionEvent messages. That gives teams a richer, event-driven sequence to validate across the full session lifecycle.

  1. Boot

    1. Charge point → CSMS

      BootNotificationRequest

    2. CSMS → Charge point · response

      BootNotificationResponse

  2. Authorize

    1. Charge point → CSMS

      AuthorizeRequest

    2. CSMS → Charge point · response

      AuthorizeResponse

  3. Transaction started

    1. Charge point → CSMS

      TransactionEventRequest

      (eventType=Started, seqNo=0)

    2. CSMS → Charge point · response

      TransactionEventResponse

  4. Transaction updated

    1. Charge point → CSMS

      TransactionEventRequest

      (eventType=Updated, seqNo=1, triggerReason=MeterValuePeriodic, chargingState=Charging)

    2. CSMS → Charge point · response

      TransactionEventResponse

  5. Transaction ended

    1. Charge point → CSMS

      TransactionEventRequest

      (eventType=Ended, seqNo=2)

    2. CSMS → Charge point · response

      TransactionEventResponse

Raw frames
Charge point -> CSMS: BootNotificationRequest
CSMS -> Charge point: BootNotificationResponse

Charge point -> CSMS: AuthorizeRequest
CSMS -> Charge point: AuthorizeResponse

Charge point -> CSMS: TransactionEventRequest (eventType=Started, seqNo=0)
CSMS -> Charge point: TransactionEventResponse

Charge point -> CSMS: TransactionEventRequest (eventType=Updated, seqNo=1, triggerReason=MeterValuePeriodic, chargingState=Charging)
CSMS -> Charge point: TransactionEventResponse

Charge point -> CSMS: TransactionEventRequest (eventType=Ended, seqNo=2)
CSMS -> Charge point: TransactionEventResponse

What the workspace asserts

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

TransactionEventEnumTypeTransactionEventRequest eventType

  1. Started
  2. Updated
  3. Ended
One transaction, one transactionId: seqNo counts up on every TransactionEventRequest, and Updated repeats as often as the station reports.

  • ConnectorStatusEnumType

    Field
    StatusNotificationRequest connectorStatus
    Values
    AvailableOccupiedReservedUnavailableFaulted

  • ChargingStateEnumType

    Field
    TransactionEventRequest transactionInfo.chargingState
    Values
    ChargingEVConnectedSuspendedEVSuspendedEVSEIdle

  • RegistrationStatusEnumType

    Field
    BootNotificationResponse status
    Values
    AcceptedPendingRejected

  • AuthorizationStatusEnumType

    Field
    AuthorizeResponse idTokenInfo.status
    Values
    AcceptedBlockedConcurrentTxExpiredInvalidNoCreditNotAllowedTypeEVSENotAtThisLocationNotAtThisTimeUnknown

Supported modern charger workflows

OCPP 2.0.1 testing is most useful when teams need stronger security, smarter charging control, and richer event-driven backend validation across newer charger profiles.

  • Smart charging profiles

    Coverage
    ChargingProfiles, scheduling, and power-management coverage
    Typical validation
    Validate schedule handling, composite logic, and backend decisioning.

  • Security-oriented deployments

    Coverage
    Profile 1, 2, and 3 validation paths
    Typical validation
    TLS, certificates, authentication, and higher-assurance charger onboarding.

  • Mixed modern DC and AC fleets

    Coverage
    TransactionEvent and device-model workflows
    Typical validation
    Exercise started, updated, ended events and variable-oriented management behavior.

What to test

  • TransactionEvent lifecycle coverage for started, updated, and ended events.
  • Smart charging and charging profile validation.
  • Device management, variables, and capability-related message flows.
  • Security-profile and authentication-related workflows.

Common scenarios

Smart charging rollout

Validate charging profile logic, scheduling behavior, and backend decisioning before enabling advanced energy management in production.

Mixed-version backend support

Test OCPP 2.0.1 alongside legacy OCPP 1.6 fleets so your CSMS handles both versions cleanly.

Protocol migration

Exercise 2.0.1 message handling before onboarding new charger models or expanding into higher-security deployments.

Related resources

Test OCPP 2.0.1 workflows before they hit real chargers

Simulate modern charger behavior, validate smart charging logic, and de-risk OCPP 2.0.1 backend changes.

Start your testingBook technical demo