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:

Direkte Kosten einer typischen Ausschusswelle in der Lohnbeschichtung:

• Materialwert der nachzuproduzierenden Teile: 5.000–20.000 Euro
• Nachbearbeitungsaufwand (Strippen, nochmals vorbehandeln, nochmals beschichten): 2.000–8.000 Euro
• Lieferverzug-Konventionalstrafen (bei Automobilzulieferern oft vertraglich fixiert): 1.000–5.000 Euro
• Reputationsschaden und Kundenbindungsverlust: schwer zu beziffern, aber real

In der Praxis berichten Lackierbetriebe und Galvanikbetriebe von Ausschussraten zwischen 2 und 8 Prozent des Produktionsvolumens — mit starker Häufung um schleichende Umgebungsveränderungen. Das Fraunhofer IPA arbeitet mit Lackierereien und Beschichtungsunternehmen daran, durch Kombination von Prozessdaten und ML-Modellen diese sogenannten “Silent Drifts” frühzeitig zu identifizieren. Das Forschungsprojekt “pAInt-Behaviour” (Helmut Fischer + Fraunhofer IPA, gefördert vom BMBF mit knapp 1,3 Millionen Euro) zielt auf 30 Prozent weniger Fehler, 10 Prozent weniger Lackverbrauch durch frühzeitige Parameterkorrektur.

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

Erfahrungswerte aus Lackier- und Galvanikbetrieben mit bis zu 400 Mitarbeitenden. ¹ Reaktionszeit hängt ab von Alert-Einstellung und Schichtbetrieb.

Das entscheidende Wort in der mittleren 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.

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 — hoch (4/5) Ein einziges verhindetes Ausschussereignis mit 500 Teilen zu 20 Euro/Teil — also 10.000 Euro Direktschaden — übersteigt typische Jahreskosten für Sensorik und Software. In Betrieben mit zwei bis vier Ausschussereignissen pro Jahr rechnet sich das System ab dem ersten verhindeten Fall. Nicht der stärkste Kosteneinspar-Hebel im Bereich (dafür müsste der Ausschuss systematisch sein), aber deutlich spürbarer als im Vergleichsfall.

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 7–30 Tage Lernphase. Realistisch bis zum Pilotbetrieb: 6–10 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 ohne nennenswerten Mehraufwand auf alle Linien, alle Hallen, alle Standorte übertragbar. Der Grenzaufwand für eine zusätzliche Linie ist fast null: Sensordaten einspeisen, Modell anlernen, Alert-Konfiguration duplizieren. Kein anderer Anwendungsfall in dieser Branche skaliert 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 (typisch 7–30 Tage) 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 % 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.

Genau diese Frühzeitigkeit ist der Wert. Nicht das Erkennen des Fehlers. Das Verhindern der Ausschusswelle.

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 Daten — teils aus Compliance-Gründen (AwSV Anlagenverordnung zum Schutz vor Gewässern, BImSchV-Vorgaben für Emissionen, Abwasser-Eigenüberwachungspflichten), teils aus betrieblicher Gewohnheit:

• Badtemperatur (in jedem geregelten Bad vorhanden)
• pH-Wert-Messung (bei Galvanik- und Vorbehandlungsbädern meist regulatorisch gefordert)
• 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: Ein industrieller Temperatur-/Feuchtesensor (z.B. autosen MH001) kostet ab 80–150 Euro, ein komplettes drahtloses IIoT-Starterset mit Cloud-Dashboard ab ca. 265 Euro
• Substrattemperatur direkt am Teil: Berührungslose IR-Sensoren, 200–400 Euro pro Messpunkt
• 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: 1.000–5.000 Euro.

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 Community Edition ist kostenfrei, kann on-premise betrieben werden (DSGVO-konform ohne Cloud-Exposure) und verarbeitet Millionen Messpunkte pro Sekunde. Wer OT-Daten nicht in eine US-Cloud geben will, ist hier richtig. Einrichtungsaufwand: 1–3 Tage mit Entwicklerunterstützung. Achtung: Für den Cloud-Betrieb gilt US-Hosting — wer das vermeiden will, hostet die OSS-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), Kosten abhängig von Compute-Zeit: typisch 100–400 Euro/Monat für kontinuierliche Inferenz bei KMU-Datenvolumen.

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. Hohe Einstiegshürde (ab 10.000–50.000 Euro Pilotprojekt), aber 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.

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.

Compliance-Daten doppelt nutzen: Viele Galvanik- und Lackierbetriebe sind ohnehin zur digitalen Aufzeichnung verpflichtet (AwSV-Eigenüberwachung, Abwasser-Parameterprotokolle). Diese Compliance-Daten können gleichzeitig als ML-Datenquelle genutzt werden — ohne zusätzliche Datenschutzprüfung, da sie bereits rechtlich abgesichert erfasst werden. Das ist ein unterschätzter Effizienzgewinn.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

Laufende Kosten (monatlich)

• Hosting InfluxDB + Grafana (on-prem oder VPS): 50–200 Euro/Monat
• Azure Machine Learning Inferenz (cloud-basiert): 100–400 Euro/Monat
• Wartung und Modellpflege (intern oder externer Dienstleister): 200–500 Euro/Monat
• Gesamt laufend: ca. 350–1.100 Euro/Monat

Was du dagegenrechnen kannst

Ein verhindetes Ausschussereignis mit 400 Teilen bei 20 Euro Wertschöpfung pro Teil: 8.000 Euro Direktschaden. Hinzu kommen Nachbearbeitungskosten (2.000–5.000 Euro) und mögliche Konventionalstrafen. Ein einziges verhindetes Ereignis pro Quartal ergibt ein Einsparpotenzial von 10.000–15.000 Euro — gegen Jahreskosten von 4.200–13.200 Euro.

Die konservative Kalkulation: Wenn das System im ersten Jahr zwei Ausschussereignisse verhindert (und das Frühwarnsystem gibt vier Tage Reaktionszeit, was in der Praxis für eine Parameterkorrektur ausreicht), amortisiert sich der Pilot. Wenn es eines verhindert, liegt man ungefähr kostendeckend. 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 50-Euro-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 erfahrungsgemäß mit Qualitätsproblemen korrelieren — Hallenfeuchtigkeit, 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. Diesen Review 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 sind 7–30 Tage historische Daten ausreichend für eine erste Baseline. Du brauchst keine Millionen Datenpunkte — du brauchst einen konsistenten Datenstrom über mehrere typische Produktionswochen. Wer bereits ein Jahr Daten in seiner SPS oder seinem Historian hat, startet 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 fehlt schlicht die statistische Masse für sinnvolle Baseline-Modelle
• 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. Zu wenig statistische Datenmenge für stabile Baseline-Modelle. Die Varianz innerhalb weniger Teile ist zu groß, um schleichende Drift von normalem Produktionsrauschen zu trennen.

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.

Dann lade die Datei in ein ChatGPT- oder Claude-Gespräch hoch und nutze folgenden Prompt:

Quellen & Methodik

• Fraunhofer IPA + Helmut Fischer, Projekt “pAInt-Behaviour” (BMBF-gefördert, Laufzeit bis 05/2024): ML-Modelle für Qualitätsvorhersage in Lackierprozessen aus Prozessdaten. Zielgrößen: 30 % Fehlerreduktion, 10 % weniger Lackverbrauch. Quellen: Helmut Fischer Pressemitteilung, Fraunhofer IPA Beschichtungstechnologie

• Mehta, D. R., Omri, S., Zowalla, R., Neuhüttler, J. (2024): “A drift detection prototype for quality control in manufacturing”, Wirtschaftsinformatik 2024 (WI2024). Unsupervised Drift Detection ohne Labeldaten — experimentell bestätigt für Erkennung von Umgebungsveränderungen, Produktspezifikationswechseln und Ausschussraten-Anstieg. Volltext: aisel.aisnet.org/wi2024/62

• Dürr AG, DXQanalyze: Industriepraxis-Referenz für KI-basierte Qualitätsprädiktion in Lackierstraßen. Bis zu 16 % Stückkostenreduktion durch frühe Fehleridentifikation. Dürr Advanced Analytics

• Anomaly Detection Learning Phase: Einstiegszeitraum 7–30 Tage für industrielle Anomalie-Erkennungssysteme — Erfahrungswerte aus Implementierungen in der Kunststoffverarbeitung, bestätigt durch elunic AG Praxisberichte (2024).

• Sensor-Preisangaben: autosen.com (Stand April 2026). Minion IoT-Sensorsystem ab 264,59 EUR, io-key System ab 297,29 EUR. Eigene Erfahrungswerte für Gesamtpilot-Kalkulation.

• Ausschusskosten-Bandbreite: Eigene Erfahrungswerte aus Beratungsprojekten in der Lohnbeschichtung. Keine repräsentative Studie — Größenordnungen konsistent mit publizierten VDMA-Benchmarks für fertigungsnahe Qualitätskosten.

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.