Ideas to make Asset Analytics more UOM-aware

Idea created by rdavin Employee on Apr 27, 2016
    Submitted
    Score18

    I would like to see UOM’s even more integrated into Asset Analytics.  After all, one of the key differences between an AFValue and a PIValue is the UOM property.  As Analytics also deals with AFValues, I'd like to see more usage of the UOM.  We are not savages.

     

    I am only working with Analytics in AF 2.7, though I am eagerly awaiting 2.8.  Maybe 2.8 has addressed some of these ideas.

     

    Background: I finally got my hands dirty with Asset Analytics, that is went beyond light-hearted training examples and jumped to real applications like detecting when a flow is occurring and output a totalized volume when the flow stops.  Though I am a newbie with Analytics, I am quite experienced with using the Formula DR and writing custom data references.

     

    Speaking of formulas, although inside the formula the equations work with just plain numbers (i.e. no UOM), it’s critical to pass the inputs in the proper UOM and make sure the output is the right UOM.  Is this the intent of Analytics as well?  That for the in’s and out’s worry about the UOM but the expressions in the middle do not?  I’d like to think there are valid spots where expressions in the middle need a UOM.

     

    With that in mind, I offer some ideas for consumption.  Note that I present them in order of what I perceive to be the least controversial and easiest to implement to the wilder, no-chance in hell variety.

     

    Idea #1 – DaySec and SecSinceChange should return a value with a UOM of seconds

     

    This should be done easily and with little controversy.  After all, they clearly state they return the number of seconds. The reasoning is to reduce chance of developer error and reduce debugging time.

     

    Presently if SecsSinceChange was 10 minutes, or 600 seconds, I would expect the function result to be 600 s and not plain 600.

     

    While this seems intuitively correct, it produces the wrong answer in AF 2.7:

            Name                                    Expression

    TotalHoursSinceMidnight     Convert(DaySec(‘*’), “h”)

     

    Instead one must perform the more awkward:

            Name                                   Expression

    TotalHoursSinceMidnight     Convert( Convert(DaySec(‘*’), “s”), “h”)

     

    Or even the more archaic (why have UOM's if I must provide my own conversion formula, simple as it may be):

            Name                                   Expression

    TotalHoursSinceMidnight     Convert( DaySec(‘*’) * 60 * 60, “h”)

     

     

    Idea #2 – New overloaded function TotalSeconds

     

    As a beginner to Asset Analytics, it was easy for me to subtract 2 times to produce a time span, but I then wanted to extract the total seconds.  First place I looked in was the Date and Time function.  Took me some time to search for the Float function, and even some more time to realize I need to complete it with a Convert.

     

    The suggested signatures would be:

     

    TotalSeconds(time t1)

    TotalSeconds(timespan t1)

     

    And the returned value with a UOM of seconds would be something like:

     

    Convert(Float(t1), “s”)

     

    This could be done easily and the only real controversy is “Is it really needed?”  Granted that’s short enough code that I can put into my analyses.  Still, it’s a simple enough function that - to me - rightfully belongs as a Date and Time function.  I’m just one guy but again my first place to look was in Date and Time functions, and I lost some time trying to find out where it really was.

     

     

    Idea #3 – TagEU should return DefaultUOM of attribute rather than Eng Units of its underlying PIPoint

     

    I have an attribute with a DefaultUOM that differs from its PIPoint Eng Units. If I input an attribute name to the TagEU function, I am expecting the attribute's DefaultUOM, and not the Eng Units of the underlying PIPoint.  Let's look at an example:

     

    PI SMT Current Values

     

    smt.png

     

    Here’s the same PIPoint listed twice in PSE.

     

    pse twice.png

     

    Here’s the definition of the child attribute.  Note it uses a different UOM than PI:

     

    pse config.png

    I would expect the next function call to return “mi” because that is the attribute’s definition:

     

    TagEU(“Kilometers|As Mile”)

     

    But instead it returned “km” from the underlying PIPoint’s definition.  (See bottom of pic at bottom of this post.)  This doesn't seem right to me.

     

     

    Idea #4 – Convert function should treat toUnit of “” as null

     

    (Starting to get controversial here.)

     

    The TagEU function returns an empty string if a UOM is not assigned, although technically it maybe should return a null.  I can live with TagEU being an empty string but if I feed that back into a Convert, it produces a Calc Failed.  So what I want is that if I feed an empty string as the toUnit to Convert, simply assign a null UOM and not fail.

     

    Consider this snippet of code:

     

    Name       Expression

    Uom       TagEU(‘attribute’)

    Current   ‘attribute’

    Target     Convert(5, Uom)

     

    Looks fine enough. What if someone comes along later and changes the DefaultUOM of ‘attribute” to be null?  Then my analysis fails.  Sure I can code this instead:

     

    Name       Expression

    Target     If Uom = "" Then 5 Else Convert(5, Uom)

     

    But now my analyses are getting longer and uglier.  Or it requires we check all analyses anytime we change an element template.

     

     

    Idea #5 – DeltaValue should return value with appropriate UOM

     

    (Now I get into the deep end.  Not really expecting these ideas to be implemented.  But maybe start a good discussion.)

     

    Admittedly this is not always the same UOM as the input attribute.  Certainly if I am subtracting meters, gallons, seconds, etc., it would be.  But if I am subtracting temperatures, then the returned value is has a UOM from the Temperature (Delta) UOM class.

     

    Again with Formulas the philosophy is to worry about UOM’s on the in’s and out’s but not the equations in-between.  If that’s the same with Analytics, then this idea can be scrapped and I can quit worrying my pretty little head with such things.

     

     

    Idea #6 – Should some operations be more UOM-aware?

     

    What is the right answer to:

     

    5 mi + 5 km = ?

     

    The wrong answer is 10.  The right answer is 8.106856 mi or equally correct 13.04672 km.

     

    With Formula equations I’m working with plain values, so it’s not “5 mi + 5 km”.  It’s just “5 + 5”.  I get that.  I accept that … with Formulas.  I just was hoping for more with Analytics.  My wish here is that I would like calculations to be more UOM-aware.  In a more perfect world, I’d like the think an expression like “Distance1 + Distance2” would produce the correct UOM-aware answer without me worrying about the little details.  Granted this opens up some tougher questions as to which UOM should be returned?  The first one referenced?  The last one referenced?  Maybe add a new column for desired UOM?  Maybe say “Thanks Rick for ideas #1-3.  We’ll get back to you on #4.”

     

    Anyway, here's a pic of an example:

     

    analysis.png