Behavior of objects with HasModellingRule = "None"

[bitctrl]

Hello
We have a question concerning the behavior of Objects with no ModellingRule (Modelling Rule = „None“ in earlier specs) in UaModeler (v1.4.2).

Following situation:
It’s allowed to add an additional component (Object, Variable, Method) to an existing instance, which is not derived from the TypeDefinition of the instance, please refer to the OPC UA specs part 3, chapter 5.5.4 and 5.6.6. In this case it’s not permitted, that the added component contains a “HasModellingRule” reference. Internally at BitCtrl we call such components “wild” InstanceMembers, which are independent from the TypeDefinitionNode. Perhaps, “individual” or “independent” InstanceMember are better words instead of “wild” ?

This situation is valid for “real” instances (i.e., instances not having a subtype of “IsAggregatedFrom” reference = inverse reference subtype of “Aggregates”) and for InstanceDeclarations as well.

But what’s about a folder object with a FolderType TypeDefinition?

If a folder is an InstanceMember in an InstanceDeclaration, e.g. “Root -> Types -> ObjectTypes -> BaseObjectType -> ServerCapabilitiesType -> AggregateFunctions”, then in UaModeler it’s possible to add a “wild” InstanceMember with any ModellingRule other than “None”. Thereafter, the added component of the InstanceDeclaration is immediately derived to the corresponding instance, i.e. in our case to “Root -> Objects -> Server -> ServerCapabilities -> AggregateFunctions -> wildInstanceMember”.

Is this behavior allowed or is it a bug? Where we can find the rules about that behavior in the specs?

TIA
bitctrl

[Support Team]

It is allowed to add these "wild" instance members. E.g. in DI model there is the TopologyElementType defining the instance declaration ParameterSet (BaseObjectType). This is Object can be used to add "wild" Variables.
Note: There can be problems with the generated code if "wild" instances are used. And you should not add "wild" instances to nodes from another namespace.

[bitctrl]

Thank you for the answer. This is all correct what you write. But this was not our question. We want to know about the right “ModellingRule” in case of a “wild” instance member. Please, refer to the example above.

TIA
bitctrl

[Support Team]

You can use the same ModellingRules for "wild" instace declarations than for "normal" instance declarations.

[bitctrl]

I disagree, because the behavior in UaModeler is different.

Example:
The “Server” object (NodeId=”i=2253”) is a part of the standard NodeSet2.xml and it’s generated in the UaModeler in the Objects tree.
In the “Children” sub-window in UaModeler you are able to add a “wild” instance member to the “Server” object, e.g.

NodeClass: Variable
Name: wildInstanceMember
Typedefinition: PopertyType
ModellingRule: No ModelingRule
DataType: String
Add: green plus
Delete: red x

But, it’s impossible to change the ModellingRule here, like you described.

Furthermore, the “Server” object contains the component “ServerConfiguration”, which was generated from the standard NodeSet2.xml,

NodeClass: Object
Name: ServerConfiguration
Typedefinition: ServerConfigurationType
ModellingRule: No ModelingRule
DataType:
Add: green plus
Delete: grey x

which is not derived from “ServerType” and which represents also a “wild” instance member with No ModellingRule. It’s impossible to change the ModellingRule in this case too.

But in case if an object is a Folder, derived from the type definition FolderType, than your explanation becomes true. I have illustrated the corresponding example in the first email.

Conclusion: The inheritance behavior of the components of a Folder object and a non Folder object is different. I expected, it should be the same. I didn’t find anything about this behavior in the specs.

TIA
bitctrl

[Support Team]

You are right that it is possible to set ModellingRules for some "wild" instances and it ist not possible to set ModellingRules for other "wild" instances. But the different behavior is not a result of the TypeDefinition of the parent node.

You can add ModellingRules to nodes located in the Types folder (e.g. ServerCapabilitiesType -> AggregateFunctions). But you are not able to add modelling rules to nodes located in the Objects folder. The ModellingRules that are displayed here are the ModellingRules of the instance declaration nodes.

[bitctrl]

Thank you very much for your explanation. But it seems, that it’s possible to bypass these rules. Your approach contains a little inconsistency in the UaModeler. Let’s give you an example, written in pseudo-code. You can try it by yourself:

Code: Select all

BaseObjectType	HasSubtype		_test_type

_test_type		HasComponent	_test_instances
_test_instances	HasTypeDefinition	FolderType	// Folder as a component in a type
_test_instances	HasModellingRule	None

_test_type		HasProperty		_test_variable	// InstanceDeclaration
_test_variable		HasDataType		String
_test_variable		HasModellingRule	Mandatory

ti01			HasTypeDefinition	_test_type	// Instance derivation
_test_instances	Organizes		ti01		// Instance is docked in a folder in the Types hierarchie

ti01			HasProperty		wild_member	// “wild” InstanceMember
wild_member		HasModellingRule	Mandatory

Objects			Organizes		ti01		// Instance is docked in the global Objects Folder

And now, look what for a ModellingRule has the “wild_member” in the “ti01” object under the Objects Folder:
It’s “Mandatory”. And you can change this to "Optional", if you like.

Excuse me please for the formatting mismatch in the pseudo-code table.

TIA
bitctrl