OPC shows signs of fragmentation

May 17, 2009
OPC has been one of the great success stories of the automation industry over the past 15 years, demonstrating that vendors and users can come together and reach agreement on issues of mutual benefit.

OPC has been one of the great success stories of the automation industry over the past 15 years, demonstrating that, despite evidence to the contrary ranging from the fieldbus wars to the recent spat over FDT and EDDL, vendors and users can come together and reach agreement on issues of mutual benefit and, on occasion, do so with commendable speed. Initiated at the height of the fieldbus wars, OPC — at that time standing for OLE (Object Linking and Embedding) for Process Control — moved from the establishment of a task force in May 1995 to a draft specification in December of the same year and the issue of a final specification in August 1996 — 16 months from start to finish compared with the fieldbus saga’s 15 years from start to bodged compromise.  

Beyond process

Since then not only has COM/DCOM gone the way of all Microsoft-based flesh, but OPC’s application has spread well beyond the process industries, with the result that it has become one of those acronyms that has outlived its origins and now stands for, well, OPC. In the intervening 14 years, the single specification has developed into a whole family which includes, in addition to the original, subsequently known as OPC Data Access, OPC Alarms & Events, OPC Batch, OPC Data eXchange, OPC Historical Data Access, OPC Security and OPC XML-DA.  

Inevitably, and despite its huge success, the one major weakness both practically and conceptually is that it is and always has been based on Microsoft technology. That’s fine so long as you only wish to communicate between Windows based systems, but it becomes a significant problem with non-Windows systems which, of course, includes most of the embedded systems encountered in industrial automation.  

That problem has now been addressed with the development of the OPC Unified Architecture (OPC UA), which replaces COM/DCOM with an open and independent communications stack and thus allows for multiple platform implementations, as well as providing scalability from embedded microcontrollers right up to mainframes. At the same time the OPC Foundation has taken the opportunity to tidy up and rationalize its growing family of OPC specifications and bring the whole together under the OPC UA umbrella.  

Transatlantic whispers

All of which sounds and indeed is entirely laudable. However, and here one again hears echoes of the fieldbus saga, such an all-embracing ambition contains within it, if not the seeds of its own destruction, at least of disagreement between partners in what has hitherto been an unusually harmonious enterprise. Sure enough, we now hear whispers from across the Atlantic of just such disagreement — some have even used the more emotive term “schism”  — focussing on whether it is necessary or even desirable to implement the full OPC UA specification.  

That argument specifically focuses on the .Net implementation of OPC UA, which only uses the lower part of the all-embracing ANSI C stack, implementing the remainder natively in .Net. The result is better performance as a consequence of eliminating a stage in the “de-serialization” process, but at a price, that of being restricted once more to a Microsoft-based world. That, say those advocating such an approach, hardly matters since the real world of industrial automation is still largely Microsoft-based anyway.  

One of the vendors in the OPC.NET camp is rumored to be Emerson. If true, that would more than a little ironic since Emerson adopted precisely the opposite position a few years back when it argued in favour of the universality of the text based EDDL and against the operating system-dependent FDT/DTM.  

Pragmatism

In truth, this appears to be a classic case of pragmatism versus purism, but it has the potential to fragment what had until now been a more genuinely standard ‘standard’ than most. True, full interoperability between different vendors’ systems depended on the quality of their individual OPC implementations, and certain vendors, notably Honeywell, had their own to some extent proprietary versions, but there is no doubt that OPC has been a huge boon to vendors, integrators and users alike. The possibility that that the user community could now be faced with not one, but as many as four flavors of OPC — original plain vanilla OPC DA, OPC.NET, full blown OPC UA and, of course, HOPC — should give everyone pause. Those with long enough memories should recall what happened to UNIX.