OPC UA vs. MQTT: Kein Kampf, sondern eine Zweckgemeinschaft

von DerSchneider

Einleitung: Zwei Schwergewichte, zwei Welten

Wer heute über Industrie 4.0, IIoT (Industrial Internet of Things) oder die Vernetzung von Produktion spricht, stößt unweigerlich auf zwei Protokolle: OPC UA (Open Platform Communications Unified Architecture) und MQTT (Message Queuing Telemetry Transport). In Foren und Fachartikeln wird oft ein „Kampf der Standards“ beschworen – als müsste sich am Ende eines durchsetzen. Diese Sichtweise ist nicht nur irreführend, sie ist auch schädlich für die Architektur moderner Automatisierungssysteme.

Die Wahrheit ist: OPC UA und MQTT wurden für unterschiedliche Anwendungsfälle, unterschiedliche Netzwerktopologien und unterschiedliche Qualitätsanforderungen entwickelt. Sie konkurrieren kaum, sie ergänzen sich. Wer beide versteht und richtig einsetzt, baut robustere, sicherere und zukunftsfähigere Systeme als derjenige, der sich auf eine Seite schlägt.

Dieser Artikel analysiert die Architekturen, Stärken und Schwächen beider Protokolle aus systemischer Perspektive – und zeigt an konkreten Integrationsszenarien, wie sie als Zweckgemeinschaft zusammenarbeiten.

OPC UA: Der schwergewichtige Universaldolmetscher

Herkunft und Philosophie

OPC UA entstand aus dem klassischen OPC (OLE for Process Control) der späten 1990er, das auf Microsofts COM/DCOM-Technologie basierte – plattformabhängig, schwer konfigurierbar und eine Sicherheitskatastrophe. Die Unified Architecture (UA) wurde ab 2006 als plattformunabhängiger Nachfolger entwickelt (heute standardisiert in IEC 62541).

Die Philosophie von OPC UA ist Information Modeling: Nicht nur Rohdaten zu übertragen, sondern deren Bedeutung, Kontext und Beziehungen zu anderen Daten. Ein OPC UA‑Server stellt einen Adressraum zur Verfügung, der Objekte, Variablen, Methoden und Ereignisse in einer baumartigen Struktur organisiert. Jedes Objekt kann mit Metadaten versehen werden – Einheit, Genauigkeit, Werksgrenzen, Historisierungsverhalten, Sicherheitsanforderungen.

Das macht OPC UA extrem mächtig, aber auch komplex. Ein vollständiger OPC UA‑Stack benötigt je nach Konfiguration 1–5 MB RAM und eine leistungsfähige CPU. Für kleine Sensoren ist das oft zu viel.

Architektur: Client/Server mit optionaler Pub/Sub

OPC UA ist klassisch ein Client/Server‑Protokoll. Ein Client (z. B. eine SPS, ein SCADA‑System oder eine Cloud‑Plattform) verbindet sich mit einem Server (z. B. einem Sensor oder einer Maschine) und liest oder schreibt Werte, ruft Methoden auf oder abonniert Datenänderungen (Monitored Items). Die Kommunikation läuft typischerweise über TCP/IP (Port 4840) oder über HTTPS (Port 443) mit SOAP/XML.

Seit Version 1.04 (2017) gibt es OPC UA Pub/Sub als Erweiterung. Hierbei senden Publisher (Server) Nachrichten an einen MQTT‑Broker, einen AMQP‑Broker oder direkt über UDP‑Multicast, ohne dass ein Client vorher eine Verbindung aufbauen muss. Das ist der wichtige Brückenschlag zu MQTT.

Stärken von OPC UA

1. Informationsmodellierung: Die Fähigkeit, komplexe Maschinenmodelle (z. B. nach VDMA 24582) abzubilden, ist einzigartig. Ein Client kann den Adressraum eines Servers durchsuchen und automatisch lernen, welche Daten verfügbar sind.
2. Sicherheit: Integrierte Authentifizierung (X.509 Zertifikate, Benutzername/Passwort), Verschlüsselung (AES‑256) und Nachrichtenintegrität. Das ist aus dem Container für die Industrie 4.0.
3. Plattformunabhängigkeit: Implementierungen existieren für Windows, Linux, VxWorks, QNX, aber auch für Embedded‑Systeme (OPC UA Nano‑Embedded‑Profile).
4. Redundanz und Failover: Kann mit redundanten Servern und automatischem Umschalten konfiguriert werden – wichtig für sicherheitskritische Anwendungen.

Schwächen von OPC UA

1. Komplexität und Ressourcenbedarf: Ein voller Stack ist schwergewichtig. Selbst das „Nano“-Profil benötigt noch etwa 200 KB RAM – für einen 8‑Bit‑Sensor immer noch zu viel.
2. Latenz bei Client/Server: Die Verbindungsaufbauphase (Handshake, Authentifizierung, Durchsuchen des Adressraums) kann mehrere Sekunden dauern. Für schnelle, spontane Verbindungen ungeeignet.
3. Verbreitung in der Feldebene: Viele einfache Sensoren (Druckschalter, Temperaturfühler) sprechen kein OPC UA – dafür sind sie zu billig und zu rechenarm.

MQTT: Das leichtgewichtige Postamt für Sensordaten

Herkunft und Philosophie

MQTT wurde 1999 von Andy Stanford-Clark (IBM) und Arlen Nipper (Arcom) entwickelt – für die Überwachung von Ölpipelines über Satellitenverbindungen mit geringer Bandbreite und hoher Latenz. Die Philosophie: Publish/Subscribe mit einem zentralen Broker. Sensoren (Publisher) senden Nachrichten an den Broker, der sie an alle interessierten Clients (Subscriber) verteilt. Die Nachrichten sind thematisch organisiert (Topics), z. B. factory/hallA/temperature/sensor3.

MQTT ist extrem leichtgewichtig. Ein minimaler MQTT‑Client kommt mit weniger als 10 KB RAM aus, der gesamte Protokoll‑Overhead beträgt nur 2 Bytes pro Nachricht (plus Topic‑Länge). Das ist ideal für batteriebetriebene Sensoren mit geringer Rechenleistung.

Architektur: Broker‑zentriertes Publish/Subscribe

MQTT kennt keine direkte Kommunikation zwischen Clients. Alle Nachrichten gehen über den Broker. Das hat Vorteile:

• Entkopplung: Publisher und Subscriber müssen sich nicht kennen.
• Skalierbarkeit: Ein Broker kann zehntausende Clients bedienen.
• Persistenz: Der Broker kann Nachrichten speichern (QoS 1 und 2) und später zustellen, wenn ein Client wieder online kommt.

Die Quality of Service (QoS) Stufen sind:

• QoS 0: Höchstens einmal (Fire and Forget) – keine Bestätigung.
• QoS 1: Mindestens einmal (Bestätigung durch PUBACK).
• QoS 2: Genau einmal (vierfacher Handshake) – aufwendig, aber sicher.

MQTT bietet keine eingebaute Verschlüsselung, kann aber über TLS (MQTTS) auf Port 8883 betrieben werden. Authentifizierung erfolgt über Benutzername/Passwort oder Client‑Zertifikate.

Stärken von MQTT

1. Leichtgewichtigkeit: Läuft auf den kleinsten Mikrocontrollern (ESP8266, Arduino) und verbraucht extrem wenig Energie – ideal für batteriebetriebene IIoT‑Sensoren.
2. Skalierbarkeit: Ein einzelner Broker (z. B. EMQX, VerneMQ, Mosquitto) kann Hunderttausende gleichzeitige Verbindungen handhaben.
3. Asynchrone Kommunikation: Publisher und Subscriber müssen nicht gleichzeitig online sein. Der Broker puffert Nachrichten.
4. Einfache Firewall‑Durchlässigkeit: MQTT nutzt in der Regel einen einzigen ausgehenden Port (8883 für MQTTS) – das ist in restriktiven Unternehmensnetzwerken ein riesiger Vorteil gegenüber OPC UA mit seinen dynamischen Ports.

Schwächen von MQTT

1. Kein Informationsmodell: MQTT überträgt nur rohe Bytes. Bedeutung, Einheit, Genauigkeit – all das muss außerhalb des Protokolls vereinbart werden (z. B. durch ein separates Topic‑Schema oder durch begleitende JSON/Protobuf‑Dokumentation).
2. Broker als Single Point of Failure: Fällt der Broker aus, bricht die gesamte Kommunikation zusammen. Redundante Broker‑Cluster (z. B. via MQTT‑Bridge) sind möglich, aber aufwendig.
3. Keine eingebaute Geräteerkennung: Ein Subscriber muss die Topics kennen, die er abonnieren will. Es gibt keine standardisierte Möglichkeit, herauszufinden, welche Topics ein Broker anbietet (außer proprietären Erweiterungen wie dem „$SYS“-Topic).
4. Sicherheit ist optional: MQTT ohne TLS ist Klartext. Viele Billig‑Sensoren unterstützen kein TLS, weil es zu rechenintensiv ist – ein großes Sicherheitsrisiko.

Der vermeintliche Konflikt: Wo die Lager sich streiten

Die hitzigsten Debatten entzünden sich an scheinbaren Widersprüchen:

„OPC UA ist zu schwer für die Feldebene“ – Ja, aber es gibt das OPC UA Pub/Sub über UDP für einfache Geräte und das Nano‑Profil. Und niemand zwingt einen Drucksensor, einen vollständigen OPC UA‑Server zu implementieren. Er kann weiterhin MQTT sprechen, und ein Gateway übersetzt.

„MQTT kann keine komplexen Maschinendaten abbilden“ – Das ist richtig, aber wozu auch? Ein Vibrationssensor sendet einen FFT‑Vektor als Byte‑Array. Die Information, dass es sich um einen FFT‑Vektor handelt, muss irgendwo abgelegt sein – entweder im Topic (z. B. machine/fft) oder in einem begleitenden Metadaten‑Kanal. OPC UA hätte diese Metadaten eingebaut, aber der Sensor ist dafür zu schwach.

„OPC UA ist sicherer“ – Grundsätzlich ja, weil Sicherheit integriert ist. Aber MQTT mit TLS und Zertifikaten ist genauso sicher. Das Problem ist, dass viele Anwender die Sicherheitsfeatures von MQTT nicht aktivieren, weil sie zu aufwendig sind.

„MQTT ist schneller“ – Bei kleinen Nachrichten und vielen Clients ja, weil der Verbindungsaufbau minimal ist. Bei großen Datenblöcken (z. B. Hunderte Variablen auf einmal) ist OPC UA oft effizienter, weil es Binärkodierung (UA‑Binary) und Datenkomprimierung unterstützt.

Die Zweckgemeinschaft: Integrationsszenarien

Die Praxis zeigt, dass eine reine MQTT‑ oder reine OPC‑UA‑Lösung selten optimal ist. Stattdessen haben sich drei etablierte Integrationsmuster herausgebildet:

Szenario 1: MQTT in der Feldebene, OPC UA in der Leitebene

Beschreibung: Hunderte einfache Sensoren (Temperatur, Füllstand, Vibration) senden ihre Daten per MQTT an einen lokalen Broker. Eine Edge‑Gateway‑Software (z. B. Node‑RED, Siemens Industrial Edge, Bosch IoT Gateway) subscribt zu diesen Topics, aggregiert die Daten, reichert sie mit Metadaten an (aus einer lokalen Konfigurationsdatenbank) und stellt sie als OPC UA‑Server zur Verfügung. Das SCADA‑System der Leitebene verbindet sich dann mit diesem OPC UA‑Server, um die Daten abzuholen und zu archivieren.

Vorteile: Die Sensoren bleiben einfach und billig. Die Leitebene bekommt ein sauberes, informationsreiches OPC UA‑Modell. Das Gateway kann auch Protokollübersetzung, Datenvalidierung und vorverarbeitende Analyse (z. B. FFT) durchführen.

Typische Produkte: MQTT‑Broker (Mosquitto, EMQX), OPC UA‑Server‑SDK (Softing, Unified Automation), Gateway‑Software (Node‑RED mit OPC UA‑ und MQTT‑Nodes).

Szenario 2: OPC UA Pub/Sub über MQTT als Transport

Beschreibung: Seit OPC UA Pub/Sub (Teil 14 der Spezifikation) ist es möglich, OPC UA‑Nachrichten über MQTT zu transportieren. Ein OPC UA‑Publisher kodiert seine Daten als UA‑Binary oder JSON und sendet sie an einen MQTT‑Broker. Ein OPC UA‑Subscriber empfängt sie von dort. Der Empfänger sieht die Nachricht als vollwertige OPC UA‑Daten mit allen Metadaten.

Vorteile: Die reiche Informationsmodellierung von OPC UA bleibt erhalten, während die Transportebene die Vorteile von MQTT nutzt: Entkopplung, Skalierbarkeit, einfache Firewall‑Passage.

Einschränkung: Nicht alle OPC UA‑Server unterstützen Pub/Sub bereits. Die Implementierung ist komplexer als klassisches Client/Server.

Szenario 3: OPC UA als „Backend“ für MQTT‑Daten

Beschreibung: Ein zentrales System (z. B. eine Cloud‑Plattform wie AWS IoT Core oder Microsoft Azure IoT Hub) empfängt MQTT‑Nachrichten von tausenden Sensoren. Diese Plattform speichert die Daten in einer Zeitreihendatenbank. Ein separates OPC UA‑Server‑Modul (z. B. als Teil der Plattform) liest die Daten aus der Datenbank und stellt sie über OPC UA zur Verfügung – für SCADA‑Systeme, die kein MQTT sprechen.

Vorteile: Alte SCADA‑Systeme, die nur OPC UA (oder klassisches OPC) verstehen, können auf moderne IIoT‑Daten zugreifen, ohne umgerüstet zu werden.

Entscheidungshilfe: Wann nehme ich was?

Zukunftsperspektive: OPC UA über MQTT als Standard

Die Industrie 4.0‑Plattform (die deutsche Standardisierungsinitiative) hat sich klar positioniert: Die Administration Shell (Verwaltungsschale) eines Assets wird als OPC UA‑Informationsmodell abgebildet. Der Transport kann über MQTT erfolgen. Das bedeutet, dass zukünftige Systeme beides können müssen – und beides auch tun werden.

Hersteller wie Siemens, Beckhoff, Bosch Rexroth und Microsoft arbeiten an der nahtlosen Integration. Siemens bietet mit Industrial Edge eine Plattform, die MQTT von Sensoren sammelt und als OPC UA‑Server bereitstellt. Microsofts Azure IoT Edge kann OPC UA‑Publisher direkt in die Cloud streamen.

Die Entwicklung geht dahin, dass die Grenzen verschwimmen: OPC UA wird leichter (UA‑FX, Field eXchange für die Feldebene), MQTT wird informationsreicher (durch standardisierte Topic‑Namensräume, z. B. Sparkplug B). Aber ein Sieger wird nicht ermittelt – weil es keinen Kampf gibt.

Fazit: Keine Hochzeit, aber eine produktive Zweckehe

OPC UA und MQTT sind keine Rivalen, sondern zwei Werkzeuge im Werkzeugkasten des Automatisierers. Das eine (OPC UA) glänzt durch Informationsreichtum, Sicherheit und Standardisierung. Das andere (MQTT) durch Leichtgewichtigkeit, Skalierbarkeit und einfache Cloud‑Anbindung. Die kluge Architektur nutzt beide dort, wo ihre Stärken liegen, und verbindet sie über Gateways oder native Pub/Sub‑Integration.

Der vermeintliche „Kampf der Standards“ ist ein Konstrukt der Marketingabteilungen und der Foren, die einfache Narrative lieben. Die Realität ist komplexer – und langweiliger: zwei Protokolle, die sich gegenseitig brauchen, um die Vision der durchgängigen, interoperablen Industrie 4.0 zu verwirklichen. Wer nur eines von beiden beherrscht, hat die Hälfte des Werkzeugs vergessen.

Quellen

• OPC Foundation (2023): OPC UA Specification Part 1–14. (insbesondere Part 14: Pub/Sub, Version 1.05)
• IEC 62541:2020 – OPC Unified Architecture (mehrteiliger Standard).
• OASIS MQTT Technical Committee (2019): MQTT Version 5.0. OASIS Standard.
• Banks, A., Gupta, R. (2021): MQTT Essentials – A Lightweight IoT Protocol. Packt Publishing, ISBN 978-1-80056-987-2.
• Mahnke, W., Leitner, S.-H., Damm, M. (2018): OPC Unified Architecture – Das praktische Handbuch für Anwender und Entwickler. Springer Vieweg, ISBN 978-3-662-56597-3.
• Plattform Industrie 4.0 (2024): Verwaltungsschale im Detail – Informationsmodellierung mit OPC UA. Whitepaper, Ausgabe April 2024.
• AWS IoT Core (2025): Developer Guide – MQTT and OPC UA Integration. Amazon Web Services.
• Siemens AG (2024): Industrial Edge – MQTT to OPC UA Gateway. Technische Dokumentation, ID: IE‑MQTT‑OPCUA‑1024.
• Eclipse Foundation (2024): Sparkplug B Specification – MQTT Topic Namespaces for Industrial IoT. Version 2.2.