Prädiktive Wartungsplanung für Gasnetzbauteile

Das echte Ausmaß des Problems

Das Durchschnittsalter der deutschen Gasverteilungsinfrastruktur liegt bei über 30 Jahren. Viele Verdichter, Druckregler und Absperrarmaturen in Nieder- und Mitteldrucknetzen stammen aus den 1970er und 1980er Jahren — Bauteile, die für eine Lebensdauer von 20–25 Jahren ausgelegt wurden und jetzt in ihre vierte Dekade gehen.

Das aktuelle Wartungsregime nach DVGW G 491 ist kalenderbasiert: Druckregelanlagen werden alle 1–3 Jahre inspiziert, abhängig von Anlagenkategorie und Druckstufe. Das Arbeitsblatt erlaubt ausdrücklich auch zustandsbasierte Wartung (“condition-based maintenance”), wenn Betreiber dies entsprechend nachweisen können — aber nur eine Minderheit der Betreiber hat die dafür nötige Datenbasis und Dokumentation aufgebaut.

Das kalenderbasierte System hat drei strukturelle Probleme:

Es ignoriert Unterschiede im Betriebsprofil. Eine Regelanlage, die täglich 80 % Lastdurchgang hat, altert schneller als eine, die nur 30 % Auslastung erreicht. Gleiches Intervall für beide ist weder wirtschaftlich noch sicherheitsoptimal.

Es reagiert nicht auf Witterungsextreme. Druckregler mit Außeninstallation verschleißen nach harten Frostwintern messbar schneller. Klimadaten sind verfügbar — aber kein klassisches Wartungsmanagement-System korreliert sie mit Wartungsbedarf.

Es verhindert nicht Notfallreparaturen. Reaktive Wartung nach einem Ausfall kostet nach Branchenerfahrung 3–5 Mal mehr als geplante Instandhaltung: Bereitschaftszuschläge, Expresslieferungen, Versorgungsunterbrechungsrisiko und Meldepflichten. In alternden Netzen macht reaktive Wartung typisch 20–35 % aller Instandhaltungsereignisse aus — ein signifikanter, aber vermeidbarer Kostenblock.

Mit vs. ohne KI — ein ehrlicher Vergleich

Zahlen aus Branchenpublikationen und Erfahrungswerten aus ML-Wartungsprojekten in Versorgungsnetzen. ¹ Die Verbesserungen treten nicht sofort ein — die ersten 12 Monate sind primär Datenbasis-Aufbau und Modelltraining.

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5) Der Zeitgewinn entsteht indirekt: Außendiensttechniker fahren weniger Fehlalarme und weniger unnötige Inspektionstermine. Das ist real, aber nicht so direkt messbar wie etwa die Zeitersparnis bei der Rohrnetz-Wissensdatenbank, wo man Minuten pro Störungsfall zählen kann. Prädiktive Wartung spart Fahrtzeit und Notfallschichten — verteilt über das Jahr.

Kosteneinsparung — hoch (4/5) Der Kosteneffekt ist einer der stärksten unter den verglichenen Anwendungsfällen. Wenn ein einziger vermiedener Notfalleinsatz 15.000–25.000 Euro einspart, und ein Netzbetreiber bisher 10–15 solcher Ereignisse pro Jahr hat, ist das Potenzial erheblich. Dazu kommen reduzierte Lagerkosten durch bedarfsgerechtes Ersatzteilmanagement.

Schnelle Umsetzung — niedrig (2/5) Das ist die kritischste Achse. Prädiktive Wartungsmodelle brauchen eine belastbare Datenbasis — mindestens 18–24 Monate SCADA-Betriebsdaten mit guter Qualität, verbunden mit einer lückenlosen Wartungshistorie. Wer diese Datenbasis nicht hat, muss sie erst aufbauen, bevor das ML-Modell trainiert werden kann. Das ist der längste Vorlauf unter allen verglichenen Anwendungsfällen in diesem Bereich.

ROI-Sicherheit — hoch (4/5) Der Nutzen ist messbar — Wartungskosten je Ereignisklasse sind buchhalterisch erfasst, Ausfallquoten dokumentiert. Wenn nach 18 Monaten die reaktive Wartungsquote von 28 % auf 12 % sinkt, rechnet das die Instandhaltungsabteilung direkt durch. Einziges Risiko: schlechte Datenqualität lässt das Modell nicht ausreichend lernen.

Skalierbarkeit — sehr hoch (5/5) Das ist der stärkste Skalierungseffekt unter den verglichenen Anwendungsfällen. Wenn das Modell für Druckregelanlagen läuft, kann die gleiche Architektur auf Verdichter, Absperrarmaturen und Messanlagen ausgeweitet werden. Und: Jedes neue Datenjahr verbessert die Modellgenauigkeit — das System wird mit Betrieb besser, nicht schlechter.

Richtwerte — stark abhängig von Sensordichte, SCADA-Qualität und Vollständigkeit der Wartungshistorie.

Was das System konkret macht

Das Herzstück ist ein Machine-Learning-Modell, das Zeitreihendaten aus verschiedenen Quellen kombiniert und für jedes überwachte Bauteil eine Ausfallwahrscheinlichkeit für die nächsten 30, 60 und 90 Tage berechnet.

Datenquellen:

• SCADA-Messreihen: Druck, Temperatur, Durchfluss, Betriebsstunden (typisch: Intervall 15 Minuten, über AVEVA PI oder gleichwertige Historian-Systeme aggregiert)
• Wartungshistorie aus dem EAM-System (IBM Maximo, SAP PM): Datum, Art der Maßnahme, Ersatzteile, durchführender Techniker, Aufwand
• Wetter- und Lastdaten: Temperaturganglinien, saisonale Lastspitzen
• Betriebsstunden und Schaltzählungen: Wie oft wurde ein Ventil in den letzten 12 Monaten betätigt?

Modellarchitektur: Für gut überwachte Bauteile (Verdichter, große Regelanlagen) kommen rekurrente Netze oder Gradient-Boosting-Modelle (LightGBM) zum Einsatz, die Zeitreihenmuster erkennen. Für weniger dicht überwachte Bauteile (viele Absperrarmaturen ohne eigene Sensoren) dominieren regelbasierte Scoring-Ansätze auf Basis von Alter, Betriebsstunden und Wartungshistorie.

Output: Das System erzeugt keine Handlungsanweisung, sondern eine Risikopriorisierung. Ein Ampelsystem zeigt je Bauteil: Grün (kein erhöhtes Risiko, nächste planmäßige Inspektion beibehalten), Gelb (erhöhte Ausfallwahrscheinlichkeit, Termin vorziehen empfohlen), Rot (unmittelbares Eingreifrisiko, sofortige Prüfung). Die Wartungsplanung entscheidet anhand dieser Priorisierung über Terminierung und Ressourceneinsatz.

Integration: Der Wartungskalender in IBM Maximo oder SAP PM wird durch automatisch generierte Arbeitsaufträge aktualisiert. Wenn das Modell für eine Regelanlage in zwei Wochen einen erhöhten Risikoscore vorhersagt, wird ein Inspektion-Arbeitsauftrag angelegt — mit Priorisierung, Ressourcenzuordnung und Ersatzteilvorabbestellung.

Datenqualität als Voraussetzung

Prädiktive Wartung ist der anspruchsvollste Anwendungsfall in diesem Bereich hinsichtlich Datenqualität. Drei häufige Probleme:

Sensorabdeckungslücken: Viele Absperrarmaturen und kleine Druckregelanlagen haben keine eigene Sensorik. Ohne Messdaten gibt es keine Zeitreihenbasis für ML — diese Bauteile können nur durch regelbasiertes Scoring bewertet werden, nicht durch Zeitreihenprognose.

Wartungshistorie-Lücken: Wenn Wartungsmaßnahmen in den letzten 10 Jahren nicht vollständig und einheitlich dokumentiert wurden (z. B. Papierlaufzettel, die nicht ins System eingepflegt wurden), fehlt das Trainingslabel. Das Modell kann dann nicht lernen, was eine “normale” Wartungshistorie vor einem Ausfall aussieht.

SCADA-Datenqualität: Signalaussetzer, Kalibrierungsoffsets und fehlende Zeitstempel sind typisch in gewachsenen SCADA-Installationen. Bevor das Modell trainiert wird, muss ein Datenbereinigungsschritt alle Lücken imputieren und Ausreißer bereinigen — das dauert und braucht Domänenwissen.

Empfehlung: Führe vor dem ML-Einstieg eine Bestandsanalyse durch — welcher Prozentsatz deiner Anlagenklassen hat ausreichende Sensorabdeckung und vollständige Wartungshistorie für die letzten 24 Monate? Wenn das weniger als 40 % sind, beginne mit Sensordaten-Nachinstallation und Wartungshistorie-Digitalisierung.

Konkrete Werkzeuge — was wann passt

AVEVA PI System — AVEVA PI (ehemals OSIsoft PI) ist einer der am häufigsten eingesetzten Historian-Systeme in deutschen Gasnetzen. Wenn AVEVA PI bereits im Einsatz ist, ist das die Datenbasis für das ML-Modell. AVEVA PI Connectors ermöglichen die Anbindung an Azure ML oder andere Analytics-Plattformen ohne Rohdaten-Export. Für Netzbetreiber, die noch kein Historian-System haben: AVEVA PI ist die empfohlene Einführungsreihenfolge, bevor prädiktive Modelle sinnvoll eingesetzt werden können.

IBM Maximo Application Suite — Wenn Maximo als EAM im Einsatz ist, bietet die Maximo Application Suite ein natives Predictive Maintenance-Modul (APM), das Sensordaten direkt einliest und Arbeitsaufträge automatisch generiert. Für Betreiber, die Maximo bereits einsetzen, ist das der direkteste Weg — keine separate Plattform, die integriert werden muss.

Azure ML — Für Netzbetreiber, die kein integriertes EAM-Modul nutzen wollen: Azure ML bietet managed Notebooks, AutoML und Deployment-Pipeline. Zeitreihendaten aus AVEVA PI können direkt eingebunden werden. EU-Region verfügbar, AVV standardmäßig erhältlich. Für KRITIS-Betreiber: Azure ML läuft in EU-Rechenzentren, aber die Abhängigkeit von Microsoft-Cloud bleibt — das muss mit dem BSI-Ansprechpartner abgestimmt werden.

C3.ai — Für große Netzbetreiber (>500 Mitarbeitende, >1.000 km Netzlänge), die eine fertige Predictive-Maintenance-Applikation kaufen wollen statt selbst zu bauen. C3.ai hat eine fertige “Predictive Maintenance”-Applikation für Versorgungsunternehmen, die auf SAP und AVEVA PI aufsetzt. Hohe Einstiegsinvestition (Jahresvertrag siebenstellig typisch), aber kaum eigene Entwicklungsarbeit. Wichtig: Aufgrund des US-amerikanischen Datenhostings für KRITIS-Betreiber ungeeignet — und grundsätzlich zu prüfen bei allen Betreibern, bei denen DSGVO-Hosting außerhalb der EU ausgeschlossen ist.

Power BI (kostenlos als Power BI Desktop; kostenpflichtig im Service-Betrieb über Microsoft 365) — Nicht für das ML, sondern für die Visualisierung: Wenn das Modell läuft, braucht die Instandhaltungsleitung ein Dashboard. Power BI integriert sich gut mit Azure ML-Outputs und zeigt Risikoampeln, Wartungskalender und KPI-Trends. Bereits in vielen Stadtwerke-Umgebungen vorhanden.

Wann welcher Ansatz:

• Maximo bereits im Einsatz → Maximo APM-Modul
• AVEVA PI vorhanden, kein Maximo → Azure ML + eigene Integration
• Kein EAM, kein Historian → Erst AVEVA PI einführen, dann ML
• Großbetreiber mit Enterprise-Budget → C3.ai evaluieren (aber US-Hosting prüfen)

Datenschutz und Datenhaltung

Sensordaten aus Druckregelanlagen und Betriebsdaten aus dem Wartungsmanagement sind technische Betriebsdaten — grundsätzlich keine personenbezogenen Daten im DSGVO-Sinne. Ausnahme: Wartungshistorie, die einzelnen Technikern zugeordnet ist (wer hat was wann gemacht), kann als Leistungsdaten personenbezogenen Charakter haben.

Für KRITIS-Betreiber gelten zusätzlich BSI-IT-Grundschutz-Anforderungen: Betriebsdaten aus dem Versorgungsnetz dürfen nicht unkontrolliert in externe Cloud-Systeme übertragen werden. Prüfe mit deinem BSI-Ansprechpartner:

• Welche Datenkategorien aus dem SCADA dürfen in welche Cloud-Regionen übertragen werden?
• Ist Azure ML (EU-Region) für deine KRITIS-Einstufung ausreichend, oder braucht es eine On-Premise-Lösung?
• Wie wird die Verschlüsselung der Datenstrecke AVEVA PI → ML-Plattform sichergestellt?

Was es kostet — realistisch gerechnet

Einmalige Einrichtung (mittlerer Netzbetreiber, 500 km, AVEVA PI vorhanden):

• Datenanalyse und -bereinigung: 20.000–40.000 €
• Modellentwicklung und Training: 40.000–80.000 €
• Integration in EAM-System (Maximo/SAP PM): 15.000–30.000 €
• Schulung Wartungsplanung und Instandhaltungsleitung: 5.000–10.000 €

Laufende Kosten:

• Cloud-/Plattformkosten: 2.000–6.000 €/Monat
• Modellpflege und -retraining: 10–20 Personentage/Jahr

ROI-Berechnung (konservativ): Angenommen: 15 reaktive Wartungsereignisse/Jahr zu je 10.000–20.000 € Durchschnittskosten (das Lede-Beispiel mit 18.000 € liegt im oberen Bereich — einfachere Fälle kosten 8.000–12.000 €). Davon 40 % durch prädiktive Wartung vermeidbar = 6 Ereignisse × 15.000 € (Mittelwert) = 90.000 € Einsparung. Zusätzlich: 100 unnötige Inspektionen/Jahr zu 800 € Fahrt- und Lohnaufwand = 80.000 €, davon 30 % vermeidbar = 24.000 €. Jahreseinsparung: ca. 114.000 €. Break-even nach etwa 2 Jahren. Die realen Zahlen hängen stark von der Ausgangssituation ab.

Drei typische Einstiegsfehler

Fehler 1: Mit zu wenig Datenbasis starten Wer nach sechs Monaten SCADA-Daten bereits ein Produktionsmodell erwartet, wird enttäuscht. ML-Modelle für Wartungsplanung brauchen mindestens 18–24 Monate Betriebsdaten, um saisonale Muster zu erkennen und Ausfallmuster von normalem Betrieb zu unterscheiden. Wer das nicht einplant, kauft eine Plattform und wartet zwei Jahre auf erste belastbare Ergebnisse — und zieht in der Zwischenzeit falsche Schlüsse aus Modellen, die noch nicht ausreichend gelernt haben.

Fehler 2: Wartungshistorie-Qualität nicht vorher prüfen Ein ML-Modell lernt, was eine schlechte Wartungshistorie ihm zeigt. Wenn in den letzten 10 Jahren Wartungsmaßnahmen unvollständig oder inkonsistent dokumentiert wurden, trainiert das Modell auf verzerrten Daten — und macht systematische Fehler bei der Prognose. Vor dem Einstieg: vollständige Prüfung der Wartungshistorie auf Lücken, Inkonsistenzen und fehlende Zustands-Infos.

Fehler 3: System einführen und Wartungsplanung nicht schulen Das ML-Modell gibt einen Risikowert aus. Aber was macht der Wartungsplaner damit? Wenn die Priorisierung als “Empfehlung” gilt, die man ignorieren kann, bleibt der ROI aus. Die eigentliche Kulturveränderung — weg vom reinen Kalenderwartung, hin zur risikopriorisierten Planung — braucht Führungsentscheidung und konsequente Einführungsbegleitung. Das dauert ein bis zwei Jahre. Eng damit verbunden: Kein Verantwortlicher für laufende Modellpflege — wenn sich Netzkomponenten ändern (neue PRSs, Stilllegungen), muss das Modell nachtrainiert werden. Ohne festen Process Owner veraltet die Prognosequalität innerhalb von 12–18 Monaten.

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

Die Instandhaltungsmonteure werden zunächst skeptisch sein. “Ein Computer sagt mir, wann meine Anlage kaputt geht?” Das ist kein theoretisches Misstrauen — es gibt gute Gründe dafür: Erfahrene Techniker haben ein Gespür für ihre Anlagen, das kein Datensatz vollständig abbildet. Das System sollte nie so kommuniziert werden, dass es das Urteil des Fachmanns ersetzt. Es ist ein Informationssystem, das Trends sichtbar macht, die kein Mensch aus Tausenden Messpunkten täglich herauslesen kann.

Die Wartungsplanung wird das System nach 6–12 Monaten schätzen — sobald die ersten vorhergesagten Risiken durch tatsächliche Befunde bestätigt werden. Dieser Moment (“das System hat recht gehabt”) ist der wichtigste Wendepunkt für die Akzeptanz.

Was nicht passiert: das System “verwaltet sich selbst”. Modellpflege, Datenqualitätsprüfung und Regel-Updates bei neuen Anlagentypen sind dauerhafte Aufgaben — mindestens 20–30 Arbeitstage pro Jahr für ein mittelgroßes Netz.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

“Wir haben DVGW-Fristen, die müssen wir einhalten — da kann keine KI dazwischenkommen.” Prädiktive Wartung ersetzt die DVGW-Fristen nicht — sie ergänzt sie. Das Modell kann empfehlen, eine Inspektion vorzuziehen (wenn Risiko hoch), aber die Pflichttermine bleiben bestehen. Was wegfällt, sind die Inspektionen, die planmäßig stattfinden, aber tatsächlich nichts zeigen — “condition-based maintenance” ist in DVGW G 491 ausdrücklich vorgesehen und dokumentationspflichtig.

“Unsere SCADA-Daten sind nicht gut genug.” Das ist meistens die ehrlichste Aussage. Und sie ist oft richtig — schlechte SCADA-Qualität ist der häufigste Grund, warum ML-Projekte in Versorgungsnetzen langsamer als geplant vorankommen. Die richtige Reaktion ist: zuerst die Datenbasis verbessern, dann das ML-Modell. Nicht: trotzdem mit schlechten Daten starten und hoffen.

Woran du merkst, dass das zu dir passt

Das Vorhaben ist sinnvoll, wenn:

• Dein Netz mehr als 200 Druckregelanlagen oder 50 Verdichter hat, die überwacht werden müssen
• Du bereits ein SCADA-System mit Historian-Funktion (AVEVA PI oder gleichwertig) mit mindestens 18 Monaten Betriebsdaten betreibst
• Deine Wartungshistorie für die letzten 5+ Jahre vollständig und strukturiert vorliegt
• Reaktive Wartungsereignisse mehr als 15 % aller Instandhaltungsmaßnahmen ausmachen

Das Vorhaben ist noch nicht sinnvoll, wenn:

• Dein SCADA hat keine Historian-Funktion oder weniger als 12 Monate Daten: Ohne Zeitreihenbasis ist prädiktive Wartung nicht möglich. Beginn mit der Sensordateninfrastruktur.
• Weniger als 50 % der relevanten Anlagen haben eigene Sensorik: Regelbasiertes Scoring statt ML — deutlich einfacher einzuführen und ausreichend für kleinere Anlagenparks.
• Dein Unternehmen hat keinen Eigentümer für das System nach der Einführung: Prädiktive Wartung braucht einen kontinuierlichen Betrieb — wenn niemand das Modell nach der Einführung pflegt, degradiert es innerhalb von 12–18 Monaten zu einem unzuverlässigen Ausgabegenerator.

Das kannst du heute noch tun

Beginne mit einer Ausfallanalyse der letzten drei Jahre: Wie viele ungeplante Ausfälle gab es? Welche Anlagenklassen waren betroffen? Wie hoch waren die Kosten je Ereignis? Wenn diese Zahlen nicht aus dem EAM-System abrufbar sind, ist das selbst ein wichtiges Ergebnis — die Datenbasis für prädiktive Wartung fehlt noch.

Der folgende Prompt hilft dir, aus vorhandenen Wartungsprotokollen erste Muster zu identifizieren:

Quellen & Methodik

• DVGW G 491 — Arbeitsblatt “Druckregelanlagen für Gas bis einschließlich 100 bar”; regelt Auslegung, Errichtung, Betrieb und Wartungsintervalle von Druckregelanlagen (PRSs); enthält Grundlage für zustandsbasierte Wartung (“condition-based maintenance”)
• IBM Maximo APM for Energy & Utilities — IBM-Produktübersicht für prädiktive Instandhaltung in Energie und Versorgungsunternehmen; ibm.com/de-en/marketplace/apm-energy-utilities
• Compressor Predictive Maintenance — The 2025 Implementation Guide — f7i.ai, 2025; Branchenübersicht zu Implementierungsaufwand und realistischen Timelines
• AI Predictive Maintenance reduces downtime by 40% in Oil & Gas — ifactoryapp.com, 2025; Literaturübersicht zu Ausfallquoten-Reduktion; Branchenzahlen mit Vorsicht zu lesen (Verkäuferperspektive)
• Methodik: Kostenschätzungen basieren auf Erfahrungswerten aus EAM-Implementierungsprojekten; reaktive vs. präventive Wartungskosten nach Branchenpublikationen und eigener Schätzung. Keine repräsentative Studie.