Several objects can occur several times in the parent object (e.g. several moulds in one machine). For these, container objects are modelled. The benefit is that all instances are collected in one object so that changes can be easily recognized by using a Property NodeVersion which can be subscribed by clients. According to OPC UA, Part 3, the instances of the container objects shall also trigger a GeneralModelChangeEvent.

The following container types are defined:

Within these containers, the child elements have the modelling rule OptionalPlaceholder which allows to add and remove instances of the objects dynamically.

The BrowseNames of the child elements are created with numbers as suffixes starting with 1 (e.g. “Mould_1”, “Mould_2” …). It is allowed to use numbers with leading zeros, e.g. “Mould_001” for better sorting. It is not mandatory to use successive numbers. That means there can be gaps and it is also allowed to have e.g. two instances with BrowseNames “Mould_042” and “Mould_099”.

The objects have an IsPresent-flag. This allows to have a fixed number of instances prepared (e.g. if the maximum number of child components is limited by the design of the machine) and to indicate if the component is physically present. With this there are two possibilities: Dynamic creation of instances or fixed number of instances. However, a client which is interested in the contents of the container shall always subscribe the NodeVersion and/or ModelChangeEvents of the container object to get informed about changes.

NOTE: As the child elements are created by the server, the namespace of the BrowseNames is the Local Server URI with namespace index 1 or a vendor specific namespace with vendor specific index.