Building Flexible PI AF Templates with Variable Tagname Patterns

When working with OSIsoft PI Asset Framework (AF), creating reusable templates is essential for scalable management of assets and data references. A common challenge is mapping PI Point attributes where only part of the tagname is fixed while other sections—such as asset descriptors or characteristics—vary in both content and length. In this post, we’ll explore strategies for designing AF templates that flexibly handle such PI tag name patterns, specifically for cases like FLOW...PV, where the middle section is variable.

The Challenge: Variable Tagname Sections

Suppose your PI Point naming convention follows this structure:

FLOW[.Descriptor1][.Descriptor2].PV

• FLOW is a fixed prefix.
• .PV is a fixed suffix.
• Descriptor1 and Descriptor2 are optional and can be any string.
• The number and values of descriptors vary by tag.

Example PI Points:

• FLOW.PV
• FLOW.WATER.PV
• FLOW.OIL.DISCHARGE.PV
• FLOW.LIQUID1.OUT.PV
• FLOW.DISCHARGE.PV

Your goal: Create one AF Template that can dynamically match the appropriate PI Point for each asset, without manually hardcoding or specifying the variable descriptors for every element.

Why is This Hard?

The AF Template’s PI Point Data Reference supports using substitution parameters (like %Element%, %Attribute%), but out-of-the-box, it does not natively support wildcard matching or regular expressions in the PI Point Name, and cannot dynamically "discover" a tag based only on fixed leading/trailing parts (unless you provide more context).

Common Workarounds

Here are some approaches AF practitioners use to address this issue:

1. Use Element or Attribute Data to Fill Gaps

If your descriptors are properties of the element (e.g., MaterialType,Characteristic), define these as string attributes (no data reference), then use those as substitution parameters in your attribute’s PI Point data reference:

FLOW.%MaterialType%.%Characteristic%.PV

When an element lacks a descriptor, you leave the corresponding attribute blank, making your PI Point reference resolve to:

FLOW..PV

While not ideal, PI ignores the extra dot if the tag exists as such. Otherwise, you may have to manage these edge cases separately.

2. Use Multiple Attributes (One Per Tag Pattern)

Define several attributes in your template for each possible tag structure:

• Attribute1: FLOW.PV
• Attribute2: FLOW.%MaterialType%.PV
• Attribute3: FLOW.%MaterialType%.%Characteristic%.PV

This keeps templates manageable but requires users to know which attribute to use per element.

3. Use PI Tag Search or Programs for Mapping (Advanced)

If you want to avoid hardcoding and have the system auto-discover the appropriate PI Point given only the bookends (e.g., FLOW at the start and PV at the end), you’d need an external mapping:

• Maintain a mapping (via a CSV, database, or AF Table) that links elements to PI Points.
• Use AF Table Lookups or custom scripting (e.g., AFSDK in C#) to find/tag the correct PI Point at runtime based on search criteria.
• As of today (2024), AF templates themselves do not support wildcard/discovery logic in substitution parameters for PI Points—they require explicit names.

4. Leverage PI Vision or Custom Scripts

For display or ad-hoc analysis, consider using PI Vision (which allows searches with wildcards) or write a custom Asset Naming Logic in C#/Python with AFSDK/PI Web API to manage mappings or surface the most likely tag to the user.

Takeaways and Recommendations

• Direct wildcard or regex matching in AF substitution parameters within templates is not supported.
• Best practice: Store descriptors as attribute values and use substitution parameters to assemble the PI Point name.
• For highly dynamic tagname environments, an external mapping or program may be necessary.

Example Template Attribute Configuration

PI Point Name: FLOW.%MaterialType%.%Characteristic%.PV

• %MaterialType% and %Characteristic% are string attributes (put blank if absent).
• For FLOW.WATER.DISCHARGE.PV, MaterialType=Water, Characteristic=Discharge.
• For FLOW.PV, both blank.

Closing Thoughts

If you’re faced with a highly variable tagging schema, consider advocating for more consistent conventions or implementing a database/mapping step. Until AF templates allow wildcards or dynamic discovery, thoughtful use of substitution parameters, attribute design, and external mapping remains the most sustainable solution.

Have you dealt with complex PI Point naming patterns in AF? Share your tips in the comments!