BACnet et Modbus dans un même bâtiment : la stratégie de mapping par passerelle
Quand le BMS parle BACnet mais que le chiller, les variateurs et les compteurs d'énergie du site ne parlent que Modbus RTU ou Modbus TCP, la solution n'est pas un second superviseur, mais un mapping documenté via une passerelle BACnet/Modbus.
Comment nous planifions le mapping
Auditer chaque appareil Modbus
Nous listons chaque chiller, variateur, compteur et régulateur du site et récupérons sa table de registres -- adresse, type de donnée, échelle et function code -- directement dans la documentation constructeur, pas par hypothèse.
Élaborer la liste d'objets BACnet
Pour chaque registre, on décide s'il devient un AI (mesure) ou un AV/BV (point commandable), et la convention Object_Name est validée avant toute configuration de la passerelle.
Configurer la passerelle et attribuer les droits d'écriture
La traduction registre-vers-objet est programmée dans la passerelle, et on consigne quel appareil unique -- BMS ou régulateur local -- détient le droit d'écriture sur chaque point.
Mise en service et vérification dans le BMS
Avant réception, on vérifie le Present_Value de chaque objet mappé, on contrôle les Status_Flags en cas de perte de communication, et on confronte la liste de points à la table de registres Modbus d'origine.
Ce que le mapping doit garantir
Chaque registre Modbus devient un objet BACnet natif
Une passerelle correctement configurée expose chaque registre holding ou input Modbus comme un objet BACnet distinct -- généralement Analog Input pour les mesures, Analog Value ou Binary Value pour les points commandables -- si bien que toute la liste de points Modbus apparaît dans les graphiques du BMS comme un appareil BACnet natif ordinaire.
Une table de registres, pas des suppositions
Modbus n'a pas de modèle d'objets auto-descriptif -- l'adresse du registre, le type de donnée et le facteur d'échelle doivent être documentés depuis le manuel de l'appareil avant qu'un objet ne soit créé sur la passerelle.
Le type d'objet correspond au point
Les mesures deviennent des Analog Input ; les consignes commandables et les points marche/arrêt deviennent des Analog Value ou Binary Value, selon les mêmes conventions Present_Value et Status_Flags que les appareils BACnet natifs.
Une seule convention de nommage, pas d'AI-1/BO-14
Les objets générés par la passerelle héritent du nom donné par l'intégrateur -- sans la même convention étage-système-point que sur les appareils BACnet natifs, les graphiques du BMS deviennent illisibles.
Un seul appareil détient chaque droit d'écriture
On décide en amont si le BMS ou un régulateur local a le droit d'écrire sur un point mappé -- le Priority_Array résout les conflits entre clients BACnet, mais pas un conflit entre une écriture BACnet et une écriture Modbus sur le même registre.
Vérifier le PICS de la passerelle avant câblage
Le PICS propre à la passerelle indique précisément quels types d'objets et services BACnet elle prend en charge en tant que serveur -- à vérifier avant de concevoir le mapping, pas après.
Ce que contient le dossier de mapping
Une documentation qu'un installateur, un intégrateur ou une équipe d'exploitation peut reprendre et réutiliser.
- Table de registres Modbus pour chaque appareil source (adresse, type de donnée, échelle, function code)
- Liste d'objets BACnet cible avec convention Object_Name et Description validée
- Tableau des droits d'écriture indiquant quel appareil écrit sur quel point
- Fiche de configuration de la passerelle avec vérification croisée du PICS
- Checklist de mise en service pour vérifier Present_Value et Status_Flags après démarrage
Questions fréquentes
Un BMS BACnet peut-il dialoguer directement avec des appareils Modbus RTU ?
Non -- BACnet et Modbus sont deux protocoles distincts avec des modèles d'objets différents. Une passerelle BACnet/Modbus s'intercale entre eux, interroge l'appareil Modbus et expose chaque registre comme un objet BACnet, si bien que le BMS lui-même ne parle jamais Modbus.
Quel type d'objet BACnet donner à un registre holding Modbus ?
Cela dépend du point, pas du type de registre. Une mesure en lecture seule devient généralement un Analog Input ; un registre que le BMS doit écrire devient un Analog Value ou Binary Value, selon l'usage réel du point.
Quel côté doit détenir le droit d'écriture sur un point mappé ?
Un seul appareil doit détenir le droit d'écriture -- soit le BMS via la passerelle, soit un régulateur local directement sur l'appareil Modbus. Cela se documente point par point ; si les deux côtés écrivent sur le même registre, cela provoque des conflits intermittents difficiles à diagnostiquer.
Faut-il un BBMD pour ce type de montage avec passerelle ?
Seulement si la passerelle et le serveur BMS sont sur des sous-réseaux IP différents et que les diffusions BACnet/IP -- Who-Is/I-Am -- doivent franchir cette frontière. Une passerelle sur le même sous-réseau que le serveur BMS n'en a généralement pas besoin.
En quoi cela diffère-t-il d'un pont OPC-UA ?
Une passerelle BACnet/Modbus est une traduction directe et dédiée entre deux protocoles de terrain. L'OPC-UA s'ajoute généralement comme couche d'intégration plus large lorsqu'un troisième système -- SCADA, un MES ou une plateforme d'analyse -- a aussi besoin des mêmes données ; voir notre page sur le pont OPC-UA / BACnet / Modbus pour ce cas de figure.
Vous intégrez des appareils Modbus dans un BMS BACnet ?
Envoyez-nous la liste des appareils -- nous vous aidons à planifier le mapping registres-objets avant la configuration de la passerelle.