EN IEC 62541-11:2020

SLOVENSKI STANDARD
01-december-2020
Nadomešča:
SIST EN 62541-11:2015
Enotna arhitektura OPC - 11. del: Zgodovinski dostop (IEC 62541-11:2020)
OPC Unified Architecture - Part 11: Historical Access (IEC 62541-11:2020)
OPC Unified Architecture - Teil 11: Zugang zu historischen Daten (IEC 62541-11:2020)
Architecture unifiée OPC - Partie 11: Accès à l'Historique (IEC 62541-11:2020)
Ta slovenski standard je istoveten z: EN IEC 62541-11:2020
ICS:
25.040.40 Merjenje in krmiljenje Industrial process
industrijskih postopkov measurement and control
35.240.50 Uporabniške rešitve IT v IT applications in industry
industriji
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN IEC 62541-11

NORME EUROPÉENNE
EUROPÄISCHE NORM
August 2020
ICS 35.100.05; 25.040.40 Supersedes EN 62541-11:2015 and all of its
amendments and corrigenda (if any)
English Version
OPC Unified Architecture - Part 11: Historical Access
(IEC 62541-11:2020)
Architecture unifiée OPC - Partie 11: Accès à l'Historique OPC Unified Architecture - Teil 11: Zugang zu historischen
(IEC 62541-11:2020) Daten
(IEC 62541-11:2020)
This European Standard was approved by CENELEC on 2020-07-28. CENELEC members are bound to comply with the CEN/CENELEC
Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2020 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN IEC 62541-11:2020 E

European foreword
The text of document 65E/710/FDIS, future edition 3 of IEC 62541-11, prepared by SC 65E "Devices
and integration in enterprise systems" of IEC/TC 65 "Industrial-process measurement, control and
automation" was submitted to the IEC-CENELEC parallel vote and approved by CENELEC as
The following dates are fixed:
• latest date by which the document has to be implemented at national (dop) 2021-04-28
level by publication of an identical national standard or by endorsement
• latest date by which the national standards conflicting with the (dow) 2023-07-28
document have to be withdrawn
This document supersedes EN 62541-11:2015 and all of its amendments and corrigenda (if any).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a mandate given to CENELEC by the European Commission
and the European Free Trade Association.
Endorsement notice
The text of the International Standard IEC 62541-11:2020 was approved by CENELEC as a European
Standard without any modification.
In the official version, for Bibliography, the following notes have to be added for the standards
indicated:
IEC 62541-6 NOTE Harmonized as EN 62541-6
IEC 62541-7 NOTE Harmonized as EN 62541-7

Annex A
(normative)
Normative references to international publications
with their corresponding European publications
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments)
applies.
NOTE 1  Where an International Publication has been modified by common modifications, indicated by (mod),
the relevant EN/HD applies.
NOTE 2  Up-to-date information on the latest versions of the European Standards listed in this annex is available
here: www.cenelec.eu.
Publication Year Title EN/HD Year
IEC/TR 62541-1 - OPC unified architecture - Part 1: CLC/TR 62541-1 -
Overview and concepts
IEC 62541-3 - OPC Unified Architecture - Part 3: - -
Address Space Model
IEC 62541-4 - OPC Unified Architecture - Part 4: - -
Services
IEC 62541-5 - OPC Unified Architecture - Part 5: - -
Information Model
IEC 62541-8 - OPC Unified Architecture - Part 8: Data EN IEC 62541-8 -
Access
IEC 62541-13 - OPC Unified Architecture - Part 13: EN IEC 62541-13 -
Aggregates
IEC 62541-11 ®
Edition 2.0 2020-06
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
OPC unified architecture –
Part 11: Historical Access
Architecture unifiée OPC –
Partie 11: Accès à l'Historique

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
INTERNATIONALE
ICS 25.040.40; 35.100.05 ISBN 978-2-8322-8454-4

– 2 – IEC 62541-11:2020 © IEC 2020
CONTENTS
FOREWORD . 5
1 Scope . 7
2 Normative references . 7
3 Terms, definitions, and abbreviated terms . 7
3.1 Terms and definitions . 7
3.2 Abbreviated terms . 9
4 Concepts . 9
4.1 General . 9
4.2 Data architecture . 10
4.3 Timestamps . 10
4.4 Bounding Values and time domain . 11
4.5 Changes in AddressSpace over time . 13
5 Historical Information Model . 13
5.1 HistoricalNodes. 13
5.1.1 General . 13
5.1.2 Annotations Property . 13
5.2 HistoricalDataNodes . 14
5.2.1 General . 14
5.2.2 HistoricalDataConfigurationType. 14
5.2.3 HasHistoricalConfiguration ReferenceType . 15
5.2.4 Historical Data Configuration Object . 16
5.2.5 HistoricalDataNodes Address Space Model . 17
5.2.6 Attributes . 17
5.3 HistoricalEventNodes . 18
5.3.1 General . 18
5.3.2 HistoricalEventFilter Property . 18
5.3.3 HistoricalEventNodes Address Space Model . 18
5.3.4 HistoricalEventNodes Attributes . 19
5.4 Exposing supported functions and capabilities . 19
5.4.1 General . 19
5.4.2 HistoryServerCapabilitiesType . 20
5.5 Annotation DataType . 22
5.6 Historical Audit Events . 23
5.6.1 General . 23
5.6.2 AuditHistoryEventUpdateEventType . 23
5.6.3 AuditHistoryValueUpdateEventType . 24
5.6.4 AuditHistoryAnnotationUpdateEventType . 25
5.6.5 AuditHistoryDeleteEventType . 25
5.6.6 AuditHistoryRawModifyDeleteEventType . 26
5.6.7 AuditHistoryAtTimeDeleteEventType . 27
5.6.8 AuditHistoryEventDeleteEventType . 27
6 Historical Access specific usage of Services . 28
6.1 General . 28
6.2 Historical Nodes StatusCodes . 28
6.2.1 Overview . 28
6.2.2 Operation level result codes . 28

IEC 62541-11:2020 © IEC 2020 – 3 –
6.2.3 Semantics changed . 30
6.3 Continuation Points . 30
6.4 HistoryReadDetails parameters . 31
6.4.1 Overview . 31
6.4.2 ReadEventDetails structure . 31
6.4.3 ReadRawModifiedDetails structure . 33
6.4.4 ReadProcessedDetails structure . 35
6.4.5 ReadAtTimeDetails structure . 37
6.4.6 ReadAnnotationDataDetails structure . 38
6.5 HistoryData parameters returned . 39
6.5.1 Overview . 39
6.5.2 HistoryData type . 39
6.5.3 HistoryModifiedData type . 39
6.5.4 HistoryEvent type . 39
6.5.5 HistoryAnnotationData type . 40
6.6 HistoryUpdateType Enumeration . 40
6.7 PerformUpdateType Enumeration . 40
6.8 HistoryUpdateDetails parameter . 40
6.8.1 Overview . 40
6.8.2 UpdateDataDetails structure . 42
6.8.3 UpdateStructureDataDetails structure . 43
6.8.4 UpdateEventDetails structure . 44
6.8.5 DeleteRawModifiedDetails structure . 46
6.8.6 DeleteAtTimeDetails structure . 47
6.8.7 DeleteEventDetails structure . 48
Annex A (informative) Client conventions . 49
A.1 How clients may request timestamps . 49
A.2 Determining the first historical data point . 50
Bibliography . 52

Figure 1 – Possible OPC UA Server supporting Historical Access . 10
Figure 2 – ReferenceType hierarchy . 16
Figure 3 – Historical Variable with Historical Data Configuration and Annotations . 17
Figure 4 – Representation of an Event with History in the AddressSpace . 19
Figure 5 – Server and HistoryServer Capabilities . 20

Table 1 – Bounding Value examples . 12
Table 2 – Annotations Property . 13
Table 3 – HistoricalDataConfigurationType definition . 14
Table 4 – ExceptionDeviationFormat Values . 15
Table 5 – HasHistoricalConfiguration ReferenceType . 16
Table 6 – Historical Access configuration definition. 16
Table 7 – Historical Events Properties . 18
Table 8 – HistoryServerCapabilitiesType Definition . 21
Table 9 – Annotation Structure . 23
Table 10 – AuditHistoryEventUpdateEventType definition . 23

– 4 – IEC 62541-11:2020 © IEC 2020
Table 11 – AuditHistoryValueUpdateEventType definition . 24
Table 12 – AuditHistoryAnnotationUpdateEventType definition . 25
Table 13 – AuditHistoryDeleteEventType definition . 26
Table 14 – AuditHistoryRawModifyDeleteEventType definition . 26
Table 15 – AuditHistoryAtTimeDeleteEventType definition . 27
Table 16 – AuditHistoryEventDeleteEventType definition . 27
Table 17 – Bad operation level result codes . 29
Table 18 – Good operation level result codes . 29
Table 19 – HistoryReadDetails parameterTypeIds . 31
Table 20 – ReadEventDetails . 32
Table 21 – ReadRawModifiedDetails . 33
Table 22 – ReadProcessedDetails . 36
Table 23 – NodesToRead and aggregateType parameters . 37
Table 24 – ReadAtTimeDetails . 37
Table 25 – ReadAnnotaionDataDetails . 38
Table 26 – HistoryData Details . 39
Table 27 – HistoryModifiedData Details . 39
Table 28 – HistoryEvent Details . 39
Table 29 – HistoryUpdateType Enumeration . 40
Table 30 – PerformUpdateType Enumeration . 40
Table 31 – HistoryUpdateDetails parameter TypeIds . 41
Table 32 – UpdateDataDetails . 42
Table 33 – UpdateStructureDataDetails . 43
Table 34 – UpdateEventDetails . 45
Table 35 – DeleteRawModifiedDetails . 47
Table 36 – DeleteAtTimeDetails . 47
Table 37 – DeleteEventDetails . 48
Table A.1 – Time keyword definitions . 50
Table A.2 –Time offset definitions . 50

IEC 62541-11:2020 © IEC 2020 – 5 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
OPC UNIFIED ARCHITECTURE –
Part 11: Historical Access
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC
Publication(s)"). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
IEC 62541-11 has been prepared by subcommittee 65E: Devices and integration in enterprise
systems, of IEC technical committee 65: Industrial-process measurement, control and
automation.
This third edition cancels and replaces the second edition published in 2015. This edition
constitutes a technical revision.
This edition includes the following significant technical changes with respect to the previous
edition:
a) a new method for determining the first historical point has been added;
b) added clarifications on how to add, insert, modify, and delete annotations.

– 6 – IEC 62541-11:2020 © IEC 2020
The text of this standard is based on the following documents:
FDIS Report on voting
65E/710/FDIS 65E/728/RVD
Full information on the voting for the approval of this International Standard can be found in
the report on voting indicated in the above table.
This document has been drafted in accordance with the ISO/IEC Directives, Part 2.
Throughout this document and the other parts of the IEC 62541 series, certain document
conventions are used:
Italics are used to denote a defined term or definition that appears in the "Terms and
definition" clause in one of the parts of the IEC 62541 series.
Italics are also used to denote the name of a service input or output parameter or the name of
a structure or element of a structure that are usually defined in tables.
The italicized terms and names are, with a few exceptions, also written in camel-case (the
practice of writing compound words or phrases in which the elements are joined without
spaces, with each element's initial letter capitalized within the compound). For example the
defined term is AddressSpace instead of Address Space. This makes it easier to understand
that there is a single definition for AddressSpace, not separate definitions for Address and
Space.
A list of all parts of the IEC 62541 series, published under the general title OPC Unified
Architecture, can be found on the IEC website.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related to
the specific document. At this date, the document will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
IEC 62541-11:2020 © IEC 2020 – 7 –
OPC UNIFIED ARCHITECTURE –
Part 11: Historical Access
1 Scope
This part of IEC 62541 is part of the OPC Unified Architecture standard series and defines the
information model associated with Historical Access (HA). It particularly includes additional
and complementary descriptions of the NodeClasses and Attributes needed for Historical
Access, additional standard Properties, and other information and behaviour.
The complete AddressSpace Model including all NodeClasses and Attributes is specified in
IEC 62541-3. The predefined Information Model is defined in IEC 62541-5. The Services to
detect and access historical data and events, and description of the ExtensibleParameter
types are specified in IEC 62541-4.
This document includes functionality to compute and return Aggregates like minimum,
maximum, average etc. The Information Model and the concrete working of Aggregates are
defined in IEC 62541-13.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their
content constitutes requirements of this document. For dated references, only the edition
cited applies. For undated references, the latest edition of the referenced document (including
any amendments) applies.
IEC TR 62541-1, OPC Unified Architecture – Part 1: Overview and Concepts
IEC 62541-3, OPC Unified Architecture – Part 3: Address Space Model
IEC 62541-4, OPC Unified Architecture – Part 4: Services
IEC 62541-5, OPC Unified Architecture – Part 5: Information Model
IEC 62541-8, OPC Unified Architecture – Part 8: Data Access
IEC 62541-13, OPC Unified Architecture – Part 13: Aggregates
3 Terms, definitions, and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC TR 62541-1,
IEC 62541-3, IEC 62541-4, and IEC 62541-13 as well as the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp

– 8 – IEC 62541-11:2020 © IEC 2020
3.1.1
annotation
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.
3.1.2
BoundingValues
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.
3.1.3
HistoricalNode
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.
3.1.4
HistoricalDataNode
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.
3.1.5
HistoricalEventNode
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.
3.1.6
modified values
HistoricalDataNode’s value that has been changed (or manually inserted or deleted) after it
was stored in the historian
IEC 62541-11:2020 © IEC 2020 – 9 –
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 can 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.
3.1.7
raw data
data that is stored within the historian for a HistoricalDataNode
Note 1 to entry: The data can be all data collected for the DataValue or it can be some subset of the data
depending on the historian and the storage rules invoked when the item’s values were saved.
3.1.8
StartTime/EndTime
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.
3.1.9
TimeDomain
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 affect the time domain
as described in 4.4.
All timestamps that 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 IEC 62541-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.
3.1.10
Structured History Data
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 metadata 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.
3.2 Abbreviated terms
DA data access
HA historical access
HDA historical data access
UA Unified Architecture
4 Concepts
4.1 General
This document defines the handling of historical time series data and historical Event data in
the OPC Unified Architecture. Included is the specification of the representation of historical
data and Events in the AddressSpace.

– 10 – IEC 62541-11:2020 © IEC 2020
Annex A defines some useful, but not normative, conventions for OPC UA Clients.
4.2 Data architecture
A Server supporting Historical Access provides Clients with transparent access to different
historical data and/or historical Event sources (e.g. process historians, event historians).
The historical data or Events may be located in a proprietary data collection, database or a
short-term buffer within the memory. A Server supporting Historical Access will provide
historical data and Events for all or a subset of the available Variables, Objects, Properties or
Views within the Server AddressSpace.
Figure 1 illustrates how the AddressSpace of a UA Server might consist of a broad range of
different historical data and/or historical Event sources.

Figure 1 – Possible OPC UA Server supporting Historical Access
The Server may be implemented as a standalone OPC UA Server that collects data from
another OPC UA Server or another data source. The Client that references the OPC UA
Server supporting Historical Access for historical data may be simple trending packages that
just desire values over a given time frame, or they may be complex reports that require data
in multiple formats.
4.3 Timestamps
The nature of OPC UA Historical Access requires that a single timestamp reference be used
to relate the multiple data points, and the Client may request which timestamp will be used as
the reference. See IEC 62541-4 for details on the TimestampsToReturn enumeration. An OPC
UA Server supporting Historical Access will treat the various timestamp settings as described
below. A HistoryRead with invalid settings will be rejected with
Bad_TimestampsToReturnInvalid (see IEC 62541-4).
For HistoricalDataNodes, the SourceTimestamp is used to determine which historical data
values are to be returned.
IEC 62541-11:2020 © IEC 2020 – 11 –
The request is in terms of SourceTimestamp but the reply could be in SourceTimestamp,
ServerTimestamp or both timestamps. If the reply has the Server timestamp, the timestamps
could fall outside of the range of the requested time.
SOURCE_0 Return the SourceTimestamp.
SERVER_1 Return the ServerTimestamp.
BOTH_2 Return both the SourceTimestamp and ServerTimestamp.
NEITHER_3 This is not a valid setting for any HistoryRead accessing
.
HistoricalDataNodes
Any reference to timestamps in this context throughout this document will represent either
ServerTimestamp or SourceTimestamp as dictated by the type requested in the HistoryRead
Service. Some Servers may not support historizing both SourceTimestamp and
ServerTimestamp, but it is expected that all Servers will support historizing SourceTimestamp
(see IEC 62541-7 for details on Server Profiles).
If a request is made requesting both ServerTimestamp and SourceTimestamp and the Server
is only collecting the SourceTimestamp the Server shall return
Bad_TimestampsToReturnInvalid.
For HistoricalEventNodes, this parameter does not apply. This parameter is ignored since the
entries returned are dictated by the Event Filter. See IEC 62541-4 for details.
4.4 Bounding Values and time domain
When accessing HistoricalDataNodes via the HistoryRead Service, requests can set a flag,
returnBounds, indicating that BoundingValues are requested. For a complete description of
the Extensible Parameter HistoryReadDetails that include StartTime, EndTime and
NumValuesPerNode, see 6.4. The concept of Bounding Values and how they affect the time
domain that is requested as part of the HistoryRead request is further explained in 4.4, also
provides examples of TimeDomains to further illustrate the expected behaviour.
When making a request for historical data using the HistoryRead Service, the required
parameters include at least two of these three parameters: startTime, endTime and
numValuesPerNode. What is returned when Bounding Values are requested varies according
to which of these parameters are provided. For a historian that has values stored at 5:00,
5:02, 5:03, 5:05 and 5:06, the data returned when using the Read Raw functionality is given
by Table 1. In the table, FIRST stands for a tuple with a value of null, a timestamp of the
specified StartTime, and a StatusCode of Bad_BoundNotFound. LAST stands for a tuple with
a value of null, a timestamp of the specified EndTime, and a StatusCode of
Bad_BoundNotFound.
In some cases, attempting to locate bounds, particularly FIRST or LAST points, may be
resource intensive for Servers. Therefore, how far back or forward to look in history for
Bounding Values is Server dependent, and the Server search limits may be reached before a
bounding value can be found. There are also cases, such as reading Annotations or Attribute
data where Bounding Values may not be appropriate. For such use cases, it is permissible for
the Server to return a StatusCode of Bad_BoundNotSupported.

– 12 – IEC 62541-11:2020 © IEC 2020
Table 1 – Bounding Value examples
Start Time End Time numValuesPerNode Bounds Data Returned
5:00 5:05 0 Yes 5:00, 5:02, 5:03, 5:05
5:00 5:05 0 No 5:00, 5:02, 5:03
5:01 5:04 0 Yes 5:00, 5:02, 5:03, 5:05
5:01 5:04 0 No 5:02, 5:03
5:05 5:00 0 Yes 5:05, 5:03, 5:02, 5:00
5:05 5:00 0 No 5:05, 5:03, 5:02
5:04 5:01 0 Yes 5:05, 5:03, 5:02, 5:00
5:04 5:01 0 No 5:03, 5:02
4:59 5:05 0 Yes FIRST, 5:00, 5:02, 5:03, 5:05
4:59 5:05 0 No 5:00, 5:02, 5:03
5:01 5:07 0 Yes 5:00, 5:02, 5:03, 5:05, 5:06, LAST
5:01 5:07 0 No 5:02, 5:03, 5:05, 5:06
5:00 5:05 3 Yes 5:00, 5:02, 5:03
5:00 5:05 3 No 5:00, 5:02, 5:03
5:01 5:04 3 Yes 5:00, 5:02, 5:03
5:01 5:04 3 No 5:02, 5:03
5:05 5:00 3 Yes 5:05, 5:03, 5:02
5:05 5:00 3 No 5:05, 5:03, 5:02
5:04 5:01 3 Yes 5:05, 5:03, 5:02
5:04 5:01 3 No 5:03, 5:02
4:59 5:05 3 Yes FIRST, 5:00, 5:02
4:59 5:05 3 No 5:00, 5:02, 5:03
5:01 5:07 3 Yes 5:00, 5:02, 5:03
5:01 5:07 3 No 5:02, 5:03, 5:05
5:00 UNSPECIFIED 3 Yes 5:00, 5:02, 5:03
5:00 UNSPECIFIED 3 No 5:00, 5:02, 5:03
a
5:00 UNSPECIFIED 6 Yes 5:00, 5:02, 5:03, 5:05, 5:06, LAST
5:00 UNSPECIFIED 6 No 5:00, 5:02, 5:03, 5:05, 5:06
5:07 UNSPECIFIED 6 Yes 5:06, LAST
5:07 UNSPECIFIED 6 No NODATA
UNSPECIFIED 5:06 3 Yes 5:06,5:05,5:03
UNSPECIFIED 5:06 3 No 5:06,5:05,5:03
b
UNSPECIFIED 5:06 6 Yes 5:06,5:05,5:03,5:02,5:00,FIRST
UNSPECIFIED 5:06 6 No 5:06, 5:05, 5:03, 5:02, 5:00
UNSPECIFIED 4:48 6 Yes 5:00, FIRST
UNSPECIFIED 4:48 6 No NODATA
4:48 4:48 0 Yes FIRST,5:00
4:48 4:48 0 No NODATA
4:48 4:48 1 Yes FIRST
4:48 4:48 1 No NODATA
4:48 4:48 2 Yes FIRST,5:00
c
5:00 5:00 0 Yes 5:00,5:02
5:00 5:00 0 No 5:00
IEC 62541-11:2020 © IEC 2020 – 13 –
Start Time End Time numValuesPerNode Bounds Data Returned
5:00 5:00 1 Yes 5:00
5:00 5:00 1 No 5:00
5:01 5:01 0 Yes 5:00, 5:02
5:01 5:01 0 No NODATA
5:01 5:01 1 Yes 5:00
5:01 5:01 1 No NODATA
a
The timestamp of LAST cannot be the specified End Time because there is no specified End Time. In this
situation the timestamp for LAST will be equal to the previous timestamp returned plus one second.
b
The timestamp of FIRST cannot be the specified End Time because there is no specified Start Time. In this
situation the timestamp for FIRST will be equal to the previous timestamp returned minus one second.
c
When the Start Time = End Time (there is data at that time), and Bounds is set to True, the start bounds will
equal the Start Time and the next data point will be used for the end bounds.

4.5 Changes in AddressSpace over time
Clients use the browse Services of the View Service Set to navigate through the
AddressSpace to discover the HistoricalNodes and their characteristics. These Services
provide the most current information about the AddressSpace. It is possible and probable that
the AddressSpace of a Server will change over time (i.e. TypeDefinitions can change;
NodeIds can be modified, added or deleted).
Server developers and administrators need to be aware that modifying the AddressSpace can
impact a Client’s ability to access historical information. If the history for a HistoricalNode is
still required, but the HistoricalNode is no longer historized, then the Object should be
maintained in
...