Progettazione di applicazioni intelligenti Bluetooth Low Energy con rete a maglie Bluetooth - Parte 2

Nota: La parte 1 di questa serie in due parti ha illustrato in dettaglio l'architettura e le capacità del protocollo Bluetooth Mesh 1.0. Questa parte 2 descrive come integrare la rete a maglie Bluetooth nei progetti Bluetooth Low Energy utilizzando chip e kit di sviluppo.

La rete a maglie Bluetooth aggiunge i notevoli vantaggi della connettività di rete al rinomato protocollo a breve raggio. Tali vantaggi sono stati esaminati in dettaglio nella Parte 1. La specifica comporta tuttavia anche nuove sfide di progettazione, specialmente per quanto concerne l'implementazione dei suoi modelli.

La chiave per superare tali sfide consiste nello sfruttare il miglioramento degli strumenti di sviluppo per acquisire una maggiore familiarità con la rete a maglie Bluetooth. Questo articolo illustra come utilizzare una selezione di elementi hardware e software, kit di sviluppo (DK) e kit di sviluppo software (SDK) per impostare e realizzare applicazioni con rete a maglie Bluetooth.

Strumenti di sviluppo con rete a maglie Bluetooth

Lo stack di rete a maglie Bluetooth include un livello host completamente nuovo che condivide alcuni concetti con il livello host BLE, ma non è compatibile con esso. Iniziano ora a diventare disponibili versioni iniziali dello stack di rete a maglie Bluetooth per lo sviluppo tecnico, tipicamente nell'ambito di un SDK.

Poiché la specifica della rete a maglie Bluetooth è complementare a quella Bluetooth di base, i fornitori non sono soggetti ad alcun obbligo di aggiornare i loro strati fisici (PHY) Bluetooth Low Energy (BLE) o i loro stack software per supportarla. L'aggiunta di una rete a maglie Bluetooth richiede tuttavia ai fornitori di introdurre la propria implementazione dello stack a supporto dei clienti.

Il fornitore BLE Nordic Semiconductor ha ad esempio introdotto l'SDK nRF5 per Mesh. Il kit include uno stack di rete a maglie Bluetooth e una selezione di driver, librerie ed esempi per le applicazioni con rete a maglie. L'SDK funziona in vari ambienti di sviluppo integrati (IDE) e con diversi compilatori, fra cui SEGGER Embedded Studio, di Segger Microcontroller Systems e CMake.

Dato che la rete a maglie Bluetooth è compatibile con tutte le versioni di BLE (vale a dire 4.0, 4.1, 4.2 e 5), l'SDK Nordic per reti a maglie funzionerà in ultimo con tutti i suoi chip BLE. La versione corrente funziona tuttavia soltanto con le più recenti soluzioni BLE della serie nRF52 dell'azienda, come il chip di fascia media nRF52832 conforme allo standard Bluetooth 5.

Dato che non vi sono variazioni dello stack software o PHY BLE, è possibile eseguire lo sviluppo di una rete a maglie Bluetooth su un DK esistente che incorpori il dispositivo target. Per il chip nRF52832 è consigliato il DK nRF52 (Figura 1).

Figura 1: L'SDK di Nordic Semiconductor per reti a maglie funziona con il DK nRF52, che include un dispositivo target SoC nRF52832. (Immagine per gentile concessione di Nordic Semiconductor)

Lo sviluppo delle reti a maglie richiede la presenza di almeno (o preferibilmente più di) tre dispositivi che comunichino fra loro, simulando un ambiente di rete a maglie. In linea di principio, per rappresentare i nodi di una rete a maglie è possibile utilizzare vari DK, ma tale soluzione presenta lo svantaggio di un notevole aumento dei costi per l'hardware di sviluppo. Un approccio alternativo consiste nell'utilizzare un DK e nell'acquistare moduli BLE testati e verificati (basati sul dispositivo target) per creare nodi aggiuntivi. Per lo sviluppo con il modello nRF52832 di Nordic, sono opzioni valide i moduli BMD-300 di Rigado o BL652-SA-01-T/R di Laird.

Cypress Semiconductor ha adottato un approccio simile a Nordic. L'azienda offre un SDK per rete a maglie Bluetooth per il suo DK BCM92073X WICED Smart, basato sul PHY BCM20736S Bluetooth v4.1 di Cypress. Fra i moduli BLE idonei per lo sviluppo di reti a maglie sulla base di tale PHY figura il modello ISM20736S di Inventek.

Comprensione dei modelli

Gli strumenti hardware, software e di sviluppo offerti da Nordic e Cypress vengono forniti con un corredo di esempi e tutorial che guidano gli sviluppatori lungo le varie fasi necessarie per realizzare applicazioni semplici con rete a maglie Bluetooth. Prima di intraprendere il primo progetto, è tuttavia utile scorrere i relativi tutorial, per comprendere le caratteristiche esclusive dell'architettura di una rete a maglie Bluetooth, in quanto la stessa riveste un'importanza fondamentale per il processo di progettazione.

Alcuni tutorial evidenziano il fatto che pur essendo disponibili nodi di rete a maglie Bluetooth di quattro tipologie generali (vedere la Parte 1 di questa serie di due articoli), le capacità di ciascun nodo sono determinate dal suo modello (o dai suoi modelli). La comprensione dei modelli è pertanto essenziale per utilizzare al meglio le capacità di una rete a maglie Bluetooth.

Una rete a maglie Bluetooth offre la flessibilità necessaria per creare nuove applicazioni con rete a maglie in quanto gli sviluppatori possono realizzare modelli che consentono ai dispositivi di attuare numerosi comportamenti personalizzati. Un modello definisce gli stati richiesti, i messaggi che agiscono su tali stati e il relativo comportamento. Tutte le comunicazioni su una rete a maglie sono agevolate dai messaggi.

Uno stato è un valore che rappresenta una condizione di un elemento. Un elemento è un'entità indirizzabile di un dispositivo o di un nodo. Ciascun dispositivo è dotato di almeno un elemento (primario) ed eventualmente di uno o più elementi secondari. Il numero e la struttura degli elementi di un nodo non variano nel corso della sua vita utile. Un elemento che 'espone' uno stato è detto server. Un elemento che 'accede' a uno stato è detto client.

È importante osservare che esistono tre tipi di modelli, vale a dire server, client e di controllo. Un modello server è costituito da uno o più stati che coprono uno o più elementi. Esso definisce una serie di messaggi obbligatori che è in grado di trasmettere o di ricevere, il comportamento di un elemento quando riceve e trasmette i messaggi, e qualunque altro comportamento successivo alla trasmissione o alla ricezione dei messaggi.

Un modello client definisce una serie di messaggi che un client utilizza per richiedere, modificare o 'consumare' i corrispondenti stati server, definiti da un modello server. Il modello client non dispone di stati.

Un modello di controllo è in grado di combinare funzionalità del modello client (per comunicare con altri modelli server) e del modello server (per comunicare con altri modelli client). Un modello di controllo può inoltre contenere una logica di controllo, vale a dire un insieme di regole e comportamenti che coordinano le interazioni del modello di controllo fra gli altri modelli cui esso si collega (Figura 2).

Figura 2: L'illustrazione mostra lo schema della struttura dei modelli degli elementi di un dispositivo di una rete a maglie Bluetooth che implementa un modello di controllo. Il dispositivo C è in grado di comunicare con i modelli server (presenti nei dispositivi A e B) come un client (messaggi X, Y e Z, e rispettivamente R, S e T), nonché con i modelli client (presenti nel dispositivo D) come un server (supportando i messaggi A, B e C). (Immagine per gentile concessione di Bluetooth SIG)

Per illustrare l'uso dei modelli nell'ambito di un esempio pratico, prendiamo in esame una ciabatta con due prese di alimentazione indipendenti, ciascuna in grado di controllare l'uscita di potenza, e con un modulo radio BLE integrato che consente alla ciabatta di collegarsi a una rete a maglie Bluetooth.

Il dispositivo (la presa multipla) è dotata di due elementi, ciascuno dei quali rappresenta una delle due prese di alimentazione. Le funzionalità di ciascun elemento sono definite dal modello Server con livello di potenza generico, che definisce una serie di stati su un server, nonché un insieme di messaggi che agiscono sugli stati. È possibile inviare al dispositivo un messaggio Impostazione livello di potenza generico per controllare la potenza in uscita. Il messaggio è indirizzato a uno degli elementi che rappresentano le prese.

È inoltre possibile controllare le prese mediante un dispositivo generico, come un dimmer, che implementa il modello Client con livello generico. Tale modello imposta un livello desiderato pari a zero, a un valore massimo o a uno compreso fra i due. Il controllo della potenza diretta alle prese avviene tramite un collegamento fra gli stati. In ciascuna presa di alimentazione, lo stato Potenza generica effettiva è collegato allo stato Livello generico. Un Client con livello generico invia messaggi di Livello generico al Server con livello generico. Lo stato di Livello generico viene modificato, e ciò modifica a sua volta (tramite il collegamento definito) lo stato di Potenza generica effettiva che controlla l'uscita di potenza.

Poiché gli elementi sono in grado di indicare gli stati, ciascuna presa può indicare il livello di potenza e il consumo energetico del dispositivo ad essa collegato. Il consumo energetico viene indicato utilizzando i messaggi definiti dal modello Server sensore.

Realizzazione di una rete a maglie Bluetooth

Assumendo che abbiano acquisito una certa familiarità sia con l'architettura di rete a maglie Bluetooth, sia con lo sviluppo BLE (vedere l'articolo DigiKey dal titolo "SoC e strumenti Bluetooth Low Energy compatibili con Bluetooth® 4.1, 4.2 e 5 pronti ad affrontare le sfide IoT" per ulteriori informazioni sulla progettazione BLE in generale) e dispongano di un SDK per reti a maglie Bluetooth, di un SDK host, di un DK e di ulteriori moduli o DK per installare una rete, gli sviluppatori possono configurare con relativa facilità l'implementazione di una rete a maglie Bluetooth.

Il primo passo consiste nel realizzare lo stack di rete a maglie. Nel caso di Nordic, la realizzazione dello stack avviene utilizzando l'IDE selezionato. Con SEGGER Embedded Studio, ad esempio, lo stack viene realizzato utilizzando uno degli esempi inclusi nell'SDK per reti a maglie Bluetooth (ad esempio quello denominato "interruttore della luce") e compilato utilizzando l'IDE.

Il PHY target sul DK viene quindi cancellato e riprogrammato con lo stack di rete a maglie Bluetooth compilato e con lo stack BLE. Una volta programmati e verificati gli stack, è possibile utilizzare l'SDK per impostare e realizzare altre reti a maglie.

Provisioning: gli strumenti di sviluppo Nordic includono un'interfaccia di programmazione delle applicazioni (API) di provisioning, che viene utilizzata per aggiungere nuovi dispositivi a una rete a maglie. Il provisioning è gestito da provisioner (vale a dire dispositivi già collegati alla rete e precedentemente configurati per l'attività di provisioning) utilizzati per fornire ai nuovi dispositivi le informazioni loro necessarie per unirsi a una rete a maglie. I nuovi dispositivi ricevono inizialmente una chiave di rete, un indirizzo e una chiave di dispositivo per la creazione di un canale sicuro per le operazioni di configurazione dopo il provisioning.

L'API consente allo sviluppatore di avviare l'ascolto il beacon trasmesso dai nodi che ancora non hanno partecipato al provisioning (o provisionee, vale a dire i dispositivi da aggiungere alla rete) su uno dei tre canali di advertising di BLE. La rete a maglie Bluetooth trasmette e riceve i messaggi utilizzando i canali di advertising di BLE invece dei 37 canali dati con larghezza di banda piena. Le richieste di collegamento in ingresso sul canale vengono automaticamente accettate dal provisioner.

Una volta stabilito, il collegamento viene autenticato utilizzando un metodo fuori banda (OOB) per accertarsi che il dispositivo che si unisce alla rete sia il target previsto. L'uso dei metodi OOB riduce le probabilità di attacchi "man-in-the-middle" provenienti da dispositivi in ascolto per spiare l'allocazione dello spettro BLE. Un evento API fornisce poi al dispositivo i dati di provisioning e la chiave di dispositivo.

Configurazione: l'applicazione "interruttore della luce" di Nordic (inclusa nel kit SDK) mostra come sviluppare applicazioni con ruoli sia di provisioner, sia di provisionee. Nella demo, un modello client Interruttore della luce (l'interruttore) è il provisioner e il modello server Interruttore della luce (la lampadina) è il provisionee.

L'esempio fornito da Nordic sfrutta al massimo il fatto che il server più semplice della specifica Bluetooth Mesh è un server OnOff generico, ad indicare che il server si trova nello stato on oppure off. Il client più semplice è ad esempio un client OnOff generico, in grado di controllare un server OnOff generico tramite messaggi definiti dal modello OnOff generico.

Quando riceve un messaggio GET o un messaggio SET (affidabile) da un modello client, il modello server in questione invia come risposta il valore corrente dello stato OnOff. Tale scambio mantiene aggiornato il client sullo stato del server (Figura 3).

Figura 3: Messaggi e opcode ATT supportati dal modello OnOff generico. (Immagine per gentile concessione di Nordic Semiconductor)

Il server di configurazione viene utilizzato per rappresentare una configurazione di rete a maglie di un dispositivo ed è un requisito obbligatorio per i nodi di una rete a maglie Bluetooth. Il server di configurazione gestisce le comunicazioni con il client di configurazione, e le istruzioni provenienti da esso (controllato dal provisioner).

La configurazione inizia una volta completato il provisioning. Il provisioner legge i dati relativi alla composizione del provisionee per identificare i metadati del dispositivo e i collegamenti fra i modelli e gli elementi presenti nel dispositivo. Vengono poi aggiunte la/le chiave/i di applicazione e/o quella/e di rete, che vengono collegate una ai vari modelli (Figura 4).

Figura 4: Diagramma di flusso di provisioning e configurazione del kit SDK nRF5 per Mesh. Le chiamate "nrf_mesh…" sono funzioni API. (Immagine per gentile concessione di Nordic Semiconductor)

L'aggiunta di ulteriori dispositivi alla rete comporta semplicemente la ripetizione dei processi di provisioning e configurazione per ciascun nuovo nodo.

Pubblicazione e sottoscrizione: la fase finale della realizzazione e della configurazione di un'applicazione iniziale consiste nel configurare lo stato di pubblicazione dei modelli. Si tratta ad esempio dell'indirizzo utilizzato per pubblicare gli eventi di stato, con quale chiave e utilizzando quale valore "Time-To-Live" (TTL), nonché le sottoscrizioni impostate.

Una volta pubblicati, i messaggi vengono inviati dall'indirizzo di pubblicazione di ciascun modello. La pubblicazione viene ad esempio utilizzata da un nodo di sensori che fornisce periodicamente i propri dati. I messaggi possono essere pubblicati una sola volta oppure ripetutamente, e vengono inviati a un indirizzo unicast, di gruppo o virtuale (vedere la parte 1 di questo articolo). La pubblicazione viene inoltre utilizzata dai modelli client per inviare messaggi ai modelli server.

La configurazione degli stati associati alla pubblicazione è in genere controllata da un provisioner tramite il modello di configurazione.

Quando si utilizza l'SDK di Nordic, i messaggi vengono pubblicati utilizzando la funzione API "access_model_publish()", che pubblica un messaggio secondo le impostazioni di pubblicazione (intervallo e destinazione) del modello di pubblicazione.

Le sottoscrizioni consentono ai modelli di mettersi in ascolto di messaggi in ingresso provenienti da indirizzi specifici. È possibile utilizzare tale capacità per ascoltare ad esempio i messaggi periodici pubblicati dai nodi di sensori. L'SDK di Nordic consente ai modelli di effettuare la sottoscrizione a un indirizzo assegnando un elenco di sottoscrizione con la funzione API "access_model_subscription_list_alloc()".

Si noti che quando si utilizza un modello client, non occorre effettuare la sottoscrizione all'indirizzo dal quale vengono inviati i messaggi per ricevere le risposte ai medesimi. Le sottoscrizioni vengono utilizzate soltanto per ricevere i messaggi non richiesti provenienti dai nodi.

Durante il processo di pre-sviluppo, può risultare vantaggioso collegare alla rete a maglie Bluetooth un dispositivo non abilitato per tale rete. Un esempio può consistere in uno smartphone che lo sviluppatore desidera utilizzare per controllare un prototipo di applicazione con rete a maglie per illuminazione intelligente. L'interazione fra il telefono cellulare e la rete a maglie avviene tramite l'interfaccia Generic Attribute Profile (GATT) dello smartphone e del dispositivo del nodo nello stack Bluetooth, invece che in quello Bluetooth Mesh.

Conclusione

Bluetooth Mesh introduce nuove capacità nelle applicazioni BLE. Non essendo incluso nella Core Specification originale, tuttavia, l'adozione delle reti a maglie ha dato origine ad alcuni compromessi e ha introdotto una certa complessità aggiuntiva nel processo di progettazione. Gli sviluppatori che hanno una certa familiarità con la progettazione basata sullo stack del protocollo Bluetooth si troveranno avvantaggiati rispetto a coloro che non dispongono di alcuna conoscenza, ma l'implementazione di una rete a maglie Bluetooth richiede anche ai progettisti esperti di apprendere una nuova architettura e di comprenderne sfumature quali stati, elementi e modelli.

È possibile alleviare le sfide di progettazione operando in partnership con fornitori quali Nordic Semiconductor o Cypress Semiconductor. Tali fornitori hanno ora reso disponibili stack di rete a maglie Bluetooth che si affiancano le loro soluzioni BLE mature. Gli stack sono accompagnati da SDK appositamente progettati, che consentono agli sviluppatori di utilizzare chip, firmware e strumenti di progettazione con cui hanno familiarità per accelerare il processo di apprendimento associato alla progettazione delle applicazioni con rete a maglie Bluetooth.

Riferimento

1. "Profilo Mesh", Specifica Bluetooth v. 1.0, Bluetooth SIG, luglio 2017.