Unified Namespace (UNS): Definition & Praxisguide

Ein Unified Namespace (UNS) ist eine Architektur, die sämtliche Daten eines Unternehmens – von der Sensorik auf dem Shopfloor bis zum ERP – in einer einheitlichen, hierarchischen Struktur zugänglich macht. Statt Dutzender Punkt-zu-Punkt-Verbindungen zwischen Systemen gibt es einen einzigen, zentralen «Namensraum», über den alle Systeme Daten publizieren und konsumieren.

Dieses Konzept löst eines der hartnäckigsten Probleme der industriellen Digitalisierung: das Spaghetti-Diagramm aus gewachsenen Schnittstellen, das jede Erweiterung teuer und jede Änderung riskant macht.

In diesem Artikel erklären wir, was ein UNS ist, wie er aufgebaut wird, warum MQTT eine Schlüsselrolle spielt und wie Unternehmen aus Industrie und öffentlichem Verkehr davon profitieren.

Das Problem: Warum klassische Integrationsarchitekturen an Grenzen stossen

In den meisten produzierenden Unternehmen sieht die Datenlandschaft heute so aus: SPS-Steuerungen sprechen mit SCADA-Systemen. SCADA liefert an ein MES. Das MES exportiert an ein ERP. Und irgendwo daneben laufen Historian, Data Lake und BI-Plattform mit eigenen Import-Jobs. Jede Verbindung ist individuell gebaut, oft mit unterschiedlichen Protokollen, Formaten und Zykluszeiten.

Das Ergebnis:

Datensilos. Die gleichen Informationen existieren in drei Systemen in drei verschiedenen Formaten – und niemand weiss, welche Version aktuell ist. Das ist ein klassisches Data-Governance-Problem.

Skalierungsprobleme. Jedes neue System braucht Einzelintegrationen zu jedem bestehenden System. Bei n Systemen entstehen n×(n-1)/2 Verbindungen – bei 10 Systemen also bereits 45.

Keine Echtzeitfähigkeit. Viele Integrationen laufen über Batch-Exporte und Datei-Transfers. Bis ein Sensorwert im Dashboard erscheint, vergehen Stunden statt Sekunden.

Hohe Änderungskosten. Wird ein System ausgetauscht, müssen alle Verbindungen zu diesem System neu gebaut werden.

Ein UNS löst dieses Problem, indem er eine zentrale Datendrehscheibe schafft: Jedes System publiziert seine Daten an genau einen Ort – und jedes andere System kann diese Daten dort abonnieren. Statt 45 Punkt-zu-Punkt-Verbindungen braucht jedes System nur noch eine einzige Verbindung zum UNS.

Aufbau eines UNS: Die ISA-95-Hierarchie

Der Unified Namespace strukturiert Daten entlang der ISA-95-Norm – dem internationalen Standard für die Integration von Unternehmens- und Steuerungssystemen. Die Hierarchie bildet die physische und organisatorische Struktur des Unternehmens ab:

Die Ebenen im Detail

Enterprise – Das Gesamtunternehmen. Auf dieser Ebene leben übergreifende Daten wie Versionierung, globale Konfigurationen und Stammdaten.

Site – Der Standort (z.B. Bern, Zürich, München). Jeder Standort hat seine eigene Infrastruktur, aber alle publizieren in denselben Namespace.

Area – Ein Bereich innerhalb eines Standorts, z.B. «Produktion Nord» oder «Logistik».

Line – Eine Produktionslinie oder Fertigungsstrasse innerhalb eines Bereichs.

Cell – Eine Zelle oder Station innerhalb der Linie, z.B. Fräsen, Montage, Härten, Prüfung, Verpackung.

Device – Das einzelne Gerät: eine CNC-Fräse, ein Roboterarm, ein Kühlsystem, eine Messstation.

Data Class – Die Art der Daten, die das Gerät liefert: Messwerte (measurements), Zustand (state), Programm (program) oder Alarme (alerts).

Tag – Der einzelne Datenpunkt: Drehzahl, Vorschub, Temperatur, Vibration.

Value – Der aktuelle Wert, z.B. 12'400 rpm.

Vertical vs. Horizontal UNS

Das Diagramm zeigt zwei Achsen:

Vertical UNS (grüne Linie) – Der Pfad von der Enterprise-Ebene bis zum einzelnen Messwert. Er bildet die hierarchische Zugehörigkeit ab: «Dieser Drehzahl-Wert gehört zur Fräse CNC-01, in der Zelle Fräsen, auf Linie 1, im Bereich Produktion Nord, am Standort Bern, der Firma MeinFirma AG.»

Horizontal UNS (orange Linien) – Die Querverbindungen auf gleicher Ebene. Sie ermöglichen den kontextübergreifenden Datenaustausch: Die Temperatur der Fräse kann direkt mit der Temperatur des Kühlsystems verglichen werden, ohne den Umweg über eine übergeordnete Ebene.

MQTT: Das Protokoll hinter dem UNS

Der Unified Namespace wird typischerweise über MQTT (Message Queuing Telemetry Transport) implementiert – ein leichtgewichtiges Publish/Subscribe-Protokoll, das speziell für IoT- und Industrie-Szenarien entwickelt wurde.

Die ISA-95-Hierarchie wird dabei direkt auf die MQTT-Topic-Struktur abgebildet:

meinfirma/bern/produktion-nord/linie1/fraesen/cnc-01/measurements/drehzahl

Jedes System, das diesen Wert braucht – sei es ein Dashboard, ein Data Lake, ein Alarmierungssystem oder ein Machine-Learning-Modell – abonniert einfach dieses Topic. Es muss nicht wissen, woher der Wert kommt oder welches Protokoll die SPS spricht.

Warum MQTT und nicht OPC UA?

Beide Protokolle haben ihre Berechtigung. OPC UA ist stark in der direkten Maschine-zu-Maschine-Kommunikation und bringt eigene Informationsmodelle mit. MQTT hingegen eignet sich besser als zentrales Rückgrat eines UNS, weil es:

• extrem leichtgewichtig ist (läuft auf Geräten mit minimalen Ressourcen),
• nativ Publish/Subscribe unterstützt (statt Request/Response),
• einfach skaliert (Millionen von Topics sind kein Problem),
• und sich nahtlos in Cloud-Plattformen integrieren lässt.

In der Praxis werden beide oft kombiniert: OPC UA auf Maschinenebene, MQTT als Transport zum UNS, und von dort weiter in Data Pipelines, Data Warehouses oder BI-Plattformen.

Sparkplug B: Struktur für industrielle MQTT-Daten

Das Sparkplug-B-Protokoll erweitert MQTT um standardisierte Nachrichtenformate für die Industrie. Es definiert, wie Geräte sich anmelden (BIRTH-Nachrichten), abmelden (DEATH-Nachrichten) und ihre Daten strukturieren. Das macht die Integration neuer Geräte zum Plug-and-Play-Erlebnis.

UNS in der Praxis: Industrie und Verkehr

Fertigungsindustrie

In der Fertigung ist der UNS der natürliche nächste Schritt für Unternehmen, die bereits Sensordaten sammeln, aber diese noch in isolierten Systemen verarbeiten. Der Weg vom Shopfloor zum Insight wird durch einen UNS massiv vereinfacht:

Predictive Maintenance – Vibrations- und Temperaturdaten von jeder Maschine fliessen in Echtzeit in den UNS. Ein ML-Modell abonniert die relevanten Topics und erkennt Anomalien, bevor ein Ausfall eintritt. Statt Sensorwerte erst stundenverzögert per Batch-Export in einen Data Lake zu schieben, stehen sie sofort für Analyse und Alarmierung bereit.

Qualitätssicherung – Prüfdaten aus der Qualitätskontrolle werden im UNS sofort mit den Prozessparametern der vorgelagerten Zellen verknüpft. Wenn ein Bauteil nicht den Spezifikationen entspricht, lässt sich der Fehler bis zur Fräse und deren Parameter zurückverfolgen – weil alle Daten im selben Namespace mit konsistenten Zeitstempeln vorliegen.

OEE-Monitoring – Maschinen-States (running, idle, error) werden in Echtzeit publiziert. Ein Dashboard berechnet daraus Overall Equipment Effectiveness (OEE) pro Linie, Bereich und Standort – aggregiert entlang der UNS-Hierarchie.

Öffentlicher Verkehr

Auch im öffentlichen Verkehr existiert eine natürliche ISA-95-ähnliche Hierarchie: Unternehmen → Betriebsbereich → Strecke → Fahrzeugflotte → Einzelfahrzeug → Subsystem → Sensor.

Flottenüberwachung – Jedes Fahrzeug publiziert GPS-Position, Geschwindigkeit, Türstatus und Energieverbrauch in den UNS. Ein Leitstand abonniert die gesamte Flotte und erhält ein Echtzeitbild des Betriebs – ohne dass jedes Subsystem einzeln angebunden werden muss.

Infrastruktur-Monitoring – Weichensensoren, Schienenzustand und Oberleitungsdaten fliessen strukturiert in den Namespace. KI-Modelle können diese Daten nutzen, um Wartungsbedarf vorherzusagen – etwa für Schienenkopfkonditionierung oder akustische Schadenserkennung an Fahrzeugen.

Energieoptimierung – Traktionsenergie, Rekuperation und Nebenverbraucher jedes Fahrzeugs im UNS verfügbar. Analytics-Modelle identifizieren Einsparpotenziale pro Strecke und Fahrprofil.

UNS vs. Data Lake vs. Data Warehouse

Ein häufiges Missverständnis: «Wir haben doch schon einen Data Lake – wozu noch ein UNS?»

Die Antwort: Ein UNS ersetzt weder Data Lake noch Data Warehouse – er ergänzt sie als Echtzeitschicht.

In einer modernen Manufacturing Data Architecture fliesst der Datenstrom so: Sensoren → UNS (Echtzeit) → Data Pipeline → Data Lake (Rohdaten) → Data Warehouse (modelliert) → Dashboards und KI. Der UNS ist die erste Meile – er strukturiert die Daten bereits am Entstehungsort.

Plattformen wie Microsoft Fabric können als nachgelagerter Konsument des UNS dienen und die Daten in einem Lakehouse für langfristige Analysen aufbereiten. Die Kombination mit dbt ermöglicht dann die automatisierte Transformation für BI und Reporting.

Implementierung: In 5 Schritten zum UNS

1. Datenlandschaft kartieren

Bevor ein UNS gebaut wird, braucht es eine Datenlandkarte: Welche Systeme existieren? Welche Daten produzieren sie? In welchem Format? Wie oft? Diese Bestandsaufnahme ist die Grundlage für das Topic-Design.

2. ISA-95-Hierarchie definieren

Die physische und organisatorische Struktur des Unternehmens wird auf die ISA-95-Ebenen abgebildet. Hier wird festgelegt, wie tief die Hierarchie gehen soll und welche Namenskonventionen gelten. Konsistenz ist entscheidend – eine saubere Data Governance zahlt sich hier direkt aus.

3. MQTT-Broker aufsetzen

Ein industrietauglicher MQTT-Broker (z.B. HiveMQ, EMQX, Mosquitto Pro) bildet das technische Rückgrat. Er muss hochverfügbar, skalierbar und sicher sein – insbesondere wenn er die Brücke zwischen OT (Operational Technology) und IT schlägt.

4. Edge-Konnektoren einrichten

Geräte und Legacy-Systeme (SPS, SCADA, MES) werden über Edge-Konnektoren an den MQTT-Broker angebunden. Protokollkonverter übersetzen OPC UA, Modbus, Profinet oder proprietäre Protokolle in MQTT-Topics.

5. Konsumenten anbinden

Dashboards, Data Pipelines, Alarmsysteme und ML-Modelle abonnieren die relevanten Topics. Hier schliesst sich der Kreis zur bestehenden BI-Plattform und den analytischen Systemen.

Wann lohnt sich ein UNS?

Ein Unified Namespace ist besonders wertvoll, wenn mehrere der folgenden Punkte zutreffen:

• Sie haben mehr als 5 Systeme, die Daten austauschen müssen (SPS, SCADA, MES, ERP, BI, Data Lake …).
• Sie kämpfen mit Datensilos – die gleiche Information existiert in mehreren Systemen in unterschiedlichen Versionen.
• Sie wollen Echtzeitdaten für Dashboards, Alarmierung oder Machine Learning nutzen, bekommen diese aber aktuell nur mit Stunden Verzögerung.
• Sie planen einen neuen Standort oder eine Erweiterung und wollen die Integration von Anfang an skalierbar aufbauen.
• Sie haben bereits begonnen, Excel durch strukturierte Systeme abzulösen, und suchen die nächste Stufe der Datenarchitektur.

Wenn Sie unsicher sind, wo Ihre Organisation in Sachen Datenreife steht, ist eine Datenmaturitätsanalyse ein guter Startpunkt. Auf dieser Basis lässt sich einschätzen, ob ein UNS der richtige nächste Schritt ist oder ob zuerst Grundlagen wie Datenstrategie und Data Governance geschaffen werden müssen.

Wie wir Sie unterstützen

Substring begleitet Unternehmen aus Industrie und öffentlichem Verkehr beim Aufbau moderner Datenarchitekturen – von der ersten Datenlandkarte über die Datenstrategie bis zur Implementierung von Data Pipelines, Echtzeitplattformen und analytischen Systemen.

Unser Team aus Data Consultants, BI-Spezialisten und AI-Engineers kennt sowohl die OT- als auch die IT-Seite. Wir wissen, wie eine SPS tickt, wie MQTT-Broker skaliert werden und wie die Daten am Ende im Power-BI-Dashboard landen.

Sie denken über einen Unified Namespace nach – oder haben Fragen zur Integration Ihrer Shopfloor-Daten? Kontaktieren Sie uns für ein unverbindliches Gespräch.

Weiterführende Glossar-Einträge

• Vom Shopfloor zum Insight – Wie Produktionsdaten zu Erkenntnissen werden
• Manufacturing Data Architecture – Referenzarchitektur für Fertigungsdaten
• Was ist eine Data Pipeline? – Daten von A nach B bewegen
• Was ist ein Data Lake? – Rohdatenspeicher für grosse Mengen
• Was ist ein Data Warehouse? – Strukturierte Datenhaltung für Analytics
• OLAP und OLTP – Operative vs. analytische Datenverarbeitung
• Big Data – Wenn Datenmengen explodieren
• Data Governance – Datenqualität organisatorisch sichern
• Datenlandkarte erstellen – Bestandsaufnahme als erster Schritt
• Microsoft Fabric für Verkehrsunternehmen – Cloud-Plattform als UNS-Konsument

‍