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

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