Edge Processing vs Central Polling
The old default was to poll every raw value back to a central master and do all the thinking there. Cheap capable gateways changed the calculus: you can now filter, aggregate, and even alarm at the site before anything crosses the link. This page is for the architect deciding where computation should live. It compares doing work at the edge against pulling everything to the center, and gives a rule for splitting the two.
Edge Processing vs Central Polling in one line: Choose edge processing when the link is slow, metered, or unreliable, when local decisions must be fast, or when raw data volume is large relative to what the center needs, because computing at the site cuts bandwidth and removes a dependency on the link staying up. Choose central polling when links are cheap and reliable and you want the full raw record centrally with the least field complexity. Most real systems split the work: reduce and safeguard at the edge, analyze and store at the center.
Compare What Belongs at Each Layer
The decision is really about where three things happen: data reduction, time-critical logic, and durable storage. Central polling puts all of them at the master and treats the edge as a dumb reader. Edge processing pushes reduction and fast logic to the site and reserves the center for analysis and history. Neither owns everything - the useful question is which task belongs where.
| Concern | Central polling | Edge processing |
|---|---|---|
| Data reduction | At the center, after transport | At the site, before transport |
| Bandwidth used | All raw values, every cycle | Only what survives filtering |
| Fast local logic | Delayed by the round trip | Runs at the site immediately |
| Behavior on link loss | Blind until the link returns | Keeps deciding and buffering |
| Field complexity | Low - devices just answer | Higher - logic to deploy and maintain |
| Central raw record | Complete | Reduced unless you also send raw |
Edge reduction and normalization are covered in protocol normalization at the edge, while central polling mechanics live in poll rate and polling in SCADA.
The catch with edge processing is that logic at the site is logic you must deploy, version, and maintain across many places, which is real operational surface. Central polling keeps the intelligence in one spot at the cost of transporting raw data and depending on the link. The right split usually gives the edge the jobs that are cheap to run and expensive to transport, and gives the center the jobs that benefit from the full picture.
When Each One Wins
Edge processing wins when transport is the bottleneck. If the link is metered, slow, or unreliable, filtering raw data down to changes and summaries at the site slashes what has to cross it, and local logic keeps working when the link is down. It also wins where a decision must be fast - a local interlock or a debounce - because waiting for a central round trip is too slow. Time-critical alarming at the site is discussed in edge-triggered alarming.
Central polling wins when the link is cheap and reliable and you value simplicity and completeness. If you want every raw sample in the historian and the network can carry it, polling everything to the center keeps field devices dumb and puts all logic in one maintainable place. It is the least operational surface in the field, which matters when sites are numerous and you do not want code running at each one. On a solid LAN, central polling is often the pragmatic default.
The winning pattern is a deliberate split. Let the edge debounce, deadband, aggregate, and safeguard - the work that is cheap locally and expensive to transport - and let the center analyze, correlate across sites, and store the durable record. If you need the raw record centrally too, have the edge buffer and forward it opportunistically rather than streaming it live. That gives you edge efficiency without giving up central history. Edge analytics scope is covered in edge analytics.
Architecture Pitfalls
The central-polling pitfall is assuming the link will always carry the load. As sites and points grow, raw polling can saturate a metered or modest link, and every value ages while it waits its turn in the poll cycle. Teams often discover the ceiling only when data goes stale, which is late. If the link is the constraint, no poll-rate tuning fixes a fundamentally raw-heavy design.
The edge-processing pitfall is scattering unmanaged logic. Every rule, deadband, and script you deploy to the site is something to version, test, and update across the fleet, and drift between sites produces inconsistent behavior that is hard to debug. Keep edge logic simple, declarative, and centrally managed where possible, and resist turning each gateway into a bespoke program. The point of the edge is reduction and safety, not a second uncontrolled control system.
A cloud SCADA such as Merobix typically sits at the central layer, consuming whatever the edge sends - reduced streams, buffered raw records, or direct polls - so the split is a design choice you make per site, not a platform constraint. Push the cheap-to-run, expensive-to-transport work to the edge, keep analysis and durable history central, and manage the edge logic like the fleet asset it is rather than a pile of one-off scripts.
Frequently Asked Questions
What should I process at the edge versus the center?
Put work at the edge when it is cheap to run locally and expensive to transport - deadbanding, debouncing, aggregation, and fast local safety logic that cannot wait for a central round trip. Keep work at the center when it benefits from the whole picture or a durable record - cross-site correlation, deep analytics, and long-term history. The split reduces bandwidth and keeps the site working during link outages while centralizing the analysis.
Is central polling obsolete now that edge gateways are cheap?
No. Central polling is still the simplest, most maintainable choice on cheap, reliable links where you want every raw sample centrally and dumb field devices. Edge processing earns its keep when transport is the bottleneck or local decisions must be fast. Both remain valid; the modern default is a split that reduces and safeguards at the edge while analyzing and storing at the center.
Does edge processing mean I lose the raw data centrally?
Only if you choose to. Edge processing reduces what streams live, but you can still capture the full raw record at the site and have the gateway buffer and forward it to the center opportunistically when the link allows. That gives you edge efficiency for live monitoring and a complete central history for analysis, without paying to stream every raw sample in real time over a constrained link.
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.