Conception d'applications Bluetooth Low-Energy intelligentes avec Bluetooth Mesh - 2e partie

Note de l'éditeur : la 1re partie de cette série en deux parties décrit l'architecture et les capacités du protocole Bluetooth Mesh 1.0. Ici, la 2e partie décrit comment intégrer Bluetooth Mesh dans les conceptions Bluetooth Low-Energy à l'aide de puces et de kits de développement.

Bluetooth Mesh apporte les avantages notables de la mise en réseau au protocole populaire à courte portée. Ceux-ci ont été abordés en détail dans la première partie. Cependant, la spécification implique également de nouveaux défis en matière de conception, en particulier lorsqu'il s'agit d'implémenter les modèles associés.

La clé pour surmonter ces défis consiste à tirer parti des outils de développement mis à niveau pour mieux se familiariser avec le Bluetooth Mesh. Cet article explique comment utiliser une sélection d'outils matériels et logiciels Bluetooth, de kits de développement (DK) et de kits de développement logiciel (SDK) pour configurer et créer des applications Bluetooth Mesh.

Outils de développement Bluetooth Mesh

La pile Bluetooth Mesh comprend une couche hôte entièrement nouvelle qui partage certains concepts avec la couche hôte BLE, mais n'est pas compatible avec celle-ci. Les premières versions de la pile Bluetooth Mesh sont désormais disponibles pour le développement technique, généralement dans le cadre d'un SDK.

Étant donné que Bluetooth Mesh est une spécification complémentaire à la spécification principale Bluetooth, les fournisseurs n'ont pas besoin de mettre à jour leurs couches physiques (PHY) ou piles logicielles Bluetooth Low-Energy (BLE) pour le prendre en charge. Cependant, l'ajout de Bluetooth Mesh nécessite que les fournisseurs mettent en place leurs propres implémentations de la pile pour leurs clients.

Par exemple, le fournisseur BLE Nordic Semiconductor a créé le SDK nRF5 pour Mesh. Le kit comprend une pile Bluetooth Mesh, une sélection de pilotes, de bibliothèques et d'exemples pour les applications maillées. Le SDK fonctionne dans plusieurs environnements de développement intégrés (IDE) et compilateurs, notamment SEGGER Embedded Studio de Segger Microcontroller Systems et CMake.

Étant donné que Bluetooth Mesh est compatible avec toutes les versions de BLE (à savoir : 4.0, 4.1, 4.2 et 5), le SDK maillé de Nordic fonctionnera avec toutes ses puces BLE. La version actuelle, cependant, ne fonctionne qu'avec les dernières solutions BLE série nRF52 de la société, comme la puce moyenne portée compatible Bluetooth 5 nRF52832.

Étant donné que la pile logicielle ou la couche physique BLE ne change pas, le développement de Bluetooth Mesh peut être effectué avec un kit de développement existant qui comprend le dispositif cible. Le kit de développement recommandé pour la puce nRF52832 est le kit de développement nRF52 DK (Figure 1).

Figure 1 : Le SDK de maillage de Nordic Semiconductor fonctionne avec le kit de développement nRF52 qui intègre un dispositif cible à système sur puce nRF52832. (Source de l'image : Nordic Semiconductor)

Le développement d'un réseau maillé nécessite au moins trois dispositifs (et de préférence plus) pour communiquer et simuler un environnement maillé. Idéalement, il est possible d'utiliser plusieurs kits de développement pour représenter les nœuds d'un réseau maillé, mais cela présente l'inconvénient d'augmenter considérablement les coûts de matériel de développement. Une autre approche consiste à utiliser un kit de développement et à acheter des modules BLE testés et vérifiés (selon le dispositif cible) pour former les nœuds supplémentaires. Pour un développement avec le nRF52832 de Nordic, le BMD-300 de Rigado ou le BL652-SA-01-T/R de Laird constituent d'excellentes options de modules.

Cypress Semiconductor a adopté une approche similaire à celle de Nordic. La société propose un SDK Bluetooth Mesh pour son kit de développement WICED Smart BCM92073X basé sur la couche physique BCM20736S Bluetooth v4.1 de Cypress. Les modules BLE appropriés pour les travaux de développement de réseaux maillés basés sur cette couche physique incluent l'ISM20736S d'Inventek.

Comprendre les modèles

Le matériel, les logiciels et les outils de développement de Nordic et Cypress sont fournis avec des exemples et des tutoriels pour guider les développeurs dans les étapes de création d'une application Bluetooth Mesh simple. Mais avant de se lancer dans une première conception, il est utile de parcourir les tutoriels associés pour comprendre les caractéristiques uniques de l'architecture Bluetooth Mesh, car elles ont une influence majeure sur le processus de conception.

Ces tutoriels soulignent le fait que même s'il existe quatre types génériques de nœuds Bluetooth Mesh (voir la première partie de cette série d'articles), les capacités de chacun sont déterminées par le ou les modèles associés. La compréhension des modèles est la clé pour tirer le meilleur parti des capacités de Bluetooth Mesh.

Bluetooth Mesh offre la flexibilité requise pour créer de nouvelles applications maillées, car les développeurs peuvent créer des modèles qui permettent aux dispositifs d'adopter de nombreux comportements personnalisés. Un modèle définit les états requis, les messages qui agissent sur ces états et le comportement associé. Toutes les communications sur un réseau maillé sont facilitées par les messages.

Un état est une valeur représentant une condition d'un élément. Un élément est une entité adressable d'un dispositif ou d'un nœud. Chaque dispositif possède au moins un élément (primaire) et peut comporter un ou plusieurs éléments secondaires. Le nombre et la structure des éléments ne changent pas pendant la durée de vie du nœud. Un élément « exposant » un état est appelé un serveur. Un élément « accédant » à un état est appelé un client.

Fait important, il existe trois types de modèles : serveur, client et commande. Un modèle serveur est composé d'un ou de plusieurs états couvrant un ou plusieurs éléments. Il définit un ensemble de messages obligatoires qu'il peut transmettre ou recevoir, le comportement de l'élément lorsqu'il transmet et reçoit les messages, et tout comportement supplémentaire qui se produit après la transmission ou la réception des messages.

Un modèle client définit un ensemble de messages qu'un client utilise pour demander, modifier ou « consommer » les états du serveur correspondant, comme cela est défini par un modèle serveur. Le modèle client n'a pas d'états.

Un modèle de commande peut combiner les fonctionnalités du modèle client (pour communiquer avec d'autres modèles serveur) et les fonctionnalités du modèle serveur (pour communiquer avec d'autres modèles client). Un modèle de commande peut également contenir une logique de commande, c'est-à-dire un ensemble de règles et de comportements qui coordonnent les interactions du modèle de commande entre les autres modèles auxquels le modèle de commande est relié (Figure 2).

Figure 2 : Structure des modèles d'éléments d'un dispositif Bluetooth Mesh qui implémente un modèle de commande. Le dispositif C peut communiquer avec les modèles serveur (dans les dispositifs A et B) en tant que client (messages X, Y et Z, et messages R, S et T respectivement) et avec les modèles client (dans le dispositif D) en tant que serveur (messages A, B et C). (Source de l'image : Bluetooth SIG)

Pour illustrer l'utilisation des modèles dans un exemple pratique, imaginez une multiprise comprenant deux prises indépendantes, chacune capable de contrôler la sortie d'alimentation et dotée d'une radio BLE, permettant ainsi à la multiprise de se connecter à un réseau Bluetooth Mesh.

Le dispositif (la multiprise) comporte deux éléments représentant chacune des deux prises. La fonctionnalité de chaque élément est définie par le modèle de serveur à niveau de puissance générique qui définit un ensemble d'états sur un serveur, ainsi qu'un ensemble de messages fonctionnant sur les états. Un message de définition du niveau de puissance générique peut être envoyé au dispositif pour contrôler la puissance de sortie. Le message est adressé à l'un des éléments de la prise.

Les prises peuvent également être contrôlées par un dispositif générique, comme un gradateur, qui implémente le modèle client à niveau générique. Ce modèle définit un niveau souhaité sur zéro, une valeur maximale ou une valeur intermédiaire. L'alimentation des prises est contrôlée par liaison d'état. Dans chaque prise, l'état de la puissance générique réelle est lié à l'état de niveau générique. Un client à niveau générique envoie des messages de niveau générique au serveur à niveau générique. L'état de niveau générique est modifié, ce qui à son tour (via la liaison définie) modifie l'état de la puissance générique réelle qui contrôle la sortie de puissance.

Étant donné que les éléments peuvent signaler des états, chaque prise peut indiquer le niveau de puissance ainsi que la consommation d'énergie d'un dispositif branché sur la prise. La consommation d'énergie est indiquée à l'aide de messages définis par le modèle de serveur de capteur.

Conception d'un réseau Bluetooth Mesh

En supposant qu'un développeur ait acquis une certaine connaissance de l'architecture Bluetooth Mesh et du développement BLE (voir l'article DigiKey : « Les outils et systèmes sur puce Bluetooth Low-Energy, compatibles avec Bluetooth 4.1, 4.2 et 5, répondent aux défis de l'IoT » pour en savoir plus sur la conception générale BLE), et dispose d'un SDK Bluetooth Mesh, d'un SDK hôte, d'un kit de développement et de modules ou de kits de développement supplémentaires pour configurer un réseau, il peut configurer une implémentation Bluetooth Mesh assez facilement.

La première étape consiste à créer la pile de maillage. Dans le cas de Nordic, la pile est construite avec l'environnement de développement intégré sélectionné. Par exemple, avec SEGGER Embedded Studio, la pile est créée à l'aide de l'un des exemples fournis avec le SDK Bluetooth Mesh (comme l'exemple du commutateur d'éclairage) et compilée à l'aide de l'environnement de développement intégré.

La couche physique cible du kit de développement est ensuite effacée et reprogrammée avec la pile Bluetooth Mesh compilée et la pile BLE. Une fois les piles programmées et vérifiées, le SDK peut servir à configurer et créer des réseaux maillés.

Provisionnement : les outils de développement de Nordic incluent une interface de programmation d'applications (API) de provisionnement qui permet d'ajouter de nouveaux dispositifs au réseau maillé. Le provisionnement est géré par des utilitaires de provisionnement (dispositifs déjà connectés au réseau et précédemment configurés pour la tâche de provisionnement) utilisés pour fournir aux nouveaux dispositifs les informations dont ils ont besoin pour rejoindre un réseau maillé. Initialement, le dispositif est fourni avec une clé réseau, une adresse et une clé de dispositif pour établir un canal sécurisé pour la configuration après le provisionnement.

L'API permet au développeur de commencer à écouter la balise de radiodiffusion du nœud non provisionné (ou provisionné et à ajouter au réseau) envoyée sur l'un des trois canaux d'annonce BLE. Bluetooth Mesh transmet et reçoit les messages en utilisant les canaux d'annonce BLE plutôt que les 37 canaux de données à bande passante complète. Les demandes de liaisons entrantes sur le canal sont automatiquement acceptées par l'utilitaire de provisionnement.

Une fois la liaison établie, elle est authentifiée à l'aide d'une méthode hors bande (OOB) afin de s'assurer que le dispositif rejoignant le réseau est bien la cible visée. L'utilisation de méthodes hors bande réduit les risques d'attaques de l'intercepteur à partir de dispositifs qui écoutent l'attribution de spectre BLE. Un événement API fournit ensuite les données de provisionnement et la clé du dispositif.

Configuration : l'application de « commutateur d'éclairage » de Nordic (fournie avec le SDK) montre comment développer des applications avec des rôles d'utilitaire de provisionnement et de provisionné. Dans la démonstration, un modèle client de commutateur d'éclairage (le commutateur) est l'utilitaire de provisionnement, tandis que le modèle de serveur de commutateur d'éclairage (l'ampoule) est le provisionné.

L'exemple de Nordic exploite le fait que le serveur le plus simple de la spécification Bluetooth Mesh est un serveur OnOff générique, ce qui signifie que le serveur est activé ou désactivé. Par exemple, le client le plus simple est un client OnOff générique, capable de contrôler le serveur OnOff générique via les messages définis par le modèle OnOff générique.

Lorsque ce modèle de serveur reçoit un message GET ou SET (fiable) de la part d'un modèle client, il envoie la valeur actuelle de l'état OnOff en réponse. Cela permet au client de rester au courant de l'état du serveur (Figure 3).

Figure 3 : Messages et codes d'opération ATT pris en charge par le modèle OnOff générique. (Source de l'image : Nordic Semiconductor)

Le serveur de configuration est utilisé pour représenter la configuration de réseau maillé d'un dispositif et est obligatoire pour les nœuds Bluetooth Mesh. Le serveur de configuration gère la communication avec le client de configuration (contrôlé par l'utilitaire de provisionnement) et les instructions qu'il envoie.

La configuration démarre après la fin du provisionnement. L'utilitaire de provisionnement lit les données de composition du provisionné pour identifier les métadonnées du dispositif et savoir quels modèles sont liés à quel élément du dispositif. Ensuite, les clés d'application et/ou de réseau sont ajoutées et reliées aux différents modèles (Figure 4).

Figure 4 : Diagramme de configuration et de provisionnement avec le kit de développement nRF5 pour Mesh. Les commandes « nrf_mesh… » sont des fonctions API. (Source de l'image : Nordic Semiconductor)

L'ajout de dispositifs supplémentaires au réseau consiste simplement à répéter le processus de configuration et de provisionnement pour chaque nouveau nœud.

Publication et abonnement : la dernière étape de la configuration et de la création d'une application initiale consiste à configurer l'état de publication des modèles. Par exemple, l'adresse utilisée pour publier les événements d'état, avec la clé correspondante, en utilisant la valeur TTL (Time-To-Live), et les abonnements.

Les messages sont envoyés lorsqu'ils sont publiés à partir de l'adresse de publication de chaque modèle. La publication est utilisée, par exemple, par un nœud de capteur indiquant périodiquement des données. Les messages peuvent être publiés une seule fois ou répétés, et sont envoyés à une adresse d'envoi individuel, à un groupe ou à une adresse virtuelle (voir la 1re partie de cet article). La publication est également utilisée par les modèles client pour envoyer des messages aux modèles serveur.

La configuration des états liés à la publication est généralement contrôlée par un utilitaire de provisionnement via le modèle de configuration.

Lors de l'utilisation du SDK de Nordic, les messages sont publiés à l'aide de la fonction API « access_model_publish() », qui publie un message en fonction des paramètres de publication (intervalle, destination) du modèle de publication.

Les abonnements permettent aux modèles d'écouter les messages entrants provenant d'adresses spécifiques. Cela peut être utilisé pour écouter, par exemple, les messages périodiques publiés à partir des nœuds de capteurs. Le SDK de Nordic permet un abonnement des modèles à une adresse en allouant une liste d'abonnements à l'aide de la fonction API « access_model_subscription_list_alloc() ».

Notez que lors de l'utilisation d'un modèle client, il n'est pas nécessaire de s'abonner à l'adresse à partir de laquelle les messages sont envoyés pour recevoir des réponses à ces messages. Les abonnements sont uniquement utilisés pour recevoir des messages non sollicités provenant de nœuds.

Pendant le processus de développement, il peut être avantageux de connecter un dispositif non compatible Bluetooth Mesh au Bluetooth Mesh. Imaginons par exemple un smartphone que le développeur souhaite utiliser pour contrôler un prototype d'application de maillage d'éclairage intelligent. L'interaction entre le mobile et le réseau maillé se fait via l'interface GATT (profil d'attributs génériques) du smartphone et du nœud dans la pile Bluetooth, plutôt que dans la pile Bluetooth Mesh.

Conclusion

Bluetooth Mesh ajoute de nouvelles fonctionnalités aux applications BLE. Cependant, comme le protocole n'était pas inclus dans la spécification de base, l'adoption du maillage a introduit des compromis et ajouté une certaine complexité au processus de conception. Les développeurs qui connaissent déjà la conception avec la pile de protocoles Bluetooth seront avantagés par rapport à ceux qui ne la connaissent pas, mais même pour les ingénieurs expérimentés, l'implémentation de Bluetooth Mesh nécessite l'apprentissage d'une nouvelle architecture et la compréhension des états, des éléments et des modèles associés.

Le défi de la conception peut être simplifié par un partenariat avec un fournisseur comme Nordic Semiconductor ou Cypress Semiconductor. Ces fournisseurs ont lancé des piles Bluetooth Mesh pour compléter leurs solutions BLE éprouvées. Les piles sont accompagnées de kits de développement logiciel spécifiques qui permettent aux développeurs d'utiliser les puces, les micrologiciels et les outils de conception auxquels ils sont habitués. Ils peuvent ainsi apprendre plus rapidement à concevoir des applications Bluetooth Mesh.

Référence

1. "Mesh Profile", spécification Bluetooth v1.0, Bluetooth SIG, juillet 2017.