Il successo delle soluzioni Internet of Things è legato alla loro sempre maggiore diffusione, ma proprio la presenza di un numero crescente di prodotti in campo IoT industriale sta mettendo in evidenza che l’interoperabilità e la stessa possibilità di connessione tra device di produttori diversi non sono affatto garantite o indolori.
La questione di fondo è che buona parte dei produttori ha sviluppato le sue soluzioni di IoT industriale senza considerare in primo luogo la loro capacità di essere interoperabili a 360 gradi.
A volte questo non è stato fatto volontariamente ma perché le soluzioni in questione erano destinate ad ambiti specifici, come la building automation. Altre volte la scelta è stata più esplicita, per garantire un certo vantaggio competitivo a un produttore o a un gruppo di vendor.
Man mano che il campo IoT industriale cresce ci si rende conto che la ricerca dell’interoperabilità è importante. Così per garantire interazione e sinergia tra soluzioni diverse si stanno seguendo molte strade. I livelli a cui questo sta accadendo sono soprattutto la connettività fisica e i layer più legati ai servizi software.
Dialogare nella IoT
Sembra strano che la connettvità fisica sia un problema in questa fase dello sviluppo tecnologico, eppure in campo IoT industriale a volte lo è. Le tecnologie di connessione wireless di stile “informatico” come WiFi o Bluetooth devono convivere con altre più mirate come ZigBee o Z-Wave, se non con altre ancora più proprietarie.
Può esistere una lingua franca per l’interconnessione fisica? Chirp da qualche anno propone di usare il suono, considerandolo come un “canale” che si può usare anche in tutte le situazioni in cui le onde elettromagnetiche dei segnali wireless non sono opportune (ad esempio in certi impianti industriali, o ne medicale). In sintesi, Chirp ha sviluppato un protocollo che usa i segnali sonori come layer di trasporto, modulando le trasmissioni dati su frequenze udibili (2-12 kHz) e anche ultrasuoni non udibili dall’orecchio umano (19 kHz).
Chirp punta soprattutto sulla semplicità del suo approccio. Usando le librerie già sviluppate da Chirp stessa le frequenze sonore possono essere gestite come un canale trasmissivo punto-punto o broadcast qualsiasi, quindi con le stesse funzioni di gestione delle comunicazioni che si userebbero di norma, cifratura compresa. Al prezzo di una banda ridotta (100-150 kbps) ma considerata sufficiente.
Interfacce universali fra servizi
La connettività fisica tra device IoT non basta se poi questi non riescono a scambiarsi informazioni perché ciascuno parla anche a livello software una “lingua” differente. Questo può avvenire in generale ma soprattutto in alcuni ambiti particolari in cui le soluzioni IoT si fondono con quelle preesistenti di impostazione più M2M.
In questo particolare ambito esiste da qualche anno una iniziativa – oneM2M – che vede coinvolte diversi enti mondiali di standardizzazione come ETSI o TIA. L’idea alla base di oneM2M è definire un layer comune a tutte le soluzioni – definito Common Services Layer – che permetta a dispositivi e applicazioni di dialogare.
A questo scopo viene creato un registro – l’AppID Registry – che raccoglie e identifica gli elementi delle reti M2M e IoT. Il suo ruolo è anche quello di fare da snodo e da coordinatore per la condivisione di informazioni tra dispositivi M2M/IoT e applicazioni che non sono nati in origine come compatibili.
A livello più astratto, ma per l’ambito specifico della IoT industriale, opera l’iniziativa EdgeX Foundry della Linux Foundation. Come lascia intendere il nome di concentra sugli ambienti di edge networking, prevedendo la collocazione di nodi edge server che facciano da punto di concentrazione per il dialogo tra device diversi, anche non IP.
L’architettura scelta è a microservizi. Ogni edge server ne offre alcuni che dipendono sia dalla sua natura sia dall’ambito in cui operano. Idealmente esiste un set di microservizi di base che semplifica lo scambio sicuro di informazioni tra qualsiasi device.
