Sparkplug – eine auf MQTT basierende Spezifikation für das IIoT
Die typische OT-Architektur (Operational Technology) in heutigen Produktionsumgebungen umfasst eine Vielzahl von Geräten, Sensoren und Gateways. Die jeweiligen Anwendungen fordern die nötigen Daten direkt von den speicherprogrammierbaren Steuerungen (SPS), Gateways oder Servern an, die auch über verschiedene Protokolle kommunizieren können. Eine beliebige Anzahl von Servern aus dem Produktionsbereich kommuniziert dabei direkt mit anderen Teilnehmern im Produktionsbereich. Besteht das Setup aus nur wenigen verschiedene Systemen, funktioniert dieser Ansatz recht gut. Bei einer größeren Anzahl von heterogenen Komponenten entsteht dadurch eine schwer wartbare Architektur. Die Komponenten stehen in einer fest definierten bidirektionale Verbindung. Das verwendete Protokoll ist meist OPC UA, eventuell um weitere Interfaces erweitert.
Es gibt im klassischen Setup keine Komponente, die alle Informationen zentral managt. Dadurch erhöht sich mit der Anzahl der Komponenten der Aufwand für Implementation, Betrieb und Wartung massiv, was am Ende zu steigenden Kosten führt.
Für OPC UA wurden Erweiterungen entwickelt, durch deren Verwendung Ziele wie z. B. die Standardisierung des Austausches der Daten von Maschinen mit den jeweiligen IT-Systemen und der Definition einer einheitlich Semantik für eine Branche, sowie der Festlegung von Sicherheitsrichtlinien und Konfigurationen für OPC Server u. a. erreicht werden sollen. Die grundlegende Architektur wird jedoch nicht weiter berührt und somit bleiben die Herausforderungen, die sich daraus ergeben, bestehen.
Viele Unternehmen suchen nach Anpassungsfähigkeit, Flexibilität und einfacher Implementierung – analog zu IT-Landschaften – jedoch mit der Zuverlässigkeit und Sicherheit, die für OT-Landschaften erforderlich sind. Für diesen Paradigmenwechsel ist eine neue Architektur erforderlich.
Möchte man von der Komplexität wegkommen hin zu einer schlanken Lösung, die einen sicheren und zuverlässigen Datenaustausch in der industriellen Automatisierung garantiert, kommt man nicht umhin, sich mit dem MQTT-Protokoll zu beschäftigen.
MQTT – der Publish-Subscribe-Ansatz
MQTT bietet als OASIS-Standard eine Spezifikation, die als De-facto-Standard für das IoT gesehen werden kann. Kernprinzip des leichtgewichtigen Netzwerkprotokolls ist das Publish-Subscribe-Muster. MQTT eignet sich aufgrund seiner Schlankheit vor allem für sehr ressourcenarme Geräte und für die Kommunikation in Netzwerken mit geringer Bandbreite. Eine MQTT-Architektur ermöglicht die Kommunikation mit einer unbegrenzte Anzahl von Clients.
Da es bereits viele gute Beschreibungen der einzelnen Features gibt [1], soll eine weitere Beschreibung des Protokolls hier nicht vorgenommen werden, sondern lediglich die wichtigsten Eigenschaften von MQTT kurz zusammengefasst werden.
Dies sind:
- Leichtgewichtig, auf TCP basierend
- Pub-Sub-Modell
- Sicher
- Zustandsbehaftet – Nutzung von Sessions
- Datenagnostisch
- Dynamische Topics
- Zustellgarantien für Nachrichten
- Last-Will- und Retained-Nachrichten-Konzept
- Mit MQTT 5
- Einführung von Metadaten wie Userproperties, Payload-Indikatoren oder Content-Typ-Deskriptoren
- Request-Response-Muster, Shared Subscriptions
- Message & Session Expiry pro Client u. a.
MQTT-Infrastruktur im Produktionsumfeld
Mit Verwendung des Pub-Sub-Protokolls wie MQTT und der damit einziehenden Komponente Message Broker ergibt sich eine wesentliche Änderung in der Architektur. Über den zentralen Broker werden alle Nachrichten verschickt. Alle MQTT Clients verbinden sich zum Broker und abonnieren beliebige Topics.
Aus OPC-UA-Sicht übernimmt der Broker hier die Aufgabe der Server. Alle beteiligten MQTT Clients sind lose gekoppelt, ohne direkte Beziehungen untereinander.
MQTT Clients sind direkt an Gateways, Geräten oder in Anwendungen implementiert. Der MQTT Broker kann neben den funktionalen Anforderungen auch Anforderungen wie Ausfallsicherheit, Hochverfügbarkeit und Skalierbarkeit innerhalb der Infrastruktur erfüllen. Die Publish-Subscribe-Architektur für MQTT ist ein signifikanter Unterschied zur client-server-basierten Architektur, da sie einen effizienten Ansatz in der Kommunikation der Geräte und Anwendungen ermöglicht.
Wichtige MQTT-Features für den Einsatz im IIoT
Bestimmte Eigenschaften von MQTT sind hinsichtlich des Einsatzes im IIoT-Umfeld besonders relevant. Die Nutzung von Sessions erlaubt es, für MQTT Clients über die Dauer der aktiven Verbindung hinaus Daten zu persistieren. Dies können zum Beispiel Subscriptions, Offline-Nachrichten oder zusätzliche Informationen sein, die am Broker gespeichert werden und bei einem Reconnect dem Client sofort zur Verfügung stehen.
MQTT ist ein daten-agnostisches Protokoll, der Payload ist binär und unterliegt zunächst keinerlei Spezifikation. Topics unterliegen in ihrer Definition nur syntaktischen Anforderungen. Sie müssen vor der Nutzung nicht spezifiziert oder erzeugt werden und existieren nur dann, wenn ein MQTT Client sich auf ein Topic subscribed, um eingehende Nachrichten zu konsumieren. MQTT baut auf TCP als Transportprotokoll auf. Es gelten die Liefergarantien von TCP bei stabiler Verbindung. Da MQTT u. a. für instabile Netzwerke entwickelt wurde sind drei Servicequalitäten (Quality of Service) spezifiziert.
Das Feature Retained Messages kann im Produktionsumfeld sinnvoll eingesetzt werden. An jedem Topic kann genau eine Nachricht gespeichert werden. Jeder Empfänger, der dieses Topic abonniert hat, bekommt bei seinem Verbindungsaufbau als Erstes diese Nachricht. Das Last-Will-Nachrichtenkonzept erlaubt es, beim Connect des Clients eine Nachricht festzulegen, die erst beim Offline-Event vom Broker verschickt wird. Die Bereitstellung von Statusinformation kann damit sehr gut umgesetzt werden.
Auf der Broker-Seite sollte unbedingt bei der Auswahl des Brokers darauf geachtet werden, das der MQTT Broker die MQTT-Spezifikation zu 100 Prozent implementiert hat. Hier sind insbesondere für MQTT 5 große Unterschiede bei den verschiedenen Brokern zu finden, insbesondere im Cloud-Bereich. Viele Features sind optional, das heißt, ein Broker kann sich MQTT-5-kompatibel nennen, auch wenn nicht alle Features unterstützt werden. Eine Gegenüberstellung der implementierten MQTT 5 Features für einige Broker in der Cloud findet sich unter [2].
Die Konzepte der MQTT-Spezifikation sind hervorragend geeignet für den Einsatz in der Digitalisierung der Produktion. Der zentrale Broker, also die Entkopplung der Daten durch den Einsatz einer zentralen Messaging-Komponente, ist ein wesentlicher Vorteil. Sicherheit kann mit MQTT schnell und vielfältig umgesetzt werden. Der Status der beteiligten Komponenten kann durch MQTT-Funktionalität einwandfrei umgesetzt werden. Gateways können als Integratoren für die Anbindung weiterer Geräte agieren, die andere Protokolle benötigen.
Die Standardisierung des Datenaustauschs sowie die Definition einer einheitlich Semantik kann durch die Hinzunahme einer weiteren Spezifikation auf MQTT aufbauend, umgesetzt werden. Dann kann MQTT mit seinen oben beschriebenen Vorteilen bezüglich Architektur elegant Anwendung finden, um die Anforderungen an Interoperabilität für industrielle Automatisierung zu erfüllen. Das ist das Ziel von Sparkplug [3].
Sparkplug
Sparkplug ist ein Projekt der Eclipse Foundation. Es 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, den MQTT Broker, bidirektional kommunizieren können. Sparkplug (Version B) ist ein Standard, der für Anwendungsfälle in industriellen Applikationen optimiert ist und beschreibt, wie die Funktionalität am besten in Echtzeit-SCADA-Implementierungen genutzt werden kann.
Mit der Sparkplug-Spezifikation sollen die drei folgenden Ziele erreicht werden:
- Ziel 1 – Festlegung eines Topic-Namensraumes: Die freie, dynamische Verwendung von Topic-Namen ist ein großes Plus von MQTT, aber für den Einsatz in Produktionsumgebungen ist die Festlegung auf eine zu definierende Ontologie notwendig, damit alle beteiligten Geräte und Anwendungen die Begriffe und die zwischen ihnen bestehenden Beziehungen im Themenraum kennen, verstehen und anwenden können.
- Ziel 2 – Spezifikation der Datenstrukturen des Payloads: Analog zur Festlegung des Topic-Namensraumes muss für den Einsatz von MQTT in Produktionsumgebungen ein Schema für die Inhalte der Nachrichten, also des Payloads definiert werden. Das kann sehr elegant mit den nativen Konzepten von MQTT 5 aber auch mit MQTT 3 umgesetzt werden.
- Ziel 3 – Definition des Zustandsmanagement: Da MQTT ursprünglich für die Überwachung von Echtzeit-Systemen entwickelt wurde, war der Fokus von Anfang an darauf ausgerichtet, mit Netzwerkausfällen und niedriger Bandbreite und hoher Latenz gut umgehen zu können – also der Nutzung von Sessions. Diese Funktionalität muss vollständig implementiert genutzt werden.
Der Zweck der Sparkplug-B-Spezifikation besteht also darin, die Vorteile von MQTT – wie Einfachheit, Effizienz, Verständlichkeit – sowohl in der Implementation 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 die 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-Namensraum haben, wie die Payload Daten zu strukturieren sind und wie der Client-Status zu halten und zu kommunizieren ist.
MQTT mit Sparkplug im IIoT-Umfeld
Das SCADA-System im "Client-Server-Architekturbild" interagiert direkt mit dem MQTT Broker als einem spezifischem MQTT Client. In einer Broker-Architektur verbinden sich Geräte, EoN-Knoten (Edge of Network) und der SCADA/IIoT-Host mit einem zentralen MQTT Broker und veröffentlichen und abonnieren Daten.
Der SCADA/IIoT-Host ist explizit nicht dafür verantwortlich, Verbindungen zu den Geräten direkt herzustellen oder aufrechtzuerhalten.
EoN-Knoten verbinden nicht-sparkplug-fähige Geräte und Sensoren mit der Infrastruktur. Ein EoN-Knoten ist für die Verwaltung seines eigenen Status und dem seiner Geräte, sowie für Empfang und Senden von Daten der Geräte an die Sparkplug-Infrastruktur verantwortlich.
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.
MQTT-Applikationen sind Komponenten, die an der Sparkplug-Kommunikation teilnehmen und MQTT-Nachrichten erzeugen und verarbeiten können, jedoch nicht der SCADA/IIoT-Host sind.
Der Broker ist die zentrale Komponente, der in einem Cluster, ausfallsicher und hochskalierbar betrieben wird und über Metrik-, Monitoring- und Alarm-Schnittstellen verfügt, damit alle beteiligten Systemkomponenten optimal überwacht werden können.
Alle MQTT Clients, insbesondere der SCADA-Host und die IT-Applikationen subscriben sich auf die Themenbereiche, von denen Informationen empfangen werden sollen. Durch die Definition der Topic-Struktur und der Datenobjekte weiß jeder MQTT Client, wo und in welcher Form Informationen abgerufen werden können. Die MQTT Clients sind zustandsbehaftet, so dass zu keiner Zeit ein Informationsverlust entsteht. Nachrichtentypen sind für bestimmte Informationen spezifiziert.
Umsetzung der Sparkplug-Spezifikation
Um die Sparkplug-Spezifikation umzusetzen, kann wie folgt vorgegangen werden: Alle MQTT Clients, die der Sparkplug-B-Spezifikation folgen, nutzen eine vorgegegebene Struktur für den Topic Namensraum, die wie folgt definiert werden kann:
[namespace]/[group_id]/[message_type]/[edge_node_id]/{[device_id]}
Alle EoN-Knoten publishen einen spezifischen Status und Daten-Nachrichten auf "Ihr" Topic und die Nachrichten ihrer Geräte auf die jeweiligen Device-Topics. Alle EoNs sind auf ihr Command-Topic subscribed, um spezifische Nachrichten des Scada Hosts zu empfangen.
Ein Scada Host abonniert alle relevanten Themen [namespace]/[group_id]/#. Command-Nachrichten published der Scada Host direkt auf das Topic des jeweiligen EoN-Nodes bzw. Gerätes am EoN-Node.
In der Sparkplug-Spezifikation werden verschiedene Nachrichtentypen für die Übertragung von Informationen über Metadaten sowie über den Zustand des jeweiligen Gerätes festgelegt.
- Statusinformationen (BIRTH/DEATH Certificates) können über die MQTT-Konzepte Last Will und Retained Messages abgebildet werden.
- Der Nachrichtentyp für Dateninhalte (DATA) wird nach dem RBE-Prinzip (Report by exception) geschrieben und Nachrichten diese Typs enthalten nur Informationen über Änderungen bezüglich des vorherigen Zustands.
- Als Format ist Protobuf definiert.
Durch diese Umsetzung wird der Payload minimiert und zugleich strukturiert, so dass alle Komponenten im System die Informationen eigenständig interpretieren können.
Neben der Festlegung der Topicstruktur und der Inhalte ist es notwendig, ein Konzept zum Statusmanagement zu implementieren. Dieses kann ebenfalls mit den nativen Mitteln von MQTT gelöst werden.
- Die MQTT Clients der beteiligten Systeme nutzen beim Verbindungsaufbau Sessions.
- Mit dem Konzept der Statusinformationen kann jeder Client im System seine Status abbilden.
- Die Bereitstellung des Status unterliegt den einzelnen Komponenten und ist über den MQTT Broker verfügbar.
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.
Fazit zu MQTT & Sparkplug
Die Konzepte der MQTT-Spezifikation sind hervorragend geeignet für den Einsatz in der Digitalisierung der Produktion. Ein wesentlicher Vorteil ist die Entkopplung der Daten durch den Einsatz einer zentralen Messaging-Komponente. Sicherheit kann mit MQTT schnell und vielfältig umgesetzt werden und für die Zustandsverwaltung sind Bordmittel vorhanden. MQTT ist aufgrund seiner Eigenschaften wie Leichtgewichtigkeit und Geschwindigkeit für den Echtzeitbetrieb von IIoT-Infrastrukturen geeignet. Die Sparkplug-Spezifikation baut darauf auf.
Für den Einsatz von MQTT in Produktionsumgebungen wird mit Sparkplug eine Ontologie definiert, damit alle beteiligten Geräte und Anwendungen die Begriffe und 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.
Sparkplug bietet einen einheitlichen Ansatz zur Nutzung von MQTT für alle Komponenten. Dies ist ein Vorteil vor allem bei der Einführung neuer Maschinen und Anlagen in ein bestehendes System, was dadurch einfacher und schneller und am Ende preiswerter gelingt.
Es ist grundsätzlich einfacher, viele Geräte in eine Infrastruktur mit einer nachrichtenorientierten Middleware, wie dem MQTT Broker zu integrieren, als in eine Client-Server-Struktur. Jede Komponente im System kommuniziert dann nur mit dem Broker und es sind keine weiteren Konfigurationen notwendig. Und dank des Pub-/Sub-Mechanismus, des geringen Datenvolumens und des komprimierten Datenformats benötigt Sparkplug im Vergleich zu OPC-UA oder HTTP sehr viel weniger Netzwerkressourcen. Im Vergleich hinsichtlich CPU, Bandbreite und Energieverbrauch gibt es Benchmarks, die zeigen, dass mit MQTT wesentlich weniger Bytes verschickt werden, sowohl für den Verbindungsaufbau aus auch für die Versendung der Nachrichtenpakete, s. IIoT-Protocol-Benchmarks von Johnathan Hottel [4].
Andere Protokolle wie OPC UA können auch mit MQTT zusammenarbeiten. Ältere Geräte, die einen OPC-Server benötigen, können trotzdem an eine Sparkplug-Infrastruktur angeschlossen werden. Mit Hilfe eines MQTT-fähigen Sensors, der an das Gerät angeschlossen ist, wird es möglich, auch hier MQTT und Sparkplug zu verwenden. Damit lassen sich auch diese Daten für die IT, zentral und für alle Komponenten, zur Verfügung stellen.
Erich Barnstedt
am 30.04.2021Wie die Authoring im letzten Abschnitt selbst beschreibt, gibt es kein Mapping von OPC UA auf das SparkplugB Metamodell und man muss die SparkplugB Daten über nachgerüstete Sensoren von dem Gerät lesen, was zusätzliche Kosten verursacht. Des Weiteren gibt es auch keine Unterstützung von SparkplugB in der Cloud und man muss die Daten von Hand in ein Format zurückübersetzen, das die Clouddatenbanken verstehen, was mit erheblichem Aufwand und Kosten verbunden ist, von den Skalierungsherausforderungen solch einer Lösung mal abgesehen. OPC UA kann im Gegensatz dazu mit dem vordefinierten JSON Format direkt verarbeitet werden und z.B. Microsoft hat sehr viele Kunden, die mit dieser Lösung in Produktion sind.
Außerdem wird SparkplugB als Standard beschrieben, was nicht der Fall ist. OPC UA, auf der anderen Seite, ist seit 6 Jahren IEC Standard und die PubSub Erweiterungen seit 2 Jahren. OPC UA ist mittlerweile der etablierte de-facto Standard für Industrial IoT, mit Unterstützung von SAP, PTC, Amazon, Google und Microsoft.