Une règle de réponse à la demande démarre un prérefroidissement de groupe frigorifique à 16 h et l’arrête à 16 h 30. Le Gateway redémarre à 16 h 10. Si l’ordre d’arrêt n’existait qu’en mémoire, le groupe continue à fonctionner jusqu’à ce que quelqu’un le remarque. Placer la commande sur un Gateway local retire Internet de cette chaîne, mais les capteurs, le réseau du site, l’équipement et les redémarrages du Gateway restent concernés. Une matrice de défaillance énumère chacune de ces pannes avec la réponse attendue ; chaque ligne devient un essai.
Tracer la chaîne d’autorité
Dessinez le chemin de la demande jusqu’à l’équipement. Une chaîne courante comprend la plateforme de l’agrégateur, l’automatisation du Gateway, le BMS, le contrôleur propre à l’équipement et un commutateur manuel local. Pour chaque couche, indiquez si elle peut demander un changement, si elle peut le bloquer et ce qu’elle fait lorsqu’elle perd le contact avec la couche supérieure.
Attribuez un seul propriétaire à chaque point inscriptible à un instant donné. Si une requête de réponse à la demande, un programme BMS et un opérateur peuvent tous écrire la même consigne, consignez leur ordre de priorité. Un ordre courant est le suivant : le commutateur local prime sur tout ; une limite de fonctionnement du BMS prime sur la requête de réponse à la demande, qui prime sur le programme normal. BACnet impose ce type d’ordre au moyen du tableau de priorités à 16 niveaux des objets commandables. Modbus n’a pas d’équivalent : la dernière écriture l’emporte et aucun des deux émetteurs n’en est informé. La comparaison BACnet et Modbus et le guide du tableau de priorités expliquent ces mécanismes.
Placez chaque fonction dans la couche qui reste active si les couches supérieures tombent en panne. Le programme d’un événement de réponse à la demande peut résider sur le Gateway. Une limite de puissance appelée ou une température minimale d’alimentation appartient au BMS ou au variateur : elle reste alors active lorsque le Gateway est éteint. La protection relève du relais, des réglages de déclenchement du variateur ou d’un contrôleur de sécurité.
Décidez ensuite du comportement de l’équipement si le Gateway reste éteint. Avec une sortie relais, câblez la charge au contact dont la position hors tension donne l’état souhaité. Avec une écriture Modbus ou BACnet, l’équipement doit posséder son propre temporisateur de perte de communication. Les variateurs de la famille ABB ACS580, par exemple, peuvent ne rien faire, se mettre en défaut, conserver la dernière vitesse ou adopter une vitesse sûre prédéfinie lorsque les messages du bus de terrain cessent plus longtemps que le délai fixé. Réglez ce délai au-delà de la plus longue interruption normale entre les écritures du Gateway, sinon le variateur se mettra en défaut en fonctionnement normal. Sur l’interface Modbus intégrée du variateur, vérifiez aussi quels messages réinitialisent le temporisateur. Si tout message suffit, un Gateway qui continue d’interroger alors que sa règle de commande s’est arrêtée maintient le variateur satisfait. Si l’équipement ne possède pas de temporisateur, le Gateway peut incrémenter un registre de vie à chaque cycle et le BMS prendre le relais lorsque sa valeur cesse de changer.
La matrice de défaillance
Rédigez la réponse attendue pour chaque ligne avant l’essai. La bonne réponse dépend de la charge. Supposons que la règle du Gateway abaisse la consigne de température d’eau sortant d’un groupe frigorifique. Si elle maintient cette consigne à partir d’une température d’alimentation périmée, seule la protection antigel propre au groupe reste active. Le maintien du dernier état d’un circuit d’éclairage ne coûte généralement que de l’énergie, sauf si ce circuit dessert un espace occupé qui ne doit pas rester dans l’obscurité.
Les colonnes « Responsable » et « Délai » ci-dessous donnent des valeurs d’exemple pour ce groupe frigorifique, avec un rapport toutes les 60 s et une évaluation de la règle toutes les 60 s. Remplacez-les par les valeurs de votre site.
| Situation | Détectée par | Réponse | Responsable | Délai | Retour à la normale |
|---|---|---|---|---|---|
| Liaison avec la plateforme perdue | Aucun échange réussi pendant 3 intervalles de vie (180 s à 60 s) | Les règles locales continuent. Les événements déjà commencés vont jusqu’à leur fin enregistrée. Aucun nouveau démarrage distant | Ingénieur du site | Évaluation suivante | 3 échanges corrects consécutifs |
| Mesure utilisée par une règle devenue périmée | Âge du point supérieur à 3 intervalles de rapport, ou indicateur de mauvaise qualité | Bloquer les nouveaux démarrages qui en dépendent. Les commandes de fin déjà dues restent exécutées | Ingénieur du site | Évaluation suivante | 2 lectures fraîches consécutives |
| Délai d’une commande dépassé | Aucune réponse pendant le délai du protocole | Traiter l’état comme inconnu. Le relire avant de réessayer. Ne renvoyer que la même valeur absolue | Intégrateur de contrôle | Relecture sous 1 cycle d’interrogation | La relecture montre l’état demandé |
| Gateway redémarré pendant un cycle | État du cycle enregistré au démarrage | Exécuter les commandes de fin dues. Retenir pour examen celles dont la fenêtre de reprise a expiré | Ingénieur du site | Commande de fin jusqu’à 5 min après son échéance | État final confirmé par le retour de l’appareil |
| Gateway durablement éteint | Temporisateur de perte de communication de l’équipement ou contrôle du registre de vie par le BMS | L’équipement prend son état de repli choisi | Fournisseur de l’équipement | Délai de perte de communication | Le Gateway écrit de nouveau, et tout défaut du variateur est réarmé |
| Verrouillage de l’équipement refusant une action | Mode, limite ou état du temporisateur fourni par l’équipement | Afficher le blocage et sa source. Ne pas réessayer contre lui | Fournisseur de l’équipement | Évaluation suivante | Verrouillage levé à partir du cycle suivant |
| Second système écrivant le même point | La relecture diffère de la dernière valeur écrite | Arrêter les écritures. Signaler le conflit | Intégrateur de contrôle | Interrogation suivante | Un seul propriétaire convenu pour le point |
| Configuration modifiée pendant un cycle | Version de la configuration | La version qui a commencé le cycle le termine aussi | Responsable de la modification de la règle | Sans échéance temporelle | Cycle terminé |
| Synchronisation temporelle perdue ou saut d’horloge | État de synchronisation et amplitude du saut | Suspendre les démarrages horaires tant que le décalage dépasse la moitié de l’intervalle d’évaluation (30 s ici) | Ingénieur du site | Évaluation suivante | Synchronisation rétablie |
| Changement d’heure d’été | Programmation sensible au fuseau horaire, pas état de l’horloge | Règle écrite pour l’heure sautée et l’heure répétée | Responsable de la programmation | Sans échéance temporelle | Jour ordinaire suivant |
Une ligne qui prévoit seulement de « déclencher une alarme » est incomplète si l’action doit aussi être arrêtée ou confiée à un autre système.
Voici la ligne de mesure périmée appliquée au groupe frigorifique précédent. La température d’alimentation est rapportée toutes les 60 s. Le point devient périmé après 180 s sans rapport. La règle refuse alors les nouveaux démarrages de réponse à la demande sur ce groupe à la prochaine évaluation, soit dans les 60 s. La commande de fin à 16 h 30 s’exécute néanmoins. Le fonctionnement normal reprend après 2 lectures fraîches consécutives. Le guide des données périmées distingue les états que la règle doit traiter.
La ligne des émetteurs concurrents est plus difficile, car rien ne tombe en panne. Le Gateway écrit 6 °C dans le registre Modbus de la température d’eau sortant du groupe à 16 h. À 16 h 15, le programme BMS réécrit sa consigne normale de 7 °C. La relecture suivante du Gateway à 16 h 16 indique 7,0 °C. S’il réécrit 6 °C, les deux systèmes se relaient toutes les 15 minutes et le journal ne montre que des écritures réussies. La réponse prévue est d’arrêter d’écrire, de signaler le point avec les deux valeurs et de désigner un propriétaire. En général, le BMS suspend ses écritures de programme tant qu’un indicateur d’événement de réponse à la demande est actif.
La ligne des verrouillages révèle souvent les durées minimales de marche et d’arrêt. Copeland recommande au moins 3 minutes entre le démarrage et l’arrêt de ses compresseurs scroll pour permettre le retour de l’huile au carter. Un contrôleur qui impose cette durée reportera une demande d’arrêt de réponse à la demande envoyée 2 minutes après le démarrage par le BMS. Beaucoup de contrôleurs de groupe frigorifique ajoutent aussi une temporisation entre redémarrages. Lisez ces valeurs dans la liste des paramètres du contrôleur et inscrivez-les dans la matrice, afin que la règle anticipe le refus sans déclarer une panne.
La ligne du changement d’heure n’est pas une panne d’horloge. En Irlande et au Royaume-Uni, l’heure locale passe de 01 h à 02 h le dernier dimanche de mars et répète 01 h à 02 h le dernier dimanche d’octobre. Une règle quotidienne prévue à 01 h 30 n’a aucun démarrage en mars et deux horaires possibles en octobre. Stockez les programmes en UTC, ou définissez le comportement pour les deux cas.
Conception des commandes
Envoyez des valeurs absolues : « régler à 21 °C » et « arrêter », pas « augmenter de 2 °C » ni « inverser l’état ». Répéter une commande absolue est sans effet supplémentaire. La recevoir en retard n’est toutefois pas sans risque : un ordre « marche » arrivé après la fin de l’événement démarre quand même la charge. Donnez à chaque commande une échéance adaptée. Un démarrage de réponse à la demande reste valide jusqu’à la fin de la fenêtre de l’événement. Une commande de fin due reste valable pendant une courte fenêtre de reprise après son échéance. Ensuite, une personne vérifie l’équipement avant tout autre envoi. La commande de fin est enregistrée avant l’envoi du démarrage : elle survit ainsi à un redémarrage et à une modification de la règle.
Un délai dépassé laisse l’état inconnu. La commande peut avoir été exécutée alors que sa réponse s’est perdue. Une réponse normale à une écriture Modbus (code de fonction 05, 06, 15 ou 16) prouve que l’appareil a accepté la trame, pas que l’équipement a bougé. Relisez l’état comme le montre le guide de vérification des commandes BESS. Le cluster Zigbee On/Off propose Toggle en plus de On et Off. Utilisez On et Off, et considérez la commande terminée seulement lorsqu’un nouveau rapport de l’attribut OnOff montre l’état demandé. Les protocoles de téléconduite rendent les étapes explicites, comme le montre le guide des commandes IEC 60870.
Tester un cycle complet
Testez d’abord en simulateur ou sur une charge non critique avant l’équipement en exploitation. Utilisez une règle qui allume une charge à la minute 0 et l’éteint à la minute 10. Pour chaque étape, consignez l’heure et la valeur de chaque commande, son retour d’état et l’état observé de l’équipement. Marquez réussite ou échec selon le délai de la ligne correspondante de la matrice.
- Exécutez le cycle normal. Réussite : un démarrage et une fin, chacun confirmé par un retour d’état.
- Redémarrez le Gateway à la minute 4. Réussite : la commande de fin s’exécute à la minute 10 sur le même équipement et le démarrage n’est pas renvoyé.
- Éteignez le Gateway à la minute 8 et rallumez-le à la minute 11. Réussite : la commande de fin due s’exécute dès le retour du Gateway. Un second « arrêt » après une panne est acceptable ; un second démarrage est un échec.
- Laissez le Gateway éteint de la minute 8 à la minute 20. Réussite : la commande de fin n’est pas rejouée à la minute 20. La règle est bloquée et l’opérateur est invité à vérifier l’équipement, comme prévu par la ligne de redémarrage. Si la charge possède un temporisateur de perte de communication inférieur à 12 minutes, le dossier montre aussi son passage à l’état de repli.
- Supprimez le retour d’état de la commande de fin. Réussite : l’opérateur voit un résultat non résolu et le démarrage suivant reste bloqué jusqu’à confirmation de l’état de l’équipement.
- Modifiez ou supprimez la règle à la minute 5. Réussite : le cycle déjà commencé se termine à la minute 10 comme prévu.
- Arrêtez la mesure d’entrée à la minute 2. Réussite : les nouveaux démarrages sont bloqués au plus tard après le délai de péremption plus une évaluation.
- Dans le simulateur, définissez le fuseau horaire du site et exécutez une règle quotidienne sur les deux changements d’heure. Réussite : le comportement suit la règle écrite pour l’heure sautée et l’heure répétée.
Conservez ces dossiers : ils prouvent que chaque ligne a été testée et servent de référence pour une répétition après modification du micrologiciel ou de la configuration.
Commande locale dans Edge
Edge exécute l’automatisation sur le Gateway, déclenchée par les données, l’état d’un appareil, la qualité des données ou un programme horaire. L’évaluation ignore les données plus anciennes qu’une limite configurable, de 5 minutes par défaut. Réglez cette limite à la valeur de péremption prévue dans votre matrice.
Les règles qui démarrent une action et l’arrêtent après une durée donnée enregistrent les commandes de fin exactes avant l’envoi du démarrage. Si cet enregistrement échoue, le démarrage n’est pas envoyé. Modifier ou supprimer la règle n’annule pas une commande de fin déjà due. Après un redémarrage, Edge récupère les commandes de fin dues jusqu’à cinq minutes après leur échéance. Passé ce délai, il ne les rejoue pas. Il bloque l’automatisation et demande la vérification de l’équipement ; la réactivation de l’automatisation ne lève pas ce blocage. Les actions de fin doivent fixer un état explicite : Edge refuse un basculement ou une valeur fictive comme action de fin. Désactiver l’automatisation empêche seulement les nouvelles actions. Les commandes de fin dues restent exécutées. Ce n’est pas un arrêt d’urgence.
Pour les commandes Zigbee, Edge ne considère la commande terminée qu’après réception d’un nouveau rapport de l’appareil indiquant la valeur demandée. Par défaut, il attend 5 s, réessaie jusqu’à trois fois, puis déclenche une alerte critique. Une action de fin non confirmée bloque le prochain démarrage de la même règle jusqu’à ce qu’un nouveau rapport confirme l’état final. Ce rapport prouve l’état logique de l’appareil. Utilisez une mesure de puissance pour prouver que la charge s’est réellement arrêtée. Edge n’arbitre pas entre deux règles qui écrivent vers le même actionneur : attribuez une seule règle à chacun.
Les règles quotidiennes marche/arrêt utilisent le fuseau horaire configuré sur le Gateway. Si le passage à l’heure d’été supprime l’heure de fin, Edge n’envoie pas le démarrage. Une heure répétée en octobre ne démarre pas deux fois un cycle quotidien. Les simples déclencheurs programmés se comportent autrement : une heure sautée en mars ne se déclenche pas et une heure répétée en octobre se déclenche deux fois, sauf si la règle limite la fréquence.
Dans l’essai précédent, l’étape 3 tombe dans la fenêtre de reprise de cinq minutes d’Edge. L’étape 4 se situe au-delà : la réussite attendue est une reprise bloquée et une demande de vérification de l’équipement.
Questions fréquentes
Qu’est-ce qu’une matrice de défaillance pour la commande ?
Un tableau avec une ligne pour chaque panne possible : liaison, mesure, commande, redémarrage ou horloge. Chaque ligne explique comment détecter la panne, ce que fait la commande, qui porte cette réponse, sous quel délai et à quelle condition le fonctionnement normal reprend. Chaque ligne correspond aussi à un essai de mise en service.
À partir de quand une mesure est-elle trop ancienne pour une règle ?
Reliez la limite à l’intervalle de rapport. Trois rapports manqués constituent un point de départ raisonnable : 180 s pour un point qui rapporte toutes les 60 s. Une limite plus courte provoque de fausses alertes sur un seul message perdu ; une limite beaucoup plus longue laisse la règle agir sur une valeur qui ne décrit plus l’équipement.
Pourquoi envoyer des valeurs absolues plutôt que des changements ?
Une commande peut arriver deux fois, notamment après une nouvelle tentative. « Régler à 21 °C » envoyé deux fois laisse la consigne à 21 °C. « Augmenter de 2 °C » envoyé deux fois l’augmente de 4 °C. Il en va de même de « arrêter » face à « inverser l’état ».