Neugestaltung industrieller Datenarchitekturen mit UNS und MQTT

In einer aktuellen Folge des „Augmented Ops “-Podcasts haben wir gemeinsam mit Vatsal Shah, Gründer und CEO von Litmus Automation, die sich rasch wandelnde Landschaft der industriellen Datenarchitekturen beleuchtet. Unter dem Titel„MQTT, Unified Namespace und der neue industrielle Daten-Stack“ befasst sich das Gespräch mit Shah eingehend mit Architekturen wie Unified Namespace (UNS) und Kommunikationsprotokollen wie Message Queuing Transport Telemetry (MQTT), die die Grundlage für die modernen Dateninfrastrukturen bilden, die Hersteller benötigen.

Auf der Grundlage seiner Erfahrungen als Automatisierungsingenieur, in deren Rahmen er mit vielen der etablierten Anbieter in diesem Bereich zusammengearbeitet hat, bis hin zur Gründung von Litmus und der Entwicklung einer neuen Reihe von Tools, gibt Shah Einblicke in die Herausforderungen bei der Datenintegration, mit denen viele Hersteller konfrontiert sind. Insbesondere betont er die dringende Notwendigkeit, die Welten der Informationstechnologie (IT) und der Betriebstechnologie (OT) durch eine offene, interoperable Datenarchitektur miteinander zu verbinden.

Shah erläutert die erheblichen Einschränkungen, denen er bei der Arbeit mit den bestehenden Tools von etablierten Anbietern im Bereich der industriellen Automatisierung begegnete und die ihn letztendlich dazu veranlassten, Litmus zu gründen. Die Probleme, auf die er stieß, drehten sich häufig um die Schwierigkeit, Systeme mit Komponenten zu integrieren, die verschiedene Plattformen und Anbieter umfassten. Shah berichtet, dass er und sein Team bei der Arbeit an einem Öl- und Gasprojekt vor der Herausforderung standen, Systeme von Emerson, Honeywell, Fisher, Rosemount und Siemens so zu vereinheitlichen, dass sie alle auf eine einzige Datenbank zugreifen konnten. Dies erforderte ein Maß an Integration über mehrere verschiedene Systeme hinweg, das mit den vorhandenen Tools nicht effizient erreicht werden konnte.

Die einzige Lösung, die ihnen damals zur Verfügung stand, bestand darin, eigenen Code in Visual Basic zu schreiben – ein Vorgang, der nicht nur zeitaufwendig war, sondern auch nicht die für moderne industrielle Abläufe erforderliche Skalierbarkeit und Flexibilität bot. Die bestehenden Lösungen versagten allesamt dabei, die OT-Daten auf effiziente Weise für IT- und andere Systeme verfügbar zu machen.

Für Shah stand damals die Lösung der technischen Herausforderungen im Vordergrund, die Gründung eines Unternehmens war zweitrangig: „Ich wusste nicht, ob ich das Unternehmen gründen würde, aber wir wollten einfach nur loslegen und dieses Problem lösen.“ Schließlich gründete er Litmus Automation mit dem Ziel, eine Konnektivitätsplattform zu schaffen, die eine nahtlosere Integration ermöglicht und es Unternehmen erlaubt, ihre OT-Daten system- und plattformübergreifend effektiver zu nutzen.

Shah betont die entscheidende Rolle des „Unified Namespace“(UNS) bei der Modernisierung industrieller Datenarchitekturen – und hebt dabei dessen zentrale Funktion bei der Überbrückung der Kluft zwischen IT und OT hervor. „Im OT herrscht Chaos. Die IT braucht die Daten sofort. Es muss eine gemeinsame Basis zwischen beiden geben“, erklärt Shah die Notwendigkeit des UNS.

Im Gegensatz zu den herkömmlichen ISA-95- oder Purdue-Modellen nutzt das UNS eine Hub-and-Spoke-Architektur mit einem zentralen Message Broker, an den sich alle Komponenten – von Maschinen in der Fertigung bis hin zu QMS ERP – über ein offenes Kommunikationsprotokoll anschließen können. Dadurch entfällt die Notwendigkeit, jedes Mal, wenn Daten zwischen zwei Knoten im Namensraum ausgetauscht werden müssen, dedizierte Punkt-zu-Punkt-Verbindungen herzustellen, was eine wesentlich flexiblere und skalierbarere Infrastruktur ermöglicht.

Shah ist der Ansicht, dass Hersteller einen offenen, interoperablen Rahmen benötigen, der den Datenaustausch und die Integration über eine Vielzahl von Systemen hinweg erleichtert. Mit der Einführung von UNS können Hersteller neue Systeme schneller integrieren und gleichzeitig „Citizen Developer“ unterstützen, indem ihnen der Zugriff auf Daten aus allen Bereichen des Unternehmens erleichtert wird.

Wie er erklärt, entscheidet bei einem einheitlichen Namensraum „OT, welche Art von Daten übertragen werden und wie diese organisiert werden. Die IT entscheidet, wie diese Daten genutzt werden, wie ihre Sicherheit gewährleistet wird und wie sie mit dem richtigen Kontext versehen werden, den alle intelligenten Anwendungen benötigen.“

Trotz des revolutionären Potenzials dieser Architektur räumt Shah ein, dass aufgrund der Einschränkungen des von ihr genutzten Datenübertragungsprotokolls – MQTT – weiterhin Herausforderungen bestehen. Das Protokoll ist offen, ressourcenschonend, basiert auf dem Publish-Subscribe-Prinzip und lässt sich so konfigurieren, dass es nur bei Ausnahmen Meldungen sendet, was es ideal für UNS-Anwendungsfälle macht. Er argumentiert jedoch, dass die MQTT-Spezifikation weiter verfeinert werden muss, um Implementierungen des Unified Namespace in großem Maßstab zu unterstützen.

Er merkt an: „MQTT hat einen langen Weg zurückgelegt … Aber es liegt noch ein langer Weg vor uns.“ Um den Anforderungen einer Infrastruktur im Unternehmensmaßstab gerecht zu werden und mit den Fähigkeiten von Datenstromprozessoren wie Kafka mithalten zu können, argumentiert Shah, dass das Protokoll Verbesserungen in Bezug auf Ausfallsicherheit und Skalierbarkeit benötigt. Er ist der Ansicht, dass dies der Grund dafür ist, dass IT-Organisationen MQTT noch nicht als die erforderliche umfassende, zukunftssichere Grundlage ansehen. Eine der Weiterentwicklungen von MQTT, die darauf abzielt, den Anforderungen von Herstellern gerecht zu werden, ist die Sparkplug-B-Spezifikation.

Shah erklärt, dass MQTT zwar auf der Transportschicht datenunabhängig ist, Sparkplug B jedoch ein strukturiertes Format zur Organisation von Daten eingeführt hat, das die Integration vereinfachen kann. Er wies jedoch auch auf die Einschränkungen von Sparkplug B hin, insbesondere auf dessen engen Anwendungsbereich. Zwar eignet es sich gut für die Organisation standardisierter Daten von edge devices und SCADA-Systemen gut geeignet ist, „muss man, sobald es um stärker analysierte Daten, abgeleitete Daten, kontextbezogene Daten oder Metadaten geht, über Sparkplug B hinausdenken“, argumentiert Shah.

Letztendlich vertritt er die Ansicht, dass Sparkplug B aufgrund seiner weniger flexiblen Nutzlaststruktur für die vielfältigen Anwendungsfälle ungeeignet ist, die erforderlich sind, um OT und IT so zu verbinden, wie es ein einheitlicher Namensraum (Unified Namespace, UNS) anstrebt. Es sind weitere Entwicklungen bei den Datentransportprotokollen erforderlich, damit Unternehmen die Vorteile, die die UNS-Architektur verspricht, voll ausschöpfen können.