L’Internet of things, ovvero l’uso dei protocolli Internet per connettere dispositivi come sensori e attuatori utilizzando protocolli standard come TCP/IP e HTTP, è un paradigma che si è diffuso su scala globale anche se, forse, differentemente da come ci si aspettava qualche anno fa.
A oggi non è emersa una corporate capace di produrre una classe di sistemi IoT, anche grazie ai protocolli standard che rendono meno importante disporre di hardware omogeneo per effettuare l’integrazione di dispositivi differenti.
Come è possibile osservare in figura, le stime sul numero di dispositivi connessi a internet varia significativamente, ma anche nella più conservativa tra le ipotesi si parla di 20 miliardi di unità già in funzione, e la necessità di comunicare per lo più piccole quantità di informazione (ad esempio una temperatura o lo stato di un sensore o di un motore) porta a un trasferimento di dati che considerato collettivamente può essere tale da saturare anche le linee dati più capaci.
(fonte: www.wespeakiot.com)
IoT, una crescita annunciata
La crescita esponenziale del numero di dispositivi che necessitano di comunicare tra loro mediante Internet e i suoi protocolli si poteva intuire già intorno al 2011, quando Cisco Research coniò il termine di fog computing per sottolineare la necessità di un’architettura cloud più distribuita poiché la banda necessaria a trasportare tutte le comunicazioni da miliardi di dispositivi IoT nel cloud pubblico non sarebbe bastata.
Il consorzio OpenFog è stato costituito alla fine del 2015 per definire un’architettura standard per il fog computing che nel frattempo si è cominciato anche a chiamare edge computing, indicando quei dispositivi di calcolo che per loro natura sono situati nel mondo reale e che contribuiscono mediante lettura di dati e attuazione al funzionamento di un sistema più complesso.
L’architettura dell’edge computing
L’essenza di questa forma di organizzare le connessioni di dispositivi è semplicemente quella di prendere sistemi di controllo monolitici in cui un computer coordinava sensori e sistemi di attuazione concertando comportamenti complessi, e disaggregarli in sensori e attuatori autonomi, capaci di eseguire programmi, inviare informazioni e ricevere comandi attraverso i normali protocolli Internet.
L’organizzazione naturale delle connessioni ricorda quella delle LAN e di Internet: gli attuatori e i sensori dialogano in reti locali (spesso Wi-Fi o, più recentemente 5G) e un qualche sistema di elaborazione raccoglie le informazioni prodotte, potenzialmente le elabora e le invia a qualche altro sistema per memorizzazione ed elaborazione successiva. Questo processo può essere iterato fino a raggiungere, in molti casi, servizi che sono in esecuzione su un cloud pubblico.
Il tratto essenziale di questa architettura è il grande numero di piccoli dispositivi caratterizzati dal basso assorbimento (e costo) che eseguono software che solo qualche anno fa era relegato a server prima e pc successivamente. Ciascuno di questi dispositivi produce piccole quantità di dati, tipicamente informazioni di stato come ad esempio la lettura di un parametro ambientale quale la temperatura o la luminosità.
Il concetto di stream nell’IoT
Quali sono i tratti che caratterizzano i dati prodotti dai dispositivi IoT? Per esemplificare e rendere più concreta la discussione immaginiamo due particolari tipi di dispositivi: il termometro e la video camera. Il primo produce un flusso costante di piccoli pacchetti di dato che svolgono principalmente due funzioni: quella di rappresentare il “battito” che indica al resto del sistema che il sensore opera correttamente e un piccolo pacchetto dati contenente la lettura del sensore. La videocamera produce, al contrario, un flusso di byte continuo che corrisponde al video registrato e la cui lettura non è solo una versione aggiornata dello stesso dato come accade nel caso del termometro.
Più in generale i sensori producono o flussi di eventi come nel caso del termometro, oppure flussi di byte come nel caso della videocamera. Nel panorama IoT i dispositivi che producono flussi di eventi sono la stragrande maggioranza e sono caratterizzati dal produrre una successione di eventi il cui contenuto non è rilevante di per sé ma solo se inserito in un contesto più ampio. Anche l’analisi del dato si limita raramente a considerare il valore contenuto in un singolo evento, essendo spesso più interessante la sua variazione nel tempo. Nel caso della temperatura, ad esempio, è la variazione che tendiamo a valutare per assicurare una qualche proprietà ambientale quale il riscaldamento o il condizionamento, o il monitoraggio di un paziente con la febbre.
Considerati collettivamente gli eventi prodotti da un insieme di dispositivi deve essere trasmesso a un sistema che ne analizza lo stato complessivo e decide le azioni da intraprendere inviando opportuni messaggi di controllo ad attuatori sempre mediante i protocolli standard. Ecco quindi come un sistema tradizionalmente monolitico come può essere il controllo di un impianto meccanico viene ridotto alla collaborazione di sensori e attuatori autonomi che scambiando messaggi con il software di controllo realizzano la stessa automazione. Questa disaggregazione offre il beneficio di poter analizzare gli eventi prodotti non solo nell’ottica di assicurare il funzionamento di un sistema complesso ma anche di poter usare gli eventi e i flussi prodotti per effettuare analisi più complesse e che coprano più sistemi di un’organizzazione. Per contro i sistemi diventano insiemi di componenti autonome che possono offrire una superficie di attacco maggiore rendendo centrale una trattazione adeguata dei temi di cybersecurity.
Pravega: uno stream storage open source
La natura dei sistemi basati su dispositivi IoT è quella di essere distribuita e di generare eventi che devono essere elaborati e memorizzati lungo tutta la catena che porta il dato dal produttore ad un qualche cloud, sia esso pubblico o privato.
Nel corso degli ultimi anni nel panorama dei software big data si sono affermati software per l’analisi di sequenze di eventi (stream) come Apache Flink o Apache Spark. Queste piattaforme si sono concentrate sugli aspetti di analisi di questi flussi di dati, ciascuna con le proprie astrazioni, lasciando agli utilizzatori la definizione delle politiche di memorizzazione dei dati che venivano memorizzate in un database tradizionale o in un sistema big data come ad esempio Hadoop.
Pochi anni fa l’azienda DellEMC annunciava, alla prima conferenza successiva all’acquisizione di EMC, il progetto nautilus, ovvero l’idea di uno storage distribuito disegnato per supportare l’analisi di flussi di eventi capace di assicurare proprietà relative alla memorizzazione di questa enorme quantità di dati. Offrendo astrazioni proprie di questo scenario quali, ad esempio, il flusso di eventi come entità ordinata di eventi, che era garantita essere analizzata e memorizzata una sola volta, scaricando un sistema di analisi e memorizzazione di questo tipo di dati di numerose scelte architetturali altrimenti necessarie. In particolare, proprietà quali la memorizzazione e la garanzia che un evento non sia inavvertitamente elaborato più volte dal sistema, producendo effetti sulle analisi non sempre facili da rilevare e potenzialmente dannosi.
L’implementazione di nautilus, messa a disposizione come progetto open source scritto in Java, è stata battezzata Pravega ed è disponibile su GitHub per tutti coloro che vogliano contribuire al suo sviluppo.
La piattaforma non è uno storage a sé stante, bensì uno strato di software che ha il compito di realizzare l’astrazione di flussi prodotti da dispositivi IoT che possono essere flussi di eventi o flussi di byte. Un insieme di API consentono di interagire con la piattaforma che fa uso di storage esistenti per la memorizzazione dei flussi.
Motori di analisi di flussi di dati, come ad esempio Flink e Spark, si integrano sulle astrazioni fornite dalla piattaforma, consentendo la definizione architetturale non solo degli elementi di elaborazione di flussi, ma anche la loro memorizzazione in un quadro organico con astrazioni ben definite.
Basandosi sul progetto open source, recentemente è stata annunciata la streaming data platform, ovvero un’architettura di stream storage basata su Pravega e su hardware proprietario. L’obiettivo della strategia è chiaro: offrire una soluzione capace di armonizzare i dati prodotti dai dispositivi IoT di un’organizzazione per consentire una più rapida messa a sistema di dispositivi consentendo allo stesso tempo l’abilità di analizzare i dati prodotti secondo tecniche big data.
La cybersecurity dell’IoT
Un tema sempre più importante è la gestione sicura dei dati e dei dispositivi IoT: semplicemente bloccando le letture di un sensore si possono produrre danni incalcolabili nel mondo reale. Un sensore di temperatura di un impianto di industriale che produce dati errati, ad esempio, può causare l’esecuzione di azioni che possono portare a danni arbitrari, incluso esplosioni o deterioramento di sostanze trattate.
L’uso di un’architettura per la gestione di flussi di eventi sicuramente può aiutare a elevare il livello delle analisi necessarie a garantire che la sicurezza logica di un sistema fortemente disaggregato e complesso sia quantomeno corretta, ma non è l’unico aspetto rilevante.
Vi sono numerose iniziative volte ad aumentare la sicurezza dei dispositivi IoT, tra cui val la pena di menzionare Azure Sphere, una piattaforma recentemente annunciata da Microsoft che cerca di supportare la sicurezza di dispositivi IoT offrendo un intero stack di hardware e software che abbia la sicurezza tra i principi ispiratori. Il colosso di Redmond ovviamente mira a promuovere il proprio Cloud Azure per la gestione dell’IoT ed offrire una piattaforma serve anche a promuovere Azure. Ma non si tratta dell’unica opzione in un panorama fitto di software e hardware dedicati allo sviluppo di dispositivi IoT in cui è difficile orientarsi e soprattutto assicurare una consistenza logica che porti a sistemi che non solo funzionino ma siano anche sicuri.
Conclusioni
La sempre più capillare diffusione dei dispositivi IoT non può che richiedere soluzioni capaci di memorizzare ed elaborare i dati prodotti da questi dispositivi in modo più naturalmente distribuito, senza dover inviare il dato ad un punto centrale che inevitabilmente non riuscirebbe ad analizzare i dati prodotti da miliardi di dispositivi.
Ben venga quindi un’astrazione che consenta di parlare di oggetti come flussi che vengono memorizzati e analizzati senza doversi preoccupare di tutti quei micro-dettagli che il trattamento esplicito di singoli eventi comporta. È presto per dire se Pravega offra le astrazioni giuste oppure qualche altro progetto open source sarà capace di offrirne di migliori, ma sicuramente si tratta di un’area che non può che crescere ed affermarsi perché volta ad indirizzare un vuoto tecnologico di cui si sentiva la necessità. L’esistenza di un prodotto, e quindi del supporto e di tutte quelle caratteristiche richieste per poter mettere in produzione un software, aiuta sicuramente l’adozione e di conseguenza lo sviluppo della codebase open source.
