rdavin

AF 2.5 RDA Should there be a PIPoint.DefaultUOM?

Discussion created by rdavin Employee on Feb 24, 2012
Latest reply on Mar 16, 2012 by MvanderVeeken

Sorry.  Don’t have my own blog so I chose that this is the best forum to post this idea regarding AF 2.5 Rich Data Access (RDA).

 

 

 

I got to watch the AF 2.5 RDA webinar – with emphasis on the ‘watch’ because my audio crapped out with “I’ll turn it over to Chr…”  Some of these features had me quite excited about 2.5 though seeing the webinar without listening to it was akin to torture.  I’ve seen the other cool threads on RDA such as reasoning behind some method names, etc.  All really great stuff, and so far I like everything I see.  Glad to see a divergence from some of the old PISDK names with AFSDK for better clarity, synergy, etc.  

 

 

 

It’s great to think I can work with 1 SDK for both AF and PI, or that I can skip AF and work just with PI while saying goodbye COM.  I can appreciate that OSIsoft must maintain a large amount of backward compatibility with how things were done 10-20 years ago but I think  the name changes are a welcome break with the old.  Sometimes it’s not a matter of doing away with the old as much as it is improving upon it. 

 

 

 

One other thing that I am pondering whether or not would be great: in order to marry the old (PI) with the new (AF), I wonder if whether an AFSDK PIPoint object should not have a read/write DefaultUOM property? 

 

 

 

Consider that a standard question I have with job candidates is “What’s the difference between a PIValue and an AFValue?”  I’ve gotten some interesting replies, which is a different topic, but the key answer I look for is: an AFValue includes a unit of measure.  Just like going from B&W to color, or from 2D to 3D, going from freeform EngUnits to structured UOM’s have opened up a brave new world.

 

 

 

With 2.5, one would get there is a PICommonPointAttributes class which includes an EngineeringUnits field  as well as a MapEngUnitsToUOM property.  MapEngUnitsToUOM is a read/write Boolean property denoting whether the SDK will automatically attempt to map a PIPoint’s EngUnits to an existing UOM.  Question: does this require EngUnits to match the UOM.Name or UOM.Abbreviation or either?  Clearly this shows that OSIsoft has given thought and effort to help marry the old with the new.

 

 

 

Speaking on behalf of my company’s usage, if I am working with AF data, then 99% of the time, I need the UOM at my fingertips.  On the other end of the spectrum, when working with PI data alone, my need for EngUnits drops to  <1.  But when working with PI+AF data in some sort of synergistic harmony, that number again climbs to over 95%.  As I ponder whether a PIPoint should have a DefaultUOM, I do try to consider my common usage as well as how others with different needs may be affected.

 

 

 

The MapEngUnitsToUOM looks intriguing but it implies the EngUnits must somehow match the UOM.  Sometimes this isn’t practical because the closer a PI historian sits to a control system, there is a competing philosophy that wants the freeform EngUnits in PI to match the freeform eu’s coming from the DCS.  Sometimes it’s only as we put in the layer of AF on top of that, when we can become further removed from the impositions of the DCS-world thereby liberating us to use an asset structure along with a structured UOM database.    Given that, automatically mapping from PI EngUnits to AF UOM’s may not help me that much.  Also MapEngUnitsToUOM hints that a conversion is done, but where is converted UOM available to me?  What other PIPoint property do I read to say “Ah yes, the eng units were correctly converted to a UOM and here it is!”?

 

 

 

I credit OSIsoft for providing a basic, international-aware UOM database that can be expanded.  But on PI Servers, which are more localized in their scope as they may sit near a DCS, users won’t care about “US gallon per day” (as AF has) but would rather just see “gal/day” or simply “gpd”.  Or again, the historian users want to see shorter abbreviations, yet a limitation (or strength) of AF is the UOM’s must be unique.  For example, ‘s’ is the abbrev for Seconds in the Time class.  Nothing else in AF can be ‘s’.  Our AF Server has a Conductance class with a UOM named ‘Siemens’.  The bummer is our historian users may rather see EngUnits of ‘S’ for Siemens, but can’t do that in AF since ‘s’ is reserved for Seconds.  My overall point being the competing factions have a disconnect that needs to be addressed.

 

 

 

On the other hand, if a PIPoint has a DefaultUOM there are different ways one could interact with it.  First of all, for any old PISDK users dealing with PI who don’t care about UOM’s, there is nothing needed to be done differently on their part.  In other words, this proposed idea would not affect them.  What I am proposing should not require anything additional on their part of cause any performance issues. 

 

 

 

But for those of us working with PI+AF in tandem, I envision the DefaultUOM being used this way: (1) if MapEngUnitsToUOM=True, then anytime the EngUnits are updated or changed, and it can be successfully mapped, then it would be saved as the DefaultUOM property on the PIPoint.  Or (2) for reasons mentioned in previous paragraphs if I set MapEngUnitsToUOM=False, I still want the ability to assign a DefaultUOM to my PIPoint.  This would be my way of saying that even though my EngUnits are loosey-goosey (slang for VERY freeform), I still want to work with structured UOM’s.  Granted it would be up to the individual developer to implement a cross reference between his PI EngUnits to a proper AF UOM.

 

 

 

Sounds great to me so far, but the idea is not without its problems.  While I would think automatically mapping EU’s to UOM’s would update the proposed DefaultUOM property, I don’t the reverse should be true.  If I update the DefaultUOM, it should not update the EngUnits on the historian.  But that is what I believe – admittedly others may have a different and equally passionate opinion to contrary.  Or does a future version of AF have a MapUOMToEngUnits property?  Where does the madness stop?!

 

 

 

What should happen if you automatically map EU’s, it converts OK, you later set the DefaultUOM explicitly, and then later change the EngUnits?  Should it automatically update the DefaultUOM with the very latest EngUnits, or because you explicitly updated DefaultUOM in this ‘session’ should it leave it alone?  I would think this would be controlled by the MapEngUnitsToUOM property.  If I explicitly update DefaultUOM, then I should likewise turn automatic mapping off.

 

 

 

What if you have automatic mapping on but the EngUnits fail to map over?  Do you set the DefaultUOM to null or leave it alone?  I’d think the latter but again, others may think differently.  All of these are examples illustrating that even a ‘simple’ idea is not so simple and must be examined from all angles, not just the one offering the best light.

 

 

 

As I said earlier, I am pondering (or struggling) with whether this is what I need.  I wanted to pitch this ‘half-baked idea’ to the community.  That last sentence was not intended at all to be derogatory.  Rather it really does indicate that the idea has not yet been fully formulated.  I offer the idea to the community to allow for further vetting, review or discussion.

 

 

 

Do you see a need to bridge the gap between PI and AF data?

 

 

 

Do you think freeform EU’s versus structured UOM’s are an important gap to be addressed?

 

 

 

Do you see other gaps that perhaps warrant their own topic?

 

 

 

 

 

PS - I didn't see any thread clouds associated with AF 2.5 or RDA so I just threw some darts against the wall.

 

 

Outcomes