Historical Access

This chapter describes the OPC UA Historical Access functionality of the WinCC OA OPC UA client which allows to query historical data of an OPC UA server.

To start the reading of historical data as well as configuring the read request, an internal datapoint must be used. The queried data can be used in the following ways:

Writing the data to an internal datapoint: In this case, the received data is mapped onto an internal datapoint from where the data can be used for further data processing. Therefore it is possible to execute historical read requests for historical data nodes of the server that are not configured via peripheral addresses in the WinCC OA project.
Writing the data to datapoint element with appropriate peripheral address: This allows to automatically insert the received data into the _archive config of all datapoint elements with the appropriate peripheral address. Therefore, it is possible to retrieve data from the server e.g. for a time interval in which the connection to the server was lost.

Historical data request

The internal datapoint element _OPCUAServer.Command.HistoryRead is used for triggering a historical read request as well as configuring its parameters.

Depending on the configuration of this datapoint element, the received data is either written to a response datapoint of type _OPCUAHistoryReadResponse or to the archive of datapoint elements with the appropriate peripheral address.

1. Write data to response datapoint

To map the received data onto a response datapoint proceed as follows:

Create a response datapoint
Create a datapoint of type _OPCUAHistoryReadResponse.
Example: responseDP
After that the created response datapoint must be entered at the internal data point element _OPCUA<Treibernummer>.Config.HistoryReadResponseDps. Thus it can be used for receiving data.
Start the request

Now it is possible to start the reading of historical data via the internal data point element _OPCUAServer.Command.HistoryRead. In order to write the data to the response datapoint, either method 1 (state the NodeId of the item which shall be queried) or 2 (state the BrowsePath of the item which shall be queried) must be selected (refer to _OPCUAServer.Command.HistoryRead - Method).

Example - Method 1:

 RequestId123
 ReadRaw
 1
 ns=2;s=AirConditioner_2.Temperature
 2015.03.03 09:00:00.000
 2015.03.03 09:10:00.000
 20
 0
 responseDP1

Example - Method 2:

 RequestId123
 ReadRaw
 2
 /0:Objects/0:Server/2:AreaAirConditioner/2:AirConditioner_2/2:Temperature
 2015.03.03 09:00:00.000
 2015.03.03 09:10:00.000
 20
 0
 responseDP1

Click on the Apply button in the PARA module and the request is triggered with the defined parameters. Click here for a detailed parameter description.

Data processing

The result of the request is written to the defined response datapoint (responseDP1) and can be used for further data processing.

2. Write data to _archive Config of datapoint elements

It is possible to write the historical values to datapoint elements with the specified peripheral address by using method 3. Proceed as follows:

Peripheral address

You have to determine a valid peripheral address via the datapoint element HW.HWMask of internal datapoint type _DriverCommon. If the _address config is linked to e.g. item ID "ns=2;s=AirConditioner_2.Temperature", this ID is not the correct peripheral address. In this case the valid address is: "opcua_server$Subscription$1$1$ns=2;s=AirConditioner_2.Temperature"

Note:

You can also define a wildcard which queries exactly this one specific address. In this case the correct wildcard would be *ns=2;s=AirConditioner_2.Temperature"

You can request historical values from several peripheral addresses and write the result to the archive of all appropriate datapoint elements. Therefore, wildcards must be used.

When writing the data of historical requests to the WinCC OA archive, the timestamp defined in the subscription of the appropriate datapoint element is used. Use the internal datapoint element OPCUAServer.Config.HistoryReadTimestamps to define which timestamp will be used in case that no subscription is defined (the source timestamp is used by default).

Note:

The OPC UA client only performs historical requests for datapoint elements where the history checkbox in the peripheral address panel is enabled (see also Notes and restrictions).

In order to label the queried data with a specific user bit the config entry userBitHistoryRead must be used. If the historical values shall be written as correction values, the config entry histDataBits must be set additionally.

Response datapoint

The response datapoint is not mandatory when using method 3. However, important information like RequestId, ReturnCode or DpList is returned in case that a response datapoint is defined.

Start the request

After defining method 3 as well as a valid peripheral address, the request can be started by clicking on the Apply button in the PARA module.

Example:

 RequestId123
 ReadRaw
 3
 ns=2;s=AirConditioner_2.Temperature
 2015.03.03 09:00:00.000
 2015.03.03 09:10:00.000
 20
 0
 responseDP2

Redundancy behavior

OPC UA server redundancy

The History Access interface of the WinCC OA OPC UA client supports OPC UA server redundancy.

In case of a non-transparent redundant OPC UA server the OPC UA client only sends a HistoryRead request to the first accessible server by default. In order to handle missing historical data on one of the two redundant servers, the OPC UA client provides the possibility to send the HistoryRead request to both servers. In this case the OPC UA Client will merge the result of the history read service requests from both servers.

In case that both servers return different values for an identical timestamp, the value of the first server is used.

The Redu.Config.HistoryReadMode datapoint element must be used for configuring the redundancy behavior.

OPC UA client redundancy

In case of redundant WinCC OA clients, both clients transmit the historical request to the server. There seem to be two separate requests for the server. The actual active/passive mechanism as well as the related discarding of values is performed in WinCC OA. In order to avoid data loss during the switch-over, it is recommended that both clients perform historical requests. The advantage of this redundancy variant is that the server does not have to support any redundancy abilities.

If that the passive OPC UA client should not transmit historical requests to the server, configure the behavior of the passive client via config entry historyReadMode.

Notes & restrictions

Notes

Since not every node in the OPC UA address space might contain history data, the internal datapoint element _OPCUAServer.Browse.AccessLevel indicates whether historical data is available for the respective nodes.

The _offset attribute of the _address config is used for indicating whether historical data is available on the server for the peripheral address in WinCC OA. When using method 3, the OPC UA client only performs a read request if the _offset attribute is set for the peripheral address. Therefore, the "History" checkbox must be enabled at the panel for defining the peripheral address of the OPC UA driver. The structure of the _offset attribute is as follows:


Bit	Description
0	Indicates whether historical data is available on the server for this peripheral address. 0 = no historical data available 1 = historical data is available
1-15	Reserved for future use

Restrictions

Only read access to historical data of an OPC UA server is possible, write requests are not supported.
The WinCC OA OPC UA client only supports the function ReadRaw of the OPC UA service History Read.
The WinCC OA OPC UA client does not support historical aggregates.

Example panel

There is an example panel (/panels/examples/OPCUA_HA_Example.pnl) which provides the following functionality:

Browse the server items and display them
Run historical queries with user-defined parameters
Display the data in a table