Sparkplug B ist eine offene Spezifikation, die auf MQTT aufsetzt und genau definiert, wie industrielle Geräte sich selbst ankündigen, ihre Daten beschreiben und signalisieren, wenn sie offline gehen, und verwandelt eine generische Nachrichtenleitung in einen selbstbeschreibenden, zustandsbewussten Telemetrie‑Standard.
Reines MQTT ist ein leichtgewichtiges Publish/Subscribe‑Transportprotokoll: Es bewegt Bytes von einem Publisher zu beliebigen Abonnenten, sagt aber nichts darüber aus, was diese Bytes bedeuten, welche Einheiten sie tragen oder ob der Sender überhaupt noch lebt. Sparkplug B schließt diese Lücke.
Unter der Eclipse Foundation geschaffen und jetzt als offener Standard gepflegt, gibt es jedem Tag einen definierten Datentyp, eine bekannte Topic‑Struktur und einen Lebenszyklus, sodass jeder Konsument, vom OEE‑Dashboard bis zum Historian, eine Payload interpretieren kann, ohne eine handgefertigte Integrationskarte.
MQTT wurde für eingeschränkte, unzuverlässige Netze entwickelt, weshalb es gerade in der Fertigung so gut funktioniert. Aber im Auslieferungszustand lässt es drei harte Probleme ungelöst. Erstens sind Topic‑Namespaces ein Freifeld: Ein Integrator publiziert auf plant1/line3/oven/temp , ein anderer auf Oven_Temp_C , und nichts erzwingt Konsistenz.
Zweitens sind Payloads undurchsichtig; ein Wert von „72“ könnte Celsius, Fahrenheit oder ein Fehlercode sein, und der Abonnent hat keine Möglichkeit, das zu wissen. Drittens kennt MQTT kein eingebautes Frische‑Konzept.
Wenn ein Gateway Strom verliert, bleibt sein zuletzt publizierter Wert auf dem Broker stehen, und ein Dashboard zeigt weiterhin einen veralteten Messwert, als würde die Maschine problemlos laufen.
Auf dem Fabrikboden sind diese Lücken nicht akademisch. Veraltete oder falsch bezeichnete Daten verfälschen Verfügbarkeits‑ und Leistungsberechnungen, weshalb Teams, die sich um Overall Equipment Effectiveness kümmern, sich nicht auf rohes MQTT allein verlassen können. Sparkplug B wurde speziell geschrieben, um diese Löcher für die Betriebstechnik zu schließen.
Das charakteristische Merkmal von Sparkplug B ist der Zertifikats‑Lebenszyklus. Wenn ein Edge‑Node oder Gerät verbindet, veröffentlicht es eine Geburtsurkunde (ein NBIRTH für einen Node, ein DBIRTH für ein Gerät). Diese Nachricht ist nicht nur ein Hallo.
Sie enthält die vollständige Liste aller Metriken, die das Gerät jemals veröffentlichen wird, jede mit ihrem Namen, Datentyp und Anfangswert. Ein Abonnent, der die Geburtsurkunde erhält, kennt sofort das gesamte Schema, ganz ohne externe Konfigurationsdatei.
Die Todesurkunde ist das Spiegelbild. Jeder Sparkplug‑Client registriert beim Verbinden einen Last Will and Testament beim Broker. Wenn das Gerät unkontrolliert vom Netz verschwindet, veröffentlicht der Broker selbst das zuvor registrierte NDEATH stellvertretend für das Gerät.
Verbraucher erfahren sofort, dass die Quelle offline ist, und können deren Daten als veraltet kennzeichnen, anstatt einem eingefrorenen letzten Wert zu vertrauen.
Das ist echtes Zustandsbewusstsein: Das System unterscheidet zwischen „der Wert ist tatsächlich stabil“ und „der Sender ist verschwunden.“ Für alle, die Zuverlässigkeitskennzahlen wie MTBF und MTTR berechnen, bedeutet die Unterscheidung zwischen einem echten Stillstand und einem Kommunikationsausfall den Unterschied zwischen einer vertrauenswürdigen Zahl und einer fiktiven.
Sparkplug‑B‑Payloads werden mit Google Protocol Buffers codiert, einem kompakten Binärformat. Jede Payload enthält einen Zeitstempel, eine Sequenznummer und ein Array von Metriken. Eine Metrik ist ein benanntes, getyptes Objekt, sodass eine Temperaturmessung als strukturierte Einheit mit einem expliziten Int‑, Float‑ oder Boolean‑Typ übertragen wird, statt als mehrdeutiger String.
Der Topic‑Namespace ist ebenso diszipliniert. Jedes Sparkplug‑Topic folgt dem festen Muster spBv1.0/group_id/message_type/edge_node_id/device_id . Weil die Struktur standardisiert ist, kann jedes Tool mit einem einzigen Wildcard abonnieren und automatisch jede Gruppe, jeden Node und jedes Gerät im Netzwerk entdecken.
Dieses Report‑by‑exception‑Modell ist ebenfalls wichtig: Nach der Geburtsurkunde publizieren Geräte nur Werte, die sich geändert haben (NDATA‑ und DDATA‑Nachrichten), was die Bandbreite auf den in Anlagen üblichen eingeschränkten Verbindungen drastisch reduziert.
Die selbstbeschreibende Natur sorgt dafür, dass die Datenbasis sauber genug bleibt, um nachgelagerte Analysen zu speisen, von Statistical Process Control ‑Diagrammen bis hin zu Pareto‑Analysen der Ausfallursachen.
Betrachten Sie eine Abfülllinie mit 40 Sensoren, die jeweils einen Gleitkommawert melden. Bei einem naiven Polling‑Schema würden Sie vielleicht alle 40 Werte jede Sekunde veröffentlichen: 40 Nachrichten pro Sekunde bzw. 3.456.000 Nachrichten pro Tag.
Mit Sparkplug B Report‑by‑Exception nehmen wir an, dass in einer Sekunde nur 5 der 40 Metriken tatsächlich ändern (Temperaturen driftet langsam, die meisten Zustände sind stabil). Das sind grob 5 DDATA‑Nachrichten pro Sekunde plus eine Geburtsurkunde beim Start: etwa 432.000 Nachrichten pro Tag, eine Reduktion des Nachrichtenvolumens um rund 87 Prozent. Auf einer zellularen oder gemeinsamen Anlagen‑Leitung ist das der Unterschied zwischen einer gesättigten Leitung und ausreichend Freiraum.
Nun die OEE‑Auszahlung. Angenommen, die Todes‑ und Geburtsurkunden der Linie zeigen, dass sie während einer 480‑minütigen Schicht tatsächlich 400 Minuten verbunden und in Betrieb war. Die Verfügbarkeit beträgt 400 / 480 = 83,3 Prozent .
Die Zählermetriken melden 9.000 Einheiten gegenüber einer Idealrate von 25 Einheiten pro Minute über diese 400 Minuten (10.000 ideal), damit ist die Performance 9.000 / 10.000 = 90 Prozent . Qualitätsmetriken zeigen 8.730 gute Einheiten, also ist die Qualität 8.730 / 9.000 = 97 Prozent .
Multipliziert ergibt das: 0,833 x 0,90 x 0,97 = 72,7 Prozent OEE . Jeder Input in dieser Berechnung stammte aus selbstbeschreibenden, zustandsbewussten Sparkplug‑Metriken, ohne Rätselraten darüber, ob ein Ausfall echten Stillstand oder ein veralteter Messwert war.
Sparkplug B wird oft mit einer einheitlichen Namespace‑Architektur kombiniert, in der ein einzelner Broker die Echtzeit‑Quelle der Wahrheit wird und jede Anwendung sowohl publiziert als auch konsumiert.
Es ergänzt bestehende Systeme, ersetzt sie nicht: Daten können von SPSen, aus SCADA -Schichten oder von unabhängigen Edge‑Gateways stammen und dann in ein CMMS für Wartungsauslöser oder in Monitoring‑Dashboards für Live‑Produktionssichtbarkeit fließen.
Da das Format offen und selbstbeschreibend ist, bildet es auch die Grundlage für zustandsbasierte Wartungsstrategien , die auf kontinuierliche, vertrauenswürdige Sensorströme statt auf periodische manuelle Prüfungen angewiesen sind.
Fabrico ist die Echtzeit‑Datenbasis, die saubere Shop‑Floor‑Telemetrie in Handlungen verwandelt. Es liefert Echtzeit‑OEE und Produktionsüberwachung sowie ein feldbereites CMMS mit Arbeitsaufträgen, Anlagenverwaltung, vorbeugender Planung und Ersatzteilmanagement, alles EU‑entwickelt mit EU‑Datenresidenz.
Wo eine Maschine keine SPS oder keinen zugänglichen Netz‑Tag hat, um einen Sparkplug‑Stream zu speisen, liest Fabricos Computer Vision die Ausrüstung direkt, sodass selbst Legacy‑Anlagen zu Ihren Verfügbarkeits‑ und Leistungskennzahlen beitragen.
Die zustandsbewusste, selbstbeschreibende Philosophie hinter Sparkplug B ist genau die Disziplin, die Fabrico auf OEE‑Daten anwendet: Wissen, was jedes Signal bedeutet, und wissen, wann man ihm vertrauen kann, bevor es jemals in einen Bericht gelangt.
Nein. Sparkplug B läuft auf Standard‑MQTT und nutzt einen konformen Broker. Es fügt einen definierten Topic‑Namespace, ein Protocol‑Buffers‑Payload‑Format und den Geburts/Todes‑Zertifikats‑Lebenszyklus hinzu. Sie benötigen weiterhin einen MQTT‑Broker darunter; Sparkplug B ist die Konventionsschicht, die die Nachrichten interoperabel und selbstbeschreibend macht.
Eine Geburtsurkunde (NBIRTH oder DBIRTH) wird einmalig beim Verbinden eines Geräts veröffentlicht und enthält das komplette Schema: jeden Metriknamen, Datentyp und Anfangswert. Normale Daten‑Nachrichten (NDATA oder DDATA) werden danach ausnahmsweise veröffentlicht und enthalten nur die Werte, die sich geändert haben. Konsumenten nutzen die Geburtsurkunde, um jede nachfolgende Daten‑Nachricht ohne externe Zuordnung zu interpretieren.
Indirekt, aber signifikant. Durch die explizite Zustandsdarstellung mittels Todesurkunden können Systeme einen echten stabilen Wert von einem offline‑Sensor unterscheiden, was verhindert, dass veraltete Messwerte die Verfügbarkeit hochziehen. Durch das Typisieren jeder Metrik beseitigt es Einheiten‑ und Format‑Ambiguitäten in den Performance‑ und Qualitätsdaten. Sauberere, zustandsbewusste Eingabedaten bedeuten, dass die berechnete OEE die Realität widerspiegelt.
Möchten Sie sehen, wie selbstbeschreibende, zustandsbewusste Telemetrie echte OEE‑Werte ohne kundenspezifische Integration für jede Maschine antreibt? Buchen Sie eine Fabrico‑Demo und sehen Sie zu, wie Ihre echten Produktionsdaten zu einer vertrauenswürdigen Grundlage werden.
Anmeldung
Blog
