Wenn Sie sich mit dem industriellen IoT beschäftigen, haben Sie die gleiche Debatte immer wieder gehört. Sollten wir MQTT oder OPC UA verwenden? Die Frage wird als Wettbewerb formuliert, als ob ein Protokoll gewinnen und das andere verlieren müsste. In der Praxis ist diese Formulierung falsch. MQTT und OPC UA wurden entwickelt, um grundsätzlich unterschiedliche Probleme zu lösen, und die meisten Produktions-IIoT-Architekturen verwenden letztendlich beide – oft gleichzeitig auf demselben Gateway.
In diesem Artikel erfahren Sie, was die einzelnen Protokolle eigentlich gut können, wo sie versagen und wie Sie entscheiden, welches auf welche Seite Ihrer Datenpipeline gehört.
TL;DR
- MQTT verschiebt Bytes. Es ist ein leichter Transport für Publish/Subscribe-Messaging, nutzlastunabhängig und ideal für eingeschränkte Netzwerke und Cloud-Telemetrie.
- OPC UA verändert die Bedeutung. Es handelt sich um ein vollständiges Informationsmodellierungs-Framework mit integrierter Sicherheit, semantischen Daten und Auffindbarkeit – konzipiert für die Interoperabilität in der Fertigungshalle.
- Sie schließen sich nicht gegenseitig aus. OPC UA PubSub (Teil 14) kann über MQTT ausgeführt werden, sodass Sie zusätzlich zu leichtgewichtigem Pub/Sub semantische Daten erhalten.
- Ein typisches IIoT-Gateway spricht OPC UA (oder Modbus, EtherNet/IP, S7) auf der Südseite und veröffentlicht es dann an MQTT-Broker auf der Nordseite.
Zwei unterschiedliche Ursprünge, zwei unterschiedliche Denkweisen
MQTT wurde 1999 bei IBM geboren und von Andy Stanford-Clark und Arlen Nipper für die Überwachung von Ölpipelines über Satellitenverbindungen entwickelt. Die Einschränkungen prägten alles daran: Nehmen wir an, das Netzwerk sei langsam, teuer und unzuverlässig; Gehen Sie davon aus, dass das Gerät klein ist. Halten Sie den Protokoll-Header mikroskopisch klein; Lassen Sie die Anwendung entscheiden, was in die Nutzlast eingefügt werden soll. Zwei Jahrzehnte später wurde MQTT 3.1.1 zum ISO-Standard (ISO/IEC 20922), und MQTT 5 fügte Funktionen hinzu, die moderne Cloud-Architekturen erwarten – Benutzereigenschaften, Nachrichtenablauf, gemeinsame Abonnements, Ursachencodes.
OPC UA entstand aus einer anderen Welt. Die OPC Foundation veröffentlichte 2008 die erste Spezifikation als Nachfolger von OPC Classic (OLE for Process Control), das die Branche an Microsoft DCOM gebunden hatte. Der Auftrag bestand darin, diese Abhängigkeit zu durchbrechen und gleichzeitig ein schwierigeres Problem zu lösen: Wie bringt man eine Siemens-SPS, einen Beckhoff-Motion-Controller, einen B&R-Servoantrieb und ein Rockwell-DCS dazu, sich semantisch zu verstehen und nicht nur Rohbytes auszutauschen? Die Antwort von OPC UA war ein Informationsmodell – ein selbstbeschreibender Adressraum, in dem Daten Typen, Beziehungen und Bedeutung haben.
Diese Entstehungsgeschichten erklären fast jede Designentscheidung, die folgt.
Architektur
MQTT ist Broker-zentriert und entkoppelt. Herausgeber senden Nachrichten an Themen. Abonnenten melden Interesse an Themen. Ein zentraler Broker fächert den Verkehr auf. Herausgeber und Abonnenten erfahren nie direkt voneinander. Der Broker kann eine winzige eingebettete Mosquitto-Instanz oder eine geclusterte HiveMQ-Bereitstellung sein, die Millionen von Clients verwaltet – das Protokoll spielt keine Rolle.
OPC UA war ursprünglich Client-Server. Ein Client öffnet eine Sitzung mit einem Server und gibt dann Dienste aus: „Browse“, um den Adressraum zu erkunden, „Read“ und „Write“, um auf Knotenwerte zuzugreifen, „CreateSubscription“, um über Änderungen benachrichtigt zu werden. Der Server ist zustandsbehaftet und autorisierend. Dies funktionierte gut in einem LAN, ließ sich jedoch nicht auf Fanout im Cloud-Stil skalieren.
OPC UA Teil 14 fügte 2018 PubSub hinzu und unterstützt sowohl Broker-basierte Transporte (MQTT, AMQP) als auch Broker-lose Transporte (UDP-Multicast). Damit erkannte die Stiftung an, dass sich die Welt vom reinen Client-Server-System entfernt hatte.
Protocol selection by design axis
bar chartDatenmodelle
Hier weichen die beiden Protokolle am stärksten voneinander ab.
MQTT ist nutzlastunabhängig. Ein Nachrichtentext kann JSON, Protobuf, CBOR, Rohbinärdatei, JPEG oder einfacher Text sein. Das Protokoll trägt es, interpretiert es aber nicht. Ihre Themenhierarchie („Fabrik/Linie-3/Ofen/Temperatur“) ist eine Namenskonvention, die Sie selbst erfinden und durchsetzen. Wenn ein Abonnent wissen muss, dass „Temperatur“ in Grad Celsius angegeben wird und zwischen 0 und 400 liegt, befindet sich dieses Wissen außerhalb des Protokolls – in der Dokumentation, in einem Vertrag, in einer Schema-Registrierung.
OPC UA ist stark strukturiert. Jeder Knoten im Adressraum verfügt über eine „NodeId“, einen „BrowseName“, einen „DataType“, einen „Value“ und Verweise auf andere Knoten. Darüber liegende Begleitspezifikationen – PLCopen für die Steuerlogik, Auto-ID für RFID-Lesegeräte, MachineTool, Pump, Robotics, Weihenstephan für Brauereien – definieren, wie eine „Pumpe“ oder ein „MachineTool“ in OPC UA-Begriffen aussieht. Ein Client, der Ihr Gerät noch nie gesehen hat, kann ohne vorherige Zustimmung eine Verbindung herstellen, den Adressraum durchsuchen, herausfinden, was verfügbar ist, und die Semantik jedes Werts verstehen.
Diese Fähigkeit – Connect-and-Discover mit vollständiger Semantik – ist die Killerfunktion von OPC UA. Dadurch wird es auch schwerer.
Sicherheit
MQTT nutzt TLS für die Transportverschlüsselung, Benutzername/Passwort oder Client-Zertifikate für die Authentifizierung und ACLs auf Broker-Ebene für die Autorisierung. Das Sicherheitsmodell lebt beim Broker. Verschiedene Broker implementieren die Autorisierung unterschiedlich und es gibt keine Standardmethode, um differenzierte Berechtigungen im Protokoll selbst auszudrücken.
OPC UA verfügt über kryptografische Sicherheit, die in die Nachrichtenschicht integriert ist. X.509-Zertifikate für Client und Server, konfigurierbare Sicherheitsrichtlinien („Basic256Sha256“, „Aes256_Sha256_RsaPss“), Signierung und Verschlüsselung pro Nachricht, von der Anwendungsauthentifizierung getrennte Benutzerauthentifizierung und rollenbasierte Zugriffskontrolle, die in Teil 18 definiert ist. Für Umgebungen, die die Konformität mit IEC 62443 oder NERC CIP nachweisen müssen, bietet Ihnen OPC UA Grundelemente, die direkt dem zugeordnet werden Standards.
Dies ist eines der stärksten Argumente für OPC UA im Fertigungsbereich: Das Sicherheitsmodell wurde vom ersten Tag an für industrielle Steuerungssysteme konzipiert.
Bandbreite und Overhead
Das Mindestpaket von MQTT besteht aus 2 Byte festem Header plus einem variablen Header und einer Nutzlast. Eine „VERÖFFENTLICHUNG“ eines 4-Byte-Floats zu einem kurzen Thema erfolgt in weniger als 20 Bytes auf der Leitung. Mit QoS 0 (Fire-and-Forget), 1 (mindestens einmal) und 2 (exakt einmal) können Sie Zuverlässigkeit gegen Bandbreite eintauschen.
OPC UA Binary ist ausführlicher. Eine einfache Benachrichtigung über überwachte Elemente kann 50 bis 100 Byte umfassen. Sitzungen, Abonnements und Sicherheitstokens erhöhen den Mehraufwand für die Zustandsverwaltung. Das Protokoll wurde für den LAN-Durchsatz und nicht für die Mobilfunkbandbreite entwickelt. OPC UA über HTTPS/SOAP (die alte XML-Bindung) war wirklich schwer und wird heute nur noch selten verwendet.
OPC UA PubSub über MQTT oder UDP reduziert den Overhead erheblich, insbesondere bei der JSON- oder binären UADP-Kodierung. Für Greenfield-Designs, die sowohl semantische Struktur als auch Bandbreiteneffizienz erfordern, ist diese Kombination zunehmend die richtige Antwort.
Auffindbarkeit
Schließen Sie einen MQTT-Client an einen Broker an, den Sie noch nie gesehen haben. Was können Sie tun? Sie können „#“ abonnieren (alles mit Platzhalterzeichen versehen) und beobachten, wie der Datenverkehr vorbeifließt, und dann versuchen, die Themenhierarchie und das Payload-Format zurückzuentwickeln. Das ist Ihre einzige Möglichkeit ohne externe Dokumentation.
Schließen Sie einen OPC UA-Client an einen Server an, den Sie noch nie gesehen haben. Sie können den gesamten Adressraum durchsuchen, Datentypen untersuchen, historische Werte lesen, sehen, welche Methoden aufrufbar sind, und feststellen, ob der Server eine bekannte Begleitspezifikation implementiert. Das Protokoll ist grundsätzlich introspizierbar.
Bei Systemen, die sich häufig weiterentwickeln – bei denen Maschinen hinzugefügt, stillgelegt oder neu konfiguriert werden – ist dies wichtig. OPC UA-Clients passen sich automatisch an. MQTT-Kunden benötigen eine Out-of-Band-Aktualisierung ihrer Verträge.
Wann sollte MQTT verwendet werden?
MQTT ist die richtige Wahl, wenn:
- Sie senden Telemetriedaten von Edge-Geräten an die Cloud, insbesondere über Mobilfunk, Satellit oder andere Verbindungen mit eingeschränkter Bandbreite.
- Sie haben viele Herausgeber und viele Abonnenten und benötigen eine lose Kopplung zwischen ihnen.
- Sie integrieren Hyperscaler-IoT-Plattformen (AWS IoT Core, Azure IoT Hub, Google Cloud IoT, HiveMQ Cloud) – alle sprechen nativ MQTT.
- Sie steuern das Payload-Format durchgängig und benötigen keine herstellerübergreifende semantische Interoperabilität.
- Sie benötigen einen kleinen Client-Footprint auf ressourcenbeschränkten Mikrocontrollern.
- Sie verbinden OT-Daten mit IT-Systemen (Kafka, Zeitreihendatenbanken, Business-Intelligence-Tools).
Wann sollte OPC UA verwendet werden?
OPC UA ist die richtige Wahl, wenn:
- Sie lesen Daten von SPSen und Motion Controllern in der Fertigungshalle. Die meisten großen Anbieter – Siemens (S7-1500), Beckhoff (TwinCAT), B&R (Automation Studio), Rockwell, ABB – liefern OPC UA-Server in ihren Steuerungen.
- Sie benötigen semantische Interoperabilität zwischen Geräten verschiedener Anbieter, ohne für jeden einzelnen benutzerdefinierten Adapter schreiben zu müssen.
- Sie arbeiten in einem regulierten Umfeld (Pharma, Automobil, Luft- und Raumfahrt), in dem Datenherkunft und -sicherheit wichtig sind.
- Ihre Datenstruktur ändert sich im Laufe der Zeit und Clients müssen sich ohne Neukompilierung anpassen.
- Sie implementieren eine bekannte Begleitspezifikation (Weihenstephan für Brauereien, Euromap für Kunststoffmaschinen, Umati für Werkzeugmaschinen).
- Sie benötigen integrierte Unterstützung für historischen Zugriff, Alarme und Bedingungen sowie Methoden (aufrufbare Funktionen).
Das Hybridmuster: OPC UA im Süden, MQTT im Norden
Die meisten modernen IIoT-Gateways – einschließlich des Modibus MB213 – implementieren im Wesentlichen eine Übersetzungsschicht. Auf der Südseite (zum Feld hin) spricht das Gateway die Protokolle, die Feldgeräte sprechen: Modbus RTU und TCP, OPC UA Client zu SPSen, EtherNet/IP, Siemens S7, BACnet für die Gebäudeautomation. Auf der Nordseite (in Richtung Cloud oder Unternehmen) veröffentlicht es an MQTT-Broker, häufig mit TLS und Client-Zertifikaten, wobei häufig Sparkplug B für die Nutzlaststruktur verwendet wird.
Dieses Muster funktioniert, weil die Anforderungen auf jeder Seite unterschiedlich sind. Der Fertigungsbereich benötigt Determinismus, Auffindbarkeit und standardisierte Semantik – OPC UA-Territorium. Der Weg in die Cloud erfordert Bandbreiteneffizienz, lose Kopplung und breite Ökosystemunterstützung – MQTT-Territorium. Das Gateway ist der Ort, an dem die Übersetzung stattfindet.
Zündkerze B: MQTT mit Semantik
Die größte Schwäche von Vanilla MQTT ist die fehlende Nutzlaststruktur. Sparkplug B, eine von Cirrus Link entwickelte Eclipse Foundation-Spezifikation, behebt dieses Problem. Es definiert:
Sparkplug B entspricht nicht der semantischen Tiefe von OPC UA – es gibt keine Begleitspezifikationen, keine Methoden, kein Alarm- und Zustandsmodell. Aber es ist wesentlich leichter als OPC UA und für viele Cloud-gebundene Telemetrie-Anwendungsfälle ist es der ideale Ort.
- Ein standardisierter Themen-Namespace (spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id})
- Geburts- und Sterbeurkunden, damit Abonnenten wissen, welche Kennzahlen ein Verlag anbietet und wann dieser offline geht
- Stark typisierte Metrikdefinitionen mit technischen Einheiten, Skalierung und historischem Zustand
- Sequenznummerierung zur Erkennung von Nachrichtenverlusten
OPC UA PubSub über MQTT
Wenn Sie den semantischen Reichtum von OPC UA, aber die Transporteffizienz von MQTT wünschen, ist OPC UA PubSub über MQTT (Teil 14) zunehmend das empfohlene Muster für Greenfield-Designs. Der Herausgeber serialisiert OPC UA-Nachrichten mithilfe der UADP-Binärkodierung oder JSON-Kodierung und veröffentlicht sie in MQTT-Themen. Abonnenten erhalten vollständig typisierte OPC UA-Daten ohne den Aufwand für den Sitzungsaufbau.
Der Nachteil: Der Reifegrad der Tools ist geringer als bei Vanilla MQTT oder OPC UA Client-Server. Noch beherrscht nicht jeder Broker, nicht jede Cloud-Plattform und nicht jedes SCADA-System OPC UA PubSub ordnungsgemäß. Erwarten Sie, dass sich dies in den nächsten zwei bis drei Jahren schnell verbessern wird.
Entscheidungsrahmen
Stellen Sie im Zweifelsfall drei Fragen:
Wo bleiben die Daten und wohin müssen sie gehen? Von Werk zu Werk: OPC UA. Werksebene bis Cloud: MQTT (oder OPC UA PubSub über MQTT). Cloud zu Cloud: MQTT.
Wer kontrolliert das Schema? Wenn Sie sowohl den Herausgeber als auch den Abonnenten kontrollieren, funktioniert MQTT plus ein dokumentiertes Nutzlastformat. Wenn Sie herstellerübergreifende Interoperabilität ohne bilaterale Vereinbarungen benötigen, bietet sich OPC UA an.
Wie hoch ist das Bandbreitenbudget? Mobilfunk, LPWAN oder Satellit: tendieren Sie zu MQTT. Kabelgebundenes LAN ohne Einschränkungen: OPC UA ist in Ordnung.
| Sorge | MQTT | OPC UA |
|---|---|---|
| Nutzlastgröße | Minimal | Höher |
| Integrierte Semantik | Nein | Ja |
| Auffindbarkeit | Nein | Ja |
| Cloud-Ökosystem | Ausgezeichnet | Begrenzt |
| Einführung im Fertigungsbereich | Wachsend | Dominant |
| Sicherheitsmodell | Transport (TLS) | Nachricht + Transport |
| Companion-Spezifikationen | Nein (Zündkerze B am nächsten) | Viele |
| Beste Passform | Telemetrie, Cloud-Bridging | Interoperabilität, Kontrollsysteme |
Schlussgedanke
Die ehrliche Antwort auf „MQTT oder OPC UA?“ ist fast immer „beide, an verschiedenen Orten“. MQTT ist das richtige Werkzeug, um Bytes effizient über Netzwerke zu verschieben. OPC UA ist das richtige Werkzeug, um Bedeutungen anbieterübergreifend zu verschieben. Eine gut konzipierte IIoT-Architektur nutzt jedes einzelne Element dort, wo seine Stärken mit dem Problem vor ihm übereinstimmen.
Genau aus diesem Grund gibt es industrielle Gateways – um die Grenze zwischen diesen beiden Welten sauber, sicher und sichtbar zu machen.
Modibus MB213 unterstützt standardmäßig MQTT (mit TLS, Sparkplug B und konfigurierbarem QoS) und OPC UA (Client- und Serverrollen) sowie Modbus RTU/TCP und andere Industrieprotokolle. Um eine bestimmte Architektur zu besprechen, [kontaktieren Sie uns](https://modibus.com).