There is a great feature in Automation World entitled “Marriage Made Where?”  about the importance of having IT and automation engineering working together.   Carl Henning called it a “must-read for anyone contemplating Industrial Ethernet” on his latest PROFIblog posting.  I’d go one step farther and say it is a must-read for anyone contemplating any OPC project.   If you consider IT and Control Engineering working together a marriage, then any OPC implementation would be their children.  Just like raising kids, if an OPC project doesn’t get acceptance, understanding and support from both ‘parents’ it’s bound to be screwed up somewhere down the line.

The article talks about the benefits of sharing information between groups, data aggregation, and collaborative interaction between engineering, corporate IT and the executive staff.   Many times, the technology layer that enables this, is OPC.   This collaboration will continue to grow with the adoption of OPC UA, which focuses even more on plant floor-to-enterprise connectivity.   So the real message here is to get the most out of your OPC connectivity, make sure you invest in the human communications too.   There is a terrific comment in the article from Eric Cosman of Dow on how ‘reaching a state of communication between the plant and executive suite is a journey, not a destination’.   Getting that level of understanding between the groups is such an important task, that there are even seminars available to help speed the ‘journey’ along. (you can catch them at the OPCUG as well)

There are a lot of good points to taken away from the paper that apply to OPC projects of any size.   Of all the OPC installations I’ve seen, the ones that are most successful and give the most payback, are those that had buy in from both the automation and IT groups.   This is particularly true when dealing with asset management  and security concerns.  

Let’s Exchange.   What’s the marriage like between your IT and controls groups? Are they Cliff and Clair Huxtable or more Al and Peg Bundy?

Greg Hale of InTech has been talking a lot about innovation this week, and it got me thinking of how this applies to open standards like OPC.   There is an argument that truly open standards do not evolve because vendors wish to maintain their proprietary edge, thus only implement the base open requirements.  Jim Pinto wrote a good article on this a couple of years ago, stating that the “The intrinsic problem is this: Vendors want proprietary differentiation, which generates higher margins.”   This may have been true, but now vendors are beginning to realize that relying on proprietary knowledge to maintain and grow market share is a short term vision.   As users attempt to balance the comfort of a single source supplier with the desire for flexibility, innovation and competitive pricing, they inevitably migrate to open solutions that give them options where they need them. 

OPC has overcome the ‘dichotomy of the open standard’ and is supported by many competing vendors.   How?  Vendors still want differentiation, so the competitive edge comes from how features beyond the base specifications are implemented in their product offerings.  There is much that specification can not dictate, and is governed by how the implementation is done.   This allows for variation among OPC products that allows leaders of innovation to create ‘best of breed’ products, while still maintaining interoperability and compliance to the standard.

When the ball really gets rolling on OPC UA, you will still see this innovation in implementation among the various products.   Although OPC UA goes farther than just the interface layer, there is still much the specifications can’t completely layout.  That’s where the innovation comes in.

With the recent airline scares, security is once on everyone’s mind.  Incidents such as the Heathrow plot renew focus on the possible vulnerabilities of critical infrastructure, such as those in the power, oil and gas, manufacturing and other industries.    One key area of concern deals with SCADA infrastructures and communication protocols, including OPC.

So the million dollar question is “How secure are our SCADA infrastructures and OPC installations?”.   The answer you get depends on who you ask.   Most company spokespeople will assure you their critical systems are secure, besides ‘control systems aren’t connected to the Internet, and are running, rare proprietary protocols’.    If you ask folks in the IT security world, the answer is more like “Danger, Will Robinson! Danger!”.   Since OPC is used extensively in the control industry, and allows open access to a myriad of proprietary protocols, it becomes a natural focus for security concerns.  

So is this all just fear mongering and scare tactics by the cyber-security industry?   Personally, I’ve been in many plants, in many industries, in many countries, and can believe a lot of what they say to be true.   On the other hand, I’ve also seen many sites that are doing things right.   With a proper security assessment, architecture and some thought to the right configuration settings, anyone can have a reasonably hardened OPC communications system.   However too many installations are content with a firewall, and default configuration settings.

Here’s my two cents.  I don’t think there is any reason for immediate panic.  Just because it’s possible, doesn’t make it probable.   Still, it’s better safe than sorry.   A few changes in policy, architecture and product choice would go along way to shoring up the defenses.

Let’s Exchange.  I’d like to hear some opinions or experiences.  I’m doing a presentation on this topic at the OPCUG, and it’s nice to have some new, interesting anecdotes.

The time is quickly approaching for the MatrikonOPC User Group conference (September 12-14, Houston, TX)  If you haven’t registered yet, I’d encourage you to do so.   The agenda is finalizing, and there are some great speakers lined up, including Jim Pinto and many other industry leaders.

If you’re a process control or discrete manufacturing professional in any industry, there’s something for you.   Some of the topics are:

• Progress in Open Standards-Based Operations & Maintenance Interoperability
• Future of Real-Time Architecture
• Working with Poor Implementation of Cyber Security
• OPC – Taking the Fear Out of Sarbanes Oxley
• Impact of OPC in the Control Industry
• Future of Technology: 3 & 10 Year Vision
• Using OPC in Discrete Manufacturing
• Achieve a High Availability SCADA System
• Combining Standards: ModBus and OPC
• Bridging BACnet and OPC for Building Automation Control
• Using OPC to Coordinate Supervisory Control of Equipment Units

There are also several workshops being offered before and after the conference;  OPC Level I & II Workshops, Executive OPC Standardization Roundtable and SCADA Security.   It’s a great chance to top up your training requirements before the year is out.

Blogs are a great way to exchange ideas, and network with those in your industry, but there is nothing quite like one on one conversation.   I’ll be doing a couple of presentations myself, and will be blogging ‘Live from Houston’.   Drop me a line, if you plan to be at the conference.  It’s always nice to know who I’m talking too out there.Come on out.  IAs Jim said in his latest newsletter – Join the Leaders.  (and we all know what humorist Lewis Grizzard said about being the lead dog)   

Speaking of leadership, Gary Mintchell’s been posting about a guy who sounds like the poster boy for ‘Top 10 Leadership Mistakes’.  I’m interested to see how this one turns out.

I’ve been busy lately working on finishing the final touches to the OPC UA – Part 11 Historical Access specification, in preparation for the next upcoming release date, so I’ve been a bit lax in keeping up with the latest RSS feeds.  Since I subscribe to all the automation blogs, process control on-line magazines and OPC feeds, there really aren’t that many to keep up on.

Gary Mintchell was lamenting our small world just recently on the Feed Forward blog, and I agree completely.  The more interesting discussions and opinions that get shared, the more innovate ideas and solutions they can produce.  I’m happy to do my part in promoting connectivity, on the plant floor and in cyberspace.  So, does a blog dedicated to OPC count as part of the Automation Blogsphere?   I think Greg Hale answered that with the statement on his InTech blog:  “At the end of the day, in this industry it is all about connectivity.”  In fact many of the folks in the ‘sphere discussed the release of OPC UA, including Gary, Greg, and of course OPC Connect.  That even goes for those who don’t necessarily agree with what OPC has to say, like Sharon at SCADA 2.0 .

Traditionally the automation industry is slow to adopt ‘cool, new technology’.  I think it is great that guys like Jim Cahill is helping to introduce the benefits of RSS and blogging to the automation masses.  BTW: Thanks Gary for mentioning the Opto 22 and ProSoft feeds, my list just grew by two.  To return the favor I’d suggest adding the Scada Security blog.   Like it or not, cybersecurity is moving from the IT world to the Process world.

As a side note: my RSS reader can’t seem to validate either the SOUND OFF, or InTech feeds.   Not sure why.   Anyone out there got these linked in to an aggregator?   These are two sites I really enjoy following and it would be nice to bring them into the fold.

If you’ve visited the OPC Foundation download page recently, you will have noticed that all the specifications are now restricted to members only.  Previously, all released specifications were available to the general public, but this was recently changed by the OPC Foundation Board of Directors.  As of May 1, 2006 downloading the OPC specifications requires either membership in the foundation, or non members are required to purchase the OPC specification.  I know the first reaction of many people will be ‘Well, that’s not very Open’  (to be honest, it was my first thought).  However there are very good reasons for this decision and it should eventually strengthen OPC as an open standard.

Being an open standard also does not necessarily mean it’s free.  Many open standards require membership in the associated standard body or charge a fee (i.e.  IEC standards, ISO specifications, DNP, etc).  Nit-picking definitions aside, the driving reason behind the new policy was to improve interoperability.  In order for the OPC Foundation to provide an acceptable level of interoperability and compliance among OPC users, they need to know who they are.

By and large, OPC products from vendors that are Foundation members are very good, since membership generally implies a level of commitment and responsibility to OPC.  However, since anyone and their dog can download the specifications, many non-compliant products are produced, and the end-users pay the price in interoperability problems.  Requiring people to register with the OPC Foundation before accessing the specifications will help in ensuring the quality of the products produced.

Eventually the companies will be able to access to the specifications in one of three ways:
1) Purchasing a membership
2) Registering with the Foundation and paying a nominal fee per specification
3) Registering with the Foundation and filling out a petition form requesting the fees be waived.

Although this new policy will undoubtedly not sit well with some, I believe it is ultimately a good thing for OPC and OPC UA.  In order to provide OPC users with a certain level of quality, robustness and interoperability, product developers need to commit to providing applications to this standard.  Becoming a member shows that commitment to quality and the greater OPC community.  

To date there has been no formal announcement on the new policy change, but the reasons are discussed on the OPC Forums.

There was a comment posted regarding my thoughts on DDE and OPC:

“I disagree DDE is not for small scale applications it has its place and should be with us for a long time. I have some huge applications that use DDE and I have never had a problem with them. Net DDE is another issue. OPC is Hard work, but does work well over networks. I get the feeling people would like to kill DDE so the OPCers of this world can have the whole market to them selves. If your DDE doesn’t work then You haven’t written it correctly.”

It seems I left the impression that DDE is bad, which I believe stems from a poor choice in words when I said DDE was only good for ‘small’ installations.   Small to some applications could be dozens of data points, it could be hundreds or even thousands in other cases.   I have seen DDE solutions that have very high point counts, and perform well.  However, since OPC is based on COM, it can handle even higher throughputs with more reliability.  Admittedly, OPC does have a steeper learning curve than DDE, so you have to put more into a solution to get out more.

The primary differentiator is how OPC and DDE behave in a networked architecture.   OPC offers much more in the way of scalability, robustness, and security.  The majority of industrial installations exist in some form of networked environment, and with increasing complexity of automation equipment, wireless access and service based applications, this trend will continue.   OPC is the better choice in these cases, (or OPC UA for enterprise type applications).  In any case, since Windows Vista does not support remote DDE connections, implementers will soon no longer have the NetDDE option.

The preference over DDE is not based on a desire to have OPC dominate the market place.  (In fact, all MatrikonOPC servers also support DDE, as do many other OPC products on the market).   System architects should always choose the right application for the right solution.   However, if someone is implementing a communications architecture today, more often than not I’d recommend OPC over DDE.  This is not because DDE performs poorly, rather OPC performs better, offers more flexibility, and has a longer supportability horizon.   Also, even if the application is local, chances are someone will want to make a remote connection to it some time in the future.

I do agree whole heartily with the last comment about the application only working as well as it was written.  Any protocol or standard is only as good as the product implementation, but that is a topic for another day.

Just a reminder that the OPC Foundation, and supporting sponsors are hosting a free, one day technical training seminar, in the Chicago area on August 23, 2006.

This is the third of four such training seminars, and is a good overall introduction to OPC and includes a special session on the new OPC Unified Architecture technology.   There is no cost for the seminar but registration is required. If you are and end-users, system integrators, or involved in automation projects, and are new to OPC this is a good way to get immersed in the basics.   It’s also a good way to see many OPC vendors and products under one roof.   If you can’t get to this one, there will be another chance in the Boston area in November.