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.