PI System Connector:  Need real time snapshot data support for the PI System connector.

As an equipment specialist working centrally, I wish to deploy my AF Element Templates including Analysis and Notifications Templates to my remote sites so I have them managed from a central location. This also insures that remote sites are using the same calculations and KPIs.

The PI System Connector allows to include PI Point replication directly from the PI Data Archive even if they are not reference in the PI AF hierarchy with the "Include all PI points from this PI Data Archive" option.

I would like to replicate only some PI Points that are not referenced, not all. This would remove the need to maintain both a PI to PI and a PI System Connector.

I could create a bogus AF Database referencing those points but I would prefer not to.

I would like to have the option to replicate AF Analyses using PI System Connector with the option to mark the desired analyses for replication.

Would like to have the connector support Null System digital states. Null system digital states can work locally on a PI Server. Would like the connector to support all the options found locally so that we could accurately sync systems.

As an architect, I have to model AF structures at a central location, and push them to distributed assets.
I would like the ability to design my AF structure centrally, then replicate it to my distributed assets (e.g ships). Example features that are needed:
- Ability to include Analyses, Notification Rules, and their templates in the synchronization
- Ability to not copy the data from source to destination

The 30-day history recovery by the connector after restarts should get activated only after the initial history recovery is confirmed to have completed successfully.

Need to add instrumentation to PI System Connector wheras exposing perfmon counters (so PI perfmon can store accordingly in PI tags) on AVG data flow in events/sec for a 120 seconds time period, status of the connector, etc

Ability to have deletions replicated across systems as well (might need to be a config option on how to handle).

Allow history recovery for PI System Connector to be longer than the current max of 30 days

To use the PI System Connector for enterprise applications like machine learning, mvda,... it should also be possible to configure "output tags". the result of analytics on enterprise level are needed also on local PI systems, so for some attributes/tags a two way communication is required.

Currently, if the PI Server specified in the source PI AF server is unreadable from the PI System Connector node, the Connector will forward the listed source PI Server name in the configuration string to the destination AF Server. This causes confusion as the Destination AF server will likely not have access to the unreachable source PI Server. Instead, The connector should create a configuration string on the destination AF server stating that the source PI Server Host is unreachable.

All in all a wrong configuration should be undone easily and not result in a complete re-installation of the system. If this is possible by using powershell scripts (an example is installed for all connections - RemoveAllConnectionConfigurationsRelay.ps1 - maybe it might be a base for a script to remove single registrations).

The PI Data Collection Manager User Interface has the options to "Collect All Data from this Entire Database" and "Collect Data from a Specific Branch". What we want to do instead is to "Collect All Data from this Entire Database EXCEPT from a specific branch". This is because the users in the target (test) database do not have permissions to configure the branch (element) that we want to exclude from syncing. The current workaround is to install a PI System Connector for each branch of the database that we want to include.

Is it possible to get it soon? it's not an option to set up a host for each system connector. it might be needed to have different data sources to define independent data streams for different use cases (e.g. send Data of AF Branch "A" to global Destination AF Database "A" and Data of Branch "B" to global Destination AF Database "B").

Point changes on the source currently necessitate a restart of PI System Connector to rectify the streams. Allow the tau framework to handle these changes at runtime without restarting the connector.

Currently, if the point type changes are made during runtime, because of the persistence of streams, there is a flood of errors in the message logs which are not consequential to the nominal functionality of the connector. This leads to erroneous conclusions about the state of the connector.