Stop Scanning Every SCADA Tag at One Second

The symptom usually shows up a few weeks after go-live: one PLC on a channel drops, and suddenly every other device on that channel reads stale too. The operator sees a frozen overview and calls it a network fault. It rarely is. It's a scan-class problem — everything on that channel polls at the same aggressive rate behind the same generous timeout, so one dead device drags the whole channel down with it.

The flat "all tags at 1 second" default is where this starts. It's easy to configure and easy to explain, which is exactly why it survives into production. It's also the reason PLC comms modules saturate, TCP-to-serial gateways fall behind, and historians fill with samples that look precise but carry no information a trend could use.

Scan class design is a control decision, not a driver checkbox. A trip permissive, a valve command feedback, a tank level, a daily totalizer, and a maintenance runtime counter do not need the same update rate — and when the channel is under load, treating them as equals is what makes the permissive arrive late while a maintenance hour-meter refreshes on time.

Group tags by how they're used, not by the driver default

Group tags by how operators and control logic actually use them.

Tag type	Typical scan approach
Command feedback and interlock status	Fast enough to support operator action and timeout logic
Alarms and safety-related indications	Fast and reliable, with clear stale quality handling
Analog process values	Based on process dynamics, not screen refresh rate
Slow equipment status	Moderate rate unless used for active sequencing
Totals, counters, maintenance hours	Slow or event-based if supported
Configuration, limits, recipe values	Read on display open, on change, or at a slow background rate
Diagnostic tags	Slow by default, faster only during troubleshooting

If a tag only appears on a maintenance screen opened once a month, it should not poll at the same rate as the running-state display an operator watches all shift. As a starting point I keep interlock feedback and heartbeats at 250–500 ms, analog process values at 1–2 s (matched to the loop, not the screen), slow status at 5 s, and totalizers and runtime counters at 30–60 s or event-based. Those numbers move per site, but the spread is the point: three or four classes, not one.

Count requests, not tags

Tag count does not describe load; request count does. A well-aligned Modbus block read can pull 100 contiguous holding registers in one transaction, while a scattered address map turns the same 100 tags into a dozen small reads. A gateway that fronts RS-485 devices over Modbus TCP will take one SCADA request and serialize it into several slow downstream transactions at 9600 or 19200 baud — the TCP side looks instant, the serial side is the real bottleneck.

Before you commit a scan rate, estimate:

• Devices per driver channel, and how they share the physical path.
• Read requests after block optimization — not tag count.
• Largest request the device actually handles reliably (some PLCs truncate or reject oversized reads).
• Response time under normal load and when a device is retrying.
• Write traffic during operator actions, recipe downloads, and batch transitions — writes often preempt reads on the same channel.
• Every other client on the endpoint: engineering tools, historian, redundant partner, dashboards, a second SCADA.

A 1-second class is fine for one PLC on its own Ethernet drop. Copy that setting onto a Modbus TCP gateway feeding six RS-485 meters and you've asked a serial bus to complete dozens of transactions per second that it physically cannot.

Decide what slows down first — before the network decides for you

If you don't define load shedding, the driver and network define it for you, through timeouts and reconnect storms. Watch the timeout math on a shared channel: a 3000 ms timeout with two retries means a single dead device blocks that channel for roughly 9 seconds every scan cycle. That's how one failed meter freezes an entire overview. Tighten the timeout, cap the retries, and — where the driver supports it — mark a device "down" after N consecutive failures so it stops taking a slot until it answers again.

The order I default to:

1. Hold command feedback, critical alarms, and heartbeat tags at their required rate — these are never sacrificed.
2. Slow diagnostics and maintenance tags first.
3. Slow background totals and counters next.
4. Drop closed-display detail tags to demand polling if the platform supports it.
5. Keep timeouts short enough that a bad device can't monopolize the channel.

The protocol often gives you a better lever than raw polling. DNP3 (IEEE 1815) is built for this: run a periodic integrity poll (Class 0) every few minutes for the full static image, and let Class 1/2/3 event data arrive by exception, priority-ordered, instead of polling every point fast. OPC UA (Part 4) splits the sampling interval on a monitored item from the subscription's publishing interval — sample a value at 250 ms but publish batched changes at 1 s, and set the queue size so nothing is lost between publishes. Both let you keep fast response to change without paying for fast polling of everything. Some platforms expose priority scan classes or demand polling directly; others need separate channels or subscription groups. The mechanism varies; the rule doesn't: low-value polling must never delay high-value visibility.

Use stale quality, not silent old values

When a scan class is slowed, paused, or failing, the operator should not see old values as if they are live. The project needs a stale-data rule.

Good rules are specific:

• A one-second critical status becomes stale after three missed updates.
• A ten-second utility meter becomes stale after one minute.
• A daily counter can tolerate a longer delay but must show its last update time.
• A demand-polled maintenance value should show "not currently polling" or a last-read timestamp.

Stale quality is not the same as a process alarm. Do not flood the alarm banner for every slow diagnostic tag. But do make stale state visible where it affects decisions.

Separate screen performance from device polling

Operators often report polling problems as "the screen is slow." Sometimes the device polling is fine and the display is heavy: too many animations, embedded trends, scripts, or faceplates open at once. Other times the display opens and creates a burst of demand reads that overloads the device.

Test both layers:

1. Watch driver statistics while the display is closed.
2. Open the display and note the change in request rate, response time, and timeout count.
3. Close the display and confirm the load drops back.
4. Check whether hidden tabs, popups, or off-screen components continue polling.
5. Compare HMI render time with protocol response time.

This separates a graphics performance issue from a communication capacity issue.

Common failure modes

Symptom	Likely cause
All devices on one channel become slow when one device fails	Timeout and retry settings block the channel
Values update quickly until a large display opens	Demand polling or display-bound tags create a burst load
Historian has many samples but little useful information	Scan rate is faster than process dynamics or compression settings
Critical feedback arrives late during recipe download	Write bursts and slow tags share the same communication path
Gateway works during FAT but fails on site	Additional clients or serial devices were not included in the load test
Operators ignore stale indicators	Stale rules are too noisy or not tied to operational decisions

Commissioning tests before handover

Run a load test before calling the interface complete:

• Normal production screens open.
• The largest overview and detail screens open together.
• Historian collection enabled.
• Redundant server or standby node connected as it will be in production.
• Engineering workstation connected, if that is allowed during operation.
• One slow or disconnected device present on the channel.
• A recipe download, command sequence, or batch transition occurring during polling.

Record driver request rate, timeout count, response time, and CPU load on the communication server. If the numbers are only acceptable in a perfect network, the scan class design is not finished.

Project note template

For each driver channel or OPC UA subscription group, keep a short note:

• Devices included and expected protocol path.
• Scan classes and their tag categories.
• Priority or load-shedding behavior.
• Timeout and retry settings.
• Stale-data thresholds by tag class.
• Results from the worst-case display and disconnected-device test.

This is more useful than a raw tag count. It tells the next engineer which data must remain fast and which data is intentionally allowed to slow down.