Scaling Analytics successfully using the AVEVA™ PI System™

PI AF Units of Measure

This is why I love PI AF’s Unit of Measure Database: a single source of truth for all units and conversions. Each Class is a controlled group of Units of Measure (UOMs) which are interchangeable with one another. They set strict boundaries for data, facilitating accurate data handling and preventing users from attempting nonsensical conversions.

ITI Group’s PI AF Developers have used these features to great effect, creating Templates and Analytics that scale quickly across assets in any region, regardless of the unit set the region utilises. They no longer have to worry about identifying and writing manual conversion factors into every calculation, nor redesigning calculations every time they encounter sensors applying different units.

Figure 1 - Heat Transfer Units of Measure

The UOM Database is thus a simple yet powerful component of PI AF, but its layers of protection are surprisingly complex:

• If a UOM is in use by any object on the AF Server, it cannot be deleted and its Abbreviation cannot be modified. This can include hidden metadata, which is especially difficult to locate.
• UOMs cannot be moved across Classes. If a UOM has had its Class assigned incorrectly, you must Delete the UOM.
• UOM Classes are based on a single Canonical Unit, which cannot be reassigned. If you are the unfortunate soul whose entire Class is based on the wrong UOM, every single unit in the Class must be deleted in order to recreate the Class!

These Layers of Protection are incredibly helpful when your UOM Database is in good shape and prevent anything from breaking, but in a poorly designed database these can make the process of rationalisation surprisingly slow and painful.

Closing the stable door after the horse has bolted

Tragically, we often hear from customers who have realised the significance of the UOM Database far too late in their development process: their developers have already created dozens of Classes and hundreds of UOMs without any approvals or oversight. Consequentially, the conversion factors are hit-and-miss, the abbreviations are inconsistent and the Classes are in chaos.

This is compounded further by the possibility of different UOM databases being accidentally superimposed upon one another. An unregulated set of units from a Development instance or from a remote supplier is often copied accidentally when a database is deployed, which overwrites and expands the existing UOM Database. Often this may not even be noticed until months later.

Figure 2 - Poor governance leads to nonsense conversions and incorrect data

For some clients, this is not an isolated problem – perhaps two or three different business segments have all generated their own UOM Databases, and are now seeking to rationalise large sets of similar but diverse UOMs to create a single corporate standard. In the most extreme cases we’ve supported customers in harmonising databases from 22 different PI AF Servers, and put in place systems to keep these synchronised going forward with minimal effort.