Protocoles de communication

Passerelles et protocoles reliant des systèmes de contrôle-commande industriels — Intégration de systèmes de contrôle-commande, d’automates, de passerelles et de systèmes tiers.

ICSS intervient sur les communications industrielles depuis l’étude de l’architecture jusqu’à la mise en service et au diagnostic sur site. L’objectif n’est pas seulement d’établir une connexion : les mesures, états, alarmes, consignes et commandes doivent être transmis avec la bonne représentation, une qualité cohérente, des temporisations maîtrisées et un comportement sûr en cas de perte puis de reprise des échanges.

Cette approche associe la connaissance des protocoles à celle des systèmes de contrôle-commande et du procédé. Elle permet de suivre une information depuis le signal ou l’équipement de terrain jusqu’au contrôleur, à la supervision, à l’historian ou au dispatching, puis de vérifier l’effet réel d’une commande sur l’installation.

Protocoles, réseaux et systèmes concernés

Les interventions portent notamment sur les protocoles et architectures suivants :

Modbus RTU et Modbus TCP sur liaisons RS-232, RS-485 ou Ethernet, entre systèmes de contrôle, automates, passerelles, compteurs, analyseurs et équipements auxiliaires.
IEC 60870-5-101, IEC 60870-5-103 et IEC 60870-5-104 pour la téléconduite, les échanges avec les dispatchings et certains équipements électriques.
DNP3 et architectures mixtes associant plusieurs protocoles de téléconduite.
ICCP/TASE.2 pour les échanges entre centrales, centres de conduite et systèmes de gestion de l’énergie.
OPC et interfaces avec des historians ou systèmes de traitement de données tels qu’OSIsoft PI.
Profibus et communications avec des analyseurs, automates ou équipements tiers.
Réseaux et interfaces propres à ALSPA P320, notamment FIP, EPL, F8000, F900, S8000 et Contronet, ainsi que les passerelles CSS-F, CSS-G et équipements associés.
Réseaux Ethernet, pare-feu, routeurs et accès distants lorsqu’ils participent à la disponibilité ou à la sécurisation des échanges industriels.

Cette liste n’est pas limitative. Une architecture réelle associe fréquemment plusieurs générations de matériel, plusieurs constructeurs et des conversions successives. Le diagnostic doit alors tenir compte du comportement de chaque couche et pas uniquement du protocole visible à l’une des extrémités.

Étude, intégration et mise en service

ICSS peut prendre en charge la définition des échanges, leur implémentation dans le système de contrôle et leur validation avec les autres intervenants. Le travail comprend selon le besoin :

L’analyse des documents d’interface, listes de points, adresses, types de données, échelles, unités, qualités et horodatages
La définition des commandes, acquittements, retours de position, watchdogs et conditions d’autorisation
La création ou la modification des variables, tables d’échange, passerelles, blocs fonctionnels, logiques de supervision et vues opérateur
La préparation de simulateurs, fichiers de test ou outils d’import afin de fiabiliser et d’automatiser les opérations répétitives
Les essais point à point, tests de commandes, pertes de liaison, reconnexions, basculements et retours à l’état nominal
La mise en service en coordination avec le dispatching, le constructeur de l’équipement tiers et les équipes d’exploitation

Diagnostiquer toute la chaîne de communication

Une perte de communication apparente peut provenir du câblage, de l’adaptation électrique, d’un port série, d’un réseau Ethernet, d’une table d’adresses, d’un ordre des mots incorrect, d’une passerelle, de la logique du contrôleur ou du système qui consomme la donnée. À l’inverse, une liaison déclarée active peut transmettre des valeurs figées, des qualités invalides ou des commandes qui ne sont plus traitées par le contrôleur actif.

Le diagnostic croise les journaux des systèmes, événements horodatés, états de communication, captures Ethernet, trames série, essais de déconnexion et observation du procédé. ICSS utilise selon les cas des analyseurs de protocoles, des simulateurs comme ASE2000, des captures réseau et l’oscilloscope pour contrôler aussi bien la couche protocole que le signal physique.

Diagnostic d’une liaison Modbus RS-232 entre un système ALSPA P320 et un automate Siemens à l’oscilloscope — Analyse d’une liaison Modbus entre un système ALSPA P320 et un automate Siemens, avec décodage RS-232 à l’oscilloscope.

Simulation d’un maître Modbus avec ASE2000 pour contrôler les réponses d’un automate esclave — Simulation d’un maître Modbus avec ASE2000 pour vérifier les réponses de l’équipement esclave.

Redondance, reprise et qualité des données

La présence de deux interfaces ne garantit pas une communication réellement redondante. Il faut vérifier quel équipement est maître, quel contrôleur accepte les écritures, comment le chemin de secours est surveillé et dans quelles conditions il prend le relais. Les valeurs lues sur un contrôleur de secours peuvent rester cohérentes par synchronisation interne alors que les commandes adressées à ce même contrôleur ne sont pas exécutées.

ICSS contrôle donc séparément les lectures, les écritures, les états de validité, la fraîcheur des données, les watchdogs, l’élection du maître et le retour automatique après défaut. Les essais couvrent les différentes combinaisons de perte d’interface, de basculement de contrôleur, de redémarrage de passerelle et de reconnexion réseau afin d’identifier les modes de panne silencieux.

Blocs Modbus et outils spécifiques

Lorsqu’un équipement n’est pas correctement pris en charge par les fonctions existantes, ICSS peut développer ou reprendre les blocs nécessaires dans ALSPA P320. Des blocs Modbus ont notamment été réalisés pour des compteurs d’énergie SINEAX AM3000 et Metrawatt A2000, ainsi que pour des analyseurs AMI de pH/Redox, sodium et conductivité cationique ou acide. Ils gèrent les fonctions Modbus adaptées, l’enchaînement de plusieurs requêtes, la détection de l’esclave, les compteurs de défauts, la validité des sorties et la reprise après perte de liaison.

Sur les contrôleurs ALSPA, ces développements peuvent s’intégrer au bloc système MBEM et au séquenceur MBSC afin d’éviter les requêtes concurrentes et de partager proprement une interface entre plusieurs équipements. L’intégration ne s’arrête pas à la lecture de registres : elle comprend la conversion des mots reçus, l’ordre des octets, les types signés ou non signés, les valeurs IEEE 754 simple ou double précision, les échelles et la conservation de la précision disponible.

À Kwinana, cette approche a permis de fiabiliser les communications avec plusieurs compteurs et analyseurs, puis de traiter dans un contrôleur ne disposant pas de réels 64 bits des index d’énergie transmis en double précision. Une bibliothèque de conversions a été développée pour conserver une résolution exploitable par le contrôle-commande, la supervision et le système PI sans calcul intermédiaire dégradant la valeur.

Exemples d’interventions récentes

Hulu Terengganu : rétablissement des échanges IEC 104

Sur la centrale hydroélectrique de Hulu Terengganu en Malaisie, les deux passerelles CSS-G reliant le système ALSPA P320 Series 6 au centre national de conduite ne démarraient plus correctement. Le diagnostic a montré que des points supprimés de la base de supervision restaient présents dans les fichiers de configuration IEC 60870-5-104. Cette incohérence interrompait les processus des passerelles après leur démarrage. ICSS a rapproché les différentes versions de la base, corrigé et aligné les fichiers des deux interfaces, rétabli le câblage réseau vers les équipements du dispatching et préparé la validation des points et paramètres restant à harmoniser.

Sohar 3 : analyse des échanges Modbus entre ALSPA et Ovation

À Sohar 3, l’analyse des échanges entre les contrôleurs MFC3000 ALSPA et Emerson Ovation a mis en évidence plusieurs comportements différents derrière une architecture présentée comme redondante : lecture possible sur un contrôleur de secours mais commandes acceptées uniquement par le contrôleur maître, perte de communication après chargement en ligne, absence de reprise automatique de certaines interfaces et chemin de secours non surveillé en permanence. Sur les turbines à gaz, la configuration de passerelles Hilscher assurant une copie bidirectionnelle de registres Modbus TCP a également été sauvegardée et rétro-analysée afin de comprendre le mapping, la surveillance des liens et les limites de la redondance existante.

Angostura : coexistence ICCP et nouvelle architecture IEC 104

À Angostura, ICSS a analysé les pertes de données et les basculements de maître sur une architecture ICCP utilisée par l’AGC, puis préparé une nouvelle chaîne IEC 60870-5-104. Un superviseur ALSPA redondant et virtualisé a été intégré à la base Controcad, avec deux passerelles, une base de supervision dédiée aux échanges externes et un outil d’import des listes de signaux. La logique ajoutée vérifie séparément les watchdogs, l’identité du maître, la fraîcheur des consignes de puissance et la cohérence entre les deux chemins avant de sélectionner la donnée transmise à la régulation.

Ces réalisations illustrent une même méthode : comprendre l’architecture effective, reproduire le défaut, distinguer la disponibilité du réseau de la validité fonctionnelle des échanges, puis corriger la chaîne sans masquer la cause. D’autres exemples sont présentés sur la page Réalisations et études de cas.

Autres références

Les références historiques ci-dessous complètent les interventions récentes :

Cycofos : diagnostic de la chaîne reliant un ALSPA P320 Series 5 au système PI par IEC 104, passerelle CSS-G et serveurs OPC Matrikon redondants.
DK6 : extension des échanges avec OSIsoft PI de 2 000 à plus de 10 000 points.
Los Humeros : conception, essais et mise en service d’un lien redondant avec le dispatching associant OPC, IEC 104 et DNP3.
Kwinana : liaison DNP3 redondante pour la conduite de charge à distance, diagnostic d’échanges Modbus avec le système de brûleurs additionnels et intégration de nouveaux équipements Modbus.
GTX et CCPP22 : mise en place de la conduite de charge depuis le dispatching par IEC 104.
Kureimat : diagnostic de liaisons Modbus et IEC 101 et mise en œuvre de mesures de cybersécurité.
Terga et Flevo : diagnostic des échanges avec les contrôleurs de turbines Egatrol et Turbotrol au travers de passerelles ALSPA.
Tzafit : résolution de problèmes de communication avec différents automates et équipements tiers pendant la mise en service.
Niehl III : interfaces Profibus avec les analyseurs, Modbus avec une autre tranche, IEC 101 avec le dispatching, exports automatisés et sécurisation des réseaux.

Une expertise particulièrement adaptée à ALSPA P320

La connaissance interne d’ALSPA P320 permet de travailler simultanément sur la base Controcad, les contrôleurs, les blocs de communication, l’ALSPA HMI, les passerelles et les réseaux historiques. ICSS peut ainsi retrouver l’origine d’un échange, modifier sa génération, développer le traitement manquant et contrôler sa propagation dans le système complet. Cette maîtrise reste tout aussi utile lorsqu’ALSPA doit communiquer avec Emerson Ovation, Siemens, ABB, Schneider, des systèmes de dispatching ou des équipements spécialisés.

Présenter un besoin

Voir les réalisations

Contrôle-commande