An OPC UA client can collect process values in two common ways. It can read each value on a schedule, usually called polling, or it can create monitored items and receive notifications through a subscription. Both methods are valid. The right choice depends on what the historian must preserve, how often values change, and what the OPC UA server can sustain.
For most continuously monitored process variables, start with a data-change subscription. Choose polling when the required record is explicitly periodic, the server has weak subscription support, or a regular snapshot matters more than capturing every change. Native OPC UA alarms and events are a separate case, covered below.
What polling does
In a polling design, the collector issues Read requests at a configured interval. A ten-second poll asks for the latest value every ten seconds, even if that value has not changed since the previous request.
This produces a predictable schedule at the client. It does not prove that the source changed at the same cadence. Each read returns a DataValue that can include a value, quality status, and timestamps. The historian still needs a clear rule for which timestamp and quality states it accepts.
Polling works well for periodic reporting, slow-changing values that still need regular records, and servers with limited subscription support. The cost is repeated read traffic whether values changed or not.
Polling can also miss transitions between reads. If a motor status changes from 0 to 1 and back to 0 inside a ten-second interval, both surrounding polls may return 0. A shorter interval reduces that risk but increases load. It never removes the basic blind spot between samples.
What a subscription does
An OPC UA subscription groups monitored items and returns notifications to the client. Each monitored item has a requested sampling interval, optional filter, and queue. The subscription has a publishing interval that controls how often it attempts to return pending notifications.
Sampling and publishing are different. The server may sample a value several times within one publishing interval. It can also revise requested intervals or queue sizes, so the client should inspect the settings the server accepted.
Data-change subscriptions usually send fewer unchanged values. A DataChangeFilter can control when a new sample generates a notification, including the use of a deadband where supported. This makes them a good fit for sparse or irregular changes and for ordinary variables where intermediate transitions matter.
Subscriptions are not a promise of unlimited delivery. If a monitored-item queue fills, values can be discarded according to its queue policy, and OPC UA marks the overflow in the status information. The client must also maintain the subscription lifetime.
The practical tradeoffs
| Decision factor | Polling | Subscription |
|---|---|---|
| Unchanged values | Read every cycle; storage depends on collector rules | Normally reported only when the monitored condition changes |
| Short transitions | Can be missed between polls | Can be captured if sampling, filtering, queues, and publishing keep up |
| Traffic pattern | Regular request and response load | Change-driven traffic with periodic keep-alives |
| Timing control | Client controls the read schedule | Client requests settings; server can revise them |
| Failure modes | Timeouts, slow reads, overloaded scan cycles | Expired subscriptions, queue overflow, missed Publish responses |
Neither mode automatically creates a complete history. Polling needs an interval short enough for the process. Subscription needs suitable sampling, filtering, queue capacity, and recovery. A fast client setting cannot create source resolution that the server does not have.
Three common collection decisions
Suppose a quality report requires one temperature record every minute, including periods when the temperature is unchanged. Polling fits that requirement because the record is explicitly periodic. Check that the source timestamp and device scan rate still support the meaning of a one-minute sample.
For a motor running status, a data-change subscription is usually a better fit. It avoids storing repeated copies of the same state and can capture transitions between polling cycles, provided the server sampling rate and monitored-item queue are adequate.
Native OPC UA alarms and events require event monitoring. They use event notifier nodes and an EventFilter, not the DataChangeFilter used for ordinary variable values. If the historian must retain alarm identity, severity, acknowledgement, and state transitions, collect the native event stream rather than inferring an alarm lifecycle from a Boolean tag alone.
A mixed design is often more accurate than one global rule. Poll periodic records, subscribe to changing process values, and use OPC UA Alarms & Events for native event semantics.
Settings to validate before deployment
- Define the loss you can tolerate. Write down the shortest event that must be captured and the longest acceptable delay before it reaches the historian.
- Check the server’s revised subscription values. Confirm actual sampling interval, publishing interval, queue size, and filter result.
- Preserve quality and the right timestamp. Do not treat a bad OPC UA status as a usable measurement, and decide whether source, server, request, or receipt time fits the application.
- Test overload and interruption. Drive representative point counts and change rates, interrupt the network, and check for overflow, gaps, duplicates, and recovery behavior.
- Measure the full path. Compare source changes with collector input and historian rows. A healthy OPC UA session does not prove that every selected value was stored.
How this maps to TDengine
When collected process values need to be retained and queried in an industrial time-series database, TDengine TSDB-Enterprise provides OPC UA ingestion through taosExplorer and taosX. The current OPC UA connector documentation labels this an Enterprise feature and states that TDengine TSDB-OSS does not include it. An agent is optional when taosX can reach the OPC UA server directly; otherwise, taosX-Agent can run on a host with access to the server.
TDengine documents three OPC UA collection modes: subscribe for data-change reports from ordinary points, observe for scheduled reads, and event for native alarms and events. The event mode uses an event-specific monitored-item and filter path; it is not the same as subscribing to value changes. In observe mode, the default collection interval is 10 seconds, and all ordinary points in one task share that interval. Points that require different poll periods should be separated into different tasks.
TDengine also lets a point use the OPC origin timestamp, request timestamp, or received timestamp as the TDengine timestamp. Make that choice from the engineering requirement, not convenience. For example, received time can help order ingestion consistently, while origin time better preserves when the source said the measurement occurred. Review source clock quality before relying on origin time.
Start with subscribe for normal change-based process collection. Switch a test task to observe when you need a periodic record or want to isolate a subscription problem. Use event when the source and requirement involve native OPC UA alarms or events. Treat each choice as an engineering decision, not a universal performance rule.
