Part 11: Historical Access
| Document number | OPC 10000-11 |
|---|---|
| IEC designation | IEC 62541-11 |
| Colloquially | Part 11 |
| Group | Access type |
Part 11 defines historical access: the HistoryRead and HistoryUpdate services with their raw, modified, at-time, processed and event variants, annotations, and the HistoricalDataConfiguration object that describes how a node's history is stored. It is how you get a time series out of a server rather than a live value.
The read details
HistoryRead takes one of several detail structures that select a mode. Raw and modified reads return stored values over a time range, optionally including superseded versions. An at-time read returns the value at each of a list of specific timestamps. A processed read asks the server to compute aggregates over intervals, which hands the work to Part 13. An event read returns historical events with a filter. Annotation reads return operator notes attached to points in the series.
Paging, bounds and empty intervals
History results are paged with continuation points, and a request can legitimately return nothing. An empty interval comes back as GoodNoData - a Good code - so client code that only tests for Bad concludes it received data. Requests can also ask for bounding values: the last point before the interval and the first point after it, so a chart can draw a line into the window from outside it. Those bounds carry timestamps outside the range you asked for, and BadBoundNotFound tells you no bound exists.
HistoricalDataConfiguration
A historised node carries a configuration object describing how its history behaves: whether the value is stepped or interpolatable, the minimum and maximum time intervals between stored points, the exception deviation used when the archive was written, and the start of the archive and the start of the online archive. This is the metadata that makes an aggregate correct. The Stepped flag in particular changes what an average means, and Part 13 depends on it.
Writing history
HistoryUpdate covers insert, replace, update and delete for both data and events, along with annotation writes. Servers advertise what they permit through the history bits of AccessLevel, and most production historians permit none of it. Where it is permitted, an audit event is expected for every change, because rewriting history is exactly the kind of operation a regulated plant has to be able to reconstruct.
What it defines
| Concept | What it is |
|---|---|
| HistoryRead | The service, taking a detail structure, a TimestampsToReturn, and a list of nodes. Batched like every other service, with a per-node StatusCode and continuation point. |
| Raw and modified reads | Return stored values over a time range. The modified variant also returns superseded versions, which is how you audit an edited archive. |
| At-time reads | Return the value at each of an explicit list of timestamps, interpolated or stepped according to the node's configuration. The right call for aligning several tags onto one grid. |
| Processed reads | Ask the server to compute aggregates over fixed intervals using the Part 13 functions. Far cheaper than pulling raw data and averaging it yourself. |
| Event history | Historical event reads with an EventFilter, which is how alarm history is retrieved. Availability is independent of data history. |
| Annotations | Operator or system notes attached to a time. Read and written separately from the values, and commonly unimplemented. |
| HistoryUpdate | Insert, replace, update and delete for data and events. Gated by the AccessLevel history-write bit and expected to raise audit events. |
| HistoricalDataConfiguration | Per-node metadata: Stepped, MinTimeInterval, MaxTimeInterval, ExceptionDeviation, StartOfArchive, StartOfOnlineArchive. Read it before computing anything. |
| Stepped | Declares whether values hold until the next point or may be interpolated between points. Getting this wrong makes every average wrong, not just approximate. |
| Bounding values | The points immediately outside the requested interval, returned on request so a chart can be drawn without a gap at each edge. |
Do you need to read it?
Anyone extracting time series for analytics, reporting or OEE, and anyone building a trend display. Also anyone specifying a historian: whether a server supports raw reads, processed reads or both, and whether it exposes HistoricalDataConfiguration, decides how much work lands on your side.
Traps that trace back to this part
- GoodNoData is a Good code. A read of an interval with nothing stored succeeds and returns an empty array, so a client that branches on severity alone treats a gap in the archive as a successful read of no data and silently loses the interval. Test explicitly for it.
- Bounding values fall outside the range you asked for. Chart and resampling code that assumes every returned timestamp is inside the window either draws points off the axis or misaligns the first bucket. Either request bounds and handle them deliberately, or do not request them.
- The Stepped flag decides whether interpolation is legal for that node. A stepped value averaged as though it were interpolated - or a continuous value treated as stepped - produces plausible numbers that are wrong, and nothing in the response tells you. Read HistoricalDataConfiguration and honour it.
- History is keyed on SourceTimestamp where one exists, and on the server's own clock where the device supplies none. On a mixed system that means two tags recorded from the same event can be tens or hundreds of milliseconds apart in the archive, which matters as soon as you correlate them.
Last verified 7 September 2026 against OPC UA 1.05.07. The specification parts themselves are published by the OPC Foundation. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.