Sparkplug B and the Unified Namespace: Structuring Industrial IoT Data on MQTT

Sparkplug B and the Unified Namespace are the two ideas that come up in almost every Industrial IoT project built on MQTT. In this article you will learn what a Unified Namespace is, how the ISA-95 hierarchy turns into a topic structure, how the Sparkplug B topic namespace and payload work, and how the two approaches complement each other. Along the way you will publish real ISA-95 and Sparkplug B messages to broker.connectmq.com.

If MQTT basics are new to you, read what an MQTT broker is first.

The Problem: Point-to-Point Spaghetti

A typical plant has PLCs, SCADA, an MES, a historian, a quality system and an ERP. Traditionally each system talks to the others through its own point-to-point connection. Add one new dashboard and you need three new integrations. Change one PLC tag and something breaks downstream.

MQTT solves the transport side: every producer publishes to a broker, every consumer subscribes. What MQTT does not decide for you is how to name topics and how to format payloads. That is exactly the gap that a Unified Namespace and Sparkplug B fill.

What Is a Unified Namespace?

A Unified Namespace (UNS) is a single, event-driven, hierarchical view of the current state of the whole business. Instead of asking each system for data, every system publishes what it knows into one shared topic tree on the broker, and every consumer subscribes to the part it needs.

Three properties define a good UNS:

• Single source of truth. The latest value of every machine, line and order lives in one place.
• Structured by the business. Topics follow the physical and organisational hierarchy, so people can find data without a tag list.
• Report by exception. Producers publish when something changes, and retained messages give new subscribers the current state immediately.

ISA-95 as a Topic Structure

The most common way to structure a UNS is the ISA-95 equipment hierarchy. Each level becomes a topic level:

Enterprise / Site / Area / Line / WorkCell / <data class>
acme       / izmir / machining / line1 / cnc1 / telemetry

Topic Design Table

A few practical rules:

• Use lowercase ASCII, no spaces, and stable IDs rather than display names.
• Keep the depth predictable. Consumers rely on wildcards such as acme/izmir/+/+/+/alarms to get every alarm in a site.
• Keep commands on their own branch (cmd) so they can be secured and audited separately from telemetry.
• Publish state messages as retained so a new dashboard sees the current value instantly.

Try It: Publish an ISA-95 JSON Message

The public area of broker.connectmq.com allows up to 8 topic levels, so use a short random prefix instead of a long one. Subscribe in one terminal:

mosquitto_sub -h broker.connectmq.com -p 1883 -i uns-a1b2-sub \
  -t "a1b2/acme/#" -v

Publish a machine reading from another terminal:

mosquitto_pub -h broker.connectmq.com -p 1883 -i uns-a1b2-cnc1 -q 1 \
  -t "a1b2/acme/izmir/machining/line1/cnc1/telemetry" \
  -m '{"spindleSpeed":12000,"temperature":41.7,"status":"RUNNING"}'

The subscriber prints the topic and JSON payload. Everything in the public area is readable by anyone, so never publish real production data there.

What Is Sparkplug B?

Sparkplug B is an open specification, maintained under the Eclipse Foundation, that defines three things MQTT leaves open: a fixed topic namespace, a binary payload format and a state management model. It was designed so that SCADA and host applications can discover devices automatically and always know whether data is current or stale.

The Sparkplug B Topic Namespace

Every Sparkplug B topic follows this pattern:

spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}

group_id groups edge nodes (for example a plant), edge_node_id is the gateway or edge device, and the optional device_id is a PLC or sensor behind that edge node.

The NDEATH message is registered as the MQTT Last Will when the edge node connects, so the broker publishes it automatically if the connection drops. Consumers then mark all of that node's data as stale.

Payload: Protobuf, Aliases and Sequence Numbers

Sparkplug B payloads are encoded with Google Protocol Buffers. A payload contains a timestamp, a sequence number and a list of metrics; each metric has a name, an optional numeric alias, a data type, a timestamp and a value.

Key mechanics:

• Birth certificates. NBIRTH and DBIRTH contain every metric with its full name and data type. Later DDATA messages can send only the numeric alias and new value, which keeps packets small.
• Sequence numbers. Every message from an edge node carries a seq value from 0 to 255 that wraps around. If a host sees a gap, it knows a message was lost and can send a rebirth command (NCMD) to request fresh birth certificates.
• bdSeq. A birth/death sequence number ties each NDEATH to the NBIRTH of the same session, so an old death certificate cannot wipe out a newer session.

Here is the same reading as above, shown as the JSON representation of a Sparkplug B DDATA payload:

{
  "timestamp": 1760600000000,
  "seq": 1,
  "metrics": [
    { "name": "temperature", "timestamp": 1760600000000, "dataType": "Double", "value": 41.7 }
  ]
}

Sparkplug B vs Unified Namespace: Complementary, Not Competing

In practice many plants use both. Edge nodes speak Sparkplug B because it gives reliable state and efficient payloads close to the machines. The data is then republished into an ISA-95 structured namespace in readable JSON, where MES, dashboards and IT applications consume it without ever touching Protobuf. The hard part is that translation layer, and that is where the broker can help.

How ConnectMQ Handles Sparkplug B and ISA-95 Topics

ConnectMQ is a managed MQTT broker with Industrial IoT support built in:

• ISA-95 detection. It recognises ISA-95 and Unified Namespace topic structures in your traffic.
• Sparkplug B decoding. It detects Sparkplug B messages and decodes both Protobuf and JSON payloads.
• Republishing into ISA-95. Sparkplug B data can be republished into an ISA-95 structure, for example spBv1.0/factory1/DDATA/line1/cnc1 becomes connectmq/factory1/production/line1/cnc1/telemetry, with a flat JSON payload that any subscriber can read.
• Portal views. The portal's Devices view organises your equipment by ISA-95 levels, and threshold alert rules with an alerts log let you react when, say, a spindle temperature crosses a limit.

Try It: Sparkplug B In, Readable Telemetry Out

Use a unique group ID such as a1b2plant. First subscribe to both the Sparkplug topic and the republished branch:

mosquitto_sub -h broker.connectmq.com -p 1883 -i spb-a1b2-sub -v \
  -t "spBv1.0/a1b2plant/#" -t "connectmq/a1b2plant/#"

Then publish a DDATA message with a JSON Sparkplug B payload:

mosquitto_pub -h broker.connectmq.com -p 1883 -i spb-a1b2-edge -q 1 \
  -t "spBv1.0/a1b2plant/DDATA/line1/cnc1" \
  -m '{"timestamp":1760600000000,"seq":1,"metrics":[{"name":"temperature","timestamp":1760600000000,"dataType":"Double","value":41.7}]}'

When we tested this on broker.connectmq.com, the subscriber received the original Sparkplug B message and a second message under connectmq/a1b2plant/.../line1/cnc1/telemetry with the payload {"temperature":41.7,"timestamp":1760600000000}. Downstream tools can now subscribe to connectmq/a1b2plant/+/+/+/telemetry and get clean JSON per machine.

For production, create a dedicated broker in the portal and connect with YOUR_USERNAME, YOUR_PASSWORD and YOUR_CLIENT_ID over TLS on port 8883. Each tenant's topics are isolated from other tenants and from the public area. See MQTT security best practices for credential and TLS guidance.

Design Checklist for Your First UNS

1. Agree on the ISA-95 levels and naming rules before the first device connects.
2. Decide which data classes you need (telemetry, state, alarms, cmd) and keep them consistent.
3. Use Sparkplug B at the edge where you need birth/death awareness, and a readable ISA-95 branch for everyone else.
4. Use QoS 1 for state and alarms; see MQTT QoS levels explained for the trade-offs.
5. Use retained messages for current state, and keep payloads small and typed.
6. Pick a broker that can grow with you; how to choose an IoT MQTT broker covers the criteria.

Get Started with ConnectMQ

You can try both examples above on the public broker right now. To build a real Unified Namespace with isolated topics, ISA-95 device views and threshold alerts, sign up at app.connectmq.com. The Serverless plan is free, needs no credit card, and you can scale to Dedicated, BYOC or Self Managed Enterprise when your plant goes live.

Frequently Asked Questions

Is Sparkplug B the same as a Unified Namespace?

No. Sparkplug B is a specification for topics, payloads and session state on MQTT, while a Unified Namespace is an architecture pattern for organising all business data in one hierarchy. They work well together.

Can I read Sparkplug B messages without a Protobuf decoder?

Not directly, because the payload is binary. ConnectMQ decodes Sparkplug B Protobuf and JSON payloads and can republish them as readable JSON into an ISA-95 topic structure.

How deep should an ISA-95 topic hierarchy be?

Enterprise, Site, Area, Line and WorkCell plus a data class gives six levels, which suits most plants. Keep the depth consistent so wildcard subscriptions work predictably.

Does Sparkplug B require MQTT 5?

No. Sparkplug B works over MQTT 3.1.1 and is commonly deployed that way. ConnectMQ supports both MQTT 3.1.1 and MQTT 5.0, so Sparkplug edge nodes and newer clients can share the same broker.