How to Configure a Quality-Flag Strategy in SCADA
A value on a SCADA screen is only as trustworthy as its quality flag, and on too many systems that flag is ignored, so a frozen last-known reading looks exactly like a live good one. This guide is for the engineer setting a quality strategy across a system who wants bad data to announce itself rather than hide. It covers defining the quality states, propagating them through calculations and displays, and making alarms and reports respect quality instead of acting on stale numbers.
Configure a Tag Quality Strategy in one line: To configure a quality-flag strategy, define a small set of quality states (typically good, bad, and uncertain), ensure every tag carries a quality alongside its value, propagate that quality through calculations and roll-ups so a bad input yields a bad result, and make alarms, trends, and reports respect quality so they never act on or display stale data as if it were live. The goal is that bad data always looks bad, never like a confident good value.
Define the Quality States and Their Sources
Start with a small, clear set of quality states, because a strategy nobody understands is not applied. Good means the value is current and trustworthy; bad means it cannot be trusted - comms failed, the device faulted, the input is out of range; uncertain covers the in-between where the value may be stale or estimated but not clearly wrong. Three states are enough for operators to act on and match the coarse quality distinctions most systems and protocols already carry.
Enumerate what actually drives a quality to bad, because quality is only useful if it is set correctly. Comms failure to the device, an out-of-range raw signal, a diagnostic fault reported by a smart transmitter, and a stale timestamp older than expected are the common triggers, and each needs to be wired to set the flag. A quality that stays good no matter what happens upstream is decoration, not information, so the strategy is mostly about connecting real fault conditions to the flag. A dead link, for instance, should drive quality bad through the same detection as a comms-fail alarm.
Map external quality codes into your states rather than passing them through raw. Protocols and OPC carry their own detailed quality encodings, and a strategy that dumps a cryptic code onto an operator screen helps no one. Translate the incoming quality into your three states at the boundary, so the whole system speaks one quality vocabulary and an operator reads good, bad, or uncertain rather than a hex status they have to look up. Every SCADA tag then carries a quality the whole stack understands.
Propagate Quality Through Everything Derived
Quality must flow, or it is trapped at the source while bad data leaks downstream looking fine. Any calculation, aggregate, or roll-up built on a tag has to inherit the worst quality of its inputs, so a total computed from a failed flow reads bad, not confidently wrong. This is the same discipline as building calculated tags safely: the derived value carries the quality of the data it came from, and a single bad input taints the result rather than being averaged away into a plausible number.
Carry quality into the historian so recorded data remembers whether it was trustworthy. A stored value with no quality is a number you can never fully trust in hindsight, because you cannot tell whether it was a live reading or a frozen one during a comms outage. Storing quality alongside value means a later investigation can filter out the bad-quality stretches instead of treating a flatlined frozen value as real process data, which is exactly the trap that fools people analyzing an old event.
Preserve quality across store-and-forward and recovery. When buffered data forwards after an outage, its quality must travel with it, and a value that was uncertain when captured should still read uncertain when it lands. Quality and timestamp are the two pieces of metadata that make recovered data honest, and dropping either during recovery leaves the archive unable to distinguish good history from filled-in guesswork.
Make Alarms and Displays Respect Quality
Stop alarms from acting on bad-quality data. An alarm evaluating a frozen or out-of-range value can either fire on a fault it should ignore or stay silent on a value it can no longer see, and both are dangerous. Configure alarms to treat bad quality explicitly - typically inhibiting the normal alarm and instead flagging the quality problem - so an operator gets told the measurement failed rather than getting a spurious process alarm or a false all-clear. This makes a SCADA alarm honest about the difference between a real excursion and a lost signal.
Show quality on the display so the operator sees it, not just stores it. A bad-quality value should look different on the screen - greyed, marked, or replaced with a quality indicator - so no one reads a frozen number as a live one. The whole point of the strategy fails if the quality is tracked internally but the operator still sees a confident number, because the human at the console is the one making decisions on it. Visible quality is what turns the flag from bookkeeping into protection.
Handle quality in reports and trends so summaries do not launder bad data. A report that averages in bad-quality readings produces a number that looks precise and is wrong, and a trend that draws a frozen value as a flat line looks like a stable process rather than a dead sensor. Reports should exclude or mark bad-quality data, and trends should show the gap, so the output reflects what was actually measured and a reader is not misled by good-looking bad data in a SCADA trend.
Verifying Quality Behaves Under Failure
Test the strategy by failing things on purpose. Pull comms to a device and confirm its tags go bad, that calculations built on them go bad too, that the operator display marks them, and that alarms on those tags do not fire spuriously. Then restore comms and confirm quality returns to good cleanly. A quality strategy is only proven by watching it react to a real failure, because a flag that never turns bad in testing is a flag you cannot trust to turn bad in production.
Check the historian and reports after a failure, not just the live screen. Confirm the bad-quality stretch is marked in the recorded data and that a report over that period excludes or flags it rather than averaging the frozen value in. The value of quality is largely retrospective - it is what lets you trust or discard old data - so the recorded quality is as important to verify as the live one, and both belong in your broader configuration validation.
Common Mistakes to Avoid
The foundational mistake is tracking quality but ignoring it, so a frozen last-known value looks identical to a live good one on the screen and in reports. Make quality visible and make alarms, trends, and reports respect it. The second mistake is failing to propagate quality through calculations, so a total built on a dead input reads as a confident good number instead of inheriting the bad quality it deserves.
The third mistake is passing raw protocol quality codes through to operators, who cannot read them, instead of translating to a simple good/bad/uncertain vocabulary at the boundary. The fourth is dropping quality during store-and-forward recovery, so recovered data loses the one piece of metadata that told you whether it was trustworthy when captured, leaving the archive unable to separate real history from filled-in gaps.
Frequently Asked Questions
What quality states should a SCADA tag have?
A small, clear set - typically good, bad, and uncertain. Good means current and trustworthy, bad means it cannot be trusted because comms failed or the input is out of range, and uncertain covers stale or estimated values that are not clearly wrong. Three states are enough for operators to act on and align with the coarse quality distinctions most protocols and systems already carry, so translate detailed external codes into them at the boundary.
How do I stop alarms from firing on bad data?
Configure alarms to treat bad quality explicitly rather than evaluating the value as if it were live. Typically you inhibit the normal process alarm on bad quality and instead raise a quality or comms-fail indication, so the operator learns the measurement failed rather than getting a spurious excursion alarm or a false all-clear on a frozen value. This requires quality to be set correctly by comms failure, out-of-range, and stale-timestamp conditions.
Why does quality need to be stored in the historian?
Because quality is largely retrospective value: a stored number with no quality cannot be trusted in hindsight, since you cannot tell a live reading from a frozen one during an outage. Storing quality alongside the value lets a later investigation filter out bad-quality stretches instead of treating a flatlined frozen value as real process data, and it keeps reports and trends from laundering bad data into good-looking summaries.
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.