3 of 3 people found this helpful
My initial thought on this is to recommend you use an enumeration set on an AF Attribute largely because you are already storing the ping in milliseconds in the Data Archive so you have all of the original data stored (rather than just the digital state).
My second comment on this, is that it doesn't matter if you use a attribute with enum set or a digital state tag in Vision because you can do a multi-state with either. As far as I know, there isn't anything special that you can do with enumerated AF attributes that you can't do with tag in vision in terms of display/config of the symbols. The only time that it might be helpful to use an attribute over a tag in vision for this particular case is if you plan on tacking advantage of context asset switching.
Thanks for the response! Can you please clarify what you mean when you say using an attribute might be beneficial over a tag during context asset switching?
In PI Vision, when an attribute based on a element template has a symbol added to the display, PI vision allows the option to switch from one element based on that element template to another element based on that element template. We tend to call that "context asset switching", changing which instance of an element based on an element template you're viewing in the display.
2 of 2 people found this helpful
I think Robert Schmitz has given you really great answers. Allow me to address the concerns away from PI Vision. Let's assume you can either use a PIPoint using a PI StateSet (i.e. a digital tag) or an AFAttribute using an AFEnumerationSet.
Within an Analysis you would refer to the states of the attribute as strings. If you used the tag in a PE or an Analysis, you too would have to refer to the digital state as a string. So there is no disadvantage using an attribute instead of a tag.
What I would really suggest to you is to decide whether your given needs should be asset-based or tag-based. If you are only going to use PIPoints from a PI Data Archive, your needs are very tag-based, in which case your only choice is PI StateSets. However, if you plan on interacting with an asset database to navigate and select a given asset (element), and then look at given attributes on that element, then obviously your needs are asset-based, in which case you have a choice to make.
For an attribute referencing a digital tag, you have 2 choices. You may define the attribute type to be Anything, which is a notable exception to the rule of "try not to use Anything". If the attribute is Anything, then you do not need to mirror the PI StateSet as an AFEnumerationSet. But you are still at liberty to do so if you want to take upon that extra task of replicating the state set to an enum set. If you do this, then the attribute's type must be the replicated enumeration set. As for other applications, such as Analytics or PI Vision, there is no real difference to using one over the other. As you point out, there is the maintenance issue of keeping state sets in sync and up to date. But as you also pointed out, PI StateSets and/or AFEnumerationSets - by their very nature - really should not change very frequently, if at all.
Which do we recommend? If your attribute refers to a digital tag, our recommendation is to define the attribute type as Anything and do not replicate the PI StateSet as an enum set. I claim "our recommendation" because I know the AF Product Manager Stephen Kwan has made this recommendation in the past.
On another issue, what Robert refers to as "context asset switching" was known as Element Relative Displays (ERD) in ProcessBook.