Why Do PI Performance Equations Report Unexpected 'OFF' (FALSE) Values? A Deep Dive into Scan Timing and Data Latency

Availability calculations in OSIsoft PI are commonly implemented using Performance Equations (PEs) or PIPE calculations. These calculations often check whether process values (such as flows or analyzers) are within expected thresholds, returning 'ON' (TRUE) when the system is considered available and 'OFF' (FALSE) otherwise. However, engineers sometimes encounter a puzzling scenario: the availability calculation intermittently outputs an 'OFF' state, even though all source tags show valid ('GOOD') data for the same time window.

Let's explore why this happens, and how you can prevent it.

The Role of Scan Timing and Data Arrival

PI Performance Equations usually run on a fixed schedule, determined by the scan class assigned in PI. For example, a PE might evaluate every 2 minutes, looking at the latest available values of the input tags.

But here's where timing becomes crucial: if the freshest data from your flowmeter or analyzer tags hasn't arrived in PI by the time the PE executes, the calculation will use older ("stale") data. This misalignment can cause the PE to incorrectly return an 'OFF' state, reflecting past conditions instead of the current, valid status.

Visualizing the Problem

Consider a PE equation such as:

if 'TAG1' > X and 'TAG2' < Y then 1 else 0

If both tags update every minute, but the PE runs every 2 minutes, there's a risk that the PE's evaluation point may use outdated values, missing an update from a tag that arrived just after the previous scan.

How to Diagnose the Issue

1. Check Scan Classes: Are your PE scans running less frequently than your data source tags? If so, data might update in between PE evaluations.
2. Review Data Latency: PI interfaces may buffer or delay data transfer. If values appear in PI after the scheduled PE runs, the calculation uses the last available value, potentially leading to incorrect results.
3. Use PI Recalculator: If reprocessing historical values with PI Recalculator returns the correct results, it's a strong sign scan timing was the culprit, as recalculation uses all data that eventually arrives.

Solutions: Ensuring Accurate Availability Calculations

1. Align Scan Schedules

Set your PE's scan class interval so it's equal to or shorter than the update interval of all source tags. This reduces the chance of missing a data update between scans.

2. Delay PE Execution

Where possible, configure your calculations to run with a slight delay, ensuring all relevant data has arrived. Some interfaces allow for a built-in buffer or delay in execution.

3. Use Event-Driven Calculations (PI Analyses)

The most robust solution is to migrate your calculation to PI AF (Analysis Framework) and use an event-triggered analysis. In PI AF, you can configure an analysis to run whenever any of its input tags update (event-based). This guarantees calculations always use the latest values and eliminates timing-induced errors from mismatched scan intervals.

4. Monitor Data Quality and Timing

Regularly monitor both data quality and arrival time of source tags, and tune your PI infrastructure (interfaces, scan classes) to minimize delays.

Conclusion

Unexpected 'OFF' or 'FALSE' results in PI PE calculations for availability are often caused by mismatches between data arrival and calculation execution times. By understanding your PI system's scan and data flow schedules, and by moving towards event-triggered analyses within the AF framework, you can eliminate these frustrating data alignment issues and ensure accurate availability monitoring.

Key Takeaways

• Scan timing and data latency are critical in scheduled PE calculations.
• Stale data can cause false 'OFF' states even when source tags are GOOD.
• PI Recalculator may correct historical errors, confirming timing issues.
• Align scan times or switch to event-based triggered calculations in PI AF for best results.

---

Have you faced similar issues with PI calculations? Share your experiences or questions below!