What Is a Scan Class?
Grouping Tags by Update Rate

Back to Blog

Why Scan Classes Exist

Not every value needs the same attention. A wellhead shut-in pressure that feeds a safety alarm should be read every second or two, while a lifetime run-hours counter or a slowly drifting tank temperature is fine at once a minute. If everything were polled at the fastest rate, a SCADA server talking to hundreds of remote sites over cellular or radio would saturate its links and CPU for no benefit.

Scan classes solve this by letting the engineer bucket tags by importance and rate of change. Each tag is assigned to a class - Fast, Normal, Slow, or custom-named intervals - and the polling engine services each class on its own schedule. This is the core lever for balancing responsiveness against bandwidth and load in a distributed system.

Scan Class and Polling in SCADA

In a polled architecture, the SCADA server cycles through its scan classes: on each Fast tick it requests the fast-class registers from every device, on each Slow tick the slow-class registers, and so on. Well-designed device drivers pack the tags in a class into as few protocol reads as possible to keep the schedule efficient.

Scan class interacts with two related ideas. Deadband or report-by-exception reduces how much of what is scanned actually gets stored or transmitted. And in report-by-exception protocols, the relevant rate is how often the device is allowed to send changes rather than how often it is polled. Merobix, as a cloud-native SCADA, reads field devices over Modbus, DNP3, OPC UA, and similar protocols and lets you set update rates per tag group, so critical values stay near real-time while low-priority data is polled economically - important when many remote sites share limited cellular bandwidth.

A Working Method for Assigning Rates

Start from consequences, not habit. For each tag ask two questions: how fast can this value change in a way that matters, and what happens if the system notices late? Values that protect equipment or people go fastest - but note that genuine protection logic belongs in the PLC or RTU, which sees the value every controller scan regardless of what the SCADA polls. The scan class only governs how quickly a human or a central system finds out about it.

A practical bucketing: operator-response values - the pressures, flows, and statuses an operator acts on - in the fast class; situational-awareness values in a middle class; totalizers, diagnostics, and slowly drifting temperatures in a slow class; and configuration or nameplate data read once at startup or on demand. The guiding principle is that the scan must be comfortably faster than the fastest change you need to observe - sample slower than the event and the event simply happens between polls and never appears at all.

The Arithmetic of an Overloaded Schedule

Whether a schedule fits is a calculation you can run symbolically before commissioning. Suppose a fast class covers several devices on one shared channel, the driver needs P protocol transactions per cycle after packing contiguous registers into block reads, and each transaction costs t seconds including radio or cellular turnaround. The cycle then needs roughly P times t seconds. If that product exceeds the class interval, the class overruns: every cycle starts late, latency accumulates, and timestamps drift steadily away from reality.

The levers, in the order to pull them: pack registers so P shrinks - scattered addresses are the usual villain - then demote tags that never needed the fast class, then split devices across channels so transactions run in parallel, and only then consider new hardware. Watch the driver's own diagnostics: actual cycle time against configured interval, timeout counts, retry counts. A class that runs near its limit on a good day will overrun on a bad one, when a marginal radio path starts forcing retries.

Scan Rate, Alarms, and Stored History

An alarm evaluated in the SCADA can only fire when a scan delivers the value, so a brief excursion shorter than the scan interval may never be seen centrally. That is acceptable for awareness alarms and unacceptable for protection - which is why trips live in the controller and the SCADA alarm announces what the controller already did. Deciding which alarms carry which duty is a design task, not a polling setting, and it deserves a line in the alarm philosophy document.

History has its own rate. Storing every scan of a fast class multiplies storage and bandwidth for values that barely move, so systems filter what is scanned before it is stored - the role of deadbands, and the reason report by exception pairs naturally with scan classes. The scan brings the value in; the exception logic decides whether it is worth keeping; the historian stores what survives. Tuning all three together, rather than one at a time, is what keeps a large system both responsive and affordable.

Frequently Asked Questions