Une gestion technique du bâtiment ne surveille pas uniquement le chauffage, la ventilation et la climatisation.

Dans un bâtiment moderne, de nombreux systèmes doivent transmettre des informations vers la supervision centrale.

Une alarme incendie peut apparaître.

Une alimentation sans interruption peut passer sur batterie.

Un système photovoltaïque peut signaler un défaut.

Un ascenseur peut tomber en panne.

Un système de contrôle d’accès peut devenir indisponible.

Une baie informatique peut présenter une température trop élevée.

Le système KNX peut perdre sa communication.

Un dispositif de protection contre les surtensions peut déclencher.

Toutes ces informations intéressent l’exploitant du bâtiment.

Mais une question apparaît immédiatement :

Comment faire parvenir toutes ces informations jusqu’à la GTB ?

Il existe principalement deux grandes approches.

La première consiste à tirer physiquement des câbles entre les différents systèmes techniques et l’automate GTB.

La seconde consiste à récupérer les informations par communication numérique, par exemple avec BACnet ou KNX.

Dans certains bâtiments, les deux méthodes sont utilisées simultanément.

C’est d’ailleurs souvent la solution la plus réaliste.

Dans cet article, nous allons comprendre comment organiser ces remontées d’alarmes, comment choisir entre câblage direct et communication numérique, comment utiliser une passerelle BACnet/KNX et surtout comment éviter les erreurs d’interface entre les différents lots techniques.

1. Qu’appelle-t-on une remontée d’alarme en GTB ?

Une remontée d’alarme consiste à transmettre à la GTB une information provenant d’un autre équipement ou d’un autre système technique.

Cette information peut indiquer :

un défaut

une alarme

un état de fonctionnement

une disponibilité

un déclenchement

un mode particulier

Prenons un groupe électrogène.

La GTB peut recevoir par exemple :

• groupe disponible ;
• groupe en fonctionnement ;
• défaut général.

Prenons une alimentation sans interruption.

La GTB peut surveiller :

• disponibilité ;
• défaut ;
• fonctionnement sur batterie.

Prenons un système photovoltaïque.

Il peut fournir :

• défaut général ;
• éventuellement production ou puissance instantanée si une communication numérique est disponible.

La GTB devient ainsi le point central permettant à l’exploitant de connaître l’état général du bâtiment.

2. Une remontée d’alarme n’est pas forcément une commande

Cette différence est fondamentale.

Recevoir une information ne signifie pas forcément avoir le droit d’agir sur le système concerné.

Prenons un système de détection incendie.

La GTB peut recevoir :

alarme générale active

ou

défaut du système

Cela ne signifie pas nécessairement que la GTB doit commander le système incendie.

Dans beaucoup d’architectures, la GTB est uniquement destinataire de l’information.

Il faut donc distinguer :

supervision

et

commande.

Cette distinction est particulièrement importante avec :

• détection incendie ;
• désenfumage ;
• contrôle d’accès ;
• éclairage de sécurité ;
• systèmes de sécurité des personnes.

Les fonctions réglementaires et de sécurité doivent rester gérées selon l’architecture et les équipements prévus pour ces fonctions.

3. Pourquoi intégrer les autres lots techniques dans la GTB ?

Imaginez un bâtiment avec quinze systèmes différents.

Sans centralisation, l’exploitant doit consulter :

• l’écran du système incendie ;
• l’écran de l’alimentation sans interruption ;
• l’interface photovoltaïque ;
• le système de contrôle d’accès ;
• l’interface des ascenseurs ;
• la supervision CVC ;
• les équipements électriques.

Cela devient rapidement difficile.

Avec une GTB correctement intégrée, l’exploitant peut disposer d’une vue globale.

Par exemple :

Alimentation sans interruption – Fonctionnement sur batterie

ou :

Ascenseur 2 – Défaut

ou encore :

Installation photovoltaïque – Défaut général

La GTB ne remplace pas nécessairement la supervision spécialisée.

Elle centralise les informations importantes pour l’exploitation générale du bâtiment.

4. Quels lots techniques peuvent transmettre des informations à la GTB ?

Le nombre de systèmes dépend fortement du bâtiment.

Dans un immeuble tertiaire important, on peut notamment retrouver les éléments suivants.

L’objectif n’est évidemment pas de remonter toutes les informations possibles.

Il faut sélectionner les informations réellement utiles à l’exploitation.

5. Première méthode : tirer des câbles jusqu’à l’automate GTB

C’est la méthode traditionnelle et encore très utilisée.

Le système externe fournit un contact.

Ce contact est câblé jusqu’à une entrée numérique de l’automate.

Le principe peut être représenté ainsi :

Équipement externe
       ↓
Contact de signalisation
       ↓
Câble
       ↓
Bornier de l’armoire GTB
       ↓
Entrée numérique
       ↓
Automate
       ↓
GTB

Prenons un exemple.

Le tableau de l’alimentation sans interruption possède un relais indiquant :

défaut général

Le fabricant met à disposition un contact libre de potentiel.

Un câble est tiré entre l’équipement et l’armoire GTB.

Le contact est raccordé à une entrée numérique.

Lorsque le défaut apparaît, l’état de cette entrée change.

L’automate détecte le changement.

La GTB génère alors :

Alimentation sans interruption – Défaut général

La chaîne est simple, robuste et facile à comprendre.

6. Qu’est-ce qu’un contact libre de potentiel ?

C’est une notion très importante dans les interfaces GTB.

Un contact libre de potentiel fonctionne comme un interrupteur électrique.

Il ne fournit pas nécessairement lui-même une tension.

Il indique simplement :

contact ouvert

ou

contact fermé.

L’automate peut utiliser sa propre alimentation pour surveiller cet état.

On retrouve alors typiquement :

24 V continu
   ↓
Contact équipement
   ↓
Entrée numérique automate

L’état du contact permet à l’automate de savoir si l’information est :

0 ou 1.

Cela convient parfaitement à des informations comme :

• défaut général ;
• marche ;
• arrêt ;
• disponibilité ;
• batterie ;
• alarme.

7. Pourquoi utilise-t-on encore beaucoup le câblage direct ?

Parce qu’il possède plusieurs avantages.

Il est relativement simple.

Il ne nécessite pas forcément de protocole de communication.

Il est facile à tester.

Il peut fonctionner entre des équipements de fabricants différents.

Et surtout, il permet de récupérer une information même lorsqu’un système ne possède aucune interface réseau compatible avec la GTB.

Prenons un ancien groupe électrogène.

Il ne communique ni en BACnet ni en KNX.

Mais son tableau possède :

un contact marche

et

un contact défaut.

Deux entrées numériques suffisent alors pour récupérer les deux informations.

8. Mais tirer des câbles a aussi des limites

Imaginez un bâtiment dans lequel vous devez récupérer :

80 informations provenant de plusieurs lots techniques.

Si chaque information nécessite un raccordement physique, cela représente :

• beaucoup de câbles ;
• beaucoup de borniers ;
• beaucoup d’entrées automate ;
• beaucoup de repérage ;
• beaucoup de tests.

Le coût peut alors devenir important.

C’est précisément à ce moment que les communications numériques deviennent intéressantes.

9. Exemple de câblage entre un équipement externe et la GTB

Prenons un ascenseur.

L’ascensoriste met à disposition un contact :

défaut général ascenseur

On tire un câble entre son tableau et l’armoire d’automatisation.

La chaîne devient :

Tableau ascenseur
       │
       │ Contact défaut
       │
       ▼
Câble de signalisation
       │
       ▼
Bornier GTB
       │
       ▼
Entrée numérique
       │
       ▼
Automate
       │
       ▼
Supervision

Sur l’écran GTB apparaît :

Ascenseur 1 – Défaut

Simple.

10. Deuxième méthode : récupérer directement les informations par BACnet

Supposons maintenant que l’équipement possède une interface BACnet.

Il n’est alors plus forcément nécessaire de tirer un câble individuel pour chaque information.

Un réseau peut transporter de nombreux points.

L’architecture peut devenir :

Équipement
     │
 BACnet/IP
     │
     ▼
Réseau Ethernet
     │
     ▼
Automate / serveur GTB

La GTB peut récupérer différents objets.

Par exemple :

défaut général

état

température

mode de fonctionnement

puissance

compteur

selon ce que l’équipement met réellement à disposition.

11. Pourquoi BACnet est très intéressant pour la GTB

BACnet a justement été conçu pour l’automatisation des bâtiments.

Il permet à différents systèmes de partager des informations structurées.

Au lieu d’avoir uniquement :

0 ou 1

comme avec un contact classique, la GTB peut parfois recevoir beaucoup plus d’informations.

Prenons une alimentation sans interruption.

Avec des contacts câblés, vous pourriez récupérer :

défaut

batterie

disponibilité.

Avec une communication numérique, selon l’équipement, vous pourriez également récupérer :

• charge ;
• tension ;
• autonomie estimée ;
• fréquence ;
• état de batterie ;
• alarmes détaillées.

La communication devient donc beaucoup plus riche.

12. Qu’est-ce qu’un objet BACnet ?

BACnet organise les informations sous forme d’objets.

Une information tout ou rien peut par exemple être représentée comme un objet binaire.

Une température peut être représentée comme une valeur analogique.

Un état comportant plusieurs modes peut utiliser un objet multi-état.

La GTB ne reçoit donc plus simplement « un fil ».

Elle reçoit une information structurée sur le réseau.

Par exemple :

Objet : Défaut général
Valeur : Actif

Ou :

Objet : Température local technique
Valeur : 29,4 °C

13. Mais BACnet ne fonctionne correctement que si les interfaces sont définies

Installer une prise réseau ne suffit pas.

Il faut connaître :

• l’adresse de l’équipement ;
• son instance BACnet ;
• les objets disponibles ;
• les droits de lecture et d’écriture ;
• les unités ;
• les états ;
• les alarmes ;
• les noms des points.

Une liste de points est donc indispensable.

Sans cette liste, l’intégrateur risque de découvrir l’interface uniquement lors de la mise en service.

Et cela crée très souvent des retards.

14. Troisième possibilité : récupérer les informations d’un système KNX

KNX est fréquemment utilisé pour :

• éclairage ;
• stores ;
• protections solaires ;
• commandes de pièce ;
• présence ;
• températures ;
• automatismes locaux.

Supposons qu’un bâtiment possède déjà un réseau KNX.

La GTB souhaite récupérer :

défaut général KNX

mais également :

alarme vent

afin de savoir pourquoi les stores ont été verrouillés.

On pourrait techniquement tirer plusieurs câbles.

Mais cela n’est pas forcément nécessaire.

Une intégration numérique peut être plus intéressante.

15. La passerelle BACnet/KNX

Une passerelle permet de faire communiquer deux systèmes utilisant des protocoles différents.

Dans notre cas :

Réseau KNX
     │
     ▼
Passerelle KNX / BACnet
     │
     ▼
BACnet/IP
     │
     ▼
GTB

La passerelle reçoit des informations KNX.

Elle les transforme en objets exploitables côté BACnet.

La GTB peut ensuite les superviser comme d’autres points BACnet.

16. Exemple concret : alarme vent KNX

Prenons une station météo KNX.

Elle détecte un vent trop important.

Le réseau KNX génère alors :

alarme vent = active

Cette information peut être utilisée localement pour remonter les stores.

Mais elle peut également être transmise à la GTB.

Le chemin devient :

Capteur de vent
     ↓
KNX
     ↓
Adresse de groupe
     ↓
Passerelle
     ↓
Objet BACnet
     ↓
GTB

La supervision peut alors afficher :

Protection solaire – Verrouillage par vent fort

Cette architecture évite de créer un deuxième capteur uniquement pour la GTB.

17. Une passerelle ne supprime pas tous les câbles

C’est un point qu’il faut absolument comprendre.

On entend parfois :

« Avec BACnet, on n’a plus besoin de câbles. »

C’est faux.

Les équipements doivent toujours être :

• alimentés ;
• raccordés au réseau ;
• parfois raccordés à leur bus terrain.

La communication numérique réduit principalement le nombre de liaisons individuelles de signalisation vers la GTB.

Prenons vingt états provenant du système KNX.

Avec vingt contacts câblés :

20 signaux → nombreux conducteurs

Avec une passerelle :

un réseau → plusieurs dizaines d’informations.

C’est très différent.

18. Câblage direct ou communication réseau : lequel choisir ?

Il n’existe pas une seule réponse correcte.

Les deux solutions sont utiles.

En pratique, les bâtiments modernes utilisent fréquemment les deux approches.

19. Exemple d’architecture hybride

Imaginons un immeuble de bureaux.

La GTB récupère :

Par câblage direct

• alarme incendie générale ;
• défaut incendie ;
• défaut groupe électrogène ;
• défaut général ascenseur.

Par BACnet

• alimentation sans interruption ;
• compteurs ;
• centrales de traitement d’air ;
• production thermique.

Par KNX via passerelle

• état du système KNX ;
• alarme vent ;
• certains états d’éclairage ;
• certaines informations de protections solaires.

C’est une architecture parfaitement logique.

Il n’est pas nécessaire d’imposer le même mode de communication partout.

20. Comment déterminer les informations réellement nécessaires ?

Avant de parler câble ou BACnet, il faut commencer par une question plus fondamentale :

Quelles informations doit voir l’exploitant ?

C’est là qu’intervient la liste des points.

Pour chaque système, on définit :

équipement

information

quantité

destination

mode de transmission

priorité

Par exemple :

Cette liste devient ensuite une référence pour tous les intervenants.

21. Pourquoi attribuer une priorité aux alarmes ?

Toutes les informations n’ont pas la même importance.

Une alarme incendie n’a évidemment pas la même criticité qu’un défaut de production photovoltaïque.

On peut donc définir plusieurs niveaux.

Par exemple :

Priorité 1 — critique

Informations nécessitant une réaction rapide.

Exemples :

• alarmes de sécurité importantes ;
• défauts affectant fortement l’exploitation ;
• indisponibilités critiques.

Priorité 2 — importante

Défauts techniques nécessitant une intervention mais pas nécessairement immédiate.

Par exemple :

• défaut ASI ;
• défaut ascenseur ;
• défaut photovoltaïque ;
• défaut de communication.

Priorité 3 — information ou événement moins critique

Par exemple :

• verrouillage d’une protection solaire par vent ;
• certains changements de mode.

Cette classification doit évidemment être adaptée au bâtiment et à sa stratégie d’exploitation.

22. Attention aux systèmes de sécurité

L’intégration des systèmes de sécurité demande une attention particulière.

Prenons la détection incendie.

La GTB peut recevoir :

alarme générale

et

défaut général.

Mais la GTB ne doit pas être considérée automatiquement comme faisant partie de la fonction de sécurité.

La logique de sécurité doit rester réalisée par les systèmes prévus et validés pour cette fonction.

La GTB peut alors être utilisée comme :

outil de visualisation

outil d’exploitation

outil d’archivage

selon le projet.

Cette distinction évite de donner à la GTB des responsabilités qu’elle n’est pas censée assurer.

23. Comment préparer un câblage direct correctement ?

Pour chaque point câblé, il faut déterminer clairement :

• origine du signal ;
• destination ;
• type de contact ;
• tension utilisée ;
• bornes ;
• câble ;
• nombre de conducteurs ;
• identification ;
• comportement normal ;
• comportement en défaut.

Prenons :

Défaut groupe électrogène.

Il faut savoir :

Le contact est-il fermé en fonctionnement normal ?

Ou :

Le contact se ferme-t-il uniquement lorsqu’un défaut apparaît ?

Ce détail semble petit.

Mais s’il n’est pas défini, le programmeur peut inverser l’alarme.

24. Faut-il privilégier un contact ouvert ou fermé ?

La réponse dépend de la philosophie de surveillance.

Pour certaines informations importantes, une logique permettant de détecter une rupture de liaison peut être intéressante.

Par exemple, si un contact doit être fermé en situation normale et que le câble est coupé, l’automate peut détecter un changement d’état.

Mais cette stratégie ne doit pas être appliquée arbitrairement.

La définition doit être réalisée avec :

• le fournisseur de l’équipement ;
• le concepteur ;
• l’intégrateur.

Ce qui compte est que l’état normal et l’état de défaut soient explicitement documentés.

25. Le problème classique : « contact fourni par qui ? »

C’est l’une des questions les plus fréquentes sur chantier.

Le concepteur écrit :

« Remontée défaut général vers GTB. »

Très bien.

Mais :

Qui fournit le contact ?

Qui programme le relais ?

Qui tire le câble ?

Qui fournit l’entrée automate ?

Qui raccorde ?

Qui teste ?

Si ces questions ne sont pas résolues, le problème apparaît généralement quelques jours avant la mise en service.

26. Les quatre responsabilités à définir pour chaque interface

Pour chaque information externe, définissez au minimum :

1. Qui fournit l’information ?

Exemple : ascensoriste.

2. Sous quelle forme ?

Contact sec, BACnet, KNX, autre interface.

3. Qui réalise la liaison ?

Entreprise électrique, intégrateur ou autre lot.

4. Qui intègre et teste le point ?

Généralement l’intégrateur GTB avec le lot concerné.

Cette simple méthode évite énormément de problèmes.

27. Exemple avec une alimentation sans interruption

Supposons qu’elle fournisse trois informations :

disponible

défaut

mode batterie

Solution A : contacts câblés

Trois contacts.

Trois signaux vers l’automate.

La GTB reçoit :

Disponibilité
Défaut
Batterie

Solution B : BACnet

Une seule communication réseau.

La GTB peut éventuellement obtenir beaucoup plus de données.

La meilleure solution dépend du nombre de points nécessaires et des possibilités de l’équipement.

28. Exemple avec KNX

Supposons que l’installation KNX gère :

• éclairage ;
• stores ;
• station météo ;
• commandes de pièces.

La GTB souhaite uniquement recevoir :

défaut réseau

et

alarme vent.

Si un équipement met déjà à disposition ces informations sous forme de contacts, deux câbles peuvent suffire.

Mais si la GTB doit récupérer :

• état de centaines de stores ;
• valeurs météo ;
• défauts ;
• états d’éclairage ;
• commandes ;

une passerelle devient beaucoup plus intéressante.

29. La passerelle BACnet/KNX doit être prévue dès la conception

Une passerelle n’est pas magique.

Il faut déterminer à l’avance :

• quelles adresses KNX doivent être récupérées ;
• quels objets BACnet doivent être créés ;
• quelle convention de nommage utiliser ;
• qui réalise le paramétrage ;
• qui fournit le fichier KNX ;
• qui réalise les essais.

Sans cette coordination, la passerelle peut être installée mais inutilisable lors de la mise en service.

30. Exemple de correspondance KNX vers BACnet

Imaginons :

KNX :
Alarme vent = adresse de groupe X

La passerelle transforme cette donnée en :

BACnet :
Protection solaire / Alarme vent

La GTB lit ensuite cet objet.

Si l’alarme devient active :

0 → 1

La supervision affiche :

Alarme vent – protections solaires verrouillées

Voilà concrètement le rôle de la passerelle.

31. La liste de points est le document le plus important de l’interface

Pour chaque information, je recommande de définir au minimum :

Pour BACnet, ajoutez notamment :

• objet ;
• instance ;
• accès lecture/écriture ;
• unité ;
• adresse réseau.

Pour KNX :

• adresse de groupe ;
• type de donnée ;
• signification ;
• objet BACnet correspondant si passerelle utilisée.

32. Comment tester les remontées d’alarmes ?

Le simple fait de voir un point sur la supervision ne suffit pas.

Il faut réaliser un test complet.

Prenons :

Défaut système photovoltaïque.

La méthode correcte consiste à provoquer ou simuler le défaut depuis l’équipement source.

Puis vérifier successivement :

1. L’équipement génère le défaut.

↓

2. Le contact ou la donnée numérique change.

↓

3. L’automate reçoit correctement l’information.

↓

4. La GTB affiche la bonne alarme.

↓

5. La priorité est correcte.

↓

6. Le texte est compréhensible.

↓

7. Lorsque le défaut disparaît, l’état revient correctement.

C’est ce qu’on appelle un test de bout en bout.

33. L’erreur la plus fréquente : tester uniquement côté GTB

Un intégrateur peut parfois forcer une entrée dans son logiciel et constater :

« L’alarme apparaît correctement. »

Cela teste uniquement la programmation GTB.

Cela ne prouve pas que :

• le câble est correct ;
• le contact fonctionne ;
• le système externe transmet réellement l’information.

Un vrai test doit partir de l’équipement source.

34. Les erreurs fréquentes lors de l’intégration des autres lots

Plusieurs erreurs reviennent régulièrement.

La première consiste à décider trop tard quelles alarmes doivent être remontées.

La deuxième est de ne pas préciser qui doit fournir le contact.

La troisième est d’indiquer uniquement « interface BACnet » sans demander la liste réelle des objets.

La quatrième consiste à supposer qu’une interface KNX rend automatiquement toutes les données accessibles.

La cinquième est d’oublier de définir les priorités.

La sixième est de ne pas préciser l’état normal des contacts.

La septième est de créer des alarmes incompréhensibles pour l’exploitant.

Et la huitième consiste à ne pas réaliser les tests avec les entreprises responsables des systèmes concernés.

35. Quelle architecture choisir pour un nouveau bâtiment ?

Pour un bâtiment moderne, on peut suivre une logique simple.

Quelques informations seulement

Par exemple :

• alarme incendie ;
• défaut ascenseur ;
• défaut groupe électrogène.

Le contact sec reste souvent une excellente solution.

Beaucoup d’informations sur un équipement communicant

Par exemple :

• centrale technique ;
• ASI ;
• compteur ;
• production énergétique.

Une communication BACnet peut devenir beaucoup plus intéressante.

Un système complet déjà basé sur KNX

Si la GTB doit récupérer de nombreux points, une passerelle KNX vers BACnet ou une intégration KNX native peut être pertinente.

L’objectif n’est donc pas :

« Tout mettre sur BACnet. »

L’objectif est :

choisir l’interface la plus adaptée au nombre de points, au niveau d’information recherché et aux exigences de fiabilité.

36. Architecture type d’une GTB avec plusieurs lots

On peut imaginer l’architecture suivante :

              GTB
               │
          Réseau BACnet/IP
               │
       ┌───────┴─────────┐
       │                 │
 Automate GTB        Passerelle
       │              KNX/BACnet
       │                 │
       │                KNX
       │
Entrées numériques
       │
 ┌─────┼──────────┬─────────┐
 │     │          │         │
Incendie Ascenseur Groupe  Autres
                   électrogène

Dans la même installation, on peut donc avoir :

contacts physiques

BACnet

KNX

sans aucune contradiction.

37. Ce qu’il faut retenir lorsque l’on conçoit les interfaces GTB

La réflexion doit toujours commencer par l’information elle-même.

Demandez-vous :

Que doit savoir l’exploitant ?

Ensuite seulement :

Comment allons-nous récupérer cette information ?

Puis :

Contact câblé ou communication numérique ?

Et enfin :

Qui fournit, qui raccorde, qui programme et qui teste ?

Cette méthode est beaucoup plus fiable que de commencer directement par la technologie.

FAQ – Remontée d’alarmes, BACnet et KNX en GTB

Qu’est-ce qu’une remontée d’alarme GTB ?

C’est la transmission d’un défaut, d’un état ou d’une alarme depuis un équipement technique vers le système de supervision du bâtiment.

Comment remonter une alarme vers la GTB ?

Elle peut être transmise par un contact câblé vers une entrée numérique ou via un protocole de communication tel que BACnet ou KNX.

Qu’est-ce qu’un contact sec ?

C’est un contact électrique fournissant principalement un état ouvert ou fermé sans imposer nécessairement sa propre tension au circuit de lecture.

BACnet évite-t-il de tirer des câbles ?

Il peut réduire considérablement le nombre de câbles individuels de signalisation, mais les équipements doivent toujours être alimentés et raccordés au réseau de communication.

Peut-on connecter KNX à une GTB BACnet ?

Oui. Une passerelle peut traduire certaines informations KNX en objets BACnet afin qu’elles soient récupérées par la supervision.

Une passerelle BACnet/KNX récupère-t-elle automatiquement toutes les informations ?

Non. Les données à échanger doivent être définies et configurées explicitement.

Quels systèmes faut-il remonter dans la GTB ?

Cela dépend du bâtiment. On retrouve souvent les systèmes incendie, intrusion, alimentations de secours, ASI, ascenseurs, photovoltaïque, contrôle d’accès, KNX et certaines installations électriques.

Peut-on utiliser uniquement des contacts secs ?

Oui pour une installation simple ou un nombre limité de points. Lorsque le nombre d’informations devient important, une communication numérique peut être plus efficace.

Pourquoi classer les alarmes par priorité ?

Parce qu’un défaut technique mineur ne doit pas être présenté au même niveau qu’une information critique nécessitant une intervention immédiate.

Qui doit tester les interfaces ?

Les essais doivent idéalement être réalisés conjointement entre l’intégrateur GTB et l’entreprise responsable du système qui fournit l’information.

Conclusion

Une GTB performante ne se limite pas au chauffage, à la ventilation et au refroidissement.

Elle peut devenir le centre de supervision technique du bâtiment.

Elle récupère alors les informations provenant de nombreux systèmes :

incendie

intrusion

alimentation de secours

éclairage de sécurité

désenfumage

alimentation sans interruption

KNX

photovoltaïque

ascenseurs

contrôle d’accès

systèmes électriques

et bien d’autres.

Pour transmettre ces informations, deux solutions principales existent.

La première est le câblage direct :

contact → câble → entrée automate → GTB

La seconde est la communication numérique :

équipement → BACnet ou KNX → réseau ou passerelle → GTB

Il n’est pas nécessaire de choisir exclusivement l’une ou l’autre.

Dans de nombreux bâtiments, la meilleure architecture est hybride.

Les quelques informations critiques peuvent être récupérées par contacts physiques.

Les équipements riches en données peuvent communiquer directement en BACnet.

Et les informations d’un réseau KNX peuvent être reprises par une interface appropriée ou une passerelle BACnet/KNX.

La technologie n’est cependant que la dernière étape.

Le véritable travail de conception consiste d’abord à déterminer :

Quelle information faut-il récupérer ?

D’où vient-elle ?

Comment doit-elle être transmise ?

Quelle est sa priorité ?

Qui fournit l’interface ?

Qui réalise la liaison ?

Qui l’intègre dans la GTB ?

Et surtout : qui vérifie que cela fonctionne réellement ?

Une fois ces questions correctement traitées, les différents lots techniques ne fonctionnent plus comme des installations isolées.

Ils deviennent les différentes sources d’information d’un bâtiment supervisé, compréhensible et exploitable depuis une GTB centrale.