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 data point must be used. The queried data can be used in the following ways:

  • Writing the data to an internal data point: In this case, the received data is mapped onto an internal data point 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 data point element with appropriate peripheral address: This allows to automatically insert the received data into the _archive config of all data point 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 data point element _OPCUAServer.Command.HistoryRead is used for triggering a historical read request as well as configuring its parameters.

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

1. Write data to response data point

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

Create a response data point

Create a data point of type _OPCUAHistoryReadResponse.

Example: responseDP

After that the created response data point 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 data point, 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 data point (responseDP1) and can be used for further data processing.

2. Write data to _archive Config of data point elements

It is possible to write the historical values to data point 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 data point element HW.HWMask of internal data point 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

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

It is possible to request historical values from several peripheral addresses and write the result to the archive of all appropriate data point 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 data point element is used. Use the internal data point element OPCUAServer.Config.HistoryReadTimestamps to define which timestamp shall 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 data point elements where the "history" checkbox at 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 data point

The response data point is not mandatory when using method 3. However, important information like RequestId, ReturnCode or DpList is returned in case that a response data point 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 data point 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.

In case that the passive OPC UA client shall 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 data point 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