Un groupe de FFUs se présente comme un problème de commande bien avant de devenir un problème de circulation d’air. Une fois que les appareils sont connectés en réseau à une passerelle ou à un système de gestion technique du bâtiment, le projet ne doit plus se contenter de répondre à la question “ chaque appareil fonctionne-t-il ? ”, mais doit plutôt déterminer si “ le système de commande sait-il, sans ambiguïté, quel appareil est lequel, à quelle zone il appartient, et ce qui se passe en cas de dysfonctionnement ? ” Une erreur à ce niveau ne se manifeste généralement pas lors de la mise en service d’une seule unité ; elle apparaît plus tard, lorsqu’une alarme signale un emplacement qui ne correspond plus au plan de mise en œuvre, ou lorsqu’une commande de zone est transmise au mauvais groupe d’unités.

Associer chaque adresse FFU à un emplacement physique et à une zone d'exploitation

Chaque FFU d’un réseau a besoin d’une adresse, mais cette adresse en soi ne fournit au système de contrôle aucune information sur l’emplacement de cette unité, sur ce qu’elle est censée faire, ni sur les autres unités dont elle dépend pour une réponse coordonnée. L’adresse est un identifiant de communication ; la mise en correspondance entre cet identifiant et le contexte physique et fonctionnel constitue une information distincte qui doit être créée et mise à jour de manière délibérée. Lorsque cette mise en correspondance n’existe pas sous la forme d’un registre distinct et consultable, la logique de contrôle et la configuration réelle des locaux ont tendance à diverger au fil du temps, en particulier lorsque des unités sont remplacées, recâblées ou réaffectées à une zone différente au cours du cycle de vie du projet.

La cartographie nécessite au moins quatre éléments associés à chaque adresse : l'emplacement physique de l'unité, la zone de fonctionnement à laquelle elle appartient, le contrôleur dont elle dépend et le circuit d'alimentation qui l'alimente. Chacun de ces éléments modifie l'interprétation d'un signal provenant de cette unité. Un signal d'état provenant d'un module a une signification si le contexte de la zone est connu, et une autre s'il ne l'est pas : un défaut signalé sans contexte de zone indique à l'opérateur qu'il y a un problème, mais ne précise pas ce que ce “ problème ” implique pour le processus que la zone protège. De même, il est important de connaître le circuit d’alimentation, car un module qui cesse de fonctionner pour une raison liée au câblage ne doit pas être diagnostiqué ni traité de la même manière qu’un module qui cesse de fonctionner pour une raison liée à la communication, même si les deux peuvent sembler identiques d’un simple point de vue de l’état.

Le regroupement en zones mérite à lui seul une attention distincte de celle accordée à l’adresse. Deux FFU peuvent partager un même local physique tout en appartenant à des zones de fonctionnement différentes si elles prennent en charge des processus différents, des limites de qualification différentes ou des exigences différentes en matière de réponse aux défaillances. À l’inverse, des unités situées dans des locaux adjacents peuvent appartenir à la même zone de fonctionnement si elles sont censées réagir conjointement à une même décision de contrôle. L’affectation des zones doit suivre le processus à protéger, et non la disposition physique des conduits ou du câblage, car cette dernière constitue une simple facilité d’installation, tandis que l’affectation des zones relève d’une décision de contrôle ayant des conséquences sur le comportement du système en fonctionnement normal et en cas de défaillance.

Avant le début de la programmation, ce registre d'adressage — emplacement, zone, contrôleur et circuit d'alimentation pour chaque unité physique — doit exister sous la forme d'un document auquel les équipes de mise en service et de contrôle peuvent se référer, et non sous la forme d'informations reconstituées de manière informelle à partir de plans ou de notes de terrain. S'assurer de l'existence de ce registre et de son exhaustivité pour chaque unité du groupe est une condition préalable à toutes les étapes suivantes de la configuration du système de contrôle.

Définir les commandes, les signaux d'état, les alarmes et les points de tendance pour chaque interface

Une fois que l'identité de chaque unité et le contexte de zone sont déterminés, la décision suivante consiste à déterminer ce qui circule effectivement à travers le interface entre les commandes de l'unité de filtration (FFU) et les systèmes environnants — le contrôleur de l'unité, toute passerelle et le système de gestion technique du bâtiment. Quatre catégories d'informations doivent généralement être définies de manière explicite : les commandes envoyées aux unités, les signaux d'état renvoyés par celles-ci, les alarmes nécessitant une intervention et les valeurs de tendance ou enregistrées conservées pour un examen ultérieur. Le fait de les traiter comme un flux de données unique et indifférencié crée une ambiguïté quant à la signification de chaque élément et à la personne censée y donner suite.

Les commandes et les signaux d’état ne sont pas des images miroir les uns des autres, même s’ils empruntent souvent le même chemin physique. Une commande indique à une unité ou à une zone ce qu’elle doit faire ; un signal d’état rend compte de ce qui se passe réellement. Lorsqu’un système de contrôle confond les deux — par exemple, en déduisant qu’une commande a été exécutée avec succès plutôt que de le confirmer par le biais d’un point d’état indépendant —, un projet perd la capacité de faire la distinction entre “ le système a demandé cela ” et “ le système a vérifié que cela s’est produit ”. Cette distinction revêt toute son importance précisément lorsqu’une défaillance survient, moment où elle est la plus difficile à rétablir a posteriori si elle n’a pas été intégrée dès le départ.

Les alarmes doivent faire l’objet d’une définition distincte de celle des états ordinaires, car une alarme implique une réponse obligatoire, tandis qu’un signal d’état peut être purement informatif. Les conditions qui déclenchent une alarme, le moment où celle-ci est générée dans la logique de contrôle et sa destination sont autant de décisions spécifiques à chaque projet, qui dépendent de la manière dont le processus protégé réagit à la condition de défaillance sous-jacente. Les points de tendance, quant à eux, ont encore une autre finalité : ils sont conservés à des fins d’analyse plutôt que de déclencher une action en temps réel ; leur valeur dépend donc de ce qui est enregistré, de la résolution utilisée et de la durée d’enregistrement, plutôt que d’une réponse immédiate.

La question de la propriété est présente dans les quatre catégories. Pour chaque élément — commande, état, alarme ou tendance —, le projet doit déterminer quel système l'enregistre, quel système fait autorité à cet égard et quel système un vérificateur doit consulter si la valeur enregistrée venait à être remise en cause. Définir ces éléments au niveau de l'interface, avant la finalisation du plan de contrôle, permet d'éviter une situation où un même signal semblerait provenir de deux systèmes sans qu'il y ait de consensus sur celui qui fait autorité.

Attribuer la responsabilité des contrôleurs d'unité, des passerelles et du système de gestion technique du bâtiment (GTB)

Une architecture de commande avec un un contrôleur d'unité, une passerelle et un système de gestion technique du bâtiment crée trois couches qui peuvent chacune revendiquer de manière plausible la responsabilité d'une décision donnée ou d'une donnée donnée. La responsabilité doit être attribuée explicitement, car la simple existence d'un chemin de données entre les couches ne permet pas de déterminer quelle couche fait autorité en cas de divergence des valeurs ou lorsqu'une commande doit être émise.

Le contrôleur d’unité est généralement le plus proche de l’équipement physique et dispose de la vision la plus immédiate de son état de fonctionnement réel. La passerelle, lorsqu’elle existe, traduit et agrège les informations entre le contrôleur d’unité et le BMS ; ce faisant, elle introduit un point où les données peuvent être retardées, transformées ou perdues si son rôle n’est pas clairement délimité. Le BMS est le plus éloigné de l’unité physique et dispose généralement de la vue d’ensemble la plus complète sur l’ensemble des zones, mais la précision de cette vue d’ensemble dépend entièrement de la qualité des données qu’il reçoit par l’intermédiaire des couches situées en dessous. Aucune de ces trois positions n’est automatiquement la “ bonne ” pour prendre une décision particulière ; le responsable approprié dépend des exigences de la décision : une réponse physique immédiate favorise une prise de décision au plus près de l’unité, tandis qu’une coordination inter-zones favorise une prise de décision au niveau du BMS.

Lorsque la propriété reste implicite, un système de contrôle peut présenter des comportements contradictoires : une commande émise au niveau du BMS peut être annulée localement au niveau du contrôleur de l’unité sans qu’aucune trace de cette annulation ne soit conservée, ou une passerelle peut mettre en mémoire tampon un changement d’état suffisamment longtemps pour que le BMS agisse sur la base d’informations obsolètes. Aucun de ces modes de défaillance ne nécessite le dysfonctionnement d’un composant en particulier — les deux peuvent se produire alors que chaque composant fonctionne exactement comme prévu, simplement parce que l’attribution de l’autorité n’a jamais été explicitée pour ce point de données ou ce chemin de commande.

L'attribution de la responsabilité implique également de décider ce qui se passe en cas de divergence entre les couches : si la lecture locale du contrôleur de l'unité fait autorité, si la passerelle est autorisée à substituer une valeur par défaut lorsqu'elle ne parvient pas à joindre l'unité, et si le BMS affiche une valeur qu'il ne peut pas vérifier lui-même. Ces décisions doivent figurer dans le schéma de contrôle, aux côtés du registre d'adressage et des définitions de points, car elles déterminent le comportement du reste du système une fois que les données circulent correctement.

Définir le comportement de la zone en cas de défaillance des communications, de l'alimentation ou de l'unité

Les adressages, les définitions des points et les attributions de propriété décrivent le comportement attendu du système dans des conditions normales. Le comportement en cas de défaillance fait l'objet d'une spécification distincte et ne peut être déduit automatiquement de la logique de fonctionnement normal : un système qui fonctionne correctement lorsque toutes les unités communiquent entre elles ne dispose pas pour autant d'un comportement défini pour les situations où une unité cesse de communiquer, subit une coupure d'alimentation ou devient indisponible pour toute autre raison.

Trois types de défaillances reviennent régulièrement au sein des groupes de FFU : la perte de communication avec une unité, la coupure d’alimentation d’une unité et le fait qu’une unité soit simplement indisponible pour une autre raison. Chacune de ces défaillances a une cause sous-jacente différente, et les traiter comme si elles étaient interchangeables entraîne une réponse de contrôle qui peut s’avérer inappropriée pour au moins l’une d’entre elles. Une perte de communication ne signifie pas nécessairement que le ventilateur a cessé de faire circuler l’air ; une coupure d’alimentation l’implique presque à coup sûr ; et le fait qu’une unité soit signalée comme indisponible par un autre mécanisme peut correspondre ou non à une modification réelle du débit d’air. Étant donné que les conséquences physiques diffèrent selon ces trois cas, la réponse programmée de la zone ne devrait pas adopter par défaut un comportement identique pour les trois simplement parce qu’il s’agit dans les trois cas de “ défauts ” du point de vue du système de contrôle.

Le comportement approprié d’une zone face à chaque défaillance dépend du processus qu’elle protège et de l’évaluation des risques propre au site, et non d’un paramètre par défaut général applicable à tous les projets. Lorsqu’une zone protège un processus ne tolérant aucune interruption du flux d’air coordonné, la perte de communication d’une seule unité peut nécessiter le déclenchement immédiat d’une alarme au niveau de la zone et l’exécution d’une commande de secours définie pour les unités restantes, avant même que la cause sous-jacente ne soit confirmée. Lorsque la zone protège un processus moins sensible, cette même perte de communication peut être gérée par une alarme différée, ce qui laisse le temps de distinguer un problème réseau transitoire d’une véritable défaillance d’unité, évitant ainsi une réponse inutile à l’échelle de la zone face à une situation qui se résout d’elle-même. Aucune de ces deux approches n’est universellement valable ; chacune relève d’un jugement qui dépend du processus protégé et des conséquences d’une fausse réponse par rapport à une réponse différée.

C'est également à ce stade que la décision de zonage du projet, prise précédemment lors de l'affectation des adresses aux zones opérationnelles, détermine la portée de la réponse en cas de défaillance. Un défaut sur une unité affectée à une zone strictement délimitée ne doit pas automatiquement propager une réponse aux unités d’une zone adjacente, sauf si le processus lui-même nécessite un comportement coordonné au-delà de cette limite. C’est en spécifiant explicitement cette portée, pour chacun des trois types de défauts, que le programme de contrôle peut définir une réponse précise, plutôt que de laisser le comportement réel se révéler uniquement lorsqu’un défaut survient en service.

Vérifier l'adressage, l'acheminement des alarmes et les données enregistrées lors de la réception sur site

Chaque décision prise en amont — le registre d'adressage, les définitions des points, les attributions de propriété et le comportement en cas de défaillance — figure sur papier sous la forme d'un schéma de commande approuvé jusqu'à ce qu'elle soit vérifiée par rapport au système installé. Acceptation du site C'est à ce stade que le projet permet de confirmer que ce qui a été spécifié correspond bien à ce qui a été réellement développé et programmé ; cette vérification doit être effectuée point par point, plutôt que de se contenter de supposer que tout est en ordre simplement parce que le système semble fonctionner.

La vérification de l'adressage consiste à s'assurer que l'adresse de chaque FFU physique, telle qu'indiquée par le système de contrôle, correspond bien à l'emplacement, à la zone, au contrôleur et au circuit d'alimentation enregistrés dans le registre. Cette vérification est nécessaire car les opérations d'installation et de mise en service — recâblage, remplacement d'unité ou réétiquetage — peuvent rompre, sans qu'on s'en aperçoive, la correspondance entre une unité physique et son identité enregistrée, sans produire aucun symptôme visible jusqu'à ce qu'une alarme ou une commande soit mal acheminée.

La vérification des commandes de zone consiste à s'assurer qu'une commande envoyée à une zone donnée parvient bien aux unités associées à cette zone, et que celles-ci, et uniquement celles-ci, y donnent suite. Cela permet de confirmer que la décision de zonage prise lors de la phase de mappage des adresses a été correctement transposée dans la logique programmée, et non pas simplement consignée par écrit.

Vérifier l'acheminement des alarmes revient à s'assurer que les chemins d'alarme définis précédemment — à savoir quelles conditions déclenchent une alarme et quel est son acheminement entre les commandes de l'unité de traitement d'air (FFU) et le système de gestion technique du bâtiment (GTB) — se comportent conformément aux spécifications dans des conditions de test, et pas seulement en fonctionnement normal. Un chemin d'alarme qui n'a jamais été testé n'offre aucune garantie quant à son acheminement correct en cas de défaut réel, car le mode de défaillance d'un chemin d'alarme est souvent silencieux plutôt qu'évident.

La vérification des valeurs enregistrées consiste à s'assurer que la tendance et les données consignées disponibles à l'interface entre les commandes de l'unité FFU et le système de gestion technique du bâtiment (GTB) correspondent à ce qui est spécifié dans le programme de contrôle : les points corrects, provenant de la source appropriée, conservés sous une forme permettant à un vérificateur de les consulter ultérieurement. Cela boucle la boucle par rapport à l'attribution des responsabilités, car une valeur enregistrée n'est utile que si sa source faisant autorité a été établie au préalable. C’est la vérification de ces quatre aspects par rapport au programme de contrôle approuvé, à ce stade, qui permet au projet de considérer le comportement du système de contrôle comme établi et non plus comme une simple hypothèse pour la suite.

Questions fréquemment posées

Q : Que faut-il mettre en place avant de commencer l'attribution définitive des adresses FFU ?
A : Définissez l'identifiant d'emplacement physique, la zone d'exploitation, le contrôleur et la relation avec le circuit d'alimentation pour chaque unité dans le registre d'adressage. Si l'une de ces affectations est encore susceptible de changer, conservez les adresses concernées à titre provisoire jusqu'à ce que l'agencement soit définitif ; sinon, un remappage ultérieur pourrait déconnecter les circuits d'alarme et les registres de réception de l'unité installée.

Q : Faut-il envoyer toutes les données des points de contrôle FFU au système de gestion technique du bâtiment (GTB) ?
A : Non. Sélectionnez les commandes, les signaux d'état, les alarmes et les valeurs de tendance nécessaires au plan d'exploitation et de surveillance du site, puis consignez la source, la destination et le responsable de chaque point sélectionné. Une interface dont la responsabilité n'est pas clairement définie peut amener tant l'équipe chargée des commandes des FFU que celle du système de gestion technique du bâtiment (GTB) à supposer que c'est à l'autre partie de la configurer ou de la vérifier.

Q : Comment le projet doit-il déterminer le comportement de la zone en cas de défaillance de la communication, de l'alimentation ou d'une unité ?
A : Définissez la réponse à adopter pour chaque type de défaillance à partir de l'évaluation des risques liés au processus protégé et au site, et consignez séparément le comportement attendu de la zone dans le plan de contrôle approuvé. N'utilisez une solution de secours commune que si le projet a établi que les différentes défaillances ont les mêmes conséquences ; dans le cas contraire, la réponse prévue peut être masquée jusqu'aux essais de réception.

Q : Quels points doivent être réglés entre le fournisseur de systèmes de contrôle et l'intégrateur BMS avant l'établissement du devis ?
A : Fournir le registre d'adressage et la liste des points d'interface, puis attribuer la responsabilité de chaque commande, signal d'état, alarme et valeur de tendance entre le contrôleur de l'unité, la passerelle et le système de gestion technique du bâtiment (GTB). Régler la question des points non attribués et définir le comportement requis en cas de défaillance avant que le cahier des charges et le devis ne soient finalisés, afin que les travaux de mise en service ne soient pas répartis entre les différents lots.

Q : Comment un acheteur peut-il éviter une validation apparente qui cache une erreur d'intégration des commandes ?
A : Utilisez le schéma de contrôle approuvé comme base de réception et testez de bout en bout le mappage des adresses physiques, les commandes de zone, les chemins d'alarme et les valeurs enregistrées. Notez les résultats attendus et observés pour chaque vérification ; une réponse en temps réel ne suffit pas à elle seule lorsque l'adresse, la destination ou la valeur enregistrée ne correspond pas au schéma approuvé.