Version dependent analysis

Unfortunately, as was mentioned in the other UV request, this would require most of our AF server client products to start being version aware. Since we're still cataloging use cases, this is likely not something that will happen in the near future. The complexity in dividing the query into subqueries that could have different time ranges depending on the version and how far back it goes could make this both expensive and difficult to troubleshoot. If versioning becomes more of a focus in future versions (which is no guarantee), the other clients could revisit this, but for now, you would likely need to investigate custom coding to be able to accomplish this.

Hi Holger, What would be your expectation if a calculation which involves a time range (such as an average) crossed between different element versions? Additionally, what would be your expectation if there are dependent calculations that crossed between element versions? Thanks for your feedback.

1. The calculation involving a time range cross different element versions with one analysis version works fine as it is (f. e. average across multiple tags). 2. The analyses should not have versions on its own. They should be coupled to each element version. When I change an analysis it should only be changed in the current element version. 3. When calculatating an analysis for the current timestamp the analysis of the latest element version should be used. 4. When backfilling analyses the backfilled time range should be split into element version time ranges. These should be calculated in a chronological order. Each time range should be aware of its own scheduling type. Not sure about advanced option "Relative to Trigger Time" because that could influence values in other time ranges, but I think it works as it is, if the chronological order of calculations is kept.

Thanks for your feedback. I have additional questions. 1) Let's say you have 2 element versions, version 1 is valid from 1-Jan-2017 to 31-Mar-2017. Version 2 is valid from 1-Apr-2017 to now. 2) In this element, attribute 1 = sinusoid for version 1, but attribute 1 = cdt158 for version 2. 3) Let's say for version 2, you have an analysis that does a tag average for 1 day for attribute 1. At 1-Apr-2017, if I do the tag average for attribute 1, what should I do? Should I simply say there's no data prior to 1-Apr-2017 therefore the tag average is only for 1 value? (Remember attribute 1 changed from sinusoid to cdt158 between version 1 and version 2.) Should I take the value of attribute 1 for cdt158 prior to 1-Apr-2017. If I do that, use sinusoid or cdt158? I don't think I should do a tag average of sinuoid and cdt158 when element version changed. 4) Analytics supports dependencies. What should I do if output of version 2 is used for input of another analysis that also has versions? I would think I should also use the proper version time aligned with the initial trigger. However, what if the output of the first is time overridden to a different time such that it's a different element version in the dependent analysis? 5) What should I do if the user changes the validity dates of the element versions? Should we recalculate? Any feedback you may have would be helpful.

A) For current timestamps all calculations should use the current element/analyses versions. B) For recalculations: 1) to 3): I think the behaviour is fine as it is now: an average between 31-mar and 2-apr should use both tags sinusoid (until 1-apr) AND cdt158 (after 1-apr). The average should be calculated for the attribute and not for the tags itself. The attribute is only a mapping for the tags. If attribute1 would not exist in version 1 the calculation should only use the values after validity date of version 2 (1-apr). 4) We discussed this a lot. We think it would be best if the OUTPUT timestamp of analysis 1 would be the trigger to analysis 2. If a user uses "Relative to Trigger Time" he has to take care that the analysis versions are consistent between each other. 5) I think that is in the responsibility of the user. He should do a backfill manually.

There is one very special case for 4): - In element1 the output of analysis1 is written to an attributeA with an offset with "relative to trigger time" - The output attributeA is mapped to an output pi tag - That output tag is also mapped to an attributeB of element2 and that attribute is used as the trigger for an analysis2 in element2. - The tag is no longer associated to the attribute at the timestamp of output from analysis1 because there is a version change in element2 exchanging the tag with another one. In that rare case I think the output from analysis1 should not trigger analysis2.