The HasSubtype ReferenceTypedefines subtypes of types. Subtyping can only occur between Nodesof the same NodeClass. Rules for subtyping ReferenceTypesare described in 5.3.3.3. There is no common definition for subtyping DataTypes, as described in 5.8.3. The remainder of 6.3specify subtyping rules for single inheritance on ObjectTypesand VariableTypes.

Subtypes inherit the parent type’s Attributevalues, except for the NodeId. Inherited Attributevalues may be overridden by the subtype, the BrowseNameand DisplayNamevalues should be overridden. Special rules apply for some Attributes of VariableTypesas defined in 6.2.7. Optional Attributes, not provided by the parent type, may be added to the subtype.

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

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

The remainder of 6.3.3define how to construct the fully-inherited InstanceDeclarationHierarchyand how InstanceDeclarationscan be overridden.

An instance of a TypeDefinitionNodeis described by the fully-inherited InstanceDeclaration Hierarchyof the TypeDefinitionNode. The fully-inherited InstanceDeclarationHierarchycan be created by starting with the InstanceDeclarationHierarchyof the TypeDefinitionNodeand merging the fully-inherited InstanceDeclarationHierarchyof its parent type.

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

image016.png

Figure 13– Subtyping TypeDefinitionNodes

An InstanceDeclarationHierarchy can be fully described as a table of Nodesidentified by their BrowsePathswith a corresponding table of References. The InstanceDeclarationHierarchy for “BetaType” is described in Table 18where the top half of the table is the table of Nodesand the bottom half is the table of References(the HasModellingRulereferences have been omitted from the table for the sake of clarity; all Nodes except for 1, 6, and 5 have ModellingRules). All InstanceDeclarationsof the InstanceDeclarationHierarchyand all Nodesreferenced with a non-hierarchical Referencefrom such an InstanceDeclarationare added to the table. Hierarchical Referencesto Nodeswithout a ModellingRuleare not considered.

Table 18– The InstanceDeclarationHierarchy for BetaType

BrowsePath

NodeId

/

6

/F

7

/B

8

/F/H

9

/B/J

10

/B/H

9

Source Path

ReferenceType

Target Path

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 BrowsePathsto the same Nodeshall be treated as separate Nodes. An Instancemay provide different Nodesfor each BrowsePath.

The fully-inherited InstanceDeclarationHierarchy for “BetaType” can now be constructed by merging the InstanceDeclarationHierarchyfor “AlphaType”. The result is shown in Table 19where 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

Source Path

ReferenceType

Target Path

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 HasNotifierreference from “/” to “/B” does not exist and was added.

The Nodesand Referencesdefined in Table 19can be used to create the fully-inherited InstanceDeclarationHierarchyshown in Figure 14. The fully-inherited InstanceDeclarationHierarchycontains all necessary information about a TypeDefinitionNoderegarding its complex structure without needing any additional information from its supertypes.

image017.png

Figure 14– The Fully-Inherited InstanceDeclarationHierarchy for BetaType

A subtype overrides an InstanceDeclarationby specifying an InstanceDeclarationwith the same BrowsePath. An overridden InstanceDeclarationshall have the same NodeClassand BrowseName. The TypeDefinitionNodeof the overridden InstanceDeclarationshall be the same or a subtype of the TypeDefinitionNodespecified in the supertype.

When overriding an InstanceDeclarationit is necessary to provide hierarchical Referencesthat link the new Nodeback to the subtype (the Referencesare used to determine the BrowsePathof the Node).

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

A Referenceis replaced if it goes between two overridden Nodesand has the same ReferenceTypeas a Referencedefined in the supertype. The Referencespecified in the subtype may be a subtype of the ReferenceTypeused in the parent type.

Any non-hierarchical Referencesspecified for the overridden InstanceDeclarationare treated as new Referencesunless the ReferenceTypeonly allows a single Referenceper SourceNode. If this situation exists the subtype can change the target of the Referencebut the new target shall have the same NodeClassand for Objectsand Variablesalso the same type or a subtype of the type specified in the parent.

The overriding Nodemay specify new values for the Node Attributesother than the NodeClassor BrowseName, however, the restrictions on Attributesspecified in 6.2.6apply. Any Attributeprovided by the overridden InstanceDeclarationhas to be provided by the overriding InstanceDeclaration, additional optional Attributesmay be added.

The ModellingRuleof the overriding InstanceDeclarationmay be changed as defined in 6.4.4.3.

Each overriding InstanceDeclarationneeds its own HasModellingRuleand HasTypeDefinition References, even if they have not been changed.

A subtype should not override a Nodeunless it needs to change it.

The semantics of certain TypeDefinitionNodesand ReferenceTypesmay impose additional restrictions with regard to overriding Nodes.