The National Institute of Standards and Technology (NIST) recently issued an initial list of standards and other elements needed to support an interoperable smart grid. The NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0, concentrates on standards that will help achieve interoperability among devices and systems. OPC Unified Architecture (UA) is one of the few non-industry specific standards to make the list.

The whole process of choosing which standard makes the cut requires a lot of effort to ensure that those chosen meet the industry specific needs and have sufficient vendor support to encourage a market of compatible products. In order to coordinate work within the SmartGrid community to work towards the achieving interoperability, NIST has coordinated the formation of Domain Expert Working Groups (DEWGs). The DEWG members are subject matter experts representing from utilities, vendors, academia, industry, standards groups, and federal agencies. The working group most relevant to OPC UA is the Industry-to-Grid (I2G) collaboration. As on OPC UA vendor, MatrikonOPC is an active part of the I2G Working group.

I’ll be attending the upcoming ARC forum in Orlando, where Keith Stouffer, the co-chair of the I2G Working group will be presenting on topics related to SmartGrid initiatives. If you’re going to be at the conference and looking to learn more on OPC applications to the SmartGrid or on the I2G working group, let me know. Hope to see you there.

If not you can always read more on it on our OPC and the SmartGrid page.

The results are in for the 2010 Control Readers’ Choice Awards. This annual survey of brand preference among suppliers of process automation technologies, represent the collective opinion of more than 1,000 process automation professionals. Those surveyed include the print magazine’s U.S.-centric readership as well as subscribers to their increasingly international digital media outlets anchored at their website ControlGlobal.com.  Here’s the most interesting section of the article. IMHO.

“Closely complementing our Readers Choice Awards across the range of essential process automation disciplines are the Readers Choice Awards for specific software competencies.”

”New to the Readers Choice Awards this year is the category of OPC Connectivity Software. Matrikon took top honors in the category”

This is a double pleasure in that, OPC was recognized as an essential process automation discipline, and the validation of MatrikonOPC’s commitment to reliable, secure OPC connectivity. Thanks to all those that voted to show their support.

If you want to try out any of those ‘top choice’ OPC products, you can find them here.

I’ve been very remiss of late on getting blog posts up.  That will be my number one resolution for the coming year.  To make up for the lack of posts recently, I thought I’d do a recap of some of the noteworthy OPC happenings of 2009. This year saw a lot of activity from the OPC Foundation, particularly in regards to OPC adoption.

Early in the year saw OPC UA meet a major international standardization milestone when the Committee Drafts of Parts 1-6 & 8 of IEC 62541 (the international version of the OPC Unified Architecture specifications) were approved.  Shortly afterwards was the Final Release of Unified Architecture Phase I Deliverables.  New released versions of Parts 1-8 of the OPC UA specifications, along with matching UA SDK and sample code was made available for members to download.  This, along with additional SDK updates through the year and the launch of the OPC Foundation Blog for Developers and creation of the Accelerated Adoption Working group helped paved the way for many new OPC UA products. 

Autumn 2009 saw several other OPC UA initiatives such as the release of the OPC UA For Devices Companion and Analyser Devices Companion Releases, as well as the OPC UA For IEC 61131-3 Companion Specification  release candidate from the PLCopen/OPC Foundation Joint Working Group (PLC). Several OPC vendors now offer OPC UA support, either as an OPC UA wrapper or native OPC UA support like the MatrikonOPC Universal Connectivity Server (UCS).

OPC adoption also got a boost from the announcement that the OPC Express Interface (Xi) was added to the OPC Foundation technology portfolio, complementing OPC UA and COM-based OPC Classic. OPC Xi’s primary objective is to provide a .NET-based migration path from OPC Classic. Additionally, OPC Xi may be used as a standard .NET WCF interface for newly developed OPC servers.  Expect to see more products supporting OPC Xi in the coming year. 

All in all, an very good year for OPC.

Although 2009 was a tough year for many companies MatrikonOPC had its share of good OPC news.   Major advancements on the core OPC Framework technology lead to had several product milestone achievements including reaching OPC Foundation Gold Level Independent Certification, achieving Wurldtech Achilles Certification and most recently enrollment in the Honeywell PKS Advantage program.  These framework advancements along with the OPC UA implementations culminate in our newest product offering the MatrikonOPC Universal Connectivity Server (UCS).   There will be much more to talk about on UCS as 2010 unfolds.

Technology investments were not the only growth this year.  MatrikonOPC expanded its reach opening regional offices in Brisbane and the United Kingdom.  This global presence allows MatrikonOPC to offer ‘round the clock’ OPC support, which plays a major role in the offerings provided by the Partnership programs such as the MatrikonOPC Integrator Program (MIP) and the MatrikonOPC Vendor Partner program.  Clearly customers recognize the value in our commitment to OPC, since the year also as had exciting business news.  These included the Shell’s global standardization on MatrikonOPC connectivity and the collaborative agreement with Siemens Industry, plus many others joining the Partner programs.

With the horizon looking brighter from an economic point of view, it bodes well for an even more exciting 2010 for OPC. 

P.S.  Don’t forget to check out the newly updated OPC Tutorial video.

Happy Halloween to all the ghouls and goblins out there.  Halloween is really a time of excitement, expectations and a little uncertainty.  What’s in the treat bag? Candy or Apples?  Who’s that behind the mask?  It’s that combined factor of anticipation and unknown that makes Halloween fun.  The same can be said for new interfaces. The recent news about the .NET based Express Interface (Xi) and the inclusion of Xi as part of the OPC Foundation portfolio is bound to raise feelings of hopeful anticipation about new connectivity options and probably some questions as to how everything will fit together.

P.S.  As a Halloween treat there are a few more questions added to the Ask The Experts pages. 

�

What is an Engineer’s favorite software tool? It has got to be Excel.  When I worked as a Project Engineer I had spreadsheets for everything!  Reports, graphs, data manipulation, text parsing. I’ve even had a flight simulator.  Excel is a great tool for analyzing and manipulating data, so it’s no surprise that there are OPC based products that help get data into Excel.

What I learned the hard way, is what Excel is not great at… storing data.  It was manageable when I was only producing information for myself. I had a set naming format for the filenames, sheets and columns, so I could keep track of what data was coming from where, and from what time frame.  But once I had to start sharing the data out to other members of the project team, managers or end client reports things went down hill fast. Data getting changed in one version but not the other, ‘multiple versions of the truth’, missing or renamed files, and other fun problems.  

Of course the right answer is to separate the data from the information.  Use Excel as the reporting and analysis tool, and store the data in a correct repository, like a historian.  Which is why the release of the MatrikonOPC Micro Historian is such great news.  Light-weight, simple to use and cheap. No wonder it’s called ‘a historian for the rest of us’ J.  Of course you get data in and out of it using OPC, with full support for both OPC DA and HDA, otherwise I won’t be talking about it.

So for all those engineer’s out there with their data files in an ‘Excel of a Mess’, give the datasheet a look.

And before anyone comments, of course the answer to what is an Engineer’s favorite tool would be duct tape.

As Gary said in a recent post on tradeshow tips, this the event and conference season.  That means I’ll be on the road again spreading the OPC message.  This year I’ll be attending Emerson Exchange, ISA Expo and Rockwell’s Automation Fair.  Other MatrikonOPC folks will be showing up at Invensys OpsManage as well as globe trotting to tradeshow events in China, Indonesia and the Honeywell HUG in Portugal.  OPC’s reach is global!

At Emerson Exchange I will be presenting on managing risk when implementing OPC projects.  I have speaking slots Wednesday at 9:00 and Thursday at 10:00.  If you’re at the event, I’d encourage you to drop by, and if you can’t you can read all about it in the whitepaper Look before You Leap: Implementing Successful OPC Projects.

ISA Expo has always been a popular event for the OPC Foundation and its members, and this year is no different. I will be parked in Booth# 1335 with a few of the other MatrikonOPC folks.  Drop on by for a conversation or three on OPC.

Hope to see you all there.

Hackers.  That’s the headline for this recent article on possible vulnerabilities in the data communications to off-shore oil platforms.  It cites the fairly recent case of an IT contractor who was charged with sabotaging offshore oil rig computer systems. “Prosecutors say the contractor hacked into a shore-to-rig communications network that, among other functions, detected oil leaks.”  There are many, many offshore data communication systems out there that use OPC as a key part of their architecture.

Folks might be tempted to call articles like this sensationalism or fear mongering, but industrial professionals know the truth is all too real.  Too many systems still rely on security-by-obscurity or their firewall as their sole line of defense.

“Although the newest oil rigs, which cost upward of $1 billion apiece, might be loaded with cutting-edge robotics technology, the software that controls a rig’s basic functions is anything but. Most rely on the decades-old supervisory control and data acquisition (SCADA) software, written in an era when the “open source” tag was more important than security, said Jeff Vail, a former counterterrorism and intelligence analyst with the U.S. Interior Department. “It’s underappreciated how vulnerable some of these systems are,” he said. “It is possible, if you really understood them, to cause catastrophic damage by causing safety systems to fail.”  

Although the safety of these systems is paramount, another important factor to consider is the economic impacts and lost production costs if these communication systems are compromised.  There are many things that can be done to make these systems more secure.  This article Securing Integrated Scada Systems against cyber attacks mentions some of them:  Network design, firewalls, Intrusion detection, and encrypted networks.  So what can be done for OPC communications in particular?  First is a good OPC network design.  The whitepaper Creating Secure OPC Architectures walks through some secure configuration options.  Of course using OPC security aware products such as OPC Tunneller and the OPC Security Gateway brings huge security benefits to the communication layer.

Are your OPC communicates secure? If you’re not sure, maybe a network assessment is in order. I’m sure there is a trusted OPC vendor you can call to arrange one J

The ever popular free OPC tool, the MatrikonOPC Explorer now has support of the OPC Alarms and Events specification.  Being able to test connections to OPC A&E servers from the familiar OPC Explorer tool has been something that people have been wanting for some time now, and it’s finally here.  You can download the MatrikonOPC A&E Explorer here.

There is support for all the expected OPC A&E client functionality:  Simple, Conditional and Tracking filtering, Severity and Category filtering as well as update throttling.  This is all in addition to all the other features that OPC Explorer already offers such as interface checking, support for OPC Security, launching server configurations, and all the other good stuff.

Now all those people out there using the MatrikonOPC Alarms and Events Server for Real Time Data, can monitor the generated OPC A&E Events, and the underlying OPC DA Server with the same tool J

I’ve been away on vacation for the last few weeks, and will be on the road again for the next few weeks.  In the meantime a few more questions have been added to the “Ask The Experts” section.

Speaking of questions, I had a query from Gary Mintchell regarding comments he’s heard about how OPC UA should be ‘simple’ like DA. (Look for some upcoming OPC discussions from Gary at Automation World).

I’d thought I’d share some of my thoughts on the topic, since I’ve come across this more than once myself.

The first thing is what your perspective is on the matter. There is a difference between being “simple to use like DA” and “simple to develop like DA”. 

The end-user experience of starting an OPC UA client application, discovering the list of available servers, connecting to the OPC UA server, browsing for available points and subscribing to value updates does not change very much from what we do today with classic OPC.  What does change is that this process now has more built in security, reliability and integration of other data models like history, alarms and conditions and programs.  Also the infrastructure is no longer tightly dependant on Microsoft operating systems and the challenges of DCOM.  Of course these additions mean that OPC UA product developers now have some more work to do.

To put it in everyday concepts: The mechanics of driving an ’82 Dodge K Car, and a 2009 Electric Tesla Roadster are the same, but how they are designed, manufactured, maintained and work under the hood is VERY different.  The same applies to OPC DA and OPC UA.

With OPC DA, a C++ programmer with a good understanding of COM could download the 200 page OPC DA 3.0 specification and basically start coding.  A bit of a simplification, but that one document bounded what the programmer had to implement.  A programmer sitting down to develop an OPC UA server opens a layered set of specifications broken into thirteen Parts. These documents are purposely described in abstract terms and in later parts are married to existing technology on which software can be built. They also have to consider options such as programming language implementation, security, information model etc.  (Not saying that’s a good or bad thing, just stating some facts.)  For many people, their first reaction is ‘this is complex’. The discussion on ‘how simple or complex’ OPC UA is really a reflection on the difference in scope between OPC DA and OPC UA.

The classic OPC specifications were COM implementations therefore the constraints of COM dictated many implementation details, including target operating system, discovery mechanism, wire protocol, security etc. 10 years ago, developers were mostly concerned with solving the interoperability problem, so accepted these constraints in order to achieve an acceptable standard.  As the OPC Foundation website states “The existing OPC COM based specifications have served the OPC Community well over the past 10 years, but as technology moves on so must our interoperability standards.” 

Users and developers now require more, several factors influenced the decision to create a new architecture:

• Microsoft has deemphasized COM in favor of cross-platform capable Web Services and SOA (Service Oriented Architecture)
• OPC Vendors want a single set of services to expose the OPC data models (DA, A&E, HDA …)
• OPC Vendors want to implement OPC on non-Microsoft systems, including embedded devices

Let’s look at each of these factors, and what impact that has on the scope of OPC UA.

Choosing Microsoft COM as the basis for classic OPC meant that many decisions were already made for the developer, but this also brought with it all the configuration pains of DCOM, close reliance on Microsoft platforms and limited ‘web’ application integration.  Selecting a Service-based model for OPC UA provides cross-platform functionality, and removes the reliance on any one vendor or technology.  In ten years from now, when the protocols used by Microsoft, IBM or Linux change (and they will), then the OPC UA applications will not need to be re-written, only the underlying mappings need be changed.  This abstraction adds scope to OPC UA that OPC DA did not have, but on the other hand by not being bound to any particular technology means that the OPC UA specifications will be timeless.

OPC UA stands for ‘Unified Architecture’, which encompasses all the classic OPC specifications: DA, HDA, A&E, Commands and Complex Data.  So comparing OPC UA to OPC DA is a bit of apples to oranges.  The base OPC UA specifications contain the common components to integrate all these features.  Again this is a larger scope than OPC DA and developers need to understand what things included in the base and what things are Access Type specific.  That said, not every OPC UA server will be required to implement all 13 Parts.  OPC UA provides multiple ‘Profiles’ that allow developers to choose the right level of functionality for their application, yet still ensure that the base level of interoperability exists will all OPC UA products. 

OPC UA has been designed to be cross-platform and scalable from embedded devices all the way to Enterprise spanning applications.  Offering this level of flexibility while at the same time guaranteeing a usable degree of interoperability means developers must make some decisions on target programming language (C, .NET, Java) and communication stack (Binary, TCP, XML)  their OPC UA products will support.  In classic OPC, COM dictated these things, but with OPC UA developers have more choices. The OPC Foundation provides multiple SDK, communication stacks and sample code to accelerate adoption, but some vendors may choose to implement these lower layers on their own.

All these factors put together means the since OPC UA offers all the functionality of the classic OPC specifications and new features plus removes many existing constraints, that the structure and depth of material to absorb in learning OPC UA is harder than the OPC COM specifications. Or as some people say “OPC UA is not as simple as DA”.

The focus of the OPC UA Working Group over the last few years has been to ensure that specification and supporting deliverables met all the criteria discussed above, while ensuring certifiable interoperability and backwards compatibility and providing increased reliability and security.  Producing a ‘simple OPC UA quick start guide for the new developer’ was not a main priority.  Now that the specifications are nearing final completion, the Early Adopter team validates that things work as expected when the ‘paper become code’, and OPC UA vendors are developing their own products, the priorities are changing. 

The next phase of OPC UA is ensuring that developers have what they need to successfully implement and adopt OPC UA. There is a large segment of the OPC community saying “As a first step we want to just provide our existing OPC functionality on the OPC UA infrastructure.  What do I need to know to do that?”   It’s not really a matter of ‘changing’ the OPC UA specifications to ‘make it simpler’, rather it’s presenting the specifications, documentation and code deliverables in a form that meets this important first step use case. 

That is the focus of the newly formed “Accelerated Adoption Working Group”.  This group is working to create the documentation, OPC UA Profiles and jump start code kits that allow product developers to quickly understand what aspects of OPC UA are required to duplicate their existing classic OPC functionality.  These implementations will still have all the core components needed for interoperability and for added extended functionality in the future.

Under the hood OPC UA is still a powerful ‘Swiss Army Knife’, but if all you want to do is cut something with the big blade, here are the steps you need to follow. You don’t need to know how the cork screw works or where it is.  However if you want to use it in the future, you don’t need to build a new knife, the functionality is there waiting to be opened.

My $0.02

Those interested in learning more of OPC UA should check out “OPC UA: 5 Things Everyone Needs To Know”

Based on the feedback I get both on and off-line, the audience of the blog really consists of two main groups of OPC users.  Those that know OPC and are interested in how others are using OPC in their systems and keeping abreast of what’s happeing with OPC and OPC UA.  The other large segment are those new to OPC and looking for general information or an answer to a specific question.  To better address the needs of the latter group, we’ve added a new resource section to the blog “Ask The Experts”

Here’s the list of the first ten questions, and others will be added over the next little while.

1. What do the letters “O-P-C” stand for?
2. What is OPC?
3. What is OPC UA?
4. Because OPC is a standard, does that imply that all OPC Servers for a specific protocol are the same?
5. What size is a typical OPC tag structure byte?
6. Where do OPC timestamps they come from?
7. What is the difference between OPC and DCOM?
8. What is the “6 Minute DCOM Timeout”?
9. How does OPC compare to DDE?
10. Can I use OPC or DDE on Windows Vista?

As always if you have any OPC questions, drop me a comment or an e-mail.