In Part 1 of this series, I introduced you to the OPC UA standard and highlighted that data modeling is one of its pillars that make it well suited to become the de facto standard of Industrial IoT information exchange. Now, the question is: why is data modeling so important for Industrial IoT?

‍

‍

Why Data Modeling Matters for Industrial IoT

To answer that question, let me reintroduce the automation pyramid, which involves a strict flow of information up and down the pyramid through dedicated communication networks at each stage.

‍

With the introduction of Industrial IoT communication standards that are common throughout these stages, there won't be a need for these boundaries. Therefore, this rigid structure will inevitably decompose into decentralized components that are capable of flexible communication with each other.

When that happens, the stage will be set for smart manufacturing, because then all the components would be able to gather information from other components at any given time, and go on to autonomously reconfigure, adapt, and optimize themselves accordingly based on that information.

But here's the catch: that can only happen if there is consistency in the presentation of information.

In other words, the manner in which information is represented in an ERP system must be the same manner in which information is represented in a field-level sensor. Hence, the reason why information representation—or modeling—is crucial for Industrial IoT.

‍

The Challenge of Complex Information

‍

Because all these components are complex systems by nature, whatever information modeling approach you decide to use, it must allow you to digitally represent these production assets in their full complexity.

This is where OPC UA Information Modeling comes in. It gives you the ability to digitally describe components of a production asset in a standardized manner, such that any component consuming its information is given a holistic view of the underlying asset.

It should go without saying that eventually, for your machine or plant to be able to interconnect with the rest of the Industrial IoT ecosystem, it will be expected to expose its underlying information in a standardized manner.

But how do you even begin to represent such complex information? I mean, we are used to using simple information types—for example, an individual floating-point variable to represent temperature. How do we move beyond that?

‍

Understanding Address Space

To explain how, let me introduce the concept of an address space.

Generally, to represent any kind of information in a computer system, you need space in memory to hold your data. This is called an address space.

To represent simple information in address space, you just have to create a variable and provide its identity or name to any client interested in reading or writing its value. The identity would typically be a string variable that is unique throughout the address space—for example, "temperature."

Now, in order to use the same address space to represent complex information, OPC UA had to come up with a particular way of organizing data.

‍

Introducing Nodes: The Building Blocks

Specifically, instead of having a name such as "temperature" representing one float variable, OPC UA uses a group of different types of variables represented by a single name or identifier.

This group of variables represented by a single name is called a node, and it is the basic unit of information in OPC UA. Every other type of information in OPC UA is built from a node.

‍

What is a Node Composed Of?

A node consists of three main parts:

1. Attributes: Information about the node itself (e.g., its name or identity)
2. Data: The actual data, which could be the value of temperature
3. References: Information about other nodes that it is related to

So an OPC UA information model, in this case, would be a collection of these nodes and their references.

‍

Node ID Structure and Namespaces

OPC UA doesn't use simple string variables to represent the node identity. Instead, the Node ID consists of three parts:

1. A namespace URI
2. The datatype of the identifier
3. The actual identifier

So ideally, your Node ID will look like this:

ns=http://example.com/UA/;s=temperature


Where:

• ns stands for namespace
• s is the type of identifier used (string)
• temperature is the actual identifier

However, because a namespace URI would be too long to use as the Node ID, the actual namespaces in your OPC UA server are stored in a table so that you only have to specify its index on that table, which would reduce your Node ID to something like this:

ns=1;s=temperature


Where s is short for string.

The Purpose of Namespaces

Now, how is a namespace URI of any use?

Because each node must belong to a namespace, it allows a single OPC UA server to expose different types of information modules. Index zero, which stores the default namespace, is always reserved for the OPC Foundation-based information model, while the other namespace indexes can be used by any other organizations that have information models specific to their industry verticals.

‍

Node Classes: Different Shapes for Different Purposes

But still, that doesn't explain how you can be able to represent complex information on an OPC UA server.

As I mentioned before, a node is a basic building block of an OPC UA information model. So to be able to build complex information out of a basic node, the node has to be able to take different shapes or forms.

Think of it like building a complex metal structure—you need different shapes of metal: straight metal, elbow metal, and T-shaped metal. But they all inherit the basic characteristics of metal.

In almost a similar fashion, OPC UA borrows from a common technique in software development called object-oriented programming to specify different classes of nodes that all inherit the characteristics of a basic node.

These are the classes that are made available for you to design an information model for your machine, your plant, or your software system.

‍

Let's take a look at some of the node classes that are key to building an information model using OPC UA.

‍

1. Variable Node Class

This is a class of nodes that hold actual data.

‍

2. Method Node Class

This is a class of nodes that are used to represent methods or functions that return a result when called by clients.

‍

3. Object Node Class

The Object Node Class is the key to understanding OPC UA information modeling because it represents real objects that you see when you look around a factory. This could be a pump, a compressor, a boiler, or the whole factory itself.

These real-world objects share two characteristics:

• State: For example, the state of a pump could be on or off
• Behavior: For example, starting the pump or stopping the pump

Your Object Nodes are similar to real-world objects. They also consist of state and behavior:

• An OPC UA Object Node stores its state using Variable Nodes
• It stores its behavior using Method Nodes

‍

4. Object Type Node Class

Remember, the Object Node Class that I just described is used to represent real-world objects. But we know that in a factory, and in general, we can have more than one object of the same type. For example, you can have two pumps of the same type.

To cater for that, the OPC UA Object Type Node Class allows you to define, for example, a specific type of pump object and then go on to create multiple instances or copies of that pump type.

In object-oriented programming, Object Types are the equivalent of classes.

‍

5. Reference Type Node Class

Reference Type Nodes contain information about how two nodes or objects are related. Because there are different types of relationships that two nodes or objects can have, there are also different types of Reference Type Nodes that you can use to define relationships between your objects.

‍

Practical Example: Creating a Pump Information Model

Let me walk you through a practical example to tie all of this together.

‍

Let's say you are creating an OPC UA server to expose information of your plant, which has 10 pumps of the same type. Here's how you'd structure it:

‍

Step 1: Create the Base Object

You'd begin by using the Object Node Class to create a pump object.

‍

Step 2: Define the Type

From the pump object, you will then create a pump type using the Object Type Node Class.

‍

Step 3: Instantiate Multiple Instances

Finally, you use the pump type class to instantiate 10 pumps of the same type.

‍

Connecting the Pieces with References

Now, zooming into our pump type, we know that our pump type has an on/off status, which can be represented by a Variable Node that holds a boolean value. We also know that our pump type has start and stop behaviors, which can be represented by Method Nodes with functions that can be called by a client.

The question is: how do we link our pump type to these state and behavior nodes that are stored somewhere in the address space?

We use Reference Type Nodes.

‍

Types of References

For example, one object can be a component of another object, which is the case with our on/off data node being a component of our pump type. So if that's the case, then we use a HasComponent reference type for our pump type in order to specify that it has the on/off status node and the start/stop nodes as its components.

When it comes to creating an instance or copy of our pump type, there is a way of specifying that our pump type is the parent of the created copy. And that is through creating the copy using a HasTypeDefinition Reference Type to indicate the type of its parent.

‍

If by any chance you're finding this hard to grasp, don't worry—it becomes clearer in Part 4 of this series, where I show you how to actually create an information model.

‍

Summary

To summarize:

• An OPC UA information model is a standardized definition of unique nodes in the OPC UA server address space
• The uniqueness of the nodes is provided by the Node ID
• Every object, device, system, or even an entire factory can be represented using an interconnection of nodes and their relationships in an OPC UA server address space

This powerful modeling capability is what makes OPC UA so well-suited for Industrial IoT, enabling complex production assets to be digitally represented in a standardized, consistent manner that can be understood by any OPC UA client—whether it's at the field level or the enterprise level.

This is Part 2 of an 11-part series on OPC UA. In Part 4, we'll dive into actually creating an OPC UA information model, where you'll see these concepts come to life with hands-on examples.

‍