Interoperability in automation is done with OPC. OP-wut?
- OPC = Ole for Process Control
- A open, proprietary protocol for how automation systems can talk to each other.
Since then, the big names in the factory automation decided to form a consortium manage the OPC standard for interoperating with each other...
And since then, OPC has basically taken over the market.
How it works is this:
You have PLCs and DCSs for process control over decades of operations. And you need data from each of these to monitor your process. These PLC and DCS vendors will write OPC Servers. In some cases, 3rd party vendors will write OPC Servers for these devices.
What's an OPC Server?
- OPC Server
- Software that outputs (serves) data in OPC.
- OPC Interface
- Software that can "listen" to OPC and translate it into the native language of another piece of automation software.
You're trying to connect your OSI PI system to an Emerson DeltaV system. Since an Emerson DeltaV system has an embedded (crippled) OSI PI system inside, you need just a PItoPI interface to connect the two automation systems and send the data from DeltaV to OSI PI.
But suppose your factory has other pieces of equipment that don't write natively to OSI PI... or more likely, you're not interested in buying the an interface for each flavor of automation that you own.
This is where OPC really shines. What you do is, you try to get OPC Servers from the automation vendors. Then you purchase exactly one OPC interface from OSIsoft. And for each OPC server, you configure and instance of the OPC interface.
by Oliver Yu
And now, you eliminate a lot of future headache because you've standardized on OPC and eliminated having to support an interface per automation vendor. You can train on the widely supported OPC standard. You have access to native OPC Servers or in cases where they don't exist, you can purchase third-party OPC Servers that do the heavy lifting.