Von Rohdaten zu verwertbaren Erkenntnissen: Diese Vorteile bringt die Standardisierung von Fertigungsdaten
Veröffentlicht am 18. September 2026 in Industrie 4.0
Viele Hersteller, die in industrielle Analytik investiert haben, kommen irgendwann zu einer sehr ähnlichen unangenehmen Erkenntnis: Das Problem der Analytik ist eigentlich ein Datenproblem.
Dashboards sind unvollständig, weil bestimmte Maschinen keine zuverlässige Verbindung herstellen. KI-Modelle liefern inkonsistente Ergebnisse, da dieselbe Variable in verschiedenen Produktionslinien unterschiedlich benannt, in unterschiedlichen Einheiten gemessen und mit unterschiedlichen Abtastraten erfasst wird. Das Hinzufügen eines neuen Datenfeeds für ein Pilotprojekt erfordert wochenlange Integrationsarbeit, da niemand den Zusammenhang zwischen Fertigungsbereich und IT-Ebene vollständig versteht.
Die Ursache liegt tiefer: in einer Datenarchitektur, die den Anforderungen moderner Analytik nicht gerecht wird. Die beiden Standards Unified Namespace (UNS) und PackML bilden in diesem Zusammenhang das Fundament für eine moderne, vernetzte Dateninfrastruktur in der Fertigung
Ohne einheitliche Datenbasis keine wirksamen Analysen
In der industriellen Fertigung kommen zahlreiche Kommunikationsprotokolle zum Einsatz, darunter OPC UA, Modbus, PROFINET, EtherNet/IP und herstellerspezifische Formate. Maschinen und ältere Systeme sprechen dadurch oft unterschiedliche Datensprachen. Zudem sind viele Systeme nur mit den Anwendungen und Anlagen verbunden, für die sie ursprünglich eingerichtet wurden. Über die Jahre entsteht so ein schwer überschaubares Netz direkter Punkt-zu-Punkt-Verbindungen, eine sogenannte „Spaghetti-Architektur“, die sich nur mit erheblichem Aufwand erweitern und anpassen lässt.
Dies führt zu zwei sich verstärkenden Problemen. Das erste ist die „Poll-and-Push“-Falle: Systeme fragen sich gegenseitig kontinuierlich nach Aktualisierungen ab, unabhängig davon, ob sich etwas geändert hat, was unnötigen Datenverkehr erzeugt und Latenzzeiten verursacht, die Echtzeitentscheidungen erschweren. Das zweite ist das Problem des Datenchaos: Selbst wenn Daten zugänglich sind, sind sie inkonsistent. Dieselbe physikalische Messgröße, etwa die Produktionsgeschwindigkeit, kann auf drei Maschinen derselben Linie unterschiedlich bezeichnet, in unterschiedlichen Einheiten ausgedrückt und in unterschiedlichen Datentypen gespeichert sein. Ein linienübergreifender Vergleich erfordert eine Übersetzungsebene. Eine standortübergreifende Analyse erfordert mehrere. Bevor sich aussagekräftige Analysen erstellen lassen, müssen diese Daten bereinigt, harmonisiert und kontextualisiert werden.
Benötigt ein Team neue Daten für ein Dashboard oder KI-Modell, muss es zunächst den gesamten Datenfluss nachvollziehen, von der Quelle bis zur Anwendung. Diese aufwendige Analyse der bestehenden Systemlandschaft zählt zu den größten Hürden für den Einsatz industrieller KI und fortgeschrittener Analytik.
Unified Namespace: Maschinendaten zentral verfügbar machen
Der Unified Namespace (UNS) löst das Integrationsproblem, indem er das Punkt-zu-Punkt-Modell durch eine Publish-Subscribe-Architektur ersetzt. Statt direkte Verbindungen zwischen Datenquellen und Anwendungen einzurichten, stellt jede Quelle ihre Daten über einen zentralen Broker bereit. Anwendungen und andere Datenempfänger abonnieren gezielt die Datenströme, die sie benötigen. So lassen sich neue Empfänger anbinden, ohne die Quellsysteme anpassen zu müssen.
Die gängigste Implementierung nutzt MQTT (Message Queuing Telemetry Transport) als Messaging-Protokoll. Dieses leichtgewichtige Publish/Subscribe-Protokoll wurde genau für die Bedingungen in industriellen Umgebungen konzipiert: unzuverlässige Netzwerke, Geräte mit begrenzten Ressourcen und die Notwendigkeit einer Übertragung mit geringer Latenz. Die Spezifikation Sparkplug B ergänzt dies um ein sogenanntes „Report-by-Exception“-Verfahren: Geräte melden Änderungen nur dann, wenn Messwerte einen definierten Schwellenwert über- oder unterschreiten. Eine kontinuierliche Abfrage in festen Intervallen ist damit nicht erforderlich.
Die Namespace-Struktur folgt der ISA-95-Hierarchie:
Unternehmen
└── Standort
└── Bereich
└── Leitung
└── Zelle / Gerät
└── Tags (Status, Kennzahlen, Ereignisse, Alarme)
Jeder Datenpunkt ist über einen eindeutig definierten Pfad innerhalb der Hierarchie auffindbar. Systeme, die diese Struktur verstehen, können direkt auf die benötigten Daten zugreifen, ohne dass dafür individuelle Schnittstellen oder zusätzliche Integrationen erforderlich sind. So lässt sich die Architektur flexibel erweitern und skalieren.
PackML: Maschinendaten herstellerübergreifend vergleichbar machen
Der Unified Namespace schafft eine einheitliche Architektur für die Datenintegration. PackML ergänzt diesen Ansatz auf Maschinenebene: Der Standard sorgt dafür, dass Maschinen ihre Betriebszustände nach einem gemeinsamen Schema beschreiben. Denn Maschinen verschiedener Hersteller verwenden oft unterschiedliche Bezeichnungen für denselben Zustand. Die eine meldet „In Betrieb“, „Gestört“ oder „Leerlauf“, die nächste „Auto“, „Not-Aus“ oder „Standby“. Andere arbeiten mit numerischen Codes.
Sollen Daten aus einer solchen Produktionslinie gemeinsam ausgewertet werden, müssen diese unterschiedlichen Angaben zunächst übersetzt und vereinheitlicht werden. PackML vereinfacht diese Übersetzung. Der Standard definiert ein gemeinsames Modell für Maschinenzustände und die Übergänge zwischen ihnen. Dazu gehören beispielsweise Zustände wie „Gestoppt“, „Leerlauf“ und „Ausführung“ sowie die Schritte, die eine Maschine beim Starten oder Stoppen durchläuft.
PackML definiert ein Standard-Zustandsmodell, das alle Maschinen übernehmen können:
Gestoppt ──► Zurücksetzen ──► Leerlauf ──► Start ──► Ausführung (Lauf) │ Abschluss │ Fertig ──► Zurücksetzen
In einer PackML-konformen Umgebung verwendet jede Maschine dieselben Zustandsnamen und Übergänge. Leistungskennzahlen wie Ist-Geschwindigkeit, Soll-Geschwindigkeit, Stückzahl und Ausschussanzahl werden unter standardisierten Tag-Namen veröffentlicht. Unterstützen Maschinen verschiedener Hersteller PackML, ist für den Vergleich ihrer Leistung keine Übersetzung erforderlich. Die Daten sind direkt vergleichbar.
PackML trifft auf UNS: Die Kombination, die linienübergreifende Analysen ermöglicht
Wenn PackML-konforme Maschinen ihre standardisierten Zustands- und Tag-Daten über MQTT in einen Unified Namespace (UNS) einspeisen, entsteht ein gemeinsames Daten-Backbone für die Fertigung. Es sorgt dafür, dass:
- alle Maschinen dieselbe Datensprache sprechen und einheitliche Bezeichnungen für Zustände und Datenpunkte verwenden,
- jeder Datenpunkt über einen vorhersehbaren Pfad in der ISA-95-Hierarchie eindeutig auffindbar ist,
- Daten effizient übertragen werden: Nach dem „Report-by-Exception“-Prinzip von Sparkplug B werden Aktualisierungen nur bei relevanten Änderungen veröffentlicht.
Der Integrationsaufwand, der bisher dazu führte, dass linienübergreifende Analysen ein monatelanges Projekt waren, wird zu einer reinen Konfigurationsaufgabe.
Datenfilterung auf Edge-Ebene
UNS und PackML schaffen eine saubere, standardisierte Datenarchitektur. Doch in einer großen Produktionsumgebung mit Hunderten von SPSen, Tausenden von Sensoren und Dutzenden von Fertigungslinien können schnell mehrere zehn Millionen Datenpunkte pro Minute anfallen. Sämtliche Daten an eine Cloud-Analyseplattform zu übertragen, ist kostspielig und verursacht Verzögerungen, die Echtzeitentscheidungen direkt an der Maschine erschweren oder unmöglich machen. Gleichzeitig verschlechtert die Datenflut das Signal-Rausch-Verhältnis und damit die Qualität der Datengrundlage für Analysemodelle.
Eine intelligente Datenfilterung auf Edge-Ebene löst dieses Problem direkt. In der Edge-Ebene werden die rohen OT-Daten von SPSen, Sensoren und Feldbussystemen gesammelt, in Standardformate übersetzt, vorverarbeitet und selektiv weitergeleitet. Sie bildet die intelligente Grenze zwischen dem physikalischen Prozess und den Informationssystemen, die diesen analysieren.
Zwei Filterverfahren reduzieren das Datenvolumen besonders effektiv. Die Totbandfilterung unterdrückt Meldungen, solange sich ein Messwert nicht stärker als um einen festgelegten Schwellenwert verändert. Schwankt beispielsweise ein Temperatursensor nur um 0,1 °C um einen stabilen Sollwert, werden diese geringfügigen Abweichungen nicht übertragen. Die Aggregation fasst Messdaten direkt am Edge über einen festgelegten Zeitraum zusammen. Statt Tausende einzelne Messwerte weiterzuleiten, überträgt das System kompakte Kennzahlen wie Mittelwert, Minimal- und Maximalwert sowie Standardabweichung. So gelangen weniger Daten in nachgelagerte Systeme, ohne dass wichtige Informationen über den Prozess verloren gehen müssen.
Die Cloud-Kostenrechnung
Die wirtschaftlichen Argumente für die Edge-Filterung liegen auf der Hand. Ein Fertigungsstandort mit 50 Maschinen, bei dem jede Maschine 200 Tags mit einer Abfrageauflösung von einer Sekunde bereitstellt, erzeugt etwa 10.000 Datenpunkte pro Sekunde oder 864 Millionen pro Tag. Bei typischen Preisen für Cloud-IoT-Plattformen von 0,10 bis 0,30 Euro pro Million Nachrichten entstehen allein an Erfassungskosten 86 bis 260 Euro pro Tag, noch bevor Speicher- oder Verarbeitungskosten hinzukommen. Durch die Anwendung von „Report-by-Exception“ und Dead-Band-Filterung am Edge, was das Nachrichtenvolumen um 90 Prozent reduziert, ändert sich das Bild erheblich:
- Gefiltert: 86 Millionen Nachrichten pro Tag → 9 – 26 € pro Tag an Erfassungskosten
- Der Speicherbedarf wird proportional reduziert
- Die Last der Stream-Verarbeitung wird reduziert, was kleinere und kostengünstigere Rechenstufen ermöglicht
In der Praxis kostet eine reine Cloud-Architektur für einen Standort dieser Größe etwa 3.000 bis 4.500 Euro pro Monat. Eine am Edge gefilterte Architektur senkt diese Kosten auf etwa 400 bis 600 Euro pro Monat. Die Investition in die Edge-Hardware amortisiert sich in der Regel in weniger als drei Monaten, und die Einsparungen über fünf Jahre betragen für einen einzelnen Standort mehr als 150.000 Euro, noch bevor der Wert schnellerer und zuverlässigerer Entscheidungen berücksichtigt wird.
Von Daten zu Entscheidungen: Was diese Architektur ermöglicht
- Produktions-Dashboards in Echtzeit, ohne aufwendige Einzelintegrationen. Da Maschinen standardisierte Daten in einem gemeinsamen Namensraum bereitstellen, lassen sich Dashboards gezielt aufbauen, indem sie die benötigten Datenströme abonnieren. Individuelle Schnittstellenlösungen und die Abhängigkeit von herstellerspezifischen APIs werden damit weitgehend überflüssig.
- Leistungsvergleiche über Produktionslinien und Standorte hinweg. PackML schafft ein einheitliches Vokabular für Maschinenzustände, während der UNS für eine konsistente Adressstruktur sorgt. So lässt sich beispielsweise die Leistung einer Produktionslinie an einem Standort direkt mit der einer vergleichbaren Linie an einem anderen Standort vergleichen, ohne dafür zunächst ein eigenes Integrationsprojekt aufsetzen zu müssen.
- Eine verlässliche Datenbasis für KI und maschinelles Lernen. Statt uneinheitlicher Rohdaten erhalten Analysemodelle strukturierte, kontextbezogene und einheitlich formatierte Informationen. Das verbessert die Voraussetzungen für aussagekräftige Ergebnisse und hilft, eine häufige Hürde beim Übergang von KI-Pilotprojekten in den produktiven Einsatz zu überwinden: eine unzureichende Datenbasis.
- Schnellere Entscheidungen direkt an der Maschine. Werden KI-Inferenz und Steuerungslogik am Edge ausgeführt, lassen sich zeitkritische Entscheidungen lokal treffen, ohne auf die Übertragung zur Cloud und zurück angewiesen zu sein. Das ist besonders wichtig für Anwendungen mit Reaktionszeiten im Millisekundenbereich, etwa die Qualitätskontrolle im geschlossenen Regelkreis oder die Anpassung von Prozessparametern in Echtzeit.
So kann OMRON Sie unterstützen
Die Einführung von UNS und PackML erfordert keinen Austausch bestehender Anlagen oder Systeme. Die meisten SPSen und industriellen Steuerungen lassen sich so konfigurieren, dass sie ihre Daten mithilfe von Edge-Gateway-Software über MQTT bereitstellen. Unterstützen Maschinen PackML nicht direkt, lässt sich die Kompatibilität über eine Übersetzung auf Gateway-Ebene herstellen. Ein sinnvoller Einstieg ist eine einzelne Produktionslinie oder Fertigungszelle. Dort wird zunächst die Edge-Infrastruktur eingerichtet und das Datenmodell validiert. Anschließend lässt sich die Lösung schrittweise auf weitere Bereiche ausweiten.
Der i-BELT-Service von OMRON unterstützt Unternehmen bei dieser Transformation: von der Planung der IT-OT-Architektur und der Definition des Datenmodells über die Bereitstellung der Edge-Infrastruktur bis zur Anbindung an Unternehmenssysteme. Dabei werden Entscheidungen zur Dateninfrastruktur mit den konkreten Produktionskennzahlen (KPIs) verknüpft, die das Unternehmen verbessern möchte.
Weitere Informationen finden Sie unter:
i-BELT Service