For example, model inference data is written to storage and required destination is a PI System.

Currently, the PI Adapter for OPC UA sends good quality data to the configured data endpoint with no way to filter on different good quality statuses. There are several OPC status codes that fall under the Good Quality Data classification.

When the status code changes from "Good" to "GoodOverload" because they fall under the OPC Good Quality Data classification, both are being sent to the configured data endpoint.
User would like to have the option to filter good quality data. For example, send only data with "Good" status code to the endpoint and filter out "GoodOverload" data.

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.

Currently if PI Adapter for OPC UA received a status other than "Good" for an event, it will not write the data to its endpoint. PI Adapter for OPC UA should be able to write a SYSTEM digital state that indicates the status it received.

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.

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.

When utilizing the SparkplugB protocol for MQTT, it would be beneficial for the adapter to be always listening for birth and death messages from specific Edge of Network nodes.

This way, the device can send a birth message to have itself added to the data selection array, then a death message to have itself removed. This would enforce a data selection array that's always reflecting the current state of devices connected to the broker, doesn't miss any data messages, and doesn't bloat over time.

As a PI System Administrator, I'd like to be able to trace values being received, and subsequently being sent by the Adapter, similar to PI Interfaces.

Having the ability to trace/log timestamps and values for specific streams would greatly help in troubleshooting data issues, without requiring a network trace or other troubleshooting tools.

As a PI System Administrator, I would like to be able to apply conversion factors to the data that is being gathered from our OPC UA server. This would allow us to get data in the format/units we'd like, without requiring extra tags and/or calculations.

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.

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.

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.

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.

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.