In the remainder of Clause 6 the type model of ObjectTypes and VariableTypes is defined regarding subtyping and instantiation.

An InstanceDeclaration is an Object, Variable or Method that references a ModellingRule with a HasModellingRule Reference and is the TargetNode of a hierarchical Reference from a TypeDefinitionNode or another InstanceDeclaration. There shall be no two TypeDefinitionNodes referencing the same InstanceDeclaration with a hierarchical Reference, either directly or from another InstanceDeclaration of that TypeDefinitionNode, i.e. an InstanceDeclaration belongs to exactly one TypeDefinitionNode.

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

If no ModellingRule exists then the Node is neither considered for instantiation of a type nor for subtyping.

If a Node referenced by a TypeDefinitionNode does not reference a ModellingRule it indicates that this Node only belongs to the TypeDefinitionNode and not to the instances. For example, an ObjectType Node may contain a Property that describes scenarios where the type could be used. This Property would 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 InstanceDeclarationHierarchy of a TypeDefinitionNode contains the TypeDefinitionNode and all InstanceDeclarations that are directly or indirectly referenced from the TypeDefinitionNode using forward hierarchical References.

A similar Node of an InstanceDeclaration is a Node that has the same BrowseName and NodeClass as the InstanceDeclaration and in cases of Variables and Objects the same TypeDefinitionNode or a subtype of it. In the case of a Method a similar Node of an InstanceDeclaration is a Node that also has the same arguments of the InstanceDeclaration, however it may append additional optional arguments and it may specialize the DataType of arguments defined with an abstract DataType to a subtype of the abstract DataType.

A BrowsePath is a sequence of BrowseNames used to describe a path between Nodes related w ith a Reference.

A BrowsePath within a TypeDefinitionNode which include targets of forward hierarchical References shall have a BrowseName that is unique within the TypeDefinitionNode, this same restriction applies to the targets of forward hierarchical References from any InstanceDeclaration. This means that any InstanceDeclaration within the InstanceDeclarationHierarchy can be uniquely identified by a sequence of BrowseNames.

Some restrictions exist regarding the Attributes of InstanceDeclarations when the InstanceDeclaration is overridden or instantiated. The BrowseName and the NodeClass shall never change and always be the same as the original InstanceDeclaration.

In addition, the rules defined in 6.2.8 apply for InstanceDeclarations of the NodeClass Variable.

Some restrictions exist regarding the Attributes of a VariableType or a Variable used as an InstanceDeclaration with regard to the data type of the Value Attribute.

When a Variable used as InstanceDeclaration or a VariableType is overridden or instantiated the following rules apply:

1. The DataType Attribute can only be changed to a new DataType if the new DataType is a subtype of the DataType originally used.
2. The ValueRank Attribute may 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 Attribute shall 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.

InstanceDeclarations are identified by their BrowsePath. Different Servers might use different NodeIds for the InstanceDeclarations of common TypeDefinitionNodes, unless the definition of the TypeDefinitionNode already defines a NodeId for the InstanceDeclaration. All TypeDefinitionNodes defined in OPC 10000-5 already define the NodeIds for their InstanceDeclarations and therefore shall be used in all Servers.

The HasSubtype ReferenceType defines subtypes of types. Subtyping can only occur between Nodes of the same NodeClass. Rules for subtyping ReferenceTypes are described in 5.3.3.3. There is no common definition for subtyping DataTypes, as described in 5.8.3. The remainder of 6.3 specify subtyping rules for single inheritance on ObjectTypes and VariableTypes.

Subtypes inherit the parent type’s Attribute values, except for the NodeId. Inherited Attribute values may be overridden by the subtype, the BrowseName and DisplayName values should be overridden. Special rules apply for some Attributes of VariableTypes as defined in 6.2.8. 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 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.

Any Instance of a TypeDefinitionNode will be the root of a hierarchy which mirrors the InstanceDeclarationHierarchy for the TypeDefinitionNode. Each Node in the hierarchy of the Instance will have a BrowsePath which may be the same as the BrowsePath for one of the InstanceDeclarations in the hierarchy of the TypeDefinitionNode. The InstanceDeclaration with the same BrowsePath is called the InstanceDeclaration for the Node. If a Node has an InstanceDeclaration then it shall have the same BrowseName and NodeClass as the InstanceDeclaration and, in cases of Variables and Objects, the same TypeDefinitionNode or a subtype of it.

Instances may reference several Nodes with the same BrowsePath. Clients that need to distinguish between the Nodes based on the InstanceDeclarationHierarchy and the Nodes that are not based on the InstanceDeclarationHierarchy can accomplish this using the TranslateBrowsePathsToNodeIds service defined in OPC 10000-4.

Instances inherit the initial values for the Attributes that they have in common with the TypeDefinitionNode from which they are instantiated, with the exceptions of the NodeClass and NodeId.

When a Server creates an instance of a TypeDefinitionNode it shall create the same hierarchy of Nodes beneath the new Object or Variable depending on the ModellingRule of each InstanceDeclaration. Standard ModellingRules are defined in 6.4.4.4. The Nodes within the newly created hierarchy may be copies of the InstanceDeclarations, the InstanceDeclaration itself or another Node in the AddressSpace that has the same TypeDefinitionNode and BrowseName. If new copies are created, then the Attribute values of the InstanceDeclarations are used as the initial values. An instance shall not be a SourceNode of a hierarchical Reference that has the same BrowsePath as an InstanceDeclaration of its TypeDefinition which has an optional or mandatory ModellingRule except for the one based on the InstanceDeclaration.

Figure 22 provides a simple example of a TypeDefinitionNode and an Instance. Nodes referenced by the TypeDefinitionNode without a ModellingRule do not appear in the instance. Instances may have children with duplicate BrowseNames; however, only one of those children will correspond to the InstanceDeclaration.

Figure 22 – An Instance and its TypeDefinitionNode

It is up to the Server to decide which InstanceDeclarations appear in any single instance. In some cases, the Server will not define the entire instance and will provide remote references to Nodes in another Server. The ModellingRules described in 6.4.4.4 allow Servers to indicate that some Nodes are always present; however, the Client shall be prepared for the case where the Node exists in a different Server.

A Client can use the information of TypeDefinitionNodes to access Nodes which are in the hierarchy of the instance. It shall pass the NodeId of the instance and the BrowsePath of the child Nodes based on the TypeDefinitionNode to the TranslateBrowsePathsToNodeIds service (see OPC 10000-4). This Service returns the NodeId for each of the child Nodes. If a child Node exists then the BrowseName and NodeClass shall match the InstanceDeclaration. In the case of Objects or Variables, also the TypeDefinitionNode shall either match or be a subtype of the original TypeDefinitionNode.

Objects and Variables may change their Attribute values after being created. Special rules apply for some Attributes as defined in 6.2.7.

Additional References may be added to the Nodes, and References may be deleted as long as the ModellingRules defined on the InstanceDeclarations of the TypeDefinitionNode are still fulfilled.

For Variables and Objects the HasTypeDefinition Reference shall always point to the same TypeDefinitionNode as the InstanceDeclaration or a subtype of it.

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

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. ModellingRules are an extendable concept in OPC UA; therefore, vendors may define their own ModellingRules.

Note that the ModellingRules defined in this standard do not define how to deal with NonHierarchical References between InstanceDeclarations, i.e. it is Server-specific if those References exist in an instance hierarchy or not. Other ModellingRules may define behaviour for NonHierarchical References between InstanceDeclaration as well.

ModellingRules are represented in the AddressSpace as Objects of the ObjectType ModellingRuleType. There are some Properties defining common semantic of ModellingRules. This edition of this standard only specifies one Property for ModellingRules. Future editions may define additional Properties for ModellingRules. OPC 10000-5 specifies the representation of the ModellingRule Objects, their Properties and their type in the AddressSpace.

Subclause 6.4.4.3 defines how the ModellingRule may be changed when instantiating InstanceDeclarations with respect to the Properties. Subclause 6.4.4.2 defines how the ModellingRule may be changed when overriding InstanceDeclarations in 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 20 specifies 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 InstanceDeclaration of another TypeDefinitionNode.

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

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

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 InstanceDeclarations of ‘A_Type’ initially maintain the same ModellingRule as their InstanceDeclarations. The ModellingRules may be updated; the allowed changes to the ModellingRules of these Nodes are the same as those defined for subtyping in 6.4.4.2.

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

Figure 25 – Example on changing InstanceDeclarations based on an InstanceDeclaration

An InstanceDeclaration marked with the ModellingRule Mandatory means that for each existing BrowsePath on the instance a similar Node shall exist, but it is not defined whether a new Node is created or an existing Node is referenced.

For example, the TypeDefinitionNode of 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 InstanceDeclaration SP1. Figure 26 illustrates the example.

Figure 26 – Use of the Standard ModellingRule Mandatory

In 6.4.4.4.2 a complex example combining the Mandatory and Optional ModellingRules is given.

An InstanceDeclaration marked with the ModellingRule Optional means that for each existing BrowsePath on the instance a similar Node may exist, but it is not defined whether a new Node is created or an existing Node is referenced.

In Figure 27 an example using the ModellingRules Optional and Mandatory is shown. The example contains an ObjectType Type_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 Node or two different Nodes with the same BrowseName (similar Node to InstanceDeclaration F). Not considered in the example is if the instances have ModellingRules or not. It is assumed that each F is similar to the InstanceDeclaration F, etc.

If there would be a NonHierarchical Reference between 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.

Figure 27 – Example using the Standard ModellingRules Optional and Mandatory

The ExposesItsArray ModellingRule exposes a special semantic on VariableTypes having a single- or multidimensional array as the data type. It indicates that each value of the array will also be exposed as a Variable in the AddressSpace.

The ExposesItsArray ModellingRule can only be applied on InstanceDeclarations of NodeClass Variable that are part of a VariableType having a single- or multidimensional array as its data type.

The Variable A having this ModellingRule shall be referenced by a forward hierarchical Reference from a VariableType B. B shall have a ValueRank value 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 Reference shall be of the same type as the hierarchical Reference that connects B with A or a subtype of it. If there are more than one forward hierarchical References between A and B, then all instances based on B shall be referenced with all those References.

Figure 28 gives 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 InstanceDeclaration ArrayExpose. The BrowseNames of those instances are not defined by the ModellingRule. In general, it is not possible to get a Variable representing a specific entry in the array (e.g. the second). Clients will typically either get the array or access the Variables directly, so there is no need to provide that information.

Figure 28 – Example on using ExposesItsArray

It is allowed to reference A by other InstanceDeclarations as well. Those References have to be reflected on each instance based on A.

Figure 29 gives an example. The Property EUUnit is referenced by ArrayExpose and therefore each instance based on ArrayExpose references the instance based on the InstanceDeclaration EUUnit.

Figure 29 – Complex example on using ExposesItsArray

For Object and Variable the intention of the ModellingRule OptionalPlaceholder is to expose the information that a complex TypeDefinition expects from instances of the TypeDefinition to add instances with specific References without defining BrowseNames for 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.

Figure 30 – Example using OptionalPlaceholder with an Object and Variable

The ModellingRule OptionalPlaceholder adds no additional constraints on instances of the TypeDefinition. It just provides useful information when exposing a TypeDefinition. When the InstanceDeclaration is complex, i.e. it references other InstanceDeclarations with hierarchical References, these InstanceDeclarations are not further considered for instantiating the TypeDefinition.

It is recommended that the BrowseName and the DisplayName of InstanceDeclarations having the OptionalPlaceholder ModellingRule should be enclosed within angle brackets.

When overriding the InstanceDeclaration, the ModellingRule shall remain OptionalPlaceholder.

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

Figure 31 – Example using OptionalPlaceholder with a Method

For Object and Variable the ModellingRule MandatoryPlaceholder has a similar intention as the ModellingRule OptionalPlaceholder. It exposes the information that a TypeDefinition expects of instances of the TypeDefinition to add instances defined by the InstanceDeclaration. However, MandatoryPlaceholder requires 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 BrowseName for it, it uses MandatoryPlaceholder as 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 ReferenceType to reference a DeviceParameter (Organizes instead of HasComponent) and Device C is not valid because it does not provide a DeviceParameter at all.

Figure 32 – Example on using MandatoryPlaceholder for Object and Variable

The ModellingRule MandatoryPlaceholder requires that each instance provides at least one instance with the TypeDefinition of the InstanceDeclaration or a subtype, and is referenced with the same ReferenceType or a subtype as the InstanceDeclaration. It does not require a specific BrowseName and thus cannot be used for the TranslateBrowsePathsToNodeIds Service (see OPC 10000-4).

When the InstanceDeclaration is complex, i.e. it references other InstanceDeclarations with hierarchical References, these InstanceDeclarations are not further considered for instantiating the TypeDefinition.

It is recommended that the BrowseName and the DisplayName of InstanceDeclarations having the MandatoryPlaceholder ModellingRule should be enclosed within angle brackets.

When overriding the InstanceDeclaration, the ModellingRule shall remain MandatoryPlaceholder.

For Methods, the ModellingRule MandatoryPlaceholder is used to define the BrowseName where subtypes and instances provide more information. The Method definition with the MandatoryPlaceholder only defines the BrowseName. An instance or subtype defines the InputArguments and OutputArguments. A subtype shall also change the ModellingRule to Mandatory. The Method is mandatory for instances.

There is no behaviour specified regarding subtypes and instances when changing ObjectTypes and 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 Property using the ModellingRule Mandatory on a type if instances of this type exist without the Property. In that case, the Server either has to add the Property to all instances of the type or adding the Property on the type has to be rejected.