In OPC UA Server Application one of the tag has to be displayed with different values for different users in OPC UA client , ( multiple session users connected to OPC UA server)
we have assign state variable tag using which logged in user(User1) "OPCUA client1"(Session user ) will take the instrument server control by writing the value as 1(Connected in control) then only user allowed to write the new values for other variable tags.
In the same time Another user(User2)(OPCUA client2) logged in assign state variable tag should show 0(Connected in View). So that he does not have access to write other tags
How to handle such tags without creating duplicates ?
There is no hard requirement in UA that every client see the same value for a variable.
For example, if the DataType is LocalizedText then each client sees a different string depending on their selected locales.
However, the default assumption is that every client sees the same value and exceptions need to be documented (i.e. in the Node Description).
Thanks for the reply
but only one tag is present , for multiple users(sessions) same tag will be displayed
we will not create separate tag for each user but need to display different values for different user
it is not based on locale , only English is supported . The value for the tag is integer (0 or 1)
I am talking about using one Variable where the value returned changes depending on the Session.
It is not a common case, but reasonable if properly documented.
The LocalizedText value is one example where this makes sense.
Another example is the SessionSecurityDiagnosticsArrayType where the contents of the array depend on the access rights that a user has: https://reference.opcfoundatio.....art5/7.15/
Now this will likely require special logic on the server side because the default behavior of all SDKs to return the same value for all Sessions that have access to the Value. Most SDKs allow applications to insert their own logic for reading a variable.
Most clients use the same credentials when they create multiple sessions.
If they do not they will encounter cases where access restrictions hide data that is visible to the other session.
That said, there will be some clients that do not do this and will have issues with a value that changes depending on the user.
I added a mantis issue to explicitly describe this behavior in specification:
Once the WG reviews it there may be caveats added.