Came across this article on open standards not long ago.  “Is our idea of “Open Standards” good enough? Verifiable vendor-neutrality”   Can’t remember how I stumbled upon it, maybe a link from Gary or Jim?  Either way, since it’s all about open standards, of course it got me thinking about how OPC measures up.

According to his bio, the author is a proponent for open standards, and the opening statement backs that up.

“Open standards are clearly a good thing. Hurrah for open standards, etc. Nail my hat to the ceiling!
But anyone who has been involved in community and consortium committees where there are commercial rivalries engaged knows that the thing that kills or corrupts a standard is when the spirit of mutual accommodation is overtaken by the spirit of competition”

I’ve been involved with many of the OPC specifications working groups, including OPC UA, and I can honestly say that the spirit of mutual accommodation is alive and well with OPC.  I think one of the main reasons for this, is from the beginning the charter members were focused on solving the problem of interoperability, not trying to push any one proprietary standard to the for front.  Too often ‘open standards’ evolve from competing solutions vying for the lion share of adoption.  OPC really doesn’t have any direct competitor.  I’d argue (and have before) that other protocols that may have overlap in some areas are complementary not competitors.

The main thrust of the article is that those that drive open standards need to meet his definition of verifiably vendor-neutral.

“Vendor-neutral here means that the standard does not discriminate against any realistic players, either by making basic implementation too hard or by disallowing vendor-specific features or innovations or experiments, where appropriate.”

Again OPC as a standard does a good job of this. Although the ‘classic’ OPC specifications didn’t specifically provide ways to extend the standard interfaces, they didn’t do anything to preclude this either. That’s the main reason users can get products that add functionality such as redundancy, tunneling or calculations without sacrificing standardization.  OPC UA does go one step further and actually provides methods for extending the specs or providing vendor specific information.  (I’ve blogged on that as well).

Of course a goal on any OPC vendor is to provide universal connectivity to a wide range of systems.  Therefore it is in their best interests to be vendor neutral, and have good working relationships with all the major players.   Seems to be working for OPC.

The article that got me thinking on this stuff is on an O’Reilly site, which got me thinking about when is there going to be an ‘OPC in A Nutshell’ from O’Reilly?  (Yes, I am easily distracted).   Of course, the biggest challenge is coming up with what animal to put on the cover.   It’s all about connectivity, so I’d say a Spider, but I think that one’s taken.  Anyone?  Maybe a Peruvian Boomslang?

During one of the presentations at DevCon 2007, Jim Luth mentioned the significance of the Server Object as part of the Information Model.  One of the things people have been wanting in the current OPC offerings is a standard way to get status, diagnostic, capability and configuration information for a given server.  This is a key requirement when putting together an enterprise wide monitoring or management strategy for your OPC architecture.   OPC UA addresses this using the standard, yet extensible, ServerType object.

I’ve posted before on the OPC UA Information model, and said that it is expected that every OPC UA server will expose at least one ServerType object in the address space.  If you want the nitty, gritty details they are all found in OPC UA – Part 5 Information Model  (or better yet join the Early Adopter Program and help implement some of this stuff ).  For everyone else, here’s the 10,000 ft view on things.  So what sort of stuff does this thing tell you about a server?  Let’s ask some questions and find out.

Where do I find things?  The ServerType object has properties that tell a server where it can get to from here.

List of Other UA Servers: One of the design intentions of OPC UA was to support chaining and federation of OPC UA servers in the enterprise, so one of the things the ServerType object has is a list of other OPC UA servers it is aware of.

Namespace Table: Each OPC UA server has it’s own namespace that is used as part of the NodeIds in a server.  The ServerType object provides a convenient index mapping to the longer name URIs.

How am I feeling?   The server usually knows the most about it’s backend connections.  The OPC UA client goes to the ServerType object to get that sort of information.

Service Level: This property is also used to support OPC UA server federation and reliability.  There will be cases in a given system where an OPC UA client may be able to access the same data from two different servers or paths (i.e. in a redundant server configuration).  The Service Level is a number between 0-255, that indicates the relative ‘health’ or ‘ability to serve data’ of a server. 255 would mean everything is A-OK.  A Service Level of 0 would indicate the OPC UA server is disconnected from it’s back end data source.   A number somewhere in between might be used to indicate periods of network slow down, servers in a timeout or reconnect mode or some other questionable state.

Status Information:  The standard start time, current time, version information and the familiar Running / Failed / No Configuration / Shutdown / etc  states are here as well.

Diagnostics: This is actually another whole object type, which in turn nests other objects.  It would contains a vast amount of diagnostic statistics such as numbers of views, sessions, timeouts, sampling and publishing rates and rejects due to security constraints.  It also has additional information on a per session, per subscription and per sampling rate granularity.

What can I do?  Ever wonder what a particular OPC server can do?

Server Capabilities:  This is another object type that contains specifics on what a particular server supports.  Rather than just checking to see if interfaces exist, OPC UA clients can now find out which specific OPC UA Profiles a server supports.  The base Server Capabilities object also has information on support node types, local information and minimum sample rates.  Clients would also start at this object to find additional capabilities objects such as Historical capability or vendor defined information .

Redundancy: The OPC UA specification defines the way clients and servers handle redundancy.  Redundancy can be a many headed beast dealing with client vs. server redundancy, transparent vs. non-transparent failover and Hot, Warm or Cold fail over scenarios.  The Server Capabilities object is where the details are found on what a server supports.

What did I do?   Almost as important as what a server can do, is what it did do.  In today’s world of Sarbanes-Oxley type legislation, process audit trails are becoming an necessity.  

Audit Events: The ServerType object also has information on what Audit events a server supports.  This contains data such as who did what when in terms of configuration, security or data updates.

In addition to providing standardized access to a wealth of knowledge about a server, the ServerType object is also a great example of how UA allows extending the standard ObjectTypes by adding additional components (with some restrictions in order to maintain interoperability of course).  I’m looking forward to seeing what types of powerful client applications will be developed to leverage these features of the OPC UA Information Model.  Aren’t you?

When someone says “I’m using OPC”, invariably they mean they are using OPC DA 2.05.  It’s far and away the front runner of existing OPC installations.  There are quite a few architectures using OPC HDA and A&E, far fewer using Batch, XML DA or DX.  Somewhat of a mixed bag, would be those using OPC DA 3.00, which was released in early 2003.  Most major OPC vendors have since upgraded their products to support OPC DA 3.00, but how many out there are using the new features?  A better question is what ARE the ‘new’ features.  In fact that topic recently surfaced again recently on the OPC Forum.  If you read the introduction of the OPC DA 3.00 specification, you see the main changes were:

• Added new interfaces  (IOPCBrowse, IOPCItemDeadbandMgt, IOPCItemSamplingMgt, IOPCItemIO, IOPCSyncIO2, IOPCAsyncIO3, IOPCGroupStateMgt2)
• Clarified startup issues and add WAITING_FOR_INITIAL_DATA quality status mask.
• Added Item Property #7, #8 for EUTYPE
• Clarify SetActiveState to indicate that an item transition from inactive to active will ultimately result in a quality change, triggering a callback.
• Add new server status enumeration (OPC_STATUS_COMM_FAULT)
• Removed Legacy Interfaces from this version of the specification (IOPCServerPublicGroups, IOPCBrowseServerAddressSpace, IOPCPublicGroupStateMgt, IOPCAsyncIO, IOPCItemProperties)
• Added Item Properties section
• Clarify RemoveGroup
• Added CATIDs to idl
• Provided the ability to read and write the quality and timestamp
• KeepAlive mechanism was added to confirm the callback connection health

Fine and dandy.  What exactly does that mean to the end user in terms of functionality?  Let’s paraphrase things, shall we?

New Browsing:  v3.00 replaced the way server browsing was performed, and was very similar to the way XML DA provided browsing.  First key item is browsing is no longer optional.  A server must return something when a client browses.  From the perspective of the user,  browsing behaves much as it did before.  The new interface greatly simplified the recursive work OPC clients sometime had to do when using the now deprecated IOPCBrowseServerAddressSpace.  It also streamlined how Item properties were accessed, as well as provided better handling for very large address spaces.   This same thinking has been carried over into the OPC UA specifications.

Better Deadband Handling:  Deadband was handled as a percentage of span of an OPC Group.  The deadband can be still be set on the at the group level, but DA 3.0, also allows the deadband to be on a per item basis. This means that each item can potentially override the deadband set for the group it resides within.

Single Item Data Access:  In OPC DA 2.05 the only way to read/write data was for an item to first be added to a group.  An interface was added so that it would be function as if a group was created, items added, a single read or write was performed and the group deleted.  

Writing VQT:  Interfaces were added/enhanced to allow for a DA write to set the value, quality and timestamp.  The DA 2.05 interface only allowed for the value to be set on a write.  Before the release of DA 3.0 people would use OPC HDA to do this.  In DA 3.0 the WriteVQT functionality applies to single item access, synchronous and asynchronous interfaces.

Maximum Age of Data:  Interfaces were added/enhanced to allow passing of an array of “staleness” for each item. The server calculates, for each requested item, the number of milliseconds between “now” and the timestamp on each item. For each item that has not been updated within the last MaxAge milliseconds, then data must be obtained from the underlying device.  This functionality applies to single item access, synchronous and asynchronous reads and refreshes.

Item Sampling:   An optional interface was added that allowed the client to manipulate the rate at which individual items within a group are obtained from the underlying device. It did not affect the group update rate of the data change callbacks.  This is sort of a poor man’s buffering solution.  In a nutshell, an server could scan data at a rate faster than the group update rate, so on an update multiple values could be returned for a single item.  This is useful for protocols like DNP 3.0 where a device could send multiple values in a single scan, which a DA 2.05 client would miss, even on an extremely fast update, but a DA 3.0 client would catch.

KeepAlive Message:  Added a specific KeepAlive message so clients could tell a server was still around even if no data was updating. 

Removed Public Groups:  Not practical. Not necessary. Not used. Not around anymore.

…and a bunch of clarifications to clear up some of the grey areas of the specification.

So, all and all some good stuff.  Conscientious vendors upgraded their servers to support DA 3.0, and clients were updated as the functionality was needed for particular applications.  The good news is it all got rolled into OPC UA as well.   It won’t be too long before you start seeing those too.

One of the hot topics at DevCon last week was security and OPC architectures.  Everyone is interested in the security features that OPC UA offers, such as being ‘firewall friendly’, functionalities for confidentiality, integrity and application authentication and leveraging other standards such as WS Security, WS Secure Conversation and XML Encryption.

As OPC UA continues to evolve and gain adoption these features will provide more secure OPC installations.  That’s all well and good, but what do users do today?  As I’ve blogged before, a lot of people aren’t doing anything.  Which is not a good thing (as the OPC Whitepaper points out).  However there are many users out there who do more than just rely on their firewalls or the fragile safe haven of security by obscurity.

The first line of defense if understanding and using proper DCOM security configuration.  The upcoming, third and final installment of the OPC Security Whitepapers will outline basic DCOM settings and IT service hardening.  

There is another whitepaper that outlines several techniques for creating secure OPC architectures.  One of the best ways to limit access to a critical OPC server, is to disable remote DCOM connections to it altogether!  Since most OPC client applications are remote from the OPC server data access would be a bit problematic with a few extra pieces of the puzzle to provide secure access.  The latest version of OPC Tunneller is all about securing remote access, with features such as IP address filtering and data encryption.  If security interests you, it’s worth a look.

One of the beauties of using open standards like OPC, is that users can layer interoperable products to provide important industrial requirements like security and redundancy.  The commitment of OPC vendors to provide long term compatibility and migration means that as the OPC standards evolve, like OPC UA, then solutions implemented today can be easily upgraded or migrated tomorrow.

Well, I didn’t keep up with the daily blogging.   Just too busy listening to the presentations (or giving presentations) and talking OPC with other folk who love industrial standardization!  This year’s DevCon had diverse group of attendees from about 20 countries from Scotland to Australia, Brazil to Japan and all points in between.   A broad range of business verticals was also represented.   Of course the usual suspects from the Industrial Automation and OPC vendors where present, as well as MES and ERP application vendors, and a good cross section of end-user companies covering auto manufacturing, Oil and Gas, Paper, Utilities.

Day 2 and 3 presentations had much more detail than some of  the earlier more introductory type topics.  There where talks on the what mechanisms OPC UA offers in terms of reliability and security.  More detailed information on the Access Type specifications, Alarms and Conditions, Historical Access and Programs.   The really ‘meaty’ talks gave details on implementing OPC UA clients, servers and the associated base framework.

Of course what technical conference would be complete without some exciting demos.  There where several prototype OPC UA server demos, included UA servers running on Embedded XP on a ControlLogix PLC,  examples of OPC UA access to EDDL information, as well as some cross-platform and cross language implementations.  There are a lot of people out there doing some interesting things with OPC UA product development.

The big question everyone keeps asking is “When can I get my hands on OPC UA products?”.  The short answer is there are many functional OPC UA products in the works already.  However, there are still several key things that need to come together before certified OPC UA products can begin shipping.   The final specification releases need to be completed, there are key software modules that need implementation and validation, as well as finalizing the base Profiles and getting the Independent Test labs set up.    (You can see the proposed timeline on the OPC Foundation site).  These are by and large parallel activities, and can be worked on simultaneously by several people.   Many hands make light work, and the more companies who volunteer the faster these deliverables will be hit.  There are a fair number of members on the Early Adopter team, but there is always room for more.

So, if you’re one of the vendors asking “So when will OPC UA be done?”, maybe a better question to be asking is “So, what can we do to help speed timeline for OPC UA adoption?”.  Anyone interested in joining the Early Adopter program should contact the Committee Chair,  Russell Tolsma, or drop me a line and I’ll be sure to get your contact info to Russ.