• Non ci sono risultati.

SAD – Smart Ambulance Detection

N/A
N/A
Protected

Academic year: 2021

Condividi "SAD – Smart Ambulance Detection"

Copied!
63
0
0

Testo completo

(1)

Studente

Luciano da Silva Moreira

Relatore

Andrea Baldassari

Correlatore

Giacomo Poretti

Committente

Premel SA

Corso di laurea

Ingegneria Informatica

Modulo

M00002 Lavoro di Diploma

Anno

2019

Data

(2)
(3)

Indice

1 Abstract 1 1.1 Italiano . . . 1 1.2 Inglese . . . 1 2 Introduzione 3 3 Analisi 5 3.1 Progetto di studio assegnato . . . 5

3.1.1 Compiti . . . 6 3.1.2 Obbiettivi . . . 6 3.1.3 Tecnologie . . . 6 3.1.4 Contatto esterno . . . 6 3.2 Contesto . . . 6 3.3 Utilizzatori . . . 6 3.4 Requisiti . . . 7 3.4.1 Requisiti Hardware . . . 7 3.5 Situazione attuale . . . 7 3.5.1 Funzionamento . . . 7 3.5.1.1 JUCE . . . 7 3.5.1.2 POMA . . . 7

3.5.1.3 Visione artificiale OpenCV . . . 8

3.5.2 Analisi delle limitazioni . . . 8

3.5.3 Integrazione nel nuovo sistema . . . 8

4 Ricerca di soluzioni 9 4.1 Disponibilità dei dati . . . 9

4.2 Schema di funzionamento . . . 9

4.3 Attori . . . 10

4.3.1 Admin . . . 10

4.3.2 User . . . 10

(4)

ii INDICE

4.4 Diagramma Use Case . . . 11

4.4.1 Gestione del Sistema . . . 11

4.4.2 Gestione dei Detectors . . . 11

4.4.3 Invio dei dati . . . 12

4.5 Diagramma Sequenza . . . 12

4.5.1 Invio di dati dal Detector al Server . . . 12

4.5.2 Definizione dei parametri di un Detector . . . 13

4.6 Tecnologie utilizzate . . . 14

4.6.1 C++ . . . 14

4.6.2 Java Spring Framework . . . 14

4.6.2.1 Spring Boot . . . 14 4.6.2.2 Javascript . . . 15 4.6.2.3 HTML5 . . . 15 4.6.3 Basi di dati . . . 15 4.6.4 Hardware . . . 15 4.6.4.1 Raspberry Pi 3 . . . 15 4.6.4.2 Microfono . . . 16 4.6.4.3 Videocamera . . . 16 4.6.5 Strumenti di sviluppo . . . 17

4.6.5.1 Intellij IDEA Ultimate . . . 17

4.6.5.2 Code::Blocks IDE . . . 17

4.6.5.3 Postman . . . 17

4.7 Design / Concezione . . . 18

4.7.1 Database MySQL . . . 18

4.7.1.1 Diagramma Entità-Relazione . . . 18

4.7.1.2 Descrizione tabelle e attributi . . . 18

4.7.2 Pianificazione del lavoro . . . 20

5 Sviluppo 23 5.1 Programma di riconoscimento . . . 23

5.1.1 Audio . . . 23

5.1.1.1 C++ REST SDK . . . 23

5.1.2 Video . . . 23

5.2 SAD Web Application . . . 24

5.2.1 Login e Sicurezza . . . 24

5.2.2 Admin . . . 24

5.2.2.1 Dashboard dell’Admin . . . 25

5.2.2.2 Gestione degli utenti . . . 26

(5)

5.2.3.1 Dashboard . . . 30

5.2.3.2 Detectors . . . 31

5.2.4 Detectors . . . 34

5.2.4.1 Aggiustamenti fatti nel programma originale . . . 35

5.2.5 Data . . . 36

5.2.5.1 Json + Database . . . 36

5.2.5.2 File di Audio e Video . . . 36

5.2.6 Configurazione e Troubleshooting dei dispositivi remoti . . . 36

5.2.6.1 Detectors . . . 37

5.2.6.2 Status del detector . . . 38

5.2.7 Autenticazione JWT . . . 39 6 Test 41 7 Manuale Tecnico 43 7.1 Requisiti . . . 43 7.1.1 Hardware . . . 43 7.1.2 Software . . . 43 7.2 Nuova installazione . . . 44

7.2.1 Copia dei dati . . . 44

7.2.1.1 Raspberry . . . 44

7.2.1.2 Server . . . 45

7.2.2 Creazione e configurazione del database MySQL sul Server . . . 45

7.2.2.1 Installazione di MySQL . . . 45

7.2.2.2 Creazione di Utente e Database . . . 45

7.2.3 Installazione e configutazione di un server FTP . . . 46

7.2.3.1 Installazione di VSFTPD . . . 46

7.2.3.2 Cartella principale per il salvataggio dei files . . . 46

7.2.3.3 Creazione di un utente per Raspberry . . . 46

7.2.3.4 Protezione della cartella principale con permessi . . . 46

7.2.3.5 Configurazione vsftpd . . . 47

7.2.3.6 Test del servizio FTP . . . 47

7.2.4 Esecuzione dell’applicazione . . . 48

7.2.4.1 Programma di riconoscimento . . . 48

7.2.4.2 SAD Web Application . . . 48

8 Conclusioni 49 8.1 Problemi/Opportunità riscontrati . . . 49

(6)
(7)

Elenco delle figure

2.1 Ambulanza . . . 4

4.1 Schema Generale . . . 9

4.2 Use Case per la Gestione del Sistema . . . 11

4.3 Use Case per la Gestione dei Detectors . . . 12

4.4 Use Case per l’invio dei dati . . . 12

4.5 Diagramma Sequenza per l’invio dei dati . . . 13

4.6 Diagramma Sequenza per la definizione dei parametri di un Detector . . . 13

4.7 ER del Database . . . 18

4.8 Analisi e Recupero SW precedenti . . . 20

4.9 Implementazione Web App SAD . . . 20

4.10 Integrazione tra sistema attuale e nuovo SW . . . 21

4.11 Documentazione . . . 21

5.1 Login . . . 24

5.2 Dashboard dell’utente . . . 26

5.3 Gestione degli utenti del sistema . . . 26

5.4 Pagina per l’inserimento di un utente . . . 27

5.5 Pagina per la gestione dei detectors . . . 27

5.6 Pagina per l’inserimento di un detector . . . 28

5.7 Avvertimento dopo l’aggiunta di un detector . . . 28

5.8 Edizione di un detector . . . 29

5.9 Pagina per la gestione di un un utente . . . 29

5.10 Dashboard dell’utente dopo login . . . 30

5.11 Detectors assegnati all’utente . . . 31

5.12 Pagina per l’inserimento dei parametri del detector . . . 32

5.13 Inserimento dei parametri . . . 32

5.14 Modifiche effettuate (Logs) . . . 33

5.15 La notifica di avvertimento scompare . . . 33

5.16 I dati ricevuti dai detector . . . 34

(8)

vi ELENCO DELLE FIGURE

5.18 Definizione dei parametri . . . 37

5.19 Richiesta fatta dai detector . . . 38

5.20 Status dei detector . . . 38

(9)

Elenco delle tabelle

4.1 Specifiche del Raspberry . . . 16

4.2 Tabella Data . . . 19

4.3 Tabella Detector . . . 19

4.4 Tabella Detector_Settings . . . 19

4.5 Tabella Detector_Settings . . . 20

4.6 Tabella User_Detector_List . . . 20

7.1 Specifiche del mio PC personale . . . 43

(10)
(11)

Capitolo 1

Abstract

1.1

Italiano

Durante un’emergenza medica è importante che i servizi medici siano capaci di muoversi ed arrivare sul luogo il più velocemente possibile. Per questa ragione i veicoli di emergenza hanno dei colori e delle caratteristiche per farsi identificare. Essi sono dotati di sirene e luci brillanti per richiamare l’attenzione. La legge di transito obbliga gli autisti ad accostare e a dare la precedenza ai veicoli di emergenza, sia a quelli della polizia sia ad ambulanze, vei-coli medicali ed altri. Un minuto può fare una grande differenza durante un’emergenza. Per questa ragione la possibilità che un semaforo sia capace di identificare questa tipologia di veicoli e diventare automaticamente verde, bloccando il resto del traffico, può essere molto utile.

Il presente progetto si prefigge l’obiettivo di integrare e sviluppare un’applicazione web so-fisticata con la quale, gli operatori che si occupano del settore interessato, sono in grado di gestire e manipolare i sensori disponibili al riconoscimento, controllando il traffico.

1.2

Inglese

During a medical emergency it is important that medical services are able to move and get to the site as quickly as possible. For this reason, emergency vehicles have colors and characteristics to identify themselves. They are equipped with sirens and bright lights to draw attention. The transit law requires drivers to pull over and give priority to emergency vehicles, both those of the police, ambulances, medical vehicles and others. A minute can make a big difference during an emergency. For this reason the possibility that a traffic light is able to identify these vehicles and automatically turn green, blocking traffic, can be very useful.

(12)

2 Abstract

The present project’s goal is to integrate and develop a sophisticated Web App in order to offer to the operators dealing with the sector concerned, the possibility of manage and ma-nipulate the sensors available for veicule recognition therefore controlling the traffic.

(13)

Capitolo 2

Introduzione

La vita degli esseri umani è fragile e spesso ci si trova confrontati con imprevisti e situazioni in cui si è chiamati a intervenire con rapidità. Questo è particolarmente vero per quanto riguarda il lavoro dei soccorritori di primo intervento, i primi a dover intervenire quando avviene un incidente o quando una persona si trova in difficoltà. L’operato dei soccorritori è quindi di fondamentale importanza e la sopravvivenza delle persone può dipendere dalle tempistiche con cui vengono curate e portate in ospedale. Per questo motivo le ambulanze, a livello di transito stradale, oltre ad avere una sirena e colori brillanti, hanno la precedenza rispetto a altri veicoli. Questo, però, purtroppo non sempre è sufficiente a consentirgli di avere la strada libera. Se i semafori potessero rilevare la presenza di un’ambulanza o di un veicolo di emergenza, diventando immediatamente verdi dopo il rilevamento e bloccando il resto del traffico, si guadagnerebbero infatti minuti preziosi.

Il progetto presentato in questa tesi nasce da queste riflessioni, dalla volontà di fornire un supporto utile agli operatori di primo soccorso e dal progetto “Intelliphore. Controllo intelligente di hub semaforici” del Signor Matteo Besenzoni, che per primo si è interrogato su questi aspetti. Il mio lavoro consiste infatti nello sviluppo e nell’implementazione del progetto del Signor Matteo Besenzoni riguardante la creazione di un dispositivo in grado di rilevare e “riconoscere veicoli stradali prioritari per mezzo di segnali audio e video, e di notificare il sistema di semafori su cui è installato, facilitando così il transito dei mezzi”. L’idea di Besenzoni è stata quella di sviluppare un dispositivo di monitoraggio – formato da un Raspberry, un computer molto piccolo, collegato a un microfono e a una videocamera – e un software da cui ricavare dati per rendere possibile l’identificazione di un’ambulanza attraverso audio e immagini. Questo doppio canale audio/immagine è stato concepito per evitare il più possibile le probabilità di errore, eliminando o almeno riducendo i falsi casi di identificazione positiva di un’ambulanza.

Trovando interessante e utile il progetto, ho cercato di intuirne le possibilità di sviluppo e i margini di miglioramento. Uno degli aspetti più importanti da implementare era sicuramente quello relativo alla trasmissione dei dati. I dati rimanevano infatti all’interno del Raspberry

(14)

4 Introduzione

e non venivano inviati a un server. In questo modo era possibile capire se i dati erano stati rilevati dal dispositivo e era possibile visionarli solo attaccando uno schermo direttamente al dispositivo Raspberry.

Lo scopo del progetto presentato in questa tesi è dunque quello di creare un sistema in grado di accedere a questi dati audio e immagine, di trasmetterli a un server esterno e di rappresentarli in maniera intuitiva, efficace e funzionale. Ho dunque sviluppato un sistema capace di raccogliere i dati messi a disposizione dai sensori e un’applicazione web attraver-so cui rappresentarli. In questo modo dovrebbe essere dunque possibile fornire al server e agli utenti dati in tempo reale relativi al rilevamento di un’ambulanza così da poter gestire al meglio la circolazione stradale e permettere alle ambulanze e ai soccorritori di gestire meglio le tempistiche di pronto intervento.

In queste pagine, dopo aver passato in rassegna le tecnologie utilizzate per lo sviluppo del software, e aver descritto la situazione di partenza, vengono analizzate le varie fasi dello sviluppo dell’applicazione web e le soluzioni adottate per implementare il sistema.

(15)

Capitolo 3

Analisi

3.1

Progetto di studio assegnato

Persone coinvolte

Proponente Poretti Giacomo Relatore Baldassari Andrea Studente Da Silva Moreira Luciano

Dati generali

Codice C10100

Anno accademico 2018/2019

Semestre Semestre estivo

Corso di laurea Ingegneria informatica (Informatica PAP)

Opzione Nessuna opzione

Tipologia del progetto diploma

Stato in corso

Confidenziale NO

Pubblicabile SI

Descrizione

Il progetto è legato a un brevetto depositato da SUPSI e dall’azienda Premel per lo svilup-po di un sensore per il controllo del traffico e il riconoscimento dei veicoli prioritari. Esso vuole perfezionare una serie di attività svolte negli ultimi anni da parte del nostro Istituto e, in particolare, mira a implementare software e hardware attuali per effettuare installazioni prototipali su impianti semaforici esistenti, inviando nel contempo le misurazioni fatte a un server esterno.

(16)

6 Analisi

3.1.1

Compiti

- adattare il modulo di riconoscimento delle sirene per trasmettere i valori rilevati a un server esterno

- adattare il modulo di riconoscimento lampeggianti per trasmettere i frame interessati a un server esterno

- disegnare un database su server per raccogliere queste informazioni

- sviluppare un software in grado di incrociare visivamente le rilevazioni sirene con le rilevazioni dei lampeggianti

- facilitare la modifica dei parametri per rilevazione di sirene e lampeggianti

3.1.2

Obbiettivi

Recuperare il software attuale da Matteo Besenzoni.

Disporre di un apparecchio per misurazioni esterne in condizioni reali. Produrre una reportistica a supporto del funzionamento del sistema

3.1.3

Tecnologie

Raspberry Pi C++ MySQL Spring Java/Javascript

3.1.4

Contatto esterno

Azienda Premel SA Contatti Christian Tilotta

3.2

Contesto

Questo progetto punta ad essere utilizzato in situazioni d’emergenza, in specifico durante l’intervento delle ambulanze, quando questioni di tempo potrebbero salvare delle vite umane ed evitare l’avvenimento di spiacevoli eventi.

3.3

Utilizzatori

I principali fruitori di questo progetto sono gli addetti alle corse delle ambulanze, che tramite l’applicazione possono rendere nota la loro presenza ai semafori, i quali possono

(17)

diretta-mente fermare gli utenti della strada per rendere il più liscio possibile il primo intervento di soccorso.

L’impatto di questa applicazione è però benevole per l’intera popolazione che a sua insaputa verrà fermata ai semafori rossi sulle strade per permettere il passaggio dei mezzi di soccor-so. Si eviteranno senz’altro situazioni sgradevoli anche per gli automobilisti stessi che non sanno come reagire.

3.4

Requisiti

3.4.1

Requisiti Hardware

• Raspberry preferenzialmente con capacità di connessione a internet integrata. Mo-dello Raspberry 3 Model B o posteriore. Sistema Operativo Linux Based.

• Server con capacità di connettersi e di processare i dati. Il server non deve necessa-riamente possedere molte performance, dal momento che i file json, i file di audio e di immagine risultano abbastanza piccoli.

3.5

Situazione attuale

3.5.1

Funzionamento

Il sistema attuale è composto da due parti principali; una capace di rilevare il suono, svilup-pata con il framework JUCE, ed una che rileva il video, creata con l’ausilio del framework POMA.

3.5.1.1 JUCE

Il Detector rileva il suono di un’ambulanza attraverso dei microfoni collegati ad esso. Per sviluppare il programma che consente ai Detector di rilevare l’audio è stato utilizzato JUCE, un Framework specifico per l’audio e il rilevamento di dati audio.

JUCE è un Framework Opensource che si è rivelato particolarmente funzionale allo scopo e di facile utilizzo.

3.5.1.2 POMA

Poma Pipeline è un framework per la costruzione di pipeline di elaborazione dati costituite da moduli componibili. Il framework Poma è stato sviluppato in seno alla SUPSI dai professori Amos Brocco e Vanni Galli1. POMA è un framework che utilizza la libreria OpenCV, motivo per cui per consentire il riconoscimento visivo, a livello di immagine, da parte dei Detectors

1

(18)

8 Analisi

è stata utilizzata questa libreria. OpenCV è infatti una libreria specifica per il processamento delle immagini.

L’utilizzo di questa libreria è composto da diverse fasi basate su una pipeline che permette di selezionare degli elementi in base a dei criteri prestabiliti. Nella prima fase si utilizza una funzionalità della libreria che permette di prendere in considerazione un pezzo del-l’immagine, mentre nella seconda fase si utilizza un’altra risorsa che consente di lavorare unicamente sui colori. Nella terza fase la libreria permette di focalizzarsi su un unico colore per arrivare infine, nell’ultima fase, a trovare quel determinato colore in una specifica tonalità ricercata.

3.5.1.3 Visione artificiale OpenCV

La Visione Artificiale, anche conosciuta come Computer Vision, è un campo interdisciplinare che studia l’elaborazione per il riconoscimento e trattamento di immagini e video. Essa è una libreria "open source" contenente centinaia di algoritmi per il processamento di immagini.

3.5.2

Analisi delle limitazioni

Una delle limitazioni del sistema attuale è che, anche se esso è in grado di rilevare con una certa precisione la presenza di un’ambulanza attraverso l’audio e video che arrivano al microfono e alla videocamera, è ancora sprovvisto di un sistema per ricevere questi dati e fare l’eventuale debug.

3.5.3

Integrazione nel nuovo sistema

L’integrazione viene svolta adattando il software già sviluppato e caricandolo nel Raspberry, per permettere a quest’ultimo di trasmettere i dati al server.

(19)

Capitolo 4

Ricerca di soluzioni

4.1

Disponibilità dei dati

Il sistema attuale da integrare nel presente nuovo progetto non è predisposto per condivide-re i dati dal dispositivo (detector) al server. Essi sono accessibili, dunque, esclusivamente dallo stesso dispositivo. Per implementare questa funzionalità è stato necessario installare e configurare un server FTP e un’applicazione RESTful.

4.2

Schema di funzionamento

Figura 4.1: Schema Generale

Il funzionamento effettivo del Detector avviene per gradi e si svolge all’insegna della sicu-rezza. Inizialmente il Detector controlla se il server di riferimento è online. Se quest’ultimo è online, il Detector prova a inviare al server la richiesta di un codice di sicurezza in modo da poter accedere all’applicazione web. Una volta ricevuto il codice di sicurezza, il Detector inizia a fare delle richieste al server, che contatta utilizzando il codice di sicurezza, il quale

(20)

10 Ricerca di soluzioni

serve per garantire la legittimità del Detector, che viene così riconosciuto come sicuro dal server. A questo punto il Detector recupera i parametri necessari per svolgere le sue ricer-che e i suoi rilevamenti. Quando è in possesso dei parametri, il Detector inizia a compiere il rilevamento attraverso il microfono e la videocamera di cui è dotato. Il Detector riceve dunque dati audio e video e inizia ad analizzarli in modo da rilevare il passaggio di eventuali ambulanze.

Nel momento in cui rileva la presenza di un’ambulanza, il Detector contatta immediatamente il server utilizzando il codice di sicurezza ricevuto in precedenza e gli invia i dati interessanti rispetto a audio e immagini. Assieme a questi dati, invia inoltre al server sia il codice di Raspberry, in modo che il server sappia il luogo da cui proviene l’informazione, sia l’orario in cui è avvenuto il rilevamento.

Nel momento in cui il server riceve i file, li mette a disposizione degli utenti che hanno i permessi per accedere a questi dati nella sezione “Data” sopracitata.

4.3

Attori

Gli attori di un sistema rappresentano le entità che interagiscono con esso. Nel caso di questo progetto esistono tre attori: admin, user e detectors.

4.3.1

Admin

L’amministratore del sistema SAD è il responsabile della registrazione degli altri attori, Users e Detectors. Inoltre è in grado di stabilire a quali detectors ogni user è autorizzato ad ac-cedere. Agli amministratori è data anche la possibilità di accedere a tutti i dati messi a disposizione dai detectors senza nessuna limitazione.

4.3.2

User

Gli users definiscono le impostazioni dei detectors a essi assegnati per il rilevamento di un’ambulanza. Le due impostazioni che i detector ricevono dagli users sono le frequenze delle sirene e le caratteristiche visive dei veicoli.

Inoltre possono accedere ai dati inviati dai detectors a loro assegnati.

4.3.3

Detector

I detectors sono i dispositivi che rilevano le ambulanze attraverso l’analisi dell’audio cattura-to dal microfono e attraverso l’analisi delle immagini rilevate dalla videocamera.

(21)

4.4

Diagramma Use Case

Il diagramma Use Case mostra come sarà l’utilizzo del sistema da parte degli attori. Il server è alimentato dai dati forniti dai detectors, mentre gli stessi dati sono accessibili dall’Admin e dagli Users.

4.4.1

Gestione del Sistema

Questo Use Case dimostra come l’utente Admin gestisce gli altri attori del Sistema.

Esendo che si ha effettuato il login con utente con i permessi amministrativi si è in grado di editare, cancellare utenti e detector, e, molto importante, definire a quale detector un user é autorizzato ad accedere.

Figura 4.2: Use Case per la Gestione del Sistema

4.4.2

Gestione dei Detectors

L’attore detector é il responsabile per la raccolta dei dati per il sistema.

L’utente definisce i parametri per il rilevamento delle ambulanze, da essere utilizzato dai Detectors che l’utente ha a se assegnato.

(22)

12 Ricerca di soluzioni

Figura 4.3: Use Case per la Gestione dei Detectors

4.4.3

Invio dei dati

Prima di iniziare a funzionare, si effetua una richiesta al server per accedere alle definizioni di rilevamento del sistema.

Questi parametri sonosuccessivamente utilizzati per il rilevamento delle ambulanze.

Figura 4.4: Use Case per l’invio dei dati

4.5

Diagramma Sequenza

4.5.1

Invio di dati dal Detector al Server

Il diagramma di sequenza qui sotto riportato, dimostra in maniera sequenziale la trasmissio-ne di dati dai Detector al Server.

(23)

Figura 4.5: Diagramma Sequenza per l’invio dei dati

4.5.2

Definizione dei parametri di un Detector

Di seguito lo schema sequenziale mostra, come un utente definisce i parametri di un detec-tor a esso assegnato.

(24)

14 Ricerca di soluzioni

4.6

Tecnologie utilizzate

4.6.1

C++

C++ (C con classi) è un linguaggio di programmazione di alto livello per uso generico pode-roso, portabile e popolare. C++ è basato sul linguaggio C, un linguaggio sviluppato a Bell Labs da Dennis Ritchie negli anni di 1972 e 1973, che è servito come modello per lo svilup-po di diversi altri linguaggi di programmazione. C++ è un’ evoluzione di questo linguaggio, a cui sono state inoltre aggiunte diverse risorse trovate nei linguaggi moderni.

Anche se si tratta di un linguaggio di alto livello, il codice generato è portabile e di veloce esecuzione, ossia perfettamente adatto per i sistemi operativi e sistemi embedded, come nel nostro caso.

4.6.2

Java Spring Framework

Spring Framework è una struttura "open source" di programmazione per lo sviluppo di ap-plicazioni sulla piattaforma JAVA. Ideale per la creazione di webapps, questo framework fornisce diversi moduli che possono essere inseriti a dipendenza delle necessità di un progetto.

4.6.2.1 Spring Boot

Gli sviluppatori di Spring Framework mettono a disposizione un creatore di progetti sulla base di Spring Framework capace di impostare, configurare ed eseguire sia applicazioni regolari sia applicazioni web.

(25)

4.6.2.2 Javascript

Javascript è un linguaggio "script" che rende le applicazioni web capaci di interattività. Es-sendo una delle tecnologie principali di internet, parte dell’applicazione è scritta utilizzando JavaScript.

4.6.2.3 HTML5

Le pagine generate dall’applicazione utilizzano lo stardard HTML 5.

4.6.3

Basi di dati

MySQL è un sistema open source di gestione relazionale di databases (RDBMS, relational database management system, in inglese). Si tratta di uno dei RDBMS più usati nel mondo, ed è famoso per la sua robustezza per le applicazioni di medio livello. MySQL offre anche una versione commerciale.

4.6.4

Hardware

(26)

16 Ricerca di soluzioni

Raspberry pi è un computer a scheda singola sviluppato da Raspberry Pi Foundation ed è stato scelto per le sue dimensioni ristrette, per il basso costo ed il basso consumo.

Architettura Cortex-A53 64 bit

Processore Quad core 1.2 GHz

Scheda Grafica VideoCore IV 400Mhz

RAM 1GB DDR2 900MHz

Tabella 4.1: Specifiche del Raspberry

Il modello scelto è dotato di Wifi e Bluetooth 4.1 ed ha una prestazione sufficiente per il lavoro richiesto.

4.6.4.2 Microfono

T.Bone GC 100 USB1

Direzionalità Omnidirezionale

Risposta in frequenza 50 - 20000 Hz

Connettività / Power USB 2.0 con cavo di 15 cm

Dimensioni 5.5cm x 2 cm (Altezza per Base)

4.6.4.3 Videocamera

Raspberry Pi Camera Module V2 USB2

Entrambi i sensori vengono collegati al Raspberry Pi e possono essere posizionati ad un’angolatura più conveniente per la cattura dei dati.

1https://www.tbone-mics.com/en/product/information/details/schwanenhals-tischmikrofon/ 2

(27)

Sensore Sony IMX219 8 megapixel

Risoluzione Immagine fino a 3280 x 2464 pixels

Video 1080p30, 720p60 e 640 x 480p60/90

Dimensioni 25mm x 24mm x 9mm

Campo Visivo Orizzontale 62.2◦

Lunghezza focale 3.04mm

Apertura orizzontale 62.2◦

Apertura verticale 48.8◦

4.6.5

Strumenti di sviluppo

4.6.5.1 Intellij IDEA Ultimate

Intellij IDEA è un Ambiente di Sviluppo Integrato, IDE in inglese, molto popolare creato da Intellij.

4.6.5.2 Code::Blocks IDE

Code Blocks è stato scelto perché è uno strumento di sviluppo veloce, privo di accessori inutili e dunque funzionale agli scopi del progetto. Si tratta inoltre di un’applicazione Open source molto utilizzata che permette un immediato utilizzo.

4.6.5.3 Postman

Postman è uno strumento che permette di mandare e ricevere richieste HTTP. È molto utile nella fase di testing per potersi accertare del giusto comportamento degli endpoint. Durante il progetto è infatti stato utilizato come strumento per i test, facilitando così l’implementazio-ne degli endpoint, dal momento che si potevano testare senza un’interfaccia grafica.

(28)

18 Ricerca di soluzioni

4.7

Design / Concezione

4.7.1

Database MySQL

Il DBMS (DataBase Management System) utilizzato per questo progetto è MySQL, che sfruttando il motore per le tabelle InnoDB tiene in memoria le strutture delle tabelle in formato relazionale.

4.7.1.1 Diagramma Entità-Relazione

Questo diagramma Entità-Relazione dimostra le relazione tra le tabelle e loro dipendenze. Ogni User può accedere a più di un Detector, e ogni Detector può essere accessibile da diversi Utenti.

A cause di questo, é importante che i cambiamenti fatti ai i dati di configurazione possano essere rintracciate all’utente che l’ha fatti.

Figura 4.7: ER del Database

4.7.1.2 Descrizione tabelle e attributi

• Tabella data: questa tabella contiene i dati riguardanti ad ogni rilevamento, ossia, luo-go di origine, Detector che genera il dato, la sua data, e il nome dei file di audio e immagine ricevute.

(29)

PK id integer date Date audio_location String img_location String location String FK detector_id int time_stamp Date

Tabella 4.2: Tabella Data

• Tabella detector: questa tabella contiene i dati di ogni Detector.

PK id integer

alias String

location String

img_location String

is_ready booleanString

Tabella 4.3: Tabella Detector

• Tabella detector_settings: tabella che permette di rintracciare chi ha fatto i cambia-menti sulla configurazione di un Detector.

PK id integer date Date freq1 float freq1_t float freq2 float freq2_t float FK detector_id int FK user_id int

Tabella 4.4: Tabella Detector_Settings

• Tabella user: contiene i dati relaviti agli utenti del sistema. La stringa username viene usata per effettuare il login in combinazione con la password.

(30)

20 Ricerca di soluzioni PK id integer admin boolean email String name String password String username String

Tabella 4.5: Tabella Detector_Settings

• Tabella user_detector_list: questa tabella permette di definire il diritto d’accesso degli utenti ai Detector già registrati.

PK id integer

PK FK detector_id int

PK FK user_id int

Tabella 4.6: Tabella User_Detector_List

4.7.2

Pianificazione del lavoro

Durante i primi passi nel progetto è stata usata la piattaforma scm, messa a disposizione dalla supsi. Purtoppo la pianificazione con questo strumento non ha funzionato particolar-mente bene e ho optato per un altro strumento di pianificazione chiamato Monday. Monday è un tool online per pianificare progetti di gruppo, condividere eventi e strutturare, in gene-rale, dei progetti dall’inizio alla fine. Questo tool mi ha permesso di avere una visione più ampia del da farsi nelle varie settimane.

Figura 4.8: Analisi e Recupero SW precedenti

(31)

Figura 4.10: Integrazione tra sistema attuale e nuovo SW

(32)
(33)

Capitolo 5

Sviluppo

5.1

Programma di riconoscimento

I programmi di riconoscimento sono divisi in due: uno per il riconoscimento dell’audio ed un altro per il riconoscimento delle immagini catturate dalla videocamera.

Per permettere al dispositivo di inviare dei dati al server, sono stati applicati alcuni cambia-menti.

5.1.1

Audio

Il framework JUCE, utilizzato per lo sviluppo del programma di rilevamento, viene espanso con l’aggiunta di una libreria contenente le procedure e funzioni necessarie per il funziona-mento delle nuove implementazioni.

Per il collegamento tra il detector e il server é stata utilizzata la libreria cpprest, disegnata per fornire delle implementazioni rest native alle applicazioni sviluppate in C++.

5.1.1.1 C++ REST SDK

Sviluppato da Microsoft e licenziato con la licenza MIT, questo kit di sviluppo sofware, SDK in inglese, fornisce un insieme di strumenti che permettono la connessione di applicazioni in rete.

Viene utilizzata per sopprimere la mancanza di queste funzionalità in C++.

5.1.2

Video

Per il riconoscimento tramite la cattura del video, é stata utilizzata la libreria OpenCV, che viene utilizzata all’interno di una pipeline, resa possibile con l’utilizzo del strumento POMA.

(34)

24 Sviluppo

5.2

SAD Web Application

5.2.1

Login e Sicurezza

È stato implementato un sistema di login per l’autenticazione degli utenti registrati. Utenti, che a loro volta sono creati da un utente con diritti amministrativi.

Figura 5.1: Login

Esistono tre livelli di sicurezza per accedere e utilizzare la web application, essendo: • Administrator: utente amministratore, capace di accedere a tutti i dati

configurazio-ne del sistema. È l’utente responsabile per l’aggiunta di altri utenti e detectors e la relazione tra essi.

• Users: sono gli utenti che definiscono la configurazione dei detectors e accedono ai dati ricevuti da questi.

• Detectors

5.2.2

Admin

Nell’applicazione si entra con un login in cui si mettono il nome utente e la password; si può scegliere se fare il login come Amministratore o come utente normale (User).

Entrando come Amministratore, l’interfaccia grafica dell’applicazione presenta, in alto a de-stra, un pannello in cui compaiono diverse sezioni ossia Home, Users, Detectors, Data,

(35)

Dropdown.

Nella sezione Users si trovano gli utenti registrati. In questa sezione l’amministratore, at-traverso la funzione “User Registration” può creare nuovi utenti attribuendogli un nome, un nome utente, un indirizzo mail e una password. Oltre ai dati dell’utente (User information) appena citati, l’Amministratore può assegnare a ogni utente un Detector, ossia un rilevatore che raccoglie i dati rilevati. I Detectors attualmente assegnabili agli utenti sono due: Rasp1, che si trova a Manno, e Rasp2, che si trova invece a Lugano.

Nella sezione Detectors sono presenti i diversi rilevatori e il luogo in cui ciascuno di essi si trova. In questa sezione è possibile anche registrare ulteriori Detectors oltre a quelli già presenti.

Nella sezione Data sono visibili e costantemente aggiornati i dati relativi ai rilevamenti dei Detectors. I rilevatori (Detectors) sono infatti dispositivi che comunicano tramite lo stesso server con l’applicazione e raccolgono, in tempo reale, dati audio e fotogrammi (immagini) riguardo alla presenza di ambulanze e veicoli. Se il Detector rileva la presenza di un vei-colo medico, carica i dati sull’applicazione e questi diventano visibili dall’Amministratore e dall’utente o dagli utenti a cui è assegnato quel determinato Detector. Tutti i dati relativi ai rilevamenti dei Detectors vengono dunque raccolti nella sezione Data.

5.2.2.1 Dashboard dell’Admin

Dopo aver fatto il login, viene presentata la pagina dashboard.

La dashboard dell’utente amministrativo permette di settare le alcune configurazione gene-rali del sistema.

(36)

26 Sviluppo

Figura 5.2: Dashboard dell’utente

5.2.2.2 Gestione degli utenti

Questa pagina permette di gestire gli utenti del sistema, permettendo l’aggiunta, cancella-zione e modifica degli stessi.

Figura 5.3: Gestione degli utenti del sistema

Pagina per la aggiunta di un utente. Se viene selezionata l’opzione Amministratore, l’utente avrà gli stessi diritti di Admin.

(37)

Figura 5.4: Pagina per l’inserimento di un utente

Su questa pagina é possibile gestire i detectors, aggiungendoli oppure configurandoli, op-zione però non consigliate per non essere una dalle "best practices".

Figura 5.5: Pagina per la gestione dei detectors

(38)

28 Sviluppo

Figura 5.6: Pagina per l’inserimento di un detector

Dopo aver aggiunto un detector, viene mostrato un segno di notifica che avverte della man-canza della definizione delle sue configurazioni. Anche se con l’utente Admin è possibile definire queste impostazioni, questa pratica non é consigliata per motivi di sicurezza.

Figura 5.7: Avvertimento dopo l’aggiunta di un detector

In questa pagina è possibile modificare il nome e l’alias di un detector. Il nome é utilizzato per identificare un detector.

(39)

L’alias invece può essere usato per facilitare l’identificazione di un detector, traverso di una nomenclatura decisa dai utilizzatori del sistema. Un’opzione sarebbe mettere il luogo in cui il dispositivo si trova al momento.

Figura 5.8: Edizione di un detector

In questa pagina si ha accesso alle informazioni degli utenti dell’applicazione ed è possibile modificarle.

(40)

30 Sviluppo

5.2.3

Users

L’Utente, a differenza dell’Amministratore, può accedere solo ai dati relativi al Detector che gli è stato assegnato dall’Amministratore. Il suo accesso è dunque limitato.

Sotto la sezione Data, l’Utente trova i dati relativi al Detector assegnatogli.

Come spiegato in precedenza, se il Detector rileva un’ambulanza ne registra l’audio e l’im-magine e invia al server i dati, che compaiono poi nella sezione “Data”. Il compito dell’ Utente è, a questo punto, quello di visionare i dati presenti nella sezione “Data” e control-lare che si tratti effettivamente di un’ambulanza e il rilevamento sia dunque esatto. L’utente controlla i dati osservando la registrazione audio e le immagini a sua disposizione.

L’Utente può anche definire la configurazione del Detector ossia il tipo di suono da rilevare (sirena dell’ambulanza o polizia) e i parametri da tenere in considerazione nell’identificazio-ne delle immagini.

5.2.3.1 Dashboard

Dopo aver fatto il login nel sistema, la pagina di dashboard dell’utente appena autenticato viene caricata.

(41)

5.2.3.2 Detectors

I Detectors sono i dispositivi che rilevano dati audio e immagini – scattano fotografie a distan-za ravvicinata - e vanno dunque configurati con i parametri necessari per poter identificare le ambulanze. Nel momento in cui il Detector rileva il suono di un’ambulanza e ne identifica i colori, esso trasmette i dati al server. Prima di inviare questi dati è però necessario, per motivi di sicurezza, che il Detector si identifichi e venga quindi autenticato dall’applicazione. Questa autenticazione viene permessa dalla tecnologia JWT.

Questa sezione permette all’utente di accedere ai detectors a esso assegnati dall’Ammini-stratore del sistema.

Come si può notare, non é stato ancora definito nessun parametro per il funzionamento del detector.

Figura 5.11: Detectors assegnati all’utente

In questa finestra è necessario definire i parametri di funzionamento del detector. Se non è stato ancora inserito alcun parametro, il suo inserimento é obbligatorio.

(42)

32 Sviluppo

Figura 5.12: Pagina per l’inserimento dei parametri del detector

La finestra con i parametri del detector inseriti si presenta nel seguente modo.

Figura 5.13: Inserimento dei parametri

Dal momento che diversi utenti possono accedere ad un detector, é importante che questo sia in grado di rintracciare chi ha applicato le modifiche.

(43)

Figura 5.14: Modifiche effettuate (Logs)

Figura 5.15: La notifica di avvertimento scompare

(44)

34 Sviluppo

Figura 5.16: I dati ricevuti dai detector

5.2.4

Detectors

I detectors non devono eseguire un login, ma necessitano di autenticarsi, in ogni caso, utilizzando altri sistemi.

Attualmente l’autenticazione dei detectors avviene tramite il loro codice nella richiesta.

Come si può vedere in questa simulazione, utilizzando il software "Postman", viene inviata una richiesta con la key "id" e un valore 389. Il programma ci ritorna i dati necessari per il funzionamento del software di riconoscimento di audio.

(45)

Figura 5.17: Dati ricevuti dalla web application

5.2.4.1 Aggiustamenti fatti nel programma originale

Per poter rendere possibile l’invio dei dati dal detector, sono state implementate delle nuove funzionalità, esse sfruttano la libreria esterna creata per questo scopo.

Le procedure per la comunicazione con il server, sono state implementate, con l’utilizzo del cpprest SDK. h t t p _ c l i e n t c l i e n t ( address ) ; auto p o s t v a l u e = j s o n : : v a l u e : : o b j e c t ( ) ; p o s t v a l u e [ " d e t e c t o r I D " ] = j s o n : : v a l u e : : s t r i n g ( d e t e c t o r I D ) ; p o s t v a l u e [ " audioFileName " ] = j s o n : : v a l u e : : s t r i n g ( audioFileName ) ; p o s t v a l u e [ " imageFileName " ] = j s o n : : v a l u e : : s t r i n g ( imageFileName ) ; p o s t v a l u e [ " timestamp " ] = j s o n : : v a l u e : : s t r i n g ( timestamp ) ; c o u t << " \ nPOST ( g e t some v a l u e s ) \ n " ; d i s p l a y _ j s o n ( p o s t v a l u e , "S : " ) ;

make_request ( c l i e n t , methods : : POST, p o s t v a l u e , " / data " ) ;

Il codice precedentemente riportato mostra una richiesta POST per l’invio dei dati in un file json

Per l’invio dei file di audio e video, é stata implementata una procedura che utilizza la libreria curl, grazie a questa scelta é in grado di inviare questi file tramite FTP.

(46)

36 Sviluppo

v o i d sendFTP ( char∗ LOCAL_FILE , char∗ RENAME_FILE_TO ) {

CURL ∗c u r l ; CURLcode r e s ; FILE ∗hd_src ; s t r u c t s t a t f i l e _ i n f o ; c u r l _ o f f _ t f s i z e ; s t r u c t c u r l _ s l i s t ∗h e a d e r l i s t = NULL ;

s t a t i c c o n s t char buf_1 [ ] = "RNFR " UPLOAD_FILE_AS ; char buf_2 [ 1 0 0 ] ;

s t r c p y ( buf_2 , "RNTO " ) ;

s t r c a t ( buf_2 , RENAME_FILE_TO ) ;

5.2.5

Data

I dati sono messi a disposizione per il server in due modi diversi. Tramite l’invio diretto al server Restful. Ed utilizzando il protocollo FTP.

5.2.5.1 Json + Database

I dati che arrivano attraverso l’applicazione sono nel formato Json, ciò permette loro di essere elaborati, interpretato e inseriti nel database MySQL.

Tra questi dati, c’è la data di rilevamento dell’ambulanza, la data di arrivo del dato al server, i nomi del file di audio e immagine da essere recuperati. Questi file non vengono persistiti nel Database.

5.2.5.2 File di Audio e Video

Per lo scambio di dati tra client (Raspberry) e server (da cui poi essi vengono ripresi e rappresentati) si è reso necessario l’utilizzo di un server FTP. I seguenti passaggi mostrano il lavoro svolto per abilitare il funzionamento del servizio.

Come detto prima, i file di audio e d’immagini non vengono inseriti nel database, ma sono invece ricevuti dal server FTP, e immagazzinati all’interno del file system stesso del server.

5.2.6

Configurazione e Troubleshooting dei dispositivi remoti

Per il funzionamento del programma di rilevamento sono necessari alcuni parametri che de-finiscono quale tipo di sirena dev’essere rilevato. Questi parametri sono definiti dagli utenti

(47)

autorizzati a farlo dall’admin.

Figura 5.18: Definizione dei parametri

Dal momento che la relazione tra gli utenti e i detectors é una relazione molti a molti e quindi le modifiche applicabili possono crescere, é necessario un log di chi ha eseguito cambiamenti sui parametri per poterne mantenere un controllo.

5.2.6.1 Detectors

Prima di iniziare l’esecuzione delle routine di rilevamento, il dispositivo invia una richiesta al server che fornisce i parametri necessari per il suo funzionamento.

Una volta che questi parametri vengono ricevuti e utilizzati, il programma fa una richiesta ogni 10 secondi al server. Nel caso del cambiamento di uno dei parametri, questi vengono sostituiti all’interno del dispositivo.

(48)

38 Sviluppo

Figura 5.19: Richiesta fatta dai detector

5.2.6.2 Status del detector

Il server mostra lo status dei detector a seguito delle richieste fatte dai dispositivi e mostra se i loro parametri sono stati definiti.

• Rosso: I parametri del detector non sono ancora stati definiti.

• Giallo: I parametri sono stati definiti ma il detector non ha contattato il server per più di 100 secondi

• Verde: I parametri sono stati definiti ed il detector ha contattato il server negli ultimi 100 secondi

Figura 5.20: Status dei detector

(49)

Figura 5.21: Dati rilevati

5.2.7

Autenticazione JWT

L’autenticazione JWT viene proposta come un modo di garantire l’autenticità dei dati scam-biati tra i detectors e i server.

(50)
(51)

Capitolo 6

Test

Durante lo sviluppo del codice è stato importante vedere subito dei risultati ottenuti, per l’applicazione web c’è stato un riscontro diretto con l’interfaccia che l’utente vede. Testato sui browser:

• Firefox • Chrome

(52)
(53)

Capitolo 7

Manuale Tecnico

Questa sezione è dedicata all’installazione completa del sistema, per permettere ai nuovi utenti di poter installare, configurare e far partire il progetto senza complicazioni.

7.1

Requisiti

7.1.1

Hardware

Per lo svolgimento è stato necessario l’utilizzo di un server. Nel presente progetto è stato usato il mio computer personale con le seguenti caratteristiche:

CARATTERISTICHE

Sistema Operativo Linux Ubuntu 18.04 64 bit

Processore Intel R Core i3-3110M CPU @ 2.40GHz

Scheda Grafica Intel R Ivybridge Mobile

RAM 8GB

Disco SSD 150 GB

Tabella 7.1: Specifiche del mio PC personale

Visto che era stato richiesto l’utilizzo dei dispositivi Raspberry, é stato recuperato il disposi-tivo utilizzato dal Signor Matteo Besenzoni, con le caratteristiche già descritte nella sezione

4.6.4.1.

7.1.2

Software

Per eseguire il programma è necessario installare il software POMA, il quale permette di compilare il progetto. Inoltre, è necessario installare anche il framework JUCE.

(54)

44 Manuale Tecnico

7.2

Nuova installazione

In questa sezione viene documentata l’installazione dell’intero progetto su un nuovo am-biente.

7.2.1

Copia dei dati

I programmi in C++ devono essere copiati all’interno del Raspberry, anche i file per il riconoscimento di audio e anche i file per il riconoscimento dell’immagine.

L’applicazione JAVA viene copiata all’interno del Server. Istruzioni più dettagliati sono di-scusse nelle sezioni seguinti.

7.2.1.1 Raspberry

Sul Raspberry, é necessaria l’installazione del framework JUCE. Bisogna soltanto scaricare il programma dal sito ufficiale,https://juce.com/get-juceed estrarlo.

Poi, si devi aprire l’applicazione Projuce, che si trova all’interno della cartella estratta, con il commando:

. / P r o j u c e r

Poi si accede a File -> Open, e si cerca il file Audio.jucer, che si trova all’interno della cartella Audio, copiata anteriormente.

Sulla finestra aperta, si fa il click su Linux MakeFile, e nel panello a destra si mettono i seguenti parametri:

Extra Preprocessor Definitions FFT_SIZE=128

Extra Linker Flags -lboost_system -lcrypto

-lcpprest

Tabella 7.2: Parametri da inserire

Si salva il progetto, e poi si esegue il commando per compilare il progetto, nella cartella contenente il file Makefile, probabilmente questa cartella avrà il percorso di Audio/Builds/Li-nuxMakeFile:

make

Per eseguirlo:

. / b u i l d / Audio −sp

L’installazione di POMA é abbastanza complessa, e le istruzioni per la sua installazione può essere trovata al seguente link:

(55)

7.2.1.2 Server

Sul server deve essere scaricato il file che contiene il codice Java. Se si utilizza l’IDE Intellij Idea, basta importare il progetto scegliendo l’opzione "Import Maven Project", e poi selezionare il file .pom all’interno della cartella del progetto.

7.2.2

Creazione e configurazione del database MySQL sul Server

7.2.2.1 Installazione di MySQL

Se il DBMS MySQL non ancora installato, si deve eseguire questo commando in un am-biente linux :

sudo a p t i n s t a l l mysql−s e r v e r −y E poi:

sudo s e r v i c e mysql s t a t u s

Se non é in esecuzione, é necessario farlo partire: sudo s e r v i c e mysql s t a r t

E infine:

sudo m y s q l _ s e c u r e _ i n s t a l l a t i o n

Questo comando serve per la configurazione di sicurezza del sistema, questo include la creazione della password dell’utente root.

7.2.2.2 Creazione di Utente e Database

Accedere a MySQL: mysql −u r o o t −p

E poi eseguire i seguenti commandi: CREATE NEW DATABASE sadDB2 ;

CREATE USER ’ userDB ’@’ l o c a l h o s t ’ IDENTIFIED BY ’ password ’ ; GRANT ALL PRIVILEGES ON sadDB2 .∗ TO ’ userDB ’@’ l o c a l h o s t ’ ;

Se non ci sono errori, sarà possibile accedere a MySQL e a vedere il database appena creato:

mysql −u r o o t −p ; show databases ;

(56)

46 Manuale Tecnico

7.2.3

Installazione e configutazione di un server FTP

7.2.3.1 Installazione di VSFTPD

Per installare il server FTP, è stato scaricato e installato vsftpd su Linux: sudo apt−g e t i n s t a l l v s f t p d

Per verificare lo status del server FTP e capire se è in ascolto o se ci sono dei problemi, torna utile il comando:

sudo s e r v i c e v s f t p d s t a t u s

7.2.3.2 Cartella principale per il salvataggio dei files

Per raccogliere i files necessari al rilevamento e alla rappresentazione dei dati, è stata creata una cartella "/data" apposita sul server:

sudo m k di r / data

7.2.3.3 Creazione di un utente per Raspberry

Per proteggere il trasferimento dei files sul server si è reso necessario creare un utente dedicato al Raspberry per permettergli di caricare i dati tramite un’autenticazione:

sudo adduser r a s p u s e r

7.2.3.4 Protezione della cartella principale con permessi

È fondamentale assegnare i corretti permessi alla cartella nella quale verranno salvati i files, sia per evitare eventuali errori di caricamento da parte del programma che per evitare possibili attacchi al sistema. Sono stati applicati i permessi seguenti:

sudo chown nobody : nogroup / data sudo chmod a−w / data

Grazie a questi permessi, la cartella principale "/data" è protetta e nessun utente può accedervi in lettura e scrittura.

Successivamente, si è creata una sottocartella nella quale verranno trasferiti tutti i files: sudo m k di r / data / sad

sudo chown r a s p u s e r : r a s p u s e r / data / sad

È stato reso proprietario l’utente "raspuser" creato appositamente per il Raspberry, in modo che possa avere qualsiasi accesso a partire da quella cartella fino alle proprie sottocartelle.

(57)

7.2.3.5 Configurazione vsftpd

Per garantire il corretto funzionamento del servizio è stato verificato il file di configurazione "/etc/vsftpd.conf" assicurandosi che i parametri siano stati configurati nel seguente modo:

l i s t e n =NO l i s t e n _ i p v 6 =YES anonymous_enable=NO l o c a l _ e n a b l e =YES w r i t e _ e n a b l e =YES local_umask =022 dirmessage_enable=YES u s e _ l o c a l t i m e =YES x f e r l o g _ e n a b l e =YES c o n n e c t _ f r o m _ p o r t _ 2 0 =YES c h r o o t _ l o c a l _ u s e r =YES s e c u r e _ c h r o o t _ d i r = / v a r / run / v s f t p d / empty pam_service_name= v s f t p d pasv_enable=Yes pasv_min_port =10000 pasv_max_port =11000 user_sub_token =$USER l o c a l _ r o o t = /home / $USER / f t p u s e r l i s t _ e n a b l e =YES u s e r l i s t _ f i l e = / e t c / v s f t p d . u s e r l i s t u s e r l i s t _ d e n y =NO

È stato creato il file "/etc/vsftpd.userlist" e aggiunto il nome utente del Raspberry, in modo da poter gestire gli utenti aventi accesso FTP mediante questa lista:

r a s p u s e r

Per poter applicare tutte le modifiche a servizio FTP è necessario riavviarlo: sudo s e r v i c e v s f t p d r e s t a r t

7.2.3.6 Test del servizio FTP

L’accesso è stato testato utilizzando un client FTP come Filezilla. È stato verificato che l’utente sia riuscito ad accedere con il proprio nome utente e password e sono state fatte delle prove di lettura, scrittura dei files e creazione di sottocartelle.

(58)

48 Manuale Tecnico

7.2.4

Esecuzione dell’applicazione

Per eseguire l’intero sistema, è necessario eseguire l’applicazione sul dispositivo Raspberry e sul server.

7.2.4.1 Programma di riconoscimento

Dopo aver compilato l’applicazione, occorre eseguire il file Audio: . / Audio −sp

7.2.4.2 SAD Web Application

Dopo aver copiato il progetto Java all’interno del Server, installato e configurato il Server FTP e MySQL, l’IDE Intellij Idea dovrebbe essere in grado di eseguire automaticamente il programma tramite il modulo TOMCAT già integrato nel sistema.

Nel caso in cui questa procedura dovesse mostrare dei problemi, occorre provare ad ese-guire la classe SadApplication per forzare la sua esecuzione con la rispettiva configurazione automatica.

(59)

Capitolo 8

Conclusioni

Il lavoro svolto permette di rendere disponibili i dati raccolti dai dispositivi raspberry che so-no capaci d’identificare il passaggio dei veicoli d’emergenza, in questo caso le ambulanze. Si è partiti da un progetto già esistente in grado di fare riconoscimento di questi veicoli tra-mite audio e immagini catturate da microfono e videocamera, si sono poi aggiunti i metodi di trasmissione dei dati al server che rendono questo progetto utilizzabile nella vita reale.

8.1

Problemi/Opportunità riscontrati

Durante la realizzazione di questo progetto si sono presentati diversi ostacoli che la forma-zione in SUPSI ha permesso di riuscire a superare.

Tra queste difficoltà, sono incluse la comprensione dell’utilizzo di tecnologie avanzate come la Computer Vision, tramite l’utilizzo di OpenCV, oppure dello strumento restcpp SDK, che ha risolto il problema di comunicazione tra il Detector e il Server. La funzionalità di invio di file multipart non è ancora stata implementata nello strumento restcpp SDK e, per questo motivo, si sono dovute trovare delle soluzioni alternative.

Dopo un inizio abbastanza difficoltoso di analisi del lavoro da svolgere, le difficoltà si sono dimostrate nel trovare delle tecnologie e soluzioni richieste per lo svolgimento del progetto. Spesso sono state trovate delle ottime soluzioni, che purtroppo non si potevano adottare, in quanto protette da licenza esclusivamente commerciale.

Più in dettaglio, qui di seguito sono riportati i problemi riscontrati nello studio delle soluzioni e nello sviluppo:

• per l’invio di dati dal Detector al Server, é stato testato l’utilizzo della libreria socket offerta da C++, che però, a causa della complessità del compito, é stata abbandonata. Successivamente, è stata utilizzata la libreria Chilkat C/C++, la quale inizialmente offriva le capability richieste, ma la soluzione è stata abbandonata in quanto la licenza

(60)

50 Conclusioni

non permette il suo utilizzo in questo contesto. Alla fine, per risolvere definitivamente questo problema, é stata utilizzata la SDK cpprest offerta da Microsoft, che concede le risorse necessarie per la comunicazione REST tra client e server;

• per l’invio dei file, invece, la SDK cpprest non fornisce la possibilità di invio multipart. Per ovviare questo problema, é stato installato e configurato un server FTP per la condivisione dei file;

• l’implementazione della tecnologia JWT per la sicurezza della trasmissione dei da-ti é stata implementata sul server e testata con Postman. L’implementazione della stessa sul client é ancora incompleta, dal momento che é stata data la priorità all’e-secuzione del programma. L’impostazione della sicurezza è in previsione di essere implementata, in quanto essenziale in un ambiente non accademico;

• l’integrazione del software POMA al sistema di invio dei dati si é rivelato abbastanza complesso e, anche se testata, la sua completa integrazione con il sistema di invio di dati viene ignorata al momento;

• la cattura di un file audio per l’invio al server si é dimostrata molto complessa perchè l’audio viene registrato in forma di streaming e, dopo l’identificazione di un’ambulan-za, sarebbe necessario fermare il processo dello streaming e iniziare a salvare il file audio, tralasciando l’idea originale di identificazione in tempo reale. Al momento è stato testato l’invio di un file di prova, non corrispondente ai file audio necessari.

8.2

Sviluppi futuri

I possibili sviluppi futuri del progetto potrebbero essere sostanzialmente due in quanto sono due i punti maggiormente critici che potrebbero essere implementati e migliorati. Entrambi gli aspetti riguardano la sicurezza ma, se il primo è legato all’autenticazione del Detector rispetto al server, il secondo concerne invece la trasmissione dei dati.

Il primo sviluppo futuro riguarda dunque l’autenticazione. Il modo in cui attualmente il Detec-tor effettua la sua autenticazione non è infatti tra i più efficaci. Per rendere questo processo più sicuro e funzionale, si potrebbe usare una tecnologia conosciuta sotto il nome di Certi-ficati. Questa tecnologia, attraverso l’utilizzo di una chiave pubblica e di una chiave privata, permette di identificare in modo sicuro un dispositivo. Facendo ricorso ad essa il server potrebbe quindi identificare il Detector, e viceversa il Detector potrebbe identificare il server, in modo più sicuro rispetto a ora e senza margini di errore.

Il secondo sviluppo possibile riguarda invece, come detto, la trasmissione dei dati dal De-tector al server. Attualmente per inviare i file il software utilizza infatti la tecnologia ftp, che

(61)

è un protocollo di trasferimento file che potrebbe essere, in futuro, sostituito da una sua ver-sione crittografata più sicura chiamata sftp. Altre soluzioni rispetto a quella proposta, sono comunque possibili e in fase di studio.

(62)
(63)

Bibliografia

[Akshat(2017)] Sinha Akshat. Socket programming in c/c++, 2017. URL https://www. geeksforgeeks.org/socket-programming-cc/.

[Besenzoni(2017)] Matteo Besenzoni. Intelliphore - controllo intelligente di hub semaforici, 2017.

[JavaInUse(2019)] JavaInUse. Spring boot security + jwt hello world example, 2019. URL https://www.javainuse.com/spring/boot-jwt.

[JUCE(2017)] Team JUCE. Juce tutorials, 2017.

[Microsoft(2017)] Microsoft. cpprestsdk wiki, 2017. URL https://github.com/ microsoft/cpprestsdk/wiki.

[OpenCV(2017)] Team OpenCV. Opencv tutorials, 2017.

[Spring(2019)] Team Spring. Spring framework guides, 2019. URLhttps://spring.io/ guides.

Riferimenti

Documenti correlati

Ainsi, notre hypothèse principale de départ est que, par le choix d’un théâtre puisant dans le dialecte, les artistes recréent un moyen d’expression à la fois archaïque et

For example, in Naples the Aics has organized some cricket tournaments, involving the immigrants from the Indian Subcontinent, where the game is very popular; in Salerno, the

I tempi di degenza della minilaparotomia, sono superiori (6,2 giorni) rispetto alle casistiche pubblicate (5 giorni, Tabella 5): questa differenza, come già spiegato per

La satira, dedicata a un altro poeta satirico cinquecentesco, canta le lodi del “bentivoglio”: il capitolo di lode (opposto nell’argomento ai due precedenti – il XIII

L’unica fonte pre-ovidiana che si riferisce schiettamente al fatto che Orfeo fosse figlio (carnale, e non metaforico) di Apollo, è Asclepiade di Tragilo. Posto che è molto

This led us to reconsider classical Caesarean sec- tion as an alternative to L.U.S C.S in case of impact- ed head, and to devise a method to select adequate

To evaluate the effects of neridronate treatment on bone mass and vertebral deformities in children with OI. every 3 months), were evaluated lumbar bone mass (BMD e BMAD) and

Nello studio sono stati inclusi gruppi di controllo, composti da bambini a sviluppo tipico e da bambini con disabilità intellettive non specifiche; quest’ultimo gruppo per