Polling hundreds of remote sites every few seconds wastes radio and cellular bandwidth on values that never change. Sending data only when something moves frees the channel and delivers real changes faster.
Traditional SCADA masters ask every RTU for every value on a fixed cycle. Exception based reporting flips that model, so field devices send data when a value changes beyond a set limit.
What Is Report by Exception?
Report by exception is a SCADA data method in which a remote device sends a value only when it changes by more than a configured deadband, or when a digital point changes state. It replaces much of the fixed cycle polling used in traditional SCADA systems.
Real Time Automation explains that DNP3 unsolicited messaging lets outstations report events without being polled, sending only changes. The master still decides how often to confirm the link.
The method works best on slow or costly links such as licensed radio, satellite and cellular. It is a core feature of DNP3 and IEC 60870 5 104.
Modbus has no native exception reporting, so masters must poll, as explained in Modbus protocol. Gateways can add exception behaviour on top.
How DNP3 Handles Events
| Class | Content | Typical Use |
|---|---|---|
| Class 0 | Static current values | Integrity poll |
| Class 1 | High priority events | Trips and alarms |
| Class 2 | Medium priority events | Analog changes |
| Class 3 | Low priority events | Counters and trends |
Time stamped events keep their true order even if the link was down. That is a major advantage over polling, which only sees the value at poll time.
Configure RTU buffers large enough to hold events during outages, as outlined in RTU architecture.
Deadbands Decide the Traffic
A deadband is the change needed before a new analog event is created. Set it too small and noise floods the channel, set it too large and operators miss real trends.
A good starting point is 0.5 to 1 percent of span for most process values. Tighten it for custody transfer and alarms, and relax it for slow tank levels.
6 Smart Report by Exception Tips
Real Time Automation warns that on shared RS485 multidrop links, unsolicited messages can collide, so best practice there is to disable them. Point to point IP links handle them well.
DNP3 has no built in keep alive, so a failed outstation can look quiet and healthy. Background polls and link alarms solve this, a common topic in SCADA communication problems.
Bandwidth Estimate
Exception bytes per hour ≈ Points × Changes per hour × Bytes per event
Example:
500 points, 4 bytes each, poll every 10 s gives 720000 bytes per hour
Each point changes 6 times per hour, 12 bytes per event with time stamp
Exception traffic ≈ 36000 bytes per hour, about 95 percent less
Protocol overhead adds to both figures, so compare using real frame sizes. Our guide on network bandwidth and throughput helps with link budgets.
Savings shrink when values are noisy or deadbands are tight. Measure event rates during commissioning.
Bandwidth Calculator
Add the integrity poll traffic to the exception figure for a full picture. It is usually small.
- Much lower bandwidth use.
- Faster delivery of real changes.
- Time stamped event order.
- Lower cellular data costs.
- Silent failures without keep alive checks.
- Event floods from noisy signals.
- Collisions on multidrop serial links.
- Buffer overflow during long outages.
Modern IIoT protocols such as MQTT use the same publish on change idea, with a broker instead of a master.
Triangle MicroWorks DNP3 Overview PDF
When to Use Unsolicited Messages Video
Report by Exception FAQ
Related Articles
- DNP3 vs IEC 60870 5 104
- SCADA Communication Protocols
- SCADA RTU Architecture
- SCADA Communication Problems
- PLC vs RTU
External References
What We Learn Today
- Report by exception sends data only when values change beyond a deadband.
- DNP3 classes, time stamps and integrity polls make it reliable.
- Tune deadbands and avoid unsolicited traffic on multidrop links.