In the remainder of Clause 6the type model of ObjectTypesand VariableTypesis defined regarding subtyping and instantiation.

An InstanceDeclarationis an Object, Variableor Methodthat references a ModellingRulewith a HasModellingRule Referenceand is the TargetNodeof a hierarchical Referencefrom a TypeDefinitionNodeor another InstanceDeclaration. There shall be no two TypeDefinitionNodesreferencing the same InstanceDeclarationwith a hierarchical Reference, either directly or from another InstanceDeclarationof that TypeDefinitionNode, i.e. an InstanceDeclarationbelongs to exactly one TypeDefinitionNode.

The type of an InstanceDeclarationmay be abstract, however the instance must be of a concrete type.

If no ModellingRuleexists then the Nodeis neither considered for instantiation of a type nor for subtyping.

If a Nodereferenced by a TypeDefinitionNodedoes not reference a ModellingRuleit indicates that this Nodeonly belongs to the TypeDefinitionNodeand not to the instances. For example, an ObjectType Nodemay contain a Propertythat describes scenarios where the type could be used. This Propertywould not be considered when creating instances of the type. This is also true for subtyping, that is, subtypes of the type definition would not inherit the referenced Node.

The InstanceDeclarationHierarchyof a TypeDefinitionNodecontains the TypeDefinitionNodeand all InstanceDeclarationsthat are directly or indirectly referenced from the TypeDefinitionNodeusing forward hierarchical References.

A similar Nodeof an InstanceDeclarationis a Nodethat has the same BrowseNameand NodeClassas the InstanceDeclarationand in cases of Variablesand Objectsthe same TypeDefinitionNodeor a subtype of it. In the case of a Methoda similar Nodeof an InstanceDeclarationis a Nodethat also has the same arguments of the InstanceDeclaration, however it may append additional optional arguments and it may specialize the DataTypeof arguments defined with an abstract DataTypeto a subtype of the abstract DataType.

All targets of forward hierarchical Referencesfrom a TypeDefinitionNodeshall have a BrowseNamethat is unique within the TypeDefinitionNode. The same restriction applies to the targets of forward hierarchical Referencesfrom any InstanceDeclaration. This means that any InstanceDeclarationwithin the InstanceDeclarationHierarchycan be uniquely identified by a sequence of BrowseNames. This sequence of BrowseNamesis called a BrowsePath.

Some restrictions exist regarding the Attributesof InstanceDeclarationswhen the InstanceDeclarationis overridden or instantiated. The BrowseNameand the NodeClassshall never change and always be the same as the original InstanceDeclaration.

In addition, the rules defined in 6.2.7apply for InstanceDeclarationsof the NodeClass Variable.

Some restrictions exist regarding the Attributesof a VariableTypeor a Variableused as an InstanceDeclarationwith regard to the data type of the Value Attribute.

When a Variableused as InstanceDeclarationor a VariableTypeis overridden or instantiated the following rules apply:

  1. The DataType Attribute can only be changed to a new DataTypeif the new DataTypeis a subtype of the DataTypeoriginally used.
  2. The ValueRank Attributemay only be further restricted
  3. ‘Any’ may be set to any other value;
  4. ‘ScalarOrOneDimension’ may be set to ‘Scalar’ or ‘OneDimension’;
  5. ‘OneOrMoreDimensions’ may be set to a concrete number of dimensions (value > 0).
  6. All other values of this Attributeshall not be changed.
  7. The ArrayDimensions Attribute may be added if it was not provided or when modifying the value of an entry in the array from 0 to a different value. All other values in the array shall remain the same.

InstanceDeclarationsare identified by their BrowsePath. Different Serversmight use different NodeIdsfor the InstanceDeclarationsof common TypeDefinitionNodes, unless the definition of the TypeDefinitionNodealready defines a NodeIdfor the InstanceDeclaration. All TypeDefinitionNodesdefined in OPC 10000-5already define the NodeIdsfor their InstanceDeclarationsand therefore shall be used in all Servers.

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 InstanceDeclarationHierarchyof 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 20which specifies a TypeDefinitionNode“BetaType” which is a subtype of “AlphaType”. The name in each box is the BrowseNameand the number is the NodeId.

image023.png

Figure 20– 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 NonHierarchical 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

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 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

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 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 21. The fully-inherited InstanceDeclarationHierarchycontains all necessary information about a TypeDefinitionNoderegarding its complex structure without needing any additional information from its supertypes.

image024.png

Figure 21– 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 21, 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 NonHierarchical 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.

A subtype shall not override an argument of its supertype’s Method InstanceDeclaration whichis defined with a concreteDataType. Method arguments defined with an abstractDataType 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 ModellingRuleof the overriding InstanceDeclarationmay be changed as defined in 6.4.4.2.

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.

Any Instanceof a TypeDefinitionNodewill be the root of a hierarchy which mirrors the InstanceDeclarationHierarchyfor the TypeDefinitionNode.Each Nodein the hierarchy of the Instance will have a BrowsePathwhich may be the same as the BrowsePathfor one of the InstanceDeclarationsin the hierarchy of the TypeDefinitionNode. The InstanceDeclarationwith the same BrowsePathis called the InstanceDeclarationfor the Node. If a Nodehas an InstanceDeclarationthen it shall have the same BrowseNameand NodeClassas the InstanceDeclarationand, in cases of Variablesand Objects, the same TypeDefinitionNodeor a subtype of it.

Instances may reference several Nodeswith the same BrowsePath. Clientsthat need to distinguish between the Nodesbased on the InstanceDeclarationHierarchyand the Nodesthat are not based on the InstanceDeclarationHierarchycan accomplish this using the TranslateBrowsePathsToNodeIds service defined in OPC 10000-4.

Instances inherit the initial values for the Attributesthat they have in common with the TypeDefinitionNodefrom which they are instantiated, with the exceptions of the NodeClassand NodeId.

When a Servercreates an instance of a TypeDefinitionNodeit shall create the same hierarchy of Nodes beneath the new Objector Variable depending on the ModellingRuleof each InstanceDeclaration. Standard ModellingRulesare defined in 6.4.4.4. The Nodes within the newly created hierarchy may be copies of the InstanceDeclarations, the InstanceDeclarationitself or another Nodein the AddressSpacethat has the same TypeDefinitionNodeand BrowseName. If new copies are created, then the Attributevalues of the InstanceDeclarationsare used as the initial values. An instance shall not be a SourceNodeof a hierarchical Referencethat has the same BrowsePathas an InstanceDeclarationof its TypeDefinitionwhich has an optional or mandatory ModellingRuleexcept for the one based on the InstanceDeclaration.

Figure 22provides a simple example of a TypeDefinitionNodeand an Instance. Nodesreferenced by the TypeDefinitionNodewithout a ModellingRuledo not appear in the instance. Instancesmay have children with duplicate BrowseNames; however, only one of those children will correspond to the InstanceDeclaration.

image025.png

Figure 22– An Instance and its TypeDefinitionNode

It is up to the Serverto decide which InstanceDeclarationsappear in any single instance. In some cases, the Serverwill not define the entire instance and will provide remote references to Nodesin another Server. The ModellingRulesdescribed in 6.4.4.4allow Serversto indicate that some Nodesare always present; however, the Clientshall be prepared for the case where the Nodeexists in a different Server.

A Clientcan use the information of TypeDefinitionNodesto access Nodes which are in the hierarchy of the instance. It shall pass the NodeIdof the instance and the BrowsePathof the child Nodes based on the TypeDefinitionNodeto the TranslateBrowsePathsToNodeIdsservice (see OPC 10000-4). This Servicereturns the NodeIdfor each of the child Nodes. If a child Nodeexists then the BrowseNameand NodeClassshall match the InstanceDeclaration. In the case of Objectsor Variables,also the TypeDefinitionNodeshall either match or be a subtype of the original TypeDefinitionNode.

Objectsand Variablesmay change their Attributevalues after being created. Special rules apply for some Attributesas defined in 6.2.6.

Additional Referencesmay be added to the Nodes, and Referencesmay be deleted as long as the ModellingRulesdefined on the InstanceDeclarationsof the TypeDefinitionNodeare still fulfilled.

For Variablesand Objectsthe HasTypeDefinition Referenceshall always point to the same TypeDefinitionNodeas the InstanceDeclarationor a subtype of it.

If two InstanceDeclarationsof the fully-inherited InstanceDeclarationHierarchyhave been connected directly with several References, all those Referencesshall connect the same Nodes. An example is given in Figure 23. The instances A1 and A2 are allowed since B1 references the same Nodewith both References, whereas A3 is not allowed since two different Nodesare referenced. Note that this restriction only applies for directly connected Nodes. For example, A2 references a C1 directly and a different C1 via B1.

image026.png

Figure 23– Example for several References between InstanceDeclarations

For a definition of ModellingRules, see 6.4.4.4. Other parts of this series of standards may define additional ModellingRules. ModellingRulesare an extendable concept in OPC UA; therefore, vendors may define their own ModellingRules.

Note that the ModellingRulesdefined in this standard do not define how to deal with NonHierarchical Referencesbetween InstanceDeclarations, i.e. it is Server-specific if those Referencesexist in an instance hierarchy or not. Other ModellingRulesmay define behaviour for NonHierarchical Referencesbetween InstanceDeclarationas well.

ModellingRulesare represented in the AddressSpaceas Objectsof the ObjectType ModellingRuleType. There are some Propertiesdefining common semantic of ModellingRules.This edition of this standard only specifies one Propertyfor ModellingRules. Future editions may define additional Propertiesfor ModellingRules. OPC 10000-5specifies the representation of the ModellingRule Objects, their Propertiesand their type in the AddressSpace.

Subclause 6.4.4.3defines how the ModellingRulemay be changed when instantiating InstanceDeclarationswith respect to the Properties. Subclause 6.4.4.2defines how the ModellingRulemay be changed when overriding InstanceDeclarationsin subtypes with respect to the Properties.

It is allowed that subtypes override ModellingRules on their InstanceDeclarations. As a general rule for subtyping, constraints shall only be tightened, not loosened. Therefore, it is not allowed to specify on the supertype that an instance shall exist with the ModellingRule Mandatory and on the subtype make this ModellingRule Optional. Table 20specifies the allowed changes on the Properties when overriding the ModellingRules in the subtype.

Table 20– Rule for ModellingRules Properties when Subtyping

ModellingRule on supertype

ModellingRule on subtype

Mandatory

Mandatory

Optional

Mandatory or Optional

MandatoryPlaceholder

MandatoryPlaceholder

OptionalPlaceholder

MandatoryPlaceholder or OptionalPlaceholder

There are two different use cases when creating an instance ‘A’ based on a TypeDefinitionNode‘A_Type’. Either ‘A’ is used as normal instance or it is used as an InstanceDeclarationof another TypeDefinitionNode.

In the first case, it is not required that newly created or referenced instances based on InstanceDeclarationshave a ModellingRule, however, it is allowed that they have any ModellingRuleindependent of the ModellingRuleof their InstanceDeclaration.

In Figure 24an example is given. The instances A1, A2, and A3 are all valid instances of Type_A, although B of A1 has no ModellingRuleand B of A3 has a different ModellingRulethan B of Type_A.

image027.png

Figure 24– Example on changing instances based on InstanceDeclarations

In the second case, all instances that are referenced directly or indirectly from ‘A’ based on InstanceDeclarationsof ‘A_Type’ initially maintain the same ModellingRuleas their InstanceDeclarations.The ModellingRulesmay be updated; the allowed changes to the ModellingRulesof these Nodes are the same as those defined for subtyping in 6.4.4.2.

In Figure 25an example of such a scenario is given. Type_B uses an InstanceDeclarationbased on Type_A (upper part of the Figure). Later on the ModellingRuleof the InstanceDeclaration A1 is changed (lower part of the Figure). A1 has become the NamingRuleof Mandatory(changed from Optional).

image028.png

Figure 25– Example on changing InstanceDeclarations based on an InstanceDeclaration

An InstanceDeclarationmarked with the ModellingRule Mandatorymeans that for each existing BrowsePathon the instance a similar Nodeshall exist, but it is not defined whether a new Nodeis created or an existing Nodeis referenced.

For example, the TypeDefinitionNodeof a functional block “AI_BLK_TYPE” will have a setpoint “SP1”. An instance of this type “AI_BLK_1” will have a newly-created setpoint “SP1” as a similar Node to the InstanceDeclarationSP1. Figure 26illustrates the example.

image029.png

Figure 26– Use of the Standard ModellingRule Mandatory

In 6.4.4.4.2a complex example combining the Mandatoryand Optional ModellingRulesis given.

An InstanceDeclarationmarked with the ModellingRule Optionalmeans that for each existing BrowsePathon the instance a similar Nodemay exist, but it is not defined whether a new Nodeis created or an existing Nodeis referenced.

In Figure 27an example using the ModellingRules Optionaland Mandatoryis shown. The example contains an ObjectTypeType_A and all valid combinations of instances named A1 to A13. Note that if the optional B is provided, the mandatory E has to be provided as well, otherwise not. F is referenced by C and D. On the instance, this can be the same Nodeor two different Nodeswith the same BrowseName(similar Nodeto InstanceDeclarationF). Not considered in the example is if the instances have ModellingRulesor not. It is assumed that each F is similar to the InstanceDeclarationF, etc.

If there would be a NonHierarchical Referencebetween E and F in the InstanceDeclarationHierarchy, it is not specified if it occurs in the instance hierarchy or not. In the case of A10, there could be a reference from E to one F but not to the other F, or to both or none of them.

image030.png

Figure 27– Example using the Standard ModellingRules Optional and Mandatory

The ExposesItsArray ModellingRuleexposes a special semantic on VariableTypeshaving a single- or multidimensional array as the data type. It indicates that each value of the array will also be exposed as a Variablein the AddressSpace.

The ExposesItsArray ModellingRulecan only be applied on InstanceDeclarationsof NodeClass Variablethat are part of a VariableTypehaving a single- or multidimensional array as its data type.

The VariableA having this ModellingRuleshall be referenced by a forward hierarchical Referencefrom a VariableType B. B shall have a ValueRankvalue that is equal to or larger than zero. A should have a data type that reflects at least parts of the data that is managed in the array of B. Each instance of B shall reference one instance of A for each of its array elements. The used Referenceshall be of the same type as the hierarchical Referencethat connects B with A or a subtype of it. If there are more than one forward hierarchical Referencesbetween A and B, then all instances based on B shall be referenced with all those References.

Figure 28gives an example. A is an instance of Type_A having two entries in its value array. Therefore it references two instances of the same type as the InstanceDeclarationArrayExpose. The BrowseNamesof those instances are not defined by the ModellingRule. In general, it is not possible to get a Variablerepresenting a specific entry in the array (e.g. the second). Clientswill typically either get the array or access the Variablesdirectly, so there is no need to provide that information.

image031.png

Figure 28– Example on using ExposesItsArray

It is allowed to reference A by other InstanceDeclarationsas well. Those Referenceshave to be reflected on each instance based on A.

Figure 29gives an example. The PropertyEUUnit is referenced by ArrayExpose and therefore each instance based on ArrayExpose references the instance based on the InstanceDeclarationEUUnit.

image032.png

Figure 29– Complex example on using ExposesItsArray

For Objectand Variablethe intention of the ModellingRule OptionalPlaceholderis to expose the information that a complex TypeDefinitionexpects from instances of the TypeDefinitionto add instances with specific Referenceswithout defining BrowseNamesfor the instances. For example, a Device might have a Folder for DeviceParameters, and the DeviceParameters should be connected with a HasComponent Reference. However, the names of the DeviceParameters are specific to the instances. The example is shown in Figure 30, where an instance Device A adds two DeviceParameters in the Folder.

image033.png

Figure 30– Example using OptionalPlaceholder with an Object and Variable

The ModellingRule OptionalPlaceholderadds no additional constraints on instances of the TypeDefinition. It just provides useful information when exposing a TypeDefinition. When the InstanceDeclarationis complex, i.e. it references other InstanceDeclarationswith hierarchicalReferences, these InstanceDeclarationsare not further considered for instantiating the TypeDefinition.

It is recommended that the BrowseNameand the DisplayNameof InstanceDeclarationshaving the OptionalPlaceholder ModellingRule shouldbe enclosed within angle brackets.

When overriding the InstanceDeclaration, the ModellingRuleshall remain OptionalPlaceholder.

For Methods,the ModellingRule OptionalPlaceholder is used to define the BrowseNamewhere subtypes and instances provide more information. The Method definition with the OptionalPlaceholder only defines the BrowseName. Aninstance or subtype defines the InputArgumentsand OutputArguments. A subtype shall also change the ModellingRuleto Optionalor Mandatory. The Methodis optional for instances.For example, a Device might have a Methodto perform calibration however the specific arguments for the Methoddepend on the instance of the Device. In this example Device A does not implement the Method, Device B implements the Methodwith no arguments and Device C implements the Methodaccepting a mode argument to select how the calibration is to be performed. The example is shown in Figure 31.

image034.png

Figure 31– Example using OptionalPlaceholder with a Method

For Objectand Variablethe ModellingRule MandatoryPlaceholderhas a similar intention as the ModellingRule OptionalPlaceholder. It exposes the information that a TypeDefinitionexpects of instances of the TypeDefinitionto add instances defined by the InstanceDeclaration. However, MandatoryPlaceholderrequires that at least one of those instances shall exist.

For example, when the DeviceType requires that at least one DeviceParameter shall exist without specifying the BrowseNamefor it, it uses MandatoryPlaceholderas shown in Figure 32. Device A is a valid instance as it has the required DeviceParameter. Device B is not valid as it uses the wrong ReferenceTypeto reference a DeviceParameter (Organizesinstead of HasComponent) and Device C is not valid because it does not provide a DeviceParameter at all.

image035.png

Figure 32– Example on using MandatoryPlaceholder for Object and Variable

The ModellingRule MandatoryPlaceholderrequires that each instance provides at least one instance with the TypeDefinitionof the InstanceDeclarationor a subtype, and is referenced with the same ReferenceTypeor a subtype as the InstanceDeclaration. It does not require a specific BrowseNameand thus cannot be used for the TranslateBrowsePathsToNodeIds Service(see OPC 10000-4).

When the InstanceDeclarationis complex, i.e. it references other InstanceDeclarationswith hierarchicalReferences, these InstanceDeclarationsare not further considered for instantiating the TypeDefinition.

It is recommended that the BrowseNameand the DisplayNameof InstanceDeclarationshaving the MandatoryPlaceholder ModellingRule should be enclosed within angle brackets.

When overriding the InstanceDeclaration, the ModellingRuleshall remain MandatoryPlaceholder.

For Methods,the ModellingRule MandatoryPlaceholder is used to define the BrowseNamewhere subtypes and instances provide more information. The Method definition with the MandatoryPlaceholder only defines the BrowseName. Aninstance or subtype defines the InputArgumentsand OutputArguments. A subtype shall also change the ModellingRuleto Mandatory. The Methodis mandatory for instances.

There is no behaviour specified regarding subtypes and instances when changing ObjectTypesand VariableTypes. It is Server-dependent, if those changes are reflected on the subtypes and instances of the types. However, all constraints defined for subtypes and instances have to be fulfilled. For example, it is not allowed to add a Propertyusing the ModellingRule Mandatoryon a type if instances of this type exist without the Property. In that case, the Servereither has to add the Propertyto all instances of the type or adding the Propertyon the type has to be rejected.