1.Alarme persistante : causes typiques et actions

Cet article explique pourquoi une alarme peut rester active ou réapparaître dans Sensinov, et quelles actions mener pour traiter la cause réelle plutôt que le symptôme.

Principe et contexte fonctionnel (logique métier)

Dans une logique d’exploitation GTB, une alarme n’est pas un événement isolé mais le signal d’un écart entre un fonctionnement attendu et un état réel.
Une alarme persistante indique que la condition de déclenchement est toujours présente ou qu’elle se reproduit régulièrement.

Le traitement efficace d’une alarme repose donc sur :

• l’identification de la cause racine,
• la vérification du retour à un état nominal,
• et la prévention des récidives.

Acquitter une alarme sans corriger sa cause ne résout pas le problème d’exploitation sous-jacent.

2.Fonctionnement et usage principal

Lorsqu’une alarme reste active ou revient fréquemment après acquittement, plusieurs catégories de causes sont possibles.

3.Causes typiques d’alarme persistante

Valeur réellement hors seuil

La condition physique à l’origine de l’alarme est toujours présente.

Exemples :

• Température réellement trop élevée ou trop basse.
• Consommation anormalement élevée.
• Équipement à l’arrêt ou en défaut réel.

Action recommandée :

• Vérifier la valeur mesurée dans le temps.
• Intervenir sur l’équipement ou la régulation concernée.
• Confirmer le retour à une valeur conforme avant acquittement.
• Objectif : montrer que la valeur est toujours en anomalie.
• Doit montrer : courbe ou valeur instantanée avec seuil visible.
• À éviter : zoom excessif ou absence de référence de seuil.

Seuil ou condition mal configuré

L’alarme se déclenche sur un seuil inadapté au contexte réel.

Exemples :

• Seuil trop strict par rapport au fonctionnement normal.
• Non-prise en compte des périodes d’arrêt ou d’inoccupation.
• Condition logique incorrecte (ET / OU).

Action recommandée :

• Vérifier la cohérence du seuil avec l’usage réel.
• Adapter la condition d’alarme si nécessaire.
• Tester le comportement après modification.
• Objectif : permettre la compréhension de la logique de déclenchement.
• Doit montrer : paramètres de seuil ou condition d’alarme.
• À éviter : autres règles non liées à l’alarme analysée.

Problème de communication ou de donnée

L’alarme est liée à une absence, un retard ou une incohérence de données.

Exemples :

• Capteur non communicant.
• Valeur figée ou non rafraîchie.
• Donnée incohérente par rapport à l’état réel.

Action recommandée :

• Vérifier l’état de communication de l’équipement.
• Identifier une perte de données ou un défaut réseau.
• Corriger la source avant d’acquitter l’alarme.
• Objectif : identifier un problème de communication.
• Doit montrer : timestamp de dernière donnée ou état de communication.
• À éviter : données historiques non pertinentes.

Alarme dépendante d’un autre défaut

L’alarme est la conséquence indirecte d’un problème amont.

Exemples :

• Alarme de température causée par un équipement à l’arrêt.
• Alarme de consommation liée à un scénario incorrect.
• Alarme aval déclenchée par une alarme non traitée en amont.

Action recommandée :

• Identifier les alarmes corrélées.
• Traiter la cause première avant les conséquences.
• Vérifier la disparition progressive des alarmes liées.
• Objectif : visualiser plusieurs alarmes liées entre elles.
• Doit montrer : liste d’alarmes actives sur un même périmètre.
• À éviter : alarmes sans lien fonctionnel.

4.Cas d’usage concrets terrain

• Une alarme de température revient chaque matin car la plage horaire ne correspond pas à l’occupation réelle.
• Une alarme de consommation persiste car le seuil est basé sur une ancienne configuration du site.
• Une alarme de défaut apparaît en continu à cause d’un capteur non communicant depuis plusieurs jours.

Points de vigilance et erreurs fréquentes ⚠️

• Acquitter une alarme sans vérifier la condition réelle.
• Modifier un seuil sans comprendre l’impact métier.
• Ignorer les alarmes corrélées.
• Traiter l’alarme sans analyser la donnée dans le temps.

À retenir

• Une alarme persistante signale un problème non résolu.
• L’acquittement ne remplace jamais l’analyse de la cause.
• Les causes peuvent être physiques, fonctionnelles ou liées à la donnée.
• Une analyse globale évite la répétition des alarmes et améliore l’exploitation.