IEC 62541-11:2020

IEC 62541-11 ®
Edition 2.0 2020-06
REDLINE VERSION
INTERNATIONAL
STANDARD
colour
inside
OPC unified architecture –
Part 11: Historical Access
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - webstore.iec.ch/advsearchform Electropedia - www.electropedia.org
The advanced search enables to find IEC publications by a The world's leading online dictionary on electrotechnology,
variety of criteria (reference number, text, technical containing more than 22 000 terminological entries in English
committee,…). It also gives information on projects, replaced and French, with equivalent terms in 16 additional languages.
and withdrawn publications. Also known as the International Electrotechnical Vocabulary

(IEV) online.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Glossary - std.iec.ch/glossary
details all new publications released. Available online and 67 000 electrotechnical terminology entries in English and
once a month by email. French extracted from the Terms and Definitions clause of
IEC publications issued since 2002. Some entries have been
IEC Customer Service Centre - webstore.iec.ch/csc collected from earlier publications of IEC TC 37, 77, 86 and
If you wish to give us your feedback on this publication or CISPR.

need further assistance, please contact the Customer Service

Centre: sales@iec.ch.
IEC 62541-11 ®
Edition 2.0 2020-06
REDLINE VERSION
INTERNATIONAL
STANDARD
colour
inside
OPC unified architecture –
Part 11: Historical Access
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 25.040.40; 35.100.05 ISBN 978-2-8322-8574-9

– 2 – IEC 62541-11:2020 RLV © 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 . 16
5.2.4 Historical Data Configuration Object . 16
5.2.5 HistoricalDataNodes Address Space Model . 17
5.2.6 Attributes . 18
5.3 HistoricalEventNodes . 18
5.3.1 General . 18
5.3.2 HistoricalEventFilter Property . 18
5.3.3 HistoricalEventNodes Address Space Model . 19
5.3.4 HistoricalEventNodes Attributes . 19
5.4 Exposing supported functions and capabilities . 20
5.4.1 General . 20
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

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 . 16
Table 5 – HasHistoricalConfiguration ReferenceType . 16
Table 6 – Historical Access configuration definition. 17
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 RLV © 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

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.
This redline version of the official IEC Standard allows the user to identify the changes
made to the previous edition. A vertical bar appears in the margin wherever a change
has been made. Additions are in green text, deletions are in strikethrough red text.

– 6 – IEC 62541-11:2020 RLV © IEC 2020
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.
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.
OPC UNIFIED ARCHITECTURE –
Part 11: Historical Access
1 Scope
This part of IEC 62541 is part of the overall 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 RLV © 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. There does
not have to be a value stored at that 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
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 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 may can be all data collected for the DataValue or it may 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 RLV © 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, etc.).
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.
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 RLV © 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
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 may can change;
NodeIds may can be modified, added or deleted).
Server developers and administrators need to be aware that modifying the AddressSpace may
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 the AddressSpace, with the appropriate AccessLevel Attribute and Historizing
Attribute settings (see IEC 62541-3 for details on access levels).
5 Historical Information Model
5.1 HistoricalNodes
5.1.1 General
The Historical Access model defines additional Properties that are applicable for both
HistoricalDataNodes and HistoricalEventNodes.
5.1.2 Annotations Property
The DataVariable or Object that has Annotation data will add the Annotations Property as
shown in Table 2.
Table 2 – Annotations Property
Name Use Data Type Description
Standard Properties
The Annotations Property is used to indicate that Annotation data
Annotations O Annotation
exists for the history collection exposed by a HistoricalDataNode
supports Annotation data. Annotation DataType is defined in 5.5.

Since it is not allowed for Properties to have Properties, the Annotations Property is only
available for DataVariables or Objects.
Not every HistoricalDataNode in the AddressSpace might contain Annotation data. The
Annotations Property indicates whether or not a HistoricalDataNode supports Annotations.

– 14 – IEC 62541-11:2020 RLV © IEC 2020
Annotation data is accessed using the standard HistoryRead functions. Annotations are
modified, inserted or deleted using the standard HistoryUpdate functions.
The Annotations Property shall be present on every HistoricalDataNode that supports
modifications, deletions, or additions of Annotations weather or not Annotations currently
exist. Annotation data is accessed using the standard HistoryRead functions. Annotations are
modified, inserted or deleted using the standard HistoryUpdate functions and the
UpdateStructuredDataDetails structure. The presence of the Annotations Property does not
indicate the presence of Annotations on the HistoricalDataNode.
A Server shall add the Annotations Property to a HistoricalDataNode only if it will also support
Annotations on that HistoricalDataNode. See IEC 62541-4 for adding Properties to Nodes. A
Server shall remove all Annotation data if it removes the Annotations Property from an
existing HistoricalDataNode.
As with all HistoricalNodes, modifications, deletions or additions of Annotations will raise the
appropriate Historical Audit Event with the corresponding NodeId.
5.2 HistoricalDataNodes
5.2.1 General
The Historical Data model defines additional ObjectTypes and Objects. These descriptions
also include required use cases for HistoricalDataNodes.
5.2.2 HistoricalDataConfigurationType
The Historical Access Data model extends the standard type model by defining the
HistoricalDataConfigurationType. This Object defines the general characteristics of a Node
that defines the historical configuration of any HistoricalDataNode that is defined to contain
history. It is formally defined in Table 3.
All Instances of the HistoricalDataConfigurationType use the standard BrowseName as
defined in Table 6.
Table 3 – HistoricalDataConfigurationType definition
Attribute Value
BrowseName HistoricalDataConfigurationType
IsAbstract False
References NodeClass BrowseName DataType TypeDefinition ModellingRule
HasComponent Object AggregateConfiguration -- AggregateConfigurationType Mandatory
HasComponent Object AggregateFunctions -- FolderType Optional
HasProperty Variable Stepped Boolean PropertyType Mandatory
HasProperty Variable Definition String PropertyType Opt
...