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