Lackhaftung bei Zinkdruckguss: ML verhindert Farbabplatzungen an Metallspielzeug

Das echte Ausmaß des Problems

Zinkdruckguss ist das bevorzugte Verfahren für lackiertes und galvanisiertes Metallspielzeug: Miniaturfahrzeuge, Spielzeugpistolen, mechanische Spielsets. Zamak-Legierungen (Zink-Aluminium-Kupfer-Magnesium) lassen sich präzise gießen, sind leicht und nehmen Farbe gut an, vorausgesetzt, die Oberfläche ist sauber vorbereitet.

Das Problem steckt in der Kette der Vorbehandlungsschritte: Entfetten, Beizen (Aktivierung der Zinkoberfläche), Spülen, gegebenenfalls Konversionsbeschichtung, dann Lackierung. Jeder Schritt hat seine eigene Fehlertoleranz, und die Parameter interagieren. Wenn das Entfettungsbad zu alt ist, verbleiben Reste von Trennmitteln aus dem Druckgussprozess auf der Oberfläche. Wenn der pH-Wert im Beizstep zu hoch ist, wird die Zinkoberfläche unzureichend aktiviert. Wenn die Spülwassertemperatur zu niedrig ist, lösen sich Salzkristalle auf der Oberfläche.

Keiner dieser Fehler ist beim Lackieren sichtbar. Sichtbar werden sie erst beim Gitterschnitttest, nach dem Lackieren.

Was das in Zahlen bedeutet:

• Typische Nachlackierungskosten: 3–15 Euro pro Einheit, je nach Bauteilgröße und Prozessaufwand
• Bei einer mittleren Produktionslinie mit 50.000 Teilen/Monat und einer Ausschussrate von 2–4 % durch Lackhaftungsfehler: 3.000–30.000 Euro monatlicher Verlust
• Brancheninterne Schätzungen gehen davon aus, dass 30–60 % dieser Fehler auf schleichende Baddrift zurückzuführen sind, also auf Ereignisse, die mit Echtzeitmonitoring erkennbar wären
• Gießereien, die ML-basierte Qualitätsprädiktionssysteme eingeführt haben, berichten von Ausschussreduktionen zwischen 30 und 60 % (Tvarit GmbH, 2024, Industrieangaben, keine unabhängige Studie)

Das akademische Pendant: Forschende der Friedrich-Schiller-Universität Jena haben 2021 in der Fachzeitschrift Coatings (MDPI) gezeigt, dass Machine Learning-Modelle (Random Forest, Logistic Regression, SVM) Lackhaftungsversagen auf lasergereinigten Metalloberflächen mit einer Genauigkeit von 75 % vorhersagen, auf Basis von Nahinfrarot-Hyperspektraldaten, erhoben vor dem Lackierstart. Das Prinzip ist übertragbar: Messung der Oberflächenzustandsinformation vor dem Lackieren, Vorhersage des Haftungsergebnisses vor dem Schaden.

Zinkdruckguss und Lackhaftung: die Materialkunde

Wer dieses System implementieren will, muss verstehen, was die Sensoren eigentlich messen, und warum.

Zamak-Legierungen haben eine besondere Eigenschaft: Die Zinkoberfläche oxidiert sehr schnell an der Luft und bildet eine Zinkoxidschicht, die die Lackhaftung verhindert. Deshalb ist das Beizen (Ätzen) mit verdünnter Salzsäure oder Beizlösungen Pflicht, es entfernt die Oxidschicht und erzeugt eine mikrostrukturell reaktive Oberfläche. Dieser Zustand ist jedoch instabil: Zwischen Beizen und Lackieren tickt die Uhr. Schon nach wenigen Stunden hat sich eine neue Oxidschicht gebildet.

Trennmittel aus dem Druckgussprozess, meist silikonhaltige Emulsionen, sind die zweite Fehlerquelle. Sie haften in Mikroporen und Hinterschneidungen des Gussteils und sind durch normales Entfetten nicht vollständig entfernbar. Ein erschöpftes Entfettungsbad (erkennbar an steigender elektrischer Leitfähigkeit und sinkendem Emulgatorzusatz) lässt Silikonreste auf der Oberfläche zurück.

Was das für die Sensorik bedeutet:

Ein ML-Modell, das nur einen dieser Parameter überwacht, löst zu viele Fehlalarme. Die Stärke des Ansatzes liegt in der Korrelation: Das Bad kann einen leicht erhöhten pH haben und trotzdem gute Haftung liefern, solange die Temperatur stimmt und die Standzeit niedrig ist. Das Modell lernt diese Wechselwirkungen aus der Geschichte von Prozessparametern und Haftungsprüfergebnissen.

Mit vs. ohne KI, ein ehrlicher Vergleich

Die Zahlen für die Rubrik “Mit ML” sind Zielwerte aus vergleichbaren Industrie-Implementierungen, keine Garantiewerte. Tatsächlich hängt das Ergebnis stark von der Datenqualität der ersten 6 Monate ab.

Einschätzung auf einen Blick

Zeitersparnis, mittel (3/5)
Die größte Zeitersparnis entsteht nicht in der Produktion selbst, sondern in der Qualitätssicherung: weniger Nacharbeit, weniger Labortests, weniger Notfall-Badkorrekturen unter Zeitdruck. Das ist real, aber kein direkter Tagesgewinn an Maschinenkapazität, der einzige Weg zu echten Taktzeitgewinnen wäre, wenn das Monitoring auch Prozessoptimierungsempfehlungen liefert (das können spezialisierte Plattformen, ist aber ein zweiter Schritt). In der Spielwarenbranche liegt das in der mittleren Gruppe.

Kosteneinsparung, hoch (4/5)
Das ist der primäre Hebel. Direkte, berechenbare Kosten: Jede vermiedene Nachlackierung spart 3–15 Euro pro Einheit. Bei 50.000 Teilen/Monat und einer halbierbaren Ausschussquote sind das schnell 30.000–60.000 Euro Jahreseinsparung. Anders als beim KI im Kundenservice ist die Einsparung hier nicht indirekt, sie taucht direkt in der Kostenrechnung als “Ausschuss Lack” auf.

Schnelle Umsetzung, niedrig (2/5)
Das ist die ehrlichste Bewertung dieses Use Case. Sensorinstallation, OT-Anbindung, Datenerfassungsphase, Modelltraining auf genügend historischen Daten: realistisch 3–6 Monate bis zu einem verlässlichen Modell. Die Sensorik kostet Zeit und Geld. Niemand, der nächsten Monat Ergebnisse braucht, sollte hier einsteigen.

ROI-Sicherheit, hoch (4/5)
Das ist das Gegengewicht zur langen Anlaufzeit: Wenn das Modell läuft, ist der ROI direkt messbar. Ausschussquote vorher vs. nachher, Chemikalienverbrauch vorher vs. nachher, beide Größen sind in der Produktion ohnehin erfasst. Die Zielvariable (Lackhaftung im Gitterschnitttest) ist klar definiert und wird eh schon gemessen. Das macht die Bewertung eindeutig, sehr anders als bei Analytics-Projekten, bei denen der ROI immer irgendwie indirekt bleibt.

Skalierbarkeit, hoch (4/5)
Ein trainiertes Modell lässt sich mit überschaubarem Mehraufwand auf weitere Lackierlinien übertragen, die Sensor-Architektur ist identisch, die Domäne ist dieselbe. Nur die Kalibrierung muss neu erfolgen (jede Linie hat leicht andere Badchemie-Charakteristika). Unternehmen mit zwei oder drei Lackierlinien können den ROI multiplizieren ohne die Grundinvestition zu wiederholen.

Richtwerte, stark abhängig von Anlagenalter, vorhandener OT-Infrastruktur und Ausschussvolumen.

Die richtigen Sensoren: was gemessen werden muss

Das ist der Abschnitt, den Lieferantenbroschüren überspringen, weil er die eigentliche technische Arbeit enthält.

Eine typische Vorbehandlungslinie für Zinkdruckguss hat drei bis fünf Bäder. Jedes braucht eigene Sensorik:

Entfettungsbad (Bad 1)

• Elektrische Leitfähigkeit: zeigt Erschöpfung des Tensidanteils an. Schwellwert typisch bei 8–12 mS/cm, je nach Emulgatorsystem. Sensor: Inline-Konduktometer, wartungsarm, Drift-Check alle 2 Wochen empfohlen.
• Temperatur: Entfetter arbeiten in einem engen Temperaturfenster (50–70°C). Abweichungen von mehr als 3°C ändern die Entfettungseffizienz messbar.

Beizbad / Aktivierungsstufe (Bad 2)

• pH-Wert: der kritischste Einzelparameter. Typisches Arbeitsfenster: pH 1,8–2,4. Ein Anstieg über 2,6 bedeutet unzureichende Aktivierung. Sensor: eintauchbarer pH-Messer mit automatischer Temperaturkompensation (wichtig!). Empfohlenes Kalibrierintervall: wöchentlich.
• Freie Säure: optional, als Redundanz zum pH. Titrationssensor oder inline-Messung.

Spülstufen (Bad 3, 4)

• Leitfähigkeit: zeigt Verschleppung von Badchemikalien ins Spülwasser an. Schwellwert typisch unter 0,5 mS/cm.
• Trübung: zeigt den Partikelgehalt im Wasser an, relevant bei Ultrafiltrations-Kreislaufspülung.

Abtropfsektion / Übergabeband

• Zeit zwischen Beizen und Lackierstart: wird oft nur mit SCADA-Zeitstempeln erfasst, aber extrem wichtig. Ab 3–4 Stunden beginnt merkliche Reoxidation, ein Laufparameter, den das Modell unbedingt kennen muss.

Sampling-Rate: pH und Leitfähigkeit können problemlos alle 60 Sekunden gemessen werden, das ist mehr als genug. Schnellere Intervalle erhöhen nur das Datenvolumen, ohne Mehrwert. Temperatur alle 5 Minuten.

Daten-Aggregation: Die Rohmesswerte gehen in eine lokale Zeitreihendatenbank (z.B. InfluxDB, on-premise betrieben). Von dort speist Node-RED die Daten in die ML-Schicht. Das ist eine bewährte Open-Source-Kombination, die auch ohne Industrieplattform funktioniert.

Was das ML-System konkret macht

Das technische Prinzip ist eine Kombination aus Prozessmonitoring und Predictive Analytics:

Phase 1, Training (Monate 1–3): Sensordaten werden zusammen mit Gitterschnitttest-Ergebnissen gesammelt und korreliert. Das Modell lernt: “Wenn pH 2.2, Leitfähigkeit Entfetter 9 mS/cm, Temperatur 62°C und Standzeit 180 Minuten, dann Haftungsklasse 0–1.” Es lernt auch: “Wenn pH 2.7 und Leitfähigkeit Entfetter 14 mS/cm, dann Haftungsklasse 3–4 (Grenzfall).”

Phase 2, Einsatz (ab Monat 4): Das Modell läuft in Echtzeit. Es bekommt die aktuellen Parameterwerte gemeldet und gibt eine Prognose: “Aktuelle Badsituation ergibt 87 % Wahrscheinlichkeit für Haftungsklasse ≤ 1 (gut). Alarmschwelle bei 95 % für akzeptable Haftung, aktuell noch nicht überschritten, aber im Trend nach oben.” Der Bediener sieht das im Dashboard.

Phase 3, Alarm: Fällt die Wahrscheinlichkeit für gute Haftung unter einen konfigurierten Schwellwert (z.B. 85 %), löst das System einen Alarm aus, nicht: “Lackierlinie stoppen”, sondern: “Beizbad prüfen, Verbrauchswert X liegt an der Grenze, Badkorrektur empfohlen.” Bediener entscheidet. Das ist Predictive Analytics, nicht autonome Steuerung.

Phase 4, Feedback: Jedes neue Gitterschnitttest-Ergebnis fließt zurück ins Modell. Das ermöglicht kontinuierliche Verbesserung, und ist der Grund, warum das Modell nach 6 Monaten besser ist als nach 3 Monaten.

Technisch braucht das kein Deep Learning. Ein gut trainierter Random Forest oder eine Gradient-Boosting-Variante (XGBoost, LightGBM) reicht für diese Art von tabellarischen Prozessdaten vollständig aus. Aufwand: machbar mit einem Python-Entwickler und einer ML-Bibliothek wie scikit-learn, kein Doktorat in Data Science erforderlich.

Modell-Retraining: wann das ML-System neu lernen muss

Das ist der meist unterschätzte Teil des Projekts, und der, der in der Praxis am häufigsten scheitert.

Ein ML-Modell, das auf den Produktionsdaten von 2024 trainiert wurde, lernt die Zusammenhänge zwischen Badparametern und Haftungsqualität für genau diese Konfiguration: diese Badchemikalien, dieser Lieferant, diese Zamak-Legierung, diese Lacksystematik. Ändert sich eine dieser Größen, verliert das Modell seine Verlässlichkeit, oft ohne es anzuzeigen.

Auslöser für Retraining:

• Wechsel des Badchemikalien-Lieferanten (neues Tensidsystem hat andere Erschöpfungskurve)
• Wechsel der Zamak-Legierung oder des Legierungsanteils (ändert Aktivierungskinetik)
• Neues Trennmittel in der Druckgusslinie (anderer Rückstandscharakter auf der Oberfläche)
• Wartung oder Erneuerung eines Bades (Geometrie, Strömungsprofil ändert sich)
• Saisonale Verschiebung der Hallatemperatur (verändert Badtemperaturgleichgewicht)
• Lacksystemwechsel (Primer, Basislack, ändert die Haftungsanforderungen)

Praktische Regel: Nach jedem dieser Ereignisse ist mindestens eine 4-wöchige Datenerfassungsphase mit engmaschiger manueller Qualitätsprüfung nötig, bevor das neue Modell in produktiven Betrieb geht. In dieser Übergangsphase gelten die alten Alarmschwellen nicht, das ist zu kommunizieren.

Wer kümmert sich darum? Das ist die entscheidende organisatorische Frage. Ohne eine namentlich benannte Person, typischerweise die Qualitätsleiterin oder ein OT-affiner IT-Mitarbeiter, die diese Retraining-Ereignisse aktiv überwacht und auslöst, hat das System nach 18 Monaten still gedriftet und niemand hat es bemerkt.

Die Plattformen Tvarit Industrial AI und Azure Machine Learning haben beide Drift-Detection-Funktionen, die automatisch warnen, wenn eingehende Sensordaten statistisch von den Trainingsdaten abweichen. Das ist keine Lösung für das Retraining-Problem, aber ein wichtiger Frühwarnindikator.

Konkrete Werkzeuge, was wann passt

Die Werkzeugwahl hängt stark von zwei Faktoren ab: OT-Reife (gibt es schon eine Dateninfrastruktur am Shopfloor?) und Teamkompetenz (gibt es interne Entwickler oder IT-Mitarbeitende mit Python-Kenntnissen?).

Tvarit Industrial AI, wenn du keine Eigenlösung bauen willst
Das Frankfurter Unternehmen hat Erfahrung mit Gieß- und Metallverarbeitungsprozessen, EU-Hosting und deutschsprachigem Support. Die Plattform enthält Prescriptive Quality als Modul, das direkt auf diesen Use Case passt. Kosten: ca. 1.000–3.000 €/Monat Lizenz plus einmalige Sensor- und Implementierungskosten (mittlerer fünfstelliger Bereich für den Einstieg). Sinnvoll ab einem Ausschussvolumen, das diese Investition in unter zwei Jahren amortisiert.

Siemens Industrial Edge, wenn du schon Siemens-SPS an der Linie hast
Edge Devices erfassen Sensordaten lokal, Apps verarbeiten sie ohne Cloud-Zwang. Für Vorbehandlungslinien mit Siemens SIMATIC-Steuerungen der kürzeste Integrationspfad. Einstieg: 10.000–50.000 € Pilotinstallation je nach Anlagengröße. Erfordert OT/IT-Doppelkompetenz oder einen Siemens-Systemintegrator.

Azure Machine Learning, wenn ihr den Eigenbau bevorzugt und Azure-Infrastruktur habt
Python-Notebooks, AutoML, Modell-Einführung in der Region Germany West Central (DSGVO-konform). Geeignet für Teams, die ML-Kompetenz aufbauen wollen und Flexibilität über Out-of-the-Box bevorzugen. Compute-Kosten für Experimente: 100–500 €/Monat; produktive Endpunkte: 500–2.000 €/Monat.

Grafana, für das Monitoring-Dashboard (alle Ansätze)
Unabhängig davon, welche ML-Plattform du wählst: Grafana ist der De-facto-Standard für Echtzeit-Prozess-Dashboards. Open-Source-Kern, selbst hostbar, verbindet sich direkt mit InfluxDB. Kosten: null (OSS), wenn du es selbst hostest. Wichtig: Grafana visualisiert, trifft aber keine ML-Prognosen, das muss die darunterliegende ML-Schicht liefern.

InfluxDB, für die Zeitreihendatenbank (DIY-Weg)
Open-Source-Zeitreihendatenbank, speziell für hochfrequente Sensordaten. On-premise betrieben: keine Daten gehen in eine US-Cloud. Verbindet sich mit Node-RED für die Daten-Routing-Schicht.

Node-RED, für die OT-IT-Verbindung (DIY-Weg)
Visual Flow Programming für die Daten-Pipeline zwischen Sensoren und Zeitreihendatenbank. Unterstützt MQTT, OPC-UA, Modbus, die gängigen Protokolle an Industrielinien. Kostenlos, läuft auf einem Raspberry Pi oder kleinen Edge-Server.

Wann welcher Ansatz:

• Keine interne IT/OT-Kompetenz, hohes Ausschussvolumen → Tvarit
• Siemens-Maschinenpark vorhanden → Siemens Industrial Edge + Tvarit oder eigenes ML-Modell
• Python-kompetentes Team, Azure-Infrastruktur vorhanden → DIY mit Azure ML + Grafana + InfluxDB
• Evaluierung ohne Budget → erstmal Daten sammeln mit Node-RED + InfluxDB + Grafana, Modell-Schicht später

Datenschutz und Datenhaltung

Prozesssensordaten aus Lackierlinien enthalten in der Regel keine personenbezogenen Daten, pH-Wert, Leitfähigkeit und Temperatur sind rein technische Messgrößen. Die DSGVO ist hier nicht der primäre Compliance-Pfad.

Relevanter ist in vielen Betrieben die OT-Sicherheit: Produktionsdaten, Badparameter, Chargenzeiten, Qualitätskennzahlen, sind oft strategisch sensitiv (Rezepturen, Produktionskapazität, Qualitäts-KPIs). Sie sollten nicht unverschlüsselt über das Internet fließen.

Für die Tool-Wahl bedeutet das:

• Tvarit: EU-Hosting in Frankfurt, AVV verfügbar. Für Produktionsdaten der saubere Weg ohne US-Cloud-Umweg.
• Siemens Industrial Edge: Lokale Verarbeitung auf Edge Device, nur konfigurierte Datenpunkte gehen optional in die Cloud. OT-Netz bleibt geschlossen.
• Azure ML: Region Germany West Central, DSGVO-Hosting, Standardvertragsklauseln nicht erforderlich (EU-Standort). Trotzdem: Datenflussdiagramm erstellen und intern freigeben.
• InfluxDB on-premise: Kein Datenabfluss nach außen möglich. Aber: Backup-Strategie und Zugriffskontrollen müssen intern geregelt werden.

Wenn Schichtbuch-Daten oder Bediener-Login-Informationen in das Modell einfließen sollen (z.B. “Bediener-ID als Feature”), gelten personenbezogene Datenschutzregeln. Dann ist der Betriebsrat früh einzubeziehen. Das gilt unabhängig vom gewählten Tool.

Was es kostet, realistisch gerechnet

Szenario A: DIY mit Open-Source-Stack (Python + InfluxDB + Grafana + Node-RED)

Szenario B: Industrieplattform (Tvarit oder vergleichbar)

Womit du das gegenrechnest:

Bei 50.000 Teilen/Monat und einer Lackhaftungs-Ausschussquote von 3 % (1.500 Teile) zu durchschnittlich 6 Euro Nachlackierungskosten: 9.000 Euro monatlicher Ausschuss. Eine Halbierung dieser Quote auf 1,5 % spart 4.500 Euro monatlich, das ist der konservative Ansatz.

Konservative Amortisation DIY: 25.000 € ÷ 4.500 €/Monat = rund 6 Monate nach Produktivbetrieb.
Konservative Amortisation Plattform: bei 2.000 €/Monat Lizenz verbleiben 2.500 €/Monat Netto-Ersparnis nach Lizenz; Einmalkosten 15.000 € ÷ 2.500 € = rund 6 Monate nach Produktivbetrieb.

Beide Szenarien rechnen sich, wenn die Ausschusszahlen stimmen. Wenn deine aktuelle Ausschussquote durch Lackhaftung unter 0,5 % liegt, rechnet sich keines der Szenarien. Dann ist statistische Prozesskontrolle (SPC) mit manuellen Badchecks die richtige Methode.

Drei typische Einstiegsfehler

1. Modell ohne ausreichende Trainingsdaten in Produktion bringen.
Der Druck, schnell Ergebnisse zu zeigen, verleitet dazu, das Modell nach 2–3 Monaten Daten einzusetzen. Das ist zu früh: Ein Lackhaftungsmodell braucht Daten aus verschiedenen Badständen, Jahreszeiten, Chemikalien-Chargen und Bedienerteams, um robuste Korridore zu lernen. Ein zu früh eingesetztes Modell löst entweder zu viele Fehlalarme aus (Bediener ignoriert es) oder verpasst echte Driftszenarien, die es noch nie gesehen hat. Minimum: 4–6 Monate Datenerfassung mit ausreichenden positiven und negativen Qualitätsereignissen im Datensatz.

2. Sensoren installieren, aber Kalibrierung vernachlässigen.
pH-Elektroden driften. Das ist keine Fehlfunktion, das ist Physik. Eine pH-Elektrode, die nicht wöchentlich gegen Pufferlösung kalibriert wird, misst nach 6–8 Wochen bis zu 0,3 pH-Einheiten daneben. Für einen Beizstep mit einem Arbeitsfenster von 0,6 pH-Einheiten bedeutet das: das Modell bekommt falsche Daten und gibt falsche Alarme. Ein Kalibrierprotokoll für alle Sensoren ist nicht optional, es ist das Fundament des Systems.

3. Das Modell läuft, aber es gibt keine Feedback-Schleife.
Das ist der gefährlichste stille Fehler. Gitterschnitttest-Ergebnisse werden weiterhin auf Papier oder in Excel erfasst, fließen aber nicht in die Modelldatenbank zurück. Das Modell altert. Neue Qualitätsereignisse (neue Badchemikalien, neuer Lackanbieter) sind im Modell nicht abgebildet. Nach 12 Monaten ist das System veraltet, aber es gibt weiterhin Alarme (oder gibt keine Alarme), ohne dass jemand merkt, dass es nicht mehr kalibriert ist. Lösung: Digitale Erfassung der Gitterschnittergebnisse direkt in das System, von Anfang an. Wer das auf Papier lässt, hat kein ML-System, er hat ein teures Sensor-Dashboard.

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

Die technische Seite ist das Einfachere. Das Herausforderndere: die Bedienerteams.

Die Skeptiker an der Linie. “Das Badcheck-Protokoll machen wir seit 15 Jahren. Das System kennt unsere Linie nicht besser als wir.” Diese Haltung ist nicht irrational, sie kommt aus Erfahrung. Das Gegengift ist nicht Erklärung, sondern Mitgestaltung: Die Bediener, die täglich am Bad arbeiten, wissen am besten, welche Situationen immer schwierig sind (Montagmorgen nach Wochenende, wenn das Bad lange stand; Hitzetage im Sommer). Diese Erfahrung explizit in die Modellkalibrierung einzubeziehen, “Welche drei Situationen führen bei euch am häufigsten zu Problemen?”, schafft Ownership und verbessert das Modell.

Die Fehlalarm-Falle. Ein Alarm, der dreimal falsch liegt, wird beim vierten Mal ignoriert, egal ob er richtig ist. Das ist Human Factors 101. Die Konfiguration der Alarmschwelle ist deshalb keine technische Nebentätigkeit, sondern eine kritische Entscheidung. Lieber konservativer einstellen (weniger Alarme, aber sicherere Trefferquote) und nach 3 Monaten auf Basis echter Daten nachschärfen. Ein System mit 90 % Trefferquote und 10 % Fehlalarmen wird akzeptiert. Eines mit 70 % Trefferquote und 30 % Fehlalarmen wird abgeschaltet.

Was konkret hilft:

• Bediener-Team beim Kalibrierungsprozess einbeziehen, sie validieren, ob die Alarme sinnvoll sind
• Transparentes Dashboard: nicht nur “Alarm ja/nein”, sondern “Hier der aktuelle pH-Wert, hier der Grenzwert, hier die Prognose”, Bediener verstehen, warum das System meldet
• Fehler explizit auswerten: Wenn ein Fehlalarm ausgelöst wurde und die Charge war trotzdem gut, warum? Das Modell lernt aus dieser Information

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

„Wir machen schon regelmäßige Badchecks, das reicht doch.”
Ein Badcheck alle 4 Stunden bedeutet: Ein Driftbeginn, der um 10:00 Uhr passiert, wird erst um 14:00 Uhr entdeckt. In dieser Zeit laufen 4 Stunden Produktion durch die Linie. Je nach Takt sind das 500–2.000 Teile, die lackiert wurden, und vielleicht alle Ausschuss sind. ML-Monitoring meldet innerhalb von 15 Minuten. Das ist kein Vorteil am Rand, das ist der Unterschied zwischen “wir korrigieren das Bad” und “wir verschrotten die Charge”.

„Unsere Linie ist zu alt für Digitalisierung.”
Das hängt von der Sensorik ab, nicht von der SPS. Sensoren für pH, Leitfähigkeit und Temperatur lassen sich an jedem Bad nachrüsten, unabhängig davon, ob die Steuerung 5 oder 25 Jahre alt ist. Ein Edge-Server mit Node-RED sammelt die Daten per analogem 4–20-mA-Signal, wenn nötig. Das ist keine Frage des Anlagenalters, sondern des Sensor-Budgets.

„Das kann unser Team nicht umsetzen.”
Kommt darauf an, was “umsetzen” bedeutet. Den DIY-Weg (Python, Azure ML, InfluxDB) braucht jemanden mit Programmiererfahrung und einige Monate Einarbeitung, das ist realistisch anspruchsvoll. Einen Plattform-Ansatz (Tvarit) kauft man als Dienstleistung; das Team muss das System dann betreiben und die Alarme interpretieren. Das ist ein wesentlich flacherer Einstieg. Klare Empfehlung: Wer kein IT/OT-Team hat, kauft die Dienstleistung.

Woran du merkst, dass das zu dir passt

Das System passt, wenn diese drei Signale auf dich zutreffen:

• Du hast Lackhaftungsausschuss oder Nacharbeit, der in der Kostenrechnung auftaucht. Nicht als Schätzung, als konkrete Zahl. Wenn du nicht weißt, wie hoch deine Ausschussrate durch Lackhaftungsfehler ist, ist der erste Schritt ein Messprojekt, kein ML-Projekt.
• Dein Vorbehandlungsprozess hat eine Baddrift-Vorgeschichte. Du erinnerst dich an zwei, drei Vorfälle in den letzten zwei Jahren, bei denen ein Bad abgedriftet ist und eine Charge Ausschuss produziert hat. Diese Ereignisse sind im System nicht systematisch erfasst.
• Du hast mindestens 20.000–30.000 Teile/Monat durch die Lackierlinie. Darunter ist das Datenvolumen für ein stabiles ML-Modell oft zu gering, und die Amortisationsrechnung schließt sich schwer.

Ähnlich wie bei der KI-gestützten Plüsch-Füllungskontrolle gilt: Wenn dein Prozess noch keine Grundlage an Messdaten hat, ist der erste Schritt Messtechnik, nicht KI.

Drei harte Ausschlusskriterien, wer es (noch) nicht tun sollte:

1. Weniger als ca. 10.000–15.000 Teile/Monat durch die Lackierlinie. Das Datenvolumen ist zu gering, um ausreichend Qualitätsereignisse für stabiles Modelltraining zu generieren. Statistische Prozesskontrolle (SPC) mit manuellen Messprotokollen ist in diesem Fall wirkungsvoller und günstiger. Das Verfahren skaliert erst bei nennenswertem Volumen.

2. Kein etabliertes Qualitätsprüfsystem für Lackhaftung. Wenn Gitterschnitttest-Ergebnisse nicht systematisch dokumentiert und rückverfolgt werden, hat das ML-Modell keine Zielgröße zum Lernen. Vor dem ML-Projekt muss ein belastbares Qualitätserfassungssystem stehen, zumindest in Excel, besser in einer Datenbank. Wer das überspringt, trainiert ein Modell auf Rauschen.

3. Keine OT-Anbindungsmöglichkeit oder -bereitschaft. Wenn die Vorbehandlungslinie vollständig isoliert ist, kein Ethernet vorhanden ist und keine Investitionsbereitschaft für Sensorinstallation besteht, ist das kein Digitalisierungsprojekt, das ist eine Infrastrukturaufgabe. Die Sensorinstallation ist Voraussetzung, kein Nebenprodukt des Projekts.

Das kannst du heute noch tun

Bevor du Budget und Tool-Entscheidungen triffst: Erstelle eine Fehlerhistorie.

Öffne deine Qualitätsprotokolle der letzten 12 Monate und suche alle dokumentierten Lackhaftungs-Ausschussereignisse. Für jedes Ereignis: Wann war es (Datum, Uhrzeit)? Welche Charge? War ein Baddrift zeitlich davorliegend dokumentiert?

Wenn du diese Korrelation siehst, und du wirst sie sehen, wenn die Daten vorhanden sind, hast du den Business Case für das Projekt bereits in der Hand.

Dann übergib diese Historiedaten an einen Data-Analyst mit dem folgenden Prompt:

Quellen & Methodik

• ML für Lackhaftungsvorhersage (75% Genauigkeit): Petermaier, L. et al. (2021). “Prediction of Coating Adhesion on Laser-Cleaned Metal Surfaces of Battery Cells Using Hyperspectral Imaging and Machine Learning.” Coatings, 11(11), 1388. MDPI. DOI: 10.3390/coatings11111388. Anmerkung: der Studienkontext ist Batteriezellen-Reinigung, nicht Zinkdruckguss, das zugrundeliegende Prinzip (Oberflächenzustand vor Lackierung als ML-Input) ist auf Druckguss-Vorbehandlungslinien übertragbar.
• Ausschussreduktion durch Industrie-KI: Tvarit GmbH (Frankfurt), Herstellerangaben 2024. Erwähnte Referenzkunde: Procast Guss GmbH, Gütersloh. Hersteller-Maximalwert “bis zu 60 % weniger Ausschuss”, realistische Mittelwerte für neue Implementierungen liegen erfahrungsgemäß im einstelligen bis niedrig zweistelligen Prozentbereich. Eigene Einschätzung auf Basis von Brancheninformationen.
• Konzeptdrift und Modellveralterung: Evidently AI, “How to handle ML model drift in production” (2023), sowie SmartDev, “AI Model Drift & Retraining: A Guide” (2023). Manufacturing-spezifisches Beispiel: “For quality prediction on the manufacturing line, if it just got a revamp, that makes the model learnings obsolete.”
• Sensorik-Grundlagen Zinkdruckguss-Vorbehandlung: International Zinc Association, “Surface Treatments in Zinc Die Casting” (diecasting.zinc.org). Ergänzt durch Bruschi Technology, “Surface Treatments in Zinc Die Casting” (2023).
• Sensor- und Systemkosten: Siemens AG, Industrial Edge Produktinformationen (siemens.com/industrial-edge). Tvarit GmbH, öffentliche Tarifhinweise und Partnerberichte (Stand: Mai 2026). Eigene Schätzwerte auf Basis vergleichbarer IIoT-Pilotprojekte in der DACH-Industrie.
• Kostenreferenz Nachlackierung: Eigene Branchenschätzung basierend auf typischen Prozesskosten für Kleinteile-Lackierung in der Spielwarenherstellung (3–15 EUR/Einheit). Keine unabhängige Studie, Schätzung sollte mit eigenen Kostenstellendaten validiert werden.

Du willst wissen, ob deine aktuelle Ausschusshistorie die Voraussetzungen für ein ML-Monitoring erfüllt, und was ein Pilot für euren Betrieb kosten würde? Meld dich, das klären wir gemeinsam in einem kurzen Gespräch.