SIST EN IEC 62541-16:2026

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

EUROPEAN STANDARD EN IEC 62541-16

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

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

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

IEC 62541-16:2025-12(en)
IEC 62541-16:2025 © IEC 2025
CONTENTS
FOREWORD . 3
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 State Machine model . 5
4.1 General . 5
4.2 Examples of finite state machines . 6
4.2.1 Simple state machine . 6
4.2.2 State machine containing substates . 6
4.3 Definition of state machine . 7
4.4 Representation of state machines in the AddressSpace . 8
4.4.1 Overview . 8
4.4.2 StateMachineType . 9
4.4.3 StateVariableType . 10
4.4.4 TransitionVariableType . 10
4.4.5 FiniteStateMachineType . 11
4.4.6 FiniteStateVariableType . 13
4.4.7 FiniteTransitionVariableType . 14
4.4.8 StateType . 15
4.4.9 InitialStateType. 15
4.4.10 TransitionType . 16
4.4.11 FromState . 17
4.4.12 ToState . 17
4.4.13 HasCause . 18
4.4.14 HasEffect . 19
4.4.15 HasSubStateMachine . 19
4.4.16 TransitionEventType . 20
4.4.17 AuditUpdateStateEventType . 20
4.4.18 Special restrictions on subtyping StateMachines . 21
4.4.19 Specific StatusCodes for StateMachines . 22
4.5 Examples of StateMachines in the AddressSpace . 22
4.5.1 StateMachineType using inheritance . 22
4.5.2 StateMachineType with a SubStateMachine using inheritance . 24
4.5.3 StateMachineType using containment . 25
4.5.4 Example of a StateMachine having Transition to SubStateMachine . 26
4.5.5 Example of a StateMachine adding a SubStateMachine on a Subtype . 27
4.6 StateMachine extensions for ChoiceStates and Guards . 30
4.6.1 Overview . 30
4.6.2 ChoiceStateType . 30
4.6.3 HasGuard . 31
4.6.4 GuardVariableType . 31
4.6.5 ExpressionGuardVariableType . 32
4.6.6 ElseGuardVariableType . 33
4.7 Example of a StateMachine using a ChoiceState and Guards . 33
Bibliography . 35

IEC 62541-16:2025 © IEC 2025
Figure 1 – Example of a simple state machine . 6
Figure 2 – Example of a state machine having a sub-machine . 7
Figure 3 – The StateMachine Information Model . 8
Figure 4 – Example of a FiniteStateMachine type. 13
Figure 5 – Example of a FiniteStateMachine instance . 13
Figure 6 – Example of an initial State in a sub-machine . 16
Figure 7 – Example of a StateMachineType using inheritance . 22
Figure 8 – Example of a StateMachineType with a SubStateMachine using inheritance . 24
Figure 9 – Example of a StateMachineType using containment . 25
Figure 10 – Example of a StateMachine with Transitions from sub-states . 26
Figure 11 – Example of a StateMachineType having Transition to SubStateMachine . 27
Figure 12 – Example of a StateMachine with two States . 28
Figure 13 – Example of a StateMachine extended with two Substates . 28
Figure 14 – Example of a StateMachine extended with another two Substates . 28
Figure 15 – Example of a StateMachineType adding SubStateMachines in Subtypes . 29
Figure 16 – Example of a ChoiceState . 30
Figure 17 – Example of a StateMachine using ChoiceState and Guards . 34

Table 1 – StateMachineType definition . 9
Table 2 – StateVariableType definition . 10
Table 3 – TransitionVariableType definition . 11
Table 4 – FiniteStateMachineType definition . 12
Table 5 – FiniteStateVariableType definition . 14
Table 6 – FiniteTransitionVariableType definition . 14
Table 7 – StateType definition . 15
Table 8 – InitialStateType definition . 16
Table 9 – TransitionType definition . 17
Table 10 – FromState ReferenceType . 17
Table 11 – ToState ReferenceType . 18
Table 12 – HasCause ReferenceType . 18
Table 13 – HasEffect ReferenceType . 19
Table 14 – HasSubStateMachine ReferenceType. 20
Table 15 – TransitionEventType . 20
Table 16 – AuditUpdateStateEventType . 21
Table 17 – Specific StatusCodes for StateMachines . 22
Table 18 – ChoiceStateType . 30
Table 19 – HasGuard ReferenceType . 31
Table 20 – GuardVariableType definition . 32
Table 21 – ExpressionGuardVariableType definition . 32
Table 22 – ElseGuardVariableType definition . 33

IEC 62541-16:2025 © IEC 2025
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
OPC unified architecture -
Part 16: State Machines
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-16 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.
The text of this International Standard is based on the following documents:
Draft Report on voting
65E/1041/CDV 65E/1132/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.
IEC 62541-16:2025 © IEC 2025
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 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 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 also often written in camel-case (the practice of writing
compound words or phrases in which the elements are joined without spaces, with each
element's initial letter capitalized within the compound). For example, the defined term is
AddressSpace instead of Address Space. This makes it easier to understand that there is a
single definition for AddressSpace, not separate definitions for Address and Space.
A list of all parts in the IEC 62541 series, published under the general title OPC Unified
Architecture, can be found on the IEC website.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
– reconfirmed,
– withdrawn, or
– revised.
IEC 62541-16:2025 © IEC 2025
1 Scope
This part of IEC 62541 defines an Information Model. The Information Model describes the basic
infrastructure to model state machines.
NOTE State Machines were dealt with in IEC 62541-5:2020, Annex B. In newer versions of IEC 62541-5 this
Annex B was removed and replaced by this document
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
3 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 62541-1,
IEC 62541-3, and IEC 62541-5 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
4 State Machine model
4.1 General
This document describes the basic infrastructure to model state machines. It defines
ObjectTypes, VariableTypes and ReferenceTypes and explains how they should be used.
The types in this document can be directly utilized. However, it is not required but strongly
recommended that a Server uses these types to expose its state machines. The defined types
can be subtyped to refine their behaviour.
When a Server exposes its state machine using the types defined in this document, it can
provide a simplified view on its internal state machine, hiding for example substates or putting
several internal states into one exposed state.
The scope of the state machines described in this document is to provide an appropriate
foundation for state machines required for IEC 62541-9 and IEC 62541-10. It does not provide
more complex functionality of a state machine like parallel states, forks and joins, history states,
choices, and junctions, etc. However, the base state machine defined in this document can be
extended to support such concepts.
IEC 62541-16:2025 © IEC 2025
4.2 to 4.7 describe examples of state machines, define state machines in the context of this
document and define the representation of state machines in OPC UA. Finally, some examples
of state machines, represented in OPC UA, are given.
4.2 Examples of finite state machines
4.2.1 Simple state machine
The following example provides an overview of the base features that the state machines
defined in this document will support. In the following, a more complex example is given, that
also supports sub-state machines.
Figure 1 gives an overview over a simple state machine. It contains the three states "State1",
"State2" and "State3". There are transitions from "State1" to "State2", "State2" to "State2", etc.
Some of the transitions provide additional information with regard to what causes (or triggers)
the transition, for example the call of "Method1" for the transition from "State1" to "State2". The
effect (or action) of the transition can also be specified, for example the generation of an Event
of the "EventType1" in the same transition. The notation used to identify the cause is simply
listing it on the transition, the effect is prefixed with a "/". More than one cause or effect are
separated by a ",". Not every transition has to have a cause or effect, for example the transition
between "State2" and "State3".

Figure 1 – Example of a simple state machine
For simplicity, the state machines described in this document will only support causes in form
of specifying Methods that are called and effects in form of EventTypes of Events that are
generated. However, the defined infrastructure allows extending this to support additional
different causes and effects.
4.2.2 State machine containing substates
Figure 2 shows an example of a state machine where "State6" is a sub-state-machine. This
means, that when the overall state machine is in State6, this state can be distinguished to be
in the sub-states "State7" or "State8". Sub-state-machines can be nested, that is, "State7" could
be another sub-state-machine.
IEC 62541-16:2025 © IEC 2025
Figure 2 – Example of a state machine having a sub-machine
4.3 Definition of state machine
The infrastructure of state machines defined in this document only deals with the basics of state
machines required for IEC 62541-9 and IEC 62541-10. The intention is to keep the basic simple
but extensible.
For the state machines defined in this document we assume that state machines are typed and
instances of a type have their states and semantics specified by the type. For some types, this
means that the states and transitions are fixed. For other types the states and transitions can
be dynamic or unknown. A state machine where all the states are specified explicitly by the
type is called a finite state machine.
Therefore, we distinguish between StateMachineType and StateMachine and their subtypes like
FiniteStateMachineType. The StateMachineType specifies a description of the state machine,
that is, its states, transitions, etc., whereas the StateMachine is an instance of the
StateMachineType and only contains the current state.
Each StateMachine contains information about the current state. If the StateMachineType has
SubStateMachines, the StateMachine also contains information about the current state of the
SubStateMachines. StateMachines which have their states completely defined by the type are
instances of a FiniteStateMachineType.
Each FiniteStateMachineType has one or more States. For simplicity, we do not distinguish
between different States like the start or the end states.
Each State can have one or more SubStateMachines.
Each FiniteStateMachineType can have one or more Transitions. A Transition is directed and
points from one State to another State.
IEC 62541-16:2025 © IEC 2025
Each Transition can have one or more Causes. A Cause leads a FiniteStateMachine to change
its current State from the source of the Transition to its target. In this document we only specify
Method calls to be Causes of Transitions. Transitions do not have to have a Cause. A Transition
can always be caused by some server-internal logic that is not exposed in the AddressSpace.
Each Transition can have one or more Effects. An Effect occurs if the Transition is used to
change the State of a StateMachine. In this document we only specify the generation of Events
to be Effects of a Transition. A Transition is not required to expose any Effects in the
AddressSpace.
Although this document only specifies simple concepts for state machines, the provided
infrastructure is extensible. If needed, special States can be defined as well as additional
Causes or Effects.
4.4 Representation of state machines in the AddressSpace
4.4.1 Overview
The types defined in this document are illustrated in Figure 3. The MyFiniteStateMachineType
is a minimal example which illustrates how these Types can be used to describe a
StateMachine. See IEC 62541-9 and IEC 62541-10 for additional examples of StateMachines.

Figure 3 – The StateMachine Information Model
IEC 62541-16:2025 © IEC 2025
4.4.2 StateMachineType
The StateMachineType is the base ObjectType for all StateMachineTypes. It defines a single
Variable which represents the current state of the machine. An instance of this ObjectType shall
generate an Event whenever a significant state change occurs. The Server decides which state
changes are significant. Servers shall use the GeneratesEvent ReferenceType to indicate which
Event(s) could be produced by the StateMachine.
Subtypes can add Methods which affect the state of the machine. The Executable Attribute is
used to indicate whether the Method is valid given the current state of the machine. The
generation of AuditEvents for Methods is defined in IEC 62541-4. A StateMachine is not
necessarily active. In this case, the CurrentState and LastTransition Variables shall have a
status equal to Bad_StateNotActive (see Table 17).
Subtypes can add components which are instances of StateMachineTypes. These components
are considered to be sub-states of the StateMachine. SubStateMachines are only active when
the parent machine is in an appropriate state.
Events produced by SubStateMachines can be suppressed by the parent machine. In some
cases, the parent machine will produce a single Event that reflects changes in multiple
SubStateMachines.
FiniteStateMachineType is a subtype of StateMachineType that provides a mechanism to
explicitly define the states and transitions. A Server should use this mechanism if it knows what
the possible states are and the state machine is not trivial. The FiniteStateMachineType is
defined in 4.4.5.
The StateMachineType is formally defined in Table 1.
Table 1 – StateMachineType definition
Attribute Value
BrowseName StateMachineType
IsAbstract False
Modelling
References NodeClass BrowseName DataType TypeDefinition
Rule
Subtype of the BaseObjectType defined in IEC 62541-5
Note that a Reference to this subtype is not shown in the definition of the BaseObjectType.
HasSubtype ObjectType FiniteStateMachineType Defined in 4.4.5
HasComponent Variable CurrentState LocalizedText StateVariableType Mandatory
HasComponent Variable LastTransition LocalizedText TransitionVariableType Optional
Conformance Units
Base Info State Machine Instance

CurrentState stores the current state of an instance of the StateMachineType. CurrentState
provides a human readable name for the current state which is not necessarily suitable for use
in application control logic. Applications should use the Id Property of CurrentState if they need
a unique identifier for the state.
LastTransition stores the last transition which occurred in an instance of the StateMachineType.
LastTransition provides a human readable name for the last transition which is not necessarily
suitable for use in application control logic. Applications should use the Id Property of
LastTransition if they need a unique identifier for the transition.
IEC 62541-16:2025 © IEC 2025
4.4.3 StateVariableType
The StateVariableType is the base VariableType for Variables that store the current state of a
StateMachine as a human readable name.
The StateVariableType is formally defined in Table 2.
Table 2 – StateVariableType definition
Attribute Value
BrowseName StateVariableType
DataType LocalizedText
ValueRank −1 (−1 = Scalar)
IsAbstract False
Modelling
References NodeClass BrowseName DataType TypeDefinition
Rule
Subtype of the BaseDataVariableType defined in IEC 62541-5
Note that a Reference to this subtype is not shown in the definition of the BaseDataVariableType.
HasSubtype VariableType FiniteStateVariableType Defined in 4.4.6
HasProperty Variable Id BaseDataType PropertyType Mandatory
HasProperty Variable Name QualifiedName PropertyType Optional
HasProperty Variable Number UInt32 PropertyType Optional
HasProperty Variable EffectiveDisplayName LocalizedText PropertyType Optional
Conformance Units
Base Info State Machine Instance

Id is a name which uniquely identifies the current state within the StateMachineType. A subtype
can restrict the DataType.
Name is a QualifiedName which uniquely identifies the current state within the
StateMachineType.
Number is an integer which uniquely identifies the current state within the StateMachineType.
EffectiveDisplayName contains a human readable name for the current state of the state
machine after taking the state of any SubStateMachines in account. There is no rule specified
for which state or sub-state should be used. It is up to the Server and will depend on the
semantics of the StateMachineType.
StateMachines produce Events which can include the current state of a StateMachine. In that
case Servers shall provide all the optional Properties of the StateVariableType in the Event,
even if they are not provided on the instances in the AddressSpace.
4.4.4 TransitionVariableType
The TransitionVariableType is the base VariableType for Variables that store a Transition that
occurred within a StateMachine as a human readable name.
The SourceTimestamp for the value specifies when the Transition occurred. This value can also
be exposed with the TransitionTime Property.
The TransitionVariableType is formally defined in Table 3.
IEC 62541-16:2025 © IEC 2025
Table 3 – TransitionVariableType definition
Attribute Value
BrowseName TransitionVariableType
DataType LocalizedText
ValueRank −1 (−1 = Scalar)
IsAbstract False
Modelling
References NodeClass BrowseName DataType TypeDefinition
Rule
Subtype of the BaseDataVariableType defined in IEC 62541-5
Note that a Reference to this subtype is not shown in the definition of the BaseDataVariableType.
HasSubtype VariableType FiniteTransitionVariable- Defined in 4.4.7
Type
HasProperty Variable Id BaseDataType PropertyType Mandatory
HasProperty Variable Name QualifiedName PropertyType Optional
HasProperty Variable Number UInt32 PropertyType Optional
HasProperty Variable TransitionTime UtcTime PropertyType Optional
Conformance Units
Base Info State Machine Instance

Id is a name which uniquely identifies a Transition within the StateMachineType. A subtype can
restrict the DataType.
Name is a QualifiedName which uniquely identifies a transition within the StateMachineType.
Number is an integer which uniquely identifies a transition within the StateMachineType.
TransitionTime specifies when the transition occurred.
EffectiveTransitionTime specifies the time when the current state or one of its substates was
entered. If, for example, a StateA is active and – while active – switches several times between
its substates SubA and SubB, then the TransitionTime stays at the point in time where StateA
became active whereas the EffectiveTransitionTime changes with each change of a substate.
4.4.5 FiniteStateMachineType
The FiniteStateMachineType is the base ObjectType for StateMachines that explicitly define
the possible States and Transitions. Once the States and Transitions are defined subtypes shall
not add new States and Transitions (see 4.4.18). Subtypes can add causes or effects.
The States of the machine are represented with instances of the StateType ObjectType. Each
State shall have a BrowseName which is unique within the StateMachine and shall have a
StateNumber which shall also be unique across all States defined in the StateMachine. Be
aware that States in a SubStateMachine can have the same StateNumber or BrowseName as
States in the parent machine. A concrete subtype of FiniteStateMachineType shall define at
least one State.
A StateMachine can define one State which is an instance of the InitialStateType. This State is
the State that the machine goes into when it is activated.
The Transitions that occur are represented with instances of the TransitionType. Each
Transition shall have a BrowseName which is unique within the StateMachine and can have a
IEC 62541-16:2025 © IEC 2025
TransitionNumber which shall also be unique across all Transitions defined in the
StateMachine.
The initial State for a Transition is a StateType Object which is the target of a FromState
Reference. The final State for a Transition is a StateType Object which is the target of a ToState
Reference. The FromState and ToState References shall always be specified.
A Transition can produce an Event. The Event is indicated by a HasEffect Reference to a
subtype of BaseEventType. The StateMachineType shall have GeneratesEvent References to
the targets of a HasEffect Reference for each of its Transitions.
A FiniteStateMachineType can define Methods that cause a transition to occur. These Methods
are targets of HasCause References for each of the Transitions that can be triggered by the
Method. The Executable Attribute for a Method is used to indicate whether the current State of
the machine allows the Method to be called.
A FiniteStateMachineType can have sub-state-machines which are represented as instances of
StateMachineType ObjectTypes. Each State shall have a HasSubStateMachine Reference to
the StateMachineType Object which represents the child States. The SubStateMachine is not
active if the parent State is not active. In this case the CurrentState and LastTransition Variables
of the SubStateMachine shall have a status equal to Bad_StateNotActive (see Table 17).
The FiniteStateMachineType is formally defined in Table 4.
Table 4 – FiniteStateMachineType definition
Attribute Value
BrowseName FiniteStateMachineType
IsAbstract True
Modelling
References NodeClass BrowseName DataType TypeDefinition
Rule
Subtype of the StateMachineType defined in 4.4.2
HasComponent Variable CurrentState LocalizedText FiniteStateVariableType Mandatory
HasComponent Variable LastTransition LocalizedText FiniteTransitionVariable- Optional
Type
HasComponent Variable AvailableStates NodeId[] BaseDataVariableType Optional
HasComponent Variable AvailableTransitions NodeId[] BaseDataVariableType Optional
Conformance Units
Base Info Finite State Machine Instance
Base Info Available States and Transitions

In some Servers an instance of a StateMachine can restrict the States and / or Transitions that
are available. These restrictions can result from the internal design of the instance. For
example, the StateMachine for an instrument’s limit alarm which only supports Hi and HiHi and
cannot produce a Low or LowLow. An instance of a StateMachine can also dynamically change
the available States and/or Transitions based on its operating mode. For example, when a piece
of equipment is in a maintenance mode the available States can be limited to some subset of
the States available during normal operation.
The AvailableStates Variable provides a NodeId list of the States that are present in the
StateMachine instance. The list can change during operation of the Server.
The AvailableTransitions Variable provides a NodeId list of the Transitions that are present in
the StateMachine instance. The list can change during operation of the Server.
IEC 62541-16:2025 © IEC 2025
An example of a FiniteStateMachine type is shown in Figure 4.

Figure 4 – Example of a FiniteStateMachine type
An example instance of the type is shown in Figure 5. In this example the States {7,8,9} and
the Transitions {G,H,I,J} are not available in this instance.

Figure 5 – Example of a FiniteStateMachine instance
4.4.6 FiniteStateVariableType
The FiniteStateVariableType is a subtype of StateVariableType and is used to store the current
state of a FiniteStateMachine as a human readable name.
IEC 62541-16:2025 © IEC 2025
The FiniteStateVariableType is formally defined in Table 5.
Table 5 – FiniteStateVariableType definition
Attribute Value
BrowseName FiniteStateVariableType
DataType LocalizedText
ValueRank −1 (−1 = Scalar)
IsAbstract False
Modelling
References NodeClass BrowseName DataType TypeDefinition
Rule
Subtype of the StateVariableType defined 4.4.3
HasProperty Variable Id NodeId PropertyType Mandatory
Conformance Units
Base Info Finite State Machine Instance

Id is inherited from the StateVariableType and overridden to reflect the required DataType. This
value shall be the NodeId of one of the State Objects of the FiniteStateMachineType. If the
FiniteStateMachine is subtyped, it shall be the NodeId of the State defined on the supertype,
i.e., where the State is defined the first time in the type hierarchy.
The Name Property is inherited from StateVariableType. Its Value shall be the BrowseName of
one of the State Objects of the FiniteStateMachineType.
The Number Property is inherited from StateVariableType. Its Value shall be the StateNumber
for one of the State Objects of the FiniteStateMachineType.
4.4.7 FiniteTransitionVariableType
The FiniteTransitionVariableType is a subtype of TransitionVariableType and is used to store a
Transition that occurred within a FiniteStateMachine as a human readable name.
The FiniteTransitionVariableType is formally defined in Table 6.
Table 6 – FiniteTransitionVariableType definition
Value
Attribute
FiniteTransitionVariableType
BrowseName
LocalizedText
DataType
−1 (−1 = Scalar)
ValueRank
False
IsAbstract
Modelling Rule
NodeClass BrowseName DataType TypeDefinition
References
Subtype of the TransitionVariableType defined in 4.4.4
Note that a Reference to this subtype is not shown in the definition of the BaseDataVariableType.
Variable Id NodeId PropertyType Mandatory
HasProperty
Conformance Units
Base Info Finite State Machine Instance

Id is inherited from the TransitionVariableType and overridden to reflect the required DataType.
This value shall be the NodeId of one of the Transition Objects of the FiniteStateMachineType.
If the FiniteStateMachine is subtyped, it shall be the NodeId of the Transition defined on the
supertype, i.e., where the Transition is defined the first time in the type hierarchy.
IEC 62541-16:2025 © IEC 2025
The Name Property is inherited from the TransitionVariableType. Its Value shall be the
BrowseName of one of the Transition Objects of the FiniteStateMachineType.
The Number Property is inherited from the TransitionVariableType. Its Value shall be the
TransitionNumber for one of the Transition Objects of the FiniteStateMachineType.
4.4.8 StateType
States of a FiniteStateMachine are represented as Objects of the StateType. Each Object of
the StateType or one of its subtypes shall be referenced from the ObjectType
FiniteStateMachineType or one of its subtypes using a HasComponent Reference or a subtype
of HasComponent and shall not have a ModellingRule as they are not
...