OPC UA vs. MQTT: Entscheidungsleitfaden für die Maschinenanbindung

OPC UA und MQTT konkurrieren seltener, als die Suchanfrage „OPC UA vs. MQTT“ vermuten lässt. OPC UA beschreibt, was ein Messwert bedeutet, und regelt den gesicherten Zugriff auf die Maschine; MQTT transportiert Nachrichten entkoppelt über einen Broker und interessiert sich nicht für deren Inhalt. In den meisten Werken lautet die Antwort deshalb nicht „entweder – oder“, sondern: OPC UA am Asset, MQTT nach oben – und ein Gateway dazwischen.

Warum „OPC UA oder MQTT“ meist die falsche Frage ist

OPC UA und MQTT lösen unterschiedliche Aufgaben im Datenpfad, deshalb ist der Unterschied zwischen OPC UA und MQTT kein Leistungsvergleich. OPC UA (OPC Unified Architecture) legt fest, wie ein Server seine Variablen als Adressraum mit Datentypen, Statuscodes und Zeitstempeln bereitstellt, wie sich Client und Server ausweisen und wie Nachrichten signiert und verschlüsselt werden. MQTT legt fest, wie ein Client eine Nachricht an einen Broker übergibt und wie der Broker sie an Abonnenten verteilt. Der Inhalt ist dem Protokoll gleichgültig.

Wer die Frage stellt, verrät meist die eigentliche Entscheidung. Die Instandhaltung will Maschinenzustände zuverlässig im Dashboard sehen. Die IT-Leitung will wissen, welche Ports offen sind, wer den Broker betreibt und wie Zertifikate erneuert werden. Hinter „OPC UA oder MQTT“ steckt also eine Entscheidung über Datenmodell, Verbindungsrichtung durch die Firewall und Betriebsmodell – nicht über Bytes pro Sekunde. Beide Standards werden gepflegt: OPC 10000 Teil 2 und Teil 14 liegen seit Oktober 2025 in Release 1.05.06 vor, MQTT 5.0 ist seit März 2019 OASIS-Standard.

Was OPC UA leistet: Informationsmodell, Adressraum, Sicherheitsmodell

OPC UA liefert mit jedem Wert seinen Kontext mit. Ein OPC-UA-Server stellt seine Daten als Knoten (Nodes) mit eindeutigen NodeIds bereit. Liest ein Client eine Variable, bekommt er laut OPC 10000-4 einen DataValue, der neben dem Wert einen StatusCode, einen SourceTimestamp und einen ServerTimestamp trägt. Der Statuscode sagt, ob der Server den Wert liefern konnte; bei einem Fehlerstatus ist der Wert laut Spezifikation zu ignorieren. Genau diese Information fehlt einem nackten MQTT-Payload, wenn niemand sie hineinschreibt.

Darüber liegen die Companion Specifications: branchenspezifische Informationsmodelle, die festlegen, wie etwa eine Werkzeugmaschine ihre Daten strukturiert. Zwei Maschinen verschiedener Hersteller mit derselben Companion Specification liefern Betriebszustand oder Stückzahl unter denselben Knotennamen. Bei MQTT muss diese Vereinbarung außerhalb des Protokolls getroffen werden – im Projekt, mit jedem Lieferanten neu.

Das Sicherheitsmodell nach OPC 10000-2 arbeitet mit Zertifikaten. Jede OPC-UA-Anwendung besitzt ein Application Instance Certificate, das beim Aufbau des SecureChannel ausgetauscht wird; der Empfänger prüft es gegen seine Trust List, einen vom Administrator gepflegten Zertifikatsspeicher. Der Nutzer authentifiziert sich zusätzlich über die Session-Dienste. Wie Nachrichten geschützt werden, bestimmt der Message Security Mode (Tab. 01). Was das bei einer konkreten Steuerungsfamilie bedeutet, zeigt S7-Daten auslesen: OPC-UA-Server, Snap7 und optimierte Datenbausteine.

OPC UA kennt seit Teil 14 außerdem ein eigenes Publish/Subscribe-Modell: ohne Broker per UDP im lokalen Netz oder über einen MQTT-Broker. Das MQTT-Mapping (OPC 10000-14, Abschnitt 7.3.4) definiert Adressen der Form mqtt:// (Port 1883) und mqtts:// (Port 8883), eine Topic-Struktur mit dem Präfix opcua, die Codierungen UADP und JSON sowie die Abbildung auf MQTT QoS 0, 1 und 2. „OPC UA over MQTT“ ist also ein spezifizierter Weg, kein Widerspruch.

Was MQTT leistet: Broker, Topics, QoS und Verhalten bei Verbindungsabbruch

MQTT entkoppelt Sender und Empfänger vollständig. Ein Client verbindet sich zum Broker, publiziert Nachrichten auf ein Topic und abonniert Topics, die ihn interessieren; wer sonst noch liest, weiß er nicht. Topics sind hierarchische Zeichenketten, deren Ebenen durch / getrennt sind. Die OASIS-Norm schreibt keine Struktur vor und nennt als Merkmal ausdrücklich einen Transport, der gegenüber dem Inhalt des Payloads agnostisch ist – gleichzeitig die Stärke und das größte Projektrisiko des Protokolls.

Drei Mechanismen machen MQTT für instabile Verbindungen robust. Erstens Retained Messages: Setzt der Publisher das RETAIN-Flag, muss der Broker die Nachricht speichern und jedem späteren Abonnenten sofort zustellen – ein neu gestartetes Dashboard sieht den letzten Zustand ohne Wartezeit. Zweitens die Will Message: Der Client hinterlegt beim Verbindungsaufbau eine Nachricht, die der Broker publiziert, wenn die Verbindung ohne reguläres DISCONNECT abreißt. Mit dem Will Delay Interval aus MQTT 5.0 wartet der Broker eine definierte Zeit; verbindet sich der Client vorher neu, unterbleibt die Will Message.

Drittens die Session-Persistenz: Über das Session Expiry Interval legt der Client fest, wie lange der Broker Abonnements und unbestätigte Nachrichten mit QoS 1 und 2 nach einem Abbruch aufbewahrt; bei 0 endet die Session mit der Verbindung. Deshalb trägt MQTT über Mobilfunk und WAN besser als eine sessionbasierte Client/Server-Verbindung: Der Client muss nur den Broker erreichen, der Broker puffert, und „Maschine nicht erreichbar“ ist selbst eine Nachricht.

OPC UA vs. MQTT: die Entscheidungsmatrix nach Szenario

OPC UA vs. MQTT entscheidet sich an wenigen Kriterien, die sich pro Anlage beantworten lassen. Tab. 03 stellt die Eigenschaften gegenüber, Tab. 04 übersetzt sie in typische Szenarien der Maschinenanbindung. Beide vergleichen OPC UA Client/Server mit MQTT als Transport.

Zwei Aussagen fehlen bewusst. „MQTT ist schneller“ steht nicht in der Matrix, weil die Latenz von Broker, QoS-Stufe, Netzstrecke und Abtastrate abhängt, nicht vom Protokollnamen. „OPC UA ist sicherer“ steht nicht dort, weil Sicherheit bei beiden eine Konfigurationsentscheidung ist: Ein Server im Modus None ist unsicherer als ein MQTT-Broker mit TLS und Client-Zertifikaten.

Sparkplug B: die Struktur, die nacktes MQTT nicht mitbringt

Sparkplug B schließt die drei Lücken, die MQTT absichtlich offen lässt. Ohne Konvention legt jeder Integrator eigene Topics an, verpackt Zahlen mal als Text, mal als JSON, mal binär, und niemand weiß, ob ein Gerät noch lebt oder nur nichts mehr sendet. Die Eclipse Foundation hat dafür die Sparkplug-Spezifikation veröffentlicht, aktuell in Version 3.0.0 aus dem Jahr 2022.

• —Topic Namespace: Alle Clients müssen die Struktur namespace/group_id/message_type/edge_node_id/[device_id] verwenden; für Sparkplug B lautet der Namespace spBv1.0.
• —Payload: Nachrichten werden mit Google Protocol Buffers codiert; Metriken tragen Namen, Datentyp, Zeitstempel und Wert.
• —Session State Management: Edge Nodes melden sich mit NBIRTH an und hinterlegen NDEATH als MQTT Will Message; Host Applications publizieren ihren Zustand auf spBv1.0/STATE/<host_id> mit QoS 1 und gesetztem Retain-Flag.
• —Report by Exception: Nach der Birth-Nachricht mit allen aktuellen Werten werden neue Werte nur bei Änderung gesendet; die Spezifikation schreibt RBE nicht für jeden Fall vor.

Sparkplug B (Eclipse 3.0):
  spBv1.0/<group_id>/<message_type>/<edge_node_id>/[<device_id>]
  Beispiel: spBv1.0/halle2/DDATA/edge-linie1/presse04

OPC UA PubSub over MQTT (OPC 10000-14, 7.3.4.7):
  <Prefix>/<Encoding>/<MqttMessageType>/<PublisherId>/[<WriterGroup>[/<DataSetWriter>]]
  Beispiel: opcua/json/data/presse04/wg1/dsw1

Sparkplug hat einen Preis. Die Spezifikation bindet den Edge Node an feste MQTT-Einstellungen: Clean Start beziehungsweise Clean Session auf true, Session Expiry Interval 0, NBIRTH und NDATA mit QoS 0 ohne Retain. Die Zuverlässigkeit kommt nicht aus QoS 1, sondern aus der Zustandslogik von Birth und Death. Wie aus Sparkplug-Gruppen ein werksweites Namensschema nach ISA-95 wird, beschreibt Unified Namespace: Referenzarchitektur mit ISA-95-Topic-Schema.

Die Brücke in der Praxis: OPC UA am Asset, MQTT für den Transport

Der Referenzpfad in den meisten Werken lautet SPS → OPC-UA-Server → Gateway → MQTT-Broker → Zeitreihenspeicher. Das OPC-UA-MQTT-Gateway – ein Industrie-PC in der Halle oder ein Edge-Modul im Schaltschrank – ist der einzige OPC-UA-Client der Maschine und der einzige Publisher für ihre Topics.

1. 01

   OPC-UA-Server inventarisieren

   Endpunkte, Security Policies, Namespaces und die tatsächlich benötigten Knoten erfassen – nicht den ganzen Adressraum abonnieren.

2. 02

   Gateway als OPC-UA-Client einrichten

   Eigenes Application Instance Certificate erzeugen, im Server in die Trust List aufnehmen, Modus SignAndEncrypt, Subscription statt Polling.

3. 03

   Payload-Vertrag festlegen

   Was aus dem DataValue mitfährt: Wert, StatusCode, SourceTimestamp, Einheit, NodeId. Sparkplug B, OPC UA PubSub JSON oder eigenes JSON – vor dem ersten Topic entscheiden.

4. 04

   Broker mit TLS und Berechtigungen betreiben

   Port 8883, Zertifikate oder Konten pro Gateway, Schreibrechte pro Topic-Präfix, Will Message für jedes Gateway.

5. 05

   Speicher und Konsumenten anbinden

   Ein Subscriber schreibt in die Zeitreihendatenbank, weitere lesen für Dashboards oder Alarmierung. Kein Konsument spricht direkt mit der Steuerung.

Beim Übersetzen geht verloren, was das Gateway nicht bewusst mitnimmt; drei Dinge fallen regelmäßig unter den Tisch. Erstens der Statuscode: Ein Wert mit Bad-Status landet als normale Zahl in der Datenbank. Zweitens die Zeitstempelquelle: Der Broker kennt nur die Ankunftszeit; bei gepuffertem Nachsenden nach einem Netzausfall stimmen alle Kurven nicht. Drittens die Semantik: Aus ns=3;s=Presse04.Motor.Temp mit Einheit wird ein Topic namens temp1. Ein Payload, das diese Felder mitführt, kostet wenige Bytes und rettet die Auswertbarkeit.

{
  "nodeId": "ns=3;s=Presse04.Motor.Temp",
  "value": 63.4,
  "unit": "°C",
  "statusCode": "Good",
  "sourceTimestamp": "2026-09-21T06:12:03.418Z",
  "serverTimestamp": "2026-09-21T06:12:03.421Z",
  "source": "opc.tcp://presse04:4840"
}

Netzwerk, Firewall und Sicherheit: was die IT wirklich fragen wird

Die erste Frage der IT lautet nicht „welches Protokoll“, sondern „welche Richtung“. Bei OPC UA Client/Server öffnet der Client die Verbindung zum Server auf der Maschine – die Regel zeigt in das OT-Netz hinein. Bei MQTT öffnen alle Clients ausgehend zum Broker; steht er in einer DMZ oder beim Hoster, braucht das OT-Netz keine eingehende Regel.

Die zweite Frage betrifft Zertifikate – auf beiden Seiten. OPC UA verlangt pro Anwendung ein Application Instance Certificate und pro Server eine gepflegte Trust List; beim Broker gilt dasselbe für TLS-Server- und Client-Zertifikate. Läuft eines ab oder passt der Hostname nicht, steht die Datenerfassung still – mit selten eindeutiger Fehlermeldung. Wie sich das eingrenzen lässt, steht in OPC-UA-Verbindung scheitert: Zertifikate, Security Policy und Endpunkte prüfen.

Die dritte Frage ist die Segmentierung: Ein gemeinsam genutzter Broker ist ein Zonenübergang und braucht eine eigene Zone, Berechtigungen pro Topic-Präfix und Schreibrechte nur für Gateways. Kommandos in Richtung Steuerung – Sparkplug NCMD oder ein OPC-UA-Write – prüft das Gateway gegen eine Freigabeliste.

Checkliste vor der Entscheidung

Zehn Fragen entscheiden über das Protokoll, bevor das erste Werkzeug installiert wird – danach ergibt sich OPC UA vs. MQTT aus Tab. 04.

Fazit: OPC UA am Asset, MQTT für den Weg nach oben

OPC UA vs. MQTT ist keine Entweder-oder-Frage, sondern eine Frage der Schicht. OPC UA gehört dorthin, wo Bedeutung entsteht und Zugriff geregelt wird: an die Maschine, mit Zertifikaten und im Modus SignAndEncrypt. MQTT gehört dorthin, wo viele Konsumenten entkoppelt lesen: über den Broker, mit TLS und einer Konvention wie Sparkplug B oder OPC UA PubSub. Die Brücke dazwischen ist kein Kompromiss, sondern die Architektur, die in den meisten Werken trägt.

Der nächste Schritt ist kein Werkzeugkauf, sondern die Checkliste oben – vor allem die Fragen nach Namenskonvention, Zertifikatserneuerung und Netzausfall. Wie so ein Datenpfad vom OPC-UA-Server bis zum Dashboard in der Praxis aussieht, zeigen die Beispiele von ralwo unter Lösungen.