Gestion Informatisée des bâtiments, télégestion

..........
.
.
.
.
.
.
.
.
.
.
SABACO inc.
Automatisation/Contrôle
Gestion Informatisée des
bâtiments, télégestion
Préparé par :
Pierre Kardous, ing.
88, 27e Avenue Nord
Bois des Filion, Québec
J6Z 4J6
Tél: [phone]
Fax: [phone]
Courriel: [email protected]

2
.
.
.
.
.
.
.
.
.
.
Télégestion
Il y a dix ans débutait les premiers
balbutiements de la télégestion!
Un peu d’histoire
En fait, la télégestion remonte à bien plus longtemps qu’on ne peut le penser. Déjà, en 1985,
je participai à l’installation et la mise en marche de mon premier projet d’automatisation en
milieu institutionnel.
Il s’agissait alors de l’installation d’un système de centralisation et de gestion énergétique qui
avait pour objectif de réduire les coûts d’exploitation en arrêtant les systèmes de ventilation
en période inoccupée. Ajouter à cela des startégies d’abaissement de température, de départ
optimisé, de délestage de charges, de réajustement de la température de l’eau chaude en
fonction de la température extérieure et voilà une centralisation en bonne et due forme d’un
système de contrôle digital direct, communément appelé: système DDC.
En ce temps-là, le système en question avait une architecture distribuée, basée sur un SAC
(Stand Alone Controller) et des RCUs (Remote Control Units). Le “SAC” assurait l’échange
des données du réseau et la synchronisation des tâches de gestion évoluées, telles que
l’optimisation et le délestage de charges. Les points d’entrées/sorties étaient raccordés aux
RCUs et ces derniers assuraient le contrôle des fonctions locales et relativement simples telles
que les boucles de contrôle PID. Le tout se rapportait à un poste opérateur pourvu d’une
interface graphique qui consistait d’un ordinateur personnel opérant sur le système
d’exploitation CPM/86. Ce n’était même pas DOS! Les disquettes de sauvegarde avaient 8
pouces et, en option, on pouvait installer un disque dur de 10 ou 20 MB.
Bien avant ça, on se rappellera des systèmes centralisés et, si on remonte encore plus loin, les
systèmes superviseurs. Ces derniers assuraient la surveillance à distance des points de
contrôles et permettaient, moyennant des installations coûteuses, le changement des points de
consigne et le démarrage à distance des systèmes électromécaniques.
Un outil de gestion mal exploité
L’obligation première d’un système de contrôle est, évidemment, de contrôler et maintenir le
confort dans les espaces et locaux. Mais cela ne représente, en général, qu’une partie minime
des capacités des systèmes d’aujourd’hui. La plupart permettent la collecte et l’analyse des
données, mais ces capacités restent souvent inexploitées; au même titre qu’une secrétaire
exploite rarement toutes les capacités de son logiciel de traitement de texte.
Avec les restrictions budgétaires incessantes, les contrats de service, monnaie courante il y a
quelques années seulement, sont mis en cause. Ils sont souvent annulés et les vérifications et
calibrage périodiques et systématiques des contrôles pourraient être négligées au point d’avoir
des répercutions sur les coûts d’exploitation.

3
Par souci de gestion et d’économie d’énergie les administrateurs doivent trouver des solutions
innovatrices pour les aider à accomplir leurs tâches et gérer le plus efficacement possible le
temps du personnel d’entretien. Une des solutions à envisager devrait se tourner vers les
capacités, encore peu exploitées, des systèmes de centralisation. La génération et l’analyse de
rapports de performance et rapports statistiques des systèmes CVAC peuvent générer des
économies substantielles.
À titre d’exemple, en analysant
les rapports quotidiens ou
hebdomadaires des systèmes de
ventilation, on peut déceler des
problèmes d’opération et encore
mieux, optimiser les points de
consignes et modifier au besoin
les séquences de contrôles pour
rentabiliser au maximum
l’opération des systèmes. Dans
la figure ci-contre on
remarquera que l’arrêt des
pompes de chauffage n’a
pratiquement pas affecté les
températures de pièces. Cela a
permis de réduire le point de
consigne de la gaine chaude du
système sans affecter le confort.
La figure ci-contre nous permet d’examiner la relation entre le signal d’ouverture des volets
de mélange d’un système versus le pourcentage d’air frais réel (tel qu’il est calculé en
fonction des températures extérieure, de retour et de mélange). Outre le fait qu’il nous permet
de nous assurer d’une ventilation
minimum, plus de 25 % ici, il nous
a permis de déceler un manque de
répétitivité du signal de modulation
des volets à grande ouverture. Ce
graphique a engendré un bon de
travail qui a permis au technicien
de se rendre compte que les tiges
d’assemblages (linkage) s’étaient
desserrées. De plus, il a permis de
calculer une approximation réaliste
du signal de contrôle nécessaire
pour maintenir une ventilation
adéquate en été, lorsque le calcul
dynamique n’est pas possible. Un
graphique similaire peut tout aussi
bien être appliqué à d’autres
équipements de contrôle pour
vérifier la modulation des valves de
chauffage et de refroidissement,
aux vannes d’entrée d’air des systèmes à volumes variables etc. Appliqué à une valve de
chauffage, on affichera le signal d’ouverture versus la capacité thermique en BTU, calculée
selon la différence de température en amont et en aval des serpentins et du débit de
ventilation; cela pourrait nous permettre de déceler des problèmes de valves et même
d’encrassement des serpentins.
VL-11
(au 29 avril 96)
y = -0.0003x3 + 0.0317x2 + 0.1819x + 5.0994
0.00
10.00
20.00
30.00
40.00
50.00
60.00
70.00
80.00
90.00
100.00
0.00 10.00 20.00 30.00 40.00 50.00 60.00 70.00 80.00 90.00 100.00
Signal d'ouverture
% d'Air Frais
Système #1
0
5
10
15
20
25
30
35
0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00
10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00
Heure
Deg C
0
10
20
30
40
50
60
70
80
90
100
% (VLM, AF, HAF)
TAF-1
PMVT-1
TAP-1
TAR-1
TAM-1
TGC-1
TGF-1
HAF-1
VLM-1
VL-1
Malgré l'arrêt des pompes de chauffage, on
remarque que les températures de pièce n'ont
pas réagi. Cela a permis de réduire le point de
consigne de la gaine chaude sans affecter le
confort.

4
L’évolution
Au début de la centralisation distribuée des contrôles, l’installation de systèmes DDC se
limitait aux points de lecture et de contrôle jugés le plus important pour accomplir les tâches
de gestion énergétique pouvant être rentabilisées dans un délai plus ou moins court. Le coût
du point se situait aux environs de 800 à 1,000 dollars et les superflus étaient simplement
éliminés. La fiabilité des systèmes était encore à éprouver et les ingénieurs exigeaient le
maintien des composantes pneumatiques en redondance sur les projets de rénovation. L’usage
généralisé des contrôles informatisés dans les nouvelles constructions était relativement
restreint puisqu’il était encore courant de voir des devis de construction avec des équipements
pneumatiques et la centralisation tenir le rôle d’une horloge glorifiée.
Depuis, les contrôleurs autonomes ont acquis plus de fiabilité, de flexibilité, de maturité et de
puissance. Les systèmes de contrôle distribués de type “Peer To Peer” (à passage de jeton) ont
surclassé les systèmes dits “Master/Slave” (maître/esclave).
Les systèmes de type “à passage de jeton” se caractérisent par la capacité des
contrôleurs, tous d’une même catégorie et d’un même niveau, de demander de
l’information et d’envoyer des commandes à d’autres, à un certain moment,
lorsqu’ils détiennent le jeton.Ils sont généralement préférés puisqu’ils
permettent une plus grande flexibilité d’installation et une plus grande fiabilité
du réseau.
Dans une architecture de type “maître/esclave”, le panneau maître gère
l’échange des données d’un panneau à un autre et permet la centralisation de
l’information au poste opérateur. Ce type d’architecture est encore très répandu
et représente l’architecture de choix lorsqu’il est question d’assurer le contrôle
terminal des locaux. Dans les systèmes traditionnels, les contrôleurs esclaves
seront dédiés aux unités de toits, aux pompes à chaleur, aux boîtes VAV, etc.
La programmation en langage informatique textuel du type “Basic, “C” et autres, a cédé la
place à la programmation orientée objet et la programmation graphique. Les interfaces se sont
uniformisées par des applications fonctionnant sur le système d’exploitation Windows, de loin
plus convivial que ne l’étaient les premiers systèmes graphiques, il y a 15 ans.
Comme tous les autres domaines touchés par l’informatique, la révolution dans le secteur des
contrôles a fait son chemin. On a assisté à une prolifération constante des contrôles à base de
microprocesseurs, influencée par la baisse continue du coût des composantes et l’amélioration
de leurs performances. Ces progrès étaient en partie responsables de leur propagation et usage
généralisé dans des applications jusque-là considérées trop dispendieuses ou trop complexes.
Aujourd’hui, on retrouve une multitude d’autres systèmes à base de microprocesseurs, utilisés
dans des bâtiments institutionnels, commerciaux ou industriels, permettant le contrôle et/ou la
télésurveillance de divers équipements tels que : chaudières, refroidisseurs, systèmes de
sécurité d’accès, système d’éclairage et d’alarme incendie, pour n’en nommer que quelques-
uns. La plupart des systèmes permettent, d’une façon ou d’une autre, la communication avec
un poste opérateur et l’échange d’information entre eux et d’autres fabricants.
Cet échange avec d’autres fabricants se faisait, en général, à l’aide de
“Gateway” dont la tâche consistait à convertir les données entre deux
protocoles de communication différents et permettait ainsi de lire les données et
centraliser l’information à un seul et même poste opérateur.

5
Cela devait permettre une intégration transparente des diverses composantes qui forment un
tout dans le bâtiment. On pouvait alors rêver du bâtiment intelligent où l’ouverture d’une
porte par une carte de sécurité aurait automatiquement enclenché une série d’actions
préprogrammées telles que, la mise en marche de la ventilation, le changement des points de
consigne au point de consigne de jour, etc. Pour les fabricants qui commercialisent des
systèmes intégrés cela était relativement facile. C’était loin d’être le cas pour ceux qui
devaient intégrer l’opération de composantes d’autres fabricants avec les leurs; surtout
lorsqu’il était question de faire des mises à jour des systèmes (les logiciels et progiciels des
“Gateways” étaient souvent à la traîne puisqu’il fallait que les fabricants en cause
coordonnent leurs activités).
L’interopérabilité des systèmes avait donc un prix et les propriétaires et gestionnaires étaient
les premiers à en faire les frais. Cela a suscité un intérêt marqué au développement et
l’adoption de protocoles ouverts.
Les protocoles ouverts
Le concept des protocoles ouverts n’est pas nouveau. En Europe, les efforts de développement
dans ce sens ont permis l’adoption de PROFI, BUS et FND. Aux États-Unis, le DNP
(Distributed Network Protocol), l’UCA (Utility Communications Architecture) et SCADA
(Supervisory Control And Data Acquisition) furent récemment développés pour le secteur
industriel. Dans le secteur commercial, tel qu’appliqué en automatisation et contrôle des
bâtiments, deux protocoles de communication se disputent la première place: BACnet
parrainé par ASHRAE et LonTalk, parrainé par la corporation Echelon.
BACnet
BACnet (Building Automation and Control NETwork) est un protocole de communication de
données. Ce n’est ni un logiciel, ni un progiciel ni un équipement de contrôle.
C’est un ensemble de règles qui gouvernent l’échange des données entre
différents ordinateurs sur un réseau local et qui couvrent tous les éléments
nécessaires à cet échange; du câble de communication à la syntaxe d’une
requête ou d’une commande à exécuter.
Il a été développé par un comité de l’ASHRAE (American Society of Heating, Refrigeration
and Air-conditionning Engineers) et adopté, par la suite, comme un standard. Il serait en cours
d’évaluation par la communauté européenne pour son adoption comme préliminaire à un
standard. Il a également été soumis à l’organisation internationale de standardisation (ISO)
pour adoption comme un standard international.
L’objectif du comité était de développer un protocole qui permettrait l’interopérabilité de
différents systèmes et fabricants d’équipements d’automatisation/contrôle. Pour permettre une
communication efficace entre les ordinateurs, il fallait définir deux choses:
1.1. Une langue commune pour la représentation des données et commandes;
2.2. Une méthode sûre pour acheminer l’information entre les ordinateurs; les
réseaux locaux.
Cette langue commune représente la partie la plus innovatrice du standard. Elle définie les
marches à suivre qui devaient se regroupaient en trois parties principales. La première partie
consistait par la description d’une méthode de représentation uniforme de tous les types
d’équipement d’automatisation du bâtiment. La seconde partie devait définir les messages qui
devaient être échangés sur le réseau pour permettre la supervision et le contrôle des