Happy-path tests confirm that normal charging sessions work. They do not tell you what happens when the network drops mid-transaction, a connector develops a fault, a driver's card is blocked, or the station gets an emergency stop while billing is in progress. These are the scenarios that cause real production incidents — and they are nearly impossible to reproduce reliably with physical hardware. A simulator built for negative testing is the practical solution.

Network disconnect and reconnect

Real chargers lose connectivity. The WebSocket closes, the CSMS session enters limbo, and the charger must reconnect and recover. Testing this correctly means verifying that your CSMS:

With SimIt you can disconnect a station's WebSocket at any point — before boot, during an active transaction, immediately after StartTransaction — and reconnect it after a configurable delay. The CSMS sees an authentic connection drop and reconnect, not a test stub.

Power loss simulation

A power loss is more disruptive than a clean disconnect: all active transactions on all connectors are lost simultaneously. Your CSMS must handle the station going offline mid-session, with no StopTransaction sent, and then recover when the station reboots and sends BootNotification.

SimIt's power loss endpoint stops all active transactions with Reason.PowerLoss and immediately drops the WebSocket. This gives your CSMS an authentic unclean shutdown to handle.

Error and fault injection

Every standard OCPP error code — GroundFailure, HighTemperature, OverCurrentFailure, EVCommunicationError, ReaderFailure, and the rest — represents a scenario your CSMS error-handling logic must cover. Testing each one means being able to put a connector into a specific faulted state on demand.

SimIt lets you set any connector to any error code via a REST call. Set the fault, verify your CSMS triggers the correct alert or billing pause, reset the fault, verify the connector returns to Available. Run this for each error code in your CI pipeline.

Emergency stop

An emergency stop ends a transaction immediately with Reason.EmergencyStop — no graceful session close, no final MeterValues, just a hard stop. Your CSMS must handle this without orphaning the transaction or corrupting billing records. It is one of the few scenarios where the normal stop flow does not apply, and the edge cases in your StopTransaction handler will surface here.

Authorization edge cases

Authorization failures are a class of invalid scenario in their own right. Testing them requires being able to control what the CSMS returns for a given idTag and verifying the station and CSMS both behave correctly:

Local-initiated transactions

Most CSMS test suites cover RemoteStartTransaction — the CSMS tells the charger to begin a session. But a large share of real-world sessions start locally: a driver taps an RFID card and the charger initiates the transaction itself. The CSMS receives a StartTransaction with Reason.Local and must handle it without having sent a RemoteStart first.

SimIt's transaction/start endpoint initiates a local session on any connector. Your CSMS must accept the StartTransaction, authorize the idTag, and track the session as normal — without the prior RemoteStart it might implicitly expect.

RemoteStart before the EV arrives

In OCPP 1.6 §5.12, a CSMS can send RemoteStartTransaction before a vehicle is physically connected. The charger moves to Preparing and holds the pending start until an EV plugs in. If no EV arrives within the ConnectionTimeOut interval, the charger reverts to Available and the session is abandoned.

With SimIt you can send RemoteStart from your CSMS, then deliberately delay connecting the virtual EV — or never connect it — to test both the successful late-arrival path and the ConnectionTimeOut expiry path. Both scenarios exercise CSMS state management that is invisible in happy-path tests.

Create a free SimIt account and start building a negative test suite for your CSMS today.