Historical access

An OPC UA server can store the history of variable values and events and let clients read past periods. Part 4 defines the HistoryRead service in section 5.10.3; Part 11 (Historical Access) defines the detailed rules.

Nodes with history

Two attributes tell you whether a variable provides history:

• Historizing (attribute 20): whether the server is currently storing the variable’s history.
• The HistoryRead bit (0x04) of AccessLevel (attribute 17): whether you can read the history.

The PDComm simulator stores the history of Simulator.Double and Simulator.Counter. Simulator.Double is recorded on every write and Simulator.Counter on every simulation tick (500 ms by default). Both initial values are also recorded once when the server starts.

The HistoryRead request

A HistoryRead request carries details that select how to read (HistoryReadDetails) and a list of nodes:

Details	Use
ReadRawModifiedDetails	Read stored raw values over a period.
ReadProcessedDetails	Read values computed by an aggregate function; Part 13 defines the aggregates.
ReadAtTimeDetails	Read the values at given timestamps.
ReadEventDetails	Read event history.

The fields of ReadRawModifiedDetails, the one you’ll use most:

Field	Meaning
startTime, endTime	The period to read
numValuesPerNode	Maximum values per node in one response; 0 means no limit
returnBounds	Whether to also return the values at the period’s bounds
isReadModified	Whether to read modification history instead of raw values

The request’s timestampsToReturn selects which timestamps go into the result DataValues: Source, Server, Both or Neither.

Continuation points

When the period holds more values than numValuesPerNode, the server returns part of them plus a continuation point. You get the rest by calling HistoryRead again with the continuation point.

HistoryRead(start, end, numValuesPerNode=2)                -> values 1..2, continuation point A
HistoryRead(same details, continuation point A)            -> values 3..4, no continuation point
HistoryRead(same details, point B, releaseContinuationPoints) -> point B released, no values

• Continue with the same details as the first request. PDComm servers return BadContinuationPointInvalid when the details differ.
• If you don’t need the remaining values, release the continuation point by setting releaseContinuationPoints to true. Continuation points are server resources.
• A continuation point can’t be used twice.

Result statuses

Status	Meaning
Good (0x00000000)	Values were read.
GoodNoData (0x00A50000)	The period holds no values.
BadContinuationPointInvalid (0x804A0000)	The continuation point is unknown, or the details differ from the first request.
BadHistoryOperationUnsupported (0x80720000)	The server doesn’t support the requested history operation.

The low bits of a history value’s StatusCode carry historian bits. 0x00000408, for example, means Good with more values at the same timestamp (HistorianExtraData). In the simulator you see it on the first value of Simulator.Counter, because two values are recorded in the same millisecond right after the server starts.

PDComm servers return BadHistoryOperationUnsupported for a history read of an existing node whose history isn’t stored (its AccessLevel has no HistoryRead bit) and BadNodeIdUnknown for a node that doesn’t exist. A historized node with no values in the period returns GoodNoData.

In PDComm

SDK. The client builds a HistoryReadRequest (i=664) in UA Binary and sends it with pdcomm_opcua_client_begin. The SDK in-memory server doesn’t store history.

Simulator. The history_read action uses ReadRawModifiedDetails and asks for Source timestamps:

Argument	Default
node	ns=2;s=Simulator.Double
start, end	One hour ago and one minute from now (Unix milliseconds)
max	100 (numValuesPerNode, 1 to 1000)
continuation	A continuation point in hex; when given, the start, end and max of the previous request are reused.
release	true releases the continuation point.

Try it in the history tutorial.

Next steps

PubSub introduces the connectionless model.