OPC UA Session Timeout vs Keep-Alive Timeout

Ignition
1

Good morning,
I had an issue with OPC UA communication and I wanted to share with you the details and, perhaps, give an input to improve Ignition OPC UA settings.

I was facing this issue while communicating with a Siemens PLC through OPC UA, but that could be generalized as the issue comes from how Ignition handles session timeout and keep-alive timeout.
I was periodically get disconnected by the PLC with SessionInvalid error so I did some investigations and I founf that the PLC was setting the revised session timeout to a different value than the one requested (which is a standard OPC UA behavior) but that revised values was anyhow greater the Keep-Alive Timout value set in UA Connection settings.
So Ignition was requesting to create a session with a specified timeout, then the PLC creates with a reviewed timeout but if you're not aware of this value you would set the keep-alive timeout to an inconsistent value that might led to frequent disconnection as the keepalive is issued after session expiration.

I did solved the issue by setting the keep-live timeout according to the session timeout but wouldn't be better to have Ignition (Milo in this case) to set the keep-alive timeout accordingly to the revised session timeout (like Kepware does for example) or having the possibility to choose between fixed or pre-calculated?

HTH

Davide

2

The keep alive isn’t usually the primary mechanism for keeping the session alive. Did you have no subscriptions or monitored items or any other service calls happening?

The keep alive ends up doing a few things, in order of intention:

  1. quickly detect a "dirty" connection loss, like a VPN connection going away, instead of waiting what could be a long time for the OS to deliver the TCP layer keep alive failure.
  2. detect that a server is unresponsive (used to happen with Kepware a lot, still does occasionally).
  3. it happens to keep the OPC UA session alive in the absence of any other service calls, but that's not its primary purpose.

The default settings are set with 1 and 2 in mind, and since 3 isn't really a goal and the defaults will keep any reasonably configured session alive, changing them in response to a revised session timeout doesn't really make sense IMO.

3

Hi Kevin,
I got your point but anyhow I got the same result even with a subscription active (configured tags in subscription mode). I don't think it's specific to Siemens as I had the same issue with a software OPC UA Server (NI LabView).

Once you know that behavior it's indeed easy to set OPC parameters properly but it took me an hour to understand the root cause as i wasn't experiencing that issue with Kepserver on the same machine.

That's my proposal to handle the Keep-Alive time accordingly to revised session timeout or having the possibility to choose which option wins.
I don't know if some other users had experienced the same issue/behavior.

Thanks

Davide

4

What are these servers revising the session timeout to? What are your Tag Group / Subscription parameters?

There is no reason you should have to adjust the keep alive timeout to make anything work. You’re “turning knobs” that almost nobody turns, and I’m not sure why you’re doing it. Siemens, Kepware, etc… all work without touching these settings. Even attending the OPC interop events I’ve never touched the keep alive settings when connecting Ignition to all the other servers there.