As a customer, I need to ensure that the primary instance of the adapter fails over to a secondary instance to minimize data loss.

Currently the PI Adapter for OPC UA only collects unsolicited advised data that is different from the previous value. We would need to see a polling feature to be able to:
- Refresh slow moving streams with updates with the same value but different timestamp
- Get the information in the OPC UA Server at a defined time stamp

This polling feature could pave the way to more features like setup the equivalent of "Trigger event tags" offered by the old PI OPC DA Interface technology

Same as the PI Interface for OPC DA feature with "Trigger Tags", the idea is to poll for updates on a series of item streams (tags) only when a certain item stream updates.

The benefit of this is to create timestamp alignments between a series of data points, when a cycle begins or ends for instance. This is very useful for analysis and visualzation of production cycle efficiencies.

The PI Adapter should be able to create a data pipe listener on certain streams (unsolicited reads) that would trigger the writes back to the OPC UA Server.

This is useful when providing set points to the equipment without the need of establishing a second (DA to UA) data flow in parallel.

Currently a StreamId cannot have more than 100 characters because of a limitation in PI Cloud for this type of object. Nevertheless for PI Cores and PI Data Archive, the PI tag limit of characters is 1024.

PI Adapters when writing to a PI WebAPI OMF endpoint should accept StreamID with more than 100 characters length to take into account a future migration path for customers currently using PI Connectors and working with existing PI tags with long tag names.

In our environment, we plan to deploy PI Adapters on Windows Server class OS. We are in a strict minimum privileges environment hence we only make use of gMSA on all PI services.

We do not want to make use of a domain service account where the password is known (by a few) and can be impersonated. PI Adapters should be enabled to make use of such gMSA type of account to run the service in a secure manner.

Adapters are currently only listening on localhost (127.0.0.1) causing them to be only accessible locally. For docker containers, they can only be accessed from within the container or directly on the host (with the --network host switch which results in not containerizing the container's networking) but they cannot be accessed for elsewhere (not able to bind them to 0.0.0.0)
This makes adapter management very difficult in distributed environment.

We have customers who are using AspenTech IP 21 and would like to have data replicated in both PI DataArchive and OCS in the future. Since the PI Interface is a bit outdated, a new PI Adapter would make perfect sense (since there is already a PI Connector for WonderWare and Honeywell PHD). The PI Adapter shall support both PI and OCS.

As a PI System Administrator, I would like for the PI Adapter for OPC UA to support array data types from the OPC UA Server. A large amount of our data may be contained within arrays on our OPC UA Server, so we would not currently be able to collect that data.

Some MQTT devices do not send json payloads; for example, some devices send a single value as the payload for a specific topic.

It would be beneficial for the adapter to be able to handle this rather than to convert these payloads into json before they get to the adapter.

Having to deal with a MQTT broker between the data source and the PI Adapter adds a single point of failure to the data handling and weakens the data flow end-to-end.
From the data source we can guarantee that the data will reach the MQTT broker, but we cannot guarantee that the PI Adapter will in turn reach the broker.
Goal is to secure the MQTT data collection end-to-end (equipment to PI Data Archive) with reliable SW built, maintained and supported by OSIsoft.

We would like to be able to see the adapter log files via REST calls. Going to the machine itself to view is problematic because of remoting into the router and then going into the container to view. I think in a lot of containerized situations a REST call access would be better.

The PI Adapter for MQTT only supports username and password authentication from the adapter to the broker, so it will not be able to connect to an MQTT broker that requires client certificates in order to authenticate client connections.

To support the migration path of existing PI Interfaces / PI Connectors to PI Adapters, the installation packages available and SW requirements only has been certified for Windows 10 and Windows 10 IoT. We would require the ability to re-use existing HW in place for collecting data instead of having to deploy new HW with compatible OS that are not server class OS.

There should be a way to configure the PI UFL interface to both discard duplicate events (same value at the same timestamp) and record multiple unique values for the same timestamp when these events come from multiple data files.

For example, if multiple data files contain the following entries:

(Timestamp)  (Value)
11:00:00      ABC
11:00:00      ABC
11:00:00      XYZ

The following data should be archived:

(Timestamp) (Value)
11:00:00 ABC
11:00:00 XYZ