Unified Namespace (UNS): Datenarchitektur für die Fertigung

Was ist ein Unified Namespace?

Ein Unified Namespace (UNS) ist ein Architekturkonzept für die industrielle Datenintegration. Die Grundidee: Statt dass jedes System (Maschine, SPS, MES, ERP, Analytics) direkt mit jedem anderen System kommuniziert, publizieren alle Systeme ihre Daten in einen gemeinsamen, hierarchisch strukturierten Datenraum. Jedes System kann Daten veröffentlichen und Daten anderer Systeme abonnieren, ohne eine direkte Verbindung zum Quellsystem zu benötigen.

Das Transportprotokoll ist in der Regel MQTT (Message Queuing Telemetry Transport), ein leichtgewichtiges Publish/Subscribe-Protokoll, das für die Kommunikation zwischen Maschinen, Gateways und Cloud-Systemen entwickelt wurde. Der MQTT-Broker ist der zentrale Knotenpunkt: Er empfängt alle Nachrichten und verteilt sie an die Abonnenten.

Die Hierarchie des Datenraums folgt typischerweise der ISA-95-Struktur: Unternehmen, Standort, Bereich, Arbeitsplatz, Maschine. Das ergibt eine Topic-Hierarchie wie:

unternehmen/werk-wilnsdorf/presswerk/presse-01/status
unternehmen/werk-wilnsdorf/presswerk/presse-01/stueckzahl
unternehmen/werk-wilnsdorf/presswerk/presse-01/stillstand
unternehmen/werk-wilnsdorf/presswerk/presse-01/auftrag

Jedes System, das diese Daten braucht (MES, Dashboard, ERP, Analytics), abonniert die relevanten Topics. Kein System muss wissen, woher die Daten kommen. Es muss nur wissen, unter welchem Topic sie zu finden sind. Das ist der "Namespace": Ein einheitlicher Adressraum für alle Produktionsdaten.

Das Problem, das der UNS löst: Punkt-zu-Punkt-Integration

In den meisten Fertigungen sieht die Systemlandschaft heute so aus: Die SPS sendet Daten an das SCADA-System. Das SCADA-System sendet Daten an das MES. Das MES sendet Daten an das ERP. Das ERP sendet Daten an das BI-System. Dazu kommen Sonderschnittstellen: Die Qualitätsdatenbank liest direkt von der SPS. Das Energiemonitoring hat einen eigenen Zähler mit eigener Software. Der Instandhaltungsplaner hat eine Excel-Datei, die manuell befüllt wird.

Das Ergebnis: Ein Netz aus Punkt-zu-Punkt-Verbindungen, bei dem jede neue Verbindung eine eigene Schnittstelle erfordert. Bei n Systemen sind theoretisch n×(n-1)/2 Verbindungen nötig. Bei 10 Systemen sind das 45 potenzielle Schnittstellen. Jede Schnittstelle muss entwickelt, getestet und gewartet werden. Jede Änderung an einem System kann andere Schnittstellen brechen.

Der UNS eliminiert nicht die Notwendigkeit, Daten zu transformieren oder zu kontextualisieren. Aber er reduziert die Komplexität der Verbindungen von quadratisch auf linear. Das ist der eigentliche Gewinn.

Wie ein Cloud-MES in den UNS passt

Ein MES ist im UNS nicht nur Konsument von Maschinendaten. Es ist auch Produzent von Kontextdaten, die die rohen Maschinensignale erst aussagekräftig machen.

Was das MES konsumiert (von der Maschine): Maschinenstatus (läuft/steht), Stückzahlsignale, Alarme, Prozessparameter (Temperatur, Druck, Drehzahl). Diese Daten kommen von der SPS oder vom IoT-Gateway und werden als Topics im UNS publiziert.

Was das MES produziert (für den Namespace): Auftragsdaten (welcher Auftrag läuft gerade auf welcher Maschine), Schichtinformationen (welche Schicht ist aktiv), Stillstandsursachen (der Bediener hat am Terminal die Ursache qualifiziert), OEE-Werte (berechnete Kennzahlen, nicht Rohdaten), Qualitätsentscheidungen (Gut/Schlecht-Bewertungen).

Das ist der Punkt, den der bestehende Artikel unter "Häufige Fehler" korrekt anspricht: "MES nur als Konsument betrachten statt als Datenproduzent für Kontextdaten." Ein Stückzahlsignal von einer Maschine sagt: "Ein Teil wurde produziert." Ohne MES-Kontext ist das eine Zahl. Mit MES-Kontext wird daraus: "Ein Teil von Auftrag 4711 wurde in der Frühschicht auf Presse 01 im Werk Wilnsdorf produziert." Dieser Kontext macht die Daten für Analytics, ERP und Dashboards nutzbar.

Bei Carcoustics sieht das in der Praxis so aus: "OT-Integration über IXON IoT Geräte und dem MQTT-Protokoll in MS Azure." Die Maschinendaten werden über MQTT an Azure publiziert, dort vom MES verarbeitet und mit Kontextdaten angereichert (Auftrag, Schicht, Stillstandsursache). Die angereicherten Daten stehen dann für "konzernweite Analyse zu Performance Kennzahlen" zur Verfügung. Das ist im Kern ein UNS-Ansatz, auch wenn Carcoustics es nicht so nennt:
Ein zentraler, MQTT-basierter Datenraum in Azure, in den Maschinen publizieren und aus dem MES, ERP und Analytics lesen.

Die Topic-Hierarchie: Wie der Namespace strukturiert wird

Die Struktur des Namespace bestimmt, ob das Konzept funktioniert oder im Chaos endet. Die bewährte Struktur folgt ISA-95:

Die Hierarchie wird einmal definiert und dann konsequent eingehalten. Jede neue Maschine, jeder neue Standort, jedes neue System folgt derselben Struktur. Wenn Meleghy Automotive ein neues Werk in Miskolc (Ungarn) aufschaltet, wird meleghy/miskolc/ als neuer Teilbaum angelegt. Die Struktur ist identisch zu meleghy/wilnsdorf/. Die Dashboards, Analysen und ERP-Schnittstellen funktionieren sofort, weil sie dieselbe Topic-Struktur erwarten.

Das ist der Skalierungsvorteil des UNS. Bei Meleghy wurde die Skalierung auf 6 Werke "innerhalb von nur 6 Monaten" umgesetzt. Bei einer Punkt-zu-Punkt-Architektur hätte jedes Werk eigene Schnittstellen zu MES, ERP und Analytics gebraucht. Mit einem UNS-Ansatz (oder einer funktional äquivalenten Cloud-Architektur) publiziert jedes Werk in denselben Namespace. Die konzernweite Analyse greift auf einen Datenraum zu, nicht auf sechs separate Systeme.

Häufige Fragen zum Unified Namespace

Ist ein UNS ein Produkt, das man kaufen kann?

Nein. Ein UNS ist ein Architekturkonzept, kein Softwareprodukt. Man kauft die Komponenten: einen MQTT-Broker (z. B. HiveMQ, EMQX, Mosquitto oder den in Azure integrierten), IoT-Gateways für die Maschinenanbindung, und Systeme die in den Namespace publizieren und daraus lesen (MES, ERP-Adapter, Dashboards). Das Konzept selbst ist die Entscheidung, diese Komponenten über einen zentralen Datenraum statt über Punkt-zu-Punkt-Verbindungen zu verbinden. Manche MES-Anbieter bringen den Broker bereits mit. Bei Cloud-MES-Systemen ist der Broker oft Teil der Cloud-Infrastruktur.

Was ist der Unterschied zwischen UNS und einem Data Lake?

Zwei Unterschiede: (1) Echtzeit vs. Batch. Ein Data Lake speichert historische Daten für Analysen. Der UNS enthält den aktuellen Zustand aller Systeme in Echtzeit. (2) Struktur. Ein Data Lake ist oft unstrukturiert ("werft alles rein, sortiert wird später"). Der UNS ist streng hierarchisch strukturiert (ISA-95-Hierarchie). In der Praxis ergänzen sich beide: Der UNS liefert Echtzeitdaten für operative Entscheidungen. Der Data Lake speichert die historischen Daten für Trendanalysen und Machine Learning.

Braucht man OPC UA oder MQTT für einen UNS?

MQTT ist das Standardprotokoll für den UNS, weil es nativ Publish/Subscribe unterstützt und extrem leichtgewichtig ist. OPC UA wird an der Maschine verwendet, um strukturierte Daten aus der SPS zu lesen. Die typische Architektur: Die SPS stellt Daten über OPC UA bereit. Ein IoT-Gateway liest diese Daten und publiziert sie über MQTT in den UNS. OPC UA ist also die "Sprache der Maschine", MQTT die "Sprache des Namespace". Beide ergänzen sich. In der Praxis gibt es auch OPC UA Pub/Sub, das direkt in einen Namespace publizieren kann, aber MQTT ist aktuell verbreiteter.

Wie verhält sich ein UNS zu ISA-95?

ISA-95 definiert die hierarchische Struktur der Fertigung (Enterprise, Site, Area, Work Center, Work Unit) und die Datenflüsse zwischen den Ebenen. Der UNS ist im Grunde eine Echtzeit-Implementierung dieser Hierarchie. Die ISA-95-Ebenen werden zur Topic-Hierarchie: enterprise/site/area/work-center/work-unit/datenpunkt. Wer seine Fertigung bereits nach ISA-95 strukturiert hat, hat die Topic-Hierarchie im Prinzip schon definiert.

Nutzt SYMESTIC einen Unified Namespace?

SYMESTIC nutzt eine funktional äquivalente Architektur: IoT-Gateways erfassen Maschinendaten über digitale I/O-Signale oder OPC UA und senden sie über sichere Verbindungen (LTE, WLAN, Ethernet) an die Cloud-Plattform auf Microsoft Azure. Dort werden die Daten in einer Microservice-Architektur verarbeitet, mit Kontextdaten (Aufträge, Schichten, Stillstandsursachen) angereichert und über Dashboards, APIs und ERP-Schnittstellen bereitgestellt. Bei Carcoustics geschieht dies explizit über MQTT: "OT-Integration über IXON IoT Geräte und dem MQTT-Protokoll in MS Azure." Ob man das "Unified Namespace" nennt oder "Cloud-native MES-Architektur", ist eine Frage der Terminologie. Die Wirkung ist dieselbe: Ein zentraler Datenraum, in den Maschinen publizieren und aus dem alle Systeme lesen.

Über den Autor:

Mark Kobbert

CTO der symestic GmbH. Verantwortet die Cloud-MES-Architektur seit 2014. B.Sc. Wirtschaftsinformatik.
LinkedIn