I think this becomes more of a change management issue rather than looking for a technical workaround.
The OPC ItemID must map to the PI Point InstrumentTag attribute in order for the interface to be able to load the tag and collect data from the OPC server - this much you know. If your OPC server updates are changing the ItemID of any given point within the OPC server, then a corresponding edit to the mapped PI Point's IntrumentTag attribute must also occur. PI can't dynamically change the InstrumentTag in response to a change in the OPC server.
If I'm understanding the nature of your changes correctly, then you should only need to change the InstrumetTag attribute of the affected PI point(s) - toggling the scan attribute shouldn't be required as editing the instrumenttag should be enought to force the interface to reload the tag. Restarting the interface is a drastic measure, and I would probably only consider that if there was a large number of edits (eg, > 500).
Therefore, I consider this only to be a change management issue. There is no escaping the fact that a change to this fundamental configuration item at the OPC layer requires a change at the PI layer, and that a reload of affected PI tag(s) is needed within the interface.
I agree with you, but unfortunately updates that change the itemid are very regular during production so this becomes a constant issue since the tag reload and opc change have to be simultaneous to avoid data loss. And we have to change scan or restart the interface because the instrument tag attribute refers to the opc item name, which does not change, not the opc item id, which does change.
I think some discussion with your OPC server vendor is in order then. For a PI OPC interface, the instrumenttag attribute of a PI point maps to the OPC point's ItemID. If this is constantly changing because of updates pushed to the OPC server then I would ask what is the nature of these updates, and why do they need to modify OPC server point ItemID's? These shouldn't need to change for existing items.
Again, I agree and were are having that discussion. In our deployment, the instrument tag maps to the item name, not Id. The item name never changes, the id does. At least this is my understanding. To clarify. I can simply turn the tag scan off then on and PI will begin collecting data again, instead of getting a configure error, without ever changing the instrument tag attribute.
To update the post,
We've consulted with Siemens and they have assured us that the behavior we are seeing is normal, that when updates are pushed to the Siemens servers the OPC Item ID is changed, but the OPC Item Name is not. The link you provided does seem confusing to me though.
The instrumenttag attribute maps the PI point to an OPC item. This field must exactly match the item name as defined on the OPC server, including any punctuation, spaces, and case.
To display the full ItemID required for instrumenttag field...
These two lines refer to different OPC Item attributes... line one states the instrument tag field must match the Item Name, line two indicates ItemID...these are different OPC Item attributes.
After several discussions with Tech Support, I have confirmed that the OPC interface uses the supplied Item Name to retrieve the ItemID from the OPC server upon tag load, and therefore when the ItemID changes (not the Name) the OPC item reference is lost until we force a tag load by restarting the interface. We are not making any changes to the PI Tag properties at this point, simply restarting to force a tag load.
Lastly, if this is indeed normal behavior for Siemens OPC Servers, I can't believe we are the only ones running into this issue.
The ItemID is the unique identifier for a tag on the OPC Server. If this changes, there is no way for an OPC Client to know what the unique identifier has been changed to. Additionally, if the initial request for the ItemID failed, it would not make sense for a client to continually request for the invalid ItemID as this would take up unnecessary network bandwidth and add additional load on the OPC Server, which is why the interface will not attempt to reload an incorrect ItemID.
If an ItemID changes, you must make the correct changes to the instrument tag field. If you are performing bulk changes, you may also restart the interface for those changes to take affect immediately (the Interface will pick up PI Point configuration changes at a rate of 25 tags every 30 seconds by default).
The preferred workaround here would be to discuss with the OPC Server vendor why ItemIDs change for existing tags . These should be unique identifiers that should not need to be modified for existing ItemIDs.
/MA (Mass Tag update) parameter works well for mass tag updates but in case of any errors with items id interface stop collecting.
Mass Tag update : KB01005 - Slow PI Interface for OPC DA Startup
Reference : PI Interface for OPC DA
/Updateinterval is another parameter to modify but make sure your OPC server supports preferred interval before making the change.
If the OPC interface detects new points or changes to existing points, it reloads those points from the PI Server. The interface processes 25 point updates at a time. If more than 25 points are added, edited, or deleted at one time, the interface processes the first 25 points, waits 30 seconds or the time specified by UniInt /updateinterval parameter, whichever is lower, processes the next 25 points, and so on. After all points have been processed, the OPC interface resumes checking for updates.
Note:During startup, the OPC interface loads all the points that it maintains. After startup, the OPC interface processes subsequently-updated points periodically, in batches of 25. For efficiency, if you’ve changed a large number of PI points, stop and restart the interface.