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 have 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, in 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, the Charging Station Management System or 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, which is a charge point emulator. This is the common case, because integrating against a CSMS, whether writing the backend or building a CPO platform on top of one, is a much larger job market than writing 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 DC fast charger in a car park or from 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.
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 anidToken, and run aTransactionEventfromStartedtoEnded, where 1.6 usesStartTransactionandStopTransactioninstead, then 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 walks the full sequence.
Emulators also come as libraries and CLIs for engineers who want to script sessions in CI. MicroOcpp is an OCPP client written in portable C/C++ for microcontrollers such as the ESP32. Because it is a charge-point-side implementation, with a network stack it doubles as an emulator you can point at a backend. Its 1.6 support is the mature path and its 2.0.1 support is gated behind a build flag rather than on by default, so check the repository for current status. The tradeoff against a browser tool is setup: you gain scriptability and scale, and you pay for it with 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 accepts the connection and returns Accepted to everything, which is enough to confirm your firmware boots and stays online. EVerest, the LF Energy EV-charging stack, ships this kind of permissive responder for smoke tests.
At the high end are full open-source CSMS servers you run locally and inspect:
- SteVe is a Java CSMS that has been in development since 2013, implementing OCPP 1.6 over both SOAP and WebSocket/JSON, including the Security Whitepaper profiles. It is GPL-licensed and does not implement 2.0.1.
- CitrineOS is a TypeScript CSMS built around OCPP 2.0.1 and now an LF Energy project. If certification matters to your procurement, check the Open Charge Alliance certified-products register directly rather than any secondary description, including this one, because that status changes without anyone updating a blog post. Details verified against each repository in August 2026.
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, with a database and configuration to match, which is more than you need if all you want is to confirm your BootNotification payload is well-formed.
There is no single standard open CSMS, and the projects come from different places on both sides of the Atlantic. That is precisely why testing against more than one is worth the effort: each will accept slightly different things, and the intersection of what they all accept is much closer to what real hardware will accept.
A note on “real firmware” tools
One more category muddies the water: full charge-point software stacks such as EVerest, which implement OCPP 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 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 or integrating a backend: charge point emulator. Start with Rey in the browser, and reach for a scriptable client such as MicroOcpp when you need CI or scale.
- Writing charge-point firmware: CSMS simulator. Use a minimal mock for smoke tests, or run SteVe for 1.6 or CitrineOS for 2.0.1 locally when you want 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 ever existed in the vocabulary. The connection itself has always been unambiguous about which end is which, and so should your test setup be.