Make it possible to sync AF enumeration sets to PI digital state sets.

Further description . . . it is possible to have a False/True digital set on a tag where False=0 and True=1 on the trend . . . but trending the attribute for that same tag results in False=1 and True=0. You have to manually create a digital sate set in AF, aka an enumeration set, and assign the attribute to it. This essentially creates two identical BUT INDEPENDENT digital sets, one on the archive and one in AF on ONE database. Granted False/True is not likely to experience changes, but not only would you have to create this enumeration set again in other databases, but it is possible that a more complicated digital state set is involved that could possibly need changing later . . . now that change has to be complete in multiple places.

Better idea: instead of syncing, why not just have the PI Data Archive and PI Asset Framework use the same set? This might require the suggestion below to be implemented, but it should be worth it. https://feedback.osisoft.com/forums/555148-pi-server/suggestions/31708795-store-pi-data-archive-information-in-an-sql-server

Unfortunately we cannot simply use the same set as there may be multiple PI Data Archives being used in a single AF database.

I'm not trying to specify HOW to fix the issue . . . and I don't necessarily agree with automatic syncing all Sets anyway. However the lack of automatic syncing being a viable solution does not eliminate the existing problem/issue. Its problematic that a tag and attribute can trend differently and only be remedied by creating a duplicate and independent Enumeration Set to match the existing Digital State Set in EACH database it is encountered in.

In addition to Steve Kwan's observation that a single AFDatabase may reference multiple PI Data Archives, it may help to understand the critical difference between an AF enumeration set and a PI state set.  While state sets and enumeration sets do much of the same thing, and we therefore would like to lump them as being the same thing, they are not exactly equivalents.   The DigitalState's Code is a positional offset within a PI StateSet.  Hence, each state set must begin at 0 with each successive Code incremented by 1.    An AFEnumerationValue has a Value property, which is not the same as its positional offset.  An AFEnumerationValue may have a negative Value, and there is no restriction on the stepping increment.  More so, there is no fixed increment with AF so you can have a Fibonacci sequence or go by powers of 2, if you want.   For a given PI Data Archive, a one-way mapping is possible from a StateSet to an AFEnumerationSet because you are going to a more restrictive system to a less restrictive one.  By an automatic mapping the other way, from an AFDatabase to a PI Data Archive cannot be 100% due to the noted differences.

I think Sync does not says that they need to be the same. Maybe a good approach would be to have a functionality where you can link an AF Enumeration to a Digital State that way you can map, for example, the Value 2 of an AF Enumeration to a position 1 of a Digital State. And more so a way to create a DigitalState using the PI System Explorer. In the above given example if you are importing an AF database from a system to another and the DA Digital States weren't created already, PI SE would create it automatically.

In response to Wilson Laizo Filho, "I think Sync does not says that they nee..." Sorry for a delayed response to this thread.  It fell off my radar when it scrolled off the bottom of my inbox So I'm still a bit confused about all this discussion about matching a PI Point Digital State Set with an AF Enumeration set.  There's really not a need to do that.  For example, if I create an attribute and configure it with a PI Point Data Reference in PI System Explorer, PSE knows that the PI Point is a Digital Tag and handles it appropriately.  In particular, it sets the attribute value type to and automatically reflects the PI Point Digital State.  If you look at the screen shot below, I created a PI Point DR attribute and configured it to point to CDM158 (an example Digital tag that comes with a default PI Data Archive install) and you can see what I mean.  I have created no AF enumeration set for this.  It also trends just fine without an AF Enumeration set.       -- Steve Kwan

In response to Stephen Kwan, "Sorry for a delayed response to this thr..." I have not used the Anything Value Type very much, but do see, now, that using that value type does eliminate any issues with discrepancies between the AF trend and the PI Tag trend with its Digital State Set. The observation I have been seeing is a discrepancy if the attribute type of string.   That being said, there is nothing about that would indicate to anybody that this should be used in this scenario. Especially since the help file specifically says "while allowed .... is not recommended". We have also recently had issues with the object because after the 2017R2 upgrade we had If-Then analyses failing because an attribute was being compared to a String object. It appears that there a many reasons to not use , and then this one hidden reason why it should be used.   If the Anything type is able to align itself with the Digital State Set . . . why can't the String type at the very least check to see if it should align it self with Digital State Set?  

In response to James Voll, "I have not used the Anything Value Type ..." Hi James,   You have valid concerns and highlighted an area that we need to document better.  First of all the help at Live Library states:   NOTE While allowed, the Anything value type is not recommended. When the value type is unspecified, many client applications may have difficulty working with that attribute. For example, PI OLEDB Enterprise, PI ProcessBook, and PI Vision would all have reduced capability with such attributes, such as the inability to trend a value numerically. Furthermore, standard PI AF features such as automatic UOM conversion, formulas, and analytics cannot function with attributes that have no value type.   You will note it says "may have difficulty working with that attribute".  There are certain data types that aren't basic but that do work well as Anything.  A digital state is one that works well.  It does work in Formulas.  Here's a simple echo Formula:     Likewise this Anything works well in Analytics.  For all intents and purposes, it's hard to tell that CDM158 is defined as Anything:     Note the last line where I can force the digital state to return its underlying code.   I have also trended this in ProcessBook.     And that's just playing around for 10 minutes to go through this.  PSE and ProcessBook do treat a digital state as a type of numeric input, although there is a duality to a digital state since it's a string AND a code, whereas a String attribute by itself is simply a string.  Granted you won't have a UOM conversion with Anything, but no loss there since a digital state does not have a UOM.   Another data type that's good for Anything is a TimeSpan object, particularly if you wish to display elapsed time in hh:mm:ss instead of decimal hours.   As for why can't a string be smart enough, let's look at his perfectly valid PI System State Set:     I have a state name that is blank, and I have a state name of "Unique" that is not so unique.  This would be problematic to automatically map back.  Which "Unique" should it map to?  Whatever answer you give me, I will say that it should be the other one.  And does a blank state mean no state or state not entered or state #1 or state #4?

In response to Stephen Kwan, "Sorry for a delayed response to this thr..." Steve; I did some testing and using templates, even if I mark a tag as Digital, it would not change automatically the type to Anything like you mentioned above. And if you use the "Create and update data reference" it will create the tag correctly and will not change the type to Anything automatically. So, not considering what James mentioned above, you would need to manually specify the type as Anything if you are using a template, which is a bit odd (to me at least).   The thing about the Sync is that it would enable more customization as well. For example, your Digital State may represent and have the same value as you see in the automation side (for example, OFF, Manual, Auto-1, Auto-2) but in AF you have more freedom to express those values, for example, instead of displaying Auto-1 you could display Pump on Automatic. Also if you associate a digital state with an Enumeration, you could automatically change the attribute type to the correct enumeration instead of Anything.   At the end I don't think this is a huge problem, but it would be a nice to have feature.

In response to Rick Davin, "Hi James,   You have valid concerns and ..." While the Live Library formatting makes it seem like the "not recommended" part and the rest of the explanation are on the same general level of importance. The Help file in System Explorer formats it such that the "not recommended" part is given a higher level of importance compared to the after thought; the "note".   While I personally, partially understand the concept of , or at least i do now . . . I find the concept to be rather confusing from the perspective of most others. You are basically suggesting that Digital State tags when used in asset framework SHOULD be set to . However there is nothing to lead to that conclusion for most others besides this conversation or their own detailed and indepth playing around.   I also stand by the fact that data types have given us trouble with Analyses. Through some additional testing it appears that the problem is if an attribute is set to and then compared to an attribute (string or anything) with a value that is not in the digital state set, then the calculation fails.   Attribute1 -> DR Attribute2 -> or String If Attribute1=Attribute2 ......   This appears to fail the analysis unless Attribute2's value is part of Attribute1's digital state set. This particular scenario was discovered after the 2017R2 upgrade seemingly caused previously functioning analyses to fail. Logically one would expect it to simply NOT be true and route to the 'else' portion of the expression. I can think of a number of scenarios where it is perfectly reasonable that Attribute2 might find itself with a value that is not part of Attribute1's digital state set. I think this all just further illustrates the non-intuitiveness of .   considering the usage of templates across multiple sites (who potentially have different digital state sets that we do no want to hardcode into the analysis), this is a very common comparison structure for us.

One possible solution comes to mind. Anytime a PI Point DR is created, PSE could check for a matching Digital State Set in AF. If none is found, PSE could offer to import it at that time. Of course that does not solve the maintenance issue. It would still be useful to have a tool that could analyze for changes since import.

In response to Chris Lonsberry, "One possible solution comes to mind. Any..." With the release of PI Server 2018 SP2 (AF SDK 2.10.5), this idea has been implemented or completed. With this version going forward, is no longer recommended for use with digital tags as AF enumeration sets have a tighter integration with the PIStateSet.  On a stronger note, is not officially recommended for use on any attribute.  However, an experienced system admin who fully understands the limitations of may still choose to use it (and ignore our official recommendation) in very select circumstances (e.g. with TimeSpan or general Object).   I leave it to Stephen Kwan to update the status.