Straight Talk about What is OPC ? This document is a work in progress that Software Toolbox is providing to our clients and the industry because we find that we are still answering many questions for our clients about OPC that remain unanswered despite the massive number of articles and papers on OPC created by the drafters of the specification and the industry. Our attempt here is to explain OPC in Plain English with a series of Questions and Answers. We also have available a paper authored by Colin Winchester, our Director of Support Services, on the subject of "What is OPC" - Colin's style of writing is often appealing to users and he enjoys writing to aid our users in learning more about technologies - click to read his paper We welcome your input and feedback. Email us your questions and we'll build them into this straight talk tutorial about OLE for Process Control. Here are some common questions we are asked and the answers. What is OPC ? OPC is a specification or set of written rules and procedures for the way multiple software programs ("applications") can talk to each other.  The OPC specification was created by users and software developers in the manufacturing/process control industry to serve the needs of the manufacturing automation/process control industry specifically.  The specification is managed by volunteer effort and administered by the independent OPC Foundation. OPC came about because application software developers and users saw the need to begin to standardize how their applications worked together to reduce integration and total life cycle costs for software used in the manufacturing automation/process control industry. Before OPC, each software application vendor provided their own custom ways to connect 3rd party applications into theirs. So to connect vendor application "A" to vendor application "B", you had usually have an expert C++ programmer who could quickly come up to speed and become an expert on the custom programming interfaces for both application "A" and application "B".   Furthermore, users usually had to purchase a toolkit from each of the two application vendors at a cost of several thousand dollars each, long before they even cut the first check to the programmer who was to integrate the two. With the OPC initiative, developers in the manufacturing automation/process control industry began to adopt the specification and build "doors" into their applications that met the OPC specfications, so that if Application A and Application B were both written to the same OPC specification, they could connect with a mere fraction of the integration time and cost and without custom code. Is OPC a standardized language for communicating to my plant hardware ? No, though in at least one perspective OPC can be perceived as such and it would be an accurate perception. When you have a software program that you want to get data from the plant floor in to you have a piece of software that sits between your application and the hardware that is often called a "driver".  Think of a driver as a translator - it reads data from the hardware using the functions and commands and wiring necessary to talk to the process control hardware and then hands it to your software application using methods, formats, and a language your software program can understand. So the "driver" software has to speak two languages or "protocols", one to your software, one to the hardware.  The OPC specification takes care of standardizing the means of speaking between your software application and the driver software. "Driver" software that follows the OPC specifications for providing data to other software applications are usually known as "OPC Servers". This term is used because they "serve up data" to the software applications that need it.  The reason there are so many different OPC Server "drivers" on the market is because the multitudes of hardware suppliers each speak a different "language" on their communications interfaces To the degree that we accept that once a piece of hardware has an OPC Server driver connected to it the interface to software applications that need the data is standardized, then yes, OPC does provide a standard means for connecting your applications to your plant hardware. Are OPC servers communications drivers ? Yes they are - they are translators between your process control hardware's language and your application that needs the data. There are other types of drivers such as DDE servers and ActiveX controls, but they do not provide the combination of performance plus standardization of interface in the same package that drivers written as OPC Servers provide. What's the difference between an OPC client and an OPC server - what are they ? An OPC Client is a software application that needs the data from the process control systems and is able to speak the "language" defined by the OPC specifications in order to be able to get the data from an OPC Server. The OPC server is the "driver" software that talks to your specific hardware and reads/writes data and "serves it up" to the OPC client application. How do I know if my software application is an OPC client ? First of all ASK the people who developed your application.  Perhaps you need a specific version in order to make your application into an OPC client.  If your application developer or vendor doesn't know what OPC is, send them to this page to learn more and then to the OPC Foundation website at http://www.opcfoundation.org My software application is not an OPC client ? How do I make it one ? First of all if you licensed the application from someone else, check with the application vendor - they may have an upgrade or accessory software application that adds OPC Client capabilities to the package. If you developed the application yourself, you have some work to do.  If you're a highly proficient C++ programmer then you can go get the OPC Specification from the OPC Foundation and read it over, look at their sample code, and dive into programming. We would caution you though that you need to have a solid understanding of COM, DCOM, and ATL programming if you take that route. The other route you could take is to license a toolkit that will help to speed your application development.  Toolkits are available for Visual C++ and Visual Basic so you can choose the language that works best for your application. The OPC Data ActiveX control is essentially a toolkit for adding OPC client functionality to your Visual Basic Applications. Visual C++ toolkits are available from SoftwareToolbox.com Why should I make my custom application into an OPC client ? Because if you do, the next time you ask someone "can I connect my software to that hardware ?" the only question you really need an answer to is "Is there an OPC Server software driver available for your hardware?" If the answer is yes, and the OPC Server author has followed the OPC Specifications, then you are done. You don't have to write any custom drivers, or change anything. By making your software application an OPC Client you are giving your application universal connectivity. If you used to have to be in the driver writing business, you can get out of that business and partner with companies who focus on writing OPC Servers and live or die by the quality of their drivers. You can focus on your application development and business needs instead of worrying about custom drivers. What if my hardware vendor says they don't have an OPC server driver ? First, you as their customer may need to explain to them why it is important to you.  Second, check places like SoftwareToolbox.com for and OPC server driver for your hardware - often times the hardware vendors are not totally aware that a company who lives and dies by writing OPC Server software has already written one for their hardware.   If still no luck and the hardware vendor and you don't have software development resources, you can hire someone to create an OPC Server for your application hardware.   New drivers can be expensive compared to buying an off-the-shelf driver that already has thousands of copies in circulation, but with the right number of licenses of software involved and arrangements, you might be surprised at what can be done when compared to investing your precious engineering time. The other alternative if you do have the development resources is to write your own OPC server. Like toolkits for OPC clients, there are toolkits to help your developers write OPC servers available. What's the difference between and OPC server and an ActiveX control ? OPC Servers and ActiveX controls are both based on the Microsoft Component Object Model.  ActiveX controls are typically user interface components and are also typically intended to be embedded inside of another application. You can't take and ActiveX control and just runt it like some EXE application.  OPC Servers are specialized applications, usually EXE standalone applications, designed to get data from the plant floor and serve it to other applications.  A Visual Basic (VB) application using our OPC Data ActiveX control is an example of a case where you're using the best of both worlds - the ActiveX because it snaps in nicely with VB, and the OPC server application because it is highly optimized for doing communications to the plant floor hardware and serving data to multiple applications that need it. When should I use and ActiveX and when should I use an OPC server for communications hardware - what are the pro's and cons of each ? Keeping in mind the solution above, sometimes you should use both. There are ActiveX controls available that drop into VB (we offer several) that do communications also. However there are some key tradeoffs that you make. If you use an OPC Server, the OPC Server will handle optimizing the communications protocol packets and tags for you.  Furthermore with an OPC server you get the option of having a tag database in the OPC server itself thus eliminating the need for you to build a tag database into your application. You map to the tags and if that tag ever needs to be tied to a different physical hardware address, you can change that without touching your VB application. Also, since OPC servers are separate applications, they can share the same data read once from the PLC or other hardware with mulitple applications at the same time. Lastly, another advantage of OPC is investment protection - since OPC is an accepted standard for connecting drivers to software, you can change your VB app out for another application anytime and keep the same driver - before OPC you couldn't do that.  On the downside, you pay a per machine license for OPC servers (keep in mind the OPC Data ActiveX offers a runtime free license for connecting VB to the OPC server).  If one considers total life cycle cost of a project you likely will find you will still come out ahead using a VB to OPC solution. To be sure though, using an ActiveX to talk to your PLC as it's advantages. The first is cost. Most PLC communications ActiveX controls are sold on a runtime free basis.  The downside is the PLC communications ActiveX control goes inside of VB, other applications can't use it at the same time, you are responsible for building your own tag database, and you are responsible for optimizing your own read/writes. The upside to that is that you have ultimate flexibility and choice to tweak the application the way you want.  However, if what you are after is a quick application time to market, then you are in for more work with an pure PLC communications ActiveX solution than if you used the OPC Data ActiveX connecting to an OPC server. What is the difference between an OPC server and a DDE server ? Most simply, it's a technology issue for one thing.  DDE was the first desktop PC technology that let multiple applications talk. It is vintage 1986 technology from Windows 2.0 (yes there was such a thing as Windows 2.0 running on a 286 PC - our founders were using it back then). Having said that, DDE was limited to one tag at a time and 50 concurrent connections, period.  Along came FastDDE, which let you pass blocks of data and made FastDDE a viable contender for many years, championed by it's visionary creator, Wonderware. Rockwell Software, not to be out done, came up with AdvanceDDE to address the same issues with a different approach. Neither FastDDE or AdvanceDDE have been in the public domain - you can gain access to them through purchasing toolkits but the specifications arent' something you can publically download like the OPC specifications. OPC is based on current Microsoft COM/DCOM technologies and does not suffer from the performance and scalability issues that DDE suffers from still today. OPC software interfaces are clearly defined by a public standards body, the OPC Foundation, with over 270 companies using the methodology. OPC was developed by automation developers for automation developers and users and thus is highly tailored to the needs of this industry, whereas DDE is a general purpose technology that at the time could be used for this industry but left unaddressed many of the automation industry's needs unless you used semi-proprietary variants. I have an application that isn't a communication's driver but it claims to be an OPC server - what's the deal with that ? Any software application that wants to provide data to other applications can be an OPC server and use the standard OPC interfaces to present the data to other software programs, regardless of the root source of the data. For example, many HMI applications expose their tag databases via OPC now -- you could use the OPC Data ActiveX to connect to the HMI application ( we tested this at OPC Interop 2001) and read data from the HMI into your Visual Basic program and combine it with data from other sources. Some other topics we are planning to address here include: What are COM and DCOM in simple terms ? What does it mean to "browse for OPC servers" and to "browse an OPC Server ?" What's the difference between a Synchronous and Asynchronous Read or Write ? Isn't Ethernet a standard protocol ? If all my hardware is on Ethernet why do I even need an OPC server ? Email us your questions and we'll try to answer them here also.