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 in a proprietary data collection, database or a short-term buffer within 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 Historian may be implemented as a standalone OPC UA Server that collects data from another OPC UA Server or another data source. The Historian may also just aggregate historical data from underlying Historians. The Client that references the OPC UA Server supporting Historical Access for historical data may be simple trending packages that desire values over a given time frame or they may be complex reports that require data in multiple formats.

There are general requirements for Historians, but Historians can vary in functionality. A consistent requirement for all Historians is that they store Historical data including a timestamp. All historical data should include status information for each value, but a Historian may compress this to only storing status information that indicates a problem (Bad status) and/or status change, instead of storing a status for every time series data item. The status of historical data can be complex. What is required is that the values returned as part of the timeseries raw data match the data that would have been observed if the Value was subscribed to at that point in time.

Historical Events are more complicated. In a stream of Events each Event can have a different list of fields. EventTypes are defined in a hierarchical manner, where each EventType inherits fields from its parent type and can add additional fields. Some of these additional fields may be mandatory and are required to understand or process the given EventType. A Historian that stores Events, shall be configurable to store all mandatory fields for any EventTypes that it historizes. If it receives for storage an EventType that it does not support all mandatory fields for, it may store it as one of its supertype EventTypes (one that it does support all mandatory fields for), but then it shall not claim that it supports historizing of that EventType (see 5.4.3). The Historian shall also provide information about the fields that are currently being historized (see 5.4.3).