AF Analytics - Bad and/or Stale Value Filters

Blog Post created by asoudek on Aug 31, 2016

Check for system digital states before using them in calculations.  Validate whether the value is stale.

When dealing with real life systems it is highly unlikely that you will always have good data for your calculations at all times.  Therefore, it is important to provide filtering of the values that are
used in calculations to prevent failure of your calculations, thus providing the wrong information to the end user. 
There are a couple of scenarios that are the most common - Bad Values (System
Digital States) and Stale Values (value has not changed in a certain period of time).  Neither scenario is a desirable one.

The first scenario will cause your calculation to fail, seen in the Figure below where the Attribute Gas Flow has a digital state for part of the time range in question and the results for the expression are Calc Failed.


The second scenario is worse since we will have results for the calculation, but they are bogus and we would not know. (I have seen one example where a value was being used by the end user in analyses, but it had not changed in several days, unknown to the user.)  The examples below give some ideas on how to handle these situations.

Bad Value:

The following example just filters out the No Data (or any other System Digital State) and only writes back the results of the calculation when there are actual values for the Gas Flow Attribute.


When the Variable BadGasFlow is TRUE then no output is written to the Adjusted Flow Attribute.  Previewing the results shows what will be written, as shown in the Figure below.


Stale Value:

This scenario is often talked about and overlooked just as often.  In PI AF 2015, there is a new function, HasChanged(), that makes it easy to validate Attributes used in expressions in certain
circumstances.  The examples below demonstrate when to use this function to find a stale value and when to use a different approach.

When to use HasChanged()

This function should be used with caution and can give incorrect results if the expression is not configured correctly.  Take the following example.  The Attribute Trigger has values in
the PI Archive as shown in the figure below. Note the last value archived is the same as the previous value and is more than 10 minutes later.


So now we would like to see if the value of Trigger has changed in the last 10 minutes, in other words every time the expression is triggered evaluate if the value has changed in the last 10 minutes.  Writing the expression using the HasChanged() function and previewing the results gives us that the value of Trigger has changed for every evaluation, see figure below.
This is clearly not true for the last two values.  The IsStale Variable value should be False at 8/3/2015 12:57:53 pm.


This is because the Attribute Trigger was used in scheduling the expression as shown in the Figure below.  So when the expression is triggered, there is a new value in the PI Archive and so the function returns True even though the actual value has not changed.


If we modify the expression to include another Attribute, in this case Pressure, which is referenced to a PI Tag, then we can trigger it only on the Pressure Attribute.  Previewing results, we see that we get the behavior we expect, as you can see in the Figures below.


We can also revert to our original expression and schedule the expression evaluation on a Periodic basis.  In the Figure below, the periodic time evaluation is 10 minutes.


When NOT to use HasChanged()

The approaches above work fine except in the case where we want to use the change in the value of the attribute Trigger in the scheduling of the expression.  In cases like this we cannot use the HasChanged() function.


Note: Because different instruments will have different periods of time for the stale value test, it is a good idea to pass the time string above, ‘*-10m’, as a parameter from
an Attribute of the Element. (See the AF Analytics - Pass parameters using Attributes blog.)