How to Plan DNP3 Integrity and Event Poll Rates
DNP3 gives a master two very different questions it can ask an outstation: what changed (an event poll) and what is the value of everything (an integrity poll). Most polling problems - overflowing buffers, saturated radio channels, cellular bills that double - come from using the wrong question for the job or asking either one at the wrong rate. This guide lays out a working strategy for setting both rates deliberately, especially on bandwidth-constrained links.
DNP3 Poll Rate Strategy in one line: A sound DNP3 poll strategy uses frequent, cheap event polls (or unsolicited reporting) as the routine data path, and reserves the expensive integrity poll for the moments it is designed for: connection establishment, recovery after an outage, response to a restart or buffer-overflow indication, and an occasional scheduled reconciliation. Event polls should run fast enough that no class buffer can fill between polls; integrity polls should be event-driven first and calendar-driven only as a backstop.
What You Need
You need three inputs per site: the realistic event generation rate (how many changes per hour the outstation produces under normal and upset conditions), the event buffer depth per class, and the link budget - what the channel can carry and, on metered cellular or satellite, what traffic costs. Poll strategy is the arithmetic connecting these three.
You also need to know what an integrity poll costs on your point counts. Reading the full static image of a large outstation is a substantial transfer; on a fast network it is trivial, on a shared radio channel it can monopolize the medium for a noticeable stretch. The role of the integrity poll is covered separately; here we decide when to spend it.
Make Event Collection the Routine Path
Set the event poll cadence from the buffer arithmetic: the interval between event polls must be comfortably shorter than the time the busiest class buffer takes to fill during an upset, because upsets are exactly when you cannot afford to lose events. A site that generates a burst of events during a trip needs its urgent class collected often enough that the burst fits in the buffer between polls, with margin.
On constrained links, consider replacing fast event polling with unsolicited reporting, where the outstation pushes events as they happen and the master's polling drops to a slow supervisory heartbeat. This is usually the most bandwidth-efficient design for quiet sites that occasionally burst, which describes most remote telemetry. The trade is configuration complexity at both ends, and you still keep a slow backup poll in case the unsolicited path silently degrades.
Reserve Integrity Polls for Recovery, Not Routine
Fire an integrity poll on the events that genuinely require full reconciliation: when a session is established, when communication is restored after an outage, when the outstation signals a restart (its event history context is gone), and when a buffer overflow indication tells you events were lost and the current image is the only way to re-baseline. These triggers are worth automating in the master rather than leaving to operator memory.
Then add a scheduled integrity poll as a backstop against silent divergence - once a day or a few times a day is a common choice, and on very constrained links some sites go longer. The backstop exists because event-driven synchronization can drift if an event is missed without any flag being raised; the periodic full read bounds how long such divergence can persist. What you should not do is run integrity polls every few minutes as the primary data path - that design pays the full-image cost continuously to learn what event collection would have told you for a fraction of the traffic.
Verifying the Result
Prove the strategy with the outstation's own indications. Over a representative period including at least one upset, the buffer overflow bit should never set - if it does, event collection is too slow for the event rate, and the fix is faster polling of that class, unsolicited reporting, wider deadbands, or a deeper buffer. Meanwhile the link utilization should leave headroom for the integrity polls when they do fire, including the worst case of every site reconnecting after a regional outage.
Also check the recovery path deliberately: drop a link on purpose, restore it, and confirm the master runs its integrity poll and the historian shows the buffered events backfilled around the outage. A strategy that has never been tested against an actual outage usually has one surprise in it, and it is better to find it on a test day. The polling load numbers to watch during all of this are the same ones discussed in round-trip time and SCADA polling.
Common Mistakes
The most expensive mistake is the minute-by-minute integrity poll as the primary acquisition method - it works on the bench, then saturates the radio channel or the data plan in production while adding nothing that event collection would not have delivered. Its mirror image is never integrity polling at all, which leaves the master's database hostage to a perfect, gapless event stream that no real link delivers forever.
The subtler mistakes: forgetting that a master restart also needs an integrity poll (the outstation did not restart, but the master's image is cold); polling all classes at one rate, which erases the priority scheme the classes were meant to create; and sizing everything for normal days when the design case is the upset - the storm, the trip cascade, the reconnect surge - because that is when the data matters most and the buffers are fullest.
Frequently Asked Questions
How often should a DNP3 master run an integrity poll?
Event-driven first: on session establishment, after outages, after a restart indication, and after a buffer overflow. On top of those triggers, a scheduled backstop - commonly somewhere between a few hours and daily, and site-specific on constrained links - bounds how long any silent divergence can persist. If you find yourself scheduling integrity polls every few minutes, the event collection design needs attention instead.
Can unsolicited reporting replace event polling entirely?
Nearly, but keep a slow backup poll. Unsolicited reporting pushes events as they occur and suits quiet remote sites well, but the path can degrade silently - a half-configured endpoint or a lost enable after a restart leaves events waiting in the buffer. A supervisory poll every few minutes to tens of minutes catches that failure mode cheaply while the unsolicited path carries the routine load.
Does an integrity poll retrieve the events I missed?
It does both jobs at once: a standard integrity poll requests the event classes along with the full static image, so pending buffered events are delivered and the current values re-baseline the database. What it cannot do is recover events the outstation already discarded in a buffer overflow - after an overflow the integrity poll gives you a correct present, but the lost interval stays lost.
Sources and verification
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.
- Overview of DNP3 (IEEE Std 1815) - DNP Users Group
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
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.