The information model is the conceptual representation of the objects that you manage to carry out your business. The same pieces of physical equipment and the associated pieces of information can be modeled in different ways, according to the requirements of the specific process and environment. In OPC Classic, it was only possible to manage simple data; the coding of any semantics was not possible, since the information model was flat. For example, in the case of a temperature measured by a sensor, the only information that would have been available to understand the meaning of that data was the name of the variable and a few other elements, such as the unit of measurement. The basic specifications of OPC UA instead provide an infrastructure to structure the information model according to your needs. It also provides a built-in, ready-to-use information model, which gives manufacturers the freedom to create their own extensions according to their devices. This means that clients are able to access this information regardless of the manufacturer, since it will be made available through the same basic model. The basic principles of information modeling in OPC UA are as follows:

• Use of object-oriented techniques, including hierarchies and inheritance
• The same mechanism is used to access the types and the instances
• Information is made available by exploiting fully-connected node networks
• The hierarchies of the data types and the links between the nodes are extendable
• There are no limitations on how to model information
• Information modeling is always placed on the server side

The set of objects and related information that an OPC UA server makes available to the clients is the address space. You can think of the address space as similar to the implementation of the OPC UA information model. The address space of the OPC UA is a set of nodes that are connected by references. Each node has properties, which are called attributes. A specific set of attributes must exist in all nodes. The relation between nodes, attributes, and references is shown in the following diagram:

Nodes can belong to different node classes, depending on their specific goal. Some nodes might represent instances, others might represent types, and so on. In the OPC UA, there are eight standard node classes: variable, object, method, view, data type, variable type, object type, and reference type. In OPC UA, the most important node classes are object, variable, and method:

• The object node class structures the address space and can be used to group variables, methods, or other objects.
• The variable node class represents a value. Clients can read, write, or subscribe to it.
• The method node class represents methods that have input and output parameters that clients can invoke through the call service to get a result. They are designed to work quickly. Some of the quick actions that can be managed through methods include opening a valve, starting a motor, or even calculating the results of a simulation based on the input parameters provided.
• A reference describes the relationship between two nodes and is uniquely identified by the source node, the target node, the reference type and its direction. We can think of references as pointers to other nodes. They are not accessible directly but can be accessed by browsing the nodes. The reference type is the way in which the link between the connected nodes is modeled. OPC UA defines a set of built-in reference types organized hierarchically, but each server has the option to define its own specific set by extending the basic one. The reference types are exposed in the address space as nodes and this allows clients to easily recover information on the references that are used by the OPC UA server in which the client is interested.
• A view is used to restrict the number of nodes and references that are visible in an extended address space. Using views, servers can provide different representations of their address space to different clients that they are connecting to, depending on their use cases. There are two ways to use views in OPC UA:
  • A view can be represented in the address space as a node that provides an entry point to the data to be displayed. All the nodes that are part of a view are accessible, starting from the starting node.
  • The node ID of the view node can be used as a filtering parameter for address space navigation. In this way, the servers can hide the references to the nodes that are not part of the view and the clients only see a subset of the address space.