ML-basierte Leckageprognose im Gasnetz

Das echte Ausmaß des Problems

Netzverluste in deutschen Gasverteilnetzen gelten als niedrig — und in absoluten Zahlen stimmt das. Die typische Netzverlustquote eines gut gewarteten Verteilnetzes liegt bei 0,3–0,8 Prozent des durchgeleiteten Volumens. Das klingt nach wenig. In Zahlen ausgedrückt: Bei einem mittelgroßen Stadtwerk mit 500 GWh Jahrestransitvolumen bedeutet 0,5 % Netzverlust einen jährlichen Gasverlust im Wert von 2–3 Millionen Euro — bei einem Gaspreis von 4–5 Cent/kWh.

Nicht alles davon ist physische Leckage. Ein Teil sind Messungenauigkeiten, Abrechnungsdifferenzen und unvermeidbare technische Verluste. Aber ein signifikanter Anteil sind tatsächliche Leckagen, die oft monate- bis jahrelang unentdeckt bleiben — weil:

• Druckabweichungen von normalen Lastschwankungen überdeckt werden. Bei hohem Verbrauch fällt der Druck, bei niedrigem steigt er. Eine kleine Leckage verändert das Muster kaum merklich.
• Messdaten in Echtzeit nicht komplett auswertbar sind. Ein Dispatcher überwacht Dutzende bis Hunderte Messpunkte gleichzeitig. Ein langfristiges statistisches Muster über Wochen ist manuell nicht zu erkennen.
• Die Lokalisierung aufwendig ist. Selbst wenn eine Leckage vermutet wird, muss das Inspektionsteam den betroffenen Abschnitt mit tragbaren Gasspürgeräten abgehen — bei einem Stadtwerknetz mit 500 km Leitungslänge ein erheblicher Aufwand.

Das Kostenproblem liegt weniger am laufenden Gasverlust selbst als an der Art der Entdeckung: Wer die Leckage zuerst bemerkt, ist oft der betroffene Anwohner. Eine reaktive Reparatur nach Gasgeruchmeldung kostet typischerweise das 3–10-fache einer geplanten Instandhaltungsmaßnahme — weil Straße geöffnet, Abschnitt gesperrt und oft unter Zeitdruck gearbeitet wird.

Laut einer 2024 auf ScienceDirect veröffentlichten Studie zur ML-basierten Echtzeiterkennung in städtischen Niederdrucknetzen erreicht Machine Learning-gestützte Anomalieerkennung auf Netzdruckdaten eine Erkennungsquote von 85–92 Prozent bei Leckagen über einer definierten Schwellengröße — mit einer Fehlalarmrate, die deutlich unter der Rate manueller Meldungen liegt. Die Studie verwendet IoT-Sensordaten in städtischen Niederdrucknetzen — die Übertragbarkeit auf AVEVA-PI-basierte SCADA-Systeme in Gasverteilnetzen ist nicht direkt belegt; Werte als Orientierungsrahmen zu verstehen.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Erfahrungswerte aus akademischen Studien und Praxisberichten; stark abhängig von Netzzustand, Sensorabdeckung und Systemqualität.

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5) Das System spart keine tägliche Routinezeit im Betrieb. Was es spart, ist die Reaktionszeit nach einer Leckage — und die Zeit, die ein Inspektionsteam mit der Suche verbringt. Das ist real, aber verglichen mit der Rohrnetz-Wissensdatenbank oder der Netzanschluss-Automatisierung kein direkter täglicher Zeitgewinn für das Team.

Kosteneinsparung — sehr hoch (5/5) Das ist der stärkste Kosteneffekt unter allen vier Anwendungsfällen in dieser Kategorie. Eine einzige vermiedene Notfallreparatur (30.000–80.000 Euro) übersteigt die jährlichen Betriebskosten des ML-Systems. Dazu kommt die langfristige Reduktion der Netzverlustquote, die bei größeren Netzen im sechsstelligen Bereich liegt. Kein anderer Anwendungsfall in dieser Kategorie hat ein so direktes Kosten-Nutzen-Verhältnis.

Schnelle Umsetzung — niedrig (2/5) Das ist zusammen mit der Netzanschluss-Automatisierung der schwierigste Einstieg. Zuverlässige Anomalieerkennung braucht historische Datenbasis: mindestens 12–24 Monate SCADA-Daten mit guter Qualität, saisonale Variationen abgedeckt, Wetterdaten verknüpft. Netze ohne strukturierten Historian (AVEVA PI oder ähnlich) müssen diese Infrastruktur erst aufbauen.

ROI-Sicherheit — hoch (4/5) Netzverlustquote vorher und nachher ist direkt messbar, Reparaturkosten sind dokumentiert. Der ROI ist real und nachweisbar — aber er hängt stark von der tatsächlichen Leckagehäufigkeit des Netzes ab. Netze mit jungem, gut gewartetem Leitungsbestand haben weniger Leckagen und damit auch geringeres ML-Einsparpotenzial.

Skalierbarkeit — hoch (4/5) Das Modell verbessert sich mit mehr historischen Daten. Neue Netzabschnitte können nach Anbindung ans Historian-System einbezogen werden. Keine proportionale Kostensteigerung mit Netzgröße — die Infrastruktur skaliert mit.

Richtwerte — stark abhängig von Netzalter, Leitungsmaterialmix, Sensorabdeckung und historischer Datenverfügbarkeit.

Was das System konkret macht

Predictive Analytics für Gasnetzleckagen basiert auf einem einfachen Grundprinzip: Ein Gasnetz ohne Leckagen verhält sich physikalisch vorhersagbar. Druckverhältnisse zwischen Einspeisepunkten und Verbrauchsstellen folgen bekannten hydraulischen Gesetzen, modifiziert durch Tageszeit, Wochentag und Außentemperatur.

Das ML-Modell lernt diese normalen Muster aus historischen SCADA-Daten: Wie verhält sich Messpunkt B7 bei 10 Grad, Dienstagabend, nach 19 Uhr? Wie bei minus 5 Grad im Spitzenverbrauch? Wenn die aktuellen Messwerte signifikant vom gelernten Normalverhalten abweichen — und das Muster konsistent über mehrere Messpunkte gleichzeitig auftritt — signalisiert das System einen Verdachtsbereich.

Was das System konkret liefert:

• Tägliche Anomalie-Reports mit Verdachtsbereichen (auf Netzabschnittsebene, nicht auf einzelne Leitungsmeter)
• Konfidenzwerte: “Wahrscheinlichkeit einer signifikanten Abweichung im Abschnitt B7: 78 %”
• Trendanalyse: Hat sich das Muster in den letzten 3 Wochen verstärkt?
• Korrelation mit Wetterdaten: Ist die Abweichung temperaturkorrigiert immer noch signifikant?

Was das System nicht leistet:

• Millimetergenaue Leckageortung — das bleibt Aufgabe des Inspektionsteams mit tragbaren Gasspürgeräten
• Klassifizierung der Leckageursache (Korrosion, Verbindungsschaden, Dritter-Einwirkung)
• Automatische Abschaltempfehlung — das ist eine Betriebsentscheidung, die Verantwortliche treffen

Warum Wetterdaten zwingend sind

Ein häufiger Fehler bei ersten Implementierungsversuchen: Das Modell trainiert nur auf Druckdaten, ohne Außentemperatur einzubeziehen. Das Ergebnis ist eine Fehlalarmquote von 20–40 Prozent, weil das Modell normale temperaturbedingte Druckschwankungen als Anomalie interpretiert. Wetterdaten — mindestens stündliche Außentemperatur, idealerweise auch Wind und Niederschlag — sind keine optionale Ergänzung, sondern Pflichtkomponente.

Auch die Tageszeit und der Wochentag müssen in das Modell einfließen: Das Netz verhält sich sonntagsmorgens um 4 Uhr anders als montags um 8 Uhr. Ein Modell, das diesen Kontext ignoriert, produziert zu viele Fehlalarme.

DVGW G 466-1 und Betriebsanforderungen

DVGW G 466-1 (Betrieb und Instandhaltung von Gasverteilnetzen) schreibt für Gasverteilnetze regelmäßige Leitungsbegehungen, Druckprüfungen und Lecksuche in definierten Prüfintervallen vor — abhängig von Leitungsalter, Material und Druckstufe. Ein ML-System ersetzt diese vorgeschriebene Inspektion nicht, aber es hilft dabei, die begrenzten Inspektionsressourcen gezielter einzusetzen: statt flächendeckender Begehung nach Standardintervall eine risikobasierte Priorisierung auf Basis der Modellausgaben.

Konkrete Werkzeuge — was wann passt

Daten-Historian (AVEVA PI): Bei den meisten größeren deutschen Gasnetzbetreibern ist AVEVA PI System als Echtzeit-Historian im Einsatz. Das ist der natürliche Ausgangspunkt: SCADA-Daten laufen bereits in PI, historische Zeitreihendaten sind vorhanden. Die ML-Modelle lesen über PI’s REST-API oder direkte Datenbankanbindung. Wer kein PI hat, muss zunächst eine Daten-Historisierungsinfrastruktur aufbauen — das ist ein vorgelagertes Projekt.

ML-Modellentwicklung: Azure ML (EU-Region) oder AWS SageMaker (EU-Region) bieten die Infrastruktur für das Modelltraining. Für Gasnetze haben sich folgende Modelltypen in der Forschung bewährt: LightGBM für Klassifikation (Leckage ja/nein), LSTM-Netzwerke für Zeitreihen-Anomalieerkennung, Isolation Forest für unüberwachte Anomalieerkennung bei fehlendem gelabeltem Trainingsmaterial. Ein Data Scientist mit OT-Erfahrung ist Voraussetzung — generische ML-Kenntnisse ohne Verständnis der Gasnetzmechanik führen zu schlecht kalibrierten Modellen.

Visualisierung: Power BI (EU-Hosting, Daten bleiben im Azure-Tenant) eignet sich gut für das tägliche Anomalie-Dashboard — vertraute Oberfläche für Dispatcher, einfache Alarm-Konfiguration. Alternativ: Grafana (Open Source) für technische Teams, die Flexibilität über Bequemlichkeit stellen.

Für kleinere Netzbetreiber ohne eigenes Data-Science-Team: C3.ai bietet eine fertige Predictive-Maintenance-Applikation, die auch auf Energienetz-Daten konfiguriert werden kann. Der Vorteil: kein eigenes Modelltraining. Der Nachteil: US-Datenhaltung und Enterprise-Preise, die für kleinere Stadtwerke kaum tragbar sind.

Datenqualität als Voraussetzung

Das ist kein optionaler Abschnitt. Ein ML-Leckageerkennungssystem ist nur so gut wie die Daten, auf denen es trainiert wird.

Minimalanforderungen:

• Mindestens 18–24 Monate historische SCADA-Daten in guter Qualität (Ausfalltage < 5 %)
• Druckmesspunkte in ausreichender Dichte — “ausreichend” hängt von der Netztopologie ab; eine Daumenregel sind Messpunkte alle 2–5 km Hauptleitung
• Metadaten zu bekannten Ereignissen: Wann wurden welche Leitungsabschnitte repariert oder gewartet? Wann gab es Netzausbauten? Diese Ereignisse müssen im Datensatz markiert sein, sonst trainiert das Modell auf Reparatur-bedingte Druckänderungen als “normal”
• Wetterdaten: stündliche Außentemperatur für alle historischen Perioden, aus einer für das Netzgebiet repräsentativen Station

Häufige Datenqualitätsprobleme:

• Messpunkte mit langen Ausfallzeiträumen → Datenlücken, die das Modell nicht überbrücken kann
• Sensordrift: Druckwandler, die über Zeit schleichend fehlmessen, ohne dass die Kalibrierung aktualisiert wird
• Fehlende Ereignis-Metadaten: Das Modell lernt auf einer Leckage-Reparatur als normalem Betrieb

Wer seine Datenlage nicht kennt, sollte vor jeder ML-Investition einen Daten-Audit durchführen. Das dauert 2–4 Wochen und spart Monate frustrierter Modellentwicklung auf schlechter Datenbasis.

Datenschutz und Datenhaltung

SCADA-Druckdaten sind in der Regel keine personenbezogenen Daten — DSGVO-Relevanz entsteht erst, wenn Verbrauchsdaten auf Einzelkunden-Ebene einbezogen werden. Bei netzweiter Anomalieerkennung auf Abschnittsebene ist das typischerweise nicht der Fall.

Relevant sind stattdessen:

• BSI-Grundschutz und KRITIS-Anforderungen: SCADA-Daten und Netztopologie-Informationen (Wo liegen welche Leitungen?) sind sicherheitsrelevant. ML-Modelle, die auf diesen Daten trainieren, und die Datenhaltung müssen im IT-Sicherheitskonzept erfasst sein.
• Externe Datenübertragung: Wer SCADA-Daten an einen externen Cloud-Anbieter überträgt, muss sicherstellen, dass Netztopologie-Daten nicht in Trainings-Datensätze von Cloud-Anbietern einfließen. Azure ML mit EU-Region und entsprechenden Datenverarbeitungsverträgen bietet hier klare vertragliche Absicherung.
• On-premise als KRITIS-konforme Alternative: Wer keine Cloud-Anbindung für SCADA-Daten zulassen will, kann das Modell on-premise auf eigener Server-Infrastruktur trainieren und betreiben — aufwendiger in der Administration, aber ohne externe Datenübertragung.

Was es kostet — realistisch gerechnet

Einmalige Implementierungskosten:

• Daten-Audit und -aufbereitung: 15.000–30.000 Euro
• Modellentwicklung (Data Scientist, 3–6 Monate): 50.000–120.000 Euro (internes Team) oder 80.000–180.000 Euro (externer Dienstleister)
• Infrastruktur (Datenanbindung, Cloud-Setup, Dashboard): 20.000–40.000 Euro
• Gesamt: 85.000–250.000 Euro

Laufende Kosten (monatlich):

• Cloud-Infrastruktur (ML-Hosting, Datenspeicher): 500–2.000 Euro
• Modellpflege und Retraining (intern, 4–8 Stunden/Monat): 300–600 Euro
• Gesamt: 800–2.600 Euro/Monat

Konservatives ROI-Szenario:

• 2 vermiedene Notfallreparaturen pro Jahr (je 40.000 Euro): 80.000 Euro
• Reduktion Netzverlustquote um 0,2 % (500 GWh Netz, 4 Cent/kWh): 40.000 Euro
• Gesamtnutzen: 120.000 Euro/Jahr
• Bei 150.000 Euro Einrichtung + 20.000 Euro/Jahr laufend: Break-even nach 1,5–2 Jahren

Das ist der attraktivste ROI unter den vier Anwendungsfällen dieser Kategorie — wenn das Netz in einem Zustand ist, der regelmäßige Leckagen produziert. Für ein junges Netz mit niedrigem Leckageaufkommen rechnet sich das Modell deutlich schlechter.

Drei typische Einstiegsfehler

Fehler 1: Fehlalarme nicht ernst nehmen In den ersten Wochen produziert fast jedes frisch eingeführte Anomalieerkennungssystem zu viele Fehlalarme. Das Team verliert schnell das Vertrauen und beginnt, Systemwarnungen zu ignorieren. Das ist gefährlich — denn irgendwann ist eine Warnung real. Die Lösung ist nicht, Fehlalarme zu tolerieren, sondern intensiv in die Kalibrierungsphase zu investieren: Jeden Fehlalarm analysieren, Modell anpassen, Schwellenwerte nachjustieren. Das dauert 4–8 Wochen und ist unverzichtbar.

Fehler 2: Ohne saisonale Datenbasis starten Wer mit 6 Monaten SCADA-Daten in der Sommersaison startet, hat ein Modell, das Winter-Druckverhalten nicht kennt. Im ersten Winter werden Spitzenlastsituationen als Anomalie gemeldet. Das Modell braucht mindestens einen vollständigen Jahresgang — idealerweise zwei, um saisonale Besonderheiten voneinander zu trennen.

Fehler 3: Keine Rückmeldeschleife zur Kalibrierung — und kein Retraining nach Netzänderungen Das Inspektionsteam geht auf Basis einer Anomaliemeldung in Abschnitt B7 und findet nichts. Diese Information muss ins Modell zurückfließen: “Abschnitt B7, Datum, kein Befund.” Wenn diese Rückmeldung nicht systematisch erfasst wird, lernt das Modell nicht, zwischen echten Anomalien und strukturellen Besonderheiten des Netzes zu unterscheiden. Das ist keine technische Automatik — es ist ein Prozess, den Menschen einhalten müssen.

Damit eng verwandt: Kein Retraining nach Netzänderungen geplant. Wenn neue Leitungsabschnitte hinzukommen, Druckregler ausgetauscht werden oder Einspeisepunkte sich verändern, kennt das Modell das neue Normalverhalten nicht — und produziert Fehlalarme auf den veränderten Abschnitten. Ein Modell, das zum Go-live-Zeitpunkt gut kalibriert war, driftet ohne Retraining innerhalb von 12–18 Monaten nach größeren Netzänderungen. Das Konzept für regelmäßiges Retraining (mindestens jährlich oder nach wesentlichen Netzänderungen) muss vor dem Produktivbetrieb festgelegt sein.

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

Dispatcher reagieren auf ML-Anomaliemeldungen anfangs skeptisch — zu Recht. Ein System, das “78 % Wahrscheinlichkeit einer Abweichung in Abschnitt B7” meldet, ohne mehr Kontext zu liefern, ist schwer einzuordnen. Die Akzeptanz steigt, wenn das Dashboard konkret zeigt: das Druckmuster der letzten 7 Tage in B7 verglichen mit dem Normalverhalten, der Trend über Zeit, die Wetterkompensation.

Was typischerweise nach 6–9 Monaten passiert: Das Team entwickelt einen eigenen Umgang mit dem System — “wenn B7 unter 70 % liegt, schauen wir nochmal, unter 85 % schicken wir einen aus” — das ist die gewünschte Entwicklung. Das ML-System wird zum Werkzeug, das menschliches Urteil informiert, nicht ersetzt.

Was nicht passiert: Das System findet alle Leckagen. Sehr kleine Leckagen unter einem bestimmten Volumenverlust-Schwellenwert bleiben statistisch unsichtbar. Das System ist ein Frühwarnwerkzeug, kein Ersatz für die regelmäßige Netzinspektion nach DVGW G 466-1.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

“Wir haben doch schon SCADA-Alarme im System.” SCADA-Schwellenwert-Alarme und ML-Anomalieerkennung sind komplementär, nicht gleich. Ein SCADA-Alarm schlägt an, wenn ein Messwert einen konfigurierten Schwellenwert überschreitet — das sind akute, große Abweichungen. Das ML-System erkennt subtile, langfristige Muster, die sich über Wochen aufbauen und immer unter dem Alarm-Schwellenwert bleiben. Genau diese langsamen Entwicklungen sind es, die bei Korrosionsleckagen typisch sind.

“Unser Netz ist zu alt / zu komplex für solche Modelle.” Ein altes Netz hat meist mehr Leckagen — was den Business Case stärkt. Und “komplex” ist kein Ausschlussgrund, wenn die Datenbasis vorhanden ist. Die Herausforderung bei alten Netzen liegt meist in der historischen Datenverfügbarkeit und der Vollständigkeit des Leitungskatasters, nicht in der Modellierbarkeit des Netzes selbst.

Woran du merkst, dass das zu dir passt

Das System lohnt sich für euch, wenn:

• Ihr mindestens 150 km Leitungsnetz betreibt mit bestehenden Druckmesspunkten
• Ihr einen Daten-Historian (AVEVA PI, InfluxDB (Open Source) oder vergleichbar) im Einsatz habt mit mindestens 18 Monaten historischer Datenbasis
• Euer Netz Leitungsmaterial aus verschiedenen Jahrzehnten enthält (höhere Leckagewahrscheinlichkeit als junges Netz)
• Ihr in den letzten 3 Jahren mindestens 3–5 reaktive Reparaturen nach Gasgeruchmeldungen hattet

Das System passt nicht zu euch, wenn:

• Euer Leitungsnetz überwiegend aus Polyethylen-Leitungen nach 1990 besteht — junges, gut gebautes Netz hat wenig Leckagepotenzial, der Business Case ist schwach
• Ihr keinen strukturierten SCADA-Historian habt — ohne historische Zeitreihendaten kein Modell, Datenerfassung ist Vorprojekt
• Kein Data Scientist oder kein Budget für externen ML-Dienstleister verfügbar ist — diese Kompetenz kann nicht durch Standardsoftware ersetzt werden
• Euer Leitungsnetz hat weniger als einen Druckmesspunkt je 5 km Hauptleitung — das Modell kann keine netzabschnittsbezogenen Verdachtsbereiche liefern, sondern nur Netzweit-Anomalien ohne Lokalisierbarkeit. Baut zuerst die Messinfrastruktur aus, bevor ML sinnvoll ist

Das kannst du heute noch tun

Zieht die Schadensfallliste der letzten 3 Jahre heraus und berechnet: Was haben die reaktiven Reparaturen nach Gasgeruchmeldungen gekostet? Wie viele Fälle gab es? Das ist die einfachste Basis-Kalkulation, ob ein ML-Frühwarnsystem wirtschaftlich ist — vor jedem technischen Gespräch mit Dienstleistern.

Quellen & Methodik

• ScienceDirect 2024: „Real-time detection of urban gas pipeline leakage based on machine learning of IoT time-series data” — Studie zur ML-basierten Leckageerkennung in städtischen Niederdrucknetzen; Erkennungsraten 85–92 % bei definierten Leckagegrößen
• Springer Nature 2025: „Machine learning anomaly detection of lost and unaccounted for gas” — Analyse von LAUF (Lost and Unaccounted for Gas) mit ML-Methoden; LightGBM erreicht ROC-AUC von 0,871 auf Testdatensätzen realer Netzoperatoren
• Thunder Said Energy: „Gas distribution: loss rates, leakage, unaccounted gas” — Branchenübersicht zu Gas-Netzverlusten; typische Verlustquoten in Europa 0,3–0,8 % (physische Leckage), europäische Gesamtrate inklusive Messabweichungen bis 1–4 %
• DVGW Arbeitsblatt G 466-1 — Betrieb und Instandhaltung von Gasverteilnetzen; schreibt Prüfintervalle für Leitungsbegehung und Lecksuche im laufenden Betrieb vor; Grundlage für die beschriebene risikobasierte Priorisierung von Inspektionsressourcen auf Basis der ML-Ergebnisse. DVGW Arbeitsblatt G 462 — Bau und Prüfung von Gasleitungen aus Polyethylen; maßgeblich für Erstinstallation und Druckprüfung bei Neuverlegung (nicht für wiederkehrende Betriebsinspektionen)
• ABB Ability: Mobile Gas-Leckageortung — Technische Dokumentation zur mobilen Leckageerkennung; Kontext für die Beschreibung der Lokalisierungsphase nach ML-Alarm
• MDPI Sensors 2025: „Research on Detection Methods for Gas Pipeline Networks Under Small-Hole Leakage Conditions” — Spatial-Temporal Attention Network (STAN) für Graph-basierte Anomalieerkennung; Einordnung der Grenzen bei sehr kleinen Leckagen