Interface
In OPC UA, an Interface is a type that adds a named set of children to any node that references it with HasInterface, independent of the node's place in the type hierarchy. Interface types derive from BaseInterfaceType and are named I...Type. The Machinery building blocks are delivered largely as interfaces.
Why single inheritance was not enough
An ObjectType has exactly one supertype, so before 1.04 a model that wanted a machine to carry both a vendor nameplate and an energy-flow contract had to either put both into one base type or duplicate the nodes. Interfaces, added in 1.04, break that: an interface is an ObjectType under BaseInterfaceType whose instance declarations are merged into anything that declares HasInterface to it. A node can declare as many interfaces as it needs.
How it appears on the wire
HasInterface is a non-hierarchical reference, so it does not show up in a browse tree drawn from HierarchicalReferences - you have to ask for it. The interface's members do appear as ordinary children of the implementing node, with the interface's BrowseNames and its modelling rules. So a client can work in two ways: browse HasInterface to learn what contracts a node claims, or simply translate the browse path for the members it needs and let absence tell it the same thing.
Interfaces in the Machinery stack
This is what makes the Machinery building blocks composable. IMachineryItemVendorNameplateType and IMachineTagNameplateType carry identification data onto any machinery item without dictating its base type; IMachineryEquipmentType marks equipment; the Machinery Energy model adds flow and energy interfaces such as IVolumeFlowType. A vendor derives its machine type from whatever base fits, then adds the interfaces for the capabilities the machine actually has. That is why two conforming machines can share a nameplate contract while having unrelated ancestries.
Writing a client against interfaces
Match on the interface, not on the concrete type. Browsing inverse HasInterface from IMachineryItemVendorNameplateType gives every node on the server that claims a vendor nameplate, whatever kind of machine it is - the same discovery pattern as HasTypeDefinition, one level more general. Keep the type-ancestry walk too: interfaces themselves form a hierarchy under BaseInterfaceType, and a node may implement a subtype of the interface you asked for.
Example
One machine type, one supertype, several interfaces
MachineryItemType (Machinery)
^ HasSubtype
MixerType (vendor, ns=4)
--HasInterface--> IMachineryItemVendorNameplateType (Machinery)
--HasInterface--> IMachineTagNameplateType (Machinery)
--HasInterface--> IVolumeFlowType (Machinery Energy)
Instance Mixer_01 then carries, as ordinary children:
Identification/Manufacturer from the vendor nameplate interface
Identification/SerialNumber from the vendor nameplate interface
Identification/AssetId from the tag nameplate interface
VolumeFlow from the energy interface
Discovery by contract rather than by class:
Browse( nodeId = IMachineryItemVendorNameplateType,
direction = Inverse,
referenceType = HasInterface )
-> every node on the server that publishes a vendor nameplateDefined in: Part 3 - Address Space Model, interfaces, BaseInterfaceType and the HasInterface reference (added in 1.04); Part 5 - Information Model for the standard types.
Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.