Un jumeau numérique CVC est un modèle logiciel vivant de vos centrales de traitement d'air (CTA), groupes froids et pompes, alimenté par des données réelles de capteurs, qui permet de voir comment l'installation se comporte et où elle gaspille de l'énergie. Dans cet article, vous en concevrez un de bout en bout : récupération des points depuis les automates BACnet, publication via MQTT, structuration de l'arborescence des topics et analyses qui détectent le chauffage et le refroidissement simultanés, un faible delta-T sur les groupes froids et la dérive des consignes. Tout repose sur des outils ouverts et un broker MQTT standard.
Pourquoi la CVC se prête naturellement au jumeau numérique
Le chauffage, la ventilation et la climatisation figurent généralement parmi les plus gros consommateurs d'énergie des bâtiments tertiaires, et une grande partie du gaspillage est invisible. Une vanne qui fuit, un registre d'économiseur bloqué fermé ou un groupe froid fonctionnant avec un mauvais écart de température déclenchent rarement une alarme dans la gestion technique du bâtiment (GTB). Le bâtiment reste confortable pendant que le compteur d'énergie grimpe discrètement.
Un jumeau numérique rend ces problèmes visibles en combinant trois éléments :
- Des données en direct de chaque point pertinent : températures, pressions, positions de vannes et de registres, vitesses et puissances des ventilateurs.
- Un modèle du comportement attendu de chaque équipement : delta-T de conception, puissance de ventilateur attendue à une vitesse donnée, séquence de fonctionnement.
- Une logique de comparaison qui signale l'écart entre comportement attendu et comportement réel.
Le jumeau ne remplace pas la GTB. La GTB continue de piloter l'installation ; le jumeau observe, analyse et conseille. Si le concept est nouveau pour vous, commencez par notre guide de référence sur la technologie du jumeau numérique.
Architecture de référence
BACnet/IP controllers (AHU, chiller, VAV, meters)
|
| BACnet ReadProperty / COV
v
BACnet-to-MQTT gateway (edge PC, industrial gateway or Node-RED)
|
| MQTT over TLS, port 8883
v
Cloud MQTT broker (ConnectMQ)
|
+--> Python analytics service (subscriber) -> publishes KPIs and faults
+--> Dashboards and 3D views (WebSocket, port 8084)
+--> Time-series database via Telegraf or a custom subscriber
La passerelle est le seul composant qui parle BACnet. Tout ce qui se trouve au-dessus parle MQTT, ce qui découple analyses, tableaux de bord et stockage du réseau du bâtiment. Plusieurs passerelles du commerce et options open source peuvent interroger des objets BACnet et les publier sous forme de messages MQTT ; Node-RED avec un nœud BACnet communautaire est un choix courant pour les pilotes.
Gardez la passerelle en lecture seule au début. Réécrire des consignes dans la GTB est possible, mais cela doit venir plus tard, une fois que les recommandations du jumeau ont gagné la confiance des équipes, et avec une gestion des changements appropriée.
Les points à collecter
Inutile de récupérer tous les points de la GTB. Commencez par ceux qui pèsent sur l'énergie et le confort :
| Équipement | Points clés | Ce qu'ils révèlent |
|---|---|---|
| Centrale de traitement d'air | Température de soufflage, de reprise, d'air mélangé, d'air extérieur | Performance de l'économiseur, chauffage et refroidissement simultanés |
| Centrale de traitement d'air | Positions des vannes froid et chaud, position du registre d'air neuf | Vannes qui fuient, registres bloqués |
| Centrale de traitement d'air | Vitesse et puissance du ventilateur de soufflage, pression statique en gaine, pression différentielle du filtre | Énergie des ventilateurs, possibilités de réduction de la pression statique, encrassement des filtres |
| Groupe froid | Températures de départ et de retour d'eau glacée, températures d'eau de condensation, puissance (kW), état | Efficacité (kW par tonne), syndrome du faible delta-T |
| Pompes | Vitesse, puissance, pression différentielle | Surpompage, vannes qui se contrarient |
| Zones et VAV | Température de zone, consigne, débit d'air, position du registre | Zones déviantes qui pilotent tout le système |
Un intervalle de relevé pratique pour la plupart de ces points est d'une minute. Les valeurs qui évoluent rapidement, comme la puissance des ventilateurs, peuvent utiliser des abonnements COV (change-of-value) côté BACnet, avec une bande morte pour que la passerelle n'inonde pas le broker.
Conception des topics pour un jumeau numérique CVC
Une hiérarchie de topics cohérente permet au jumeau, aux tableaux de bord et aux analyses de trouver les données sans configuration point par point. Une structure de type ISA-95 fonctionne bien aussi pour les bâtiments : entreprise, site, zone, équipement.
acme/hq-building/plant/chiller-1/telemetry
acme/hq-building/plant/chwp-1/telemetry
acme/hq-building/floor-3/ahu-3/telemetry
acme/hq-building/floor-3/ahu-3/faults
acme/hq-building/floor-3/ahu-3/kpi
Regroupez les points liés d'un même équipement dans un seul message JSON, publié à l'intervalle de relevé :
{
"ts": "2026-10-16T09:42:00Z",
"sat": 13.1,
"rat": 23.4,
"mat": 17.9,
"oat": 9.6,
"clg_valve": 42,
"htg_valve": 18,
"oa_damper": 20,
"fan_speed": 78,
"fan_kw": 11.2,
"filter_dp": 185
}
Les groupes froids suivent le même modèle avec des champs comme chws et chwr (températures de départ et de retour d'eau glacée), flow_lps (débit en litres par seconde), kw et status, sur lesquels s'appuient les analyses ci-dessous.
Utiliser un message par équipement plutôt qu'un message par point garde les horodatages alignés, ce qui compte lorsque vos règles comparent plusieurs valeurs au même instant. ConnectMQ reconnaît les hiérarchies de topics de type ISA-95, si bien que la vue des appareils du portail regroupe les équipements par niveau. Notre article sur les jumeaux numériques ISA-95 détaille le modèle de nommage.
Des analyses qui détectent le gaspillage d'énergie
La valeur du jumeau vient de règles simples et explicables. Le service Python ci-dessous s'abonne à toutes les CTA et à tous les groupes froids du bâtiment, applique trois contrôles classiques et republie les résultats sur MQTT, où tableaux de bord et règles d'alerte peuvent les récupérer.
import json
import time
import paho.mqtt.client as mqtt
BROKER = "broker.connectmq.com"
PORT = 8883
SITE = "acme/hq-building"
DESIGN_CHW_DELTA_T = 5.5 # degrés C, d'après les données de conception du groupe froid
VALVE_OVERLAP_PCT = 10 # les deux vannes ouvertes au-delà de cette valeur = gaspillage
ECON_OAT_MAX = 15.0 # free cooling attendu en dessous de cette température extérieure
def check_ahu(asset, d):
faults = []
if d["clg_valve"] > VALVE_OVERLAP_PCT and d["htg_valve"] > VALVE_OVERLAP_PCT:
faults.append("simultaneous_heating_cooling")
if d["oat"] < ECON_OAT_MAX and d["clg_valve"] > 20 and d["oa_damper"] < 30:
faults.append("economizer_not_used")
if d["filter_dp"] > 250:
faults.append("filter_loaded")
return {"faults": faults, "fan_kw": d["fan_kw"]}
def check_chiller(asset, d):
delta_t = d["chwr"] - d["chws"]
tons = d["flow_lps"] * 4.19 * delta_t / 3.517 # kW thermiques convertis en tonnes de réfrigération
kw_per_ton = d["kw"] / tons if tons > 1 else None
faults = []
if d["status"] == "on" and delta_t < 0.6 * DESIGN_CHW_DELTA_T:
faults.append("low_delta_t")
return {"delta_t": round(delta_t, 2),
"kw_per_ton": round(kw_per_ton, 3) if kw_per_ton else None,
"faults": faults}
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe(f"{SITE}/+/+/telemetry", qos=1)
def on_message(client, userdata, msg):
parts = msg.topic.split("/")
area, asset = parts[2], parts[3]
data = json.loads(msg.payload)
if asset.startswith("ahu"):
result = check_ahu(asset, data)
elif asset.startswith("chiller"):
result = check_chiller(asset, data)
else:
return
base = f"{SITE}/{area}/{asset}"
client.publish(f"{base}/kpi", json.dumps(result), qos=1, retain=True)
if result["faults"]:
client.publish(f"{base}/faults", json.dumps({"ts": time.time(), "faults": result["faults"]}), qos=1)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set() # le magasin de CA du système fait confiance au certificat Let's Encrypt du broker
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, PORT, keepalive=60)
client.loop_forever()
Les trois contrôles ciblent des problèmes énergétiques CVC bien connus :
- Chauffage et refroidissement simultanés. Quand les deux vannes d'une CTA sont ouvertes, l'unité lutte contre elle-même. Les causes vont d'une vanne qui fuit à une boucle de régulation mal réglée.
- Économiseur non utilisé. S'il fait frais dehors et que l'unité produit toujours du froid mécanique avec le registre d'air neuf proche du minimum, le free cooling est laissé de côté.
- Faible delta-T d'eau glacée. Une boucle d'eau glacée qui fonctionne bien en dessous de son écart de température de conception impose davantage de pompage et souvent la mise en route de groupes froids supplémentaires. C'est l'une des inefficacités les plus courantes et les plus coûteuses des productions de froid.
Chaque seuil est ici un point de départ. Ajustez-les équipement par équipement à l'aide des documents de conception et de quelques semaines de données observées. L'article jumeau numérique énergétique va plus loin sur les références et la mesure des économies.
Alertes et visualisation
Comme les résultats sont de simples messages MQTT, n'importe quel abonné peut les consommer. Dans le portail ConnectMQ, vous pouvez créer des règles d'alerte à seuil sur des valeurs numériques, par exemple kw_per_ton ou une température de soufflage, et consulter les alertes déclenchées dans le journal des alertes. Les messages de défaut eux-mêmes sont mieux acheminés par vos propres outils : Node-RED peut les transformer en e-mails ou en tickets, et un tableau de bord Grafana adossé à une base de séries temporelles peut afficher les tendances.
Pour la visualisation, un navigateur se connecte en WebSocket sécurisé sur le port 8084 (chemin /mqtt) et s'abonne aux topics kpi et telemetry. Un plan d'étage 2D avec des CTA colorées est souvent plus utile aux équipes techniques qu'un modèle photoréaliste. Si vous voulez voir à quoi ressemble un jumeau 3D en direct, la démo web de jumeau numérique de ConnectMQ anime une usine avec machines, cuves, pompes et convoyeurs mis à jour via WSS, et le même principe s'applique à une chaufferie ou à une salle des machines.
Checklist de déploiement
- Inventaire : exportez la liste des points de la GTB et sélectionnez ceux du tableau ci-dessus pour une CTA et un groupe froid.
- Passerelle : installez une passerelle BACnet vers MQTT sur le réseau du bâtiment, en lecture seule, publiant via TLS.
- Topics : convenez de la hiérarchie et des noms de champs JSON avant de connecter le deuxième équipement.
- Broker : créez un broker privé avec des identifiants par passerelle et par service d'analyse.
- Validation : comparez pendant une journée les valeurs du jumeau à celles de la supervision GTB ; corrigez les mises à l'échelle et les unités.
- Règles : activez les trois contrôles, examinez les constats chaque semaine avec l'équipe technique, ajustez les seuils.
- Extension : ajoutez les autres CTA, pompes et zones, puis envisagez des cas d'usage prédictifs comme l'usure des filtres et des roulements.
Pour le volet maintenance, voir jumeau numérique et maintenance prédictive, et pour la vision plus large du bâtiment, le guide jumeau numérique de bâtiment.
Considérations de sécurité
Les réseaux des bâtiments sont souvent anciens, plats et mal segmentés : la passerelle est donc un point sensible. Placez-la dans son propre segment réseau, n'autorisez que les connexions sortantes vers le broker sur le port 8883, n'exposez jamais BACnet sur Internet et attribuez à chaque passerelle ses propres identifiants. Un broker MQTT managé supprime totalement le besoin d'ouvrir des ports entrants sur le réseau du bâtiment, puisque toutes les connexions partent du site. Ne publiez jamais de données réelles du bâtiment sur le serveur MQTT public gratuit ; utilisez-le uniquement avec des valeurs synthétiques pendant le prototypage.
Construisez votre jumeau numérique CVC sur ConnectMQ
ConnectMQ est un broker MQTT cloud qui transporte les données en direct dont dépend votre jumeau CVC : MQTT 3.1.1 et 5.0, TLS, WebSockets pour les tableaux de bord, vues des appareils compatibles ISA-95 et alertes à seuil dans le portail. Vos passerelles, analyses et tableaux de bord se connectent comme des clients MQTT standard. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et diffusez les données de votre première CTA dès aujourd'hui.
Questions fréquentes
Qu'est-ce qu'un jumeau numérique CVC ?
C'est un modèle vivant d'équipements CVC comme les centrales de traitement d'air et les groupes froids, mis à jour en continu avec des données réelles de capteurs et comparé au comportement attendu pour détecter les défauts et le gaspillage d'énergie.
Faut-il remplacer sa GTB pour construire un jumeau numérique CVC ?
Non. Le jumeau lit les données de la GTB existante via une passerelle BACnet vers MQTT et laisse le pilotage à la GTB. Il ajoute de l'analyse, pas un nouveau système de contrôle.
Pourquoi utiliser MQTT plutôt que lire BACnet directement ?
BACnet est conçu pour les réseaux locaux des bâtiments. MQTT achemine les données de manière sécurisée vers le cloud via des connexions sortantes et permet à de nombreux consommateurs, comme les analyses, les tableaux de bord et le stockage, de partager le même flux.
En combien de temps un jumeau numérique CVC donne-t-il des résultats ?
Des règles simples comme le chauffage et le refroidissement simultanés ou le faible delta-T des groupes froids peuvent faire ressortir des problèmes dès les premières semaines de données, mais les économies dépendent du bâtiment et de la mise en œuvre des actions correctives.



