Unsere Erfahrung hat zwei Adressen! Um die Welt der Collaborative und Meeting Spaces zu entdecken:
In der heutigen industriellen Realität zeigt sich ein gewisser Widerspruch. Einerseits erzeugen Sensoren, Steuerungen und vernetzte Anlagen Datenmengen in einem Ausmaß, das es so noch nie gegeben hat. Andererseits bleiben laut Studien von Forrester, die in mehreren Branchenanalysen aufgegriffen werden, rund 70 % dieser Daten ungenutzt. Nicht, weil sie keinen Wert hätten, sondern weil sie schlicht nicht dort ankommen, wo sie benötigt werden.
Das eigentliche Problem ist also nicht die Datenerzeugung, sondern ihr Transport. Genau hier setzt das Management industrieller Datenflüsse an: nicht als zusätzliche technische Ebene, sondern als zentrale Infrastruktur, ohne die Entscheidungen in Echtzeit kaum möglich sind.
Bevor man sich mit Architekturen und Protokollen beschäftigt, lohnt sich ein Blick darauf, warum dieses Problem trotz jahrzehntelanger Automatisierungs- und Leitsysteme weiterhin besteht.
Die Antwort lässt sich in einem Wort zusammenfassen: Silos. Industrielle Umgebungen wurden historisch auf Robustheit und Leistung ausgelegt, nicht auf Offenheit. Eine Siemens-SPS aus den frühen 2000er-Jahren war nie dafür gedacht, direkt mit einem SAP-ERP-System zu kommunizieren. Ein SCADA-System in einer Chemieanlage war nicht dafür konzipiert, Daten in einen Cloud-Data-Lake zu übertragen. Diese Systeme waren bewusst geschlossen gestaltet: weniger Schnittstellen bedeuteten weniger Ausfallrisiken und geringere Angriffsflächen.
Heute steht diese Architektur im Widerspruch zu den Anforderungen der vernetzten Industrie. Produktionsverantwortliche erwarten Echtzeitkennzahlen, das Management möchte Daten standortübergreifend konsolidieren, und Instandhaltungsteams versuchen, Anomalien frühzeitig zu erkennen, bevor es zu Stillständen kommt. All das setzt voraus, dass Daten zuverlässig, konsistent und sicher ihren Weg finden – vom Sensor bis zur Anwendung, die sie benötigt.
Laut dem IT/OT-Observatorium 2024 von NXO und Cisco, das 135 industrielle Entscheidungsträger befragt hat, sehen 64 % der Befragten den Datenfluss als oberste Priorität ihrer Programme zur Konvergenz von IT- und Produktionsnetzwerken. Nur 11 % der Unternehmen hatten diese Konvergenz zum Zeitpunkt der Erhebung bereits vollständig umgesetzt, während 44 % sie zumindest angestoßen hatten. Das Vorhaben ist also in vollem Gange, aber noch längst nicht abgeschlossen.
Damit eine Messgröße von einem Drucksensor in ein Leitsystem oder eine Cloud-Pipeline gelangt, braucht es zunächst eine gemeinsame „Sprache“. Genau das leisten industrielle Kommunikationsprotokolle – und ihre Landschaft ist deutlich weniger einheitlich, als man annehmen würde.
Modbus wurde 1979 von Modicon entwickelt und ist bis heute eines der am weitesten verbreiteten Protokolle in der Fertigung. Es basiert auf einem einfachen Master-Slave-Modell: Eine Steuerung fragt ein Gerät ab, das anschließend seine Daten zurückliefert. Mit der Variante Modbus TCP hat es den Sprung ins Ethernet-Zeitalter geschafft. Seine Stärke liegt in seiner Einfachheit und breiten Unterstützung – nahezu jedes industrielle Gerät beherrscht es.
Doch Modbus stammt aus einer anderen Zeit. Sicherheit ist nicht nativ integriert, es gibt kein standardisiertes Datenmodell, und das Polling-Prinzip (der Master fragt jedes Gerät einzeln ab) wird schnell zum Engpass, sobald die Anzahl der Teilnehmer steigt. Für bestehende Maschinenparks bleibt es daher unverzichtbar, ist jedoch nicht dafür ausgelegt, große Datenströme in Echtzeit Richtung Cloud zu liefern.
OPC UA (Open Platform Communications Unified Architecture) verfolgt einen deutlich anderen Ansatz. Es basiert auf einem hierarchischen Objektmodell, das nicht nur Messwerte wie Temperatur, Druck oder Durchfluss beschreibt, sondern auch ihren Kontext: zu welchem Gerät sie gehören, welche Einheit sie haben und welche Grenzwerte gelten.
Diese semantische Tiefe unterscheidet OPC-UA klar von Modbus. Es transportiert nicht nur Rohwerte, sondern strukturierte, interpretierbare Informationen.
OPC-UA unterstützt zudem das Publish/Subscribe-Modell (Pub/Sub), wodurch das klassische Master-Slave-Prinzip entfällt: Geräte veröffentlichen Daten bei Änderungen, während abonnierende Systeme sie direkt empfangen. Das ist ein wichtiger architektonischer Wandel, insbesondere für Echtzeitanwendungen. Auch die integrierte Sicherheit mit Verschlüsselung, Authentifizierung und Signaturen macht OPC-UA zu einer zentralen Technologie in regulierten Umgebungen wie unter der NIS-2-Richtlinie.
Der Nachteil liegt in der Komplexität der Implementierung. Der Aufbau einer Verbindung erfordert mehrere Schritte wie Handshake, Sicherheitsverhandlung und Session-Management. Das erzeugt mehr Overhead als bei Modbus oder MQTT. In Umgebungen mit geringer Bandbreite oder sehr ressourcenarmen Geräten kann das problematisch sein.
MQTT (Message Queuing Telemetry Transport) wurde speziell für stark eingeschränkte Umgebungen entwickelt: instabile Netzwerke, geringe Rechenleistung und intermittierende Verbindungen. Das Protokoll ist extrem leichtgewichtig, der Overhead minimal, und das Publish/Subscribe-Modell über einen zentralen Broker eignet sich ideal für verteilte Systeme mit vielen Datenquellen.
In einem typischen Setup senden industrielle Gateways oder Steuerungen ihre Messwerte an MQTT-Topics (zum Beispiel fabrik/linie3/presse/temperatur). Ein Broker – häufig Eclipse Mosquitto oder EMQX – empfängt diese Nachrichten und verteilt sie an abonnierende Systeme wie SCADA, Datenplattformen oder Predictive-Maintenance-Anwendungen. Bei Verbindungsabbrüchen kann MQTT Nachrichten puffern und nach der Wiederverbindung erneut zustellen, wodurch Datenverluste vermieden werden.
Die Einschränkung von MQTT liegt in der fehlenden nativen Semantik. Ein Message enthält zwar einen Wert, aber das Protokoll selbst definiert nicht, was dieser Wert bedeutet, welchem Sensor er zugeordnet ist oder in welcher Einheit er gemessen wird. Deshalb wurde mit Sparkplug B eine Erweiterung entwickelt, die MQTT um ein standardisiertes Datenmodell ergänzt.
In der Praxis sind OPC-UA und MQTT keine Konkurrenten, sondern ergänzen sich. OPC-UA wird häufig im Produktionsnetzwerk eingesetzt, wo semantische Tiefe und Sicherheit im Vordergrund stehen. MQTT übernimmt dagegen den Transport Richtung Cloud oder externe Systeme, wo Leichtgewichtigkeit und Robustheit gegenüber Verbindungsabbrüchen entscheidend sind.
Das Verständnis einzelner Protokolle reicht nicht aus, wenn man die Gesamtarchitektur nicht im Blick hat. Ein moderner industrieller Datenfluss ist in der Regel in drei klar abgegrenzte Ebenen strukturiert.
Hier beginnt alles. Sensoren für Temperatur, Vibration, Druck, Durchfluss oder Stromstärke erzeugen analoge oder digitale Signale. Diese werden von Steuerungs- und Erfassungssystemen verarbeitet – speicherprogrammierbaren Steuerungen (SPS), Datenerfassungsmodulen oder Prozessleitsystemen für kontinuierliche Prozesse (DCS) – und über die entsprechenden Protokolle bereitgestellt.
Eine moderne Produktionslinie kann mehrere tausend Messpunkte erzeugen, mit Abtastraten von wenigen Millisekunden bis hin zu mehreren Sekunden. Alles ungefiltert in die Cloud zu senden wäre zwar technisch möglich, aber wirtschaftlich nicht sinnvoll – und oft auch fachlich unnötig: Eine hochfrequente Abtastung einer langsam variierenden Temperatur liefert vor allem Rauschen statt zusätzlicher Erkenntnis.
Hier entscheidet sich ein großer Teil der Systemqualität. Ein industrielles Edge-Gateway – häufig ein robuster Industrie-PC oder spezialisierte Hardware von Herstellern wie Siemens, Moxa oder Advantech – übernimmt mehrere zentrale Funktionen direkt vor Ort.
Zunächst erfolgt die Protokollnormalisierung: Daten aus Modbus RTU, Profinet, OPC-UA oder analogen 4–20-mA-Signalen werden aufgenommen und in ein einheitliches Format überführt. Man spricht hier oft von Protokoll-Gateways.
Darauf folgt die Datenreduktion und Filterung: Statt alle Messwerte kontinuierlich weiterzuleiten, werden nur relevante Änderungen (Change of Value, CoV), aggregierte Kennzahlen über Zeitfenster oder ereignisbasierte Alarme übertragen. Dadurch lässt sich das Datenvolumen erheblich reduzieren.
Immer häufiger kommt zusätzlich lokale Intelligenz zum Einsatz: einfache Anomalieerkennung, Vorverarbeitung oder sogar leichtgewichtige Machine-Learning-Modelle, die direkt auf Embedded-Hardware (ARM oder x86) laufen, etwa mit TensorFlow Lite oder OpenVINO. Diese Verarbeitung vor Ort ermöglicht Reaktionszeiten im Millisekundenbereich, unabhängig von der Cloud-Verfügbarkeit.
Sobald die Daten normalisiert und gefiltert sind, gelangen sie in die Integrationsschicht. Hier kommen Datenpipelines und Messaging-Systeme zum Einsatz.
In industriellen Architekturen fungiert Kafka häufig als zentrales Daten-Backbone: Edge-Gateways schreiben ihre Daten in Topics, während Anwendungen wie ERP-Systeme, Instandhaltungstools, Data Lakes oder SCADA-Systeme die relevanten Streams konsumieren. Für die Echtzeitverarbeitung werden häufig ergänzende Frameworks wie Apache Flink oder Spark Streaming eingesetzt, um Daten zu aggregieren, zu filtern oder anzureichern.
Für kleinere oder weniger komplexe Umgebungen wird häufig Apache NiFi eingesetzt. Es ermöglicht die grafische Modellierung von Datenflüssen zwischen Quellen und Zielen, inklusive Fehlerbehandlung, Routing und Verschlüsselung.
Ein oft unterschätzter Punkt ist die Daten-Governance auf Schemaebene. Wenn ein System eine Temperaturmessung empfängt, muss eindeutig sein, dass es sich um eine Temperatur in Grad Celsius handelt und welchem Asset sie zugeordnet ist. Ohne zentrales Metadaten-Register (häufig Schema Registry im Kafka-Ökosystem) werden Datenpipelines schnell zu schwer wartbaren Black Boxes.
Fehlende Metadaten machen Herkunft und Bedeutung der Daten schwer nachvollziehbar. Ohne durchgängige Datenherkunft (Lineage) wird zudem die Fehlersuche komplex. Genau so entsteht das sogenannte „Data Swamp“ – ein Datenbestand, in dem niemand mehr sicher weiß, was er eigentlich enthält.
Die Theorie von geschichteten Architekturen wirkt auf dem Papier klar und elegant. In der industriellen Realität sind Projekte jedoch deutlich widerspenstiger.
In nahezu jeder Fabrik existieren mehrere Technologiegenerationen nebeneinander. In einer einzigen Fertigungshalle können noch Steuerungen aus den 1990er-Jahren im Einsatz sein, die weiterhin zuverlässig laufen, daneben Antriebe aus den 2010er-Jahren und IoT-Sensoren aus jüngster Zeit. Ältere Anlagen unterstützen teilweise nur Modbus RTU und verfügen über keinerlei Ethernet-Anbindung.
Diese Systeme in eine moderne Datenarchitektur zu integrieren erfordert Protokollkonverter, zusätzliche Gateways und nicht selten pragmatische Umwege, die weder ursprünglich geplant noch budgetiert waren.
Wer ist eigentlich für die Daten einer Produktionslinie verantwortlich? Das Instandhaltungsteam, das die Automatisierung betreut? Die IT-Abteilung, die das Netzwerk verwaltet? Oder die Fachbereiche, die die Daten für Qualitäts- und Produktionssteuerung nutzen?
In der Praxis bleibt diese Frage oft ungeklärt. Die Folge: Datenmodelle werden nicht konsistent dokumentiert, Datenqualität wird selten systematisch geprüft, und Projekte entwickeln sich in Form schrittweiser Korrekturen statt einer durchgängigen Architektur.
Die Öffnung von OT-Netzen in Richtung IT erhöht die Angriffsfläche erheblich. Modbus bietet beispielsweise keinerlei integrierte Mechanismen für Authentifizierung oder Verschlüsselung. Ohne saubere Netzwerksegmentierung kann jedes Gerät im Netz theoretisch Befehle an eine SPS senden.
Die NIS-2-Richtlinie zwingt Industrieunternehmen zunehmend dazu, diese Risiken strukturiert zu adressieren und ihre Datenflussarchitekturen nachvollziehbar zu dokumentieren, um Sicherheitsanalysen überhaupt zu ermöglichen.
Eine ausgefeilte Datenpipeline kann keine falsch kalibrierten Sensoren, fehlerhafte Zeitstempel oder unzureichend dokumentierte Variablen kompensieren. Dennoch wird die Datenqualität auf Feldebene in vielen Betrieben nie systematisch überprüft.
Typische Probleme sind schleichende Sensordrift, unerkannte Ausreißer, die historische Daten verfälschen, oder schlecht benannte Modbus-Tags, die eine eindeutige Zuordnung der Messwerte verhindern. Diese Probleme an der Quelle zu beheben ist oft die unsichtbarste, aber zugleich wertvollste Arbeit.
Aus diesen Herausforderungen lassen sich einige Grundprinzipien ableiten, die den Unterschied zwischen erfolgreichen und gescheiterten Projekten ausmachen.
Zuerst kartieren, dann verbinden. Bevor eine einzige Gateway-Komponente installiert wird, müssen alle Anlagen, Protokolle, Datenpunkte und Aktualisierungsfrequenzen erfasst werden. Diese Inventarisierung bildet die Grundlage jeder weiteren Architektur.
Auf offene und standardisierte Protokolle setzen. Bei Neuanschaffungen sollte die Unterstützung von OPC UA zwingend gefordert werden. Für bestehende Systeme ermöglichen Protokollgateways eine schrittweise Integration, ohne komplette Austauschprojekte.
Daten-Governance als eigenständiges Projekt behandeln. Einheitliche Namenskonventionen, strukturierte MQTT-Topics oder OPC-UA-Knoten, ein gepflegtes Metadatenregister sowie klar definierte Einheiten und Wertebereiche sind entscheidend für langfristige Wartbarkeit.
OT- und IT-Netze konsequent segmentieren. Eine industrielle DMZ zwischen Produktions- und Unternehmensnetzwerk ermöglicht kontrollierte Datenflüsse und reduziert Risiken erheblich. Daten werden über definierte Gateways oder gefilterte Kanäle übertragen, ohne direkten Zugriff aus der IT auf die Steuerungsebene.
Klein anfangen, konsequent dokumentieren, dann skalieren. Erfolgreiche Projekte starten meist mit einem klar abgegrenzten Bereich – einer Linie, einer Anlage oder einem Gerätetyp – und einer sauberen Architektur. Von dort aus lässt sich das System deutlich stabiler und kontrollierter erweitern als bei großflächigen Parallelprojekten.
Quellen
IT/OT-Observatorium 2024, NXO & Cisco (135 Befragte); Forrester Research (Anteil ungenutzter Industriedaten); OPC Foundation Dokumentation (OPC UA); Linux-Embedded-Analysen zu Edge-Architekturen und industriellen Datenpipelines (2025).
Copyright © 2026. MOTILDE. All rights reserved.