Unified Namespace aufbauen: Schritt-für-Schritt-Anleitung

Wer weiß, wie man einen Unified Namespace (UNS) aufbaut, macht aus einem Schlagwort eine funktionierende Architektur: einen MQTT-Broker, an den jede Maschine, jede Linie und jedes System seinen aktuellen Zustand unter einem vorhersehbaren, hierarchiebasierten Topic publiziert. In diesem Tutorial modellieren Sie Ihr Werk, wählen einen Broker, publizieren Edge-Daten mit Python als Retained Messages, fügen einen Consumer hinzu, der den gesamten Anlagenzustand liest, und etablieren die Governance, die den Namespace auch bei Wachstum nutzbar hält.

Was Sie aufbauen

Ein Unified Namespace ist kein Produkt. Er ist eine Vereinbarung: Alle Producer publizieren in einen ereignisgesteuerten Hub, der nach einer gemeinsamen Struktur organisiert ist, und alle Consumer abonnieren genau das, was sie brauchen, statt Punkt-zu-Punkt-Integrationen zu bauen. In der Praxis ist dieser Hub ein MQTT-Broker, und die Struktur ist meist die ISA-95-Anlagenhierarchie.

Die fertige Architektur besteht aus vier Schichten:

Die entscheidende Eigenschaft ist die Entkopplung. Der Historian weiß nicht, dass die SPS existiert, und das SPS-Gateway weiß nicht, wer zuhört. Jeder verbindet sich genau einmal, nämlich mit dem Broker.

Schritt 1: Anlagenhierarchie modellieren

Bevor Sie Code schreiben, legen Sie fest, wie das Werk im Namespace organisiert ist. Die ISA-95-Anlagenhierarchie (IEC 62264) bietet einen bewährten Ausgangspunkt: Unternehmen, Standort, Bereich, Linie (oder Prozesszelle) und Zelle bzw. Maschine. Im UNS wird jede dieser Ebenen genau eine Topic-Ebene auf dem MQTT-Broker, also Enterprise → Site → Area → Line → Cell, zum Beispiel acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Unser Leitfaden zur ISA-95-Anlagenhierarchie erklärt jede Ebene mit Beispielen aus der Fertigung.

Arbeiten Sie für einen Pilotbereich eine kurze Liste ab:

1. Listen Sie die betroffenen Standorte auf und geben Sie jedem eine kurze, stabile Kennung in Kleinbuchstaben (dallas, stuttgart).
2. Listen Sie innerhalb eines Standorts die Bereiche auf (packaging, utilities, machining).
3. Listen Sie innerhalb eines Bereichs die Linien und ihre Maschinen auf (line2/filler, line2/capper).
4. Entscheiden Sie, was unter jede Maschine gehört: ein telemetry-Objekt, einzelne Metrik-Topics oder beides.
5. Halten Sie das Ergebnis als Topic-Baum fest und stimmen Sie ihn mit Produktion, Engineering und IT ab.

Ein erster Pilotbaum könnte so aussehen:

acme/dallas/packaging/line2/filler/telemetry
acme/dallas/packaging/line2/filler/state
acme/dallas/packaging/line2/capper/telemetry
acme/dallas/utilities/compressors/comp1/telemetry

Nehmen Sie sich hier Zeit. Ein Topic umzubenennen, nachdem zwanzig Consumer davon abhängen, ist mühsam. Unsere Leitfäden zu ISA-95-MQTT-Topics und zur UNS-Topic-Struktur enthalten fertige Bäume und die Fallstricke, die Sie vermeiden sollten.

Schritt 2: Den zentralen Broker wählen

Der Broker wird zur wichtigsten Software, die Sie im Werk betreiben, also wählen Sie ihn mit Bedacht. Er muss MQTT 3.1.1 für ältere Gateways und MQTT 5 für neuere Clients unterstützen, Retained Messages für den aktuellen Zustand, TLS mit Zugangsdaten pro Client sowie genügend Verbindungen für alle Gateways und Consumer, die Sie hinzufügen wollen. Eine vollständige Checkliste finden Sie unter IoT-MQTT-Broker auswählen.

Sie können den Broker selbst auf einem Server im Werk betreiben oder einen Cloud-MQTT-Broker nutzen, den jemand anderes betreibt. Werke starten den Pilot oft mit einem verwalteten MQTT-Broker, weil dadurch Server-Patching und Monitoring aus dem kritischen Pfad verschwinden. ConnectMQ zum Beispiel bietet jedem Broker MQTT 3.1.1 und 5.0, TLS auf Port 8883, einen Live-Topic-Explorer und eine Geräteansicht, die aktive Geräte nach ISA-95-Ebenen gruppiert – genau das, was Sie sehen möchten, während der Namespace Gestalt annimmt.

Für dieses Tutorial können Sie den öffentlichen MQTT-Broker unter broker.connectmq.com verwenden. Er benötigt kein Konto, aber alles, was dort publiziert wird, ist für jeden lesbar; er ist für Tests und Prototypen gedacht, nicht für Produktivdaten. Deshalb versehen wir die Topics mit dem Präfix connectmq/demo/<random-id>/ und publizieren nur simulierte Werte. Der öffentliche MQTT-Broker erlaubt bis zu 8 Topic-Ebenen, was genau zu connectmq/demo/k4p9/dallas/packaging/line2/filler/telemetry passt.

Schritt 3: Edge-Daten als Retained State publizieren

Die Edge-Schicht liest Maschinen aus und publiziert deren aktuellen Zustand. Echte Installationen nutzen OPC UA, Modbus oder SPS-Treiber; hier übernimmt ein Python-Skript die Rolle des Gateways, damit Sie die Publishing-Regeln klar erkennen. Installieren Sie den Client mit pip install "paho-mqtt>=2.0".

import json
import random
import time
from datetime import datetime, timezone

import paho.mqtt.client as mqtt

BROKER = "broker.connectmq.com"
PREFIX = "connectmq/demo/k4p9"     # k4p9 durch Ihre eigene Zufalls-ID ersetzen
MACHINES = [
    ("dallas", "packaging", "line2", "filler"),
    ("dallas", "packaging", "line2", "capper"),
]

def on_connect(client, userdata, flags, reason_code, properties):
    print("gateway connected:", reason_code)
    for site, area, line, machine in MACHINES:
        state_topic = f"{PREFIX}/{site}/{area}/{line}/{machine}/state"
        client.publish(state_topic, "online", qos=1, retain=True)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="uns-gateway-k4p9")
client.on_connect = on_connect
# Fällt das Gateway aus, markiert der Broker die erste Maschine für alle als offline
client.will_set(f"{PREFIX}/dallas/packaging/line2/filler/state", "offline", qos=1, retain=True)
client.connect(BROKER, 1883, keepalive=30)
client.loop_start()

counts = {m[3]: 0 for m in MACHINES}
try:
    while True:
        for site, area, line, machine in MACHINES:
            counts[machine] += random.randint(4, 6)
            payload = {
                "timestamp": datetime.now(timezone.utc).isoformat(),
                "speed_bpm": round(random.uniform(110, 125), 1),
                "temperature_c": round(random.uniform(38, 44), 1),
                "good_count": counts[machine],
            }
            topic = f"{PREFIX}/{site}/{area}/{line}/{machine}/telemetry"
            client.publish(topic, json.dumps(payload), qos=1, retain=True)
        time.sleep(5)
except KeyboardInterrupt:
    client.loop_stop()
    client.disconnect()

Drei Regeln machen daraus einen UNS-Publisher statt eines bloßen Datensenders. Jede Nachricht ist retained, sodass ein neuer Consumer sofort den aktuellen Wert erhält. Payloads tragen ihren eigenen Zeitstempel und die Einheiten in den Feldnamen. Und die Verfügbarkeit der Maschine ist explizit, mit einer Will-Message, die den Zustand auf offline setzt, wenn das Gateway verschwindet.

Wenn Ihre Edge bereits Sparkplug B spricht, müssen Sie sie nicht neu schreiben. ConnectMQ dekodiert Sparkplug-B-Payloads und kann sie in ISA-95-Topics erneut publizieren, zum Beispiel spBv1.0/factory1/DDATA/line1/cnc1 nach connectmq/factory1/production/line1/cnc1/telemetry. So können Sparkplug-Edge-Nodes und einfache JSON-Publisher einen gemeinsamen Namespace nutzen. Die Vor- und Nachteile beider Ansätze behandelt MQTT, Sparkplug B und der Unified Namespace.

Schritt 4: Die ersten Consumer hinzufügen

Ein Namespace zahlt sich aus, wenn Consumer hinzukommen, ohne dass jemand die Edge anfassen muss. Dieser Subscriber baut aus einem einzigen Wildcard-Abonnement ein In-Memory-Modell des gesamten Werks auf:

import json
import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/k4p9"
plant = {}

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/#", qos=1)

def on_message(client, userdata, msg):
    levels = msg.topic[len(PREFIX) + 1:].split("/")
    if len(levels) != 5:
        return
    site, area, line, machine, kind = levels
    node = plant.setdefault(site, {}).setdefault(area, {}).setdefault(line, {}).setdefault(machine, {})
    text = msg.payload.decode()
    node[kind] = json.loads(text) if kind == "telemetry" else text
    print(f"{site}/{area}/{line}/{machine} {kind}: {node[kind]}" + (" (retained)" if msg.retain else ""))

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="uns-viewer-k4p9")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

Starten Sie ihn, während das Gateway läuft, und achten Sie darauf, dass die ersten Nachrichten als retained markiert sind: Der Consumer hatte das vollständige Bild des Werks in dem Moment, in dem er abonniert hat. Grenzen Sie den Umfang mit Wildcards nach dem Präfix ein, zum Beispiel connectmq/demo/k4p9/+/packaging/# für einen Bereich an allen Standorten oder connectmq/demo/k4p9/+/+/+/filler/telemetry für jeden Abfüller überall.

Typische nächste Consumer sind ein Dashboard, ein Historian und ein Alarmierungsdienst. Jeder davon ist einfach ein weiterer Subscriber. Für die Speicherung zeigt unser Leitfaden zum MQTT-Historian, wie Telegraf- und Python-Subscriber Zeitreihendatenbanken befüllen; der Namespace bleibt die Quelle des aktuellen Zustands, während der Speicher die Historie hält.

Schritt 5: Den Namespace steuern

Ohne Regeln verkommt ein UNS innerhalb weniger Monate zu einem Topic-Sumpf. Führen Sie Folgendes ein, bevor der zweite Bereich hinzukommt:

• Namensstandard. Kleinbuchstaben, Bindestriche statt Leerzeichen, keine Personennamen oder Ticketnummern in Topics.
• Verantwortlichkeit. Jeder Zweig des Baums hat einen Owner, der neue Topics freigibt.
• Payload-Vertrag. Ein dokumentiertes JSON-Schema pro Topic-Typ, mit Regeln für Einheiten und Zeitstempel.
• Zugangsdaten pro Publisher. Eine Identität pro Gateway oder Anwendung, damit Sie sehen, wer was publiziert, und den Zugriff sauber entziehen können.
• Änderungsprozess. Neue Topics werden hinzugefügt, alte Topics mit einem Abschaltdatum als veraltet markiert, aber nie stillschweigend umbenannt.
• Beobachtbarkeit. Jemand überwacht Verbindungsstatus, Nachrichtenraten und veraltete Topics.

Das ConnectMQ-Portal unterstützt Sie bei der Beobachtbarkeit: Der Live-Topic-Explorer zeigt den Baum, während er wächst, die ISA-95-Geräteansicht zeigt, zu welchem Unternehmen, Standort, Bereich und welcher Linie jedes aktive Gerät gehört, und Schwellwert-Alarmregeln benachrichtigen Sie, wenn ein Wert ein Limit überschreitet.

Häufige Fehler beim Aufbau eines UNS

Den größeren industriellen Kontext finden Sie in unserem Leitfaden zu Industrial IoT mit MQTT.

Bauen Sie Ihren Unified Namespace auf ConnectMQ

Ein Unified Namespace braucht einen Broker, auf dessen Verfügbarkeit Sie sich verlassen können, und einen klaren Blick auf den Topic-Baum, während er wächst. ConnectMQ ist ein verwalteter MQTT-Broker mit MQTT 3.1.1 und 5.0, TLS, Retained Messages, Sparkplug-B-Dekodierung, ISA-95-Republishing und einer ISA-95-Geräteansicht. Starten Sie Ihren Pilot im kostenlosen Serverless-Plan unter app.connectmq.com, ohne Kreditkarte, und wechseln Sie zu einem kostenpflichtigen, Dedicated- oder BYOC-Plan, wenn weitere Linien hinzukommen.

Häufig gestellte Fragen

Brauche ich Sparkplug B, um einen Unified Namespace aufzubauen?

Nein. Viele Namespaces nutzen einfaches JSON über MQTT. Sparkplug B ergänzt Zustandsverwaltung und typisierte Metriken, und beides kann nebeneinander bestehen, wenn der Broker Sparkplug-Daten in lesbare Topics erneut publiziert.

Sollte der UNS-Broker On-Premises oder in der Cloud laufen?

Beides funktioniert. On-Premises hält den Datenverkehr lokal; ein verwalteter MQTT-Broker nimmt Ihnen den Betriebsaufwand ab und erleichtert den standortübergreifenden Zugriff. Viele Werke starten den Pilot mit einem verwalteten MQTT-Broker und entscheiden auf Basis ihrer Erfahrungen.

Wie groß sollte der erste UNS-Pilot sein?

Eine Linie oder ein Bereich mit einer Handvoll Maschinen und zwei oder drei Consumern reicht aus, um das Muster zu beweisen und den Namensstandard zu verfeinern.

Ersetzt ein Unified Namespace einen Historian?

Nein. Der UNS hält aktuellen Zustand und Ereignisse; ein Historian oder Data Lake abonniert ihn und speichert die langfristige Historie.