OPC UA vs. MQTT (ein Vergleich der wichtigsten Eigenschaften)

Inhalt

Im Bereich der industriellen Automatisierung stechen zwei Technologien aufgrund ihrer weiten Verbreitung und spezifischen Fähigkeiten hervor: OPC Unified Architecture (OPC UA) und Message Queuing Telemetry Transport (MQTT). Beide Protokolle spielen eine entscheidende Rolle bei der Vernetzung von OT Geräten und IT Anwendungen. Allerdings bedienen OPC UA und MQTT auf Basis ihrer spezifischen Eigenschaften unterschiedliche Anforderungen und Anwendungsfälle. Der folgende Artikel arbeitet daher die wesentlichen Unterschiede von OPC UA vs. MQTT im Hinblick auf diese Eigenschaften heraus.

 

Grundlagen von OPC UA

OPC UA (Open Platform Communications Unified Architecture) ist ein Kommunikationsstandard, welcher von der OPC Foundation entwickelt wurde. Dieser Standard wurde für den sicheren, zuverlässigen und plattformunabhängigen Datenaustausch in industriellen Automatisierungssystemen konzipiert. Dabei unterstützt OPC UA komplexe Datentypen und Objektmodelle. Diese Fähigkeit ermöglicht es, komplexe industrielle Prozesse zu unterstützen. Detaillierte Informationen zu OPC UA finden Sie hier.

Die OPC UA Schlüsselfunktionen sind:

  1. Informationsmodellierung: Unterstützt umfangreiche Informationsmodellierung inkl. strukturierte Datentypen, objektorientierte Modelle und komplexe Datenstrukturen.
  2. Integrierte Sicherheitsmechanismen: Bietet integrierte Sicherheitsfunktionen, einschließlich Authentifizierung, Autorisierung, Verschlüsselung und Datenintegrität.
  3. Plattformunabhängige Kommunikation: OPC UA unterstützt sowohl Client-Server- als auch Publish-Subscribe-Kommunikationsmodelle und kann auf embedded Geräten ebenso wie in großen Server-Infrastrukturen eingesetzt werden.

 

Grundlagen von MQTT

MQTT (Message Queuing Telemetry Transport) ist ein leichtgewichtiges Messaging-Protokoll, das ursprünglich für Netzwerke mit geringer Bandbreite und hoher Latenz entwickelt wurde. Dies ist insbesondere in IoT-Szenarien (z.B. Integration externer Sensorik) relevant. Von IBM entwickelt, basiert MQTT auf einem Publish/Subscribe-Modell. Dies macht den Standard sehr skalierbar und effizient in der Verteilung von Informationen an eine Vielzahl von Abonnenten. Mehr Informationen finden Sie hier.

Die Schlüsselfunktionen von MQTT sind:

  1. Effizienz: Leichtgewichtiges Protokoll mit minimaler Datenübertragung, ideal für Anwendungsfälle mit Einschränkungen im Netzwerk oder auf den IoT Geräten.
  2. Entkopplung: Das Publisher- und Subscriber-Modell ermöglicht eine Entkopplung zwischen Geräten und Anwendungen.
  3. Skalierbarkeit: Einfache Skalierung möglich, um Tausende bis Millionen von Geräten und Abonnenten zu unterstützen.

 

 

OPC UA vs. MQTT

OPC UA und MQTT sind für verschiedene industrielle Anwendungsbereiche konzipiert und daher nicht direkt vergleichbar. Die Unterschiede spiegeln sich unter anderem in folgenden wichtigen Eigenschaften der beiden Standards wider.

 

1. Integrationsaufwand: OPC UA vs. MQTT

OPC UA weist mit über 1200 Seiten eine sehr umfangreiche Spezifikationen auf, die eine breite Palette von Funktionen in der industriellen Automatisierung abdecken. MQTT hingegen konzentriert sich auf eine kleine Anzahl von Kernspezifikationen (ca. 80 Seiten), die auf Effizienz und Einfachheit in IoT-Szenarien ausgerichtet sind. Die Unterschiede in der Anzahl und Art der Spezifikationen spiegeln die unterschiedlichen Designziele und Anwendungsfelder wider. Der Unterschied im Umfang schlägt sich auch im Integrationsaufwand der beiden Standards nieder.

MQTT vs. OPC UA Specifications

OPC UA: Die OPC UA-Spezifikationen sind in mehrere Teile untergliedert, die verschiedene Aspekte der OPC Architektur behandeln. Diese Aufteilung zeigt, dass OPC UA nicht nur ein einfaches Datenübertragungsprotokoll ist, sondern ein umfassendes Framework für die Kommunikation in industriellen Systemen. Dieses umfasst unter anderem Sicherheit, Datenmodellierung, Zustandsmanagement und historischen Datenzugriff. Ein Großteil hiervon ist optional. D.h. es wird dem Anwender überlassen, welcher Teil der Spezifikation implementiert wird und welcher nicht. Aufgrund des jahrzehntelang gewachsenen Standards und dessen Breite ist die Implementierung in der Praxis komplex und aufwendig. Nicht zuletzt ein Grund, weshalb die meisten Systeme lediglich einen kleinen Teil des Standards nutzen.

MQTT: Im Gegensatz zu OPC UA ist MQTT ein einfaches und leichtgewichtiges Protokoll. Es besteht im Wesentlichen aus zwei Dokument mit ca. 80 Seiten (MQTT 3 und die neuere Version des Standards MQTT 5), welche sich hauptsächlich auf die Kernelemente des Protokolls konzentrieren. Aufgrund dieser Tatsache, ist die Integration deutlich einfacher und erfordert in der Regel deutlich weniger Ressourcen.

 

2. Kommunikationsmodell: OPC UA vs. MQTT

Im Bereich der Kommunikationsmodelle unterscheiden sich OPC UA und MQTT grundlegend in ihrer Architektur, was erhebliche Auswirkungen auf ihre Anwendung und Leistungsfähigkeit in industriellen Umgebungen hat.

OPC UA vs. MQTT Communication Model

OPC UA Client/Server: verwendet im Kern ein Client-Server-Modell. In dieser „Eins-zu-Eins“ Topologie fordert ein Client Daten vom einem Server an und der Server antwortet mit den geforderten Daten (Poll-Response). Während Clients mit vielen Servern gleichzeitig interagieren können, können Server viele Clients bedienen. Die Client/Server Architektur ist insbesondere in Automatisierungsszenarien geeignet, in denen eine direkte synchrone Kommunikation (z.b. für closed-loop, command & control) zwischen wenigen Systemen erforderlich ist.

MQTT minimiert die Bandbreitennutzung, indem es von einer konventionellen „Poll-Response“ Verhalten (wie z.B. bei der OPC UA Client-Server Architektur) zu einem event-basierten „Publish-Subscribe“ Verhalten übergeht. In diesem Modell wird die Kommunikation durch einen Broker entkoppelt, der Nachrichten asynchron zwischen den Teilnehmern vermittelt. Event-basiert bedeutet, ein Datenkonsument wartet auf Datenänderungen (anstelle diese zyklisch abzufragen), was eine ereignisgesteuerte Kommunikation zwischen Geräten und Anwendungen ermöglicht. Aufgrund dieser Eigenschaften ist die Pub/Sub Architektur besonders in Skalierungsszenarien mit Dutzenden bis Millionen von Datenproduzenten und -abonnenten geeignet.

OPC UA Publisher/Subscriber (Pub/Sub), Teil 14 der Spezifikation, wurde erstmals im Jahr 2017 als Ergänzung zum ursprünglichen Client/Server-basierten Kommunikationsmodell veröffentlicht. Pub/Sub adressiert insbesondere die Limitierung in der Skalierbarkeit des Client/Server Modelle und wurde entwickelt, um den wachsenden Bedarf an effizienten und leichtgewichtigen Kommunikationsmechanismen für IoT Anwendungen zu adressieren. Es ist allerdings wichtig zu erwähnen, dass OPC UA Pub/Sub auf Standard Pub/Sub Protokollen wie MQTT oder AMQP basiert.

 

3. Sicherheit: OPC UA vs. MQTT

Während MQTT den Nutzern Flexibilität in der Sicherheitsimplementierung bietet, verfügt OPC UA über integrierte Sicherheitsmechanismen, die eine breite Palette von Sicherheitsaspekten abdecken. Beide Herangehensweisen bieten Vorteil, setzen allerdings entsprechendes Know-how beim Anwender voraus.

OPC UA vs. MQTT Security Architecture

MQTT definiert keine eigenen Sicherheitsprotokolle. Stattdessen überlässt MQTT die Implementierung der Sicherheit auf der TCP/IP-Ebene. Das bedeutet, dass der Anwender selbst zwischen passenden Sicherheitsmodellen wie TLS/SSL oder Zertifikaten wählen kann. Zudem bietet der MQTT Standard keine spezifische Maßnahmen für Benutzer- und Applikationssicherheit, was oft durch zusätzliche Sicherheitsimplementierungen auf Anwendungsebene kompensiert wird. Während die Möglichkeit zur Nutzung von anerkannten Standards wie TLS/SSL die Implementierung einer sicheren MQTT Architektur grundsätzlich erleichtern, so bedarf es dennoch zusätzlichem Aufwand auf Anwendungsebene.

OPC UA bietet demgegenüber eine integrierte Sicherheitslösung, die Benutzer-, Applikations- und Transportsicherheit umfasst. Diese Sicherheitsarchitektur von OPC UA unterstützt Authentifizierung, Autorisierung sowie Verschlüsselung und Datenintegrität. Dies kann das Protokoll zu einer robusten Wahl für industrielle Automatisierungssysteme machen. Allerdings nur, sofern richtig implementiert und konfiguriert. Und genau hier liegt in der Praxis häufig das Problem. Aufgrund des Umfangs und der Komplexität von OPC UA, finden sich in der Praxis häufig schwache Sicherheitsimplememtierungen wider.

 

4. Interoperabilität: OPC UA vs. MQTT

Interoperabilität ist ein beliebtes Buzzwort. Und leider wird der Begriff von denjenigen, die Interoperabilität bewerben, häufig nicht verstanden. Tatsächlich garantieren weder OPC UA noch MQTT für sich genommen echte Interoperabilität in der Praxis. Zur Veranschaulichung dieser Herausforderung ziehen wir das „Data Access Model“ von Matthew Parris (Quelle) heran, das die entscheidenden Ebenen für die Interaktion zwischen Datenquellen und -konsumenten im industriellen Umfeld definiert. Interoperability: OPC UA vs. MQTT

Dabei gilt:

  • Undefinierte Ebenen begünstigen die Flexibilität auf Kosten eines höheren Integrationsaufwands, da jede Implementierung individuell interpretiert und integriert werden muss.
  • Mehrere Optionen auf einer Ebene begünstigen die Flexibilität auf Kosten eines höheren Integrationsaufwands, da verschiedene Implementierungen individuell integriert werden müssen.

 

Level 0 – Transport

Diese Ebene definiert die grundlegenden Transportmechanismen, die zur Datenübertragung zwischen Systemen notwendig sind. Während MQTT TCP/IP oder Websockets für eine leichte und effiziente Datenübertragung nutzt, ermöglicht OPC UA weitere Transportmöglichkeiten. Die Auswahl des Transportmechanismen wird dabei je nach Bedürfnissen und technischen Anforderungen dem Anwender überlassen.

 

Level 1 – Protocol

Diese Ebene betrifft die konkrete Implementierung und Anwendung des Kommunikationsprotokolls selbst. MQTT setzt auf ein einfaches Publish/Subscribe-Modell, das hohe Flexibilität und Skalierbarkeit bietet, jedoch wenig hinsichtlich Sicherheitsfeatures und Fehlerbehandlung spezifiziert. OPC UA hingegen definiert ein komplexeres Protokoll, das nicht nur Publish/Subscribe, sondern auch Session-Management, Authentifizierung und verschlüsselte Kommunikation umfasst.

 

Level 2 – Mappings

Diese Ebene legt die spezifischen Protokoll-Mappings fest. Diese bestimmen, wie Daten innerhalb des gewählten Kommunikationsprotokolls strukturiert und übermittelt werden. Während MQTT dies dem Anwender überlässt (z.B. Konventionen für Topic Namespaces), beinhaltet die OPC UA Spezifikation detaillierte Informationsmodelle, die die Struktur der Daten exakt definieren.

 

Level 3 – Encoding

Diese Ebene definiert die für die Übertragung über das Netzwerk notwendig Kodierung der Daten. Dies umfasst die Wahl des Datenformats, das sowohl die Effizienz der Übertragung als auch die Kompatibilität zwischen unterschiedlichen Systemen definiert. Während MQTT das Encoding der Daten dem Anwender überlässt, spezifiziert OPC UA Encodings wie Binär, XML und JSON. Die Auswahl des geeigneten Encodings wird dabei je nach Bedürfnissen und technischen Anforderungen dem Anwender überlassen.

 

Level 4 – Values

Diese Ebene legt die Datentypen für die Datenübertragung fest. Dabei ist eine klare Spezifikation von Datentypen essentiell für die korrekte Interpretation und Nutzung der Daten durch unterschiedliche Systeme. Während MQTT dies dem Anwender überlässt, spezifiziert OPC UA 60 sogenannter “Base Types” und ermöglicht dem Anwender individuelle komplexe Types zu ergänzen.

 

Level 5 – Objects

Diese Ebene definiert Datenmodelle und -schemata, d.h. wie Daten als Objekte organisiert sind, einschließlich ihrer Attribute und Methoden. Dies ist insbesondere für die Anwendungslogik relevant. Während MQTT dies dem Anwender überlässt, spezifiziert OPC UA diese Modelle für den Anwender über sogenannte Companion Spezifikationen.

 

Zusammengefasst: MQTT ist nicht gleich MQTT , OPC UA ist nicht gleich OPC UA

MQTT: Da der Standard wesentliche Ebenen nicht spezifiziert, ist die Implementierung dem Anwender überlassen. Dies mag zunächst deutlich flexibler und einfacher erscheinen, führt jedoch zu individuellen Implementierungen. Zwei MQTT fähige Systeme müssen daher auf diesen Ebenen individuell integriert werden. Abhilfe hierbei schafft der neuer Standard “Sparkplug B”. Mehr Informationen finden Sie hier.

OPC UA: Der Standard wurde ursprünglich zwar für die plattformübergreifende Kompatibilität entwickelt, um Kommunikation über verschiedene Hardwaresysteme hinweg zu erleichtern. Aber: Aufgrund der hohen Anzahl an optionalen und alternativen Spezifikationen sowie der gewachsenen Komplexität, sind typischerweise verschiedene Teile und Versionen des Standards implementiert. Zwei OPC UA fähige Systeme sind daher nur mit sehr viel Glück wirklich interoperabel.

 

5. Skalierbarkeit: OPC UA vs. MQTT

Die Skalierbarkeit ist ein entscheidender Aspekt in der Auswahl des richtigen Kommunikationsprotokoll. Dies gilt insbesondere in Umgebungen, in der die Anzahl vernetzter Geräte stetig steigt.

OPC UA: Die Skalierbarkeit von OPC UA kann in großen industriellen Umgebungen herausfordernd sein. Dies gilt insbesondere dann, wenn eine Vielzahl von Geräten und Systemen für den Datenaustausch vernetzt werden. Neben der traditionellen Client/Server-Struktur von OPC UA limitiert die Komplexität des Standards und dessen Implementierung eine Skalierung erheblich. Um die Skalierbarkeit zu verbessern, unterstützt OPC UA auch ein Publish/Subscribe-Modell (Pub/Sub). Dies wurde in der jüngeren Spezifikation Teil 14 eingeführt. Hierbei kommen Broker wie AMQP oder MQTT zum Einsatz, welche die effiziente Verteilung der Nachrichten an viele Abonnenten garantieren.

MQTT: MQTT hingegen wurde mit Blick auf Leichtigkeit und Effizienz entworfen. Es ist ideal für Szenarien, in denen Tausende bis Millionen von Geräten effizient unterstützt werden müssen. Das Publish/Subscribe-Modell von MQTT minimiert den Netzwerkverkehr und reduziert die Ressourcenbelastung erheblich. Zudem machen die Einfachheit und Effizienz MQTT besonders geeignet in Skalierungsszenarien. Allerdings muss der Anwender während der Skalierung aufgrund der fehlenden Tiefe des Standards (siehe Interoperabilitäts-Layer) zwingend die bestehenden Lücken selbst füllen. Dies inkludiert u.a. die Nutzung weiterer Standards (z.B. Sparkplug B) oder die Beschreibung eigener Standards.

 

Fazit

Sowohl OPC UA als auch MQTT spielen eine entscheidende Rolle im Ökosystem der industriellen Automatisierung und der OT/IT Vernetzung. Jedoch führen weder OPC UA noch MQTT heute in der Praxis zu interoperablen System Architekturen. Während hierfür die bewusst fehlende Tiefe der MQTT Spezifikation nicht ausgelegt ist, führt bei OPC UA in der Praxis die Komplexität und der Umfang der Spezifikation zu Interoperabilitätsproblemen.

Die Wahl zwischen OPC UA und MQTT hängt größtenteils von den spezifischen Anforderungen der jeweiligen Anwendung ab. Für komplexe industrielle Anwendungen, die eine detaillierte Datenmodellierung und robuste Sicherheit erfordern, ist OPC UA das bevorzugte Protokoll. Im Gegensatz dazu bietet MQTT eine optimale Lösung für die leichte, effiziente Datenübertragung in Umgebungen mit Dutzenden bis Millionen von Datenproduzenten und -abonnenten. Aufgrund dieser spezifischen Stärken werden die beiden Technologien im Rahmen der Industrial Unified Namespace Architektur (UNS) immer häufiger kombiniert eingesetzt, um eine effiziente und zuverlässige Datenkommunikation zwischen OT und IT zu gewährleisten.

Über i-flow: i-flow ist ein Unternehmen für industrielle Software mit Sitz in Süddeutschland. Wir bieten produzierenden Unternehmen die weltweit intuitivste Software zur Vernetzung von Fabriken. Täglich über 400 Millionen Datenoperationen in produktionskritischer Umgebung demonstrieren nicht nur die Skalierbarkeit der Software, sondern auch das tiefe Vertrauen, das unsere Kunden in i-flow setzen. Unser Erfolg basiert auf enger Zusammenarbeit mit Kunden und Partnern weltweit, darunter namhafte Fortune-500-Unternehmen und Branchenführer wie Bosch.

Jetzt selbst ausprobieren - Kostenlose Testversion

Überzeugen Sie sich in einem Test selbst von den unbegrenzten Möglichkeiten, die Sie mit i-flow erhalten. Jetzt 30 Tage kostenfrei testen, auf Ihren Systemen.

Ihre Frage wurde nicht be­antwortet? Kontaktieren Sie uns.

Es gilt unsere Datenschutzerklärung.

Ihr Kontakt:

Marieke Severiens (i-flow GmbH)
content@i-flow.io