Comment remplacer la logique « en oignon » fragile par des machines à états API

Pour remplacer la logique « en oignon » fragile dans les programmes API, les ingénieurs doivent utiliser des machines à états finis explicites. Une architecture de machine à états peut réduire l'ambiguïté de l'ordre de balayage, isoler la gestion des défauts et rendre les tests de conditions anormales observables en simulation avant que la logique n'atteigne un processus réel.

Une idée fausse courante est que la logique à contacts (Ladder) devient « avancée » lorsqu'elle devient dense. En pratique, la densité n'est souvent que de l'ambiguïté portant un casque de chantier. Les machines ne tombent pas en panne parce qu'un barreau semblait sophistiqué ; elles tombent en panne parce que la séquence n'était pas déterministe lorsqu'une entrée réelle a changé au mauvais moment.

Lors d'une récente analyse comparative interne de 200 exercices de séquences de mélange soumis par des utilisateurs dans OLLA Lab, 82 % des programmes à « logique en oignon » profondément imbriqués sont entrés dans un blocage de séquence irrécupérable lorsqu'ils ont été soumis à un événement de perte de capteur intermittente de 100 ms, tandis que les versions à états explicites refactorisées ont récupéré de manière déterministe dans 100 % de ces mêmes tests de scénario [Méthodologie : n=200 tâches de séquence de mélange soumises, comparateur = implémentation originale à verrous imbriqués versus implémentation à états explicites refactorisée, fenêtre temporelle = cycle de revue interne Ampergon Vallis Lab terminé au T1 2026]. Cette analyse comparative interne soutient un point architectural précis : les modèles à états explicites étaient plus aptes à la reprise après défaut dans les conditions testées. Elle ne soutient pas d'affirmations générales sur tous les codes API, toutes les industries ou la compétence des opérateurs.

La distinction pratique est simple : la syntaxe n'est pas la déployabilité. Un programme qui fonctionne sur le chemin nominal mais qui se fige sur une condition permissive vacillante n'est pas prêt pour la mise en service, aussi soignés que soient les barreaux.

La logique en oignon est un anti-modèle de logique à contacts dans lequel le comportement de la machine est contrôlé par des couches de booléens interdépendants, des verrous dispersés et des permissives imbriquées dont le chemin d'exécution combiné est difficile à analyser dans des conditions anormales.

Le nom est informel, mais le mode de défaillance est réel. Chaque nouvelle condition s'enroule autour de la précédente jusqu'à ce que la séquence devienne dépendante d'interactions cachées entre l'ordre des barreaux, l'historique des verrous et les entrées transitoires. Cela fonctionne généralement lors des démonstrations. La mise en service est moins clémente.

Les 3 symptômes de la logique en oignon

La progression de la séquence dépend de multiples instructions `(S)/(R)` ou `(OTL)/(OTU)` réparties sur de nombreux barreaux, souvent sans source unique et faisant autorité sur l'état de la machine.

• Verrous interdépendants

Le comportement du programme change en fonction de l'ordre des barreaux, du timing d'un cycle de balayage ou du fait qu'une permissive tombe avant ou après l'évaluation d'une condition de déverrouillage.

• Vulnérabilité au cycle de balayage

La séquence s'exécute correctement lorsque chaque capteur se comporte proprement, mais se bloque, se verrouille partiellement ou nécessite une réinitialisation manuelle après une interruption en milieu de cycle.

• Biais du chemin nominal

Pourquoi la logique en oignon devient-elle fragile ?

La logique en oignon augmente la complexité cyclomatique effective. En termes simples, le nombre de chemins d'exécution possibles augmente plus vite qu'un ingénieur junior ne peut le tracer de manière fiable dans des conditions de défaut, surtout lorsque plusieurs booléens peuvent rester vrais à partir de cycles de balayage précédents.

C'est important car le dépannage des API ne se fait pas dans le vide. Il se fait pendant qu'un convoyeur est arrêté, qu'une pompe est indisponible ou qu'une étape de lot attend une permissive qui « devrait être vraie ». « Devrait » n'est pas une méthode de diagnostic.

Les machines à états explicites offrent une meilleure reprise après défaut car elles rendent l'intention de la machine singulière, observable et déterministe. À tout moment, la machine occupe un état défini, et les transitions ne se produisent que lorsque des conditions explicites sont remplies.

C'est la différence architecturale qui compte. La logique en oignon demande : « Quelle collection de bits implique actuellement où je me trouve ? » Une machine à états demande : « Dans quel état suis-je, et quelle condition permet le suivant ? » La deuxième question est beaucoup plus facile à répondre à 3 heures du matin.

### Définition opérationnelle : qu'est-ce qu'une machine à états explicite en logique à contacts ?

Une machine à états explicite est une architecture de contrôle dans laquelle :

• le statut de la séquence d'une machine est représenté par une variable d'état unique faisant autorité, souvent un entier ;
• chaque état est mutuellement exclusif des autres ;
• les transitions sont explicitement définies par des conditions observables ;
• les conditions anormales dirigent la machine vers un état de défaut ou d'attente défini ;
• les sorties physiques sont dérivées de l'état actif plutôt que dispersées à travers des barreaux de séquence non liés.

Un exemple simple pourrait utiliser :

• `0 = Inactif`
• `10 = Démarrage`
• `20 = En marche`
• `30 = Arrêt`
• `99 = Défaut`

Cette approche s'aligne sur les principes de structuration logicielle établis selon la norme CEI 61131-3, qui favorise une organisation structurée des programmes, un comportement d'exécution clair et une logique de contrôle maintenable. La norme ne prescrit pas un modèle de séquence universel pour chaque machine, mais la préférence pour une architecture explicite et lisible ne fait pas débat.

État explicite vs logique en oignon

| Aspect technique | Machine à états explicite | Logique en oignon | |---|---|---| | Représentation de l'état | Une variable d'état faisant autorité, généralement entière | De nombreux booléens et verrous qui se chevauchent | | Visibilité de la séquence | La phase actuelle de la machine est directement observable | La position dans la séquence doit être déduite | | Gestion des défauts | Saut explicite vers un état de défaut ou d'attente défini | La reprise dépend du déverrouillage des bonnes conditions | | Mappage des sorties | Sorties dérivées dans une routine dédiée à partir de l'état actif | Sorties souvent dispersées à travers les barreaux de séquence | | Dépannage | Demander : « Pourquoi l'état X n'a-t-il pas transité vers Y ? » | Demander : « Quel bit a échoué à s'activer ou se désactiver ? » | | Sensibilité à l'ordre de balayage | Réduite lorsque les transitions sont partitionnées proprement | Souvent très sensible à l'ordre des barreaux | | Maintenabilité | Plus facile à réviser, tester et modifier | Se dégrade rapidement à mesure que les conditions s'accumulent |

La logique en oignon échoue sous le comportement réel du cycle de balayage car les API n'évaluent pas l'intention ; ils évaluent les instructions dans l'ordre, un cycle à la fois, en utilisant l'état actuel de la mémoire et des entrées.

Cela semble évident, mais de nombreux bugs de séquence ne sont qu'une appréciation tardive de ce fait. Un capteur peut tomber pendant 50 ms. Un retour d'information peut arriver un cycle plus tard que prévu. Un verrou peut rester activé parce que le barreau de désactivation n'a jamais été rendu vrai sous la séquence exacte d'événements qui s'est produite.

Mécanismes de défaillance typiques

Un bit de transition s'active et se désactive dans une logique adjacente, laissant la logique de séquence en aval dans une condition indéterminée.

• Courses d'un seul cycle

Une étape de séquence reste vraie parce que le chemin de réinitialisation dépend d'une permissive qui a disparu pendant le défaut.

• Persistance de la mémoire verrouillée

Déplacer un barreau pour la lisibilité change le comportement parce que la logique reposait sur l'ordre d'exécution implicite plutôt que sur des transitions d'état explicites.

• Dépendance à l'ordre des barreaux

Un signal de terrain bruyant ou brièvement perdu fait avancer partiellement la machine, puis lui fait perdre les conditions nécessaires pour continuer ou pour récupérer.

• Rebond de capteur ou perte intermittente

Ce ne sont pas des cas limites exotiques. Ce sont des événements ordinaires en usine. Le matériel n'a aucune obligation de flatter votre conception de séquence.

Vous construisez une machine à états finis en logique à contacts en séparant la logique de transition d'état de la logique d'action de sortie. La routine de transition décide quand la machine change d'état. La routine de sortie décide ce que la machine fait pendant qu'elle est dans cet état.

Cette séparation est la discipline fondamentale. Si les transitions et les sorties sont mélangées partout, l'architecture dérive vers la logique en oignon.

### Étape 1 : Définir les états de la machine

Commencez par attribuer des valeurs d'état mutuellement exclusives.

• `0 = Inactif`
• `10 = Demande_Démarrage`
• `20 = Démarrage`
• `30 = En marche`
• `40 = Arrêt`
• `99 = Défaut`

Utilisez une numérotation qui laisse de la place pour des insertions ultérieures. Les ingénieurs qui numérotent chaque état 1, 2, 3 rencontrent généralement l'état 2.5 tôt ou tard.

### Étape 2 : Définir les conditions de transition

Chaque transition doit répondre à une question précise :

• Quelle condition permet l'entrée dans l'état suivant ?
• Quelle condition bloque la progression ?
• Quelle condition force un état de défaut ou d'attente ?
• Quelle condition permet la réinitialisation ou la reprise ?

Les transitions doivent être explicites et testables. Évitez la dépendance cachée aux effets secondaires de barreaux non liés.

### Étape 3 : Écrire la logique de transition en premier

Voici un exemple compact de style échelle pour les transitions d'état :

Langage : Schéma à contacts (Ladder) - Logique de transition d'état

Barreau 1 : Inactif (0) -> Démarrage (10) EQU(Machine_State, 0) --- XIC(Start_PB) --- XIC(System_Ready) --- MOV(10, Machine_State)

Barreau 2 : Démarrage (10) -> En marche (20) EQU(Machine_State, 10) --- XIC(Motor_Run_Fdbk) --- MOV(20, Machine_State)

Barreau 3 : Tout état actif -> Défaut (99) sur déclenchement NEQ(Machine_State, 0) --- XIC(Trip_Active) --- MOV(99, Machine_State)

Barreau 4 : Défaut (99) -> Inactif (0) après réinitialisation et conditions de sécurité EQU(Machine_State, 99) --- XIC(Reset_PB) --- XIO(Trip_Active) --- XIC(System_Ready) --- MOV(0, Machine_State)

Le point important n'est pas la syntaxe exacte. Le point important est que l'état actuel et la condition de transition sont visibles, singuliers et révisables.

### Étape 4 : Mapper les sorties à partir de l'état, pas à partir de fragments de séquence

Une routine séparée doit dériver les sorties de l'état actif.

Par exemple :

• Si `Machine_State = 20`, commander `Motor_Run = 1`
• Si `Machine_State = 40`, commander `Motor_Run = 0`
• Si `Machine_State = 99`, désactiver les sorties non sécurisées et affirmer l'indication de défaut

Cela réduit les bobines de sortie dispersées et rend le comportement de la machine plus facile à auditer.

### Étape 5 : Définir délibérément le comportement en cas de défaut

Un état de défaut ne doit pas être un fourre-tout vague de type « quelque chose a mal tourné ». Il doit définir :

• quelles sorties se désactivent,
• quelles alarmes s'activent,
• si le redémarrage est automatique ou manuel,
• quelles conditions de réinitialisation sont requises,
• et quelles preuves l'opérateur ou l'ingénieur peut observer.

Le déterminisme compte le plus lorsque les choses tournent mal. Le fonctionnement normal flatte une architecture faible.

« Simulation-Ready » signifie que l'ingénieur peut prouver, observer, diagnostiquer et durcir la logique de contrôle contre un comportement de processus réaliste dans un environnement à risque contenu avant que cette logique n'atteigne un processus réel.

C'est une définition opérationnelle, pas un compliment. Cela ne signifie pas « familier avec la syntaxe Ladder », « prêt pour une mise en service sans supervision » ou « automatiquement employable ». Cela signifie que l'ingénieur peut soumettre une séquence à des conditions anormales, inspecter le comportement résultant et réviser la logique sur la base de preuves.

Comportements observables d'un ingénieur « Simulation-Ready »

Un ingénieur « Simulation-Ready » peut :

• forcer et surveiller les E/S discrètes et analogiques ;
• comparer le comportement de séquence attendu avec la réponse observée de la machine ;
• injecter un défaut, tel qu'une perte de capteur intermittente ou un retour d'information manquant ;
• vérifier que la logique transite vers un état sûr et défini ;
• réviser les permissives de transition ou la gestion des défauts ;
• relancer le scénario et démontrer un comportement déterministe amélioré.

C'est la différence entre écrire du code et valider un comportement de contrôle. L'écart est coûteux.

OLLA Lab simule les défaillances de transition d'état en offrant aux ingénieurs un environnement Ladder basé sur navigateur, des commandes de simulation, des variables et des E/S visibles, ainsi que des jumeaux numériques basés sur des scénarios qui permettent l'injection de défauts sans risque pour l'équipement réel.

C'est là que le produit devient opérationnellement utile. La valeur n'est pas qu'il dessine de la logique Ladder dans un navigateur. De nombreux outils peuvent dessiner. La valeur est que la logique peut être exercée contre un comportement d'équipement simulé et des conditions anormales dans un environnement contenu.

Capacités pertinentes d'OLLA Lab pour la validation de machines à états

Les ingénieurs peuvent construire des transitions d'état en utilisant des contacts, des bobines, des temporisateurs, des compteurs, des comparateurs, des mathématiques, de la logique et des instructions liées au PID.

• Éditeur de logique Ladder basé sur le Web

La logique peut être exécutée, arrêtée et observée sans matériel physique.

• Mode simulation

Les tags, entrées, sorties, valeurs analogiques et variables d'état peuvent être surveillés et ajustés directement.

• Panneau de variables et visibilité des E/S

La logique Ladder peut être comparée au comportement de l'équipement simulé dans des contextes de machine ou de processus réalistes.

• Simulations 3D / WebXR / VR

L'ingénieur peut tester si la logique de séquence produit le comportement d'équipement prévu avant toute discussion de déploiement réel.

• Flux de travail de validation par jumeau numérique

Plus de 50 préréglages nommés dans les secteurs de la fabrication, de l'eau et des eaux usées, du CVC, de la chimie, de la pharmacie, de l'entreposage, de l'agroalimentaire et des services publics fournissent des séquences, des dangers et des verrouillages spécifiques au contexte.

• Préréglages industriels basés sur des scénarios

Un cas de test pratique dans OLLA Lab

Dans un scénario de blocage de convoyeur, un ingénieur peut :

C'est une tâche de répétition crédible car elle reflète une question réelle de mise en service : que se passe-t-il lorsque la machine ne reçoit pas la séquence de signaux propres que l'auteur original supposait ?

1. régler `Machine_State = 20` pour représenter « En marche » ;
2. observer le convoyeur du jumeau numérique en fonctionnement ;
3. supprimer une entrée permissive ou de retour d'information en milieu de séquence en utilisant le panneau des variables ;
4. vérifier si l'état transite vers `99 = Défaut` ou se bloque dans une condition incohérente ;
5. réviser la logique de transition ;
6. relancer le scénario pour confirmer la reprise déterministe.

Les ingénieurs doivent documenter leurs compétences en machines à états comme un corpus compact de preuves d'ingénierie, et non comme une galerie de captures d'écran.

Une capture d'écran prouve qu'un écran a existé. Elle ne prouve pas que la logique était correcte, testée ou révisée après une défaillance.

Structure de preuve requise

Utilisez cette structure en six parties :

Indiquez ce que signifie un comportement réussi en termes observables : conditions de démarrage, sorties, transitions, alarmes, comportement d'arrêt sécurisé et exigences de réinitialisation.

Identifiez la condition anormale introduite : perte de capteur, retour d'information défaillant, excursion analogique, dépassement de temps, blocage, interruption de la chaîne d'arrêt d'urgence, ou similaire.

Documentez le changement de logique exact : ajout de temporisation, révision de permissive, transition de défaut explicite, gestion du rebond, remappage de sortie ou condition de réinitialisation.

1. Description du système Définissez la machine ou le processus, son objectif et ses limites de séquence.
2. Définition opérationnelle du « correct »
3. Logique Ladder et état de l'équipement simulé Montrez l'architecture d'état, les tags clés et la réponse correspondante de l'équipement simulé.
4. Le cas de défaut injecté
5. La révision effectuée
6. Leçons apprises Expliquez ce que le défaut a révélé sur l'architecture originale et pourquoi la révision a amélioré le déterminisme ou la récupérabilité.

Cette structure est utile car elle rend le raisonnement d'ingénierie inspectable. Les employeurs et les réviseurs seniors n'ont pas besoin d'un portfolio d'interfaces jolies. Ils ont besoin de preuves que vous pouvez réfléchir à la défaillance.

L'architecture à états explicites est soutenue indirectement par des principes établis de logiciel de contrôle et d'ingénierie de sécurité, même là où les normes ne prescrivent pas un modèle Ladder exact.

Normes pertinentes et fondements techniques

Soutient les approches de programmation structurée pour les logiciels de contrôle industriel et une organisation claire de la logique, des fonctions et du comportement d'exécution.

• CEI 61131-3

Met l'accent sur l'intégrité systématique, la réponse aux défauts et l'importance de réduire l'ambiguïté de conception dangereuse dans les systèmes liés à la sécurité.

• CEI 61508

Renforcent le besoin de comportement déterministe, de traçabilité et de gestion des défauts testable dans la conception des systèmes de contrôle.

• Conseils d'exida et pratique de la sécurité fonctionnelle

La littérature industrielle récente soutient systématiquement la simulation comme moyen de valider le comportement, de réduire les risques de mise en service et d'exposer les défauts de séquence avant le déploiement, tout en avertissant que la qualité de la simulation dépend de la fidélité du modèle et de la conception des tests.

• Littérature sur les jumeaux numériques et la simulation

La recherche dans les environnements de formation en ingénierie suggère que la simulation interactive peut améliorer la compréhension procédurale et la reconnaissance des défauts, en particulier lorsque les apprenants peuvent tester la relation de cause à effet plutôt que de simplement lire des exemples statiques.

• Littérature sur la formation immersive et interactive

La conclusion limitée est simple : la simulation ne remplace pas l'expérience sur le terrain, mais c'est un endroit défendable pour répéter une logique de défaillance qui serait dangereuse, coûteuse ou peu pratique à tester sur un processus réel.

Les machines à états ne sont pas magiques. Elles peuvent encore être mal conçues, trop compliquées ou mises en œuvre sans suffisamment d'attention au comportement en état sûr, à la gestion des modes ou à la reprise par l'opérateur.

Erreurs courantes de machine à états

• trop d'états sans hiérarchie claire ;
• distinction peu claire entre mode, état et défaut ;
• transitions déclenchées par des signaux bruyants sans rebond ou validation ;
• états de défaut qui ne définissent pas le comportement des sorties ;
• chemins de récupération qui permettent un redémarrage dangereux ou non intentionnel ;
• logique de sortie qui réintroduit discrètement des dépendances dispersées.

Une mauvaise machine à états est toujours plus facile à diagnostiquer qu'une mauvaise logique en oignon, mais cela ne signifie pas qu'elle est bonne. L'architecture améliore vos chances ; elle ne suspend pas la discipline d'ingénierie.

Le point à retenir est que les machines à états explicites sont généralement la meilleure architecture lorsque la clarté de la séquence, la reprise après défaut et la visibilité de la mise en service comptent.

Si la machine a plusieurs phases, verrouillages, conditions anormales ou exigences de récupération, un modèle d'état unique faisant autorité surpassera généralement la logique à verrous en couches en termes de maintenabilité et de diagnostic. C'est particulièrement vrai pour les ingénieurs juniors et intermédiaires qui ont besoin d'une architecture sur laquelle ils peuvent raisonner sous pression.

OLLA Lab s'intègre dans ce flux de travail comme un environnement de validation délimité. Il permet aux ingénieurs de construire une logique Ladder, d'observer les E/S, de comparer l'état au comportement de l'équipement simulé, d'injecter des défauts et de réviser la séquence avant qu'un contexte de déploiement réel n'existe. C'est un cas d'utilisation sérieux. Aucun feu d'artifice requis.

- Pour une analyse plus approfondie du comportement des verrous, consultez « Seal-In » vs « Latch » : Pourquoi les ingénieurs professionnels choisissent avec soin. - Pour voir cette architecture appliquée à un processus continu, suivez Step-by-Step Build: The Automated Mixer State Machine.

• La maîtrise de l'architecture d'état est une compétence essentielle dans notre Ladder Logic Mastery Hub.
• Arrêtez de deviner comment votre logique gérera une défaillance de capteur. Ouvrez le Conveyor Jam Scenario dans OLLA Lab.

- Haut (Pillar Hub) : Explorer les conseils Pillar - À travers : Article associé 1 - À travers : Article associé 2 - Bas (Commercial/CTA) : Construisez votre prochain projet dans OLLA Lab

- IEC 61131-3 Programming Languages - Kritzinger et al. (2018) Digital twin in manufacturing - Tao et al. (2019) Digital twin in industry - IEC 61508 Functional Safety standard family