Piattaforma raccolta dati per sistema IOT - SYNOVATEC

Giussani Luca

Poretti Giacomo

Alfons Knüsel

Ingegneria Informatica

Progetto di diploma

2018-2019

Indice

1 Abstract 1

2 Progetto assegnato 3

3 Introduzione 5

4 Tecnologie e metodologie utilizzate 7

4.1 Back-end . . . 7

4.2 Front-end . . . 7

4.3 Google Cloud Platform . . . 8

4.4 Docker . . . 8

4.5 Git & GitHub . . . 9

4.6 Protocollo LoRa . . . 9

4.7 Metodologia di lavoro . . . 10

5 Analisi dei requisiti 11 5.1 Amministrazione delle compagnie esterne . . . 11

5.1.1 Creazione del cliente . . . 12

5.1.2 Gestione dei cantieri . . . 12

5.2 Utilizzo dei sensori . . . 12

5.2.1 Progettazione . . . 13

5.2.2 Trasmissione dati . . . 14

5.2.3 Utilizzo nella piattaforma . . . 15

5.2.4 Gestione allarmi . . . 15

5.3 Visualizzazione grafica dei dati ricevuti dai sensori . . . 15

5.4 Dashboard per monitoraggio . . . 16

5.4.1 Personalizzata per amministratore . . . 16

5.4.2 Personalizzata per il cliente . . . 17

ii INDICE

6 Organizzazione del lavoro 19

6.1 Suddivisione degli sprint . . . 19

6.1.1 Obiettivi . . . 19

6.1.2 Contenuti degli sprint . . . 20

7 Implementazione e funzionamento 23 7.1 Database . . . 23

7.2 Sistema gestionale delle risorse . . . 24

7.2.1 Amministrazione delle compagnie esterne . . . 25

7.2.2 Gestione dei dipendenti . . . 27

7.2.3 Autogestione del cliente . . . 28

7.2.4 Gestione sensori . . . 30

7.3 Visualizzazione informazioni . . . 32

7.4 Gestione mappature per controllo di sicurezza . . . 34

7.5 Docker e Google Cloud . . . 34

7.6 Test . . . 35

8 Sviluppo futuro 37 9 Conclusione 39 9.1 Obiettivi raggiunti . . . 39

Elenco delle figure

2.1 Progetto assegnato . . . 4

4.1 Google Cloud Platform Services . . . 8

4.2 Schema di applicazione del protocollo LoRaWAN . . . 9

5.1 Sensore di rilevamento nel cemento . . . 13

5.2 Dispositivo di conversione e trasmissione delle informazioni rilevate . . . 13

5.3 Contenitore protettivo dell’hardware . . . 14

7.1 Diagramma ER del database creato . . . 23

7.2 Fragment del banner di intestazione all’interno della pagina di master HTML . 24 7.3 Interfaccia di creazione di una nuova compagnia . . . 25

7.4 Funzione del Service di aggiunta di una nuova compagnia . . . 26

7.5 Assegnamento sensori con sistema di autocompletamento . . . 26

7.6 Sezione di script interni alla pagina .html che gestisce i sensori per la compa-gnia . . . 27

7.7 Form di aggiunta di un nuovo cantiere . . . 28

7.8 Metodo per inizializzazione della mappa e del marker . . . 29

7.9 Metodo per trascinamento del marker . . . 29

7.10 Aggiunta o modifica di sezioni al cantiere con caricamento planimetria . . . . 30

7.11 Interfaccia di aggiunta di sensori al sistema . . . 31

7.12 Posizionamento dei sensori all’interno della planimetria . . . 31

7.13 Dashboard dell’amministratore . . . 32

7.14 Visualizzazione delle informazioni specifiche di un sensore . . . 33

7.15 Google Cloud Console che mostra i servizi di frontend e backend attivi . . . . 35

Capitolo 1

Abstract

Synovatec1è una società commerciale specializzata nel settore delle costruzioni, che forni-sce consulenza ai propri clienti a 360 gradi e servizi di noleggio di macchinari per l’impiego su particolari fibre.

Il signor Alfons Knüsel, amministratore delegato della compagnia, inizierà a commercializ-zare un sensore in grado di misurare la temperatura e il grado di umidità del cemento e inviarne i dati tramite un’apposita antenna. L’utilizzo di questa tecnologia, recentemente brevettata, consentirà quindi di informare in tempo reale le imprese di costruzione su quan-do poter procedere con i successivi lavori ad ogni gettata di cemento.

Il progetto rientra nella definizione classica dei sistemi IOT (Internet Of Things) e si prefig-ge l’obbiettivo di sviluppare una piattaforma di prefig-gestione e monitoraggio delle informazioni raccolte da una rete di sensori e di generazione di allarmi nel caso in cui si verifichino de-terminate condizioni.

Il risultato finale sarà un’applicazione web che si occuperà della gestione completa delle compagnie, dei sensori e dell’invio di allarmi.

Synovatec is a company specialized in building business, which provides all-around advice to his customer and rental services of machine for use on particular fiber.

Mr. Alfons Knüsel, CEO of the society, will commercialize a sensor able to mesure the temperature and the humidity of the cement and able to send the data obtained using a dedicated antenna. The use of this technology, recently patented, will allow to inform in real time the construction company on when is possible to move forward with the next job for all concrete slabs.

This project belongs to the classic definition of IOT (Internet Of Things) and it has the goal to develop a platform which manages and monitors the information collected from a sensor net and also to create alarms when special conditions take place.

1

2 Abstract

The final result will be a web application which will takes care of the complete management of the companies, sensors and the sending of alarms.

4 Progetto assegnato

Capitolo 2

Progetto assegnato

Capitolo 3

Introduzione

Le principali funzionalità di cui è richiesta l’implementazione per la creazione del progetto vanno nella direzione di un sistema IOT, incaricato di monitorare e gestire le informazioni ricavate da una rete di sensori.

I sensori inviano dati come la temperatura e il livello di umidità del cemento in cui sono in-seriti, attraverso un’antenna che trasmette a Swisscom utilizzando il protocollo LORA.

Per fare in modo che la piattaforma sia visibile all’esterno e quindi anche a Swisscom, tra i requisiti del progetto è stato aggiunto quello di poterla esporre in internet attraverso i server di Google1.

Uno dei compiti più importante da svolgere è quindi la realizzazione di una web application per consentire un’amministrazione diretta delle risorse, sia da parte di Synovatec sia da parte delle imprese che hanno adottato la nuova tecnologia brevettata. Più nello specifico si vuole concepire un modello dati su cui costruire un sistema in grado di gestire le anagrafiche delle compagnie, dei suoi impiegati e cantieri e i rispettivi sensori assegnati, mostrandone le informazioni e dando la possibilità di impostare le soglie per cui far scattare gli allarmi.

Quando si verificano determinate condizioni partiranno delle email automatiche verso gli utenti registrati, garantendo una maggior efficienza. Se l’operatore viene a conoscenza per tempo che la gettata è pronta allora potrà subito procedere con i lavori, senza dover recarsi sul posto per monitorare lo stato.

1

Capitolo 4

Tecnologie e metodologie utilizzate

Il progetto preso in carico, come detto, è una nuova piattaforma del tipo IOT, di conseguenza per il lavoro sono state stabilite insieme al relatore le tecnologie e metodologie da utilizzare per affrontare al meglio l’intero sviluppo.

4.1

Back-end

Il back-end dell’applicazione è stato sviluppato in Java con Spring MVC. Il framework

for-nisce tecnologie per la gestione della sicurezza e della connessione con il database, oltre che naturalmente la possibilità di servire richieste HTTP.

Per la gestione del database, Spring è stato affiancato da un ORM, JPA, per la gestione

della struttura e del contenuto delle tabelle.

4.2

Front-end

Il front-end è stato implementato utilizzando le comuni tecnologie web comeHTML e CSS

per la creazione di pagine e template conThymeleaf, per ottenere delle pagine costruite

dinamicamente dal server. Il layout grafico della GUI è stato preso da Colorlib1ed è succes-sivamente stato adattato, integrato nel sistema e personalizzato, mantenendo solamente le parti ritenute più significative per lo scopo del progetto. Le altre componenti grafiche sono state ottenute utilizzando Bootstrap e librerie esterne tra cui le API di Google per la creazio-ne e gestiocreazio-ne delle mappe, ChartJS 2per i grafici e InteractJS3 per la funzionalità di drag and drop dei sensori per il posizionamento sulla planimetria. Per la gestione dell’interazione con l’utente e per la comunicazione asincrona con il server sono stati usati, rispettivamente,

JavaScript e AJAX tramite JQuery.

1

Link al sito web: https://colorlib.com/

2_{https://www.chartjs.org/} 3

8 Tecnologie e metodologie utilizzate

4.3

Google Cloud Platform

Google fornisce una suite dicloud computing service all’interno della stessa infrastruttura.

Qui è quindi possibile creare progetti di natura diversa, che si possono appoggiare a nume-rose tipologie di strumenti, sistemi di archiviazione, servizi di networking e di intelligenza artificiale.

Tra i molteplici servizi offerti c’è ancheKubernetes Engine in cui è possibile configurare un

cluster in grado di gestire più container (vedi capitolo 4.4) e automatizzare la creazione e manutenzione delle macchine virtuali che ospitano l’applicazione web.

L’ultimo strumento offerto che è stato utilizzato è ilLoad Balancer, grazie al quale è

possi-bile esporre all’esterno l’app e amministrarne il carico di lavoro.

Figura 4.1: Google Cloud Platform Services

4.4

Docker

Per rendere il deploy e l’esecuzione dell’applicazione più semplice e scalabile è stata utiliz-zata questa tecnologia che sfrutta i container per pacchettizzare l’applicazione con tutte le sue parti necessarie. Grazie a questo sistema si è certi che la l’applicazione funzionerà su una qualsiasi macchina linux dal momento che viene emulato un ambiente isolato.

Grazie a questa tecnologia, assieme al Kubernetes Engine di Google Cloud, è stato pos-sibile fare Continuous Integration perchè ad ogni incremento di funzionalità viene ricreata una nuova istanza che va a prendere il posto di quella vecchia all’interno del repository di Docker, Docker Hub4. Una volta applicate le modifiche all’interno del cluster di Kubernetes quindi verrà utilizzata la nuova istanza per far ripartire il deploy, avendo già in produzione le ultime modifiche effettuate.

4

per le differenti tipologie di funzionalità (prevenendo eventuali inconsistenze o perdite di co-dice quando sopraggiungono errori complessi) per poi unirle nel ramo di sviluppo principale, che contiene l’intera evoluzione del progetto.

4.6

Protocollo LoRa

Sebbene questo protocollo non viene impiegato direttamente per lo sviluppo dell’applica-zione web, esso è importante per l’ecosistema generale del sistema (piattaforma + sensori) in quanto viene utilizzato per la trasmissione delle informazioni che vengono ricavate dai sensori posti all’interno della gettata di cemento.

LoRa (Long Range) si sta affermando sempre di più nel settore IOT, in quanto è uno dei principali protocolli utilizzati nel campo del LPWAN (Low Power WAN). Esso utilizza una modulazione Chirp Spread Spectrum (applicata negli ambienti militari) che aumenta la re-sistenza al rumore e, grazie all’impiego dello Spreading Factor, permette di regolare il bit rate a seconda della larghezza di banda influenzando la durata della trasmissione e quindi i consumi energetici.

Figura 4.2: Schema di applicazione del protocollo LoRaWAN

5

10 Tecnologie e metodologie utilizzate

Sopra a questo livello fisico giace ilLoRaWAN che è il protocollo con il quale vengono

defi-nite una serie di regole e architetture per poter creare una rete interconnessa di dispositivi. La topologia di rete LoRaWAN, come si può vedere in figura 4.2, viene chiamata star of stars perchè un server per le applicazioni è collegato ad una moltitudine di gateway a cui sono allacciati i terminali secondo un’architettura a stella.

In questo progetto quindi diventa importante l’impiego di questo protocollo perchè consente ai sensori di poter trasmettere per anni utilizzando delle piccole batterie e coprendo notevoli distanze.

4.7

Metodologia di lavoro

Per poter pianificare al meglio il lavoro (14 settimane) e poterne gestire l’avanzamento è stata applicata la metodologia agileSCRUM. I requisiti da portare a termine e le funzionalità

da implementare sono state inizialmente segnate e discusse insieme al relatore e ad esse è stata data una priorità. Successivamente è avvenuto l’incontro con il committente, con il quale si è verificato se le funzionalità decise accoglievano i suoi bisogni. A questo punto il lavoro è stato suddiviso su più sprint (della durata ciascuno di due settimane, per un totale di 7 sprint) ed è stato gestito utilizzando l’applicazione web Trello6.

Vedi approfondimento al capitolo 6.

6

Capitolo 5

Analisi dei requisiti

Come già accennato durante la spiegazione delle metodologie scelte, a inizio progetto sono stati definiti con il relatore e successivamente confermati con il committente i requisiti del progetto (in questo caso, le funzionalità prioritarie su cui focalizzarsi):

• Amministrazione delle compagnie esterne fruitrici dei sensori • Gestione interna ed esterna (clienti) dei sensori

• Visualizzazione grafica dei dati ricevuti dai sensori • Dashboard per monitoraggio semplificato

• Export dei dati per l’amministratore

Il livello di dettaglio e la comprensione dei requisiti sono andati mano a mano migliorando con l’avanzare del progetto: i primi incontri con il relatore e quello principale con il com-mittente sono serviti a dettagliare le richieste più importanti e a circoscrivere le diverse situazioni di utilizzo delle nuove funzionalità dell’applicazione. In aggiunta sono stati effet-tuati degli incontri anche con il docente che sta seguendo la parte di elettronica del progetto finale per chiarire il sistema di trasmissione usato e strutturare l’interpretazione grafica dei dati ricevuti secondo la tipologia effettiva di ciò che è contenuto nel pacchetto inviato dal sensore (ID, temperatura, umidità, potenza del segnale e livello di batteria).

5.1

Amministrazione delle compagnie esterne

Per poter vendere i propri sensori ai clienti, il committente necessita di un sistema che possa gestire in maniera funzionale e semplice le compagnie esterne che compreranno la tecnologia di sensori recentemente brevettata.

A tal proposito sono state create delle apposite sezioni disponibili solamente all’azienda amministratrice e altre rivolte alle imprese partner.

12 Analisi dei requisiti

5.1.1

Creazione del cliente

Per poter creare un cliente l’amministratore deve specificare le informazioni principali e le-gali della nuova azienda e in aggiunta anche una persona di riferimento, per cui si richiede l’inserimento di un indirizzo mail e di un numero di cellulare.

I primi dati servono per identificare la compagnia esterna, mentre gli ultimi per dare ac-cesso all’applicazione web ad una figura fisica, che può ricoprire per esempio il ruolo di amministratore delegato oppure di capo cantiere, vista la tipologia di clienti che può esse-re inteesse-ressata all’acquisto dei sensori. All’indirizzo mail specificato verrà inviata quindi una password temporanea, la quale serve per garantire il primo accesso e successivamente può essere modificata per soddisfare meglio le esigenze del nuovo utente creato.

Si è successivamente pensato di dare in aggiunta la possibilità alle impresa partner di con-sentire l’accesso e l’utilizzo della webapp anche ai propri dipendenti. Per fare ciò si è reso necessario aprire la registrazione a tutti i possibili utenti (operazione che prima poteva effet-tuare solamente l’admin), ma impedendo loro di poter vedere dei contenuti che non faces-sero parte della loro compagnia.

La soluzione a questo problema è un token identificativo univoco che viene assegnato alla compagnia in fase di creazione, e che in seguito viene spedito automaticamente via mail. In questo modo i dipendenti (es. muratori) possono registrarsi nella piattaforma, specificando il rispettivo token, e accedere solamente alle informazioni di loro competenza.

5.1.2

Gestione dei cantieri

Nel momento in cui il cliente ottiene l’accesso alla piattaforma, avrà a disposizione una se-rie di funzionalità mirate alla visualizzazione e gestione dei sensori nei diversi cantieri da lui aperti.

Quando viene avviato un nuovo cantiere nella realtà, esso va registrato anche all’interno dell’applicazione web, specificandone la posizione e dandogli un nome identificativo. In questo modo il cliente può successivamente definire all’interno del cantiere stesso le dif-ferenti sezioni (es. primo piano, secondo piano, etc..), nelle quali verranno effettivamente piazzati i sensori dopo aver fatto la gettata. Essi quindi verranno localizzati internamente al futuro edificio tramite la loro posizione all’interno delle planimetrie delle sezioni.

5.2

Utilizzo dei sensori

Nel momento in cui avverrà la commercializzazione dei sensori brevettati dal committente, la piattaforma deve essere pronta a poterli gestire, dal loro inserimento all’interno del database al loro utilizzo all’interno dei cantieri delle diverse compagnie esterne.

La tecnologia brevettata dal committente prevede la presenza di più componenti hardware: • Sensore di rilevamento: questo è il componente che viene inserito nella gettata ed ha il compito di rilevare l’umidità e la temperatura del cemento. Ogni volta che si procede alle successive gettate questa parte viene persa.

Figura 5.1: Sensore di rilevamento nel cemento

• Dispositivo di trasmissione: è una scheda stampata che riceve le informazioni grezze dal sensore, le converte in formato human readable e le trasmette tramite l’antenna. Dispone inoltre di un piccolo pacco batterie che gli consente, assieme alle caratte-ristiche power safe del protocollo di trasmissione LoRa, di operare per una durata quantificata in anni.

14 Analisi dei requisiti

• Contenitore: è un box di plastica strutturato per contenere il dispositivo di trasmissione e inserire il sensore di rilevamento che giace all’esterno. Questo ha un coperchio di plastica per proteggere l’hardware contenuto e deve venir posizionato prima della gettata, in maniera tale che il cemento gli si disponga attorno.

Figura 5.3: Contenitore protettivo dell’hardware

5.2.2

Trasmissione dati

Dalle antenne poste vengono trasmessi l’identificativo del sensori, la potenza del segnale, il livello di batteria e in aggiunta i dati che vengono ricavati, quindi temperatura e umidità. L’antenna collegata invia i dati utilizzando il protocollo LORA e per consentirne il funziona-mento è necessario che tutti i sensori commercializzati siano prima registrati su Swisscom ThingPark1 .

A questo punto il sensore manderà i dati ai server di Swisscom, ma ThingPark non offre nessuna funzione di visualizzazione. Occorre per questo motivo appoggiarsi ad altri servizi verso cui instradare i dati. Per verificare il funzionamento del sistema di trasmissione quindi si è ricorso all’utilizzo di Cayenne, il quale permette di visionare con dei grafici personaliz-zati l’andamento dei dati inviati dai sensori. Ciò è consentito perchè nelle impostazioni deve essere specificato il tipo di protocollo usato e quindi può avvenire la decodifica dei pacchetti di informazioni in ingresso.

Questo passaggio al giorno d’oggi non può venir effettuato verso l’applicazione web di tesi perchè non è ancora chiaro al team di sviluppo della parte elettronica dell’intero progetto

1

5.2.3

Utilizzo nella piattaforma

I sensori devono essere inizialmente inseriti all’interno del sistema, specificandone l’ID, il quale deve essere uguale a quello che è registrato su Swisscom. In questo modo quando vengono ricevuti i dati inviati, essi si potranno associare al rispettivo sensore.

A questo punto l’amministratore può decidere quali dispositivi assegnare ad ogni cliente, la-sciandone il controllo. Quest’ultimo ha poi la possibilità di caricare nel sistema le planimetrie delle varie sezioni dei cantieri e in esse potrà posizionare i sensori in maniera grafica. Pa-rallelamente dovrà effettuare la medesima operazione nella realtà, inserendoli nel cemento nelle zone da lui precedentemente specificate.

Da qui in avanti i sensori iniziano a trasmettere giornalmente informazioni come tempera-tura, umidità, livello di batteria e potenza del segnale, dopo che la compagnia esterna ha definito sull’umidità una soglia per ogni sensore; quando la rete di sensori presente per ogni sezione all’interno del cantiere supera questa soglia, partirà un allarme che informa l’azienda che si può procedere per la successiva gettata.

5.2.4

Gestione allarmi

Come spiegato nella sezione precedente, gli allarmi partono ogni volta che tutti i sensori po-sizionati all’interno di una planimetria rilevano che l’umidità è scesa sotto il valore di soglia. All’inizio del progetto questa passaggio corrispondeva alla generazione di una notifica all’in-terno di un’applicazione mobile apposita, però durante le settimane di sviluppo si è deciso assieme al relatore di utilizzare un altro sistema perchè altrimenti si sarebbe dovuta creare un’app esclusivamente per la semplice ricezione di una comunicazione.

L’allarme in questione si è quindi tramutato in una mail che viene inviata alla compagnia e ai suoi dipendenti in cui è indicato in quale cantiere e più precisamente in quale sezione è possibile continuare i lavori. In questo modo viene evitato al cliente di delegare dei lavora-tori che devono continuamente monitorare lo stato di ogni cantiere attivo per poter capire in quale si può avanzare nella costruzione.

5.3

Visualizzazione grafica dei dati ricevuti dai sensori

I dati sopracitati vengono trasmessi una volta al giorno e quando giungono all’applicazione web essi sono memorizzati all’interno del database.

2

16 Analisi dei requisiti

Una delle funzionalità richieste è la visualizzazione semplificata delle informazioni, generali e specifiche, per tutti i sensori presenti nel sistema.

Si è pensato quindi di creare una sezione in cui si possono vedere sottoforma di tabella i dispositivi acquistati dalla compagnia e di essi devono venir mostrati l’identificativo, lo stato, il tipo di attività, la data di creazione, quella di assegnamento all’interno di un cantiere ed eventualmente quella in cui è partito l’allarme.

È possibile successivamente entrare nello specifico di ogni sensore per agevolare l’inter-pretazione dei dati da parte del cliente. In questo caso è richiesta la creazione di grafici rispettivamente per temperatura, umidità e livello di batteria, di cui si mostra l’andamento nel tempo. In questo modo diventa facile per il cliente capire come evolve la situazione all’interno delle sezioni dei vari cantieri e allo stesso tempo può monitorare lo stato del sensore verificandone il livello di batteria. Nel caso in cui si riduce drasticamente si può informare l’azienda che per un determinato sensore va sostituita la batteria.

5.4

Dashboard per monitoraggio

Nel corso dello sviluppo dell’applicazione web si è deciso di creare un sistema che semplifi-casse e velocizzasse il processo di monitoraggio delle risorse, sia per il committente sia per i successivi clienti.

È stata quindi creata una dashboard che viene personalizzata a seconda del ruolo dell’u-tente loggato, amministratore o cliente.

5.4.1

Personalizzata per amministratore

Una volta loggato l’amministratore viene condotto alla propria dashboard in cui sono presenti in alto delle informazioni generiche, come il numero totale dei clienti e dei sensori e la percentuale di sensori assegnati alle compagnie esterne.

Subito sotto si trovano invece più dettagli sottoforma di grafici. Un diagramma a barre indica quanti sensori sono assegnati ai diversi clienti, mentre un grafico a torta ne mostra lo stato: • Attivo funzionante: inserito nel cemento e sta inviando correttamente le informazioni

una volta al giorno.

• Attivo down: inserito nel cemento ma presenta un malfunzionamento o una mancata copertura di segnale.

• Inattivo: non inserito nel cemento, di conseguenza non c’è invio di informazioni. Ogni componente all’interno della dashboard è cliccabile e porta l’utente in pagine dedicate per mostrare informazioni mirate.

Come per l’amministratore anche il cliente dispone di un sistema di monitoraggio persona-lizzato secondo le sue esigenze.

A livello grafico le due tipologie di dashboard sono molto simili (viene utilizzata la stessa disposizione), ma le informazioni mostrate sono ovviamente diverse.

In questo caso nella sezione generica vengono visualizzati il numero di cantieri aperti, il numero di sensori acquistati e la percentuale di sensori che sono impiegati.

Le informazioni più dettagliate vengono mostrate di seguito grazie ad un diagramma a barre che mostra quanti sensori sono assegnati ad ogni cantiere e ad un grafico a torta analogo a quello dell’amministratore, ma destinato ai soli sensori dell’azienda.

Anche in questo caso i componenti sono cliccabili.

5.5

Export dei dati

Durante l’incontro con il committente è emersa la sua necessità di avere a portata di ma-no quando necessario le informazioni presenti all’interma-no del database, per poter effettuare delle analisi e valutare la strategia di business più efficace.

Per questo motivo si è deciso di creare un sistema, accessibile direttamente dalla dash-board, che permetta all’amministratore di esportare le informazioni ogni qualvolta lo ritenga necessario. Queste sono condensate all’interno di file .csv e l’admin può decidere tra due possibili tipologie di log files:

• Informazioni generiche dei sensori come il cliente proprietario, la sezione in cui sono inseriti, la loro condizione di attività, il loro stato (soglia superata o no) e le date di creazione, inserimento nel cemento ed eventualmente di raggiungimento della soglia. • Collezione di dati ricevuti giornalmente dalle antenne dei dispositivi, contenenti infor-mazioni di contesto del sensore (compagnia di appartenenza e dov’è collocato) e tutti i rispettivi rilevamenti come temperatura, umidità e stato del segnale e batteria del dispositivo per monitorare le condizioni del sistema di trasmissione.

I file possono venire scaricati e in questo modo essi potranno essere archiviati nella loca-zione più comoda per il committente all’interno del suo computer o smartphone per poter essere studiati al meglio.

Capitolo 6

Organizzazione del lavoro

Come stabilito dalle metodologie agili, il lavoro è stato suddiviso in sprint della durata di 2 settimane ciascuno, per un totale di 7 sprint (il tempo stabilito per il progetto durante la pausa estiva sono 14 settimane). Per ogni sprint è stato sempre fissato un incontro con il relatore per verificare l’avanzamento dei lavori e la corrispondenza del prodotto con quanto richiesto dai requisiti.

Per poter tenere traccia del lavoro svolto e organizzare gli sprint, è stato utilizzato Trel-lo, un’applicazione web che consente di organizzare e pianificare al meglio le attività e i progetti. Su Trello sono state create diverse liste:

• ToDo: contiene le richieste segnate durante gli incontri con il committente e relato-re, insieme a tutte le operazioni e modifiche che sono state ritenute necessarie per completare le funzionalità stabilite.

• Sprint: contiene le attività necessarie per portare all’incremento, che vengono prele-vate dalla ToDo list in ordine a seconda della priorità.

• DailyToDo: comprende quelle mansioni presenti all’interno degli sprint che sono as-segnate per essere completate nell’arco della giornata.

In seguito vengono mostrati gli sprint con le rispettive attività che sono state portate a termine nel corso delle settimane di sviluppo.

6.1

Suddivisione degli sprint

6.1.1

Obiettivi

Una volta dettagliati gli obiettivi principali, in accordo alle metodologie di lavoro adottate, per ogni sprint è stato definito l’obiettivo principale da raggiungere1:

1

20 Organizzazione del lavoro

• Sprint 7: gestione allarmi e documentazione • Sprint 6: compimento interfaccia e miglioramenti

• Sprint 5: sviluppo geolocalizzazione e rinforzo della consistenza generale • Sprint 4: gestione sensori e assegnamento alle planimetrie

• Sprint 3: ultimazione database e della sua interazione con la GUI • Sprint 2: studio delle tecnologie da usare e inizio dell’interfaccia • Sprint 1: comprensione e partenza del progetto

Capitolo 7

Implementazione e funzionamento

Per ognuno dei requisiti esposti nel capitolo 5 vengono presentate le soluzioni fornite po-nendo ora l’attenzione sulle scelte implementative, condizionate anche dal fatto che l’ap-plicazione web viene resa disponibile sia per dispositivi desktop sia per mobile in quanto codificata totalmente in maniera responsive.

7.1

Database

24 Implementazione e funzionamento

Per rendere persistenti le informazioni che vengono trasmesse dai sensori, insieme a tutte quelle inserite all’interno della piattaforma, è fondamentale l’utilizzo di un database.

Esso è stato inizialmente strutturato per il sistema gestionale delle risorse e compagnie e in seguito sono state aggiunte nuove entità perchè necessarie ad alcune funzionalità.

In figura 7.1 si può vederne la struttura rappresentata mediante un diagramma Entity-Relationship.

7.2

Sistema gestionale delle risorse

Tutto ciò che concerne la gestione delle compagnie e dei sensori richiede un sistema in gra-do di mantenere tutte le informazioni e renderle disponibili all’utente in maniera semplificata, dandogli la possibilità di potersi interfacciare e di utilizzarle come meglio ritiene.

Le differenti pagine sono state realizzate con comuni tecnologie web, HTML, CSS e Java-script per animarle o mostrare contenuti differenti a seconda del comportamento dell’utente. Come anticipato al capitolo 4.2, lo scheletro della GUI è stato ricavato prendendo spunto da un layout fornito dalla piattaforma Colorlib, ma esso è stato adattato nel contesto del progetto ed è stato scomoposto in componenti sottoforma di fragment che poi vengono dinamicamente renderizzati nelle pagine da Thymeleaf.

Figura 7.2: Fragment del banner di intestazione all’interno della pagina di master HTML

Esse infatti sono accomunate da molte parti comuni (es. intestazione, navbar, banner) e utilizzano spesso gli stessi fogli di stile o di Javascript, quindi il template engine riduce notevolmente le porzioni di codice all’interno di ogni file .html.

Il layout utilizzato si appoggia internamente a differenti librerie e tra queste anche JQuery. Per questo motivo si è deciso di utilizzare più comodamente Ajax sull’oggetto jQuery per effettuare le chiamate asincrone.

inserire all’interno dell’applicazione web per consentirgli l’utilizzo dell’intero sistema.

Figura 7.3: Interfaccia di creazione di una nuova compagnia

Questa operazione viene fornita sottoforma di registrazione di un’utente, come spiegato nel capitolo 5.1.1, ma richiede delle operazioni aggiuntive all’interno del Controller nel momento in cui deve venir aggiunta la nuova compagnia.

26 Implementazione e funzionamento

Figura 7.4: Funzione del Service di aggiunta di una nuova compagnia

Si può vedere dal codice che il processo di aggiunta di un nuovo cliente prevede il con-trollo iniziale dell’esistenza di un’azienda con lo stesso nome (condizione non permessa) e successivamente la generazione di una password temporanea e di un token, che vengono inviati tramite email al referente della compagnia.

La password verrà criptata e inserita insieme alla compagnia, poi può venir cambiata una volta che avviene il login.

Le compagnie una volta registrate possono essere visualizzate sottoforma di tabella e da questa sezione è possibile cancellarle o gestirle. Se si sceglie la seconda opzione ci si riporta ad una apposita pagina in cui si può decidere se assegnare o rimuovere dei sensori.

.js che ricava dal Controller del server gli array contententi i sensori da aggiungere e rimuo-vere, per consentire il completamento degli identificativi man mano che l’amministratore ne digita delle parti.

Figura 7.6: Sezione di script interni alla pagina .html che gestisce i sensori per la compagnia

Lato Javascript vengono creati dinamicamente dei div in cui sono contenuti gli ID dei di-spositivi e catturati gli eventi di alcuni tasti. Ciò consente di evidenziare le righe in cui ci si sposta quando si premono le freccie ’su’ e ’giù’ e confermare i sensori selezionati al press di ’invio’. A questo punto i sensori scelti vengono aggiunti sottoforma di checkbox in maniera tale che se ne è stato selezionato uno per sbaglio è possibile rimuoverlo semplicemente togliendo la spunta.

7.2.2

Gestione dei dipendenti

Nel momento in cui viene creato il cliente da parte dell’amministratore, esso ottiene automa-ticamente un account sottoforma di utente, dove lo username è l’indirizzo mail della persona referente della compagnia e la password è quella temporanea invitata allo stesso indirizzo (può essere poi modificata).

Insieme alla password, come spiegato nel capitolo 7.1.1, viene inviato un token che serve per permettere anche ai dipendenti dell’azienda di potersi registrare sulla piattaforma. Essi infatti possono registrarsi come dei normali utenti, ma specificando questo token vengono associati alla loro compagnia di appartenenza per fare in modo che non possano avere ac-cesso a risorse che non gli appartengono. Senza il token o con uno non corretto il proac-cesso di registrazione non può avvenire.

28 Implementazione e funzionamento

7.2.3

Autogestione del cliente

Una volta registrato il cliente (in questa versione anche i suoi dipendenti) e assegnati dal-l’amministratore i sensori a disposizione, egli ha accesso a una serie di funzionalità che lo rende autonomo nel gestire le sue risorse.

Quando nella realtà viene avviato un nuovo cantiere, esso deve essere registrato all’interno della piattaforma specificandone un nome identificativo e la posizione esatta. Per questa operazione sono state utilizzate le API di Google Maps che consentono una localizzazione accurata e un indirizzo formattato, ottenendo dalla console di Google Cloud Platform nella sezione "API" una chiave che va usata nell’import dello script all’interno del file .html.

Figura 7.7: Form di aggiunta di un nuovo cantiere

L’utente inserisce l’indirizzo specificando la città e la via e automaticamente premendo l’ap-posito bottone viene riportato sulla mappa un marker alla posizione esatta. Dal momento che una nuova costruzione potrebbe non avere ancora un numero civico, è stata codificata la funzionalità che permette di spostare il marker a proprio piacimento nell’esatta posizio-ne in cui deve avvenire la costruzioposizio-ne. Se questo punto ha un indirizzo civico allora esso verrà mostrato nel apposito input box sopra la mappa per poi essere submittato, altrimenti

Figura 7.8: Metodo per inizializzazione della mappa e del marker

Il metodo sopra viene invocato al click sul bottone ’ok’ all’interno dell’interfaccia e permette il posizionamento della mappa, specificando inoltre che il marker può essere trascinato. Successivamente salva le coordinate ricavate e invoca la funzione in figura 7.8.

Figura 7.9: Metodo per trascinamento del marker

Questa pone un listener sul rilascio del marker dopo il dragging, che aggiorna l’indirizzo formattato e salva le coordinate esatte.

Il passo seguente la registrazione del cantiere è l’aggiunta delle sezioni di cui sarà compo-sto. Per l’operazione sono richiesti il nome (es. 1° piano, 2° piano, etc..) e un’immagine della rispettiva planimetria. Ciò è necessario per poter geolocalizzare i sensori all’interno dell’edificio, visto che essi non dispongono di un’antenna GPS per motivi energetici.

30 Implementazione e funzionamento

Figura 7.10: Aggiunta o modifica di sezioni al cantiere con caricamento planimetria

In questa sezione vengono caricati dei file di tipo immagine e sono gestiti lato server co-me dei MultipartFile per essere salvati sul filesystem secondo un percorso definito dalla seguente struttura: Planimetries/nomeCompangia/nomeCantiere/nomeSezione. Viene in-fatti memorizzato solamente il riferimento all’immagine in modo tale che la visualizzazione front-end non debba aspettare una risposta pesante dal database, bensì il server fornirà il percorso da cui andare a scaricare la planimetria e ciò avverrà con una richiesta http. Nella sezione 7.1.4 viene illustrato l’effettivo utilizzo dei sensori, che può essere effettuato dopo aver compiuto le operazioni sopra citate.

7.2.4

Gestione sensori

All’interno di questo progetto i sensori coinvolgono più entità, in quanto il loro utilizzo è fondamentale per le compagnie esterne, ma richiede una gestione anche da parte del com-mittente.

Uno degli oneri dell’amministratore è quello di inserire i sensori all’interno del sistema, spe-cificando l’identificativo che deve corrispondere con quello reale inserito all’interno di Swis-scom e per questo motivo è stata creata una pagina dedicata.

Va quindi specificato l’ID di ogni dispositivo ed essi saranno aggiunti sottoforma di tabella, mantenendo un checkbox per poterli rimuovere facilmente prima ancora di inserirli all’inter-no del database.

Una volta confermata l’operazione essi saranno inviati al server e memorizzati, controllando che non vengano inseriti dei sensori doppi e allo stesso tempo che questa nuova aggiun-ta non vada a sovrascrivere i dati di quelli già esistenti, se per sbaglio viene specificato lo stesso ID.

Figura 7.11: Interfaccia di aggiunta di sensori al sistema

Per quanto riguarda invece l’utilizzo da parte dei clienti le funzionalità implementate sono multiple, ma l’utente è tenuto solamente a posizionarli all’interno delle planimetrie trasci-nandoli nelle aree equivalenti a quelle nella sezione reale del cantiere. Una volta posizionati viene richiesto di specificare la soglia di umidità su ogni sensore e, quando questa scenderà sotto al limite, scatterà l’allarme che fa partire delle email automatiche verso il referente del-la compagnia e i suoi dipendenti. Qui viene specificato quale sezione del cantiere è pronta e tramite un link si viene rimandati direttamente sulla pagina informativa del cantiere. In questo modo essi saranno informati che potranno procedere nei lavori con la successiva gettata.

32 Implementazione e funzionamento

La pagina come si può vedere dalla figura 7.7 è composta dall’immagine della planimetria e subito sotto dalla lista degli ID dei sensori disponibili. Per permettere ai sensori di essere trascinati nella posizione giusta è stata utilizzata la libreria InteractJS la quale mette a dispo-sizione una comoda gestione degli eventi di tipo drag and drop. In questo caso sono stati utilizzati i listener dello start per prendere le coordinate iniziali del dispositivo, del movimen-to per spostare graficamente il sensore e della fine per prendere lo spostamenmovimen-to relativo al momento del rilascio del mouse, convertirlo e inviarlo automaticamente al server.

Viene poi aggiunta una riga nella tabella che consente all’utente di specificare la soglia del-l’umidità per il relativo sensore.

Dal momento che la libreria fornisce solamente dei dati relativi alla posizione di partenza del sensore, le coordinate che vengono salvate sono ottenute da una conversione dello sposta-mento tenendo conto delle dimensioni dell’immagine, ricavandone un valore percentuale per l’asse x e y. In questo modo anche sui dispositivi mobile o su schermi con dimensio-ni diversi non ci saranno problemi di inconsistenza sia durante la fase di disposizione, sia durante quella di ricaricamento dei sensori.

7.3

Visualizzazione informazioni

Per permettere una più facile gestione sia per l’amministratore sia per i clienti, è stato im-plementato un sistema che semplifica la visualizzazione delle risorse generali, andando a creare una dashboard personalizzata a seconda del ruolo (spiegata al capitolo 5.4).

Gli elementi della dashboard sono creati utilizzando l’omonima libreria dashboard di Boo-tstrap. I primi in alto sono ottenuti dal server side rendering, mentre i grafici vengono creati dinamicamente al caricamento della pagina utilizzando Ajax per ricavare i dati dal server in maniera asincrona e ChartJS per disegnarli.

I componenti sono cliccabili e portano a pagine con informazioni più precise a seconda del contesto.

Per gestire i dati di più entità (es. n compangie) viene impiegato l’utilizzo di tabelle che sono renderizzate sfruttando i loop di Thymeleaf.

Si può entrare ancora più nel dettaglio per quanto riguarda i sensori. Per monitorare in maniera più efficace l’andamento nel tempo della trasmissione dei dispositivi è stata creata una sezione che mette a disposizione dei grafici specifici per i rilevamenti di temperatura, umidità e livello di batteria, anch’essi implementati con ChartJS.

34 Implementazione e funzionamento

Visto che i dispositivi una volta utilizzati possono essere spostati o posizionati nella succes-siva gettata, le informazioni precedenti a questo spostamento non devono essere visualiz-zate e di conseguenza è stato aggiunto un attributo nell’entità sensor_info che specifica se questo dato è di un sensore in uso oppure no.

7.4

Gestione mappature per controllo di sicurezza

All’inizio dello sviluppo l’applicazione web era pensata come un intero nuovo sito per l’azien-da committente, per questo motivo è stata creata una sezione aperta a tutti in cui si possono vedere delle aree informative grafiche sulla compagnia, sul prodotto, sul team e dei moduli di contatto. Questa però è rimasta con immagini e testi di prova (lorem impsum) in quanto successivamente è emerso che la piattaforma sarebbe diventata una parte del sito web già esistente di Synovatec.

Le funzionalità offerte quindi, a parte la home generale sopra citata, sono ristrette ai soli amministratore e clienti e per questo motivo tutte le pagine sono state mappate nel control-ler con una formattazione definita per gestirne la sicurezza più semplicemente con Spring Security. Alcuni endpoint inizieranno con /admin e /company rispettivamente per consentire unicamente l’accesso o all’amministratore o alla compagnia esterna, mentre altri con il loro nome di scopo. Tramite la configurazione nel file WebSecurityConfig vengono controllati inoltre i ruoli e se è avvenuta l’autenticazione per gli endpoint senza la formattazione sopra illustrata.

Viene infine verificato tramite l’aggiunta della classe CustomAuthenticationSuccessHand-ler il ruolo dell’utente in fase di login per rimandarlo verso la pagina corretta, nel caso dell’applicazione web in questione verso la giusta dashboard.

7.5

Docker e Google Cloud

Per rendere il deploy dell’applicazione più scalabile e versatile è stato utilizzato il progetto open source Docker.

All’interno del progetto sono stati quindi aggiunti dei file per consentire la containerizzazio-ne dell’applicaziocontainerizzazio-ne. Tra questi troviamo il Dockerfile in cui sono specificati i parametri per creare l’immagine nell’ambiente virtuale, successivamente il docker-compose che serve per mettere in comunicazione gli ambienti isolati tra di loro (in questo caso il backend con my-sql).

A questo punto si utilizza il comando docker-compose build per creare l’effettivo container, il quale deve essere poi successivamente taggato e pushato su un repository remoto, è stato scelto Docker Hub. Collegato a questo account va creato in seguito un secret per il succes-sivo utilizzo nel deploy.

un pool di Compute Engine VM instances 1 _{che fanno girare Kubernetes. Esiste un tool,}

kompose 2, in grado di convertire il file docker-compose.yml precedentemente creato, in sintassi Kubernetes (vengono creati numerosi files .yaml che poi sono stati condensati in due: deploy.yaml e claim.yaml, contenente il claim di archiviazione e il secret per collegarsi alla repository privata nella successiva fase di creazione dei pod).

I file .yaml creati vanno caricati sul cluster di Google e tramite il comando kubectl create –save-config vengono create le configurazioni attuali e, se modificate alcune, ricaricate solo le nuove modifiche con kubectl apply.

Figura 7.15: Google Cloud Console che mostra i servizi di frontend e backend attivi

Se le configurazioni sono corrette e se è stato specificato un Load Balancer, l’applicazione web sarà funzionante ed esposta su un indirizzo IP pubblico, in questo caso 35.202.70.125.

7.6

Test

Per garantire la consistenza delle modifiche e delle aggiunte durante il periodo di sviluppo, a seguito dell’implementazione di ogni funzionalità veniva codificato il rispettivo test.

1_{https://cloud.google.com/compute} 2

36 Implementazione e funzionamento

Figura 7.16: Esempio test dell’aggiunta di un nuovo cliente

Si è scelto di testare il sistema evitando l’utilizzo intensivo dei Mock e orientandosi verso un approcio più realistico. È stato deciso di utilizzare un database nella memoria RAM della macchina durante l’esecuzione di questi test: così facendo l’ambiente di test rimane isolato da quello di produzione, permettendo di inserire o cancellare dei dati senza alterare il reale database.

Come si può vedere in figura 7.15 alcuni oggetti necessitano comunque di essere mockati. In particolare in questo esempio viene testata la creazione di una nuova compagnia esterna e questa operazione nella realtà prevede la generazione di un token casuale e l’invio auto-matico di una email. Dal momento che il valore del token deve essere noto per i successivi metodi di test, l’oggetto che lo genera viene mockato e lo stesso trattamento viene fatto per quello incaricato di preparare la mail e inviarla perchè non è efficiente lasciar partire delle email ogni volta che girano i test.

Capitolo 8

Sviluppo futuro

L’applicazione web creata rappresenta una delle parti fondamentali dell’intero progetto IOT in quanto permette l’effettiva gestione delle risorse e quindi l’impiego nel mercato della nuo-va idea brevettata. Questa parte però è ancora scollegata da quella hardware (sensori + antenne), dal momento che la trasmissione di informazioni di alcuni dispositivi di prova in questo momento si ferma sui server di Swisscom, come spiegato nel capitolo 5.2.2.

Uno dei prossimi passi deve essere quindi la redirezione dei dati trasmessi verso un end-point all’interno del server che gestisce l’applicazione web.

Dall’incontro con il committente non sono emerse ulteriori richieste oltre alle funzionalità che sono state implementate, ma visto che il progetto è una realtà appena nata possono essere aggiunte nuove features:

• Aggiunta per l’amministratore di un collegamento diretto a Swisscom in fase di inseri-mento nel sistema dei nuovi sensori.

• Verificare ad ogni arrivo di informazione dei sensori il bollettino meteo, per cercare un collegamento tra le condizioni meteorologiche e il livello di umidità del cemento. • Creazione di una gerarchia all’interno dei clienti più profonda rispetto a quella attuale

(persona di riferimento della compagnia e dipendenti), in modo da fornire diversi livelli di accesso alle risorse.

Capitolo 9

Conclusione

Al termine delle 14 settimane di lavoro viene svolta un’analisi del lavoro svolto durante il progetto, come previsto dalla metodologia di lavoro, in modo da identificare gli obiettivi rag-giunti, le criticità riscontrate e definire le features implementabili nel futuro prossimo del progetto (illustrate al capitolo 8).

9.1

Obiettivi raggiunti

Si può sostenere che gli obiettivi del progetto, costituiti dalle richieste del committente (vedi capitolo 5), siano stati raggiunti con successo e sono attualmente in produzione sui server di Google:

• Piattaforma responsive: il progetto front-end è stato implementato per essere utiliz-zabile in maniera confortevole sia con dispositivi desktop sia con quelli mobile, dal momento che per l’interfaccia grafica sono stati utilizzati componenti di Bootstrap re-sponsive e gestite le dimensioni degli elementi in modo generico/percentuale oppure tenendo conto delle dimensioni dello schermo del dispositivo.

• Sistema di gestione dell’utenza: l’applicazione web consente all’amministratore di ge-stire le proprie risorse in maniera semplice e allo stesso tempo dà alle compagnie esterne e ai loro dipendenti la possibilità di potersi registrare e utilizzare la piatta-forma. Vengono fornite all’amministratore le funzionalità di aggiunta e rimozione dei clienti, con corrispettivo inserimento e assegnamento dei sensori, mentre alle compa-gnie esterne la possibilità di creare e localizzare i cantieri e successivamente impie-garne i dispositivi assegnati per poter essere notificati al raggiungimento di particolari condizioni del cemento.

• Gestione dei sensori: i dispositivi che vengono assegnati ai clienti possono essere facilmente utilizzati per poter contribuire alla semplificazione del lavoro dell’impresa (scopo principale della tecnologia brevettata). Ne viene reso semplice l’inserimento e

40 Conclusione

rimozione nelle sezioni del cantiere e automatico il sistema di allarme ogni qualvolta l’umidità rilevata scende al di sotto di una soglia definita su ciascun sensore.

• Interpretazione informazioni: sebbene il servizio che invia i dati dei sensori sia simula-to, ciò che viene ricevuto è immagazzinato e gestito in maniera realistica. Viene data la possibilità di vedere le informazioni di ogni sensore utilizzando dei grafici specifici per ogni misurazione.

• Dashboard personalizzate: sono state create delle dashboard personalizzate per l’amministratore e i clienti che riassumono visivamente le rispettive risorse per una più semplice gestione. I vari componenti sono inoltre interattivi e permettono all’utente di cliccarli per spostarsi nelle pagine informative più specifiche.

• Export database: solo per l’amministratore è stata data la possibilità di esportare delle informazioni mirate all’interno del DB in maniera completa a seconda del caso: informazioni generiche su tutti i sensori in commercio o più dettagliate con tutti i dati trasmessi dai singoli dispositivi. L’export avviene sottoforma di file .csv, salvabile a piacimento dell’admin per poi essere analizzato.

9.2

Competenze sviluppate

Il progetto di diploma rappresenta un punto importante del percorso di studi perché consen-te di applicare nella pratica quanto imparato duranconsen-te le lezioni.

In particolare, in questo progetto le competenze maggiormente accresciute sono:

• Applicazione dei principi di lavoro propri delle metodologie agili: dall’organizzazione del lavoro in sprint fino alle pratiche di Continuos Integration.

• Conoscenza di nuove tecnologie di deploy come Docker e in parte Kubernetes e gestione della Continuous Integration su un server pubblico esterno (Google Cloud). • Analisi e progettazione di un database MySql in grado di supportare una più crescente

mole di dati.

• Applicazione delle conoscenze di sviluppo relative alle applicazioni web, sia backend sia frontend.

• Lavoro a contatto con un committente di lingua straniera: Alfons viene dalla Svizzera tedesca e durante l’incontro è stato necessario spiegare le funzionalità che si volevano implementare. Per fare ciò è stata utilizzata la lingua inglese perchè conosciuta da entrambi e solo in alcuni casi il tedesco, madrelingua del committente.