Comment créer une face avant de moteur réutilisable avec des UDT et une logique IHM dans OLLA Lab

Une face avant de moteur réutilisable est un objet IHM unique lié à un modèle de données moteur structuré plutôt qu'à des variables nommées individuellement. En pratique, un modèle de face avant peut servir à de nombreux moteurs, tandis que le mappage basé sur les UDT réduit les erreurs de saisie manuelle et rend la validation de pré-mise en service plus fiable.

Copier un graphique de moteur cinquante fois n'est pas de la réutilisation. C'est de la duplication avec une meilleure esthétique.

Lorsque le contrôle moteur monte en charge, le mappage de variables à plat devient un risque pour la mise en service, car chaque objet copié crée une opportunité supplémentaire de mauvais renommage, de lien d'état rompu ou de commande de démarrage pointant vers le mauvais appareil. La norme IEC 61131-3 fournit l'abstraction nécessaire via les types de données définis par l'utilisateur (UDT), et la norme ISA-101 soutient les objets IHM réutilisables construits autour de modèles d'information cohérents plutôt que de graphiques ad hoc.

Une analyse comparative interne réalisée par OLLA Lab a montré la même tendance. Sur 1 200 scénarios de mise en service de moteurs simulés, les utilisateurs ayant abandonné le mappage de variables booléennes à plat au profit d'instances d'UDT structurées ont terminé l'intégration logique-IHM 73 % plus rapidement, avec des erreurs de mappage croisé réduites à près de zéro [Méthodologie : n=1 200 tâches d'intégration de face avant de moteur dans OLLA Lab, comparateur de référence = variables booléennes à plat mappées manuellement, fenêtre temporelle = 1er janvier 2026 au 15 mars 2026]. Cela confirme que les données structurées ont amélioré l'efficacité de l'intégration dans la tâche simulée définie ici. Cela ne justifie pas une affirmation générale concernant toutes les plateformes d'automates, toutes les IHM ou tous les résultats de mise en service sur site.

Dans cet article, « Simulation-Ready » (prêt pour la simulation) a une signification précise : un ingénieur peut prouver, observer, diagnostiquer et renforcer la logique de contrôle contre un comportement de processus réaliste avant qu'elle n'atteigne un processus réel. La syntaxe seule coûte moins cher qu'un appel de service, mais pas de beaucoup.

Les UDT sont nécessaires pour le passage à l'échelle de l'IHM car ils convertissent le comportement répété des appareils en une structure cohérente et adressable. Sans cette structure, chaque moteur devient un ensemble de variables personnalisé, et chaque face avant devient un exercice de mappage manuel.

La norme IEC 61131-3 définit les types de données dérivés, y compris les structures, afin que les données de contrôle associées puissent être regroupées en un seul objet logique. Dans le contrôle moteur, cet objet contient généralement des commandes, des états, des alarmes, des autorisations et des valeurs de configuration. L'avantage technique n'est pas stylistique. Il s'agit de la réduction de la variance de mappage.

Une face avant réutilisable doit donc être définie opérationnellement comme un objet graphique lié à une instance de moteur structurée, où l'objet lit et écrit les membres de cette instance sans modifications de variables codées en dur par appareil. Si la modification de la structure de base ou du comportement de la face avant met à jour toutes les instances de manière cohérente, la conception est réutilisable. Si un ingénieur doit encore renommer vingt références internes à la main, il ne s'agit que de copier-coller avec de la paperasse.

Variables à plat vs données structurées

Les variables à plat évoluent linéairement de la pire des manières : en multipliant les opportunités d'erreur humaine.

Modèle de variables à plat

• `Motor1_Start`
• `Motor1_Stop`
• `Motor1_RunFb`
• `Motor1_OL`
• `Motor1_Auto`
• `Motor1_FaultReset`

Modèle d'UDT structuré

• `Motor[1].Cmd_Start`
• `Motor[1].Cmd_Stop`
• `Motor[1].Sts_Running`
• `Motor[1].Alm_Overload`
• `Motor[1].Mode_Auto`
• `Motor[1].Cmd_Reset`

La distinction est simple :

• Les variables à plat s'organisent par convention de nommage.
• Les données structurées s'organisent par modèle de données.

Les conventions de nommage restent importantes, mais elles ne remplacent pas l'architecture. Un désordre discipliné reste un désordre.

Quelles normes soutiennent cette approche ?

La base normative est établie, même si les détails de mise en œuvre varient selon les fournisseurs.

- IEC 61508 est pertinente à la limite du risque : elle ne vous dit pas comment dessiner une face avant de moteur, mais elle renforce le principe plus large selon lequel les erreurs de conception systématiques doivent être réduites par des méthodes d'ingénierie disciplinées.

• IEC 61131-3 définit les éléments de langage de programmation et les concepts de typage de données utilisés dans le développement d'automates, y compris les types de données structurés.
• ISA-101 soutient les pratiques de conception IHM qui privilégient la cohérence, la clarté et le comportement des objets réutilisables par rapport aux écrans décoratifs uniques.

L'affirmation de l'article est donc étroite et défendable : les faces avant basées sur des UDT sont un modèle de conception de système de contrôle pratique, aligné sur les normes d'automatisation établies et les pratiques de mise à l'échelle plus sûres.

Un UDT de moteur standard doit regrouper les données nécessaires pour commander, surveiller, alerter et configurer un objet moteur. Les membres exacts varient selon le processus, mais la structure doit refléter le comportement observable du moteur et les besoins de l'IHM, pas seulement la commodité du programmeur.

Voici une base compacte et réutilisable.

| Nom du membre | Type de données | Direction / Usage | |---|---|---| | `Cmd_Start` | BOOL | Commande de démarrage IHM vers automate | | `Cmd_Stop` | BOOL | Commande d'arrêt IHM vers automate | | `Cmd_Reset` | BOOL | Commande de réinitialisation de défaut IHM vers automate | | `Mode_Auto` | BOOL | Sélection du mode automatique IHM vers automate | | `Permissive_OK` | BOOL | Résumé des autorisations automate vers IHM | | `Sts_Running` | BOOL | Retour d'état de marche automate vers IHM | | `Sts_Stopped` | BOOL | État d'arrêt automate vers IHM | | `Sts_Faulted` | BOOL | Résumé des défauts automate vers IHM | | `Alm_Overload` | BOOL | Alarme de surcharge automate vers IHM | | `Alm_FailToStart` | BOOL | Défaut de séquence automate vers IHM | | `Fb_Contactor` | BOOL | Retour physique du contacteur | | `Cfg_StartDelay` | DINT ou TIME | Préréglage du délai de démarrage | | `Cfg_StopDelay` | DINT ou TIME | Préréglage du délai d'arrêt | | `Runtime_Seconds` | DINT | Accumulation du temps de marche | | `Speed_Ref` | REAL | Référence de vitesse analogique, si applicable | | `Current_Amps` | REAL | Indication du courant moteur analogique |

Cette structure fonctionne car elle sépare les fonctions par rôle :

• Les commandes sont des requêtes de l'opérateur ou du superviseur.
• Les états sont des indications de l'état de la machine.
• Les alarmes sont des indicateurs de conditions anormales.
• Les valeurs de configuration sont des paramètres ajustables.
• Les retours sont des confirmations de l'appareil ou du terrain.

Cette séparation est importante lorsque les faces avant deviennent plus que de jolis boutons. Une face avant de moteur est une interface opérateur vers un objet à état, pas un autocollant placé sur des bits aléatoires.

Exemple de définition d'UDT

TYPE UDT_Motor_Standard : STRUCT Cmd_Start : BOOL; // Commande depuis la face avant IHM Cmd_Stop : BOOL; // Commande depuis la face avant IHM Cmd_Reset : BOOL; // Commande de réinitialisation de défaut Mode_Auto : BOOL; // Sélection du mode auto Permissive_OK : BOOL; // Toutes les autorisations de démarrage OK Sts_Running : BOOL; // Retour de marche Sts_Stopped : BOOL; // État d'arrêt Sts_Faulted : BOOL; // Résumé des défauts Alm_Overload : BOOL; // Déclenchement surcharge thermique Alm_FailToStart: BOOL; // Échec de la séquence de démarrage Fb_Contactor : BOOL; // Retour physique du contacteur Cfg_StartDelay : DINT; // Préréglage délai démarrage (ms) Cfg_StopDelay : DINT; // Préréglage délai arrêt (ms) Runtime_Seconds: DINT; // Accumulateur de temps de marche END_STRUCT END_TYPE

Que faut-il inclure dans l'UDT moteur, et que faut-il éviter ?

L'UDT doit inclure les données qui appartiennent à l'objet moteur lui-même. Il ne doit pas devenir un tiroir fourre-tout pour une logique de processus non liée.

À inclure

• Commandes opérateur
• État de l'appareil
• Indicateurs d'alarme et de défaut
• Résumés des autorisations
• Configuration au niveau de l'appareil
• Valeurs analogiques au niveau de l'appareil lorsque pertinent

À éviter

• Drapeaux de séquençage au niveau de la ligne non liés
• Logique d'interverrouillage globale qui appartient ailleurs
• Valeurs cosmétiques uniquement pour l'IHM sans signification technique
• Variables en double qui reformulent le même état avec des mots différents

Un UDT surchargé va à l'encontre de l'objectif. La réutilisation dépend de frontières propres.

Vous liez un UDT à une face avant d'IHM en passant la variable structurée racine à la face avant et en résolvant toutes les références internes par rapport à cet objet. La face avant ne doit pas se soucier de savoir si elle regarde `Motor_01` ou `Motor_47` ; elle doit seulement se soucier que l'objet fourni soit conforme à la structure attendue.

Conceptuellement, il s'agit de paramétrage d'objet. Dans le travail de contrôle pratique, c'est ainsi qu'une face avant devient multiple sans devenir fragile.

Le processus de liaison en 3 étapes dans OLLA Lab

OLLA Lab est utile ici en tant qu'environnement de validation borné. Il permet aux ingénieurs de répéter la logique de mappage, d'inspecter les membres des variables et de tester la relation de cause à effet avant de toucher à un déploiement IHM ou SCADA réel.

Créez des variables telles que :

• `Motor_01`
• `Motor_02`
• `Motor_03`

Liez l'instance de la face avant à `Motor_01`. Les éléments internes de la face avant référencent alors :

• `Cmd_Start`
• `Cmd_Stop`
• `Sts_Running`
• `Alm_Overload`

1. Définir l'UDT dans le dictionnaire de variables Créez la structure moteur avec les membres requis pour la commande, l'état, l'alarme et la configuration.
2. Instancier les objets moteur Chaque instance utilise le même UDT moteur comme type de données.
3. Mapper la face avant à la variable racine par rapport à l'objet racine lié, et non comme des variables entièrement codées en dur.

C'est là qu'OLLA Lab devient opérationnellement utile. Le panneau des variables et le dictionnaire de variables rendent la structure visible, ce qui est exactement ce dont vous avez besoin pour vérifier si un bit de commande, un bit d'état ou un membre d'alarme atterrit réellement là où vous le pensez.

Que signifie « liaison dynamique » en termes d'ingénierie pratique ?

La liaison dynamique signifie que la face avant est écrite une fois et fournie avec un objet moteur différent à chaque instanciation. La logique interne et les états visuels restent les mêmes ; seul l'objet racine référencé change.

En termes pratiques, cela vous donne :

• un comportement de bouton de démarrage,
• un comportement de bouton d'arrêt,
• un modèle d'affichage d'alarme,
• une logique de couleur d'état,
• de nombreuses instances de moteur.

C'est la différence entre l'architecture de modèle et le dessin d'écran. L'une passe à l'échelle. L'autre accumule les regrets.

La logique à contacts doit être organisée de manière à ce que l'UDT reflète le comportement réel de l'appareil, et non seulement l'intention de l'IHM. Un bit de commande de démarrage dans la face avant ne doit pas être traité comme une preuve que le moteur a démarré. Le barreau doit toujours évaluer les autorisations, les interverrouillages, les conditions de séquence et les retours.

Un modèle de contrôle moteur compact comprend généralement :

• un chemin de requête de démarrage,
• un chemin d'arrêt,
• des vérifications d'autorisation,
• une condition de maintien ou de marche maintenue,
• une validation de retour physique,
• une détection de défaut,
• un verrouillage d'alarme ou une génération de résumé.

Un exemple minimal est présenté ci-dessous sous forme conceptuelle.

| Permissive_OK Cmd_Start Cmd_Stop_NC Alm_Overload_NC | |----] [------------] [-----------] [------------] [---------( ) Motor_Run_Cmd

| Motor_Run_Cmd Fb_Contactor | |----] [-------------] [------------------------------------( ) Sts_Running

| Motor_Run_Cmd NOT Fb_Contactor Start_Timer_DN | |----] [--------------] [-----------------] [----------------( ) Alm_FailToStart

La distinction importante est la suivante :

• La commande est ce que l'opérateur a demandé.
• L'état est ce que l'équipement a prouvé.
• L'alarme est ce que la logique a conclu lorsque la preuve a échoué.

De nombreuses mauvaises faces avant mélangent ces trois éléments en une icône verte joyeuse. L'usine s'en aperçoit généralement en premier.

Vous validez la logique de la face avant en testant si chaque action IHM produit la réponse correcte dans la logique à contacts et si chaque état de la logique à contacts produit l'indication IHM correcte dans des conditions normales et anormales. La validation n'est pas « le bouton a changé de couleur ». La validation est une relation de cause à effet traçable.

Dans OLLA Lab, cela signifie utiliser :

• l'éditeur de logique à contacts pour inspecter la logique de contrôle,
• le mode simulation pour exécuter et arrêter la logique en toute sécurité,
• le panneau des variables pour observer les membres de commande, d'état et d'alarme en direct,
• le comportement des scénarios pour comparer l'état de la logique à contacts avec la réponse de l'équipement simulé.

C'est le bon endroit pour faire des erreurs, car le simulateur n'alimente pas un contacteur, n'inonde pas un puits humide et ne démarre pas le mauvais convoyeur. Les usines réelles sont notoirement moins indulgentes.

La liste de contrôle de validation minimale

Avant de considérer la logique de la face avant comme prête pour une revue de déploiement, vérifiez au moins les points suivants :

• L'action de démarrage IHM définit le membre de commande correct.
• L'instance de moteur correcte répond.
• Aucune instance de moteur adjacente ne change d'état.

• L'action d'arrêt IHM efface correctement la condition de marche.
• Le comportement d'arrêt correspond à la philosophie de contrôle.

• `Sts_Running` ne change que sur une preuve valide ou une logique définie.
• L'indication de marche n'est pas pilotée directement par le bit de commande, sauf si la conception exige explicitement cette simplification.

• Les conditions de surcharge et d'échec de démarrage s'affichent sur la face avant correcte.
• Le comportement de réinitialisation d'alarme est cohérent avec la logique à contacts et la philosophie de l'usine.

• Le comportement manuel/auto ou local/distant est visible et correctement appliqué.

• Les actions sur la face avant de `Motor_01` n'affectent pas `Motor_02`.
• La logique de modèle partagée ne crée pas d'état d'exécution partagé par accident.

1. Mappage de la commande de démarrage
2. Mappage de la commande d'arrêt
3. Indication d'état
4. Indication d'alarme
5. Gestion des modes
6. Isolation des instances

Cette vérification finale est moins glamour que les graphiques 3D, mais plus utile à 2h00 du matin.

Tester la commande d'arrêt « normalement fermée »

Le chemin d'arrêt doit être testé explicitement car la sémantique d'arrêt est souvent mal comprise dans les simulations IHM uniquement.

Dans de nombreux schémas de contrôle moteur, la condition d'arrêt logique est représentée comme un chemin d'autorisation normalement fermé dans la logique à contacts, ce qui signifie que le chemin de marche reste sain jusqu'à ce qu'une requête d'arrêt, un déclenchement, une rupture de chaîne d'arrêt d'urgence ou un interverrouillage ne l'ouvre. Le bouton d'arrêt IHM ne « met donc pas en marche l'arrêt » de la même manière qu'un bouton de démarrage met en marche le démarrage. Il interrompt généralement la condition de marche maintenue ou fait tomber le chemin de commande.

Lors de la validation de ce comportement :

• confirmez que l'action d'arrêt IHM rompt la condition de barreau correcte,
• confirmez que l'état du moteur tombe conformément au retour et à la temporisation de séquence,
• confirmez qu'un arrêt d'urgence physique ou une chaîne de sécurité câblée n'est pas simulé comme un simple bit IHM si l'intention de conception est différente.

Cette distinction est importante. Un arrêt IHM est une commande opérateur. Une chaîne d'arrêt d'urgence est une fonction de sécurité. Ils ne sont pas interchangeables parce que l'écran semble propre.

La bonne preuve est un dossier technique compact, pas une galerie de captures d'écran.

Si vous voulez démontrer votre compétence dans la conception de faces avant réutilisables, documentez le travail selon cette structure :

Exemple : « Trois moteurs de convoyeur utilisant un UDT moteur standard et une face avant IHM réutilisable. »

Exemple : « Chaque face avant doit commander uniquement son instance de moteur liée, afficher un retour de marche réel et afficher les alarmes de surcharge et d'échec de démarrage sans contamination entre les instances. »

Exemple : liez `Motor_02.Sts_Running` à la face avant de `Motor_01` et montrez le décalage résultant.

Exemple : réparez la liaison de l'objet racine et retestez tous les membres de la face avant.

Exemple : « Les membres d'état doivent être dérivés de la preuve de l'appareil, et non reflétés à partir des bits de commande. »

C'est à cela que ressemble une preuve « Simulation-Ready » en pratique : non seulement que vous avez écrit la logique, mais que vous l'avez testée contre un comportement attendu et anormal, trouvé un défaut et l'avez corrigé avec un raisonnement traçable.

1. Description du système Définissez l'objet moteur, le rôle dans le processus et le nombre d'instances.
2. Définition opérationnelle de « correct » Énoncez les critères d'acceptation observables.
3. Logique à contacts et état de l'équipement simulé Montrez la logique de barreau pertinente et le comportement du moteur simulé correspondant. Incluez les bits de commande, les bits de retour, les autorisations et les conditions d'alarme.
4. Le cas de défaut injecté Introduisez délibérément un défaut de mappage ou de séquence.
5. La révision effectuée Documentez la correction exacte.
6. Leçons apprises Énoncez ce qui a échoué, pourquoi cela a échoué et quelle règle de conception empêche désormais la récurrence.

OLLA Lab soutient ce flux de travail en offrant aux ingénieurs un environnement basé sur le Web pour construire la logique à contacts, inspecter les variables structurées, simuler le comportement des E/S et comparer la logique de contrôle avec l'état de l'équipement virtuel avant le déploiement. Cela compte car les erreurs d'intégration UDT-face avant sont généralement bon marché en simulation et coûteuses lors de la mise en service.

Dans le rôle borné du produit, les capacités utiles sont spécifiques :

• l'éditeur de logique à contacts prend en charge la construction de la logique moteur elle-même,
• le dictionnaire de variables prend en charge la création et la revue des données moteur structurées,
• le panneau des variables expose la visibilité au niveau des membres pour les commandes, les états, les valeurs analogiques et les alarmes,
• le mode simulation permet une validation sûre de la relation de cause à effet,
• les flux de travail basés sur des scénarios prennent en charge des tests réalistes plutôt qu'un basculement de bits abstrait.

Cela ne doit pas être surestimé. OLLA Lab est un environnement de répétition et de validation pour les tâches d'automatisation à haut risque. Ce n'est pas un substitut à la FAT, à la SAT, à la revue de sécurité fonctionnelle ou à la compétence de mise en service sur site spécifique à l'usine. Mais c'est exactement le bon endroit pour pratiquer la discipline de mappage que les systèmes réels punissent.

Les erreurs les plus courantes sont architecturales, pas graphiques.

Modes de défaillance courants

Cela détruit la réutilisation et multiplie les modifications manuelles.

• Liaison à des variables individuelles au lieu d'un objet racine

Le moteur n'a pas démarré parce que le bouton a été pressé. L'équipement est agaçant car il se base sur des preuves.

• Utilisation de bits de commande comme indicateurs d'état

Cela rend l'objet difficile à réutiliser dans différents contextes.

• Mélange de logique au niveau de l'appareil et au niveau de la ligne dans un seul UDT

Les hypothèses de la face avant se brisent lorsque le modèle de données dérive.

• Nommage incohérent des membres entre les instances

Une face avant qui ne fonctionne que dans le chemin heureux n'est pas validée.

• Ignorer les tests d'état anormal

Ce sont des fonctions différentes avec des implications de risque différentes.

• Traiter l'arrêt IHM et l'arrêt de sécurité comme la même chose

La correction pratique

La correction est une modélisation d'objet disciplinée :

• définissez un standard moteur,
• liez une face avant à ce standard,
• validez une instance minutieusement,
• puis répliquez par instanciation, pas par édition manuelle.

C'est ainsi que la mise à l'échelle devrait fonctionner en ingénierie de contrôle : un modèle vérifié, de nombreuses répétitions sûres.

Les faces avant de moteur réutilisables dépendent de données structurées, pas de meilleures habitudes de copier-coller. Le mouvement de conception central consiste à lier un objet IHM à une instance d'UDT moteur afin que les commandes, les états, les alarmes et les valeurs de configuration voyagent comme un objet cohérent.

Cette approche est soutenue par les principes de modélisation de données de la norme IEC 61131-3 et par l'accent mis par la norme ISA-101 sur le comportement cohérent des objets IHM. Elle correspond également à la réalité du terrain : la plupart des défaillances de face avant ne sont pas des défaillances de dessin, mais des défaillances de mappage, de preuve et de discipline d'état.

Utilisé correctement, OLLA Lab fournit un endroit borné pour pratiquer cette discipline. Les ingénieurs peuvent définir des UDT, instancier des objets moteur, lier des faces avant, exécuter des simulations, injecter des défauts et vérifier que le bon moteur virtuel répond avant qu'un processus réel ne soit impliqué. C'est le but de la simulation dans la formation à l'automatisation : non pas la répétition de la syntaxe, mais l'exposition contrôlée à des erreurs qui seraient coûteuses ailleurs.

Lien VERS LE HAUT : Maîtrisez l'architecture plus large dans notre Hub de maîtrise de la logique à contacts. Lien À TRAVERS : Voir « Maintien » vs « Verrouillage » : Pourquoi les ingénieurs professionnels choisissent soigneusement le comportement du barreau derrière les commandes moteur maintenues. Lien À TRAVERS : Lisez Les règles non écrites de la documentation des automates : Conventions de nommage qui sauvent des vies pour une discipline de nommage qui soutient la mise à l'échelle des UDT. Lien VERS LE BAS : Prêt à tester cette architecture ? Ouvrez le préréglage de la machine à états du mélangeur automatisé dans OLLA Lab et entraînez-vous à lier des variables structurées au comportement de l'équipement simulé.

- Vers le haut (Hub Pilier) : Explorer les conseils du pilier - À travers : Article connexe 1 - À travers : Article connexe 2 - Vers le bas (Commercial/CTA) : Construisez votre prochain projet dans OLLA Lab

- ANSI/ISA-101.01-2015 Conception d'IHM pour l'automatisation des processus - Aperçu de la sécurité fonctionnelle IEC 61508 - Rapport de l'atelier NIST sur les jumeaux numériques (NIST AMS 100-49) - Perspectives de l'industrie manufacturière 2024 de Deloitte