Torna a reti di sensori

Caso d’uso BLE

Date le particolarità della tecnologia, i casi d’uso per la rete di sensori sono quelli tipici applicazioni IoT indoor a corto/medio raggio, dove concorre con altre tecnologie di rete: WIFi, BLE e, sotto certe condizioni, LoRaWAN. Per la sensoristica Indoor ha praticamente gli stessi punti di forza di BLE con il quale è praticamente intercambiambile (ma non interoperabile).

alt text

Esiste però un ambito nel quale il BLE è attualmente senza rivali rispetto alle tecnologie BLE, WiFi e LoRaWAN: il tracciamento indoor degli asset aziendali e la localizzazione indoor degli utenti. Il meccanismo che consente queste funzioni si basa sulla trasmissione di particolari messaggi periodici detti beacon.

La tecnologia dei beacon è comune a quasi tutti i protocolli wireless moderni, compresi BLE, WiFi e LoRaWAN, che quindi sono in parte capaci anche loro delle funzioni di localizzazne suddette, ma in maniera molto meno precisa e versatile.

Aspetti critici

Elementi critici su cui bilanciare convenienze e saper fare delle scelte argomentate sono:

Architettura di una rete di reti

Di seguito è riportata l’architettura generale di una rete di reti di sensori. Essa è composta, a livello fisico, essenzialmente di una rete di accesso ai sensori e da una rete di distribuzione che fa da collante di ciascuna rete di sensori.

alt text

Rete di distribuzione

I gateway utilizzano la rete internet e/o una LAN per realizzare un collegamento verso il broker MQTT, per cui, in definitiva, la topologia risultante è, fisicamente, quella di più reti di accesso con tecnologia e topologia differente (a maglia nel caso di BLE) tenute insieme da una rete di distribuzione qualsiasi purchè sia di tipo TCP/IP (LAN o Internet).

Avere a disposizione una rete di distribuzione IP per i comandi e le letture è utile perchè permette di creare interfacce web o applicazioni per smartphone o tablet per:

Il gateway All-In-One potrebbe essere un dispositivo con doppia interfaccia, modem UMTS per l’accesso alla rete di distribuzione su Internet, BLE verso la rete di sensori. Può essere utile per realizzare un gateway BLE da campo da adoperare:

Federazione di reti BLE in Internet

L’albero degli apparati attivi di una rete di sensori + rete di distribuzione in Internet + server di gestione e controllo che potrebbe rappresentare tre edifici distanti domotizzati tramite BLE e federati tramite Internet:

alt text

Il bridge BLE (in realtà è un gateway e quindi pure un router) è normalmente anche il master o centrale della rete di sensori.

Il broker MQTT può essere installato in cloud, in una Virtual Private network, oppure On Premise direttamente nel centro di gestione e controllo.

Il gateway, quando collegato direttamente ad Internet, è normalmente anche un firewall (con funzioni di NAT se si adopera IPv4), mentre se collegato alla LAN (attraverso uno SW o un HUB wiereless) ha solamente la funzioni di:

Federazione di reti BLE su LAN

Partizionamento e ridondanza

Per quanto riguarda il numero dei gateway in una stessa LAN, il numero minimo necessario perchè la rete BLE funzioni è uno. Un gateway avente anche funzione di master nelle rete di sensori. Però, data la criticità di eventuali guasti su questo dispositivo (la rete di sensori diventa nel suo complesso inaccessibile), potrebbe essere opportuno prevedere:

La partizione di una rete BLE può essere utile in determinate situazioni, specialmente se si hanno un gran numero di dispositivi o se si vuole separare i dispositivi per zone o per scopi diversi. Ecco alcune situazioni in cui potrebbe essere vantaggioso partizionare una rete BLE:

Il partizionamento delle reti BLE può essere utile per migliorare l’efficienza, la sicurezza e la gestibilità di una infrastruttura IoT. Per partizionare una rete BLE, si potrebbero creare più centrali BLE, cioè più gateway, ciascuno con la propria rete di sensori da gestire, e utilizzare una LAN (compoasta da switch) per collegare le reti tra loro.

alt text

Canali di comunicazione principali in una rete di sensori

In sintesi, sono necessari almeno due canali di comunicazione che, insieme, complessivamente, realizzano la comunicazione tra sensori e gestore delle informazioni:

Broker MQTT

Il broker MQTT è solo una delle tante soluzioni possibili per realizzare un canale multicast di livello applicativo tramite cui un utente col ruolo di publisher è in grado di notificare una replica dello stesso messaggio a più subscribers. E’ utile per:

Il canale applicativo su cui vengono inviati i messaggi sono quindi i topic. Su un certo topic il dispositivo con il ruolo di output agisce come un publisher, mentre quello con il ruolo di input agisce come un subscriber.

Gli utenti, in ogni caso, si comportano tutti come client poiché sono loro che iniziano la connessione con il broker e non il viceversa.

alt text

Fasi del protocollo:

  1. Il Subscriber dichiara presso il broker il proprio interesse a ricevere notifiche riguardo ad un certo argomento (topic) effettuando una chiamata subscribe()
  2. il publisher pubblica un messaggio che riguarda un certo topic effettuando una chiamata publish()
  3. Il broker inoltra il messaggio a tutti i subscriber interessati a quel topic

L’ID MQTT è un identificativo che permette di individuare un dispositivo ma non è un indirizzo di livello 3, non individua la macchina host in base al suo IP, piuttosto è un indirizzo di livello applicativo noto solo ad un server centrale, cioè il broker. Un dispositivo IoT non è tenuto a conoscere l’IP di tutti gli altri dispositivi ma solamente quello del broker. Il broker soltanto sa gli indirizzi di tutti i dispositivi, conoscenza che acquisisce durante la fase di connessione di un client al broker, momento in cui avviene anche il recupero del’socket remoto del client.

Il broker, dal canto suo, associa ogni topic con tutti gli ID che sono registrati presso di esso come subscriber. Questa associazione è utilizzata per smistare tutti i messaggi che arrivano con un certo topic verso tutti gli ID che ad esso sono associati. Il topic diventa così un indirizzo di gruppo. La particolarità di questo indirizzo è che è gerarchico secondo una struttura ad albero, cioè gruppi di dispositivi possono essere suddivisi in sottogruppi più piccoli estendendo il nome del path con un ulteriore prefisso, diverso per ciascun sottogruppo. L’operazione può essere ripetuta ulteriormente in maniera ricorsiva.

Ad esempio, posso individuare le lampade della casa con il path luci e accenderle e spegnerle tutte insieme, ma posso sezionarle ulteriormente con il path luci/soggiorno con il quale accendere o spegnere solo quelle del soggiorno oppure con il path luci/soggiorno/piantane con il quale fare la stessa cosa ma solo con le piantane del soggiorno.

Osservando l’albero degli apparati attivi, si vede bene che, nelle reti BLE, il client MQTT (con il ruolo di publisher o di subscriber) è sempre il gateway che è anche il master della rete BLE.

In generale, su reti non IP, i client MQTT (con il ruolo di publisher o di subscriber) sono sempre i gateway di confine della rete di sensori. Le uniche reti di sensori che non hanno bisogno di un gateway di confine che sia, nel contempo anche client MQTT, sono le reti IP. Esistono ancora i gateway nelle reti IP ma con scopi diversi da quello di realizzare un client MQTT. Nelle reti IP, il client MQTT è, normalmente, direttamente a bordo del dispositivo sensore dotato di indirizzo IP (MCU).

Il vantaggio del broker MQTT è quello di poter gestire in modo semplice e standardizzato lo smistamento (inoltro) delle misure e dei comandi tra i vari portatori di interesse (stakeholder) di un cluster di reti di sensori, siano essi utenti umani, interfacce grafiche, server applicativi diversi o altri dispositivi IoT.

Alternative ad MQTT

Esistono molte altre soluzioni che magari sono più semplici e graficamente accattivanti ma che passano per portali proprietari o per servizi cloud a pagamento e nulla aggiungono di didatticamente rilevante ai nostri discorsi. Normalmente sono basate su webservices realizzati con protocolli Request/Response quali HTTPS e COAP.

Server di gestione

E’ un client del broker MQTT con funzioni sia di publisher che di subscriber per:

Semantica applicativa standard

La semantica delle entità BLE definisce:

Si può comprendere, quindi, come una rete BLE non si limiti a trasmettere, tra dispositivi sensori e attuatori, dei messaggi generici di cui lo stack di protocolli non capisce il significato e non conosce la struttura ma, bensì, trasmette proprio messaggi di comando e messaggi di stato ritagliati per una certa categoria di dispositivi domotici modellata dal protocollo. Essendo parte del protocollo, questi messaggi hanno la proprietà di essere standard, per cui sono comuni a dispositivi di marca diversa purchè siano dello stesso tipo previsto dallo standard.

E’ una differenza sostanziale con una rete LoraWAN o IP:

Esempio di Servizio Lampadina BLE

Ogni servizio, caratteristica e descrittore ha un UUID (Universaly Unique Identifier). Un UUID è un numero univoco a 128 bit (16 byte).

Service: Lampadina
UUID: 12345678-1234-5678-1234-56789abcdef0

Characteristic: On/Off
UUID: 12345678-1234-5678-1234-56789abcdef1
Properties: Read, Write, Notify
Value: Boolean (true = On, false = Off)

Scenario d’Uso

Immaginiamo di avere un’applicazione di controllo della casa intelligente che deve interagire con una lampadina BLE.

Accendere la Lampadina:

Spegnere la Lampadina:

Leggere lo Stato della Lampadina:

Gateway

Ruolo del gateway

Riassumendo, alla rete di distribuzione IP si collegano, quindi, una o più reti secondarie che servono da rete di accesso per i dispositivi sensori o attuatori con interfacce spesso di tipo non ethernet che necessitano di un gateway di confine con possibili funzioni di:

Il gateway è uno snodo nevralgico dei messaggi, per cui la sua posizione dovrebbe essere ben nota e accuratamente riportata in planimetria per permettere una sua rapida manutenzione/sostituzione.

E’ il dispositivo posto a cavallo tra la rete di accesso ai sensori e la rete di distribuzione.

Il gateway ha tante schede di interfaccia quanti sono i tipi diversi di rete a cui si collega. Inoltre il gateway deve possedere almeno una interfaccia capace di traffico ethernet (cablata o wifi) che lo colleghi alla rete di distribuzione.

Gateway come Client MQTT

In generale, su reti non IP, i client MQTT (con il ruolo di publisher o di subscriber) sono sempre i gateway di confine della rete di sensori. Le uniche reti di sensori che non hanno bisogno di un gateway di confine che sia, nel contempo anche client MQTT, sono le reti IP. Esistono ancora i gateway nelle reti IP ma con scopi diversi da quello di realizzare un client MQTT. Nelle reti IP, il client MQTT è, normalmente, direttamente a bordo del dispositivo sensore dotato di indirizzo IP (MCU).

Gateway come MCU hub di sensori

La parola gateway potrebbe talvolta portare a fraintendimenti dovuti al diverso significato nei diversi contesti in cui la si usa. Spesso, con il termine gateway si intente anche il dispositivo IoT che potrebbe essere, a sua volta, un gateway tra la il link di campo, porte analogiche/digitali o BUS, (vedi bus di campo per dettagli) e la rete di sensori (WiFi, BLE, LoraWAN, LAN, BLE, ecc.). Vedi (dispositivi terminali) per approfondimenti.

Gateway come router L7

Gateway come router L7

Avendo più interfacce su reti di tipo diverso sia in L1 che in L2, ha anche le funzioni di router. Se la rete di distribuzione è pubblica come Internet dovrebbe possedere pure le funzioni di firewall.

Ma la funzione più importante che possiede nel contesto di una rete di dispositivi IoT è la traduzione della semantica, cioè del significato degli oggetti, dalla rete BLE al livello applicativo MQTT che smista i messaggi nella rete IP. Questa funzione rende il gateway un bridge di traduzione di comandi da un ambiente all’altro.

Misure e comandi sono definiti due volte:

In ogni caso, per gli oggetti BLE, la semantica dei comandi e dello stato è standardizzata, nel senso che dispositivi di marche diverse si possono comandare allo stesso modo. Tutti i dispositivi di ugual tipo si rappresentano come uno stesso oggetto BLE, avente gli stessi attributi per tutti i dispositivi di quel tipo.

Gli oggetti JSON scambiati nella rete di distribuzione vanno progettati in modo tale da includere la semantica di tutti i dispositivi IoT coinvolti nelle reti di sensori collegate, che di volta in volta, poi andrà tradotta nella semantica applicativa standard prevista nello stack della rete di accesso BLE.

Formato dei messaggi

Misure e comandi sono attualmente definiti sotto forma di oggetti JSON in formato ASCII. Questo dovrebbe garantire da un lato l’interoperabilità tra reti di sensori diverse, dall’altro l’interoperabilità con sistemi terzi che si occupano della pubblicazione dei dati o della loro eleborazione statistica. Il fatto che il formato scelto sia chiaro, testuale ed autoesplicativo è sicuramente un vantaggio nella rete di distribuzione.

Gli oggetti JSON scambiati nella rete di distribuzione vanno progettati in modo tale da includere la semantica di tutti i dispositivi IoT coinvolti nelle reti di sensori collegate, che di volta in volta, poi andrà tradotta nella semantica applicativa standard prevista nello stack della rete di accesso BLE.

Per Bluetooth Low Energy (BLE), i dispositivi sono spesso strutturati utilizzando servizi e caratteristiche (characteristics). Per una lampadina BLE, potremmo avere un servizio che consente di controllare lo stato di accensione e spegnimento della lampadina. Di seguito viene fornito un esempio di come potrebbe essere strutturato un servizio BLE per una lampadina, con le operazioni di accensione e spegnimento.

Traduzione della semantica applicativa

Ble2mqtt è un software open-source progettato per permettere ai dispositivi BLE di comunicare direttamente con un server MQTT (Message Queuing Telemetry Transport) senza la necessità di un hub proprietario. Ble2mqtt

BLE è uno standard di comunicazione wireless utilizzato anche per il controllo e l’automazione domestica, mentre MQTT è un protocollo di messaggistica leggero utilizzato per il trasferimento di dati tra dispositivi. Utilizzando BLE2mqtt, gli utenti possono integrare facilmente dispositivi BLE di diversi produttori in un sistema di automazione domestica basato su MQTT, con un alto livello di flessibilità e controllo.

Il bridge ble2mqtt opera a livello di presentazione della pila OSI ed esegue, nell’ordine, le seguenti operazioni:

  1. sbusta tutti i messaggi provenienti dall’interfaccia BLE uno dopo l’altro, a partire dal livello fisico fino ad arrivare al livello di presentazione, dove BLE realizza la sua rappresentazione semantica dell’oggetto comandato/attuato/configurato, completa di attributi e corrispondenti valori.
  2. a questo punto traduce il payload BLE in un payload JSON che contiene gli stessi attributi con gli stessi valori.
  3. dopo di che smista il JSON così costruito sull’interfaccia IP del gateway, dove viene imbustato come payload del protocollo MQTT ed inviato fino al broker.

Ble2mqtt funge da ponte tra la rete BLE e il broker MQTT, consentendo agli utenti di interagire con i dispositivi BLE tramite messaggi MQTT.

La traduzione è resa possibile perchè le reti BLE definiscono per ogni dispositvo la semantica applicativa standard che abbiamo visto sopra (una lampadina ha gli stessi comandi, lo stesso stato e la stessa configurazione per tutte le lampadine BLE mai prodotte da chiunque). Compito del bridge Ble2mqtt è tradurre gli oggetti standard BLE in JSON e inserirli in un messaggio MQTT.

Funzionamento di ble2mqtt

Ecco una descrizione di come funziona ble2mqtt:

  1. Scansione dei Dispositivi BLE: ble2mqtt esegue una scansione per rilevare dispositivi BLE nelle vicinanze. Questo include sensori, attuatori, lampadine, termostati, ecc.
  2. Connessione ai Dispositivi BLE: una volta individuati, ble2mqtt si connette ai dispositivi BLE per leggere e scrivere dati. Può interagire con i servizi e le caratteristiche esposte dai dispositivi.
  3. Pubblicazione su MQTT: i dati letti dai dispositivi BLE vengono convertiti in messaggi MQTT e pubblicati su un broker MQTT. Questo può includere dati di stato, misurazioni di sensori, ecc.
  4. Sottoscrizione a Comandi MQTT: ble2mqtt si iscrive anche a determinati topic MQTT per ricevere comandi. Quando un comando MQTT viene ricevuto, ble2mqtt lo traduce in un’operazione BLE e lo invia al dispositivo appropriato.

Configurazione di ble2mqtt

Per controllare tre lampadine diverse sotto lo stesso topic stanzetta usando BLE2mqtt, è possibile configurare un approccio che permetta di inviare comandi a tutte e tre le lampadine contemporaneamente o individualmente. Un modo efficace per farlo è usare un payload JSON che includa informazioni specifiche per ciascuna lampadina.

mqtt:
  base_topic: ble2mqtt
  server: 'mqtt://localhost'
  user: 'MQTT_USERNAME'
  password: 'MQTT_PASSWORD'

devices:
  'C4:7C:8D:6A:95:BD':
    friendly_name: lampadina1
  'D0:52:A8:00:67:AB':
    friendly_name: lampadina2
  'F0:99:B6:43:55:AC':
    friendly_name: lampadina3

Ora, configurando un singolo topic BLE2mqtt/stanzetta/set per inviare comandi a tutte e tre le lampadine, possiamo usare un payload JSON per specificare lo stato desiderato di ogni lampadina.

Accendere tutte le Lampadine:

#!/bin/bash

# Accendere lampadina1
mosquitto_pub -h localhost -t 'BLE2mqtt/lampadina1/set' -m '{"state": "ON"}'

# Accendere lampadina2
mosquitto_pub -h localhost -t 'BLE2mqtt/lampadina2/set' -m '{"state": "ON"}'

# Accendere lampadina3
mosquitto_pub -h localhost -t 'BLE2mqtt/lampadina3/set' -m '{"state": "ON"}'

Spegnere tutte le Lampadine:

#!/bin/bash

# Accendere lampadina1
mosquitto_pub -h localhost -t 'BLE2mqtt/lampadina1/set' -m '{"state": "OFF"}'

# Accendere lampadina2
mosquitto_pub -h localhost -t 'BLE2mqtt/lampadina2/set' -m '{"state": "OFF"}'

# Accendere lampadina3
mosquitto_pub -h localhost -t 'BLE2mqtt/lampadina3/set' -m '{"state": "OFF"}'

Comandare le Lampadine Singolarmente:

#!/bin/bash

# Accendere lampadina1
mosquitto_pub -h localhost -t 'BLE2mqtt/lampadina1/set' -m '{"state": "ON"}'

# Accendere lampadina2
mosquitto_pub -h localhost -t 'BLE2mqtt/lampadina2/set' -m '{"state": "OFF"}'

# Accendere lampadina3
mosquitto_pub -h localhost -t 'BLE2mqtt/lampadina3/set' -m '{"state": "ON"}'

Utilizzo dei topic

Puoi definire una gerarchia di topic MQTT per raggruppare le lampadine. Ad esempio, potresti avere un topic per ciascun ambiente della tua casa o per ciascun piano dell’edificio. Ecco un esempio di come potrebbe apparire la gerarchia dei topic:

casa/
  └── soggiorno/
      ├── lampadina1/
      │   ├── comandi
      │   └── stato
      ├── lampadina2/
      │   ├── comandi
      │   └── stato
      └── lampadina3/
          ├── comandi
          └── stato

In questo esempio, casa è il prefisso di tutti i tuoi topic MQTT. All’interno di questo prefisso, hai un sotto-topic per il soggiorno chiamato soggiorno, e all’interno di questo sotto-topic hai i sotto-topic per ciascuna delle tue lampadine, ciascuno dei quali ha due sotto-topic: cmd e stato.

mqtt:
  base_topic: casa
  server: 'mqtt://localhost'
  user: 'MQTT_USERNAME'
  password: 'MQTT_PASSWORD'
serial:
  port: '/dev/ttyUSB0'
devices:
 'F0:99:B6:43:55:AC':
    friendly_name: lampadina1
    state_topic: 'soggiorno/lampadina1/stato'
    set_topic: 'soggiorno/lampadina1/comandi'
 'C4:7C:8D:6A:95:BD':
    friendly_name: lampadina2
    state_topic: 'soggiorno/lampadina2/stato'
    set_topic: 'soggiorno/lampadina2/comandi'
 'D0:52:A8:00:67:AB':
    friendly_name: lampadina3
    state_topic: 'soggiorno/lampadina3/stato'
    set_topic: 'soggiorno/lampadina3/comandi'

Accendere una lampadina del Soggiorno

mosquitto_pub -h localhost -t 'casa/soggiorno/lampadina1/cmd' -m '{"state": "ON"}'

Accendere tutte le Lampadine nel Soggiorno

mosquitto_pub -h localhost -t 'casa/soggiorno/cmd' -m '{"state": "ON"}'

Spegnere tutte le Lampadine nel Soggiorno

mosquitto_pub -h localhost -t 'casa/soggiorno/cmd' -m '{"state": "OFF"}'

Reti BLE per tracciamento e localizzazione

Si tratta di un utilizzo diverso da quello di una normale rete di sensori poichè l’obiettivo finale non è creare una rete di dispositivi domotici composta da sensori e attuatori ma creare una rete di dispositivi per la localizzazione e il tracciamento, nel tempo e nello spazio, della posizione di altri dispositivi.

L’iBeacon di Apple è stata la prima tecnologia BLE Beacon a essere pubblicata, quindi la maggior parte dei beacon si ispira al formato dati iBeacon. Gli iBeacon sono abilitati in molti SDK di Apple e possono essere letti e trasmessi da qualsiasi iDevice abilitato per BLE. IBeacon è uno standard proprietario e chiuso. I beacon trasmettono quattro informazioni:

alt text

Un’applicazione di scansione legge l’UUID, il numero maggiore e il numero minore e li usa come riferimento per ottenere informazioni sul beacon da un database; il beacon stesso non porta informazioni descrittive, richiede che questo database esterno sia raggiungibile. Il campo di potenza TX viene utilizzato con l’intensità del segnale misurata per determinare la distanza del dispositivo beacon dallo smartphone. Si noti che TxPower deve essere calibrato dall’utente per raggiungere una buona precisione.

Scopo iBeacon

Questo innovativo uso della tecnologia fa principalmente leva su due concetti chiave:

Importante sottolineare alcune proprietà peculiari del BLE:

In definitiva, gli iBeacon utilizzano Bluetooth Low Energy per creare un’infrastruttura smart, orientata alla localizzazione, che i dispositivi mobili possono utilizzare per ricavare informazioni contestuali basate sull’ambiente stesso in cui si muovono, in tempo reale.

Le applicazioni possono ora sapere esattamente dove si trovano e cosa le circonda, aprendo la strada ad un nuovo livello di interazione col mondo, senza bisogno di una connessione ad Internet.

Schema di cablagggio a beacon fisso

È l’approccio più comune. I beacon sono posizionati in posizioni fisse e note, rispetto a una mappa interna. 

I dispositivi mobili (listener) abilitati Bluetooth riconoscono i beacon quando questi si trovano all’interno del raggio della loro portata (variabile dal metro alle decine di metri) e determinano la posizione assoluta (latitudine e longitudine) del dispositivo sulla mappa, stimata grazie a misure di distanza:

I dati di tracciamento raccolti da ciascun dispositivo mobile possono quindi essere inviati, via wifi o modem UMTS, a un sistema centralizzato a scopo analitico e ad altri servizi come la mappatura delle presenze in tempo reale, o delle localizzazioni in tempo reale.

Si noti che in questo approccio i dispositivi da localizzare hanno il ruolo di listener e devono essere essere collegati alla rete, mentre i dispositivi fissi no.

La particolarità di questo approccio è:

alt text

Esempio: tour digitale in un museo, in cui ogni stanza o attrazione potrebbe avere un beacon fisso che emette un tag BLE specifico. Se una persona sceglie di installare l’app mobile del museo, il suo telefono, ogni qualvolta cammina vicino a un beacon, legge il tag e le informazioni pertinenti e mirate sull’esposizione potrebbero essere recuperate da ciascun dispositivo tramite il tag, consentendo un’esperienza più istruttiva e coinvolgente per i visitatori.

Esempio ambulatorio.

alt text

Esempio shopping.

alt text

Esempio ospedale.

alt text

Schema di cablagggio a scanner fisso

È un’approccio sempre più diffuso. Questi “ascoltatori” fissi raccolgono gli identificativi di tutti i beacon Bluetooth alla loro portata e sono loro stessi che trasmettono le informazioni raccolte a un sistema centralizzato per l’analisi, invece che un dispositivo mobile collegato alla rete.

Il sistema centrale applicherà alcuni filtri digitali e, in base alla posizione degli ascoltatori fissi nota sistema, determinerà la posizione dei beacon mediante la trilaterazione.

Utilizzando questo approccio, invece di tracciare o localizzare un dispositivo mobile costoso (smartphone) , si effettua il tracciamento dei singoli beacon che, grazie al costo irrisorio e alle ridodittissime dimensioni, consentono una serie di casi d’uso nuovi e innovativi.

Si noti che in questo approccio i dispositivi fissi hanno il ruolo di listener e devono essere essere collegati alla rete, mentre i dispositivi da localizzare no.

Questo approccio è però molto più oneroso per l’infrastruttura perchè adesso serve una rete di distribuzione delle informazioni di tracciamento raccolte dai listener che deve essere estesa almeno quanto tutta l’area da presidiare.

alt text

Esempi:

Nell’architettura a scanner fissi i dispositivi BLE sono analoghi ai gateway dell’infrastruttura BLE Mesh solo che adesso lo scopo è radicalmente diverso, non servono a connettere l’intera rete di sensori alla LAN, ma a mandare ad un server una informazione di tracciamento da parte del listener che la ha raccolta. Poichè il beacon si muove nello spazio, potenzialmente in tutti gli ambienti, è necessario installare molti scanner lungo i percorsi che si desiderano tracciare e non pochi gateway soltanto.

Posizionamento listener (scanner)

Nell’architettura a scanner fissi i dispositivi BLE non possono restare isolati ma devono comunicare le informazioni sui beacon di passaggio nelle vicinanze ad un server centrale e, per far questo, hanno necessità di una rete da utilizzare come infrastruttura di comunicazione. Esistono alcune alternative:

Esempio tracking assets industriali

alt text

Rete di sensori BLE

alt text

E’ una architettura a stella gerarchica (albero). E’ realizzata da un solo dispositivo master. Un master può essere contemporaneamente pure slave di un’altra piconet.

Topologie di connessione

Beacon

I beacon sono delle sequenze di sincronizzazione (dette preambolo) in grado sia di sincronizzare gli orologi dei dispositivi (Tx e Rx) che si accingono ad iniziare una comunicazione, ma anche di indentificare in maniera univoca i dispositivi che li emettono. Per dei dettagli vedi preambolo di sincronizzazione.

La trama dati compresa tra due beacon consecutivi viene detta supertrama (superframe) ed è generalmente divisa in due zone con politiche di accesso al canale diverse:

Nel contesto di BLE, un centrale può assumere un ruolo di coordinamento, simile a quello svolto dal PCF in una rete Wi-Fi, gestendo l’accesso al canale in modo master/slave in cui il centrale ha il ruolo di master che stabilisce quale stazione deve parlare, quando e per quanto tempo usando una politica di turnazione delle stazioni (polling).

Tutti i dispositivi BLE emettono beacon per cui il nome di beacon alla fine è finito per identificare anche un generico dispositivo BLE.

Le superframe BLE sono divise principalmente in tre zone:

Queste zone sono organizzate in un ciclo temporale (la supertrama) che si ripete periodicamente per consentire la comunicazione tra i dispositivi BLE in modo efficiente e sincronizzato.

Topologia broadcast

Il beacon non collegabile è un dispositivo Bluetooth (broadcaster) a bassa energia in modalità di trasmissione. Trasmette semplicemente informazioni statiche archiviate internamente senza ricevere alcunchè da un eventuale observer. Dato che la trasmissione è non connettibile non attiva alcuna risorsa HW di ricezione, per cui ha il minor consumo energetico possibile. Il dispositivo deve semplicemente svegliarsi, trasmettere (pochi) dati e tornare a dormire (modalità radiofaro). Ciò comporta l’inconveniente che gli unici dati dinamici sono limitati a ciò che è noto al dispositivo o a ciò che è disponibile tramite altri canali di cui è dotato il dispositivo quali interfacce seriali RS232 (UART), periferiche 4-wire (SPI), bus seriale universale (USB) e così via.

Gli attori di questa modalità sono quindi due:

alt text

I pacchetti di advertisement sono periodici e sono messaggi di beacon trasmessi in broadcast da dispositivi broadcaster detti, per l’appunto, essi stessi beacon. Da questi l’osservatore ricava informazioni minimali (tag).

Topologia connessa

Il beacon collegabile (o periferica) è un dispositivo Bluetooth a bassa energia in modalità periferica, il che significa che può non solo trasmettere, ma anche ricevere e quindi potrebbe anche essere interrogato periodicamente per interagire con i servizi implementati sul dispositivo beacon effettuando:

Gli attori di questa modalità sono sempre due:

alt text

La differenza tra la scansione dei beacon effettuata da un dispositivo centrale e quella effettuata da un semplice observer sta nel fatto che la prima è una ricerca che è abilitata ad instaurare una connessione bidirezionale con i dispositivi beacon periferici, mentre la seconda è una scansione che permette l’attivazione di connessioni di sola ricezione.

Topologia mista

Stanno iniziando a comparire dispositivi dual-mode e single-mode più avanzati, dispositivi in ​​grado di combinare più ruoli contemporaneamente. Ciò consente loro di partecipare a più connessioni contemporaneamente, mentre usano gli advertisement per trasmettere informazioni in broadcast.

alt text

GATT

I dispositivi BLE, dal punto di vista SW, si dividono in dispositivi Client e in dispositivi Server:

Esempi:

I servizi BLE sono stati nel tempo standardizzati e sono raggruppati per profili, cioè per categorie di servizi, all’interno dei quali i tipi di servizio hanno comandi, stato e configurazioni standardizzati. Questo approccio fa si che un comando inviato da un dispositivo di una marca X possa essere recepito dall’attuatore di una marca Y con la garanzia che venga intepretato correttamente. In sostanza viene garantita la piena interoperabilità tra dispositivi analoghi anche se di marca diversa.

Nel caso particolare dei beacon, è però prassi comune introdurre dei servizi custom che possono essere diversi da un costruttore all’altro a patto, però, che il loro identificativo globale, l’UIID sia unico e diverso da quello già assegnato ad altri servizi.

GATT sta per Generic Attributes e definisce una struttura dati gerarchica esposta ai dispositivi BLE collegati. Ciò significa che GATT definisce il modo in cui due dispositivi BLE inviano e ricevono messaggi standard.

alt text

UUID

Ogni servizio, caratteristica e descrittore ha un UUID (Universaly Unique Identifier). Un UUID è un numero univoco a 128 bit (16 byte). Per esempio:

55072829-bc9e-4c53-938a-74a6d4c78776

Esistono UUID abbreviati per tutti i tipi, servizi e profili specificati nel SIG Bluetooth Special Interest Group.

Ma se la tua applicazione necessita di un proprio UUID, è possibile generarlo utilizzando questo sito Web di generatore di UUID UUID generator website.

In sintesi, l’UUID viene utilizzato per identificare in modo univoco le informazioni. Ad esempio, può identificare un particolare servizio fornito da un dispositivo Bluetooth.

Protocolli di accesso al canale

La situazione può essere riassunta nel seguente modo:

alt text

Ogni piconet ha due canali fisici: un canale peer to peer ad accesso probabilistico CSMA detto Canale di Advertisement ed un canale ad accesso deterministico TDMA detto Canale Dati regolato da un dispositivo master:

alt text

Una connessione può essere stabilita solo tra un dispositivo advertiser ed un dispositivo initiator e questi dispositivi diventeranno rispettivamente slave e master della piconet e, appena questa è formata, comunicheranno sul canale dati, terminando così l’Advertising Event ed iniziando un Connection Event.

Connection Interval: tempo tra connection events. Stabilisce un appuntamento regolare tra dispositive master e slave. Se non ci sono dati dell’applicazione da inviare o ricevere, i due dispositivi scambiano pacchetti di controllo per mantenere la connessione. Slave Latency: il numero di eventi connection che lo slave può «saltare» cioè nei quali lo slave non è obbligato ad “ascoltare” il master e quindi può restare nello stato standby. Supervision Timeout: tempo massimo tra due pacchetti di dati validi ricevuti prima che una connessione venga considerata “persa”.

API di connessione

alt text

Il livello GAP dello stack BLE è il responsabile della funzione di connessione. Questo livello gestisce le modalità e le procedure di accesso del dispositivo, inclusi:

Si può accedere al livello GAP tramite chiamate dirette o tramite la API GAPRole Task. E’ consigliato utilizzare il metodo GAPRole Task anziché le chiamate dirette quando possibile.

La configurazione diretta del livello GAP descrive le funzioni e i parametri che non sono gestiti o configurati tramite le API GAPRole Task e che pertanto devono essere modificati direttamente tramite il livello GAP. GAPRole Task è un’attività separata che scarica l’applicazione della gestione della maggior parte delle funzionalità del livello GAP. Questa attività è abilitata e configurata dall’applicazione durante l’inizializzazione. Sulla base di questa configurazione, molti eventi dello stack BLE vengono gestiti direttamente dal GAPRole Task e non vengono mai passati all’applicazione. Esistono funzioni di callback che l’applicazione può registrare con l’attività GAPRole in modo che l’attività dell’applicazione possa essere notificata per determinati eventi e procedere di conseguenza.

alt text

Modulazione

BLE adopera una forma di FDM in cui trasmettitore e ricevitore non usano in una connessione sempre la stessa frequenza ma saltano, ad istanti prefissati, lungo 37 canali secondo uno schema reso noto ad entrambi in fase di setup. Ogni connessione avrà uno schema di salti che, istante per istante, non si sovrappone a quello delle altre connessioni. In una connessione dati, viene utilizzato un algoritmo di salto di frequenza per scorrere i 37 canali di dati:

fn+1=(fn+hop) mod 37

Dove fn+1 è la frequenza (canale) da utilizzare al prossimo evento di connessione e hop è un valore che può variare da 5-16 e viene impostato al momento del setup della connessione. Il meccanismo di salto è dinamico e può variare per adattarsi a sopraggiunte condizioni di interferenza con altri dispositivi.

Supponiamo, ad esempio, che un dispositivo BLE si trovi a coesistere con reti Wi-Fi sui canali 1, 6 e 11. Il dispositivo BLE contrassegna i canali 0-8, 11-20 e 24-32 come canali non buoni. Ciò significa che mentre i due dispositivi comunicano, rimapperanno i salti in maniera tale da evitare i canali con interferenza Modulazione FHSS.

alt text

Messaggi MQTT

Messaggi confermati

La conferma dei messaggi inviati da parte del ricevente normalmente non è necessaria nel caso dei sensori. Infatti, se un invio da parte di un sensore non andasse a buon fine, è inutile richiedere la ritrasmissione di un dato che comunque a breve arriva con una misura più aggiornata.

La conferma, invece, è prevista per funzioni di comando o configurazione. Ad esempio nel caso di pulsanti, rilevatori di transito o allarmi in cui l’invio del messaggiò avviene sporadicamente e in maniera del tutto asincrona (cioè non prevedibile dal ricevitore), potrebbe essere auspicabile avere un feedback da parte del protocollo mediante un meccanismo di conferma basato su ack. Ma non sempre ciò è possibile.

La conferma, però, potrebbe pure essere gestita soltanto dal livello applicativo (non dal protocollo) utilizzando un topic di feeedback (o stato) per inviare il valore dello stato corrente subito dopo che questo viene interessato da un comando in ingresso sul dispositivo.

Definizione di topic e payload

Sovente, nella rete di distribuzione IP è presente un server col ruolo di broker MQTT a cui sono associati:

In realtà, il topic di configurazione, pur essendo teoricamente appropriato, potrebbe anche essere incorporato nel topic di comando, magari prevedendo un livello più alto di autorizzazione rispetto ai comandi relativi alle funzioni ordinarie.

Gestione dei topic di comando

Potremmo a questo punto inserire il comando delle luci nel topic più generale delle misure ed attuazioni che chiameremo comandi e registrare i pulsanti del soggiorno al topic luci/soggiorno/comandi come pubblisher, mentre potremmo registrare le attuazioni delle lampade allo stesso topic come subscriber. Il comando potrebbe essere il JSON {"toggle":"true"}, per cui alla fine tutto intero il path diventerebbe luci/soggiorno/comandi/{"toggle":"true"}. Se volessimo selezionare un solo dispositivo sono possibili due strade alternative:

Gestione dei topic di stato

Questo canale viene utilizzato per inviare lo stato di un dispositivo a tutti coloro che ne sono interessati. L’interesse potrebbe nascere per più motivi:

Un esempio di canale MQTT di stato potrebbe essere:

Gestione dei topic di configurazione

Questo canale viene utilizzato per inviare comandi di configurazione al dispositivo da parte del server di processo. L’interesse potrebbe nascere per più motivi:

Un esempio di canale MQTT di configurazione per, ad esempio, impostare il periodo di pubblicazione automatica dello stato potrebbe essere:

Pagine correlate:

Sitografia:

Torna a reti di sensori