Notte dei Ricercatori · Web viewNotte dei Ricercatori. Notte dei Ricercatori. Notte dei...

Notte dei Ricercatori

CASO DI STUDIOAntonio Bruno & Eleonora MendolaUniversità degli studi dell’aquila | ingegneria del software

1. IntroduzioneLa Notte dei Ricercatori (NdR) è una mostra scientifica organizzata dalla comunità dei ricercatori dell’Università degli studi dell’Aquila. Essa dura un’intera serata ed è divisa in vari eventi che si svolgono in diversi luoghi sparsi per tutta la città dell’Aquila. Gli eventi possono essere di vario genere (dimostrazioni, workshop, conferenze, ecc.) ed avere differenti tematiche. Ogni evento viene svolto in un luogo specifico, come ad esempio una piazza o una strada principale o anche un’aula con un numero di posti limitato. Sparsi per la città ci sono, inoltre, aree adibite a parcheggi vicino ai luoghi dove vengono svolti gli eventi. Questo progetto ha come scopo quello di fornire nuovi servizi per risolvere alcune problematiche riscontrate nel tempo e per migliorare l’esperienza del visitatore.

1.1. Informazioni raccolteDall’esperienza degli anni passati, si sono raccolte alcune informazioni utili e si sono evidenziate differenti problematiche:

- Ogni anno i visitatori della NdR sono circa 25.000;- I picchi di partecipazione sono nelle ore tarde della giornata;- Il meteo influisce sulle preferenze dei visitatori su cosa vedere e dove trattenersi maggiormente;- Viene generato traffico per colpa dalla ricerca di posti auto disponibili;- Non è possibile per i visitatori vedere anticipatamente se ci sono posti disponibili ad un evento a

numero chiuso;

1.2. Servizi richiestiPer risolvere le precedenti problematiche, e migliorare l’esperienza del visitatore, si è scelto di mettere a disposizione i seguenti servizi:

- Permettere ai visitatori di verificare la disponibilità dei posti per un dato evento e, in caso negativo, suggerire altri eventi con posti ancora disponibili;

- Dare la possibilità ai visitatori di prenotare un posto in un dato evento;- Permettere di verificare la disponibilità dei posti auto nelle aree designate e, in caso negativo,

suggerire posti auto disponibili in un altro parcheggio adiacente al luogo di interesse; - Dare la possibilità agli organizzatori di avere una panoramica della situazione dell’intero sistema;- Fornire informazioni sui servizi di trasporto;- Fornire informazioni sul meteo;

1.3. Attori del sistemaGli utilizzatori del sistema saranno:

- I visitatori;- Gli organizzatori;

1.4. Sensori a disposizione- Parking mats: tappetini che segnalano il passaggio di una macchina;- QR code scanner: lettori di codici QR;

Antonio Bruno & Eleonora Mendola 1


2. Requisiti architetturalmente significativiAnalizziamo in questo capitolo quali sono i requisiti più importanti da soddisfare che possono influenzare la scelta dell’architettura:

o Informazioni in tempo reale: se l’informazione fosse troppo vecchia non sarebbe più utile per il visitatore. L’informazione sui parcheggi liberi, per esempio, ha come scopo quello di ottimizzare la ricerca del parcheggio più vicino al luogo interessato per diminuire il traffico e, in caso di informazioni aggiornate i tempi troppo elevanti, il sistema non porterebbe al risultato desiderato perché non eviterebbe che il visitatore vaghi inutilmente per andare ad occupare un posto auto che in realtà è stato già occupato;

o Alta tolleranza ai malfunzionamenti dei sensori: un malfunzionamento del sensore comporterebbe la non veridicità delle informazioni (come per esempio il numero sbagliato dei posti auto disponibili o dei posti ad un evento disponibili) e quindi comprometterebbe l’utilità del sistema. Bisognerebbe quindi avere visibilità e celere segnalazione dei sensori non funzionanti;

o Alta tolleranza ai malfunzionamenti dei servizi: se uno dei servizi non funzionasse per un qualsiasi problema, dovrà esserci sempre la possibilità di utilizzare gli altri servizi funzionanti.

o Sostenere i picchi di accesso degli utenti: è importante riuscire a reggere un picco di accessi che può arrivare fino a circa 25.000 utenti contemporaneamente, in modo da rendere sempre fruibili i vari servizi;

Riportiamo qui sotto un’analisi più dettagliata dei requisiti architetturalmente significativi (ARS) e, per ogni requisito, individuiamo gli attori coinvolti e il valore misurabile alla risposta attesa:

Cod Fonte dello stimolo Stimolo Risposta Misura di rispostaARS1 Informazioni in tempo realeARS1.1

Visitatori Ricerca di posti auto disponibili in un dato parcheggio

Numero di posti auto liberi nel parcheggio aggiornati in tempo reale

Il numero di posti disponibili in un parcheggio deve essere aggiornato in base all’ultima entrata o uscita di un’auto degli ultimi 5 secondi

ARS1.2

Visitatori Verifica di disponibilità dei posti in un dato evento

Numero di posti disponibili per partecipare all’evento

Il numero di posti deve essere uguale al numero di posti disponibili meno il numero di prenotazioni attive, il tutto aggiornato negli ultimi 5 secondi

ARS1.3

Visitatori Verifica del meteo nell’ora dell’evento

Condizioni meteo e temperatura durante l’orario di svolgimento dell’evento

Le condizioni meteo devono essere aggiornate con le previsioni più precise che si hanno a disposizione

ARS Organizzatori Valutazione dello Numero di posti auto Il numero di posti



1.4 stato di occupazione delle aree adibite a parcheggio

occupati nel parcheggio aggiornati in tempo reale

occupati in un parcheggio deve essere aggiornato in base all’ultima entrata o uscita di un’auto negli ultimi 5 secondi

ARS1.5

Organizzatori Controllo del numero dei partecipanti attuali all’evento

Numero dei partecipanti attuali all’evento

Il numero dei partecipanti deve essere uguale al numero degli ingressi effettuati negli ultimi 5 secondi

ARS2

Alta tolleranza ai malfunzionamenti dei sensori

ARS2.1

Visitatori Ricerca di posti auto disponibili in un dato parcheggio

Numero di posti auto realmente liberi nel parcheggio

Il numero di posti deve rispecchiare il numero reale di posti auto disponibili o nel caso peggiore segnalare il guasto del contatore

ARS2.2

Visitatori Prenotazione di un posto in un dato evento

Posto realmente disponibile prenotato

Il posto prenotato deve essere realmente disponibile nel momento della prenotazione

ARS2.3

Organizzatori Controllo del numero dei partecipanti reali all’evento

Numero dei partecipanti effettivi all’evento

Il numero dei partecipanti effettivo deve essere veritiero a prescindere dai malfunzionamenti dei sensori

ARS2.4

Organizzatori Controllo dei sensori Segnalazione dei sensori funzionanti e quelli non funzionanti

Dovrà essere visibile sulla dashboard quali siano i sensori funzionanti (stato ON) e i sensori non funzionanti (stato OFF). Inoltre, al momento dell’individuazione di un sensore non funzionante, dovrà essere inviata una mail agli organizzatori

ARS3

Alta tolleranza ai malfunzionamenti dei servizi



ARS3.1

Visitatori Consultazione di uno dei servizi disponibili

Risposta al servizio se disponibile o avvertenza del problema per i servizi non disponibili

Anche se uno dei servizi riscontra una qualunque problematica, i servizi senza alcuna problematica devono continuare a rispondere correttamente

ARS3.2

Organizzatori Consultazione della dashboard

Risposta dei servizi che non presentano errori e segnalazione di quelli in cui si è riscontrato un errore

Dovrà essere visibile sulla dashboard quali siano i servizi funzionanti (ON) e i servizi non funzionanti (OFF)

ARS4

Sostenere i picchi di accesso degli utenti

ARS4.1

Visitatori e organizzatori

Accesso ad uno dei servizi

Risposta al servizio senza rallentamenti

La risposta al servizio deve essere sempre minore di 500 millisecondi a prescindere dal numero di utenti che usufruiscono del servizio

3. RequisitiIndividuati i punti principali possiamo stilare un elenco di requisiti che soddisfano i bisogni degli utilizzatori del sistema.

3.1. Requisiti funzionaliCod Titolo DescrizioneA CONSULTAZIONE EVENTIA1 Indicazioni dei luoghi su mappa Possibilità di consultare una mappa interattiva (es. Google

Maps, Leaflet, Open Map, ecc.) con le posizioni geolocalizzate dei luoghi in cui avverranno gli eventi

A2 Lista gli eventi nei luoghi Per ogni luogo verranno indicati gli eventi che ci saranno durante l’intera giornata, con il dettaglio dell’orario e dell’eventuale sala; gli eventi saranno ordinati per orario crescente

A3 Filtri avanzati di ricerca Sarà possibile filtrare gli eventi per nome, per orario, per luogo e per argomento

A4 Consultazione dettaglio evento Per ogni evento sarà possibile consultare il dettaglio che contiene una descrizione generale dell’evento e altre informazioni quali orario d’inizio, orario di fine, il luogo e l’argomento

B PRENOTAZIONE POSTIB1 Disponibilità posti Per ogni evento in programma verrà visualizzata la capienza

massima, il numero di posti prenotati e il numero di posti



disponibiliB2 Prenotazione posto Ogni utente potrà riservare un solo posto per un determinato

eventoB3 Generazione del ticket virtuale Con la prenotazione verrà generato un ticket virtuale con un

QR code univoco che servirà poi per partecipare all’eventoB4 Annullamento prenotazione Sarà possibile annullare la prenotazione del posto ad un

determinato evento cancellando la prenotazione e quindi rendendo non più valido il QR code

B5 Controllo overlap prenotazioni Il sistema blocca la prenotazione quando si tenta di prenotare un evento che inizia prima che finisca un altro evento precedentemente prenotato

B6 Time-line prenotazioni Sarà possibile visionare una time-line degli eventi prenotati ordinati per orario crescente

B7 Suggerimento degli eventi disponibili

Nel caso in cui non ci sia disponibilità di posti per un evento, il sistema suggerirà altri eventi disponibili in base all’affinità con l’evento ricercato (es. eventi prossimi per orario o luogo oppure eventi con lo stesso argomento)

B8 Ingresso agli eventi L’ingresso agli eventi sarà possibile attraverso la scansione del QR code generato durante la prenotazione

C SERVIZIO PARCHEGGIOC1 Indicazioni su mappa dei

parcheggiVerranno indicati sulla mappa interattiva i vari luoghi adibiti a parcheggio

C2 Disponibilità dei parcheggi Per ogni parcheggio verranno indicate le disponibilità totali di posti auto, il numero di posti già occupati e il numero di quelli liberi

C3 Lista dei parcheggi vicini In base al luogo scelto, verrà suggerita una lista di parcheggi dal più vicino al più lontano con il numero dei posti disponibili aggiornato al momento della ricerca

D SERVIZIO DI TRASPORTOD1 Consultazione dei mezzi di

trasporto per un indirizzo ed un orario scelto

Scegliendo un indirizzo da cui partire e un indirizzo ed un ora di arrivo, verranno mostrate una serie di opzioni di trasposto che partono dal luogo più vicino a quello indicato come partenza al luogo più vicino a quello indicato come arrivo, entro l’orario selezionato, con le indicazioni degli orari e dei mezzi di trasporto di cui usufruire; le corse saranno ordinate per durata del viaggio in maniera crescente

D2 Filtro per mezzo di trasporto Sarà possibile scegliere quale mezzo di trasporto includere nella ricerca

E SERVIZIO METEOE1 Indicazioni meteo per gli eventi Nel dettaglio dell’evento e nella time-line degli eventi

prenotati, saranno visualizzate, se disponibili, le condizioni metereologiche in base all’orario in cui si svolge l’evento

F DASHBOARDF1 Gestione dei luoghi Per gli organizzatori sarà possibile aggiungere, modificare ed



eliminare i luoghiF2 Gestione degli eventi Per gli organizzatori sarà possibile aggiungere, modificare ed

eliminare gli eventi (compresa la disponibilità dei posti)F3 Gestione dei parcheggi Gli organizzatori potranno aggiungere, modificare ed

eliminare i parcheggiF4 Controllo dei sensori Gli organizzatori potranno controllare lo stato dei sensori e

vedere quali sensori sono attivi e quali non lo sonoF5 Controllo dei servizi Gli organizzatori potranno controllare lo stato dei servizi

vedendo quali sono funzionanti e quali noF6 Controllo in tempo reale Gli organizzatori, dalla dashboard sarà possibile controllare:

- tutti gli eventi in corso con l’eventuale numero di partecipanti che hanno fatto l’accesso con il ticket virtuale aggiornato in tempo reale

- tutti i parcheggi con il numero di auto all’interno del parcheggio aggiornati in tempo reale attraverso i sensori di entrata e di uscita



3.2. Requisiti non funzionaliCod Titolo DescrizioneRF1 Tempi di risposta rapidi I tempi di risposta ad una chiamata devono essere

minori di 500 millisecondiRF2 Informazioni real-time Vedi ARS1RF3 Affidabilità Vedi ARS2 e ARS3RF4 Scalabilità Vedi ARS4

4. Architettura





Figura 1 - Architettura basata su micro-servizi

4.1. Architettura a micro-serviziL’architettura rappresentata in Figura 1 è un’architettura basata su micro-servizi. Questo tipo di architettura soddisfa alcuni requisiti importanti per il nostro sistema:

- Affidabilità : (requisito ARS3) si possono gestire gli errori di un servizio isolando la funzionalità senza bloccare l’intera applicazione. Eventuali servizi “difettosi” possono essere isolati singolarmente, riparati e rimessi in funzione senza necessariamente interrompere le funzionalità dell’intera applicazione;

- Scalabilità : (requisito ARS4) ogni servizio può essere distribuito sull’hardware più adatto alle esigenze specifiche del servizio e in termini di risorse permette di ridimensionare in modo corretto l’infrastruttura in base alle necessità, proteggendo il sistema nel caso in cui il servizio sperimenti un aumento nella richiesta.

Inoltre, abbiamo alcuni vantaggi come:

- Manutenibilità : i servizi si sviluppano e si distribuiscono in modo indipendente e quindi sono più facili da manutenere, correggere ed aggiornare;

- Flessibilità : l’aggiunta di un nuovo servizio è più facile e veloce riducendo così i tempi del time-to-marker; è possibile inoltre scegliere ogni volta un linguaggio di programmazione e framework diverso, magari i più adatti per quel servizio.

4.2. I micro-serviziIn base ai requisiti, è stato pensato di dividere il sistema in 8 micro-servizi dove ogni micro-servizio racchiude una serie di funzionalità:

- Venue service : (soddisfa alcuni dei requisiti della sezione A) permette di gestire tutte le informazioni che riguardano i luoghi della città in cui vengono svolti gli eventi;

- Event service : (soddisfa alcuni dei requisiti della sezione A e B) permette di gestire tutti gli eventi della giornata compreso l’inserimento del numero di posti disponibile per gli eventi a numero limitato; Racchiude anche il servizio di suggerimento di eventi affini;

- Booking service : (soddisfa alcuni dei requisiti della sezione B) gestisce le prenotazioni dei posti disponibili per partecipare ad un evento;

- Parking service : (soddisfa i requisiti della sezione C) permette di gestire tutte le informazioni sui parcheggi aggiornando anche le disponibilità dei posti auto con i dati che arrivano dai sensori;

- Transport service : (soddisfa i requisiti della sezione D) fornisce le informazioni sui mezzi di trasporto per raggiungere determinati luoghi e lo fa interfacciandosi con i diversi servizi di trasporto della città;

- Weather service : (soddisfa i requisiti della sezione E) fornisce le informazioni meteo per un dato evento e si interfaccia con un servizio esterno che restituisce informazioni sulle condizioni meteo;

- Dashboard service : (soddisfa i requisiti della sezione F) si interfaccia con gli altri servizi per fornire informazioni sulla situazione generale di tutto il sistema;

- Authentication service : fornisce il servizio di autenticazione e gestisce i permessi di accesso ai vari servizi di tutto il sistema.



4.3. I sensori- Parking mats : all’ingresso e all’uscita di ogni area recintata adibita a parcheggio ci saranno questi

sensori che conteranno, al passaggio della macchina, la presenza di una macchina in più o in meno nel parcheggio. Inoltre, per soddisfare il requisito ARS2, metteremo in ogni punto di entrata e di uscita 2 parking mats così da aumentare la fault tollerance in questo modo: i due sensori (che chiameremo sensore primario e sensore secondario) invieranno ogni 5 secondi un segnale per comunicare il loro stato di attività; entrambi i sensori, inoltre, invieranno il conteggio della macchina entrata o uscita e, se il sentore primario non sarà attivo allora si prenderanno i dati dal sensore secondario. Questo aiuta a coprire il tempo in cui il sensore primario non è funzionante senza perdere il conteggio delle auto, lasciando così il tempo agli organizzatori di sostituire il sensore o di vedere qual è la causa del problema;

- QR code scanner : all’entrata di un evento a numero limitato verrà posto un QR code scanner, con cui sarà possibile validare i biglietti virtuali generati dalla prenotazione, che permetterà ai visitatori di accedere all’evento e darà visibilità agli organizzatori di contare quante persone effettivamente sono entrate per partecipare all’evento. Per soddisfare il requisito ARS2, nel caso non funzionasse lo scanner, ci sarà la possibilità di validare manualmente il biglietto inserendo un codice che verrà visualizzato insieme al QR code.

4.4. I clientPer la parte client ci saranno due modalità di accesso:

- App mobile : i visitatori potranno usufruire dei servizi attraverso un’applicazione mobile. Essi hanno bisogno di un modo facile e veloce per accedere ai servizi in qualunque momento e dovunque si trovino e lo smartphone è naturalmente il dispositivo più adatto allo scopo; Tutti i servizi saranno fruibili senza bisogno di registrazione, tranne per il servizio di prenotazione agli eventi: nel momento in cui si vuole prenotare l’evento, sarà obbligatoria la registrazione per far sì che ogni visitatore prenoti un solo biglietto ad un evento (requisito B2) ma anche per gestire l’overlap delle prenotazioni per ogni utente (requisito B5) e generare la time-line degli eventi (requisito B6);

- Browser : gli organizzatori accederanno ai servizi attraverso il browser. Il lavoro di interazione più impegnativo per gli organizzatori è precedente al giorno dell’evento essendo il momento in cui inseriranno tutti i dati sugli eventi, i luoghi, ecc. Per questo tipo di inserimenti la soluzione più comoda è il PC. In ogni caso, durante l’evento, gli organizzatori potranno monitorare attraverso il browser dei loro smartphone la situazione in tempo reale e fare delle modifiche all’ultimo minuto. Per accedere ai servizi sarà necessaria l’autenticazione.

4.5. Il databaseIl database sarà NO-SQL così da poter dare vita a un’applicazione scalabile (requisito ARS4) a costi contenuti e con un’alta velocità di interazione (requisito RF1) data dalle seguenti caratteristiche:

- la navigazione tra oggetti che sfrutta i riferimenti tra i vari nodi di informazione rende molto più veloce l’accesso al db non avendo bisogno di operazioni di JOIN;

- non ci sono conversioni onerose tra record e oggetti, né si ricorre all’utilizzo di ORM o altre librerie specifiche.



5. PrototipoPer realizzare un prototipo del sistema sono stati sviluppati diverse componenti:

- Simulazione dei sensori parking mats : come tool di simulazione per i dispositivi IoT abbiamo scelto di utilizzare Node-RED (https://nodered.org) con cui sono stati gestiti i due parking mats;

- Message broker : realizzato attraverso una libreria in NodeJS (https://nodejs.org/it) chiamata Aedes (https://github.com/moscajs/aedes);

- Micro-servizi : tutti realizzati con il framework NestJS (https://nestjs.com) in NodeJS tranne Dashboard service che è stato realizzato con il framework Angular (https://angular.io);

- Integrazione con il servizio meteo : utilizzando le API di OpenWeather (https://openweathermap.org);- API gateway : realizzato tramite Amazon API Gateway (https://aws.amazon.com/it/api-gateway);- Database : come database NO-SQL è stato scelto MongoDB (https://www.mongodb.com/it) e per

garantire l’integrità dei dati è stata utilizzata la libreria Mongoose (https://mongoosejs.com);

5.1. Simulazione dei sensori parking matsAbbiamo utilizzato il plug-in Node-red-contrib-iot-virtual-device che aggiunge altri tipi di nodi che permettono la creazione del dispositivo virtuale e la manipolazione delle proprietà dello stesso.

Check dispositivo attivo

Partendo da un input che da informazioni circa l’id del dispositivo e il parcheggio a cui è associato, vengono generati 2 dispositivi, il sensore primario e il sensore secondario, a cui viene associato un timestamp per capire il momento in cui viene eseguito il controllo. Dopo questa operazione, grazie ad un nodo di collegamento, viene inviato un messaggio al message broker con l’id e il timestamp del sensore. I sensori verranno eliminati dopo aver mandato il suddetto messaggio.

Simulazione ingresso e uscita di auto

In questo caso abbiamo due tipi di input, uno è per l’entrata e l’altro è per l’uscita di un’automobile. In questi input, oltre alle informazioni sul parcheggio, verrà settata anche la variabile delta che sarà +1 all’entrata e -1 all’uscita. Come nel check del dispositivo attivo, verranno generati due device: il primario verrà istanziato al momento della ricezione dell’input, mentre il secondario verrà istanziato dopo un tempo random che varia da 1 a 5 secondi (è stato fatto per simulare il passaggio di una macchina che passerà sopra il sensore secondario solo dopo qualche secondo dal passaggio sul primario). Appena dopo, al sensore verrà settato il timestamp per poi inviare il messaggio al message broker con tutte le informazioni. I sensori verranno eliminati dopo aver mandato il suddetto messaggio.

5.2. Message brokerLa libreria Aedes genera un server che utilizza l’MQTT protocol (https://mqtt.org) come protocollo per lo scambio dei messaggi. Esso è un protocollo ISO standard di messaggistica leggero di tipo publish-subscribe. Questo protocollo è l’ideale per i device IoT perché è estremamente leggero e riduce drasticamente il peso dei messaggi sulla rete.

Abbiamo creato due tipi di eventi di cui il message broker è sempre in ascolto:



https://mqtt.org/

https://mongoosejs.com/

https://www.mongodb.com/it

https://aws.amazon.com/it/api-gateway/

https://openweathermap.org/

https://angular.io/

https://nestjs.com/

https://github.com/moscajs/aedes

https://nodejs.org/it/

https://nodered.org/

- check_activated : è il tipo di messaggio che riceve quando un sensore segnala di essere attivo. In questo caso il message broker richiama le API di Parking service per aggiornare lo stato del sensore che ha inviato il messaggio, impostandolo come attivo;

- parking : è il tipo di messaggio che riceve quando entra o esce una macchina. In questo caso richiama le API di Parking service per aggiungere un posto auto disponibile, se il campo delta è -1, o aggiungere un posto auto disponibile se il campo delta è +1; Anche questo tipo di evento aggiorna lo stato del sensore segnalando che è attivo.

5.3. Micro-serviziVenue service

Effettua le operazioni CRUD sui luoghi in cui avverranno gli eventi. Le operazioni di create, update e delete possono essere effettuate solo dagli Organizzatori.

Un luogo avrà:

- ID- Nome- Coordinate

Event service

Effettua le operazioni CRUD sugli eventi. Le operazioni di create, update e delete possono essere effettuate solo dagli Organizzatori.

Un evento avrà:

- ID- Nome- Inizio- Fine- Luogo ID (riferimento ad un luogo censito in Vanue service)- Sala- Argomento- Descrizione- Posti totali- Posti disponibili (viene calcolato in base al numero di prenotazioni di quell’evento censite in Booking

service)

Booking service

Ci sono due modalità di utilizzo del servizio: come Organizzatore sarà possibile vedere tutte le prenotazioni potendo effettuare le operazioni CRUD su di esse; come Visitatore si potranno vedere, dopo aver effettuato l’accesso, tutte le proprie prenotazioni ed effettuare quindi operazioni CRUD sono su di esse.

Una prenotazione avrà

- ID (è di tipo GUID e viene utilizzato per generare il QR code)



- Data creazione- Data validazione- Evento ID (riferimento ad un evento censito in Event service)- Utente ID (riferimento ad un utente censito attraverso Authentication service)

Parking service

Effettua le operazioni CRUD sui parcheggi. Le operazioni di create, update e delete possono essere effettuate solo dagli Organizzatori. Il Message broker invece può richiamare questo servizio per aggiornare la data dell’ultimo check dei sensori oppure per aggiornare il numero di posti auto disponibili.

Un parcheggio ha:

- ID- Nome- Posti auto totali- Posti auto disponibili- Coordinate- Sensori ID (riferimento ai due oggetti di tipo sensore che hanno ID, Ultimo check e il Tipo)

Weather service

Richiama un servizio esterno per aggiornare le condizioni atmosferiche. Una condizione atmosferica è in sola lettura e ha:

- Codice- Stato- Coordinate- Data- Temperatura- Temperatura percepita- Umidità- Velocità del vento- Icona

Authentication service

Tramite questo servizio viene gestito il servizio di login e di registrazione degli utenti. Solo gli Organizzatori possono effettuare le operazioni CRUD su tutti gli utenti, mentre i Visitatori effettuano operazioni CRUD solo sul proprio utente.

Un utente ha:

- ID- Username- Nome- Cognome- E-mail- Password



- Ruolo (nel nostro caso ci sono 2 tipi di ruolo, cioè Organizzatore e Visitatore)- Data creazione

Dashboard service

È un progetto client che sfrutta quasi tutti gli altri micro-servizi:

- L’accesso alla dashboard viene fatto attraverso Authentication service che, nel caso di autenticazione avvenuta con successo, restituisce un token che servirà per verificare che chi sta agendo sul sistema abbia i permessi per accedere alle funzionalità;

- L’anagrafica dei luoghi sfrutta Venue service per effettuare operazioni CRUD sui luoghi;- L’anagrafica degli eventi sfrutta Event service per effettuare operazioni CRUD sugli eventi;- L’anagrafica dei parcheggi sfrutta Parking service per effettuare operazioni CRUD sui luoghi;- La sezione dei sensori, invece, mostra lo stato di tutti i sensori del sistema. Ogni sensore sarà nello

stato ON se il campo ultimo check ha una data di massimo 5 secondi prima, OFF altrimenti.

5.4. Integrazione con il servizio di meteoI dati forniti gratuitamente da OpenWeather sono: le condizioni meteo attuali, le previsioni orarie per le prossime 48 ore e le previsioni giornaliere per i prossimi 7 giorni.

In base ai dati forniti abbiamo implementato il servizio meteo in questo modo: in base alla data passata in input (cioè la data e l’ora dell’evento) si cerca se quella data/ora è presente nelle previsioni orario delle prossime 48 ore, se è presente vengono restituite le informazioni, altrimenti si cerca quella stessa data/ora all’interno delle previsioni giornaliere dei prossimi 7 giorni. Se la data/ora è presente vengono restituite le informazioni altrimenti le previsioni meteo verranno segnate come non disponibili.

5.5. API gatewayÈ stato sfruttato il servizio Amazon API Geteway su cui sono stati creati tutti gli endpoint dei vari servizi implementati. Ad ogni endpoint viene associata un AWS Lambda che si prende in carico le azioni necessarie per eseguire l’operazione richiesta ricalibrando le risorse.

5.6. DatabasePer questo prototipo abbiamo realizzato un unico database con le seguenti collection:

- Bookings- Events- Parkings- Users- Venues

5.7. Materiale fornito per testare il prototipoNella cartella NdR-prototype ci sono i seguenti file e cartelle:

- simulate-parking-mats.json : file json da importare su Node-RED per simulare i parking mats;- microservices : codice sorgente degli 8 micro-servizi;



- mqtt-server : codice sorgente del message broker;

Per testare il prototipo bisogna:

1. installare NodeJS (https://nodejs.org/it/download)2. installare il gestore di pacchetti NPM (solitamente installando NodeJS viene installato anche NPM)3. installare Typescript eseguendo il comando npm i -g typescript4. installare la CLI di Angular eseguire il comando npm i -g @angular/cli5. installare Node-RED eseguendo il comando npm i -g node-red oppure seguendo la guida

(https://nodered.org/docs/getting-started/local)6. importare su Node-RED il json simulate-parking-mats.json7. aprire una finestra di comando nella cartella NdR-prototype ed eseguire il comando npm run

install_and_start per installare le dipendenze dei progetti e per far partire il server mqtt, node-RED e ndr-dashboard (l’operazione potrebbe richiedere qualche minuto).Nel caso di errori, eseguire il comando nmp i sia nella cartella mqtt-server che nella cartella ndr-dashboard (all’interno della cartella microserveces) e successivamente eseguire il comando npm run start:prod nella cartella NdR-prototype

8. Per accedere alla dashboard andare su http://localhost:4200 e fare login con username admin e password 123456

Per i successivi avvii basterà semplicemente eseguire il comando npm run start:prod



http://localhost:4200/

https://nodered.org/docs/getting-started/local

https://nodejs.org/it/download

Notte dei Ricercatori · Web viewNotte dei Ricercatori. Notte dei Ricercatori. Notte dei...

Documents

Transcript of Notte dei Ricercatori · Web viewNotte dei Ricercatori. Notte dei Ricercatori. Notte dei...