6 Historical Access specific usage of Services ToC Previous Next

6.4 HistoryReadDetails parameters ToC Previous Next

6.4.4 ReadProcessedDetails structure ToC Previous Next

6.4.4.1 ReadProcessedDetails structure details ToC

Table 22 defines the structure of the ReadProcessedDetails structure.

Table 22 – ReadProcessedDetails

Name Type Description
ReadProcessedDetails Structure Specifies the details used to perform a “processed” history read.
   startTime UtcTime Beginning of period to read.
   endTime UtcTime End of period to read.
   ProcessingInterval Duration Interval between returned Aggregate values. The value 0 indicates that there is no ProcessingInterval defined.
   aggregateType[] NodeId The NodeId of the HistoryAggregate object that indicates the list of Aggregates to be used when retrieving the processed history. SeeOPC 10000-13 for details.
   aggregateConfiguration Aggregate
Configuration
Aggregate   configuration structure.
      useServerCapabilitiesDefaults Boolean As described in OPC 10000-4.
      TreatUncertainAsBad Boolean As described in OPC 10000-13.
      PercentDataBad Byte As described in OPC 10000-13.
      PercentDataGood Byte As described in OPC 10000-13.
      UseSlopedExtrapolation Boolean As described in OPC 10000-13.

SeeOPC 10000-13 for details on possible NodeId values for the aggregateType parameter.

6.4.4.2 Read processed functionality ToC

This structure is used to compute Aggregate values, qualities, and timestamps from data in the history database for the specified time domain for one or more HistoricalDataNodes. The time domain is divided into intervals of duration ProcessingInterval. The specified Aggregate Type is calculated for each interval beginning with startTime by using the data within the next ProcessingInterval.

For example, this function can provide hourly statistics such as Maximum, Minimum, and Average for each item during the specified time domain when ProcessingInterval is 1 hour.

The domain of the request is defined by startTime, endTime, and ProcessingInterval. All three shall be specified. If endTime is less than startTime then the data shall be returned in reverse order with the later data coming first. If startTime and endTime are the same then the Server shall return Bad_InvalidArgument as there is no meaningful way to interpret such a case. If the ProcessingInteval is specified as 0 then Aggregates shall be calculated using one interval starting at startTime and ending at endTime.

The aggregateType[] parameter allows a Client to request multiple Aggregate calculations per requested NodeId. If multiple Aggregates are requested then a corresponding number of entries are required in the NodesToRead array.

For example, to request Min Aggregate for NodeId FIC101, FIC102, and both Min and Max Aggregates for NodeId FIC103 would require NodeId FIC103 to appear twice in the NodesToRead array request parameter.

aggregateType[] NodesToRead[]
   Min    FIC101
   Min    FIC102
   Min    FIC103
   Max    FIC103

If the array of Aggregates does not match the array of NodesToRead then the Server shall return a StatusCode of Bad_AggregateListMismatch.

The aggregateConfiguration parameter allows a Client to override the Aggregate configuration settings supplied by the AggregateConfiguration Object on a per call basis. SeeOPC 10000-13 for more information on Aggregate configurations. If the Server does not support the ability to override the Aggregate configuration settings then it shall return a StatusCode of Bad_ AggregateConfigurationRejected. If the Aggregate is not valid for the Node then the StatusCode shall be Bad_AggregateNotSupported.

The values used in computing the Aggregate for each interval shall include any value that falls exactly on the timestamp at the beginning of the interval, but shall not include any value that falls directly on the timestamp ending the interval. Thus, each value shall be included only once in the calculation. If the time domain is in reverse order then we consider the later timestamp to be the one beginning the subinterval, and the earlier timestamp to be the one ending it. Note that this means that simply swapping the start and end times will not result in getting the same values back in reverse order as the intervals being requested in the two cases are not the same.

If an Aggregate is taking a long time to calculate then the Server can return partial results with a continuation point. This might be done if the calculation is going to take more time than the Client timeout hint. In some cases it may take longer than the Client timeout hint to calculate even one Aggregate result. Then the Server may return zero results with a continuation point that allows the Server to resume the calculation on the next Client read call.

Refer toOPC 10000-13 for handling of Aggregate specific cases.

Previous Next