MQTT Sparkplug for PLC and SCADA: Topics, Birth/Death and Testing

Direct answer

MQTT Sparkplug for a PLC and SCADA system is a defined industrial application convention built on MQTT. Sparkplug 3.0 standardizes the topic namespace, protobuf payload, metric model and session-state behavior that ordinary MQTT leaves to the application designer. A Sparkplug-capable Edge Node reads PLC or device data, connects to an MQTT server, publishes complete NBIRTH and DBIRTH declarations, sends changes in NDATA or DDATA, and uses death messages so a SCADA host can mark unavailable values stale instead of displaying old values as live.

“The PLC publishes MQTT” is not enough to claim Sparkplug compatibility. The implementation must honor the versioned namespace, roles, message types, birth-before-data sequence, seq and bdSeq rules, MQTT session behavior and state-management requirements. If a product is advertised as officially compatible, verify the exact product and version in the Eclipse Sparkplug compatibility list; a vendor feature name alone is not TCK evidence.

For a new project, define five contracts before configuring software:

1. Role contract: which component is the PLC, Edge Node, MQTT server, Primary Host Application and secondary consumer?
2. Namespace contract: which group_id, edge_node_id, device_id and metric names are globally owned?
3. State contract: what makes a value live, stale, bad or unknown after PLC-link, edge, broker or host loss?
4. Command contract: which requests may cross MQTT, and how does the PLC authorize, sequence, expire, interlock, acknowledge and prove them?
5. Evidence contract: which captures, logs, metric ages, birth revisions and acceptance results prove correct operation and recovery?

Download the Sparkplug design register, topic and metric map and 20-test acceptance matrix. They turn a broker demo into a reviewable control-system interface.

This guide uses the ratified Sparkplug 3.0 specification published in 2022. It does not claim that every MQTT broker, gateway, SCADA package or PLC driver implements the same optional facilities. The broader PLC and IIoT integration guide remains the architecture owner; this page owns Sparkplug session mechanics, implementation and diagnosis.

What Sparkplug adds to MQTT

MQTT transports messages; Sparkplug defines industrial meaning

MQTT defines client/server messaging, topics, subscriptions, retained messages, Quality of Service, session state and Will messages. It intentionally does not define whether factory/a/temperature is a sensor, which datatype its payload contains, how a receiver discovers every metric, or when a cached value becomes stale.

Sparkplug adds the shared convention required for interoperable industrial state. The current specification defines:

• an OT-oriented topic namespace;
• node and device roles;
• birth, data, death and command message types;
• a binary Sparkplug B payload with typed metrics;
• session ordering, sequence counters and birth/death correlation;
• Primary Host online/offline state; and
• a rebirth mechanism when a host no longer has a trustworthy definition.

The result is not a replacement for PLC logic, OPC UA, historian design or cybersecurity. Sparkplug can sit above a PLC driver using OPC UA, Modbus, EtherNet/IP, PROFINET or a vendor API. It can also be implemented in a supported controller or gateway. The source protocol still owns its addressing, update, quality and diagnostic behavior.

Layer	Defines	Does not prove
PLC program and I/O	control state, permissives, interlocks, modes and physical response	broker or Sparkplug health
PLC driver or device adapter	source addressing, polling/subscription, conversion and link diagnostics	end-to-end namespace correctness
Sparkplug	topics, payload metrics, births, deaths, state and command message shapes	safe authorization of a process command
MQTT	client/server transport, subscription, QoS, Will and retained mechanics	industrial semantic interoperability
Primary Host / SCADA	authoritative Sparkplug state, visualization, alarms and operator workflow	controller execution or final-element state without feedback
Historian / analytics	persistence, aggregation and analysis	that a late value was live when produced

Sparkplug does not modify MQTT

The Eclipse Sparkplug FAQ is explicit that Sparkplug does not change MQTT. That distinction matters during troubleshooting. A TCP connection and successful MQTT PUBLISH prove transport milestones; they do not prove a valid Sparkplug topic, decodable payload, complete birth, acceptable sequence or live metric state.

Similarly, Sparkplug and OPC UA are not simply substitutes. OPC UA defines a much broader information and service architecture and has its own PubSub mappings. A gateway may read a rich OPC UA model and expose a deliberately smaller Sparkplug metric contract. Record what semantics are retained, renamed or lost rather than assuming automatic one-to-one translation.

Roles and ownership in a PLC–SCADA design

PLC, Edge Node, MQTT server and Primary Host

Use role names precisely. In the worked packaging-line design:

Role	Worked component	Responsibility	First evidence when data is wrong
PLC/device	Packer01 controller	executes control and exposes approved source values	online status, source tags, task/scan and driver diagnostics
Edge Node	Line01Edge	acquires PLC data, owns Sparkplug node/device session and publishes metrics	driver state, birth revision, bdSeq, seq, outbound queue
MQTT server	redundant or single approved broker service	authenticates clients, authorizes topics and routes messages	listeners, TLS identity, ACL result, connection and resource logs
Primary Host Application	production SCADA	owns authoritative visualization of Sparkplug state	own STATE, subscriptions, birth cache, stale logic and event log
secondary consumer	historian or analytics	consumes approved metrics without becoming control authority	subscription, persistence and data-quality handling

The Sparkplug Edge Node is a logical role, not necessarily a separate industrial computer. It may be a gateway, an application on an industrial PC, a supported PLC module or a controller-native implementation. The exact version and TCK status still matter.

The Primary Host Application is not merely any dashboard. It is the Sparkplug-aware host whose online state can govern when configured Edge Nodes publish births. Give it a unique sparkplug_host_id. Avoid deploying two systems with the same identity or two Edge Nodes with the same group_id and edge_node_id; identity collisions make one logical session overwrite or invalidate another.

Control authority remains at the process boundary

The PLC must remain authoritative for process permissives, interlocks, operating mode, command arbitration, feedback timeouts and safe-state reactions. A valid DCMD delivered to an Edge Node is a request to write a metric under the configured application model. It is not evidence that:

• the request came from an authorized human or service;
• the request is current rather than replayed;
• the process is in an allowed mode;
• all permissives and safety functions are healthy;
• the output or final element changed; or
• the requested result was achieved.

These conditions require layered broker authorization, application authorization and PLC-side validation, followed by independent command and process feedback.

Sparkplug topic namespace by example

Read every segment; do not parse by visual guess

Sparkplug 3.0 uses the general structure:

namespace/group_id/message_type/edge_node_id/[device_id]

The Sparkplug B namespace is spBv1.0. For group PlantA, Edge Node Line01Edge and device Packer01, representative topics are:

spBv1.0/PlantA/NBIRTH/Line01Edge
spBv1.0/PlantA/NDATA/Line01Edge
spBv1.0/PlantA/NDEATH/Line01Edge
spBv1.0/PlantA/NCMD/Line01Edge

spBv1.0/PlantA/DBIRTH/Line01Edge/Packer01
spBv1.0/PlantA/DDATA/Line01Edge/Packer01
spBv1.0/PlantA/DDEATH/Line01Edge/Packer01
spBv1.0/PlantA/DCMD/Line01Edge/Packer01

device_id is present for the four device message types and absent for node message types. The Primary Host state topic has a different shape:

spBv1.0/STATE/PlantScada01

Its state payload is UTF-8 JSON rather than a Sparkplug B protobuf payload. A generic decoder that expects every spBv1.0 message to be the same binary object will mishandle host state.

Namespace governance prevents collisions

Do not let each gateway installer invent names at commissioning time. Maintain a namespace register with the business owner, physical scope, Edge Node owner, device source, approved characters/case, retirement state and replacement identity. Topic strings are operational interfaces: changing one can create a new logical asset while silently abandoning subscriptions and history attached to the old identity.

Prefer stable asset identities over network location or a person’s project nickname. PlantA/Line01Edge/Packer01 can survive an IP-address change. 192_168_4_20/NewGateway2 embeds temporary implementation detail. If a physical machine is replaced while continuity is required, document how identifier reuse, metric revision, history and commissioning evidence are controlled.

Namespace defect	Observable symptom	Evidence that separates it
wrong group_id	host subscribes successfully but sees no asset	compare published topic capture with host subscription filter
duplicate Edge Node identity	repeated rebirths, alternating data or unexpected stale transitions	correlate MQTT client IDs, source addresses, bdSeq and broker disconnect logs
case mismatch	one expected device appears absent	compare raw topic bytes; treat identifiers as exact strings
unexpected device segment	decoder rejects or misroutes message	validate message-type shape against the specification
renamed metric without revision	trend splits or consumer reports missing value	compare current DBIRTH with controlled metric contract
wildcard subscription too broad	consumer receives other plants or command topics	review least-privilege ACL and subscription evidence

Birth, data and death state machine

NBIRTH establishes the Edge Node definition

After the approved session prerequisites are met, an Edge Node publishes NBIRTH with QoS 0 and retain false. Its payload sequence begins at zero. The birth includes the node timestamp and every metric the Edge Node will report, with at least each metric’s name, datatype and current value. Template definitions are included when the implementation uses them.

The node birth also carries a bdSeq metric matching the value placed in the MQTT CONNECT Will’s NDEATH payload. That birth/death sequence starts at zero and increments on every MQTT CONNECT according to the specification’s counter behavior. It is not the same as the per-message seq field.

Sparkplug defines a Boolean Node Control/Rebirth metric, initially false, so a host can request a fresh set of births when it cannot reconcile the current definition or sequence. Rebirth is recovery, not a periodic refresh job. Continuous rebirth requests indicate an unresolved identity, subscription, decoder, sequence or lifecycle defect.

DBIRTH establishes each downstream device definition

For every represented device, the Edge Node publishes a DBIRTH containing every metric that device will report, again with name, datatype and current value. The DBIRTH uses the next message sequence. A device is not safely reconstructed by an NBIRTH alone: after a new node birth, the host needs a new DBIRTH before treating that device’s later data as live.

This requirement prevents a common failure: a host retains yesterday’s device definition, receives a new Edge Node session and immediately accepts compact or changed data against the old schema. The complete birth sequence gives the host a controlled point to replace its metric model.

NDATA and DDATA carry changes after birth

Node and device data messages carry metrics changed since the previous applicable birth or data message. Their seq increments from the prior Sparkplug message in that Edge Node session and wraps from 255 to 0. The specification supports time-based publication but discourages unnecessary periodic traffic; change-based reporting is the normal design.

Do not translate that into “there will never be an unchanged value.” An application may need approved time-based updates, historical/store-forward behavior or quality transitions. The contract must state why an update occurs, the maximum expected source age, how consumers distinguish repeated value from repeated sample, and how time behavior is tested.

NDEATH and DDEATH mean different failures

NDEATH is the Edge Node’s MQTT Will message supplied in CONNECT, not a normal last-second publish performed after the connection is already lost. Its payload contains the matching bdSeq; it has no ordinary Sparkplug seq field. When a Primary Host receives an NDEATH matching the last NBIRTH bdSeq, it can mark the node and its device metrics stale.

DDEATH is published by a still-connected Edge Node when one downstream device becomes unavailable. It uses the device topic shape and the next seq. The distinction preserves fault location:

Failure	MQTT session	Expected state evidence	Scope to mark stale
PLC/device driver unavailable	Edge Node still connected	DDEATH plus driver diagnostics	affected device
Edge process crash	connection disappears	broker publishes configured NDEATH Will	node and its devices
edge network path lost	connection eventually judged lost	NDEATH after broker/client session detection	node and its devices
broker unavailable to all	clients lose service; no single subscriber may immediately observe every Will	broker cluster, client and host connection evidence	system state by designed timeout/recovery
Primary Host stops	its retained STATE death becomes authoritative to subscribers	host Will and edge logs	host state; edge reaction per Primary Host design

Primary Host STATE and MQTT session settings

Publish host state in the specified order

The Primary Host’s STATE birth message is JSON such as an object with online true and a timestamp. It is published at QoS 1 with retain true, so newly connected Edge Nodes can learn the current authoritative host state. The corresponding Will state has online false, the matching CONNECT-time timestamp, QoS 1 and retain true.

The Primary Host subscribes to its own STATE topic and the appropriate Sparkplug namespace before publishing online state. For a clean shutdown, it publishes its offline state before disconnecting; for an ungraceful loss, the broker publishes the configured Will.

The Sparkplug 3.0 session requirements use a non-persistent client session: MQTT 3.1.1 Clean Session true, or MQTT 5 Clean Start true with Session Expiry Interval zero. Copying a generic “persistent MQTT session” recipe into a Sparkplug component can preserve old subscription/session assumptions that conflict with deterministic state reconstruction.

Primary Host gating is a deliberate availability decision

An Edge Node configured for a Primary Host waits for that host’s online STATE before issuing its birth sequence. This allows the authoritative application to be present before state is constructed, but it also makes host identity and availability operational dependencies.

Define these cases explicitly:

Case	Required design answer
Primary Host starts after Edge Node	does edge wait, then birth exactly once after authoritative online state?
host restarts while edge remains connected	does host death become visible, and does the edge rebuild state after the new online state?
duplicate host identity	which client is authoritative and how is collision prevented?
retained host state is administratively corrupted	who can correct it, and how is a forced change audited?
host disaster recovery changes infrastructure	does sparkplug_host_id continuity remain correct?
secondary dashboard is offline	can it fail without becoming Primary Host or blocking control?

Do not use a retained custom “edge online” data value as a substitute for the specified birth/death lifecycle. Retained application telemetry can outlive the session that produced it. Sparkplug edge births and data are sent with retain false; host STATE is the deliberate retained state surface.

Design the metric contract before building tags

A metric name is an interface, not a screen label

Start with process meaning, datatype, unit, source, range, quality, update rule and revision. Do not publish every PLC tag. Internal states, temporary values, counters, engineering overrides and safety-related data can be misleading or dangerous outside their execution context.

For Packer01, a minimum observable contract might be:

Metric	Type	Unit	Source	Update rule	Consumer rule
Running	Boolean	state	proven command feedback, not request coil	on change	live only after current DBIRTH and good PLC link
ActualSpeed	Int32	rpm	scaled drive feedback	on change beyond approved deadband	validate range and source age
Count	Int64	count	controlled production counter	on change	define reset and restart continuity
FaultCode	UInt16	code	PLC first-out state	on change	decode against versioned codebook
PlcLinkQuality	UInt8	percent or documented enumeration	Edge Node driver	every health transition	never infer from broker session alone
SourceAge	Int32	ms	edge-calculated from last source update	bounded interval	alarm or stale at approved threshold

The exact Sparkplug datatype and product mapping require the implementation documentation. A PLC DINT, an OPC UA Int32 and a Sparkplug metric type may look similar but still need signedness, range, null/quality, overflow and conversion tests.

Treat aliases as session-scoped compression

Sparkplug aliases reduce repeated metric-name overhead after a birth establishes the mapping. Consumers must not assume an alias from an earlier session or device definition. When a birth is missed or a decoder loses its current mapping, a compact data message can appear undecodable or attach to the wrong stale definition.

Use deterministic alias generation supported by the chosen product, validate uniqueness inside its scope, capture the DBIRTH mapping, then test reconnect and rebirth. Do not expose alias numbers as durable historian or API identities. The metric name and governed asset context are the stable application contract.

Separate value, quality and age

A cached value of 1450 rpm can remain numerically plausible long after the PLC link fails. Publish or derive enough evidence for the host to answer three different questions:

1. What was the last value?
2. Was its source healthy when acquired?
3. How old is it now?

Sparkplug death/state handling covers important session failures, but a live Edge Node connection does not prove its PLC driver is updating. Add device-level death and driver-quality evidence. If the product supports historical/store-forward metric flags, verify its exact implementation against the specification and product documentation; do not treat Sparkplug messages themselves as a historian. The historian remains responsible for durable retention, query behavior, late data and audit requirements.

Commands: request, validate, acknowledge and prove

NCMD and DCMD are metric writes—not a safety argument

NCMD targets Edge Node metrics; DCMD targets device metrics. They are published at QoS 0 with timestamp and metrics to write under the Sparkplug model. The PLC application must still implement a bounded command protocol where consequences matter.

A robust motor-speed request uses separate fields and states:

Surface	Example	Owner	Required check
request	RunRequest, SpeedRequest, RequestId, RequestedAt	authorized SCADA workflow	role, scope, range and intent confirmation
transport acceptance	broker and edge audit	MQTT/edge platform	authenticated identity, allowed topic, valid payload
PLC command acceptance	CommandAccepted, CommandRejectReason, RequestIdEcho	PLC command arbiter	mode, freshness, sequence, permissives and interlocks
command state	RunCommand	PLC logic	single writer and defined reset/fault behavior
equipment feedback	Running, ActualSpeed	sensor/drive/process	independent timeout and plausibility
outcome	reached speed, rejected, tripped or timed out	process application	first-out evidence and operator response

A delivery retry or duplicate application request must not create a second start/stop pulse or repeat a non-idempotent action. Define request identifiers, acceptance windows and last-processed state. Reject an old request even if its MQTT timestamp is syntactically valid. Clock synchronization supports diagnosis but should not be the only replay defense.

Never place fast closed-loop control across a remote broker

Keep deterministic machine sequencing, motion, safety and fast PID execution at the controller or approved local control layer. MQTT/Sparkplug is suitable for supervisory requests, state distribution, analytics and carefully designed coordination where latency, disconnection and duplicate handling are explicitly tolerated.

For any command path, test broker loss before, during and after acceptance; Edge Node restart; SCADA retry; stale timestamp; sequence wrap; duplicate request; wrong operating mode; false permissive; feedback loss and operator cancellation. A green dashboard demonstration is not a command-risk assessment.

Security and availability architecture

Start with zones, unique identities and least privilege

NIST SP 800-82 Rev. 3 treats operational technology as a distinct environment with safety, reliability and performance constraints. Apply defense in depth without assuming an Internet-style control can be inserted harmlessly into an operational path.

At minimum:

• place broker, edge, PLC and enterprise consumers in documented zones and conduits;
• avoid direct public-Internet exposure of OT brokers and control identities;
• use encrypted transport where supported and approved, with server validation;
• issue unique client identities and credentials or certificates;
• authorize publish and subscribe rights by exact role and namespace;
• deny SCADA consumers from publishing command topics unless explicitly required;
• separate administration, application and monitoring identities;
• protect private keys and define enrollment, renewal, revocation and expiry monitoring;
• set tested connection, message-size, inflight, queue and resource limits;
• monitor authentication failures, ACL denials, disconnect rates, rebirth rates and resource saturation; and
• maintain offline configuration backups and a proved restore procedure.

Identity	Minimum topic rights in the worked example	Must not receive by default
Line01Edge	publish its node/device birth, data and death; subscribe to its approved commands and Primary Host STATE	other plants’ commands or broker administration
PlantScada01	publish its own STATE and approved node/device commands; subscribe to approved group state	unrestricted administration or unrelated business topics
historian	subscribe to approved birth/data/death/state required for interpretation	publish rights and command topics
engineering diagnostic user	time-limited read evidence and, if approved, controlled test namespace	standing production command authority
broker administrator	platform administration through controlled management path	routine process operation

MQTT QoS is not an end-to-end process guarantee. QoS describes MQTT delivery behavior between a client and server under protocol conditions. It does not prove the Edge Node decoded a command, the PLC accepted it, the output changed or the process responded. Preserve application acknowledgments and physical feedback.

Design recovery, not just steady-state connectivity

Record recovery-time and recovery-point objectives for the broker, Primary Host, Edge Node and metric history. If the broker is clustered, test the supported client connection strategy, session consequences, retained host state, Will timing and certificate identity during failover. If an Edge Node buffers data, define storage limit, ordering, overflow, age, historical marking and what happens when the broker returns.

A healthy architecture should degrade observably:

• source link lost: device quality becomes bad/stale while broker session can remain online;
• broker path lost: Edge Node queues only within its approved policy and exposes resource state locally;
• Primary Host lost: its STATE becomes offline and configured nodes follow the defined gating behavior;
• certificate near expiry: monitoring warns before production loss;
• namespace or schema revision rejected: old and new contract versions are traceable rather than silently mixed.

Commissioning sequence with captured evidence

Pass one: prove each layer independently

Do not begin by toggling a remote output. Use a read-only metric and collect evidence from source to host:

1. Freeze the design register, exact versions and namespace map.
2. Prove the PLC source value and its local quality/age.
3. Prove the Edge Node driver reads the correct address and datatype.
4. Prove MQTT TLS identity, authorization and connection without Sparkplug assumptions.
5. Capture and decode Primary Host STATE.
6. Capture NBIRTH, confirm seq zero and correlate bdSeq with the Will design.
7. Capture every DBIRTH and diff metrics against the approved contract.
8. Change one safe test value and trace its DDATA, timestamp, sequence and host state.
9. Interrupt only the PLC/device link and prove DDEATH/device stale behavior.
10. Interrupt the Edge Node network in an isolated test and prove NDEATH/node stale behavior.
11. Reconnect and prove fresh NBIRTH plus DBIRTH before data returns live.
12. Export broker, edge, host and PLC evidence under one synchronized incident identifier.

Pass two: prove commands under negative conditions

Only after read/state behavior passes should the team enable an approved command metric in an isolated or otherwise controlled test. Begin with a non-physical test state where possible. Then prove authorized acceptance, unauthorized rejection, expired request, duplicate request, wrong sequence, wrong mode, false permissive, loss during transaction, feedback timeout and first-out capture.

For physical commissioning, follow the site’s energy-control, machine-safety, permit, guarding and change procedures. A software interlock demonstrated on a screen is not a validated safety function. Safety-related design and validation belong to the applicable functional-safety lifecycle and qualified team.

Evidence clock	Capture	Why it matters
PLC/controller	source value, logic state and first-out event	proves control-layer timing and decision
Edge Node	driver update, local timestamp, metric mapping and publish result	separates PLC-link from broker-link fault
broker	client identity, connect/disconnect, authorization and routing	proves transport/security milestone
Primary Host	STATE, subscription, birth cache, stale transition and displayed value	proves authoritative interpretation
packet capture where approved	topic, QoS, retain, order and decoded test payload	provides independent wire evidence
test record	version hashes, test step, expected result, observed result and sign-off	makes commissioning repeatable

Troubleshooting Sparkplug without guessing

Start at the first wrong state transition

Do not troubleshoot from the final red icon alone. Compare the last known-good session with the incident: Primary Host STATE, Edge Node connect, NBIRTH, every DBIRTH, sequence progression, device link quality, last data age, death event and reconnect births.

Symptom	Likely boundary	Decisive evidence	Corrective direction
all nodes stale	host STATE, broker connection or shared network/service	host/broker logs and own STATE topic	restore authoritative host or broker path; do not rebirth blindly
one node and all devices stale	edge process/network/session	matching NDEATH, bdSeq, broker disconnect	repair edge/session cause, then require clean births
node live but one device stale	PLC/device driver path	DDEATH and Edge Node driver diagnostics	repair source link; preserve device-scoped fault
values visible but never change	source polling, datatype, deadband or data publication	PLC trace versus edge driver and DDATA capture	repair first missing transition
unknown alias	birth missing, cache reset or illegal alias mapping	captured DBIRTH alias table and current session ID	request one controlled rebirth and repair lifecycle cause
sequence gap	loss, decoder issue, session mix or overloaded path	ordered decoded payloads and component logs	determine loss scope; rebuild state when required
rebirth storm	host repeatedly rejects state or edge repeatedly reconnects	NCMD/rebirth, connection and identity timeline	stop request loop; fix definition, identity or session cause
duplicate device/node	namespace or deployment collision	MQTT client IDs, source addresses and alternating births	isolate duplicate and restore registered ownership
commands arrive but PLC rejects	application validation	request ID, mode, expiry and reject reason	fix legitimate precondition; never bypass silently
broker reports online but PLC data is stale	source link is independent of MQTT link	driver status and SourceAge	repair PLC/driver path and quality model
history jumps after reconnect	store-forward/time semantics	historical flags if supported, timestamps and queue logs	repair ordering/age policy and historian interpretation
intermittent disconnect under load	broker/client resource or network quality	CPU, memory, queues, quotas, packet loss and keepalive timeline	remove bottleneck; validate controlled capacity

Use rebirth as a bounded recovery action

Request a rebirth when the current host cannot trust or reconstruct the node/device definitions—for example, after a missed birth or unresolved alias. Record who or what requested it, the reason, current session evidence and outcome. One new NBIRTH followed by the required DBIRTH messages should converge the model.

If the host requests rebirth repeatedly, rate-limit automated action and preserve the first failing payload. A rebirth storm can increase load and erase the simplest incident timeline without correcting a malformed metric, duplicate identity or decoder incompatibility.

Selection and proof-of-fit checklist

Verify the exact product version, not the logo

The Eclipse Sparkplug compatibility program uses a Technology Compatibility Kit. Check whether the exact software/product version appears in the current compatible-products list. A newer unlisted release may still be conformant, but that becomes a project verification claim rather than inherited evidence from a different version.

For every candidate Edge Node, broker and host, obtain dated answers:

Decision surface	Evidence to request
Sparkplug revision and role	exact implemented specification revision and supported role
compatibility	exact TCK-listed product/version or vendor conformance statement
MQTT version/session	client settings, clean-session/start behavior and Will configuration
payload and metrics	datatype, property, dataset/template, alias and timestamp support actually used
source drivers	exact PLC families, firmware, protocol services and quality mapping
store and forward	capacity, ordering, overflow and historical/age behavior
security	TLS versions, certificate validation, identity storage and ACL integration
availability	broker and application failover behavior plus tested recovery time
observability	logs, metrics, packet/decoder support and audit export
lifecycle	supported OS, update path, vulnerability response, backup and rollback

Run the same proof contract across products. Marketing screenshots are not comparative evidence. Use isolated infrastructure, a fixed metric map, documented failures and exported results.

Twenty acceptance tests before production

The downloadable matrix contains the detailed evidence columns. The minimum suite covers:

1. Primary Host cold-start ordering and retained STATE.
2. Complete NBIRTH metric declaration.
3. Complete DBIRTH for every represented device.
4. One controlled PLC value change through DDATA to host.
5. seq progression, gap detection and 255-to-0 wrap handling.
6. Abrupt Edge Node loss and matching NDEATH state transition.
7. Controlled Edge Node shutdown.
8. Device-only/PLC-link loss and DDEATH scope.
9. Reconnect with fresh node and device births.
10. One authorized rebirth request without a storm.
11. Primary Host restart and correct online/offline state.
12. Broker restart/failover and complete state reconstruction.
13. Unauthorized subscription denial.
14. Unauthorized command denial.
15. Expired, duplicated and out-of-sequence command rejection.
16. Unsafe-mode or false-permissive command rejection by the PLC.
17. Live MQTT session with stale PLC source data.
18. Clock-offset and source-age visibility.
19. Representative connection, topic and message load under quotas.
20. Backup restore and controlled rollback.

For every test, capture the initial state, controlled stimulus, expected state transition, timestamps from each layer, raw/decoded message evidence where permitted, actual result, defect reference and accountable sign-off. “It appeared on the SCADA screen” proves only one visible endpoint.

Practice the diagnostic boundary before touching production

A generic PLC troubleshooting lab can help a technician practice separating request, PLC command, feedback, timeout and first-out fault states. Open the PLC troubleshooting simulator after you have defined the Sparkplug evidence columns.

Disclosure: PLCProgramming.io and PLCSimulationSoftware.com share ownership. The linked browser lab does not emulate an MQTT broker, Sparkplug B protobuf encoding, Edge Node session, Primary Host STATE, seq, bdSeq, NBIRTH/DBIRTH, NDEATH/DDEATH, product driver, certificate, ACL, physical PLC I/O, final element or safety function. Use it only to rehearse the application-level fault boundary, then validate the real components with the 20-test matrix. Measure clicks, scenario starts, registrations and paid conversion together; do not optimize the CTA on traffic alone.

Answer map for engineers and AI assistants

Question	Concise answer
Is Sparkplug the same as MQTT?	No. MQTT transports messages; Sparkplug defines an industrial topic, payload, metric and session-state convention on top of it.
Does a PLC need to publish Sparkplug directly?	No. A compatible Edge Node can acquire PLC data through an approved driver and own the Sparkplug session.
What is the Sparkplug B namespace?	spBv1.0 in Sparkplug 3.0 topic paths.
What is NBIRTH?	The complete definition and current value set for Edge Node metrics at the start of a valid session.
What is DBIRTH?	The complete definition and current value set for one device represented by the Edge Node.
What is NDEATH?	The Edge Node MQTT Will payload used to correlate an unexpected session loss through bdSeq.
What is DDEATH?	A device-scoped death published by a connected Edge Node when the represented device becomes unavailable.
What is seq?	The per-Edge-Node Sparkplug message sequence, beginning at birth and wrapping after 255.
What is bdSeq?	The birth/death connection sequence that correlates the NBIRTH with the configured NDEATH Will.
Should Sparkplug data be retained?	Edge birth/data messages use retain false; Primary Host STATE deliberately uses retain true. Do not invent retained latest-value behavior.
Can Sparkplug replace a historian?	No. A historian still owns durable persistence, query, late-data and audit behavior.
Does MQTT QoS prove a motor started?	No. It describes protocol delivery, not PLC acceptance, output state or physical process feedback.

Frequently asked questions

What is MQTT Sparkplug in PLC automation?

MQTT Sparkplug is an open industrial specification that defines how Edge Nodes, devices and Primary Host Applications use MQTT topics, typed Sparkplug B metrics, births, deaths, data and commands. It gives a SCADA host a consistent way to discover an interface and mark data stale after a session or device failure.

What is the difference between Sparkplug and Sparkplug B?

Sparkplug is the specification and application convention. Sparkplug B refers to the current binary payload encoding and its spBv1.0 namespace. Use the ratified Sparkplug 3.0 document for normative behavior rather than deriving requirements from an older tutorial.

Can any MQTT-enabled PLC connect to a Sparkplug SCADA?

Not automatically. Generic MQTT capability does not prove the Sparkplug topic namespace, protobuf metric payload, birth/death state machine, sequence handling or Primary Host behavior. Use a compatible PLC implementation or Edge Node and test the exact product/version.

What is the difference between NBIRTH and DBIRTH?

NBIRTH declares every metric owned by the Edge Node itself. DBIRTH declares every metric for one device represented under that Edge Node. After a new NBIRTH, a device remains stale until its new DBIRTH reconstructs the device definition.

What happens when a Sparkplug Edge Node disconnects?

For an ungraceful disconnect, the MQTT server publishes the NDEATH Will configured when the Edge Node connected. A matching bdSeq lets the Primary Host associate that death with the current birth and mark the node and its devices stale. Exact detection time depends on MQTT session/network settings and the implementation.

Why is a Sparkplug device stale while its Edge Node is online?

The downstream PLC/device link can fail without the Edge Node’s MQTT session failing. Check DDEATH, the PLC driver status, last successful source update, metric age and DBIRTH status. Do not use broker connectivity as proof that controller data is fresh.

When should a Primary Host request rebirth?

Request rebirth when it cannot trust or reconstruct the current metric definitions—for example, after a missed birth or unknown alias. Expect one controlled new NBIRTH and the necessary DBIRTH messages. Repeated requests require root-cause diagnosis.

Should MQTT Sparkplug control a PLC output directly?

Treat DCMD or NCMD as an application request. The PLC must validate identity context supplied by the application, freshness, sequence, mode, range, permissives and interlocks, then expose separate acceptance and physical feedback. Keep safety and fast closed-loop control in approved local systems.

Is MQTT QoS 1 or 2 required for all Sparkplug data?

No. Sparkplug 3.0 defines QoS behavior by message type; Edge Node birth/data/command messages are not made “safer” by changing settings arbitrarily. Primary Host STATE uses QoS 1 and retain true. Follow the normative tables and the exact product documentation.

Does Sparkplug retain the latest PLC value in the broker?

Not through retained edge birth or data messages: those use retain false. The host rebuilds live state from the current birth/data lifecycle. Primary Host STATE is retained by design. Persist process history in a historian with explicit quality and late-data rules.

How do I verify a product is Sparkplug compatible?

Check the Eclipse Sparkplug compatible-software list for the exact named product and version that passed the Technology Compatibility Kit. If the deployed version is not listed, ask for its conformance evidence and run the project acceptance suite rather than inheriting a claim from another release.

Is Sparkplug a replacement for OPC UA?

No universal replacement claim is justified. OPC UA provides a broad information and service architecture, while Sparkplug standardizes a particular MQTT-based industrial state model. Gateways can map between them, but the project must document datatype, quality, namespace, security and lifecycle semantics preserved or changed.

How should Sparkplug metric names and aliases be managed?

Govern metric names as durable interface identifiers with type, unit, source, range, quality and revision. Treat aliases as compact mappings established by the current birth, not durable historian IDs. Test uniqueness, reconnect and rebirth behavior.

Can a browser simulator validate Sparkplug compatibility?

Not unless it explicitly implements and tests the broker, Sparkplug payload, topic, session and state requirements. The linked simulator practices generic PLC fault-state reasoning only. Compatibility requires the exact Edge Node, broker, host and PLC path with captured Sparkplug evidence.

Primary sources and review trail

Reviewed 31 August 2026. Product versions, compatibility listings and cybersecurity guidance can change; preserve controlled copies and recheck before design approval.

1. Eclipse Sparkplug specification landing page — current published revision and specification access.
2. Eclipse Sparkplug 3.0 version page — ratified revision record.
3. Sparkplug Specification 3.0.0 PDF — normative roles, namespace, payload, message and state requirements.
4. Eclipse Sparkplug FAQ — MQTT relationship, interoperability and scope.
5. Eclipse Sparkplug compatible software — exact product/version TCK listings.
6. How to get a Sparkplug product listed — Technology Compatibility Kit process.
7. Eclipse Tahu project — official open-source Sparkplug implementation and tooling project.
8. OASIS MQTT Version 5.0 standard — MQTT session, Will, QoS, retained and protocol behavior.
9. OASIS MQTT Version 3.1.1 standard — MQTT 3.1.1 protocol and Clean Session semantics.
10. NIST SP 800-82 Rev. 3 — current OT security guidance and operational constraints.
11. ISA/IEC 62443 series overview — industrial automation and control system security lifecycle and roles.
12. OPC UA Part 14: PubSub — primary reference for the separate OPC UA PubSub model used in comparisons.

Scope and limitations

The examples are a design pattern, not a product configuration recipe. Verify the exact Sparkplug revision, MQTT version, Edge Node, broker, Primary Host, PLC driver, firmware, operating system, certificates, ACL syntax, metric features, timestamp source, store-forward behavior, redundancy and safety architecture. Topic strings and example metric types are illustrative except where identified as specification structures. Do not deploy remote commands or physical tests without authorized change control, risk assessment, isolation, qualified personnel and the site’s safety procedures.