SIST EN IEC 62541-10:2026

OPC unified architecture - Part 10: Programs (IEC 62541-10:2025)

This part of IEC 62541 defines the Information Model associated with Programs in OPC Unified Architecture (OPC UA). This includes the description of the NodeClasses, standard Properties, Methods and Events and associated behaviour and information for Programs.
The complete AddressSpace model including all NodeClasses and Attributes is specified in IEC 62541-3. The Services such as those used to invoke the Methods used to manage
Programs are specified in IEC 62541-4.
An example for a DomainDownload Program is defined in Annex A.

OPC Unified Architecture - Teil 10: Programme (IEC 62541-10:2025)

Architecture unifiée OPC - Partie 10: Programmes (IEC 62541-10:2025)

IEC 62541-10:2025 définit le Modèle d'information associé aux Programmes dans l'Architecture unifiée OPC (OPC Unified Architecture). Elle comprend la description des NodeClasses, des Propriétés, Méthodes et Événements normalisés et du comportement associé ainsi que des informations relatives aux Programmes. Le modèle complet de l'AddressSpace comprenant toutes les NodeClasses et tous les Attributs est spécifié dans l'IEC 62541-3. Les Services tels que ceux utilisés pour invoquer les Méthodes appliquées pour gérer les Programmes sont spécifiés dans l'IEC 62541-4. Un exemple de Programme DomainDownload est défini à l'Annexe A. Cette quatrième édition annule et remplace la troisième édition parue en 2020. Cette édition constitue une révision technique.
Cette édition inclut les modifications techniques majeures suivantes par rapport à l'édition précédente:
- le format du tableau StateMachine a été aligné.

Enotna arhitektura OPC - 10. del: Programi (IEC 62541-10:2025)

Ta del standarda IEC 62541 določa informacijski model, povezan s programi v OPC Unified Architecture (OPC UA). To vključuje opis NodeClasses (razredov vozlišč), standardnih lastnosti, metod in dogodkov ter povezanega vedenja in informacij za programe.
Celoten model AddressSpace (naslovnega prostora), vključno z vsemi NodeClasses in atributi, je določen v IEC 62541-3. Storitve, kot so tiste, ki se uporabljajo za klicanje metod za upravljanje programov, so določene v IEC 62541-4.
Primer za program DomainDownload (prenos domene) je določen v Prilogi A.

General Information

• Status: Published
• Public Enquiry End Date: 30-Mar-2024
• Publication Date: 12-Apr-2026
• ICS: 25.040.40 - Industrial process measurement and control
• ICS: 35.100.05 - Multilayer applications
• ICS: 35.240.50 - IT applications in industry
• Technical Committee: MOV - Measuring equipment for electromagnetic quantities
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 24-Feb-2026
• Due Date: 01-May-2026
• Completion Date: 13-Apr-2026
• Mandate: M/490 - Standardisation mandate to the European Standardisation Organisations (ESOs) to support European Smart Grid deployment
• Ref Project: EN IEC 62541-10:2026 - OPC unified architecture - Part 10: Programs

Relations

• Refers: SIST EN IEC 62541-3:2020 - OPC unified architecture - Part 3: Address Space Model (IEC 62541-3:2020)
• Effective Date: 10-Feb-2026
• Refers: SIST EN IEC 62541-5:2020 - OPC Unified Architecture - Part 5: Information Model
• Effective Date: 10-Feb-2026
• Refers: SIST EN IEC 62541-3:2026 - OPC unified architecture - Part 3: Address space model (IEC 62541-3:2025)
• Effective Date: 03-Feb-2026
• Refers: SIST EN IEC 62541-1:2026 - OPC unified architecture - Part 1: Overview and concepts (IEC 62541-1:2025)
• Effective Date: 03-Feb-2026
• Refers: SIST EN IEC 62541-5:2026 - OPC unified architecture - Part 5: Information model (IEC 62541-5:2026)
• Effective Date: 03-Feb-2026
• Refers: SIST EN IEC 62541-4:2020 - OPC Unified Architecture - Part 4: Services (IEC 62541-4:2020)
• Effective Date: 03-Feb-2026
• Refers: SIST EN IEC 62541-4:2026 - OPC unified architecture - Part 4: Services (IEC 62541-4:2025)
• Effective Date: 03-Feb-2026
• Refers: SIST EN IEC 62541-16:2026 - OPC unified architecture - Part 16: State machines (IEC 62541-16:2025)
• Effective Date: 03-Feb-2026
• Referred By: SIST EN IEC 62769-1:2023 - Field Device Integration (FDI®) - Part 1: Overview (IEC 62769-1:2023)
• Effective Date: 10-Feb-2026
• Referred By: SIST-TP CLC IEC/TR 62541-1:2021 - OPC unified architecture - Part 1: Overview and concepts
• Effective Date: 10-Feb-2026
• Referred By: SIST EN 62769-6:2015 - Devices and integration in enterprise systems; Field Device Integration - Part6: Technology Mapping (IEC 62769-6:2015)
• Effective Date: 10-Feb-2026
• Referred By: SIST EN IEC 62769-6:2021 - Field Device Integration (FDI) - Part 6: Technology Mapping (IEC 62769-6:2021
• Effective Date: 10-Feb-2026
• Referred By: SIST EN 62769-3:2015 - Devices and integration in enterprise systems; Field Device Integration - Part 3: FDI Server (IEC 62769-3:2015)
• Effective Date: 10-Feb-2026
• Referred By: SIST EN IEC 62769-7:2021 - Field Device Integration (FDI) - Part 7: Communication devices (IEC 62769-7:2021)
• Effective Date: 10-Feb-2026
• Referred By: SIST EN 62541-5:2015 - OPC Unified Architecture -- Part 5: Information Model (IEC 62541-5:2015)
• Effective Date: 10-Feb-2026

Overview

prEN IEC 62541-10:2024 / IEC 62541-10:2025 RLV - OPC Unified Architecture (OPC UA) Part 10: Programs defines the information model for Programs in OPC UA. It specifies the structure and behaviour of program-related nodes in the AddressSpace, including NodeClasses, standard Properties, Methods, Events, and program lifecycle semantics. This fourth edition is a technical revision that replaces the 2020 edition and is published as an RLV (redline/version) that shows changes relative to the previous edition.

Key topics

• Information Model for Programs: Definition of Program types and components that represent executable activities or processes within an OPC UA AddressSpace.
• ProgramStateMachineType and FSM: Program finite state machine (states, transitions, stimuli) and alignment of the StateMachine table format (note: the StateMachine model has been moved to Part 16).
• Standard Properties, Methods and Events: Canonical properties and method signatures for controlling programs (start, stop, suspend, resume, etc.), and event types for transition and audit reporting (e.g., ProgramTransitionEventType, AuditProgramTransitionEventType).
• Diagnostics and Result Data: Types for program diagnostics (e.g., ProgramDiagnostic2 DataType / VariableType) and final/intermediate result data structures.
• Security and Lifetime: Security considerations for invoking program methods and guidelines for program lifetime and resource management.
• Examples and Annex A: A DomainDownload program example illustrating state diagrams, methods and event usage.

Practical applications

• Device and PLC vendors: expose embedded or controller-resident programs (recipes, firmware downloads, batch steps) as OPC UA Programs for standardized control and monitoring.
• System integrators and automation engineers: model and orchestrate executable tasks across factories and processes using standardized program semantics.
• MES / IT application developers: consume program states, events and results in higher-level workflows, traceability and auditing.
• Test, QA and security teams: validate program lifecycle, access control and event/audit chains according to the standard.

Who should use this standard

• Automation architects, control-system vendors and device manufacturers implementing OPC UA servers/clients.
• Software developers building OPC UA stacks, industrial applications, or orchestration tools.
• Integrators and consultants designing interoperable solutions across devices, control systems and enterprise systems.

Related standards

• IEC 62541-3 - AddressSpace model (complete node and attribute specifications referenced by Part 10).
• IEC 62541-4 - Services (mechanisms used to invoke Methods for program control).
• IEC 62541-16 - StateMachine model (StateMachine details now consolidated in Part 16).

Keywords: OPC Unified Architecture, OPC UA Programs, IEC 62541-10, ProgramStateMachineType, AddressSpace, Methods, Events, industrial automation, program lifecycle.

Standards Content (Sample)

SLOVENSKI STANDARD
01-maj-2026
Enotna arhitektura OPC - 10. del: Programi (IEC 62541-10:2025)
OPC unified architecture - Part 10: Programs (IEC 62541-10:2025)
OPC Unified Architecture - Teil 10: Programme (IEC 62541-10:2025)
Architecture unifiée OPC - Partie 10: Programmes (IEC 62541-10:2025)
Ta slovenski standard je istoveten z: EN IEC 62541-10:2026
ICS:
25.040.40 Merjenje in krmiljenje Industrial process
industrijskih postopkov measurement and control
35.240.50 Uporabniške rešitve IT v IT applications in industry
industriji
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN IEC 62541-10

NORME EUROPÉENNE
EUROPÄISCHE NORM February 2026
ICS 25.040.40; 35.100.05 Supersedes EN IEC 62541-10:2020
English Version
OPC unified architecture - Part 10: Programs
(IEC 62541-10:2025)
Architecture unifiée OPC - Partie 10: Programmes OPC Unified Architecture - Teil 10: Programme
(IEC 62541-10:2025) (IEC 62541-10:2025)
This European Standard was approved by CENELEC on 2026-01-20. CENELEC members are bound to comply with the CEN/CENELEC
Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Türkiye and the United Kingdom.

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

European foreword
The text of document 65E/1057/CDV, future edition 4 of IEC 62541-10, prepared by SC 65E "Devices
and integration in enterprise systems" of IEC/TC 65 "Industrial-process measurement, control and
automation" was submitted to the IEC-CENELEC parallel vote and approved by CENELEC as
The following dates are fixed:
• latest date by which the document has to be implemented at national (dop) 2027-02-28
level by publication of an identical national standard or by endorsement
• latest date by which the national standards conflicting with the (dow) 2029-02-28
document have to be withdrawn
This document supersedes EN IEC 62541-10:2020 and all of its amendments and corrigenda (if any).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a standardization request addressed to CENELEC by the
European Commission. The Standing Committee of the EFTA States subsequently approves these
requests for its Member States.
Any feedback and questions on this document should be directed to the users’ national committee. A
complete listing of these bodies can be found on the CENELEC website.
Endorsement notice
The text of the International Standard IEC 62541-10:2025 was approved by CENELEC as a European
Standard without any modification.
Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments)
applies.
NOTE 1  Where an International Publication has been modified by common modifications, indicated by (mod),
the relevant EN/HD applies.
NOTE 2  Up-to-date information on the latest versions of the European Standards listed in this annex is available
here: www.cencenelec.eu.
Publication Year Title EN/HD Year
IEC 62541-1 - OPC Unified Architecture - Part 1: EN IEC 62541-1 -
Overview and concepts
IEC 62541-3 - OPC Unified Architecture - Part 3: Address EN IEC 62541-3 -
Space Model
IEC 62541-4 - OPC unified architecture - Part 4: Services EN IEC 62541-4 -
IEC 62541-5 - OPC Unified architecture - Part 5: EN IEC 62541-5 -
Information Model
IEC 62541-16 - OPC unified architecture - Part 16: State EN IEC 62541-16 -
Machines
IEC 62541-10 ®
Edition 4.0 2025-12
INTERNATIONAL
STANDARD
OPC unified architecture -
Part 10: Programs
ICS 25.040.40; 35.100.05 ISBN 978-2-8327-0876-7

IEC 62541-10:2025-12(en)
IEC 62541-10:2025 © IEC 2025
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 . 6
4 Concepts . 6
4.1 General . 6
4.2 Programs . 7
4.2.1 Overview . 7
4.2.2 Security considerations . 8
4.2.3 Program Finite State Machine . 8
4.2.4 Program states . 9
4.2.5 State transitions . 9
4.2.6 Program state transition stimuli . 9
4.2.7 Program Control Methods . 10
4.2.8 Program state transition effects . 10
4.2.9 Program result data . 10
4.2.10 Program lifetime . 11
5 Model . 12
5.1 General . 12
5.2 ProgramStateMachineType . 13
5.2.1 Overview . 13
5.2.2 ProgramStateMachineType Properties . 14
5.2.3 ProgramStateMachineType components . 15
5.2.4 ProgramStateMachineType causes (Methods) . 19
5.2.5 ProgramStateMachineType effects (Events) . 20
5.2.6 AuditProgramTransitionEventType. 21
5.2.7 FinalResultData . 22
5.2.8 ProgramDiagnostic2 DataType . 22
5.2.9 ProgramDiagnostic2Type VariableType . 23
Annex A (informative) Program example . 24
A.1 Overview . 24
A.2 DomainDownload Program . 24
A.2.1 General . 24
A.2.2 DomainDownload states . 25
A.2.3 DomainDownload transitions . 26
A.2.4 DomainDownload Methods . 27
A.2.5 DomainDownload Events. 27
A.2.6 DomainDownload model . 27

Figure 1 – Automation facility control . 6
Figure 2 – Program illustration . 7
Figure 3 – Program states and transitions . 8
Figure 4 – Program Type . 12
Figure 5 – Program FSM References . 15
IEC 62541-10:2025 © IEC 2025
Figure 6 – ProgramStateMachineType causes and effects . 18
Figure A.1 – Program example . 24
Figure A.2 – DomainDownload state diagram . 25
Figure A.3 – DomainDownloadType partial state model . 32
Figure A.4 – Ready To Running model . 34
Figure A.5 – Opening To Sending To Closing model . 36
Figure A.6 – Running To Suspended model . 37
Figure A.7 – Suspended To Running model . 38
Figure A.8 – Running To Halted – Aborted model . 39
Figure A.9 – Suspended To Aborted model . 40
Figure A.10 – Running To Completed model . 41
Figure A.11 – Sequence of operations . 42

Table 1 – Program Finite State Machine . 8
Table 2 – Program states . 9
Table 3 – Program state transitions . 9
Table 4 – Program Control Methods . 10
Table 5 – ProgramStateMachineType . 13
Table 6 – ProgramStateMachineType Attribute values for child Nodes . 14
Table 7 – ProgramStateMachineType Additional References . 16
Table 8 – ProgramStateMachineType causes . 19
Table 9 – ProgramTransitionEventType . 20
Table 10 – AuditProgramTransitionEventType . 21
Table 11 – ProgramDiagnostic2DataType structure . 22
Table 12 – ProgramDiagnostic2DataType definition . 23
Table 13 – ProgramDiagnostic2Type VariableType . 23
Table A.1 – DomainDownload states . 26
Table A.2 – DomainDownloadType . 28
Table A.3 – TransferStateMachineType . 29
Table A.4 – TransferStateMachineType Attribute values for child Nodes . 30
Table A.5 – Finish State Machine Type . 30
Table A.6 – FinishStateMachineType Attribute values for child Nodes . 31
Table A.7 – DomainDownloadType Property Attributes variable values . 31
Table A.8 – TransferStateMachineType Additional References . 33
Table A.9 – Start Method additions. 35
Table A.10 – StartArguments . 35
Table A.11 – IntermediateResults Object . 36
Table A.12 – Intermediate result data Variables . 37
Table A.13 – FinalResultData . 40

IEC 62541-10:2025 © IEC 2025
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
OPC unified architecture -
Part 10: Programs
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-10 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 fourth edition cancels and replaces the third edition published in 2020. This edition
constitutes a technical revision.
This edition includes the following significant technical changes with respect to the previous
edition:
a) StateMachine table format has been aligned.
IEC 62541-10:2025 © IEC 2025
The text of this International Standard is based on the following documents:
Draft Report on voting
65E/1057/CDV 65E/1094/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 IEC 62541 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 IEC 62541 series.
Italics are also used to denote the name of a service input or output parameter or the name of
a structure or element of a structure that are usually defined in tables.
The italicized terms and names are, with a few exceptions, 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.
IEC 62541-10:2025 © IEC 2025
1 Scope
This part of IEC 62541 defines the Information Model associated with Programs in OPC Unified
Architecture (OPC UA). This includes the description of the NodeClasses, standard Properties,
Methods and Events and associated behaviour and information for Programs.
The complete AddressSpace model including all NodeClasses and Attributes is specified in
IEC 62541-3. The Services such as those used to invoke the Methods used to manage
Programs are specified in IEC 62541-4.
An example for a DomainDownload Program is defined in Annex A.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies.
For undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC 62541-1, OPC Unified Architecture - Part 1: Overview and Concepts
IEC 62541-3, OPC Unified Architecture - Part 3: Address Space Model
IEC 62541-4, OPC Unified Architecture - Part 4: Services
IEC 62541-5, OPC Unified Architecture - Part 5: Information Model
IEC 62541-16, OPC Unified Architecture - Part 16: State Machines
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 62541-1,
IEC 62541-3, IEC 62541-16 and the following 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
Function
programmatic task performed by a Server or device, usually accomplished by computer code
execution
3.1.2
Finite State Machine
sequence of states and valid state transitions along with the causes and effects of those state
transitions that define the actions of a Program in terms of discrete stages
3.1.3
ProgramStateMachineType
type definition of a Program and is a subtype of the FiniteStateMachineType
IEC 62541-10:2025 © IEC 2025
3.1.4
Program Control Method
Method having specific semantics designed for the control of a Program by causing a state
transition
3.1.5
Program Invocation
unique Object instance of a Program existing on a Server
Note 1 to entry: A Program Invocation is distinguished from other Object instances of the same
ProgramStateMachineType by the object node's unique browse path.
3.2 Abbreviated terms
DA data access
FSM finite state machine
HMI human machine interfaces
UA unified architecture
4 Concepts
4.1 General
Integrated automation facilities manage their operations through the exchange of data and the
coordinated invocation of system Functions as illustrated in Figure 1. Services are required to
perform the data exchanges and to invoke the Functions that constitute system operation.
These Functions can be invoked through Human Machine Interfaces, cell controllers, or other
supervisory control and data acquisition type systems. OPC UA defines Methods and Programs
as an interoperable way to advertise, discover, and request these Functions. They provide a
normalizing mechanism for the semantic description, invocation, and result reporting of these
Functions. Together Methods and Programs complement the other OPC UA Services and
ObjectTypes to facilitate the operation of an automation environment using a client-server
hierarchy.
Figure 1 – Automation facility control
IEC 62541-10:2025 © IEC 2025
Methods and Programs model Functions typically have different scopes, behaviours, lifetimes,
and complexities in OPC Servers and the underlying systems. These Functions are not normally
characterized by the reading or writing of data which is accomplished with the OPC UA Attribute
service set.
Methods represent basic Functions in the Server that can be invoked by a Client. Programs, by
contrast, model more complex and stateful functionality in the system. For example, a method
call can be used to perform a calculation or reset a counter. A Program is used to run and
control a batch process, execute a machine tool part program, or manage a domain download.
Methods and their invocation mechanism are described in IEC 62541-3 and IEC 62541-4.
This document describes the extensions to, or specific use of, the core capabilities defined in
IEC 62541-5 and IEC 62541-16 as required for Programs.
4.2 Programs
4.2.1 Overview
Programs are complex Functions in a Server or underlying system that can be invoked and
managed by a Client. Programs can represent any level of functionality within a system or
process in which Client control or intervention is required and progress monitoring is desired.
Figure 2 illustrates the model.

Figure 2 – Program illustration
Programs are stateful and transition through a prescribed sequence of states as they execute.
Their behaviour is defined by a Program Finite State Machine (PFSM). The elements of the
PFSM describe the phases of a Program's execution in terms of valid transitions between a set
of states, the stimuli or causes of those transitions, and the resultant effects of the transitions.
IEC 62541-10:2025 © IEC 2025
4.2.2 Security considerations
Since Programs can be used to perform advanced control algorithms or other actions, their use
should be restricted to personnel with appropriate access rights. It is recommended that
AuditUpdateMethodEvents are generated to allow monitoring the number of running Programs
in addition to their execution frequency.
4.2.3 Program Finite State Machine
The states, transitions, causes and effects that compose the Program Finite State Machine are
listed in Table 1 and illustrated in Figure 3.
Table 1 – Program Finite State Machine
No. Transition name Cause From state To state Effect
Report Transition 1
HaltedToReady Reset Method Halted Ready
Event/Result
Report Transition 2
ReadyToRunning Start Method Ready Running
Event/Result
Report Transition 3
Halt Method or Internal
RunningToHalted Running Halted
Event/Result
(Error)
Report Transition 4
RunningToReady Internal Running Ready
Event/Result
Report Transition 5
RunningToSuspended Suspend Method Running Suspended
Event/Result
Report Transition 6
SuspendedToRunning Resume Method Suspended Running
Event/Result
Report Transition 7
SuspendedToHalted Halt Method Suspended Halted
Event/Result
Report Transition 8
SuspendedToReady Internal Suspended Ready
Event/Result
Report Transition 9
ReadyToHalted Halt Method Ready Halted
Event/Result
Figure 3 – Program states and transitions
IEC 62541-10:2025 © IEC 2025
4.2.4 Program states
A standard set of base states is defined for Programs as part of the Program Finite State
Machine. These states represent the stages in which a Program can exist at an instant in time
as viewed by a Client. This state is the Program's current state. All Programs shall support this
base set. A Program can require a Client action to cause the state to change. The states are
formally defined in Table 2.
Table 2 – Program states
State Description
Ready The Program is properly initialized and can be started.
Running The Program is executing making progress towards completion.
Suspended The Program has been stopped prior to reaching a terminal state but can be resumed.
Halted The Program is in a terminal or failed state, and it cannot be started or resumed without being
reset.
The set of states defined to describe a Program can be expanded. Program substates can be
defined for the base states to provide more resolution of a process and to describe the cause
and effect(s) of additional stimuli and transitions. Standards bodies and industry groups can
extend the base Program Finite State Model to conform to various industry models. For
example, the Halted state can include the substates "Aborted" and "Completed" to indicate if
the Function achieved a successful conclusion prior to the transition to Halted. Transitional
states such as "Starting" or "Suspending" can also be extensions of the Running state, for
example.
4.2.5 State transitions
A standard set of state transitions is defined for the Program Finite State Machine. These
transitions define the valid changes to the Program's current state in terms of an initial state
and a resultant state. The transitions are formally defined in Table 3.
Table 3 – Program state transitions
Transition no. Transition name Initial state Resultant state
1 HaltedToReady Halted Ready
2 ReadyToRunning Ready Running
3 RunningToHalted Running Halted
4 RunningToReady Running Ready
5 RunningToSuspended Running Suspended
6 SuspendedToRunning Suspended Running
7 SuspendedToHalted Suspended Halted
8 SuspendedToReady Suspended Ready
9 ReadyToHalted Ready Halted
4.2.6 Program state transition stimuli
The stimuli or causes for a Program's state transitions can be internal to the Server or external.
The completion of machining steps, the detection of an alarm condition, or the transmission of
a data packet are examples of internal stimuli. Methods are an example of external stimuli.
Standard Methods are defined which act as stimuli for the control of a Program.
IEC 62541-10:2025 © IEC 2025
4.2.7 Program Control Methods
Clients manage a Program by calling Methods. The Methods impact a Program's behaviour by
causing specified state transitions. The state transitions dictate the actions performed by the
Program. This standard defines a set of standard Program Control Methods. These Methods
provide sufficient means for a Client to run a Program.
Table 4 lists the set of defined Program Control Methods. Each Method causes transitions from
specified states and shall be called when the Program is in one of those states.
Individual Programs can optionally support any subset of the Program Control Methods. For
example, if suspension is not useful for a Program, the Suspend and Resume Methods are not
provided.
Programs can support additional user defined Methods. User defined Methods shall not change
the behaviour of the base Program Finite State Machine.
Table 4 – Program Control Methods
Method Name Description
Start Causes the Program to transition from the Ready state to the Running state.
Suspend Causes the Program to transition from the Running state to the Suspended state.
Resume Causes the Program to transition from the Suspended state to the Running state.
Halt Causes the Program to transition from the Ready, Running or Suspended state to the Halted
state.
Reset Causes the Program to transition from the Halted state to the Ready state.

All Program Control Methods are defined with their BrowseName on the
ProgramStateMachineType with the OptionalPlaceholder ModellingRule. As defined in
IEC 62541-3, this rule allows the inclusion of Arguments to these Methods on sub-types or on
instances. For example, a Start Method can include an options argument that specifies dynamic
options used to determine some program behaviour. The Method Call service specified in
IEC 62541-4 defines a return status. This return status indicates the success of the Program
Control Method or a reason for its failure.
4.2.8 Program state transition effects
A Program's state transition generally has a cause and also yields an effect. The effect is a
byproduct of a Program state transition that can be used by a Client to monitor the progress of
the Program. Effects can be internal or external. An external effect of a state transition is the
generation of an Event notification. Each Program state transition is associated with a unique
Event. These Events reflect the progression and trajectory of the Program through its set of
defined states. The internal effects of a state transition can be the performance of some
programmatic action such as the generation of data.
4.2.9 Program result data
4.2.9.1 Overview
Result data is generated by a running Program. The result data can be intermediate or final.
Result data can be associated with specific Program state transitions.
4.2.9.2 Intermediate result data
Intermediate result data is transient and is generated by the Program in conjunction with non-
terminal state transitions. The data items that compose the intermediate results are defined in
IEC 62541-10:2025 © IEC 2025
association with specific Program state transitions. Their values are relevant only at the
transition level.
Each Program state transition can be associated with different result data items. Alternately, a
set of transitions can share a result data item. Percentage complete is an example of
intermediate result data. The value of percentage complete is produced when the state
transition occurs and is available to the Client.
Clients acquire intermediate result data by subscribing to Program state transition Events. The
Events specify the data items for each transition. When the transition occurs, the generated
Event conveys the result data values captured to the subscribed Clients. If no Client is
monitoring the Program, intermediate result data can be discarded.
4.2.9.3 Terminal result data
Terminal result data is the final data generated by the Program as it ceases execution. Total
execution time, number of widgets produced, and fault condition encountered are examples of
terminal result data. When the Program enters the terminal state, this result data can be
conveyed to the Client by the transition Event. Terminal result data is also available within the
Program that is read by a Client after the program stops. This data persists until the Program
Instance is rerun or deleted.
4.2.9.4 Monitoring Programs
Clients can monitor the activities associated with a Program's execution. These activities
include the invocation of the management Methods, the generation of result data, and the
progression of the Program through its states. Audit Events are provided for Method Calls and
state transitions. These Events allow a record to be maintained of the Clients that interacted
with any Program and the Program state transitions that resulted from that interaction.
4.2.10 Program lifetime
4.2.10.1 Overview
Programs can have different lifetimes. Some Programs are always present on a Server while
others are created and removed. Creation and removal can be controlled by a Client or can be
restricted to local means.
A Program can be Client creatable. If a Program is Client creatable, then the Client can add the
Program to the Server. The Object Create Method defined in IEC 62541-3, is used to create the
Program instance. The initial state of the Program can be Halted or Ready. Some Programs,
for example, can require that a resource becomes available after its creation and before it is
ready to run. In this case, it would be initialized in the Halted state and transition to Ready when
the resource is delivered.
A Program can be Client removable. If the Program is Client removable, then the Client can
delete the Program instance from the Server. The DeleteNodes Service defined in
IEC 62541-4 is used to remove the Program Instance. The Program shall be in a Halted state
to be removed. A Program can also be auto removable. An auto removable Program deletes
itself when execution has terminated.
4.2.10.2 Program instances
Programs can be multiple instanced or single instanced. A Server can support multiple
instances of a Program if these Program Instances can be run in parallel. For example, the
Program can define a Start Method that has an input argument to specify which resource is
acted upon by its Functions. Each instance of the Program is then started designating use of
different resources. The Client can discover all instances of a Program that are running on a
Server. Each instance of a Program is uniquely identified on the Server and is managed
independently by the Client.
IEC 62541-10:2025 © IEC 2025
4.2.10.3 Program recycling
Programs can be run once or run multiple times (recycled). A Program that is run once will
remain in the Halted state indefinitely once it has run. The normal course of action would be to
delete it following the inspection of its terminal results.
Recyclable Programs can have a limited or unlimited cycle count. These Programs can require
a reset step to transition from the Halted state to the Ready state. This allows for replenishing
resources or reinitializing parameters prior to restarting the Program. The Program Control
Method "Reset" triggers this state transition and any associated actions or effects.
5 Model
5.1 General
The Program model extends the FiniteStateMachineType and basic ObjectType models
presented in IEC 62541-16. Each Program has a Type Definition that is the subtype of the
FiniteStateMachineType. The ProgramStateMachineType describes the Finite State Machine
model supported by any Program Invocation of that type. The ProgramStateMachineType also
defines the property set that characterizes specific aspects of that Program's behaviour such
as lifetime and recycling as well as specifying the result data that is produced by the Program.

Figure 4 – Program Type
The base ProgramStateMachineType defines the standard Finite State Machine specified for
all Programs. This includes the states, transitions, and transition causes (Methods) and effects
(Events). Subtypes of the base ProgramStateMachineType can be defined to extend or more
specifically characterize the behaviour of an individual Program as illustrated with
"MyProgramType" in Figure 4.
IEC 62541-10:2025 © IEC 2025
5.2 ProgramStateMachineType
5.2.1 Overview
The additional properties and components that compose the ProgramStateMachineType are
listed in Table 5. No ProgramStateMachineType specific semantics are assigned to the other
base ObjectType or FiniteStateMachineType Attributes or Properties.
Table 5 – ProgramStateMachineType
Attribute Value
Includes all attributes specified for the FiniteStateMachineType
BrowseName ProgramStateMachineType
IsAbstract False
References NodeClass BrowseName Data Type TypeDefinition Other
HasProperty Variable Creatable Boolean PropertyType
HasProperty Variable Deletable Boolean PropertyType M
HasProperty Variable AutoDelete Boolean PropertyType M
HasProperty Variable RecycleCount Int32 PropertyType M
HasProperty Variable InstanceCount UInt32 PropertyType
HasProperty Variable MaxInstanceCount UInt32 PropertyType
HasProperty Variable MaxRecycleCount UInt32 PropertyType

HasComponent Variable ProgramDiagnostic ProgramDiagnostic2 ProgramDiagnostic2 O
DataType Type
HasComponent Object Halted StateType
HasComponent Object Ready StateType
HasComponent Object Running StateType
HasComponent Object Suspended StateType

HasComponent Object HaltedToReady TransitionType
HasComponent Object ReadyToRunning TransitionType
HasComponent Object RunningToHalted TransitionType
HasComponent Object RunningToReady TransitionType
HasComponent Object RunningToSuspended TransitionType
HasComponent Object SuspendedToRunning TransitionType
HasComponent Object SuspendedToHalted TransitionType
HasComponent Object SuspendedToReady TransitionType
HasComponent Object ReadyToHalted TransitionType

HasComponent Method Start  OP
HasComponent Method Suspend  OP
HasComponent Method Reset  OP
HasComponent Method Halt  OP
HasComponent Method Resume  OP

HasComponent Object FinalResultData BaseObjectType O
Conformance Units
Program Basic
IEC 62541-10:2025 © IEC 2025
The component Variables of the ProgramStateMachineType have additional Attributes defined
in Table 6.
Table 6 – ProgramStateMachineType Attribute values for child Nodes
BrowsePath Value Attribute
Halted 11
StateNumber
Ready 12
StateNumber
Running 13
StateNumber
Suspended 14
StateNumber
HaltedToReady 1
TransitionNumber
ReadyToRunning 2
TransitionNumber
RunningToHalted 3
TransitionNumber
RunningToReady 4
TransitionNumber
RunningToSuspended 5
TransitionNumber
SuspendedToRunning 6
TransitionNumber
SuspendedToHalted 7
TransitionNumber
SuspendedToReady 8
TransitionNumber
ReadyToHalted 9
TransitionNumber
5.2.2 ProgramStateMachineType Properties
The Creatable Property is a boolean that specifies if Program Invocations of this
ProgramStateMachineType can be created by a Client. If False, these Program Invocations are
persistent or can only be created by the Server.
The Deletable Property is a boolean that specifies if a Program Invocation of this
ProgramStateMachineType can be deleted by a Client. If False, these Program Invocations can
only be deleted by the Server.
The AutoDelete Property is a boolean that specifies if Program Invocations of this
ProgramStateMachineType are removed by the Server when execution terminates. If False,
these Program Invocations persist on the Server until they are deleted by the Client. When the
Program Invocation is deleted, any result data associated with the instance is also removed.
IEC 62541-10:2025 © IEC 2025
The RecycleCount Property is an unsigned integer that specifies the number of times a Program
Invocation of this type has been recycled or restarted from its starting point (not resumed). Note
that the Reset Method can be required to pr
...