SCADA Polling vs Report by Exception: The Difference

Polling sends a request on a fixed schedule and waits for a reply. Report by exception (RBE) sends data only when a value changes. Both approaches move process data from field devices to SCADA, but they make opposite assumptions about how often values actually change — and that assumption determines bandwidth consumption, latency, and total infrastructure cost.

Choose the wrong model for your communication link and you either flood a narrow radio channel with redundant traffic or miss a fast-moving alarm because your poll cycle is too slow.

Report by Exception Device-initiated, on change

SCADA Server listens RTU / IED monitors & pushes Push on change only Deadband: ±0.05 bar Heartbeat: every 60 s Low BW 80–95% less data Scales to 5,000+ points Latency = near real-time

Quick Answer: Polling vs Report by Exception

Attribute	Polling	Report by Exception (RBE)
Who initiates	Master (SCADA)	Field device / RTU
Data sent when	Every cycle, regardless of change	Only on value change
Bandwidth	High — constant baseline	Low — proportional to activity
Latency	Up to one full poll cycle	Near-real-time on change
Scalability	Limited by poll cycle time	Scales to thousands of points
Comms cost (cellular)	High — always-on data	Low — burst only
Complexity	Simple — deterministic timing	Higher — requires deadband and heartbeat config
Best fit	Local LAN/fibre, fast loops	Cellular, radio, satellite, IIoT

---

What Is Polling in SCADA?

Polling is a master-initiated, cyclic data request. The SCADA server (master) sends a request frame to a field device — RTU, PLC, or meter — and waits for the device to respond with the current value of one or more registers. This cycle repeats on a fixed interval regardless of whether any process value has changed since the last scan.

In a classic Modbus RTU setup over serial or Ethernet, the master generates a Function Code 03 (Read Holding Registers) request every scan cycle. If the cycle is 5 seconds and the temperature in a tank has not moved in the past hour, the master still sends 5,000 identical requests per day asking for the same number.

How a poll cycle works

1. SCADA master opens connection (or uses existing persistent connection).
2. Master sends read request: device address, register start, register count.
3. Field device receives request, reads hardware I/O, assembles response.
4. Device sends response frame with current register values.
5. Master receives response, timestamps it, stores in historian or tag database.
6. Timer elapses — cycle repeats from step 1.

The key characteristic: the master controls the timing. The field device is passive. It answers when asked and is silent otherwise.

Polling is the native model for Modbus RTU/TCP, DNP3 Class 0 polling, PROFIBUS DP, and legacy serial protocols going back to the 1970s. It is deeply familiar to controls engineers and straightforward to debug — a protocol analyser on the wire shows exactly what data moved and when.

---

What Is Report by Exception in SCADA?

Report by exception (RBE) is a device-initiated model where the field device transmits data only when a value crosses a defined threshold or deadband. The SCADA server does not ask — the device decides when something worth reporting has happened and pushes the update.

If a pressure transmitter sits at 4.32 bar and the deadband is ±0.05 bar, no message goes to the server until pressure moves outside the 4.27–4.37 bar window. On an hourly trend log that value might never transmit. On a fast-moving surge event, multiple messages per second might arrive.

How RBE works

1. Field device (RTU, IED, IIoT gateway) is configured with a deadband per tag — an amount of change that must occur before transmission is triggered.
2. Device continuously monitors hardware I/O against the last-reported value.
3. When a value changes by more than the deadband, the device assembles a timestamped message and pushes it to the SCADA server.
4. Server receives the unsolicited message, processes it, and updates the tag database.
5. A heartbeat interval is configured as a backup — if no change occurs within (e.g.) 60 seconds, the device sends the current value anyway to confirm the link is alive.

The key characteristic: the device controls timing. The SCADA server is a listener. This inverts the traditional master-slave model and requires the server to handle unsolicited messages from potentially thousands of sources simultaneously.

RBE is the native model for MQTT/Sparkplug B, DNP3 unsolicited reporting, IEC 60870-5-104 spontaneous transmission, and modern IIoT protocols.

---

How Each Works: A Side-by-Side Walkthrough

Scenario: 200-point water treatment site, 4G cellular link

With polling (Modbus TCP over 4G):

• Poll cycle: 10 seconds per full scan of 200 tags.
• Each Modbus TCP request/response pair: approximately 60–120 bytes including headers.
• 200 tags × 120 bytes × 6 polls/minute = ~144 KB/minute regardless of process activity.
• Peak activity (alarm storm): same 144 KB/minute — polling cannot accelerate.
• Quiet Sunday night: same 144 KB/minute — polling cannot slow down.
• Monthly data cost at 4G rates: ~6 GB per site.

With RBE (MQTT/Sparkplug B over 4G):

• All 200 tags publish a birth certificate on connect (~5 KB one-time).
• Typical process: 10–15 tags actually change per minute during normal operation.
• 15 tags × 80 bytes × 60 minutes = ~72 KB/hour during normal operation.
• Peak activity: 200 tags changing rapidly might reach 30–50 KB/minute — still less than polling baseline.
• Heartbeat every 60 seconds per tag: 200 × 80 bytes × 1/minute = ~16 KB/minute worst-case with all heartbeats firing simultaneously (they stagger in practice).
• Monthly data cost: 90–95% reduction vs polling for a quiet process.

---

Bandwidth and Cellular/Radio Cost

Bandwidth cost is where the polling vs RBE decision has the clearest financial impact. Polling generates a constant, predictable data rate proportional to tag count and poll frequency. RBE generates a variable, activity-proportional data rate.

For sites on leased fibre or a local LAN, bandwidth is essentially free and polling's constant overhead is irrelevant. This is why Modbus over Ethernet remains dominant in plant floor applications where the network is wired and the distances are short.

For sites on cellular (4G/5G LTE), satellite, or licensed/unlicensed radio, bandwidth has a direct monthly cost. Data SIMs for RTUs in water, oil and gas, and utilities are typically capped at 1–5 GB/month per site. A Modbus TCP polling implementation can blow through a 1 GB SIM in days for a large tag count. RBE over MQTT can keep the same site within budget for a full month.

On narrow-band radio links (VHF/UHF licensed, 900 MHz ISM), the constraint is even harder — raw throughput may be 9.6 kbps to 115 kbps. Polling 500 tags on a 9.6 kbps link can mean scan cycles of 30–60 seconds, which is too slow for any loop requiring sub-second detection. RBE lets the same link prioritise urgent changes without waiting for the master to ask.

Deadband tuning is the primary lever for controlling RBE data volume. A poorly configured deadband — set too tight — causes a point to chatter and transmit continuously on noise, defeating the bandwidth benefit. A deadband set too wide misses real process changes. Good practice is to set deadband at 2–3x the normal sensor noise floor.

---

When to Use Polling

Polling is the right choice when:

• The communication link is local LAN or fibre — bandwidth is not a constraint and simplicity is more valuable than efficiency.
• You are using Modbus RTU/TCP or legacy serial protocols — these protocols are inherently master-slave and are not designed for unsolicited messaging.
• Deterministic scan time matters — control loops and interlocks that need a guaranteed update rate every N milliseconds benefit from a predictable poll cycle. You know exactly when data was last refreshed.
• The device does not support RBE — older PLCs, legacy meters, and simple sensors may only support register reads. You cannot implement RBE on a device that has no concept of it.
• The tag count is small — polling 20 tags on a reliable link imposes negligible overhead and the simplicity advantage is real.
• Debugging and diagnostics require transparency — every transaction is explicit and visible in a protocol trace. There is no ambiguity about what data was requested and when.

Polling is also appropriate as a fallback mechanism inside an RBE architecture. Most implementations configure periodic integrity polls (DNP3 Class 1/2/3 poll, or MQTT heartbeat) to confirm device health even when no exception has fired.

---

When to Use Report by Exception

RBE is the right choice when:

• The communication link is cellular, satellite, or narrow-band radio — bandwidth cost or throughput limit makes constant polling unacceptable.
• Tag counts are large — a polling master querying 5,000 tags on a 1-second cycle is physically impossible on most links; RBE scales naturally because quiet points consume no bandwidth.
• Event-driven accuracy is needed — a valve that opens and closes in 200 ms may be missed entirely by a 5-second poll; RBE captures the event at the moment it occurs with a device-side timestamp.
• You are building IIoT or cloud SCADA architectures — cloud brokers (AWS IoT, Azure IoT Hub, Google Cloud IoT) are designed for publish/subscribe, not for responding to polling masters.
• Power-constrained devices — field devices on solar or battery can sleep between transmissions; a polling master would require the radio to stay on continuously.
• Audit trails and SOE (sequence of events) logging — RBE with millisecond-accurate device-side timestamps gives a true SOE record. Polling timestamps reflect when the master received the data, not when the event occurred.

The tradeoff to accept with RBE is configuration complexity. Every point needs a deadband and a heartbeat interval, and those values need tuning. The server must handle unsolicited traffic and maintain connection state for each publishing device. Monitoring for "no data received" (link failure) replaces the simple "no response to poll" indicator of a polling architecture.

---

The MQTT and Sparkplug B Connection

MQTT is architecturally a report-by-exception protocol. The publish/subscribe model — where a device publishes a message to a broker only when it has data to report — is RBE by design.

MQTT and Sparkplug B extends the core MQTT protocol with a defined payload structure specifically for industrial SCADA and IIoT. Sparkplug B enforces several RBE conventions:

• Birth certificates (NBIRTH/DBIRTH): On connection, a node publishes the full current value of every tag. This eliminates the cold-start problem where the server has no baseline.
• Data messages (NDATA/DDATA): Only changed tags are included in a data message. If 200 tags are configured and only 3 changed, the DDATA message contains 3 tag values.
• Death certificates (NDEATH/DDEATH): Published automatically by the broker (via MQTT Last Will and Testament) if the device disconnects unexpectedly, signalling link loss to the server.
• Rebirth command: The server can request a fresh birth certificate at any time to force a full state sync — effectively an on-demand "integrity poll" equivalent.

This structure means Sparkplug B gets the bandwidth efficiency of RBE while preserving the ability to force a full data refresh when needed. It addresses the primary operational concern about RBE ("how do I know the server has the right value?") without requiring constant polling.

OPC UA PubSub, the other dominant IIoT protocol, takes the same approach — publishers emit data on change, and a configurable sampling interval plus deadband controls how often a value qualifies as "changed." See the SCADA architecture explained guide for where these protocols fit in a complete system design.

---

Polling vs RBE for RTUs and Remote Sites

Remote Terminal Units (RTUs) are the field devices most directly affected by the polling vs RBE decision. An RTU sitting on a wellhead, a pipeline isolation valve, or a water tower typically communicates over a cellular or radio link where bandwidth is constrained and the round-trip latency may be 200–800 ms.

Traditional RTU deployments use DNP3 over serial or TCP in polling mode — the SCADA master polls Class 0 (static data), Class 1 (high-priority events), Class 2 (medium-priority events), and Class 3 (low-priority events) on different schedules. DNP3 also supports unsolicited reporting (RBE equivalent) where the RTU pushes Class 1 events immediately without waiting for a poll. Most modern DNP3 deployments enable unsolicited reporting for Class 1 events (alarms, digital state changes) while retaining periodic Class 0 integrity polls for analog values.

For newer RTU deployments using an MQTT gateway layer, the RTU hardware continues to run Modbus or DNP3 to the field instruments, while an edge gateway converts the data to MQTT/Sparkplug B before sending it over the WAN link. This hybrid architecture lets existing field devices and wiring stay in place while the WAN communication shifts from polling to RBE.

The SCADA tutorial for beginners covers RTU fundamentals and communication architectures in more detail if you are building this mental model from scratch.

---

FAQ

What is the difference between polling and report by exception?

Polling means the SCADA master sends a data request to the field device on a fixed schedule — every 5 seconds, every 10 seconds — and the device responds with the current value whether or not anything has changed. Report by exception means the field device sends data to the SCADA server only when a value changes by more than a configured deadband. Polling is master-initiated and deterministic; RBE is device-initiated and event-driven.

What is report by exception in SCADA?

Report by exception (RBE) is a data transmission strategy where a field device — RTU, PLC, IED, or smart sensor — monitors its own process values and transmits a message to the SCADA system only when a value changes beyond a configured threshold (deadband). The opposite of polling, RBE dramatically reduces bandwidth consumption on remote communication links because quiet points with stable values never generate traffic. A heartbeat interval is typically configured so the server can confirm the device is still connected even when no exceptions are firing.

Which uses less bandwidth, polling or report by exception?

Report by exception uses significantly less bandwidth for typical industrial processes, where the majority of tags are stable most of the time. In real-world deployments, RBE over MQTT can reduce WAN data consumption by 80–95% compared to equivalent Modbus TCP polling, because only the subset of tags that actually change generate traffic. The savings are largest when the process is quiet (night shifts, steady-state operation) and smallest during alarm storms or rapid process changes. Polling bandwidth is constant regardless of process activity.

Does MQTT use report by exception?

Yes — MQTT is inherently a report-by-exception protocol. Devices publish messages to the broker only when they have data to send, not on a fixed request-response cycle. The Sparkplug B specification formalises this for industrial SCADA by defining birth certificates (full state on connect), data messages (changed tags only), and death certificates (link failure notification). MQTT/Sparkplug B is the most widely adopted protocol for implementing RBE in modern IIoT and cloud SCADA architectures.