Unified Namespace (UNS): Definition, Architektur und Einführung

Das Problem: Punkt-zu-Punkt-Verbindungen und die Automatisierungspyramide

In den meisten Fabriken ist jedes System direkt mit den anderen verbunden. Das MES holt sich Daten von der Steuerung, das ERP vom MES, und das Energiemonitoring hat eigene Anschlüsse. Mit jeder neuen Anwendung wächst die Zahl der Verbindungen, bei n Systemen im schlimmsten Fall auf n × (n−1) / 2. Bei 10 Systemen sind das bis zu 45 Einzelverbindungen, bei 20 Systemen schon 190, die alle aufgebaut und gepflegt werden müssen.

Die klassische ISA-95-Automatisierungspyramide verstärkt das Problem. Daten wandern Schicht für Schicht nach oben und verlieren dabei Aktualität und Kontext. Typische Folgen:

• Datensilos: Informationen liegen in proprietären Formaten und sind nur für eine Anwendung nutzbar.
• Hoher Integrationsaufwand: Jede Schnittstelle muss einzeln gebaut, dokumentiert und gewartet werden.
• Fehlender Kontext: Ein Rohwert wie „73,4“ sagt ohne Einheit, Maschine und Zeitpunkt nichts aus.
• Keine Skalierung: Was in einem Werk funktioniert, muss im nächsten neu gebaut werden.

Wie sich dieser „Datendschungel“ konkret anfühlt, beschreibt unser Beitrag Kein Unified Namespace, keine Smart Factory.

So funktioniert ein Unified Namespace: die Architektur

Der UNS ersetzt die vertikale Pyramide durch eine horizontale Datendrehscheibe. Alle Systeme docken an eine zentrale Stelle an, statt direkt miteinander zu sprechen.

Publish/Subscribe statt Punkt-zu-Punkt

Datenquellen (Publisher) senden neue Werte an den UNS, sobald sie sich ändern. Anwendungen (Subscriber) abonnieren genau die Daten, die sie brauchen. Publisher und Subscriber kennen sich nicht. Eine neue Anwendung braucht deshalb keine neue Schnittstelle zur Maschine, sondern nur ein Abo.

MQTT als De-facto-Standard

Die meisten UNS setzen auf MQTT: leichtgewichtig, asynchron, mit geringer Latenz und breiter Unterstützung in OT und IT. OPC UA bleibt wichtig, vor allem für die Anbindung und Modellierung auf Maschinenebene. In der Praxis ergänzen sich beide: OPC UA an der Maschine, MQTT im UNS. Für einheitliche Payloads und Zustandsmeldungen setzen viele Projekte zusätzlich auf die MQTT-Spezifikation Sparkplug B.

Topic-Hierarchie nach ISA-95

Ohne klare Struktur wird ein Unified Namespace schnell unübersichtlich. Bewährt hat sich eine Topic-Struktur entlang der ISA-95-Hierarchie:

So findet jede Anwendung Daten nach derselben Logik, egal in welchem Werk. Die Grafik zeigt, wie sich der Topic-Baum verzweigt und wie eine typische Payload aussieht: JSON mit Wert, Einheit, Zeitstempel und Qualität.

Kontext und Datenmodell

Erst kontextualisierte Daten schaffen Mehrwert. Ein Datenmodell legt Namenskonventionen, Einheiten und Metadaten fest, bevor die Daten publiziert werden. Damit wird aus einem Rohsignal eine Information, die MES, Analytics und KI direkt verstehen.

Edge, Werk und Enterprise

Große Unternehmen betreiben selten einen einzigen zentralen Broker. Üblich ist eine dezentrale Architektur: lokale UNS-Instanzen pro Werk für Autonomie und geringe Latenz, verbunden mit einer Enterprise-Ebene für standortübergreifende Auswertungen. Fällt die Verbindung aus, produziert das Werk weiter.

Im Video sehen Sie, wie Topics und Datenmodelle in einem UNS in der Praxis aussehen.

Die Vorteile eines Unified Namespace für die Fertigung

• Transparenz in Echtzeit: OT- und IT-Daten stehen über alle Linien und Werke in einheitlicher Form bereit.
• Weniger Integrationsaufwand: Jede Datenquelle wird einmal angebunden und steht danach allen Anwendungen zur Verfügung.
• Schnellere Use Cases: Neue Dashboards, KPIs oder KI-Modelle starten auf vorhandenen Daten, statt mit einem Integrationsprojekt.
• Skalierbarkeit: Neue Maschinen, Anwendungen und Standorte docken an die bestehende Struktur an.
• OT und IT sprechen dieselbe Sprache: Eine gemeinsame Struktur verbessert MES-, ERP- und Analytics-Integration.
• Herstellerunabhängigkeit und Datenhoheit: Offene Standards statt proprietärer Silos, die Daten bleiben unter Ihrer Kontrolle.
• Basis für KI: Kontextualisierte Echtzeitdaten sind die Voraussetzung für belastbare KI-Anwendungen. Mehr dazu in Das Fundament für KI in der Fertigung.

Herausforderungen bei der Einführung und wie Sie sie lösen

Ein UNS ist kein Selbstläufer. Wer die typischen Stolpersteine kennt, plant sie von Anfang an ein.

Unified Namespace in der Praxis: Beispiele und Use Cases

Maschinen- und Linienüberwachung

SPS-, Sensor- und Energiedaten laufen strukturiert im UNS zusammen. Daraus entstehen einheitliche KPIs wie die OEE über alle Linien, ohne pro Linie eigene Integrationen.

MES- und ERP-Integration

Fertigungsdaten werden einmal im UNS bereitgestellt. MES und ERP abonnieren nur die Informationen, die sie brauchen, etwa Auftragsstatus, Stückzahlen oder Ausschuss. Individuelle Schnittstellen entfallen. Mehr unter MES-Integration und Integration von OT und IT.

Predictive Maintenance und Condition Monitoring

Maschinen- und Sensordaten mit Kontext ermöglichen Anomalieerkennung und Wartungsprognosen. Ungeplante Stillstände lassen sich früher erkennen. Siehe Predictive Maintenance.

Multi-Site-Rollout

Mehrere Werke nutzen dasselbe Datenmodell. Lokale UNS-Instanzen verbinden sich über eine zentrale Governance-Ebene. So hat Blum Cybus Connectware als globalen Standard für seine industrielle Dateninfrastruktur gewählt.

Automobilfertigung

In der Automobilfertigung laufen Daten aus Rohbau, Lackiererei und Montage von hunderten Robotern, Steuerungen und Prüfständen zusammen. Ein UNS mit einheitlicher Topic-Struktur je Werk und Linie macht Taktzeiten, Qualitätsdaten und Stillstände werkübergreifend vergleichbar. Ein durchgespieltes Beispiel aus einem Automobilwerk zeigt der Deep Dive zur Skalierung.

Weitere Szenarien finden Sie in unseren Use Cases.

Unified Namespace vs. Data Lake und MES

Ein UNS ersetzt keine bestehenden Systeme, er verbindet sie. Die wichtigsten Abgrenzungen:

Kurz: Der UNS ist das Nervensystem, der Data Lake das Langzeitgedächtnis. Wie der UNS mit dem Konzept eines zentralen Datenhubs zusammenhängt, erklärt der Glossareintrag Factory Data Hub.

Governance und Sicherheit im Unified Namespace

Wenn alle Daten an einem Ort liegen, muss klar geregelt sein, wer was lesen und schreiben darf. Ein produktionsreifer UNS braucht:

• Rollen- und attributbasierte Zugriffskontrolle (RBAC/ABAC) bis auf Topic-Ebene
• Verschlüsselte Kommunikation zwischen allen Teilnehmern
• Auditing: Nachvollziehbar, wer wann welche Daten publiziert oder abonniert hat
• Datenqualität: Validierung von Struktur und Payload, bevor Daten in den UNS gelangen
• Föderierte Governance: Zentrale Regeln, lokale Verantwortung in den Werken

Häufige Fragen zum Unified Namespace

Was ist ein Unified Namespace einfach erklärt?

Ein zentraler Ort, an dem alle Maschinen und Systeme einer Fabrik ihre aktuellen Daten in einer einheitlichen Struktur ablegen. Jede Anwendung holt sich dort, was sie braucht.

Wofür steht UNS?

UNS ist die Abkürzung für Unified Namespace, auf Deutsch etwa „vereinheitlichter Namensraum“. In der Fertigung bezeichnet der Begriff eine zentrale Datenebene, in der Maschinen, Linien und IT-Systeme ihren aktuellen Zustand in einheitlicher Struktur teilen.

Wie sieht ein Unified Namespace Beispiel aus?

Ein Roboter in Linie 3 des Werks Hamburg publiziert seine Temperatur unter acme/hamburg/montage/linie-03/roboter-07/temperatur. Dashboard, MES und Wartungssoftware abonnieren diesen Wert, ohne direkte Verbindung zum Roboter.

Brauche ich für einen Unified Namespace MQTT?

Nicht zwingend, aber MQTT ist der verbreitetste Standard, weil er leichtgewichtig ist und Publish/Subscribe nativ unterstützt.

Was ist ein Unified Namespace Broker?

Ein UNS-Broker ist die zentrale Komponente, die alle Daten im Unified Namespace nach dem Publish/Subscribe-Prinzip verteilt. In der Praxis ist das fast immer ein MQTT-Broker: Datenquellen publizieren ihre Werte dorthin, Anwendungen abonnieren die Topics, die sie brauchen. Im Produktivbetrieb sollte der Broker hochverfügbar im Cluster laufen, damit er nicht zum Single Point of Failure wird.

Was ist der Unterschied zwischen OPC UA und Unified Namespace?

OPC UA ist ein Kommunikationsprotokoll mit Informationsmodell, meist auf Maschinenebene. Der UNS ist ein Architekturprinzip für das ganze Unternehmen. OPC UA-Daten werden häufig in den UNS eingespeist.

Was ist der Unterschied zwischen Unified Namespace und Factory Data Hub?

Ein Factory Data Hub ist die Software-Plattform, die Daten aus Maschinen und IT-Systemen sammelt, verarbeitet und verteilt. Der UNS ist das Architekturprinzip, nach dem diese Daten strukturiert und bereitgestellt werden. In der Praxis wird ein UNS häufig auf einem Factory Data Hub aufgebaut.

Welche Rolle spielt ISA-95 im Unified Namespace?

ISA-95 liefert die bewährte Hierarchie (Unternehmen, Werk, Bereich, Linie, Maschine), nach der die Topics im UNS strukturiert werden.

Lässt sich ein Unified Namespace mit bestehenden Anlagen aufbauen?

Ja. Auch ältere Steuerungen und Maschinen im Brownfield werden über eine Konnektivitätsschicht mit Protokolladaptern wie S7, Modbus oder OPC UA angebunden. Dort werden die Daten normalisiert und mit Kontext versehen, bevor sie in den UNS publiziert werden. Ein Austausch der Anlagen ist dafür nicht nötig.

Wie lange dauert die Einführung eines Unified Namespace?

Ein erster Use Case auf einer Linie ist in wenigen Wochen umsetzbar. Der Rollout auf weitere Werke geht mit Templates und Infrastructure as Code deutlich schneller als der Erstaufbau.