DNP3 does not treat all data the same way. It divides a device's data into classes - a static class that holds current values and three event classes that hold changes as they happen. This structure is the reason DNP3 can report events efficiently while still guaranteeing a reliable full picture, and it is assumed by the integrity poll and unsolicited reporting without those pages ever defining it. This page explains what Class 0, 1, 2, and 3 mean, how a class poll works, and why the class model underpins DNP3's efficiency.
DNP3 Class 0/1/2/3 Data in one line: In DNP3, Class 0 is the static data - the current value of every point - while Classes 1, 2, and 3 are event data, the record of changes that have occurred since the master last read them. A master can request a specific class, so a Class 1/2/3 poll retrieves only recent events rather than every value, which is far more efficient than reading everything. The three event classes exist so the engineer can assign different priorities to different points, letting the most important changes be reported first or most often.
The heart of the DNP3 class model is the split between static and event data. Static data, Class 0, is the present state of the world: the current value of every point in the device, right now. Event data is different - it is a log of things that changed. When a point's value moves past a configured threshold or a status flips, the device records that change as an event and holds it in an event buffer. The event captures not just the new value but when it happened, so no transition is lost between reads.
This distinction is what makes DNP3 efficient over slow links. A master does not need to re-read every value on every poll if nothing changed; it only needs to know what changed. By reading the event classes, the master pulls just the transitions that occurred since last time, along with their timestamps, and reconstructs an accurate history without transferring the entire dataset repeatedly. On a busy device where most points are steady, this is enormously less traffic than polling all values constantly.
The event buffer is where those changes wait to be collected. Each event class has its own buffer holding the unread events assigned to it. When the master reads a class, the device delivers the buffered events and clears them, ready to accumulate the next batch. This buffering is also why the integrity poll exists as a backstop: if a buffer overflows because events piled up faster than the master read them, some transitions can be lost, and only a full read of the static Class 0 data guarantees the master's picture is correct again.
Why three event classes instead of one? So the engineer can prioritize. Every event point is assigned to Class 1, 2, or 3, and the assignment is a way of grouping data by importance or urgency. A common pattern puts the most critical or time-sensitive points in one class and routine points in another, so the master can read the urgent class more often, or the device can report it first, without dragging along the less important changes. The three classes are not fixed in meaning by the protocol; their significance is set by how the engineer maps points to them.
A class poll is a request for the events in specific classes. The master might poll Classes 1, 2, and 3 together on a fast timer to collect all recent changes, or poll only the high-priority class more frequently and the others less often. Because the poll asks for events rather than static values, it returns a compact set of just-what-changed data, which is the efficient day-to-day mode of operation. This is fundamentally different from reading Class 0, which returns every current value regardless of whether anything changed.
This is precisely where the class poll and the integrity poll diverge. A class poll normally reads the event classes to get recent changes efficiently. The integrity poll reads Class 0 - all static data - plus the event classes, giving a complete snapshot that re-synchronizes the master with the device's true state. The integrity poll runs on a slow timer and after disruptions like a restart or a reported buffer overflow, precisely because it is the heavier, comprehensive read that backstops the lightweight event-based polling the rest of the time. Understanding the classes is what makes that division of labor make sense.
For remote oil and gas telemetry over cellular or radio links, the DNP3 class model is a strong fit because it minimizes traffic while preserving a complete, timestamped event history. Configuring a device so that critical points - a high-high pressure, a valve trip - land in a high-priority event class means those changes can be reported promptly and preferentially, while slow, routine points sit in a lower class that is collected less aggressively. The class assignment becomes a tool for spending scarce bandwidth on the data that matters most.
A cloud SCADA platform such as Merobix acting as a DNP3 master uses class polls for the efficient, routine collection of events and periodic integrity polls to guarantee the picture stays correct after outages or buffer overflows. That combination gives the best of both: normal operation is lean, sending only changes, while the periodic full read ensures a dropped event or a device restart never leaves the platform's view of the field quietly wrong. On unreliable remote links, that self-correcting behavior is exactly what keeps the data trustworthy.
The practical upshot for field operations is that DNP3's structure aligns well with how remote sites actually behave - long stretches of little change punctuated by important events, over links that cannot afford constant full reads. Assigning points to sensible classes and letting the master mix class polls with integrity polls means a well site sends compact, prioritized updates most of the time and a guaranteed full snapshot periodically, which is a far better use of a cellular or radio channel than polling everything on a timer.
Class 0 is static data - the current value of every point in the device. Classes 1, 2, and 3 are event data - the record of changes that occurred since the master last read them, held in event buffers with timestamps. Reading Class 0 gives a full current snapshot, while reading the event classes gives only what changed, which is far more efficient on slow links.
A class poll typically reads the event classes to collect recent changes efficiently, sending only what moved. An integrity poll reads Class 0 static data plus the event classes to produce a complete snapshot that re-synchronizes the master. Class polls are the lightweight routine mode; the integrity poll is the heavier periodic backstop that runs on a slow timer and after restarts or buffer overflows.
The three event classes let the engineer group points by importance and assign them different priorities. Critical or time-sensitive points can be placed in a class that is polled more often or reported first, while routine points sit in a lower-priority class collected less aggressively. The protocol does not fix each class's meaning; it is defined by how points are mapped to them.
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.