Nick’s latest posting over at ProSoft came across a blog entry on OPC in comparison to other Ethernet protocols, like Modbus.  Nick asked what I’d have to say, so I gotta say something, now don’t I?  Actually the article is rather fair, and makes some good points, but of course the discussion favors Modbus.  As I’ve said before,  OPC and Modbus are complementary protocols, and each has it’s merits in different installations.

I would like to add a few comments to the list of ‘limitations’ discussed about OPC.   Here’s the excerpt from the posting:

In comparison, OPC DA is a much more sophisticated protocol by design.  It incorporates many of the capabilities missing in the open Ethernet protocols:

• OPC supports the data discovery by tag browsing capability.

• Data quality and time stamps can be available as an attribute of the value.

Although there may be some who will argue with me, my experience is that the COM architecture (that OPC is built upon) is proven and sufficient for real-time data communications.  However, when applied to real-time, plan-floor network communications between different vendors, OPC DA runs into big limitations such as:

• The performance and stability of communications is many times dependent upon the characteristics and design of the OPC Server.  The OPC Client application almost needs to be tuned or designed for the characteristics of the OPC server that it is addressing.

• OPC is too big and difficult to implement for embedded systems.  Because it is built upon Microsoft technology, it is not easily ported to other operating systems.

• The configuration of DCOM between networked nodes is tricky and easily broken.  OS service packs can undo DCOM settings breaking the communication links.

• Because data sources are implemented as Servers, passing data between two data sources requires a middleware of some type of two-headed client.  Often these applications add another layer of complexity and unreliability.

• Redundant OPC applications require proprietary components and implementation.  I have yet to hear of a successful out-of the-box redundant OPC application.

Here’s my two cents on some of the points:

• On the point about performance being dependant on the OPC Client and Server design, I’d argue this is true for ANY software communications.  Modbus Master/Slaves are just as susceptible to this sort of thing.  Protocols are only as good as the implementation, for example a Master polling a Slave faster than it can handle requests can cause problem.

• Yes, OPC/Microsoft COM is big for an embedded system, and Microsoft centric.  There are OPC products for Windows CE, Embedded XP, etc.

• DCOM is tricky.  Got to agree on that, and DCOM can cause a lot of frustration to OPC users the first times around.  However with proper understanding and configuration this gets easier.   Also you can get the benefits of OPC, with the networking of TCP  by using OPC Tunnelling.

• Same is true for Modbus.   A Master is needed to pass data between two Slaves.

• Again same is true for Modbus.   Since Redundancy is not part of the specifications, then redundancy handling must be designed into the products, or applications that handle redundancy are required in the architecture.

As to successful out-of-the box redundant OPC solutions, here’s a small sampling:

Agrium Integrated Plant Wide Open Communication
Santee Cooper Automates Processes
OPC Redundancy in Critical Plant Application
OPC Redundancy for Nuclear Power Plant
Enbridge Energy Achieves Robust Redundancy
OPC in safe Burner Management System

(The Santee Cooper example is actually using an OPC Server for Modbus as part of their architecture.)

Having been a part of both projects, I know that Herman and Lee did have some difficult times.   As was mentioned, these gentlemen are early adopters of new technology driving their organizations.   Early adopters often have projects or applications that push the limits of technology and software.  Sometimes this is limitations of the specification, but usually it’s the growing pains of the specific applications.  I’ve rehashed Lyondell’s challenges before, and    without getting too deep into project details, Shell had similar experiences.  The project involved many thousands of points, combined OPC DA and OPC Alarms and Events interfaces, with multiple levels of redundancy and high speed data requirements.  Multiple vendors, Stratus hardware issues, and work flow problems made the situation even more fun. 

Their reluctance to fully embrace OPC for large scale, mission critical applications is understandable, given their experiences.  Lessons were learned, and had those same projects been implemented today (as many others have), it most likely would have been a much different experience for both.  I’d also have to say, that knowing the background on some of the issues faced, a Modbus implementation would have not been a cake walk either, and some of the project requirements may not even have been possible to meet.

There will always be a place for different protocols, and it will be a long time before there is one to truly rule them all.  (Maybe OPC UA?).  From my seat, the automation industry has had many successes and is still moving forward with OPC.  It is also looking forward to OPC UA to see what solutions it may bring.