Glossary · Subscriptions

Subscription

A subscription is the server-side container that groups MonitoredItems and delivers their notifications on one cyclic publishing interval, in response to Publish requests the client leaves outstanding. It owns PublishingInterval, LifetimeCount, MaxKeepAliveCount, MaxNotificationsPerPublish, Priority and PublishingEnabled. Everything about what and how often to sample belongs to the items, not here.

The parameter split is the whole design

Subscription-level parameters control delivery: how often the queues are drained, how many notifications one Publish response may carry, how long silence is tolerated, and which subscription wins when the server is saturated. Item-level parameters control acquisition: what to watch, how fast to sample it, what to filter out, how much to buffer. Confusing the two is the root cause of most subscription tuning failures.

One subscription per distinct publishing interval

A subscription has exactly one publishing interval, so every distinct rate you want forces another subscription - a client that wants fifty different rates ends up with fifty subscriptions, each with its own Publish pipeline, keep-alive traffic and lifetime bookkeeping. Standardise on a small set of rates such as 100, 1000 and 10000 ms, and use per-item sampling intervals for the finer differences.

Delivery, sequence numbers and gaps

Each NotificationMessage carries a sequence number. The client acknowledges numbers in its next Publish, and the server keeps unacknowledged messages available for Republish, which is how a client recovers a message lost across a reconnect. If the client stops publishing for LifetimeCount cycles the server deletes the subscription outright and later calls return BadSubscriptionIdInvalid.

Example

Where each parameter lives

Subscription (one per publishing rate)      MonitoredItem (one per attribute)
  PublishingInterval        1000 ms           SamplingInterval    250 ms  / 0 / -1
  MaxKeepAliveCount         10                QueueSize           4
  LifetimeCount             60                DiscardOldest       true
  MaxNotificationsPerPublish 0 = unlimited    Filter              DataChangeFilter
  Priority                  0..255            MonitoringMode      Reporting
  PublishingEnabled         true              ClientHandle        17

Fifty different publishing intervals = fifty subscriptions. Consolidate the rates.
The mistake people make: Creating one subscription per screen, per tag group or per developer. Servers advertise MaxMonitoredItemsPerSubscription in ServerCapabilities and enforce their own subscription count, and you hit BadTooManySubscriptions or BadTooManyMonitoredItems long before the data volume itself is a problem. Consolidate by rate, not by application structure.

Defined in: Part 4 - Services, Subscription Service Set (CreateSubscription, ModifySubscription, SetPublishingMode, Publish, Republish, TransferSubscriptions, DeleteSubscriptions).

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.

Free download
OPC UA Server Acceptance Test Pack
A 40-check acceptance test you run against a vendor's server before commissioning sign-off. Weighted scoring, three hard gates, and a one-page verdict for the supplier meeting.
Get the free test pack →
Free, no course, no login