whenever the OPC server undergoes any restarts or configuration changes, the OPC interface will delete all old connections, groups, etc. and it will establish a new connection to the OPC server, loading all ItemID's etc (as if it is an automatic restart of the interface).

The reason for this enhancement request:
if OPC server is restarted or undergone configuration changes, all the handles and subscriptions for advise tags are not valid anymore. The interface would get the advise values in an inconsistent manor (values betwen the OPC server and the interface would show a mismatch)

Emerson has a new PK Controller based DCS available (in lieu of full blown DeltaV). This new device is contained with OPC-UA and Batch Exec/Historian. We want support for the existing EMDVB interface to supply S88 based batches into PI Event Frames and/or PI Batch. Additionally, we will want to run the PI OPC-UA interface to get the live module data into PI tags. Do you have support for this today?

Prior to UniInt v4.6.0.60, UFO sync files created during interface startup would inherit file permissions from their parent folder (assuming child inheritance had been enabled on the folder).

With UniInt v4.6.0.60, this behavior changed and now sync files created by the interface do not respect inheritance.  Instead, they are created with a standard ACL containing only the local "Administrators" and "Users" security groups.

For users with complex file permission schemas, this change introduces additional, unnecessary configuration efforts that scale as interface numbers grow beyond the site-level. 

Allow for monthly scan intervals for scan classes. i.e. "scan monthly on the first hour of the first day of every month".

EMBVBCS currently does not bring in UOM from source files to the interface.

Add an option to encrypt trafic between interfaces/connectors and the PI Data Archive

There needs to be a 64-bit version of the CatGH5 interface that is capable of parallel processing in order to efficiently process an quantity of data/files (that the 32-bit version is not up to the task of handling well).

(Posted on behalf of our customer)

It can reduce the chance of startup failure because of the connection to PI Data Archive time-out. It's also helpful if interface can reduce time to get PI point information from PI Data Archive.

We are using this interface to capture meter attributes and measurements. However, the voltage comes in the XML files as an "instrumentation value", which is not currently supported. We would like to bring the voltage into a tag for the meter to use in PI analytics.

When our EEAMAS Interface was originally implemented, the Head_End parameter was set to "Elster", the vendor name for our meters. So all of our meters from that interface are named Elster_xxx. Elster was purchased by Honeywell, so the name no longer makes sense. We would like to change our prefix for the elements to something more generic like "MTR", since the element name is something that is exposed regularly to end users.

I understand that you can remotely view logs using pigetmsg. However this solution does not work for me as the interface is on a controlled network that only allows outbound traffic. I would like a way for the interface node to be able to push out interface logs somewhere such as to my DA, that way I could use SMT to view my interface logs.

Provide a configuration option in UniInt interfaces, to enable shutdown of the interface if it consistently receives error messages when attempting to write to PI. Recently had an interface successfully connect to PI but not achieve write access to its tags; would've been nice to have this interface gracefully shut down or restart, and allow its UFO failover partner to serve the data flow

Add support for BACnet Setpoint objects in the PI BACnet interface.

Add functionality for the Davis to Pi Interface to read additional sensor data points. The Davis to Pi Interface does not support the use of additional sensors, such as a second or third temperature sensor. The Davis console supports additional sensors, but the Pi Interface cannot read them.

Add ping -i feature to the interface and allow for either the output of the ping time or destination in the PI tag.

Case: This will allow for IT to monitor the network path taken in communication from one site to another. If the route has changed in the communication of devices, we will be able to track it in PI and know exactly when the route changed.

When using a single PI tag, the fields are delimited by the pipe (|) symbol by default.
It would be useful to change it to another delimiter or a combination of others. There could be messages containing this pipe (|) symbol, which would make it difficult to split the fields afterwards.