How to Verify a Sparkplug Birth Certificate

Back to Blog

Capture the Birth With a Plain MQTT Client

Start by observing the raw traffic, not the polished SCADA view. Connect a plain MQTT client to the same broker and subscribe broadly enough to catch the node's birth topic, then trigger the node to connect or reconnect so it issues a fresh NBIRTH. Watching at the MQTT level, below your SCADA host's interpretation, is essential because it shows you what the node actually published rather than what your host chose to display, which is exactly the layer where a misconfiguration hides.

Confirm the birth lands on the topic you expect from your namespace design. The NBIRTH must carry the correct namespace element, group identifier, and edge node identifier per your namespace design. If the birth arrives under an unexpected group or node identifier, you have found the problem before looking at a single metric: the node is misconfigured or duplicated, and no downstream check will make sense until the topic is right.

Confirm Every Metric Is Declared Correctly

Open the NBIRTH payload and check that it declares the full set of metrics you expect. The birth is the complete manifest, so every metric the node will ever report by alias must appear here with its name, its correct datatype, and its assigned alias. A metric missing from the birth cannot be sent later, and a metric present with the wrong datatype will be decoded wrongly by every consumer. This is the single richest source of commissioning bugs, so check it carefully against your point list.

Verify the datatypes specifically, because a type mismatch produces values that look plausible but are wrong. A metric that should be a floating-point reading declared as an integer, or a signed value declared unsigned, yields a number that is not obviously broken yet is incorrect, which is far more dangerous than an outright failure. The birth is where these types are pinned, as covered in metric datatype and metadata, so confirming them here prevents a class of silent errors downstream.

If you use devices behind the node, check that each device also issues a DBIRTH declaring its metrics, not just the node's NBIRTH. A node can be born correctly while a device behind it is misconfigured, so walk each expected device's birth the same way. Confirm that device identifiers match your namespace and that each device's metric manifest is complete, since a consumer will mark a device's metrics stale or uninterpretable if its birth is absent or wrong.

Verifying the Result

The decisive ordering check is that the birth precedes any data. A well-behaved node publishes its NBIRTH, and each DBIRTH, before it sends any DDATA or NDATA, because the data messages are meaningless without the manifest and aliases the birth established. Watching the message stream, you should see births first, then data. If a data message arrives before the corresponding birth, a consumer has nothing to interpret it against, and you have found a real defect in the node's startup sequence.

Finally, sanity-check the sequence and birth-death numbering. The birth should start the sequence cleanly and carry a bdSeq that will match the node's death, the pairing explained in bdSeq and seq numbering. A birth with these in order, on the right topic, with a complete and correctly typed metric manifest, published ahead of any data, is a birth you can trust, and your consumer should now build a correct model from it.

Common Mistakes

The frequent mistakes cluster around trusting the wrong layer and skipping the ordering check. Engineers verify against the SCADA host's rendered display instead of the raw MQTT stream, so they see the host's guess rather than the node's actual birth and miss a subtle topic or type error. They check that metrics appear but not that their datatypes are right, so a value that is wrong-but-plausible slips through. They forget to confirm each device's DBIRTH, catching only the node. And they never confirm births precede data, so a startup-ordering defect that only bites on a fast reconnect goes unnoticed until it causes a mysterious consumer error in production.

Frequently Asked Questions