Structurer une liste d'entrées-sorties et une base de tags, du P&ID au SCADA

Pourquoi une seule liste

La liste d'entrées-sorties est le document que tout le monde recopie. L'automaticien la ressaisit dans TIA Portal ou CODESYS, l'intégrateur SCADA dans sa base de tags, le bureau d'études dans le dossier de câblage. Chaque recopie est une occasion d'erreur, et chaque révision doit être reportée à la main dans trois ou quatre outils.

La règle est donc simple : une liste, des exports. La liste fait foi ; la table de variables de l'automate, les tags de la supervision et les fichiers du serveur OPC en sont dérivés. Si un outil a besoin d'une information qui n'est pas dans la liste, c'est une colonne qui manque.

Les colonnes à prévoir

Une ligne correspond à un signal. Les colonnes ci-dessous couvrent ce dont l'automate, l'IHM et la supervision ont besoin.

Deux colonnes sont souvent oubliées : l'unité, qui manque ensuite sur tous les écrans, et la priorité d'alarme, qu'on finit par régler une par une dans la supervision. Pour mesurer ensuite la santé de votre système d'alarmes, voir aussi les indicateurs d'alarmes ISA-18.2.

Du P&ID au repère automate

Le repère vient du P&ID. Un transmetteur de niveau de la boucle 101 y porte l'étiquette LT-101, selon les lettres d'identification de l'ISA-5.1 : L pour le niveau, T pour le transmetteur, 101 pour la boucle. Si ces lettres vous sont moins familières, le guide de lecture des symboles ISA-5.1 les détaille.

Ce repère ne peut pas toujours être repris tel quel dans l'automate. Les identificateurs de l'IEC 61131-3 n'admettent que des lettres, des chiffres et le trait de soulignement, et ne doivent pas être des mots réservés du langage. LT-101 devient donc LT_101 ou LT101 : choisissez une règle de conversion une fois pour toutes et écrivez-la dans l'en-tête de la liste.

Quelques conventions qui épargnent des heures :

• Un repère, un signal. Une même boucle peut donner plusieurs signaux (la mesure, un défaut, une commande) : distinguez-les par un suffixe constant, par exemple _DEF pour le défaut.
• Une zone par équipement ou par fonction. Elle sert de dossier dans la base de tags et de filtre dans la liste. Pour le repérage des équipements eux-mêmes, l'IEC 81346 fournit une méthode de structuration si votre client l'impose.
• Le libellé est écrit pour l'opérateur. « Niveau cuve de reprise » se lit sur un écran et dans une alarme ; « LT101 AI » ne dit rien à l'exploitant.

Adresses : à l'octet ou à l'élément

La syntaxe d'adresse dépend de l'automate, et c'est la première source de chevauchements.

Contrôlez donc l'emprise réelle de chaque adresse, pas seulement l'égalité des chaînes : %IW0 et %IX0.3 ne sont pas la même adresse, mais elles se recouvrent. C'est parfois voulu (lire un mot d'état bit à bit), plus souvent une erreur de recopie.

Vérifiez aussi la zone : une entrée doit être en %I, une sortie en %Q. Et chez Siemens, une adresse absolue dans un bloc de données (%DB10.DBD0) suppose un bloc non optimisé ; WinCC Unified l'exige alors pour y accéder.

Mise à l'échelle et seuils

Saisissez l'échelle et les seuils en unités physiques (0 à 5 m, 0 à 10 bar). La conversion vers les valeurs brutes de la carte se fait ensuite pour chaque outil. Les plages brutes varient : 0 à 27 648 sur les cartes analogiques Siemens, 0 à 32 767 sur beaucoup d'autres. Garder la valeur physique dans la liste évite de refaire ce calcul à la main dans chaque logiciel.

Deux pièges reviennent souvent :

1. La troncature. Si la supervision met la valeur à l'échelle, la variable de supervision doit être déclarée en flottant (Real dans WinCC, Float4 dans Ignition). Une variable restée en entier affichera 2 m au lieu de 2,37 m.
2. Le battement d'alarme. Une alarme haute sans hystérésis apparaît et disparaît à chaque oscillation d'une mesure bruitée. Prévoyez une hystérésis, par exemple 1 % de l'échelle : l'alarme apparaît au seuil et ne disparaît que lorsque la mesure redescend sous le seuil moins l'hystérésis.

Les seuils doivent être dans l'ordre (LL inférieur à L, inférieur à H, inférieur à HH) et à l'intérieur de l'échelle. Un seuil sur un signal TOR, ou une alarme d'état sur un signal qui n'est pas booléen, signale presque toujours une erreur de nature.

Les contrôles à faire avant chaque diffusion

Avant d'envoyer la liste ou d'en tirer un import, passez-la au crible :

• repères manquants, en double ou non conformes à l'IEC 61131-3 ;
• adresses manquantes, en double, dans la mauvaise zone, de taille incompatible avec le type, ou qui se chevauchent ;
• voie de carte câblée deux fois ;
• type incompatible avec la nature (une entrée TOR doit être BOOL) ;
• échelle absente ou invalide (minimum supérieur ou égal au maximum), unité manquante ;
• seuils dans le désordre ou hors échelle ;
• entrée physique ouverte en écriture depuis la supervision ;
• variable interne placée dans la zone des entrées-sorties.

Un repère en double, une adresse dans la mauvaise zone, une voie câblée deux fois ou des seuils dans le désordre doivent bloquer l'export : un fichier faux importé dans un projet coûte plus cher qu'un export retardé. Un chevauchement d'adresses, une unité manquante, un seuil hors échelle, une entrée ouverte en écriture ou une variable interne dans la zone des E/S sont plutôt des points à vérifier, parfois voulus.

Réviser la liste

Une liste d'E/S évolue jusqu'à la mise en service, et au-delà. À chaque diffusion (revue client, mise en service, recette), figez une révision : un code (A, B, ou V1, V2), un auteur, un commentaire et une copie complète de la liste à cette date.

Joignez à la diffusion un rapport d'écarts avec la révision précédente : signaux ajoutés, supprimés, et pour chaque signal modifié, le champ qui a changé et ses deux valeurs. C'est ce document que le client relit, pas la liste entière.

Si la liste est un fichier texte rangé ligne par ligne, elle se suit aussi dans Git, avec des différences lisibles.

Les imports côté automate et supervision

Chaque outil a son format d'import : classeurs Excel pour les variables API, les variables IHM et les alarmes de TIA Portal, fichier JSON de tags pour Ignition, PLCopenXML pour CODESYS, CSV par appareil pour Kepware. Les colonnes attendues changent parfois d'une version d'outil à l'autre, et selon la langue du projet. La méthode la plus sûre : exporter une fois les variables de votre propre projet, et produire l'import avec exactement le même en-tête.

Dans tous les cas, faites le premier import dans une copie du projet et ouvrez quelques variables et alarmes avant la mise en service.

Tenir la liste avec Bornier

Bornier est une application de bureau, Windows et Linux, hors ligne, qui tient la liste d'E/S dans une grille qui se manie comme Excel, importe vos listes Excel ou CSV existantes, applique 25 contrôles (dont les erreurs bloquent l'export), fige les révisions avec leur rapport d'écarts, et écrit les fichiers d'import de WinCC Unified, Ignition 8.1 et 8.3, CODESYS V3 et Kepware, ainsi qu'une liste Excel pour le client. Il gère les automates Siemens S7-1200 / S7-1500 et CODESYS V3. Ses formats ont été écrits d'après la documentation des éditeurs et des exports réels, mais l'éditeur n'a pas encore fait d'import réel dans TIA Portal, une passerelle Ignition ou KEPServerEX : relisez toujours le résultat dans l'outil cible. Un essai complet de 30 jours est proposé.

Sources

• IEC 61131-3, Automates programmables, partie 3 : langages de programmation (règles des identificateurs, non reproduite)
• ANSI/ISA-5.1, Instrumentation Symbols and Identification (non reproduite)
• IEC 81346, Principes de structuration et désignations de référence (non reproduite)
• Bornier, guide utilisateur et description des formats d'export (FORMATS.md), version 1.0