What Are Sparkplug Metric Datatype and Metadata?
One of Sparkplug's defining traits is that its payloads are self-describing: every metric declares its own datatype, and metrics can carry metadata about themselves. For an engineer used to a SCADA world of external tag dictionaries that must be kept in sync, this is a real shift. This page explains what a metric datatype is, what metadata a metric can carry, and why self-description matters at scale.
Sparkplug Metric Datatype and Metadata in one line: In Sparkplug B, every metric declares a datatype, such as an integer, floating point, boolean, or string type, so the consumer knows how to interpret its value. Metrics can also carry metadata and properties, extra descriptive fields about the metric itself. Because this information travels in the birth message, the payload is self-describing and a consumer needs no external tag dictionary to understand it.
Datatypes and Why They Travel with the Metric
Each Sparkplug metric has a declared datatype drawn from the set the specification defines: various sizes of signed and unsigned integer, single and double precision floating point, boolean, string, datetime, and the richer structured types like template and dataset. The datatype tells the consumer exactly how to decode the bytes for that metric's value, so a value is never ambiguous. A metric declared as a 32-bit integer is decoded as one; a float is decoded as a float. There is no guessing and no reliance on a side agreement about what type a tag is.
This is a deliberate contrast with protocols where the wire carries raw values and the meaning lives entirely in an external configuration. In such systems a mismatch between the device's idea of a register's type and the SCADA's idea of it produces silently wrong values, a classic and painful integration bug. Sparkplug moves the type declaration into the data itself, carried in the birth, so both ends necessarily agree. That self-description is a large part of why Sparkplug is attractive for unified namespace architectures.
Because the datatype is declared once in the birth and referenced by alias thereafter, you get the best of both worlds: full type clarity when the metric is introduced, and lean data messages afterward that need not repeat the type. The birth is the expensive, complete description; the steady-state data messages are compact deltas that lean on the type information the birth already established.
Metadata and Properties on a Metric
Beyond its value and type, a Sparkplug metric can carry additional descriptive information. A metric can include metadata and a set of properties, which are key-value descriptors attached to the metric, letting a metric describe attributes about itself such as engineering context or handling hints. These travel with the metric definition, so a consumer receives not just a number but the surrounding description that makes the number meaningful, without a separate lookup. The property mechanism is detailed further in the property set and property value structure.
The practical payoff is that a consumer can be far more generic. A cloud SCADA host receiving a self-describing Sparkplug birth can build its tag model automatically from the birth, because everything it needs, names, types, aliases, and descriptive properties, is present in the message. Compare that to a system where the host must be hand-configured with a matching tag database before it can interpret anything, and where every device change means a coordinated edit on both sides. Self-description collapses that coordination.
The discipline this asks of you is to treat the birth as the source of truth and to design metadata thoughtfully rather than dumping everything into properties. Because properties add bytes and are re-sent on every birth and rebirth, a lean, purposeful set of descriptors is better than an exhaustive one. But the core principle stands: a Sparkplug metric is meant to carry enough about itself that a well-built consumer needs no external dictionary, which is a meaningful reduction in the integration burden that dogs traditional tag-by-tag SCADA configuration.
Frequently Asked Questions
Why does a self-describing payload matter in SCADA?
Because it removes the fragile requirement to keep an external tag dictionary in sync on both ends. In many protocols the wire carries only raw values and the meaning lives in a configuration that the device and the SCADA must agree on exactly; a mismatch produces silently wrong readings. A self-describing Sparkplug payload carries each metric's name, datatype, and descriptive metadata in the birth, so a consumer can build its model from the data itself and both ends necessarily agree on what each value means and how to decode it.
Does declaring a datatype on every metric bloat the traffic?
Not in steady state. The full datatype declaration is carried once, in the birth message, along with each metric's name and alias. After that, ongoing data messages reference metrics by their compact numeric alias and do not repeat the type, so the routine telemetry stays lean. You pay the descriptive cost once when the metric is introduced and again only on a rebirth, while the frequent data messages that dominate link usage remain small deltas that rely on the type the birth already established.
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.