Un package arrive avec son automate, sa logique et sa propre idée de ce que le DCS doit voir. La liaison est souvent en Modbus — RTU sur liaison série ou TCP sur Ethernet — et sur le papier, tout paraît simple : une liste de registres à lire et à écrire.
En pratique, la plupart des soucis de démarrage avec les packages sont des soucis d'interface : une valeur plausible mais fausse, un ordre envoyé mais jamais exécuté, un défaut que l'opérateur ne sait pas interpréter. Voici la checklist que nous appliquons à chaque package que nous intégrons.
1. Une table d'échange validée par écrit
La table d'échange — la liste des registres — est le contrat entre le package et le DCS. Elle doit être validée par écrit et tenue sous indice de révision, et chaque ligne doit préciser :
| Champ | Ce qu'il doit préciser |
|---|---|
| Adresse | Type de registre et adresse, et si la numérotation commence à 0 ou à 1 |
| Type de donnée | Entier 16 ou 32 bits, ou flottant ; signé ou non signé |
| Sens | Lecture seule, ou lecture et écriture par le DCS |
| Mise à l'échelle et unité | Comment la valeur brute se convertit en unités physiques |
| Signification | Pour les mots d'état et d'alarme : le sens de chaque bit |
La seule question des adresses comptées à partir de 0 ou de 1 explique bien des décalages d'un registre au démarrage. La trancher sur le papier ne coûte rien.
2. Ordre des octets, ordre des mots et mise à l'échelle — vérifiés sur des valeurs réelles
Une valeur 32 bits voyage dans deux registres de 16 bits, et tous les équipements ne les rangent pas dans le même ordre. Les octets d'un registre peuvent aussi être inversés. Une erreur ne produit pas de message d'erreur : elle produit un nombre plausible mais faux. C'est pourquoi nous vérifions l'interface sur des valeurs réelles, pas seulement sur le papier :
- forcer une valeur connue dans l'automate du package, ou lire une mesure stable et connue, et la comparer à ce qu'affiche le DCS ;
- vérifier au moins une valeur de chaque type de donnée utilisé dans la table ;
- vérifier la mise à l'échelle aux deux extrémités de la plage, pas seulement au milieu.
3. Un heartbeat pour détecter la perte de communication
Une valeur figée ressemble exactement à une valeur stable. Sans heartbeat (signal de vie), le DCS peut continuer d'afficher la dernière bonne mesure longtemps après la coupure de la liaison. Un chien de garde simple règle le problème : le package incrémente un compteur ou fait basculer un bit, le DCS vérifie qu'il change dans un délai défini et lève une alarme s'il se fige. Si le package doit lui aussi savoir que le DCS est vivant, le même principe s'applique dans l'autre sens.
4. Un comportement défini en cas de perte de communication
Détecter la perte ne fait que la moitié du travail. L'analyse fonctionnelle doit dire ce qui se passe ensuite, des deux côtés :
- ce que fait le package : continuer en local, rester dans son état actuel ou passer en arrêt sûr ;
- ce que fait le DCS : quelles séquences se mettent en attente, quels verrouillages agissent, quelles valeurs passent en mauvaise qualité ;
- quelle alarme reçoit l'opérateur, et avec quelle priorité ;
- ce qui se passe au retour de la communication — rien ne doit redémarrer seul sans règle définie.
5. Des commandes avec retour
Écrire un registre n'est pas exécuter un ordre. Chaque commande du DCS — marche, arrêt, consigne, changement de mode — doit être confirmée par un retour du package : état de marche, consigne effective, mode en cours. La logique du DCS compare commande et retour et lève une alarme de discordance s'ils diffèrent encore après un délai défini. Ne jamais supposer qu'un ordre a été exécuté parce qu'il a été envoyé.
6. Des alarmes du package compréhensibles par l'opérateur
Les packages remontent souvent leurs alarmes sous forme d'un mot d'état ou d'un seul bit « défaut général ». Un défaut général dit à l'opérateur que quelque chose ne va pas, mais pas quoi. Quand le package fournit le détail, nous ramenons les alarmes individuelles dans le DCS avec des textes clairs, la bonne priorité et le nom du package : l'opérateur sait s'il doit appeler la maintenance, le fournisseur, ou simplement réarmer. Les alarmes du package ont leur place dans la base alarmes et verrouillages, comme toutes les autres.
Un seul partenaire des deux côtés de l'interface
Beaucoup de problèmes d'interface viennent de deux équipes qui pensent chacune que l'autre s'occupe d'un point : la mise à l'échelle, le heartbeat, le comportement en perte de communication. Quand le même partenaire d'ingénierie intervient sur la configuration du DCS et côté automate, ces trous se referment tôt, pendant la conception plutôt qu'au démarrage. C'est pourquoi nous travaillons à la fois sur Emerson DeltaV et sur les automates Siemens.
En résumé
Une table d'échange validée par écrit, l'ordre des octets et des mots vérifié sur des valeurs réelles, un heartbeat, un comportement défini en perte de communication, des commandes avec retour et des alarmes claires : six points qui suppriment l'essentiel des soucis de démarrage avec les packages. Découvrez nos prestations d'automatisme Siemens et d'intégration au DCS.
Un package à intégrer à votre DCS ?
Envoyez-nous le périmètre et la table d'échange si vous l'avez : réponse sous 48 heures.