PI Point User Settings in AF Client
The Suggested PI Point Name configuration item in the AF Client should be able to be set on a AF Server basis instead of a User basis, at least as the initial default. There are default parameters we need to enforce from an enterprise/site level but it become unmanageable when the setting is based on user and PC.
Example parameters we would have as a default for all users:
\%Server%\164-%..\Element%.%Element%.%Attribute%-AFA;descriptor=%Attribute|Description%;exdesc=AFPath:%System%\%Database%\%ElementPath%;ptsecurity=piadmin: A(r,w) | piadmins: A(r,w) | PIWorld: A(r,w);step=0
Matt Voll commented
yes, using the ID as a default for the system makes sense. this enhancement request is less about changing that default behavior and more about having the ability to set a system's default behavior to something else, server side . . . instead of having to change it on individual user's computers.
also, even if a case was made that the ID would need to ALWAYS default into the tag name . . . i'd still make the argument that being able to add other tag properties (ptsecurity, step, descriptor, exdesc) is a huge need
Thank you for the detailed explanation. I do want to close the loop on why we default to appending the ID to the PI Point name if you create them using PI Analysis Service. Imagine you have an Element template with Analysis Template that uses substitution parameters to define the PI Point name. It is very easy to inadvertently create 10 elements from templates, each with analyses created from template and they all write their outputs to the exact same PI Point. As a way to prevent this, the default is to append the ID to the PI Point name since the ID is unique.
Matt Voll commented
utilizing AF analyses (which inherently leads to the need to have the Analysis Service create pi tags) does not mean that an AF User fully understands all the pi tag properties and does not mean that person is capable or permissible to modify normal process tags on interfaces. The typical AF user also may not fully understand the extensive usage of parameter substitution parameters, nor the need to keep some organization and structure necessary for us to to manage, find, and troubleshoot these tags when there are problems.
having a defined exdesc=AFPAth... like in my above example is critical for us to be able to find where tags are being populated from later. This allows the tag name itself to deviate from the typical naming above while still allowing us to find the analysis.
just because someone is given permissions to create analyses and thus pipoints does NOT mean we are making them piadmins where they have potential control over LOTS of process tags. But they should be able to maintain some permission on the tags they have created so that they can make changes to them . . . like switching step=1 to step=0 or vice versa. Thus making sure they are have the appropriate ptsecurity to allow them to edit the tag
also access to the management tab in PSE is not the problem . . . regardless of whether they have that component installed . . . the above issues can only be addressed by modifying every individual's PSE installation . . . instead of having everyone's PSE settings at least default to some server side configuration. Its unmanageable to have to make this change on every users computer.
one last example . . . at this was done by a 'piadmin' . . . because even many piadmins find it easier to create tags in SMT than use PSE to create the tags because PSE, by default, puts that ridiculous ID string of characters on the tag name and they don't realize the setting in PSE exists to modify that default behavior. The piadmin created a tag with the identical naming structure as one of our ControlLogix tags and had an AF Analysis output to it. Causing lots of confusion as why an apparent ControlLogix tag had no pointsource and no instrumenttagand, and difficulty for us to find where the analysis was.
Hi, can you verify that you allow your users to create analyses and create PI Points, yet you don't give them access to the management tab in PSE. Do you consider these users to be restricted users?
Another fact is that if the user has no access to the management tab in PSE, they can not access the "PI Point Creation User Settings".