Reconnectiing DA Server has ServiceFaults at 20ms

[afolleco]

Hello SupportTeam,

We are experiencing ServiceFaults(BadNoSubscription) at 20ms(millisecs) or less after the UA Gateway reconnects to our DA server.

Every time we stop the UA Gateway for a few seconds/minutes, then restart it, the ServiceFaults occur at 20ms or less, continuously.

How can we prevent this from happening? i tried 'adjusting' the MinPublishingInterval to 5000ms (from 50ms) but didn't help...

BTW- we see similar behavior using the Matrikon Wrapper product, their ServiceFaults have BadSessionClosed.

In contrast, if we use the KEPware ServerEX with their built-in UA Quick Client, we never see such flood of continuous ServiceFaults at 20ms or less. Some ServiceFaults do occur at 5 seconds until connection/protocol exchange is completed. At that point, no other ServiceFaults occur...

UA Gateway version 1.3.8, our test OPC DA server supports 1.0, 2.0, and 3.0
Thanks.

[Support Team]

Hi,

Can you explain/confirm how you use UaGateway and where you see the service fault?

Is it right that you use UaGateway for converting a COM DA server into an OPC UA server and you connect with a UA Client to UaGateway?
What kind of UA Client do you use?
Where do you see the service fault?
What kind of service returns the fault?

Best Regards,
Unified Automation Support Team

[afolleco]

Hello,

as you stated, we are using the UA gateway for converting DA Server into UA Server,via the UA Gateway, and we connect with a UA client to the UA Gateway.

We use your UA SDK 1.3.2 for our UA client in a Linux (Ubuntu like) box.

we see the service faults by doing a tcpdump on the IP of the UA Gateway and reading the dumps using WireShark.
tcpdump host <IP address of UA Gateway> -i eth0 -s 65535 -w BmsTrace20150319-143600.cap

this issue has been reproduced in our Labs, in an identical fashion as to what's happening in our customer's environment.

As soon as the UA Gateway is restarted, after being stopped for a few seconds or minutes, the ServiceFaults begin
immediately, continuously, with no stopping.

the ServiceFaults are seeing in the protocol exchange with our client, and are always initiated by the UA server (the UA Gateway),
it almost looks like the gateway drops into some sort of emergency 'mode' and keeps requesting at 20ms a number of
different operations including PublishRequests. These requests generate ServiceFaults at that rate, 20ms or faster.

the only way to stop the 20ms traffic(noise), is by restarting our UA Client, once the UA Gateway has been restarted.

I may be able to provide you with an actual captured dump file, let me know your email where i can post it for you.
(i need approval). We recommend the use of wireshark to backtrace the dump...

[Support Team]

Hi,

from your description it seems to be a problem in your UA-Client application. When reconnecting it seems that you try to "re-use" the old subscription object. When sending PublishRequest for such, the UA-Server (and hence the UAGateway) will very quickly respond with ServiceFault (BadNoSubscription) because the corresponding Subscription no longer exists in the UaGateway.

When you recognize such ServiceFault-Error in your client application you must delete that "old" subscription object and create a new one. The Publishes send out for the new subscription should return without ServiceFault.

To verify the error please use UaExpert (has C++ Client SDK inside) and confirm the issue. When UaExpert can smoothly reconnect, the error is very likely in your client implementation.

Best Regards
Support Team

[afolleco]

Hello,

Your advice was correct. We had to actually tear down the global subscription 'bucket' where all nodeid subscriptions
are placed when actually subscribed. As it turns out, we have to do this whenever the server status is not 'Connected',
else if a sequence of server ups and downs occurs, we can eventually start getting the 20ms noise.
We also tighten the individual nodeids subscriptions to prevent duplicates and potential errors after, again, sequences
of server ups and downs.

Thanks again.