What Is a Sparkplug Dataset Metric?
Most Sparkplug metrics are a single scalar value, but sometimes the natural unit of data is a table: a recipe, a lookup curve, a list of active alarms. The dataset metric type carries exactly that, rows and typed columns, in one metric. For an engineer who has been tempted to flatten a table into dozens of numbered tags, this page explains what a dataset metric is and when it is the right tool.
Sparkplug Dataset Metric in one line: A Sparkplug dataset metric is a metric datatype that holds tabular data: a set of named, typed columns and a number of rows, all inside one metric. Instead of exploding a table into many scalar metrics, a dataset carries the whole structure, a recipe, a lookup curve, or a list of rows, in a single payload with the column names and types declared up front.
Tabular Data in a Single Metric
A dataset is one of the richer datatypes a Sparkplug metric can take. Where an ordinary metric carries a single value of a single type, a dataset declares a set of columns, each with a name and a datatype, and then carries some number of rows of values conforming to those column types. It is, in effect, a small typed table transmitted as one metric. The column definitions travel with the data, so a consumer knows how to interpret each cell without an external schema for that particular table.
The alternative, which many systems fall into, is to flatten a table into a scatter of scalar metrics: row1_col1, row1_col2, and so on, or a fixed grid of numbered tags. That works for a tiny fixed table but becomes unwieldy as rows vary, and it loses the fact that these values form one coherent structure. A dataset keeps the table together, which is both cleaner in the data model and more efficient than a flat explosion when the table has many cells. It sits alongside the other structured tools like the template, but for tabular rather than object-shaped data.
Because a dataset is still a metric, it flows through the same Sparkplug machinery. It is declared in the birth like any other metric and its changes ride in the ordinary data messages. That means a dataset can be updated as a unit when its contents change, which is often the natural granularity for a table: you replace the whole recipe or the whole active-alarm list rather than mutating individual cells across many separate metrics.
When a Dataset Is the Right Choice
Datasets suit data that is genuinely tabular and travels as a unit. A batch recipe with several ingredients and their setpoints is a natural dataset: the rows are the ingredients, the columns are the parameters, and you almost always want the whole recipe together. A lookup or characterization curve, pairs of input and output values, is another. A snapshot list, such as the currently active alarms with their tags and timestamps, fits too, because the list changes as a whole and each row shares the same columns.
The judgement call is whether the values really belong together as a table or are independent points that merely look tabular. A handful of unrelated readings that happen to sit near each other are better as individual scalar metrics, because each can change and be trended on its own, and forcing them into a dataset makes per-value trending and alarming awkward. Datasets shine when the row structure is meaningful and the table is consumed as a unit, not when you are just avoiding declaring several scalars.
There is also a consumer-side consideration. A dataset arriving as one metric must be unpacked by the consumer into its rows and columns, and how a cloud SCADA host presents that depends on the host understanding the dataset type. A host modelling Sparkplug faithfully can render a dataset as a table or drive a recipe screen from it; a naive consumer that only understands scalars may struggle. So choosing a dataset commits you to a consumer that handles the type, which is worth confirming when you design the payload, in the same spirit as agreeing a payload schema both ends honour.
Frequently Asked Questions
When should I use a dataset instead of many scalar metrics?
Use a dataset when the values form a genuine table that is consumed as a unit, such as a batch recipe, a lookup curve, or a snapshot of active alarms, where the rows share the same columns and you almost always want the whole thing together. Use separate scalar metrics when the values are independent points that each change and need to be trended or alarmed on their own. If forcing values into rows makes per-value trending awkward, they probably should be individual metrics, not a dataset.
Does a dataset metric carry its own column types?
Yes. A dataset declares its columns with names and datatypes as part of the metric, so the structure of the table travels with the data. A consumer receiving the dataset knows how many columns there are, what each is called, and what type each holds, without needing a separate schema definition for that specific table. This self-describing quality is consistent with the rest of Sparkplug, where metrics carry their own type information rather than relying on an out-of-band description.
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.