Comment dépanner un verrouillage de sécurité API rémanent : Repérer l'erreur n° 2

Un verrouillage de sécurité API qui reste à l'état vrai après un cycle d'alimentation est généralement une erreur de conception liée à une mémoire rémanente. Lorsque la logique Set/Latch (verrouillage) est utilisée là où une autorisation non rémanente est requise, la machine peut repasser en mode RUN avec le mouvement toujours autorisé, ce qui peut entrer en conflit avec les exigences de redémarrage des normes NFPA 79 et IEC 60204-1.

Une idée fausse courante est de considérer que tout barreau qui « fonctionnait avant la coupure de courant » constitue une bonne logique de contrôle. Ce n'est pas le cas. Dans une logique d'autorisation liée à la sécurité, survivre à un redémarrage peut être le défaut lui-même.

Considérez le mode de défaillance : l'alimentation chute, l'unité centrale (CPU) redémarre, et un moteur ou une séquence reprend sans action préalable de l'opérateur. Il s'agit d'un risque lié au redémarrage.

Métrique Ampergon Vallis : Lors d'un test de coupure de courant simulé sur 50 cycles dans le scénario de contrôle moteur d'OLLA Lab, les bits de verrouillage rémanents sont restés à l'état TRUE pendant l'état de redémarrage du CPU dans les 50 essais, tandis que les sorties équivalentes par auto-maintien non rémanent sont passées à FALSE lors du redémarrage en moins de 12 ms. Méthodologie : n=50 tests de transition RUN→PROG→RUN contrôlés sur une tâche interne de contrôle moteur ; comparateur de référence = barreau d'auto-maintien OTE non rémanent ; fenêtre temporelle = session QA unique le 24/03/2026. Cela soutient l'affirmation restreinte selon laquelle le simulateur peut reproduire la distinction comportementale entre la logique rémanente et non rémanente lors des tests de redémarrage. Cela ne soutient aucune affirmation plus large sur le taux de défaillance sur le terrain.

Dans cet article, la tâche est médico-légale : identifier pourquoi le bit survit, pourquoi cela est important au regard des attentes en matière de sécurité des machines, et comment remplacer ce modèle par une conception non rémanente que vous pourrez défendre lors de la mise en service.

Le comportement de verrouillage survit à un redémarrage car les instructions rémanentes et les instructions de sortie non rémanentes ne sont pas traitées de la même manière lors de l'initialisation du CPU.

Dans l'exécution pratique d'un API, la distinction est simple : OTE écrit l'état pour le cycle actuel ; OTL stocke l'état jusqu'à ce qu'une instruction explicite le supprime. La syntaxe peut sembler similaire à l'écran. C'est sur le comportement au redémarrage que la discussion se termine.

La routine de nettoyage de pré-balayage (pre-scan)

Lorsqu'un API passe du mode PROGRAM au mode RUN, ou récupère après une coupure de courant, le CPU effectue généralement une routine d'initialisation ou de pré-balayage. L'implémentation exacte varie selon la plateforme, mais la distinction technique est cohérente :

1. Le CPU évalue les conditions de démarrage avant que l'exécution cyclique normale ne reprenne.
2. Les instructions de sortie standard non rémanentes telles que OTE sont remises à FALSE pendant le comportement de pré-balayage.
3. Les instructions rémanentes telles que OTL ne sont pas effacées simplement parce que le contrôleur a redémarré.
4. Leur mémoire associée reste dans le dernier état stocké jusqu'à ce qu'une condition de réinitialisation explicite OTU ou équivalente soit exécutée.

C'est pourquoi une autorisation rémanente peut rester active après un redémarrage, même si aucun opérateur n'a émis de nouvelle commande de démarrage.

Ce que cela signifie en termes de logique à contacts (Ladder)

Un verrouillage rémanent répond à une question différente de celle d'un circuit d'auto-maintien.

- Logique d'auto-maintien : « Cette sortie doit-elle rester vraie tant que le chemin d'autorisation actuel demeure valide ? » - Logique de verrouillage rémanent : « Ce bit doit-il rester vrai malgré une perte de cycle, un changement de mode ou une interruption de l'alimentation jusqu'à ce qu'une autre instruction l'efface ? »

Ce ne sont pas des choix de conception interchangeables. L'un concerne la continuité de l'état. L'autre concerne la continuité d'une autorisation active. Les confondre est la manière dont les risques de redémarrage sont écrits, barreau après barreau.

Un verrouillage stocke l'état malgré une interruption. Un circuit d'auto-maintien rétablit l'état uniquement tant que les conditions du barreau restent valides.

C'est la distinction diagnostique fondamentale.

| Modèle de conception | Comportement de la mémoire | Comportement au redémarrage | Utilisation typique | Adéquation pour l'autorisation de sécurité | |---|---|---|---|---| | OTL/OTU Set-Reset | Rémanent | L'état peut persister après redémarrage jusqu'à réinitialisation explicite | Premier défaut (first-out), mémoire d'étape de lot, compteurs de maintenance | Mauvais choix pour les autorisations de mouvement ou les habilitations sensibles au redémarrage | | Circuit d'auto-maintien OTE | Non rémanent | La sortie chute au redémarrage et doit être rétablie par des conditions de barreau valides | Maintien de marche/arrêt moteur, autorisations de marche commandées par l'opérateur | Préféré lorsque le redémarrage doit nécessiter une réinitialisation délibérée |

Un raccourci utile est le suivant : le verrouillage est une mémoire ; l'auto-maintien est une continuité. L'usine a généralement besoin de savoir ce que vous vouliez dire.

Les normes NFPA 79 et IEC 60204-1 exigent que le rétablissement de l'alimentation ne provoque pas automatiquement le redémarrage des machines lorsque ce redémarrage crée un danger.

C'est la question normative derrière le problème de codage. Le défaut dans le ladder est important car le comportement de redémarrage de la machine est important.

Le principe des normes

L'exigence pertinente, exprimée en termes d'ingénierie pratique, est la suivante :

• La perte et le rétablissement de l'alimentation ne doivent pas, par eux-mêmes, provoquer la reprise d'un mouvement dangereux.
• Le redémarrage doit nécessiter une action délibérée lorsque la reprise automatique mettrait le personnel en danger.
• L'arrêt d'urgence, l'interruption d'une protection ou le rétablissement de l'alimentation ne doivent pas être contournés par un état rémanent obsolète.

Les normes NFPA 79 et IEC 60204-1 sont alignées sur ce point. Le libellé diffère selon l'édition et le contexte d'application, mais l'intention de conception est stable : pas de redémarrage dangereux et inattendu.

Pourquoi un bit « prêt » rémanent devient un problème normatif

Un bit `System_Ready`, `Run_Enable` ou d'autorisation de porte de protection rémanent peut contourner le chemin de réinitialisation manuelle attendu après un redémarrage.

Cela signifie que la logique peut satisfaire la syntaxe interne tout en violant la philosophie de redémarrage de la machine. Les normes ne se soucient pas de l'élégance du barreau. Elles se soucient de savoir si la machine s'est déplacée alors qu'elle aurait dû attendre.

Cet article ne constitue pas un avis de conformité formel, et la conformité dépend toujours de l'évaluation complète des risques de la machine, de l'architecture de sécurité et de la juridiction applicable. Mais en tant que règle de conception de contrôle, l'utilisation de la mémoire rémanente pour les autorisations de mouvement est difficile à défendre.

Vous repérez cette erreur en observant une transition d'état, et non en admirant le barreau de manière isolée.

L'examen statique du code aide, mais les défauts de redémarrage se cachent souvent à la vue de tous. Un barreau peut sembler propre et pourtant mal se comporter dès que le CPU cligne des yeux.

Définition opérationnelle de « prêt pour la simulation » : un ingénieur est prêt pour la simulation lorsqu'il peut prouver, observer, diagnostiquer et durcir la logique de contrôle contre un comportement de processus réaliste avant que cette logique n'atteigne un processus réel. Dans ce cas, cela signifie reproduire la condition de redémarrage, surveiller la persistance des tags et vérifier que la logique révisée échoue en toute sécurité lors du changement d'état du CPU.

Reproduction du défaut étape par étape

Utilisez OLLA Lab comme environnement de validation délimité pour un test de mise en service à haut risque qui serait dangereux ou opérationnellement perturbateur sur un équipement réel.

1. Ouvrez le scénario de contrôle moteur dans OLLA Lab.
2. Dans le panneau des variables, surveillez le tag `System_Ready` et tous les tags de sortie ou d'autorisation associés.
3. Dans l'éditeur de logique Ladder, déclenchez la condition de démarrage pour que le verrouillage rémanent s'active.
4. Confirmez que `System_Ready = TRUE`.
5. Utilisez le mode simulation pour faire passer le CPU virtuel de RUN à PROG, représentant une perte de courant ou une transition de mode du contrôleur.
6. Faites repasser le CPU de PROG à RUN.
7. Observez si `System_Ready` reste TRUE avant qu'une nouvelle action de l'opérateur ne se produise.

Si le bit reste activé après le redémarrage, vous avez reproduit le modèle de défaut.

Pourquoi ce test doit être effectué en simulation en premier

C'est là qu'OLLA Lab devient opérationnellement utile.

La valeur de la plateforme ici n'est pas qu'elle « enseigne les API » dans l'abstrait. Elle offre un espace pour répéter un test d'état de redémarrage qui est souvent coûteux, gênant ou dangereux sur des machines en service. Vous pouvez surveiller l'état du ladder, l'état des E/S et le comportement de l'équipement simulé ensemble, ce qui est exactement ce que nécessitent les diagnostics de redémarrage.

C'est la différence entre la pratique de la syntaxe et la pratique de la validation. La distinction n'est pas cosmétique.

Le remplacement correct pour une autorisation de marche sensible au redémarrage est généralement un circuit d'auto-maintien non rémanent construit autour d'une instruction OTE.

Le modèle classique de contrôle à trois fils survit toujours car il résout un problème réel de manière propre. Les anciens modèles persistent lorsque la physique continue de voter pour eux.

Modèle de ladder incorrect vs correct

INCORRECT : Verrouillage rémanent (survit à la coupure de courant)

|---[ Start_PB ]-------------------------------------( L )---| System_Ready

CORRECT : Auto-maintien non rémanent (chute à la coupure de courant)

|---[ Start_PB ]-------[/ Stop_PB ]------------------( )---| | System_Ready |---[ System_Ready ]---------------------------------|

Pourquoi le barreau d'auto-maintien est plus sûr pour ce cas d'utilisation

La conception par auto-maintien non rémanent fonctionne car :

• la sortie n'est maintenue que tant que la logique du barreau reste valide,
• l'instruction OTE est effacée lors du comportement de redémarrage,
• l'opérateur doit réémettre une commande de démarrage après le rétablissement de l'alimentation,
• le chemin de contrôle reflète les conditions actuelles de la machine plutôt qu'une mémoire historique.

Cela s'aligne avec la philosophie de redémarrage attendue pour de nombreuses commandes de marche de machine et autorisations de mouvement.

Que vérifier après la révision

Après avoir remplacé le verrouillage par un barreau d'auto-maintien, répétez le test de redémarrage et vérifiez :

• `System_Ready` passe à FALSE pendant la transition de redémarrage,
• aucune sortie ne reprend le mouvement sans une nouvelle commande,
• les conditions d'arrêt et de verrouillage (interlock) rompent toujours correctement le chemin de maintien,
• les conditions anormales ne recréent pas l'autorisation de manière inattendue.

Une correction n'est pas complète simplement parce que le barreau semble plus respectable. Elle est complète lorsque le comportement au redémarrage est correct.

Vous devez documenter un ensemble compact de preuves techniques, et non une galerie de captures d'écran.

Un dossier de dépannage crédible montre le raisonnement, la méthode de test, la reproduction du défaut et le résultat de la révision. C'est ce que les examinateurs, les instructeurs et les employeurs peuvent réellement inspecter.

Utilisez cette structure :

Énoncez le comportement de redémarrage attendu en termes observables. Exemple : « Après le rétablissement de l'alimentation, la sortie moteur doit rester hors tension jusqu'à ce que l'opérateur appuie sur Start. »

Décrivez le test exact : transition RUN→PROG→RUN, bit rémanent observé, conséquence sur la sortie.

Enregistrez le principe de conception : la mémoire rémanente est valide pour un état stocké, pas pour une autorisation de mouvement sensible au redémarrage.

1. Description du système Définissez la cellule de la machine, l'objectif de contrôle et l'autorisation ou la sortie affectée.
2. Définition opérationnelle de « correct »
3. Logique Ladder et état de l'équipement simulé Capturez le barreau original, les tags pertinents et l'état de la machine simulée avant et après le redémarrage.
4. Le cas de défaut injecté
5. La révision effectuée Montrez la logique de remplacement et expliquez pourquoi elle modifie le comportement de redémarrage.
6. Leçons apprises

Cette structure est utile dans la formation car elle reflète l'examen réel de la logique de mise en service. Elle est également utile sur le terrain car la mémoire est peu fiable sous la pression des délais, alors que les preuves écrites sont simplement démodées.

OTL et OTU sont valides lorsque le processus nécessite réellement un état conservé malgré une interruption.

Le problème n'est pas l'instruction. Le problème est de prétendre que tout état mérite de survivre à un redémarrage.

Applications appropriées de la mémoire rémanente

| Application | Pourquoi le comportement rémanent est approprié | |---|---| | Capture du premier défaut (alarm first-out) | La source initiale du défaut doit rester enregistrée même si l'alimentation est interrompue avant l'examen. | | Suivi de recette ou d'étape de lot | Le processus peut avoir besoin de reprendre avec la connaissance de la dernière étape confirmée. | | Compteurs de maintenance | Les comptes de cycles et les indicateurs d'usure doivent survivre au redémarrage pour l'intégrité de la maintenance. | | Accusés de réception opérateur avec logique de réinitialisation contrôlée | Certains accusés de réception peuvent devoir persister jusqu'à ce qu'un chemin de réinitialisation formel soit exécuté. | | Marqueurs d'état de production non liés à la sécurité | Certains états de séquence sont intentionnellement conservés pour préserver la continuité du processus après une récupération contrôlée. |

Quand la mémoire rémanente doit déclencher une surveillance accrue

Appliquez un examen supplémentaire lorsque le bit rémanent est lié à :

• l'autorisation de mouvement,
• l'autorisation de protection,
• l'autorisation de redémarrage,
• le chemin de récupération après arrêt d'urgence,
• les verrouillages adjacents à la sécurité,
• toute sortie dont la restauration inattendue pourrait créer un risque pour le personnel.

Cela ne rend pas automatiquement la conception non conforme, mais cela signifie que la charge de la justification devient réelle.

La validation par jumeau numérique aide en rendant le comportement de redémarrage observable au niveau de la couche logique et de la couche de comportement de l'équipement en même temps.

C'est la valeur opérationnelle. Vous ne demandez pas seulement si un bit est resté à l'état haut. Vous demandez ce que la machine ferait parce que le bit est resté à l'état haut.

Dans OLLA Lab, l'éditeur de ladder, la visibilité des variables et l'état de l'équipement simulé peuvent être utilisés ensemble pour tester :

• si le bit rémanent persiste,
• si le chemin de sortie se rétablit,
• si le modèle d'équipement reflète une condition de démarrage non commandée,
• si la logique révisée supprime ce comportement.

C'est pourquoi la simulation est importante pour la pratique de la mise en service. De nombreux défauts dangereux sont des défauts de transition : démarrage, récupération, changement de mode, perte d'autorisation, désaccord de capteur, retour d'information retardé. Ils ne sont pas toujours évidents en fonctionnement en régime permanent. Les usines réelles n'aiment pas être utilisées comme bacs à sable de débogage, pour des raisons assez valables.

La littérature récente sur les jumeaux numériques, la mise en service virtuelle et la formation industrielle basée sur la simulation soutient généralement l'utilisation d'environnements simulés haute fidélité pour une découverte plus précoce des défauts, la préparation des opérateurs et la validation des systèmes de contrôle, tout en précisant que la simulation ne remplace pas la validation formelle de la sécurité ou les tests d'acceptation sur site. Cette limite est importante.

Un verrouillage de sécurité API rémanent est généralement une erreur de conception lorsqu'il permet à une autorisation de machine de survivre au rétablissement de l'alimentation.

Le principe correctif est simple :

• utilisez la mémoire rémanente pour l'état qui doit survivre à une interruption,
• utilisez une logique d'auto-maintien non rémanente pour l'autorisation de marche sensible au redémarrage,
• testez le comportement par la transition d'état du CPU plutôt que de supposer que l'intention du barreau est évidente,
• documentez le défaut, la révision et le résultat de redémarrage observé.

C'est à cela que ressemble le travail « prêt pour la simulation » en pratique : non seulement écrire une logique ladder, mais prouver comment elle se comporte lorsque le processus fait quelque chose d'incommode. Ce qui, dans l'industrie, arrive la plupart des jours.

- IEC 60204-1 équipement électrique des machines - IEC 61508 Aperçu de la sécurité fonctionnelle - ISO 13849-1 parties des systèmes de commande relatives à la sécurité - Documentation Studio 5000 Logix Designer - Revue de la mise en service virtuelle et du jumeau numérique (Journal of Manufacturing Systems)