Lademanagement für Parkanlagen

Projekteinblicke

Elektroautos laden mit bis zu 32 A bzw. 22 kW. In einem Mehrfamilienhaus ist der Hausanschluss typischerweise auf 500 A ausgelegt, wobei 400 A für das Gebäude reserviert sind. Die verbleibenden 100 A für die Ladeinfrastruktur sind bereits bei drei Elektroautos ausgelastet. Da viele Menschen einen ähnlichen Tagesablauf haben, laden sie ihre Fahrzeuge oft gleichzeitig zu Beginn der günstigeren Niedertarifzeiten.

Vorteile eines Lademanagements

Anstatt den teuren Ausbau des Hausanschlusses zu wählen, ist die Implementierung eines Lademanagements eine wirtschaftlichere Option. Die verfügbare Leistungskapazität wird so dynamisch auf die Lasten verteilt. Da ein Elektroauto durchschnittlich nur 8 kWh pro Tag benötigt, können sie reduziert oder abwechselnd laden. Um Ladeverluste zu minimieren, wird auf eine deutliche Reduzierung der Ladeleistung verzichtet und stattdessen früher mit dem abwechselnden Laden begonnen.

Universelles OCPP-Protokoll

Ein universelles und offenes Lademanagementsystem ist erforderlich, wenn unterschiedliche Ladestationen in der Parkanlage genutzt werden. SCS entwickelte zusammen mit EKZ Software für das herstellerunabhängige EKZ-Lademanagement, das auf dem offenen «Open Charge Point Protocol» (OCPP) basiert und von vielen Ladestationstypen unterstützt wird. So bleibt die Lösung zukunftssicher und flexibel erweiterbar, ohne von spezifischen Herstellern abhängig zu sein.

Edge Device mit Algorithmik

Herzstück des Systems ist das Edge Device, ein industrieller Single-Board-Computer, der in der Parkanlage als Gateway zwischen Ladestationen und Backend fungiert. Neben der Steuerung der Ladestationen erfasst er Messwerte der Stromzähler und berücksichtigt Signale vom Verteilnetzbetreiber, um den verfügbaren Strom optimiert zu verteilen.

Sicherheit und Zuverlässigkeit mit Yocto Linux

Auf dem Edge Device läuft Yocto Linux, eine schlanke, auf die Anwendung zugeschnittene Linux-Distribution. Die Verbindung zum Backend ist über ein VPN geschützt, während die Firewall nur notwendige Ports öffnet. Jedes Gerät nutzt ein individuelles Client-Zertifikat für den sicheren VPN-Zugang und das System ist gegen unbefugte Zugriffe robust abgesichert. Das Betriebssystem wird verschlüsselt und signiert per Over-the-Air (OTA) Updates aktualisiert. Dieser Prozess ist robust gegenüber Unterbrüchen und fehlerhaften Firmwaredateien. Das Gerät bootet in diesem Fall in das vorherige System, was eine Wartung vor Ort vermeidet.

Erfolgreiche Implementierung

Bis Mitte 2025 wurde das EKZ-Lademanagement in über 1’600 Parkanlagen mit rund 60’000 Parkplätzen installiert, ohne dass eine Erweiterung des Hausanschlusses erforderlich war. Durch die Überwachung der Ladestationen und Hausanschlusszählers in Echtzeit optimiert das Edge Device die Stromverteilung an die Ladestationen dynamisch und effizient.

(Quelle Titelbild: EKZ/Norbert Egli)

Einfacher Balisenleser für den Messzug

Projekteinblicke

Das Schienennetz ist ausgestattet mit Balisen, also magnetisch gekoppelten Transpondern, die zwischen den Schienen eines Gleises montiert sind. Jede davon trägt eine eindeutige Identifikationsnummer. Eine Antenne unter der Lokomotive regt die Balise mit einem 27 MHz RF-Feld an, worauf die Balise auf 4 MHz die Identifikationsnummer zurückgibt. Über die Identifikationsnummer wird der Zug sicher lokalisiert für das ETCS-Zugsicherungssystem.

Diagnosezug liest Balisen aus

Zur Überwachung und Instandhaltung der Infrastruktur setzt die SBB Diagnosezüge ein, die mit diversen Sensoren und Kameras den Zustand der Gleise erfassen. Für die Verortung der Diagnosedaten auf der Topologie der Infrastruktur werden, neben Odometrie und GPS, auch die Balisen als fixe Objekte verwendet, da diese in der Datenbank mit Position eingepflegt sind. Dafür hat die SBB eine Handvoll nicht-sicherheitsrelevanter Balisenleser im Einsatz, die nicht mit dem Zugsicherungssystem verbunden sind.

Die heute genutzten Balisenleser können nicht nachbestellt werden, da die beiden aktuellen Hersteller dieser Geräte keinen Support mehr anbieten und die Geräte nicht mehr produziert werden. Aus Gründen der Wirtschaftlichkeit und Verfügbarkeit sollte ein neuer Balisenleser entwickelt werden, der in einer kleinen Serie zu einem tiefen Preis hergestellt werden kann.

Reverse Engineering

Von den bestehenden Balisenlesern existiert keine Dokumentation, weshalb der Typ eines Lieferanten per Reverse Engineering analysiert und mit der Spezifikation der Eurobalisen abgeglichen wurde. Die Schlüsselkomponenten sind:

  • ein TX Sender bei 27.095 MHz als Telepower Source, die genaue Leistung ist unbekannt, liegt aber aufgrund der Leistungsaufnahme bei rund 3 bis 5 Watt.
  • ein RX Verstärker mit einem Tiefpassfilter (DC bis 5MHz) mit einer Attenuation von -50dB bei 27MHz.
  • ein Duplexer, um Sender und Empfänger zu trennen bei der Antenne.
  • ein Software Defined Radio (SDR), um den Sender einzuschalten und das Signal der Balise zu demodulieren.
  • ein Industrie-PC, der das Signal decodiert.

Retrofit: Nicht nur eine Kopie

Bei einem Retrofit soll nicht nur eine Kopie hergestellt, sondern auch aus dem bestehenden System gelernt werden. Im bestehenden Balisenleser wird der Sender beispielsweise über ein USB-attached Relais aus der Software ein- und ausgeschaltet, könnte aber auch direkt über das SDR-Board gesteuert werden. Zudem wird das SDR-Board nur fürs Sampling (und Demodulation) der empfangenen Signale genutzt – die Daten werden danach auf dem integrierten PC decodiert. Auch werden viele verschiedene Speisespannungen (+5V, +15V, -15V, 24V) eingesetzt. Die System-Architektur ist recht komplex und belegt wertvollen Platz im Messzug (4U Höheneinheiten im 19-Zoll Rack).

Das neue System soll deutlich vereinfacht werden:

  • TX Kontrolle direkt auf dem SDR-Board
  • reduzierte Anzahl Speisespannungen (Amplifier nicht symmetrisch versorgt)
  • Decoding direkt auf dem SDR Board, ohne separaten PC

Ohne relevante Abstriche bei der Funktionalität konnte das neue Design um einen Faktor 4 verkleinert werden (auf eine Höheneinheit im 19-Zoll Rack). Weniger Komplexität bringt zudem höhere Zuverlässigkeit und bessere Wartbarkeit.

Neues Systemdesign

Das 27 MHz Signal wird im neuen Balisenleser direkt im SDR-Board erzeugt und vom RF-Modul nur verstärkt. Da das SDR-Board mit einer Taktfrequenz von 125 MHz arbeitet, werden die Oberwellen für ein sauberes Ausgangssignal nach dem Verstärker herausgefiltert.
Das Empfangssignal wird direkt im SDR-Board decodiert. Damit besteht das neue System nur noch aus drei wesentlichen Elementen: einem Netzgerät zur Speisung, dem SDR-Board und dem RF-Frontend. Letzteres wurde kundenspezifisch für den Balisenleser entwickelt.

RF-Frontend

Im RF-Frontend sind sowohl der TX- als auch RX- und Duplexer-Pfad integriert. Auf dem Bild (unten) sieht man unten den TX- und oben den RX-Pfad. Rechts ist der Anschluss für die Antenne. Die Ausgangsleistung von 35dBm (3.2W) reicht zuverlässig, um die Balisen auszulesen. Die Leistungsaufnahme des RF-Moduls liegt bei 700mA/12V.

Software Defined Radio (SDR)

Die SDR-Plattform basiert auf einem Red Pitaya Board mit 125MHz Takt und einer Auflösung von 14bit. Es ist bestückt mit einem Xilinx Zynq 7010 FPGA. Als Betriebssystem wurde ein Yocto-basiertes Linux mit einem U-Boot Bootloader aufgesetzt. Sichere Software-Updates sind jederzeit über das Webinterface möglich. Die Applikation (Decoder) ist in Python3 geschrieben.
Während der frühen Entwicklungsphase wurden verschiedene Algorithmen für Demodulation und Decoding mit Hilfe von GNU Radio und einem Hardware-in-the-Loop Setup evaluiert. Im fertigen Produkt übernimmt das FPGA die rechenintensive Demodulation, das anschliessende Decoding geschieht in der Python-Applikation.

Websocket Applikation

Die Applikation ist als Websocket-Server ausgestaltet. Im Vergleich zu einem HTTP-Server kann ein Websocket bei einer geöffneten Verbindung auch von sich aus Daten schicken, ohne auf eine neue Verbindung des Clients zu warten. Sobald eine Balise erkannt wird, sendet der Server die Identifikationsnummer und einen Zeitstempel. Weil die Balise bei der Überfahrt mehrfach erkannt wird, kann sehr genau bestimmt werden, wann sich die Balise mittig unter dem Leser befindet. Die Genauigkeit (Jitter) des Zeitstempels ist besser als 200 Mikrosekunden, wenn die Zeitsynchronisation mittels Network Time Protocol geschieht.

Der neue Balisenleser wurde für die SBB umgesetzt und im Diagnosefahrzeug in die OpenTLS Messapplikation integriert. Täglich werden damit tausende Balisen zuverlässig ausgelesen. Über ein Web-Interface kann der Status oder das Live Log abgerufen werden. Und dank offenem Quellcode, Produktionsdaten und IP-Rechten ist die Verfügbarkeit von Balisenlesern für die SBB nun gesichert.