What Is a DNP3 Data Set?

Back to Blog

Bundling Mixed Values Into One Object

Core DNP3 objects are homogeneous: a group 30 analog input variation carries analog values, a group 1 binary input carries statuses. A data set breaks that mold by letting a device define a structure that holds a mix - for example an analog measurement, a status bit, a timestamp, and a text label - and report them together as one addressable object. This is useful when a set of values only makes sense as a unit and you want them to travel and be timestamped together.

The layout is not fixed by the standard; it is described by the device using a data set prototype and a data set descriptor. The prototype names the element types and order, and the descriptor ties the prototype to actual point sources. The present-value and event data set objects then carry the live data laid out per that definition. Because the structure is self-described, a master that understands data sets can parse a device's custom bundle without hard-coded knowledge of it, much as the object group and variation scheme makes ordinary points self-describing.

When Data Sets Are Worth It

Data sets add configuration overhead: you have to define prototypes and descriptors on both ends, and not every master fully supports them. For most SCADA point maps, plain analog and binary objects are simpler and entirely sufficient, and the point index scheme keeps them organized without any custom structures. So the default answer for a typical outstation is that you probably do not need data sets.

Where they earn their keep is when a device genuinely produces compound records - a metering event that must carry a value, a quality flag, and a timestamp as an inseparable unit, or a structured report that should stay together. In those cases a data set delivers the whole record with one definition and one event, rather than forcing the master to correlate several separate points by timestamp. The judgment call is whether the coupling of the values justifies the extra definition work, which is a device-specific decision to make against the outstation's device profile.

The Four Object Groups Behind a Data Set

Data sets occupy four dedicated object groups in the standard, and the division of labor between them is what makes the feature self-describing. Groups 85 and 86 carry the definitions; groups 87 and 88 carry the data laid out according to those definitions.

Group	Role
85	Data set prototype - the reusable element layout, naming the types and their order
86	Data set descriptor - binds a prototype to the device's actual data sources
87	Present value - the current contents of a data set, read on demand
88	Event - a snapshot of the data set captured when its trigger condition occurs

The reading order follows from the table: a master that wants to use a device's data sets first reads the group 85 prototypes and group 86 descriptors to learn the structures, and only then can it parse the group 87 and 88 payloads. Skipping that discovery step is why a generic poll of an unfamiliar device can return data set bytes the master cannot interpret.

How Data Set Events Reach the Master

Once defined, a data set event behaves like any other DNP3 event. The snapshot is assigned to an event class, held in the outstation's event buffer, and delivered either when the master runs a class data scan or through an unsolicited response, with the same confirmation and retry behavior as ordinary events. That is the payoff of the design: the exotic part is only the structure definition, while the transport machinery is the one integrators already know.

The practical wrinkle is buffer arithmetic. A data set event is one logical event but carries the whole bundle, so each occurrence consumes considerably more buffer space than a single analog or binary event. On a device that generates data set events at any real rate, buffer capacity and the polling or unsolicited strategy need to be checked together, or a communications outage will overflow the buffer and drop compound records that cannot be reconstructed from other points.

Checking Support Before You Commit

Data sets only work when both ends implement them, and support is far from universal - many otherwise complete master drivers stop at the core static and event groups. Before designing a map around data sets, confirm two documents: the outstation's device profile, which states whether groups 85 through 88 are implemented and how many data sets the device supports, and the master or gateway driver's conformance documentation for the same groups. A short bench test that reads the prototypes and descriptors with a protocol test tool settles the question faster than any datasheet reading.

It is also worth agreeing on a fallback before committing. Most devices that offer data sets can expose the same values as individual points; mapping them that way sacrifices the atomic, single-timestamp delivery but works with every master. Deciding up front which mode the integration uses - and recording the choice in the point map - avoids the awkward mid-project discovery that one end speaks a structure the other cannot parse.

Frequently Asked Questions