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?

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.

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).

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

These days, 32-bit operating systems are used for 1 of 2 reasons:

• Somebody accidentally installed the 32-bit version instead of the 64-bit version, which is a mistake that OSIsoft has no obligation to accommodate.

• The computer is very old, in which case it is due for an upgrade. If companies want to keep their operating systems up to date, they will need to replace their computers because of the minimum hardware requirements of Windows 11 and because Windows 11 does not have a 32-bit version. The replacement computers will be able to run the 64-bit versions of PI Interfaces, so the 32-bit versions are no longer needed.

Please retire the 32-bit versions of PI Interfaces that have a 64-bit version. It will be less for OSIsoft to maintain and less clutter for customers to sift through when they go to download the PI Interfaces.