Jede Diskussion über KI in der Fertigung landet irgendwann am selben Punkt: Daten. Nicht Algorithmen, nicht Rechenleistung, nicht Talente — Daten. Genauer gesagt, die Qualität der Daten, die jedes Modell, jede Vorhersage und jede automatisierte Entscheidung auf dem Shopfloor speisen. Und in den meisten Fabriken sind diese Daten in einem deutlich schlechteren Zustand, als irgendjemand zugeben möchte.
Die unbequeme Wahrheit ist: Die Fertigung erzeugt jede Sekunde enorme Datenmengen, aber nur ein Bruchteil davon ist ohne erhebliche Aufbereitung für maschinelles Lernen nutzbar. Sensoren erfassen Rohsignale. SPSen protokollieren Zustände in proprietären Formaten. MES-Systeme zeichnen Ereignisse mit eigenen Zeitstempeln und Konventionen auf. Das Ergebnis ist eine ausufernde Informationslandschaft, die oberflächlich vollständig wirkt, aber auseinanderfällt, sobald man versucht, ein Modell darauf zu trainieren.
Die vier stillen Killer der Fertigungsdaten
Datenqualitätsprobleme in der Fertigung sind nicht immer offensichtlich. Sie lösen keine Alarme aus. Sie stoppen keine Produktion. Sie verschlechtern leise die Modellperformance, bis ein Team zu dem Schluss kommt, dass „KI für unseren Prozess nicht funktioniert." In Wirklichkeit war nicht der Prozess das Problem — sondern die Daten. Hier sind die vier häufigsten Probleme, die wir fabrikübergreifend beobachten.
Sensordrift ist vielleicht das tückischste Problem. Ein Temperatursensor, der vor sechs Monaten kalibriert wurde, zeigt mittlerweile möglicherweise 2°C zu hoch an. Ein Vibrationssensor, der an einem Motorgehäuse montiert ist, verschiebt seine Basislinie allmählich, wenn die Befestigung unmerklich lockerer wird. Diese Driften sind klein genug, dass Bediener sie nie bemerken, aber groß genug, dass ein auf historischen Daten trainiertes ML-Modell fehlerhafte Vorhersagen produziert. Ohne systematische Nachverfolgung der Rekalibrierung vergiftet Sensordrift Ihren Datensatz leise über die Zeit.
Zeitstempel-Fehlausrichtung ist der zweite Killer. Eine SPS zeichnet eine Spindeldrehzahländerung um 10:03:22 auf. Das MES protokolliert ein Qualitätsereignis um 10:03:25. Die Prüfstation erfasst eine Messung um 10:03:28. Stehen diese drei Ereignisse in Zusammenhang? Das hängt vollständig davon ab, ob die Uhren synchronisiert sind — und in den meisten Fabriken sind sie es nicht. SPSen, SCADA-Systeme, MES-Plattformen und Edge-Geräte führen jeweils eigene Uhren, die manchmal um Sekunden, gelegentlich um Minuten abweichen. Wenn Sie versuchen, Ursache und Wirkung systemübergreifend zu korrelieren, machen fehlausgerichtete Zeitstempel den Aufbau zuverlässiger Trainingsdaten nahezu unmöglich.
Fehlende Labels stellen die dritte Herausforderung dar. Überwachtes maschinelles Lernen erfordert gelabelte Daten — man muss wissen, welche Produktionsläufe gut waren und welche Defekte aufwiesen, welche Maschinenzustände zu Ausfällen führten und welche normal waren. Aber in der Fertigung sind Ausfälle seltene Ereignisse. Qualitätsergebnisse werden oft Stunden oder Tage nach der Produktion erfasst. Ursachen sind mehrdeutig, inkonsistent dokumentiert oder gar nicht dokumentiert. Einen gelabelten Datensatz für einen Prozess mit 0,3 % Defektrate aufzubauen, bedeutet, dass man Tausende von Produktionszyklen benötigt, nur um eine statistisch aussagekräftige Anzahl an Fehlerbeispielen zu erhalten.
Kontextlücken sind das vierte und am meisten übersehene Problem. Ein Vibrationswert von 4,2 mm/s bedeutet beim Maschinenanlauf etwas völlig anderes als im eingeschwungenen Produktionsbetrieb. Die gleiche Stromaufnahme eines Motors erzählt eine andere Geschichte bei einer Schruppoperation als bei einem Schlichtdurchgang. Ohne betrieblichen Kontext — das Rezept, den Werkzeugzustand, die Materialcharge, die Produktionsphase — sind rohe Sensordaten mehrdeutig. Modelle, die ohne diesen Kontext trainiert werden, lernen Muster, die sich nicht verallgemeinern lassen, weil sie Rauschen anpassen statt Prozessphysik.
Warum herkömmliche Ansätze zu kurz greifen
Die Standardreaktion auf Datenqualitätsprobleme ist, ein Data-Engineering-Team einzustellen, ETL-Pipelines zu bauen und die Daten zentral zu bereinigen. Dieser Ansatz hat in einer Fertigungsumgebung drei fundamentale Schwächen:
- Data Engineers verstehen den Prozess nicht. Sie können Formate normalisieren und offensichtliche Ausreißer entfernen, aber sie können nicht beurteilen, ob ein Temperatursprung zum Zeitpunkt X Sensordrift, eine legitime Prozessänderung oder ein Anfahrtransient ist. Nur jemand, der die Maschine versteht, kann diese Entscheidung treffen.
- Zentrale Bereinigung ist zu langsam. Bis eine Datenpipeline gebaut, validiert und für einen Anwendungsfall deployed ist, hat sich der Prozess bereits verändert — neues Werkzeug, andere Materialchargen, aktualisierte Rezepte. Die Pipeline jagt immer einem beweglichen Ziel hinterher.
- Es skaliert nicht. Jeder neue KI-Anwendungsfall erfordert seinen eigenen Datenaufbereitungs-Workflow. Der zweite Anwendungsfall dauert fast so lange wie der erste, weil die zugrundeliegenden Datenprobleme nachgelagert statt an der Quelle behoben werden.
Daten an der Quelle korrigieren — mit No-Code-Tools
Der Durchbruch gelingt, wenn man Werkzeuge zur Datenaufbereitung direkt in die Hände der Menschen legt, die den Prozess verstehen: der Prozessingenieure, der Qualitätsmanager, der Maschinenbediener. Das sind die Menschen, die wissen, dass Sensor 7 an Linie 3 seit dem letzten Wartungsfenster driftet. Sie wissen, dass die ersten 45 Sekunden nach einem Werkzeugwechsel immer abnormale Vibrationswerte erzeugen. Sie wissen, welche Materialchargen sich unterschiedlich verhalten.
Genau deshalb haben wir das RockQ ML Studio als visuelle No-Code-Umgebung entwickelt. Prozessingenieure können Signaldaten grafisch inspizieren, Driftperioden identifizieren und entfernen, Zeitstempel systemübergreifend abgleichen, betrieblichen Kontext taggen und Qualitätsergebnisse labeln — alles ohne eine einzige Zeile Code. Die Daten werden dort korrigiert, wo das Wissen liegt, nicht in einem abgekoppelten Data-Engineering-Silo drei Abteilungen entfernt.
Die Auswirkung ist messbar. Wenn Domänenexperten die Daten aufbereiten, trainieren Modelle schneller, generalisieren besser und benötigen deutlich weniger Iterationen, um produktionsreife Genauigkeit zu erreichen. Noch wichtiger: Der Datenaufbereitungs-Workflow wird wiederverwendbar. Die gleiche Bereinigungslogik, die Daten für ein Predictive-Maintenance-Modell vorbereitet, kann für ein Qualitätsvorhersagemodell auf derselben Linie adaptiert werden, weil die zugrundeliegenden Datenprobleme an der Quelle gelöst werden, anstatt in einer einmaligen Pipeline gepatcht zu werden.
Fertigungsdaten werden nie perfekt sein. Sensoren werden driften, Uhren werden abweichen, Labels werden unvollständig sein. Die Frage ist nicht, ob diese Probleme existieren — das werden sie immer. Die Frage ist, ob Ihre Organisation sie schnell genug identifizieren und beheben kann, mit den richtigen Menschen, unter Verwendung von Werkzeugen, die zu deren Expertise passen. Das ist das eigentliche Fundament von KI in der Fertigung.