IBMS · Périmètre
Périmètre IBMS — une matrice de sous-systèmes, pas une liste de souhaits
Une méthode pratique pour définir le périmètre IBMS : une matrice de sous-systèmes, une profondeur d’intégration réaliste, des exclusions et des critères d’acceptation.
Réponse rapide
Le périmètre IBMS se définit par une matrice de sous-systèmes : pour chaque système, indiquez s’il est surveillé, piloté, inclus dans des interverrouillages inter-systèmes ou seulement rapporté. Les systèmes de sécurité incendie et de sûreté restent généralement sous leur propre contrôle, l’IBMS supervisant les états et les événements plutôt que d’émettre des commandes.
Le périmètre est une matrice, pas une liste
Une liste de sous-systèmes indique ce qui est raccordé. Une matrice indique ce que chaque raccordement est autorisé à faire. Utilisez des lignes pour les systèmes et des colonnes pour la surveillance, le pilotage, le traitement des alarmes, l’interverrouillage inter-systèmes et le reporting. Ajoutez des colonnes pour le responsable de l’interface et le test d’acceptation. La matrice révèle les lacunes avant qu’elles ne deviennent des avenants : un système marqué comme piloté mais sans interface accessible en écriture, ou un interverrouillage qui dépend d’un point que personne ne fournit. Elle donne aussi à l’exploitant une vision réaliste de ce que la plateforme fera et ne fera pas. Une matrice sans colonne de responsabilité est un schéma d’intentions. Gardez la colonne du test d’acceptation visible lors des revues de conception ; elle transforme une promesse en livrable.
Une profondeur réaliste par sous-système
La CVC prend généralement en charge la surveillance et le pilotage complets. L’éclairage peut prendre en charge des scénarios et des horaires, mais tous les groupes de luminaires ne justifient pas un pilotage individuel. Les compteurs d’énergie sont en surveillance seule, la profondeur de reporting étant déterminée par le compteur et la passerelle. Le contrôle d’accès peut partager des événements et des autorisations, tandis que le système de contrôle d’accès conserve sa propre logique de décision. La détection incendie est en surveillance seule pour les états et les événements ; les commandes restent au système incendie. Les ascenseurs, le stationnement et les chambres d’hôtel varient fortement. La bonne profondeur est celle que l’exploitant utilisera réellement, pas le maximum autorisé par le protocole. Le pilotage des chambres d’hôtel peut inclure des scénarios et des limites d’énergie, tandis que le PMS de l’hôtel conserve son propre flux de travail. Chaque décision de profondeur doit être justifiée par un scénario d’exploitation, pas par une liste de capacités du protocole.
Ce qu’il faut exclure
Excluez tout ce qui ne peut pas être maintenu après la réception. Cela inclut les contrôleurs obsolètes sans interface documentée, les portails fournisseurs qui exigent un compte personnel et les systèmes dont le seul chemin d’intégration contourne leurs limites de sécurité. Les commandes de sécurité des personnes doivent rester au système de sécurité des personnes lui-même. Évitez d’intégrer un sous-système uniquement pour afficher une valeur sur un tableau de bord ; l’interface, la passerelle et la charge de maintenance survivront à la nouveauté. Une liste d’exclusions claire protège le projet autant qu’une liste d’inclusions claire. Chaque exclusion doit avoir une raison et une conséquence, afin que le client puisse l’accepter en connaissance de cause. Si un sous-système n’a pas d’interface stable, un processus manuel documenté est souvent la réponse honnête.
Rédiger l’énoncé de périmètre
Transformez la matrice en un énoncé de périmètre comportant quatre parties : inclusions, exclusions, responsabilités d’interface et tests d’acceptation. Nommez le protocole, le responsable de la passerelle, la base de comptage des points et la propriété des données. Indiquez ce qui se passe lorsqu’une interface est indisponible. Définissez le test qui prouve chaque ligne et exigez le résultat dans le dossier de réception. Révisez l’énoncé à chaque étape de conception, car le périmètre s’étend discrètement au fil des questions de chantier. Le document doit être assez court pour être lu en une réunion et assez précis pour être chiffré. Utilisez les mêmes termes que les documents d’appel d’offres, afin que le périmètre puisse être comparé ligne par ligne. Lorsqu’une question modifie le périmètre, consignez la modification et son coût avant de poursuivre.
Profondeur d’intégration IBMS typique par sous-système
7 rows| Sous-système | Profondeur typique | Frontière |
|---|---|---|
| HVAC | Surveillance et pilotage | Les séquences restent dans les contrôleurs DDC |
| Éclairage | Scénarios, horaires et états | L’éclairage de sécurité reste sur son propre système |
| Comptage d’énergie | Surveillance et reporting | Exactitude du compteur et responsabilité de la passerelle |
| Contrôle d’accès | Événements et autorisations | Les décisions d’accès restent au système de contrôle d’accès |
| CCTV | Événements et flux sélectionnés | Règles de confidentialité et de conservation |
| Alarme incendie | États et événements uniquement | Les commandes restent au système incendie |
| Ascenseurs et stationnement | États, alarmes et disponibilité | Interface fournisseur et limites de sécurité |
Images du projet
3 images
Questions fréquentes
01L’IBMS doit-il piloter le système de détection incendie ?
Non. La détection incendie et les autres systèmes de sécurité des personnes conservent leur propre contrôle dédié. L’IBMS peut surveiller les états et les événements et les afficher aux côtés des autres alarmes.
02Combien de sous-systèmes un IBMS doit-il intégrer ?
Il n’y a pas de nombre cible. Intégrez les systèmes qui étayent une décision que l’exploitant prend réellement ; laissez les autres de côté jusqu’à ce qu’un cas d’usage réel apparaisse.
03Peut-on ajouter un sous-système plus tard ?
Oui, si le modèle de données, le nommage et le réseau sont conçus pour cela. L’ajout ultérieur d’un sous-système non documenté est bien plus difficile que celui d’un système doté d’une interface stable.
04Qui est responsable de la passerelle ?
Une seule partie devrait l’être. L’énoncé de périmètre doit nommer qui fournit, configure, teste et maintient la passerelle, y compris les mises à jour de firmware et les unités de rechange.
05Qu’est-ce qui prouve que le périmètre est complet ?
Une matrice signée avec un résultat de test d’acceptation pour chaque ligne, plus une liste d’exclusions acceptée par le client et l’exploitant.
É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.