Störungsdiagnose an Prozessanlagen beschleunigen

Das echte Ausmaß des Problems

In der Prozessindustrie ist die Alarmflut das normalste Ding der Welt — und gleichzeitig eines der teuersten Probleme. Wenn eine Störung in einer Destillationskolonne beginnt, löst sie typischerweise nicht einen Alarm aus, sondern eine Kaskade: Druck steigt, Temperatur folgt, Durchfluss bricht ein, Sicherheitsventile reagieren. Was eigentlich eine einzige Ursache hat, erscheint im Leitsystem als Dutzende parallele Meldungen — und welche davon die Ursache ist und welche nur Folgeerscheinungen sind, das muss der Operator in Echtzeit unter Druck herausfinden.

Die Normen der Branche beschreiben das Problem präzise: NAMUR NE 102 legt als Richtwert maximal einen Alarm pro zehn Minuten im Normalbetrieb und maximal zehn Alarme in zehn Minuten bei einer Störung fest. In der Praxis sieht das häufig anders aus: Ein typisches Chemiewerk, das über Jahre gewachsen ist, hat im Schnitt drei- bis fünfmal mehr aktive Alarmpunkte als nach dieser Norm zulässig wäre — mit entsprechendem Rauschen bei jeder Störung.

Die finanziellen Konsequenzen sind erheblich: Laut Siemens Senseye “True Cost of Downtime 2024” (Bericht auf Basis von 3.215 Instandhaltungsverantwortlichen weltweit) kostet eine ungeplante Stillstandsstunde in der Industrie durchschnittlich 125.000 US-Dollar. Für deutsche Spezialchemiebetriebe liegt die Bandbreite je nach Reaktorgröße und Produktwert typisch zwischen 5.000 und 100.000 Euro pro Stunde. Ein Betrieb, der pro Monat fünf solcher Ereignisse hat und die Diagnosezeit von 90 auf 20 Minuten verkürzt, spart damit rechnerisch 40.000 bis 200.000 Euro monatlich — und das ist nur der direkte Produktionsverlust, ohne Qualitätseinbußen beim Hochfahren, ohne Materialverschleiß, ohne die verlorene Arbeitszeit der Nachtschicht.

Das eigentliche Problem liegt oft nicht im Fehlen der richtigen Information — sie steckt bereits im System. Historische Alarmdaten, Wartungsprotokolle aus dem CMMS, Schichtberichte und Sensorverläufe: In einem gut geführten Betrieb sind die meisten Störungsursachen schon einmal aufgetreten und dokumentiert. Nur findet der Schichtleiter um 2:47 Uhr diese Information nicht in zwei Minuten, sondern in neunzig.

Mit vs. ohne KI — ein ehrlicher Vergleich

Die Verbesserungen bei der Diagnosegenauigkeit stammen aus Branchenerfahrungswerten und publizierten Implementierungen (u.a. Yokogawa Applied AI, 2023). Kein KI-System diagnostiziert allein — der menschliche Operator bleibt die letzte Entscheidungsinstanz. Die KI reduziert den Suchraum, ersetzt aber nicht das Urteilsvermögen des Schichtleiters.

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5)
Die Diagnosezeit lässt sich von 60–120 Minuten auf 10–20 Minuten verkürzen — ein Faktor vier bis sechs in der Reaktionszeit auf eine laufende Störung. Das ist einer der stärksten Zeitgewinne im gesamten Chemie-Anwendungsfeld, weil er genau in dem Moment greift, wenn jede Minute direkte Kosten verursacht. Kein Büroprozess, kein Reporting-Tool kann einen ähnlich unmittelbaren finanziellen Hebel bieten. Einzige Einschränkung: Der Zeitgewinn realisiert sich nur in den Momenten, in denen tatsächlich eine Störung auftritt — bei zuverlässigen Anlagen mit weniger als zwei bis drei Ereignissen pro Monat spürst du den Effekt seltener.

Kosteneinsparung — hoch (4/5)
Die potenziellen Einsparungen sind erheblich — aber direkt an die Häufigkeit und Schwere von Störungsereignissen geknüpft. Ein Betrieb mit seltenen, aber kostspieligen Störungen (zwei Mal im Jahr, je 50.000 Euro Schaden) kann durch schnellere Diagnose einen bedeutenden Teil davon einsparen. Ein Betrieb mit häufigen, aber günstigen Ereignissen (dreißig Mal im Jahr, je 1.000 Euro) profitiert weniger. In der Gesamtbetrachtung landet dieser Anwendungsfall im oberen Bereich des Chemie-Portfolios, weil die Stillstandskosten pro Stunde in Prozessanlagen strukturell hoch sind — vergleichbar mit Reaktorausbeute-Optimierung und Vorausschauender Wartung.

Schnelle Umsetzung — niedrig (2/5)
Vier bis sieben Monate bis zum produktiven Einsatz sind die realistische Untergrenze — und zwar nicht wegen der KI-Entwicklung selbst, sondern wegen der vorgelagerten Arbeit: Alarm-Rationalisierung nach NAMUR NE 102, Historiker-Anbindung, CMMS-Integration, Modelltraining auf gereinigten Historiedaten. Wer diesen Aufwand unterschätzt, landet bei einem System, das auf einem schlechten Datenfundament trainiert wurde — und entsprechend schlechte Diagnosen liefert.

ROI-Sicherheit — mittel (3/5)
Der ROI ist gut messbar, wenn genug Störungsereignisse vorhanden sind: Du zählst einfach, wie lange die Diagnose ohne und mit System dauert. Aber bei Betrieben mit weniger als fünf bis sechs messbaren Störungen pro Monat wird die statistische Basis für eine valide Aussage dünn. Außerdem: Die besten Verbesserungen passieren bei wiederkehrenden Störungsmustern — neuartige Störungen, die kein historisches Äquivalent haben, diagnostiziert das System schlechter als ein erfahrener Ingenieur.

Skalierbarkeit — mittel (3/5)
Jede Anlage, jede Produktionslinie braucht ein eigenes Modell — trainiert auf den spezifischen Sensordaten, Alarmpunkten und Betriebsmodi dieser Anlage. Ein Modell für Reaktor R-101 lässt sich nicht eins zu eins auf Reaktor R-202 übertragen, auch wenn beide baugleich sind, weil die Betriebshistorie, der Rohstoffmix und die Konfiguration abweichen. Skalierung bedeutet hier: pro Anlage Onboarding-Aufwand, keine zentrale Lösung für den ganzen Standort.

Richtwerte — stark abhängig von Anlagentyp, Störungshäufigkeit und vorhandener Dateninfrastruktur.

Was das KI-System konkret macht

Klassische Leitsysteme wie DCS oder SCADA zeigen Alarme in der Reihenfolge, in der sie ausgelöst werden — nicht in der Reihenfolge ihrer Kausalität. Das führt dazu, dass Folgealarm Nummer siebenundzwanzig oft oben im Stack steht, während der eigentliche Auslöser weit unten vergraben ist. Das Gehirn des Schichtleiters muss unter Zeitdruck eine kausale Reihenfolge aus einem zeitlichen Datenstrom rekonstruieren — eine Aufgabe, für die Menschen nicht gut ausgestattet sind.

Das KI-System macht genau diese Rekonstruktion — systematischer, schneller und ohne die kognitive Belastung einer Alarmflut.

Schritt 1: Alarmkorrelation. Das System analysiert die Zeitstempel aller ausgelösten Alarme und prüft, ob dieses Muster einem historisch bekannten Störungsfall ähnelt. Es berücksichtigt nicht nur, welche Alarme ausgelöst wurden, sondern in welcher zeitlichen Abfolge — denn die Kausalität steckt in der Reihenfolge, nicht in der Gleichzeitigkeit.

Schritt 2: Ähnlichkeitssuche im CMMS. Wenn ein Muster gefunden wird, das einer bekannten Störung ähnelt, ruft das System die historischen Wartungsberichte aus dem CMMS ab: Was war die Ursache damals? Was war die Behebungsmaßnahme? Wie lange dauerte die Reparatur? Diese Information erscheint direkt im Operator-Interface — mit Ähnlichkeitsscore und Link zum vollständigen Wartungsbericht.

Schritt 3: Ursachenhypothese. Das System gibt nicht eine einzige Diagnose aus, sondern eine priorisierte Liste: “Wahrscheinlichste Ursache (78 %): Kavitation in Pumpe P-204 — bestätigt durch Vibrationsanomalie Sensor VS-204 und niedrigen Zulaufdruck. Zweithäufigste Ursache (14 %): Verschmutzung Wärmetauscher WX-11.”

Schritt 4: Behebungsschritte. Zur wahrscheinlichsten Diagnose zeigt das System die dokumentierten Behebungsschritte aus dem CMMS — keine Interpretation, sondern direkte Verknüpfung mit der Betriebsdokumentation, die dein Team selbst erstellt hat.

Technisch basiert das auf einer Kombination aus zeitlicher Mustererkennung (Machine Learning auf Alarmsequenzen), Ähnlichkeitssuche in der Alarmhistorie und Predictive Analytics auf den Sensorzeitreihen. Das Ergebnis ist kein Orakel, sondern eine strukturierte Entscheidungshilfe — ein erfahrener Schichtleiter bleibt die letzte Instanz.

Alarmdaten-Bereinigung: Die Hausaufgabe vor dem KI-Einsatz

Das ist der Teil, über den Softwareanbieter gerne schweigen, weil er weder glamourös noch schnell ist — aber er entscheidet darüber, ob dein KI-System brauchbare oder wertlose Diagnosen liefert.

Das Problem heißt Alarm-Rauschen. Wenn deine Alarmhistorie voll mit Nuisance-Alarmen ist — Alarme, die routinemäßig ausgelöst werden und routinemäßig ignoriert werden — lernt das KI-Modell genau das: dass diese Alarme nichts bedeuten. Es lernt Muster aus Daten, die selbst kein echtes Signal enthalten. Das Modell wird so gut wie die Daten, auf denen es trainiert wurde.

NAMUR NE 102 und EEMUA 191 definieren klare Richtwerte. Eine praktisch gute Faustregel: Wenn ein einzelner Alarmpunkt mehr als zwölf Mal pro Monat im Normalbetrieb auslöst, ist er ein Nuisance-Alarm und muss vor dem KI-Rollout entweder neu parametriert, supprimiert oder in eine Benachrichtigung (statt Alarm) umgewandelt werden.

Wie die Bereinigung aussieht in der Praxis:

1. Alarm-Rationalisierung: Export der Alarmdaten der letzten 12–24 Monate aus dem Leitsystem. Klassifikation nach Häufigkeit und Quittierungszeit — Alarme, die innerhalb von zwei Sekunden quittiert werden, sind regelmäßig Scheinalarme.
2. Ursachenanalyse für Top-Störer: Die zwanzig häufigsten Alarmpunkte werden einzeln analysiert. Falsche Grenzwerte? Kaputter Sensor? Prozessparameter, der immer am Grenzwert läuft? Jeder davon wird korrigiert — nicht ausgeblendet.
3. Dokumentation des Ist-Zustands: Erst wenn die Alarmstruktur den NAMUR-Richtwerten nahekommt, wird der KI-Rollout gestartet. Dieser Schritt dauert vier bis acht Wochen bei einem mittelgroßen Betrieb — aber er ist die Investition, die den Unterschied zwischen einem nützlichen und einem nutzlosen System macht.

Viele Betriebe berichten, dass die Alarm-Rationalisierung allein — ohne jede KI — zu messbarer Effizienzverbesserung führt. Das ist ein gutes Zeichen. Nicht weil die KI überflüssig ist, sondern weil es zeigt, dass die Datengrundlage stimmt.

Konkrete Werkzeuge — was wann passt

Die Werkzeugwahl hängt stark davon ab, welche Infrastruktur bereits existiert und wie groß dein Betrieb ist.

AVEVA PI System — der Historiker als Datenfundament
Wenn dein Betrieb bereits AVEVA PI als Process Historian betreibt, hast du das Datenfundament für den KI-Rollout bereits. PI speichert Millionen von Sensorwerten in Echtzeit — genau das Rohmaterial, aus dem Alarmkorrelationsmodelle gebaut werden. Die eigentliche Alarm-Analytics-Schicht kommt entweder als PI-Modul (PI Event Frames) oder als Drittanwendung darüber. Kosten: PI-Lizenzen über Anfrage; Erfahrungswerte zeigen fünfstellige EUR-Jahresbeträge für mittlere Deployments.

Seeq — für Root-Cause-Analyse ohne Data-Science-Team
Seeq ist speziell für Prozessingenieure gebaut, nicht für Data Scientists. Es verbindet sich direkt mit AVEVA PI und anderen Historikern, bietet visuelles Korrelations-Toolset, und ermöglicht mit Seeq Data Lab Python-basierte Alarmsequenz-Modelle — ohne dass du eigene ML-Infrastruktur aufbauen musst. Besonders geeignet für mittelgroße Chemiestandorte, die einen Ingenieur mit Prozessverständnis (aber ohne ML-Hintergrund) für das Projekt einsetzen können. Kosten: ca. 1.000–1.200 USD/Nutzer/Jahr.

ABB Genix — Komplettplattform für Großanlagen
ABB Genix System Anomaly Detection ist eine vollintegrierte Lösung für Großkonzerne mit ABB-Equipment. Das System erkennt Anomalien über gesamte Anlageverbünde hinweg und unterstützt root cause identification mit vortrainierten Industrie-Modellen. Geeignet für Standorte ab ca. 500 Mitarbeitenden mit eigenem OT/IT-Team und sechsstelligem Projektbudget. Kosten: ausschließlich auf Anfrage.

Siemens Insights Hub — für Siemens-Infrastruktur
Wer bereits SIMATIC-Leitsysteme und Siemens Industrial Edge betreibt, findet mit Insights Hub eine native Anbindung ohne aufwendige Middleware. Geeignet für Multi-Standort-Betreiber mit Siemens-Backbone, weniger sinnvoll für herstellergemischte Anlagen. Kosten: Enterprise-Preise auf Anfrage; EU-Hosting in EU-Rechenzentren.

IBM Maximo — wenn das CMMS die eigentliche Quelle ist
Maximo Application Suite hat mittlerweile integrierte KI-Funktionen für predictive maintenance und Anomalie-Korrelation. Wenn euer CMMS bereits IBM Maximo ist und dort die Wartungshistorie gepflegt wird, ist die KI-Schicht im bestehenden System aktivierbar — ohne Drittanbieter. Der Vorteil: Die Diagnosevorschläge sind direkt mit den Arbeitsauftrags-Workflows verknüpft. Der Nachteil: Maximo ist Enterprise-Software mit entsprechenden Implementierungsaufwänden. Ab ca. 3.000–8.000 USD/Monat für kleine SaaS-Deployments.

Zusammenfassung: Wann welcher Ansatz

• AVEVA PI vorhanden, Ingenieur verfügbar → Seeq als Analyse-Schicht drüber
• ABB-Equipment, Konzernbudget → ABB Genix System Anomaly Detection
• Siemens-Maschinenpark, mehrere Standorte → Siemens Insights Hub
• IBM Maximo bereits im Einsatz → KI-Module in Maximo aktivieren
• Kein Historian vorhanden → zuerst Historian implementieren, dann KI

Integrations-Realität: DCS, Historian und CMMS zusammenbringen

Wer noch nie ein industrielles KI-Projekt gemacht hat, unterschätzt diesen Teil regelmäßig. Die eigentliche Arbeit in einem Störungsdiagnose-Projekt ist nicht das KI-Modell — es ist die Verbindung der Systeme.

Ein typischer Chemiebetrieb hat vier bis sechs technische Systeme, die für eine vollständige Störungsdiagnose relevant sind:

• DCS/Leitsystem (Siemens PCS 7, Emerson DeltaV, Yokogawa Centum) — Echtzeitdaten, Alarme
• Process Historian (AVEVA PI, OSIsoft, InfluxDB) — Zeitreihenspeicher
• CMMS (SAP PM, IBM Maximo, IFS) — Wartungshistorie, Ersatzteile, Schichtberichte
• LIMS (Laborinformationssystem) — Qualitätsdaten, Proben
• ERP (SAP S/4HANA) — Produktionsaufträge, Materialeinsatz

Diese Systeme sprechen in der Regel nicht miteinander. Die KI braucht Daten aus mehreren davon gleichzeitig — und zwar synchronisiert auf einen gemeinsamen Zeitstempel. Das ist die eigentliche Integrationsarbeit.

Was in der Praxis passiert:

Das DCS exportiert Alarme über OPC-UA oder OPC-DA in den Historian. Das CMMS hat Wartungsberichte in einem eigenen Datenbankformat. Das LIMS hat Laborergebnisse in wiederum anderem Format. Keiner dieser Datenpunkte hat den gleichen Zeitstempel-Standard. Die Implementierung einer Alarm-Analytics-Lösung bedeutet faktisch: zuerst diese Systeme per Middleware (z.B. Azure IoT Hub, Kepware) anbinden, die Zeitstempel harmonisieren und in eine gemeinsame Datenpipeline bringen.

Erfahrungswert aus Implementierungsprojekten: Diese Integrationsarbeit nimmt bei mittelgroßen Betrieben 40–60 Prozent der Gesamtprojektzeit in Anspruch. Plane sie nicht als Randthema, sondern als eigenständige Projektphase mit eigenem Budget und einer klar benannten verantwortlichen Person auf der OT-Seite.

Was das für die Werkzeugwahl bedeutet:
Wenn dein Betrieb bereits einen guten Historian hat (AVEVA PI oder ähnlich) und das CMMS über eine REST-API oder SAP-Schnittstelle zugänglich ist, ist die Integration deutlich schneller als von Null. Wenn beides fehlt oder auf proprietären Systemen ohne Schnittstellen läuft, verdoppelt sich der Implementierungsaufwand realistisch.

Datenschutz und Datenhaltung

Gute Neuigkeit: Die Kerndaten für ein Störungsdiagnose-System sind Maschinendaten — Temperatur, Druck, Durchfluss, Alarmstatus. Diese sind in der Regel keine personenbezogenen Daten im Sinne der DSGVO und unterliegen damit nicht dem vollen DSGVO-Pflichtenprogramm.

Problematisch wird es an zwei Stellen:

Schichtprotokolle und Kommentare. Wenn Schichtberichte aus dem CMMS in das Diagnose-System einfließen, können diese personenbezogene Informationen enthalten — Schichtleiter-Namen, Bemerkungen über bestimmte Mitarbeitende, handschriftliche Anmerkungen. Hier gilt DSGVO, und ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO ist Pflicht, sobald diese Daten an einen Cloud-Anbieter übertragen werden.

Cloud-Hosting oder On-Premises? Für viele chemische Betriebe — besonders wenn sie unter NIS-2-Regulierung fallen, kritische Infrastruktur betreiben oder mit Kunden-Rezeptur-Daten arbeiten — ist ein reines Cloud-Deployment keine Option. Die gute Nachricht: Alle relevanten Plattformen (AVEVA PI, Seeq, IBM Maximo) unterstützen Hybrid- oder On-Premises-Deployments. Für DSGVO-konforme Cloud-Nutzung bieten Siemens Insights Hub (EU-Rechenzentren) und Azure ML (Frankfurt, Amsterdam) valide EU-Optionen.

NIS-2-Relevanz: Betriebe, die als kritische Infrastruktur oder wichtige Einrichtung nach NIS-2 eingestuft werden (was viele Chemiebetriebe ab einem bestimmten Umsatz betrifft), haben zusätzliche Anforderungen an die IT-Sicherheit ihrer OT-Systeme. Eine KI-Schicht auf dem Leitsystem ist ein neuer Angriffspunkt — Security-by-Design muss im Projekt von Anfang an berücksichtigt werden, nicht nachträglich.

Was es kostet — realistisch gerechnet

Einmalige Projektkosten

• Alarm-Rationalisierung (NAMUR-Konformität herstellen): 2–6 Wochen interne Kapazität + externer Berater 10.000–25.000 €
• Historian-Anbindung und Daten-Pipeline: 15.000–40.000 €, stark abhängig von Systemkomplexität
• CMMS-Integration: 10.000–30.000 €
• KI-Modellentwicklung und -konfiguration: 20.000–50.000 €
• Gesamtprojektbudget: 50.000–150.000 € für einen mittelgroßen Chemiebetrieb; Enterprise-Lösungen (ABB Genix, vollintegrierte Siemens-Plattform) deutlich darüber

Laufende Kosten

• Seeq: ca. 1.000–1.200 USD/Nutzer/Jahr
• AVEVA PI (bestehendes System): Marginalkosten durch hinzukommende PI-Module
• IBM Maximo SaaS: 3.000–8.000 USD/Monat (Basis-Deployment)
• Interne Pflegekapazität: ca. 0,2–0,5 FTE/Jahr für Modell-Updates und neue Anlagentypen

Konservatives ROI-Szenario
Ausgangslage: 8 Störungsereignisse pro Monat, durchschnittliche Diagnosezeit heute: 75 Minuten, mit KI: 18 Minuten. Durchschnittlicher Stillstandsschaden: 10.000 €/Stunde (kleines bis mittleres Chemiewerk).

Zeitersparnis: 57 Minuten × 8 Ereignisse = 456 Minuten = 7,6 Stunden/Monat.
Finanzieller Gegenwert: 7,6 × 10.000 € = 76.000 €/Monat (Orientierungswert, nicht garantiert).
Amortisation eines 100.000-€-Projekts: 1–2 Monate bei dieser Parameterkombination.

Realitätscheck: In der Praxis liegt der realisierte Effekt in den ersten Monaten bei 40–60 Prozent des theoretischen Werts — weil Modelle nachjustiert werden, das Team sich einarbeiten muss und nicht jede Störung einem bekannten Muster entspricht. Selbst bei 40 Prozent beträgt die Amortisationszeit vier bis fünf Monate.

Wie du den ROI tatsächlich misst:
Vor dem Rollout: Für jedes Störungsereignis den Zeitstempel “Alarm ausgelöst” und “Ursache identifiziert” manuell dokumentieren (Schichtprotokoll). Nach dem Rollout: Die gleiche Messung, jetzt mit System. Die Differenz ist dein tatsächlicher Effekt — für externe Stakeholder und Geschäftsleitung.

Drei typische Einstiegsfehler

1. Auf dem unbereinigten Alarmsystem trainieren.
Der schnellste Weg zu einem nutzlosen Diagnose-KI ist, das Modell auf einem Alarmsystem zu trainieren, das voller Nuisance-Alarme steckt. Das System lernt dann: “Diese 47 Alarme feuern immer gleichzeitig und bedeuten nichts.” Die Diagnose für echte Störungen ist anschließend unzuverlässig. Lösung: Alarm-Rationalisierung vor dem Training — nicht optional, sondern Pflichtschritt.

2. Das CMMS nicht synchron pflegen.
Das Diagnose-System lernt aus historischen Wartungsberichten. Wenn diese Berichte zu 30 Prozent lückenhaft sind, zu 20 Prozent falsche Ursachen enthalten, weil der Schichtleiter “Diverses” als Kategorie einträgt, und die letzten drei Monate noch nicht eingearbeitet sind — dann hat das System eine schlechte Lerngrundlage. Die Datenqualität im CMMS ist eine organisatorische Daueraufgabe. Sie muss vor dem KI-Projekt beginnen und danach konsequent weitergeführt werden.

3. Das Modell nie wieder anfassen, nachdem es einmal läuft.
Das ist der klassische Konzeptdrift-Fehler. In einer Prozessanlage ändert sich regelmäßig etwas: neuer Rohstoff, neue Produktrezeptur, Umbau in Anlagenteil B, neue Pumpe in Sektion 4. Jede dieser Änderungen verschiebt die Alarmcharakteristik der betroffenen Anlagenteile. Ein Modell, das vor zwölf Monaten auf den alten Zustand trainiert wurde, liefert für den neuen Zustand schlechtere Diagnosen — ohne offensichtlichen Fehler, still degradierend. Lege daher beim Rollout eine klare Retraining-Triggerregel fest: Jede signifikante Anlagenänderung löst eine Modell-Überprüfung aus. Und ein jährliches Review sowieso.

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

Die Technik ist auch bei diesem Anwendungsfall das Einfachere. Die menschliche Seite ist komplizierter.

Widerstandsmuster 1: Die erfahrenen Schichtleiter.
Jeder gut geführte Chemiebetrieb hat zwei oder drei Schichtleiter, die seit zwanzig Jahren wissen, was jeder Alarm bedeutet. Die sehen kein System auf dem Bildschirm — die hören am Geräusch der Pumpe, ob es Kavitation ist. Für diese Menschen ist das KI-System im besten Fall überflüssig, im schlimmsten Fall eine Bedrohung ihres Status als unverzichtbarer Wissensträger. Was hilft: Diese Schichtleiter nicht übergehen, sondern aktiv einbinden — ihre Erfahrungen sollen das System besser machen, nicht ersetzt werden. Lass sie die historischen Referenzfälle validieren, aus denen das Modell lernt. Wer am Aufbau des Systems mitgearbeitet hat, ist kein Gegner mehr.

Widerstandsmuster 2: Das System liegt daneben.
Kein KI-System hat beim ersten Einsatz 100 Prozent Trefferquote. Wenn ein Schichtleiter zweimal hintereinander eine andere Diagnose als das System hatte — und er Recht hatte — ist das Vertrauen weg. Dieser Effekt ist vorhersehbar und vermeidbar: Führe in den ersten drei Monaten eine explizite “Lernphase” ein, in der das System Diagnosevorschläge macht, aber der Schichtleiter seine eigene Einschätzung daneben setzt. Abweichungen werden dokumentiert und fließen als Korrektursignal zurück. Das System lernt weiter, und das Team erlebt sichtbar, dass ihre Einschätzungen das Modell verbessern.

Was konkret hilft:

• Benenne eine verantwortliche Person aus dem Betrieb (kein IT-Mensch, sondern jemand aus der Produktion), der das System “vertritt” — Ansprechpartner für Schichtleiter, Feedback-Kanal in die Weiterentwicklung
• Plane drei Monate für die Kalibrierungsphase ein — in dieser Zeit ist das System noch kein verlässliches Diagnose-Tool, sondern ein lernender Prototyp
• Kommuniziere klar: Das System macht einen Vorschlag. Der Schichtleiter entscheidet. Immer.

Realistischer Zeitplan mit Risikohinweisen

Wichtig: Die Phasen überlappen sich bewusst — Modelltraining beginnt, bevor die Integration vollständig abgeschlossen ist, um Kalibrierungszeit zu gewinnen. Plane 28–32 Wochen für einen vollständigen produktiven Einsatz bei einem mittelgroßen Betrieb.

Häufige Einwände — und was dahintersteckt

„Wir haben schon NAMUR-konformes Alarmmanagement.”
Das ist tatsächlich eine gute Voraussetzung — dann überspringst du den längsten Vorbereitungsschritt. Prüfe trotzdem: Ist die Alarmhistorie der letzten 24 Monate digital verfügbar und exportierbar? Sind die Wartungsberichte im CMMS vollständig und mit korrekter Ursachenklassifikation versehen? NAMUR-Konformität in der Leitsystem-Konfiguration reicht nicht — die Datenqualität in der Alarmhistorie und im CMMS ist der eigentliche Gradmesser.

„Unsere Störungen sind zu individuell für ein KI-Modell.”
Kein Betrieb hat ausschließlich neuartige Störungen. Erfahrungsgemäß sind 70–80 Prozent der Störungsereignisse in einem gut geführten Chemiebetrieb wiederkehrende Muster — dieselben Ventile, dieselben Pumpen, dieselben Temperatur-Druck-Konstellationen, die unter ähnlichen Betriebsbedingungen ähnliche Alarme auslösen. Für genau diese Fälle ist das KI-System am wertvollsten. Für echte Novitäten bleibt das Modell stumm oder gibt niedrige Wahrscheinlichkeitswerte aus — und dann übernimmt der erfahrene Ingenieur. Das ist kein Fehler des Systems, sondern das korrekte Verhalten.

„Das funktioniert nur bei großen Konzernen mit riesigen Datenmengen.”
Nein — aber es braucht eine Mindestdatenmenge. Die Faustregel: Für ein nützliches Alarmkorrelationsmodell sind mindestens 200–300 dokumentierte Störungsereignisse im CMMS notwendig, verteilt über verschiedene Anlagenteile. Bei einem mittelgroßen Chemiebetrieb mit acht Störungen pro Monat sind das 24–38 Monate Betriebshistorie. Die meisten Betriebe haben diese Daten — sie sind nur nicht strukturiert genug.

Woran du merkst, dass das zu dir passt

• Deine Anlage hat mehr als fünf Alarmfeuerereignisse pro Monat, die aktive Diagnosearbeit durch den Schichtleiter erfordern — nicht nur kurze Quittierungen
• Die Diagnosezeit liegt regelmäßig über dreißig Minuten, und ihr habt das Gefühl, dass erfahrene Schichtleiter das schneller lösen würden als jüngere
• Ihr habt einen Process Historian (AVEVA PI, InfluxDB oder ähnlich) mit mindestens zwölf Monate Alarmhistorie
• Euer CMMS enthält vollständige Wartungsberichte mit Ursachenklassifikation für die letzten zwei bis drei Jahre
• Jede Stillstandsstunde kostet mehr als 5.000 Euro — darunter wird die Amortisationszeit des Projekts lang

Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:

1. Weniger als drei bis vier Störungsereignisse pro Monat mit echter Diagnosepflicht. Dann ist die Datenbasis für Mustererkennung zu dünn, und die Amortisationszeit des Projekts überschreitet fünf Jahre. Ein strukturierter manueller Postmortem-Prozess mit gut gepflegtem CMMS ist für solche Betriebe wertvoller als eine KI-Lösung.

2. Kein digitaler Historian mit Echtzeit-Sensordaten. Wenn eure Sensordaten nicht in einem Process Historian landen (oder nur als Tagesdurchschnittswerte in Excel), hat eine Alarmkorrelations-KI kein Rohmaterial. Die Voraussetzung ist ein laufender Historian — nicht nur ein SCADA-System ohne Langzeitarchivierung.

3. Das CMMS ist nicht vollständig gepflegt oder die Ursachenklassifikation fehlt. Wenn euer CMMS zwar existiert, aber Wartungsberichte zu 40 Prozent ohne Ursache abgeschlossen wurden oder die Kategorien “Sonstiges” und “Diverses” die häufigsten Einträge sind, hat das Modell keine Lerngrundlage. Das Ziel: Mindestens 80 Prozent der Störungsfälle im CMMS haben eine eindeutige Ursachenklassifikation — bevor der KI-Rollout beginnt.

Das kannst du heute noch tun

Starte mit einer Alarmanalyse — kostenlos, ohne externe Hilfe, in einem Nachmittag.

Exportiere die Alarmdaten der letzten sechs Monate aus deinem Leitsystem (die meisten DCS-Systeme haben einen integrierten Alarm-Historienbericht). Zähle: Wie viele einzigartige Alarmpunkte haben mehr als zwölf Auslösungen pro Monat im Normalbetrieb? Das sind deine Nuisance-Alarme — und du kannst diese Liste sofort als Grundlage für die nächste Instandhaltungsbesprechung nutzen.

Parallel dazu kannst du Seeq auf einer kostenlosen Demo-Session evaluieren — die Demo erlaubt dir, mit eigenen Historian-Daten zu arbeiten und das Korrelations-Toolset zu testen.

Für die nächste Störungsdiagnose in deiner Anlage: Gib einfach die Alarmsequenz in einen LLM wie Claude oder ChatGPT und frage nach möglichen Ursachen. Du wirst überrascht sein, was ein gut gebauter Prompt schon liefert — nicht als Ersatz für ein trainiertes System, aber als schnelle Orientierung, wenn du eine Störung noch nicht kennst.

Quellen & Methodik

• Siemens Senseye “True Cost of Downtime 2024”: Studie auf Basis von 3.215 Instandhaltungsverantwortlichen global; unerwarteter Stillstand kostet Großunternehmen 11 % des Jahresumsatzes. Verfügbar als PDF unter assets.new.siemens.com (2024).
• Deloitte / Innovapptive (via Accruent): Durchschnittlicher Produktionsverlust pro Stillstandsstunde in der Chemieindustrie: ca. 100.000 USD. Quelle: Aberdeen Group “Asset Performance Management: Blazing a Better Path to Operational Excellence” (zitiert in Branchenberichten 2023–2024).
• Yokogawa Applied AI — AI for Process Abnormality Diagnosis: Yokogawa-Fallstudien zur KI-basierten Störungsdiagnose in Benzinreaktor und Kühlturm; Aktivierung eines “OODA-Loop”-Ansatzes zur Root-Cause-Identifikation. Verfügbar unter yokogawa.com (2023).
• NAMUR NE 102: NAMUR-Empfehlung Alarmmanagement — max. 1 Alarm/10 Minuten im Normalbetrieb, max. 10 Alarme/10 Minuten bei Störung. Branchenstandard für Prozessleittechnik in der Chemie.
• EEMUA 191 (4th Edition, 2024): Engineering Equipment and Materials Users Association — Alarmmanagement-Standard für die Prozessindustrie; 4. Ausgabe November 2024.
• Alarmflood-Beispiel Chemieanlage am Niederrhein: Aus CHEManager / process.vogel.de — 160 Alarme in Sekunden bei Temperaturanstieg; typisches Alarm-Flood-Szenario im Chemiebetrieb (2023).
• Implementierungskosten und Laufzeitkosten: Erfahrungswerte aus industriellen Integrationsprojekten für Alarm-Analytics in der Prozessindustrie (Stand April 2026).
• Seeq-Preise: Veröffentlichte Lizenzinformationen des Anbieters: ca. 1.000–1.200 USD/Nutzer/Jahr für die Workbench-Lizenz (Stand April 2026).

Du willst wissen, ob euer Alarmaufkommen und eure CMMS-Datenqualität für ein solches Projekt ausreichen? Meld dich — das lässt sich in einem kurzen Gespräch einschätzen, ohne Beratervertrag.