Smart-Meter-Rollout 2026: Warum Stadtwerke ohne Lakehouse die BNetzA-Frist reißen

Pexon Consulting | 11 Min. Lesezeit | 15.06.2026

TL;DR

Stadtwerke vor der März-2026-BNetzA-Aufsicht: Die klassische IS-U-Welt verarbeitet das SMGW-Daten-Volumen nicht produktionsreif. Microsoft Fabric als Lakehouse läuft parallel zu SAP und stemmt die §29-MsbG-Reporting-Pflicht plus BSI-Konformität. Pexon Consulting baut diese Pipelines seit 2024 als 8-Wochen-Festpreis-Sprint zwischen 55 und 95k EUR mit dokumentiertem TR-03109-Compliance-Nachweis.

Die BNetzA-Lage im März 2026 nüchtern betrachtet

Wir hören das aktuell wöchentlich in IT-Leiter-Erstgesprächen bei kleinen und mittelgroßen Stadtwerken: „Wir haben die Smart-Meter-Roll-out-Quote bisher nicht aus eigener Kraft erreicht. Die BNetzA hat ihre Aufsichts-Welle für März 2026 angekündigt — wir müssen jetzt liefern.“

Die Lage strukturiert. Das Messstellenbetriebsgesetz (MsbG) verpflichtet seit 2017 Messstellenbetreiber zum stufenweisen Smart-Meter-Roll-out — verstärkt seit Mai 2023 durch das GNDEW (Gesetz zum Neustart der Digitalisierung der Energiewende). Die Pflicht-Einbauquoten für Pflichteinbaufälle (Verbrauch über 6.000 kWh oder PV-Erzeugung über 7 kW) wurden auf 95% bis Ende 2025 angehoben, plus die freiwilligen Einbaufälle.

Der Realitätsabgleich: Branchenweit liegt die Quote Anfang 2026 deutlich unter Plan — in einigen Stadtwerken bei 20-35%, statt der gesetzlich verlangten 95%. Die BNetzA hat ihre Aufsichts-Initiative für März 2026 angekündigt. Wer die Quote nicht erreicht hat, kommt ins Aufsichtsverfahren und muss konkrete Maßnahmen plus Zeitplan vorlegen.

Das technische Engpass-Thema dabei: Viele Stadtwerke können die SMGW-Daten nicht produktiv verarbeiten. Selbst wenn die Geräte verbaut wären — die Daten landen nicht in einer auswertbaren Schicht. Das ist die Lücke, die ein Lakehouse-Setup schließt.

Warum die klassische IS-U-Welt strukturell nicht trägt

SAP IS-U und klassische EDM-Tools sind seit den 1990ern auf Monats- oder Tages-Werte ausgelegt. Smart-Meter-Daten brechen drei Annahmen.

Annahme 1: Daten kommen periodisch in Batches. IS-U geht von monatlichen Ablesungen mit etwa 12 Werten pro Zählpunkt pro Jahr aus. Smart-Meter liefern 96 Werte pro Tag (15-Minuten-Granularität) = 35.040 Werte pro Zählpunkt pro Jahr. Bei 50.000 SMGW sind das 1,75 Milliarden Datenpunkte jährlich — eine Größenordnung, die klassische IS-U-Datenbanken nicht performant verarbeiten.

Annahme 2: Werte sind manuell prüfbar. IS-U-Prozesse setzen auf manuelle Sichtprüfung und Korrektur bei Auffälligkeiten. Bei Smart-Meter-Volumen nicht möglich — Plausibilitätsprüfung muss als Pipeline-Schritt laufen, nicht als Sachbearbeiter-Workflow.

Annahme 3: Reporting läuft auf aggregierten Werten. Die klassische Monats-Sicht reicht nicht für die BNetzA-Reporting-Pflicht. Die Aufsicht will Lastgänge pro Zählpunkt-Klasse, Roll-out-Quoten pro Pflicht-Typ, Verbrauchs-Profile pro Kundengruppe. Dafür braucht es eine Lakehouse-Schicht, die die Roh-Werte vorhält und beliebig aggregiert.

Die ehrliche Antwort: IS-U weiter für Abrechnung und Vertrags-Management. Lakehouse parallel für die Mess-Daten-Verarbeitung und BNetzA-Reporting.

Was Microsoft Fabric strukturell anders macht

Drei Kern-Komponenten, die für die SMGW-Daten-Verarbeitung passen.

Eventstream für SMGW-Ingest. Smart Meter Gateways liefern Daten in der Regel über sichere Verbindungen an den Messstellenbetreiber. Fabric Eventstream ingestiert diese Datenströme aus Event Hubs, Kafka oder direkt aus dem TR-03109-konformen Gateway-Backend. Bei einem Stadtwerk-Pilotkunden verarbeitet die Pipeline aktuell 8 Millionen Events pro Tag mit Sub-Sekunden-Latenz.

OneLake als zentraler Storage. Alle Mess-Daten landen in OneLake — in Delta-Lake-Format mit Z-Ordering auf Zeitstempel und Zählpunkt-ID. Damit sind Time-Series-Anfragen performant und das Audit-Trail-Versionierung kostenlos dabei.

Power BI für BNetzA-konforme Reports. Die Berichte werden als Direct-Lake-Modelle auf OneLake aufgesetzt. Aufsichts-Berichte für die BNetzA lassen sich aus den gleichen Daten generieren wie operative Werks-Sichten. Mehr zur breiten Fabric-Pro-Contra-Bewertung im Mittelstand.

Die Architektur in der Übersicht

Bronze-Layer — Rohdaten. Jeder eingehende Event landet unverändert mit Eingangs-Zeitstempel. Bei Audit-Anfragen oder Plausibilitäts-Streits ist das die Quelle der Wahrheit. Aufbewahrung gesetzlich vorgeschrieben — wir setzen typisch 7-10 Jahre.

Silver-Layer — Plausibilisierung. Hier laufen die Validierungs-Schritte: Ausreißer-Detection, Plausibilität gegen Profil-Daten, Lücken-Behandlung (mit dokumentierter Schätzungs-Methodik). Bei einem Stadtwerk-Pilotkunden haben wir 7 Plausibilitäts-Regeln implementiert, die in Summe 0,3-0,8% der Werte als auffällig markieren.

Gold-Layer — Aggregate für Reports. Tages-, Wochen-, Monats-Aggregate für die verschiedenen Reporting-Pflichten. BNetzA-Roll-out-Quoten pro Pflicht-Kategorie, EDM-konforme Lastprofile, Verbrauchs-Klassen-Auswertung.

# Beispiel: Plausibilitätsprüfung für SMGW-Werte in Delta Live Tables
import dlt
from pyspark.sql.functions import col, lag, abs, when
from pyspark.sql.window import Window

@dlt.table(name="silver_smgw_measurements_validated")
def silver_smgw_measurements_validated():
    window_spec = Window.partitionBy("measurement_point_id").orderBy("timestamp")
    
    return (
        dlt.read("bronze_smgw_measurements")
        .withColumn("prev_value", lag("kwh_consumed", 1).over(window_spec))
        .withColumn(
            "plausibility_flag",
            when(col("kwh_consumed") < 0, "negative_consumption")
            .when(col("kwh_consumed") > col("prev_value") * 10, "spike_detected")
            .when(col("kwh_consumed").isNull(), "gap_detected")
            .otherwise("valid")
        )
    )

Der Compliance-Layer: TR-03109 und BSI-Anforderungen

Wo es bei Stadtwerk-Setups besonders eng wird.

TR-03109 ist der BSI-Standard für SMGW-Kommunikation. Daten verlassen das Gateway über kryptographisch gesicherte Verbindungen, die Schlüsselverwaltung läuft über das Smart-Meter-Gateway-Administrator-Konzept. Bis hier hin ist die Compliance in den meisten Stadtwerken etabliert — der Gateway-Administrator ist meist ausgelagert (Stadtwerke-Verbund, externer Dienstleister).

Die Lücke beginnt im Lakehouse-Layer. Daten, die nach der TR-03109-Strecke im Lakehouse landen, müssen weiterhin den BSI-Schutzzielen entsprechen. Konkret bedeutet das.

• Verschlüsselung at Rest. OneLake-Storage mit Customer-Managed Keys aus Azure Key Vault.
• Verschlüsselung in Transit. Alle Pipeline-Verbindungen über Private Endpoints, kein einziger Public-IP-Endpunkt.
• Identity-Layer mit Audit-Trail. Wer hat wann welche Daten gelesen — analog zum Multi-Tenant-Permission-Layer-Pattern in RAG-Setups.
• Datenresidenz Deutschland oder EU. Region-Lock auf Germany West Central oder West Europe.
• Aufbewahrungs-Konformität. Strukturierte Löschung nach gesetzlicher Aufbewahrungs-Frist mit dokumentiertem Lösch-Konzept.

Diese Anforderungen lassen sich auf der Fabric-Architektur sauber abbilden — die meisten sind Standard-Pattern. Wir liefern den BSI-Konformitäts-Nachweis als Sprint-Bestandteil. Mehr zum breiten Compliance-as-Code-Pattern für regulierte AI-Workloads.

Pexon-Sprint im Detail

8-Wochen-Festpreis-Sprint:

• Wochen 1-2 — Discovery und Architektur. Inventur SMGW-Stand, Gateway-Administrator-Anbindung, IS-U-Schnittstellen, BSI-Konformitäts-Workshop mit IT-Leiter und Datenschutzbeauftragten. Architektur-Skizze.
• Wochen 3-4 — Ingest-Pipeline. Eventstream-Setup, Bronze-Layer mit voller TR-03109-Konformität, Initial-Ingest von Bestands-Daten.
• Wochen 5-6 — Silver/Gold + IS-U-Sync. Plausibilitäts-Pipeline, BNetzA-Aggregate, Sync-Schicht zur IS-U für Abrechnungs-Relevanz.
• Wochen 7-8 — Reports, BSI-Doku, Übergabe. BNetzA-konforme Reports, BSI-Konformitäts-Doku, Schulung IT-Team plus Aufsichts-Verantwortliche.

Investment-Festpreis: 55-95k EUR je nach Komplexität. Untere Spanne bei klar fokussiertem Setup (< 30.000 SMGW, eine Gateway-Administrator-Welt). Obere Spanne bei größeren Setups (> 100.000 SMGW, mehrere Administratoren, komplexe IS-U-Landschaft).

Laufende Cloud-Kosten: Fabric-Capacity F4 für mittelgroße Stadtwerke typisch 1.200-2.800 EUR pro Monat inkl. Storage. Bei sehr großen Setups (> 500.000 SMGW) eher F8 mit 2.800-4.500 EUR pro Monat.

Was nach dem Sprint noch ansteht

Ehrlicher Blick: Der 8-Wochen-Sprint stellt die Daten-Schicht produktiv und liefert die BNetzA-Reporting-Basis. Drei Folgethemen sind typisch.

Folgethema 1: Lastganganalyse für dynamische Tarife. Sobald die Daten in der Lakehouse-Schicht liegen, sind dynamische Tarif-Modelle berechenbar — Zeit-, Last-, Erzeugungs-abhängige Tarife. Hebel für Kunden-Bindung und neue Geschäftsmodelle. Typisch 4-6-Wochen-Folge-Sprint.

Folgethema 2: Netzzustandsschätzung im Niederspannungs-Netz. Mit Smart-Meter-Daten lässt sich der Netzzustand in Echtzeit modellieren — wichtig für die Steuerung des Verteilnetzes mit zunehmenden PV-Einspeisungen. Aufwändigeres Engineering, typisch 12-16 Wochen.

Folgethema 3: BNetzA-Aufsichtsverfahren-Begleitung. Wenn die Aufsicht das Verfahren eröffnet, brauchen Stadtwerke kompetente fachliche Begleitung. Pexon kombiniert hier mit Branchen-Rechtsanwälten zu einer strukturierten Verfahrens-Begleitung. Mehr zur Compliance-Architektur in regulierten AI-Workloads.

Häufig gestellte Fragen

Was wenn unser SMGW-Roll-out gerade erst startet?

Häufiger Fall bei kleinen Stadtwerken. Die Lakehouse-Architektur ist parallel zum Roll-out aufsetzbar — ihr ingestiert anfangs nur einige hundert Geräte, skaliert mit jeder Roll-out-Welle. Wichtig: Architektur muss von Anfang an auf das Zielvolumen ausgelegt sein, sonst kommen 18 Monate später teure Re-Engineering-Kosten.

Können wir den Sprint mit unserem bestehenden EDM-System parallelisieren?

Ja. Wir orchestrieren das so, dass das EDM weiterläuft und die Lakehouse-Schicht parallel die SMGW-Daten verarbeitet. Im zweiten Jahr typisch Sync-Schicht für Stamm- und Vertrags-Daten. Komplette Ablösung des EDM ist nicht typisches Sprint-Ziel — Lakehouse erweitert, nicht ersetzt.

Was wenn der Gateway-Administrator nicht kooperiert?

Häufiges Pattern in Stadtwerke-Verbünden mit mehreren Administratoren. Wir machen das vor Sprint-Start zum Discovery-Punkt — Verträge mit den Administratoren prüfen, technische Schnittstellen klären, ggf. Eskalation auf Verbund-Ebene. Bei klaren vertraglichen Lücken ist das ein separater Klärungs-Pfad vor dem technischen Sprint.

Wie verhält sich das bei sehr kleinen Stadtwerken (< 10.000 SMGW)?

Bei kleinen Stadtwerken empfehlen wir oft Managed-Cooperation-Modelle (Datenverarbeitung beim Verbund oder Stadtwerke-Cooperative), nicht eigene Lakehouse-Infrastruktur. Die Wirtschaftlichkeit kippt bei < 10.000 SMGW typisch nicht. Bei 10.000-30.000 SMGW ist Eigenbetrieb möglich, aber muss durchgerechnet werden.

Wie verhält sich Fabric vs Databricks für Smart-Meter-Daten?

Beide Plattformen können die Daten verarbeiten. Wir empfehlen für Stadtwerke meist Fabric, weil die Microsoft-Stack-Integration (Power BI, Entra ID, Microsoft Teams für Aufsichts-Berichte) in der Regel passt. Bei Stadtwerken mit existierendem AWS- oder reinem Datenwissenschafts-Setup kann Databricks die bessere Wahl sein — siehe Plattform-Vergleich am Beispiel OEE-Dashboards.

Wir haben die Roll-out-Quote schon erreicht — brauchen wir das trotzdem?

Ja, sobald ihr die Geräte produktiv habt. Die Datenmenge fließt in jedem Fall — entweder verarbeitet ihr sie strukturiert oder die Daten liegen ungenutzt im Gateway-Backend. Wir sehen den Hebel dann eher bei dynamischen Tarifen, Netzzustand und Kundenbindung.

Nächster Schritt

Wenn euer Stadtwerk oder Verteilnetzbetreiber vor der BNetzA-Aufsichts-Welle März 2026 steht und das Smart-Meter-Daten-Volumen nicht in eine BNetzA-konforme Reporting-Schicht bringt: Wir machen einen 60-Minuten-Discovery-Call mit dir und idealerweise dem IT-Leiter plus Aufsichts-Verantwortlichen. Du beschreibst die Roll-out-Lage und die IS-U-Welt, wir skizzieren den 8-Wochen-Sprint mit Festpreis.

Verwandte Themen