IEC 62541-1:2025
(Main)OPC Unified Architecture - Part 1: Overview and concepts
OPC Unified Architecture - Part 1: Overview and concepts
IEC 62541-1:2025 presents the concepts and overview of the OPC Unified Architecture (OPC UA). Reading this document is helpful to understand the remaining parts of the IEC 62541 series. Each of the other parts is briefly explained along with a suggested reading order. This first edition cancels and replaces IEC TR 62541-1 published in 2020
Architecture unifiée OPC - Partie 1: Vue d'ensemble et concepts
L'IEC 62541-1:2025 décrit les concepts et donne une vue d'ensemble de l'Architecture unifiée OPC (OPC UA). La lecture du présent document est utile pour comprendre les autres parties de la série IEC 62541. Chacune des autres parties est brièvement expliquée avec un ordre de lecture suggéré. Cette première édition annule et remplace l'IEC TR 62541-1 paru en 2020.
General Information
Relations
Standards Content (Sample)
IEC 62541-1 ®
Edition 1.0 2025-12
INTERNATIONAL
STANDARD
OPC unified architecture -
Part 1: Overview and concepts
ICS 25.040 ISBN 978-2-8327-0828-6
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 Secretariat 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 - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
The advanced search enables to find IEC publications by a publications previews, graphical symbols and the glossary.
variety of criteria (reference number, text, technical With a subscription you will always have access to up to date
committee, …). It also gives information on projects, content tailored to your needs.
replaced and withdrawn publications.
Electropedia - www.electropedia.org
The world's leading online dictionary on electrotechnology,
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
once a month by email. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer
Service Centre: sales@iec.ch.
CONTENTS
FOREWORD . 3
1 Scope . 5
2 Normative references . 5
3 Terms, definitions and abbreviated terms . 5
3.1 Terms and definitions. 5
3.2 Abbreviated terms . 9
4 Structure of the IEC 62541 series . 10
4.1 Series organization . 10
4.2 IEC 62541 series parts . 10
5 Overview . 12
5.1 Scope . 12
5.2 General . 12
5.3 Design goals . 12
5.4 Integrated models and services . 14
5.4.1 Security model . 14
5.4.2 Integrated AddressSpace model . 15
5.4.3 Integrated object model . 16
5.4.4 Integrated services . 16
5.5 Sessions . 16
6 Systems concepts . 17
6.1 Client Server Overview . 17
6.2 OPC UA Clients . 17
6.3 OPC UA Servers . 18
6.3.1 General . 18
6.3.2 Real objects . 18
6.3.3 Server application . 18
6.3.4 OPC UA AddressSpace . 19
6.3.5 Subscription entities . 19
6.3.6 OPC UA Service interface . 20
6.3.7 Server to Server interactions . 20
6.4 Redundancy . 21
6.5 Publish-Subscribe . 21
6.6 Synergy of models . 22
6.7 Global Services . 23
6.7.1 General . 23
6.7.2 Discovery Services . 23
6.7.3 Certificate management . 24
6.7.4 KeyCredential management . 24
6.7.5 Authorization services . 24
6.7.6 Device Onboarding . 24
6.7.7 Alias Names . 24
6.7.8 Security Key Service (SKS) . 24
7 Client/Server 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 . 26
7.9 Method Service Set . 27
7.10 MonitoredItem Service Set . 27
7.11 Subscription Service Set . 27
Bibliography . 29
Figure 1 – OPC UA target applications. 13
Figure 2 – OPC UA system architecture . 17
Figure 3 – OPC UA Client architecture . 17
Figure 4 – OPC UA Server architecture . 18
Figure 5 – Peer-to-peer interactions between Servers . 20
Figure 6 – Chained Server example . 21
Figure 7 – Integrated Client Server and PubSub models . 23
Figure 8 – SecureChannel and Session Services . 26
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) IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in
respect thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s), which
may be required to implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at https://patents.iec.ch. IEC
shall not be held responsible for identifying any or all such patent rights.
IEC 62541-1 has been prepared by subcommittee 65E: Devices and integration in enterprise
systems, of IEC technical committee 65: Industrial-process measurement, control and
automation. It is an International Standard.
This first edition cancels and replaces IEC TR 62541-1 published in 2020.
The text of this International Standard is based on the following documents:
Draft Report on voting
65E/1039/CDV 65E/1093/RVC
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this International Standard is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available
at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are
described in greater detail at www.iec.ch/publications.
Throughout this document and the 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 definitions"
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 in 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 webstore.iec.ch in the data related to the
specific document. At this date, the document will be
– reconfirmed,
– withdrawn, or
– revised.
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 the IEC 62541
series. Each of the other parts is briefly explained along with a suggested reading order.
2 Normative references
There are no normative references in this document.
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following
addresses:
– IEC Electropedia: available at https://www.electropedia.org/
– ISO Online browsing platform: available at https://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 an identity
Note 1 to entry: Certificates are used to identity for example Clients, Servers, users, and certificate authorities.
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.
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
Complex Data
data that is composed of elements of more than one primitive data type, such as a structure
3.1.11
DataSet
list of named data values
Note 1 to entry: A DataSet typically consists of Event fields or Variable values.
3.1.12
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.13
Discovery
process by which Client obtains information about Servers, including endpoint and security
information
3.1.14
Event
generic term used to describe an occurrence of some significance within a system or system
component
3.1.15
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.16
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.17
Message
data unit conveyed between Client and Server that represents a specific Service request or
response
3.1.18
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.19
Method
callable software function that is a component of an Object
3.1.20
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.21
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 can
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.22
Node
fundamental component of an AddressSpace
3.1.23
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.24
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.25
NotificationMessage
Message published from a Subscription that contains one or more Notifications
3.1.26
Object
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.27
Object Instance
synonym for Object
Note 1 to entry: Not all Objects are defined by ObjectTypes.
3.1.28
ObjectType
Node that represents the type definition for an Object
3.1.29
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.30
Publisher
entity sending NetworkMessages to a Message Oriented Middleware
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.31
PubSub
OPC UA variant of the publish subscribe messaging pattern
3.1.32
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.33
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.34
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.35
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.36
Server
software application that implements and exposes the Services specified in this set of
specifications
3.1.37
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.38
Service Set
group of related Services
3.1.39
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.40
Subscriber
entity receiving DataSetMessages from a Message Oriented Middleware
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.41
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.42
Underlying System
hardware or software platforms that exist as an independent entity. 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 1 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.43
Variable
Node that contains a value
3.1.44
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
OAuth2 open authorization
OPC open platform communications
PLC programmable logic controller
SCADA supervisory control and data acquisition
UA unified architecture
UADP UA datagram protocol
WSDL web services definition language
XML extensible markup language
XMPP extensible messaging and presence protocol
4 Structure of the IEC 62541 series
4.1 Series organization
This document is organized as a multi-part standard. Parts 1 through 5 describe core concepts
of OPC UA, therefore, readers are encouraged to read Parts 1 through 5 of the series before
reading the other Parts.
4.2 IEC 62541 series parts
At the time of publication of this document, the IEC 62541 series is composed of the following
parts:
– Part 1 (IEC 62541-1) – Overview and concepts
Part 1 (this part) presents the concepts and overview of OPC UA.
– Part 2 (IEC 62541-2) – Security Model
Part 2 describes the model for securing interactions between OPC UA Applications.
– Part 3 (IEC 62541-3) – Address Space Model
Part 3 describes the contents and structure of the Server's AddressSpace.
– Part 4 (IEC 62541-4) – Services
Part 4 specifies the Services provided by Servers.
– Part 5 (IEC 62541-5) – Information Model
Part 5 specifies the types and their relationships defined for Servers.
– Part 6 (IEC 62541-6) – Mappings
Part 6 specifies the mappings to transport protocols and data encodings supported by
OPC UA.
– Part 7 (IEC 62541-7) – Profiles
Part 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.
– Part 8 (IEC 62541-8) – Data Access
Part 8 specifies the use of OPC UA for data access.
– Part 9 (IEC 62541-9) – Alarms and Conditions
Part 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 (IEC 62541-10) – Programs
Part 10 specifies OPC UA support for access to Programs.
– Part 11 (IEC 62541-11) – Historical Access
Part 11 specifies use of OPC UA for historical access. This access includes both historical
data and historical Events.
– Part 12 (IEC 62541-12) – Discovery and Global Services
Part 12 specifies how Discovery Servers operate in different scenarios and describes how
UA Clients and Servers should interact with them. It also defines Information Models for
Certificate management, key credential management and authorization services.
– Part 13 (IEC 62541-13) – Aggregates
Part 13 specifies how to compute and return aggregates like minimum, maximum, average
etc. Aggregates can be used with current and historical data.
– Part 14 (IEC 62541-14) – PubSub
Part 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.
– Part 15 (IEC 62541-15) – Safety
Part 15 extends OPC UA to fulfil the requirements of functional safety as defined in the
IEC 61508 series of standards and in IEC 61784-3.
– Part 16 (IEC 62541-16) – State Machines
Part 16 specifies the basic infrastructure to model state machines.
– Part 17 (IEC 62541-17) – Alias Names
Part 17 specifies a manner of configuring and exposing an alternate well-defined name for
any OPC UA Node in a Server or system.
– Part 18 (IEC 62541-18) – Role-Based Security
Part 18 specifies the basic infrastructure to model role-based access control (RBAC)
– Part 19 (IEC 62541-19) – Dictionary References
Part 19 specifies the basic infrastructure to reference from an OPC UA Information Model
to external dictionaries like IEC Common Data Dictionary or ECLASS.
– Part 20 (IEC 62541-20) – File Transfer
Part 20 specifies the basic infrastructure to model file transfers and file systems.
– Part 21 (IEC 62541-21) – Device Onboarding
Part 21 specifies the life cycle of Devices and Composites and mechanisms to verify their
authenticity, set up their security and maintain their configuration.
– Part 22 (IEC 62541-22) – Base Network Model
Part 22 specifies an OPC UA Information Model for a basic set of network related
components to be used in more specific Information Models.
– Part 23 (IEC 62541-23) – Common ReferenceTypes
Part 23 specifies common types of references between Nodes.
– Part 24 (IEC 62541-24) – Scheduler
Part 24 specifies an OPC UA information model to expose and configure the dates and times
specific actions are executed by the OPC UA Server.
5 Overview
5.1 Scope
The IEC 62541 series 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) and others. These systems are intended to exchange information and to use
command and control for industrial processes. The IEC 62541 series defines a common
infrastructure model to facilitate this information exchange. The IEC 62541 series 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 can 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, the IEC 62541 series 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 can be defined by OPC,
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 can 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 1, 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.
Figure 1 – 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 can implement a subset of these capabilities. To promote
interoperability, OPC UA defines subsets, referred to as Profiles, to which Servers can 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 is 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.
Several data encodings are defined:
• XML/text,
• UA Binary,
• JSON.
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 (OPC Classic). 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 can 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
specifications of OPC Classic developed by OPC Foundation 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 can 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 is 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 or the
MQTT 5.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 can be specified by other standards.
Rather, OPC UA provides a security model, described in IEC 62541-2, in which security
measures can be selected and configured to meet the security needs of a given installation.
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 cannot 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 will 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 (Recommendation ITU-T X.509 (2019) | ISO/IEC 9594-8:2020,
Information technology - Open Systems Interconnection - The Directory: Public-key and
attribute certificate frameworks) 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 that shall 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 Attributes. Attributes are the only elements
of a Server that have data values. Data types that define attribute values can 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-1 ®
Edition 1.0 2025-12
NORME
INTERNATIONALE
Architecture unifiée OPC -
Partie 1: Vue d'ensemble et concepts
ICS 25.040 ISBN 978-2-8327-0828-6
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et
les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.
IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.
A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.
Recherche de publications IEC - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Découvrez notre puissant moteur de recherche et consultez
La recherche avancée permet de trouver des publications gratuitement tous les aperçus des publications, symboles
IEC en utilisant différents critères (numéro de référence, graphiques et le glossaire. Avec un abonnement, vous aurez
texte, comité d’études, …). Elle donne aussi des toujours accès à un contenu à jour adapté à vos besoins.
informations sur les projets et les publications remplacées
ou retirées. Electropedia - www.electropedia.org
Le premier dictionnaire d'électrotechnologie en ligne au
IEC Just Published - webstore.iec.ch/justpublished monde, avec plus de 22 500 articles terminologiques en
Restez informé sur les nouvelles publications IEC. Just anglais et en français, ainsi que les termes équivalents
dans 25 langues additionnelles. Egalement appelé
Published détaille les nouvelles publications parues.
Disponible en ligne et une fois par mois par email. Vocabulaire Electrotechnique International (IEV) en ligne.
Service Clients - webstore.iec.ch/csc
Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-
nous: sales@iec.ch.
SOMMAIRE
AVANT-PROPOS . 3
1 Domaine d'application . 5
2 Références normatives . 5
3 Termes, définitions et abréviations . 5
3.1 Termes et définitions . 5
3.2 Abréviations . 10
4 Structure de la série IEC 62541 . 10
4.1 Organisation de la série . 10
4.2 Parties de la série IEC 62541 . 11
5 Vue d'ensemble . 12
5.1 Domaine d'application . 12
5.2 Généralités . 13
5.3 Objectifs de conception . 13
5.4 Modèles et services intégrés . 15
5.4.1 Modèle de sécurité . 15
5.4.2 Modèle d'AddressSpace intégré . 16
5.4.3 Modèle d'objet intégré . 17
5.4.4 Services intégrés . 17
5.5 Sessions . 18
6 Concepts de systèmes. 18
6.1 Vue d'ensemble Client/Serveur . 18
6.2 Clients OPC UA . 18
6.3 Serveurs OPC UA . 19
6.3.1 Généralités . 19
6.3.2 Objets réels . 20
6.3.3 Application Serveur . 20
6.3.4 AddressSpace OPC UA . 20
6.3.5 Entités d'abonnement . 21
6.3.6 Interface de services OPC UA . 21
6.3.7 Interactions Serveur/Serveur . 22
6.4 Redondance . 23
6.5 Publication/Abonnement . 23
6.6 Synergie des modèles . 24
6.7 Services globaux . 25
6.7.1 Généralités . 25
6.7.2 Services Découverte . 26
6.7.3 Gestion des certificats . 26
6.7.4 Gestion des KeyCredentials. 26
6.7.5 Services d'autorisation. 26
6.7.6 Mise en service d'appareils . 26
6.7.7 Alias . 26
6.7.8 Service de clés de sécurité (SKS, Security Key Service) . 27
7 Jeux de services Client/Serveur . 27
7.1 Généralités . 27
7.2 Jeu de services Découverte . 27
7.3 Jeu de services SecureChannel . 27
7.4 Jeu de services Session . 28
7.5 Jeu de services NodeManagement . 28
7.6 Jeu de services Vue . 28
7.7 Jeu de services Requête . 29
7.8 Jeu de services Attribut . 29
7.9 Jeu de services Méthode . 29
7.10 Jeu de services MonitoredItem. 29
7.11 Jeu de services Abonnement . 30
Bibliographie . 31
Figure 1 – Applications cibles de l'OPC UA . 14
Figure 2 – Architecture système OPC UA . 18
Figure 3 – Architecture Client OPC UA . 19
Figure 4 – Architecture Serveur OPC UA . 20
Figure 5 – Interactions entre Serveurs homologues . 22
Figure 6 – Exemple de Serveur chaîné . 23
Figure 7 – Modèles Client/Serveur et PubSub intégrés . 25
Figure 8 – Services SecureChannel et Session . 28
COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE
____________
Architecture unifiée OPC -
Partie 1: Vue d'ensemble et concepts
AVANT-PROPOS
1) La Commission Électrotechnique Internationale (IEC) est une organisation mondiale de normalisation composée
de l'ensemble des comités électrotechniques nationaux (Comités nationaux de l'IEC). L'IEC a pour objet de
favoriser la coopération internationale pour toutes les questions de normalisation dans les domaines de
l'électricité et de l'électronique. À cet effet, l'IEC – entre autres activités – publie des Normes internationales,
des Spécifications techniques, des Rapports techniques, des Spécifications accessibles au public (PAS) et des
Guides (ci-après dénommés "Publication(s) de l'IEC"). Leur élaboration est confiée à des comités d'études, aux
travaux desquels tout Comité national intéressé par le sujet traité peut participer. Les organisations
internationales, gouvernementales et non gouvernementales, en liaison avec l'IEC, participent également aux
travaux. L'IEC collabore étroitement avec l'Organisation Internationale de Normalisation (ISO), selon des
conditions fixées par accord entre les deux organisations.
2) Les décisions ou accords officiels de l'IEC concernant les questions techniques représentent, dans la mesure du
possible, un accord international sur les sujets étudiés, étant donné que les Comités nationaux de l'IEC intéressés
sont représentés dans chaque comité d'études.
3) Les Publications de l'IEC se présentent sous la forme de recommandations internationales et sont agréées
comme telles par les Comités nationaux de l'IEC. Tous les efforts raisonnables sont entrepris afin que l'IEC
s'assure de l'exactitude du contenu technique de ses publications; l'IEC ne peut pas être tenue responsable de
l'éventuelle mauvaise utilisation ou interprétation qui en est faite par un quelconque utilisateur final.
4) Dans le but d'encourager l'uniformité internationale, les Comités nationaux de l'IEC s'engagent, dans toute la
mesure possible, à appliquer de façon transparente les Publications de l'IEC dans leurs publications nationales
et régionales. Toutes divergences entre toutes Publications de l'IEC et toutes publications nationales ou
régionales correspondantes doivent être indiquées en termes clairs dans ces dernières.
5) L'IEC elle-même ne fournit aucune attestation de conformité. Des organismes de certification indépendants
fournissent des services d'évaluation de conformité et, dans certains secteurs, accèdent aux marques de
conformité de l'IEC. L'IEC n'est responsable d'aucun des services effectués par les organismes de certification
indépendants.
6) Tous les utilisateurs doivent s'assurer qu'ils sont en possession de la dernière édition de cette publication.
7) Aucune responsabilité ne doit être imputée à l'IEC, à ses administrateurs, employés, auxiliaires ou mandataires,
y compris ses experts particuliers et les membres de ses comités d'études et des Comités nationaux de l'IEC,
pour tout préjudice causé en cas de dommages corporels et matériels, ou de tout autre dommage de quelque
nature que ce soit, directe ou indirecte, ou pour supporter les coûts (y compris les frais de justice) et les dépenses
découlant de la publication ou de l'utilisation de cette Publication de l'IEC ou de toute autre Publication de l'IEC,
ou au crédit qui lui est accordé.
8) L'attention est attirée sur les références normatives citées dans cette publication. L'utilisation de publications
référencées est obligatoire pour une application correcte de la présente publication.
9) L'IEC attire l'attention sur le fait que la mise en application du présent document peut entraîner l'utilisation d'un
ou de plusieurs brevets. L'IEC ne prend pas position quant à la preuve, à la validité et à l'applicabilité de tout
droit de brevet revendiqué à cet égard. À la date de publication du présent document, l'IEC n'avait pas reçu
notification qu'un ou plusieurs brevets pouvaient être nécessaires à sa mise en application. Toutefois, il y a lieu
d'avertir les responsables de la mise en application du présent document que des informations plus récentes
sont susceptibles de figurer dans la base de données de brevets, disponible à l'adresse https://patents.iec.ch.
L'IEC ne saurait être tenue pour responsable de ne pas avoir identifié tout ou partie de tels droits de brevet.
L'IEC 62541-1 a été établie par le sous-comité 65E: Les dispositifs et leur intégration dans les
systèmes de l'entreprise, du comité d'études 65 de l'IEC: Mesure, commande et automation
dans les processus industriels. Il s'agit d'une Norme internationale.
Cette première édition annule et remplace l'IEC TR 62541-1 paru en 2020.
Le texte de cette Norme internationale est issu des documents suivants:
Projet Rapport de vote
65E/1039/CDV 65E/1093/RVC
Le rapport de vote indiqué dans le tableau ci-dessus donne toute information sur le vote ayant
abouti à son approbation.
La langue employée pour l'élaboration de cette Norme internationale est l'anglais.
Ce document a été rédigé selon les Directives ISO/IEC, Partie 2, il a été développé selon les
Directives ISO/IEC, Partie 1 et les Directives ISO/IEC, Supplément IEC, disponibles sous
www.iec.ch/members_experts/refdocs. Les principaux types de documents développés par
l'IEC sont décrits plus en détail sous www.iec.ch/publications.
Dans l'ensemble du présent document et dans les autres parties de la série, certaines
conventions de document sont utilisées:
Le format italique est utilisé pour mettre en évidence un terme défini ou une définition qui
apparaît à l'article "Termes et définitions" dans l'une des parties de la série.
Le format italique est également utilisé pour mettre en évidence le nom d'un paramètre d'entrée
ou de sortie de service, ou le nom d'une structure ou d'un élément de structure habituellement
défini dans les tableaux.
Par ailleurs, les termes et noms en italique sont souvent écrits en camel-case (pratique qui
consiste à joindre, sans espace, les éléments des mots ou expressions composés, la première
lettre de chaque élément étant en majuscule). Par exemple, le terme défini est AddressSpace
et non Espace d'Adressage. Cela permet de mieux comprendre qu'il existe une définition unique
pour AddressSpace, et non deux définitions distinctes pour Espace et pour Adressage.
Une liste de toutes les parties de la série IEC 62541, publiées sous le titre général Architecture
unifiée OPC, se trouve sur le site web de l'IEC.
Le comité a décidé que le contenu de ce document ne sera pas modifié avant la date de stabilité
indiquée sur le site web de l'IEC sous webstore.iec.ch dans les données relatives au document
recherché. À cette date, le document sera
– reconduit,
– supprimé, ou
– révisé.
1 Domaine d'application
La présente partie de l'IEC 62541 décrit les concepts et donne une vue d'ensemble de
l'Architecture unifiée OPC (OPC UA). La lecture du présent document est utile pour comprendre
les autres parties de la série IEC 62541. Chacune des autres parties est brièvement expliquée
avec un ordre de lecture suggéré.
2 Références normatives
Le présent document ne contient aucune référence normative.
3 Termes, définitions et abréviations
3.1 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
L'ISO et l'IEC tiennent à jour des bases de données terminologiques destinées à être utilisées
en normalisation, consultables aux adresses suivantes:
– IEC Electropedia: disponible à l'adresse https://www.electropedia.org/
– ISO Online browsing platform: disponible à l'adresse https://www.iso.org/obp
3.1.1
AddressSpace
collection d'informations qu'un Serveur rend visible pour ses Clients
Note 1 à l'article: Voir IEC 62541-3 pour une description du contenu et de la structure de l'AddressSpace du
Serveur.
3.1.2
Agrégat
fonction qui calcule les valeurs obtenues à partir de Données brutes
Note 1 à l'article: Les Données brutes peuvent provenir d'un historiques ou de données en temps réel mises en
mémoire tampon. Les Agrégats courants incluent les moyennes sur un intervalle de temps donné, les valeurs
minimales sur un intervalle de temps donné et les valeurs maximales sur un intervalle de temps donné.
3.1.3
Alarme
type d'Événement associé à une condition d'état qui exige généralement un acquittement
Note 1 à l'article: Voir l'IEC 62541-9 pour une description des Alarmes.
3.1.4
Attribut
caractéristique primitive d'un Nœud
Note 1 à l'article: Tous les Attributs sont définis par l'OPC UA et peuvent ne pas être définis par les Clients ou les
Serveurs. Les Attributs sont les seuls éléments de l'AddressSpace autorisés à avoir des valeurs de données.
3.1.5
Avec courtier
module de programme intermédiaire qui achemine les NetworkMessages des Éditeurs aux
Abonnés
Note 1 à l'article: Les Courtiers sont des blocs de construction de l'Intergiciel Orienté Message.
3.1.6
Certificat
structure de données signée numériquement qui contient une clé publique et une identité
Note 1 à l'article: Les certificats sont utilisés pour identifier, par exemple, les Clients, les Serveurs, les utilisateurs
et les autorités de certification.
3.1.7
Client
application logicielle qui envoie des Messages aux Serveurs OPC UA conformément aux
Services spécifiés dans cet ensemble de spécifications
3.1.8
Condition
terme générique qui désigne une extension d'un Événement
Note 1 à l'article: Une Condition représente les conditions d'un système ou de l'un de ses composants et existe
toujours dans un certain état.
3.1.9
Pile de communication
ensemble de modules logiciels disposés en couches entre l'application et le matériel qui fournit
différentes fonctions pour coder, chiffrer et formater un Message pour l'envoi, et pour décoder,
déchiffrer et décompresser un Message qui a été reçu
3.1.10
Données complexes
données composées d'éléments de plusieurs types de données primitives, comme une structure
3.1.11
DataSet
liste de valeurs de données nommées
Note 1 à l'article: Un DataSet est généralement constitué de champs d'Événements ou de valeurs de Variables.
3.1.12
DataSetMessage
charge utile d'un NetworkMessage créé à partir d'un DataSet
Note 1 à l'article: Le DataSetMessage est une charge utile immuable du NetworkMessage transmise à l'Intergiciel
Orienté Message (couche transport) pour être livrée par l'Éditeur. L'Abonné reçoit le DataSetMessage comme charge
utile d'un NetworkMessage de l'Éditeur avec des en-têtes supplémentaires qui peuvent être fournis par l'Intergiciel
Orienté Message en cours de route.
3.1.13
Découverte
processus par lequel le Client obtient des informations relatives aux Serveurs, y compris des
informations sur les points d'extrémité et la sécurité
3.1.14
Événement
terme générique utilisé pour décrire une occurrence d'une certaine importance au sein d'un
système ou d'un composant du système
3.1.15
EventNotifier
Attribut spécial d'un Nœud qui signifie qu'un Client peut s'abonner à ce Nœud particulier pour
recevoir des Notifications d'occurrences d'Événements
3.1.16
Modèle d'information
cadre organisationnel qui définit, caractérise et relie les ressources d'information d'un système
ou d'un ensemble de systèmes donné
Note 1 to entry: Le modèle principal de l'AddressSpace prend en charge la représentation des Modèles
d'information dans l'AddressSpace. Voir l'IEC 62541-5 pour une description du Modèle d'information de base de
l'OPC UA.
3.1.17
Message
unité de données transmise entre le Client et le Serveur qui représente une demande ou une
réponse de Service spécifique
3.1.18
Intergiciel Orienté Message
infrastructure qui prend en charge l'envoi et la réception de NetworkMessages entre les
systèmes distribués
Note 1 to entry: Une Application OPC UA peut prendre en charge différents types d'infrastructures et de protocoles
d'Intergiciels Orientés Message comme AMQP, MQTT ou UDP avec multidiffusion IP. D'autres types comme DDS ou
XMPP peuvent également être intégrés dans le modèle PubSub OPC UA.
3.1.19
Méthode
fonction logicielle appelable qui est une composante d'un Objet
3.1.20
MonitoredItem
entité définie par le Client dans le Serveur utilisée pour surveiller les Attributs ou EventNotifiers
par rapport aux nouvelles valeurs ou occurrences d'Événements et qui génère les Notifications
correspondantes
3.1.21
NetworkMessage
DataSetMessages et en-tête pour faciliter la livraison, le routage, la sécurité et le filtrage
Note 1 à l'article: L'Éditeur transmet le NetworkMessage à l'Intergiciel Orienté Message (couche transport) pour
livrer les DataSetMessages aux Abonnés.
Note 2 à l'article: Le terme "message" est utilisé avec différentes connotations dans le domaine de la messagerie.
L'Éditeur peut envisager le message comme une charge utile immuable remise à l'Intergiciel Orienté Message pour
livraison. L'Abonné considère souvent le message comme non seulement la charge utile immuable de l'émetteur,
mais également différentes annotations fournies par l'Intergiciel Orienté Message en cours de route. Pour éviter
toute confusion, le terme DataSetMessage désigne le message fourni par l'Éditeur pour un DataSet et le terme
NetworkMessage désigne le DataSetMessage plus les sections d'annotation au début et à la fin du DataSetMessage.
3.1.22
Nœud
composant fondamental d'un AddressSpace
3.1.23
NodeClass
classe d'un Nœud dans un AddressSpace
Note 1 à l'article: Les NodeClasses définissent les métadonnées des composantes du modèle d'objet OPC UA.
Elles définissent également les constructions telles que les Vues qui sont utilisées pour organiser l'AddressSpace.
3.1.24
Notification
terme générique qui désigne les données qui annoncent la détection d'un Événement ou d'une
valeur d'Attribut modifiée; les Notifications sont envoyées dans des NotificationMessages
3.1.25
NotificationMessage
Message publié à partir d'un Abonnement qui contient une ou plusieurs Notifications
3.1.26
Objet
Nœud qui représente un élément physique ou abstrait d'un système
Note 1 à l'article: Les Objets sont modélisés à l'aide du Modèle d'Objet OPC UA. Les systèmes, sous-systèmes et
appareils sont des exemples d'Objets. Un Objet peut être défini comme une instance d'ObjectType.
3.1.27
Instance d'objet
synonyme d'Objet
Note 1 à l'article: Tous les Objets ne sont pas définis par des ObjectTypes.
3.1.28
ObjectType
Nœud qui représente la définition de type d'un Objet
3.1.29
Application OPC UA
Client qui appelle les Services OPC UA, ou Serveur qui exécute ces Services, ou Éditeur OPC
UA ou Abonné OPC UA
3.1.30
Éditeur
entité qui envoie des NetworkMessages à un Intergiciel Orienté Message
Note 1 à l'article: Un Éditeur peut être une Application OPC UA native ou une application qui connaît uniquement
l'Intergiciel Orienté Message et les règles de codage des NetworkMessages et des DataSetMessages.
3.1.31
PubSub
variante OPC UA du modèle de messagerie publication/abonnement
3.1.32
Profil
ensemble spécifique de capacités auquel un Serveur peut déclarer être conforme
Note 1 à l'article: Chaque Serveur peut déclarer être conforme à plusieurs Profils.
Note 2 à l'article: L'ensemble de capacités est défini dans l'IEC 62541-7.
3.1.33
Programme
Objet exécutable qui, lorsqu'il est appelé, retourne immédiatement une réponse pour indiquer
que l'exécution a démarré, puis retourne des résultats intermédiaires et finaux au moyen
d'Abonnements identifiés par le Client lors de l'invocation
3.1.34
Référence
relation explicite (un pointeur nommé) d'un Nœud à un autre
Note 1 à l'article: Le Nœud qui contient la Référence est le Nœud source, et le Nœud référencé est le Nœud cible.
Toutes les Références sont définies par des ReferenceTypes.
3.1.35
ReferenceType
Nœud qui représente la définition de type d'une Référence
Note 1 à l'article: Le ReferenceType spécifie la sémantique d'une Référence. Le nom d'un ReferenceType identifie
la façon dont les Nœuds sources sont liés aux Nœuds cibles et reflète généralement une opération entre les deux,
par exemple "A contient B".
3.1.36
Serveur
application logicielle qui met en œuvre et indique les Services spécifiés dans cet ensemble de
spécifications
3.1.37
Service
opération appelable par le Client dans un Serveur
Note 1 à l'article: Les Services sont définis dans l'IEC 62541-4. Un Service est similaire à un appel de méthode
dans un langage de programmation ou à une opération dans un contrat WSDL pour les services Web.
3.1.38
Jeu de services
groupe de Services associés
3.1.39
Session
connexion logique de longue durée entre un Client et un Serveur
Note 1 à l'article: Une Session conserve les informations d'état entre deux appels de Service du Client vers le
Serveur.
3.1.40
Abonné
entité qui reçoit des DataSetMessages à partir d'un Intergiciel Orienté Message
Note 1 à l'article: Un Abonné peut être une Application OPC UA native ou une application qui connaît uniquement
l'Intergiciel Orienté Message et les règles de décodage des NetworkMessages et des DataSetMessages. Un
Abonnement dans le modèle Client/Serveur OPC UA a une signification différente de celle de l'Abonné dans le
modèle PubSub.
3.1.41
Abonnement
point d'extrémité défini par le Client dans le Serveur, utilisé pour retourner des Notifications au
Client
Note 1 à l'article: Abonnement est un terme générique qui décrit un ensemble de Nœuds choisis par le Client (1)
que le Serveur surveille régulièrement pour détecter l'existence d'une certaine condition, et (2) pour lequel le Serveur
envoie des Notifications au Client lorsque la condition est détectée.
3.1.42
Système sous-jacent
plateformes matérielles ou logicielles qui existent en tant qu'entité indépendante. Les
Applications UA dépendent de l'existence d'une entité pour réaliser des services UA.
Cependant, l'entité ne dépend pas des Applications UA
Note 1 à l'article: Les plateformes matérielles et logicielles incluent le matériel physique, le micrologiciel, le système
d'exploitation, la mise en réseau, les applications non-UA, ainsi que d'autres Applications UA. Par exemple, un
Système sous-jacent peut se composer d'un Système à commande répartie, d'un PLC/Appareil et d'un Serveur UA.
3.1.43
Variable
Nœud qui contient une valeur
3.1.44
Vue
sous-ensemble spécifique de l'AddressSpace qui intéresse le Client
3.2 Abréviations
A&E Alarmes et Événements
AMQP (advanced message queuing Protocole avancé de mise en file d'attente de
protocol) messages
API (application programming interface) Interface de programmation d'application
COM (component object model) Modèle d'objet composant
DA (data access) Accès aux données
DCS (distributed control system) Système à commande répartie
DDS (data distribution service) Service de distribution des données
HDA (historical data access) Accès aux données historiques
IHM Interface homme-machine
JSON (JavaScript object notation) Notation objet issue de JavaScript
LDAP (lightweight directory access
Protocole LDAP
protocol)
MES (manufacturing execution system) Système d'exécution de la fabrication
MQTT (message queue telemetry transport) Protocole MQTT
Oauth2 (open authorization) Autorisation ouverte
OPC (open platform communications) Communications omniplateformes
PLC (programmable logic controller) Automate programmable
SCADA (supervisory control and data Commande de surveillance et d'acquisition de
acquisition) données
UA (unified architecture) Architecture unifiée
UADP (UA datagram protocol) Protocole de datagramme UA
WSDL (web services definition language) Langage de description des services Web
XML (extensible markup language) Langage de balisage extensible
XMPP (extensible messaging and presence Protocole extensible de présence et de
protocol) messagerie)
4 Structure de la série IEC 62541
4.1 Organisation de la série
Le présent document est organisé sous la forme d'une norme en plusieurs parties. Les Parties
1 à 5 décrivent les concepts de base de l'OPC UA. Par conséquent, les lecteurs sont
encouragés à lire les Parties 1 à 5 de la série avant de lire les autres Parties.
4.2 Parties de la série IEC 62541
Au moment de la publication du présent document, la série IEC 62541 comprend les parties
suivantes:
– Partie 1 (IEC 62541-1) – Vue d'ensemble et concepts
La Partie 1 (la présente partie) décrit les concepts et donne une vue d'ensemble de
l'OPC UA.
– Partie 2 (IEC 62541-2) – Modèle de sécurité
La Partie 2 décrit le modèle de sécurisation des interactions entre les Applications OPC UA.
– Partie 3 (IEC 62541-3) – Modèle d'espace d'adressage
La Partie 3 décrit le contenu et la structure de l'AddressSpace du Serveur.
– Partie 4 (IEC 62541-4) – Services
La Partie 4 définit les Services fournis par les Serveurs.
– Partie 5 (IEC 62541-5) – Modèle d'information
La Partie 5 spécifie les types et leurs relations, définis pour les Serveurs.
– Partie 6 (IEC 62541-6) – Mappings
La Partie 6 définit les mappings avec les protocoles de transport et les codages de données
pris en charge par l'OPC UA.
– Partie 7 (IEC 62541-7) – Profils
La Partie 7 définit les Profils disponibles pour les Applications OPC UA. Ces Profils
fournissent des regroupements de fonctionnalités qui peuvent être utilisés pour la
certification du niveau de conformité. Les Applications OPC UA sont vérifiées par rapport
aux Profils.
– Partie 8 (IEC 62541-8) – Accès aux données
La Partie 8 définit l'utilisation de l'OPC UA pour accéder aux données.
– Partie 9 (IEC 62541-9) – Alarmes et conditions
La Partie 9 définit l'utilisation de la prise en charge par l'OPC UA pour accéder aux Alarmes
et Conditions. Le système de base inclut la prise en charge des Événements simples. Cette
spécification étend la prise en charge pour inclure la prise en charge des Alarmes et des
Conditions.
– Partie 10 (IEC 62541-10) – Programmes
La Partie 10 définit la prise en charge par l'OPC UA pour accéder aux Programmes.
– Partie 11 (IEC 62541-11) – Accès à l'historique
La Partie 11 définit l'utilisation de l'OPC UA pour accéder à l'historique. Cet accès inclut les
données historiques et les Événements historiques.
– Partie 12 (IEC 62541-12) – Services globaux et de découverte
La Partie 12 définit comment les Serveurs Découverte fonctionnent dans différents
scénarios et décrit comment il convient que les Clients et Serveurs UA interagissent avec
eux. Elle définit également les Modèles d'information pour la gestion des Certificats, la
gestion des authentifiants clés et les services d'autorisation.
– Partie 13 (IEC 62541-13) – Agrégats
La Partie 13 définit comment calculer et retourner les agrégats comme le minimum, le
maximum, la moyenne, etc. Les Agrégats peuvent être utilisés avec des données courantes
et historiques.
– Partie 14 (IEC 62541-14) – PubSub
La Partie 14 définit le modèle de communication PubSub de l'Architecture unifiée OPC
(OPC UA). Le modèle de communication PubSub définit un modèle de
publication/abonnement OPC UA en plus du modèle Client/Serveur défini par les Services
dans l'IEC 62541-4.
– Partie 15 (IEC 62541-15) – Sécurité
La Partie 15 étend l'OPC UA pour satisfaire aux exigences de sécurité fonctionnelle définies
dans la série de normes IEC 61508 et dans l'IEC 61784-3.
– Partie 16 (IEC 62541-16) – Diagrammes d'états
La Partie 16 définit l'infrastructure de base pour modéliser les diagrammes d'états.
– Partie 17 (IEC 62541-17) – Alias
La Partie 17 définit une méthode de configuration et de présentation d'un autre nom bien
défini pour tout Nœud OPC UA dans un Serveur ou système.
– Partie 18 (IEC 62541-18) – Sécurité fondée sur les rôles
La Partie 18 définit l'infrastructure de base pour modéliser le contrôle d'accès fondé sur les
rôles (RBAC, Role-Based Access Control).
– Partie 19 (IEC 62541-19) – Références de dictionnaire
La Partie 19 définit l'infrastructure de base pour une référence allant d'un Modèle
d'information OPC UA à des dictionnaires externes comme le Dictionnaire de données
communes de l'IEC ou ECLASS.
– Partie 20 (IEC 62541-20) – Transfert de fichiers
La Partie 20 définit l'infrastructure de base pour modéliser les transferts de fichiers et les
systèmes de fichiers.
– Partie 21 (IEC 62541-21) – Mise en service d'appareils
La Partie 21 définit le cycle de vie des Appareils et Composites, ainsi que les mécanismes
permettant de vérifier leur authenticité, de paramétrer leur sécurité et de maintenir leur
configuration.
– Partie 22 (IEC 62541-22) – Modèle de réseau de base
La Partie 22 définit un Modèle d'information OPC UA pour un ensemble de composants de
base liés au réseau, à utiliser dans des Modèles d'information plus spécifiques.
– Partie 23 (IEC 62541-23) – ReferenceTypes communs
La Partie 23 spécifie les types de références communs entre les Nœuds.
– Partie 24 (IEC 62541-24) – Ordonnanceur
La Partie 24 définit un modèle d'information OPC UA pour indiquer et configurer les dates
et les heures d'exécution d'actions spécifiques par le Serveur OPC UA.
5 Vue d'ensemble
5.1 Domaine d'application
La série IEC 62541 s'applique aux composants de tous les domaines industriels, comme les
capteurs et les actionneurs industriels, les systèmes de commande, les systèmes d'exécution
de la fabrication et les systèmes de planification des ressources de l'entreprise, y compris
l'Internet industriel des objets (IIoT, Industrial Internet of Things), la communication entre
machines (M2M) et autres. Ces systèmes sont destinés à échanger des informations et à utiliser
la commande et le contrôle pour les processus industriels. La série IEC 62541 définit un modèle
d'infrastructure commun pour faciliter cet échange d'informations. La série IEC 62541 définit
les éléments suivants:
• le modèle d'information qui représente la structure, le comportement et la sémantique;
• le modèle de message pour les interactions entre applications;
• le modèle de communication pour le transfert des données entre points d'extrémité;
• le modèle de conformité pour assurer l'interopérabilité entre les systèmes.
5.2 Généralités
L'OPC UA est une norme indépendante de la plateforme par laquelle différents types de
systèmes et d'appareils peuvent communiquer en envoyant des Messages de demande et de
réponse entre Clients et Serveurs ou des NetworkMessages entre Éditeurs et Abonnés sur
différents types de réseaux. Elle prend en charge une communication robuste et sécurisée qui
assure l'identité des Applications OPC UA et qui résiste aux attaques.
Dans le modèle Client/Serveur, l'OPC UA définit des jeux de Services que les Serveurs peuvent
fournir, et chaque Serveur spécifie aux Clients les jeux de Services qu'il prend en charge.
L'information est transmise en utilisant des types de données définis par l'OPC UA et définis
par le fournisseur, et les Serveurs définissent des modèles d'objets que les Clients peuvent
découvrir dynamiquement. Les Serveurs peuvent fournir un accès à des données courantes et
historiques, ainsi que des Alarmes et des Événements pour signaler aux Clients des
modifications importantes. L'OPC UA peut être associée par mapping à une variété de
protocoles de communication et les données peuvent être encodées de différentes façons pour
assurer un compromis entre portabilité et efficacité.
En plus du modèle Client/Serveur, la série IEC 62541 définit un mécanisme permettant aux
Éditeurs de transférer les informations aux Abonnés en utilisant le modèle PubSub.
5.3 Objectifs de conception
L'OPC UA fournit un AddressSpace et un modèle de services cohérents et intégrés. Cela
permet à un Serveur unique d'intégrer les données, les Alarmes et Événements, ainsi que
l'historique dans son AddressSpace, et de fournir un accès à ces derniers au moyen d'un
ensemble intégré de Services. Ces Services incluent également un modèle de sécurité intégré.
L'OPC UA permet également aux Serveurs de fournir aux Clients des définitions de type pour
les Objets accessibles depuis l'AddressSpace. Cela permet d'utiliser des Modèles d'information
pour décrire le contenu de l'AddressSpace. L'OPC UA permet de présenter les données dans
de nombreux formats différents, y compris des structures binaires et des documents XML ou
JSON. Le format des données peut être défini par l'OPC, par d'autres organisations normalisées
ou par des fournisseurs. Les Clients peuvent demander les métadonnées qui décrivent le format
des données au Serveur, au moyen de l'AddressSpace. Dans de nombreux cas, les Clients
sans connaissance préprogrammée des formats de données sont capables de déterminer les
formats lors de l'exécution et d'utiliser les données correctement.
L'OPC UA ajoute la prise en charge de nombreuses relations entre les Nœuds au lieu de se
limiter à une seule hiérarchie. De cette manière, un Serveur peut présenter des données dans
différentes hiérarchies adaptées à la manière dont un ensemble de Clients souhaite
généralement consulter les données. Cette souplesse, associée à la prise en charge des
définitions de type, rend l'OPC UA applicable à un large éventail de domaines de problèmes.
Comme cela est représenté à la Figure 1, l'OPC UA ne cible pas uniquement l'interface SCADA,
PLC et DCS, mais elle vise également à renforcer l'interopérabilité entre les fonctions de niveau
supérieur.
Figure 1 – Applications cibles de l'OPC UA
L'OPC UA est conçue pour assurer la robustesse des données publiées. La capacité à publier
des données et des Notifications d'Événements est une caractéristique majeure de tous les
serveurs OPC. L'OPC UA fournit des mécanismes permettant aux Clients de détecter
rapidement les défaillances de communication associées à ces transferts et de récupérer
rapidement à la suite de celles-ci sans avoir à attendre de longs délais imposés par les
protocoles sous-jacents.
L'OPC UA est conçue pour prendre en charge une large gamme de Serveurs, des PLC de
l'installation de fabrication aux Serveurs d'entreprise. Ces Serveurs sont caractérisés par une
grande variété de tailles, de performances, de plateformes d'exécution et de capacités
fonctionnelles. Par conséquent, l'OPC UA définit un ensemble complet de fonctionnalités, et
les Serveurs peuvent mettre en œuvre un sous-ensemble de ces fonctionnalités. Pour
promouvoir l'interopérabilité, l'OPC UA définit les sous-ensembles, appelés Profils, auxquels
les Serveurs peuvent déclarer être conformes. Les Clients peuvent alors découvrir les Profils
d'un Serveur et adapter leurs interactions avec ce Serveur en fonction des Profils. Les Profils
sont définis dans l'IEC 62541-7.
L'OPC UA est hiérarchisée pour isoler la conception principale des technologies informatiques
sous-jacentes et du transport réseau. Cela permet à l'OPC UA d'être associée par mapping
avec les technologies futures si nécessaire, sans abandonner la conception de base. Les
mappings et les codages de données sont décrits dans l'IEC 62541-6. Plusieurs codages de
données sont définis:
• XML/texte,
• UA Binaire,
• JSON.
En outre, plusieurs protocoles sont définis:
• OPC UA TCP,
• HTTPS,
• WebSockets.
Les Applications OPC UA qui prennent en charge plusieurs transports et codages permettent
aux utilisateurs finaux de prendre des décisions concernant les compromis entre performances
et compatibilité au moment du déploiement, plutôt que de faire en sorte que ces compromis
soient déterminés par le fournisseur OPC au moment de la définition du produit.
L'OPC UA est conçue comme un chemin de migration pour les clients et serveurs OPC qui
reposent sur la technologie Microsoft COM (OPC Classic). La conception de l'OPC UA a fait
l'objet d'une attention particulière, de sorte que les données existantes présentées par les
serveurs OPC COM (DA, HDA et A&E) puissent facilement être associées par mapping et
présentées par l'OPC UA. Les fournisseurs peuvent choisir de faire migrer leurs produits
nativement vers l'OPC UA ou d'utiliser des conteneurs externes pour la conversion de l'OPC
COM vers l'OPC UA et inversement. Chacune des spécifications d'OPC Classic établies par la
Fondation OPC définissait son propre modèle d'espace d'adressage et son propre ensemble
de Services. L'OPC UA unifie les modèles précédents en un espace d'adressage unique intégré
avec un ensemble unique de Services.
Le modèle PubSub OPC UA ouvre de nouveaux champs d'application pour l'OPC UA. Les
exemples suivants représentent des utilisations de PubSub:
• communication configurable entre homologues entre les contrôleurs et entre les contrôleurs
et les IHM. Les homologues ne sont pas directement connectés et n'ont même pas besoin
de connaître l'existence de chacun. L'échange de données exige souvent un intervalle de
temps fixe; il peut s'agir d'une connexion point à point ou d'une connexion multipoint;
• flux de travaux asynchrones. Par exemple, une application de traitement des commandes
peut placer une commande dans une file d'at
...
IEC 62541-1 ®
Edition 1.0 2025-12
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
OPC unified architecture -
Part 1: Overview and concepts
Architecture unifiée OPC -
Partie 1: Vue d'ensemble et concepts
ICS 25.040 ISBN 978-2-8327-0828-6
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.
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et
les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.
IEC Secretariat 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 - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
The advanced search enables to find IEC publications by a publications previews, graphical symbols and the glossary.
variety of criteria (reference number, text, technical With a subscription you will always have access to up to date
committee, …). It also gives information on projects, content tailored to your needs.
replaced and withdrawn publications.
Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
once a month by email. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer
Service Centre: sales@iec.ch.
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.
A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.
Recherche de publications IEC - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Découvrez notre puissant moteur de recherche et consultez
La recherche avancée permet de trouver des publications gratuitement tous les aperçus des publications, symboles
IEC en utilisant différents critères (numéro de référence, graphiques et le glossaire. Avec un abonnement, vous aurez
texte, comité d’études, …). Elle donne aussi des toujours accès à un contenu à jour adapté à vos besoins.
informations sur les projets et les publications remplacées
ou retirées. Electropedia - www.electropedia.org
Le premier dictionnaire d'électrotechnologie en ligne au
IEC Just Published - webstore.iec.ch/justpublished monde, avec plus de 22 500 articles terminologiques en
Restez informé sur les nouvelles publications IEC. Just anglais et en français, ainsi que les termes équivalents
Published détaille les nouvelles publications parues. dans 25 langues additionnelles. Egalement appelé
Disponible en ligne et une fois par mois par email. Vocabulaire Electrotechnique International (IEV) en ligne.
Service Clients - webstore.iec.ch/csc
Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-
nous: sales@iec.ch.
CONTENTS
FOREWORD . 3
1 Scope . 5
2 Normative references . 5
3 Terms, definitions and abbreviated terms . 5
3.1 Terms and definitions. 5
3.2 Abbreviated terms . 9
4 Structure of the IEC 62541 series . 10
4.1 Series organization . 10
4.2 IEC 62541 series parts . 10
5 Overview . 12
5.1 Scope . 12
5.2 General . 12
5.3 Design goals . 12
5.4 Integrated models and services . 14
5.4.1 Security model . 14
5.4.2 Integrated AddressSpace model . 15
5.4.3 Integrated object model . 16
5.4.4 Integrated services . 16
5.5 Sessions . 16
6 Systems concepts . 17
6.1 Client Server Overview . 17
6.2 OPC UA Clients . 17
6.3 OPC UA Servers . 18
6.3.1 General . 18
6.3.2 Real objects . 18
6.3.3 Server application . 18
6.3.4 OPC UA AddressSpace . 19
6.3.5 Subscription entities . 19
6.3.6 OPC UA Service interface . 20
6.3.7 Server to Server interactions . 20
6.4 Redundancy . 21
6.5 Publish-Subscribe . 21
6.6 Synergy of models . 22
6.7 Global Services . 23
6.7.1 General . 23
6.7.2 Discovery Services . 23
6.7.3 Certificate management . 24
6.7.4 KeyCredential management . 24
6.7.5 Authorization services . 24
6.7.6 Device Onboarding . 24
6.7.7 Alias Names . 24
6.7.8 Security Key Service (SKS) . 24
7 Client/Server 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 . 26
7.9 Method Service Set . 27
7.10 MonitoredItem Service Set . 27
7.11 Subscription Service Set . 27
Bibliography . 29
Figure 1 – OPC UA target applications. 13
Figure 2 – OPC UA system architecture . 17
Figure 3 – OPC UA Client architecture . 17
Figure 4 – OPC UA Server architecture . 18
Figure 5 – Peer-to-peer interactions between Servers . 20
Figure 6 – Chained Server example . 21
Figure 7 – Integrated Client Server and PubSub models . 23
Figure 8 – SecureChannel and Session Services . 26
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) IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in
respect thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s), which
may be required to implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at https://patents.iec.ch. IEC
shall not be held responsible for identifying any or all such patent rights.
IEC 62541-1 has been prepared by subcommittee 65E: Devices and integration in enterprise
systems, of IEC technical committee 65: Industrial-process measurement, control and
automation. It is an International Standard.
This first edition cancels and replaces IEC TR 62541-1 published in 2020.
The text of this International Standard is based on the following documents:
Draft Report on voting
65E/1039/CDV 65E/1093/RVC
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this International Standard is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available
at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are
described in greater detail at www.iec.ch/publications.
Throughout this document and the 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 definitions"
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 in 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 webstore.iec.ch in the data related to the
specific document. At this date, the document will be
– reconfirmed,
– withdrawn, or
– revised.
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 the IEC 62541
series. Each of the other parts is briefly explained along with a suggested reading order.
2 Normative references
There are no normative references in this document.
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following
addresses:
– IEC Electropedia: available at https://www.electropedia.org/
– ISO Online browsing platform: available at https://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 an identity
Note 1 to entry: Certificates are used to identity for example Clients, Servers, users, and certificate authorities.
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.
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
Complex Data
data that is composed of elements of more than one primitive data type, such as a structure
3.1.11
DataSet
list of named data values
Note 1 to entry: A DataSet typically consists of Event fields or Variable values.
3.1.12
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.13
Discovery
process by which Client obtains information about Servers, including endpoint and security
information
3.1.14
Event
generic term used to describe an occurrence of some significance within a system or system
component
3.1.15
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.16
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.17
Message
data unit conveyed between Client and Server that represents a specific Service request or
response
3.1.18
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.19
Method
callable software function that is a component of an Object
3.1.20
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.21
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 can
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.22
Node
fundamental component of an AddressSpace
3.1.23
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.24
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.25
NotificationMessage
Message published from a Subscription that contains one or more Notifications
3.1.26
Object
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.27
Object Instance
synonym for Object
Note 1 to entry: Not all Objects are defined by ObjectTypes.
3.1.28
ObjectType
Node that represents the type definition for an Object
3.1.29
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.30
Publisher
entity sending NetworkMessages to a Message Oriented Middleware
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.31
PubSub
OPC UA variant of the publish subscribe messaging pattern
3.1.32
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.33
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.34
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.35
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.36
Server
software application that implements and exposes the Services specified in this set of
specifications
3.1.37
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.38
Service Set
group of related Services
3.1.39
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.40
Subscriber
entity receiving DataSetMessages from a Message Oriented Middleware
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.41
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.42
Underlying System
hardware or software platforms that exist as an independent entity. 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 1 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.43
Variable
Node that contains a value
3.1.44
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
OAuth2 open authorization
OPC open platform communications
PLC programmable logic controller
SCADA supervisory control and data acquisition
UA unified architecture
UADP UA datagram protocol
WSDL web services definition language
XML extensible markup language
XMPP extensible messaging and presence protocol
4 Structure of the IEC 62541 series
4.1 Series organization
This document is organized as a multi-part standard. Parts 1 through 5 describe core concepts
of OPC UA, therefore, readers are encouraged to read Parts 1 through 5 of the series before
reading the other Parts.
4.2 IEC 62541 series parts
At the time of publication of this document, the IEC 62541 series is composed of the following
parts:
– Part 1 (IEC 62541-1) – Overview and concepts
Part 1 (this part) presents the concepts and overview of OPC UA.
– Part 2 (IEC 62541-2) – Security Model
Part 2 describes the model for securing interactions between OPC UA Applications.
– Part 3 (IEC 62541-3) – Address Space Model
Part 3 describes the contents and structure of the Server's AddressSpace.
– Part 4 (IEC 62541-4) – Services
Part 4 specifies the Services provided by Servers.
– Part 5 (IEC 62541-5) – Information Model
Part 5 specifies the types and their relationships defined for Servers.
– Part 6 (IEC 62541-6) – Mappings
Part 6 specifies the mappings to transport protocols and data encodings supported by
OPC UA.
– Part 7 (IEC 62541-7) – Profiles
Part 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.
– Part 8 (IEC 62541-8) – Data Access
Part 8 specifies the use of OPC UA for data access.
– Part 9 (IEC 62541-9) – Alarms and Conditions
Part 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 (IEC 62541-10) – Programs
Part 10 specifies OPC UA support for access to Programs.
– Part 11 (IEC 62541-11) – Historical Access
Part 11 specifies use of OPC UA for historical access. This access includes both historical
data and historical Events.
– Part 12 (IEC 62541-12) – Discovery and Global Services
Part 12 specifies how Discovery Servers operate in different scenarios and describes how
UA Clients and Servers should interact with them. It also defines Information Models for
Certificate management, key credential management and authorization services.
– Part 13 (IEC 62541-13) – Aggregates
Part 13 specifies how to compute and return aggregates like minimum, maximum, average
etc. Aggregates can be used with current and historical data.
– Part 14 (IEC 62541-14) – PubSub
Part 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.
– Part 15 (IEC 62541-15) – Safety
Part 15 extends OPC UA to fulfil the requirements of functional safety as defined in the
IEC 61508 series of standards and in IEC 61784-3.
– Part 16 (IEC 62541-16) – State Machines
Part 16 specifies the basic infrastructure to model state machines.
– Part 17 (IEC 62541-17) – Alias Names
Part 17 specifies a manner of configuring and exposing an alternate well-defined name for
any OPC UA Node in a Server or system.
– Part 18 (IEC 62541-18) – Role-Based Security
Part 18 specifies the basic infrastructure to model role-based access control (RBAC)
– Part 19 (IEC 62541-19) – Dictionary References
Part 19 specifies the basic infrastructure to reference from an OPC UA Information Model
to external dictionaries like IEC Common Data Dictionary or ECLASS.
– Part 20 (IEC 62541-20) – File Transfer
Part 20 specifies the basic infrastructure to model file transfers and file systems.
– Part 21 (IEC 62541-21) – Device Onboarding
Part 21 specifies the life cycle of Devices and Composites and mechanisms to verify their
authenticity, set up their security and maintain their configuration.
– Part 22 (IEC 62541-22) – Base Network Model
Part 22 specifies an OPC UA Information Model for a basic set of network related
components to be used in more specific Information Models.
– Part 23 (IEC 62541-23) – Common ReferenceTypes
Part 23 specifies common types of references between Nodes.
– Part 24 (IEC 62541-24) – Scheduler
Part 24 specifies an OPC UA information model to expose and configure the dates and times
specific actions are executed by the OPC UA Server.
5 Overview
5.1 Scope
The IEC 62541 series 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) and others. These systems are intended to exchange information and to use
command and control for industrial processes. The IEC 62541 series defines a common
infrastructure model to facilitate this information exchange. The IEC 62541 series 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 can 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, the IEC 62541 series 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 can be defined by OPC,
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 can 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 1, 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.
Figure 1 – 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 can implement a subset of these capabilities. To promote
interoperability, OPC UA defines subsets, referred to as Profiles, to which Servers can 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 is 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.
Several data encodings are defined:
• XML/text,
• UA Binary,
• JSON.
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 (OPC Classic). 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 can 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
specifications of OPC Classic developed by OPC Foundation 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 can 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 is 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 or the
MQTT 5.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 can be specified by other standards.
Rather, OPC UA provides a security model, described in IEC 62541-2, in which security
measures can be selected and configured to meet the security needs of a given installation.
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 cannot 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 will be authenticated only once, when the application Session is
established. The mechanisms for discovering Servers and establ
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...