Im Industrial IoT hat sich die Unified Namespace (UNS) Architektur als strategischer Schritt für effizientes Datenmanagement etabliert. Damit der UNS dieser Rolle gerecht wird, ist ein durchdachtes Architektur-Design erforderlich. Dabei müssen die funktionalen Komponenten einer Unified Namespace (UNS) Architektur müssen spezifische Anforderungen in der Fertigungsumgebung erfüllen. Dazu zählen Skalierbarkeit, Edge-Fähigkeit, Redundanz sowie Sicherheit und Monitoring Fähigkeiten. Im Folgenden werden die entscheidenden funktionalen Komponenten einer Industrial UNS-Architektur inkl. typischer Anforderungen im Industrie 4.0 Kontext vorgestellt.
Der Unified Namespace (UNS) als Single-Source-of-Truth
Der Unified Namespace (UNS) ist ein Architekturprinzip zur zentralen Organisation industrieller Datenströme. Er definiert einen gemeinsamen Datenraum, in dem alle relevanten Informationen aus OT- und IT-Systemen standardisiert, zeitnah und kontextualisiert bereitstehen – unabhängig von Quelle, Format oder Standort. Der UNS fungiert dabei als Single Source of Truth für die Fabrik: Alle Systeme – von der Maschine bis zur Cloud – greifen auf denselben konsistenten Informationsstand zu. So wird vermieden, dass Daten mehrfach, inkonsistent oder isoliert verarbeitet werden.
Funktionale Komponenten der Unified Namespace (UNS) Architektur
Ein Unified Namespace (UNS) basiert auf 4 funktionalen Komponenten, die gemeinsam eine skalierbare, resiliente und semantisch konsistente Datenarchitektur für industrielle Anwendungen schaffen. Im Folgenden werden die zentralen Bausteine dieser Architektur vorgestellt.
1. Komponente: Konnektivität – das Gateway in den Single-Source-of-Truth
Der Konnektivitäts-Layer bildet eine zentrale Komponente einer Unified Namespace (UNS) Architektur. Der Layer fungiert als universeller Übersetzer (Gateway) zwischen Maschinen, Sensoren, Steuerungen, IT-Systemen und dem Single-Source-of-Truth (SSOT). Denn: In Fertigungsumgebungen existiert eine Vielzahl an Systemen. Diese Systeme nutzen verschiedenste Kommunikationsprotokolle – von OPC UA bis hin zu proprietären Protokollen wie Siemens S7, Modbus oder SAP RFC. Das Gateway sorgt dafür, dass diese heterogenen Systeme zuverlässig und konsistent in den SSOT integriert werden können.
2. Komponente: Harmonisierung – der Schlüssel zur Skalierbarkeit
Der Harmonisierungs-Layer bildet das strukturelle Rückgrat einer skalierbaren Unified Namespace (UNS) Architektur. In der industriellen OT-Landschaft liefern Maschinen, Steuerungen und Sensoren Daten in proprietären Formaten mit herstellerspezifischen Bezeichnern, Strukturen und Einheiten. Ohne zentrale semantische Harmonisierung dieser heterogenen Rohdaten entsteht Chaos im Single-Source-of-Truth. In der Folge müssten individuelle Punkt-zu-Punkt-Mappings für die Integration von OT- und IT-Systemen geschaffen werden.
3. Komponente: Single-Source-of-Truth (SSOT) für Fabrikdaten
Im Zentrum jeder Unified Namespace (UNS) Architektur steht ein zuverlässiger Datenraum, welcher als Single-Source-of-Truth (SSOT) fungiert. Dieser stellt sicher, dass alle OT- und IT-Systeme auf konsistente und eindeutig interpretierbare Daten zugreifen können.
Je nach Use Case kann diese Instanz unterschiedliche Ausprägungen annehmen. Typische Beispiele sind:
- Message Broker für eventbasierte, bidirektionale Kommunikation mit hoher Frequenz, etwa auf Basis von MQTT, NATS oder Kafka.
- Relationale Datenbanken (z. B. SQL) für strukturierte, transaktionale Daten, etwas auf Basis von Microsoft SQL.
4. Komponente: Microservices – verteilte Logik in der Unified Namespace (UNS) Architektur
Microservices bilden den skalierbaren Verarbeitungs-Layer innerhalb der UNS-Architektur. Sie kapseln funktionale Logik in klar abgegrenzte, modulare Services – etwa zur OEE-Berechnung oder zur Datenanreicherung. Dabei lässt sich jeder Service unabhängig deployen, aktualisieren und skalieren. Hierdurch lassen sich neue Anforderungen flexibel und ohne Eingriff in andere Systembestandteile umsetzen. Änderungen an einzelnen Funktionen erfordern keine Modifikationen der Gesamtarchitektur. Zudem fördert der Microservice-Ansatz abteilungsübergreifende Entwicklung: Teams können parallel an unterschiedlichen Services arbeiten. Produktionsteams können Services für Condition Monitoring entwickeln, während Qualitätsteams an produktspezifischen Auswertungen und Analysen arbeiten. Dabei greifen alle Fachbereiche auf denselben konsistenten Datenraum zu.
Anforderungen an die Unified Namespace (UNS) Architektur
Je nach Anwendungsfall in der Produktion müssen die einzelnen UNS-Komponenten unterschiedliche technische Anforderungen erfüllen. Die folgende Übersicht zeigt typische Anforderungen, die sich in industriellen IIoT-Umgebungen bewährt haben – von Konnektivität und Datenharmonisierung bis hin zu Governance, Skalierbarkeit und Sicherheit.
Komponentenspezifische Anforderungen
Komponente | Anforderung | Beschreibung |
---|---|---|
Konnektivität | Breite Protokollunterstützung | Unterstützt vielfältige OT-/IT-Protokolle wie OPC UA, REST oder SPS-Protokolle. |
SDK für Erweiterbarkeit | Eigene Erweiterungen unabhängig vom Hersteller dank SDK möglich. | |
Polling und Event-basiert | Je nach Quellsystem ist entweder Polling oder eventgetriggerte Kommunikation erforderlich. | |
Closed-Loop | Erlaubt direkte Kommunikation zwischen Maschinen für Synchronisation oder Reaktion. | |
Harmonisierung | Datenstandardisierung & Semantik | Normiert proprietäre Datenformate in standardisierte, semantisch eindeutige Informationsmodelle nach gängigen Industriestandards wie OPC UA Companions oder ISA-95. |
Lokale Datenverarbeitung | Kontextualisiert, aggregiert und reichert Maschinen- und Prozessdaten direkt an der Quelle an. | |
Data Buffering & Offline-Fähigkeit | Puffert Daten bei Verbindungsausfall zum zentralen UNS lokal auf der Edge und leitet sie später verlustfrei nach FIFO weiter. | |
Single-Source-of-Truth (SSOT) | Echtzeit- und Batch-Daten | Verarbeitet sowohl hochfrequente Maschinentelemetrie als auch Batch-Informationen (z. B. Auftragsdaten). |
Verteilbarkeit und Synchronisierung | Unterstützt verteilte SSOT-Instanzen (z.B. pro Linie, Werk oder Region) und automatische Synchronisierung für Konsistenz über Standortgrenzen hinweg. | |
Skalierbarkeit auf Edge & Cloud | SSOTs sind durch Clustering horizontal skalierbar, um hohe Durchsatzraten zu bewältigen (Cloud). Zudem unterstützen sie topologische Verteilung – z. B. dedizierter Broker pro Maschine oder Linie – für die Skalierung auf der Edge. | |
Microservices | Unabhängigkeit und Kapselung | Jeder Microservice lässt sich unabhängig von anderen Diensten bereitstellen, aktualisieren und skalieren. |
Domänenorientierung | Teams entwickeln Microservices gezielt entlang fachlicher Domänen – etwa für Maschinenverfügbarkeit, Materialverfolgung oder Qualitätsprüfung. Das vereinfacht Wartung und stärkt fachliche Verantwortlichkeit. | |
Edge- und Cloud-Fähigkeit | Microservices laufen flexibel in allen Ebenen – lokal auf Edge-Geräten für latenzkritische Anwendungsfälle oder zentral in der Cloud für datenintensive Analysen. |
Komponentenübergreifende Anforderungen
Anforderung | Beschreibung |
---|---|
Entkopplung von Systemen | Systeme sind lose über standardisierte Schnittstellen wie MQTT verbunden. Dabei dient der UNS als Puffer- und Integrationsschicht, um Systemvernetzung ohne Abhängigkeiten zu ermöglichen. |
Modularität | Der UNS besteht aus spezialisierten Komponenten. Diese können unabhängig skaliert, deployed und weiterentwickelt werden. |
Single-Source-of-Truth | Alle OT- und IT-Systeme greifen auf eine konsistente Datenbasis zu, um redundante und widersprüchliche Informationen zu vermeiden. |
Edge-to-Cloud-Fähigkeit | UNS-Komponenten sind containerisiert und können leichtgewichtig auf Edge-Geräten und flexibel in der Cloud betrieben werden. So ist ein durchgängiges Deployment-Modell realisierbar. |
Skalierbarkeit | Broker, Microservices und Konnektoren sind horizontal skalierbar (z.B. durch Clustering oder topologische Trennung und Verknüpfung pro Linie oder Maschine). |
Redundanz | Der UNS muss Ausfälle einzelner Komponenten abfangen – durch Cluster, lokale Redundanz auf der Edge, Fallback-Puffer und automatische Re-Synchronisation. |
Security-by-Design | Sicherheit ist integraler Bestandteil – u. a. durch TLS-Verschlüsselung, RBAC, Netzwerksegmentierung und Audit-Logging. Zugriff auf Daten und Systeme muss komponenten- und standortübergreifend konfigurierbar sein. |
Eventbasiert | Die Architektur ist auf eventbasierte Kommunikation optimiert, um Latenz und Ressourcenverbrauch zu minimieren. Pull-basierte Mechanismen (Polling) werden unterstützt (z.B. für SPS Kommunikation). |
Governance | Komponenten werden über eine gemeinsame Oberfläche oder API zentral verwaltet und sind dabei lokal autonom. Standortübergreifende Konfiguration und Rollouts sind per Klick möglich. |
Unterstützung von Echtzeit- und Batch-Daten | Die Architektur muss sowohl hochfrequente Echtzeitdaten als auch Batch-Informationen zuverlässig erfassen, verarbeiten und bereitstellen. |
Low-Code-Fähigkeit | Die Skalierung eines UNS ist keine Einzelleistung weniger Entwickler – sie gelingt nur über Fachbereiche hinweg. Daher unterstützten die Komponenten Low-Code, um zentrale IT- und dezentrale OT-Teams einzubinden. |
Monitoring und Logging | Alle Komponenten stellen zur Überwachung des Gesamtsystems Telemetrie-Daten, Metriken und Logs bereit – z. B. über zentrale Hubs oder Plattformen wie Prometheus. |
Performance und Latenz | Die Systemarchitektur ist auf minimale Latenzen bei tausenden Datenpunkten pro Sekunde optimiert, um lokal zeitkritische Anwendungen wie Alerts oder Steuerbefehle zu unterstützen. |
Zustellgarantien | Die Architektur bietet Zustellgarantien für Nachrichten – etwa durch QoS Level. |
Infrastrukturkomponenten im UNS
Die Umsetzung eines Unified Namespace (UNS) erfordert mehr als den Einsatz einzelner Tools – sie braucht ein schlüssiges, komponentenbasiertes Architekturdesign. Ein praxiserprobter Aufbau folgt dabei dem in diesem Artikel beschriebenen Prinzip der funktionalen Trennung: Konnektivität, Harmonisierung, Datenbereitstellung und Management sind klar abgegrenzte, aufeinander abgestimmte Funktionen. In einem typischen Architekturdesign werden diese Funktionen entlang von drei Infrastrukturkomponenten realisiert: Edge, Message Layer und zentralem Management. Eine konkrete Umsetzung zeigt das folgende Architekturdiagramm.
Die funktionalen Komponenten Konnektivität, Harmonisierung, SSOT und Microservices – spiegeln sich direkt in diesen Komponenten wider:
- i-flow Edge für die lokale Integration und Harmonisierung heterogener OT- und IT-Systeme – etwa über OPC UA, Modbus oder herstellerspezifische Protokolle.
- i-flow Broker als Single-Source-of-Truth, sorgt für die konsistente Datenverteilung entlang eines definierten MQTT-Namespaces
- i-flow Hub als Management-Plattform ermöglicht standortübergreifendes Deployment, Monitoring und Governance aller Edge- und Broker-Instanzen.
Diese Architektur folgt konsequent den in der Industrie bewährten UNS-Prinzipien – wie Modularität, Entkopplung, Skalierbarkeit und Edge-to-Cloud-Fähigkeit – und lässt sich nahtlos in bestehende IIoT-Landschaften integrieren. Lokale Knoten arbeiten dabei autark, synchronisieren sich jedoch bei Verfügbarkeit automatisch mit zentralen Systemen. So entsteht eine robuste, konsistente Infrastruktur mit einheitlichem Datenraum vom Sensor bis zur Cloud. Ein konkretes Anwendungsbeispiel dieser Architektur finden Sie hier.
Fazit
Eine leistungsfähige Unified Namespace (UNS) Architektur ist weit mehr als der Einsatz eines Message Brokers – sie ist ein strategisches Framework zur ganzheitlichen, skalierbaren und semantisch eindeutigen Integration industrieller Daten. Im Zentrum steht der SSOT als gemeinsame Datenbasis, flankiert von spezialisierten Schichten für Konnektivität, Harmonisierung und Verarbeitung. Durch diese funktionale Entkopplung lassen sich IIoT-Landschaften flexibel, robust und mandantenfähig gestalten – vom Edge bis in die Cloud. Wer den UNS entlang klar definierter Architekturprinzipien plant und umsetzt, schafft die Grundlage für durchgängige Transparenz, schnellere Innovation und eine zukunftsfähige Smart Factory.