2 of 2 people found this helpful
Can you provide an example or explain a bit more detailed what you expect from a totalisation function that is unit-aware? Within the Units of Measurement you can specify information that allows to convert from one unit to another but only for units belonging to the same category. I believe a common example is electricity. Electric power is usually measured in Watts (W); electrical energy (the time integral for electrical power) usually in kilowatt hours (kWh). In addition to the time unit, there's also a conversion in the tens potency that a unit-aware totalisation would have to care for. I am not saying that it is impossible to implement a unit-aware functions but it appears this would require first to enhance Unit of Measurement to allow to define how one unit category translates into another when time comes into play.
With your last question you ask for an event weighted total. A function for this doesn't exist - neither in Performance Equations nor in Asset Based Analytics (at least I didn't see it). The good news is that you can easily use TagMean() and multiply it with EventCount(). TagMean() provides the event weighted average. For sure point, start- and endtime provided with both functions must be equal.
Fair enough, I had not considered that unit names were relevant and I can see that there may be complications, however...
kWatts is kJoules/Second so a totalisation should return kJoules, which then can be converted into kWh (I think the conversion is just a name change).
What we were actually totalising was a flow rate in Kg/h so we would expect the answer to be in Kg
I suppose essentially AF needs to be aware when a unit of measure is composed of another unit per a time period. Then it can just multiply out the time unit. I can't think right now of any circumstances where this would not work but I understand that the AF Units of Measure are not quite as clever as I first thought. I don't think it would be too hard an enhancement though.
Thanks for the suggestion of TagMean() * EventCount(), we will use that. It's a shame that we have to implicitely divide by the event count and then explicitely multiply by it though: two unnecessary operations!
Current AF does UOM conversions, as long as both are listed in the same UOM class and you have configured the conversion correctly within AF. What you have described above is what I would call dimensional analysis. Dimensional analysis is quite a bit more complicated as we have to have at least the following: all the UOM for the inputs are properly configured and these UOM are something that are recognizable (e.g. I've seen PI Points with units of "kW", "kilowatts", "kWatts", etc.), conversion formulas (e.g. mass flow rate to volumetric flow rate would require information such as density of the material and whether there's any effect due to ambient or process conditions - say density changes with temperature - typically this is a lookup to a calibration curve), time context (e.g. in your example you may have totalized not over 1 hour but over something like 72 minutes ) and the output UOM that is also recognizable. As you can imagine, this is not so easy. Unfortunately the current AF UOM system was not designed to do this.
Having said that, I do want to point out a couple of things. With Asset Analytics, if your expression is only a PE function, then we would respect the UOM of the input and convert to the UOM of the output attribute as long as both input and output UOM are defined in the AF UOM database and they are in the same UOM class. For example, let's say you have Att1 with UOM of fahrenheit and Att2 of UOM of celcius. If your expression is:
tagavg('Att1', '*-1h', '*')
Then if you map the output to 'Att2', the you will see that Att2 will have the answer in celcius.
This will not work if there's any mathematical operations within your expression due to the above on dimensional analysis. In this case, you can wrap your expression using the Convert() function which we just recently added as another workaround for UOM conversions.
Hope this helps.
AF Product Manager
Thanks for the elaboration. I can see that my case just one example of a much more general feature. As is so often the case, "it's a bit more complicated" than I thought!