What is ObjectType in OPC UA?

Glossary · Address space

ObjectType

In OPC UA, an ObjectType is the NodeClass that defines the shape of Objects: which Variables, Methods, child Objects and events an instance of it has. Every Object points at one ObjectType via HasTypeDefinition. ObjectTypes form a subtype hierarchy rooted at BaseObjectType and may be abstract.

A type is a template made of nodes

An ObjectType is not a schema in a separate file: it is itself a node in the TypesFolder, with real child nodes hanging off it by HasComponent and HasProperty. Those children are instance declarations, each carrying a modelling rule that says whether an instance must have it. Instantiating the type means copying that structure, which is why a server's type nodes and its instance nodes look identical when you browse them.

Inheritance and abstractness

HasSubtype links a type to its parent, all the way up to BaseObjectType at i=58. A subtype inherits every instance declaration of its supertype and may add more, or narrow an optional declaration to mandatory. The IsAbstract attribute marks types that exist only to be subtyped - you will never find an instance of an abstract type, and a server that offers one is non-conformant.

Type-driven clients

The reason ObjectTypes matter operationally is discovery. Rather than browsing a whole plant address space, a client browses inverse HasTypeDefinition references from MachineToolType and gets every machine tool on the server, whatever the vendor named its folders. This is how the umati dashboard client works, and it also skips instances that are missing mandatory nodes - a useful conformance check in itself.

Example

An ObjectType with its instance declarations, and one instance of it

Types/ObjectTypes
 +- BaseObjectType                    (i=58)
     +- MixerType                     HasSubtype, IsAbstract = false
         +- Temperature  (Variable, Double)     HasComponent, Mandatory
         +- Pressure     (Variable, Double)     HasComponent, Optional
         +- Start        (Method)               HasComponent, Mandatory
         +- Identification (Object)             HasComponent, Mandatory

Objects/Machines
 +- Mixer_01           HasTypeDefinition -> MixerType
     +- Temperature    present  (Mandatory - must be there)
     +- Start          present
     +- Identification present
     (Pressure absent - legal, it was Optional)

The mistake people make: Assuming every child declared on an ObjectType exists on every instance. Only Mandatory declarations are guaranteed; Optional ones may be absent and Placeholder ones have server-chosen BrowseNames. Code that reads a companion-specification type as if it were a fixed struct fails with BadNodeIdUnknown against the first conforming server that omits an optional node.

Defined in: Part 3 - Address Space Model, ObjectType NodeClass, instance declarations and modelling rules; Part 5 - Information Model for the standard type hierarchy.

Related concepts

Object Type hierarchy HasSubtype HasTypeDefinition Instance declaration Modelling rule Mandatory / Optional

Status codes you will meet

BadNodeIdUnknown BadTypeMismatch BadNodeClassInvalid

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.