Netzengpass-Ursachenanalyse (nichtlinear)

Das echte Ausmaß des Problems

Deutschland gab 2023 rund 3,1 Milliarden Euro für Netzengpassmanagement aus — Redispatch konventioneller und erneuerbarer Anlagen sowie Countertrading zusammen, auf rund 34.000 GWh Maßnahmenvolumen. Laut der Bundesnetzagentur-Transparenzplattform SMARD stammten dabei rund 42 Prozent des eingespeisten erneuerbaren Volumens aus Anlagen, die ans Verteilnetz angeschlossen sind — obwohl 80 Prozent der ursächlichen Engpässe im Übertragungsnetz lagen. Das zeigt das eigentliche Problem: Verteil- und Übertragungsnetz interagieren, und die Ursachen sind selten dort, wo die Symptome auftreten.

Auf Verteilnetzebene wächst der Druck schnell: Zwischen 2020 und 2025 hat sich die installierte PV-Leistung im deutschen Verteilnetz auf über 75 GW mehr als verdoppelt. Gleichzeitig nehmen Wärmepumpen (heute rund 1,6 Millionen installierte Geräte) und Elektrofahrzeuge (über 1,5 Millionen Pkw, Stand 2025) die Netze von der Lastseite her in die Zange. Die Besonderheit: Alle drei Technologien reagieren auf Wetter und Tageszeit — und erzeugen damit Gleichzeitigkeitseffekte, die klassische Planungstools systematisch unterschätzen.

Die klassische Lastflussrechnung — das Werkzeug, mit dem Netzplaner seit Jahrzehnten Engpässe berechnen — basiert auf linearen Vereinfachungen (DC-Näherung) und deterministischen Szenarien. Das N-1-Kriterium (“Das Netz muss auch nach Ausfall einer beliebigen Komponente sicher betreibbar sein”) ist für einzelne Hochlastsituationen robust — aber es sagt nichts darüber, welche Kombination aus Einspeisern, Lasten und Schaltzuständen den Engpass in der Praxis tatsächlich ausgelöst hat. Und je mehr dezentrale Erzeuger und steuerbare Lasten ins Netz kommen, desto mehr Kombinationseffekte gibt es — und desto weniger helfen lineare Szenarien weiter.

Was das für die Netzplanung bedeutet:

• Ursachenanalysen nach Engpassereignissen dauern bei manueller SCADA-Auswertung typisch 3–15 Arbeitstage je nach Komplexität
• Ohne klare Ursachenzuordnung können Netzausbaumaßnahmen nicht sicher priorisiert werden — es wird dort verstärkt, wo zuletzt ein Ereignis stattfand, nicht unbedingt dort, wo die Ursache liegt
• Redispatch-Maßnahmen werden reaktiv ausgelöst, nicht präventiv geplant — was die Kosten erhöht
• Die Frage “War das ein Einzelereignis oder ein Systemmuster?” bleibt oft unbeantwortet

Mit vs. ohne KI — ein ehrlicher Vergleich

Der deutlichste Effekt liegt nicht in der Kosteneinsparung, sondern in der Erkenntnisqualität: Netzplanerinnen wie Miriam erhalten erstmals eine statistisch belastbare Antwort auf die Frage, welche Treiberkombinationen wirklich riskant sind — und können Netzausbaumaßnahmen damit datenbasiert begründen statt auf Erfahrungswerte zu verweisen.

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5)
Der stärkste messbare Hebel dieses Ansatzes. Was bisher 3–15 Arbeitstage SCADA-Auswertung erforderte, liefert eine trainierte ML-Pipeline in 2–8 Stunden — inklusive SHAP-basierter Treiber-Erklärung und automatischer Plausibilisierung gegen das Netzmodell. Für ein Team, das mehrere Engpassereignisse pro Quartal auswertet, summiert sich das schnell auf Wochen eingesparter Analysezeit pro Jahr. Damit gehört dieser Use Case zu den zeitlich stärksten im Energie-Bereich.

Kosteneinsparung — niedrig (2/5)
Dieser Ansatz reduziert Redispatch-Kosten nicht direkt — er macht die Ursachen sichtbar, aber das Beheben der Ursachen (Netzausbau, Flexibilitätssteuerung) ist ein separater Schritt mit eigenem Budget und langen Umsetzungszeiten. Der wirtschaftliche Hebel liegt in besserer Priorisierung von Netzausbaumaßnahmen: Weniger unnötige Verstärkungen, gezielterer Einsatz von Investitionsbudget. Dieser indirekte Effekt ist real, aber schwer isoliert messbar — weshalb die Einstufung trotz der hohen absoluten Zahlen beim deutschen Redispatch niedrig bleibt.

Schnelle Umsetzung — sehr niedrig (1/5)
Einer der aufwendigsten Einstiege in der gesamten Energie-Kategorie: SCADA-Datenintegration mit ausreichender zeitlicher Auflösung, Aufbau eines CIM-konformen digitalen Netzmodells, historische Datenbereinigung, ML-Pipeline-Entwicklung, physikalische Validierung, Einbindung in den Planungsprozess — das ist ein 6–12-Monats-Projekt für ein Team mit Power-Systems-Engineering- und Data-Science-Kompetenz. Keine Lösung für eine schnelle Pilotierung über Nacht.

ROI-Sicherheit — niedrig (2/5)
Der ROI hängt davon ab, ob die ML-Erkenntnisse tatsächlich zu besseren Netzausbauinvestitionen führen — und das ist ein Folgeentscheidungsprozess, der von Regulatorik, Budgetzyklen und Planungsfristen beeinflusst wird. Ein Redispatch-Kosteneinsparungsnachweis, der direkt auf die KI-Ursachenanalyse zurückzuführen ist, ist methodisch komplex und selten möglich. Der ehrliche ROI-Fall: “Wir haben einen 2-Millionen-Euro-Netzausbau gespart, weil die Analyse zeigte, dass die eigentliche Ursache woanders liegt” — aber dieser Zusammenhang bleibt von Planern für Planer, nicht für den CFO.

Skalierbarkeit — niedrig (2/5)
Ein Modell, das für eine bestimmte Netztopologie trainiert wurde, lässt sich nicht ohne erneutes Training auf eine andere Topologie übertragen. Jede neue Umspannstation, jede neue Stichleitung, jede Topologieänderung durch Schaltoperationen kann die gelernten Muster entwerten. Das ist strukturell anders als softwarebasierte Use Cases, die einmal deployed skalieren. Für einen TSO mit stabiler Übertragungsnetztopologie ist die Situation günstiger; für DSOs mit schnell wachsendem dezentralem Netz ist Skalierbarkeit die größte praktische Herausforderung.

Richtwerte — stark abhängig von Netzgröße, SCADA-Datenqualität und vorhandener Modellierungsinfrastruktur.

Warum N-1-Analyse allein nicht mehr ausreicht

Das N-1-Kriterium war für das Netz des 20. Jahrhunderts konzipiert: wenige große Kraftwerke, stabile Lastkurven, vorhersehbare Engpasspunkte. In diesem Netz funktioniert die lineare Näherung gut — Stromflüsse sind näherungsweise proportional zu Einspeisungen, und ein Worst-Case-Szenario (“volle Last, schlechtester Einspeisefall”) ist ausreichend konservativ.

Mit dezentralen erneuerbaren Energien und steuerbaren Lasten gilt das nicht mehr:

Problem 1: Kombinatorische Explosion. Ein Verteilnetz mit 50 PV-Anlagen, 200 Wärmepumpen und 100 Ladestationen hat astronomisch viele mögliche Gleichzeitigkeitszustände. Eine deterministische Szenarienrechnung kann diese Menge nicht abdecken — sie muss repräsentative Szenarien auswählen, und dabei gehen genau die seltenen Randfälle verloren, die in der Praxis Engpässe verursachen.

Problem 2: Nichtlineare Wechselwirkungen. Reaktive Leistung, Spannungsabhängigkeit von Lasten und die Rückkopplung zwischen Einspeiserspannung und Netzspannung sind nichtlineare Effekte. Ein DC-Lastflussmodell (die gängige Vereinfachung) bildet sie nicht ab — und genau diese Nichtlinearitäten sind es, die erklären, warum ein Engpass bei 80 % PV-Einspeisung plus 40 % Wärmepumpen-Gleichzeitigkeit auftritt, aber nicht bei 100 % PV-Einspeisung allein.

Problem 3: Temporale Kausalität. Engpässe entstehen nicht instantan — sie haben Vorläufer. Ein Spannungsabfall 15 Minuten vor der Überlast, ein Anlaufen von Pumpen nach einem Netzspannungseinbruch, ein koordinierter Ladebeginn von EV-Wallboxen nach 15:00 Uhr. Diese zeitlichen Muster sind in SCADA-Zeitreihen vorhanden, aber für manuelle Analyse unsichtbar.

Machine Learning — konkret: Gradient-Boosting-Verfahren mit erklärbaren Attributionsmethoden (SHAP), Graph Neuronale Netze oder Deep Learning-basierte Zeitreihenanalyse — kann diese drei Probleme systematisch angehen, weil es direkt auf den historischen Betriebsdaten trainiert, ohne auf Linearisierungen angewiesen zu sein.

Was das System konkret macht

Ein ML-gestütztes Ursachenanalysesystem für Netzengpässe arbeitet typisch in vier Schritten:

Schritt 1 — Ereignis-Labeling.
Alle historischen Engpassereignisse aus den SCADA-Protokollen werden als positive Klasse markiert. Für jedes Ereignis wird ein Zeitfenster (z.B. 4 Stunden vor bis 1 Stunde nach dem Ereignis) extrahiert. Zeiträume ohne Engpass bilden die negative Klasse. Das Ergebnis: ein Trainingsdatensatz mit mehreren Tausend Zeitschritten, bei denen bekannt ist, ob ein Engpass folgte oder nicht.

Schritt 2 — Feature Engineering.
Aus SCADA-Zeitreihen werden relevante Merkmale abgeleitet: Einspeiseleistung je PV-Anlage, Laststrom je Kabel, Wirkleistung und Blindleistung an Messstellen, Außentemperatur, Globalstrahlung, Tageszeit, Wochentag, Netz-Schaltzustand. Für Graph-Neuronale-Netze wird zusätzlich die Netztopologie als gerichteter Graph codiert — jeder Knoten (Umspannstation, Hausanschluss) und jede Kante (Kabel, Transformator) wird als Feature dargestellt.

Schritt 3 — Modelltraining und Erklärung.
Ein Gradient-Boosting-Modell (z.B. XGBoost oder LightGBM, implementiert über scikit-learn) wird trainiert, den Zeitpunkt eines Engpassereignisses zu klassifizieren. Entscheidend ist dabei nicht nur die Vorhersagegenauigkeit, sondern die SHAP-Wert-Analyse (SHapley Additive exPlanations): Für jedes Ereignis zeigt SHAP, welche Features wie stark zur Engpass-Klassifikation beigetragen haben. Das Ergebnis ist eine ranggeordnete Liste von Treibern — “PV-Einspeisung Anlage A47 hat in 73 % der Ereignisse positiv zum Engpass beigetragen, wenn gleichzeitig Wärmepumpenlast >65 %.”

Schritt 4 — Physikalische Validierung.
Die identifizierten Treiberkombinationen werden anschließend in einem Lastfluss-Tool (z.B. pandapower oder DIgSILENT PowerFactory) nachgerechnet, um zu prüfen, ob das ML-Muster physikalisch plausibel ist. Dieser Schritt ist nicht optional — er verhindert, dass statistische Korrelationen als kausale Muster missverstanden werden. Das Modell kann eine Korrelation mit Außentemperatur finden, die eigentlich Lastverhalten widerspiegelt; der Lastfluss zeigt, ob das auch mechanistisch stimmt.

Für größere Netze mit komplexer Topologie (viele Schaltoptionen, mehrere Spannungsebenen) können physikbasierte Graph Neuronale Netze (Deep Learning auf dem Netzgraph) das Gradient-Boosting-Modell ersetzen — sie lernen direkt auf dem Netzgraphen und müssen keine Features manuell extrahieren. Akademische Studien (arXiv 2503.22721: “PowerGNN”, 2025) zeigen 37-fache Beschleunigung gegenüber klassischer Lastflusssimulation bei vergleichbarer Genauigkeit — das ist für Echtzeit-Anwendungen relevant, für retrospektive Ursachenanalyse aber nicht der primäre Vorteil.

Datenbasis: Was das ML-System wirklich braucht

Das ist die Sektion, die in vielen KI-Projekten zu spät diskutiert wird — und dann zum Projektabbruch führt.

Mindestanforderung 1 — SCADA-Zeitreihen mit ausreichender Auflösung.
15-Minuten-Mittelwerte, wie sie für die BNetzA-Transparenzpflichten ausreichend sind, reichen für Ursachenanalyse nicht aus. Für die Erkennung von Gleichzeitigkeitseffekten bei Wärmepumpen (die innerhalb von Minuten anlaufen) und EV-Ladestationen (die in Gruppen nach 15:00 Uhr starten) braucht es mindestens 1-Minuten-Auflösung, besser 10-Sekunden. Nicht alle SCADA-Systeme speichern diese Auflösung über mehr als 30–90 Tage — das muss vor Projektstart geprüft werden.

Mindestanforderung 2 — Digitales Netzmodell (CIM-konform).
Ein Common Information Model (CIM, IEC 61970/61968) des betroffenen Netzbereichs ist Voraussetzung für die physikalische Validierung. Ohne ein maschinenlesbares Netzmodell gibt es keine Grundlage, ML-Muster gegen Lastflussergebnisse zu prüfen. Viele kleine DSOs haben ihr Netzmodell in GIS-Systemen (Geographic Information Systems), aber nicht in einem Format, das direkt in pandapower oder DIgSILENT PowerFactory importierbar ist — die Konvertierung ist ein eigenständiges Teilprojekt.

Mindestanforderung 3 — Historische Ereignisdichte.
Für ein statistisch belastbares Modell braucht man mindestens 20–50 dokumentierte Engpassereignisse in dem betrachteten Netzbereich. Bei kleineren DSOs mit weniger als 5–10 Ereignissen pro Jahr über 3 Jahre hinweg ist der Datensatz für zuverlässiges Musterlernen zu dünn. Das Modell wird dann nominell gute Klassifikationsergebnisse zeigen (weil es wenige Events gibt, die es einzuprägen hat), aber nicht generalisieren.

Mindestanforderung 4 — Externe Kontextdaten.
PV-Einspeisung, Außentemperatur, Globalstrahlung und — wo verfügbar — Smart-Meter-Daten oder Aggregatdaten von Wärmepumpenanbietern müssen mit SCADA-Zeitreihen zeitsynchronisiert vorliegen. Fehlende oder zeitverschobene Kontextdaten sind die häufigste Ursache dafür, dass Modelle nur oberflächliche Korrelationen (Tageszeit, Wochentag) lernen, nicht die eigentlichen Treiber.

Konkrete Werkzeuge — was wann passt

Es gibt keinen einzigen Softwareanbieter, der “KI-Netzengpass-Ursachenanalyse” als Fertiglösung verkauft. Der Ansatz erfordert eine Kombination aus Power-Systems-Tools und ML-Infrastruktur — typisch als Python-basierter Stack.

pandapower — für Lastfluss-Simulation und Datengenerierung
Das Open-Source-Fundament. pandapower berechnet AC-Lastflüsse auf realen Netzmodellen, erzeugt synthetische Trainingsdaten für seltene Szenarien, die in historischen SCADA-Daten fehlen, und validiert ML-Erkenntnisse gegen die Netzphysik. Kostenlos, Python-nativ, CIM-Import unterstützt. Einstieg für DSOs und Planungsbüros, die ohne sechsstellige Lizenzkosten prototypisieren wollen.

DIgSILENT PowerFactory — für industriellen Validierungsstandard
Wenn die ML-Erkenntnisse in eine regulatorische Unterlage eingehen oder Netzausbaubeschlüsse begründen sollen, ist DIgSILENT PowerFactory die verlässlichere Grundlage für die physikalische Validierung. Die Python-API von PowerFactory ermöglicht eine vollständig automatisierte Validierungspipeline: ML-Treibermuster werden als PowerFactory-Szenarien durchgerechnet, und die Ergebnisse fließen direkt zurück in die Analyse. Kosten: 30.000–60.000 € Basislizenz + Schulung, sinnvoll wenn PowerFactory ohnehin im Betrieb ist.

scikit-learn + Python-Ökosystem — für ML-Modellentwicklung
XGBoost oder LightGBM (beide über scikit-learn-API nutzbar) sind für tabellare Zeitreihendaten aus SCADA-Logs der robusteste Startpunkt. Sie trainieren auf modernen Laptops in Minuten, liefern sofort SHAP-Werte zur Erklärung und sind für Power-Systems-Ingenieure ohne Deep-Learning-Hintergrund greifbar. PyTorch-basierte Graph Neuronale Netze sind für Netze mit komplexer Topologie überlegen, aber erfordern wesentlich mehr ML-Expertise.

MLflow — für Experiment-Tracking und Modellverwaltung
Sobald mehrere Netzabschnitte analysiert und verschiedene Modellversionen verglichen werden, ist strukturiertes Experiment-Tracking unverzichtbar. MLflow protokolliert Hyperparameter, Metriken und Modell-Artifacts, ermöglicht Vergleiche zwischen Topologie-spezifischen Modellen und macht den Re-Training-Zyklus nach Topologieänderungen reproduzierbar. Kostenlos, auf dem eigenen Server deploybar.

Zusammenfassung: Wann welcher Ansatz

• Prototyp auf eigener Infrastruktur, begrenzte Topologie → pandapower + scikit-learn
• Regulatorisch verwendbare Validierung → DIgSILENT PowerFactory + Python-API
• Komplexe Netztopologie, viele Schaltoptionen → PyTorch + Graph Neural Network
• Mehrere Netzabschnitte, laufende Modellpflege → alle obigen + MLflow für Tracking

Datenschutz und Datenhaltung

Netzengpass-Ursachenanalyse arbeitet primär mit betrieblichen Messdaten (Spannungen, Ströme, Leistungen, Schaltzustände) — keine personenbezogenen Daten im klassischen Sinne. Die DSGVO-Relevanz ist dennoch vorhanden:

Smart-Meter-Daten und Haushaltslastprofile — Falls disaggregierte Smart-Meter-Daten oder individuelle Wärmepumpen-Telemetrie in die Analyse einfließen, handelt es sich um personenbezogene Daten (verbrauchsbezogene Informationen von Haushalten sind nach EuGH-Rechtsprechung personenbezogen). Hier braucht es eine Rechtsgrundlage (typisch: berechtigtes Interesse nach Art. 6 Abs. 1 lit. f DSGVO für die Netzbetreiber-Aufgabe der Netzplanung) und bei externen Dienstleistern einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO.

Aggregierte Netzmessdaten — Betriebsmessungen ohne Haushalts-Identifikation (Sammelschienenmessungen, Kabelstrommessungen) sind in der Regel keine personenbezogenen Daten. Trotzdem: Bei KRITIS-regulierten Netzbetreibern gelten besondere Anforderungen an die Verarbeitung von Netzbetriebsdaten — IT-Sicherheitsgesetz 2.0, NIS-2-Richtlinie (Umsetzung in Deutschland bis Oktober 2024 vorgeschrieben) und BDEW-Whitepaper zur IT-Sicherheit in der Energiewirtschaft.

Werkzeug-Empfehlung für KRITIS-Kontext:

• pandapower und DIgSILENT PowerFactory sind Desktop-/On-Premise-Tools — keine Daten verlassen den eigenen Server. Geeignet für KRITIS-Betreiber.
• Cloud-basiertes ML (AWS SageMaker, Azure ML) erfordert explizite Prüfung nach BDEW-Whitepaper und mögliche Genehmigung nach §8a BSIG. Viele TSOs und große DSOs haben interne Richtlinien, die externe Cloud-Verarbeitung von SCADA-Daten ausschließen.
• Self-hosted MLflow auf eigenem Server oder VM in deutscher/EU-Cloud: konforme Option für das Experiment-Tracking.

Empfehlung: Bevor ein externer Data-Science-Dienstleister SCADA-Daten erhält, sollte ein Datenschutzbeauftragter die Datenkategorien prüfen und einen AVV-Rahmen vorschlagen. Das ist keine bürokratische Hürde, sondern für KRITIS-Betreiber eine regulatorische Pflicht.

Was es kostet — realistisch gerechnet

Einmalige Projektkosten (Pilotphase, ein Netzabschnitt):

• Datenaufbereitung und SCADA-Integration: typisch 3–8 Personenmonate interner oder externer Aufwand
• Externer Data-Science-Dienstleister (falls intern keine ML-Kompetenz): 50.000–150.000 € für Konzept, Modellentwicklung und Validierung
• Lizenzen: pandapower kostenlos, DIgSILENT PowerFactory falls nicht vorhanden: 30.000–60.000 € Einstieg, MLflow kostenlos
• Gesamtpilot: 60.000–200.000 € je nach Eigenleistung und bereits vorhandener Infrastruktur

Laufende Kosten:

• Re-Training nach Topologieänderungen: typisch 2–5 Tage Data-Science-Aufwand je Änderung
• Modellüberwachung (Drift-Detection): 0,5–1 Personentag pro Monat bei aktivem Netz
• Infrastruktur (Self-hosted): vernachlässigbar bei vorhandener IT-Infrastruktur

Was du dagegenrechnen kannst:
Der direkte ROI-Case ist anspruchsvoll zu führen — aber nicht unmöglich. Ein DSO, der durch gezieltere Ursachenanalyse eine Netzausbaumaßnahme für 2–3 Millionen Euro um 3 Jahre verzögern oder durch eine günstigere Alternativmaßnahme ersetzen kann, rechnet das Projekt mehrfach zurück. Für TSOs liegt der Hebel anders: Die Zuordnung von Redispatch-Ursachen zu einzelnen Einspeisern ermöglicht präzisere Begründungen gegenüber der BNetzA und kann Regulierungsdiskussionen über Netzverstärkungs-Investitionen substanziell unterstützen.

Ehrliche Einschätzung: Die beste Rechtfertigung für dieses Projekt ist nicht der direkte ROI-Beweis, sondern die Verbesserung der Entscheidungsqualität. Netzplanungsentscheidungen in der Größenordnung von 1–10 Millionen Euro pro Einzelprojekt, die heute auf Erfahrung und Einzelereignis-Auswertungen basieren, können mit belastbareren Mustern begründet werden. Das ist ein qualitativer, aber realer Nutzen.

Drei typische Einstiegsfehler

1. Das Modell auf simulierten Daten trainieren, dann an realen SCADA-Daten scheitern.
Es ist verlockend, für das Modelltraining synthetische Szenarien aus dem Lastfluss-Simulator zu verwenden — damit bekommt man viele Trainingsdaten in kurzer Zeit. Das Problem: Simulations-Daten und echte SCADA-Messungen haben systematisch unterschiedliche Charakteristika. Messfehler, Kommunikationsausfälle, ungleichmäßige Abtastzeiten und physikalische Phänomene, die das Simulationsmodell nicht abbildet (Oberschwingungen, transienter Anlaufstrom von Wärmepumpen) sorgen dafür, dass ein auf Simulationsdaten trainiertes Modell auf echten Daten deutlich schlechter abschneidet. Lösung: Zuerst mit echten historischen SCADA-Daten arbeiten, auch wenn die Datenmenge kleiner ist. Synthetische Daten nur zur Augmentierung — nicht als primärer Trainingsdatensatz.

2. Topologieänderungen ignorieren und das Modell nie neu trainieren.
Das ist der stille Killer. Ein Modell, das auf Netzzustand 2022 trainiert wurde, “weiß” nicht, dass 2024 eine neue 20-kV-Leitung in Betrieb genommen wurde, drei Umspannwerke topologisch umgestellt wurden und 40 neue PV-Anlagen ans Netz gegangen sind. Die Muster haben sich verändert, das Modell weiß das nicht — und es wird trotzdem Ergebnisse liefern, die wie vorher aussehen. Das Muster der Ergebnisse verschlechtert sich schleichend, bis irgendwann ein offensichtlich falsches Ergebnis auffällt. Lösung: Für jeden dokumentierten Topologieeingriff und für jede signifikante neue Einspeisung > X MW muss ein Re-Training-Ticket erstellt werden. Das ist ein Prozess, kein Technikproblem — und er muss in der Rollout-Planung verankert sein, bevor das System live geht.

3. Die physikalische Validierung als optionalen Schritt behandeln.
SHAP-Werte zeigen statistische Zusammenhänge, keine Kausalitäten. Ein Modell, das trainiert auf norddeutschen Daten wird wahrscheinlich “Wind aus Nordwest” als Treiber identifizieren — aber ist das direkt kausal, oder ist es ein Proxy für hohe PV-Einspeisung und Temperaturschwankungen? Ohne Lastfluss-Validierung kann man das nicht unterscheiden. In der Praxis passiert es regelmäßig, dass ML-Modelle Scheinkorrelationen aufgreifen (Netzwartungszyklen, die zufällig mit hoher Last zusammenfallen; Wochentag-Effekte, die nichts mit der Netztechnik zu tun haben). Wer diese Ergebnisse ohne physikalische Plausibilisierung in Netzausbau-Anträge schreibt, riskiert Rückfragen der BNetzA oder falsche Investitionsentscheidungen. Lösung: Die Validierung gegen pandapower oder DIgSILENT PowerFactory ist Teil der Analysepipeline, nicht ein nachgelagerter Schritt.

Und der Fehler, der am teuersten wird:
Das Modell wird eingeführt und dann nicht gepflegt. Nicht wegen mangelnder Überzeugung, sondern weil nach dem Pilotprojekt das externe Beratungsteam abreist und kein interner Mitarbeitender dauerhaft für die Modellpflege zuständig ist. Nach 18 Monaten ist das System still veraltet, produziert Ergebnisse, die niemand mehr hinterfragt, und die nächste Netzausbauplanung stützt sich auf Muster aus 2022. Das ist schwerer zu verhindern als es klingt — es erfordert eine explizite interne Rollenzuteilung (“wer ist dauerhaft verantwortlich für dieses Modell?”) schon während des Pilotprojekts, nicht danach.

Was mit der Einführung wirklich passiert — und was nicht

Die technische Herausforderung ist lösbar. Die organisatorische Herausforderung ist größer.

Was nicht passiert: Das Modell gibt täglich Empfehlungen aus, die direkt in Redispatch-Entscheidungen eingehen. So ist dieser Anwendungsfall nicht konzipiert — die Ursachenanalyse ist retrospektiv, nicht operativ. Sie verändert nicht den Netzbetrieb am nächsten Tag, sondern die Netzplanung im nächsten Halbjahres- oder Jahresplan. Wer ein operatives Echtzeit-Eingreifsystem erwartet, ist hier falsch — dafür gibt es die Netz-Zustandsüberwachung.

Was passiert: Die Netzplanungsabteilung bekommt ein neues Analysewerkzeug, das ihre Arbeit verändert. Erfahrene Netzplanerinnen und -planer werden ihre Erfahrungswerte mit den Modell-Ergebnissen konfrontieren — manchmal stimmen sie überein, manchmal nicht. Das erzeugt Reibung: “Das Modell sagt Wärmepumpen-Gleichzeitigkeit, aber ich kenne diesen Netzteil seit 20 Jahren und weiß, dass das die alte Schaltkonfiguration war.” Diese Diskussion ist produktiv, wenn sie als Kalibrierung behandelt wird — das Modell lernt von der Erfahrung, die Erfahrung bekommt Daten-Evidenz.

Typische Widerstands-Muster:
Netzplanende mit langer Erfahrung sehen das Modell als Angriff auf ihre Fachkompetenz — was es nicht ist, aber so erlebt wird, wenn die Kommunikation das nicht klärt. Hilfreich ist, erfahrene Netzplaner aktiv in die Modellvalidierung einzubeziehen und sie als Experten für die physikalische Plausibilitätsprüfung zu positionieren: Sie entscheiden, ob ein ML-Muster Sinn ergibt. Das Modell findet Muster, der Ingenieur bewertet sie.

Was IT und OT-Abteilung vorbereiten müssen:
SCADA-Datenexport in das Analyse-System muss entweder als regelmäßiger Batch oder als Stream konfiguriert werden — das ist eine OT/IT-Grenzaufgabe, die in vielen Energieversorgern mehrere Monate dauert, weil SCADA-Systeme und IT-Netzwerke getrennt sind (Air-Gap oder Datendioden). Wer diese Abhängigkeit unterschätzt, steht nach 3 Monaten Modellentwicklung vor einer Daten-Integrationshürde, die das Projekt um weitere 6 Monate verzögert.

Realistischer Zeitplan mit Risikohinweisen

Ehrliche Einschätzung: Wer dieses Projekt mit sechs Monaten plant, hat die Datenbewertungs- und Validierungsphase unterschätzt. Realistische Erstimplementierungen liegen bei 8–14 Monaten bis zum produktiven Einsatz im Planungsprozess. Das ist kein Scheitern — es ist die richtige Erwartung für ein technisch anspruchsvolles Analysesystem.

Häufige Einwände — und was dahintersteckt

“Unsere SCADA-Daten haben nicht die nötige Qualität.”
Das ist selten ein absolutes Ausschlusskriterium, aber häufig ein Realitätscheck. Die entscheidende Frage ist: Wie viele dokumentierte Engpassereignisse gibt es in den letzten 3–5 Jahren, und in welcher Zeitauflösung wurden die Messdaten gespeichert? Falls die Antwort “unter 20 Ereignisse, 15-Minuten-Mittelwerte” lautet, ist der Ansatz tatsächlich zu früh — aber nicht weil die Idee falsch ist, sondern weil die Datenbasis erst aufgebaut werden muss. Das ist auch ein Signal: Welche Messdaten sollten jetzt besser archiviert werden, damit der Ansatz in 2 Jahren funktioniert?

“Wir haben bereits lineare Lastflussmodelle — das reicht.”
Lineare Lastflussmodelle sind ausgezeichnete Planungstools für Worst-Case-Szenarien und N-1-Prüfungen. Sie beantworten aber nicht die Frage “Welche Kombination aus Betriebszuständen hat diesen konkreten historischen Engpass verursacht?” Diese retrospektive Frage ist der Kern der Ursachenanalyse — und genau hier scheitern deterministische Modelle, weil sie keine statistische Häufigkeitsanalyse über alle historischen Zustände durchführen. Beides schließt sich nicht aus: DIgSILENT PowerFactory bleibt das Validierungstool, ML analysiert die Muster.

“Die regulatorische Anerkennung ist unklar — können wir das für BNetzA-Anträge nutzen?”
Hier ist ehrliche Einschätzung gefragt: ML-Analysen sind keine Netzberechnungen nach IEC 60364 oder VDE-AR-N 4110/4120. Sie sind Musteranalysen, die einer physikalischen Plausibilisierung durch normenkonforme Berechnungen bedürfen — genau deshalb ist der Validierungsschritt mit DIgSILENT PowerFactory oder pandapower nicht optional. Ein Netzausbauantrag, der ausschließlich auf ML-SHAP-Werten basiert, wird keine regulatorische Anerkennung erhalten. Ein Antrag, der ML-Muster als Hypothese nutzt und sie mit Lastflussergebnissen belegt, ist methodisch deutlich stärker als eine klassische Einzelfallbetrachtung.

“Das ist nur für große TSOs relevant.”
Nein — das Kernproblem ist auf Mittelspannungsebene bei DSOs mit hoher dezentraler Einspeisung mindestens genauso relevant. Netzengpässe in 20-kV-Netzen mit hoher PV-Dichte sind heute das häufigere Problem als Übertragungsnetz-Engpässe im klassischen Sinne. Der Ansatz skaliert runter: Ein DSO mit 5 Umspannwerken und 50 dokumentierten Engpassereignissen kann diesen Ansatz mit pandapower und einem Python-Stack ohne sechsstellige Lizenzkosten prototypisieren.

Woran du merkst, dass das zu dir passt

• Du betreibst ein Verteilnetz oder Übertragungsnetz mit wiederholten Engpassereignissen in denselben Netzabschnitten — mindestens 15–20 dokumentierte Ereignisse in den letzten 3 Jahren
• Deine Netzplanung trifft Investitionsentscheidungen im mittleren bis hohen einstelligen Millionenbereich und sucht belastbarere Entscheidungsgrundlagen als Einzelereignis-Auswertungen
• Du hast SCADA-Zeitreihen mit mindestens 1-Minuten-Auflösung oder kannst diese für relevante Netzabschnitte aktivieren
• Du hast ein digitales Netzmodell (GIS-Export oder CIM-konform) für den betroffenen Netzbereich
• Du verfügst intern über Power-Systems-Engineering-Kompetenz und kannst Data-Science-Expertise entweder intern aufbauen oder gezielt extern einkaufen

Drei harte Ausschlusskriterien — wann dieser Ansatz noch nicht passt:

1. Unter ca. 15 dokumentierten Engpassereignissen in 3 Jahren im relevanten Netzbereich. Das ist eine harte statistische Grenze: Mit weniger Daten kann ein ML-Modell keine verlässlichen Muster lernen — es wird die wenigen Ereignisse auswendig lernen (“memorieren”), aber bei neuen Ereignissen versagen. Das Ausschlusskriterium ist nicht die Unternehmensgröße, sondern die Ereignisdichte. Kleine DSOs mit wenig Engpasshistorie sollten zuerst in bessere SCADA-Archivierung und Smart-Meter-Rollout investieren.

2. Kein maschinenlesbares Netzmodell vorhanden und kein Ressourcenbudget für die Konvertierung. Ohne digitales Netzmodell fehlt die Grundlage für die physikalische Validierung — der Kern, der ML-Korrelationen von kausalen Treibern trennt. GIS-zu-CIM-Konvertierungsprojekte sind eigenständige 3–6-Monats-Projekte. Wer beides gleichzeitig angehen will, unterschätzt den Aufwand.

3. SCADA-Daten können den eigenen Server aus regulatorischen oder OT-Sicherheitsgründen nicht verlassen, aber kein internes Data-Science-Team ist vorhanden. Die Alternative wäre ein externer Dienstleister — aber wenn SCADA-Daten auf keinem externen System verarbeitet werden dürfen (KRITIS-Anforderungen, interne IT-Richtlinien) und gleichzeitig kein internes Team aufgebaut werden soll, gibt es keine funktionierende Lösung. Wer in dieser Situation ist, muss zuerst die OT-Datenstrategie klären.

Das kannst du heute noch tun

Bevor du ein Projekt budgetierst: Mach eine erste Datenbewertung in drei Schritten, die zusammen weniger als einen Arbeitstag kostet.

Schritt 1: Exportiere aus deinem SCADA-System alle Engpassereignisse (Überlastauslösungen, Übertemperaturalarme, manuelle Redispatch-Einleitungen) für die letzten 3 Jahre. Zähle die Ereignisse pro Netzabschnitt. Wenn der kritischste Netzabschnitt weniger als 15 Ereignisse hat — warte, bis die Datenmenge ausreicht.

Schritt 2: Prüfe, in welcher Zeitauflösung dein SCADA-System Messwerte archiviert und wie weit zurück diese Archive reichen. 15-Minuten-Archiv über 3 Jahre ist Ausgangslage; 1-Minuten-Archiv über 1 Jahr ist deutlich wertvoller. Diese Information bestimmt, welche nichtlinearen Muster überhaupt erkennbar sind.

Schritt 3: Prüfe, ob ein maschinenlesbares Netzmodell für den betrachteten Bereich exportierbar ist — aus eurem GIS-System, aus DIgSILENT PowerFactory oder aus einem anderen Netzdatensystem. Falls ja: Teste, ob pandapower einen Lastfluss auf diesem Modell rechnen kann.

Mit diesen drei Antworten weißt du, ob du starten kannst oder welche Voraussetzungen noch fehlen.

Hier ist ein Prompt, mit dem du eine erste Muster-Hypothese für ein einzelnes Ereignis aus rohen SCADA-Daten extrahieren kannst — kein Ersatz für eine vollständige Analyse, aber ein sinnvoller erster Schritt:

Quellen & Methodik

• Titz, M. & Pütz, S. (2024): “Identifying drivers and mitigators for congestion and redispatch in the German electric power system with explainable AI.” Applied Energy, Volume 356, Article 122351. DOI: 10.1016/j.apenergy.2023.122351. ScienceDirect. Gradient-Boosting-Modell mit SHAP-Werten auf deutschen Übertragungsnetzdaten; Hauptergebnis: Windkraft in Norddeutschland ist primärer Treiber; Methodik direkt übertragbar auf Verteilnetzanalyse.
• BNetzA / SMARD-Plattform (2024): “Netzengpassmanagement im Jahr 2023.” smard.de. Gesamtvolumen 34.294 GWh, vorläufige Gesamtkosten ~3,1 Milliarden Euro; 42% des erneuerbaren Volumens aus Verteilnetz-Anlagen.
• arXiv 2503.22721 (2025): “PowerGNN: A Topology-Aware Graph Neural Network for Electricity Grids.” Physikbasierte GNN für Leistungsflussvorhersage; 37-fache Beschleunigung gegenüber klassischer Simulation.
• arXiv 2405.07343 (2024): “Graph Neural Networks for Power Grid Operational Risk Assessment under Evolving Grid Topology.” Dokumentiert Robustheitsprobleme von ML-Modellen bei Topologieänderungen — die wichtigste Failure-Mode-Quelle für diesen Use Case.
• pandapower-Dokumentation (2026): pandapower.org. Fraunhofer IEE / Universität Kassel, CIM-Import (IEC 61970), Python-Ökosystem-Integration.
• BDEW-Whitepaper IT-Sicherheit in der Energiewirtschaft (aktuelle Fassung): Relevante Grundlage für OT-Datenschutz bei KRITIS-Betreibern.
• Preisangaben DIgSILENT PowerFactory: Erfahrungswerte aus öffentlichen Ausschreibungen (Stand April 2026); keine offiziellen Listenpreise verfügbar.
• Energieversorgungsstatistiken (Wärmepumpen, EV, PV): BDEW und Kraftfahrtbundesamt, Stand 2025.

Du willst wissen, ob deine SCADA-Datenbasis für diesen Ansatz ausreicht — oder wo die Lücken liegen? Meld dich für ein kurzes Bewertungsgespräch.