I am currently trying to initiate OPC UA communications between two vendors.
Vendor A provides an OPC UA Server which we connect to for a list of individual tags.
All tags provide the DataType (For example Double) and a ValueRank of -2 (Any)
Vendor B has an OPC UA Client connection which errors on a ValueRank of -2.
Vendor B has noted that they have OPC Foundation certification and ValueRank of -2 is not required.
Vendor A has noted they are following the specification that states -2 is valid.
I have looked through the specification and -2 does appear to be a valid setting with the client required to read the dataType in this scenario, as I read it.
That said, I did stumble across this page: https://kb.opclabs.com/QuickOP....._Test_List
Which did appear to imply at  "All nodes (even scalars from standard information model etc.) have ValueRank equal to -2 (Any): not compliant."
I am curious to the correctness of this compliance statement.
It seems for all the detail in the OPC UA Specifcation, an abritrary decision at Vendor A and Vendor B can mismatch to the point where we simply cannot establish a connection. This seems suprising, so I would like to know if I am misunderstanding something or if there is clear fault on the side of one of the vendors?
There are numerous built in variables which have ValueRanks of Scalar (-1) (i.e. ServerState) or Variables where the VariableType or containing ObjectType restrict the ValueRank (i.e. VectorType or ConditionType). If the Server does not have the correct ValueRanks for these Variables it is NOT compliant and the Client is not wrong if it has issues connecting to it.
If the Server exposes writable Variables with ValueRank -2 then writing Arrays is permitted. If they reject Array writes despite the -2 then the Server is not compliant. However, a compliant Client must be able to deal with ValueRank -2 when it is valid according to the TypeDefinition so it is possible that both sides are wrong in this case.
It is not clear what the client vendor means when it says that ValueRank is not required. Support for Arrays is mandatory for every Client so it is not clear why a Client would have a problem with a ValueRank of -2 because all it means is Arrays could be returned. At a minimum it should be able to accept data when it actually is a Scalar and treat array data as 'bad data' when it is returned at runtime. i.e. the client should not fail before it even gets to the point where is receiving data. The latter rule is more common sense/defensive software design principle than an explicit requirement.
I thought I might reply because I am the author of the post you referenced (on https://kb.opclabs.com ).
What I meant is simple: Although in general ValueRank = -2 is a valid value according to the specification, it does not mean that *any* variable can have this value rank. When the OPC specification requires certain value rank for certain node, which is the basically the case with all variables defined in the standard, the variables must have the value rank which the specification lists for it.
Thank you for your replies and assistance.
For confirmation, the Server has no arrays, but does have Int32s, Doubles, EnumValueTypes, Strings and Booleans.
All of the above have a ValueRank of -2 and ArrayDimensions = 0.
When we check the ServerDiagnosticsSummary, the DataType is ServerDiagnosticsSummaryDataType and the ValueRank is -1.
Based on the above, would the server be seen to be compilant?
Apologies, I miswrote above. Vendor B noted that they have OPC Foundation certification and ValueRank of -2 (or a ValueRank of 0) is not supported. "The Client is certified by the OPC Foundation with what it provides, however it does not support data items with a ValueRank value of -2"
Vendor B has said: It must be a value of ‘-1 (Scalar)’ and not ‘-2 (Any)’. A ValueRank of -2 (Any) means there is no datatype check, meaning it would be possible to write an INT Value into a BOOL, etc. The client enables direct access to OPC servers from the real-time logic, therefore in this environment the data type and size needs to be known in advance
Is the a true reflection of what -2 means. I am unsure how there could be no DataType check given the DataType is also listed when we browse to it?
But I'm really not sure of the purpose of -2 at all when it could just be defined.
The DataType is the same in all cases. A ValueRank of -2 means that the value returned or written is Scalar or Array. If a client is subscribing to data it could start out as a Scalar but then switch to for an update Array and then back to Scalar for next update.
This statement is completely false:
A ValueRank of -2 (Any) means there is no datatype check, meaning it would be possible to write an INT Value into a BOOL, etc.
If the DataType is an INT the value is a INT scalar or an INT array. It can't be anything else. A client that only accepts scalar data (i.e. a historian) could easily handle a ValueRank -2 by rejecting values at runtime if they are Arrays. Such clients should not refuse to use Variables that might return Arrays because it creates IOP headaches like you are posting about. That said, they are correct to say that a compliant client does not need to handle these variables.
That said, the Server is clearly not compliant if it only supports Scalars but uses a ValueRank of -2. A ValueRank -2 means is it valid to write a Array to the Variable. If they do not support that their model is not compliant.
For closure then,
1) A client is still compliant if it does not deal with ValueRank = -2, why is it that they do not need to handle these variables? This would appear to be the simplest way to close this headache.
2) A server is only non compliant if it fails to support Arrays whilst using ValueRank = -2. As such, all they would have to do is say that they can send an array, we simply don't want an array, if I am not mistaken.
This seems to leave me with neither side doing anything against the specification requirements which is surpising, and doesn't give me a clear way forward with either of them.
1) It is reasonable for a client (i.e. a historian or a low memory device) to say that it cannot handle variables with sizes that are unknown at configuration time. This is usually not an issue because Servers have information models that accurately reflect what will be returned. That said, if the client does not have any real constraints like RAM/DB storage and is just being lazy then it is a problem.
2) It is unusual but not wrong for a Server to say that every data Variable can be a scalar or an array. However, if the server vendor is just being lazy because it does not want to set the ValueRank properly then it is a problem.
In both cases the flexibility exists in the specification because there are real uses cases to support the behaviour. However, beyond the needs for compliance there is a rule called 'don't do stuff that makes customers hate using your product'. Anyone who refuses to implement a optional but important behaviour because they are lazy is violating this rule. You need to figure out if there is a good reason for the behaviour and strongly suggest that product useability is criteria as important as compliance and just doing what is required for compliance is not enough.