Anja Helmbrecht-Schaar

HiveMQ

Kontaktdaten

Software

Für Interoperabilität im IIoT

Die Konzepte des Kommunikationsprotokolls MQTT eignen sich für den Einsatz in der digitalisierten Produktion. Ein Vorteil ist die Entkopplung der Daten durch den Einsatz einer zentralen Messaging-Komponente. MQTT ermöglicht die einfache Implementierung verschiedener Sicherheitsmechanismen sowie die Zustandsverwaltung der Clients. Die Sparkplug-B-Spezifikation baut darauf auf: Sie gibt MQTT ein Framework, das für die Anforderungen an Systeme des Industrial Internet of Things (IIoT) entwickelt wurde.

Die digitale Transformation hat längst auch die Fertigungshallen erreicht. Typische Prozesse, die sich in 200 Jahren industrieller Produktion etabliert haben, befinden sich mit dem IIoT in einem gewaltigen Wandel. Das ist notwendig, denn die digitale Vernetzung ist ein entscheidender Faktor, um wettbewerbsfähig zu bleiben. Der derzeit trotzdem noch zögerliche Einzug von Digitalisierung in der Produktionsbranche ist insbesondere der Komplexität vieler Systeme geschuldet, die Datentransparenz und -vernetzung bislang erschwert.

Im Hinblick auf die Interoperabilität im IIoT sind Lösungen gefragt, die Daten automatisiert systemübergreifend integrieren und analysieren. Um allein ein einzelnes Input/Output-Signal von der Fabrikhalle in die Cloud zu übertragen, war bislang oft ein komplexes, technologisches Setup erforderlich, das weder in Hinblick auf die IT-Sicherheit noch auf den Kosten- und Arbeitsaufwand effektiv war. Neue, schlanke Technologien bieten der Fertigungsindustrie mittlerweile eine Alternative zum traditionellen, komplexen Set-up.

MQTT

Der Blick auf MQTT zeigt ein quelloffenes IoT-Kommunikationsprotokoll nach dem Publish-Subscribe-Modell, das insbesondere in Verbindung mit der Sparkplug-Erweiterung für reibungslose Maschine-zu-Maschine-Kommunikation sorgt. MQTT feierte 2019 sein 20-jähriges Bestehen und bietet eine Spezifikation, die als ein De-facto-Standard für das Internet der Dinge angesehen wird. Kernprinzip des Netzwerkprotokolls ist das Publish-Subscribe-Muster (Pub-Sub), das es einer beliebigen Anzahl von Datenkonsumenten ermöglicht, einzelne Themenbereiche oder Gruppen von Topics zu abonnieren und die darüber veröffentlichten Nachrichten zu empfangen.

Aufgrund seiner Schlankheit eignet sich MQTT besonders für sehr ressourcenarme Geräte sowie für die Kommunikation in Netzwerken mit geringer Bandbreite, in unzuverlässigen Netzwerken oder Netzwerken mit hoher Latenz. Die Verwendung eines Pub-Sub-Protokolls wie MQTT stellt eine grundlegende Änderung in der Architektur dar. Alle Nachrichten werden über einen Broker als zentrale Komponente versendet, über den sich alle MQTT-Geräte für bestimmte Topics registrieren. Der Broker übernimmt die Aufgabe des Servers, über den jede Kommunikation zwischen beliebigen Clients abgewickelt wird. MQTT-Clients sind am Gateway, auf Geräten oder in Applikationen implementiert und stehen nicht in direkter Beziehung zueinander. In MQTT gibt es somit eine einzige Datenquelle (Single Source of Truth), was ein wesentlicher Vorteil ist. Sichere Kommunikation lässt sich schnell und auf viele Arten realisieren. Der Client-Status, inhärent für die beteiligten Systeme, kann durch die Funktionalität vollständig implementiert werden.

Aufgrund der schlanken Strukturen eignet sich MQTT für ressourcenarme Geräte oder Netzwerke mit geringer Bandbreite. Quelle: MQTT

Sparkplug B

Um der Anforderung an Interoperabilität für industrielle Automatisierung gerecht zu werden, gilt es, Implementierungsstandards aufbauend auf MQTT zu definieren. Dies ist das Ziel von Sparkplug, einem Projekt der Eclipse Foundation – Tahu Working Group. Sparkplug stellt eine offene und frei verfügbare Spezifikation zur Verfügung, die beschreibt, wie Edge Gateways oder native MQTT-fähige Endgeräte und MQTT-Applikationen über eine zentrale Komponente bidirektional kommunizieren können. So entsteht ein Standard, der für Anwendungsfälle in industriellen Applikationen optimiert ist und der beschreibt, wie die Funktionalität am besten in Echtzeit-SCADA-Implementierungen genutzt werden kann.

Derzeit gibt es zwei mit Sparkplug definierte Schemata. Sparkplug B bietet die spezifische Lösung für eine Anwendung im Produktionsumfeld: Der Zweck der Spezifikation besteht darin, die Vorteile von MQTT wie Einfachheit, Effizienz sowie Verständlichkeit sowohl in der Implementierung als auch im Betrieb mit den Anforderungen aus der OT zu paaren, eine Ontologie festzulegen, die allen Beteiligten bekannt ist, ein Session Management für Clients zu garantieren und schließlich Nachrichtengrößen auf ein Minimum zu beschränken.

Dies bedeutet, dass Entwickler und Planer mit der Sparkplug-Spezifikation klare Richtlinien für den Entwurf des Topic-Namensraumes haben, wie die Payload-Daten zu strukturieren sind und wie der Client-Status zu halten und zu kommunizieren ist. Mit MQTT und Sparkplug B werden Nachrichtengröße und Frequenz minimiert.

MQTT-Infrastruktur

Ein herkömmliches Scada-System im OPC-UA-Architekturbild interagiert immer direkt mit dem MQTT-Broker. Der Broker ist die zentrale Komponente. Er wird in einem Cluster, ausfallsicher und hochskalierbar betrieben und verfügt über Metrik-, Monitoring- und Alarm-Schnittstellen, damit alle beteiligten Systemkomponenten optimal überwacht werden können.

In einer Sparkplug-Architektur hingegen verbinden sich Geräte, EoN-Knoten (End of Network) und der Scada/IIoT-Host mit einem zentralen MQTT-Broker und veröffentlichen oder abonnieren Daten. Der Scada/IIoT-Host ist explizit nicht dafür verantwortlich, Verbindungen zu den Geräten direkt herzustellen oder aufrechtzuerhalten, sondern die EoN-Knoten verbinden Nicht-Sparkplug-/MQTT-fähige Geräte und Sensoren mit der Infrastruktur. Ein EoN-Knoten ist für die Verwaltung seines eigenen Status sowie des Status der Geräte verantwortlich – und für den Empfang sowie das Senden von Daten der Geräte an die Sparkplug-Infrastruktur. Inzwischen bieten viele Hersteller native MQTT-Funktionen für ihre Geräte und Sensoren an. Ist das Gerät bereits mit Sparkplug ausgestattet, kann es direkt an der Infrastruktur teilnehmen. In diesem Fall identifiziert es sich als EoN-Knoten für die Sparkplug-Infrastruktur.

Alle MQTT-Clients, insbesondere der Scada-Host und die IT-Applications, abonnieren oder setzen sich auf die Themenbereiche, von denen Informationen empfangen werden sollen. Dank der fest definierten Topic-Struktur Datenobjekte weiß jeder MQTT-Client, wo und in welcher Form Informationen abgerufen werden können. Die MQTT-Clients sind zustandsbehaftet, so dass nie ein Informationsverlust entsteht. Die jeweiligen Nachrichtentypen sind für bestimmte Informationen spezifiziert.

Ein wesentlicher Vorteil ist die Entkopplung der Daten durch den Einsatz einer zentralen Messaging-Komponente. MQTT ermöglicht sowohl die einfache Implementierung verschiedener Sicherheitsmechanismen sowie die Zustandsverwaltung der Clients und ist aufgrund seiner Eigenschaften wie Leichtgewichtigkeit und Geschwindigkeit ideal für den Echtzeitbetrieb von IIoT-Infrastrukturen geeignet. Die Sparkplug-B-Spezifikation baut genau darauf auf: Sie gibt MQTT ein Framework, das in Anlehnung an die Anforderungen an IIoT-Systeme entwickelt wurde. Folgende Funktionalitäten der Spezifikation sorgen dabei für eine extreme Einsparung in puncto Netzwerkressourcen

  • nur Datenänderungen schicken (Report by Exception)
  • Pub/Sub-Mechanismus
  • Session- und Statusmanagement
  • Komprimierter Payload

Für den Einsatz von MQTT in Produktionsumgebungen gilt es, eine Onthologie zu definieren, damit alle beteiligten Geräte und Anwendungen die Begriffe sowie die zwischen ihnen bestehenden Beziehungen im Themenraum kennen, verstehen und anwenden können.

Das sorgt dafür, dass die gesendeten Informationen für die Komponenten der IT-Strukturen ohne weitere Metainformationen interpretierbar sind. Dieser Ansatz ermöglicht es Herstellern, Geräte schon mit dieser Spezifikation auszuliefern.

Kontakt

Anja Helmbrecht-Schaar

Senior Consultant (MQTT & Architektur)
HiveMQ
Landshut
Tel. +49 871 97 50 63 00
E-Mail senden

www.hivemq.com