Kommunikation : OPC UA versus MQTT: Gelingt der direkte Vergleich?

Helmut Ritter: MQTT steht für Message Queuing Telemetry Transport und wurde ursprünglich für kleine Sensoren mit geringer Rechenleistung entwickelt. Alle Netzwerkteilnehmer verbinden sich dabei mit einem zentralen Server, welcher alle einlaufenden Daten-Telegramme der Sensoren entgegennimmt. Die Telegramme sind durch „Topics“ identifiziert, dabei werden lesbare Namen verwendet. Konsumenten der Information melden sich am zentralen Broker an und können unter Angabe der jeweiligen Topics eine Teilmenge der Informationen abonnieren (subscribe). Erhält der Broker von einer Quelle neue Daten, prüft er das Topic auf Übereinstimmung und sendet die Daten an alle darauf angemeldeten Konsumenten weiter.

Es heißt: MQTT ist in der Anwendung sehr flexibel, da sich die Teilnehmer untereinander nicht kennen müssen?

Ritter: Richtig. Produzenten und Konsumenten der Daten können beliebig zum Netzwerk hinzugefügt und oder entfernt werden. Der Standard gibt auch nicht vor, wie Daten modelliert, strukturiert und codiert werden müssen, das kann der Anwender völlig frei für sich definieren. Eine Verschlüsselung der Daten ist auch bei MQTT möglich.

Lesen Sie auch: OPC UA auf Bestellung - so kommen Anwender:innen zur Schnittstelle

Ritter: Sowohl MQTT als auch OPC UA erlauben die eindeutige Identifikation der Teilnehmer (Authentication) an Hand von X.509 Zertifikaten sowie die Verschlüsselung der übertragenen Daten (Encryption). Somit sind die beiden Verfahren in Hinblick auf die Security gleichauf. Bei den konventionellen standardisierten Feldbussen und Kommunikationsverfahren ist Security hingegen kein Thema, da sie nur für die Anwendung innerhalb der Maschine konzipiert sind.

Ritter: Die zusätzlichen Möglichkeiten von OPC UA, wie Browsen, das Auslesen von Meta-Informationen oder das flexible Organisieren von Variablen in Überwachungslisten bietet großen Komfort, wenn eine Maschine von außen betrachtet und überwacht werden soll. Hier helfen auch die sogenannten „Companion Specifications“, die derzeit für verschiedene Branchen entstehen. Vergleichbare Einheiten wie Pressen, Druck- und Spritzgussmaschinen werden dadurch in Ihren Datenmodellen vergleichbar und können herstellerübergreifend bedient werden.

Ritter: Lautet die Aufgabe, erfasste oder berechnete Prozessdaten zu spontanen Zeitpunkten (beispielsweise wenn ein Werkstück die Maschine verlässt) in einen externen Cloud-Speicher zu übertragen, ist MQTT die einfachere und bessere Lösung. Die Daten können so vorab auf Seite der Maschine festgelegt werden.

Und für Machine Learning – da braucht es doch die strukturierten Daten von OPC UA?

Ritter: Für die Auswertung der Daten muss selbstverständlich immer deren Bedeutung bekannt sein. Wenn dabei das Datenmodell von der Maschine weg über die Zwischenspeicherung in der Cloud bis hin zur maschinellen Auswertung unverändert bleiben kann, ist es an allen Stellen wiedererkennbar. Das ist sicher ein Vorteil.

Häufig müssen Daten für eine sinnvolle Nachbearbeitung jedoch neu gruppiert werden.

Ritter: Dann entstehen aus der Aggregation auch neue Datenpunkte. Hier muss die gesamte Kette der Datenverarbeitung betrachtet werden, von der Quelle bis zum Berechnungsalgorithmus. Die Realität zeigt, dass alle großen Cloud-Anbieter MQTT als Interface bieten, aber nur wenige OPC UA

Ritter: Die Fachpresse hat sogar erwartet, dass Kleinstgeräte wie Sensoren zukünftig eine OPC UA Schnittstelle erhalten werden. In der Realität hat sich jedoch gezeigt, dass Sensoren weiterhin einen klar überschaubaren Datenraum liefern und nur wenige Daten, diese dafür mit Echtzeit-Anspruch, zu übertragen sind. Deshalb sind Sensoren mit OPC UA bis heute nicht auf dem realen Markt anzutreffen.

Ritter: OPC UA und MQTT sind nicht direkt zu vergleichen, denn sie lösen unterschiedliche Aufgaben. Es ist wie mit den Äpfeln und Birnen. Der Anwendungsfall muss passen.

Ritter: Bachmann electronic bietet sowohl einen OPC UA Server und Client an als auch Lösungen für MQTT. Beide Technologien werden von Kunden eingesetzt. Der OPC UA Server wird erwartungsgemäß dann eingesetzt, wenn die Steuerung möglichst viele Daten vorrätig halten soll und eine frei gestaltbare Maschinenvisualisierung eine Untermenge dieser Daten überwachen soll. MQTT hat hingegen seine Stärken, wenn auf der Steuerungsseite vorab festgelegt werden kann, welche Daten gesammelt, aggregiert und weitergeleitet werden sollen.

Ritter: Eine Kombination ist nicht zwingend notwendig und sogar nur in speziellen Fällen sinnvoll. Die meisten HMI- und Scada-Anwendungen basieren auf einer direkten OPC UA Client-Server-Beziehung. Das Netzwerkprotokoll TCP/IP erlaubt hier bereits den Zugriff über Netzwerksgrenzen, ein zusätzlicher Einsatz von MQTT bringt keine Vorteile.

Die kürzlich erschienene Erweiterung „Publish/Subscribe“ in OPC UA Part 14 beschreibt ein 1-zu-n- Verfahren. Erklären Sie uns das kurz.

Ritter: Der Publisher versendet UDP-Multicast-Pakete, die von mehreren Teilnehmern im Netzwerk empfangen werden können. Die notwendige technische Infrastruktur für die Übertragung ist lediglich ein handelsüblicher Ethernet-Switch, der die Multicasts weiterleitet. Wenn die Daten der Fertigungszelle eine Menge erreichen, bei der ein „Jeder-erzählt-jedem-alles-Verfahren“ nicht mehr praktikabel ist, kann zusätzlich ein MQTT-Broker eingesetzt werden. Dieser bietet im Gegensatz zum normalen Switch die zusätzliche Möglichkeit, die Weiterleitung der Daten über den Topic-Filter zu steuern und entlastet somit das Netzwerk und die Subscriber von unnötigen Datentransfers.

Vielen Dank für das Gespräch!