La supervision d’un poste de transformation HTA ne se limite pas à vérifier si une cellule est sous tension. Pour comprendre les perturbations électriques, anticiper les défauts et corréler les événements réseau avec les arrêts de production, il faut collecter les mesures des analyseurs de réseau, relais de protection, compteurs et équipements Modbus. Eziwan centralise ces données terrain, les transforme en grandeurs exploitables et les publie vers InfluxDB pour une visualisation Grafana claire et historisée.
Le problème
Un gestionnaire de réseau industriel doit collecter les mesures de 18 analyseurs de réseau Schneider PM800 en Modbus TCP et de 12 relais de protection Sepam en Modbus RTU dans plusieurs postes HTA. Les données attendues couvrent la tension, le courant, les puissances active et réactive, le facteur de puissance, la fréquence, les harmoniques, les alarmes et certains états de protection.
Sur le papier, Modbus paraît simple. Sur le terrain, la supervision d’un poste HTA devient vite complexe.
-
Les tables de registres Modbus des équipements anciens sont parfois incomplètes, dispersées ou dépendantes de la version firmware.
-
Les unités, facteurs d’échelle et formats numériques varient selon les familles d’équipements : entier signé, entier non signé, flottant 32 bits, mot haut avant mot bas ou ordre inverse.
-
Les analyseurs Modbus TCP et relais Modbus RTU ne se collectent pas de la même manière : topologie, latence, timeout et fréquence de polling doivent être adaptés.
-
Les passerelles propriétaires répondent souvent à un besoin précis, mais supportent mal l’ajout d’un nouveau protocole, d’un nouveau compteur ou d’une transformation métier.
-
L’absence de transformations embarquées oblige à convertir les valeurs brutes côté cloud, ce qui crée une couche applicative coûteuse à maintenir.
-
Les équipes énergie, maintenance et production n’ont pas toujours une vue commune pour relier une perturbation électrique à un arrêt machine, une alarme automate ou une baisse de qualité.
-
Les postes HTA sont parfois isolés, avec une connectivité limitée ou intermittente, ce qui impose de bufferiser les mesures localement.
L’enjeu est donc double : fiabiliser la collecte Modbus et rendre les données immédiatement exploitables dans une chaîne InfluxDB, Grafana, supervision ou GMAO.
Objectif de supervision
Dans un poste de transformation HTA, les données électriques servent à comprendre le comportement réel du réseau. Elles permettent de suivre la charge, détecter les déséquilibres, identifier les creux de tension, surveiller les harmoniques et analyser les événements de protection.
Les mesures typiques à collecter sont :
-
Tensions simples et composées.
-
Courants par phase.
-
Puissance active, réactive et apparente.
-
Facteur de puissance.
-
Fréquence.
-
Énergie active et réactive.
-
THD tension et courant.
-
Harmoniques par rang selon les capacités de l’analyseur.
-
États des relais de protection.
-
Alarmes, défauts et déclenchements.
-
Horodatage des événements lorsque disponible.
Ces données prennent toute leur valeur lorsqu’elles sont historisées et corrélées avec les événements de production : arrêt de ligne, défaut variateur, redémarrage automate, déclenchement protection ou baisse de rendement.
Architecture recommandée
L’architecture cible place une gateway Eziwan dans le poste ou à proximité de la zone électrique. Elle collecte les équipements Modbus TCP sur Ethernet, interroge les équipements Modbus RTU sur RS-485, applique les transformations nécessaires puis publie les séries temporelles vers InfluxDB. Grafana fournit les tableaux de bord énergie et qualité réseau.
Cette architecture évite de multiplier les logiciels de collecte et rend la donnée électrique disponible dans un format standard, exploitable par les équipes énergie, maintenance et production.
Notre approche
Eziwan centralise la collecte Modbus, la transformation des registres et l’envoi vers les outils de supervision. La gateway agit comme un collecteur industriel capable de parler aux équipements existants, de diagnostiquer les échanges et de normaliser les données avant publication.
-
Interface de diagnostic en temps réel : visualisation des valeurs brutes lues sur chaque registre Modbus depuis l’interface web, sans outil externe.
-
Librairie de templates constructeurs : configurations pré-établies pour les compteurs, analyseurs, variateurs et capteurs Modbus courants, notamment Schneider, ABB, Siemens et Danfoss.
-
Support des équipements hérités : prise en charge de scénarios Modbus RTU, Modbus TCP, Modbus ASCII et passerelles associées aux environnements Schneider historiques selon l’architecture du site.
-
Transformations embarquées : conversion des registres bruts en grandeurs physiques, application des facteurs d’échelle, renommage des points, tags de site et horodatage.
-
Publication vers InfluxDB : écriture des mesures sous forme de séries temporelles prêtes pour Grafana.
-
Buffer local : conservation temporaire des données en cas de coupure réseau, puis rattrapage lorsque la connectivité revient.
-
Supervision du collecteur : état des équipements, erreurs Modbus, temps de réponse, trames en timeout, disponibilité par équipement.
Cette approche s’intègre naturellement avec la gateway Eziwan, les architectures de connectivité industrielle et la supervision centralisée via le cloud Eziwan.
Modbus TCP et Modbus RTU dans un poste HTA
Modbus TCP et Modbus RTU reposent sur une logique proche, mais leurs contraintes d’exploitation sont différentes. Dans un poste HTA mixte, il faut adapter la collecte à chaque support.
| Critère | Modbus TCP | Modbus RTU |
|---|---|---|
| Support | Ethernet IP | RS-485 ou RS-232 |
| Adressage | Adresse IP et port | Adresse esclave sur bus série |
| Performance | Plus rapide selon réseau | Dépend du baudrate et du nombre d’équipements |
| Diagnostic | Ping, port TCP, logs réseau | Analyse bus, timeout, collision, câblage |
| Risque fréquent | Mauvais port ou firewall | Mauvaise terminaison, parité, adresse, polarité |
| Usage typique | Analyseurs récents, passerelles | Relais, compteurs et équipements hérités |
Sur un bus RS-485, le temps de polling doit être calculé avec prudence. Interroger trop souvent trop d’équipements peut créer des timeouts, des collisions ou une latence inutile. Sur Modbus TCP, le réseau est plus souple, mais il faut tout de même limiter les requêtes inutiles et superviser les erreurs applicatives.
Cartographie des équipements
Avant de configurer la collecte, il faut produire une cartographie claire des équipements. Elle évite les doublons, les registres mal interprétés et les erreurs de corrélation.
| Famille | Exemple | Protocole | Données utiles |
|---|---|---|---|
| Analyseur réseau | Schneider PM800 | Modbus TCP | Tension, courant, puissance, harmoniques |
| Relais protection | Sepam | Modbus RTU | États, alarmes, défauts, mesures électriques |
| Compteur énergie | Compteur Modbus | RTU ou TCP | Énergie active, réactive, index |
| Automate local | PLC poste | TCP | États cellule, synthèse défauts |
| Passerelle série | Convertisseur RS-485/IP | TCP vers RTU | Accès aux équipements hérités |
Cette cartographie doit aussi indiquer le site, la cellule, le transformateur, la ligne alimentée, l’adresse IP, l’adresse Modbus, le baudrate et la criticité.
Registres Modbus : du brut au physique
Un registre Modbus ne suffit pas à lui seul. Pour obtenir une mesure exploitable, il faut connaître son type, son unité, son facteur d’échelle et parfois l’ordre des mots.
Exemple de transformation :
equipement:
nom: pm800_tgbt_01
protocole: modbus_tcp
ip: 192.168.20.41
port: 502
mesures:
- nom: tension_l1_l2
registre: 3020
fonction: holding_register
type: float32
word_order: high_low
unite: V
facteur: 1
tags:
site: usine_nord
poste: hta_1
depart: ligne_a
- nom: puissance_active_totale
registre: 3054
fonction: holding_register
type: int32
facteur: 0.001
unite: kW
tags:
site: usine_nord
poste: hta_1
depart: ligne_a
L’intérêt d’une transformation embarquée est d’éviter d’envoyer vers InfluxDB des valeurs brutes incompréhensibles. La plateforme reçoit directement des grandeurs physiques cohérentes.
Diagnostic temps réel des registres
La phase la plus chronophage d’un projet Modbus est souvent l’investigation. Un registre documenté peut être décalé d’une adresse selon la convention utilisée, une valeur peut être codée sur deux mots, ou un facteur d’échelle peut être appliqué dans l’équipement.
Une interface de diagnostic doit permettre de vérifier :
-
La disponibilité de l’équipement.
-
Le temps de réponse.
-
Le code fonction utilisé.
-
Le registre demandé.
-
La valeur brute lue.
-
La valeur convertie.
-
Les erreurs Modbus retournées.
-
Les timeouts et refus de connexion.
-
La fréquence de polling réelle.
-
L’horodatage de la dernière mesure valide.
Ce diagnostic réduit le besoin d’outils externes et accélère la mise en service, surtout lorsque les équipements sont anciens ou mal documentés.
Pipeline de données vers InfluxDB
InfluxDB est adapté aux séries temporelles industrielles : mesures répétées, tags de contexte, rétention, agrégation et visualisation via Grafana. La qualité du modèle de données est déterminante.
Une mesure bien modélisée doit contenir une valeur, un horodatage et des tags utiles. Par exemple : site, poste, transformateur, départ, équipement, phase et unité.
Exemple de point InfluxDB
Une écriture InfluxDB peut représenter une mesure électrique avec ses tags industriels.
qualite_reseau,site=usine_nord,poste=hta_1,equipement=pm800_tgbt_01,phase=l1_l2 tension=401.7 1719403200000000000
qualite_reseau,site=usine_nord,poste=hta_1,equipement=pm800_tgbt_01 puissance_active_kw=842.5 1719403200000000000
qualite_reseau,site=usine_nord,poste=hta_1,equipement=pm800_tgbt_01 thd_tension_pct=2.8 1719403200000000000
Cette structure permet ensuite de filtrer par site, poste, équipement ou phase dans Grafana, sans multiplier les bases ou les dashboards.
Tableau de bord Grafana pour la qualité réseau
Un tableau de bord Grafana doit répondre aux questions des équipes terrain, pas seulement afficher des courbes. Pour un poste HTA, les vues utiles sont :
-
Vue synthèse du poste : tension, courant, puissance, fréquence, THD, alarmes.
-
Vue par départ : charge, déséquilibre, puissance active et réactive.
-
Vue qualité réseau : creux, surtensions, harmoniques, fréquence.
-
Vue protection : états Sepam, alarmes, déclenchements, défauts.
-
Vue disponibilité collecte : équipements joignables, timeouts, dernières mesures.
-
Vue corrélation production : événements électriques et arrêts de ligne.
-
Vue historique : comparaison jour, semaine, mois et période de référence.
Un dashboard efficace doit éviter l’empilement de graphiques inutiles. Les panels doivent orienter la décision : surveiller, diagnostiquer, corréler ou déclencher une intervention.
Corréler perturbations réseau et arrêts de production
La valeur du projet apparaît lorsque les données électriques expliquent des événements de production. Une ligne qui s’arrête à 14 h 03 peut être corrélée avec un creux de tension, un déséquilibre de phase, une alarme Sepam ou une hausse d’harmoniques.
Cette corrélation ne remplace pas l’analyse électrique, mais elle donne une base factuelle. Elle aide à distinguer une panne machine d’une perturbation d’alimentation ou d’un événement réseau amont.
Fréquence de collecte et priorisation
Toutes les mesures ne doivent pas être collectées à la même fréquence. Une fréquence trop élevée surcharge le bus Modbus, la gateway et la base de données. Une fréquence trop basse peut manquer un événement important.
| Donnée | Fréquence indicative | Commentaire |
|---|---|---|
| Tension et courant RMS | 1 à 10 secondes | Selon criticité et capacité équipement |
| Puissance active et réactive | 5 à 30 secondes | Utile pour suivi charge |
| Énergie cumulée | 1 à 5 minutes | Variation lente |
| THD et harmoniques | 10 à 60 secondes | À adapter au besoin qualité réseau |
| États relais | 1 à 5 secondes | Important pour alarmes |
| Événements protection | Dès disponibilité | Priorité élevée |
| Diagnostic collecte | 30 à 60 secondes | Disponibilité équipement |
Ces valeurs doivent être ajustées selon le bus, les équipements, la volumétrie InfluxDB et le niveau de détail attendu.
Gestion des timeouts et données manquantes
Dans une supervision électrique, une absence de donnée est elle-même une information. Il faut distinguer une vraie mesure nulle d’une mesure indisponible.
Bonnes pratiques :
-
Marquer explicitement les équipements en timeout.
-
Conserver l’horodatage de la dernière valeur valide.
-
Ne pas remplacer automatiquement une donnée manquante par zéro.
-
Créer des alertes sur absence de données.
-
Superviser le taux d’erreur par équipement.
-
Bufferiser localement lorsque le lien réseau est instable.
-
Rejouer les données bufferisées avec leur horodatage d’origine.
Cette rigueur évite les conclusions fausses dans Grafana, notamment sur les graphes de puissance ou d’énergie.
Sécurité et segmentation du poste HTA
Les données électriques sont sensibles. Elles révèlent la charge, les incidents, les horaires d’activité et parfois la criticité d’une ligne. La collecte doit donc être sécurisée.
Mesures recommandées :
-
Isoler le réseau du poste HTA dans une zone dédiée.
-
Limiter les flux entre la gateway et les équipements Modbus.
-
Éviter toute exposition directe des analyseurs ou relais sur Internet.
-
Chiffrer les flux sortants vers la plateforme de données.
-
Journaliser les connexions et changements de configuration.
-
Restreindre les accès Grafana par rôle.
-
Documenter les équipements, ports, protocoles et droits.
-
Prévoir une procédure de révocation des accès prestataires.
Cette approche rejoint les principes de segmentation OT/IT et de moindre privilège détaillés dans les guides de connectivité industrielle et d’accès sécurisé via gateway Eziwan.
Templates constructeurs
Les templates accélèrent fortement la mise en service. Ils décrivent les registres, types, facteurs d’échelle, unités et noms de mesures pour des équipements connus.
Un template utile doit contenir :
-
Le modèle exact ou la famille d’équipement.
-
La version de documentation utilisée.
-
Les registres lus.
-
Les types de données.
-
Les facteurs d’échelle.
-
Les unités.
-
Les tags recommandés.
-
Les fréquences de collecte par groupe de mesures.
-
Les limites connues.
-
Une procédure de validation terrain.
Les templates ne dispensent pas d’un test réel. Deux équipements d’une même famille peuvent avoir des options ou versions différentes.
Exemple de configuration multi-équipements
poste:
nom: hta_usine_nord
timezone: Europe/Paris
collecte:
modbus_tcp:
- nom: pm800_depart_ligne_a
ip: 192.168.30.11
port: 502
template: schneider_pm800_qualite_reseau
intervalle: 5s
tags:
poste: hta_1
depart: ligne_a
- nom: pm800_depart_ligne_b
ip: 192.168.30.12
port: 502
template: schneider_pm800_qualite_reseau
intervalle: 5s
tags:
poste: hta_1
depart: ligne_b
modbus_rtu:
port: /dev/rs485-1
baudrate: 19200
parite: paire
stop_bits: 1
equipements:
- nom: sepam_cellule_arrivee
adresse: 1
template: schneider_sepam_etats_protection
intervalle: 2s
- nom: sepam_depart_moteurs
adresse: 2
template: schneider_sepam_etats_protection
intervalle: 2s
sortie:
influxdb:
bucket: qualite_reseau
measurement: poste_hta
buffer_local: true
Ce type de configuration rend le déploiement reproductible. Il facilite aussi l’audit, car chaque point collecté est relié à un équipement et à un template.
Alertes utiles
Les alertes doivent être actionnables. Une alerte trop vague génère du bruit ; une alerte contextualisée aide à diagnostiquer.
Exemples d’alertes pertinentes :
-
Perte de communication avec un analyseur PM800.
-
Perte de communication avec un relais Sepam.
-
Creux de tension au-delà du seuil défini.
-
Déséquilibre de courant entre phases.
-
THD tension ou courant supérieur au seuil de surveillance.
-
Déclenchement ou alarme protection.
-
Absence de données sur un poste critique.
-
Augmentation du taux de timeout Modbus.
-
Puissance réactive élevée sur une période prolongée.
-
Écart de charge inhabituel entre départs.
Les seuils doivent être validés par les équipes électriques. Il ne faut pas transformer la supervision en générateur d’alertes non qualifiées.
Checklist avant mise en production
| Contrôle | Question | Priorité |
|---|---|---|
| Inventaire | Tous les analyseurs et relais sont-ils identifiés ? | Haute |
| Documentation | Les tables Modbus sont-elles validées ? | Haute |
| Interfaces | TCP, RTU, baudrate et adresses sont-ils confirmés ? | Haute |
| Templates | Les conversions et unités sont-elles testées ? | Haute |
| Horodatage | La timezone et la synchronisation temps sont-elles définies ? | Haute |
| InfluxDB | Les tags et mesures sont-ils cohérents ? | Haute |
| Grafana | Les dashboards répondent-ils aux besoins métier ? | Haute |
| Alertes | Les seuils sont-ils validés par l’équipe électrique ? | Haute |
| Sécurité | Les flux sont-ils segmentés et chiffrés ? | Haute |
| Buffer | Les coupures réseau temporaires sont-elles gérées ? | Moyenne |
Cette checklist évite les erreurs classiques : registre mal converti, unité incohérente, mesure non horodatée ou dashboard impossible à exploiter.
Erreurs fréquentes à éviter
Collecter trop de registres dès le départ
Il est tentant de tout collecter. Mais une collecte excessive surcharge les bus, complique les dashboards et augmente le stockage. Il vaut mieux commencer par les mesures utiles, puis étendre selon les besoins.
Ignorer les facteurs d’échelle
Une valeur brute peut représenter des volts, kilovolts, ampères, dixièmes ou millièmes d’unité. Sans facteur d’échelle, les courbes Grafana peuvent être fausses tout en semblant cohérentes.
Confondre donnée nulle et donnée absente
Une puissance à zéro et une mesure indisponible n’ont pas le même sens. Les timeouts doivent être traités explicitement.
Négliger la qualité du bus RS-485
Un bus mal terminé, trop long, mal polarisé ou perturbé peut créer des erreurs intermittentes difficiles à diagnostiquer. Le diagnostic de communication est aussi important que la configuration logicielle.
Construire Grafana sans logique métier
Un bon dashboard doit aider à décider. Les courbes doivent être organisées par poste, départ, équipement et événement, avec des seuils lisibles et des filtres utiles.
Indicateurs de pilotage
Pour exploiter la supervision dans la durée, il faut suivre à la fois les données électriques et la qualité de collecte.
| Indicateur | Utilité |
|---|---|
| Tension moyenne et min/max | Détecter creux, surtensions et instabilités |
| Courant par phase | Identifier déséquilibre et surcharge |
| Puissance active | Suivre charge et consommation |
| Puissance réactive | Surveiller compensation et facteur de puissance |
| THD tension et courant | Analyser qualité réseau |
| Alarmes Sepam | Corréler défauts et événements |
| Disponibilité équipement | Vérifier la collecte |
| Taux de timeout Modbus | Détecter un problème bus ou réseau |
| Dernière mesure valide | Identifier les équipements silencieux |
| Nombre d’événements corrélés | Relier réseau électrique et production |
Ces indicateurs permettent une exploitation progressive : supervision, diagnostic, analyse qualité, puis optimisation énergétique.
Comment Eziwan simplifie la supervision HTA
| Besoin | Réponse Eziwan | Bénéfice |
|---|---|---|
| Collecter Modbus TCP | Polling analyseurs réseau | Mesures électriques centralisées |
| Collecter Modbus RTU | Interface RS-485 | Intégration relais et équipements hérités |
| Comprendre les registres | Diagnostic temps réel | Mise en service plus rapide |
| Normaliser les données | Transformations embarquées | Valeurs physiques exploitables |
| Accélérer les projets | Templates constructeurs | Moins de configuration manuelle |
| Historiser | Publication InfluxDB | Séries temporelles prêtes pour Grafana |
| Superviser | Logs et alertes | Diagnostic plus simple |
| Sécuriser | Tunnels et segmentation | Pas d’exposition directe des équipements |
Eziwan transforme une collecte Modbus dispersée en pipeline industriel exploitable, compatible avec les besoins de qualité réseau, maintenance et production.
Conclusion
La supervision des analyseurs de réseau Modbus dans un poste de transformation HTA permet de passer d’une vision ponctuelle à une analyse continue de la qualité électrique. En collectant les PM800, Sepam et autres équipements Modbus, puis en historisant les mesures dans InfluxDB et Grafana, les équipes peuvent corréler les perturbations réseau avec les arrêts de production, diagnostiquer plus vite et mieux prioriser les actions.
Eziwan apporte les briques nécessaires : collecte Modbus TCP et RTU, diagnostic des registres, templates constructeurs, transformations embarquées, buffer local, publication InfluxDB, alertes et sécurisation des flux. Pour les sites industriels, cette approche rend la supervision HTA plus fiable, plus lisible et directement exploitable par les équipes terrain.
Pour aller plus loin
- Modbus RTU vers cloud — connectez vos équipements RS-485 Modbus RTU au cloud sans modifier votre cablage
- Modbus TCP vers cloud — remontez les données Modbus TCP de vos automates vers une plateforme cloud
- RS-485 Modbus 4G — solution clé en main pour transporter du Modbus RTU sur réseau 4G LTE
- Protocoles industriels — tour d’horizon des protocoles OT : Modbus, OPC UA, MQTT, Profibus et BACnet
- Gateway IoT industrielle — choisir la bonne passerelle pour convertir et remonter vos données terrain