OPC UA Historical Access (HA) is the part of the OPC UA specification that standardizes reading and writing of historical process data. While live data access answers "what is the value now?", historical access answers "what happened, when, and what was the value between two timestamps?". Because HA is defined inside the same address space as live data, a single OPC UA client can browse, subscribe to live values, and retrieve history through one consistent interface — which is why historians, analytics platforms, and MES systems increasingly use UA HA instead of vendor-specific APIs.
What Historical Access Covers
OPC UA Part 11 (Historical Access) defines two main service groups:
- HistoricalRead — retrieve stored values, events, or annotations for a time range.
- HistoricalUpdate — insert, replace, or delete stored values and annotations (typically restricted to the server's own applications).
Historical data is exposed through HistoricalDataNodes (variables marked with the Historizing attribute) and through the server's HistoryServerCapabilities, which tells clients what the server supports: interpolation, aggregates, multiple time domains, and so on.
Reading Modes and Aggregates
Raw reads
A raw read returns the stored samples as they were recorded: each sample has its value, quality, and source timestamp. Clients can read raw data between two timestamps, optionally bounded by a maximum number of values, and the server may return "continuation points" for paging through very large result sets.
Processed reads with aggregates
Rather than transferring thousands of raw samples, clients request aggregates — precomputed summaries over time intervals. The standard defines a large set of aggregates:
| Aggregate | Meaning |
|---|---|
| Average | Mean of values in the interval |
| Minimum / Maximum | Extreme values in the interval |
| Count | Number of values in the interval |
| DurationInState | How long a value stayed in a given state |
| Start / End / Delta | First, last, or change of value across the interval |
| TimeAverage / TimeAverage2 | Time-weighted average (correct for irregular sampling) |
| Total / Total2 | Sum over the interval (e.g., energy, flow totals) |
| PercentBad | Fraction of time the value was bad quality |
Aggregates are calculated by the server, which keeps the data volume small and the calculation consistent for all clients. A client requesting daily averages of a temperature trend receives one value per day, computed the same way for every consumer.
Time Domains and Timestamps
Every stored sample carries two timestamps:
- Source timestamp — when the value was captured at the source (e.g., by the PLC).
- Server timestamp — when the historian received it.
Well-designed historians preserve both and let clients read by either. Be aware of clock synchronization: if PLCs, gateways, and historian run on different clocks, source timestamps can be misleading. Use NTP/SNTP (or IEEE 1588/PTP where required) to keep the fleet synchronized; the time-quality of the samples is often recorded too.
Historizing Configuration
On most UA servers that support history, configuration involves:
- Selecting nodes: mark which variables are historized (enable the Historizing attribute on the variable node).
- Sampling: define the capture rate (on-change, periodic, or both) and deadbands.
- Storage: choose the backing store — the server's internal database, a SQL database, or an external historian.
- Retention: set how long data is kept, and the roll-up strategy (e.g., keep raw data 1 year, hourly averages 5 years).
- Continuity: ensure the store survives restarts; a historian that loses the last 10 minutes on every restart is a liability.
Integrating HA with a Data Historian
Many plants use a dedicated data historian (see the Data Historian Selection and Deployment article) as the long-term store, with OPC UA HA as the interface. Typical architecture:
PLC / DCS --OPC UA--> Historian (collects + stores)
|
|--OPC UA HA--> MES / analytics / dashboards
|--OPC UA HA--> Engineering analysis tools
|--OPC UA HA--> Cloud data platform (edge relay)
The historian collects once and serves many consumers through UA HA, avoiding multiple collection paths and inconsistent stores. The same pattern works with the historian acting as a UA server in front of a SQL database.
Common Pitfalls
- Non-uniform timestamps. Mixing source and server timestamps in one dataset corrupts intervals; pick one time basis and document it.
- Data loss on restart. Verify that the historian flushes buffered data to durable storage before shutdown.
- Quality filtering. Decide whether bad-quality samples are stored, and whether aggregates include them (PercentBad exists precisely to quantify this).
- Retention vs. disk. Raw data grows quickly; plan retention and roll-up before the disk fills, and monitor historian disk usage.
- Client-side interpolation. If the server cannot provide interpolated reads, clients must handle gaps themselves; check the server's capabilities first.
Summary
OPC UA Historical Access turns process history into a standard, browsable service instead of a vendor-specific export. By using raw reads for analysis, aggregates for dashboards and reports, and a well-configured historian as the single store, plants get consistent, queryable, long-term process data that serves operations, engineering, and business systems alike.