The HistoryRead Service defined in OPC 10000-4 can perform several different functions. The HistoryReadDetails parameter is an Extensible Parameter that specifies which function to perform and the details that are specific to that function. See OPC 10000-4 for the definition of Extensible Parameter. Table 27 lists the symbolic names of the valid Extensible Parameter structures. Some structures will perform different functions based on the setting of its associated parameters. For simplicity the functionality of each structure is listed. For example, text such as ‘using the Read modified functionality’ refers to the function the HistoryRead Service performs using the Extensible Parameter structure ReadRawModifiedDetails with the isReadModified Boolean parameter set to TRUE.

Table 27 – HistoryReadDetails parameter Symbolic Names

Symbolic Name	Functionality	Description
ReadEventDetails	Read event	This structure selects a set of Events from the history database by specifying a filter and a time domain for one or more Objects or Views. See 6.5.2.1. When this parameter is specified, the Server returns a HistoryEvent structure for each operation (see 6.6.4).
ReadEventDetails2	Read event	This structure selects a set of Events from the history database by specifying a filter and a time domain for one or more Objects or Views. See 6.5.2.1. When this parameter is specified, the Server returns a HistoryEvent structure for each operation (see 6.6.4).
ReadEventDetails2	Read event modified	This structure selects a set of modified Events from the history database by specifying a filter and a time domain for one or more Objects or Views. See 6.5.2.3 When this parameter is specified, the Server returns a HistoryModifiedEvent structure for each operation (see 6.6.4).
ReadRawModifiedDetails	Read raw	This structure selects a set of values from the history database by specifying a time domain for one or more Variables. See 6.5.3.1. When this parameter is specified, the Server returns a HistoryData structure for each operation (see 6.6.2).
ReadRawModifiedDetails	Read modified	This parameter selects a set of ModifiedValues from the history database by specifying a time domain for one or more Variables. See 6.5.3.1. When this parameter is specified, the Server returns a HistoryModifiedData structure for each operation (see 6.6.3).
ReadProcessedDetails	Read processed	This structure selects a set of Aggregate values from the history database by specifying a time domain for one or more Variables. See 6.5.4.1. When this parameter is specified, the Server returns a HistoryData structure for each operation (see 6.6.2)
ReadAtTimeDetails	Read at time	This structure selects a set of raw or interpolated values from the history database by specifying a series of timestamps for one or more Variables. See 6.5.5.1. When this parameter is specified, the Server returns a HistoryData structure for each operation (see Clause 6.6.2).
ReadAnnotationDataDetails	Read Annotation Data	This structure selects a set of Annotation Data from the history database by specifying a series of timestamps for one or more Variables. See 6.5.6.1. When this parameter is specified, the Server returns an Annotation structure for each operation (see Clause 6.6.6).

The HistoryReadDetails Structure definition in the AddressSpace is shown in Table 28. The Structure is an abstract supertype and contains no fields.

Table 28 – HistoryReadDetails definition

Attribute		Value
BrowseName		HistoryReadDetails
IsAbstract		True
References	NodeClass		BrowseName	DataType	TypeDefinition	Other
Subtype of the Structure defined in OPC 10000-3
Conformance Units
Historical Access Read Raw

Table 29 defines the ReadEventDetails structure. This parameter is only valid for Objects that have the EventNotifier Attribute set to TRUE (see OPC 10000-3). At least two of the three parameters, numValuesPerNode, startTime, and endTime shall be specified.

Table 29 – ReadEventDetails Structure

Name	Type	Description
ReadEventDetails	Structure	Specifies the details used to perform an Event history read.
numValuesPerNode	Counter	The maximum number of Events returned for any Node over the time range. If only one time is specified, the time range shall extend to return this number of Events. The default value of 0 indicates that there is no maximum.
startTime	UtcTime	Beginning of period to read. The default value of DateTime.MinValue indicates that the startTime is unspecified.
endTime	UtcTime	End of period to read. The default value of DateTime.MinValue indicates that the endTime is unspecified.
Filter	EventFilter	A filter used by the Server to determine which HistoricalEventNode should be included. This parameter shall be specified and at least one EventField is required. The EventFilter parameter type is an Extensible parameter type. It is defined and used in the same manner as defined for monitored data items which are specified in OPC 10000-4. This filter also specifies the EventFields that are to be returned as part of the request.

Its representation in the AddressSpace is defined in Table 30.

Table 30 – ReadEventDetails definition

Attribute		Value
BrowseName		ReadEventDetails
IsAbstract		False
References	NodeClass		BrowseName	DataType	TypeDefinition	Other
Subtype of the HistoryReadDetails defined in Table 28
Conformance Units
Historical Access Events

The ReadEventDetails structure is used to read the Events from the history database for the specified time domain for one or more HistoricalEventNodes. The ReadEventDetails2 can also be used. The Events are filtered based on the filter structure provided. This filter includes the EventFields that are to be returned. For a complete description of filter refer to OPC 10000-4.

The startTime and endTime are used to filter on the Time field for Events.

The time domain of the request is defined by startTime, endTime, and numValuesPerNode; at least two of these shall be specified. If endTime is less than startTime, or endTime and numValuesPerNode alone are specified then the data will be returned in reverse order with later/newer data provided first as if time were flowing backward. If all three are specified then the call shall return up to numValuesPerNode results going from startTime to endTime, in either ascending or descending order depending on the relative values of startTime and endTime. If numValuesPerNode is 0 then all of the Events in the range are returned. The default value of startTime, endTime or numValuesPerNode is used to indicate not specified.

It is specifically allowed for the startTime and the endTime to be identical. This allows the Client to request the Event(s) at a single instance in time. When the startTime and endTime are identical then time is presumed to be flowing forward. If no data exists at the time specified then the Server shall return the Good_NoData StatusCode.

The standard ContinuationPoint rules (see 6.3) apply. In addition, the following ContinuationPoint rule applies to ReadEventDetails. If a startTime, endTime and numValuesPerNode are all provided, and if more than numValuesPerNode Events exist within that time range for a given Node, then only numValuesPerNode Events per Node are returned along with a ContinuationPoint.

For an interval in which no data exists, the corresponding StatusCode shall be Good_NoData.

The filter parameter is used to determine which historical Events and their corresponding fields are returned. It is possible that the fields of an EventType are available for real time updating, but not available from the Historian. In this case a StatusCode value will be returned for any Event field that cannot be returned. The value of the StatusCode shall be Bad_NoData.

When reading Events, TimestampsToReturn only applies to Event fields that are of type DataValue. If the requested TimestampsToReturn is not supported for an Event field then the returned value of the Event field is the Bad_TimestampNotSupported StatusCode.

Table 29 defines the ReadEventDetails2 structure. The structure is a subtype of ReadEventDetails. This subtype only adds the readModified Boolean. The description provided in 6.5.2.2 applies when readModified Boolean is set to FALSE. This updated structure can be used for all event retrieval operations.

ReadEventDetails2 is only valid for Objects that have the EventNotifier Attribute set to TRUE (see OPC 10000-3). At least two of the three parameters, numValuesPerNode, startTime, and endTime shall be specified.

Table 31 – ReadEventDetails2 Structure

Name	Type	Description
ReadEventDetails2	Structure	Specifies the details used to perform an Event history read.
readModified	Boolean	TRUE for Read Modified functionality

Its representation in the AddressSpace is defined in Table 30.

Table 32 – ReadEventDetails2 definition

Attribute		Value
BrowseName		ReadEventDetails2
IsAbstract		False
References	NodeClass		BrowseName	DataType	TypeDefinition	Other
Subtype of the ReadEventDetails
Conformance Units
Historical Access Modified Events

When this structure is used for reading ModifiedEvents (isReadModified is set to TRUE), it reads the ModifiedEvents, modification type, the user identifier, and the timestamp of the modification from the history database for the specified time domain for one or more HistoricalDataNodes. If there are multiple replaced Events the Server shall return all of them. The updateType specifies what Event is returned in the modification record. If the updateType is INSERT the Event is the new Event that was inserted. If the updateType is anything else the Event is the old Event that was changed. See 6.9 HistoryUpdateDetails parameter for details on what updateTypes are available.

The purpose of this function is to read Events from history that have been Modified.

The startTime and endTime are used to filter on the Time field for Events.

The domain of the request is defined by startTime, endTime, and numValuesPerNode; at least two of these shall be specified. If endTime is less than startTime, or endTime and numValuesPerNode alone are specified, then the data shall be returned in reverse order with the later data coming first. If all three are specified then the call shall return up to numValuesPerNode results going from StartTime to EndTime, in either ascending or descending order depending on the relative values of StartTime and EndTime. If numValuesPerNode is 0 then all of the Events in the range are returned.

It is specifically allowed for the startTime and the endTime to be identical. This allows the Client to request the Event(s) at a single instance in time. When the startTime and endTime are identical then time is presumed to be flowing forward. If no Events exists at the time specified then the Server shall return the Good_NoData StatusCode.

The standard ContinuationPoint rules (see 6.3) apply. In addition, the following ContinuationPoint rule applies to ReadEventDetails. If a startTime, endTime and numValuesPerNode are all provided, and if more than numValuesPerNode Events exist within that time range for a given Node, then only numValuesPerNode Events per Node are returned along with a ContinuationPoint.

For an interval in which no Events exists, the corresponding StatusCode shall be Good_NoData.

The filter parameter is used to determine which historical Events and their corresponding fields are returned. It is possible that the fields of an EventType are available for real time updating, but not available from the Historian. In this case a StatusCode value will be returned for any Event field that cannot be returned. The value of the StatusCode shall be Bad_NoData.

When reading Events, TimestampsToReturn only applies to Event fields that are of type DataValue. If the requested TimestampsToReturn is not supported for an Event field then the returned value of the Event field is the Bad_TimestampNotSupported StatusCode.

Table 33 defines the ReadRawModifiedDetails structure. Two of the three parameters, numValuesPerNode, startTime, and endTime shall be specified.

Table 33 – ReadRawModifiedDetails structure

Name	Type	Description
ReadRawModifiedDetails	Structure	Specifies the details used to perform a “raw” or “modified” history read.
isReadModified	Boolean	TRUE for Read Modified functionality, FALSE for Read Raw functionality. Default value is FALSE.
startTime	UtcTime	Beginning of period to read. Set to default value of DateTime.MinValue if no specific start time is specified.
endTime	UtcTime	End of period to read. Set to default value of DateTime.MinValue if no specific end time is specified.
numValuesPerNode	Counter	The maximum number of values returned for any Node over the time range. If only one time is specified, the time range shall extend to return this number of values. The default value 0 indicates that there is no maximum.
returnBounds	Boolean	A Boolean parameter with the following values: TRUEBounding Values should be returned FALSEAll other cases

Its representation in the AddressSpace is defined in Table 30.

Table 34 – ReadRawModifiedDetails definition

Attribute		Value
BrowseName		ReadRawModifiedDetails
IsAbstract		False
References	NodeClass		BrowseName	DataType	TypeDefinition	Other
Subtype of the HistoryReadDetails defined in Table 28
Conformance Units
Historical Access Read Raw
Historical Access Modified Values

When this structure is used for reading Raw Values (isReadModified is set to FALSE), it reads the values, qualities, and timestamps from the history database for the specified time domain for one or more HistoricalDataNodes. This parameter is intended for use by a Client that wants the actual data saved within the historian. The actual data may be compressed or may be all RawData collected for the item depending on the historian and the storage rules invoked when the item values were saved. When returnBounds is TRUE, the Bounding Values for the time domain are returned. The optional Bounding Values are provided to allow the Client to interpolate values for the start and end times when trending the actual data on a display.

The time domain of the request is defined by startTime, endTime, and numValuesPerNode; at least two of these shall be specified. If endTime is less than startTime, or endTime and numValuesPerNode alone are specified then the data will be returned in reverse order, with later data coming first as if time were flowing backward. If numValuesPerNode is not specified (set to 0), then all the values in the range are returned. A default value of DateTime.MinValue (see Table 33) is used to indicate when startTime or endTime is not specified. When only startTime (or only endTime) and numValuePerNode is specified, the provided time is used as a starting point and the requested number of values is returned.

The standard ContinuationPoint rules (see 6.3) apply. In addition, the following ContinuationPoint rule applies to ReadRawModifiedDetails If a startTime, endTime and numValuesPerNode are all provided and if more than numValuesPerNode values exist within that time range for a given Node then only numValuesPerNode values per Node shall be returned along with a ContinuationPoint.

It is specifically allowed for the startTime and the endTime to be identical. This allows the Client to request just one value. When the startTime and endTime are identical then time is presumed to be flowing forward. It is specifically not allowed for the Server to return a Bad_InvalidArgument StatusCode if the requested time domain is outside of the Server's range. Such a case shall be treated as an interval in which no data exists.

If Bounding Values are requested and a non-zero numValuesPerNode was specified then any Bounding Values returned are included in the numValuesPerNode count. If numValuesPerNode is 1 then only the start bound is returned (the end bound if the reverse order is needed). If numValuesPerNode is 2 then the start bound and the first data point are returned (the end bound if reverse order is needed). When Bounding Values are requested and no bounding value is found then the corresponding StatusCode entry will be set to Bad_BoundNotFound, a timestamp equal to the start or end time as appropriate, and a value of null. How far back or forward to look in history for Bounding Values is Server dependent.

For an interval in which no data exists, if Bounding Values are not requested, then the corresponding StatusCode shall be Good_NoData. If Bounding Values are requested and one or both exist, then the result code returned is Success and the bounding value(s) are returned.

For cases where there are multiple values for a given timestamp, all but the most recent are considered to be ModifiedValues and the Server shall return the most recent value. If the Server returns a value which hides other values at a timestamp then it shall set the ExtraData bit in the StatusCode associated with that value. The additional values can be retrieved with the isReadModified flag set to true, see 6.5.3.3. If the Server contains additional information regarding a value, such as Annotations, then the ExtraData bit shall also be set.

If the requested TimestampsToReturn is not supported for a Node, the operation shall return the Bad_TimestampNotSupported StatusCode.

When this structure is used for reading Modified Values (isReadModified is set to TRUE), it reads the ModifiedValues, StatusCodes, timestamps, modification type, the user identifier, and the timestamp of the modification from the history database for the specified time domain for one or more HistoricalDataNodes. If there are multiple replaced values the Server shall return all of them. The updateType specifies what value is returned in the modification record. If the updateType is INSERT the value is the new value that was inserted. If the updateType is anything else the value is the old value that was changed. See 6.9 HistoryUpdateDetails parameter for details on what updateTypes are available.

The purpose of this function is to read values from history that have been Modified. The returnBounds parameter shall be set to FALSE for this case, otherwise the Server returns a Bad_InvalidArgument StatusCode.

The domain of the request is defined by startTime, endTime, and numValuesPerNode; at least two of these shall be specified. If endTime is less than startTime, or endTime and numValuesPerNode alone are specified, then the data shall be returned in reverse order with the later data coming first. If all three are specified then the call shall return up to numValuesPerNode results going from StartTime to EndTime, in either ascending or descending order depending on the relative values of StartTime and EndTime. If numValuesPerNode is 0 then all of the values in the range are returned. If the Server cannot return all ModifiedValues for a given timestamp in a single response then it shall return ModifiedValues with the same timestamp in subsequent calls.

The standard ContinuationPoint rules (see 6.3) apply. In addition, the following ContinuationPoint rule applies to ReadRawModifiedDetails. If more than numValuesPerNode values exist within that time range for a given Node then only numValuesPerNode values per Node are returned along with a ContinuationPoint.

If a value has been modified multiple times then all values for the time are returned. This means that a timestamp can appear in the array more than once. The order of the returned values with the same timestamp should be from the most recent to oldest modification timestamp, if startTime is less than or equal to endTime. If endTime is less than startTime, then the order of the returned values will be from the oldest modification timestamp to the most recent. It is Server dependent whether multiple modifications are kept or only the most recent.

If the requested TimestampsToReturn is not supported for a Node then the operation shall return the Bad_TimestampNotSupported StatusCode.

Table 35 defines the structure of the ReadProcessedDetails structure.

Table 35 – ReadProcessedDetails structure

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. See OPC 10000-13 for details.
AggregateConfiguration	Aggregate Configuration	Aggregate configuration structure.
useServerCapabilitiesDefaults	Boolean	As described in OPC 10000-4 AggregateFilter Structure. (also see AggregateConfiguration settings defined in OPC 10000-13, and as described in HistorianConfiguration Objects (see 5.2.2).
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.

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

Its representation in the AddressSpace is defined in Table 30.

Table 36 – ReadProcessedDetails definition

Attribute		Value
BrowseName		ReadProcessedDetails
IsAbstract		False
References	NodeClass		BrowseName	DataType	TypeDefinition	Other
Subtype of the HistoryReadDetails defined in Table 28
Conformance Units
Historical Access Aggregates

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 ProcessingInterva l 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. See OPC 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.

The standard ContinuationPoint rules (see 6.3) apply.

Refer to OPC 10000-13 for handling of Aggregate specific cases. Not all Aggregates can be applied to arrays, for example calculated value Aggregates can not be performed on arrays (e.g. Minimum, Maximum, Average…). Any Aggregate that can not be applied to an array, shall report Bad_NotSupported for the operation result associated with the given NodeId.

Table 37 defines the ReadAtTimeDetails structure.

Table 37 – ReadAtTimeDetails structure

Name	Type	Description
ReadAtTimeDetails	Structure	Specifies the details used to perform an “at time” history read.
reqTimes []	UtcTime	The entries define the specific timestamps for which values are to be read.
useSimpleBounds	Boolean	Use SimpleBounds to determine the value at the specific timestamp.

Its representation in the AddressSpace is defined in Table 30.

Table 38 – ReadAtTimeDetails definition

Attribute		Value
BrowseName		ReadAtTimeDetails
IsAbstract		False
References	NodeClass		BrowseName	DataType	TypeDefinition	Other
Subtype of the HistoryReadDetails defined in Table 28
Conformance Units
Historical Access Time Instance

The ReadAtTimeDetails structure reads the values and qualities from the history database for the specified timestamps for one or more HistoricalDataNodes. This function is intended to provide values to correlate with other values with a known timestamp. For example, a Client may need to read the values of sensors when lab samples were collected.

The order of the values and qualities returned shall match the order of the timestamps supplied in the request.

When no value exists for a specified timestamp, a value shall be Interpolated from the surrounding values to represent the value at the specified timestamp. The interpolation will follow the same rules as the standard Interpolated Aggregate as outlined in OPC 10000-13.

If the useSimpleBounds flag is True and Interpolation is required then simple bounding values will be used to calculate the data value. If useSimpleBounds is False and Interpolation is required then interpolated bounding values will be used to calculate the data value. See OPC 10000-13 for the definition of simple bounding values and interpolated bounding values.

If a value is found for the specified timestamp, then the Server will set the StatusCode InfoBits to be Raw. If the value is Interpolated from the surrounding values, then the Server will set the StatusCode InfoBits to be Interpolated.

The standard ContinuationPoint rules (see 6.3) apply

If the requested TimestampsToReturn is not supported for a Node, then the operation shall return the Bad_TimestampNotSupported StatusCode.

Table 39 defines the ReadAnnotationDataDetails structure. This request is passed using the NodeId of a node that has an Annotations Property.

Table 39 – ReadAnnotationDataDetails Structure

Name	Type	Description
ReadAnnotationDataDetails	Structure	Specifies the details used to perform an “at time” history read.
reqTimes []	UtcTime	The entries define the specific timestamps for which values are to be read.

Its representation in the AddressSpace is defined in Table 40

Table 40 – ReadAnnotationDataDetails definition

Attribute		Value
BrowseName		ReadAnnotationDataDetails
IsAbstract		False
References	NodeClass		BrowseName	DataType	TypeDefinition	Other
Subtype of the HistoryReadDetails defined in Table 28
Conformance Units
Historical Access Annotations

The ReadAnnotationDataDetails structure reads the Annotation Data from the history database for the specified timestamps for one or more HistoricalDataNodes. It will return any annotation that is associated with the given HistoricalDataNodes. The ExtraData bit may indicate that an annotation is present at the given time (it may also indicate that data has been modified at the given time). Annotations may also be returned by ReadRawModifiedDetails using the Annotations Property as the NodeId.

The order of the Annotations Data returned shall match the order of the timestamps supplied in the request.

If Annotation Data is not supported for a HistoricalDataNodes then the StatusCode shall be Bad_HistoryOperationUnsupported.

The standard ContinuationPoint rules (see 6.3) apply