How to Set OPC UA Sampling and Publishing Intervals
Two separate numbers control how fast an OPC UA subscription delivers data, and they are constantly confused: the sampling interval on each monitored item, and the publishing interval on the subscription that carries them. Set them backwards and you either flood a cellular link with empty packets or miss fast transients. This page walks the order you should set them in, on a real remote-telemetry link, so the client sees every meaningful change and nothing else.
Set OPC UA Sampling and Publishing Intervals in one line: To set OPC UA sampling and publishing intervals, first pick a sampling interval per monitored item equal to how often the value can meaningfully change, then set the subscription publishing interval to how often you want a batch delivered. Sampling should be equal to or faster than publishing; the server queues samples and ships them at each publish tick.
Understand Which Interval Does What
The sampling interval belongs to the monitored item. It is how often the server reads the underlying variable and evaluates whether the value cleared its deadband. A slow-moving tank level does not need to be sampled faster than it can physically move; a fast pressure spike does. The server, not the client, does this sampling, so you are asking the server to watch on your behalf.
The publishing interval belongs to the subscription that groups those monitored items. It is how often the server assembles whatever has changed and pushes one publish message to the client. Between publishes, changed samples wait in each item's queue. So publishing sets the cadence of network traffic, and sampling sets the resolution of what that traffic can contain. For the mechanics of the objects involved, see OPC UA subscriptions and monitored items.
Set the Sampling Interval per Item First
Work item by item and set each sampling interval to the fastest rate at which that specific value carries information you would act on. A wellhead pressure that you use for a fast shutdown interlock is not a good fit for a slow subscription at all, but for trend and alarm purposes a modest sample rate is usually enough. Oversampling a slow point wastes server CPU and buys nothing.
Requesting a sampling interval faster than the server's own scan of the field device is pointless: the server can only report values as fresh as it reads them. Ask for a rate the server can honor, and read back the revised sampling interval it returns. If the server revises your request upward, that is your real floor, and it will show up later as an apparent quality issue if you assumed the faster number stuck. Quality tells you when a value is stale; see OPC quality code substatus.
Set the Publishing Interval to Match the Link
Now set the subscription publishing interval to the cadence your network and application can live with. On a metered cellular or satellite link, a longer publishing interval batches more changes into each message and cuts per-message overhead, which is where the real bandwidth savings live. On a fast LAN you can publish aggressively because packets are nearly free.
Keep the publishing interval equal to or slower than your fastest sampling interval. If you sample at one rate and publish slower, changes simply queue and arrive in the next batch, which is exactly what you want on a constrained link. If you publish faster than you sample, most publishes carry nothing and you have added keep-alive traffic for no benefit. Publishing cadence interacts with round-trip latency, covered in round-trip time in SCADA polling.
Set the Deadband to Suppress Noise
Sampling and publishing decide timing; the deadband decides which samples count as a change worth queuing. Set an absolute deadband on each analog monitored item just above the sensor and process noise floor so a value jittering in the last digit does not generate a report every sample. The deadband is expressed in engineering units for absolute mode, so a level in feet takes a deadband in feet.
The right deadband is site-specific and depends on the instrument's real noise, not a number you can copy from a datasheet. Set it too tight and you flood the link with meaningless changes; too wide and you miss the small real movements that matter for control. Trend the raw value first, read the noise band off the trend, and set the deadband just above it.
Verify the Result on the Wire
Watch the actual publish messages arriving at the client. On a stable process with a correct deadband, you should see mostly keep-alive publishes with no data, punctuated by real data change notifications only when the process actually moves. A stream of data changes on a still process means the deadband is too tight or absent.
Confirm each item's effective sampling by nudging the process and checking that the first-detected change arrives within one sampling-plus-publishing period. If a fast change you injected shows up late, either the server revised your sampling interval slower than requested, or the publishing interval is the bottleneck. Compare the revised values the server returned against what you asked for before blaming the network.
Common Mistakes
The most common mistake is setting a fast publishing interval and a slow sampling interval, then wondering why fast events are missed: the subscription cannot publish detail it never sampled. The second is ignoring the server's revised values and assuming your requested rates were accepted verbatim. The third is leaving the deadband at zero on noisy analogs, which turns a well-designed subscription into a firehose.
One more: do not solve a bandwidth problem by lengthening the publishing interval alone if the real cost is a per-item deadband that lets noise through. Fix the deadband first, then set the cadence. If your goal is to move this data onward to a broker, plan the interval before the bridge, not after, because the bridge inherits whatever cadence the subscription produces - see the OPC UA to MQTT bridge.
Frequently Asked Questions
Should the sampling interval be faster or slower than the publishing interval?
Sampling should be equal to or faster than publishing. The server samples each item at its own rate, queues changes, and ships the queue at each publish tick. If you publish faster than you sample, most publishes carry no data. If you sample faster than the server can read the field device, the server revises your request upward, so read back the value it returns.
Why do I still get frequent updates after setting a slow publishing interval?
A slow publishing interval batches changes but does not suppress them. If a noisy analog clears its deadband every sample, each publish still carries many changes. Set an absolute deadband just above the instrument's noise floor so only real movement queues, then the slow publish cadence delivers the bandwidth savings you expected.
Does the client or the server do the sampling in OPC UA?
The server does the sampling. When a client creates a monitored item it requests a sampling interval, but the server reads the underlying variable and evaluates the deadband on its own schedule, then delivers results at the subscription's publishing interval. That is why a subscription uses far less bandwidth than a client polling the same points itself.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- OPC Unified Architecture Specification (IEC 62541) - OPC Foundation
- MQTT Version 5.0 (OASIS Standard) - OASIS (v5.0, 2019)
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.