Polled vs Event-Driven Telemetry: The Cost
On a metered cellular or satellite link, how you move data off a site is a recurring bill, and the choice between polling every point on a schedule and reporting only when values change can shift that bill by an order of magnitude. This page compares the two telemetry models on economics specifically, works the bandwidth math symbolically so the drivers are clear, and shows why slow-changing data is where event-driven reporting earns its keep.
Polled vs event-driven telemetry cost in one line: Polling costs the same whether or not data changes, because the master requests every point every cycle, so its bandwidth scales with tag count times poll rate regardless of activity. Event-driven reporting sends data only when a value moves past a deadband, so its cost scales with how often the process actually changes. For slow-moving data on a metered link, event-driven is dramatically cheaper; for fast-changing data, the two converge.
Work the Bandwidth Math Symbolically
Strip the two models to their cost drivers and the difference is obvious. Polling generates traffic proportional to the number of tags N multiplied by the poll frequency f, every cycle, forever, whether the values changed or not. Call the per-poll overhead p; then polled data volume grows roughly as N times f times p over time, a flat, constant spend that is completely indifferent to whether the process is busy or idle. This is the model behind poll rate and polling in SCADA, and its predictability is both its virtue and its cost.
Event-driven reporting, the model behind report by exception, generates traffic proportional instead to the number of actual changes. If a tag crosses its deadband C times in a period, it sends C messages; if it never moves, it sends nothing beyond periodic integrity confirmations. Volume scales as the sum over all tags of their change counts, which for slow-changing process data is far smaller than N times f. The deadband is the tuning knob: widen it and C falls, narrowing bandwidth at the cost of resolution on small movements.
Compare the Economics Side by Side
The table sets the two models against the cost-relevant factors, keeping the drivers symbolic rather than inventing figures.
| Factor | Polled | Event-driven |
|---|---|---|
| Cost driver | Tag count times poll rate | Number of real changes |
| Cost when data is idle | Unchanged - still polls | Near zero - nothing to send |
| Cost when data is volatile | Unchanged | Rises toward polled levels |
| Predictability of bill | Flat and easy to forecast | Varies with process activity |
| Tuning knob | Poll rate | Deadband width |
| Cheaper when | Data changes almost every cycle | Data changes rarely relative to poll rate |
The crossover is the whole story. When a value changes roughly every poll cycle anyway, event-driven reporting sends about the same number of messages as polling would, so there is little to save and polling's simpler, more predictable pattern may win. When a value sits still for many cycles between moves, which describes most tank levels, pressures, and temperatures, event-driven collapses the traffic to a fraction of the polled volume. Deciding between them is really a question about how active your data is, formalized in how to choose report by exception or polling.
Two refinements matter for the real bill. First, event-driven schemes still send periodic integrity or heartbeat traffic so the master knows the link is alive and no change was missed, so the floor is not truly zero. Second, polling can be made cheaper without abandoning it by widening the interval on stable points, the idea behind an adaptive poll rate, which narrows the gap between the two models for data that is mostly but not entirely idle.
When Each Model Wins on Cost
Event-driven wins decisively for slow-changing data on a metered link, which is the common remote-monitoring case. Tank levels that drift over hours, line pressures that hold steady, and temperatures that move slowly generate few real changes, so reporting only those changes cuts the recurring data bill sharply compared with polling every point every cycle. On cellular or satellite tariffs where every byte is billed, this is where event-driven reporting pays for its added configuration complexity many times over.
Polling wins on cost when the data genuinely changes almost every cycle, because then event-driven reporting is sending nearly as many messages as polling would while carrying extra per-message overhead. Fast, continuously varying signals, or situations where you need a guaranteed sample every interval regardless of change, are cases where polling's flat, predictable pattern is as cheap and simpler to reason about. Its forecastable bill is also easier to budget.
Many real fleets run a hybrid: event-driven reporting for the bulk of slow analog points to save bandwidth, plus a slow background integrity poll so nothing is silently lost and the master periodically confirms the full picture. This captures most of the savings while keeping the guarantee that a missed change is eventually caught, and it is worth validating with a data-usage check as described in verifying cellular data usage against the polling math.
Pitfalls in the Economics
The biggest pitfall is choosing event-driven for its savings and then setting the deadband so tight that noise on a signal generates a flood of changes, turning the cheap model into an expensive one. A jittery analog point with a narrow deadband can report constantly, sending more traffic than a modest poll would, so deadbands must be set against the real noise floor of each signal, not left at a hopeful default.
A second trap is forgetting the integrity floor and assuming event-driven costs nothing when idle, then being surprised by the steady heartbeat and periodic full-refresh traffic that keeps the link honest. Budget for that floor. The final pitfall is a purely economic decision that ignores latency and freshness: a value that changes rarely but matters urgently when it does may still warrant a fast poll or a tight deadband, so let the process consequence, not only the data bill, set the reporting behavior for critical points.
Frequently Asked Questions
Is report by exception always cheaper than polling?
Only when data changes rarely relative to the poll rate, which covers most slow-moving analog points like tank levels and pressures. If a value changes almost every cycle, event-driven reporting sends nearly as many messages as polling plus extra overhead, so the savings shrink to nothing. The savings come from not transmitting during idle periods, so the model wins in proportion to how much of the time your data actually sits still.
What drives cellular data cost in a polled SCADA system?
The tag count multiplied by the poll rate, plus the per-poll protocol overhead, all of which is spent every cycle whether or not values changed. That makes the bill flat and predictable but indifferent to process activity, so you pay the same on a quiet night as during a busy shift. The levers are polling fewer points, polling less often, or switching stable points to event-driven reporting so idle time stops costing money.
Can I combine polling and event-driven reporting?
Yes, and many fleets do. Report the bulk of slow analog points by exception to save bandwidth, and run a slow background integrity poll so the master periodically confirms the full picture and nothing is silently lost. This captures most of the savings while preserving the guarantee that a missed change is eventually caught. Validate the result against a real data-usage measurement rather than assuming the configured behavior matches the actual bill.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.