L’interopérabilité est une problématique connue des acteurs de l’ioT. Cela est renforcé par la multiplication des objets connectés qui ne communiquent pas entre eux et des gateways qui ne peuvent par interpréter les données de tous les capteurs. Les différents protocoles (EnOcean, Zigbee, Z-Wave, Bluetooth, Wi-Fi…) ne parlent pas entre eux et cela peut créer des difficultés d’installation et de fonctionnement au sein d’un même logement/bâtiment.
L’interopérabilité, qu’est-ce que c’est ?
Concrètement, l’interopérabilité désigne des systèmes capables de s’adapter et de collaborer avec d’autres systèmes indépendants, afin de créer un réseau et de faciliter le transfert de données.
Le concept d’interopérabilité est divisé en 3 couches :
La couche physique représente la bande de fréquence (433 MHz, 868 MHz, 2,4 GHz), le type de modulation et le type d’encodage.
→ Si on fait l’analogie avec le corps humain, il s’agirait des cordes vocales
La couche transport définit les tailles des paquets, les mécanismes de gestion d’erreur, le routage des messages dans le réseau.
→ La parole
La couche applicative / datamodel représente le contenu des messages et leur signification.
→ La langue (français, anglais etc.)
Concrètement :
Si on recherche une interopérabilité totale, il faut que l’interopérabilité soit faite sur ces 3 couches.
Si on a un datamodel commun, on peut conserver le format de la donnée tout au long du voyage (le message entre un produit A et un produit B).
En revanche, si les couches physiques sont différentes, il sera nécessaire d’ajouter des passerelles pour passer d’un monde à l’autre.
Chez NodOn, l’objectif est d’avoir une interopérabilité totale sur les 3 couches afin de pouvoir agir d’un produit à l’autre : utiliser la même bande de fréquence, utiliser la même couche transport et utiliser le même datamodel.
Si on a cette interopérabilité sur les 3 couches, on va limiter au maximum le besoin de passerelles.
Quid des protocoles existants
Aujourd’hui, 3 protocoles garantissent une interopérabilité totale : Zigbee, Z-Wave et EnOcean.
Ces 3 protocoles offrent chacun une couche physique, une couche transport et un datamodel standardisés.
Exemple du Zigbee 3.0 : lorsqu’un interrupteur dit à une ampoule de s’allumer, il le dit toujours de la même façon, pour que quelle que soit la marque ou le fabricant, ce soit compris de la même façon. Le Zigbee utilise notamment une couche transport 802.15.4 et qui est très standardisée.
Thread est un protocole interopérable sur les couches 1 et 2. La couche transport est standardisée (802.15.4) et basée sur l’IP. Cela rend sont interopérabilité de transport intéressante car les infrastructures IP sont très déployées sur le marché. Il n’existe pas de datamodel sur Thread.
Le Bluetooth offre une couche physique standard (2,4 GHz), une couche transport standardisée par Bluetooth SIG. Il n’existe pas encore de datamodel sur Bluetooth mais il y en a un en construction : Bluetooth Mesh.
Le Wi-Fi est très normé sur la couche physique et la couche transport. En revanche, il n’y a pas de datamodel défini.
Matter pour résoudre la problématique d’interopérabilité ?
Le nouveau protocole Matter a une vocation d’interopérabilité totale. Le datamodel sera relativement similaire à celui du Zigbee. Les couches de transport seront basées IP.
La grande subtilité est d’utiliser le Bluetooth pour tout ce qui est provisionning et commissioning (appairage, onboarding des devices dans un réseau…).
La promesse de Matter est de simplifier l’expérience utilisateur.
Laisser un commentaire