Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
UNIVERSITÀ DEGLI STUDI DI PADOVA
TESI DI LAUREA MAGISTRALE
Sistemi domotici integrati per la
gestione intelligente d’ambie...
iii
Sommario
Università degli Studi di Padova
Dipartimento di Ingegneria dell’Informazione
Laurea magistrale in Ingegneria...
v
Indice
Sommario iii
Elenco delle figure vii
1 Introduzione 1
1.1 Letteratura . . . . . . . . . . . . . . . . . . . . . . ...
vi
3.3 Applicazione pratica . . . . . . . . . . . . . . . . . . . . . . . . 27
4 Conclusioni 35
Bibliografia 37
vii
Elenco delle figure
1.1 Architettura proposta da Ventylees Raj.S . . . . . . . . . . . . . 3
2.1 Proposta architettura ...
1
Capitolo 1
Introduzione
La domotica, dall’unione delle parole domus (che in latino significa "ca-
sa") e robotica, è la s...
2 Capitolo 1. Introduzione
di creare un sistema intelligente in grado di interconnettere vari dispositivi
all’interno di u...
1.1. Letteratura 3
Nei prossimi paragrafi verranno analizzate alcune proposte della lette-
ratura attuale e successivamente...
4 Capitolo 1. Introduzione
FIGURA 1.1: Architettura proposta da Ventylees Raj.S
and Karim Alaa Hamed consiste nell’utilizz...
1.2. Scopo della tesi 5
sistema RFID: consistente nell’utilizzo di tag all’interno di dispositivi indos-
sabili, sensori d...
6 Capitolo 1. Introduzione
caso di persone che hanno problemi di salute. Si sono volute creare alcune
situazioni ad-hoc ch...
7
Capitolo 2
Design pattern e progettazione
In questo capitolo parleremo dei design pattern progettuali individuati du-
ra...
8 Capitolo 2. Design pattern e progettazione
di pannelli di controllo situati in ogni stanza. E’ possibile inoltre regolar...
2.2. Scenari 9
La suddivisione ci sarà utile per comprendere al meglio la differenza tra i
comportamenti che non agiscono ...
10 Capitolo 2. Design pattern e progettazione
LUMINOSITA TEMPERATURE PROSSIMITA
SENSORS
WI-FI BLUETOOTH NFCETHERNET
COMMUN...
2.2. Scenari 11
in due categorie che si differenziano tra di loro in base al livello di dispo-
sitivi medici e controlli p...
12 Capitolo 2. Design pattern e progettazione
• segnalazione soglia consumo energetico: ogni oggetto elettrico colle-
gato...
2.2. Scenari 13
• rilevamento gas: ogni stanza è dotata di un rilevatore di gas collega-
to al sistema. Appena i sensori r...
14 Capitolo 2. Design pattern e progettazione
le caratteristiche descritte precedentemente, aggiungendo ulteriori oggetti ...
2.2. Scenari 15
lieve viene consigliato alla persona di assumere i farmaci prescritti, mentre
nel secondo caso viene attiv...
16 Capitolo 2. Design pattern e progettazione
migliorare l’efficienza complessiva nel sistema che risulta essere una pro-
b...
2.2. Scenari 17
dipendenti quando tendono a rimanere troppo attaccati ad un computer di-
minuendo la produttività a causa ...
19
Capitolo 3
Realizzazione scenari
In questo capitolo parleremo inizialmente del framework utilizzato per la
realizzazion...
20 Capitolo 3. Realizzazione scenari
• Linux
• Windows
• Mac
• Raspberry Pi
Altro punto forza di questo software è, come s...
3.1. Freedomotic 21
FIGURA 3.1: Schermata iniziale freedomotic
la lista degli oggetti inseribili nell’ambiente. Da qui è p...
22 Capitolo 3. Realizzazione scenari
FIGURA 3.2: Architettura freedomotic
• crea un layer di astrazione cosicché utenti o ...
3.1. Freedomotic 23
All’interno di freedomotic i plugin si dividono in due categorie: Object plu-
gin e Device plugin. I p...
24 Capitolo 3. Realizzazione scenari
if bathtub water level is 95%
TRIGGER
then turn off bathtub
COMMAND
REACTION
FIGURA 3...
3.1. Freedomotic 25
LISTING 3.1: Trigger
1 <t rigg er>
2 <name>When Bathtub water Level i s 95%</name>
3 <description>bad ...
26 Capitolo 3. Realizzazione scenari
LISTING 3.3: Reaction
1 <reaction>
2 <t rigg er>When Bathtub water Level i s 95%</tri...
3.2. MQTT per IoT 27
3.2.1 Modello publish - subscribe
Il modello utilizzato per il protocollo MQTT risulta essere il mode...
28 Capitolo 3. Realizzazione scenari
FIGURA 3.5: Modello Publish-Subscribe
• QoS 2 - exactly once: garantisce la consegna ...
3.2. MQTT per IoT 29
3.2.3 Topic
Il topic è una stringa usata dal broker per filtrare i messaggi per ogni client
connesso. ...
30 Capitolo 3. Realizzazione scenari
Sicurezza
Si sta La sicurezza nel mondo IoT è molto importante a maggior ragione
quan...
3.3. Applicazione pratica 31
• network level: in questo livello vengono utilizzate VPN per collegare
client e broker.
MQTT...
32 Capitolo 3. Realizzazione scenari
rispetto ad un’azione voluta da una persona sana. Per esempio: se la perso-
na con pr...
3.3. Applicazione pratica 33
all’interno dei vari scenari e verranno descritti brevemente i software ester-
ni adoperati c...
34 Capitolo 3. Realizzazione scenari
espressioni regolari; la formula utilizzata per la composizione del payload
del messa...
3.3. Applicazione pratica 35
Mosquitto broker
L’oggetto che si occupa di gestire tutti i topic, come descritto nel paragra...
36 Capitolo 3. Realizzazione scenari
FIGURA 3.9: Schermata iniziale MQTT spy
esiste la possibilità di poter inviare a sua ...
3.3. Applicazione pratica 37
Modificando il client MQTT di Freedomotic è stato possibile inviare messag-
gi per poter simul...
38 Capitolo 3. Realizzazione scenari
possibile realizzare le idee proposte verificandone così la fattibilità e la fun-
zion...
39
Capitolo 4
Conclusioni
Oggigiorno ci troviamo in un mondo in cui la tecnologia è parte integrante
della nostra vita. Si...
40 Capitolo 4. Conclusioni
divisione ha portato alla scelta di utilizzare un cloud esterno per l’ambiente
domotico mentre ...
Capitolo 4. Conclusioni 41
realizzando così una banca dati da cui poter attingere informazioni. Aven-
do a disposizione se...
43
Bibliografia
[1] Domotica. URL https://it.wikipedia.org/wiki/Domotica.
[2] M.longo, MC. Roscia, D. Zaninelli. Net Zero E...
44 BIBLIOGRAFIA
[7] Serge Offermans, Aravind Kota Gopalakrishna, Harm van Essen, Tanir
Özçelebi. Breakout 404: A smart spa...
BIBLIOGRAFIA 45
[17] MQTT broker test Mosquitto.org. URL http://test.mosquitto.
org/.
[18] MQTT spy. . URL https://kamilfb...
Sistemi domotici integrati per la gestione intelligente d’ambiente
Sistemi domotici integrati per la gestione intelligente d’ambiente
Sistemi domotici integrati per la gestione intelligente d’ambiente
Sistemi domotici integrati per la gestione intelligente d’ambiente
Sistemi domotici integrati per la gestione intelligente d’ambiente
Upcoming SlideShare
Loading in …5
×

Sistemi domotici integrati per la gestione intelligente d’ambiente

10,870 views

Published on

Tesi di laurea magistrale in Ingegneria Informatica di Riccardo Trivellato svolta presso l'Università degli Studi di Padova.
In questo lavoro si è voluto progettare e realizzare un sistema intelligente domotico che si integrasse in due scenari comuni: casa e ufficio. La simulazione degli ambienti è stata effettuata con il framework Freedomotic

Published in: Software
  • Hello! Who wants to chat with me? Nu photos with me here http://bit.ly/helenswee
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Sistemi domotici integrati per la gestione intelligente d’ambiente

  1. 1. UNIVERSITÀ DEGLI STUDI DI PADOVA TESI DI LAUREA MAGISTRALE Sistemi domotici integrati per la gestione intelligente d’ambiente Autore: Riccardo Trivellato Relatore: Carlo Ferrari Tesi di Laurea magistrale in Ingegneria Informatica 28 Febbraio 2017
  2. 2. iii Sommario Università degli Studi di Padova Dipartimento di Ingegneria dell’Informazione Laurea magistrale in Ingegneria Informatica Sistemi domotici integrati per la gestione intelligente d’ambiente Riccardo Trivellato In questo lavoro si è voluto progettare e realizzare un sistema intelligente domotico che si integrasse in due scenari comuni: casa e ufficio. Si è par- titi da una progettazione dell’architettura del sistema per arrivare alla sua configurazione settando i comportamenti che dovrà adottare all’accadere di determinati eventi. Un aspetto importante che si è voluto sottolineare è l’in- terazione del sistema con casi di assistenza sanitaria presenti in entrambi gli scenari. Terminata la progettazione si è passati alla simulazione degli am- bienti attraverso l’utilizzo di un framework di lavoro: Freedomotic. Grazie a questo software si è potuta testare la bontà della realizzazione verificandone le caratteristiche principali.
  3. 3. v Indice Sommario iii Elenco delle figure vii 1 Introduzione 1 1.1 Letteratura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Scopo della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Design pattern e progettazione 7 2.1 Analisi progettuale . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Scenari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1 Ambiente domestico . . . . . . . . . . . . . . . . . . . . 9 Livello a basso impatto . . . . . . . . . . . . . . . . . . . 10 Livello a medio impatto . . . . . . . . . . . . . . . . . . 12 2.2.2 Ambiente lavorativo . . . . . . . . . . . . . . . . . . . . 14 3 Realizzazione scenari 17 3.1 Freedomotic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.1 Cos’è Freedomotic . . . . . . . . . . . . . . . . . . . . . 17 3.1.2 Primo impatto . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.3 Struttura . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2 MQTT per IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.1 Modello publish - subscribe . . . . . . . . . . . . . . . . 23 3.2.2 QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.3 Topic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
  4. 4. vi 3.3 Applicazione pratica . . . . . . . . . . . . . . . . . . . . . . . . 27 4 Conclusioni 35 Bibliografia 37
  5. 5. vii Elenco delle figure 1.1 Architettura proposta da Ventylees Raj.S . . . . . . . . . . . . . 3 2.1 Proposta architettura casa . . . . . . . . . . . . . . . . . . . . . 9 2.2 Proposta architettura ufficio . . . . . . . . . . . . . . . . . . . . 10 2.3 Esempio design ambiente domestico . . . . . . . . . . . . . . . 14 2.4 Esempio design ambiente lavorativo . . . . . . . . . . . . . . . 15 3.1 Schermata iniziale freedomotic . . . . . . . . . . . . . . . . . . 18 3.2 Architettura freedomotic . . . . . . . . . . . . . . . . . . . . . . 19 3.3 Schema utilizzo plugin . . . . . . . . . . . . . . . . . . . . . . . 20 3.4 Esempio reaction in Freedomotic . . . . . . . . . . . . . . . . . 21 3.5 Modello Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . 24 3.6 Schema QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.7 Scrittura topic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.8 Topic multilevel . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.9 Schermata iniziale MQTT spy . . . . . . . . . . . . . . . . . . . 31 3.10 Reaction in azione . . . . . . . . . . . . . . . . . . . . . . . . . . 32
  6. 6. 1 Capitolo 1 Introduzione La domotica, dall’unione delle parole domus (che in latino significa "ca- sa") e robotica, è la scienza interdisciplinare che si occupa dello studio delle tecnologie atte a migliorare la qualità della vita nella casa e più in generale negli ambienti antropizzati[1]. La domotica è diventata più pratica all’inizio del ventesimo secolo, seguendo la rapida diffusione dell’elettricità e l’ascesa dell’information technology[2]. Le persone, solitamente, considerano questa scienza come "un set di gadget costosi che rendono la casa smart" e molti pensano che la domotica non sia essenziale. Probabilmente potevano aver ragione anni fa, ma un’analisi più approfondita di questa materia potrebbe far cambiare loro idea [3]. Questa disciplina, con l’avvento dell’ Internet of Things (IoT), sta espan- dendo sempre più il suo raggio d’azione e gli obiettivi che si propone sono quelli di: • migliorare la qualità di vita • aumentare la sicurezza • aumentare il comfort • migliorare la safety Esistono sempre più proposte di ambienti con una fortissima componente domotica atta ad agevolare la vita delle persone. Il fine di queste, è quello
  7. 7. 2 Capitolo 1. Introduzione di creare un sistema intelligente in grado di interconnettere vari dispositivi all’interno di un ambiente(temperatura, luci, sensori di movimento, etc). Grazie a questo sistema di interconnessione è possibile sia monitorare che comandare i vari oggetti connessi tra di loro. Una caratteristica importante è la possibilità di avere oggetti che agiscano autonomamente basandosi su una serie di regole o azioni imposte dall’u- tente, per esempio: chiudere tutte le tapparelle ad una certa ora, regolare la temperatura quando si è fuori casa per ottenere un risparmio energetico. Tutte queste azioni possono essere controllate o all’interno dell’ambiente stesso attraverso pannelli di controllo o, grazie al continuo sviluppo del- l’IoT, possiamo controllarli da remoto attraverso smartphone, tablet e note- book. L’unico requisito necessario è quello di possedere una connessione ad Internet. Grazie a questo possiamo avere una panoramica completa di quello che sta avvenendo nel nostro ambiente non essendo presenti fisica- mente. Attraverso i nostri device possiamo connetterci al nostro sistema e monitorare in tempo reale lo stato della nostra casa o del nostro ufficio. Oltre al controllo remoto possiamo, attraverso sistemi intelligenti, ottimiz- zare i nostri consumi energetici. Con opportune regole impostate o con re- gole derivate da un apprendimento automatico, i dispositivi possono agire al posto nostro controllando costantemente le informazioni che ricevono. Basandosi su queste informazioni possono modificare il loro comportamen- to per aumentare la qualità della vita o per cercare di aumentare l’efficienza degli edifici.
  8. 8. 1.1. Letteratura 3 Nei prossimi paragrafi verranno analizzate alcune proposte della lette- ratura attuale e successivamente l’obiettivo di questa tesi. 1.1 Letteratura In questa sezione verranno prese in considerazione alcune proposte riguar- danti ambienti con forte possibilità di componente domotica come l’abita- zione e l’ambiente lavorativo; le motivazioni di questa scelta saranno tratta- te nel Capitolo 2. I principali aspetti emersi dalle pubblicazioni scelte e che verranno anche trattati in questa tesi sono i seguenti: • progettazione verticale di un sistema domotico • metodi di localizzazione all’interno dell’ambiente • interoperabilità tra dispositivi Analizziamoli ora nel dettaglio. Progettazione verticale di un sistema domotico L’architettura principale utilizzata per progettare questa tipologia di siste- ma è un’architettura centralizzata a stella[2][4]. I principali componenti so- no: assistenti, gateway e core. Gli assistenti sono presenti in ogni stanza e la- vorano raccogliendo informazioni dall’ambiente che li circonda. Il gateway si occupa di raccogliere i dati dagli assistenti e di prendere decisioni in base alle informazioni raccolte. Il core presenta le stesse funzioni del gateway ma non gli invia dati, si occupa di collezionare statistiche o controllare i vari sistemi. Questo modello è pensato principalmente per edifici lavorativi, ma secon- do l’autore può essere tranquillamente adattato ad uno scenario domestico rimuovendo l’uso del gateway. Il modello proposto da Ahmed ElShafee
  9. 9. 4 Capitolo 1. Introduzione FIGURA 1.1: Architettura proposta da Ventylees Raj.S and Karim Alaa Hamed consiste nell’utilizzo di tre moduli principali: ser- ver, hardware per intefacciamento e software[5]. Anche qui, come in al- tri modelli proposti viene utilizzata una tipologia di architettura centraliz- zata attraverso l’uso di un’unità di calcolo centrale, seguita da gateway e sensori[2][3]. Questa strategia permette di avere una visione completa della gerarchia tra livelli e del funzionamento del sistema. Metodi di localizzazione all’interno dell’ambiente Una questione aperta risulta essere la localizzazione degli oggetti e soprat- tutto delle persone all’interno di un ambiente. Alcune pubblicazioni sfrutta- no l’uso di un sistema infrastruttura Radio-Frequency IDentification (RFID), altre sfruttano tecnologie di Ultra Wide Band (UWB). L’utilizzo del protocollo RFID per la localizzazione avviene attraverso tag e comunicazione ad infrarossi. Ogni stanza è provvista di una zona che riceve il segnale dai tag e successivamente, attraverso un server, elabora i dati. Questa metodologia è risultata essere poco precisa rispetto all’uso di tecnologie UWB. Il funzionamento piattaforma UWB è pressoché identico al
  10. 10. 1.2. Scopo della tesi 5 sistema RFID: consistente nell’utilizzo di tag all’interno di dispositivi indos- sabili, sensori di movimento posti nei soffitti, switch e server per la raccolta e l’elaborazione dei dati. Questo sistema permette di rilevare con precisione la posizione anche in presenza di ambienti complessi e ricchi di ostacoli ed ha permesso di individuare le persone con una accuratezza di 30cm. [6]. Interoperabilità tra dispositivi L’interoperabilità tra dispositivi è una tematica molto varia nell’ambito del- la domotica. Non esiste uno standard comune per la comunicazione. Una soluzione proposta da Ventylees Raj.S[3] prevede l’utilizzo misto tra Wi-Fi e Zigbee, mentre altri utilizzano il protocollo XBee[7]. Questi protocolli vengo- no utilizzati a livello fisico; per quanto riguarda la raccolta e l’elaborazione dati, è emerso un protocollo su tutti: Message Queue Telemetry Transport (MQTT). La sua notorietà è dovuta al fatto che risulta essere molto leggero e adatto a scambio di piccole quantità di dati. Il suo utilizzo verrà trattato nel Capitolo 3. 1.2 Scopo della tesi L’obiettivo principale di questa tesi è quello di progettare e analizzare un sistema intelligente domotico da applicare a scenari quotidiani come quello domestico e quello lavorativo. La motivazione di questa scelta è dovuta al fatto che la maggior parte delle persone trascorre il proprio tempo tra casa e lavoro. Ed è proprio qui che si vogliono analizzare i benefici che la domotica può portare in termini di comfort e di automazione. Con questo lavoro si vuole mostrare l’importanza di questa disciplina appli- cata alla quotidianità e soprattutto mostrare come una progettazione com- pleta può essere fatta attraverso strumenti semplici e gratuiti. Viene inoltre dato peso ad un aspetto che non viene messo in risalto quando si parla di domotica, ovvero i vantaggi che si potrebbero ottenere in ambito di aiuto in
  11. 11. 6 Capitolo 1. Introduzione caso di persone che hanno problemi di salute. Si sono volute creare alcune situazioni ad-hoc che possono accadere in casa e in ufficio dando peso al comportamento del sistema e dei dispositivi medici integrati, cercando così di poter aiutare le persone ed evitare ulteriori complicazioni mediche. L’integrazione dei device con il sistema e la loro eterogeneità ha portato alla luce un problema di interoperabilità tra di essi che verrà trattato nel Cap.3. Dopo la fase di progettazione si passerà alla fase di realizzazione e simu- lazione. Non disponendo di un vero scenario nel quale testare le idee pro- poste, verrà utilizzato un framework di simulazione gratuito che consentirà di testare le proposte fatte: Freedomotic. Grazie ad esso è sarà possibile sviluppare il progetto e analizzare i comportamenti del sistema. L’insieme di queste fasi mostrerà un connubio tra idee di ambienti domotici e possi- bili implementazioni che potranno essere usate per una futura realizzazio- ne pratica del sistema pensato, mostrando così la possibilità di risparmiare tempo e denaro sia in fase di progettazione che in fase di configurazione. La fase di progettazione verrà discussa nel Capitolo 2, mentre la fase di realizzazione verrà discussa nel Capitolo 3. Il Capitolo 4 parlerà principal- mente del risultato ottenuto e degli sviluppi futuri.
  12. 12. 7 Capitolo 2 Design pattern e progettazione In questo capitolo parleremo dei design pattern progettuali individuati du- rante il lavoro e delle idee riguardanti l’inserimento di un sistema intelli- gente domotico in un ambiente domestico e in un ambiente lavorativo. La scelta è ricaduta su questi due scenari perché è qui che la maggior parte delle persone trascorre il proprio tempo. L’inserimento della componente domotica in questi due ambienti potrebbe veramente migliorare la qualità del tempo trascorso al loro interno. Nei prossimi paragrafi analizzeremo i design pattern di progettazione e successivamente gli scenari proposti. 2.1 Analisi progettuale La progettazione di un sistema domotico richiede come primo passo la ste- sura di una sua architettura. Per entrambi gli scenari è stata scelta un’ar- chitettura centralizzata (vedi fig.2.1 e fig.2.2) simile alle idee già proposte in letteratura (vedi par. 1.1). Entrambe utilizzano un paradigma clientserver dove è presente un’unità di calcolo centrale che può raccogliere dati attra- verso gateway(chiamati controllori) ed i dati raccolti sono forniti da sensori o dispositivi come gli elettrodomestici. Analizziamo prima quella riguar- dante l’ambiente domestico e poi quella riguardante l’ambiente lavorativo. Il sistema previsto per l’ambiente domestico, prevede un’elaborazione dati basata su un cloud esterno, un gateway centrale nell’abitazione ed una serie
  13. 13. 8 Capitolo 2. Design pattern e progettazione di pannelli di controllo situati in ogni stanza. E’ possibile inoltre regolare le varie azioni o controllare i valori rilevati dai vari sensori da remoto con un’applicazione dedicata per smartphone o accedendo al sito web relativo al proprio sistema, fornito sempre grazie all’utilizzo del cloud esterno. La scelta dell’esternalità dell’elaborazione dati e del controllo software è dovu- ta principalmente alla fase di manutenzione e aggiornamento del sistema. In caso di problemi hardware o software, l’azienda fornitrice del servizio può accorgersi immediatamente del malfunzionamento e recarsi in loco per fornire assistenza, evitando così che il cliente debba provvedere alla manu- tenzione. La differenza rispetto alle proposte di letteratura risulta essere proprio questa, tutte prevedono un sistema centralizzato nell’edificio dove la domotica viene applicata, non tenendo conto di futuri interventi di ma- nutenzione. Lato ufficio, il server contente i dati raccolti l’unità di elaborazione non so- no esterni ma vengono installati internamente all’edificio. L’interazione tra utente e sistema è divisa in due parti: l’amministratore del sistema a cui è consentito il controllo completo del sistema e il dipendente che può solo modificare parametri ambientali per migliorare il proprio comfort. Nell’uf- ficio, solo l’amministratore ha il pieno controllo dell’intero sistema. Nel- la fase di configurazione degli scenari che vedremo successivamente, sono stati identificati due tipi di comportamento da parte del sistema e sono: • comportamento passivo: riguarda azioni che il sistema effettua per avvisare le persone che qualche evento è avvenuto o sta per accade- re. Questo comportamento non implica un intervento del sistema in maniera autonoma ma solo un’azione di avviso. • comportamento attivo: implica un’azione autonoma da parte del si- stema. Esso reagisce ad un evento in maniera automatica. L’azione che viene compiuta può essere preimpostata dall’utente o ottenuta at- traverso tecniche di apprendimento applicate al comportamento delle persone che occupano l’ambiente.
  14. 14. 2.2. Scenari 9 La suddivisione ci sarà utile per comprendere al meglio la differenza tra i comportamenti che non agiscono e svolgono una funzione preventiva e i comportamenti che agiscono autonomamente. Addentriamoci ora nello specifico delle situazioni proposte. LUMINOSITA TEMPERATURA PROSSIMITA SENSORS WI-FI BLUETOOTH NFCETHERNET COMMUNICATION MODULE ZIG-BEE MQTT CORE CENTRALE DATABASE (log, user profile) CONTROLLORE STANZA N CONTROLLORE STANZA 1 CONTROLLORE STANZA 2 USERINTEFACES WEBUSER INTERFACE APP SMARTPHONE LCD ASTRAZIONEINPUT COMMAND INPUT / OUTPUT DATA INPUT/OUTPUT MANUALE REMOTO CLOUD ESTERNO FIGURA 2.1: Proposta architettura casa 2.2 Scenari Nei precedenti capitoli abbiamo discusso alcune proposte presenti in lette- ratura. Ora invece verranno analizzati gli scenari e le scelte fatte in fase di progettazione per il comportamento del sistema. Lo scenario domestico si concentra sulle funzionalità base di un impianto domotico(temperatura, controllo consumi elettrici etc) e, in aggiunta, ci si è voluti focalizzare sull’assistenza sanitaria domestica che spesso non viene
  15. 15. 10 Capitolo 2. Design pattern e progettazione LUMINOSITA TEMPERATURE PROSSIMITA SENSORS WI-FI BLUETOOTH NFCETHERNET COMMUNICATION MODULE ZIG-BEE MQTT CORE CENTRALE DATABASE (log, user profile) CONTROLLORE RELAX ROOM CONTROLLORE UFFICIO CONTROLLORE MEETING ROOM INTERFACCIAUTENTE WEBUSERINTERFACE LCD ASTRAZIONE GESTIRELARRIVODEIDATIE COMINUCARLICORRETTAMENTEAL CONTROLLORE.STESSACOSAPERLINVIO DATA INPUT/OUTPUT INTERFACCIA AMMINISTRATORE SERVER CENTRALE AZIENDA ASTRAZIONECOMANDICOMUNICAZIONE ZONA SERVER FIGURA 2.2: Proposta architettura ufficio trattata. Questa situazione è ricorrente in alcune famiglie se pensiamo ma- gari a genitori che vivono con i figli. Potrebbero esserci persone che presen- tano malattie croniche, le quali possono venire tranquillamente controllate a casa senza l’aiuto di assistenza ospedaliera o personale qualificato. Lo scenario lavorativo, invece, tratta un ufficio suddiviso in quattro zo- ne: hall, sala d’attesa, sala conferenza e back end lavorativo. Ognuna di queste avrà una particolare situazione che verrà illustrata successivamente. 2.2.1 Ambiente domestico In questo paragrafo descriveremo l’ambiente domestico progettato. Partire- mo da una descrizione dello scenario e successivamente passeremo le azioni impostate. Una parte importante sarà dedicata alla descrizione dei device connessi e alle azioni che comportano, le quali risulteranno essere parte inte- grante del funzionamento del sistema. L’ambiente domestico è stato diviso
  16. 16. 2.2. Scenari 11 in due categorie che si differenziano tra di loro in base al livello di dispo- sitivi medici e controlli presenti. In entrambe le suddivisioni il sistema pri- vilegia le persone con problematiche rispetto alle persone sane perché sono proprio quelle con patologie che hanno bisogno di una maggiore attenzio- ne. Il privilegio si riassume nel fatto che qualsiasi azione richiesta da coloro che presentano problematiche verrà eseguita prima rispetto ad altre azioni chieste da persone sane. Livello a basso impatto Lo scenario domestico è composto da classica abitazione composta da: due bagni, garage, salotto, cucina, camera da letto e ufficio(vedi fig.2.1). All’in- terno di queste stanze sono state inserite, a secondo dell’utilizzo, un insie- me di dispositivi interconnessi atti ad aumentare il comfort interno. I devi- ce connessi sono: rilevatore di gas, lampadine elettriche, forno, frigorifero, termometri, termostati, condizionatori, letti e poltrone reclinabili, lavatrice, lavastoviglie, vasca da bagno, contatore e porte intelligenti. Oltre a questi dispositivi sono state previste prese elettriche intelligenti. Tutti questi oggetti comportano una serie di azioni inserite nel sistema che verranno distinte tra attive e passive. I comportamenti del sistema riguar- dano l’utilizzo di una strategia armonizzata tra persona/oggetto e perso- na/ambiente, dove per strategia armonizzata si intende i modi di agire del sistema nei vari contesti. Elenchiamo ora le azioni più importanti progetta- te: • controllo livello acqua vasca da bagno: una persona apre l’acqua nel- la vasca da bagno e nel frattempo occupa il suo tempo con altre com- missioni. Quando l’acqua raggiunge la soglia del 95% scatta il control- lo inserito nel sistema, che esegue il blocco dell’uscita evitando così di allagare il bagno. Questo tipo di azione è inserita nella categoria com- portamento attivo perché il sistema agisce al posto dell’utente secondo una regola preimpostata.
  17. 17. 12 Capitolo 2. Design pattern e progettazione • segnalazione soglia consumo energetico: ogni oggetto elettrico colle- gato ad una presa consuma una determinata quantità di Watt. Grazie alla prese intelligenti è possibile monitorare in tempo reale il consumo. Considerando che un’utenza abitativa possiede un consumo massimo di 3kW/h, quando questa raggiunge il 95% della potenza totale viene segnalata attraverso una notifica sul pannello di controllo che si sta per superare la soglia. Questo comportamento viene inserito nella lista dei comportamenti passivi perché esso si limita a ricordare alle persone che stanno per superare la quantità di potenza a loro disposizione. Non compie azio- ne di spegnimento di oggetti elettrici perché non conosce quali sono realmente in uso e quali no. • spegnimento automatico forno: questo comportamento appartiene alla categoria delle azioni attive. Nel caso in cui si voglia cucinare una qualsiasi pietanza che abbia bisogno di tempo e temperatura pre- cisi l’utente può impostare questi parametri ed accendere il forno. Se poi dovesse dimenticarsi di spegnere per tempo il forno, rischierebbe di rovinare il piatto, ecco che qui il sistema agisce per conto dell’utente spegnendo il forno in maniera automatica. • accensionespegnimento luce stanze: ogni stanza è configurata per accendere o spegnere le luci a seconda della presenza di una o più persone al suo interno grazie a sensori di presenza. Questa azione viene classificata come attiva. • controllo temperatura: nelle stanze principali sono presenti un senso- re di temperatura, un termostato e un condizionatore. Il sensore rileva la temperatura e la comunica al termostato, se questa risulta essere diversa dalla temperatura settata, scatta automaticamente l’attivazio- ne del condizionatore per scaldare o raffreddare la stanza risultando essere un azione attiva.
  18. 18. 2.2. Scenari 13 • rilevamento gas: ogni stanza è dotata di un rilevatore di gas collega- to al sistema. Appena i sensori rilevano del fumo scatta l’allarme di avviso per l’utente e viene bloccata l’erogazione di gas, segnalando at- traverso il pannello di controllo l’emergenza. Qui siamo in presenza di un comportamento ibrido perché è presente sia un azione passiva (notifica) che un azione attiva (spegnimento gas). • controllo lavatrice: la lavatrice pensata risponde a comandi da re- moto e aggiorna in tempo reale l’utente sullo stato di un lavaggio. E’ inoltre possibile impostare i parametri per un lavaggio completo: temperatura, giri centrifuga, programma capi e timer. • controllo frigo: anche il frigo è controllabile da remoto come gli altri oggetti. Qui è possibile conoscere la temperatura del frigo e del freezer ed impostarle a proprio piacimento. Terminate le azioni riguardanti l’ambiente, passiamo ora alle azioni che ri- guardano l’assistenza medica all’interno della casa. Per questo livello sono state scelte due patologie mediche comuni: ipertensione e glicemia. Esse possono essere costantemente monitorate attraverso due dispositivi medici, il sfigmomanometro e lo glucometro. Rendendo questi device interconnes- si con il sistema si possono costantemente tenere sotto controllo pressione e livello di glucosio presenti nel sangue. Quando questi sono misurati, il siste- ma confronta i valori rilevati con i valori ottimali. Nel caso in cui dovessero risultare leggermente differenti, viene notificato all’utente di assumere i far- maci prescritti. Questo comportamento è comune ad entrambi gli oggetti e rientra nella categoria di comportamento passivo. Livello a medio impatto Questo livello, come il precedente, si occupa di simulare la maggior parte delle azioni che accadono nella quotidianità domestica. Esso include tutte
  19. 19. 14 Capitolo 2. Design pattern e progettazione le caratteristiche descritte precedentemente, aggiungendo ulteriori oggetti e azioni che riguardano persone con problemi di salute maggiore. Questo scenario è stato progettato per far fronte ad un livello di assistenza sanitaria superiore. E’ possibile avere una o più persone in casa con proble- mi di salute più importanti rispetto ai precedenti, quali: problemi cardiaci e problemi respiratori. Anche queste patologie possono essere monitora- te attraverso dispositivi medici che potrebbero essere connessi al sistema domotico. I dispositivi sanitari che vanno ad aggiungersi a quelli già vi- sti(sfigmomanometro e glucometro) sono: cardiofrequenzimetro e saturi- metro. A corredo di questi dispositivi medici, e vista l’importanza delle nuove pa- tologie previste, è stato inserito un sistema di telesoccorso ed un sistema di rilevamento cadute composto da sensori di movimento. In caso di problemi gravi o di caduta da parte di una persona problematica, il sistema inoltra im- mediatamente una chiamata d’emergenza al pronto soccorso. Analizziamo ora le integrazioni del cardiofrequenzimetro,dell’saturimetro e del telesoc- corso con il sistema domotico. Descriviamo ora brevemente le funzionalità dei due oggetti aggiunti. Il cardiofrequenzimetro è un dispositivo che misura i battiti cardiaci. Sono presenti delle azioni collegate alla rilevazione di valori anomali riguardanti il battito cardiaco. Le azioni scattano quando si scende sotto una soglia mi- nima o si supera la soglia massima. Quando si scende al di sotto di 60 battiti per minuto o si superano i 120 scatta immediatamente il sistema di pronto soccorso per evitare perdita di tempo in caso di situazioni critiche. L’ossimetro è un dispositivo che rileva la percentuale di ossigeno all’in- terno del sangue. In questo scenario sono previste due casistiche per i valori rilevati: ipossia lieve ed ipossia grave. La prima si ha quando la percentuale dell’ossigeno nel sangue rilevata è compresa tra 89% e 95%, mentre la secon- da si ha quando il valore risulta essere inferiore al 89%. Nel caso di ipossia
  20. 20. 2.2. Scenari 15 lieve viene consigliato alla persona di assumere i farmaci prescritti, mentre nel secondo caso viene attivato il telesoccorso. Le azioni che il sistema esegue risultano essere di tipo passivo nel caso di ipossia lieve e di tipo attivo nel caso si abbiano problemi di cuore o di ipossia grave. Questa scelta è stata fatta per differenziare la gravità delle problematiche. FIGURA 2.3: Esempio design ambiente domestico 2.2.2 Ambiente lavorativo Trattiamo ora lo scenario di un ambiente lavorativo. Si è voluto capire come un ufficio possa adattarsi alle nuove tecnologie di domotica e IoT. Il con- testo risulta essere molto dinamico a causa del continuo movimento al suo interno. Lo scenario ideato è composto da sei stanze: hall d’accoglienza, sala d’atte- sa, sala conferenze, ufficio di lavoro e due bagni, uno nella sala d’attesa e l’altro nella zona lavoro(vedi fig.2.2). La configurazione di base del sistema comprende anche qui, come nello scenario domestico, un controllo dell’effi- cienza energetica tramite prese intelligenti e un controllo della temperatura basato sulla presenza di persone nelle stanze. Queste azioni servono per
  21. 21. 16 Capitolo 2. Design pattern e progettazione migliorare l’efficienza complessiva nel sistema che risulta essere una pro- blematica importante[4][8]. Sono previsti anche rilevatori di gas per ogni stanza, per evitare il propagarsi di un incendio all’interno dell’edificio. Nel sistema sono impostate delle azioni riguardanti l’assistenza sanitaria in ambito lavorativo. Può capitare che, all’interno di un ufficio, una persona possa non sentirsi bene. Per determinare il comportamento del sistema, in questo tipo di situazione, si è partiti dal presupposto che in ogni azienda sia presente una figura che abbia un attestato di primo soccorso. Sulla base di questa ipotesi, se qualcuno dovesse sentirsi male, viene immediatamente avvisata la persona incaricata e gli viene comunicata la posizione a cui si deve recare. Questi avvisi vengono inoltrati attraverso notifiche su smart- phone o su notebook. Nel caso in cui le condizioni del soggetto che si è sentito male risultano essere gravi viene attivato il sistema di telesoccorso. Descritte le azioni di base, passiamo alle configurazioni relative alle stan- ze. La sala d’attesa è configurata per rendere più confortevole la visita agli ospiti. Sono inseriti dei monitor a muro che si comportano come dei quadri a tema. Conoscendo la nazionalità degli ospiti, essi si configurano automa- ticamente mostrando immagini in sintonia con la loro cultura. Nella stanza, inoltre, sono stati inseriti una televisione ed un gruppo di tablet opportu- namente configurati per accendersi solo in presenza di persone e spegnersi altrimenti. E’ installata anche una copertura Wi-Fi con accesso ad internet. Tutte queste azioni sono categorizzate come azioni attive. La sala conferenze presenta un tablet per ogni postazione, una televisione ed uno scudo luminoso per filtrare la luce. Quando la sala viene usata per una riunione, vengono inviati i documenti utili a tutti i dispositivi e lo scu- do luminoso si attiva schermando la luce, rendendo l’ambiente consono ad una riunione. Le azioni presenti in questa stanza fanno parte della categoria dei comportamenti attivi perché agiscono autonomamente senza richiedere l’azione da parte dell’amministratore. La zona lavoro è configurata anch’essa con scudi luminosi per non affatica- re la vista dei lavoratori. Sono presenti scrivanie intelligenti che avvisano i
  22. 22. 2.2. Scenari 17 dipendenti quando tendono a rimanere troppo attaccati ad un computer di- minuendo la produttività a causa della stanchezza. L’azione riguardante lo scudo luminoso è classificata come azione passiva, mentre la seconda come azione attiva. FIGURA 2.4: Esempio design ambiente lavorativo Ora che gli scenari sono stati descritti passiamo alla realizzazione di questo progetto. Nel capitolo 3 verrà discusso come sono stati realizzati e simulati gli ambienti attraverso il framework di lavoro scelto e illustrato il protocollo utilizzato per garantire l’interoperabilità e la comunicazione tra i dispositivi.
  23. 23. 19 Capitolo 3 Realizzazione scenari In questo capitolo parleremo inizialmente del framework utilizzato per la realizzazione delle idee proposte: Freedomotic. Analizzeremo la sua archi- tettura e le funzionalità offerte che hanno permesso la realizzazione degli scenari. Successivamente entreremo nel dettaglio del protocollo MQTT, un protocollo specifico per IoT, supportato dal software utilizzato; questo ci consentirà di connettere dispositivi, interni all’ambiente, con il sistema. Nell ultima parte del capitolo, verrà discussa la realizzazione finale del progetto. 3.1 Freedomotic 3.1.1 Cos’è Freedomotic Il software scelto per realizzare l’idea di questa tesi è Freedomotic. E’ un fra- mework open-source, gratuito che permette di disegnare e progettare sce- nari ed utilizzare domotica al suo interno. E’ possibile creare qualsiasi tipo di ambiente: dalla singola cameretta ad una casa intera ad un ufficio. Il punto di forza di questo programma è la possibilità di integrarsi con molti protocolli specifici di IoT vedi MQTT(Cap.3.2) ed utilizzarli per far comu- nicare gli oggetti virtuali con quelli reali; ovvero avere un modello della propria idea sul software e riproporla nella realtà tale quale la progettazio- ne fatta in precedenza. E’ possibile installare Freedomotic sulle seguenti piattaforme:
  24. 24. 20 Capitolo 3. Realizzazione scenari • Linux • Windows • Mac • Raspberry Pi Altro punto forza di questo software è, come si può notare, la portabilità. Portabilità raggiunta grazie all’utilizzo di Java come linguaggio di sviluppo. Gli sviluppatori di Freedomotic si sono posti una mission con lo sviluppo di questo framework ed è la seguente: "Develop an application framework which reduces effort and time to maket required to produce solutions based on the Internet of Things concept. This means we are making the environment aware of the People and the Things in it. Things can reach a new level of usefulness thanks to their new connected nature, allowing them to leverage the web and all the information based Services it provides."[9] Ovvero cercare di realizzare un software che riduca il tempo e gli sforzi per progettare e sviluppare un ambiente basato sul concetto di IoT. Analizziamo ora il suo funzionamento. 3.1.2 Primo impatto Il primo impatto con Freedomotic è quello di aver di fronte un software molto semplice e adatto alla progettazione di ambienti. Come si può nota- re dall’immagine 3.1, esso si presenta con due interfacce: riga di comando e una GUI(Graphical User Interface) che risulta essere un plugin installato sul core centrale, che può essere anche disabilitato mantenendo solo l’utilizzo della riga di comando. La versione per non sviluppatori non fornisce l’av- vio da riga di comando ma consente di avviare il programma solo da file eseguibile. L’interfaccia a riga di comando ci permette di visualizzare tutti gli avvenimenti che accadono all’interno del framework. La GUI presenta sulla sinistra un frame che visualizza la lista dei plugin o
  25. 25. 3.1. Freedomotic 21 FIGURA 3.1: Schermata iniziale freedomotic la lista degli oggetti inseribili nell’ambiente. Da qui è possibile inserire gli oggetti nell’ambiente sul frame di destra e cominciare a disegnare la propria idea. Nella sezione successiva ci addentreremo meglio nel funzionamento del software e analizzeremo le due componenti principali: framework e plugin. 3.1.3 Struttura La struttura principale di Freedomotic è composta da due parti fondamen- tali: framework e plugin. Analizziamole ora nel dettaglio. Framework • implementa un sistema indipendente di scambio messaggi in manie- ra tale da favorire l’utilizzo di un linguaggio di comunicazione tra oggetti che lo sviluppatore conosce di più (JSON, XML ecc...). • mantiene una struttura dati degli oggetti e degli ambienti che si sono creati
  26. 26. 22 Capitolo 3. Realizzazione scenari FIGURA 3.2: Architettura freedomotic • crea un layer di astrazione cosicché utenti o software esterni possa- no utilizzare una logica ad alto livello per comunicare con gli oggetti creati nel software. • fornisce un motore di regole unito ad un sistema linguaggio di natural processing che permette allo sviluppatore o all’utente di definire rego- le con l’utilizzo di comandi e trigger. Questa parte verrà approfondita maggiormente nelle sezioni successive. Plugin I plugin sono parti essenziali all’interno dell’intero software. Possono es- sere sviluppati indipendentemente dal funzionamento del core principale e possono essere successivamente integrati sfruttando le API [10] messe a disposizione. Una volta creati e compilati, vengono installati nel framework e saranno pronti all’utilizzo al primo avvio.
  27. 27. 3.1. Freedomotic 23 All’interno di freedomotic i plugin si dividono in due categorie: Object plu- gin e Device plugin. I primi servono per creare o modellare oggetti all’in- terno dell’ambiente mentre i secondi servono o per mettere in comunica- zione hardware esterno con il core o per sviluppare nuove idee da applicare agli scenari creati. L’immagine seguente illustra meglio l’utilizzo dei plugin. all’interno del software. FIGURA 3.3: Schema utilizzo plugin Events, commands, triggers e reactions Freedomotic e i plugin inviano eventi nel messaging bus quando avviene qualcosa all’interno dell’ambiente. Questo qualcosa può significare un cam- biamento di stato di un oggetto o di cambiamento di condizione all’interno delle varie stanze. Una volta che il cambiamento viene segnalato nell’appo- sito canale, gli oggetti interessati possono catturarlo e cambiare il proprio
  28. 28. 24 Capitolo 3. Realizzazione scenari if bathtub water level is 95% TRIGGER then turn off bathtub COMMAND REACTION FIGURA 3.4: Esempio reaction in Freedomotic comportamento . Ogni oggetto può essere programmato con dei comportamenti detti Beha- vior[11]; oltre ai behavior si possono scrivere dei comandi che esso può svolgere (Turn on light, set brightness ecc) e assieme a questi si possono creare dei trigger che vengono attivati a delle determinate condizioni che lo sviluppatore o un utente impone (Every five second, At 8.00 AM). E’ di- sponibile anche un plugin Automation editor che svolge le stesse funzioni di installazione dei trigger senza l’ausilio della programmazione. Il vantaggio di questo plugin è la facilità d’uso da parte dell’utente; lo svantaggio è che non si possono precaricare reazioni predefinite fin dal primo avvio del pro- gramma, cosa che risulta essere molto scomoda se il numero di funzioni da impostare è elevato. La combinazioni di comandi e trigger compongono una reactions, queste reazioni aiutano a programmare e adattare al meglio l’oggetto desiderato all’interno dell’ambiente. E’ possibile inoltre settare più azioni da eseguire allo scatto di un trigger (multi commands). Il vantaggio di questo sistema di natural processing, utilizzato per comporre trigger, comandi e reazioni, è la possibilità di poter utilizzare un linguaggio d’alto livello per settare i comportamenti degli oggetti, evitando così di do- ver scrivere codice a basso livello. Vediamo ora un esempio di struttura di una reaction: Sia i comandi, i triggers e le reazioni sono dei file di testo che vanno inseriti all’interno di cartelle specifiche presenti nella directory del plugin. Vediamo ora degli esempi semplici per programmare queste funzioni.
  29. 29. 3.1. Freedomotic 25 LISTING 3.1: Trigger 1 <t rigg er> 2 <name>When Bathtub water Level i s 95%</name> 3 <description>bad level of water</description> 4 <channel>app . event . sensor . object . behavior . change</channel> 5 <payload> 6 <payload> 7 <statement> 8 < l o g i c a l >AND</ l o g i c a l > 9 < a t t r i b u t e >object . behavior . waterLevel</ a t t r i b u t e > 10 <operand>GREATER_THAN</operand> 11 <value>94</value> 12 </statement> 13 </payload> 14 </payload> 15 </t rigg er> LISTING 3.2: Command 1 <command> 2 <name>Turn Bathtub off</name> 3 <receiver>app . events . sensors . behavior . request . objects</ receiver> 4 <description>Turn Turn Bathtub off</description> 5 <delay>0</delay> 6 <timeout>0</timeout> 7 <properties> 8 <properties> 9 <property name=" object " value=" Bathtub "/> 10 <property name=" behavior " value=" waterLevel "/> 11 <property name=" value " value=" 95 "/> 12 </properties> 13 </properties> 14 </command>
  30. 30. 26 Capitolo 3. Realizzazione scenari LISTING 3.3: Reaction 1 <reaction> 2 <t rigg er>When Bathtub water Level i s 95%</trig ger> 3 <sequence> 4 <command>Turn Bathtub off</command> 5 </sequence> 6 </reaction> Questo esempio forma una reaction che viene attivita al raggiungimento di un determinato livello d’acqua nella vasca da bagno. Una volta che il beha- vior waterLevel, appartenente all’oggetto bathtub, raggiunge una soglia pre- determinata (95%) scatta il comando che blocca l’uscita d’acqua dalla vasca. Come si può notare dagli esempi, il linguaggio usato per scrivere queste funzioni è XML . 3.2 MQTT per IoT Mqtt è un protocollo di comunicazione M2M (machine-to-machine) che si pone sopra al protocollo TCP/IP, il suo acronimo è il seguente Message Queue Telemetry Transport. Viene utilizzato nell’ambito IoT perché risulta essere un protocollo semplice, affidabile, leggero e aperto (royal free). E’ stato ideato per scambiare una grande quantità di messaggi tra macchine non appesantendo la rete ed evitando il "polling" dei dispositivi che lo utilizzano. E’ utile per connessioni remote dove la banda è scarsa e il dato da invia- re richiede pochi byte; per esempio, viene utilizzato per comunicazioni tra sensori o in uno scenario di device con poca capacità computazionale.[12] Nei paragrafi successivi verrà trattata la struttura del protocollo MQTT nei suoi aspetti principali e successivamente verrà discusso l’utilizzo di questo protocollo all’interno del software Freedomotic.
  31. 31. 3.2. MQTT per IoT 27 3.2.1 Modello publish - subscribe Il modello utilizzato per il protocollo MQTT risulta essere il modello Pu- blish - Subscribe. Esso è un messaging pattern dove colui che invia il mes- saggio (chiamato publisher) non programma l’invio direttamente allo spe- cifico ricevente (chiamato subscriber), ma pubblica il messaggio su un topic all’interno di un oggetto chiamato broker.[13] Il broker è un componente che si occupa di effettuare il matching tra pu- blisher e subscriber ed una volta effettuato, consegnerà il messaggio al de- stinatario corretto. La comunicazione tra i vari componenti è asincrona e bidirezionale ovvero la consegna e lettura del messaggio avverranno quando il dispositivo si troverà in una situazione che gli garantirà la ricezione e la lettura dei dati arrivati. Nel caso in cui un dispositivo non possa ricevere im- mediatamente un messaggio di un topic a cui è iscritto, il messaggio verrà congelato e consegnato appena possibile, evitando così di perdere messag- gi a causa dell’impossibilità di ricezione da parte del destinatario. Questo meccanismo garantisce un livello di QoS. 3.2.2 QoS Il QoS è una caratteristica molto importante di questo protocollo, in quanto rende più semplice, attraverso il meccanismo di ri-trasmissione, lo scambio di messaggi attraverso reti con bassa qualità[14]. Esistono 3 livelli di QoS: • QoS 0 - at most once: questo livello garantisce best effort delivery per il messaggio. E’ chiamato anche fire & forget perché non prevede la conferma di ricezione. • QoS 1 - at least once: il messaggio viene consegnato almeno una volta al ricevente.
  32. 32. 28 Capitolo 3. Realizzazione scenari FIGURA 3.5: Modello Publish-Subscribe • QoS 2 - exactly once: garantisce la consegna del messaggio una ed una sola volta al ricevente. E’ il livello di qualità più sicuro e più len- to. Come si può notare dalla fig 3.6, QoS 2 è garantito da due flussi publish e receive. FIGURA 3.6: Schema QoS
  33. 33. 3.2. MQTT per IoT 29 3.2.3 Topic Il topic è una stringa usata dal broker per filtrare i messaggi per ogni client connesso. Un topic può avere uno o più livelli. Ogni topic è separato dal carattere forward slash. In confronto ad una coda di messaggi, un topic è FIGURA 3.7: Scrittura topic molto leggero. Non c’è bisogno di crearne uno nuovo prima di pubblicare o sottoscriverne uno perché è il broker che si occupa di accettare ogni topic valido senza bisogno di un’inizializzazione. Il suo nome deve contenere almeno un carattere, può contenere spazi ed è case-sensitive. Esiste un operatore speciale # che permette di sottoscrivere più livelli di un topic, esso è detto multilevel. Un client che sottoscrive un topic utilizzando il multilevel riceverà tutti i messaggi che cominciano per un dato pattern prima del carattere #. Come si può notare dall’immagine FIGURA 3.8: Topic multilevel 3.8, colui che è sottoscritto a questo topic riceverà informazioni da tutti i livelli sottostanti al topic freedomotic.
  34. 34. 30 Capitolo 3. Realizzazione scenari Sicurezza Si sta La sicurezza nel mondo IoT è molto importante a maggior ragione quando si tratta di interagire con un ambiente personale. Attualmente ogni device ha la possibilità di connettersi ad Internet per comunicare e scambia- re informazioni per poi successivamente ottimizzare processi, migliorare il nostro stile di vita ed aumentare il nostro comfort. In un ambiente domotico la sicurezza degli oggetti connessi è molto importante perché essi raccolgo- no informazioni sul nostro stile di vita e informazioni personali. Proteggere questi dati da malintenzionati risulta essere fondamentale per aumentare la propria privacy. La sicurezza in MQTT è divisa in questi layer application level, transport le- vel, network level. Ogni layer previene differenti tipi di attacchi. Non tut- ti i meccanismi di sicurezza sono presenti ma solo alcuni, i quali però of- frono sicurezza allo stato dell’arte. Analizziamo ora la sicurezza nei layer interessati: • application level: in questo layer troviamo come meccanismo di sicu- rezza l’autenticazione. Viene fornito una login attraverso l’utilizzo di username e password. L’implementazione varia a seconda del broker utilizzato. I meccanismi più usati risultano essere l’utilizzo del certifi- cato X.509 o l’utilizzo meno sicuro di id affiancati alle credenziali. • transport level: qui viene utilizzato o il protocollo TLS o il protocollo SSL. Questo meccanismo non riguarda MQTT ma riguarda il protocol- lo TCP/IP. In alternativa all’utilizzo di questi è disponibile una cifra- tura del pacchetto MQTT attraverso l’utilizzo di algoritmi di cifratura simmetrica o assimetrica. Lo svantaggio nell’utilizzo di encryption per i pacchetti MQTT è l’u- tilizzo di ulteriori risorse, quindi consumo maggiore di energia in di- spositivi con capacità di calcolo e batteria limitate.
  35. 35. 3.3. Applicazione pratica 31 • network level: in questo livello vengono utilizzate VPN per collegare client e broker. MQTT fornisce molte possibilità per renderlo sicuro ma non esiste ancora la combinazione perfetta e la sicurezza, molto spesso, dipende dai casi di utilizzo. [15] 3.3 Applicazione pratica Parliamo ora di come sono stati realizzati gli scenari attraverso l’uso di Free- domotic. Per la realizzazione, sono stati scritti due plugin che identificano gli ambienti progettati. La parte iniziale si è concentrata inizialmente sulla creazione degli scena- ri: abitazione e ufficio. Essi sono stati disegnati grazie all’editor grafico a disposizione. Successivamente si è passati alla realizzazione degli ogget- ti non presenti nella suite iniziale che verranno poi inseriti all’interno del designer all’avvio del plugin. Le reazioni viste nel Cap. 2 sono distribui- te all’interno degli oggetti, all’interno del codice come controlli runtime di determinati parametri e come combinazione di trigger e commands che for- mano una reaction. Quelle scritte all’interno del plugin riguardano princi- palmente l’interazione ambiente-persona. Questo è dovuto al fatto che non è possibile, attraverso il solo uso di oggetti, creare un sistema che racchiuda tutti gli aspetti descritti in precedenza; è necessaria una maggiore integra- zione tra ambiente e reazioni che è possibile ottenere solo attraverso funzio- ni programmate internamente al software. Per una completa simulazione, sono stati inseriti all’interno del plugin la creazione e il posizionamento di persone nel designer. Gli oggetti che rappresentano le persone sono sta- ti modificati per simulare una condizione di malessere prevista nella fase progettuale. Per quanto riguarda la gestione della priorità nell’esecuzione di azioni il sistema controlla prima chi effettua una richiesta, se questa do- vesse venire da parte di una persona con problematiche, essa viene favorita
  36. 36. 32 Capitolo 3. Realizzazione scenari rispetto ad un’azione voluta da una persona sana. Per esempio: se la perso- na con problematiche setta la temperatura dell’ambiente ad un certo valore e quella in salute vuole modificarla ad un valore differente, il sistema non accoglie quest’ultima lasciando la temperatura invariata rispetto all’impo- stazione precedente. In generale l’identificazione di una persona avviene attraverso il controllo di un parametro apposito dell’oggetto, che ne identi- fica lo stato (sano, problematiche leggere, problematiche gravi). Configurati tutti i dispositivi necessari ci troviamo di fronte ad uno scenario statico privo di movimento. Per simulare al meglio i movimenti delle per- sone è stato necessario creare un nuovo plugin che permette di impostare un movimento guidato attraverso le stanze presenti. Grazie al moto delle persone attraverso le stanze ed alle reazioni impostate, risulta essere ben vi- sibile il comportamento del sistema che è stato progettato (vedi Cap.2). A completare la configurazione si è reso necessario utilizzare MQTT come protocollo di comunicazione per controllare da remoto l’ambiente. Al gior- no d’oggi grazie a smartphone, tablet e notebook accedere ai nostri sistemi è diventato molto facile anche se non siamo collegati direttamente a loro. Questo ci permette di avere un maggiore controllo sui nostri dispositivi an- che se non siamo a casa. Freedomotic consente l’invio di dati da remoto. Per far questo esso dispone di vari plugin che consentono la connessione dall’esterno, tra questi sono presenti un broker MQTT e un client MQTT. Essi sono entrambi scheletri che consentono un utilizzo basilare della comunicazione tra oggetti all’in- terno e all’esterno dell’ambiente di simulazione. Per configurare gli oggetti in modo tale da ricevere e trasmettere dati at- traverso MQTT, bisognare settare l’impostazione d’ascolto dal pannello di ognuno di essi. E’ presente una limitazione nella struttura del client: non è possibile inviare più parametri di configurazione attraverso un singolo messaggio. Questo ostacolo è stato superato grazie ad una modifica del client che verrà descritta nel par. 3.3 Nei paragrafi successivi verrà illustra- to come viene utilizzato il protocollo MQTT per comunicare con gli oggetti
  37. 37. 3.3. Applicazione pratica 33 all’interno dei vari scenari e verranno descritti brevemente i software ester- ni adoperati che lo sfruttano per simulare molteplici condizioni all’interno degli ambienti. Software utilizzati I software utilizzati per il controllo da remoto dell’ambiente sono: • client MQTT [16] • Mosquitto broker [17] • MQTT spy [18] • MQTTool[19] Successivamente verranno elencate le modifiche e i modi d’uso dei vari software per adattarli ai vari scenari previsti. Client MQTT Il client MQTT fornito è programmato in Java ed utilizza le API apposite per il servizio MQTT: Eclipse Paho Java Client[20]. Esso risulta essere un mo- dello base essenziale che permette la sottoscrizione e la ricezione di valori direttamente del broker. Il nome del topic a cui ogni oggetto fa riferimento è formato da freedomotic/nome_ oggetto. Questa scelta è stata fatta per identi- ficare meglio il contesto a cui si fa riferimento. Il contenuto del messaggio è composto da un solo parametro di configurazione, senza specificare quale sia. Viene automaticamente indirizzato al behavior settato in ascolto. Come scritto in precedenza, questo approccio pone delle limitazioni per- ché se un oggetto dovesse possedere più parametri di configurazione da poter settare (es. temperatura forno e timer accensione) risulta impossibile poterlo fare. Una correzione importante è stata quella di riscrivere un nuo- vo client MQTT che accettasse l’invio di più dati agli oggetti presenti nella simulazione. La possibilità di gestire più parametri è data dall’utilizzo di
  38. 38. 34 Capitolo 3. Realizzazione scenari espressioni regolari; la formula utilizzata per la composizione del payload del messaggio è la seguente: NOME_BEHAV IOR : V ALORE; (3.1) Con il codice 3.4 vine mostrato un esempio di messaggio inviato ad una lampadina sfruttando il nuovo settaggio del payload. Questa modifica è interna al plugin e non va a modificare parametri del protocollo MQTT ma solo il contenuto del messaggio. LISTING 3.4: Esempio messaggio MQTT 1 <MqttMessage 2 id=" 24 " 3 timestamp=" 1483377385941 " 4 topic=" freedomotic/livingroom_ligth " 5 qos=" 0 " 6 retained=" f a l s e "> 7 powered:1 ; brightness:50 8 </MqttMessage> Come si può notare dalla figura il pacchetto è composto da un id, un time- stamp, il topic (par. 3.2.3) e il valore di QoS (par. 3.2.2). Analizzando il con- tenuto del messaggio si può vedere che la scrittura 3.1 va ripetuta per ogni parametro dell’oggetto che si vuole settare. In questo modo viene elimina- ta la limitazione di un unico valore di configurazione per oggetto. Grazie alla possibilità di comunicare sul canale degli eventi di Freedomotic, ogni cambio di stato viene individuato e inviato tramite evento all’oggetto che acquisirà il proprio valore. Per rendere il client più funzionale è stata introdotta lo sottoscrizione runti- me di ogni oggetto presente nel designer al topic freedomotic/NOME_ STAN- ZA/NOME_ OGGETTO cosicché si possa avere un controllo remoto comple- to di ogni oggetto presente.
  39. 39. 3.3. Applicazione pratica 35 Mosquitto broker L’oggetto che si occupa di gestire tutti i topic, come descritto nel paragrafo 3.2.1 è il broker. Per l’utilizzo pratico inizialmente si è fatto affidamento ad un broker locale, successivamente invece si è deciso di optare per un broker esterno. Il vantaggio dell’esternalizzazione è quello di non dover preoccu- parsi della successiva manutenzione in fase di utilizzo. L’indirizzo di rete del broker gratuito fornito da Mosquitto[17] e’: test.mosquitto.org:1883. Questo viene utilizzato sia dal broker che dai vari client che vogliono inviare o ricevere messaggi riguardanti gli oggetti che sono connessi. Utilizzando questo fornitore, non è possibile autenticare o cifrare i messaggi perché essendo gratuito i servizi offerti sono limitati. Esistono altre possibilità per poter utilizzare broker più avanzati che of- frono meccanismi di sicurezza avanzati[21]. Una volta settati il broker, il client Freedomotic e gli oggetti con cui si vuole interagire si può passare alla comunicazione con loro. MQTT spy e MQTTool Per interagire con gli oggetti è stato necessario utilizzare software esterni. I software utilizzati sono: MQTT spy e MQTTool. MQTT spy è un programma free utilizzato su piattaforma Windows R scritto in Java che consente di: • sottoscrivere più topic • ricevere messaggi da più topic • controllare le statistiche dei messaggi • connettersi a più broker Queste funzioni lo rendono un software flessibile e completo per poter mo- nitorare da desktop tutti gli oggetti che inviano e ricevono messaggi. Inoltre
  40. 40. 36 Capitolo 3. Realizzazione scenari FIGURA 3.9: Schermata iniziale MQTT spy esiste la possibilità di poter inviare a sua volta dati per cambiare il compor- tamento di questi. La GUI risulta essere molto semplice e intuitiva come si può notare dall’immagine 3.9 ed una volta settata la connessione con i pa- rametri scritti precedentemente è possibile inviare e ricevere dati. Per poter comunicare in mobilità con gli oggetti domotici presenti in Freedomotic è stato scelto di utilizzare MQTTool un’app gratuita presente su App Store R . Quest’applicazione presenta le medesime funzionalità di MQTT spy; una volta configurati i parametri di connessione è pronta all’uso per dialogare in remoto con i dispositivi presenti nei vari scenari. E’ possibile inoltre set- tare il livello di QoS per i messaggi da inviare secondo le specifiche trattate nel paragrafo 3.2.2. Modalità d’uso L’utilizzo di una delle due applicazioni permette di controllare e simulare vari comportamenti degli oggetti. Modificando i parametri si possono far scattare le reactions descritte nel Cap.2. Oltre che poter inviare dati, è pos- sibile ricevere informazioni da ogni oggetto o sensore presente.
  41. 41. 3.3. Applicazione pratica 37 Modificando il client MQTT di Freedomotic è stato possibile inviare messag- gi per poter simulare tutti i comportamenti di tutti gli oggetti, ottendo così una visione e un controllo completo della situazione dell’ambiente. Tutto questo è risultato possibile grazie all’utilizzo del protocollo MQTT. Vedia- mo ora esempio di simulazione di reaction: blocco uscita acqua dalla vasca da bagno. Viene simulata da remoto il superamento della soglia prefissata del livello dell’acqua e grazie a questo viene attivata la reactions che blocca la fuoriuscita, come si può vedere in fig. 3.10. Questa viene segnalata su Freedomotic come avviso e viene anche ricevuta sul topic dell’oggetto inte- ressato. FIGURA 3.10: Reaction in azione Senza l’utilizzo di questo protocollo la simulazione degli scenari sarebbe ri- masta limitata solo all’utilizzo di Freedomotic ovvero fine a se stessa. Grazie a MQTT è stato possibile interfacciare il software al controllo remoto simu- lando avvenimenti casuali permettendo così di verificare la configurazione del sistema di azioni installato all’interno del simulatore. Utilizzando il framework di lavoro e il protocollo di comunicazione è stato
  42. 42. 38 Capitolo 3. Realizzazione scenari possibile realizzare le idee proposte verificandone così la fattibilità e la fun- zionalità. Simulando situazioni critiche si è potuto inoltre valutare il com- portamento del sistema progettato. Tutto questo è stato possibile grazie alla flessibilità che Freedomotic permette attraverso la scrittura di plugin esterni al core centrale, non intaccando così il codice originale ma arricchendolo di ulteriori funzionalità.
  43. 43. 39 Capitolo 4 Conclusioni Oggigiorno ci troviamo in un mondo in cui la tecnologia è parte integrante della nostra vita. Siamo circondati da smartphone, tablet e computer, ma siamo anche pervasi da dispositivi invisibili che controllano gli oggetti più comuni: dal nostro televisore alla nostra macchina. Questa nuova ondata di apparecchi connessi sta cambiando il nostro modo di vivere. Una disciplina che sta traendo vantaggio da questo cambiamento è la domotica. Essa si propone come obiettivo principale quello di migliorare la qualità della vita delle persone. La maggior parte del tempo viene trascorso tra la casa e l’ambiente di lavoro ed è qui che l’inserimento della componente domotica può portare grandi benefici. Con questo lavoro si è voluto progettare e analizzare un sistema intelligente da inserire in questi scenari. Si è cercato di capire come integra- re le nuove tecnologie in questi ambienti progettando tutto il sistema nella sua interezza. Gli aspetti messi in risalto con questo lavoro sono il comfort generale e l’inserimento della possibilità di assistere le persone con proble- mi di salute. Queste due caratteristiche sono state evidenziate sia per la casa che per l’ufficio. Il primo passo compiuto per la progettazione è stato quello di stendere un’architettura. Durante questa fase si è dovuto tenere conto della diversità che le situazioni richiedono: una casa, in cui le persone preferiscono non dover provvedere ad operazioni tecniche riguardanti il sistema ed un uffi- cio, in cui la fase di manutenzione può essere svolta internamente. Questa
  44. 44. 40 Capitolo 4. Conclusioni divisione ha portato alla scelta di utilizzare un cloud esterno per l’ambiente domotico mentre per l’ambiente lavorativo la scelta è ricaduta su un server interno. Progettata l’architettura si è passati alla fase di composizione del sistema, sono state scelte le azioni da inserire (vedi Cap.2) per ottenere un funziona- mento adeguato ai due ambienti. Si è voluto dare peso alle azioni automati- che e non, che possono esserci, integrate con i valori rilevati dai dispositivi presenti. L’integrazione e l’interoperabilità dei device risulta essere fonda- mentale per un corretto funzionamento. Una parte delle azioni progettate è dedicata all’interazione tra device medici che misurano parametri vitali e reagiscono o avvisando la persona o direttamente chiamando il pronto soccorso in casi gravi. Questa analisi riferita all’assistenza medica potreb- be portare dei vantaggi in caso si dovesse realizzare realmente un sistema intelligente che integri queste caratteristiche, in quanto la tempistica in de- terminati casi, può fare la differenza. Una volta terminata la fase di progettazione si è passati alla realizzazio- ne pratica attraverso l’utilizzo di Freedomotic che è un framework open- source che permette di simulare ambienti integrando la componente domo- tica. Grazie ad esso si è potuta verificare la fattibilità della progettazione e sperimentare le nuove idee proposte. Per simulare al meglio l’interope- rabilità degli oggetti creati nel simulatore, si è fatto uso di un protocollo di comunicazione adatto: MQTT. Questo è un protocollo molto usato nel- l’ambito IoT perché risulta essere molto leggero. Grazie alla combinazione di Freedomotic e MQTT si è potuto realizzare una simulazione con eventi casuali atti a testare il sistema. Queste prove hanno consentito di trovare i difetti e correggerli per ottenere un funzionamento migliore. Questo lavoro potrà successivamente essere testato su un ambiente reale at- traverso l’uso di device fisici per ottenere dati reali. Ottenendo una mole di dati superiore, si possono testare tecniche di machine learning per cer- care di capire al meglio le abitudini delle persone presenti negli ambienti,
  45. 45. Capitolo 4. Conclusioni 41 realizzando così una banca dati da cui poter attingere informazioni. Aven- do a disposizione sempre più dati sarà possibile quindi ottenere un miglior funzionamento del sistema sia dal punto di vista del risparmio energetico sia dal punto di vista di aumento del comfort cercando così di aiutare le persone e migliorare la loro qualità di vita.
  46. 46. 43 Bibliografia [1] Domotica. URL https://it.wikipedia.org/wiki/Domotica. [2] M.longo, MC. Roscia, D. Zaninelli. Net Zero Energy of smart house design. International Conference on Clean Electrical Power, pages 548–554, 2015. [3] S. Ventylees Raj. Implementation of pervasive computing based high-secure smart home system. IEEE International Conference on Computational Intelligence and Computing Research, pages 1–8, 2012. [4] Artur Balanuta, Ricardo Lopes Pereira, Carlos Santos Silva. PerO- MAS: Personal Office Management and Automation System. Inter- national Conference on Distributed Computing in Sensor Systems, pages 31–39, 2015. [5] Ahmed ElShafee, Karim Alaa Hamed. Design and Implementation of a WiFi Based Home Automation System. World Academy of Science, Engineering and Technology, pages 2177–2180, 2012. [6] S. de Miguel-Bilbao, J. Roldán, J. García, F. López , P. García-Sagredo, V. Ramos. Comparative Analysis of Indoor Location Technologies for Monitoring of Elderly . IEEE 15th International Conference on e-Health Networking, Applications and Services (Healthcom 2013), pages 320–323, 2013.
  47. 47. 44 BIBLIOGRAFIA [7] Serge Offermans, Aravind Kota Gopalakrishna, Harm van Essen, Tanir Özçelebi. Breakout 404: A smart space implementation for lighting ser- vices in the office domain. Ninth International Conference on Networked Sensing (INSS), pages 1–4, 2012. [8] Hang Li. A novel design for a comprehensive smart automation sy- stem for the office environment. IEEE Emerging Technology and Factory Automation, pages 1–4, 2014. [9] Mission freedomotic. URL http://freedomotic.com/content/ learn-more. [10] API freedomotic. URL http://api.freedomotic.com:9111/. [11] Lista behavior. URL http://freedomotic-developer-manual. readthedocs.io/en/latest/things/ create-new-thing-types.html#predefined-behaviors. [12] Protocolo MQTT. . URL www.mqtt.org. [13] Message pattern Publish - Subscribe. URL https://en. wikipedia.org/wiki/Publish%E2%80%93subscribe_ pattern. [14] Davide Pozza. MQTT: il protocollo che ren- de possibile l’Internet Of Things. 2015. URL http://www.smau.it/milano15/schedules/ mqtt-il-protocollo-che-rende-possibile-linternet-of-things/. [15] Introducing the MQTT security fundamen- tals. URL http://www.hivemq.com/blog/ introducing-the-mqtt-security-fundamentals. [16] MQTT client Freedomotic. URL http://freedomotic.com/ content/plugins/mqtt-client.
  48. 48. BIBLIOGRAFIA 45 [17] MQTT broker test Mosquitto.org. URL http://test.mosquitto. org/. [18] MQTT spy. . URL https://kamilfb.github.io/mqtt-spy/. [19] MQTTool for iPhone R . . URL https://itunes.apple.com/us/ app/mqttool/id1085976398?mt=8. [20] API Java per programmazione MQTT. URL https://eclipse. org/paho/clients/java/. [21] Advanced broker for MQTT. URL http://www.hivemq.com/ features/.

×