OPC UA vs. MQTT ist eine der häufigsten Debatten im Industrial IoT, und meist wird sie falsch geführt. Dieser Vergleich erklärt, wofür jedes Protokoll entworfen wurde, wie sie sich bei Informationsmodellierung, Kommunikationsmuster, Sicherheit und Cloud-Anbindung unterscheiden und warum die häufigste Antwort aus der Praxis lautet: „OPC UA an der Edge, MQTT in die Cloud". Am Ende wissen Sie, welches Protokoll Sie für welche Schicht Ihrer Architektur verwenden.
Zwei Protokolle, zwei verschiedene Aufgaben
OPC UA (Open Platform Communications Unified Architecture) ist ein Framework für industrielle Interoperabilität. Es definiert nicht nur, wie Bytes transportiert werden, sondern auch, wie eine Maschine sich selbst beschreibt: Objekte, Variablen, Methoden, Typen, physikalische Einheiten, Alarme und Historie. Ein Client verbindet sich mit einem Server, durchsucht dessen Adressraum und liest, schreibt, abonniert oder ruft Methoden auf. Es ist als IEC 62541 standardisiert und in viele moderne SPSen (etwa die Siemens S7-1500), CNC-Steuerungen und SCADA-Systeme integriert.
MQTT ist ein schlankes Publish/Subscribe-Messaging-Protokoll. Clients verbinden sich mit einem zentralen Broker, veröffentlichen Nachrichten auf Topics und abonnieren die Topics, die sie interessieren. MQTT sagt bewusst nichts darüber aus, was die Payload bedeutet; es transportiert Bytes effizient und zuverlässig über unzuverlässige Netze. Es ist ein OASIS-Standard, und die Versionen 3.1.1 und 5.0 sind weit verbreitet. Wenn das Broker-Konzept neu für Sie ist, beginnen Sie mit was ein MQTT-Broker macht.
Der Vergleich ähnelt also ein wenig dem zwischen einem Datenbankschema und einem Nachrichtenbus. Beide bewegen Daten, aber der Nutzen, den jeder bringt, ist ein anderer.
OPC UA vs. MQTT im Überblick
| Dimension | OPC UA (Client/Server) | MQTT |
|---|---|---|
| Grundmuster | Client/Server-Sessions; Subscriptions pro Session | Publish/Subscribe über einen Broker |
| Informationsmodell | Reichhaltiger, typisierter, durchsuchbarer Adressraum mit Metadaten | Nicht eingebaut; Topics und Payloads definieren Sie selbst oder eine Spezifikation wie Sparkplug B |
| Discovery | Server durchsuchen, um Nodes und Typen zu finden | Mit Wildcards abonnieren; keine eingebaute Schema-Discovery |
| Kopplung | Jeder Konsument verbindet sich mit jedem Server | Produzenten und Konsumenten kennen nur den Broker |
| Netzwerkrichtung | Client muss den Server erreichen, typischerweise eingehend ins OT-Netz | Alle Clients verbinden sich ausgehend mit dem Broker |
| Ressourcenbedarf | Schwererer Stack, größere Nachrichten, Session-Zustand | Sehr kleine Client-Bibliotheken, minimaler Header von 2 Byte |
| Sicherheit | Anwendungszertifikate, Signieren und Verschlüsseln, User Tokens | TLS auf der Transportebene, Benutzername/Passwort oder Client-Zertifikate, Autorisierung im Broker |
| Schreiben und Methodenaufrufe | Nativ: Variablen schreiben, Methoden aufrufen | Über Command-Topics möglich, aber nur per Konvention |
| Reichweite in Cloud und IT | Begrenzte native Unterstützung in Cloud-Plattformen | Von praktisch jeder IoT-Plattform und Programmiersprache unterstützt |
| Typisches Einsatzfeld | SPSen, CNCs, SCADA, MES im Werksnetz | Edge-Gateways, Cloud-Anwendungen, Dashboards, Mobilgeräte, ressourcenarme Geräte |
OPC UA hat außerdem eine PubSub-Erweiterung (Part 14), die MQTT als Transport nutzen kann. Das verwischt die Grenze erheblich und wird in unserem Artikel zu OPC UA PubSub über MQTT behandelt. Dieser Vergleich konzentriert sich auf klassisches Client/Server-OPC-UA, weil die meisten installierten Anlagen heute genau das bereitstellen.
Informationsmodellierung: der große Vorteil von OPC UA
Die stärkste Eigenschaft von OPC UA ist die Semantik. Ein Server kann sagen: „Das ist eine Variable namens SpindleTemperature, sie ist vom Typ Double, ihre Einheit ist Grad Celsius, ihr Bereich ist 0 bis 120, und sie gehört zu einem Objekt vom Typ MachineToolType." Companion Specifications gehen noch weiter und definieren Standardmodelle für ganze Maschinenklassen, sodass Spritzgießmaschinen zweier Hersteller für einen Client gleich aussehen können.
MQTT bringt nichts davon von Haus aus mit. Eine Payload 47.3 auf einem Topic ist nur eine Folge von Bytes. Teams gleichen das auf drei Arten aus:
- Topic-Konventionen wie eine ISA-95-Hierarchie, sodass der Pfad selbst Kontext trägt. Aus Enterprise → Site → Area → Line → Cell wird so ein Topic wie
acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Unser Leitfaden zu ISA-95-MQTT-Topics zeigt einen praxistauglichen Aufbau. - Selbstbeschreibendes JSON mit Wert, Einheit, Qualität und Zeitstempel in jeder Nachricht.
- Sparkplug B, das auf MQTT eine definierte Payload, Birth- und Death-Zertifikate sowie Metrik-Metadaten ergänzt.
Ist reichhaltige Modellierung für einen Anwendungsfall unverzichtbar, etwa wenn ein MES Rezepturen liest und Methoden an einer Maschine aufruft, ist OPC UA die natürliche Wahl.
Kommunikationsmuster: Sessions vs. Entkopplung
Bei klassischem OPC UA öffnet jeder Konsument eine Session mit jedem Server, den er braucht. Zehn Anwendungen, die von fünfzig Maschinen lesen, können Hunderte Sessions bedeuten, die jeweils Speicher auf SPSen belegen, die dafür nie ausgelegt wurden. Ein neuer Konsument bedeutet, Firewall-Regeln und Serverkonfiguration anzufassen.
Bei MQTT veröffentlicht jede Maschine oder jedes Gateway einmal an den Broker, und beliebig viele Konsumenten abonnieren. Ein neues Dashboard oder ein neuer Analytics-Job berührt nichts in der Fertigung. Diese Entkopplung ist der Hauptgrund, warum MQTT zum Rückgrat des Unified Namespace (UNS) wurde: Der Broker hält den aktuellen Zustand von Werk, Linien und Maschinen in einer ISA-95-strukturierten Topic-Hierarchie, und MES, ERP, Historian und Analytics lesen alle aus derselben Quelle. Wie Sparkplug B dabei hilft, erklärt unser Artikel zu Sparkplug B und Unified Namespace.
Die Kehrseite: MQTT stellt den Broker in den kritischen Pfad. Fällt er aus, fließt nichts mehr, daher werden Verfügbarkeit, Monitoring und Kapazität des Brokers zu betrieblichen Themen. Das ist ein Grund, warum viele Teams einen verwalteten MQTT-Broker wählen, statt Broker selbst zu betreiben.
Sicherheitsmodelle
Beide Protokolle lassen sich gut absichern, und beide lassen sich unsicher betreiben.
OPC-UA-Sicherheit setzt auf Anwendungsebene an: Jeder Client und jeder Server hat ein X.509-Anwendungsinstanzzertifikat, und die Session kann signiert oder signiert und verschlüsselt werden. Die Benutzerauthentifizierung kommt darüber hinzu. Der häufige betriebliche Schmerzpunkt ist das Management des Zertifikatsvertrauens über Dutzende Geräte hinweg.
MQTT-Sicherheit liegt vor allem auf Transport- und Broker-Ebene: TLS für die Verschlüsselung, Zugangsdaten oder Client-Zertifikate für die Authentifizierung und Regeln im Broker dafür, was jeder Client darf. Der architektonische Vorteil ist die Richtung. Weil sich jeder MQTT-Client ausgehend mit dem Broker verbindet, öffnen Sie keine eingehenden Ports ins OT-Netz. Unser Artikel zu Best Practices für MQTT-Sicherheit listet das Wesentliche auf.
Cloud-Anbindung
Hier ist der Vergleich am einseitigsten. Cloud-Dienste, Web-Apps, Mobile-Apps und Datenwerkzeuge sprechen fast durchweg MQTT, HTTP oder beides. Sehr wenige sprechen OPC UA Client/Server nativ, und einen OPC-UA-Server direkt ins Internet zu stellen, ist eine schlechte Idee. Der kleine Ressourcenbedarf von MQTT, seine Toleranz gegenüber instabilen Verbindungen, Keep-alives und Last-Will-Nachrichten wurden genau für diese Art entfernter, zeitweiliger Verbindungen entworfen.
Das Muster der meisten Werke: OPC UA an der Edge, MQTT in die Cloud
In der Praxis lautet die Frage selten „OPC UA oder MQTT", sondern „wohin gehört welches". Das Muster, das man immer wieder sieht:
Level 0-2 Machines and PLCs -> OPC UA servers (native or via drivers)
Level 2-3 Edge gateway -> OPC UA client: subscribes to tags
-> maps nodes to a topic hierarchy, adds units and quality
Level 3-4 MQTT broker -> single hub (Unified Namespace)
Level 4+ Consumers -> dashboards, historian, MES, analytics, cloud apps
Das Gateway bewahrt die Semantik von OPC UA dort, wo die Maschinen sind, und übersetzt sie in eine Topic-Struktur und ein Payload-Format, das alle anderen nutzen können. Unser Tutorial zum Bau eines OPC UA MQTT Gateways führt durch eine funktionierende Python-Implementierung, die per TLS an einen Broker veröffentlicht.
Wie die MQTT-Seite dieses Musters aussieht, sehen Sie in Sekunden. Dieser Befehl veröffentlicht einen aus OPC UA stammenden Wert samt Kontext auf dem öffentlichen MQTT-Broker (nur für Tests und Prototypen, nicht für echte Produktionsdaten):
mosquitto_pub -h broker.connectmq.com -p 1883 -i opcua-vs-mqtt-5d2e \
-t "connectmq/demo/5d2e/plant1/line1/cnc1/spindle_temp" -r -q 1 \
-m '{"value":47.3,"unit":"degC","quality":"Good","source":"ns=2;s=Line1.CNC1.SpindleTemp"}'
Jeder Subscriber auf connectmq/demo/5d2e/# erhält ihn nun, ohne irgendetwas über OPC UA zu wissen.
Checkliste für die Entscheidung
Entscheiden Sie anhand dieser Liste pro Anwendungsfall, nicht pro Werk:
- Muss ein Client eine Maschine durchsuchen, Sollwerte schreiben oder Methoden aufrufen? Verwenden Sie OPC UA Client/Server.
- Brauchen viele Konsumenten dieselben Daten, einige außerhalb des Werksnetzes? Veröffentlichen Sie sie per MQTT.
- Sind die Geräte ressourcenarm (Mikrocontroller, batteriebetriebene Sensoren) oder per Mobilfunk angebunden? MQTT.
- Brauchen Sie herstellerneutrale Maschinenmodelle mit Standardsemantik? OPC UA und seine Companion Specifications; übertragen Sie die Semantik in die MQTT-Payloads, wenn Sie eine Brücke bauen.
- Wollen Sie einen UNS aufbauen? MQTT als Knotenpunkt mit ISA-95-Topic-Struktur, gespeist von OPC UA an der Edge.
- Können Sie keine eingehenden Firewall-Ports öffnen? Die rein ausgehenden Verbindungen von MQTT passen.
- Brauchen Sie deterministische Steuerung mit niedriger Latenz zwischen Steuerungen? Keines der beiden ist das richtige Werkzeug für harte Echtzeitsteuerung; verwenden Sie den dafür entworfenen Feldbus.
Wo ConnectMQ ins Bild passt
ConnectMQ ist die MQTT-Seite dieser Architektur: ein verwalteter MQTT-Broker mit Unterstützung für MQTT 3.1.1 und 5.0 über TCP, TLS und WebSockets. Es spricht selbst kein OPC UA, und das ist so gewollt; Ihr Edge-Gateway übernimmt OPC UA und veröffentlicht per MQTT an ConnectMQ. ConnectMQ erkennt ISA-95- und Unified-Namespace-Topics, zeigt sie in einem Live-Topic-Explorer und einer nach ISA-95-Ebenen gegliederten Geräteansicht und kann Sparkplug-B-Payloads dekodieren, falls Ihr Gateway dieses Format nutzt. Einen Überblick über den gesamten Stack bietet unser Leitfaden zu Industrial IoT mit MQTT.
Starten Sie mit ConnectMQ
Testen Sie das Edge-to-Cloud-Muster, ohne einen Broker zu installieren. Registrieren Sie sich unter app.connectmq.com im kostenlosen Serverless-Plan (ohne Kreditkarte), legen Sie einen Broker an und richten Sie Ihr OPC-UA-Gateway mit den generierten Zugangsdaten darauf aus. Noch am selben Nachmittag fließen Ihre Werksdaten zu einem privaten Cloud-MQTT-Broker.
Häufig gestellte Fragen
Ersetzt MQTT OPC UA?
Nein. MQTT ersetzt Punkt-zu-Punkt-Integrationen oberhalb der Fertigungsebene, während OPC UA der Standardweg bleibt, über den viele Maschinen strukturierte Daten bereitstellen. Die meisten Architekturen nutzen beide.
Ist OPC UA oder MQTT sicherer?
Beide sind sicher, wenn sie korrekt konfiguriert sind. OPC UA sichert Sessions mit Anwendungszertifikaten ab; MQTT setzt auf TLS und Authentifizierung im Broker, mit dem Vorteil, dass Clients nur ausgehende Verbindungen aufbauen.
Kann OPC UA MQTT direkt nutzen?
Ja. OPC UA Part 14 PubSub definiert MQTT als Transport mit JSON- oder binärer UADP-Kodierung, sodass OPC-UA-Publisher Nachrichten über einen standardmäßigen MQTT-Broker senden können.
Was ist besser für einen Unified Namespace, OPC UA oder MQTT?
MQTT ist dank der Entkopplung durch Publish/Subscribe der übliche Knotenpunkt für einen Unified Namespace. OPC-UA-Server speisen diesen Namespace typischerweise über Edge-Gateways.
