Gestion des extensions propriétaires d'automates : UDT vs USER_DEFINED dans la norme IEC 61131-3

La norme IEC 61131-3 normalise les langages de programmation des automates, mais pas le comportement complet des runtimes selon les fournisseurs. Les structures de données complexes telles que les UDT, les DUT et les types définis par l'utilisateur spécifiques aux fournisseurs restent dépendantes de l'implémentation, notamment en ce qui concerne la disposition en mémoire et l'accès aux blocs. OLLA Lab fournit un environnement de simulation délimité pour s'exercer au mappage de données, à la structuration des tags et à la validation logique avant tout déploiement spécifique à un fournisseur.

La conformité à la norme IEC 61131-3 n'est pas synonyme de portabilité du code. La norme définit des familles de langages et des sémantiques fondamentales, mais elle laisse des détails importants concernant le runtime et la mémoire à la discrétion de l'implémentation, ce qui est précisément là où les migrations multiplateformes tendent à échouer.

Une correction pratique s'impose ici : la plupart des migrations échouées ne sont pas causées par le barreau (rung) qui démarre un moteur. Elles sont causées par la structure qui l'entoure. Dans une étude comparative interne chez Ampergon Vallis, 68 % des échecs de migration multiplateforme simulés étaient associés à des incompatibilités de structures de données imbriquées définies par l'utilisateur, à des conflits de remplissage (padding) ou à des hypothèses sur le modèle d'adressage, plutôt qu'à des erreurs de syntaxe Ladder de base [Méthodologie : n=512 tâches de migration simulées impliquant des structures multi-tags et un remappage d'E/S, comparateur de référence = acceptation du Ladder par syntaxe uniquement, fenêtre temporelle = janv. 2025 à fév. 2026]. Cela soutient une affirmation précise : la modélisation des données est un point de défaillance majeur lors des répétitions de migration. Cela ne prouve pas un taux industriel universel.

Cette distinction est importante car la syntaxe est facile à admirer mais difficile à déployer. La disposition mémoire est un problème plus discret, et c'est généralement celui qui attend lors de la mise en service.

La norme IEC 61131-3 normalise les langages de programmation, et non un comportement identique des fournisseurs. Elle définit des langages tels que le Ladder Diagram (LD), le Function Block Diagram (FBD), le Structured Text (ST), le Sequential Function Chart (SFC) et les concepts de types associés, mais elle autorise des comportements dépendants de l'implémentation dans des domaines qui affectent l'exécution, le stockage et l'interopérabilité.

En pratique, « dépendant de l'implémentation » n'est pas une note de bas de page. C'est le domaine où les fournisseurs prennent des décisions divergentes concernant :

• l'alignement et le remplissage (padding) des données,
• l'ordre des octets et les conventions de stockage,
• l'accès mémoire optimisé par rapport à l'accès absolu,
• le traitement des structures et des types imbriqués par le compilateur,
• le comportement des variables rémanentes,
• les implémentations de blocs fonctionnels spécifiques aux bibliothèques.

C'est pourquoi deux contrôleurs peuvent être décrits comme conformes à la norme IEC 61131-3 tout en étant en désaccord sur la manière dont une structure complexe est stockée ou adressée.

Une définition technique utile en découle : une logique portable n'est pas une logique qui compile à deux endroits ; c'est une logique dont les hypothèses sur les données, l'exécution et les interfaces survivent aux deux compilateurs. C'est une exigence plus élevée que ce que suggère la plupart des discours marketing.

Que laisse réellement la norme à la discrétion des fournisseurs ?

La norme laisse une marge de manœuvre pour l'implémentation spécifique aux fournisseurs dans plusieurs domaines pertinents pour les structures de données et l'interopérabilité. Selon l'édition et la documentation du fournisseur, cela inclut généralement :

• la représentation interne des types de données,
• le compactage et l'alignement des structures,
• les méthodes d'accès aux variables et aux blocs,
• les détails du comportement des tâches et du cycle de balayage (scan),
• les extensions de bibliothèques et de runtime.

Le résultat est simple. Une déclaration de type peut sembler standard alors que le comportement mémoire sous-jacent ne l'est pas.

Pourquoi est-ce important sur un système en service ?

C'est important car les interfaces externes ne négocient pas avec vos hypothèses. Une table de registres Modbus, un client OPC UA, une face avant IHM ou un échange entre automates attendent une interprétation stable des données. Si un côté ajoute du remplissage à un champ `BOOL` ou réorganise une structure pour un accès optimisé, la logique peut toujours compiler alors que les données de processus se décalent en arrière-plan.

C'est le genre d'erreur qui survient après la revue de code et apparaît lors du démarrage.

La différence clé ne réside pas seulement dans la dénomination. Elle réside dans la manière dont chaque fournisseur lie les types personnalisés à la mémoire, aux règles d'accès et au comportement des outils.

Différents écosystèmes utilisent des termes différents pour des idées globalement similaires :

Répartition de la terminologie par fournisseur

- Rockwell Automation (Studio 5000) :

• Utilise des User-Defined Data Types (UDT).
• Les UDT sont au cœur de la modélisation des tags Logix.
• Le comportement mémoire et l'alignement des membres suivent les règles de compilation spécifiques au fournisseur.
• Les intégrateurs rencontrent souvent des hypothèses d'alignement lors de l'échange de données compactées avec des systèmes non-Rockwell.

- Siemens (TIA Portal) :

• Utilise des types de données PLC et des UDT dans le langage d'ingénierie courant.
• L'« accès optimisé aux blocs » peut modifier la manière dont les données sont organisées en interne.
• Cela améliore l'efficacité au sein de l'environnement Siemens, mais peut perturber les flux de travail qui dépendent d'offsets absolus fixes.
• Si un système externe attend des adresses fixes de type ancien, l'accès optimisé n'est pas utile.

- Plateformes basées sur Codesys, y compris Beckhoff et WAGO dans de nombreuses implémentations :

• Utilisent couramment des DUT (Data Unit Types) déclarés avec `TYPE ... END_TYPE`.
• La syntaxe est normalisée dans le style, mais le compactage au runtime et le comportement de la cible dépendent toujours de la plateforme et du compilateur.
• La portabilité entre cibles reste conditionnelle, et non automatique.

- Autres environnements de fournisseurs :

• Peuvent utiliser des termes tels que `STRUCT`, `USER_DEFINED`, des types d'enregistrement personnalisés ou des modèles d'objets spécifiques à la plateforme.
• La différence de nommage est moins importante que le comportement de stockage et d'accès qui en résulte.

Quelle est la distinction opérationnelle dont les ingénieurs doivent se soucier ?

La distinction opérationnelle est la suivante : un type défini par l'utilisateur n'est pas seulement une commodité de nommage ; c'est un contrat sur la forme des données, l'ordre des membres et les attentes en matière d'accès. Si deux systèmes sont en désaccord sur ce contrat, la logique entourant les données devient peu fiable, même lorsque le Ladder lui-même est parfaitement ordinaire.

C'est là que les ingénieurs confondent souvent la compatibilité linguistique avec la déployabilité. La première est textuelle. La seconde est physique.

Le remplissage mémoire casse la logique normalisée en décalant l'emplacement attendu des champs à l'intérieur d'une structure. La logique peut rester syntaxiquement valide, mais toute interface qui suppose une disposition différente des octets ou des mots peut lire la mauvaise valeur.

Considérez cette déclaration simplifiée :

TYPE Motor_Control_DUT : STRUCT Start_Cmd : BOOL; ( peut être complété par du padding selon le fournisseur ) Speed_Ref : REAL; ( 32 bits ) Fault_Code : INT; ( 16 bits ) END_STRUCT END_TYPE

Cette déclaration semble simple. Elle ne l'est pas universellement en mémoire.

Un compilateur peut placer `Start_Cmd` dans un emplacement binaire compacté et placer `Speed_Ref` immédiatement après la frontière valide suivante. Un autre peut aligner le `REAL` sur une frontière de 32 bits et insérer du remplissage après le `BOOL`. Un troisième peut optimiser la structure à l'intérieur d'un bloc d'une manière qui rend les offsets absolus dangereux pour les consommateurs externes.

Un mode de défaillance concret

Un mode de défaillance courant apparaît dans les communications basées sur des registres.

• Un contrôleur émetteur expose une structure à une table Modbus TCP.
• L'ingénieur suppose que `Start_Cmd`, `Speed_Ref` et `Fault_Code` occupent des offsets consécutifs attendus.
• Le contrôleur récepteur importe ou reconstruit la même structure conceptuelle en utilisant ses propres règles de compilation.
• Le `REAL` atterrit à un offset différent car la première plateforme a ajouté du remplissage au champ `BOOL`.
• Le côté récepteur lit désormais des données de référence de vitesse corrompues ou interprète une partie de la valeur à virgule flottante comme un code de défaut.

Le Ladder peut être « correct » et la machine peut toujours se comporter de manière incorrecte. C'est la conséquence pratique du désalignement des données.

Pourquoi les types imbriqués aggravent-ils la situation ?

Les structures imbriquées multiplient le risque car chaque structure enfant peut introduire son propre comportement d'alignement. Un objet moteur simple peut être gérable. Un objet de skid de processus contenant des commandes, des autorisations, des alarmes, des valeurs analogiques, des paramètres PID et des mots d'état devient beaucoup plus fragile.

Le schéma de défaillance est prévisible :

• une hypothèse incorrecte au niveau de la structure parente,
• une règle d'alignement cachée dans une structure enfant,
• un mappage externe construit sur des offsets absolus,
• une longue journée de mise en service.

Les différences pratiques apparaissent dans la manière dont les ingénieurs définissent, accèdent et échangent des données structurées.

Rockwell Automation

Les UDT Rockwell sont largement utilisés pour les modèles d'équipement réutilisables, les faceplates et l'organisation des tags adjacents aux AOI. En pratique, les ingénieurs conçoivent souvent autour de structures de tags Logix qui sont propres au sein de l'écosystème Rockwell, mais qui nécessitent un remappage délibéré lorsqu'elles sont exposées à des systèmes tiers.

Les implications pratiques incluent :

• une forte cohérence interne pour les projets Logix,
• une utilisation fréquente dans les modèles d'objets de moteurs, vannes et dispositifs,
• une attention requise lors du mappage vers des protocoles externes ou des consommateurs non-Rockwell,
• des hypothèses d'alignement et de compactage qui doivent être vérifiées, et non devinées.

Siemens

Siemens introduit une distinction importante entre l'accès de style standard et l'accès optimisé aux blocs. L'accès optimisé peut améliorer l'utilisation de la mémoire et les performances internes, mais il réduit la transparence des adresses pour les systèmes externes qui attendent des offsets fixes.

Les implications pratiques incluent :

• une gestion interne efficace des données structurées,
• une fiabilité réduite des anciennes hypothèses d'adresses absolues,
• la nécessité de décider explicitement si l'interopérabilité externe ou l'optimisation interne est prioritaire,
• une prudence accrue lors de l'intégration d'IHM, d'historiques ou d'automates pairs attendant des adresses stables.

Codesys et plateformes associées

Les DUT de style Codesys offrent un modèle de déclaration de type familier et flexible. Ils sont puissants pour l'ingénierie structurée, les bibliothèques réutilisables et l'abstraction des machines. Ils ne garantissent cependant pas qu'une autre cible stockera la même structure de manière identique.

Les implications pratiques incluent :

• une syntaxe de déclaration de type claire,
• une portabilité sous réserve d'hypothèses de plateforme délimitées,
• des différences de runtime spécifiques à la cible toujours pertinentes,
• la nécessité d'une vérification explicite lors du franchissement des frontières entre fournisseurs.

La migration d'automates par « copier-coller » échoue généralement parce que le logiciel de contrôle industriel est couplé au comportement du matériel, aux modèles de mémoire, aux conventions d'E/S, aux hypothèses de balayage et aux outils des fournisseurs. La logique n'est qu'une couche du système.

Une migration nécessite normalement que les ingénieurs réconcilient au moins cinq éléments :

- Systèmes de types : les conventions UDT, DUT, struct et bloc diffèrent. - Modèles d'adressage : les dispositions absolues, symboliques, optimisées et exposées par protocole diffèrent. - Comportement des instructions : les temporisateurs, compteurs, blocs PID et fonctions de bibliothèque ne sont pas toujours sémantiquement identiques. - Liaison des E/S : les dispositifs de terrain, la mise à l'échelle et les bits de diagnostic sont spécifiques à la plateforme. - Hypothèses de mise en service : le séquencement du démarrage, le comportement de réinitialisation des défauts et la gestion des autorisations sont souvent encodés dans des modèles natifs du fournisseur.

La version honnête est donc la suivante : il n'existe pas de « migration par copier-coller » industrielle digne de confiance sur un processus en direct. Il n'y a que la traduction, la vérification et la réduction des risques.

Simulation-Ready doit être défini de manière opérationnelle, et non aspirationnelle. Un ingénieur « Simulation-Ready » peut prouver, observer, diagnostiquer et renforcer la logique de contrôle contre un comportement de processus réaliste avant que cette logique n'atteigne un processus en direct.

Pour le travail sur les structures de données multiplateformes, cela signifie que l'ingénieur peut :

• définir clairement les tags structurés et les membres imbriqués,
• tracer la relation de cause à effet entre l'état du Ladder et l'état de l'équipement,
• vérifier le comportement attendu dans des conditions normales et anormales,
• identifier où les hypothèses sur les données dépendent de règles de compactage ou d'accès spécifiques au fournisseur,
• réviser la logique ou le mappage après l'injection d'un défaut,
• documenter ce que signifie « correct » avant le déploiement.

C'est différent du simple fait de savoir écrire un barreau. La syntaxe est nécessaire. Ce n'est pas la ligne d'arrivée.

Ce cadre s'aligne sur la littérature d'ingénierie plus large sur la validation basée sur la simulation, l'utilisation du jumeau numérique dans les systèmes industriels et la vérification pré-déploiement comme mesure de réduction des risques dans les environnements d'automatisation complexes (par exemple, Fuller et al., 2020 ; Jones et al., 2020 ; et les principes de la norme IEC 61508 sur la réduction systématique des risques).

OLLA Lab aide en offrant aux ingénieurs un environnement délimité pour répéter la conception de tags structurés, la simulation et la validation sensible aux défauts avant de passer aux contraintes IDE spécifiques aux fournisseurs. Ce n'est pas un traducteur de code universel, et il ne doit pas être traité comme tel.

Sa valeur ici est plus étroite et plus crédible : il permet aux ingénieurs de pratiquer l'habitude d'ingénierie que le travail de migration exige réellement.

Ce que fait OLLA Lab dans ce flux de travail

Dans le cadre documenté du produit, OLLA Lab fournit :

• un éditeur de logique Ladder basé sur le web,
• un mode de simulation pour exécuter et arrêter la logique,
• un panneau de variables pour surveiller et ajuster les tags, les E/S, les valeurs analogiques et les états associés,
• des exercices industriels basés sur des scénarios,
• des contextes de simulation de type jumeau numérique pour valider le comportement par rapport à l'équipement modélisé.

Pour le cas d'utilisation de cet article, le panneau de variables est le plus important car il permet aux ingénieurs de définir et d'inspecter des variables structurées dans un environnement agnostique au matériel avant de se confronter aux règles de compilation et de mappage spécifiques aux fournisseurs.

Ce que signifie « agnostique vis-à-vis des fournisseurs » ici

Agnostique vis-à-vis des fournisseurs ne signifie pas un déploiement sans fournisseur. Cela signifie que l'environnement de pratique ne force pas l'étudiant à apprendre les règles de mémoire de Rockwell, Siemens et Codesys en même temps qu'il apprend la causalité, le séquencement et l'architecture des tags.

Cette séparation est utile car les débutants et les ingénieurs juniors échouent souvent pour deux raisons à la fois :

• ils ne comprennent pas encore le comportement de contrôle,
• et ils sont déjà ensevelis sous des détails spécifiques à la plateforme.

Le flux de travail consiste à modéliser d'abord le comportement de contrôle, puis à modéliser la forme des données, et enfin à valider la causalité sous simulation.

### Étape 1 : Définir la logique de contrôle brute

Construisez la logique Ladder dans l'éditeur en utilisant le jeu d'instructions requis pour le scénario :

• contacts et bobines,
• temporisateurs et compteurs,
• comparateurs et blocs mathématiques,
• éléments analogiques et PID le cas échéant.

À ce stade, concentrez-vous sur la séquence et la causalité. Une chaîne d'autorisation de démarrage moteur doit se comporter correctement avant de vous soucier de la manière dont un fournisseur spécifique complétera une structure enfant.

### Étape 2 : Construire les tags structurés dans le panneau de variables

Utilisez le panneau de variables pour créer un modèle de tag imbriqué qui reflète l'objet d'équipement ou de processus. Par exemple :

• `Motor_Status.Running`
• `Motor_Status.Faulted`
• `Motor_Command.Start`
• `Motor_Command.Stop`
• `Motor_Analog.Speed_Ref`
• `Motor_Alarm.Overload`

C'est là qu'OLLA Lab devient opérationnellement utile. L'ingénieur peut pratiquer la discipline de nommage, le regroupement des membres liés à la logique et l'observation de la manière dont l'état du barreau se mappe à l'état de l'équipement.

### Étape 3 : Simuler et observer les changements d'état

Exécutez la simulation et basculez les entrées tout en surveillant les sorties et les variables.

Vérifiez :

• les transitions attendues,
• les autorisations échouées,
• le comportement des alarmes,
• la réponse analogique,
• le timing de la séquence,
• la discordance entre l'état prévu et le comportement réel du tag.

Une bonne session de simulation répond à une question simple : lorsque le processus change, la logique change-t-elle pour la bonne raison ?

### Étape 4 : Injecter une condition anormale

Introduisez un cas de défaut tel que :

• échec du retour de preuve,
• déclenchement analogique haut-haut,
• perte d'autorisation pendant la marche,
• confirmation de démarrage retardée,
• état de commande obsolète.

Le but est de vérifier que la structure et la logique ont toujours du sens lorsque le processus cesse de coopérer.

### Étape 5 : Réviser la logique et documenter les hypothèses de mappage

Ajustez le Ladder, le regroupement des tags ou la gestion des états après l'apparition du défaut. Enregistrez ensuite quelles hypothèses sont portables et lesquelles nécessiteront un traitement spécifique au fournisseur plus tard.

Cette dernière étape est la différence entre la pratique et la preuve.

Un ingénieur junior doit construire un corpus compact de preuves d'ingénierie qui démontre le raisonnement, la validation et la révision. Les captures d'écran sont des artefacts de soutien. Elles ne constituent pas l'argument.

Utilisez cette structure :

Énoncez ce que signifie un comportement correct en termes observables. Exemple : « La pompe démarre uniquement lorsque l'autorisation principale, le déclenchement de basse aspiration et la commande de démarrage à distance sont vrais ; les défauts sont mémorisés jusqu'à la réinitialisation. »

1. Description du système Définissez la machine ou l'objet de processus, son but, ses états principaux et ses E/S clés.
2. Définition opérationnelle de « correct »
3. Logique Ladder et état de l'équipement simulé Montrez les barreaux pertinents et les changements d'état simulés correspondants dans les tags, les sorties ou l'équipement modélisé.
4. Le cas de défaut injecté Décrivez la condition anormale introduite et pourquoi elle est importante sur le plan opérationnel.
5. La révision effectuée Expliquez ce qui a changé dans la logique, la structure des tags ou la gestion des séquences après l'observation du défaut.
6. Leçons apprises Enregistrez la conclusion d'ingénierie, en particulier là où la modélisation des données, le séquençage ou les hypothèses d'interface ont créé un risque.

Ce format est utile dans la formation car il démontre le jugement de mise en service, et non seulement la littératie des diagrammes. Les employeurs n'ont pas besoin de plus de captures d'écran de bits verts. Ils ont besoin de preuves que l'ingénieur peut réfléchir lorsque le processus est en désaccord.

La validation par jumeau numérique est utile lorsqu'elle est définie comme une vérification du comportement par rapport à un modèle de machine ou de processus réaliste avant le déploiement. Elle n'est pas utile lorsqu'elle est traitée comme un décor 3D attaché à une logique non testée.

Dans un environnement de formation délimité tel qu'OLLA Lab, la simulation de type jumeau numérique aide les ingénieurs à comparer :

• l'état du Ladder,
• l'état des E/S,
• le comportement analogique,
• la progression de la séquence,
• et la réponse de l'équipement modélisé.

Cette comparaison est importante car les échecs de mise en service sont souvent relationnels. Le barreau semble correct isolément. La séquence de processus ne l'est pas.

La recherche sur les jumeaux numériques industriels et l'ingénierie basée sur la simulation a constamment soutenu la valeur de la validation virtuelle pour réduire le risque d'intégration en fin de projet, améliorer la compréhension du système et soutenir la formation des opérateurs ou des ingénieurs lorsqu'elle est correctement cadrée (Fuller et al., 2020 ; Tao et al., 2019). Les conseils sur la sécurité fonctionnelle renforcent également le principe plus large selon lequel les défauts systématiques doivent être trouvés le plus tôt possible grâce à une conception et une vérification disciplinées plutôt que découverts sur le site de production (IEC 61508 ; exida, 2024).

La traduction sur le terrain est simple : si un défaut peut être trouvé avant le démarrage, c'est le moment correct pour le trouver.

Les ingénieurs doivent traiter OLLA Lab comme un environnement de répétition, puis effectuer une traduction et une vérification explicites spécifiques au fournisseur avant le déploiement.

Utilisez cette liste de contrôle de transfert :

• confirmez le système de types et les conventions de nommage de la plateforme cible,
• vérifiez le comportement de compactage et d'alignement de la structure,
• décidez si les systèmes externes nécessitent un adressage fixe,
• examinez les paramètres d'accès aux blocs optimisés par rapport aux paramètres standard,
• mappez explicitement les données exposées par protocole,
• validez la mise à l'échelle analogique et les unités d'ingénierie,
• comparez le comportement des temporisateurs, compteurs et PID par rapport à la sémantique de la cible,
• exécutez à nouveau les cas de défaut dans l'environnement du fournisseur,
• documentez toutes les hypothèses qui ont changé pendant la traduction.

C'est le chemin discipliné de la simulation au déploiement. C'est plus lent que les vœux pieux et plus rapide qu'un mauvais démarrage.

- UP : Explorez le hub complet de maîtrise de la logique Ladder. - ACROSS : Article connexe 1. - ACROSS : Article connexe 2. - ACROSS : Article connexe 3. - DOWN : Pratiquez ce flux de travail dans OLLA Lab.

- IEC 61131-3: Automates programmables — Partie 3 - Famille de normes de sécurité fonctionnelle IEC 61508 - Ressources de sécurité fonctionnelle et de validation exida - Recommandation NAMUR NE 107 sur la signalisation d'état - Jumeau numérique dans l'industrie : état de l'art (DOI)