Add an option to receive real-time data in the client during recovery of buffered data:

The default behaviour of our interfaces / buffering is that after a connection failure the buffer will be flushed and data will be sent in it’s original order (which is correct behaviour). During that time, there is no view on the realtime (snapshot) data for end users.

Customer is asking for an option to not have to wait for the ‘new’ snapshot data. 

It is clear that this would produce many OOO events, which will influence PI Data Archive performance and most probably will influence any analytic/report/visualization on top of those tags.

Perhaps there can be a way to have a parallel dataflow to the visualization layer, showing 'new' data whilst buffered data flows through the Data Archive processes in the background?

We've noticed this particularly with the RDBMS-PI interface when configured for failover: Health tags that are only written to when the interface becomes primary or has completed its first scan (eg Point Count, Scan Class I/O Rate etc.) say 'Intf Shut' when the instance is actually in 'Backup' mode. Even when changing to Primary status, many of these tags don't get a value till after the first scan, which could be quite a long wait.

I would like UnitInt interfaces, on startup, to post an 'Initialising' or 'Awaiting 1st Scan' or some such digital state to all health tags that would otherwise still be saying 'Intf Shut'.

I think it would be a good idea to allow exception settings to be created. The DeltaV history collection settings only allow for compression. Since many/most users use 1/2 compression for their exception value then perhaps we could have a check box on install of the smart connector to turn a general exception rule on. The point of the smart connector is so that a user shouldn't have to modify tags after they are created from DeltaV.

The other enhancement that would be great is if we didn't have hard-coded security groups (DeltaV and Deltavadmin user) but could put in the group security required so the point security for each tag would be created correctly to use the Identities we already have defined on our system, perhaps a read/write group and a read only group (so that we don't have to use PIWorld if we want to limit data access).

Currently, it is recommended to use the read-only version of a PI Interface if only reading is required, and to have separate read and write instances of the read-write version of a PI Interface if writing is required. (Reference: page 15 of the PI Interface For OPC HDA user guide, and I assume that the recommendation applies to other PI Interfaces as well)

This approach is unnecessarily complicated and can still be made more secure. Instead of having read-only and read-write versions of a PI Interface, consider having read-only and write-only versions of a PI Interface. That way, the recommendation becomes impossible to violate and is therefore no longer needed, and it avoids the migration from the read-write version to the read-only version if writing is no longer required.

Since PI Interfaces are slowly being replaced with PI Connectors, the implementation of write-only versions makes sense only for commonly used PI Interfaces such as OPC DA, OPC HDA, RDBMS, and SNMP.

Currently when running any event frame generator interface (EFGen, PIFTBatch, etc.) in history recovery mode, there is no way to monitor progress of the actual history recovery. The only way to determine status is to check message logs periodically looking for the message "Switching to [REALTIME] data processing.". It would be helpful if there was a way to check progress of the history recovery (i.e. percent complete) along with an estimated time until completion. I'm currently in a position in which I'm running a PI-FTBatch interface history recovery, but also have users who need access to FTBatch EVT data generated after the start of the PI interface history recovery. I currently have no way to communicate to the users how long it will be before this EVT data is processed into event frames in PI.

Additionally, it would be great to have the ability to perform history recovery on a single EVT file in the event of an issue with a particular recipe. Currently history recovery is a time based operation only. Allowing for history recovery on a single EVT would allow a more surgical option while helping minimize the time not spent in real time mode.

This functionality would allow users to test the connection to the data source and inspect the data that is retrieved without sending it to PI. That data might be written to a text file, for example.

This would allow users to verify settings and data integrity without needing to delete archived values, for example. Potentially, this functionality would also have some type of PI point selection so that user would be able to select which tags the interface should use for this test mode, rather than using all tags (The interface would essentially assume that all other tags have scan off).

Please upgrade the most commonly used PI Interfaces so that the only Microsoft Visual C++ Redistributable version that they require is the 2015-2019 version. This will reduce the size of the install kit, make it faster to download, make it faster to install, reduce the wear on the customer's disk, and reduce the clutter in the list of installed programs.

Here are the versions of the Microsoft Visual C++ Redistributables that some of the most commonly used PI Interfaces currently use:
OPC DA & OPC HDA: 2008, 2010, 2012, 2017
PI To PI: 2008, 2012, 2017
UFL: 2008, 2012, 2013, 2017
RDBMS: 2012, 2019