Inferensys

Glossary

Monitored Item

A client-defined entity in an OPC UA Subscription that specifies a particular Node attribute to watch and the criteria for generating a Notification Message.
Operations room with a large monitor wall for system visibility and control.
OPC UA SUBSCRIPTION ENTITY

What is a Monitored Item?

A Monitored Item is a client-defined entity within an OPC UA Subscription that specifies a particular Node attribute to watch and the criteria for generating a Notification Message.

A Monitored Item is the fundamental sampling unit within an OPC UA Subscription. It is created by a Client to instruct the Server to observe a specific Node Attribute—typically the Value attribute of a Variable Node—at a defined sampling interval. Crucially, the Monitored Item also specifies a Monitoring Filter, such as a Deadband Filter, which determines the conditions under which a change in the attribute's state triggers the generation of a Notification Message for delivery to the Client.

This mechanism decouples the sampling rate from the notification rate, dramatically reducing network overhead compared to cyclic polling. The Server monitors the attribute in its internal real-time data system, applying the filter to suppress inconsequential fluctuations. Only when the filter criteria are met is a notification queued for transmission within the next Publish Response, ensuring efficient, event-driven data flow for supervisory control and data acquisition.

CONFIGURATION

Key Parameters of a Monitored Item

A Monitored Item is defined by a set of parameters that specify what to watch and when to notify. These settings control the sampling rate, filtering criteria, and delivery semantics for data change notifications within a Subscription.

01

Sampling Interval

Defines the rate at which the Server samples the underlying data source for the Monitored Item.

  • Fastest practical rate: -1, meaning the Server samples at its maximum capability.
  • Explicit rate: A positive integer in milliseconds (e.g., 100 for 10 Hz).
  • 0 value: Inherits the Subscription's publishing interval.
  • Key behavior: A faster sampling interval increases CPU load but reduces the risk of missing transient signal changes between publish cycles.
02

Queue Size

Specifies the depth of the notification queue for this Monitored Item before overflow behavior occurs.

  • Default of 1: Only the most recent notification is queued; older unsent notifications are discarded.
  • Larger values: Buffer multiple changes for delivery in the next Publish response.
  • Discard policy: When the queue is full, the Server either discards the oldest notification (DiscardOldest) or the newest (DiscardNewest).
  • Use case: Set >1 for high-frequency signals where every transition must be logged, even during network congestion.
03

Data Change Filter

An optional filter that suppresses notifications unless the data change meets specific criteria, reducing network traffic.

  • Deadband Filter: Suppresses notifications unless the absolute change in a numeric value exceeds a defined threshold. Types include:
    • Absolute Deadband: Triggers on a fixed engineering unit change (e.g., ±0.5°C).
    • Percent Deadband: Triggers on a percentage of the EURange.
  • Status Change Filter: Triggers only when the StatusCode quality bits change (e.g., from Good to Uncertain).
  • No filter: Every detected change generates a notification.
04

Monitoring Mode

Controls the operational state of the Monitored Item and how it interacts with the Server's sampling engine.

  • Disabled: The item is defined but not actively monitored. No sampling occurs.
  • Sampling: The Server samples the value but does not generate notifications. Useful for pre-warming caches.
  • Reporting: Full operation—the Server samples, evaluates filters, and queues notifications.
  • Lifecycle: Clients can dynamically toggle modes to pause and resume monitoring without deleting and recreating the item.
05

Attribute ID & Index Range

Identifies the specific Node attribute to monitor and, for array values, a subset of elements.

  • Attribute ID: The numeric identifier of the attribute (e.g., 13 for the Value attribute, 14 for SourceTimestamp).
  • Index Range: A string specifying a subset of an array value (e.g., "0:4" to monitor only the first five elements).
  • Scalar vs. Array: Monitoring a scalar attribute is straightforward; monitoring an array attribute without an Index Range triggers on any element change.
  • Practical use: Monitor only a critical element of a large array to minimize processing overhead.
06

Discard Policy

Determines which notification is discarded when the Monitored Item's queue overflows.

  • DiscardOldest: Removes the earliest queued notification to make room for the newest. Best for applications that prioritize the most current state.
  • DiscardNewest: Removes the most recent notification, preserving the historical sequence. Best for applications that must not lose any transitions.
  • Interaction with Queue Size: A Queue Size of 1 with DiscardOldest means only the latest value is ever queued—ideal for dashboard displays.
  • Configuration: Set per Monitored Item, allowing different policies for different signals within the same Subscription.
MONITORED ITEM CLARIFIED

Frequently Asked Questions

A Monitored Item is the fundamental unit of data surveillance in OPC UA. These FAQs dissect the mechanics of sampling intervals, queue depths, and filter criteria that determine how and when a client receives change notifications from the server's address space.

A Monitored Item is a client-defined entity within an OPC UA Subscription that specifies a particular Node Attribute to watch and the precise criteria for generating a Notification Message. It acts as a configurable probe inserted into the server's address space. The server's subscription component samples the designated attribute—typically the Value attribute of a Variable Node—at a client-defined Sampling Interval. If the sampled value or status meets the configured filter criteria (e.g., a Deadband Filter), the server creates a notification and places it into the subscription's delivery queue. This mechanism eliminates inefficient client polling, as data flows from server to client only when a meaningful change is detected. Each Monitored Item is uniquely identified by a ClientHandle and a server-assigned MonitoredItemId, allowing precise correlation of incoming notifications to their originating configuration.

OPC UA ENTITY COMPARISON

Monitored Item vs. Subscription vs. Node

Distinguishing the three core entities involved in OPC UA data monitoring and their distinct roles in the client-server architecture.

FeatureMonitored ItemSubscriptionNode

Definition

Client-defined entity specifying a Node attribute to watch and notification criteria

Client-managed object grouping Monitored Items and controlling notification pacing

Fundamental atomic unit in the Server's Address Space with attributes and references

Primary Location

Exists within a Subscription on the Client side

Exists within a Session on the Client side

Exists within the Address Space on the Server side

Core Function

Defines what to watch and when to report

Controls how and when notifications are delivered

Represents the actual data source, object, or method

Lifecycle Management

Created and deleted by the Client via the Subscription

Created and deleted by the Client via the Session

Managed by the Server; created and deleted via NodeManagement services

Sampling Interval

Configurable per-item; determines rate Server checks the value

Not applicable; inherits pacing from Publishing Interval

Not applicable; Node is a passive data structure

Filtering Capability

Notification Trigger

Value change exceeding Deadband, or StatusCode change

Publishing Interval timer expires

Not applicable; Node does not initiate communication

Relationship

References exactly one Node attribute

Contains zero or more Monitored Items

Referenced by zero or more Monitored Items

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.