5 of 5 people found this helpful
We do not have a single document containing all Tag Best Practices, but we do have many published KBs that may help you on that subject:
- 1172OSI8 - PI Server Storage and precision of Float32 and Float64 data
- KB00472 - "Under range"/"Over range" behavior for Float16 and Float32 tags
- KB00296 - Best Practice: Assigning a unique point source for each instance of an interface
- KB01494 - Polled vs. Advise tags on the PI Interface for OPC DA
- 3226OSI8 - What are recommended Exception and Compression settings
- KB00384 - Monitoring Data Freshness or "Stale" tags
- KB01298 - Troubleshooting bad quality data
- KB00884 - PI System daily health check
Also, if you are thinking of renaming or changing tags and digital states, you should read the following KBs first:
- KB01027 - Consequences of Renaming a PI Tag
- KB00248 - What happens when I change a digital tag's digital state set or delete a digital state set
Many of our customers have their own PI Point naming conventions, and they vary a lot. Considering that new technologies such as PI Connectors create PI Points automatically, PI Point naming conventions are gradually becoming a less important factor.
Thank you Victor. The information provided is helpful, but I guess what you are telling me is that I should just maintain my own list as I come across articles?
I think this is a miss because I don't know what I don't know. Also this paradigm seems to deviate from OSIsoft's software design philosophy. For example, we can think of the KB articles as PI tags. They have some name that I can search but otherwise have a flat structure. I was thinking you would have something similar to AF where you could create hierarchies for your different technologies: PI Server, Data Ingress, Data Egress, Clients, etc. PI Server might have DA and AF underneath it and so on. This would make it easier to find this treasure trove of great information. Maybe I should post this in the feedback site under OSIsoft Learning instead of this forum.
As for PI Point naming, I guess my counter argument is that many customers will have different AF structures as well but there is information on ways to design AF. This framework of information would be good to have to help with building/reviewing such conventions. Also, connectors are adding technology to allow for renaming. I think this is critical because of all the system that are built on top of these names, such as OSIsoft AF technology using substitution. Connectors can't create the appropriate hierarchies for me, they can only group tags by data source. Whereas when I am creating a hierarchy I might be pulling tags from multiple data sources (and possibly vendors in which I had no part of creating the underlying tag name) to contextualize a particular asset appropriately.
With that being said this is a good start for my own library. Thanks again,