Un IBMS est souvent décrit comme « une plateforme qui connecte tout ». Cette description est vraie et inutile. La question utile est de savoir où la connexion se produit, qui possède les données et ce qui se passe lorsqu’un sous-système se comporte mal.
Nous appliquons un modèle à trois couches sur chaque projet : équipement, supervision et application. Il provient du modèle d’intégration distribuée utilisé dans le cahier des charges à l’origine de cette pratique, et il a résisté au contact de bâtiments réels parce qu’il maintient les responsabilités explicites.
Pourquoi une architecture plate vaut mieux qu’une architecture profonde
Chaque passerelle, traducteur de protocole ou saut d’intergiciel supplémentaire ajoute de la latence, un point de défaillance et un endroit où le modèle de données peut dériver. Une architecture plate réduit le nombre de traductions entre un capteur et la personne qui doit agir.
Plate ne signifie pas « sans hiérarchie ». Cela signifie que la hiérarchie est fonctionnelle, non accidentelle : des contrôleurs en périphérie, un cœur de supervision unique et des applications qui lisent ce cœur plutôt que de construire leurs propres bases de données miroir.
Couche 1 : équipement
La couche équipement est celle où le contrôle physique a lieu. Les contrôleurs et modules d’E/S Loxone exécutent des séquences locales, lisent les capteurs et pilotent les actionneurs. Les systèmes tiers se connectent via des passerelles ou des interfaces natives : BACnet/IP pour les installations techniques, Modbus pour les compteurs et onduleurs, KNX pour l’éclairage et la protection solaire, DALI pour les luminaires, contacts secs pour le feu et les équipements anciens.
La décision de conception importante n’est pas de savoir quel protocole gagne. Elle porte sur le contrôleur qui possède chaque séquence et sur ce qui se passe lorsque la couche de supervision est hors ligne. Le contrôle local doit être suffisamment complet pour que le bâtiment reste sûr et utilisable.
Couche 2 : supervision
La couche de supervision est le cœur de l’intégration. Elle normalise chaque sous-système dans un modèle d’objet commun : un point possède une identité, une unité, un indicateur de qualité, un état d’alarme et un historique. Une porte est une porte, qu’elle provienne d’un contrôleur d’accès ou d’un PLC. Une température est une température, qu’elle arrive par BACnet ou par Modbus.
C’est ici que résident les interverrouillages intersystèmes. Le contrôle d’accès ouvre une salle ; l’éclairage, le CVC et la vidéosurveillance réagissent. L’interverrouillage est configuré dans la couche de supervision, et non câblé en dur entre les contrôleurs de fournisseurs. Il devient ainsi visible, testable et modifiable.
Ce que la couche de supervision doit posséder
- Un modèle d’alarme unique avec priorité, acquittement et escalade.
- Un modèle d’horaires auquel il est possible de déroger sans modifier le code du contrôleur.
- Une piste d’audit des commandes, des consignes et des acquittements.
- Un modèle d’historique stockant les données d’intervalle à une résolution connue.
- Une convention de nommage qui survit à la réception.
Couche 3 : application
La couche application est ce que les gens voient. Elle doit être conçue pour des rôles, non pour la démonstration de l’intégrateur : une vue opérateur qui fait ressortir ce qui demande attention, une vue ingénieur qui expose les points et les tendances, une vue direction qui rend compte des résultats.
Les applications lisent le cœur de supervision. Elles n’interrogent pas directement les sous-systèmes et ne conservent pas leur propre copie de la vérité. Cette règle évite le mode de défaillance classique où le tableau de bord et la GTB ne sont pas d’accord.
Un exemple concret
Un locataire entre dans un étage à 07:40. Le contrôleur d’accès signale l’événement. La couche de supervision vérifie l’horaire du locataire et l’état d’occupation de l’étage. Elle déclenche la scène d’éclairage, lance la séquence CVC et demande à la vidéosurveillance de marquer l’événement d’entrée. L’opérateur voit un événement, pas quatre.
Si un comportement intersystème ne peut pas être décrit en une phrase, il appartient probablement à une séquence documentée, pas à un script caché.
Ce qu’il faut prescrire
| Exigence | Pourquoi elle compte |
|---|---|
| Indépendance du contrôle local | Le bâtiment doit rester sûr et utilisable pendant une panne réseau ou cloud. |
| Liste de protocoles ouverts | Empêche un fournisseur unique de devenir le seul accès aux données du bâtiment. |
| Modèle d’alarme unique | Évite les alarmes en double et rend l’escalade auditable. |
| Convention de nommage des points | Rend possibles la réception, la maintenance et l’intégration future. |
| Conservation et export de l’historique | Les affirmations en matière d’énergie et de performance exigent une traçabilité défendable. |
Un modèle à trois couches n’est pas un schéma produit. C’est un schéma de responsabilités. Si vous ne pouvez pas dire quelle couche possède un comportement, ce comportement est probablement au mauvais endroit.
À retenir
L’architecture IBMS ne consiste pas à connecter le plus de systèmes possible. Elle consiste à rendre les connexions lisibles : un modèle de données, un modèle d’alarme, une piste d’audit et un contrôle local qui survit au réseau. Réussissez ces points et le tableau de bord devient facile. Ratez-les et aucun tableau de bord ne sauvera le projet.
