Was ist ein CSMS und wie ist es aufgebaut?

Eine Ladestation sieht von außen aus wie „eine Steckdose mit Strom“. In Wirklichkeit ist sie ein vernetztes, ferngesteuertes Gerät, das mit dem Stromnetz und mit Zahlungssystemen verbunden ist. Was all das zu einem funktionierenden, sicheren und abrechenbaren Dienst verbindet, ist das CSMS — Charging Station Management System.

In diesem Artikel erklären wir, was ein CSMS ist, wie seine Architektur aufgebaut ist, welche Kommunikationsstandards es verbinden (OCPP, OCPI, ISO 15118) und — am wichtigsten — warum Sicherheit hier kein Zusatz, sondern das Fundament des Designs ist. Wenn Sie das Ganze lieber auf einem Bild sehen, haben wir ein EV24®-CSMS-Architekturdiagramm vorbereitet.

Was ist ein CSMS?

Ein CSMS (Charging Station Management System), auch CPMS (Charge Point Management System) genannt, ist das Backend, das ein Netz von Ladestationen verwaltet. Es:

• verbindet sich mit den Ladestationen und hält einen dauerhaften Kommunikationskanal,
• überwacht ihren Status in Echtzeit,
• startet und beendet Ladesitzungen,
• verwaltet Leistung, Tarife und Zugriff,
• erfasst Messdaten (CDR — Charge Detail Record),
• wickelt Zahlungen, Abrechnungen und Rechnungen ab,
• stellt Daten für Betreiber, Fahrer, Karten und Roaming-Partner bereit.

Anders gesagt: Die Ladestation ist der „Muskel“ und das CSMS das „Nervensystem“ des gesamten Netzes. Ohne es haben Sie eine Menge unabhängiger Geräte; mit ihm haben Sie einen Ladedienst, den Sie skalieren, abrechnen und steuern können.

Hier lohnt es, drei oft verwechselte Rollen zu unterscheiden. Ein CPO (Charge Point Operator) betreibt die Stationen physisch und ist für ihren Betrieb verantwortlich. Ein eMSP (e-Mobility Service Provider) liefert den Dienst für den Fahrer — App, Konto, Zahlung. Das CSMS ist das Softwaresystem, das die Operationen des CPO ausführt und Daten mit eMSPs austauscht. Ein Unternehmen kann mehrere Rollen zugleich einnehmen, in der Architektur zahlt es sich jedoch aus, sie zu trennen, weil sie unterschiedliche Anforderungen und Daten haben.

Warum ein CSMS kritische Infrastruktur ist und keine „gewöhnliche Software“

Bevor wir zur Architektur kommen, hilft die richtige Denkweise. Ein CSMS liegt an der Schnittstelle dreier Welten, jede mit hohen Anforderungen:

1. Energie — Sie steuern Geräte, die reale Leistung aus dem Netz beziehen. Ein Fehler oder eine Übernahme ist kein „Datenleck“, sondern hat physische Folgen: eine blockierte Station, ein überlasteter Anschluss, eine unterbrochene Sitzung auf einer Reise.
2. Zahlungen — Transaktionen, Kartendaten und Terminals laufen durch das System. Branchenstandards und Regulierungen gelten.
3. Recht und Compliance — AFIR, E-Mobilitätsrecht, DSGVO und zunehmend Cybersicherheitsanforderungen (z. B. NIS2 für wesentliche Einrichtungen).

Deshalb wird ein gutes CSMS wie ein hochverfügbares Echtzeitsystem entworfen, mit Sicherheit von der ersten Codezeile an, nicht am Ende angeklebt.

Architektur auf hoher Ebene

Am einfachsten beschreibt man eine CSMS-Architektur als vier Schichten, von links nach rechts:

1. Ladeinfrastruktur — AC-Stationen, DC-Stationen, mobile Ladegeräte, Controller und Zähler an den Standorten.
2. CSMS-Kern — eine Reihe von Microservices, die Kommunikation annehmen, Sitzungen führen, rechnen und Events veröffentlichen.
3. Business-Module — Smart Charging, Billing und Tarife, Roaming, Analytik.
4. Abnehmer — die Fahrer-App, das Betreiber-Panel, die öffentliche API und Integrationen.

Das Kernprinzip: die Schichten sind lose gekoppelt und kommunizieren über Events, nicht über starre, direkte Aufrufe. Dadurch kann jeder Teil unabhängig entwickelt, skaliert und abgesichert werden — und der Ausfall eines Elements legt nicht das Ganze lahm.

Schicht 1: Infrastruktur und ihre Vielfalt

Stationen unterscheiden sich in Leistung (AC vs. DC), Konnektivität (eSIM, SIM, WiFi, LTE) und Protokollversion. In einem Netz koexistieren OCPP-1.6J-, 2.0.1- und 2.1-Ladestationen natürlich, daneben Controller und Energiezähler, die z. B. über Modbus kommunizieren. Aufgabe des CSMS ist es, diese Vielfalt zu vereinheitlichen — sodass der Rest des Systems nicht wissen muss, welche Hardware genau im Feld steht.

Schicht 2: der Microservices-Kern

Der Kern ist kein „großes Programm“, sondern eine Reihe spezialisierter Services. Bei EV24 sehen sie so aus:

• OCPP Gateway — hält die WebSocket-Verbindungen zu den Stationen, übersetzt Befehle zwischen OCPP-Versionen und isoliert die „schmutzige“ Gerätewelt vom Rest. Es ist die einzige Komponente, die direkt mit der Hardware spricht.
• Session Service — behandelt Start, Stopp und Verlauf einer Sitzung und erzeugt das CDR (Charge Detail Record), Grundlage der Abrechnung.
• Chargers Registry — ein Register der Stationen, EVSEs und Steckverbinder mit ihrer Konfiguration, ihren Status und Fähigkeiten.
• Event Bus & Streams — der Bus aus Events und Echtzeit-Telemetrie, der alle Services verbindet und ihnen erlaubt, ohne starre Abhängigkeiten zu reagieren.

Darüber arbeiten die Business-Module: Smart Charging (Load Balancing, DLM), Billing und Tarife, Roaming (OCPI) und Analytik.

Schicht 3 und 4: Business-Module und Abnehmer

Die Business-Module machen aus Roh-Events Wert: Sie berechnen Kosten, verteilen Leistung zwischen Punkten, tauschen Daten mit anderen Betreibern aus und berechnen Kennzahlen. Die Abnehmer — Fahrer-App, Betreiber-Panel, öffentliche API und Integrationen — konsumieren diese Daten. Wichtig: Abnehmer greifen nie direkt auf die Geräte zu, immer über den Kern, was auch für die Sicherheit entscheidend ist.

Die Standards, die ein CSMS zusammenhalten

Eine Architektur ist nur so gut wie die Standards, auf denen sie steht. Sie entscheiden über Interoperabilität und darüber, ob man in einen Vendor-Lock-in gerät.

OCPP — die Sprache zwischen Ladestation und System

OCPP (Open Charge Point Protocol) ist der offene Standard für die Kommunikation zwischen Station und CSMS. In der Praxis begegnen Ihnen drei Versionen:

Ein gutes CSMS unterstützt alle drei Versionen gleichzeitig, denn der Bestand im Feld ist gemischt. Man kann nicht über Nacht alle Ladestationen austauschen — deshalb muss das OCPP-Gateway jeden dieser „Dialekte“ sprechen und sie in ein gemeinsames, internes Modell übersetzen. Mehr zum Protokoll und den Unterschieden im Artikel zum Open Charge Point Protocol (OCPP).

OCPI — Roaming zwischen Betreibern

OCPI (Open Charge Point Interface), meist in Version 2.2.1, ist der Roaming-Standard — er erlaubt, dass ein Fahrer eines Dienstanbieters (eMSP) an der Station eines anderen Betreibers (CPO) lädt, mit korrekter Abrechnung zwischen den Parteien. OCPI ist in Module unterteilt, jedes für einen anderen Teil des Datenaustauschs:

Dank OCPI ist Ihr Netz weit über die eigene App hinaus sichtbar und nutzbar — und das schlägt sich direkt in der Auslastung der Stationen nieder.

ISO 15118 — Plug & Charge

ISO 15118 (Plug & Charge) ist eine sichere, zertifikatsbasierte Autorisierung „per Stecker“: Der Fahrer steckt das Kabel ein, und Authentifizierung sowie Abrechnung geschehen automatisch, ohne App und ohne Karte. Darunter läuft eine Public-Key-Infrastruktur (PKI): Fahrzeug und Station tauschen Zertifikate aus und prüfen sie, die gesamte Übertragung ist verschlüsselt. Das ist Komfort für den Fahrer und ein höheres Sicherheitsniveau — erfordert aber vom CSMS die Zertifikatsverwaltung auf der Stationsseite.

Modbus, Zähler und Zahlungen

Auf Standortebene kommen noch Energiezähler und Controller hinzu, oft über Modbus (Verbrauchsmessung, Leistungssteuerung). Und Zahlungen: Terminals (z. B. Payter, PAX), mobile Zahlung, Karten. Das CSMS muss diese Welten verbinden — aber wichtig: sie in getrennten, gut isolierten Domänen halten.

Sicherheit — das Fundament, kein Zusatz

Das ist der wichtigste Teil des Artikels. In einem CSMS muss Sicherheit auf mehreren Ebenen zugleich betrachtet werden, denn ein Angreifer wählt nicht den „schönen“ Weg, sondern das schwächste Glied.

1. Absicherung der OCPP-Schicht

Das ist der sensibelste Kanal: Über ihn senden Sie dem Gerät die Befehle „Start“, „Stopp“, Konfigurationsänderungen oder Updates. OCPP 2.0.1 definiert Security Profiles, die man kennen sollte:

Die Richtung ist klar: letztlich Profil 3 (mTLS), bei dem Station und CSMS ihre Identität gegenseitig bestätigen und die Verbindung immer über TLS (WSS) läuft, nie über einen „nackten“ WebSocket. Hinzu kommt das Zertifikats-Lebenszyklus-Management — Ausstellung, Rotation und Widerruf. Ohne das könnte „jeder“ eine Station oder einen Server vortäuschen.

2. Isolation und Segmentierung (Defense in Depth)

Die Welt der Feldgeräte ist per Definition nicht vertrauenswürdig. Deshalb läuft das OCPP Gateway als separater, isolierter Service — ein Gateway, das den Verkehr von Stationen annimmt und ihn vom Business-Kern trennt. Selbst wenn eine einzelne Station kompromittiert wird, gibt es keinen direkten Weg zur Kundendatenbank, zu Zahlungen oder Rechnungen. Das ist Defense in Depth — viele Schutzschichten statt einer einzigen Wand.

3. Authentifizierung und Autorisierung (Least Privilege)

Innerhalb des Systems gilt das Prinzip der geringsten Rechte: Kein einzelner Service „darf alles“. Der Session-Service hat keinen Zugriff auf Kartendaten; der Payment-Service steuert nicht die Ladestation. Hinzu kommen rollenbasierte Zugriffskontrolle (RBAC) für Betreiber im Panel und starke Benutzer-Authentifizierung. Der Zugriff auf administrative Funktionen ist abgetrennt und auditiert — jede Operation hinterlässt eine Spur (wer, was und wann).

4. Zahlungssicherheit

Zahlungen sind eine eigene Vertrauensdomäne. Terminals (Payter, PAX), mobile Zahlung und Karten erfordern Konformität mit Branchenstandards (der PCI-DSS-Familie), Tokenisierung der Kartendaten und Trennung vom Rest. Ein CSMS sollte sensible Zahlungsdaten nicht „nebenbei“ speichern — diese Daten leben in einem getrennten, gesicherten Pfad, und das Ladebetriebssystem sieht nur das Autorisierungsergebnis, nicht die Kartennummer.

5. Datenschutz und Privatsphäre

Sitzungs-, Standort- und Fahrerdaten unterliegen der DSGVO. Gute Praxis ist die Verarbeitung im Europäischen Wirtschaftsraum, die Minimierung des Datenumfangs, Verschlüsselung „at rest“ und „in transit“ sowie volle Prüfbarkeit. Zu bedenken ist, dass Ladedaten Gewohnheiten und Aufenthaltsorte eines Nutzers verraten können — deshalb behandeln wir sie als sensible Daten.

6. Resilienz und Bedrohungserkennung

• Hochverfügbarkeit (HA) — kein Single Point of Failure; Schlüsselkomponenten sind redundant.
• Monitoring und Telemetrie — ständiger Einblick in den Zustand der Stationen und des Systems, Alarme bei Anomalien.
• Missbrauchsschutz — Rate Limiting, Erkennung ungewöhnlicher Muster, Widerstandsfähigkeit gegen volumetrische (DoS-)Angriffe.
• Sichere Firmware-Updates — aus der Ferne, aber signiert und verifiziert, damit ein Update nicht zum Angriffsvektor wird.

7. Regulatorische Konformität

Sicherheit ist auch Compliance: AFIR (u. a. Ad-hoc-Zahlung und Preistransparenz), E-Mobilitätsrecht, Pflichten gegenüber den zuständigen Behörden und zunehmend, für größere Betreiber, NIS2-Cybersicherheitsanforderungen für wesentliche Einrichtungen. Ein gutes CSMS sollte diese Anforderungen ab Werk unterstützen, statt sie vollständig auf den Betreiber abzuwälzen.

Skalierbarkeit und Zuverlässigkeit

Der Verkehr in einem Ladenetz ist nicht linear: Abendspitzen, Frost, Feiertage, ein plötzliches Onboarding eines neuen Betreibers mit Hunderten Stationen. Genau hier zahlt sich die Microservices-Architektur aus:

• Unabhängige Skalierung — wächst der OCPP-Verkehr? Es skaliert nur das OCPP Gateway, nicht das ganze System.
• Event-getriebene Kommunikation — der Event Bus entkoppelt die Services, sodass eine kurzzeitige Verlangsamung eines Dienstes die anderen nicht blockiert (ein Backpressure-Mechanismus schützt das System vor Überflutung).
• Idempotenz und Konsistenz — Events sind so gestaltet, dass eine erneute Verarbeitung Abrechnungen nicht zerstört. Das ist besonders bei Rechnungen und CDRs wichtig: Dieselbe Sitzung darf nicht zweimal berechnet werden.
• HA-Cluster für das OCPP-Gateway — die dauerhaften WebSocket-Verbindungen zu Stationen müssen einen Neustart oder den Ausfall eines einzelnen Knotens überstehen, sonst „fallen“ Stationen vom System ab.

Auf eines der Module — das Lastmanagement — gehen wir im Artikel zum Lastmanagement für Ladestationen näher ein.

Integrationen mit der Außenwelt

Ein CSMS arbeitet nicht im Vakuum. Typische Integrationen sind:

• Karten (Google Maps, Apple Maps) — Veröffentlichung von Standorten und Verfügbarkeit dort, wo Fahrer tatsächlich nach Laden suchen.
• Register und Aufsichtssysteme — die Meldepflichten des Betreibers.
• Rechnungsstellung — automatisches Erstellen und Versenden von Rechnungen und Buchhaltungsdokumenten.
• Roaming (OCPI) — Austausch mit anderen Betreibern und Dienstanbietern.

Die Abrechnung ist übrigens ein Thema, bei dem man leicht danebenliegt — praktische Hinweise haben wir im Artikel zur Abrechnung von Ladestationen gesammelt.

Wie es bei EV24® aussieht

Bei EV24 ist das CSMS genau nach diesen Prinzipien gebaut: ein isoliertes OCPP-Gateway für 1.6J / 2.0.1 / 2.1, ein event-getriebener Microservices-Kern, getrennte Domänen für Zahlungen und Abrechnungen, Roaming über OCPI sowie volle Telemetrie und Monitoring. Das Ganze entworfen wie kritische Infrastruktur — weil es das ist.

Am besten sieht man es auf einem Bild: Wir haben ein EV24-CSMS-Architekturdiagramm vorbereitet — von den Stationen über OCPP und Microservices bis zu Zahlungen, Roaming und Rechnung. Wenn Sie die Produktseite interessiert, werfen Sie auch einen Blick auf das Ladepunkt-Management-System.

Zusammenfassung

Ein CSMS ist keine „App für Ladestationen“. Es ist ein Echtzeitsystem, das aus einer Menge Geräte einen sicheren, skalierbaren und abrechenbaren Dienst macht. Drei Dinge entscheiden über seine Qualität:

1. Sicherheit — verschlüsseltes und authentifiziertes OCPP (letztlich mTLS), Gateway-Isolation, Least Privilege, Zahlungs- und Datenschutz, Compliance (AFIR, DSGVO, NIS2). Das ist das Fundament, keine Option.
2. Standards — OCPP (1.6J/2.0.1/2.1), OCPI 2.2.1, ISO 15118. Sie liefern Interoperabilität und schützen vor Vendor-Lock-in.
3. Skalierbarkeit — Microservices-Architektur, event-getriebene Kommunikation, Hochverfügbarkeit, idempotente Abrechnungen.

Wenn Sie ein Ladenetz planen oder einen Betreiber wählen, fragen Sie nicht nur „unterstützt die Ladestation OCPP?“. Die eigentliche Frage lautet: Ist das gesamte System — von der Sicherheit über die Standards bis zur Skalierung — so gebaut, dass es kritische Infrastruktur tragen kann.