Send Data Hub stream data to PI System

This is on behalf of a customer. They are a global mining company with operations in several countries, including (but not limited to) Brazil and Canada.

They want to use AVEVA Data Hub to send data from on-prem PI Systems and make them available to 3rd party companies which will, along with other user cases, analyze data, calculate performance and suggest changes to process parameters.

In order to suggest these changes, the 3rd party will write results back to ADH streams and this data needs to go back to on-prem PI System so plant operators can view the suggested parameters and make the necessary changes in the process.

Custom applications are not an option as they would increase custom software landscape (and therefore maintenance) when compared to an off-the shelf solution.

Unfortunately, PI Connector for UFL is not an option at this time since it does not support ADH Client-Credentials authentication.

Acknowledging that adapters are the path forward for data collection, an option would be to have an adapter built for data collection from ADH or incorporate this feature to the PI to Data Hub Agent, both being able to send messages to a PI web API OMF endpoint.

Remote edge devices collecting data (on behalf of another company) with the requirement to share with that company and also on-premise PI Server.

Ability to share OSI PI data with external company who has not got OSI PI as a subscriber

Can't stress enough the importance that communication with OCS be bidirectional with a on premise pi system that is easy to configure (i.e. NOT programmatic methods - we aren't all developers). It would be preferable if this functionality be built into the existing PI to OCS Connector. We have consultants that push data into our OCS instance (which is great), but we also need to easily be able to pull it down.

This is on behalf of a customer, Clearway Energy Group. They are a renewables energy producer and have an on-prem PI System currently. They don’t have OCS at the moment, but are looking for ways to share data with their customers, vendors and business partners. They are looking at PI Cloud Connect as a preferred method for this, as their customers, etc. also have on-prem PI Systems. However, they are interested in OCS to complement their on-prem PI system in the future, but worry about ways moving forward that their customers etc. can get that data into their own on-prem PI systems.

PI pushes data to OCS for DS/ML/AI purposes. Cloud applications create predictive outcomes which needs to be pushed back into future tags in the PI System for situational awareness.

Large customers looking into IoT require OCS to collect data, which later will be sent to their Corporate PI Server. This is a way to keep their Corporate PI System isolated from external sources, and sent data to Corporate only once its clean and fit to purpose.

This functionality will be very beneficial for customers that use contract manufacturing. I have more than one customer that uses contract manufacturing and has a central PI System, and are having to come up with bespoke solutions to get data. Not all contract manufacturers will have a PI System, some barely have a historian, so placing a PI Adapter and EDS at their site to move data to an on Prem PI System via the cloud will open up this market. There will be a shift towards more contract manufacturing when cell and gene therapy become more prevalent.

There is a tremendous use case using the UFL Interface to bring the OCS data back to PI. Currently, the security issues prevent this from being a possibility. In most instances, system integrators and 3rd party data providers need the ability to be non-invasive in regard to end user fire wall. This will dramatically effect the usability of OCS and effect the total number of tags managed within the PI System. When considering the global push for digital transformation and IIoT initiatives, this is an immediate need.

When discussing the adding OCS for IIOT projects with customers with on-prem PI systems, this topic comes up regularly. Perhaps for additional security, a data-diode can be considered in the physical architecture to prevent external intrusions via our OCS instance.

I think the best solution from a user perspective would be to integrate this functionality straight into PI to OCS Agent. But having PI Connector to UFL to be able to handle OCS authentication would be a viable solution too (and could be use for those cases that only getting data from OCS is necessary, not sending it).