Log In
Home
06/02/2020
Offline
I have a question on how should the node ID behaves for dynamic nodes and optional nodes in particular.
Suppose we have an object type that defines a child variable as optional. The presence of this variable depends on the runtime execution context of the system, meaning that while the server is running this optional variable might be present or not depending on some condition.
Considering the following sequence:
1) An instance of the object type is created, the optional variable is not added because the condition is not there.
2) The condition about the presence of this variable is now true, then the server adds the optional variable to the object instance. A node ID “A” is generated for the variable.
3) The condition disappears, then the server removes the optional variable to the object instance.
4) In the mean time some other nodes are dynamically created, removed, etc. in the model.
5) The condition about the presence of this variable is again true, then the server adds the optional variable to the object instance again, with the same browse name as before. => Here is my question: what should be the node ID of the variable:
a) the same as in point 2), that is “A”?
b) or a new node ID “B”, since other nodes have been created in the meantime?
Regards
Thomas
05/30/2017
Offline
It is up to the server to decide what to do with the NodeIds in this case.
That said, it will likely be easier for clients if the same NodeId is used.
Or better yet, always instantiate the node but set the value status to BadOutOfService if the state of the Object means the variable is not available.
Do you have a reason that you want the Variable to disappear entirely?
06/02/2020
Offline
Hi Randy, thank you for your reply.
I though to not make it available when not necessary to make the exposed model simpler, but from your answer I understand that I make it more complex in another aspect, the node ID management at the client side.
When accessing model and nodes, what it the typical approach for the client, using node ID or using browse name?
Thank you for your help
Regards
Thomas
05/30/2017
Offline
Clients will use the browse name when being configured but will cache the NodeId once the create a subscription.
Consider a scenario with a HMI panel display that shows several variables from the Object.
When the display is initialized it will browse for the NodeIds and not find optional variable.
It then creates a subscription for the variables that do exist which keeps the display up to date.
If the optional variable is later added the display will not get updated.
The client would need special logic to monitor for the disappearing variable.
OTOH, if the variable is always there it gets the NodeId but a value of BadOutOfService tells it that there is no value to display.
If the object changes HMI will detect it automatically and display the right value.
06/02/2020
Offline
So if I generalize this to objects having child variables, properties but also having child methods and child objects that might all be also either mandatory or optional and these child objects having their own child variables, properties, methods and objects either mandatory or optional, etc., the best practice would be:
– Create instances of objects with all the optional members, whatever it is variable, property, method or object
– And for optional members, also recursively within child objects, when the optional member is not available
– for variables and properties:
– if read only, then value status code set to BadOutOfService
– if writable, then value status code set to BadOutOfService and report BadOutOfService to a write request
– for method report BadOutOfService to a call request
– for object, the instance is created (no particular status is possible) and statement above apply to its child members
Would this be the generalized best practice for optional members?
05/30/2017
Offline
Would this be the generalized best practice for optional members?
You had a very specific user where runtime changes to an object could cause a property to appear.
This is different from a situation where a change to configuration adds or removes components.
Configuration changes, by their nature, can require that that client’s update their configuration.
Runtime changes do not.
So the best practice is to assume that all optional components are only added via configuration changes and do not create them unless they are needed.
If, in specific use cases, an optional component can come and go due to runtime changes then you have the option of instantiating it in advance and using a bad status code to report when it comes and goes.
Whether you want to do that or not depends on the component and the reason for the runtime change.
1 Guest(s)
Usage Policy