Kommen wir zu einem praxisnahen Beispiel unseres Observability-Schwerpunkts: Dieser Artikel beschäftigt sich mit dem Einsatz von Grafana für das E-Mobilitäts-Backend der Stromnetz Hamburg GmbH und ihrer Kunden. Durch eine gemeinsame Datenquelle entsteht die Herausforderung, wie in Grafana jedem Mandanten entsprechend nur das relevante Subset der Ladeinfrastruktur zum Monitoring zur Verfügung gestellt werden kann.

Die Stromnetz Hamburg GmbH ist im Gebiet der Freien und Hansestadt Hamburg Eigentümer und Betreiber des Stromverteilungsnetzes. Im Zuge des 2014 deutschlandweit beschlossenen Masterplans für öffentliche Ladeinfrastruktur wurden in Hamburg bis Ende 2020 insgesamt 1 000 Ladepunkte für Elektroautos errichtet. Dafür wurde ein Java-basiertes Backend entwickelt, das über die Jahre modularisiert wurde. Es ist mandantenfähig und wird inzwischen für über 8 000 Ladepunkte deutschlandweit auch von anderen Ladestationsbetreibern (Charge Point Operator, CPO) [1] eingesetzt.

Ladesäulen 101

Die Kommunikation der Ladesäulen mit dem Backend geschieht über das Open Charge Point Protocol (OCPP) [2]. Viele Ladesäulen sprechen leider noch immer mit OCPP-Version 1.5 (SOAP und XML), ab Version 1.6 stehen die Ladesäulen über (secure) WebSockets und JSON-Nachrichten mit dem Backend im Austausch. Das Backend filtert nach unterschiedlichen Nachrichtentypen, so werden z. B. während einer Transaktion (also eines Ladevorgangs) sogenannte MeterValue-Updates geschickt. Diese erlauben es, den Ladefortschritt in regelmäßigen Intervallen zu ermitteln. Daneben können auch Statusbefehle bis hin zu Soft Resets oder neue Firmwareversionen eingespielt werden.

Daten sammeln

Je nach Nachrichtentyp werden die anfallenden Informationen gebündelt und auf entsprechenden Kafka Topics interessierten Konsumenten zur Verfügung gestellt. Die Kernkomponente (CORE) steht mit den Ladesäulen in Verbindung und sendet die für die Datenanalyse relevanten Informationen über den Fortschritt des Ladevorgangs. Des Weiteren existieren Vertikale z. B. für das Lastmanagement (LLM), Parkplatzdetektoren (PPD) und Central User Service (CUS).

Abbildung 1 stellt das Gesamtbild der ein- und ausgehenden Eventströme mit Fokus auf die Datenanalysevertikale dar. Im Sinne einer Microservices-Architektur wird die Vertikale für die Datenanalyse unabhängig von den anderen Systemkomponenten weiterentwickelt sowie unabhängig deployt und skaliert. Als Persistenzschicht wird für die Datenanalyse die für Zeitreihen optimierte TimescaleDB...