Is report-by-exception always more bandwidth-efficient than polling?

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.

How does the master know a device using report-by-exception hasn't failed?

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.

What is a deadband in this context?

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.

Can a single SCADA system use both polling and report-by-exception?

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.

Which protocols support report-by-exception?

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.

← SCADA & Industrial Controls Studio

Concept Explainer · SCADA

Polling vs. Report-by-Exception

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.