Pi System Structure

Your idea definitely holds merit, if for no other reason the staging location provides a check-point of where the problem lies... Inside the facility or on the corporate system. Segmentation also adds another layer of protection between the PLCs running the process and the remote PI system. The last thing you want is someone pointing fingers stating the corporate caused a problem at the facility...

Adding the layer will likely slow down work because corporate can't just reach down into a control system to retrieve the data... And that is a good thing because it makes people think about what they are doing and communicate.

We are a much larger company with facilities scattered around the world, but employ the strategy you suggest. We have an interface boxes between the DCS/PLC/etc. and the facility PI systems... Then important data we want to move to corporate moves from the facility PI systems to corporate... If we every add PI to our small converting plants we have already decided we would regionalize/centralize the PI servers, but interface nodes would still reside at the facility...

hope this help.

rick

Thanks Rick, much appreciated.

I also agree with Rick. You could even do some segmentation at the central server with AF. This centralization might actually promote some cooperation between engineers on common mill problems being solved with AF. I am seeing a trend toward this kind of architecture.

Another up vote for what you are suggesting, especially if the Pi server is remote. that should allow you to reduce a level network traffic and, depending on how you deploy, should provide a level of security between the Pi interface and the PLC as you would only need to open up ports required to communicate to a Kepware OPC server or the like while keeping access to the PLCs/DCS secured. As well as provide you with a way to quickly see if (and which) device has stopped communicating to the OPC.

Also agree with Rick.  Kind of ironic that engineers who work with distributed control systems want a centralized, enterprise solution.  Distributed interfaces help with troubleshooting and customization.  And Rick is spot on that you do not want a business network to reach down into a process network.  Granted it could be at the DMZ between them but that would only work for one site.  An enterprise server cannot be at a given site's DMZ.

I fully agree with Rick. It makes a lot of sense to have an OPC Server intermediating communication between the PI Server and PLC/DCS

Also, in most cases, you'd have to set up multiple interfaces to talk with different PLCs/DCS and that would require more effort to administrate.

Echoing everyone else's comments, definitely try to avoid having one interface reaching across the WAN to your 5 sites.

It's always a good idea to have your interface as close to the data source as possible. The risk of losing data is lower as the distance / number of devices between the PLC and the interface is low, and data can be buffered there at the interface if the WAN connection to the enterprise PI server is down.

Ideally the Kepware server and the PI interface are on the same machine. This may not be possible, depending on the security requirements of each site. Having the PI-OPC interface in a DMZ with the Kepware server on the control network is a reasonable compromise.

Pi OPC and Kepware would be on a local server at each location, with the WAN between them and the PI Data Archive servers.

I figure that if the WAN went down, each location could buffer the data till the WAN came back up.