What Are Sparkplug DDATA and NDATA Messages?
The birth certificates get all the attention, but the DDATA and NDATA messages are where the real telemetry lives. After a device and node have announced themselves, these are the messages that carry every subsequent metric change. For an engineer sizing a link or debugging why a value is not updating, understanding the data messages is essential. This page explains what DDATA and NDATA carry and how they rely on the birth that came before.
Sparkplug DDATA and NDATA in one line: In Sparkplug B, DDATA and NDATA are the ongoing data messages: DDATA carries metric value changes for a device, and NDATA carries them for the edge node itself. They follow the birth certificates and, because those births already declared every metric, the data messages send only what changed, typically identifying metrics by alias rather than name to keep the payload small.
Data Messages Depend on the Birth That Preceded Them
A DDATA or NDATA message is only meaningful in the context of the birth that came before it. The device's DBIRTH, and for the node its NBIRTH, declared the full set of metrics with their names, datatypes, and aliases. A subsequent DDATA does not redeclare that structure; it references it. This is why a consumer that receives a DDATA before it has seen the matching birth cannot interpret it, and why the protocol is strict about birth ordering. The data message is a delta against a state the birth established.
The split between DDATA and NDATA mirrors the node-versus-device hierarchy. An NDATA reports changes to metrics that belong to the edge node itself, things like a gateway's own diagnostics or status. A DDATA reports changes to metrics belonging to a specific device sitting behind that edge node, addressed within the node's topic namespace. This is the same distinction that runs through the whole Sparkplug model, explained in the edge node and device hierarchy, and it determines which topic a given data change is published on.
Because the births carry the full metric definitions, the data messages can be lean. A DDATA typically identifies each changed metric by its numeric alias rather than repeating its full string name, and it includes a timestamp and the new value. That leanness is the whole efficiency argument for Sparkplug over naive MQTT: you pay the cost of a full description once at birth, then every steady-state update is small, which is what makes it viable on a metered cellular link.
Report by Exception and Why Values Go Quiet
Sparkplug data messages are meant to be sent on change, a discipline called report by exception. A metric that is not changing generates no DDATA, so the link carries traffic only when the process actually moves. This is efficient, but it changes how you reason about a quiet value. In a polled system, no update means the poll failed; in Sparkplug, no update legitimately means the value has not changed, and distinguishing the two is a common source of confusion.
This is exactly why the birth-death lifecycle matters so much. Because a healthy but unchanging metric is silent, you cannot use silence on one metric to infer the node is alive. Liveness comes from the node lifecycle, the birth and death certificates and the underlying keepalive, not from the data stream. A consumer trusts that a metric holds its last reported value until either a new DDATA changes it or a death certificate invalidates the whole node's state. Conflating a quiet metric with a dead node leads to false alarms.
When you are debugging a value that is not updating on a SCADA screen, the report-by-exception model tells you where to look. First confirm the node is alive through its birth and the absence of a death; if it is alive, the value may simply not have changed. If you suspect the consumer has lost track of state, the remedy is a rebirth so the node reissues its full birth and current values, which resynchronizes the consumer. This is why the rebirth request exists and why it is the standard recovery when data and state have drifted apart.
Frequently Asked Questions
What is the difference between DDATA and DBIRTH?
DBIRTH is the device's birth certificate, sent once when the device comes online, and it declares the full set of metrics with their names, datatypes, and aliases along with current values. DDATA is sent repeatedly afterward and carries only the metrics that have changed, usually identified by alias rather than name. In short, DBIRTH establishes the complete metric structure and baseline; DDATA reports incremental changes against that baseline, which is what keeps steady-state traffic small.
Why would a Sparkplug metric stop sending DDATA?
Most often because it has not changed. Sparkplug uses report by exception, so a metric that holds steady simply generates no data messages, and that silence is normal rather than a fault. The value the consumer holds remains valid until a new DDATA updates it or the node issues a death. If you genuinely suspect the consumer and node have lost sync, the correct action is to trigger a rebirth so the node reissues its full birth and current metric values, resynchronizing both ends.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- MQTT Version 5.0 (OASIS Standard) - OASIS (v5.0, 2019)
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.