Sparkplug Metrik-Aliase: Bandbreite in DATA sparen

Mit Sparkplug Metrik-Aliasen kann ein Edge Node lange Metriknamen wie Line2/Filler/Motor/CurrentAmps in jeder DATA-Nachricht durch eine kleine Ganzzahl ersetzen. In diesem Leitfaden erfahren Sie, wie die Alias-Zuordnung zwischen BIRTH- und DATA-Nachrichten funktioniert, wann Aliase die zusätzliche Komplexität wert sind und wie Sie Alias-Abweichungen finden und beheben, wenn dekodierte Werte plötzlich falsch aussehen.

Warum Metriknamen teuer sind

Sparkplug B Payloads sind Protobuf und damit bereits kompakt. Zahlen werden als Varint kodiert, Zeitstempel sind 64-Bit-Ganzzahlen, und es gibt keine JSON-Satzzeichen. Der einzige Teil eines Payloads, den Protobuf nicht verkleinern kann, ist ein String, und Metriknamen sind Strings.

Industrielle Namenskonventionen machen diese Strings lang. Ein Tag-Pfad, der aus dem Tag-Browser einer SPS oder eines SCADA-Systems kopiert wurde, enthält oft Bereich, Maschine, Subsystem und Signal: Packaging/Line2/Filler/Infeed/Motor1/Current. Meldet eine DDATA-Nachricht einen einzigen geänderten Wert, kann dieser 45 Zeichen lange Name um ein Mehrfaches größer sein als Wert und Zeitstempel zusammen.

In einem kabelgebundenen Werksnetz spielt das selten eine Rolle. Über Mobilfunk, Satellit, lizenzierten Funk oder ausgelastete geteilte Netze spielt es eine große Rolle, etwa bei verteilten Pumpstationen der Wasserversorgung oder bei Maschinen, die ein Maschinenbauer beim Kunden per Mobilfunk anbindet. Jedes Byte kostet, entweder Geld oder Latenz. Sparkplug Metrik-Aliase sind die Antwort der Spezifikation: den Namen einmal senden und danach per Nummer darauf verweisen.

Wie Sparkplug Metrik-Aliase funktionieren

Der Mechanismus folgt drei Regeln.

Im NBIRTH (für Metriken auf Node-Ebene) oder DBIRTH (für Device-Metriken) wird jede Metrik sowohl mit ihrem name als auch mit einem alias gesendet, einer vorzeichenlosen 64-Bit-Ganzzahl.
In den folgenden NDATA-, DDATA-, NCMD- und DCMD-Nachrichten wird die Metrik nur mit dem alias gesendet. Das Feld name entfällt.
Aliase müssen innerhalb eines Edge Nodes eindeutig sein. Zwei Metriken desselben Edge Nodes dürfen sich keinen Alias teilen, selbst wenn sie zu verschiedenen Devices gehören.

Eine Primary Host Application oder ein anderer Konsument baut beim Empfang des BIRTH eine Zuordnungstabelle auf. Ab dann wird jede DATA-Metrik, die mit einem Alias eintrifft, über diese Tabelle wieder ihrem vollständigen Namen zugeordnet.

Hier dieselbe Metrik in beiden Nachrichtentypen, dargestellt als dekodierte Protobuf-Struktur:

DBIRTH  spBv1.0/plant1/DBIRTH/edge-07/filler-02
  metric { name: "Infeed/Motor1/Current"  alias: 12  datatype: Float  float_value: 4.81 }
  metric { name: "Infeed/Motor1/Running"  alias: 13  datatype: Boolean  boolean_value: true }

DDATA   spBv1.0/plant1/DDATA/edge-07/filler-02
  metric { alias: 12  datatype: Float  float_value: 4.93  timestamp: 1792137600123 }

Die DDATA-Metrik enthält überhaupt keinen Namen. Ohne das DBIRTH hat ein Konsument einen Float-Wert und die Zahl 12, sonst nichts.

Was Aliase nicht ändern

Aliase ersetzen nur den Namen. Datentyp, Wert, Zeitstempel, Quality-Properties und Metadaten funktionieren genau wie zuvor. Auch die Topics bleiben gleich: Aliase haben nichts mit den Topic-Aliasen von MQTT 5 zu tun, die den Topic-String auf Protokollebene verkürzen. Beides kann nebeneinander existieren, es handelt sich aber um unabhängige Funktionen aus verschiedenen Spezifikationen. Die Variante auf MQTT-Ebene beschreibt der Abschnitt zu Topic-Aliasen in unserem Leitfaden zu den MQTT-5-Funktionen.

Namen oder Aliase: die Abwägung

Aspekt	Namen in jeder DATA-Nachricht	Sparkplug Metrik-Aliase
Payload-Größe	Wächst mit der Namenslänge	Klein und pro Metrik etwa konstant
Debugbarkeit	Jede mitgeschnittene Nachricht ist selbstbeschreibend	DATA ist ohne das zugehörige BIRTH bedeutungslos
Spät verbundene Subscriber	Können sofort dekodieren	Müssen auf ein Rebirth warten oder es anfordern
Komplexität beim Konsumenten	Gering	Muss pro Edge Node eine Alias-Tabelle pflegen
Risiko stiller Fehler	Gering	Eine veraltete Tabelle ordnet Werte der falschen Metrik zu
Am besten geeignet für	Kabelgebundenes LAN, wenige Tags	Volumenbasierte oder eingeschränkte Verbindungen, viele Tags

Entscheidend ist die Zeile zum Risiko. Ein falscher Name fällt sofort auf. Ein falscher Alias nicht: Der Konsument schreibt fröhlich einen Motorstrom in ein Temperatur-Tag, und die Zahl wirkt plausibel.

Der Alias-Lebenszyklus in der Praxis

Aliase gelten nur für die Lebensdauer eines einzelnen BIRTH. Wer versteht, wann diese Lebensdauer endet, vermeidet die meisten Fehler.

NBIRTH setzt alles zurück. Veröffentlicht ein Edge Node ein neues NBIRTH, wird jede Alias-Tabelle dieses Nodes verworfen und aus dem neuen NBIRTH und den folgenden DBIRTHs neu aufgebaut. Ein Edge Node darf nach einem Rebirth andere Alias-Nummern vergeben, daher darf ein Konsument Aliase niemals über Births hinweg zwischenspeichern.
NDEATH macht die Tabelle ungültig. Veröffentlicht der Broker die NDEATH-Will-Nachricht des Edge Nodes, sollten Konsumenten die Metriken des Nodes als veraltet markieren und der Alias-Tabelle bis zum nächsten NBIRTH nicht mehr vertrauen.
DBIRTH kann Device-Metriken hinzufügen. Ein Device kann einzeln ein neues Birth senden, und die Aliase seiner Metriken müssen trotzdem im gesamten Edge Node eindeutig sein.
Rebirth-Anforderungen stellen verlorenen Zustand wieder her. Ein Host, der einen unbekannten Alias sieht, sollte eine NCMD mit der auf true gesetzten Metrik Node Control/Rebirth senden, statt zu raten. Unser Artikel zum Sparkplug Rebirth beschreibt diesen Ablauf ausführlich.

Auch die Sequenznummer hilft. Jede Sparkplug-Nachricht eines Edge Nodes trägt ein seq von 0 bis 255, das danach wieder bei 0 beginnt. Sieht ein Konsument eine Lücke, hat er möglicherweise ein BIRTH verpasst und sollte ein Rebirth anfordern, bevor er Aliasen wieder vertraut. Die Regeln für BIRTH- und DEATH-Nachrichten erklärt Sparkplug Birth- und Death-Zertifikate.

Daten mit Aliasen in Python dekodieren

Das folgende Skript abonniert den gesamten Sparkplug-Verkehr einer Gruppe, baut Alias-Tabellen aus NBIRTH- und DBIRTH-Nachrichten auf und ordnet DATA-Metriken wieder ihren Namen zu. Es nutzt sparkplug_b_pb2.py, das generierte Protobuf-Modul aus dem Eclipse-Tahu-Projekt; kopieren Sie es neben das Skript und installieren Sie die Abhängigkeiten mit pip install paho-mqtt protobuf.

import paho.mqtt.client as mqtt
import sparkplug_b_pb2

BROKER = "broker.connectmq.com"
GROUP = "demo-7f3k2"          # auf dem öffentlichen Broker eine eigene, eindeutige Group ID verwenden
alias_tables = {}             # edge_node_id -> {alias: name}

def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.subscribe(f"spBv1.0/{GROUP}/#", qos=0)

def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    if len(parts) < 4:
        return
    msg_type, edge_node = parts[2], parts[3]
    device = parts[4] if len(parts) > 4 else None

    payload = sparkplug_b_pb2.Payload()
    payload.ParseFromString(msg.payload)

    if msg_type == "NBIRTH":
        alias_tables[edge_node] = {}          # ein neues NBIRTH setzt alle Aliase zurück
    if msg_type in ("NBIRTH", "DBIRTH"):
        table = alias_tables.setdefault(edge_node, {})
        for m in payload.metrics:
            if m.HasField("alias"):
                if m.alias in table and table[m.alias] != m.name:
                    print(f"WARNING duplicate alias {m.alias} on {edge_node}")
                table[m.alias] = m.name
        print(f"{msg_type} {edge_node}/{device or ''}: {len(alias_tables[edge_node])} aliases")
        return

    if msg_type == "NDEATH":
        alias_tables.pop(edge_node, None)
        print(f"NDEATH {edge_node}: alias table cleared")
        return

    if msg_type in ("NDATA", "DDATA"):
        table = alias_tables.get(edge_node)
        for m in payload.metrics:
            name = m.name
            if not name and m.HasField("alias"):
                if table is None or m.alias not in table:
                    print(f"UNKNOWN alias {m.alias} from {edge_node}, request a rebirth")
                    continue
                name = table[m.alias]
            value = getattr(m, m.WhichOneof("value")) if m.WhichOneof("value") else None
            print(f"{edge_node}/{device or ''} {name} = {value} (seq {payload.seq})")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="alias-decoder-7f3k2")
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.loop_forever()

Um Testverkehr mit Aliasen zu erzeugen, kombinieren Sie das Skript mit dem Publisher aus unserem Tutorial zum Sparkplug B Edge-Node-Simulator. Beide Skripte funktionieren mit dem kostenlosen öffentlichen MQTT-Broker unter broker.connectmq.com. Denken Sie daran, dass der öffentliche MQTT-Broker für Tests und Prototypen gedacht und für jeden lesbar ist: Verwenden Sie eine zufällige Group ID und veröffentlichen Sie dort niemals echte Anlagendaten.

Alias-Abweichungen debuggen

Die meisten Alias-Probleme folgen einer Handvoll Muster. Nutzen Sie diese Checkliste, wenn dekodierte Werte falsch aussehen.

Konsument nach dem BIRTH gestartet. BIRTH-Nachrichten sind in Sparkplug nicht retained, ein später verbundener Konsument sieht also nur DATA mit Aliasen. Die Lösung ist eine Rebirth-Anforderung oder eine Primary Host Application, die Rebirths automatisch auslöst.
Veralteter Cache nach einem Rebirth. Behält ein Konsument nach einem neuen NBIRTH seine alte Tabelle, landen Werte unter falschen Namen. Setzen Sie bei jedem NBIRTH zurück, wie es das obige Skript tut.
Doppelte Aliase über Devices hinweg. Manche Edge-Konfigurationen nummerieren Aliase pro Device ab 1. Dann beanspruchen zwei Devices beide Alias 1, was die Eindeutigkeitsregel verletzt und jeden Konsumenten durcheinanderbringt, der Tabellen nach Edge Node schlüsselt.
Alias null als fehlend gewertet. In Protobuf kann ein Feld mit seinem Standardwert je nach Prüfung im Code nicht von einem fehlenden Feld unterscheidbar sein. Wer Aliase bei 1 beginnen lässt, vermeidet eine ganze Fehlerklasse.
Namen und Aliase gemischt. Eine DATA-Metrik darf zulässigerweise Name und Alias enthalten. Konsumenten sollten den Namen bevorzugen, wenn er vorhanden ist, und Edge Nodes sollten konsistent sein.
Mehrere Publisher mit derselben Edge Node ID. Zwei Gateways mit derselben Gruppe und Edge Node ID überschreiben gegenseitig ihre Births. Das Symptom sind Aliase, deren Bedeutung hin und her springt.

Eine visuelle Prüfung beschleunigt das. ConnectMQ dekodiert Sparkplug B Payloads, ob Protobuf oder JSON, sodass Sie im Live-Topic-Explorer des Portals BIRTH- und DATA-Nachrichten nebeneinander öffnen und prüfen können, ob Alias 12 wirklich die erwartete Metrik ist. ConnectMQ kann Sparkplug-B-Daten außerdem in lesbare ISA-95-Topics erneut veröffentlichen, etwa spBv1.0/factory1/DDATA/line1/cnc1 nach connectmq/factory1/production/line1/cnc1/telemetry. Damit erhalten Konsumenten ohne Sparkplug-Unterstützung einen Weg, der überhaupt nicht von Alias-Tabellen abhängt.

Genau das ist die Idee eines Unified Namespace (UNS): Die ISA-95-Equipment-Hierarchie (Enterprise → Site → Area → Line → Cell) wird zur Topic-Struktur auf dem MQTT-Broker, etwa acme/werk-stuttgart/verpackung/linie-2/abfueller-02/motorstrom. Aliase bleiben ein Optimierungsdetail an der Edge, während MES, ERP und Dashboards im UNS mit vollständigen, lesbaren Namen arbeiten. Mehr dazu im Artikel Sparkplug B und Unified Namespace.

Wann sollten Sie Aliase aktivieren?

Aliase sind optional. Aktivieren Sie sie, wenn die Verbindung zwischen Edge und Broker volumenbasiert abgerechnet oder eingeschränkt ist, wenn viele Tags lange Namen haben oder wenn ein einzelnes Gateway viele Metriken mit hoher Rate veröffentlicht. Bleiben Sie bei reinen Namen, wenn Sie Prototypen bauen, wenn viele schlanke Konsumenten ohne Primary Host direkt abonnieren oder wenn Debugbarkeit wichtiger ist als Bytes.

Für viele Teams funktioniert ein Mittelweg gut: mit Namen entwickeln und in Betrieb nehmen, Payload-Größen unter realistischer Last messen und Aliase nur an den Standorten einschalten, deren Verbindungen es erfordern. Da Aliase vollständig im BIRTH ausgehandelt werden, brauchen Konsumenten, die die Zuordnung korrekt implementieren, keine Konfigurationsänderung, wenn Sie den Schalter umlegen.

Wo Sparkplug in eine Anlagenarchitektur passt, zeigt unser Leitfaden zu Industrial IoT mit MQTT, und der Artikel zum Sparkplug B Payload erklärt jedes Feld aus der dekodierten Ausgabe oben. Die maßgebliche Definition des Alias-Verhaltens ist die Eclipse-Sparkplug-Spezifikation.

Sparkplug-Aliase auf ConnectMQ testen

Edge Nodes und Host-Anwendungen gegen einen Broker zu betreiben, den Sie selbst kontrollieren, ist der schnellste Weg, die Alias-Behandlung vor dem Produktivbetrieb zu validieren. ConnectMQ ist ein verwalteter MQTT-Broker mit MQTT 3.1.1 und 5.0, TLS auf Port 8883 und integrierter Sparkplug-B-Dekodierung im Portal. Erstellen Sie unter app.connectmq.com einen Broker im kostenlosen Serverless-Plan, ganz ohne Kreditkarte, und richten Sie Ihren Edge Node mit dem generierten Benutzernamen, Passwort und der Client ID darauf aus.

Häufig gestellte Fragen

Sind Sparkplug Metrik-Aliase Pflicht?

Nein. Aliase sind in Sparkplug B optional. Ein Edge Node kann in jeder DATA-Nachricht vollständige Metriknamen senden, und Konsumenten müssen beide Formen beherrschen.

Können sich Alias-Nummern zwischen Births ändern?

Ja. Aliase gelten nur bis zum nächsten NBIRTH dieses Edge Nodes. Konsumenten müssen ihre Tabellen bei jedem NBIRTH neu aufbauen und Aliase niemals über Sessions hinweg speichern.

Was sollte ein Host mit einem unbekannten Alias tun?

Er sollte nicht raten. Die korrekte Reaktion ist eine NCMD mit Node Control/Rebirth auf true, damit der Edge Node seine BIRTH-Nachrichten und damit die vollständige Alias-Zuordnung erneut veröffentlicht.

Sind Sparkplug-Aliase dasselbe wie MQTT-5-Topic-Aliase?

Nein. Sparkplug Metrik-Aliase ersetzen Metriknamen im Payload, MQTT-5-Topic-Aliase ersetzen den Topic-String auf Protokollebene. Beide sind unabhängig voneinander und können gemeinsam genutzt werden.

Sparkplug Metrik-Aliase: Bandbreite in DATA-Nachrichten sparen