Sous-comptage ‘multi-fluides’ : OMS (M‑Bus) + passerelles IP — comment concevoir une collecte exploitable (hôtel & tertiaire)

Illustration générée par IA — visuel conceptuel.

Pourquoi OMS / M‑Bus devient un “bon réflexe” en sous-comptage multi-fluides

Dans un hôtel ou un bâtiment tertiaire, le sous-comptage ne concerne rarement une seule énergie. On veut souvent suivre plusieurs fluides (eau, énergie thermique, électricité, parfois gaz selon site) et plusieurs périmètres (chambres, étages, cuisines, buanderie, CVC, espaces communs). Le risque classique n’est pas d’installer “trop peu” de compteurs, mais d’obtenir des données incohérentes et difficiles à exploiter : unités mélangées, noms instables, trous de collecte, difficultés de maintenance, et intégration GTB/BMS fragile.

Dans ce contexte, OMS (Open Metering System) est intéressant parce qu’il vise à structurer l’interopérabilité et la lecture automatique des compteurs (AMR). L’OMS-Group présente OMS comme basé sur M‑Bus et orienté vers des applications multi-fluides (eau, chaleur, gaz, etc.). Source OMS-Group.

Point essentiel : OMS n’est pas une promesse de compatibilité universelle avec “tous les compteurs M‑Bus”. Une approche de projet robuste consiste plutôt à cadrer une chaîne cohérente : compteurs explicitement OMS (idéalement listés/certifiés), collecte (filaire ou radio), puis passerelle(s) IP et intégration GTB validées par recette.

Rappels utiles : M‑Bus filaire, wM‑Bus et OMS — qui fait quoi ?

M‑Bus filaire : un bus de comptage (polling / “pull”)

Le M‑Bus filaire (Meter‑Bus) est un bus historiquement utilisé pour la télérelève de compteurs. En Europe, il s’appuie notamment sur la série EN 13757 ; la partie EN 13757‑2 décrit des éléments liés à la communication M‑Bus filaire (couches physique et liaison) pour des systèmes de comptage (notamment eau, gaz, chaleur). Référence (fiche DIN).

En pratique projet, le M‑Bus filaire se prête bien à une collecte de type passerelle qui interroge (pull/polling) : la passerelle questionne les compteurs selon une fréquence de lecture choisie.

wM‑Bus / OMS : radio (télégrammes “push”) et contraintes de bâtiment

OMS décrit aussi des modes de collecte radio via wM‑Bus. Dans la spécification OMS Gen 5 (Vol.2 Primary Communication), la logique est explicitement décrite comme :

• M‑Bus filaire (2 fils) en mode “pull” (interrogation par la passerelle),
• wM‑Bus en mode “push” (télégrammes radio émis périodiquement par les compteurs), avec des cas particuliers selon équipements.

Référence : OMS Spec Vol.2 Primary Communication (PDF).

La même spécification rappelle également un point de dimensionnement important : la capacité (nombre de périphériques) gérable côté M‑Bus dépend de la passerelle et doit être donnée par le fabricant. Autrement dit : on ne “déduit” pas cette limite d’un texte OMS ; on l’exige sur la fiche technique, et on la valide en recette. (OMS Spec Vol.2, PDF).

Choisir l’architecture de collecte : ce que vous décidez vraiment

Pour “faire remonter des compteurs dans une GTB”, il faut séparer deux couches :

• Couche terrain (compteurs ↔ collecte) : M‑Bus / wM‑Bus / OMS, topologie, accès aux locaux, contraintes radio, alimentation, maintenance.
• Couche IP/GTB (collecte ↔ supervision) : passerelles IP, mapping des points, protocole vers la GTB/BMS, cybersécurité, supervision et DOE.

Option A — M‑Bus filaire : stabilité et diagnostic, au prix du câblage

En neuf (ou rénovation lourde), le M‑Bus filaire est souvent apprécié pour sa prévisibilité : câblage identifié, lecture par polling, troubleshooting plus direct. C’est aussi cohérent avec une démarche “bâtiment” : infrastructure d’abord, services ensuite.

Points de vigilance typiques :

• accès aux gaines et passages (ne pas découvrir les impossibilités de cheminement en fin de chantier) ;
• localisation des passerelles et des départs ;
• stratégie de maintenance : qui intervient sur un compteur, sur une passerelle, sur le réseau IP ?

Option B — wM‑Bus / OMS : utile quand le câblage est difficile, mais à traiter comme un vrai lot radio

Le wM‑Bus peut devenir pertinent lorsque tirer un bus est disproportionné (bâtiment existant, zones compliquées, phasage d’hôtel). Mais il introduit des variables qui doivent être anticipées : propagation radio réelle dans le bâtiment, implantation des collecteurs, et contraintes locales (cadre radio et agrément des équipements à vérifier au Maroc selon modèles/variantes).

La spécification OMS Gen 5 (Vol.2) précise notamment le périmètre des modes supportés (dans ce document : support de modes spécifiques, et absence de multi-hop relaying). La conséquence pratique est simple : on ne compte pas sur un “maillage” automatique ; on conçoit l’implantation et on la recète. Référence : OMS Spec Vol.2 (PDF).

Intégration vers IP / GTB : la passerelle fait (souvent) la différence

OMS structure l’échange entre compteurs et collecte. Mais dès que vous voulez exploiter ces données dans une GTB/BMS, le sujet devient : qu’est-ce que la passerelle expose sur IP, et comment les points sont nommés et maintenus ?

Dans les projets, on rencontre typiquement des passerelles/serveurs M‑Bus qui remontent vers :

• BACnet/IP (courant en GTB),
• Modbus TCP (très utilisé pour l’énergie et certaines supervisions),
• et parfois des approches “IT/IoT” selon stratégie (à cadrer au cas par cas).

À titre d’exemples documentés par des fabricants :

• HMS Networks (Intesis) présente une passerelle “M‑Bus Meters to BACnet/IP server” : fiche produit, et son manuel “M‑Bus to BACnet/IP Server Gateway” : manuel (PDF).
• Le même fabricant documente une passerelle “M‑Bus to Modbus TCP Server Gateway” et décrit le rôle serveur côté Modbus et le polling côté M‑Bus : manuel (PDF).

Dans tous les cas : ne spécifiez pas “compatible GTB” ; spécifiez les points, les unités, le sens, la périodicité, et la preuve par recette.

Pour replacer la collecte dans une logique GTB (qui supervise quoi, et jusqu’où), voir aussi GTB, GTC et BMS : quelles différences ?.

Industrialiser : nomenclature, registre, mapping — la partie la plus rentable

Un sous-comptage “réussi” n’est pas celui qui lit un compteur en démonstration. C’est celui qui reste exploitable après des remplacements, des extensions et des changements d’équipe.

Règle simple : séparer identité terrain et identité exploitation

Évitez que “l’adresse M‑Bus” devienne le seul identifiant. En exploitation, vous avez besoin d’identifiants stables, lisibles et durables.

• Identité exploitation (stable) : un identifiant métier qui décrit périmètre et usage (bâtiment / zone / utilité).
• Identité protocolaire (technique) : adresse(s) M‑Bus, identifiant radio, etc.
• Identité GTB : objet(s) BACnet / registre(s) Modbus, tags supervision, etc.

Livrables à prévoir (DOE exploitation) :

• un registre des compteurs (localisation, usage mesuré, numéro de série, protocole, passerelle associée) ;
• une table de correspondance (ID exploitation ↔ identifiants terrain ↔ points GTB) ;
• une convention claire sur unités, sens, index cumulés, fréquence de lecture.

Sur la logique “données exploitables vs données brutes”, notre article Sous-comptage énergétique : savoir précisément où part l’énergie d’un bâtiment complète cette approche côté plan de comptage (arborescence, cohérence, recette).

Structurer le réseau IP comme une infrastructure de service (pas un “détail IT”)

Une collecte AMR devient vite dépendante de services réseau (adressage, VLAN, accès d’administration). Sans méthode, chaque ajout de passerelle peut devenir une exception.

Deux lectures utiles selon contexte :

• Architecture réseau IP d’un hôtel : faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS (vision convergée hôtel) ;
• Plan d’adressage IP & nomenclature : méthode orientée exploitation (discipline VLAN/DHCP/réservations/nommage).

Sécurité : ce qu’il faut décider au projet (sans surpromettre)

OMS documente des aspects de sécurité au niveau des spécifications et de documents associés, mais la réalité d’un projet hôtel/tertiaire dépend surtout de vos décisions d’architecture : segmentation réseau, accès d’administration, gestion des identifiants, et procédures (qui fait quoi, et comment on retire un accès).

Mesures “bâtiment” généralement pertinentes

• Segmenter : isoler le périmètre des passerelles de comptage des réseaux invités et bureautiques, et limiter les flux aux besoins (principe allow-list).
• Réduire l’exposition : pas d’accès d’administration exposé inutilement ; accès distant via méthode maîtrisée (VPN / bastion selon politique IT).
• Tracer : comptes nominatifs quand les plateformes le permettent, journalisation des accès, sauvegardes de configuration des passerelles.
• Documenter : une fiche “cybersécurité exploitation” par passerelle (où, qui administre, comment restaurer, dépendances).

Pour une lecture orientée hôtellerie (IT/OT, segmentation, accès), voir Cybersécurité d’un hôtel connecté et Segmentation OT/IT : isoler GTB/GRMS/CCTV du SI bureautique.

Recette (FAT/SAT) : une checklist qui évite les “données inexploitables”

La recette doit tester la mesure, mais aussi la maintenabilité : redémarrage, perte réseau, remplacement, cohérence des identifiants. Ci-dessous une grille de tests simple (à adapter au site et au protocole GTB choisi).

Test	Comment le vérifier (terrain)	Limites / points d’attention
Inventaire de collecte	Comparer la liste “compteurs vus” par passerelle avec le plan de comptage et les plans (zone/étage)	En radio, l’inventaire peut varier selon couverture et périodes ; stabiliser l’implantation avant conclusions
Cohérence unités & sens	Vérifier unités, signe, index cumulés (monotones), conversions (si appliquées)	Une unité fausse produit des tableaux convaincants… et inutilisables
Latence de donnée	Mesurer délai entre un événement (consommation/variation) et sa visibilité GTB	Pull filaire et push radio n’ont pas la même latence : l’exploitant doit le savoir
Perte IP (mode dégradé)	Couper la liaison IP (contrôlée) : observer stockage tampon, reprise, trous	Ne pas supposer le buffering : certains équipements ne tamponnent pas ou peu
Redémarrage passerelle	Redémarrer : vérifier retour à l’état nominal, réapparition des points, absence de reset mapping	À valider avec la GTB : certains points peuvent rester “en défaut” si la reprise n’est pas gérée
Remplacement d’un compteur	Simuler un remplacement (ou un “swap” en atelier) : vérifier procédure et impact sur l’identifiant exploitation	Le registre et la nomenclature sont la clé : sans eux, le remplacement casse l’historique
Sécurité d’administration	Vérifier où sont les interfaces d’admin, qui peut y accéder, et comment on retire un accès	Une bonne recette inclut la gouvernance (pas seulement le “technique”)

Points de vigilance à mettre noir sur blanc dans un CCTP / cahier des charges

• Compatibilités : exiger références explicitement OMS (et, si possible, vérifier l’existence d’un listing/certificat côté OMS-Group) ; sinon prévoir un lot d’intégration/driver et une recette renforcée. Voir : OMS Certified Products.
• Capacité et performance de la passerelle : charge de polling, nombre d’esclaves, comportement en cas de perte IP, méthodes de sauvegarde/restauration.
• Radio (si wM‑Bus) : concevoir l’implantation, tester en conditions réelles, et vérifier le cadre local (bandes, agrément, variantes produits) avant achat/import.
• Données exploitables : registre, nomenclature, mapping, et PV de recette font partie du livrable, sinon la “télérelève” reste un assemblage de compteurs.

Sources et références (pour aller plus loin)

• OMS-Group — OMS home : https://oms-group.org/en/oms-home/
• OMS-Group — Specification (documents OMS) : https://oms-group.org/en/specification/
• OMS-Group — OMS Spec Vol.2 Primary Communication (Issue 5.0.1) : PDF
• DIN Media — fiche DIN EN 13757‑2 : https://www.dinmedia.de/en/standard/din-en-13757-2/375192193
• HMS Networks (Intesis) — passerelle M‑Bus vers BACnet/IP : fiche produit + manuel (PDF)
• HMS Networks (Intesis) — manuel M‑Bus vers Modbus TCP : manuel (PDF)

Conclusion : viser un système de données, pas une collection de compteurs

OMS (basé sur M‑Bus) peut être un excellent socle pour structurer un sous-comptage multi-fluides. Mais la réussite d’un projet hôtel/tertiaire se joue surtout sur l’industrialisation : une architecture de collecte cohérente, des passerelles IP correctement intégrées à la GTB, une nomenclature stable, une sécurité exploitable et une recette orientée exploitation.

Si vous le souhaitez, Domocasa peut vous accompagner sur la conception (plan de comptage, architecture IP/GTB, nomenclature) et la préparation d’une recette “chambre/étage type” avant généralisation.