Waver e nuove applicazioni IOT

Introduzone

Questo articolo è il primo di una serie che descriverà il nostro operato verso il mondo dell’internet of things. Partirò dal riflettere su concetti generale fino ad arrivare ad esempi pratici.

Gli articoli sono evidentemente dedicati ad operatori dell’IT ma alcuni passi saranno anche per chi non è un tecnico o un esperto del settore.

 

IoT vs Domotica

Molti confondono internet of things con la domotica ma si tratta di due approcci differenti. Innanzitutto la domotica è prevalentemente orientata alla casa (da cui prende il nome) e comprende una serie di dispositivi o sensori comandati, in genere, da una centralina che è  in grado di reagire in modo intelligente a ciò che avviene nell’ambiente o a dei comandi impartiti da un utilizzatore.

Ogni produttore ha creato il proprio standard di funzionamento e il proprio protocollo di comunicazione, ed è proprio questo, assieme ad altri fattori, che ha decretato il sostanziale fallimento di questa tecnologia rispetto alle aspettative iniziali. L’assoluta impossibilità di fare comunicare dispositivi di vendor differenti e la difficoltà di apprendimento di dispositivi complessi e costoni ne hanno reso una tecnologia solo per appassionati o ricchi.

IoT parte dai concetti base della domotica estendendoli a protocolli liberi e ben conosciuti e dividendo l’intelligenza tra dispositivi hardware e cloud. IoT fa dell’interconnessione dei dispositivi il suo punto di forza dove ogni oggetto è abbastanza intelligente da poter navigare in internet, inviare informazioni e ricevere eventuali comandi. I campi di applicazione di IoT sono praticamente infiniti, ovunque possiamo inserire un dispositivo elettronico in grado di andare in internet potremo sfruttare concetti di IoT, tanto che ora si parla di Internet of Everything.

 

Le nostre applicazioni

Siamo partiti da quanto abbiamo più vicino a noi nella nostra esperienza di produttori di apparati di interconnessione e system integrator, sviluppando una serie di software e nuove tecnologie rivolte a spostare parte dell’intelligenza e dell’operatività in cloud.

Stiamo applicando concetti di IoT agli stessi dispositivi che la devono trasportare. Infatti se un domani inserirò in casa una cappa aspirante intelligente questa dovrà collegarsi ad un wifi che sarà collegato ad un router che sarà collegato ad un ponte radio etc… fino alla destinazione prevista.

Per noi anche quello che è in mezzo tra cloud e device finale merita di essere considerato IoT.

Un tempo il controllo di questi dispositivi veniva eseguito con il protocollo SNMP utilizzando un software che seguendo una predefinita lista inviava le richieste al device memorizzando il risultato in un database di tipo circolare (Round Robin Database). Questo metodo seppur ancor usato soffre di una condizione essenziale e cioè che i dispositivi monitorati o loro eventuali proxy devono essere raggiungibili dal server snmp. Inoltre SNMP, essendo un protocollo molto datato, soffre di una sintassi e di una nomenclatura dei dispositivi molto ostica da gestire. Inoltre il controllo degli apparati da remoto diventa tanto più complessa quanto maggiormente aumentano i dispositivi da verificare. In genere il poller (così è chiamato il software che va in esecuzione a tempi predefiniti) può eseguire un massimo di scansioni date dall’intervallo di esecuzione diviso il tempo medio di risposta di ogni singolo apparato per ogni singolo dato monitorato, al netto dei timeout indotti dai dispositivi non raggiungibili.

 

Il nuovo approccio vede questo paradigma completamente ribaltato. Essendo l’apparato ad inviare il dato al server in modo autonomo dovremo preoccuparci solo della parte server. I vantaggi sono di seguito elencati:

1. Espandibilità dei client connessi praticamente illimitata.
2. Nessun problema per dispositivi collocati dietro NAT.
3. Possibilità di verificare la presenza dei client in modo contestuale.
4. Possibilità di ricevere dei comandi e impostazioni come risposta ad una richiesta di invio o ad una richiesta specifica.

Adesso analizziamo i vari punti

Punto 1

Il primo punto rappresenta il punto focale di tutto il sistema ed è proprio per questo che è nato il cloud come lo intendiamo oggi, cioè un sistema articolato di computers con possibilità di essere espansi per aumentare le capacità di ricezione dei dati. Il limite di questo approccio è dato solo dalla potenza di elaborazione lato server che dovrà essere in gradi di ricevere il numero di richieste inviate dai client.

Punto 2

Il punto due risolve il problema della raggiungibilità dei client che sono in una rete “nattata”. Essendo il processo innescato dal client stesso basterà che sia in grado di andare in internet per poter raggiungere il server e scrivere i dati su di esso.

Punto 3

Essendo l’invio delle informazioni schedulato in modo programmato è facile capire lato server se un dispositivo non si è fatto più sentire. In pratica se ci aspettiamo un’informazione ogni 5 minuti basterà filtrare tutti i dispositivi che non inviano informazioni da più di un certo tempo per avere un ragionevole sospetto.

Punto 4

L’IOT non si ferma solo all’invio dei dati ad un server e successiva realizzazione di un grafico. il dato può essere analizzato ed il client potrebbe ricevere come risposta della richiesta una sequenza di istruzioni per migliorare il proprio stato o variare la propria configurazione, Vedremo questa particolare funzionalità in un successivo articolo dedicato solo a questo argomento.

 

Archiviazione ed analisi dei dati

Una delle base su cui si fonda IoT è proprio la storicizzazione e successiva analisi delle informazioni. Tanti più dati possiamo storicizzare tanto più precisa sarà l’analisi che potremo eseguire.

Va detto però che non è sempre necessario archiviare tutto per sempre, in molto casi sarà sufficiente tenere i dati più significativi e su quelli eseguire i vari calcoli di analisi.

 

Il nostro approccio prevede di accettare tutti i dati in ingresso nel modo più semplice e veloce possibile per poi eseguire successivi calcoli, conteggi ed eventuali cancellazioni di informazioni non necessarie

Il nostro processo prevede sue fase distinte che sono la fase di ingresso o input dei dati e la fase di recupero.

 

Input dati

La fase di input prevede la definizione dei valori scrivibili nel DB da un determinato oggetto identificato con il suo UUID. Ad ogni richiesta è possibile inviare un numero preimpostato di valori che potranno subire un processo di trasformazione per essere adattati all’esigenza di archiviazione e analisi. Ad esempio se abbiamo un dato di traffico di rete che arriva in kb lo potremo trasformare in mb.

 

Esempio pagina di dettaglio UUID

History page per dettaglio valori ricevuti

 

Lettura dati

Una volta definito il modo con cui i dati vengono archiviati nel sistema l’operazione successiva è quella di definire come essi possono essere riletti.

a questo punto si aprono differenti scenari che implicano differenti analisi in base alle varie condizioni. La velocità di analisi dei dati dipende molto dalla quantità di dati analizzati, dalla frequenza di lettura e dall’esigenza di visione in real-time.

il nostro approccio è assolutamente aperto a tutte le soluzioni e sarà l’utente finale che selezionerà la soluzione per lui più efficace.

Ad esempio un lettura real-time e totale per gli ultimi dati inseriti e una rilettura compattata (Averaged) o addirittura differita per dati storici

 

Profondità di analisi

Il problema principale di tutti i sistemi IoT durante la fase di analisi è la definizione della quantità di dati memorizzati definiti in base al tempo ed alla frequenza. In genere si blocca la memorizzazione ad un certo numero di giorni massimo, ma anche la frequenza di aggiornamento è importante per calcolare il numero di record memorizzati sul DB.

Un approccio equilibrato è quello di gestire la frequenza di aggiornamento in base alle effettive esigenze di monitoring o analisi.

Ad esempio il valore di ricarica di una batteria su una stazione radio non ha bisogno di un intervallo di aggiornamento esagerato perché in genere la velocità di scarica è abbastanza lenta ed un aggiornamento ogni 5/10 minuti può essere più che sufficiente per essere allarmati o per valutare una previsione di scarica.

Quindi la formula F*T (Frequenza * Tempo) è determinante per comprendere la quantità di dati memorizzati, la loro dimensione sul disco e successiva difficoltà di elaborazione.

La seguente tabella riporta una visione di numero di record archiviati per singolo dato in base alla frequenza di aggiornamento e al tempo di storicizzazione.

 

Frequenza (Minuti)	1 Giorno	1 Settimana	1 Mese	1 Anno
1	1440	10080	43200	518400
5	288	2016	8640	103680
10	144	1008	4320	51840
30	48	336	1440	17280

 

E’ evidente che analizzare una quantità di 518400 records è sicuramente più pesante che analizzarne 51840, con un rapporto 1/10 sui tempi di calcolo.

 

Analisi in real-time vs Analisi differita

In questo caso un’analisi differita rispetto ad una real-time ci può venire in auto preparando i dati necessari per l’analisi in un formato più compatto o parzialmente elaborato.

Se è vero che in questa condizione non ho un visione totale è altrettanto vero che l’analisi viene eseguita in una frazione del tempo necessario con un risultato molto probabilmente più che soddisfacente.

 

Come detto sopra è sempre importante uno studio preliminare del tipo di dato da memorizzare e della tipologia di rilettura effettivamente necessaria.

 

Un’analisi real-time può essere efficace se copre un panorama di pochi dati se non addirittura restituire solo l’ultimo dato e lasciare il compito dell’analisi o della visualizzazione al client che richiede il valore.

 

Un secondo metodo è quello di prelevare i dati dal database passando per funzionalità di trasformazione che ne compattano la forma così da avere uno storico mediato ma molto compatto.

E’ questo il caso molto usato in IT per il monitoring dei dispositivi di rete dove la frequenza di aggiornamento è di 5 minuti e i dati vengono memorizzati in modo differito in base alla quantità storica il cui massimo è in genere un anno.

I grafici eseguiti con questo sistema soffrono della perdita di informazioni ma sono immediatamente visibili.

 

Il terzo modo per analizzare le informazioni è quella di usare delle procedure differite che preparano i dati in un’altro database mettendo a disposizione delle procedure di rilettura informazioni già filtrate e preparate.

Il grande vantaggio di questo approccio è quello di poter disporre di dati pronti e immediatamente analizzabili con grande velocità con lo svantaggio di avere una perdita di informazioni per quanto riguarda l’immediato per effetto dell’intervallo di elaborazione della procedura che prepara i dati.

 

Conclusione

Siamo ancora agli albori dell’IoT ma molta carne è già stata messa al fuoco.  L’analisi dei dati e l’interazione con i devices diventerà nei prossimi anni un punto cruciale per le infrastrutture di rete.

Il controllo di intere reti permetterà un’analisi approfondita di ogni aspetto della rete sia a livello fisico che geografico con ampie possibilità di espandibilità ed interazione.

Tutto questo si traduce in nuove opportunità di businnes per tutte le entità coinvolte nella catena del valore, dalla gestione del sistema centralizzato, alle singole installazioni.