For a definition of ModellingRules, see 6.4.4.5. 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 non-hierarchical Referencesbetween InstanceDeclarations, i.e. it is Server-specific if those Referencesexist in an instance hierarchy or not. Other ModellingRulesmay define behaviour for non-hierarchical 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. The semantic of the Propertiesfor ModellingRulesis defined in 6.4.4.2.

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

NamingRuleis a mandatory Propertyof a ModellingRule. It specifies the purpose of an InstanceDeclaration. Each InstanceDeclarationreferences a ModellingRuleand thus the NamingRuleis defined per InstanceDeclaration.

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

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

For an instance A1 of a TypeDefinitionNodeAlphaType with an InstanceDeclarationB1 having a ModellingRuleusing the NamingRule Optional the following rule applies: For each BrowsePathfrom 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 Nodeexists then the TranslateBrowsePathsToNodeIds Service(see OPC 10000-4) returns this Nodeas the first entry in the list.

For an instance A1 of a TypeDefinitionNodeAlphaType with an InstanceDeclarationB1 having a ModellingRuleusing the NamingRule Mandatory the following rule applies: For each BrowsePathfrom AlphaType to B1 the instance A1 shall have a similar Node(see 6.2.4) for B1 using the same BrowsePathif all Nodesof the BrowsePathexist. For example, if a Nodein the BrowsePathhas a NamingRule Optionaland is omitted in the instance, then all children of this Nodewould also be omitted, independent of their ModellingRules.

If an InstanceDeclarationhas a ModellingRuleusing the NamingRule Constraintit identifies that the BrowseNameof the InstanceDeclarationis 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 ModellingRuleson 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 20specifies the allowed changes on the Propertieswhen exchanging the ModellingRulesin 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 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 17an 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.

image020.png

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

In Figure 18an 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).

image021.png

Figure 18– Example on changing InstanceDeclarations based on an InstanceDeclaration

The remainder of 6.4.4.5defines ModellingRules. In Table 21the Propertiesof those ModellingRulesare summarized.

Table 21– Properties of ModellingRules

Title

NamingRule

Mandatory

Mandatory

Optional

Optional

ExposesItsArray

Constraint

OptionalPlaceholder

Constraint

MandatoryPlaceholder

Constraint

An InstanceDeclarationmarked with the ModellingRule Mandatoryfulfils exactly the semantic defined for the NamingRule Mandatory. That means 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 19illustrates the example.

image022.png

Figure 19– Use of the Standard ModellingRule Mandatory

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

An InstanceDeclarationmarked with the ModellingRule Optionalfulfils exactly the semantic defined for the NamingRule Optional. That means 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 20an 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 non-hierarchical 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.

image023.png

Figure 20– 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 21gives 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.

image024.png

Figure 21– 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 22gives an example. The PropertyEUUnit is referenced by ArrayExpose and therefore each instance based on ArrayExpose references the instance based on the InstanceDeclarationEUUnit.

image025.png

Figure 22– 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 23, where an instance Device A adds two DeviceParameters in the Folder.

image026.png

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

image027.png

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

image028.png

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