In modernen Industrie-4.0-Umgebungen stehen Unternehmen vor der Herausforderung, Daten aus heterogenen OT- und IT-Systemen effektiv nutzbar zu machen. Eine Unified Namespace (UNS) Architektur schafft hierfür einen zentralen Datenraum (Namespace), in welchem sämtliche Fabrikdaten zusammenfließen. Dieser Namespace dient als Wahrheitsquelle (Single Source of Truth) für alle Systeme. Anstatt Daten mehrfach in verschiedenen Systemen vorzuhalten, greifen alle Beteiligten auf dieselbe, konsistente Datenbasis zu. Damit dieser Ansatz zuverlässig funktioniert, bedarf es klarer Prinzipien. Diese legen fest, wie Systeme entkoppelt, Daten harmonisiert und Sicherheit gewährleistet wird. Der folgende Artikel stellt die wichtigsten Designprinzipien der Unified Namespace (UNS) Architektur vor und zeigt, wie sie eine skalierbare und robuste Gesamtarchitektur ermöglichen.
1. Designprinzip: Publish Once, Distribute Everywhere
Alle OT- und IT-Systeme kommunizieren lose gekoppelt über den Unified Namespace (UNS), anstatt über direkte Punkt-zu-Punkt-Verbindungen.
Technischer Hintergrund: Datenquellen publizieren ihre Informationen einmalig in den Namespace (publish once). Aus diesem Namespace können dann beliebig viele Datenkonsumenten diese Informationen abonnieren (distribute everywhere). Anstatt direkte Abhängigkeiten zwischen Systemen zu schaffen, kommunizieren alle Systeme über diesen zentralen Namespace (Datenraum) und Protokolle wie MQTT.
Design-Implikationen:
- Reduzierter Aufwand: Neue Maschinen oder Applikationen müssen lediglich an einen Namespace angebunden werden, anstatt in ein Geflecht bestehender Schnittstellen.
- Entlastung von Netzwerk und Geräten: Die Datenbereitstellung erfolgt durch einmaliges Publizieren. Insbesondere für ressourcenbeschränkte Systeme wie SPSen reduziert dies die Kommunikationslast, da keine mehrfachen Pull-Abfragen erforderlich sind.
- Höhere Flexibilität: Der UNS fungiert als entkoppelte Integrationsschicht. Hierdurch lassen sich System unabhängig aktualisieren, austauschen oder erweitern ohne die Architektur zu beeinträchtigen.
2. Designprinzip: Verteilte Architektur
Entgegen einem weit verbreiteten Irrtum ist ein Unified Namespace (UNS) nicht mit einem zentralen Broker gleichzusetzen. Vielmehr handelt es sich um eine Architektur mit mehreren lokalen UNS-Instanzen, verteilt auf der Edge in Werken und Produktionslinien.
Technischer Hintergrund: Jede lokale UNS-Instanz kann einen eigenen MQTT-Broker oder vergleichbare Kommunikationskomponenten enthalten. Sie stellt Daten kontextreich für lokale Applikationen bereit und arbeitet bei unterbrochener Verbindung autark. Falls erforderlich, werden ausgewählte Daten aus lokalen UNS-Instanzen in übergeordnete oder zentrale Instanzen übertragen – etwa auf Konzern-Ebene. Dies erfolgt gezielt und regelbasiert, beispielsweise über MQTT-Bridging oder konfigurierbare Forwarding-Mechanismen.
Design-Implikationen:
- Lokale Autonomie und Performance: Edge-Instanzen arbeiten unabhängig und stellen sicher, dass Anwendungen bei minimaler Latenz auch bei Netzwerkausfall weiterlaufen.
- Globale Datenverfügbarkeit: Zentrale UNS-Instanzen aggregieren ausgewählte Daten standortübergreifend.
- Skalierbarkeit: Neue Standorte oder Produktionslinien können durch Hinzufügen lokaler UNS-Instanzen schnell integriert werden.
3. Designprinzip: Report-by-Exception
Im UNS sollten Datenflüsse nach dem Prinzip „Report-by-Exception“ erfolgen: Informationen werden nur dann publiziert, wenn ein Wert seinen Zustand ändert oder ein definiertes Ereignis auftritt.
Technischer Hintergrund: „Report by Exception“ ist ein in der Automatisierungstechnik bewährtes Verfahren, das unnötige Datenübertragung vermeidet. Im Gegensatz zum zyklischen Polling – bei dem Daten unabhängig von Änderungen in festen Intervallen gesendet werden – reduziert dieser Ansatz die Kommunikationslast erheblich. Datenpunkte erzeugen nur dann eine Nachricht, wenn tatsächlich eine neue Information vorliegt. Push-basierte Protokolle wie MQTT unterstützen dieses Muster nativ, indem sie Zustandsänderungen sofort an alle Abonnenten verteilen. Für Legacy-Systeme ohne Event-Unterstützung kann Polling als Fallback eingesetzt werden, sollte jedoch klar begrenzt bleiben.
Design-Implikationen:
- Optimierte Ressourcennutzung: Minimale Bandbreiten- und CPU-Belastung, da nur relevante Änderungen publiziert werden.
- Geringere Latenz: Zustandsänderungen werden unmittelbar übertragen, ohne auf Abfragezyklen zu warten.
- Integration von Altsystemen: Polling bleibt möglich, wird aber auf Systeme ohne native Eventfähigkeit beschränkt.
4. Designprinzip: Modularität
Eines der zentralsten Designprinzipien der Unified Namespace (UNS) Architektur ist die Aufteilung in klar abgegrenzte Module, die jeweils eine definierte Funktion erfüllen.
Technischer Hintergrund: Die funktionale Trennung ermöglicht unabhängiges Deployment, individuelle Skalierung und eine gezielte Optimierung jeder einzelnen Schicht. Änderungen oder Störungen in einer Komponente wirken sich nicht direkt auf andere aus, was die Gesamtarchitektur deutlich robuster und anpassungsfähiger macht. Die modulare Struktur eines UNS umfasst typischerweise folgende Schichten (hier finden Sie weitere Details):
- Konnektivität – Anbindung verschiedenster Datenquellen und IT/OT Protokolle.
- Harmonisierung – Semantische Normalisierung, Datenmodellierung und Strukturierung nach einheitlichen Standards.
- Single-Source-of-Truth – Zentraler Namespace zur Verteilung aller Datenströmen in Echtzeit.
- Microservices – Gekapselte funktionale Logiken zur Verarbeitung, Aggregation und Analyse von UNS-Daten.
- Management- und Security – Zentrales Monitoring, Konfigurationsmanagement, Rollen- und Rechteverwaltung sowie Sicherheitsrichtlinien.
Design-Implikationen:
- Bessere Wartbarkeit: Fehler oder Updates betreffen nur die jeweilige Schicht.
- Hohe Flexibilität: Einzelne Module lassen sich durch neue Technologien ersetzen, ohne das Gesamtsystem zu verändern.
- Gezielte Optimierung: Jede Schicht kann separat skaliert und technisch optimiert werden.
5. Designprinzip: Zentrale Governance
Eine verteilte UNS-Architektur benötigt zentrale Steuerungs- und Verwaltungsmöglichkeiten, um trotz dezentraler Strukturen einen konsistenten Betrieb zu gewährleisten.
Technischer Hintergrund: Über eine zentrale Benutzeroberfläche oder API lassen sich Konnektoren, Microservices, Broker und Standardisierungsregeln standortübergreifend konfigurieren und ausrollen. Templates für Topics, Polling-Zyklen oder Sicherheitsrichtlinien sorgen für konsistente Implementierungen über alle Werke hinweg. Gleichzeitig behalten lokale Standorte ihre operative Autonomie, sodass sie eigenständig agieren können, ohne den globalen Standard zu verletzen. Dieses Zusammenspiel von zentraler Governance und lokaler Freiheit ermöglicht eine skalierbare und sichere Verwaltung des UNS.
Design-Implikationen:
- Konsistente Umsetzung: Einheitliche Standards für Naming, Security und Konfiguration über alle Standorte hinweg.
- Effiziente Verwaltung: Zentrale Steuerung reduziert den Aufwand für Rollouts, Updates und Monitoring
- Lokale Autonomie: Werke und Produktionslinien können eigenständig arbeiten, bleiben aber in die globale Governance eingebettet.
6. Designprinzip: Simplicity-by-Design
Eines der wichtigsten Designprinzipien der Unified Namespace (UNS) Architektur in der Fertigungsindustrie ist die Unabhängigkeit von einzelnen Entwicklern. Stattdessen sollten sowohl IT- als auch OT-Teams die Architektur gemeinsam gestalten.
Technischer Hintergrund: In verteilten Werksorganisationen sind erfahrene Softwareentwickler eher die Ausnahme. Damit zentrale IT-Teams und dezentrale OT-Teams gleichermaßen am Aufbau und Betrieb des UNS mitwirken können, sind einfache, visuelle Werkzeuge entscheidend. Hierbei bilden Low-Code- und No-Code-Plattformen wie i-flow die Grundlage. Sie ermöglichen Datenintegration, Konfiguration und Verteilung auch ohne tiefgehende Programmierkenntnisse. So können Fachabteilungen mit dem Prozess- und Anlagen Know-how vor Ort selbstständig Systeme integrieren, ohne auf langwierige IT Tickets angewiesen zu sein.
Design-Implikationen:
- Reduzierte Abhängigkeit: Unternehmen vermeiden Engpässe durch wenige Spezialisten und erhöhen die organisatorische Resilienz.
- Schnellere Skalierung: Neue Standorte oder Anwendungsfälle lassen sich zügig einbinden, auch ohne zusätzliche Entwicklerressourcen.
- Agilität in Projekten: Änderungen an Konfigurationen können direkt durch verantwortliches Fachpersonal vorgenommen werden.
7. Designprinzip: Security-by-Design
Ein UNS kann nur als zuverlässige Datendrehscheibe funktionieren, wenn Sicherheitsmechanismen auf Protokoll-, Netzwerk- und Applikationsebene von Anfang an fest in die Architektur eingebettet sind.
Technischer Hintergrund: Beim Aufbau einer zentralen Dateninfrastruktur (und damit auch beim UNS), müssen Sicherheitsmechanismen von Anfang an integriert sein. Dazu gehören TLS-Verschlüsselung, Authentifizierung, rollenbasierte Zugriffskontrollen (RBAC), Netzwerksegmentierung und Audit-Logging. Ein zentrales User- und Rollenmanagement stellt sicher, dass Nutzer in Multi-Werk-Architekturen nur auf die für sie relevanten Daten und Systeme zugreifen. Ergänzend liefern alle UNS-Komponenten Telemetrie-Metriken und Logs für das zentrale Monitoring.
Design-Implikationen:
- Hohe Sicherheit: Durch TLS, RBAC, Audit-Logs und Netzwerksegmentierung ist Schutz standardmäßig integriert und nicht nachträglich aufzusetzen.
- Gezielte Zugriffskontrolle: Zentrales User- und Rollenmanagement verhindert unautorisierten Zugriff und sorgt für klare Zuständigkeiten in komplexen Multi-Werk-Umgebungen.
- Früherkennung von Risiken: Kontinuierliches Monitoring über Telemetrie, Metriken und Logs ermöglicht das proaktive Erkennen von Anomalien und schnelles Eingreifen.
8. Designprinzip: Edge-to-Cloud-Fähigkeit
Eine vollständig skalierte UNS-Architektur umfasst sowohl lokale Edge-Instanzen in der Fabrik als auch zentrale Deployments in Cloud-Umgebungen.
Technischer Hintergrund: Containerisierte Komponenten sind die Grundlage dafür. Sie sind leichtgewichtig, portabel und ermöglichen es, UNS-Bausteine – vom Broker über Konnektoren bis hin zu Microservices – in unterschiedlichen Umgebungen auszuführen. So können dieselben Container sowohl auf ressourcenarmen Edge-Geräten in der Fabrik als auch in hochskalierbaren Cloud-Clustern laufen. Dieses Prinzip ermöglicht hybride Deployments: Lokale UNS-Instanzen übernehmen latenzarme Verarbeitung und stellen Autonomie sicher, während zentrale UNS-Instanzen standortübergreifend Daten aggregieren und bereitstellen.
Design-Implikationen:
- Reduzierter Aufwand: Containerisierung ermöglicht einheitliche Update- und Rollout-Prozesse für alle Umgebungen – vom Edge-Gerät bis in die Cloud.
- Flexibilität: Unternehmen können frei entscheiden, wo einzelne UNS-Komponenten am meisten Mehrwert liefern – lokal, zentral oder hybrid.
- Latenzarme Verarbeitung: Kritische Daten werden lokal verarbeitet, unabhängig von Cloud-Verbindungen.
9. Designprinzip: Redundanz
Bei produktionskritischen Anwendungsfällen ist die Vermeidung von Ausfällen durch den Einsatz von Redundanz- und Fehlertoleranzmechanismen ein zentrales Ziel des UNS-Designs.
Technischer Hintergrund: Fehlertoleranz im UNS wird durch Redundanz auf mehreren Ebenen erreicht: Broker-Cluster stellen eine hochverfügbare Messaging-Infrastruktur bereit, redundante Edge-Puffer sichern Daten lokal zwischen. Automatische Re-Synchronisation nach Netzwerkunterbrechungen sorgt dafür, dass verteilte UNS-Instanzen wieder einen konsistenten Datenstand erreichen. Hierbei ist die Eliminierung von Single Points of Failure (SPOF) in allen kritischen Pfaden der Architektur das Ziel. Da Redundanz jedoch zusätzlichen Aufwand bei Setup, Konfiguration und Betrieb verursacht, empfiehlt sich ein solches Hochverfügbarkeits-Setup vor allem für produktionskritische Anwendungen, bei denen Ausfälle direkte Auswirkungen auf Produktion oder Qualität hätten.
Design-Implikationen:
- Erhöhte Ausfallsicherheit: Redundante Broker-Cluster und Edge-Puffer minimieren das Risiko von Datenverlust und Systemstillständen.
- Konsistente Datenbasis: Automatische Re-Synchronisation stellt nach Netzwerkausfällen den konsistenten Datenstand aller UNS-Instanzen sicher.
- Mehraufwand: Da Redundanz Mehraufwand bei Setup und Betrieb verursacht, ist sie insbesondere für produktionskritische Anwendungen sinnvoll.
10. Designprinzip: Datenharmonisierung
Einheitliche Datenstrukturen sind die Grundlage für Interoperabilität und Wiederverwendbarkeit im UNS.
Technischer Hintergrund: Daten sollten möglichst früh – idealerweise direkt an der Quelle – harmonisiert und semantisch beschrieben werden. Das bedeutet, dass Sensoren, Steuerungen oder Gateways ihre Daten bereits nach anerkannten Standards (z. B. OPC UA Companion Specifications, ISA-95) modellieren, bevor sie in den Namespace publiziert werden. Ergänzend sorgt ein klar strukturierter Topic-Namespace dafür, dass Informationen leicht auffindbar und systemübergreifend verständlich sind. Durch diese frühzeitige Standardisierung sinkt der Aufwand für nachgelagerte Integrationen und Datenaufbereitung erheblich.
Design-Implikationen:
- Konsistenz: Einheitliche Datenmodelle verhindern Mehrdeutigkeiten und erleichtern den Austausch zwischen Systemen.
- Effizienz: Früh harmonisierte Daten reduzieren den Aufwand für Mapping und Transformation in nachgelagerten Systemen.
- Wiederverwendbarkeit: Standardisierte Strukturen und ein sauberer Topic-Namespace erleichtern die Nutzung der Daten über Fachbereiche und Werke hinweg.
Fazit
Die Designprinzipien der Unified Namespace (UNS) Architektur sind die Grundlage für eine skalierbare, sichere und zukunftsfähige IT/OT-Integration. Sie sorgen für klare Strukturen, reduzieren Komplexität und ermöglichen eine effiziente Nutzung industrieller Daten – von der Edge bis zur Cloud. Unternehmen, die diese Prinzipien konsequent berücksichtigen, schaffen eine robuste Dateninfrastruktur und legen den Grundstein für erfolgreiche Industrie-4.0 Anwendungen.
