OPC UA vs. MQTT: Welches Protokoll wofür? 

Kurz gesagt: OPC UA verbindet, MQTT entkoppelt. OPC UA ist ein dienstorientiertes Protokoll für den standardisierten, sicheren Zugriff auf Maschinen- und Anlagendaten – ein Client fragt gezielt bei einem Server an. MQTT ist ein ereignisgetriebenes Publish-/Subscribe-Protokoll: Datenquellen und Datenempfänger kennen sich nicht, ein Broker vermittelt zwischen ihnen. Beide Protokolle sind offene Standards, beide transportieren strukturierte Daten – der Unterschied liegt im Kommunikationsmuster, nicht in der Wertigkeit. 

Die praktische Antwort lautet deshalb selten „entweder – oder“: OPC UA für Zugriff und Erfassung an der Maschine, MQTT für Verteilung und Integration Richtung IT und Cloud. Wer beides kombiniert, bekommt eine Architektur, die vom Shopfloor bis in die Cloud durchgängig trägt.

Der externe Link zum Video zum Beitrag: Lunch Talk – OPC UA vs. MQTT auf YouTube

Die Kernfrage: Wer spricht wen an? 

Der entscheidende Unterschied zwischen den beiden Protokollen ist die Frage, wer die Kommunikation initiiert, und wer wen kennen muss. 

Bei OPC UA besteht eine gerichtete Beziehung: Ein Client baut eine Session zu einem Server auf, navigiert durch dessen Adressraum, liest Werte, schreibt Parameter, abonniert Änderungen. Der Client weiß, mit welcher Maschine er spricht. Das ist ideal, wenn Sie gezielt auf eine Anlage zugreifen wollen und es setzt voraus, dass beide Seiten erreichbar sind. 

Bei MQTT gibt es diese Beziehung nicht. Ein Publisher schickt Daten an ein Topic auf dem Broker und weiß nicht, wer sie liest. Ein Subscriber abonniert ein Topic und weiß nicht, woher die Daten kommen. Sender und Empfänger sind zeitlich, räumlich und technisch entkoppelt. Neue Datenempfänger lassen sich hinzufügen, ohne dass an der Quelle irgendetwas geändert werden muss. 

Genau diese Entkopplung macht MQTT zur Grundlage moderner Datenarchitekturen wie dem Unified Namespace, in dem der Broker den strukturierten, semantisch benannten Datenraum eines Unternehmens abbildet. MQTT ist damit deutlich mehr als reiner Transport.

Die Stärken von OPC UA – mit Beispielen aus der Praxis 

Semantik statt Rohwerte 

Ein OPC UA Server liefert nicht nur die Zahl 73,4, sondern die Information: Spindeltemperatur, Grad Celsius, Zeitstempel, Qualitätskennzeichen, zugehörige Maschine. Diese Struktur ist Teil des Protokolls und muss nicht nachträglich in einer Mapping-Tabelle gepflegt werden. 

Beispiel: Ein Werkzeugmaschinenhersteller stellt seine Anlagen über die Companion Specification umati bereit. Ein MES kann Auftragsstatus, Werkzeugstandzeiten und Störungen auslesen, ohne dass für jede Maschine ein eigenes Datenmodell entwickelt wird. 

Schreiben, nicht nur lesen 

OPC UA ist bidirektional und kennt Methodenaufrufe. Sie können Sollwerte setzen, Rezepte übertragen und Abläufe anstoßen. 

Beispiel: Aus dem ERP wird ein Fertigungsauftrag angelegt, die Rezeptparameter werden per OPC UA an die Abfüllanlage geschrieben, der Anlagenbediener quittiert – Papier und manuelle Eingabe entfallen vollständig. 

Sicherheit ab Werk 

Zertifikatsbasierte Authentifizierung, verschlüsselte Kommunikation und eine feingranulare Rechteverwaltung sind fester Bestandteil der Spezifikation, nicht Zusatzaufwand im Projekt. 

Beispiel: In einer regulierten Produktion muss nachvollziehbar sein, welcher Dienst welchen Parameter geändert hat. Mit OPC UA lässt sich das ohne zusätzliche Zwischenschicht abbilden. 

Alarme, Events und Diagnose 

Zustände, Grenzwertverletzungen und Quittierungen sind im Modell vorgesehen. 

Beispiel: Ein Instandhaltungssystem abonniert die Alarme mehrerer Anlagen und erzeugt automatisch Tickets, inklusive Anlagenkontext und Fehlercode.

Die Stärken von MQTT – mit Beispielen aus der Praxis 

Ein Datenstrom, beliebig viele Empfänger 

Ein Wert wird einmal publiziert und steht allen interessierten Systemen gleichzeitig zur Verfügung. Neue Empfänger kommen hinzu, ohne dass an der Quelle etwas verändert wird. 

Beispiel: Die Stückzahlen einer Linie gehen einmal auf den Broker. Von dort bedienen sie das Shopfloor-Dashboard, die Cloud-Datenplattform und die Qualitätsauswertung – drei Verbraucher, eine Anbindung. 

Robust bei schwierigen Netzen 

Geringer Overhead, Quality-of-Service-Stufen und Pufferung machen MQTT belastbar, wo Verbindungen instabil oder Bandbreiten knapp sind. 

Beispiel: Ein Maschinenpark an mehreren Standorten überträgt Energie- und Zustandsdaten über Mobilfunk in die Zentrale. Fällt eine Verbindung kurz aus, gehen keine Daten verloren. 

Skalierung über Werke und Standorte hinweg 

Ein einheitlicher Topic-Baum bildet die Organisationsstruktur ab – Unternehmen, Werk, Bereich, Linie, Maschine, Kennzahl. 

Beispiel: Im Unified Namespace liegen die OEE-Werte aller Werke unter derselben Topic-Logik. Eine standortübergreifende Auswertung ist damit eine Frage der Subscription, nicht eines neuen Integrationsprojekts. 

Ereignisgetrieben statt zyklisch 

Es wird gesendet, wenn sich etwas ändert – nicht, weil ein Poll-Intervall abläuft. Das reduziert Last und verkürzt Reaktionszeiten. 

Beispiel: Eine Störmeldung erreicht das Instandhaltungsteam auf dem Mobilgerät im Moment ihres Auftretens, ohne dass ein System im Sekundentakt nachfragt.

Wann setzen Sie welches Protokoll ein? 

OPC UA, wenn…

• Sie strukturierten Zugriff auf Maschinen- und Anlagendaten benötigen 

• Sie semantische Informationen brauchen – Einheiten, Alarme, Status, Methoden 

• Sie in die Anlage zurückschreiben, parametrieren oder Abläufe auslösen wollen 

• Sicherheit und Benutzerverwaltung integriert sein sollen 

• Engineering, Diagnose oder Inbetriebnahme im Fokus stehen 

MQTT, wenn…

• Sie Daten effizient an viele Empfänger verteilen möchten 

• Sie zahlreiche Systeme, Werke und Standorte anbinden müssen 

• Sie mit geringer Bandbreite oder instabilen Netzen arbeiten 

• Sie Cloud-, IoT- oder Analytics-Szenarien umsetzen 
  
• Sie eine Architektur brauchen, die ohne Umbau der Quellen wachsen kann
  

Das Zusammenspiel in der Praxis 

In den meisten Produktionsumgebungen entsteht die tragfähige Architektur aus der Kombination beider Protokolle: 

Feldebene – Sensoren, SPS, Roboter, CNC-Maschinen → OPC UA Server – strukturierter, semantischer Zugriff auf Maschinendaten → Edge / Gateway – Aufbereitung, Aggregation, Kontextualisierung → MQTT Broker – Verteilung nach dem Publish-/Subscribe-Prinzip → Cloud & Datenplattform, MES/ERP, Dashboards, KI & Analytik 

Genau an dieser Schnittstelle setzen unsere Produkte an: kepware und der OPC Router erschließen die Anlagen und übersetzen zwischen den Protokollwelten, manubes und pronubes machen die Daten nutzbar – als Echtzeitvisualisierung, als Datenmodell und als Grundlage für Entscheidungen. Die Protokollfrage wird damit zu einer Architekturentscheidung, nicht zu einer Glaubensfrage.

Fazit 

OPC UA und MQTT sind keine Konkurrenten. Sie beantworten unterschiedliche Fragen: OPC UA die nach dem strukturierten, sicheren Zugriff auf die Maschine – MQTT die nach der entkoppelten, skalierbaren Verteilung im Unternehmen. OPC UA verbindet. MQTT entkoppelt. Wer beides an der richtigen Stelle einsetzt, schafft die Grundlage für eine durchgängig vernetzte, intelligente Produktion – und damit für smart production. 

Sie möchten tiefer einsteigen? 

In unserem Lunch Talk Video „OPC UA vs. MQTT“ gehen wir das Thema anhand konkreter Architekturen durch und beantworten Ihre Fragen live. Jetzt Platz sichern – oder direkt Kontakt zu unseren Expertinnen und Experten aufnehmen. 

👉 Jetzt das ganze Video ansehen

Kriterium	OPC UA	MQTT
Kommunikationsmuster	Client/Server, dienstorientiert (zusätzlich PubSub ab OPC UA 1.04)	Publish/Subscribe über Broker
Kopplung	Gerichtete Verbindung, Client kennt den Server	Vollständig entkoppelt über Topics
Datenmodell	Semantisches Informationsmodell im Adressraum: Typen, Einheiten, Status, Alarme, Methoden	Topic-Struktur; Semantik über Konventionen oder Sparkplug B
Sicherheit	Integriert: Zertifikate, Verschlüsselung, Authentifizierung, Rechteverwaltung	TLS-Verschlüsselung, Authentifizierung am Broker; Rechte je Topic
Overhead	Höher – umfangreiches Protokoll, binär über TCP	Sehr gering – minimaler Header, ideal für schmale Bandbreiten
Skalierung	Pro Verbindung; viele Clients erhöhen die Serverlast	Sehr gut – ein Datenstrom, beliebig viele Abonnenten
Verhalten bei Netzstörungen	Session bricht ab, Reconnect nötig	Puffern, QoS-Stufen, Last Will & Testament
Typischer Einsatzort	Feld- und Steuerungsebene, OT-nah	Standortübergreifend, Edge, Cloud, IT-nah
Standard	IEC 62541 (OPC Foundation)	ISO/IEC 20922 (OASIS)
Standardport	4840	1883 (8883 mit TLS)
In einem Satz	Verbindet gezielt und beschreibt vollständig	Entkoppelt sauber und verteilt effizient