Subtypes inherit the fully-inherited parent type’s InstanceDeclarations.

As long as those InstanceDeclarations are not overridden they are not referenced by the subtype. InstanceDeclarations can be overridden by adding References, changing References to reference different Nodes, changing References to be subtypes of the original ReferenceType, changing values of the Attributes or adding optional Attributes. In order to get the full information about a subtype, the inherited InstanceDeclarations have to be collected from all types that can be found by recursively following the inverse HasSubtype References from the subtype. This collection of InstanceDeclarations is called the fully-inherited InstanceDeclarationHierarchy of a subtype.

The remainder of 6.3.3 define how to construct the fully-inherited InstanceDeclarationHierarchy and how InstanceDeclarations can be overridden.

An instance of a TypeDefinitionNode is described by the fully-inherited InstanceDeclarationHierarchy of the TypeDefinitionNode. The fully-inherited InstanceDeclarationHierarchy can be created by starting with the InstanceDeclarationHierarchy of the TypeDefinitionNode and merging the fully-inherited InstanceDeclarationHierarchy of its parent type.

The process of merging InstanceDeclarationHierarchies is straightforward and can be illustrated with the example shown in Figure 20 which specifies a TypeDefinitionNode “BetaType” which is a subtype of “AlphaType”. The name in each box is the BrowseName and the number is the NodeId.

Figure 20 – Subtyping TypeDefinitionNodes

An InstanceDeclarationHierarchy can be fully described as a table of Nodes identified by their BrowsePaths with a corresponding table of References. The InstanceDeclarationHierarchy for “BetaType” is described in Table 18 where the top half of the table is the table of Nodes and the bottom half is the table of References (the HasModellingRule references have been omitted from the table for the sake of clarity; all Nodes except for 1, 6, and 5 have ModellingRules). All InstanceDeclarations of the InstanceDeclarationHierarchy and all Nodes referenced with a NonHierarchical Reference from such an InstanceDeclaration are added to the table. Hierarchical References to Nodes without a ModellingRule are not considered.

Table 18 – The InstanceDeclarationHierarchy for BetaType

BrowsePath	NodeId
/	6
/F	7
/B	8
/F/H	9
/B/J	10
/B/H	9
SourceBrowsePath	ReferenceType	TargetBrowsePath	TargetNodeId
/	HasComponent	/F	-
/	HasComponent	/B	-
/	Z	/B	-
/	HasTypeDefinition	-	BetaType
/F	HasComponent	/F/H	-
/F	HasTypeDefinition	-	BaseObjectType
/B	HasProperty	/B/J	-
/B	HasTypeDefinition	-	BaseObjectType
/F/H	HasTypeDefinition	-	PropertyType
/B/J	HasTypeDefinition	-	PropertyType
/B	HasComponent	/B/H	-
/B/H	HasTypeDefinition	-	BaseDataVariableType

Multiple BrowsePaths to the same Node shall be treated as separate Nodes. An Instance may provide different Nodes for each BrowsePath.

The fully-inherited InstanceDeclarationHierarchy for “BetaType” can now be constructed by merging the InstanceDeclarationHierarchy for “AlphaType”. The result is shown in Table 19 where the entries added from “AlphaType” are shaded with grey.

Table 19 – The Fully-Inherited InstanceDeclarationHierarchy for BetaType

BrowsePath	NodeId
/	6
/F	7
/B	8
/F/H	9
/B/J	10
/B/H	9
/B/D	4
/C	3
SourceBrowsePath	ReferenceType	TargetBrowsePath	TargetNodeId
/	HasComponent	/F	-
/	HasComponent	/B	-
/	Z	/B	-
/	HasTypeDefinition	-	BetaType
/F	HasComponent	/F/H	-
/F	HasTypeDefinition	-	BaseObjectType
/B	HasProperty	/B/J	-
/B	HasTypeDefinition	-	BaseObjectType
/F/H	HasTypeDefinition	-	PropertyType
/B/J	HasTypeDefinition	-	PropertyType
/B	HasComponent	/B/H	-
/B/H	HasTypeDefinition	-	BaseDataVariableType
/	HasNotifier	/B	-
/B	HasProperty	/B/D	-
/	HasComponent	/C	-
/	Y	/C	-
/C	HasTypeDefinition	-	BaseDataVariableType
/B/D	HasTypeDefinition	-	PropertyType
/B/D	X	/C	-

The BrowsePath “/B” already exists in the table so it does not need to be added. However, the HasNotifier reference from “/” to “/B” does not exist and was added.

The Nodes and References defined in Table 19 can be used to create the fully-inherited InstanceDeclarationHierarchy shown in Figure 21. The fully-inherited InstanceDeclarationHierarchy contains all necessary information about a TypeDefinitionNode regarding its complex structure without needing any additional information from its supertypes.

Figure 21 – The Fully-Inherited InstanceDeclarationHierarchy for BetaType

A subtype overrides an InstanceDeclaration by specifying an InstanceDeclaration with the same BrowsePath. An overridden InstanceDeclaration shall have the same NodeClass and BrowseName. The TypeDefinitionNode of the overridden InstanceDeclaration shall be the same or a subtype of the TypeDefinitionNode specified in the supertype.

When overriding an InstanceDeclaration it is necessary to provide hierarchical References that link the new Node back to the subtype (the References are used to determine the BrowsePath of the Node).

It is only possible to override InstanceDeclarations that are directly referenced from the TypeDefinitionNode. If an indirect referenced InstanceDeclaration, such as “J” in Figure 21, has to be overridden, then the directly referenced InstanceDeclarations that includes “J”, in that case “B”, have to be overridden first and then “J” can be overridden in a second step.

A Reference is replaced if it goes between two overridden Nodes and has the same ReferenceType as a Reference defined in the supertype. The Reference specified in the subtype may be a subtype of the ReferenceType used in the parent type.

Any NonHierarchical References specified for the overridden InstanceDeclaration are treated as new References unless the ReferenceType only allows a single Reference per SourceNode. If this situation exists the subtype can change the target of the Reference but the new target shall have the same NodeClass and for Objects and Variables also the same type or a subtype of the type specified in the parent.

The overriding Node may specify new values for the Node Attributes other than the NodeClass or BrowseName, however, the restrictions on Attributes specified in 6.2.7 apply. Any Attribute provided by the overridden InstanceDeclaration has to be provided by the overriding InstanceDeclaration, additional optional Attributes may be added.

A subtype shall not override an argument of its supertype’s Method InstanceDeclaration which is defined with a concrete DataType. Method arguments defined with an abstract DataType may be overridden. A subtype shall not remove an argument of its supertype’s Method InstanceDeclaration. A subtype shall not add mandatory arguments however it may append optional arguments after all existing arguments of the supertype’s Method InstanceDeclaration.

The ModellingRule of the overriding InstanceDeclaration may be changed as defined in 6.4.4.2.

Each overriding InstanceDeclaration needs its own HasModellingRule and HasTypeDefinition References, even if they have not been changed.

A subtype should not override a Node unless it needs to change it.

The semantics of certain TypeDefinitionNodes and ReferenceTypes may impose additional restrictions with regard to overriding Nodes.