PI Asset Framework Best Practices: Designing Reliable Asset Models in the PI System

PI Asset Framework adds operational context to time-series data. A good AF model makes equipment, signals, calculations, and relationships easier to understand and reuse.

Poor AF design creates the opposite result. Templates drift, attributes map to the wrong tags, and analyses become difficult to maintain.

Start with the use case and the physical model

Do not begin an AF project by creating a large hierarchy.

First identify the decisions and workflows that the model must support. Then define the physical equipment and process structure that users need to navigate.

A useful hierarchy is usually stable and understandable to operations and engineering teams.

Avoid creating hierarchy levels only to match an organizational chart. Organizational structures change more often than equipment structures.

Use templates for repeatable asset types

Templates are one of the strongest features of AF. Use them when multiple assets share a common structure.

A good equipment template can define:

• Standard attributes

• Engineering units

• Data-reference patterns

• Analysis templates

• Event-frame logic when applicable

• Categories and traits

Keep templates focused. A single template with many optional attributes can become difficult to govern.

Separate source mapping from asset meaning

An AF attribute should have a clear business or engineering meaning. The data reference connects that meaning to a source.

For example, the attribute can be named Discharge Pressure even if different sites use different PI Point names.

This separation lets the AF model remain consistent when source naming differs by site or control system.

Validate attribute mappings

Template deployment can create a large number of mappings quickly. It can also repeat a mapping error across many assets.

Validate:

• PI Point existence

• Correct server and point name

• Engineering units

• Expected data type

• Expected update behavior

• Correct substitution parameters

Use sample assets from each equipment class and site before large deployment.

Design analyses for maintainability

Use analysis templates when logic is truly common across similar assets.

Keep expressions readable. Use meaningful variable names. Avoid long chains of hidden dependencies when a simpler design is possible.

Document:

• Calculation purpose

• Inputs

• Output

• Schedule or trigger

• Expected behavior for bad or missing data

Monitor analysis status and performance after deployment.

Control template changes

A template change can affect hundreds or thousands of elements.

Before a material change, identify which elements and analyses use the template. Test the change in a controlled environment when possible. Record the reason for the change and the expected effect.

This is where dependency and change history become important.

Keep the model aligned with the plant

AF becomes less useful when the digital structure no longer matches the physical facility.

Use a process to update AF after equipment replacements, project handover, control-system migrations, and major MOC work.

Do not assume that project deliverables will update the production AF model automatically.

Avoid common design problems

Common problems include:

• Copying assets instead of using templates

• Inconsistent attribute names for the same measurement

• Mixing source-specific names with business meaning

• Creating deep hierarchies that users cannot navigate

• Using formulas where stored analyses are required

• Leaving obsolete analyses enabled

• Allowing template changes without impact review

The objective of a good AF model

A reliable AF model gives users a stable semantic layer over PI data. Engineers should be able to find an asset, understand its attributes, verify the source data, and reuse common analytics without reverse engineering the system.

That outcome requires both good initial design and continuous governance.