Back to Documents List

What is OPC ?
Colin Winchester, Director of Support Services, Software Toolbox Inc.

What is OPC?
Have you even heard of this acronym? OPC stands for OLE for Process Control.  That's right the "O" itself is an acronym of an acronym. Yes, but what does all this mean, you're still asking yourself? First lets start with the "O" of OLE. OLE refers to Object Linking and Embedding (OLE). It's one of Microsoft invented labels. The term refers to how different programs can share each other's capabilities while presenting the user with a single interface. Why they didn't just call this object sharing is anyone's guess. One example of this object sharing or OLE is an Excel spreadsheet in a Word document. Microsoft wasn't the only company doing this with spreadsheets and word processors, but once they got started there was no stopping them. Now you can link and embed almost any object in almost any Microsoft product. This is because Microsoft had to standardize their methods so they could be compatible not only with their own products but with other vendors products as well. Much to Microsoft's chagrin other companies could also use these standards. OLE is now an accepted standard so products from different vendors can now share information as long as no one breaks the rules. This all led to good news for the rest of us. Software products that have different capabilities can be used together to meet your specific needs. 

OPC is the automation industry's version of OLE. Why do we need a different standard if OLE is already a standard you may be asking? The important reason is because OLE couldn't do all the things needed for data communication in a process control environment. The unimportant reasons most likely include politics and the basic human desire to be different. Even so, the OPC specification is specific to the automation industry and its' unique needs for data communication. Not only is data passed from one program to another like in OLE, you can also control the rates for the requested data. You can also identify if the data being received is accurate and get the time it was received. According to John Weber of Software Toolbox Inc., "The OPC specification has been developed over the last 2 years by a team starting with a 150 charter companies and represents a shining example of how industry organizations can be effective."  The OPC Foundation, an independent organization, is responsible for the specification. The Foundation is supported by fees paid on an equitable basis by its' members, now over 220 companies. For more information about the OPC Foundation visit their web site at www.OPCFoundation.org.

The goal of the OPC specification is "to provide an open, flexible, plug-and-play software standard for software interoperability in the automation industry."  The specification intends to addresses the specific needs of the automation industry such as data access (i.e. drivers), alarming, historical data access and trending, batch, and more. The Specs are founded upon the Microsoft Component Object Model (COM) that specifies how programs connect and access each other. Hold on, first you say this is OLE based and now you're saying it's COM based? It works like this, OLE is what is being done and COM is how it is done. We want our programs to be able to share and exchange information and COM is the method we use to do it. OPC software uses COM methods to communicate its' information to other OPC software. While the COM methods are the foundation more specific guidelines are needed to obtain the performance needed in Process Control situations. So why isn't it call CPC? Some questions are better not asked. You may be thinking, this sounds like the old DDE (Dynamic Data Exchange) server model that has been around since the late eighties.  When DDE was invented, COM and the whole 32 bit world didn't exist.   Unlike DDE and its' variations, the OPC specifications allow low-level connectivity. This means the data access and transfer times are much faster. The OPC specification also sets standards for the kind of information required for the industry, unlike DDE.

By standardizing the interfaces between industry software, all client programs meeting the OPC specification can work with all servers meeting the OPC specifications. This is another advantage over some variations of DDE that are proprietary. Outside of these interfaces each product can try to meet users need in whatever way seems best. The long-term benefits for the user of OPC will come from the ability to pick best-of-breed application modules such as drivers, trending, alarming, graphics, etc. from various sources and bring them together with common interfaces.  Because all products meeting the specification are interchangeable, the user can choose which products meet their needs best without being locked into a single proprietary product. While a user can choose to use brand X's driver, HMI, and database, they can also choose to use brand Y's diver, brand X's HMI and brand Z's database if this meets their needs better. If need be a user can also write a specialized program meeting the OPC specification and interface with other OPC programs as well. 

When using OPC compliant programs it is important to understand the client to server relationship.  A client is a program that requests information and a server is a program that provides information the client requests. A program can be a client to some servers and a server to some clients. For example, your graphics environment could function as an OPC client, getting its' data from an OPC data server connected to your PLCs.  The trending package you choose could function as an OPC client to the graphics package to get it's data, which also happens to be an OPC server!  Or it could go direct to the OPC data server.

What about ActiveX controls? Can't you use them to connect to PLCs and other programs? Yes you can! An ActiveX (once called OCX or VBX) often is all someone needs in a particular application . When writing specialized programs requiring no connectivity to other products this can often be the best solution. On the other hand, if you need the advantages of Plug and Play connectivity, OPC products may better meet your needs. So as you begin looking at new manufacturing software packages, whether they are HMI or others, find out if they are OPC and ActiveX compliant.  If they are, you'll be able to shop Software Toolbox and find all the OPC and ActiveX tools that you need in one place. To learn more, visit our website as we'll be adding more technical articles there as OPC becomes more and more popular.

Questions about this article ? You can send Colin Winchester an email at cwinchester@softwaretoolbox.com

Back to Documents List