Reaktorausbeute durch KI-Prozessoptimierung steigern

Das echte Ausmaß des Problems

Ausbeuteschwankungen in chemischen Reaktoren sind kein Randproblem. Sie sind der unsichtbare Feind der Produktionsökonomie — weil sie nicht in einem einzelnen Großereignis sichtbar werden, sondern in der kumulierten Differenz zwischen dem, was ein Reaktor könnte, und dem, was er tatsächlich liefert.

Fachleute sprechen vom “yield gap”: die Lücke zwischen der theoretisch erreichbaren Ausbeute (oft aus Laborversuchen bekannt) und dem tatsächlichen Betriebsergebnis unter realen Bedingungen. Dieser Gap liegt bei vielen kontinuierlichen und Batch-Prozessen zwischen 3 und 8 Prozentpunkten — gelegentlich höher, wenn Rohstoffschwankungen, Katalysatordrift und Anlagenverschleiß zusammenkommen.

Was das wirtschaftlich bedeutet, lässt sich nüchtern kalkulieren: Bei einem Bulk-Produkt mit 50 €/kg Rohstoffwert und 10.000 t/Jahr Produktion entspricht jeder Ausbeute-Prozentpunkt rund 500.000 Euro jährlich. Bei Spezialchemikalien mit 200–500 €/kg Rohstoffwert verdoppelt oder vervierfacht sich dieser Betrag. Laut Industriedaten aus APC-Deployments (Quelle: LeKa Control, 2020, basierend auf über 500 dokumentierten APC-Projekten) erzielen Werke, die Machine Learning und Advanced Process Control konsequent einsetzen, durchschnittlich 2 % Ausbeutesteigerung und 2–10 % Energieeinsparung — bei einer Reduktion der Produktqualitätsvarianz um bis zu 50 %.

Ein weiteres Problem, das in der Diskussion oft übersehen wird: die Streuung. Konstante 85 % Ausbeute ist besser als ein Mittelwert von 86 % bei einer Schwankungsbreite von ±4 %. Denn die Ausreißer nach unten produzieren Off-Spec-Material, das entweder nachbearbeitet werden muss oder als Nebenprodukt abgeführt wird — zu deutlich geringeren Erlösen. Ein Predictive Analytics-System, das die Streuung reduziert, erzeugt wirtschaftlichen Wert, bevor es die mittlere Ausbeute auch nur um einen halben Prozentpunkt verschoben hat.

Warum ist das Problem trotzdem ungelöst in so vielen Werken? Nicht wegen mangelnder Messtechnik — im Gegenteil. Moderne Prozessleitsysteme erzeugen Datenmengen, die klassische statistische Methoden überfordern. Ein Reaktor mit 50 Messpunkten im Sekundentakt liefert pro Jahr über 1,5 Milliarden Messpunkte. Die Korrelation zwischen Parameterkonstellationen zu Beginn eines Batches und dem Ergebnis sechs Stunden später — über Temperaturgradienten, Rührwerksprofile, Druckverlauf, Zulaufmengen — liegt in diesen Daten. Aber sie ist nicht mit einfachen Tabellenkalkulationen zu heben.

Mit vs. ohne KI — ein ehrlicher Vergleich

Vergleichswerte basierend auf über 500 dokumentierten APC/ML-Projekten in der Prozessindustrie (LeKa Control 2020, AspenTech Kundenberichte). Einzelergebnisse hängen stark von Rohstoffhomogenität, Katalysatorstabilität und Sensorqualität ab.

Einschätzung auf einen Blick

Zeitersparnis — niedrig (2/5)
Ein ML-Optimierungssystem spart keine Arbeitszeit im klassischen Sinne — es verändert, was in dieser Zeit entsteht. Operatoren verbringen nicht weniger Stunden am Reaktor, sondern führen ihn unter besseren Parametern. Der direkte Zeitgewinn ist gering; der wirtschaftliche Effekt liegt komplett auf der Kosteneinsparungs- und Ertragsseite. Im Branchenvergleich — wo Batch-Protokollautomatisierung oder Sicherheitsdatenblatt-Generatoren echte Arbeitsstunden einsparen — ist dieser Use Case das klare Schlusslicht auf der Zeitersparnis-Achse.

Kosteneinsparung — sehr hoch (5/5)
Das ist der dominante Nutzen und der Grund, warum die Ausbeuteoptimierung trotz hoher Implementierungskosten wirtschaftlich attraktiv ist. Jeder Ausbeute-Prozentpunkt hat einen direkten Rohstoffgeldwert — anders als bei indirekten Einsparungen durch bessere Dokumentation oder schnellere Kommunikation. Bei Produktionsvolumina ab 500 t/Jahr und Rohstoffwerten über 50 €/kg lassen sich fünfstellige monatliche Einsparungen realisieren. Die höchste Kosteneinsparung unter allen hier verglichenen Chemie-Anwendungsfällen.

Schnelle Umsetzung — niedrig (2/5)
Von der Entscheidung zum validen ersten Ergebnis vergehen realistisch 4–8 Monate: Sensoraudit, Datenbereinigung, Modellentwicklung, Pilotbetrieb. Unter den verglichenen Chemie-Anwendungsfällen teilt dieser Use Case die niedrige Einstiegsbewertung mit der Produktionsplanung für chemische Anlagen — beide erfordern solide OT-Infrastruktur als Voraussetzung. Wer kein AVEVA PI System oder äquivalenten Historian betreibt, fügt noch 3–6 Monate Infrastrukturaufbau hinzu.

ROI-Sicherheit — hoch (4/5)
Die Ausbeute ist direkt messbar — es gibt keine Zuordnungsprobleme wie bei Wissensmanagement-Systemen, wo man nie sicher ist, ob die Einsparung dem Tool oder besserer Dokumentation zuzuschreiben ist. Ein Werk, das die mittlere Ausbeute von Batch-Periode A zu Periode B vergleicht, sieht sofort, ob der Effekt real ist. Dennoch kein 5er: Das Modell kann degradieren, Rohstoffchargen können die Basislinie verschieben, und der Effekt des ML-Systems lässt sich nicht immer sauber von gleichzeitigen Anlagenoptimierungen trennen. Solide ROI-Nachweisbarkeit, aber mit Sorgfalt zu messen.

Skalierbarkeit — sehr hoch (5/5)
Ein validiertes Modell für Reaktor R-07 erfordert für die Übertragung auf R-08 neues Training — aber die Methodologie, die Software-Infrastruktur und das interne Wissen bleiben. Jeder weitere Reaktor kostet einen Bruchteil des Erstprojekts. Auf Unternehmensebene: Wer die Methodik einmal etabliert hat, hat eine dauerhafte Kompetenz aufgebaut, die mit jedem weiteren Reaktor ROI generiert.

Richtwerte — stark abhängig von Produktionsvolumen, Rohstoffwert, Sensorinfrastruktur und vorhandener OT-Kompetenz.

Was das System konkret macht

Der technische Kern ist ein Modell, das aus historischen Prozessdaten lernt, welche Parameterkombinationen zu überdurchschnittlichen Ausbeuten führen. Es gibt zwei grundlegend verschiedene Ansätze, die unterschiedliche Reifegrade der Dateninfrastruktur voraussetzen:

Ansatz 1: Retrospektive Batch-Analyse (der einfachere Einstieg)

Das System liest alle historischen Batch-Protokolle aus dem Historian aus und segmentiert sie in “gute” Batches (überdurchschnittliche Ausbeute) und “schlechte” Batches. Ein Klassifikationsmodell — oft ein Gradient-Boosting-Modell wie XGBoost oder ein Random Forest — identifiziert, welche Parametermuster zu welchem Ergebnis gehören.

Das Ergebnis ist keine Echtzeit-Steuerung, sondern ein Erkenntnisbericht: “Die 15 % der besten Batches zeichnen sich durch eine Zulauftemperatur zwischen 78–82 °C in den ersten 40 Minuten, eine Rührerdrehzahl von 180–190 rpm ab Minute 25 und einen Druckaufbau von maximal 0,3 bar/min aus.” Diese Erkenntnis fließt in einen aktualisierten Betriebsstandard — Operatoren erhalten bessere Sollwert-Empfehlungen.

Ansatz 2: Echtzeitoptimierung (Closed-Loop)

Auf dem Historian-Datenfundament baut ein Prozessmodell auf, das nicht nur historisch analysiert, sondern in Echtzeit die optimalen nächsten Stellgrößen berechnet. Das ist der Ansatz von Model Predictive Control (MPC) wie AspenTech DMC3: Das System kennt den aktuellen Zustand des Reaktors (Temperatur, Druck, Konzentration, wenn Inline-Analytik vorhanden ist) und berechnet kontinuierlich, welche Stellgrößenänderungen in den nächsten 5–60 Minuten den Reaktor auf dem Optimalweg halten.

Hier kommt der Begriff Advanced Process Control (APC) ins Spiel — und damit ein wichtiger Unterschied zu einfachen PI-Reglern (mehr dazu im nächsten Abschnitt).

Was das System nicht macht

Das Modell extrapoliert nicht über bekannte Bedingungen hinaus. Wenn ein Rohstofflieferant die Zusammensetzung einer Charge stark verändert, fährt das System weiter mit dem trainierten Modell — das dann auf einer verschobenen Basislinie optimiert. Es erkennt nicht selbstständig, dass es die Grundannahmen neu lernen müsste. Deshalb ist Monitoring unverzichtbar.

PI-Regler vs. ML-Optimierung — was passt wann

Viele chemische Anlagen sind bereits gut geregelt — mit PI-Reglern (proportional-integral), die Temperatur, Druck und Durchfluss auf Sollwert halten. Die naheliegende Frage ist: Warum reicht das nicht?

PI-Regler sind reaktiv und einvariabel. Ein Temperaturregler hält die Reaktortemperatur auf 80 °C, egal was sonst passiert. Er weiß nicht, dass die Zulaufkonzentration gerade geschwankt hat, dass der Katalysator in Woche 8 seines Lebenszyklus ist und langsamer anspricht, oder dass die optimale Temperatur bei dieser Rohstoffcharge eigentlich 78,5 °C wäre. Er regelt stur auf den vordefinierten Sollwert.

ML-Optimierung ist vorausschauend und multivariabel. Ein Modell predictive control-System berechnet, wie sich 20–200 Prozessvariablen in den nächsten Minuten entwickeln werden, und bestimmt die Stellgrößen so, dass der Reaktor auf dem Optimum bleibt — auch wenn mehrere Störgrößen gleichzeitig wirken. Es hält nicht nur einen Sollwert, es optimiert ein Zielfunktional (typischerweise maximale Ausbeute bei gegebenen Sicherheitsschranken).

Wann PI-Regler ausreichen:

• Hochkontinuierliche Prozesse mit sehr stabilen Rohstoffen und Betriebsbedingungen
• Kleines Produktportfolio (ein oder zwei Produkte) mit gut dokumentierten Sollwertplänen
• Anlage unter 200 t/Jahr — der wirtschaftliche Hebel der ML-Optimierung ist zu klein

Wann ML-Optimierung lohnt:

• Mehr als 5 gleichzeitig zu regelnde Prozessvariablen mit gegenseitigen Abhängigkeiten
• Rohstoffschwankungen, die regelmäßig manuelle Sollwertanpassungen durch den Operateur erfordern
• Mehr als 30 % der Optimierungsentscheidungen basieren auf Operator-Erfahrung statt dokumentierten Regeln
• Ausbeutevarianz von mehr als 2 % zwischen Batches unter scheinbar gleichen Bedingungen

Die ehrliche Einschätzung: Eine gut konfigurierte APC-Schicht mit AspenTech DMC3 oder vergleichbaren Produkten bringt typischerweise 60–80 % des theoretisch erreichbaren Optimierungspotenzials. Das verbleibende Potenzial liegt in Bereichen, die das Modell nicht kennt — Rohstoffqualitätsvariationen auf Molekülebene, Katalysatorzustand ohne Inline-Analytik. Wer diesen Rest heben will, braucht Inline-Spektroskopie oder regelmäßige Blind-Tests.

Sensorqualität als Grundvoraussetzung

Hier scheitern mehr ML-Projekte als an schlechten Algorithmen: Die Sensordaten, auf deren Basis das Modell trainiert wird, sind unbrauchbar — nicht augenfällig unbrauchbar, sondern subtil.

Sensorkorruption ist in chemischen Anlagen strukturell: Thermoelemente kalibrieren sich durch Messmedium-Ablagerungen langsam aus der Genauigkeit. Durchflussmessungen driften bei Viskositätsveränderungen der Medien. Drucksensoren zeigen eine schleichende Nullpunktverschiebung über Monate. Ein Sensor, der um 1,5 Kelvin aus der Kalibrierung driftet, meldet monatelang “37,5 °C” statt “39 °C” — systematisch, unbemerkt, und im Historien-Datensatz als Wahrheit gespeichert.

Das ML-Modell lernt auf diesen korrumpierten Daten und generiert eine Empfehlung, die unter realen Bedingungen falsch ist — aber mit der statistischen Zuversicht eines gut validierten Modells präsentiert wird. Das ist gefährlicher als kein Modell.

Sensoraudit vor Projektstart ist nicht optional. Ein gutes Projekt beginnt mit einer Analyse aller Sensoren auf bekannte Driftcharakteristika, fehlende Kalibrierungsprotokoll und physikalisch unmögliche Wertebereiche im historischen Datensatz. Typische Befunde:

• 5–15 % der Sensoren zeigen statistisch signifikante Drift über einen 2-Jahres-Zeitraum
• 2–8 % der Datenpunkte sind Nullwerte oder Stuck-Values (Sensor hängt auf letztem Wert)
• 10–25 % der nominell gleichen Messpunkte sind durch Wartungsmaßnahmen zeitweise verschoben

Was das für die Projektplanung bedeutet: Rechne 4–8 Wochen für den Sensoraudit und die Datenbereinigung ein — vor der ersten Zeile Modellcode. Bei umfangreicher Sensorinfrastruktur (200+ Messpunkte) kann allein dieser Schritt 3 Monate in Anspruch nehmen. Wer diesen Schritt überspringt, läuft in einen der drei klassischen Einstiegsfehler hinein (siehe unten).

Für die laufende Überwachung nach Go-Live: Definiere Grenzen, jenseits derer das System den Closed-Loop-Betrieb automatisch verlässt und auf manuellen Betrieb zurückfällt. “Sensor außerhalb der Kalibriergrenze” muss ein System-Alarm sein, kein Wartungsprotokoll-Eintrag vier Wochen später.

Konkrete Werkzeuge — was wann passt

Die Werkzeugwahl hängt weniger von den Fähigkeiten der Tools als von der vorhandenen OT-Infrastruktur und der Betriebsgröße ab.

AVEVA PI System — die Dateninfrastruktur, die fast immer am Anfang steht
AVEVA PI (früher OSIsoft PI) ist der De-facto-Standard für industrielle Prozessketten-Historisierung — in der Spezialchemie ist er bei Betrieben ab 50.000 t/Jahr nahezu universell. PI sammelt alle Sensorwerte in Echtzeit, speichert sie komprimiert über Jahre und stellt sie über REST-API und PI Datalink (Excel) für Analysen bereit. Wer kein PI oder einen gleichwertigen Historian betreibt, muss vor jedem ML-Projekt die Historian-Infrastruktur aufbauen — Mehraufwand von 3–9 Monaten. Lizenz ab 80.000 €/Jahr für mittelgroße Deployments, Implementierung: 50.000–200.000 €.

AspenTech DMC3 — Branchen-Standard für Closed-Loop-Optimierung
AspenTech DMC3 (Dynamic Matrix Control) ist das meisteingesetzte MPC-System in der Petrochemie und Feinchemie. Es baut auf dem Historian-Datenfundament auf, entwickelt ein empirisches Prozessmodell (Identifikation per Step Tests) und berechnet in Echtzeit optimale Stellgrößen für 20–200 Prozessvariablen gleichzeitig. Typische Projekte kosten 150.000–400.000 € Implementierung plus 30.000–120.000 €/Jahr Lizenz. Ergebnis: 1–3 % Ausbeutesteigerung, 2–10 % Energieeinsparung in dokumentierten Deployments. Richtig für: Betriebe ab 500 t/Jahr mit bestehendem AspenTech-Ökosystem.

ABB Genix — Enterprise-Plattform für ABB-ausgerüstete Anlagen
ABB Genix kombiniert Asset Performance Management mit ML-gestützter Prozessoptimierung und industriespezifischen Vormodellen für Chemie, Energie und Metall. Der integrierte “Genix Copilot” ermöglicht natürlichsprachige Abfragen auf OT-Daten. Enterprise-Plattform mit sechsstelligen Jahreskosten — sinnvoll für Konzerne, die bereits ABB-Leitsysteme betreiben und OT, IT und ET in einer Plattform konsolidieren wollen.

Siemens Insights Hub — IIoT-Cloud für Siemens-Maschinenparks
Für Chemiewerke mit Siemens-DCS (Simatic PCS 7 oder PCS neo) bietet Insights Hub eine werksübergreifende Datenbasis mit vorgefertigten Analytics-Apps. Predictive-Maintenance-Modelle und Prozessoptimierungs-Apps lassen sich über das Mendix-Ökosystem maßschneidern. EU-Hosting ist ein echter Vorteil. Sinnvoll für: Multi-Site-Betreiber, die Siemens-Automatisierungstechnik im Kern haben.

Azure ML + Python — der flexible Eigenentwicklungs-Pfad
Für Betriebe mit Data-Science-Kompetenz intern oder bei einem Systemintegrator ist der offene Ansatz oft die flexiblere und langfristig günstigere Alternative zu proprietären Plattformen: Historian-Daten via REST-API nach Azure ML exportieren, scikit-learn oder PyTorch-Modelle trainieren, Ergebnisse via OPC-UA zurück ins Leitsystem schreiben. Einstiegskosten signifikant niedriger als bei proprietären Systemen; dafür selbst für Modell-Monitoring, Retraining-Kadenz und Drift-Erkennung verantwortlich. EU-Hosting in Azure Frankfurt verfügbar. Richtig für: Betriebe, die langfristig interne ML-Kompetenz aufbauen wollen und die Abhängigkeit von Anbietern minimieren.

Zusammenfassung: Wann welcher Ansatz

• Kein Historian vorhanden → zuerst AVEVA PI System aufbauen, dann ML
• Bestehender AspenTech-Stack, >500 t/Jahr → AspenTech DMC3
• ABB-Leitsysteme, Enterprise-Budget → ABB Genix
• Siemens-Automatisierung, Multi-Site → Siemens Insights Hub
• Interne Data-Science-Kapazität vorhanden → Azure ML + Python

Datenschutz und Datenhaltung

Prozessdaten aus chemischen Reaktoren enthalten typischerweise keine personenbezogenen Daten — Temperaturen, Drücke, Durchflüsse und Ausbeuten sind Maschinendaten. Die DSGVO ist damit in der Regel nicht das primäre Thema. Was aber durchaus schützenswert ist: Betriebsgeheimnisse.

Reaktorparameter, Rohstoffkombinationen und Prozessrezepturen gehören zum Kern-Know-how eines Chemieunternehmens. Wenn diese Daten in die Cloud übertragen werden — sei es zu einem SaaS-Anbieter oder einer Hyperscaler-Plattform — besteht das Risiko, dass Wettbewerber oder der Anbieter selbst Rückschlüsse auf Prozess-Know-how ziehen können.

Für die konkreten Werkzeuge:

• AVEVA PI System: On-Premises-Deployment hält alle Daten lokal auf eigenen Servern — DSGVO und Betriebsgeheimnis-Anforderungen vollständig erfüllt. Cloud-Option (AVEVA Connect) läuft auf Azure EU-Region.
• AspenTech DMC3: Typischerweise als On-Premises-System betrieben; die Prozessmodelle laufen lokal auf Industrie-PC-Hardware im OT-Netz. Keine Cloud-Abhängigkeit im Standard-Deployment.
• ABB Genix: Globale Datenhaltung als Default — für Betriebe mit strikten Datensouveränitäts-Anforderungen muss On-Premises-Deployment vertraglich vereinbart werden. NIS-2 prüfen für KRITIS-relevante Chemiewerke.
• Siemens Insights Hub: EU-Hosting standardmäßig (AWS/Azure EU-Regionen), ISO 27001-zertifiziert. Für höchste Anforderungen: Private-Cloud-Option verfügbar.
• Azure ML + Python: Frankfurt-Region (eu-central-1) für vollständige EU-Datenhaltung wählbar. Kein AVV notwendig für reine Maschinendaten — empfohlen, sobald Mitarbeiter-Schichtdaten oder Kundendaten in die Analyse einfließen.

Praktische Empfehlung: Lasse vor dem Produktiveinsatz explizit klären, welche Datenkategorien in welches System fließen, wer Lesezugriff auf Modellparameter hat (die de facto Prozessrezepturen kodieren) und ob der Anbieter vertragliche Einschränkungen akzeptiert, nach denen er keine Rückschlüsse auf Prozess-Know-how ziehen oder weitergeben darf.

Was es kostet — realistisch gerechnet

Einmalige Projektkosten

Die Kosten variieren stark je nach vorhandener Infrastruktur. Hier die zwei realistischen Szenarien:

Szenario A: Historian bereits vorhanden (AVEVA PI System oder vergleichbar), Batch-Analyse-Ansatz

• Sensoraudit und Datenbereinigung: 15.000–40.000 € (extern oder intern)
• Modellentwicklung und Validierung: 30.000–80.000 € (Ingenieursdienstleistung)
• Gesamtprojektkosten: 45.000–120.000 €
• Laufende Kosten: 5.000–20.000 €/Jahr Plattform und Wartung

Szenario B: Closed-Loop-Optimierung mit AspenTech DMC3 von Null

• Historian-Infrastruktur (falls nicht vorhanden): 80.000–200.000 €
• DMC3-Implementierung inkl. Step-Tests und Modellentwicklung: 150.000–400.000 €
• Jahreslizenzen DMC3: 30.000–120.000 €/Jahr
• Gesamterstinvestition: 260.000–720.000 € im ersten Jahr

Wie du den ROI tatsächlich misst

Kein Schätzen, kein theoretisches Kalkül. Die einzig saubere Methode: Definiere vor Projektstart einen Kontrollzeitraum (6–12 Monate), in dem du die Baseline-Ausbeute sorgfältig misst — bereinigt um Rohstoffchargen-Effekte. Nach Go-Live misst du dieselbe Kennzahl unter denselben Bedingungen. Der Unterschied ist dein ROI — sofern keine anderen Maßnahmen gleichzeitig eingeführt wurden.

Konservatives Beispiel: 5.000 t/Jahr Produktion, Rohstoffwert 80 €/kg, aktuelle Ausbeute 85 %, Investition 150.000 €.

• 1 % Ausbeutesteigerung = 50 t mehr Produkt/Jahr × 80 €/kg = 4.000.000 € Rohstoffwert-Einsparung
• Selbst bei nur 0,5 % Steigerung: 2.000.000 €/Jahr
• Amortisation der Investition: unter 2 Monate

Das ist kein Hochglanz-Szenario: Das sind Zahlen aus einem mittleren Spezialchemie-Betrieb, wie er sich in Deutschland dutzendfach findet. Der wirtschaftliche Hebel ist real — weshalb die Technologie trotz hoher Einstiegskosten in der Prozesschemie seit 30 Jahren Standard ist.

Drei typische Einstiegsfehler

1. Mit Modellentwicklung starten, bevor der Datensatz validiert ist.
Der häufigste Fehler, auch bei erfahrenen Teams. Das Modell wird auf historischen Daten trainiert, sieht gut aus im Backtest, versagt im Live-Betrieb — weil die Trainingsdaten 15 % unerkannte Sensor-Drift-Perioden enthielten, die als Optimierungsparameter kodiert wurden. Das Modell hat eine Artefakt-Korrelation gelernt, keine echte Kausalität. Die Lösung: Sensoraudit und Datensatz-Validierung sind Phase 1, nicht Phase 3.

2. Das Modell wird deployed und dann nicht mehr überwacht.
Das ist der gefährlichste Fehler, weil er still passiert. Ein ML-Modell, das im Closed-Loop ohne Monitoring betrieben wird, optimiert irgendwann auf falscher Grundlage — wenn der Katalysator eine neue Charge hat, wenn ein Sensor langsam driftet, wenn der Betriebsbereich außerhalb der Trainings-Range erweitert wird. Das Modell gibt weiterhin Empfehlungen mit voller statistischer Zuversicht, aber sie werden schlechter. Ohne wöchentliches Monitoring der Modell-Performance gegenüber der aktuellen Ausbeute fällt das erst nach Monaten auf.

Definiere vor Go-Live: Wer ist verantwortlich für das Modell-Monitoring? Mit welchem KPI (Ausbeute-Abweichung vs. Baseline) wird der Verfall erkannt? Was löst ein Retraining aus — automatisch oder manuell? Diese Antworten müssen vor dem ersten Closed-Loop-Tag existieren, nicht danach.

3. Operatoren werden nicht einbezogen, bevor das System empfiehlt.
Schichtführer, die mit einem neuen System konfrontiert werden, das ihnen sagt, wie sie ihren Reaktor zu fahren haben, werden skeptisch sein — insbesondere, wenn das System gelegentlich Empfehlungen gibt, die dem erfahrenen Urteil widersprechen. Dieser Widerstand ist nicht irrational; er ist gesunder Pragmatismus.

Lösung: Der Advisory-Mode ist nicht nur eine technische Sicherheitsstufe, er ist ein Change-Management-Instrument. Lass erfahrene Schichtführer in der Advisory-Phase aktiv teilnehmen — sie sollen Empfehlungen beurteilen, Feedback geben und selbst Fälle benennen, bei denen das System Recht oder Unrecht hat. Das Modell lernt dabei nicht direkt, aber das Team baut Vertrauen auf, das bei der Umstellung auf Closed-Loop-Betrieb den Unterschied macht.

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

Die Technik ist das Einfachere. Das Schwierigere ist die Frage, wer das System im Betrieb verantwortet — und was passiert, wenn es Empfehlungen gibt, denen niemand traut.

Das “Wer hat Recht?”-Problem. In der ersten Betriebsphase werden Schichtführer auf Situationen stoßen, in denen das System eine Parameterkonstellation empfiehlt, die ihrer Erfahrung widerspricht. Manchmal hat das System Recht. Manchmal hat der Schichtführer Recht, weil er etwas weiß, das im Modell nicht kodiert ist — die Farbe der aktuellen Rohstoffcharge, ein leises Klappern im Rührergetriebe. Der Umgang mit diesen Konflikten muss explizit geregelt sein: Wer entscheidet? Wer dokumentiert Abweichungen, damit das Modell verbessert werden kann?

Was konkret hilft:

• Advisory-Mode für mindestens 8 Wochen, bevor Closed-Loop-Betrieb beginnt — auch wenn das System technisch bereit ist
• Strukturierte Review-Meetings alle zwei Wochen: Was hat das System empfohlen, was wurde umgesetzt, was war das Ergebnis?
• Einen internen “Modell-Owner” benennen — nicht die IT, nicht der Anlagenlieferant, sondern jemand aus dem Prozess-Engineering, der bei Abweichungen bewertet, ob Retraining oder manuelle Korrektur angebracht ist
• Klare Kommunikation nach oben: Die ersten Monate zeigen möglicherweise keine Ausbeuteverbesserung — weil das Modell noch im Learning-Modus ist und die Operatoren noch kalibrieren. Das ist normal und muss als solches kommuniziert werden, bevor die Ungeduld das Projekt gefährdet

Was nicht passiert: Das System schreibt keine Batch-Protokolle um, ersetzt keine Laboranalytik und gibt keine Garantien auf Produktqualität. Es ist ein Optimierungswerkzeug, kein Qualitätssicherungssystem. Wer das System auch für Compliance-relevante Dokumentation einsetzen will, braucht eine gesonderte Validierung — und steht dann in der Nähe eines GxP-regulierten Systems.

Realistischer Zeitplan mit Risikohinweisen

Kritische Voraussetzung für Closed-Loop-Betrieb: Bei Änderungen an der Prozesssteuerung, die in den Closed-Loop-Betrieb übergehen, ist ein HAZOP-Review (Hazard and Operability Study) empfehlenswert — je nach Anlage und Produktkategorie auch regulatorisch vorgeschrieben. Plane diesen Schritt frühzeitig; er kann 4–8 Wochen zusätzlich kosten.

Häufige Einwände — und was dahintersteckt

“Unsere Operatoren kennen den Reaktor seit 20 Jahren besser als jedes Modell.”
Das stimmt für viele Situationen — insbesondere für ungewöhnliche Betriebszustände, bei denen Erfahrung und Intuition entscheidend sind. Das Modell kennt genau einen Aspekt besser: alle 800 historischen Batches gleichzeitig und deren statistische Korrelationen. Kein Mensch kann 800 Batches im Kopf halten und die optimale Parameterkonzentration der Top-100 davon in Echtzeit ableiten. Das Modell und der erfahrene Operator ergänzen sich — das eine ersetzt das andere nicht.

“Die Datenqualität ist bei uns nicht gut genug für ML.”
Das ist in den meisten Fällen ein Argument für einen Sensoraudit, nicht für den Verzicht auf ML. Schlechte Datenqualität ist die häufigste Ausgangslage, nicht die Ausnahme. Ein sorgfältiger Audit klärt, welche Sensoren zuverlässig sind und auf welchen das Modell trainiert werden kann. Meistens genügen 60–70 % der verfügbaren Sensoren für ein valides Modell — der Rest darf fehlen oder unsicher sein.

“Das kostet 200.000 €, und wir sind ein mittelständisches Unternehmen.”
Für einen Betrieb mit 500 t/Jahr Produktion und 80 €/kg Rohstoffwert entsprechen 200.000 € Investitionskosten dem Wert von 0,5 % Ausbeuteverlust über 6 Monate. Wenn das Modell 1 % bringt, amortisiert es sich in einem Jahr. Die Frage ist nicht “Können wir uns das leisten?” sondern “Können wir es uns leisten, den Yield Gap offen zu lassen?” Die ehrliche Antwort hängt vom Produktionsvolumen und Rohstoffwert ab — ein 100-Tonnen-Betrieb sollte tatsächlich mit einfacheren Methoden beginnen.

“Was wenn der Closed-Loop falsch steuert und wir einen Reaktorunfall bekommen?”
Das ist ein berechtigtes Sicherheitsanliegen, das ernsthaft behandelt werden muss, nicht wegdiskutiert. Deswegen gibt es den Advisory-Mode als Pflichtstufe, den HAZOP-Review vor Closed-Loop-Freigabe und die Definition von Hardware-Interlock-Grenzen, die das ML-System niemals überschreiten kann — unabhängig von der Modell-Empfehlung. Das Sicherheitsinstrumentierungssystem (SIS) bleibt immer übergeordnet. Ein ML-Optimierungssystem agiert innerhalb der definierten Safe Operating Limits, nie jenseits davon.

Woran du merkst, dass das zu dir passt

• Du produzierst mehr als 500 Jahrestonnen eines Hauptprodukts, bei dem Rohstoffpreise und Ausbeute direkt gekoppelt sind
• Dein Historian enthält mindestens 18 Monate saubere Batch-Daten für das Zielprodukt — oder du betreibst einen kontinuierlichen Prozess mit 6+ Monaten valider Aufzeichnung
• Die Batch-zu-Batch-Ausbeute schwankt um mehr als 2 % unter nominell gleichen Bedingungen, ohne dass die Ursache klar benennbar ist
• Du oder dein Team verbringen regelmäßige Zeit damit, gute und schlechte Batches manuell zu vergleichen — mit dem Gefühl, die Antwort müsste “irgendwo in den Daten” stecken
• Du hast OT-/IT-Kapazität intern oder kannst einen Systemintegrator mit Prozesschemie-Erfahrung einbinden (kein reines Software-Projekt)

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

1. Unter 200 t/Jahr Produktionsvolumen für das Zielprodukt. Selbst bei Spezialchemikalien mit hohem Rohstoffwert ist der absolute Wert einer 2-%-Ausbeutesteigerung bei kleinem Volumen oft zu gering, um einen 6-monatigen ML-Implementierungsaufwand zu rechtfertigen. Hier sind manuelle Batch-Reviews mit SPC-Methoden (Statistical Process Control) der bessere erste Schritt.

2. Kein valider Historian mit mindestens 50 vollständigen Batches je Produktklasse. Ohne ausreichende Trainingsdaten lernt das Modell Rauschen statt Muster — und gibt mit der Zuversicht eines Modells Empfehlungen, die faktisch zufällig sind. Wer den Historian erst aufbauen muss, sollte damit beginnen und mindestens 12 Monate saubere Daten sammeln, bevor ML sinnvoll ist.

3. Bekannte, aber ungeklärte Sensorfehler im System. Wenn ihr wisst, dass zwei der wichtigsten Temperatursensoren “manchmal komische Werte zeigen” und das seit Jahren toleriert wird, ist kein ML-Projekt das Richtige — sondern ein Wartungsprojekt. Ein Modell, das auf korrumpierten Daten trainiert wird, ist gefährlicher als kein Modell.

Das kannst du heute noch tun

Starte mit einer einfachen Ausbeute-Analyse — ohne ML, ohne große Infrastruktur. Das Ziel ist, zu prüfen, ob das Optimierungspotenzial überhaupt im Daten-Bereich liegt oder in ungeklärten Prozess-Faktoren.

Exportiere die letzten 50–100 Batch-Protokolle aus eurem Historian oder dem Produktionsleitsystem. Du brauchst mindestens: Ausbeute (gemessen), Zulauftemperatur in der ersten halben Stunde, Rührerdrehzahl, Reaktionszeit bis Temperatur-Maximum, Enddruck. Lade diese Tabelle in Claude oder ChatGPT und stelle die Frage aus dem Prompt-Template unten.

Das dauert 30–60 Minuten. Was du danach weißt: Ob es in euren Daten statistisch trennbare “gute” und “schlechte” Parameterkonstellationen gibt — das ist die Vorbedingung für alles Weitere.

Quellen & Methodik

• APC-Ausbeute- und Energieeinsparungsdaten: LeKa Control, „Economic Value of Advanced Process Control (APC)” (2020), basierend auf über 500 dokumentierten APC-Projekten in der Prozessindustrie. Kennzahlen: 2 % Ausbeutesteigerung, 2–4 % Kapazitätssteigerung, 2–10 % Energieeinsparung, bis zu 50 % Reduktion der Produktqualitätsvarianz. URL: lekacontrol.com/2020/01/13/economic-value-of-advanced-process-control-apc/

• AspenTech-Fallstudie europäische Raffinerie: AspenTech Case Study, „Major European Refinery Uses Process Simulation Technology to Improve Energy Efficiency and Yields”. Ergebnis: 10 MW Energieeinsparung, nahezu $12 Mio./Jahr aus verbesserter Ausbeute. URL: aspentech.com/en/resources/case-studies (Zugriff Mai 2026, Volltext 403 bei direktem Abruf — Fallstudie im AspenTech-Kundenbereich).

• Imubit Batch-Reaktor Analyse: Imubit, „AI for Batch Chemical Reactor Yield and Consistency” (2024). Belegt: „mid-single-digit improvements in yield, cycle time, and energy use” für Batch-Prozesse. URL: imubit.com/article/ai-chemical-reactor/

• BASF KI-Reaktor: Chemie Technik, „BASF setzt auf Innovation und Digitalisierung” (2025), basierend auf BASF Research Press Briefing 2025. Erwähnt 20-fach schnellere Versuchszyklen durch KI-gestützten Laborreaktor. URL: chemietechnik.de/markt/basf-investiert-in-ki-und-chemische-erzaufbereitung

• Sensor-Korruption als Failure Mode: „Data-Driven Process Monitoring and Fault Diagnosis: A Comprehensive Survey”, MDPI Processes 2024. Belegt systematische Sensordrift (Coking, Kalibrierungsverlust) als primärer Failure Mode für datengetriebene Prozessoptimierung. URL: mdpi.com/2227-9717/12/2/251

• ML-Lifecycle-Herausforderungen in der Chemie: Gärtler et al., „The Machine Learning Life Cycle in Chemical Operations — Status and Open Challenges”, Chemie Ingenieur Technik, 2021. DOI: 10.1002/cite.202100134 (Volltext hinter Paywall; Titel und Abstract öffentlich zugänglich).

• AVEVA PI System Preisangaben: Erfahrungswerte aus öffentlichen Industrieberichten und verified-Einträgen in der ki-syndikat.de Tool-Datenbank (Stand Mai 2026).

• AspenTech DMC3 Implementierungskosten: Erfahrungswerte aus Industrieprojekten und AspenTech-Partnerdokumentation. Angaben ohne Gewähr; aktuelle Angebote via AspenTech-Vertrieb einholen.

Du willst wissen, ob die Sensordaten in eurer Anlage ausreichen und welcher Implementierungsweg für euer Produktionsvolumen sinnvoll ist? Das klären wir in einem kurzen Gespräch — ohne Vendor-Bias.