OSISoft customers across a spectrum of industries see a huge need for Asset Frameworks for their PI System data. Despite this, only a small percentage have deployed these capabilities. Companies that are using asset frameworks generally aren’t happy, complaining about the lack of quality and consistency. And few companies – less than one in five – have taken steps to make their asset frameworks more valuable by adding data related to quality, financials and other metrics.
These are among the findings of a survey that we conducted of PI System users, for our State of the AF Report. The results, and the potential solution, should be of interest to every industrial company. The Survey is ongoing, but of the dozens of respondents we have to date, from industries as varied as power generation, upstream oil and gas, manufacturing and chemical processing, the alignment around the need for AF and the lack of broad adoption is apparent.
OSIsoft’s PI System has become a foundational element for industrial operations around the world. More than 1,000 leading utilities, 80 percent of the world's largest oil and gas companies and 65 percent of the industrial companies in the Fortune 500 use the PI System. In all, more than 2 billion sensor-based data streams around the world are managed by the PI System
A potentially important component of PI System, the PI Asset Framework, has been in the market since 2007 and bundled with the PI System since 2010. Its considerable value lies in organizing PI Tags (a time-series data stream, typically a sensor reading) so PI System users can see all needed information at a glance and share it with parties who need access to the PI data for analysis. This “global view” can, for example, help quickly identify why a process isn’t operating properly, or flag problems before they happen.
Briefly, the PI Asset Framework is a hierarchy-based, contextual model that is stored on the PI System. The hierarchical structure enables PI System users to drill down and find the PI Tag of interest. Think of it as something similar to the directory structure you build to organize the files on your computer. Each of the directory levels in the PI AF provides contextual information about the PI Tag’s location-- critical information that makes PI System data easier to find, share, and collaborate upon.
So, what’s causing the adoption inertia? Let’s take a look.
The data we’ve collected so far in our customer survey reveals notable insights:
PI AF Survey respondents resoundingly say “YES” when asked if the market needs an Asset Framework. They emphasize the need to share their PI data with those in their organization who are unfamiliar with PI Tag naming conventions but need to extract business insights from asset and operational data. In fact, to get the most out of PI Vision, PI Integrator, and much of the PI Partner Ecosystem - you need an Asset Framework.
Customers keep asking for a way to share their PI data with those that need to extract business insights from asset and operational data but are not familiar with the PI Tags.
– AF Survey Results
In our conversations with the PI community, we’ve narrowed the roadblocks to AF adoption into five important areas:
1. The need for a contextualized, digitized, hierarchical model
As you build out your data-driven, digitized, hierarchical model with PI data, our Report indicates that AF builders are looking to bring in context that is not in the PI System. Often, they need to include data from other systems including:
As these sources undergo contextual changes (for example, if an EAM system records a part replacement), users want their AF PI model to update immediately with the new metadata.
Additionally, PI respondents are looking for ways to harmonize the PI-driven AF model across all their systems. The hierarchical model doesn’t need to store the same information across all systems, just be organized in the same way across each system. You can use PI via Table References to encode the information, but this is hard to maintain and scale across the enterprise, given the complexity of IT governance requirements.
2. The need for speed (the time it takes to build an AF model)
It takes way too long to build out a single AF for a site or facility. For example, it can take up to six months for a complex asset like a chemical plant. One respondent said it took his organization north of 18 months for a single paper mill.
OSI provides an Excel-based plug-in (AF Builder) to ease this, but you’re still mapping everything manually, one at a time. As AF requirements increase beyond simple, process-based analytical applications, AF build times increase exponentially. Under these conditions, getting an enterprise-scale, contextual, AF model seems impossible to build, let alone maintain.
3. The need for ongoing maintenance (the time it takes to keep the AF model up-to-date and accurate)
Once you’ve got an AF model, the next question is: “how do I keep the AF up-to-date with all the operational and maintenance changes?” Keeping an AF model up-to-date, or evergreen, poses major challenges and requires its own strategy.
PI AF uses substitution parameters to make this process easier, allowing you to create an AF structure without PI Tags and then using the structure to generate the tags. Substitution parameters also allow you to map future tags, based on a common naming convention. In either case, these approaches assume that your existing PI Tags are uniformly named and that you will continue to maintain the same naming convention.
The analogy I like to make here is to imagine the internet was organized in a way where you memorized the naming convention of IP addresses to get to the internet site you need. Or the DNS table looked at the websites by the convention of the IP address.
This is a brittle way to organize your data and keep it up-to-date.
4. The need for a flexible, AF hierarchical structure
Hierarchical models, by definition, have structure. The AF’s hierarchical structure stores the context of how your assets relate to each other in a set of “parent-child” relationships. The resulting model has a static, pre-structured, format. This can create a roadblock for AF buildouts as you may need additional use cases to add context to the structure.
Even if you maintain additional structures, it gets difficult to get agreement and keep the relationship information constantly up-to-date across all of those structures. PI attempts to address this through object reference but those are about the objects themselves, not about the relationship between objects in the AF model - creating a limitation in the model.
Our Report indicates that AF users are looking to store just the relationships, thereby providing users the flexibility to generate whatever structure they need, for a given use case. This way they are just managing relationship information, not 10s or 100s of hierarchical structures.
5. The need for an AF strategy to deploy across the enterprise
The AF model has to be enterprise ready. This implies that a fully functioning AF allows people to collaborate, establish governance controls, and track versioning throughout the system. It should provide check-in/out features and some integration with an authentication and authorization tool, such as Azure Active Directory, for security regarding who can access what on the hierarchy. Currently, AF models do not support approvals, collaboration, commenting, and version management. These requirements make it hard to implement AF at scale.
Our analysis has shown that all of the PI features (Table references, substitution parameters, and AF Builder), provide partial solutions to the larger need for a flexible, enterprise-scale, contextual asset data model. With this in mind, we developed our AssetHub™ software from the ground up to make building and maintaining an Enterprise Asset Model achievable. AssetHub allows users to build, assure, and rapidly share the most current asset data within and across organizations. And we’ve developed a program to help our customers get started called Asset Framework Accelerator, to make it easy to build and scale quickly.
Using the Asset Framework Accelerator, industrial companies can build Asset Frameworks 10 times faster than with conventional methods. In addition, the Asset Framework Accelerator eliminates the need to hire systems integrators or manually create and maintain spreadsheets. Finally, once an asset framework is built, information in the framework is constantly, automatically updated and can be shared across an enterprise. Also, more asset frameworks can be quickly built using the original asset framework as a model,
Our surveys show that industrial enterprises are eager to make use of their data for value-add analysis. Achieving this goal requires building reliable and scalable asset frameworks in an efficient manner. The quickest, most reliable and most scalable way to do this is by using the Element Asset Framework Accelerator.
Any questions?
If so, get in touch with us at accelerator@elementanalytics.com
