DNP3 does not just move raw numbers; it wraps every value in a description of what kind of point it is and how it is encoded. That description has two parts - the object group, which says what the data represents, and the variation, which says how it is packed. Choosing the right group and variation is not a formality: it decides whether a value arrives with a timestamp and quality flags or as a bare number, and that choice directly controls how much bandwidth a pipeline outstation's poll consumes.
DNP3 Object Groups and Variations in one line: In DNP3, an object group identifies the type of data - such as binary input, analog input, or counter - so a master knows whether a value is a status, a measurement, or a running total. A variation specifies how each value of that group is encoded, for example as a 16-bit or 32-bit number, with or without quality flags, and with or without a timestamp. Together the group and variation define both the meaning and the size of every point in a message, so selecting them controls the bandwidth an outstation poll uses.
DNP3 organizes points into groups by their fundamental type. A binary input group carries two-state statuses - a breaker open or closed, a pump running or stopped, an alarm set or clear. An analog input group carries measured values - a pressure, a flow, a temperature. A counter group carries accumulating totals - pulses from a meter, a volume totalizer that only increases. There are further groups for outputs, such as binary outputs for controls and analog outputs for setpoints, so the group tells a master at a glance what category of point it is dealing with.
The group is also what lets a master interpret a value correctly without external context. Because the object group travels with the data, a master receiving a binary input object knows to treat it as a status bit, and an analog input object as a measurement, rather than relying on a separate configuration to guess. This self-describing quality is part of what distinguishes DNP3 from a bare register protocol: the data carries its own type, so a point is unambiguous about whether it is a status, a reading, or a count.
Groups also split along a dimension that matters for polling: static versus event. A static object represents the current value of a point - what a measurement is right now - while an event object represents a change that occurred, often with a timestamp of when it happened. The same physical point therefore has both a static form, reported when a master asks for the present state, and an event form, reported when the point changes. Knowing which group and form a value is in tells a master whether it is looking at a present snapshot or a logged change.
Within a group, the variation specifies the encoding, and this is where size and richness are decided. An analog input, for instance, can be sent as a 32-bit integer, a 16-bit integer, or a floating-point value, and it can be sent either as a bare number or bundled with a quality flag byte that indicates whether the value is valid, over range, or from a device that has restarted. A variation that omits the flags is smaller on the wire; one that includes them is larger but tells the master more about the value's trustworthiness.
Timestamps are the other major axis a variation controls. An event variation can carry the absolute time the change occurred, which is invaluable for sequence-of-events reconstruction, but a timestamp adds several bytes to every point. A variation without a timestamp is more compact but loses the exact timing, so the master only knows a change happened, not precisely when. The choice between timestamped and non-timestamped variations is thus a direct trade between the fidelity of the event record and the bytes each event consumes.
Because a single group offers several variations, an engineer effectively picks the data's resolution and metadata per point type. A binary input might be sent as a single packed bit for compactness or with flags for diagnostics; an analog input might be a float with flags where precision and quality matter, or a smaller integer where they do not. The variation is the lever that tunes how much each point costs to transmit, and it is set knowingly rather than by default when bandwidth is scarce.
On a pipeline or wellsite outstation reached over a slow or metered link - a low-bandwidth radio, a cellular connection, or a satellite path - the size of each poll response matters directly, and group and variation are the main levers over that size. Requesting analog inputs in a variation that includes 32-bit precision, quality flags, and a timestamp produces a fat response; requesting a leaner variation without flags or timestamps produces a much smaller one. Multiplied across many points and many polls, the difference in variation choice becomes the difference between a link that keeps up and one that saturates.
This interacts with the static-versus-event nature of the groups to shape an efficient polling strategy. An outstation can report only the events that changed, in a compact variation, most of the time, and provide the full static picture of every point far less often. Choosing event variations that carry just enough - flags where quality genuinely matters, timestamps where timing genuinely matters, and nothing extra where it does not - keeps routine traffic small while preserving the information the operation actually needs. Over-specifying variations wastes bandwidth on metadata no one uses; under-specifying loses information that later turns out to matter.
A cloud SCADA such as Merobix polling a DNP3 outstation configures which object groups and variations it requests for each point, so the same platform can pull rich, timestamped analog data where a link affords it and lean status-only data where bandwidth is tight. Getting the group and variation right per point is what lets a remote pipeline outstation report meaningful data - accurate values, valid quality, useful timing - without overwhelming a constrained field link, which is exactly the balance that makes DNP3 well suited to sprawling, bandwidth-limited oil and gas telemetry.
An object group identifies the type of data - such as binary input for a status, analog input for a measurement, or counter for a running total - so a master knows what a point represents. A variation specifies how each value of that group is encoded, for example as a 16-bit or 32-bit number, with or without quality flags, and with or without a timestamp. The group gives meaning; the variation gives encoding and size.
Because the variation decides how many bytes each point takes on the wire. A variation that adds quality flags and an absolute timestamp is larger than one that sends a bare value, and that difference multiplies across every point in every poll. On a slow or metered outstation link, requesting richer variations than the operation needs inflates traffic, while leaner variations keep responses small - so variation choice is a direct lever over poll bandwidth.
A static object represents the current value of a point - what a measurement or status is right now - and is reported when a master requests the present state. An event object represents a change that occurred, often carrying a timestamp of when it happened, and is reported when the point changes. The same physical point has both forms, letting a master ask either for a present snapshot or for the log of recent changes.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.