Two small features do a lot of quiet work in Sparkplug B. The metric alias replaces a long tag name with a short number so that ongoing data messages stay tiny, which matters enormously on metered cellular links. The sequence number stamps every message with a rolling counter so the host can tell when one has gone missing or arrived out of order. This guide explains how aliases are established at birth and used thereafter, how the per-message sequence number works, how it triggers a rebirth when something is wrong, and why both features are central to running Sparkplug over constrained field connections.
Metric Alias and Seq Number in one line: In Sparkplug B, a metric alias is a short numeric identifier the edge node assigns to each metric in its NBIRTH so that later NDATA messages can refer to the metric by that small integer instead of its full name, cutting payload size. The sequence number is a rolling counter carried on every message that increments with each one, letting the host detect a missed or out-of-order message and request a rebirth to resynchronize.
Industrial tag names are descriptive and therefore long - something like a full path identifying a site, an asset, and a measurement can run to many characters. Repeating that name in every single data message would waste bandwidth, because the name never changes; only the value does. Sparkplug solves this with aliases. In the NBIRTH, where the node declares its full set of metrics, it assigns each metric a numeric alias alongside its full name. The birth message thus establishes a mapping: this long name corresponds to this short number, for the duration of the session.
Once that mapping is established, ongoing data messages - the NDATA messages that carry actual value updates - refer to each metric by its alias rather than its name. Instead of resending a long path with every reading, the node sends a small integer and the new value. The host, having recorded the alias mapping from the birth certificate, looks up which metric each alias refers to and applies the value correctly. The full names appear once, at birth; everything after that is lean. This is a straightforward but powerful compression: the expensive, unchanging part of the message is stated a single time and then referenced by a compact handle.
The savings compound with message rate. A node reporting many metrics frequently sends a great many NDATA messages, and shaving the name off each one removes a large, repeated cost. This is why aliases are not a mere convenience but a core efficiency mechanism in Sparkplug, and it is also why the all-metrics-at-birth rule matters: the alias mapping only works because the host received the complete name-to-alias correspondence in the NBIRTH before any aliased data arrived. A metric that never appeared at birth would have an alias the host cannot resolve.
Alongside aliases, every Sparkplug message carries a sequence number, usually written as seq. It is a rolling counter that increments with each message the node sends, wrapping around back to its start after it reaches the top of its range. The birth message begins the sequence, and each subsequent message - each NDATA, and the eventual NDEATH-related handling - carries the next value in order. The point of this counter is not to identify messages permanently but to let the host verify that it is receiving them in an unbroken chain.
The host tracks the sequence number it expects next. When a message arrives, the host checks whether its seq matches the expected value. If it does, all is well and the host advances its expectation. If the number has skipped ahead - the host expected one value but received a higher one - a message went missing somewhere in between. If it arrives out of the anticipated order, the host can tell that too. Either way, the host has detected that its picture of the node may no longer be complete or correct, purely from the arithmetic of a small counter, without needing any acknowledgment traffic flowing back to the node.
There is also a separate birth-death sequence number, often called bdSeq, that operates at the session level rather than the message level. It pairs each NBIRTH with the matching NDEATH so the host can be sure a death corresponds to the birth it thinks it does, which keeps session transitions from being confused when a node reconnects quickly. Between the per-message seq that guards the message stream and the bdSeq that guards the session lifecycle, Sparkplug gives the host two complementary ways to notice when something in the sequence of events has gone wrong.
When the host detects a sequence gap, it does not silently carry on with a possibly incomplete view. Instead it takes a defined recovery action: it requests a rebirth. A rebirth is a command the host sends asking the node to republish its full NBIRTH - the complete metric catalog with fresh values and the alias mapping restated - which resynchronizes the host from scratch. Once the node responds with a new birth certificate and restarts its sequence, the host has a clean, authoritative picture again and resumes normal processing. The missed-message problem is resolved not by trying to recover the lost message but by re-establishing the whole state.
This self-healing loop is what makes Sparkplug robust over exactly the kind of links industrial monitoring lives on. Cellular connections at remote sites drop packets, reconnect, and reorder traffic, and without a way to notice a missed message a host could quietly drift out of sync with a node - showing values that are subtly wrong because an update never landed. The sequence number turns that silent failure into a detected event, and the rebirth turns a detected event into an automatic correction. A cloud SCADA platform such as Merobix acting as a Sparkplug host uses this mechanism to keep its view of remote edge nodes honest: a gap in the sequence prompts a rebirth request, and the node's full state is restored rather than left to decay.
The two features reinforce each other in the field. Aliases keep the ongoing data stream small enough to be economical over metered cellular airtime, so a node can report frequently without running up cost or saturating a weak link. The sequence number ensures that this lean, high-frequency stream stays trustworthy, catching the inevitable losses that come with wireless links and healing them through rebirth. Together they let Sparkplug deliver both efficiency and reliability on connections that are neither fast nor perfectly stable - which is precisely the condition of most oil and gas telemetry from remote assets.
It is a short numeric identifier assigned to each metric in the NBIRTH so that ongoing NDATA messages can refer to the metric by that small integer instead of its full, long tag name. Because the name is stated only once at birth and referenced by the compact alias thereafter, data messages stay small. This cuts bandwidth substantially, which matters a great deal on metered or constrained cellular links.
Every message carries a rolling sequence number that increments by one each time the node sends a message. The host tracks the value it expects next and compares it to what arrives. If the number skips ahead, a message was lost in between; if it arrives out of order, the host can tell that too. The gap is detected purely from the counter, with no acknowledgment traffic needed back to the node.
It requests a rebirth. The host asks the node to republish its full NBIRTH - the complete metric catalog, current values, and alias mapping - which resynchronizes the host from scratch and restarts the sequence. Rather than trying to recover the individual missed message, Sparkplug re-establishes the whole node state, so the host returns to a clean, authoritative picture and resumes normal processing.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.