Making Sense of PI Calculations: AF Analyses, Performance Equations, Formulas, and Totalizers

PI environments can contain several calculation technologies. Each has a different operating model and maintenance profile.

The correct choice depends on whether the value must be calculated on demand, scheduled, stored as history, or maintained in a legacy architecture.

AF Formula data references

AF Formula data references calculate a value when the attribute is requested.

They are useful for relatively simple calculations that do not require a stored output history.

Consider the cost of repeated calculation when many users or applications request the value frequently.

AF Analyses

AF Analyses support scheduled and event-triggered calculations and can write results to history.

They are usually the preferred calculation framework for new AF-based applications because they work with templates and asset context.

Manage them carefully at scale. A small inefficiency in one template can become significant when deployed across thousands of assets.

Performance Equations

Performance Equations are common in older PI environments. They can remain valid for existing applications, but they are more difficult to govern centrally than AF analyses.

Do not migrate a stable legacy calculation only because it is old. Migrate when the change improves maintainability, performance, supportability, or governance enough to justify the risk.

Totalizers

PI Totalizers are also common in legacy systems for aggregate calculations over time.

Review existing totalizers during modernization projects, but preserve them until the replacement has been tested against historical behavior.

Choose based on requirements

Ask:

• Does the result need history?

• How often must it calculate?

• Is the logic reusable across an asset template?

• How does it handle bad or missing data?

• How important is auditability and change control?

• What is the expected calculation load?

Monitor performance

For AF Analyses, review lag, skipped calculations, repeated errors, and expensive templates.

For all calculation types, track downstream dependencies so teams know what is affected before a change.

Avoid hidden logic

Document important calculation purpose, inputs, output, owner, and expected behavior.

A technically correct formula becomes an operational risk when nobody can explain what it does or what depends on it.

Modernize with evidence

Do not use a rule such as "all formulas must become analyses" or "all legacy calculations must be removed."

Use measured performance, maintenance burden, business criticality, and future architecture to decide.

The goal is a calculation landscape that is reliable, understandable, and supportable, not a specific technology for every use case.