OPC UA defines a type model supporting one object-oriented type hierarchy for ObjectTypes. Although the specification does not restrict those hierarchies to be single inheritance (i.e. a type can only have one super-type) it only specifies the semantic (inheritance rules) for single inheritance.

In general, good object-oriented design is accomplished by using composition to aggregate an object which provides several functions instead of over-using inheritance [GH95], [FF04] .

Interfacesand AddInscomplement the type model and can be used when subtyping is not suitable for the required extension. They:

  • allow enhancing multiple types at arbitrary positions in the type hierarchy.
  • also allow enhancing just instances.

Interfacesare ObjectTypesthat represent a generic feature (functionality), assumed to be usable by different ObjectTypesor Objects. The Interfacemodel specifies the rules and mechanisms to achieve this.

The “InterfaceTypesObject(see OPC 10000-5) has been defined so that all Interfacesof the Serverare either directly or indirectly accessible browsing HierarchicalReferencesstarting from this Node.

Rules for the definition of Interfaces:

Rules for applying Interfaces:

If the rules cannot be fulfilled (e.g. name collisions) the ObjectTypecannot apply the Interface, i.e. it shall not reference the Interfacewith a HasInterface Referenceof a subtype.

The rules apply for each referenced Interface. As a consequence, an ObjectTypecannot reference two Interfacesusing the same BrowsePathfor Nodesthat are not similar Nodesor have TypeDefinitionNodesthat are not compatible (compatible means they have either the same TypeDefinitionNodeor one TypeDefinitionNodeis the subtype of the other TypeDefinitionNode).

Figure 8illustrates example Interfaces:

  • ISerializeServiceType, an Interfaceto convert the Objectand its components into a stream of bytes.
  • ITransactionServiceType, an Interfaceto perform a sequence of changes to the Objectas a single operation.
  • ILocationType, an Interfaceto specify the installation location of the Object.


Figure 8– Examples of Interfaces

The following examples illustrate the application of these Interfaces. In Figure 9the example Interface ILocationTypeis applied to the XYZ-DeviceType ObjectType. It also illustrates the overriding of Property“Address” by changing the ModellingRulefrom Optionalto Mandatory. Figure 10in addition shows how to use the ISerializeService Interfaceon the instance only. Figure 11shows an Interfacehierarchy where InstanceDeclarationsof the referenced Interfaceand its parent type(s) are applied (the fully-inherited InstanceDeclarationHierarchy).


Figure 9– Example: Interface application to an ObjectType


Figure 10– Example: One Interface applied to an ObjectType another one to the instance


Figure 11– Example: Interface Hierarchy

Clientscan detect the implementation of Interfacesby filtering for the HasInterface Referenceinto the Browse Servicerequest.

On instances, the Browse Servicewill return elements derived from an Interfacetogether with elements of the Node’sbase type. Clientscan also use the TranslateBrowsePathsToNodeId Servicewith BrowseNamesof Interfacemembers to get the NodeIdof these members directly.

In the example in Figure 10Address” with the starting node MD002can be used to request the NodeIdof this Property.

On Objectinstances, some Nodesof an Interfacemay not be available if defined with ModellingRule Optional.

AddInsassociate a feature or feature-set, represented by an ObjectTypeto the Node(an Objector ObjectType) they are applied to. The Interfacemodel is different than the AddInmodel in that it is based on composition. An AddInis applied to a Nodeby adding a Referenceto the AddIninstance.

There are no restrictions for AddIn ObjectTypesand there is no special supertype for AddIns. To identify instances as an AddIn, the HasAddIn Referenceor a subtype shall be used.

The AddIn ObjectTypeshall include the definition of a default BrowseNameusing the DefaultInstanceBrowseName Property. Instances of such an AddInshould use this default BrowseName. If an AddInis instantiated multiple times in the same parent, only one instance can have the default BrowseName.

The definition of an AddInand its use with a default BrowseNameis illustrated in Figure 12.


Figure 12– Example of AddIn with default BrowseName

As already described, an AddIncan be applied on types and instances. The use on an instance is shown in Figure 13.


Figure 13– Example of AddIn applied to an instance

Clientscan detect the implementation of AddInsby passing the HasAddIn Referenceas filter to the Browse Servicerequest. If an AddInhas a default BrowseName, Clientscan use the TranslateBrowsePathsToNodeId Servicewith the default BrowseNameto get the NodeIdof an AddIn.

In the example in Figure 12the relative path “MyFeature/MyPropertyM” with the starting node MD002can be used to request the NodeIdof this Propertyand the relative path “MyFeature/MyMethodO” can be used for the respective Method.