This standard defines the handling of historical time series data and historical Event data in the OPC Unified Architecture. Included is the specification of the representation of historical data and Events in the AddressSpace.

A Server supporting Historical Access provides Clients with transparent access to different historical data and/or historical Event sources (e.g. process historians, event historians, etc.).

The historical data or Events may be located in a proprietary data collection, database or a short term buffer within the memory. A Server supporting Historical Access will provide historical data and Events for all or a subset of the available Variables, Objects, Properties or Views within the Server AddressSpace.

Figure 1 illustrates how the AddressSpace of a UA Server might consist of a broad range of different historical data and/or historical Event sources.

Figure 1 – Possible OPC UA Server supporting Historical Access

The Server may be implemented as a standalone OPC UA Server that collects data from another OPC UA Server or another data source. The Client that references the OPC UA Server supporting Historical Access for historical data may be simple trending packages that just desire values over a given time frame or they may be complex reports that require data in multiple formats.

The nature of OPC UA Historical Access requires that a single timestamp reference be used to relate the multiple data points, and the Client may request which timestamp will be used as the reference. See OPC 10000-4 for details on the TimestampsToReturn enumeration. An OPC UA Server supporting Historical Access will treat the various timestamp settings as described below. A HistoryRead with invalid settings will be rejected with Bad_TimestampsToReturnInvalid (see OPC 10000-4).

For HistoricalDataNodes , the SourceTimestamp is used to determine which historical data values are to be returned.

The request is in terms of SourceTimestamp but the reply could be in SourceTimestamp, ServerTimestamp or both timestamps. If the reply has the Server timestamp the timestamps could fall outside of the range of the requested time.

SOURCE_0Return the SourceTimestamp.

SERVER_1Return the ServerTimestamp.

BOTH_2Return both the SourceTimestamp and ServerTimestamp.

NEITHER_3This is not a valid setting for any HistoryRead accessing HistoricalDataNodes.

Any reference to timestamps in this context throughout this standard will represent either ServerTimestamp or SourceTimestamp as dictated by the type requested in the HistoryRead Service. Some Servers may not support historizing both SourceTimestamp and ServerTimestamp, but it is expected that all Servers will support historizing SourceTimestamp (see OPC 10000-7 for details on Server Profiles).

If a request is made requesting both ServerTimestamp and SourceTimestamp and the Server is only collecting the SourceTimestamp the Server shall return Bad_TimestampsToReturnInvalid.

For HistoricalEventNodes this parameter does not apply. This parameter is ignored since the entries returned are dictated by the Event Filter. See OPC 10000-4 for details.

When accessing HistoricalDataNodes via the HistoryRead Service, requests can set a flag, returnBounds, indicating that BoundingValues are requested. For a complete description of the Extensible Parameter HistoryReadDetails that include StartTime, EndTime and NumValuesPerNode, see 6.4. The concept of Bounding Values and how they affect the time domain that is requested as part of the HistoryRead request is further explained in 4.4. 4.4 also provides examples of TimeDomains to further illustrate the expected behaviour.

When making a request for historical data using the HistoryRead Service, the required parameters include at least 2 of these three parameters: startTime, endTime and numValuesPerNode. What is returned when Bounding Values are requested varies according to which of these parameters are provided. For a historian that has values stored at 5:00, 5:02, 5:03, 5:05 and 5:06, the data returned when using the Read Raw functionality is given by Table 1. In the table, FIRST stands for a tuple with a value of null, a timestamp of the specified StartTime, and a StatusCode of Bad_BoundNotFound. LAST stands for a tuple with a value of null, a timestamp of the specified EndTime, and a StatusCode of Bad_BoundNotFound.

In some cases, attempting to locate bounds, particularly FIRST or LAST points, may be resource intensive for Servers. Therefore how far back or forward to look in history for Bounding Values is Server dependent, and the Server search limits may be reached before a bounding value can be found. There are also cases, such as reading Annotations or Attribute data where Bounding Values may not be appropriate. For such use cases it is permissible for the Server to return a StatusCode of Bad_BoundNotSupported.

Table 1 – Bounding Value examples

Start Time	End Time	numValuesPerNode	Bounds	Data Returned
5:00	5:05	0	Yes	5:00, 5:02, 5:03, 5:05
5:00	5:05	0	No	5:00, 5:02, 5:03
5:01	5:04	0	Yes	5:00, 5:02, 5:03, 5:05
5:01	5:04	0	No	5:02, 5:03
5:05	5:00	0	Yes	5:05, 5:03, 5:02, 5:00
5:05	5:00	0	No	5:05, 5:03, 5:02
5:04	5:01	0	Yes	5:05, 5:03, 5:02, 5:00
5:04	5:01	0	No	5:03, 5:02
4:59	5:05	0	Yes	FIRST, 5:00, 5:02, 5:03, 5:05
4:59	5:05	0	No	5:00, 5:02, 5:03
5:01	5:07	0	Yes	5:00, 5:02, 5:03, 5:05, 5:06, LAST
5:01	5:07	0	No	5:02, 5:03, 5:05, 5:06
5:00	5:05	3	Yes	5:00, 5:02, 5:03
5:00	5:05	3	No	5:00, 5:02, 5:03
5:01	5:04	3	Yes	5:00, 5:02, 5:03
5:01	5:04	3	No	5:02, 5:03
5:05	5:00	3	Yes	5:05, 5:03, 5:02
5:05	5:00	3	No	5:05, 5:03, 5:02
5:04	5:01	3	Yes	5:05, 5:03, 5:02
5:04	5:01	3	No	5:03, 5:02
4:59	5:05	3	Yes	FIRST, 5:00, 5:02
4:59	5:05	3	No	5:00, 5:02, 5:03
5:01	5:07	3	Yes	5:00, 5:02, 5:03
5:01	5:07	3	No	5:02, 5:03, 5:05
5:00	UNSPECIFIED	3	Yes	5:00, 5:02, 5:03
5:00	UNSPECIFIED	3	No	5:00, 5:02, 5:03
5:00	UNSPECIFIED	6	Yes	5:00, 5:02, 5:03, 5:05, 5:06, LASTa
5:00	UNSPECIFIED	6	No	5:00, 5:02, 5:03, 5:05, 5:06
5:07	UNSPECIFIED	6	Yes	5:06, LAST
5:07	UNSPECIFIED	6	No	NODATA
UNSPECIFIED	5:06	3	Yes	5:06,5:05,5:03
UNSPECIFIED	5:06	3	No	5:06,5:05,5:03
UNSPECIFIED	5:06	6	Yes	5:06,5:05,5:03,5:02,5:00,FIRSTb
UNSPECIFIED	5:06	6	No	5:06, 5:05, 5:03, 5:02, 5:00
UNSPECIFIED	4:48	6	Yes	5:00, FIRST
UNSPECIFIED	4:48	6	No	NODATA
4:48	4:48	0	Yes	FIRST,5:00
4:48	4:48	0	No	NODATA
4:48	4:48	1	Yes	FIRST
4:48	4:48	1	No	NODATA
4:48	4:48	2	Yes	FIRST,5:00
5:00	5:00	0	Yes	5:00,5:02c
5:00	5:00	0	No	5:00
5:00	5:00	1	Yes	5:00
5:00	5:00	1	No	5:00
5:01	5:01	0	Yes	5:00, 5:02
5:01	5:01	0	No	NODATA
5:01	5:01	1	Yes	5:00
5:01	5:01	1	No	NODATA
aThe timestamp of LAST cannot be the specified End Time because there is no specified End Time. In this situation the timestamp for LAST will be equal to the previous timestamp returned plus one second. b The timestamp of FIRST cannot be the specified End Time because there is no specified Start Time. In this situation the timestamp for FIRST will be equal to the previous timestamp returned minus one second. c When the Start Time = End Time (there is data at that time), and Bounds is set to True, the start bounds will equal the Start Time and the next data point will be used for the end bounds.

Clients use the browse Services of the View Service Set to navigate through the AddressSpace to discover the HistoricalNodes and their characteristics. These Services provide the most current information about the AddressSpace. It is possible and probable that the AddressSpace of a Server will change over time (i.e. TypeDefinitions may change; NodeIds may be modified, added or deleted).

Server developers and administrators need to be aware that modifying the AddressSpace may impact a Client’s ability to access historical information. If the history for a HistoricalNode is still required, but the HistoricalNode is no longer historized, then the Object should be maintained in the AddressSpace, with the appropriate AccessLevel Attribute and Historizing Attribute settings (see OPC 10000-3 for details on access levels).