A collector serving thousands of tags cannot treat them all the same. A fast pressure loop deserves collection every second, while a tank temperature that drifts over hours is wasteful to poll that often, and mixing the two carelessly either starves the fast tags or floods the archive with pointless samples. The way collectors organize this is the scan group: tags are bundled by how often they should be collected, and each group is polled on its own interval. This page explains how scan groups assign tags to collection frequencies, how right-sizing them balances collector load, and why this collector-side grouping is a different thing from a single tag's scan rate or a controller's scan logic.
Historian tag scan group in one line: A historian tag scan group is a collection of tags that a collector polls together at a shared interval, grouped by how frequently each tag needs to be sampled. Fast-changing tags go in a group scanned every second or few seconds, while slow tags go in a group scanned every minute or longer, so the collector spends effort in proportion to how quickly each signal actually changes. Grouping tags this way balances the collector's workload and keeps fast tags from crowding out slow ones or the reverse.
The purpose of a scan group is to attach a collection interval to a set of tags rather than to each tag individually, so the collector can gather them efficiently in one pass on that cadence. Tags whose values change quickly and matter at fine resolution, such as fast pressures, flows, and control loop variables, are placed in a fast group polled at a short interval. Tags that change slowly, such as ambient temperatures, tank levels, and equipment status that rarely flips, go in slower groups polled at longer intervals. Each group has its own timer, and when a group's interval elapses, the collector reads all of its tags and forwards the samples.
Grouping matters because collection is not free. Every poll consumes time on the collector, bandwidth to the source device, and, ultimately, archive space for the samples produced. Sampling a slow tag every second produces a stream of nearly identical values that add cost without adding information, while sampling a fast tag only once a minute misses the very changes that make it worth historizing. By assigning each tag to a group whose interval fits how fast that tag actually moves, the scan group aligns effort with value, giving fine resolution where it is needed and restraint where it is not.
Assigning tags to the right group is a design decision that pays off over the life of the system. It is worth grouping by the genuine dynamics of each signal rather than by habit, because an over-fast assignment multiplied across thousands of tags becomes a real load, and an over-slow assignment quietly loses detail that cannot be recovered later. Reviewing group membership when tags are added, and when the process or the reporting needs change, keeps the collection footprint sensible as the system grows.
A collector has finite capacity, and how tags are distributed across scan groups determines whether that capacity is used smoothly or in damaging spikes. If too many tags share one fast group, the collector may struggle to read them all within the group's interval, causing the scan to overrun so that some reads slip late or the next cycle starts before the last finished. That overrun degrades the timeliness of exactly the fast tags that needed prompt collection. Splitting an overloaded fast group, or moving tags that do not truly need the fast rate into a slower group, relieves the pressure and restores on-time collection.
Right-sizing also means preventing fast tags from starving slow ones and the reverse. If everything is lumped into a single frequent scan, the sheer volume of fast reads can crowd the collector so that slow tags, which are cheap individually, still suffer because the collector is perpetually busy. Conversely, a poorly balanced set of groups whose intervals all align can cause every group to come due at the same instant, producing a synchronized burst of collection that momentarily overwhelms the collector even though the average load is fine. Staggering group timing and distributing tags thoughtfully smooths these peaks so the collector's work is spread evenly over time.
The health signals to watch are whether groups complete their scans within their intervals and whether the collector's load stays within a comfortable margin. Persistent overruns in a group are the clearest sign it is too large or too fast for the collector, and the remedy is to rebalance, either by splitting the group, relaxing its interval where the data allows, or distributing tags across an additional collector. Treating scan group configuration as something to tune based on observed behavior, rather than set once and forget, keeps collection reliable as the tag count climbs.
It is easy to conflate a scan group with a single tag's scan rate, but they operate at different levels. A tag's scan rate is the frequency at which that one tag is collected, the answer to how often is this specific value sampled. A scan group is the collector-side container that assigns a shared interval to many tags at once, the answer to how is collection organized across the tag set. In practice a tag inherits its effective scan rate from the group it belongs to, so the group is the mechanism and the rate is the per-tag result. Thinking in groups is what makes managing thousands of tags tractable, because you configure and tune intervals per group rather than per tag.
Scan groups are also distinct from a controller's scan-class logic. Inside a PLC or DCS, scan classes govern how often the controller executes portions of its own control program, a matter of control loop timing and processor loading within the automation device. A historian scan group governs how often a separate collector reaches out to acquire values for archiving, which is about data collection, not control execution. The controller might update a value every few milliseconds internally, while the historian's scan group collects that value once a second for trending; the two rates serve different purposes and are set independently.
In a SCADA and cloud monitoring context, scan groups are where the tradeoff between fidelity and cost is actually dialed in for the historical record. A remote site feeding a central historian benefits from grouping so that its most dynamic signals are captured at fine resolution while its slow, stable measurements are collected sparingly, keeping bandwidth and storage in check without losing the detail that matters. Aligning each group's interval with both the physics of the signal and the resolution the monitoring team needs downstream ensures the archive holds enough detail to be useful and not so much that it becomes expensive to move, store, and query.
A tag's scan rate is how often that one tag is collected, while a scan group is the collector-side container that assigns a shared interval to many tags at once. A tag usually inherits its effective scan rate from the group it belongs to, so the group is the mechanism and the per-tag rate is the result. Working in groups makes it practical to configure and tune intervals across thousands of tags without setting each one individually.
No. A PLC or DCS scan class controls how often the controller executes parts of its own control program, which is about control timing and processor loading inside the automation device. A historian scan group controls how often a separate collector acquires values for archiving, which is about data collection. The controller may update a value far faster internally than the historian's scan group collects it, and the two rates are set independently for different purposes.
The main sign is scan overrun, where the collector cannot read all of a group's tags within the group's interval, so reads slip late or the next cycle starts before the last finished. That degrades the timeliness of the fast tags in the group. The fix is to rebalance by splitting the group, relaxing its interval where the data allows, or distributing tags across another collector, and then confirming that groups again complete their scans on time.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.