PD CLC IEC/TR 62541‑1:2021

BSI Standards Publication

OPC unified architecture

Part 1: Overview and concepts

PD CLC IEC/TR 62541‑1:2021 PUBLISHED DOCUMENT

National foreword
This Published Document is the UK implementation of
CLC IEC/TR 62541‑1:2021. It is identical to IEC TR 62541‑1:2020. It
supersedes PD CLC/TR 62541‑1:2010 and PD IEC TR 62541‑1:2020, which
are withdrawn.
The UK participation in its preparation was entrusted to Technical
Committee GEL/65/3, Industrial communications: process measurement
and control, including fieldbus.
A list of organizations represented on this committee can be obtained on
request to its committee manager.
Contractual and legal considerations
This publication has been prepared in good faith, however no
representation, warranty, assurance or undertaking (express or
implied) is or will be made, and no responsibility or liability is or will be
accepted by BSI in relation to the adequacy, accuracy, completeness or
reasonableness of this publication. All and any such responsibility and
liability is expressly disclaimed to the full extent permitted by the law.
This publication is provided as is, and is to be used at the
recipient’s own risk.
The recipient is advised to consider seeking professional guidance with
respect to its use of this publication.
This publication is not intended to constitute a contract. Users are
responsible for its correct application.
This publication is not to be regarded as a British Standard.
© The British Standards Institution 2021
Published by BSI Standards Limited 2021
ISBN 978 0 539 18800 4
ICS 25.040.40; 35.100.01
Compliance with a Published Document cannot confer immunity
from legal obligations.
This Published Document was published under the authority of the
Standards Policy and Strategy Committee on 31 December 2020.

Amendments/corrigenda issued since publication

Date Text affected

31 August 2021 This corrigendum renumbers

PD IEC TR 62541‑1:2020 as
PD CLC IEC/TR 62541‑1:2021
 PD CLC IEC/TR 62541‑1:2021

TECHNICAL REPORT CLC IEC/TR 62541-1

RAPPORT TECHNIQUE
TECHNISCHER BERICHT July 2021

ICS 25.040.40; 35.100.01 Supersedes CLC/TR 62541-1:2010

English Version

OPC unified architecture - Part 1: Overview and concepts

(IEC/TR 62541-1:2020)

Architecture unifiée OPC - Partie 1: Vue d'ensemble et OPC Unified Architecture - Teil 1: Übersicht und Konzepte
concepts (IEC/TR 62541-1:2020)
(IEC/TR 62541-1:2020)

This Technical Report was approved by CENELEC on 2021-07-05.

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

© 2021 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.

Ref. No. CLC IEC/TR 62541-1:2021 E

PD CLC IEC/TR 62541‑1:2021
CLC IEC/TR 62541-1:2021 (E)

European foreword

This document (CLC IEC/TR 62541-1:2021) consists of the text of IEC/TR 62541-1:2020, prepared by
SC 65E "Devices and integration in enterprise systems" of IEC/TC 65 "Industrial-process
measurement, control and automation".

This document supersedes CLC/TR 62541-1:2010.

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.

Any feedback and questions on this document should be directed to the users’ national committee. A
complete listing of these bodies can be found on the CENELEC website.

Endorsement notice

The text of the International Technical Report IEC/TR 62541-1:2020 was approved by CENELEC as a
European Technical Report without any modification.

2
 PD CLC IEC/TR 62541‑1:2021
CLC IEC/TR 62541-1:2021 (E)

Annex ZA
(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-2 - OPC unified architecture – Part 2: CLC/TR 62541-2 -
Security Mode
IEC 62541-3 - OPC Unified Architecture - Part 3: EN IEC 62541-3 -
Address Space Model
IEC 62541-4 - OPC Unified Architecture - Part 4: EN IEC 62541-4 -
Services
IEC 62541-5 - OPC Unified Architecture - Part 5: EN IEC 62541-5 -
Information Model
IEC 62541-6 - OPC Unified Architecture - Part 6: EN IEC 62541-6 -
Mappings
IEC 62541-7 - OPC unified architecture - Part 7: Profiles EN IEC 62541-7 -
IEC 62541-8 - OPC Unified Architecture - Part 8: Data EN IEC 62541-8 -
Access
IEC 62541-9 - OPC Unified Architecture - Part 9: Alarms EN IEC 62541-9 -
and Conditions
IEC 62541-10 - OPC Unified Architecture - Part 10: EN IEC 62541-10 -
Programs
IEC 62541-11 - OPC Unified Architecture - Part 11: EN IEC 62541-11 -
Historical Access
IEC 62541-12 - OPC unified architecture - Part 12: EN IEC 62541-12 -
Discovery and global services
IEC 62541-13 - OPC Unified Architecture - Part 13: EN IEC 62541-13 -
Aggregates
IEC 62541-14 - OPC unified architecture - Part 14: EN IEC 62541-14 -
PubSub
ITU X.509 - Information technology – Open Systems
Interconnection – The Directory: Public-
key and attribute certificate
frameworkshttps://www.itu.int/rec/T-REC-
X.509

3
This page deliberately left blank
 PD CLC IEC/TR 62541‑1:2021

–2– IEC TR 62541-1:2020 © IEC 2020

CONTENTS

FOREWORD ........................................................................................................................... 4
1 Scope .............................................................................................................................. 6
2 Normative references ...................................................................................................... 6
3 Terms, definitions, and abbreviated terms ....................................................................... 7
3.1 Terms and definitions .............................................................................................. 7
3.2 Abbreviated terms ................................................................................................. 11
4 Structure of the OPC UA series ..................................................................................... 12
4.1 Specification organization ..................................................................................... 12
4.2 Core specification parts ........................................................................................ 12
4.3 Access Type specification parts ............................................................................ 13
4.4 Utility specification parts ....................................................................................... 13
5 Overview ....................................................................................................................... 14
5.1 UA scope .............................................................................................................. 14
5.2 General ................................................................................................................. 14
5.3 Design goals ......................................................................................................... 14
5.4 Integrated models and services............................................................................. 16
5.4.1 Security model ............................................................................................... 16
5.4.2 Integrated AddressSpace model .................................................................... 17
5.4.3 Integrated object model ................................................................................. 18
5.4.4 Integrated services ........................................................................................ 18
5.5 Sessions ............................................................................................................... 18
6 Systems concepts ......................................................................................................... 19
6.1 Client Server Overview ......................................................................................... 19
6.2 OPC UA Clients .................................................................................................... 19
6.3 OPC UA Servers ................................................................................................... 20
6.3.1 General ......................................................................................................... 20
6.3.2 Real objects .................................................................................................. 20
6.3.3 Server application .......................................................................................... 20
6.3.4 OPC UA AddressSpace ................................................................................. 21
6.3.5 Subscription entities ...................................................................................... 21
6.3.6 OPC UA Service Interface ............................................................................. 21
6.3.7 Server to Server interactions ......................................................................... 22
6.4 Redundancy .......................................................................................................... 23
6.5 Publish-Subscribe ................................................................................................. 23
6.6 Synergy of models ................................................................................................ 24
7 Service Sets .................................................................................................................. 25
7.1 General ................................................................................................................. 25
7.2 Discovery Service Set ........................................................................................... 25
7.3 SecureChannel Service Set .................................................................................. 25
7.4 Session Service Set .............................................................................................. 26
7.5 NodeManagement Service Set .............................................................................. 26
7.6 View Service Set ................................................................................................... 26
7.7 Query Service Set ................................................................................................. 26
7.8 Attribute Service Set ............................................................................................. 27
7.9 Method Service Set ............................................................................................... 27
7.10 MonitoredItem Service Set .................................................................................... 27
PD CLC IEC/TR 62541‑1:2021

IEC TR 62541-1:2020 © IEC 2020 –3–

7.11 Subscription Service Set ....................................................................................... 28

Figure 1 – OPC UA specification organization ....................................................................... 12

Figure 2 – OPC UA target applications .................................................................................. 15
Figure 3 – OPC UA System architecture ............................................................................... 19
Figure 4 – OPC UA Client architecture .................................................................................. 19
Figure 5 – OPC UA Server architecture ................................................................................ 20
Figure 6 – Peer-to-peer interactions between Servers ........................................................... 22
Figure 7 – Chained Server example ...................................................................................... 23
Figure 8 – Integrated Client Server and PubSub models ....................................................... 24
Figure 9 – SecureChannel and Session Services .................................................................. 26
 PD CLC IEC/TR 62541‑1:2021

–4– IEC TR 62541-1:2020 © IEC 2020

INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________

OPC UNIFIED ARCHITECTURE –

Part 1: Overview and concepts

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.

The main task of IEC technical committees is to prepare International Standards. However, a
technical committee may propose the publication of a technical report when it has collected
data of a different kind from that which is normally published as an International Standard, for
example "state of the art".

IEC TR 62541-1, which is a Technical Report, 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 of IEC TR 62541-1, published in
2016. This edition constitutes a technical revision.

This edition includes the following significant technical changes with respect to the previous
edition:

a) added Subclauses 6.5 and 6.6 and other text throughout to include PubSub introduction;
b) added new transports and encodings to existing overview sections;
c) removed WS-SecureConversation example since this mapping has been deprecated;
PD CLC IEC/TR 62541‑1:2021

IEC TR 62541-1:2020 © IEC 2020 –5–

d) improved the definition of Certificate.

The text of this Technical Report is based on the following documents:

Enquiry draft Report on voting

65E/678/DTR 65E/702/RVDTR

Full information on the voting for the approval of this technical report can be found in the report
on voting indicated in the above table.

This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

Throughout this document and the referenced other Parts of the 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 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 also often 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 publication will remain unchanged until the
stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data related to
the specific publication. At this date, the publication 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.
 PD CLC IEC/TR 62541‑1:2021

–6– IEC TR 62541-1:2020 © IEC 2020

OPC UNIFIED ARCHITECTURE –

Part 1: Overview and concepts

1 Scope

This part of IEC 62541 presents the concepts and overview of the OPC Unified Architecture
(OPC UA). Reading this document is helpful to understand the remaining parts of this multi-part
document set. Each of the other parts of IEC 62451 is briefly explained along with a suggested
reading order.

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-2, OPC unified architecture – Part 2: Security Model

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-6, OPC unified architecture – Part 6: Mappings

IEC 62541-7, OPC unified architecture – Part 7: Profiles

IEC 62541-8, OPC unified architecture – Part 8: Data access

IEC 62541-9, OPC unified architecture – Part 9: Alarms and Conditions

IEC 62541-10, OPC unified architecture – Part 10: Programs

IEC 62541-11, OPC unified architecture – Part 11: Historical Access

IEC 62541-12, OPC unified architecture – Part 12: Discovery and global services

IEC 62541-13, OPC Unified Architecture – Part 13: Aggregates

IEC 62541-14, OPC unified architecture – Part 14: PubSub

ITU X.509, Information technology – Open Systems Interconnection – The Directory: Public-key
and attribute certificate frameworks
https://www.itu.int/rec/T-REC-X.509
PD CLC IEC/TR 62541‑1:2021

IEC TR 62541-1:2020 © IEC 2020 –7–

3 Terms, definitions, and abbreviated terms

3.1 Terms and definitions

For the purposes of this document, the following terms 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

3.1.1
AddressSpace
collection of information that a Server makes visible to its Clients

Note 1 to entry: See IEC 62541-3 for a description of the contents and structure of the Server AddressSpace.

3.1.2
Aggregate
function that calculates derived values from Raw data

Note 1 to entry: Raw data may be from a historian or buffered real time data. Common Aggregates include averages
over a given time range, minimum over a time range and maximum over a time range.

3.1.3
Alarm
type of Event associated with a state condition that typically requires acknowledgement

Note 1 to entry: See IEC 62541-9 for a description of Alarms.

3.1.4
Attribute
primitive characteristic of a Node

Note 1 to entry: All Attributes are defined by OPC UA, and may not be defined by Clients or Servers. Attributes are
the only elements in the AddressSpace permitted to have data values.

3.1.5
Broker
intermediary program module that routes NetworkMessages from Publishers to Subscribers

Note 1 to entry: Brokers are building blocks of Message Oriented Middleware.

3.1.6
Certificate
digitally signed data structure that contains a public key and the identity of a Client or Server

3.1.7
Client
software application that sends Messages to OPC UA Servers conforming to the Services
specified in this set of specifications

3.1.8
Condition
generic term that is an extension to an Event

Note 1 to entry: A Condition represents the conditions of a system or one of its components and always exists in
some state.
 PD CLC IEC/TR 62541‑1:2021

–8– IEC TR 62541-1:2020 © IEC 2020

3.1.9
Communication Stack
layered set of software modules between the application and the hardware that provides various
functions to encode, encrypt and format a Message for sending, and to decode, decrypt and
unpack a Message that was received

3.1.10
DataSet
list of named data values

Note 1 to entry: A DataSet typically consists of Event fields or Variable values.

3.1.11
DataSetMessage
payload of a NetworkMessage created from a DataSet

Note 1 to entry: The DataSetMessage is an immutable payload of the NetworkMessage handed off to the Message
Oriented Middleware (transport layer) for delivery by the Publisher. The Subscriber receives the DataSetMessage as
the payload of a NetworkMessage from the Publisher with additional headers that may be supplied by the Message
Oriented Middleware along the way.

3.1.12
Discovery
process by which Client obtains information about Servers, including endpoint and security
information

3.1.13
Event
generic term used to describe an occurrence of some significance within a system or system
component

3.1.14
EventNotifier
special Attribute of a Node that signifies that a Client may subscribe to that particular Node to
receive Notifications of Event occurrences

3.1.15
Information Model
organizational framework that defines, characterizes and relates information resources of a
given system or set of systems

Note 1 to entry: The core AddressSpace model supports the representation of Information Models in the
AddressSpace. See IEC 62541-5 for a description of the base OPC UA Information Model.

3.1.16
Message
data unit conveyed between Client and Server that represents a specific Service request or
response

3.1.17
Message Oriented Middleware
infrastructure supporting sending and receiving NetworkMessages between distributed systems

Note 1 to entry: An OPC UA Application may support different types of Message Oriented Middleware
infrastructures and protocols like AMQP, MQTT, or UDP with IP multicast. Other types like DDS or XMPP can also
be integrated into the OPC UA PubSub model.

3.1.18
Method
callable software function that is a component of an Object
PD CLC IEC/TR 62541‑1:2021

IEC TR 62541-1:2020 © IEC 2020 –9–

3.1.19
MonitoredItem
Client-defined entity in the Server used to monitor Attributes or EventNotifiers for new values
or Event occurrences and that generates Notifications for them

3.1.20
NetworkMessage
DataSetMessages and header to facilitate delivery, routing, security and filtering

Note 1 to entry: The Publisher hands off the NetworkMessage to the Message Oriented Middleware (transport layer)
to deliver DataSetMessages to the Subscribers.

Note 2 to entry: The term message is used with various connotations in the messaging world. The Publisher might
like to think of the message as an immutable payload handed off to the Message Oriented Middleware for delivery.
The Subscriber often thinks of the message as not only that immutable payload from the sender, but also various
annotations supplied by the Message Oriented Middleware along the way. To avoid confusion, the term
DataSetMessage is used to mean the message as supplied by the Publisher for a DataSet and the term
NetworkMessage is used to mean the DataSetMessage plus sections for annotation at the head and tail of the
DataSetMessage.

3.1.21
Node
fundamental component of an AddressSpace

3.1.22
NodeClass
class of a Node in an AddressSpace

Note 1 to entry: NodeClasses define the metadata for the components of the OPC UA object model. They also
define constructs, such as Views, that are used to organize the AddressSpace.

3.1.23
Notification
generic term for data that announces the detection of an Event or of a changed Attribute value;
Notifications are sent in NotificationMessages.

3.1.24
NotificationMessage
Message published from a Subscription that contains one or more Notifications

3.1.25
Object
Object Instance
Node that represents a physical or abstract element of a system

Note 1 to entry: Objects are modelled using the OPC UA Object Model. Systems, subsystems and devices are
examples of Objects. An Object may be defined as an instance of an ObjectType.

3.1.26
ObjectType
Node that represents the type definition for an Object

3.1.27
OPC UA Application
Client, which calls OPC UA Services, or a Server, which performs those Services, or an OPC
UA Publisher or an OPC UA Subscriber

3.1.28
Publisher
entity sending NetworkMessages to a Message Oriented Middleware
 PD CLC IEC/TR 62541‑1:2021

– 10 – IEC TR 62541-1:2020 © IEC 2020

Note 1 to entry: A Publisher can be a native OPC UA Application or an application that only has knowledge about
the Message Oriented Middleware and the rules for encoding the NetworkMessages and DataSetMessages.

3.1.29
PubSub
OPC UA variant of the publish subscribe messaging pattern

3.1.30
Profile
specific set of capabilities to which a Server may claim conformance

Note 1 to entry: Each Server may claim conformance to more than one Profile.

Note 2 to entry: The set of capabilities are defined in IEC 62541-7.

3.1.31
Program
executable Object that, when invoked, immediately returns a response to indicate that execution
has started, and then returns intermediate and final results through Subscriptions identified by
the Client during invocation

3.1.32
Reference
explicit relationship (a named pointer) from one Node to another

Note 1 to entry: The Node that contains the Reference is the source Node, and the referenced Node is the target
Node. All References are defined by ReferenceTypes.

3.1.33
ReferenceType
Node that represents the type definition of a Reference

Note 1 to entry: The ReferenceType specifies the semantics of a Reference. The name of a ReferenceType
identifies how source Nodes are related to target Nodes and generally reflects an operation between the two, such
as “A contains B”.

3.1.34
Server
software application that implements and exposes the Services specified in this set of
specifications

3.1.35
Service
Client-callable operation in a Server

Note 1 to entry: Services are defined in IEC 62541-4. A Service is similar to a method call in a programming
language or an operation in a Web services WSDL contract.

3.1.36
Service Set
group of related Services

3.1.37
Session
logical long-running connection between a Client and a Server

Note 1 to entry: A Session maintains state information between Service calls from the Client to the Server.

3.1.38
Subscriber
entity receiving DataSetMessages from a Message Oriented Middleware
PD CLC IEC/TR 62541‑1:2021

IEC TR 62541-1:2020 © IEC 2020 – 11 –

Note 1 to entry: A Subscriber can be a native OPC UA Application or an application that has just knowledge about
the Message Oriented Middleware and the rules for decoding the NetworkMessages and DataSetMessages. A
Subscription in the OPC UA Client Server model has a different meaning than the Subscriber in the PubSub model.

3.1.39
Subscription
Client-defined endpoint in the Server, used to return Notifications to the Client

Note 1 to entry: "Subscription" is a generic term that describes a set of Nodes selected by the Client (1) that the
Server periodically monitors for the existence of some condition, and (2) for which the Server sends Notifications to
the Client when the condition is detected.

3.1.40
Underlying System
hardware or software platforms that exist as an independent entity

Note 1 to entry: UA Applications are dependent on an entity’s existence in order to perform UA services. However,
the entity is not dependent on UA Applications.

Note 2 to entry: : Hardware and software platforms include physical hardware, firmware, operating system,
networking, non-UA applications, as well as other UA Applications. A Distributed Control System, PLC/Device, and
UA Server are examples of an Underlying System.

3.1.41
Variable
Node that contains a value

3.1.42
View
specific subset of the AddressSpace that is of interest to the Client

3.2 Abbreviated terms

A&E Alarms and Events
AMQP Advanced Message Queuing Protocol
API Application Programming Interface
COM Component Object Model
DA Data Access
DCS Distributed Control System
DDS Data Distribution Service
HDA Historical Data Access
HMI Human-Machine Interface
JSON JavaScript Object Notation
LDAP Lightweight Directory Access Protocol
MES Manufacturing Execution System
MQTT Message Queue Telemetry Transport
OPC OPC Foundation (a non-profit industry association) formerly an acronym for “OLE
for Process Control”. Acronym no longer used.
PLC Programmable Logic Controller
SCADA Supervisory Control And Data Acquisition
UA Unified Architecture
WSDL Web Services Definition Language
XML Extensible Markup Language
XMPP Extensible Messaging and Presence Protocol
 PD CLC IEC/TR 62541‑1:2021

– 12 – IEC TR 62541-1:2020 © IEC 2020

4 Structure of the OPC UA series

4.1 Specification organization

This specification is organized as a multi-part specification, as illustrated in Figure 1.

OPC UA Multi-Part Specification

Core Specification Parts Access Type Specification Parts

Part 1 – Overview & Concepts Part 8 – Data Access

Part 2 – Security Model Part 9 – Alarms & Conditions

Part 3 – Address Space Model Part 10 – Programs

Part 4 – Services Part 11 – Historical Access

Part 5 – Information Model

Utility Specification Parts
Part 6 – Service Mappings
Part 12 – Discovery
Part 7 – Profiles
Part 13 – Aggregates
Part 14 – PubSub

Figure 1 – OPC UA specification organization

IEC 62541-1 through IEC 62541-7 and IEC 62541-14 specify the core capabilities of OPC UA.
These core capabilities define the structure of the OPC AddressSpace and the Services that
operate on it. IEC 62541-14 1 defines an OPC UA publish subscribe pattern in addition to the
Client Server pattern defined by the Services in IEC 62541-4. IEC 62541-8 through
IEC 62541-11 apply these core capabilities to specific types of access previously addressed by
separate OPC COM specifications, such as Data Access (DA), Alarms and Events (A&E) and
Historical Data Access (HDA). IEC 62541-12 describes Discovery mechanisms for OPC UA and
IEC 62541-13 describes ways of aggregating data.

Readers are encouraged to read IEC 62541-1 through IEC 62541-5 of the core specifications
before reading IEC 62541-8 through IEC 62541-14. For example, a reader interested in UA
Data Access should read IEC 62541-1 through IEC 62541-5 and IEC 62541-8. References in
IEC 62541-8 may direct the reader to other parts of this specification.

4.2 Core specification parts

Part 1 – Overview and Concepts

Part 1 (this document) presents the concepts and overview of OPC UA.

____________
1 Under preparation. Stage at the time of publication: IEC 62541-14/FDIS:2019.
PD CLC IEC/TR 62541‑1:2021

IEC TR 62541-1:2020 © IEC 2020 – 13 –

Part 2 – Security Model

IEC TR 62541-2 describes the model for securing interactions between OPC UA Applications.

Part 3 – Address Space Model

IEC 62541-3 describes the contents and structure of the Server’s AddressSpace.

Part 4 – Services

IEC 62541-4 specifies the Services provided by Servers.

Part 5 – Information Model

IEC 62541-5 specifies the types and their relationships defined for Servers.

Part 6 – Mappings

IEC 62541-6 specifies the mappings to transport protocols and data encodings supported by
OPC UA.

Part 7 – Profiles

IEC 62541-7 specifies the Profiles that are available for OPC UA Applications. These Profiles
provide groupings of functionality that can be used for conformance level certification. OPC UA
Applications will be tested against the Profiles.

4.3 Access Type specification parts

Part 8 – Data Access

IEC 62541-8 specifies the use of OPC UA for data access.

Part 9 – Alarms and Conditions

IEC 62541-9 specifies use of OPC UA support for access to Alarms and Conditions. The base
system includes support for simple Events; this specification extends that support to include
support for Alarms and Conditions.

Part 10 – Programs

IEC 62541-10 specifies OPC UA support for access to Programs.

Part 11 – Historical Access

IEC 62541-11 specifies use of OPC UA for historical access. This access includes both
historical data and historical Events.

4.4 Utility specification parts

Part 12 – Discovery

IEC 62541-12 specifies how Discovery Servers operate in different scenarios and describes
how UA Clients and Servers should interact with them. It also defines how UA related
information should be accessed using common directory service protocols such as LDAP.
 PD CLC IEC/TR 62541‑1:2021

– 14 – IEC TR 62541-1:2020 © IEC 2020

Part 13 – Aggregates

IEC 62541-13 specifies how to compute and return aggregates like minimum, maximum,
average, etc. Aggregates can be used with current and historical data.

Part 14 – PubSub

IEC 62541-14 specifies the OPC Unified Architecture (OPC UA) PubSub communication model.
The PubSub communication model defines an OPC UA publish subscribe pattern in addition to
the Client Server pattern defined by the Services in IEC 62541-4.

5 Overview

5.1 UA scope

OPC UA is applicable to components in all industrial domains, such as industrial sensors and
actuators, control systems, Manufacturing Execution Systems and Enterprise Resource
Planning Systems, including the Industrial Internet of Things (IIoT), Machine To Machine (M2M)
as well as Industrie 4.0 and China 2025. These systems are intended to exchange information
and to use command and control for industrial processes. OPC UA defines a common
infrastructure model to facilitate this information exchange. OPC UA specifies the following:

• the information model to represent structure, behaviour and semantics;

• the message model to interact between applications;
• the communication model to transfer the data between end-points;
• the conformance model to guarantee interoperability between systems.

5.2 General

OPC UA is a platform-independent standard through which various kinds of systems and

devices can communicate by sending request and response Messages between Clients and
Servers or NetworkMessages between Publishers and Subscribers over various types of
networks. It supports robust, secure communication that assures the identity of OPC UA
Applications and resists attacks.

In the Client Server model, OPC UA defines sets of Services that Servers may provide, and
individual Servers specify to Clients what Service sets they support. Information is conveyed
using OPC UA-defined and vendor-defined data types, and Servers define object models that
Clients can dynamically discover. Servers can provide access to both current and historical
data, as well as Alarms and Events to notify Clients of important changes. OPC UA can be
mapped onto a variety of communication protocols and data can be encoded in various ways to
trade off portability and efficiency.

In addition to the Client Server model, OPC UA defines a mechanism for Publishers to transfer
the information to Subscribers using the PubSub model.

5.3 Design goals

OPC UA provides a consistent, integrated AddressSpace and service model. This allows a
single Server to integrate data, Alarms and Events, and history into its AddressSpace, and to
provide access to them using an integrated set of Services. These Services also include an
integrated security model.

OPC UA also allows Servers to provide Clients with type definitions for the Objects accessed
from the AddressSpace. This allows information models to be used to describe the contents of
the AddressSpace. OPC UA allows data to be exposed in many different formats, including
binary structures and XML or JSON documents. The format of the data may be defined by OPC,
PD CLC IEC/TR 62541‑1:2021

IEC TR 62541-1:2020 © IEC 2020 – 15 –

other standard organizations or vendors. Through the AddressSpace, Clients can query the
Server for the metadata that describes the format for the data. In many cases, Clients with no
pre-programmed knowledge of the data formats will be able to determine the formats at runtime
and properly utilize the data.

OPC UA adds support for many relationships between Nodes instead of being limited to just a
single hierarchy. In this way, a Server may present data in a variety of hierarchies tailored to
the way a set of Clients would typically like to view the data. This flexibility, combined with
support for type definitions, makes OPC UA applicable to a wide array of problem domains. As
illustrated in Figure 2, OPC UA is not targeted at just the SCADA, PLC and DCS interface, but
also as a way to provide greater interoperability between higher level functions.

Corporate Enterprise

OPC UA

Manufacturing, Production and Maintenance

OPC UA
HMI MES SCADA
OPC UA

OPC UA
Adv.
OPC UA Batch
Control
Control

OPC UA

PLC Data
Data
PLC Industrial ??.......??
DCS IndustrialNetworks
Networks Acquisition ??.......??
DCS Acquisition

Figure 2 – OPC UA target applications

OPC UA is designed to provide robustness of published data. A major feature of all OPC servers
is the ability to publish data and Event Notifications. OPC UA provides mechanisms for Clients
to quickly detect and recover from communication failures associated with these transfers
without having to wait for long timeouts provided by the underlying protocols.

OPC UA is designed to support a wide range of Servers, from plant floor PLCs to enterprise
Servers. These Servers are characterized by a broad scope of size, performance, execution
platforms and functional capabilities. Therefore, OPC UA defines a comprehensive set of
capabilities, and Servers may implement a subset of these capabilities. To promote
interoperability, OPC UA defines subsets, referred to as Profiles, to which Servers may claim
conformance. Clients can then discover the Profiles of a Server, and tailor their interactions
with that Server based on the Profiles. Profiles are defined in IEC 62541-7.

The OPC UA specifications are layered to isolate the core design from the underlying computing
technology and network transport. This allows OPC UA to be mapped to future technologies as
necessary, without negating the basic design. Mappings and data encodings are described in
IEC 62541-6. Three data encodings are defined:

• XML/text,
• UA Binary,
• JSON.
 PD CLC IEC/TR 62541‑1:2021

– 16 – IEC TR 62541-1:2020 © IEC 2020

In addition, several protocols are defined:

• OPC UA TCP,
• HTTPS,
• WebSockets.

OPC UA Applications that support multiple transports and encodings will allow the end users to
make decisions about trade-offs between performance and compatibility at the time of
deployment, rather than having these trade-offs determined by the OPC vendor at the time of
product definition.

OPC UA is designed as the migration path for OPC clients and servers that are based on
Microsoft COM technology. Care has been taken in the design of OPC UA so that existing data
exposed by OPC COM servers (DA, HDA and A&E) can easily be mapped and exposed via
OPC UA. Vendors may choose migrating their products natively to OPC UA or use external
wrappers to convert from OPC COM to OPC UA and vice-versa. Each of the previous OPC
specifications defined its own address space model and its own set of Services. OPC UA unifies
the previous models into a single integrated address space with a single set of Services.

OPC UA PubSub opens new application fields for OPC UA. The following are some example
uses for PubSub:

• Configurable peer to peer communication between controllers and between controllers and
HMIs. The peers are not directly connected and do not even need to know about the
existence of each other. The data exchange often requires a fixed time-window; it may be
point-to-point or a multi-point connection.
• Asynchronous workflows. For example, an order processing application can place an order
on a message queue or an enterprise service bus. From there it can be processed by one
or more workers.
• Logging to multiple systems. For example, sensors or actuators can write logs to a
monitoring system, an HMI, an archive application for later querying, and so on.
• Servers representing services or devices can stream data to applications hosted in the
cloud; for example, backend servers, big data analytics for system optimization and
predictive maintenance.

PubSub is not bound to a particular messaging system. Rather, it can be mapped to various
different systems as illustrated with two examples:

• PubSub with UDP may be well-suited in production environments for frequent transmissions
of small amounts of data. It also allows data exchange in one-to-one and one-to-many
configurations.
• The use of established messaging protocols (e.g. the ISO/IEC AMQP 1.0 protocol) with
JSON data encoding supports the cloud integration path and readily allows handling of the
information in modern stream and batch analytics systems.

5.4 Integrated models and services

5.4.1 Security model

5.4.1.1 General

OPC UA security is concerned with the authentication of Clients and Servers, the authentication
of users, the integrity and confidentiality of their communications, and the verifiability of claims
of functionality. It does not specify the circumstances under which various security mechanisms
are required. That specification is crucial, but it is made by the designers of the system at a
given site and may be specified by other standards.

Rather, OPC UA provides a security model, described in IEC TR 62541-2, in which security
measures can be selected and configured to meet the security needs of a given installation.
PD CLC IEC/TR 62541‑1:2021

IEC TR 62541-1:2020 © IEC 2020 – 17 –

This model includes security mechanisms and parameters. In some cases, the mechanism for
exchanging security parameters is defined, but the way that applications use these parameters
is not. This framework also defines a minimum set of security Profiles that all OPC UA
Applications support, even though they may not be used in all installations. Security Profiles
are defined in IEC 62541-7.

5.4.1.2 Discovery and Session establishment

Application level security relies on a secure communication channel that is active for the
duration of the application Session and ensures the integrity of all Messages that are
exchanged. This means users need to be authenticated only once, when the application Session
is established. The mechanisms for discovering Servers and establishing secure
communication channels and application Sessions are described in IEC 62541-4 and
IEC 62541-6. Additional information about the Discovery process is described in
IEC 62541-12.

When a Session is established, the Client and Server applications negotiate a secure
communications channel. Digital (ITU X.509) Certificates are utilized to identify the Client and
Server. The Server further authenticates the user and authorizes subsequent requests to
access Objects in the Server.

5.4.1.3 Auditing

OPC UA includes support for security audit trails with traceability between Client and Server
audit logs. If a security-related problem is detected at the Server, the associated Client audit
log entry can be located and examined. OPC UA also provides the capability for Servers to
generate Event Notifications that report auditable Events to Clients capable of processing and
logging them. OPC UA defines security audit parameters that can be included in audit log
entries and in audit Event Notifications. IEC 62541-5 defines the data types for these
parameters. Not all Servers and Clients provide all of the auditing features. Profiles, found in
IEC 62541-7, indicate which features are supported.

5.4.1.4 Transport security

OPC UA security complements the security infrastructure provided by most web service capable
platforms.

Transport level security can be used to encrypt and sign Messages. Encryption and signatures
protect against disclosure of information and protect the integrity of Messages. Encryption
capabilities are provided by the underlying communications technology used to exchange
Messages between OPC UA Applications. IEC 62541-7 defines the encryption and signature
algorithms to be used for a given Profile.

5.4.2 Integrated AddressSpace model

The set of Objects and related information that the Server makes available to Clients is referred
to as its AddressSpace. The OPC UA AddressSpace represents its contents as a set of Nodes
connected by References.

Primitive characteristics of Nodes are described by OPC-defined Attributes. Attributes are the
only elements of a Server that have data values. Data types that define attribute values may be
simple or complex.

Nodes in the AddressSpace are typed according to their use and their meaning. NodeClasses
define the metadata for the OPC UA AddressSpace. IEC 62541-3 defines the OPC UA
NodeClasses.
 PD CLC IEC/TR 62541‑1:2021

– 18 – IEC TR 62541-1:2020 © IEC 2020

The Base NodeClass defines Attributes common to all Nodes, allowing identification,
classification and naming. Each NodeClass inherits these Attributes and may additionally define
its own Attributes.

To promote interoperability of Clients and Servers, the OPC UA AddressSpace is structured

hierarchically with the top levels the same for all Servers. Although Nodes in the AddressSpace
are typically accessible via the hierarchy, they may have References to each other, allowing
the AddressSpace to represent an interrelated network of Nodes. The model of the
AddressSpace is defined in IEC 62541-3.

Servers may subset the AddressSpace into Views to simplify Client access. Subclause 6.3.4.3
describes AddressSpace Views in more detail.

5.4.3 Integrated object model

The OPC UA Object Model provides a consistent, integrated set of NodeClasses for
representing Objects in the AddressSpace. This model represents Objects in terms of their
Variables, Events and Methods, and their relationships with other Objects. IEC 62541-3
describes this model.

The OPC UA object model allows Servers to provide type definitions for Objects and their
components. Type definitions may be subclassed. They also may be common or they may be
system-specific. ObjectTypes may be defined by standards organizations, vendors or end-
users.

This model allows data, Alarms and Events, and their history to be integrated into a single
Server. For example, Servers are able to represent a temperature transmitter as an Object that
is composed of a temperature value, a set of alarm parameters, and a corresponding set of
alarm limits.

5.4.4 Integrated services

The interface between Clients and Servers is defined as a set of Services. These Services are
organized into logical groupings called Service Sets. Service Sets are discussed in 6.4 and
specified in IEC 62541-4.

OPC UA Services provide two capabilities to Clients. They allow Clients to issue requests to
Servers and receive responses from them. They also allow Clients to subscribe to Servers for
Notifications. Notifications are used by the Server to report occurrences such as Alarms, data
value changes, Events, and Program execution results.

OPC UA Messages may be encoded as text (XML or JSON) or in binary format for efficiency
purposes. They may be transferred using multiple underlying transports, for example TCP or
HTTP. Servers may provide different encodings and transports as defined by IEC 62541-6.

5.5 Sessions

OPC UA Client Server interaction requires a stateful model. The state information is maintained
inside an application Session. Examples of state-information are Subscriptions, user credentials
and continuation points for operations that span multiple requests.

Sessions are defined as logical connections between Clients and Servers. Servers may limit
the number of concurrent Sessions based on resource availability, licensing restrictions, or
other constraints. Each Session is independent of the underlying communications protocols.
Failures of these protocols do not automatically cause the Session to terminate. Sessions
terminate based on Client or Server request, or based on inactivity of the Client. The inactivity
time interval is negotiated during Session establishment.
PD CLC IEC/TR 62541‑1:2021

IEC TR 62541-1:2020 © IEC 2020 – 19 –

6 Systems concepts

6.1 Client Server Overview

The OPC UA systems architecture models Clients and Servers as interacting partners. Each
system may contain multiple Clients and Servers. Each Client may interact concurrently with
one or more Servers, and each Server may interact concurrently with one or more Clients. An
application may combine Server and Client components to allow interaction with other Servers
and Clients as described in 6.3.7.

Clients and Servers are described in 6.2 and 6.3. Figure 3 illustrates the architecture that
includes a combined Server and Client.

Client Client
requests requests
Combined
OPC OPC OPC
UA Server UA Server UA
client responses server responses server
and
client
Published Published
notifications notifications

Figure 3 – OPC UA System architecture

6.2 OPC UA Clients

The OPC UA Client architecture models the Client endpoint of client/server interactions.
Figure 4 illustrates the major elements of a typical Client and how they relate to each other.

OPC UA Client
Client-Application
Requests to Delivery of Requests to Delivery of
send service received service send publishing received
requests responses requests notifications

OPC UA Client API

OPC UA
Communication Req Msg Rsp Msg Publ Msg Notif Msg
Stack

To OPC From To From

UA OPC UA OPC UA OPC UA
server server server server

Figure 4 – OPC UA Client architecture

The Client Application is the code that implements the function of the Client. It uses the Client
API to send and receive OPC UA Service requests and responses to the Server. The Services
defined for OPC UA are described in 6.4, and specified in IEC 62541-4.
 PD CLC IEC/TR 62541‑1:2021

– 20 – IEC TR 62541-1:2020 © IEC 2020

Note that the “Client API” is an internal interface that isolates the Client application code from
an OPC UA Communication Stack. The OPC UA Communication Stack converts Client API calls
into Messages and sends them through the underlying communications entity to the Server at
the request of the Client application. The OPC UA Communication Stack also receives response
and NotificationMessages from the underlying communications entity and delivers them to the
Client application through the Client API.

6.3 OPC UA Servers

6.3.1 General

The OPC UA Server architecture models the Server endpoint of client/server interactions.
Figure 5 illustrates the major elements of the Server and how they relate to each other.

OPC UA Server

OPC UA Server Application

Real
Objects

OPC UA AddressSpace
Monitored
Node Item
Node Node

Node Node
View
Node Node
Node Subscription
Subscription
Node Subscription

OPC UA Server API

OPC UA
Communication Req Msg Rsp Msg Publ Msg Notif Msg
Stack

From To From To
OPC UA OPC UA OPC UA OPC UA
client client client client

Figure 5 – OPC UA Server architecture

6.3.2 Real objects

Real objects are physical or software objects that are accessible by the Server application or
that it maintains internally. Examples include physical devices and diagnostics counters.

6.3.3 Server application

The Server application is the code that implements the function of the Server. It uses the Server
API to send and receive OPC UA Messages from Clients. Note that the “Server API” is an
internal interface that isolates the Server application code from an OPC UA Communication
Stack.
PD CLC IEC/TR 62541‑1:2021

IEC TR 62541-1:2020 © IEC 2020 – 21 –

6.3.4 OPC UA AddressSpace

6.3.4.1 AddressSpace Nodes

The AddressSpace is modelled as a set of Nodes accessible by Clients using OPC UA Services
(interfaces and methods). Nodes in the AddressSpace are used to represent real objects, their
definitions and their References to each other.

6.3.4.2 AddressSpace organization

IEC 62541-3 contains the details of the meta model “building blocks” used to create an
AddressSpace out of interconnected Nodes in a consistent manner. Servers are free to organize
their Nodes within the AddressSpace as they choose. The use of References between Nodes
permits Servers to organize the AddressSpace into hierarchies, a full mesh network of Nodes,
or any possible mix.

IEC 62541-5 defines OPC UA Nodes and References and their expected organization in the
AddressSpace. Some Profiles will not require that all of the UA Nodes be implemented.

6.3.4.3 AddressSpace Views

A View is a subset of the AddressSpace. Views are used to restrict the Nodes that the Server
makes visible to the Client, thus restricting the size of the AddressSpace for the Service
requests submitted by the Client. The default View is the entire AddressSpace. Servers may
optionally define other Views. Views hide some of the Nodes or References in the
AddressSpace. Views are visible via the AddressSpace and Clients are able to browse Views
to determine their structure. Views are often hierarchies, which are easier for Clients to navigate
and represent in a tree.

6.3.4.4 Support for information models

The OPC UA AddressSpace supports information models. This support is provided through:

• Node References that allow Objects in the AddressSpace to be related to each other.
• ObjectType Nodes that provide semantic information for real Objects (type definitions).
• ObjectType Nodes to support subclassing of type definitions.
• Data type definitions exposed in the AddressSpace that allow industry specific data types
to be used.
• OPC UA companion standards that permit industry groups to define how their specific
information models are to be represented in Server AddressSpace.

6.3.5 Subscription entities

6.3.5.1 MonitoredItems

MonitoredItems are entities in the Server created by the Client that monitor AddressSpace
Nodes and their real-world counterparts. When they detect a data change or an event/alarm
occurrence, they generate a Notification that is transferred to the Client by a Subscription.

6.3.5.2 Subscriptions

A Subscription is an endpoint in the Server that publishes Notifications to Clients. Clients control
the rate at which publishing occurs by sending Publish Messages.

6.3.6 OPC UA Service Interface

6.3.6.1 General

The Services defined for OPC UA are described in 6.4, and specified in IEC 62541-4.
 PD CLC IEC/TR 62541‑1:2021

– 22 – IEC TR 62541-1:2020 © IEC 2020

6.3.6.2 Request/response Services

Request/response Services are Services invoked by the Client through the OPC UA Service
Interface to perform a specific task on one or more Nodes in the AddressSpace and to return a
response.

6.3.6.3 Subscription Services

The Publish Service is invoked through the OPC UA Service Interface for the purpose of
periodically sending Notifications to Clients. Notifications include Events, Alarms, data changes
and Program outputs.

6.3.7 Server to Server interactions

Server to Server interactions in the Client Server model are interactions in which one Server
acts as a Client of another Server. Server to Server interactions allow for the development of
servers that:

a) exchange information with each other on a peer-to-peer basis, this could include
redundancy or remote Servers that are used for maintaining system wide type definitions
(see Figure 6),
b) are chained in a layered architecture of Servers to provide:
1) aggregation of data from lower-layer Servers,
2) higher-layer data constructs to Clients, and
3) concentrator interfaces to Clients for single points of access to multiple underlying
Servers.

Figure 6 illustrates interactions between Servers.

Network

OPC Server OPC Server

server client
interface Interactions interface
between servers
client server
interface interface

Figure 6 – Peer-to-peer interactions between Servers

Similar peer-to-peer interactions can also be accomplished using the OPC UA PubSub model
where each peer Application is both a Publisher and a Subscriber.

Figure 7 extends the previous example and illustrates the chaining of Servers together for
vertical access to data in an enterprise.
PD CLC IEC/TR 62541‑1:2021

IEC TR 62541-1:2020 © IEC 2020 – 23 –

OPC OPC
Client Client
Enterprise Network
Enterprise
Semantic
OPC Layer
Server

OPC OPC
Client Client Process
Operations Network
Semantic
Layer
OPC OPC
Server Server

OPC OPC
Client Client Device
Plant Floor Network Semantic
Layer
OPC OPC
Server Server

Figure 7 – Chained Server example

6.4 Redundancy

OPC UA provides the data structures and services by which Redundancy may be achieved in a
standardized manner. Redundancy may be used for high availability, fault tolerance and load
balancing. IEC 62541-4 formally defines Client, Server and Network Redundancy. Whether and
what Redundancy is supported by an OPC UA Application is defined by its Profiles. Profiles are
described in IEC 62541-7.

Required client and server behaviours are associated with two distinct modes of Server
Redundancy, transparent and non-transparent. The Client and Server responsibilities when
using either transparent or non-transparent redundancy are defined in IEC 62541-4.

Servers that support non-transparent redundancy can also support client controlled load
balancing. The health of a Server including its ability to Service requests is collectively defined
as ServiceLevel. See IEC 62541-5 for a formal definition of ServiceLevel.
IEC 62541-4 defines four distinct ServiceLevel sub-ranges and example usage.

6.5 Publish-Subscribe

With PubSub, OPC UA Applications do not directly exchange requests and responses. Instead,
Publishers send messages to a Message Oriented Middleware, without knowledge of what, if
any, Subscribers there may be. Similarly, Subscribers express interest in specific types of data,
and process messages that contain this data, without knowledge of what Publishers there are.

Message Oriented Middleware is software or hardware infrastructure supporting sending and

receiving messages between distributed systems. It depends on the Message Oriented
Middleware how this distribution is implemented.

To cover a large number of use cases, OPC UA PubSub supports two largely different Message
Oriented Middleware variants. These are:

• A broker-less form, where the Message Oriented Middleware is the network infrastructure that
is able to route datagram-based messages. Subscribers and Publishers use datagram
protocols like UDP multicast.
 PD CLC IEC/TR 62541‑1:2021

– 24 – IEC TR 62541-1:2020 © IEC 2020

• A broker-based form, where the Message Oriented Middleware is a Broker. Subscribers and
Publishers use standard messaging protocols like AMQP or MQTT to communicate with the
Broker. All messages are published to specific queues (e.g. topics, nodes) that the Broker exposes
and Subscribers can listen to these queues. The Broker may translate messages from the formal
messaging protocol of the Publisher to the formal messaging protocol of the Subscriber.

PubSub is used to communicate messages between different system components without these
components having to know each other’s identity.

A Publisher is pre-configured with what data to send. There is no connection establishment

between Publisher and Subscriber.

The knowledge about who Subscribers are and the forwarding of published data to the
Subscribers is off-loaded to the Message Oriented Middleware. The Publisher does not know or
even care if there is one or many Subscribers. Effort and resource requirements for the
Publisher are predictable and do not depend on the number of Subscribers.

IEC 62541-14 describes the details of the OPC UA PubSub model.

6.6 Synergy of models

PubSub and Client Server are both based on the OPC UA Information Model. PubSub therefore
can easily be integrated into Servers and Clients. Quite typically, a Publisher will be a Server
(the owner of information) and a Subscriber is often a Client. Above all, the PubSub Information
Model for configuration promotes the configuration of Publishers and Subscribers using the
OPC UA Client Server model. Figure 8 depicts a single OPC UA Application that acts as both
a Server and a Publisher.

OPC UA Subscriber 1 Subscriber N

Client A

Message Oriented Middleware

OPC UA Server Client A Session Publisher

DataSetWriter
Subscription
DataSet

Address Space

OPC UA
Application

Figure 8 – Integrated Client Server and PubSub models

Nevertheless, the PubSub communication does not require such a role dependency. That
means, Clients can be Publishers and Servers can be Subscribers. In fact, there is no necessity
PD CLC IEC/TR 62541‑1:2021

IEC TR 62541-1:2020 © IEC 2020 – 25 –

for Publishers or Subscribers to be either a Server or a Client to participate in PubSub

communications.

7 Service Sets

7.1 General

OPC UA Services are divided into Service Sets, each defining a logical grouping of Services
used to access a particular aspect of the Server. The Service Sets are described in 7.2 to 7.11.
The Service Sets and their Services are specified in IEC 62541-4. Whether or not a Server
supports a Service Set, or a specific Service within a Service Set, is defined by its Profile.
Profiles are described in IEC 62541-7.

7.2 Discovery Service Set

This Service Set defines Services used to discover Servers that are available in a system. It
also provides a manner in which clients can read the security configuration required for
connection to the Server. The Discovery Services are implemented by individual Servers and
by dedicated Discovery Servers. Well known dedicated Discovery Servers provide a way for
clients to discover all registered Servers. IEC 62541-12 describes how to use the Discovery
Services with dedicated Discovery Servers.

7.3 SecureChannel Service Set

This Service Set defines Services used to open a communication channel that ensures the
confidentiality and integrity of all Messages exchanged with the Server. The base concepts for
UA security are defined in IEC TR 62541-2.

The SecureChannel Services are unlike other Services because they are typically not
implemented by the OPC UA Application directly. Instead, they are provided by the
communication stack that the OPC UA Application is built on. OPC UA Applications simply need
to verify that a SecureChannel is active whenever it receives a Message. IEC 62541-6 describes
how the SecureChannel Services are implemented with different types of communication
stacks.

A SecureChannel is a long-running logical connection between a single Client and a single

Server. This channel maintains a set of keys that are known only to the Client and Server and
that are used to authenticate and encrypt Messages sent across the network. The
SecureChannel Services allow the Client and Server to securely negotiate the keys to use.

The exact algorithms used to authenticate and encrypt Messages are described in the security
policies for a Server. These policies are exposed via the Discovery Service Set. A Client selects
the appropriate endpoint that supports the desired security policy by the Server when it creates
a SecureChannel.

When a Client and Server are communicating via a SecureChannel, they verify that all incoming
Messages have been signed and/or encrypted according to the security policy. A UA application
is expected to ignore any Message that does not conform to the security policy for the channel.

A SecureChannel is separate from the UA Application Session; however, a single UA

Application Session may only be accessed via a single SecureChannel. This implies that the
UA application is able to determine what SecureChannel is associated with each Message. A
communication stack that provides a SecureChannel mechanism but that does not allow the
application to know what SecureChannel was used for a given Message cannot be used to
implement the SecureChannel Service Set.

The relationship between the UA Application Session and the SecureChannel is illustrated in
Figure 9. The UA applications use the communication stack to exchange Messages. First, the
 PD CLC IEC/TR 62541‑1:2021

– 26 – IEC TR 62541-1:2020 © IEC 2020

SecureChannel Services are used to establish a SecureChannel between the two

communication stacks, allowing them to exchange Messages in a secure way. Second, the UA
applications use the Session Service Set to establish a UA application Session.

OPC UA Client OPC UA Server

UA Application Session UA Application

Communication Stack Communication Stack

SecureChannel

Figure 9 – SecureChannel and Session Services

7.4 Session Service Set

This Service Set defines Services used to establish an application-layer connection in the
context of a Session on behalf of a specific user.

7.5 NodeManagement Service Set

The NodeManagement Service Set allows Clients to add, modify, and delete Nodes in the
AddressSpace. These Services provide an interface for the configuration of Servers.

7.6 View Service Set

Views are publicly defined, Server-created subsets of the AddressSpace. The entire
AddressSpace is the default View, and therefore, the View Services are capable of operating
on the entire AddressSpace. Future versions of this specification may also define Services to
create Client defined Views.

The View Service Set allows Clients to discover Nodes in a View by browsing. Browsing allows
Clients to navigate up and down the hierarchy, or to follow References between Nodes
contained in the View. In this manner, browsing also allows Clients to discover the structure of
the View.

7.7 Query Service Set

The Query Service Set allows users to access the address space without browsing and without
knowledge of the logical schema used for internal storage of the data.

Querying allows Clients to select a subset of the Nodes in a View based on some Client-
provided filter criteria. The Nodes selected from the View by the query statement are called a
result set.

Servers may find it difficult to process queries that require access to runtime data, such as
device data, that involves resource intensive operations or significant delays. In these cases,
the Server may find it necessary to reject the query.
PD CLC IEC/TR 62541‑1:2021

IEC TR 62541-1:2020 © IEC 2020 – 27 –

7.8 Attribute Service Set

The Attribute Service Set is used to read and write Attribute values. Attributes are primitive
characteristics of Nodes that are defined by OPC UA. They may not be defined by Clients or
Servers. Attributes are the only elements in the AddressSpace permitted to have data values.
A special Attribute, the Value Attribute is used to define the value of Variables.

7.9 Method Service Set

Methods represent the function calls of Objects. They are defined in IEC 62541-3. Methods are
invoked and return after completion, whether successful or unsuccessful. Execution times for
Methods may vary, depending on the function they are performing.

The Method Service Set defines the means to invoke Methods. A Method is always a component
of an Object. Discovery is provided through the browse and query Services. Clients discover
the Methods supported by a Server by browsing for the owning Objects that identify their
supported Methods.

Because Methods may control some aspect of plant operations, method invocation may depend
on environmental or other conditions. This may be especially true when attempting to re-invoke
a Method immediately after it has completed execution. Conditions that are required to invoke
the Method may not yet have returned to the state that permits the Method to start again. In
addition, some Methods may be capable of supporting concurrent invocations, while others may
have a single invocation executing at a given time.

7.10 MonitoredItem Service Set

The MonitoredItem Service Set is used by the Client to create and maintain MonitoredItems.
MonitoredItems monitor Variables, Attributes and EventNotifiers. They generate Notifications
when they detect certain conditions. They monitor Variables for a change in value or status;
Attributes for a change in value; and EventNotifiers for newly generated Alarm and Event
reports.

Each MonitoredItem identifies the item to monitor and the Subscription to use to periodically
publish Notifications to the Client (see 7.11). Each MonitoredItem also specifies the rate at
which the item is to be monitored (sampled) and, for Variables and EventNotifiers, the filter
criteria used to determine when a Notification is to be generated. Filter criteria for Attributes
are specified by their Attribute definitions in IEC 62541-4.

The sample rate defined for a MonitoredItem may be faster than the publishing rate of the
Subscription. For this reason, the MonitoredItem may be configured to either queue all
Notifications or to queue only the latest Notification for transfer by the Subscription. In this latter
case, the queue size is one.

MonitoredItem Services also define a monitoring mode. The monitoring mode is configured to
disable sampling and reporting, to enable sampling only, or to enable both sampling and
reporting. When sampling is enabled, the Server samples the item. In addition, each sample is
evaluated to determine if a Notification should be generated. If so, the Notification is queued. If
reporting is enabled, the queue is made available to the Subscription for transfer.

Finally, MonitoredItems can be configured to trigger the reporting of other MonitoredItems. In

this case, the monitoring mode of the items to report is typically set to sampling only, and when
the triggering item generates a Notification, any queued Notifications of the items to report are
made available to the Subscription for transfer.
 PD CLC IEC/TR 62541‑1:2021

– 28 – IEC TR 62541-1:2020 © IEC 2020

7.11 Subscription Service Set

The Subscription Service Set is used by the Client to create and maintain Subscriptions.
Subscriptions are entities that periodically publish NotificationMessages for the MonitoredItem
assigned to them (see 7.10). The NotificationMessage contains a common header followed by
a series of Notifications. The format of Notifications is specific to the type of item being
monitored (i.e. Variables, Attributes, and EventNotifiers).

Once created, the existence of a Subscription is independent of the Client’s Session with the
Server. This allows one Client to create a Subscription, and a second, possibly a redundant
Client, to receive NotificationMessages from it.

To protect against non-use by Clients, Subscriptions have a configured lifetime that Clients
periodically renew. If any Client fails to renew the lifetime, the lifetime expires and the
Subscription is closed by the Server. When a Subscription is closed, all MonitoredItems
assigned to the Subscription are deleted.

Subscriptions include features that support detection and recovery of lost Messages. Each
NotificationMessage contains a sequence number that allows Clients to detect missed
Messages. When there are no Notifications to send within the keep-alive time interval, the
Server sends a keep-alive Message that contains the sequence number of the next
NotificationMessage sent. If a Client fails to receive a Message after the keep-alive interval has
expired, or if it determines that it has missed a Message, it can request the Server to resend
one or more Messages.

___________
NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW

British Standards Institution (BSI)

BSI is the national body responsible for preparing British Standards and other
standards-related publications, information and services.
BSI is incorporated by Royal Charter. British Standards and other standardization
products are published by BSI Standards Limited.

About us Reproducing extracts

We bring together business, industry, government, consumers, innovators For permission to reproduce content from BSI publications contact the BSI
and others to shape their combined experience and expertise into standards Copyright and Licensing team.
-based solutions.
The knowledge embodied in our standards has been carefully assembled in Subscriptions
a dependable format and refined through our open consultation process. Our range of subscription services are designed to make using standards
Organizations of all sizes and across all sectors choose standards to help easier for you. For further information on our subscription products go to bsigroup.
them achieve their goals. com/subscriptions.
With British Standards Online (BSOL) you’ll have instant access to over 55,000
Information on standards British and adopted European and international standards from your desktop.
We can provide you with the knowledge that your organization needs It’s available 24/7 and is refreshed daily so you’ll always be up to date.
to succeed. Find out more about British Standards by visiting our website at You can keep in touch with standards developments and receive substantial
bsigroup.com/standards or contacting our Customer Services team or discounts on the purchase price of standards, both in single copy and subscription
Knowledge Centre. format, by becoming a BSI Subscribing Member.

Buying standards PLUS is an updating service exclusive to BSI Subscribing Members. You will
automatically receive the latest hard copy of your standards when they’re
You can buy and download PDF versions of BSI publications, including British and revised or replaced.
adopted European and international standards, through our website at bsigroup.
com/shop, where hard copies can also be purchased. To find out more about becoming a BSI Subscribing Member and the benefits
of membership, please visit bsigroup.com/shop.
If you need international and foreign standards from other Standards Development
Organizations, hard copies can be ordered from our Customer Services team. With a Multi-User Network Licence (MUNL) you are able to host standards
publications on your intranet. Licences can cover as few or as many users as you
Copyright in BSI publications wish. With updates supplied as soon as they’re available, you can be sure your
documentation is current. For further information, email [email protected].
All the content in BSI publications, including British Standards, is the property
of and copyrighted by BSI or some person or entity that owns copyright in the Revisions
information used (such as the international standardization bodies) and has
formally licensed such information to BSI for commercial publication and use. Our British Standards and other publications are updated by amendment or revision.

Save for the provisions below, you may not transfer, share or disseminate any We continually improve the quality of our products and services to benefit your
portion of the standard to any other person. You may not adapt, distribute, business. If you find an inaccuracy or ambiguity within a British Standard or other
commercially exploit or publicly display the standard or any portion thereof in any BSI publication please inform the Knowledge Centre.
manner whatsoever without BSI’s prior written consent.
Useful Contacts
Storing and using standards Customer Services
Standards purchased in soft copy format: Tel: +44 345 086 9001
• A British Standard purchased in soft copy format is licensed to a sole named Email: [email protected]
user for personal or internal company use only.
Subscriptions
• The standard may be stored on more than one device provided that it is Tel: +44 345 086 9001
accessible by the sole named user only and that only one copy is accessed at Email: [email protected]
any one time.
• A single paper copy may be printed for personal or internal company use only. Knowledge Centre
Tel: +44 20 8996 7004
Standards purchased in hard copy format: Email: [email protected]
• A British Standard purchased in hard copy format is for personal or internal
company use only. Copyright & Licensing
Tel: +44 20 8996 7070
• It may not be further reproduced – in any format – to create an additional copy.
This includes scanning of the document. Email: [email protected]

If you need more than one copy of the document, or if you wish to share the BSI Group Headquarters
document on an internal network, you can save money by choosing a subscription
product (see ‘Subscriptions’). 389 Chiswick High Road London W4 4AL UK

This page deliberately left blank