prEN IEC 62541-1:2024

SLOVENSKI STANDARD
01-marec-2024
Enotna arhitektura OPC - 1. del: Pregled in koncepti
OPC unified architecture - Part 1: Overview and concepts
Ta slovenski standard je istoveten z: prEN IEC 62541-1:2024
ICS:
25.040.40 Merjenje in krmiljenje Industrial process
industrijskih postopkov measurement and control
35.240.50 Uporabniške rešitve IT v IT applications in industry
industriji
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

65E/1039/CDV
COMMITTEE DRAFT FOR VOTE (CDV)
PROJECT NUMBER:
IEC 62541-1 ED1
DATE OF CIRCULATION: CLOSING DATE FOR VOTING:
2024-01-26 2024-04-19
SUPERSEDES DOCUMENTS:
65E/949/NP, 65E/1009/RVN
IEC SC 65E : DEVICES AND INTEGRATION IN ENTERPRISE SYSTEMS
SECRETARIAT: SECRETARY:
United States of America Mr Donald (Bob) Lattimer
OF INTEREST TO THE FOLLOWING COMMITTEES: PROPOSED HORIZONTAL STANDARD:

Other TC/SCs are requested to indicate their interest, if any,
in this CDV to the secretary.
FUNCTIONS CONCERNED:
EMC ENVIRONMENT QUALITY ASSURANCE SAFETY
SUBMITTED FOR CENELEC PARALLEL VOTING NOT SUBMITTED FOR CENELEC PARALLEL VOTING
Attention IEC-CENELEC parallel voting
The attention of IEC National Committees, members of
CENELEC, is drawn to the fact that this Committee Draft for
Vote (CDV) is submitted for parallel voting.
The CENELEC members are invited to vote through the
CENELEC online voting system.
This document is still under study and subject to change. It should not be used for reference purposes.
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which
they are aware and to provide supporting documentation.
Recipients of this document are invited to submit, with their comments, notification of any relevant “In Some Countries”
clauses to be included should this proposal proceed. Recipients are reminded that the CDV stage is the final stage for
submitting ISC clauses. (SEE AC/22/2007 OR NEW GUIDANCE DOC).

TITLE:
OPC Unified Architecture – Part 1: Overview and Concepts

PROPOSED STABILITY DATE: 2026
NOTE FROM TC/SC OFFICERS:
electronic file, to make a copy and to print out the content for the sole purpose of preparing National Committee positions.
You may not copy or "mirror" the file or printed version of the document, or any part of it, for any other purpose without
permission in writing from IEC.

Internal
1 CONTENTS
2 Page
4 1 Scope . 1
5 2 Normative References . 1
6 3 Terms, definitions, and abbreviations . 2
7 Document conventions . 2
8 Terms and definitions . 2
9 Abbreviations . 6
10 4 Structure of the OPC UA series . 7
11 Specification organization . 7
12 Specification parts . 7
13 5 Overview . 8
14 Scope . 8
15 General . 9
16 Design goals . 9
17 Integrated models and services. 11
18 Security model . 11
19 Integrated AddressSpace model . 12
20 Integrated object model . 12
21 Integrated services . 12
22 Sessions . 13
23 6 Systems concepts . 13
24 Client Server Overview . 13
25 OPC UA Clients . 14
26 OPC UA Servers . 15
27 General . 15
28 Real objects . 15
29 Server application . 15
30 OPC UA AddressSpace . 15
31 Subscription entities . 16
32 OPC UA Service Interface . 16
33 Server to Server interactions . 16
34 Redundancy . 17
35 Publish-Subscribe . 18
36 Synergy of models . 18
37 Global Services. 19
38 General . 19
39 Discovery Services. 19
40 Certificate Management . 20
41 KeyCredential Management . 20
42 Authorization Services . 20
43 Device Onboarding . 20
44 Alias Names . 20
45 Security Key Service (SKS) . 20
46 7 Client/Server Service Sets . 20
47 General . 20
48 Discovery Service Set . 20
49 SecureChannel Service Set . 21
50 Session Service Set . 22

Internal
IEC CDV 62541-1 © IEC 2023 ii
51 NodeManagement Service Set . 22
52 View Service Set . 22
53 Query Service Set . 22
54 Attribute Service Set . 22
55 Method Service Set . 22
56 MonitoredItem Service Set . 22
57 Subscription Service Set . 23
60 FIGURES
62 Figure 1 – OPC UA target applications . 10
63 Figure 2 – OPC UA System architecture . 13
64 Figure 3 – OPC UA Client architecture . 14
65 Figure 4 – OPC UA Server architecture . 15
66 Figure 5 – Peer-to-peer interactions between Servers . 17
67 Figure 6 – Chained Server example. 17
68 Figure 7 – Integrated Client Server and PubSub models . 19
69 Figure 8 – SecureChannel and Session Services . 21
72 TABLES
73 No table of figures entries found.
Internal
iii IEC CDV 62541-1 © IEC 2023

75 INTERNATIONAL ELECTROTECHNICAL COMMISSION
76 ____________
78 OPC UNIFIED ARCHITECTURE –
80 Part 1: Overview and Concepts
82 FOREWORD
83 1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national
84 electrotechnical committees (IEC National Committees). The object of IEC is to promote international co-operation on all
85 questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities,
86 IEC publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS)
87 and Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any IEC
88 National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental
89 and non-governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely with
90 the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between
91 the two organizations.
92 2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international consensus
93 of opinion on the relevant subjects since each technical committee has representation from all interested IEC National
94 Committees.
95 3) IEC Publications have the form of recommendations for international use and are accepted by IEC National Committees in
96 that sense. While all reasonable efforts are made to ensure that the technical content of IEC Publications is accurate, IEC
97 cannot be held responsible for the way in which they are used or for any misinterpretation by any end user.
98 4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications transparently to
99 the maximum extent possible in their national and regional publications. Any divergence between any IEC Publication and
100 the corresponding national or regional publication shall be clearly indicated in the latter.
101 5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity assessment
102 services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any services carried out by
103 independent certification bodies.
104 6) All users should ensure that they have the latest edition of this publication.
105 7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of
106 its technical committees and IEC National Committees for any personal injury, property damage or other damage of any
107 nature whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication,
108 use of, or reliance upon, this IEC Publication or any other IEC Publications.
109 8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is indispensable
110 for the correct application of this publication.
111 9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent rights.
112 IEC shall not be held responsible for identifying any or all such patent rights.
113 The main task of IEC technical committees is to prepare International Standards. However, a technical
114 committee may propose the publication of a technical report when it has collected data of a different
115 kind from that which is normally published as an International Standard, for example "state of the art".
116 International Standard IEC 62541-1 has been prepared by subcommittee 65E: Devices and integration
117 in enterprise systems, of IEC technical committee 65: Industrial-process measurement, control and
118 automation.
119 The text of this international standard is based on the following documents:
CDV Report on voting
65E/XX/CDV 65E/XX/RVC
121 Full information on the voting for the approval of this international standard can be found in the report
122 on voting indicated in the above table.
123 This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
124 Throughout this document and the other Parts of the series, certain document conventions are used:

Internal
IEC CDV 62541-1 © IEC 2023 iv
125 Italics are used to denote a defined term or definition that appears in the “Terms and definition” clause
126 in one of the parts of the series.
127 Italics are also used to denote the name of a service input or output parameter or the name of a structure
128 or element of a structure that are usually defined in tables.
129 The italicized terms and names are also often written in camel-case (the practice of writing compound
130 words or phrases in which the elements are joined without spaces, with each element's initial letter
131 capitalized within the compound). For example, the defined term is AddressSpace instead of Address
132 Space. This makes it easier to understand that there is a single definition for AddressSpace, not
133 separate definitions for Address and Space.
134 A list of all parts of the IEC 62541 series is included in IEC 62541-1 clause 4 Structure of the OPC UA
135 series and published under the general title OPC Unified Architecture, can be found on the IEC website.
136 The committee has decided that the contents of this publication will remain unchanged until the stability
137 date indicated on the IEC web site under "http://webstore.iec.ch" in the data related to the specific
138 publication. At this date, the publication will be
139 • reconfirmed,
140 • withdrawn,
141 • replaced by a revised edition, or
142 • amended.
143 A bilingual version of this publication may be issued at a later date.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct understanding
of its contents. Users should therefore print this document using a colour printer.
Internal
1 IEC CDV 62541-1 © IEC 2023
149 OPC Unified Architecture Specification
151 Part 1: Overview and Concepts
154 1 Scope
155 This part of IEC 62541 presents the concepts and overview of the OPC Unified Architecture (OPC
156 UA). Reading this document is helpful to understand the remaining parts of this multi-part document
157 set. Each of the other parts is briefly explained along with a suggested reading order. Except for the
158 Term definitions in clause 3.2, this Part is non-normative.
159 2 Normative References
160 The following documents, in whole or in part, are normatively referenced in this document and are
161 indispensable for its application. For dated references, only the edition cited applies. For undated
162 references, the latest edition of the referenced document (including any amendments and errata)
163 applies.
164 IEC 61508 (all parts), Functional safety of electrical/electronic/programmable electronic safety-related
165 systems
166 https://www.iec.ch/functionalsafety/standards/
167 IEC 61784 3:2017, Industrial communication networks – Profiles – Part 3: Functional safety fieldbuses
168 – General rules and profile definitions
169 https://webstore.iec.ch/publication/61165/
170 IEC 62541-2, OPC Unified Architecture – Part 2: Security
171 IEC 62541-3, OPC Unified Architecture – Part 3: Address Space Model
172 IEC 62541-4, OPC Unified Architecture – Part 4: Services
173 IEC 62541-5, OPC Unified Architecture – Part 5: Information Model
174 IEC 62541-6, OPC Unified Architecture – Part 6: Mappings
175 IEC 62541-7, OPC Unified Architecture – Part 7: Profiles
176 IEC 62541-8, OPC Unified Architecture – Part 8: Data Access
177 IEC 62541-9, OPC Unified Architecture – Part 9: Alarms and Conditions
178 IEC 62541-10, OPC Unified Architecture – Part 10: Programs
179 IEC 62541-11, OPC Unified Architecture – Part 11: Historical Access
180 IEC 62541-12, OPC Unified Architecture – Part 12: Discovery and Global Services
181 IEC 62541-13, OPC Unified Architecture – Part 13: Aggregates
182 IEC 62541-14, OPC Unified Architecture – Part 14: PubSub
183 IEC 62541-15, OPC Unified Architecture - Part 15: Safety

Internal
IEC CDV 62541-1 © IEC 2023 2
184 IEC 62541-16, OPC Unified Architecture - Part 16: State Machines
185 IEC 62541-17, OPC Unified Architecture - Part 17: Alias Names
186 IEC 62541-18, OPC Unified Architecture - Part 18: Role-Based Security
187 IEC 62541-19, OPC Unified Architecture - Part 19: Dictionary References
188 IEC 62541-20, OPC Unified Architecture - Part 20: File Transfer
189 IEC 62541-21, OPC Unified Architecture - Part 21: Device Onboarding
190 IEC 62541-22, OPC Unified Architecture - Part 22: Base Network Model
191 IEC 62541-23, OPC Unified Architecture - Part 23: Common ReferenceTypes
192 IEC 62541-24, OPC Unified Architecture - Part 24: Scheduler
193 X.509, X.509 Public Key Certificate Infrastructure
194 https://www.itu.int/rec/T-REC-X.509
196 3 Terms, definitions, and abbreviations
197 Document conventions
198 Throughout this document and the referenced other Parts of the series, certain document conventions
199 are used.
200 Italics are used to denote a defined term or definition that appears in the “Terms and definition” clause
201 in one of the parts of the series.
202 Italics are also used to denote the name of a service input or output parameter or the name of a
203 structure or element of a structure that are usually defined in tables.
204 The italicized terms and names are also often written in camel-case (the practice of writing compound
205 words or phrases in which the elements are joined without spaces, with each element's initial letter
206 capitalized within the compound). For example, the defined term is AddressSpace instead of Address
207 Space. This makes it easier to understand that there is a single definition for AddressSpace, not
208 separate definitions for Address and Space.
209 Terms and definitions
210 For the purposes of this document, the following terms apply.
212 AddressSpace
213 collection of information that a Server makes visible to its Clients
214 Note 1 to entry: See IEC 62541-3 for a description of the contents and structure of the Server AddressSpace.
216 Aggregate
217 function that calculates derived values from Raw data
218 Note 1 to entry: Raw data may be from a historian or buffered real time data. Common Aggregates include averages over
219 a given time range, minimum over a time range and maximum over a time range.
221 Alarm
222 type of Event associated with a state condition that typically requires acknowledgement
223 Note 1 to entry: See IEC 62541-9 for a description of Alarms.

Internal
3 IEC CDV 62541-1 © IEC 2023
225 Attribute
226 primitive characteristic of a Node
227 Note 1 to entry: All Attributes are defined by OPC UA, and may not be defined by Clients or Servers. Attributes are the only
228 elements in the AddressSpace permitted to have data values.
230 Broker
231 intermediary program module that routes NetworkMessages from Publishers to Subscribers
232 Note 1 to entry: Brokers are building blocks of Message Oriented Middleware.
234 Certificate
235 digitally signed data structure that contains a public key and an identity
236 Note 1 to entry: Certificates are used to identity for example Clients, Servers, users, and certificate authorities.
238 Client
239 software application that sends Messages to OPC UA Servers conforming to the Services specified in
240 this set of specifications
242 Condition
243 generic term that is an extension to an Event
244 Note 1 to entry: A Condition represents the conditions of a system or one of its components and always exists in some
245 state.
247 Communication Stack
248 layered set of software modules between the application and the hardware that provides various
249 functions to encode, encrypt and format a Message for sending, and to decode, decrypt and unpack a
250 Message that was received
252 Complex Data
253 data that is composed of elements of more than one primitive data type, such as a structure
255 DataSet
256 list of named data values
257 Note 1 to entry: A DataSet typically consists of Event fields or Variable values.
259 DataSetMessage
260 payload of a NetworkMessage created from a DataSet
261 Note 1 to entry: The DataSetMessage is an immutable payload of the NetworkMessage handed off to the Message Oriented
262 Middleware (transport layer) for delivery by the Publisher. The Subscriber receives the DataSetMessage as the payload of a
263 NetworkMessage from the Publisher with additional headers that may be supplied by the Message Oriented Middleware along
264 the way.
266 Discovery
267 process by which Client obtains information about Servers, including endpoint and security information
269 Event
270 generic term used to describe an occurrence of some significance within a system or system
271 component
273 EventNotifier
274 special Attribute of a Node that signifies that a Client may subscribe to that particular Node to receive
275 Notifications of Event occurrences

Internal
IEC CDV 62541-1 © IEC 2023 4
277 Information Model
278 organizational framework that defines, characterizes, and relates information resources of a given
279 system or set of systems.
280 Note 1 to entry: The core AddressSpace model supports the representation of Information Models in the AddressSpace.
281 See IEC 62541-5 for a description of the base OPC UA Information Model.
283 Message
284 data unit conveyed between Client and Server that represents a specific Service request or response
286 Message Oriented Middleware
287 infrastructure supporting sending and receiving NetworkMessages between distributed systems
288 Note 1 to entry: An OPC UA Application may support different types of Message Oriented Middleware infrastructures and
289 protocols like AMQP, MQTT, or UDP with IP multicast. Other types like DDS or XMPP can also be integrated into the OPC
290 UA PubSub model.
292 Method
293 callable software function that is a component of an Object
295 MonitoredItem
296 Client-defined entity in the Server used to monitor Attributes or EventNotifiers for new values or Event
297 occurrences and that generates Notifications for them
299 NetworkMessage
300 DataSetMessages and header to facilitate delivery, routing, security, and filtering
301 Note 1 to entry: The Publisher hands off the NetworkMessage to the Message Oriented Middleware (transport layer) to
302 deliver DataSetMessages to the Subscribers.
303 Note 2 to entry: The term message is used with various connotations in the messaging world. The Publisher might like to
304 think of the message as an immutable payload handed off to the Message Oriented Middleware for delivery. The Subscriber
305 often thinks of the message as not only that immutable payload from the sender, but also various annotations supplied by
306 the Message Oriented Middleware along the way. To avoid confusion the term DataSetMessage is used to mean the message
307 as supplied by the Publisher for a DataSet and the term NetworkMessage is used to mean the DataSetMessage plus sections
308 for annotation at the head and tail of the DataSetMessage.
310 Node
311 fundamental component of an AddressSpace
313 NodeClass
314 class of a Node in an AddressSpace
315 Note 1 to entry: NodeClasses define the metadata for the components of the OPC UA object model. They also define
316 constructs, such as Views, that are used to organize the AddressSpace.
318 Notification
319 generic term for data that announces the detection of an Event or of a changed Attribute value;
320 Notifications are sent in NotificationMessages.
322 NotificationMessage
323 Message published from a Subscription that contains one or more Notifications
325 Object
326 Node that represents a physical or abstract element of a system
327 Note 1 to entry: Objects are modelled using the OPC UA Object Model. Systems, subsystems, and devices are examples
328 of Objects. An Object may be defined as an instance of an ObjectType.

Internal
5 IEC CDV 62541-1 © IEC 2023
330 Object Instance
331 synonym for Object
332 Note 1 to entry: Not all Objects are defined by ObjectTypes.
334 ObjectType
335 Node that represents the type definition for an Object
337 OPC UA Application
338 Client, which calls OPC UA Services, or a Server, which performs those Services, or an OPC UA
339 Publisher or an OPC UA Subscriber.
341 Publisher
342 entity sending NetworkMessages to a Message Oriented Middleware
343 Note 1 to entry: A Publisher can be a native OPC UA Application or an application that only has knowledge about the
344 Message Oriented Middleware and the rules for encoding the NetworkMessages and DataSetMessages.
346 PubSub
347 OPC UA variant of the publish subscribe messaging pattern
349 Profile
350 specific set of capabilities to which a Server may claim conformance.
351 Note 1 to entry: Each Server may claim conformance to more than one Profile
352 Note 2 to entry: The set of capabilities are defined in IEC 62541-7
354 Program
355 executable Object that, when invoked, immediately returns a response to indicate that execution has
356 started, and then returns intermediate and final results through Subscriptions identified by the Client
357 during invocation
359 Reference
360 explicit relationship (a named pointer) from one Node to another
361 Note 1 to entry: The Node that contains the Reference is the source Node, and the referenced Node is the target Node. All
362 References are defined by ReferenceTypes.
364 ReferenceType
365 Node that represents the type definition of a Reference
366 Note 1 to entry: The ReferenceType specifies the semantics of a Reference. The name of a ReferenceType identifies how
367 source Nodes are related to target Nodes and generally reflects an operation between the two, such as “A contains B”.
369 Server
370 software application that implements and exposes the Services specified in this set of specifications
372 Service
373 Client-callable operation in a Server
374 Note 1 to entry: Services are defined in IEC 62541-4. A Service is similar to a method call in a programming language or
375 an operation in a Web services WSDL contract.
377 Service Set
378 group of related Services
Internal
IEC CDV 62541-1 © IEC 2023 6
380 Session
381 logical long-running connection between a Client and a Server.
382 Note 1 to entry: A Session maintains state information between Service calls from the Client to the Server.
384 Subscriber
385 entity receiving DataSetMessages from a Message Oriented Middleware
386 Note 1 to entry: A Subscriber can be a native OPC UA Application or an application that has just knowledge about the
387 Message Oriented Middleware and the rules for decoding the NetworkMessages and DataSetMessages. A Subscription in
388 the OPC UA Client Server model has a different meaning than the Subscriber in the PubSub model.
391 Subscription
392 Client-defined endpoint in the Server, used to return Notifications to the Client
393 Note 1 to entry: Subscription is a generic term that describes a set of Nodes selected by the Client (1) that the Server
394 periodically monitors for the existence of some condition, and (2) for which the Server sends Notifications to the Client when
395 the condition is detected.
397 Underlying System
398 hardware or software platforms that exist as an independent entity. UA Applications are dependent on
399 an entity’s existence in order to perform UA services. However, the entity is not dependent on UA
400 Applications.
401 Note 1 to entry: Hardware and software platforms include physical hardware, firmware, operating system, networking,
402 non-UA applications, as well as other UA Applications. A Distributed Control System, PLC/Device, and UA Server are
403 examples of an Underlying System.
405 Variable
406 Node that contains a value
408 View
409 specific subset of the AddressSpace that is of interest to the Client.
410 Abbreviations
411 A&E Alarms and Events
412 AMQP Advanced Message Queuing Protocol
413 API Application Programming Interface
414 COM Component Object Model
415 DA Data Access
416 DCS Distributed Control System
417 DDS Data Distribution Service
418 HDA Historical Data Access
419 HMI Human-Machine Interface
420 JSON JavaScript Object Notation
421 LDAP Lightweight Directory Access Protocol
422 MES Manufacturing Execution System
423 MQTT Message Queue Telemetry Transport
424 OAuth2 Open Authorization
425 OPC Open Platform Communications
426 PLC Programmable Logic Controller
427 SCADA Supervisory Control And Data Acquisition
428 UA Unified Architecture
429 UADP UA Datagram Protocol
430 WSDL Web Services Definition Language
431 XML Extensible Markup Language
432 XMPP Extensible Messaging and Presence Protocol

Internal
7 IEC CDV 62541-1 © IEC 2023
433 4 Structure of the OPC UA series
434 Specification organization
435 This specification is organized as a multi-part specification. Parts 1 through 5 describe core concepts
436 of OPC UA, therefore, readers are encouraged to read Parts 1 through 5 of the specification before
437 reading the other Parts.
438 Specification parts
439 Part 1 (IEC 62541-1) – Overview and Concepts
440 Part 1 (this part) presents the concepts and overview of OPC UA.
441 Part 2 (IEC 62541-2) – Security Model
442 Part 2 describes the model for securing interactions between OPC UA Applications.
443 Part 3 (IEC 62541-3) – Address Space Model
444 Part 3 describes the contents and structure of the Server’s AddressSpace.
445 Part 4 (IEC 62541-4) – Services
446 Part 4 specifies the Services provided by Servers.
447 Part 5 (IEC 62541-5) – Information Model
448 Part 5 specifies the types and their relationships defined for Servers.
449 Part 6 (IEC 62541-6) – Mappings
450 Part 6 specifies the mappings to transport protocols and data encodings supported by OPC UA.
451 Part 7 (IEC 62541-7) – Profiles
452 Part 7 specifies the Profiles that are available for OPC UA Applications. These Profiles provide
453 groupings of functionality that can be used for conformance level certification. OPC UA Applications
454 will be tested against the Profiles.
455 Part 8 (IEC 62541-8) – Data Access
456 Part 8 specifies the use of OPC UA for data access.
457 Part 9 (IEC 62541-9) – Alarms and Conditions
458 Part 9 specifies use of OPC UA support for access to Alarms and Conditions. The base system
459 includes support for simple Events; this specification extends that support to include support for Alarms
460 and Conditions.
461 Part 10 (IEC 62541-10) – Programs
462 Part 10 specifies OPC UA support for access to Programs.
463 Part 11 (IEC 62541-11) – Historical Access
464 Part 11 specifies use of OPC UA for historical access. This access includes both historical data and
465 historical Events.
466 Part 12 (IEC 62541-12) – Discovery and Global Services
467 Part 12 specifies how Discovery Servers operate in different scenarios and describes how UA Clients
468 and Servers should interact with them. It also defines Information Models for Certificate management,
469 key credential management and authorization services.
470 Part 13 (IEC 62541-13) – Aggregates

Internal
IEC CDV 62541-1 © IEC 2023 8
471 Part 13 specifies how to compute and return aggregates like minimum, maximum, average etc.
472 Aggregates can be used with current and historical data.
473 Part 14 (IEC 62541-14) – PubSub
474 Part 14 specifies the OPC Unified Architecture (OPC UA) PubSub communication model. The PubSub
475 communication model defines an OPC UA publish subscribe pattern in addition to the Client Server
476 pattern defined by the Services in IEC 62541-4.
477 Part 15 (IEC 62541-15) – Safety
478 Part 15 extends OPC UA to fulfil the requirements of functional safety as defined in the IEC 61508 and
479 IEC 61784 3:2017 series of standards.
480 Part 16 (IEC 62541-16) – State Machines
481 Part 16 specifies the basic infrastructure to model state machines.
482 Part 17 (IEC 62541-17) – Alias Names
483 Part 17 specifies a manner of configuring and exposing an alternate well-defined name for any OPC
484 UA Node in a Server or system.
485 Part 18 (IEC 62541-18) – Role-Based Security
486 Part 18 specifies the basic infrastructure to model role-based access control (RBAC)
487 Part 19 (IEC 62541-19) – Dictionary References
488 Part 19 specifies the basic infrastructure to reference from an OPC UA Information Model to external
489 dictionaries like IEC Common Data Dictionary or ECLASS.
490 Part 20 (IEC 62541-20) – File Transfer
491 Part 20 specifies the basic infrastructure to model file transfers and file systems.
492 Part 21 (IEC 62541-21) – Device Onboarding
493 Part 21 specifies the life cycle of Devices and Composites and mechanisms to verify their authenticity,
494 set up their security and maintain their configuration.
495 Part 22 (IEC 62541-22) – Base Network Model
496 Part 22 specifies an OPC UA Information Model for a basic set of network related components to be
497 used in more specific Information Models.
498 Part 23 (IEC 62541-23) – Common ReferenceTypes
499 Part 23 specifies common types of references between Nodes.
500 Part 24 (IEC 62541-24) – Scheduler
501 Part 24 specifies an OPC UA information model to expose and configure the dates and times specific
502 actions are executed by the OPC UA Server.
503 5 Overview
504 Scope
505 OPC UA is applicable to components in all industrial domains, such as industrial sensors and
506 actuators, control systems, Manufacturing Execution Systems and Enterprise Resource Planning
507 Systems, including the Industrial Internet of Things (IIoT), Machine To Machine (M2M) and others.
508 These systems are intended to exchange information and to use command and control for industrial
509 processes. OPC UA defines a common infrastructure model to facilitate this information exchange.
510 OPC UA specifies the following:

Internal
9 IEC CDV 62541-1 © IEC 2023
511 • the information model to represent structure, behaviour and semantics;
512 • the message model to interact between applications;
513 • the communication model to transfer the data between end-points;
514 • the conformance model to guarantee interoperability between systems.
515 General
516 OPC UA is a platform-independent standard through which various kinds of systems and devices can
517 communicate by sending request and response Messages between Clients and Servers or
518 NetworkMessages between Publishers and Subscribers over various types of networks. It supports
519 robust, secure communication that assures the identity of OPC UA Applications and resists attacks.
520 In the Client Server model, OPC UA defines sets of Services that Servers may provide, and individual
521 Servers specify to Clients what Service sets they support. Information is conveyed using OPC UA-
522 defined and vendor-defined data types, and Servers define object models that Clients can dynamically
523 discover. Servers can provide access to both current and historical data, as well as Alarms and Events
524 to notify Clients of important changes. OPC UA can be mapped onto a variety of communication
525 protocols and data can be encoded in various ways to trade off portability and efficiency.
526 In addition to the Client Server model, OPC UA defines a mechanism for Publishers to transfer the
527 information to Subscribers using the PubSub model.
528 Design goals
529 OPC UA provides a consistent, integrated AddressSpace and service model. This allows a single
530 Server to integrate data, Alarms and Events, and history into its AddressSpace, and to provide access
531 to them using an integrated set of Services. These Services also include an integrated security model.
532 OPC UA also allows Servers to provide Clients with type definitions for the Objects accessed from the
533 AddressSpace. This allows Information Models to be used to describe the contents of the
534 AddressSpace. OPC UA allows data to be exposed in many different formats, including binary
535 structures and XML or JSON documents. The format of the data may be defined by OPC, other
536 standard organizations or vendors. Through the AddressSpace, Clients can query the Server for the
537 metadata that describes the format for the data. In many cases, Clients with no pre-programmed
538 knowledge of the data formats will be able to determine the formats at runtime and properly utilize the
539 data.
540 OPC UA adds support for many relationships between Nodes instead of being limited to just a single
541 hierarchy. In this way, a Server may present data in a variety of hierarchies tailored to the way a set
542 of Clients would typically like to view the data. This flexibility, combined with support for type
543 definitions, makes OPC UA applicable to a wide array of problem domains. As illustrated in Figure 1,
544 OPC UA is not targeted at just the SCADA, PLC and DCS interface, but also as a way to provide
545 greater interoperability between higher level functions.

Internal
OOPPC UAC UA
OOPPC UAC UA
IEC CDV 62541-1 © IEC 2023 10
Corporate Enterprise
Corporate Enterprise
OOPPC UAC UA
Manufacturing, Production and Maintenance
Manufacturing, Production and Maintenance
OOPPCC UA UA
HMHMII MMESES SSCACADADA
Adv.
Adv.
BBatatchch
OPC UA
OPC UA
CContontrrolol
Control
Control
OOPPC UAC UA
Data
PLC
Data
PLC ??.??
Industrial Networks
??.??
DCS Industrial Networks Acquisition
DCS Acquisition
547 Figure 1 – OPC UA target applications
548 OPC UA is designed to provide robustness of published data. A major feature of all OPC servers is
549 the ability to publish data and Event Notifications. OPC UA provides mechanisms for Clients to quickly
550 detect and recover from communication failures associated with these transfers without having to wait
551 for long timeouts provided by the underlying protocols.
552 OPC UA is designed to support a wide range of Servers, from plant floor PLCs to enterprise Servers.
553 These Servers are characterized by a broad scope of size, performance, execution platforms and
554 functional capabilities. Therefore, OPC UA defines a comprehensive set of capabilities, and Servers
555 may implement a subset of these capabilities. To promote interoperability, OPC UA defines subsets,
556 referred to as Profiles, to which Servers may claim conformance. Clients can then discover the Profiles
557 of a Server, and tailor their interactions with that Server based on the Profiles. Profiles are defined in
558 IEC 62541-7.
559 The OPC UA architecture is layered to isolate the core design from the underlying computing
560 technology and network transport. This allows OPC UA to be mapped to future technologies as
561 necessary, without negating the basic design. Mappings and data encodings are described in
562 IEC 62541-6. Several data encodings are defined:
563 • XML/text,
564 • UA Binary,
565 • JSON.
566 In addition, several protocols are defined:
567 • OPC UA TCP,
568 • HTTPS,
569 • WebSockets.
570 OPC UA Applications that support multiple transports and encodings will allow the end users to make
571 decisions about trade-offs between performance and compatibility at the time of deployment, rather
572 than having these trade-offs determined by the OPC vendor at the time of product definition.
573 OPC UA is designed as the migration path for OPC clients and servers that are based on Microsoft
574 COM technology. Care has been taken in the design of OPC UA so that existing data exposed by OPC
575 COM servers (DA, HDA and A&E) can easily be mapped and exposed via OPC UA. Vendors may

Internal
11 IEC CDV 62541-1 © IEC 2023
576 choose migrating their products natively to OPC UA or use external wrappers to convert from OPC
577 COM to OPC UA and vice-versa. Each of the previous OPC specifications defined its own address
578 space model and its own set of Services. OPC UA unifies the previous models into a single integrated
579 address space with a single set of Services.
580 OPC UA PubSub opens new application fields for OPC UA. The following are some example uses for
581 PubSub:
582 • Configurable peer to peer communication between controllers and between controllers and HMIs.
...