18 Replies Latest reply on Mar 16, 2012 8:04 AM by MvanderVeeken

    AF 2.5 RDA Should there be a PIPoint.DefaultUOM?

    Rick Davin

      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.



        • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?
          Ahmad Fattahi

          Thanks Rick for the great and extensive post. I apologize for the audio problems during the webinar. We will post the recorded version soon. One fairly general question: if you got a case where PI Engineering Units are deemed sufficient in their free format, would a corresponding and dedicated UOM on the PI AF side, just for that PI tag, address your concerns? My impression is that if you don't need UOM usage significantly, you don't have to use it in any major way.

            • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?
              Rick Davin

              Ahmad, to summarize my verbose original post, yes, I am thinking I want a UOM property for just the PI Point.  For those of us who don't work with UOM's and PI tags, then it has no affect.  But for those of us of who do work with AF+PI tags, I think we need the OSIsoft.AF.PI.PIPont class to have a UOM member.  And, I want to have my cake and eat it too.  That is to say that if I have relatively structured EngUnits, I want UOM updated automatically.  But if I have very freeform EngUnits, I want to still to set/get the UOM via the SDK.

                • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?

                  Hey Rick, nice post (someone get this guy a blog)...


                  Do you remember this topic I started way back in Jan 2009?  You commented on it back then too, interesting to see where we were at then, and how AF has evolved to today:




                  I am still a fan of structured UOM in the PI Server, but you do raise some important issues around different DCS standards for EUs.  I would even flirt with the idea of having PI Interfaces (especially PI to PI!) better integrated with AF and access UOM to describe source/destination UOM from there, but that is probably too adventurous right now.


                  When you talk about the UOM member of a PI Point object in AF SDK, can't you essentially already do that by creating a dynamic attribute and tagging the required UOM to the PI Point path?  e.g. "\\server\sinusoid; UOM=%"


                  What I have found now is more users are turning to the AF Dataset in ProcessBook for accessing data, where they specify their required UOM for the data.  It relies on some upfront work to model a process, plant, ... in AF but it tackles part of the UOM problem.

                    • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?

                      With posts like this, Rick is on the best way to get his own blog...

                        • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?
                          Rick Davin

                          @Rhys, I remember that thread but needed to review it.  Thank goodness I feel I have been consistent on the topic!  As have you btw, though we are in different camps.


                          I hadn't given thought to creating a dynamic attribute.  While that idea is creative, I need to still ponder whether or not that would be sufficient.  Sounds like it requires more code on my part to glue things together.  Although in a pinch, it may be a prudent path to explore while waiting for something else!  


                          I think the new MapEngUnitsToUOM property is start in the right direction.  I just don't think it goes far enough.  I think there are opportunities to 'fill the gap'.  What I am proposing shouldn't be considered too radical:


                          OSIsoft.AF.PI.PIPoint.DefaultUOM  (or simply UOM?)


                          My proposal would try to get a little SDK-synergy from the MapEngUnitsToUOM property but it would require some more OSIsoft code to be the glue.

                          • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?



                            This is my first post so bear with me... I'm working with a new PI system and transferring some applications from a legacy historian to PI. One app uses a set of 150 screens each with up to one hundred point references. I decided to use AF attributes with PI Point data references rather than direct references to PI Tags as the indirection allows PI tag name changes without updating screens.


                            In order to display the UOM in the screens, I had to use the DefaultUOM because tagging the UOM to the PI Point path (\\server\sinusoid; UOM=%) did not enable the units to be available in ProcessBook. A call to tech support confirmed this is expected behavior.


                            I bring this up because it appears the two methods of assigning the UOM seem to have different behaviors and may not be synonymous. Alternately, I am missing something entirely and need to get a better understanding of the two methods.


                            One of the side-effects of having to use the DefaultUOM property is that a template based element has to have this property set in the template. This resulted in the need for a separate template for each UOM that I have. Where otherwise I only needed one template, now I have over a dozen which left me thinking I must be doing something wrong as I would expect to have the minimum number of templates necessary.


                            This is not exactly on the topic of 2.5 RDA, but hopefully not too far off.



                              • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?

                                I’d like to frame the discussion in terms “Long Term” and “Short Term”.


                                In Long Term, we would like to see a closer synergy between the attribute and point configuration data store.  In this time frame, we could imagine that a pi event stream (aka PI Point), has an additional point attribute that is a UOM. The UOM would be stored in the definition of the pi event stream.  Configuration tools would be modified to make coordinating with EngUnits a better experience.  


                                In the Short Term, we must deal with the two different configuration data stores.  The traditional PI Point tag classes do not contain an attribute for UOM nor a mechanism for storing anything there that is more than a string.  As Rhys mentioned, there is a place for a UOM on a PI Point in the AF SDK – it is AFAttribute.DataReference.UOM.  In the webinar, I set that property using the configuration string:




                                You can set it programmatically this way as well:

                                a = AFAttribute.FindAttribute(@”\\localhost\sinuoid”);
                                a.DataReference.UOM = pisystem.UOMDatabase.UOMs[“m”]

                                A design goal for us in AF RDA is to minimize as much as possible when you might have to use the PIPoint object directly and that non-configuration access would simply be through an AFAttribute.  That turns out to be a bit idealistic for the 2.5 release.  However, we still would like applications to use AFAttribute whenever possible; reserving the use of PIPoint for primarily point configuration tasks that simply require a more in-depth object model that is PI Server specific. Thus, I would prefer to not expose a UOM property directly on the PIPoint object in AF, but continue to use the Attribute.DataReference.UOM for this purpose.


                                Regarding wheither AFAttribute tied to PIPoints should have an option to auto configure themselves in regards to UOM of the PI Point based on the EngUnits attribute, I think that having a mapping from EngUnits to UOMs available is nice option, and as you detail, is likely required for effective auto-mapping to occur. I could imagine providing a tool in the UOM Database which would allow scanning of PI Servers for existing definitions to ease the building of this mapping.


                                • Given that auto-mapping may not always be desired, I think doing the mapping at configuration time is preferable.  


                                For example, a configuration setting such as, ”\\localhost\sinuoid;UOM=Auto”, would create the attribute with the properly mapped UOM (effectively replacing “Auto” with the mapped UOM in the configuration string).


                                An option for explicitly mapping should be available.  Perhaps something similar to :


                                afAttr.DataReference.UOM = myPISys.UOMDatabase.MapEngineeringUnitsToUOM(myAttr.PIPoint.GetAttribute(PICommonPointAttributes.EngineeringUnits));


                                Finally, the PI Point Data Reference UI could automatically attempt such a mapping after finding a tag.




                                Dennis brings up a related topic, which is the confusion between Attribute.DefaultUOM and Attribute.DataReference.UOM, as well as the lack of the ability to change the Default UOM of an attribute separately from the template.


                                The Attribute.DefaultUOM is the UOM that the value is returned to the client in if it is not otherwise specified on a GetValue/SetValue (and related) calls.  We made this the same for all attributes of a template so that applications could correlate values between attributes of the same template easier. 


                                The DataReference.UOM is the UOM that the source of the data is in.  It allows AF to convert the external data to any specified UOM.  If no UOM is specified, then the data will be converted to the Attribute.DefaultUOM.


                                Most of the client tools are typically keying of the Attribute.DefaultUOM to detect if the attribute has an associated UOM and enabling UOM conversion specification in the UI only at that point. The clients should really key off if either are set.  (In ProcessBook, if you specify the UOM on the AF reference, it will display and convert correctly regardless if whether the DefaultUOM property is set – e.g. “AF2.\\myAF\myDB\myElement|myAttribute;kg” )


                                We do have an outstanding request for the ability to override the default UOM on a per attribute basis, or alternately, provide a configurable “Display UOM” that will be used, by default, in the clients for a specific attribute.  


                                Our concern over the override of the defaultUOM on the attribute is that it provides opportunity for ambiguity or errors for template based data references and analyses.  Imagine a Formula data reference configured in the template which calculates mass, based on volume and density attributes.  If done properly, the formula would specify the desired UOMs for these two variables, as well as specify the UOM of the output : (V=volume;UOM=L;D=density;UOM=kg/m3;[V*D];UOM=kg).  However, it might be that the user assumed the templates UOMs would hold, and thus could have configured the formula without the UOM (V:volume;D=density;[V*D]).  In this case, the override in attribute’s Default UOM could break the formula.  Similarly, tools that are requesting values from many elements could also be confused.

                                  • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?

                                    Chris Manhard

                                    I think that having a mapping from EngUnits to UOMs available is nice option, and as you detail, is likely required for effective auto-mapping to occur. I could imagine providing a tool in the UOM Database which would allow scanning of PI Servers for existing definitions to ease the building of this mapping.



                                    Sounds like Library>White Papers and Tutorials>PI AF>White Paper - Units of Measurement in AF vs. Engineering Units in PI.

                                      • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?

                                        Thanks Chris and Steve for your helpful replies. The distinction between DefaultUOM and DataReference.UOM and the need for reliable formulas makes sense and clears up a lot for me.  


                                        The use case I have is for AF to be an abstraction layer for a large number if PI points with varied UOM classes (voltage, current, power, pressure, elevation, volume and volumetric flow rate) and with varied units within each class.  


                                        I know this could be solved without AF just by using the Instrument Tag and Tag Name as intended – but in this case the PI server is already configured otherwise.  Plus, I would like to use the UOM system (great design BTW).  For me, just having the UOM functionality alone justifies using AF as a thin veil.  


                                        So I wind up with a flat hierarchy of elements each with a single PI point attribute all based on one simple template without UOM.  To introduce the units, each PI EngUnit becomes both the reference and the default UOM for each attribute and is typically the presentation unit also.  


                                        So I don’t see a way around having multiple UOM-specific templates in this case. This is not a problem in any way – just got me curious if I was taking the right approach.

                                          • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?



                                            The concept of UOM-specific templates is somewhat unique.  I would've thought you would create templates base on specific assets, such as a pump or tank or meter or whatever.  Can you provide a couple of examples of your templates?

                                              • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?

                                                Dennis, just catching up on this thread...would also like to see (if possible) couple of your attributes + templates like Steve mentioned above, because unless I have misunderstood what you have said you might be over complicating your use of AF templates with regards to UOM.

                                                  • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?

                                                    Steve/Rhys - I agree this is a unique and possibly misdirected application of AF/UOM. I had a large amount of screen conversions to do quickly so was constrained by those circumstances - but did want to use the UOM feature and indirection AF provides. Thanks for you interest and comments. - Dennis

                                                      • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?
                                                        Rick Davin

                                                        I've been away from my own thread for a few days, but wanted to thank Chris and Steve for their extensive replies.  @Chris, really sorry that my very long note caused you to type an almost as long reply, since that keeps you away from your coding.  @Steve, I don't have same regrets for you since I figure thats part of your job as Product Manager ;-).


                                                        It would have helped if I had just been patient enough to wait for the webinar.  Part of the cause of my original post is that I am too entrenched in the old conventional wisdom of working with AF+PI SDK's.  The new 2.5 RDA stuff changes to a new conventional wisdom, which has been addressed in this thread.


                                                        At least its been a good discussion, and the community is all the better for it.  Thanks again.



                                                          • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?

                                                            Having PI Point adopting UOM idea of AF in the long term would be great! Less confusion and much better user experience when configuring Source/Default UOM in AF Attributes.


                                                            I remember the projects where we had to recalculate values in PE for UOM conversion, which is done automatically in AF now.

                                                              • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?

                                                                Alex Brodskiy @ Wipro

                                                                I remember the projects where we had to recalculate values in PE for UOM conversion, which is done automatically in AF now.



                                                                I remember those days...although now we face a similar UOM problem in the PI for StreamInsight Adapters.




                                                                @Rick: So where do you think you are at the moment: a UOM database applied to the PI Server (maybe as an additional Point Attribute to complement EngUnits Attribute), or do you still think there should be separation where AF is the UOM "master"?  (Are we still is agreement of our disagreement from 2 years ago? )

                                                                  • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?
                                                                    Rick Davin

                                                                    @Rhys, I believe in the separation.  To impose a more rigid UOMDatabase in the PI Server would be far more radical a change than my suggestion to add a property to the SDK to help bridge the gap.  Even now I take back my suggestion for RDA, since I can always 'promote' a PIPoint object to be an AFAttribute if I need automatic UOM conversions.


                                                                    I can foresee in many, many years from now seeing the UOMDatabase more tightly integrated with the PI Server.  The Eng Units right now is considered (at best) a loose association if set up properly, yet it it workable.


                                                                    To be tightly integrated would require a greater fusion of the AF and PI Servers, or so I think.  You'd want the PI UOM to be saved by UOM GUID - otherwise if the abbreviation is sufficient you already have that with Eng Units.  Internally the AF Server tracks references to the UOM's assignments to other attributes and table columns.  This aids in data integrity so you can't delete a UOM from the UOMDatabase if its referenced elsewhere.  


                                                                    So if you want tight integration, its very problematic (or so I claim).  If you're OK with loose integration, we have that today.

                                                  • Re: AF 2.5 RDA Should there be a PIPoint.DefaultUOM?



                                                    You certainly do not need to have a separate template for every UOM as long as there exists a conversion factor or equation between your UOM's.  (You can create the conversion in the UOM pane in PI System Explorer.)  AF can apply the conversion automatically between UOM's that are in the same UOM class.  So, in addition to what Chris has already described, I'm going to attach a few screen shots here from PI System Explorer and ProcessBook.  I hope this mimics what you were describing in your question.


                                                    First, this is a screen shot from the Heat Exchanger demo that ships with the AF Developer's setup kit displaying the Heat Exchanger template.  Note the default UOM for the Shell Side Inlet Temperature is degF in the template.




                                                    Now when you instantiate an instance from this template and configure this PI Point Data Reference, you can optionally configure the UOM of the source PI Point within the PI Point DR configuration pane.  (Maybe in your PI Server, the UOM for this PI point is in degKelvin, for example.)  AF would convert, if necessary, from the UOM of the source PI Point to the UOM of the template (degF in this case).


                                                    In addition, PI System Explorer, you can optionally change the display UOM to something different than the default UOM of the template, as long as they are in the same UOM class.  So in the following screen shot of PI System Explorer, I'm showing an instance of the heat exchanger created from the template, but now I have changed the display UOM to show degC.  (Pardon the other stuff in the screen shot, I took a screen shot from my test machine.)




                                                    Now, finally, if  you are using ProcessBook, when you trend this same attribute, you are given a choice of UOM to trend the attribute.  Here's a screen shot of the configuration dialog box in ProcessBook giving you the choice of UOM to trend.  (I'm using the AF2 option when I configure the trend.)




                                                    So, in summary, you do not need a separate template for each UOM that you have, as long as you can configure a conversion factor (or equation) between these UOM's.  You'd need to place them in the same UOM class and AF would take care of the conversion for you.


                                                    Hope this answers your questions.  If not, let me know.  And if I've gone down the wrong path and completely misunderstood your question, certainly do let me know and we'll see how we can help you.