In den vergangenen Wochen ging es um drei Dinge, die im ampareq Gen3 fehlen: das Display, den Lüfter und den Elektrolytkondensator. Alle drei Entscheidungen verfolgen dasselbe Ziel. Das Gerät soll 20 Jahre im Keller hängen, ohne dass jemand daran schrauben muss.

Heute geht es um etwas, das man nicht anfassen kann, das aber darüber entscheidet, ob diese 20 Jahre gelingen: die Frage, wie man eine Firmware aktualisiert, die zwei Regelwerken gleichzeitig genügen muss.

Zwei Regelwerke, zwei Richtungen.

Seit dem 11. September gilt Artikel 14 des Cyber Resilience Act auch für Produkte, die bereits auf dem Markt sind. Wird eine Schwachstelle aktiv ausgenutzt, muss der Hersteller innerhalb von 24 Stunden eine Frühwarnung abgeben, innerhalb von 72 Stunden eine Meldung machen und spätestens 14 Tage nach Verfügbarkeit einer Korrektur einen Abschlussbericht erstellen. Die Meldepflicht allein schließt keine Lücke. Sie macht jedoch sichtbar, wie lange ein Hersteller vom Befund bis zum Patch braucht.

Auf der anderen Seite steht die Netzanschlussregel. Ein Wechselrichter am Niederspannungsnetz benötigt ein Einheitenzertifikat nach VDE-AR-N 4105, das sich auf einen dokumentierten Softwarestand bezieht. Wird die Software geändert, prüft die Zertifizierungsstelle in der Regel, ob das Zertifikat weiterhin gültig ist.

Der CRA verlangt Tempo. Die Zertifizierung verlangt jedoch einen nachweislich geprüften Stand. Wer die gesamte Firmware als einen Block betrachtet, muss sich im Ernstfall zwischen beidem entscheiden.

Die meisten Updates haben mit dem Netz nichts zu tun.

Betrachtet man die Updates, die ein Hybridwechselrichter über seine Lebensdauer erhält, so stellt man fest, dass der größte Teil netzfern ist. Eine Lücke in einer Kryptobibliothek. Ein neuer dynamischer Tarif, den das Energiemanagement kennen soll. Eine geänderte Schnittstelle beim Plattformanbieter. Ein neues Batteriemodell. Nichts davon betrifft die Frequenz-Wirkleistungs-Regelung, Q(U), oder den Netz- und Anlagenschutz. Trotzdem liegt all das in vielen Geräten in derselben Firmware wie die Funktionen, die das Zertifikat abdeckt.

Die Trennung

Beim ampareq Gen3 haben wir das von Anfang an anders umgesetzt. Die Software läuft in zwei getrennten Kerneln. Kernel 1 enthält alles, was für die Zertifizierung relevant ist. Kernel 2 enthält alles andere, einschließlich der Integration von Energieanbietern und Plattformen. Beide haben ihren eigenen Update-Weg.

Der Clou dabei ist: Eine Sicherheitslücke im Kommunikationsteil lässt sich schließen, ohne den zertifizierten Teil anzufassen. Und eine neue Anbieteranbindung erfordert keinen Termin im Prüflabor.

Der Gesetzgeber denkt in eine ähnliche Richtung. In Erwägungsgrund 57 des CRA formuliert er das Ziel, Sicherheitsupdates, wo technisch machbar, getrennt von Funktionsupdates bereitzustellen. Wir trennen eine Ebene tiefer: nicht nur Sicherheit von Funktion, sondern auch Zertifiziertes von allem anderen.

Woher das Muster kommt

Die Idee ist nicht neu. In der Automobilentwicklung habe ich an der Grundlage einer Fahrzeug-Softwareplattform mitgearbeitet. Eines der Ziele war dort, Fahrzeuge 20 Jahre lang hardwareunabhängig mit Updates und neuen Funktionen zu versorgen, solange die Hardware leistungsfähig genug bleibt. Ein Auto und ein Wechselrichter haben einiges gemeinsam: Beide sind sicherheitsrelevant, beide sind vernetzt und beide bleiben deutlich länger im Einsatz als die Software, mit der sie ausgeliefert wurden.

Der Preis

Wie beim Lüfter und beim Elko gibt es das nicht umsonst.

Erstens gibt es die Schnittstelle zwischen den Kerneln. Sie ist die wichtigste Grenze im ganzen Gerät. Kernel 2 darf Anforderungen stellen, aber nie die Grenzen verschieben, die Kernel 1 einhält. Das ist keine reine Geschmacksfrage der Architektur. Im Zertifizierungsverfahren muss nachgewiesen werden, dass die frequenzabhängige Wirkleistungsregelung Vorrang vor Sollwertvorgaben Dritter hat. Die Trennung bildet genau diese Rangfolge im Aufbau der Software ab. Jede neue Idee aus dem Energiemanagement beginnt deshalb mit der Frage, ob sie über diese Schnittstelle passt.

Zweitens Disziplin. Die bequemste Lösung für eine neue Funktion ist oft die, die im Kernel 1 landet. Genau das darf nicht passieren. Sonst wächst der zertifizierte Teil und damit auch die Zahl der Updates, die erneut zur Zertifizierungsstelle müssen.

Drittens entsteht doppelter Aufwand in Test und Pflege. Zwei Update-Wege bedeuten zwei Freigabeprozesse, eine Kompatibilitätsmatrix zwischen den Versionsständen beider Kernel sowie Rollback-Szenarien, die für jede zulässige Kombination funktionieren müssen.

Viertens hilft die Trennung nicht immer. Liegt eine Schwachstelle in Kernel 1 vor, führt kein Weg an der Prüfung vorbei. Die Architektur verhindert diesen Fall nicht. Sie macht ihn nur seltener, da der zertifizierte Teil so klein wie möglich gehalten wird.

Warum das für Installateure und Distributoren zählt

Ein Kunde fragt selten, wie eine Firmware aufgebaut ist. Er fragt, ob sein Gerät in zehn Jahren noch mit seinem Stromanbieter, seiner Wallbox und den dann geltenden Regeln zusammenarbeitet. Und der Installateur möchte nicht erklären müssen, ob das Gerät nach dem letzten Update noch zugelassen ist.

Im Januar habe ich hier gefragt, was mit einem Gerät passiert, das 20 Jahre lang genutzt werden soll, wenn sich die Spielregeln alle zwölf Monate ändern. Display, Lüfter und Elko waren die Antwort auf der Hardware-Seite. Die getrennten Update-Wege sind die Antwort auf der Software-Seite.

Konformität am Tag der Auslieferung ist Pflicht. Konformität über einen Zeitraum von 20 Jahren ist eine Architekturentscheidung.

Wie lösen Sie in Ihren Projekten den Konflikt zwischen schnellem Patchen und zertifiziertem Softwarestand?