Comment historiser vos données machines avec InfluxDB et Grafana ?
Sur une ligne de production, la question revient tôt ou tard : que faire des données que vos automates génèrent en continu ? Températures, cadences, états de marche, consommations, tout cela transite déjà par vos PLC et vos SCADA, mais rarement de manière exploitable sur le long terme. Les historians industriels traditionnels (OSIsoft PI, Wonderware, Canary) répondent à ce besoin depuis longtemps, avec des licences et des coûts d’intégration qui freinent souvent les PME. Une alternative s’est installée progressivement sur le terrain : associer InfluxDB et Grafana pour bâtir un historian open source, sans frais de licence et avec un contrôle complet sur l’architecture.
Cette combinaison n’a rien d’expérimental. Des intégrateurs et des éditeurs de solutions de mesure l’utilisent déjà en production, preuve que le duo tient la charge sur des cas réels d’usine.
Pourquoi InfluxDB pour historiser des données machines
InfluxDB est une base de données de séries temporelles (time series database), écrite en Go et pensée dès l’origine pour encaisser un flux continu de mesures horodatées. Contrairement à une base relationnelle classique, elle ne demande pas de modéliser des tables à l’avance : chaque point de donnée arrive avec son horodatage, ses tags (identifiants d’équipement, de ligne, de site) et ses champs (valeurs mesurées). Cette absence de schéma rigide facilite grandement l’ajout d’une nouvelle variable machine sans repenser toute la base.
Supervision en temps réel des métriques de performance et du trafic API d’un cluster InfluxDB (© grafana.com)
Côté performance, InfluxDB encaisse des dizaines de milliers d’écritures par seconde sur du matériel standard, ce qui couvre largement les besoins d’un site industriel multi-machines. La compression des données temporelles permet aussi de conserver plusieurs années d’historique sans exploser le stockage, un point souvent décisif face aux historians propriétaires qui facturent la rétention longue durée.
Le rôle de Grafana dans la chaîne
Grafana ne stocke rien : c’est la couche de visualisation qui vient interroger InfluxDB pour construire des tableaux de bord. Son plugin de source de données InfluxDB (ou le plugin InfluxDB SQL pour les versions v3+) s’intègre nativement, laissant le choix selon la version de votre base entre InfluxQL, le langage SQL standard ou Flux pour les requêtes plus fines et les cas avancés.
Pour un technicien de maintenance, l’intérêt tient surtout à la rapidité de mise en place d’une courbe de tendance ou d’un tableau d’alarmes. Une fois la source de données connectée, créer un graphique de température sur 24 heures ou comparer la cadence de deux lignes ne demande que quelques minutes, sans écrire de code.
Collecter les données depuis vos automates
La brique qui manque souvent dans les présentations théoriques, c’est la collecte terrain. C’est le rôle de Telegraf, l’agent open source d’InfluxData, qui embarque plus de 300 plugins d’entrée. Pour l’automatisme industriel, les plugins les plus utilisés sont OPC UA et Modbus TCP, qui couvrent la grande majorité des automates récents (Siemens S7-1200/1500, Schneider, Rockwell) et des équipements plus anciens raccordés via une passerelle.
Contactez nos experts pour connecter vos automates à une base InfluxDB.
Pour les automates ne disposant pas nativement d’un serveur OPC UA, Node-RED reste une solution intermédiaire fréquemment utilisée pour implémenter des flux de communication ou faire office de passerelle de protocole, notamment sur des installations mêlant Modbus et OPC UA.
Déploiement et architecture
Le déploiement le plus courant repose sur des conteneurs Docker : un conteneur pour InfluxDB, un pour Grafana, un ou plusieurs pour Telegraf selon le nombre de sources à collecter. Cette approche permet de démarrer avec un historian fonctionnel sur une seule machine hôte en une demi-journée, puis de faire évoluer l’architecture.
Trois schémas reviennent régulièrement sur le terrain. Le premier, local, place tout sur un seul hôte à proximité de la machine ou de l’atelier concerné. Le second, en scale-out, centralise InfluxDB et Grafana sur un serveur unique tandis que plusieurs agents Telegraf collectent les données de différentes lignes. Le troisième, cloud, héberge la base et les tableaux de bord à distance tout en gardant la collecte au plus près des équipements, pour les sites multi-usines qui veulent une vue consolidée.
Limites et contraintes à anticiper
Un historian open source demande un investissement en compétences que les solutions propriétaires masquent souvent derrière leur prix de licence. La configuration de Telegraf pour OPC UA nécessite de connaître précisément les espaces de noms et les identifiants exposés par l’automate, ce qui suppose l’usage d’un client OPC UA type UaExpert en phase de préparation.
La sécurité mérite aussi une attention particulière. Activer une politique de sécurité OPC UA (certificats, chiffrement) complique la mise en route si les certificats ne sont pas gérés correctement, avec un risque de boucle de régénération à chaque redémarrage si l’étape n’est pas anticipée.
Enfin, contrairement à un historian certifié, la responsabilité de la maintenance, des mises à jour et des sauvegardes repose entièrement sur vos équipes ou votre intégrateur. Sur un site critique, il faut prévoir une redondance ou un plan de sauvegarde de la base InfluxDB, faute de quoi une panne serveur peut faire perdre l’historique.
Conclusion
InfluxDB et Grafana forment aujourd’hui une base solide et éprouvée pour historiser les données de vos machines sans dépendre d’une licence coûteuse. La combinaison avec Telegraf pour la collecte OPC UA ou Modbus couvre la majorité des cas industriels courants. La démarche la plus raisonnable reste de démarrer petit, sur une ligne ou un atelier, avec une architecture Docker simple, avant d’étendre progressivement le périmètre une fois les premiers tableaux de bord validés par les équipes terrain.
