UNS-Topic-Struktur: Beispiele für Fertigungsunternehmen

Eine gute UNS-Topic-Struktur macht einen Unified Namespace (UNS) navigierbar: Wer das Werk kennt, kann erraten, wo ein Wert liegt, ohne eine Dokumentation zu öffnen. Dieser Leitfaden liefert Ihnen sofort nutzbare Topic-Bäume für Stück- und Prozessfertigung, die Namens- und Payload-Regeln, die sie sauber halten, und einen kleinen Validator, den Sie in der CI oder am Gateway ausführen können, um fehlerhafte Topics zu stoppen, bevor sie den Broker erreichen.

Die Prinzipien hinter einer UNS-Topic-Struktur

Jedes Beispiel in diesem Artikel folgt denselben fünf Prinzipien. Wenn Sie die Bäume anpassen, behalten Sie die Prinzipien bei.

1. Das Werk modellieren, nicht die Technologie. Topics beschreiben, wo sich etwas befindet und was es ist, nicht welches Protokoll oder welche SPS-Marke es erzeugt hat. opcua/ und s7/ gehören nicht in den Pfad.
2. Hierarchie zuerst, ISA-95 als Rückgrat. Unternehmen, Standort, Bereich, Linie oder Zelle und Anlage ergeben eine Struktur, die die Produktion bereits versteht: Die ISA-95-Ebenen Enterprise → Site → Area → Line → Cell (IEC 62264) werden eins zu eins zu Topic-Ebenen auf dem MQTT-Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Der Leitfaden zur ISA-95-Anlagenhierarchie erklärt jede Ebene.
3. Möglichst feste Tiefe. Wenn jede Maschine auf derselben Ebene liegt, funktionieren Wildcard-Abonnements wie +/+/+/+/telemetry im gesamten Unternehmen.
4. Eine kleine Menge an Blatttypen. Lassen Sie jeden Anlagenzweig in einer vorhersehbaren Menge von Namespaces wie telemetry, state, alarms, events und cmd enden.
5. Stabile Kennungen. Kurze, kleingeschriebene Namen mit Bindestrichen, die Umorganisationen überstehen. Anlagennummern sind oft besser als beschreibende Namen, die sich ändern.

Beispiel 1: Stückfertigung

Ein Werk der Stückfertigung mit Montagelinien, Bearbeitungszellen und gemeinsamen Versorgungsanlagen:

acme/                                     enterprise
  dallas/                                 site
    machining/                            area
      cell-03/                            work cell
        cnc-01/                           equipment
          telemetry                       {"spindle_rpm":..., "load_pct":..., "ts":...}
          state                           "running" | "idle" | "down" (retained)
          alarms                          active alarm list (retained)
          events/cycle-complete           one message per finished part
          cmd/                            commands, request/response
        robot-01/
          telemetry
          state
    assembly/
      line-02/                            production line
        station-10/
          telemetry
          events/part-scanned
        station-20/
          telemetry
      line-02/kpi/oee                     line-level calculated values
    utilities/
      compressors/
        comp-01/telemetry

Beachten Sie den Zweig kpi auf Linienebene. Berechnete Werte wie OEE oder Durchsatz gehören auf die Ebene, die sie beschreiben, und werden von der Anwendung publiziert, die sie berechnet. So bleiben Rohdaten der Maschinen und abgeleitete Daten klar getrennt und dennoch im selben Baum.

Beispiel 2: Prozessfertigung

Prozessanlagen denken in Prozesszellen und Teilanlagen statt in Linien und Stationen. ISA-95 deckt beides ab, daher ändert der Baum sein Vokabular, aber nicht seine Form:

acme/
  izmir/                                  site
    brewing/                              area
      brewhouse-1/                        process cell
        mash-tun/                         unit
          telemetry                       {"temp_c":..., "level_pct":..., "ts":...}
          state                           "heating" | "resting" | "transferring"
          batch                           current batch id and recipe (retained)
        lauter-tun/
          telemetry
      fermentation/
        fv-07/
          telemetry
          batch
    utilities/
      boiler-1/telemetry
      water-treatment/ro-1/telemetry

Das Blatt batch ist das Gegenstück zum Fertigungsauftrag in der Prozessindustrie: retained, klein und aktualisiert, sobald sich die Charge ändert. Consumer verknüpfen Chargenkontext und Telemetrie über den Topic-Pfad, ohne separate Datenbankabfrage.

Beispiel 3: Unternehmen mit mehreren Standorten und gemeinsamen Diensten

Wenn sich mehrere Standorte einen Broker oder einen per Bridge verbundenen Namespace teilen, ergänzen Sie einen Zweig auf oberster Ebene für Unternehmenssysteme, damit MES-, ERP- und Qualitätsdaten ein Zuhause haben, das nicht vorgibt, eine Anlage zu sein:

acme/dallas/...                           site trees as above
acme/izmir/...
acme/_enterprise/erp/work-orders/dallas   work orders per site (retained)
acme/_enterprise/quality/spc/dallas/line-02
acme/_enterprise/mes/schedule/izmir

Der führende Unterstrich sortiert den Zweig getrennt von den Standortnamen ein und macht deutlich, dass es sich nicht um einen physischen Ort handelt.

Wie Sparkplug B in eine UNS-Topic-Struktur passt

Sparkplug B verwendet ein eigenes festes Topic-Format, spBv1.0/<group>/<message type>/<edge node>/<device>. Dieses Format ist für das Zustandsmanagement zwischen Edge-Nodes und Host-Anwendungen optimiert, nicht für das Durchsuchen nach Anlagenhierarchie. Unser Artikel zum Sparkplug-Topic-Namespace erklärt es ausführlich.

Sie müssen sich nicht entscheiden. Ein gängiges Muster behält Sparkplug für den Verkehr zwischen Edge und Host bei und publiziert die Werte für alle anderen erneut in den ISA-95-Baum. ConnectMQ erledigt das für Sparkplug-B-Verkehr automatisch: Es dekodiert die Protobuf- oder JSON-Payload und publiziert sie in ISA-95-Topics, sodass aus spBv1.0/factory1/DDATA/line1/cnc1 das Topic connectmq/factory1/production/line1/cnc1/telemetry wird. Dashboards und Historians abonnieren lesbares JSON im ISA-95-Baum, während SCADA-Hosts weiterhin natives Sparkplug nutzen.

Namens- und Payload-Regeln

Ein führender Schrägstrich ist ein klassischer Fehler: Er erzeugt eine leere erste Ebene, sodass /acme/# und acme/# unterschiedliche Abonnements sind. Gemischte Groß- und Kleinschreibung ist ein weiterer: MQTT-Topics unterscheiden Groß- und Kleinschreibung, und Line-02 und line-02 werden zu zwei verschiedenen Zweigen, die Ihre Daten unbemerkt aufspalten.

Topics validieren, bevor sie den Broker erreichen

Das folgende Skript prüft Topics gegen die obigen Regeln und die fünfstufige Anlagenstruktur. Nutzen Sie es in einem Gateway, in einem CI-Test über Ihre Tag-Mapping-Datei oder als Monitoring-Subscriber, der Verstöße meldet.

import re

LEVEL = re.compile(r"^[a-z0-9]+(-[a-z0-9]+)*$")
LEAVES = {"telemetry", "state", "alarms", "batch", "events", "cmd", "kpi"}

def validate(topic: str, depth: int = 5) -> list[str]:
    """Return a list of problems; an empty list means the topic is valid."""
    problems = []
    if topic.startswith("/") or topic.endswith("/"):
        problems.append("leading or trailing slash")
    levels = topic.strip("/").split("/")
    if any(ch in topic for ch in "+#$"):
        problems.append("wildcard or $ character in topic name")
    if any(" " in level for level in levels):
        problems.append("space in topic level")
    if len(levels) < depth + 1:
        problems.append(f"expected at least {depth + 1} levels, got {len(levels)}")
        return problems
    for level in levels[:depth]:
        if not (LEVEL.match(level) or level.startswith("_")):
            problems.append(f"level '{level}' is not lowercase-hyphenated")
    if levels[depth] not in LEAVES:
        problems.append(f"leaf '{levels[depth]}' not in {sorted(LEAVES)}")
    return problems

if __name__ == "__main__":
    tests = [
        "acme/dallas/machining/cell-03/cnc-01/telemetry",
        "acme/dallas/machining/cell-03/CNC_01/telemetry",
        "/acme/dallas/assembly/line-02/station-10/telemetry",
        "acme/dallas/assembly/line-02/station-10/temperature",
    ]
    for t in tests:
        result = validate(t)
        print("OK  " if not result else "FAIL", t, "" if not result else result)

Führen Sie es mit python validate_topics.py aus und passen Sie LEAVES und depth an Ihren Standard an.

Die Struktur weiterentwickeln, ohne Consumer zu brechen

Keine Topic-Struktur übersteht den Kontakt mit einem echten Werk unverändert. Linien werden umgebaut, Maschinen wechseln zwischen Zellen, ein neuer Standort wird mit eigenen Namensgewohnheiten übernommen. Ziel ist nicht, Veränderung zu vermeiden, sondern sie sicher zu machen.

1. Hinzufügen, nie direkt umbenennen. Wenn sich ein Zweig ändern muss, publizieren Sie für einen festgelegten Zeitraum parallel auf den neuen und den alten Pfad und stellen den alten dann ein. Kündigen Sie das Abschaltdatum allen Verantwortlichen der Consumer an.
2. Retained Messages beim Abschalten löschen. Ein stillgelegter Zweig liefert neuen Subscribern weiterhin Retained-Werte. Publizieren Sie eine leere Retained Message auf jedes alte Zustands-Topic, um sie zu entfernen.
3. Ein Register führen. Eine einfache Datei in der Versionsverwaltung, die jeden Zweig, seinen Owner, seine Blatttypen und die Version seines Payload-Schemas auflistet, genügt. Der obige Validator kann seine Regeln aus dieser Datei lesen.
4. Payloads versionieren, nicht Topics. Fügen Sie der Payload ein Feld v hinzu, wenn sich das Schema ändert. Topics mit /v2/ im Pfad vermehren sich gern und verwirren Wildcard-Abonnements.
5. Neue Zweige prüfen. Eine kurze Prüfung durch den Namespace-Owner, bevor ein Gateway live geht, fängt die meisten Probleme ab, solange sie noch günstig zu beheben sind.

Behandeln Sie die Struktur wie eine API, von der das ganze Werk abhängt, denn genau das wird sie, sobald Dashboards, Historians und MES-Integrationen sie abonnieren.

Die Struktur auf einem Live-Broker ausprobieren

Bevor Sie eine Struktur ausrollen, publizieren Sie einige Beispielnachrichten und sehen Sie sie sich an. Auf dem öffentlichen MQTT-Broker unter broker.connectmq.com geht das ohne Konto, solange Sie ein eindeutiges Präfix verwenden und bedenken, dass dort alles für alle lesbar ist; er ist für Tests und Prototypen gedacht, nicht für Produktivdaten. Der öffentliche MQTT-Broker erlaubt 8 Topic-Ebenen, sodass connectmq/demo/<id>/ plus fünfstufiger Baum und Blatt genau passen, wenn Sie die Unternehmensebene weglassen:

mosquitto_pub -h broker.connectmq.com -p 1883 -i uns-test-pub-q7 -r \
  -t "connectmq/demo/q7w2/dallas/machining/cell-03/cnc-01/state" -m "running"

mosquitto_sub -h broker.connectmq.com -p 1883 -i uns-test-sub-q7 \
  -t "connectmq/demo/q7w2/dallas/+/+/+/state" -v

Auf einem privaten ConnectMQ-Broker können Sie den vollständigen Baum ohne Demo-Präfix nutzen, und der Live-Topic-Explorer sowie die ISA-95-Geräteansicht des Portals zeigen auf einen Blick, ob Geräte beim richtigen Unternehmen, Standort, Bereich und bei der richtigen Linie landen. Schritt-für-Schritt-Regeln zur Kodierung finden Sie unter ISA-95-MQTT-Topics, den vollständigen Aufbauprozess unter Unified Namespace aufbauen. Das Gesamtbild liefert unser Leitfaden zu Industrial IoT mit MQTT.

Bringen Sie Ihre UNS-Topic-Struktur auf ConnectMQ

Eine Topic-Struktur ist nur so gut wie der Broker, der sie trägt, und die Transparenz, die Sie darüber haben. ConnectMQ ist ein verwalteter MQTT-Broker, der ISA-95- und Unified-Namespace-Topics erkennt, Sparkplug B dekodiert und in Ihren ISA-95-Baum erneut publiziert. Erstellen Sie einen Broker im kostenlosen Serverless-Plan unter app.connectmq.com, ohne Kreditkarte, und publizieren Sie Ihren ersten Namespace-Zweig in wenigen Minuten.

Häufig gestellte Fragen

Wie viele Ebenen sollte eine UNS-Topic-Struktur haben?

Die meisten Werke verwenden fünf oder sechs: Unternehmen, Standort, Bereich, Linie oder Zelle, Anlage und ein Blatt wie telemetry oder state. Eine feste Tiefe hält Wildcard-Abonnements einfach.

Sollte jede Metrik ein eigenes Topic bekommen?

Beide Ansätze funktionieren. Ein JSON-Objekt pro Telemetrie-Topic einer Anlage ist einfacher und günstiger; ein Topic pro Metrik passt zu Tools, die Topics direkt auf Tags abbilden. Wählen Sie pro Blatttyp einen Ansatz und wenden Sie ihn konsequent an.

Wohin gehören berechnete KPIs?

Auf die Ebene, die sie beschreiben, publiziert von der Anwendung, die sie berechnet, zum Beispiel in einen Zweig kpi/oee unterhalb der Linie.

Können Sparkplug-B-Topics Teil eines UNS sein?

Ja, aber sie sind nicht nach Anlagenhierarchie organisiert. Publizieren Sie Sparkplug-Werte erneut in ISA-95-Topics, damit alle Consumer einen einzigen Baum durchsuchen können.