Two fundamentally different ways a SCADA master learns what's happening in the field — the master asking on a schedule, or the device speaking up when something actually happens.
Every SCADA system has to solve the same basic problem: the master station lives in a control room, the process lives out in the field, and someone has to initiate the conversation that gets data from one to the other. There are exactly two ways to structure that conversation. Either the master repeatedly asks every device "what's your status?" on a fixed schedule — polling — or each device is left to decide for itself when something worth reporting has actually happened, and speaks up unprompted — report-by-exception. Which side initiates communication changes almost everything about the resulting system's bandwidth use, data freshness, and failure-detection behavior.
In polling, the master decides when it hears from a device, so a lack of response to a poll is itself meaningful information — the master can conclude a device has gone unresponsive. That guarantee comes at a cost: every poll consumes channel time whether or not the underlying value has moved, and a device's data can only ever be as fresh as its last poll. In report-by-exception, the device decides when to speak, so bandwidth is spent only on genuine changes — but a device with nothing new to report is, on the wire, indistinguishable from a device that has failed. That silence is ambiguous unless something else fills the gap. Which is exactly why so many real deployments run both mechanisms at once: report-by-exception for routine data, plus a periodic poll or heartbeat purely to confirm "still alive."
Not quite. Report-by-exception genuinely does save bandwidth and can improve responsiveness to changes that matter — a real event gets reported the moment it happens instead of waiting its turn in a scan cycle. But it gives up something polling provides for free: a guaranteed, periodic confirmation that every device is still alive and communicating. A device that has nothing new to report and a device that has quietly failed both look identical on the wire — pure silence — unless a separate heartbeat or "still alive" message is added specifically to tell the two apart. That's why most real SCADA systems don't pick one mechanism exclusively. They run a deliberate hybrid: report-by-exception for routine data updates, combined with periodic polling or heartbeat messages whose entire purpose is confirming device health — not treating either approach as a universal substitute for the other.
Explains the two fundamental ways a SCADA master learns about field conditions — polling, where the master actively and repeatedly requests data from every remote device on a fixed schedule, and report-by-exception, where the field device itself decides when a monitored value has changed enough to warrant an unsolicited report — and the real tradeoff between them: bandwidth efficiency and event responsiveness versus guaranteed, predictable confirmation of device health.
In a polled system, the SCADA master station (or its communication front-end) works through a defined scan list, sending a request to Device 1, waiting for its response, then moving to Device 2, then Device 3, and cycling back to Device 1 again — a round-robin sequence repeated on a fixed schedule. Every device answers every poll, whether or not its value has changed since the last cycle. That guarantees the master hears from each device on a predictable interval, but it also means communication bandwidth is spent transmitting unchanged values over and over, which matters most on slower serial or radio links common in SCADA. It also means the master, not the device, determines data freshness: a value is only ever as current as the last time it was polled, and adding more devices to a shared channel or scan group makes every device's data proportionally staler.
In a report-by-exception (RBE) system, the field device (RTU or PLC) monitors its own data continuously and only transmits when a value changes beyond a configured threshold — a deadband. Instead of the master repeatedly asking "any change?", the device proactively reports "here's a change" only when something meaningful actually happened. This can dramatically cut communication bandwidth, since no messages are wasted confirming values that haven't moved, and it can improve responsiveness for events that matter, because a real change is reported immediately instead of waiting for its turn in a scan cycle. The cost is that the device needs more onboard intelligence to evaluate its own values and decide when a report is warranted, and the deadband has to be tuned carefully — too sensitive and the channel gets flooded with nuisance reports; too insensitive and real changes go unreported until they exceed an unnecessarily large threshold.
Polling is simple and gives the master deterministic, guaranteed control over when it hears from each device — which matters when a system needs periodic proof that a device is still alive and responding, since the absence of a poll response is itself meaningful information (the device has likely failed or lost communication). Report-by-exception is more bandwidth-efficient and can respond faster to genuinely important changes, but it sacrifices that guarantee: a device that simply has nothing new to report looks identical, on the wire, to a device that has failed, unless a separate heartbeat mechanism is added. Because of this real tradeoff, most production SCADA systems use a hybrid: report-by-exception for routine data updates to save bandwidth, combined with periodic polling or dedicated heartbeat messages specifically to confirm device health and communication status. Treating either mechanism as a universal replacement for the other ignores exactly the problem the other one solves.
For data that changes infrequently relative to the poll rate, yes — RBE avoids retransmitting unchanged values entirely. But if a monitored value is genuinely volatile and crosses its deadband constantly, RBE can generate more traffic than a modest polling rate would, especially with a poorly tuned (too-sensitive) deadband. The efficiency gain depends on how often the value actually changes relative to how often it would otherwise be polled.
It generally can't tell, from RBE traffic alone, whether silence means "nothing changed" or "the device is offline." That's why most RBE deployments add a separate mechanism — a periodic heartbeat message, an occasional health-check poll, or a communication watchdog timer — specifically to distinguish a quiet-but-healthy device from a failed one.
A deadband is the minimum amount a monitored value must change before the device considers it significant enough to report. Too tight a deadband causes excessive, nuisance reporting on normal process noise; too loose a deadband means real, meaningful changes can go unreported until they exceed an unnecessarily large threshold. Tuning it is a direct tradeoff between reporting sensitivity and communication load.
Yes, and many real systems do exactly this deliberately — RBE for routine data updates to minimize bandwidth use, combined with periodic polling or heartbeat messages purely to confirm each device is still alive and communicating. The two approaches solve different problems and are commonly combined rather than treated as mutually exclusive alternatives.
DNP3 is the protocol most associated with native report-by-exception support in SCADA, via unsolicited responses and event classes with configurable deadbands. Classic Modbus, by contrast, is fundamentally a master-initiated polling protocol with no built-in unsolicited reporting, which is one practical reason DNP3 is often preferred over Modbus for bandwidth-constrained utility and pipeline SCADA links.
Try our SCADA Studio
More calculators, simulators, and guides for this discipline.