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 Bausteine einer Unified Namespace (UNS) Architektur 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 Bausteine einer Industrial UNS-Architektur inkl. Anforderungen im Industrie 4.0 Kontext dargestellt.
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.
Bausteine der Unified Namespace (UNS) Architektur
Ein Unified Namespace (UNS) basiert auf 6 funktionalen Bausteinen, die gemeinsam eine skalierbare, resiliente und semantisch konsistente Datenarchitektur für industrielle Anwendungen schaffen. Im Folgenden werden die zentralen Bausteine dieser Architektur vorgestellt.
1. IT/OT Konnektivität: Gateway in den Single-Source-of-Truth
Der Konnektivitäts-Layer bildet einen zentralen Baustein 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. Harmonisierung – der Schlüssel zur Skalierbarkeit
Der Harmonisierungs-Layer bildet das 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. 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 Kommunikation mit hoher Frequenz, je nach Anforderung auf Basis von MQTT, NATS oder Kafka. Sofern entsprechende Anforderungen vorhanden sind, kombinieren Unternehmen mehrere Broker-Technologien, um etwa hohe Datenraten als auch Robustheit und Integrationstiefe entlang der gesamten OT/IT-Topologie sicherzustellen.
- MQTT eignet sich durch seine leichtgewichtige Architektur ideal für die Anbindung von Tausenden bis Millionen IoT-Geräten, etwa Maschinen und Sensoren an die IT.
- Kafka dient als skalierbares Backbone für Streaming, Verarbeitung und Analyse großer Datenmengen in der IT.
- NATS kombiniert niedrige Latenz mit hoher Performance und eignet sich für hybride Szenarien.
- Relationale Datenbanken (z. B. SQL) für strukturierte, transaktionale Daten.
4. Microservices – verteilte Logik im Unified Namespace (UNS)
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.
Typische Beispiele für Microservices sind:
- OEE-Berechnung (Overall Equipment Effectiveness)
- Datenanreicherung durch Stamm- oder Prozessdaten
- Rückmeldungen und Materialbuchungen an ERP-Systeme (z. B. Fertigmeldungen oder Verbrauchsbuchungen)
- Condition Monitoring für Maschinen und Anlagen
- Anomalieerkennung auf Basis von Echtzeitdaten
- Traceability-Services zur Rückverfolgung von Material- und Prozessdaten
- Qualitätsanalysen z. B. auf Basis von Messdaten oder Ausschussquoten
- Energy Monitoring zur Erfassung und Auswertung von Energieverbrauchsdaten
5. Management: UNS Monitoring, Deployment und Governance
Der Management Layer bildet die orchestrierende Schicht der UNS-Architektur. Es bündelt zentrale Funktionen für Überwachung, Steuerung und Governance des gesamten UNS-Ökosystems – von der Edge bis zur Cloud. Dazu zählt insbesondere das standortübergreifende Deployment, Konfigurationsmanagement und Monitoring aller operativen Bausteine wie Konnektoren, Broker und Microservices. Ein zentrales Management ermöglicht:
- Zentrale Verwaltung dezentraler Edge-Instanzen und Message Broker
- Rollout und Aktualisierung von Konfigurationspaketen per Klick
- Konfiguration und Management von zentralen und lokalen Redundanz und Failover Mechanismen
- Überwachung des Systemzustands durch Metriken, Logs und Alerts (z. B. über Prometheus)
- Durchsetzung von Sicherheits- und Zugriffsrichtlinien (RBAC, Zertifikatsmanagement)
- Integration in CI/CD-Prozesse
- Zentrale Template Verwaltung und Instanziierung für wiederkehrende Konfigurationen (z.B. Harmonisierungen, Microservices)
- Verwaltung und Versionierung von Konfigurationen (z.B. semantische Modelle, Microservices)
Das Management fungiert damit als zentraler Zugangspunkt in das UNS-Ökosystem. Ohne diesen Baustein lässt sich ein UNS nicht über Fabrikgrenzen hinweg skalieren.
6. Sicherheit im Unified Namespace (UNS)
Sicherheit ist essenziell für den stabilen und vertrauenswürdigen Betrieb einer UNS-Architektur – insbesondere im industriellen Kontext mit hohen Anforderungen an Verfügbarkeit, Integrität und Vertraulichkeit. Sicherheit ist daher ein durchgängiges Querschnittsthema und muss beim Architekturdesign berücksichtigt werden („Security-by-Design“). Denn: Ein UNS verarbeitet sensible Produktionsdaten über unterschiedlichste Ebenen und Systeme hinweg – vom Sensor bis zur Cloud. Um Manipulation, Datenverlust oder unberechtigten Zugriff zu verhindern, sind geeignete Schutzmechanismen auf allen Schichten erforderlich:
- Transportverschlüsselung über TLS (z. B. für MQTT, REST, OPC UA)
- Authentifizierung & Autorisierung über X.509-Zertifikate, API-Keys oder OAuth2
- Feingranulare Zugriffskontrollen (Role-Based Access Control, RBAC)
- Unterstützung einer segmentierten Netzwerkinfrastruktur zur Trennung von OT- und IT-Netzen
- Audit-Logging für revisionssichere Nachvollziehbarkeit aller Zugriffe
- Zentrales Zertifikatsmanagement für alle Komponenten
Die Sicherheitsarchitektur muss zentral konfigurierbar und über alle Standorte hinweg konsistent ausrollbar sein – idealerweise über die Management-Komponente. Nur so lässt sich ein ganzheitlich abgesicherter Datenraum etablieren, der auch regulatorischen Anforderungen wie ISO 27001 oder NIS2 gerecht wird.
Anforderungen im industriellen Kontext
Je nach Anwendungsfall müssen die UNS-Bausteine spezifische Anforderungen erfüllen. Die folgende Übersicht fasst typische Anforderungen im industriellen Kontext zusammen – von Konnektivität und Datenharmonisierung bis hin zu Governance, Skalierbarkeit und Sicherheit.
Bausteinspezifische Anforderungen
| Funktion | Anforderung | Beschreibung |
|---|---|---|
| 1. 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. | |
| 2. 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. | |
| 3. 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. | |
| 4. 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. | |
| 5. Management | 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. |
| Monitoring und Logging | Alle Komponenten stellen zur Überwachung des Gesamtsystems Telemetrie-Daten, Metriken und Logs bereit. | |
| Zentrale Sicherheitskonfiguration | Sicherheitsarchitektur muss zentral konfigurierbar und über alle Standorte hinweg konsistent ausrollbar sein. | |
| 6. Sicherheit | Security-by-Design | Integriert grundlegende Sicherheitsmechanismen wie TLS-Verschlüsselung, RBAC, Netzwerksegmentierung und Audit-Logging. |
| Zertifikatsmanagement | Ermöglicht zentrale Verwaltung und Erneuerung von TLS-Zertifikaten über alle Systemkomponenten hinweg. | |
| Zugriffskontrolle | Unterstützt feingranuliertes Benutzer- und Rollenmanagement für Daten und Dienste – idealerweise integrierbar in zentrale Identitätsdienste wie Azure Entra ID. |
Bausteinü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. |
| 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). |
| 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. |
| 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. |
Unified Namespace (UNS) Referenzarchitektur
Die Umsetzung eines Unified Namespace (UNS) erfordert ein schlüssiges, komponentenbasiertes Architekturdesign. Ein praxiserprobter Aufbau folgt dabei dem in diesem Artikel beschriebenen Prinzip der funktionalen Trennung: Konnektivität, Harmonisierung, Single-Source-of-Truth (SSOT), Microservices, Management und Sicherheit sind klar abgegrenzte, aufeinander abgestimmte Funktionen. In einem typischen Architekturdesign werden diese Funktionen entlang von drei Infrastrukturschichten realisiert: Edge, Message Layer und zentralem Management. Eine konkrete Umsetzung zeigt das folgende Architekturdiagramm.
Dabei spiegeln sich die Funtkionen 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 SSOT, 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 hybride Edge-to-Cloud-Fähigkeit – und lässt sich nahtlos in bestehende IIoT-Landschaften integrieren. Lokale Knoten arbeiten dabei autark und synchronisieren sich 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.
