It’s hard to believe we are almost into June already, and it looks like summer is finally making it to Edmonton, here in the Great White North.   Just in case anyone’s been living under a rock, I’ll give another reminder of the OPC UA DevCon 2007 in Scottsdale, AZ for June 25-28, 2007.

If you’re not yet registered, there is still time, so get on it.   Previous years event’s where geared more to getting out the message of OPC UA, and what is aims to achieve.   Now that most Parts of the OPC UA specification have been released, and key code deliverables are out there, this year’s event will have even more meat to it.

I’m really looking forward to this year’s event, and hope to get to meet some of you in person.  Not only are these events important for communicating and gathering input on the future direction of OPC architecture and product development, they are great networking opportunities to meet with other users and OPC vendors.   Imagine hundreds of people talking, sharing and discussing OPC. Add in a very nice conference location, nice weather and some beer, and you got one of my top 10 places to be.

The second part of the OPC Security Whitepaper from written by Byres Security, Digital Bond and BCIT has been available for download for the last couple of days.   Since this part talks about vulnerabilities in host systems and architecture, common configuration issues, and possible risk scenarios; OPC Exposed is most provocative of the three parts.    I’m actually a bit surprised there hasn’t been any “Run-For-Your-Life-Chicken-Little-The-Sky-Is-Falling” type press on this.   Not that it should, but the paper goes into more detail than OPC Security Whitepaper Part I, and even that generated some ‘ruffled feathers’

The report go into detail of the various situations, but the main thing that sticks out is a lot of the so-call OPC vulnerabilities are really the result of poor end-user configuration of their computers, not problems with OPC.   That in itself is a problem, but one that can be remedied by good communication and knowledge sharing.   The main conclusions are highlighted in the paper’s abstract namely:

• Attacking OPC deployments does not require special skills or esoteric process controls knowledge.
• The two core vulnerabilities, namely excessively open firewalls and overly permissive DCOM access rights, lay at the heart of many scenarios. If either vulnerability is addressed then the chance of these scenarios occurring is significantly reduced.
• The security of most OPC systems would be greatly enhanced if vendors improved the quality of configuration guidance to include recommended security settings and provided easy to use hardening scripts to automatically enable more reasonable security setting after installation.

Again this is a well written, and presents a nicely balanced message on securing OPC systems. The paper sticks to the facts, without any drama or finger pointing.  Actually the only time it mentions any vendors is to point out examples of those with good practices that make securing OPC easier.  (Hint:  one of the company names rhymes with ‘My Truck Run’)

These reports reinforce two key concepts;  any control system or SCADA application, including OPC, needs to take into account security.   And if the system end user does not have this knowledge, experience or time to obtain it, then they need to be talking with an experienced, committed vendor who does.

As I’ve said before, I think these whitepapers will go a long way to providing users with guidelines for improving the overall security of their networks and OPC architectures.  Anything that improves the overall adoption, usability and security of an open standard like OPC as a good thing.

The OPC Foundation, and supporting sponsors will by in Philly in July for the fourth of six OPC Technical sessions.

This OPC Seminar is scheduled for July 12, 2007 in Philadelphia, PA. The seminar will start with registration and continental breakfast at 8:00 AM and the program will begin at 8:30 AM. The seminar will cover all aspects of OPC Technology from OPC Servers to OPC Clients to OPC Best Practices. The seminar will be held at the Renaissance Philadelphia Hotel Airport located at 500 Stevens Drive.

As always, the seminar is free,  but registration is required.  Sign up early, since these things have been popular and space is limited.  Great introduction for end-users, system integrators, or anyone involved in automation projects who are new to OPC.   The seminars are informative and a chance to see many OPC vendors and products all in one swell foop.  (And what a swell foop it will be.)

A lot of OPC talk in the Automation blogs this week.  Reminders to get registered for the upcoming OPC UA DevCon 2007, the OPC security article continues to circulate and Walt Boyes (and friends) had several mentions of OPC on Matrikon Summit 2007 postings.

One post in particular that caught my attention was his recap of Sean Leonard’s presentation on OPC.  The topic of the presentation was the “Business Case for OPC”, and as always Sean had a lot of great things to say.  He sums it all up with the following key points:

“The future of OPC is going to be much bigger and go much farther than we can imagine,”

• The driving forces for the future
• The enterprise requires more data, more timely.
• A single vendor will not rule the world. You will have systems from different vendors working together.
• System communications failures will occur
• Process information will remain critical
• There will be a focus on security.

“This is a harsh competitive environment. Business leadership is challenging. Agility requires timely data. Which requires interoperability, which requires standards, and OPC is the only choice.”

At the end of his post, Walt added a couple of questions he didn’t get to ask at the talk: There are significant and well known security issues with OPC. Perhaps it is fair to say there are serious exploitable security holes in current OPC implementations. How are they going to be resolved?  

At the end of his post, Walt added a couple of questions he didn’t get to ask at the talk: The security issues reported in the news lately are not vulnerabilities with the OPC specifications, but rather with product implementation.  How they will be really rests with who performs the implementations, the End-users and Vendors.  The buck has to stop with them.   I’d view it in the same light as safety.  Who’s fault is it, when a guy gets tossed through his front windshield because he didn’t do up his seat belt?  Manufactures add bells and whistles to remind you to fasten the belts.  Governing bodies introduce laws to enforce compliance.  Safety groups campaign on the benefits of using them.  Ultimately it is promoting awareness and communicating what needs to be done to the guy sitting behind the wheel.

You could argue that the really serious ‘exploitable security hole’ is users are turning off their OPC security!  This will be only be resolved by vendors and users working together to communicate the right architectures.  Bells and whistles can be added to make security easier to use, for example OPC UA has security as an integral part of the design.  Governing bodies are and will continue to introduce laws that will affect software security in the automation industry.  But it still needs to be the vendors that change things and communicate how to configure systems.

The spotlight continues to shine on security, and things are happening; The OPC Security Whitepapers are a good step in the right direction (Part II is due out soon),  there is increasing security focus from OPC vendors and the OPC UA specification includes Security.  The changing world has prompted end users to begin demanding security, and committed vendors will listen.

The North American OPC Interoperability (IOP) event is on this week in Deerfield Beach, Florida.  I couldn’t make it down this year, but two of the MatrikonOPC guru’s will be running a bunch of products through the paces.  Included is the MatrikonOPC Universal Server (which is the framework server all the MatrikonOPC servers are built on), the Desktop Historian, OPC Tunneller, Redundancy Broker, OPC Server for Triconex and the Data Manager.  The boys will be busy since many of the products are both clients and servers.

Of course, the purpose of the workshop is to make sure that OPC products work together. The plan is to validate interoperability for all required interfaces and functions, as well as validate interoperability for any optional interface.  End users have the confidence that Vendor products which have attended IOP events have validated typical functionality, albeit in a controlled environment.  Where Compliance testing tests the ‘letter’ of the specification, Interoperability testing deals with variances in implementation and functional testing.

The next stage is ensuring that OPC products perform well in a production environment.  The third party independent test labs will give end users a way to compare system level test results across multiple vendors.  An apples-to-apples type comparison.

In addition to these formal testing phases, really serious OPC vendors take their product validation one step further by cooperating with each other, so that they can say without a doubt that “All features of my product works in a full production environment with Vendor X’s system”.  For example, MatrikonOPC has partnered with the likes of ABB, Honeywell, Emerson.   The QA Staging area is literally jammed with DCS systems!   Each company is in lock step with development and testing.   The OPC Foundation must, and does, provide the infrastructure and certification process for interoperability, but guaranteeing ongoing compatibility is ultimately the vendor’s responsibility.

The OPC Foundation has just released it’s latest issue of it’s OPConnect newsletter.   As always, some good case studies from the OPC vendors.  (including a condensed version of one of my whitepapers “If These Walls Could Talk”.  This concludes the Shameless Self Promotion segment of this posting.)

Tom has some good points in his message this month on OPC UA, including:

• One of the important strategies for OPC UA is leveraging the existing installed base of the legacy OPC products.
• But don’t stop buying products based on the existing OPC specifications, such as Data Access (DA), Historical Data Access (HDA) and others, just because OPC UA is on the way.
• The OPC Foundation is collaborating with the information model consortiums to facilitate the widespread adoption of the respective information model technology using OPC UA as the transport.
• The first OPC Foundation third-party labs are planned to be deployed starting on July 1, 2007.
• Plan to have OPC UA client and server certification tools available to the vendors as part of the initial rollout of OPC UA components and deliverables. 

This article contains a lot of positive, forward looking statements about OPC UA, because even though the majority of the OPC UA specifications have been released, there is still work to be done before OPC UA products really get ‘out there’.    I’ve been getting a lot of questions lately like ‘When will you have OPC UA products for sale?’ or ‘It’s been almost a year since the specifications were announced, where is OPC UA today?”.   The answers are basically, not for many months yet, and things are progressing very well, but there is still stuff to get done.

I think it’s important for people to appreciate the scale of what OPC UA is designed to accomplish, the importance of getting it right, and the staged milestones that are part of rolling out the specification.   These milestones really just begin with releasing the specification documents.   The sample code and supporting OPC UA components need to be completed and tested, the specifications need to be validated by code and implementation testing, and the compliance and certification infrastructure needs to be in place.   In addition, to help ensure a widespread adoption communication of what OPC UA entails, and collaboration with other consortiums needs to be facilitated.    All these activities have been, and still are, been ongoing and progressing steadily.   Producing the next generation in industrial enterprise connectivity takes time, patience and a whole lot of effort from a lot of people.   Realistically, I would say we are probably about another year away from being able to call up a vendor and purchase OPC UA Product XYZ off their site.

However, with each milestone, users will begin to see concrete results.   Already OPC members have access to the initial OPC UA SDK.  (OPCconnect.com recently implemented a handy RSS Feed to keep up to date on new downloadables).    Vendor companies that belong to the Early Adopter Program are busily working on the OPC UA components, and integrating them into their product offerings, and announcements like the recent EDDL/FDT agreement shows things are still gaining momentum.    Much has been accomplished, but there is still more to be done.  But as they say, Rome was not built in a day.