OPC UA information model

Question

Lets say I have multiple distributed complex machines. Each machine contains of multiple cpmplex devices. Each device has its own OPC UA server to monitore the device components. With an OPC UA client I want to read all the data items of the OPC UA servers.

Now I don't know how to build the information model. I design a global information model which contains all machines, their devices and the internal components of the devices. From the global point of view, that makes sense. But do I have to create also a local information model for each server? Or does the local OPC UA server use the global information model, but the server implements only for that server relevant objects (based on the global information model)?

UPDATE:

Here is an example setup:

In the example you can see three layers - machine layer, building layer and factory layer.

Here is my understanding how to model such setups. There is one overall OPC UA information model, which describes all types etc. Each OPC UA server knows that information model and all contained type descriptions.

Now, depending on the real world setup, I can create an object model. An OPC UA server at the machine layer contains all objects from the underlying system, in this example the devices.

With an OPC UA Client at the building layer, I can connect to the OPC UA server from the machines and I can read all data items from the devices inside the machines.

An OPC UA client at the factory layer can connect to the OPC UA servers from the buildings. The OPC UA server at the building level can provide more objects:

And an OPC UA client from outside the factory can see the whole picture of the object model:

But how can I route through the servers to get the device data from outside the factory? Do I have to create the object model from the machine layer again in the building layer? And again in the next higher level layer and so on?

Or does any OPC UA server at each layer know the whole object model like the information model?

Answer 1

The system could be modelled using three different models, and links among the three models:

1. A hierarchical real-world data model that models the real-world objects: For example,

   Factory 1
   |--Building 1      
   |  |--Machine 1    
   |  |  |--Device 1
   |  |--Machine 2
   |     |--Device 1
   |--Building 2    
      |--Machine 1  
         |--Device 1
         |--Device 2
         |--Device 3
   
   Factory 2
   |--Building 1
      |--Machine 1
         |--Device 1
         |--Device 2
         |--Device 3
   

2. A remote terminal unit data model that models data it monitor directly, and it corresponds to an OPC UA server:

   RTU 1 
   |--Data 1   ## Factory 1 -> Building 1 -> Machine 1 -> Device 1
   |--Data 2   ## Factory 1 -> Building 1 -> Machine 2 -> Device 1
   
   RTU 2
   |--Data 1   ## Factory 1 -> Building 2 -> Machine 1 -> Device 1
   |--Data 2   ## Factory 1 -> Building 2 -> Machine 1 -> Device 2
   |--Data 3   ## Factory 1 -> Building 2 -> Machine 1 -> Device 3
   
   RTU 3
   |--Data 1   ## Factory 2 -> Building 1 -> Machine 1 -> Device 1
   |--Data 2   ## Factory 2 -> Building 1 -> Machine 1 -> Device 2
   |--Data 3   ## Factory 2 -> Building 1 -> Machine 1 -> Device 3
   

3. A logical remote terminal unit data model that models one or more remote terminal units, or other logical remote terminal units:

   LRU 1
   |--RTU 1
   |--RTU 2
   
   LRU 2 
   |--RTU 3
   

The following tasks are required:

1. OPC UA information model is only mapped to the remote terminal unit data model.
2. OPC UA client maps the received data (from the OPC UA server) to the hierarchical real-world data model. This is independent of the OPC UA data model but rather application specific.
3. To issue commands from the hierarchical real-world data model to its source OPC UA server, OPC UA uses links to find the correct remote terminal unit and then the data from the remote terminal unit data model.

Answer 2

The OPC UA servers include two main categories of information: types and instances.

When we are talking about information models, we typically talk about different type definitions. For example generic models for all devices (OPC UA for Device (DI)) or specific models for certain device types (OPC UA for Analyzer Devices (ADI), etc). The types define common structures for objects: when you encounter an object of type "spectrometer", for example, you know what kind of structure to expect from it. The types are often fixed and when they are standardised, they should not change. If you define your own types, which can be specialisations of the standard types, you have of course a bit more flexibility.

Now, if you wish to model a complete production site, you would be creating the outline and arrangement of actual instances: "Spectrometer 1" inside the "Laboratory" and "Vessel 13" inside the "ProductionHall B", for example. This model is typically more dynamic and up to change, when the layout of the facility is changed.

Due to the above reasons, we don't typically model the instances in the standard models or talk about them that much as information models. You could think that they are more or less the configuration of the system.

Now, as you've realised, the whole system may consist of various OPC UA servers in practice. The capabilities of each server are varying and your options may be limited. In an ideal world, all servers would be serving data modelled via proper information models. That is, the instances would follow the structures of standard types or enabling you to model them with your own types.

On the other hand, most of the currently existing OPC UA servers are just providing "unmodeled" data. This was the only option in OPC Classic and most actual OPC UA servers are still on the same level. Hopefully, in future we will see more OPC UA servers providing the option to adopt information models in them as well. Or we might see a rise of "Aggerating OPC UA Servers", which enable you to remodel the data according to standard or custom models.

Anyway, when you create models of your systems, I advice you to concentrate on the type information and then just apply this to the actual layout model of your system by using these types.

To actually answer your question, I think it is enough if you just create the model you need in your system, since you cannot probably spread it very well to the actual OPC UA servers at the moment. But of course, it would be better if you could apply the models to the specific servers as well.