We’re coming onto the end of 2007, marking about a year and half since the release of the first OPC UA specifications.  More and more people ask me ‘Is this OPC UA stuff vaporware or what?’.  It’s an understandable question since you hear a lot about OPC UA, but don’t see any products yet.  You can see how implementers are wondering, ‘Should I implement the OPC I know today or wait for OPC UA?’    Those are tough questions, and when faced with a tough question I usually resort to a higher authority.  My Magic 8-Ball.

Seriously though, the answers really depend on; what is your situation, what you are looking for from OPC UA and what is your realistic timeframe.   First, let’s take a quick look at the ‘OPC UA State of the Union’.  I’ve written on this before, but here’s a quick rundown.   The base specifications are out and many will have a maintenance update very shortly.  The remaining Implementation Parts are nearing completion and will be released soon.   The basic framework and OPC DA implementations of the OPC UA Microsoft .NET implementation code work is complete, with the other specification proxies and the ANSI C and Java implementations nearing completion.    Work on the Certification Profiles and Independent Testing Facilities continues to move steadily forward.  So, a lot of work is complete and everyone is working hard on hitting the remaining milestones.   What that all adds up to is a bunch of mixed messages from the OPC vendors.  Those that are road mapping their long term OPC UA implementation paint a glowing picture of what currently is and will be their OPC UA offerings.  Those whose business model embraces a specific feature set of OPC UA reflects the current phase of that specific implementation.  And those who focus on the immediate advantages of the current OPC specifications have a more cautionary outlook.  As confusing as it is, they are all valid viewpoints.

OPC UA encompasses a huge undertaking of offering standardized data connectivity, that not only unifies the existing OPC functional offerings, but is also cross-platform, reaches farther into enterprise interoperability, and adds increased standardization for security, redundancy and robustness.  No wonder people want it to turn down the sheets, feed the dog and balance their checkbooks too!    The best answer is ‘OPC UA is farther along than vaporware, but will not be available as commercially available, officially certified product next week’.

Will independently tested and officially certified OPC UA products will not be available within the next quarter?  My Magic 8-ball says “Don’t Count On It”.  Will OPC UA products will be available within a realistic timeframe to consider adopting it?   The all knowing Magic 8-ball says “Signs Point to Yes”.   

The million dollar question is when?  6 months? 1 year? 2-3 years? More?   (Too bad the Magic 8-ball can’t tell us that one).   The answer lies in how fast the OPC volunteers complete their work, how fast vendors adopt the technology and how much pressure end users exert for particular feature sets.   As wide as the OPC UA blanket covers, the feature set users are looking for boil down to three broad categories:

1) Those that use OPC today and want better integration of the various OPC specifications (The United part of the OPC UA name)

2) Those that use OPC today, and want a standardized method of by passing Microsoft DCOM.  (a by-product of using web service based technology that offers standardization, even if existing products solve the DCOM problem today)

3) Those that want the advantages of standardized interoperability but are deployed on non-Windows platforms.

Additionally, a subset that spans all three categories is those that want increased standardization in data collection aspects such as security, reliability and redundancy.  The reality of OPC UA is that each of these aspects will hit milestones at different times as the specifications and associated code bases mature.  

Since the Magic 8-Ball answers can be a bit unreliable at time, I’ll offer you my thoughts on the matter:

a) If you are deciding on OPC or a proprietary interface, choose OPC.   OPC offers standardization today and the migration path to fully certified OPC UA products is well defined.

b) Should I choose OPC for connectivity?   Yes.   The reasons for choosing OPC have not changed for the last 10 years.   Choosing OPC today is just as valid as choosing OPC UA now, tomorrow or the next day.  They are invariably linked in terms of functionality, and the migration path is targeted towards the multitudes of thousands of current OPC users that exist today.

c) If you are deciding between a home-grown web service interface or OPC UA, then choose OPC UA.  The work to finalize/correct your OPC UA implementation verses modifying whatever you implemented in order to meet or cover all that OPC UA offers will be invariably be lessened.

d) If you currently are working in a non-Microsoft platform, then why would NOT embrace the cross platform technology like OPC UA that fully meets your needs?

e) OPC UA might take some time to be embraced by all industries, but how much longer will it take for any alternative technology you are considering that does not have the install base, vendor support or product promise of OPC?

Like it or not the OPC we all know and love (or not) is here to stay for the foreseeable future.   Equally true is that OPC UA is the future of OPC.   It has the backing of many committed OPC vendors, who have achieved some measurable milestones and are working hard on completing the rest.   Ultimately, if you have questions on how and when OPC UA best fits into your plans, you need to talk to a trusted OPC vendor about your requirements.   They can probably give you better direction on implementing an OPC solution or road mapping your future connectivity than the Magic 8-Ball can. “You May Rely On It”