mqtt sparkplug as a standard
Evaluating Vanilla MQTT vs. Sparkplug B for Enterprise Unified Namespace (UNS) Architectures
Build Your Solution
Want to historize from an MQTT Sparkplug broker or transform data into Sparkplug payloads?
using mqtt sparkplug with timebase
Sparkplug Is How Manufacturing Data gains real power
The MQTT specification deliberately defines no topic structure, no payload format, and no convention for knowing whether a device is actually online. That flexibility is why MQTT spread across every industry. It is also why two MQTT deployments in the same company rarely interoperate. One team encodes context in topic strings, another buries it in JSON, a third invents its own heartbeat scheme, and every consumer has to be hand-built against every publisher's private conventions. You end up with a broker in the middle of the same integration mess you were trying to escape.
Sparkplug exists to close those gaps. It is an open specification, stewarded by the Eclipse Foundation, that defines three things on top of standard MQTT: a topic namespace, a state management model, and a typed payload format. Nothing about the broker changes. What changes is that every participant now speaks the same language, and that turns a message pipe into an interoperable industrial data infrastructure.
Flow Software and our Timebase and Infohub product offerings have been part of that story for years. We are a member of the Eclipse Sparkplug Working Group, sitting alongside companies like Chevron, Inductive Automation, Cirrus Link, HiveMQ, Opto 22, Autosol, and others to steward the specification itself, and our products are certified through the Eclipse Sparkplug Compatibility Program. We did not adopt Sparkplug because it was fashionable. We adopted it because we build data infrastructure for manufacturers, and Sparkplug is the most credible open answer to problems we watch customers fight every day.
What Sparkplug adds that vanilla MQTT cannot
spBv1.0/group_id/message_type/edge_node_id/device_id. That single convention means any compliant application can discover what exists in the infrastructure without a mapping document, a tribal briefing, or a phone call to the integrator who left last year. Subscribe to the namespace and the system describes itself.State you can trust. This is the part most vanilla MQTT deployments get wrong, and it matters enormously in operations. Sparkplug uses MQTT's native Will Message mechanism to guarantee that every Edge Node registers a Death Certificate the moment it connects. When the node publishes its Birth Certificate, the two are linked by a birth/death sequence number. If the connection drops, even ungracefully, the broker delivers the death message on the node's behalf, and every subscriber knows immediately that the data from that node is stale rather than current. A SCADA host, a historian, or an analytics engine never has to guess whether silence means "nothing changed" or "the cellular link died an hour ago." In a control environment, that distinction is the difference between data you can act on and data you merely hope is right.
Payloads with types, not guesses. Sparkplug B payloads are Google Protocol Buffer encoded, compact on the wire, and strongly typed. Every metric carries a name, a datatype, a UTC timestamp, and optionally engineering properties, quality codes, and metadata. Birth messages must declare every metric a node will ever publish, so consumers build their full data structure the moment a device comes online. Aliases let subsequent messages drop the metric name entirely to save bandwidth. Templates support user-defined types, so a "Filler" or a "CIP Circuit" can be defined once and instantiated everywhere. None of this exists in raw MQTT, where a payload is just bytes and every consumer writes its own parser.
Report by Exception that actually works. Because Sparkplug sessions are stateful, nodes only publish when values change. There is no polling, no periodic re-broadcast of unchanged data, and sequence numbers on every message let consumers detect a gap and request a rebirth. The result is dramatically less network traffic carrying dramatically more trustworthy data. This is what MQTT was originally designed for in SCADA over satellite links; Sparkplug is the specification that makes the pattern reliable enough to standardize on.
Redundancy built into the protocol. Sparkplug's STATE mechanism lets Edge Nodes track whether their Primary Host Application is online, and walk to the next broker in a multi-server deployment if it is not. High availability stops being a bespoke engineering project and becomes protocol behavior.The specification is also more than a document. Eclipse publishes a Technology Compatibility Kit, maintains the open source Tahu reference implementation, and runs a formal compatibility program so that "Sparkplug compatible" is a tested claim rather than a marketing one. That governance is why Sparkplug has become the acknowledged convention for industrial MQTT rather than one more vendor dialect.
The architecture this makes possible
Put Sparkplug at the center and the manufacturer's architecture changes shape. Devices and edge gateways publish once, to the broker, in a form every consumer understands. OT and IT decouple cleanly: the SCADA host, the historian, the analytics platform, and the enterprise consumers all subscribe to the same namespace without touching the PLC network or each other. Adding a consumer stops being an integration project. Access control lists on the broker restrict each node to its own topics, so a compromised credential cannot impersonate the rest of the plant. State awareness flows to everyone, so every consumer can distinguish live data from last-known-good.
That is the transport layer done right. The next question is what sits on either side of the broker, and this is where Timebase Historian and Timebase Atlas become the pillars of the architecture.
Model How Your Plant Actually Operates
Timebase Historian: a subscriber built for the full specification
Plenty of products can parse a Sparkplug payload. Far fewer honor the whole specification, and the difference shows up in production.
Timebase Historian's Sparkplug Collector subscribes to the namespace and treats birth, data, and death messages the way the specification intends. When an NBIRTH or DBIRTH arrives, the Historian learns the complete metric set for that node or device, with names, datatypes, and current values, and builds its storage structures automatically. There is no tag mapping exercise, and new equipment onboarded at the edge simply appears. When data flows, the Historian validates sequence ordering, deduplicates, compresses losslessly, and persists at full fidelity. When a death certificate arrives, the Historian knows the data has gone stale rather than silent, which is precisely the state awareness the specification was written to provide. Wildcard subscriptions and metric filters let you decide whether to ingest an entire enterprise namespace or one production line, and store-and-forward in the collection layer protects against the network outages Sparkplug itself was designed to survive.
A Sparkplug payload includes a native information model; a structured asset hierarchy that defines equipment, components, and their relationships as part of the protocol itself, not as a separate software layer. Timebase collects that metadata which means asset and namespace context flows into the historian automatically, without external configuration layers or translation tables.
There is also a philosophical alignment worth naming. Sparkplug's Report by Exception model assumes you want every change event, captured once, kept forever. Traditional historians undermine that assumption with per-tag licensing that forces engineers to ration what they store. Timebase Historian is free, with no tag limits, tested continuously past a million tags and 150,000 writes per second. When the transport says "publish everything that changes" and the historian says "store everything you publish," the architecture finally works the way it was drawn on the whiteboard.
Timebase Atlas: publishing meaning back into the namespace
Sparkplug solves transport and discovery. It does not solve meaning. A topic tells you a metric named Tank101/Temperature exists in Group: Plant2. It does not tell you that Tank-101 feeds Reactor-3 during fermentation, or that its CIP cycle can only run when Pump-3 is offline. That knowledge lives in your engineers' heads, and no topic taxonomy can hold it.
This is Atlas's role in the architecture. Atlas is a manufacturing knowledge platform: it connects to the Historian, the broker, and the transactional systems around them, and exposes everything through one user-defined knowledge graph. The graph captures the types, instances, and relationships that make the raw namespace intelligible, authored domain by domain by the people who actually hold the knowledge.
What makes Atlas unusual in a Sparkplug context is that it participates in the namespace from both sides. As a consumer, it uses the discovery and state semantics of the specification to keep its model synchronized with what is really deployed. As a publisher, Atlas puts modeled, contextualized information back onto the broker as first-class Sparkplug data: born with full metric definitions, strongly typed, carrying properties and quality, honoring the same lifecycle rules as any edge node. Derived KPIs, model-resolved values, and enterprise context become available to every Sparkplug subscriber in the infrastructure, not just to clients of an Atlas API. The specification's Template mechanism, which most publishers ignore, maps naturally onto Atlas's ontology: define an asset type once, publish structured instances everywhere.
The pairing is easy to summarize. The broker moves messages. Sparkplug makes the messages interoperable and stateful. Timebase Historian makes every message permanent and queryable. Atlas makes the whole namespace mean something. Or in the shorthand we use internally: the Historian stores, Atlas means.
Stand Behind The Spec
Manufacturers evaluating this architecture should weigh not just whether a vendor supports Sparkplug, but how. Flow Software is an Eclipse Foundation member and a member of the Sparkplug Working Group, contributing to the specification's development, and our solutions are certified under the Eclipse Sparkplug Compatibility Program. That commitment predates the current wave of UNS enthusiasm, and it reflects a simple conviction: open, well-governed specifications are how manufacturers escape vendor lock-in, and vendors who help write those specifications tend to implement them properly.
If you are building or rethinking your industrial data architecture, start with the specification. Then choose the pillars that take full advantage of it. Timebase Historian and Timebase Atlas were built to be exactly that.
If you are evaluating a software or hardware vendor implementing Sparkplug solutions and they are not members of the Sparkplug Working Group, beware, you are likely going to implement an incomplete Sparkplug specification and will miss the true benefit of the spec.
