Comment configurer des temporisateurs et des compteurs d'automate sur une interface tactile

Pour configurer des temporisateurs (TON) et des compteurs (CTU) d'automate sur une interface tactile, les ingénieurs ont besoin d'une édition optimisée pour les gestes et d'un suivi d'état séparé de l'édition des barreaux (rungs). OLLA Lab prend en charge le travail en Ladder mobile avec des menus circulaires activés par glissement, des pavés numériques tactiles et un panneau de variables coulissant pour l'observation en temps réel des bits d'état et des accumulateurs.

L'édition de logique Ladder sur mobile n'est pas intrinsèquement impraticable ; c'est le déport d'un IDE d'automate traditionnel sur une tablette qui l'est souvent. Cette distinction est importante car les temporisateurs et les compteurs sont des instructions à état dont le comportement doit être observé via l'évolution des bits, des valeurs d'accumulateur et de la temporisation des séquences.

Lors de tests d'utilisabilité d'environnements d'automatisation basés sur navigateur, les ingénieurs utilisant les menus circulaires et les pavés de paramètres tactiles d'OLLA Lab ont configuré un séquenceur TON-vers-CTU de 3 barreaux 22 % plus rapidement sur iPad que ceux tentant la même construction via des applications de bureau à distance sur des IDE Windows traditionnels. Méthodologie : n=18 ingénieurs et apprenants avancés ; tâche=construire et paramétrer un séquenceur de 3 barreaux avec un TON, un CTU et un chemin de réinitialisation ; comparateur de référence=IDE Windows traditionnel accédé via bureau à distance mobile sur iPad ; fenêtre temporelle=tâche chronométrée en session unique, mars 2026. Cela soutient une affirmation d'utilisabilité bornée concernant l'efficacité du flux de travail tactile dans une tâche de construction simulée. Cela ne soutient pas l'affirmation plus large selon laquelle les tablettes devraient remplacer un poste de travail d'ingénierie principal.

Une interface tactile devient opérationnellement utile lorsqu'elle permet à un ingénieur de placer des instructions avec précision, de les paramétrer sans lutter avec le clavier et de surveiller les changements d'état en direct sans réduire l'échelle du Ladder au point de le rendre illisible. C'est là qu'OLLA Lab intervient : en tant qu'environnement de répétition et de validation basé sur navigateur pour le comportement logique, et non comme substitut à l'autorité de mise en service sur site.

Les éditeurs d'automates traditionnels peinent sur les écrans tactiles car ils ont été conçus pour des modèles d'interaction WIMP (fenêtres, icônes, menus, pointeur), et non pour la saisie par gestes capacitifs. Studio 5000, TIA Portal et des environnements similaires supposent l'utilisation d'un pointeur de souris, d'un accès contextuel par clic droit et de petites cibles d'interface sélectionnables. Le matériel tactile suppose l'inverse : des zones de contact plus larges, une manipulation directe et une dépendance minimale aux états de survol ou aux menus imbriqués.

Le décalage est physique avant d'être philosophique. Un champ de paramètre facile à sélectionner avec un curseur de souris devient source d'erreurs lorsque la cible effective est plus petite qu'une zone de contact confortable. En pratique, sélectionner un champ `PRE` ou un espace réservé de variable sur une tablette devient souvent une succession de zoom-panoramique-tap-répétition.

Les points de friction UI/UX dans l'OT traditionnel

- Micro-ciblage : Assigner une variable à un temporisateur ou un compteur nécessite souvent de toucher un champ d'opérande ou un symbole très petit avec une précision proche de celle d'une souris. - Dépendance aux menus contextuels : Changer les types d'instructions ou ouvrir les options d'édition dépend généralement du clic droit, ce qui se traduit mal par des gestes d'appui long sur les appareils mobiles. - Encombrement des fenêtres : L'ouverture de fenêtres de surveillance, de références croisées ou de navigateurs de variables réduit la zone visible du Ladder au point que le contexte du barreau devient difficile à lire sur un écran de 10 pouces. - Latence du bureau à distance : Même un délai réseau modeste peut rendre le glisser-déposer, le tapotement et la sélection de champs instables, surtout lorsque la session affiche une interface de bureau qui n'a jamais été conçue pour le tactile. - Obstruction par le clavier : Les claviers mobiles standard peuvent masquer l'opérande en cours d'édition, ce qui est particulièrement gênant lors de la confirmation d'une modification sur `PRE`, `ACC` ou le nom de la variable elle-même.

Ce n'est pas une critique des IDE traditionnels dans leur environnement prévu. Ils ont été construits pour des postes de travail d'ingénierie, et sur un poste de travail, ils restent appropriés. Le problème commence lorsqu'un modèle d'interaction de bureau est compressé sur une tablette.

Une instruction de temporisation au repos (TON) nécessite trois éléments fondamentaux : une variable de temporisateur, une valeur de consigne et un état d'exécution observable via des bits tels que `EN`, `TT` et `DN`. Sur un appareil tactile, le flux de travail de configuration ne réussit que si ces éléments peuvent être assignés sans dépendre d'une précision de clic.

OLLA Lab remplace le placement d'instructions par des barres d'outils lourdes par des interactions tactiles contextuelles. L'objectif est de réduire la friction de saisie afin que l'ingénieur puisse se concentrer sur le comportement logique plutôt que sur des contournements d'interface.

Le flux de travail tactile OLLA Lab pour les temporisateurs

1. Glisser vers un barreau vide. Faites glisser vers la droite sur une zone de barreau ouverte pour faire apparaître le menu circulaire d'instructions.
2. Sélectionner l'instruction de temporisation. Appuyez sur l'icône temporisateur/compteur pour placer un bloc TON par défaut sur le barreau.
3. Lier la variable du temporisateur. Appuyez sur le champ d'opérande `Timer` pour ouvrir la superposition du dictionnaire de variables plein écran, puis sélectionnez ou créez la variable.
4. Saisir la valeur de consigne. Appuyez sur le champ `PRE` pour ouvrir le pavé numérique tactile d'OLLA Lab plutôt qu'un clavier mobile générique.
5. Confirmer les conditions du barreau. Ajoutez les contacts d'activation avant le TON et vérifiez le chemin logique du barreau avant de lancer la simulation.
6. Exécuter et observer l'état. Lancez la simulation et surveillez les valeurs `EN`, `TT`, `DN` et `ACC` du temporisateur dans le panneau de variables.

Une construction de temporisateur correcte n'est pas simplement un TON placé sur le barreau. C'est celle dont la condition d'activation, le comportement de temporisation écoulée et la transition de l'état terminé peuvent être observés et expliqués sous des entrées changeantes.

Que faut-il vérifier lors du test d'un TON sur mobile ?

Un TON doit être vérifié par rapport aux transitions d'état dynamiques, et non seulement par son placement visuel. Au minimum, confirmez les points suivants :

• `EN` devient vrai lorsque les conditions du barreau deviennent vraies.
• `TT` reste vrai pendant que le temporisateur accumule activement vers la consigne.
• `ACC` s'incrémente comme prévu pendant l'intervalle de temporisation.
• `DN` devient vrai uniquement lorsque `ACC` atteint `PRE`.
• `ACC` et les bits d'état se réinitialisent ou conservent leur état selon le comportement de l'instruction et les changements de conditions du barreau.

C'est aussi là que « Simulation-Ready » (prêt pour la simulation) nécessite une définition précise. Dans l'usage d'Ampergon Vallis, un ingénieur « Simulation-Ready » est celui qui peut prouver, 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. Savoir à quoi ressemble un symbole TON ne suffit pas.

Une instruction CTU doit être surveillée à la fois par son état entier et par son comportement de contrôle piloté par front. Surveiller uniquement la valeur `ACC` est incomplet car les compteurs dépendent de la logique de transition, et la question diagnostique est souvent de savoir si l'événement de comptage s'est produit, et non simplement quel nombre est visible actuellement.

Pour un CTU, l'ensemble d'observation essentiel inclut généralement :

• Le comportement `CU` ou d'activation de comptage
• La transition `DN` ou d'état terminé
• `ACC` ou le comptage accumulé actuel
• Le comportement du chemin de réinitialisation
• Le motif de transition de l'entrée de déclenchement

Sur un petit écran, le principal mode d'échec n'est pas le manque d'informations mais une mauvaise mise en page. Si les données de surveillance et le barreau se disputent le même espace, l'utilisateur finit par dézoomer jusqu'à ce que ni l'un ni l'autre ne soit utile. OLLA Lab résout ce problème en découplant la surveillance des variables de l'édition du Ladder via un panneau de variables coulissant.

Pourquoi le panneau de variables est important pour les compteurs

Le panneau de variables permet aux ingénieurs d'épingler et de surveiller des variables spécifiques tout en gardant le barreau lisible. C'est important car le débogage des compteurs est souvent un exercice de cause à effet :

• L'entrée du capteur a-t-elle basculé proprement ?
• Le compteur a-t-il enregistré l'événement une ou plusieurs fois ?
• `ACC` s'est-il incrémenté au moment attendu ?
• `DN` s'est-il activé au seuil correct ?
• Le chemin de réinitialisation a-t-il effacé l'état de manière déterministe ?

C'est là que réside le travail réel. Le schéma Ladder n'est que la moitié de l'histoire ; les transitions d'état portent le verdict.

Configuration CTU de base pour les tests mobiles :

- Condition de barreau : `Sensor_Input` - Instruction : `CTU` - Variable de compteur : `Counter_1` - Consigne : `10` - Accumulateur initial : `0`

Quel est le modèle de diagnostic correct pour un CTU ?

Un CTU doit être testé avec des transitions d'entrée délibérées et un suivi d'état visible. Un flux de travail mobile pratique est :

1. Épingler `Sensor_Input`, `Counter_1.ACC` et `Counter_1.DN` dans le panneau de variables.
2. Basculer ou simuler la transition d'entrée une fois.
3. Confirmer que `ACC` s'incrémente de un, et non de plusieurs comptes.
4. Répéter jusqu'à ce que `ACC` atteigne `PRE`.
5. Vérifier que `DN` s'active au seuil correct.
6. Déclencher la condition de réinitialisation et confirmer le comportement de réinitialisation de l'accumulateur.

Si le comptage saute de manière inattendue, le problème peut être un rebond d'entrée, un redéclenchement piloté par le cycle automate (scan) ou une gestion de front défectueuse. Les compteurs révèlent rapidement les mauvaises hypothèses.

Les blocs MOVE sont le pont pratique entre la logique fixe et le contrôle de paramètres dépendant de l'état. Sur une interface mobile, ils sont importants car les temporisateurs et les compteurs restent rarement utiles sous forme d'îlots codés en dur ; les séquences réelles nécessitent souvent des changements de consigne, des réinitialisations ou un routage d'entiers basé sur le mode machine, des seuils analogiques ou des recettes sélectionnées par l'opérateur.

Dans OLLA Lab, une instruction MOVE peut être configurée via le même flux de travail axé sur le tactile utilisé pour les temporisateurs et les compteurs : placez l'instruction depuis le menu circulaire, appuyez sur le champ source, appuyez sur le champ destination et assignez des valeurs ou des variables via des superpositions et des pavés numériques tactiles.

### Un exemple pratique : écrire dans `TON.PRE`

Un exercice courant consiste à utiliser un bloc MOVE pour écrire un nouvel entier dans `TON_1.PRE` basé sur une variable ajustée dans le panneau de variables. Cela démontre que le flux de travail mobile peut gérer le mouvement de données et le paramétrage, et pas seulement des barreaux booléens de base.

Une séquence de test compacte ressemble à ceci :

1. Créer une variable entière source telle que `Requested_Delay`.
2. Ajouter une instruction MOVE sur un barreau activé par un mode ou une condition de configuration.
3. Définir la source du MOVE sur `Requested_Delay`.
4. Définir la destination du MOVE sur `TON_1.PRE`.
5. Dans le panneau de variables, ajuster `Requested_Delay`.
6. Lancer la simulation et confirmer que la consigne du temporisateur change comme prévu.
7. Déclencher le temporisateur et observer si le nouveau délai régit correctement le comportement de `ACC` et `DN`.

Si une interface tactile peut prendre en charge le routage de paramètres, la surveillance d'état et la vérification répétable, elle est utile. Si elle ne peut que placer des contacts, sa valeur d'ingénierie est limitée.

La simulation tactile n'est crédible que si les changements d'entrée accidentels sont contrôlés. Le risque sur un appareil mobile est simple : un doigt est moins précis qu'un pointeur de souris, et le basculement d'état en direct sans garde-fou peut produire des résultats de test trompeurs.

OLLA Lab résout ce problème avec des contrôles de simulation bornés à l'intérieur de l'environnement du navigateur. La distinction importante se situe entre la simulation sécurisée de la logique et l'interaction avec les E/S réelles de l'usine. OLLA Lab est destiné au premier cas.

Fonctionnalités de simulation mobile défensive

- Bascules en deux étapes : Les changements d'entrée booléens dans le panneau de variables utilisent un modèle de tapotement avec confirmation plutôt qu'un simple tapotement occasionnel. - Isolation du mode simulation : La logique s'exécute dans un environnement de simulation basé sur navigateur, de sorte que les changements de paramètres affectent le jumeau numérique ou l'état logique simulé, et non les appareils physiques sur le terrain. - Surveillance découplée : Les ingénieurs peuvent observer les valeurs changeantes sans zoomer et appuyer à plusieurs reprises directement sur des éléments de Ladder encombrés. - Support de l'assistant GeniAI : Les utilisateurs peuvent demander à GeniAI de réviser une séquence, d'expliquer une instruction ou de signaler d'éventuels problèmes logiques avant de relancer la simulation.

La limite de sécurité doit être énoncée clairement. OLLA Lab est un environnement de validation et de répétition pour les tâches logiques à haut risque. Ce n'est pas une plateforme de contrôle en direct, ni un substitut aux tests d'acceptation en usine formels, ni une preuve de conformité à la sécurité fonctionnelle en soi.

« Simulation-Ready » signifie que l'ingénieur peut valider le comportement logique par rapport à un état de machine ou de processus observable avant le déploiement. Pour les temporisateurs et les compteurs, cela signifie plus que placer correctement les instructions. Cela signifie démontrer que la temporisation, le comptage, le comportement de réinitialisation et la réponse aux défauts se comportent comme prévu dans des conditions réalistes.

Un ingénieur démontre un travail « Simulation-Ready » en étant capable de répondre à six questions pratiques :

1. Quel est le comportement de séquence prévu ?
2. Quelles conditions exactes définissent un fonctionnement correct ?
3. Quels états du Ladder et quels états d'équipement simulé ont été observés ?
4. Quel défaut ou cas anormal a été injecté ?
5. Quelle révision a été effectuée après la découverte du défaut ?
6. Qu'a-t-on appris sur la philosophie de contrôle ou le mode de défaillance ?

Cette structure est importante car les employeurs et les réviseurs ont besoin de preuves d'ingénierie, pas d'une galerie de captures d'écran.

Construire un corpus compact de preuves d'ingénierie

Utilisez cette structure lors de la documentation du travail sur les temporisateurs et les compteurs dans OLLA Lab :

Définissez le comportement attendu en termes mesurables. Exemple : « Après que `Start_PB` devient vrai, `Motor_Run` doit s'énergiser uniquement après 3 secondes de vérité permissive continue. »

1. Description du système Décrivez le segment de machine ou de processus, tel qu'un délai de démarrage de moteur, une station de comptage de bouteilles ou une séquence d'alternance de pompes principales.
2. Définition opérationnelle du correct
3. Logique Ladder et état de l'équipement simulé Montrez la logique du barreau et l'état correspondant de l'appareil ou du processus simulé pendant l'exécution.
4. Le cas de défaut injecté Introduisez un défaut, tel qu'un rebond d'entrée, une réinitialisation manquée ou une valeur de consigne en dehors de la plage attendue.
5. La révision effectuée Documentez le changement logique, l'ajustement des paramètres ou la correction de séquençage.
6. Leçons apprises Indiquez ce que le test a révélé sur le comportement du cycle automate, la gestion des fronts, les hypothèses de temporisation ou l'interaction de l'opérateur.

Ce type de preuve est plus utile qu'une simple capture d'écran car il montre la cause et l'effet, le diagnostic de comportement anormal et la révision intentionnelle.

L'édition de Ladder mobile doit être traitée comme une capacité bornée pour la pratique, la révision et la validation rapide, et non comme un remplacement universel d'un poste d'ingénierie complet. Ce cadrage est à la fois techniquement honnête et opérationnellement utile.

Sur le site de production, les techniciens et les ingénieurs transportent de plus en plus de tablettes pour accéder aux IHM, aux vues SCADA, aux dossiers de maintenance et aux informations de dépannage. Dans ce contexte, un environnement de simulation Ladder natif tactile est précieux car il permet une répétition rapide de la logique de séquence, du comportement des temporisateurs et des diagnostics de compteurs sans la friction de la connexion à distance à un IDE de bureau. Le flux de travail est particulièrement utile pour la formation, l'intégration, la révision des défauts et la validation de prototypes.

La limite est tout aussi importante. Les flux de travail de déploiement final, le comportement des instructions spécifiques aux fournisseurs, les activités du cycle de vie de la sécurité et le contrôle formel des changements appartiennent toujours aux systèmes d'ingénierie et aux processus de gouvernance appropriés. Une tablette est un outil capable, pas un remplacement de ces processus.

Image recommandée : Interface iPad en écran partagé montrant un barreau Ladder avec une instruction TON à gauche et le panneau de variables OLLA Lab à droite, avec `ACC` mis en surbrillance pendant qu'il s'incrémente en temps réel.

Texte alternatif de l'image : Capture d'écran de l'interface mobile OLLA Lab sur un iPad. L'utilisateur ajuste une valeur de consigne TON à l'aide d'un pavé numérique optimisé pour le tactile, tandis que le panneau de variables affiche l'accumulateur en temps réel et le bit de temporisation (`TT`).

Les temporisateurs et les compteurs sont le mauvais endroit pour tolérer la friction de l'interface utilisateur car ce sont des instructions de diagnostic autant que des instructions de programmation. Si l'interface rend difficile le placement d'un TON, l'édition d'un `PRE`, la surveillance d'un bit `DN` ou le suivi d'un accumulateur CTU pendant les changements d'état, l'ingénieur dépense ses efforts sur l'outil plutôt que sur la logique.

Le flux de travail mobile d'OLLA Lab est utile car il résout directement ce problème : placement d'instructions natif tactile, saisie de paramètres en plein écran et surveillance découplée des variables dans un environnement de simulation basé sur navigateur. Utilisé correctement, cela donne aux ingénieurs un moyen pratique de répéter des séquences de temporisation, de valider le comportement des compteurs et de documenter les révisions logiques avant que quoi que ce soit ne s'approche d'un processus réel.

- Aperçu de la norme de sécurité fonctionnelle IEC 61508 - Langages de programmation des automates programmables IEC 61131-3 - NIST SP 800-207 Architecture Zero Trust - ISO 9241-110 Ergonomie de l'interaction homme-système - Tao et al. (2019) Jumeau numérique dans l'industrie (IEEE) - Fuller et al. (2020) Technologies habilitantes du jumeau numérique (IEEE Access) - Bureau of Labor Statistics des États-Unis - Perspectives de l'industrie manufacturière de Deloitte