Sparkplug B is an open specification that sits on top of MQTT and defines exactly how industrial devices announce themselves, describe their data, and signal when they go offline, turning a generic message pipe into a self-describing, stateful telemetry standard. Plain MQTT is a lightweight publish/subscribe transport: it moves bytes from a publisher to any subscriber, but it says nothing about what those bytes mean, what units they carry, or whether the sender is even still alive. Sparkplug B fills that gap. Created under the Eclipse Foundation and now maintained as an open standard, it gives every tag a defined data type, a known topic structure, and a lifecycle so that any consumer, from an OEE dashboard to a historian, can interpret a payload without a hand-built integration map.
MQTT was designed for constrained, unreliable networks, which is exactly why it thrives in manufacturing. But out of the box it leaves three hard problems unsolved. First, topic namespaces are a free-for-all: one integrator publishes to plant1/line3/oven/temp, another to Oven_Temp_C, and nothing enforces consistency. Second, payloads are opaque; a value of "72" could be Celsius, Fahrenheit, or a fault code, and the subscriber has no way to know. Third, MQTT has no built-in concept of freshness. If a gateway loses power, its last published value lingers on the broker, and a dashboard keeps showing a stale reading as if the machine were running fine.
On a factory floor these gaps are not academic. Stale or mislabeled data corrupts availability and performance calculations, which is why teams that care about overall equipment effectiveness cannot rely on raw MQTT alone. Sparkplug B was written specifically to close these holes for operational technology.
The signature feature of Sparkplug B is the certificate lifecycle. When an edge node or device connects, it publishes a birth certificate (an NBIRTH for a node, a DBIRTH for a device). This message is not just a hello. It contains the full list of every metric the device will ever publish, each with its name, data type, and initial value. A subscriber that receives the birth certificate immediately knows the entire schema, no external configuration file required.
The death certificate is the mirror image. Every Sparkplug client registers a Last Will and Testament with the broker at connect time. If the device drops off the network ungracefully, the broker itself publishes the pre-registered NDEATH on the device's behalf. Consumers instantly learn the source is offline and can mark its data as stale rather than trusting a frozen last value. This is genuine state awareness: the system knows the difference between "the value is legitimately steady" and "the sender is gone." For anyone computing reliability metrics like MTBF and MTTR, distinguishing a real stop from a communications dropout is the difference between a trustworthy number and a fictional one.
Sparkplug B payloads are encoded with Google Protocol Buffers, a compact binary format. Each payload carries a timestamp, a sequence number, and an array of metrics. A metric is a named, typed object, so a temperature reading travels as a structured unit with an explicit Int, Float, or Boolean type rather than an ambiguous string.
The topic namespace is equally disciplined. Every Sparkplug topic follows the fixed pattern spBv1.0/group_id/message_type/edge_node_id/device_id. Because the structure is standardized, any tool can subscribe with a single wildcard and automatically discover every group, node, and device on the network. This report-by-exception model also matters: after the birth certificate, devices publish only values that have changed (NDATA and DDATA messages), which slashes bandwidth on the constrained links common in plants. The self-describing nature means the data foundation stays clean enough to feed downstream analysis, from statistical process control charts to Pareto analysis of downtime causes.
Consider a bottling line with 40 sensors, each reporting a floating-point value. Under a naive polling scheme you might publish all 40 values every second: 40 messages per second, or 3,456,000 messages per day.
With Sparkplug B report-by-exception, assume only 5 of the 40 metrics actually change in any given second (temperature drifts slowly, most states are steady). That is roughly 5 DDATA messages per second plus one birth certificate at startup: about 432,000 messages per day, a reduction of around 87 percent in message volume. On a cellular or shared plant link, that is the difference between a saturated pipe and headroom to spare.
Now the OEE payoff. Say the line's death and birth certificates show it was truly connected and running for 400 minutes out of a 480-minute shift. Availability is 400 / 480 = 83.3 percent. The counter metrics report 9,000 units against an ideal rate of 25 units per minute over those 400 minutes (10,000 ideal), so performance is 9,000 / 10,000 = 90 percent. Quality metrics show 8,730 good units, so quality is 8,730 / 9,000 = 97 percent. Multiply them: 0.833 x 0.90 x 0.97 = 72.7 percent OEE. Every input in that calculation came from self-describing, state-aware Sparkplug metrics, with no guesswork about whether a dropout was real downtime or a stale reading.
Sparkplug B is often paired with a unified namespace architecture, where a single broker becomes the real-time source of truth and every application both publishes to and consumes from it. It complements rather than replaces existing systems: data can originate from PLCs, from SCADA layers, or from independent edge gateways, then flow into a CMMS for maintenance triggers or into monitoring dashboards for live production visibility. Because the format is open and self-describing, it also underpins condition-based maintenance strategies that depend on continuous, trustworthy sensor streams rather than periodic manual checks.
Fabrico is the real-time data foundation that turns clean shop-floor telemetry into action. It delivers real-time OEE and production monitoring, and a field-ready CMMS with work orders, assets, preventive scheduling, and spare-parts management, all EU-built with EU data residency. Where a machine has no PLC or accessible network tag to feed a Sparkplug stream, Fabrico's computer vision reads the equipment directly, so even legacy assets contribute to your availability and performance numbers. The state-aware, self-describing philosophy behind Sparkplug B is exactly the discipline Fabrico applies to OEE data: know what each signal means, and know when it can be trusted, before it ever reaches a report.
No. Sparkplug B runs on top of standard MQTT and uses a compliant broker. It adds a defined topic namespace, a Protocol Buffers payload format, and the birth/death certificate lifecycle. You still need an MQTT broker underneath; Sparkplug B is the convention layer that makes the messages interoperable and self-describing.
A birth certificate (NBIRTH or DBIRTH) is published once when a device connects and contains the complete schema: every metric name, data type, and initial value. Normal data messages (NDATA or DDATA) are published afterward by exception and carry only the values that have changed. Consumers use the birth certificate to interpret every subsequent data message without any external mapping.
Indirectly but significantly. By making state explicit through death certificates, it lets systems distinguish a genuine steady value from an offline sensor, which prevents stale readings from inflating availability. By typing every metric, it removes unit and format ambiguity from the performance and quality inputs. Cleaner, state-aware inputs mean the OEE figure you calculate reflects reality.
Want to see self-describing, state-aware telemetry drive live OEE without a custom integration for every machine? Book a Fabrico demo and watch your real production data become a trustworthy foundation.
Login
Blog