Vom Grenzwert zum Gate-Treiber: Was nach dem EEBUS-Signal passiert

In Teil 1 dieser Serie endete die Geschichte an der Stelle, an der das Leistungslimit per EEBUS im Wechselrichter ankommt. In Teil 2 haben wir gesehen, dass der Verbraucher davon idealerweise nichts merkt. Heute geht es um das Stück dazwischen, über das selten geschrieben wird: Wie wird aus einem semantischen Grenzwert auf IP-Ebene am Ende ein Schaltmuster in der Leistungselektronik? Die Antwort führt durch drei Protokollwelten, und jede Übersetzung zwischen ihnen ist eine Fehlerquelle und eine Angriffsfläche.

Ebene 1: EEBUS, die Welt der Bedeutung

Das Signal der Steuerbox kommt als EEBUS-Nachricht an: SPINE als Datenmodell, transportiert über SHIP, eine TLS-gesicherte Verbindung im lokalen Netzwerk. Was hier ankommt, ist eine Aussage über das Gesamtsystem: netzwirksame Leistung am Netzanschlusspunkt maximal X Kilowatt. Das ist bewusst kein Gerätebefehl. EEBUS sagt nicht, welches Gerät wie viel darf, sondern was am Zähler herauskommen muss. Die Intelligenz, dieses Systemlimit in Gerätebefehle zu übersetzen, liegt beim Energiemanagement.

Ebene 2: SunSpec Modbus, die Welt der Register

In vielen realen Anlagen beginnt jetzt die erste Übersetzung. Das Energiemanagement spricht mit Wechselrichtern über SunSpec Modbus, und dort wird aus der Systemaussage ein Registerwert: ein Prozentsatz der Nennleistung eines einzelnen Geräts, geschrieben in ein Setpoint-Register wie WMaxLimPct, dazu ein separates Enable-Flag, ohne das der geschriebene Wert schlicht wirkungslos bleibt.

Diese Übersetzung hat es in sich. Aus “X Kilowatt netzwirksam am Anschlusspunkt” muss “Y Prozent Nennleistung an Gerät Z” werden, und zwar unter Berücksichtigung von Haushaltslast, PV-Ertrag und Speicherzustand. Wer die Rechnung falsch macht, begrenzt zu streng und verschenkt Energie, oder zu lax und verletzt die Vorgabe. Dazu kommt das Timing: Modbus wird gepollt, typisch im Sekundentakt. Und schließlich die Interoperabilität, die Leserinnen und Leser meiner SunSpec-Serie kennen: Skalierungsfaktoren, die vor der Verwendung gelesen werden müssen, Register, die je nach Hersteller unterschiedlich interpretiert werden, und aktuell der Übergang von den 100er-Modellen aus dem Jahr 2009 auf die neue 700er-Serie nach IEEE 1547-2018, die offiziell freigegeben ist und die alten Modelle ablöst, während etliche Bestandsgeräte und Herstellerprofile noch auf der 100er-Welt aufsetzen. Zwei Modellgenerationen parallel im Feld, das ist gelebte Interoperabilität.

Ebene 3: CAN, die Welt der Physik

Die Batterie spricht eine dritte Sprache. Das Batteriemanagementsystem meldet über CAN seine Betriebsgrenzen: maximale Lade- und Entladeströme, Zellspannungen, Temperatur-Derating, und das in Echtzeit, denn hier geht es um Zellchemie und damit um Sicherheit. Diese Grenzen sind nicht verhandelbar. Das Energiemanagement kann nach außen nur zusagen, was das BMS in diesem Moment freigibt. Ein EEBUS-Limit, dessen Einhaltung die Batterie als Puffer voraussetzt, ist exakt so viel wert wie die aktuelle BMS-Freigabe. Wenn die Zellen kalt sind und das BMS die Ladeleistung drosselt, muss die Rechnung am Netzanschlusspunkt das sofort berücksichtigen, nicht erst beim nächsten Polling-Zyklus.

Der rote Faden: Sicherheit endet an der ersten Übersetzung

Jetzt der Blick, der mir als Sicherheitsingenieur am wichtigsten ist. EEBUS ist per SHIP mit TLS gesichert, mit gegenseitiger Authentifizierung beim Pairing. Diese Absicherung endet aber genau dort, wo die Kette in die nächste Protokollwelt übersetzt.

Modbus stammt aus dem Jahr 1979 und wurde für abgeschottete Industrieanlagen entworfen, in denen Sicherheit schlicht kein Designziel sein musste. Die spätere TCP-Variante hat dieses Sicherheitsmodell geerbt: von Haus aus weder Authentifizierung noch Verschlüsselung noch Integritätsschutz, alles läuft im Klartext über Port 502. Ein Protokoll aus der Ära der Luftspalt-Isolation arbeitet heute im vernetzten Heimnetz. Es gibt seit 2018 eine offizielle Security-Erweiterung, Modbus/TCP Security mit TLS und X.509-Zertifikaten auf Port 802. Nur: Die Verbreitung im installierten Bestand ist bis heute dünn, und die SunSpec Alliance arbeitet noch an den Testprozeduren für ihre sichere Variante. Wer heute eine Anlage aus Komponenten verschiedener Hersteller zusammensteckt, betreibt die Strecke zwischen EMS und Wechselrichter mit hoher Wahrscheinlichkeit ungesichert. CAN schließlich wurde nie für Vertraulichkeit entworfen; wer physischen oder logischen Zugriff auf den Bus hat, kann mitlesen und senden.

Das Fazit daraus ist unbequem, aber wichtig: In einer Kette aus Boxen verschiedener Hersteller ist der Grenzwert nur auf dem ersten Teilstück kryptografisch geschützt. Danach läuft er als Klartext-Registerwert durchs Heimnetz. Ein Angreifer muss nicht die TLS-Verbindung der Steuerbox brechen, er greift die schwächste Übersetzungsstelle an. Die Angriffsfläche eines Systems ist die Summe seiner Übersetzungsstellen, und genau deshalb schaut der Cyber Resilience Act auf das Produkt als Ganzes und nicht auf das beste Teilstück seiner Kommunikation.

Was das architektonisch bedeutet

Die Konsequenz, die wir beim ampareq Gen3 gezogen haben, ist einfach zu formulieren und aufwendig zu bauen: Übersetzungsstellen minimieren. Die TLS-gesicherte EEBUS-Verbindung terminiert direkt in dem Gerät, das die Leistungselektronik regelt und das BMS anbindet. Die Umrechnung vom Netzanschlusspunkt-Limit auf Stellgrößen passiert dort, wo alle Messwerte ohnehin vorliegen, von der Phasenstrommessung bis zur BMS-Freigabe, und der Grenzwert verlässt das Gerät auf dem Weg zur Leistungselektronik nie als ungeschützte Netzwerknachricht. Was an interner Kommunikation bleibt, liegt innerhalb einer Vertrauensgrenze, die sich nach IEC 62443 sauber ziehen und verteidigen lässt.

Man kann es so zusammenfassen: Jede Box in der Kette ist eine Übersetzung, jede Übersetzung ist eine Fehlerquelle, und jede Fehlerquelle ist im Zweifel auch eine Angriffsfläche. Die eleganteste Absicherung ist die Strecke, die es gar nicht gibt.

Meine Frage an die Systemintegratoren und Entwickler unter euch: Wie sichert ihr heute die Modbus-Strecke zwischen EMS und Wechselrichter ab, per Netzsegmentierung, per VPN-Tunnel, oder läuft sie schlicht offen im Heimnetz mit?