Dans ce sixième article de la série sur KNX IoT, Bruno Johnson et Wouter van der Beek nous expliquent comment utiliser Thread pour KNX IoT.
Depuis quelques années déjà, la transformation numérique est l’un des principaux sujets stratégiques à l’ordre du jour des conseils d’administration des entreprises. La possibilité de développer des services numériques à partir d’applications infonuagiques nécessite des connexions réseau basées sur le protocole Internet (IPv6) qui relient les périphériques et deviennent l’interface client. Pour y parvenir, les entreprises de toutes formes et tailles œuvrant dans le domaine de l’automatisation des bâtiments commerciaux ont demandé des solutions IoT sans fil, et l’association KNX a répondu à ces demandes avec l’API KNX IoT Point (KNX IoT).
Introduction à Thread
Comme nous l’avons déjà expliqué dans notre article « KNX IoT : 2e partie – les avantages de Thread », Thread est un réseau maillé basé sur IPv6. Dans cet article, nous expliquerons Thread plus en détail techniquement, et soulignerons notamment comment il peut être utilisé pour les périphériques KNX IoT.
Le réseau maillé Thread renferme divers rôles de réseau Thread, comme le montre la figure 1.
Routeur de bordure Thread
Le routeur de bordure (BR – Border Router) Thread est l’entité réseau qui connecte le réseau Thread au réseau informatique plus large. Cette entité est nécessaire lorsque l’outil logiciel de configuration KNX, ETS, fonctionne comme une application PC sur un réseau informatique. Elle est également nécessaire pour d’autres communications réseau, par exemple, dans le cas de l’utilisation d’un routeur KNX IoT (voir la 5e partie de cette série) pour connecter KNX IoT à d’autres périphériques KNX.
Le routeur de bordure Thread est une fonction réseau standard. Ce produit peut avoir plusieurs aspects et peut être basé sur un équipement réseau : par exemple, Thread peut être une extension d’un routeur Wi-Fi. De plus, d’autres utilisations sont possibles, par exemple en l’intégrant au domaine d’application. Notez qu’à des fins de redondance, Thread permet l’utilisation de plusieurs routeurs de bordure dans un réseau Thread.
Cela permet aux réseaux Thread d’être partitionnés intentionnellement ou non (en cas de panne d’un routeur pour une raison quelconque), sans que le fonctionnement s’en trouve interrompu.
À côté du routeur de bordure, Thread spécifie les types de périphériques qui peuvent assumer les différents rôles réseau. Pour expliquer les différents types de périphériques, il faut d’abord comprendre les rôles réseau de Thread.
Rôle de routeur
Le nœud du routeur est l’entité réseau qui achemine les messages IPv6 entre les nœuds de Thread, qu’il s’agisse d’autres nœuds de routeur ou de périphériques finaux. Il s’agit d’une fonction de réseau du réseau Thread.
Rôle de périphérique final
Le rôle de périphérique final est un nœud-feuille (leaf node). Du point de vue du réseau, il ne communique qu’avec son parent (un routeur). Ces rôles de périphérique final sont celui de REED (Router Eligible End Device, c’est-à-dire un périphérique final pouvant jouer le rôle de routeur) ou de périphérique final.
Rôle de leader
Le rôle de leader est un rôle spécifique du nœud d’un routeur. Le premier nœud du routeur du réseau deviendra un leader. Le leader est chargé de prendre les décisions relatives au réseau. Par exemple, le leader peut promouvoir au rôle de routeur les périphériques admissibles afin d’améliorer la connectivité lorsque nécessaire. Il n’y a qu’un seul leader dans un réseau Thread. Si le leader échoue, un autre routeur deviendra le leader. Tous les routeurs stockent les données du réseau, mais seul le leader peut y apporter des modifications.
REED (périphérique final pouvant jouer le rôle de routeur)
Un REED peut avoir le rôle de routeur de Thread ou le rôle de périphérique final de Thread, et se mettra à niveau dynamiquement vers un routeur à partir d’un périphérique final à mesure que le réseau Thread se développera et, inversement, se rétrogradera de routeur à périphérique final à mesure que le réseau se contractera. Le REED est très utile, car il permet au réseau Thread de s’autogérer.
ED (périphérique final)
Ce périphérique prend uniquement en charge le rôle de périphérique final. Le périphérique final ne peut se connecter qu’à un périphérique doté d’un rôle de routeur ou de routeur de bordure.
SED (périphérique final dormant)
Ce périphérique prend uniquement en charge le rôle de périphérique final, mais il a la capacité de se mettre en veille. La principale différence est que lorsque le périphérique se met en veille, il se détache du réseau Thread (c’est-à-dire sans communication radio). Le routeur parent mettra en cache le trafic entrant pour un tel périphérique. Ainsi, lorsqu’il sera à nouveau actif, il recevra le trafic entrant.
Le SED ne peut se connecter qu’à un périphérique doté d’un rôle de routeur ou de routeur de bordure, et il changera automatiquement de parent s’il perd la connectivité.
Extenseur de maillage
Ce périphérique n’a pas été mentionné précédemment, mais il s’agit en fait d’un routeur alimenté par ligne ou d’un REED. Le but de ce périphérique est d’étendre la portée du réseau maillé, c’est-à-dire qu’il peut être placé là où une liaison réseau directe est faible. Ce périphérique peut être un périphérique Thread pur, ce qui signifie qu’aucune fonction d’application n’est implémentée sur le périphérique.
Implications
Donc, comment ces rôles Thread s’appliquent-ils aux périphériques KNX IoT ?
Les périphériques KNX IoT basés sur Thread devront être implémentés en tant que REED, ED ou SED, sinon ils ne feront pas partie du réseau Thread. Cela semble être une décision distincte de la fonction du périphérique KNX, mais est-ce vraiment le cas ?
Tous les périphériques KNX IoT implémenteront un ensemble de blocs fonctionnels, c’est-à-dire la fonction du périphérique. La sélection matérielle pour déterminer la fonction du périphérique dépendra du fait que le périphérique doit être alimenté par le secteur (toujours allumé) ou par des sources à faible consommation d’énergie (telles que la récupération d’énergie ou alimenté par batterie). La règle générale est que si le périphérique est alimenté par secteur, il faut construire un REED. Pour toutes les autres sources, on peut créer un périphérique final et même un périphérique final dormant si la fonction du périphérique KNX IoT peut être réalisée avec du matériel qui consomme peu d’énergie ou peut être périodiquement éteint (c’est-à-dire qu’il ne consomme pas d’énergie active).
Exemples d’ED et de SED KNX IoT
Par exemple, si un périphérique n’envoie des données que périodiquement, comme c’est le cas avec un capteur de température, et si l’acquisition des données du capteur de température est de faible consommation, on peut créer un SED. Si l’acquisition des données du capteur est continue, alors un SED peut toujours être réalisé (afin d’éviter une consommation d’énergie supplémentaire utilisée par l’émetteur RF), mais il pourrait s’agir d’un ED.
Pour les périphériques qui reçoivent des requêtes entrantes et nécessitent une réponse rapide, il peut s’agit d’un ED ou d’un REED.
Pour les périphériques qui reçoivent des requêtes entrantes, mais dont la réponse sera lente, comme un capteur de qualité de l’air, ceux-ci peuvent être exécutés en tant que SED.
Les périphériques nécessitant une alimentation secteur en raison de leur matériel supplémentaire doivent être construits comme des REED. Les luminaires en sont des exemples.
Résumé
Thread permet de développer des périphériques KNX IoT de manière à s’adapter au budget énergétique requis. Le choix de REED, ED ou SED doit se faire en fonction du besoin en énergie des périphériques qui assurent la fonction du périphérique.
Bruno Johnson et Wouter van der Beek sont respectivement PDG et COO de Cascoda Limited. Cascoda est une société de communications qui fabrique des radios et des modules à semi-conducteurs IoT sécurisés et dirige le développement de normes de communications IoT sécurisées pour les bâtiments et les villes intelligentes. Ses produits résolvent les problèmes de portée, de fiabilité, de sécurité, de puissance et d’évolutivité pour l’IoT industriel et commercial grâce à des innovations brevetées et aux dernières normes les plus sécurisées, le tout intégré dans des modules IoT à très faible consommation et peu coûteux.
