Skip to content
Use case

CSMS testing without hardware

Point virtual chargers on OCPP 1.6, 2.0.1 and 2.1 at your Charging Station Management System and run one test run across all three. Each check shows the answer your CSMS sent, and a CALLERROR lands on its own row with the frame and the error code.
Animated example of a CSMS test run in OCPPLab: virtual chargers connect to your CSMS at wss://csms.example.com/ocpp and checks resolve one by one, including BootNotification Accepted, StatusNotification and MeterValues answered with an empty CALLRESULT, and SetChargingProfile with an invalid schedule, which the charger answers Rejected as the check expects. One check fails on its own row: the CSMS answered a valid OCPP 2.0.1 TransactionEvent with a CALLERROR ProtocolError. Example run, not a captured result.

Why hardware labs stall CSMS releases

Building a CSMS means testing against dozens of charger vendors, each with their own OCPP implementation quirks. A physical test lab is costly to set up, takes weeks to configure, and covers only a handful of scenarios at a time.

  • Every physical charger is a hardware purchase
  • Lab setup can take weeks for each vendor
  • A bench tests only a few charge points at once
  • No way to simulate peak load or failure scenarios
  • Bug fixes require physical access to test hardware

What a virtual fleet covers

OCPPLab simulates vendor-style charge point behavior. Run virtual charger checks, test important edge cases, and make QA workflows repeatable.

  • Vendor-style device profiles for ABB, EVBox, Wallbox, Alfen and other vendors
  • Run OCPP 1.6, 2.0.1 and 2.1 chargers against your CSMS in one test run
  • Simulate firmware updates, network failures, and concurrent sessions
  • Reusable workflows cover common OCPP requirements
  • Run release checks with automation API access

What you can test

BootNotification handling

BootNotification ⇄ Accepted

Validate how your CSMS registers and configures new charge points from each vendor-style profile.

Transaction management

TransactionEvent (2.x) · StartTransaction / StopTransaction (1.6)

Test StartTransaction and StopTransaction on OCPP 1.6, TransactionEvent on OCPP 2.0.1 and 2.1, and MeterValues with realistic charging patterns.

Smart charging

SetChargingProfile ⇄ Accepted (1.6 · 2.0.1 · 2.1)

Validate charging profiles, power limits, and grid integration with SetChargingProfile on OCPP 1.6, 2.0.1, and 2.1.

Firmware management

UpdateFirmware → FirmwareStatusNotification Installed

Test firmware update workflows including download, install, and rollback scenarios.

Authorization

Authorize ⇄ Accepted

Validate RFID, remote start, and certificate-oriented OCPP 2.0.1 authorization paths.

Error recovery

reconnect → BootNotification

Simulate network drops, timeout scenarios, and charge point reboot sequences.

What is CSMS testing?

CSMS (Charging Station Management System) testing validates that your charging platform correctly handles OCPP communication with charge points at scale. That means testing BootNotification registration, transactions, meter values, smart charging profiles, firmware updates, and error recovery. Without virtual testing tools like OCPPLab, teams rely on physical hardware labs that are costly to build and test only a handful of charge points at once. OCPPLab lets teams simulate virtual charge points across vendor-style profiles. Run repeatable workflow suites and add checks to release pipelines.

Test your CSMS against virtual chargers

No hardware needed. Start with a virtual charge point and expand into repeatable release checks.

Start your testingBook technical demo

Last updated: