OPC UA vs. MQTT — wann welches Protokoll in der industriellen IoT

Wenn Sie 2026 eine industrielle IoT-Architektur entwerfen, haben Sie sich sicher schon gefragt: Soll ich OPC UA oder MQTT verwenden? Im Internet finden Sie Stammtisch-Antworten — OPC-UA-Leute sagen „OPC UA", MQTT-Leute sagen „MQTT." Keine der beiden Antworten hilft weiter.

Hier ist die echte Antwort, von einem Engineering-Team, das beides in der Produktion ausgeliefert hat: Sie lösen unterschiedliche Probleme, und die meisten ernsthaften Architekturen verwenden beide.

Der Unterschied in einem Satz

OPC UA gibt Ihren Daten Struktur und Bedeutung. MQTT transportiert Bytes von A nach B.

Das ist alles. OPC UA ist ein Informationsmodell plus Transport. MQTT ist nur Transport. Alles Weitere ergibt sich aus dieser Unterscheidung.

Wo jedes Protokoll seine Stärken hat

OPC UA: reichhaltige Datensemantik

OPC UA definiert ein Typsystem für Industriedaten — Datentypen, Beziehungen, Einheiten, Bereiche, Zugriffsrechte. Eine Pumpe ist nicht einfach eine Gleitkommazahl; sie ist eine Pumpe mit Durchflussrate in Liter pro Minute, Betriebszustand, Alarmschwelle und Wartungsplan. Diese semantische Reichhaltigkeit macht OPC UA herstellerübergreifend interoperabel — ohne individuelles Mapping.

MQTT: leichtgewichtiges Publish-Subscribe

MQTT wurde für ressourcenbeschränkte Geräte und unzuverlässige Netzwerke entwickelt. Ein minimaler Client, ein einfacher Topic-String, QoS-Stufen und ein Broker dazwischen. Hervorragend geeignet, um Telemetriedaten von Sensoren an eine Cloud-Plattform zu senden — mit minimalem Overhead. Aber MQTT-Topics sind nur Zeichenketten — das Protokoll sagt nichts über die Bedeutung der Daten aus.

OPC UA: eingebautes Sicherheitsmodell

OPC UA umfasst X.509-zertifikatbasierte Authentifizierung, Verschlüsselung, Signierung und rollenbasierte Zugriffskontrolle als Teil der Spezifikation. Sicherheit ist kein Opt-in — sie ist der Standard. Das ist entscheidend, wenn Ihr System IEC 62443 oder den Cyber Resilience Act (CRA) einhalten muss.

MQTT: Broker-Einfachheit

Ein MQTT-Broker ist trivial zu deployen und zu betreiben. Mosquitto läuft auf einem Raspberry Pi. Cloud-Anbieter (AWS IoT Core, Azure IoT Hub, HiveMQ Cloud) bieten verwaltete Broker mit Millionen von Verbindungen. Die betriebliche Einfachheit ist für reine Telemetrie-Anwendungsfälle unerreicht.

Die Vergleichstabelle

Wann OPC UA verwenden

Verwenden Sie OPC UA, wenn der Konsument die Daten verstehen muss, nicht nur empfangen.

SCADA- und MES-Integration. Ihr Leitsystem muss das Datenmodell durchsuchen, Prozesswerte mit Ingenieurseinheiten lesen, Methoden auf der SPS aufrufen und Alarme abonnieren. Das ist das Heimspiel von OPC UA.

Herstellerneutrale Interoperabilität. Sie verbinden Maschinen verschiedener Hersteller und brauchen ein gemeinsames semantisches Modell. Companion Specifications wie PackML, Euromap 77/83 und PADIM liefern branchenstandard-konforme Modelle.

Brownfield-Modernisierung. Sie wollen bestehende Steuerungen (Siemens S7, Modbus, EtherNet/IP) über eine einzige, standardisierte Schnittstelle zugänglich machen, ohne Firmware umzuschreiben.

Compliance. IEC 62443, NIS2 oder der CRA verlangen dokumentierte Sicherheit und Rückverfolgbarkeit. Das eingebaute Sicherheitsmodell von OPC UA liefert das nativ.

Wann MQTT verwenden

Verwenden Sie MQTT, wenn Sie leichtgewichtigen, skalierbaren Datentransport brauchen und der Konsument bereits weiß, was die Daten bedeuten.

Sensor-to-Cloud-Telemetrie. Tausende Sensoren, die kleine Payloads an eine Cloud-Plattform für Speicherung und Analyse senden.

Ressourcenbeschränkte Geräte. Mikrocontroller und Low-Power-Geräte, bei denen der OPC-UA-Stack-Overhead zu hoch ist.

Eventgesteuerte Microservices. Entkoppelte Dienste, die über einen Message Broker kommunizieren.

Mobile und Web-Dashboards. MQTT über WebSockets ist in JavaScript-/Browser-Umgebungen gut unterstützt.

Wann beides verwenden: OPC UA PubSub über MQTT

Das ist das Architekturmuster, auf das die meisten Produktionsarchitekturen 2026 konvergieren. OPC UA PubSub ermöglicht es, OPC-UA-Daten — mit voller Semantik, Typen, Einheiten und Struktur — über einen MQTT-Broker als Transportschicht zu publizieren.

Am Edge verbindet sich ein OPC-UA-Server mit SPSen und Sensoren, stellt einen strukturierten Adressraum bereit und bedient lokale SCADA- und Engineering-Tools über das Standard-Client/Server-Modell. Derselbe Edge-Server publiziert dann ausgewählte Daten als OPC-UA-PubSub-Nachrichten an einen MQTT-Broker — unter Beibehaltung des Datenmodells bei gleichzeitiger Nutzung der Broker-Skalierbarkeit und Cloud-Integration.

Dieses „Best of Both Worlds"-Muster bietet Ihnen:

• Semantische Daten auf jeder Ebene — Konsumenten in der Cloud erhalten typisierte, strukturierte OPC-UA-Daten, keine opaken JSON-Blobs.
• Broker-Skalierbarkeit — Millionen von Verbindungen, verwaltete Cloud-Dienste, QoS.
• Eine einzige Wahrheitsquelle — das OPC-UA-Informationsmodell ist die einzige Datendefinition, ob über Client/Server oder PubSub konsumiert.

Der Fehler, den die meisten Teams machen

Der häufigste Architekturfehler, den wir sehen: MQTT als einziges Protokoll nutzen und das Informationsmodell in JSON-Payloads neu erfinden.

Was dann passiert:

1. Team A definiert ein JSON-Schema für Pumpen-Telemetrie.
2. Team B definiert ein anderes JSON-Schema für dieselbe Pumpe.
3. Sechs Monate später weiß niemand mehr, welches Feld der Durchfluss und welches der Druck ist.
4. Jemand erstellt eine „Datenwörterbuch"-Tabelle zum Mapping der Feldnamen.
5. Die Tabelle ist immer veraltet.

OPC UA löst dieses Problem by Design. Das Informationsmodell ist der Vertrag zwischen Produzent und Konsument. Companion Specifications liefern branchenstandard-konforme Modelle, die Hersteller gemeinsam nutzen — kein Spreadsheet nötig.

Fazit

Hören Sie auf zu fragen „welches?" Fragen Sie „welches, wo?"

Wir sind die Schöpfer von node-opcua und das Team hinter Omni-Edge — dem OPC-UA-Server, der PubSub über MQTT nativ publiziert. Wenn Sie Hilfe beim Entwurf Ihrer OPC UA + MQTT-Architektur brauchen, sprechen Sie mit unseren Ingenieuren.