

22:29, EEST

August 5, 2025

I am testing the function `NodeManager.createInstance` to create an Object node with all its child nodes in the NodeManager.
The problem is that, while most of the child nodes are correctly created (and using a NodeId which looks like “ns=5;s=3/4:MachineInformation/2:DeviceClass”), the method child nodes (and subsequently their child nodes) are created with NodeId with namespace equal to the namespace of the ObjectTypeDefinition that defines the Object node I am creating (looking like “ns=4;i=7005”, where ns=4 corresponds to the ObjectTypeDefinition used namespace).
I am using the following overload of `createInstance`:
UaInstance com.prosysopc.ua.server.NodeManagerUaNode.createInstance(NodeId arg0, NodeId arg1, QualifiedName arg2, LocalizedText arg3)
11:04, EEST

April 3, 2012

Hi,
Method nodes by default are not instantiated, but instead the Reference just points to the Method node already existing in the TypeDefinition. In most cases Method nodes have not had any differences per instance. If you need to have unique method nodes per instance, you can set:
TypeDefinitionBasedNodeBuilderConfiguration.builder(MethodInstantiationLogic.UNIQUE).build();
via
NodeManagerUaNode.setNodeBuilderConfiguration(UaNodeBuilderConfiguration)
Then it will affect all createInstance’s for that NodeManagerUaNode. Alternatively you can use the .createNodeBuilder overloads taking the configuration as parameter for it to just apply to a single instantiation/NodeBuilder. Or you can set it on the NodeManagerTable to affect the whole server.
22:49, EEST

August 5, 2025

Thanks! That solved it.
Nevertheless, I see that method nodes created under `MethodInstantiationLogic.UNIQUE` do not replicate the node in the TypeDefinition perfectly: properties which appear with `ModellingRule.Mandatory` in the “original” method node, do not have a `HasModellingRule` reference in the newly created instance.
As an example, I am evaluating the creation of `SetMESMessage` Method (https://github.com/OPCFoundati…..deSet2.xml) as a component of `MachineMESStatus` with `MethodInstantiationLogic.UNIQUE` compared to `MethodInstantiationLogic.SHARED`. With `SHARED` everything looks well, as it is only referencing the method node in the TypeDefinition. With `UNIQUE`, the `HasModellingRule` reference in its property “InputArguments” gets lost.
13:01, EEST

April 3, 2012

OPC UA instantiation is not a “1:1 copy of everything”, it just needs to fulfill each InstanceDeclaration ModellingRule of the type (with parent-types hierachy taken into account). HasModellingRule is only used in the Types section of the address space to mark which nodes (BrowsePaths having a target, more specifically) shall be in the instance, which can be, and which cannot be, https://reference.opcfoundatio…..docs/6.4.2 “Nodes referenced by the TypeDefinitionNode without a ModellingRule do not appear in the instance.”
None of new nodes created by the instantiation system has the HasModellingRule Reference. The reason why it exist for the SHARED strategy Method node is that no new Method node is created and the one in the type is referenced (that has the HasModellingRule Reference).
https://reference.opcfoundatio…..cs/6.4.4.4
“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.” (SHARED => refers existing Method node, UNIQUE => creates new ones)
1 Guest(s)
