Umgebungsbedingungsabweichungs-Erkennung

Das echte Ausmaß des Problems

Wer in der Beschichtungs- oder Galvanikbranche arbeitet, kennt das Muster: Ausschuss kommt in Wellen, nicht einzeln. Wenn die Qualität kippt, sind es selten zehn Teile, es sind Hunderte, manchmal ein ganzer Produktionstag.

Das liegt an der Natur von Umgebungsparameter-Drift. Temperatur, relative Luftfeuchtigkeit, Badleitfähigkeit, pH-Wert oder Vorbehandlungsqualität driften nicht sprunghaft, sie gleiten. Über Stunden, manchmal über Tage. Dieser Gleitprozess ist mit konventionellem Schwellwert-Monitoring praktisch unsichtbar: Die Parameter befinden sich definitionsgemäß im erlaubten Bereich. Der Alarm schlägt nicht an. Trotzdem verändert sich die Beschichtungsqualität graduell, bis sie kippt.

Die Folgen sind nicht trivial. Was eine Ausschusswelle in der Lohnbeschichtung wirklich kostet, ist der Zweitdurchlauf, nicht der Auftragswert:

• Entlacken, erneute Vorbehandlung und Beschichtung: Material, Energie, Arbeitszeit und Anlagenzeit ein zweites Mal
• Ersatz für Kundenteile, die sich nicht entlacken lassen, soweit der Vertrag dich dafür haften lässt
• Transport und Handling, gegebenenfalls eine vertraglich vereinbarte Strafe für den Lieferverzug
• Reputationsschaden und Kundenbindungsverlust: schwer zu beziffern, aber real

Deinen Preis je Teil rechnest du nicht mit ein, den bekommst du einmal, ob du einmal oder zweimal beschichtest. Nur wenn die Anlage ausgelastet ist, kostet der Zweitdurchlauf zusätzlich den Deckungsbeitrag des Auftrags, der in dieser Zeit nicht laufen kann. Eine belastbare Branchenzahl, wie hoch Ausschussquoten in Lackier- und Galvanikbetrieben liegen und welcher Anteil auf schleichende Umgebungsveränderungen entfällt, haben wir nicht gefunden. Die Zahlen aus deinem Reklamations- und Nacharbeitsprotokoll sind die bessere Grundlage.

Die Forschung arbeitet an der Verknüpfung von Prozess- und Qualitätsdaten. Das Projekt “pAInt-Behaviour” (Helmut Fischer mit dem Fraunhofer IPA und weiteren Partnern, vom damaligen BMBF, heute BMFTR, mit knapp 1,3 Millionen Euro gefördert, Laufzeit bis Mai 2024) hatte zum Ziel, mit selbstlernenden Verhaltensmodellen aus Prozess-, Lack- und Umgebungsdaten 30 Prozent weniger Fehler und 10 Prozent weniger Lackverbrauch zu erreichen. Das sind Projektziele, keine gemessenen Ergebnisse.

Das ist die gute Nachricht: Die Daten, die für diese Früherkennung gebraucht werden, sind in den meisten Betrieben längst vorhanden. Sie werden nur nicht genutzt.

Mit vs. ohne KI, ein ehrlicher Vergleich

Richtung, keine Messwerte: Eine Studie, wie viel Ausschuss eine Driftüberwachung in Lackier- oder Galvanikbetrieben verhindert, haben wir nicht gefunden. Wie viel Reaktionszeit bleibt, hängt von Alarmeinstellung, Schichtbetrieb und Geschwindigkeit der Drift ab.

Das entscheidende Wort in der zweiten Zeile ist “Parameterkorrektur”. Das System muss nicht wissen, warum die Hallenfeuchtigkeit steigt, es muss früh genug warnen, damit der Anlagenfahrer handeln kann. Das ist fundamental anders als klassische Ursachenanalyse nach dem Ausschuss. Verhindern tut den Ausschuss aber erst die Gegenmaßnahme: Entfeuchtung hochfahren, Teile vor dem Beschichten temperieren, im Zweifel die Linie anhalten. Das kostet Zeit und Geld, und bei einem Fehlalarm kostet es dasselbe.

Einschätzung auf einen Blick

Zeitersparnis, niedrig (2/5) Dieses System spart keine tägliche Arbeitszeit. Es läuft im Hintergrund, analysiert kontinuierlich, und meldet sich nur, wenn es etwas Relevantes erkennt. Wer tägliche Produktivitätsgewinne sucht, schaut sich besser andere Anwendungsfälle an. Der Wert liegt in verhinderten Katastrophenereignissen, das ist ein anderer Effekt-Typ als Zeitersparnis.

Kosteneinsparung, mittel (3/5) Ein verhindertes Ereignis spart die Kosten des Zweitdurchlaufs, bei Tobias rund 14.000 Euro. Das System selbst verhindert aber nichts: Es muss die Drift rechtzeitig melden, jemand muss reagieren, und die Gegenmaßnahme muss wirken. Jede Gegenmaßnahme kostet, auch bei Fehlalarmen. In Betrieben mit mehreren Driftereignissen im Jahr kann das die Einrichtung schnell tragen, bei einem Ereignis im Jahr, das dann womöglich nicht rechtzeitig erkannt wird, eher nicht. Die Rechnung dazu steht weiter unten.

Schnelle Umsetzung, mittel (3/5) Der größte Zeitvorteil: Viele Betriebe loggen schon. Wer bereits eine SPS, ein Betriebsdatenerfassungssystem oder Compliance-Logging hat, spart die Sensor-Infrastrukturphase. Bis zur ersten ML-Baseline vergehen einige Wochen Lernphase. Realistisch bis zum Pilotbetrieb: 9–12 Wochen. Kein Sprint, kein Marathonprojekt.

ROI-Sicherheit, mittel (3/5) Das ROI-Szenario ist überzeugend, aber probabilistisch: Es hängt davon ab, wie oft Driftereignisse tatsächlich auftreten. In einem gut kontrollierten Betrieb mit stabilen Lieferanten und wenig Saisonschwankungen kann es Monate gehen, ohne dass das System anschlägt. Der ROI ist dann real, aber schwerer messbar. In Betrieben mit volatilerem Klima, häufigen Badwechseln oder wechselnden Materialchargen ist der ROI klarer und schneller.

Skalierbarkeit, sehr hoch (5/5) Das ist die stärkste Achse dieses Anwendungsfalls. Eine ML-Architektur für eine Linie ist auf alle Linien, alle Hallen, alle Standorte übertragbar. Ganz umsonst ist die zusätzliche Linie nicht: Sie braucht ihre eigenen Sensoren, eine eigene Baseline und eine Abstimmung der Alarmschwellen. Trotzdem skaliert kein anderer Anwendungsfall in dieser Branche so flach.

Richtwerte, stark abhängig von vorhandener Sensorinfrastruktur, Häufigkeit von Driftereignissen und Produktionsvolumen.

Was das System konkret macht

Das technische Fundament ist Machine Learning auf Zeitreihendaten, konkret: Anomalie- und Trenderkennungsmodelle, die lernen, wie “normal” aussieht.

In der Einlernphase (einige Wochen; einen Saisonwechsel kennt das Modell erst, wenn es ihn gesehen hat, siehe Einstiegsfehler 3) beobachtet das Modell die Sensorwerte unter normalen Betriebsbedingungen. Es lernt dabei nicht nur Einzelwerte, sondern Muster: Wie verhält sich die Hallenfeuchtigkeit über einen typischen Montag? Wie korreliert Badtemperatur mit Außentemperatur? Wie sieht ein normaler pH-Verlauf nach einem Badwechsel aus? Diese Baseline ist das Herzstück, alles Weitere ist Abweichungsrechnung davon.

Im laufenden Betrieb vergleicht das Modell den aktuellen Sensordatenstrom kontinuierlich mit dieser erlernten Baseline. Es erkennt:

• Absolute Drift: Ein Parameter bewegt sich langsam aus dem Normalbereich heraus, zu langsam für Schwellwert-Alarme
• Relative Drift: Zwei Parameter, die normalerweise korreliert sind, entkoppeln sich, ein Zeichen, dass etwas im Prozess gestört ist
• Musterwechsel: Das Tagesverhalten eines Sensors sieht plötzlich anders aus als gewohnt, auch wenn alle Einzelwerte im Limit sind

Das Ergebnis ist kein binärer Alarm (“gut/schlecht”), sondern ein Drift-Score: Ein kontinuierlicher Wert, der anzeigt, wie weit sich der aktuelle Zustand von der erlernten Normalität entfernt. Überschreitet dieser Score einen einstellbaren Grenzwert, geht eine Warnung raus, nicht weil ein Messparameter seinen Schwellwert verletzt hat, sondern weil der Gesamtzustand des Prozesses auffällig ist.

Der Unterschied zu Schwellwert-Monitoring, konkret

Ein Beispiel: Die Hallenfeuchtigkeit liegt bei 67 % relativer Feuchte. Der Alarmgrenzwert ist 75 %. Kein Alarm. Aber: Vor 72 Stunden lag sie bei 61 %, vorgestern bei 63 %, gestern bei 65 %. Das ist eine gleichmäßige Steigung von etwa 2 Prozentpunkten pro Tag. Das ML-Modell berechnet: Wenn sich dieser Trend fortsetzt, wird die kritische Zone in 4 Tagen erreicht. Es warnt jetzt, mit vier Tagen Reaktionszeit. Das Schwellwert-System warnt in vier Tagen, wenn es zu spät ist.

Für die Lackhaftung zählt dabei nicht die relative Feuchte allein, sondern der Abstand zwischen der Oberflächentemperatur der Teile und dem Taupunkt der Hallenluft. Wer Substrattemperatur und Hallenklima zusammen erfasst, kann diesen Abstand direkt überwachen, und das Modell bekommt ein physikalisch sinnvolles Signal statt zweier Einzelwerte.

Genau diese Frühzeitigkeit ist der Wert. Nicht das Erkennen des Fehlers. Die Chance, die Ausschusswelle zu verhindern, die dann aber jemand mit einer Gegenmaßnahme nutzen muss.

Welche Sensoren du wirklich brauchst, und welche du bereits hast

Das ist der Abschnitt, den generische IoT-Artikel konsequent überspringen. Und er ist der entscheidende.

Was die meisten Betriebe bereits aufzeichnen:

Fast jede moderne Lackieranlage und jeder Galvanikbetrieb loggt heute schon Prozessdaten, meist aus betrieblicher Gewohnheit und für die eigene Prozessführung. Umweltauflagen verlangen daneben eigene Aufzeichnungen, etwa die Lösemittelbilanz nach der 31. BImSchV oder die Überwachung des Abwassers; die Prozessdaten aus Bädern und Kabine gehören aber meist nicht dazu. Typisch vorhanden sind:

• Badtemperatur (in jedem geregelten Bad vorhanden)
• pH-Wert-Messung (bei Galvanik- und Vorbehandlungsbädern Standard in der Prozessführung)
• Leitfähigkeit der Bäder (Standard in modernen Anlagen)
• Zuluft- und Ablufttemperatur der Lackierkabine
• Druckluftqualität und -menge für Spritzaggregate

Was oft fehlt, aber günstig nachgerüstet werden kann:

• Relative Luftfeuchtigkeit in der Beschichtungszone: Industrielle Temperatur- und Feuchtesensoren gehören zu den günstigsten Nachrüstungen; autosen nennt für sein autarkes IoT-Sensorsystem minion einen Preis ab 264,59 Euro
• Substrattemperatur direkt am Teil: Berührungslose IR-Sensoren je Messpunkt; zusammen mit der Hallenfeuchte ergibt sie den Abstand zum Taupunkt
• Vorbehandlungsqualität als Messgröße: Hier ist Wasserbruchtest-Automatisierung selten, oft reicht aber die Abzählung indirekter Parameter (Badkonzentration, Spülwasserleitfähigkeit, Spülwassertemperatur)

Was ihr explizit nicht braucht:

Keine neuen Maschinen. Keine vollständige Digitalisierung der Produktion. Keine PLM- oder MES-Integration in Phase 1. Die ML-Schicht braucht nur einen Datenstrom, ob der aus einer modernen SPS, einem Datenlogger oder einem einfachen IoT-Gateway kommt, ist gleichgültig.

Die entscheidende Frage beim Start: “Wo werden unsere Parameter heute schon aufgezeichnet, und in welchem Format?” Die Antwort bestimmt den Integrationsaufwand. Wer bereits ein SPS-System mit OPC-UA-Schnittstelle hat, kann in wenigen Tagen Daten in eine Zeitreihendatenbank einleiten. Wer nur analoge Messfühler hat, braucht ein IoT-Gateway, Aufwand: 2–4 Wochen, Kosten: grob 1.000–4.000 Euro, hol dir ein Angebot.

Konkrete Werkzeuge, was wann passt

Das technische Stack für Umgebungsbedingungsüberwachung hat typischerweise drei Schichten: Datenspeicherung, Visualisierung/Alerting, ML-Modellierung.

Schicht 1, Zeitreihendatenbank: InfluxDB Der Open-Source-Standard für industrielle Sensordaten. Die Open-Source-Version InfluxDB 3 Core ist kostenfrei, kann on-premise betrieben werden, ohne dass Daten das Werk verlassen, und verarbeitet Millionen Messpunkte pro Sekunde. Einrichtungsaufwand: 1–3 Tage mit Entwicklerunterstützung. Wer lieber in die Cloud geht: InfluxDB Cloud Serverless gibt es auch in der Region Frankfurt. Wer OT-Daten gar nicht außer Haus geben will, hostet die Open-Source-Version selbst.

Schicht 2, Dashboarding und Alerting: Grafana Die meistgenutzte Open-Source-Visualisierungsplattform für Zeitreihendaten. Verbindet sich direkt mit InfluxDB . Dashboards zeigen Sensorverläufe, Trendlinien, gleitende Mittelwerte, und Alert-Regeln melden Abweichungen per E-Mail oder Teams-Nachricht. Kostenlos, selbst gehostet, keine Lizenzkosten. Erste einsatzfähige Dashboards entstehen in 1–2 Tagen. Wichtig: Grafana allein ist Schwellwert-Monitoring. Für echte Drift-Erkennung braucht es die ML-Schicht.

Schicht 3, ML-Modellierung: Azure Machine Learning Für Betriebe, die Azure-Infrastruktur nutzen oder sich in der Microsoft-Welt befinden. Azure Machine Learning bietet AutoML für Zeitreihen-Anomalieerkennung, ohne tiefe Data-Science-Kenntnisse ist eine erste Baseline in 2–4 Wochen trainierbar. EU-Rechenzentren verfügbar (Frankfurt, Amsterdam). Eine Grundgebühr gibt es nicht, bezahlt wird die Rechenleistung; was eine dauerhaft laufende Inferenz für deine Instanzgröße kostet, rechnet dir der Azure-Preisrechner aus, bevor du startest.

Für Siemens-geprägte Umgebungen: Siemens Industrial Edge Wer SIMATIC-SPSen betreibt, kann Industrial Edge als lokale Analyse-Schicht einsetzen, ohne Daten in eine externe Cloud zu leiten. Der AI Inference Server als App ermöglicht das Ausführen eigener Anomalie-Erkennungsmodelle direkt am Edge Device. Siemens veröffentlicht keine Listenpreise; die Kosten setzen sich aus Edge-Hardware, Management-Software und App-Lizenzen zusammen, oft kommt ein Systemintegrator dazu. Für Betriebe mit weniger als zehn Maschinen rechnet sich das selten, dafür bietet es maximale Datensouveränität.

Für historische Prozessdaten in Großbetrieben: AVEVA PI System Wenn bereits ein AVEVA PI System Historian vorhanden ist, ist die Datenbasis für ML-Modellierung schon vorhanden. PI speichert langjährige Zeitreihendaten mit hoher Granularität, ideales Trainingsmaterial für Drift-Erkennungsmodelle. Nur für Betriebe mit bestehender PI-Installation empfehlenswert; als Neueinführung zu komplex und teuer für diesen Use Case.

Zusammenfassung: Wann welcher Ansatz

• Kein Budget für Enterprise-Lösungen, bestehende Sensorinfrastruktur → InfluxDB + Grafana + Python/ Azure Machine Learning
• Siemens-Maschinenpark mit OT/IT-Team → Industrial Edge + eigenes ML-Modell
• Microsoft-365-Umgebung, kein Entwicklerteam intern → Azure Machine Learning mit AutoML-Funktionen
• AVEVA PI System vorhanden → PI als Datenquelle, ML-Schicht on-top

Datenschutz und Datenhaltung

Prozessparameterdaten aus Lackierlinien und Galvanikbädern sind keine personenbezogenen Daten im Sinne der DSGVO, sie beschreiben Maschinen und Bäder, nicht Personen. Das entlastet den Datenschutz erheblich.

Dennoch gibt es Punkte zu beachten:

Schichtdaten und Maschinendaten: Sobald Sensorprotokolle mit Schichtzuordnung oder namentlichen Aufzeichnungen verknüpft werden (wer hat welchen Parameter wann verändert?), entsteht Personenbezug. Das gilt insbesondere für Wartungsprotokolle und Einstellungsänderungen. Diese Daten unterliegen der DSGVO und brauchen einen Auftragsverarbeitungsvertrag (AVV), wenn sie in eine Cloud übermittelt werden. Gibt es einen Betriebsrat, ist eine solche Auswertung zudem nach § 87 Abs. 1 Nr. 6 BetrVG mitbestimmungspflichtig, weil sie Verhalten oder Leistung der Anlagenfahrer überwachen kann, unabhängig von der Betriebsgröße. Am einfachsten bleibt es, wenn das Modell nur Anlagendaten ohne Bedienerkennung bekommt.

Cloud vs. On-Premises: InfluxDB OSS und Grafana lassen sich vollständig on-premises betreiben, kein Datentransfer nach außen. Für Betriebe mit Betriebsgeheimnissen (Rezepturen, Badkompositionen, Prozessparameter als Know-how) empfiehlt sich das on-premises Deployment klar. Azure Machine Learning und AWS SageMaker bieten EU-Rechenzentren, aber die Daten verlassen das Firmengelände.

Vorhandene Aufzeichnungen doppelt nutzen: Viele Betriebe führen ohnehin Protokolle für Umweltauflagen und Qualitätsmanagement. Reine Anlagenwerte daraus kannst du ohne Datenschutzfrage als ML-Datenquelle nutzen. Stehen Namen oder Kürzel der Bediener darin, ist die Auswertung ein neuer Zweck, der eine eigene Prüfung nach Art. 6 Abs. 4 DSGVO braucht, und bei einem Betriebsrat die Mitbestimmung. Lass die Bedienerspalte im Export einfach weg.

Was es kostet, realistisch gerechnet

Einmalige Einrichtungskosten

Laufende Kosten (monatlich)

• Server für die selbst gehostete Datenbank und die Dashboards: eigener Rechner oder gemieteter Server, die Open-Source-Software selbst kostet nichts
• Azure Machine Learning , falls du in der Cloud rechnest: nach Compute-Verbrauch, vorab im Azure-Preisrechner kalkulieren
• Zeit einer benannten Person für Alarmprüfung, monatliche Modellbewertung und halbjährliches Nachtraining; wer das extern vergibt, zahlt den Dienstleister zusätzlich
• Die Gegenmaßnahmen selbst: jede Entfeuchtung, jedes Temperieren, jeder Linienstopp nach einem Alarm, auch nach einem Fehlalarm

Was du dagegenrechnen kannst

Gerechnet wird mit den Kosten des Zweitdurchlaufs, die du bei einem echten Ereignis vermeidest, bei Tobias rund 14.000 Euro. Der Jahresnutzen ist dann: Zahl der Driftereignisse im Jahr mal Anteil, den das System rechtzeitig meldet, mal Anteil, bei dem die Gegenmaßnahme wirkt, mal Kosten des Zweitdurchlaufs, abzüglich der Kosten aller Gegenmaßnahmen, auch der unnötigen. Wie hoch die beiden Anteile sind, weiß niemand vorab, auch wir nicht; das zeigt erst der Pilot.

Ein Rechenbeispiel mit Annahmen: Zwei Driftereignisse im Jahr, das System meldet eines davon rechtzeitig, die Gegenmaßnahme greift. Das sind 14.000 Euro gespart. Das deckt die bezifferbaren Posten von 2.500 bis 12.000 Euro im ersten Jahr, lässt aber je nach Umfang wenig Luft für Modellaufbau, Integration und die laufende Betreuung. Wird kein Ereignis rechtzeitig erkannt, bleibt nur die Infrastruktur. Bei vier bis sechs Ereignissen im Jahr und einer funktionierenden Reaktion sieht die Rechnung deutlich besser aus.

Bei null verhinderten Ereignissen war entweder die Baseline-Phase zu kurz, die Driftursachen liegen außerhalb des Sensorspektrums, oder der Betrieb hat schlicht sehr wenige Ausschussereignisse pro Jahr, was dann auch ein Zeichen für gute Prozessstabilität ist.

Drei typische Einstiegsfehler

1. Auf einen vollständig digitalen Betrieb warten. Viele Betriebe verschieben das Projekt, weil sie “erst noch die SPS erneuern” oder “warten, bis das neue MES läuft”. Das ist meistens ein Fehler. Ein ML-Modell braucht keine perfekte Infrastruktur, es braucht einen verlässlichen Datenstrom aus den vorhandenen Sensoren. Oft reicht ein Einplatinenrechner wie ein Raspberry Pi mit einem einfachen Logging-Script als Brücke zwischen alter SPS und moderner Datenbank. Den Schritt “alles modernisieren, dann KI” kann man machen, aber er ist nicht notwendig.

2. Zu viele Parameter auf einmal erfassen wollen. Der Reflex: alle 80 verfügbaren Messwerte in das Modell geben. Das klingt intuitiv richtig, mehr Daten, besseres Modell. In der Praxis führt es dazu, dass das Modell nichts Sinnvolles lernt, weil irrelevante Parameter das Signal übertönen, die Trainingsphase zu lang wird und Alarme schwer zu interpretieren sind. Einstieg: drei bis fünf Parameter, die in euren bisherigen Ausschussanalysen verdächtig waren, zum Beispiel Hallenfeuchtigkeit, Abstand zum Taupunkt, Badtemperatur, pH-Wert. Erst nach erfolgreicher Pilotphase erweitern.

3. Das Modell trainieren und vergessen. Das ist der gefährlichste Fehler, weil er still passiert und spät auffällt.

Wenn sich die Produktionsumgebung ändert, neuer Lieferant für Badchemie, neue Anlagenteile, Umbau der Absauganlage, saisonale Klimaverschiebungen, verändert sich auch, wie “normal” aussieht. Ein Modell, das auf Sommerdaten trainiert wurde, wird im Winter fälschlicherweise Alarm schlagen, weil niedrigere Luftfeuchtigkeit für es anomal ist. Das erzeugt Alert-Ermüdung: das Team lernt, Alarme zu ignorieren, weil sie zu oft falsch sind.

Lösung: Monatliche Modellbewertung (False-Positive-Rate kontrollieren), halbjährliches Nachtraining auf aktuellen Daten. Wer das nicht plant, hat nach 12 Monaten ein System, das niemand mehr ernst nimmt. Diese Prüfung muss eine namentlich benannte Person verantworten, nicht “die IT”.

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

Die Technologie ist der einfache Teil. Das Schwierige ist die Frage: Wer handelt, wenn das System warnt?

Ein Drift-Alert ist keine Fehlermeldung, er ist eine Hypothese. Das System sagt: “Die Parameter verhalten sich auffällig.” Es sagt nicht: “Stell die Feuchtigkeit auf 62 %.” Die Reaktion auf einen Alert erfordert Erfahrung, Kontext und die Bereitschaft, eine Produktionslinie eventuell kurz anzuhalten oder Parameter manuell zu korrigieren. Das ist Eingriff in den laufenden Betrieb, und das tun Anlagenfahrer nur, wenn sie dem System vertrauen.

Das Vertrauensproblem: In der Einführungsphase werden Alerts ankommen, die sich im Nachhinein als harmlos herausstellen. Das ist normal und unvermeidlich, kein Modell ist von Anfang an perfekt. Die Reaktion der Belegschaft darauf entscheidet über den Erfolg: Wer die ersten falsch-positiven Alarme als Systemversagen deutet, wird das System schnell ignorieren. Wer sie als Lernmaterial versteht, “was war an diesem Fall anders, sodass das Modell es fälschlicherweise als Anomalie erkannt hat?”, baut systematisch eine bessere Baseline auf.

Was konkret hilft:

• Vor dem Launch: schriftlich festlegen, was auf einen Alert hin passiert, wer entscheidet, wer informiert wird, welche Mindestmaßnahme (dokumentieren, Parameter prüfen, Chef informieren)
• Ersten Monat: alle Alerts gemeinsam im Team besprechen, auch die falschen, das schult das Verständnis für das Modell
• Eine “Systemverantwortliche Person” benennen, die Alert-Konfiguration verantwortet und Schwellwerte anpasst, wenn die False-Positive-Rate zu hoch wird
• Keine voreiligen Schlüsse: “Das System hat drei Mal falsch Alarm geschlagen” heißt nicht, dass es nicht funktioniert, es heißt, dass die Schwellwerte noch kalibriert werden müssen

Was ihr nicht erwarten solltet: Das System wird nicht alle Qualitätsprobleme vorhersagen. Manche Ausschussursachen liegen außerhalb des Sensorspektrums (Fehler im Rohmaterial, Bedienfehler, mechanische Defekte). Das System ist ein Werkzeug für Umgebungsdrift, kein allgemeines Qualitäts-Oracle.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

“Wir haben schon ein Klimamonitoring-System.” Dieser Einwand ist berechtigt, und genau das Missverständnis, das es aufzuklären gilt. Schwellwert-Alerting und Drift-Erkennung sind fundamental verschiedene Dinge.

Ein Klimamonitoring-System meldet, wenn die Hallenfeuchtigkeit über 75 % steigt. Das ist wichtig. Aber es meldet nicht, wenn die Hallenfeuchtigkeit in drei Wochen gleichmäßig von 61 % auf 74 % gestiegen ist, weil kein einziger Wert den Schwellwert verletzt hat. Die Drift war die ganze Zeit sichtbar. Nur nicht für einen Schwellwert-Alarm.

Stell dir vor, dein Auto hätte keinen Tachometer, sondern nur einen Alarm bei 200 km/h. Du könntest auf der Autobahn mit 185 km/h fahren, kein Alarm. Das System “funktioniert”, ist aber kein Geschwindigkeitsmesser.

Der ML-Ansatz liest den Tachometer, kontinuierlich, mit Trendberechnung.

“Wir hätten zu wenig Daten für ein ML-Modell.” Für einfache Anomalie- und Trenderkennungsmodelle auf Zeitreihendaten reichen einige typische Produktionswochen für eine erste Baseline. Du brauchst keine Millionen Datenpunkte, du brauchst einen konsistenten Datenstrom. Eine solche Baseline kennt aber nur die Jahreszeit, in der sie gelernt hat; beim ersten Saisonwechsel produziert sie Fehlalarme. Wer bereits ein Jahr Daten in seiner SPS oder seinem Historian hat, startet deshalb mit einem erheblichen Vorteil.

“Was, wenn das System einen Alarm schlägt und wir trotzdem produzieren?” Das ist keine Systemversagen-Situation, sondern eine Management-Entscheidung. Ein Drift-Alert ist kein Stopp-Signal, er ist eine Warnung. Die Entscheidung, wie darauf zu reagieren ist, liegt beim Anlagenfahrer und Schichtleiter. Gutes Alert-Design enthält daher immer: Schweregrad, betroffener Parameter, empfohlene Erstmaßnahme, Eskalationsweg. Niemand wird gezwungen, sofort abzuschalten.

Woran du merkst, dass das zu dir passt

• Du hattest in den letzten 12 Monaten mindestens eine Ausschusswelle, bei der die nachträgliche Ursachenanalyse auf schleichende Parameterveränderungen hingedeutet hat, auch wenn sich nichts endgültig beweisen ließ
• Deine Anlage zeichnet heute schon Daten auf: Badtemperatur, Klimaanlage, pH-Messung, Druckluft, irgendetwas läuft in einem Logbuch oder einer SPS mit
• Dein Betrieb produziert über 200 gleichartige Teile täglich auf der betroffenen Linie, darunter trifft eine Driftwelle meist zu wenige Teile, als dass der vermiedene Zweitdurchlauf Sensorik und Modellpflege tragen würde
• Du hast eine Person, die bereit und in der Lage ist, auf Alerts zu reagieren und das System zu betreuen, nicht zwingend IT, aber jemand mit Prozessverständnis

Wann es sich (noch) nicht lohnt, vier harte Ausschlusskriterien:

1. Batchfertigung unter 200 Teilen pro Tag. Das Modell lernt aus Sensordaten, nicht aus Teilezahlen, aber das Geld kommt aus den Teilen: Eine Driftwelle trifft dann wenige Teile, und der vermiedene Zweitdurchlauf ist zu klein, um Sensorik, Modellaufbau und Betreuung zu bezahlen. Ein Taupunkt-Alarm im vorhandenen Klimasystem ist hier die billigere Lösung.

2. Kein digitales Sensor-Logging vorhanden. Wer ausschließlich analoge Fühlertechnik mit manueller Ablesepflicht hat, muss erst digitalisieren. Das ist ein anderes Projekt, und ein sinnvoller erster Schritt, aber kein ML-Projekt.

3. Einproduktlinien mit täglich manuell verifizierten, stabilen Parametern. Wenn eure Anlagenfahrer jeden Morgen systematisch alle Parameter prüfen und manuell dokumentieren, ist die Drift-Erkennung weitgehend redundant. Das ML-System würde keinen Informationsvorsprung liefern.

4. Vollständig implementiertes statistisches Prozessregelwerk (SPC). Wer bereits echtes Statistical Process Control mit Control Charts, Cpk-Werten und automatischer Trend-Erkennung betreibt, hat das Problem bereits gelöst. ML-basierte Drift-Erkennung wäre marginal additiver Nutzen gegenüber gut kalibriertem SPC, der Aufwand lohnt sich erst bei konkreten SPC-Lücken.

Das kannst du heute noch tun

Die einfachste Möglichkeit zum Einstieg: Exportiere die letzten 30 Tage Badtemperatur- und Hallenfeuchtedaten aus eurem bestehenden System als CSV. Falls das nicht direkt geht, bitte die IT oder den Instandhaltungsleiter um den Export.

Hallenfeuchte und Badtemperatur verraten kaum Betriebsgeheimnisse. Badzusammensetzungen, Rezepturparameter und Bedienerkennungen lässt du trotzdem aus dem Export heraus, und in einem privaten Chat-Abo schaltest du die Nutzung deiner Eingaben zum Training ab. Dann lade die Datei in ein ChatGPT - oder Claude -Gespräch hoch und nutze folgenden Prompt:

Quellen & Methodik

• Helmut Fischer, Fraunhofer IPA und weitere Partner, Projekt “pAInt-Behaviour” (vom damaligen BMBF, heute BMFTR, mit knapp 1,3 Millionen Euro gefördert, Laufzeit bis 31.05.2024): selbstlernende Verhaltensmodelle aus Prozess- und Qualitätsdaten in Lackierprozessen. Projektziele: 30 % weniger Fehler, 10 % weniger Lackverbrauch, 10 % kürzere Anlaufzeit neuer Lacke, 20 % weniger Stillstand. Ziele, keine gemessenen Ergebnisse. Helmut Fischer Pressemitteilung

• Mehta, D. R., Omri, S., Zowalla, R., Neuhüttler, J. (2024): “A drift detection prototype for quality control in manufacturing”, Wirtschaftsinformatik 2024 (WI2024). Unüberwachte Drift-Erkennung für Bildverarbeitungsmodelle in der Qualitätskontrolle, getestet für Umgebungsveränderungen, Produktspezifikationswechsel und steigenden Ausschuss. Es geht um Verschiebungen in den Bilddaten eines Vision-Modells, nicht um Prozessparameter wie Hallenklima; das Prinzip, Drift ohne Labeldaten zu erkennen, ist übertragbar. Volltext: aisel.aisnet.org/wi2024/62

• Dürr, Advanced Analytics (DXQanalyze): Pressemitteilung vom 27. März 2020 zur KI-Anwendung in Lackierstraßen, Fehlerursachen, Wartungszeitpunkte, selbstlernende Algorithmen. Die Mitteilung nennt keine Prozentzahlen zur Wirkung. Dürr Advanced Analytics

• Lernphase: Eine belastbare Angabe, wie viele Tage eine Baseline für Lackier- oder Galvanikdaten braucht, haben wir nicht gefunden. Die Seite nennt deshalb einige Wochen für den Start und ein Jahr für Saisonwechsel.

• Sensor-Preis: autosen, autarkes IoT-Sensorsystem minion ab 264,59 EUR (abgerufen September 2026).

• Ausschusskosten: Eine belastbare Branchenzahl zu Kosten je Driftereignis in der Lohnbeschichtung haben wir nicht gefunden. Die Seite rechnet mit dem Beispiel aus der Einleitung und beschreibt, wie du deine eigenen Zahlen einsetzt.

• Recht: 31. BImSchV (Lösemittelbilanz), § 87 BetrVG (Mitbestimmung bei technischen Überwachungseinrichtungen), Art. 6 Abs. 4 DSGVO (Zweckänderung).

Du willst wissen, ob eure vorhandene Sensorinfrastruktur für ein ML-Monitoring ausreicht, und was der erste Schritt wäre? Meld dich, wir klären das gemeinsam in einem kurzen Gespräch.