Unified Namespace: Referenzarchitektur mit konkretem ISA-95-Topic-Schema

Ein Unified Namespace (UNS) ist ein einziger, hierarchisch geordneter und ereignisgetriebener Datenraum, in dem jedes System der Fabrik seinen aktuellen Zustand veröffentlicht und die Zustände der anderen abonniert – in der Praxis fast immer über einen MQTT-Broker. Dieser Artikel liefert, was in den meisten Konzepttexten fehlt: ein durchgezogenes Topic-Schema nach ISA-95, begründete Namensregeln, die Einordnung von Sparkplug B, ein Kriterienraster für die Broker-Auswahl und eine ehrliche Antwort auf die Frage, wann ein UNS Überbau ist.

Was ein Unified Namespace ist – und was er nicht ist

Ein Unified Namespace ist der aktuelle Zustand des gesamten Betriebs, an einem Ort, in einer Struktur, für alle lesbar. Technisch besteht er aus drei Dingen: einem Message-Broker nach dem Publish/Subscribe-Prinzip, einer verbindlichen Topic-Hierarchie und der Vereinbarung, dass jedes System seine Daten dorthin veröffentlicht und alles, was es von anderen braucht, von dort abonniert. Die deutschsprachige Wikipedia beschreibt das Konzept knapp als IIoT-Ansatz und hält fest: „Häufig wird ein MQTT-Broker als Middleware-Infrastruktur für die Implementierung des Unified Namespace verwendet.“ Der Artikel trägt allerdings einen Qualitätssicherungs-Hinweis wegen inhaltlicher Mängel, was die dünne deutsche Quellenlage gut illustriert.

Die Abgrenzung ist wichtiger als die Definition. Ein UNS ist keine Datenbank: Er hält den letzten bekannten Zustand jedes Signals, nicht dessen Historie. Er ist kein Data Lake: Dort landen Rohdaten zur späteren Analyse, im UNS liegt kuratierte, benannte Gegenwart. Er ist kein MES und kein SCADA: Beide bleiben Produzenten und Konsumenten am Broker. Und er ist kein Produkt, das man bestellt – die Arbeit steckt in der Namenskonvention und in der Disziplin, sie durchzuhalten.

Das Problem dahinter: Punkt-zu-Punkt-Integration in der Automatisierungspyramide

Die klassische Schichtung nach ISA-95 – Feld, Steuerung, Prozessleitung, Betriebsleitung, Unternehmensplanung – ist ein funktionales Modell, keine Netzwerkarchitektur. Dennis Brandl und Charlotta Johnsson schreiben dazu in der ISA-Zeitschrift InTech (Oktober 2021), die pyramidale Struktur sei zwar eine traditionelle Implementierung, werde aber vom Standard nicht vorgegeben. In der Praxis wurde die Pyramide trotzdem zur Verdrahtungsvorlage: Jedes System spricht mit dem darüber und dem darunter, und für jede Querbeziehung entsteht eine eigene Schnittstelle.

Das Problem ist nicht die einzelne Schnittstelle, sondern ihre Anzahl. Wenn jedes System potenziell mit jedem anderen Daten austauschen muss, wächst die Zahl der möglichen Kopplungen quadratisch. Jede neue Anlage und jedes neue Auswertungswerkzeug erzwingt eine neue Kopplung zu jedem System, das seine Daten braucht – und nach drei Jahren weiß niemand mehr, welche Zahl auf welchem Weg in welches Dashboard gelangt.

Kein Werk baut alle 66 Kopplungen tatsächlich. Der Effekt zeigt sich subtiler: Ein neues Energiemonitoring braucht Maschinenzustände, die bisher nur das MES kennt; eine Instandhaltungsauswertung braucht Zykluszeiten, die bisher nur im SCADA landen. Im UNS liegen diese Signale unter einem bekannten Namen bereit – der neue Konsument abonniert sie, ohne dass jemand die Steuerung anfasst. Wie sich das auf die Kopplung von MES und ERP auswirkt, behandelt MES-ERP-Schnittstelle: welches Integrationsmuster wann trägt.

Die Topic-Hierarchie: ISA-95 als Namensraum, nicht als Pyramide

Die ISA-95-Topic-Hierarchie eines UNS übernimmt vom Standard nicht die Ebenen der Pyramide, sondern die rollenbasierte Anlagenhierarchie. Die OPC-UA-Companion-Spezifikation für ISA-95 (OPC 10030) definiert diese Ebenen im Wortlaut: Ein Enterprise ist „a collection of sites and areas“, ein Site eine „physical, geographical, or logical grouping determined by the enterprise“, ein Area eine entsprechende Gruppierung unterhalb des Site, ein Work Center „the grouping of equipment scheduled by the Level 4 or Level 3 functions“ und ein Work Unit „any element of the equipment hierarchy under a work centre“. In der diskreten Fertigung heißen Work Center und Work Unit meist Produktionslinie und Arbeitszelle.

Daraus wird ein Topic-Schema mit fünf Ortsebenen, gefolgt vom Gerät, einer Signalkategorie und dem Signal selbst. MQTT trennt die Ebenen laut OASIS-Standard mit dem Schrägstrich; + steht als Platzhalter für genau eine Ebene, # für beliebig viele. Das folgende Unified-Namespace-Beispiel zeigt ein fiktives Werk mit einer Spritzgießmaschine in Halle 2, Linie 3, Zelle 7:

<enterprise>/<site>/<area>/<line>/<cell>/<device>/<kategorie>/<signal>

musterwerk/schwerin/halle-2/linie-03/zelle-07/sgm-0712/zustand/betriebsart
musterwerk/schwerin/halle-2/linie-03/zelle-07/sgm-0712/zustand/stoerung-aktiv
musterwerk/schwerin/halle-2/linie-03/zelle-07/sgm-0712/prozess/zykluszeit
musterwerk/schwerin/halle-2/linie-03/zelle-07/sgm-0712/prozess/werkzeugtemperatur
musterwerk/schwerin/halle-2/linie-03/zelle-07/sgm-0712/zaehler/gutteile
musterwerk/schwerin/halle-2/linie-03/zelle-07/sgm-0712/zaehler/ausschuss
musterwerk/schwerin/halle-2/linie-03/zelle-07/sgm-0712/energie/wirkleistung
musterwerk/schwerin/halle-2/linie-03/auftrag/aktiv
musterwerk/schwerin/halle-2/linie-03/kennzahl/oee/schicht

Abonnement aller Gutteile-Zaehler in Halle 2:
musterwerk/schwerin/halle-2/+/+/+/zaehler/gutteile

Zwei Entscheidungen sind bewusst getroffen. Erstens trägt jedes Gerät einen stabilen Bezeichner (sgm-0712) statt eines sprechenden Namens – Maschinen werden umgestellt, verkauft, ersetzt, und der Bezeichner soll das überleben. Zweitens gibt es eine Kategorieebene (zustand, prozess, zaehler, energie), damit ein Konsument alle Zähler oder alle Energiewerte einer Halle abonnieren kann, ohne jedes Signal einzeln zu kennen. Was die Zähler dann in eine sauber definierte Kennzahl verwandelt, steht in OEE berechnen: Formel, Rechenbeispiel und Datenquellen.

Payload und Zustandsverwaltung: warum Sparkplug B den Unterschied macht

Ein Topic-Schema ordnet, aber es sagt nichts darüber, was im Payload steht und wie ein Konsument den aktuellen Zustand erfährt, wenn er sich erst nach der letzten Änderung verbindet. Ohne Zusatzschicht löst das der Broker selbst: MQTT kennt das RETAIN-Flag. Der OASIS-Standard MQTT 5.0 (März 2019) schreibt vor, dass der Server eine so markierte Nachricht speichern MUSS und sie einem neuen Abonnenten je passendem Topic zustellt – sofern dessen Subscription-Option Retain Handling das nicht einschränkt (Werte 1 und 2). Ein Dashboard, das sich um 6:12 Uhr verbindet, sieht damit sofort den Zustand aller Maschinen – der Broker ist der Zustandsspiegel.

Dieser Ansatz hat drei Lücken. Der Payload ist unstrukturiert – jeder Publisher entscheidet selbst, ob eine nackte Zahl, ein JSON-Objekt oder ein Text ankommt. Es gibt keine Typisierung. Und niemand weiß, ob ein gespeicherter Wert aktuell ist oder ob die Maschine seit zwei Stunden ohne Netz läuft. Ein pragmatisches Minimum ist deshalb ein einheitlicher JSON-Payload mit Wert, Einheit, Qualität und Zeitstempel. Wer mehr Verbindlichkeit braucht, landet bei Sparkplug B.

{
  "value": 12.4,
  "unit": "s",
  "quality": "good",
  "ts": "2026-09-21T06:12:03.412Z",
  "source": "opcua:ns=3;i=1042"
}

Eclipse Sparkplug definiert laut Spezifikation einen MQTT-Topic-Namespace, ein Payload-Format und ein Session-State-Management. Die Fassung 3.0 – Revisionsverzeichnis 21. Oktober 2022, Dokumentstand 3.0.0 vom 16. November 2022 – ist seit November 2023 zugleich als ISO/IEC 20237 veröffentlicht, wie die Eclipse Foundation mitteilte. Die Mechanik: Ein Edge Node meldet sich mit einem NBIRTH, das laut Spezifikation alle Metriken enthalten MUSS, die er in dieser Sitzung jemals publizieren wird – mit Name, Datentyp und Wert. Als MQTT-Will-Message hinterlegt er ein NDEATH, das der Broker bei Verbindungsabbruch automatisch veröffentlicht. Danach folgen NDATA-Nachrichten, die alle seit dem letzten NBIRTH oder NDATA geänderten Metriken enthalten MÜSSEN (Report by Exception). Der Payload ist mit Google Protocol Buffers kodiert, Metriken können numerische Aliasse tragen.

Wichtig für den Vergleich: Sparkplug setzt bei NBIRTH und NDATA das Retain-Flag laut Spezifikation auf false; nur die STATE-Nachricht der Host-Anwendung ist retained. Der Zustandsspiegel liegt also nicht im Broker, sondern in der Host-Anwendung, die ihn aus Birth-Zertifikaten und Datenupdates rekonstruiert. Das ist sauberer – die Anwendung weiß immer, ob ein Wert lebt –, aber ein generischer MQTT-Client ohne Sparkplug-Verständnis kann mit dem Baum wenig anfangen.

Die ehrlichen Kosten: Sparkplug-Topics haben die feste Form spBv1.0/group_id/message_type/edge_node_id/[device_id] – nur drei Ortsebenen, und / ist in den Bezeichnern verboten. Ein achtstufiger ISA-95-Pfad muss also in group_id, edge_node_id oder die Metriknamen gefaltet werden. Die Werkzeugauswahl ist kleiner, weil Konsumenten Protobuf dekodieren und den Sitzungszustand nachbilden müssen; die Fehlersuche wird schwerer, weil niemand mit einem gewöhnlichen MQTT-Client mitlesen kann. Dafür bekommt man Typisierung, Lebenszeichen und ein Verhalten, das mehrere Hersteller gleich implementieren. Viele Aufbauten trennen deshalb: Sparkplug zwischen Edge und Broker, darüber ein lesbarer ISA-95-Baum mit JSON, den ein Übersetzer aus den Sparkplug-Daten speist.

Broker-Auswahl und Betrieb: die Kriterien, die im zweiten Jahr zählen

Der MQTT-Broker im Unified Namespace ist per Konstruktion ein Single Point of Failure: Fällt er aus, publiziert und abonniert niemand mehr. Das ist kein Argument gegen das Konzept, aber ein Argument dafür, den Broker wie ein Produktionssystem zu behandeln – mit Betreiber, Monitoring, Wartungsfenster und einem Plan für den Ausfall. Für die Auswahl zählen deshalb weniger die Durchsatzangaben auf der Produktseite als die Eigenschaften, die im zweiten Betriebsjahr Ärger machen oder ersparen.

Zu den HA-Optionen gehört Ehrlichkeit: Ein Broker-Cluster beseitigt den Single Point of Failure nicht, er verschiebt ihn auf das Cluster und dessen Netz. Für viele Werke ist ein einzelner, überwachter Broker mit geprobtem Neustart und Edge-Pufferung realistischer als ein Cluster, den niemand im Haus betreiben kann.

Edge-Filterung: was gar nicht erst in den UNS gehört

In den UNS gehört, was sich geändert hat – nicht, was gerade abgetastet wurde. Eine Steuerung liefert eine Werkzeugtemperatur zyklisch alle 100 ms; Dashboard, Energiemonitor und Datenbank brauchen sie nur, wenn sie sich bewegt. Ohne Filterlogik an der Kante wird ein UNS zum Kostenproblem: Der Broker verteilt Millionen identischer Werte, die Datenbank speichert sie, und niemand kann sagen, wann tatsächlich etwas passiert ist.

• —Änderungserkennung statt Abtastrate: Publiziert wird, wenn sich ein Wert um mehr als ein Totband (Deadband) ändert – bei Zählern und Zuständen jede Änderung. Dazu ein Heartbeat in festem Abstand, damit Stillstand von Ausfall unterscheidbar bleibt.
• —Aggregation an der Kante: Minimum, Maximum und Mittelwert je Minute für Prozesswerte, deren Einzelabtastung niemand konsumiert; der Rohwert bleibt bei Bedarf in einem lokalen Historian.
• —Pufferung bei Netzausfall: Der Edge-Client speichert lokal und liefert mit QoS 1 nach, sobald der Broker erreichbar ist. Sparkplug nutzt dafür das STATE-Signal der Host-Anwendung; ohne Sparkplug braucht es eine eigene Store-and-Forward-Logik.
• —Zeitstempel an der Quelle: Der Zeitstempel stammt von Steuerung oder Edge-Gerät, nicht vom Broker – sonst tragen nachgelieferte Nachrichten den Zustellzeitpunkt. Zeitsynchronisation per NTP ist Pflicht.
• —Stillstand bewusst behandeln: Eine stehende Maschine publiziert keine Prozesswerte, aber ihren Zustand. Schweigen darf nie als „läuft unverändert“ gelesen werden; deshalb Zustandssignal plus Heartbeat plus Death-Zertifikat.

Ein Zahlenbeispiel, angenommen: Eine Linie mit zwölf Maschinen liefert je 40 Signale im 100-ms-Takt – 4.800 Werte pro Sekunde, rund 415 Millionen am Tag. Mit Änderungserkennung und Minutenaggregation bleiben davon wenige Prozent übrig, und genau diese tragen die Information. Wie die gefilterten Signale danach auf einem Shopfloor-Bildschirm landen, beschreibt Produktionsdaten visualisieren: vom Maschinensignal zum Dashboard.

Wie OPC UA und der UNS zusammenpassen

Unified Namespace vs. OPC UA ist eine falsche Gegenüberstellung: OPC UA liefert das Informationsmodell an der Maschine, der UNS verteilt den Zustand im Betrieb. Ein OPC-UA-Server auf der Steuerung beschreibt, welche Variablen es gibt, welchen Typ sie haben und wie sie zusammengehören – bei Companion Specifications sogar herstellerübergreifend. Ein Edge-Gateway abonniert diese Knoten, wendet die Filterlogik an und publiziert sie unter dem ISA-95-Topic. Die NodeId wandert dabei als Herkunftsangabe in den Payload, nicht in den Topic-Pfad – Topics sollen anlagenbezogen lesbar bleiben, ns=3;i=1042 ist es nicht.

Eine Alternative zum Gateway ist OPC UA PubSub over MQTT nach OPC 10000-14. Dort publiziert die OPC-UA-Seite selbst an den Broker, mit einer Topic-Struktur der Form <Prefix>/<Encoding>/<MqttMessageType>/<PublisherId>/…, wobei der Präfix laut Spezifikation standardmäßig opcua lautet und die Kodierung json oder uadp ist. Metadaten- und Statusnachrichten werden mit RETAIN=True gesendet, Datennachrichten mit RETAIN=False. Das ist typsicher und standardkonform, folgt aber der Publisher-Struktur, nicht der Anlagenhierarchie. Wer einen ISA-95-Baum will, braucht auch hier eine Abbildungsschicht.

Die Entscheidung zwischen OPC UA Client/Server, OPC UA PubSub und nativem MQTT je Maschine ist eine Protokollentscheidung mit eigenen Kriterien und wird in OPC UA oder MQTT? Entscheidungsleitfaden für die Maschinenanbindung behandelt. Für die UNS-Architektur in der Produktion reicht die Regel: OPC UA dort, wo das Informationsmodell entsteht; MQTT dort, wo viele Konsumenten denselben Zustand brauchen.

Wann ein Unified Namespace Überbau ist

Ein UNS trägt sich erst, wenn mehrere Systeme dieselben Daten brauchen. Drei Situationen sprechen gegen den Aufbau: eine Handvoll Maschinen an einem Standort, ein einziges konsumierendes System – meist ein Dashboard oder eine Zeitreihendatenbank – und niemand im Haus, der einen Broker als Produktionssystem betreiben will. In dieser Lage ist ein Broker eine zusätzliche Komponente, die ausfallen kann, und eine Namenskonvention, die niemand nutzt.

Der Schwellenwert ist keine Maschinenzahl, sondern eine Konsumentenzahl. Fehlt die Betreiberrolle, ist die direkte Anbindung nicht die schlechtere, sondern die ehrlichere Lösung.

Einführung in Stufen: ein realistischer Pfad

Der Unified-Namespace-Aufbau gelingt, wenn er klein beginnt und jede Stufe eine organisatorische Frage beantwortet: Wer betreibt das, und wer darf das Schema ändern? Ein vorgeschlagener Pfad in vier Stufen:

1. 01

   Stufe 1 – eine Linie, ein Broker, ein Dashboard

   Ein Broker on-premise, ein Edge-Gateway an einer Linie mit Änderungserkennung, ein Dashboard als einziger Konsument. Ziel ist das Lernen: Welche Signale gibt es, wie heißen sie, wie oft ändern sie sich. Betreiber: die Person, die das Gateway aufgesetzt hat. Schema: noch Entwurf.

2. 02

   Stufe 2 – Namenskonvention und Rollenmodell festschreiben

   Das Schema wird schriftlich, mit den Regeln aus Tab. 01 und einer Liste erlaubter Kategorien und Signalnamen. ACLs trennen Schreib- und Leserechte je Teilbaum, TLS mit Client-Zertifikaten wird Pflicht. Ab jetzt gibt eine benannte Stelle Änderungen am Schema frei – ohne sie zerfällt der Baum.

3. 03

   Stufe 3 – weitere Linien und der zweite Standort per Bridge

   Weitere Linien folgen demselben Schema; das zweite Werk bekommt einen eigenen Broker, und eine Bridge spiegelt ausgewählte Teilbäume – Kennzahlen und Zustände, keine Rohprozesswerte. Betreiber: eine Rolle mit Vertretung. Das Broker-Monitoring gehört in dieselbe Überwachung wie das MES.

4. 04

   Stufe 4 – schreibende Systeme und Freigaben

   Erst jetzt publizieren Systeme, deren Nachrichten Wirkung haben: Sollwerte, Auftragsstarts, Freigaben. Dafür ein eigener Teilbaum, eigene ACLs und Quittierung durch den Empfänger. Wer hier zu früh beginnt, macht aus dem Datenraum einen Steuerungspfad ohne die Sicherheitsmechanismen einer Steuerung.

Fazit

Ein Unified Namespace ist die Antwort auf ein Skalierungsproblem, nicht auf ein Technologieproblem. Der Wert entsteht nicht durch den Broker, sondern durch eine Topic-Hierarchie, die der Anlage folgt, durch Namensregeln, die zehn Jahre halten, und durch eine klare Zuständigkeit für beides. Sparkplug B, OPC UA PubSub und Broker-Cluster sind Werkzeuge für bestimmte Stellen der Architektur – keine Voraussetzungen. Wer ein zweites konsumierendes System hat, sollte mit einer Linie, einem Broker und einem schriftlichen Schema beginnen und die Stufen in der beschriebenen Reihenfolge nehmen.

Wenn Sie prüfen möchten, wie ein solcher Namensraum mit Ihren vorhandenen Steuerungen, Ihrem MES und einem Shopfloor-Dashboard zusammenspielt, zeigen unsere Lösungen für Maschinendaten und Produktionskennzahlen, welche Bausteine der Weg vom Signal zum gemeinsamen Datenraum braucht.