Sei sulla pagina 1di 4

 

Anno accademico 2018/2019 

Progetto d’esame 
Laboratorio di Reti 2 

MODALITÀ D’ESAME 
L’esame del Laboratorio di Reti 2 consta di tre parti, tutte obbligatorie: 

1. Consegna individuale di 2 laboratori (10 punti), da svolgersi durante il corso 


2. Consegna di un progetto di gruppo inerente un sistema Internet of Things (IoT) (16 punti) 
3. Dimostrazione e breve orale sul progetto (8 punti) 

La valutazione dei progetti e la dimostrazione/orale riguarderà il materiale consegnato entro 3 


giorni prima dell’appello. 

La dimostrazione e la breve discussione orale inerente il progetto è da svolgersi il giorno 


dell’appello. Durante la dimostrazione, occorre introdurre il progetto e spiegarne gli 
scopi/obiettivi e le funzionalità dal punto di vista dell’​utilizzatore finale​ del progetto. Gli aspetti più 
tecnici potranno essere approfonditi durante la discussione orale. Il contributo individuale di ogni 
membro del gruppo deve emergere dalla discussione. 

Il voto finale del laboratorio è dato dalla somma delle tre parti precedenti. 

GRUPPO DI LAVORO 
Il progetto deve essere svolto a gruppi da 3-4 persone. 

REQUISITI E POLICY 
● Il progetto deve essere realizzato dai gruppi di studenti in maniera indipendente, senza 
eccessiva “collaborazione” tra gruppi diversi 
● Il progetto presenta descrizioni generiche in alcuni punti, in modo da permettere agli 
studenti di effettuare autonomamente delle scelte di progettazione 
● Il progetto deve prevedere tutte le componenti hardware e software descritte nella 
relativa specifica (vedi sotto) 
● Il codice sorgente deve essere ben scritto e corredato di opportuni commenti laddove 
necessario 
● Il codice sorgente deve essere testabile dal docente su IntelliJ o eclipse 

 
 
 
● I gruppi sono liberi di personalizzare le parti del progetto inerenti l’​interfaccia grafica​, in 
termini di librerie (CSS, JS, …) e linguaggio di programmazione server-side (dove 
necessario) 

ISTRUZIONI PER LA CONSEGNA DEL PROGETTO 


La consegna del progetto deve avvenire nel repository GitHub associato a ogni gruppo, entro 3 
giorni prima dell'appello (vedi calendario nella colonna laterale della pagina del corso su DIR per 
le date precise). 

Ogni repository dovrà contenere: 

● Codice sorgente delle parti software del sistema IoT realizzato 


● Relazione scritta (PDF) contenente 
○ un’introduzione sul sistema (obiettivo/scopo, funzionamento, ...) 
○ l’architettura del sistema 
○ la lista dei componenti (hardware e software) effettivamente utilizzati 
○ le scelte implementative ed eventuali limitazioni della soluzione adottata 

Ogni modifica al repository/alla relazione fatta dopo la data di consegna non sarà considerata ai 
fini della valutazione. 

ARCHITETTURA GENERALE 
Il sistema da realizzare è composto da tre elementi fondamentali: 

1. ​ /o​ attuatori​ (commerciali) che si interfacceranno con il gateway utilizzando le 


Sensori e
loro modalità native. Ad esempio: 
○ FitBit (battito cardiaco, passi, …) - RESTful API (HTTP) 
○ Philips Hue (luci) - RESTful API (HTTP) 
○ Dispositivi Z-Wave (sensori di presenza, attuatori on/off, …) - RESTful API (HTTP) 
2. Il ​gateway​ ha il compito di raccogliere le informazioni provenienti dai sensori e azionare 
gli attuatori secondo appropriate logiche, dettagliate nei singoli progetti. Il gateway si 
occuperà di: 
a. ricevere ed elaborare dati dai sensori del punto precedente 
b. interagire con gli attuatori per adempiere al suo obiettivo principale 
c. esporre informazioni e funzionalità tramite API REST e/o MQTT 
d. implementare parte della logica applicativa 
3. Il ​server/UI​ ha come funzione principale quella di raccogliere le informazioni che arrivano 
dal gateway ed esporle in un’interfaccia web-based. 
 
 

Il gateway deve girare su un Raspberry Pi, mentre il server/UI può rimanere su un computer 
“normale”.  

PROGETTO 2019: SMART BART 


Si vuole realizzare una stazione BART (​https://www.bart.gov​) intelligente. La stazione conterrà un 
gateway che dovrà gestire le informazioni sulla stazione stessa (disponibilità di parcheggi, di 
posti bici, …), quelle sui treni in transito (linee, orari previsti, orari in tempo reale, …) e le 
informazioni fornite dai passeggeri. 

I passeggeri, infatti, utilizzando un apposito sito web, potranno prenotare un posto su uno 
specifico treno, indicando anche la loro necessità di trasportare una bicicletta. 

Il gateway, tenendo conto di tutte queste informazioni, accenderà una luce verde in stazione per 
indicare la prenotazione di bici. Più prenotazioni con bici vengono effettuate, più la luminosità 
della luce dovrà essere intensa. Il gateway, inoltre, dovrà stimare quante persone si troveranno 
su un specifico treno: se il treno diventasse troppo affollato, dovrà notificare i passeggeri con 
bicicletta del fatto che non potranno salire con la loro bici sul treno; contestualmente, la luce 
relativa alle “prenotazioni con bici” dovrà diventare di un rosso intenso e lampeggiante. 

In dettaglio: 

- il gateway deve raccogliere i dati di passaggio dei treni (previsti), nonché le informazioni 
su una specifica stazione (a scelta del gruppo), utilizzando le API messe a disposizione da 
https://www.bart.gov/schedules/developers/api 
- l’interfaccia grafica, web-based, deve permettere al viaggiatore di visualizzare le 
informazioni sulla stazione e selezionare uno o più passaggi di treni alla stazione scelta, 
interrogando il gateway attraverso le sue API REST 
- l’interfaccia grafica, sempre utilizzando le API REST del gateway, deve permettere al 
viaggiatore di prenotare un posto sul treno precedentemente selezionato, facendogli 
indicare la sua necessità di portare una bici a bordo 
- per ogni prenotazione di posto con bici, il gateway deve accendere una luce (Philips Hue) 
verde, aumentandone sempre più l’intensità all’aumentare delle prenotazioni con bici 
- nel caso in cui il treno diventi troppo affollato, il gateway deve far diventare la “luce bici” 
rossa lampeggiante (ci si aspetta che i passeggeri con bici si comportino adeguatamente); 
se non ci sono bici prenotate, la luce deve rimanere spenta 
- nel caso in cui il treno diventi troppo affollato, l’interfaccia grafica, sempre utilizzando le 
API REST del gateway, deve visualizzare tale informazione in fase di prenotazione posto 
(e impedire nuove prenotazioni) 
 
 
- [gruppi da 4] nel caso in cui il treno diventi troppo affollato (soglia a scelta del gruppo), il 
gateway deve notificare via MQTT al viaggiatore l’impossibilità di caricare la sua bici e 
chiedergli se vuole cancellare la prenotazione o salire senza bici, sempre via MQTT 
- il gateway è responsabile di memorizzare le associazioni tra viaggiatore, bici, treno, … in 
un apposito database 

In aggiunta, i gruppi da quattro persone devono curare ​con particolare attenzione​ l’interfaccia 
grafica. 

L’architettura generale del progetto è riportata di seguito. 

Hardware da utilizzare: 

- Lampadine Philips Hue 


- Raspberry Pi (per gateway) 
- Computer (del laboratorio o personale)