System CSMS: czym jest i jak jest zbudowany?

Ładowarka samochodu elektrycznego wygląda z zewnątrz jak „gniazdko z prądem”. W rzeczywistości to urządzenie sieciowe, sterowane zdalnie, podłączone do infrastruktury energetycznej i do systemów płatności. Tym, co spina to wszystko w działającą, bezpieczną i rozliczalną usługę, jest CSMS — Charging Station Management System.

W tym artykule wyjaśniamy, czym jest CSMS, jak zbudowana jest jego architektura, jakie standardy komunikacji go łączą (OCPP, OCPI, ISO 15118) i — co najważniejsze — dlaczego bezpieczeństwo nie jest tu dodatkiem, tylko fundamentem projektu. Jeśli wolisz zobaczyć całość na jednym rysunku, przygotowaliśmy diagram architektury EV24® CSMS.

Czym jest CSMS?

CSMS (Charging Station Management System), nazywany też CPMS (Charge Point Management System), to backend, który zarządza siecią stacji ładowania. To on:

• łączy się z ładowarkami i utrzymuje z nimi stałą komunikację,
• monitoruje ich status w czasie rzeczywistym,
• uruchamia i kończy sesje ładowania,
• zarządza mocą, taryfami i dostępem,
• zbiera dane pomiarowe (CDR — Charge Detail Record),
• obsługuje płatności, rozliczenia i faktury,
• udostępnia dane operatorom, kierowcom, mapom i partnerom roamingowym.

Innymi słowy: ładowarka to „mięsień”, a CSMS to „układ nerwowy” całej sieci. Bez niego masz zbiór niezależnych urządzeń; z nim masz usługę ładowania, którą da się skalować, rozliczać i kontrolować.

Warto tu rozróżnić trzy role, które często się mylą. CPO (Charge Point Operator) to operator, który fizycznie prowadzi stacje i odpowiada za ich działanie. eMSP (e-Mobility Service Provider) to dostawca usługi dla kierowcy — aplikacja, konto, płatność. CSMS to system informatyczny, który obsługuje operacje CPO i wymienia dane z eMSP. Jeden podmiot może pełnić kilka ról naraz, ale w architekturze warto je rozdzielać, bo mają różne wymagania i różne dane.

Dlaczego CSMS to infrastruktura krytyczna, a nie „zwykły software”

Zanim przejdziemy do architektury, warto ustawić właściwy sposób myślenia. CSMS działa na styku trzech światów, z których każdy ma wysokie wymagania:

1. Energetyka — sterujesz urządzeniami, które pobierają realną moc z sieci. Błąd lub przejęcie kontroli to nie „wyciek danych”, to fizyczne skutki: zablokowana stacja, przeciążenie przyłącza, przerwana sesja na trasie.
2. Płatności — przez system przechodzą transakcje, dane kart, terminale. Obowiązują standardy branżowe i regulacje.
3. Prawo i zgodność — AFIR, ustawa o elektromobilności, RODO, a coraz częściej wymogi cyberbezpieczeństwa (np. NIS2 dla podmiotów kluczowych).

Dlatego dobry CSMS projektuje się jak system czasu rzeczywistego o wysokiej dostępności, z bezpieczeństwem wbudowanym od pierwszej linijki, a nie doklejonym na końcu.

Architektura wysokopoziomowa

Architekturę CSMS najłatwiej opisać jako cztery warstwy, od lewej do prawej:

1. Infrastruktura ładowania — stacje AC, stacje DC, ładowarki mobilne, kontrolery i liczniki w lokalizacjach.
2. Rdzeń CSMS — zbiór mikroserwisów, które przyjmują komunikację, prowadzą sesje, liczą i publikują zdarzenia.
3. Moduły biznesowe — smart charging, billing i taryfy, roaming, analityka.
4. Odbiorcy — aplikacja kierowcy, panel operatora, publiczne API i integracje.

Kluczowa zasada: warstwy są luźno powiązane i komunikują się zdarzeniami, a nie sztywnymi, bezpośrednimi wywołaniami. Dzięki temu każdą część można rozwijać, skalować i zabezpieczać niezależnie — i awaria jednego elementu nie kładzie całości.

Warstwa 1: infrastruktura i jej różnorodność

Stacje różnią się mocą (AC vs DC), łącznością (eSIM, SIM, WiFi, LTE) i wersją protokołu. W jednej sieci naturalnie współistnieją ładowarki OCPP 1.6J, 2.0.1 i 2.1, a obok nich kontrolery i liczniki energii komunikujące się np. przez Modbus. Zadaniem CSMS jest ujednolicić tę różnorodność — tak, aby reszta systemu nie musiała wiedzieć, jaki dokładnie sprzęt stoi w terenie.

Warstwa 2: rdzeń mikroserwisowy

Rdzeń to nie jeden „wielki program”, tylko zestaw wyspecjalizowanych serwisów. W EV24 wyglądają one tak:

• OCPP Gateway — utrzymuje połączenia WebSocket ze stacjami, tłumaczy komendy między wersjami OCPP i izoluje „brudny” świat urządzeń od reszty systemu. To jedyny komponent, który rozmawia bezpośrednio ze sprzętem.
• Session Service — obsługuje start, stop i przebieg sesji oraz generuje CDR (dokument szczegółów ładowania), który jest podstawą rozliczeń.
• Chargers Registry — rejestr stacji, EVSE i konektorów oraz ich konfiguracji, statusów i możliwości.
• Event Bus & Streams — magistrala zdarzeń i telemetrii w czasie rzeczywistym, która spina wszystkie serwisy i pozwala im reagować bez sztywnych zależności.

Nad tym pracują moduły biznesowe: Smart Charging (load balancing, DLM), Billing i taryfy, Roaming (OCPI) oraz Analityka.

Warstwa 3 i 4: moduły biznesowe i odbiorcy

Moduły biznesowe zamieniają surowe zdarzenia w wartość: naliczają koszty, równoważą moc między punktami, wymieniają dane z innymi operatorami i liczą wskaźniki. Odbiorcy — aplikacja kierowcy, panel operatora, publiczne API i integracje — konsumują te dane. Ważne, że odbiorcy nigdy nie sięgają bezpośrednio do urządzeń: zawsze przez rdzeń, co jest istotne również z punktu widzenia bezpieczeństwa.

Standardy, które spinają CSMS

Architektura jest tak dobra, jak standardy, na których stoi. To one decydują o interoperacyjności i o tym, czy nie wpadasz w vendor lock-in.

OCPP — język między ładowarką a systemem

OCPP (Open Charge Point Protocol) to otwarty standard komunikacji między stacją a CSMS. W praktyce spotkasz trzy wersje:

Dobry CSMS obsługuje wszystkie trzy wersje jednocześnie, bo park maszynowy w terenie jest mieszany. Nie da się z dnia na dzień wymienić wszystkich ładowarek — dlatego bramka OCPP musi mówić każdym z tych „dialektów” i tłumaczyć je na wspólny, wewnętrzny model. Więcej o samym protokole i różnicach piszemy w artykule Open Charge Point Protocol (OCPP).

OCPI — roaming między operatorami

OCPI (Open Charge Point Interface), najczęściej w wersji 2.2.1, to standard roamingu — pozwala, aby kierowca jednego dostawcy usług (eMSP) mógł naładować się na stacji innego operatora (CPO), z prawidłowym rozliczeniem między stronami. OCPI dzieli się na moduły, z których każdy odpowiada za inny fragment wymiany danych:

Dzięki OCPI Twoja sieć jest widoczna i użyteczna szerzej niż tylko we własnej aplikacji — a to bezpośrednio przekłada się na obłożenie stacji.

ISO 15118 — Plug & Charge

ISO 15118 (Plug & Charge) to bezpieczna, oparta na certyfikatach autoryzacja „wtyczką”: kierowca podłącza kabel, a uwierzytelnienie i rozliczenie dzieją się automatycznie, bez aplikacji i kart. Pod spodem działa infrastruktura klucza publicznego (PKI): pojazd i stacja wymieniają i weryfikują certyfikaty, a cała transmisja jest szyfrowana. To wygoda dla kierowcy i wyższy poziom bezpieczeństwa — ale wymaga od CSMS obsługi zarządzania certyfikatami po stronie stacji.

Modbus, liczniki i płatności

Na poziomie lokalizacji dochodzą jeszcze liczniki energii i kontrolery, często komunikujące się przez Modbus (pomiar zużycia, sterowanie mocą). Oraz płatności: terminale (np. Payter, PAX), płatność z telefonu, BLIK i karty. CSMS musi te światy spiąć, ale — co ważne — trzymać je w osobnych, dobrze odseparowanych domenach.

Bezpieczeństwo — fundament, nie dodatek

To najważniejsza część tego artykułu. W CSMS bezpieczeństwo trzeba rozpatrywać na kilku poziomach naraz, bo atakujący nie wybiera „ładnej” drogi — wybiera najsłabsze ogniwo.

1. Bezpieczeństwo warstwy OCPP

To najbardziej newralgiczny kanał: to nim wysyłasz do urządzenia komendy „start”, „stop”, zmiany konfiguracji czy aktualizacje. Standard OCPP 2.0.1 definiuje profile bezpieczeństwa, które warto znać:

Kierunek jest jasny: docelowo Profil 3 (mTLS), gdzie stacja i CSMS potwierdzają swoją tożsamość nawzajem, a połączenie zawsze idzie przez TLS (WSS), nigdy „gołym” WebSocketem. Do tego dochodzi zarządzanie cyklem życia certyfikatów — wystawianie, rotacja i unieważnianie. Bez tego „każdy” mógłby udawać stację albo serwer.

2. Izolacja i segmentacja (defense in depth)

Świat urządzeń w terenie jest z definicji niezaufany. Dlatego OCPP Gateway działa jako osobny, izolowany serwis — bramka, która przyjmuje ruch od stacji i oddziela go od rdzenia biznesowego. Nawet jeśli pojedyncza stacja zostanie skompromitowana, nie ma bezpośredniej ścieżki do bazy klientów, płatności czy faktur. To zasada defense in depth — wiele warstw obrony zamiast jednej ściany.

3. Uwierzytelnianie i autoryzacja (least privilege)

Wewnątrz systemu obowiązuje zasada najmniejszych uprawnień: żaden pojedynczy serwis nie „może wszystkiego”. Serwis sesji nie ma dostępu do danych kart; serwis płatności nie steruje ładowarką. Do tego dochodzi kontrola dostępu ról (RBAC) dla operatorów w panelu i silne uwierzytelnianie użytkowników. Dostęp do funkcji administracyjnych jest wydzielony i audytowany — każda operacja zostawia ślad (kto, co i kiedy).

4. Bezpieczeństwo płatności

Płatności to osobna domena zaufania. Terminale (Payter, PAX), płatność mobilna i karty wymagają zgodności ze standardami branżowymi (rodzina PCI DSS), tokenizacji danych kart i separacji od pozostałych funkcji. CSMS nie powinien przechowywać wrażliwych danych płatniczych „przy okazji” — te dane żyją w wydzielonej, zabezpieczonej ścieżce, a system operacyjny ładowania widzi jedynie wynik autoryzacji, nie numer karty.

5. Ochrona danych i prywatność

Dane sesji, lokalizacji i kierowców podlegają RODO. Dobre praktyki to przetwarzanie danych w Europejskim Obszarze Gospodarczym, minimalizacja zakresu danych, szyfrowanie „w spoczynku” i „w tranzycie” oraz pełna audytowalność. Warto pamiętać, że dane o ładowaniu potrafią zdradzić nawyki i lokalizacje użytkownika — dlatego traktujemy je jak dane wrażliwe.

6. Odporność i wykrywanie zagrożeń

• Wysoka dostępność (HA) — brak pojedynczego punktu awarii; kluczowe komponenty są redundantne.
• Monitoring i telemetria — stały wgląd w stan stacji i systemu, alerty o anomaliach.
• Ochrona przed nadużyciem — ograniczanie ruchu (rate limiting), wykrywanie nietypowych wzorców, odporność na ataki wolumetryczne (DoS).
• Bezpieczne aktualizacje firmware — zdalne, ale podpisane i weryfikowane, żeby aktualizacja nie stała się wektorem ataku.

7. Zgodność regulacyjna

Bezpieczeństwo to także zgodność: AFIR (m.in. płatność ad-hoc i transparentność cen), ustawa o elektromobilności, obowiązki wobec EIPA i UDT, a dla większych operatorów coraz częściej wymogi NIS2 dotyczące cyberbezpieczeństwa podmiotów kluczowych. Dobry CSMS powinien te wymogi wspierać „z pudełka”, a nie zrzucać ich w całości na operatora.

Skalowalność i niezawodność

Ruch w sieci ładowania nie jest liniowy: wieczorne szczyty, mrozy, święta, nagłe podłączenie nowego operatora z setkami stacji. Dlatego architektura mikroserwisowa daje przewagę:

• Skalowanie niezależne — rośnie ruch OCPP? Skaluje się tylko OCPP Gateway, a nie cały system.
• Komunikacja zdarzeniowa — magistrala zdarzeń rozdziela serwisy, więc chwilowe spowolnienie jednego nie blokuje pozostałych (mechanizm backpressure chroni system przed zalaniem).
• Idempotencja i spójność — zdarzenia projektuje się tak, aby ponowne przetworzenie nie psuło rozliczeń. To szczególnie ważne przy fakturach i CDR: ta sama sesja nie może zostać naliczona dwa razy.
• Klaster HA dla bramki OCPP — stałe połączenia WebSocket ze stacjami muszą przetrwać restart czy awarię pojedynczego węzła, inaczej stacje „odpadają” od systemu.

O jednym z modułów — zarządzaniu mocą — piszemy szerzej w artykule zarządzanie mocą ładowania (load balancing).

Integracje ze światem zewnętrznym

CSMS nie działa w próżni. Typowe integracje to:

• Mapy (Google Maps, Apple Maps) — publikacja lokalizacji i dostępności stacji tam, gdzie kierowcy realnie szukają ładowania.
• Rejestry i systemy nadzoru (np. EIPA) — obowiązki sprawozdawcze operatora.
• Fakturowanie i KSeF — automatyczne wystawianie i wysyłka faktur oraz dokumentów księgowych.
• Roaming (OCPI) — wymiana z innymi operatorami i dostawcami usług.

Rozliczenia to zresztą temat, na którym łatwo się przejechać — zebraliśmy praktyczne uwagi w artykule o rozliczaniu stacji ładowania.

Jak to wygląda w EV24®

W EV24 CSMS jest zbudowany dokładnie według tych zasad: izolowana bramka OCPP obsługująca 1.6J / 2.0.1 / 2.1, event-driven rdzeń mikroserwisów, osobne domeny dla płatności i rozliczeń, roaming przez OCPI oraz pełna telemetria i monitoring. Całość projektowana jak infrastruktura krytyczna — bo nią jest.

Najlepiej zobaczyć to na obrazku: przygotowaliśmy diagram architektury EV24 CSMS — od stacji, przez OCPP i mikroserwisy, po płatności, roaming i fakturę. Jeśli interesuje Cię strona produktowa, zajrzyj też do systemu zarządzania stacjami ładowania.

Podsumowanie

CSMS to nie „aplikacja do ładowarek”. To system czasu rzeczywistego, który zamienia zbiór urządzeń w bezpieczną, skalowalną i rozliczalną usługę. Trzy rzeczy decydują o jego jakości:

1. Bezpieczeństwo — szyfrowany i uwierzytelniany OCPP (docelowo mTLS), izolacja bramki, least privilege, ochrona płatności i danych, zgodność (AFIR, RODO, NIS2). To fundament, nie opcja.
2. Standardy — OCPP (1.6J/2.0.1/2.1), OCPI 2.2.1, ISO 15118. To one dają interoperacyjność i chronią przed vendor lock-in.
3. Skalowalność — architektura mikroserwisowa, komunikacja zdarzeniowa, wysoka dostępność, idempotentne rozliczenia.

Jeśli planujesz sieć ładowania albo wybierasz operatora, nie pytaj tylko „czy ładowarka obsługuje OCPP?”. Prawdziwe pytanie brzmi: czy cały system — od bezpieczeństwa, przez standardy, po skalowanie — jest zbudowany tak, żeby udźwignąć infrastrukturę krytyczną.