Type hierarchy
In OPC UA, the type hierarchy is the tree of type nodes built from HasSubtype references. There are four of them, rooted at BaseObjectType, BaseVariableType, BaseDataType and References, plus the event tree under BaseEventType. Companion specifications extend these roots, which is how a Robotics node is still a DI node.
Four hierarchies, one mechanism
ObjectTypes descend from BaseObjectType at i=58, VariableTypes from BaseVariableType at i=62, DataTypes from BaseDataType at i=24 and ReferenceTypes from References at i=31. Event types are ObjectTypes and live under BaseEventType at i=2041, which is why an EventFilter select clause is written against a type in that subtree. All four are browsable at runtime under the TypesFolder at i=86, so a client can read an unknown server's entire type system without any prior file.
Layering is what companion specifications sell
The value of the hierarchy is that models stack. Robotics types derive from IA types, which derive from DI types, which derive from core UA types; Machinery item types sit on the same spine. A client that understands only DI can still read the identification nameplate of a Robotics instance, because that instance is a DeviceType by ancestry. Reading how far up a node's chain goes tells you exactly how much of it your client can interpret.
Ancestry, not equality
Almost every useful question is about ancestry: is this instance a MachineryItem, is this DataType a Structure or an Enumeration, is this reference hierarchical. None is answered by comparing one NodeId. Services take an IncludeSubtypes flag so the server can do the walk; where that is not available, browse HasSubtype inverse from the concrete type until you reach the type you care about. Cache the resulting map once per session - it does not change while you are connected unless the server loads a nodeset.
Abstract types mark the joints
IsAbstract types exist only to be subtyped and never have instances: BaseObjectType, Structure at i=22, Enumeration at i=29, HierarchicalReferences at i=33. They are the anchors your ancestry walk tests against, and a DataType attribute naming an abstract type is a server telling you the concrete type varies per value.
Example
The four type roots plus the event tree, as browsed under i=86
Types i=86
+- ObjectTypes
| +- BaseObjectType i=58 (abstract)
| +- FolderType
| +- BaseEventType i=2041 -> the whole event/alarm tree
| +- BaseInterfaceType -> interfaces (I...Type)
| +- TopologyElementType (DI) -> DeviceType -> MachineryItemType -> ...
+- VariableTypes
| +- BaseVariableType i=62 (abstract)
| +- BaseDataVariableType i=63
| +- PropertyType i=68
+- DataTypes
| +- BaseDataType i=24 (abstract)
| +- Structure i=22 (abstract)
| +- Enumeration i=29 (abstract)
+- ReferenceTypes
+- References i=31 (abstract)
+- HierarchicalReferences i=33 (abstract)
+- NonHierarchicalReferences i=32 (abstract)Defined in: Part 3 - Address Space Model, type definitions and HasSubtype; Part 5 - Information Model for the standard type hierarchy.
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.