LernenMQTT oder OPC UA
Kostenlose UNS-Werkzeuge
MQTT oder OPC UA

Zwei Standards, zwei verschiedene Aufgaben.

OPC UA (IEC 62541) ist ein Interoperabilitätsstandard mit Informationsmodell: typisierte, durchsuchbare Objekte mit Datentypen, technischen Einheiten und Methoden, üblicherweise per Client/Server abgefragt. MQTT (OASIS, v3.1.1 und v5.0) ist ein leichtgewichtiger Publish/Subscribe-Transport: Ein Broker entkoppelt Sender von Empfängern und bewegt kleine Nachrichten über unzuverlässige Netze — ohne jede Meinung darüber, was darin steht. Beide bewerben sich nicht um denselben Platz, und deshalb lautet die ehrliche Antwort meist: beide — OPC UA, um strukturierte Daten aus Maschinen zu holen, MQTT, um sie im Werk zu verteilen.

Gegenüberstellung

Die Unterschiede, die Ihre Architektur wirklich verändern.

KriteriumOPC UAMQTT
KommunikationsmodellClient/Server-Sitzungen mit Subscriptions und Monitored Items. Ein Client muss jeden Server kennen und erreichen. OPC UA PubSub (Teil 14) ergänzt einen Broker-Modus, der über MQTT laufen kann.Publish/Subscribe über einen Broker. Sender und Empfänger kennen einander nie; ein zehnter Konsument ändert stromaufwärts nichts.
InformationsmodellEin durchsuchbarer Adressraum: Objekte, Variablen, Datentypen, Einheiten, Methoden, dazu Companion Specifications für ganze Maschinenfamilien.Keines. Die Nutzlast ist ein undurchsichtiger Bytestrom. MQTT 5 ergänzt User Properties und einen Content-Type-Hinweis, aber kein Modell — Sparkplug B liefert es üblicherweise nach.
AuffindbarkeitDen Server zur Laufzeit durchsuchen. Ein neuer Client lernt die Struktur, ohne auf die Tabelle des Integrators zu warten.Ein Wildcard abonnieren und sehen, was ankommt. Bedeutung entsteht aus einer Topic-Konvention, die Sie selbst entwerfen, dokumentieren und steuern.
NetzverhaltenEmpfindlich gegen Latenz und Paketverlust; Sitzungen bauen sich neu auf und abonnieren erneut. Verlangt eingehende Verbindungen durch die Firewalls zwischen den Ebenen sowie einen Zertifikatsaustausch.Jedes Edge-Gerät öffnet eine einzige ausgehende TLS-Verbindung. QoS 1, persistente Sitzungen und Last Will überstehen Abbrüche — daher die Robustheit über Mobilfunk, Satellit und NAT.
Nutzlast und BandbreiteUA Binary über TCP 4840 ist kompakt, die JSON-Kodierung nicht. Subscriptions melden nur Änderungen, wenn Sie Totbänder und Abtastung bewusst konfigurieren.Fester Header ab zwei Byte; Port 1883 unverschlüsselt, 8883 mit TLS. Ein Sparkplug-DDATA-Update mit Metrik-Aliassen wiegt typischerweise einige Dutzend Byte.
SicherheitX.509-Zertifikate je Sitzung, Signatur und Verschlüsselung, Benutzerauthentifizierung, benannte Security Policies. Vertrauenslisten und Ablaufdaten sind echte, wiederkehrende Betriebsarbeit.TLS plus Benutzername/Passwort, Client-Zertifikat oder Token. Die Autorisierung je Topic liegt im Broker; dessen Zugriffskonzept ist die Entwurfsarbeit, die man nicht überspringen kann.
Bester EinsatzMaschinen- und Linienintegration: typisierter Zugriff, Kommandos und Methoden mit Quittung, oder eine Hersteller-Companion-Specification, die man erbt statt neu erfindet.Verteilung im ganzen Werk und Richtung Cloud: viele unabhängige Konsumenten, unterbrochene Verbindungen, ereignisgetriebene Architektur — und der Transport unter den meisten UNS-Installationen.

OPC UA wählen

Wenn Sie die Struktur einer Maschine brauchen und nicht eine Adressliste: typisierte Knoten, Einheiten, Methoden, Alarms and Conditions, und eine Companion Specification, die Ihre Geräteklasse bereits modelliert. Ebenso, wenn ein Kommando eine verbindliche Quittung braucht statt eines Fire-and-Forget.

MQTT wählen

Wenn ein Messwert viele Abnehmer hat — Dashboards, Historian, MES, eine Analyse, ein zweiter Standort — und Sie nicht für jeden neuen Abnehmer eine Integration bauen wollen. Ebenso, sobald die Leitung schlecht ist: Ein Broker mit QoS 1 und Store-and-Forward verträgt, was eine Client/Server-Sitzung nicht verträgt.

Das übliche Muster

OPC UA von den Maschinen zu einem Edge-Knoten; der Edge-Knoten bildet Tags auf einen geregelten Namensraum ab und veröffentlicht Änderungen an einen MQTT-Broker; alles andere abonniert. In dieser Abbildung steckt die Modellierungsarbeit — wer sie überspringt, bekommt einen Broker voller bedeutungsloser Tags.

Fallen aus realen Projekten.

  • Die Wahl als werksweite Glaubensfrage behandeln. Entschieden wird pro Abschnitt — Maschine zu Edge, Edge zu Werk, Werk zu Cloud — und verschiedene Abschnitte entscheiden zu Recht verschieden.
  • Einen OPC-UA-Knoten ohne Modell dazwischen auf ein MQTT-Topic brücken. Damit ist die Unordnung umgezogen, kein Namensraum entstanden.
  • Annehmen, MQTT liefere einen UNS. MQTT liefert Nachrichten; Hierarchie, Benennung, Nutzlastvertrag und Governance bleiben Ihre Aufgabe.
  • OPC-UA-Zertifikate und Vertrauenslisten treiben lassen, bis ein Ablaufdatum die Linie an einem Sonntag stoppt.
  • QoS 2 überall aktivieren, „sicherheitshalber“. Das kostet einen vierteiligen Handshake pro Nachricht; QoS 1 mit idempotenten Konsumenten ist die normale industrielle Wahl.
  • 20.000 OPC-UA-Knoten im Sekundentakt pollen und das Ergebnis ereignisgetrieben nennen. Report by Exception ist eine Konfigurationsentscheidung, kein Protokollabzeichen.
Verwandte Konzepte

Wo diese Entscheidung hingehört.

Die Protokollwahl ist die Installation unter einer größeren Frage: Welche Information veröffentlicht das Werk, und wer darf sich darauf verlassen? Genau das definiert ein Unified Namespace, das kodiert Sparkplug B auf der Leitung, dafür liefert ISA-95 ein gemeinsames Vokabular, und die Kontextualisierung macht daraus etwas, das Mensch und Modell lesen können. Die technischen Mindestanforderungen — edge-getrieben, Report by Exception, offen, leichtgewichtig — filtern schneller als jede Funktionsmatrix. Weiter stromabwärts entscheidet dieselbe Wahl, ob eine OEE-Zahl belastbar ist und ob vorausschauende Instandhaltung das benötigte Signal je zu sehen bekommt.

Kostenlos, Ohne Anmeldung

Prüfen Sie Ihre Topics, bevor Sie sie zum Standard machen.

Unsere kostenlosen Browser-Werkzeuge prüfen ein Sparkplug-B-Topic gegen die Grammatik der Spezifikation und durchsuchen eine Liste von Namensraumpfaden nach dem, was einen Namensraum leise verdirbt: uneinheitliche Tiefe, gemischte Schreibweisen, Leerzeichen, Kollisionen durch Groß- und Kleinschreibung, Duplikate. Nichts, was Sie einfügen, verlässt Ihren Rechner.

Kostenlose Werkzeuge öffnen

Häufige Fragen

Müssen wir uns für das ganze Werk auf eines festlegen?

Nein, und die Frage deutet meist auf einen Zuschnittfehler hin. Entschieden wird pro Abschnitt: OPC UA zwischen Maschine und Edge-Knoten, MQTT zwischen diesem Knoten und allen Konsumenten dahinter. Eine einzige Entscheidung für alles erzwingt später genau die unbeholfenen Gateways, die niemand betreuen will.

Bekommen wir mit MQTT einen Unified Namespace?

Nein. MQTT ist der Transport, auf dem die meisten UNS-Installationen laufen, mehr nicht. Der Namensraum ist gerade das, was MQTT nicht mitliefert: eine Hierarchie, die das Geschäft abbildet, eine Namenskonvention, ein Nutzlastvertrag und jemand, der für deren Änderung verantwortlich ist. Ein Broker mit 40.000 frei gewählten Topics ist ein Nachrichtenbus, kein Namensraum.

Ist OPC UA PubSub über MQTT das Beste aus beiden Welten?

Es hilft tatsächlich, wenn UA-Typinformationen über einen Broker statt über Punkt-zu-Punkt-Sitzungen reisen sollen. Die Unterstützung in Brokern und Clients ist aber weiterhin ungleich, die Kodierungswahl (JSON oder UA Binary) entscheidet, wer mitlesen kann, und Ihren Namensraum entwirft es nicht. Prüfen Sie, was Ihre tatsächlichen Konsumenten dekodieren können, bevor Sie es zum Standard erklären.