What a CSMS does
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 are allowed to charge, what to bill you, or how much current it is safe to draw right now given the other six chargers on the same circuit.
Somebody has to answer those questions. That somebody is a Charging Station Management System — a CSMS. Flowion is one.
The parties involved#
| Party | What it is |
|---|---|
| Driver | Turns up with a car and an RFID card or an app. |
| Charging station | The hardware. Delivers energy, 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 mean the same role.
Why there is a protocol at all#
A charger manufacturer and a CSMS vendor are usually different companies. If every manufacturer invented its own way of saying "someone plugged in", an operator could never mix hardware brands in one fleet — and mixed fleets are the normal case, because chargers get bought over years as sites expand.
OCPP — the Open Charge Point Protocol, published by the Open Charge Alliance — is the agreement that makes a mixed fleet possible. A station that speaks OCPP can be managed by any CSMS that speaks OCPP.
That is the whole reason your integration looks the way it does. Flowion does not invent the vocabulary you will read about in these pages; it implements a published specification, and where the specification is awkward, the awkwardness usually shows through.
What a CSMS is actually responsible for#
Authorization. A driver presents a card. The station does not know whether that card is valid, so it asks. The CSMS answers yes or no, and the station only then closes the contactor. A station may cache recent answers so it can keep working when the network is down — but the CSMS owns the truth.
Transactions. Every charging session is recorded: who started it, when, on which connector, how much energy flowed, why it stopped. This record is what billing, reporting and dispute resolution are built on. The station reports the events; the CSMS is what remembers them.
Telemetry and status. Stations report connector status changes (available, preparing, charging, faulted) and periodic meter readings. Between them these tell you whether a site is healthy and what it is doing right now.
Control. The CSMS can tell a station to do things: start or stop a session remotely, unlock a stuck cable, take a connector out of service, reboot, change a setting. These behave differently from an ordinary API call, for reasons the next page explains.
Load management. A site has one grid connection with a fixed capacity. Ten chargers each capable of 22 kW cannot all draw 22 kW at once. Somebody must decide, continuously, how to divide what is available. That is the CSMS.
Provisioning. New station arrives on site, is powered on, connects, and announces itself. The CSMS decides whether it is a station it recognises and is willing to accept.
What a CSMS is not#
It is not the thing a driver interacts with. Apps, maps, roaming between networks, payment and pricing are a layer above, usually run by an e-Mobility Service Provider (eMSP) and connected to operators through a different protocol entirely (OCPI). OCPP stops at the boundary between the operator and their own hardware.
It is also not a real-time control system in the safety sense. OCPP is a management protocol over a possibly-flaky internet connection. The station is responsible for its own safety interlocks and keeps working — within limits it already knows — when the CSMS is unreachable.
The one structural fact worth internalising now#
The station connects to you, not the other way round.
Chargers live behind NAT on mobile or site networks, with no stable inbound address. So the station opens a long-lived connection outward to the CSMS and holds it open, and everything in both directions travels over that one connection.
This has consequences that will follow you through the whole integration:
- You cannot send a station a command unless it is currently connected.
- "Send a command" means writing into a socket the station opened and waiting for it to answer, so it can time out even when nothing is broken.
- A station that has just rebooted, lost signal, or had its connection reaped by a mobile carrier is simply absent until it dials back in.
OCPP in ten minutes explains the mechanics. If you would rather see the whole thing end to end first, read Lifecycle of a charging session.