Eine Produktionsanlage kann intern zuverlässig mit OPC UA arbeiten und trotzdem bei der Übertragung zu Cloud, Leitwarte oder entfernten Standorten an Grenzen stoßen. Genau hier ergänzt MQTT die industrielle Kommunikation mit einem schlanken Publish-Subscribe-Modell. Ich zeige, was mit mqtt opc ua technisch gemeint ist, wie beide Protokolle zusammenspielen, welche Integrationswege sich für IoT-Systeme eignen und wo typische Fehler entstehen.
Die passende Kombination für verteilte IoT-Systeme
- OPC UA beschreibt industrielle Daten, Geräte, Zustände, Methoden und Alarme.
- MQTT transportiert Nachrichten effizient über einen Broker und instabile Netzwerke.
- Die häufigste Architektur nutzt ein Edge-Gateway als Übersetzer zwischen Maschine und IoT-Plattform.
- OPC UA PubSub über MQTT ist eine standardisierte Variante mit JSON- oder UADP-Nachrichten.
- QoS 1 ist oft der vernünftige Kompromiss zwischen Zustellgarantie und zusätzlichem Datenverkehr.
Was MQTT und OPC UA jeweils leisten
Mit mqtt opc ua ist in technischen Projekten meist die Verbindung von MQTT und OPC UA gemeint, nicht ein neues drittes Protokoll. Beide Standards lösen unterschiedliche Probleme und werden gerade deshalb häufig gemeinsam eingesetzt.
OPC UA ist auf industrielle Interoperabilität ausgelegt. Ein OPC-UA-Server stellt Datenpunkte, Objekte, Eigenschaften, Methoden, Ereignisse und Alarme in einem strukturierten Informationsmodell bereit. Eine Anwendung kann dadurch nicht nur den Wert eines Sensors lesen, sondern auch erkennen, was dieser Wert bedeutet und zu welchem Anlagenteil er gehört.
MQTT arbeitet dagegen als leichtgewichtiges Nachrichtenprotokoll nach dem Publish-Subscribe-Prinzip. Ein Gerät veröffentlicht Daten an einen Topic, während beliebig viele Empfänger diese Daten über einen zentralen Broker abonnieren. Für entfernte Pumpstationen, Energieanlagen oder mobile Messstellen mit Mobilfunk- oder Satellitenverbindung ist das oft deutlich praktischer als viele direkte Verbindungen.
Ich sehe den wichtigsten Unterschied so: OPC UA liefert den industriellen Kontext, MQTT den effizienten Transport. Wer beide Protokolle verwechselt, baut entweder einen sehr guten Datenkatalog mit schlechter Verteilung oder einen schnellen Datenkanal ohne ausreichende Bedeutung der Messwerte.
Die beiden Protokolle im direkten Vergleich
| Kriterium | OPC UA | MQTT |
|---|---|---|
| Grundmodell | Client-Server und PubSub | Publish-Subscribe über Broker |
| Stärke | Informationsmodell und industrielle Dienste | Schlanker Nachrichtentransport |
| Datenbeschreibung | Strukturierte Typen, Eigenschaften und Metadaten | Payload bleibt grundsätzlich anwendungsspezifisch |
| Typische Nutzung | Maschinenzugriff, Diagnose, Alarme, Konfiguration | Telemetrie, Ereignisse, Cloud- und Edge-Kommunikation |
| Netzwerkverhalten | Gut für lokale und kontrollierte Anlagenetze | Gut für viele Clients und wechselhafte Verbindungen |
| Sicherheit | Zertifikate, Signierung, Verschlüsselung und Zugriffsrechte | TLS, Client-Authentifizierung und Broker-Berechtigungen |
MQTT definiert absichtlich weder ein bestimmtes Datenformat noch eine verpflichtende Topic-Struktur. Ein Topic wie anlage/pumpe/temperatur ist verständlich, aber noch kein vollständiges industrielles Informationsmodell. Genau deshalb reicht reines MQTT in größeren Projekten oft nicht aus, wenn mehrere Hersteller, Gateways und Anwendungen zusammenspielen müssen.
OPC UA ist semantisch stärker, bringt aber mehr Komplexität mit. Für eine einzelne Temperaturmeldung über eine schwache Verbindung wäre das vollständige Modell unnötig schwer. Für die Frage, ob eine Pumpe betriebsbereit ist, welche Einheit ein Messwert besitzt oder welcher Alarm zu einer Anlage gehört, ist diese zusätzliche Struktur jedoch sehr wertvoll.
So funktioniert die Integration im IoT-System
Das Edge-Gateway als Übersetzer
In der Praxis ist ein Edge-Gateway meist der sauberste Einstieg. Es verbindet sich lokal mit OPC-UA-Servern oder Steuerungen, liest ausgewählte Variablen und veröffentlicht sie als MQTT-Nachrichten an einen Broker. Die IoT-Plattform, ein Dashboard oder ein Analysemodell muss dadurch keine direkte Verbindung zu jeder Maschine aufbauen.
Diese Architektur trennt die Verantwortlichkeiten sinnvoll. Die lokale Seite kümmert sich um Maschinenprotokolle, Pufferung und Datenfilterung, während die zentrale Seite Daten speichert, visualisiert und analysiert. Fällt die WAN-Verbindung aus, kann das Gateway Messwerte zwischenspeichern und später übertragen, sofern diese Funktion in der eingesetzten Lösung vorgesehen ist.
OPC UA PubSub über MQTT
OPC UA kann MQTT auch direkt als Transport für sein PubSub-Modell verwenden. Die OPC Foundation beschreibt dafür standardisierte Topic-Strukturen und zwei wichtige Nachrichtenabbildungen, JSON und UADP. JSON ist leichter zu inspizieren und häufig einfacher in Web- und Cloud-Dienste einzubinden, während UADP binär und in der Regel effizienter ist.
Diese Variante ist besonders interessant, wenn mehrere Systeme ein gemeinsames OPC-UA-PubSub-Modell verwenden sollen. Sie beseitigt aber nicht automatisch jede Integrationsarbeit. Geräteprofile, Namensräume, Zertifikate, Topic-Konventionen und die Auswahl der übertragenen Variablen müssen weiterhin sauber geplant werden.
Ein konkretes Beispiel
Eine entfernte Wasseraufbereitungsanlage misst Druck, Durchfluss und Motorzustand. Der OPC-UA-Server kennt die technischen Einheiten, Grenzwerte und Alarmzustände. Das Gateway veröffentlicht nur die benötigten Werte an MQTT, etwa mit Zeitstempel, Qualität und Anlagenkennung.
Die Leitwarte abonniert die Betriebsdaten, ein Wartungssystem nur die Alarme und eine Analyseplattform die historischen Messwerte. Ein Messwert kann so mehrere Anwendungen versorgen, ohne dass jede Anwendung eine eigene Verbindung zur Steuerung benötigt. Für verteilte Infrastruktur mit begrenzter Bandbreite ist genau diese Entkopplung oft der entscheidende Vorteil.
Welche Architektur zu welcher Aufgabe passt
Ich würde die Entscheidung nicht mit der Frage beginnen, welches Protokoll moderner klingt. Entscheidend ist, ob die Anwendung eher Maschinenverständnis, skalierbare Verteilung oder beides benötigt.
- Nur OPC UA passt, wenn Anwendungen direkt auf Maschinen zugreifen, Diagnosen ausführen oder Methoden und Alarme vollständig nutzen müssen.
- Nur MQTT reicht für einfache Telemetrie, sofern Datenmodell, Topic-Struktur und Zustände verbindlich dokumentiert sind.
- OPC UA plus MQTT-Gateway ist meist die beste Wahl für bestehende Anlagen mit zentraler IoT-Plattform.
- OPC UA PubSub über MQTT eignet sich, wenn standardisierte PubSub-Nachrichten und eine gemeinsame OPC-UA-Semantik im Mittelpunkt stehen.
Für ein kleines System mit zehn Sensoren kann eine direkte MQTT-Lösung genügen. Bei mehreren Anlagen, Herstellern und Standorten würde ich dagegen nicht auf frei erfundene Payloads vertrauen. Eine Spezifikation wie Sparkplug kann MQTT um Topic-Namensraum, Payload-Struktur und Zustandsmanagement für industrielle Anwendungen ergänzen.
Sparkplug ersetzt OPC UA nicht. Es standardisiert die Nutzung von MQTT für industrielle Szenarien, während OPC UA die Beschreibung und den Zugriff auf industrielle Informationen übernimmt. Wer beide kombiniert, sollte vorher festlegen, welches System die führende Semantik besitzt. Sonst entstehen doppelte Bezeichnungen, widersprüchliche Einheiten und schwer wartbare Datenmodelle.
Sicherheit und Betrieb entscheiden über den Erfolg
Ein verschlüsselter Transport allein macht eine Anlage noch nicht sicher. Für MQTT gehören TLS, eindeutige Client-Identitäten, getrennte Berechtigungen pro Topic und eine sorgfältige Broker-Konfiguration zum Mindestumfang. Ein Sensor sollte nicht automatisch auf Steuerbefehle oder Daten anderer Standorte zugreifen können.
OPC UA bringt eigene Sicherheitsmechanismen mit, darunter Zertifikate, Signierung, Verschlüsselung und Benutzerrechte. Diese Schutzschicht bleibt wichtig, auch wenn die Daten anschließend über MQTT weitergeleitet werden. Das Gateway darf Sicherheitsprüfungen nicht einfach umgehen, nur weil die zentrale Plattform bequemere Zugangsdaten verwendet.
QoS richtig einsetzen
MQTT bietet drei Quality-of-Service-Stufen. QoS 0 sendet höchstens einmal und eignet sich für häufige Messwerte, bei denen ein einzelner Verlust verkraftbar ist. QoS 1 bestätigt die Zustellung, kann eine Nachricht bei Wiederholung aber doppelt liefern. QoS 2 bietet den aufwendigsten Zustellablauf und sollte gezielt eingesetzt werden.
Wichtig ist die praktische Einschränkung: QoS 2 garantiert nicht automatisch, dass ein Geschäftsprozess eine Aktion nur einmal ausführt. Bei einem Steuerbefehl braucht die Anwendung zusätzlich eine eindeutige Nachrichten-ID, eine Quittierung und eine sichere Wiederholungslogik. Für normale Telemetrie ist QoS 1 oft der bessere Kompromiss zwischen Zuverlässigkeit und Datenverkehr.
Lesen Sie auch: KI am Edge im IoT - Lohnt sich das wirklich?
Typische Fehler bei der Umsetzung
- MQTT wird ohne einheitliche Topic-Struktur eingeführt, sodass jede Abteilung eigene Namen verwendet.
- Einheiten, Zeitstempel und Qualitätsstatus fehlen in der Payload.
- Alle Daten werden ungefiltert in die Cloud übertragen, obwohl Edge-Verarbeitung Bandbreite sparen könnte.
- Retained Messages werden für schnell wechselnde Werte missbraucht und zeigen später veraltete Zustände.
- Steuerbefehle werden wie harmlose Telemetrie behandelt, obwohl sie eine zusätzliche Freigabe benötigen.
- Offline-Verhalten, Puffergröße und Zeitstempel werden erst nach dem ersten Netzausfall geprüft.
Gerade beim Betrieb über Mobilfunk oder Satellitenverbindungen ist ein Test mit absichtlich unterbrochener Verbindung sehr aufschlussreich. Ich prüfe dabei nicht nur, ob Daten später ankommen, sondern auch, ob die Plattform den Unterschied zwischen aktuell, verspätet und unbekannt korrekt anzeigt.
Die pragmatische Entscheidung für langfristige IoT-Projekte
Für die meisten industriellen IoT-Systeme lautet meine Empfehlung nicht MQTT oder OPC UA, sondern eine klare Rollenverteilung. OPC UA bleibt die Sprache der Anlage, MQTT übernimmt die verteilte Nachrichtenverteilung und ein Edge-Gateway kontrolliert die Übersetzung.
Wer neu plant, sollte zuerst Datenmodell, Topic-Namensraum, Sicherheitszonen und Offline-Verhalten festlegen. Danach wird entschieden, ob einfache MQTT-Payloads, Sparkplug oder OPC UA PubSub über MQTT den besten Kompromiss aus Interoperabilität, Aufwand und Bandbreite bieten.
Die wichtigste Investition ist dabei selten der Broker selbst. Den größten Unterschied machen saubere Semantik, begrenzte Zugriffsrechte und realistische Netzwerktests. Dann wird aus zwei Protokollen keine zusätzliche Fehlerquelle, sondern eine belastbare Kommunikationsschicht für Maschinen, Edge-Systeme und entfernte Standorte.
