OPC UA vs. MQTT: Kein Kampf, sondern eine Zweckgemeinschaft
Autor: DerSchneider
Einleitung
Kaum ein Thema wird in der industriellen Kommunikation so leidenschaftlich und zugleich so irreführend diskutiert wie die Frage: „OPC UA oder MQTT – welches Protokoll ist das richtige?“ In Foren, auf Konferenzen und in Verkaufspräsentationen wird dieser Gegensatz oft als ein Entweder-Oder inszeniert, bei dem sich der Anwender für die eine oder die andere Technologie entscheiden müsse. Die Hersteller der einen Fraktion preisen die semantische Tiefe und Sicherheit von OPC UA an, die der anderen das geringe Gewicht und die Skalierbarkeit von MQTT.
Doch diese Fragestellung ist grundlegend falsch. Sie ist, wie ein Branchenkenner treffend formuliert, ein „category error“ – ein Kategoriefehler. OPC UA und MQTT operieren auf völlig unterschiedlichen Ebenen des Kommunikationsstapels und lösen unterschiedliche Probleme. OPC UA ist das Wörterbuch, das den Daten Bedeutung verleiht; MQTT ist der Umschlag, der sie schnell und leicht von A nach B transportiert.
Dieser Artikel räumt mit dem Missverständnis auf, dass es einen „Kampf“ zwischen den beiden Protokollen gäbe. Stattdessen zeigt er, wie OPC UA und MQTT in einer modernen IIoT-Architektur ideal zusammenwirken – als Zweckgemeinschaft, bei der jedes Protokoll das leistet, was es am besten kann.
1. Die Grundlagen: Zwei Welten, zwei Philosophien
A) OPC UA – Die Semantikmaschine
OPC UA (Open Platform Communications Unified Architecture) ist kein reines Transportprotokoll. Es ist ein umfassender Kommunikationsstandard, der von der OPC Foundation entwickelt wurde und für den sicheren, zuverlässigen und plattformunabhängigen Datenaustausch in industriellen Automatisierungssystemen konzipiert ist.
Die Schlüsselkompetenz von OPC UA liegt in seiner Informationsmodellierung: Es unterstützt strukturierte Datentypen, objektorientierte Modelle und komplexe Datenstrukturen. Eine Pumpe ist in OPC UA nicht einfach eine Gleitkommazahl, sondern ein Objekt mit Eigenschaften wie Fördermenge in Liter pro Minute, Betriebszustand, Alarmschwellen und Wartungsintervall.
Hinzu kommen integrierte Sicherheitsmechanismen – Authentifizierung, Autorisierung, Verschlüsselung und Datenintegrität sind fest in der Spezifikation verankert und nicht optional. OPC UA ist damit der einzige Industriestandard, der von Haus aus ein Sicherheitsniveau bietet, das den Anforderungen von IEC 62443 oder der Cyber Resilience Act (CRA) genügt.
OPC UA beherrscht sowohl das klassische Client/Server-Modell als auch das Publish/Subscribe-Modell (PubSub). Mit der Veröffentlichung von Part 14 des Standards im Jahr 2018 wurde PubSub offiziell eingeführt und ermöglicht den Einsatz von OPC UA direkt über das Internet – unter Nutzung von MQTT oder AMQP als Transport.
B) MQTT – Der Minimalist
MQTT (Message Queuing Telemetry Transport) wurde 1999 von Andy Stanford-Clark (IBM) und Arlen Nipper (Cirrus Link) für die Überwachung von Ölpipelines über Satellitenverbindungen entwickelt. Es ist ein leichtgewichtiges Messaging-Protokoll für Netzwerke mit geringer Bandbreite und hoher Latenz.
MQTT tut genau eine Sache: Es bewegt kleine Nachrichten zwischen Geräten über unzuverlässige Netzwerke mit minimalem Aufwand. Der Protokoll-Header beträgt gerade einmal 2 Bytes. Eine Temperaturmessung mit Topic und Payload passt in unter 50 Bytes.
Die Architektur ist denkbar einfach: Publisher senden Nachrichten zu benannten Topics an einen zentralen Broker. Subscriber drücken ihr Interesse an bestimmten Topic-Mustern aus. Der Broker routet die Nachrichten von den Publishern zu den passenden Subscribern. Das ist alles.
Was MQTT nicht bietet: Es hat kein Konzept für Datentypen, keine eingebaute Entdeckung von Geräten oder Diensten, keine Validierung von Nachrichtenstrukturen und kein Verständnis für Beziehungen zwischen Datenpunkten. Topics sind Konventionen, keine Spezifikationen.
2. Der entscheidende Unterschied: Ebene und Zweck
Der Irrglaube, OPC UA und MQTT seien Konkurrenten, entsteht aus einer Verwechslung der Ebenen:
Die Analogie, die in der Industrie zunehmend Verbreitung findet, ist einprägsam: OPC UA ist das Wörterbuch, MQTT der Umschlag. Das Wörterbuch definiert die genaue Bedeutung der Wörter – dass „Temperatur“ spezifisch „Celsius“ und „Int32“ bedeutet. Der Umschlag hingegen transportiert die Nachricht blitzschnell und leicht. Es kümmert sich nicht darum, ob der Inhalt ein Liebesbrief oder eine Erpresserforderung ist – es liefert nur die Nachricht aus.
3. Die Domänen: Wo welches Protokoll seine Stärken ausspielt
A) Die Domäne von OPC UA: Maschine-zu-Maschine und SCADA
OPC UA ist die erste Wahl, wenn der Empfänger der Daten die Bedeutung der Daten verstehen muss – nicht nur sie empfangen.
- SCADA- und MES-Integration: Das übergeordnete System muss in der Lage sein, das Datenmodell zu durchsuchen, Prozesswerte mit Einheiten zu lesen, Methoden auf der SPS aufzurufen und Alarme zu abonnieren.
- Herstellerübergreifende Interoperabilität: Wenn Maschinen verschiedener Hersteller miteinander kommunizieren, benötigen sie ein gemeinsames semantisches Modell. Companion Specifications wie PackML, Euromap 77/83 oder PADIM stellen genau diese standardisierten Modelle bereit.
- Brownfield-Modernisierung: Alte SPSen (Siemens S7, Modbus, EtherNet/IP) werden über eine einzige, standardisierte OPC-UA-Schnittstelle nach außen gebracht.
OPC UA ist das Protokoll für die Ebene der Maschinensteuerung und -koordination.
B) Die Domäne von MQTT: Telemetrie und Cloud
MQTT glänzt dort, wo es um hochfrequente Telemetrie, Bandbreiteneffizienz und die Anbindung an die Cloud geht.
- Sensor-Telemetrie: Tausende von Sensoren, die periodisch oder bei Ereignissen Daten senden – MQTT bewältigt dies mit minimalem Overhead.
- Edge-to-Cloud: Der MQTT-Broker sitzt in der Cloud (AWS IoT Core, Azure IoT Hub, HiveMQ Cloud) und nimmt die ausgehenden Verbindungen der Geräte entgegen.
- Unzuverlässige Netzwerke: Die drei QoS-Stufen (Quality of Service) von MQTT – von „Fire and Forget“ bis „Exactly Once“ – bieten Flexibilität für unterschiedliche Netzwerkbedingungen.
MQTT ist das Protokoll für die Datenübertragung vom Feld in die IT-Welt.
4. Der Sicherheitsaspekt: Der Firewall-Test
Ein entscheidender Unterschied zwischen den Protokollen zeigt sich bei der Netzwerksicherheit – und hier liegt ein klarer Vorteil von MQTT für die Cloud-Anbindung.
Das klassische OPC-UA-Client/Server-Modell erfordert einen Handshake. Um einem Cloud-Server den Zugriff auf die Fabrik zu ermöglichen, muss oft ein Loch in der Firewall geöffnet werden – eingehende Ports werden freigegeben. Dies birgt erhebliche Risiken: Internet-exponierte OPC-UA-Server ohne angemessene Zugriffskontrolle sind eine bekannte Gefahrenquelle.
MQTT löst dieses Problem mit seinem Publish/Subscribe-Modell. Das Gerät in der Fabrik schiebt die Daten von innen nach außen zu einem Broker. Die Verbindung ist outbound-only – keine offenen Ports, keine IT-Albträume.
Die Praxisempfehlung für 2025 lautet daher:
- Outbound only: Alle Cloud-Verbindungen werden von innerhalb der Fabrik initiiert (MQTT)
- TLS 1.3: Verschlüsselung für OPC UA (lokal) und MQTT (Cloud) erzwingen
- Standardports ändern: 4840 für OPC UA, 1883 für MQTT auf öffentlichen Schnittstellen
5. Die Vereinigung: OPC UA PubSub über MQTT
Die eigentliche Pointe der Geschichte ist, dass sich die beiden Protokolle nicht nur ergänzen, sondern offiziell miteinander verbunden sind.
Die OPC Foundation hat mit Part 14 des OPC-UA-Standards (PubSub) einen Mechanismus geschaffen, der es erlaubt, OPC UA direkt über MQTT zu transportieren. PubSub ermöglicht die Nutzung von OPC UA über das Internet unter Beibehaltung der Ende-zu-Ende-Sicherheit und der standardisierten Datenmodellierung.
Konkret bedeutet das: Ein OPC-UA-Server kann seine Daten nicht nur über das klassische TCP, sondern auch als Nachrichten über einen MQTT-Broker veröffentlichen. Die OPC-UA-PubSub-Spezifikation definiert, wie die OPC-UA-Nachrichten in MQTT-Topics abgebildet werden und wie die Sicherheitsmechanismen erhalten bleiben.
Diese Kombination vereint die Stärken beider Welten:
- Die semantische Tiefe und Sicherheit von OPC UA
- Die Skalierbarkeit und Einfachheit von MQTT
6. Die Praxis: Unified Namespace als gemeinsame Bühne
In der modernen Industrie-4.0-Architektur hat sich das Konzept des Unified Namespace (UNS) als zentrale Datenplattform etabliert. Hier verschmelzen die Welten von OPC UA und MQTT auf natürliche Weise.
Ein typisches Szenario:
- Auf der Feldebene kommunizieren SPSen und Maschinen untereinander über OPC UA – mit all seinen semantischen und sicherheitstechnischen Vorteilen.
- Ein Edge-Gateway oder eine UNS-Plattform (wie N3uron) sammelt diese OPC-UA-Daten ein und stellt sie als einheitlichen Namensraum bereit.
- Nach Norden zur Cloud werden die Daten über MQTT (oft mit Sparkplug B als Datenmodell-Erweiterung) an einen Cloud-Broker gesendet.
- Analytische Anwendungen in der Cloud konsumieren die MQTT-Streams und führen ihre Berechnungen durch.
Gateway-Lösungen wie die SDEX Suite oder Cogent DataHub unterstützen heute nahtlos die Konvertierung zwischen OPC UA und MQTT. OPC-UA-Daten von SPSen und MQTT-Daten von Edge-Sensoren landen in derselben Datenbank und sind gemeinsam abfragbar.
7. Ein Vergleich auf einen Blick
Fazit & Ausblick
Die Frage „OPC UA oder MQTT?“ ist falsch gestellt. Beide Protokolle werden in jeder ernsthaften IIoT-Architektur der Zukunft gemeinsam auftreten. Sie sind keine Konkurrenten, sondern Partner mit komplementären Rollen.
Die Zukunft gehört der hybriden Architektur:
- OPC UA bleibt das Rückgrat der Maschinenkommunikation in der Fabrik – mit seiner semantischen Tiefe, seiner eingebauten Sicherheit und seiner Fähigkeit, komplexe Maschinenmodelle abzubilden.
- MQTT wird die Brücke zur Cloud – mit seiner Leichtigkeit, seiner Skalierbarkeit und seiner outbound-only-Sicherheitsarchitektur.
- OPC UA PubSub über MQTT verbindet beide Welten offiziell und ermöglicht Ende-zu-Ende-Sicherheit auch über das Internet.
Für den Ingenieur in der Praxis bedeutet dies: Nicht mehr „entweder-oder“, sondern „sowohl-als-auch“ . Die Kunst besteht darin, die richtige Protokollwahl für die jeweilige Ebene der Architektur zu treffen und die Schnittstellen sauber zu definieren. Wer das beherrscht, hat den Schlüssel zur erfolgreichen digitalen Transformation in der Hand – und muss sich nicht mehr in einem sinnlosen Glaubenskrieg zwischen zwei hervorragenden Technologien verlieren.
Quellen
- i‑flow.io: „OPC UA vs. MQTT (ein Vergleich der wichtigsten Eigenschaften)“
- manubes.de: „MQTT vs. REST vs. OPC UA – Unterschiede und Einsatzgebiete“
- IndustryX.ai: „MQTT vs OPC UA (2025) — The Honest Architecture Guide“
- FlowFuse: „MQTT vs OPC UA: Why This Question Never Has a Straight Answer“
- Sterfive: „OPC UA vs MQTT — when to use what in industrial IoT“
- OPC Foundation / OPConnect: „OPC UA + MQTT = A Popular Combination for IoT Expansion“
- OPC Foundation: „UA Part 14: PubSub – 7.3.4 MQTT“
- ScienceDirect: „OPC UA and MQTT performance analysis within a unified namespace context“ (2025)
- ASME: „MQTT-UNS and OPC UA in RAMI4.0: A Comparative Analysis“ (2026)
Post Comment