ML-basierte Leckageprognose im Gasnetz

Das echte Ausmaß des Problems

Netzverluste in deutschen Gasverteilnetzen gelten als niedrig, und in absoluten Zahlen stimmt das. Für europäische Verteilnetze nennt die Branchenübersicht von Thunder Said Energy 0,3–0,8 Prozent physische Verluste des durchgeleiteten Volumens. In Euro ausgedrückt: Bei einem mittelgroßen Stadtwerk mit 500 GWh Jahrestransitvolumen sind 0,5 % Netzverlust 2,5 GWh, also 2,5 Millionen kWh mal 4–5 Cent/kWh, zusammen 100.000–125.000 Euro im Jahr.

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.

Wem eine Senkung der Verluste zugutekommt, regelt die Anreizregulierung. Kosten für Verlustenergie gehen in die Erlösobergrenze ein. Solange die Bundesnetzagentur sie nicht als volatile Kosten festgelegt hat (§ 11 Abs. 5 ARegV), bleibt eine Einsparung nur bis zur nächsten Kostenprüfung beim Netzbetreiber und senkt danach die Netzentgelte, landet also beim Netznutzer.

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 ist teurer als eine geplante, weil sofort ausgerückt, abgesperrt und unter Zeitdruck gearbeitet wird. Wie groß der Unterschied ist, dafür haben wir keine belastbare Erhebung gefunden. Ihr könnt ihn aus eurer eigenen Schadensliste ablesen: Kosten der Reparaturen nach Gasgeruchmeldung gegen geplante Maßnahmen an Leitungen gleicher Nennweite.

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. 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

¹ Annahmen dieser Seite, keine Erhebung. Die Reparaturkosten entnehmt ihr eurer Schadensliste, Entdeckungszeiten und den Anteil reaktiver Reparaturen könnt ihr erst nach einem Betriebsjahr gegen die Vorjahre halten. 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, mittel (3/5) Eine früh gefundene Leckage muss trotzdem repariert werden. Gespart wird nur die Differenz zwischen Notfall und geplanter Maßnahme, nach der Tabelle oben 10.000 bis 75.000 Euro je Fall, und nur bei den Fällen, die das System tatsächlich früher meldet. Jede Verdachtsmeldung ohne Befund kostet dagegen einen Suchtrupp-Einsatz. Die Senkung der Verlustquote bringt bei 500 GWh Durchsatz eher fünfstellige als sechsstellige Beträge, und die bleiben nur bis zur nächsten Kostenprüfung beim Netzbetreiber. Das trägt einen Business Case in leckageanfälligen Netzen, in jungen Netzen nicht.

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, mittel (3/5) Reparaturkosten sind dokumentiert, aber die Zahl der Fälle ist klein. Bei einer Handvoll Leckreparaturen im Jahr dauert es mehrere Jahre, bis sich eine Verschiebung von reaktiv zu geplant vom Zufall unterscheiden lässt. Die Netzverlustquote enthält Messdifferenzen und schwankt mit Temperatur und Abrechnung, sie taugt nur eingeschränkt als Vorher-nachher-Beleg. 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 465-1 und Betriebsanforderungen

Das DVGW-Arbeitsblatt G 465-1 (Überprüfung von Gasrohrnetzen mit einem Betriebsdruck bis 16 bar) legt fest, in welchen Abständen das Rohrnetz mit Gasspürgeräten überprüft wird. Diese Intervalle sind Pflicht und fallen durch ein ML-System nicht weg, auch nicht in Abschnitten, die das Modell für unauffällig hält. Das Modell kann nur zweierlei: die Reihenfolge innerhalb des Pflichtintervalls festlegen und zusätzliche Begehungen zwischen den Pflichtterminen dorthin lenken, wo es Auffälligkeiten sieht. Wer die Modellausgabe als Grund nimmt, eine vorgeschriebene Überprüfung zu strecken, verstößt gegen das Regelwerk.

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 große 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-Jahresverträge, die laut unserer Toolseite typisch im siebenstelligen Bereich liegen. Für Stadtwerke ist das keine Option, dort bleibt nur der externe ML-Dienstleister.

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:

• IT-Sicherheitskatalog der Bundesnetzagentur (§ 5c EnWG): 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 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

Beispielrechnung für ein leckageanfälliges Netz:

• Das Netz hat sechs Leckreparaturen im Jahr, das System meldet zwei davon früh genug, dass sie geplant laufen. Gespart wird die Differenz, nicht die ganze Reparatur: 2 mal (40.000 Euro Notfall minus 12.500 Euro geplant) = 55.000 Euro
• Senkung der Verlustquote um 0,1 Prozentpunkte, eine Annahme, weil die Quote auch Messdifferenzen enthält: 500 GWh mal 0,1 % = 500.000 kWh mal 4 Cent = 20.000 Euro, nach heutiger ARegV-Logik nur bis zur nächsten Kostenprüfung bei euch
• Laufende Kosten: 20.000 Euro im Jahr (rund 1.700 Euro im Monat, Mitte der Spanne oben)
• Netto: 55.000 plus 20.000 minus 20.000 = 55.000 Euro im Jahr
• Bei 150.000 Euro Einrichtung: Break-even nach knapp drei Jahren (150.000 geteilt durch 55.000)

Noch nicht abgezogen sind die Einsätze für Verdachtsmeldungen ohne Befund. Jede Meldung schickt einen Trupp mit Gasspürgerät los, und in den ersten Monaten sind das viele (siehe Fehler 1). Setzt dafür euren eigenen Kostensatz je Einsatz an.

Die Rechnung hängt fast ganz an der Zahl der Leckfälle. Ein Netz mit ein bis zwei Leckreparaturen im Jahr verschiebt vielleicht eine halbe davon, rund 14.000 Euro (ein halber Fall mal 27.500 Euro Differenz). Verlustenergie-Effekt und laufende Kosten heben sich in der Beispielrechnung gerade auf, es bleiben also 14.000 Euro im Jahr, und die Einrichtung ist erst nach rund elf Jahren bezahlt. Für ein junges Netz mit niedrigem Leckageaufkommen lohnt sich das Projekt nicht.

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 vorgeschriebene Rohrnetzüberprüfung nach DVGW G 465-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 12–15 reaktive Reparaturen nach Gasgeruchmeldungen hattet, also vier bis fünf im Jahr (darunter trägt die Rechnung oben nicht)

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 465-1, Überprüfung von Gasrohrnetzen mit einem Betriebsdruck bis 16 bar; legt die Pflichtintervalle der Rohrnetzüberprüfung fest, die ein ML-System nicht ersetzt, sondern nur innerhalb der Intervalle priorisieren kann; dvgw.de
• ARegV § 11 Abs. 5, volatile Kostenanteile; Verlustenergie zählt nur dazu, wenn die Bundesnetzagentur das festgelegt hat (gesetze-im-internet.de/aregv/__11.html)
• 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