Errata exists for this version of the document.
For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-3, OPC 10000-4, andOPC 10000-13 as well as the following apply.
metadata associated with an item at a given instance in time
Note 1 to entry: An Annotation is metadata that is associated with an item at a given instance in time.
values associated with the starting and ending time
Note 1 to entry: BoundingValues are the values that are associated with the starting and ending time of a ProcessingInterval specified when reading from the historian. BoundingValues may be required by Clients to determine the starting and ending values when requesting raw data over a time range. If a raw data value exists at the start or end point, it is considered the bounding value even though it is part of the data request. If no raw data value exists at the start or end point, then the Server will determine the boundary value, which may require data from a data point outside of the requested range. See 4.4 for details on using BoundingValues.
Object, Variable, Property or View in the AddressSpace where a Client can access historical data or Events
Note 1 to entry: A HistoricalNode is a term used in this document to represent any Object, Variable, Property or View in the AddressSpace for which a Client may read and/or update historical data or Events. The terms “HistoricalNode’s history” or “history of a HistoricalNode” will refer to the time series data or Events stored for this HistoricalNode. The term HistoricalNode refers to both HistoricalDataNodes and HistoricalEventNodes .
Variable or Property in the AddressSpace where a Client can access historical data
Note 1 to entry: A HistoricalDataNode represents any Variable or Property in the AddressSpace for which a Client may read and/or update historical data. “HistoricalDataNode’s history” or “history of a HistoricalDataNode” refers to the time series data stored for this HistoricalNode. Examples of such data are:
- device data (like temperature sensors)
- calculated data
- status information (open/closed, moving)
- dynamically changing system data (like stock quotes)
- diagnostic data
The term HistoricalDataNodes is used when referencing aspects of the standard that apply to accessing historical data only.
Object or View in the AddressSpace for which a Client can access historical Events
Note 1 to entry: “HistoricalEventNode’s history” or “history of a HistoricalEventNode” refers to the time series Events stored in some historical system. Examples of such data are:
- Notifications
- system Alarms
- operator action Events
- system triggers (such as new orders to be processed)
The term HistoricalEventNode is used when referencing aspects of the standard that apply to accessing historical Events only.
HistoricalDataNode’s value that has been changed (or manually inserted or deleted) after it was stored in the historian
Note 1 to entry: For some Servers, a lab data entry value is not a modified value, but if a user corrects a lab value, the original value would be considered a modified value, and would be returned during a request for modified values. Also manually inserting a value that was missed by a standard collection system may be considered a modified value. Unless specified otherwise, all historical Services operate on the current, or most recent, value for the specified HistoricalDataNode at the specified timestamp. Requests for modified values are used to access values that have been superseded, deleted or inserted. It is up to a system to determine what is considered a modified value. Whenever a Server has modified data available for an entry in the historical collection it shall set the ExtraData bit in the StatusCode.
data that is stored within the historian for a HistoricalDataNode
Note 1 to entry: The data may be all data collected for the DataValue or it may be some subset of the data depending on the historian and the storage rules invoked when the item’s values were saved.
bounds of a history request which define the time domain
Note 1 to entry: For all requests, a value falling at the end time of the time domain is not included in the domain, so that requests made for successive, contiguous time domains will include every value in the historical collection exactly once.
interval of time covered by a particular request, or response
Note 1 to entry: In general, if the start time is earlier than or the same as the end time, the time domain is considered to begin at the start time and end just before the end time; if the end time is earlier than the start time, the time domain still begins at the start time and ends just before the end time, with time "running backward" for the particular request and response. In both cases, any value which falls exactly at the end time of the TimeDomain is not included in the TimeDomain. See the examples in 4.4. BoundingValues effect the time domain as described in 4.4.
All timestamps which can legally be represented in a UtcTime DataType are valid timestamps, and the Server may not return an invalid argument result code due to the timestamp being outside of the range for which the Server has data. See OPC 10000-3 for a description of the range and granularity of this DataType. Servers are expected to handle out-of-bounds timestamps gracefully, and return the proper StatusCodes to the Client.
structured data stored in a history collection where parts of the structure are used to uniquely identify the data within the data collection
Note 1 to entry: Most historical data applications assume only one current value per timestamp. Therefore the timestamp of the data is considered the unique identifier for that value. Some data or meta data such as Annotations may permit multiple values to exist at a single timestamp. In such cases the Server would use one or more parameters of the Structured History Data entry to uniquely identifiy each element within the history collection. Annotations are examples of Structured History Data.
DAData Access
HAHistorical Access
HDAHistorical Data Access
UA Unified Architecture