Charge Point Emulator vs CSMS Simulator: Which Do You Need?

If you have shopped for OCPP testing tools, you have hit the terminology fog: “charge point emulator,” “virtual charge point,” “CSMS simulator,” “OCPP simulator,” “mock backend.” People use these words loosely and often interchangeably, which is exactly why nobody can tell you which one to download. This article cuts through it. The distinction that actually matters is simple, and once you see it you will always know which tool to reach for.

Here it is: a charge point emulator fakes the charger; a CSMS simulator fakes the backend. They stand in for opposite ends of the same OCPP connection. Everything else is detail.

If you just want the hands-on version, Rey is a free, browser-based charge point emulator — it opens a real OCPP connection (1.6, 2.0.1, or 2.1) to a CSMS and lets you drive a full session. More on where it fits below.

One connection, two roles

Every OCPP session has exactly two parties, and they are not symmetric. If you need a refresher on the protocol itself, what OCPP is covers the basics; here is the part that decides your tooling.

The charge point (the charging station) is the WebSocket client. It dials out. It opens a connection to a URL like wss://csms.example.com/ocpp/CP-0001, and it drives the conversation: it sends BootNotification, StatusNotification, Authorize, TransactionEvent, MeterValues, Heartbeat.

The CSMS (Charging Station Management System — the backend) is the WebSocket server. It listens, accepts connections, answers those requests, and occasionally initiates its own commands back down the pipe: RequestStartTransaction, Reset, TriggerMessage, GetVariables.

Because the two ends play fixed, opposite roles, a testing tool has to pick a side. That is the whole taxonomy:

• A tool that plays the charger so you can test a backend is a charge point emulator — also marketed as a “virtual charge point” or, confusingly, an “OCPP simulator.”
• A tool that plays the backend so you can test firmware is a CSMS simulator — also called a “mock CSMS” or “OCPP server simulator.”

Same protocol, mirror-image jobs. The question “emulator or simulator?” is really the question “which side am I building, and which side do I need to fake?”

The rule: fake the side you are not building

That reframing gives you a one-line decision rule. Whatever you are building is real; you fake the other end.

Building or integrating a CSMS? Your backend is the thing under test. You do not have thirty different physical chargers on your desk, and you should not need them. You need something that behaves like a charger and connects to your backend — a charge point emulator. This is by far the most common case, because far more people integrate against a CSMS (writing the backend, or building a CPO platform on top of one) than write charger firmware.

Writing charge-point firmware? Your firmware is the thing under test. It needs something to connect to — a server that accepts the WebSocket and answers. You need a CSMS simulator.

Learning the protocol, building neither yet? You do not need to fake anything live. You want to watch a correct session play out. A canned, passive walkthrough is the right first step — the interactive OCPP simulator replays a full message flow so you can learn the sequence before you connect anything real.

That is the entire decision. Everything below is about picking a good tool once you know your side.

Charge point emulators (for testing a CSMS)

An emulator’s job is to be indistinguishable, on the wire, from real firmware. Your CSMS cannot tell whether the bytes on the socket came from a €4,000 DC fast charger or a browser tab — as long as the messages are well-formed and arrive in a plausible order, it processes them identically. That is why software testing works, and it is covered in depth in how to test an OCPP charge point without hardware ^{(coming soon)}.

This is where Rey fits. Rey is a free, browser-based virtual charge point. It has two modes:

• Connect my CSMS — enter your backend’s wss:// URL, a station id, and a Basic-auth password if it needs one, and Rey opens a real OCPP connection to your CSMS in whichever version you pick. In 2.0.1 you boot it, authorize an idToken, and run a TransactionEvent from Started to Ended (1.6 uses StartTransaction/StopTransaction instead) — and watch exactly how your backend responds. A relay handles the auth headers a browser cannot set on a WebSocket itself.
• Explore — drive the station against a built-in demo CSMS with zero setup, if you just want to see a live session without wiring up a backend.

Because it runs entirely in the browser, there is nothing to install and nothing to provision. You point it at a backend and go. Every message is shown as its real OCPP-J array, so you can lift frames straight out as test fixtures. If you want to understand what those frames mean end to end, the OCPP charging-session message flow ^{(coming soon)} walks the full sequence.

Emulators also come as libraries and CLIs for engineers who want to script sessions in CI. MicroOcpp (maintained by matth-x) is an OCPP 1.6 / 2.0.1 client written in portable C/C++ for microcontrollers such as the ESP32 — it is a charge-point-side implementation, so with a network stack it doubles as an emulator you can point at a backend. (Its 2.0.1 support is still marked alpha and off by default.) The tradeoff versus a browser tool is setup: you get scriptability and scale in exchange for a build step.

CSMS simulators (for testing firmware)

If you are on the firmware side, you need a backend to talk to, and your options span a wide range of fidelity.

At the low end, a minimal mock CSMS just accepts the connection and returns Accepted to everything — enough to check that your firmware boots and stays online. EVerest, the LF Energy EV-charging stack, ships exactly this kind of “friendly” responder for smoke tests.

At the high end are full open-source CSMS servers you run locally and inspect:

• SteVe — a Java CSMS in continuous development since 2013, implementing OCPP 1.6 (over both SOAP and WebSocket/JSON) with the full Security Whitepaper profile set. Originating out of RWTH Aachen in Germany, it is GPL-licensed and one of the most widely deployed open backends for 1.6.
• CitrineOS — a newer, TypeScript CSMS created by the North American company S44 and contributed to LF Energy. It launched in 2023 as an OCPP 2.0.1 backend (OCA-certified for Core and Advanced Security) and added OCPP 1.6 support in its 1.6.0 release in April 2025.

Running a real CSMS locally is the honest way to test firmware, because it answers like a production backend rather than rubber-stamping everything. The cost is that you are now operating a full server — database, config, the works — which is more than you need if all you want is to confirm your BootNotification payload is well-formed.

Note the geography here is genuinely mixed: SteVe and EVerest have European roots (Aachen and Pionix), while CitrineOS comes out of North America — all four are open source and used on both continents. There is no single “standard” CSMS, which is precisely why testing against more than one is worth the effort.

A note on “real firmware” tools

One more category muddies the water: full charge-point software stacks like EVerest, which implement OCPP 1.6, 2.0.1, and 2.1 alongside ISO 15118 and IEC 61851. EVerest is not an emulator — it is production firmware meant to run on actual charging hardware. But because it is a charge-point-side stack, you can run it against a CSMS simulator to test the backend integration.

The lesson is the same taxonomy applied one level up: EVerest sits on the client side of the wire, so pairing it with a CSMS simulator tests the pair, while pairing your own backend with a charge point emulator like Rey tests yours. Always ask which side of the connection a tool stands on.

The decision in one screen

• Building a CSMS / integrating a backend → charge point emulator. Start with Rey in the browser; reach for a scriptable client like MicroOcpp when you need CI or scale.
• Writing charge-point firmware → CSMS simulator. Use a minimal mock for smoke tests, or run SteVe (1.6) or CitrineOS (2.0.1 and 1.6) locally for real answers.
• Just learning → neither yet. Watch a full session in the passive OCPP simulator first, then come back and pick your side.

Get the side right and the tool follows. The confusion only exists because the words got blurry — the connection never did.