Ob Smart Factory or Smart Home: Um Daten zwischen Geräten / Maschinen bzw. zwischen Maschinen und übergreifenden Steuerungssystemen austauschen zu können, ist der Datentransfer über ein Netzwerkprotokoll erforderlich. Während im IT-Bereich das SNMT-Protokoll („Standard Network Management Transfer“) etabliert ist, gilt im OT-Bereich („Operation Technology“): Verschiedene Netzwerkprotokolle sind im Einsatz, es gibt Dutzende von Protokollen. Bisweilen werden in einer Smart Factory auch mehrere Protokolle parallel eingesetzt. Nachfolgend stelle ich zwei weit verbreitete Netzwerkprotokolle für Smart Home und Smart Factory vor. Nämlich OPC UA und MQTT.

MQTT

MQTT steht für Message Queuing Telemetry Transport. Es handelt sich um ein Netzwerkprotokoll, das nach dem Publish-Subscribe-Prinzip funktioniert. Dies lässt sich an einem einfachen Beispiel illustrieren: Nehmen wir an, zwei Maschinen sind miteinander über ein Förderband verbunden. Maschine 1 (M1) erstellt das Vorprodukt, das auf Maschine 2 (M2) verarbeitet wird. Nun gibt es einen Bewegungssensor des Förderbandes, der anzeigt, ob das Förderband läuft (=funktioniert). Die Übertragung von Daten ist ereignisgesteuert, der Bewegungssensor übermittelt etwa die Information [Förderband im Haltemodus]. Das ist der Publish-Vorgang.

Dieser Datentransfer erfolgt in einem sogenannten Topic, zum Beispiel „Smart-Factory-Berlin/Produktionslinie1/Förderband-M1-M2“. Wenn die Maschine M1 etwa Daten versendet, dann fiele dies etwa unter das Topic „Smart-Factory-Berlin/Produktionslinie1/M1“. Topics strukturieren folglich die bereitgestellten Daten, die über das Netzwerkprotokoll MQTT versandt werden. Topics sind von der Syntax her wie eine Ordnerstruktur aufgebaut. Nun gilt: Jedes Geräte / jede Maschinen kann ein Topic „abonnieren“ (Subscribe-Prinzip). Die Maschine M1 kann das Topic „Smart-Factory-Berlin/Produktionslinie1/Förderband-M1-M2“ abonnieren; und wenn das Förderband in den Haltemodus geht, dann stoppt die Maschine M1 die Fertigung von Vorprodukten.

Eine koordinierende Instanz für das Publish-Subscribe-Prinzip ist der sogenannte Broker. Bekommt der Broker von einem Datenliefernaten („Publisher“) neue Daten, prüft er das Topic auf Übereinstimmung und sendet die Daten an alle darauf angemeldeten Datenkonsumenten („Subscriber“) weiter. Ein solcher Broker ist etwa Mosquitto. Wenn übrigens neue Geräte zum IoT-/IIoT-Netzwerk hinzugkommen, muss dies nicht (manuell) konfiguriert werden: Diese werden automatisch erkannt und können ummittelbar als Publisher oder Subscriber agieren.

Die Vorteile des Netzworkprotokolls MQTT: Erstens, es handelt sich um ein sehr leichtgewichtiges Protokoll, das auch bei unzuverlässigen Netzwerken und eingeschränkter Bandbreite funktioniert. Denn der Protokoll-Overhead ist minimiert, das kleinste Paket hat nur 2 Byte Overhead. Das Netzwerk wird nur minimal belastet (ressourcenschonend). Zweitens, die MQTT-Architektur ermöglicht eine unbegrenzte Anzahl von Clients über ein Publish/Subscribe-Protokoll; mehrere Datenkonsumenten können gleichzeitig die Daten konsumieren. IoT-/IIoT-Netzwerke lassen sich folglich leicht skalieren.

Drittens, das Protokoll ist leicht zu implementieren. Die Spezifikation für das MQTT-Netzwerkprotokoll umfasst gerade einmal 80 Seiten, zudem stellt die MQTT-Community umfangreichen Referenzcode für die praktische Umsetzung zur Verfügung. Viertens, MQTT erlaubt Flexibilität für das Datenformat. Je nach Präferenz können Anwender JSON, XML oder auch Base64 nutzen. Zur Sicherheit: Daten können selbstverständlich auch verschlüsselt werden, und auch die eindeutige Authentifizierung von Teilnehmern mithilfe X.509 Zertifikaten wird von MQTT unterstützt.

Fünftens und letztens: Die Community rund um MQTT wächst schnell, das betrifft vor allem Anbieter auf der Hardware- und Softwareseite, die MQTT-Sparkplug nativ implementieren. Sparkplug wiederum ist eine Open-Source-Softwarespezifikation, die MQTT-Clients ein Framework zur Integration von Daten zur Verfügung stellt. Alle führenden Cloud-Anbieter, IoT-Plattformen, Edge-Computing-Plattformen, Big Data und andere Anwendungen von Drittanbietern unterstützen MQTT.

Nachfolgend ein Demo-Video (16 Minuten), das zeigt, wie sich MQTT in der Praxis implementieren lässt. In diesem Fall in …

OPC UA

Das Akronym OPC UA steht für Open Platform Communications – Unified Architecture. Dieser Architektur liegt im Kern eine Client-Server-Architektur zugrunde – auch wenn neuerdings eine Publish-Subscribe-Kommunikation hinzugefügt wurde. Die Daten auf einem OPC Client werden ausgelesen und über einen OPC Server im Netzwerk bereitgestellt. Es ist ein IP-basiertes Netzwerk erforderlich (heißt: auf dem Internet Protokoll (IP) basierend). Es gilt, dass neue Clients konfiguriert werden müssen (und nicht automatisch erkannt werden).

Der zentrale Vorteil von OPC UA liegt in einer vereinheitlichten Semantik der Nachrichten, so dass Hersteller-übergreifend Maschinen gesteuert und überwacht werden können. Dies stellt Interoperabilität her. Hierzu werden eigene Informationsmodelle in Form von sogenannten Companion Specifications bereitgestellt, die von Fachgremien erarbeitet werden. Die Initiative UMATI (Webseite: www.umati.org) etwa bringt Maschinenhersteller, Nutzer, Softwarehäuser an einen Tisch, um offene, weltweit gültige Standards zu definieren. Die Vision: ” For the benefit of users of machinery, and the machine building industries themselves, umati tackles this issue by promoting open standards throughout the world.”

Die Nachrichten (+ das Vokabular) sind also für branchenspezifische Anwendungen und Objekte bei gleichartigen Maschinen und Systemen standardisiert. Press-, Druck- oder Spritzgussmaschinen lassen sich dadurch in Ihren Datenmodellen vergleichen. Dabei gilt: Die Interoperabilität ist geradezu ein Kernmerkmal von IIoT-Netzwerken. Warum? Das Internet (Start Anfang 1990er Jahre) arbeitete noch mit semantisch agnostischen Transportprotokollen wie HTTP, FTP, SMTP; die transportierte Information (die Webseiten) werden von Menschen empfangen und verarbeitet. Im Gegensatz dazu zielen IIoT-Netzwerke auf eine wachsende Autonomie der interagierenden (technischen, maschinellen) Komponenten ab. Die ausgetauscht Information muss darum semantisch eindeutig bereitgestellt werden.

Was Entwickler als Nachteil einschätzen: Diese Architektur und Zielsetzung der Interoperabilität / Standardisierung ist mit Nachteilen verbunden. Erstens, die Implementierung ist in der Regel kompliziert und vergleichsweise teuer. Die OPC UA Spezifikation beläuft sich etwa auf 1 250 Seiten. Zweitens, die Skalierbarkeit stößt (gerade im Vergleich zu MQTT) an Grenzen. Die Server-zentrierte Architektur macht eben diesen Server zu einem Bottleneck, die Anzahl der Datenkonsumenten (One-to-Some vs One-to-Many) lässt sich nicht beliebig erhöhen.

Es ist vor allem kritisch zu bewerten, dass nur vereinzelte Hersteller und Cloud-Anbieter die OPC UA Schnittstellenfähigkeit anbieten. Während etwa alle großen Cloud-Anbieter MQTT als Interface bieten, gilt das nicht für OPC UA. Und auch nur wenige Sensoren liefern bis heute eine OPC UA Schnittstelle.

OPC UA oder MQTT?

Die vorgenannten Architekturen, Protokoll-Eigenschaften und die damit verbundenen Vorteile bzw. Nachteile liefern gute Anhaltspunkte für Unternehmen, die sich für das eine oder andere Protokoll entscheiden müssen. Eine robuste Sicherheitsarchitektur lässt sich sowohl mit MQTT als auch mit OPC UA aufbauen.

Der Experte Helmut Ritter von Bachmann electronics liefert folgende Faustformel: 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.

In der Praxis lässt sich auch beobachten: Wenn Unternehmen ein SCADA-System [Supervisory Control and Data Acquisition] haben, neigen sie dazu, OPC oder OPC UA zu verwenden.

Zum Weiterlesen

Author

Der Autor ist Manager in der Softwareindustrie mit internationaler Expertise: Prokurist bei einem der großen Beratungshäuser - Verantwortung für den Aufbau eines IT Entwicklungszentrums am Offshore-Standort Bangalore - Director M&A bei einem Softwarehaus in Berlin.