We have posted a question about this in the OPC Certification and Interoperability Testing forum a while ago and haven’t received any response so I try to post it here (https://opcfoundation.org/forum/opc-certification-and-interoperability-testing/attribute-write-values-for-device-without-writable-variable-nodes/)
My question is what status code to return when a client tries to set the value of a variable node when only the read bit of the AccessLevel attribute is set? The UA CTT expects either Good or BadNotWritable. But in Part 3 table 3 (Bit mask for WriteMask and UserWriteMask), it is stated, for ValueForVariableType, that “It does not apply for Variables since this is handled by the AccessLevel and UserAccessLevel Attributes for the Variable. For Variables this bit shall be set to 0.”
Doesn’t this mean that the accepted status code in addition to Good should be BadUserAccessDenied?
Can you provide the actual CTT test case you are looking at, including the version of the CTT you are using? This allows us to look at the actual test that you are having an issue with. Some additional information on what you are asking:
Table 3 Part 3 – Bit mask for WriteMask and UserWriteMask describe what the bits in the writemask/userwritemask apply to. there is no bit for value, since the value is handle separately. The ValueForVariableType bit is if the value field is in a VariableType definition – i.e. what it is stating is that this bit is only for a VariableType not a Variable.
The value field is only governed by the fields described in table 8 – i.e. AccessLevel and UserAccessLevel
So an Access level of read is not a user access level restriction, it is just not writeable. Typically the write operation would check if the variable is even writeable, before it check if the user has write access. If you provide more information on the actual test case and ctt version we can check if it needs to be updated.
We agree that there is a difference between user access level and access level and that if a variable is writeable or not should be checked before the access level for the current user. We went ahead and made this change in our implementation and returned an error code that we believe is appropriate in this case (Bad_NotWritable). The CTT expects a different error code though, either Good (0x00000000) or BadWriteNotSupported (0x80730000).
Table 60 – Write Operation Level Result Codes (Part 4 1.03) lists all acceptable StatusCode for the write service. As I understand it Bad_WriteNotSupported (which the CTT suggests) shall be used if the write combination isn’t supported or if writing and IndexRange isn’t supported. If the variable itself isn’t writable I think Bad_NotWritable should be used instead, do you agree?
The underlying problem here though is probably that the CTT expects all nodes specified in “Server Test->NodeIds->Static->All Profiles” to be both readable and writable (as suggested by the tooltip for those nodes). Our implementation doesn’t support any writable nodes so this is a problem for us as we can’t specify such nodes.
You can see the error output from the CTT as well as the relevant test case in the image below (is there a way to export the log in any other way?).
We are aware of the issue in the CTT with Servers that are ReadOnly. There are a number of information models that provide ReadOnly data. We have a Mantis issue on the CTT. The test lab can work around this problem and certify a product that only has ReadOnly nodes, but we agree that the CTT should be able to support a ReadOnly configuration.
The list of Test cases that need to be fixed is long, thus we are targeting fixing this issue in the 1.04 build of the CTT.
Most Users Ever Online: 87
Currently Browsing this Page:
Rod Stein: 25
Martin Lang: 22
Randy Armstrong (Sparhawk): 20
Guest Posters: 1
Administrators: firstname.lastname@example.org, email@example.com, Randy Armstrong
Moderators: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Jim.Luth@Schneider-Electric.com, Karl-Heinz Deiretsbacher, email@example.com, firstname.lastname@example.org