Inhalt
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/statusunternehmen/werk-wilnsdorf/presswerk/presse-01/stueckzahlunternehmen/werk-wilnsdorf/presswerk/presse-01/stillstandunternehmen/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.
| Kriterium | Punkt-zu-Punkt | Unified Namespace |
|---|---|---|
| Verbindungsanzahl | Quadratisch wachsend: n×(n-1)/2. Jedes System braucht eine direkte Verbindung zu jedem anderen. | Linear wachsend: n. Jedes System braucht nur eine Verbindung zum Broker. |
| Neues System anbinden | Jede bestehende Verbindung muss geprüft werden. Neue Schnittstellen zu allen relevanten Systemen. | Das neue System publiziert in den Namespace und/oder abonniert Topics. Keine Änderung an bestehenden Systemen. |
| Datenmodell | Jede Schnittstelle hat ihr eigenes Format. Dieselbe Information (z. B. "Maschine steht") existiert in 5 verschiedenen Formaten in 5 Systemen. | Ein einheitliches Datenmodell. "Maschine steht" wird einmal publiziert und von allen Systemen im selben Format gelesen. |
| Echtzeit | Abhängig von der Schnittstelle. Viele Verbindungen arbeiten batch-basiert (Datei alle 5 Minuten, API-Abfrage alle 30 Sekunden). | Event-basiert. Daten werden publiziert, sobald sie entstehen. Abonnenten erhalten sie in Millisekunden. |
| Wartungsaufwand | Hoch. Jede Schnittstelle ist ein einzelner Fehlerpunkt. Wenn ein System sich ändert, brechen abhängige Verbindungen. | Gering. Der Broker ist der einzige Infrastruktur-Punkt. Systeme sind entkoppelt. |
| Single Source of Truth | Nein. Dieselbe Information existiert in mehreren Systemen mit unterschiedlichen Zeitstempeln und Formaten. | Ja. Der Namespace ist der eine Ort, an dem der aktuelle Zustand aller Systeme abgebildet ist. |
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.
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:
| Ebene | Beispiel-Topic | Was publiziert wird |
|---|---|---|
| Unternehmen | meleghy/ |
Unternehmensweite Stammdaten, globale KPIs. |
| Standort | meleghy/wilnsdorf/ |
Standort-KPIs, Schichtkalender, Energiedaten. |
| Bereich | meleghy/wilnsdorf/presswerk/ |
Bereichs-OEE, laufende Aufträge, Personalzuordnung. |
| Maschine | meleghy/wilnsdorf/presswerk/presse-01/ |
Status, Stückzahl, Zykluszeit, Alarme, aktiver Auftrag. |
| Datenpunkt | meleghy/wilnsdorf/presswerk/presse-01/oee |
Einzelner Wert: aktueller OEE-Wert dieser Maschine. |
Die Hierarchie wird einmal definiert und dann konsequent eingehalten. Jede neue Maschine, jeder neue Standort, jedes neue System folgt derselben Struktur. 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 4 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 publiziert jedes Werk in denselben Namespace. Die konzernweite Analyse greift auf einen Datenraum zu, nicht auf vier 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.
Sehen Sie SYMESTIC an Ihrem eigenen Anwendungsfall
In der kostenlosen Live-Demo zeigt Ihnen ein Produktexperte an der laufenden Plattform, wie OEE, Stillstände und die Anbindung Ihrer Maschinen und Ihres ERP konkret aussehen.
- OEE live
- Stillstände und Gründe
- Maschinen und ERP anbinden
Alte Maschine, neue Daten, in unter drei Stunden
Die IoT Box von SYMESTIC liest die digitalen Signale ab, ohne Eingriff in die Steuerung.