Gateway Handling OPC-UA Server Disappearance

[Lushee-inno]

Hi Development Team,

I'm using the gateway to get data from an OPC-UA server to DDS ecosystem and found that the behavior of the gateway when the server/PLC disappears (i.e. if the power to the server gets disrupted) to be needing improvement. From my observations, when this happens, the gateway just stop the spinning of the update loop stating there was a BadDisconnect. But it does not neither exit the whole application OR try to reconnect to the server. This makes its very difficult to integrate the gateway to an automated system in a robust manner.

I am currently looking at the code to find a way to introduce either of these features. Any suggestion will be highly appreciated.. :)

Lushee.

[fgaranda]

Hi @Lushee-inno,

Thanks for reaching out. This is something we were thinking on adding soon. We've run into issues like these in the past and we wanted to add the ability to reconnect if the connection drops for any reason.

If all you want is to exit when the Gateway loses connectivity, you can provide the Thread that runs the OPC UA Client with a shutdown hook (see feature/5-propagate-shutdown-hook). We have prototyped it as follows: If the update loop runs into an issue (a BadDisconnect or any other error), it can call the shutdown hook and exit gracefully. While such behavior may not be desirable if the Gateway embeds more than one OPC UA Client (e.g., it may be connecting to more than one Server), as it will end up affecting connections that were working just fine, if you only have one Client this behavior may be okay. You could have a cron job that checks whether the Gateway is running and relaunch it if it's no longer running.

However, to address your issue, I think it'd be best to provide a mechanism to reconnect if run_iterate returns BadDisconnect. I'm going to try to build on the ideas in feature/5-propagate-shutdown-hook to provide such functionality. In principle the thread could try to reconnect, maybe for a configurable period of time. If after that period of time the Client hasn't reconnected, we could provide the ability to close the connection or the application altogether. What do you think?

[Lushee-inno]

Hi @fgaranda,

Thank you very much for the reponse. Really appreciate it :)

I built the feature/5-propagate-shutdown-hook and ran some experiments where I disconnected the OPC UA Server while the gateway is connected to it. With your recent patch, it is now gracefully exiting the app when the client disconnects. This is certainly an improvement which clarifies the ambiguity about the gateway health if/when the OPC UA Client disappear. I do agree with the point you made about this is not the ideal solution if we run more than one OPC UA Clients with a single gateway instance.

Regarding the cron job suggestion you made, I already tried a similar approach (before the feature/5-propagate-shutdown-hook patch was introduced) where I used a thin secondary monitor client and a cpp wrapper around the gateway executable with a boost thread. It is working fine and successfully reconnects the gateway after disconnections. But using a second client is not the most elegant method since the client in the gateway itself can theoretically do the same. We took this wrapper approach since are also concerned about making any custom changes to this code stack due to future maintainability.

I totally agree with you about implementing this re-connection feature within run_iterate when a BadDisconnect is detected as the best method and excited to see how you would introduce the re-connection feature with a configurable period of time. Do you think that we can see this feature soon? (hopefully :)

Another question, what do you think is the future for the feature/5-propagate-shutdown-hook branch. Since merging this to master will limit the gateway to run one instance per client, are you think of keeping this branch just until the re-connection feature is introduced?