Piattaforma raccolta dati per sistema IOT - SYNOVATEC Giussani Luca
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Piattaforma raccolta dati per sistema IOT
- SYNOVATEC
Studente/i Relatore
Giussani Luca Poretti Giacomo
Correlatore
-
Committente
Alfons Knüsel
Corso di laurea Modulo
Ingegneria Informatica Progetto di diploma
Anno
2018-2019
Data
30 agosto 2019
i
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
5.5 Export dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Piattaforma raccolta dati per sistema IOT - SYNOVATEC
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
9.2 Competenze sviluppate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Piattaforma raccolta dati per sistema IOT - SYNOVATEC
iii
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
7.16 Esempio test dell’aggiunta di un nuovo cliente . . . . . . . . . . . . . . . . . . 36
Piattaforma raccolta dati per sistema IOT - SYNOVATEC
iv ELENCO DELLE FIGURE Piattaforma raccolta dati per sistema IOT - SYNOVATEC
1
Capitolo 1
Abstract
Synovatec 1 è 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 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
Link al sito web: https://synovatec.ch/
Piattaforma raccolta dati per sistema IOT - SYNOVATEC
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. Piattaforma raccolta dati per sistema IOT - SYNOVATEC
3 Piattaforma raccolta dati per sistema IOT - SYNOVATEC
4 Progetto assegnato
Capitolo 2
Progetto assegnato
Figura 2.1: Progetto assegnato
Piattaforma raccolta dati per sistema IOT - SYNOVATEC5
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 Google 1 .
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
https://console.cloud.google.com
Piattaforma raccolta dati per sistema IOT - SYNOVATEC6 Introduzione Piattaforma raccolta dati per sistema IOT - SYNOVATEC
7
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 come HTML e CSS
per la creazione di pagine e template con Thymeleaf, per ottenere delle pagine costruite
dinamicamente dal server. Il layout grafico della GUI è stato preso da Colorlib 1 ed è 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-
2 3
ne e gestione delle mappe, ChartJS per i grafici e InteractJS 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
https://interactjs.io/
Piattaforma raccolta dati per sistema IOT - SYNOVATEC8 Tecnologie e metodologie utilizzate
4.3 Google Cloud Platform
Google fornisce una suite di cloud 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’è anche Kubernetes 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 è il Load 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 Hub 4 . 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
https://hub.docker.com
Piattaforma raccolta dati per sistema IOT - SYNOVATEC9
4.5 Git & GitHub
Per lo sviluppo dell’applicazione web si è deciso di utilizzare come sistema di versioning il
software Git e di ospitare il codice sulla piattaforma GitHub 5 .
Grazie a questa tecnologia è stato possibile creare dei rami di sviluppo secondari specifici
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
https://github.com
Piattaforma raccolta dati per sistema IOT - SYNOVATEC10 Tecnologie e metodologie utilizzate
Sopra a questo livello fisico giace il LoRaWAN 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 agile SCRUM. 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 Trello 6 .
Vedi approfondimento al capitolo 6.
6
trello.com
Piattaforma raccolta dati per sistema IOT - SYNOVATEC11
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.
Piattaforma raccolta dati per sistema IOT - SYNOVATEC12 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 interessata 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. Uno degli scopi del progetto è infatti fare in modo che, una volta acquistati o noleggiati Piattaforma raccolta dati per sistema IOT - SYNOVATEC
13
i sensori, le compagnie esterne possano utilizzarli nella maniera più consona per le loro
esigenze.
5.2.1 Progettazione
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.
Figura 5.2: Dispositivo di conversione e trasmissione delle informazioni rilevate
Piattaforma raccolta dati per sistema IOT - SYNOVATEC14 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
ThingPark 1 .
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
https://portal.lpn.swisscom.ch
Piattaforma raccolta dati per sistema IOT - SYNOVATEC15
2
quale chiave viene implicata per la codifica del pacchetto e quindi non è tuttora possibile
la decodifica.
L’invio delle informazioni del sensore sarà simulato con un apposito servizio e indirizzato
verso un endpoint mappato nel server.
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
Utilizzando l’algoritmo AES-128
Piattaforma raccolta dati per sistema IOT - SYNOVATEC16 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.
Piattaforma raccolta dati per sistema IOT - SYNOVATEC17
Solo per l’amministratore infine viene predisposto in fondo alla pagina un sistema per espor-
tare i dati presenti nel database.
5.4.2 Personalizzata per il cliente
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’interno 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.
Piattaforma raccolta dati per sistema IOT - SYNOVATEC18 Analisi dei requisiti Piattaforma raccolta dati per sistema IOT - SYNOVATEC
19
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 raggiungere 1 :
1
Gli obiettivi di sprint sono stati definiti ad ogni sprint e non all’inizio del progetto
Piattaforma raccolta dati per sistema IOT - SYNOVATEC20 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
6.1.2 Contenuti degli sprint
Piattaforma raccolta dati per sistema IOT - SYNOVATEC21 Piattaforma raccolta dati per sistema IOT - SYNOVATEC
22 Organizzazione del lavoro Piattaforma raccolta dati per sistema IOT - SYNOVATEC
23
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
Figura 7.1: Diagramma ER del database creato
Piattaforma raccolta dati per sistema IOT - SYNOVATEC24 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. Piattaforma raccolta dati per sistema IOT - SYNOVATEC
25
7.2.1 Amministrazione delle compagnie esterne
L’amministratore dopo aver stretto un contratto con i suoi clienti ha la necessità di doverli
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.
Piattaforma raccolta dati per sistema IOT - SYNOVATEC26 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.
Figura 7.5: Assegnamento sensori con sistema di autocompletamento
Piattaforma raccolta dati per sistema IOT - SYNOVATEC27
Dal momento che la quantità di vendita di questi dispositivi ed un eventuale ritorno alla casa
produttrice può essere molto modesta, l’amministratore nella procedura di aggiunta o rimo-
zione è agevolato da un sistema di autocompletamento (vedi figura 7.4) che lo guida verso
la ricerca dell’identificativo esatto.
Questa funzionalità è stata ottenuta creando un metodo globale all’interno di un apposito file
.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 processo
di registrazione non può avvenire.
In aggiunta viene controllato che non venga inserito un nome utente già nel sistema.
Piattaforma raccolta dati per sistema IOT - SYNOVATEC28 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 costruzione. Se questo punto ha un indirizzo civico allora esso
verrà mostrato nel apposito input box sopra la mappa per poi essere submittato, altrimenti
Piattaforma raccolta dati per sistema IOT - SYNOVATEC29
verranno inviate solamente le coordinate precise al server (ma sufficienti per geolocalizzare
un cantiere).
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.
Piattaforma raccolta dati per sistema IOT - SYNOVATEC30 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.
Piattaforma raccolta dati per sistema IOT - SYNOVATEC31
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.
Figura 7.12: Posizionamento dei sensori all’interno della planimetria
Piattaforma raccolta dati per sistema IOT - SYNOVATEC32 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 spostamento 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).
Figura 7.13: Dashboard dell’amministratore
Piattaforma raccolta dati per sistema IOT - SYNOVATEC33
In figura si può notare anche un bottone di export dei log files, ma questa funzionalità è
disponibile solo all’amministratore ed è stata codificata incaricando il server di generare i
file .csv e di posizionarli all’interno del file system. Con JavaScript a questo punto vengono
aggiunte le icone di download dei file, i quali hanno il riferimento al percorso sul server e
quindi basterà cliccarci sopra per avviare la procedura di download.
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.
Figura 7.14: Visualizzazione delle informazioni specifiche di un sensore
Piattaforma raccolta dati per sistema IOT - SYNOVATEC34 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’applicazione. 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. Google Cloud Platform offre tra numerosi servizi anche il Kubernetes Engine, per questo Piattaforma raccolta dati per sistema IOT - SYNOVATEC
35
motivo si è deciso di registrarsi alla piattaforma (inizialmente con l’indirizzo mail personale
e in seguito con uno appositamente creato per Synovatec) e aprire un account di fatturazio-
ne per poter ricevere i 300$ omaggio che sono tuttora utilizzati per far girare l’applicazione
web.
La prima operazione da fare a questo è creare un container cluster, il quale consiste in
1
un pool di Compute Engine VM instances che fanno girare Kubernetes. Esiste un tool,
2
kompose , 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
http://kompose.io
Piattaforma raccolta dati per sistema IOT - SYNOVATEC36 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.
Piattaforma raccolta dati per sistema IOT - SYNOVATEC37
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.
Piattaforma raccolta dati per sistema IOT - SYNOVATECPuoi anche leggere
