How to Detect Stale or Flatlined PI Tags in the PI System

A PI Point can look valid even when the signal is no longer useful. The last value can remain on a display for hours or days with no obvious error state.

For this reason, PI teams should distinguish stale data from flatlined data and monitor both conditions.

Stale and flatlined are not the same

A stale tag has not received a new event within the expected time.

A flatlined tag can continue to receive events while the value remains constant.

The difference matters because the likely causes are different.

A stale tag can indicate:

• Interface or connector failure

• Network interruption

• Source-system outage

• Retired equipment

• A calculation that stopped writing

A flatlined tag can indicate:

• A failed or frozen instrument

• A constant process condition

• A control-system problem

• Excessive filtering

• A deliberately held value

Do not classify every constant signal as bad. Some signals are expected to remain constant for long periods.

Use expected update behavior

A fixed stale threshold does not work for every tag.

A one-second process variable and a daily laboratory result have different expected update intervals.

Define the expected update behavior by tag, asset type, or signal class. Then compare the last event time with that expectation.

This reduces false alarms.

Check the full data path

When a tag is stale, verify the failure point in order.

1. Confirm that the instrument or source system is producing data.

2. Check the interface or connector.

3. Check buffering or communication errors.

4. Confirm that the PI Point configuration is correct.

5. Check whether an analysis or application is responsible for the output.

6. Review recent configuration changes.

This sequence prevents unnecessary changes in the historian when the problem is upstream.

Detect flatlines with context

A flatline rule usually needs a time window and a minimum amount of expected variation.

For example, a vibration signal that has exactly the same value for six hours can be suspicious. A valve-position command can remain unchanged for the same period and be normal.

Use asset criticality and process context to choose the rule.

Consider compression and exception settings

A trend that looks flat does not always mean that the source was flat.

Exception and compression settings determine which events are sent and stored. Aggressive settings can reduce visible variation in archived data.

When the archive does not show expected movement, compare the stored history with source behavior and review the relevant point settings before you conclude that the instrument failed.

Prioritize by usage and criticality

Large PI environments can contain many stale points. Treating every stale point as the same priority creates alert noise.

Prioritize points that support:

• Critical equipment monitoring

• Alarms or operational decisions

• AF analyses

• PI Vision displays

• Regulatory or production reporting

A stale unused tag is a cleanup issue. A stale tag used in a critical calculation is an operational issue.

Monitor continuously

Periodic manual reviews can find old problems. Continuous checks can detect new problems before users report them.

A useful stale-data program combines expected update intervals, flatline rules, asset context, usage information, and recent change history.

The goal is not to flag every constant value. The goal is to identify signals that no longer behave as the plant and the data system expect.