Troubleshooting Common PI AF Analysis Runtime Errors: How Osprey Can Help

PI AF Analysis errors usually come from configuration, unavailable inputs, output problems, or service performance. The fastest troubleshooting method is to verify the analysis in a consistent order.

Do not treat the error text as the complete diagnosis. Use it as a starting point.

Verify analysis configuration

Confirm that the analysis is enabled and that the expression is valid.

Review:

• Input attributes

• Output attribute

• Data types

• Schedule or trigger

• Analysis template substitutions

• Output history configuration when applicable

For template analyses, verify a failed example and then determine whether the same condition exists across other elements.

Check missing or bad inputs

An analysis can fail or produce no output when an input is unavailable.

Trace each input to its source. Check the PI Point or data reference for current values and quality states.

If bad or missing data is expected occasionally, define explicit handling in the expression. Use supported analysis functions and test the behavior before deployment.

Check output configuration

If an analysis writes history, verify that the output attribute and target PI Point are configured correctly.

Check:

• Data reference

• Target point existence

• Security and write access

• Point creation state when the point is new

• Whether another process writes to the same output

Do not create competing writers for the same calculated point.

Review runtime and service health

If many analyses fail or lag at the same time, the issue can be service-level rather than expression-level.

Review:

• Calculation lag

• Skipped calculations

• Service status

• Workload trends

• Repeated failures by template

A single expensive analysis can also create pressure when it is deployed across many assets.

Review dependencies

A failed analysis can affect other analyses and displays.

Identify downstream dependencies before you disable, change, or backfill an important calculation.

Review recent changes

Compare the failure start time with changes to:

• Input tags

• AF attributes

• Templates

• Analysis expressions

• Servers

• Security

A runtime error that starts immediately after a configuration change often has a direct relationship to that change.

Verify recovery

After the correction, confirm that:

• The analysis returns to a healthy state.

• New output values are written as expected.

• Required historical recalculation is complete.

• Downstream analyses and displays recovered.

For important calculations, record the cause and corrective action.

A disciplined sequence of configuration, input, output, runtime, dependency, and change checks is more reliable than trial-and-error troubleshooting.