QuickOPC-UA Subscription Behavior: Reads and Auto-Subscribe Logic

QuickOPC-UA, the OPC UA flavor of the QuickOPC component library, behaves differently from QuickOPC "Classic" (the COM/DA flavor) in one commonly misunderstood area: how the library treats user-initiated Read and Write operations. QuickOPC-UA does not create an OPC UA Subscription and MonitoredItem in response to every Read or Write the developer issues. Despite that, an OPC UA analyzer trace from a connected application will show traffic that looks subscription-like. This reference explains, mechanism by mechanism, what traffic is generated automatically, why it is generated, and which configuration parameters govern it.

Subscription Model: QuickOPC Classic vs QuickOPC-UA

The key takeaway: when using QuickOPC-UA, a user-level Read or Write does not leave behind a Subscription containing a corresponding MonitoredItem. Any subscriptions that appear in a Wireshark capture against an OPC UA endpoint are explained by one of the three mechanisms listed next, not by the call you performed in code.

Mechanism 1: Pre-Defined Node Reads on Connect

When QuickOPC-UA opens a session to an OPC UA server, the underlying OPC UA .NET stack (used by the library) issues a small batch of one-time Read service calls against well-known, pre-defined nodes. Examples include:

• The server's Server_NamespaceArray node (Namespace 0, node id i=2255) so that string identifiers can be resolved into numeric NodeIds.
• Server capability, server status, and product/server name attributes used to populate browse roots.

These reads are issued shortly after CreateSession/ActivateSession complete and are dictated by the OPC UA specification itself. They are not application-visible and cannot be disabled through any QuickOPC-UA setting, because the OPC UA .NET stack performs them automatically. See OPC UA Part 4 — Services for the mandatory Read and Browse service interactions that every conformant client must perform against a server's well-known nodes.

Mechanism 2: Periodic Keep-Alive Status Read

The OPC UA .NET stack also issues a periodic Read against the server's status. This serves as a low-level session/connection keep-alive and as a sanity check on server health.

• Target node attribute: typically Value of the Server_ServerStatus_State variable (Namespace 0, i=2256) and related status components.
• Transport layer: regular ReadRequest/ReadResponse over the active secure channel.
• Source: OPC UA .NET stack within the QuickOPC-UA process.

The rate is influenced by parameters exposed by QuickOPC-UA, but the server itself can also revise the requested rate. As a result, configuring a faster rate on the client does not guarantee the server honors a faster cadence — the server ultimately controls what it executes and at what interval. Refer to OPC UA Part 6 — Mappings for the wire-level encoding details of these services.

Mechanism 3: Server-Status Monitored-Item Subscription

For each session, QuickOPC-UA creates one additional Subscription containing one or more MonitoredItems that watch server-status-related attributes. Characteristics of this subscription:

• Count: A single subscription per session (not per Read/Write, not per application subscription).
• Purpose: OPC compliance — ensuring the client observes server state changes through the standard pub/sub mechanism.
• Items: Well-known, pre-defined pieces of information in the OPC UA server's address space. They have no relationship to whatever the developer later subscribes to at the application level.
• Relationship to Mechanism 2: Functionally duplicates the periodic Read to a large extent today; future versions are expected to consolidate more server-status monitoring into this subscription and reduce other traffic.

Default Rates and How to Change Them

QuickOPC-UA exposes settings that let you change the sampling and publishing rates of the server-status subscription. Sample configuration patterns:

// C# / .NET example — illustrative, not copied from any specific QuickOPC API version
var uaClient = new OpcLabs.EasyOpc.UA.EasyUAClient();

// Recommended use of explicit settings object to change rates
uaClient.SessionParameters = new OpcLabs.EasyOpc.UA.UASessionParameters
{
    // Lower the server-status subscription rates to a less aggressive cadence
    SubscriptionParameters = new OpcLabs.EasyOpc.UA.UASubscriptionParameters
    {
        PublishingInterval = 5000,   // milliseconds
        SamplingInterval   = 10000   // milliseconds
    }
};

Why the Library Behaves This Way (OPC UA Specification Drivers)

The three mechanisms are not arbitrary. Each one exists because the OPC UA specification, as written, makes them necessary or strongly recommended.

1. Namespace and capability discovery. Before the client can resolve string NodeIds or browse a server, it needs the NamespaceArray, ServerCapabilities, and a few additional well-known nodes. Many of these are only available through Read/Browse service calls (see OPC UA Part 3 — Address Space).
2. Session keep-alive. OPC UA relies on session and secure channel timeouts. A periodic Read against server status fulfills the same role as a transport-level keep-alive without the complexity of a dedicated heartbeat message.
3. Compliance profile expectations. Several OPC UA compliance test groups expect a client to demonstrate subscription-based monitoring of server status (rather than relying exclusively on polling). Adding an internal subscription future-proofs the library against evolving certification profiles (see OPC UA technology overview).

Network and Performance Implications

For the vast majority of installations, the three automatic mechanisms are negligible compared to the application's actual Read/Write load. Each mechanism alone produces:

• Mechanism 1: A few Read requests during connection setup — no ongoing traffic.
• Mechanism 2: One Read request at the configured keep-alive cadence (often tens of seconds).
• Mechanism 3: One Publish request at the configured publishing cadence, carrying one or more MonitoredItems of server status.

Combined steady-state cost at default rates (15000 ms sampling / 7500 ms publishing) is on the order of a couple of requests per interval — far smaller than typical poll loops in SCADA applications. The library author specifically notes awareness that none of the three mechanisms should be causing field issues at these rates.

When to Tune the Defaults

Common motivations for altering the defaults include:

• Reducing subscription churn for audit-friendly networks. Some compliance regimes dislike any subscription that the auditor cannot trace to application code. Setting the sampling interval to Double.PositiveInfinity suppresses Mechanism 3 entirely. Verify this against the version-specific QuickOPC-UA help before relying on the behavior.
• Tuning subscription lifetime to OPC UA session timeouts. If the server's session timeout is shorter than the status subscription's publishing cadence, server-side housekeeping may be triggered more aggressively than needed. Aligning the publishing interval to roughly half the session timeout avoids surprises.
• Optimizing WAN links. On constrained links, lengthening intervals reduces request/response pressure without losing the keep-alive benefit.

Verification: Confirming Behavior in the Field

Two practical checks confirm the library is behaving as documented.

1. Capture during connect. Point QuickOPC-UA at the server, start a packet capture (Wireshark with the OPC UA dissector enabled), and observe: CreateSession, ActivateSession, the small batch of Read requests against well-known server nodes, then the CreateSubscription and CreateMonitoredItems request pair from Mechanism 3.
2. Capture during steady state. With the application idle (no application-level Reads/Writes), observe one Read request per keep-alive interval (Mechanism 2) and one Publish request per publishing interval (Mechanism 3). The MonitoredItems in these requests should reference server-status nodes, not application-specific tags.

If additional subscriptions appear, the cause is application-level code that subscribed to those items — not the library's internal mechanisms.

Troubleshooting Matrix

Summary of Default Values