Télégestion, supervision : l’interopérabilité des systèmes

Il faut en tout cas abandonner d’entrée l’espoir d’un langage universel. « Il n’y aura jamais un langage unique. Chaque protocole de communication n’est efficace que dans certains cas d’usage. Par exemple, un poste local de télégestion est tout le temps connecté pour piloter l’installation en temps réel, alors que les data logger ou capteurs IoT “dorment” la plupart du temps, ne poussant la donnée que lorsque c’est nécessaire. Ils doivent alors communiquer de manière efficiente en Lora, Sigfox, 4G… Le protocole retenu doit être adapté à la mission de chaque appareil » affirme ainsi Jérôme Floch, Product Manager-Supervision & Data analytics chez Lacroix Sofrel. Petit tour des solutions, niveau par niveau.

Couches “basses” : une grande variété

Première source de contraintes, en termes d’interopérabilité : certains capteurs ou actionneurs envoient leurs données ou reçoivent leurs instructions en mode analogique (4-20 mA en général, plutôt 0-10 V pour les variateurs de vitesse), d’autres en mode numérique (Modbus ou autres). « Les armoires électriques communiquent avec des équipements de marques et natures différentes. Le premier défi de l’interopérabilité, à ce niveau, est de mélanger l’analogique et le numérique. Les gens de terrain plébiscitent encore les organes analogiques car ils sont plus faciles à dépanner. Par ailleurs, dans les installations simples, une armoire qui pilote de 10 à 20 organes comporte un automate de télégestion. Au-delà, elle héberge deux équipements : un automate de télégestion, qui ne fait alors pas d’automatisme mais simplement de la transmission, et un véritable automate industriel programmable. Les deux sont reliés, généralement en Modbus TCP. C’est un autre niveau d’interopérabilité » souligne Jean-Marie Laurendeau, directeur Développement et Innovation chez Cetie, une société d’ingénierie en électricité industrielle et automatisme.

Spécialiste bien connu de la télégestion, Lacroix Sofrel propose deux grands types d’appareils. D’une part des data loggers -en fait des télétransmetteurs- autonomes pour l’instrumentation des réseaux et de tous les endroits dépourvus d’alimentation électrique, d’autre part des automates de télégestion (RTU) pour les sites plus centralisés (STEP, usine d’eau potable station de relevage, château d’eau, etc.). Tous utilisent le protocole de communication propriétaire de Lacroix, le LACBus RTU, pour envoyer leurs données, en général par des réseaux IP (ethernet, GSM…). Cette particularité ne pose cependant pas de problème. « Soit l’exploitant utilise une supervision ayant intégré en natif notre protocole, ce qui permet à nos produits de transmettre directement leurs données, soit nous proposons des passerelles qui autorisent la transmission des données de manière standardisée. En France, le protocole dominant dans le monde de l’eau est l’OPC UA mais d’autres, comme le DNP3 ou l’IEC 104 sont également présents, et même dominants sur certains marchés internationaux » affirme Jérôme Floch, de Lacroix Sofrel.

Schneider Electric domine - avec Siemens - le marché des automates industriels programmables dans le monde de l’eau. « En ce moment on parle beaucoup de convergence entre le monde de l’internet et le monde opérationnel. Nous devons donc apporter des solutions ayant des capacités de communication nouvelles, qu’on ne voyait pas auparavant dans monde industriel » explique Loïc Watel, System Architect Expert WWW chez Schneider Electric. La société propose une gamme complète allant des automates simples, dédiés à une machine, comme les M 221 et M 241, à des appareils adaptés au contrôle de process entiers, comme le M 580. « Tous communiquent en TCP-IP avec les protocoles normés OPC-UA ou DNP3 pour remonter facilement données vers les scadas du marché » détaille Loïc Watel. Il met également en avant l’automate ScadaPack RTU. « Le ScadaPack RTU, de Schneider Electric, est un nouvel automate programmable communicant pouvant s’interfacer à un modem GSM ou radio. Très robuste, il est adapté à des installations disséminées/dispersées dans la nature, par exemple sur des postes de relevage » affirme-t-il. La communication vers le “bas” - les capteurs et actionneurs - est un peu plus complexe. « Nous ne pouvons évidemment pas changer le parc des clients, imposer une marque ou un protocole. Nous utilisons donc des passerelles qui traduisent les divers langages de ces organes en protocoles TCP IP normés que nos automates comprennent tous » précise Loïc Watel.

« Aujourd'hui, la passerelle de données Ewon Flexy embarque nativement tous les principaux protocoles automates du marché + le Modbus RTU, TCP et l'OPC UA Client/Serveur, relève Olivier Benas, responsable IoT chez RG2I, architecte et distributeurs de solutions IOT. Cela permet ainsi de séparer la partie process et communication. En termes de publication de données, les clients peuvent choisir entre un échange direct en MQTT(s) ou HTTPS, ou indirect via l'API Rest “Talk2M” ».

Supervision : la gare de triage

Les scada voient converger ces flux divers, avant de renvoyer les données traitées vers les couches “supérieures”. Première difficulté : tous les data loggers n’utilisent pas le même protocole, sans compter le fait que de plus en plus d’organes connectés sont directement liés à la supervision sans passer par des automates. « Jusqu’à récemment, nous faisions face à une grande variété : chaque fabricant y allait de son protocole de communication propriétaire, et nous devions faire un développement logiciel spécifique pour chaque matériel. La donne a un peu changé ces derniers temps. On voit apparaître de nouveaux standards de communication sur le marché avec l’arrivée de nouveaux matériels » estime Arnaud Judes, direc­teur commercial d’Areal, éditeur de la plateforme logicielle Topkapi. Qui pré­cise que « toutefois, cette variété n’a jamais posé de problème pour Areal. En tant qu’édi­teurs de logiciels, nous faisons les développements nécessaires afin d’inté­grer chaque protocole propriétaire. C’est par exemple le cas avec Lacroix Sofrel : nous avons un accord d’échanges des spécifications de leurs protocoles ». Il ajoute cependant un petit bémol. « La standardisation des protocoles ne concerne pour l’heure que la couche de transport mais pas le contenu des mes­sages. Chaque fabricant y va toujours de sa façon de formater les données. D’où une certaine diversité de formats de données trans­férés par des protocoles communs comme MQTT ou des Web Services. Pour répondre à cette problématique, nous fournissons de notre côté un protocole dit ‘scriptable’ que nos clients peuvent personnaliser afin de faire leur propre acquisition de donnée. Cela demande néanmoins quelques compétences informatiques du côté de nos clients » explique-t-il.

Codra édite pour sa part le scada Panorama, évidemment confronté aux mêmes problématiques. « Panorama est totalement indépendant des fabricants, donc interopérable avec tous les automates de télégestion courants. Par exemple, on voit apparaître de plus en plus de protocoles universels pour des data loggers. Le MQTT est donc intégré d’office dans la nouvelle suite Panorama qui va sortir ce printemps. Cela permet d’interagir avec tout ce qui relève du monde de l’IoT. Il se rajoute aux protocoles déjà intégrés comme OPC-UA pour récupérer les données de la couche basse, mais aussi pour mettre toutes les données de Panorama à disposition de systèmes tiers : GMAO, ERP, etc » explique Jérôme Deyx, experts des métiers de l’eau chez Codra.

L’IoT : un chemin direct, des nouveaux langages

Cela va même désormais au-delà des simples capteurs ou compteurs. « Nous fournissons des data loggers autonomes très peu coûteux et adaptés aux milieux “peu sympathiques” : humides, noirs, éloignés. Tous sont qualifiés IP 68. Ils peuvent être utilisés pour le comptage ou la mesure de toutes sortes de grandeurs (pression, hauteur, inclinaison, luminosité, chlore, pH…). Nous utilisons le plus souvent des sondes fabriquées en Suisse mais nos appareils sont compatibles avec tous les compteurs à impulsions et tous types de sondes sortant en 4-20 mA. Notre particularité : nous utilisons un montage spécifique qui consomme très peu d’énergie » affirme Thierry Sartorius, PDG de Blue Whale Company qui vient d’intégrer le groupe Celec. Étant donné leurs spécificités - autonomie, faible coût et sobriété énergétique - les data loggers de Blue Whale Company sont souvent déployés en primo-équipement dans des endroits jusqu’alors non instrumentés, ce qui limite le problème du dialogue avec des capteurs préexistants. La gamme actuelle communique ses données par GSM en 2G, mais Blue Whale s’apprête à mettre sur le marché une nouvelle génération fonctionnant en 4G (NB-IoT et LTE-M). Le syndicat des eaux de Tremblay-en-France (Seine Saint Denis), par exemple, a choisi ces dataloggers. Blue Whale Company a également développé une solution logicielle de supervision, SPCanVision, dotée d’un langage propriétaire “universel”, capable de prendre en compte toutes les grandeurs physiques. « C’est un langage ouvert : nous donnons les clés au client. Le décodage est possible pour tous les serveurs du commerce… avec un peu de compétence informatique » ajoute Thierry Sartorius.

Chez Prisma Instruments « nous avons compris depuis longtemps qu'en matière de supervision et de télégestion l’interopérabilité est incontournable, assure Abdallah Boukli-Hacene, son directeur général. Ainsi, qu'il s'agisse de l'outil de supervision et de télégestion WebAccess, ou des dataloggers de la série ML-X17 que nous offrons à nos clients, le maître mot est la standardisations des moyens de communication ». La plateforme WebAccess, conçue dès l'origine pour un déploiement natif sur le web, offre ainsi pour toutes les applications IoT une palette de services Web, sur la base du protocole open source MQTT qui s'est imposé comme un standard pour ces applications, et des formats JSON, XML. « De la même manière, nos dataloggers sont des enregistreurs autonomes intelligents disposant d'une grande variété de moyens de communications standards. En matière d’acquisition, ils peuvent gérer un grand nombre d'entrées/sorties logiques et analogiques, capables d'effectuer des calculs mathématiques et d'agréger des données diverses. Ils peuvent également assurer la gestion de capteurs communicants en Modbus, SDI12 (jusqu'à 20 abonnés) et peuvent échanger en MQTT, TCP, FTP, HTT et email comme la plateforme WebAccess ».

Hydreka propose pour sa part un “automate autonome”, le DTU2, combinant l’autonomie des data logger à la capacité de calcul périphérique et de pilotage des automates. L’appareil intègre les données de différents capteurs et les envoie directement à la supervision par réseau téléphonique (3G ou 4G). « Chaque client a sa propre supervision, aussi faisons nous en sorte d’être compatibles avec la majorité des systèmes du marché (Topkapi, Lerne de Veolia, Panorama, etc.) » explique Korentin Jolivet, responsable marketing et communication chez Hydreka.

De leur côté, les éditeurs de logiciels scadas clas­siques doivent s’adapter à l’arrivée de données provenant de l’IoT. « Nous en avons déjà l’expérience avec le portail Live Objects, d’Orange Business Services. Nous avons réalisé un développe­ment qui permet à notre solution Topkapi d’aller chercher les données sur cette plateforme. Nous nous efforçons de rester ouverts à ces nouvelles technologies » affirme ainsi Arnaud Judes, Areal. « Récemment, par exemple, le conseil général des Hauts de Seine a positionné des capteurs autonomes sur son réseau d’assainissement supervisé (Gaia 2). Ces derniers remontent leurs données en Lora opéré sur le portail Live Objects, auquel la solution Topkapi est connectée » rapporte-t-il. Jérôme Deyx, de Codra, confirme : « beaucoup de nouveaux produits communiquant en Lora ou Sigfox passent par des portails Web ou de la basse fréquence. Panorama est compatible avec eux car nous utilisons des Web Services, du MQTT, etc ». Un industriel près de Toulouse, équipé d’un Panorama connecté à des automates classiques, a ainsi voulu récupérer des données de compteurs d’eau avec un datalogger non référencé, communiquant en MQTT. « L’intégrateur l’a simplement connecté en MQTT sur le Panorama, ce qui n’a posé aucun problème puisque c’est un protocole usuel » rapporte Jérôme Deyx. Même cas de figure à la nouvelle STEP de Mont de Marsan (Jouanas), dont les automates industriels de l’usine sont connectés au Panorama ainsi qu’aux télégestions Sofrel installées dans les postes de relevage. Le client final a émis le souhait de valider la compatibilité de nouveaux dataloggers en MQTT avec Panorama, ce qui n’a pas posé aucun problème.

« C’est une tendance de fond aujourd’hui : les protocoles internet font leur apparition. Les télégestions doivent de plus en plus mêler les protocoles standards de télégestion et ceux de l’internet (IT) » résume Jérôme Floch, de Lacroix. « Cela va perdurer. Nos produits de télémétrie, à la différence des produits IoT qui sont “consommables”, ont une durée de vie de 10-15 ans. Donc ces deux mondes, l’internet et l’opérationnel, vont cohabiter un certain temps dans les supervisions » renchérit Ludovic Pertuisel, Product Manager chez Lacroix.

Couches “hautes” : l’exploitation des données

Même constatation chez Codra. « Panorama est complètement ouvert, ce qui permet aux logiciels de la couche “métier” de venir chercher les données. Cela se fait soit à travers une base de données, soit via une communication OPC UA. Donc si le client a déjà des outils métier, nous voyons par quels moyens les connecter à Panorama. Nous pouvons également proposer notre solution Panorama H2 qui permet de faire les reportings, via une interface Web, et créer tous les indicateurs dont il a besoin » expose Jérôme Deyx. « Panorama dispose aussi de Web Services, par exemple pour pouvoir importer des données issues de portails web comme ceux de données Météo mises à disposition. Ce sont les portails eux-mêmes qui définissent le format des données, par exemple du format Json » précise Jérôme Deyx. La nouvelle Panorama Suite 2022 intègre un tout nouveau moteur Web qui s’inscrit toujours dans notre démarche de cybersécurité. Codra reste à ce jour le seul éditeur de supervision qualifié par l’ANSSI qui propose son superviseur certifié également par l’ANSSI insiste Jérôme Deyx.

Birdz commercialise la solution FluksAqua, un outil de valorisation des données issues de la supervision. « Nous avons une politique claire. Dès 2017, nous avons choisi d’être agnostiques pour toute la chaîne amont de mesure et de collecte des données. Nous avons mis en place un système de passerelles très polyvalent » affirme Lionel Hude, responsable offre FluksAqua chez Birdz. « Les exploitants n’utilisent pas forcément une seule marque de plateforme de collecte, voire un seul scada. Nous pouvons faire face » ajoute-t-il. Ainsi la Roannaise des Eaux (Loire) récupère-t-elle ses données de compteurs et débitmètres de différentes marques, via des systèmes de télégestion variés (Sofrel, Perax…) remontant sur un scada Topkapi. A cette architecture classique s’ajoutent des équipements Primayer (devenu Ovaro) qui remontent leurs données sur la plateforme Prime Web. « Nous sommes arrivés dans cette situation. Une de nos valeurs ajoutées a été de pouvoir utiliser les données remontant de l’interfaçage avec Topkapi comme de Prime Web, et les croiser pour donner une vision homogène des indicateurs métier. L’année dernière, nous avons ajouté un système de récupération des données liées à des gros consommateurs : un comptage Itron qui remonte sur une plateforme Web. Nous pouvons là aussi croiser ces données avec celles des deux autres sources » rapporte Lionel Hude. Située “au bout” de la chaîne de traitement/analyse des données, la solution FluksAqua peut exporter des informations sous différents formats : Excell par exemple, ou Sandre pour des besoins réglementaires.

Veolia a également développé, outre ses outils de supervision comme Lerne, une couche métier qui peut récupérer des données de toute provenance afin de les exploiter. « Nous travaillons avec le parc existant plutôt qu’imposer une remise à plat lorsqu’on nous confie l’exploitation. Cela nous a demandé un gros travail de développement pour intégrer tous les langages dans nos hypervisions. Nous avons fait le choix d’être interopérables. Notre système est ouvert, nous pouvons interroger les autres systèmes et vice versa, via des API, bien sûr en respectant les conditions de cybersécurité » affirme Pierre Rousseau, responsable Digital France chez Veolia Water Technologies. L’offre se décline en différents niveaux. Le premier, Essential, consiste à connecter des installations encore dépourvues de systèmes de télégestion. « Nous installons des capteurs et transmetteurs du marché que nous relions à l’équivalent d’une supervision, mais dans le Cloud » explique Pierre Rousseau. Le niveau Performance correspond à une couche “métier”. « Nous avons mis en équation notre grande expertise des métiers de l’eau. Nous pouvons construire, en temps réel comme en différé, des indicateurs pertinents à partir des données brutes. Nous pouvons aussi faire de la gestion prévisionnelle sur certains organes, comme les osmoseurs ou notre système à charbon actif Actiflo®. Plus récemment, nous avons introduit de véritables jumeaux numériques de certaines installations. On ne peut faire ça que dans le Cloud car les sites n’ont pas la puissance de calcul nécessaire » énumère Pierre Rousseau. Enfin, le niveau Assist fait intervenir des experts réels lorsque les outils informatiques ne suffisent pas. « Au début le système restait cantonné à l’eau. Dans une collectivité, nous rassemblions des données issues de postes de relevage et de la STEP, par exemple. C’est un bon début d’interconnexion mais maintenant nous prenons en compte toutes les données internes et incluons des données externes comme celles des radars de MétéoFrance, pour tout intégrer dans les jumeaux numériques » affirme Pierre Rousseau. Pour John Cockerill Environment qui conçoit et optimise des installations de traitement d’eau et de pompage depuis plus de 30 ans pour ses clients municipaux et industriels, l’enjeu de l’interopérabilité s’est très vite imposé également comme un point essentiel à maîtriser. « Notre Business Line John Cockerill Water a sa propre équipe d’automaticiens qui intègre les différents protocoles de communication, “bas” et “hauts” niveaux, tant industriels (Modbus, OPC-UA, …) que liés à l’IoT (MQTT, …). De cette manière, nous pouvons répondre aux besoins de nos clients : l’intégration “transparente” et fluide de la remontée, la normalisation et l’exploitation des informations issues du site. En collaboration étroite avec les fabricants de matériel et de logiciels, notre équipe interconnecte tous les niveaux de gestion de données pour répondre aux acteurs de terrain, aux pilotes des installations ou aux managers suivant leurs besoins respectifs ». Pratiquement, cela se traduit par la capacité à adapter le niveau de détail en fonction des utilisateurs ou en mettant en place des outils d’analyse de données (développés en interne ou en partenariat comme avec la société WideTech). « Côté hardware, nous pouvons également proposer une passerelle universelle - John’s Connector - entre le site et les outils d’aide à la décision- et fournir à nos équipes de services, à nos metteurs en route process et in fine à nos clients un accès aisé aux données de fonctionnement des installations », souligne Fabrice Delfosse, Expert PLC/Automatisme chez John Cockerill Water.

Itron propose quant à elle, via l’intelligence embarquée de sa solution Water Operation Management (WOM), de faire la transition entre les flux de production et de facturation et a ainsi travaillé l’interfaçage de ses solutions et systèmes avec des acteurs existants. « Nous avons travaillé par exemple avec Lacroix Sofrel pour collecter et rediriger les données vers nos systèmes de gestion de comptage d’eau afin de les faire converger vers nos données consommateurs, résidentielles ou commerciales et industrielles », souligne Pierre Flamand, Responsable Produit de plateforme gestion de compteurs eau chez Itron. En outre, dans son portefeuille de solutions, WaterMind permet la supervision de compteurs de sectorisation et gros consommateurs. « Pour couvrir le marché français, nous avons ouvert nos interfaçages aux acteurs existants afin de permettre la collecte de données haute résolution, indispensable au traitement de nos algorithmes logiciels », explique Pierre Flamand. La finalité étant de fournir des indicateurs aux compagnies d’eau dans le cadre de leur effort de réduction de perte en eau et d’identification de fuite.

Cette couche métier est aussi le domaine d’éditeurs spécialisés connaissant bien les problématiques de l’eau comme Arc Informatique, HTT Project, IP Systèmes, ou encore de spécialistes de l’IA comme Purecontrol qui s’appuie sur des technologies de machine learning pour valoriser les données issues des équipements et pour les croiser à des facteurs externes. Dans cette logique chez Technilog, Dev I/O est un frontal d’acquisition multi-protocole, multi-application, multi-canal qui fédère différents canaux de communication et protocoles propriétaires des constructeurs. « Le logiciel rend ainsi indépendant l’évolution des couches matérielles et logicielles hétérogènes (SCADA, plateforme dédiée à gestion de l’efficacité énergétique, Microsoft Azure, AWS…), afin de monitorer le fonctionnement de chaque protocole, cloisonner certains flux sensibles et délocaliser l’acquisition de données pour certains ouvrages », détaille Jean-François Ducourtioux, directeur des Opérations chez Technilog.

Un monde complexe mais fonctionnel

Couches multiples, protocoles de communication variés, réseaux différents : tout cela peut paraître compliqué. « Au total, cela ne marche pas trop mal dans l’environnement français : tous les systèmes arrivent à communiquer entre eux » estime Pierre Rousseau, responsable Digital chez Veolia. Un bilan globalement positif que partagent tous les acteurs interrogés. « A l’image des autres secteurs, le monde de l’eau voit lui aussi arriver la généralisation de l’IP, les communications en temps réel, l’explosion du volume des données et l’émergence de protocoles standardisés comme MQTT ou DNP3, aux côtés des protocoles historiques très couramment utilisés comme Modbus-RTU et Modbus-TCP ou, plus récemment, OPC-UA. Ainsi, l’interopérabilité reste donc un enjeu, mais jamais un problème, les fabricants proposant des passerelles de communication ou interfaces de connexion bien maîtrisées par les intégrateurs du métier  » confirme Jean-Marie Laurendeau (Cetie).