How to Choose Report by Exception or Polling
Report by exception and polling are two ways for a SCADA master to get data, and choosing between them is really a choice about where you spend bandwidth and how you know a device is still alive. This guide is for the engineer configuring the update model on a remote site, weighing a jumpy cellular data bill against the need to notice a dead RTU quickly. It lays out the decision per point, the comparison side by side, and the pitfalls that bite when you pick the wrong one.
Choose Report by Exception or Polling in one line: To choose report by exception or polling, match the update model to the link and the data cost: use report by exception on expensive or thin links like cellular and satellite where sending only changes saves money, and use polling where the link is cheap, deterministic timing matters, or you need constant proof the device answers. Most real sites blend the two - exception reporting for data plus a slow background poll or heartbeat to confirm the device is alive.
Frame the Decision as Bandwidth Versus Liveness
The choice comes down to two competing needs. Polling means the master asks every device for every value on a schedule, which gives you deterministic timing and constant proof the device is answering, at the cost of sending traffic whether or not anything changed. Report by exception means the device speaks only when a value moves past its deadband, which slashes traffic on quiet points but means silence is ambiguous - a device with nothing to report and a dead device look identical on the wire until you add something that distinguishes them.
On a cheap, fast, reliable network the argument for report by exception weakens, because the bandwidth it saves is bandwidth you were not paying for anyway, and constant polling gives you liveness for free. On a metered or thin link - cellular, satellite, licensed radio - the argument flips hard: polling every point every few seconds can dominate a data plan and buy you almost nothing on values that rarely change. The link economics usually decide the default, and the mechanism behind the savings is exactly what report by exception describes.
Frame liveness as a separate requirement you must satisfy regardless of the data model. If you go pure exception reporting, you have to solve the dead-device problem another way, because a silent device is no longer distinguishable from a healthy quiet one. If you poll, liveness is built in but you pay for it continuously. Naming this trade explicitly stops the classic failure where a site switches to exception reporting for the data savings and quietly loses its ability to notice a failed RTU.
Compare the Two Models Point by Point
Neither model has to win the whole site. The right granularity is per point or per point-group: a fast, critical, rarely-changing safety input might poll so its timing is guaranteed, while a hundred slow analog points on the same RTU report by exception to save the link. Deciding at that granularity is the whole craft, and this table lays out the criteria:
| Criterion | Favors polling | Favors report by exception |
|---|---|---|
| Link cost | Cheap, unmetered | Metered cellular or satellite |
| Update timing | Must be deterministic | Change-driven is fine |
| Change frequency | Value moves constantly | Value is usually quiet |
| Liveness proof | Needed continuously, built in | Solved by a separate heartbeat |
| Buffer risk | None, master pulls | Events can overflow on a busy point |
Watch the buffer-overflow failure mode that only exception reporting has. A device buffers its unsolicited events between contacts, and a point that suddenly gets noisy or a link that drops for a while can overflow that buffer and silently lose events. Polling never has this problem because the master pulls a current value each time. The mechanics of change-driven updates and their buffering are covered in unsolicited reporting, and understanding the buffer is what keeps an exception-reporting site from losing data during exactly the busy moments you most want recorded.
Tie the decision back to scan-rate strategy rather than treating it as separate. Poll rate, scan class, and the exception deadband are one system: how often you ask, which group a point is in, and how big a change has to be to matter. The place these settings come together is your overall scan-rate configuration, and choosing the update model is the first decision that shapes all the others.
Verifying the Choice on the Real Link
Measure the actual traffic each model produces on the real network before you commit the whole site. Run a representative set of points in each mode for a period and compare the data volume and the update timing you get. Exception reporting that theoretically saves bandwidth can still surprise you if the points are noisier than expected, and polling you thought was cheap can dominate a link once you multiply it across every point and RTU. The numbers on your link, not the theory, decide whether the choice was right.
Prove liveness explicitly for any point-group on exception reporting. Kill the link to a device and confirm the system notices within an acceptable time through whatever mechanism you chose - a background integrity poll, a heartbeat, or a comms-fail watchdog. If the device can go dead and the system stays quiet, you have optimized the data bill at the expense of knowing your plant is being watched, and that is the wrong trade. The dedicated safeguard is a comms-fail alarm, and exception-reporting sites depend on it far more than polled ones do.
Common Mistakes to Avoid
The signature mistake is switching to pure exception reporting for the data savings and losing liveness without noticing, so a dead RTU sits silent and undetected for hours. Always pair exception reporting with an independent liveness check. The second mistake is running full polling over a metered link and then being surprised by the data bill, when most of the traffic was carrying values that never changed.
The third mistake is ignoring event-buffer overflow on busy exception points, which silently drops the very events you most wanted during an upset. Size and monitor the buffer, or poll the points that get noisy under stress. The fourth is treating the update model as a single site-wide switch instead of a per-point decision, which forces every point into a compromise that fits none of them. Decide per point-group and blend the models.
Frequently Asked Questions
When should I use report by exception instead of polling?
Use report by exception when the link is expensive or thin - cellular, satellite, licensed radio - and the points are usually quiet, because sending only changes cuts traffic dramatically. Stay with polling when the network is cheap and deterministic timing matters, or when you need constant, built-in proof the device is answering. Most sites blend the two, using exception reporting for data and a slow poll or heartbeat for liveness.
Does report by exception risk losing data?
Yes, in one specific way polling avoids: a device buffers unsolicited events between contacts, and if a point gets noisy or the link drops long enough, that buffer can overflow and silently lose events. Polling pulls a fresh current value each time so it has no buffer to overflow. Size and monitor the event buffer on busy exception points, or poll the ones that turn noisy during the upsets you most need recorded.
How do I detect a dead device if I use report by exception?
You add a separate liveness mechanism, because with pure exception reporting a healthy quiet device and a dead one look identical on the wire. Use a slow background integrity poll, a periodic heartbeat, or a comms-fail watchdog that alarms when a device has been silent too long. Prove it by killing the link in a test and confirming the system notices within an acceptable time rather than staying silent.
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.