• State Not Answered
  • Replies 2 replies
  • Subscribers 3 subscribers
  • Views 227 views
  • Users 0 members are here
Options
Related

PI Asset Framework Units of Measure: Any Custom Libraries Available?

James.Aylard

PI Asset Framework includes a reasonably good default selection of units of measure, but compared to the variety of engineering units in my PI data archive and the UOMs these represent, AF's list is limited. I know how to create custom UOMs, and have made several. But I got to wondering: instead of laboring to reinvent an already-existing wheel, is anyone aware of an open-source library of custom UOMs that can be imported into AF? My searches turned up nothing.

  • 0

    On the surface, this sounds like a perfectly reasonable request. But in reality, it is quite problematic.

     

    While each UOM has its own Guid as a unique identifier, which is how it would be stored on SQL Server's PIFD database, a UOM also has 2 other unique identifiers: the Name and the Abbreviation. If you tried finding a UOM using the UOMs[string] property, what is searched for first is by Name, and secondly by Abbreviation. For remainder of my discussion, when I say Name I really mean Name and/or Abbreviation.

     

    While the earliest versions of the UOMDatabase uses case-insensitive Names. And given that Names had to be unique, it made it tough. My company had a UOM for Siemens and we could not use "S" because seconds had an abbreviation of "s". Thankfully later, OSIsoft supported case-sensitive UOM's but still the fact remains that you can now only have 1 UOM using "s" and another using "S", and after that NONE SHALL PASS.

     

    So consider trying to import some other UOMDatabase into your PISystem. There is so much potential for naming conflicts. At best, I would consider trying to import just a UOMClass, but even then name conflicts could occur.

     

    I worked on a PISystem from 2009-2016 for one company. I left for 3.5 years and returned. I cringed when I saw the shape of the UOMDatabase. One must give very clear thoughts and organization to not just the UOM, but equally to the UOMClass. Once the UOMDatabase goes slightly off the rails, and AFAttributes are created referencing those UOMs, then it becomes very ugly to clean up.

     

  • 0

    Rick, that sounds about right. But done with care, it seems that values imported from an open-source, community-evaluated database would still be a better option that having to come up with UOMs from scratch. I think the GUID aspect would be resolved by unchecking the "Preserve Unique IDs" checkbox upon file import? Not completely certain, but that is how it appears to me. But I understand the points you raise around unique naming. I can see value in avoiding duplicate abbreviations for different UOMs, but I can also understand where that creates problems when the standard abbreviations are the same for two different units of measure. In that case, adding some very brief parenthetical addition to one or both UOM abbreviations might help, but would not be ideal.