What Is Report by Exception in Sparkplug?
Report by exception is the idea that quietly powers Sparkplug's efficiency: send a value only when it changes, not on a fixed schedule. For an engineer used to polling, it is both a huge bandwidth win and a shift in how you interpret a quiet tag. This page explains what report by exception means, how a deadband decides what counts as a change, and how it changes the way you reason about liveness and stale data.
Report by Exception (Sparkplug) in one line: Report by exception is the practice of publishing a metric only when its value changes beyond a defined threshold, rather than on a fixed polling interval. In Sparkplug, an edge node sends a data message for a metric when it moves past its deadband and stays silent otherwise, which sharply reduces link traffic but means a quiet metric is presumed unchanged, not failed.
Publish on Change Instead of Polling on a Clock
Traditional SCADA polling asks every device for every value on a fixed cycle, whether or not anything moved, which means the link carries the same volume of traffic on a dead-calm process as on a runaway one. Report by exception inverts this: the edge node holds the current value and publishes only when the value changes. A tank level sitting still generates no traffic; the same level ramping during a fill generates a stream of updates. Traffic now tracks process activity rather than a clock, which is the fundamental efficiency argument.
This is a natural fit for the publish/subscribe model and for a metered link. Because Sparkplug rides on publish/subscribe over MQTT, the node simply does not publish when there is nothing to say, and no consumer wastes a request asking. On a cellular plan where every byte is billed, sending data only on genuine change is the difference between a workable data budget and a painful one, which connects directly to managing protocol overhead on constrained links.
The mechanism that decides what counts as a change is the deadband. Rather than publishing for every least-significant-bit flicker of a noisy analog reading, a metric is configured with a threshold, and only a change larger than that threshold triggers a publish. Set the deadband too tight and a noisy signal floods the link with meaningless updates; set it too loose and you miss real movement. Tuning the deadband per metric is where report by exception goes from a nice idea to a well-behaved system.
How Silence Changes What You Can Infer
The subtle cost of report by exception is that silence becomes ambiguous unless you handle liveness separately. In a polling world, a value that stops arriving means the poll failed, a clear fault signal. Under report by exception, a value that stops arriving almost always means it simply has not changed, which is entirely healthy. You cannot look at one metric's quiet stream and conclude anything about whether the node is alive.
Sparkplug solves this deliberately by separating data from liveness. Node health comes from the birth and death certificates and the underlying MQTT keepalive, not from the data flow. The consumer trusts that a metric holds its last reported value until a new data message changes it or a death certificate invalidates the node's whole state. This is precisely why the NBIRTH and NDEATH lifecycle is not optional decoration; it is the only thing that lets a consumer distinguish a calm process from a dead node.
This also drives the need for a way to resynchronize. If a consumer joins late, or loses track of state, it has no polling loop to fall back on to re-read everything, so it asks the node to reissue its full picture through a rebirth. The node then republishes its birth with current values for every metric, giving the consumer a fresh baseline. Understanding report by exception is therefore incomplete without understanding both the birth-death liveness channel and the rebirth resynchronization path, because those are what make on-change reporting safe.
Frequently Asked Questions
How does report by exception save bandwidth compared to polling?
Polling requests every value on a fixed cycle regardless of whether anything changed, so a steady process still generates constant traffic. Report by exception publishes a metric only when it actually moves past its deadband, so a stable value generates no traffic at all and the link carries data in proportion to real process activity. On a metered cellular link, where you pay per byte, sending only genuine changes rather than repeatedly re-reporting unchanged values is a large and direct saving.
If a metric goes quiet, how do I know the node is not just dead?
You check the node's liveness separately from its data. Under report by exception a quiet metric normally just means the value has not changed, so you cannot infer a fault from silence alone. Sparkplug provides liveness through the node birth and death certificates and the MQTT keepalive: as long as the node's birth stands and no death has been issued, the node is alive and the quiet metric is simply steady. If you doubt the consumer's state, trigger a rebirth to get a fresh baseline.
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.