Die Umsetzung einer Unified Namespace Architektur erfordert ein durchdachtes Design. Ein zentraler Aspekt ist die Auswahl der Komponenten für Systemintegration, Microservices und den Message Broker. Für eine erfolgreiche Skalierung ist jedoch nicht nur die Auswahl entscheidend, sondern auch die Frage, auf welcher Ebene in der IT/OT Architektur die Komponenten installiert und betrieben werden (Hosting Ebene). Hierbei ist eine häufige Frage, welche Hosting Ebene für den Message Broker optimal ist. Dieser Artikel beleuchtet daher die Leitprinzipien für die Auswahl der optimalen Ebene – Shopfloor, Edge oder Cloud.
Broker Hosting Optionen in der Unified Namespace (UNS) Architektur
Prinzipiell kann der Broker in jeder Ebene der IT/OT Architektur installiert und betrieben werden. Von der Maschinensteuerung (z.B. möglich in der CtrlX von Bosch Rexroth) bis in die Cloud (z.B. Microsoft Azure). Bei der Wahl der optimalen Ebene gilt folgende Faustregel: Die Hosting Ebene – ob Cloud, virtuelle oder physische Edge – sollte so hoch wie möglich und so niedrig wie nötig gewählt werden. So bleibt die Infrastruktur flexibel und anpassungsfähig, während sie gleichzeitig eine skalierbare Implementierung der UNS Architektur ermöglicht. Dabei hängt die Entscheidung immer von den Anforderungen des spezifischen Use-Cases sowie von der gewünschten Funktionalität ab. Hierbei gelten folgende Leitprinzipien.
Leitprinzip Nr. 1: Balance zwischen Standardisierung und Individualität
Trotz der Vorteile einer unternehmensweiten Standardisierung bleibt die Individualität der Werke ein wichtiger Aspekt im UNS-Design. Unterschiedliche IT/OT-Systemlandschaften, spezifische Wertströme und marktbezogene Anforderungen erfordern häufig maßgeschneiderte Lösungen. Erfolgreiche Unternehmen kombinieren daher eine Standardisierung für möglichst viele Anwendungsfälle mit der Flexibilität, werkspezifische Lösungen zuzulassen. Diese Philosophie prägt auch das UNS-Design. Denn die modulare und verteilte Architektur ermöglicht eine individuelle und gleichzeitig skalierbare Implementierung. Dabei werden Komponenten wie der Message Broker häufig mehrfach auf verschiedenen Architekturebenen installiert – überall dort, wo sie benötigt werden. Diese verteilte Broker-Architektur unterstützt sowohl individuelle Fabrik-Use-Cases (Factory UNS) als auch unternehmensweite Use-Cases (Enterprise UNS). Dabei sind die Broker miteinander über sogenannte Bridges verbunden, um relevante Daten und Events in Echtzeit zu synchronisieren.
Leitprinzip Nr. 2: Balance zwischen Latenz und Skalierbarkeit
Als Faustregel gilt: Je näher der Broker am Shopfloor positioniert ist, desto besser ist die Kommunikation mit niedriger Latenz. Wird der Broker hingegen auf einer höheren Architekturebene platziert, verbessert sich die Skalierbarkeit (weitere Informationen hierzu im nächsten Abschnitt). Use-Cases in der Produktion erstrecken sich typischerweise über beide Enden dieses Spektrums. Daher werden häufig lokale Broker (z. B. für einen Factory UNS) eingesetzt, die ihre Daten an übergeordnete Broker (z. B. für einen Enterprise UNS) weiterleiten. In stark verteilten Systemen können sogar mehrere lokale Broker (z.B. pro Netzwerksegment, Maschine oder Produktionslinie) erforderlich sein.
Broker Hosting: Physische vs. virtuelle Edge
Während die Vorteile eines Cloud Hostings weithin bekannt sind, sind die Unterschiede zwischen einer physischen Edge (z. B. Hosting auf Industrie-PCs) und einer virtuellen Edge (z. B. virtuelle Maschinen in einem Rechenzentrum) oftmals unklar. Gerade in der Produktion, wo industrielle Geräte große Datenmengen erzeugen, ist es entscheidend, Latenzen zu minimieren, schnelle Reaktionen auf kritische Ereignisse zu ermöglichen sowie hochfrequente Maschinendaten für die Verarbeitung in IT Systemen zu aggregieren. Genau hierfür ist das Hosting auf der Edge prädestiniert. Im Allgemeinen sind die Vorteile eines Edge Hostings für Industrial IoT Use-Cases:
- Dezentralisierte Datenverarbeitung: Datenverarbeitung und -aggregation näher an der Quelle.
- Einsparung von Bandbreite und Cloud Kosten: Weniger Datenübertragung in die Cloud.
- Schnellere Reaktionszeiten: Kritische Prozesse profitieren von minimaler Latenz.
Vorteile der physischen Edge
- Datenvorverarbeitung: Reduziert die Netzwerklast durch lokale Datenverarbeitung nahe der Produktionslinie.
- Geschlossene Regelkreise: Extrem niedrige Latenzzeiten (< 10 ms), da Steuerungsalgorithmen direkt auf Edge-Geräten ausgeführt werden.
- Offline-Funktionalität: Arbeitet auch ohne Verbindung zum Rechenzentrum zuverlässig.
- Sicherheit: Wandelt unsichere Protokolle in sichere Protokolle um, ideal z.B. für SPSen ohne Verschlüsselung.
Vorteile der virtuellen Edge
- Höhere Verfügbarkeit: Virtuelle Maschinen (VMs) bieten verbesserte Ausfallsicherheit.
- Bessere Skalierbarkeit: Besonders bei groß angelegten Implementierungen von Vorteil.
- Kosteneffizienz: Zusätzliche Hardware und Verkabelung entfallen, was Kosten spart.
Getting Started
Viele Unternehmen starten ihre Implementierung auf einer Ebene, die den ersten Anwendungsfällen entspricht. Oft ist dies die virtuelle Edge-Ebene, da sie eine gute Balance zwischen Effizienz und Skalierbarkeit bietet. Mit der Weiterentwicklung des industriellen Ökosystems wird das Broker Infrastrukut schrittweise erweitert. Neue Broker können einfach hinzugefügt werden, um zusätzliche Anwendungsfälle zu unterstützen. Bei einer Expansion auf mehrere Werke konsolidieren Unternehmen dann lokale UNS Instanzen zu einer zentralen Broker, um eine unternehmensweite UNS Struktur zu schaffen.
Fazit
Die Wahl der optimalen Hosting-Ebene für den Message Broker ist ein entscheidender Faktor für den Erfolg einer UNS-Architektur. Mit den Leitprinzipien – der Balance zwischen Standardisierung und Individualität sowie zwischen Latenz und Skalierbarkeit – lässt sich eine flexible und zukunftssichere Infrastruktur schaffen, die sowohl lokale als auch unternehmensweite Anforderungen erfüllt.
