In general, changing the configuration of an application accessible via an OPC UA Server can be done by writing Variables or calling Methods. Sometimes, configuration changes also lead to changes of the AddressSpace, that is, adding or removing Nodes or References from the AddressSpace. This section focuses on this case and provides different options with their pros and cons.

The recommended option is to use Methods, as described in 8.4.

Note that some Servers will not allow dynamic changes of the AddressSpace via the OPC UA interface. They either have a static AddressSpace specific to the product version (never changed for a specific product like maybe a temperature sensor with a fixed set of configuration parameters) or a configuration that can only be changed outside the OPC UA interface (like a PLC where the configuration is only changed via the proprietary engineering tools of the PLC vendor).

The NodeManagement Services defined in OPC 10000-4 are designed to add or remove Nodes and References from an OPC UA Server. They might be seen as an obvious fit to change the configuration of the AddressSpace. However, there are various challenges with those Services:

• The Services take the information exactly according to the OPC UA meta model, i.e., for each added Node you provide all the Attributes of the Node. If the Server would need some additional information not exposed in the AddressSpace (like a field bus address) the Services are not suitable. Servers can of course extend the AddressSpace with for example a Property containing the field bus address, but this might not be wanted to be generally accessible.
• The Services do not provide a transactional context. There is an individual Service for adding Nodes, one for removing Nodes, one to add References and one to remove References. If the configuration change requires a transactional context (e.g. deleting some Nodes and adding various new ones including References between them), the Services are not suitable.
• The Services do not provide any information where it is allowed to add what Nodes. Often, a Server does not allow to add or remove all Nodes, but only specific Nodes at specific places of the AddressSpace. The Services are generic and do not make any restrictions. That means, the Client would need to guess where it is allowed to use them and where not, or additional information would need to be added to the AddressSpace.

Therefore, using the NodeManagement Services is in most cases not the best approach and it is recommended to use one of the other approaches described in this whitepaper.

Writing Variables can be used to change the structure of an AddressSpace. A Server may, for example, have a Variable “NumberOfSubmodules” and an Object for each submodule. If the Variable is written, either Objects are added (if the number increases) or removed (if the number decreases). This approach is limited and has the issue that it is not clear which Nodes to delete (which submodule in the example) and does not provide a configuration for new added Nodes (new submodules), so they need to be created with some default values and may need to be changed afterwards. Therefore, in general it is not recommended to use this approach.

However, as a special case a server may expose the elements of an array as subvariables. In this case, writing the array may lead to the creation or deletion of subvariables. OPC 10000-5 uses the ModellingRule “ExposesItsArray” in the diagnostics information for this approach. Servers may also use the “HasStructuredComponent” References to expose the entries of an array as subvariables. The slight differences of both approaches are described in 7.6 and OPC 10000-3.

By providing Methods to change the AddressSpace, using the arguments of those Methods provides the highest flexibility and is therefore the recommended approach to change the structure of the AddressSpace. The specific arguments allow, for example, to provide the full configuration of a newly added Node or set of Nodes, to define exactly which Nodes should be removed with which options, etc.

There are different patterns that can be used when using Methods. They are described in the following.

In this case, the TypeDefinition provides Methods to add or remove instances of the type.

Note that Methods can only be applied to Objects and ObjectTypes, therefore this only works with ObjectTypes, not with VariableTypes.

OPC 10000-3 already defines a standardized BrowseName to create Objects of an ObjectType, “0:Create”. It is supposed to be a class Method on the ObjectType which is called on the ObjectType to create a new instance of the ObjectType. The arguments of the Method should provide the place where to put the new Object (e.g. the parent NodeId), and the configuration of the new Object (like what optional components should be available).

The deletion of an Object can be a normal instance Method, which is called on the instance in order to delete it. As an alternative, a class Method could be used taking identification of the instance to be deleted as an input argument.

An alternative approach, taking the ownership of the instance into account, is to provide Methods to add or remove Nodes on the parent where the new Node is to be added or removed.

This is a more intuitive approach for client users as they directly experience where the new Node is added or an existing one can be removed, and from a server developer’s perspective fits better to the place where the functionality would be implemented.

Examples of this approach can be found in the PubSub configuration of OPC 10000-14. For example, the PubSubConnectionType allows you to add a WriterGroup with the AddWriteGroup Method or a ReaderGroup with a AddReaderGroup Method, and to delete them with the RemoveGroup Method. Those added groups become direct children of instances of the PubSubConnectionType. See Figure 8 for a graphical representation, taken from OPC 10000-14. A Server may have several instances of those, and the Object on which the Method is called, gives the context where an instance is added or removed.

Figure 8 – Example of Methods at the place the instance is located (taken from OPC 10000-14)

As a special case of Method calls, the standardized file transfer of OPC UA can be used to provide larger changes of the AddressSpace. This is useful, when many things need to change in the AddressSpace in one atomic operation, and not just individual instances or a small set of Nodes based on a TypeDefinition.

OPC 10000-14 provides this approach as well for larger changes of the PubSub Configuration. The PubSubConfigurationType is a subtype of the FileType defined in OPC 10000-20 and allows to either read a whole PubSubConfiguration or deploy a new configuration to the server. A specific file format is used for this case. Depending on the use case, different file formats may be used, for example, when downloading a recipe to a machine.

In order to provide smaller changes to the AddressSpace it is recommended to use the approach described in 8.4.2 where the Methods are located at the place the instance is managed. In case, a larger configuration change should be deployed, it is recommended to use the file transfer described in 8.4.3.