MQTT vs. OPC UA: Unterschiede, Einsatz und Planung

IET-Berlin

iet-berlin.de

Schnittstellen frühzeitig sauber planen

IET-Berlin plant elektrotechnische Anlagen und unterstützt Projekte mit technischer Planung und Koordination, auch bei Energiemanagement und Ladeinfrastruktur.

Besuchen

Kurz gesagt

OPC UA (IEC 62541) ist ein Interoperabilitätsstandard mit Informationsmodell: Werte kommen mit Datentyp, Einheit, Zeitstempel, Qualität und Zusammenhang.
MQTT (OASIS-Standard, Version 5.0 seit 2019) ist ein leichtgewichtiges Publish/Subscribe-Protokoll; die Bedeutung der Nutzdaten muss das Projekt selbst festlegen.
Sicherheit ist bei OPC UA im Standard verankert, bei MQTT über TLS, Broker-Authentifizierung und Topic-Rechte zu ergänzen.
In der Praxis ergänzen sich beide: OPC UA PubSub kann MQTT sogar als Transportschicht verwenden.
Entscheidend ist, dass Protokolle, Schnittstellen, Datenpunkte und Verantwortlichkeiten bereits in der Planung festgelegt werden, nicht erst bei der Inbetriebnahme.

Was OPC UA leistet

Die OPC Unified Architecture ist als internationale Normenreihe IEC 62541 festgeschrieben. Teil 1 der IEC 62541 beschreibt die Konzepte und den Überblick der Architektur; erarbeitet wurde die Norm vom IEC-Subkomitee 65E, das sich mit der Integration von Geräten in Unternehmenssysteme befasst. Die Normenreihe umfasst 24 Teile, darunter das Sicherheitsmodell (Teil 2), das Adressraummodell (Teil 3), das Informationsmodell (Teil 5), Data Access (Teil 8), Alarms and Conditions (Teil 9) und PubSub (Teil 14).

Der wesentliche Unterschied zu einem reinen Transportprotokoll liegt im Informationsmodell. Ein OPC-UA-Server liefert nicht nur einen Zahlenwert, sondern beschreibt Objekte, Variablen, Datentypen und Beziehungen; zusätzlich kann er Methoden bereitstellen, Ereignisse übertragen, die Datenqualität kennzeichnen und Zeitstempel mitliefern. Eine Pumpe ist in diesem Modell also kein loser Gleitkommawert, sondern ein Objekt mit Durchfluss in Litern pro Minute, Betriebszustand, Alarmschwelle und Wartungsinformation. Diese Semantik ermöglicht herstellerübergreifende Interoperabilität, ohne dass jeder Datenpunkt einzeln gemappt werden muss.

Das klassische Kommunikationsmuster ist Client/Server: Ein Client fragt gezielt bei einem Server an, liest, schreibt oder ruft Methoden auf. In der deutschen Industrie hat OPC UA einen festen Platz; bereits im April 2015 wurde es im Referenzarchitekturmodell Industrie 4.0 (RAMI 4.0) als Empfehlung für den Kommunikationslayer gelistet. Hinter dem Standard steht die OPC Foundation, in der Anwender, Hersteller und Konsortien gemeinsam an Standards für eine sichere, herstellerübergreifende Interoperabilität arbeiten.

Was MQTT leistet

MQTT ist nach der OASIS-Spezifikation MQTT Version 5.0 vom 7. März 2019 ein Client-Server-Publish/Subscribe-Messaging-Protokoll, das leichtgewichtig, offen und einfach zu implementieren ist. Es wurde ausdrücklich für ressourcenbeschränkte Umgebungen wie M2M- und IoT-Anwendungen konzipiert, in denen ein kleiner Code-Footprint oder eine geringe Bandbreite gefordert sind. Seinen Ursprung hat das Protokoll im Jahr 1999 in der Überwachung von Ölpipelines; 2014 wurde es als OASIS-Standard veröffentlicht.

Das Prinzip ist einfach: Alle Teilnehmer verbinden sich mit einem zentralen Broker. Datenquellen veröffentlichen Nachrichten zu sogenannten Topics, und Empfänger abonnieren genau die Topics, die sie benötigen; der Broker nimmt die Telegramme entgegen und leitet sie an die angemeldeten Konsumenten weiter, wie industr.com die Arbeitsweise beschreibt. Sender und Empfänger kennen sich nicht, was neue Abnehmer ohne Eingriff in die Quelle ermöglicht.

Für die Zuverlässigkeit definiert die Spezifikation drei Zustellstufen (Quality of Service): „At most once“ mit möglichem Nachrichtenverlust, „At least once“ mit garantierter Zustellung und möglichen Duplikaten sowie „Exactly once“ mit exakt einmaliger Zustellung. Hinzu kommt ein Mechanismus, der Abonnenten über eine abnormale Trennung eines Clients informiert, was für die Zustandsüberwachung von Anlagen relevant ist. Topics selbst sind allerdings nur Zeichenketten, und die Nutzlast ist für das Protokoll ein Bytestrom ohne vordefiniertes Datenmodell.

Die Unterschiede im Überblick

Kriterium	OPC UA	MQTT
Normung	IEC 62541, 24 Teile	OASIS-Standard, Versionen 3.1.1 und 5.0 verbreitet
Kommunikationsmuster	Client/Server, zusätzlich PubSub (Teil 14)	Publish/Subscribe über zentralen Broker
Datenmodell	Umfangreiches Informationsmodell mit Typen, Einheiten, Beziehungen	Kein Datenmodell; Semantik legt das Projekt fest
Kommunikationsrichtung	Lesen, Schreiben, Methodenaufrufe, Ereignisse	Primär Verteilung von Nachrichten an Abonnenten
Sicherheit	Im Standard: Zertifikate, Authentifizierung, Signierung, Verschlüsselung	Über TLS, Broker-Authentifizierung und Topic-Rechte zu ergänzen
Zustellgarantie	Sessions und Subscriptions	QoS 0, 1 und 2
Skalierung bei vielen Abnehmern	Je Konsument eigene Session je Server	Einmal publizieren, beliebig viele Abonnenten
Typischer Ort	SPS, Feld- und Automationsebene, SCADA	Edge, Leitebene, IT, Cloud

Der Skalierungsunterschied wird in größeren Liegenschaften schnell praktisch: Bei klassischem OPC UA öffnet jeder Konsument eine Session zu jedem benötigten Server, sodass zehn Anwendungen an fünfzig Maschinen Hunderte Sessions bedeuten können, die jeweils Ressourcen auf den Steuerungen belegen. Bei MQTT veröffentlicht jede Quelle oder jedes Gateway einmal an den Broker. Umgekehrt fehlt MQTT das, was OPC UA auszeichnet: Ein OPC-UA-Client kann den Adressraum durchsuchen und findet Datenpunkte, ohne vorher eine Adressliste zu kennen.

Sicherheit: im Standard verankert oder im Projekt ergänzt

OPC UA bringt eine integrierte Sicherheitsarchitektur mit, die Benutzer-, Applikations- und Transportsicherheit abdeckt. Dazu gehören Secure Channels, Anwendungszertifikate, Authentifizierung, Autorisierung, Signierung und Verschlüsselung entsprechend den eingesetzten Sicherheitsprofilen. Wegen des Umfangs des Standards finden sich in der Praxis allerdings häufig schwach konfigurierte Sicherheitsimplementierungen, etwa wenn Endpunkte ohne Signierung und Verschlüsselung freigegeben oder Zertifikate pauschal akzeptiert werden. Die Sicherheitsfunktionen müssen also nicht nur vorhanden, sondern im Projekt verbindlich vorgegeben und abgenommen werden.

MQTT definiert keine eigenen Sicherheitsprotokolle und darf keinesfalls mit Verschlüsselung gleichgesetzt werden. Ein sicher betriebenes MQTT-System benötigt TLS für die Transportverschlüsselung, Authentifizierung am Broker, gegebenenfalls Client-Zertifikate, Topic-basierte Zugriffsrechte sowie Netzsegmentierung und abgestimmte Firewall-Regeln. Wer einen Broker im Gebäudenetz betreibt, übernimmt damit Verantwortung für einen zentralen Knoten, über den sämtliche Zustands- und Messdaten laufen.

Für Betreiber gilt in beiden Fällen: Sicherheitsanforderungen, Zertifikatsverwaltung und Zuständigkeiten zwischen Elektro-, MSR- und IT-Gewerk gehören schriftlich in die Planung und die Vergabeunterlagen. Werden sie dort nicht festgelegt, bleibt offen, wer für eine unsichere Konfiguration haftet, und die Klärung verlagert sich in die Phase der Inbetriebnahme, in der Änderungen am teuersten sind.

Welches Protokoll für welchen Anwendungsfall

Fertigung, Prozess- und Versorgungstechnik

OPC UA ist dort stark, wo Steuerungen, Antriebe und Leitsysteme strukturiert und bidirektional miteinander kommunizieren müssen. Der Standard ist in viele moderne SPSen, CNC-Steuerungen und SCADA-Systeme integriert und findet sich vor allem in großen SCADA-Umgebungen und Fertigungsanlagen, weniger in kleinen, energiesparenden Sensoren. Wer Messwerte aus Anlagen zusätzlich in Instandhaltungssysteme überführen will, profitiert von typisierten Daten, wie sie auch eine MES-Anbindung in der Instandhaltung voraussetzt.

Gebäudeautomation und TGA

In der Gebäudetechnik sind BACnet, KNX, Modbus, M-Bus oder DALI die etablierten Feld- und Automationsprotokolle; OPC UA und MQTT treten typischerweise als Integrationsschicht hinzu. Wie heterogen eine solche Landschaft im Bestand sein kann, zeigt die Modernisierung der Gebäudeleittechnik im Frankfurter MAIN TOWER: Das Migrationskonzept für 750 Elektroverteiler deckt unter anderem BACnet, KNX, LonWorks, Modbus, OPC DA, OPC UA und Profinet ab. Ein weiteres Beispiel ist die Überwachung von Schranksystemen im Rechenzentrum, bei der Messwerte per OPC UA zugleich der IT und der Gebäudetechnik bereitgestellt werden. Die Abgrenzung zwischen Leittechnik der Anlage und Gebäudeleittechnik erläutert IET-Berlin ausführlich im Beitrag SCADA und BMS im Vergleich.

Energiemanagement, Submetering und Cloud-Anbindung

MQTT spielt seine Stärken aus, wenn viele verteilte Quellen ihre Werte an mehrere Abnehmer liefern sollen: Zählerdaten an das Energiemanagement, Zustände an das Dashboard, Zeitreihen an einen Historian oder eine Cloud-Plattform. Der Hauptanwendungsfall ist die Integration von OT-Datenquellen in IT- und Cloud-Systeme. Für ein Energiemanagement nach ISO 50001 sind durchgängige Messreihen die Grundlage; wie sich IoT-Telemetrie für ISO-50001-Audits aufbereiten lässt, zeigt ein Praxisbeitrag zur Auditvorbereitung. Wie Messkonzepte rechtssicher aufgebaut werden, beschreibt IET-Berlin im Beitrag zur Submetering-Planung; die Kette aus Zähler, Gateway und Steuerung im Wohngebäude behandelt der Artikel zu Smart Meter Gateway, Steuerbox und HEMS.

OPC UA und MQTT gemeinsam: die typische Architektur

MQTT ist kein Gegenentwurf zu OPC UA, sondern eine im OPC-UA-Standard vorgesehene Transportschicht. Teil 14 (PubSub) beschreibt, wie OPC-UA-Nachrichten über Publish/Subscribe-Protokolle wie MQTT übertragen werden, und ordnet die Zustellgarantien zu: „AtLeastOnce“ entspricht MQTT QoS 1, „ExactlyOnce“ entspricht QoS 2. Eine bewährte Architektur folgt dieser Kette:

Feld- und Automationsebene: Steuerungen, Zähler und Automationsstationen kommunizieren über ihre Feldprotokolle (zum Beispiel BACnet, Modbus, M-Bus) oder stellen Daten direkt per OPC UA bereit.
OPC UA an der Anlage: Ein OPC-UA-Server liefert die Daten strukturiert, mit Einheit, Zeitstempel und Qualitätskennzeichen.
Edge-Gateway: Das Gateway liest per OPC UA, normalisiert die Werte und übersetzt sie in ein festgelegtes Topic- und Payload-Schema.
MQTT-Broker: Der Broker verteilt die Nachrichten abgesichert per TLS und mit Topic-Rechten an alle berechtigten Abonnenten.
Abnehmer: Energiemanagement, Historian, Dashboard, Instandhaltung oder Cloud-Plattform abonnieren nur die benötigten Topics.

Der kritische Punkt dieser Architektur ist die Semantik zwischen Schritt 3 und 5. Die Open Industry 4.0 Alliance betont in ihrer Development Guideline for Open Edge Computing, dass für echte Interoperabilität nicht nur dieselben Protokolle, sondern auch dieselbe Semantik verwendet werden muss; sie setzt MQTT v3.1.1 als Message Bus ein und verwendet für die Nutzdaten das OPC-UA-PubSub-Format in JSON. Für Projekte bedeutet das: Ein verbindliches Topic- und Datenpunktschema ist eine Planungsleistung und kein Detail, das der ausführenden Firma überlassen werden sollte.

Was in Planung und Leistungsverzeichnis gehört

Die Protokollfrage entscheidet sich nicht in der Inbetriebnahme, sondern in den frühen Leistungsphasen. Folgende Punkte sollten Bauherren und Generalplaner verbindlich festlegen lassen:

Datenpunktliste: Welche Mess-, Zähl- und Zustandswerte werden benötigt, in welcher Auflösung, mit welcher Einheit und für welchen Abnehmer?
Schnittstellenbeschreibung: Welche Anlage stellt Daten per OPC UA bereit, wo sitzt das Gateway, welcher Broker verteilt die Daten, und wer betreibt ihn?
Semantik: Verbindliches Topic-Schema bzw. OPC-UA-Informationsmodell einschließlich Benennungskonvention über alle Gewerke.
Sicherheitsvorgaben: Sicherheitsprofile für OPC UA, TLS und Authentifizierung für MQTT, Zertifikatsverwaltung, Netzsegmentierung.
Gewerkegrenzen: Zuständigkeiten zwischen Elektrotechnik, MSR, Gebäudeautomation und IT, einschließlich Abnahmekriterien.
Zukunftsfähigkeit: Reserven für zusätzliche Abnehmer wie Photovoltaik, Ladeinfrastruktur oder Lastmanagement.

Fehlen diese Festlegungen in der Ausführungsplanung, entstehen Nachträge, Schnittstellenlücken und Zuständigkeitskonflikte, deren Folgen der Bauherr trägt. Warum gerade diese Leistungsphase den Verlauf der Baustelle bestimmt, erläutert der Beitrag Die Ausführungsplanung entscheidet über den Verlauf der Baustelle.

Unsere Sicht: Die Protokollwahl ist eine Planungsaufgabe

In unseren Projekten erleben wir, dass die Frage „MQTT oder OPC UA“ häufig zu spät gestellt wird: dann, wenn Anlagen bereits bestellt sind und das Energiemanagement Daten erwartet, die niemand verbindlich beschrieben hat. Aus unserer Sicht ist die Wahl des Protokolls keine IT-Detailfrage, sondern Teil eines durchdachten Energie- und Datenkonzepts, das bereits in der Grundlagenermittlung und Vorplanung beginnt.
Wir planen elektrotechnische Anlagen so, dass Messkonzept, Zählerstruktur, Schnittstellen und Verantwortlichkeiten von Anfang an zusammenpassen. Dazu gehört, festzulegen, wo OPC UA die strukturierte Bereitstellung an der Anlage übernimmt und wo MQTT die Daten an Energiemanagement, Photovoltaik-Monitoring oder Lastmanagement für die Ladeinfrastruktur verteilt. Diese Festlegungen überführen wir in Pläne, Leistungsverzeichnisse und Kostenkalkulationen, damit die ausführenden Firmen auf einer eindeutigen Grundlage anbieten.
Unser Anspruch ist eine elektrische Infrastruktur, die über den Tag der Abnahme hinaus erweiterbar bleibt. Wer die Datenkommunikation sauber plant, vermeidet spätere Umbauten und schafft die Grundlage für ein nachhaltiges Energiekonzept.
Alexander Blau

Datenkommunikation von Anfang an mitplanen

IET-Berlin begleitet Bauherren, Architekten, Generalunternehmer und öffentliche Auftraggeber in Berlin, Brandenburg und bundesweit von der Grundlagenermittlung bis zur Objektbetreuung. In der Beratung zum Energiemanagement entwickelt das Team individuelle Energiekonzepte, in denen Messung, Datenerfassung und Schnittstellen zu Photovoltaik und Ladeinfrastruktur aufeinander abgestimmt sind.

Planen Sie einen Neubau, einen Umbau oder die Modernisierung einer Liegenschaft mit Gebäudeautomation und Energiemonitoring? Sprechen Sie uns an, damit Schnittstellen und Datenkonzept rechtzeitig in die Planung einfließen.

Häufige Fragen

Kann MQTT OPC UA ersetzen?

Nicht vollständig. MQTT transportiert Nachrichten effizient, liefert aber kein Informationsmodell, keine Methodenaufrufe und keine im Standard verankerte Anwendungssicherheit. In den meisten Projekten ergänzen sich beide Protokolle: OPC UA an der Anlage, MQTT für die Verteilung an viele Abnehmer.

Ist MQTT schneller als OPC UA?

MQTT erzeugt durch seinen kleinen Protokoll-Overhead und das Publish/Subscribe-Prinzip wenig Netzlast und skaliert gut bei vielen Empfängern. Die tatsächliche Latenz hängt jedoch von Netz, Broker, QoS-Stufe und Gateway ab. Für die strukturierte Kommunikation an der Steuerung ist OPC UA ausgelegt; ein pauschaler Geschwindigkeitsvergleich führt daher selten zur richtigen Entscheidung.

Ist MQTT ohne Zusatzmaßnahmen sicher?

Nein. MQTT definiert keine eigenen Sicherheitsprotokolle. Erforderlich sind TLS-Verschlüsselung, Authentifizierung am Broker, Topic-basierte Rechte sowie Netzsegmentierung und Firewall-Regeln, die bereits in der Planung festgelegt werden sollten.

Welche Rolle spielen die beiden Protokolle in der Gebäudeautomation?

Auf Feld- und Automationsebene dominieren BACnet, KNX, Modbus oder M-Bus. OPC UA und MQTT kommen vor allem als Integrationsschicht hinzu, etwa um Daten der Gebäudeleittechnik an Energiemanagement, IT oder Cloud-Plattformen weiterzugeben.