Report by exception is a data-acquisition method where a machine or edge device sends a value only when it changes by more than a defined threshold, instead of transmitting readings on a fixed timer. The alternative, polling, asks every device for its current value at a regular interval whether or not anything has moved. On a modern factory floor with hundreds of tags flowing from PLCs, sensors, and vision systems, the difference between these two approaches decides whether your network stays healthy or drowns in redundant traffic. This article breaks down report by exception, the deadbanding and change-of-value techniques behind it, and how to scale machine data economically without dropping the signal that matters.
Polling is the default in many legacy SCADA and historian setups because it is simple: a master device requests each tag on a cycle, say once per second, and writes whatever comes back. The problem is that most process values are stable most of the time. A tank temperature that holds at 72.0 degrees for ten minutes still generates 600 identical readings under one-second polling. Multiply that across every tag on a line and you are paying for bandwidth, storage, and edge CPU to move data that says nothing new.
Polling also scales badly. Each new device you add lengthens the poll loop, so either your scan rate slows or you split the load across more channels and gateways. On constrained links (cellular, LoRa, or a shared industrial VLAN), the fixed traffic floor of polling can crowd out the readings you genuinely care about. Understanding your true data profile is a prerequisite for any real-time monitoring effort, the same way understanding your losses is a prerequisite for improving overall equipment effectiveness.
Report by exception (often called RBE or event-driven reporting) flips the model. The edge device holds the last transmitted value and continuously compares it to the live reading. It sends an update only when the new reading crosses a threshold. Nothing changes on the wire while the process is stable, and the moment a value moves, the change propagates immediately. The result is traffic that is proportional to how much your process is actually varying, not to how many tags you have or how fast you poll.
Two mechanisms make this reliable:
Most implementations pair the two: deadband suppresses noise, COV logic handles the actual reporting, and a heartbeat or maximum-time setting guarantees a periodic update even during long stable periods so downstream systems know the link is alive.
Deadband is usually expressed as an absolute value or a percentage of the signal range. Say you have a temperature sensor spanning 0 to 200 degrees C, reporting a live analog signal that carries about 0.3 degrees of electrical noise. You set a deadband of 1.0 degree.
Now the bandwidth math. Under one-second polling, that single tag produces 86,400 messages per day, regardless of behavior. Suppose the temperature genuinely crosses the 1.0-degree deadband about 40 times per hour during production, which is 960 events per day, plus a safety heartbeat every 15 minutes adding 96 messages. Report by exception sends roughly 1,056 messages per day against polling's 86,400, a reduction of about 98.8 percent. Across 300 tags with similar profiles, you move from 25.9 million messages daily to around 317,000, and you have lost none of the meaningful transitions.
The lever is the deadband width. Too wide and you smooth away real events; too narrow and noise leaks through. Tune each tag to its own noise floor and the smallest change that carries business meaning, the way a well-built control plan specifies tolerances per characteristic rather than one blanket rule.
The fear with report by exception is missing something important. You avoid that by setting the deadband deliberately rather than by feel:
Done this way, report by exception is not lossy. You keep every transition that crosses your defined significance threshold and simply stop paying for the flat lines in between. For root-cause work on stubborn losses, the transitions are exactly what you want, and a Pareto analysis of exception events surfaces the top offenders faster than sifting through polled noise.
This is not an all-or-nothing choice. A pragmatic architecture uses both:
The trade-offs to weigh: report by exception needs edge logic to hold last values and evaluate deadbands, and it can produce bursty traffic when a process swings hard. Polling is dead simple and deterministic in timing but wasteful and poor at scale. Many SCADA historians support both models per tag, which lets you match the method to the signal. The same layered thinking that separates reactive from proactive maintenance applies here: use the cheaper event-driven method by default and reserve the heavier fixed-cadence method for where it earns its cost. Event streams also feed cleanly into condition-based maintenance, where a threshold crossing is precisely the trigger you act on.
Fabrico is the real-time data foundation that sits on top of whatever acquisition method your floor uses. It ingests live machine and production signals for real-time OEE and production monitoring, and it can read machines with computer vision where there is no PLC to poll or push events at all, which is often the case on older or standalone assets. That vision path gives you an exception-style stream (cycle counts, stops, state changes) from equipment that was never instrumented for IIoT. On the maintenance side, Fabrico is a field-ready CMMS covering work orders, assets, preventive scheduling, and spare parts, so the events your data layer surfaces turn directly into action. Fabrico is EU-built with EU data residency, which matters when your machine data cannot leave the region. Explore the OEE monitoring and CMMS overviews to see how the pieces connect.
Not if the deadband is set correctly. You keep every change that crosses your defined significance threshold and only suppress movement smaller than that, which by definition is either noise or below the level anyone acts on. A mandatory heartbeat interval guarantees a periodic reading even during long stable periods, so historians and downstream systems always have a recent anchor and can confirm the link is live.
Change-of-value reporting is the rule that fires an update when a value differs from the last reported one. Deadbanding is the tolerance band that defines how big that difference must be before it counts. In practice they work together: the deadband filters out jitter and analog noise, and the change-of-value logic handles the actual transmission when the signal leaves the band.
Yes, and most well-designed systems do. Use report by exception for the majority of continuous analog tags and for state changes, and reserve polling for cases that need a guaranteed value at a fixed cadence, such as regulatory logging or legacy devices that cannot push events. Many historians and gateways let you set the method per tag, so you match each signal to the approach that fits it.
Ready to turn efficient machine data into real-time OEE and actionable maintenance? Book a Fabrico demo and see how a live data foundation, including vision on machines with no PLC, scales across your floor.
Login
Blog
