Indice
Introduzione 5
Contributo della tesi . . . 6
Organizzazione della tesi . . . 9
1 La Domotica 13 1.1 Introduzione . . . 13
1.2 Ambiti applicativi . . . 15
1.3 I problemi della domotica . . . 18
1.4 Gli standard domotici . . . 21
1.4.1 EIB . . . 22 1.4.2 EHS . . . 22 1.4.3 BatiBus . . . 23 1.4.4 Konnex . . . 23 1.4.5 LonWorks . . . 25 1.4.6 UPnP . . . 26 1.4.7 X10 . . . 28 1.5 Stato dell’arte . . . 29 2 DomoNet 31 2.1 Il framework DomoNet . . . 31 2.1.1 DomoML . . . 34 2.1.1.1 DomoDevice . . . 34 2.1.1.2 DomoMessage . . . 37 2.1.2 DomoNetWS . . . 39 2.1.2.1 Tech Manager . . . 40 2.1.3 DomoNetClient . . . 42
2 Indice
2.2 I LinkedService . . . 42
3 Tech-manager BTicino 47 3.1 BTicino . . . 47
3.2 My Home BTicino . . . 48
3.3 Topologia e configurazione My Home . . . 51
3.4 OpenWebNet . . . 55
3.4.1 Sessione comandi e monitor: introduzione . . . 56
3.4.2 Messaggi OPEN . . . 57
3.4.2.1 Ack e Nack OPEN . . . 57
3.4.2.2 Comando e stato OPEN . . . 57
3.4.2.3 Richiesta stato . . . 58
3.4.2.4 Richiesta/valore grandezze . . . 59
3.4.2.5 Scrittura grandezze . . . 60
3.4.3 Sessione comandi e monitor: dettaglio . . . 61
3.4.3.1 Comportamento del server OPEN . . . 61
3.4.3.2 Comportamento del client OPEN . . . 63
3.5 Tech Manager BTicino . . . 64
3.5.1 I dipositivi connessi a My Home . . . 68
4 UPnP AV 71 4.1 Introduzione . . . 71
4.2 Playback Architecture . . . 73
4.3 Media Server . . . 74
4.3.1 Content Directory Service . . . 75
4.3.2 ConnectionManager Service . . . 75
4.3.3 AVTransport Service . . . 76
4.4 Media Renderer . . . 76
4.4.1 Rendering Control Service . . . 77
4.4.2 ConnectionManager Service . . . 77
4.4.3 AVTransport Service . . . 78
5 DomoNet: un’estensione multimediale 79 5.1 Introduzione . . . 79
Indice 3 5.3 Il techManager UPnP . . . 82 5.4 Conclusioni . . . 83 6 Configuratore di LinkedService 85 6.1 Introduzione . . . 85 6.2 JGraph . . . 86 6.3 Il configuratore . . . 89
7 Un caso reale: il progetto AlmaViva-CNR 93 7.1 Introduzione . . . 93
7.2 Controllo carichi . . . 95
Conclusioni 101 A Esempi di tabelle dei COSA e dei DOVE BTicino 103 A.1 Categoria Comfort . . . 103
A.1.1 Scenari (CHI=0) tabella dei COSA . . . 103
A.1.2 Scenari (CHI=0) tabella dei DOVE . . . 104
A.1.3 Automazione (CHI=1) tabella dei COSA . . . 104
A.1.4 Illuminazione (CHI=2) tabella dei COSA . . . 104
A.1.5 Automazione e illuminazione tabella dei DOVE . . . . 106
A.2 Categoria Multimedia . . . 106
A.2.1 Multimedia (CHI=7) tabella dei COSA . . . 106
A.2.2 Multimedia (CHI=7) tabella dei DOVE . . . 107
Introduzione
Lo sviluppo che sta avendo la domotica in questi ultimi anni sembra avere un unico grande freno che ne impedisce una completa e diffusa affermazione: la guerra degli standard. Ogni dispositivo elettronico dispone di un proprio protocollo di comunicazione che solo se conosciuto anche ad altri dispositivi ne permette l’interazione.
In una casa moderna esistono ormai molteplici impianti. L’impianto elet-trico di illuminazione `e stato affiancato da tanti altri impianti elettrici tutti o quasi indipendenti tra loro: l’impianto antifurto, quello di riscaldamento, quello di condizionamento . . . .
Tali impianti dovrebbero poter interagire tra loro in maniera il pi`u pos-sibile automatica secondo criteri di interazioni stabiliti dai singoli utenti in base alle esigenze personali.
Un efficace e funzionale sistema domotico dovrebbe quindi permettere l’integrazione di tutti i sottosistemi in modo tale da poterli gestire, in ma-niera univoca e semplice, e, possibilmente, attraverso un’unica centrale di supervisione (per esempio un computer, locale o remoto). Sarebbe quindi necessario avere un’unica interfaccia che permetta di controllare qualsiasi apparecchio della casa per eseguire comandi, interrogare il sistema, attivare o disattivare un componente, modificare una precedente programmazione. Questo tuttavia `e reso molto complicato dalla presenza sul mercato di molte-plici dispositivi con diversi standard, spesso proprietari e quindi difficilmente controllabili.
Sebbene ci sia stata negli scorsi anni la tendenza da parte delle grandi case produttrici di prodotti tecnologici a cercare un protocollo di comunica-zione comune, non sono stati raggiunti obiettivi soddisfacenti e sul mercato si stanno diffondendo sempre di pi`u singoli dispositivi o interi sistemi
domo-6 Introduzione tici che non consentono la convivenza e l’interazione con altri dispositivi di differenti aziende. E’ ormai improbabile che tra tutti gli standard esistenti ne emerga uno che sovrasti gli altri in quanto ogni azienda ha ormai conquistato una sua parte di mercato. E’ altres`ı difficile che aziende in forte concorrenza possano collaborare per la realizzazione di un middleware che permetta la cooperazione dei propri dispositivi con gli altrui.
Questo `e invece un problema cruciale che deve necessariamente essere risolto affinch´e la domotica si sviluppi definitivamente.
Contributo della tesi
Nell’ambito di questa tesi `e stato portato avanti un lavoro che estende quello gi`a iniziato in precedenti tesi di laurea [23, 31, 35], che hanno portato allo sviluppo di DomoNet, un framework che permette l’interoperabilit`a tra sistemi domotici.
DomoNet `e stato sviluppato per consentire l’interoperabilit`a tra dispo-sitivi domotici di diversi standard, con diversi protocolli di comunicazio-ne, che, se collegati alla rete, possono scambiarsi messaggi ed interagire. Le caratteristiche principali di DomoNet, sono il linguaggio domoML e i TechManager.
Il linguaggio DomoML `e un linguaggio basato su XML che permette di tradurre i messaggi, dai linguaggi dei singoli dispositivi domotici, in un lin-guaggio comune. La traduzione `e effettuata dai TechManager (presenti uno per ogni standard) che ‘conoscono’ il protocollo di comunicazione e di con-seguenza il formato dei messaggi proprio della tecnologia del dispositivo e possono quindi convertirli in domoMessage e viceversa. Inizialmente sono stati implementati soltanto i TechManager UPnp e Konnex, permettendo quindi solo la gestione di dispositivi appartenenti a questi standard.
Alle funzionalit`a gi`a presenti in DomoNet `e stato aggiunto un modulo che permette la gestione di dispositivi BTicino, il loro controllo e la loro interazione con altri dispositivi domotici che si trovino connessi alla stessa rete.
Introduzione 7 Per realizzare il TechManager BTicino, e rendere quindi possibile la tra-duzione dei messaggi dei dispositivi BTicino in DomoML, `e stato necessario analizzare il linguaggio OPEN Web Net che BTicino ha sviluppato proprio per permettere il controllo di tutti i suoi dispositivi indipendentemente dal-le loro caratteristiche specifiche. Una volta isolati tutti i possibili messaggi OPEN Web Net che possono essere inviati o ricevuti `e stato realizzato un gateway e un meccanismo di traduzione di questi messaggi in messaggi in lin-guaggio DomoML, che permette di astrarre le caratteristiche di un dispositivo domotico in modo indipendente dalla sua tecnologia.
Per rendere possibile l’integrazione della tecnologia BTicino all’interno di DomoNet `e stato d’aiuto uno Starter Kit che contiene alcuni dei dispositi-vi presenti nel pi`u esteso sistema domotico My Home BTicino. Attraverso questo Starter Kit, che l’azienda stessa mette a disposizione per attivit`a di studio e di ricerca, `e stato possibile inizialmente simulare e analizzare il fun-zionamento di tali dispositivi, e una volta implementato il TechManager, `e stato possibile testarne il funzionamento.
L’integrazione della tecnologia BTicino all’interno dell’infrastruttura Do-moNet, ed in particolare il TechManager realizzato, `e poi stata utilizzato per l’implementazione di un’ulteriore estensione del framework con l’obiettivo di includere anche contenuti multimediali tra quelli condivisibili tra i disposi-tivi. In questo modo, i dispositivi collegati alla rete DomoNet non devono pi`u limitarsi a scambiarsi semplici messaggi di testo o numerici, ma possono scambiarsi anche contenuti pi`u complessi come quelli audio e video.
A questo scopo `e stata utilizzata la telecamera BTicino, presente nello Starter Kit, menzionato precedentemente, ed `e stato simulato via software un renderer UPnP, che permette la visualizzazione dei contenuti ripresi dalla telecamera. Tale telecamera `e generalmente utilizzata come videocitofono e con questa estensione `e possibile avere come videoterminale un qualsiasi altro dispositivo UPnP, che non sia quindi necessariamente BTicino. La scelta `e ricaduta su un renderer UPnP perch`e facilmente simulabile via software.
Un ulteriore contributo dato da questo lavoro allo sviluppo di DomoNet `e rappresentato dalla realizzazione di un’interfaccia utente che rende possibile
8 Introduzione gestire i vari componenti collegati alla rete e in particolar modo di configurare i collegamenti tra servizi di dispositivi tecnologicamente distinti.
Questa interfaccia permette di gestire i cosiddetti LinkedService che pos-sono essere creati tra i diversi dispositivi collegati alla rete.
I LinkedService sono una delle peculiarit`a di DomoNet o meglio del lin-guaggio DomoML, per mezzo del quale si rende possibile l’interoperabilit`a tra i diversi standard domotici. I LinkedService sono, infatti, formalizzati mediante il linguaggio DomoML e permettono di associare con semplicit`a, servizi resi disponibili dai device domotici. Un LinkedService tra due dispo-sitivi permette in particolare di associare al verificarsi di un evento del primo dispositivo (per esempio l’abilitazione dell’allarme anti intrusione) uno o pi`u eventi che dovranno verificarsi su altri dispositivi (per esempio lo spegni-mento di eventuali luci rimaste accese e la chiusura delle tapparelle, in con-seguenza dell’abilitazione dell’allarme). Si possono avere delle associazioni semplici, come per esempio l’accensione di una luce che avvenga conseguen-temente all’accensione di un’altra luce, oppure associazioni pi`u complesse che coinvolgono pi`u dispositivi.
Affinch´e questi collegamenti siano effettivamente funzionali devono poter essere decisi dall’utente in base alle singole esigenze. Perch´e questo possa essere fatto, senza che sia necessaria la presenza di un ‘esperto’ (che vada a scrivere del codice in linguaggio DomoML), `e stata realizzata questa inter-faccia chiamata DomoConfigurator, che in modo molto semplice permette di stabilire le interazioni tra i dispositivi e di configurare le caratteristiche di ogni rete domotica che utilizza DomoNet.
Il software sviluppato durante il lavoro di tesi `e disponibile con licen-za GNU GPL, all’indirizzo http://sourceforge.net/projects/DomoNet, dove `e possibile scaricare il codice completo di DomoNet, le estensioni svi-luppate e la loro documentazione.
Introduzione 9
Organizzazione della tesi
I capitoli della tesi sono strutturati nel modo seguente: Capitolo 1: La domotica
In questo capitolo verranno descritte le principali caratteristiche della domotica: come si `e sviluppata e come pu`o essere utilizzata per migliorare la vita quotidiana. Verrano descritti gli ambiti in cui si pu`o trovare giovamento da un’introduzione della domotica e saranno descritti quali sono i motivi per cui ancora stenta a raggiungere un adeguato livello di diffusione.
Poich´e uno dei principali limiti alla diffusione della domotica `e la presenza sul mercato di molteplici standard tra loro incompatibili, verranno descritte le caratteristiche dei pi`u diffusi e verr`a presentata una breve descrizione dei progetti che si stanno sviluppando nel mondo allo scopo di integrare i dispo-sitivi domotici di standard diversi.
Capitolo 2: DomoNet
In questo capitolo verr`a descritto il framework DomoNet, che `e stato utilizzato come base per lo sviluppo di questa tesi che ha portato alla realiz-zazione di alcune estensioni che ne incrementano le funzionalit`a. DomoNet `e un middleware per l’integrazione di dispositivi domotici che, tra le altre cose, fornisce un linguaggio comune che permette di tradurre gli specifici linguaggi dei vari dispositivi, che in questo modo possono essere messi in comunicazio-ne.
Capitolo 3 : Tech manager BTicino
L’implementazione e l’integrazione in DomoNet del Tech manager BTici-no `e stata realizzata per permettere l’utilizzo dei dispositivi BTiciBTici-no insieme a dispositivi Konnex e UPnP.
A partire dall’analisi del formalismo del linguaggio OPEN Web Net, for-nito dalla casa produttrice, `e stato realizzato un gateway che permetta la traduzione di tali messaggi in DomoML. In questo modo i dispositivi BTi-cino una volta collegati alla rete DomoNet, possono interagire con tutti gli altri dispositivi, siano essi dello stesso standard o no.
10 Introduzione
Capitolo 4: UPnP AV
In questo capitolo verr`a fornita una breve descrizione dello standard UPnP AV, lo standard UPnP per il trasferimento di contenuti multimediali tra dispositivi. Il mediaServer descritto in questo capitolo `e stato utilizzato per estendere il framework e permettere un primo approccio all’interopera-bilit`a anche di contenuti multimediali.
Capitolo 5: Un’estensione multimediale
Il Tech manager BTicino, dopo essere stato implementato, `e stato poi utilizzato per estendere il framework DomoNet allo scopo di permettere la condivisione di contenuti multimediali tra standard domotici distinti. L’esten-sione multimediale prevede la visualizzazione delle immagini di una teleca-mera BTicino su dispositivi UPnP utilizzando anche il MediaServer descritto nel capitolo 4.
Capitolo 6: Configuratore di LinkedService
In questo capitolo verr`a descritta l’implementazione di un’interfaccia gra-fica per la configurazione di LinkedService, dei costrutti del linguaggio Do-moML che permettono il collegamento di servizi di dispositivi domotici di standard diversi. L’interfaccia grafica permette di semplificare, velocizzare e limitare il numero di errori che possono essere commessi nella stesura di un LinkedService.
Capitolo 7: Un caso reale: il progetto Almaviva
Nel corso della tesi, il framework DomoNet `e stato al centro di una colla-borazione tra il CNR e una grande societ`a italiana nel settore dell’IT, che ha visto coinvolto in modo rilevante anche il TechManager BTicino sviluppato in questa tesi per la gestione di una simulazione in ambienti reali. In questo capitolo verr`a descritta sommariamente la collaborazione, e come il modulo BTicino di questa tesi sia stato integrato nel progetto.
Conclusioni
Introduzione 11 possibili sviluppi futuri.
Appendice A
In questa sezione verranno mostrate le tabelle di corrispondenza dei COSA e dei DOVE di OPEN Web Net in funzione di alcuni CHI.
Capitolo 1
La Domotica
In questo capitolo sono descritte le principali caratteristiche della domo-tica, gli ambiti in cui si sta sviluppando e i motivi per cui tale sviluppo `e ancora frenato dalla mancata possibilit`a di integrazione tra i diversi dispo-sitivi domotici che potrebbero essere installati all’interno di una abitazione privata o di un’edificio pubblico.
1.1
Introduzione
Lo sviluppo scientifico e tecnologico che caratterizza la nostra epoca, nel contesto di un generale sviluppo economico e sociale, ha generato profon-di mutamenti nel modo profon-di vivere la quotiprofon-dianit`a. La casa, il luogo dove si passa gran parte della propria vita, non pu`o essere tagliata fuori dalle gran-di trasformazioni e dai ragran-dicali cambiamenti che ci circondano. La casa del XXI secolo non `e pi`u esclusivamente una casa bella, funzionale ma fine a se stessa, `e una casa costruita a misura di chi la abita. Nelle scelte di progetta-zione, realizzazione e arredamento, gli architetti, i progettisti e i costruttori, non possono pi`u prescindere dalle caratteristiche personali degli individui che dovranno abitare un determinato spazio. Persone ed ambienti devono poter interagire in ogni momento della vita quotidiana. Un motto dei romani era “non domo dominus sed domino domus” ritenendo che non deve essere la casa a dominare e possedere l’uomo, ma il padrone che deve possederla e governarla. C’`e un ritorno all’umanesimo nel modo di concepire la casa e gli spazi domestici. L’uomo deve essere il fulcro degli ambienti che lo circondano
14 La Domotica e che sono stati costruiti per lui. Devono sapersi adattare al suo stile di vita e alle sue abitudini, garantendo in ogni momento il massimo della conforte-volezza, della sicurezza e dell’accessibilit`a. In un contesto di questo tipo si inserisce la domotica.
La domotica, detta anche home automation, `e la disciplina che si occupa di studiare le tecnologie atte a migliorare la qualit`a della vita negli ambienti antropizzati, grazie all’automazione, al controllo e all’integrazione di sistemi eterogenei.
Il termine ”domotica” `e un neologismo derivante dalla contrazione dalla parola latina domus e il sostantivo ’automatica’ con il significato di ‘scienza dell’automazione delle abitazioni’. Il termine sta quindi ad indicare una casa in cui l’aspetto informatico ed elettronico (telematico) `e preminente.
Domotica vuol dire interazione tra la casa e l’uomo, vuol dire ricerca di una migliore fruibilit`a e accessibilit`a dell’abitazione, vuol dire creare nuovi mezzi per condividere gli ambienti domestici con gli altri membri della fa-miglia. Con la domotica nasce un nuovo modo di vivere la casa: quello di vedere non pi`u un elettrodomestico oppure un servizio dell’abitazione come unico e isolato dagli altri, ma concepire un ambiente in modo integrato dove interoperabilit`a diventa le parola d’ordine.
Dal punto di vista tecnologico l’obiettivo `e quello di aggiungere intelligen-za e funzioni di comunicazione a tutti i dispositivi alimentati da elettricit`a presenti in casa. I dispositivi collegati alla rete elettrica in una comune abi-tazione sono moltissimi: basti pensare agli elettrodomestici, all’impianto di illuminazione, quello antintrusione, l’allarme, i sistemi di rivelazione di gas, fumo e allagamento, l’impianto di irrigazione del giardino, le tapparelle (se motorizzate), il condizionamento ed il riscaldamento, l’impianto audio video e tanto altro ancora. Oggi tutti questi impianti sono per la maggior parte separati tra loro, hanno diverse centraline, lavorano con diversi standard, hanno diversi tipi di comandi, con una complicazione che si traduce in mag-giori costi, magmag-giori disservizi, minor comfort. La possibilit`a di armonizzare e coordinare tutti questi dispositivi `e gi`a da tempo un’esigenza, ma chi li utilizza non ha quasi mai idea di come si possa raggiungere questo risultato. La domotica, forse non si conosce bene, per`o la sua introduzione e attuazio-ne incuriosisce, attrae e piace. E’ qualcosa di innovativo, rivoluzionario che
1.1.2 Ambiti applicativi 15 incanta con il fascino della tecnologia e la seduzione dell’elettronica.
Le soluzioni tecnologiche offerte dalla domotica, indipendentemente dagli specifici ambiti di utilizzo, devono essere caratterizzate dalle stesse funzio-nalit`a dei classici dispositivi domestici, che sono utilizzati senza particolari difficolt`a da un vasto bacino di utenza.
In particolare `e necessario che un sistema domotico possa funzionare, in maniera affidabile e continua, senza richiedere speciali attenzioni. Anche in presenza di guasti dovrebbe essere fornito un servizio minimo, e il sistema dovrebbe essere progettato in modo da avvertire tempestivamente l’utente, che deve essere messo nelle condizioni di poter risolvere il problema sorto senza necessariamente l’intervento di un esperto. Diventa quindi importante il meccanismo di interfacciamento con l’utente che deve essere il pi`u funzionale e semplice possibile in modo da permettere una facile ed efficace interazione. Un sistema domotico deve essere facile da utilizzare e facile da personalizzare, almeno in parte, anche da persone che non ne conoscano gli aspetti pi`u tecnici.
1.2
Ambiti applicativi
Gli attuali campi applicativi della domotica sono molteplici, ma possono essere riassunti in quattro grandi aree: il comfort, la security, la safety, e il risparmio energetico. Queste aree per`o non vanno viste come separate e in-dipendenti tra loro. Gli stessi rilevatori di presenza utilizzati per il controllo intrusioni nell’area sicurezza vengono utilizzati dall’area comfort per accen-dere una luce all’ingresso di una persona in una stanza, e utilizzata dall’area risparmio energetico per ottimizzare la temperatura di un ambiente. Quindi la suddivisione `e solo logica: il vantaggio della domotica `e proprio quello di permettere a un dispositivo di comunicare, e anche di poter essere usato per scopi diversi da quelli per cui era stato pensato inizialmente.
Comfort
Nell’ambito del comfort rientrano tutti i sistemi progettati per la sempli-ficazione del rapporto uomo-casa e per il miglioramento della qualit`a della vita privata e lavorativa. Il comfort `e ad esempio il benessere percepito dal-la termoregodal-lazione selettiva dell’ambiente, dal-la possibilit`a di controldal-lare ogni
16 La Domotica aspetto della casa mediante semplici interfacce accessibili anche fuori casa, la programmazione di pi`u azioni attivabili mediante un solo pulsante. E’ pos-sibile ad esempio, mediante scenari, impostare con una sola azione all’uscita di casa, lo spegnimento di tutte le luci, l’abbassamento di tutte le tapparel-le, la chiusura dell’elettro-valvole di gas e acqua e l’attivazione dell’allarme perimetrale. Al ritorno a casa viceversa, l’impianto di riscaldamento o condi-zionamento si sar`a gi`a attivato preventivamente, verrano riattivate le funzioni vitali di una casa e all’ingresso accese le luci di percorso. Questi sono solo alcuni semplici esempi di quello che vuol dire comfort, ma che possono dare comunque un idea delle possibilit`a permesse dall’integrazione dei sistemi.
Security
La sicurezza `e intesa come controllo degli accessi indesiderati dall’esterno, mediante rivelatori di presenza, sensori perimetrali, video sorveglianza degli ambienti accessibili anche fuori casa. La possibilit`a di attivare il sistema di allarme selettivamente solo in alcune zone dell’abitazione mentre ci si trova in altre. Nel caso si verifichi un’intrusione il sistema `e in grado di accendere tutte le luci di casa per spaventare l’intruso, e di chiamare sia le forze dell’ordine con messaggi preregistrati, sia il padrone di casa mediante anche sms.
Safety
Con il termine safety si intende la sicurezza personale contro eventua-li malfunzionamenti d’impianti potenzialmente pericolosi o dannosi per le persone e l’abitazione.
E’ noto che la maggior parte degli incidenti avviene all’interno delle mura domestiche. Questo succede perch´e il grado di sicurezza delle case non `e suf-ficiente alle esigenze della vita moderna. L’introduzione di automatismi e di procedure che permettano una maggiore sicurezza e controllo della casa pu`o portare sicuramente a una sensibile diminuzione di questo tipo di inciden-ti. Talvolta bastano pochi accorgimenti per evitare una sciagura, altre volte invece solo con sofisticati automatismi si possono evitare incidenti.
Le tecnologie volte alla sicurezza si stanno affermando negli edifici ad uso pubblico con notevole successo, mentre nelle abitazioni private, c’`e ancora una
1.1.2 Ambiti applicativi 17 certa ritrosia ad introdurre elementi per la sicurezza ritenendo che, prestando maggiore attenzione nelle azioni quotidiane, si possano evitare costose spese aggiuntive. Oggi per`o i costi della tecnologia sono molto diminuiti e, dal momento che l’attenzione delle persone pu`o venir meno, nonostante la buona volont`a, pu`o essere pi`u conveniente dotare la casa di dispositivi opportuni.
Parliamo, per esempio, dell’impianto antincendio, di un sistema di anti-allagamento, del controllo fughe di gas, del controllo carichi elettrici... Tutti i sistemi domotici prevedono ormai come standard sensori che, integrati con la rete domotica, monitorizzano l’ambiente ed avvertono attraverso allar-mi e comunicazioni all’utente della presenza di probleallar-mi che possono ledere l’incolumit`a delle persone o della casa stessa.
Risparmio energetico
Il risparmio energetico `e l’area applicativa che ha i maggiori vantaggi so-ciali [12]. Un sistema completamente automatizzato pu`o infatti evitare i costi generati dagli sprechi energetici dovuti a dimenticanze o ad altre situazioni particolari, monitorando continuamente l’ambiente, con sensori e attuatori a basso consumo elettrico, e garantendo, ad esempio, la termoregolazione dei singoli locali in funzione dei cambiamenti ambientali (apertura delle fi-nestre, temperatura esterna, orario, ecc.) oppure la corretta illuminazione dell’ambiente utilizzando dei sensori di presenza, sensori crepuscolari, rego-latori di flusso, ecc. Ad esempio, d’inverno, dopo una certa ora, quando ormai l’apporto di luce naturale proveniente dall’esterno `e irrisorio, utilizzando in modo combinato un sensore crepuscolare, `e possibile comandare la chiusu-ra di tutte le tapparelle dell’abitazione, in modo da ridurre ulteriormente la dissipazione termica verso l’esterno. Uno studio promosso dalla regione Emi-lia Romagna [9] , in un edificio multipiano, composto da 27 appartamenti, ha stimato il risparmio energetico conseguibile con l’applicazioni di questi impianti. I risultati sono riassunti nella tabella 1.1.
Oltre a quanto finora riportato, `e anche possibile, gestendo la priorit`a di accensione di elettrodomestici come lavastoviglie e lavatrice, livellare il consu-mo elettrico e utilizzare l’energia quando costa meno, come ad esempio le ore notturne. In aggiunta alla gestione delle accensioni `e possibile sovraintendere il funzionamento dei carchi pi`u pesanti (forno, scaldabagno, lavatrice, boiler,
18 La Domotica
Impianto Stima risparmio %
Gestione impianto Riscaldamento 5 %
Gestione impianto Raffrescamento 3 %
Gestione impianto Condizionamento 15%
Gestione impianto ACS 6-12 %
Gestione impianto illuminotecnico 15-28 %
Tabella 1.1: Stima del risparmio energetico con l’applicazione della domotica in un edificio residenziale
ecc.) gestendone il distacco controllato per evitare sovraccarichi e relativi blackout. La gestione dei carichi avviene attraverso l’azione combinata di una unit`a centrale situata subito a valle del contatore elettrico, con le interfacce remote. Il distacco dei carichi pu`o avvenire quando la previsione di consumo totale va oltre la potenza contrattuale impegnata. Questo sistema ottimizza l’energia disponibile sganciando i carichi interrompibili, tenendo conto del quantitativo di energia che `e possibile recuperare attraverso il suo spegni-mento in base al peso (espresso in kW) del carico stesso. La riaccensione di tali carichi verr`a in seguito effettuata gradualmente per evitare pericolosi spunti di assorbimento di corrente in caso di riaccensione contemporanea.
Anche fuori casa `e possibile avere un controllo continuo e in tempo reale degli impianti dei dispositivi domestici. Questo si traduce nella possibilit`a di decidere l’accensione e lo spegnimento di alcuni carichi elettrici e dell’im-pianto di riscaldamento o climatizzazione in funzione del rientro a casa degli occupanti in orari non tradizionali, traendo grandi vantaggi nel comfort.
1.3
I problemi della domotica
Arrivati a questo punto del discorso, dopo aver esplorato almeno in parte tutte le meraviglie e le promesse che la domotica sembra poter soddisfare, dopo aver immaginato una casa che coccola i propri abitanti proteggendoli, seguendo e anticipando le loro preferenze, mantenendo contemporaneamente in sicurezza se stessa dai pericoli che ci sono dentro e fuori dalla casa, verreb-be da chiedersi come mai la domotica non sia un enorme e fiorente mercato. Come mai `e sulla bocca di pubblico specializzato e addetti ai lavori ma non `e
1.1.3 I problemi della domotica 19 ancora esplosa in tutte le sue potenzialit`a? Cosa impedisce a questo mercato di spiccare il volo verso il ricco mercato di massa? Certamente non si tratta solo di un problema di carattere economico, visto che attualmente i costi di componenti e cablaggio di un sistema domotico in una casa in costruzione verrebbe a costare solo il 20-30% rispetto a un sistema tradizionale di pari prestazioni [16], costi che si potrebbero abbattere sensibilmente con la mag-gior diffusione che permetterebbe la copertura di buona parte dei costi di ricerca e promozione.
I motivi dell’attuale impasse vanno cercati principalmente altrove, e vanno distribuiti equamente tra installatori, che hanno ancora poca dimestichezza con i nuovi sistemi domotici, utenti, che temono un notevole aumento delle loro spese, e aziende, che sono ancora restie a permettere una facile integra-zione dei propri sistemi con quelli dei concorrenti.
Gli installatori sono meravigliati dalle molteplici prestazioni offerte, ma quando si trovano a dover fare un preventivo hanno difficolt`a a proporre un impianto domotico completo. Quella dell’installatore `e ancora la figura di un lavoratore molto impegnato con problemi materiali quali la posa di canale, tubi, cavi, ecc. Quando devono occuparsi di configurazioni e programmazione dei dispositivi domotici, offerta di soluzioni integrate di installazione, manu-tenzione e assistenza, si trovano in grande difficolt`a, e faticano ad aggiornarsi alle esigenze di un mercato in rapido cambiamento. Questo problema `e vali-do soprattutto per le piccole imprese a carattere artigianale, mentre `e meno sentito nelle medie imprese che spesso si occupano anche di automazione ne-gli edifici, e all’interno delle quali si trovano pi`u figure di carattere tecnico specializzato. Buona parte di questi problemi potrebbero essere superati ap-poggiandosi ad un progettista abilitato e rivolgendosi al servizio di assistenza del costruttore, ma riguardano una piccola parte degli installatori pi`u smali-ziati e aperti alle novit`a.
Gli utenti dal canto loro, bench´e affascinati dalla tecnologia e dalla pos-sibilit`a di usufruire di nuovi servizi, sono ancora diffidenti verso soluzioni che vengono percepite come complicate e riservate a pochi eletti. La percezione di complessit`a, in questo ambito, `e un problema molto sentito.
20 La Domotica Possiamo citare a tal proposito [2] un fatto piuttosto esplicativo. Per anni sono state costruite lavatrici con evoluti controlli elettronici senza che gli acquirenti ne sapessero nulla. L’aspetto di queste macchine era del tutto uguale a quello delle lavatrici elettromeccaniche delle generazioni precedenti: una grossa manopola simulava il vecchio timer meccanico per la scelta dei programmi di lavaggio e vi era la completa assenza di display. L’unica diffe-renza consisteva ne fatto che il bucato veniva pi`u pulito, con minor consumo di elettricit`a e detersivo. Non veniva messo in evidenza nella pubblicit`a del prodotto che la lavatrice poteva prendere alcune decisioni autonomamente basandosi sul peso della biancheria, sul grado di sporco (rilevato analizzando l’acqua prima e dopo il risciacquo) ecc. Questo perch´e le migliorie appor-tate, bench´e importanti, utili e significative, avrebbero potuto spaventare i potenziali acquirenti.
Eppure esistono ambienti in cui viviamo parte della nostra vita, in cui l’automatizzazione gioca un ruolo importantissimo e non spaventa nel modo pi`u assoluto l’utente finale, anzi sono incentivi alla vendita del prodotto.
Se si confronta, per esempio, l’abitazione tradizionale con un’automo-bile si pu`o constatare che quest’ultimo ambiente si `e evoluto molto pi`u rapidamente.
Attualmente ci troviamo ancora nella situazione in cui l’abitante, rinca-sando di notte, deve ‘tastare’ tutto il muro per cercare l’interruttore che gli permetta di accendere le luci e non inciampare sulla soglia di ingresso. La stessa persona, se entra in macchina di notte, si chiede cosa sia successo se la luce d’interno non si accende automaticamente quando apre lo sportello. La stessa persona che vede di buon grado che la macchina gestisca e controlli la frenata per lui in casi ritenuti pericolosi(intervento del sistema ABS). Perch´e l’utente non cerca lo stesso grado di evoluzione tecnologica che possiede nella propria automobile nella sua stessa casa?
Buona parte della colpa ricade comunque sulle aziende che producono e distribuiscono dispositivi domotici. Se da un lato il mercato si `e arricchito di nuove soluzioni ed il regime di concorrenza ha avuto un effetto benefico sui costi degli impianti, dall’altro c’`e stato un disorientamento da parte dei pro-gettisti e degli installatori che hanno sempre maggiori difficolt`a ad orientarsi
1.1.4 Gli standard domotici 21 sul mercato. Tantissime aziende negli ultimi anni, hanno avuto nei confronti della domotica un atteggiamento ambiguo. Da una parte si `e cercato di unire gli sforzi in associazioni sempre pi`u grandi per creare uno standard domotico unico e definitivo, dall’altra ognuno ha cercato di imporre sul mercato il pro-prio standard cercando di approfittare di una possibile posizione dominante. Il fatto che in realt`a non esista un vero e proprio leader del mercato ha por-tato invece ad una proliferazione di standard pi`u o meno diffusi che creano moltissima confusione. La mancanza di uno standard comune impedisce a diversi componenti domotici, che utilizzano standard diversi, di poter esse-re liberamente installati in una stessa installazione domotica. Non `e ancora nato, infatti, un mercato nel quale i componenti tecnologici proposti dalle diverse aziende produttrici possano comunicare tra loro, innescando un mec-canismo di diffusione della domotica e di riduzione dei costi grazie ad una maggiore possibilit`a di scelta da parte di chi decide di installare un nuovo sistema domotico.
Proprio questo problema `e stato preso in esame nell’ambito di questa tesi in cui si `e cercato di risolvere, almeno in parte, il problema dell’interope-rabilit`a, o meglio della mancanza di interopedell’interope-rabilit`a, nei sistemi domotici. Sarebbe infatti auspicabile che i futuri sistemi domotici si appoggiassero sul-le nuove tecnologie (hardware e software) che rendono possibisul-le una gestione della mancanza di uniformit`a dei sistemi sottostanti, in modo da far interagire prodotti di case produttrici diverse, in modo trasparente all’utente.
Per avere un’idea pi`u chiara dei molteplici standard domotici presenti sul mercato ne verranno descritti i pi`u diffusi nel paragrafo seguente. E’ da sottolineare per`o come questi rappresentano s`ı i pi`u diffusi, ma si trovano comunque a coesistere con i molti altri paradigmi di comunicazione presenti sul mercato.
1.4
Gli standard domotici
I principali standard utilizzati nel mondo della domotica sono in molti casi localizzati in particolari aree del mondo piuttosto che in altre per via del fatto che in alcuni paesi pi`u volte si `e tentato di spingere e standardizzare un determinato protocollo per mezzo di associazioni tra produttori o a volte a
22 La Domotica livello istituzionale. Il risultato sono un buon numero di standard come EHS, EIB, BatiBus che si sono successivamente riuniti nello standard Konnex per il mercato Europeo, Lontalk, Havi, Cebus e X10 per il mercato Americano, e infine HBS per il mercato Giapponese. Di seguito una breve descrizione di questi standard con le caratteristiche pi`u interessanti.
Figura 1.1: Mercato mondiale degli standard
1.4.1
EIB
EIB identifica l’acronimo European Installation Bus, sviluppato da EI-BA [11] (European Installation Bus Association). Il protocollo `e stato svi-luppato da un pool di aziende leader nei settori dei materiali e componenti per l’installazione elettrica, per soddisfare le esigenze legate all’automazione di case, uffici, ed edifici in genere. EIB `e uno standard aperto e disponibile a tutti i costruttori che intendono fornire soluzioni innovative nel settore del-l’automazione degli edifici. Pu`o utilizzare come mezzo trasmissivo doppino, powerline (onde convogliate su rete elettrica), EIB.net (Ethernet), frequenze radio e infrarosso. A una rete Eibus (dorsale di tipo bus dello standard EIB) `e possibile collegare fino a 61.455 dispositivi. Il protocollo dello standard `e sviluppato sui sette livelli del modello OSI.
1.4.2
EHS
EHS `e l’acronimo di European Home System, sviluppato da EHSA (Eu-ropean Home System Association). Le specifiche EHS, sviluppate in seno al progetto europeo ESPRIT (European Strategy Programme for Research &
1.1.4.3 BatiBus 23 Development in Information Tecnologies) n.2431 , da esperti delle principa-li industrie e grazie ad una collaborazione governativa, definiscono il modo in cui dispositivi elettrici ed elettronici presenti all’interno e all’esterno di un abitazione, possono comunicare tra loro, utilizzando tutti i media co-munemente disponibili. E’ uno standard aperto per il quale `e prevista una certificazione dei prodotti. Il sistema pu`o controllare milioni di indirizzi, cor-rispondenti ad altrettanti dispositivi collegati alla rete, riuniti in gruppi di 256 elementi. Dispone di funzionalit`a Plug & Play e di un efficace servizio svi-luppato per fornire robustezza al sistema contro gli errori di comunicazione, apparecchi mal funzionanti o ri-allocazioni casuali.
1.4.3
BatiBus
Sviluppato da BatiBus Club International con lo scopo di promuovere le applicazioni dello standard BatiBus. Si tratta di uno standard aperto il cui mezzo trasmissivo utilizzato `e il doppino, su varie topologie di rete: stella, anello, bus, albero, oppure una loro combinazione. Il doppino permette il transito di comandi e dati tra CPU, sensori ed attuatori, che compongono un sistema di automazione domestica. E’ utilizzata per lo pi`u nell’ambito dell’automazione di edifici industriali.
1.4.4
Konnex
Si tratta di uno standard definito a livello Europeo che riunisce sotto il medesimo tetto l’esperienza e le specifiche di tre dei principali sistemi per l’automazione domestica usati in Europa: EIB, EHS, e BatiBus. Lostandard Konnex `e stato adottato da oltre cento aziende diverse che hanno sviluppato prodotti e soluzioni completamente interoperanti tra di loro e hanno di fatto costituito la pi`u ampia offerta di dispositivi per l’automazione degli edifici presente sul mercato [13]. Konnex si basa su un’architettura distribuita costi-tuita da una rete di dispositivi che interagiscono tra loro attraverso una serie di protocolli e segnalazioni che sono stato dettagliatamente descritti dallo standard [19]. I mezzi di comunicazione che il modello Konnex stabilisce di utilizzare come infrastruttura di rete sono di vario tipo: principalmente li doppino (‘twisted-pair’), in misura minore le onde convogliate su rete
elet-24 La Domotica trica (‘powerline’) e, pi`u recentemente, la radio frequenza (868 MHz). La progettazione e la configurazione di un sistema di home/building automa-tion basato su Konnex `e adattata alle esigenze del caso. La flessibilit`a e la modularit`a di Konnex si ha sia nelle tipologie di hardware utilizzabile per realizzare i dispositivi (possono essere usati, a seconda dell’obbiettivo, archi-tetture molto semplici o molto evolute, fino ai sistemi pc) sia nella modalit`a con cui il sistema pu`o essere configurato. Lo standard prevede tre diverse mo-dalit`a di configurazione con diversi target applicativi e corrispondenti livelli di difficolt`a:
System Mode La modalit`a di configurazione System mode che riprende le specifiche EIB, `e in assoluto la pi`u completa, in quanto permette di agire su tutti i parametri di funzionamento, ma richiede l’intervento di un tecnico specializzato e l’utilizzo di un software di programmazione (ETS) distribuito da Konnex a livello internazionale.
Easy mode La modalit`a Easy mode riprende le specifiche BatiBUS e pre-dispone una serie di profili funzionali che permettono di effettuare la configurazione in modo pi`u semplice e senza richiedere l’uso di un PC (piuttosto possono essere usate interfacce pi`u immediate, ad esempio pulsantiere)
Automatic mode L’Automatic mode deriva direttamente dalle specifiche EHS, ed `e quello che offre una configurabilit`a plug-and-play special-memte rivolta al settore di ‘consumer electronics’, permettendo cos`ı all’utente finale di aggiungere nuovi dispotivi alla rete.
Le specifiche della rete Konnex seguono il modello architetturale standard ISO/OSI per definire i protocolli e le funzionalit`a offerte da ogni layer, ed in particolare come `e possibile vedere nella figura 1.2 sono definiti quattro dei sette layer del modelo standard: il layer physical (1), data link (2), network (3) e il layer application (7).
Grazie al fatto che Konnex `e un sistema aperto, esente da royalty e com-pletamente indipendente dal costruttore, la comunit`a scientifica Europea par-tecipa attivamente allo sviluppo di soluzioni innovative basate su questo stan-dard. Nel 2003 il Comitato tecnico Europeo CENELEC ha indicato Konnex
1.1.4.5 LonWorks 25
Figura 1.2: Il modello architetturale Konnex
come riferimento per i sistemi dedicati alla automazione e al controllo delle case.
1.4.5
LonWorks
La tecnologia LonWorks `e stata introdotta sul mercato dall’americana Echelon Corporation che poi si `e trasformata in LonMark International strut-turandosi come organizzazione indipendente i cui membri sono sviluppatori, produttori, system integrator, e utilizzatori finali di questa tecnologia [13]. Si tratta di uno standard aperto con architettura distribuita che non prevede il pagamento di alcuna royalty. Garantisce l’interoperabilit`a dei dispositivi attraverso la standardizzazione delle variabili che transitano nella rete [22]. I dispositivi comunicano attraverso il protocollo LonTalk e sono sviluppati at-torno ad un circuito integrato, il Neuron Chip, che integra tre processori, due dei quali dedicati alla gestione del protocollo e il terzo in grado di eseguire codice scritto dall’utilizzatore. Ogni nodo `e costituito da un Neuron Chip, un
26 La Domotica transceiver (un device che si occupa sia della trasmissione che della ricezione) ed un circuito elettronico specifico per l’applicazione. Il collegamento tra i dispositivi pu`o essere realizzato con un doppino intrecciato, ad onde convo-gliate sulla rete elettrica, via radio o in fibra ottica. Ogni dispositivo viene individuato sulla rete attraverso un sofisticato meccanismo di indirizzamen-to a pi`u livelli che consente un rapido ed efficiente scambio di messaggi. Si identificano quattro tipi di indirizzo:
fisico Chiamato Neuron ID, unico in tutto il mondo , non cambia mai ed assegnato in fase di costruzione del Neuron Chip.
di dispositivo Assegnato quando il dispositivo `e installato in una certa re-te. Viene utilizzato al posto dell’indirizzo fisico, perch´e consente un istradamento pi`u efficace dei messaggi e semplifica la sostituzione dei dispositivi guasti.
di gruppo Serve ad ottimizzare il traffico di rete quando lo stesso messaggio `e indirizzato a diversi dispositivi
broadcast Identifica tutti i dispositivi di una sottorete.
Per la configurazione e la messa in funzione del sistema sono disponibili una serie di tool software tra cui il LonBuilder Developer’s Workbench, il NodeBuilder Tool e il Lon Maker che oltre all’ambiente di programmazione forniscono anche potenti funzioni di debug. La tecnologia LonWorks `e stata fatta propria della EIA (Electronic Industries Alliances) ed integrata nello standard americano EIA-709. In Italia, i nuovi contatori elettronici di energia installati dall’Enel adottano questa tecnologia.
1.4.6
UPnP
Universal Plug and Play (UPnP) `e un protocollo di rete creato dall’UPnP Forum [37], un’iniziativa guidata da Microsoft e da oltre 700 partner indu-striali. L’obiettivo della tecnologia UPnP `e quello di permettere a diversi terminali di connettersi l’uno all’altro e di semplificare drasticamente l’uti-lizzo di reti domestiche e aziendali mediante lo sviluppo di reti peer-to-peer tra i dispositivi. Il termine plug and play indica la possibilit`a di utilizzare un
1.1.4.6 UPnP 27 componente non appena viene connesso al computer o alla rete, senza dover effettuare nessun tipo di configurazione manuale.
E’ progettato per supportare reti a configurazione nulla (zero-configuration), reti invisibili (invisibile networking), e il riconoscimento automatico di una vasta gamma di dispositivi. Questo significa che ogni apparecchiatura pu`o entrare a far parte della rete, ottenere un indirizzo IP, trasmettere le sue refe-renze e ricevere informazioni sulla presenza e le capacit`a degli altri dispositivi presenti in modo dinamico e senza il bisogno di un intervento esterno.
I protocolli utilizzati da UPnP sono quelli standard di Internet come IP, TCP, UDP, HTTP, XML e SOAP. Questo consente il supporto di qualsiasi mezzo fisico per cui sia disponibile lo stack TCP/IP, e lo sviluppo di software attraverso molteplici linguaggi di programmazione, su qualunque ambiente operativo implementi TCP/IP.
UPnP identifica due classi di dispositivi: device e control point. Un device (o controlled device) svolge il tipico ruolo di un server, rispondendo alle richieste provenienti da uno o pi`u control point, che assume quindi il ruolo di client.
L’interazione generale in uno scenario UPnP prevede 6 fasi distinte: ad-dressing, discovery, description, control, eventing e presentation.
addressing La fase di addressing, `e quella che consente al dispositivo con-nesso di poter avere un proprio indirizzo IP. Questo avverr`a mediante un DHCP (Dynamic Host Configuration Protocol ) se presente, o me-diante un auto-assegnamneto (meccanismo di AutoIP) per ottenere un indirizzo valido.
discovery Non appena il dispositivo ha ottenuto un proprio indirizzo, viene eseguita la fase di discovery, che consiste nel pubblicare i propri servizi se il dispositivo `e un device, oppure nel caso sia un control point ricerca tutti i servizi a cui `e interessato. Entrambe le interazioni avvengono mediante il protocollo di discovery utilizzato dallo standard, l’SSPD (Simple Service Discovery Protocol).
description La fase di description prevede che quando un control point nota la presenza di un dispositvo, richiede al device la descrizione in formato XML, a partire dalla URL (Uniform Resource Locator) fornita dallo
28 La Domotica stesso dispositivo durante la fase di discovery. Nella descrizione oltre al nome del produttore e il numero seriale, sono specificati i dettagli di ogni servizio esposto.
control Quando il control point ha ottenuto tutte le informazioni necessarie per un certo dispositivo, pu`o invocare le azioni corrispondenti ai servizi che questo espone. L’interazione avviene tramite lo scambio di messaggi SOAP (Simple Object Access Protocol), seguendo un modello RPC (Remote Procedure Call).
eventing Ogni device pu`o avere una serie di variabili di stato che col tempo cambiano. La fase di eventing mediante l’utilizzo di messaggi scambiati col protocollo GENA (General Event Notification Architecture), espres-si secondo il formalismo standard XML, permettono l’aggiornamento delle notifiche di questi stati da parte dei control point.
presentation Se il control point ha bisogno di ottenere informazioni ag-giuntive su un particolare dispositivo, queste possono essere acquisite, se presenti, da una pagina web indicata in un’opportuna URL nel file XML di descrizione del dispositivo.
1.4.7
X10
Il protocollo X10, nato nel 1976, `e lo standard storico della domotica. X10 `e basato su una semplice architettura centralizzata, in cui un singolo di-spositivo di controllo pu`o controllare fino a 256 tipi di periferiche (`e possibile assegnare uno stesso indirizzo a pi`u periferiche per far eseguire a tutte gli stessi comandi). E’ inoltre possibile controllare i vari dispositivi sfruttando dei telecomandi a onde radio [39]. Il dispositivo di controllo `e gestibile anche mediante un personal computer. Per consentire la diffusione del protocollo sono state scelte come mezzo di comunicazione sono le powerline. Il proto-collo `e molto semplice e prevede che a ogni periferica venga assegnato un indirizzo statico di 8 bit (i primi quattro tipicamente rappresentati da una lettera da A a P e i secondi quattro da un numero da 1 a 16) a tempo di installazione. L’invio di un comando da parte del controllore o di un tele-comando prevede l’invio in broadcast sul bus utilizzato di 12 bit, i primi 8
1.1.5 Stato dell’arte 29 rappresentanti l’indirizzo della periferica che deve eseguire il comando, e i restanti 4 rappresentanti il comando stesso. E’ evidente quindi come tramite X10 sia possibile l’automazione solamente di semplici funzionalit`a domesti-che. L’estrema semplicit`a e il basso costo di installazione e realizzazione di prodotti compatibili hanno fatto s`ı che le aziende realizzassero molti prodotti idonei allo standard e quindi, ancora oggi, lo X10 `e molto diffuso.
1.5
Stato dell’arte
Nel corso degli ultimi anni, sono state proposte alcune interessanti soluzio-ni al problema dell’interoperabilit`a dei sistemi domotici di standard differenti, soluzioni innovative con un buon livello di scalabilit`a e affidabilit`a.
Weseda University [34] ha per esempio sviluppato un framework per con-sentire una facile integrazione di middleware domotici attuali, e linee guida per l’inserimento di nuovi middleware in futuro. Tutto ci`o si ottiene me-diante l’uso di un Virtual Service Gateway che connette middleware distinti sfruttando un Protocol Conversion Manager, il cui compito `e convertire i diversi protocolli standard o proprietari, in un protocollo comune utilizzato dal Virtual Service Gateway. Informazioni riguardanti invece la posizione di un dispositivo, o le funzioni messe a disposizioni dei servizi, sono fornite da un’altro servizio chiamato Virtual Repository.
Il gruppo Open Building Information Exchange [29], lavora invece su una piattaforma basata su Web Service e uno standard XML, per l’automazione di sitemi meccanici ed elettronici.
L’univesit`a di Twente [32] propone una soluzione che mira a sostenere tecnologie eterogenee utilizzando la cosiddetta cluster culture, cio`e applica-zioni e servizi che che risiedono in un cluster, condividono l’interesse per un determinato valore. L’architettura basata sul sistema touch and play per-mette, a tempo di registrazione dei dispositivi, lo scambio delle informazioni tra i propri gateway e i dispositivi stessi, senza una preventiva configurazione (‘zero-configuration’) dei servizi, che sono organizzati mediante una struttura gerarchica. L’architettura consente inoltre un alto livello di sicurezza utiliz-zando algoritmi crittografici, che vengono utilizzati sia durante il discovery dei servizi dei device, sia durante l’esecuzione del servizio.
30 La Domotica Un altro progetto interessante `e il Domotic House Gateway [30], un si-stema basato su un meccanismo ad eventi per lo scambio di messaggi tra il dispositivo e il sistema. Tali eventi ‘fisici’ sono convertiti logicamente in eventi interni al sistema in modo da separare nettamente quello che succede a livello fisico su un dispositivo e la relativa semantica, dal ruolo che poi effettivamente occuper`a all’interno della casa. Il primo livello dell’architet-tura, ha lo scopo di implementare un layer basato su regole, che pu`o essere per`o adattato, o dinamicamente dal sistema stesso o manualmente tramite interfacce esterne. Ogni dispositivo ha bisogno di un driver di periferica che `e responsabile della traduzione del linguaggio a basso livello dell’hardware e degli stessi stati, in eventi del sistema.
Un importante progetto europeo `e Amigo [1]. Questo progetto, che avr`a termine a marzo del 2008, ha l’obiettivo di rendere intelligente un ambiente come la casa, mediante l’interconnessione delle reti, ed ha come obbiettivo principale, l’usabilit`a del sistema. Il concetto di usabilit`a deve essere rag-giunto mediante tre importanti target: l’uso di interfacce user-friendly, l’in-teroperabilit`a, e il discovery automatico dii dispositivi e servizi. I principi architetturali, molto simili a DomoNet, e gli obbiettivi promessi, hanno fatto si che questo progetto ricevesse un finanziamento dell’Unione Europea di 13 milioni di Euro. Tutt’ora per`o l’unica tecnologia integrata nel framework `e UPnP.
Capitolo 2
DomoNet
In questo capitolo verr`a descritta la struttura e l’architettura di DomoNet, un framework sviluppato con l’obiettivo di risolvere i problemi derivanti dalla compresenza di dispositivi con diversi standard domotici, che di per s´e non riescono e comunicare e interagire tra loro.
2.1
Il framework DomoNet
Una possibile soluzione al problema dell’interoperabilit`a fra i diversi stan-dard domotici `e stata sviluppata in precedenti tesi di laurea [31] e articoli [27] in cui `e stata delineata e implementata un’infrastruttura che rende possibi-le una comunicazione tra dispositivi diversi, con standard diversi, realizzata attraverso la traduzione dei vari protocolli in un linguaggio comune.
Il risultato di tali lavori `e stata la realizzazione di un’infrastruttura basata sul modello di un framework, avendo l’obiettivo di fornire un insieme di fun-zionalit`a di base che potessero integrare i principali standard domotici, ma anche di fornire una solida interfaccia che permettesse una facile estensione a tutti quelli standard domotici non considerati in prima istanza. Durante lo sviluppo dell’applicazione infatti sono stati implementati due moduli, capaci di gestire i dispositivi Konnex e UPnP (due teconologie tra le pi`u diffuse nella domotica). Come gi`a detto durante una parte di questa tesi `e stato implementato il modulo utilizzabile per l’integrazione dei dispositivi BTici-no, resa possibile proprio grazie alla modello di framework su cui `e basata l’applicazione che rende possibile una sua facile estensione.
32 DomoNet Questo framework, denominato DomoNet, fornisce una visione dell’intera topologia della rete secondo un modello SOA, ed `e basato sull’utilizzo di uno o pi`u web service a cui ogni dispositivo domotico `e collegato tramite un modulo specializzato e diverso a seconda della tecnologia utilizzata.
Invocando un modulo specializzato per ogni tecnologia, il web service `e in grado di volta in volta di gestire l’esecuzione e il controllo di un dispositivo domotico.Il modulo, funzionando da gateway, ha il compito di tradurre ogni messaggio che transita tra i dispositivi di un determinato standard, in un linguaggio comune, per permettere la cooperazione tra device di tecnologie diverse. Al fine di gestire efficientemente la comunicazione tra i dispositivi, principale obiettivo del sistema, `e stato utilizzato un linguaggio, basato su XML, in cui vengono tradotti tutti i messaggi da e per i dispositivi domotici. Tale linguaggio, denominato DomoML [14], `e stato introdotto per tradurre in un linguaggio comune per tutte le tecnologie, le funzionalit`a e i servizi di un particolare dispositivo domotico. DomoML permette inoltre una descri-zione astratta di tutti dispositivi domotici (domoDevice) e rende possibile la comunicazione tra tecnologie differenti.
L’architettura DomoNet `e quindi composta da uno o pi`u (web service) e da uno o pi`u client utilizzati per il controllo remoto dei dispositivi domoti-ci collegati alla rete DomoNet. La struttura portante di tale architettura `e mostrata in figura 2.1, in cui possiamo osservare le componenti principali.
Il framework DomoNet `e costituito da due parti distinte: il lato client (il DomoNetClient), e il lato server (web service che ingloba anche i cosiddetti tech managers). Un client, dopo essersi collegato ad un web service riceve una lista dei dispositivi domotici connessi al server mediante i tech manegers. Quest’ultimi infatti sono dei veri e propri gateway, collegati fisicamente ad una determinata rete domotica, che rendono disponibile al web service un’a-strazione dei dispositivi domotici a loro connessi mediante una descrizione dei device in DomoML. Nel momento in cui deve essere eseguita una ope-razione remota sui dispositivi, il client inoltra al server il tipo di opeope-razione che intende richiedere e il dispositivo che intende utilizzare. Il server prova a soddisfare la richiesta, inoltrandola al tech manager opportuno, che essen-do l’unico a conoscere il protocollo e il linguaggio di comunicazione di una particolare tecnologia, traduce il messaggio in modo opportuno e risponde al
2.2.1 Il framework DomoNet 33
Figura 2.1: Architettura di DomoNet
server, che a sua volta invia una risposta al client comunicando il successo o il fallimento dell’esecuzione dell’operazione richiesta. Le comunicazioni tra il server e il client avvengono mediante il protocollo TCP/IP utilizzando ancora il linguaggio DomoML.
Il client pu`o quindi essere usato come punto centralizzato del controllo e della gestione di tutti i dispositivi domotici presenti in una casa o in un edificio in modo del tutto indipendente dai tipi, le funzioni, le tecnologie e gli standard presenti. DomoNet per`o `e stato concepito e sviluppato per an-dare oltre il semplice controllo di un dispositivo domotico. L’obbiettivo di questo framework `e l’interoperabilit`a dei sistemi domotici, interoperabilit`a intesa nel senso pi`u esteso del termine, mediante l’associazione di servizi. Per servizio si intende una qualunque azione che un device domotico mette a di-sposizione al mondo esterno. Un player musicale ad esempio deve per forza di cose permettere la scelta di una traccia musicale, l’esecuzione di questa, lo stop, la pausa e generalmente anche la gestione del volume, del bilanciamento dei toni ecc. Quelli appena descritti possono essere definiti, e cos`ı avviene in DomoNet, in servizi che il dispositivo player musicale mette a disposizione. DomoNet, frapponendosi tra le reti domotiche, realizza l’interoperabilit`a as-sociando in un semplicissimo esempio il servizio accendi/spegni lampadina
34 DomoNet della tecnologia X con il servizio on/off dell’interruttore della tecnologia Y. Quanto appena descritto avviene mediante l’uso dei LinkedService, quello che possiamo definire il vero cuore di DomoNet.
Nei prossimi paragrafi verranno descritti i componenti fondamentali del framework DomoNet finora appena accennati: il linguaggio DomoML, il lato client e server, nonch´e i techManger.
2.1.1
DomoML
DomoML `e un un linguaggio per rappresentare in maniera compatta i di-spositivi domotici, i relativi servizi offerti e le relative interazioni, astraendo dalla tecnologia di appartenenza. DomoML, usato con questa architettura, `e un middle language da e verso il quale tradurre le rappresentazioni dei dispo-sitivi e dei pacchetti. Ad esclusione delle interazioni fisiche tra i techManager e i device, che usano il linguaggio specifico e proprio di ogni tecnologia, tutta la parte logica dell’architettura DomoNet utilizza DomoML.
Per mezzo del formalismo del linguaggio DomoML `e possibile rappresen-tare i:
domoDevice : una descrizione astratta dei dispositivi.
domoMessage : una descrizione astratta delle interazioni da e verso i dispo-sitivi.
2.1.1.1 DomoDevice
Ogni domoDevice fornisce una descrizione di un dispositivo connesso alla rete DomoNet astraendo dalla tecnologia.
Un esempio di domoDevice per una lampadina `e mostrato nella figura 2.2.
Il tag device rappresenta un generico domoDevice, attraverso gli attri-buti che forniscono una sintetica descrizione del tipo di device, la posizione all’interno della casa e informazioni sul costruttore. Osservando gli attributi del tag device, tra i pi`u significativi possiamo individuare:
2.2.1.1 DomoML 35
<device description="lampada a risparmio energetico" id="0"
manufacturer="pholips" postionDescription="comodino accanto al letto" serialNumber="xxxxxxxxx" tech="KNX" type="lampada"
url="http://www.questowebservice.it/servizio">
<service output="BOOLEAN" outputDescription="The value" name="GET STATUS" prettyName="Get status" />
<service name="SET STATUS" prettyName="Set status">
<input description="The value" name="status" type="BOOLEAN"> <allowed value="TRUE" />
<allowed value="FALSE" /> </input>
<LinkedService id="3" service="setPower" url="http://www.altrowebservice.it/servizio">
<linkedInput from="status" to="power" /> </LinkedService>
</service> </device>
Figura 2.2: DomoDevice di una lampadina
• id, un identificatore univoco del dispositivo all’interno del web service • serialNumber, che permette l’identificazione univoca del dispositivo
all’interno della propria tecnologia. Esempi di numeri seriali sono:
per UPNP serialNumber=’uuid:214578e3-d4a0-f498-790e-d927709b781d’ per BTicino serialNumber=’*1**24##’
per Konnex serialNumber=’1.1.18’ • tech, la tecnologia nativa del dispositivo • URL, l’indirizzo web del web service
Gli attributi id e url vengono utilizzati dal web service per ricavare il domoDeviceID, l’indentificatore di un device all’interno di DomoNet. Con l’attributo tech sono gli unici obbligatori.
Ogni domoDevice pu`o offrire uno o pi`u servizi descritti nel tag service. Quest’ultimo `e composto dagli attributi:
36 DomoNet • name, il nome del servizio
• prettyName, la descrizione in linguaggio naturale del servizio • output, il tipo dell’output risultante dall’esecuzione del servizio • outputDescription, la descrizione dell’output generato dal servizio Ogni tag service pu`o contenere uno o pi`u tag input. Questi stanno ad indicare che il servizio necessita di un input per poter essere eseguito. gli attributi che lo compongono sono:
• description, la descrizione dell’input • name, il nome dell’input
• type, il tipo (String, int, boolean ecc.) dell’input
Se un input pu`o assumere solo un determinato sottoinsieme di valori, possono essere aggiunti come figli del tag input, uno o pi`u tag allowed in ognuno dei quali specificare, attraverso l’attributo value, uno dei valori di input permessi.
Se all’esecuzione di un servizio `e associata l’esecuzione di una altro servi-zio, non necessariamente dello stesso domoDevice, all’interno del tag service pu`o essere specificato un tag LinkedService. Gli attributi di un LinkedService sono:
• URL, l’indirizzo del web service che gestisce il domoDevice da collegare al servizio
• id, l’identificatore del domoDevice all’interno del web service specifi-cato in URL
• service,il nome del servizio da collegare del domoDevice individuato dai precedenti attributi
All’interno di un tag LinkedService possono essere specificati uno o pi`u tag linkedInput. Quest’ultimi specificano quale input del presente servizio deve essere associato agli input del servizio da richiamare. Ogni input del
2.2.1.1 DomoML 37 servizio da richiamare deve avere un’associazione, in questo modo il valo-re dell’input del pvalo-resente servizio viene passato come input al servizio da richiamare. Gli attributi di LinkedService sono:
• from, `e il nome dell’input di questo servizio dal quale prendere il valore • to, `e il nome input a cui passare il valore assunto dall’input specificato
nel campo from
L’associazione di servizi non ha vincoli semantici ovvero `e possibile com-binare un servizio con qualsiasi altro a patto di riuscire a dare dei valori compatibili ai linkedInput.
2.1.1.2 DomoMessage
Il domoMessage ha lo scopo di creare un meccanismo semplice, compatto ed efficace per rappresentare le interazioni tra i domoDevice astraendo dalle tecnologie.
Un esempio di domoMessage per l’accensione di una lampadina `e mostra-to in figura 2.3.
<message message="SET_STATUS" messageType="COMMAND" receiverId="1" receiverURL="http://www.altrowebservice.it/servizio" senderId="0" senderURL="http://www.questowebservice.it/servizio">
<input name="status" type="BOOLEAN" value="TRUE" /> </message>
Figura 2.3: Messaggio di tipo COMMAND per l’accensione di una lampadina Il tag message rappresenta un generico messaggio. Gli attributi che lo compongono permettono di descrivere qualunque tipo di messaggio che tran-sita all’interno della rete DomoNet. Gli attributi di un tag message sono:
• message, il corpo del messaggio. Se il messaggio `e un comando, tipica-mente contiene il nome del servizio da eseguire.
• messageType, il tipo del messaggio. Tra i possibili messaggi attualmen-te trasmissibili ci sono:
38 DomoNet – COMMAND, se il messaggio `e una richiesta di esecuzione di un
comando, tipicamente l’esecuzione di un servizio
– SUCCESS, se `e un messaggio di risposta a l’esecuzione di un co-mando con esito positivo. In questo caso l’attributo message pu`o contenere un valore di risposta.
– FAILURE, se `e un messaggio di risposta a l’esecuzione di un co-mando con esito negativo.In questo caso l’attributo message pu`o contenere un codice di errore.
– UPDATE, utilizzato per informare DomoNet che un determinato dispositivo ha cambiato stato. Viene utilizzato principalmente per aggiornare lo stato nelle interfacce del lato client di DomoNet quando si verifica un evento esterno (tipicamente all’interno della sottorete domotica).
• receiverURL, l’indirizzo web del web service destinatario il messaggio • receiverId, l’identificatore univoco all’interno del web service
desti-natario, del domoDevice che dovr`a eseguire il comando
• senderURL,l’indirizzo web del web service che ha inviato il messaggio • senderId, l’identificatore univoco all’interno del web service mittente,
del domoDevice che ha richiesto l’esecuzione del comando
Nel caso in cui il messaggio sia di tipo COMMAND il tag message pu`o contenere uno o pi`u tag input, che rappresentano i valori da associare agli input del servizio da eseguire. Gli attributi possibili sono:
• name, il nome dell’input del servizio da eseguire
• type, il DomoDevice.DataType dell’input del servizio da eseguire (per esempio String, int, byte ecc.)
• value, il valore in formato stringa dell’input del servizio da eseguire In figura 2.4 si pu`o vedere un esempio di messaggio di conferma al mittente che il precedente messaggio 2.3 `e stato eseguito con successo e che la lampada `e ora accesa.
2.2.1.2 DomoNetWS 39
<message message="TRUE" messageType="SUCCESS"
receiverURL="http://www.questowebservice.it/servizio" receiverId="0" senderId="1"
senderURL="http://www.altrowebservice.it/servizio" />
Figura 2.4: Messaggio di tipo SUCCESS in risposta a un comando eseguito
2.1.2
DomoNetWS
DomoNetWs `e il lato server dell’applicazione DomoNet. La sua funzione `e quella di rendere possibile la cooperazione tra le diverse tecnologie domotiche. Permette il controllo dello stato dei device e l’esecuzione di comandi da parte di altri web service o dei client.
Figura 2.5: Architettura del lato server di DomoNet
Nel momento in cui il DomoNetWs viene avviato, carica tutti i tech ma-nager presenti nella techMama-nagerList che a loro volta restituiscono tutti i device collegati. Ogni device restituito dai techManager convertito secondo il formalismo DomoML e assegnatoli un DomoDeviceId viene inserito nella DomoDeviceList. Un DomoDeviceId `e composto dall’URL del web service e l’id del dispositivo, in realt`a un numero progressivo assegnato dal web service. La richiesta di esecuzione di un comando pu`o provenire dallo stesso web service, da un altro web service (per implementare la cooperazione) o da un client (per il controllo e la gestione dei dispositivi). DomoNetWs
rac-40 DomoNet coglie il domoMessage ricevuto, ricava il DomoDeviceId attraverso gli at-tributi receiverURL e receiverId presenti nel messaggio, ed estrae dal-la lista DomoDeviceList il domoDevice interessato. Dal domoDevice vie-ne ricavata la tecnologia di appartevie-nenza del dispositivo, ed estratto dalla techManagerList il rispettivo techManager. Viene a questo punto delegata al techManager l’esecuzione vera e propria del comando, che verr`a effet-tuata secondo il rispettivo techMessage. Finita l’esecuzione del messaggio il techManager invia un nuovo domoMessage a DomoNetWs che conterr`a il va-lore SUCCESS, se l’esecuzione `e avvenuta senza problemi, o FAILURE se il comando non `e potuto essere eseguito.
2.1.2.1 Tech Manager
Per potersi interfacciare fisicamente con le rispettive reti degli standard domotici, DomoNet necessita dell’implementazione di un gateway specializ-zato per ogni diversa tecnologia. Questi gateway chiamati tech manager, una volta sviluppati possono essere inclusi in DomoNet ed utilizzati senza alcun sforzo aggiuntivo, per via del fatto che estendono delle interfacce comuni.
Il tech manager `e implementato per poter interagire, comandare e control-lare tutti i dispositivi di una determinata tecnologia utilizzando il linguaggio e il protocollo nativo di un determinato standard. Tra i principali compiti che un tech manager deve implementare ci sono:
• Restituire una lista dei dispositivi collegati alla propria sottorete • Tradurre un DomoDeviceId (l’indenficatore unico di un dispositivo
in DomoNet) in un indirizzo reale nella tecnologia del dispositivo e viceversa
• Tradurre un domoMessage in un techMessage e viceversa
L’ultimo punto `e chiaramente il pi`u importante tra tutti. Il compito prin-cipale di un TechManager `e infatti proprio quello della traduzione dei mes-saggi provenienti dalla specifica rete domotica in mesmes-saggi che rispecchiano il formalismo di DomoNet utilizzando il linguaggio DomoML e viceersa. Il techManager `e la parte di DomoNet pi`u complicata da sviluppare, in quan-to necessita della conoscenza dettagliata di una determinata tecnologia, dei
2.2.1.2 DomoNetWS 41 suoi protocolli, della sintassi dei linguaggi e dei messaggi utilizzati, dei tipi di dati ammissibili, e di tutta una serie di informazioni che non si possono improvvisare, pena l’errato funzionamento del techManager.
Non `e possibile descrivere ne dettaglio un techManager, in quanto ognuno si differenzia profondamente in funzione della tecnologia che implementa. Quello che `e possibile fare `e dare una descrizione dei passi che sicuramente un techManager deve effettuare per tradurre in un senso e nell’altro messaggi provenienti da DomoNet e dalla rete domotica specifica.
Quando un tech manager riceve un domoMessage dal web service, il primo passo da compiere, `e trovare la corrispondenza tra il domoAddress (Domo-DeviceId ) e il realAddress (l’indirizzo del dispositivo nella propria tecnolo-gia). Questa corrispondenza verr`a trovata utilizzando un hash-map che ha come chiave proprio il DomoDeviceId. Un volta ricavato il realAddress e verificato che il messaggio `e di tipo COMMAND, il tech manager deve crea-re l’opportuno techMessage interpcrea-retando il valocrea-re dell’attributo message e convertendo gli input del domoMessage in opportuni input del techMessage utilizzando gli attributi dataType e value. Inviato il techMessage sul mezzo di comunicazione specifico della tecnologia in uso, viene creato il domoMes-sage di risposta. Se l’esecuzione del techMesdomoMes-sage prevedeva un risposta o un valore di output questo verr`a convertito, e inserito nel domoMessage di tipo SUCCESS o FAILURE nell’attributo message. Se non `e previsto un valore di output, verr`a comunque creato il domoMessagge di successo o fallimento, ma questa volta con attributo message vuoto.
Figura 2.6: Diagramma UML di esecuzione di un LinkedService in seguito ad un evento
