MQTT, OPC UA und Unified Namespace

WISSEN | Industrial Data

MQTT, OPC UA und Unified Namespace: Drei Dinge, die ständig durcheinandergeworfen werden

OPC UA, MQTT und Unified Namespace werden oft in einen Topf geworfen. Das ist problematisch, weil sie unterschiedliche Aufgaben lösen.
OPC UA hilft dabei, industrielle Daten strukturiert bereitzustellen. MQTT verteilt Informationen. Der Unified Namespace definiert, wie diese Informationen gemeinsam organisiert und genutzt werden.
Klingt einfach. In Projekten wird genau das trotzdem ständig vermischt. Und dann wird aus einem MQTT-Broker plötzlich ein „UNS“ – obwohl eigentlich nur Daten verschoben wurden.

Von Martin Waßmann – IT/OT Experts

Bei kaum einem Thema werden Begriffe so schnell vermischt wie beim Unified Namespace.

Da wird ein MQTT-Broker installiert und plötzlich gibt es einen UNS. Eine Maschine hat OPC UA und damit ist sie „angebunden“. Oder MQTT und OPC UA werden gegeneinander gestellt, als müsste man sich für eines von beiden entscheiden.

Das führt in Projekten schnell in die falsche Richtung.
Denn OPC UA, MQTT und Unified Namespace lösen unterschiedliche Probleme.

Sie können sehr gut zusammenspielen. Aber nur, wenn klar ist, wofür welches Element überhaupt da ist.
Die Kurzfassung:

  • OPC UA hilft mir, industrielle Daten bereitzustellen und zu verstehen.
  • MQTT hilft mir, Informationen zu verteilen.
  • Der Unified Namespace definiert, wie diese Informationen organisationsweit strukturiert und nutzbar werden.
  • Und ja: Das ist bewusst vereinfacht. Aber für Architekturentscheidungen ist diese Trennung wichtiger als die nächste Diskussion über Broker-Features.

Kurz erklärt

OPC UA ist ein industrieller Kommunikationsstandard, der nicht nur Werte übertragen, sondern auch Strukturen, Datentypen und semantische Informationen beschreiben kann.

MQTT ist ein leichtgewichtiges Publish/Subscribe-Protokoll. Ein Publisher veröffentlicht Nachrichten zu Topics, ein Broker vermittelt sie, Subscriber abonnieren die für sie relevanten Informationen.

Ein Unified Namespace ist dagegen kein Protokoll. Er beschreibt eine gemeinsame Informations- und Architekturstruktur, über die industrielle Informationen konsistent bereitgestellt und genutzt werden können.

Deshalb sind die drei Begriffe nicht austauschbar.

OPC UA: Holt doch nur Daten aus der Steuerung, oder?

Diese Vereinfachung stimmt nicht!

Ein großer Vorteil von OPC UA ist, dass Daten nicht zwingend nur als anonyme Adressen bereitgestellt werden müssen.
Eine Steuerung oder ein OPC-UA-Server kann beispielsweise Strukturen, Objekte, Variablen, Datentypen und Beziehungen bereitstellen.

Beispiel – Statt nur:

DB17.DBD24

kann eine Anwendung im besten Fall etwas bekommen, das bereits fachlich wesentlich näher an der Maschine liegt:

FillingMachine

  • State
  • Speed
  • GoodCount
  • RejectCount

Das ist ein großer Unterschied. Vor allem dann, wenn man nicht eine Maschine integrieren möchte, sondern irgendwann hundert(e).
Aber auch hier gilt: Nur weil eine Maschine OPC UA spricht, ist ihre Datenstruktur noch lange nicht automatisch gut.

Ich habe genügend OPC-UA-Server gesehen, bei denen letztlich einfach SPS-Variablen in einer etwas schöneren Oberfläche angeboten werden.
Technischer Zugriff ist dann vorhanden.
Ein brauchbares Informationsmodell sucht man häufig vergebens.


MQTT: Daten verteilen, ohne jeden direkt mit jedem zu verbinden

MQTT löst ein anderes Problem.
Klassische Integrationen sehen häufig so aus:

Maschine → OEE
Maschine → Reporting
Maschine → MES
Maschine → Analytics

Jede neue Anwendung baut eine weitere Verbindung zur Datenquelle.
Mit einem Publish/Subscribe-Modell lässt sich diese direkte Kopplung reduzieren. Eine Datenquelle veröffentlicht beispielsweise:

site1/line2/machine5/state

und verschiedene Anwendungen können genau diese Information abonnieren. Die Maschine muss nicht wissen, ob dahinter OEE, Reporting oder ein KI-Modell sitzt. Das ist stark. Vor allem bei steigender Zahl von Datenquellen und Anwendungen.
Aber MQTT beantwortet zunächst nur:

Wie verteile ich Nachrichten?

MQTT beantwortet nicht automatisch:

  • Wie benennen wir Anlagen?
  • Welche Informationen gehören zu einer Maschine?
  • Was bedeutet state = 2?
  • Welche Struktur gilt an allen Standorten?
  • Wer darf Topics verändern?
  • Welche Information ist verbindlich?

Und genau deshalb ist der Satz wichtig:

MQTT ist ein sehr gutes Transportmittel. Aber ein Transportmittel definiert noch keine Datenarchitektur.


Der Broker ist nicht der Unified Namespace

Das ist vermutlich der häufigste Denkfehler. Und ich wiederhole es gern.
Szenario:

  1. Es wird ein MQTT-Broker installiert.
  2. Maschinen oder Gateways veröffentlichen Daten.
  3. Anwendungen abonnieren Topics.
  4. Und das Ganze bekommt das Label „Unified Namespace“.

Technisch kann das hervorragend funktionieren aber trotzdem muss es noch lange kein sinnvoller UNS sein.

Ein Praxisbeispiel:

machine01/db17/tag27
machine02/plc/status_1
line3/maschine4/var_127
site-b/packaging/m5/state

Alles liegt auf demselben Broker. Alles ist erreichbar. Und trotzdem hat niemand etwas vereinheitlicht.
Dann wurde zwar die Transportarchitektur zentralisiert – die semantische Komplexität aber einfach auf den Broker verschoben.

Ein gemeinsamer Broker ist nicht automatisch ein gemeinsames Informationsmodell.
Das ist der Punkt, an dem viele UNS-Diskussionen aus meiner Sicht zu technisch anfangen.


Wo kommt nun der Unified Namespace ins Spiel?

Ein Unified Namespace versucht, eine verbindliche Struktur für relevante industrielle Informationen zu schaffen.
Beispielsweise:

Enterprise

└─ Site

└─ Area

└─ Line

└─ Asset

├─ State

├─ Production

├─ Quality

└─ Energy

Ob genau diese Hierarchie richtig ist, hängt vom Unternehmen ab.
Das Entscheidende ist etwas anderes:

Eine Anwendung soll Informationen nicht aus herstellerspezifischen Strukturen erraten müssen.

Sie soll wissen, wo sie Informationen findet, wie sie heißen und was sie bedeuten. Damit passiert konzeptionell Folgendes:

Maschinenwelt

unterschiedlich, technisch, herstellerspezifisch

↓

Integration / Mapping / Kontext

↓

Unified Namespace

einheitlich, verständlich, wiederverwendbar

↓

OEE | MES | Reporting | Analytics | KI

Genau diese mittlere Schicht wird gerne unterschätzt.
Denn irgendjemand muss entscheiden, wie aus technischen Maschinendaten eine organisationsweit nutzbare Information wird.


Also OPC UA unten und MQTT oben?

Das wäre eine schöne eine schöne Vereinfachung – entspricht aber nicht der Realität. Eine Maschine kann OPC UA sprechen. Eine andere vielleicht Modbus TCP. Eine ältere Anlage wird über S7 angebunden. Ein anderes System bietet eine REST-API. Und vielleicht veröffentlicht ein moderner Edge-Controller bereits direkt MQTT, lässt aber keine Konfiguration der Strukturen zu.

Das ist Brownfield.

Deshalb würde ich die Architektur nicht vom gewünschten Protokoll rückwärts planen. Die Maschine sollte über den sinnvollsten verfügbaren Weg integriert werden. Das kann OPC UA sein. Muss es aber nicht.

Entscheidend ist anschließend, dass die bereitgestellte Information in die gemeinsame Struktur passt. Oder in kurz:

Die Integration zur Maschine darf heterogen sein. Die Informationsstruktur darüber sollte es möglichst nicht mehr sein.

Das ist für mich wesentlich wichtiger als „OPC UA oder MQTT?“.


MQTT oder OPC UA? In der Frage steckt das Problem.

Die Frage taucht in regelmäßigen Abständen auf:
Sollen wir OPC UA oder MQTT verwenden?

In den meisten Fällen lautet die Antwort:
Beides. Für unterschiedliche Aufgaben.

Beispielsweise:

SPS / Maschine

↓

OPC UA

↓

Edge / Integration

↓

MQTT

↓

Unified Namespace

↓

Anwendungen

Das ist nur eine mögliche Architektur, aber eine sehr verständliche. OPC UA kann dabei den strukturierten Zugriff auf Maschineninformationen liefern. Die Integrationsschicht entscheidet, welche Informationen benötigt werden und wie sie in die Zielstruktur überführt werden. MQTT verteilt sie anschließend ereignisbasiert an andere Systeme.
Und der UNS definiert, wie diese Informationen im größeren Kontext organisiert werden.

Es gibt keinen Wettbewerb zwischen OPC UA und MQTT. Es ist eine sehr praktische Arbeitsteilung.


Einwand: Aber OPC UA kann doch auch Pub/Sub?

Ja. Schön. (Unnötig dogmatisch)

OPC UA kann mehr als klassische Client/Server-Kommunikation und unterstützt ebenfalls Publish/Subscribe-Mechanismen.
MQTT kann wiederum wesentlich mehr transportieren als einfache Zahlenwerte.

Die Technologien überschneiden sich also teilweise.
Das ändert aber nichts an der eigentlichen Architekturfrage:

Welches Problem soll an welcher Stelle gelöst werden?

Wenn eine vorhandene Architektur Anforderungen mit OPC UA PubSub sauber erfüllt, muss niemand MQTT einführen, nur weil auf einer Konferenz jeder von UNS spricht.
Umgekehrt sollte man MQTT nicht ablehnen, nur weil OPC UA theoretisch ebenfalls Publish/Subscribe kann.

Architektur sollte aus Anforderungen entstehen – nicht aus Loyalität zu irgendeiner Technologie.


Ein Praxisbeispiel aus dem Brownfield

Nehmen wir eine Produktionslinie mit Maschinen unterschiedlicher Generationen.
Maschine A bietet einen gut strukturierten OPC-UA-Server.
Maschine B liefert zwar OPC UA, aber praktisch nur eine Liste technischer SPS-Tags.
Maschine C hat überhaupt keinen OPC-UA-Server und muss über ein anderes Protokoll integriert werden.

Für die Anwendungen darüber sollte dieser Unterschied möglichst keine Rolle mehr spielen. Alle drei Maschinen könnten anschließend beispielsweise dieselben Informationen bereitstellen:

  • State
  • CurrentOrder
  • GoodCount
  • RejectCount
  • Speed

Genau hier entsteht der eigentliche Mehrwert. Nicht dadurch, dass alle Maschinen dasselbe Protokoll sprechen. Sondern dadurch, dass unterschiedliche Maschinen am Ende dieselbe Sprache gegenüber den Anwendungen sprechen.

Das ist ein wesentlich realistischeres Ziel für Brownfield als die Vorstellung, man müsse zunächst jede Maschine technisch standardisieren.

Datenmodell. Datenmodell. Datenmodell. Topic Struktur?

Eine weitere typische Diskussion:
Wie soll unsere MQTT-Topic-Struktur aussehen?

Hier wird häufig viel zu früh über Syntax gesprochen. “enterprise / site / area / line / asset”.
Das sieht toll aus, kann aber dennoch schlechte Informationen transportieren.

Die entscheidende Fragen sind andere ->

  • Was ist bei uns überhaupt ein Asset?
  • Wie behandeln wir Linien und Teilanlagen?
  • Wo liegt ein Produktionsauftrag?
  • Wer besitzt einen Maschinenzustand?
  • Wie werden Qualitätsinformationen modelliert?
  • Wie gehen wir mit Versionen um?
  • Welche Informationen gehören dauerhaft in den UNS – und welche nicht?

Eine gute Topic-Struktur kann ein Informationsmodell sichtbar machen.
Sie ersetzt das Informationsmodell aber nicht.


Zusammenfassung in einem Satz

Wenn ich die drei Begriffe auf eine praktische Frage reduzieren müsste:

OPC UA:
Wie bekomme und verstehe ich industrielle Daten?

MQTT:
Wie verteile ich Informationen entkoppelt und ereignisbasiert?

Unified Namespace:
Wie organisiere ich diese Informationen so, dass sie unternehmensweit wiederverwendbar werden?

Das ist nicht technisch vollständig. Aber es verhindert ungefähr 80 Prozent der falschen Architekturgespräche.

Häufige Fragen

Ist MQTT Voraussetzung für einen Unified Namespace?

Nein. MQTT wird für UNS-Architekturen häufig eingesetzt, weil Publish/Subscribe und die Entkopplung von Datenquellen und Anwendungen sehr gut zum Konzept passen. Der Unified Namespace selbst ist aber kein MQTT-Standard.

Ist OPC UA besser als MQTT?

Die Frage greift zu kurz. Beide Technologien adressieren unterschiedliche Anforderungen und können gemeinsam eingesetzt werden.

Kann eine Maschine direkt in MQTT publizieren?

Ja. Ob das sinnvoll ist, hängt unter anderem davon ab, ob sie die benötigte Datenstruktur, Kontextinformationen, Security und Betriebsanforderungen zuverlässig unterstützt.

Muss ich OPC-UA-Daten eins zu eins in MQTT übertragen?

Nein. Genau das ist häufig nicht sinnvoll. Die Integrationsschicht kann relevante Informationen auswählen, normalisieren und in das gemeinsame Informationsmodell überführen.

Ist der MQTT-Broker die zentrale Datenbank eines UNS?

Nein. Ein MQTT-Broker vermittelt Nachrichten. Persistenz und Historisierung sind separate Anforderungen und sollten bewusst architektonisch gelöst werden.

Gehören alle Maschinendaten in den UNS?

Nein. Welche Daten veröffentlicht werden, sollte sich aus Anforderungen, Wiederverwendbarkeit und Verantwortlichkeiten ableiten – nicht aus dem Prinzip „wir sammeln erst einmal alles“.


Sie diskutieren gerade über UNS, MQTT oder eine neue Produktionsdatenplattform?

Bevor Technologie ausgewählt wird, sollte klar sein, welches Problem die Architektur eigentlich lösen soll. Genau dort setzen wir an.

Vorhaben besprechen

Über den Autor

Martin Waßmann ist Gründer von IT/OT Experts und unterstützt produzierende Unternehmen bei Digitalstrategie, IT/OT-Integration und skalierbaren Produktionsdatenarchitekturen. Schwerpunkte sind unter anderem Brownfield-Integration, Unified Namespace, MQTT und OPC UA.

Mehr über Martin Waßmann