Are you up for a challenge?

Hi everyone!

I’ve got a challenge I wish to share with you and hopefully get some ideas on a solution as my creativity, knowledge of PI, and patience have been pushed to the limits! J

Background:

I’m working on a fugitive emissions project for the mining industry. The purpose of the project is to implement a system to capture emissions data from our underground mines using Citect SCADA, historize all the data in our PI historian, calculate our emissions in volumetric tonnes (CO2 equivalent tonnes) using the PI ModuleDB and PI ACE, and report the volume of our emissions to our overarching systems such as our ERP and BI using PI OLEDB.

Instrumentation in our mine sites can be replaced due to damage, reliability, or accuracy, or temporarily changed for servicing (e.g. calibration).

Our data stream though cannot stop, as we require continuous monitoring (both for safety reasons and our calculations). As a result, we have primary instrumentation, and secondary instrumentation.

Primary instruments pass data that is deemed as reliable for our calculations. Secondary instrumentation passes data for validation purposes. The data from both types of instrumentation is captured and historized in PI.

As a result, we conceptually have two types of PI tags; primary and secondary tags. Primary tags collect and historize readings from primary instruments, and secondary tags collect and historize readings from secondary instruments.

The ModuleDB holds the mapping between our primary PI tags (as module aliases) and our required parameters for our PI ACE calculations.

Issue:

When our primary instrumentation changes for reasons described above, we need the primary tag changes reflected in the ModuleDB so our PI ACE calculations can retrieve the correct data.

Because the ModuleDB does not have any effective and obsolete dates for module aliases, we have an issue on how we can capture the instrumentation change-out, and therefore tag mapping changes, for our PI ACE calculations and recalculations, whether it’s a permanent or a temporary instrument change.

Here's an example of the issue:

Tag “Pressure_01” is a primary tag that collects and historizes all the pressure readings from the mine’s primary instrument. Being a primary tag, it’s data is used for our PI ACE calculations.

If the primary instrumentation measuring pressure changes, we must create a new tag “Pressure_02” to collect and historize all the pressure readings from the mine’s new primary instrument.

NB. The process of creating a new tag is required as new instrumentation may be recording in different units of measure (engineering units attribute on the PI tag), which are critical for our calculations (e.g. measuring pressure in kPa vs. Pa, the difference in UoM significance is 1000 times!). Our PI ACE calculations have been coded to include conversion logic between recorded UoM’s vs. required UoM’s for our calculations (e.g. if our calculations require pressure in kPa, but the instrument is recording in Pa, simply divide the tag’s data by 1000 to get the relative reading in kPa).

As a result of the primary instrument change and new tag creation, we must then update our ModuleDB alias to retrieve pressure data from tag “Pressure_02” for our PI ACE calculations.

If we change the ModuleDB alias for ‘Pressure’ to now point to tag “Pressure_02”, if recalculations need to take place sometime in the future for a period starting past the creation date of “Pressure_02”, no pressure data will exist as all that data was historized in tag “Pressure_01”.

Challenge: How do we get around this?

Solutions considered but rejected are (I’ll continue with the example used above for ease):

1. Have an intermediate PE tag called “Pressure”, which all it does is replicate (using the PrevVal() PE function) readings from our primary tags “Pressure_01”, and then “Pressure_02” when the instrumentation changes. That way we no longer need to change any aliases in the ModuleDB! Hooray!  But… the problems with this solution are:
   1. If the data in the “Pressure_01” or “Pressure_02” tags are substituted/corrected by operators, the changes will not replicate on to the intermediate tag called “Pressure”. This of course could be overcome if the operators review and correct the “Pressure” tag’s data, but this links on to problem b. below.
   2. Responsiveness of PI Administrator to update the PE tag to now point to the new tags. If the PI administrator is notified of the change-out of the instrument, he/she must be quick to amend the “Pressure” intermediate tag to retrieve the data from “Pressure_02”. If not done immediately, that’s more work for the operators as they need to review and substitute more data!
   3.  “Spaghetti” tags – Chained links of tags increases complexity, risk of error when changes are required, and most importantly traceability (our auditor friends will not be happy!)
2. Forget about intermediate tags and creating multiple tags recording the same attribute (pressure). Have only one single tag capturing the pressure readings from the primary instruments. If an instrument changes, simply update the instrument tag field on the PI tag for the data to now be collected and historized from our new primary instrument. Well, what if the instrument has different UoM’s (remember my example above of kPa vs. Pa?). Our calculation results will be incorrect!
3. Similar to solution 2, have only one single tag capturing the pressure readings from the primary instruments. If an instrument changes, update the instrument tag field on the PI tag, but this time also update the engineering units of the PI tag (e.g. from Pa to kPa). Hmmm… what if we choose to recalculate for a period past the instrument change? Our as reading UoM’s will be different, thus our recalculation results will be incorrect!

If you are still awake, and have some ideas to share to solve this challenge, please do! J

Thanks guys!

Cheers,

Mario