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 “InterfaceTypes” Object(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:

• Interface ObjectTypesshall be abstract subtypes of the BaseInterfaceType ObjectType.
• InstanceDeclarationson an Interfaceshall only have ModellingRules Optionalor Mandatory.
• Interfacescan be subtyped as specified in clause 6.3.
• Interfacesshall not be the source of HasInterface References.
• Recommended convention: The first letter of an Interfaceshould be ‘I’. See examples below.

Rules for applying Interfaces:

• When an ObjectTypereferences an Interfacewith a HasInterface Referenceor a subtype, the following rules apply:
• Each mandatory InstanceDeclarationof the fully-inherited InstanceDeclarationHierarchyof the Interfaceshall have for each BrowsePatha similar Node(see 6.2.4) with the ModellingRule Mandatoryusing the same BrowsePathin the fully-inherited InstanceDeclarationHierarchyof the ObjectType. The rules for instantiating InstanceDeclarationsdefined in 6.2.6 shall be applied.
• Each optional InstanceDeclarationof the fully-inherited InstanceDeclarationHierarchyof the Interfaceshould have for each BrowsePatha similar Node(see 6.2.4) with the ModellingRule Mandatoryor Optionalusing the same BrowsePathin the fully-inherited InstanceDeclarationHierarchyof the ObjectType. The rules for instantiating InstanceDeclarationsdefined in 6.2.6 shall be applied. If no similar Nodewith the same BrowsePathexists, the ObjectTypeand its sub-types shall not use the same BrowsePathfor a different Node(e.g. with a different NodeClass).

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).

• Subtypes should not have a HasInterface Reference to an Interface if it was already applied to a super-type.
• When an Objectreferences an Interfacewith a HasInterface Referenceor a subtype, the following rules apply:
• The Interfaceshall not be applied on the Objectwhen the Interfacecannot be applied on the TypeDefinitionNodeof the Object.
• The same rules on the Objectapply as if the Interfacewould have been applied on the TypeDefinitionNodeof the Object(e.g. all Mandatory InstanceDeclarationsneed to be applied).
• The Nodesdefined based on the Interfaceshall be handled as if they were defined by the TypeDefinitionNode. For example, the TranslateBrowsePathsToNodeIds Serviceshall return them first.
• If several Interfacesshould be applied to the Object, they should be treated as if they were all applied to the ObjectTypeof the Objectat the same time. If this is not possible, the Interfacescannot be applied to the Objecttogether.
• Instances should not have a HasInterface Referenceto an Interfaceif it was already applied to the TypeDefinitionNode.
• A BaseInterfaceTypeor any subtype of BaseInterfaceTypeshall not be the TargetNodeof a HasTypeDefinition Reference.

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 10“Address” 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.