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.