Definitions
Die Frage, ob man OPC UA oder MQTT verwenden sollte, wird mir häufig gestellt. Die meisten Vergleiche, die ich gefunden habe, sind jedoch ziemlich voreingenommen und spiegeln nicht die Realität wider, da sie davon ausgehen, dass Fabriken voll mit der neuesten Technologie ausgestattet sind.
Zunächst einmal ist die Frage an sich vergleichbar mit dem Vergleich von Lastwagen und Paletten. Der eine ist dazu gemacht, den anderen zu transportieren. MQTT ist eine Methode, um Nachrichten von einem Ort zum anderen zu übertragen, während OPC UA mehr darum geht, das Nachrichtenformat zu standardisieren, das von einer Übertragungsmethode getragen wird.
Natürlich ist die obige Antwort in der Regel nicht das, wonach jeder sucht. Ich werde daher ein paar praxisnahe Beispiele für die Unterschiede auflisten. In diesem Beitrag werde ich die Unterschiede zwischen OPC UA Client/Server und proprietärer MQTT-Nachrichtenübertragung behandeln, da dies die gängigsten sind.
OPC UA vs MQTT
Beginnen wir damit, uns daran zu erinnern, dass OPC UA eine Request-Response-Kommunikation ist, während MQTT eine Einwegkommunikation ist. Wenn Sie eine Antwort auf Ihren Aufruf in OPC UA benötigen, erhält Ihr Client diese automatisch, während Sie in MQTT mit benutzerdefiniertem Code eine asynchrone Antwort erstellen müssen.
Ein weiterer Unterschied besteht darin, dass OPC UA eine eingebaute Sicherheit hat (sechs von sieben traditionellen Aspekten der Sicherheit). In MQTT müssen Sie die Sicherheit selbst implementieren, was besonders kompliziert wird, wenn die Anzahl der Publisher und Subscriber zunimmt.
Das OPC UA-Payload ist standardisiert, sodass mit den Standard-Browse- und Subscribe-Funktionen jeder OPC UA so konfiguriert werden kann, dass er auf jeden OPC UA-Server liest und schreibt. In MQTT ist das Payload typischerweise in jedem Fall unterschiedlich, und es ist Codierung erforderlich, um das Payload verschiedener Publisher zu interpretieren.
Der MQTT-Topic-Baum bietet insbesondere bei fehlender Verschlüsselung eine einfache Möglichkeit zur automatischen Konfiguration. Der OPC UA-Adressraum ermöglicht ebenfalls eine Auto-Konfiguration, auch wenn der Datentransport verschlüsselt ist, erfordert jedoch mehr Fachkenntnisse und Aufwand vom Programmierer.
MQTT-Publisher und -Subscriber lassen sich mit Open-Source-Bibliotheken sehr einfach implementieren, in wenigen Tagen. Die Programmierung eines OPC UA-Clients oder -Servers dauert einige Wochen, um mit dem kommerziellen SDK zu implementieren, und mit Open-Source dauert es etwas länger.
MQTT kann Millionen von Werten in Millionen von Publishern skalieren. OPC UA-Clients können problemlos Hunderte von Servern und Zehntausende von Knoten verbinden.
Im derzeitigen Stand des Jahres 2023 ist der OPC UA Client/Server MQTT überlegen, wenn es um die Integration von OT-Datenquellen in die herkömmliche Fabrik-IT geht. MQTT ist hingegen typischerweise bequem, wenn OT-Daten in das Industry 4.0 Cloud IT integriert werden müssen, aufgrund der einfachen Auto-Konfiguration. In diesen Fällen empfehle ich die Verwendung von OPC UA über MQTT, da Sie so den besten Teil des standardisierten OPC UA-Payloads nutzen können.
Wenn ich ein Dutzend Jahre in die Zukunft blicke, prognostiziere ich, dass die Verwendung von MQTT, insbesondere der Versionen 5+, zum Mainstream werden wird, während die Übernahme von OPC UA Pub/Sub und den Open Industry 4.0 Alliance Open Edge Computation Guidelines zu de facto industriellen Standards werden.
Immerhin sehe ich auch in Zukunft keine guten Alternativen zu OPC UA, wenn es um deterministische sichere Kommunikation zwischen MES, SCADA und Controller geht. In diesen Anwendungsfällen möchten Sie sicher sein, dass Sie eine etablierte Kommunikation haben und eine synchrone Bestätigung erhalten, dass Ihre Schreiboperation erfolgreich war.
Wenn Sie Fragen haben, können Sie sich gerne direkt an den Autor Pyry Grönholm oder den Prosys OPC Vertrieb über unser Kontaktformular wenden.
