Deadband Filter

The filter applies a user-defined absolute deadband to a numeric Variable. A notification is generated only when the absolute difference between the current sampled value and the last reported value exceeds this threshold.

• Type: AbsoluteDeadband
• Mechanism: |CurrentValue - LastReportedValue| > DeadbandValue
• Unit: Matches the engineering units of the Variable (e.g., °C, kPa, mm)
• Use Case: Ideal for analog signals with inherent noise, such as tank level sensors or vibration monitors.

For variables with wide operating ranges, a percent deadband scales the threshold relative to the EURange of the AnalogItem. This prevents excessive notifications at low values while maintaining sensitivity at high values.

• Type: PercentDeadband
• Mechanism: |CurrentValue - LastReportedValue| > (EURange.High - EURange.Low) * DeadbandPercent / 100
• Example: A 2% deadband on a 0–1000 °C range suppresses changes less than 20 °C.
• Benefit: Dynamically adapts sensitivity across the full scale of the instrument.

When a deadband filter suppresses notifications, the Server may still sample values. If the filter later passes a value, the queue ensures the most recent valid sample is sent, not an outdated one.

• Behavior: The Server discards older suppressed values and retains only the latest sample.
• Queue Size: Configured per MonitoredItem to control buffer depth.
• Overflow Policy: Typically set to DiscardOldest to ensure the Client always receives the freshest data point when the deadband is exceeded.

The deadband filter operates on values acquired at the SamplingInterval rate. A faster sampling rate combined with a tight deadband can still generate high-frequency notifications if the process is noisy.

• Best Practice: Tune the SamplingInterval to be 2–5x faster than the expected rate of meaningful change.
• Pitfall: Setting a deadband too wide relative to the sampling rate can mask genuine transient spikes.
• Optimization: Use in conjunction with a PublishingInterval to batch multiple deadband-passed changes into a single NetworkMessage.

A deadband filter only suppresses notifications based on value changes. Notifications triggered by a change in the StatusCode quality (e.g., from Good to Uncertain) bypass the deadband and are sent immediately.

• StatusCode Precedence: A transition from Good to Bad or Uncertain always generates a notification.
• Implication: Clients are guaranteed to receive quality degradation alerts even when the value fluctuation is within the deadband.
• Configuration: This behavior is inherent to the OPC UA specification and cannot be disabled.

By filtering out inconsequential noise, deadband filters directly reduce the volume of DataChangeNotification messages on the network. This is critical for high-node-count systems and bandwidth-constrained edge links.

• Impact: A 1% deadband on a stable process can reduce notification traffic by over 90%.
• Scalability: Enables a single OPC UA Server to support thousands of MonitoredItems without saturating the client connection.
• Contrast: Without deadband, every minor ADC quantization step generates a packet, flooding the network with redundant data.

A client-defined entity within a Subscription that specifies a particular Node attribute to watch. Each Monitored Item has configurable settings—including a sampling interval and a filter—that determine when the Server must generate a Notification Message. The deadband filter is applied directly to a Monitored Item to suppress notifications for insignificant value changes.

A client-managed object that groups multiple Monitored Items and controls the publishing interval—the rate at which queued notifications are sent to the Client. Subscriptions decouple the sampling rate of individual items from the network delivery cadence. When a deadband filter suppresses a change on a Monitored Item, no notification enters the Subscription's queue, reducing the payload size of the next Publish response.

The specific type of deadband filter defined by the OPC UA standard. It calculates the absolute difference between the last reported value and the current sampled value. If this difference is less than the configured DeadbandValue, the notification is suppressed. This is distinct from a percent deadband, which uses the EURange of the Variable Node to calculate a relative threshold.

The OPC UA structure applied to a Monitored Item that defines the trigger conditions for a data change notification. It contains three key parameters:

• Trigger: Status, value, or both
• DeadbandType: None, absolute, or percent
• DeadbandValue: The numeric threshold for suppression Configuring this filter correctly is essential for high-density sensor networks where raw sampling would overwhelm the Secure Channel.

The fastest rate, in milliseconds, at which the Server evaluates a Monitored Item for changes. A deadband filter operates on each sample: if the value change falls below the deadband threshold, the sample is discarded before it becomes a notification. Using a -1 sampling interval binds the item to the publishing interval of the parent Subscription, creating a direct relationship between evaluation and delivery cycles.

The number of notification slots allocated per Monitored Item in the Server's memory. When a deadband filter suppresses most changes, the queue remains largely empty, preventing overflow. If the queue size is set to 1, only the most recent notification is kept, ensuring the Client always receives the latest significant value without processing stale intermediate states.