IEC 62541-16:2025

IEC 62541-16 ®
Edition 1.0 2025-12
NORME
INTERNATIONALE
Architecture unifiée OPC -
Partie 16: Diagrammes d'états
ICS 25.040  ISBN 978-2-8327-0834-7

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et
les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.

Recherche de publications IEC -  IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Découvrez notre puissant moteur de recherche et consultez
La recherche avancée permet de trouver des publications gratuitement tous les aperçus des publications, symboles
IEC en utilisant différents critères (numéro de référence, graphiques et le glossaire. Avec un abonnement, vous aurez
texte, comité d’études, …). Elle donne aussi des toujours accès à un contenu à jour adapté à vos besoins.
informations sur les projets et les publications remplacées
ou retirées. Electropedia - www.electropedia.org
Le premier dictionnaire d'électrotechnologie en ligne au
IEC Just Published - webstore.iec.ch/justpublished monde, avec plus de 22 500 articles terminologiques en
Restez informé sur les nouvelles publications IEC. Just anglais et en français, ainsi que les termes équivalents
Published détaille les nouvelles publications parues. dans 25 langues additionnelles. Egalement appelé
Disponible en ligne et une fois par mois par email. Vocabulaire Electrotechnique International (IEV) en ligne.

Service Clients - webstore.iec.ch/csc
Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-
nous: sales@iec.ch.
SOMMAIRE
AVANT-PROPOS . 3
1 Domaine d'application . 5
2 Références normatives . 5
3 Termes et définitions. 5
4 Modèle de diagramme d'états . 5
4.1 Généralités . 5
4.2 Exemples de diagrammes d'états finis . 6
4.2.1 Diagramme d'états simple . 6
4.2.2 Diagramme d'états contenant des sous-états . 7
4.3 Définition de diagramme d'états . 7
4.4 Représentation des diagrammes d'états dans l'AddressSpace . 8
4.4.1 Vue d'ensemble . 8
4.4.2 StateMachineType . 9
4.4.3 StateVariableType . 10
4.4.4 TransitionVariableType . 11
4.4.5 FiniteStateMachineType . 12
4.4.6 FiniteStateVariableType . 15
4.4.7 FiniteTransitionVariableType . 16
4.4.8 StateType . 16
4.4.9 InitialStateType. 17
4.4.10 TransitionType . 18
4.4.11 FromState . 19
4.4.12 ToState . 19
4.4.13 HasCause . 20
4.4.14 HasEffect . 21
4.4.15 HasSubStateMachine . 21
4.4.16 TransitionEventType . 22
4.4.17 AuditUpdateStateEventType . 22
4.4.18 Restrictions spéciales sur le sous-typage des StateMachines . 23
4.4.19 StatusCodes spécifiques pour StateMachines . 24
4.5 Exemples de StateMachines dans l'AddressSpace . 24
4.5.1 StateMachineType utilisant la relation d'héritage . 24
4.5.2 StateMachineType avec un SubStateMachine utilisant la relation
d'héritage . 26
4.5.3 StateMachineType utilisant la hiérarchie d'appartenance . 27
4.5.4 Exemple de StateMachine ayant une Transition vers un
SubStateMachine . 28
4.5.5 Exemple d'un StateMachine ajoutant un SubStateMachine sur un sous-type . 29
4.6 Extensions de StateMachine pour ChoiceStates et Sentinelles . 32
4.6.1 Vue d'ensemble . 32
4.6.2 ChoiceStateType . 32
4.6.3 HasGuard . 33
4.6.4 GuardVariableType . 33
4.6.5 ExpressionGuardVariableType . 34
4.6.6 ElseGuardVariableType . 35
4.7 Exemple de StateMachine utilisant un ChoiceState et des Sentinelles. 35
Bibliographie . 37
Figure 1 – Exemple d'un diagramme d'états simple . 6
Figure 2 – Exemple d'un diagramme d'états ayant un sous-diagramme . 7
Figure 3 – Modèle d'information StateMachine . 9
Figure 4 – Exemple d'un type de FiniteStateMachine . 14
Figure 5 – Exemple d'une instance de FiniteStateMachine . 15
Figure 6 – Exemple d'un État initial d'un sous-diagramme. 18
Figure 7 – Exemple d'un StateMachineType utilisant la relation d'héritage. 24
Figure 8 – Exemple d'un StateMachineType avec un SubStateMachine utilisant la
relation d'héritage . 26
Figure 9 – Exemple d'un StateMachineType utilisant la hiérarchie d'appartenance . 27
Figure 10 – Exemple d'un StateMachine avec des Transitions partant de sous-états . 28
Figure 11 – Exemple d'un StateMachineType avec une Transition vers un
SubStateMachine . 29
Figure 12 – Exemple d'un StateMachine avec deux États . 30
Figure 13 – Exemple de StateMachine étendu avec deux Sous-états . 30
Figure 14 – Exemple de StateMachine étendu avec deux autres Sous-états . 30
Figure 15 – Exemple d'un StateMachineType ajoutant des SubStateMachines à des
Sous-types . 31
Figure 16 – Exemple de ChoiceState . 32
Figure 17 – Exemple de StateMachine utilisant un ChoiceState et des Sentinelles . 36

Tableau 1 – Définition de StateMachineType . 10
Tableau 2 – Définition de StateVariableType . 11
Tableau 3 – Définition de TransitionVariableType . 12
Tableau 4 – Définition de FiniteStateMachineType . 13
Tableau 5 – Définition de FiniteStateVariableType . 15
Tableau 6 – Définition de FiniteTransitionVariableType . 16
Tableau 7 – Définition de StateType . 17
Tableau 8 – Définition d'InitialStateType . 18
Tableau 9 – Définition de TransitionType . 19
Tableau 10 – ReferenceType FromState . 19
Tableau 11 – ReferenceType ToState . 20
Tableau 12 – ReferenceType HasCause . 20
Tableau 13 – ReferenceType HasEffect . 21
Tableau 14 – ReferenceType HasSubStateMachine . 22
Tableau 15 – TransitionEventType . 22
Tableau 16 – AuditUpdateStateEventType . 23
Tableau 17 – StatusCodes spécifiques pour StateMachines . 24
Tableau 18 – ChoiceStateType . 33
Tableau 19 – ReferenceType HasGuard . 33
Tableau 20 – Définition de GuardVariableType . 34
Tableau 21 – Définition d'ExpressionGuardVariableType . 34
Tableau 22 – Définition d'ElseGuardVariableType . 35

COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE
____________
Architecture unifiée OPC -
Partie 16: Diagrammes d'états
AVANT-PROPOS
1) La Commission Électrotechnique Internationale (IEC) est une organisation mondiale de normalisation composée
de l'ensemble des comités électrotechniques nationaux (Comités nationaux de l'IEC). L'IEC a pour objet de
favoriser la coopération internationale pour toutes les questions de normalisation dans les domaines de
l'électricité et de l'électronique. À cet effet, l'IEC – entre autres activités – publie des Normes internationales,
des Spécifications techniques, des Rapports techniques, des Spécifications accessibles au public (PAS) et des
Guides (ci-après dénommés "Publication(s) de l'IEC"). Leur élaboration est confiée à des comités d'études, aux
travaux desquels tout Comité national intéressé par le sujet traité peut participer. Les organisations
internationales, gouvernementales et non gouvernementales, en liaison avec l'IEC, participent également aux
travaux. L'IEC collabore étroitement avec l'Organisation Internationale de Normalisation (ISO), selon des
conditions fixées par accord entre les deux organisations.
2) Les décisions ou accords officiels de l'IEC concernant les questions techniques représentent, dans la mesure du
possible, un accord international sur les sujets étudiés, étant donné que les Comités nationaux de l'IEC intéressés
sont représentés dans chaque comité d'études.
3) Les Publications de l'IEC se présentent sous la forme de recommandations internationales et sont agréées
comme telles par les Comités nationaux de l'IEC. Tous les efforts raisonnables sont entrepris afin que
l'IEC s'assure de l'exactitude du contenu technique de ses publications; l'IEC ne peut pas être tenue responsable
de l'éventuelle mauvaise utilisation ou interprétation qui en est faite par un quelconque utilisateur final.
4) Dans le but d'encourager l'uniformité internationale, les Comités nationaux de l'IEC s'engagent, dans toute la
mesure possible, à appliquer de façon transparente les Publications de l'IEC dans leurs publications nationales
et régionales. Toutes divergences entre toutes Publications de l'IEC et toutes publications nationales ou
régionales correspondantes doivent être indiquées en termes clairs dans ces dernières.
5) L'IEC elle-même ne fournit aucune attestation de conformité. Des organismes de certification indépendants
fournissent des services d'évaluation de conformité et, dans certains secteurs, accèdent aux marques de
conformité de l'IEC. L'IEC n'est responsable d'aucun des services effectués par les organismes de certification
indépendants.
6) Tous les utilisateurs doivent s'assurer qu'ils sont en possession de la dernière édition de cette publication.
7) Aucune responsabilité ne doit être imputée à l'IEC, à ses administrateurs, employés, auxiliaires ou mandataires,
y compris ses experts particuliers et les membres de ses comités d'études et des Comités nationaux de l'IEC,
pour tout préjudice causé en cas de dommages corporels et matériels, ou de tout autre dommage de quelque
nature que ce soit, directe ou indirecte, ou pour supporter les coûts (y compris les frais de justice) et les dépenses
découlant de la publication ou de l'utilisation de cette Publication de l'IEC ou de toute autre Publication de l'IEC,
ou au crédit qui lui est accordé.
8) L'attention est attirée sur les références normatives citées dans cette publication. L'utilisation de publications
référencées est obligatoire pour une application correcte de la présente publication.
9) L'IEC attire l'attention sur le fait que la mise en application du présent document peut entraîner l'utilisation d'un
ou de plusieurs brevets. L'IEC ne prend pas position quant à la preuve, à la validité et à l'applicabilité de tout
droit de brevet revendiqué à cet égard. À la date de publication du présent document, l'IEC n'avait pas reçu
notification qu'un ou plusieurs brevets pouvaient être nécessaires à sa mise en application. Toutefois, il y a lieu
d'avertir les responsables de la mise en application du présent document que des informations plus récentes
sont susceptibles de figurer dans la base de données de brevets, disponible à l'adresse https://patents.iec.ch.
L'IEC ne saurait être tenue pour responsable de ne pas avoir identifié tout ou partie de tels droits de brevet.
L'IEC 62541-16 a été établie par le sous-comité 65E: Les dispositifs et leur intégration dans les
systèmes de l'entreprise, du comité d'études 65 de l'IEC: Mesure, commande et automation
dans les processus industriels. Il s'agit d'une Norme internationale.
Le texte de cette Norme internationale est issu des documents suivants:
Projet Rapport de vote
65E/1041/CDV 65E/1132/RVC
Le rapport de vote indiqué dans le tableau ci-dessus donne toute information sur le vote ayant
abouti à son approbation.
La langue employée pour l'élaboration de cette Norme internationale est l'anglais.
Ce document a été rédigé selon les Directives ISO/IEC, Partie 2, il a été développé selon les
Directives ISO/IEC, Partie 1 et les Directives ISO/IEC, Supplément IEC, disponibles sous
www.iec.ch/members_experts/refdocs. Les principaux types de documents développés par
l'IEC sont décrits plus en détail sous www.iec.ch/publications.
Dans l'ensemble du présent document et dans les autres parties de la série, certaines
conventions de document sont utilisées:
Le format italique est utilisé pour mettre en évidence un terme défini ou une définition qui
apparaît à l'article "Termes et définitions" dans l'une des parties de la série.
Le format italique est également utilisé pour mettre en évidence le nom d'un paramètre d'entrée
ou de sortie de service, ou le nom d'une structure ou d'un élément de structure habituellement
défini dans les tableaux.
Par ailleurs, les termes et noms en italique sont souvent écrits en camel-case (pratique qui
consiste à joindre, sans espace, les éléments des mots ou expressions composés, la première
lettre de chaque élément étant en majuscule). Par exemple, le terme défini est AddressSpace
et non Espace d'Adressage. Cela permet de mieux comprendre qu'il existe une définition unique
pour AddressSpace, et non deux définitions distinctes pour Espace et pour Adressage.
Une liste de toutes les parties de la série IEC 62541, publiées sous le titre général Architecture
unifiée OPC, se trouve sur le site web de l'IEC.
Le comité a décidé que le contenu de ce document ne sera pas modifié avant la date de stabilité
indiquée sur le site web de l'IEC sous webstore.iec.ch dans les données relatives au document
recherché. À cette date, le document sera
– reconduit,
– supprimé, ou
– révisé.
1 Domaine d'application
La présente partie de l'IEC 62541 définit un Modèle d'information. Le Modèle d'information
décrit l'infrastructure de base pour modéliser les diagrammes d'états.
NOTE Les diagrammes d'états étaient traités dans l'IEC 62541-5:2020, Annexe B. Dans les versions plus récentes
de l'IEC 62541-5, cette Annexe B a été supprimée et remplacée par le présent document
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu'ils constituent, pour tout ou partie
de leur contenu, des exigences du présent document. Pour les références datées, seule
l'édition citée s'applique. Pour les références non datées, la dernière édition du document de
référence s'applique (y compris les éventuels amendements).
IEC 62541-1, Architecture unifiée OPC - Partie 1: Vue d'ensemble et concepts
IEC 62541-3, Architecture unifiée OPC - Partie 3: Modèle d'espace d'adressage
IEC 62541-4, Architecture unifiée OPC - Partie 4: Services
IEC 62541-5, Architecture unifiée OPC - Partie 5: Modèle d'information
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions de l'IEC 62541-1,
l'IEC 62541-3, et l'IEC 62541-5 s'appliquent.
L'ISO et l'IEC tiennent à jour des bases de données terminologiques destinées à être utilisées
en normalisation, consultables aux adresses suivantes:
– IEC Electropedia: disponible à l'adresse https://www.electropedia.org/
– ISO Online browsing platform: disponible à l'adresse https://www.iso.org/obp
4 Modèle de diagramme d'états
4.1 Généralités
Le présent document décrit l'infrastructure de base pour modéliser les diagrammes d'états. Il
définit les ObjectTypes, VariableTypes et ReferenceTypes, et explique comment il convient de
les utiliser.
Les types contenus dans le présent document peuvent être utilisés directement. Cependant, il
n'est pas exigé, mais fortement recommandé, qu'un Serveur utilise ces types pour présenter
ses diagrammes d'états. Les types définis peuvent être sous-typés pour affiner leur
comportement.
Lorsqu'un Serveur présente son diagramme d'états en utilisant les types définis dans le présent
document, il peut fournir une vue simplifiée de son diagramme d'états interne en masquant par
exemple les sous-états ou en plaçant plusieurs états internes dans un état présenté.
Le domaine d'application des diagrammes d'états décrits dans le présent document concerne
la fourniture d'une fondation appropriée pour les diagrammes d'états exigés pour l'IEC 62541-9
et l'IEC 62541-10. Ne sont pas décrites les fonctionnalités plus complexes d'un diagramme
d'états telles que les états parallèles, les bifurcations et unions, les états d'historique, les choix
et jonctions, etc. Cependant, le diagramme d'états de base défini dans le présent document
peut être étendu pour prendre en charge ces concepts.
Les 4.2 à 4.7 décrivent des exemples de diagrammes d'états, définissent des diagrammes
d'états dans le contexte du présent document et définissent la représentation de diagrammes
d'états OPC UA. Enfin, certains exemples sont donnés pour les diagrammes d'états
représentés dans l'OPC UA.
4.2 Exemples de diagrammes d'états finis
4.2.1 Diagramme d'états simple
L'exemple suivant fournit une vue d'ensemble des caractéristiques de base que prennent en
charge les diagrammes d'états définis dans le présent document. Dans le texte ci-dessous est
donné un exemple plus complexe, qui prend également en charge des diagrammes de
sous-états.
La Figure 1 donne une vue d'ensemble sur un diagramme d'états simple. Il contient trois états
"State1", "State2" et "State3". Il existe des transitions de "State1" à "State2", de "State2" à
"State2", etc. Certaines de ces transitions fournissent des informations complémentaires quant
aux causes (ou déclencheurs) de la transition, par exemple l'appel de la "Method1" pour la
transition de "State1" à "State2". L'effet (ou action) de la transition peut aussi être spécifié, par
exemple, la création d'un Événement du type "EventType1" dans la même transition. La
notation utilisée pour identifier la cause consiste à l'énumérer tout simplement sur la transition,
l'effet étant préfixé par un "/". Plusieurs causes ou effets sont séparés par une ",". Toutes les
transitions ne doivent pas avoir de cause ou d'effet, par exemple la transition entre "State2" et
"State3".
Figure 1 – Exemple d'un diagramme d'états simple
Pour des raisons de simplicité, les diagrammes d'états décrits dans le présent document
prennent uniquement en charge les causes sous la forme de Méthodes de spécification qui sont
appelées et les effets sous la forme d'EventTypes des Événements générés. Cependant,
l'infrastructure définie permet d'étendre ce mécanisme afin de prendre en charge différentes
causes et différents effets supplémentaires.
4.2.2 Diagramme d'états contenant des sous-états
La Figure 2 montre un exemple de diagramme d'états où "State6" est un diagramme de
sous-états. Cela signifie que, si le diagramme d'états global est dans l'état State6, cet état peut
être distingué comme étant dans les sous-états "State7" ou "State8". Les diagrammes de
sous-états peuvent être imbriqués, c'est-à-dire que "State7" peut être un autre diagramme de
sous-état.
Figure 2 – Exemple d'un diagramme d'états ayant un sous-diagramme
4.3 Définition de diagramme d'états
L'infrastructure des diagrammes d'états définis dans le présent document traite seulement des
fondamentaux des diagrammes d'états exigés pour l'IEC 62541-9 et l'IEC 62541-10. L'objectif
est de maintenir les fondamentaux simples, mais extensibles.
Pour les diagrammes d'états définis dans le présent document, l'hypothèse admise est que les
diagrammes d'états sont typés et que les instances d'un type ont leurs états et leur sémantique
spécifiés par le type. Pour certains types, cela signifie que les états et les transitions sont fixes.
Pour d'autres types, les états et les transitions peuvent être dynamiques ou inconnus. Un
diagramme d'états où tous les états sont spécifiés explicitement par le type est appelé un
diagramme d'états finis.
Par conséquent, une distinction est faite entre StateMachineType et StateMachine et leurs
sous-types tels que FiniteStateMachineType. Le StateMachineType spécifie une description du
diagramme d'états, c'est-à-dire ses états, transitions, etc. tandis que le StateMachine est une
instance de StateMachineType et contient seulement l'état actuel.
Chaque StateMachine contient des informations relatives à l'état actuel. Si le
StateMachineType a des SubStateMachines, le StateMachine contient aussi des informations
relatives à l'état actuel des SubStateMachines. Les StateMachines qui ont leurs états
complètement définis par le type sont des instances d'un FiniteStateMachineType.
Chaque FiniteStateMachineType à un ou plusieurs États. Pour des raisons de simplicité, il n'est
pas fait de distinction entre des États différents comme les états de départ ou de fin.
Chaque État peut avoir un ou plusieurs SubStateMachines.
Chaque FiniteStateMachineType peut avoir une ou plusieurs Transitions. Une Transition est
orientée et pointe d'un État vers un autre État.
Chaque Transition peut avoir une ou plusieurs Causes. Une Cause conduit un
FiniteStateMachine à passer son État actuel d'une source de Transition vers sa cible. Dans le
présent document, seuls les appels de Méthode sont spécifiés comme étant des Causes de
Transitions. Il n'est pas nécessaire que les Transitions aient une Cause. Une Transition peut
toujours être provoquée par quelque logique interne au serveur qui n'est pas présentée dans
l'AddressSpace.
Chaque Transition peut avoir un ou plusieurs Effets. Un Effet a lieu si la Transition est utilisée
pour modifier l'État d'un StateMachine. Dans le présent document, seule la création
d'Événements est spécifiée comme étant les Effets d'une Transition. Une Transition ne doit pas
présenter d'Effets dans l'AddressSpace.
Bien que le présent document ne spécifie que des concepts simples pour les diagrammes
d'états, l'infrastructure fournie est extensible. Si nécessaire, des États spéciaux peuvent être
définis ainsi que des Causes ou des Effets supplémentaires.
4.4 Représentation des diagrammes d'états dans l'AddressSpace
4.4.1 Vue d'ensemble
Les types définis dans le present document sont représentés à la Figure 3. Le
MyFiniteStateMachineType est un exemple minimal qui montre comment ces Types peuvent
être utilisés pour décrire un StateMachine. Voir l'IEC 62541-9 et l'IEC 62541-10 pour d'autres
exemples de StateMachines.
Figure 3 – Modèle d'information StateMachine
4.4.2 StateMachineType
Le StateMachineType est l'ObjectType de base pour tous les StateMachineTypes. Il définit une
seule Variable qui représente l'état actuel du diagramme. Une instance de cet ObjectType doit
générer un Événement chaque fois qu'il se produit un changement d'état significatif. Le Serveur
décide des changements d'état qui sont significatifs. Les Serveurs doivent utiliser le
ReferenceType GeneratesEvent pour indiquer le ou les Événements qui peuvent être produits
par le StateMachine.
Les sous-types peuvent ajouter des Méthodes qui altèrent l'état du diagramme. L'Attribut
Executable est utilisé pour indiquer si la Méthode est valide ou non en fonction de l'état actuel
du diagramme. La création d'AuditEvents pour les Méthodes est définie dans l'IEC 62541-4. Un
StateMachine n'est pas nécessairement actif. Dans ce cas, les Variables CurrentState et
LastTransition doivent avoir un statut égal à Bad_StateNotActive (voir Tableau 17).
Les sous-types peuvent ajouter des composantes qui sont des instances des
StateMachineTypes. Ces composantes sont réputées être des sous-états du StateMachine. Les
SubStateMachines ne sont actifs que lorsque le diagramme parent est dans un état approprié.
Les Événements produits par des SubStateMachines peuvent être supprimés par le diagramme
parent. Dans certains cas, le diagramme parent produit un seul Événement qui reflète les
changements dans plusieurs SubStateMachines.
Le FiniteStateMachineType est un sous-type de StateMachineType qui fournit un mécanisme
pour définir explicitement les états et les transitions. Il convient qu'un Serveur utilise ce
mécanisme s'il connaît les états possibles et si le diagramme d'états n'est pas trivial. Le
FiniteStateMachineType est défini au 4.4.5.
Le StateMachineType est défini de manière formelle dans le Tableau 1.
Tableau 1 – Définition de StateMachineType
Attribut Valeur
BrowseName StateMachineType
IsAbstract False
Modelling
Références NodeClass BrowseName DataType TypeDefinition
Rule
Sous-type du BaseObjectType défini dans l'IEC 62541-5
Une Référence à ce sous-type n'apparaît pas dans la définition du BaseObjectType.
HasSubtype ObjectType FiniteStateMachineType Défini au 4.4.5
HasComponent Variable CurrentState LocalizedText StateVariableType Mandatory
HasComponent Variable LastTransition LocalizedText TransitionVariableType Optional
Unités de Conformité
Informations de base Instance de diagramme d'états

CurrentState enregistre l'état actuel d'une instance du StateMachineType. CurrentState fournit
un nom interprétable par l'utilisateur pour l'état actuel qui n'est pas nécessairement adapté à
une utilisation dans la logique de commande d'application. Il convient que les applications
utilisent la Propriété Id de CurrentState si elles nécessitent un identificateur unique pour l'état.
LastTransition stocke la dernière transition qui a eu lieu dans une instance du
StateMachineType. LastTransition fournit un nom interprétable par l'utilisateur pour la dernière
transition qui n'est pas nécessairement adaptée à une utilisation dans la logique de commande
d'application. Il convient que les applications utilisent la Propriété Id de LastTransition si elles
nécessitent un identificateur unique pour la transition.
4.4.3 StateVariableType
Le StateVariableType est le VariableType de base pour les Variables qui stockent l'état actuel
d'un StateMachine sous la forme d'un nom interprétable par l'utilisateur.
Le StateVariableType est défini de manière formelle dans le Tableau 2.
Tableau 2 – Définition de StateVariableType
Attribut Valeur
BrowseName StateVariableType
DataType LocalizedText
ValueRank -1 (-1 = Scalaire)
IsAbstract False
Modelling
Références NodeClass BrowseName DataType TypeDefinition
Rule
Sous-type du BaseDataVariableType défini dans l'IEC 62541-5
Une Référence à ce sous-type n'apparaît pas dans la définition du BaseDataVariableType.
HasSubtype VariableType FiniteStateVariableType Défini au 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
Unités de Conformité
Informations de base Instance de diagramme d'états

Id est un nom qui identifie de façon unique l'état actuel dans le StateMachineType. Un sous-type
peut limiter le DataType.
Name est un QualifiedName qui identifie de façon unique l'état actuel du StateMachineType.
Number est un nombre entier qui identifie de façon unique l'état actuel du StateMachineType.
EffectiveDisplayName contient un nom interprétable par l'utilisateur pour l'état actuel du
diagramme d'états après avoir pris en compte l'état de tous les éventuels SubStateMachines.
Il n'est spécifié aucune règle concernant l'état ou le sous-état qu'il convient d'utiliser. Cela est
du ressort du Serveur et dépend de la sémantique du StateMachineType.
Les StateMachines produisent des Événements qui peuvent inclure l'état actuel d'un
StateMachine. Dans ce cas, les Serveurs doivent fournir toutes les Propriétés facultatives du
StateVariableType dans l'Événement, même si elles ne sont pas fournies sur les instances dans
l'AddressSpace.
4.4.4 TransitionVariableType
Le TransitionVariableType est le VariableType de base pour les Variables qui stockent une
Transition qui a eu lieu dans un StateMachine sous la forme d'un nom interprétable par
l'utilisateur.
Le SourceTimestamp pour la valeur spécifie le moment où la Transition a eu lieu. Cette valeur
peut également être présentée avec la Propriété TransitionTime.
Le TransitionVariableType est défini de manière formelle dans le Tableau 3.
Tableau 3 – Définition de TransitionVariableType
Attribut Valeur
BrowseName TransitionVariableType
DataType LocalizedText
ValueRank -1 (-1 = Scalaire)
IsAbstract False
Modelling
Références NodeClass BrowseName DataType TypeDefinition
Rule
Sous-type du BaseDataVariableType défini dans l'IEC 62541-5
Une Référence à ce sous-type n'apparaît pas dans la définition du BaseDataVariableType.
HasSubtype VariableType FiniteTransitionVariable- Défini au 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
Unités de Conformité
Informations de base Instance de diagramme d'états

Id est un nom qui identifie de façon unique une Transition dans le StateMachineType. Un sous-
type peut limiter le DataType.
Name est un QualifiedName qui identifie de façon unique une transition du StateMachineType.
Number est un nombre entier qui identifie de façon unique une transition du StateMachineType.
TransitionTime spécifie le moment où la transition a eu lieu.
EffectiveTransitionTime spécifie le moment auquel l'état actuel ou l'un de ses sous-états a été
saisi. Si, par exemple, un StateA est actif et que, tout en étant actif, il commute plusieurs fois
entre ses sous-états SubA et SubB, le TransitionTime reste au moment où StateA est devenu
actif tandis que l'EffectiveTransitionTime varie à chaque changement de sous-état.
4.4.5 FiniteStateMachineType
Le FiniteStateMachineType est l'ObjectType de base pour les StateMachines qui définissent
explicitement les États et Transitions possibles. Dès que les États et les Transitions ont été
définis, les sous-types ne doivent pas ajouter de nouveaux États et Transitions (voir 4.4.18).
Les Sous-types peuvent ajouter des causes ou des effets.
Les États du diagramme sont représentés avec des instances de l'ObjectType StateType.
Chaque État doit avoir un BrowseName qui est unique dans le StateMachine et doit avoir un
StateNumber qui doit aussi être unique parmi tous les États définis dans le StateMachine.
Garder à l'esprit que les États dans un SubStateMachine peuvent avoir le même StateNumber
ou BrowseName que les États dans le diagramme parent. Un sous-type concret de
FiniteStateMachineType doit définir au moins un État.
Un StateMachine peut définir un seul État qui est une instance d'InitialStateType. Cet État est
l'État dans lequel entre le diagramme lorsqu'il est activé.
Les Transitions qui se produisent sont représentées avec des instances du TransitionType.
Chaque Transition doit avoir un BrowseName qui est unique dans le StateMachine et peut avoir
un TransitionNumber qui doit aussi être unique parmi toutes les Transitions définies dans le
StateMachine.
L'État initial pour une Transition est un Objet StateType qui est la cible d'une Référence
FromState. L'État final pour une Transition est un Objet StateType qui est la cible d'une
Référence ToState. Les Références FromState et ToState doivent toujours être spécifiées.
Une Transition peut produire un Événement. L'Événement est indiqué par une Référence
HasEffect à un sous-type de BaseEventType. Le StateMachineType doit avoir des Références
GeneratesEvent aux cibles d'une Référence HasEffect pour chacune de ses Transitions.
Un FiniteStateMachineType peut définir des Méthodes faisant qu'une transition a lieu. Ces
Méthodes sont des cibles des Références HasCause pour chacune des Transitions qui peuvent
être enclenchées par la Méthode. L'Attribut Executable pour une Méthode est utilisé pour
indiquer si l'État actuel du diagramme permet ou non d'appeler la Méthode.
Un FiniteStateMachineType peut avoir des diagrammes de sous-états qui sont représentés
comme des instances d'ObjectTypes StateMachineType. Chaque État doit avoir une Référence
HasSubStateMachine à l'Objet StateMachineType qui représente les États enfants. Le
SubStateMachine n'est pas actif si l'État parent n'est pas actif. Dans ce cas, les Variables
CurrentState et LastTransition du SubStateMachine doivent avoir un statut égal à
Bad_StateNotActive (voir Tableau 17).
Le FiniteStateMachineType est défini de manière formelle dans le Tableau 4.
Tableau 4 – Définition de FiniteStateMachineType
Attribut Valeur
BrowseName FiniteStateMachineType
IsAbstract True
Modelling
Références NodeClass BrowseName DataType TypeDefinition
Rule
Sous-type du StateMachineType défini au 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
Unités de Conformité
Informations de base Instance de diagramme d'états finis
Informations de base États et transitions disponibles

Dans certains Serveurs, l'instance d'une StateMachine peut restreindre les États et/ou les
Transitions disponibles. Ces restrictions peuvent résulter de la conception interne de l'instance.
Par exemple, la StateMachine de l'alarme de limite d'un instrument qui prend en charge
uniquement Hi et HiHi et ne peut pas produire un Low ou un LowLow. L'instance d'une
StateMachine peut également modifier de manière dynamique les Transitions et/ou les États
disponibles en fonction de son mode de fonctionnement. Par exemple, lorsqu'une pièce
d'équipement est en mode maintenance, les États disponibles peuvent être limités à un sous-
ensemble des États disponibles pendant le fonctionnement normal.
La Variable AvailableStates fournit une liste de NodeId des États présents dans l'instance de
la StateMachine. La liste peut évoluer pendant le fonctionnement du Serveur.
La Variable AvailableTransitions fournit une liste de NodeId des Transitions présentes dans
l'instance de la StateMachine. La liste peut évoluer pendant le fonctionnement du Serveur.
Un exemple d'un type de FiniteStateMachine est représenté à la Figure 4.

Figure 4 – Exemple d'un type de FiniteStateMachine
Un exemple d'instance du type est représenté à la Figure 5. Dans cet exemple, les États {7,8,9}
et les Transitions {G,H,I,J} ne sont pas disponibles dans cette instance.
Figure 5 – Exemple d'une instance de FiniteStateMachine
4.4.6 FiniteStateVariableType
Le FiniteStateVariableType est un sous-type de StateVariableType et est utilisé pour stocker
l'état actuel d'un FiniteStateMachine sous la forme d'un nom interprétable par l'utilisateur.
Le FiniteStateVariableType est défini de manière formelle dans le Tableau 5.
Tableau 5 – Définition de FiniteStateVariableType
Attribut Valeur
BrowseName FiniteStateVariableType
DataType LocalizedText
ValueRank -1 (-1 = Scalaire)
IsAbstract False
Modelling
Références NodeClass BrowseName DataType TypeDefinition
Rule
Sous-type du StateVariableType défini au 4.4.3
HasProperty Variable Id NodeId PropertyType Mandatory
Unités de Conformité
Informations de base Instance de diagramme d'états finis

Id est hérité du StateVariableType et neutralisé pour refléter le DataType exigé. Cette valeur
doit être le NodeId de l'un des Objets State du FiniteStateMachineType. Si le
FiniteStateMachine comporte un sous-type, il doit s'agir du NodeId de l'État défini dans le
supertype, c'est-à-dire où l'État est défini pour la première fois dans la hiérarchie de types.
La Propriété Name est héritée de StateVariableType. Sa Valeur doit être le BrowseName de
l'un des Objets State du FiniteStateMachineType.
La Propriété Number est héritée de StateVariableType. Sa Valeur doit être le StateNumber de
l'un des Objets State du FiniteStateMachineType.
4.4.7 FiniteTransitionVariableType
Le FiniteTransitionVariableType est un sous-type de TransitionVariableType et est utilisé pour
stocker une Transition qui a eu lieu dans un FiniteStateMachine sous la forme d'un nom
interprétable par l'utilisateur.
Le FiniteTransitionVariableType est défini de manière formelle dans le Tableau 6.
Tableau 6 – Définition de FiniteTransitionVariableType
Attribut Valeur
BrowseName FiniteTransitionVariableType
DataType LocalizedText
ValueRank -1 (-1 = Scalaire)
IsAbstract False
Modelling
Références NodeClass BrowseName DataType TypeDefinition
Rule
Sous-type du TransitionVariableType défini au 4.4.4
Une Référence à ce sous-type n'apparaît pas dans la définition du BaseDataVariableType.
HasProperty Variable Id NodeId PropertyType Mandatory
Unités de Conformité
Informations de base Instance de diagramme d'états finis

Id est hérité du TransitionVariableType et neutralisé pour refléter le DataType exigé. Cette
valeur doit être le NodeId de l'un des Objets Transition du FiniteStateMachineType. Si le
FiniteStateMachine comporte un sous-type, il doit s'agir du NodeId de la Transition définie dans
le supertype, c'est-à-dire où la Transition est définie pour la première fois dans la hiérarchie de
types.
La Propriété Name est héritée du TransitionVariableType. Sa Valeur doit être le BrowseName
de l'un des Objets Transition du FiniteStateMachineType.
La Propriété Number est héritée du TransitionVariableType. Sa Valeur doit être le
TransitionNumber de l'un des Objets Transition du FiniteStateMachineType.
4.4.8 StateType
Les États d'un FiniteStateMachine sont représentés comme des Objets du StateType. Chaque
Objet du StateType ou de l'un de ses sous-types est référencé à partir de l'ObjectType
FiniteStateMachineType ou de l'un de ses sous-types au moyen d'une Référence
HasComponent ou d'un sous-type de HasComponent et ne doit pas comporter de
ModellingRule, dans la mesure où celles-ci ne s'appl
...

IEC 62541-16 ®
Edition 1.0 2025-12
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
OPC unified architecture -
Part 16: State Machines
Architecture unifiée OPC -
Partie 16: Diagrammes d'états
ICS 25.040  ISBN 978-2-8327-0834-7

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or
by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either
IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC copyright
or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local
IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et
les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
The advanced search enables to find IEC publications by a publications previews, graphical symbols and the glossary.
variety of criteria (reference number, text, technical With a subscription you will always have access to up to date
committee, …). It also gives information on projects, content tailored to your needs.
replaced and withdrawn publications.
Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
once a month by email. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer
Service Centre: sales@iec.ch.
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.

Recherche de publications IEC -  IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Découvrez notre puissant moteur de recherche et consultez
La recherche avancée permet de trouver des publications gratuitement tous les aperçus des publications, symboles
IEC en utilisant différents critères (numéro de référence, graphiques et le glossaire. Avec un abonnement, vous aurez
texte, comité d’études, …). Elle donne aussi des toujours accès à un contenu à jour adapté à vos besoins.
informations sur les projets et les publications remplacées
ou retirées. Electropedia - www.electropedia.org

Le premier dictionnaire d'électrotechnologie en ligne au
IEC Just Published - webstore.iec.ch/justpublished monde, avec plus de 22 500 articles terminologiques en
Restez informé sur les nouvelles publications IEC. Just anglais et en français, ainsi que les termes équivalents
Published détaille les nouvelles publications parues. dans 25 langues additionnelles. Egalement appelé
Disponible en ligne et une fois par mois par email. Vocabulaire Electrotechnique International (IEV) en ligne.

Service Clients - webstore.iec.ch/csc
Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-
nous: sales@iec.ch.
CONTENTS
FOREWORD . 3
1 Scope . 5
2 Normative references . 5
3 Terms 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

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

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.
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.
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.
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.
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.
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
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.
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.
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
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.
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.
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.
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 applied on the instances.
The StateType is formally defined in Table 7.
Table 7 – StateType definition
Attribute Value
BrowseName StateType
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.
HasProperty Variable StateNumber UInt32 PropertyType Mandatory
HasSubtype ObjectType InitialStateType Defined in 4.4.9
HasSubtype ObjectType ChoiceStateType Defined in 4.6.2
Conformance Units
Base Info Finite State Machine Instance

4.4.9 InitialStateType
The InitialStateType is a subtype of the StateType and is formally defined in Table 8. An Object
of the InitialStateType represents the State that a FiniteStateMachine enters when it is
activated. Each FiniteStateMachine can have at most one State of type InitialStateType, but a
FiniteStateMachine does not have to have a State of this type.
A SubStateMachine goes into its initial state whenever the parent state is entered. However, a
state machine can define a transition that goes directly to a state of the SubStateMachine. In
this case the SubStateMachine goes into that State instead of the initial Sta
...