Unified Namespace im MES: eine Architektur statt hundert Schnittstellen
Ein Unified Namespace (UNS) ist ein Architekturansatz für die Fertigungs-IT, bei dem ein zentraler MQTT-Broker mit dem Sparkplug-B-Protokoll als einzige verbindliche Datenquelle (single source of truth) für Maschinen-, MES-, SCADA- und ERP-Daten dient, organisiert in einem hierarchischen, an ISA-95 angelehnten Themenbaum von Enterprise über Site, Area und Line bis Device. Für Fertigungsunternehmen in Deutschland, Österreich und der Schweiz löst dieser Ansatz ein strukturelles Problem klassischer MES-Landschaften: die wachsende Zahl fester Punkt-zu-Punkt-Schnittstellen zwischen Maschinen, MES, SCADA, ERP und Cloud-Systemen. Laut Bitkom-Studienbericht Industrie 4.0 2025 setzen bereits 46 Prozent der befragten Industrieunternehmen IoT-Plattformen ein und weitere 43 Prozent planen dies, während laut einer VDMA-Erhebung unter mehr als 600 Maschinen- und Anlagenbauern über 90 Prozent einen Bedarf an interoperablen, herstellerunabhängigen Schnittstellen sehen. Diese Seite erklärt das UNS-Konzept technisch fundiert, ordnet es in die MES-Auswahl ein und zeigt, worauf bei der Bewertung einer bestehenden Integrationsarchitektur zu achten ist.
Ein Namensraum,
eine Wahrheit.
Der Begriff Unified Namespace stammt aus der IIoT- und Sparkplug-Community rund um die Eclipse Foundation und beschreibt keinen einzelnen Produktnamen, sondern ein Architekturmuster.
Ein Unified Namespace ist ein zentrales, ereignisgesteuertes Datenrückgrat, in dem jedes Gerät, jede Maschine und jedes System seine Daten unter einem eindeutigen, hierarchisch strukturierten Themennamen (Topic) veröffentlicht, statt sie über feste Einzelverbindungen an ein bestimmtes Zielsystem zu senden. Technisch basiert der Ansatz meist auf dem Nachrichtenprotokoll MQTT (Message Queuing Telemetry Transport), einem 1999 entwickelten und seit 2013 bei der Organization for the Advancement of Structured Information Standards (OASIS) genormten Publish/Subscribe-Protokoll, kombiniert mit der Sparkplug-Spezifikation der Eclipse Foundation, einer gemeinnützigen Open-Source-Stiftung mit Sitz in Brüssel. Sparkplug definiert laut der Eclipse Sparkplug Working Group ein einheitliches Topic-Namensschema, ein kompaktes Nachrichtenformat auf Protobuf-Basis sowie Statusmeldungen für Geräteverfügbarkeit (Birth/Death-Zertifikate); die aktuelle Hauptversion Sparkplug 3.0 wurde im Dezember 2022 veröffentlicht und laut Eclipse Foundation parallel für ein beschleunigtes Verfahren zur internationalen Normung eingereicht. Ein zentraler MQTT-Broker, der die Sparkplug-B-Kodierung versteht, fungiert dabei als einzige verbindliche Datenquelle (single source of truth): Jedes System, das etwas über den Zustand einer Maschine wissen will, etwa ein MES, ein SCADA-System oder ein ERP, abonniert den passenden Themenzweig, statt eine eigene Verbindung zur Maschine aufzubauen.
Zentraler MQTT/Sparkplug-B-Broker
Ein MQTT-Broker (z. B. Eclipse Mosquitto, HiveMQ oder EMQX) verteilt Nachrichten nach dem Publish/Subscribe-Prinzip. Sparkplug B standardisiert Topic-Struktur, Nutzdatenformat und Geräte-Status darauf.
Single Source of Truth
Der aktuelle Zustand jedes Datenpunkts liegt genau einmal im Broker vor (Retained Messages). Neue Konsumenten erhalten beim Abonnieren sofort den letzten bekannten Wert, ohne die Quelle erneut abzufragen.
Hierarchischer, ISA-95-naher Topic-Baum
Themen werden als Pfad organisiert, etwa Enterprise/Site/Area/Line/Device, angelehnt an die Ebenen aus ISA-95 (ANSI/ISA-95, IEC 62264). Das macht Datenherkunft und -kontext im Topic-Namen selbst lesbar.
Event-driven statt Request/Response
Geräte melden Änderungen aktiv (Report by Exception), statt zyklisch abgefragt zu werden. Konsumenten reagieren auf Ereignisse, statt in festen Intervallen zu pollen.
Entkopplung von Erzeuger und Verbraucher
MES, SCADA und ERP kennen sich gegenseitig nicht mehr direkt. Jedes System ist entweder Publisher, Subscriber oder beides gegenüber dem Broker, nie eine feste Direktverbindung zu einem anderen Anwendungssystem.
Neutralität gegenüber Anwendungssystemen
Der Namespace selbst enthält keine Business-Logik. Auswertung, Regelwerke und Workflows bleiben in MES, MOM- oder Analytics-Systemen, die den Namespace lediglich als Datenquelle nutzen.
Quelle: Eclipse Foundation, Eclipse Sparkplug Working Group, sparkplug.eclipse.org, Spezifikationsübersicht und Release-Historie Sparkplug 3.0, Stand 2026; OASIS, MQTT Version 5.0 Standard. Der Begriff „Unified Namespace" ist kein genormter Fachbegriff eines Normungsgremiums, sondern ein in der IIoT-Praxis etabliertes Architekturmuster auf Basis von MQTT und Sparkplug.
So liest sich
ein UNS-Topic-Baum.
Der Themenbaum eines Unified Namespace bildet die reale Werksstruktur ab. Jede Ebene entspricht einer Zeile im ISA-95-Ebenenmodell, jeder Blattknoten einem konkreten Datenpunkt.
| ISA-95-Ebene | UNS-Topic-Segment | Beispielpfad | Typischer Inhalt |
|---|---|---|---|
| Enterprise | Unternehmen | Sectorlens-Fertigung/… | Konzern- oder Unternehmensname als Namespace-Wurzel |
| Site | Werk / Standort | …/Werk-Leipzig/… | Physischer Produktionsstandort |
| Area | Bereich | …/Montage/… | Fertigungsbereich oder Halle innerhalb des Werks |
| Line | Linie / Zelle | …/Linie-3/… | Produktionslinie, Fertigungszelle oder Arbeitsplatz |
| Device | Gerät / Datenpunkt | …/Roboter-07/Zykluszeit | Konkrete Maschine, Sensor oder Kennzahl als Blattknoten |
Ein MES, das die aktuelle Zykluszeit von Roboter 7 in Linie 3 des Werks Leipzig benötigt, abonniert den Pfad Sectorlens-Fertigung/Werk-Leipzig/Montage/Linie-3/Roboter-07/Zykluszeit beim zentralen Broker und erhält jede Änderung in Echtzeit, ohne eine eigene Verbindung zur Robotersteuerung aufzubauen. Ein ERP-System, das nur Auftragsfortschritt auf Linienebene braucht, abonniert stattdessen einen höher liegenden Zweig des Baums. Beide Systeme lesen aus derselben Struktur, ohne voneinander zu wissen. Diese Adressierbarkeit nach Werk, Bereich, Linie und Gerät ist der Kern dessen, was die Sparkplug-Spezifikation als strukturiertes Topic-Namensschema vorgibt, angewendet auf die im MES-Umfeld etablierte ISA-95-Hierarchie.
Quelle: Eclipse Foundation, Sparkplug-Spezifikation (Topic-Namespace-Format spBv1.0/group_id/message_type/edge_node_id/device_id), sparkplug.eclipse.org; ISA (International Society of Automation), ANSI/ISA-95 Teil 1, Ebenenmodell. Eine vertiefte Erklärung des Ebenenmodells finden Sie unter ISA-95 und IEC 62264 erklärt.
Vier Schichten,
ein Datenfluss.
Unabhängig vom gewählten Broker-Produkt folgen die meisten Unified-Namespace-Implementierungen im Fertigungsumfeld demselben Vier-Schichten-Aufbau von der Maschine bis zur Auswertung.
│ OPC UA, Modbus, proprietäre Feldprotokolle
▼
Edge-Schicht — Gateway übersetzt Feldprotokolle in MQTT/Sparkplug B
│ publiziert auf Topic-Pfad Enterprise/Site/Area/Line/Device
▼
Namespace-Schicht — zentraler MQTT/Sparkplug-B-Broker (single source of truth)
│ Publish/Subscribe, Retained Messages, Birth/Death-Zertifikate
▼
Anwendungsschicht — MES, SCADA, ERP, Historian/Analytics, Dashboards
Feldebene
Maschinen, SPS und Sensoren erzeugen Rohdaten in herstellerspezifischen Protokollen. Diese Schicht entspricht Level 0 und 1 des ISA-95-Ebenenmodells und ist im UNS-Muster selbst noch nicht Teil des Namespace.
Edge-Gateway
Ein Edge-Gerät übersetzt Feldprotokolle wie OPC UA oder Modbus in MQTT/Sparkplug-B-Nachrichten und veröffentlicht sie unter dem passenden Topic-Pfad. Details zur Rolle von Edge-Rechenleistung im MES-Kontext erklärt Edge Computing im MES.
Namespace-Schicht
Der zentrale Broker hält den aktuellen Zustand jedes Topics als Retained Message vor und verteilt Änderungen in Echtzeit an alle Abonnenten. Diese Schicht ist der eigentliche Unified Namespace.
Anwendungsschicht
MES, SCADA, ERP sowie Historian- und Analytics-Systeme abonnieren die für sie relevanten Topic-Zweige. Analytics-Systeme berechnen daraus häufig Fertigungskennzahlen nach ISO 22400, etwa die Gesamtanlageneffektivität (OEE), ohne eine eigene Maschinenanbindung zu benötigen.
Quelle: Eclipse Foundation, Sparkplug-Spezifikation, sparkplug.eclipse.org, Schichtmodell abgeleitet aus dem in der IIoT-Praxis etablierten Edge-Broker-Anwendungs-Muster; ISO 22400, Kennzahlendefinitionen für die Fertigungsleistung (Key Performance Indicators for Manufacturing Operations Management), Stand 2026. Eigene Sectorlens-Darstellung der Schichtzuordnung.
Von n·(n−1)/2 Verbindungen
zu einer Architektur.
Der klassische Integrationsansatz verbindet Systeme paarweise direkt miteinander. Mit jedem neuen System wächst die Zahl nötiger Schnittstellen quadratisch, nicht linear.
Im klassischen Punkt-zu-Punkt-Integrationsmodell erhält jedes Paar von Systemen, das Daten austauschen muss, eine eigene, individuell entwickelte und gewartete Schnittstelle: die SPS spricht direkt mit dem MES, das MES direkt mit dem ERP, das SCADA-System direkt mit dem MES, das ERP direkt mit dem Lagerverwaltungssystem, und so weiter. Mathematisch ergibt sich bei n Systemen, die potenziell alle miteinander Daten austauschen müssen, eine maximale Zahl möglicher Punkt-zu-Punkt-Verbindungen von n·(n−1)/2. Bei 5 Systemen (etwa SPS, MES, SCADA, ERP, Qualitätsmanagement) sind das bis zu 10 mögliche Einzelverbindungen, bei 10 Systemen bereits 45, bei 15 Systemen 105. Jede dieser Verbindungen bedeutet in der Praxis: ein eigenes Protokoll oder eine eigene API, eigene Fehlerbehandlung, eigene Versionspflege bei jedem Software-Update auf einer der beiden Seiten, und häufig eine Abhängigkeit von genau der Person, die die Schnittstelle ursprünglich gebaut hat. Ein Unified Namespace ersetzt dieses n·(n−1)/2-Muster durch ein n-Muster: Jedes System braucht nur noch eine einzige Verbindung, die zum zentralen Broker. Bei 10 Systemen sind das 10 Verbindungen statt bis zu 45, bei 15 Systemen 15 statt bis zu 105. Neue Systeme lassen sich anschließen, ohne bestehende Verbindungen anzufassen, weil sie lediglich zusätzliche Publisher oder Subscriber am selben Broker werden.
| Dimension | Punkt-zu-Punkt (klassisch) | Unified Namespace |
|---|---|---|
| Kommunikationsmuster | Request/Response, oft zyklisches Polling | Event-driven, Publish/Subscribe, Report by Exception |
| Kopplung | Eng gekoppelt: Systeme kennen Gegenstelle direkt | Entkoppelt: Systeme kennen nur den Broker |
| Schnittstellenzahl bei n Systemen | Bis zu n·(n−1)/2 | Bis zu n (je System eine Verbindung zum Broker) |
| Neues System anbinden | Neue Einzelschnittstelle zu jedem relevanten Bestandssystem | Ein zusätzlicher Publisher/Subscriber am bestehenden Broker |
| Datenaktualität | Abhängig vom Abfrageintervall der jeweiligen Punkt-Schnittstelle | Nahezu in Echtzeit bei Zustandsänderung |
| Fehlerquelle bei Systemausfall | Jede betroffene Punktverbindung muss einzeln geprüft werden | Broker-Status und Birth/Death-Zertifikate zeigen Verfügbarkeit zentral an |
Eigene Sectorlens-Darstellung auf Basis der Kombinatorik von Punkt-zu-Punkt-Netzwerken (n·(n−1)/2-Formel für ungerichtete Verbindungen zwischen n Knoten) und der MQTT/Sparkplug-Spezifikation der Eclipse Foundation, sparkplug.eclipse.org, Stand 2026. Die Zahlenbeispiele sind illustrative Obergrenzen für den Fall, dass tatsächlich jedes System mit jedem anderen Daten austauschen müsste; in der Praxis ist die tatsächliche Schnittstellenzahl oft niedriger, aber mit jedem zusätzlichen System überproportional wachsend.
MES, SCADA, ERP:
Publisher und Subscriber statt Nachbarsysteme.
Im Unified-Namespace-Modell verändert sich nicht, was MES, SCADA und ERP tun, sondern wie sie miteinander sprechen.
SCADA / HMI
Überwacht und steuert den physischen Prozess in Echtzeit. Im UNS publiziert SCADA Prozesswerte in den Namespace, statt sie ausschließlich lokal zu halten oder einzeln an das MES weiterzureichen.
MES / MOM
Bündelt Fertigungsauftragssteuerung, Qualität, Instandhaltung und Bestand. Im UNS ist das MES sowohl Subscriber von Maschinen- und Prozessdaten als auch Publisher von Auftragsfortschritt, Losnummern und Qualitätsstatus.
ERP
Verantwortet Auftragsplanung, Einkauf und Finanzen. Im UNS abonniert das ERP verdichtete Fertigungskennzahlen aus dem Namespace, statt für jede Kennzahl eine eigene Punkt-Schnittstelle zum MES zu pflegen.
Ein Unified Namespace ersetzt keine dieser Systeme und übernimmt keine ihrer Funktionen. Die Frage, ob ein MES nötig ist, bleibt unabhängig von der Integrationsarchitektur bestehen: Ein UNS liefert die Datenbasis, ein MES liefert die Fertigungslogik darauf. Eine Systemübersicht mit Zuständigkeitsmatrix bietet MES, ERP, SCADA und MOM im Überblick.
Kein Ersatz für OPC UA,
sondern eine andere Ebene.
MQTT/Sparkplug und OPC UA (Open Platform Communications Unified Architecture) lösen unterschiedliche Probleme und werden in vielen Fertigungsarchitekturen kombiniert.
OPC UA (IEC 62541), ein plattformunabhängiger Kommunikationsstandard der OPC Foundation, einer 1996 gegründeten Non-Profit-Organisation mit Sitz in Scottsdale, Arizona, definiert sowohl Informationsmodelle als auch Übertragungsmechanismen für die Maschine-zu-Maschine-Kommunikation und wird häufig auf Feldebene zwischen Steuerungen und SCADA-Systemen eingesetzt. Laut OPC Foundation existieren mittlerweile über 60 sogenannte Companion Specifications, die branchenspezifische Informationsmodelle auf OPC UA standardisieren, und die Organisation arbeitet aktiv an Publish/Subscribe-Erweiterungen (OPC UA PubSub) und an Companion-Spezifikationen, die OPC UA gezielt mit MQTT-basierten Unified-Namespace-Architekturen verknüpfen. In der Praxis übernimmt OPC UA häufig die standardisierte, semantisch reiche Anbindung einzelner Steuerungen und Maschinen, während MQTT/Sparkplug die leichtgewichtige, broker-basierte Verteilung dieser Daten über das gesamte Werk und Unternehmen hinweg übernimmt; ein OPC-UA-Server kann als einer von vielen Publishern in einen Unified Namespace einspeisen. Ein Unified Namespace ersetzt außerdem weder ein Manufacturing Execution System noch ersetzt er IT/OT-Konvergenz als Organisationsthema: Governance-Fragen wie Datenhoheit, Zugriffsrechte, Netzwerksegmentierung zwischen Office-IT und Fertigungs-OT und die Verantwortung für den Betrieb des Brokers selbst bleiben zu klären, unabhängig davon, wie elegant die Topic-Struktur modelliert ist.
Quelle: OPC Foundation, opcfoundation.org, Übersicht UA Companion Specifications und OPC UA PubSub, Stand 2025/2026. Vertiefend zur OPC-UA-Anbindung im MES-Kontext: OPC UA im MES; zu Organisationsfragen der IT/OT-Konvergenz: IT/OT-Konvergenz im MES.
Der Broker wird
zu kritischer Infrastruktur.
Weil alle beteiligten Systeme über denselben zentralen Broker kommunizieren, verlangt ein Unified Namespace ein eigenes Sicherheits- und Betriebskonzept, das über die reine Topic-Modellierung hinausgeht.
Für die Absicherung industrieller Automatisierungs- und Steuerungssysteme (Industrial Automation and Control Systems, IACS) existiert mit der Normreihe IEC 62443 ein internationaler Standard, der ursprünglich als ISA-99 von der International Society of Automation entwickelt und anschließend in die IEC-Normung überführt wurde. IEC 62443 definiert unter anderem das Zonen-und-Conduits-Modell, bei dem ein Netzwerk in Sicherheitszonen mit vergleichbarem Schutzbedarf unterteilt wird, die über kontrollierte Übergänge (Conduits) miteinander kommunizieren, sowie vier abgestufte Security Level (SL 1 bis SL 4) für Angreiferfähigkeiten von zufälliger bis gezielter, ressourcenstarker Kompromittierung. Ein zentraler MQTT/Sparkplug-Broker fungiert dabei typischerweise als kontrollierter Übergang zwischen der OT-Zone der Fertigung und der IT-Zone der Unternehmenssysteme und sollte entsprechend als eigene Schutzzone betrachtet werden, nicht als neutrale Durchleitung.
TLS und Client-Zertifikate
Verbindungen zum Broker sollten per TLS verschlüsselt und Publisher wie Subscriber über Client-Zertifikate oder Benutzer-Credentials authentifiziert werden, statt anonyme Verbindungen zuzulassen.
Zugriffsrechte je Topic
Access Control Lists (ACLs) legen je Topic-Zweig fest, welches System lesen und welches schreiben darf. Ein SCADA-System etwa darf typischerweise nur unterhalb der ihm zugeordneten Line publizieren.
Hochverfügbarkeit und Monitoring
Da ein Ausfall des Brokers potenziell alle angeschlossenen Systeme betrifft, setzen produktive UNS-Umgebungen meist auf Broker-Cluster mit Redundanz sowie aktives Monitoring der Birth/Death-Zertifikate je Gerät.
Quelle: ISA/IEC 62443, internationale Normreihe für Cybersicherheit industrieller Automatisierungs- und Steuerungssysteme, iec.ch, Zonen-und-Conduits-Modell sowie Security-Level-Konzept SL 1 bis SL 4; Eclipse Foundation, Sparkplug-Spezifikation zu Birth/Death-Zertifikaten, sparkplug.eclipse.org. Die konkrete Verantwortungsteilung zwischen IT- und OT-Organisation für den Brokerbetrieb ist eine unternehmensspezifische Governance-Frage und kein technischer Standardwert.
Wann ein UNS
den Aufwand wert ist.
Ein Unified Namespace ist eine Architekturentscheidung mit Implementierungsaufwand. Er lohnt sich dort am meisten, wo die Zahl der Systeme und Standorte bereits Integrationsdruck erzeugt.
Mehrere Standorte oder Linien
Werke mit mehreren Fertigungslinien oder mehreren Standorten profitieren am stärksten, da sich der ISA-95-Topic-Baum über Werksgrenzen hinweg konsistent skalieren lässt.
Heterogener Maschinenpark
Bei Maschinen unterschiedlicher Hersteller und Baujahre reduziert ein zentraler Broker die Zahl proprietärer Einzeltreiber, sofern Edge-Gateways die Feldprotokolle in MQTT/Sparkplug übersetzen.
Wachsende Systemlandschaft
Wer in den nächsten Jahren weitere Systeme anbinden will, etwa Energiemonitoring, Predictive Maintenance oder ein zweites ERP-Modul, spart mit jedem weiteren System überproportional an Integrationsaufwand.
Bestehende Punkt-zu-Punkt-Altlasten
Werke mit historisch gewachsenen Einzelschnittstellen, die nur noch der ursprüngliche Integrator versteht, gewinnen durch die Migration auf einen Namespace dokumentierte, wartbare Struktur.
Geringer Nutzen bei kleinen Einzelwerken
Ein Werk mit einer Linie und drei Systemen hat selten mehr als drei bis sechs mögliche Punktverbindungen; der Architekturaufwand eines UNS übersteigt hier oft den kurzfristigen Nutzen.
Betriebsverantwortung klären
Der Broker wird selbst zu kritischer Infrastruktur. Ohne geklärte Zuständigkeit für Betrieb, Hochverfügbarkeit und Berechtigungen im Broker entsteht ein neuer Single Point of Failure.
In der MES-Auswahl zeigt sich der Reifegrad des UNS-Themas meist zuerst im Lastenheft: Anbieter werden gefragt, ob ihr MES nativ als MQTT/Sparkplug-B-Client publizieren und abonnieren kann, ob es sich in einen bestehenden Broker (etwa HiveMQ, Eclipse Mosquitto oder EMQX) einbinden lässt, oder ob eine Anbindung nur über einen zusätzlichen, separat zu wartenden Adapter möglich ist. Diese Frage lässt sich strukturiert im MES Selection Portal abbilden, das Integrationsfähigkeit als eines von über 80 Merkmalen in der Anbieterbewertung erfasst.
So beginnt
die Umstellung konkret.
Ein Unified Namespace wird nicht an einem Wochenende eingeführt. Sinnvoll ist ein schrittweiser Aufbau, der mit einer einzelnen Linie beginnt und bestehende Punkt-zu-Punkt-Schnittstellen zunächst unangetastet lässt.
Schnittstellen erfassen
Alle bestehenden Punkt-zu-Punkt-Verbindungen zwischen Maschinen, MES, SCADA und ERP dokumentieren: wer sendet was an wen, in welchem Intervall, über welches Protokoll.
Pilotlinie auswählen
Eine einzelne Linie oder Zelle mit überschaubarer Maschinenzahl als Pilotbereich festlegen, statt die gesamte Werksintegration auf einmal umzustellen.
Topic-Baum entwerfen
Die ISA-95-Ebenen Enterprise, Site, Area, Line und Device auf konkrete Namen im eigenen Werk abbilden und als verbindliche Namenskonvention dokumentieren, bevor die erste Nachricht veröffentlicht wird.
Edge-Gateways einrichten
Für jede Maschine oder Steuerung, die kein natives MQTT/Sparkplug spricht, ein Edge-Gateway zur Protokollübersetzung konfigurieren und gegen den Topic-Baum aus Schritt 3 veröffentlichen.
Sicherheitskonzept festlegen
Zugriffsrechte je Topic, Verschlüsselung und Betriebsverantwortung für den Broker klären, bevor produktive Systeme daran angeschlossen werden.
Bestandssysteme schrittweise anbinden
MES, SCADA und ERP nacheinander als Publisher oder Subscriber am Namespace anschließen und bestehende Punkt-zu-Punkt-Schnittstellen erst nach erfolgreichem Parallelbetrieb ablösen.
Dieser Migrationspfad läuft parallel zur eigentlichen MES-Auswahl, nicht davor oder danach: Ob ein bestehendes oder neu ausgewähltes MES sich als Publisher und Subscriber in Schritt 6 anbinden lässt, sollte bereits im Lastenheft geklärt sein, etwa mithilfe der Integrationskriterien aus Composable MES und Microservices.
Häufige Fragen
zum Unified Namespace.
Was ist ein Unified Namespace einfach erklärt?
Ein Unified Namespace ist ein zentrales, ereignisgesteuertes Datenrückgrat, meist auf Basis von MQTT und der Sparkplug-B-Spezifikation der Eclipse Foundation, in dem jedes System seine Daten unter einem eindeutigen, hierarchisch strukturierten Themennamen veröffentlicht. Statt fester Einzelverbindungen zwischen zwei Systemen liest jedes interessierte System die Daten aus einem gemeinsamen zentralen Broker. Der Namespace selbst ist keine Software, sondern ein Architekturmuster, das mit verschiedenen MQTT-Brokern umgesetzt werden kann.
Was ist der Unterschied zwischen Unified Namespace und MQTT?
MQTT (Message Queuing Telemetry Transport) ist ein 1999 entwickeltes, seit 2013 bei OASIS genormtes Nachrichtenprotokoll für Publish/Subscribe-Kommunikation. Ein Unified Namespace ist die konkrete Anwendung dieses Protokolls auf eine gesamte Fertigungsorganisation: eine bewusst gestaltete, hierarchische Topic-Struktur plus die organisatorische Entscheidung, MQTT als zentrales Integrationsrückgrat statt nur für einzelne Punktverbindungen zu nutzen. MQTT ist das Werkzeug, der Unified Namespace ist die Architekturentscheidung, wie es eingesetzt wird.
Was ist Sparkplug B und wozu wird es im Unified Namespace gebraucht?
Sparkplug B ist eine offene Spezifikation der Eclipse Sparkplug Working Group der Eclipse Foundation, die auf MQTT aufsetzt und ein einheitliches Topic-Namensschema, ein kompaktes Protobuf-Nachrichtenformat sowie Statusmeldungen für Geräteverfügbarkeit definiert. Die aktuelle Hauptversion Sparkplug 3.0 erschien im Dezember 2022. Ohne eine solche Spezifikation könnte zwar jedes System MQTT nutzen, aber Topic-Namen und Nachrichtenformate blieben uneinheitlich, wodurch der Vorteil eines gemeinsamen Namespace verloren ginge.
Wie unterscheidet sich ein Unified Namespace von klassischer Punkt-zu-Punkt-Integration?
Im klassischen Punkt-zu-Punkt-Modell erhält jedes Systempaar, das Daten austauschen muss, eine eigene direkte Schnittstelle, wodurch bei n Systemen bis zu n·(n−1)/2 mögliche Einzelverbindungen entstehen, etwa 45 bei 10 Systemen. Im Unified-Namespace-Modell verbindet sich jedes System nur einmal mit dem zentralen Broker, wodurch die maximale Verbindungszahl auf n sinkt. Neue Systeme lassen sich zudem anschließen, ohne bestehende Verbindungen zu verändern.
Ersetzt ein Unified Namespace ein MES?
Nein. Ein Unified Namespace ist eine Datenintegrationsarchitektur, kein Manufacturing Execution System. Er liefert Maschinen-, Prozess- und Statusdaten in Echtzeit an alle berechtigten Systeme, übernimmt aber keine Fertigungsauftragssteuerung, kein Qualitätsmanagement und keine Personaleinsatzplanung. Diese Funktionen bleiben Aufgabe des MES, das im UNS-Modell selbst als Publisher und Subscriber am Namespace teilnimmt.
Wie hängt ISA-95 mit dem Unified Namespace zusammen?
ISA-95 (ANSI/ISA-95, inhaltlich weitgehend deckungsgleich mit IEC 62264) definiert das etablierte fünfstufige Ebenenmodell für Fertigungsunternehmen, von Level 0 (physischer Prozess) bis Level 4 (Geschäftsplanung). Ein Unified Namespace übernimmt diese Logik häufig als Vorlage für seinen Topic-Baum, typischerweise abgebildet als Enterprise/Site/Area/Line/Device. ISA-95 liefert damit die inhaltliche Struktur, MQTT/Sparkplug die technische Umsetzung.
Was bedeutet event-driven im Zusammenhang mit einem Unified Namespace?
Event-driven bedeutet, dass Systeme Daten senden, sobald sich ein Wert ändert (Report by Exception), statt in festen Intervallen abgefragt zu werden (Polling). Ein Sensor meldet also nur dann eine neue Temperatur, wenn sie sich geändert hat, statt zum Beispiel jede Sekunde denselben Wert erneut zu übertragen. Das reduziert Netzwerklast und liefert Änderungen nahezu in Echtzeit an alle Abonnenten des jeweiligen Topics.
Was ist der Unterschied zwischen Publish/Subscribe und Request/Response?
Bei Request/Response fragt ein System aktiv bei einem anderen System an und wartet auf eine Antwort, wodurch beide Systeme sich gegenseitig kennen und erreichbar sein müssen. Bei Publish/Subscribe veröffentlicht ein System (Publisher) Daten an ein Thema beim Broker, ohne zu wissen, wer sie liest; interessierte Systeme (Subscriber) abonnieren dieses Thema unabhängig davon, ob der Publisher gerade aktiv ist. Diese Entkopplung ist die Grundlage der losen Kopplung im Unified Namespace.
Braucht ein Unified Namespace OPC UA oder ersetzt er es?
Ein Unified Namespace ersetzt OPC UA (Open Platform Communications Unified Architecture) nicht, sondern ergänzt es meist. OPC UA, standardisiert von der OPC Foundation, wird häufig für die semantisch reiche Anbindung einzelner Steuerungen und Maschinen genutzt; ein OPC-UA-Server kann dann als ein Publisher unter vielen in den Unified Namespace einspeisen. MQTT/Sparkplug übernimmt anschließend die leichtgewichtige Verteilung dieser Daten über das gesamte Werk hinweg.
Was ist ein MQTT-Broker und welche Broker werden für einen Unified Namespace genutzt?
Ein MQTT-Broker ist die zentrale Serverkomponente, die Nachrichten von Publishern entgegennimmt und an passende Subscriber verteilt; im Unified Namespace übernimmt er zusätzlich die Rolle der single source of truth durch sogenannte Retained Messages, die den letzten bekannten Wert je Topic dauerhaft vorhalten. Verbreitete Broker-Software für diesen Einsatzzweck sind unter anderem Eclipse Mosquitto, ein Open-Source-Projekt der Eclipse Foundation, sowie kommerzielle Angebote wie HiveMQ und EMQX. Die Wahl des konkreten Brokers ist unabhängig vom Unified-Namespace-Konzept als solchem.
Was kostet die Einführung eines Unified Namespace?
Die Hersteller von MQTT-Brokern und UNS-Werkzeugen veröffentlichen unterschiedliche Preismodelle, teils mit kostenlosen Open-Source-Basisversionen wie Eclipse Mosquitto und teils mit lizenzpflichtigen Enterprise-Editionen; ein einheitlicher Marktpreis lässt sich daher nicht seriös nennen. Sectorlens rät, die Kosten eines UNS-Projekts nicht isoliert auf die Broker-Lizenz zu beziehen, sondern Implementierung, Edge-Gateways zur Protokollübersetzung und den laufenden Betrieb als Gesamtkalkulation zu betrachten, etwa mit dem TCO-Rechner MES.
Ist ein Unified Namespace nur für Großunternehmen sinnvoll?
Nein, aber der Nutzen skaliert mit der Systemzahl. Werke mit mehreren Fertigungslinien, mehreren Standorten oder einer wachsenden Zahl anzubindender Systeme profitieren am stärksten, da die Zahl möglicher Punkt-zu-Punkt-Verbindungen dort am schnellsten steigt. Ein Einzelwerk mit wenigen Systemen kann von einer schlankeren Integration profitieren, sollte die Architekturfrage aber dennoch früh mitdenken, um spätere Migrationsaufwände zu vermeiden.
Welche Risiken hat ein zentraler Broker als single source of truth?
Da alle Systeme über denselben Broker kommunizieren, wird dieser zu kritischer Infrastruktur; fällt er aus oder ist er falsch konfiguriert, sind potenziell alle angeschlossenen Systeme betroffen. Üblich sind deshalb hochverfügbare Broker-Cluster, klar definierte Zugriffsrechte je Topic und ein dediziertes Betriebskonzept, das Verantwortlichkeiten zwischen IT und OT klärt. Diese Betriebsverantwortung ist eine organisatorische Entscheidung, keine rein technische.
Kann ein bestehendes MES nachträglich an einen Unified Namespace angebunden werden?
In vielen Fällen ja, sofern das MES über eine MQTT- oder Sparkplug-B-fähige Schnittstelle verfügt oder sich über einen Adapter beziehungsweise ein Middleware-Gateway anbinden lässt. Ob eine native Anbindung oder ein zusätzlicher Adapter nötig ist, unterscheidet sich stark je Anbieter und sollte im Auswahlprozess konkret abgefragt werden. Diese Integrationsfähigkeit lässt sich strukturiert über einen RFI-Fragebogen MES bei Anbietern erfragen.
Was ist Report by Exception im Zusammenhang mit Sparkplug?
Report by Exception ist eine Regel der Sparkplug-Spezifikation, nach der Datenerzeuger einen Wert nur dann erneut an den Namespace senden, wenn er sich seit der letzten Meldung tatsächlich geändert hat. Das unterscheidet sich von zyklischem Polling, bei dem ein Wert unabhängig von einer Änderung in festen Zeitabständen abgefragt wird. Report by Exception reduziert Netzwerklast erheblich, besonders bei einer großen Zahl von Sensoren mit selten wechselnden Werten.
Wie migriert man in der Praxis von Punkt-zu-Punkt-Integration zu einem Unified Namespace?
Der Umstieg erfolgt schrittweise und nicht als einmaliger Big-Bang-Wechsel: Zunächst werden bestehende Schnittstellen dokumentiert, dann eine einzelne Pilotlinie ausgewählt, ein ISA-95-naher Topic-Baum entworfen, Edge-Gateways zur Protokollübersetzung eingerichtet, ein Sicherheitskonzept für den Broker festgelegt und erst danach Bestandssysteme wie MES, SCADA und ERP nacheinander angebunden. Bestehende Punkt-zu-Punkt-Verbindungen werden dabei typischerweise erst nach erfolgreichem Parallelbetrieb abgelöst, nicht sofort abgeschaltet.
Welche Sicherheitsanforderungen gelten für den zentralen MQTT-Broker in einem Unified Namespace?
Da der Broker zu kritischer Infrastruktur wird, sollten Verbindungen per TLS verschlüsselt und über Client-Zertifikate oder Credentials authentifiziert werden, ergänzt um Zugriffsrechte je Topic-Zweig. Als Rahmenwerk für die Absicherung industrieller Automatisierungs- und Steuerungssysteme dient international die Normreihe IEC 62443, die unter anderem ein Zonen-und-Conduits-Modell sowie vier abgestufte Security Level definiert. Der Broker sollte dabei als eigene Sicherheitszone zwischen OT- und IT-Netzwerk betrachtet werden, nicht als neutrale Durchleitung.
Wie werden Daten aus einem Unified Namespace historisiert und für Kennzahlen wie OEE genutzt?
Ein Unified Namespace selbst speichert in der Regel nur den jeweils letzten Wert je Topic als Retained Message, keine vollständige Historie. Für Trendanalysen und Kennzahlen wie die Gesamtanlageneffektivität (Overall Equipment Effectiveness, OEE) abonniert ein separates Historian- oder Analytics-System den relevanten Topic-Zweig und schreibt jede Änderung in eine Zeitreihendatenbank. Die Berechnung solcher Kennzahlen folgt üblicherweise den Definitionen der Normreihe ISO 22400 für Fertigungskennzahlen.
Ihre Integrationsarchitektur
gehört auf den Prüfstand.
Bevor Sie ein MES auswählen oder eine bestehende Landschaft ablösen, lohnt sich eine nüchterne Bestandsaufnahme der heutigen Schnittstellenlage. Sectorlens unterstützt an drei Stellen.
MES Selection Portal
Über 80 strukturierte Merkmale je Anbieter, darunter Integrationsfähigkeit zu MQTT/Sparkplug, OPC UA und ERP-Standardschnittstellen, zum eigenständigen Vergleich.
Unabhängige Anbieterrecherche
Neutrale, ausschließlich primärquellenbasierte Aufbereitung von Anbieterangaben zu Architektur, Schnittstellen und Integrationskonzepten, ohne Bewertung einzelner Hersteller.
Bewertung der bestehenden Integrationsarchitektur
Einordnung der aktuellen Schnittstellenlandschaft anhand der n·(n−1)/2-Logik: wie viele Punkt-zu-Punkt-Verbindungen heute bestehen und wo ein Unified-Namespace-Ansatz strukturell entlasten könnte.
Integrationsarchitektur klären, bevor Sie ein MES auswählen.
Ob klassische Punkt-zu-Punkt-Integration oder Unified Namespace: Die richtige MES-Wahl hängt davon ab, wie Ihr Anbieter sich in die bestehende oder geplante Datenarchitektur einfügt. Das MES Selection Portal macht diesen Vergleich strukturiert und anbieterneutral.