Unlike Shakespearean roses, an AF Attribute by any other name does not smell as sweet.
When naming PI tags, the naming convention often corresponds tightly with the control system topology – or, often, the PI tag names are the control system tag names. Or (as many of you are muttering right now) there is no naming convention, but the names are still cryptic. When the name is the primary identifier of an object, it makes sense to do cryptic, human-unfriendly maneuvers in an attempt to uniquely and positively identify the tags for those individuals who are in “the club” and understand the control system lingo.
Try going onsite and understanding a competitor’s tag names. Go on, I dare you. Or hire a contractor to do integration work at your site. Or hire a new employee – you get the idea. With cryptic tag names, your data is cloaked in a fog of mystery. One of the prime directives of PI AF is to make your assets understandable by any onlooker (...who has the right security permissions).
Instead of requiring you to parse a fully-qualified PI Tag name (e.g. CEL-LIS_TRK001_DLOAD.MEAS.PV), PI AF presents Truck 1 as an entity with meaningful properties of a truck: Speed, Oil temperature, Dynamic load, and so forth. Furthermore, those properties are each presented in a known (and selectable!) unit of measure. Standardization (every truck is a truck), legible naming (e.g. Oil temperature), and units of measure (Oil temperature is presented by default in °C, unless requested otherwise) is how PI AF shines the light of sanity upon complex worlds.
Thus we arrive at my sermon: When you’ve got your hard hat on and are playing PI AF builder, remember the prime directive: PI AF must be friendly. A crucial and repeated task is to give PI AF Attributes “good” names. Good names are names that immediately have meaning to mortal humans, foreign systems, and the humans establishing mappings between PI and foreign systems.
Talk like you're a human
Names must be written like you’re communicating with a human. “ENG SPD” is a lousy and obscure representation of “Engine speed,” so don’t even think about naming your PI AF attributes in the former, cryptic way. Forget how your PI tags are named; it doesn’t matter one bit. “Engine speed” makes much more sense to everyone and that is what matters going forward. I’m a mechanical engineer, and even I get nauseated by coded names.
Don't mix names with units
Names should not include units-of-measure. It makes absolutely no sense to say “Generated watts” when consumers can request the value of “Generated watts” in watts, kilowatts, BTUs, or horsepower. What you’re trying to describe is “Generated power,” so call it that.
Child attributes should be named relative to their parents. Long lists of attribute soup can be avoided three ways: subdividing your assets, categorizing the attributes (to enable grouping/sorting), and by nesting them (some attributes as child attributes of others). The latter case of child attributes pertains to this article on naming. If “Feed A Flow” is the parent attribute holding “Feed A Total” and “Feed A Rate of Change,” those children’s’ names should be reduced relative to their parent – to “Total” and “Rate of Change.” Otherwise, you’ll end up with a attributes fully-named as, e.g., “Feed A Flow|Feed A Total.” This likely makes more sense as “Feed A Flow|Total” – the total of Feed A’s flow.
In the new integrated PI Search experience (cf. Coresight, DataLink), search results will appear associated with their immediate parent:
These three rules – legible names, not including units of measure, and not over-qualified if nested – will help your PI AF implementation be successful as an enterprise-level object model and data foundation. Go forth and prosper.
And I'm hoping for some great comments from those of you who can add to this list of good practices! What's missing?