Supposons que nous lisions la valeur brute suivante dans l’un des registres Modbus d’un compteur de puissance électrique industriel :

registre : 40001
valeur :   23871

En avons-nous fini avec la numérisation industrielle ?

En réalité, nous n’avons même pas vraiment commencé.

23871 n’est rien de plus qu’une suite de chiffres. Pour pouvoir fonder une décision sur ce nombre, il faut savoir ce qu’il signifie, d’où il vient, quand il était valide, quel est son degré de fiabilité, à quoi il se rattache, par rapport à quoi il doit être jugé anormal et ce qui doit se passer si un problème existe réellement.

Suivons le parcours complet de la donnée.

1. Lire correctement le registre

La documentation Modbus doit permettre de déterminer :

  • le code fonction utilisé ;
  • l’adresse réelle du registre ;
  • le type de données ;
  • l’interprétation signée ou non signée ;
  • l’ordre des octets et des mots ;
  • le facteur d’échelle ;
  • l’unité de mesure ;
  • les indicateurs de validité et d’erreur.

La notation 40001 elle-même peut prêter à confusion. Certaines documentations utilisent une numérotation « humaine », d’autres une adresse de protocole commençant à zéro. Un seul décalage d’adresse peut conduire à lire non pas la puissance, mais un registre voisin.

Supposons que, selon la documentation, la valeur soit un entier non signé de 16 bits, avec une échelle de 1 W. On obtient alors :

23871 → 23 871 W → 23,871 kW

La valeur a désormais une signification physique. Mais elle n’a pas encore de contexte métier.

2. Identité de l’équipement et horodatage

La donnée doit être rattachée à un compteur et à un point de mesure précis. L’adresse IP ou l’identifiant d’unité Modbus (unit ID) ne suffisent pas, car ils peuvent changer ou se répéter sur plusieurs sites.

Il faut un identifiant stable de l’équipement et du point de mesure, ainsi qu’un horodatage fiable. Le système doit aussi distinguer :

  • le moment où la mesure a été effectuée ;
  • le moment où la passerelle l’a lue ;
  • le moment où elle est arrivée dans le système central.

Après une coupure réseau, une donnée mise en mémoire tampon peut arriver plus tard. Si seule l’heure de réception est enregistrée, l’historique se décale et les règles risquent de l’évaluer de manière erronée.

3. Qualité et validité des données

Tout nombre lu n’est pas une mesure réelle. Il peut s’agir de la dernière valeur connue après une erreur de communication, d’un dépassement de capacité, d’un état pendant le démarrage de l’équipement ou d’un code d’erreur documenté.

Un indicateur de qualité peut donc accompagner la donnée :

quality: good | uncertain | bad
source: live | buffered | estimated

Une règle métier ne peut pas traiter de la même façon une mesure en temps réel vérifiée et une valeur estimée et incertaine. C’est particulièrement important dans un processus de facturation ou de régulation.

4. Message normalisé

La passerelle convertit la valeur de terrain dans un modèle de données unifié. Par exemple :

{
  "site_id": "site-etyek-01",
  "asset_id": "compressor-03",
  "measurement": "active_power",
  "value": 23.871,
  "unit": "kW",
  "measured_at": "2026-09-14T06:32:10Z",
  "quality": "good"
}

À partir de là, le traitement central n’a plus besoin de connaître la table de registres propre à chaque fabricant de compteur. Les différences de terrain sont prises en charge par la passerelle et le profil d’équipement, tandis que la plateforme travaille avec des notions unifiées.

5. Transmission sécurisée et mise en mémoire tampon

Le message parvient au système de traitement par une connexion contrôlée. Lors de la conception de la communication, il faut définir l’authentification, le chiffrement, les autorisations, la structure des topics ou des points de terminaison, la redistribution des messages et la gestion des erreurs.

Si la connexion est interrompue, la passerelle peut stocker la donnée localement, puis la transmettre plus tard avec l’heure de mesure d’origine. Le système central doit savoir gérer les messages qui arrivent en retard, voire plusieurs fois.

Ce n’est pas une fonction spectaculaire. Mais sans elle, la courbe présente des trous, la facturation devient contestable et le modèle apprend sur des données erronées.

6. Stockage et contexte métier

La mesure de 23,871 kW est enregistrée dans une base de séries temporelles. En parallèle, les données de référence de la plateforme indiquent, pour compressor-03 :

  • sur quel site il se trouve ;
  • à quelle ligne de production il appartient ;
  • à quel centre de coûts il est imputé ;
  • qui est responsable de son exploitation ;
  • quelle est sa puissance nominale ;
  • quand il a été entretenu pour la dernière fois ;
  • quel contrat ou quel projet le concerne.

C’est à ce moment que le point de mesure devient partie intégrante du fonctionnement de l’entreprise.

7. Interpréter le nombre

Supposons que le compresseur tourne actuellement à vide. D’après les données historiques, une puissance de 12 à 15 kW est habituelle dans cet état. Les 23,871 kW ne sont donc pas intéressants parce qu’il s’agirait d’un grand nombre en soi, mais parce qu’ils représentent un écart important par rapport à cet état de fonctionnement.

La règle ou le modèle de détection d’anomalies peut tenir compte :

  • de l’état de fonctionnement ;
  • de la référence (baseline) de la période précédente ;
  • de la température extérieure ;
  • de la valeur de pression ;
  • de la durée de l’écart ;
  • de l’indicateur de qualité du capteur.

Par exemple, un événement n’est créé que si la puissance à vide reste supérieure à 20 kW pendant au moins 20 minutes. Ainsi, un pic ponctuel ne déclenche pas d’alarme inutile.

8. De l’événement à la tâche

Le système crée l’événement :

Type :        consommation d’énergie élevée à vide
Équipement :  compresseur n° 3
Priorité :    moyenne
Responsable : maintenance du site
Échéance :    24 heures
Preuves :     tendance, état de fonctionnement, mesures associées

Un ordre de travail peut être généré automatiquement à partir de l’événement. Sur place, le technicien de maintenance voit les données de l’équipement, son historique et la courbe qui étaye l’alerte. Lors de l’intervention, il consigne qu’en raison d’une vanne qui fermait mal, l’installation fonctionnait inutilement même hors charge.

9. Intervention et vérification

Après la réparation de la vanne, le système ne se contente pas de clôturer la tâche. Il compare la nouvelle consommation à vide avec l’état antérieur.

Supposons que la valeur redescende à 13,5 kW. L’écart est d’environ 10,4 kW chaque fois que la machine tourne à vide.

Avec 120 heures de fonctionnement de ce type par mois, l’économie estimée est la suivante :

10,4 kW × 120 h = 1 248 kWh/mois

En appliquant le coût interne ou d’achat actuel de l’énergie, on peut en déduire un impact financier. Le système documente ainsi non seulement que « nous avons réparé la vanne », mais aussi le résultat énergétique et financier obtenu grâce à l’intervention.

10. Décision de la direction

Un cas isolé ne fait pas forcément une stratégie. Mais si la même plateforme gère des événements similaires sur plusieurs sites et équipements, la direction peut obtenir des réponses à des questions telles que :

  • quel type d’équipement cause le plus de pertes ;
  • où la surveillance instrumentée de l’état est la plus rapidement rentabilisée ;
  • quel site réagit le plus vite ;
  • combien d’économies vérifiées les interventions ont permis de réaliser ;
  • quels équipements il convient de rénover ou de remplacer ;
  • quel projet pilote mérite d’être étendu à l’ensemble de l’entreprise.

Le dirigeant ne voit plus le registre 40001. Il voit ce qu’un problème technique mesurable a coûté, comment il a été traité, en combien de temps il a été résolu et quel résultat a été obtenu.

Voilà le véritable sens de l’intégration IT/OT

L’ensemble de l’environnement technologique OrigSmart relie précisément ce parcours. Si nécessaire, nous partons de la couche de mesure et de communication de terrain. La passerelle interprète et transmet la donnée. La plateforme la relie à l’équipement, au lieu, au responsable et au processus métier. L’événement devient une action exécutable, et l’action un résultat vérifiable.

C’est bien plus qu’un pilote Modbus, une base de données ou un tableau de bord. Ce sont tous des composants nécessaires, mais à eux seuls ils ne constituent pas un système opérationnel.

OrigSmart crée de la valeur en menant un simple nombre brut issu du monde physique à travers l’interprétation, la responsabilité et l’intervention, jusqu’à la décision de la direction.

Parlons de votre projet

Sources