Bad Data Quality Across a Site: How to Triage
Every point from a site, or a large block of them, just went to bad or uncertain quality while the numbers themselves may still look plausible. Because quality is metadata about whether a value can be trusted, a whole-site quality change is telling you the system has lost confidence in the entire feed at once, which points at a shared cause. This page is a symptom-first tree that separates the common reasons a site's quality goes bad: a communication timeout, a device fault, or a configuration change that broke the mapping.
Bad Quality Across a Site in one line: When data quality goes bad across a site, the flag is doing its job: something made the system stop trusting the whole feed. Work three causes in order of likelihood - a communication timeout that marked every polled tag stale, a controller or interface fault that stopped serving valid values, and a configuration or mapping change that broke the source addresses. The scope of the bad quality, matching a device, poll, or interface boundary, names which one.
First Checks: What Quality State and What Scope
Read the exact quality state before anything else, because the different bad states point at different causes. A stale or last-known-value state usually means the values are old - the device stopped answering and the system is holding and flagging the last good numbers. An explicit bad or comm-fault state means the system actively knows the path failed. An uncertain state often means the value arrived but something about it is doubtful, such as a sensor out of range or a device reporting its own fault. Knowing which state you have narrows the tree before you touch anything.
Map the scope, exactly as you would for any all-at-once symptom. Did every tag from the whole site go bad, or just the tags behind one interface, one controller, or one poll group? The boundary of the bad quality is the boundary of the fault. If quality went bad for one controller's tags while another controller at the same site stayed Good, the site link is fine and the fault is that one controller or its interface. If the whole site went bad together, the shared element is the link or the site-level equipment. This is the same scope-mapping discipline that drives the tree for tags flatlining at once.
Check whether the underlying numbers froze when the quality went bad. In most timeout cases the values stop changing and go stale together - the flag and the frozen number are two views of the same event. If the numbers kept updating but the quality still reads uncertain, that is a different situation: data is arriving but the device or the range check is unhappy with it. Understanding what a quality flag actually encodes helps here, because the flag is a compact statement of why the system does or does not trust the value.
Comms Timeout Versus Device Fault Versus Config Change
Take the communication timeout first because it is the most common cause of a whole-site quality drop. When a poll stops getting answers, the system waits, times out, and marks every tag it was polling as stale or bad, all at once, because they all missed the same poll. The tell is that the quality change is simultaneous across exactly the polled set and the last values are frozen at plausible numbers. This is closely related to a Modbus or protocol timeout, and the workflow for fixing a Modbus timeout error covers the link-level side of the same failure. Confirm by checking whether the device is answering at all.
If the link is proven up but quality is still bad, suspect the device or its interface. A controller that is running but has faulted, a communications processor that hung, or a protocol interface that is returning errors rather than data can drive tags to bad or uncertain quality while the network path itself is fine. The distinction from a timeout is that you can reach the device but it is not serving valid values - you get errors, exceptions, or fault responses instead of silence. A PLC sitting in fault mode is a classic version of this, and it drives every tag it should serve to bad quality until it is cleared.
If nothing changed in the field but quality went bad after someone touched the system, suspect a configuration or mapping change. An edited address, a renamed device, a changed data type, or a broken point mapping can make the system request values it can no longer read, which it flags as bad or uncertain. The signature is a quality change that coincides with a configuration edit rather than a field event, and it often hits exactly the tags whose mapping was altered. Checking the change log against the timestamp of the quality drop is the fastest way to catch a self-inflicted fault before dispatching anyone to a site that is actually fine.
Verifying the Cause and Restoring Trust
Verify by matching the recovery to the suspected cause. If you believe it was a timeout and the link recovers, quality should snap back to Good across the whole polled set at once, in the same simultaneous way it went bad. If you believe it was a device fault and you clear the fault or restart the interface, the tags served by that device return while the rest are unaffected. If you believe it was a config change and you revert the edit, exactly the mis-mapped tags recover. A recovery that matches the predicted scope confirms the diagnosis; one that does not means you fixed the wrong layer.
Do not clear or acknowledge bad quality without understanding it, because the flag is protecting downstream users. A bad or stale flag stops operators from acting on numbers that are actually old or wrong, and it stops calculations and reports from consuming stale inputs. Suppressing the flag to make a screen look clean, without fixing the cause, leaves everyone trusting values the system already knows are untrustworthy. The correct end state is Good quality earned by a working feed, not a silenced flag over a broken one.
In a cloud SCADA such as Merobix, a whole-site quality change is visible with its scope and timestamp, and the platform carries the quality flag alongside every value so downstream trends, alarms, and reports all know when the data went untrustworthy. An engineer can see whether the bad quality follows a device, poll, or site boundary, line it up against the change log, and watch it recover in the same shape when the fix lands. The flag is not noise to be cleared; it is the evidence this tree runs on.
When to Escalate
Escalate to the communication owner when the bad quality spans the whole site and the link is the shared element, because restoring trust means restoring the feed, which is a comms or infrastructure task. Escalate to controls when the link is proven up but the device is serving faults, because clearing a controller fault or restarting an interface is a controls job that may need a site visit if no remote reset exists.
Escalate to whoever made the recent configuration change when the quality drop coincides with an edit, because the fastest fix for a self-inflicted mapping break is to have the person who changed it revert or correct it. In all three cases, hand over the quality state, the scope, and the timestamp, because those three facts route the problem to the right owner and prevent a field dispatch for a fault that lives in the head end or the config.
Frequently Asked Questions
Why did all my tags from one site go to bad quality at once?
Because a quality flag reports whether a value can be trusted, and a whole-site change means the system lost trust in the entire feed at the same instant, which points at a shared cause. The three common causes, in order of likelihood, are a communication timeout that marked every polled tag stale, a device or interface fault that stopped serving valid values, and a configuration change that broke the point mapping. Map the scope of the bad quality against your device, poll, and site boundaries to see which shared element failed.
Should I just clear the bad quality flags to clean up the screen?
No. The flag is protecting operators, calculations, and reports from acting on values the system already knows are stale or wrong. Clearing or suppressing it without fixing the cause leaves everyone trusting untrustworthy data, which is exactly the situation the flag exists to prevent. The correct end state is Good quality earned by a working feed. Fix the timeout, the device fault, or the broken mapping, and the quality returns to Good on its own, in the same scope in which it went bad.
The numbers look fine but the quality says uncertain. What does that mean?
Uncertain usually means the value arrived but something about it is doubtful rather than the feed being dead. Common causes are a sensor reading out of its configured range, a device reporting its own internal fault alongside the value, or a partial read. Unlike a timeout, the data is still updating, so this is not a comms loss. Check the device's own diagnostics and the tag's range configuration, because the system is telling you it received a number it is not confident is valid, not that it received nothing at all.
Sources and verification
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.
- Modbus Application Protocol Specification - Modbus Organization
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.