For the last little while my postings have been pretty detailed, even though from a specification point of view the commentary was quite high level.    I think demonstrates the point I was trying to make, that the specifications ARE very low level and detailed.  The decision on whether or not to use OPC does not lie in the specifications, rather its best found in case studies, user experience and training courses conducted by those who know, use and develop OPC

After reviewing the overview posts one question I don’t think I answered is one I get asked a lot. Is OPC really plug and play?  Well, in terms of interoperability, I’d say yes OPC is almost there.   What does the term ‘plug and play’ mean?  Generally, it means when you install a component, it slides in with other pieces of the architecture seamlessly, without the need for a lot of configuration.   With the increased focus on interoperability, OPC Certification, Interoperability events and vendor commitment OPC is getting closer to true plug-and-play.  That is if you connect a trusted OPC client to an OPC server from a reputable OPC vendor, you would not expect to have any interoperability issues. 

However, does any technology mean you no longer need to consider connectivity issues or architecture design?   Can any specification cover all the features users want?  Back in the days of Yore, before the Microsoft-oply and Proprietary Dinosaurs roamed the industrial automation landscape, getting applications from different vendors to communicate was a significant problem.  An old adage I’ve heard repeatedly that I must agree with is ‘Connectivity issues get 1% of the budget and are 99% of the headaches’.    Sometimes I think that even with the wide spread adoption of OPC, that adage hasn’t really changed much.   Although OPC solves the issues of proprietary interfacing, many system implementers think ‘We don’t need to spend time or money on system integration, we’ll just use OPC’.  Yes, OPC solves the question of which interface to use and does reduce implementation time and costs.   But what about the issues associated with functionality, through put, guaranteed data delivery, network interoperability, communication disruption and recovery, maintainability and the countless other considerations associated with system connectivity?  

I think a much better saying to live by is ‘Plan and Play’.  Regardless of what technology you are using, you need to be working with a trusted vendor who understands your requirements and has the products and services to meet your needs.   OPC has done amazing things with leveling the playing field for system interoperability.  However, no protocol, technology or product can remove the planning and understanding needed in creating industrial strength connections between different systems.  So use OPC plug-and-play technology from a vendor you trust, and plan your implementation and get out and play.