Over at https://www.trendminer.com/osisoft/ it’s stated that “TrendMiner works on top of your PI System and makes the time-series data directly available for advanced analytics through plug & play connectivity to all historical data for batch, continuous or asset analytics”. 

However, what’s not clear until connecting Trendminer to Asset Framework is there are only two narrow integrations between Trendminer and PI AF:

1. PI Event Frames (imported/linked as Context Items), and 
2. PI Asset Framework attributes which are configured with PI point data reference types. 

What this means is that any information stored/calculated/referenced in attributes in your AF hierarchy not explicitly linked to a PI tag is invisible to Trendminer. 

In this (dated) stock screenshot below, only the “Level”, “Mixer Speed”, “Pressure”, and “Temperature” attributes would be accessible in Trendminer, where useful configuration items like Diameter, Height, and Product are invisible to TM, along with useful AF-calculated formula data references like Heat Capacity and Volume. 

Here are a few examples from our AF deployment where we 

Example #1 – Simple constant values in PI AF Attributes

In a bunch of places in AF we have thresholds and limits set up that are then used in PI Vision Graphics and PI AF analytics/calculations. In the simple example below, the “Vapourizer Temp High Limit” would not be visible in Trendminer since it’s a constant value and not linked to a PI tag.

The use case is being able to use that constant value as an input to Trendminer calculations, monitors, etc. 

Since this is invisible to Trendminer, users would be unable to set up any kind of calculation or analysis that takes the limit value into account (they’d have to duplicate the value in Trendminer - and this crudely requires generating a Trendminer “tag” from a formula outputting a constant value to do so). 

In addition to constant values in AF Attributes, we also have limits in AF tables (either an internal SQL table in PI AF or a linked table) so that the constants can be integrated into other applications as well...

Example #2 – Import tabular data as time-series PI AF Attribute

Here’s a simple example where a (poorly-named) Attribute called “NEWEST TABLE VALUE TEST” is set up as a Table Reference which basically does a “SELECT * this_table” from a Linked Table in AF. The Attribute is then available in PI Vision and AF analyses for trending and/or incorporation into analytics.

This linked table-based trend data is wholly unavailable in Trendminer. 

Example #3 – Laboratory Information Management System (LIMS) Data

Our most-used and most-valuable linked table is our laboratory sample data which originates in SAP and is accessed in PI AF via linked table - over 2,000 lab sample points configured in AF! Each lab sample point has four unique parameters that we have in AF set up as constants (highlighted orange below; similar to the value in Example 1) which are then passed into a Table Reference query, which then returns values specific to that sample point from the table (highlighted green).

We are relatively new to Trendminer, but not having our LIMS data available alongside our process data is a big gap. 

Possible (Rejected) Solutions

We’ve considered and rejected a few possible solutions:

1. Build PI tags for all non-PI Point AF data references and basic configuration attributes. This is infeasible for many reasons: 
   • The time it would take to tag-ify the sheer number of attributes.
   • Related, to that, the assed load and management on the PI AF server of thousands of low-value Asset Analytics that simply read a table and write the result to tags.
   • PI tag licensing considerations. The PI tags have an associated cost, and there’s zero value in storing something in a tag that can be stored/referenced/calculated in an AF attribute. 
2. For LIMS and other linked tables, link them to Trendminer directly. This is undesirable as we’ve invested in Asset Framework as a central “hub” of operations and process data. We have over 100 linked tables in PI Asset Framework and have no desire to duplicate these connections in Trendminer and other tools that may come along. 

For discussion… I would love to hear if other Trendminer/PI users are experiencing similar constraints, or have possible workaround ideas we have not considered. 

Returning to my first paragraph, may I suggest https://www.trendminer.com/osisoft/ is updated to say Trendminer “mostly works on top of your PI System and makes the time-series data (and only time-series data, which must be explicitly stored in PI tags) directly available for advanced analytics...”