5 Bewertungen

Interview über Kommunkationsprotokolle OPC UA und MQTT: „Wie Äpfel und Birnen“

Helmut Ritter, Produktmanager bei Bachmann Electronic, im Interview mit der A&D.

Bild: Bachmann Electronic
03.09.2020

Wie kommen die Daten in die Cloud? Diese Frage stellen sich viele Industrieanwender. In vielen Publikationen wabern Vergleiche von OPC UA und MQTT, doch diese hinken. Helmut Ritter, Produktmanager bei Bachmann Electronic, erklärt warum.

Um was genau handelt es sich eigentlich bei MQTT?

MQTT steht für Message Queuing Telemetry Transport und wurde für kleine Sensoren mit geringer Rechenleistung entwickelt. Alle Netzwerkteilnehmer verbinden sich mit einem zentralen Server, welcher alle einlaufenden Datentelegramme der Sensoren entgegennimmt. Die Telegramme sind durch „Topics“ identifiziert, typischerweise werden hier 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 ein neues Datentelegramm, sendet er dieses automatisch an alle angemeldeten Konsumenten weiter.

Was ist der Vorteil von MQTT?

MQTT ist wesentlich einfacher in der Anwendung: Ein beliebiger Informationsblock mit Daten aus der Steuerungssoftware (Message) wird mit einer lesbaren Kennzeichnung (Topic) an den Broker gesendet. Von dort können datenverarbeitende Einheiten diese Informationsblöcke per Subscription empfangen und weiterverarbeiten. Eine Verschlüsselung der Message ist ebenfalls möglich.

Also kein Security Defizit gegenüber OPC UA?

Nein, aber OPC UA wurde in einer Evaluierung der amerikanischen Öl- und Gasindustrie im Jahr 2014 zum allgemeinen Kommunikationsstandard erklärt. Der Hauptgrund für diese Entscheidung war das ausgereifte Security-Konzept von OPC UA, das bei den meisten anderen standardisierten Feldbussen und Kommunikationsverfahren fehlt oder als Add-on später nachspezifiziert wurde.

Warum schwören viele Anbieter auf OPC UA?

In der Industrieautomatisierung 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. Die zusätzlichen Möglichkeiten von OPC UA, wie Browsen, das Auslesen von Metainformationen oder das flexible Organisieren von Variablen in Überwachungslisten werden dabei schlicht und einfach nicht benötigt, erhöhen hingegen die Komplexität in der Anwendung.

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

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.

Aber es herrscht ein Hype um OPC UA!?

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. OPC UA und MQTT zu vergleichen, ist nicht nützlich, denn sie leisten unterschiedliche Aufgaben. Es ist wie mit den Äpfeln und Birnen, der Anwendungsfall muss passen. Wir können beides.

Wie reagieren Ihre Kunden?

Wir bieten sowohl einen OPC UA-Server und -Client, als auch Lösungen für MQTT an. 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 will. MQTT hat hingegen seine Stärken, wenn auf der Steuerungsseite vorab festgelegt werden kann, welche Daten gesammelt, aggregiert und archiviert werden sollen.

Gibt es Kombinationen?

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 Netzwerkgrenzen, 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. 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ötigem Datentransfer.

Firmen zu diesem Artikel
Verwandte Artikel