IEC 62541-10:2025
(Main)OPC Unified Architecture - Part 10: Programs
OPC Unified Architecture - Part 10: Programs
IEC 62541-10:2025 is available as IEC 62541-10:2025 RLV which contains the International Standard and its Redline version, showing all changes of the technical content compared to the previous edition.IEC 62541-10:2025 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. 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:
- StateMachine table format has been aligned.
Architecture unifiée OPC - Partie 10: Programmes
IEC 62541-10:2025 est disponible sous forme de IEC 62541-10:2025 RLV qui contient la Norme internationale et sa version Redline, illustrant les modifications du contenu technique depuis l'édition précédente.L'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é.
General Information
Relations
Standards Content (Sample)
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
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
publications previews, graphical symbols and the glossary.
The advanced search enables to find IEC publications by a
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 . 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
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
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.
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.
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
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
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.
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
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.
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
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.
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.
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
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.
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 prepare a Program to be restarted.
The MaxRecycleCount Property is an integer that specifies the maximum number of times a
Program Invocation of this type can be recycled or restarted from its starting point (not
resumed). If the value is less than 0, then there is no limit to the number of restarts. If the value
is zero, then the Program cannot be recycled or restarted.
The InstanceCount Property is an unsigned integer that specifies the number of Program
Invocations of this type that currently exist.
The MaxInstanceCount Property is an integer that specifies the maximum number of Program
Invocations of this type that can exist simultaneously on this Server. If the value is less than 0,
then there is no limit.
5.2.3 ProgramStateMachineType components
5.2.3.1 Overview
The ProgramStateMachineType components consist of a set of References to the Object
instances of StateTypes, TransitionTypes, EventTypes and the Methods that collectively define
the Program FiniteStateMachine.
Figure 5 – Program FSM References
Figure 5 illustrates the component References that define the associations between two of the
ProgramStateMachineType's states, Ready and Running. The complementary ReferenceTypes
have been omitted to simplify the illustration.
5.2.3.2 ProgramStateMachineType states
The state Objects are instances of the StateType defined in IEC 62541-16. Each state is
assigned a unique StateNumber value defined in Table 6. Subtypes of the
ProgramStateMachineType can add references from any state to a subordinate or nested
StateMachine Object to extend the FiniteStateMachine.
The Halted state is the idle state for a Program. It can be an initial state or a terminal state. As
an initial state, the Program Invocation cannot begin execution due to conditions at the Server.
As a terminal state, Halted can indicate either a failed or completed Program. A subordinate
state or result can be used to distinguish the nature of the termination. The Halted state
references four Transition Objects, which identify the allowed state transitions to the Ready
state and from the Ready, Running, and Suspended states.
The Ready state indicates that the Program is prepared to begin execution. Programs that are
ready to begin upon their creation can transition immediately to the Ready state. The Ready
state references four Transition Objects, which identify the allowed state transitions to the
Running and Halted states and from the Halted and Ready states.
The Running state indicates that the Program is actively performing its Function. The Running
state references five Transition Objects, which identify the allowed state transitions to the
Halted, Ready, and Suspended states and from the Ready and Suspended states.
The Suspended state indicates that the Program has stopped performing its Function but retains
the ability to resume the Function at the point at which it was executing when suspended. The
Suspended state references four Transition Objects, which identify the allowed state transitions
to the Ready, Running, and Halted state and from the Ready state.
5.2.3.3 ProgramStateMachineType transitions
ProgramStateMachineType Transitions are instances of the TransitionType defined in
IEC 62541-16 which also includes the definitions of the ToState, FromState, HasCause, and
HasEffect references used. Table 7 specifies the transitions defined for the
ProgramStateMachineType. Each transition is assigned a unique TransitionNumber defined in
Table 6.
Table 7 – ProgramStateMachineType Additional References
SourceBrowsePath
...
IEC 62541-10 ®
Edition 4.0 2025-12
NORME
INTERNATIONALE
Architecture unifiée OPC -
Partie 10: Programmes
ICS 25.040.40; 35.100.05 ISBN 978-2-8327-0876-7
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
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.
SOMMAIRE
AVANT-PROPOS . 3
1 Domaine d'application . 5
2 Références normatives . 5
3 Termes, définitions et termes abrégés . 5
3.1 Termes et définitions . 5
3.2 Abréviations . 6
4 Concepts . 6
4.1 Généralités . 6
4.2 Programmes . 7
4.2.1 Vue d'ensemble . 7
4.2.2 Considérations relatives à la sécurité . 8
4.2.3 Diagramme d'états finis de programme . 8
4.2.4 États de Programme . 10
4.2.5 Transitions d'états . 10
4.2.6 Stimuli de transition d'états de Programme . 11
4.2.7 Méthodes de Commande de Programme . 11
4.2.8 Effets des transitions d'états de Programme . 11
4.2.9 Données de résultat de Programme . 12
4.2.10 Durée de vie d'un Programme . 12
5 Modèle . 13
5.1 Généralités . 13
5.2 ProgramStateMachineType . 14
5.2.1 Vue d'ensemble . 14
5.2.2 Propriétés ProgramStateMachineType . 16
5.2.3 Composants de ProgramStateMachineType . 17
5.2.4 Causes de ProgramStateMachineType (Méthodes) . 21
5.2.5 Effets de ProgramStateMachineType (Événements) . 22
5.2.6 AuditProgramTransitionEventType. 23
5.2.7 FinalResultData . 24
5.2.8 DataType ProgramDiagnostic2 . 24
5.2.9 VariableType ProgramDiagnostic2Type . 25
Annexe A (informative) Exemple de Programme . 26
A.1 Vue d'ensemble . 26
A.2 Programme DomainDownload . 26
A.2.1 Généralités . 26
A.2.2 États de DomainDownload . 27
A.2.3 Transitions de DomainDownload . 28
A.2.4 Méthodes de DomainDownload . 29
A.2.5 Événements de DomainDownload . 29
A.2.6 Modèle de DomainDownload . 30
Figure 1 – Commande d'installation d'automatisation . 7
Figure 2 – Représentation d'un Programme . 8
Figure 3 – États de Programme et transitions . 9
Figure 4 – Type de Programme . 14
Figure 5 – Références FSM de Programme . 17
Figure 6 – Causes et effets de ProgramStateMachineType . 20
Figure A.1 – Exemple de Programme . 26
Figure A.2 – Diagramme d'états de DomainDownload . 27
Figure A.3 – Modèle d'états partiel de DomainDownloadType . 35
Figure A.4 – Modèle ReadyToRunning . 37
Figure A.5 – Modèle OpeningToSendingToClosing . 39
Figure A.6 – Modèle RunningToSuspended . 40
Figure A.7 – Modèle SuspendedToRunning . 41
Figure A.8 – Modèle RunningToHalted – Aborted . 42
Figure A.9 – Modèle SuspendedToAborted . 43
Figure A.10 – Modèle RunningToCompleted . 44
Figure A.11 – Séquence des opérations . 45
Tableau 1 – Diagramme d'états finis de programme . 9
Tableau 2 – États de Programme . 10
Tableau 3 – Transitions d'états de Programme . 10
Tableau 4 – Méthodes de Commande de Programme . 11
Tableau 5 – ProgramStateMachineType . 15
Tableau 6 – Valeurs d'Attribut ProgramStateMachineType pour les Nœuds enfants . 16
Tableau 7 – Références supplémentaires de ProgramStateMachineType . 18
Tableau 8 – Causes de ProgramStateMachineType . 21
Tableau 9 – ProgramTransitionEventType . 22
Tableau 10 – AuditProgramTransitionEventType . 23
Tableau 11 – Structure de ProgramDiagnostic2DataType . 24
Tableau 12 – Définition de ProgramDiagnostic2DataType . 25
Tableau 13 – VariableType ProgramDiagnostic2Type . 25
Tableau A.1 – États de DomainDownload . 28
Tableau A.2 – DomainDownloadType . 31
Tableau A.3 – TransferStateMachineType . 32
Tableau A.4 – Valeurs d'Attribut TransferStateMachineType pour les Nœuds enfants . 33
Tableau A.5 – Type de Diagramme d'états Finish . 33
Tableau A.6 – Valeurs d'Attribut FinishStateMachineType pour les Nœuds enfants . 34
Tableau A.7 – Valeurs des variables d'Attributs de Propriété du DomainDownloadType . 34
Tableau A.8 – Références supplémentaires de TransferStateMachineType . 36
Tableau A.9 – Ajouts de la Méthode Start . 38
Tableau A.10 – StartArguments. 38
Tableau A.11 – Objet IntermediateResults . 39
Tableau A.12 – Variables de données de résultat intermédiaires . 40
Tableau A.13 – FinalResultData . 43
COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE
____________
Architecture unifiée OPC -
Partie 10: Programmes
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-10 a été établie par le sous-comité 65E: Les appareils 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 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:
a) le format du tableau StateMachine a été aligné.
Le texte de cette Norme internationale est issu des documents suivants:
Projet Rapport de vote
65E/1057/CDV 65E/1094/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 IEC 62541,
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 IEC 62541.
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.
Les termes et noms en italique sont, à quelques exceptions près, é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é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.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu'ils constituent, pour tout ou partie
de leur contenu, des exigences du présent document. Pour les références datées, seule
l'édition citée s'applique. Pour les références non datées, la dernière édition du document de
référence s'applique (y compris les éventuels amendements).
IEC 62541-1, Architecture unifiée OPC - Partie 1: Vue d'ensemble et concepts
IEC 62541-3, Architecture unifiée OPC - Partie 3: Modèle de l'Espace d'Adressage
IEC 62541-4, Architecture unifiée OPC - Partie 4: Services
IEC 62541-5, Architecture unifiée OPC - Partie 5: Modèle d'information
IEC 62541-16, Architecture unifiée OPC - Partie 16: Diagrammes d'états
3 Termes, définitions et termes abrégés
3.1 Termes et définitions
Pour les besoins du présent document, les termes et définitions de l'IEC 62541-1,
l'IEC 62541-3, l'IEC 62541-16 ainsi que les 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
Fonction
tâche de programmation assurée par un Serveur ou un appareil, généralement réalisée par
l'exécution d'un code machine
3.1.2
Diagramme d'états finis
séquence d'états et de transitions d'états valides, associés aux causes et effets de ces
transitions, définissant les actions d'un Programme en ce qui concerne les stades discrets
3.1.3
ProgramStateMachineType
définition de type d'un Programme, qui constitue un sous-type du FiniteStateMachineType
3.1.4
Méthode de Commande de Programme
Méthode à la sémantique particulière conçue pour commander un Programme en déclenchant
une transition d'états
3.1.5
Invocation de Programme
instance d'Objet unique d'un Programme existant sur un Serveur
Note 1 à l'article: L'Invocation de Programme se différencie des autres instances d'Objet du même
ProgramStateMachineType par le chemin de navigation unique du nœud d'objet.
3.2 Abréviations
DA (Data Access) Accès aux données
FSM (Finite State Machine) Diagramme d'états finis
IHM Interfaces Homme-Machine
UA (Unified Architecture) Architecture unifiée
4 Concepts
4.1 Généralités
Les installations d'automatisation intégrée gèrent leurs opérations par des échanges de
données et par l'invocation coordonnée de Fonctions système, comme cela est représenté à la
Figure 1. Il est exigé des Services qu'ils réalisent les échanges de données et qu'ils invoquent
les Fonctions nécessaires à l'exploitation du système. Ces Fonctions peuvent être invoquées
au moyen des interfaces homme-machine, des contrôleurs cellulaires ou d'autres systèmes de
commande de surveillance et d'acquisition de données. L'OPC UA définit les Méthodes et les
Programmes comme des outils d'interopérabilité permettant d'annoncer, de découvrir et
d'interroger ces Fonctions. Ils fournissent un mécanisme de normalisation applicable à la
description sémantique, à l'invocation et à la consignation des résultats de ces Fonctions. Les
Méthodes et les Programmes viennent compléter les autres Services et ObjectTypes OPC UA
afin de faciliter l'exploitation d'un environnement d'automatisation fondé sur une hiérarchie
client-serveur.
Figure 1 – Commande d'installation d'automatisation
Les Fonctions de modélisation des Méthodes et Programmes mises en œuvre dans les
Serveurs OPC et les systèmes sous-jacents présentent généralement des domaines
d'application, des comportements, des durées de vie et des niveaux de complexité différents.
En règle générale, ces Fonctions ne sont pas basées sur des opérations de lecture ou d'écriture
de données réalisées avec le jeu de services d'Attributs OPC UA.
Les Méthodes représentent les Fonctions de base du Serveur que le Client peut invoquer. En
revanche, les Programmes permettent de modéliser une fonctionnalité dynamique plus
complexe dans le système. Par exemple, un appel de méthode peut être utilisé pour réaliser
un calcul ou réinitialiser un compteur. Un Programme est utilisé pour exécuter et commander
un traitement par lots, exécuter un programme-pièce de machine-outil ou gérer un
téléchargement de domaine. Les Méthodes et leur mécanisme d'invocation sont décrits dans
l'IEC 62541-3 et l'IEC 62541-4
Le présent document décrit les extensions aux capacités fondamentales définies dans
l'IEC 62541-5 et l'IEC 62541-16, ou leur utilisation particulière, exigées pour les Programmes.
4.2 Programmes
4.2.1 Vue d'ensemble
Les Programmes sont des Fonctions complexes résidant dans un Serveur ou un système sous-
jacent qu'un Client peut invoquer et gérer. Les Programmes peuvent représenter n'importe quel
niveau de fonctionnalité au sein d'un système ou d'un processus pour lequel la commande ou
l'intervention du Client est exigée et dont le contrôle du déroulement est souhaité. Ce modèle
est représenté à la Figure 2.
Figure 2 – Représentation d'un Programme
L'exécution des Programmes dynamiques se déroule par transition selon une séquence d'états
prédéfinie. Le comportement des Programmes est défini par un Diagramme d'états finis de
programme (PFSM, Program Finite State Machine). Les éléments du PFSM décrivent les
phases d'exécution d'un Programme en ce qui concerne les transitions valides entre un
ensemble d'états, les stimuli ou causes de ces transitions et les effets qui résultent de celles-ci.
4.2.2 Considérations relatives à la sécurité
Dans la mesure où les Programmes peuvent être utilisés pour réaliser des algorithmes de
commande avancés ou d'autres actions, il convient de limiter leur utilisation au personnel
disposant des droits d'accès appropriés. Il est recommandé de générer les
AuditUpdateMethodEvents pour permettre la surveillance du nombre de Programmes en cours
d'exécution en plus de leur fréquence d'exécution.
4.2.3 Diagramme d'états finis de programme
Le Tableau 1 répertorie les états, transitions, causes et effets constitutifs du Diagramme d'états
finis de programme qui est représenté à la Figure 3.
Tableau 1 – Diagramme d'états finis de programme
Dénomination de
N° Cause De l'état À l'état Effet
transition
Consigne
l'Événement/le Résultat
HaltedToReady Méthode Reset Halted Ready
de la Transition 1
Consigne
l'Événement/le Résultat
ReadyToRunning Méthode Start Ready Running
de la Transition 2
Consigne
Méthode Halt ou Interne
l'Événement/le Résultat
RunningToHalted Running Halted
(Erreur)
de la Transition 3
Consigne
l'Événement/le Résultat
RunningToReady Interne Running Ready
de la Transition 4
Consigne
l'Événement/le Résultat
RunningToSuspended Méthode Suspend Running Suspended
de la Transition 5
Consigne
l'Événement/le Résultat
SuspendedToRunning Méthode Resume Suspended Running
de la Transition 6
Consigne
l'Événement/le Résultat
SuspendedToHalted Méthode Halt Suspended Halted
de la Transition 7
Consigne
l'Événement/le Résultat
SuspendedToReady Interne Suspended Ready
de la Transition 8
Consigne
l'Événement/le Résultat
ReadyToHalted Méthode Halt Ready Halted
de la Transition 9
Figure 3 – États de Programme et transitions
4.2.4 États de Programme
Un ensemble normalisé d'états de base est défini pour les Programmes, faisant partie
intégrante du Diagramme d'états finis de programme. Ces états représentent les stades
auxquels un Programme peut exister à un moment donné, tel que visualisé par un Client. Cet
état est l'état actuel du Programme. Tous les Programmes doivent prendre en charge cet
ensemble de base. Un Programme peut exiger une action du Client pour voir son état modifié.
Le Tableau 2 définit les états de manière formelle.
Tableau 2 – États de Programme
État Description
Ready Le Programme est correctement initialisé et peut être démarré.
Marche Le Programme est en cours d'exécution jusqu'à son achèvement.
Suspended Le Programme a été interrompu avant d'atteindre un état final, mais peut être repris.
Halted Le Programme est parvenu à un état final ou d'échec; il ne peut pas être démarré ou repris sans
réinitialisation.
L'ensemble des états définis pour décrire un Programme peut être étendu. Les sous-états de
Programme peuvent être définis de sorte que les états de base fournissent une plus grande
résolution d'un processus et décrivent la cause et les effets des stimuli et transitions
supplémentaires. Les organismes de normalisation et les groupes industriels peuvent étendre
le Modèle d'états finis de Programme de base pour se conformer aux différents modèles
industriels. Par exemple, l'état Halted peut comprendre les sous-états "Aborted" et "Completed"
permettant d'indiquer si la Fonction a été achevée de manière satisfaisante avant de passer à
la transition vers l'état Halted. Les états de transition tels que "Starting" ou "Suspending"
peuvent également être des extensions de l'état Running, par exemple.
4.2.5 Transitions d'états
Un ensemble normalisé de transitions d'états est défini pour le Diagramme d'états finis de
programme. Ces transitions définissent les modifications valides apportées à l'état actuel du
Programme, par rapport à l'état initial et à l'état résultant. Le Tableau 3 définit les transitions
de manière formelle.
Tableau 3 – Transitions d'états de Programme
N° de transition Dénomination de transition État initial État résultant
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 Stimuli de transition d'états de Programme
Les stimuli ou les causes de transitions d'états d'un Programme peuvent être internes ou
externes au Serveur. Les stimuli internes sont par exemple l'achèvement des étapes d'usinage,
la détection d'une condition d'alarme ou la transmission d'un paquet de données. Les stimuli
externes sont par exemple les Méthodes. Des Méthodes normalisées sont définies; elles
agissent comme des stimuli pour commander un Programme.
4.2.7 Méthodes de Commande de Programme
Les Clients gèrent un Programme en appelant des Méthodes. Les Méthodes agissent sur le
comportement d'un Programme en provoquant des transitions d'états spécifiées. Les transitions
d'états régissent les actions réalisées par le Programme. La présente norme définit un
ensemble de Méthodes de Commande de Programme normalisées. Ces Méthodes fournissent
les moyens suffisants au Client pour exécuter un Programme.
Le Tableau 4 répertorie l'ensemble des Méthodes de Commande de Programme définies.
Chaque Méthode provoque des transitions à partir d'états spécifiés et doit être appelée lorsque
le Programme est parvenu à l'un de ces états.
Des Programmes individuels peuvent en option prendre en charge n'importe quel sous-
ensemble des Méthodes de Commande de Programme. Par exemple, si un état d'interruption
n'est pas utile pour un Programme, les Méthodes Suspend et Resume ne sont pas proposées.
Les Programmes peuvent prendre en charge des Méthodes supplémentaires définies par
l'utilisateur. Les Méthodes définies par l'utilisateur ne doivent pas modifier le comportement du
Diagramme d'états finis de programme de base.
Tableau 4 – Méthodes de Commande de Programme
Dénomination Description
de méthode
Démarrage Fait passer le Programme de l'état Ready à l'état Running.
Suspension Fait passer le Programme de l'état Running à l'état Suspended.
Reprise Fait passer le Programme de l'état Suspended à l'état Running.
Halt Fait passer le Programme de l'état Ready, Running ou Suspended à l'état Halted.
Réinitialisation Fait passer le Programme de l'état Halted à l'état Ready.
Toutes les Méthodes de Commande de Programme sont définies par leur BrowseName dans
le ProgramStateMachineType, selon la ModellingRule OptionalPlaceholder. Comme cela est
précisé dans l'IEC 62541-3, cette règle permet l'ajout d'Arguments à ces Méthodes pour les
sous-types et instances. Par exemple, une Méthode Start peut inclure un argument d'options
qui spécifie des options dynamiques utilisées pour déterminer un comportement donné du
programme. Le service d'Appel de Méthode spécifié dans l'IEC 62541-4 définit un statut de
retour. Ce statut de retour indique la réussite de la Méthode de Commande de Programme ou
la raison de son échec.
4.2.8 Effets des transitions d'états de Programme
La transition d'états d'un Programme a généralement une cause et produit également un effet.
L'effet est un sous-produit de la transition d'états d'un Programme, qu'un Client peut utiliser
pour surveiller l'avancement du Programme. Les effets peuvent être internes ou externes. Un
effet externe d'une transition d'états est caractérisé par la génération d'une notification
d'Événement. Chaque transition d'états de Programme est associée à un Événement unique.
Ces Événements reflètent la progression et la trajectoire du Programme dans son ensemble
d'états définis. Les effets internes d'une transition d'états peuvent se caractériser par la
réalisation d'une action de programmation donnée telle que la génération de données.
4.2.9 Données de résultat de Programme
4.2.9.1 Vue d'ensemble
Les données de résultat sont générées par un Programme en cours d'exécution. Les données
de résultat peuvent être intermédiaires ou finales. Les données de résultat peuvent être
associées à des transitions d'états de Programme spécifiques.
4.2.9.2 Données de résultat intermédiaires
Les données de résultat intermédiaires sont transitoires et sont générées par le Programme
conjointement avec les transitions d'états non finales. Les éléments de données constitutifs des
résultats intermédiaires sont définis en association avec les transitions d'états de Programme
spécifiques. Leurs valeurs ne sont significatives qu'au niveau de la transition.
Chaque transition d'états de Programme peut être associée à différents éléments de données
de résultat. À l'inverse, un ensemble de transitions peut partager un élément de données de
résultat. Le pourcentage d'achèvement est un exemple de données de résultat intermédiaires.
La valeur du pourcentage d'achèvement est obtenue lorsque la transition d'états se produit et
est disponible pour le Client.
Les Clients acquièrent les données de résultat intermédiaires en s'abonnant aux Événements
de transition d'états de Programme. Les Événements spécifient les éléments de données pour
chaque transition. Lorsque la transition se produit, l'Événement généré transmet les valeurs de
données de résultat obtenues aux Clients abonnés. Si aucun Client ne surveille le Programme,
les données de résultat intermédiaires peuvent être éliminées.
4.2.9.3 Données de résultat finales
Les données de résultat finales sont générées à la fin de l'exécution du Programme. Le temps
d'exécution total, le nombre de widgets produits et la condition de défaut rencontrée sont des
exemples de données de résultat finales. Lorsque le Programme passe à l'état final, ces
données de résultat peuvent être transmises au Client par l'Événement de transition. Les
données de résultat finales sont également disponibles dans le Programme pour être lues par
un Client après l'arrêt du programme. Ces données sont conservées jusqu'à une nouvelle
exécution ou jusqu'à la suppression de l'Instance du Programme.
4.2.9.4 Surveillance des Programmes
Les Clients peuvent surveiller les activités associées à l'exécution d'un Programme. Ces
activités comprennent l'invocation des Méthodes de gestion, la génération de données de
résultat et la progression du Programme dans ses états. Les Événements d'audit sont fournis
par les Appels de Méthode et les transitions d'états. Ces Événements permettent de conserver
l'enregistrement des Clients qui interagissent avec un Programme et les transitions d'états du
Programme résultants de cette interaction.
4.2.10 Durée de vie d'un Programme
4.2.10.1 Vue d'ensemble
Les Programmes peuvent avoir différentes durées de vie. Certains Programmes résident de
manière permanente sur un Serveur, tandis que d'autres sont créés et retirés. La création et le
retrait peuvent être commandés par un Client ou peuvent être limités à des moyens locaux.
Un Programme peut pouvoir être créé par le Client. Dans ce cas, le Client peut ajouter le
Programme au Serveur. La Méthode de Création d'Objet définie dans l'IEC 62541-3 permet de
créer l'instance du Programme. L'état initial du Programme peut être Halted ou Ready. Certains
Programmes, par exemple, peuvent exiger la mise à disposition d'une ressource après leur
création, avant d'être prêts pour l'exécution. Dans ce cas, le Programme est initialisé à l'état
Halted pour ensuite passer à l'état Ready lorsque la ressource est fournie.
Un Programme peut pouvoir être retiré par le Client. Dans ce cas, le Client peut supprimer
l'instance du Programme du Serveur. Le Service DeleteNodes défini dans
l'IEC 62541-4 permet de retirer l'Instance du Programme. Le Programme doit être à l'état Halted
pour être retiré. Un Programme peut également pouvoir être retiré automatiquement. Dans ce
cas, le Programme se supprime lui-même à la fin de son exécution.
4.2.10.2 Instances d'un Programme
Les Programmes peuvent avoir une ou plusieurs instances. Un Serveur peut prendre en charge
plusieurs instances d'un Programme si elles peuvent être exécutées en parallèle. Par exemple,
le Programme peut définir une Méthode Start présentant un argument d'entrée destiné à
spécifier la ressource qui est utilisée par ses Fonctions. Chaque instance du Programme est
ensuite démarrée en désignant l'utilisation des différentes ressources. Le Client peut découvrir
toutes les instances d'un Programme en cours d'exécution sur un Serveur. Chaque instance
d'un Programme est identifiée de manière unique sur le Serveur et est gérée de manière
indépendante par le Client.
4.2.10.3 Recyclage d'un Programme
Les Programmes peuvent être exécutés une ou plusieurs fois (recyclés). Un Programme
exécuté une fois reste indéfiniment à l'état Halted après son exécution. La procédure normale
consiste à le supprimer après examen de ses résultats finaux.
Les Programmes recyclables peuvent comporter un nombre de cycles limité ou illimité. Ces
Programmes peuvent exiger une étape de réinitialisation pour passer de l'état Halted à l'état
Ready. Cela permet de reconstituer les ressources ou de réinitialiser les paramètres avant de
redémarrer le Programme. La Méthode de Commande de Programme "Reset" déclenche cette
transition d'états et toute action ou tout effet associé.
5 Modèle
5.1 Généralités
Le modèle de Programme étend le modèle FiniteStateMachineType et le modèle de base
ObjectType décrits dans l'IEC 62541-16. Chaque Programme comporte une Définition de Type
qui constitue le sous-type du FiniteStateMachineType. Le ProgramStateMachineType décrit le
modèle de Diagramme d'états finis pris en charge par toute Invocation de Programme du type
en question. Le ProgramStateMachineType définit également le jeu de propriétés qui
caractérise les aspects particuliers du comportement du Programme, tels que la durée de vie
et le recyclage, ainsi que les données de résultat générées par le Programme.
Figure 4 – Type de Programme
Le ProgramStateMachineType de base définit le Diagramme d'états finis normalisé spécifié
pour tous les Programmes. Cela comprend les états, les transitions et les causes (Méthodes)
et les effets (Événements) des transitions. Les sous-types du ProgramStateMachineType de
base peuvent être définis pour étendre ou caractériser de manière plus spécifique le
comportement d'un Programme particulier, comme cela est représenté par "MyProgramType"
à la Figure 4.
5.2 ProgramStateMachineType
5.2.1 Vue d'ensemble
Le Tableau 5 répertorie les propriétés et composants supplémentaires qui constituent le
ProgramStateMachineType. Aucune sémantique spécifique au ProgramStateMachineType
n'est attribuée aux autres ObjectTypes de base, Attributs FiniteStateMachineType ou
Propriétés.
Tableau 5 – ProgramStateMachineType
Attribut Valeur
Comprend tous les attributs spécifiés pour le FiniteStateMachineType
BrowseName ProgramStateMachineType
IsAbstract False
Références NodeClass BrowseName Type de données TypeDefinition Autre
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 Objet Halted StateType
HasComponent Objet Ready StateType
HasComponent Objet Running StateType
HasComponent Objet Suspended StateType
HasComponent Objet HaltedToReady TransitionType
HasComponent Objet ReadyToRunning TransitionType
HasComponent Objet RunningToHalted TransitionType
HasComponent Objet RunningToReady TransitionType
HasComponent Objet RunningToSuspende TransitionType
d
HasComponent Objet SuspendedToRunnin TransitionType
g
HasComponent Objet SuspendedToHalted TransitionType
HasComponent Objet SuspendedToReady TransitionType
HasComponent Objet ReadyToHalted TransitionType
HasComponent Méthode Start OP
HasComponent Méthode Suspend OP
HasComponent Méthode Reset OP
HasComponent Méthode Halt OP
HasComponent Méthode Resume OP
HasComponent Objet FinalResultData BaseObjectType O
Unités de Conformité
Programme de base
Le composant Variables du ProgramStateMachineType comporte des Attributs supplémentaires
définis dans le Tableau 6.
Tableau 6 – Valeurs d'Attribut ProgramStateMachineType pour les Nœuds enfants
BrowsePath Valeur d'Attribut
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 Propriétés ProgramStateMachineType
La Propriété Creatable est un booléen qui indique si les Invocations de Programme de ce
ProgramStateMachineType peuvent être créées par un Client. Si la valeur est False, ces
Invocations de Programme sont persistantes ou peuvent uniquement être créées par le
Serveur.
La Propriété Deletable est un booléen qui indique si une Invocation de Programme de ce
ProgramStateMachineType peut être supprimée par un Client. Si la valeur est False, ces
Invocations de Programme peuvent uniquement être supprimées par le Serveur.
La Propriété AutoDelete est un booléen qui indique si les Invocations de Programme de ce
ProgramStateMachineType sont retirées par le Serveur à la fin de l'exécution. Si la valeur est
...
IEC 62541-10 ®
Edition 4.0 2025-12
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
OPC unified architecture -
Part 10: Programs
Architecture unifiée OPC -
Partie 10: Programmes
ICS 25.040.40, 35.100.05 ISBN 978-2-8327-0876-7
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.
Also known as the International Electrotechnical Vocabulary
once a month by email.
(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 . 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
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
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.
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.
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
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
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.
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
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.
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
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.
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.
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
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.
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 prepare a Program to be restarted.
The MaxRecycleCount Property is an integer that specifies the maximum number of times a
Program Invocation of this type can be recycled or restarted from its starting point (not
resumed). If the value is less than 0, then there is no limit to the number of restarts. If the value
is zero, then the Program cannot be recycled or restarted.
The InstanceCount Property is an unsigned integer that specifies the number of Program
Invocations of this type that currently exist.
The MaxInstanceCount Property is an integer that specifies the maximum number of Program
Invocations of this type that can exist simultaneously on this Server. If the value is less than 0,
then there is no limit.
5.2.3 ProgramStateMachineType components
5.2.3.1 Overview
The ProgramStateMachineType components consist of a set of References to the Object
instances of StateTypes, TransitionTypes, EventTypes and the Methods that collectively define
the Program FiniteStateMachine.
Figure 5 – Program FSM References
Figure 5 illustrates the component References that define the associations between two of the
ProgramStateMachineType's states, Re
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.