Bad values, and the reports that quietly include them

Process data carries a quality attribute as well as a value: an indication of whether the reading is good, uncertain, or known bad because of a device fault, communication failure or out-of-range condition.

That attribute is generated reliably by most control systems and is then discarded by a substantial proportion of everything downstream. Reports, calculations and dashboards frequently consume the value and ignore the quality, which means a failed instrument reading zero enters an average as a zero.

How bad values propagate

A transmitter fails and reads downscale. The historian records the value with a bad quality flag, correctly. A daily average is calculated from the historian, and the calculation sums the values and divides by the count, because that is what an average does.

Self-reported operational information can be affected by recall, incentives and reporting bias. A related reference is available at https://www.monitask.com/business-glossary/self-reporting-bias/.

A useful external reference for timing and synchronisation is NIST time and frequency services.

The result is a daily figure dragged down by eight hours of zeros. It appears on a report, is compared against the previous day, and someone investigates a production shortfall that did not occur.

The same mechanism affects control calculations, key performance indicators, mass balances and anything else built on stored data.

Where quality gets lost

Quality information is typically lost at one of a small number of boundaries.

Export to spreadsheet, where the value comes across and the quality does not.

Custom calculations that read the value field directly.

Interfaces between systems that transfer only value and timestamp.

Reporting tools configured against the value column without a quality filter.

Each is straightforward to fix once identified, and identifying them requires someone to trace how a given reported number is actually produced.

Stale data is the harder case

A value that has stopped updating is more dangerous than one flagged bad, because it looks entirely normal. A communication failure that freezes a reading leaves the last good value displayed indefinitely.

Detection requires monitoring the update timestamp rather than the value: a tag whose timestamp has not advanced for longer than a few polling intervals is stale regardless of what the value says.

Displaying that explicitly, and alarming on it for critical measurements, converts an invisible failure into a visible one.

Frozen instruments

A related failure has no system indication at all: a transmitter that continues to communicate and reports a plausible but unchanging value because the sensing element has fouled or blocked.

Nothing in the data path detects this. The detection methods are analytical: a variance check that flags a measurement whose variability has collapsed, or a comparison against a redundant or related measurement.

For critical measurements this is worth implementing. For the general population it is usually caught by operators noticing that a value looks too steady, which is a reason to keep operators looking at trends.

Substituted and manually entered values

Where an instrument is out of service, operations sometimes enter a manual value so that dependent calculations continue to work.

This is a legitimate practice and it needs to be visible. A manually substituted value that is indistinguishable from a measured one in the historical record corrupts any later analysis of that period, and the substitution is usually forgotten before the analysis happens.

Flagging substituted values distinctly, and reporting the proportion of substituted data in any period, keeps it honest.

Reporting the quality alongside the number

The practical discipline is that any derived figure should carry an indication of the data it was built from: what proportion of the underlying samples were good, and whether any substitution occurred.

This is unpopular because it complicates a clean number, and it is what distinguishes a figure that can be relied on from one that cannot. A monthly efficiency calculated from ninety-eight percent good data is a result. The same calculation from sixty percent is an estimate, and the difference should be visible to whoever reads it.

Making quality visible to the operator

Quality handling is usually discussed as a reporting concern, and it matters equally at the operator display, where a bad value shown as a normal number can drive a wrong action.

The display convention should make bad quality unmistakable — a distinct visual treatment, not a subtle colour change — and it should apply consistently across every display.

The same applies to stale data. A value that has stopped updating should be visibly marked as such rather than continuing to present the last known reading indistinguishably from a live one.

Quality in calculations

Derived values inherit the quality of their inputs, and most calculation implementations do not propagate it. A calculated efficiency built from one good and one bad measurement will produce a number with no indication that half its input was invalid.

The correct behaviour is that a calculation with a bad input produces a bad-quality output rather than a plausible number. Implementing that requires the calculation to check input quality explicitly, which is a small amount of additional work per calculation and is routinely omitted.

Tracking quality as a metric

The proportion of good data, by tag and by area, is a useful operational metric in its own right. A declining figure indicates instrumentation degrading, communication problems, or increasing manual substitution.

Reported monthly alongside the maintenance backlog, it also gives the instrument team a demand signal: the measurements whose data quality is worst are usually the ones causing the most downstream trouble.

Quality at the interface boundaries

Data crossing between systems — control system to historian, historian to reporting, historian to a business system — passes through interfaces that may or may not carry the quality attribute.

Each boundary is a place where quality can be lost silently. Establishing what each interface actually transfers, rather than assuming, is a short investigation with a lasting benefit.

Where an interface cannot carry quality, the practical mitigation is to transfer a separate quality tag alongside the value, which is inelegant and considerably better than discarding the information.

Bad data and automatic control

Where a measurement feeds a control loop or a calculation that drives an output, its quality has immediate consequences rather than merely reporting ones.

Control strategies should specify what happens on bad input: hold the last good value, transfer to manual, use a backup measurement, or drive to a defined safe output.

The default behaviour of the platform is frequently not what the process requires, and it is rarely examined until it produces a surprise.