Der Unified Namespace — kurz UNS — beschreibt einen gemeinsamen, hierarchisch benannten Datenraum, in dem der jeweils aktuelle Stand aller relevanten Werte eines Unternehmens liegt. Quellen veröffentlichen dorthin, Verbraucher abonnieren von dort. Beide kennen einander nicht; sie kennen nur den Namen der Information.

Der Begriff stammt aus der Praxis, nicht aus einer Norm — geprägt und verbreitet wurde er vor allem in der US-amerikanischen Automatisierungsberatung. Er beschreibt ein Architekturmuster: ereignisgesteuert statt abfragegetrieben, benannt statt verdrahtet, eine Quelle der Wahrheit statt vieler Kopien.

Der Namensraum hält dabei immer den aktuellen Stand: Wer ihn abfragt, bekommt den Wert von eben, nicht den Verlauf. Diese Nähe zur Echtzeit ist der eigentliche Gewinn gegenüber nächtlichen Exporten — und sie ist der Grund, warum sich Sensorik und IIoT-Geräte ohne Umweg über die Leitebene anschließen lassen: Sie veröffentlichen an ihren Platz in der Struktur und sind damit für jedes berechtigte System verfügbar.

In der klassischen Pyramide reicht jede Ebene Daten an die nächste weiter: Feldebene, Steuerung, SCADA, MES, ERP. Das Modell hat die Automatisierung jahrzehntelang getragen — und es hat drei Eigenschaften, die heute stören:

• Kontext geht unterwegs verloren. Was auf jeder Ebene neu verdichtet wird, lässt sich oben nicht mehr auf die Quelle zurückführen.
• Jede Ebene ist ein Projekt. Eine neue Auswertung braucht Änderungen in mehreren Systemen — und in mehreren Zuständigkeiten.
• Der Weg ist einseitig. Nach unten zurück fließt selten etwas, und wenn, dann als Sonderweg.

Der UNS bricht diese Reihenfolge auf. Er ersetzt die Ebenen nicht — Steuerung und MES bleiben, was sie sind — aber er nimmt ihnen die Rolle des Datenboten.

Dazu kommt ein zweites Problem, das sich erst mit der Größe zeigt. Wo Systeme Punkt zu Punkt gekoppelt werden, wächst die Zahl der Verbindungen quadratisch: sechs direkt verbundene Systeme ergeben fünfzehn Strecken, zehn ergeben fünfundvierzig. Über einen gemeinsamen Namensraum sind es sechs beziehungsweise zehn Anbindungen. Genau darin liegt die Skalierbarkeit des Prinzips — und der Grund, warum sich der Aufwand erst ab dem zweiten Standort deutlich auszahlt. Mehr zur Interoperabilität

Die Pyramide ordnet Geräte nach Ebenen. Der Namensraum ordnet Daten nach Bedeutung.

Die Struktur folgt der realen Ordnung des Unternehmens, nicht der Ordnung seiner Software. Bewährt hat sich eine Hierarchie entlang von Standort, Bereich, Linie und Anlage — in der Systematik von ISA-95 entspricht das den Ebenen Enterprise, Site, Area, Work Center (etwa eine Linie) und Work Unit.

Die Gliederung ist nicht frei erfunden: Sie folgt ISA-95, international als IEC 62264-1 geführt (Enterprise-control system integration — Part 1: Models and terminology). Wer sich daran hält, spricht dieselbe Sprache wie MES- und ERP-Anbieter.

Der vollständige Pfad eines Werts lautet dann etwa:

konzern/werk-nord/halle-2/linie-3/abfueller/temperatur

Daneben stehen die Werte desselben Aggregats:

konzern/werk-nord/halle-2/linie-3/abfueller/druck konzern/werk-nord/halle-2/linie-3/abfueller/status konzern/werk-nord/halle-2/linie-3/abfueller/auftrag

Ein Verbraucher, der alle Temperaturen der Halle 2 braucht, abonniert konzern/werk-nord/halle-2/# und filtert — er muss weder wissen, welche Anlagen dort stehen, noch wer sie liefert. Kommt eine Linie hinzu, veröffentlicht sie unter demselben Muster und ist damit sofort sichtbar, ohne dass ein bestehendes System geändert wird.

Drei Regeln haben sich für die Schreibweise bewährt: durchgehend Kleinbuchstaben, keine Umlaute und Leerzeichen, und keine Technik im Namen. abfueller beschreibt die Anlage und überlebt den Steuerungswechsel; sps-3-db12-dw4 beschreibt die Verdrahtung und stirbt mit ihr.

Entscheidend ist am Ende nicht die Schreibweise selbst, sondern dass sie einmal festgelegt und danach überall gleich verwendet wird.

Der UNS ist ein Ordnungsprinzip, aber er braucht eine Stelle, an der die Nachrichten zusammenlaufen. Diese Stelle ist ein Broker: Er nimmt entgegen, was Quellen veröffentlichen, und stellt es allen zu, die es abonniert haben. Quellen und Verbraucher kennen einander nie direkt — sie kennen nur den Broker und den Namen der Information.

• MQTT ist der verbreitetste Transportweg dafür: leichtgewichtig, nach dem Publish-Subscribe-Prinzip, entwickelt für unzuverlässige Verbindungen. Es beschreibt allerdings nur, wie eine Nachricht reist, nicht was in ihr steht.
• Sparkplug B schließt diese Lücke. Die Spezifikation der Eclipse Foundation (aktuell Version 3.0) gibt MQTT-Nachrichten eine feste Struktur für Zustände, Messwerte und Lebenszeichen — und regelt, woran ein Verbraucher merkt, dass eine Quelle ausgefallen ist. Ohne diese Konvention weiß niemand, ob ein Wert alt oder die Anlage stillsteht.
• OPC UA (IEC 62541) bringt ein eigenes Informationsmodell mit und wird häufig parallel eingesetzt: nah an der Maschine OPC UA, in die Breite MQTT mit Sparkplug.

Der Broker selbst ist austauschbar. Was nicht austauschbar ist, ist die Benennung darauf — deshalb ist die Wahl der Software die kleinere Entscheidung.

1. Benennung festlegen

   Struktur und Schreibweise werden verbindlich beschlossen — für alle Werke, nicht für das erste. Das ist Papierarbeit und die wichtigste Stunde des Vorhabens.

2. Quellen anbinden

   Steuerungen, Sensorik, Datenbanken und Bestandssysteme veröffentlichen in den Namensraum — über Standardkonnektoren statt über Einzelbau.

3. Kontext ergänzen

   Zu den Live-Werten kommen Stammdaten: Sollwerte, Aufträge, Anlagenmerkmale. Erst damit wird der Namensraum für Anwendungen lesbar, die die Anlage nicht kennen.

4. Verbraucher anschließen

   Dashboards, ERP, Historian und Auswertemodelle abonnieren, was sie brauchen. Neue Verbraucher kommen hinzu, ohne dass eine Quelle etwas davon merkt.

• Kein Produkt. Es gibt keine Software, deren Installation einen UNS erzeugt. Es gibt Software, die einen gut oder schlecht trägt.
• Kein Datenspeicher. Der UNS hält den aktuellen Stand. Historie gehört in einen Historian oder einen Data Lake, der aus dem Namensraum liest.
• Kein Ersatz für MES oder ERP. Diese Systeme bleiben führend für ihre Prozesse. Der UNS ist der Ort, an dem sie sich treffen.
• Kein Protokoll. MQTT ist verbreitet, OPC UA ebenso; beide sind Transportwege, nicht das Ordnungsprinzip selbst.

• Benennung nach Software statt nach Werk. Wer die Struktur aus einem bestehenden System ableitet, erbt dessen Eigenheiten — und dessen Lebensdauer.
• Alles auf einmal. Ein Namensraum entsteht mit einem Bereich und wächst. Der Versuch, vorab alle Quellen zu modellieren, kommt selten in den Betrieb.
• Ungeklärte Zuständigkeit. Wenn niemand die Schicht besitzt, wird sie nicht betrieben, sondern nur repariert.
• Kein Betriebsblick. Ein Namensraum, in dem stillschweigend eine Quelle ausfällt, liefert falsche Sicherheit — nicht fehlende Daten, sondern alte.

pronubes ist die Plattform zwischen Shopfloor und IT. Sie erfasst Produktionsdaten sicher, normalisiert sie und führt sie in eine gemeinsame Struktur — und bringt Entscheidungen als Vorgaben zurück in die Prozesse.

• pronubes Zones bildet Standorte, Bereiche, Systeme und Datenflüsse hierarchisch ab — die Benennung wird gepflegt, nicht dokumentiert.
• pronubes Edge übersetzt zwischen OPC UA, MQTT, REST, SQL und Dateiformaten und puffert bei Verbindungsverlust.
• pronubes Insights zeigt, welche Quelle liefert, welche schweigt und wie alt ein Wert ist.

Der Namensraum bleibt damit kein Diagramm, sondern ein betriebener Bestandteil der Landschaft. Mehr zur Plattform