Eine Produktionslinie meldet einen Fehler, obwohl die Ursache zwei Bereiche weiter liegt. Genau an diesem Punkt scheitern viele KI-Projekte in der Industrie. Die Maschinen sind vernetzt, ihre Daten kommen an. Doch Ankunft ist noch keine Verwendbarkeit.

Auf der Ignition Community Conference 2026 wurde dieses Problem an einer Produktionsanlage demonstriert. Mehr als 1.800 Teilnehmende und über 60 Sessions beschäftigten sich mit der Frage, wie sich vorhandene Produktionsdaten sinnvoll nutzen lassen. Die technische Verbindung ist dabei nicht der schwierigste Teil. Schwieriger ist die Einordnung. Ein Messwert braucht einen Ort, eine Einheit, einen Prozessbezug und eine Aussage darüber, ob er überhaupt plausibel ist.

Diese Arbeit wird in vielen Projekten nach hinten verschoben. Erst werden Maschinen angeschlossen. Danach landen Werte in einer zentralen Plattform. Irgendwann beginnt jemand, aus uneinheitlichen Bezeichnungen, fehlenden Zeitbezügen und unklaren Zuständigkeiten ein Datenmodell zu bauen. Das kostet Zeit und produziert Unsicherheit. Eine Angabe aus dem Konferenzbeitrag bringt die Lage auf den Punkt. 70 Prozent der Hersteller sehen Datenqualität, Kontext und Validierung als wesentliche Hindernisse für industrielle KI. Ein Fertigungskunde vertraut sogar 60 Prozent der gesammelten Daten nicht.

Die Ursache liegt oft außerhalb der betroffenen Linie

Die Demonstration nutzt eine Anlage mit drei Produktionsbereichen und einer gemeinsamen Druckluftversorgung. In Packaging füllt und verschließt eine Linie 60 Flaschen pro Minute. Processing mischt und pasteurisiert das Produkt. Ein regelmäßiger Reinigungszyklus benötigt dort viel Druckluft. Utilities versorgt die Bereiche unter anderem mit Druckluft, Kaltwasser und Dampf.

Nach dem Start des Reinigungszyklus verschlechterte sich die Leistung der Verpackungslinie deutlich. Die Zeit zwischen zwei Ausfällen sank von 3,1 Minuten auf weniger als 30 Sekunden. Die Gesamtanlageneffektivität fiel von 67 auf 45 Prozent. Auf dem Bildschirm erschien immer derselbe Fehlercode, E-217 Cap Misfeed. Aus Sicht der Linie lag der Verdacht beim Verschließer.

Eine breitere Auswertung führte zu einer anderen Diagnose. Die Reparaturzeiten wurden kürzer, die Ausfälle traten aber wesentlich häufiger auf. Benachbarte Maschinen zeigten weder Materialmangel noch Rückstau. Das Verschlussdrehmoment lag innerhalb der Vorgaben. Erst die Verbindung mit den Daten aus Utilities machte die zeitliche Abhängigkeit sichtbar. Rund 40 Sekunden nach Beginn des Reinigungszyklus sank der Druck im gemeinsamen Verteiler von 6,5 auf 5,5 bar.

Der Verschließer war also nicht defekt. Er reagierte auf eine Versorgungssituation, die in einem anderen Produktionsbereich ausgelöst wurde. Ein Agentennetzwerk empfahl eine Anpassung des Sollwerts. Ein Mensch gab die Änderung frei. Danach stabilisierte sich die Gesamtanlageneffektivität laut Demonstration bei ungefähr 60 Prozent. Die Maschine an der Verpackungslinie musste nicht verändert werden.

Kontext entsteht nahe an der Maschine

Für CTOs und Innovationsmanager liegt darin die wichtigste technische Aussage. Eine zentrale Plattform kann Daten sammeln. Sie kann aber fehlenden Kontext nicht zuverlässig nachträglich erfinden. Deshalb setzt die gezeigte Architektur früher an. Daten werden bereits am Edge geprüft, mit einem Informationsmodell verbunden und auf ihre Gültigkeit kontrolliert.

Die Verbindung zwischen Operational Technology und IT übernimmt ein sicherer MQTT Datenstrom. Ignition Edge liest OPC UA Tags ein und veröffentlicht sie über Sparkplug B. Eine MQTT Plattform dekodiert diese Information einmal und stellt sie anschließend in einem durchsuchbaren Namensraum bereit. Nachgelagerte Anwendungen müssen dadurch keine eigene Sparkplug Bibliothek verwenden.

Entscheidend ist weniger das einzelne Protokoll als die Zuständigkeit für den Kontext. Eine Kennzahl wie Overall Equipment Effectiveness darf nicht an jedem Standort anders berechnet werden. Auch Begriffe wie Stillstand, Reparaturzeit oder Ausfall müssen eindeutig definiert sein. In der gezeigten Struktur werden solche Kennzahlen aus normalen Tags möglichst nahe an der Quelle berechnet. Berechnete Werte können anschließend wieder in die vorhandenen Ignition Dashboards zurückfließen.

Das wirkt zunächst unspektakulär. In der Praxis entscheidet genau diese Ebene darüber, ob ein Modell belastbare Signale erhält oder nur sauber aussehende Zahlen. Bei Smart X Automation ist deshalb die Frage nach Datenmodellen und Freigaben genauso wichtig wie die Auswahl eines KI Modells. Ein technisch leistungsfähiger Agent hilft wenig, wenn er unterschiedliche Definitionen von Stillstand miteinander vergleicht.

Agenten brauchen Grenzen und einen gemeinsamen Datenraum

Die demonstrierte Analyse arbeitet mit einem Orchestrator, einem Monitor und einem Analysten. Diese Agenten greifen auf Daten aus Ignition, MQTT, SQL und REST zu. Ihre Stärke liegt in der Verbindung verschiedener Bereiche. Ein einzelnes Dashboard hätte den Druckabfall in Utilities vermutlich nicht mit dem Fehler an der Verpackungslinie verknüpft.

Das bedeutet jedoch nicht, dass ein Agent direkt in die Steuerung eingreifen sollte. Die Quelle setzt auf Empfehlungen durch die Software und Freigaben durch Menschen. Protokollierung und klar definierte Grenzen gehören dabei zur Architektur. Diese Zurückhaltung ist vernünftig. Eine Empfehlung lässt sich prüfen. Eine automatische Änderung an einer laufenden Anlage verlangt deutlich mehr Vertrauen, Nachweise und technische Absicherung.

Für mehrere Standorte kommt eine weitere Voraussetzung hinzu. Produktionsdaten werden nach Standort, Bereich, Linie und Anlage geordnet. Ein lokaler Namensraum kann mit einem globalen verbunden werden. Definitionen und Kennzahlen lassen sich dadurch an mehreren Orten einheitlich verwenden. Das ist praktisch, wenn Standorte ihre Ausfallzeiten vergleichen sollen. Es setzt aber voraus, dass die Begriffe vorab verbindlich festgelegt wurden.

Die Architektur ersetzt vorhandene Systeme nicht. Ignition, OPC UA und bestehende Dashboards bleiben erhalten. Verändert wird vor allem der Ort, an dem Kontext, Prüfung, Kennzahlen und Analyse stattfinden. Genau darin liegt der realistische Ansatz für den Mittelstand. Ein Pilot muss nicht mit einer neuen Gesamtplattform beginnen. Er muss zeigen, ob die Daten eines konkreten Prozesses vollständig, verständlich und für eine Entscheidung geeignet sind.

Die Konferenzdemonstration belegt keine Amortisationszeit und keinen dauerhaften Produktivitätsgewinn im Serienbetrieb. Sie zeigt aber ein relevantes Muster. Ein lokaler Fehlercode kann die falsche Ursache nahelegen, wenn der Prozesszusammenhang fehlt. KI wird in der Produktion deshalb erst dann belastbar, wenn Daten Herkunft, Bedeutung und Gültigkeit mitliefern. Vernetzung schafft die Verbindung. Erst Kontext macht daraus eine Grundlage für Entscheidungen.

Quelle: HiveMQ