Dynamically Setting Source UOMs in AF Templates: Streamlining PI System Management

Dynamically Setting Source UOMs in AF Templates: Streamlining PI System Management

When managing a PI System environment, one encounters both the beauty of scale and the beast of complexity. As organizations seek to leverage templates in PI Asset Framework (AF) for consistency and efficiency, one recurring challenge is handling multiple units of measure (UOM) among heterogeneous data streams. Specifically, users grapple with automatically setting a source UOM in AF that corresponds to the engineering units of a referenced PI Point while preserving template integrity.

The Challenge

Imagine having a PI System where you want to monitor mass flow for different pumps. Each mass-flow attribute is backed by a PI Point varying in UOM, such as pounds per hour (lb/hr) or kilograms per minute (kg/min). However, your standardized AF template has a default UOM like pounds per minute (lb/min). The dilemma arises because AF doesn’t natively auto-convert the PI Point’s UOM while maintaining the default value in your template. Changing the source UOM post-creation breaks the element's tie to the template, leading to an inefficient and cumbersome process when repeated thousands of times.

Potential Solutions

Some initial thoughts might include creating derived templates for each UOM combination. Yet, this can quickly become an untenable approach, since it multiplies the number of templates, counteracting the simplicity that AF templates aim to provide.

A Strategy for Efficiency

Currently, there’s no direct substitution parameter available in PI System Explorer (PI SE) that allows the engineering units from a PI Point to dynamically populate into the attribute’s configuration string. However, leveraging tools like PI Builder and Excel, you can manage bulk updates effectively without manually breaking templates.

Implementation Workflow:

1. Harnessing PI Builder: Use PI Builder to export the needed attributes with their corresponding ConfigStrings and default UOM values.

2. Excel Power: Excel becomes a powerful ally where the exported data can be manipulated. Utilize IF statements and string concatenation within Excel to adjust the ConfigStrings. For example:

   =IF(F2="", J2, J2&";UOM="&F2)
   

   Here, F2 is the column with the default UOM, and J2 contains the original ConfigString.

3. Data Publishing: Once the ConfigStrings are correctly adjusted in Excel, use PI Builder to publish these changes back to PI AF, applying them in bulk across your elements.

Storing as a Separate Attribute

As a part of this procedure, you might consider storing the UOM as a separate attribute within each element. Although manual, it provides a reference point within your data models, potentially simplifying future changes or validations.

Conclusion

While there isn’t a built-in feature in PI System Explorer to dynamically adjust source UOMs based on PI Point metadata, by creatively employing PI Builder and Excel, users can achieve an efficient workaround. This method ensures that PI System remains scalable, offering both customization and template integrity without an overwhelming administrative overhead.

Looking Forward

The community feedback channels and enhancement requests, such as those on OSIsoft forums, are crucial. A native solution could dramatically simplify these types of challenges. Continuing dialogue and input from users will likely lead to new functionalities making it simpler to manage UOMs dynamically within AF templates, driving both usability and adoption.