Lastmanagement mittels OCPP-Proxy

Die Ladeinfrastruktur wird mit den steigenden Zahlen von E-Fahrzeugen, immer wichtiger. Der Ausbau der lokalen Stromversorgung durch den EVU, kann da aber nicht Schritthalten und somit kann es zu Beschränkungen in der beziehbaren Leistung für eine bestimmte Anzahl von Ladesäulen an einem Ort kommen.

Problemstellung

Grundsätzlich bieten sehr viele Hersteller von Wallboxen Möglichkeiten, diese untereinander zu vernetzen und dadurch ein Lastmanagement zur Leistungsbeschränkung oder Regulierung zu betreiben. Die Verbindung unter den Boxen ist hier aber Herstellerspezifisch und die Funktionalität ist teilweise sogar auf die gleichen Typen von Wallboxen beschränkt oder sie ist gekoppelt an eine herstellerspezifische Backend Lösung. Diese Herstellerlösungen sind wiederum entweder mit höheren laufenden Kosten verbunden oder diese Lösungen sind in ihrem Funktionsumfang beschränkt.

Ein Kunde kam aus diesen Gründen mit der Anforderung einer Lastmanagement  Lösung, welche Herstellerunabhängig und hochflexibel in der Implementierung ist. Dieser Forderung wollten wir nachkommen und haben das verwendete Kommunikationsprotokoll OCPP 1.6 genauer betrachtet, welches zwischen Charge Point und Backend eingesetzt wird. Nach einer kurzen Einlernphase war klar, dass wir einen Local Controller laut OCPP 1.6 in einer Proxy Variante einsetzen wollten. Soll heißen, der Local Controller wird nicht lokal beim Kunden sein, sondern soll auf einem Cloud Server laufen und alle Messages zwischen Wallbox und bestehendem Backend durch routen. Relevante Messages, wie die aktuelle Ladeleistung, Start der Autorisierung, Ende der Ladung etc. verwendet der Proxy aber, um seiner Arbeit der Lasterverteilung nachkommen zu können.

Konzept

Der Proxy ist gegenüber den Charge Points das Backend und verbindet sich zusätzlich auf das tatsächliche Backend über welches die Verrechnung respektive der restliche Betrieb läuft. Jeder Charge Point schickt während eines Ladevorgangs zyklisch Ist-Daten zum Ladevorgang. Diese Daten können zur Lastverteilung verwendet werden. Übersteigen die addierten Leistungen das Maximum der aktuell verfügbaren Leistung werden die Charge Points vom OCPPProxy über ein MaxProfile "gedrosselt". Dazu muss vorab definiert werden, welche Charge Points auf welches Backend müssen und was die maximale Anschlussleistung für alle Wallboxen zusammen ist.

Umsetzung

Mittels Python wurde ein Webservice programmiert welcher als Proxy fungiert und die Daten von einer Wallbox an das Backend weitergibt. Die Konfigurationsdaten werden in einer PostgreSQL Datenbank gespeichert. Für eine einfache Konfiguration der einzelnen Charge Points und Charging Sites wurde ein Web Frontend mittels Streamlit erstellt.

Der Proxy betrachtet zyklisch die maximalen Ströme der Charging Site und adaptiert bei Bedarf die Ströme der einzelnen Ladeboxen. Über eine Rest API kann dem OCPPProxy zusätzlich dynamisch eine Leistungsvorgabe gemacht werden, sodass zum Beispiel bei Stromüberschuss einer lokalen PV Anlage, höhere Ladeströme möglich sind. Für jede Ladebox ist ein Mindestladestrom definiert, unter welchen sie nicht geregelt wird.

Der Proxy, die GUI und die Rest API für die Energiedaten der Site, sind allesamt Container Applikationen. Der Datenaustausch zwischen den einzelnen Systemen erfolgt mittels SQL Tabellen.

Es wurde eine Datenerfassung realisiert, durch welche die Kennzahlen der Ladeboxen aufgezeichnet und im Anschluss über Grafana visualisiert werden können.

Hosting

Das Hosting der Applikationen erfolgt auf Cloud Servern in einem europäischen Rechenzentrum mit Linux OS. Als Containerplattform wurde Docker verwendet. Die einzelnen Server laufen hinter einer pfSense Firewall. Als Servermonitoring kommt Prometheus auf allen Systemen zum Einsatz. Die Zustandsdaten der Server werden mittels Grafana Dashboard visualisiert. Aus Grafana erfolgt das Alarming, sollte eine Applikation oder Server nicht mehr richtig funktionieren, respektive an seine Kapazitätsgrenzen kommen.