Scénarios · Multi-sites
IBMS multi-sites : une vision d’exploitation unique pour plusieurs bâtiments
Comment concevoir un IBMS multi-sites doté d’un modèle de données commun, d’une autonomie locale et d’une couche centrale qui résiste aux coupures réseau.
Réponse rapide
Un IBMS multi-sites offre au parc un modèle de données, un modèle d’alarme et une couche de reporting uniques, tandis que chaque bâtiment conserve sa commande locale. Les sites exécutent leurs propres séquences et stockent leur propre historique ; le centre compare les performances, diffuse les standards et gère les accès, mais n’est pas nécessaire à l’exploitation quotidienne.
Ce qu’exige réellement une vision d’exploitation unique
Un tableau de bord de parc n’est pas un IBMS multi-sites. Le plus difficile est de convenir de ce que signifie un point d’un bâtiment à l’autre : le même nom pour la température extérieure, les mêmes unités, la même gravité d’alarme, le même traitement des fuseaux horaires et la même définition de l’occupation. Sans ce modèle, le centre reçoit des données qu’il ne peut pas comparer et les exploitants passent leur temps à réconcilier des définitions. Le modèle doit être rédigé avant la configuration du premier site, avec une convention de nommage, un dictionnaire d’objets et une règle pour les extensions propres à un site. La standardisation de cette couche rend le reporting de parc crédible et accélère aussi la mise en service d’un nouveau site.
Autonomie locale et couche centrale
Chaque site doit rester pleinement exploitable lorsque la liaison étendue est coupée. Les contrôleurs de site exécutent les séquences de CVC, d’éclairage, de protection solaire et de comptage, et conservent suffisamment d’historique pour survivre à une coupure. La couche centrale agrège, visualise, produit des rapports et gère les utilisateurs. Elle peut aussi diffuser les mises à jour du modèle, mais celles-ci doivent être progressives et réversibles. Cette division maintient la sécurité et le confort en local tout en donnant à la direction une vue de parc. Elle limite aussi le rayon d’impact d’une défaillance centrale et facilite la sécurisation de l’architecture réseau. La plateforme centrale peut être mise à niveau sans toucher à la logique de commande des sites. Le test est simple : déconnectez un site et confirmez que le bâtiment fonctionne toujours, que les alarmes sont toujours enregistrées et que l’historique n’est pas perdu.
Standardiser le modèle, documenter le profil de site
Un parc a besoin d’un modèle commun : synoptiques, nommage des points, classes d’alarme, objets d’horaire, définitions de rapports et rôles utilisateurs. Il a aussi besoin d’un profil de site pour ce qui diffère légitimement : type d’installation, climat, horaires d’ouverture, comptage locatif, réglementations locales et topologie réseau. Le modèle doit être versionné, et chaque site doit consigner la version qu’il exécute. Lorsqu’un site nécessite un écart, consignez-le et décidez s’il doit être intégré à la version suivante du modèle. Cela évite la divergence progressive qui transforme un parc en un ensemble de systèmes sans lien. Cela donne aussi à l’équipe centrale un moyen de déployer une amélioration sans réingénierie manuelle de chaque bâtiment.
Déploiement, sécurité et gouvernance
Déployez par vagues, avec un site de référence qui valide le modèle avant sa réplication. Définissez qui peut modifier les consignes, qui peut acquitter les alarmes et qui peut ajouter des utilisateurs à chaque niveau. Segmentez les réseaux du bâtiment par rapport à l’informatique de l’entreprise, exigez des comptes nominatifs et maintenez une politique de correctifs et de firmware couvrant les contrôleurs, les passerelles et la plateforme centrale. Testez un site isolément, puis testez la vue de parc, y compris ce qui se passe lorsqu’un site est hors ligne. La gouvernance n’est pas de la paperasse : c’est ce qui distingue un système qui reste comparable d’un système qui se fragmente insidieusement. Le modèle d’exploitation doit nommer les responsables de chaque couche et la fréquence de revue des performances. Un court rapport mensuel suffit à maintenir la visibilité du parc.
Couches d’un IBMS multi-sites
7 rows| Couche | Fonction | Décision de conception |
|---|---|---|
| Commande de site | Séquences de CVC, d’éclairage, de protection solaire et de comptage | S’exécute localement et résiste à une coupure WAN |
| Historique de site | Stockage des tendances et journal des alarmes | Conserve suffisamment de données pour l’exploitation locale et le téléversement ultérieur |
| Agrégation centrale | Tableaux de bord et rapports de parc | Lit un modèle de données commun, et non les points bruts des fournisseurs |
| Gestion des alarmes | Acheminement et escalade entre sites | Distingue les alarmes critiques de parc des alarmes de nuisance locales |
| Accès utilisateurs | Rôles et permissions | Applique le moindre privilège au niveau du site et du central |
| Gestion du modèle | Synoptiques, séquences et nommage standardisés | Versionne le modèle et consigne la version de chaque site |
| Réseau et sécurité | Segmentation, accès à distance, correctifs | Maintient les réseaux du bâtiment séparés de l’informatique de l’entreprise |
Images du projet
3 images
Questions fréquentes
01Tous les sites ont-ils besoin du même BMS ?
Ils ont besoin d’un modèle de données et d’une couche de reporting communs. Le matériel des sites peut différer si le modèle définit la manière dont les points, les alarmes et l’historique sont exposés.
02Que se passe-t-il lorsqu’un site perd sa connexion ?
Le site continue de fonctionner en commande locale et stocke l’historique localement. Le centre doit afficher le site comme hors ligne et réinjecter les données au retour de la liaison.
03À qui appartiennent les données ?
Le maître d’ouvrage doit l’être. Les contrats doivent préciser où les données sont stockées, comment elles sont exportées et ce qui se passe à la fin d’un contrat de service.
04Comment gérer les différents fuseaux horaires ?
Stockez les horodatages avec un fuseau horaire explicite et synchronisez les horloges. Les rapports doivent indiquer s’ils utilisent l’heure locale ou l’heure centrale.
05Peut-on ajouter un nouveau site ultérieurement ?
Oui, si le modèle est versionné et si le nouveau site est profilé par rapport à celui-ci. Le coût et l’effort dépendent de l’écart entre le site et le standard.
Étape suivante
Apportez-nous le bâtiment.
Indiquez le type de bâtiment, les systèmes concernés et le résultat dont vous avez besoin. Nous tracerons le chemin le plus court vers un système opérationnel.