Fonctionnement du cycle de scrutation d'un automate : simulation de l'exécution déterministe dans OLLA Lab

Le cycle de scrutation d'un automate (PLC) est une boucle déterministe dans laquelle le contrôleur lit les entrées, exécute la logique de manière séquentielle, écrit les sorties et effectue des tâches système. OLLA Lab reproduit ce comportement dans un environnement de simulation basé sur navigateur afin que les ingénieurs puissent observer les erreurs dépendantes de la scrutation, tester les révisions logiques et valider les relations de cause à effet avant la mise en service réelle.

Une idée fausse courante est que la logique Ladder se comporte comme un logiciel ordinaire réagissant instantanément aux événements. Ce n'est pas le cas. Un automate interroge généralement la réalité lors d'une scrutation répétitive, évalue la logique dans un ordre défini et met à jour les sorties une fois cette évaluation terminée. Cette distinction fait toute la différence entre un code qui semble correct et un code qui fonctionne réellement sur une machine.

Lors d'une récente évaluation interne du scénario de tri à haute vitesse d'OLLA Lab, 68 % des utilisateurs juniors n'ont pas réussi à capturer une impulsion de capteur optique de 10 ms lorsque le temps de scrutation simulé était réglé sur 20 ms [Méthodologie : n=41 utilisateurs ; tâche = détecter et verrouiller une impulsion transitoire de cellule photoélectrique dans un scénario de rejet sur convoyeur ; comparateur de référence = capture réussie de l'impulsion avec une scrutation simulée de 5 ms ; fenêtre temporelle = 15 janv. – 10 mars 2026]. Il s'agit d'un benchmark interne d'Ampergon Vallis, et non d'une affirmation sur la prévalence dans l'industrie. Cela soutient un point précis : le timing de scrutation est souvent mal compris, même lorsque la logique des barreaux semble syntaxiquement correcte.

C'est précisément là qu'OLLA Lab est utile. Il fournit un environnement de type « logiciel dans la boucle » (software-in-the-loop) pour observer l'exécution déterministe, la visibilité des E/S et les modes de défaillance dépendants de la scrutation avant que quiconque n'en fasse l'expérience sur une machine réelle, où le coût de l'erreur est beaucoup plus élevé.

Un cycle de scrutation standard d'un automate est une séquence répétitive et déterministe comportant quatre phases fonctionnelles. L'implémentation exacte varie selon le fournisseur et le modèle de tâche, mais le schéma de base reste stable dans le cadre d'une exécution cyclique conventionnelle.

Le point clé pour l'ingénierie est simple : le programme ne lit généralement pas une entrée physique fraîche à chaque instruction. Il travaille à partir d'une image mémoire pendant l'exécution, puis met à jour les sorties par la suite.

1. Scrutation des entrées (Lecture) Le contrôleur lit l'état actuel des entrées physiques et copie ces états dans la mémoire, souvent appelée table d'image des entrées ou image de processus.
2. Exécution du programme (Logique) Le contrôleur exécute le programme utilisateur en utilisant les états d'entrée stockés. En logique Ladder, cela est généralement évalué de haut en bas et de gauche à droite au sein de la structure de tâche ou de routine active.
3. Scrutation des sorties (Écriture) Le contrôleur écrit les états de sortie finaux calculés à partir de la mémoire vers les terminaux de sortie physiques.
4. Maintenance (Comms/Diagnostics) Le contrôleur gère les diagnostics internes, les communications, les mises à jour des temporisateurs, la messagerie et d'autres tâches système.

Pourquoi cela est important en pratique

L'exécution basée sur la scrutation crée des comportements prévisibles mais non évidents :

• Une impulsion courte peut être manquée si elle se produit entre deux scrutations.
• Une bobine écrite deux fois au cours d'une même scrutation peut être écrasée silencieusement.
• Une sortie qui semble vraie dans un barreau peut ne jamais s'activer physiquement si un barreau ultérieur la réinitialise avant la phase de mise à jour des sorties.
• Les hypothèses de timing qui semblent inoffensives à l'écran peuvent échouer face à la dynamique réelle du processus.

C'est pourquoi connaître la syntaxe Ladder n'est pas la même chose que d'être prêt pour la simulation. Sur le plan opérationnel, un ingénieur prêt pour la simulation peut prouver, observer, diagnostiquer et renforcer la logique de contrôle contre le comportement réel du processus avant qu'elle n'atteigne un processus en production.

Les langages informatiques à usage général ne sont pas intrinsèquement mauvais pour le logiciel. Ils sont inadaptés pour expliquer l'exécution des automates si le modèle de contrôle est ignoré. Le problème n'est pas le prestige du langage, mais la sémantique d'exécution.

Exécution informatique versus exécution OT

| Caractéristique | Langages informatiques (Python/JavaScript, globalement) | Exécution OT / Automate (contexte IEC 61131-3) | |---|---|---| | Modèle de déclenchement principal | Piloté par les événements, les rappels ou le planificateur | Interrogation cyclique et exécution déterministe des tâches | | Relation à la mémoire | L'allocation dynamique est courante | Tags prédéfinis, mémoire structurée, mappage direct du processus | | Interaction matérielle | Généralement abstraite via des pilotes/API | Relation directe avec les images d'E/S, les états de terrain et le timing de scrutation | | Timing d'exécution | Souvent non déterministe au niveau de l'application | Conçu pour une exécution de contrôle répétable et bornée | | Mode de défaillance | Latence, conditions de concurrence, problèmes d'ordre de rappel | Impulsions manquées, logique d'écrasement, hypothèses d'image obsolète | | Priorité d'ingénierie | Débit, flexibilité, interaction utilisateur | Déterminisme, répétabilité, comportement sûr de la machine |

La norme IEC 61131-3 définit les langages de programmation et les concepts d'exécution utilisés dans le contrôle industriel, notamment le schéma à contacts (Ladder), le schéma fonctionnel (FBD), le texte structuré (ST) et le grafcet (SFC) (IEC, 2013). En pratique, le contrôle par automate dépend du comportement déterministe des tâches, de la gestion explicite des états et d'un ordre de scrutation prévisible. Les logiciels Web supposent souvent que le monde peut attendre l'événement suivant. Les pompes, les vérins et les convoyeurs ne le peuvent généralement pas.

Le contraste important

Le contraste est clair : réponse aux événements versus contrôle cyclique.

Cette différence est importante car l'automatisation physique ne consiste pas seulement à calculer un résultat. Il s'agit de calculer le résultat au bon moment, dans le bon ordre, en fonction des conditions changeantes de l'usine.

L'exécution séquentielle en Ladder signifie que le contrôleur évalue la logique dans un ordre défini, et non tout en même temps. Dans une scrutation conventionnelle, le programme est résolu barreau par barreau, du haut de la routine vers le bas, et au sein de chaque barreau de gauche à droite selon les règles d'exécution de la plateforme.

Conséquences observables de l'exécution séquentielle

- Le dépannage doit distinguer :

• Une logique antérieure peut définir un bit interne qu'une logique ultérieure utilise immédiatement.
• Une logique ultérieure peut écraser un résultat établi plus tôt dans la même scrutation.
• Des états intermédiaires peuvent exister en mémoire pendant l'exécution, même si la sortie physique n'a pas encore changé.
• l'état du tag en mémoire
• l'état de la sortie physique au terminal

Cette distinction est facile à manquer en classe et difficile à ignorer lors de la mise en service.

Fondements IEC

La norme IEC 61131-3 fournit le cadre linguistique, mais la documentation du fournisseur et l'architecture d'exécution déterminent les détails exacts de la planification des tâches et de la mise à jour. L'affirmation sûre est la suivante : l'évaluation séquentielle et l'exécution cyclique sont des comportements fondamentaux dans les systèmes de contrôle par automate grand public, même si les détails d'implémentation diffèrent selon la famille de contrôleurs.

Le syndrome de la double bobine se produit lorsque la même sortie ou bobine mémoire est écrite à plusieurs endroits, permettant à une instruction ultérieure d'écraser une instruction antérieure au cours de la même scrutation. L'état final écrit lors de l'exécution de la logique est celui qui survit jusqu'à l'étape de mise à jour des sorties.

Voici le schéma classique :

BARREAU 1 : La commande de démarrage met Motor_Run à vrai en mémoire. |---[ Start_PB ]-------------------------------------( Motor_Run )---|

BARREAU 2 : Une condition ultérieure écrit sur la même bobine. Si ce barreau s'évalue comme faux de manière à désactiver la même cible, l'état précédent est effectivement écrasé avant que les sorties ne soient écrites. |---[ Some_Other_Condition ]-------------------------( Motor_Run )---|

Ce qui se passe réellement

- Résultat : le moteur peut ne jamais s'activer même si un barreau précédent semblait correct.

• Le premier barreau écrit `Motor_Run = TRUE` en mémoire.
• Un barreau ultérieur écrit sur la même cible.
• La dernière écriture détermine l'état final de la mémoire à la fin de l'exécution.
• La mise à jour de la sortie physique se produit après.

C'est l'exécution déterministe qui fait exactement ce que la logique spécifie, indépendamment de l'intention.

Pourquoi cette erreur est utile pour la formation

Les erreurs de double bobine exposent rapidement trois idées fondamentales :

• l'ordre compte
• l'état de la mémoire n'est pas le même que l'état du terminal
• la correction visuelle d'un barreau ne suffit pas

Dans OLLA Lab, cela devient observable plutôt que théorique, car les utilisateurs peuvent exécuter la logique, inspecter les variables et comparer l'état du Ladder avec le comportement de l'équipement simulé.

Une impulsion courte peut être manquée lorsque sa durée est inférieure à l'opportunité effective du contrôleur de l'échantillonner. Si une entrée s'active et se désactive entre deux scrutations d'entrées, le processeur peut ne jamais enregistrer l'événement dans l'image des entrées.

### Exemple : largeur d'impulsion versus temps de scrutation

Si :

• une impulsion de cellule photoélectrique dure 10 ms, et
• le contrôleur échantillonne les entrées toutes les 20 ms,

alors l'impulsion peut se produire entièrement entre deux scrutations et disparaître du point de vue du programme.

Il s'agit d'un problème d'échantillonnage. Dans le travail de contrôle, cela apparaît souvent comme : « le capteur s'est certainement déclenché, mais l'automate ne l'a jamais vu ». Les deux affirmations peuvent être vraies.

Pourquoi les ingénieurs devraient s'en soucier

Les impulsions manquées affectent :

• le tri à haute vitesse
• la logique adjacente aux codeurs
• la confirmation de rejet
• le comptage de bouteilles ou de cartons
• les signaux de preuve intermittents
• les alarmes déclenchées sur front

La solution peut impliquer des tâches plus rapides, un verrouillage matériel, un étirement d'impulsion, des monostables, des compteurs rapides ou une conception de séquence révisée. La réponse correcte dépend du processus et de l'architecture du contrôleur.

OLLA Lab reproduit la scrutation physique du processeur en fournissant un environnement de simulation structuré dans lequel la logique Ladder est exécutée comme une boucle déterministe plutôt que comme des réactions d'événements de navigateur lâches. Plus simplement, il est conçu pour permettre aux utilisateurs d'observer le comportement de contrôle dépendant de la scrutation, et pas seulement de dessiner des barreaux.

Ce qu'OLLA Lab fait en termes bornés

Au sein de la plateforme, les utilisateurs peuvent :

• construire une logique Ladder dans un éditeur basé sur le Web
• exécuter la logique en mode simulation
• basculer et inspecter les entrées, sorties et variables
• travailler sur des scénarios industriels réalistes
• comparer le comportement du Ladder avec des vues d'équipement 3D/WebXR/VR lorsque disponibles
• utiliser GeniAI, le guide de laboratoire IA, pour un support guidé

Pour la portée de cet article, le fait produit est plus étroit : OLLA Lab fournit un environnement basé sur logiciel pour répéter l'exécution de logique déterministe et observer comment le timing de scrutation affecte le comportement de la machine.

Comportements observables que la plateforme est adaptée à démontrer

• Comportement d'écrasement par double bobine
• Impulsions transitoires manquées
• Traçage de cause à effet à travers les E/S
• Erreurs de séquence causées par des hypothèses obsolètes sur l'état
• Différences entre l'état du Ladder et l'état de l'équipement simulé

Cela le rend utile comme environnement de répétition de type logiciel dans la boucle pour les tâches de mise en service à haut risque. Il ne remplace pas les tests de réception du matériel, la validation de la sécurité ou la mise en service spécifique au site. Ceux-ci appartiennent toujours au système réel, avec le contrôleur réel, sous les contraintes réelles.

Pourquoi la livraison par navigateur est importante

Un environnement basé sur navigateur réduit la friction de configuration pour l'apprentissage et la révision. Plus important encore, il permet une injection de fautes répétée et à faible risque sans immobiliser un formateur physique ou du matériel adjacent à la production.

Dans ce contexte, la validation par jumeau numérique signifie tester la logique Ladder par rapport à un modèle de machine ou de processus simulé et vérifier si le comportement attendu de l'équipement correspond à la philosophie de contrôle dans des conditions normales et anormales.

Cette définition doit rester ancrée. Elle ne signifie pas que la simulation est un substitut légalement suffisant pour la réception sur site, la vérification SIL ou la mise en service de l'usine.

### Sur le plan opérationnel, la validation par jumeau numérique comprend :

• la comparaison des états de commande avec la réponse de l'équipement simulé
• la vérification de l'ordre de séquence et des permissifs
• la vérification du comportement des alarmes et des déclenchements
• l'observation des changements d'état analogiques ou pilotés par PID lorsqu'ils sont modélisés
• l'injection de fautes et la confirmation de la réponse logique
• la révision du programme et le re-test

C'est là qu'OLLA Lab devient opérationnellement utile. Il permet aux ingénieurs de tester si une séquence fonctionne sur un modèle réaliste avant de la tester sur un équipement qui peut se bloquer, déborder, dépasser sa course ou échouer de manière coûteuse.

Les ingénieurs devraient pratiquer la gestion des erreurs dépendantes de la scrutation en construisant des scénarios où la logique est forcée d'échouer pour des raisons de timing, puis en révisant la conception jusqu'à ce que le mode de défaillance soit contrôlé et explicable.

### Un exercice pratique : capture d'impulsion dans un scénario de convoyeur

Utilisez un scénario de type convoyeur ou tri et définissez un événement de capteur transitoire plus court que l'intervalle de scrutation simulé.

#### Étape 1 : Construire la logique initiale

Créez une logique qui dépend directement d'une impulsion de cellule photoélectrique pour déclencher une action telle qu'un rejet, un comptage ou une déviation.

#### Étape 2 : Définir les conditions simulées

Utilisez un intervalle de scrutation plus long que la durée de l'impulsion. Exécutez ensuite le scénario et observez si l'événement est capturé de manière fiable.

#### Étape 3 : Inspecter les variables et l'état de l'équipement

Utilisez le panneau des variables pour comparer :

• l'état de l'entrée
• les bits de mémoire interne
• les commandes de sortie
• la réponse de l'équipement simulé

#### Étape 4 : Injecter le cas de défaillance

Forcez une impulsion qui se produit trop rapidement pour les hypothèses de scrutation actuelles. Confirmez que la logique la manque.

#### Étape 5 : Réviser la logique

Les révisions possibles incluent :

• l'ajout d'un verrouillage ou d'un chemin de maintien
• l'utilisation de la détection de front le cas échéant
• l'étirement de l'impulsion dans la logique
• la reconception de la séquence pour éviter la dépendance à un transitoire étroit
• la documentation des cas où des fonctionnalités matérielles seraient requises dans un contrôleur réel

#### Étape 6 : Ré-exécuter et vérifier

Validez que la logique révisée capture l'événement dans les conditions définies et ne crée pas de faux positifs ou de persistance dangereuse.

Une galerie de captures d'écran prouve que le logiciel a été ouvert. Elle ne prouve pas le jugement technique. Si un apprenant veut démontrer une réelle compréhension du contrôle, l'artefact doit montrer le raisonnement, la gestion des erreurs et la discipline de révision.

Utilisez cette structure :

Indiquez exactement ce que signifie un comportement correct. Exemple : « Une impulsion de détection de produit de 10 ms doit être capturée et verrouillée afin que la séquence de rejet s'exécute une fois et une seule. »

Documentez la défaillance dépendante de la scrutation. Exemple : « L'impulsion a été manquée lorsque le temps de scrutation a dépassé la largeur d'impulsion. »

1. Description du système Définissez la machine ou le segment de processus, l'objectif de contrôle et les E/S pertinentes.
2. Définition opérationnelle du comportement correct
3. Logique Ladder et état de l'équipement simulé Montrez les barreaux, les tags pertinents et le comportement correspondant de la machine simulée.
4. Le cas de défaillance injecté
5. La révision effectuée Expliquez ce qui a changé dans la logique et pourquoi.
6. Leçons apprises Résumez le principe de contrôle, tel que le timing de la table d'image, le comportement d'écrasement ou pourquoi la capture d'impulsion nécessite une conception explicite.

C'est le genre de preuve qu'un examinateur peut interroger. C'est aussi celle qui tend à mieux résister à une revue technique qu'une simple capture d'écran.

La simulation du cycle de scrutation est précieuse car elle rend observable le comportement invisible du contrôleur. Ses limites comptent tout autant.

Une déclaration bornée de ce que la simulation peut et ne peut pas faire

La simulation peut aider les ingénieurs à :

• comprendre l'exécution déterministe
• tester la logique de séquence
• observer les erreurs liées au timing
• répéter le dépannage
• comparer le comportement attendu et simulé de l'équipement

La simulation ne peut pas, par elle-même :

• certifier la compétence sur site
• remplacer la validation spécifique au matériel
• établir la conformité à la sécurité fonctionnelle
• prouver le comportement final du timing du bus de terrain
• se substituer aux FAT, SAT, tests de boucle ou mise en service réelle

Cette limite n'est pas une faiblesse. Elle fait partie de ce qui maintient la crédibilité de l'outil.

La formation basée sur la simulation et les modèles numériques sont bien établis dans l'ingénierie industrielle, surtout là où l'expérimentation directe sur des actifs réels est coûteuse ou dangereuse. La littérature soutient généralement la simulation comme un moyen d'améliorer la compréhension du comportement dynamique, de la réponse aux erreurs et de la préparation des opérateurs ou des ingénieurs, tout en soulignant que la fidélité du modèle et la conception de la tâche déterminent l'utilité.

Normes pertinentes et fondements techniques

• IEC 61131-3 définit les cadres des langages de programmation des automates et les concepts d'exécution pertinents pour le comportement de la logique Ladder (IEC, 2013).
• IEC 61508 établit le cadre plus large de la sécurité fonctionnelle et renforce le fait que les déclarations de sécurité nécessitent des preuves de cycle de vie disciplinées, et non une simple confiance informelle dans la simulation (IEC, 2010).
• exida et les conseils connexes en matière de sécurité fonctionnelle soulignent la vérification, la validation et la rigueur du cycle de vie dans le travail d'automatisation lié à la sécurité.
• La recherche en simulation industrielle, jumeaux numériques et environnements de formation a montré une valeur dans la répétition des erreurs, la préparation à la mise en service et la compréhension humaine des systèmes dynamiques, en particulier lorsque la simulation est liée au comportement observable du processus plutôt qu'à la seule instruction abstraite.

La conclusion prudente est la suivante : la simulation est plus forte lorsqu'elle est utilisée pour exposer des comportements, tester des hypothèses et améliorer le jugement avant le déploiement. Elle est plus faible lorsqu'elle est traitée comme un raccourci contournant les preuves d'ingénierie.

La maîtrise du cycle de scrutation compte parce que le contrôle déterministe n'est pas intuitif pour les personnes formées aux logiciels pilotés par événements ou aux exemples Ladder statiques. Un automate ne remarque pas tout au moment où cela se produit. Il échantillonne, résout, écrit et répète.

C'est pourquoi OLLA Lab a une place légitime dans le flux de travail. Il donne aux ingénieurs un environnement borné pour observer l'ordre de scrutation, inspecter l'état des E/S, injecter des erreurs et réviser la logique avant que ces mêmes erreurs n'atteignent un processus réel. Il ne s'agit pas de rendre la simulation impressionnante. Il s'agit de rendre la défaillance visible alors que le coût de l'erreur est encore tolérable.

En termes pratiques, c'est le passage de la syntaxe à la déployabilité.

Ampergon Vallis Lab est une équipe de recherche technique dédiée à l'amélioration de la formation en ingénierie industrielle et à la simulation de systèmes de contrôle.

Cet article a été révisé par les ingénieurs d'Ampergon Vallis pour garantir la conformité avec les principes de la norme IEC 61131-3 et les pratiques de simulation industrielle.

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standard overview - NIST Smart Manufacturing Profile - IEEE Access: Digital twin enabling technologies (DOI)