Was ist Unified Namespace? Praxis-Leitfaden für die Fertigung

Digitale Transformation und der Bedarf an besserer Datenintegration

Im Zeitalter von Industrie 4.0 stehen viele Unternehmen noch immer vor einer einfachen Frage: Was ist Unified Namespace, und wie verbindet er IT-Systeme (ERP, BI, Cloud-Analytik) mit der OT-Welt (Maschinen, SPS, SCADA, Sensoren)?

In vielen Werken liegen die Daten in getrennten Tools und Tabellen. Ein Team sieht „Maschine steht“, ein anderes „Produktion läuft“, und jemand verbringt Stunden damit, Berichte abzugleichen. Diese Spaghetti-Architektur aus Punkt-zu-Punkt-Integrationen, Datensilos und inkompatiblen Protokollen bremst den Datenfluss, verringert die Transparenz und treibt die Wartungskosten nach oben. Genau deshalb sind Datenmanagement und Data Governance heute wichtiger denn je.

Ein Unified Namespace (UNS) ändert die Spielregeln: Er schafft ein gemeinsames Echtzeit-Datenmodell, das zur Single Source of Truth für das gesamte Unternehmen wird. Statt eine weitere Integration zu bauen, veröffentlichen und abonnieren die Systeme dieselben strukturierten Daten. Informationen lassen sich so leichter finden, wiederverwenden und skalieren.

Lesen Sie weiter, wenn Sie sehen möchten, wie ein UNS verstreute Signale in eine konsistente, geschäftsrelevante Sicht auf die Produktion verwandelt.

Dieser Leitfaden richtet sich an Werkleiter, OT/IT-Architekten und Datenteams, die eine skalierbare IT/OT-Integration aufbauen.

UNS in 60 Sekunden: das Wichtigste auf einen Blick

Was ist Unified Namespace in einem Satz: Ein UNS ist ein gemeinsames Echtzeit-Datenmodell (meist auf einem MQTT-Broker), in dem OT und IT strukturierte Daten nach dem Publish/Subscribe-Prinzip austauschen – als Single Source of Truth.
Das Problem: Die Spaghetti-Architektur (Punkt-zu-Punkt-Integration) erzeugt technische Schulden und verhindert die schnelle Skalierung digitaler Initiativen, KI-Einführung eingeschlossen.
Die Lösung: Ein Unified Namespace ist ein Architekturansatz. Er wirkt als zentraler Daten-Broker, an den alle smarten Assets publizieren und von dem alle Anwendungen abonnieren. Die UNS-Architektur vereinfacht die Integration strukturell und ermöglicht Datenzugriff in Echtzeit.
Schlüsseltechnologie: MQTT ist das Standard-Transportprotokoll; Sparkplug B oder standardisiertes JSON definiert die Struktur.
Strategie: Kein „Rip and Replace“. Der UNS entsteht neben den bestehenden Systemen (Brownfield-first).
Governance: Namenskonventionen, Sicherheit (ACLs) und belastbare Praktiken für Datenmanagement und Data Governance sind wichtiger als die Software, die Sie kaufen.
Ergebnis: Echtzeit-Transparenz, Entkopplung von Hardware und Software sowie schnelle Anbindung neuer Technologien (KI, Analytik).

Was ist ein Unified Namespace?

Unified Namespace (UNS) ist ein Architekturkonzept, keine bestimmte Software. Es ist eine konsolidierte Abstraktion Ihrer Unternehmensstruktur, Ihrer Ereignisse und Prozessdaten in der Fertigung, die in Echtzeit zugänglich ist.

In einem klassischen ISA-95-Stack fließen Daten linear: Sensor → SPS → SCADA → MES → ERP. Das erzeugt Latenz und Silos.

In einer UNS-Architektur ist die Struktur Hub-and-Spoke. Der UNS ist der Hub (in der Regel ein MQTT-Broker). Jeder Knoten – Edge-Gateway, MES, ERP, Cloud-Analytik – ist ein gleichberechtigter Peer. Alle produzieren Daten in den Namespace und konsumieren Daten daraus.

Vereinfacht gesagt: Der Unified Namespace ist das zentrale Nervensystem der Fabrik – ein einziger Punkt mit lebendigen, kontextualisierten Daten, der jede Maschine, jedes System und jede Entscheidung verbindet. Durch Zentralisierung und Standardisierung der Daten verbessert der UNS die Entscheidungsfindung, weil Informationen für alle Nutzer und Systeme zugänglich und konsistent sind. Zugleich verbessert er die Kommunikation zwischen Operational Technology (OT) und Informationstechnologie (IT) und steigert so die operative Effizienz im gesamten Unternehmen.

Ein typisches Beispiel für den Datenfluss in einem UNS zeigt die folgende Tabelle: Jedes System publiziert seine Daten einmal und abonniert nur das, was es braucht.

System	Publiziert an den MQTT-Broker	Abonniert vom MQTT-Broker
Anlage 1 und Anlage 2	Maschinen- und Prozessdaten, z. B. Stillstandsereignisse	Produktionsaufträge
Historian	Aggregate und KPIs	Datenänderungen aus dem Shopfloor
MES	Kategorisierung von Stillständen	Produktionsaufträge und Stillstandsereignisse
ERP	Produktionsaufträge	Status der Auftragsausführung

Was ist der Unterschied zwischen Unified Namespace und dem Purdue-Modell?

Das Purdue-Modell ist die „Pyramide“ der Fabrik. Lange war es das Standardmuster für den industriellen Datenfluss: Daten wandern Stufe für Stufe nach oben (Maschine → SCADA → MES → ERP). Deshalb sind sie oft nicht in Echtzeit verfügbar, und Teile der Daten werden unterwegs verzögert oder umgeformt.

Unified Namespace funktioniert anders. Er steht für ein modernes Muster der Datenintegration und ist ein Beispiel für eine ereignisgesteuerte Architektur (Event-Driven Architecture, EDA). Die Kernidee: Der Unified Namespace ist ein gemeinsamer Ort (meist ein Broker), an dem Systeme Echtzeitdaten einmal publizieren und andere Systeme sie abonnieren. So entsteht ein konsistenter Datenstrom aus dem Shopfloor, der in Echtzeit zur Verfügung steht. Das unterstützt die digitale Transformation, weil „Spaghetti“-Integrationen entfallen und Daten samt Kontext über alle Anwendungen hinweg konsistent bleiben.

Merkmal	Purdue-Modell	Unified Namespace
Struktur	Pyramide mit Ebenen: Sensoren, SPS, SCADA, MES, ERP	Hub-and-Spoke: zentraler UNS-Knoten mit gleichberechtigten Peers (ERP, MES, SCADA, Sensoren, SPS)
Datenfluss	Linear, Ebene für Ebene nach oben	Publish/Subscribe über einen Broker
Aktualität	Häufig verzögert, Daten werden unterwegs umgeformt	Echtzeit, einmal publiziert, von vielen konsumiert
Integration	Punkt-zu-Punkt zwischen benachbarten Ebenen	Ein Publikationspfad, beliebig viele Abonnenten

Warum ein UNS zu Unternehmen mit mehreren Standorten passt

Single Source of Truth: Der aktuelle Zustand des Unternehmens ist jederzeit unter einer bekannten Topic-Adresse verfügbar – als einheitliche, konsistente Sicht über die gesamte Organisation.
Entkopplung: Sie können ein SCADA-System austauschen, ohne die ERP-Integration zu brechen, solange das neue SCADA an dieselben Topics publiziert.
Edge to Cloud: Der UNS schließt die Lücke zwischen hochfrequenten OT-Daten und latenztoleranten IT- und Cloud-Systemen, indem er Daten so organisiert und strukturiert, dass sie die Struktur und Ereignisse Ihres Unternehmens abbilden.

Wie sich ein UNS von gängigen Alternativen unterscheidet

Punkt-zu-Punkt-Integrationen: enge Kopplung. Jeder neue Konsument braucht eine neue Verbindung und ein neues Mapping. Fragil und langsam zu skalieren.
Historians: hervorragend für die Speicherung und Analyse von Zeitreihen, aber in der Regel kein lebendiges Integrations-Backbone. Sie speichern Daten, lösen Standardisierung und Entkopplung aber nicht von selbst. Ein Data Historian lässt sich jedoch in den UNS integrieren, um den Zugriff zu zentralisieren und einheitliche Datenflüsse zu ermöglichen.
Data Lakes / Data Warehouses: gut für Langzeitanalysen und Unternehmensreporting, aber oft zu langsam und zu batch-lastig für den Echtzeitbetrieb und ereignisgesteuerte Anwendungsfälle. Werden sie in den UNS eingebunden, entsteht ein einheitlicher Zugriff auf historische und Echtzeitdaten in einer Plattform.

Ein UNS eignet sich für die Fertigung an mehreren Standorten, weil er einen konsistenten, wiederverwendbaren Vertrag von der Edge bis in die Cloud liefert und so einen digitalen roten Faden über alle Werke hinweg ermöglicht. Ein konkretes Beispiel dafür, wie Produktionsdaten standardisiert und von mehreren Konsumenten wiederverwendet werden, finden Sie in diesem Beitrag: Unified Namespace example in FMCG (auf Englisch).

Ergebnisse und Nutzen eines UNS

Ein gut entworfener Unified Namespace liefert schnell geschäftlichen Nutzen – vor allem dann, wenn Sie neue Dashboards, Analysewerkzeuge oder MES-Anwendungen anbinden können, ohne jedes Mal die Integration von der SPS zur Anwendung neu zu bauen.

Kernnutzen (am häufigsten)

Single Source of Truth: Alle lesen dieselbe operative Bedeutung – nicht nur Rohtags –, sodass Teams aufhören, darüber zu streiten, welche Zahl „richtig“ ist.
Entkopplung: Produzenten publizieren einmal, Konsumenten abonnieren nach Bedarf. Sie können ein System ändern oder ersetzen, ohne die anderen zu brechen.
Weniger Integrationen: Statt vieler fragiler Punkt-zu-Punkt-Verbindungen gibt es einen Publikationspfad und viele Abonnenten.
Schnelleres Onboarding: Neue Konsumenten (Dashboards, MES, BI, Analytik, KI) werden per Abonnement angebunden, nicht per individueller Verdrahtung.

Operative Gewinne (wo sie zuerst sichtbar werden)

Schnelleres OEE- und Stillstands-Reporting: Standardisierte Ereignisse und Zustände verbessern die Klassifizierung und reduzieren den manuellen Abgleich.
Kürzere Verbesserungsschleifen beim Rüsten: Konsistente Echtzeitsignale machen es leichter, Muster zu erkennen und Engpässe zu beseitigen.
Bessere Diagnose und geringere MTTR: Instandhaltungsteams erhalten klareren Kontext (was ist wann und wo passiert) und beheben Störungen schneller.
Besseres Datenmanagement und bessere Analytik: Der UNS organisiert und vereinheitlicht Echtzeitdaten aus mehreren Systemen und ermöglicht schnellere Analysen und bessere Entscheidungen. Mehr dazu: Datensilos aufbrechen: wie ein Unified Namespace die Produktionsdaten zusammenführt.

Brownfield-Realität: Sie müssen zum Start keine SPS-Programme „herausreißen und ersetzen“. Sie standardisieren, was an der Edge möglich ist, publizieren sicher und verbessern die Semantik über die Zeit.

Checkliste der Voraussetzungen

Klären Sie vor dem Start, was Unified Namespace für Ihr Werk konkret bedeutet: Umfang, Verantwortliche und Konsumenten.

Must-have:

Asset-Inventar (SPS, Gateways, SCADA/MES/Historian)
Entwurf einer Namenskonvention (ISA-95-Hierarchie)

Nice-to-have (erleichtert die Skalierung):

Netzwerksegmentierung und OT-DMZ für den Broker-Zugriff
Zeitsynchronisation (mindestens NTP)
Plan für den PKI-Lebenszyklus (Zertifikatsrotation)
Change-Management (RACI, Wartungsfenster, Rollback)
Aufbewahrungsrichtlinie (Broker vs. Historian vs. Data Lake)

Referenzarchitektur: wie die Daten fließen

Die physische Umsetzung folgt in der Regel einem gestuften Ansatz, um Sicherheit und Zuverlässigkeit zu gewährleisten.

Der Datenfluss

Ebene 0–1 (Edge): SPSen und Sensoren sind die Datenproduzenten. Ihre Datenpunkte werden von einem Edge-Gateway (z. B. Kepware, Ignition Edge) eingesammelt. Das Gateway übersetzt native Protokolle (EtherNet/IP, Modbus, PROFINET) nach MQTT. Hier findet die erste Vereinheitlichung und Standardisierung der Datenpunkte aus unterschiedlichen Quellen statt. Wie diese Anbindung im Brownfield gelingt, beschreibt unser Beitrag Industrielle Konnektivität: der praktische Leitfaden für Fertigungsunternehmen.
Ebene 2–3 (Standort): Die Edge-Gateways publizieren diese vereinheitlichten Datenpunkte an einen lokalen MQTT-Broker (Standort-UNS).
Ebene 4–5 (Unternehmen/Cloud): Der lokale Broker leitet ausgewählte Topics per Bridge an einen Unternehmens-MQTT-Broker (globaler UNS) oder in die Cloud weiter. So werden Datenquellen mehrerer Standorte in einem einzigen Unified Namespace zusammengeführt – für unternehmensweiten Zugriff und Analyse.

Hochverfügbarkeit und DMZ-Muster

HA für ein einzelnes Werk: Broker-Cluster (aktiv/aktiv) oder Primär/Sekundär mit Failover.
OT-DMZ: Broker oder Broker-Endpunkte in der DMZ platzieren; SPS-Netzwerke isoliert halten.
Mehrere Standorte:

Lokaler Broker pro Werk für Resilienz (bevorzugt)
Optionale MQTT-Bridge zu einem regionalen oder zentralen Broker für Unternehmenskonsumenten
Replikation über mehrere Regionen für Cloud- und Unternehmensskalierung

Faustregel für mehrere Standorte: Halten Sie das Publizieren lokal in jedem Werk – für Verfügbarkeit und Zuverlässigkeit. Replizieren Sie nach oben; zwingen Sie nicht jedes Edge-Gerät, die Cloud zu erreichen.

Wie man einen Unified Namespace (UNS) implementiert: Topic- und Datendesign

Topics entwerfen: die Regeln, die Chaos verhindern

Das ist der kritischste Schritt. Ist Ihre Topic-Struktur unordentlich, wird aus dem Data Lake ein Datensumpf.

Modellieren mit ISA-95/ISA-88 und Domain-Driven Design

Definieren Sie Ihre Kernhierarchie nach ISA-95 (Enterprise/Site/Area/Line/Cell) und nutzen Sie ISA-88-Konzepte, wo Batch- oder Prozessfertigung vorliegt (Unit/Procedure/Phase).

Die Basishierarchie lässt sich um domänengetriebene Elemente erweitern: Topics repräsentieren geschäftsrelevante Objekte und Systeme (Anlagen, Aufträge, Qualitätsereignisse, MES, ERP) – nicht beliebige SPS-Speicheradressen.

Basis-Topic-Muster

Die Standardhierarchie für einen Unified Namespace lautet: Enterprise / Site / Area / Line / Cell / Asset. Ein Beispiel für einen solchen Topic-Baum: Acme Corp → PL01 → Welding → Line03 → Robot01. Unter Robot01 liegt ein Edge-Knoten mit Datentags (State, Mode, Cycle Active, Cycle Time) und Verknüpfungen zu den Systemen MES, ERP und CMMS.

Ebene	Beispiel	Beschreibung
Enterprise	acme	Die globale Organisation
Site	DE-MUC	Ein konkreter physischer Standort
Area	packaging	Ein Produktionsbereich
Line	L03	Eine sequenzielle Produktionslinie
Cell	cell-02	Eine logische Gruppe von Anlagen
Asset	packer	Das physische Gerät

Gute und schlechte MQTT-Topic-Beispiele

Gut (aussagekräftig, konsistent):

prod/acme/DE-MUC/packaging/L3/cell-02/packer-01/speed
prod/acme/DE-MUC/packaging/L3/cell-02/packer-01/jam_detected
prod/acme/DE-MUC/packaging/L3/cell-02/packer-01/mode

Schlecht (undurchsichtig, instabil oder zu SPS-zentriert):

PLCMUC/DB12.DBW4
werk1/linie3/tag123
prod/packer01/speed/fast

Sparkplug B vs. natives MQTT + JSON

Sparkplug B: eine offene Spezifikation, die Topic-Struktur und Payload definiert. Vorteile: Plug-and-play-Interoperabilität; „Birth“- (ich bin online) und „Death“-Zertifikate (ich bin offline) werden automatisch definiert. Nachteile: kann starr sein; für den vollen Nutzen sind Sparkplug-fähige Broker und Clients nötig.
Natives MQTT + JSON: eigene Struktur. Vorteile: maximale Flexibilität; menschenlesbar. Nachteile: Governance und Zustandsverwaltung (Birth/LWT) müssen Sie selbst aufbauen.

Variante	Topic-Format	Beispiel-Topic	Payload-Beispiel
Natives MQTT + JSON	company/site/area/line/machine/tag	Acme/PL01/Welding/Line03/Robot01/Speed	JSON mit value: 42.7, unit: mm/s und einem Zeitstempel
Sparkplug B	spBv1.0/group_id/message_type/edge_node_id/[device_id]	spBv1.0/Acme/DDATA/PL01-Welding-Line03/Robot01	Payload mit seq, timestamp und einem metrics-Array, das die Metrik „Speed“ mit dem Wert 42.7 enthält

Empfehlung: Nutzen Sie Sparkplug B, wenn Ihr Ökosystem (MES/SCADA/Gateways) es nativ unterstützt. Nutzen Sie natives MQTT mit streng verwalteten JSON-Schemas für individuelle App-Integrationen oder bei Legacy-Einschränkungen.

Style Guide für den Unified Namespace (UNS)

Schreiben Sie einen einseitigen Style Guide und setzen Sie ihn durch.

Namensregeln

Topics in Kleinbuchstaben (vermeidet Probleme mit Groß-/Kleinschreibung).
Trennzeichen: / für MQTT-Topics; – innerhalb von IDs; keine Leerzeichen.
Stabile IDs: Standort und Asset sollten, wo möglich, den technischen Plätzen im CMMS entsprechen.
Kein Freitext in Topic-Namen; Details gehören in Payload-Felder.

Versionierungsregeln

Die Topic-Struktur sollte stabil bleiben.
Änderungen am Payload-Schema folgen semantischer Versionierung (MAJOR.MINOR.PATCH).
Breaking Changes erfordern eine neue Version und ein Kompatibilitätsfenster.

Einheiten und Zeitstempel

Immer uom (Maßeinheit) mitgeben.
Zeitstempel in UTC nach ISO 8601.
Ein Qualitätsflag ergänzen.

Mapping-Tabelle: von SPS-Tags zu standardisierten Topics und Payloads

Quelle (SPS/SCADA)	Roh-Tag	Standard-Topic	Payload-Signal	uom
SPS Packer01	DB20.Speed	prod/acme/DE-MUC/packaging/L3/cell-02/packer-01/speed	speed	bpm
SPS Packer01	JamBit	…/jam_detected	jam_detected	bool
SCADA	ModeText	…/mode	mode	enum

Daten-Payloads und Governance

Das Topic sagt Ihnen, wo die Daten sind. Der Payload sagt Ihnen, was sie sind.

Bei der Implementierung eines Unified Namespace sind Data Governance und Datenmanagement unverzichtbar, um die Qualität der Payloads und die Einhaltung der Datenschemas sicherzustellen. Starke Governance- und Managementpraktiken sichern Integrität, Zuverlässigkeit und Sicherheit der Informationen in industriellen Echtzeitumgebungen.

Anforderungen an Payloads

Jeder Payload muss enthalten:

Value: der eigentliche Datenpunkt (z. B. 45.2).
Timestamp (ts): ISO 8601 oder Unix Epoch. Der Zeitpunkt, an dem das Ereignis stattgefunden hat – nicht der Empfangszeitpunkt.
Quality (q): good, bad, uncertain.
Unit of Measure (uom): standardisieren (z. B. immer Celsius, nie Fahrenheit).
Semantische Versionierung: Feld v im Payload.
Idempotenz: Ereignis-IDs mitgeben, um Duplikate zu vermeiden.

MQTT-Verhaltensregeln (Zuverlässigkeit)

QoS (Quality of Service): QoS 0 (höchstens einmal): Fire-and-forget, gut für hochfrequente Daten. QoS 1 (mindestens einmal): garantierte Zustellung, Standard für die meisten Prozessdaten. QoS 2 (genau einmal): hoher Overhead, nur wenn unbedingt nötig.
Retained Messages: für Zustands-Topics aktivieren (z. B. Line/State). Verbindet sich ein neues Dashboard, erhält es sofort den letzten bekannten Zustand, ohne auf eine Änderung zu warten. Üblich für Zustände (letzter bekannter Wert), nicht für hochfrequente Telemetrie.
LWT (Last Will and Testament): bei Verbindungsabbruch den Offline-Zustand publizieren.

Empfehlungen zur Quality of Service:

Telemetrie: QoS 0 oder 1 (je nach Verlusttoleranz)
Ereignisse: QoS 1 (mindestens einmal) plus Duplikatbehandlung
Befehle: QoS 1 oder 2 (mit Vorsicht; gründlich testen)

Schema first, immer: Wer ohne Schema publiziert, baut künftige Integrationsschulden auf. Ein „funktionierender“ UNS mit undokumentierten Payloads ist nur Chaos mit MQTT.

Security first: keinen offenen Broker ausliefern

Sicherheit ist nicht optional. Betreiben Sie keinen offenen Port 1883. In der DACH-Region kommt hinzu, dass NIS2 und die Anforderungen an KRITIS-Betreiber Zugriffskontrolle, Protokollierung und Segmentierung im OT-Umfeld zur Pflicht machen – ein UNS ist dafür ein guter Anlass, diese Grundlagen sauber zu setzen. Was das konkret bedeutet, lesen Sie in unserem Beitrag NIS2 und die Realität in OT-Umgebungen.

Zero-Trust-Grundlagen

TLS überall
Gegenseitige Authentifizierung (Client-Zertifikate bevorzugt)
Least Privilege mit MQTT-ACL-Mustern
Audit-Logging und Nachvollziehbarkeit
Getrennte Dev-/Test-/Prod-Broker (oder mindestens getrennte Listener plus strikte ACLs)

ACL-Muster

ACLs (Access Control Lists) legen fest, wer auf welche Daten zugreifen darf.

Publisher dürfen nur unter ihrem eigenen Asset-Pfad schreiben
Konsumenten dürfen nur lesen, was sie brauchen
Keine Wildcard-Publish-Rechte

Offline-Pufferung und Store-and-Forward

Edge-Gateways sollten puffern, wenn der Broker nicht erreichbar ist
Persistente Sessions nutzen, wo sinnvoll
Warteschlangentiefe und Reconnect-Stürme überwachen

Bridging zwischen Brokern

Nutzen Sie eine MQTT-Bridge für die Replikation über mehrere Standorte:

Der Werks-Broker ist die Single Source of Truth für den Werksbetrieb
Der zentrale Broker aggregiert für die Unternehmensnutzung
Filtern und drosseln Sie, was repliziert wird (nicht alles replizieren)

Wenn Sie MQTT in industriellen Umgebungen sicherheitskonform betreiben wollen, nutzen Sie eine maßgebliche Referenz: OASIS hat „MQTT and the NIST Cybersecurity Framework“ veröffentlicht – eine Leitlinie, die MQTT-Betriebspraktiken auf das NIST Cybersecurity Framework abbildet. Sie ist eine solide externe Basis für Entscheidungen zu TLS, Authentifizierung, Zugriffskontrolle (ACLs), Protokollierung und operativer Sicherheits-Governance, ohne Sie an einen Anbieter zu binden.

Schritt-für-Schritt-Implementierungsplan

Phase	Ziel	Schritte	Abnahmekriterien	Verantwortliche (typisch)
Phase 0: Discovery (1–3 Wochen pro Standort)	Assets, Protokolle und Konsumenten verstehen.	1) Assets, SPS-Typen und Protokolle inventarisieren (OPC UA, Modbus, proprietäre Treiber). 2) Konsumenten identifizieren: Historian, MES, QMS, CMMS, Analytik, Cloud. 3) 3–5 hochwertige Signale/Ereignisse pro Asset-Klasse auswählen. 4) Ersten Namespace-Entwurf und Payload-Vorlage definieren.	– Asset-Hierarchie abgestimmt (IDs für Site/Area/Line/Cell/Asset) – Erstes Topic-Muster dokumentiert – Sicherheitsansatz gewählt (Zertifikate, ACL-Ansatz)	OT-Lead, IT-Netzwerk/Security, Daten-/Analytik-Lead
Phase 1: Pilot eines Wertstroms (4–8 Wochen)	Nutzen und Muster an einer Linie oder Zelle nachweisen.	1) Edge-Konnektor ausrollen 2) Broker bereitstellen (falls nötig zunächst nicht produktiv) 3) Telemetrie und Ereignisse publizieren 4) Einen Konsumenten anbinden (z. B. Stillstands-Dashboard plus Historian-Integration) 5) Testfälle für Qualitäts- und Zuverlässigkeitsprüfungen dokumentieren und ausführen (z. B. Failover-Szenarien)	– Datenqualität geprüft (Zeitstempel, Einheiten, Qualitätsflags) – Konsument ohne Punkt-zu-Punkt-Verbindung zur SPS gebaut – Basis-Monitoring vorhanden
Phase 2: Härten und standardisieren (4–6 Wochen)	Wiederholbar machen.	1) Namenskonventionen und Topic-Struktur festschreiben 2) Schemavalidierung und Versionierungsrichtlinie ergänzen 3) MQTT-ACL-Vorlagen und Zertifikatslebenszyklus definieren 4) Onboarding-Runbook für neue Assets und Konsumenten erstellen	– Style Guide veröffentlicht und in CI/Review durchgesetzt – Keine neuen Topics ohne Verantwortlichen und Schema – Trennung Dev/Test/Prod definiert
Phase 3: Skalierung auf das Werk, dann auf mehrere Standorte (8–20 Wochen)	Abdeckung und Resilienz ausbauen.	1) HA-Broker-Topologie (Cluster oder Primär/Sekundär) 2) Werks-DMZ-Muster umsetzen 3) Standard-Images und -Konfigurationen für Gateways 4) MQTT-Bridge zum zentralen Broker (optional) 5) Observability: Broker-Metriken, Gateway-Zustand, Latenz, Verlustquoten	– Verfügbarkeitsziel des Brokers erreicht – Onboarding-Zeit pro Asset sinkt mit jedem Sprint – Topic-Konsistenz über Standorte hinweg erreicht
Phase 4: Steuern und weiterentwickeln (laufend)	Sauber halten.	1) Change Board, Deprecation-Fenster, Release Notes 2) Quartalsweise Bereinigung: ungenutzte Topics entfernen, Versionen abkündigen 3) Sicherheitsaudits und Übungen zur Zertifikatsrotation	– Breaking Changes folgen der Richtlinie – Fenster für Abwärtskompatibilität werden eingehalten – Audits bestehen ohne „alle sind Admin“

Tooling-Optionen

Wählen Sie Werkzeuge, die zu Ihren Rahmenbedingungen passen (Brownfield, Verfügbarkeit, Kompetenzen). Einige Entscheidungskriterien finden Sie in der Tabelle.

Kategorie	Optionen	Auswahlkriterien
MQTT-Broker	EMQX, HiveMQ, Mosquitto, VerneMQ	Skalierbarkeit (Anzahl Verbindungen), Clustering/HA, Bridging/Replikation, Sicherheitsoptionen, Observability, Enterprise-Support.
Edge-Gateways	Ignition Edge, Kepware, HighByte, in manchen Fällen auch OPC UA	Protokolltreiber (Siemens, Allen-Bradley, weitere – aber auch IT-Protokolle wie MQTT), Store-and-Forward, Verwaltbarkeit im großen Maßstab (mehrere Werke). Einen Überblick über die Treiberlandschaft gibt unser Leitfaden zu Kepware-Treibern.
Data Ops/Kontext	HighByte Intelligence Hub, Node-RED	Fähigkeit, Daten vor dem Publizieren in den UNS zu modellieren und zu transformieren.
Observability	Grafana, Prometheus, MQTT Explorer	Einfache Visualisierung und Alarmierung, Audit-Trails.
Datensenken	Historians (etwa Canary Historian), Data Lakes / Warehouses, Stream-Prozessoren	Anbindbarkeit (z. B. MQTT-Unterstützung), Skalierbarkeit, Performance bei Lese-/Schreibzugriff im Verhältnis zur Datenmenge, Aggregationsfunktionen, Reporting.

Es gibt keine einfache Empfehlung und kein „einzig bestes“ Werkzeug. Nach einer ersten Due Diligence lässt sich das passende Setup für Ihre aktuelle Landschaft empfehlen.

KPIs und ROI

Messen Sie die Ergebnisse, die zählen:

Integrationszeit: Zeit, die nötig ist, um eine neue Maschine anzubinden.
Datenverfügbarkeit: Anteil der Werks-Assets, die im UNS sichtbar sind.
Eingesparte Engineering-Stunden: Stunden, die nicht mehr für Punkt-zu-Punkt-Skripte anfallen.
MTTR (Mean Time To Recovery): verbessert durch schnellere Diagnose über den UNS.

Typische Fehler und ihre Behebung

Topic-Wildwuchs:

Symptom: Beliebige Topics wie temp_test_final_v2 tauchen im UNS auf.
Abhilfe: Strikte ACLs, die das Publizieren auf undefinierte Topics ablehnen. Ein Topic-Register mit regelmäßigem Monitoring. Governance und klare Verantwortliche je Topic.

Undokumentierte Payloads:

Symptom: Konsumenten brechen, sobald sich ein Feldname ändert.
Abhilfe: Versionierung und allgemein akzeptierte Schemas verwenden.

Broker als Datenbank:

Symptom: Versuche, historische Daten aus dem Broker abzufragen.
Abhilfe: Broker bewegen Daten, Historians speichern Daten. Den Broker per Bridge an einen Historian anbinden.

Vermischung von Dev und Prod:

Symptom: Testdaten verunreinigen das Produktions-Dashboard.
Abhilfe: Unterschiedliche Root-Topics (z. B. /prod/acme/… vs. /test/acme/…) oder getrennte Broker.

Broker als Single Point of Failure (SPOF):

Symptom: Bei einem Broker-Ausfall gibt es keinen Datenaustausch und keine UNS-Aktualisierung mehr.
Abhilfe: HA-Clustering oder Primär/Sekundär mit getestetem Failover.

Zu frühes Über-Modellieren:

Symptom: Viel Zeit fließt früh in die Dokumentation aller denkbaren Standards. Die Discovery-Phase zieht sich in die Länge.
Abhilfe: Minimal starten und mit echten Konsumenten iterieren.

Governance und Lebenszyklus

Halten Sie die Governance schlank, aber strikt:

Verantwortung und Steuerung: klare Verantwortliche für einzelne Teile der Hierarchie bzw. Topics; regelmäßige Governance-Meetings, um Änderungen zu prüfen und zu entscheiden. Starke Data-Governance-Praktiken sind unverzichtbar, um Datenqualität, Sicherheit und Compliance im Unified Namespace zu erhalten.
Versionierungsrichtlinie: semantische Versionierung; Breaking Changes erfordern eine neue Major-Version.
Abkündigungen: Release Notes und geplante Entfernungstermine veröffentlichen.
Fenster für Abwärtskompatibilität: z. B. 90–180 Tage für Major-Versionen.
Änderungsfenster: an den OT-Wartungsfenstern ausrichten.
Dokumentationsvorlagen: je Topic/Payload: Verantwortlicher, Zweck, Schema-Link, Beispiele, QoS, Aufbewahrung, Konsumenten.

Rollout-Checkliste für den Unified Namespace (UNS)

Asset-Inventar abgeschlossen und CMMS-IDs abgeglichen
HA-Muster für den Broker ausgewählt und getestet
Namespace-Style-Guide veröffentlicht (Topics und IDs)
Regeln für Payload-Schemas definiert (JSON Schema plus Versionierung)
Standards für QoS/Retained/LWT vereinbart
MQTT-ACL-Vorlagen erstellt und validiert
Edge-Gateway-Vorlage gebaut (Pufferung, Reconnect-Verhalten)
Pilotlinie publiziert Telemetrie und Ereignisse
Ein echter Konsument per Abonnement angebunden
Historian-Integration validiert (Zeitstempel/Qualität)
Monitoring-Dashboards und Alarme aktiv
PKI und Zertifikatslebenszyklus definiert
Netzwerkzonen/DMZ-Muster freigegeben
Zeitsynchronisation geprüft (NTP/PTP)
Change Board und Abkündigungsprozess aktiv

UNS im DACH-Kontext: OPC UA, Siemens-Landschaften und NIS2

In deutschen, österreichischen und Schweizer Werken sieht das Brownfield oft ähnlich aus: Siemens-Steuerungen (S7-300/400/1200/1500) mit PROFINET dominieren den Shopfloor, daneben laufen Anlagen mit Beckhoff, B&R oder Rockwell, und fast überall gibt es eine gewachsene SCADA- und Historian-Landschaft. Ein Unified Namespace ersetzt diese Systeme nicht. Er legt sich als Datenschicht darüber und macht aus heterogenen Protokollen einen einheitlichen, kontextualisierten Datenstrom.

Eine häufige Frage aus der DACH-Region lautet: OPC UA oder MQTT? Die Antwort ist in der Praxis „beides“. OPC UA – mit den Companion Specifications aus dem VDMA-Umfeld – liefert die semantische Beschreibung der Maschine und ist der Standard für die Anbindung an der Edge. MQTT ist das Transportprotokoll für den UNS selbst: leichtgewichtig, Publish/Subscribe, geeignet für viele Konsumenten. Mit OPC UA PubSub und Sparkplug B wachsen beide Welten zusammen; ein Edge-Gateway wie Kepware liest OPC UA und PROFINET und publiziert strukturiert nach MQTT.

Der dritte DACH-spezifische Treiber ist die Regulierung. NIS2 und die Anforderungen an KRITIS-Betreiber verlangen nachvollziehbare Zugriffskontrolle, Protokollierung und Segmentierung auch im OT-Netz. Ein UNS mit TLS, Client-Zertifikaten, ACLs und einer sauberen DMZ-Architektur erfüllt diese Anforderungen nicht nebenbei, sondern macht sie zum Konstruktionsprinzip. Wer den UNS mit Security-by-Design aufbaut, hat beim nächsten Audit deutlich weniger zu erklären.

Fazit

Die Einführung eines Unified Namespace ist ein Paradigmenwechsel von „Integration“ zu „Modellierung“. Sie führt weg von fragilen Punkt-zu-Punkt-Verbindungen hin zu einer resilienten, ereignisgesteuerten Architektur – und beantwortet die Frage, was Unified Namespace in der Praxis bedeutet.

Wenn Sie es ernst meinen mit der Implementierung eines Unified Namespace, fangen Sie klein an: Wählen Sie eine Linie, führen Sie einen Workshop durch, publizieren Sie einige hochwertige Signale und Ereignisse und weisen Sie nach, dass ein Konsument ohne neue SPS-Integration angebunden werden kann. Dann härten Sie die Sicherheit, standardisieren und skalieren Werk für Werk – mit Governance.

Nächster Schritt: Versuchen Sie nicht, das gesamte Unternehmen auf dem Papier zu architektieren. Beginnen Sie mit einer Linie. Vereinbaren Sie in einem Workshop die Namenskonvention für diese Linie, stellen Sie einen Broker bereit und bringen Sie die Daten zum Fließen. Skalierbarkeit entsteht aus dem Standard, nicht aus der Software. Wie wir Sie dabei unterstützen, erfahren Sie auf unserer Seite zum Unified Namespace für die Fertigung.

Unified Namespace mit Experten aufbauen

Verbinden Sie IT und OT mit einer skalierbaren UNS-Architektur in Echtzeit – ausgelegt auf Ihr Brownfield, mit Governance und Sicherheit vom ersten Tag an.

UNS-Services entdecken

Häufige Fragen zum Unified Namespace

Ist ein Unified Namespace ein Produkt, das man kaufen kann?

Nein. Ein UNS ist ein Architekturkonzept. Umgesetzt wird es mit einem MQTT-Broker, Edge-Gateways und einer verbindlichen Namens- und Payload-Konvention. Die Software ist austauschbar, der Standard nicht.

Ersetzt ein UNS unser MES oder SCADA?

Nein. MES und SCADA bleiben Produzenten und Konsumenten im UNS. Der Unterschied: Sie tauschen Daten über den Broker aus statt über individuelle Punkt-zu-Punkt-Schnittstellen, und lassen sich dadurch leichter ersetzen oder ergänzen.

OPC UA oder MQTT – was brauchen wir für einen UNS?

In der Regel beides: OPC UA für die semantisch reiche Anbindung der Maschinen an der Edge, MQTT als Publish/Subscribe-Transport für den UNS selbst. Ein Edge-Gateway übersetzt dazwischen.

Wie lange dauert ein UNS-Pilot?

Ein Pilot für eine Linie oder Zelle dauert typischerweise vier bis acht Wochen, nach einer Discovery-Phase von ein bis drei Wochen pro Standort. Die Skalierung auf ein Werk und weitere Standorte ist ein Programm von mehreren Monaten.

Wie sicher ist ein UNS im Hinblick auf NIS2?

So sicher, wie Sie ihn bauen. TLS, gegenseitige Authentifizierung mit Zertifikaten, ACLs nach dem Least-Privilege-Prinzip, Audit-Logging und eine DMZ-Architektur sind die Grundlage – und decken zugleich zentrale Anforderungen von NIS2 an OT-Umgebungen ab.

Glossar

UNS: Unified Namespace

IIoT: Industrial Internet of Things

MQTT: Publish/Subscribe-Messaging-Protokoll

QoS: Quality of Service (Stufen der Zustellgarantie)

ACL: Access Control List für Topic-Berechtigungen

DCS: Distributed Control System (Prozessleitsystem)

MES: Manufacturing Execution System

CMMS: Computerized Maintenance Management System (Instandhaltungssoftware)

OEE: Overall Equipment Effectiveness (Gesamtanlageneffektivität)

ISA-95/88: Standards für die Modellierung von Fertigung und Batch-Prozessen

PKI: Public Key Infrastructure (Zertifikate, Vertrauen)

HA: High Availability (Hochverfügbarkeit)

Walker Reynolds: Experte und Vordenker im Bereich Unified Namespace (UNS) und industrielle Automatisierung, bekannt für seinen Einfluss auf die Entwicklung der UNS-Architektur und für die Verbreitung und Erklärung dieser Technologie in der Industrie.