Transcript Implementazione di un modulo per il monitoraggio della potenza

 Università degli studi di Pavia
Corso di laurea in Ingegneria Elettronica e Informatica “Implementazione di un modulo per il monitoraggio della potenza virtuale” Relatore: Chiar.mo prof. Tullio Facchinetti Tesi di laurea di: Leonardo Migliorini Anno Accademico 2013/2014 Indice Introduzione 2 1. Il fotovoltaico e il risparmio energetico 3 1.1
1.2
1.3
1.4
1.5
1.6
1.7
Tecnologia fotovoltaica . . . . . . . . . . . . . . . 3 La cella fotovoltaica . . . . . . . . . . . . . . . . . 4 Caratteristche di un impianto fotovoltaico . . . . . . 5 L’autoconsumo . . . . . . . . . . . . . . . . . . . 6 I contatori intelligenti (Smart Meter) . . . . . . . . . 7 Smart Grid . . . . . . . . . . . . . . . . . . . . . . 9 Gestione dei carichi elettrici . . . . . . . . . . . . . 10 2. Il framework OSGi 12 2.1 Genesi e architettura . . . . . . . . . . . . . . . . 12 2.2 Il bundle . . . . . . . . . . . . . . . . . . . . . . 13 2.3 Il ciclo-­‐vita di un bundle . . . . . . . . . . . . . . . 13 2.4 Bundle e servizi . . . . . . . . . . . . . . . . . . . 14 2.5 Il file manifest.mf . . . . . . . . . . . . . . . . . . 15 2.6 Concettii fondamentali e peculiarità . . . . . . . . . 17 3. Il Dog e Z-­Wave 20 3.1 The Dog Gateway . . . . . . . . . . . . . . . . . . 20 3.2 DogOnt . . . . . . . . . . . . . . . . . . . . . . . 21 3.3 Architettura . . . . . . . . . . . . . . . . . . . . . 23 3.4 Il protocollo di comunicazione Z-­‐Wave . . . . . . . . 25 3.5 Dog e Z-­‐Wave . . . . . . . . . . . . . . . . . . . . 26 4. Virtual Power Meter 4.1
4.2
4.3
4.4
28 Premessa e scopo . . . . . . . . . . . . . . . . . . 28 Implementazione . . . . . . . . . . . . . . . . . . 29 Applicazioni future . . . . . . . . . . . . . . . . . 32 Conclusioni . . . . . . . . . . . . . . . . . . . . . 33 1 Introduzione La potenza virtuale è definita dalla differenza tra potenza consumata (positiva) e potenza prodotta (negativa). Essa può essere un importante indicatore per capire se, in un dato istante, è maggiore la quantità di energia che viene consumata rispetto a quella che viene prodotta o viceversa, quindi se si sta comprando energia elettrica o se si sta utilizzando quella che si sta producendo. Al giorno d’oggi, il modo più diffuso per produrre energia da consumare in loco (in questo caso si parla di autoconsumo), è rappresentato dal fotovoltaico. Nel corso dell’elaborato verrà introdotto il funzionamento degli impianti e delle celle fotovoltaiche, passando per la definizione di potenza nominale di un impianto, le sue caratteristiche, il rendimento e i vantaggi legati a esso. Successivamente verranno presentati i contatori intelligenti (smart meters), come questi possano avvantaggiare il cliente nell’utilizzo, le loro caratteristiche e applicazioni. Verrà introdotto il concetto di smart grid, cioè una rete intelligente in cui tutti i nodi della rete (da piccole abitazioni a grandi industrie) collaborano tra di loro giocando il ruolo di prosumer, ovvero sia consumatore che produttore. Infine sarà trattato il problema della gestione dei carichi elettrici nei diversi ambiti. Per quanto riguarda la gestione e la manipolazione dei dati da controllare, ovvero la potenza elettrica che giunge dai pannelli fotovoltaici e dagli elettrodomestici/macchinari di una abitazione/impresa, verrà utilizzato un particolare software nato appositamente per scopi domotici, denominato Dog. Esso si appoggia al framework OSGi, che sarà descritto dettagliatamente dall’architettura ai concetti fondamentali che lo caratterizzano, passando per la definizione del modulo principale di programmazione OSGi, il bundle, il suo ciclo vita nel framework, la sua interazione con i servizi (altri modui di programmazione) e il file che lo caratterizza ovvero il manifest. Successivamente sarà descritto Dog, la sua architettura, l’ontologia e il protocollo di comunicazione Z-­‐Wave, che rappresenta una delle possibili modalità di comunicazione tra i dispositivi domotici e il sistema centrale (gateway). Dopo aver descritto gli strumenti utilizzati, viene riportata la fase di implementazione: verrà realizzato un bundle Dog, il VirtualPowerMeter, il cui compito sarà, all’interno di un ambiente domotico, rilevare e visualizzare, con opportuni algoritmi, la potenza virtuale dell’ambiente istante per istante. Il bundle sarà testato prima tramite gli strumenti di test e debug forniti da Eclipse e successivamente sarà insallato sul gateway e testato sul sistema reale. Infine verranno riportate le criticità individuate nel modulo implementato e gli sviluppi futuri a partire da esso. 2 Capitolo 1: Il fotovoltaico e il risparmio energetico 1.1 Tecnologia fotovoltaica Un impianto fotovoltaico è essenzialmente un generatore di energia elettrica. Per il suo funzionamento non ha bisogno di combustibile né di parti in movimento perché trasforma direttamente l’energia contenuta nella radiazione solare in energia elettrica. E’ essenzialmente composto da: • Moduli fotovoltaici (Panelli): la potenza specificata dal modulo fotovoltaico è pari a 100-­‐400 Watt. Il modulo occupa una superficie non superiore ai due metri quadrati e presenta un peso di circa 20 kg. Il carico specifico medio è pari perciò a circa 10 kg/m2. • Gruppo di Conversione (Inverter): dispositivo elettronico che permette di ottenere la conversione da corrente continua, prodotta dall’impianto, in alternata, per essere adeguata alle caratteristiche della rete elettrica nazionale. • Quadri elettrici e cavi di collegamento. Figura 1.1 Schema semplificato di funzionamento di un impianto fotovoltaico.1 I moduli contengono al loro interno le celle fotovoltaiche, che rappresentano la parte attiva del sistema e a cui è dedicata la sezione 1.2 del capitolo. 1 Fonte dell’immagine: http://www.arredareecostruire.com 3 Opportunamente collegate tra di loro, le celle forniscono al Modulo una potenza elettrica che è la somma della potenza di ogni singola cella. Collegamenti in serie/parallelo di più Moduli conferiscono all’impianto le caratteristiche di potenza richieste dal progetto (potenza nominale del campo fotovoltaico.) Prima che l’energia prodotta dall’impianto possa essere immessa nella rete elettrica deve subire un adattamento per quanto riguarda la tensione (230/400 Volt), la frequenza (50 Hz) e la fase. Questo compito è svolto dal Gruppo di Conversione all’uscita del quale è possibile prelevare l’energia nella forma utilizzabile dalle comuni apparecchiature elettriche (elettrodomestici, motori, ecc…). Ogni impianto fotovoltaico ha una Potenza Nominale (o di picco) espressa in KWp (KiloWatt di picco) che rappresenta la potenza elettrica che l’impianto è in grado di produrre nelle seguenti condizioni assunte come standard (STC): • Radiazione solare incidente: 1000 Watt/m^2 • Temperatura: 25 °C 1.2 La cella fotovoltaica L’elemento fondamentale dell’impianto fotovoltaico è la cella fotovoltaica, realizzata in silicio e capace di trasformare l’energia solare incidente su di essa direttamente in energia elettrica. Il principio fisico che viene sfruttato dalla cella è l’effetto fotoelettrico: un flusso luminoso che investe il reticolo cristallino di un semiconduttore (in questo caso il silicio), genera un flusso di elettroni, ovvero corrente elettrica. Figura 1.2: Principio di funzionamento della cella fotovoltaica.2 La cella può essere di tre tipi diversi, in base alla tipologia del materiale costituente lo strato che costituisce la cella stessa: 1) Celle monocristalline: questo tipo di celle viene prodotto tagliando una barra monocristallina; esse sono tipicamente caratterizzate da un’omogenea colorazione blu. Le celle monocristalline permettono di raggiungere rendimenti molto alti (13÷18%); di contro però presentano costi elevati a causa del complicato processo di produzione. 2 Fonte dell’immagine: http://www.funsci.com 4 2) Celle policristalline: queste celle vengono prodotte realizzando colate in blocchi che poi vengono tagliate a dischetti; esse presentano un disegno ben distinguibile, a causa dei vari cristalli contenutivi. Le celle policristalline hanno rendimenti intermedi (10÷12%), con un prezzo che però è inferiore rispetto a quello delle celle monocristalline. 3) Celle amorfe: questo tipo di celle viene prodotto attraverso spruzzamento catodico di atomi di silicio su una piastra di vetro; esse presentano un caratteristico colore scuro e sono realizzabili in qualsiasi forma geometrica. Le celle amorfe hanno il rendimento più basso (6÷10%), ma presentano bassi costi e si adattano anche al caso di irradiamento diffuso (cielo coperto, ecc.). 1.3 Caratteristiche di un impianto fotovoltaico La produzione di energia elettrica per effetto fotovoltaico è completamente scevra da ogni tipo di emissione (inquinante o meno) e non consuma alcun tipo di combustibile. Un impianto è facilmente espandibile (aumento della potenza nominale) data la sua natura fortemente modulare. L’assenza di parti in movimento inoltre riduce quasi completamente costi e problemi di manutenzione, aumenta notevolmente l’affidabilità dell’intero sistema e non produce inquinamento acustico. La forma dei moduli, le loro caratteristiche geometriche e fisiche, le strutture di supporto esistenti sul mercato rendono possibile l’installazione di un impianto fotovoltaico praticamente ovunque. Le considerazioni da fare per la scelta del sito migliore riguardano le disponibilità di spazio (possibilmente non altrimenti utilizzabile), l’assenza di ombreggiamenti e la corretta esposizione della superficie captante dei moduli (verso SUD con inclinazione di circa 30°). La superficie necessaria per installare la potenza nominale di 1 kWp varia secondo il tipo di modulo da utilizzare e secondo la tipologia del sito di installazione. Per impianti installati direttamente su superfici inclinate si stimano le seguenti occupazioni: Silicio mono/poli-­‐crisallino ≈ 8 m2 Silicio amorfo ≈ 17 m2 Installazioni realizzate a terra, o su superfici piane, necessitano di strutture di supporto per i moduli in modo da conferire a questi l’inclinazione ottimale; in questi casi si deve prevedere una distanza minima tra le schiere di moduli per evitare l’ombreggiamento reciproco. La produzione di energia elettrica derivante da ogni kWp di potenza nominale installata dipende dalla quantità di radiazione solare che raggiunge i moduli nell’arco dell’anno. Valori puramente indicativi stimano, per ogni kWp installato, da circa 1.000 kWh/anno per le regioni settentrionali e circa 1.600 kWh/anno per quelle meridionali. I moduli fotovoltaici certificati per l’utilizzo in “Conto Energia” hanno una garanzia del produttore per un rendimento non inferiore all’80% dopo 20 anni (durata dell’incentivazione prevista dal “Conto Energia”). Impianti che utilizzano questo tipo di moduli hanno vita media stimata di circa 40 – 50 anni. •
•
5 1.4 L’autoconsumo L’autoconsumo è una caratteristica fisiologica dell’impianto fotovoltaico. Chi possiede un impianto e consuma energia elettrica nelle ore di produzione dell’impianto stesso, “autoconsuma” l’energia prodotta. L’obiettivo, sempre più auspicabile dopo la fine della tariffa incentivante, è massimizzare la quota di autoconsumo per migliorare sensibilmente la rendita dell’impianto. L’autoconsumo di energia solare è più conveniente rispetto alla tradizionale immissione in rete poiché il prezzo di acquisto dell’energia dalla rete è maggiore del prezzo di vendita. I fattori che influenzano l’autoconsumo sono: • Il proprio fabbisogno energetico • La produzione di energia dell’impianto fotovoltaico • Il profilo di consumo, ovvero la ripartizione temporale del fabbisogno energetico Si parla di autoconsumo di energia solare quando la corrente così prodotta viene utilizzata direttamente nel luogo di produzione. L’autoconsumo del giorno corrisponde esattamente alla parte di energia consumata (profilo blu) che si trova “all’interno” dell’energia FV prodotta (profilo grigio), come mostrato dalla figura 1.3. Figura 1.3: Rappresentazione grafica della produzione e del consumo di energia giornaliero. 3 La stima della quota di autoconsumo standard (senza specifici provvedimenti) è attività complessa poiché vanno considerati molteplici fattori. In media si considera la quota di autoconsumo di un impianto residenziale a servizio di un’utenza privata, con famiglia di 4 persone, pari circa al 30 %. Molto più alto invece è il range per gli impianti commerciali, dove il fabbisogno energetico e il profilo di consumo sono altamente variabili. Considerata la percentuale media di autoconsumo, si pone la questione della parte di energia per cui produzione e consumo non coincidono. Tale quota dipende dalle condizioni metereologiche e stagionali e dalla disponibilità giornaliera dell’energia solare. Come aumentare l’autoconsumo? Per quanto riguarda gli impianti residenziali è possibile aumentare la quota di autoconsumo modificando il profilo di consumo stesso: attivare i 3 fonte dell’immagine: http://www.ibc-­‐solar.it , IBC SOLAR Srl 6 maggiori utilizzatori elettrici negli orari di elevato irraggiamento può far aumentare la quota di autoconsumo di 10 punti percentuali (il problema della gestione dei carichi elettrici, o “electric load management” è rimandato alla sezione 1.6); ciò è tuttora più semplice con la diffusione sempre più radicata degli Smart Meter, cioè contatori intelligenti, che permettono di valutare istantaneamente l’energia consumata. All’utilizzo degli Smart Meter è dedicata la sezione 1.4 del capitolo. Esistono anche soluzioni tecniche che permettono di incrementare l’autoconsumo chiamate “Home Management System”: questi sistemi monitorano il consumo energetico dei carichi e la produzione istantanea dell’impianto; grazie all’analisi dei dati in input, attivano i carichi della casa nel momento migliore ottimizando l’autoconsumo (anche questi metodi prevedono l’utilizzo di smart meters). Anche per le utenze commerciali è possibile ottimizzare il profilo di consumo al fine di aumentare la quota di autoconsumo ma spesso è molto complicato. Il fattore d’influenza più importante è il rapporto tra quantità di energia prodotta e necessaria, poiché limita la quota di autoconsumo conseguibile: se il fabbisogno energetico è sufficientemente elevato, è possibile utilizzare direttamente quote rilevanti dell’energia solare prodotta, anche quando i momenti di consumo e produzione non coincidono perfettamente. Se invece l’energia solare è superiore, per via di una produzione particolarmente elevata, solo una piccola parte di questa potrà essere direttamente utilizzata. Al secondo posto, vi è il rispettivo profilo di consumo, che determina in via quasi esclusiva in che modo coincidono produzione e consumo durante la giornata. Influisce così enormemente sulla quota di autoconsumo, tuttavia solo se il rapporto tra potenza prodotta e fabbisogno energetico è equilibrato. Altri fattori sono da ricercarsi negli aspetti produttivi, come l’ubicazione e l’orientamento dell’impianto, che influiscono sull’ammontare del rendimento energetico e anche sulla ripartizione durante la giornata, un elemento fondamentale per l’autoconsumo. 1.5 I contatori intelligenti (Smart Meter) Il costo crescente dell’energia, l’esigenza di ridurre i costi di gestione e l’indispensabile protezione dell’ambiente richiedono una sempre maggiore capacità di gestire il consumo di energia in termini non solo di consuntivazione dei profili di consumo ma di gestione degli stessi profili compatibilmente con le disponibilità delle reti e delle infrastrutture e delle necessità degli utenti. La consuetudine di analizzare i costi dell’energia una volta l’anno, o nella migliore delle ipotesi una volta al mese, non consente alcun tipo di azione di miglioramento. Solo quando si riesce a conoscere istantaneamente quando, a quale scopo e quanta energia viene consumata, si possono prendere delle decisioni che incidano realmente sui consumi, come per esempio attivare o spegnere determinate utenze nelle fasce tariffarie più favorevoli. Chi viene messo a confronto tempestivamente con i propri costi energetici, immediatamente può intraprendere misure di risparmio veloci e mirate. Per questo motivo, l’introduzione di contatori di corrente intelligenti è stata fortemente incentivata in Italia e nel mondo per una maggiore trasparenza nel consumo dell’energia elettrica. Lo smart metering rappresenta una tecnologia di grande utilità nel campo dell'efficienza energetica perché è lo strumento impiegato per la misurazione dei risparmi conseguibili a seguito di interventi di efficientamento. La sua applicazione, infatti, consente di accompagnare ogni intervento dalla fase progettuale, con la misurazione e valutazione dei consumi e delle dispersioni di energia di un impianto o di un edificio prima dell'intervento di riqualificazione, passando per il monitoraggio nel corso della fase di realizzazione e terminare con la 7 misurazione e il controllo in tele gestione dei consumi post intervento e dei risparmi conseguiti. Lo smart metering è un sistema di controllo basato su reti di sensori (wireless, Plc, RS485) per il monitoraggio in tempo reale dei consumi non solo di energia elettrica, ma anche di gas e acqua. Grazie alla possibilità di interfaccia con le tecnologie informatiche e di comunicazione, esso consente di intervenire sugli impianti regolando lo scambio sia di energia sia di informazioni sul funzionamento dell'impianto, offrendo anche la possibilità di intervenire in caso di problematiche o guasti in modalità immediata, senza dover ricorrere all'intervento sul posto. Le tecnologie di cui si compone, in particolare la sensoristica, sono tecnologie già mature e ampiamente diffuse sul mercato e accessibili a prezzi contenuti. Pertanto il ricorso allo smart metering è auspicabile a ogni livello della rete di distribuzione e consumo di energia, dalla centrale, alla rete intelligente alla singola unità abitativa, in quanto con un costo contenuto permette da sola di valutare i consumi energetici e alla luce dei risultati riscontrati programmare interventi di efficientamento. I requisiti di legge prevedono che l’ente erogatore di energia installi nuovi contatori presso i clienti e che effettui una rilevazione del consumo di energia a intervalli regolari mediante la lettura remota o diretta e la metta a disposizione del cliente in una modalità opportuna. In questo modo si pensa di informare il cliente sul suo consumo di energia in forma cartacea, mediante l’accesso all’ente erogatore via internet o direttamente. Il vantaggio per i clienti consiste nell’essere informati sui loro consumi effettivi a intervalli di tempo regolari invece che attendere una bolletta energetica riferita magari a tutto l’anno con consumi di energia stimati mediante una estrapolazione basata sulle letture dell’anno precedente. Il vantaggio per i clienti potrebbe sembrare presunto, poiché i requisiti di legge impongono esclusivamente una rilevazione giornaliera dei dati di energia e si limitano all’energia elettrica. Infatti, da una curva giornaliera dei consumi di energia i clienti non riceverebbero molte informazioni utili per trarre delle conclusioni circa i profili di consumo delle singole utenze; la seconda perplessità potrebbe nascere dal fatto che conoscere i costi di riscaldamento senza essere informati sulle temperature nei vari ambienti, sullo stato di apertura delle finestre o sullo stato di occupazione dell’abitazione risulterebbe inutile. A che cosa serve essere informati sui costi di fornitura dell’energia elettrica, senza tuttavia conoscere lo stato delle singole utenze o di occupazione dell’edificio? I clienti sono in grado di trarre migliori conclusioni sul comportamento di consumo e sul potenziale di risparmio o indicazioni dirette per l’ottimizzazione dei comportamenti se sono disponibili le temperature negli ambienti, la posizione delle finestre e lo stato di occupazione. Per questo motivo un sistema di monitoraggio offre soluzioni per la visualizzazione e l’automazione che possono essere combinate con la rilevazione dei dati di consumo. Il risultato di questa implementazione è una gestione attiva dell’energia, mediante la quale i clienti sono informati e, ancora più importante, consigliati in modo mirato su tutte le modifiche necessarie dei modi di utilizzo, il che rende il vantaggio del cliente tutt’altro che presunto. Lo smart metering è inoltre strumento indispensabile nell'evoluzione delle reti elettriche tradizionali in smart grid, argomento che verrà trattato nella sezione seguente. 8 1.6 Smart Grid Per Smart Grid si intende una rete elettrica in grado di integrare intelligentemente le azioni di tutti gli utenti connessi (consumatori e produttori, "prosumers") al fine di distribuire energia in modo efficiente, sostenibile, economicamente vantaggioso e sicuro. La Smart Grid prevede l’utilizzo di prodotti e servizi innovativi assieme a tecnologie intelligenti di monitoraggio, controllo, comunicazione, self-­‐healing al fine di facilitare la connessione e l'operatività di generatori elettrici eterogenei di qualunque dimensione e tecnologia, fornire ai consumatori strumenti per contribuire ad ottimizzare il funzionamento del sistema globale, dare ai consumatori maggiore informazione e potere di scelta, ridurre significativamente l'impatto ambientale dell'intero sistema elettrico e aumentare il grado di affidabilità e sicurezza del sistema elettrico. Con il concetto di Smart Grid viene superata la visione classica di rete elettrica. Non più una rete di distribuzione sostanzialmente passiva che trasporta l'energia in una sola direzione, da poche grandi centrali di generazione a tanti piccoli punti di consumo dislocati presso gli utenti finali. Non più solo un controllo centralizzato, con linee, interruttori, trasformatori, ma anche flussi di potenze bidirezionali e reti attive, fatte anche di elettronica, informatica e comunicazione. Con una tale trasformazione della rete di distribuzione è necessario gestire sia i flussi di energia prodotta dalle grandi centrali (termoelettriche, idroelettriche), sia quelli da produzione di media e piccola entità da fonti rinnovabili (fotovoltaico, eolico, termico) superando anche le difficoltà connesse all'inversione di flusso sull'interfaccia AT/MT (cabine primarie) e sulle linee MT. Sul piano del controllo la rete elettrica dovrà assomigliare ad una "internet of Energy" in cui ogni sistema di micro-­‐generazione sia connesso in rete e in grado di comunicare e ricevere dati. In sostanza ogni casa, ogni utente potrebbe divenire un prosumer, sia consumatore che produttore di energia in un mercato aperto sia ai grandi distributori che ai piccoli utenti. La necessità di rendere disponibili in tempo reale i profili di consumo/micro generazione di utenti e gestori richiede l'introduzione di smart meters (contatori intelligenti) connessi ad una rete di comunicazione broadband in grado di gestire un flusso di monitoraggio e controllo bidirezionale. Il software consente di disporre in ogni momento dei dati sui quantitativi di energia utilizzati in qualsiasi punto della rete, utilizzando la capacità di interconnessione per orientare e dosare i flussi di energia a seconda dei momenti e dei luoghi di maggiore o minor consumo L'impiego di tecnologie informatiche e di comunicazione (ICT) è quindi il trampolino per l'evoluzione delle reti in reti intelligenti perché consente la comunicazione fra utilities e utenti finali, così come le tecnologie, le piattaforme informatiche e gli algoritmi di controllo distribuito necessari ad ottimizzare l'efficienza di tutti i sistemi coinvolti. Inoltre le ICT possono garantire un nuovo livello applicativo di servizi basati sull'energia quali servizi di smart metering, nuovi schemi tariffari, prepagato per l'energia, portali domestici per la gestione di consumi e generazione, sistemi automatici di acquisto, accumulo e vendita dell'energia elettrica, sistemi di bilanciamento della domanda e offerta di energia. 9 Figura 1.4: Esempio di Smart Grid4 1.7 Gestione dei carichi elettrici Uno dei sistemi più efficaci per contenere i costi di energia elettrica è quello di avere totale consapevolezza dei consumi energetici dei propri carichi e poterne gestire il funzionamento in maniera automatica. A tale scopo esistono diversi sistemi di Building Automation per la gestione dei carichi elettrici, più o meno complessi ed efficaci. In sintesi si tratta di dispositivi in grado di monitorare istante per istante gli assorbimenti elettrici degli utilizzatori in maniera da individuarne le caratteristiche principali (picchi di assorbimento, basso utilizzo, disturbi ecc) e poter così adottare gli accorgimenti correttivi idonei. Tali sistemi, opportunamente programmati, sono in grado anche di gestire i carichi stessi, disattivando, ad esempio in caso di sovraccarico, le linee "secondarie", cioè meno importanti (insegne, distributori di bevande, condizionamento ecc) a favore dei carichi "primari" più importanti (ascensori, computer, server, illuminazione ecc). Tramite dispositivi Touch screen e Local display oppure attraverso veri e propri sistemi di supervisione installati su PC, l'utente può verificare il consumo totale delle singole linee controllate e decidere di modificare la priorità tra le stesse. Prevenire i rischi di sovraccarico è importante sia per evitare lo sgancio di interruttori di protezione e quindi il disservizio che ne deriverebbe (mancanza di erogazione di energia elettrica parziale o totale), sia per contenere considerevolmente i costi dell'energia: è noto infatti che superato il limite contrattuale di fornitura dell'energia elettrica concordato con il gestore, sull'esubero vengono applicate penali o tariffe maggiorate e spesso l'utente se ne accorge solo nel momento in cui riceve la bolletta. Nel dimensionamento di un impianto elettrico si effettua per prima cosa l'analisi dei carichi: si sommano le singole potenze e quindi si moltiplicano per il fattore di contemporaneità; questo fattore, che oscilla fra 30% e 70%, indica quale sia il consumo massimo che ci si può aspettare. Il coefficiente di contemporaneità dipende dall'utilizzo che si fa della corrente elettrica: il risultato indica quale è la potenza da richiedere al proprio fornitore. Il sistema di gestione carichi permette di abbassare il fattore di contemporaneità e quindi riduce la potenza massima necessaria, consentendo così di stipulare contratti economicamente più vantaggiosi. Inoltre attraverso tali sistemi è possibile disattivare determinate utenze elettriche in particolari fasce orarie o in giorni prestabiliti (ad esempio di notte ed in giornate festive): ciò determina un ulteriore importante risparmio energetico, oltre che un maggior livello di sicurezza. 4 Fonte dell’immagine: http://www.hitachi.com 10 I sistemi sopra descritti possono essere facilmente integrati su impianti elettrici esistenti di qualunque tipo, oppure previsti in fase progettuale nella realizzazione di nuovi impianti con costi aggiuntivi davvero contenuti rispetto ai vantaggi che ne derivano. 11 Capitolo 2: Il framework OSGi 2.1 Genesi e architettura Nel 1998 Oracle, Ericsson, Ibm e altre aziende fondano un consorzio, denominato OSGi (Open Servce Gateway Initiative) Alliance il cui obiettivo è implementare un framework che sia: 1. modulare: per la piattaforma Java e JEE; 2. dinamico: che consenta la distribuzione, l’avvio, lo stop e la rimozione di moduli a run-­‐time, senza dover riavviare l’intero sistema; 3. orientato ai servizi: che possano essere dinamicamente registrati e utilizzati. Il modello è a strati ed è descritto dalla figura 2.1. Figura 2.1: Struttura a strati del framework OSGi5 La lista seguente contiene una breve definizione dei termini: • Bundles (a cui è dedicata la seguente sezione del capitolo) : sono i componenti OSGi creati dagli sviluppatori. • Services : sono classi Java che implementano interfacce “di servizio”, le quali possono essere native(ad es. HTTPService, LogService, DeviceAccessService) o realizzate dallo sviluppatore. • Life-­‐Cycle: API per installare, avviare, arrestare, aggiornare e disinstallare i bundle. • Modules: è lo strato che definisce come un bundle possa esportare e importare codice. • Security: lo strato che si occupa degli aspetti di sicurezza. • Execution Environment: definisce quali metodi e/o classi sono disponibili per una specifica piattaforma. 5 Fonte dell’immagine: http://www.osgi.org 12 2.2 Il bundle Il framework definisce l’unità modulare, detta bundle. Un bundle comprende classi Java e risorse che insieme fornisco funzionalità all’utente. Nel framework OSGi, i bundle sono le uniche entità di sviluppo di un’applicazione Java. Un bundle è dunque un Java ARchive (JAR) file che: • Contiene le risorse necessarie per fornire funzionalità. Queste risorse possono essere classi Java, files HTML, icone e così via. Un bundle può inoltre integrare JARs addizionali disponibili come classi (non è ricorsivo). • Contiene un file speciale, il “manifest” (la cui descrizione è rimandata alla sezione 2.5), che descrive il contenuto del file JAR e fornisce ulteriori informazioni riguardo al bundle. Il manifest usa degli headers per specificare alcune informazioni che il framework deve utilizzare per installare correttamente e attivare un bundle. • Può contenere documentazione opzionale nella directory OSGI-­‐OPT del file JAR o in una delle sue subdirectory. Ogni informazione contenuta nella directory è opzionale. Solitamente la directory OSGI-­‐OPT contiene codice sorgente e/o la documentazione del bundle. Una volta che un bundle viene avviato, le sue funzionalità vengono rese disponibili e i servizi esposti agli altri bundle installati sul framework. 2.3 Il ciclo-­vita di un bundle Un bundle può trovarsi esclusivamente in uno dei seguenti sei stati: 1. INSTALLED – Il bundle è correttamente installato. 2. RESOLVED – Le classi Java del bundle sono effettivamente disponibili. In altre parole, lo stato indica che il framework ha risolto le dipendenze descritte nel manifest. 3. STARTING – Il bundle è avviato, viene cioè chiamato BundleActivator.start() e il metodo non ha ancora un valore di ritorno. 4. ACTIVE – Il bundle è lanciato e i suoi servizi sono resi disponibili. 5. STOPPING – Il bundle viene arrestato, viene cioè chiamato BundleActivator.stop() e il metodo non ha ancora un valore di ritorno. 6. UNINSTALLED – Il bundle viene disinstallato. Da qui non si può raggiungere alcun altro stato. L’interfaccia Bundle definisce un metodo getState() che ritorna lo stato in cui si trova il bundle. La sequenza degli stati nel ciclo vita di un bundle, con le relative transizioni, è descritta dalla figura 2.2. 13 Figura 2.2: Descrizione degli stati e delle transizioni di un bundle.6 2.4 Bundle e servizi Nel framework OSGi, i bundle sono costruiti attorno a un set di servizi, disponibile in un registro condiviso: il service registry. Ogni servizio è definito dalla propria interfaccia (OSGi dispone di molte interfacce riservate ai servizi per diverse esigenze) e implementato come “oggetto servizio”. Un bundle può creare un oggetto e registrarlo nel service registry sotto una o più interfacce. Altri bundle possono accedere al registro dei servizi e ottenere la lista completa di tutti i servizi registrati sotto una specifica classe o interfaccia. Un bundle può dunque registrare un servizio, “leggerlo” (get) o abbonarsi a esso (listen, ovvero il bundle riceve una notifica ogni qual volta quel particolare servizio cambia). 6 fonte dell’immagine: https://www.ibm.com 14 Figura 2.3: Interazione bundle-­‐servizi7 Le dipendenze tra bundle e servizi sono gestite direttamente dal framework. Ad esempio quando un bundle viene arrestato tutti i servizi registrati da quel bundle vengono automaticamente eliminati (unregistered). Cosa accade se diversi bundle registrano oggetti sotto la stessa classe o interfaccia? Come potranno essere distinti? I servizi dispongono di una serie di proprietà che forniscono informazioni riguardo al servizio considerato. Le informazioni contenute nelle proprità vengono mantenute in forma di chiave/valore, dove la chiave è un oggetto di tipo stringa a cui è associato un generico oggetto (esattamente come nelle HashMap Java, con la differenza che la chiave in questo specifico contesto è obbligatoriamente una stringa) che fornisce una descrizione del servizio. Le proprietà vengono spesso utilizzate per la ricerca di un servizio, ricerca che può essere filtrata in base alla chiave. Tutte le chiavi che iniziano con il prefisso “service.” e la chiave “ObjectClass” sono riservate per le specifiche d’uso OSGi. 2.5 Il file manifest.mf l file manifest.mf, attraverso una serie di coppie nome-­‐valore, definisce le direttive di distribuzione e installazione del bundle all’interno della piattaforma, il suo classpath, le sue dipendenze da altri package e servizi, oltre ai servizi che espone. Ecco una breve e schematica descrizione degli header presenti nel manifest, caratteristico di ogni bundle: Bundle Activator: Classe utilizzata per avviare e arrestare il bundle. Bundle-­‐ClassPath: Specifica il CLASSPATH da utilizzare per il bundle. La struttura può contenere riferimenti a directory o file jar all’interno del bundle. Bundle-­‐ContactAddress: Contiene l’indirizzo per contattare il venditore. Bundle-­‐Copyright: Contiene le specifiche di copyright del bundle. Bundle-­‐Localization: Specifica la locazione del file bundle, il cui valore di default è OSGI INF/bundle. Bundle-­‐ManifestVersion: Specifica che il bundle segue le specifiche V3 o V4 di OSGi. 7 Fonte dell’immagine: http://felix.apache.org 15 Bundle-­‐Name: Specifica il nome del bundle senza spazi. Bundle-­‐SymbolicName: Specifica un nome univoco per il bundle. Bundle-­‐Vendor: Contiene il nome del venditore del bundle. Bundle-­‐Version: Specifica il numero di versione del bundle. Bundle-­‐ActivationPolicy: La politica con cui il bundle a runtime deve essere attivato (“lazy” è l’unico valore supportato). Export-­‐Package: Specifica tutti i package da esporre pubblicamente ad altri plug-­‐in. Import-­‐Package: Specifica tutti i package necessari da importare in modo esplicito dal bundle. Require-­‐Bundle: Questa proprietà specifica quali bundle e quali loro exported package siano da importare per essere utilizzati nel bundle. Import-­‐Package e Require-­‐Bundle possono includere anche l’informazione sulla versione del package o del bundle. Gli header sopracitati sono in gran parte opzionali tuttavia, quando possibile, è consigliato farne uso. Figura 2.4: Esempio del manifest relativo al bundle “prova”. 16 2.6 Concetti fondamentali e peculiarità Per gli sviluppatori software che utilizzano Java, la tecnologia OSGi rappresenta il logico passo successivo perché risolve molti problemi che il linguaggio nativo non permette di gestire efficacemente. I vantaggi della tecnologia OSGi, che verranno dettagliatamente esaminati, sono così numerosi che, uno sviluppatore che utilizza Java, deve (o comunque dovrà) avere OSGi nel proprio bagaglio: • Complessità Ridotta – Sviluppare su tecnologia OSGi significa sviluppare bundle, cioè i componenti OSGi. I bundle sono moduli che incapsulano il loro “interno” nascondendolo ad altri bundle e comunicano tramite i servizi. Nascondere il proprio interno signifca avere più libertà di modifica nel futuro, il che non solo riduce il numero e la probabilità di bug ma rende più semplice lo sviluppo dei bundle stessi. • Mondo Reale – Il framework OSGi è dinamico. Può caricare bundle “al volo” e i servizi “vanno e vengono”. Sviluppatori abituati a un più tradizionale Java lo vedono come una caratteristica problematica e talvolta non ne colgono i reali vantaggi. Tuttavia, risulta che il “mondo reale” è altamente dinamico e la dinamicità dei servizi si adatta particolarmente a molti scenari reali e attuali. Per esempio, un servizio può tenere traccia di un dispositivo nella rete: se questo è attivo, il servizio viene registrato, altrimenti no. • Facile Diffusione – La tecnologia OSGi non è solamente un modello per componenti. Esso specifica anche come questi vengono installati e gestiti. La sua API è standardizzata in modo tale da renderene facile la diffusione e l’integrazione nei sistemi esistenti e in quelli futuri. • Aggiornamenti Dinamici – La dinamicità del modello consiste nel fatto che i bundle possono essere installati, avviati, arrestati, aggiornati e disinstallati senza dover riavviare l’intero sistema. Molti sviluppatori Java inizialmente non si fidano, credendo che tutta questa dinamicità possa non essere sufficientemente attendibile. Tuttavia, dopo aver fatto esperienza, questi si rendono conto che sfruttare la tecnologia OSGi nel modo adeguato può rendere lo sviluppo sorpredentemente efficiente e affidabile. • Adattabile – Il service registry è un registro dinamico nel quale i bundle possono registrarsi, leggere (get), o abbonarsi (ovvero ricevere una notifica al cambiamento) a uno o più servizi. Questo permette ai bundle di verificare quali proprietà sono disponibili sul sistema e adattarne le funzionalità che il bundle stesso può poi fornire. Tutto ciò rende il codice più flessibile ed elastico ai cambiamenti. • Trasparenza – L’API di management fornisce l’accesso all’interno di un bundle oltre a rendere noto come quel bundle è connesso agli altri. Inoltre, il framework fornisce una shell di comando che mostra lo stato interno. Parti di una applicazione possono essere arrestate singolarmente per operazioni di debug, evitando così al programmatore di dover leggere migliaia di righe di codice, facendogli risparmiare tempo e pazienza. • Versioning – Talvolta il problema dei file JAR è che la libreria A funziona con la libreria B versione 2 ma la libreria C può funzionare solamente con la libreria B versione 3. Un Java standard può portare il programmatore ad avere, in un contesto simile, seri problemi di gestione. Nell’ambiente OSGi, tutti i bundle vengono attentamente versionati e solamente i bundle che possono collaborare tra loro vengono collocati nella stessa class space. Questo 17 permette ai bundle A e C di funzionare correttamente con le rispettive librerie. Anche se non è obbligatorio un design che tenga conto di questo metodo di gestione delle versioni, in casi come quello sopra citato potrebbe semplificare la vita del programmatore. •
•
•
•
•
•
•
Facile – L’API OSGi è sorprendentemente semplice. Il nucleo è solamente un package con meno di 30 classi/interfacce. Esso è sufficiente per scrivere bundle, installarli, avviarli ecc... e include tutti i listeners e le classi di sicurezza. Sono poche le API che forniscono cosi tanto rimanendo al contempo così semplici. Piccolo – La versione 4 del framework OSGi è un file JAR di soli 300KB. L’overhead risulta veramente piccolo rispetto alla quantità di funzionalità che si aggiungono a un’applicazione includendo OSGi. Per questo motivo si adatta sia a dispositivi piccoli, come uno smartphone, sia ai grandi mainframes. Esso richiede solamente una minimale Java Virtual Machine per funzionare e ad essa aggiunge pochissimo. Veloce – Una delle responsabilità principali del framework è quella di caricare le classi dai bundle. In un Java tradizionale i JARs sono completamente visibili e localizzati in una lista lineare; per questo motivo cercare una classe può significare far scorrere l’intera lista, il che può risultare lungo in termini di tempi. Oppositamente, OSGi “pre-­‐collega” i bundle e conosce di ognuno di essi esattamente quale fornisce la classe. Non aver la necessità di ricerca delle classi rappresenta un notevole guadagno di tempo all’avvio. Pigro – Essere pigro (lazy) in ambito software è una qualità vincente e la tecnologia OSGi presenta molti meccanismi per “fare solo quando è veramente necessario”. Un bundle può essere avviato bramosamente, tuttavia esso può anche essere configurato in modo da attivarsi solo nel momento in cui un altro bundle lo richiede. I servizi possono essere registrati ma possono essere creati solo quando vengono utilizzati. Le specifiche con le varie versioni sono state ottimizzate in modo da risparmiare notevoli costi a runtime a causa di questi possbili scenari. Sicuro – Il modello di sicurezza OSGi fa leva su quello Java e ne migliora l’utilizzabiltà, rafforzandolo, facendo specificare i dettagli direttamente dallo sviluppatore in maniera semplice. Comunque, OSGi fornisce uno degli ambienti più sicuri utilizzabile anche senza piattaforme con hardware protetto. “Gira” Dappertutto – L’ obiettivo originale di Java era di girare dappertutto. Ovviamente ciò non sempre è possibile date le differenze delle Java VM. Ad esempio, una Java virtual machine di un telefono cellulare non potrà supportare le stesse librerie di un mainframe che sta eseguendo un’applicazione per una banca. Le questioni sono essenzialmente due: anzitutto l’API OSGi non dovrebbe utilizzare classi che non sono disponibili per tutti gli ambienti, secondariamente un bundle non dovrebbe essere avviato se contiene codice che non è supportato dall’ambiente su cui viene eseguito. Entrambe le questioni sono presenti nelle specifiche OSGi. Ampiamente Utilizzato – Le specifiche OSGi si diffusero inizialmente nel mercato dei sistemi embedded per la domotica, trovando largo impiego in molte industrie, da quelle di automobili e di telefonia mobile a quelle di automazione, di gateway e routers e molte altre. Dal 2003 Eclipse si basa su tecnologia OSGi e fornisce il supporto per lo sviluppo di bundle. Negli ultimi anni, OSGi è sbarcato nelle aziende dedicate allo sviluppo. Gli sviluppatori Eclipse, ma non solo, hanno scoperto l’enorme potere della tecnologia OSGi. 18 Oggi, si può trovare la tecnologia OSGi alla base di Websphere di IBM, SpringSource dm Server, Weblogic e GlassFish di Oracle e molti altri. Osgi è anche alla base di Dog (Domotic Osgi Gateway), il quale verrà esaminato nel capitolo 3 e sarà il software di base su cui verrà sviluppato il bundle VirtualPowerMeter (capitolo 4 ). •
Supportato da Aziende “Chiave” – OSGi conta alcune tra le maggiori compagnie informatiche e non quali Oracle, IBM, Samsung, Nokia, Progress, Motorola, NTT, Siemens, Hitachi, Deutsche Telekom, Redhat, Ericsson e molte altre. 19 Capitolo 3: Dog e Z-­Wave 3.1 The Dog Gateway Dog (Domotic OSGi Gateway) è un middleware che utilizza la tecnologia OSGi come coordinatore di moduli di attivazione dinamici, per introdurre e togliere componenti dinamicamente (hot-­‐plug) e per gestire anomalie dei moduli. Dog viene sviluppato, per scopi domotici, a partire dal 2006 dal gruppo di ricerca e-­‐Lite del Politecnico di Torino. La prima versione viene chiamata BCF, acronimo di Basta Che Funzioni, presumibilmente per evidenziare che il software era destinato a crescere ancora. Dal 2007 ad oggi, Dog è stato sviluppato e migliorato notevolmente; esso viene utilizzato in sistemi domotici integrati per abitazioni di ultima generazione, ma anche per macchine di automazione industriale. Negli ultimi anni sono state rilasciate 3 maggiori versioni; attualmente l’ultima è la 3.1. Dog è una soluzione open source capace di funzionare su hardware a basso costo (e basse prestazioni) come la Raspberri Pi, fornendo comunque un servizio efficiente ed efficace. Dog fornisce una semplice interfaccia web che consente il controllo dei dispositivi, e non solo, da parte dell’utente che comprende tre sezioni: overview, che mostra lo stato del gateway, la memoria totale, utilizzata e libera e il numero di dispositivi e dei bundle attivi; devices, che per ogni dispositivo mostra lo stato, i dati associati al dispositivo(ad esempio potenza, energia ecc..) e i comandi per controllare il dispositivo stesso (on, off, associate ecc…); components, che elenca tutti i bundle e visualizza il loro stato (attivo o non attivo). La figura 3.1 riporta un esempio dell’interfaccia web. Figura 3.1: interfaccia web Dog, sezioni overview e devices (screenshot). 20 3.2 DogOnt DogOnt è la rappresentazione formale, condivisa ed esplicita della concettualizzazione dell’ambiente domotico, ovvero l’ontologia. DogOnt descrive un modello “a dispositivi” ed è organizzato in 5 grandi gerarchie di concetti (rappresentati dalle relative interfacce, in corsivo di seguito), che descrivono: • La struttura di un ambiente domotico (stanze, muri, porte ecc..), concetti derivanti dal BuildingEnvironment; • Il tipo di dispositivi domotici ( Controllable, derivante da BuildingThing); • Il tipo di “arredamento” (Uncontrollable, derivante anch’esso da BuildingThing); • La configurazione che i dispositivi possono assumere (stati), States e StateValues. • Le funzionalità dei dispositivi (Functionalities) in termini di accettazione di eventi e generazione di messaggi, Commands e Notification. • Le informazioni della tecnologia specifica necessaria per interfacciarsi al mondo dei dispositivi (NetworkComponent); Ogni dispositivo può essere schematizzato in una struttura ad albero in cui i nodi principali sono costituiti dalle caratteristiche che un dispositivo può effettivamente avere all’interno di un ambiente domestico, vale a dire Controllable o Uncontrollable, BuildingEnvironment (in quale stanza della casa il dispositivo si trova), State, StateValues e Functionality. Functionalities Descrive il dispositivo sotto il punto di vista delle proprietà di interazione con l’ambiente, cioè come un dato dispositivo può essere controllato, interrogato e come esso può autonomamente generare eventi. Ad esempio, se una lampada può solamente essere spenta o accesa, un sensore di luminosità può essere interrogato su quale sia la luminosità attuale ma può anche notificare i cambiamenti di luminosità a intervalli di tempo regolari. DogOnt Functionalities include: • ControlFunctionalities: come un dispositivo può essere controllato da messaggi o comandi; • QueryFunctionalities: come un disposivo può essere interrogato riguardo allo stato in cui si trova; • NotificationFunctionalities: come un dispositivo può mandare notifiche sul cambiamento di stato. States Descrive le varie configurazioni stabili che un dispositivo può assumere durante il suo ciclo vita. Ogni dispositivo può includere simultaneamente differenti comportamenti. Ad esempio un lettore CD può essere acceso o spento, può riprodurre una canzone e può avere un valore di volume in output per gli auricolari. Nel DogOnt questi comportamenti sono chiamti dogont:States. La descrizione di ogni state è invece chiamata dogont:StateValue. Per quanto riguarda l’esempio del lettore CD, esso può avere tre dogont:States differenti : un dogont:OnOffState, un dogont:PlayingState e un dogont:VolumeLevelState. Ognuno di questi tre stati include specifici set di possibili valori, ad esmpio OnStateValue o OffStateValue. Le figure 3.1 e 3.2 mostrano esempi di dispositivi all’interno della rete schematizzata dal DogOnt. 21 Figura 3.1: Lampada nel DogOnt.8 Figura 3.2: Dimmer Lamp nel DogOnt9 8 Fonte dell’immagine: www.slideshare.net/dbonino 9 Fonte dell’immagine: www.slideshare.net/dbonino 22 3.3 Architettura Dog è organizzato in un’architettura a strati, precisamente quattro, ognuno con scopi e responsabiltà differenti. Ogni strato contiene diversi bundle OSGi, corrispondenti ai moduli funzionali del sistema (88 in totale). Figura 3.2: Architettura a strati di Dog.10 Il primo strato, Drivers, comprende i bundle Dog che forniscono un’interfaccia tra le diverse abitazioni e le reti a cui Dog può connettersi. Ogni tecnologia di rete è gestita da un set di driver dedicato che astrae sui protocolli specifici di ogni rete permettendo così una rappresentazione che gestisce in modo uniforme dispositivi differenti. Il secondo strato, Core, contiene il nucleo (core) di Dog, basato su DogOnt, implementato dal bundle Semantic House Model. Inoltre, fornisce un set di librerie comuni e servizi utili all’intero sistema o previste dalle specifiche OSGi. Il terzo strato, Addons, include bundle addizionali che possono fornire ulteriori funzionalità al “core” , come ad esempio salvataggio di dati, stream processing ecc. L’ultimo strato, Communication, fornisce bundle che offrono l’accesso da applicazioni esterne (ad esempio WebSocket). Di seguito vengono riportati le rilevanti funzionalità di ogni strato. Drivers Per interfacciare le abitazioni alle reti di “building automation”, Dog fornisce una serie di drivers, uno per ogni tecnologia (KNX NetIP, Z-­‐Wave, ecc.). L’implementazione e le operazioni 10 Fonte dell’immagine: www.slideshare.net/dbonino 23 dei driver seguono le specifiche OSGi. Ogni driver svolge una fase di “self-­‐configuration” in cui interagisce col framework OSGi al fine di ricevere tutte le informazioni necessarie quali ad esempio l’indirizzo o l’ID di un dispositivo nella rete. Per ogni tecnologia deve esistere almeno un Network Driver, un Gateway Driver e un Device Driver. Il Network Driver si occupa di gestire la comunicazione a livello di rete (protocolli e procedure di polling, ove necessario). Definisce inoltre le API di accesso alla rete per tutti i bundle Device Driver della stessa tecnologia. Solamente un Network Driver può esistere per ogni tecnologia. Il Gateway Driver gestisce le associazioni tra i dispositivi e i loro gateway. Inoltre, per una specifica tecnologia, può fornire specifici comandi e funzionalità per il gateway. Solamente un Gateway Driver può esistere per ogni tecnologia. Un Device Driver implementa le caratteristiche di un dispositivo del DogOnt per una data classe di dispositivi, traduce cioè comandi ,funzionalità e stati dei dispositivi in messaggi a livello rete. Tipicamente, un Device Driver viene creato per ogni classe di dispositivi. Attualmente sono presenti otto tecnologie differenti supportate da Dog, ognuna con un largo numero di dispositivi associati a essa: KNX NetIp, Modbus (RTU e TCP), Echelon iLon100, eLite (un set di driver simulati), Bticino OpenWebNet, ZigBee Home Automation profile, SimpliciTi e Z-­‐Wave, a cui sono dedicate le sezioni 3.4 e 3.5 del capitolo. Core Lo strato core rappresenta il nucleo, la parte cioè intelligente del sistema; esso fornisce librerie e servizi utili all’intero sistema. La categoria Device Management comprende tre bundle per gestire interamente il ciclo vita di un dispositivo e le sue variabili di stato: • Il bundle Device Factory è responsabile di creare e distruggere istanze di dispositivi nel framework, secondo le configurazioni che riceve a run-­‐time. La configurazione può essergli fornita da uno degli “House Models” oppure dal Gateway Driver. • Il bundle Device Manager implementa le specifiche di accesso di un dispositivo OSGi (Device Access Specification): gestisce le procedure che associano un dispositivo al corretto driver, ogni qual volta uno dei dispositivi viene aggiunto, modificato o rimosso dal framework. • Il bundle Monitor Admin implementa le specifiche di servizio dell’amministratore del monitor OSGi (Monitor Admin Service Specification): fornisce l’accesso a ogni variabile di stato definita nel framework. Inoltre, fornisce algoritimi di controllo per la sicurezza e lo scheduling di alcuni processi a lui collegati. La categoria House Models comprende due bundle: Semantic e Simple House Model: • Il bundle Semantic House Model gestisce la descrizione dell’abitazione in forma di istanze del DogOnt; dispone di alcune funzionalità di “model merging” e fornisce potenziale accesso a tutte le proprietà definite nell’ontology. Inoltre, può generare la configurazione XML usata successivamente da Simple House Model. • Il bundle Simple House Model gestisce ladescrizione dell’abitazione in formato XML e tipicamente viene utilizzato da istanze Dog legate a dispositivi con un basso potere computazionale. A differenza del Semantic, non possiede supporto per funzionalità di merging. La categoria Facilities comprende due bundle: Logger e Clock. Essi offrono rispettivamente uan console di log tramite l’OSGi LogServce e un servizio di clock interno. La categoria Libraries consiste di sei bundle che si comportano come repository di classi, interfacce e servizi di altri bundle. La JAXB Library fornisce una funzionalità di serializzazione XML per gestire la configurazione del Simple House Model o anche per messaggi dello strato 24 Communication. La Measure Library fornisce tutte le unità di misura e le operazioni ad esse collegate offrendo la libreria JScience a tutti i bundle Dog; fornisce anche ulteriori unità di misura che la libreria JScience non supporta. La Semantic Library incapsula e rende disponibili tutte le librerie “semantiche”, quali Apache Jena, Pellet e SPARQ query facilitator. La Stream Library definisce alcuni tipi di eventi e ne uniforma la modalità di accesso. La org.rxrx, similmente alla Measure Library, esporta la libreria API RXTX a tutti i bundle Dog. Infine, la Core Library è quella più importante: essa contiene tutti i possibili dispositivi, le funzionalità, i valori degli stati associati ad essi come definito nel DogOnt e tutte le loro possibili implementazioni, dispone di funzioni di notifica e fornisce classi di utility agli altri bundle, al fine di evitare duplicazione di codice. Addons Lo strato Addons fornisce bundle addizionali al fine di introdurre funzionalità che incrementino l’intelligenza dello strato precendente. Attualmente, comprende i seguenti bundle: • Il Rule Engine : fornisce un “motore regolatore” runtime per definire scenari automatici e comportamenti complessi dei dispositivi; è programmabile tramite messaggi XML dedicati, da parte dello strato Communication o direttamente da disco. • Il Power Bundle offre stime di consumo basate su misure attuali o valori nominali definiti dal DogOnt. • Il bundle Stream Processor fornisce funzionalità di stream processing. • Infine, il bundle Event Storage memorizza gli eventi più importanti (ad esempio le misurazioni) in un piccolo database. I dati memorizzati possono essere successivamene visualizzati e analizzati. Communication Lo strato Communication fornisce accesso da applicazioni esterne (non OSGi) offrendo due API alternative: REST API e WebSocket API. Entrambe le API utilizzano una struttura “a messaggi” fornendo le stesse funzionalità e informazioni: esse aiutano a reperire le informazioni riguardo la configurazione dell’abitazione, mandando messaggi ai dispositivi gestiti da Dog, e di tutti i dispositivi. L’unica eccezione riguarda gli eventi asincroni (cioè le notifiche) che possono giungere da ogni dispositivo manipolato da Dog: la funzionalità di gestione di questi è fornita solamente dalla WebSocket API. 3.4 Il protocollo di comunicazione Z-­Wave Z-­‐Wave è un protocollo proprietario per le comunicazioni wireless, sviluppato dalla società Zensys, progettato specificamente per l’home automation, cioè per il controllo remoto di dispositivi in ambito residenziale. La tecnologia alla base del protocollo fa uso di antenne radio a basso consumo, particolarmente adatte a quei dispositivi che possono essere comuni in una casa e che non sempre sono alimentati a corrente. A differenza di altri protocolli per le trasmissioni wireless pensati per l’home automation, quali ad esempio ZigBee, che operano a frequenze elevate (intorno ai 2.4 GHz), Z-­‐Wave utilizza una banda che si assesta intorno ai 900 MHz (con variazioni dipendenti dalle regioni in cui i dispositivi vengono impiegati) per limitare il consumo e per ridurre la probabilità di interferenze con altre applicazioni che operino alle stesse frequenze. Ciò permette di avere un raggio d’azione molto ampio (dipendente 25 comunque dagli ostacoli presenti nell’ambiente di impiego dei dispositivi), di circa 30 metri nel caso di dispositivi interni alla casa e circa 100 metri (e piu`) nel caso di dispositivi impiegati all’aperto. Diversi produttori di dispositivi Z-­‐Wave hanno fondato un’organizzazione, la Z-­‐Wave Alliance, con lo scopo di massimizzare l’interoperabilità tra dispositivi sviluppati da aziende diverse, garantendo dei livelli minimi di compatibilità basati sullo standard di comunicazione Z-­‐Wave. Lo standard Z-­‐Wave, a differenza di altre soluzioni “piu` aperte”, non è di pubblico dominio ed è disponibile soltanto a quelle società che sottoscrivono un accordo di non divulgazione direttamente con Zensys. Z-­‐Wave utilizza una architettura mesh network (ovvero un architettura a nodi in cui ogni nodo coopera con gli altri per la condivisione e la diffusione di dati nela rete) e parte da un singolo dispositivo controllabile; nel nostro caso il primo e unico dispositivo collegato è il gateway. Dispositivi addizionali possono essere aggiunti in qualsiasi momento; un dispositivo, prima di poter essere controllato tramite Z-­‐Wave, deve essere “incluso”, processo che solitamente avviene cliccando un pulsante presente sul dispositivo da includere diverse volte (per i dispositivi da noi utilizzati 3 volte). Per rimuovere il dispositivo dalla rete bisogna fare un procedimento analogo. La procedura di inclusione viene ripetuta per ogni dispositivo presente nel sistema. 3.5 Dog e Z-­Wave Dog è realizzato utilizzando come base la tecnologia OSGi, quindi, ogni dispositivo può essere controllato dalla piattaforma soltanto se questo viene modellato tramite un apposito servizio OSGi Device. Quest’ultimo può essere utilizzato per controllare realmente il dispositivo fisico soltanto se è agganciato ad un opportuno servizio Driver, che può interagire con il particolare driver di rete che gestisce appunto la rete a cui il dispositivo considerato appartiene. Nel driver di rete Z-­‐Wave, infatti, è presente una parte che si occupa di creare una corrispondenza tra un dispositivo Z-­‐Wave e i relativi servizi OSGi. Il driver di rete include anche un sistema di notifiche che ha il compito di propagare gli eventi di rete, quali l’aggiunta o la rimozione di un nodo Z-­‐Wave e il cambiamento di stato di un dispositivo, alla parte di driver che si occupa dei servizi OSGi. Ad esempio, nel caso in cui venga aggiunto un nuovo dispositivo alla rete, verrà generato un apposito evento che provocherà la registrazione dei servizi Device/Driver necessari a controllare il nodo. Le reti wireless come Z-­‐Wave danno l’opportunità di includere o rimuovere un dispositivo in modo relativamente semplice durante il normale funzionamento della rete. Data la dinamicità della rete, non è possibile presupporre una configurazione statica della rete stessa. Per la caratteristica sopra evidenziata di una rete Z-­‐Wave, il problema della registrazione dei servizi Device/Driver in Dog è stato trattato in modo diverso rispetto a quanto è stato fatto per altre reti gestite dalla piattaforma. Nel caso della rete BTicino, ad esempio, si sa a priori quanti dispositivi siano presenti e a quale tipologia appartengano, quindi, viene istanziato per ogni dispositivo un corrispondente servizio Device e un servizio Driver; quest’ultimo in realtà diventa disponibile come servizio e, quindi, utilizzabile dal Device, soltanto quando viene registrato il corretto driver di rete BTicino. Per quanto riguarda Z-­‐Wave, invece, è il driver di rete stesso a istanziare e registrare gli opportuni servizi OSGi quando viene scoperto un nuovo nodo e, altresì, a occuparsi della loro rimozione dal service registry e del loro aggiornamento di stato. Quando viene rilevato un nuovo nodo, il driver di rete crea una o piu` coppie di servizi Device-­‐Driver. Per fare questo, viene utilizzato un sistema di notifiche che permette di sapere 26 quando devono essere istanziati i servizi e/o quando bisogna procedere nell’aggiornare lo stato di un certo Device tramite il Driver associato. 27 Capitolo 4: VirtualPowerMeter 4.1 Premessa e scopo Il VirtualPowerMeter è un componente Dog (un bundle) progettato e realizzato al fine di monitorare e quindi visualizzare la potenza virtuale di un ambiente domotico. Il principio di funzionamento del VirtualPowerMeter è descritto schematicamente dalla figura 4.1. Figura 4.1: schema di funzionamento del VirtualPowerMeter La corrente continua uscente dall’impianto fotovoltaico viene convertita in corrente alternata con le caratteristiche standard di utilizzo. La potenza relativa a questa corrente, tramite un apposito PowerMeter, viene rilevata. Analogamente, sempre tramite l’utilizzo di un PowerMeter appositamente collocato all’interno del contatore principale, viene rilevata la potenza consumata dall’intero ambiente. Il VirtualPowerMeter prende le due potenze in ingresso e ne fa semplicemente la differenza. Successivamente il VirtualPowerMeter visualizzerà la differenza che, a seconda del segno che possiede, indicherà se in quel dato istante l’energia consumata è maggiore di quella prodotta (segno +), se queste si pareggiano (potenza virtuale = 0 cioè si sta autoconsumando) oppure se l’energia prodotta è maggiore di quella consumata (segno -­‐); il primo e l’ultimo caso verranno analizzati nella sezione 4.3 dedicata alle applicazioni future del VirtualPowerMeter. 28 4.2 Implementazione Il bundle rappresenta un dispositivo virtuale, dunque non associabile a nessun dispositivo fisico. Per questo motivo è stato necessario creare una sezione ad hoc per i dispositivi virtuali, del tutto analoga alla sezione “Devices” presente nell’interfaccia web di Dog, in modo tale da poter visualizzare le informazioni necessarie. L’interfaccia web ora si presenta come in figura 4.2. Figura 4.2: Interfaccia web Dog con aggiunta della sezione “Virtual Devices”. Per la realizzazione, sono stati utilizzati due meter: un SinglePhaseMeter e un MeteringPowerOutlet che rappresentano le due fonti di potenza del VirtualPowerMeter ovvero la potenza totale consumata dall’abitazione e quella prodotta da un eventuale impianto fotovoltaico. Non avendo a disposizione per l’attività di un impianto fotovoltaico, questo è stato simulato utilizzando un MeteringPowerOutlet: la potenza fornita dal dispositivo collegato al MeteringPowerOutlet è stata trattata come se proveniente direttamente dall’impianto. Nella prima fase di implementazione si è andati a modificare un componente all’interno del core, la classe WolfUtil, creando due variabili e i relativi metodi di get e set, con lo scopo di mantenere all’interno di esse le informazioni di potenza utili. I metodi e le variabili che ne fanno uso sono raffigurati in figura 4.3. Figura 4.3: get e set di strMeteringOutletPowerValue e strSinglePhasePowerValue. 29 A questo punto è stato necessario andare a settare correttamente queste variabili con i valori reali di potenza dei dispositivi. Ogni dispositivo fisico è collegato al proprio driver, all’interno di Dog. I dispositivi che danno un contributo in potenza, come quelli che ci interessano in questo momento, implementano un metodo, il notifyNewActivePowerValue, la cui responsabilità è quella di notificare il cambiamento di valore della potenza del dispositivo. All’interno di questo metodo, per entrambi i dispositivi, è stata inserita una chiamata rispettivamente a WolfUtil.setPowerFromSinglePhase e WolfUtil.setPowerFromMeteringOutlet, passando al metodo le misure della potenza attuale, in modo tale da sovrascrivre le variabili che contengono la misura di potenza dei dispositivi ogni qual volta questa cambi. Dopo aver implementato l’algoritmo per recuperare i dati necessari è possibile procedere con lo sviluppo del bundle VirtualPowerMeter. Per prima cosa, dopo aver creato il plug-­‐in project, viene definita l’interfaccia VirtualDevicesInterface. L’interfaccia, come mostrato in figura 4.4, dichiara tre metodi: getInputMeasure(), getOutputMeasure() e getResult(), rispettivamente per leggere e visualizzare i valori di potenza dei due meter e del risultato della loro differenza. Figura 4.4: VirtualDevicesInterface. La classe concreta che implementa VirtualDevicesInterfaces è VirtualDevicesManager. La classe VirtualDevicesManager oltre ai classici metodi di un bundle activate e deactivate, utili essenzialmente in fase di debug, contiene l’implementazione dei tre metodi dell’interfaccia, riportata in figura 4.5. I metodi, come anticipato prima, fanno una chiamata a WolfUtil.getPower per leggere il valore della misura di potenza dei dispositivi. getInputMeasure() e getOutputMeasure() sono essenzialmente uguali, con la differenza che leggono e visualizanno la misura di potenza dei due diversi dispositivi. getResult() invece legge le due misure, ne fa la differenza e visualizza il risultato; entrambi vengono prima correttamente formattati. 30 Figura 4.5: VirtualDevicesManager Ora, dopo aver installato il bundle sul gateway, aprendo il browser e immettendo l’url identificatico dell’interfaccia web Dog (indirizzo:porta/admin/ui/index.html), ciò che verrà visualizzato, nella sezione Virtual Devices, è riportato in figura 4.6. Figura 4.6: Virtual Power Meter 31 4.3 Future applicazioni Ora che è stato realizzato il modulo che visualizza la potenza virtuale è lecito chiedersi come questo utile indicatore sul consumo di un ambiente domotico possa essere sfruttato. Prendendo in considerazione il caso in cui il la potenza virtuale ha segno positivo, overo che si sta consumando di più di quello che si sta producendo, si potrebbe fare in modo, tramite appositi algoritmi, di comandare lo spegnimento di un determinato elettrodomestico (o comunque suggerire all’utente di farlo). Un caso ancor più interessante è quando la potenza virtuale ha segno negativo, ovvero quando si sta producendo di più di quello che si sta consumando. Le strade da percorrere sono molteplici: una soluzione può essere quella di immettere l’energia prodotta nella rete (come nelle smart grid); la rete immessa viene così venduta. Questa soluzione è comunque poco conveniente per il fatto che il prezzo di vendita da parte del singolo utente è decisamente inferiore al prezzo di acquisto. Una soluzione invece decisamente innovativa potrebbe essere quella, con la potenza in “esubero” fornita dai pannelli fotovoltaici, di andare a comandare in modo automatico un circuito come quello mostrato in figura 4.8 in modo tale da scaldare una resistenza all’interno di un boiler; così facendo l’energia disponibile non viene nè sprecata né venduta ma trasformata in acqua calda la quale può essere facilmente accumulata e utilizzata dall’utente anche nei momenti della giornata in cui l’impianto fotovoltaico non produce nulla. Figura 4.7: Schema di possibili applicazioni del VirtualPowerMeter 32 4.4 Conclusioni Il plug-­‐in Virtual Power Meter si è dimostrato funzionante e in linea con le richieste del committente, vale a dire Ecodhome. A partire dal modulo implementato sono stati individuati possibili sviluppi futuri: attualmente il Virtual Power Meter è strettamente dipendente dai due dispositivi che forniscono i valori di potenza. In accordo con l’azienda che sviluppa questo software, Sysman, si è individuata particolare criticità in tale aspetto: l’utente, infatti, dovrà poter configurare il proprio dispositivo virtuale, scegliendo i dispositivi fisici da cui prelevare le informazioni. L’utente dovrà poi anche poter decidere la funzione da associare al particolare dispositivo virtuale, per esempio somma, sottrazione ecc. Infine, come preannunciato nella sezione precedente, Virtual Power Meter dovrà costituire un punto di partenza per lo sviluppo di algoritmi che, in base al segno della potenza virtuale, prendano decisioni che possano incidere positivamente sul consumo o suggeriscano, all’utente, in modo gentile, di farlo. 33