Comment Teréga a développé son historien de données « maison »

Une modernisation nécessaire

Huit ans plus tôt, Teréga exploitait une infrastructure IT adaptée à son activité, mais qui était « très peu agile ». « Nous avions tout sur site, avec des centres de données locaux redondés. Notre agilité était assez limitée pour créer de nouveaux services », se rappelle Thomas Delquié.

L’arrivée de Dominique Mockly à la tête du groupe en 2016 a été le déclencheur d’une transformation IT. « La nouvelle direction a décrété que le digital serait moteur pour améliorer la performance dans l’entreprise », indique le CTO de Teréga Solutions.

Si l’existence de Teréga Solutions est la preuve de cette transformation, il faut se rappeler qu’elle a commencé par une migration progressive vers le cloud de la majorité des systèmes et du remplacement pour certains d’entre eux par des outils SaaS.

Un des projets emblématiques de cette transformation n’est autre que l’ouverture des données industrielles à l’échelle du groupe.

Nés dans les années 1980 et réellement déployés au cours de la décennie suivante, les historiens de données sont des architectures IT-OT pensées pour gérer les données industrielles. Bon nombre d’industriels s’appuient sur ces systèmes pour gérer leurs opérations. Teréga ne fait pas exception.

Le groupe arrivait déjà à récolter les informations des capteurs disséminés sur les 5 100 kilomètres de pipelines et sur ses 600 points de livraison pour les stocker et les présenter dans un système SCADA et un historien central, redondé.

Le réseau de cette architecture IT était complexe à gérer, tandis que la récupération des données depuis les différents sites entraînait des lenteurs d’ingestion. De même, la nécessité de redonder les données impliquait l’achat de baies de stockage et des licences correspondantes.

« Tout le reste de l’entreprise devait appeler la salle de contrôle afin d’obtenir les indicateurs ou des données opérationnelles ».

Pire, ces données industrielles n’étaient accessibles que par les opérateurs en salle de contrôle. « Tout le reste de l’entreprise devait appeler la salle de contrôle afin d’obtenir les indicateurs ou des données opérationnelles, comme la valeur de pression du gaz, par exemple », signale Thomas Delquié.

InfluxDB, un choix naturel

Teréga a d’abord envisagé de migrer son historien OSIsoft PI vers le cloud. « Nous nous sommes dit que nous pouvions effectuer une copie de notre historien dans le cloud », relate Thomas Delquié. Ce projet, simple sur le papier, a rapidement été abandonné. « C’était non seulement extrêmement compliqué de copier ces données, d’assurer leur cohérence, mais également très coûteux ».

Perçu comme une exigence contradictoire à l’époque, Teréga souhaitait obtenir l’agilité promise par le cloud tout en conservant le niveau de cybersécurité que ses clients et l’État français sont en droit d’attendre de lui.

Il n’existait pas de solution sur étagère à la fois robuste et agile pouvant répondre aux besoins de l’entreprise.

Il y a cinq ans, l’équipe de Thomas Delquié se renseigne alors sur les briques disponibles dans le cloud auprès des deux fournisseurs cloud principaux du groupe, AWS et GCP.

Sécurité, performance et facilité d’utilisation étaient les principaux critères de choix au moment de concevoir son « propre historien dans le cloud ».

Avant tout, avant d’être un système de gestion des données industrielles, un historien est une base de données time series.

« Nous nous sommes rapidement dirigés vers la base de données leader du marché : InfluxDB. Elle est très performante, simple à utiliser, il y a beaucoup d’outils pour l’exploiter. Nous étions totalement rassurés », indique Thomas Delquié. « De plus, InfluxData proposait un service managé autoscalable, ce qui pour nous était très important, puisque nous ne voulions plus être des exploitants de data center. Ce n’est pas notre métier ».

Il fallait choisir le cloud d’accueil de ce SGBD. « Nous avons fait un POC comparatif. Nous avons fait un petit peu “la bagarre”. Moi, j’ai testé InfluxDB sur GCP, et mes collègues ont fait de même sur AWS. Ils ont gagné », relate le CTO.

D’autant qu’AWS offrait à l’époque davantage de services, que l’écosystème était plus mature et qu’il était en passe de devenir le cloud de choix du groupe industriel, selon le CTO de Teréga Solutions.

Teréga a donc choisi InfluxDB Cloud 1 et migrera plus tard vers InfluxDB 3.0.

Une dizaine d’applications analytiques

Un moteur ne suffit pas. Après des tests concluants en matière d’ingestion de données et de réutilisation des requêtes, il fallait développer des services pour reproduire les fonctionnalités clés de l’historien en évitant les déboires passés.

Pour assurer la collecte sécurisée de données depuis ses sites industriels, le groupe a développé son propre équipement IoT. Indabox, c’est un boîtier physique compatible avec les protocoles OPC-UA, MODBUS, TCP et EthIP, « à implanter à proximité des automates existants ».

Ces boîtiers installés sur les 600 sites du groupe ont permis de se connecter directement aux services cloud en évitant de passer par un dépôt intermédiaire sur site qui aurait complexifié la collecte des données.

Les données transitent depuis les sites industriels via HTTPS au format JSON et sont envoyées vers un répartiteur de charge qui les fait passer par un réseau privé. Une passerelle API de « transit » sépare le compte AWS d’InfluxData et celui de Teréga. En périphérie, le tout est protégé à l’aide de l’outil d’authentification OAuth2 d’Auth0 (racheté par Okta) et d’AWS CloudFront, en sus des mesures prises sur site.

« Nous sommes convaincus que nous sommes plus en sécurité dans le cloud que sur site », assure Thomas Delquié. « En sus des mesures prises par AWS, nous avons ajouté des surcouches pour l’accès et l’authentification, des règles Ops, des bonnes pratiques de développement et nous réalisons très régulièrement des pentests avec Yogosha ».

Les données brutes sont stockées dans InfluxDB, tandis qu’une couche de cache Redis doit accélérer les visualisations de données en temps réel (une latence de l’ordre de quelques secondes). DynamoDB sert quand les utilisateurs veulent filtrer des données sans perturber le système en production.

Une fois cela fait, Teréga a « recrée des capacités de reporting et de visualisation de processus, tel que l’on peut les retrouver dans OSIsoft de manière plus simple, mais largement suffisante pour ses besoins », ajoute notre interlocuteur. Concrètement, les opérationnels ont leurs alarmes et leurs vues sur les processus.

Plus récemment, Teréga a lié son historien maison qui récolte non plus 50 000 points de données, mais 120 000 (pression, qualité du gaz, statut des valves, température, consommation électrique, vibration, latences, etc.) avec Snowflake et Power BI. Si le data warehouse peut être utilisé pour préparer les données avant de les afficher dans la suite BI, Teréga a mis au point des connecteurs « directs » pour afficher les données entrantes dans l’historien à des fins opérationnelles.

« Nous avons non seulement augmenté le nombre de données, mais aussi la fréquence de collecte ».

« Nous avons non seulement augmenté le nombre de données, mais aussi la fréquence de collecte », signale Thomas Delquié.

Auparavant, Teréga observait les livraisons de gaz chez ses clients à l’aide d’un capteur qui prenait une mesure toutes les minutes. Or un client industriel se plaignait de coupure dans la distribution.

« Avec l’ancien système, tout semblait fonctionner sans problème, mais en augmentant la fréquence de collecte, nous avons constaté des microcoupures qui se produisaient entre les prises de mesures », raconte le CTO de Teréga Solutions. « Il y avait des périodes de dix secondes où le gaz n’était plus délivré. Grâce à l’amélioration de la collecte, nous avons pu identifier ce problème et le régler ».

Un tel projet ne s’est pas fait en un jour.

D’autant que le groupe souhaitait internaliser les compétences. « Nous avons intégré des développeurs et des Tech leads. Pour les aspects dont nous n’avions pas la maîtrise en interne, nous nous sommes appuyés sur des partenaires comme Skale-5 pour l’exploitation du cloud et de manière ponctuelle sur Inetum, Capgemini et Equinis ».

Petit à petit, le groupe a développé une dizaine d’applications de reporting opérationnel, comptable, d’analyse vibratoire, de prévision, de simulation, de maintenance prédictive et de protection cathodique (analyse de la corrosion des pipelines). 

« Très rapidement, nous avons développé deux applications : la protection cathodique et la surveillance de tous nos postes de livraison », commente le CTO de Teréga Solutions.

La naissance d’IO-Base

Ce n’est pas tout. « Au bout de deux ans de travail sur cet outil, nous nous sommes dit qu’il était temps de se débarrasser d’Osisoft PI, parce que trop coûteux, trop lourd », poursuit le CTO. « Nous avons basculé toutes nos données dans l’historien et nous avons conservé PI juste en backup et pour des cas d’usage très précis ».

Après avoir décommissionné son historien sur site, Teréga a pu réduire de 50 % le coût total de possession de son historien tout en doublant le volume de données analysées. L’ensemble des métiers concernés peuvent accéder aux données des sites et les performances du système s’avèrent meilleures que celle du SI historique.

Au moment de lancer sa filiale Teréga Solutions, il était naturel pour l’opérateur gazier qu’elle développe et vende cet historien de données « maison ». Le nom de ce produit ? IO-Base.

« Teréga Solutions poursuit le développement d’IO-Base pour ses premiers clients et nous sommes là pour aider tous les clients qui souhaitent quitter leur data historian afin d’adopter un outil moderne et fonctionnel », vante le CTO.

L’éditeur collabore avec ses partenaires AWS, Skale-5, Slowsense, Biogasview, Starting blocks ou encore Omnegy.

Parmi les applications en cours de développement, Teréga Solutions met au point un simulateur consacré aux réseaux de gaz. « C’est un outil utile pour Teréga et pour tout opérateur de réseau afin de l’opérer et l’optimiser », déclare-t-il. La commercialisation de ce simulateur est prévue l’année prochaine.