Introduction to information models

The PLCnext Technology eUA server provides these IEC 62541-5 compliant information models:

Common OPC UA terminology

This topic describes some common OPC UA terms which are used in this documentation.

The information of the OPC UA server can be browsed as a graph of nodes and references. This is called address space.

The entry point of the address space is the Root node. Below that there are folders for Objects with the instance space of the server and Types with the type space which can be referenced by the instances. These nodes can be objects, variables, object types, variable types, methods, reference types or data types.

The address space allows basic interoperability between client and server. However, every server can expose its address space in a different way so clients do not know what the information means and how it is structured.

Information models on the other hand define a type system and semantics of the address space. With the information model a client can understand the information found in the address space.

For example: The DI information model defines a DeviceType with a Manufacturer property. This way, a client can identify devices with their manufacturer exposed by any OPC UA server that spports the DI information model. A server also exposes the information model as part of the address space (mainly in the Types section).

An OPC UA server can implement several information models which also can depend on each other. To distinguish between the nodes of different information models, namespaces are used. A NodeId is then a combination of the namespace (or its index in the namespace array) together with the identifier which is unique within its namespace.

Information models are commonly defined in form of so called companion standards. These are human readable documents describing the type structure and semantics of a domain. In addition, there is a machine-readable version in form of a so-called NodeSet.xml file. These files contain most parts of the specification and can be used to generate code for clients and servers. Some servers can read these files directly in order to expose its nodes in the address space.

Internal and external information models in PLCnext

In PLCnext, we distinguish between internal information models and external information models:

Internal information models are built-in and come with PLCnext (e.g., DI, GDS, Files, Alarms)
External information models are additional application-specific information models that the user can add to PLCnext – like companion standards or vendor-specific extensions

In PLCnext, an external information model needs to be provided in form of a NodeSet.xml file. These files are normally distributed together with the specification of the companion standard. With tools like UA Modeller, user-specific NodeSet.xml files can be created.

Type and instance NodeSets files

NodeSet.xml files typically contain a lot of types and no (or only a few) instance nodes. The instances of these types are project-specific and need to be created for an actual PLCnext Technology project.

In PLCnext, the instances are also described in form of another NodeSet file. This instance NodeSet file needs to be supplied along with the PLCnext project.

Instance nodes for variables or methods can be connected to PLC variables of PLCnext. This way, a user can write a PLC program (C++ or IEC) that implements the functional part of the custom address space.

Note: Currently there is no way to automatically generate such instance NodeSet files. A user needs to write or generate these XML files following the schema of the UA standard. Extra information can be attached to the nodes in the file if interaction with PLCnext is needed.