I often get questions on OPC, and recently more of the queries are on OPC UA.  It seems a lot of the questions are about the OPC UA Information Model, so I thought I post some of my thoughts on the subject.

A good starting point to understanding what the Information Model might represent, is to think in terms of the OPC Item address space, and Browsing interfaces in OPC DA.  The specification described interfaces for viewing and navigating the address space (browse space).   It did not dictate how the browse space was built or persisted in the underlying OPC DA COM server.   In OPC DA there was an implied HasComponent relationship between the branches/leaves.

Take for example the OPC Server for Honeywell TPS.  The OPC Server HasComponent of (root branch per LCN),  each (root branch per LCN) HasComponent of (Unit branch), each (Unit branch) HasComponent of (Point.Parameter DCS tags per Unit), etc.  In some cases the OPC Server did not persist this information, it simply made calls into the underlying native system to return the Items, like the OPC Server for Performance Monitor.  In other cases the OPC Server would persist the information as a memory map, relational database or XML schema, such as the OPC Server for Microsoft Excel.  In both cases it was transparent to OPC Client where the information came from.

The same is true for an OPC UA server, except instead of hierarchical folder of ItemId’s in a branch/leave relationship, the OPC UA specification allows for a full mesh network of NodeID’s with additional References.  OPC UA defines the services to view and navigate the address space, as well as some provisions for OPC UA clients to configure or modify the address space.

All information in an OPC UA server will be composed of the standard OPC UA Object types (ServerTypes, EventTypes, VariableTypes, BaseTypes, basically any type outlined in Part 5 – Section 8.  Vendors can not create new ObjectTypes, but they can extend the BaseObject type to create Objects with specific semantics (i.e extend the BaseObject type to create a PumpObject).  An OPC UA server can be thought of as a whole collection of Objects, or a ‘cloud‘ of Objects that can be grouped together or organized in different ways.  There will be some well defined entry points into the address space depending on which Object Relationships the user cares about.

1. Every OPC UA server will have an OPC UA Root object. (the entry point to the whole address space)
2. Every OPC UA server will have at least one Server Object. (the entry point for Server information)
3. It is expected that an OPC UA server will support at least one View Object.  This where vendors would present different organizational browse spaces.   This would be very similar to the ItemID browse space of an OPC DA server.
4. The Reference Type object is the entry point for supported references.  Clients can determine what relationships a server supports, and use them as filters to browse calls

If the OPC UA Server represents a physical plant, you might want to have a ‘Mechanical View’; Plant Area A contains Unit 1 and Unit 2.  Unit 1 contains Distillation Column 100, Pump 101, Pump 102, Heat Exchanger 101.  Pump 101 contains InletFlow 1000, IsolationValve 1001, OutletFlow 1000.

You could also create a View that shows some of the same assets in a different relationship, ‘Maintenance View’ ;  Plant Area A contains Engineer A and Engineer B,  Engineer A is responsible for Pumps 101, Pump 102, Engineer B is responsible for Heat Exchanger 101, Distillation Column 100.  

In some cases the OPC UA server will not need to persist this information if the underlying native system provides the information (i.e. An OPC UA Server for an EMS database).  In most cases, the server will have to persist the reference relationships between the nodes. 

The whole concept of an abstract information model, various Views based on different criteria, and the implementation details of how to store and organize the ‘cloud’ of Objects and their relationships is a difficult thing to explain.  Hopefully this sheds a little light on things.  Once more powerful OPC UA servers are developed, different Vendors should offer Whitepapers or implementation guides on examples of building information models.

The OPC Foundation has released the details for the upcoming OPC Interoperability Workshop in Deerfield Beach, Florida USA.  It’s running May 7th-11th, 2007.  This year’s session will allow up to a 50 participants to validate OPC DA (V1, V2 and V3) interoperability, OPC HDA, OPC A&E and OPC XML-DA.

In order for a DA Client to qualify to use the new ‘Self-Tested’ logo, the product must be tested at an Interoperability Workshop with other DA Servers and it must pass a supervised test with the OPC Analyzer.  The interoperability workshops will be the only venue clients are tested with the Analyzer, and this is the first North American IOP to use the OPC Analyzer, it likely the first chance for many vendors to quality for the new logo. (sleek, new design for improved interoperability )

It’s a good idea for OPC member vendors to download the OPC Analyzer and run all the tests beforehand.

The will all be a chance to test OPC Servers against the beta OPC UA DA COM Wrapper as well.  Online registration is now available for OPC members with all the details. (The price goes up after April 7th, so get in early.)

It’s five days of OPC Interoperability fun in the sun.  What more could anyone ask for?

Well, maybe not all on it’s own, but OPC can do its part.  Seems everywhere you look these days people are talking about climate change, using less resources and saving energy.  Here in Canada, the Kyoto hot potato is in the news again.  The latest entry on YourEneryForum.com mentions that the State of the Union address touched on energy efficiency, but goes on to talk more about saving energy in the Home and Building applications.  There was an interesting excerpt from the posting:

According to the American Institute of Architects, “Buildings account for forty-eight percent of U.S. energy consumption and generate far more greenhouse gas emissions than any other sector.”  From schools and office buildings to big-box retailers and factories, all those structures use energy. 

It got me thinking about system monitoring and process optimization.  For years, the industrial automation world have been using OPC to monitor assets and feed data to optimization applications, provide historical analysis, and advanced calculation packages in order to save energy and improve operational efficiency.  OPC can provide the same functionality for building automation systems.  The home and building control industry has several wire level protocols, and there are OPC servers available for many of the popular ones, such as Lonworks, BACNet, and Johnson Controls.

With all this focus on energy efficiency and security, it seems inevitable that the successful OPC solutions from the industrial automation world will be applied more and more to the building automation world.  See, OPC can help save the planet.

The Digital Bond blog is posting a couple of videos from their S4 SCADA Security Scientific Symposium 2007 for a week.  Included is the presentation of  OPC Exposed: Denial of Service Attacks, by Ralph Langner, Langner Communications AG.

For those that missed the presentations, it’s a good chance to have a look at some of the good work folks are doing on raising awareness of security and OPC.  The presentation gives an overview of some DoS attacks and Man-In-The-Middle type scenarios, and some Conclusions:

…for end users
• Think about using OPC Tunnelling products
• Do configure DCOM access rights properly
• Update your operating system, if possible
• Handle OPC access to SCADA systems with extra care

And for the SCADA and OPC vendors to be conscious of proper DCOM settings, and designing products with these types of problems in mind.  If nothing else, it gives vendors some things to consider when developing and implementing OPC servers, and types of testing to perform.  Langner also offers the testing tool used to any vendors who wants it.  I’m sure many OPC vendors have similar test platforms already.   I know our OPC Q&A folk have applications the developers affectionately call ‘The Wringer’ and ‘The 1000 Monkeys’

As the focus on security in OPC and SCADA continues, expect to hear more presentations like these.  I’d also expect to see a renewed focus on OPC architectures and products that increase OPC security and monitoring of OPC assets.

The latest of the Access Type specification parts, Part 10 – Commands has been released. 

For those of you new to the blog, I’ve been giving a brief recap of the Access Type specs as they’ve been released  (Part 8 and Part 11 for your reading enjoyment).    I also gave a high level view of Part 10 when it was set to Release Candidate, so everyone already knows  Programs is a more comprehensive covering of the functionality that was intended for the OPC Commands specification.  

The big difference between the Release Candidate and the Final Release version is the very detailed Program example in the Appendix.   The Programs specification represents a very powerful feature set of OPC UA, and of course what comes with that a degree of complexity in implementation.   The example ties together many of the concepts nicely.

As always Members can get the full details of the specifications from the downloads section.

The OMAC Microsoft Manufacturing User Group (MS MUG) hosted the Manufacturing Operations Forum in Redmond, Washington, last week.  For those not familiar with the MS MUG, it was formed in 1999 to address issues that arise when applying Microsoft technology in manufacturing.  It’s mission is to define and resolve these issues, such as version management, system integration, maintenance, and supplier responsibility.  One of the subgroups is MUGOPC, which concentrates on the expanding need to update user issues into OPC standards.

Some of the topics discussed included the results from a recent on-line survey,  and some disappointing, but not unexpected, news on Vista that Dale over at Digital Bond has more details on.

The MUGOPC group also recently conducted surveys of the vendors and end-users asking about their experiences with OPC, and interoperability.  Of the over 650 end-user respondents, nearly 75% had no or only minor OPC problems.   Not too shabby, but of course that number can be improved on.  The OPC Foundation is working on a few things to do just that.   There’s an article in this month’s ControlGlobal OPC Connection column, that goes into more details on OPC Interoperability.  I’d encourage you to take a look, since I know the author.