T’is the holiday season and a time for celebration, time with friends and family.  I for one plan to spend it relaxing, eating too much turkey and imbibing goodly amounts of holiday cheer.  I won’t be doing much blogging over the holidays, so I thought I’d leave everyone with the version of ‘The Night Before Christmas’ we use around our house.

‘Twas the night before Christmas, when all through the plant
“The HMIs are frozen!!”, was the Operator’s rant;
The Engineer stared at the historian with despair;
Desperately hoping the data soon would be there.

The hardware vendors nestled all snug in their beds,
No thoughts of connectivity problems worrying their heads;
The plant manager just getting home and hangs up his cap,
Looking forward to dinner and a long winter’s nap,

When his cellphone and beeper both start to clatter,
He reluctantly answers to find out what’s the matter.
The HMI graphics are static!   The reports, they are too!
The process is still running, but there’s nothing to view!

The PLC vendor said ‘It’s not us.  The panel shows green’
The HMI vendor said ‘It’s not us.  You still got your screen’
It’s your network, your router, maybe a cord has a bend.
‘Must be in the middle, cuz everything’s good at our end.’

The Engineer got to looking for the broken link,
Checked the interface software, and started to think.
There was fault with the driver and the code proprietary
He knew in a moment, he should have used OPC.

Now who to call?  Now what to do?
Who will help us at this hour, and pull us all through?
To the Internet!  To Google! ‘OPC Support DCS’
Need to find a trusted vendor and get out this mess.

At the top of the page appeared a link to a site.
Quickly, find an OPC Server that will work just right.
A phone call, some discussion and a question or two.
‘Just download the software when the e-mail comes through.’

And then, in a twinkling, the download had completed.
OPC Support on the phone, should any help be needed.
The installation went smoothly and the Engineer feels calm.
Now just got to configure the tricky DCOM.

The Support staff was helpful, and the instructions quite clear;
The Engineer soon knew then he had nothing to fear.
The OPC Server auto-configured, and the test client worked first shot;
Just get other OPC clients connected and we’re done with the lot!

The displays — how they twinkled! The Operators how merry!
The HMI’s were working, but the Engineer was wary.
Off to the historian he went like a shot;
And found that things there, were not quite so hot.

The historian and DCS were on different LANs.
Microsoft’s DCOM had put a crimp in their plans.
Is it possible to eliminate DCOM from OPC?
There must be a way to let the data go free.

‘It can be done’ said Support ‘You need to talk to IT’
Or use OPC Tunneller.  It’s easier if you ask me.
In no time at all, everything was in place.
The Engineer saw data flowing with smile on his face.

He thanked OPC Support for all their good work,
When back to his office and grabbed the phone with a jerk,
He called the plant manger to give him the news,
Communications restored! And Interoperability much improved!

The manager gave a happy sign, and nodded his head.
He hung up the phone and got ready for bed.
But you could hear him say as he shut off his light,
“Thank You, OPC.  Let’s all have a good-night.”

Well I know that not every OPC installation goes quite like that, but hey it’s the season for believing, magic and dwelling on the good things.  Of course, with good planning, quality products and a trusted OPC vendor, you don’t need to rely on Christmas miracles. 

May your Days be Merry, your Holidays be Safe and all your OPC implementations be the stuff of Magic!

Happy Holidays to All.

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”

I was just reading over this year’s ARC/Control Top 50 list of Process Automation vendors.   Matrikon is listed on both the North American and Global categories.  I guess it’s not surprising, since the company has made the Top 50 for more than 5 years running, but it still goes to show the support the industry has for OPC.  Matrikon does a lot in the process automation industry, but a huge chunk of the business is OPC products, services and training.   In fact, the Top 50 lists read like a ‘who’s who’ of OPC supporters, many of which are MatrikonOPC interoperability partners.   I’m not saying OPC is the only reason automation companies are making millions of dollars, but I’m sure supporting standardized interoperability helps a little bit.

I was a little surprised to see that Building Automation was not considered for the rankings.   I’ve heard the statistic that ‘More than one-third of the energy consumed in the United States is used in buildings’.  If energy management is not a process that needs automation and optimization, I don’t know what is.    With the focus on ‘greener’ operation, optimized buildings systems, smart controllers etc., I say operating a large network of buildings is equivalent to running an industrial process.  I must not be the only one, since OPC is continuing to make roads into the building automation scene.  Maybe next year OPC will help building automation get on the list too.

I read a posting on a new industrial software blog with the title “OPC HDA, what a bummer!”  (Thanks for the lead Tom!)    The post was mainly a lament about Microsoft COM, and I usually try to avoid linking flamebait, however the author said he couldn’t see any reason to use OPC HDA if SQL exists.  (It might just be because their product is built on SQL, but I’ll list a few anyway)

First off, let me say that OPC HDA and SQL/ODBC are complementary.  They each have their strengths and weakness, depending on the format of your data and database structure.   Many companies make use of both for different reasons.  (It’s not surprising that one of our most popular downloads is the MatrikonOPC Server for ODBC).

A key thing to remember is OPC HDA is designed for time-series data, and typically is the interface of choice for process historians that collect and archive real time data.  SQL/ODBC is the interface of choice for relational databases, which allows for more complex relationships between the data.   Some people do choose to store real-time process data in a relational database (even Access or Excel ‘dramatic shudder’).   With a good database design, and enough processing power it will work.   We have one customer using the OPC Server for ODBC against an Oracle database with 1 million records!  (As a side note, even Oracle uses OPC).   However, in my experience most industrial automation users choose a real time historian to collect, store and present real time data.

Other than standardized access to history data, what else does OPC HDA bring to the table?   For starters the same look and feel of OPC DA, with Items, Browsing and most importantly standardized timestamp format and item quality information.   OPC HDA also provides standardized data aggregation such as data Interpolation, Time-weighted Average, Minimum, Maximum, etc.

More important than a laundry list of features (which every protocol or standard can come up with), is what the OPC HDA standard offers in terms of dealing with history.   Since OPC HDA is focused on time-series data, it can be used to create standard architectures that deal with common history based problems.  OPC HDA is so much more than the interface to a trending application.   Guaranteed data delivery mechanisms,  distributed historian designs,  rolling buffer pre-post trip capture applications and at-the-source reliability buffering during disconnect from PLC.   There are just some of the history based solutions many companies use today based on the OPC HDA specification.

Needless to say I believe OPC HDA brings a lot to the table, and that’s one of the reasons all that functionality is being rolled forward into OPC UA, with a migration path for all those that will have to still use Microsoft COM for then long while.   I’ll get off my soapbox now.

Here is a post with links to all the OPC DA 3.0 specification overview.   Thanks Dale for the link up, and the good suggestion for this post

OPC DA 3.0 Specification Overview

Part I - Introduction and Overview
Part II - General Information
Part III - OPC Server object
Part IV - OPC Group object (Overview, Item/Group management)
Part V  - OPC Group object continued (Read/Write methods)
Part VI - Client side interfaces and Installation issues.

I hope everyone gets as much from reading it, as I did from writing it.

Actually, after following ‘polyphasic’ mention in Gary Mintchell’s sleep survey, I realized how useful it is to end multi stage posts with link backs to all the preceding ones.  Live and learn.  If you can’t sleep some night, check out the posting on polyphasic sleep.  I can think of several dozen things I could get done with an extra 30-40 hours a week, even if it is in the middle of the night.  Just imagine the OPC products you could dream up.