Gestion des alarmes multi-protocoles en supervision industrielle : filtrage, hystérésis, temporisations et réduction des fausses alertes

Supervision industrielle : fiabiliser les alarmes

Pourquoi le multi-protocoles complexifie l'alarme

Dans une architecture de supervision industrielle moderne, une même application SCADA consolide des données issues d'automates, RTU, postes électriques, capteurs IIoT et systèmes IT/OT, via des protocoles hétérogènes (ex. Modbus TCP, OPC UA, IEC 60870-5-104, DNP3, MQTT, SNMP). Cette convergence est un levier d'optimisation, mais elle introduit aussi des modes de dégradation qui impactent directement la pertinence des alarmes.

Quand l'alarme est dérivée trop directement de la valeur brute, l'exploitation subit rapidement une surcharge d'alarmes (alarm flood), une hausse des acquittements « réflexes », et un risque accru de non-détection (un événement critique noyé dans le bruit). L'objectif est donc de construire une chaîne d'alarme cohérente, depuis l'acquisition jusqu'à la notification, afin de réduire les fausses alertes sans affaiblir la sécurité ni la capacité de diagnostic.

Alarmes multi-protocoles : sources d'erreurs

Latence, cadence et gestion du temps

Les cadences d'acquisition varient fortement : un automate peut publier à 100 ms, un RTU à 5–10 s, un équipement de télégestion à la minute, et un broker MQTT « à l'événement ». Sans stratégie explicite de timestamp et d'âge de la donnée, un dépassement bref peut être surestimé (effet de suréchantillonnage) ou au contraire invisibilisé (effet de sous-échantillonnage).

Qualité de donnée : implicite vs native

OPC UA transporte nativement un StatusCode (qualité et détail d'état) permettant de qualifier la validité d'une valeur (familles Good / Uncertain / Bad). La sémantique est décrite dans les spécifications OPC UA, par exemple Bad_NoCommunication lorsque la communication avec la source est définie mais non établie, sans dernière valeur exploitable. Voir : OPC UA Core – StatusCode.

À l'inverse, Modbus TCP ne transporte pas intrinsèquement un indicateur de qualité : la supervision doit déduire la qualité (timeouts, erreurs de lecture, watchdog applicatif, incohérences de trames, rupture de liaison). Si cette qualité n'est pas modélisée, une alarme process (ex. HH pression) peut se déclencher sur une valeur obsolète ou figée.

Oscillations autour des seuils (chattering)

Les capteurs analogiques bruités (niveau, pression, débit, courant moteur) franchissent souvent un seuil dans un sens puis dans l'autre. Un déclenchement immédiat « seuil ? alarme » génère des alarmes yoyo (chatter), coûteuses (acquittements répétés) et destructrices de confiance.

Cascades d'événements et alarm flood

Lors d'un incident (perte de communication, coupure d'alimentation, arrêt d'un skid), un opérateur peut recevoir des dizaines d'alarmes corrélées. Sans priorisation, regroupement et règles de masquage conditionnel, la cause racine devient difficile à identifier.

Référentiels : appliquer une logique de cycle de vie

Dans l'industrie de process, la gestion des alarmes est structurée par le cycle de vie décrit par ANSI/ISA-18.2 et par IEC 62682 (philosophie d'alarme, rationalisation, mise en uvre, exploitation, suivi et amélioration continue). Sur des domaines « hybrides » (bâtiments, eau, énergie distribuée), ces pratiques existent mais restent parfois incomplètes : seuils peu documentés, temporisations empiriques, priorités incohérentes, traçabilité inconstante, KPI absents.

Réduire les fausses alertes : méthode terrain

1) Normaliser valeur, unités, temps et qualité

Avant d'appliquer une logique d'alarme fiable, il faut stabiliser le socle de données :

• Unités et échelles : expliciter les conversions (ex. mbar bar, ppm mg/Nm3) et les documenter dans le modèle de données.
• Temps : conserver le timestamp source quand il existe ; sinon, calculer l'âge de la donnée (time since last update) et définir des seuils d'acceptation (par type de mesure et criticité).
• Qualité unifiée : construire une qualité « supervision » homogène, exploitable quel que soit le protocole. En OPC UA, s'appuyer sur le StatusCode (Good/Uncertain/Bad et sous-états). En Modbus/SNMP/MQTT, produire une qualité dérivée (timeout, absence de rafraîchissement, incohérence, erreur de polling).

Opérationnellement, une classification simple et efficace est :

• Good : acquisition valide et récente.
• Uncertain : valeur reçue mais conditions dégradées (retard/jitter, précision douteuse, état indéterminé).
• Bad : acquisition invalide (erreur de communication, source indisponible, valeur explicitement invalide).
• Stale : valeur non mise à jour au-delà d'un délai maximal (détection de figement / gel).

Cette qualité sert à inhiber les alarmes process sur donnée non fiable (ex. éviter un HH sur une valeur Bad) et à déclencher des alarmes diagnostic dédiées (communication, capteur figé, retard anormal), plus pertinentes pour maintenance et astreinte.

2) Stabiliser le déclenchement : filtres, hystérésis, temporisations

La stabilisation vise à absorber le bruit de mesure et les micro-événements sans masquer un phénomène réel.

Filtrage numérique
Selon la dynamique du procédé, on peut utiliser une moyenne glissante, une médiane (utile contre les spikes), un passe-bas 1er ordre ou un lissage exponentiel. Le dimensionnement se fait par rapport :

• à la période d'échantillonnage et au jitter réseau,
• à la constante de temps procédé,
• au niveau de risque (exploitation vs sécurité).

Hystérésis (deadband)
L'hystérésis fixe des seuils d'entrée/sortie distincts (ex. HH = 10,0 bar ; retour = 9,7 bar). Elle supprime les basculements répétés autour du seuil. Bonne pratique : dimensionner le deadband au-dessus de l'addition résolution capteur + bruit + quantification induite par la chaîne d'acquisition.

Temporisations (on-delay / off-delay)
Les temporisations valident la persistance :

• On-delay : la condition doit être vraie pendant X secondes avant déclenchement.
• Off-delay : la condition doit être fausse pendant Y secondes avant réarmement.

En multi-protocoles, ces temporisations absorbent efficacement les micro-coupures VPN/4G, les retransmissions, ou les rafales de reconnexion. Point de vigilance : sur les fonctions de sécurité, une temporisation excessive peut être inacceptable (ces alarmes doivent rester liées à des sources et chaînes adaptées).

3) Contextualiser : inhibition, regroupement, traçabilité

Masquage conditionnel (inhibition / shelving)
On réduit les alarmes « conséquences » en les inhibant lorsque la cause racine est identifiée. Exemples :

• inhiber des alarmes analogiques d'une station lorsque l'alimentation est absente,
• inhiber des alarmes process si la qualité est Bad ou Stale,
• inhiber des alarmes aval si une vanne amont est confirmée fermée.

Corrélation et regroupement
Le regroupement (par site, atelier, skid, équipement) remplace avantageusement une rafale de N alarmes par un événement synthétique exploitable. Cela nécessite une modélisation hiérarchique cohérente (site ? zone ? équipement ? point de mesure), et une politique de priorités alignée avec l'exploitation.

Acquittement et traçabilité
Pour rester auditables, les alarmes doivent intégrer : acquittement horodaté, identification opérateur, commentaires, distinction acquittement local/central et suivi des standing alarms (alarmes actives non acquittées). En sites à risques majeurs, cette rigueur s'inscrit dans une logique globale de maîtrise des risques (références européennes type directive Seveso III 2012/18/UE, selon le périmètre réglementaire du site).

Mettre en place une amélioration continue

KPI d'alarmes et revues périodiques

Une stratégie d'alarme ne se fige pas à la mise en service : elle se pilote. Dans l'esprit des cycles de vie ISA-18.2 et IEC 62682, on met en place :

• KPI : alarmes/heure/opérateur, top N, standing alarms, épisodes de flood, taux d'acquittement, récurrence par tag.
• Revues : ajustement deadband/on-delay/off-delay sur des périodes représentatives (ex. 30/90 jours).
• Tests de scénarios : perte de com, redémarrage RTU, basculement réseau, reprise après coupure.
• Documentation : mise à jour contrôlée de la philosophie d'alarme.

Analyse : gains, limites et points de vigilance

Compromis entre réactivité et robustesse

Chaque couche de stabilisation (filtrage, on-delay) introduit de l'inertie. Pour les alarmes à enjeu sécurité ou intégrité d'équipement, il faut limiter le filtrage et privilégier des signaux et architectures adaptés (ex. détection dédiée au contrôle-commande, séparation exploitation/sécurité). Une philosophie d'alarme mature distingue clairement :

• alarmes de sécurité : réaction rapide, chaîne de mesure et logique appropriées, peu filtrées ;
• alarmes d'exploitation : stabilisées et contextualisées ;
• alarmes de maintenance/diagnostic : qualité de données, communication, dérive capteur, incohérences.

Qualité construite : attention aux valeurs figées

Là où OPC UA fournit une base solide via les StatusCodes (OPC UA Core – StatusCode), Modbus et certains équipements terrain exigent une qualité « reconstruite ». La détection de figement doit combiner :

• âge maximum admissible,
• variation minimale attendue selon le contexte,
• cohérence croisée (ex. débit et état pompe/vanne).

Corrélation : éviter le masquage excessif

Des règles d'inhibition trop agressives peuvent masquer un symptôme utile. Bonnes pratiques :

• préférer le regroupement à la suppression pure ;
• conserver un historique des alarmes masquées (audit) ;
• distinguer inhibition automatique et shelving manuel, temporaire et tracé.

Perspectives : compléter par des approches avancées

Au-delà des mécanismes classiques (seuil, hystérésis, temporisations), des approches complémentaires peuvent être envisagées selon la maturité des données : détection d'anomalies, seuils adaptatifs par régime de fonctionnement, corrélation multi-capteurs et scoring de confiance. L'enjeu est de rester explicable et compatible avec les exigences opérationnelles.

Retours d'expérience et mise en oeuvre SCADA

Structurer le modèle plutôt que chercher un "réglage magique"

Sur des projets multisites (eau, énergie, bâtiments, industrie), la réduction durable des fausses alertes dépend surtout de la cohérence du modèle : hiérarchie d'équipements, états de qualité homogènes, règles d'inhibition documentées, et KPI suivis. C'est typiquement un travail d'interface entre terrain (capteurs, automates, RTU, télécoms) et supervision.

Mettre en pratique avec un outil adapté

Superviser et gérer les alarmes en multi-protocoles

Pour concrétiser ces principes dans un environnement SCADA, la plateforme de supervision connectée PcVue permet d'intégrer des environnements multi-protocoles et d'implémenter des stratégies d'alarmes structurées (temporisations, priorisation, exploitation, historisation et traçabilité) au sein d'architectures industrielles distribuées. L'éditeur ARC INFORMATIQUE accompagne également la définition d'une philosophie d'alarme et le déploiement de pratiques de suivi adaptées aux contraintes de terrain.

Conclusion

Des alarmes utiles, moins nombreuses, mieux actionnables

En supervision industrielle multi-protocoles, la fiabilité des alarmes repose sur une chaîne cohérente : normalisation (unités, temps), qualification (Good/Uncertain/Bad et détection de données stale), stabilisation (filtrage, hystérésis, on-delay/off-delay), contextualisation (inhibition prudente, corrélation, regroupement) et pilotage par KPI dans une logique de cycle de vie inspirée de ISA-18.2 et IEC 62682. Le résultat attendu est concret : moins de bruit, meilleure réactivité, diagnostic accéléré et exploitation 24/7 plus robuste.

Pour industrialiser cette démarche sur vos sites et vos protocoles, contactez ARC INFORMATIQUE et demandez un devis pour la mise en oeuvre d'une stratégie de gestion des alarmes et de supervision avec PcVue.