One of key strengths of OPC is it’s simplicity.   Each specification is designed to target the interface between two different systems.  The specifications do not delve into the behavior of the underlying systems, or boundary case situations.   No standard, general purpose specification really can, without aligning to a particular use case.  That’s not to say that all OPC products or architectures are simple.  In fact, it’s this simplicity that allows for the development of robust applications, products or architectures that solve very complex problems, while maintaining the interoperability of the standard specifications.  Unfortunately the term OPC gets applied to the complete interfacing structure, including the specification, the particular products, the full architecture (regardless of complexity), Microsoft DCOM and other implementation issues.  

All too often, when someone has a bad experience with an OPC product, a vendor, or a project implementation, it is OPC as a whole that is assigned the blame.  This is understandable,  since the bottom line is usually that time and money were lost and OPC was involved.  The details of where things went wrong are usually not all that relevant at the time.  However, when this leads to OPC not being used or considered in future opportunities, then ultimately everybody loses. 

Next post, I’ll share an all too true life example of this.