Not every measurement a SCADA system reads deserves the same urgency. A shutdown status, a vessel pressure, or a high-level float needs to be fresh on every scan, while a slow-moving temperature that only feeds a trend can be minutes stale without anyone caring. A poll priority scheme is the arrangement that makes the master treat those tags differently on purpose, sorting them into tiers so the important ones are guaranteed to be read frequently and the rest fill in the time that is left. It is how a comms link with limited capacity is spent first on the data that matters.
Poll Priority Scheme in one line: A poll priority scheme assigns each tag or point to a priority tier that determines how often the SCADA master reads it, so safety-critical and control-relevant measurements are polled on every cycle while trend-only or informational tags are polled less frequently. It exists to guarantee a bounded worst-case latency for the tags that matter, using finite comms bandwidth on the most important data first rather than spreading it evenly across everything.
A priority scheme starts by sorting a site's tags into a small number of tiers, typically two or three, defined by how quickly a stale reading would hurt. The top tier holds the measurements where lateness has real consequence: a pressure or level that feeds a trip, an emergency shutdown status, a fire-and-gas indication, a valve position that operators act on. These are polled on every cycle because a delayed reading on any of them could mean a missed alarm or a wrong operator decision. The top tier is deliberately kept small so that reading it every cycle stays affordable.
The middle tier holds data that is genuinely useful but tolerant of some delay, such as flows, motor currents, or setpoints that operators watch but do not need updated multiple times a second. These tags are polled regularly but not necessarily on every single cycle, so they get fresh values within a few seconds without competing for the bandwidth reserved for the top tier. The bottom tier is for the slow and the informational: ambient temperatures, run-hour counters, diagnostics, and trend-only points whose value changes gradually or whose staleness costs nothing. These can be polled infrequently, filling whatever capacity remains after the higher tiers are served.
The assignment is a judgment about consequence, not about how interesting a number looks, and getting it right is the heart of the scheme. A common mistake is to put too much in the top tier, which defeats the purpose by making every-cycle polling too heavy to sustain, and the opposite mistake is to demote a control-critical tag into a slow tier where a delayed reading can bite. A good scheme keeps the top tier lean and defensible, so that the guarantee attached to it, that these tags are always fresh, is one the comms link can actually keep.
The tiers only mean something because of how the master orders its poll queue. Rather than reading tags in a flat round-robin, a priority-aware master services the high-priority tags on every pass and interleaves the lower tiers into the gaps. In practice this often looks like the top tier being read every cycle, the middle tier every few cycles, and the bottom tier every many cycles, so a single scan pass always includes all the critical data plus a rotating slice of everything else. High-priority tags effectively jump the queue, and low-priority tags wait their turn without ever blocking the important reads.
The point of this ordering is a bound you can state and defend: the worst-case time between two consecutive reads of any top-tier tag. Because the critical tier is serviced every cycle, that worst case is one cycle long, and it does not stretch when someone adds a hundred trend tags to the site, because those new tags land in a lower tier and consume only the leftover capacity. The determinism is the deliverable. An engineer can promise that a shutdown status is never more than one scan old, and that promise holds regardless of how much low-priority clutter the tag database accumulates over the years.
This is also what makes a priority scheme robust as a site grows. Tag counts on a real site tend to creep upward as instruments are added and as engineers instrument more of the process for diagnostics. Under a flat, unprioritized scan, every new tag lengthens the cycle and slowly degrades the freshness of the critical data along with everything else. Under a priority scheme, growth in the lower tiers is absorbed by pushing their read interval out further, while the top tier's every-cycle guarantee is untouched. The tags that matter keep their latency budget no matter how much informational data piles up around them.
Priority polling earns most of its value on the same constrained links where every read is expensive, such as a cellular remote or a shared licensed-radio channel serving many field sites. On those links there is only so much time in a cycle to ask questions, and a scheme that treats every tag equally spends that time indiscriminately, so a slow trend point can end up polled just as often as a trip pressure. A priority scheme redirects the scarce reads toward the top tier first, so the safety and control data stays current even when the link is too slow to keep everything current at once.
In a cloud SCADA platform such as Merobix, each remote site can carry its own priority assignment so the platform knows which of that site's tags must be read every cycle and which can lag. The master then services the critical points across the whole fleet frequently and lets the informational points on each site fill the remaining capacity, which keeps the fleet's most important data fresh without needing a fast link at every location. A remote tank with one critical high-level point and dozens of diagnostic points is polled sensibly: the level is always current, and the diagnostics arrive when there is room for them.
Priority polling also interacts naturally with a busy day in the field. When several sites are active at once and the shared channel is under pressure, the scheme ensures the squeeze falls on the low-priority reads rather than the critical ones, so the informational data ages a little while the trip and control data stays fresh everywhere. That is the behavior operators want during an upset: the numbers they act on remain trustworthy and current, and the numbers that merely feed long-term trends can wait until the channel has room again. The scheme turns a limited link into one that degrades gracefully, giving up freshness on what does not matter first.
Put a tag in the top tier when a stale or delayed reading would have a real consequence, such as a measurement feeding a trip, an emergency shutdown status, a fire-and-gas indication, or a value operators act on directly. Keep that tier deliberately small so reading it on every cycle stays affordable and the every-cycle guarantee remains achievable. Slower, trend-only, and diagnostic points belong in lower tiers where some staleness costs nothing.
The master services the top-priority tier on every scan pass and interleaves lower tiers into the leftover capacity, so a critical tag is never more than one cycle old. Because new low-priority tags land in lower tiers and only consume spare capacity, adding them does not stretch the top tier's read interval. That gives an engineer a defensible bound that holds even as the tag database grows over time.
They are related but not the same. Grouping simply bundles tags that are read together, whereas a priority scheme adds an explicit ranking that decides which tags jump the queue and get read on every cycle versus which wait for spare capacity. The priority scheme is about guaranteeing latency for the tags that matter under a constrained link, not just about organizing which tags travel in the same request.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.