A scan class is a named update rate that a SCADA or PLC assigns to a group of tags, so different data is read at the speed it actually needs. Fast-changing safety values get scanned every second; slow readings like a daily total get scanned every minute or on demand. Grouping tags this way keeps the system responsive where it matters without drowning the network in needless traffic. This guide explains what scan classes are, why they exist, and how they shape SCADA polling.
Scan Class in one line: A scan class is a defined polling or update interval - such as 1 second, 5 seconds, or 1 minute - to which tags are assigned so each value is read at an appropriate frequency. It lets a control or SCADA system spend bandwidth and CPU on fast-changing data while polling slow data less often.
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.
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.
Because it wastes bandwidth and CPU. A server polling hundreds of remote sites over cellular or radio would saturate its links reading slow-changing values needlessly. Scan classes let fast, important tags update near real-time while slow tags are read far less often.
Scan class sets how often a tag is read. Deadband, or report-by-exception, sets how much a value must change before it is stored or transmitted. They work together: scan class controls the read rate, deadband filters out insignificant changes so you keep only meaningful updates.
Match the rate to how fast the value changes and how important it is. Safety and control values that change quickly go in a fast class of a second or two; totalizers, run-hours, and slowly drifting readings go in a slow class of a minute or more.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.