prEN IEC 62541-10:2024

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

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

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

TITLE:
OPC Unified Architecture - Part 10: Programs

PROPOSED STABILITY DATE: 2026
NOTE FROM TC/SC OFFICERS:
electronic file, to make a copy and to print out the content for the sole purpose of preparing National Committee positions.

You may not copy or "mirror" the file or printed version of the document, or any part of it, for any other purpose without
permission in writing from IEC.

IEC CDV 62541-10 © IEC 2023 iii

1 CONTENTS
3 1 Scope . 1
4 2 Normative references . 1
5 3 Terms, definitions and conventions . 1
6 3.1 Terms and definitions . 1
7 3.2 Abbreviations . 2
8 4 Concepts . 2
9 4.1 General . 2
10 4.2 Programs . 3
11 4.2.1 Overview . 3
12 4.2.2 Security considerations . 4
13 4.2.3 Program Finite State Machine . 4
14 4.2.4 Program states . 5
15 4.2.5 State transitions . 6
16 4.2.6 Program state transition stimuli . 6
17 4.2.7 Program Control Methods . 6
18 4.2.8 Program state transition effects . 7
19 4.2.9 Program result data . 7
20 4.2.10 Program lifetime . 8
21 5 Model . 8
22 5.1 General . 8
23 5.2 ProgramStateMachineType . 9
24 5.2.1 Overview . 9
25 5.2.2 ProgramStateMachineType Properties . 11
26 5.2.3 ProgramStateMachineType components . 12
27 5.2.4 ProgramStateMachineType causes (Methods) . 15
28 5.2.5 ProgramStateMachineType effects (Events) . 16
29 5.2.6 AuditProgramTransitionEventType . 18
30 5.2.7 FinalResultData . 18
31 5.2.8 ProgramDiagnostic2 DataType . 18
32 5.2.9 ProgramDiagnostic2Type VariableType . 19
33 Annex A (informative) Program example . 21
34 A.1 Overview. 21
35 A.2 DomainDownload Program . 21
36 A.2.1 General . 21
37 A.2.2 DomainDownload states . 21
38 A.2.3 DomainDownload transitions. 22
39 A.2.4 DomainDownload Methods . 23
40 A.2.5 DomainDownload Events . 24
41 A.2.6 DomainDownload model . 24
IEC CDV 62541-10 © IEC 2023 iv

43 FIGURES
45 Figure 1 – Automation facility control . 3
46 Figure 2 – Program illustration . 4
47 Figure 3 – Program states and transitions . 5
48 Figure 4 – Program Type . 9
49 Figure 5 – Program FSM References . 12
50 Figure 6 – ProgramStateMachineType causes and effects . 15
51 Figure A.1 – Program example . 21
52 Figure A.2 – DomainDownload state diagram . 22
53 Figure A.3 – DomainDownloadType partial state model . 28
54 Figure A.4 – Ready To Running model . 30
55 Figure A.5 – Opening To Sending To Closing model . 32
56 Figure A.6 – Running To Suspended model . 33
57 Figure A.7 – Suspended To Running model . 34
58 Figure A.8 – Running To Halted – Aborted model . 35
59 Figure A.9 – Suspended To Aborted model . 35
60 Figure A.10 – Running To Completed model . 36
61 Figure A.11 – Sequence of operations . 37
v IEC CDV 62541-10 © IEC 2023
63 TABLES
65 Table 1 – Program Finite State Machine . 4
66 Table 2 – Program states . 5
67 Table 3 – Program state transitions . 6
68 Table 4 – Program Control Methods . 7
69 Table 5 – ProgramStateMachineType . 10
70 Table 6 – ProgramStateMachineType Attribute values for child Nodes . 11
71 Table 7 – ProgramStateMachineType Additional References . 13
72 Table 8 – ProgramStateMachineType causes . 15
73 Table 9 – ProgramTransitionEventType . 17
74 Table 10 – AuditProgramTransitionEventType . 18
75 Table 11 – ProgramDiagnostic2DataType structure . 19
76 Table 12 – ProgramDiagnostic2DataType definition . 19
77 Table 13 – ProgramDiagnostic2Type VariableType . 19
78 Table A.1 – DomainDownload states . 23
79 Table A.2 – DomainDownloadType . 25
80 Table A.3 – TransferStateMachineType . 25
81 Table A.4 – TransferStateMachineType Attribute values for child Nodes . 26
82 Table A.5 – Finish State Machine Type . 26
83 Table A.6 – FinishStateMachineType Attribute values for child Nodes . 27
84 Table A.7 – DomainDownloadType Property Attributes variable values . 27
85 Table A.8 – TransferStateMachineType Additional References . 28
86 Table A.9 – Start Method additions . 30
87 Table A.10 – StartArguments . 31
88 Table A.11 – IntermediateResults Object . 32
89 Table A.12 – Intermediate result data Variables . 33
90 Table A.13 – FinalResultData . 35
IEC CDV 62541-10 © IEC 2023 vi

93 INTERNATIONAL ELECTROTECHNICAL COMMISSION
94 ____________
96 OPC UNIFIED ARCHITECTURE –
98 Part 10: Programs
100 FOREWORD
101 1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
102 all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
103 co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
104 in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
105 Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC Publication(s)"). Their
106 preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with
107 may participate in this preparatory work. International, governmental and non-governmental organizations liaising
108 with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for
109 Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
110 2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
111 consensus of opinion on the relevant subjects since each technical committee has representation from all
112 interested IEC National Committees.
113 3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
114 Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
115 Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
116 misinterpretation by any end user.
117 4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
118 transparently to the maximum extent possible in their national and regional publications. Any divergence between
119 any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
120 5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
121 assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
122 services carried out by independent certification bodies.
123 6) All users should ensure that they have the latest edition of this publication.
124 7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
125 members of its technical committees and IEC National Committees for any personal injury, property damage or
126 other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
127 expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
128 Publications.
129 8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
130 indispensable for the correct application of this publication.
131 9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent
132 rights. IEC shall not be held responsible for identifying any or all such patent rights.
133 International Standard IEC 62541-10 has been prepared by subcommittee 65E: Devices and
134 integration in enterprise systems, of IEC technical committee 65: Industrial-process
135 measurement, control and automation.
136 This fourth edition cancels and replaces the third edition published in 2020. This edition
137 constitutes a technical revision.
138 This edition includes the following significant technical changes with respect to the previous
139 edition:
140 a) The StateMachine model which had been in Part 5 is now a separate part – Part 16.
141 b) StateMachine table format has been aligned.

vii IEC CDV 62541-10 © IEC 2023

142 The text of this International Standard is based on the following documents:
CDV Report on voting
65E/XX/CDV 65E/XX/RVC
144 Full information on the voting for the approval of this International Standard can be found in the
145 report on voting indicated in the above table.
146 This document has been drafted in accordance with the ISO/IEC Directives, Part 2.
147 Throughout this document and the other parts of the IEC 62541 series, certain document
148 conventions are used:
149 Italics are used to denote a defined term or definition that appears in the "Terms and definition"
150 clause in one of the parts of the IEC 62541 series.
151 Italics are also used to denote the name of a service input or output parameter or the name of
152 a structure or element of a structure that are usually defined in tables.
153 The italicized terms and names are, with a few exceptions, written in camel-case (the practice
154 of writing compound words or phrases in which the elements are joined without spaces, with
155 each element's initial letter capitalized within the compound). For example, the defined term is
156 AddressSpace instead of Address Space. This makes it easier to understand that there is a
157 single definition for AddressSpace, not separate definitions for Address and Space.
158 A list of all parts of the IEC 62541 series, published under the general title OPC Unified
159 Architecture, can be found on the IEC website.
160 The committee has decided that the contents of this document will remain unchanged until the
161 stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related to
162 the specific document. At this date, the document will be
163 • reconfirmed,
164 • withdrawn,
165 • replaced by a revised edition, or
166 • 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 understanding
of its contents. Users should therefore print this document using a colour printer.
1 IEC CDV 62541-10 © IEC 2023
169 OPC Unified Architecture Specification
171 Part 10: Programs
175 1 Scope
176 This part of IEC 62541 defines the Information Model associated with Programs in OPC Unified
177 Architecture (OPC UA). This includes the description of the NodeClasses, standard Properties,
178 Methods and Events and associated behaviour and information for Programs.
179 The complete AddressSpace model including all NodeClasses and Attributes is specified in IEC
180 62541-3. The Services such as those used to invoke the Methods used to manage Programs
181 are specified in IEC 62541-4.
182 2 Normative references
183 The following documents, in whole or in part, are normatively referenced in this document and
184 are indispensable for its application. For dated references, only the edition cited applies. For
185 undated references, the latest edition of the referenced document (including any amendments
186 and errata) applies.
187 IEC 62541-1, OPC Unified Architecture – Part 1: Overview and Concepts
188 IEC 62541-3, OPC Unified Architecture – Part 3: Address Space Model
189 IEC 62541-4, OPC Unified Architecture – Part 4: Services
190 IEC 62541-5, OPC Unified Architecture – Part 5: Information Model
191 IEC 62541-7, OPC Unified Architecture – Part 7: Profiles
192 IEC 62541-16, OPC Unified Architecture – Part 16: State Machines
194 3 Terms, definitions and conventions
195 3.1 Terms and definitions
196 For the purposes of this document, the terms and definitions given in IEC 62541-1, IEC 62541-
197 3, IEC 62541-16, as well as the following apply.
198 3.1.1
199 Function
200 programmatic task performed by a Server or device, usually accomplished by computer code
201 execution
202 3.1.2
203 Finite State Machine
204 sequence of states and valid state transitions along with the causes and effects of those state
205 transitions that define the actions of a Program in terms of discrete stages
206 3.1.3
207 ProgramStateMachineType
208 type definition of a Program and is a subtype of the FiniteStateMachineType
209 3.1.4
210 Program Control Method
211 Method having specific semantics designed for the control of a Program by causing a state
212 transition
IEC CDV 62541-10 © IEC 2023 2
213 3.1.5
214 Program Invocation
215 unique Object instance of a Program existing on a Server
216 Note 1 to entry: A Program Invocation is distinguished from other Object instances of the same
217 ProgramStateMachineType by the object node’s unique browse path.
218 3.2 Abbreviations
219 DA Data Access
220 FSM Finite State Machine
221 HMI Human Machine Interfaces
222 UA Unified Architecture
223 4 Concepts
224 4.1 General
225 Integrated automation facilities manage their operations through the exchange of data and the
226 coordinated invocation of system Functions as illustrated in Figure 1. Services are required to
227 perform the data exchanges and to invoke the Functions that constitute system operation.
228 These Functions may be invoked through Human Machine Interfaces, cell controllers, or other
229 supervisory control and data acquisition type systems. OPC UA defines Methods and Programs
230 as an interoperable way to advertise, discover, and request these Functions. They provide a
231 normalizing mechanism for the semantic description, invocation, and result reporting of these
232 Functions. Together Methods and Programs complement the other OPC UA Services and
233 ObjectTypes to facilitate the operation of an automation environment using a client-server
234 hierarchy.
3 IEC CDV 62541-10 © IEC 2023
Cleaning
Filling
Labelling
Palletizing
Packaging
236 Figure 1 – Automation facility control
237 Methods and Programs model Functions typically have different scopes, behaviours, lifetimes,
238 and complexities in OPC Servers and the underlying systems. These Functionsare not normally
239 characterized by the reading or writing of data which is accomplished with the OPC UA Attribute
240 service set.
241 Methods represent basic Functions in the Server that can be invoked by a Client. Programs, by
242 contrast, model more complex and stateful functionality in the system. For example, a method
243 call may be used to perform a calculation or reset a counter. A Program is used to run and
244 control a batch process, execute a machine tool part program, or manage a domain download.
245 Methods and their invocation mechanism are described in IEC 62541-3 and IEC 62541-4.
246 This standard describes the extensions to, or specific use of, the core capabilities defined in
247 IEC 62541-5 and IEC 62541-16 as required for Programs.
248 4.2 Programs
249 4.2.1 Overview
250 Programs are complex Functions in a Server or underlying system that can be invoked and
251 managed by a Client. Programs can represent any level of functionality within a system or
252 process in which Client control or intervention is required and progress monitoring is desired.
253 Figure 2 illustrates the model.

IEC CDV 62541-10 © IEC 2023 4
Program
Control Methods
________()
Manage
________()
________()
State Machine
_________
Get Description
_________
_________
Transition Events
_________
Monitor
_________
_________
Result Data
_________
Get Results
_________
_________
255 Figure 2 – Program illustration
256 Programs are stateful and transition through a prescribed sequence of states as they execute.
257 Their behaviour is defined by a Program Finite State Machine (PFSM). The elements of the
258 PFSM describe the phases of a Program’s execution in terms of valid transitions between a set
259 of states, the stimuli or causes of those transitions, and the resultant effects of the transitions.
260 4.2.2 Security considerations
261 Since Programs can be used to perform advanced control algorithms or other actions, their use
262 should be restricted to personnel with appropriate access rights. It is recommended that
263 AuditUpdateMethodEvents are generated to allow monitoring the number of running Programs
264 in addition to their execution frequency.
265 4.2.3 Program Finite State Machine
266 The states, transitions, causes and effects that compose the Program Finite State Machine are
267 listed in Table 1 and illustrated in Figure 3.
268 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
Suspend Report Transition 5
5 RunningToSuspended Running Suspended
Method Event/Result
Resume Report Transition 6
6 SuspendedToRunning Suspended Running
Method Event/Result
Report Transition 7
7 SuspendedToHalted Halt Method Suspended Halted
Event/Result
5 IEC CDV 62541-10 © IEC 2023
No. Transition name Cause From state To state Effect
Report Transition 8
8 SuspendedToReady Internal Suspended Ready
Event/Result
Report Transition 9
9 ReadyToHalted Halt Method Ready Halted
Event/Result
HALTED
READY
4 7
RUNNING
SUSPENDED
271 Figure 3 – Program states and transitions
272 4.2.4 Program states
273 A standard set of base states is defined for Programs as part of the Program Finite State
274 Machine. These states represent the stages in which a Program can exist at an instant in time
275 as viewed by a Client. This state is the Program’s current state. All Programs shall support this
276 base set. A Program may or may not require a Client action to cause the state to change. The
277 states are formally defined in Table 2.
278 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.
280 The set of states defined to describe a Program can be expanded. Program substates can be
281 defined for the base states to provide more resolution of a process and to describe the cause
282 and effect(s) of additional stimuli and transitions. Standards bodies and industry groups may
283 extend the base Program Finite State Model to conform to various industry models. For
284 example, the Halted state can include the substates “Aborted” and “Completed” to indicate if
285 the Function achieved a successful conclusion prior to the transition to Halted. Transitional
286 states such as “Starting” or “Suspending” might also be extensions of the Running state, for
287 example.
IEC CDV 62541-10 © IEC 2023 6
288 4.2.5 State transitions
289 A standard set of state transitions is defined for the Program Finite State Machine. These
290 transitions define the valid changes to the Program’s current state in terms of an initial state
291 and a resultant state. The transitions are formally defined in Table 3.
292 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
294 4.2.6 Program state transition stimuli
295 The stimuli or causes for a Program’s state transitions can be internal to the Server or external.
296 The completion of machining steps, the detection of an alarm condition, or the transmission of
297 a data packet are examples of internal stimuli. Methods are an example of external stimuli.
298 Standard Methods are defined which act as stimuli for the control of a Program.
299 4.2.7 Program Control Methods
300 Clients manage a Program by calling Methods. The Methods impact a Program’s behaviour by
301 causing specified state transitions. The state transitions dictate the actions performed by the
302 Program. This standard defines a set of standard Program Control Methods. These Methods
303 provide sufficient means for a Client to run a Program.
304 Table 4 lists the set of defined Program Control Methods. Each Method causes transitions from
305 specified states and shall be called when the Program is in one of those states.
306 Individual Programs can optionally support any subset of the Program Control Methods. For
307 example, some Programs may not be permitted to suspend and so would not provide the
308 Suspend and Resume Methods.
309 Programs can support additional user defined Methods. User defined Methods shall not change
310 the behaviour of the base Program Finite State Machine.
7 IEC CDV 62541-10 © IEC 2023
312 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.
314 All Program Control Methods are defined with their BrowseName on the
315 ProgramStateMachineType with the OptionalPlaceholder ModellingRule. As defined in IEC
316 62541-3, this rule allows the inclusion of Arguments to these Methods on sub-types or on
317 instances. For example, a Start Method may include an options argument that specifies dynamic
318 options used to determine some program behaviour. The Method Call service specified in IEC
319 62541-4 defines a return status. This return status indicates the success of the Program Control
320 Method or a reason for its failure.
321 4.2.8 Program state transition effects
322 A Program’s state transition generally has a cause and also yields an effect. The effect is a by
323 product of a Program state transition that can be used by a Client to monitor the progress of
324 the Program. Effects can be internal or external. An external effect of a state transition is the
325 generation of an Event notification. Each Program state transition is associated with a unique
326 Event. These Events reflect the progression and trajectory of the Program through its set of
327 defined states. The internal effects of a state transition can be the performance of some
328 programmatic action such as the generation of data.
329 4.2.9 Program result data
330 4.2.9.1 Overview
331 Result data is generated by a running Program. The result data can be intermediate or final.
332 Result data may be associated with specific Program state transitions.
333 4.2.9.2 Intermediate result data
334 Intermediate result data is transient and is generated by the Program in conjunction with non-
335 terminal state transitions. The data items that compose the intermediate results are defined in
336 association with specific Program state transitions. Their values are relevant only at the
337 transition level.
338 Each Program state transition can be associated with different result data items. Alternately, a
339 set of transitions can share a result data item. Percentage complete is an example of
340 intermediate result data. The value of percentage complete is produced when the state
341 transition occurs and is available to the Client.
342 Clients acquire intermediate result data by subscribing to Program state transition Events. The
343 Events specify the data items for each transition. When the transition occurs, the generated
344 Event conveys the result data values captured to the subscribed Clients. If no Client is
345 monitoring the Program, intermediate result data may be discarded.
346 4.2.9.3 Terminal result data
347 Terminal result data is the final data generated by the Program as it ceases execution. Total
348 execution time, number of widgets produced, and fault condition encountered are examples of
349 terminal result data. When the Program enters the terminal state, this result data can be
350 conveyed to the Client by the transition Event. Terminal result data is also available within the
351 Program to be read by a Client after the program stops. This data persists until the Program
352 Instance is rerun or deleted.

IEC CDV 62541-10 © IEC 2023 8
353 4.2.9.4 Monitoring Programs
354 Clients can monitor the activities associated with a Program’s execution. These activities
355 include the invocation of the management Methods, the generation of result data, and the
356 progression of the Program through its states. Audit Events are provided for Method Calls and
357 state transitions. These Events allow a record to be maintained of the Clients that interacted
358 with any Program and the Program state transitions that resulted from that interaction.
359 4.2.10 Program lifetime
360 4.2.10.1 Overview
361 Programs can have different lifetimes. Some Programs may always be present on a Server
362 while others are created and removed. Creation and removal can be controlled by a Client or
363 may be restricted to local means.
364 A Program can be Client creatable. If a Program is Client creatable, then the Client can add the
365 Program to the Server. The Object Create Method defined in IEC 62541-3, is used to create the
366 Program instance. The initial state of the Program can be Halted or Ready. Some Programs,
367 for example, may require that a resource becomes available after its creation and before it is
368 ready to run. In this case, it would be initialized in the Halted state and transition to Ready when
369 the resource is delivered.
370 A Program can be Client removable. If the Program is Client removable, then the Client can
371 delete the Program instance from the Server. The DeleteNodes Service defined in
372 IEC 62541-4 is used to remove the Program Instance. The Program shall be in a Halted state
373 to be removed. A Program may also be auto removable. An auto removable Program deletes
374 itself when execution has terminated.
375 4.2.10.2 Program instances
376 Programs can be multiple instanced or single instanced. A Server can support multiple
377 instances of a Program if these Program Instances can be run in parallel. For example, the
378 Program may define a Start Method that has an input argument to specify which resource is
379 acted upon by its Functions. Each instance of the Program is then started designating use of
380 different resources. The Client can discover all instances of a Program that are running on a
381 Server. Each instance of a Program is uniquely identified on the Server and is managed
382 independently by the Client.
383 4.2.10.3 Program recycling
384 Programs can be run once or run multiple times (recycled). A Program that is run once will
385 remain in the Halted state indefinitely once it has run. The normal course of action would be to
386 delete it following the inspection of its terminal results.
387 Recyclable Programs may have a limited or unlimited cycle count. These Programs may require
388 a reset step to transition from the Halted state to the Ready state. This allows for replenishing
389 resources or reinitializing parameters prior to restarting the Program. The Program Control
390 Method “Reset” triggers this state transition and any associated actions or effects.
391 5 Model
392 5.1 General
393 The Program model extends the FiniteStateMachineType and basic ObjectType models
394 presented in IEC 62541-16. Each Program has a Type Definition that is the subtype of the
395 FiniteStateMachineType. The ProgramStateMachineType describes the Finite State Machine
396 model supported by any Program Invocation of that type. The ProgramStateMachineType also
397 defines the property set that characterizes specific aspects of that Program’s behaviour such
398 as lifetime and recycling as well as specifying the result data that is produced by the Program.

9 IEC CDV 62541-10 © IEC 2023
States
States StateMachineObjectType
HasComponents
HasSubtype
Transitions
ProgramStateMachine
Type
Method
Method
HasSubtype
Methods
MyProgramType
MyProgram
400 Figure 4 – Program Type
401 The base ProgramStateMachineType defines the standard Finite State Machine specified for
402 all Programs. This includes the states, transitions, and transition causes (Methods) and effects
403 (Events). Subtypes of the base ProgramStateMachineType can be defined to extend or more
404 specifically characterize the behaviour of an individual Program as illustrated with
405 “MyProgramType” in Figure 4.
406 5.2 ProgramStateMachineType
407 5.2.1 Overview
408 The additional properties and components that compose the ProgramStateMachineType are
409 listed in Table 5. No ProgramStateMachineType specific semantics are assigned to the other
410 base ObjectType or FiniteStateMachineType Attributes or Properties.
IEC CDV 62541-10 © IEC 2023 10

412 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 ProgramDiagnostic2D ProgramDiagnostic2 O
ataType 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
11 IEC CDV 62541-10 © IEC 2023

414 The component Variables of the ProgramStateMachineType have additional Attributes defined
415 in Table 6.
416 Table 6 – ProgramStateMachineType Attribute values for child Nodes
BrowsePath Value Attribute
Halted
StateNumber
Ready
StateNumber
Running
StateNumber
Suspended
StateNumber
HaltedToReady
TransitionNumber
ReadyToRunning
TransitionNumber
RunningToHalted
TransitionNumber
RunningToReady
TransitionNumber
RunningToSuspended
TransitionNumber
SuspendedToRunning
TransitionNumber
SuspendedToHalted
TransitionNumber
SuspendedToReady
TransitionNumber
ReadyToHalted
TransitionNumber
419 5.2.2 ProgramStateMachineType Properties
420 The Creatable Property is a boolean that specifies if Program Invocations of this
421 ProgramStateMachineType can be created by a Client. If False, these Program Invocations are
422 persistent or may only be created by the Server.
423 The Deletable Property is a boolean that specifies if a Program Invocation of this
424 ProgramStateMachineType can be deleted by a Client. If False, these Program Invocations can
425 only be deleted by the Server.
426 The AutoDelete Property is a boolean that specifies if Program Invocations of this
427 ProgramStateMachineType are removed by the Server when execution terminates. If False,
428 these Program Invocations persist on the Server until they are deleted by the Client. When the
429 Program Invocation is deleted, any result data associated with the instance is also removed.
430 The RecycleCount Property is an unsigned integer that specifies the number of times a Program
431 Invocation of this type has been recycled or restarted from its starting point (not resumed). Note
432 that the Reset Method may be required to prepare a Program to be restarted.
433 The MaxRecycleCount Property is an integer that specifies the maximum number of times a
434 Program Invocation of this type can be recycled or restarted from its starting point (not
435 resumed). If the value is less than 0, then there is no limit to the number of restarts. If the value
436 is zero, then the Program may not be recycled or restarted.
437 The InstanceCount Property is an unsigned integer that specifies the number of Program
438 Invocations of this type that currently exist.

IEC CDV 62541-10 © IEC 2023 12

439 The MaxInstanceCount Property is an integer that specifies the maximum number of Program
440 Invocations of this type that can exist simultaneously on this Server. If the value is less than 0,
441 then there is no limit.
442 5.2.3 ProgramStateMachineType components
443 5.2.3.1 Overview
444 The ProgramStateMachineType components consist of a set of References to the Object
445 instances of StateTypes, TransitionTypes, EventTypes and the Meth
...