Log In
Home
06/25/2014
Offline
Even it is not best practice, but is it allowed to change (e.g. numerical) NodeIds below the base spec defined object Objects (ns=0;i=85)?
For example due to an update from the server component?
I guess to know, that a client shall/should only rely on BrowseNames, but is this written anywhere in the specification.
I did not find anything in the forum or the specification.
Regards,
Martin
05/30/2017
Offline
Absolutely not.
NodeIds are the normative identifiers for well known Nodes and cannot be changed.
The BrowseName is, at most, an alias for a Node that can be used to map TypeDefinitions on to instances.
06/25/2014
Offline
Ok, some question/example whether I unterstand it correct.
The OPC UA specification and the companion specification some well known NodeIds, these cannot be changed.
But if an ObjectType from e.g. a componion specification shall be instantiated into the instance address space it is up to the implementator which type of NodeId are used (numerical, strings,...).
So ask for these Nodes/NodesIds.
If a read your answer a server once is released, it is not possible to update any already used NodeId in the future. Correct?
It would be only be possible by a server breaking change by switching from V1 to V2 for example.
05/30/2017
Offline
Everything depends on the authority controlling the namespace.
Instances in a different namespace controlled by a different authority can have their own rules.
The only restriction from the specification is clients have to be able to persist NodeIds and be able to use them on re-reconnect without browsing provided the server configuration has not changed (i.e. randomly generated ids assigned on load are not acceptable).
The "server configuration has not changed" is a fuzzy requirement intended deal with scenarios where a PLC gets a complete new image uploaded and it not practical or possible to keep track of which nodes are "new" and which ones existed before. That said, server configuration changes should be rare and should not happen on every reboot.
06/25/2014
Offline
"Instances in a different namespace controlled by a different authority can have their own rules."
Is there meant the Instance from e.g. the IO-Link Companion Specification or any other Companion Specification?
"The only restriction from the specification is clients have to be able to persist NodeIds and be able to use them on re-reconnect without browsing provided the server configuration has not changed (i.e. randomly generated ids assigned on load are not acceptable)."
This is for server rebooting, ok thats fine.
"The "server configuration has not changed" is a fuzzy requirement intended deal with scenarios where a PLC gets a complete new image uploaded and it not practical or possible to keep track of which nodes are "new" and which ones existed before. That said, server configuration changes should be rare and should not happen on every reboot."
Is "server configuration has not changed" correct or rather "server configuration has changed"?
Is there a possibilty how a client can get knowledge of a modified Server Address Space? By reading the Servers BuildInfo for instance.
For me it not clear under which circumstances a server is possible to change NodeIds in a newer server version.
Is a version jump from V1 to V2 ok for breaking changes due to changed NodeIds?
Shall a product starting from V1 even have no breaking changes until V5 and so on?
05/30/2017
Offline
All CS define 'static' namespaces. These NodeIds can never change once assigned to a Node (see static ranges).
Instances created from the Types in these namespaces are not in the CS namespace. They need to be in a namespace specific to the Server.
There is a difference between product versions and configuration versions.
Server configurations are specified by the end-user based on their needs that can change frequently (especially during system set up).
Product versions are rare and should not change NodeIds if the product Nodes represent the same thing. IOW, I expect Nodes that are part of a product to be similar to a CS and therefore be static. OTOH, if these Nodes are really dynamic like end user configuration defined Nodes then they could change.
The decision should be driven by what is best for your customers. Doing something that breaks existing systems if the product version is upgraded is a good way to annoy your customers and ensure few people would be willing to upgrade.
1 Guest(s)
Usage Policy