How to Configure Sparkplug Metric Birth Certificates
In Sparkplug, the birth message is a contract: it declares every metric an edge node or device will ever report, with its name, data type, and starting value, so that later data messages can be lean. Get the birth wrong - a missing metric, a wrong type, a mismatched alias - and consumers either reject the data or misinterpret it. This page walks how to build a correct, complete birth certificate so the data that follows is trusted.
Configure Sparkplug Metric Birth Certificates in one line: To configure Sparkplug metric birth certificates, list every metric the node or device will ever publish in its birth message, each with a unique name, correct data type, and initial value, and assign each a stable alias. Later data messages then carry only the alias and value. Any metric not declared at birth cannot be reported until the next birth.
Declare Every Metric the Node Will Ever Report
The birth message must contain the complete set of metrics the node or device can publish - not a subset, not the ones currently changing, but every one. A consumer builds its model of the node entirely from the birth, so a metric absent from the birth does not exist as far as the consumer is concerned, and a later data message referencing it is invalid. Enumerate the full metric list before you build the birth.
This completeness is the whole point of the birth-then-data pattern: a heavy, complete birth buys lean data messages afterward. The birth and its counterpart death frame the node's life - see the Sparkplug NBIRTH and NDEATH message. Treat the birth as the authoritative schema for everything that follows.
Set the Correct Data Type on Each Metric
Every metric in the birth carries a data type, and consumers use that type to decode all subsequent values for that metric. Declare an integer as an integer and a float as a float; a type mismatch between the birth and the real value corrupts decoding silently, because the consumer trusts the birth. This is the single most common source of garbage values downstream, and it is entirely preventable at birth time.
Be deliberate about types that look interchangeable, like an integer count versus a floating measurement, because the wire encoding differs and the consumer will not second-guess the birth. If a metric can hold special values, declare the type that represents them properly rather than forcing them into a type that cannot. The type you declare at birth is a promise the data must keep.
Assign Stable Aliases and Initial Values
Sparkplug lets data messages reference a metric by a numeric alias instead of its full name, which is where the bandwidth savings come from. Assign each metric an alias in the birth, and keep that alias mapping stable for the life of the session so data messages decode correctly. The alias-to-name binding lives only in the birth, so a consumer that missed the birth cannot decode aliased data - which is why a rebirth exists.
Give each metric a sensible initial value in the birth too, so a consumer has a complete starting snapshot the instant the node comes online, before any data message arrives. The alias and sequence discipline is detailed in the Sparkplug metric alias and sequence number; the birth is where that discipline starts.
Publish Data Messages Consistent With the Birth
After the birth, data messages should carry only metrics that changed, referenced by their birth-assigned alias, with values matching the declared type. Never introduce a new metric in a data message; if the node genuinely gains a metric, it must issue a fresh birth first. This is the rule consumers enforce, and violating it is what makes data get rejected despite the node appearing healthy.
Keep the node's device-level births consistent with its own node birth if the node hosts devices, because the hierarchy is declared top-down. The node and device birth structure is covered in the Sparkplug edge node and device hierarchy. A clean, consistent birth-then-data stream is what a Sparkplug consumer is built to trust.
Verify the Birth Against a Consumer
Bring the node online and watch a Sparkplug-aware consumer build its metric model from the birth. Every metric you intended should appear with the right type and initial value; a missing one or a wrong type shows here, before it corrupts a historian. Then push a data change on one metric and confirm the consumer decodes it correctly by alias - that proves the alias mapping and type both took.
Force a rebirth and confirm the consumer rebuilds cleanly, because a consumer that connects mid-session relies on the rebirth to get the schema it missed. If the rebirth does not reproduce the same complete metric set, your birth generation is not deterministic and a late-joining consumer will be broken. A birth that survives this check is one downstream systems can rely on.
Common Mistakes
The top mistake is an incomplete birth that omits metrics the node later tries to report in data messages, which consumers reject. The second is a data-type mismatch between the birth declaration and the actual value, silently corrupting everything downstream because the consumer trusts the birth.
Another is introducing a new metric in a data message without a fresh birth, which is invalid by the specification. And do not let the alias mapping drift within a session; if aliases change without a rebirth, every data message decodes to the wrong metric. When the node's metric set genuinely changes, issue a new birth rather than patching around it.
Frequently Asked Questions
What must a Sparkplug birth message contain?
Every metric the node or device will ever report, each with a unique name, a correct data type, an initial value, and a stable alias. Consumers build their entire model of the node from the birth, so any metric absent from it cannot be reported in later data messages, and a wrong data type silently corrupts all values for that metric.
Can I add a new metric in a Sparkplug data message?
No. Data messages may only report metrics that were declared in the birth, referenced by their birth-assigned alias. If a node genuinely gains a metric, it must publish a fresh birth that includes the new metric before reporting it. Introducing an undeclared metric in a data message is invalid and consumers will reject it.
Why do downstream values look like garbage after a Sparkplug birth?
Almost always a data-type mismatch: the birth declared a metric as one type but the data carries another. Consumers decode every value using the type from the birth, so if the declaration is wrong the decode is wrong for that metric. Verify each metric's declared type against its real value by watching a consumer build its model from the birth.
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.