Articolazione dei WP
RILIES è un progetto strutturato e articolato secondo WP logici riportati di seguito con la sintetica illustrazione delle attività ed il ruolo dei partner.
Il progetto è articolato in 3 Work Packages, ciascuno dei quali è strutturato in più attività realizzative. Di seguito viene presentata la descrizione delle varie sezioni del progetto, con l’indicazione dei partner coinvolti e delle competenze apportate.
Workpackage 1: Analisi del contesto e stato dell’arte
AR1.1 – Analisi del fabbisogno dell’Amministrazione Comunale di Crotone.
L’attività iniziale del progetto consisterà nel mettere a punto con i referenti dell’ente proponente l’ambito dell’intervento progettuale, attraverso una serie di incontri mirati a condividere i seguenti aspetti:
– Problemi dovuti all’esondazione dei corsi d’acqua nel territorio crotonese
– Sistemi di monitoraggio e allerta attualmente utilizzati
– Risorse dirette dell’ente proponente da destinare a compiti di monitoraggio e allerta
– Altri soggetti istituzionali e privati coinvolti nella gestione del problema
– Entità della popolazione interessata in modo diretto o indiretto al problema;
– Problemi dovuti all’esondazione dei corsi d’acqua nel territorio crotonese
– Sistemi di monitoraggio e allerta attualmente utilizzati
– Risorse dirette dell’ente proponente da destinare a compiti di monitoraggio e allerta
– Altri soggetti istituzionali e privati coinvolti nella gestione del problema
– Entità della popolazione interessata in modo diretto o indiretto al problema;
AR1.2 – Analisi del contesto idrografico oggetto dell’intervento
Il fiume Esaro è uno dei principali corsi d’acqua della regione Calabria ed attraversa la città di Crotone (KR) nella sua parte terminale, per circa 3.5 km. Il bacino idrologico nel suo complesso ha una estensione di circa 106 km2, nella media considerando le caratteristiche dei piccoli bacini costieri calabresi. L’asta principale ha una lunghezza di circa 20 km ed origine a circa 300 m s.l.m. Alla formazione del deflusso contribuiscono principalmente tre diversi sottobacini individuati da tre torrenti: il torrente Acqua della Quercia, il torrente Sant’Anna ed il torrente Tufolo.
Questi tre corsi d’acqua sono quelli che, unendosi poco prima dell’inizio del centro abitato di Crotone, possono essere considerati delle “sentinelle” in riferimento a fenomeni di esondazione localizzata e/o diffusa che interessino la città di Crotone (come quella tristemente nota dell’ottobre del 1996). Pertanto, nella proposta progettuale in oggetto, si è scelto di individuare tre sezioni (Figura 1), una per ciascun corso d’acqua, ove collocare gli idrometri, ossia strumenti per misurare i livelli idrici, ed allo stesso tempo individuare i sottobacini delle aree di monte, cioè quelle porzioni di territorio che contribuiscono a generare il deflusso superficiale che attraversa quella sezione. In corrispondenza delle sezioni relative a ciascun idrometro e di un numero adeguato di sezioni immediatamente a monte e a valle si procederà inoltre all’esecuzione di una serie di rilievi idrografici diretti necessari per la successiva analisi idraulica finalizzata alla stima della scala di deflusso (AR2.3 e AR3.1). In corrispondenza di zone significative (in prossimità dei crinali o dei baricentri geometrici) di ciascun sottobacino sarà posizionata inoltre una stazione meteo completa, tale da misurare in continuo le principali variabili meteo-idrologiche. In particolare, la pioggia misurata sarà assimilata come rappresentativa dell’intero sottobacino e dunque indicativa delle soglie pluviometriche da individuare.
Il fiume Esaro nella sua parte terminale è reggimentato artificialmente, tuttavia questo intervento di mitigazione strutturale può generare degli inconvenienti. Infatti, in considerazione delle velocità di deflusso considerevolmente aumentate si può dar luogo a fenomeni di esondazione localizzata in prossimità di punti nevralgici per la conformazione idrografica del territorio, come per esempio i ponti o le curve.
Pertanto, al fine di migliorare sensibilmente la qualità del progetto ed in vista della successiva analisi idraulica (AR2.3) si procederà all’esecuzione di rilievi topografici supportati da LiDAR su circa 8.7 km di reticolo idrografico (Figura 1), cioè su tutte le aste fluviali a valle delle sezioni scelte per il posizionamento degli idrometri. Il rilievo con sensore LiDAR garantirà un’accurata precisione, dell’ordine inferiore al metro, ed inoltre riguarderà tutte le aree di “pertinenza idraulica”, quindi si estenderà con un buffer anche oltre gli argini.
Tutto ciò al fine di garantire un’adeguata accuratezza geomorfologica alla successiva analisi idraulica.
Prodotti attesi:
1. Report con analisi aggiornata del contesto idrografico oggetto dell’intervento inclusivo di analisi idrologica
2. Rilievo topografico delle sezioni dell’asta fluviale in corrispondenza degli idrometri e delle sezioni immediatamente a valle (fino a 150 m) e a monte (fino a 150 m), per un totale di circa 11 rilievi. Restituzione in tavole e file .dwg
3. Rilievo con sensore LiDAR dell’asta fluviale a valle degli idrometri fino al mare, da argine destro ad argine sinistro considerando un ulteriore buffer di 40 m in entrambi i lati. Restituzione del modello digitale delle superfici (DSM) e del terreno (DTM) sia con sistema di riferimento WGS84 e quote ellissoidiche che con sistema di riferimento UTM33 e quote ortometriche.
Questi tre corsi d’acqua sono quelli che, unendosi poco prima dell’inizio del centro abitato di Crotone, possono essere considerati delle “sentinelle” in riferimento a fenomeni di esondazione localizzata e/o diffusa che interessino la città di Crotone (come quella tristemente nota dell’ottobre del 1996). Pertanto, nella proposta progettuale in oggetto, si è scelto di individuare tre sezioni (Figura 1), una per ciascun corso d’acqua, ove collocare gli idrometri, ossia strumenti per misurare i livelli idrici, ed allo stesso tempo individuare i sottobacini delle aree di monte, cioè quelle porzioni di territorio che contribuiscono a generare il deflusso superficiale che attraversa quella sezione. In corrispondenza delle sezioni relative a ciascun idrometro e di un numero adeguato di sezioni immediatamente a monte e a valle si procederà inoltre all’esecuzione di una serie di rilievi idrografici diretti necessari per la successiva analisi idraulica finalizzata alla stima della scala di deflusso (AR2.3 e AR3.1). In corrispondenza di zone significative (in prossimità dei crinali o dei baricentri geometrici) di ciascun sottobacino sarà posizionata inoltre una stazione meteo completa, tale da misurare in continuo le principali variabili meteo-idrologiche. In particolare, la pioggia misurata sarà assimilata come rappresentativa dell’intero sottobacino e dunque indicativa delle soglie pluviometriche da individuare.
Il fiume Esaro nella sua parte terminale è reggimentato artificialmente, tuttavia questo intervento di mitigazione strutturale può generare degli inconvenienti. Infatti, in considerazione delle velocità di deflusso considerevolmente aumentate si può dar luogo a fenomeni di esondazione localizzata in prossimità di punti nevralgici per la conformazione idrografica del territorio, come per esempio i ponti o le curve.
Pertanto, al fine di migliorare sensibilmente la qualità del progetto ed in vista della successiva analisi idraulica (AR2.3) si procederà all’esecuzione di rilievi topografici supportati da LiDAR su circa 8.7 km di reticolo idrografico (Figura 1), cioè su tutte le aste fluviali a valle delle sezioni scelte per il posizionamento degli idrometri. Il rilievo con sensore LiDAR garantirà un’accurata precisione, dell’ordine inferiore al metro, ed inoltre riguarderà tutte le aree di “pertinenza idraulica”, quindi si estenderà con un buffer anche oltre gli argini.
Tutto ciò al fine di garantire un’adeguata accuratezza geomorfologica alla successiva analisi idraulica.
Prodotti attesi:
1. Report con analisi aggiornata del contesto idrografico oggetto dell’intervento inclusivo di analisi idrologica
2. Rilievo topografico delle sezioni dell’asta fluviale in corrispondenza degli idrometri e delle sezioni immediatamente a valle (fino a 150 m) e a monte (fino a 150 m), per un totale di circa 11 rilievi. Restituzione in tavole e file .dwg
3. Rilievo con sensore LiDAR dell’asta fluviale a valle degli idrometri fino al mare, da argine destro ad argine sinistro considerando un ulteriore buffer di 40 m in entrambi i lati. Restituzione del modello digitale delle superfici (DSM) e del terreno (DTM) sia con sistema di riferimento WGS84 e quote ellissoidiche che con sistema di riferimento UTM33 e quote ortometriche.
AR1.3 – Stato dell’arte della sensoristica e dei modelli di analisi
Questa azione di ricerca è tesa ad inquadrare il posizionamento della scelta progettuale nel ventaglio di strumenti operativi a disposizione per il monitoraggio e preannuncio del rischio alluvioni, esplicitando le caratteristiche che rendono il progetto “smart” e “low-cost”, applicabile dunque anche in contesti operativi privi di specifiche competenze e risorse computazionali.
Per quanto riguarda in particolare la misura della pioggia, secondo le stringenti norme internazionali WMO (Weather Meteorological Organization), i pluviometri devono avere una precisione di 0.2 mm ed un’accuratezza di ± 0.05 mm. Normalmente essi sono costituiti da un recipiente cilindrico, che può avere diverse dimensioni, con all’interno un imbuto per convogliare l’acqua verso una camera sottostante dotata di bascula oscillante in grado di fornire la misura. Tali strumenti devono essere in metallo in modo tale da garantirne la durata nel tempo alle diverse condizioni climatiche, inoltre devono essere costruiti con delle caratteristiche costruttive tali da minimizzare il disturbo generato dal vento o dall’evaporazione dovuta alle alte temperature estive.
Per quanto riguarda i misuratori di portata esistono diverse scelte possibili, in particolare, occorre accoppiare delle misure di livello idrometrico a delle misure di velocità della corrente idrica, pertanto oltre agli idrometri, che sono strumenti dedicati alla sola misura dei livelli idrometrici, talvolta si affiancano misuratori Doppler per ottenere la velocità idrica superficiale. Tuttavia, questi misuratori di velocità sono molto costosi sia per l’installazione che per la manutenzione stessa.
Nell’ottica generale del progetto, che intende offrire soluzioni affidabili e al contempo “low-cost” alla problematica del rischio idraulico, si è scelto di utilizzare dei sensori basati sul paradigma “Open Hardware”, che si fonda sul concetto di rendere fruibile a chiunque la strumentazione fisica, *l’hardware, per effettuare misure di grandezze di interesse meteo-idrologico. Tale paradigma consente di avere sensori che rispettano tutti gli standard WMO, ma allo stesso tempo notevoli vantaggi dal punto di vista economico.
Per quanto riguarda il preannuncio dei fenomeni alluvionali, i sistemi più complessi, ma anche più efficienti, sono costituiti dall’accoppiamento fra modelli numerici dell’atmosfera (NWP – Numerical Weather Prediction) e modelli idrologici-idraulici. Il vantaggio principale di tale catena modellistica è dato dalla capacità di fornire con opportuno anticipo previsioni utili ad allertare la popolazione in caso di necessità (Avolio et al., 2019). Tuttavia, lo svantaggio di questa modellistica è dato dall’elevato onere computazionale richiesto dai modelli atmosferici (Furnari et al, 2019), i quali non solo richiedono ingenti costi in termini di infrastrutture informatiche, ma anche personale con elevate competenze specifiche.
Pertanto, nella visione generale “smart” e “low-cost” del progetto, si è scelto di utilizzare un approccio basato sul cosiddetto “metodo inverso” (AR2.1), che valutando l’evoluzione temporale delle serie di pioggia misurate in tempo reale è in grado di fornire elementi importanti di supporto alle decisioni per il rischio alluvioni.
L’impegno relativo a quest’azione sarà dunque soprattutto indirizzato alla descrizione delle varie scelte operative disponibili nell’approccio al problema, puntualizzandone vantaggi e svantaggi, per poi soffermarsi in particolare sulla soluzione operativa adottata nel presente progetto.
Prodotti attesi:
1. Report relativo al posizionamento della proposta progettuale nel panorama degli strumenti operativi a disposizione per il monitoraggio e preannuncio del rischio alluvioni
Per quanto riguarda in particolare la misura della pioggia, secondo le stringenti norme internazionali WMO (Weather Meteorological Organization), i pluviometri devono avere una precisione di 0.2 mm ed un’accuratezza di ± 0.05 mm. Normalmente essi sono costituiti da un recipiente cilindrico, che può avere diverse dimensioni, con all’interno un imbuto per convogliare l’acqua verso una camera sottostante dotata di bascula oscillante in grado di fornire la misura. Tali strumenti devono essere in metallo in modo tale da garantirne la durata nel tempo alle diverse condizioni climatiche, inoltre devono essere costruiti con delle caratteristiche costruttive tali da minimizzare il disturbo generato dal vento o dall’evaporazione dovuta alle alte temperature estive.
Per quanto riguarda i misuratori di portata esistono diverse scelte possibili, in particolare, occorre accoppiare delle misure di livello idrometrico a delle misure di velocità della corrente idrica, pertanto oltre agli idrometri, che sono strumenti dedicati alla sola misura dei livelli idrometrici, talvolta si affiancano misuratori Doppler per ottenere la velocità idrica superficiale. Tuttavia, questi misuratori di velocità sono molto costosi sia per l’installazione che per la manutenzione stessa.
Nell’ottica generale del progetto, che intende offrire soluzioni affidabili e al contempo “low-cost” alla problematica del rischio idraulico, si è scelto di utilizzare dei sensori basati sul paradigma “Open Hardware”, che si fonda sul concetto di rendere fruibile a chiunque la strumentazione fisica, *l’hardware, per effettuare misure di grandezze di interesse meteo-idrologico. Tale paradigma consente di avere sensori che rispettano tutti gli standard WMO, ma allo stesso tempo notevoli vantaggi dal punto di vista economico.
Per quanto riguarda il preannuncio dei fenomeni alluvionali, i sistemi più complessi, ma anche più efficienti, sono costituiti dall’accoppiamento fra modelli numerici dell’atmosfera (NWP – Numerical Weather Prediction) e modelli idrologici-idraulici. Il vantaggio principale di tale catena modellistica è dato dalla capacità di fornire con opportuno anticipo previsioni utili ad allertare la popolazione in caso di necessità (Avolio et al., 2019). Tuttavia, lo svantaggio di questa modellistica è dato dall’elevato onere computazionale richiesto dai modelli atmosferici (Furnari et al, 2019), i quali non solo richiedono ingenti costi in termini di infrastrutture informatiche, ma anche personale con elevate competenze specifiche.
Pertanto, nella visione generale “smart” e “low-cost” del progetto, si è scelto di utilizzare un approccio basato sul cosiddetto “metodo inverso” (AR2.1), che valutando l’evoluzione temporale delle serie di pioggia misurate in tempo reale è in grado di fornire elementi importanti di supporto alle decisioni per il rischio alluvioni.
L’impegno relativo a quest’azione sarà dunque soprattutto indirizzato alla descrizione delle varie scelte operative disponibili nell’approccio al problema, puntualizzandone vantaggi e svantaggi, per poi soffermarsi in particolare sulla soluzione operativa adottata nel presente progetto.
Prodotti attesi:
1. Report relativo al posizionamento della proposta progettuale nel panorama degli strumenti operativi a disposizione per il monitoraggio e preannuncio del rischio alluvioni
WP2 – Progettazione e realizzazione della soluzione
AR2.1 – Individuazione ambito della sperimentazione obiettivi e confini del progetto
L’obiettivo generale della proposta RILIES è la definizione, implementazione e successiva sperimentazione di un sistema di monitoraggio e preannuncio caratterizzato da sensoristica low-cost e modelli di calcolo speditivi in grado di fornire indicazioni utili e tempestive a supporto dei decisori per il rischio alluvioni. La sperimentazione del sistema avverrà in un’area particolarmente sensibile alla tematica, il bacino dell’Esaro di Crotone, un corso d’acqua che nel recente passato (14 ottobre 1996) ha prodotto una violenta inondazione causando ben 6 vittime, oltre a danni economici di entità rilevantissima.
Il concetto alla base del sistema che si intende sperimentare è dato dalla ricerca della cosiddetta soluzione inversa della classica trasformazione degli afflussi meteorici in deflussi di piena. Tramite questo approccio, assegnata una portata di guardia nelle sezioni caratteristiche di un tronco fluviale, si determina tramite modellistica numerica la soglia pluviometrica di allertamento, ossia la quantità di precipitazione lorda che per diverse durate determina la portata di piena assegnata. Il valore della portata di guardia è definito, in particolare, come quella quantità d’acqua che, transitando nella sezione di controllo, determina un livello idrico tale da garantire un franco medio sufficiente (es. 1 m) per ciascun tronco principale del reticolo idrografico di cui è nota la geometria.
In seguito all’esondazione del fiume Esaro del 1996, all’interno del “Piano di interventi infrastrutturali di emergenza e di prima sistemazione idrogeologica nel territorio del comune di Crotone”, è stata prevista la determinazione delle soglie idrometeorologiche di allerta ed allarme delle piene fluviali utilizzando l’approccio sopra esposto. La proposta RILIES intende rivisitare ed aggiornare la metodologia facendo leva su una serie di importanti innovazioni scientifiche e tecnologiche.
L’architettura generale del sistema può essere definita dalla seguente catena procedurale:
• Monitoraggio in continuo delle principali variabili meteo-idrologiche nei tre principali sottobacini che comprendono l’area a monte del bacino del Fiume Esaro e dei livelli idrici in corrispondenza delle sezioni di chiusura degli stessi sottobacini
• Trasmissione in tempo reale delle misure presso il database NOSQL ElasticSearch; ElasticSearch nasce come motore di analisi e ricerca RESTful altamente scalabile, distribuito e open-source che offre analisi dei log, monitoraggio delle applicazioni in tempo reale, analisi dei flussi di clic e altro ancora. Elasticsearch memorizza e recupera strutture dati in tempo reale. Ha funzionalità multi-tenant con un’interfaccia web HTTP, presenta i dati sotto forma di documenti JSON strutturati, rende la ricerca full-text accessibile tramite RESTful API utilizzabili con client Web per linguaggi come PHP, Ruby, .Net e Java.
• Utilizzo delle misure di pioggia per la valutazione, tramite l’utilizzo integrato di modelli idrologici ed idraulici ed algoritmi di real time analytics, del raggiungimento della soglia pluviometrica di allertamento e quindi dell’eventuale rischio alluvioni.
La valutazione del rischio avverrà, per le specifiche condizioni di umidità del suolo associate all’evento in analisi, confrontando l’andamento delle piogge misurate con un poderoso database di serie di piogge sintetiche in grado di determinare il raggiungimento della portata di guardia. Le serie di piogge sintetiche saranno selezionate, adottando un approccio del tipo Monte Carlo e valutando evoluzioni temporali tipiche associate sia a fenomeni meteorologici convettivi che a sistemi frontali, tramite una catena di modellazione idrologico-idraulica. Il confronto tra piogge osservate e piogge sintetiche si baserà su reti neurali, e quindi su tecniche di apprendimento automatico che, in base ad alcuni recenti studi, risultano molto più vantaggiose rispetto l’uso di tecniche e metodi analitici, in cui la previsione dei fenomeni a partire da dati empirici è soggetto ad errori o incompletezza delle informazioni.
Per ognuno degli elementi del sistema possono essere evidenziati i seguenti aspetti innovativi:
1. Le misure meteo (in particolare le misure di pioggia) e di livello idrometrico (da cui saranno desunti, attraverso la definizione delle scale di deflusso, i valori di portata) saranno eseguite con sensori low-cost, ma rispettosi di standard di accuratezza elevati, basati sul paradigma open hardware
2. Trasmissione dati in tempo reale. Questa fase è molto importante per il corretto monitoraggio dei corsi d’acqua, e verrà effettuata attraverso l’uso di tecnologia LORA abbinata all’uso di rete Cellulare GSM/3G+ …[IFM] 3. La modellazione idrologica relativa alla trasformazione afflussi-deflussi sarà costantemente monitorata e validata su tre sezioni idrometriche, permettendo di valutare con la necessaria accuratezza le condizioni di umidità del suolo medie delle rispettive aree drenanti
4. La determinazione della portata di guardia tramite modellazione idraulica si avvarrà di un rilievo eseguito con sensore Lidar per l’intera asta fluviale a valle degli idrometri di controllo, permettendo un livello di dettaglio assolutamente inedito
5. Algoritmi di analytics, attraverso l’applicazione di tecnologie di intelligenza Artificiale con le quali il sistema permetterà di evidenziare le possibili criticità dei corsi d’acqua monitorati. Il prototipo non deve essere inteso come un sistema di Event Alerting ma un sistema di supporto alle decisioni relative alle criticità sui flussi d’acqua.
Il concetto alla base del sistema che si intende sperimentare è dato dalla ricerca della cosiddetta soluzione inversa della classica trasformazione degli afflussi meteorici in deflussi di piena. Tramite questo approccio, assegnata una portata di guardia nelle sezioni caratteristiche di un tronco fluviale, si determina tramite modellistica numerica la soglia pluviometrica di allertamento, ossia la quantità di precipitazione lorda che per diverse durate determina la portata di piena assegnata. Il valore della portata di guardia è definito, in particolare, come quella quantità d’acqua che, transitando nella sezione di controllo, determina un livello idrico tale da garantire un franco medio sufficiente (es. 1 m) per ciascun tronco principale del reticolo idrografico di cui è nota la geometria.
In seguito all’esondazione del fiume Esaro del 1996, all’interno del “Piano di interventi infrastrutturali di emergenza e di prima sistemazione idrogeologica nel territorio del comune di Crotone”, è stata prevista la determinazione delle soglie idrometeorologiche di allerta ed allarme delle piene fluviali utilizzando l’approccio sopra esposto. La proposta RILIES intende rivisitare ed aggiornare la metodologia facendo leva su una serie di importanti innovazioni scientifiche e tecnologiche.
L’architettura generale del sistema può essere definita dalla seguente catena procedurale:
• Monitoraggio in continuo delle principali variabili meteo-idrologiche nei tre principali sottobacini che comprendono l’area a monte del bacino del Fiume Esaro e dei livelli idrici in corrispondenza delle sezioni di chiusura degli stessi sottobacini
• Trasmissione in tempo reale delle misure presso il database NOSQL ElasticSearch; ElasticSearch nasce come motore di analisi e ricerca RESTful altamente scalabile, distribuito e open-source che offre analisi dei log, monitoraggio delle applicazioni in tempo reale, analisi dei flussi di clic e altro ancora. Elasticsearch memorizza e recupera strutture dati in tempo reale. Ha funzionalità multi-tenant con un’interfaccia web HTTP, presenta i dati sotto forma di documenti JSON strutturati, rende la ricerca full-text accessibile tramite RESTful API utilizzabili con client Web per linguaggi come PHP, Ruby, .Net e Java.
• Utilizzo delle misure di pioggia per la valutazione, tramite l’utilizzo integrato di modelli idrologici ed idraulici ed algoritmi di real time analytics, del raggiungimento della soglia pluviometrica di allertamento e quindi dell’eventuale rischio alluvioni.
La valutazione del rischio avverrà, per le specifiche condizioni di umidità del suolo associate all’evento in analisi, confrontando l’andamento delle piogge misurate con un poderoso database di serie di piogge sintetiche in grado di determinare il raggiungimento della portata di guardia. Le serie di piogge sintetiche saranno selezionate, adottando un approccio del tipo Monte Carlo e valutando evoluzioni temporali tipiche associate sia a fenomeni meteorologici convettivi che a sistemi frontali, tramite una catena di modellazione idrologico-idraulica. Il confronto tra piogge osservate e piogge sintetiche si baserà su reti neurali, e quindi su tecniche di apprendimento automatico che, in base ad alcuni recenti studi, risultano molto più vantaggiose rispetto l’uso di tecniche e metodi analitici, in cui la previsione dei fenomeni a partire da dati empirici è soggetto ad errori o incompletezza delle informazioni.
Per ognuno degli elementi del sistema possono essere evidenziati i seguenti aspetti innovativi:
1. Le misure meteo (in particolare le misure di pioggia) e di livello idrometrico (da cui saranno desunti, attraverso la definizione delle scale di deflusso, i valori di portata) saranno eseguite con sensori low-cost, ma rispettosi di standard di accuratezza elevati, basati sul paradigma open hardware
2. Trasmissione dati in tempo reale. Questa fase è molto importante per il corretto monitoraggio dei corsi d’acqua, e verrà effettuata attraverso l’uso di tecnologia LORA abbinata all’uso di rete Cellulare GSM/3G+ …[IFM] 3. La modellazione idrologica relativa alla trasformazione afflussi-deflussi sarà costantemente monitorata e validata su tre sezioni idrometriche, permettendo di valutare con la necessaria accuratezza le condizioni di umidità del suolo medie delle rispettive aree drenanti
4. La determinazione della portata di guardia tramite modellazione idraulica si avvarrà di un rilievo eseguito con sensore Lidar per l’intera asta fluviale a valle degli idrometri di controllo, permettendo un livello di dettaglio assolutamente inedito
5. Algoritmi di analytics, attraverso l’applicazione di tecnologie di intelligenza Artificiale con le quali il sistema permetterà di evidenziare le possibili criticità dei corsi d’acqua monitorati. Il prototipo non deve essere inteso come un sistema di Event Alerting ma un sistema di supporto alle decisioni relative alle criticità sui flussi d’acqua.
AR2.2 – Progettazione sistema di IoT (Gateway di campo e Componente Cloud)e di Analytics
Obiettivo di questa attività è la progettazione del sistema IoT per la gestione dei sensori e l’acquisizione dei dati e del sistema di Analytics per l’elaborazione, anche in tempo reale, dei dati al fine di costruire informazioni per gli utenti diretti e indiretti del sistema sperimentale. Dal punto di vista software saranno utilizzate componenti open source già note ad IFM che andranno a comporre i diversi blocchi del sistema che è riepilogato nello schema seguente.
Si individuano le seguenti componenti:
– Sensori di campo – sono i sensori individuati tra quelli descritti nell’attività 1.3 che saranno gestiti da un Edge Gateway su cui risiederà la logica elaborativa periferica con il compito di acquisirei dati e trasferirli opportunamente codificati e formattati alla piattaforma cloud IoT attraverso un sistema di comunicazione basato su protocolli industriali di trasporto e applicativi offerti dalla piattaforma stessa (genericamente HTTP/REST e MQTT sopra IP). La logica elaborativa presente sugli edge gateway sarà costruita in base alle interfacce di comunicazione dei sensori e produrrà un flusso normalizzato di dati verso la piattaforma IoT. Sarà implementata da Eclipse Kura che è un IoT Edge Framework estensibile e open source basato su Java / OSGi. Nella piattaforma è impiegato come software di base per la gestione dei gateway, mettendo in comunicazione i vari sensori impiegati con la piattaforma IoT in cloud. Kura offre accesso API alle interfacce hardware dei gateway IoT (porte seriali, GPS, watchdog, GPIO, I2C, ecc.). È dotato di protocolli di campo pronti all’uso (tra cui Modbus, OPC-UA, S7), un contenitore di applicazioni e una programmazione del flusso di dati visivi basata sul web per acquisire dati dal campo, elaborarli al limite e pubblicarli sulle principali piattaforme cloud IoT attraverso la connettività MQTT.
– IoT – è responsabile dell’autenticazione centralizzata dei dispositivi di campo (edge gateway), dello scambio di messaggi (informazioni lette dal campo) tramite protocolli IoT standard. Tali informazioni vengono “ingerite” dal middleware IoT e vengono redirette secondo regole verso gli altri consumatori, oggi rappresentati dalla piattaforma di analitica ma comunemente anche mobile/web applications. Caratteristiche fondamentali di un IoT middleware open source in grado di soddisfare i requisiti dell’attività sono il supporto dei protocolli MQTT e HTTP/REST per lo scambio di messaggi, la gestione degli account device utilizzati tramite tali protocolli e la possibilità’ di impostare regole di “Routing” sui messaggi, quindi allarmi e trigger, in grado di reagire in tempo reale, anche con elevati throughput (bisogna considerare che l’infrastruttura possa ingerire milioni di messaggi al secondo e che l’IoT middleware debba essere in grado di gestirli). Le componenti open source individuate, in termini di prestazioni, scalabilità’ e completezza del software è Eclipse IoT (Kapua) che supporta diversi protocolli di ingestione dati e ha una moderna interfaccia web, colloquia in modo nativo con il software agent Eclipse Kura presente sugli edge gateway.
– Communication Layer – il compito di trasferire le infoprmazoni dalla piattaforma di IoT al sistema di Analytics è affidato alla componente Apache Kafka. E’ una piattaforma open source di stream processing scritta in Java e Scala e sviluppata dall’Apache Software Foundation. Il progetto mira a creare una piattaforma a bassa latenza ed alta velocità per la gestione di feed dati in tempo reale. Le informazioni acquisite e presenti nella piattaforma IoT vengono inviate alla piattaforma di Analytics attraverso dei Job creati con Vert.X.
– Analytics Real Time e Batch – le componenti del sistema elaborano gli algoritmi di l’intelligenza artificiale per analizzare i dati che provengono dalla piattaforma di IoT e ancor prima dai sensori di campo che saranno installati nell’area interessata dall’intervento. Ci saranno due tipi di elaborazioni, in Real Time e Batch ed entrambi producono report e dashboard per la segnalazione di anomalie, destinate a chi deve successivamente prendere delle decisioni, dell’area soggetta a controllo. La componente dove vengono memorizzati i big data provenienti dai sensori è ElasticSearch; è un server di ricerca basato su Lucene, con capacità Full Text, con supporto ad architetture distribuite. Tutte le funzionalità sono nativamente esposte tramite interfaccia a servizi di tipo RESTful, mentre le informazioni sono gestite come documenti JSON. Elasticsearch nel gennaio 2016 risulta essere il motore di ricerca più utilizzato. Date le sue alte performance nella ricerca di documenti, nell’ambito del progetto, viene usato come database NOSQL. Apache Spark è un framework open source per il calcolo distribuito sviluppato dall’AMPlab della Università della California e successivamente donato alla Apache Software Foundation. Il meccanismo di processing delle informazioni attraverso funzionalità “in-memory” multilivello fornisce prestazioni molto elevate rispetto ad altri software di pari funzionalità. Grazie alle sue alte prestazioni nel calcolo computazionale, Spark è utilizzato per implementazione degli algoritmi di apprendimento automatico con tecniche di Machine Learning e Deep Learning. Nel progetto viene usato in due modalità, prelevando direttamente dati forniti su Code Kafka, attraverso la libreria Apache Spark Streaming, o in modalità batch, prelevando i dati dal Db No SQL Elastic Search, attraverso l’uso delle librerie standard Apache Sparck Batch. Eclipse Vert.x è un framework per la creazione di sistemi “event driven” e “non blocking”. Ciò significa che è possibile creare applicazioni che gestiscono dati in concorrenza usando ed ottimizzando le poche risorse hardware a disposizione. Sposa a pieno il concetto delle applicazioni a Microservizi. Nella piattaforma viene utilizzato per creare job di acquisizione dati dalla piattaforma IoT in Cloud e il loro riversamento nel database Elastic Search. Può essere inoltre utilizzato per inviare direttamente dati agli applicativi (web e mobile) in modalità WebSocket agli stakeholder del sistema. Il software HEC-RAS permette di modellare la propagazione di una corrente lungo un d’acqua utilizzando uno schema unidimensionale sia in condizioni di moto permanente che in condizioni di moto vario. Il programma può essere utilizzato per simulare la propagazione dell’onda di piena lungo il reticolo idraulico e determinare l’altezza che il livello idrico raggiunge nelle varie sezioni, permettendo di perimetrare le aree allagabili con diversi tempi di ritorno. Il software HEC‐HMS è un sistema di analisi dei fiumi sviluppato dall’Hydrologic Engineering Center. È stato progettato per simulare i processi di precipitazione e di deflussi di bacini idrografici, ed è applicabile ad una vasta gamma di problemi idrologici; il software, infatti, consente la modellazione idrologica di un bacino, mediante la definizione degli elementi concettuali che lo rappresentano e dei processi fisici che avvengono in essi. Infine Kibana è un plugin open source Data Visualization per Elastic Search. Viene utilizzato nell’ambito del progetto di ricerca nell’applicazione di front-end per la visualizzazione dei report e dei dashboard.
Una evidenza particolare è rivestita dall’attività di acquisizione dei dati dai sensori che di fatto sono di due tipologie: stazione meteo completa (a sua volta composta da diversi sensori quali pluviometro, temperature e umidità, irragiamento, ecc.) e idrometri per la misurazione del livello dell’acqua. Tutti questi sensori comunicheranno con la piattaforma IoT e con la piattaforma di Analytics secondo delle specifiche in formato JSON che saranno messe a punto nella fase esecutiva del progetto. Sostanzialmente sarà prodotto un JSON SCEMA per ogni sensore e un JSON SCHEMA per la comunicazione tra KURA e KAPUA. Il disegno che segue riepiloga concettualmente il flusso di acquisizione dei dati.
La frequenza di acquisizione dipenderà dalla tipologia di sensore e dal tipo di analisi che si intenderà implementare.
Prodotti attesi:
1. Report contenente la definizione dettagliata delle componenti del sistema e delle interfacce di correlazione; il report conterrà anche la definizione del flusso di interfaccia tra i sensori e gli edge gateway, tra questi ed il cloud IoT e tra il cloud e la piattaforma di Analytics.
Si individuano le seguenti componenti:
– Sensori di campo – sono i sensori individuati tra quelli descritti nell’attività 1.3 che saranno gestiti da un Edge Gateway su cui risiederà la logica elaborativa periferica con il compito di acquisirei dati e trasferirli opportunamente codificati e formattati alla piattaforma cloud IoT attraverso un sistema di comunicazione basato su protocolli industriali di trasporto e applicativi offerti dalla piattaforma stessa (genericamente HTTP/REST e MQTT sopra IP). La logica elaborativa presente sugli edge gateway sarà costruita in base alle interfacce di comunicazione dei sensori e produrrà un flusso normalizzato di dati verso la piattaforma IoT. Sarà implementata da Eclipse Kura che è un IoT Edge Framework estensibile e open source basato su Java / OSGi. Nella piattaforma è impiegato come software di base per la gestione dei gateway, mettendo in comunicazione i vari sensori impiegati con la piattaforma IoT in cloud. Kura offre accesso API alle interfacce hardware dei gateway IoT (porte seriali, GPS, watchdog, GPIO, I2C, ecc.). È dotato di protocolli di campo pronti all’uso (tra cui Modbus, OPC-UA, S7), un contenitore di applicazioni e una programmazione del flusso di dati visivi basata sul web per acquisire dati dal campo, elaborarli al limite e pubblicarli sulle principali piattaforme cloud IoT attraverso la connettività MQTT.
– IoT – è responsabile dell’autenticazione centralizzata dei dispositivi di campo (edge gateway), dello scambio di messaggi (informazioni lette dal campo) tramite protocolli IoT standard. Tali informazioni vengono “ingerite” dal middleware IoT e vengono redirette secondo regole verso gli altri consumatori, oggi rappresentati dalla piattaforma di analitica ma comunemente anche mobile/web applications. Caratteristiche fondamentali di un IoT middleware open source in grado di soddisfare i requisiti dell’attività sono il supporto dei protocolli MQTT e HTTP/REST per lo scambio di messaggi, la gestione degli account device utilizzati tramite tali protocolli e la possibilità’ di impostare regole di “Routing” sui messaggi, quindi allarmi e trigger, in grado di reagire in tempo reale, anche con elevati throughput (bisogna considerare che l’infrastruttura possa ingerire milioni di messaggi al secondo e che l’IoT middleware debba essere in grado di gestirli). Le componenti open source individuate, in termini di prestazioni, scalabilità’ e completezza del software è Eclipse IoT (Kapua) che supporta diversi protocolli di ingestione dati e ha una moderna interfaccia web, colloquia in modo nativo con il software agent Eclipse Kura presente sugli edge gateway.
– Communication Layer – il compito di trasferire le infoprmazoni dalla piattaforma di IoT al sistema di Analytics è affidato alla componente Apache Kafka. E’ una piattaforma open source di stream processing scritta in Java e Scala e sviluppata dall’Apache Software Foundation. Il progetto mira a creare una piattaforma a bassa latenza ed alta velocità per la gestione di feed dati in tempo reale. Le informazioni acquisite e presenti nella piattaforma IoT vengono inviate alla piattaforma di Analytics attraverso dei Job creati con Vert.X.
– Analytics Real Time e Batch – le componenti del sistema elaborano gli algoritmi di l’intelligenza artificiale per analizzare i dati che provengono dalla piattaforma di IoT e ancor prima dai sensori di campo che saranno installati nell’area interessata dall’intervento. Ci saranno due tipi di elaborazioni, in Real Time e Batch ed entrambi producono report e dashboard per la segnalazione di anomalie, destinate a chi deve successivamente prendere delle decisioni, dell’area soggetta a controllo. La componente dove vengono memorizzati i big data provenienti dai sensori è ElasticSearch; è un server di ricerca basato su Lucene, con capacità Full Text, con supporto ad architetture distribuite. Tutte le funzionalità sono nativamente esposte tramite interfaccia a servizi di tipo RESTful, mentre le informazioni sono gestite come documenti JSON. Elasticsearch nel gennaio 2016 risulta essere il motore di ricerca più utilizzato. Date le sue alte performance nella ricerca di documenti, nell’ambito del progetto, viene usato come database NOSQL. Apache Spark è un framework open source per il calcolo distribuito sviluppato dall’AMPlab della Università della California e successivamente donato alla Apache Software Foundation. Il meccanismo di processing delle informazioni attraverso funzionalità “in-memory” multilivello fornisce prestazioni molto elevate rispetto ad altri software di pari funzionalità. Grazie alle sue alte prestazioni nel calcolo computazionale, Spark è utilizzato per implementazione degli algoritmi di apprendimento automatico con tecniche di Machine Learning e Deep Learning. Nel progetto viene usato in due modalità, prelevando direttamente dati forniti su Code Kafka, attraverso la libreria Apache Spark Streaming, o in modalità batch, prelevando i dati dal Db No SQL Elastic Search, attraverso l’uso delle librerie standard Apache Sparck Batch. Eclipse Vert.x è un framework per la creazione di sistemi “event driven” e “non blocking”. Ciò significa che è possibile creare applicazioni che gestiscono dati in concorrenza usando ed ottimizzando le poche risorse hardware a disposizione. Sposa a pieno il concetto delle applicazioni a Microservizi. Nella piattaforma viene utilizzato per creare job di acquisizione dati dalla piattaforma IoT in Cloud e il loro riversamento nel database Elastic Search. Può essere inoltre utilizzato per inviare direttamente dati agli applicativi (web e mobile) in modalità WebSocket agli stakeholder del sistema. Il software HEC-RAS permette di modellare la propagazione di una corrente lungo un d’acqua utilizzando uno schema unidimensionale sia in condizioni di moto permanente che in condizioni di moto vario. Il programma può essere utilizzato per simulare la propagazione dell’onda di piena lungo il reticolo idraulico e determinare l’altezza che il livello idrico raggiunge nelle varie sezioni, permettendo di perimetrare le aree allagabili con diversi tempi di ritorno. Il software HEC‐HMS è un sistema di analisi dei fiumi sviluppato dall’Hydrologic Engineering Center. È stato progettato per simulare i processi di precipitazione e di deflussi di bacini idrografici, ed è applicabile ad una vasta gamma di problemi idrologici; il software, infatti, consente la modellazione idrologica di un bacino, mediante la definizione degli elementi concettuali che lo rappresentano e dei processi fisici che avvengono in essi. Infine Kibana è un plugin open source Data Visualization per Elastic Search. Viene utilizzato nell’ambito del progetto di ricerca nell’applicazione di front-end per la visualizzazione dei report e dei dashboard.
Una evidenza particolare è rivestita dall’attività di acquisizione dei dati dai sensori che di fatto sono di due tipologie: stazione meteo completa (a sua volta composta da diversi sensori quali pluviometro, temperature e umidità, irragiamento, ecc.) e idrometri per la misurazione del livello dell’acqua. Tutti questi sensori comunicheranno con la piattaforma IoT e con la piattaforma di Analytics secondo delle specifiche in formato JSON che saranno messe a punto nella fase esecutiva del progetto. Sostanzialmente sarà prodotto un JSON SCEMA per ogni sensore e un JSON SCHEMA per la comunicazione tra KURA e KAPUA. Il disegno che segue riepiloga concettualmente il flusso di acquisizione dei dati.
La frequenza di acquisizione dipenderà dalla tipologia di sensore e dal tipo di analisi che si intenderà implementare.
Prodotti attesi:
1. Report contenente la definizione dettagliata delle componenti del sistema e delle interfacce di correlazione; il report conterrà anche la definizione del flusso di interfaccia tra i sensori e gli edge gateway, tra questi ed il cloud IoT e tra il cloud e la piattaforma di Analytics.
AR2.3 – Progettazione algoritmi di elaborazione dati rilevati modello idrologico ed idraulico e intro a reti neurali
I sistemi di monitoraggio ed allertamento rappresentano la principale tipologia di intervento non strutturale per la mitigazione del rischio idraulico. Tali sistemi si fondano su catene modellistiche alla cui base vi è la definizione delle soglie pluviometriche di allertamento. Le soglie pluviometriche sono delle soglie numeriche e definiscono una quantità di precipitazione lorda P, ossia non depurata, distribuita nella durata di tempo t, che provoca deflussi superficiali, cioè portate, tali da generare il superamento di alcuni vincoli posti sul livello idrometrico del corso d’acqua in oggetto. Nello specifico, normalmente si considera come vincolo da non superare almeno 1 m di franco fra la superficie del corso d’acqua e l’arginatura a quota inferiore del corso d’acqua stesso, sia esso naturale che eventualmente artificiale, ragionando quindi a vantaggio di sicurezza.
La catena modellistica che il progetto propone di realizzare prevede, dopo la prima fase di acquisizione dei dati di pioggia e portata volumetrica , una simulazione sia idrologica che idraulica. Per quanto riguarda la modellazione idraulica si farà uso del software freeware HEC-RAS River Analysis System, sviluppato dall’US Army Corps of Engineers. Tale software consente di effettuare simulazioni idrauliche monodimensionali o, come potrà essere possibile nel caso in analisi, bidimensionali, sia in regime transitorio che stazionario, utilizzando diverse tecniche di approssimazione e risoluzione numerica. Il software, largamente adoperato nell’ambito dell’ingegneria idraulica, è estremamente versatile e consente di ottenere risultati sufficientemente accurati per gli scopi del progetto. Esso sarà tra l’altro utilizzato, in combinazione con misure periodiche di portata (che avverranno tramite uno strumento portatile), per la definizione delle scale di deflusso in corrispondenza degli idrometri.
La modellazione idrologica, al fine di quantificare il deflusso superficiale generato dalla pioggia lorda registrata dalle stazioni pluviometriche o generata con tecniche di generazione Monte Carlo, è affidata al software freeware HEC-HMS Hydrologic Modeling System, sviluppato sempre dall’US Army Corps of Engineers. Questo software, così come HEC-RAS, è estremamente personalizzabile e consente quindi l’applicazione di diversi possibili modelli per rappresentare le varie componenti, come per esempio l’infiltrazione, l’evapotraspirazione o la trasformazione matematica fra afflussi netti e deflussi.
Un aspetto caratterizzante del WP è dato dal fatto che la catena di modellazione sarà costantemente monitorata e validata, in particolare per quanto riguarda la trasformazione afflussi-deflussi, utilizzando i dati disponibili dalle tre sezioni idrometriche, permettendo quindi di valutare in tempo reale, con la necessaria accuratezza, le condizioni di umidità del suolo medie dei rispettivi sottobacini. La modellazione idraulica sarà invece caratterizzata da un’attenta stima dei parametri di scabrezza definita tramite appositi sopralluoghi e da misure a terra a completamento del rilievo Lidar (es., pile dei ponti), e sarà validata sia con eventuali valori di portata e/o di livello idrometrico forniti dalla stazione di misura “Ponte San Francesco” gestita dal Centro Funzionale Multirischi ARPACAL, sia con ulteriori misure di portata spot per diverse sezioni a valle degli idrometri.
La catena di modellazione calibrata e validata sarà utilizzata in modalità off-line per la definizione delle soglie pluviometriche di allertamento. In particolare, applicando la tecnica Monte Carlo sarà generata una significativa quantità ( 103) di ietogrammi considerando: i) tipologie di evoluzione temporale del fenomeno associate sia a fenomeni meteorologici convettivi che a sistemi frontali; ii) durate di precipitazione variabili da 1 a 24 ore; iii) intensità di pioggia variabili (ma comunque di entità significativa, definita in base ad un apposito studio idrologico del bacino dell’Esaro); iv) condizioni di umidità iniziale del suolo variabili da molto secche a molto umide.
Tra tutte le serie di piogge sintetiche generate saranno selezionate quelle capaci di generare una portata pari almeno al livello di guardia. Le serie sintetiche selezionate saranno confrontate con l’andamento delle piogge misurate e su cui verranno applicativi algoritmi di predizione basata sulle reti neurali, le quali permetteranno di determinare le probabilità relative ai livelli di criticità dei flussi d’acqua.
Prodotti attesi:
1. Report relativo all’implementazione, la validazione e l’applicazione operativa della catena modellistica idrologico-idraulica.
2. Database delle serie sintetiche di pioggia selezionate per l’analisi tramite reti neurali.
La catena modellistica che il progetto propone di realizzare prevede, dopo la prima fase di acquisizione dei dati di pioggia e portata volumetrica , una simulazione sia idrologica che idraulica. Per quanto riguarda la modellazione idraulica si farà uso del software freeware HEC-RAS River Analysis System, sviluppato dall’US Army Corps of Engineers. Tale software consente di effettuare simulazioni idrauliche monodimensionali o, come potrà essere possibile nel caso in analisi, bidimensionali, sia in regime transitorio che stazionario, utilizzando diverse tecniche di approssimazione e risoluzione numerica. Il software, largamente adoperato nell’ambito dell’ingegneria idraulica, è estremamente versatile e consente di ottenere risultati sufficientemente accurati per gli scopi del progetto. Esso sarà tra l’altro utilizzato, in combinazione con misure periodiche di portata (che avverranno tramite uno strumento portatile), per la definizione delle scale di deflusso in corrispondenza degli idrometri.
La modellazione idrologica, al fine di quantificare il deflusso superficiale generato dalla pioggia lorda registrata dalle stazioni pluviometriche o generata con tecniche di generazione Monte Carlo, è affidata al software freeware HEC-HMS Hydrologic Modeling System, sviluppato sempre dall’US Army Corps of Engineers. Questo software, così come HEC-RAS, è estremamente personalizzabile e consente quindi l’applicazione di diversi possibili modelli per rappresentare le varie componenti, come per esempio l’infiltrazione, l’evapotraspirazione o la trasformazione matematica fra afflussi netti e deflussi.
Un aspetto caratterizzante del WP è dato dal fatto che la catena di modellazione sarà costantemente monitorata e validata, in particolare per quanto riguarda la trasformazione afflussi-deflussi, utilizzando i dati disponibili dalle tre sezioni idrometriche, permettendo quindi di valutare in tempo reale, con la necessaria accuratezza, le condizioni di umidità del suolo medie dei rispettivi sottobacini. La modellazione idraulica sarà invece caratterizzata da un’attenta stima dei parametri di scabrezza definita tramite appositi sopralluoghi e da misure a terra a completamento del rilievo Lidar (es., pile dei ponti), e sarà validata sia con eventuali valori di portata e/o di livello idrometrico forniti dalla stazione di misura “Ponte San Francesco” gestita dal Centro Funzionale Multirischi ARPACAL, sia con ulteriori misure di portata spot per diverse sezioni a valle degli idrometri.
La catena di modellazione calibrata e validata sarà utilizzata in modalità off-line per la definizione delle soglie pluviometriche di allertamento. In particolare, applicando la tecnica Monte Carlo sarà generata una significativa quantità ( 103) di ietogrammi considerando: i) tipologie di evoluzione temporale del fenomeno associate sia a fenomeni meteorologici convettivi che a sistemi frontali; ii) durate di precipitazione variabili da 1 a 24 ore; iii) intensità di pioggia variabili (ma comunque di entità significativa, definita in base ad un apposito studio idrologico del bacino dell’Esaro); iv) condizioni di umidità iniziale del suolo variabili da molto secche a molto umide.
Tra tutte le serie di piogge sintetiche generate saranno selezionate quelle capaci di generare una portata pari almeno al livello di guardia. Le serie sintetiche selezionate saranno confrontate con l’andamento delle piogge misurate e su cui verranno applicativi algoritmi di predizione basata sulle reti neurali, le quali permetteranno di determinare le probabilità relative ai livelli di criticità dei flussi d’acqua.
Prodotti attesi:
1. Report relativo all’implementazione, la validazione e l’applicazione operativa della catena modellistica idrologico-idraulica.
2. Database delle serie sintetiche di pioggia selezionate per l’analisi tramite reti neurali.
AR2.4 - Realizzazione piattaforma di IoT per la gestione delle stazioni di rilevazione e implementazione dei modelli di analisi dei dati rilevati
Per la realizzazione della componente centrale di connettività verso il campo (gateway e sensori) e verso la componente di analitica, è necessario integrare e personalizzare l’importante componente di infrastruttura rappresentata dal middleware IoT. Il middleware IoT è responsabile dell’autenticazione centralizzata dei dispositivi di campo, dello scambio di messaggi (informazioni lette dal campo) tramite protocolli IoT standard. Tali informazioni vengono “ingerite” dal middleware IoT e vengono redirette secondo regole specifiche verso gli altri consumatori, oggi rappresentati dalla piattaforma di analitica ma comunemente anche mobile/web applications. Caratteristiche fondamentali di un IoT middleware open source in grado di soddisfare i requisiti dell’attività sono il supporto dei protocolli MQTT e HTTP/REST per lo scambio di messaggi, la gestione degli account device utilizzati tramite tali protocolli e la possibilità’ di impostare regole di “Routing” sui messaggi, quindi allarmi e trigger, in grado di reagire in tempo reale, anche con elevati throughput (bisogna considerare che a tendere l’infrastruttura possa ingerire milioni di messaggi al secondo e che l’IoT middleware debba essere in grado di gestirli). La soluzione che sarà adottata offre tutte le caratteristiche necessarie a garantire l’affidabilità e la robustezza del sistema di IoT in termini prestazioni, scalabilità’ e completezza del software è Eclipse IoT Kapua insieme alla sua componente di campo Eclipse Kura. Parallelamente alla realizzazione della componente di IoT sarà realizzata la componente di analytics integrando le componenti open source identificate e descritte nell’attività AR2.2. Successivamente sarà realizzato il modulo di integrazione tra la piattaforma IoT ed il modulo di Analytics, basato sulla componente open source Kafka. Passo fondamentale nella realizzazione dell’infrastruttura software sarà la realizzazione dei modelli di analisi progettati nell’AR2.3 e del loro test con un training set di dati allo scopo predisposti. Infine in questa attività saranno inoltre definite le caratteristiche dei server che ospiteranno l’intera infrastruttura software e si procederà all’acquisizione delle risorse hardware necessarie e alla successiva installazione e test dell’intero sistema.
Prodotti attesi:
1. Applicazione Web e Mobile per il monitoring in real time dei corsi d’acqua
2. Report di descrizione dettagliata delle integrazioni software realizzate
3. Report sulla configurazione completa del sistema software e l’installazione del software di base e di ambiente sui server
Prodotti attesi:
1. Applicazione Web e Mobile per il monitoring in real time dei corsi d’acqua
2. Report di descrizione dettagliata delle integrazioni software realizzate
3. Report sulla configurazione completa del sistema software e l’installazione del software di base e di ambiente sui server
WP3 – Sperimentazione e Disseminazione della soluzione
AR3.1 – Acquisizione e installazione stazioni di rilevazione e sensori
Gli strumenti di misura che saranno installati per monitorare le principali grandezze di interesse idraulico ed idrologico sono di due tipi: le stazioni meteorologiche e le stazioni idrometriche. Le prime, che saranno posizionate in corrispondenza di zone significative (in prossimità dei crinali o dei baricentri geometrici dei sottobacini individuati), servono per la misura delle variabili precipitazione e intensità di pioggia, temperatura dell’aria, umidità relativa e pressione atmosferica, direzione e velocità del vento, radiazione solare netta. In particolare, queste stazioni forniscono delle altezze di pioggia ragguagliate alla superficie in pianta occupata dallo strumento stesso. Tali altezze sono normalmente espresse in millimetri, con una precisione di 0.2 mm. La centralina di acquisizione ed elaborazione convertirà i dati da analogici a digitali, permettendone la successiva trasmissione da parte del sistema di comunicazione GSM. Il tutto sarà autoalimentato dal pannello solare collegato al sistema di accumulo rappresentato dalla batteria.
Le stazioni idrometriche, invece, forniranno in continuo indicazioni sul livello idrometrico nelle sezioni in cui sono installate. Ogni stazione idrometrica sarà composta da un misuratore di livello radar, che sfrutta quindi il segnale retro-diffuso per ricavare l’altezza dello specchio liquido espressa in metri e con una precisione dell’ordine del mm. Il dato sarà processato dalla centralina e comunicato tramite il sistema di comunicazione GSM. Anche in questo caso la stazione sarà autoalimentata tramite un sistema fotovoltaico accoppiato con accumulo. Le stazioni idrometriche installate saranno tre, in modo tale da avere tre distinti corsi d’acqua “sentinella”.
Le stazioni di misura, oltre ad essere basate sul paradigma open-hardware, saranno fornite in modalità “kit-fai-da-te”, che agevolerà il montaggio.
Alle stazioni di misura fisse saranno affiancate misure periodiche di portata tramite un misuratore di portata con sonda aerea velocity Doppler acustico, finalizzate alla realizzazione delle scale di deflusso in corrispondenza degli idrometri e di eventuali misure di portata per sezioni a valle (lungo l’asta finale dell’Esaro).
Prodotti attesi:
Report di installazione delle stazioni di misura
Le stazioni idrometriche, invece, forniranno in continuo indicazioni sul livello idrometrico nelle sezioni in cui sono installate. Ogni stazione idrometrica sarà composta da un misuratore di livello radar, che sfrutta quindi il segnale retro-diffuso per ricavare l’altezza dello specchio liquido espressa in metri e con una precisione dell’ordine del mm. Il dato sarà processato dalla centralina e comunicato tramite il sistema di comunicazione GSM. Anche in questo caso la stazione sarà autoalimentata tramite un sistema fotovoltaico accoppiato con accumulo. Le stazioni idrometriche installate saranno tre, in modo tale da avere tre distinti corsi d’acqua “sentinella”.
Le stazioni di misura, oltre ad essere basate sul paradigma open-hardware, saranno fornite in modalità “kit-fai-da-te”, che agevolerà il montaggio.
Alle stazioni di misura fisse saranno affiancate misure periodiche di portata tramite un misuratore di portata con sonda aerea velocity Doppler acustico, finalizzate alla realizzazione delle scale di deflusso in corrispondenza degli idrometri e di eventuali misure di portata per sezioni a valle (lungo l’asta finale dell’Esaro).
Prodotti attesi:
Report di installazione delle stazioni di misura
AR3.2 – Acquisizione dati in tempo reale dalle stazioni di rilevazione
I sensori dialogheranno con i gateway attraverso la tecnologia WiFi o attraverso la tecnologia LORA. Il gateway invece, sarà connesso alla piattaforma IoT in Cloud attraverso connettività GSM/3G+. Lo scambio delle informazioni JSON avverrà mediante il protocollo di trasmissione MQTT e il formato dei dati verrà descritto attraverso un JSON-Schema che terrà conto di tutte le variabili fornite dai sensori di campo.Il rilevamento delle informazioni avverrà con intervalli temporali configurabili con finestre minime di 5 secondi. Attraverso la piattaforma sarà possibile impostare tutta una serie di parametri verranno schedulati i rilevamenti di campo. Questa serie di parametri saranno impostabili direttamente sul Gateway su cui verrà installato il Sistema Operativo per IoT Eclipse Kura; lo stesso sistema è responsabile dell’invio dei dati rilevati dai sensori alla piattaforma IoT in Cloud Eclipse Kapua e più precisamente su specifici TOPIC del broker MQTT in dotazione. Il broker MQTT della piattaforma IoT verrà velocemente scaricato (evitando il sovraccarico dati del sistema) attraverso alcuni job di trasformazione dati, che avranno anche il compito di trasferire le informazioni sulle code della piattaforma Apache Kafka che saranno la sorgente dati per la piattaforma di Analytics. A questo punto, le informazioni verranno normalizzate e storicizzate sul database documentale Elastic Search e saranno disponibili per creare report e analisi storiche; per le analisi in real time i dati potranno essere acquisiti direttamente da Apache Kafka dall’applicazione Web e dall’App Mobile.
AR3.3 – Elaborazione algoritmi di real time analytics e produzione reportistica
La piattaforma sarà dotata di algoritmi di AI basati su reti neurali. Le reti neurali artificiali (ANN) costituiscono una classe di algoritmi di apprendimento automatico, cioè a partire da coppie di dati input-output note, viene estratta una regola generale che permette di associare a qualsiasi input l’output corretto.
Una rete neurale artificiale è composta a neuroni, organizzati a strati e interconnessi tra loro. Le reti, oltre all’essenziale strato di ingresso, composto dalle variabili di input, devono possedere uno o più strati di elaborazione: in generale, vi sono N strati, di cui i primi N – 1 nascosti (hidden layer), contenenti un numero arbitrario di neuroni ciascuno, mentre l’ultimo, visibile, è lo strato di output e contiene un numero q≥1 di neuroni pari alle variabili di uscita.
Ogni neurone è collegato ai neuroni dello strato successivo da connessioni pesate, dove una connessione non è altro che un valore numerico, detto peso, che viene moltiplicato per il valore del neurone. Alla somma dei prodotti tra pesi e neuroni, viene aggiunta una costante, detta bias. Al valore risultante da questa operazione, verrà applicata una funzione, detta funzione di attivazione, e l’output prodotto costituirà il neurone dello strato successivo. Dunque posto xi+1,j il j-esimo neurone dello strato (i+1)-esimo, allora xi+1,j = f(bj+Σwkxi,k),
dove xi,k è il k-esimo neurone dello strato i-esimo, wk è il peso che connette xi,k con xi+1,j, bj è il valore bias associato al neurone xi+1,j e f è la funzione di attivazione. La scelta della funzione di attivazione dipende dal tipo di problema e dalla complessità della rete neurale, esempi di funzioni di attivazione molto utilizzate sono la funzione lineare, la funzioni sigmoide e la funzione relu.
Continuando il procedimento descritto sopra fino all’ultimo strato della rete, in fase di training, il valore ricavato verrà confrontato con l’output noto, e a seconda dell’errore commesso verrà rieseguito tutto il procedimento, dopo aver modificato il valore assegnato ai pesi. Al termine della procedura di addestramento, i pesi assegnati saranno tali per cui la rete sarà in grado di calcolare un output corretto anche per valori di input sconosciuti.
L’utilizzo di reti neurali risulta particolarmente vantaggioso rispetto all’utilizzo di metodi analitici, in tutti quei campi in cui si vogliono prevedere fenomeni a partire da dati empirici, soggetti dunque ad errori imprecisioni o incompletezze.
Molta importanza verrà data alla parte di reportistica, dove insieme agli stakeholders saranno decise sia le dashboard di supporto, sia gli indicatori di riferimento. Il sistema nasce comunque per essere dinamico, per cui sarà dinamica anche la gestione dei report che sarà affinata assieme agli stackholders.
Prodotti attesi:
1. Report finale relativo alle statistiche delle misure acquisite nel corso del progetto (incluse le misure eseguite con il misuratore di portata portatile)
2. Report contenente i risultati di sintesi delle elaborazioni effettuate tramite gli algoritmi di real time analytics
Una rete neurale artificiale è composta a neuroni, organizzati a strati e interconnessi tra loro. Le reti, oltre all’essenziale strato di ingresso, composto dalle variabili di input, devono possedere uno o più strati di elaborazione: in generale, vi sono N strati, di cui i primi N – 1 nascosti (hidden layer), contenenti un numero arbitrario di neuroni ciascuno, mentre l’ultimo, visibile, è lo strato di output e contiene un numero q≥1 di neuroni pari alle variabili di uscita.
Ogni neurone è collegato ai neuroni dello strato successivo da connessioni pesate, dove una connessione non è altro che un valore numerico, detto peso, che viene moltiplicato per il valore del neurone. Alla somma dei prodotti tra pesi e neuroni, viene aggiunta una costante, detta bias. Al valore risultante da questa operazione, verrà applicata una funzione, detta funzione di attivazione, e l’output prodotto costituirà il neurone dello strato successivo. Dunque posto xi+1,j il j-esimo neurone dello strato (i+1)-esimo, allora xi+1,j = f(bj+Σwkxi,k),
dove xi,k è il k-esimo neurone dello strato i-esimo, wk è il peso che connette xi,k con xi+1,j, bj è il valore bias associato al neurone xi+1,j e f è la funzione di attivazione. La scelta della funzione di attivazione dipende dal tipo di problema e dalla complessità della rete neurale, esempi di funzioni di attivazione molto utilizzate sono la funzione lineare, la funzioni sigmoide e la funzione relu.
Continuando il procedimento descritto sopra fino all’ultimo strato della rete, in fase di training, il valore ricavato verrà confrontato con l’output noto, e a seconda dell’errore commesso verrà rieseguito tutto il procedimento, dopo aver modificato il valore assegnato ai pesi. Al termine della procedura di addestramento, i pesi assegnati saranno tali per cui la rete sarà in grado di calcolare un output corretto anche per valori di input sconosciuti.
L’utilizzo di reti neurali risulta particolarmente vantaggioso rispetto all’utilizzo di metodi analitici, in tutti quei campi in cui si vogliono prevedere fenomeni a partire da dati empirici, soggetti dunque ad errori imprecisioni o incompletezze.
Molta importanza verrà data alla parte di reportistica, dove insieme agli stakeholders saranno decise sia le dashboard di supporto, sia gli indicatori di riferimento. Il sistema nasce comunque per essere dinamico, per cui sarà dinamica anche la gestione dei report che sarà affinata assieme agli stackholders.
Prodotti attesi:
1. Report finale relativo alle statistiche delle misure acquisite nel corso del progetto (incluse le misure eseguite con il misuratore di portata portatile)
2. Report contenente i risultati di sintesi delle elaborazioni effettuate tramite gli algoritmi di real time analytics
AR3.4 – Organizzazione eventi rivolti agli stakeholders per diffondere e condividere i risultati della sperimentazione
Il paradigma Living Labs si caratterizza in modo rilevante per il coinvolgimento dell’utenza finale nel corso delle diverse fasi del progetto. Infatti, tra gli obiettivi principali dei progetti che puntano a soddisfare i fabbisogni espressi dagli enti pubblici, rientrano le ricadute sociali delle soluzioni realizzate. La presente proposta, nello specifico, punta a fornire alla collettività una piattaforma di monitoraggio dei corsi d’acqua che possa affiancarsi, con nuovi contenuti tecnologici, agli strumenti già in dotazione agli enti preposti alla sicurezza ambientale della popolazione.
D’altro canto, è necessario che, per alzare il livello di partecipazione civica della cittadinanza, si inneschi un dialogo costante con i cosiddetti stakeholder, cioè tutti i cittadini, le imprese, le organizzazioni e gli enti pubblici che hanno interesse verso la specifica problematica. In quest’ottica, si individuano alcune fasi progettuali all’interno delle quali deve trovare posto la partecipazione della cittadinanza attiva e interessata all’iniziativa. In particolare, tali fasi sono:
– Analisi del contesto su cui avrà impatto l’iniziativa
– Progettazione della soluzione prototipale
– Realizzazione della soluzione prototipale
– Sperimentazione e disseminazione della soluzione.
Pertanto, all’avvio del progetto, si prevede una divulgazione pubblica dell’iniziativa e dei suoi obiettivi, attraverso i vari media (Tv, stampa tradizionale e su web, conferenze locali), evidenziando gli obiettivi sociali e determinando un clima favorevole alla partecipazione. La comunicazione dovrà proseguire nella fase di progettazione della soluzione, accompagnata da eventi che consentono l’interazione diretta tra gli stakeholder e l’ente proponente (il c.d. rappresentante dell’utenza finale), con la partecipazione dei partner di progetto.
Anche la fase di realizzazione, per stati di avanzamento, dovrà prevedere dei momenti di interazione con la cittadinanza, ad es., attraverso la comunicazione dei risultati intermedi raggiunti, possibilmente su un portale di progetto che ne traccia il progresso.
La fase di sperimentazione deve rendere pubblici i risultati via via ottenuti, tramite l’esposizione periodica dei dati acquisiti, elaborati e opportunamente aggregati per essere resi fruibili ad un’utenza non specialistica.
Infine, la disseminazione dei risultati avverrà, oltre che tramite una comunicazione unilaterale, anche mediante convegni e altri momenti di partecipazione collettiva, tra cui gruppi sui social media, da cui l’ente può trarre interessanti spunti di riflessione nella fase cruciale in cui l’ente dovrà decidere come utilizzare i risultati di progetto, passando da una fase prototipale ad una industriale.
D’altro canto, è necessario che, per alzare il livello di partecipazione civica della cittadinanza, si inneschi un dialogo costante con i cosiddetti stakeholder, cioè tutti i cittadini, le imprese, le organizzazioni e gli enti pubblici che hanno interesse verso la specifica problematica. In quest’ottica, si individuano alcune fasi progettuali all’interno delle quali deve trovare posto la partecipazione della cittadinanza attiva e interessata all’iniziativa. In particolare, tali fasi sono:
– Analisi del contesto su cui avrà impatto l’iniziativa
– Progettazione della soluzione prototipale
– Realizzazione della soluzione prototipale
– Sperimentazione e disseminazione della soluzione.
Pertanto, all’avvio del progetto, si prevede una divulgazione pubblica dell’iniziativa e dei suoi obiettivi, attraverso i vari media (Tv, stampa tradizionale e su web, conferenze locali), evidenziando gli obiettivi sociali e determinando un clima favorevole alla partecipazione. La comunicazione dovrà proseguire nella fase di progettazione della soluzione, accompagnata da eventi che consentono l’interazione diretta tra gli stakeholder e l’ente proponente (il c.d. rappresentante dell’utenza finale), con la partecipazione dei partner di progetto.
Anche la fase di realizzazione, per stati di avanzamento, dovrà prevedere dei momenti di interazione con la cittadinanza, ad es., attraverso la comunicazione dei risultati intermedi raggiunti, possibilmente su un portale di progetto che ne traccia il progresso.
La fase di sperimentazione deve rendere pubblici i risultati via via ottenuti, tramite l’esposizione periodica dei dati acquisiti, elaborati e opportunamente aggregati per essere resi fruibili ad un’utenza non specialistica.
Infine, la disseminazione dei risultati avverrà, oltre che tramite una comunicazione unilaterale, anche mediante convegni e altri momenti di partecipazione collettiva, tra cui gruppi sui social media, da cui l’ente può trarre interessanti spunti di riflessione nella fase cruciale in cui l’ente dovrà decidere come utilizzare i risultati di progetto, passando da una fase prototipale ad una industriale.
AR3.5 – Analisi per la valorizzazione economica dei risultati ottenuti dalla sperimentazione
I progetti finanziati dai Living Labs devono fornire soluzioni concrete e avanzate ai fabbisogni espressi dagli enti proponenti, ma, naturalmente, sia per problemi di possibile alterazione delle dinamiche di mercato che per problemi di budget, non possono essere considerate dei prodotti industriali pronti per il mercato. Trattandosi di progetti di sviluppo sperimentale, i risultati non possono che essere di natura prototipale. E’ evidente, ad esempio, che la soluzione auspicata nella presente proposta, per essere considerata una piattaforma in produzione, avrebbe bisogno di almeno due ulteriori caratteristiche:
– Un periodo di sperimentazione più lungo, per acquisire una maggiore quantità di dati da fornire al sistema di real time analytics e rendere, pertanto, la piattaforma più intelligente
– Un budget in strumentazione e attrezzature molto più alto, per poter estendere l’area geografica oggetto della sperimentazione.
Dalle precedenti considerazioni si evince che, nel percorso di industrializzazione della soluzione proposta, è necessario prevedere un time to market, con un ben definito piano che al termine del percorso, consegni un prodotto industriale che garantisca ricadute produttive sia alle imprese partecipanti che alla collettività che ne ha sollecitato la realizzazione.
Pertanto è prevista una specifica attività afferente al WP3 che ha l’obiettivo di effettuare un’analisi per la valorizzazione economica dei risultati della sperimentazione. Tale analisi, la cui articolazione dipende anche dalla quantità e qualità dei risultati raggiunti, deve tenere conto di una serie di variabili, tra le quali non possono mancare:
– Il mercato di riferimento della soluzione
– Il livello tecnologico del prototipo
– Le caratteristiche del prodotto che si intende realizzare
– L’entità dell’investimento che si intende effettuare.
L’output dell’attività sarà un business plan da avviare in continuità con la fase di sperimentazione.
– Un periodo di sperimentazione più lungo, per acquisire una maggiore quantità di dati da fornire al sistema di real time analytics e rendere, pertanto, la piattaforma più intelligente
– Un budget in strumentazione e attrezzature molto più alto, per poter estendere l’area geografica oggetto della sperimentazione.
Dalle precedenti considerazioni si evince che, nel percorso di industrializzazione della soluzione proposta, è necessario prevedere un time to market, con un ben definito piano che al termine del percorso, consegni un prodotto industriale che garantisca ricadute produttive sia alle imprese partecipanti che alla collettività che ne ha sollecitato la realizzazione.
Pertanto è prevista una specifica attività afferente al WP3 che ha l’obiettivo di effettuare un’analisi per la valorizzazione economica dei risultati della sperimentazione. Tale analisi, la cui articolazione dipende anche dalla quantità e qualità dei risultati raggiunti, deve tenere conto di una serie di variabili, tra le quali non possono mancare:
– Il mercato di riferimento della soluzione
– Il livello tecnologico del prototipo
– Le caratteristiche del prodotto che si intende realizzare
– L’entità dell’investimento che si intende effettuare.
L’output dell’attività sarà un business plan da avviare in continuità con la fase di sperimentazione.
Output di progetto
Il progetto intende costruire una piattaforma per la gestione operativa di un sistema di monitoraggio e preannuncio caratterizzato da sensoristica low-cost e modelli di calcolo speditivi in grado di fornire indicazioni utili e tempestive a supporto dei decisori per il rischio alluvioni. Obiettivo di questa soluzione è quello di caratterizzarsi come importante (anche se non unica) sorgente informativa a supporto dei decisori istituzionali per la predizione di eventi di altissima criticità che nel tempo hanno portato a disastrose conseguenze sul territorio Crotonese.
L’output progettuale consisterà dunque in una prototipazione software per la gestione dei dati, dei modelli idrologico/idraulici e degli algoritmi di real time analytics, finalizzata alla valutazione del raggiungimento di una soglia pluviometrica di allertamento e quindi dell’eventuale rischio alluvioni.