Progetto e sviluppo di un'architettura modulare e multiprotocollare per la gestione di sistemi domotici

(1)

(2)

Indice

1 Introduzione 6

2 Domotica 9

2.1 I vantaggi della domotica . . . 12 2.1.1 Risparmio energetico . . . 12 2.1.2 Comfort . . . 13 2.1.3 Supporto a disabilit`a psicomotorie . . 14 2.2 Prodotti commerciali . . . 15 2.2.1 Virtuoso Home [Ecodhome] . . . 15 2.2.2 Di-BOSS [Selex ES] . . . 17 2.2.3 Clever Energy Manager [Connet] . . 18

3 Descrizione dell’architettura 20

3.1 Home Gateway . . . 22

(3)

3 3.2 Domotic Coordinator . . . 23 3.2.1 Decisore . . . 25 3.2.2 Database . . . 26 3.2.3 Parser dati . . . 27 3.2.4 Interprete comandi . . . 27

3.2.5 Controllore dell’operativit`a dei sistemi 28 3.2.6 Multicast sender . . . 28

3.3 Interfacce utente . . . 29

4 Implementazione 30 4.1 Sip Home Gateway . . . 31

4.1.1 Session Initial Protocol . . . 33

4.1.1.1 ZigBee . . . 36

4.1.1.2 Topologia di rete . . . 37

4.2 Domotic Coordinator . . . 39

4.2.1 Database . . . 40

4.2.1.1 Tabella SUBSYSTEMS . . 40

4.2.1.2 Tabella NOME SUBSYSTEMS 41 4.2.1.3 Tabella COMMANDS . . . 42

4.2.1.4 Tabella SUBSCRIBERS . . 43

4.2.2 DB connector . . . 43

4.2.3 Interfaccia SIP fra DC e SHG . . . . 45

(4)

4

4.2.5 Subscriber . . . 47

4.2.6 Controllore dello stato dei sistemi . . 48

4.2.7 Interfaccia SIP fra DC e User Agent 49 4.2.8 Interfaccia Web Service Rest . . . 50

4.2.8.1 Cenni ai Web Service . . . . 50

4.2.8.2 Implementazione . . . 51

4.2.8.3 REST listener . . . 52

4.2.9 Interprete dei comandi . . . 53

4.2.10 Multicast Sender . . . 54

4.2.11 Decisore . . . 55

4.2.12 Main . . . 57

4.3 Applicazione Android . . . 57

4.3.0.1 Notifiche Push . . . 59

5 Validazione tramite lo sviluppo di un prototi-po 62 5.1 Implementazione del decisore . . . 63

5.2 Configurazione del Database . . . 66

5.3 Configurazione e adattamento Home Gateway 67 5.4 Configurazione dei client . . . 68

5.5 Svolgimento demo . . . 70

5.5.1 Inizializzazione . . . 71

(5)

INDICE 5

5.5.3 Invio comandi di subscribe . . . 75 5.5.4 Invio comando non lecito . . . 76 5.5.5 Uscita dalla configurazione critica . . 77 5.5.6 Esecuzione automatica decisore . . . 77

(6)

Capitolo 1

Introduzione

Negli ultimi anni il mercato della domotica ha vissuto, in Italia e nel mondo, un notevole sviluppo; si stima una cre-scita media annua del mercato che supera il 30%, motivo per cui aziende e enti di ricerca hanno fatto investimenti per lo sviluppo di nuove soluzioni in ambito domotico, che possono consistere in soluzioni per la sicurezza, il rispar-mio energetico e la razionalizzazione dei consumi delle case, all’intrattenimento e tempo libero fino alla salute e all’assi-stenza degli utenti. In questo lavoro di tesi si descriver´a la progettazione e l’implementazione di un’architettura,

(7)

1. Introduzione 7

dulare e multiprotocollare, concepita con lo scopo di fornire un set di strumenti utili alla realizzazione di un coordinatore domotico che abbia il compito di amministrare una molti-tudine di sottosistemi domotici coordinando, nella maniera pi´u opportuna e in modo automatico, i comandi inviati da-gli utenti utilizzatori dei sottosistemi.

La scelta di sviluppare tale architettura deriva dalla tesi se-condo la quale le scelte che possono essere effettuate all’in-terno di un particolare sottosistema (ad esempio per quanto riguarda il risparmio energetico) in maniera pi´u precisa e pi´u ottimizzata se l’elemento che si occupa di compiere la scelta ha una conoscenza globale di tutti i sottosistemi nella loro interezza, avendo quindi delle conoscenze estrinseche al sottosistema in esame.

Nel prosieguo della tesi si andrá dunque a descrivere il con-cetto di domotica, che cosa é, a cosa serve ed alcuni prodotti commerciali esemplificativi e come questi si differenzino ri-spetto alla nostra soluzione. Verrá poi descritta la struttura dell’architettura della nostra soluzione e come questa sia stata implementata, garantendo l’estendibilitá a differenti protocolli e tecnologie in realtiva semplicitá; vedremo infine la realizzazione di un prototipo funzionante con lo scopo di

(8)

1. Introduzione 8

validare l’architettura e mostrare le potenzialit´a e i vantaggi che questa porta.

(9)

Capitolo 2

Domotica

Il termine domotica deriva dal neologismo francese do-motique, a sua volta contrazione della parola greca domos

(10)

2. Domotica 10

(casa, costruzione) e di automatique (automatica; secondo altri informatique, informatica): quindi letteralmente casa automatica.[8]

Con questo termine si vanno ad identificare tutte quelle tec-nologie integrabili e controllabili in ambito residenziale, ap-portando cos`ı benifici all’utilizzatore in termini di efficienza, sicurezza, funzionalità, estetica, tutto questo in conformità alle normative vigenti ed alle regole dell’arte. Automatiz-zare, coerentemente e correttamente, un edificio valorizza l’immobile stesso; si tratta questo di un dato oggettivo e non di una valutazione soggettiva. Ad esempio infatti l’al-legato A della norma tecnica CEI 64-8-V3 [1] afferma che, utilizzando la domotica, si raggiunge un livello massimo di prestazione (Livello 3) e di fruibilità di un impianto. Citan-do la norma questa definisce il livello 3 come “[...] il livello domotico destinato all’utente che sceglie una casa ai massi-mi standard di efficienza, sicurezza e comfort [...] consente di disporre della più avanzata tecnologia domotica: gestio-ne automatica dei carichi e dei consumi, sensori di sicurezza [...] tutto controllabile da remoto anche quando non si è in casa attraverso il cellulare o il pc.”

(11)

ca-2. Domotica 11

paci di comunicare tra loro e interagire in maniera omo-genea, perci`o le comunicazioni tra il singolo dispositivo e i vari sottosistemi, siano esse cablate o senza fili, sono di vitale importanza per il corretto funzionamento dei sistemi domotici.

I componenti fondamentali di qualunque sistema domotico sono l’insieme dei sensori e degli attuatori; questi general-mente vanno a formare una o più reti e ,tra tutte, quelle che si stanno imponendo con maggior successo sono le Wireless Sensor Network (WSN); ciò sta accadendo principalmente perchè la tecnologia senza fili permette una maggior facilità nell’installazione e nella configurazione della rete, consen-tendo inoltre di poter installare un sistema domotico anche successivamente alla costruzione del fabbricato anche l`ı dove non era stato previsto in fase di progettazzione. Per l’im-plementazione delle WSN sono al giorno d’oggi disponibli diversi standard e tecnologie, nati con l’intento di favorire l’interoperabilità tra dispositivi resi disponibili da differenti produttori, come ZigBee, Z-Wave o KNX che sono ormai largamente diffusi e adottati dalla stragrande maggioranza delle aziende produttrici.

(12)

2.1. I vantaggi della domotica 12

2.1 I vantaggi della domotica

Le applicazioni domotiche consentono di ottenere un sensi-bile risparmio energetico a vantaggio del bilancio economi-co dell’utente e alla salute globale del pianeta, migliorare il comfort domestico e può significare inoltre un aiuto con-creto a tutti quegli utenti con difficoltà motorie, permet-tendo di abbattere le barriere architettoniche e tutti quegli ostacoli che possono rendere complicate anche le azioni più naturali.[1]

2.1.1 Risparmio energetico

In fase d’uso e di esercizio del sistema domotico è possi-bile ottenere dei notevoli risparmi riconducibili a circa il 25% per costi energetici rispetto ai sistemi tradizionali [2], questo grazie a comandi automatizzati (spegnimento degli impianti in assenza di chi occupa i locali o accensione di questi poco prima che rientrino) e al controllo degli scenari (ad esempio l’accensione automatica degli elettrodomesti-ci secondo le fasce orarie economicamente più vantaggiose oppure quando l’accensione di più utenze comporterebbe il superamento della potenza disponibile, oppure prefissando

(13)

un tetto massimo di budget di spesa che, qualora raggiunto, ne determini la disattivazione secondo un ordine preventi-vamente stabilito). Per poter operare al meglio, un siste-ma di controllo di un edificio ad alta efficienza deve poter comandare e monitorare gli impianti in funzione di:

• stato di funzionamento dei vari impianti; • presenza di persone;

• condizioni climatiche esterne; • condizioni climatiche interne;

• produzione locale energia elettrica/termica;

• sistema di schermatura delle superfici vetrate etc...

2.1.2 Comfort

L’integrazione dei sistemi consente di aumentare il com-fort nella casa automatizzando azioni della routine quoti-diana guadagnando in praticit`a e permettendo di rispar-miare tempo e fatica. Rendendo la casa in grado di verifi-care autonomamente i cambiamenti dei fattori ambientali `

(14)

degli scenari che si attivino automaticamente in presenza di determinati fattori, come ad esempio:

• sollevare o abbassare le tapparelle in orari diversi a seconda del giorno della settimana;

• azionare automaticamente l’irrigazione del giardino in funzione della temperatura e dell’umidit`a del terreno; • sollevare le tende o le veneziane in caso di vento e/o

pioggia;

• regolare autonomamente l’illuminazione artificiale in base a quella proveniente dall’esterno;

• diffusione sonora, aromaterapia, cromoterapia etc...

2.1.3 Supporto a disabilit`a psicomotorie

Un altro degli obiettivi principali della domotica è sempre stato quello di realizzare nuovi ausili per persone disabi-li, affette da handicap e per coloro che, a causa di malattie neurodegenerative o traumatiche, non hanno più il controllo volontario dei propri muscoli. A supporto della persona con disabilità è necessario far s`ı che i singoli sistemi che com-pongono la casa non siano indipendenti ma è fondamentale

(15)

2.2. Prodotti commerciali 15

che venga reso disponibile all’utente un sistema unico che comprenda tutte le funzioni di comunicazione ed autonomia di cui la persona necessita. Bisogna considerare la persona disabile come elemento attivo all’interno della struttura im-mobiliare, le strutture edili con cui entra in contatto devo-no poter interagire e consentire un grado di autodevo-nomia alla persona disabile; quindi l’ambiente e le tecnologie adottate dovranno necessariamente essere personalizzate sulla base delle esigenze dell’utilizzatore.

2.2 Prodotti commerciali

L’offerta di prodotti per la domotica `e ormai una realt`a consolidata; aziende leader nel settore come Selex ES, Bti-cino, ABB, Siemens, AMX, Schneider Electric propongono sul mercato tutta una serie di componenti per la realizza-zione e l’integrarealizza-zione di sistemi domotici. In questa serealizza-zione ne illustreremo , a titolo di esempio, alcuni.

2.2.1 Virtuoso Home [Ecodhome]

Virtuoso Home una piattaforma italiana che, mediante l’u-tilizzo di dispositivi di attuazione e di misura e

(16)

l’imple-2.2. Prodotti commerciali 16

mentazione di regole domotiche, consente di incrementare il comfort casalingo e di ottenere un risparmio energetico. Il sistema è composto da un gateway che consente il dialogo tra tutti i dispositivi ad esso collegati (senza fili) utilizzan-do il protocollo Z-Wave, ha un sistema operativo Linux e supporta connessioni, oltre al già citato Z-Wave, Ethernet, Wi-Fi 802.11 b/g/n e GSM/GPRS/3G; è poi possibile acce-dere al gateway da pc o smarphone per verificare il consumo e lo stato dei dispositivi.

Figura 2.1: Virtuoso Home

Andando a configurare il gateway sar`a quindi possibi-le ottenere una gestione integrata dell’impianto termico ed elettrico, avere un controllo costante dell’energia prodotta

(17)

da impianti fotovoltaici ed eolici, avere un controllo sul-la energia consumata, controlsul-lare sul-la temperatura di ciascun radiatore e agire da remoto sull’accensione o lo spegnimento delle utenze.

La soluzione offerta dalla Ecodhome si differenzia dal quella descritta in questo lavoro di tesi per alcune differenze sostanziali:

• vincola all’utilizzo esclusivo del protocollo Z-Wave; • l’accesso al gateway ´e fornito esclusivamente tramite il

software proprietario;

• non provede la possibilit´a di separare il dominio in sot-tosistemi indipendenti differenziando l’accesso a que-sti.

2.2.2 Di-BOSS [Selex ES]

Di-BOSS (Digital Building Operating System Solution) `e la soluzione di Smart Building sviluppata da Selex ES che permette di integrare tutte le informazioni provenienti dai sottosistemi di un edificio, fornendo un quadro completo dello stato dell’infrastruttura e favorendo cos`ı l’incremento

(18)

dei livelli di sicurezza. Il sistema utilizza i dati storici, inte-grandoli con quelli acquisiti in tempo reale, e altri dati come ad esempio le previsioni meteo o la presenza di persone, e li utilizza per fornire indicazioni operative necessarie alla riduzione del consumo energetico nell’edificio e delle emis-sioni di CO2, mantenendo inalterati i livelli di comfort degli occupanti.

Le differenze rispetto alla nostra soluzione sono:

• i sottosistemi considerati non sono sistemi indipenden-ti, ma sono distinti per destinazione d’uso;

• l’accesso al sistema ´e garantito esclusivamente tramite software proprietario;

• Di-BOSS fornisce esclusivamente indicazioni delle con-figurazioni ritenute pi´u performanti in quel momento, senza eseguire automaticamente le decisioni prese.

2.2.3 Clever Energy Manager [Connet]

Il Clever Energy Manager garantisce la gestione dell’im-pianto fotovoltaico estendendolo alla gestione dell’imdell’im-pianto nella sua interezza. Grazie a sensori amperometrici effettua le misurazioni della energia prodotta e scambiata verso la

(19)

rete ed analizza l’energia consumata dalle utenze fornendo un quadro completo della potenza prodotta e consumata, l’energia prodotta o acquistata o venduta, indicazioni per l’ottimizzazione dei consumi, permette inoltre di pilotare le utenze anche da remoto, tutto questo tramite PC, Tablet o Smartphone grazie ai software forniti nell’installazione.

A differenza del Domotic Coordinator, il Clever Energy Manager:

• vincola all’utilizzo esclusivo delle componenti domoti-che fornite dal produttore stesso;

• l’accesso al servizio ´e fornito esclusivamente tramite il software proprietario;

• non prevede la possibilit´a di separare il dominio in sot-tosistemi indipendenti differenziando l’accesso a que-sti;

• si limita a fornire indicazioni sull’ottimizzazione dei consumi.

(20)

Capitolo 3

Descrizione

dell’architettura

In questo capitolo andremo a descrivere l’architettura pro-gettata e sviluppata in questo lavoro di tesi, approfondendo le componenti cardine del sistema, e descrivendo ove neces-sario, eventuali protocolli e standard che sono stati utiliz-zati.

In Figura 3.1 `e possibile osservare una rappresentazione gra-fica dell’architettura nella quale sono stati inseriti i blocchi principali che la compongono: in ciascun sottosistema

(21)

3. Descrizione dell’architettura 21

ranno presenti dei Gateway con lo scopo di disaccopiare le reti di sensori e gli attuatori, dal piano di controllo; que-sti si andranno ad interfacciare con il Domotic Coordinator (DC) attraverso gli standard di comunicazione scelti; il DC avrá un ulteriore serie di interfacce per la comunicazione lato utenti, e conterrá al suo interno un inseme di moduli atti all’analisi del sistema, cardine dei quali é il decisore che avrá il compito di appunto decidere quali sono le attivitá da autorizzare o meno, in accordo con le regole implementate al suo interno. DB DOMOTIC COORDINATOR DECISORE Protocollo 1 Protocollo 1 HOME GATEWAY 1 HOME GATEWAY 2 HOME GATEWAY N Protocollo 2 Protocollo N Protocollo 2 Protocollo N Protocollo 2 Protocollo N Protocollo 1

(22)

3.1. Home Gateway 22

3.1 Home Gateway

Nel Capitolo 2 abbiamo visto come siano nati diversi stan-dard e tecnologie per l’implementazione delle Wireless Sen-sors Network (allo scopo di facilitare l’integrazione tra di-spositivi di differenti aziende produttrici); quello che manca `

e per`o un piano di controllo comune che permetta la gestio-ne dei compogestio-nenti, sia che essi implementino tutti lo stesso standard ma siano prodotti da aziende differenti, sia a mag-gior ragione che implementino standard tra loro differenti. Con l’implementazione di un Home Gateway si vuole anda-re a anda-realizzaanda-re un’architettura di tipo modulaanda-re nella quale siano presenti tante interfacce quanti sono i protocolli uti-lizzati nelle reti di sensori e attuatori DSAN (Domotics Sen-sor and Actuator Network) integrate nel sottosistema. Una ulteriore interfaccia che tramite uno specifico protocollo si occupi di mantenere la connetivit`a fra l’Home Gateway e il DC, ed infine un livello intermedio di astrazione che per-metta il disaccoppiamento tra i due domini del sistema e che si occupi di tradurre i messaggi da e per il particolare linguaggio della DSAN.

(23)

3.2. Domotic Coordinator 23 DOMOTIC COORDINATOR HOME GATEWAY Interfaccia Domotic Coordinator Interfaccia Gateway Interfaccia DSAN Livello di astrazione Device DSAN

Rete di trasmissione Rete DSAN

Figura 3.2: Home Gateway

3.2 Domotic Coordinator

Il Domotic Coordinator è l’elemento principale di questo lavoro di tesi, avrà il compito di interfacciarsi con i singoli sistemi domotici che dovrà amministrare (ovvero con i sin-goli Home Gateway installati in ogni sistema autonomo), ed inoltre dovrà interfacciarsi con le applicazioni gestite dagli utenti tramite le quali sarà possibile inviare e ricevere mes-saggi al DC. Nucleo del Domotic Coordinator è il decisore; questo, tramite le regole decise e impostate dall’amministra-tore, dovrà effettuare delle scelte andando a determinare se

(24)

3.2. Domotic Coordinator 24

Figura 3.3: Domotic Coordinator

le richieste inviate dagli utenti rispettino o meno le regole specificate e, in base a questo, decidere se soddisfare la ri-chiesta, bocciarla oppure metterla in coda nel caso in cui un cambio dello scenario potrebbe portare il comando a di-ventare lecito successivamente.

Le funzioni che quindi il Domotic Coordinator dovr`a svol-gere saranno:

• Ricevere i messaggi di update contenenti il valore dei sensori e lo stato degli attuatori, salvando la cronologia di questi in un Database.

(25)

• Determinare la raggiungibilit`a e l’operativit`a dei sot-tosistemi amministrati.

• Inviare comandi agli attuatori tramite gli Home Ga-teway.

• Ricevere le richieste dagli utenti e gestire una coda di queste.

• Effettuare le decisioni sulle richieste da soddisfare in accordo con le regole implementate nel decisore. • Comunicare agli utenti interessati ogni decisione presa

e ogni modifica effettuata nel sottosistema.

3.2.1 Decisore

Il ruolo del decisore deve essere quello di amministrare e coordinare le richieste degli utenti affinch`e queste non en-trino in conflitto con le regole decise in fase di implementa-zione; regole che devono essere formulate in base ai requisiti che si vogliono soddisfare nel sistema globale come ad esem-pio il risparmio energetico, consumo di potenza, sicurezza dei sistemi etc... Il decisore, andando ad analizzare lo stato dei sistemi in real time e la cronologia di questi memorizzata

(26)

nel database, potr`a decidere se rigettare la richiesta, accet-tarla o metterla in coda, oppure suggerire una soluzione alternativa che soddisfi la domanda senza andare incontro all’infrazione delle regole e dei requisiti di sistema.

3.2.2 Database

Nel database verranno memorizzati tutti quei dati utili al funzionamento e all’operatività del DC; al suo interno do-vranno essere inseriti i valori registrati nei sensori e gli stati degli attuatori registrando la cronologia di questi, e diffe-renziandoli per singolo sottosistema per facilitare una suc-cessiva analisi, sia da parte del decisore, sia da parte di altri elementi che debbano utilizzare questi dati (il DC control-lerà che gli aggiornamenti arrivino con la cadenza prefissata per verificare il corretto funzionamento del sistema e può essere previsto un modulo che analizzi i dati per la stima dei valori medi dei parametri di ciascun sensore). Nel da-tabase dovranno inoltre essere definite: la lista dei sistemi disponibili e la relativa interfaccia tramite la quale questi potranno comunicare con il DC, la coda dei comandi in lista d’attesa e la lista degli utenti interessati agli eventi in un particolare sistema grazie al quale il multicast sender (vedi

(27)

3.2.6) potr`a informare tutto il gruppo degli eventi occorsi nel sottosistema.

3.2.3 Parser dati

Ogni Home Gateway dovrà comunicare al DC i valori dei sensori e lo stato degli attuatori ad intervalli prefissati o nel caso cambi lo stato di uno dei dispositivi; questi verranno inseriti in un messaggio che il parser dati avrà il compito di analizzare e, dopo averli estrapolati dalla stringa, dovrà andare a memorizzare i parametri nel database inserendoli nella tabella relativa a quel particolare sistema domotico.

3.2.4 Interprete comandi

Nel DC dovranno essere previste alcune funzioni tramite le quali gli utenti potranno indicare la volontà di apportare cambiamenti allo stato dei sistemi o richiedere informazioni sullo stato di questi. L’interprete dei comandi dovrà quindi analizzare il comando invitato dall’utente andando ad indi-viduare che tipo di funzione questo vuole svolgere e qual è il sistema destinatario della richiesta; una volta ricavati quin-di il mittente, il tipo quin-di comando, e il destinatario passerà i

(28)

dati al decisore per l’analisi della fattibilit`a della richiesta.

L’interprete dei comandi, cos´ı come il parser dati visto nella sezione precedente, sono stati inseriti per permette-re il disaccoppiamento del decisopermette-re e le specifiche inter-facce implementate che possono cos´ı operare in maniera indipendente.

3.2.5 Controllore dell’operativit`a dei sistemi Il Domotic Coordinator tramite questo modulo esegue dei controlli ciclici per verificare che i sottosistemi amministrati siano raggiungibili e stiano effettivamente inviando gli up-date sullo stato dei componenti; in caso contrario il control-lore deve prevedere una procedura per ripristinare la conne-tivit`a tra l’Home Gateway e la relativa interfaccia presente nel DC.

3.2.6 Multicast sender

Il DC utilizzer`a questo modulo per inviare messaggi con-tententi gli eventi che accadono all’interno di un sistema e alle decisioni prese riguardo a questo a tutti quegli utenti

(29)

3.3. Interfacce utente 29

che, tramite una procedura di registrazione effettuata tra-mite comando apposito, sono autorizzati a ricevere le notizie riguardati quel particolare sottosistema domotico.

3.3 Interfacce utente

Data la natura multiprotocollare del DC sarà relativamente semplice implementare una moltitudine di client differenti, per permettere ad un utente di poter accedere alle funzio-nalità offerte tramite differenti dispositivi, reti d’accesso e protocollo di comunicazione; sarà quindi possibile inviare e ricevere messaggi da e per il DC con un particolare pro-tocollo, implementando il modulo relativo e fornendo agli utenti un applicazione che lo supporti. A seconda dei casi, e del protocollo in esame, gli utenti potranno usare delle applicazioni di messaggistica già esistenti sul mercato (ad esempio potrebbe essere implementato il protocollo SMTP per permettere all’utente di controllare la casa tramite il proprio programma di posta elettronica), oppure potrà es-sere fornita all’utente un’applicazione specificatamente svi-luppata per facilitare l’usabilità delle funzioni implementate nel DC.

(30)

Capitolo 4

Implementazione

In questo capitolo verranno descritti i passi principali che costituiscono la fase implementativa del lavoro. Verrá de-scritto come, a partire da un precedente prototipo realizzato dal TLC Net Group dell’Universitá di Pisa, siano stati rea-lizzati gli Home Gateway; verrá descritta l’implementazione delle classi principali che costituiscono il Domotic Coordina-tor e come sia stata sviluppata un applicazione Android che permettesse ad un utente di utilizzare, in modo semplice, le funzionalitá offerte dal sistema.

(31)

4.1. Sip Home Gateway 31

4.1 Sip Home Gateway

Per l’implementazione di un Home Gateway si `e utilizza-to il SIP Home Gateway (SHG), sviluppautilizza-to dal gruppo di reti del Dipartimento di Ingegneria dell’Informazione del-l’Universit`a di Pisa [6]; in questo lavoro era stato deciso di implementare con protocollo SIP un piano di control-lo comune a tutte le tecnocontrol-logie per poter sfruttare tutti i vantaggi derivanti da questo:

• il SIP `e un protocollo aperto e molto flessibile;

• sfruttando l’infrastruttura SIP esistente gli utenti han-no la possibilit`a di accedere ai servizi forniti dal sistema tramite qualsiasi Client SIP presente nel mercato; Era stata cos`ı realizzata una architettura di tipo modula-re nel quale furono sviluppate delle interfacce (una per ogni tipo di protocollo o tecnologia) che si occupassero di comu-nicare con le reti di sensori e attuatori DSAN (Domotics Sensor and Actuator Network); nello specifico erano state implementate due interfacce, una ZigBee e una Bluetooth; era stato poi sviluppato un Domotics facility abstration che permettesse il disaccoppiamento tra i due domini del siste-ma (il SIP e le DSAN), che potevano cos`ı essere sviluppati

(32)

indipendentemente, e che si occupasse di tradurre i messaggi ricevuti dagli utenti nel linguaggio specifico di quella parti-colare DSAN e viceversa, ed infine era stata implementata un’interfaccia SIP che si occupasse di mantenere la connet-tivit`a tra il SHG e l’utente. In Figura 4.2 ´e possibile osserva la descrizione schematica di quanto appena detto.

Figura 4.1: Descrizione modulare del Sip Home Gateway

Per la realizzazione dell’intero sistema si è partiti da tut-to questut-to, andando però a modificare il modo in cui gli utenti interagiscono con i singoli SHG; questo perché scopo del DC è creare un ulteriore piano di controllo intelligente che coordini gli Home Gateway. I SHG quindi non comuni-cheranno piú direttamente con gli utenti si interfacceranno costantemente con il DC ricevendo i comandi degli utenti solo dopo che il decisore inoltrerà la richiesta avendola mar-cata come conforme alle regole definite nel decisore stesso.

(33)

Nelle due sottosezioni che seguono vedremo un po’ pi`u nel dettaglio SIP e ZigBee per l’importanza che questi avran-no nell’implementazione dell’architettura del Domotic Coor-dinator.

4.1.1 Session Initial Protocol

SIP (Session Initial Protocol) è un protocollo di segnalazio-ne di livello applicativo, standardizzato dall’ Intersegnalazio-net Enn-gineering Task Force (IETF) nel 1999 [7]. Esso consente la crezione, modifica o terminazione di una sessione tra uno o più utenti. Il protocollo SIP permette una buona intergra-zione con gli altri protocolli definiti per le reti IP come SDP (Session Description Protocol), RTP (Real Time Transport Protocol)/RTCP (RTP Control Protocol), ma non è dipen-dente da essi e può quindi essere utilizzanto senza problemi con protocolli diversi da questi. Altra caratteristica fonda-mentale del SIP è l’indipendenza anche dal protocollo di trasporto sottostante e per questo è possibile utilizzare sia UDP che TCP.

(34)

Figura 4.2: Architettura SIP

SIP `e un protocollo di tipo client-server e ha come ele-menti principali:

• SIP User Agent (UA): detto anche SIP endpoint, questo `e un software, installato su PC, smartphone o tablet, che interagisce direttamente con l’utilizzatore; esso funziona sia come Client (UAC) quando deve in-viare una richiesta, sia come Server (UAS) quando deve rispondere.

• SIP Registrar Server: `e un server che ha il com-pito di accettare le richieste di registrazione da parte degli User Agent presenti all’interno del dominio di re-te a lui assegnato e deve provvedere a memorizzare le

(35)

informazioni in un Location Server.

• SIP Proxy Server: `e un router con il compito di inviare le richieste dall’UA al successivo SIP server o ad un altro UA interno alla rete. Questi possono essere di tipo stateful se ricorda le richieste inviate, le risposte fornite e i messaggi inoltrati; viceversa si definisce di tipo stateless.

• SIP Redirect Server: ha il compito di ricevere le richieste fornendo l’indirizzo di un user agent o di un server in grado di localizzare l’UA richiesto.

Il protocollo SIP, essendo un modello client-server de-finisce dei metodi di richiesta e di risposta; la sintassi di queste segue le specifiche dei messaggi HTTP, sono quindi composti da tre elementi: la Request (o la Response nel caso di messaggi di risposta), gli header e il corpo del messag-gio. Per quanto riguarda i metodi base di richiesta abbiamo l’INVITE che inizia una chiamata invitando un utente a partecipare ad una sessione, il BYE che la chiude, l’ACK per la conferma di ricezione di una risposta e altri metodi come REGISTER,CANCEL,OPTIONS e INFO

(36)

il più importante dei quali, ai fini del nostro lavoro, è il metodo MESSAGE : questo consente di realizzare servizi di Instant Messaging basati su SIP dove il corpo della richie-sta inviata dal mittente è proprio il messaggio che si vuole inviare al destinatario. Il metodo MESSAGE nel corso di questo lavoro di tesi è stato utilizzato sia per inviare mes-saggi di update sullo stato dei sensori e degli attuatori al DC, che da parte del DC per inviare i comandi alle sin-gole abitazioni, che da parte degli utilizzatori per inviare i comandi al coordinator dal proprio client SIP.

4.1.1.1 ZigBee

Lo standard IEEE 802.15.4 [3] definisce il protocollo di interconnessione, tramite comunicazioni radio, tra i diver-si dispodiver-sitivi facente parte di una Personal Area Network (PAN). Le WPAN (Wireless PAN) vengono utilizzate per distribuire informazioni su distanze relativamente brevi e senza cavi di collegamento; scopo delle WPAN `e connette-re piccolo ambienti e infrastruttuconnette-re favoconnette-rendo lo sviluppo di soluzioni economicamente ed energicamente efficienti. Lo scopo dell’ 802.15.4 `e proprio fornire una base per reti i cui dispositivi sono caratterizzati da bassissimo costo,

(37)

bassis-4.1. Sip Home Gateway 37

simo consumo energetico e bassa complessit`a. Lo standard definisce i primi due livelli dello stack ISO/OSI [4] : il li-vello fisico (PHY) e il lili-vello data link del Medium Access Control (MAC); la definizione di questi due livelli fa s`ı che siano garantiti una connessione wireless a basso rate (Low Rate WPAN) tra i dispositivi, che necessitano di basse po-tenze di funzionamento offrendo cos`ı una lunga durata delle batterie. ZigBee estende i livelli definiti in precedenza soddi-sfacendo allo standard 802.15.4; opera nelle frequenze radio per scopi industriali, scientifici e medici, include diverse mi-sure per evitare interferenze come ad esempio la scelta del miglior canale durante la fase di inizializzazione, oppure il cambiare il canale di trasmissione in maniera automatica nel caso in cui si registri un eccessiva interferenza su quello in uso.

4.1.1.2 Topologia di rete

Una WPAN deve necessariamente essere composta da al-meno due dispositivi operanti in uno stessa POS (Personal Operating Space); per ciascun POS solo uno dei dispositivi deve essere configurato come PAN COORDINATOR, che

(38)

avrà il compito di iniziare, terminare e redirigire le comuni-cazioni tra i diversi componenti. La topologia che si viene cos`ı a formare è dunque una tipica topologia a stella, dove ciascun dispositivo può comunicare solo ed esclusivamente con il coordinatore e sarà quest’ultimo ad inoltrare even-tualmente i messaggi agli altri nodi; essendo il ruolo del coordinator fondamentale per la corretta operatività della WPAN, viene generalmente collegato ad un’alimentazione fissa mentre gli altri dispositivi possono anche essere ali-mentati a batteria. COORDINATOR SENSORE SENSORE SENSORE SENSORE

(39)

`

E anche possibile andare a costituire una topologia di ti-po peer-to-peer che si differenzia da quella a stella in quanto ogni dispositivo pu`o comunicare direttamente con un altro dispositivo interno alla rete senza ricorrere alla mediazione del coordinatore; un topologia di questo tipo si presta mol-to bene per la formazione di reti di sensori molmol-to complesse e dense, come ad esempio il controllo e il monitoraggio in ambito industriale o ambientale.

4.2 Domotic Coordinator

Per lo sviluppo del Domotic Coordinator e di tutti i suoi moduli è stato utilizzato il linguaggio di programmazione JAVA. La scelta di questo linguaggio è dovuta principal-mente ai vantaggi propri della programmazione a oggetti affiancata alla natura portabile del JAVA che grazie alla Java Virtual Machine (JVM) realizza infatti un ambiente di esecuzione omogeneo, che nasconde al software Java (e quindi al programmatore) qualsiasi specificità del sistema operativo sottostante permettendo cos`ı di poter sviluppare un software eseguibile su qualsiasi piattaforma.

(40)

vi-4.2. Domotic Coordinator 40

sto nella sezione 4.1 è stata implementata una interfaccia SIP, mentre per quanto riguarda il lato utenti è stata im-plementata un ulteriore interfaccia SIP e un Web Service REST che permette l’invio e la ricezione dei messaggi tra-mite protocollo HTTP; il database infine è stato scelto di tipo relazionale e nella fattispecie mysql.

4.2.1 Database

Il database denominato DB DOMOTIC COORDINATOR `

e costituito da tutte quelle tabelle utili al funzionamento del domotic coordinator a supporto delle interfacce che lo compongono e del decisore.

4.2.1.1 Tabella SUBSYSTEMS

La tabella SUBSYSTEMS contiene la lista, riga per riga, dei sottosistemi che il DC ha il compito di amministrare; ogni tupla `e composta dal campo NAME che identifica uni-vocamente il particolare Home Gateway, PROTOCOL che specifica il protocollo utilizzato, l’ID PROTOCOL che `e l’i-dentificativo specifico relativo al protocollo utilizzato (per esempio il SIP URI se si utilizza il SIP o l’URL se si utilizza

(41)

un web service), ed infine il campo STATE nel quale viene registrato lo stato ONLINE/OFFLINE di quel particolare sottosistema.

Figura 4.4: Esempio di tabella SUBSYSTEMS

4.2.1.2 Tabella NOME SUBSYSTEMS

All’interno del Database è necessario creare una tabella per ciascun sottosistema che raccoglierà al suo interno la cronologia dei valori dei sensori e lo stato degli attuatori; ogni tupla sarà quindi composta dal campo TIMESTAMP che identifica l’istante di arrivo dell’update e da un campo specifico per ciascun sensore o attuatore.

(42)

Figura 4.5: Esempio di tabella NOME SUBSYSTEMS 4.2.1.3 Tabella COMMANDS

La tabella COMMANDS continere tutti i comandi che il decisore ha messo in lista d’attesa, in questo caso ogni tu-pla `e composta dal campo NAME che identifica il sot-tosistema destinatario del comando da eseguire, il campo COMMAND che specifica la funzione da svolgere, il cam-po PROTOCOL che specifica da quale interfaccia `e sta-to ricevusta-to il comando e il campo ID USER che, come nel caso dell’ID PROTOCOL visto in precedenza, definisce l’identificativo dell’utente specifico al protocollo utilizzato.

(43)

4.2.1.4 Tabella SUBSCRIBERS

All’interno di questa tabella vengono memorizzati, riga per riga, gli utenti che effettuano una subscribe per essere infor-mati istantaneamente nel caso un evento modifichi lo stato del sottosistema per cui hanno effettuato la registrazione; ogni tupla sarà composta del campo PROTOCOL per me-morizzare da quale interfaccia è arrivata la subscribe e per-mettere quindi di poter informare, tramite la stessa, che l’e-vento è avvenuto, il campo ID USER con la stessa funzione svolta nella tabella COMMANDS e il campo SUBSYSTEM che specifica per quale sottosistema l’utente ha effettutato la subscribe.

Figura 4.7: Esempio di tabella SUBSCRIBERS

4.2.2 DB connector

La classe DBConnector `e stata implementata per fornire alle altre classi uno strumento che permettesse l’astarazione

(44)

del database; i metodi implementati dal DBConnector sono: • insert: accetta come parametri di ingresso delle strin-ghe che identificano la tabella nella quale si vuole inse-rire la riga e i valori dei relativi campi che la compon-gono, esegue una connessione col database e invia il co-mando INSERT mysql al server con la stringa costruita a partire dai parametri in ingresso al metodo;

• delete: metodo molto simile all’insert con la differen-za che il comando inviato al server mysql `e di tipo DELETE.

• query: accetta come parametri di ingresso la tabella in cui fare la query e i campi di interesse, restituisce un oggetto di tipo ResultSet;

• setState: accetta come parametri di ingresso il nome del sottosistema e il tipo di stato che si vuole definire (ONLINE o OFFLINE), ha il compito di connettersi al database e andare a modificare il campo STATE nella tabella SUBSYSTEMS con il relativo parametro passato in ingresso;

• setAllOffline: metodo richiamato in fase di inizia-lizzazione dal DC che serve per resettare la tabella

(45)

SUBSYSTEMS con tutti i campi state impostati su OFFLINE.

4.2.3 Interfaccia SIP fra DC e SHG

Interfaccia SIP implementata nel DC per poter inviare e ricevere messaggi con i SIP Home Gateway implementati in ciascun sottosistema; per il suo sviluppo `e stata utiliz-zata la libreria MjSIP sviluppata dall’Universit`a di Parma e distribuita sotto licenza GNU GPL. L’interfaccia quindi, denominata SIPCoordSHG fornisce una serie di metodi allo scopo di interconnettersi con l’infrastruttura SIP e inviare o ricevere messaggi attraverso questa:

• register: utilizzando la classe RegistrationClient forni-ta da MjSIP esegue la registrazione del DC al Registrar associando il SIP URI e la password e comunicando l’indirizzo ip e la porta che verranno memorizzati nel Location Server per garantire la raggiungibilit`a; • onRegistrationFailure: nel caso la registrazione non

vada a buon fine comunica tramita una stringa nel terminale il fatto avvenuto.

(46)

• onRegistrationSuccess: nel caso la registrazione va-da a buon fine inizializza i va-database tramite il metodo setAllOffline, successivamente richiama il metodo sub-scribe della classe Subsub-scriber descritta nel sottocapito-lo 4.2.5 ed infine si mette in ascolto tramite il metodo receive() in attesa di ricevere messaggi sull’interfaccia; • sendMessage: richiamando questo metodo `e possibi-le inviare messaggi tramite SIP con l’extended method MESSAGE e accetta come parametri di ingresso il de-stinatario e il campo body contenente il messaggio; `e stato inoltre necessario implementare i metodi onMa-DeliveryFailure e onMaDeliverySuccess per verificare che il messaggio sia stato spedito correttamente o in caso contrario segnalare il non corretto invio di questo; • onMaReceivedMessage: richiamato dal metodo re-ceive() quando un nuovo messaggio raggiunge l’inter-faccia, questo metodo si occupa di distinguere se il mes-saggio ricevuto sia un update da parte del SIP Home Gateway, e in quel caso richiama il metodo parsing del-la cdel-lasse DataParser(vedi 4.2.4), oppure che il messag-gio ricevuto sia la risposta di “subscription accepted” fornita da SHG (vedi 4.2.5) e in quel caso richiama il

(47)

metodo setState della classe DBConnector per settare lo stato ONLINE della riga corrispondente al sottosi-stema che ha accettato la subscribe.

4.2.4 Parser dati

Ogni messaggio di update inviato dagli Home Gateway do-vrà seguire un certo formato per la composizione della strin-ga, essa è costituita dal nome del sottosistema e dalle se-quenze di associazione dell’identificativo del sensore o del-l’attuatore seguito dal valore di questo; la classe Parser tra-mite il metodo parsing accetta in ingresso la stringa di up-date da esaminare e un istanza della classe DBConnector; andando ad analizzare le sottostringhe che compongono il messaggio identificherà il sottosistema e i valori dei suoi di-spositivi, e andrà ad inserire tramite il metodo insert della classe DBConnector la nuova riga di update nella tabella NOME SUBSYSTEM.

4.2.5 Subscriber

La classe Subscriber, tramite il metodo doSubscribe, si oc-cupa di inviare la richiesta di Subscribe agli Home Gateway,

(48)

ovvero la volont`a di ricevere da questi i messaggi di update a intervalli costanti o nel caso cambino gli scenari al lo-ro interno; il metoto doSubscribe esegue una query di tutta la tabella SUBSYSTEM e, per ciascun sottosistema rappre-sentato dalla riga della tabella, invia il messaggio di Subscri-be all’Home Gateway rappresentato dal campo NAME, at-traverso l’interfaccia identificata dal campo PROTOCOLL specificando il realtivo ID PROTOCOL.

4.2.6 Controllore dello stato dei sistemi

Questa classe denominata CheckOffline estende TimerTask in quanto sarà un Thread che tramite il suo metodo run() verrà lanciato a intervalli regolari per verificare lo stato di tutti i sottosistemi amministrati; il metodo run() si occu-perà quindi di andare ad analizzare i dati conservati nel database e in particolar modo andrà a verificare, tramite il campo TIMESTAMP, se l’Home Gateway preso in esa-me ha sesa-messo di inviare i esa-messaggi di update da più di un certo tempo limite oltre il quale il sottosistema è dichia-rato offline; una volta verificato questo andrà a modificare il campo STATE nella tabella SUBSYSTEM impostandolo su OFFLINE, e successivamente ripeterà la procedura di

(49)

Subscribe per tutti quei sistemi che a quell’istante abbiano lo stato di OFFLINE nel campo STATE.

4.2.7 Interfaccia SIP fra DC e User Agent

L’interfaccia SIP lato utenti denominata SIPCoordClient `e un classe molto simile a quella vista in 4.2.3 con alcune differenze sostanziali:

• una volta che la registrazione del DC lato utenti al SIP Registrar `e andata a buon fine si limita a rimanere in ascolto su quella porta con il metodo receive, in attesa di nuovi messaggi ricevuti che andranno poi ad essere analizzati nel metodo onMaReceivedMessage ;

• questa volta andr`a ad identificare i messaggi che de-scrivono il comando che l’utente vuole eseguire, pas-sandolo poi all’interprete dei comandi per l’analisi (ve-di 4.2.9), e i messaggi (ve-di subscribe, questa volta da parte degli utenti, che passera all’istanza del Multi-castSender (vedi 4.2.10) per l’inserimento nella tabella SUBSCRIBERS del database.

(50)

4.2.8 Interfaccia Web Service Rest

Dal lato utenti, oltre ad un interfaccia SIP, si `e voluto an-dare ad implentare nel DC un interfaccia Web Service che tramite protocollo HTTP rendesse possibile una comunica-zione DC - Utenti tramite un’applicacomunica-zione Android (vedi 4.3), come esempio di ulteriore tecnologia di controllo.

4.2.8.1 Cenni ai Web Service

Un Web Service è un sistema software che rende possibile l’interazione tra dispositivi attraverso la rete; esso possie-de un’interfaccia che può essere descritta attraverso un file, tipicamente nel formato Web Service Description Langua-ge (WSDL), tramite il quale viene specificato l’insieme delle funzionalità offerte. Esistono due tipologie principali di web service: il SOAP (Simple Object Access Protocol) e il REST (Representional State Transfer). In questo elaborato si è de-ciso di utilizzare il REST in quanto il SOAP introduce dei costi considerevoli in termini di performance in quanto pre-vede connessioni di tipo stateful, e lo scambio e il parsing di grandi file ti tipo XML. Il REST invece è un alterna-tiva leggera alla classica tipologia di web service senza la

(51)

definizione di messaggi SOAP e di interfacce WSDL; nu-cleo centrale del paradigma REST `e il concetto di risorsa: qualsiasi informazione che possa essere referenziata da un identificatore URI (Uniform Resource Identifier) [5], pu`o infatti essere considerata una risorsa.

L’architettura REST prevede che l’interazione con le risorse avvenga attraverso un limitato insieme di metodi; nel caso HTTP, utilizzato nell’implementazione del Domotic Coor-dinator, i metodi a disposizione sono GET, POST, PUT, DELETE ; il formato usato per la rappresentazione delle risorse `e detto media type ed in genere a questo scopo ven-gono utilizzati linguaggi come XML o, come fatto nel corso del nostro lavoro, JSON.

4.2.8.2 Implementazione

L’interfaccia Web Service, in particolar modo REST, è stata implementata in linguaggio PHP integrato in un web server Apache, ed è stata poi garantita la comunicazione interpro-cesso Java-PHP attraverso un socket implementato nel ser-vizio PHP e nella classe RestListener (vedi 4.2.8.3). Il client web service quindi, andando a richiamare lo script php da remoto, tramite il metodo POST passerà come parametro

(52)

il messaggio al server, e questo verr`a poi passato al socket JAVA implementato nel RestListener (vedi sezione succes-siva). Figura 4.8 `e possibile osservare una rappresentazione schematica della comunicazione interprocesso qui esposta.

Figura 4.8: Comunicazione interprocesso php-java tramite socket

4.2.8.3 REST listener

La classe RestListener estende la classe Threads in quanto dovr`a stare costantemente in ascolta sulla porta associa-ta al socket in attesa di nuovi messaggi ricevuti; per ogni messaggio ricevuto attraverso il socket Java-PHP il thread avr`a il compito, cos`ı come parallelamente svolge l’interfaccia utente del SIP, di andare a discriminare i messaggi ricevuti

(53)

andando a distinguere se questi si trattino di comandi da eseguire al decisore oppure messaggi di richiesta di subscri-be; come per quanto riguarda il SIP (vedi 4.2.7), nel primo caso i messaggi verranno passati all’interprete dei comandi (vedi 4.2.9), mentre nel secondo verranno invece passati al MulticastSender (vedi 4.2.10) per le successive analisi.

4.2.9 Interprete dei comandi

La classe CommandParser, tramite il suo metodo parsing, ha il compito di analizzare la stringa che compone il messag-gio ricevuto, andando ad identificare qual è il tipo di coman-do, l’utente che l’ha inviato (o meglio il suo ID PROTO-COLL) e la casa destinataria; parametri di ingresso del me-todo sono la stringa contenente il comando e l’identificativo dell’interfaccia dalla quale tale metodo è stato richiama-to, questo per memorizzare in una variabile di tipo String il tipo di interfaccia che permetterà poi al decisore di co-municare al richiedente la scelta effettutata su quella de-terminata richiesta e l’eventuale corretto inserimento nella tabella COMMANDS del comando messo in lista d’attesa. Ricapitolande dunque, a partire dalla stringa messaggio, il CommandParser andrà ad individuare le sottostringhe che

(54)

caratterizzano i vari campi e passer`a poi queste informazioni al costruttore della classe decisore (vedi 4.2.11).

4.2.10 Multicast Sender

La classe MulticastSender, tramite i sue due metodi subscri-be e sendMessage, ha il compito di amministrare l’insieme degli utenti, definiti per gruppi, che hanno dichiarato di es-sere interessati a ricevere gli aggiornamenti sugli eventi che accadono al sottosistema per cui hanno inviato la subscribe. Nel specifico i due metodi hanno la funzione di:

• subscribe: inserire nella tabella SUBSCRIBERS una riga contentente l’utente che ha effettutato la richiesta, il sottosistema di interesse e l’interfaccia in cui il mes-saggio di “subscribe” `e arrivato che sono ovviamente anche i tre parametri di ingresso che il metodo richiede; • sendMessage: inviare a tutti gli utenti che ne hanno fatto richiesta il messaggio passato come parametro di ingresso a questo metodo; gli altri parametri richiesti sono il sottosistema oggetto del messaggio e l’utente che originariamente ha eventualmente ha inviato il co-mando che ha causato l’evento che si vuole

(55)

pubblicizza-4.2. Domotic Coordinator 55

re; quest’ultimo particolare parametro è stato inserito in quanto è stato previsto che un qualsiasi utente abbia la facoltà di poter inviare un comando anche se non ri-sulta subscriber per il sottosistema in cui vuole andare ad agire, perciò l’utente attore viene sempre informato separatamente dal decisore degli eventi che accadono in conseguenza del suo comando e quindi, per evita-re messaggi duplicati, il metodo sendMessage invia il messaggio a tutti gli utenti presenti nella tabella SUB-SCRIBERS registrati a quel particolare sottosistema escludendo l’utente che ha originato il comando (nel caso fosse anche lui subscriber), che verrà in ogni caso informato dal decisore.

4.2.11 Decisore

La classe DecisionMaker, per come è stata progettata e pen-sata l’architettura, non ha un implementazione definita e specifica perchè questa deve essere analizzata caso per caso in base alle esigenze e alle funzionalità che si vogliono offrire agli utenti. Vi sono comunque delle linee guida e dei vin-coli che possono aiutare lo sviluppatore ad implementare al meglio il decisore:

(56)

• estendere la classe come Thread ed implementare quin-di il metodo run();

• definire un costruttore nel quale sia possibile passare all’oggetto dei parametri fondamentali per la succes-siva analisi come i riferimenti alle interfacce utili per l’invio dei messaggi agli utenti che hanno inviato i co-mandi, l’utente che ha inviato il messaggio, l’interfac-cia in cui il comando `e arrivato, il tipo di comando e il sottosistema destinatario della richiesta;

• per ciascun tipo di comando supportato prevedere un metodo che compia la decisione, distinguendo se que-sto metodo è stato lanciato in conseguenza di un nuo-vo evento “comando ricevuto” oppure se è stato lan-ciato da un timer task per il controllo periodico della fattibilità dei comandi in lista d’attesa

• per ciascuna decisione presa, se questa risulta confor-me alla richiesta comunicare la decisione presa sia al richiedente sia a tutto il gruppo interessato tramite MulticastSender, in caso contrario informare esclusi-vamente il richiedente sia nell’eventualit`a che la sua

(57)

4.3. Applicazione Android 57

richiesta venga bocciata e scartata, sia nell’eventualit`a che venga messa in lista d’attesa.

4.2.12 Main

La classe Main, che viene istanziata all’avvio del program-ma, ha il compito di inizializzare tutte le interfacce imple-mentate nel Domotic Coordinator, creare due timer task che avranno il compito di istanziare a intervalli regolari un og-getto di tipo Coordinator per il controllo dell’eseguibilit`a dei comandi in lista d’attesa, e un oggetto di tipo CheckOffline per la verifica periodica dello stato degli Home Gateway.

4.3 Applicazione Android

A differenza dell’applicazione SIP che verrá poi usata nel prototipo, di cui non è stato necessario lo sviluppo in quan-to ci si è serviti di uno dei tanti User Agent presenti sul mercato (nel caso particolare è stato utilizzato Linphone), per fornire agli utenti uno strumento in grado di sfrutta-re le funzionalità del DC attraverso l’interfaccia che offre il servizio web service, si è deciso di implementare un’ap-plicazione per smartphone e tablet con sistema operativo

(58)

Android; l’applicazione avr`a la struttura tipica dei servizi di instant messaging, con una lista scorrevole contentente i messaggi ricevuti e precedentemente inviati, un componente editabile per la scrittura del testo da inviare e un pulsante per l’invio del messaggio.

L’applicazione `e stata sviluppata implementando due Acti-vity, una per la registrazione al server push (vedi 4.3.0.1) e una per l’invio e la ricezione dei messaggi al DC; `e sta-to inoltre necessario implementare un servizio di Brodacast Receive per intercettare i messaggi ricevuti tramite il server push e poterlo passare all’activity principale tramite notifi-cation.

L’invio di messaggi avviene tramite un AsyncTask che vie-ne lanciato vie-nel momento in cui l’utente preme il pulsante invia, il task esegue una richiesta di tipo HTTP al servi-zio Rest integrato nel DC e tramite il metodo POST passa come parametro il messaggio che l’utente vuole inviare; vie-ne passato come parametro anche l’identificativo push che il DC si occuperà di memorizzare nel campo ID PROTOCOL delle tabelle per garantire la raggiungibilità dell’utente che riceverà le risposte dal server push.

(59)

Figura 4.9: Applicazione Android Domotic Coordinator 4.3.0.1 Notifiche Push

Le notifiche push sono state implementate nei principali sistemi operativi mobili (Android, iOS, Windows Phone, BlackBerry OS) per evitare quello che viene generalmente indicato con il termine polling, ovvero la necessit`a da parte di un’applicazione di interrogare ciclicamente il server per verificare l’eventualit`a che ci siano aggiornamenti sui dati di suo interesse; ad esempio nel caso del REST l’applicazione `

e obbligata ad eseguire periodicamente una chiamata GET o POST per verificare se si siano modificati alcuni valori

(60)

in un determinato server, come per esempio se in un parti-colare database siano presenti nuove entry di interesse per l’applicazione stessa.

Quando si utilizzano le notifiche PUSH invece accade l’e-satto contrario, cioè sarà il server, nel caso accadano nuovi eventi di interesse per la particolare applicazione installata in un determinato terminale, a comunicare all’applicazio-ne il nuovo evento che si è venuto a verificare. Per quanto riguarda il servizio di notifiche push per Android, che è sta-to utilizzasta-to nella nostra architettura, le notifiche vengono inviate dal server al dispositivo, passando per un server in-termedio di proprietà di Google denominato Google Cloud Messaging (GCM), questo significa che tutte le notifiche push di tutte le diverse applicazioni installate sul disposi-tivo dovranno necessariamente passare per il GCM; si avrà cos`ı un dispositivo costantemente connesso ad un unico ser-ver consentendo di risparmiare notevolmente in termini di consumi energetici e traffico consumato, in particolar modo se si confrontano gli stessi parametri nel caso in cui mol-teplici applicazioni debbano fare altrettanti Polling ad un numero consistente di server.

(61)

(62)

Capitolo 5

Validazione tramite lo

sviluppo di un prototipo

In questo capitolo si andr`a a validare l’architettura descritta nei capitoli precedenti, sviluppando un prototipo funzionan-te del Domotic Coordinator, implementando un esempio di decisore e andando ad utilizzare tutti gli strumenti forniti dal nostro framework. Nel prototipo si emuler`a l’esistenza di quattro sottosistemi domotici e due utenti, che, tramite ap-plicazioni SIP e Rest, invieranno comandi ed effettueranno la subscribe ad alcuni dei sottosistemi in esame.

(63)

5.1. Implementazione del decisore 63

5.1 Implementazione del decisore

Nel caso in esame è stato deciso di implementare un deci-sore che permettesse di accendere (o spegnere) un impian-to nel sotimpian-tosistema destinatario, esclusivamente nel caso in cui l’avviamento di questo non provocasse il superamento di una soglia complessiva di potenza; per semplicità, ma senza per questo perdere di generalità, si è ipotizzato che in ogni sottosistema fosse installato un unico impianto con consumo di energia di 10 kWh, con un limite contrattua-le di carico globacontrattua-le dei quattro sottosistemi di 30 kW. Di conseguenza, affinchè il sistema non superi la soglia, è ne-cessario che massimo tre dei quattro impianti siano accesi contemporaneamente.

In questo scenario gli utenti avranno a disposizione due co-mandi, il comando critico switch on che dovr´a essere ese-guito esclusivamente nel caso in cui questo non infranga il limite dei 30kW, e il comando non critico switch off che pu´o essere eseguito in ogni caso. In Figura 5.1 sono descritte, tramite un diagramma di flusso, le operazioni implementate nel decisore in accordo con lo scenario in esame.

Come si pu´o osservare in Figura 5.1, nel momento in cui il decisore viene istanziato, tramite una variabile modificata

(64)

(65)

dal costruttore, andr´a a discriminare se sia stato richiamato dal timer task o dall’evento “comando ricevuto”.

Nel secondo caso, in principio, andrà ad analizzare il tipo di comando ricevuto, e se questo si tratta del comando non critico switch off, inoltrerá la richiesta all’Home Gateway di destinazione comunicando la decisione al mittente e a tutti i subscriber; viceversa se il comando è di tipo switch on, verificherà prima di tutto se nella lista di comandi in coda sono presenti altre richieste di quel tipo e, in caso affer-mativo, inserisce il comando in coda (è stata implementata una coda FIFO senza priorità); nell’eventualità invece che la coda risulti vuota, andrà a valutare il consumo di ener-gia presente in quel momento nei sottosistemi, e inoltrerà la richiesta qualora la somma di questi non superi il limite imposto di 30 kW; nel caso invece in cui questo limite risul-ti raggiunto, il comando verrá messo in coda e la decisione sará comunicata all’utente che aveva effettuato la richiesta; qualora invece la richiesta venga accolta, il comando verrá inoltrato al sottosistema destinatario e anche in questo ca-so verrá comunicata la decisione presa, sia all’utente che ai subscriber.

(66)

timer-5.2. Configurazione del Database 66

task per il controllo periodico della fattibilitá delle richie-ste in coda, per prima cosa andrá ad estrarre dalla lista il comando in cima alla coda (nel caso in esame sará esclu-sivamente di tipo switch on in quanto i comandi in lista d’attesa sono necessariamente di tipo critico) ed effettuerá la decisione come visto in precedenza; se il comando risulta lecito questo verrá eliminato dalla coda, in caso contrario invece la lista rimarrá invariata.

5.2 Configurazione del Database

Il database va configurato inserendo i parametri richiesti dal Domotic Coordinator per la fase di inizializzazione; in particolar modo vanno inseriti nella tabella SUBSYSTEMS i singoli sottosistemi come mostrato in Figura 5.2: inseren-do il tipo di protocollo utilizzato (nel caso specifico il SIP) e l’ID PROTOCOL (nel caso specifico i SIP URI di ciascun SIP Home Gateway) si specifica al DC come e dove rag-giungere gli Home Gateway, va inoltre inserito il Name per permettere all’interprete dei comandi e al Multicast Sender di ricavare il sottosistema a cui l’utente intende inviare il comando o la subscribe.

(67)

5.3. Configurazione e adattamento Home Gateway 67

Figura 5.2: Configurazione tabella SUBSYSTEMS

5.3 Configurazione e adattamento Home

Gateway

Per il prototipo ´e stato deciso di utilizzare quattro SIP Ho-me Gateway, di questi, tre hanno richiesto specifiche modi-fiche per poter operare simulando al loro interno tre DSAN nel quale i messaggi di update venivano costruiti andando a leggere da file il valore di ciascun sensore; nella dimostra-zione i tre sottosistemi simulati sono rispettivamente Bian-chi,Verdi e Blu; per quanto riguarda invece il sottosistema Rossi, il SIP Home Gateway ha il compito di interfacciarsi con un Sensor Node ZigBee prodotto dalla Freescale Semi-conductor (Figura 5.3), integrante un sensore di tempera-tura, un sensore di pressione, un accelerometro e un

(68)

rice-5.4. Configurazione dei client 68

trasmettitore RF conforme allo standard 802.15.4. Il sensor Node integra anche diversi led, e grazie alla possibilitá del-la board di poter essere riprogrammata per modificarne il comportamento, sono stati utilizzati i led di stato per si-mulare l’impianto che é idealmente presente all’interno del sottosistema: led accesi = impianto in funzione, led spenti = impianto spento; nei messaggi di update, quindi, il sensor node comunicherá periodicamente al SIP Home Gateway lo stado dei led, e li accenderá o li spegnerá in base ai comandi ricevuti, come illustrato in Figura 5.4

5.4 Configurazione dei client

Nella simulazione saranno presenti due utenti, uno che ac-ceder´a al DC tramite PC con l’User Agent SIP Linphone in un sistema operativo Linux; il secondo invece utilizzer´a l’applicazione Android Domotic Coordinator Messenger da

(69)

5.4. Configurazione dei client 69

Figura 5.3: Sensor Node Freescale Semiconductor modello MC1322x

Figura 5.4: Accensione e spegnimento led per simulare impianto attivo/spento

(70)

5.5. Svolgimento demo 70

noi sviluppata, interfacciandosi con il DC tramite Web Ser-vice. I due utenti per poter accedere dovranno effettuare pochi passi di configurazione descritti nel seguito:

• l’utente SIP dovrá configurare il proprio user agent af-finché questo possa effetturare la registrazione trami-te il proprio SIP Registar dopo ciò potrà accedere al Domotic Coordinator tramite il SIP-URI configurato nell’interfaccia SIP lato utente.

• l’utente Android dovrà avviare l’applicazione effettuan-do, esclusivamente la prima volta che l’app viene av-viata, la registrazione al server push per ottenere l’i-dentificativo utile alla sua raggiungibilitá nel prosieguo della simulazione. Una volta effettutata la registrazione comparirá l’Activity principale tramite la quale potrá inviare e ricevere i messaggi.

5.5 Svolgimento demo

In questa sezione si descriveranno, passo per passo, i co-mandi inviati agli utenti e gli effetti che questi avranno nel Domotic Coordinator e nei sottosistemi emulati.

(71)

5.5.1 Inizializzazione

L’inizializzazione dei sistemi avviene mediante la seguente procedura:

1. accensione del Sensor Node e del Coordinator ZigBee relativi al sottosistema Rossi;

2. avvio dei quattro SIP Home Gateway controllando che le registrazioni SIP effettuate nel Registar Server sia-no avvenute con successo e che tutti i sistemi siasia-no operativi;

3. avvio del Domotic Coordinator;

4. inizio fase di subscribe dove il DC comunica a ciascun SHG la volont`a di ricevere i messaggi di update; Alla fine di questa fase, tutti i sistemi sono operativi e gli impianti di ciascun sottosistema sono spenti. I SHG iniziano l’invio periodico al DC dei messaggi di update contenenti i valori e lo stato dei propri sensori grazie al quale il DC popoler´a le tabelle NOME SUBSYSTEMS.

(72)

5.5.2 Invio comandi leciti

Dopo la fase di inizializzazione lo stato dei sistemi risulta quello illustrato in Figura 5.5, nel quale i quattro impianti sono spenti e gli utenti non hanno ancora inviato nessun comando.

Figura 5.5: Stato dei sistemi dopo la fase di inizializzazione

In questa fase si andr´a, tramite gli opportuni comandi, ad accendere tre dei quattro impianti:

(73)

“switch on Bianchi”;

2. il DC, nel momento in cui riceve il messaggio, istanzia il decisore che, essendo tutti gli impianti spenti, con-sidera il comando lecito e lo inoltra al SHG di Bian-chi, inviando all’utente SIP il messaggio con la risposta “Bianchi switch on eseguito”;

3. l’utente SIP invia lo stesso identico comando per Verdi ottenendo cos´ı l’accensione dell’impianto e ricevendo la medesima risposta in quanto anche in questo caso il comando risulta lecito;

4. l’utente Android invia il comando “switch on Blu” che risulta ancora lecito ed ottiene a sua volta l’accensione di Blu e la ricezione del messaggio di conferma; 5. si arriva cos´ı alla condizione critica di tre impianti

ac-cesi su quattro e da questo momento in poi il tentativo di accendere l’impianto di Rossi porterebbe ad una ri-sposta negativa da parte del decisore e alla messa in coda del comando, come mostrato in Figura 5.6;

(74)

(75)

5.5.3 Invio comandi di subscribe

In questa fase i due utenti inviano i comandi subscribe rispettivamente:

• l’utente SIP invia il comando “subscribe Rossi” rice-vendo in risposta il messaggio “Subscribe Rossi accet-tata”;

• l’utente Android allo stesso tempo invia il comando di subscribe per la casa Bianchi ottenendo il messaggio di conferma.

Da questo momento quindi i due utenti riceveranno le notifiche degli eventi del sottosistema per cui hanno effet-tuato la subscribe e la tabella SUBSCRIBERS é ora com-posta dalle righe come mostrato in Figura 5.7 dove è pos-sibile osservare la riga riferita all’utente SIP subscriber di Rossi dove nel campo ID user èstato memorizzato il rela-tivo SIP-URI; mentre per quanto riguarda la riga relativa all’utente Android è stato specificato che il messaggio è ar-rivato dall’interfaccia REST, ed è stato memorizzato nel campo ID user l’identificativo utile al server push per poter inoltrare la notifica all’utente.

(76)

Figura 5.7: Tabella SUBSCRIBERS conseguente ai due messaggi di subscribe

5.5.4 Invio comando non lecito

A questo punto il sistema è in una situazione critica dove è permessa l’accensione del quarto sistema. Viene inviato, da parte dell’utente Android, il messaggio “switch on Rossi”, il decisore quindi, non ritenendo la richiesta accettabile, inse-risce la riga nella tabella COMMANDS ed invia all’utente Android un messaggio per avvisarlo della decisione presa contenente la stringa “Rossi: non é stato possibile esegui-re lo switch on, il comando é stato messo in coda. Verrai avvisato non appena sará possibile eseguirlo”; l’utente SIP invece, nonostante avesse effettutato la subscribe per Rossi, non riceve nessun messaggio perché dal punto di vista del sottosistema nulla é cambiato.

(77)

5.5.5 Uscita dalla configurazione critica

Il decisore, essendo in configurazione critica, continuer´a ad intervalli regolari a bocciare il comando in coda switch Rossi, fino a quando uno dei tre sistemi avviati non venga spen-to da uno degli utenti; con l’intenspen-to quindi di uscire dalla criticit´a si opera nella seguente maniera:

• l’utente SIP invia il comando “switch off Bianchi” e questo, essendo un comando non critico, viene imme-diatamente inoltrato dal DC verso il SHG di Bianchi; • l’utente SIP riceve la conferma dello spegnimento

tra-mite il messaggio “Bianchi switch off eseguito”; • l’utente Android, in quanto subscriber di quel

sottosi-stema, riceve da parte del Multicast Sender lo stesso messaggio di avvenuto spegnimento ricevuto dall’uten-te SIP.

5.5.6 Esecuzione automatica decisore

Infine, essendo ora il sistema uscito dalla configurazione critica, all’avvio automatico del decisore per il controllo periodico da parte del timer task accade che:

(78)

• il decisore sommando ora i valori ricevuti dai quattro sottosistemi rivela il cambiamento e considera questa volta il comando in coda di switch on lecito;

• il DC inoltra quindi la richiesta di accensione dell’im-pianto a Rossi, arrivando cos´ı alla situazione mostrata in Figura 5.8 ;

• l’utente Android, mittente originario della richiesta, ri-ceve il messaggio di avvenuta accensione “Rossi switch on eseguito”;

• l’utente SIP, in quanto subscriber di Rossi, riceve da parte del Multicast Sender lo stesso messaggio conte-nenente la notizia che l’impianto di Rossi ´e ora acceso.

(79)

Figura 5.8: Stato dei sistemi successivo alll’avvio automatico del decisore

(80)

Capitolo 6

Conclusioni

Con questo lavoro di tesi abbiamo cercato di mostrare le potenzialitá che può avere un’architettura come quella qui proposta; attraverso la costruzione modulare delle compo-nenti abbiamo reso possibile, in maniera relativamente sem-plice, estendere l’architettura ad altri di protocolli di comu-nicazione e ad altre tecnologie in ambito domotico e, come abbiamo dimostrato nello sviluppo del prototipo, per poter usufruire degli strumenti bisognerà limitarsi ad implemen-tare l’Home Gateway opportuno all’interno dei sottosistemi da amministrare, scegliere a quali regole il decisore dovrá