Comment dépanner une condition de concurrence « double-OTE » en logique Ladder

Une condition de concurrence « double-OTE » survient lorsqu'un programme d'automate écrit plus d'une fois sur la même bobine de sortie au cours d'un seul cycle de balayage. Comme la logique Ladder s'exécute de manière séquentielle, le dernier barreau écrase les commandes précédentes. La solution est architecturale : consolider le contrôle des sorties, valider le comportement du balayage et vérifier le résultat par rapport à la réponse simulée de l'équipement.

Un convoyeur n'ignore pas une commande d'arrêt parce que l'automate est « confus ». Il l'ignore parce que le programme lui a donné deux instructions différentes en un seul balayage, et que la dernière instruction a prévalu.

Lors d'un examen récent de 500 soumissions de débutants basées sur le scénario de convoyeur d'OLLA Lab, 68 % ont introduit une écriture en double sur le même bit de marche moteur lors de l'ajout d'un arrêt secondaire ou d'une condition de permission [Méthodologie : n=500 soumissions de dépannage de convoyeur, tâche définie comme la modification d'un convoyeur à moteur unique de base pour ajouter un chemin d'arrêt en condition anormale, le comparateur était la solution de référence OTE unique originale, fenêtre temporelle du 15 janvier au 15 mars 2026]. Cette métrique interne d'Ampergon Vallis soutient un point précis : l'inspection visuelle seule manque souvent les duplications de sortie destructrices dans les modifications Ladder novices. Elle ne soutient aucune affirmation plus large sur les taux de défauts dans l'industrie.

C'est exactement là qu'un environnement de simulation devient opérationnellement utile. Le problème n'est pas la syntaxe. Le problème est la déployabilité dans la réalité du cycle de balayage.

Une erreur « double-OTE » se produit lorsque la même adresse ou étiquette de sortie est écrite par plus d'une instruction « Output Energize » (OTE) au cours d'un seul balayage d'automate.

En logique Ladder, l'automate exécute généralement un cycle répétitif :

1. Lecture des entrées
2. Exécution de la logique
3. Mise à jour des sorties
4. Maintenance et communications

Cette séquence est déterministe. Le processeur ne fait pas la « moyenne » des instructions de sortie contradictoires et ne négocie pas entre elles. Il les exécute dans l'ordre.

Si `MTR_1_Run` est activé au barreau 3, puis désactivé ou réactivé différemment au barreau 15, le dernier barreau définit l'état final écrit dans l'image de sortie. Sur un équipement réel, cela peut signifier qu'un moteur continue de tourner après une entrée de bourrage, ou qu'un contacteur vibre sous l'effet d'une logique contradictoire.

La règle du « dernier barreau gagnant »

La règle du « dernier barreau gagnant » est la conséquence pratique de l'exécution séquentielle.

Un automate ne pilote généralement pas la carte de sortie physique dès qu'il rencontre une instruction OTE dans le programme. Il met à jour l'image de sortie interne au fur et à mesure de l'exécution de la logique, puis écrit l'état résultant sur les sorties physiques à la fin du balayage. Si plusieurs barreaux écrivent sur le même bit, c'est la dernière écriture exécutée qui survit.

C'est pourquoi les bobines en double ne sont pas seulement un style négligé. Ce sont des ambiguïtés destructrices codées sous forme de comportement déterministe.

Pourquoi cela est important physiquement, et pas seulement logiquement

Un défaut « double-OTE » n'est pas seulement un défaut logiciel. Il peut entraîner des conséquences mécaniques.

Sur les convoyeurs et les systèmes motorisés, des commandes marche/arrêt contradictoires peuvent produire :

• des conditions d'arrêt ignorées,
• des vibrations intermittentes des contacteurs,
• des déclenchements intempestifs,
• une usure prématurée des démarreurs et des relais,
• des collisions de produits,
• une perte de séquence entre les équipements amont et aval.

Le code peut sembler lisible et être pourtant erroné en fonctionnement. La mise en service a une faible tolérance pour les erreurs élégantes.

Le convoyeur a planté parce que la condition d'arrêt a été écrasée plus tard dans le balayage par un second barreau commandant la même sortie de marche moteur.

Voici la logique du scénario en termes simples :

- L'objectif : Arrêter le convoyeur lorsque la cellule photoélectrique `PE_1` détecte un bourrage. - Le comportement attendu : Un bourrage doit supprimer la commande de marche vers `MTR_1_Run`. - L'erreur : Un barreau précédent coupe `MTR_1_Run` en cas de bourrage, mais un barreau ultérieur réactive `MTR_1_Run` en utilisant une condition de permission amont et une condition de marche système. - Le résultat : L'arrêt sur bourrage existe dans le code mais pas dans l'état de sortie final.

C'est le paradoxe que les opérateurs n'aiment pas : le capteur a fonctionné, le barreau semblait correct, et le convoyeur a quand même poussé le produit dans un blocage.

Exemple du motif destructeur

Barreau 3 : `[NOT PE_1_Jam] ------------------------------- (OTE) [MTR_1_Run]`

Barreau 15 : `[Upstream_Clear] -- [System_Run] ------------- (OTE) [MTR_1_Run]`

Si `PE_1_Jam` devient vrai, le barreau 3 coupe le bit de marche moteur. Si le barreau 15 reste vrai plus tard dans le même balayage, `MTR_1_Run` est à nouveau activé. Le convoyeur tourne. Le bourrage persiste.

À quoi ressemble le défaut en fonctionnement

Dans une ligne de convoyeur simulée, les symptômes visibles incluent généralement :

• le produit qui continue dans une zone occupée,
• aucune réponse efficace à la cellule photoélectrique de bourrage,
• l'état de la commande moteur qui semble incohérent avec la logique d'arrêt prévue,
• une confusion intermittente de l'opérateur car l'IHM ou la vue logique peut montrer une condition alors que l'état de sortie final en reflète une autre.

C'est pourquoi le dépannage par capture d'écran statique est une preuve faible. Vous avez besoin d'une visibilité sur l'état à travers le balayage et à travers le modèle de la machine.

Les conditions de concurrence en logique Ladder ne sont généralement pas des « conditions de concurrence » au sens du multi-threading logiciel. Ce sont des conflits d'état déterministes créés par l'ordre de balayage, les écritures en double, les changements d'entrées asynchrones entre les balayages ou une logique de séquençage mal partitionnée.

Dans cet article, la condition de concurrence est spécifiquement un écrasement par ordre de balayage.

Le mécanisme est simple :

• l'automate lit l'image actuelle des entrées,
• la logique des barreaux s'exécute en séquence,
• plusieurs instructions ciblent le même bit de sortie,
• la dernière écriture définit l'image de sortie finale,
• la machine réagit à cet état final, et non à l'intention du programmeur.

Ceci est important car de nombreux nouveaux programmeurs supposent que chaque barreau agit indépendamment sur la machine réelle. Ce n'est pas le cas. Le balayage est un passage d'exécution unique, et la machine ne voit que l'état de l'image résultante. La logique Ladder est indulgente sur la syntaxe et impitoyable sur l'architecture.

Causes courantes des défauts d'écriture en double

Les causes techniques les plus courantes sont :

• l'ajout d'un second chemin d'arrêt sans consolider la logique de marche originale,
• le mélange de permissions et de commandes sur des barreaux séparés ciblant la même sortie physique,
• la correction de défauts pendant le débogage au lieu de redessiner la structure de sortie,
• l'utilisation directe d'étiquettes de sortie physique à l'intérieur de plusieurs sections de séquence,
• l'échec à séparer la logique d'état interne du mappage de sortie final.

Un contraste utile est le suivant : génération de brouillon versus veto déterministe. L'automate exécutera volontiers les deux barreaux. Il ne vous avertira pas que l'un a silencieusement invalidé l'autre.

Vous repérez une condition de concurrence « double-OTE » en observant l'état de l'étiquette de sortie, les conditions de déclenchement et la réponse simulée de l'équipement ensemble, plutôt qu'en inspectant la syntaxe Ladder de manière isolée.

C'est là qu'OLLA Lab est utile de manière crédible en tant qu'environnement de validation et de répétition. Il ne remplace pas la mise en service sur site et ne confère pas de compétence sur site par association. Ce qu'il fournit, c'est un endroit sûr pour observer une relation de cause à effet qui serait coûteuse, rapide ou dangereuse à étudier sur un équipement réel.

Utilisez le panneau des variables comme instrument de diagnostic

Le panneau des variables est utile car il expose les changements d'état au niveau des étiquettes que l'examen statique du Ladder peut masquer.

Pour ce défaut, surveillez au moins ces étiquettes :

• `PE_1_Jam`
• `Upstream_Clear`
• `System_Run`
• `MTR_1_Run`

Le motif de diagnostic est :

• `PE_1_Jam` devient vrai,
• le barreau précédent supprime logiquement la condition de marche,
• un barreau ultérieur est toujours évalué comme vrai,
• `MTR_1_Run` redevient vrai à la fin du balayage,
• le jumeau numérique du convoyeur continue de bouger malgré la condition de bourrage.

C'est une preuve diagnostique d'un comportement d'écrasement, pas seulement une suspicion.

Ralentissez l'exécution pour inspecter la cause et l'effet

Le contrôle du temps de balayage est utile car il rend les transitions d'état rapides plus faciles à inspecter.

Lorsque cela est disponible dans le flux de travail du scénario, ralentissez l'exécution suffisamment pour observer :

1. la transition de l'entrée,
2. la réponse du barreau précédent,
3. l'écrasement du barreau ultérieur,
4. l'état de sortie final,
5. la réponse de l'équipement dans le modèle de convoyeur.

Sur un système réel, ces transitions sont souvent trop rapides pour être observées proprement sans outils de tendance, forçant la référence croisée de la logique, et une journée calme que l'usine n'a pas prévue pour vous.

Comparez l'état du Ladder avec l'état de l'équipement

La vraie valeur de la simulation n'est pas que vous puissiez voir un barreau devenir vert. C'est que vous pouvez comparer l'état logique avec le comportement de la machine.

Pour ce cas de convoyeur, vérifiez si :

• le Ladder indique une condition de bourrage,
• le bit de marche moteur reste activé à la fin du balayage,
• le convoyeur simulé continue de faire avancer le produit,
• la conséquence de collision ou de bourrage apparaît dans le modèle d'équipement.

Cette comparaison est ce qui rend l'environnement prêt pour la simulation dans un sens opérationnel : l'ingénieur peut observer, diagnostiquer et durcir la logique de contrôle contre un comportement de processus réaliste avant qu'il n'atteigne un processus réel.

L'architecture correcte consiste à laisser un barreau, une routine ou une couche de mappage clairement délimitée posséder la commande de sortie physique finale.

La règle est simple : une sortie physique, un seul rédacteur final. Tout le reste doit alimenter cette décision, et non entrer en compétition avec elle.

### Méthode 1 : Branchement parallèle pour une logique OU consolidée

Le branchement parallèle est une solution propre lorsque plusieurs permissions ou chemins de commande doivent piloter une décision de sortie.

Au lieu d'écrire `MTR_1_Run` dans plusieurs barreaux, combinez la logique dans un seul barreau avec des branches explicites et des conditions d'arrêt.

Structure exemple :

`[System_Run] -- [Upstream_Clear] -- [NOT PE_1_Jam] -- [NOT EStop_Active] -- (OTE) [MTR_1_Run]`

Ou, là où plusieurs demandes de marche valides existent, utilisez une logique de branchement en amont d'une seule OTE finale.

Cette approche est généralement la plus lisible pour un contrôle moteur simple.

### Méthode 2 : Latch/Unlatch (OTL/OTU) avec prudence

Les instructions de verrouillage (latch) et déverrouillage (unlatch) peuvent être appropriées pour des états de commande retenus, des étapes de séquence ou des demandes d'opérateur, mais elles exigent de la discipline.

Utilisez-les avec précaution car :

• les états retenus peuvent survivre à des conditions que le programmeur a oublié d'effacer,
• le comportement de redémarrage après une perte de puissance ou des transitions de mode doit être explicitement pris en compte,
• le comportement lié à la sécurité ne doit jamais reposer sur une logique de verrouillage occasionnelle.

Pour les fonctions de sécurité, la base de conception directrice doit provenir de l'architecture et des normes de sécurité applicables, et non de la commodité dans la rédaction du Ladder.

### Méthode 3 : Étiquetage intermédiaire avec mappage de sortie final

Les étiquettes intermédiaires sont souvent la solution la plus évolutive dans les machines plus grandes ou les skids de processus.

Le modèle est :

• calculer les conditions internes en utilisant des bits de mémoire,
• séparer les permissions, les déclenchements, les demandes et les états de séquence,
• mapper ces états internes vers une seule sortie physique finale dans une routine de sortie dédiée.

Exemple :

`Barreau 5 : [System_Run] -- [Upstream_Clear] -------------------- (OTE) [Run_Request]` `Barreau 6 : [PE_1_Jam] ------------------------------------------ (OTE) [Jam_Trip]` `Barreau 20 : [Run_Request] -- [NOT Jam_Trip] -- [NOT EStop_Active] ---- (OTE) [MTR_1_Run]`

Cette architecture améliore la traçabilité car la décision de sortie finale est explicite.

Vous devriez documenter des preuves d'ingénierie, pas une galerie de captures d'écran.

Si vous voulez démontrer une réelle compétence en dépannage, utilisez cette structure compacte :

Énoncez des critères d'acceptation observables, tels que : « Si `PE_1_Jam = TRUE`, alors `MTR_1_Run = FALSE` à la fin du balayage, et le mouvement du convoyeur s'arrête dans le jumeau numérique. »

Documentez la correction architecturale : barreau consolidé, conception d'étiquette intermédiaire ou propriété de séquence révisée.

Capturez le principe d'ingénierie, tel que : « Les sorties physiques nécessitent un seul rédacteur final », ou « la logique de condition anormale doit être validée par rapport à l'état final du balayage, et non seulement par rapport à l'intention locale du barreau. »

1. Description du système Définissez la section du convoyeur, la commande moteur, le capteur de bourrage, la permission amont et la séquence attendue.
2. Définition opérationnelle du comportement correct
3. Logique Ladder et état de l'équipement simulé Incluez l'ensemble de barreaux pertinent et l'état de l'équipement correspondant avant la correction.
4. Le cas de défaut injecté Montrez l'OTE en double ou le chemin d'écriture concurrent et la condition exacte sous laquelle il écrase la logique d'arrêt.
5. La révision effectuée
6. Leçons apprises

Ce type de preuve est utile dans la formation, l'examen par les pairs et la répétition de mise en service car il montre un raisonnement, pas seulement une possession de logiciel.

Le modèle d'exécution de base provient de la pratique IEC 61131-3 : les programmes d'automate s'exécutent de manière déterministe selon le langage et le modèle d'exécution implémentés par la plateforme du contrôleur.

L'argument du risque est également bien fondé. La littérature sur la sécurité fonctionnelle distingue systématiquement le comportement de contrôle prévu et le comportement vérifié dans des conditions défaillantes ou anormales. Cette distinction est importante ici car les écritures en double peuvent invalider la logique de protection prévue sans produire d'erreur de syntaxe.

L'argument de la simulation doit également rester limité. Un jumeau numérique ou un modèle de machine simulé ne certifie pas à lui seul la préparation sur le terrain. Ce qu'il soutient, lorsqu'il est utilisé correctement, est une découverte plus précoce des défauts, une répétition plus sûre des conditions anormales et une validation plus observable du comportement de la séquence avant la mise en service.

OLLA Lab s'intègre comme un environnement de validation et de répétition basé sur le web pour la logique Ladder, le comportement des E/S simulées et le dépannage aligné sur le jumeau numérique.

Dans ce cas d'utilisation spécifique, il est utile pour :

• construire et modifier la logique Ladder dans le navigateur,
• exécuter le scénario de convoyeur sans matériel physique,
• surveiller les étiquettes dans le panneau des variables,
• comparer l'état du Ladder au comportement de la machine simulée,
• répéter des conditions anormales telles que les bourrages, la perte de permission et les révisions de chemin d'arrêt,
• documenter la correction sous forme de dossier de preuves d'ingénierie.

C'est une portée crédible.

- Lire : Comprendre les cycles de balayage : comment OLLA Lab imite le matériel réel. - Lire : Seal-In vs. Latch : pourquoi les ingénieurs professionnels choisissent avec soin. - Testez le défaut en toute sécurité dans la pratique : ouvrez le préréglage « Conveyor Crash » dans OLLA Lab.

• Pour une analyse complète de la structure de programmation IEC 61131-3 et des fondamentaux du Ladder, visitez le Ladder Logic Mastery Hub.

- IEC 61131-3: Automates programmables — Partie 3 : Langages de programmation - Fondamentaux du cycle de balayage des automates (AutomationDirect) - Aperçu de la sécurité fonctionnelle IEC 61508 - Concepts de conditions de concurrence et de synchronisation (Glossaire NIST) - Validation par jumeau numérique pour la logique de contrôle (IFAC-PapersOnLine)