KB00868 recommends Asset Analytics as the right job, but there are some major limitations that inhibit ease of use and deployment, specifically around operations on >1 attribute or tag simultaneously.

To improve this, AF analyses functions that take in data of type "attribute attname" should be able to process an expression that returns type attribute. Perhaps limited to periodic analyses other toggleable somehow, as there is potential to use a lot of CPU cycles.

== Example 1: Totalized Mass Flow ==
Given FIT-001 and DIT-002, return the totalized mass flow (say, kg) over an interval. The current process:
1. Create short-interval periodic, or event-based analyses to write the product of flow & density to a tag-linked attribute WIT-003 (I don't think you can use an attribute as we care about the history).
2. TagTot(WIT-003, '*'. '*-1w')
Better solution:
AF should be able to see that I'm asking for a 1-week total of an expression, so run the expression and totalize the result.
TagTot((FIT-001 * DIT-002), '*'. '*-1w')
This is basically what the SUMPRODUCT function in Excel does, and we haven't found a better way to do it in AF yet.

== 2. Conditional Expressions ==
We monitor processes and create KPIs for utilization and value delivered. PIAF makes it cumbersome to compute utilization or value based on multiple conditions. Utilization of an application APP-001 might depend on x=1, y=2, z=3.
Current process:
1. Create short-interval periodic, or event-based analyses to write the result of ('x' = 1) AND ('y' = 2) AND ('z' = 3) to a tag-based attribute, MYTAG-001.
2. Create an analysis to run TimeEq('MYTAG-001', '*', '*-1w', 'true')
Better solution:
AF should be able to process something like this:
TimeEq((('x' = 1) AND ('y' = 2) AND ('z' = 3)), '*', '*-1w', 'true')

The current process is inefficient and a bad use of tags (both a waste of a tag license and adding a low-value intermediary calculated result to the data archive). There are also complexities around scheduling the preliminary analytics to ensure the results are ready for the insight-generating analytics.

Thanks for your feedback. I'd also be overjoyed to hear there's an easy solution we're overlooking.

By now the NumOfChanges Function in AF Analytics does not take into account the value at the start of the timerange. NumOfChanges only counts the amount of changed values of the recorded values in the given timeframe.
If I query the NumOfChanges for today 12 am till now and my Archived Values are:
Val1, 11:59 pm (day before)
Val 2, 4 am
Val 2, 12 pm
Val 2, 8 pm

the function will result in 0 although in the time from 12 am to 4 am there was Val1.
Regarding TechSupport this is not a bug in the functionality, only a bad description of the functionality of NumOfChanges.

For now I built a workaround:
If TagVal(Tag,Starttime) <> NextVal(Tag,Starttime) THEN NumOfChanges + 1 ELSE NumOfChanges

But I think such a missleading function should be changed.

From a varying number of child elements (all sharing the same template), I want to find the most recent timestamp of a same template-based attribute, and output the value with timestamp to an attribute in the parent element.
In addition, constantly (event-triggered/periodic) comparing the timestamps of these child element attributes and always output the "newest" value to the parent element attribute.

Example:

From 3 child elements, all sharing the same template with attribute "ALARM", I want to have the most recent value comparing the 3 "ALARM"s, and have this timestamp and value in an attribute in the parent element.

Suggestions for enhancement:

- Function in Rollup Analysis which compares timestamps of template based attributes and outputs the most recent timestamp (with value!).

Safeguard against multiple analyses writing to the same PI Point. Currently it is possible to configure more than one analysis to write to the same PI point. This is a problem since it often goes undetected until someone looks at the data and sees unpredictable results. The road to finding which analyses is usually long and tedious. In my opinion, one improvement would be to either:
1. Safeguard so that it is impossible to configure the system so that more than one analysis cannot write to the same PI Point
or
2. develop a mechanism which warns about this configuration (if OSIsoft deems this behavior valid and an acceptable use case)

Use case:
1. An element has an attribute that looks up information on equipment configuration (ex: a pump rate)
2.  Due to an equipment change, the lookup table and the element were increased in version
3. A backfill needed to be performed on an analysis that included the attribute which changed, and the date range spans over multiple version effective dates. The desired behavior would be to use the latest version of the attribute's value since the last effective date, and the previous version of the attribute's value before the last effective date.
4.  Currently, the backfill cannot go further back than the effective date of the current version.

Created on behalf of a customer:
In order to use fewer attributes in an element, a customer hoped to output analysis results to an attribute with a dynamic PI Point data reference. Unfortunately, with the use of substitution parameters or with string builder, the "dynamic" PI Point data reference will only resolve the tagname once - upon creation (or when the data reference is manually updated). It doesn't act dynamically because it's not actually designed to act that way.

The current workaround is to create all necessary output attributes, categorize them, and flatten/hide/minimize all categories containing the attributes that are not important at the time to reduce clutter.