Interopérabilité IoT dans les systèmes multimarques

Un compteur électrique et une gestion technique du bâtiment (GTB) peuvent tous deux prendre en charge Modbus TCP et néanmoins ne pas s’accorder sur l’adresse de base des registres, l’ordre des mots d’un flottant 32 bits, l’unité ou le signe de l’exportation. La connexion fonctionne, un nombre apparaît sur le tableau de bord, mais ce nombre est faux.

Lorsque deux produits documentent le même protocole, le même transport et des rôles compatibles, il existe un chemin de connexion. Cela suffit pour les qualifier de compatibles sur le plan du protocole ; il n’est pas nécessaire qu’un essai générique en laboratoire ait d’abord reproduit cette paire. Le reste relève du projet : correspondance des points, unités, horodatages, règles de qualité et comportement en cas de rupture de liaison. Les documents des fabricants établissent que le chemin existe. La mise en service vérifie que les points installés sont justes. Consignez ces deux preuves séparément.

Exemple : puissance active d’un compteur

Un compteur publie la puissance active triphasée. La GTB doit l’afficher en kW et l’utiliser pour une alarme de puissance appelée. Chacune des erreurs ci-dessous passe pourtant un contrôle élémentaire « nous arrivons à lire la valeur ».

• Base d’adressage. La table indique la valeur au registre 3000 en FLOAT32. La liste commence à 1 : l’adresse transmise sur le bus est donc 2999. Un client qui demande 3000 lit le mot bas de cette valeur et le mot haut de la suivante.
• Ordre des mots. Le client assemble les deux registres dans le mauvais ordre. Le décodage ci-dessous montre le résultat.
• Unité. Le registre contient des watts, mais le point de la GTB est étiqueté kW : 42 700 W deviennent 42 700 kW à l’écran.
• Grandeur. Le registre contient la puissance apparente totale en kVA, et non la puissance active. À un facteur de puissance de 0,85, la lecture est environ 18 % trop élevée.
• Signe. Le compteur donne une valeur négative pour l’exportation. La destination traite toute puissance comme de l’importation et ramène les valeurs négatives à zéro : l’exportation disparaît.
• Double mise à l’échelle. Le rapport du TC de 400/5 A est déjà réglé dans le compteur, qui fournit donc le courant primaire. L’intégrateur applique aussi un multiplicateur de 80 dans le client.
• Temps. Après reconnexion, le Gateway horodate les mesures mises en mémoire tampon à leur réception : les anciennes données paraissent actuelles.
• Données périmées. La destination conserve la dernière valeur sans signaler qu’elle est périmée. L’alarme de puissance appelée ne se déclenche jamais.
• Commande. Une écriture reçoit un accusé de réception du protocole, mais l’équipement la rejette, une commande locale prévaut ou l’équipement revient ensuite à son état antérieur.

Décoder la valeur

Le flottant simple précision IEEE 754 représentant 42,7 est formé des quatre octets 42 2A CC CD. Un compteur qui transmet le mot haut en premier place 0x422A dans le premier registre et 0xCCCD dans le second. L’ordre des octets et des mots choisi dans le client détermine la valeur lue :

Une valeur énorme ou proche de zéro révèle souvent une erreur d’ordre. Les fabricants n’emploient pas toujours les étiquettes ABCD de la même façon : ne vous fiez pas à leur nom. Lisez une valeur non nulle visible aussi sur l’écran du compteur, décodez-la dans chaque ordre avec le convertisseur de flottants IEEE 754 ou le décodeur de registres Modbus, puis retenez l’ordre correspondant.

Les compteurs d’énergie présentent deux autres pièges. Un compteur UINT32 en Wh déborde après 4 294 967 295 Wh, soit environ 4 295 MWh. Une charge continue de 500 kW atteint cette valeur en environ 358 jours. Le destinataire doit distinguer une baisse due au débordement d’une remise à zéro du compteur, au lieu d’y voir une consommation négative. Un compteur FLOAT32 en kWh perd de la résolution à mesure que sa valeur augmente. À 1 000 000 kWh, son plus petit pas vaut 0,0625 kWh ; la variation en une minute d’une charge de 10 kW (0,167 kWh) ressort alors à 0,125 ou 0,1875 kWh. Utilisez un registre entier pour l’énergie par intervalle si le compteur en propose un.

Huit couches d’interopérabilité

Ces couches se recoupent, mais les distinguer rend les lacunes visibles.

L’architecture Web of Things du W3C sépare ces préoccupations. Une Thing Description décrit les interactions, schémas de données, liaisons de protocole et métadonnées de sécurité d’un appareil dans un fichier lisible par machine. Cela réduit le travail de découverte spécifique. Le système destinataire doit néanmoins prendre en charge la même liaison et interpréter correctement le sens décrit.

Ce que chaque protocole laisse à définir

Chaque protocole normalise une partie de la chaîne. Les documents du fabricant et la configuration du projet définissent le reste.

Modbus

La spécification du protocole applicatif Modbus définit des codes de fonction et quatre tables de données : bobines, entrées discrètes, registres d’entrée et registres de maintien. Elle ne précise ni quelle valeur se trouve à quelle adresse, ni son type, son échelle ou l’ordre de ses mots. La table des registres du fabricant le fait.

La notation 4x ajoute un piège d’adressage. La référence 40001 désigne le registre de maintien 1, envoyé comme adresse 0 dans la requête. Certains manuels donnent des numéros de registre commençant à 1, d’autres des adresses commençant à 0. Les clients n’attendent pas tous la même convention. Edge attend l’adresse commençant à 0 : entrez 0 pour la référence 40001. Le convertisseur d’adresses Modbus fait la correspondance. La référence des codes de fonction et d’exception Modbus aide à décoder les réponses d’erreur.

Les écritures ont leurs propres pièges. Le code de fonction 06 écrit un registre ; le code 16 en écrit plusieurs dans une requête. Écrire une valeur 32 bits au moyen de deux requêtes FC06 n’est pas atomique : le premier mot peut être enregistré alors que le second échoue, laissant une consigne partiellement écrite. Certains appareils répondent normalement à une écriture qu’ils ignorent ou limitent ensuite. Relisez le registre cible après chaque écriture. Par défaut, Edge suspend pendant 2 secondes les lectures en direct sur une connexion après une écriture, afin de laisser à un appareil lent le temps d’appliquer la valeur avant la relecture.

Sur RS-485, la durée de transmission limite le nombre de points. À 9 600 bauds avec des caractères de 11 bits, une requête et sa réponse pour un bloc de 60 registres occupent environ 160 ms sur le bus, avant même le délai de réponse de l’appareil. Le guide de mise en service RS-485 détaille un cycle complet d’interrogation.

BACnet/IP

BACnet définit des objets et propriétés. La puissance active d’un compteur arrive dans la propriété Present_Value d’un objet Analog Input, avec une propriété Units à côté. Cela élimine le problème de décodage des registres, mais pas les autres : quelle instance d’objet porte quelle grandeur, chaque instance d’appareil est-elle unique sur le réseau, et les diffusions de découverte (Who-Is sur le port UDP 47808) traversent-elles les sous-réseaux ?

Une inscription BTL couvre les blocs d’interopérabilité (BIBB) et les types d’objets de son périmètre. Elle ne valide pas la liste d’objets de l’appareil que vous installez.

Pour la commande, BACnet utilise un tableau de 16 niveaux de priorité. Une écriture au niveau 8 reste active jusqu’à ce que NULL soit écrit au même niveau pour libérer la commande. Convenez de l’autorité de chaque système sur chaque niveau et de la procédure de libération.

MQTT

MQTT 5.0 définit les sujets, propriétés des messages, sessions et trois niveaux de qualité de service (QoS). Il ne définit pas le sens de la charge utile. Deux systèmes peuvent tous deux prendre en charge MQTT, mais diverger sur la hiérarchie des sujets, le schéma, l’identité des points, les unités, les horodatages, les messages conservés et le traitement des doublons.

QoS 1 assure une livraison au moins une fois. Si un accusé de réception se perd, l’émetteur retransmet et le destinataire peut recevoir le même message deux fois. QoS 2 assure exactement une livraison, mais sur un seul saut : client vers courtier ou courtier vers abonné. Un abonné inscrit avec un QoS plus faible reçoit ce niveau inférieur. Aucun QoS ne prouve qu’un échantillon était juste, que tous les échantillons sont devenus des messages ou que la base de données les a enregistrés une seule fois. Placez l’horodatage source et un identifiant de message ou numéro de séquence dans la charge utile pour permettre au destinataire d’écarter les doublons.

Sparkplug 3.0, publié comme ISO/IEC 20237:2023, comble une partie de cette lacune pour les données industrielles. Il définit l’espace de noms des sujets, une charge utile binaire typée et des messages de naissance et de mort. Un nœud Edge publie un message NBIRTH énumérant toutes les mesures qu’il transmettra. Il enregistre un message NDEATH comme testament MQTT, que le courtier publie si la connexion tombe. Les abonnés savent alors quelles valeurs sont périmées. Sparkplug laisse au projet les unités, conventions de signe et identités des actifs.

La sécurité du transport doit faire l’objet d’un accord distinct. Voir MQTTS, MQTT sur TLS.

OPC UA

Le guide comparant OPC UA, MQTT et Modbus expose leurs différences ; le guide d’identité des nœuds explique les NodeId et les espaces de noms.

OPC UA transporte davantage de contexte qu’un registre ou un message arbitraire. Son DataValue associe une valeur, un StatusCode, un horodatage source et un horodatage serveur. Les deux bits de poids fort du StatusCode donnent sa gravité : Good, Uncertain ou Bad. Une variable peut aussi exposer ses unités techniques. L’application destinataire doit malgré tout choisir le bon nœud, vérifier l’état avant d’utiliser la valeur, garder l’horodatage pertinent et décider du traitement des valeurs Uncertain et Bad.

Client et serveur doivent également s’accorder sur une politique de sécurité et un mode de message, par exemple Basic256Sha256 avec SignAndEncrypt, et faire confiance à leurs certificats d’application respectifs. La validation des certificats dépend de l’heure : une mauvaise horloge d’un côté ou de l’autre empêche la session.

Zigbee et LoRaWAN

La certification Zigbee 3.0 signifie qu’un appareil peut rejoindre un réseau et échanger des données par la Zigbee Cluster Library. Elle ne garantit pas que toutes ses valeurs utilisent un cluster standard. Un compteur peut publier sa puissance via le cluster Electrical Measurement (0x0B04), avec ses propres attributs multiplicateur et diviseur, ou via un cluster propre au fabricant que seul son convertisseur décode. Avant achat, vérifiez les clusters et attributs du modèle. Appliquez le multiplicateur et le diviseur transmis par l’appareil, pas une constante fixée d’avance.

LoRaWAN normalise la liaison radio, la couche MAC et l’activation de l’appareil. La charge utile applicative reste un format binaire propre au fabricant. Le codec qui transforme ces octets en valeurs est un logiciel dont il faut désigner le responsable, gérer les versions et assurer les mises à jour. Si une mise à jour du micrologiciel change la disposition de la charge utile, le codec cesse de fonctionner sans que le serveur réseau, qui continue de livrer les messages montants, signale une erreur. L’appareil doit aussi correspondre aux paramètres régionaux du site, par exemple EU868, et à sa méthode d’activation. Le guide Utiliser Zigbee avec LoRaWAN compare les deux réseaux.

Interopérabilité syntaxique et sémantique

L’interopérabilité syntaxique signifie que le destinataire peut analyser les données. L’interopérabilité sémantique signifie que les deux parties donnent le même sens aux données analysées.

Ce JSON est valide :

{
  "point": "P_TOTAL",
  "value": 42.7,
  "unit": "kW",
  "time": "2026-09-19T10:15:00Z",
  "quality": "good"
}

Il ne constitue pas un contrat complet. Le destinataire ignore à quel site, actif et périmètre de mesure appartient P_TOTAL. Il ne sait pas si la valeur est instantanée ou moyenne sur un intervalle, si le signe positif signifie importation ou exportation, ni comment l’état good a été déterminé. time peut être l’heure de mesure, de calcul ou de réception par le Gateway. Le rapport du TC et la révision du calcul manquent aussi.

ETSI SAREF est une ontologie conçue pour ce problème ; ses recommandations sont publiées dans ETSI EN 303 760. Chaque système conserve son propre modèle de données et le relie à des concepts communs. Il n’est pas nécessaire d’adopter SAREF pour appliquer la méthode : définissez une seule fois chaque signification, puis faites correspondre chaque système à cette définition. Les correspondances directes de noms de champs entre chaque paire de systèmes croissent comme n(n−1)/2 : cinq systèmes exigent dix correspondances et dix systèmes en exigent 45.

Temps et qualité

Définissez l’origine de chaque horodatage. Séparez heure de mesure et heure de réception ; après une coupure, elles peuvent différer de plusieurs heures. OPC UA SourceTimestamp est attribué par la source et devrait indiquer le dernier changement de valeur ou d’état. ServerTimestamp indique quand le serveur a reçu la valeur ou l’a connue comme exacte. Aucun ne désigne automatiquement une nouvelle mesure physique ou l’arrivée en base de données. Vérifiez leur signification à la source et préservez-la lors de la retransmission ; enregistrez séparément l’heure de réception.

Les horloges dérivent. Un compteur qui avance de 2 secondes par jour a une minute d’avance au bout d’un mois. Cela suffit à placer des mesures proches d’une frontière dans le mauvais intervalle de 15 minutes. Synchronisez toutes les horloges qui horodatent les données sur la même source NTP et mesurez le décalage à la réception. Les contrôles des certificats TLS et OPC UA échouent aussi lorsqu’une horloge dérive beaucoup ; l’incident ressemble alors à un problème de sécurité.

Définissez une règle de fraîcheur dans la destination. Une règle pratique correspond à trois intervalles de transmission : pour une cadence de 60 secondes, une valeur vieille de plus de 180 secondes est périmée. Ne dépendez pas seulement de la source. Edge marque un appareil Modbus hors ligne après deux interrogations manquées, avec un minimum de cinq minutes. Un point interrogé chaque seconde peut donc dater de cinq minutes avant qu’Edge ne signale l’appareil.

Les valeurs synthétiques ont besoin d’un indicateur conservé sur toute la chaîne. Edge peut combler de courtes lacunes en répétant une valeur, en insérant zéro ou en interpolant, et marque ces points _synthetic: true. Une base de données en aval qui supprime les champs inconnus supprime aussi cet indicateur : les valeurs comblées paraissent alors mesurées. Désactivez le comblement des lacunes pour la facturation, les alarmes et la commande.

Conformité, certification et réception du projet

Chaque type de preuve répond à une question différente.

Le cadre d’interopérabilité des réseaux électriques intelligents du NIST considère les essais de conformité et d’interopérabilité comme complémentaires. Le format d’essai d’interopérabilité de oneM2M exige d’indiquer configuration, conditions initiales, séquence d’événements et résultats attendus pour chaque essai. Reprenez ces quatre rubriques pour les essais sur site.

Fiche de consultation

Demandez à chaque fournisseur ou intégrateur de remplir la même fiche avant la commande du matériel.

Indiquez explicitement « inconnu » lorsque la réponse manque. Une cellule vide devient souvent une hypothèse pour une partie et un engagement pour l’autre.

Essai de réception en douze étapes

Utilisez exactement le matériel, les versions de micrologiciel, les documents d’interface et l’application destinataire prévus pour le projet. Capturez les données brutes à la source, à chaque système intermédiaire et à la destination finale.

1. Consignez identité et configuration : modèle, numéro de série, micrologiciel, révision du document d’interface, versions du Gateway et d’Edge, version du connecteur et empreinte de configuration.
2. Prouvez le chemin physique. Inspectez câblage et topologie. Vérifiez les réglages série et réseau. Montrez que les équipements prévus communiquent réellement entre eux.
3. Retracez chaque point depuis la destination jusqu’au registre, objet, canal ou message source, puis jusqu’à l’étiquette de l’actif physique.
4. Vérifiez le codage. Lisez deux valeurs connues non nulles pour chaque point. Comparez base d’adresse, type de données, signe, ordre des octets et mots, échelle et énumérations.
5. Vérifiez le sens. Confirmez unité, direction, périmètre de mesure et calcul par rapport à un instrument de référence ou à une source contrôlée.
6. Vérifiez le temps. Comparez les horloges. Introduisez un délai connu. Confirmez que des données retransmises ne paraissent pas actuelles.
7. Vérifiez qualité et péremption. Provoquez une panne de source, une valeur invalide et l’arrêt des mises à jour. L’application finale doit les distinguer tous d’un zéro valide.
8. Testez les écritures permises. Vérifiez autorisations, limites et verrouillages. Consignez requête, réponse protocolaire, effet observé sur l’équipement et état final rapporté.
9. Coupez chaque liaison. Débranchez séparément la connexion de terrain et la connexion en aval. Consignez détection de perte, traitement de la dernière valeur, mise en mémoire tampon, alarmes et comportement local.
10. Rétablissez chaque liaison. Reconnectez avant et après la fenêtre de mémoire tampon. Vérifiez ordre, doublons, lacunes, variation du compteur d’énergie pendant la coupure et levée de l’état périmé.
11. Redémarrez chaque composant à tour de rôle, puis restaurez depuis la sauvegarde documentée. Vérifiez identités, correspondance des points, horloges, identifiants et données en attente.
12. Appliquez une modification approuvée de micrologiciel ou de configuration, puis répétez les essais concernés. Revenez à l’état précédent en cas d’échec.

Le dossier de réception de chaque chemin indique modèle, micrologiciel et révision de configuration, application destinataire et version, points et scénarios réussis, options non testées, date, observateur et personne ayant accepté chaque écart. Lorsqu’une version, un profil, une table de points ou une exigence de sécurité change plus tard, ce dossier indique les essais à refaire.

Exemple pratique : PowerLogic PM5000 vers Edge

Schneider Electric décrit les interfaces de la famille PM5000 modèle par modèle dans sa documentation de gamme. Les PM5110 et PM5330 possèdent une interface RS-485 Modbus RTU. Le PM5560 ajoute Ethernet Modbus TCP. BACnet/IP est disponible sur les PM5560 et PM5563 à partir du micrologiciel 2.3.0, selon la note BACnet/IP de Schneider. Schneider publie des tables de registres Modbus distinctes pour les PM51xx/PM53xx et les PM55xx/PM56xx/PM57xx.

Le guide de l’appareil PM5000 décrit trois chemins vers Edge :

1. Modbus RTU : raccordez un modèle RS-485 à un ZMB-31. Le ZMB-31 est maître Modbus RTU de 300 à 115 200 bauds et lit jusqu’à 30 registres. Il transmet les valeurs par le maillage Zigbee, sans tirer de câble de données jusqu’au Gateway.
2. Modbus TCP : raccordez un modèle Ethernet au réseau du site. Configurez Edge comme client Modbus avec l’adresse IP du compteur, le port 502 et l’identifiant d’unité.
3. BACnet/IP : sur un PM5560 ou PM5563 équipé du micrologiciel 2.3.0 ou ultérieur, configurez le client BACnet/IP d’Edge pour découvrir le compteur et lire ses objets.

Mettez d’abord un seul point en service. Consignez la référence commerciale complète et le micrologiciel. Choisissez la table des registres correspondant à cette gamme. Déterminez si elle donne des numéros de registres commençant à 1 ou des adresses commençant à 0. Associez la puissance active totale à un FLOAT32, lisez-la sous charge et comparez-la à l’écran du compteur. Si le site exporte, vérifiez le signe pendant l’exportation. Ajoutez ensuite les autres points et réglez l’intervalle d’interrogation et la règle de péremption pour la liste complète.

Si le répertoire des appareils propose un modèle d’importation Edge pour ce modèle, la table des points est déjà rédigée. Sinon, l’intégrateur la crée à partir de la table des registres du fabricant.

Interopérabilité des commandes

Pour le suivi, la réception s’achève lorsque la valeur de destination est juste et récente. Pour la commande, il faut aussi confirmer l’état de l’équipement après chaque écriture.

Une commande passe par les étapes suivantes :

1. Un demandeur autorisé crée une commande avec identifiant, cible, valeur et échéance.
2. Le contrôleur vérifie plage, mode, verrouillages et autorité en vigueur.
3. Le contrôleur envoie l’écriture protocolaire.
4. L’équipement accuse réception, rejette ou dépasse le délai.
5. Une relecture ou une mesure indépendante du procédé montre si l’effet voulu s’est produit.
6. Le système consigne toute commande locale ultérieure, toute nouvelle consigne qui remplace la précédente ou toute perte d’autorité.
7. Un état local défini s’applique lorsque le demandeur n’est plus disponible.

Une réussite TCP, une publication MQTT ou une réponse Modbus ne prouvent pas que l’installation a atteint l’état demandé. Edge signale l’accusé de réception protocolaire d’une écriture Modbus mais ne relit pas lui-même la valeur : l’intégration doit effectuer cette relecture. Pour BACnet, convenez aussi du niveau de priorité et de la procédure de libération décrits plus haut.

Les fonctions de sécurité, de protection du réseau et de protection de l’équipement exigent une conception qualifiée qui leur est propre. Ne les confiez pas à un chemin de suivi.

Standards ouverts et dépendance au fournisseur

Un flux MQTT est ouvert au niveau du transport. Si sa charge utile est un format binaire non documenté ou si ses sujets codent une identité d’actif que seul le cloud du fournisseur peut résoudre, un nouveau prestataire doit reconstruire toute la table des points. Un protocole ouvert ne réduit la dépendance que si l’acheteur peut également obtenir et réutiliser :

• la table complète des points et objets ;
• la configuration du protocole et du profil ;
• les certificats, identités et procédures de rotation des identifiants ;
• les exports de données et d’événements avec unités, horodatages et qualité ;
• les règles, calculs et correspondances sémantiques sous forme documentée ;
• les sauvegardes et une procédure de restauration éprouvée ;
• les conditions d’assistance et de mises à jour de sécurité pendant la vie de l’actif.

Un adaptateur propre au projet peut rester facile à maintenir si ses entrées, sorties, essais et responsable sont documentés.

NIST IR 8259 Rev. 1, publié en avril 2026, attend des fabricants qu’ils fournissent à la fois les fonctions de sécurité et les informations nécessaires pour les utiliser. Inscrivez la date de fin d’assistance du micrologiciel et la méthode de rotation des identifiants de chaque composant dans la fiche de consultation. Quand un fournisseur cesse de publier des mises à jour, les vulnérabilités connues restent ouvertes. Quand un certificat expire sans procédure de renouvellement, la liaison s’arrête à cette date.

Matériel EpiSensor et Edge

Les capteurs EpiSensor transmettent par Zigbee au Gateway ZGW-20, qui exécute Edge. Pour les équipements tiers, Edge tient les rôles suivants :

Les flux en aval publient certains points par MQTTS ou HTTPS, ou les écrivent dans des fichiers. Les données et les règles restent sur le Gateway lorsque la liaison Internet est coupée.

Commencez par le guide d’intégration des compteurs à une GTB ou un SCADA. Apportez ensuite la fiche de consultation remplie et les documents d’interface à jour dans System Builder ou lors d’une demande technique.