Use Cases Storytelling

AirHeritage

ENEA Sensors Application Lab

Use Case 1 (Pedibus)

• Studenti aderenti al pedibus verranno condotti dal pedibus leader che, dotato di un MONICA-

AH, effettuerà il monitoraggio durante il tragitto casa scuola.

• Il PL dovrà indicare al termine della sessione, il numero totale di bambini partecipanti per

permettere un ranking della scuola in termini di Km percorsi x Numero di Partecipanti a

livello di singola sessione.

• L' interfaccia dovrà permettere la lettura istantanea delle concentrazioni/ di un indice di

esposizione personale così come l' accesso ad una mappa indicante il percorso e utilizzante

un codice di colore per valutare l' esposizione personale.

• I dati relativi alle singole sessioni così come quelle effettuate dal singolo PL (anche in scuole

diverse) e quelle effettuate dalle singole scuole dovranno essere conservati e resi reperibili

ai diversi attori coinvolti (ENEA, Scuole, Associazioni).

• Una pagina ad hoc dovrà prevedere la possibilità di valutare il ranking scolastico in tempo

reale (giornoxgiorno)

Use Case 2 (Associazioni)

• Cittadini aderenti o mobilitati dalle associazioni provvederanno a monitorare in mobilità lo

stato della qualità dell' aria.

• Le associazioni parteciperanno ad un contest il cui ranking è stabilito in numero di km

monitorati durante le sessioni effettuate da tutti gli utenti mobilitati da qualle specifica

associazione

• L' interfaccia dovrà permettere la lettura istantanea delle concentrazioni/ di un indice di

esposizione personale così come l' accesso ad una mappa indicante il percorso e utilizzante

un codice di colore per valutare l' esposizione personale.

• I dati relativi alle singole sessioni così come quelle effettuate dal singolo cittadino e quelle

effettuate dalle singole associazini dovranno essere conservati e resi reperibili ai diversi

attori coinvolti (ENEA, Cittadini, Associazioni).

• Una pagina ad hoc dovrà prevedere la possibilità di valutare il ranking scolastico in tempo

reale (giornoxgiorno)

Use Case 3 (Polizia Locale)

• Singoli Agenti o autovetture della polizia locale (mezzi pubblici) potranno effettuare sessioni

di monitoraggio in mobilità dello stato della qualità dell' aria.

• L' interfaccia dovrà permettere di assicurarsi che MONICA sia in funzionamento e che la

connettività sia garantita

• Desiderata: l' interfaccia potrebbe permettere la lettura istantanea delle concentrazioni/ di un

indice di esposizione personale così come l' accesso ad una mappa indicante il percorso e

utilizzante un codice di colore per valutare l' esposizione personale. (controllare eventuali

problematiche)

• I dati relativi alle singole sessioni così come quelle effettuate dal singolo agente dovranno

essere conservati e resi reperibili ai diversi attori coinvolti (ENEA, Cittadini, Agenti, CdP).

Use Case 4 (Cittadini)

• La cittadinanaza generale dovrà avere accesso su cartelloni pubblici e su sito web (+ twitter

+ fb) alle informazioni relative alla qualità dell' aria e all' andamento del progetto includendo

– Classifica provvisoria e dati sui contest (numero di km monitorati, numero di sessioni, numero di

partecipanti, etc)

– Mappa con rilevazioni puntuali più recenti (live feed + diciamo effettuate nell' ultima ora o parte della

giornata, giornata, settimana).

– Live feed sessioni (un utente anonimo ha effettuato una sessione, in questa zona, con indice medio di

esposizione pari a... o mappa deella traccia di misura)

– Mappa con livelli della qualità dell' aria sulle strade o su tutto il territorio realizzata fondendo insieme

dati rilevati e dati da modello della qualità dell' aria (basato su traffico, orografia,condimeteo)

Use Case 5 (Sistemi esterni - Modelli- DSS)

– Il sistema di backend dovrà essere aperto alla richiesta dati provenienti dal DSS Terraria

– Il sistema di backenddovrà integrare dati provenienti da centraline fisse low cost e regolatorie

(ARPAC) anche mobili, presenti nel territorio

– Il sistema di backend dovrà integrare dati provenienti da sensoristica per il monitoraggio del traffico

– Il sistema di backend dovrà essere aperto alla richiesta dati (e/o integrarsi in tempo reale, vedi Use

case 4) con il sistema di generazione model based della mappa della qualità dell' aria

– Il sistema di frontend web dovrà supportare la visualizzazione del dato sensoristico (incluso sensori

ARPAC, traffico, meteo) in viste specifiche per cittadini generici, partecipanti, modellisti,

amministratori.

– Il sistema di backend (globale incluso eventuali data sink generati ad hoc) dovrà supportare

operazioni di calibrazione in campo e in laboratorio permettendo il calcolo dei parametri di riferimento

– Desiderata: Il sistema dovrà supportare operazioni di network cross calibration basate su altri nodi o

su valori generati dal modello