Scaling Analytics successfully using the AVEVA™ PI System™
Steve Taylor, Principal Systems Engineer at ITI Group, offers:
Expert insight on UOM Databases and PI System analytics …
Real-time analytics projects usually begin with great excitement – crafting the minimum viable product (MVP) to prove the concept – but often lacking the Governance necessary to ensure success. 12-18 months later, Technical Debt has accrued steadily and begins to impact delivery timelines. In hindsight, it is often recognised that it takes more than IT know-how to correctly handle Engineering data.
Before I became a PI System Integrator, I spent many years as an end user, building spreadsheets and tools gathering real-time data to produce statistical summaries. Data from hundreds of sensors were constantly processed and combined to create a rich overview of asset production, allowing us to forecast those figures into the weeks and months ahead.
Summarising data in this manner is no mean feat – between the source instrument and final report, the data is normalised, corrected and converted. The Engineering Units applied at each stage are critical to ensuring the final figures are precisely correct – if you assign the wrong units to any figure at any point in the process, you’re in trouble. I knew the common conversion factors off by heart, and for completeness had them scrawled on a piece of paper above my desk.
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.
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.
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.
DOMAIN KNOWLEDGE AND GOVERNANCE ARE ESSENTIAL
Traditional IT contractors struggle in this space because they lack the engineering context awareness to discern fact from fiction in a UOM Database. For the uninitiated, it can be nearly impossible to identify, correct and validate UOMs without incurring later rework – knowing how to craft and shape the database effectively can be challenging even for those who know the problems well.
The layers of protection can become immense hurdles to harmonisation, which has led to others taking drastic steps – migrating or deleting vast portions of configuration, or resorting to intricate database modifications that circumvent these layers, against vendor recommendations. However, by creating and leveraging modern automation tools our own people have safely rearchitected and merged large and complex UOM databases, no matter how great the challenge.
Businesses reach out to ITI Group time after time because our team possesses the necessary mixture of domain and technical knowledge required to bring harmony to UOM Databases and the Analytics that use them. We understand the common pitfalls and challenges well, and are not only able to resolve the chaos, but then to help the organisation put in the kinds of processes and governance that allow the system to mature safely over time without incurring further rework.