Improving Data Quality in the PI System: Common Issues and Solutions

PI System data can become unreliable for many reasons. The source can fail, a configuration can drift, a calculation can break, or a user can connect a display to the wrong signal.

A practical data-quality program should identify the condition, locate the cause, and prioritize the repair by operational importance.

Bad or system digital states

A PI Point can contain a bad system state because the source or interface cannot provide a valid measurement.

Check:

• Source-system status

• Interface or connector status

• Point configuration

• Data-reference health

• Recent communication failures

Do not replace bad data with a normal numeric value only to make a dashboard look complete. Preserve the quality state when it is important to interpretation.

Low PercentGood

PercentGood can help summarize the proportion of good data in a time range. A low value indicates that the period contains bad or questionable data.

Use it as a screening metric, not as the only quality measure. A signal can have 100 percent good status and still be stale, flatlined, or mapped to the wrong source.

Stale data

A stale tag has not updated within the expected interval.

The correct threshold depends on the signal. Compare the last event time with the expected update behavior for that point or asset class.

Flatlined data

A flatlined signal continues to report the same value for an abnormal period.

Use process context. Some binary, state, or slowly changing signals can remain constant for long periods without a fault.

Broken references

AF attributes and calculations can reference tags or objects that no longer exist or no longer represent the intended source.

Validate reference integrity after migrations, tag renames, template changes, and server consolidation.

Duplicate signals

Duplicate PI Points can create confusion and conflicting downstream use.

Confirm duplicates by comparing source address, interface, metadata, time-series behavior, and usage. Similar names alone are not enough.

Metadata inconsistencies

Incorrect engineering units, descriptions, span, and source metadata can make a technically valid value unsafe to interpret.

Standardize required metadata and include it in audits.

Multiple writers to the same output

Two calculations or applications writing to the same PI Point can create unexpected values and timestamps.

For calculated outputs, define one authoritative writer and document it.

Compression and exception problems

Exception and compression settings affect event delivery and archive fidelity.

Review settings when the stored trend does not show expected process movement, or when a point creates an unusually high event rate.

Do not copy the same settings to every signal type.

Prioritize by downstream use

Large environments can contain thousands of quality findings. A useful program ranks findings by impact.

Consider:

• Asset criticality

• Use in PI Vision

• Use in AF analyses

• Use in reports or external systems

• Safety, environmental, or production relevance

Build a repeatable response

For each important issue, record the finding, owner, cause, remediation, and verification result.

The objective is not only to remove bad values. It is to reduce repeated failures and increase confidence in the data that people and applications actually use.