Hi,

For classic OPC DA OPC UA, we recommend using https://www.prosysopc.com/products/opc-ua-gateway/.

The OPC UA Server must keep track of all MonitoredItems. OPC UA Clients do make the Subscription and items to it, after that they queue up PublishRequests that the server sends back as PublishResponses with the notifications for the items.

The notifications contains IDs assigned by the client. Basically if the server messes up that the client would have to detect that somehow. IF the server keeps however sending so called KeepAlives to it, then it cannot be done (the client cannot know should a variable be changing, at least not withing out-of-baud knowledge i.e. not directly via OPC UA, but you could e.g. “know” that an item should receive a change at least once within 10minutes for example).

If the client does not receive KeepAlives, it is still a server error, but that can be detected, though recovery of those must be handled by the SDK user manually. It is still a problem with the server usually though. Anyway, you must attach a SubscriptionAliveListener to the Subscription and handle that in onTimeout (no KeepAlive when it should have happened, Subscription should still exist on the server) and/or onLifetimeTimeout (no keepalives and the Subscription no longer exist on the server). Note that both are our custom client side time-based detections. Subscription.setAliveDetectionFactor and setTimeoutDetectionFactor can be used to adjust e.g. network latency if it is huge. Both however are an indication that something is wrong on the server.

Where possible, https://www.prosysopc.com/blog/opc-ua-wireshark/ is the best debugging way to know for sure that did the server respond a PublishResponse (and did we send a PublishRequest earlier for which that would have happened). Though you must use None or Sign(only) security modes for that to work.

Additionally, if you could also test with https://www.unified-automation.com/products/development-tools/uaexpert.html that does it too not get the data, if so, it would basically rule our SDK out of the picture and typically if both (UaExpert + our SDK) fails, it typically tends to be a server issue.