OPC UA Monitored-Item Queues: Detect Discarded Changes Instead of Assuming Complete History

For a full OPC UA data MonitoredItem queue, discardOldest true removes the oldest queued notification and appends the new one. False replaces the most recently queued value with the new value; it does not simply reject the incoming sample. Inspect the Overflow information bit and the revised queue size before interpreting a notification stream as complete history.

This guide pins OPC UA Part 4, Services, version 1.05.07, especially sections 5.13.1.5 and 7.21. Its scope is data-change MonitoredItems carrying DataValues, not Event queues. Original logical queue traces were executed locally; no OPC UA server, StatusCode codec or network experiment was run.

Locate the queue before counting losses

The MonitoredItem samples a source and applies its filter. A passing sample creates a notification queued for transfer by the Subscription. This queue sits before the notification is included in a sent NotificationMessage.

The server’s retransmission storage holds already sent NotificationMessages. It is a different stage. Recovering a lost sent message through Republish cannot recreate a value discarded from the item queue before it was ever published.

Record each item’s requested queue size, revisedQueueSize, discard policy, sampling interval, filter and monitoring mode. The server may limit the requested size. A capacity estimate based on the requested value is not the active contract if the service result returned a smaller queue.

Trace both policies with the same input

Use a hypothetical queue with revised size three. Hold publication so the five distinct values one through five all pass the filter and reach the queue. In the table, an asterisk denotes the logical Overflow flag:

After value arrives	discardOldest true	discardOldest false
1	[1]	[1]
2	[1, 2]	[1, 2]
3	[1, 2, 3]	[1, 2, 3]
4	[2*, 3, 4]	[1, 2, 4*]
5	[3*, 4, 5]	[1, 2, 5*]

With true, removal of the oldest entry places the flag on the next retained value. With false, replacement of the last queued entry places the flag on the new value. These placement rules come from section 5.13.1.5 and matter when locating the loss boundary in the returned stream.

Calling the false policy “drop newest” can be misleading if it suggests the newly arriving value is thrown away. In this contract, the earlier queued prefix survives while the queue’s final slot advances to the latest incoming value.

Treat queue size one as a different mode

For data MonitoredItems, requested queue size zero or one produces a revised size of one. The queue then behaves as a latest-notification buffer and ignores the discard policy. Both policies in the executed model ended with value five after the same input sequence.

The larger-queue Overflow indication applies when the queue size is greater than one. Therefore the absence of that bit with a one-entry buffer does not demonstrate that every intermediate change was delivered. A client displaying only the latest state may intentionally accept that behavior; a history collector must not assume otherwise.

Do not confuse “newest queued notification” with “every physical state was sampled.” Source update and sampling boundaries can already omit brief changes before any item-queue decision occurs.

Preserve information bits in the consumer

Keep the full DataValue StatusCode through decoding, storage and application delivery. Checking only its severity can discard useful information bits. Expose an explicit loss indication when Overflow is present, even if the retained numeric value remains usable for the product’s latest-state purpose.

The bit is not an exact dropped-item counter. Multiple lost values can collapse into one surviving flagged notification, and a flagged entry can itself be replaced or discarded later. Record the observed flag and the known test sequence; do not invent a precise loss count from the flag alone.

NotificationMessage sequence numbers identify messages sent by the Subscription. A contiguous sequence of those messages can still contain item-level overflow because the loss occurred earlier. Conversely, a missing message sequence calls for investigating retransmission recovery rather than assuming the MonitoredItem queue was too small.

Keep filtering out of the baseline experiment

Use distinct changes that pass the configured filter, or disable optional deadband filtering for the first test. If a value is legitimately suppressed by a DataChangeFilter, its absence is not queue overflow.

Section 5.13.1.5 also warns that filtering and queue loss interact: the first value remaining after loss may not exceed the deadband relative to the last value the client received. The server compares against its relevant queued-value state, so a client-side adjacent-value check is not a complete filter oracle.

Event monitoring uses a different overflow mechanism and is excluded here. Do not expect a DataValue Overflow bit to be the universal marker for all subscription data types.

A bounded implementation qualification

1. Create one data MonitoredItem and verify successful creation, revised size and effective filter.
2. Arrange a controlled source sequence whose changes are actually sampled and pass the filter.
3. Delay publication or supported client delivery in an isolated test without accidentally expiring the Subscription.
4. Release delivery and compare returned per-item order, values and full StatusCodes with the expected policy trace.
5. Repeat for both discard settings at size three, then at size one.
6. Repeat with production filters and realistic delay, recording any additional loss stages separately.

The local model reproduced all four logical campaigns and each intermediate queue state. It used boolean overflow annotations, not actual wire encodings. Server scheduling, revised capacities, lifetime handling and client decoding remain integration tests.

Choose acceptance according to the consumer’s purpose. Latest-state displays can tolerate deliberate coalescing with an honest contract. A complete change-history requirement needs evidence across source sampling, filtering, item queues, message delivery and storage. Enlarging one queue or receiving contiguous message sequence numbers proves only part of that path.