As a PI to OCS Administrator, I would like to be able to modify a PI to OCS Transfer after it is created. I may need to add data to the transfer - because we added new data sources, or because I may have missed some data that needs to be included. This is important so I don't have to delete the existing transfer and then rebuild it with the modified list of PI Points.

Sometimes, the PI2OCS agent seems to have some interruption in replicating data from a PI Data Archive into OCS. It would be beneficial to have some more monitoring options (in addition to what is available through the OCS portal) either by supporting performance counters in the Agent software or having some statistics available through the REST API. Either receiving a notification when data is not current anymore would be a great accomplishment. Connection stability is crucial for using OCS within a production environment.

In addition to building the transfer list via searching a data archive, it would also be good to allow the user to reference a file (e.g. CSV) that has a list of points to transfer.

As a PI System Administrator, I would like a way to deploy PItoOCS in a secure and manageable way so that it is easy to maintain, and I can trust it is secure.

Currently, OSIsoft recommends PItoOCS be installed on a separate computer from the Data Archive to which it connects. PItoOCS only supports a single connection to a single Data Archive in the current version.

OSIsoft Product Management would like to better understand customer requirements about deployment of PItoOCS in their environment.

Enable a more seamless upgrade experience for the PI to OCS Agent, the on-premises component required to transfer data to OCS

As of this writing, the PI to OCS Agent sends data every 30 seconds or every 10,000 events and this is currently not configurable. The idea is to allow an administrator to configure these types of parameters so they could control how often data is sent from PI to OCS. This idea came from discussions where there are PI Tags that update infrequently and those are the only tags that are part of the PI to OCS transfer.

The Pi to OCS agent is not collective aware. Instead, only a single archive can be mapped to the agent. Please allow the Pi to OCS agent to utilize collectives. This increases the system's overall resiliency.

Ability to see how stale data is. Do I expect to see data but it hasn't been updated in a long while?

PI to OCS creates an OCS stream type for PI digital tags with a property called DigitalStateName. This property includes both the "real" value of the tag's digital state set, but also the System Digital State (No Data, Error, Comm Fail, etc) when the Value property is null. It's difficult to distinguish what strings correspond to values and what strings correspond to errors.

Send soft sensor and IOT device data straight to the cloud bypassing traditional automation and plant floor networks.

Provide built in dashboarding for the data in the cloud.

Allow PI to OCS Data Transfer to be defined by Search Criteria such as Point Source or Tag mask and dynamically include\exclude points based on the criteria -- rather than building an explicit list of tags.

For PI Point Data References brought in from PI AF using PI to OCS, it would be valuable to to have additional metadata fields on the OCS streams to indicate AF information such as the attribute's Path and UoM. This could allow us to leverage some of the hierarchy we have already built to better understand the context of streams, as well as AF UoM that may be more useful than the PI Point's engunits.

As a PI to OCS Administrator, I would like to be able to minimize the PI to OCS Post Installation Configuration Utility so I can more easily switch between running applications to gather necessary information to correctly configure my PI to OCS connection.

As a System Administrator in charge of deploying software at my organization, I would like PI to OCS to support multiple transfers from a single Data Archive, with a single agent so my Data Owners can manage the transfer of data without impacting other Data Owners in my organization. This will also provide more granular control for smaller data transfers, instead of one single data transfer that could encompass 100,000's to 1 million PI Points.

By placing the engineering units from the data archive into a stream metadata, it precludes their usage within OCS's UoM functionality (such as data view column labels for example). The EngUnits won't be trivial to sync into OCS, but an attempt to find a match, then prompting for manual intervention where necessary would be helpful to get the engunits synced into something more functional.

Allow for manual configuration of proxy settings for the PI to OCS Agent. Items such as the endpoint to use as well as how to authenticate (default credentials, specified username/password).

I am bringing some of my customers' PI Data into OCS. I would like to be able to add a prefix to the data within a particular transfer, because it is very possible my customers could have PI tags with the same name, and even PI Servers that are named the same. I am concerned about the possibility for naming conflicts.