WP5
Infrastruttura ICT
5.1
Flusso dati in Cloud
| Autore | Francesco D’Amore |
| Data di creazione | 1-Ottobre-2022 |
| Ultima revisione | 30-Ottobre-2022 |
| Titolo | D5.1 – Flusso dati in Cloud |
| Soggetto | WP5 – Infrastruttura ICT |
| Stato | Completato |
| Editore | CNR-IIA |
| Tipo | Deliverable |
| Identificazione | D5.1 |
| Descrizione | |
| Contributi | Mariantonia Bencardino, Delia Evelina Bruno, Valentino Mannarino |
ARCHITETTURA CLOUD BASED PER IL
PROCESSAMENTO DEI DATI
Il fornitore Cloud che si è scelto per ARMONIA è Google Cloud Platform (GCP). Sono state considerate a tal proposito le problematiche relative al blocco tecnologico (Technological Lock In), cioè quel fenomeno che rende una soluzione tecnica strettamente dipendente dalle piattaforme di supporto individuate. Per mitigare il blocco tecnologico dovuto alla scelta di uno specifico rivenditore Cloud (Google nel caso di ARMONIA), sono stati individuati protocolli standard, come MQTT nel caso dei dati trasferiti tramite canali IoT, e componenti Open Source.
Si è inoltre optando per servizi cloud che hanno una chiara controparte anche su altre piattaforme concorrenti di quella prescelta.
Nel caso di ARMONIA, i servizi principali scelti per l’architettura dati sono i seguenti:
- IoT Core: gestore dati IoT e Broker MQTT.
- Dataflow e/o Cloud Functions: processamento e pipeline di dati
- BigQuery: data warehouse
- Cloud Storage: Immagazzinamento standard dei dati
In Immagine 1 si descrive per blocchi il sistema progettato per ARMONIA su Google Cloud. Il flusso dei dati va da sinistra verso destra: inizialmente il dato viene raccolto da dispositivi Single-Board Computer (Computer a Scheda Singola) e successivamente inviati verso il cloud utilizzando flussi in (quasi) tempo reale (Stream Data) tramite ponti IoT, come illustrato del deliverable D5.2.
Nel caso di indisponibilità della rete dati, le informazioni vengono raccolte nel device locale e successivamente trasferiti (Batch Data) in sistemi capaci di immagazzinare dati grezzi (Cloud Storage).
I dati provenienti da canali IoT in (quasi) tempo reale vengono invece raccolti da da buffer che rendono più flessibile l’architettura, disaccoppiando le fasi di inserimento del dato da quelle di immagazzinamento e analisi.
In funzione della struttura del dato raccolto, ci si può trovare nella necessità di processare il dato con approcci diversi:
- ETL (Extraction, Transformation and Load) nel caso di dati scarsamente strutturati
- EL (Extraction and Load) nel caso di dati strutturati.
Nel primo caso la struttura dell’informazione raccolta necessità un processamento importante appena dopo l’inserimento nella piattaforma cloud e si dovrà usare, a tal fine, un componente come Dataflow che permette l’impiego di processi astratti di aggregazione e processamento.
Nel secondo caso il dato raccolto dai devices locali ha una struttura già adeguata all’immagazzinamento in Data Warehouse (Big Query) e saranno quindi sufficienti sistemi meno onerosi dal punto di vista computazionale per il passaggio verso sistemi di immagazzinamento, come ad esempio Cloud Function di GCP.
L’ultimo componente della piattaforma descritta sopra raccoglie il dato strutturato nel Data Warehouse (Big Query) e lo utilizza per creare strumenti per la condivisione del dato in Web Dashboard. A tal fine viene usato Data Studio, componente di GCP direttamente connesso al Data Warehouse.
INTRODUZIONE
E FINALITÀ
I dati prodotti dai sensori individuati nel deliverable D2.1 e assemblati come descritto nel deliverable D2.2 devo essere gestiti tramite risorse computazionali capaci di immagazzinare il dato e condividerlo con l’utente finale.
I processi e i dati nelle moderne architetture ICT (Information and Communication Technologies) vengono ospitati in infrastrutture Cloud dove le risorse computazionali vengono virtualizzate al fine di renderle flessibili e utilizzabili su richiesta dell’utente in base alle reali necessità.
In ARMONIA si vogliono sperimentare metodi di gestione dei dati ambientali orientati al cloud dove, successivamente all’inserimento, i dati verrebbero processati e analizzati. Il processo di acquisizione del dato tramite ponte IoT verrà descritto nel deliverable D5.2, mentre nel presente documento si descrive la configurazione della piattaforma Cloud per la gestione del dato acquisito.
Nella scelta di approcci orientati al Cloud Computing è importante considerare anche tematiche ambientali: acquistare macchine server per il processamento dei dati relativi ad un solo progetto specifico non rientra nelle buone pratiche atte a minimizzare l’impatto ambientale, tema di strettissima attualità che va considerato soprattutto per un progetto con le finalità di quello in oggetto: le risorse cloud, al contrario di quelle tradizionali possono essere rilasciate quando non sono più necessarie.
Dal punto di vista funzionale, l’obiettivo dell’architettura cloud descritta nel prossimo paragrafo è quello di acquisire dati grezzi in arrivo da canali IoT, immagazzinare i dati in data warehouse per il loro processamento e, infine, utilizzare sistemi di Business Intelligence (BI) per visualizzare i dati e condividerli con l’utente finale.
Il documento presente si focalizza sulla sola progettazione e configurazione della piattaforma cloud di ARMONIA: la descrizione dell’implementazione esula dagli scopi di questo deliverable e sarà oggetto uno successivo.
In alcuni casi verranno descritte soluzioni alternativi: in base alle specifiche esigenze, in fase realizzativa, queste scelte collesseranno in una specifica direzione implementativa.
Immagine 1
5.2
IoTTy
| Autore | Francesco D’Amore |
| Data di creazione | 1-Ottobre-2022 |
| Ultima revisione | 30-Ottobre-2022 |
| Titolo | D5.2 – IoTTy |
| Soggetto | WP5 – Infrastruttura ICT |
| Stato | Completato |
| Editore | CNR-IIA |
| Tipo | Deliverable |
| Identificazione | D5.2 |
| Descrizione | |
| Contributi | Mariantonia Bencardino, Delia Evelina Bruno, Valentino Mannarino |
STRUTTURA DEL
PONTE IoT
In figura viene riportato lo schema sintetico della funzionalità della libreria: IoTTy espone localmente un client UDP che si interfaccia con gli script di produzione dei dati, mentre internamente funziona come un automa a stati finiti. Il passaggio da uno stato all’altro di IoTTy viene comandato da messaggi inviati tramite l’interfaccia UDP, mentre l’interfaccia HTTP viene usata per ottenere stato corrente e le informazioni ad esso associate.
Il client di IoTTy è generalmente un loop che legge i dati da sensore, li organizza secondo un formato prestabilito e ordinale e li invia a IoTTy tramite l’interfaccia UDP. Il client deve interrogare l ‘interfaccia HTTP per conoscere lo stato di IoTTy, ad esempio per sapere se IoTTy è in grado di trasmettere attraverso un canale attivo MQTT.
CLIENT UDP:
GENERAZIONE DEI DATI DA SENSORE
Il client UDP di IoTTY è essenzialmente un loop che attiva il canale tramite il comando START e poi prova a inviare dati. Nell’ambito del progetto ARMONIA, IoTTy verrà installato in una Raspberry Pi montata sulla piastra multisensore come progettato e descritto nel deliverable D2.2. Nella Raspberry Pi verrà inserita una procedura Python di cui una porzione di codice viene riportato nell’immagine sopra. Per il lettore che ha dimestichezza con il linguaggio in oggetto, si tratta di un loop che raccoglie il dato, qui semplicemente simulato, e lo invia su interfaccia UDP a IoTTY usando il comando SEND. IoTTy invierà tutto quello che viene dopo il comando SEND sul canale MQTT, se attivo. Il canale MQTT è le ragioni della scelta in tal senso verranno presentati nel prossimo paragrafo.
IL PROTOCOLLO
MQTT
MQTT è uno dei protocolli abilitanti dell’universo IoT. È un protocollo circuitato, che cioè stabilisce un circuito con il ricevente. I messaggi sono estremamente ottimizzati per il contesto applicativo e la comunicazione è bidirezionale: sul protocollo viaggiano non solo i dati dalla sorgente al destinatario ma anche configurazioni e comandi per la sorgente, informazioni che possono essere usati per configurare i dispositivi che producono dati.
Il ricevente è un MQTT Broker, un dispositivo cioè che gestisce il messaggio MQTT proveniente dal client (in questo caso IoTTY) o che invia al client comandi e configurazioni sempre tramite MQTT. Come indicato nel deliverable D5.1, i dati di ARMONIA vengono gestiti in Google Cloud Platform (GCP): GCP, al tempo in cui si sta scrivendo, espone il servizio IoT Core che consente di avere un MQTT Broker pienamente integrato con l’ecosistema GCP. IoT Core verrà dismesso nell’agosto del 2023: questo non darà problemi particolari ai client come IoTTY perchè MQTT è un protocollo standard che potrà funzionare con altri MQTT Broker integrati in GCP come sistemi di terze parti.
L’uso di tali protocolli in ARMONIA consente ai dispositivi sviluppati nel progetto di essere conformi alle metodologie IoT e di ottimizzare quindi l’invio dei messaggi verso le risorse computazionali dove i dati verranno immagazzinati e analizzati.
INTRODUZIONE
E FINALITÀ
I dati prodotti dalla piattaforma multi sensore sviluppata nel WP2 devono essere trasmessi in risorse computazionali in cloud per poter essere processati e analizzati. Trasmettere i dati in (quasi) tempo reale permette di sviluppare applicazioni orientate al monitoraggio, di interesse stringente date le finalità del progetto ARMONIA. La trasmissione in (quasi) tempo reale non è sempre possibile per mancanza o scarsità di rete dati e deve essere sempre presente l’opzione batch, cioè l’accumulo di dati in sistemi locali e la successiva trasmissione massiva.
I sistemi IoT (Internet delle Cose – Internet of Things) stanno assumendo sempre maggior importanza nel collegare risorse computazionali remote con sorgenti dati ed è interesse di chi scrive sperimentare l’approccio IoT in sistemi di misura orientati all’osservazione della terra. I metodi propri dell’IoT possono essere usati nel contesto di ARMONIA per poter trasmettere in (quasi) tempo reale i dati misurati dalle piattaforme di sensori sviluppate nel WP2.
Nei paragrafi successivi verrà presentata IoTTy, una libreria sviluppata nell’ambito del progetto ARMONIA al fine di creare un ponte IoT fra i dati misurati dalla piattaforma multi sensore (deliverables D2.1 e D2.2) e le risorse computazionali progettate per l’analisi e la condivisione del dato (deliverable D5.1).
L’immagine sopra mostra un terminale di IoTTy che comunica all’utente di essere pronto a ricevere messaggi e dati.
SCHEMA DI FLUSSO DI
IoTTy
I comandi che IoTTy può elaborare attraverso la sua interfaccia UDP sono:
- START
- END
- SEND
- STARTM
- ENDM
- SEND
- UPLOAD
I comandi di START e di END provocano un cambio di stato dell’automa interno: START pone il sistema nello stato di ricevere dati tramite il comando SEND. STARTM fa partire il monitoraggio dei dati che vengono così salvati anche localmente e non solo inviati sul canale MQTT mentre ENDM termina il salvataggio in locale dei dati. I dati in locale possono essere inviati massivamente su un cloud remoto tramite il comando UPLOAD. Il comando END termina il canale di invio dati e rilascia le risorse MQTT.
Tutto il testo che segue un comando di SEND viene inviato sul canale MQTT, se attivo: è compito del MQTT Broker del ricevente applicare le logiche che ritiene opportuno per interpretare il messaggio inviato. Questo approccio agnostico sul dato in ingresso conferisce al ponte IoT realizzato da IoTTY la flessibilità necessaria ad essere utilizzato in differenti contesti applicativi, anche al di fuori del progetto ARMONIA.
I comandi di STARTM e ENDM mettono lo stato di IoTTY in modalità monitor: in questo stato i dati inviati tramite SEND vengono anche salvati nel device locale e possono essere inviati tramite il comando UPLOAD, come citato sopra. Questa funzionalità necessità di una configurazione particolare dello storage finale dove verranno inviati e immagazzinati massivamente i dati salvati localmente.
Lo stato dell’automa interno può essere interrogato tramite richiesta GET HTTP, come mostrato nelle due immagini che seguono: sono due messaggi JSON rielaborati dal browser che mostrano nel primo caso lo stato di IoTTY con un canale MQTT attivo e nel secondo caso i dati inviati e gestiti dal monitor interno di IoTTY precedentemente attivato tramite il comando STARTM.
ASPETTI IMPLEMENTATIVI DI
IOTTY
La libreria IoTTy è stata sviluppata in Java. Di fianco la struttura dei package dove viene organizzato il codice sorgente. Attualmente il codice sorgente è gestito in un repository GIT ospitato su Google Cloud. È intenzione di chi scrive di spostare IoTTy su GitHub.
5.3
INTERFACCIA SENSORI
| Autore | Francesco D’Amore |
| Data di creazione | 25-Ottobre-2023 |
| Ultima revisione | 25-Ottobre-2023 |
| Titolo | D5.3 – Interfaccia Sensori |
| Soggetto | WP5 – Infrastruttura ICT |
| Stato | Completato |
| Editore | CNR-IIA |
| Tipo | Deliverable |
| Identificazione | D5.3 |
| Descrizione | |
| Contributi | Mariantonia Bencardino, Delia Evelina Bruno, Valentino Mannarino |
ARCHITETTURA DELL’INTERFACCIA
SENSORI
In Figura 1 si illustra schematicamente l’architettura adottata dall’interfaccia. I sensori sono interfacciati con delle schede proprietarie Alphasense (ISB – si veda figura) che prendono il segnale dei sensori in corrente e lo convertono in un sensore in tensione.
I segnali in corrente provenienti dai sensori inseriti nella piastra sensori (vedi D2.2), vengono convertiti in segnali in tensione dalle schede ISB Alphasense (vedi figura di fianco). Ogni sensori con uscita in corrente è accoppiato con la corrispondente scheda ISB. Il sensore di temperatura, pressione e umidità (PHRT) produce invece i dati direttamente in formato digitale attraverso una interfaccia i2c (Inter Integrated Circuit). Allo stesso modo, il sensore di particolato (OPC) espone dati attraverso un’interfaccia seriale. Per tutti gli altri è stato necessario raccogliere il segnale in tensione e usare un convertitore analogico digitale, come mostrato in Figura 1. A tale scopo è stato utilizzato il convertitore analogico digitale ADS115. Per i riferimenti ai sensori scelti per il progetto ARMONIA si veda il deliverable D2.1.
Una coppia del convertitore ADS115 è stata integrata in una scheda realizzata in laboratorio al fine di supportare i segnali provenienti dai sei sensori (nella configurazione completa) installabili nella piattaforma del prototipo. In Figura 1 questa scheda rappresenta il componente Analog to Digital Converter – ADC. I segnali in uscita da questa scheda, integrati con i segnali già digitali provenienti dai sensori con interfaccia seriale (OPC e PRHT) vengono successivamente forniti al componente che sempre in Figura 1 viene identificato come Processing Unit. Il disegno prototipale prevede come Processing Unit una Raspeberry PI (vedi deliverable D2.1), che consente di preprocessare il dato digitale prima di immagazzinarlo e inviarlo verso sistemi di processamento in cloud. Al fine di velocizzare lo sviluppo del prototipo, si è scelto in fase di realizzazione di utilizzare un microcontrollore Arduino Due che consente l’interfacciamento più agevole con i flussi seriali e uno sviluppo iterativo del prototipo. In una potenziale successiva fase di standardizzazione e consolidamento del prototipo, Arduino Due potrebbe essere sostituito o affiancato con una scheda di tipo Raspberry PI, come da progetto. L’utilizzo in fase prototipale di Arduino Due ha reso necessario l’inserimento di un sistema di storage dei dati esterno (chiamato External Memory in Figura 1) e di un clock esterno per gestire il tempo di sistema.
UNITÀ
DI PROCESSAMENTO
Come accennato nel paragrafo precedente, l’unità di processamento scelta per il prototipo è stato Arduino Due, sistema che consente una veloce prototipizzazione e un agevole interfacciamento con i convertitori ADC e, in cascata, con i sensori della piastra.
Un microcontrollore come Arduino DUE essenzialmente esegue in continuo, in un loop ad una certa frequenza, del codice che nel nostro caso si occupa di interrogare i sensori. Ad ogni iterazione il sistema assume il tempo da inserire nella lettura puntale, interrogando un integrato collegato al microcontrollore che fornisce il clock, e immagazzina il dato come riga appesa ad un file salvato su una scheda micro SD.
Per i lettori interessati ai dettagli implementativi del ciclo di lettura, riportiamo alcuni estratti del codice sorgente. Innanzitutto il sistema viene inizializzato importando gli strumenti che servono alle letture strumentali.
Si possono notare dal codice sopra i comandi necessari per interagire con i due convertitori ADS115. Successivamente è necessario configurare i sistemi attraverso una funzione di configurazione, riportata sotto.
Nella funzione di configurazione vengono impostati parametri necessari ad individuare le risorse dati (i convertitori ADC, ad esempio) ed a configurare i file nella scheda SD dove verranno conservate le informazioni. Finalmente viene fatto partire il loop che caratterizza il funzionamento di un microcontrollore. Nel loop che si riporta sotto vengono lette le informazioni dai sensori per tramite dei convertitori ADC per poi salvare i dati nella scheda SD precedentemente configurata.
06
07
INTRODUZIONE
E FINALITÀ
I dati prodotti dalla piattaforma multi sensore sviluppata nel WP2 devono essere trasmessi in risorse computazionali per poter essere processati e analizzati. La trasmissione dei dati non è sempre possibile per mancanza o scarsità di rete dati e deve essere sempre presente l’opzione batch, cioè l’accumulo di dati in sistemi locali e la successiva trasmissione massiva. Nel deliverable D5.2 è stata descritta una libreria (IoTTy) adatta alla trasmissione in quasi tempo reale tramite protocolli IoT. IoTTy è stata sviluppata per il progetto ARMONIA al fine di collegare il dispositivo prototipale per la produzione del dato (si vedano i risultati del WP2) con i sistemi di immagazzinamento e processamento in cloud: in questo deliverable invece verrà descritta l’interfaccia con i sensori, cioè di quei sistemi che raccolgono i segnali in corrente e la modificano in informazioni adatte ad essere eventualmente trasmesse con IoTTy.
REALIZZAZIONE
In questo paragrafo finale vengono mostrate alcune immagini del sistema descritto precedentemente e realizzato nella piastra sensori descritta nei deliverables afferenti il WP2.
I sensori sono alloggiati nella piastra attraverso gli ISB Alphasense descritti sopra che ne estraggono i segnali in corrente. La parte sensore risulta invece esposta come mostrato in figura centrale. La piastra di alloggiamento è estraibile al fine di consentire l’agevole gestione del dispositivo in fase di sviluppo e testing in laboratorio. Mentre quindi la zona inferiore viene esposta per la misurazione dei fenomeni di interesse, internamente il box protegge i dispositivi elettronici descritti sopra. Il risultato finale è mostrato nella terza figura sotto, dove tutti i componenti sono montati e interfacciati tra loro. Si possono notare i due ADS montati nell’integrato che li contiene, collegandoli direttamente alle schede ISB di ogni sensore che necessità una conversione digitale del segnale in tensione. Gli ADS sono poi collegati all’unità di processamento rappresentata dalla scheda Arduino Due anch’essa presente in figura. Il sistema si alimenta con una fonte a 12 Volt. In figura l’alimentazione è fornita da un cavo posto nell’anima del palo di supporto, collegato al pannello fotovoltaico posto in cima ad esso.
D5.1
D5.2
D5.3
Contattaci
CNR-IIA
U.O.S. di Rende
Svolge attività di ricerca e sviluppo tecnologico nel campo dell’inquinamento atmosferico su scala regionale e globale e ha un ruolo di leadership nel contesto di progetti e programmi Internazionali, Europei e Nazionali. Opera in partnership con i maggiori Istituti ed Università in Europa, Australia, Oriente, Nord e Sud America.
WWW.RENDE.IIA.CNR.IT
Replanet
È un’azienda con sede a Cosenza che opera da anni nel mercato delle energie rinnovabili e dell’efficienza energetica. Replanet promuove la diffusione di comportamenti sostenibili e di applicazioni tecnologiche finalizzate ad un uso razionale delle risorse ambientali ed energetiche.