Bad_EncodingLimitsExceeded from getDiagnosticInfoArray | OPC UA SDK for JavaProsys Forum

Please consider registering
guest

Forum

OPC UA SDK for Java
sp_ArrowRight

Bad_EncodingLimitsExceeded from getDiagnosticInfoArray

Topic RSS

Bad_EncodingLimitsExceeded from getDiagnosticInfoArray

May 11, 2017
10:17, EEST

Ben

Member

Members

Forum Posts: 4

Member Since:
May 11, 2017

Offline

Hi all

I’m working for GE and we are currently trying to connect to a Siemens Sinumerik 840D, v4.7 over OPC UA via Predix Machine. The underlying library used by Predix Machine is the Prosys OPC UA Java stack (as explained to us by Predix support). Their support asked us to contact you directly with this problem, hence my post here.

We are getting the following error message when trying to first establish connection with the Siemens OPC UA Server:

[TcpConnection/Read]|WARN|org.opcfoundation.ua.transport.tcp.io.TcpConnection|71-com.ge.dspmicro.opcua-common-16.4.3|/xxx.xxx.xxx.xxx:4840 Error
org.opcfoundation.ua.encoding.DecodingException: Bad_EncodingLimitsExceeded (code=0x80080000, description=”MaxArrayLength=65535 < 1869182049")
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.assertArrayLength(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getDiagnosticInfoArray(Unknown Source)
at org.opcfoundation.ua.core.EncodeableSerializer$121.getEncodeable(Unknown Source)
at org.opcfoundation.ua.encoding.utils.AbstractSerializer.getEncodeable(Unknown Source)
at org.opcfoundation.ua.encoding.utils.SerializerComposition.getEncodeable(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getMessage(Unknown Source)
at org.opcfoundation.ua.transport.tcp.io.TcpConnection$ReadThread.run(Unknown Source)[71:com.ge.dspmicro.opcua-common:16.4.3]

As a side note: we can successfully establish connection with other clients, e.g. the OPC UA .NET stack, UA Expert etc.

After getting some initial feedback from Siemens I have spotted in their Siemens Sinumerik 840D OPC UA server documentation that, at least with the curent version, DiagnosticInfos are not supported (see here: https://support.industry.siemens.com/cs/document/109481648/sinumerik-840d-sl-sinumerik-integrate-access-mymachine-opc-ua?dti=0&lc=en-WW).
After contacting their support, their official response was: "Yes, it’s disabled and we are returning NULL". Whatever that means.
While this is sad, there is nothing we can do about it and we would certainly not expect the OPC UA library to explode because of it.

So we were digging into the reasons a bit more by executing a network trace to see exactly what gets returned by the OPC UA server. It seemed somehow excessive that we should get an array with almost 2 billion entries for something that is disabled.
1. From the Predix log files, we suspect that the CreateSession request fails, but then it continues executing ActivateSession + ReadRequest requests (which then obviously also fail).
2. The one difference I can spot in the network trace (not being an OPC UA expert) is, that the DiagnosticInfos array in the in the CreateSession request is not present AT ALL. All the other requests contain the array, just with a length of 0. See below for three examples of the output from the trace, one for each relevant response type.

So my suspicion is that the OPC UA Java stack blows up because the DiagnosticInfos array is not present at all in the create session response. Is there a way you can check (and fix) this?

Do you have any more input on this problem?
If at all relevant, the original forum post where it all started in the Predix forum can be found here (initially, we had a different error with certificates, but solved that):
https://forum.predix.io/questions/12506/opc-ua-adapter-the-security-mode-does-not-meet-the.html

Thanks for any help

Ben

Finally, here the three samples from the trace:

CreateSession response:

Frame 31: 1113 bytes on wire (8904 bits), 1113 bytes captured (8904 bits) on interface 0
Ethernet II, Src: Siemens_a1:65:fa (00:1b:1b:a1:65:fa), Dst: Dell_18:52:56 (34:e6:d7:18:52:56)
Internet Protocol Version 4, Src: xxx.xxx.xxx.xxx, Dst: yyy.yyy.yyy.yyy
Transmission Control Protocol, Src Port: 4840 (4840), Dst Port: 62606 (62606), Seq: 1625, Ack: 425, Len: 1059
[2 Reassembled TCP Segments (2519 bytes): #30(1460), #31(1059)]
[Frame: 30, payload: 0-1459 (1460 bytes)]
[Frame: 31, payload: 1460-2518 (1059 bytes)]
[Segment count: 2]
[Reassembled TCP length: 2519]
[Reassembled TCP Data: 4d534746d70900005e440900010000003400000002000000…]
OpcUa Binary Protocol
Message Type: MSG
Chunk Type: F
Message Size: 2519
SecureChannelId: 607326
Security Token Id: 1
Security Sequence Number: 52
Security RequestId: 2
OpcUa Service : Encodeable Object
TypeId : ExpandedNodeId
CreateSessionResponse
ResponseHeader: ResponseHeader
Timestamp: Mar 22, 2017 10:40:42.246000000 W. Europe Standard Time
RequestHandle: 0
ServiceResult: 0x00000000 [Good]
ServiceDiagnostics: DiagnosticInfo
EncodingMask: 0x00
StringTable: Array of String
AdditionalHeader: ExtensionObject
SessionId: NodeId
AuthenticationToken: NodeId
RevisedSessionTimeout: 100000
ServerNonce: [OpcUa Null ByteString]
ServerCertificate: 3082036c308202d5a0030201020204a93d0000300d06092a…
ServerEndpoints: Array of EndpointDescription
ServerSoftwareCertificates: Array of SignedSoftwareCertificate
ServerSignature: SignatureData
MaxRequestMessageSize: 0

ActivateSession response:

Frame 34: 118 bytes on wire (944 bits), 118 bytes captured (944 bits) on interface 0
Ethernet II, Src: Siemens_a1:65:fa (00:1b:1b:a1:65:fa), Dst: Dell_18:52:56 (34:e6:d7:18:52:56)
Internet Protocol Version 4, Src: xxx.xxx.xxx.xxx, Dst: yyy.yyy.yyy.yyy
Transmission Control Protocol, Src Port: 4840 (4840), Dst Port: 62606 (62606), Seq: 2684, Ack: 777, Len: 64
OpcUa Binary Protocol
Message Type: MSG
Chunk Type: F
Message Size: 64
SecureChannelId: 607326
Security Token Id: 1
Security Sequence Number: 53
Security RequestId: 3
OpcUa Service : Encodeable Object
TypeId : ExpandedNodeId
ActivateSessionResponse
ResponseHeader: ResponseHeader
Timestamp: Mar 22, 2017 10:40:42.280000000 W. Europe Standard Time
RequestHandle: 0
ServiceResult: 0x00000000 [Good]
ServiceDiagnostics: DiagnosticInfo
StringTable: Array of String
AdditionalHeader: ExtensionObject
ServerNonce: [OpcUa Null ByteString]
Results: Array of StatusCode
DiagnosticInfos: Array of DiagnosticInfo
ArraySize: 0

ReadRequest response:

Frame 216: 212 bytes on wire (1696 bits), 212 bytes captured (1696 bits) on interface 0
Ethernet II, Src: Siemens_a1:65:fa (00:1b:1b:a1:65:fa), Dst: Dell_18:52:56 (34:e6:d7:18:52:56)
Internet Protocol Version 4, Src: xxx.xxx.xxx.xxx, Dst: yyy.yyy.yyy.yyy
Transmission Control Protocol, Src Port: 4840 (4840), Dst Port: 62615 (62615), Seq: 2748, Ack: 900, Len: 158
OpcUa Binary Protocol
Message Type: MSG
Chunk Type: F
Message Size: 158
SecureChannelId: 607335
Security Token Id: 1
Security Sequence Number: 54
Security RequestId: 4
OpcUa Service : Encodeable Object
TypeId : ExpandedNodeId
ReadResponse
ResponseHeader: ResponseHeader
Timestamp: Mar 22, 2017 10:40:52.135000000 W. Europe Standard Time
RequestHandle: 175
ServiceResult: 0x00000000 [Good]
ServiceDiagnostics: DiagnosticInfo
EncodingMask: 0x00
StringTable: Array of String
AdditionalHeader: ExtensionObject
TypeId: ExpandedNodeId
EncodingMask: 0x00
Results: Array of DataValue
ArraySize: 3
[0]: DataValue
[1]: DataValue
[2]: DataValue
DiagnosticInfos: Array of DiagnosticInfo
ArraySize: 0

May 11, 2017
10:53, EEST

Jouni Aro

Moderator

Moderators

Forum Posts: 1010

Member Since:
December 21, 2011

Offline

Thanks for bringing the issue out here in the forum.

Unfortunately, this issue with Sinumerik is a known problem and we have raised it to the awareness of Siemens already last year. The problem is that they are encoding OPC UA ExtensionObjects incorrectly, with ExtensionObject length=-1. This confuses the decoder, which assumes that the array is not present and decoding the next part of the message will then fail, accordingly.

The reason why this is possible and that they can still communicate with UaExpert is that it does not use the length field for known (i.e. standard) ExtensionObject (i.e. Structure) types. Unfortunately, this is not possible with the OPC Foundation OPC UA Java Stack, which we are using in the SDK. The OPC Foundation .NET Stack behaves similarly, as far as I know. The reason why you can still connect with .NET is probably, that the plain connect does not need support for ExtensionObjects (when the DiagnosticArray is the last element in the message, it does not really matter).

The Prosys OPC UA Java SDK starts polling the server for server status after the connection, and this is the message that fails because of the described problem. You should be able to connect, if you disable the automatic status read with UaClient.setStatusCheckInterval(0). However, this will not provide full functionality, since the subscriptions are also relying on ExtensionObjects and their decoding will fail as well.

The SDK 2.3.0 release included another fix for the case where the server is responding with DiagnosticArray of size 0 instead of a null array, in case it has no diagnostic info for the read request.

Unfortunately, we don’t have exact information from Siemens when and how the fix for the server is or will be available. Also, there is no simple way to fix this in the Java Stack, which relies on the servers to follow the OPC UA specification in this regard. The design that UaExpert is using will not work 100% with all extension objects either, but you will not notice these issues in normal use cases. Unfortunately, in this case the extra tolerance of UaExpert has enabled the server developers to release this type of a product without doing a full interoperability testing themselves.

May 12, 2017
14:32, EEST

Ben

Member

Members

Forum Posts: 4

Member Since:
May 11, 2017

Offline

Hey Jouni

Thanks a lot for the elaborate reply.
It’s a shame that we cannot somehow work around this problem within the OPC Foundation OPC UA Java Stack to provide a fix for this issue.
I completely understand the reasons for this, though, as you have laid them out. If we were to water down the implementation of standards in libraries, we basically open Pandora’s Box by letting suppliers run their own variations, in turn rendering the standard practically useless.

I hope a company as big as GE can pull some weight with Siemens to get this fixed sooner rather than later. I will certainly report back if I should hear of a fix.

Cheers

Ben

May 12, 2017
14:47, EEST

Jouni Aro

Moderator

Moderators

Forum Posts: 1010

Member Since:
December 21, 2011

Offline

Yes, typically we do try to work around all problems as much as possible. In this particular case, however the decoding should be changed completely.

How it works now is:
1. When messages are decoded, ExtensionObjects are read as byte arrays without decoding them
2. ExtensionObject.decode() is called in the application layer when these objects are being used

To be able to fix this, we should move the decoding of ExtensionObject to the stack layer, which in practice would mean that we should generate code for all known Structure types, which could then decode the data from the byte array and ignore the length of the byte array. This is not trivial and not really worth it. Since, the problem will remain to all custom structure types even in this scenario, which can only be decoded dynamically.

I hope Siemens has fixed this issue already and it should be just a question of when the updated OPC UA server version will be available. Please, keep on asking and putting pressure on them, since we have no way to affect their schedules.

All RSS

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 518

Currently Online:
17 Guest(s)

Currently Browsing this Page:
1 Guest(s)