Troubleshooting WinCC OPC UA Error 0x80310000 BadNoCommunication

Problem Summary

Siemens WinCC installations that expose OPC UA servers and are polled by QuickOPC-based .NET services intermittently return OPC UA StatusCode 0x80310000 (BadNoCommunication) with the textual description "Server not responding to keep-alive requests". The failure manifests as a coordinated pattern across three layers:

1. The OPC UA client (QuickOPC) logs BadNoCommunication and OpcLabs engine code 3201 ("OPC-UA client session is not available when connecting the client subscription").
2. An in-process WinCC API that forwards data raises Cannot lock the OPC-UA client session because it is not available during WriteMultiple.
3. A custom HTTP healthcheck endpoint returns 503 ServiceUnavailable with the body Connection to OPC UA Alarms & Conditions Server not established, while a remote WinCC instance polling that endpoint logs the same 503 in parallel.

When the failure clears, the same log shows OPC UA Server Connected twice and both the healthcheck and downstream consumers return to 200 OK. The pattern is reproducible but transient, which is the classic signature of a server-side or transport-layer problem rather than a client-side bug.

Decoding OPC UA Status Code 0x80310000

OPC UA StatusCodes are 32-bit unsigned integers defined in the OPC UA specification. The numeric value 0x80310000 encodes both severity and semantic meaning. Per the OPC UA StatusCode table (defined in the OPC UA specification, Part 4, section 7.39 and Part 6, Annex A):

The specification text for BadNoCommunication states that the server cannot be reached, the session has timed out, or the underlying connection has been closed without a clean CloseSession exchange. The accompanying QuickOPC message "Server not responding to keep-alive requests" specifically points at the subscription keep-alive timer, which is a transport-layer liveness probe defined in OPC UA Part 4.

Reference: OPC UA Specification Part 4 (Services) and Part 6 (Mappings).

OPC UA StatusCode Severity Classes Used in This Fault

The QuickOPC engine code OpcLabs.UAEngine=3201 is a vendor-specific OpcLabs diagnostic code, not an OPC UA StatusCode. It maps to "OPC-UA client session is not available when connecting the client subscription". Treat it as confirmation that the QuickOPC library observed the underlying BadNoCommunication and reacted by tearing down its session state.

System Architecture Analysis

The deployment under investigation has three distinct logical roles that share infrastructure. Drawing the data flow explicitly makes the failure correlation obvious:

Important architectural insight from the source: the "problemserver" is itself a WinCC server. That means the QuickOPC client and the WinCC OPC UA server can run on the same physical or virtual host. This complicates isolation because a CPU, memory, or disk pressure event on that host can affect both ends of the OPC UA conversation simultaneously and look like a network problem.

Error Sequence Timeline

Reconstructing the log ordering of one fault window reveals a deterministic cascade:

The fact that BadNoCommunication appears four times in a row before the client gives up is consistent with OPC UA keep-alive semantics: the client must miss k consecutive keep-alives (where k = publishingInterval / keepAliveCount) before tearing down the subscription.

Root Causes of BadNoCommunication

Based on the OPC UA specification and the symptom pattern, work through this list from most likely to least likely:

Server-Side Diagnostics in WinCC

The WinCC OPC UA server is configured inside the WinCC project, not from a generic OPC UA management tool. Two paths cover both WinCC Classic and WinCC Unified:

WinCC V7 / Classic (SIMATIC WinCC Explorer)

1. Open the WinCC project on the problemserver.
2. In WinCC Explorer, right-click OPC UA Server and select Properties.
3. Open the Runtime tab and verify: Server starts with WinCC Runtime is enabled and the endpoint URL is opc.tcp://<server>:4840.
4. Open the Security tab and check the current server certificate's valid-from / valid-to dates.
5. In the Windows Event Viewer, expand Applications and Services Logs -> SIMATIC WinCC and correlate the outage window with OPC UA Server start/stop events.

WinCC Unified (V16+)

1. In TIA Portal, open the WinCC Unified device.
2. Navigate to Properties -> OPC UA Server.
3. Inspect Sessions (max sessions), Subscription settings (max subscriptions per session, publishing interval, keep-alive count), and Diagnostics logging level.
4. Verify that Server diagnostics enabled is checked; this populates server-side counters available via the OPC UA diagnostic nodes.

Reference: Siemens Industry Online Support for the WinCC OPC UA configuration manuals specific to the installed version (WinCC V7.5 SP2, WinCC Unified V18, etc.).

Client-Side Hardening in QuickOPC

Even though the source is on the server side, the QuickOPC client can be tuned so the application survives a brief outage without flooding the log and without dropping writes.

Recommended QuickOPC parameter map

QuickOPC usage example (C#)

using OpcLabs.EasyOpc.UA;
using OpcLabs.EasyOpc.UA.OperationModel;
using OpcLabs.EasyOpc.UA.Parameters;

var client = new EasyUAClient();

// Tune session and subscription parameters
var parameters = new UACreateSubscriptionParameters
{
    PublishingInterval = 1000,
    KeepAliveCount = 30,
    LifetimeCount = 300,
    MinLifetime = 30000
};

UAEndpointDescriptor endpoint = new UAEndpointDescriptor(
    "opc.tcp://problemserver:4840");

UADataChangeSubscriptionCallback handler = (sender, args) =>
{
    if (args.StatusCode.IsBad)
    {
        // Handle BadNoCommunication explicitly without retrying writes
        if (args.StatusCode.Code == 0x80310000)
        {
            GlobalFields.Logger.Warning(
                $"OPC UA keep-alive lost: {args.StatusCode}");
            return;
        }
    }
    // Forward value upstream
};

client.SubscribeDataChange(endpoint, "ns=2;s=Channel1\Device1\Tag1",
    parameters, handler);

Reference: OpcLabs QuickOPC product page and the EasyUAClient API documentation for property names applicable to the installed version (QuickOPC 2023.x and 2024.x).

Healthcheck Endpoint Dependencies

The C# controller method exposed in the source ties the healthcheck output to three predicates:

public HttpResponseMessage Get()
{
    if (SyncController.StateIO == false
        || GlobalFields.RefreshComplete == false
        || GlobalFields.TransmitGSDV != "true")
    {
        GlobalFields.Logger_Healthcheck.Warning(
            HttpContext.Current.Request.ServerVariables["REMOTE_ADDR"]
            + ": GET Request Healthcheck --> (503 ServiceUnavailable)");
        return Request.CreateResponse(
            HttpStatusCode.ServiceUnavailable,
            "Connection to OPC UA Alarms & Conditions Server not established");
    }
    else
    {
        GlobalFields.Logger_Healthcheck.Information(
            HttpContext.Current.Request.ServerVariables["REMOTE_ADDR"]
            + ": GET Request Healthcheck --> (200 OK)");
        return Request.CreateResponse(
            HttpStatusCode.OK,
            "Connection to OPC UA Alarms & Conditions Server OK");
    }
}

Recommendations for the healthcheck contract

1. Distinguish "OPC UA not currently connected" from "API not initialized". Today the 503 conflates the three predicates; a downstream WinCC server cannot tell whether to retry or escalate.
2. Include the last successful data update timestamp in the JSON body. A 503 with lastGoodValue: 2024-05-01T12:00:00Z is far more useful than 503 with a static string.
3. Return Retry-After header on 503 so HTTP-aware probes back off.
4. Move the healthcheck evaluation off the request thread. If the QuickOPC session state is checked synchronously, a blocked OPC UA call stalls the HTTP thread and can exhaust the thread pool.

Suggested improved healthcheck body

{
  "status": "degraded",
  "checks": {
    "opcUaSession": {
      "ok": false,
      "lastError": "0x80310000",
      "lastGood": "2024-05-01T11:58:14Z"
    },
    "refreshComplete": { "ok": true },
    "gsdvTransmit":   { "ok": true }
  },
  "nextRetryMs": 5000
}

Network and Wireshark Capture Procedure

If the server-side logs do not identify the cause, capture traffic between the QuickOPC client and the WinCC OPC UA server.

1. Install Wireshark on the problemserver and on the WinCC server (or use a mirror port on the switch).
2. Start a capture on the interface that carries the OPC UA traffic. Filter: tcp.port == 4840.
3. Reproduce the fault window (or wait for the next intermittent failure).
4. Save the capture and analyze:
   • Open the Conversations dialog. Look for the OPC UA TCP session. If the conversation shows a RST or FIN during the outage, the client or server tore down the socket.
   • Filter for OPC UA messages: opcua (if the dissector is loaded) or tcp.port == 4840 && tcp.len > 0.
   • Look for PublishRequest / PublishResponse sequences. The interval between PublishRequests corresponds to the negotiated PublishingInterval. Gaps longer than PublishingInterval * KeepAliveCount indicate a real server-side stall.
   • Look for ServiceFault messages in either direction. The fault contains the StatusCode returned for the failing service call.
5. If encryption is enabled, the OPC UA payload is opaque. Switch the WinCC OPC UA server temporarily to None security policy and a self-signed certificate for diagnostic capture only, then revert.

Step-by-Step Resolution Procedure

1. Confirm the symptom class. Grep all QuickOPC logs for 0x80310000 and the OpcLabs engine code 3201 over a 7-day window. Tabulate hour-of-day and duration. Look for clustering that correlates with backups, antivirus scans, or scheduled jobs.
2. Check WinCC server health during the window. On the problemserver, open Task Manager -> Performance and Resource Monitor. A CPU spike or memory pressure that coincides with the OPC UA outage points at host contention, not OPC UA itself.
3. Read the WinCC OPC UA server logs. In WinCC Explorer, raise the OPC UA server diagnostic verbosity to Information or Verbose. Reproduce or wait for the fault. Look for stack traces, certificate validation failures, or session-limit messages.
4. Inspect certificates. Open %ProgramData%\Siemens\Automation\OpcUa\PKI\ on the WinCC server and the QuickOPC client's trusted store. Any expired certificate or trust mismatch will close the channel silently.
5. Capture network traffic. Follow the Wireshark procedure above. Compare the PublishRequest cadence before, during, and after the outage.
6. Tune the client keep-alive. Adjust QuickOPC KeepAliveCount and LifetimeCount per the table above. This is a stability improvement, not a root-cause fix; do it as a hardening step, not a substitute for diagnosis.
7. Add reconnect backoff. Wrap the QuickOPC subscription in an exponential-backoff reconnect policy. Without backoff, repeated reconnect attempts during a server outage will themselves contribute to the load that prevents recovery.
8. Split the server role. If the OPC UA WinCC server runs on the same host as the QuickOPC client, consider moving the QuickOPC client to a separate host. This isolates the OPC UA server from client-side resource pressure and lets you determine which side is starving.
9. Upgrade server-side OPC UA stack. Check the installed WinCC version against current Siemens updates. OPC UA stack bugs that cause intermittent hangs have been corrected in several WinCC V7 SP and Unified V updates.
10. Update QuickOPC. Upgrade to the latest QuickOPC release. OpcLabs regularly improves reconnect handling, certificate management, and StatusCode classification.
11. Improve the healthcheck contract. Implement the improved healthcheck body from the previous section. A descriptive payload eliminates the need for guesswork during the next outage.

Verification Checklist

Frequently Asked Questions