Resolving OPC UA Bad_NoSubscription Errors on S7-1500

1. Problem Summary

The OPC UA client receives Bad_NoSubscription (status code 0x80210000) as a service result on the PublishResponse even though the client application believes it has one or more active Subscriptions registered with the server. The symptom is observed against:

• Siemens S7-1500 CPU OPC UA server (firmware V1.8 through V2.x families)
• Siemens S7-1200 CPU OPC UA server (firmware V4.2 and later with activated OPC UA)
• Third-party OPC UA gateways front-ending S7-1500/S7-1200 (for example Kepware 5.20)

Typical log output from a Prosys OPC UA Java SDK client:

2017-03-24 10:59:34,894 DEBUG [Blocking-Work-Executor-17] client.UaClient handlePublishResponse: response=0
2017-03-24 10:59:34,894 INFO  [Blocking-Work-Executor-17] client.UaClient$a Got Bad_NoSubscription as a PublishResponse, although we have connected Subscriptions
2017-03-24 10:59:34,997 DEBUG [Blocking-Work-Executor-21] client.UaClient handlePublishResponse: response=0
2017-03-24 10:59:34,997 INFO  [Blocking-Work-Executor-21] client.UaClient$a Got Bad_NoSubscription as a PublishResponse, although we have connected Subscriptions

The repeat rate is often millisecond-scale (10–200 ms between lines) which means the client is not recovering on its own. Each redundant PublishRequest in the client's queue is bounced back with Bad_NoSubscription, blocking notifications and inflating traffic.

2. OPC UA Subscription and Publish Model (Spec Background)

The mechanism that produces Bad_NoSubscription is defined by the OPC UA specification, Part 4 – Services. The relevant clauses are:

Reference: OPC UA Part 4 specification (Services), OPC Foundation.

The publish queue is a per-session buffer that the client keeps filled. The server responds to each PublishRequest in FIFO order with either a notification message or a KeepAlive if no notifications are pending. When the server has zero subscriptions matching the session, every queued PublishRequest is de-queued and answered with Bad_NoSubscription. The client must therefore guarantee that any PublishRequest it has outstanding corresponds to a live subscription on the server.

3. Root Cause Analysis

The status code itself is correct behaviour from a strictly compliant OPC UA server. The condition that triggers it on S7-1500 / S7-1200 is one of the following desynchronisation states:

3.1 Empty Subscription Added Before Any MonitoredItem

The Java code pattern most often associated with the symptom is:

Subscription subscription = new Subscription();
subscription.addNotificationListener(this.subscriptionNotificationListener);
client.addSubscription(subscription);   // Subscription registered with 0 MonitoredItems

The Prosys SDK ships the subscription to the server immediately. Some S7-1500 firmware builds (notably V1.8 through V2.0 with limited OPC UA session resources) reject, evict, or fail to retain a subscription that has zero MonitoredItems attached at the moment of CreateSubscription. The client's internal model still references the original subscriptionId; the server's session table does not. The client's queue of PublishRequest calls therefore never matches a real subscription.

3.2 Subscription Removed or Cleared Mid-Session

If a subscription is added, populated, then later emptied of all MonitoredItems and never deleted, the server may garbage-collect the empty subscription while the client retains the handle. The same loop of PublishRequest → Bad_NoSubscription follows.

3.3 Server-Side Restart or TIA Portal Download

A PLC stop/start, a TIA Portal "Download to device", a firmware update, or an OPC UA server option-bit toggle invalidates the session. The PLC drops all subscriptions silently. The client only discovers the desynchronisation when its next PublishRequest returns Bad_NoSubscription. If the client does not react to this status code with a full DeleteSubscriptions + reconnect, the loop persists.

3.4 Network-Induced Session Timeout

The S7-1500 default SessionTimeout is 60,000 ms. If the client misses two consecutive keep-alives (timeout = 2 × publishingInterval minimum) the server closes the session and discards the subscriptions. The client's UaSession object still believes the channel is open until its next operation fails.

3.5 Kepware Channel Reconnect

When Kepware 5.20 is front-ending the S7-1500/1200, a channel reconnect drops all internal subscriptions without sending a ServiceFault for queued publish requests. The S7-1500-side session is rebuilt; the client-side session is not, producing the same Bad_NoSubscription cascade.

4. Affected SDK Versions and PLC Firmware

Reference: Siemens Industry Online Support – S7-1500 OPC UA server documentation.

5. Diagnostic Procedure

5.1 Capture a Network Trace

1. Install Wireshark with the OPC UA dissector.
2. Capture the TCP conversation to the PLC (default TCP/4840, sometimes TCP/4845 for redundant pairs).
3. Filter on opcua and look for the PublishRequest / PublishResponse pairs.
4. Confirm the response carries StatusCode.ServiceResult = 0x80210000 (Bad_NoSubscription).
5. Compare the SubscriptionId in the request against the most recent CreateSubscriptionResponse – if they match, the client believes the subscription is alive but the server has already deleted it.

5.2 Enable Prosys SDK Tracing

Add the following to logback.xml:

<logger name="com.prosysopc.ua.client.UaClient" level="DEBUG"/>
<logger name="com.prosysopc.ua.client.Subscription" level="DEBUG"/>
<logger name="com.prosysopc.ua.transport.tcp.impl.SecurityTokenListener" level="DEBUG"/>

Reference: Prosys OPC UA Java SDK – logging configuration.

5.3 TIA Portal Server Diagnostics

1. In TIA Portal, navigate to CPU Properties → Communication → OPC UA.
2. Open the Diagnostics view on the PLC web server (https://<plc-ip>/diagnostics) for live session counts.
3. Count the active subscriptions. If the count is zero but the client log shows non-zero, the desynchronisation is confirmed.

Reference: Siemens – S7-1500 OPC UA server diagnostics entry ID 109769500.

6. Workaround – Populate Subscription Before Registering

The most reliable workaround documented for the Prosys SDK 2.2.x series is to add at least one valid MonitoredItem to the subscription before registering the subscription with the client:

// Step 1: build the subscription
Subscription subscription = new Subscription();
subscription.setPublishingInterval(250.0);     // ms
subscription.setSamplingInterval(100.0);       // ms
subscription.setPublishingEnabled(true);
subscription.addNotificationListener(notificationListener);

// Step 2: create a MonitoredItem BEFORE registering the subscription
UaMonitoredItem item = new UaMonitoredItem(
    client.getAddressSpace().getNode(NODE_ID),   // any valid variable
    AttributeId.Value,
    MonitoringMode.Reporting,
    new MonitoringParameters());
item.setMonitoringMode(MonitoringMode.Reporting);
subscription.addItem(item);

// Step 3: only now register the subscription
client.addSubscription(subscription);

// Step 4: attach the items via the SDK
client.registerMonitoredItems(Collections.singletonList(item));

This pattern keeps the subscription non-empty for the entire lifetime of its CreateSubscription + CreateMonitoredItems sequence on the server, eliminating the empty-subscription eviction race.

7. Reconnection Strategy and KeepAlive Recovery

Even with the population workaround, the client must react to Bad_NoSubscription as a hard signal to rebuild its state. Implement a guarded reconnection listener:

private final ScheduledExecutorService watchdog =
        Executors.newSingleThreadScheduledExecutor();

void onBadNoSubscription() {
    watchdog.schedule(() -> {
        try {
            logger.warn("Bad_NoSubscription detected; rebuilding session");
            client.disconnect();
            client.connect();
            rebuildAllSubscriptions();   // creates new CreateSubscription
        } catch (Exception e) {
            logger.error("Reconnection failed", e);
        }
    }, 250, TimeUnit.MILLISECONDS);
}

private void rebuildAllSubscriptions() throws ServiceResultException {
    for (Subscription s : client.getSubscriptions().values()) {
        client.removeSubscription(s);
    }
    // re-add with at least one MonitoredItem (see §6)
    recreateFromConfig();
}

7.1 Keep-Alive Tuning

7.2 ServiceResult Inspection

Subscribe to the SDK's UaClient.ServiceResponseListener and inspect every ServiceResponse:

client.addServiceResponseListener((request, response) -> {
    if (response.getServiceResult().getValue() == StatusCode.Bad_NoSubscription) {
        onBadNoSubscription();
    }
});

Reference: Prosys OPC UA Java SDK – Client API documentation.

8. Server-Side Hardening (TIA Portal OPC UA Settings)

1. Open the CPU in TIA Portal.
2. Navigate to Properties → Communication → OPC UA → Server.
3. Set Minimum publishing interval to 100 ms.
4. Set Minimum sampling interval to 100 ms.
5. Set Maximum subscriptions per session to 10 (matches typical client use, prevents resource exhaustion).
6. Set Maximum MonitoredItems per subscription to 2000.
7. Enable Security policies at minimum Basic128Rsa15 or Basic256Sha256.
8. Confirm Server interface = "Activate OPC UA Server" is checked.
9. Compile and download the hardware configuration to the PLC.

Reference: Siemens – S7-1500 OPC UA server configuration entry ID 109769500.

9. Kepware-Specific Configuration

When front-ending an S7-1500/1200 with Kepware 5.20:

1. Open Kepware Configuration.
2. Right-click the channel → Properties → Advanced.
3. Set OPC UA Server Max Subscription Lifetime to 30000 ms.
4. Set OPC UA Server Max Keep-Alive Count to 10.
5. Set Reconnect Enabled = True.
6. Set Reconnect Interval = 5000 ms.

Reference: Kepware KEPServerEX – OPC UA server settings documentation.

10. Long-Term Mitigation

• Upgrade the Prosys Java SDK to the latest 5.x line. The 2.x SDK is no longer maintained; new versions ship explicit handling for Bad_NoSubscription and Bad_SubscriptionIdInvalid that auto-rebuilds state.
• Move from empty-then-populate to populate-then-register as a coding standard for any OPC UA client against S7-1500/1200.
• Implement a watchdog that fires every LifeTimeCount × PublishingInterval and verifies the subscription is still healthy by writing a dummy value to a known tag.
• Wrap every subscription operation in a circuit breaker that pauses new PublishRequest issuance for 5 s after receiving three consecutive Bad_NoSubscription errors.

11. Verification Checklist

12. Troubleshooting Matrix

FAQ