Come con l’uso del PC, il concetto del Plug and Play ha reso semplice l’installazione e l’uso delle periferiche, eliminando la complessità della configurazione dei driver, così è arrivato il momento di portare lo stesso concetto anche nel mondo dell’IoT, dove ancora la connettività tra device e software nel cloud non è sempre così facile. La piattaforma cloud Azure di Microsoft per l’IoT ha introdotto questo approccio, con la finalità ultima di rendere facile ai produttori la realizzazione di device che poi possono integrarsi in soluzioni software senza l’intervento manuale e agli utilizzatori degli stessi un rapido utilizzo.
Il cloud per l’IoT: Azure IoT
Prima di avventurarci nel descrivere il soggetto di questo articolo è opportuno introdurre almeno due concetti, per far in modo di essere tutti allineati nella lettura. Azure è la piattaforma di cloud computing di Microsoft, con più di 60 regioni a livello globale. In estrema sintesi la piattaforma offre sia servizi IaaS, come macchine virtuali, sia servizi PaaS, ovvero servizi gestiti per diverse tipologie di applicazioni, ad esempio per diversi DBMS, per l’intelligenza artificiale, per il web, per applicazioni mobile e inoltre anche per realizzare soluzioni IoT.
A scopo puramente indicativo potete vedere nella figura seguente la lista di questi “mattoncini del Lego” con cui è possibile sviluppare applicazioni per l’Internet of Things.
Una tipica soluzione può prevedere l’uso di device che comunicano usando protocolli come MQTT, AMQP o HTTPS verso un Hub nel cloud per mandare telemetria. Questo Hub si chiama Azure IoT Hub, che è appunto un servizio PaaS, completamente gestito da Azure. Il vantaggio di avere un componente gestito è che l’alta disponibilità, la scalabilità e la sicurezza vengono offerte direttamente dalla piattaforma Azure. Un device, può utilizzare l’Azure IoT Device SDK, che è una libreria software, che gli permetterà di comunicare agevolmente con questo componente. Un’applicazione collegata all’IoT Hub dovrà essere in grado di utilizzarli, interpretando i dati di telemetria inviati dal device. Questi, di solito, arrivano in formato JSON, ma quello che spesso accade è che la struttura non è nota a priori, oppure può variare nel tempo, rendendo di fatto difficile l’interfacciamento tra device e applicazioni nel cloud. Ed è proprio qui che sorgono i problemi, se il formato che viene inviato dal device non è quello che si aspetta l’applicazione, ci deve essere dunque accordo tra le parti. Il Plug and Play per l’IoT aiuta a risolvere questo problema alla radice.
Cos’è il plug and play per l’IoT
L’IoT plug and play permette ai solution builder di integrare smart device nelle loro soluzioni senza intervento manuale.
Questo avviene tramite la realizzazione di un device model, che il device utilizza per descrivere le sue funzionalità ad un’applicazione che anch’essa supporta il plug and play. Esempi di funzionalità che il device può descrivere sono i tipi di telemetria che i sensori ospitati possono inviare, come la temperatura, l’umidità, la pressione, oppure i comandi che il device accetta dall’applicazione nel cloud, come ad esempio quelli necessari per far partire una pala eolica, cambiare una soglia di temperatura, aggiornare il firmware del device, etc.
Per la descrizione del modello viene utilizzato un linguaggio chiamato Digital Twins Definition Language (DTDL). Questo linguaggio viene anche utilizzato per la descrizione di IoT Digital Twins. DTDL è un linguaggio aperto, disponibile su GitHub e si basa su standard W3C come il JSON-LD e RDF.
Chi sono gli utilizzatori
L’IoT Plug and Play si indirizza a due principali tipi di sviluppatori:
- Il solution builder che è responsabile di realizzare una soluzione che usi Azure IoT Hub o Azure IoT Central, quest’ultimo un servizio SaaS della piattaforma Azure. Inoltre si occupa dell’identificazione dei device che vanno integrati.
- Il device builder, invece, è colui che crea il codice che gira sul device e deve utilizzare le regole affinché anche il device sia compatibile con il protocollo del Plug and Play. È colui che realizza il JSON del device model in DTDL e che descrive appunto il “suo” device al mondo circostante.
Come funziona: il device model
Come detto in precedenza, il modello del device è, di fatto, un’interfaccia, cioè un contratto tra il device e l’applicazione o le applicazioni che lo usano.
Non è obiettivo di questo articolo entrare nel dettaglio di come è fatto un file scritto in DTDL e la sintassi, ma possiamo dire che ad alto livello questo si struttura in tre parti:
- Le proprietà, che rappresentano delle grandezze del nostro device a cui abbiamo accesso o in sola lettura o in scrittura. Ad esempio: il numero seriale del device è una proprietà, disponibile in sola lettura, che l’applicazione può leggere dal cloud, mentre la temperatura di regime di un termostato è una proprietà disponibile in scrittura dall’applicazione che la imposta, magari su richiesta dell’utente remoto che può modificarla a suo piacimento.
- La telemetria, che sono i dati veri e propri emessi dal device, sia emessi in modo continuativo, sia che si tratti di uno stato o di un messaggio di errore.
- I comandi, che descrivono un’operazione o una funzione che il device può compiere, come ad esempio far ripartire un gateway, fermare o far partire delle pale eoliche.
Abbiamo detto in precedenza che, di solito, questo modello viene fatto dal device builder, il quale, dovrà poi scrivere il codice del device in modo che la telemetria, proprietà e comandi inviati rispettino le convenzioni. Inoltre, non meno importante, nel codice del device, viene annunciato l’ID del modello durante una connessione MQTT; questo così che l’applicazione che lo riceve sappia a sua volta a quale modello dovrà mappare tutto ciò che riceverà da quel device e di conseguenza le funzioni che questo supporta.
Sviluppare un’applicazione che usa il plug and play
Fino ad ora abbiamo visto metà dell’architettura, cioè quella in carico al device builder, ora vediamo come si sviluppa invece una soluzione che supporta il plug and play.
Come visto in precedenza il device è in grado di trasmettere il suo model ID a un Azure IoT Hub. Questo identificativo sarà proprio quello usato per realizzare il codice dell’applicazione. Infatti, una volta recuperato questo, l’applicazione sarà in grado di andare a recuperare il modello vero e proprio da un model repository o da uno proprio, dove in precedenza lo abbia salvato. A questo punto il gioco è fatto, avendo a disposizione il “contratto”, sa esattamente cosa il device sarà in grado di inviare e come operare con lo stesso. Inoltre, chi sviluppa il codice dell’applicazione, saprà anche cosa aspettarsi e potrà costruirsi l’interfaccia utente, controlli, grafici, etc.
Certificazione di device per l’IoT plug and play
Microsoft offre un programma di certificazione per i device per assicurare che gli stessi funzionino al meglio con le componenti di Azure IoT.
Il vantaggio è duplice: chi infatti deve scegliere un device, ha maggiori garanzie sapendo che sia già stato certificato, inoltre ha maggiore sicurezza e fiducia nella scelta.
In ultimo Microsoft offre uno catalogo dei device certificati, ciò ne aumenta la visibilità e l’esposizione del marchio sul mercato.
Tra le certificazioni di questo programma, è possibile aggiungere la IoT Plug and Play certification, che come ci si può facilmente aspettare ne certifica anche la compatibilità con il Plug and Play e poi ne viene resa evidenza nel catalogo dei device, come si vede dalla figura seguente.
IoT plug and play bridge
Fino ad ora abbiamo visto che il device builder è in grado di scrivere il codice del device in modo che rispetti il modello. Ci sono però dei casi in cui ciò non è possibile, magari perché non si può modificare il codice di un dispositivo esistente.
IoT Plug and Play bridge è un progetto open source che consente di collegare questi device ad un gateway, il quale a sua volta si collegherà all’Azure IoT Hub, sfruttando quando visto in precedenza. La figura sottostante dovrebbe essere esplicativa.
Dopo aver installato il “bridge” su un gateway lo si può configurare per collegare il device esistente e quindi fare un mapping tra la telemetria inviata da quest’ultimi e le interfacce plug and play che possiamo definire.
Possiamo immaginare in questo scenario di voler collegare un dispositivo Bluetooth usando il plug and play. Il Bluetooth non è uno dei protocolli supportati da IoT Hub e in questo caso l’uso del gateway ha un duplice vantaggio: il primo di poter collegare questo device al cloud e il secondo di sfruttare il “bridge” per introdurre anche le funzionalità di plug and play.
Conclusioni
Spesso si sente parlare di progettualità in ambito IoT e della complessità di progetti in questo settore e delle competenze molto diversificate che servono: da chi sviluppa hardware, firmare, programma device, chi sviluppa software per il cloud e non ultimo chi si occupa di data science per abilitare scenari di predictive maintenance, etc. L’idea del plug and play va proprio a semplificare lo sviluppo di soluzioni in ambito IoT, cercando di semplificare come avviene la connessione tra device e soluzioni nel cloud. Avere poi un catalogo di device certificati da cui poter scegliere renderà ancora più semplice, anche per chi non ha tutte le competenze in azienda, realizzare soluzioni a valore aggiunto per il proprio business.
