It's kind of like a translation layer. You use an OPC Server to translate between whatever your device speaks (Modbus, DDE, DNP3, etc), and OPC. The application that needs to use the data needs to have an OPC Client. OPC Servers and Clients are software.
Since there are hundreds of OPC Servers out there, you can get OPC from most devices. And since you can get OPC from most any device, pretty much all process applications have OPC Clients built-in.
Before OPC, every SCADA and HMI application had their industrial communications network protocol drivers as part of the application. Since most industrial network protocol specifications were (and still are) proprietary and secret, that limited your choice of SCADA and HMI to whichever one supported the hardware you were planning to purchase.
Someone then came up with OPC. All OPC is, is a "standard" software interface between a SCADA or HMI program and a communications protocol driver (its also sometimes used for other things, but it's primarily intended for communications drivers). I said "standard", but it's not an open standard. You have to be a member of the OPC club (OPC Foundation http://www.opcfoundation.org/) to get access to the specs. However, it does mean that you can buy your SCADA software from one vendor and your communications drivers from another vendor, and there's a reasonable chance you can (with enough effort) get them to work with each other. There are other specialised versions of OPC for things like database connections, etc., but the original purpose and the primary purpose today, is for communications drivers.
After reading the above, the obvious question which should come to mind is why something like OPC is even necessary. It seems like a lot of complexity and effort for no obvious benefit. After all, you can send e-mail and browse the internet and do multiple other things from your PC without needing anything like OPC. The e-mail program knows how to talk to e-mail servers, and the web browser knows how to talk to web servers, and the same goes for so many other applications. Why do we need all this extra complexity and cost as soon as we are talking about industrial applications? The reason for this is that the internet runs on open protocols while most industrial protocols are proprietary and secret. If we used mainly open protocols in industry OPC would be completely unnecessary. The protocols would simply be built into the software that needed to use them and we would just take it for granted that two things could talk to each other. OPC allows companies that refuse to cooperate with anyone else on a open basis to at least cooperate on a very limited basis.
What OPC *isn't* is a protocol. We see a lot of questions here asking things like "does PLC 'x' talk OPC"? That sort of question makes no sense. The PLC talks Modbus or Profibus (or whatever). What happens is the SCADA software talks to the OPC software, which in turn translates the requests into the protocol which the PLC understands (e.g. Modbus), and then passes the request in that protocol. The PLC (or other field device) doesn't know the OPC software exists. It just sees the request in the protocol that it natively understands.
The OPC software that you see is called an "OPC server" (for reasons that I won't go into). There is another half of the OPC software which you don't normally see which is compiled into the SCADA or HMI program. If you were writing a custom program in C or Java (or whatever), you would see these as "OPC client" libraries. We won't go into that much further, other than to point out that these client libraries are there. The SCADA or HMI software can't talk to an OPC server without them, but (as mentioned above) since their built into the application you don't normally see them directly.
OPC stands for "OLE for Process Control". "OLE" in turn stands for "Object Linking and Embedding". I won't go into a long boring explanation of ancient computer history, so I will skip forward to a few years ago.
Current versions of OPC depend very deeply on certain design details of MS Windows, which is why it only works on MS Windows. I mentioned that OPC *isn't* a protocol. Rather, it uses Microsoft COM/DCOM (MS Component Object Model/MS Distributed Component Object Model) to implement a "remote procedure call" (RPC). A protocol passes data back and forth, while an RPC calls software functions in a remote program directly. To perhaps phrase that a bit more clearly, sending a message using a protocol such as Modbus means putting some data into a package and sending it off to some other device. So long as the device on the other end understands the protocol, it will know what to do with the data. An RPC on the other hand means allowing one program to reach deep down into the guts of another program and manipulate its internals directly. An RPC gives you a lot more control, but it is also means that it is usually a lot more complicated.
The preceding might sound a bit uninteresting, but it is necessary to understand the OPC situation today. Current versions of OPC are based deeply and fundamentally on the MS Windows COM/DCOM model. The problem for OPC is that Microsoft has obsoleted those features. COM/DCOM turned out to be horribly insecure, and very difficult to set up so that it is secure but still does something useful. This is why we get so many requests for help here from people who can't get their OPC servers to talk to their SCADA systems.
Microsoft's solution to that was a new SOAP (XML) based RPC mechanism (I can't remember their current name for it) to layer on top of the existing COM/DCOM. The OPC club then dutifully began work on a whole new specification for OPC that used the MS SOAP based RPC. That didn't turn out to be such as good idea either. I won't go into the details, but MS's SOAP based RPC turned out to be constantly changing, badly documented, and up to several orders of magnitude slower than other methods. The computer industry in general seems to be writing it off as a bad dream and moving on to simpler ideas, so the whole SOAP/XML idea seems to have come into vogue and gone out of fashion faster than the OPC club could figure out how to use it.
I don't know how internal decision making works in the OPC club, but at some point reality seemed to have sunk in, and they decided they needed to free themselves from the constant churn involved in following Microsoft's commercial product efforts. The OPC club came up with their own system, called "OPC UA" (Unified Architecture). This has two parts. One incorporates the SOAP/XML system mentioned above, but I understand they are suggesting that it not be used except in special applications. Instead they have their own binary (not ASCII text like XML) "protocol" which they are proposing be used to replace traditional OPC.
I'm calling it a "protocol" as that's what it looks like it is from the limited information that I have about it. Since the OPC Foundation is a closed club, they don't release their specs to outsiders and it's hard to say how it really works. From what little information I do have on it, it *may* be a distinct improvement over traditional OPC. However, the public information doesn't go beyond generalities, and the technical details are restricted to club members. Whether OPC UA will be as widely used as the more widespread (and technically obsolete) traditional version remains to be seen.
Here is an example for the "non-technical person": what did MS do to make sure ALL word processing programs and ALL spreadsheet programs can print on ALL printers? Answer is the Windows Print Manager, which connects all the programs to all the printers. That's the general idea. OPC allows OPC "clients" (programs) to connect and get data from a variety of devices w/o knowing the proprietary nature of the devices. OPC is the common layer that does this.
Also some of the companies have free tools to try:
Iconics (client)
Cyberlogic (OPC servers)
Softwaretoolbox (Visual Basic development for OPC)
Kepware (OPC servers)
Facebook
Google
GitHub
Linkedin
