OPC-UA Durable Subscription Support Plan

Ignition
1

Hi,

just want to ask if there are any plans to support durable subscriptions ( [UA Part 4: Services - 6.8 Durable Subscriptions](UA Part 4: Services - 6.8 Durable Subscriptions or Profile Durable Subscription Client Facet)) for OPC-UA Clients and/or the OPC-UA server.

Thank you,
André

2

It's not really something we're considering. You might be the first person to ever ask about durable Subscriptions.

What's your use case?

3

Proud to be the first one :stuck_out_tongue:

The primary use case aligns closely with the purpose of durable subscriptions:

  1. A client connects to an OPC-UA server.
  2. The network is unstable, or data criticality is very high.
  3. OPC-UA's monitored item queues help reduce data loss temporarily, depending on data volume and server RAM capacity.
  4. Durable subscriptions allow for larger queues, leveraging non-volatile storage instead of relying solely on RAM.
  • While improving network reliability (e.g., redundancy) can reduce issues, network failures are ultimately unavoidable.
  • Using edge components is another option, but this introduces additional complexity. Moreover, the edge device must still maintain connectivity to the OPC-UA server, altough the likelihood of a network issue is much lower.
  • Adapting the underlying system of the OPC-UA server with a handshake mechanism is also an option, but in most situation not really possible.

In summary: Durable subscriptions offer a buffer mechanism at the OPC-UA level—provided the server and client supports it. If the Ignition client would support it, it would help in realizing a more reliable system. It would also help, when we expose data via the OPC-UA server (not only because of the buffer mechanism, but it might reduces the required RAM)

4

I guess I deserve that answer... just thought you might have a more concrete real world example.

I've just never seen a Server in the wild that supports it, nor a situation where the non-durable queue sizes are insufficient :man_shrugging:

5

Oh, it wasn't my intention to give a bad reply — it's just difficult to be more specific.

1. Ignition as the OPC-UA Client (Data Collection)
We have a server that exposes machine data via an OPC-UA interface. The OPC-UA server is built using an SDK that supports durable subscriptions. Unfortunately, Ignition's OPC-UA client does not support it. Our requirement is to buffer the data for a longer time (just in case there are issues) and one option is to use OPC-UA for this.
It might be possible to enable durable subscriptions through some workaround anyhow. But normally it should be activated by the OPC-UA client during subscription creation. As a fallback, we can use edge component to reduce the risk, but this increase the complexity. There are other fallbacks e.g. handshakes, buffer via flat files, but all require some adaption of the devices.

2. Ignition as the OPC-UA Server (Data Exposure)
The second use case is to use Ignition to expose critical data via its OPC-UA server.
I think the internal queue size is capped at around 100,000 items, which is not providing the required size. Anyway, this queue size already has a noticeable impact on RAM consumption.

6

I suppose there is nothing stopping you from calling the SetSubscriptionDurable method using system.opcua.callMethod.

As long as you don't force a reconnect on the OPC UA connection in Ignition via edit/save or some other means, it will attempt re-activate its existing Session upon reconnecting^, and if that fails attempt to transfer existing Subscriptions upon creating a new Session.

^ session re-activation during client reconnect was only implemented in Milo 1.0 / Ignition 8.3. Prior versions rely solely on transferring Subscriptions to a new Session.

7

Hi Kevin,

okay, thank you for the hint. We will give it a try, but I would like to be as close as possible to the standard functionalities. Maybe it will be part of a standard OPC-UA subscription/server in Ignition at some time.