SMGW-Backend skalieren: Messdatenmanagement und PKI für Millionen Geräte

Die drei Schichten des SMGW-Backends

Hinter jedem Smart Meter Gateway steht ein Backend aus drei Systemen. Erst ihr Zusammenspiel macht aus den Rohwerten des Zählers abrechenbare und marktfähige Daten. Im Hochlauf des Rollouts ist genau diese Schichtung die tragende Infrastruktur, an der sich Skalierung entscheidet.

Die erste Schicht ist das GWA-System. Es übernimmt die Administration und Konfiguration der Gateways und verwaltet ihr Schlüsselmaterial. Hier werden Geräte in Betrieb genommen, Profile und Tarifanwendungsfälle ausgerollt und der Bestand verwaltet. Die zweite Schicht ist das Head-End-System (HES), das die WAN-Kommunikation mit den Geräten im Feld führt. Es spricht die Gateways über das Weitverkehrsnetz an, nimmt ihre Meldungen entgegen und ist damit der Engpass für Erreichbarkeit und Durchsatz.

Die dritte Schicht ist das Messdatenmanagement (MDM). Es validiert die eingehenden Werte, bildet bei Lücken Ersatzwerte, bereitet die Daten auf und stellt sie für Abrechnung und Marktkommunikation bereit. Unter allen drei Schichten liegen zwei Querschnittsfunktionen, ohne die nichts läuft: die Smart-Meter-PKI als Vertrauensgerüst und die Hardware-Sicherheitsmodule für die kryptografischen Operationen. Beide müssen mitskalieren, sonst wird die Sicherheit zum Flaschenhals des gesamten Betriebs.

Die Smart-Meter-PKI und die Zertifikate

Die PKI ist das Vertrauensgerüst des Rollouts. Ohne gültige Zertifikate redet kein Gateway mit dem Backend, und genau das macht sie im Massenbetrieb anspruchsvoll. Sie ist nach BSI TR-03109-4 aufgebaut und folgt einem dreistufigen Modell.

An der Spitze steht die Root-CA beim BSI als Vertrauensanker. Darunter liegen die privaten Sub-CAs, betrieben von Dienstleistern und Stadtwerken, und auf der untersten Ebene die Endteilnehmer: Gateway, GWA, Hersteller und externe Marktteilnehmer. Aktuell sind 11 Sub-CAs registriert. Jede Sub-CA stellt die Zertifikate für ihre Endteilnehmer aus, das BSI verankert über die Root-CA das Vertrauen für die gesamte Infrastruktur.

Auf der Ebene der Endteilnehmer wird die PKI granular. Jeder Teilnehmer braucht getrennte Schlüsselpaare je Verwendungszweck. Pro Kommunikationsbeziehung gibt es eigene Signatur-, Verschlüsselungs- und TLS-Zertifikate, und ein privater Schlüssel darf nur für seinen definierten Zweck genutzt werden. Diese Trennung erhöht die Sicherheit, vervielfacht aber die Zahl der zu verwaltenden Zertifikate, sobald der Bestand in die Millionen wächst.

Branchenüblich sind mehrjährige Laufzeiten der Zertifikate. Die exakten Werte je Zertifikatstyp stehen in der Certificate Policy der SM-PKI und sind hier nicht abschließend gesichert wiedergegeben, wer plant, sollte sie dort im Detail prüfen. Für die Backend-Architektur ist vor allem eines wichtig: Jedes Zertifikat hat ein Ablaufdatum, und bei Millionen Geräten verteilt sich dieser Ablauf über das ganze Jahr.

Das Datenvolumen: 15-Minuten-Werte im Massenbetrieb

Skalierung ist vor allem ein Mengenproblem. Aus einem harmlosen Viertelstundenwert werden im Bestand schnell sehr große Datenmengen, und die müssen Head-End-System und Messdatenmanagement aufnehmen und verarbeiten, ohne ins Stocken zu geraten.

Die Rechnung ist einfach: Bei 15-Minuten-Messung entstehen 96 Datenpunkte pro Gerät und Tag. Hochgerechnet auf zig Millionen Geräte ergeben sich daraus Milliarden Messwerte pro Tag. Diese Milliarden-Größenordnung ist eine Hochrechnung aus dem Viertelstundenwert und der erwarteten Gerätezahl, kein gemessener Tageswert, aber sie zeigt die Dimension, auf die das Backend ausgelegt sein muss.

Das Messdatenmanagement nimmt diese Werte nicht nur entgegen. Es muss sie validieren, bei Lücken Ersatzwerte bilden und die Marktkommunikation bedienen, also die aufbereiteten Daten an die Marktpartner liefern. Jeder dieser Schritte vervielfacht den Rechenaufwand gegenüber der reinen Aufnahme, weshalb die Verarbeitungslast schneller wächst als die nackte Zahl der Datenpunkte.

Die Frequenz steigt zusätzlich. Dynamische Tarife und die netzorientierte Steuerung nach Paragraf 14a erhöhen die Auslesefrequenz weiter, weil mehr Werte häufiger gebraucht werden. Was heute als Tagesvolumen tragbar erscheint, kann mit diesen Anwendungsfällen deutlich anwachsen. Eine Architektur, die nur auf den heutigen Bestand ausgelegt ist, gerät damit doppelt unter Druck, durch mehr Geräte und durch mehr Werte je Gerät.

Der Zertifikats-Lebenszyklus im Massenbetrieb

Was bei tausend Geräten Handarbeit sein kann, muss bei Millionen automatisiert laufen. Der Zertifikats-Lebenszyklus wird im Massenbetrieb zur kritischen Backend-Funktion, weil ein einziger verpasster Rollover die Kommunikation lahmlegt.

Den Anfang macht die laufende Überwachung ablaufender Zertifikate. Das Backend muss jederzeit wissen, welche Zertifikate wann auslaufen, und den Erneuerungsprozess rechtzeitig anstoßen. Darauf folgt der automatische Rollover: Das alte Zertifikat wird durch ein neues abgelöst, und in der Übergangsphase laufen altes und neues Zertifikat parallel, damit die Kommunikation nicht abreißt.

Die Kehrseite ist hart. Abgelaufene Zertifikate stoppen die Kommunikation zwischen Gateway und Backend, ohne Ausnahme. Bei Millionen Geräten wird der Rollover damit zum möglichen Single Point of Failure: Fällt die Automatik aus oder ist sie zu knapp dimensioniert, betrifft das nicht ein Gerät, sondern potenziell den ganzen Bestand. Monitoring und Alarmierung sind deshalb keine Kür, sondern Pflichtfunktionen des Backends.

Unter all dem arbeiten die Hardware-Sicherheitsmodule. Sie halten die privaten Schlüssel und führen die kryptografischen Operationen aus, von der Signatur bis zur Entschlüsselung. Im Massenbetrieb werden ihr Krypto-Durchsatz und ihre Verfügbarkeit zu Engpässen, die früh eingeplant gehören. Ein HSM, das den Spitzenlasten eines Rollovers nicht gewachsen ist, bremst den gesamten Betrieb aus, unabhängig davon, wie leistungsfähig HES und MDM sonst sind.

Eigenbetrieb oder GWA-as-a-Service

Am Ende steht eine Make-or-buy-Entscheidung. Der Skalenvorteil großer Backends ist messbar, und er drängt kleine Betreiber in die Auslagerung. Der Markt kippt sichtbar Richtung SaaS und GWA-as-a-Service.

Die Plattformen werben mit Größe. SaaS-Anbieter administrieren über eine Million Messsysteme pro Umgebung, und kleine Messstellenbetreiber lagern zunehmend aus, weil sie diese Skalierung allein nicht erreichen. Das schlägt sich in den Quoten nieder: Große Messstellenbetreiber erreichen höhere Rollout-Quoten als sehr kleine, zuletzt 27,1 gegen 14,6 Prozent. Wer mehr Geräte effizient administriert, kommt im Rollout schneller voran.

Der Eigenbetrieb hat trotzdem sein Gewicht. Er bietet Datenhoheit und Souveränität, weil die Werte und das Schlüsselmaterial im eigenen Haus bleiben. Diese Kontrolle kostet aber Skalierung: Wer selbst betreibt, muss HES, MDM, PKI-Anbindung und Hardware-Sicherheitsmodule selbst dimensionieren, betreiben und absichern. Für kleine Bestände rechnet sich das selten gegen den Skalenvorteil eines großen Dienstleisters.

Unabhängig vom Modell gilt ein Mindeststandard für die Infrastruktur. Geo-redundante, nach ISO 27001 zertifizierte Rechenzentren sind der Standard, an dem sich beide Wege messen lassen müssen. Eng verknüpft mit der Make-or-buy-Frage sind die Zertifizierungspflicht der GWA-Rolle nach TR-03109-6, der GWA-Wechsel im Massengeschäft, die KI-gestützte Beschleunigung des Rollouts sowie der finanzielle Rahmen aus der MsbG-Novelle 2025.

Was Unternehmen jetzt tun sollten

Wer das Backend auf die Zielgröße von 2030 dimensioniert statt auf den heutigen Bestand, vermeidet teure Nachrüstung. Aus den Anforderungen an Architektur, Sicherheit und Betrieb lässt sich eine konkrete Handlungsliste ableiten.

• Kapazität auf die Zielgröße auslegen: die Backend-Kapazität von HES und MDM auf die Zielgerätezahl 2030 und 2032 dimensionieren, nicht auf den aktuellen Bestand, damit der Hochlauf ohne teure Nachrüstung gelingt.
• Zertifikats-Lebenszyklus automatisieren: Überwachung ablaufender Zertifikate, automatischen Rollover und den Parallelbetrieb von altem und neuem Zertifikat einrichten, damit kein verpasster Rollover die Kommunikation stoppt.
• Make-or-buy ehrlich rechnen: den Skalenvorteil eines GWA-as-a-Service gegen die Datenhoheit des Eigenbetriebs abwägen und beide Wege gegen geo-redundante, nach ISO 27001 zertifizierte Rechenzentren messen.
• HSM, WAN und Konformität in die Roadmap aufnehmen: die Kapazität der Hardware-Sicherheitsmodule und des WAN sowie die TR-03109-6-Konformität früh einplanen, damit Sicherheit und Erreichbarkeit nicht zum Flaschenhals werden.

Weiterführende Informationen

Häufig gestellte Fragen