CTT Index range varries on 2d String Array

[johannwesely]

Hello, i have the following CTT Error

Any Suggestions on this ?

Greetings Johann

[kevinherron]

I would guess it has something to do with the Node you configured the CTT with that has a 2D string array value and whether or not the index range parameter is working when reading the value of that Node.

[johannwesely]

Actually i have no multi dimensional arrays configured in CTT ?


so i guess i have to ask fa. allmendiger about this.

[kevinherron]

I think it actually uses the All Profiles > Arrays > String Node, since that is effectively 2D if you treat the String as an array of bytes, and indexing operations are allowed on Strings.

[johannwesely]

Ah ok there i have a String array configured. But what should i check there ?

[kevinherron]

The test is suggesting you are returning a bad quality value when it creates a MonitoredItem for whatever that Node is and has specified an index range.

In the demo server all the CTT Nodes are part of a ManagedAddressSpaceFragment, which means all the reads are done with AttributeReader.readAttribute. It also uses the naive SubscriptionModel which just periodically calls read, so the same logic is applied.

If you've got any kind of custom logic or implementation for reads or subscriptions then you are responsible for handling the index range parameters as well.

Milo will get you most of the way there, but some of the CTT is actually testing your implementation. It wouldn't be very useful otherwise.

[johannwesely]

I think it is a problem from my ctt test script because it assumes that all strings in the array are the same length wich in my case doesnt match because my strings differ in their length.
Monitor Value Changes\testCases\038.js

Greeting Johann

[johannwesely]

Hello in the meantime i got the following Answer from Allmendinger to this case:
"In the test case Monitor Value Change / 038, the CTT uses the length of the first element to calculate the IndexRange, as you have correctly analyzed. However, this is at first glance not a problem either. Let's take the string array ["ABCDEFGH", "ABC", "ABCDE", "ABCDEFG"] as an example. The script then creates a MonitoredItem with the IndexRange "0:2,5:7", that is, from the first 3 elements of the array, the characters 5-7 -> ["FGH", "", ""]. At that point, an array with 3 elements is expected, with the last 2 elements representing NULL values (or empty strings). We are currently sitting with the Director of Compliance of the OPC Foundation and have also discussed this behavior. The topic will be handed over to the UA Working Group for discussion, so that a clarification - also in the specification - can be made." So we have to wait i guess but is there something we can do now? Greetings Johann

[kevinherron]

I'll be in the UA WG meeting tomorrow to discuss this. It may end up requiring a fix in Milo, we'll see.

…

On Mon, Jun 23, 2025 at 1:39 AM Johann Wesely ***@***.***> wrote: Hello in the meantime i got the following Answer from Allmendinger to this case: "In the test case Monitor Value Change / 038, the CTT uses the length of the first element to calculate the IndexRange, as you have correctly analyzed. However, this is at first glance not a problem either. Let's take the string array ["ABCDEFGH", "ABC", "ABCDE", "ABCDEFG"] as an example. The script then creates a MonitoredItem with the IndexRange "0:2,5:7", that is, from the first 3 elements of the array, the characters 5-7 -> ["FGH", "", ""]. At that point, an array with 3 elements is expected, with the last 2 elements representing NULL values (or empty strings). We are currently sitting with the Director of Compliance of the OPC Foundation and have also discussed this behavior. The topic will be handed over to the UA Working Group for discussion, so that a clarification - also in the specification - can be made." So we have to wait i guess but is there something we can do ? Greetings Johann — Reply to this email directly, view it on GitHub <#1470 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACTCMLXERTJLDAHM67ZBY33E64KZAVCNFSM6AAAAAB5V5RCYKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNJUHA3DCNQ> . You are receiving this because you commented.Message ID: ***@***.***>

[kevinherron]

We decided to special case this behavior when the value being indexed into is a String array or ByteString array and the final range in the index range parameter is out of range. In this case, only for String or ByteString, the result should be the partial or full range requested, or null / empty String / empty ByteString if the range is fully out of bounds.

We tested with demo servers with something like 6 SDKs and there was an even split in behavior. Milo and a couple other SDKs will have to update this particular behavior now.

[kevinherron]

#1497