How Data Quality Degrades in the PI System and Why It Matters

PI data quality can degrade at several layers. A reliable instrument does not guarantee a reliable dashboard, and a healthy server does not guarantee a correct calculation.

Teams should review data quality as a chain from source to use.

Source and interface layer

Problems can begin before data reaches the archive.

Common conditions include:

• Instrument failure or drift

• Communication loss

• Interface mapping errors

• Incorrect scan behavior

• Buffering or connectivity problems

These issues can create bad values, stale data, gaps, or unexpected event frequency.

PI Point configuration

Point configuration affects how data is collected, stored, and interpreted.

Review:

• Point source and source address

• Engineering units and span

• Exception settings

• Compression settings

• Expected update behavior

Aggressive filtering can remove useful variation. Loose settings can create excessive event volume. The correct balance depends on the signal.

Asset Framework

AF adds context, but a wrong mapping can make a healthy source appear under the wrong asset or attribute.

Typical problems include:

• Broken PI Point references

• Incorrect substitution parameters

• Template drift

• Inconsistent units

• Obsolete elements

A structured validation process is important after bulk AF changes.

Calculations

Calculations can amplify upstream problems.

A bad input can create a bad output. A failed analysis can also leave a downstream value stale while the last numeric result still appears reasonable.

For critical analyses, monitor execution status and define how missing or bad inputs are handled.

PI Vision and downstream systems

A display can use the wrong server, tag, AF attribute, or calculated output. The display itself can function normally while the information is wrong.

The same issue can propagate into reports, cloud pipelines, and AI workflows.

Data quality can propagate

A source problem becomes more important as the number of downstream dependencies increases.

For this reason, a data-quality finding should include lineage and usage context when possible.

Manage degradation as an operating process

Use recurring checks for source freshness, bad states, point configuration, AF references, analysis health, and display dependencies.

Also review change history. Many data-quality problems begin after a normal engineering change rather than a hardware failure.

The objective is to detect where quality changed, understand what depends on the affected data, and restore trust before the problem spreads further downstream.