Un module DIN-rail parlant MQTT vers le cloud, BACnet vers le bâtiment, et Modbus TCP vers les machines. Cette phrase était utilisée pour décrire un panneau plein de passerelles. Elle décrit maintenant un seul CPU compact capable d'Ethernet, et l'histoire multi-protocole sur la plateforme xLogic n'est pas une diapositive marketing — elle est dans le firmware, documentée à travers les révisions du manuel : MQTT depuis V1.04, BACnet depuis V1.57, Modbus depuis le premier jour.
Voici comment utiliser cela sans créer un cauchemar de maintenance.
La Carte des Protocoles
Chaque protocole a son public naturel, et le truc est de les garder séparés :
- Modbus TCP— le sol des machines : VFDs, HMIs, SCADA, autres PLCs. Déterministe, basé sur les registres, la poignée de main industrielle universelle
- MQTT— le cloud : publier des télémétries à un courtier, les tableaux de bord s'abonnent. Orienté événements, amical avec le NAT, conçu pour des réseaux peu fiables
- BACnet— le bâtiment : salles des machines, AHUs, têtes de BMS. La langue natale de l'industrie immobilière
Un CPU servant les trois publics signifie que le constructeur de machines, le gestionnaire des installations et le tableau de bord cloud voient le même appareil — chacun dans sa propre langue, aucun d'eux n'ayant besoin d'une boîte de conversion.
Bâtiment Réel : Petite Salle de Machines
Une salle de machines avec une AHU, deux groupes de ventilo-convecteurs et une pompe à chaleur : Modbus TCP vers le HMI local et les VFD, BACnet vers le BMS du bâtiment pour la planification et les alarmes, MQTT vers un service cloud pour le suivi à distance. Trois protocoles, un contrôleur, un programme. L'ingénieur BMS a demandé qui fabriquait la passerelle. La réponse — "il n'y a pas de passerelle" — a valu un silence qui a duré cinq secondes.
Ce silence est le produit qui fonctionne.
Ce qu'il faut garder séparé
Les protocoles peuvent partager le CPU, mais ils ne devraient pas partager le plan de données. Cartographiez les points une fois, délibérément : quels registres sont visibles Modbus, quels objets sont BACnet, quels sujets sont MQTT. Une seule carte de points, maintenue dans un tableau, empêche l'échec classique — un numéro de registre changeant et trois systèmes devenant silencieusement obsolètes.
Et rappelez-vous les limites des modèles : BACnet/IP et MQTT ont besoin des CPUs capables d'Ethernet. Les modèles uniquement série conservent Modbus RTU et BACnet/MSTP. Vérifiez le modèle par rapport à l'exigence avant la promesse, pas après le bon de commande.
L'Angle de Support Que Personne Ne Tarife
Le multi-protocole n'est pas juste une fonctionnalité ; c'est une porte de vente. Les appels d'offres demandent maintenant l'intégration BMS comme standard, la connectivité cloud comme élément de liste de contrôle. Un contrôleur qui répond aux deux sans ajouts passe le filtre de pré-qualification. La différence de prix entre les versions mono-protocole et multi-protocole est faible ; la différence dans les projets sur lesquels vous êtes autorisé à soumissionner ne l'est pas.
Discipline de la Carte des Points
Le multi-protocole est une bénédiction et un piège. La bénédiction : un CPU servant trois systèmes. Le piège : trois systèmes lisant des versions légèrement différentes de la vérité. La solution est ennuyeuse et non négociable — une seule carte de points qui liste chaque valeur une fois, avec son registre, son objet BACnet, et son sujet MQTT dans la même ligne.
Commencez le tableau dès le premier jour, avant que le premier bloc ne soit câblé. Colonnes : nom de la valeur, registre Modbus, type et instance d'objet BACnet, sujet MQTT, type de données, mise à l'échelle, fréquence de mise à jour, et quel système est autoritaire pour les écritures. La dernière colonne compte plus que ce que les gens pensent — lorsque le BMS et le tableau de bord cloud veulent tous deux changer un point de consigne, quelqu'un doit gagner, et la carte indique qui. Sans cela, deux systèmes se battent pour une valeur et la machine se comporte de manière imprévisible à 3 heures du matin.
Versionnez la carte avec le programme. Chaque changement de firmware, chaque point ajouté, chaque renumérotation — la carte se met à jour dans le même commit. J'ai hérité de projets où la carte était obsolète de deux ans et trois personnes avaient des copies différentes. La reconstruire a pris une semaine à regarder des tableaux de registres. Une semaine. Ne soyez pas ce projet.
Et testez les chemins inter-protocoles délibérément : écrivez un point de consigne depuis le BMS, vérifiez que la machine répond, vérifiez que le tableau de bord cloud montre le changement. Un test de bout en bout par point, lors de la mise en service, attrape les erreurs de cartographie pendant qu'elles sont peu coûteuses à corriger.
Réalité du Firmware et de la Version
Les fonctionnalités du protocole sont arrivées par vagues, et l'historique des révisions du manuel raconte l'histoire : MQTT en 4.2, le serveur web en 4.5, les instructions WiFi en 6.0, BACnet en 6.2, support SR-22 en 6.2.1. Si vous prévoyez un projet multi-protocole, la version du firmware n'est pas un détail — c'est une exigence. Un CPU expédié il y a deux ans peut nécessiter une mise à jour avant de parler BACnet, et le chemin de mise à jour dépend du modèle.
Faites de la vérification du firmware une partie de la liste de contrôle de pré-vente. Notez la version sur la commande, confirmez-la à la livraison, et documentez-la sur la feuille de mise en service. La conversation la plus coûteuse dans ce secteur est "cela devrait le supporter" suivie de "celui-ci ne le fait pas."
Et gardez les protocoles honnêtes sur leurs forces. BACnet pour le bâtiment, Modbus pour les machines, MQTT pour le cloud — chacun sur le type de fil pour lequel il a été conçu. Le CPU Ethernet gère les trois simultanément ; il ne les transforme pas magiquement en un seul protocole, et il ne devrait pas. La séparation est ce qui maintient l'usine en fonctionnement lorsque le lien cloud tombe — le trafic Modbus et BACnet local n'attend pas l'internet.
L'Habitude de Documentation des Protocoles
Un contrôleur à trois protocoles sans carte de protocole est une exposition de musée. La discipline coûte une heure lors de la mise en service et économise une semaine chaque fois que le bâtiment change : une feuille listant chaque point, son registre Modbus, son objet BACnet, et son sujet MQTT — avec l'autorité d'écriture marquée. La feuille vit avec les dessins du panneau, versionnée avec le programme. Lorsque l'ingénieur BMS demande "quelle valeur est la température d'alimentation ?" la réponse est une ligne, pas un après-midi d'archéologie de registre.
Achetez la version avec les protocoles. Les projets suivront.
