Data Access

The Read Service allows a Client to retrieve the current value, timestamp, and quality of one or more Variable Node attributes in a single request. OPC UA supports both synchronous (blocking) and asynchronous (non-blocking) invocation models.

• Synchronous Read: The Client thread waits for the Server to process and return the complete result set before continuing execution.
• Asynchronous Read: The Client issues the request and continues processing; the Server delivers results via a callback when ready.
• Optimized Bulk Reads: A single Read request can target multiple Nodes across different areas of the Address Space, minimizing round-trip latency.

The Write Service allows a Client to modify the current value of writable Variable Nodes. Beyond simple scalar updates, OPC UA supports IndexRange parameters for partial writes into arrays and matrices.

• Scalar Write: Update a single value, such as a setpoint temperature.
• Array Write: Modify a specific element within an array using an IndexRange (e.g., [5] to target the sixth element).
• Matrix Write: Update a sub-region of a two-dimensional matrix using multi-dimensional IndexRanges.
• StatusCode Return: Each write target receives an individual StatusCode, allowing partial success in bulk operations.

Instead of polling, Clients create Subscriptions that contain Monitored Items to receive automatic, event-driven notifications when data changes. This publish-subscribe pattern within the Client-Server model drastically reduces network overhead.

• Sampling Interval: The rate at which the Server evaluates a Monitored Item's value for changes.
• Publishing Interval: The cadence at which the Subscription delivers queued notifications to the Client.
• Queue Size: Defines how many notifications the Server buffers if the Client is temporarily unreachable.
• Keep-Alive: Periodic empty messages ensure the Subscription remains active and the connection is healthy.

To suppress noise and reduce unnecessary network traffic, Monitored Items can be configured with Data Change Filters. The most common is the Deadband Filter, which prevents notifications unless a value change exceeds a defined threshold.

• Absolute Deadband: A notification triggers only if |current_value - last_reported_value| exceeds the deadband value.
• Percent Deadband: The threshold is calculated as a percentage of the engineering unit range (EURange) of the Variable.
• StatusCode Triggers: Notifications can also be configured to fire on StatusCode changes alone, even if the value remains static.
• Filter Operand: Advanced filters allow Clients to specify complex trigger conditions using mathematical operands.

Every Data Access value is accompanied by a StatusCode that encodes the operational quality, sub-status, and limit conditions of the measurement. This is critical for deterministic control logic.

• Quality Bits: Indicate Good, Bad, or Uncertain data quality at a glance.
• Sub-Status: Provides granular detail, such as Bad_SensorFailure or Uncertain_LastUsableValue.
• Limit Bits: Flag whether a value is at a High, Low, or Constant engineering limit.
• Source Timestamp: Marks the exact moment the data was sampled at the physical sensor or controller.

Before reading or writing, a Client must discover what data is available. The View Services (Browse, BrowseNext) allow Clients to navigate the Server's Address Space hierarchically and programmatically.

• Browse: Starting from a root Node, the Client requests the list of forward References (e.g., HasComponent) to discover child Nodes.
• BrowseNext: Used when the Server's response indicates more results are available than fit in a single message.
• Type Filtering: Clients can restrict browsing to specific NodeClasses, such as only returning Variable Nodes.
• Continuation Points: Stateless pointers that allow a Client to resume a large browse operation across multiple requests.

The primary synchronous request/response mechanism used by a Client to retrieve the current value, status, and timestamp of one or more Variable Node Attributes. The Client specifies a list of ReadValueIds, each containing a NodeId and an AttributeId. The Server returns a corresponding list of DataValues with a StatusCode indicating quality. This service supports max-age parameters, allowing a Client to request a value from the Server's cache if it is fresher than a specified interval, optimizing for speed over absolute accuracy in high-frequency polling scenarios.

The synchronous mechanism for a Client to update the values of one or more Variable Nodes. Each write operation targets a specific NodeId and AttributeId, sending a new DataValue. The Server validates the request against the Node's DataType, ValueRank, and access level permissions defined in the Address Space. A successful write updates the SourceTimestamp and triggers associated Subscriptions to notify other Clients of the change. This service is critical for sending setpoints, commands, and configuration parameters to industrial equipment.

The asynchronous, event-driven alternative to polling. A Client creates a Subscription within a Session to define pacing and publishing intervals. Within that Subscription, the Client adds MonitoredItems, each watching a specific Node Attribute. The Server samples the value at a configurable SamplingInterval and queues a NotificationMessage only when a change exceeds the Deadband Filter threshold. This model drastically reduces network overhead compared to continuous polling, making it essential for high-frequency sensor telemetry and alarm monitoring.

Extends basic Data Access by defining how Clients retrieve time-series data and event logs stored in a Server's historian. Rather than just reading the current value, a Client can call HistoryRead to request raw data, aggregated summaries, or modified values over a specified time domain. Common aggregates include Interpolative, Average, and TimeAverage2. This service set is foundational for predictive maintenance algorithms and post-incident root cause analysis, allowing engineers to replay and analyze process behavior leading up to a failure event.

A stateful eventing model that goes beyond simple threshold violations. Unlike a basic MonitoredItem that reports a value crossing a limit, an Alarm is a specific Condition type with a defined lifecycle: Inactive, Active, Acknowledged, and Confirmed. A LimitAlarm monitors a Variable against a high or low setpoint. When triggered, it requires explicit human acknowledgment via the Acknowledge Method. This two-way handshake ensures critical safety interlocks and process deviations are not just logged but actively managed, supporting ISA-18.2 alarm management standards.

A critical data suppression mechanism applied to a MonitoredItem to prevent network flooding from noisy analog signals. The AbsoluteDeadband filter calculates the change between the last reported value and the current sample. A notification is generated only if the absolute difference exceeds the defined threshold. For example, a temperature sensor fluctuating by ±0.1°C with a deadband of 0.5°C will not trigger updates until a meaningful thermal shift occurs. This filter is essential for preserving bandwidth in large-scale SCADA integrations.