Ambienti di Sviluppo Integrati per Sistemi Domotici Intelligenti

Transcript

1 POLITECNICO DI TORINO III Facoltà di Ingegneria dell Informazione Corso di Laurea in Ingegneria Informatica Tesi di Laurea Specialistica Ambienti di Sviluppo Integrati per Sistemi Domotici Intelligenti Relatori: prof. Fulvio Corno ing. Dario Bonino Candidato: Daniele Mina Luglio 2011

2 Indice 1 Introduzione Scenario Obiettivi Struttura della tesi Stato dell arte Sistemi domotici Intelligent Domotic Environment Il linguaggio DogOnt DogOnt Ontology Il gateway DOG Architettura Punti critici e aree di possibile miglioramento Obiettivi Scopo della tesi Requisiti Requisiti funzionali Requisiti non funzionali Analisi delle possibili soluzioni Strumenti utilizzati La piattaforma Eclipse Eclipse Modeling Framework Componenti Definire un modello EMF Graphical Editing Framework Componenti Usare GEF con EMF Graphical Modeling Framework II

3 5 Generazione dell applicazione DogDomoticIde Struttura della soluzione DataModel Structure Generazione del modello dati Generazione delle interfacce annotate Completamento delle classi implementazione Costruzione dei modelli per GMF Graphical Definition Model Tooling Definition Model Mapping Definition Model Generazione dell editor Implementazione Architettura logica di DogDomoticIde La gestione degli ambienti stanza L algoritmo RoomDetection Integrazione dell algoritmo RoomDetection nell applicazione DogDomoticIde La Summary View Aggiornamento della Summary View Aspetto e funzionalità della Summary View Modifica della Property View Il tab CommonProperties I tab Network e NetworkGateway I tab ControlRelation e RelationsSummary Esportazione del file di progetto Il formato xmldog Esempio di descrizione xmldog di un sistema domotico Casi di studio Caso 1: progetto di un appartamento Generazione del file di configurazione ed installazione su DOG Caso 2: ambiente composto da 2 appartamenti Caso 3: SimpleHome Tecniche a confronto: risultati sperimentali Conclusioni 98 Bibliografia 100 III

4 Elenco delle figure 2.1 Intelligent Domotic Environment La struttura di DogOnt Ontology Esempio di interconnessione tra una lampada ed uno switch DOG Architecture L architettura di base di Eclipse La gerarchia del modello ECore Il funzionamento di EMF Il workflow di GMF Struttura della soluzione Esempio di interfacce e di classi implementazione Esempio di mapping Componenti dell applicazione DogDomoticIde generata mediante GMF Il ruolo del DataModel Structure La classe ArchitecturalElement La classe BuildingArea Il DataModel Structure La classe DeviceElement La gestione della componente di rete Le classi NotificationElement, CommandElement e Param La classe HomeGateway Le classi ControlProperties e ControlElement Le classi ActuatorElement e SensorElement La classe VisualElement Workflow per la generazione del modello dati Le interfacce DeviceElement e Lamp Classe implementazione prima e dopo l esecuzione di FillImplementation Classe implementazione relativa allo stato OnOffState Costruzione dei modelli per GMF Descrizione grafica del dispositivo Computer Descrizione grafica del ControlLink IV

5 5.23 Rappresentazione grafica risultante Costruzione della palette degli oggetti Mapping dell elemento ArmChair Generazione dell editor Screenshot dell applicazione DogDomoticIde versione base, cioè ottenuta mediante generazione automatica Architettura logica di DogDomoticIde Esempio di struttura di due ambienti appartamento Muri connessi e non connessi Struttura dell algoritmo RoomDetection Caso di studio: appartamento dotato di un muro centrale La struttura dati intersectionlist La struttura dati intersectionmap Esempio di grafo di aree di intersezione Stanze individuate dall algoritmo RoomDetection Integrazione dell algoritmo RoomDetection in DogDomoticIde Aggiornamento della struttura dati builtroom La Summary View Struttura della Summary View Esempio di SummaryView Modifica della Property View Il tab CommonProperties Il tab Network/BTicinoComponent Il tab Network/KonnexComponent Il tab NetworkGateway Il tab ControlRelation Il tab RelationsSummary Esportazione del file di progetto Descrizione della struttura di un ambiente nel formato xmldog Descrizione di un dispositivo nel formato xmldog Caso di studio Caso di studio SimpleHome V

6 Capitolo 1 Introduzione 1.1 Scenario La domotica è la scienza interdisciplinare che si occupa dello studio di tecnologie e di soluzioni architetturali atte a migliorare la qualità della vita in un ambiente domestico. L obiettivo di un impianto domotico è quello di rendere più intelligente l ambiente nel quale è installato al fine di aumentarne la sicurezza, centralizzare il controllo dell abitazione, semplificare lo svolgimento delle più comuni operazioni anche ad individui che possiedano delle disabilità, e attuare politiche di risparmio energetico. Le funzionalità di una rete domotica possono essere suddivise in due categorie: 1. funzionalità di monitoraggio; 2. funzionalità di controllo centralizzato. Le funzionalità di monitoraggio sono quelle che forniscono all ambiente una maggiore affidabilità e sicurezza; tipicamente vengono realizzate mediante la presenza di sensori controllati dall impianto domotico. In questo caso l intelligenza della rete domotica risiede nella sua capacità di reagire opportunamente in base alle informazioni che arrivano dai sensori. Consideriamo, ad esempio, un sensore di fumo: nel momento in cui questo dispositivo rileva la presenza di un incendio, la rete domotica dovrà agire di conseguenza attivando gli sprinkler, sistema automatico di estinzione a pioggia, oppure effettuando una telefonata per contattare i soccorsi. Le funzionalità di controllo centralizzato hanno come obiettivo quello di aumentare il comfort facilitando le operazioni che normalmente si eseguono in un ambiente domestico. L utente, attraverso un opportuna interfaccia, interagisce con la rete domotica allo scopo di eseguire azioni (accendere la luce, chiudere tutte le tapparelle, ecc.) o di visionare alcuni parametri di stato dell abitazione. Queste 1

7 1 Introduzione funzionalità sono molto importanti per persone con disabilità in quanto permettono loro di avere maggiore autonomia e maggior controllo dell abitazione. Quando si parla di domotica molto spesso si utilizza il termine rete in quanto la struttura di un impianto domotico presenta molte analogie con quella di una tradizionale rete di computer. In particolare i dispositivi elettrici presenti nell abitazione sono dotati di un componente di rete che permette loro di essere connessi con l impianto domotico, di inviare notifiche riguardanti il loro stato e di ricevere comandi di controllo. Questa comunicazione viene realizzata attraverso l uso di protocolli ad hoc. Le più comuni tecnologie utilizzate nell ambito di una rete domotica filare, cioè basata sulla connessione dei dispositivi che la compongono mediante fili (bus), vengono fornite a livello Europeo dalla BTicino e dal consorzio Konnex. Recentemente stanno emergendo protocolli e standard wireless che permettono un interazione tra dispositivi senza la necessità di fili e/o connessioni elettriche (protocolli Z-Wave e ZigBee). Ogni dispositivo presente in una rete domotica viene catalogato in base al tipo di componente che gli permette di accedere alla rete. In particolare si definisce dispositivo BTicino un dispositivo con componente di rete di tipo BTicino (che utilizza i protocolli proprietari BTicino per la comunicazione su bus), analogamente un dispositivo di tipo Konnex è un dispositivo che utilizza lo standard Konnex per la comunicazione. In un tipico scenario domotico possono potenzialmente essere presenti dispositivi disomogenei per quanto riguarda la tecnologia di accesso alla rete. Tornando all analogia con i computer è come se nello stesso ufficio convivessero pc con scheda di rete Ethernet, altri con scheda di rete TokenRing e altri ancora con scheda di rete WiFi. Come non è possibile una comunicazione diretta tra un computer su rete Ethernet ed un computer su rete WiFi, così non è possibile una comunicazione diretta tra un dispositivo Konnex ed un dispositivo BTicino. In generale non è possibile instaurare una comunicazione diretta tra dispositivi che utilizzano diverse tecnologie per l accesso alla rete. Occorre inoltre tener presente che le differenze tra i vari impianti domotici non riguardano sono il livello di accesso alla rete ma interessano tutti i livelli della pila ISO-OSI. L introduzione di sistemi hardware e software aggiuntivi, nati con lo scopo di amministrare tutti gli altri dispositivi presenti nell ambiente, rappresenta quindi un innovazione importante rispetto a quello che è il tradizionale modello della smart home. Per smart home, infatti, si è sempre intesa un abitazione dotata di dispositivi sensori ed attuatori equipaggiati di hardware e software dedicati che permettono loro di autogestirsi e di realizzare politiche intelligenti semplici. Questo modello, nato nei tardi anni 90, risulta oggi sempre più limitante in relazione al continuo espandersi del mercato della domotica ed alle sempre più complesse funzionalità richieste. Inoltre è da evidenziare che le soluzioni domotiche cominciano a trovare applicazione anche in grandi strutture ed edifici, pensiamo ad ospedali o centri commerciali. In 2

8 1 Introduzione questi contesti è normale che i dispositivi non siano forniti tutti dallo stesso produttore con la conseguenza che, in alcuni casi, non è possibile un interazione diretta per via delle diverse tecnologie utilizzate. Da queste problematiche nasce la necessità di inserire, in un impianto domotico, un nodo centrale capace di fare da ponte per la comunicazione tra dispositivi disomogenei: il gateway domotico; in questa tesi, in particolare, tale gateway sarà DOG (Domotic OSGi Gateway) sviluppato al Politecnico di Torino dal gruppo e-lite. DOG permette di espandere il tradizionale modello domotico diventando il cervello dell impianto. I suoi obiettivi sono quelli di permettere: 1. la gestione dei dispositivi presenti nell ambiente assicurando la convivenza e l interazione anche tra quelli che accedono alla rete con protocolli diversi; 2. un espansione delle funzionalità realizzabili dalla rete domotica rispetto a quelle fornite dal modello tradizionale (semplice interazione sensore-attuatore). Il gateway rappresenta un valore aggiunto che si va a sommare al tradizionale modello domotico al fine di renderlo più funzionale. In genere si tratta di un comune personal computer connesso a tutte le reti di dispositivi presenti nell ambiente con lo scopo di monitorare il loro stato (ricevendo le loro notifiche) e di inviare comandi da eseguire. Per rendere chiaro questo concetto si consideri il caso di un interruttore BTicino e di una lampada Konnex. Si vuole realizzare la seguente interazione: quando l interruttore viene posizionato in posizione On la luce della lampada deve accendersi. Una possibile soluzione consiste nell inserire una regola di controllo all interno del gateway, da eseguire solo se si verificano certe condizioni. La ricezione di una notifica On dall interruttore determinerà la generazione e la trasmissione alla lampada di un comando per accendere la luce. Il gateway svolge quindi la funzione di traduttore: riceve una notifica BTicino, la interpreta e genera un comando Konnex per la lampada. Nel caso specifico di DOG il gateway è costruito utilizzando come base la piattaforma OSGi, un framework Java che permette al sistema di essere molto flessibile. OSGi supporta, infatti, l aggiunta ed il caricamento dinamico di moduli software, il riconoscimento e l hot-plug/-unplug di nuovi dispositivi tramite la Device Access Specification: specifica indipendente da qualunque particolare venditore che definisce come un dispositivo, non necessariamente fisico, si agganci alla piattaforma OSGi e come quest ultima provveda a rilevarlo in modo automatico. Uno degli aspetti che permettono al gateway di svolgere i suoi compiti è la conoscenza dell ambiente in cui viene installato: DOG deve essere informato su come è strutturato l ambiente (piani, stanze), da quali elementi architetturali è composto, quali sono i dispositivi presenti e come interagiscono tra di loro. 3

9 1 Introduzione Tali informazioni sono contenute nel bundle HouseModel, un modulo del gateway che risulta quindi essere specifico per ogni impianto domotico che si sta progettando. Nella soluzione proposta dal gruppo e-lite, il linguaggio utilizzato per descrivere i sistemi domotici è DogOnt, un metamodello basato sulla modellazione semantica e composto da due parti: un ontologia (DogOnt Ontology), espressa in OWL, il cui compito è formalizzare tutte le caratteristiche di un sistema domotico. DogOnt Ontology fornisce una libreria di classi ognuna delle quali descrive un elemento del sistema domotico; un insieme di regole (DogOnt Rules) che facilitano il processo di modellazione dell ambiente. La scelta di utilizzare DogOnt come formato di descrizione è dovuta al fatto che è una rappresentazione che permette al gateway DOG di attuare politiche intelligenti per l ambiente: l ontologia DogOnt si presta, infatti, ad essere interrogata da sistemi inferenziali che consentono l estrazione di informazioni avanzate necessarie al gateway per poter operare. Per rappresentare un ambiente il progettista dovrà utilizzare le classi fornite dall ontologia DogOnt per descrivere i vari elementi che lo compongono (dispositivi, arredamento, struttura dell abitazione, interazioni). Viene quindi creato un documento, istanza dell ontologia DogOnt, che deve essere installato sul gateway DOG all interno del modulo HouseModel. Se da un lato il formato OWL utilizzato da DogOnt incrementa le potenzialità del gateway, dall altro introduce delle problematiche di configurazione. Produrre un documento istanza di DogOnt è infatti molto complesso: il formato OWL richiede di organizzare le informazioni in una maniera poco intuitiva, utilizzando costrutti e ridondanze tediose. Il dover descrivere un ambiente domotico direttamente in formato OWL (attraverso l uso di software come Protégé) crea molte difficoltà al progettista: richiede di essere fortemente specializzati ed è dispendioso di tempo. Per alleggerire questa problematica è stato proposto, sempre dal gruppo e-lite, un tool in grado di generare automaticamente un file di ontologia sulla base di un documento di configurazione XML. Il formato XML proposto (xmldog) ha una struttura più semplice rispetto al formato OWL e permette al progettista di descrivere l ambiente inserendo solo quelle che sono le informazioni essenziali. Tuttavia questa soluzione non può essere considerata definitiva per il problema: anche se il formato proposto è più semplice ed intuitivo, il progettista resta comunque vincolato alla descrizione testuale dell ambiente ed alla conoscenza del formato XML utilizzato. 4

10 1 Introduzione 1.2 Obiettivi Il lavoro di tesi mira a risolvere queste problematiche andando a realizzare un ambiente di sviluppo integrato per la progettazione di sistemi domotici intelligenti, basati sulla modellazione semantica DogOnt e sul gateway domotico DOG. L applicazione sviluppata vuole coprire il tassello mancante che vi è tra il progettista ed il gateway DOG per quanto riguarda la descrizione dell impianto. Allo stato attuale, infatti, l unico modo per configurare DOG su uno specifico sistema domotico è quello di creare un istanza dell ontologia DogOnt utilizzando software come Protégé. Questa procedura risulta essere poco intuitiva e vincolante in quanto richiede piena conoscenza del formato interpretabile da DOG da parte del progettista. L ambiente di sviluppo ha come priorità quella di risolvere questa problematica fornendo gli strumenti necessari per descrivere un impianto domotico attraverso una semplice interfaccia grafica. Il progettista, attraverso l uso di questa applicazione, potrà: 1. definire la struttura ed i contenuti di un impianto di tipo domotico, a partire da librerie di componenti (passivi o attivi) che possono essere inseriti nell ambiente; 2. effettuare editing degli aspetti grafici (layout 2D) e dei meta-dati (elenchi di proprietà) relativi agli ambienti creati ed ai componenti inseriti; 3. descrivere in maniera semplice ed intuitiva le interazioni che intercorrono tra i dispositivi presenti nell ambiente; 4. esportare le informazioni derivanti dal progetto in un formato direttamente utilizzabile dal gateway DOG. Il sistema è realizzato sulla base della piattaforma Eclipse RCP e del plug-in GMF (Graphical Modeling Framework). Inoltre il modello dati di lavoro è costruito per essere accessibile ad eventuali, ulteriori, plug-in che in futuro potranno estendere l applicazione fornendo funzionalità aggiuntive. 1.3 Struttura della tesi Il presente documento è organizzato nei seguenti capitoli: Stato dell arte (cap. 2) - ha lo scopo di di approfondire il contesto in cui si sviluppa questa tesi; 5

11 1 Introduzione Obiettivi (cap. 3) - vengono evidenziati gli obiettivi del lavoro di tesi, espressi sotto forma di requisiti funzionali e non funzionali; Strumenti utilizzati (cap. 4) - vengono introdotti la piattaforma Eclipse ed i plug-in EMF, GEF e GMF; Generazione dell applicazione DogDomoticIde (cap. 5) - descrizione delle fasi che conducono alla generazione automatica dell applicazione di base mediante l ausilio dei plug-in EMF e GMF; Implementazione (cap. 6) - descrizione delle operazioni di integrazione ed estensione dell applicazione generata automaticamente al fine di supportare i requisiti funzionali primari dichiarati; Casi di studio (cap. 7) - progettazione di scenari domestici reali mediante l uso dell applicazione costruita; Conclusioni (cap. 8) - risultati ottenuti nel lavoro di tesi e possibili sviluppi futuri. 6

12 Capitolo 2 Stato dell arte Questo capitolo ha lo scopo di di approfondire il contesto in cui si sviluppa questa tesi. A tal fine viene ripreso il concetto di sistema domotico per poi passare alla presentazione del linguaggio di modellazione semantica DogOnt e del gateway domotico DOG. 2.1 Sistemi domotici I sistemi domotici vengono studiati e sono presenti sul mercato da molti anni. Nonostante questo, la loro applicazione nell ambito residenziale è recente ed è legata al continuo abbassamento del costo della tecnologia ed all emergere di nuovi bisogni per quanto riguarda il comfort, il risparmio energetico, la sicurezza e la multimedialità. Le attuali soluzioni domotiche presentano però 2 problematiche che ne frenano lo sviluppo: la presenza di molti produttori di componenti domotici, ognuno dei quali è specializzato solo in alcuni ambiti e ha ben precisi obiettivi di mercato; la struttura dei dispositivi domotici, che sono pensati e costruiti come un evoluzione dei dispositivi elettrici tradizionali (come switch e relay) e che permettono, quindi, solo semplici interazioni di automazione. In questo contesto ogni produttore propone solo alcuni dispositivi (in base alla propria politica di mercato) con soluzioni specifiche per la loro gestione. Questo genera problematiche di interoperabilità con i sistemi prodotti dagli altri vendor: non è infatti possibile fare interagire direttamente dispositivi costruiti da diversi produttori perchè, per la comunicazione, si basano su tecnologie e protocolli differenti. Nella prima fase di sviluppo della domotica, dove le installazioni erano poche ed isolate, il problema dell interoperabilità era secondario. Oggi invece queste tecnologie trovano applicazione anche in grandi strutture (hotel, università, ospedali, 7

13 2 Stato dell arte ecc.) dove è scontata la presenza di dispositivi costruiti con tecnologie diverse che necessitano di essere coordinati da un unico sistema centrale. L altro problema sopra citato è legato alla concezione dei componenti domotici come un evoluzione dei dispositivi elettrici. Questo approccio è riduttivo in quanto le funzionalità richieste ad un sistema domotico sono sempre più articolate, complesse e necessarie di una intelligenza superiore rispetto a quella garantita dalla semplice automazione. Come citato nel capitolo introduttivo, viene definita smart home un abitazione dotata di sensori ed attuatori, di hardware e software dedicati, allo scopo di realizzare semplici interazione di automazione. Questo approccio, rivoluzionario negli anni 90, risulta oggi limitante in quanto non consente l introduzione di nuove e più complesse funzionalità. Al fine di risolvere queste problematiche è necessario estendere il modello proposto dalla smart home inserendo, nel sistema domotico, un dispositivo (il gateway) in grado, grazie alle sue capacità computazionali, di supportare l interoperabilità e di attuare politiche intelligenti per la gestione dei dispositivi. Questo nuovo modello, che in letteratura viene chiamato Intelligent Domotic Environment (IDE), permette al sistema domotico di apprendere le abitudini degli abitanti dell abitazione, di attuare avanzate tecniche di sicurezza e di implementare politiche per il comfort e per il risparmio energetico. Un passo evolutivo molto importante riguarda la modellazione astratta e formale dei dispositivi domotici e delle loro capacità, indipendentemente dagli aspetti tecnologici. Ad esempio una lampada viene modellata come un oggetto in grado emettere luce, indipendentemente dalla tecnologia con cui è realizzata e con la condizione che sia in qualche modo controllabile dal sistema domotico. L astrazione dei dispositivi presenti in un ambiente permette al gateway di fare da ponte tra diverse tecnologie: per ogni dispositivo reale viene creata una descrizione astratta che ne esplica il funzionamento attraverso l uso di un linguaggio comune e condiviso. A tal fine è stato sviluppato dal gruppo e-lite il linguaggio DogOnt, un metamodello in formato OWL il cui scopo è permettere la descrizione di sistemi domotici. Attualmente DogOnt viene utilizzato per permettere la modellazione dell ambiente e per introdurre capacità di ragionamento all interno del gateway domotico DOG. Nel paragrafo successivo sarà approfondito il concetto di IDE per poi passare alla presentazione del linguaggio DogOnt e del gateway DOG Intelligent Domotic Environment Un ambiente domotico intelligente (IDE, Figura 2.1) è tipicamente composto da uno o più sistemi domotici, da un insieme di elettrodomestici e da un Home Gateway che permette di implementare politiche di interoperabilità e comportamenti intelligenti. 8

14 2 Stato dell arte Figura 2.1. Intelligent Domotic Environment Un sistema domotico contiene, tipicamente, diversi dispositivi domotici (attuatori per porte e finestre, luci, sensori, ecc.) ed un network gateway che, agendo da tunnel (inserendo quindi un intestazione di rete), permette la trasmissione dei messaggi specifici del protocollo di basso livello, utilizzato dai dispositivi appartenenti al sistema domotico per la comunicazione, su di una tecnologia di interconnessione maggiormente versatile ed indipendente dal tipo di applicazione (es. Ethernet). I network gateway rappresentano quindi un punto di accesso per i sistemi domotici, ma non sono programmabili e non introducono funzionalità aggiuntive all interno dell IDE. Gli elettrodomestici possono essere stupidi, ovvero che possono essere controllati solo attivando o disattivando le prese elettriche alle quali sono collegati, o smart, cioè capaci di offrire funzionalità complesse e di controllare altri dispositivi attraverso uno specifico protocollo di comunicazione. La presenza nello stesso ambiente di molti sistemi domotici introduce delle problematiche di interoperabilità: dispositivi appartenenti a sistemi diversi non possono interagire per via delle diverse tecnologie e dei diversi protocolli utilizzati per comunicare. L home gateway è progettato con lo scopo di risolvere questa problematica: agisce da ponte tra le diverse tecnologie e supporta complesse interazioni tra i dispositivi. I compiti che un home gateway deve essere in grado di svolgere possono essere raggruppati in 3 livelli di priorità: 9

15 2 Stato dell arte 1. livello 1 : include tutte le feature necessarie per controllare diversi sistemi domotici utilizzando un unico protocollo di comunicazione di alto livello e un singolo punto di accesso; 2. livello 2 : definisce le feature necessarie per permettere l automazione internetwork (interazione tra dispositivi appartenenti a sistemi domotici differenti); 3. livello 3 : riguarda gli aspetti di comportamento intelligente e di capacità di adattamento da parte dell utente. Una casa domotica si definisce Intelligent Domotic Environment se il gateway soddisfa i requisiti di livello 1 e di livello 2 (quelli di livello 3 sono considerati relativi a funzionalità avanzate ed opzionali). 2.2 Il linguaggio DogOnt DogOnt è un linguaggio descrittivo di sistemi IDE basato sulla modellazione semantica. Con l adozione di rappresentazioni ben note come le ontologie e fornendo strutture adeguate al ragionamento, DogOnt è in grado di affrontare problemi di interoperabilità consentendo di descrivere: dov è situato un dispositivo domotico; le capacità e le funzionalità di un dispositivo; le specifiche tecnologiche necessarie per interfacciarsi con un dispositivo; le possibili configurazioni che un dispositivo può assumere; come è strutturata l abitazione (piani, stanze, muri); gli elementi architetturali e di arredamento presenti nell ambiente. Queste informazioni possono poi essere sfruttate da sistemi basati sull inferenza per fornire le funzionalità avanzate richieste al sistema domotico. DogOnt è composto di due parti: un ontologia (DogOnt Ontology), espressa in OWL, il cui compito è formalizzare tutti gli aspetti di un IDE, e un insieme di regole (DogOnt Rules), che facilitano il processo di modellazione generando automaticamente gli stati e le funzionalità relativi ai dispositivi, e associandoli automaticamente alle opportune istanze attraverso regole sematiche. 10

16 2 Stato dell arte DogOnt Ontology Un ontologia è una rappresentazione formale di un interpretazione condivisa di uno specifico dominio di conoscenza. Non esistendo l ontologia perfetta, la rappresentazione di un determinato dominio può essere formalizzata in una moltitudine di modi e dipende dallo scopo per cui viene creata. Un ontologia assume normalmente una struttura a grafo connesso con concetti e relazioni che li collegano. Le componenti fondamentali di una ontologia sono: Classi - insiemi, collezioni o tipi di oggetti; Attributi - proprietà, caratteristiche o parametri che gli oggetti possono avere e condividere; Relazioni - modi in cui gli oggetti possono essere messi in relazione gli uni con gli altri; Individui - istanze del modello. È costituita da un insieme di classi organizzate in una struttura gerarchica a grafo dove i collegamenti tra un nodo e l altro rappresentano relazioni di ereditarietà (isa). Ad esempio, come si osserva nella Figura 2.2, la classe Garage (che descrive l ambiente garage) è una specializzazione della classe BuildingEnviroment: eredita cioè le proprietà di ogni tipologia di ambiente incrementandole con le proprie caratteristiche specifiche. Anche se non rappresentate nella figura, sono possibili situazioni di ereditarietà multipla. Tutte le classi che descrivono un dispositivo (Computer, Alarm- Clock, ecc.), ad esempio, derivano sia dalla classe Controllable (che definisce le funzionalità di base di ogni dispositivo) sia da una classe NetworkComponent (BticinoComponent o KonnexComponent) che fornisce le specifiche caratteristiche di rete. La descrizione di ogni dispositivo è quindi composta da due componenti: una parte astratta che descrive il comportamento del dispositivo ed una parte tecnologica necessaria per la comunicazione. Questo tipo di approccio favorisce l interoperabilità tra i dispositivi in quanto permette uniformità nel linguaggio utilizzato per la loro descrizione. L insieme delle classi definite da DogOnt può essere diviso in 8 gruppi: Building Thing: per modellare qualsiasi elemento controllabile e non controllabile. Si definisce elemento controllabile (o dispositivo) un elemento che può essere controllato dal sistema domotico (interrogato sul proprio stato o comandato). I dispositivi sono suddivisibili in due categorie: quelli appartenenti ad uno degli impianti domestici (la lampada, ad esempio, viene catalogata come appartenente all impianto elettrico) e gli elettrodomestici (frigorifero, forno, hifi, ecc.). Ogni dispositivo possiede diverse funzionalità (Functionality, rintracciate dalle relazioni hasfunctionality) e può assumere 11

17 2 Stato dell arte Figura 2.2. La struttura di DogOnt Ontology diverse configurazioni di stato (State, identificate mediante la relazione has- State). La quantità ed il tipo di stati e di funzionalità dipendono ovviamente dal dispositivo; in generale ogni elemento controllabile mette a disposizione almeno una QueryFunctionality che permette di fornire informazioni riguardanti la sua configurazione. Gli elementi non controllabili possono essere di tipo architetturale per la definizione dell ambiente (muri, pavimenti, ecc.) e di arredamento (mobili, scrivanie, tavoli, ecc.); Building Environment: per modellare la posizione di un elemento. Contiene una descrizione delle varie tipologie di ambiente: vengono definiti gli ambienti giardino (classe Garden), garage (classe Garage) e appartamento (classe Flat). Ogni piano può contenere una o più stanze (cucina, camera da letto, bagno, ecc.); Functionality: per modellare le operazioni che si possono effettuare su un dispositivo. Tutte le funzionalità definiscono i comandi necessari per modificare o per interrogare una specifica proprietà del dispositivo. Sono suddivise in 12

18 2 Stato dell arte diverse categorie in relazione al loro scopo: le ControlFunctionality modellano la capacità di controllare un dispositivo. Le NotificationFunctionality riguardano l abilità di un dispositivo di segnalare un proprio cambiamento di stato. Le QueryFunctionality permettono di interrogare un dispositivo che fornirà, quindi, informazioni sulla propria configurazione attuale. Infine le funzionalità vengono organizzate anche in base a come modificano lo stato di un particolare dispositivo: le ContinuosFunctionality permettono la modifica delle caratteristiche di un dispositivo in maniera continua (ad esempio il volume di un impianto audio) e le DiscreteFunctionality sono utilizzate per quelle proprietà che possono assumere solo valori discreti. Le relazioni hasnotification e hascommand contengono rispettivamente i riferimenti alle notifiche ed ai comandi che realizzano concretamente le funzionalità svolte dalle NotificationFunctionality e ControlFunctionality; State: per modellare le configurazioni che un dispositivo può assumere. Come per le funzionalità, anche gli stati vengono classificati in base ai valori che possono assumere: i ContinuosState, che riguardano quelle proprietà che possono assumere valori continui, ed i DiscreteState, associati alle proprietà che assumono solo valori discreti; NetworkComponent: per modellare le caratteristiche tecniche specifiche di ogni rete domotica. Attualmente i NetworkComponent definibili sono tre: KNX- Component utilizzato per dispositivi Konnex, BTicinoComponent dedicato ai dispositivi BTicino ed infine EliteComponent attribuito a tutti i dispositivi non reali (che non hanno componente di rete dichiarato); Notification: per modellare tutte le notifiche che i dispositivi possono generare in seguito ad una variazione di stato; Command: per modellare tutti i comandi per controllare ed interrogare i dispositivi; StateValue: per modellare la tipologia di valori che gli stati dei dispositivi possono assumere: le classi ContinuosStateValue e DiscreteStateValue descrivono rispettivamente i valori continui e discreti che gli stati possono assumere. Gli stati ContinuosState e DiscreteState sono associati alle classi ContinuosStateValue e DiscreteStateValue (relazione hasstatevalue). Si consideri, come esempio riassuntivo, la rappresentazione di una lampada ad intensità luminosa regolabile. Questo dispositivo, nel formato OWL utilizzato da DogOnt, è descritto dalla classe DimmerLamp che a sua volta deriva, nell ordine indicato, dalle classi Lamp, Lighting, HousePlant e Controllable. La presenza di questa scala gerarchica permette al dispositivo DimmerLamp di ereditare le 13

19 2 Stato dell arte Figura 2.3. Esempio di interconnessione tra una lampada ed uno switch funzionalità definite nelle super classi: dalle classi Lamp, Controllable e House- Plant vengono ereditate rispettivamente le funzionalità OnOffFunctionality (che a sua volta definisce i comandi On e Off per accendere e spegnere la lampada), QueryFunctionality (per permettere l interrogazione dello stato della lampada) e StateChangeNotificationFunctionality (notifica che segnala un cambiamento di stato della lampada). La classe DimmerLamp è inoltre caratterizzata dalla funzionalità LightRegulationFunctionality e dallo stato LightIntensityState: LightRegulationFunctionality definisce i comandi StepUpCommand, StepDown- Command e SetCommand(value) per governare l incremento ed il decremento dell intensità luminosita, LightIntensityState tiene traccia, in percentuale, del valore dell intensità luminosa. La Figura 2.3 mostra, come esempio, la descrizione OWL schematica di un dispositivo lampada (istanza della classe DimmerLamp) controllata da uno switch (OnOffSwitch). Il funzionamento, la configurazione attuale e le proprietà della lampada sono descritte dalle relazioni: 14

20 2 Stato dell arte hasstate: relazione che contiene il riferimento ad un istanza della classe Ligh- IntensityState che, tramite il valore LightIntensityStateValue, tiene traccia del valore corrente dell intensità luminosa (nell esempio 77%); isin: relazione che descrive la posizione dell oggetto nell ambiente. Nell esempio la lampada è inserita in una LivingRoom; hasfunctionality: relazione che contiene il riferimento ad un istanza di una classe funzionalità. Ogni lampada di tipo DimmerLamp è caratterizzata dal possedere tre relazioni hasfunctionality che rispettivamente contengono un riferimento ad una istanza della classe: StateChangeNotificationFunctionality: definisce la notifica per segnalare un cambiamento di stato; OnOffFunctionality: definisce i comandi per accendere e spegnere la lampada; LightRegulationFunctionality: definisce i comandi per regolare l intensità luminosa della lampada. Il controllo che il dispositivo OnOffSwitch esercita sulla lampada è descritto dalle relazioni controlledobject e generatescommand: la prima contiene il riferimento all oggetto controllato (in questo caso la lampada), la seconda viene inserita all interno delle istanze delle notifiche OnNotification e OffNotification. Nell esempio si vuole realizzare la seguente interazione: quando lo switch è in posizione Off la lampada deve essere spenta, quando è in posizione On la lampada deve essere accesa. A tal fine nelle notifiche OnNotification e OffNotification dello switch vengono inserite le relazioni generatescommand riferite rispettivamente ai comandi OnCommand e OffCommand della lampada. In questo modo quando si imposta lo switch in posizione Off automaticamente viene generato il comando OffCommand che spegne la lampada. Analogamente quando si imposta lo switch in posizione On viene generato il comando OnCommand che accende la lampada. 2.3 Il gateway DOG DOG (Domotic OSGi Gateway) è una piattaforma che permette l interfacciamento, la gestione e l integrazione di dispositivi domotici prodotti da diversi costruttori. Nell architettura OSGi i protocolli e gli altri moduli aggiuntivi, come ad esempio le politiche di comportamento intelligente, vengono demandati a terze parti: i bundle, che possono essere dinamicamente caricati nel framework OSGi a run-time. Il grande vantaggio che ne deriva è l elevata flessibilità del sistema: un bundle può 15

21 2 Stato dell arte essere infatti aggiunto all architettura in modo da estenderne le sue capacità, può essere successivamente aggiornato, modificato o rimosso senza dover riavviare l intero framework Architettura Come illustrato nella Figura 2.4, l architettura modulare del gateway DOG è composta da un insieme di bundle organizzati in 4 livelli funzionali: Device Management, DeviceControl, API e DogLibrary. Figura 2.4. DOG Architecture 1. Device Management contiene i bundle che realizzano la Device Access Specification, specifica che definisce la logica e le entità (bundle) che devono essere realizzate per implementare il supporto all auto-detection dei dispositivi presenti nell ambiente e per permettere l hot-plug/unplug di nuovi dispositivi. È costituito da: DogDeviceManager: rileva la registrazione di servizi Device e associa questi dispositivi all opportuno Driver service; DogDevice: è l oggetto Dog che rappresenta la classe dispositivi definita in DogOnt. Si tratta del software proxy del dispositivo reale il cui compito è interfacciare il dispositivo con l opportuno Driver service; 16

22 2 Stato dell arte Driver: contiene i bundle (Driver service) necessari per interfacciarsi con i vari tipi di rete domotica. Ogni tecnologia di rete viene gestita da uno specifico driver che consente l accesso agli aspetti specifici del protocollo attraverso un interfaccia di alto livello comune per tutte le tecnologie. Questo permette uniformità nella rappresentazione dei diversi dispositivi. Attualmente è composto da 3 bundle: Konnex Network Driver, per i sistemi KNX; BTicino Network Driver, per i sistemi MyHome BTicino; Emulator Network Driver che permette di emulare i dispositivi fisicamente non disponibili, consentendo così di utilizzare il software anche in assenza di un ambiente domotico reale, cioè in simulazione. HouseModel: bundle che contiene l istanza dell ontologia DogOnt che descrive la struttura, le proprietà e le capacità dello specifico ambiente IDE nel quale il gateway è installato. Questo modulo sfrutta le informazioni derivanti dalle classi e dalle istanze di DogOnt per implementare funzionalità di ragionamento e politiche intelligenti per l ambiente. In particolare HouseModel permette la generazione delle regole necessarie per realizzare l interoperabilità tra i dispositivi presenti: (a) vengono individuate le relazioni controlledobject e generatescommand all interno dell ontologia DogOnt; (b) le relazioni trovate vengono convertite in regole nel formato MVEL; (c) tali regole sono direttamente eseguibili dal bundle DogRules. Durante la fase di startup del gateway, il modulo DogRules interroga il modulo HouseModel al fine di ottenere le regole di interoperabilità che deve eseguire. In risposta a questa richiesta il modulo HouseModel analizza il modello DogOnt per individuare le associazioni presenti tra i dispositivi: per ogni coppia notifica-comando viene creata una regola di interoperabilità. Le regole prodotte vengono infine comunicate al bundle DogRules. 2. Device Control include i bundle dedicati a controllare ed a monitorare i dispositivi. È costituito da: DogStateMonitor: fornisce le informazioni riguardanti lo stato corrente dei dispositivi connessi a Dog; DogExecutor: permette l esecuzione di comandi, ricevuti da altri bundle, sui dispositivi attraverso la chiamata dei metodi presenti negli oggeti DogDevice. Grazie al modulo HouseModel, DogExecutor verifica la correttezza sintattica e semantica dei comandi ricevuti; 17

23 2 Stato dell arte DogScheduler: offre un servizio centralizzato per schedulare l esecuzione dei comandi e le operazioni di monitoraggio dei dispositivi. Sfrutta i moduli DogExecutor e DogStateMonitor; DogRuleEngine: fornisce un ambiente di esecuzione per le regole di interoperabilità (JBoss Rules) definite dall utente. Questo modulo riceve gli eventi generati dall ambiente e verifica se ci sono delle regole da eseguire. 3. API include bundle che definiscono le interfacce di programmazione (indipendenti dalla tecnologia) per permettere l accesso ai servizi forniti da Dog ad applicazioni esterne e plug-in OSGi: DogApi: permette ad applicazioni basate sulla piattaforma OSGi di ottenere informazioni sulla configurazione dell ambiente, di riceve eventi provenienti dall ambiente e di inviare comandi ai dispositivi gestiti da DOG; DogXmlEndPoint: fornisce un endpoint XML-RPC per i servizi offerti dal modulo DogApi, questo permette l accesso a DOG da parte di applicazioni non costruite sulla base di OSGi o di Java. 4. DogLibrary definisce le interfacce che permettono l interazione tra i vari moduli che compongono il gateway. L interazione tra diversi bundle è basata sullo scambio di oggetti DogMessage ognuno dei quali è composto dai campi typedeclaration, che identifica il tipo di messaggio, e payload che contiene il corpo del messaggio. 2.4 Punti critici e aree di possibile miglioramento I punti critici dei sistemi domotici basati sull architettura DogOnt+Dog sono essenzialmente 2: difficoltà nella creazione del modello di un singolo appartamento/edificio; capacità computazionali richieste da DOG. Il primo punto riguarda il fatto che il funzionamento del gateway DOG si basa sul modello dell ambiente contenuto nel bundle HouseModel ed espresso nel formato OWL. Produrre un documento istanza dell ontologia DogOnt è molto complesso: il formato OWL richiede di organizzare le informazioni in una maniera poco intuitiva, utilizzando costrutti e ridondanze tediose. Il progettista che configura questi impianti domotici si trova nella situazione di dover creare un file di configurazione direttamente nel formato OWL (attraverso l uso di software come Protégé) e questo crea molte difficoltà: la complessità del processo richiede un alta specializzazione 18

24 2 Stato dell arte che esula dalle capacità dell installatore medio. Per ridurre questo problema occorre produrre degli strumenti il cui compito è facilitare la produzione di un modello OWL. Il lavoro di questa tesi si pone l obiettivo di fornire al progettista un applicazione che, attraverso un interfaccia grafica semplice, consente di sviluppare il modello di un sistema domotico senza avere conoscenza approfondita del formato OWL. Il secondo punto è relativo alle difficoltà nell elaborare informazioni complesse e nell applicare sistemi inferenziali in tempo reale su sistemi con capacità computazionali ridotte. In questo caso il modulo HouseModel viene sostituito dal modulo SimpleHouseModel che contiene una rappresentazione statica e semplificata dell ambiente (ottenuta mediante il processamento del modello di ontologia durante la fase di configurazione del gateway). Tutti i processi inferenziali vengono eseguiti off-line: DOG, durante la sua esecuzione, svolge i suoi compiti sfruttando le informazioni statiche prodotte in fase di configurazione. 19

25 Capitolo 3 Obiettivi 3.1 Scopo della tesi L utilizzo del gateway DOG in un ambiente domotico rappresenta una soluzione per permettere l interoperabilità tra dispositivi domotici diversi e l aggiunta di funzionalità avanzate. Se da un lato DOG incrementa le capacità del sistema domotico (trasformandolo in un IDE, Intelligent Domotic Environment), dall altro introduce delle problematiche di configurazione non banali. Per il suo funzionamento, infatti, DOG si appoggia al modello DogOnt che descrive l ambiente. L istanza dell ontologia, quindi, è specifica del contesto: per ogni impianto domotico in cui viene installato DOG occorre creare il file di ontologia che lo descrive. La scelta di utilizzare DogOnt come formato di descrizione è dovuta al fatto che è una rappresentazione che permette al gateway DOG di attuare politiche intelligenti per l ambiente: esistono sistemi inferenziali che, interrogando l ontologia, consentono l estrazione di informazioni avanzate necessarie al gateway per poter operare. Il problema di questa rappresentazione è che produrre un documento istanza di DogOnt è molto complesso: il formato OWL richiede infatti di organizzare le informazioni in una maniera poco intuitiva, utilizzando costrutti e ridondanze tediose. Il dover descrivere un ambiente domotico direttamente in formato OWL (attraverso l uso di software come Protégé) crea molte difficoltà al progettista: richiede di essere fortemente specializzati ed è dispendioso di tempo. Questo approccio frena quindi lo sviluppo e l installazione di ambienti domotici basati su DOG in quanto è molto difficile produrre un file di configurazione corretto ed è comunque pensabile solo per la descrizione di sistemi semplici, dove gli elementi e le interazioni presenti siano pochi. Per alleggerire questa problematica è stato proposto, sempre dal gruppo e-lite, un tool in grado di generare automaticamente un file di ontologia partendo da un 20

26 3 Obiettivi documento di configurazione XML. Il formato XML proposto (xmldog) ha una struttura più semplice rispetto al formato OWL e permette al progettista di descrivere l ambiente inserendo solo le informazioni essenziali. È compito del tool ricevere il file XML come input, validarlo, analizzarlo per estrarre le informazioni ed infine produrre le relative istanze di DogOnt. Il tool si prende quindi carico di introdurre tutte le restanti parti necessarie che, da un punto di vista umano, risultano essere complicate, ridondanti e tediose. Quest idea rappresenta di certo un passo avanti ma non può essere considerata come la soluzione definitiva per il problema: anche se il formato proposto è più semplice ed intuitivo, il progettista resta comunque vincolato alla descrizione testuale dell ambiente ed alla conoscenza del formato XML utilizzato. Il lavoro di tesi mira a risolvere queste problematiche andando a realizzare un ambiente di sviluppo integrato per la progettazione di sistemi domotici intelligenti basati sulla modellazione semantica DogOnt e sul gateway DOG: l applicazione DogDomoticIde. Il progettista di sistemi domotici, attraverso l uso di questo programma, ha la possibilità di descrivere un ambiente domotico utilizzando una semplice interfaccia grafica. Nel seguito verranno organizzati e trattati nel dettaglio i requisiti definiti per questa applicazione. 3.2 Requisiti I requisiti alla base della progettazione dell applicazione DogDomoticIde possono essere suddivisi in 2 categorie: requisiti funzionali: dall IDE; sono le funzionalità che devono essere rese disponibili requisiti non funzionali: caratteristiche strutturali e/o di implementazione richieste all applicazione che non hanno impatto diretto sull utilizzatore e sull output prodotto Requisiti funzionali I requisiti funzionali vengono catalogati in relazione alla loro priorità. Il lavoro di tesi ha come obiettivo l implementazione di tutti i requisiti funzionali primari. Le altre categorie (requisiti funzionali secondari e sviluppi futuri) sono considerati, per il momento, opzionali e di secondo piano. 21

27 3 Obiettivi Requisiti funzionali primari 1. presenza di un interfaccia grafica di base in grado di fornire le tradizionali operazioni effettuabili in un IDE (drag & drop, copia/incolla, undo e redo, zoom, salvataggio su file); 2. descrizione della struttura e dei contenuti di un impianto di tipo domotico, a partire da librerie di componenti (passivi o attivi) che possono essere inseriti nell ambiente; 3. editing degli aspetti grafici (layout 2D) e dei meta-dati (elenchi di proprietà) relativi agli ambienti creati ed ai componenti inseriti; 4. layout dell applicazione costituito da almeno: Design View: vista nella quale l utilizzatore progetta l impianto domotico inserendo, cancellando e modificando i vari elementi; Palette View: vista che contiene la libreria degli elementi inseribili nell impianto domotico, organizzati in relazione alla loro natura; Property View: vista che permette di modificare le proprietà dell elemento selezionato; 5. descrizione delle interazioni che intercorrono tra i dispositivi presenti nell ambiente; 6. esportazione delle informazioni derivanti dal progetto in un formato utilizzabile direttamente dal gateway DOG. Requisiti funzionali secondari 1. inserimento nel layout dell applicazione di una Summary View, vista ad albero che contiene un riepilogo degli oggetti inseriti nell impianto; 2. esportazione delle informazioni derivanti dal progetto direttamente nel formato OWL; 3. costruzione di nuovi elementi a run-time (riferiti alle classi già esistenti in DogOnt) consentendo il loro inserimento nella libreria personale dell utilizzatore; 4. inserire controlli di validazione sugli oggetti inseriti nell impianto domotico: un oggetto è considerato valido se tutte le sue proprietà sono compilate ed assumono un valore sintatticamente corretto; 22