OPC UA Sampling and Publishing Intervals: Make a Slow Trend Update Explainable

A slow OPC UA trend can be limited by three separate schedules: when the underlying source changes its exposed value, when a MonitoredItem samples it, and when the Subscription publishes queued notifications. Reducing the publishing interval cannot reveal a source update that has not happened, and reducing sampling cannot force a delayed Publish response to arrive sooner.

This guide pins OPC UA Part 4, Services, version 1.05.07, particularly sections 5.13.1.2, 5.14.1.1 and 7.21. An original idealized event-schedule model was executed. No server, SDK, network latency or industrial process timing was measured.

Build a three-clock worksheet

Boundary	Evidence to collect	What it cannot prove alone
Underlying source update	Source sequence or controlled transition and acquisition evidence	When the UA server samples it
MonitoredItem sampling	Requested and revisedSamplingInterval, filter and monitoring mode	When a client receives a notification
Subscription publication	Revised publishing interval, queued Publish requests and response times	That every physical change was sampled

Keep the actual returned intervals. The server can revise requested values to supported settings. A GUI that continues displaying the requested interval can conceal the operating contract. Also record server/client versions, node identity, queue size, filter and timestamps requested.

Section 5.13.1.2 describes sampling as best effort and notes that the underlying data source may update much more slowly. Source updates and UA sampling are usually unsynchronized. The server’s cache can therefore be sampled repeatedly without containing a new process observation.

Interpret zero and negative sampling requests

A sampling request of zero asks for the fastest practical rate. It does not guarantee instantaneous acquisition. A server can report zero for an exception-based source that generates updates rather than being polled periodically.

A negative sampling request asks for the default associated with the Subscription’s publishing interval. Section 7.21 adds an important boundary: subsequently changing the publishing interval does not change the MonitoredItem’s sampling interval. Reinspect the actual revised sampling setting and use the appropriate MonitoredItem modification when that behavior must change.

Where a Variable supplies MinimumSamplingInterval, use it as documented capability evidence. It is not a substitute for observing the actual source update path. Some servers front a decoupled system and do not know its internal acquisition schedule.

Use a controlled step rather than a changing dashboard

In an isolated test source, generate one identifiable state transition and hold it long enough to cross every expected schedule. A short pulse can disappear between source updates or samples; a later publishing change cannot reconstruct an observation that was never captured.

Keep filtering disabled or explicitly controlled for the baseline, set the MonitoredItem to Reporting, provision adequate queue space, and maintain outstanding Publish requests. Record a source sequence or generation with the test data so equal-looking values do not hide whether a new observation occurred.

Capture the first source-cache update, the notification’s value and timestamps, and client receipt. If those observations use different clocks, establish their relationship and uncertainty before subtracting timestamps. A sourceTimestamp describes the data’s source timing contract; it is not automatically the client’s receipt time or the instant of a physical stimulus.

An original ideal-clock comparison

The executed model places a hypothetical step at eleven milliseconds. Source updates occur every 120 milliseconds with a ten-millisecond phase; MonitoredItem samples occur every fifty milliseconds; publication opportunities occur every 200 milliseconds. There is no filtering, queue loss, network delay or Publish-request shortage.

Synthetic configuration	First source update	First matching sample	Publication opportunity
Baseline	130 ms	150 ms	200 ms
Publishing interval reduced to 40 ms	130 ms	150 ms	160 ms
Sampling interval reduced to 20 ms	130 ms	140 ms	200 ms
Source 30 ms, sampling 20 ms, publication 40 ms	40 ms	40 ms	40 ms

At equal timestamps, the model processes source update, sampling and publication in that order. This explicit convention explains the last row. Real implementations need their own ordering and scheduling evidence; these numbers are neither benchmarks nor guaranteed upper bounds.

Check the Publish-request supply

Section 5.14.1.1 defines NotificationMessages as responses to Publish requests queued for the Session. If a publishing cycle has notifications but no available Publish request, the server waits. When a request arrives, it can respond immediately without waiting for the next cycle.

A client that submits only one request and waits too long before replenishing it can therefore add delay unrelated to the requested publishing interval. Inspect the selected SDK’s supported request-pipeline controls and limits rather than manually inventing an unlimited pipeline.

Also avoid interpreting the publishing interval as a strict minimum separation between all responses. The standard requires clients to tolerate more frequent responses, for example when notifications exceed maxNotificationsPerPublish. Arrival bursts can reflect backlog delivery rather than faster source acquisition.

Change one stage at a time

1. Establish the baseline with returned intervals, controlled filter, adequate queues and ready Publish requests.
2. Reduce only the publishing interval and inspect whether delivery advances while source/sample evidence stays unchanged.
3. Restore publication and change sampling; verify the actual revised value rather than the requested one.
4. Where supported by the test source, change its update period independently.
5. Deliberately delay Publish-request replenishment and distinguish that symptom from slow source data.
6. Reintroduce production filters, queues and load only after the three baseline boundaries are understood.

Acceptance is an explanation of the observed delay and the configuration that controls each part. Keep filtering, queue overflow, network transfer and application rendering as separate later investigations. A faster-looking chart is useful only when its source, sampling and publication evidence agree about what became faster.