OCPP Simulator

Why OCPP simulation matters

Testing EV charging infrastructure against real hardware is expensive and slow. Charge points, CSMS back-ends, and energy management systems need to exchange OCPP 1.6 messages reliably before deployment, but integration bugs typically surface only when a physical EVSE meets a production CSMS.

SPX closes that gap by simulating both sides of the OCPP conversation. Teams can validate boot notifications, authorize flows, meter values, and charging profiles against controllable digital twins instead of waiting on hardware lockstep.

Integration problem

EVSE and CSMS need to interoperate before deployment

Charge points and central systems must agree on OCPP message format, timing, and state transitions long before field installation.

Energy problem

Metering and telemetry must match real hardware behavior

Meter values, energy registers, and charging session data need to behave like real EVSE telemetry for energy management and billing validation.

Network problem

WebSocket connectivity and reconnect behavior is hard to test

OCPP runs over WebSocket, and connection drops, reconnect storms, and message ordering issues are difficult to reproduce against physical devices.

SPX approach

Simulate both sides of OCPP in one runtime

SPX can act as a Charge Point, a Central System, or both, giving teams full control over OCPP 1.6 behavior for integration and regression testing.

What SPX simulates

SPX provides OCPP 1.6J adapters that can run as a Charge Point (role: charge_point) or as a Central System (role: central_system). Both roles map OCPP messages onto SPX attributes, so you can inspect, steer, and validate behavior through one runtime.

Charge Point role

EVSE / Charge Point simulator

Boot notifications, status notifications, authorize requests, start/stop transactions, meter values, and heartbeat flows from the EVSE side.

Central System role

CSMS control simulator

Run a Central System that accepts WebSocket connections from charge points, handles boot notifications, and sends remote start/stop or profile requests.

Metering

Realistic meter values and energy registers

Meter values, energy imports, power readings, and charging session telemetry are part of the twin behavior, not random stubs.

Connectivity

WebSocket connection and reconnect scenarios

Trigger connection drops, reconnect sequences, and message timing issues to harden CSMS and EVSE logic against real-world network behavior.

Core capabilities

OCPP simulation in SPX goes beyond protocol shells. The twins expose full device behavior so energy, e-mobility, and charging management teams can test end-to-end flows.

Both roles

Charge Point and Central System in one platform

Run an EVSE twin and a CSMS twin in the same runtime, or connect a real CSMS to a simulated charge point and vice versa.

Runtime control

Start, stop, and steer charging sessions at runtime

Change connector status, trigger transactions, inject meter values, and control charging profiles while the twin is running.

Scenarios

Reproducible fault and reconnect scenarios

Script connection drops, authorization failures, metering anomalies, and abnormal state transitions as repeatable test cases.

Observability

Inspect OCPP messages and twin state in real time

See WebSocket frames, OCPP message payloads, attribute changes, and session lifecycle from one runtime view.

Example models

SPX ships with ready-to-run OCPP models in the Energy Pack. These models connect to real or simulated CSMS back-ends and expose realistic EVSE behavior.

EVSE