What Is a Sparkplug Property Set and Property Value?
Sparkplug lets a metric carry more than a number: a property set attaches named, typed descriptors that ride with the metric. For an engineer who wants engineering units or a range to travel with a reading instead of living in a separate config, the property set is the mechanism. This page explains what a property set and property value are, how they attach to a metric, and where they help without bloating the payload.
Sparkplug Property Set in one line: A Sparkplug property set is a collection of named property values attached to a metric, where each property value is a typed piece of metadata such as an engineering unit, a range limit, or a quality indicator. It lets descriptive attributes travel with the metric in the payload, so a consumer receives the context that makes a raw value meaningful without consulting an external configuration.
How a Property Set Attaches to a Metric
A property set is a structured collection of key-value pairs bound to a metric, where each key is a name and each value is a typed property value. The property values are themselves typed, so a numeric range limit is carried as a number and a unit label as a string, which keeps the metadata as unambiguous as the metric's own value. This is the mechanism that fleshes out the self-describing nature of Sparkplug metrics, extending the basic datatype and metadata a metric already carries.
The natural things to put in a property set are the descriptors that make a reading interpretable and that you would otherwise store in a separate tag database. Engineering units are the canonical example: a value of 42 means little until you know it is degrees Celsius or bar. Range or scale limits let a consumer render a bar graph or validate a value. A quality or status descriptor can travel alongside the value. Carrying these as properties means the consumer gets them in the same message as the value, not from a config that must be kept in step.
Because properties are declared with the metric, typically in the birth, a consumer building a tag model can populate units, ranges, and descriptions automatically from what it receives. This is the same collapse of coordination that makes Sparkplug attractive generally: instead of hand-entering units for every tag on the SCADA side to match the device, the units arrive with the metric. It complements the reusable structure of a template, where each member metric can carry its own property set.
Using Property Sets Without Bloating the Payload
The practical tension with property sets is the same as with any metadata: they add bytes, and those bytes are re-sent whenever the metric is redeclared in a birth or rebirth. On a metered cellular link this is not free, so the goal is a purposeful set of properties rather than an exhaustive one. Units and a range are almost always worth carrying; a long free-text description repeated for thousands of metrics on every rebirth may not be. Choosing what earns its place is part of good payload design.
The saving grace is that properties, like the metric's full description, live in the birth and not in every data message. Steady-state data messages carry values by alias and do not repeat the property set, so the ongoing telemetry stays lean regardless of how much descriptive metadata a metric carries. The cost of a rich property set is paid at birth and rebirth, which are infrequent compared to the flow of data, so a thoughtful set of properties is usually affordable.
The deeper value is architectural. When units, ranges, and quality descriptors travel with the data, a whole class of integration errors disappears, the ones where the device thinks a value is in one unit and the SCADA renders it in another because two separate configurations drifted apart. This is why property sets fit so well into a unified namespace approach, where the data itself is meant to be self-sufficient and consumable by many applications without each one needing a private copy of the tag dictionary.
Frequently Asked Questions
What kind of information goes in a Sparkplug property set?
Descriptive attributes about the metric that make its value interpretable: engineering units, range or scale limits, and quality or status descriptors are the common ones. Each is a typed property value, so a unit is carried as a string and a numeric limit as a number. The idea is to attach the context you would otherwise keep in a separate tag database directly to the metric, so a consumer receives units and ranges in the same message as the value rather than from a configuration it must keep synchronized.
Do property sets slow down routine telemetry?
No, because they are carried in the birth and rebirth, not in every data message. A metric's property set is declared when the metric is introduced, and ongoing data messages reference the metric by alias and carry only its changing value, so the steady stream of telemetry stays lean regardless of how rich the property set is. The cost of the descriptors is paid at birth and on the occasional rebirth, which are infrequent compared with the flow of data messages that dominate link usage.
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.