Comment programmer une logique de machine à états dans un automate pour un moteur triphasé

Pour programmer une logique de machine à états dans un automate (PLC), les ingénieurs divisent la séquence d'une machine en états mutuellement exclusifs et effectuent des transitions explicites entre eux. Pour un moteur triphasé, cela signifie généralement utiliser des états basés sur des entiers (Arrêt, Démarrage, Marche, Arrêt contrôlé et Défaut), qui sont plus faciles à valider, à dépanner et à fiabiliser que la logique à maintien (seal-in) imbriquée.

La logique à maintien imbriquée n'est pas « suffisante » simplement parce qu'elle fonctionne lors du premier test. Dans le contrôle séquentiel, une logique booléenne qui semble propre sur un écran statique peut générer des conditions de course, des chemins de récupération ambigus et un comportement dépendant du cycle de balayage (scan) lorsque les entrées fluctuent ou que des défauts surviennent en cours de séquence.

Lors des tests internes du préréglage pour moteur triphasé d'Ampergon Vallis dans OLLA Lab, le remplacement des contacts de maintien imbriqués par une machine à états finis explicite basée sur des entiers a réduit les événements de défaut liés aux conditions de course de 87 % lors d'essais d'arrêt anormal simulés [Méthodologie : n=30 exécutions de simulation de la même tâche de moteur triphasé, comparateur de référence à maintien imbriqué, fenêtre de test février-mars 2026]. Cela soutient une affirmation bornée concernant un préréglage de formation interne sous injection de défauts simulés. Cela n'établit pas un taux de réduction des défauts universel pour toutes les architectures d'automates, usines ou applications moteurs.

Cette distinction est importante. Les échecs de mise en service naissent généralement dans les conditions limites, et non dans le fonctionnement nominal.

La logique de machine à états finis est supérieure pour le contrôle séquentiel car elle rend le comportement de la machine explicite, mutuellement exclusif et déterministe. Une FSM correctement construite permet à l'automate d'évaluer les règles de l'état actuel, puis de ne transiter que lorsque les conditions définies sont remplies.

Les échelons de maintien imbriqués font l'inverse. Ils dispersent souvent la mémoire de la séquence à travers de multiples bits, permissifs, verrous et interverrouillages qui interagissent indirectement. Le résultat est une logique qui peut fonctionner, mais seulement jusqu'à ce que le timing, une perte de retour d'information ou un arrêt anormal expose le couplage caché. La syntaxe n'est pas la même chose que la déployabilité.

La norme IEC 61131-3 n'impose pas un modèle séquentiel universel, mais son modèle d'organisation de programme soutient fortement une logique de contrôle structurée, lisible et maintenable pour le séquençage basé sur les états dans les applications d'automates (IEC, 2013). En pratique, les FSM sont devenues une architecture courante pour les séquences de machines car elles sont plus faciles à raisonner, à tester et à rétablir après des défauts.

Une définition opérationnelle utile est la suivante :

- Machine à états finis en logique à contacts (ladder) : une architecture de contrôle dans laquelle une variable d'état représente le mode actuel de la machine, un seul état valide est actif à la fois, et les transitions se produisent par des conditions explicites qui assignent l'état suivant.

Cette dernière clause est essentielle. Si la transition n'est pas explicite, la machine repose sur des effets secondaires.

Logique « oignon » vs Architecture de machine à états

| Facteur d'ingénierie | Maintien imbriqué / « Logique oignon » | Machine à états finis | |---|---|---| | Mémoire de séquence active | Distribuée entre bits et verrous | Centralisée dans une variable d'état | | Comportement du cycle de balayage | Peut devenir sensible à l'ordre et ambigu | Déterministe lorsque les transitions sont explicites | | Récupération sur défaut | Souvent déduite de plusieurs conditions | État de défaut explicite, ex. `99` | | Dépannage | Tracer de nombreux bits en interaction | Lire d'abord l'entier de l'état actuel | | Extension de séquence | Fragile à mesure que les branches croissent | Plus facile d'insérer des états intermédiaires | | Validation en simulation | Difficile d'isoler le chemin de défaillance | Tests clairs transition par transition |

Les ingénieurs en contrôle expérimentés rejettent la logique « oignon » pour la même raison qu'ils rejettent le câblage non étiqueté : le système peut fonctionner, mais personne ne devrait avoir à deviner pourquoi.

Une séquence de moteur triphasé nécessite plus qu'un bit de marche et d'arrêt, car l'équipement réel présente un comportement de transition, des temps de réponse et une gestion des défauts. Même un simple démarreur moteur nécessite généralement un traitement explicite des permissifs, de la confirmation de démarrage, du comportement à l'arrêt et de la récupération après déclenchement.

Une FSM pratique pour un moteur triphasé utilise généralement ces états :

1. État 0 — Arrêt / Prêt Le moteur est hors tension. Les permissifs requis sont sains. La séquence attend une commande de démarrage valide.
2. État 10 — Démarrage La sortie de démarrage a été émise. La logique attend le retour d'information attendu, tel qu'un contact auxiliaire, un état de marche, une confirmation de vitesse ou une fenêtre de démarrage temporisée.
3. État 20 — Marche Le moteur est en fonctionnement stable. La logique continue de surveiller les commandes d'arrêt, les surcharges, la perte de permissifs et les retours d'information anormaux.
4. État 30 — Arrêt contrôlé Une commande d'arrêt ou un arrêt contrôlé a été initié. La logique attend la confirmation de la mise hors tension, le retour de vitesse nulle ou la fin de la temporisation.
5. État 99 — Défaut Un déclenchement, une preuve d'échec, une surcharge ou une condition de séquence invalide s'est produit. Les sorties sont pilotées vers la réponse de sécurité définie, et la logique de réinitialisation est gérée explicitement.

Utiliser des incréments de 10 est une habitude pratique car cela laisse de la place pour l'insertion ultérieure d'états tels que `15 = Vérification démarrage` ou `25 = Confirmation arrêt par inertie` sans renuméroter toute la séquence.

Pourquoi les états de transition sont importants dans le contrôle moteur réel

Les états de transition existent parce que les moteurs interagissent avec la réalité électrique et mécanique, et non seulement avec des symboles ladder. Selon l'application, la séquence de contrôle peut devoir prendre en compte :

• le temps d'enclenchement du contacteur
• le temps de transfert étoile-triangle
• l'accélération et la décélération du variateur (VFD)
• le retour de preuve des contacts auxiliaires
• la perte de permissifs pendant le fonctionnement
• les déclenchements de relais de surcharge
• les interverrouillages de processus en aval
• la confirmation de vitesse nulle ou d'arrêt

C'est aussi là que « Simulation-Ready » nécessite une définition précise.

- Simulation-Ready : capable de prouver, d'observer, de diagnostiquer et de durcir la logique de contrôle contre un comportement de processus réaliste avant qu'elle n'atteigne un processus réel.

Cela signifie plus que d'écrire un échelon qui compile. Cela signifie valider si l'état ladder, l'état des E/S et l'état de l'équipement simulé restent cohérents dans des conditions normales et anormales.

Une FSM basée sur le ladder est construite en lisant l'état actuel avec un comparateur et en écrivant l'état suivant avec un transfert explicite (MOV). Dans OLLA Lab, ce travail s'effectue dans l'éditeur ladder, le panneau des variables et le mode simulation.

OLLA Lab doit être compris ici comme un environnement de validation et de répétition borné. Il est utile car il permet aux ingénieurs de pratiquer des comportements de mise en service à haut risque tels que la validation logique, l'observation des E/S, l'injection de défauts et la révision sans utiliser d'équipement réel comme aide pédagogique.

### Étape 1 : Définir l'entier d'état

Créez une étiquette (tag) telle que :

- `Motor_State` : `INT`

Cet entier est la source unique de vérité pour l'état de séquence actuel de la machine.

Les étiquettes complémentaires recommandées incluent :

• `Start_PB`
• `Stop_PB`
• `OL_Trip`
• `Aux_Run_Proof`
• `Reset_PB`
• `Motor_Output`
• `Start_Timer.DN`
• `Stop_Timer.DN`

### Étape 2 : Construire la transition Arrêt vers Démarrage

La première transition déplace généralement le moteur de l'état prêt à l'état de démarrage lorsque les permissifs et une demande de démarrage sont présents.

Concept de logique exemple :

• Si `Motor_State = 0`
• et `Start_PB = TRUE`
• et aucun déclenchement n'est actif
• et les permissifs requis sont sains
• alors `MOV 10` dans `Motor_State`

C'est le modèle de base :

• `EQU(Motor_State, 0)`
• `XIC(Start_PB)`
• `XIO(OL_Trip)`
• `XIC(Permissive_OK)`
• `MOV(10, Motor_State)`

### Étape 3 : Construire la transition Démarrage vers Marche

L'état de démarrage doit confirmer que le moteur a réellement atteint la condition attendue. Cette confirmation peut être un contact auxiliaire, un retour de marche, une preuve de débit, une preuve de rotation ou une condition de temporisation selon l'application.

Concept de logique exemple :

• Si `Motor_State = 10`
• et `Aux_Run_Proof = TRUE`
• alors `MOV 20` dans `Motor_State`

Si la preuve n'est pas reçue dans le temps imparti, passez plutôt à l'état de défaut.

• Si `Motor_State = 10`
• et `Start_Timer.DN = TRUE`
• et `Aux_Run_Proof = FALSE`
• alors `MOV 99` dans `Motor_State`

### Étape 4 : Construire la transition Marche vers Arrêt

L'état de marche doit surveiller à la fois les arrêts commandés et les conditions anormales.

Concept de logique exemple :

• Si `Motor_State = 20`
• et `Stop_PB = TRUE`
• alors `MOV 30` dans `Motor_State`

Incluez également la gestion des déclenchements :

• Si `Motor_State = 20`
• et `OL_Trip = TRUE`
• alors `MOV 99` dans `Motor_State`

### Étape 5 : Construire la transition Arrêt vers Arrêt (0)

L'état d'arrêt doit attendre que le moteur atteigne la condition d'arrêt attendue.

Concept de logique exemple :

• Si `Motor_State = 30`
• et la confirmation d'arrêt est vraie
• alors `MOV 0` dans `Motor_State`

Lorsqu'aucune preuve physique d'arrêt n'existe, une temporisation bornée peut être utilisée, mais cela doit être un choix de conception conscient plutôt qu'une supposition déguisée en certitude.

### Étape 6 : Construire l'état de défaut explicite

L'état de défaut doit mettre les sorties hors tension et nécessiter un chemin de réinitialisation défini. Dans de nombreuses applications, cela signifie aucun redémarrage automatique après une surcharge ou une preuve échouée, sauf si la philosophie de contrôle l'autorise explicitement.

Concept de logique exemple :

• Si `Motor_State = 99`
• forcer `Motor_Output = FALSE`
• exiger `Reset_PB = TRUE`
• exiger que le déclenchement soit effacé
• alors `MOV 0` dans `Motor_State`

Résumé du modèle ladder

Un modèle d'échelon FSM propre dans OLLA Lab suit généralement cette séquence :

• `EQU` pour identifier l'état actuel
• une ou plusieurs conditions `XIC` / `XIO` pour valider la transition
• `MOV` pour écrire l'état suivant

Exemple de modèle ladder :

• `EQU Motor_State 10` et `XIC Aux_Run_Proof` alors `MOV 20 -> Motor_State`
• `EQU Motor_State 10` et `XIO Aux_Run_Proof` et `XIC Start_Timer.DN` alors `MOV 99 -> Motor_State`

Texte alternatif de l'image : Capture d'écran de l'éditeur de logique ladder d'OLLA Lab montrant un échelon de machine à états finis où un bloc EQU vérifie si Motor_State est égal à 10, une condition d'entrée vérifie Aux_Run_Proof, et un bloc MOV fait passer Motor_State à 20.

Les sorties doivent être dérivées de l'état actif, et non utilisées comme mémoire cachée pour la séquence. Cette distinction est facile à manquer et coûteuse à ignorer.

Un modèle courant est :

• mettre `Motor_Output` sous tension quand `Motor_State = 10` ou `Motor_State = 20`
• mettre hors tension dans `0`, `30` et `99` sauf si la philosophie d'arrêt nécessite un maintien contrôlé

Cela vous donne une relation directe entre l'intention de la séquence et la sortie commandée. Cela rend également la simulation et le dépannage plus propres car la sortie devient une conséquence de l'état, et non une seconde machine à états non documentée.

Exemple de logique de sortie

• Si `Motor_State = 10` OU `Motor_State = 20`
• alors `Motor_Output = TRUE`

• Si `Motor_State = 0`, `30`, ou `99`
• alors `Motor_Output = FALSE`

Pour des systèmes moteurs plus complexes, tels que les démarreurs inverseurs, les transitions étoile-triangle ou les arrangements de dérivation VFD, chaque commande d'actionneur doit toujours rester dérivée de l'état et interverrouillée explicitement.

La défaillance FSM la plus courante est un état bloqué. Un état bloqué se produit lorsque la machine entre dans un état valide mais ne satisfait jamais les conditions requises pour en sortir.

C'est pourquoi la simulation est importante. Elle vous permet d'observer la causalité avant que le matériel, la mécanique et la pression du calendrier ne compliquent le diagnostic.

Dans OLLA Lab, le dépannage d'une FSM doit suivre une séquence simple :

1. Lire d'abord l'entier de l'état actuel Vérifiez `Motor_State` dans le panneau des variables. Ne commencez pas par deviner quel échelon semble incorrect.
2. Vérifier la condition de transition attendue Si le moteur est dans `State 10`, confirmez si `Aux_Run_Proof` change réellement, si la temporisation fonctionne et si les permissifs restent vrais.
3. Vérifier l'état ladder par rapport à l'état de l'équipement simulé Le ladder peut commander une sortie moteur, mais l'équipement simulé peut toujours montrer une preuve échouée, une réponse retardée ou un comportement défectueux.
4. Injecter un défaut délibérément Basculez `OL_Trip` pendant `State 20` et confirmez que la séquence passe immédiatement à `State 99`.
5. Vérifier la réponse de sécurité Confirmez que les sorties moteur sont mises hors tension comme requis et que la machine ne peut pas reprendre son fonctionnement tant que les conditions de réinitialisation ne sont pas remplies.

C'est là qu'OLLA Lab devient opérationnellement utile. Il permet à l'apprenant de comparer l'entier d'état de contrôle, les conditions d'E/S et le comportement de l'équipement au même endroit, ce qui reflète le travail que font les ingénieurs de mise en service sous pression.

Un test pratique d'injection de défaut

Utilisez ce cas de test borné :

• Commencer à partir de `State 0`
• Émettre une commande de démarrage valide
• Confirmer la transition vers `State 10`
• Confirmer le retour de preuve et la transition vers `State 20`
• Forcer `OL_Trip = TRUE`
• Vérifier la transition immédiate vers `State 99`
• Vérifier `Motor_Output = FALSE`
• Effacer le déclenchement et émettre une réinitialisation
• Vérifier la transition de retour à `State 0`

Si l'une de ces étapes échoue, le problème n'est plus abstrait. Vous avez maintenant un cas de défaut reproductible.

La validation par jumeau numérique, dans cet article, signifie tester la logique ladder contre un modèle de machine simulé réaliste afin que le comportement de la séquence puisse être observé dans des conditions normales et anormales avant le déploiement. Cela ne signifie pas que la simulation est un substitut légal à l'acceptation sur site, à la vérification de la sécurité fonctionnelle ou à la signature de mise en service.

Cette limite est importante. Un jumeau numérique peut améliorer la validation de la séquence, le réalisme de la formation et la répétition des défauts, mais il n'élimine pas le besoin d'examen spécifique au site, de vérification des dispositifs et d'activités formelles du cycle de vie de sécurité selon des normes telles que l'IEC 61508 le cas échéant (IEC, 2010 ; exida, 2024).

Dans OLLA Lab, la validation par jumeau numérique est opérationnellement utile lorsque l'ingénieur peut faire tout ce qui suit :

• comparer l'état ladder au comportement de l'équipement simulé
• observer si les transitions d'E/S se produisent comme prévu
• injecter des défauts et vérifier la réponse à l'état sûr
• réviser la logique après une défaillance
• relancer le même scénario pour confirmer la correction

C'est la différence entre la pratique de la syntaxe et la répétition de la mise en service.

Une galerie de captures d'écran n'est pas une preuve d'ingénierie. Ce n'est qu'un enregistrement partiel.

Si vous voulez démontrer une réelle compétence en contrôle, construisez un corpus de preuves compact en utilisant cette structure :

1. Description du système Définissez la machine ou l'unité de processus, son objectif et les E/S pertinentes.
2. Définition opérationnelle du comportement correct Indiquez ce que la séquence doit faire, quel retour d'information elle doit recevoir et ce qui constitue une réponse de sécurité valide.
3. Logique ladder et état de l'équipement simulé Montrez la logique d'état, la logique de sortie et le comportement simulé correspondant.
4. Le cas de défaut injecté Documentez la condition anormale que vous avez introduite, telle qu'un déclenchement par surcharge, une preuve de démarrage échouée ou une perte de permissif.
5. La révision effectuée Expliquez quelle logique a changé et pourquoi.
6. Leçons apprises Enregistrez ce que la défaillance a révélé sur la conception de la séquence, les hypothèses ou les interverrouillages manquants.

Cette structure est plus crédible car elle montre le raisonnement, la gestion des défaillances et la discipline de révision. Un échelon propre ne montre pas à lui seul si la logique survit à des conditions réalistes.

Le contrôle séquentiel structuré, la validation basée sur la simulation et les tests conscients des défauts sont bien alignés avec les pratiques d'ingénierie établies, bien que la mise en œuvre exacte varie selon le secteur et la classe de risque.

Les bases pertinentes incluent :

• IEC 61131-3 pour les langages de programmation d'automates et les principes de mise en œuvre du contrôle structuré (IEC, 2013)
• IEC 61508 pour la réflexion sur le cycle de vie de la sécurité fonctionnelle, en particulier là où les conditions anormales et le comportement à l'état sûr sont importants (IEC, 2010)
• Conseils d'exida sur la discipline du cycle de vie de la sécurité, la rigueur de la vérification et la différence entre l'intention logique et le comportement validé dans les systèmes industriels (exida, 2024)
• la littérature de recherche sur la simulation industrielle, les jumeaux numériques et les environnements de formation immersifs montrant que les environnements simulés peuvent améliorer la compréhension procédurale, la répétition des défauts et l'apprentissage au niveau du système lorsqu'ils sont liés à une performance de tâche observable plutôt qu'à la nouveauté seule (Tao et al., 2019 ; Jones et al., 2023 ; Villalonga et al., 2021)

La conclusion prudente n'est pas que la simulation remplace le travail sur site. C'est que la simulation peut déplacer l'apprentissage coûteux vers l'amont, là où les erreurs sont moins chères et plus visibles.

Expert en automatisation industrielle et systèmes de contrôle, spécialisé dans l'architecture de machines à états finis et la validation par simulation.

Cet article a été vérifié pour sa conformité avec les principes de la norme IEC 61131-3 et les meilleures pratiques de simulation industrielle.

- IEC 61131-3: Automates programmables — Partie 3 - Aperçu de la norme de sécurité fonctionnelle IEC 61508 - Profil de fabrication intelligente du NIST - IEEE Access: Technologies habilitantes pour les jumeaux numériques (DOI)