IEC 62541-10:2012

IEC 62541-10 ®
Edition 1.0 2012-07
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
OPC unified architecture –
Part 10: Programs
Architecture unifiée OPC –
Partie 10: Programmes
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 la CEI ou du Comité national de la CEI du pays du demandeur.
Si vous avez des questions sur le copyright de la CEI 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 la CEI de votre pays de résidence.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
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 corrigenda or an amendment might have been published.

Useful links:
IEC publications search - www.iec.ch/searchpub Electropedia - www.electropedia.org
The advanced search enables you to find IEC publications The world's leading online dictionary of electronic and
by a variety of criteria (reference number, text, technical electrical terms containing more than 30 000 terms and
committee,…). definitions in English and French, with equivalent terms in
It also gives information on projects, replaced and additional languages. Also known as the International
withdrawn publications. Electrotechnical Vocabulary (IEV) on-line.

IEC Just Published - webstore.iec.ch/justpublished Customer Service Centre - webstore.iec.ch/csc
Stay up to date on all new IEC publications. Just Published If you wish to give us your feedback on this publication
details all new publications released. Available on-line and or need further assistance, please contact the
also once a month by email. Customer Service Centre: csc@iec.ch.

A propos de la CEI
La Commission Electrotechnique Internationale (CEI) 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 CEI
Le contenu technique des publications de la CEI est constamment revu. Veuillez vous assurer que vous possédez
l’édition la plus récente, un corrigendum ou amendement peut avoir été publié.

Liens utiles:
Recherche de publications CEI - www.iec.ch/searchpub Electropedia - www.electropedia.org
La recherche avancée vous permet de trouver des Le premier dictionnaire en ligne au monde de termes
publications CEI en utilisant différents critères (numéro de électroniques et électriques. Il contient plus de 30 000
référence, texte, comité d’études,…). termes et définitions en anglais et en français, ainsi que
Elle donne aussi des informations sur les projets et les les termes équivalents dans les langues additionnelles.
publications remplacées ou retirées. Egalement appelé Vocabulaire Electrotechnique
International (VEI) en ligne.
Just Published CEI - webstore.iec.ch/justpublished
Service Clients - webstore.iec.ch/csc
Restez informé sur les nouvelles publications de la CEI.
Just Published détaille les nouvelles publications parues. Si vous désirez nous donner des commentaires sur
Disponible en ligne et aussi une fois par mois par email. cette publication ou si vous avez des questions
contactez-nous: csc@iec.ch.
IEC 62541-10 ®
Edition 1.0 2012-07
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
OPC unified architecture –
Part 10: Programs
Architecture unifiée OPC –
Partie 10: Programmes
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
PRICE CODE
INTERNATIONALE
CODE PRIX X
ICS 25.040.40; 25.100.01 ISBN 978-2-83220-284-5

– 2 – 62541-10 © IEC:2012
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 7
2 Normative references . 7
3 Terms, definitions and abbreviations . 7
3.1 Terms and definitions . 7
3.2 Abbreviations . 8
4 Concepts . 8
4.1 General . 8
4.2 Programs . 9
4.2.1 Overview . 9
4.2.2 Program Finite State Machine . 10
4.2.3 Program States . 11
4.2.4 State Transitions . 11
4.2.5 Program State Transition Stimuli . 12
4.2.6 Program Control Methods . 12
4.2.7 Program State Transition Effects . 13
4.2.8 Program Result Data . 13
4.2.9 Program Lifetime . 13
5 Model . 14
5.1 General . 14
5.2 ProgramType. 15
5.2.1 Overview . 15
5.2.2 ProgramType Properties . 17
5.2.3 ProgramType Components . 17
5.2.4 ProgramType Causes (Methods) . 23
5.2.5 ProgramType Effects (Events) . 24
5.2.6 AuditProgramTransitionEventType . 27
5.2.7 FinalResultData . 28
5.2.8 ProgramDiagnosticType . 28
Annex A (informative) Program Example . 30

Figure 1 – Automation facility control . 9
Figure 2 – Program illustration . 10
Figure 3 – Program States and Transitions . 11
Figure 4 – Program Type . 15
Figure 5 – Program FSM References . 18
Figure 6 – ProgramType Causes and Effects . 23
Figure A.1 – Program Example . 30
Figure A.2 – DomainDownload State Diagram . 31
Figure A.3 – DomainDownloadType Partial State Model . 38
Figure A.4 – ReadyToRunning Model . 41
Figure A.5 – OpeningToSending ToClosing Model . 43
Figure A.6 – RunningToSuspended Model . 44

62541-10 © IEC:2012 – 3 –
Figure A.7 – SuspendedToRunning Model . 45
Figure A.8 – RunningToHalted – Aborted Model . 46
Figure A.9 – SuspendedToAborted Model . 47
Figure A.10 – RunningToCompleted Model . 48
Figure A.11 – Sequence of Operations . 49

Table 1 – Program Finite State Machine . 10
Table 2 – Program States . 11
Table 3 – Program State Transitions . 12
Table 4 – Program Control Methods . 12
Table 5 – ProgramType . 16
Table 6 – Program States . 19
Table 7 – Program Transitions . 20
Table 8 – ProgramType Causes . 23
Table 9 – ProgramTransitionEventType . 25
Table 10 – ProgramTransitionEvents . 26
Table 11 – AuditProgramTransitionEventType . 27
Table 12 – ProgramDiagnosticType . 28
Table A.1 – DomainDownload States . 32
Table A.2 – DomainDownload Type . 34
Table A.3 – Transfer State Machine Type . 35
Table A.4 – Transfer State Machine – States . 36
Table A.5 – Finish State Machine Type . 36
Table A.6 – Finish State Machine – States . 37
Table A.7 – DomainDownload Type Property Attributes Variable Values . 37
Table A.8 – Additonal DomainDownload Transition Types . 39
Table A.9 – Start Method Additions . 41
Table A.10 – StartArguments . 42
Table A.11 – Intermediate Results Object . 43
Table A.12 – Intermediate Result Data Variables . 44
Table A.13 – Final Result Data . 47
Table A.14 – Final Result Variables . 48

– 4 – 62541-10 © IEC:2012
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 interna-
tional 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, Tech-
nical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publica-
tion(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 Interna-
tional 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 inter-
ested 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 misinter-
pretation 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 be-
tween 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 ex-
penses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC Publica-
tions.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62541-10 has been prepared by subcommittee 65E: Devices and
integration in enterprise systems, of IEC technical committee 65: Industrial-process meas-
urement, control and automation.
The text of this standard is based on the following documents:
FDIS Report on voting
65E/244/FDIS 65E/269/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
A list of all parts of the IEC 62541 series, published under the general title OPC unified archi-
tecture, can be found on the IEC website.

62541-10 © IEC:2012 – 5 –
The committee has decided that the contents of this publication will remain unchanged until
the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data re-
lated to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct understand-
ing of its contents. Users should therefore print this document using a colour printer.

– 6 – 62541-10 © IEC:2012
INTRODUCTION
This International Standard is a specification intended for developers of OPC UA applications.
The specification is a result of an analysis and design process to develop a standard interface
to facilitate the development of applications by multiple vendors that inter-operate seamlessly
together.
62541-10 © IEC:2012 – 7 –
OPC UNIFIED ARCHITECTURE –
Part 10: Programs
1 Scope
This part of the IEC 62541 series specifies the standard representation of Programs as part of
the OPC Unified Architecture and its defined information model. This includes the description
of the NodeClasses, standard Properties, Methods and Events and associated behaviour and
information for Programs.
The complete address space 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 Pro-
grams are specified in IEC 62541-4.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amend-
ments) applies.
IEC/TR 62541-1, OPC Unified Architecture – Part 1: Overview and Concepts
IEC 62541-3:2010, OPC unified architecture – Part 3: Address Space Model
IEC 62541-4:2011, OPC unified architecture – Part 4: Services
IEC 62541-5, OPC unified architecure – Part 5: Information Model
IEC 62541-7, OPC unified architecture – Part 7: Profiles
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC/TR 62541-1 and
IEC 62541-3, as well as the following apply.
3.1.1
function
programmatic task performed at 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

– 8 – 62541-10 © IEC:2012
3.1.3
ProgramType
ObjectType Node that represents the type definition of a Program and is a subtype of the
FiniteStateMachineType
3.1.4
Program Control Method
Method specified by this specification 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: The Program Invocation is distinguished from other Object instances of the same ProgramType
by the object node’s unique browse path.
3.2 Abbreviations
API Application Programming Interface
DA Data Access
FSM Finite State Machine
HMI Human Machine Interfaces
PCM Program Control Method
PGM Program
PI Program Invocation
PLC Programmable Logic Controller
UA Unified Architecture
UML Unified Modelling Language
4 Concepts
4.1 General
Integrated automation facilities manage their operations through the exchange of data and
coordinated invocation of system functions like illustrated in Figure 1. Services are required to
perform the data exchanges and to invoke the functions that constitute system operation.
These functions may be invoked through human machine interfaces, cell controllers, or other
supervisory control and data acquisition type systems. OPC UA defines Methods and Pro-
grams as an interoperable way to advertise, discover, and request these functions. They pro-
vide a normalizing mechanism for the semantic description, invocation of, 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.
62541-10 © IEC:2012 – 9 –
Filling
Cleaning
Labelling
Palletizing
Packaging
IEC  1511/12
Figure 1 – Automation facility control
Methods and Programs model functions typically having different scopes, behaviours, life-
times, 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, stateful functionality in the system. For example, a method call
may 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. Meth-
ods and their invocation mechanism are described in IEC 62541-3 and IEC 62541-4.
This specification describes the extensions to, or specific use of the core capabilities defined
in IEC 62541-5. Support for the feature described in this specification is described by means
of Profiles in IEC 62541-7.
4.2 Programs
4.2.1 Overview
Programs are complex functions in a server or underlying system that can be invoked and
managed by an OPC UA 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.

– 10 – 62541-10 © IEC:2012
Program
Control Methods
________()
Manage
________()
________()
State Machine
_________
Get Description
_________
_________
Transition Events
_________
Monitor
_________
_________
Result Data
_________
Get Results
_________
_________
IEC  1512/12
Figure 2 – Program illustration
Programs are state full, transitioning through a prescribed sequence of states as they exe-
cute. 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 tran-
sitions.
4.2.2 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
1 HaltedToReady Reset Method Halted Ready
Event/Result
Report Transition 2
2 ReadyToRunning Start Method Ready Running
Event/Result
Halt Method or Report Transition 3
3 RunningToHalted Running Halted
Internal (Error) Event/Result
Report Transition 4
4 RunningToReady Internal Running Ready
Event/Result
Report Transition 5
5 RunningToSuspended Suspend Method Running Suspended
Event/Result
Report Transition 6
6 SuspendedToRunning Resume Method Suspended Running
Event/Result
Report Transition 7
7 SuspendedToHalted Halt Method Suspended Halted
Event/Result
Report Transition 8
8 SuspendedToReady Internal Suspended Ready
Event/Result
Report Transition 9
9 ReadyToHalted Halt Method Ready Halted
Event/Result
62541-10 © IEC:2012 – 11 –
HALTED
READY
4 7
RUNNING
SUSPENDED
IEC  1513/12
Figure 3 – Program States and Transitions
4.2.3 Program States
A standard set of base states are defined for Programs as part of the Program Finite State
Machine. These states represent the stages in which a Program can exist at an instance in
time as viewed by a client. This state is the Program’s Current State. All Programs shall sup-
port this base set. A Program may or may not 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 may be started.
Running The Program is executing making progress towards completion.
The Program has been stopped prior to reaching a terminal state but may be
Suspended
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 to the process and to describe the
cause and effects of additional stimuli and transitions. Standards bodies and industry groups
may extend the base Program Finite State Model to conform to industry models. For example,
the Halted state can include the sub states “Aborted” and “Completed” to indicate if the func-
tion achieved a successful conclusion prior to the transition to Halted. Transitional states such
as “Starting” or “Suspending” might also be extensions of the running state, for example.
4.2.4 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.

– 12 – 62541-10 © IEC:2012
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.5 Program State Transition Stimuli
The stimuli or causes for a Program’s state transitions can be internal to the Server or exter-
nal. Completion of machining steps, the detection of an alarm condition, or the transmission of
a data a 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.6 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 action’s performed by the
Program. This specification defines a set of standard Program Control Methods. These Meth-
ods 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, some Programs may not be permitted to suspend and so would not provide the
Suspend and Resume Methods.
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.

Program Control Methods can include arguments that are used by the Program. For example,
a Start method may include an options argument that specifies dynamic options used to de-
termine some program behaviour. The arguments can differ on each ProgramType. The
Method Call service specified in IEC 62541-4:2011, 5.11 defines a return status. This return
status indicates the success of the Program Control Method or a reason for its failure.

62541-10 © IEC:2012 – 13 –
4.2.7 Program State Transition Effects
A Program’s state transition generally has a cause and also yields an effect. The effect is a by
product 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 pro-
grammatic action such as the generation of data.
4.2.8 Program Result Data
4.2.8.1 Overview
Result data is generated by a running Program. The result data can be intermediate or final.
Result data may be associated with specific Program state transitions.
4.2.8.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 tran-
sition.
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 inter-
mediate 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 moni-
toring the Program, intermediate result data may be discarded.
4.2.8.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 con-
veyed to the client by the transition event. Terminal result data is also available within the
Program to be read by a client after the program stops. This data persists until the program
instance is rerun or deleted.
4.2.8.4 Monitoring Programs
Clients can monitor the activities associated with a Program’s execution. These activities in-
clude the invocation of the management methods, the generation of result data, and the pro-
gression 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.9 Program Lifetime
4.2.9.1 Overview
Programs can have different lifetimes. Some programs may always be present on a Server
while others are created and removed. Creation and removal can be controlled by a Client or
may 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:2010, 5.5.4 is

– 14 – 62541-10 © IEC:2012
used to create the Program Instance. The initial state of the Program can be Halted or Ready.
Some Programs, for example, may require that a resource becomes available after its crea-
tion, before it is ready to run. In this case, it would be initialized in the Halted state and transi-
tion 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:2011, 5.7 is used to remove the Program Instance. The Program shall be in a
Halted state to be removed. A Program may also be auto removable. An auto removable Pro-
gram deletes itself when execution has terminated.
4.2.9.2 Program Instances
Programs can be multiple instanced or single instanced. A Server can support multiple in-
stances of a Program if these Program instances can be run in parallel. For example, the Pro-
gram may define a Start Method that has an input argument to specify which resource is act-
ed upon by its functions. Each instance of the Program is then started designating use of dif-
ferent 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 inde-
pendently by the Client.
4.2.9.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 may have a limited or unlimited cycle count. These Programs may re-
quire a reset step to transition from the Halted state to the Ready state. This allows for re-
plenishing 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 pre-
sented in IEC 62541-5. Each Program has a type definition that is the subtype of the
FiniteStateMachineType. The ProgramType describes the Finite State Machine model sup-
ported by any Program Invocation of that type. The ProgramType also defines the property
set that characterize specific aspects of that Program’s behaviour such as lifetime and recy-
cling, as well as specifying the result data that is produced by the Program.

62541-10 © IEC:2012 – 15 –
States
States StateMachineObjectType
HasComponents
HasSubtype
Transitions
ProgramType
Method
Method
HasSubtype
Methods
MyProgramType
MyProgram
IEC  1514/12
Figure 4 – Program Type
The base ProgramType defines the standard Finite State Machine specified for all Programs.
This includes the states, transitions, transition causes (Methods) and effects (Events). Sub-
types of the base ProgramType can be defined to extend or more specifically characterize the
behaviour of an individual Program as illustrated with “MyProgramType” in Figure 4.
5.2 ProgramType
5.2.1 Overview
The additional properties and components that compose the ProgramType are listed in
Table 5. No ProgramType specific semantics are assigned to the other base ObjectType or
FiniteStateMachineType Attributes or Properties.

– 16 – 62541-10 © IEC:2012
Table 5 – ProgramType
Attribute Value
Includes all attributes specified for the FiniteStateMachineType
BrowseName ProgramType
IsAbstract False
References NodeClass BrowseName Data TypeDefinition Modelling
Type Rule
HasProperty Variable Creatable Boolean PropertyType --
HasProperty Variable Deletabe Boolean PropertyType Mandatory
HasProperty Variable AutoDelete Boolean PropertyType Mandatory
HasProperty Variable RecycleCount Int32 PropertyType Mandatory
HasProperty Variable InstanceCount UInt32 PropertyType --
HasProperty Variable MaxInstanceCount UInt32 PropertyType --
HasProperty Variable MaxRecycleCount UInt32 PropertyType --

HasComponent Variable ProgramDiagnostic ProgramDiagnos- Optional
ticType
HasComponent Object Halted StateType Mandatory
HasComponent Object Ready StateType Mandatory
HasComponent Object Running StateType Mandatory
HasComponent Object Suspended StateType Mandatory

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

HasComponent Method Start  Optional
HasComponent Method Suspend  Optional
HasComponent Method Reset  Optional
HasComponent Method Halt  Optional
HasComponent Method Resume  Optional

HasComponent Object FinalResultData BaseObjectType Optional

62541-10 © IEC:2012 – 17 –
5.2.2 ProgramType Properties
The Creatable Property is a Boolean that specifies if Program Invocations of this Pro-
gramType can be created by a Client. If False, these Program Invocations are persistent or
may only be created by the server.
The Deletable Property is a Boolean that specifies if a Program Invocation of this Pro-
gramType 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 Pro-
gramType are removed by the Server when execution terminates. If False, these Program In-
vocations persist on the server until they are deleted by the Client. When the Program Invoca-
tion 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 Pro-
gram Invocation of this type has been recycled or restarted from its starting point (not re-
sumed). Note: The Reset Method may 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 re-
sumed). If the value is less than 0, there is no limit to the number of restarts. If the value is
zero, the Program may not be recycled or restarted.
The InstanceCount Property is an unsigned integer that specifies the number of Program In-
vocations 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, there is no limit.
5.2.3 ProgramType Components
5.2.3.1 Overview
The ProgramType Components consists of a set of references to the object instances of
StateTypes, TransitionTypes, EventTypes and the Methods that collectively define the Pro-
gram FiniteStateMachine.
– 18 – 62541-10 © IEC:2012
Ready StateType
FromState
TransitionType
Has Cause ReadyToRunning
Start
BaseEventType
ToState
HasEffect
Running TransitionEventType
IEC  1515/12
Figure 5 – Program FSM References
Figure 5 illustrates the Component References that define the associations between two of
the ProgramType’s states, Ready and Running. The complementary ReferenceTypes have
been omitted to simplify the illustration.
5.2.3.2 ProgramType States
Table 6 specifies the ProgramType’s State Objects. These State Objects are instances of the
StateType defined in IEC 62541-5:2011, Annex B. Each State is assigned a unique
StateNumber value. Subtypes of the ProgramType can add references from any state to a
subordinate or nested StateMachine Object to extend the FinitStateMachine.

62541-10 © IEC:2012 – 19 –
Table 6 – Program States
BrowseName References Target BrowseName Value Target TypeDefini- NOTES
tion
States
Halted HasProperty StateNumber 1 PropertyType
ToTransition HaltedToReady TransitionType
FromTransition RunningToHalted TransitionType
FromTransition SuspendedToHalted TransitionType
FromTransition ReadyToHalted TransitionType

Ready HasProperty StateNumber 2 PropertyType
FromTransition HaltedToReady TransitionType
ToTransition ReadyToRunning TransitionType
FromTransition RunningToReady TransitionType
ToTransition ReadyToHalted TransitionType

Running HasProperty StateNumber 3 PropertyType
ToTransition RunningToHalted TransitionType
ToTransition RunningToReady TransitionType
ToTransition RunningToSuspended TransitionType
FromTransition ReadyToRunning TransitionType
FromTransition SuspendedToRunning TransitionType

Suspended HasProperty StateNumber 4 PropertyType
ToTransition SuspendedToRunning TransitionType
ToTransition SuspendedToHalted TransitionType
ToTransition SuspendedToReady TransitionType
FromTransition RunningToSuspended TransitionType

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 can not yet 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
...