Errata exists for this version of the document.

For a definition of ModellingRules, see 6.4.4.5. 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 non-hierarchical 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 non-hierarchical 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. The semantic of the Properties for ModellingRules is defined in 6.4.4.2.

Subclause 6.4.4.4 defines how the ModellingRule may be changed when instantiating InstanceDeclarations with respect to the Properties. Subclause 6.4.4.3 defines how the ModellingRule may be changed when overriding InstanceDeclarations in subtypes with respect to the Properties.

NamingRule is a mandatory Property of a ModellingRule. It specifies the purpose of an InstanceDeclaration. Each InstanceDeclaration references a ModellingRule and thus the NamingRule is defined per InstanceDeclaration.

Three values are allowed for the NamingRule of a ModellingRule: Optional, Mandatory, and Constraint.

The following semantic is valid for the entire life-time of an instance that is based on a TypeDefinitionNode having an InstanceDeclaration.

For an instance A1 of a TypeDefinitionNode AlphaType with an InstanceDeclaration B1 having a ModellingRule using the NamingRule Optional the following rule applies: For each BrowsePath from AlphaType to B1 the instance A1 may or may not have a similar Node (see 6.2.4) for B1 with the same BrowsePath. If such a Node exists then the TranslateBrowsePathsToNodeIds Service (see OPC 10000-4) returns this Node as the first entry in the list.

For an instance A1 of a TypeDefinitionNode AlphaType with an InstanceDeclaration B1 having a ModellingRule using the NamingRule Mandatory the following rule applies: For each BrowsePath from AlphaType to B1 the instance A1 shall have a similar Node (see 6.2.4) for B1 using the same BrowsePath if all Nodes of the BrowsePath exist. For example, if a Node in the BrowsePath has a NamingRule Optional and is omitted in the instance, then all children of this Node would also be omitted, independent of their ModellingRules.

If an InstanceDeclaration has a ModellingRule using the NamingRule Constraint it identifies that the BrowseName of the InstanceDeclaration is of no significance but other semantic is defined with the ModellingRule. The TranslateBrowsePathsToNodeIds Service (see OPC 10000-4) can typically not be used to access instances based on those InstanceDeclarations.

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 name (NamingRule Mandatory) and on the subtype make this optional (NamingRule Optional). Table 20 specifies the allowed changes on the Properties when exchanging the ModellingRules in the subtype.

Table 20 – Rule for ModellingRules Properties when Subtyping

	Value on supertype	Value on subtype
NamingRule	Mandatory	Mandatory
NamingRule	Optional	Mandatory or Optional
NamingRule	Constraint	Constraint

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 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 17 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 17 – 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.3.

In Figure 18 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 18 – Example on changing InstanceDeclarations based on an InstanceDeclaration

The remainder of 6.4.4.5 defines ModellingRules. In Table 21 the Properties of those ModellingRules are summarized.

Table 21 – Properties of ModellingRules

Title	NamingRule
Mandatory	Mandatory
Optional	Optional
ExposesItsArray	Constraint
OptionalPlaceholder	Constraint
MandatoryPlaceholder	Constraint

An InstanceDeclaration marked with the ModellingRule Mandatory fulfils exactly the semantic defined for the NamingRule Mandatory. That 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 19 illustrates the example.

Figure 19 – Use of the Standard ModellingRule Mandatory

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

An InstanceDeclaration marked with the ModellingRule Optional fulfils exactly the semantic defined for the NamingRule Optional. That 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 20 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 non-hierarchical 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 20 – 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 21 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 21 – 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 22 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 22 – 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 23, where an instance Device A adds two DeviceParameters in the Folder.

Figure 23 – 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 24.

Figure 24 – 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 25. 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 25 – 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.