OPC Shortcomings

I was recently involved in a project in which we linked the Operator Interface stations at two pipeline terminals together using OPC over a
corporate WAN to facilitate consolidated operations of the facilities. During the course of the project we ran into several problems which from my perspective I believe highlight fundamental problems in the implementation of OPC on industry standard Windows operating systems, which are not particular to the vendor of the systems which we utilized, which I will detail below. I am interesting in hearing from anyone who has made similar observations and the solutions that they arrived at, and from anyone who has product based solutions that address these issues both from an implementation or diagnostic perspective.
Having carried out a number of SCADA projects over the past twenty+ years of my career in the control & automation field, and having written a number of serial communication drivers in "the old days" before the widespread adoption of Ethernet and the Winsock API I have an expectation as to the level of diagnostic capability that a user should expect in an industrial communication system. During the course of working through the problems that we encountered on this project and spending considerable time consulting with the vendor and researching OPC, DCOM and the Winsock interface my impression is that there is an almost complete disconnect between the application sitting on top of the OPC / Windows OS based "system" and the low level communications resources from a communication control & diagnostic perspective. Once a call has been made to the Winsock API the details of what happens below in the OS and communication system is nearly totally abstracted.
One of the results of this is that there is almost no information returned to the application (in our case operator interface) by the API, hence the diagnostic information presented to the operator interface application is extremely limited. Third party tools must be used to observe what is going on within the communication system, (stack counters / diagnostic status flags / Ethernet packets), and from a diagnostic perspective there is no ability to link a specific communication request from the application to communication events occurring within the communications sub-system.
A second result to the disconnect between the application and the communications system is the inability to exercise any control over the communication system. The Winsock API offers no real access to do this. Good from the perspective of ease of implementation, however inadequate from the perspective of providing control over the communications system used for industrial control. In order to access the limited control that is available in the Windows OS the user is forced to access the system registry using yet again another "disconnected" tool.
I believe that OPC is a great concept and believe that it has a lot to offer, however I believe that in order to get it to the point that it offers the integrity and diagnostics that industrial users are accustomed to the shortcomings of the communications resources provided by the "off the shelf" Windows OS have to be addressed.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Hi, Greg. Part of the reasoning behind this "abstraction" is the "plug-and-play" mentality that (pushed by Micro$oft) everyone has become used to - nobody *wants* to know exactly what is going on behind the scenes, they just want it to work!
There are a host of tools out there to debug problems with OPC systems (like those from www.matrikon.com), but you are correct - most of these don't give you the really low-level access you could get with an RS232 port monitor or the like.
The biggest issue with Ethernet is that I'm not convinced that knowing what's going on behind the scenes will help much - Ethernet (TCP/IP flavour, anyway) is horribly inefficient (the packet sizes are enormous) and to sort through that lot trying to find a missing data byte and where it went missing would take forever! Comms has changed a lot in the past decade or so...
Cameron:-)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hello,
Not disputing the difficulties of debugging higher level comms, I'd like to point out something below:

These things are completely different layers of comms. The difficulty to debug a DCOM problem has nothing to do with the difficulty to debug a MAC layer of Ethernet. If, instead of Ethernet, you use RS232 and run SLIP or PPP over it, it won't help you a bit to find a problem hidden in the application layer (OPC, DCOM).

The difficulty to debug Ethernet has nothing to do with its inefficiency, that, in turn, depends on the ratio between the header sizes (MAC+IP+TCP, for example) and the trasmitted data size. There are tools for analysing Ethernet and TCP/IP problems. These tools range from handheld devices to computer programs, some of which are free (tcpdump and ethereal spring to mind). Ethereal can parse Ethernet traffic into Modbus frames, for instance.

That's for sure :)
Andrey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.