How to Set OPC UA Deadbands Without Hiding a Drifting Transmitter

The filter is an operating decision, not a bandwidth knob

A monitored item does not have to report every sampled value. The DataChangeFilter you attach to it (defined in OPC UA Part 4) decides which sampled changes become notifications, using two fields: a DeadbandType and a DataChangeTrigger. Set them without thinking about the process and you get one of two failures.

Too loose, and a transmitter that drifts 0.4 °C per hour never crosses the deadband — the value on the screen looks rock steady while the loop walks off. Too tight, and a noisy analog fills the notification queue every publish cycle; the client looks unstable and someone starts blaming the network when the real problem is that you asked for every wiggle.

Separate sampling from reporting

Two timings are often mixed together during commissioning:

Setting	Meaning	Typical mistake
Sampling interval	How often the server checks the source value	Set fast for every tag because the screen refreshes fast
Publishing interval	How often the subscription can send notifications	Shared across slow and fast tags without checking latency
Data change filter	Which sampled changes are worth reporting	Copied from analog tags to status bits or counters
Queue size	How many notifications can wait before publishing	Left at one for bursty diagnostic values

A value may be sampled every 250 ms but only reported when it changes by a configured amount. That is useful for a noisy analog value. It is wrong for a command feedback bit, alarm state, batch step number, or totalizer where every change matters.

DataChangeTrigger: what counts as a change

The DataChangeTrigger enum has three values. Clients dress them up with friendlier labels, but underneath they are always these:

• Status (0) — notify only when StatusCode changes. Use it for pure diagnostic items where you care that quality flipped to Bad, not what the number did.
• StatusValue (1) — notify on a status or value change. This is the default in most stacks and the right choice for ordinary HMI process values.
• StatusValueTimestamp (2) — notify when the source timestamp moves too, even if status and value are identical. Reach for it on heartbeat-style tags and PLC-calculated values that must prove they are still being recomputed.

The trap is StatusValueTimestamp on a fleet of steady analogs: the source timestamp updates every scan, so you get a notification every publish cycle whether the process moved or not. The opposite trap is leaving a stalled calculation on StatusValue — its value happens to sit unchanged, so a frozen block looks perfectly healthy. Pick per tag, not per template.

Absolute deadband (DeadbandType 1) is the one to reach for first

With DeadbandType set to Absolute (1), the DeadbandValue is in the same engineering units as the value itself: report only when the value moves by at least that much from the last reported one. It is easy to reason about because there is nothing to convert. A tank level in percent might use 0.1 or 0.5. A furnace temperature might use 1 °C. A pressure transmitter might use 0.02 bar if operators actually work at that resolution.

Field checks before setting it:

• Confirm the scaled engineering unit and decimal precision shown on the HMI.
• Compare normal instrument noise with the smallest operator-relevant change.
• Check alarm limits. A deadband larger than the margin to an alarm threshold can delay useful visibility.
• Do not use the same deadband for raw counts and scaled engineering units.

If an HMI display shows one decimal place, a 0.001 engineering-unit deadband usually wastes traffic. If the value is used for tuning or troubleshooting, a tighter separate group may be justified.

Percent deadband (DeadbandType 2) lives or dies on EURange

DeadbandType Percent (2) is defined against the node's EURange Property (OPC UA Part 8, Data Access). The server computes the effective band as DeadbandValue / 100 * (EURange.high - EURange.low). So a 1% deadband on a 0 to 100 range is one unit; the same 1% on a 0 to 10,000 range is 100 units — the same config, a hundred times coarser.

That is where commissioning mistakes hide. Percent deadband is only valid on a node that actually has an EURange Property; if it is missing the server should return Bad_MonitoredItemFilterUnsupported, but a sloppy stack may silently fall back to no deadband instead. And if EURange was inherited from a template and never corrected, the band is quietly wrong. When a value looks frozen until it makes one big jump, read the range metadata before you touch the network.

Good practice:

• Verify EURange for analog inputs that use percent deadband.
• Avoid percent deadband for values with artificial ranges, counters, or recipe parameters.
• Document whether the configured percent is based on instrument span, operating span, or vendor default metadata.

Tags that should usually avoid deadband

Some values should report every meaningful change, even if the numeric movement is small.

• Alarm active, acknowledged, shelved, or suppressed state.
• Equipment mode, step, phase, and interlock summary.
• Command feedback and permissive status.
• Counters where each increment is an event of interest.
• Batch identifiers, lot identifiers, recipe numbers, and operator selections.
• Communication heartbeat and watchdog values used for health checks.

For these items, use the right sampling and publishing rate instead of hiding changes with a deadband.

Common failure modes

The HMI looks calm but the historian is noisy

The HMI may use a deadbanded subscription while the historian collects on a tighter exception rule or periodic sample. Operators see stable values, but historian storage grows quickly.

Check both clients. OPC UA filters are per monitored item and per client. A good HMI setting does not automatically protect historian load, and the historian's own deadband and compression still apply on top of whatever this filter already removed — review both layers together.

Small oscillations disappear during tuning

A loop may hunt by 0.2 °C while the configured deadband is 0.5 °C. The trend shows stair steps and the tuning problem is missed.

For tuning work, create a temporary diagnostic subscription or trend pen with a smaller deadband and a known time window. Remove it after the test.

Queue overflow hides bursts

If many changes occur between publish cycles and the queue size is one, intermediate values are discarded. For a slow analog display that may be fine. For a sequence step or fault code, it can hide the actual order of events.

Review discarded notification counters if the server provides them. Increase queue size only where the intermediate values matter.

Server rejects the filter

Some servers do not support every filter combination for every node. A client may silently fall back to no deadband or mark the item bad.

During FAT, log the revised sampling interval, revised queue size, and monitored item status returned by the server. Do not assume the requested settings were accepted.

Commissioning checklist

• Group tags by behavior: operator analogs, fast diagnostics, status bits, counters, historian collection, and command feedback.
• Use absolute deadband where engineering units are clear and stable.
• Use percent deadband only after verifying EURange.
• Keep alarm and command state changes unfiltered except for deliberate debounce in the control layer.
• Test with a forced ramp, a small step, and a noisy steady signal.
• Compare HMI trend, historian values, and server diagnostics for the same time period.
• Record the reason for non-default filters in the tag template or client configuration notes.

Practical rule

Start with the process question: what change must an operator, alarm function, historian, or troubleshooting engineer actually see? Then set sampling, publishing, filter, and queue size to preserve that change without flooding the system. A data change filter is successful when it removes noise, not evidence.