What Is Classic OPC?

If we’re going to talk about Classic OPC (That’s the one currently installed all over the place) we have to start with the definition of a Client and a Server. That’s a pretty easy place to start as everyone as one or more servers that they connect to every day of their life. A Server is just that, a device that serves up data to some Client device. Usually there are multiple Clients for every Server. In fact, you could have hundreds of Clients for a Server.

In the OPC world, the “device driver” portion of a Client Server connection is the Server. That’s the software component that has the knowledge of how to ask a particular device for its data. It knows the commands, protocols and data formats and how to use them to send and receive data from that device.

The Client software component is the user application that wants that data or wants to send a data value to the device without knowing much at all about the internals or operation of that device. In this world, databases, excel spreadsheets, HMIs and other applications are Client software applications that want to access data in one or more field devices through an OPC Server.

If we use the concepts of Clients and Services, it is really easy to define what OPC really is. OPC is a structured way for these Client software applications to access field devices through OPC Servers. Since, OPC Servers are the only ones that understand the structure and content of the field devices, OPC Clients only have to know how to talk to an OPC Server to get whatever data they need.

So, how does this happen?

Classic OPC Clients and Servers use Microsoft communications technologies COM (Component Object Model) and DCOM (Distributed COM). COM and DCOM are the plumbing inside Microsoft Windows that allows programs to send commands and data to each other. COM is used for programs that reside in the same computer while DCOM is used to exchange messages with systems located on a network.

A Client like and Excel spreadsheet, HMI or other application that needs data from a factory floor device sends messages over COM to an OPC Server. That Server contains two components. A component that offers services that can be accessed over COM and another component that knows how to get data from some factory floor device.

Getting data from the factory floor device is completely hidden from the Client. That mechanism can use any number of different physical media, transport layers and protocols. It can be as simple as receiving an ASCII string over an RS232 connection or as complex as reading and writing the data tables of a Siemens S7 PLC.

Providing that interface for the Client to get that data from the Server is the real genius and beauty of Classic OPC. The creators of OPC standardized the way that Clients could access the Server. They provided a mechanism which Clients could use to browse the data available in a Server, organize it in a way that meets the needs of the Client application and transfer data when and how it was needed.

For this and many other reasons Classic OPC is an unqualified success. Thousands of OPC servers have been deployed tens of thousands of times savings untold number of hours that would have been wasted developing proprietary data transfer solutions