Secteur de l’eau : évolution de la communication entre dispositifs connectés ?

Cinq questions à Arnaud JUDES, Directeur commercial et responsable des relations avec les fabricants de matériel pour AREAL.

Question 1 : Quelles sont les tendances actuelles en matière de communication ?

Nous sommes régulièrement sollicités par de nouveaux entrants dans le domaine des objets connectés (IoT) ou des fabricants plus traditionnels qui proposent de nouveaux capteurs/équipements communicants pour l’instrumentation des réseaux d’eau potable et des réseaux d’assainissement. Leur objectif est d’être compatible avec Topkapi car ils savent que de nombreux clients, collectivité ou opérateurs, sont équipés de notre solution. Nous échangeons moins sur les réseaux de communications (Sigfox, LoRa, NB-IoT, LTE-M, etc.) mais plus sur les protocoles de communications pour intégrer les données dans Topkapi : MQTT, OPC UA, Webservices voire lecture de fichiers à plat. Tout dépend de la stratégie adoptée par le fabricant : lien direct entre l’équipement et la supervision ou données collectées par une plateforme logicielle hébergée chez le client ou dans le cloud avec laquelle il faut interfacer Topkapi.
 

Question 2 : Que propose AREAL pour prendre en compte ces nouvelles tendances ?

Dès 2017, nous avons anticipé les évolutions du marché en proposant à partir de la version 6.0 de Topkapi un protocole de communication dit scriptable. Il permet de gérer n’importe quelle source de données pour une intégration souple et évolutive de ces dernières dans notre plateforme logicielle. Le terme scriptable peut rebuter car il induit la nécessité d’avoir des compétences en programmation informatique (langage JavaScript) pour la mise en œuvre de l’acquisition de données. Mais c’est un mal pour un bien ! En réalité, le protocole scriptable apporte souplesse, adaptabilité et évolutivité face aux besoins rencontrés. 
A noter que les protocoles de communication du type Webservices ou protocole de messagerie MQTT ne sont pas standardisés. Par exemple, MQTT standardise seulement la couche transport mais pas la mise en forme des données échangées. On comprend alors aisément qu’il faille réaliser une adaptation du protocole d’acquisition quasiment pour chaque fabricant. Le socle MQTT étant fourni avec le protocole scriptable : il ne reste donc plus qu’à focaliser sur le décryptage des données.
 

Question 3 : Quelles sont les conditions de déploiement avec le protocole scriptable ?

Le script peut être réalisé par le client final lui-même s’il en a les compétences, un prestataire de son choix ou par nos soins. Nous proposons un transfert de compétences pour l’utilisation du protocole scriptable afin de comprendre l’intégration des données dans Topkapi. Cependant, je précise que nous ne formons pas au JavaScript : c’est éloigné de notre métier d’éditeur. Notez que ces nouveaux modes de communication prennent en compte la sécurité, HTTPS pour les Webservices, TLS ou SSL (chiffrement des données) pour MQTT. Quant à OPC UA, le standard intègre nativement l’authentification et le chiffrement des données. OPC UA est natif aujourd’hui dans Topkapi que ce soit en tant que client ou serveur de données.
 

Question 4 : Quels sont les retours d’expérience, les cas concrets d’usage ?

Ils sont nombreux depuis 2017. Par exemple, pour la régie des Eaux Gessiennes un Webservice a été scripté dans Topkapi pour réaliser l’interfaçage avec le backend (portail web) Sigfox. Il permet de faire l’acquisition de données de matériels Ijinus (instrumentation du réseau d’assainissement) ou Connit (pour la télérelève de compteurs). 
Les exemples de Webservices sont aussi nombreux : plateforme de données type Vigicrue ou Météo France, plateforme Web propriétaire Link2Valves pour les vannes communicantes de CLA-VAL ou encore interfaçage avec le portail Live Object d’orange (LoRA opéré pour la communication) qui propose également un connecteur MQTT pour mettre à disposition des données. 
La communication du très récent équipement IoT DeltaX de Perax elle se base sur MQTT : l’écriture du script a été réalisée par le fabricant sur la base du protocole scriptable pour être ensuite packagé par nos soins et mis à disposition pour toutes les licences (version récente) équipées du protocole Perax. 
 

Question 5 : Comment traiter toutes les données collectées dans Topkapi ?

Nous remarquons que nos utilisateurs ont tendance à collecter de plus en plus de données. Les besoins de traitement sont par conséquent plus nombreux : nous sommes sur la vague du Big Data et de la Data analyse. Avec Topkapi - dont l’une des fonctions principales est la collecte de données - nous essayons de répondre à l’ensemble des besoins clients :

• Traitements de données traditionnels de supervision : alarmes, présentation des données sous forme de courbes, etc.
• Traitements intelligents intégrés à Topkapi avec la mise en forme de KPI* (agrégation de données) et leur présentation sous forme de tableaux de bord. Sur ce dernier point, je vous invite à découvrir le nouveau module Dataviz, en version 6.2, intégré à Topkapi qui répond à ce besoin.
• Mise à disposition des données à des solutions tierces du système d’information pour un traitement externe à la supervision : de nombreux connecteurs sont proposés avec Topkapi au service de l’ouverture et de l’interopérabilité.

*KPI = Key performance Indicator / Indicateur clé de performance