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 |
||||||
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 |
||||||
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 ReadEventDetailsSorted structure. The structure is a subtype of the ReadEventDetails Structure defined in 6.5.2, adding a SortClause used to define the order in which events will be returned by the Server. The Server shall use the SortClause to determine how the filtered rows shall be sorted before the results are returned.
Table 33 – ReadEventDetailsSorted Structure
|
Name |
Type |
Description |
|
ReadEventDetailsSorted |
Structure |
Specifies the details used to perform an Event history read. |
|
SortClause |
SortRuleElement[] |
Sorting rules for the filtered notification that match the EventFilter. The priority of the ordering is evaluated by using the position of the elements in this array, starting with the first element. |
Its representation in the AddressSpace is defined in Table 34.
Table 34 – ReadEventDetailsSorted definition
|
Attribute |
Value |
|||||
|
BrowseName |
ReadEventDetailsSorted |
|||||
|
IsAbstract |
False |
|||||
|
References |
NodeClass |
BrowseName |
DataType |
TypeDefinition |
Other |
|
|
Subtype of the ReadEventDetails defined in 6.5.2 |
||||||
|
Conformance Units |
||||||