What a CSMS does
Every charger needs a server that decides, records and instructs. See what that server is responsible for, and how Flowion does each job for you.
On this page
An EV charger is a computer bolted to a wall in a car park. It has a power contactor, a card reader, maybe a screen, and a network connection. What it does not have is any idea who you are, whether you may charge, what the session should cost, or how much current it can draw right now given the other six chargers on the same circuit.
A server answers those questions: the Charging Station Management System, or CSMS. Flowion is one, and it is built as an energy platform around it: the same place that runs your chargers also knows your circuits, your energy monitors and the price of electricity.
Who is involved
| Party | What it is |
|---|---|
| Driver | Turns up with a car and an RFID card or an app. |
| Charging station | The hardware. Delivers energy and reports what it sees. |
| CSMS | The server the station talks to. Decides, records, instructs. |
| Charging Station Operator (CSO) | The business running the fleet. Often called a CPO. |
The specification's own term for the operator is CSO; the industry usually says CPO (Charge Point Operator). They are the same role, and if you run chargers on Flowion, it is you.
One open standard, any charger
Charger makers and CSMS vendors are usually different companies, and fleets are almost always mixed: chargers get bought over years as sites grow. What makes that work is OCPP, the Open Charge Point Protocol, published by the Open Charge Alliance. A charger that speaks OCPP can be run by any CSMS that speaks it.
Flowion speaks all three versions in the field, so you never have to. Your own code talks to Flowion over a REST API and webhooks, in terms of chargers, sessions and sites. The protocol stays on Flowion's side of the line.
What a CSMS is responsible for
Authorization. A driver presents a card. The station does not know whether that card is valid, so it asks, and only closes the contactor once the CSMS says yes. Stations can cache answers to keep working through a network outage, but the CSMS owns the truth. In Flowion you decide who may charge (open to everyone, or private to the people you name) and Flowion answers every request, and keeps each charger's offline behaviour in line with that choice.
Sessions. Every charge is recorded: who started it, when, on which outlet, how much energy flowed and why it stopped. Billing, reporting and disputes are built on this record. Flowion keeps it as an event log with the meter readings attached, the same shape for every charger.
Status and telemetry. Stations report each outlet's state (available, charging, faulted) and periodic meter readings. Flowion turns these into current status, history and live events you can subscribe to.
Control. The CSMS can tell a station to start or stop a session, release a stuck cable, go out of service, restart or change a setting. Flowion turns each of these into a tracked command you can retry safely, and holds it until the charger is reachable.
Load management. A site has one grid connection with a fixed capacity. Ten chargers that can each draw 22 kW cannot all draw it at once, so something has to decide, continuously, how to share what is available. Flowion does this from a model of your circuits and, where you have one, a live energy monitor.
Provisioning. A new charger is powered on, connects and introduces itself. Flowion checks that it is a charger you added, reads what it is, configures it for its make and model, and only then lets it serve drivers.
Where OCPP stops
OCPP covers one relationship: an operator and their own hardware. Roaming between networks is a separate protocol (OCPI), and it is not part of the picture here.
OCPP is also a management protocol, not a safety system. Each charger enforces its own electrical interlocks and keeps working within limits it already knows when the network drops. Flowion keeps a site within the limits you give it; the breaker is still the last protection.
The station calls the server
The station connects to the CSMS, never the other way round. Chargers sit behind NAT on mobile or site networks with no reachable address, so each one opens a long-lived connection outward and holds it. Everything in both directions travels over that one connection.
That is why a CSMS has to be always on, and why Flowion does the work around it for you:
It runs the endpoint every charger dials, at
ocpp.flowion.io, and holds each connection open.It records whether each charger is online and when it was last heard from, so a charger that drops off a mobile network is visible at once.
It queues a command for a charger that is offline and delivers it when the charger dials back in, until the command's expiry.
OCPP in ten minutes shows the mechanics. To see the whole thing end to end first, read Lifecycle of a charging session.