The right OPC UA collection rate is the slowest configuration that still preserves the process behavior needed for operations and historical analysis. That rate is not one number. Device updates, server sampling, subscription publishing, filtering, and historian storage are separate stages.
Treating them as a single “scan rate” can create two opposite problems. An aggressive request may add server and collector load without revealing any new information. A slow request or a wide deadband may hide a pressure transient or short state change that the historian was expected to explain.
Start with the five rates in the data path
| Stage | What it controls | What it does not guarantee |
|---|---|---|
| Device or PLC scan | How often control logic or I/O updates the source value | How often an OPC UA client receives it |
| Server source update | How the OPC UA server obtains or refreshes that value | A client-selected rate |
| Monitored-item sampling interval | The fastest requested rate at which the server should sample the item | Faster resolution than the source provides |
| Subscription publishing interval | How often the subscription attempts to return queued notifications | That every item changes during each cycle |
| Historian storage or aggregation | Which received records are retained or summarized | Recovery of changes filtered out upstream |
These stages interact, but none replaces another. A PLC may update a temperature every 500 milliseconds while the OPC UA server refreshes its internal value once per second. Asking the server to sample every 100 milliseconds will then read the same underlying value repeatedly or detect changes no sooner than the server makes them available.
Sampling and publishing solve different timing problems
An OPC UA monitored-item sampling interval tells the server how frequently it should check the underlying source for a change. The specification describes this as a best-effort cyclic rate. A request of zero means the fastest practical rate, not an unlimited or guaranteed rate.
Servers commonly support a limited set of intervals. When a client creates or modifies a monitored item, the server can return a revised sampling interval. The client should use the revised value as the actual agreement. The server can likewise revise the requested publishing interval to meet its constraints.
The publishing interval belongs to the subscription. At each cycle, the subscription attempts to send notifications that monitored items have generated and queued. Sampling can therefore occur several times within one publishing interval. The later publication may group those notifications, subject to queue size and other subscription limits.
A shorter publishing interval can reduce delivery latency, but it does not make the source update faster. A shorter sampling interval can improve change detection only when the source and server can supply useful changes at that rate.
Deadbands decide which numeric changes become notifications
An OPC UA DataChangeFilter can suppress small numeric value changes while still reporting changes that meet its trigger rules. This filtering happens before the historian receives the notification, so the historian cannot reconstruct suppressed samples later.
OPC UA defines three deadband types:
- None applies no deadband calculation.
- Absolute compares the magnitude of the current value change with a configured value in the measurement’s units. A change is reported when it is greater than the absolute deadband.
- Percent calculates the threshold as a percentage of the item’s
EURange. It applies to AnalogItems that provide that engineering-unit range.
For example, a 1 percent deadband on an EURange of 0 to 200 bar produces a threshold of 2 bar. That is not 1 percent of the current reading. If EURange is missing or does not represent the intended operating range, the percentage setting is unavailable or may produce an unsuitable threshold.
Deadbands are not a general-purpose setting for every value. The OPC UA absolute deadband applies to numeric variables. A Boolean motor-running state has no useful numeric noise band. Its important information is the transition itself. Status changes are also not suppressed merely because a value falls within a deadband.
Tune settings to the measurement, not the tag count
| Measurement | Engineering priority | Practical starting approach |
|---|---|---|
| Tank temperature | Preserve slow trends without recording sensor noise | Sample in line with the process response; consider a small, justified numeric deadband |
| Pump discharge pressure | Preserve transients, cycling, and instability | Sample faster than the shortest event that must be investigated; use a tight or no deadband if peaks matter |
| Motor running state | Capture every start and stop transition | Use change reporting with no numeric deadband; confirm sampling and queue behavior can retain short transitions |
There is no safe universal interval for any of these classes. A temperature used for long-term energy analysis may tolerate slower collection than the same temperature used for trip investigation. A pressure average may look correct even when a damaging one-second excursion was never collected.
Define the evidence requirement first. Ask for the shortest event duration, maximum acceptable detection delay, smallest meaningful value change, and calculations that will use the data. These requirements provide a defensible basis for timing and filtering.
More samples can create load without more information
Short sampling intervals increase the number of evaluations the server may perform. Tight deadbands can generate more notifications. Short publishing intervals can increase message frequency. Across thousands of points, those choices affect server CPU, subscription queues, network traffic, collector processing, and historian writes.
The answer is not to filter everything aggressively. Upstream filtering trades data volume for irreversible information loss. Use it when measurement noise is understood and the suppressed changes are demonstrably irrelevant to the intended use.
Also inspect the values the server actually grants. A configuration screen may show the requested sampling or publishing interval while the server is operating at a revised value. Record both during commissioning.
Prove the configuration with a controlled test
Test representative signals under normal and abnormal operating conditions:
- Capture a trusted high-resolution reference from the controller, server, or test instrument.
- Record requested and revised OPC UA sampling and publishing settings, plus filter and queue settings.
- Generate known ramps, small oscillations, fast transients, and state transitions where the process permits.
- Compare event timing, peaks, transition counts, averages, and totals in the collected history with the reference.
- Observe server, network, collector, and storage load before expanding the configuration.
Repeat the test after firmware, server, or collector changes. A configuration that was adequate for a slow process may fail after the control strategy or analysis requirement changes.
Where TDengine fits in the collection path
TDengine TSDB-Enterprise OPC UA ingestion supports subscribe mode, in which the server reports data changes, and observe mode, in which the task polls at a configured collection interval. The current OPC UA ingestion documentation states that the observe interval is task-level and that subscribe mode does not scan every point on a fixed interval.
The documentation does not describe a taosExplorer control for OPC UA monitored-item sampling intervals, publishing intervals, or deadbands. Verify those settings in the OPC UA server and the connector version in use rather than assuming the ingestion task exposes them.
Once values reach an industrial time-series database, retention, downsampling, and query design can manage stored data for different consumers. Those downstream choices cannot restore a transient that source sampling or a deadband never reported. Collection tuning therefore needs to be validated before storage optimization begins.
