Università Politecnica delle Marche
Scuola di Dottorato di Ricerca in Scienze dell’Ingegneria
Curriculum in Ingegneria Informatica, Gestionale e dell’Automazione (IIGA)
----------------------------------------------------------------------------------------
Modellazione e simulazione di sistemi
domotici per la gestione dell'energia
Ph.D. Dissertation of:
Riccardo Donnini
Advisor:
Prof. Giuseppe Conte
Curriculum supervisor:
Prof. Sauro Longhi
V 1.0 edition
Università Politecnica delle Marche
Dipartimento di Ingegneria dell’Informazione
Via Brecce Bianche — 60131 - Ancona, Italy
A Sara, Paola e Franco
Ringraziamenti
Ringrazio tutti coloro che mi hanno supportato nell’esaltante esperienza che ho vissuto in
questo dottorato.
Desidero ringraziare il Prof. Conte e il Prof. Scaradozzi per il significativo contributo che
mi hanno dato nell’accrescere la mia curiosità nella ricerca e per avermi spronato sempre a
vedere oltre gli obiettivi più immediati.
Un ringraziamento va inoltre ai miei colleghi che mi hanno accompagnato in questo
percorso e con i quali ho imparato a costruirmi un futuro.
i
ii
Indice
1.
Introduzione ......................................................................................... 1
2.
Il problema energetico in ambito residenziale .................................. 3
2.1 Le risorse ......................................................................................... 3
2.2 Utilizzatori energetici ...................................................................... 3
2.3 Produttori e Accumulatori energetici .............................................. 4
2.4 Simulazione come strumento di analisi .......................................... 4
2.4.1
Descrizione dello scenario ....................................................... 5
3.
Metodologie di modellazione .............................................................. 7
3.1 I sistemi multi agente ...................................................................... 8
3.2 Modellazione UML ....................................................................... 10
3.2.1
Diagramma delle classi .......................................................... 12
3.2.2
Diagramma di stato ................................................................ 15
3.3 Elementi a stati finiti e Statechart ................................................. 17
3.4 BEHAVIOR: utilizzatori e produttori energetici .......................... 19
3.4.1
Elettrodomestico .................................................................... 19
3.4.2
Provider energetici ................................................................. 20
4.
Costruzione struttura del sistema .................................................... 23
4.1 Reti di Petri ................................................................................... 23
4.2 Componenti elementari ................................................................. 26
4.3 Fusione tra Petri Net ..................................................................... 30
4.3.1
Inserimento di vincoli locali .................................................. 31
4.3.2
Algoritmo di Fusione ............................................................. 33
4.4 Agenti generici .............................................................................. 39
5.
Ambiente di simulazione proposto ................................................... 41
5.1 Progettazione dell‟ambiente di simulazione. ................................ 41
5.2 Accoppiamento tra elettrodomestici virtuali e smart plug ............ 43
5.3 Strategie di controllo ..................................................................... 48
5.3.1
Gestione potenza istantanea ................................................... 48
i
5.3.2
5.3.3
Stima e gestione delle taglie energetiche ................................56
Massimizzazione autoconsumo ..............................................65
6.
Software di Simulazione/Emulazione ...............................................69
6.1 Gestione potenza istantanea e taglia energetica .............................70
6.1.1
Costruzione dell‟ambiente di simulazione in LabVIEW ........71
6.1.2
Gestione potenza istantanea ...................................................79
6.1.3
Stima e gestione delle taglie energetiche ................................81
6.1.4
Scheduling comportamento abitanti .......................................83
6.1.5
Interfaccia utente ....................................................................87
6.1.6
Avvio di una simulazione/emulazione ...................................90
6.2 Massimizzazione autoconsumo .....................................................93
6.2.1
Strumento di dimensionamento ..............................................95
6.3 Integrazione/Comunicazione tra elettrodomestici reali e simulati.97
7.
Validazione ..........................................................................................99
7.1 Elettrodomestico simulato .............................................................99
7.2 Gestione potenza istantanea .........................................................102
7.2.1
DW e WM senza sistema di controllo ..................................102
7.2.2
DW e WM con sistema di controllo .....................................103
7.3 Gestione stima/taglia energetica ..................................................105
7.4 Massimizzazione autoconsumo ...................................................113
8.
Collaborazioni ...................................................................................115
9.
Conclusioni ........................................................................................117
Riferimenti ................................................................................................119
A. Appendice ..........................................................................................121
A.1 Strumenti Software ..........................................................................121
Il software Umbrello UML Modeller .................................................121
LabVIEW............................................................................................122
Endevo UML Modeller ......................................................................125
A.2. Petri Net del sistema LeafHouse.....................................................128
ii
Lista delle Figure
Figura 2.1 - Assemblaggio modelli elementari ............................................. 5
Figura 3.1 - Classe UML ............................................................................. 13
Figura 3.2 - Classi: generalizzazione.......................................................... 14
Figura 3.3 - Classi: associazione ................................................................ 14
Figura 3.4 - Area di lavoro di Endevo UML Modeller ............................... 15
Figura 3.5 - Stati UML ................................................................................ 15
Figura 3.6 - State diagram UML ................................................................. 16
Figura 3.7 - Statechart in LabVIEW............................................................ 17
Figura 3.8 - BEHAVIOR di un Elettrodomestico ........................................ 20
Figura 3.9 - BEHAVIOR di un provider energetico .................................... 21
Figura 4.1 - Rete di Petri della componente PLUG .................................... 27
Figura 4.2 - Componenti BEHAVIOR e PLUG della washing machine ..... 29
Figura 4.3 - PN del Generic appliance ....................................................... 29
Figura 4.4 - PN totale dell‟impianto domotico ........................................... 30
Figura 4.5 - PM Editor tool......................................................................... 32
Figura 4.6 - Sequenza delle fasi nel modello PN di un elettrodomestico.... 33
Figura 4.7 - Vincolo imposto ....................................................................... 33
Figura 4.8 - PN 1 ......................................................................................... 34
Figura 4.9 - PN 2 ......................................................................................... 34
Figura 4.10 - PN 3 ....................................................................................... 35
Figura 4.11 - PN1, PN2 e PN3 unite ........................................................... 38
Figura 4.12 - PN di un Provider energetico................................................ 39
Figura 4.13 - Agente generico ..................................................................... 40
Figura 5.1 - Implementazione del simulatore/emulatore HAS-Sim............. 43
Figura 5.2 - Livelli della struttura dell'HAS-Sim ........................................ 45
Figura 5.3 - Struttura hardware HAS.......................................................... 47
Figura 5.4 - PN componente PLUG controllata ......................................... 49
Figura 5.5 - Statechart del controllore in LabVIEW................................... 51
Figura 5.6 - Algoritmo di intervento del contatore ENEL .......................... 52
Figura 5.7 - Interfaccia grafica relativa al controllore .............................. 53
Figura 5.8 - Creazione modello PN di un appartamento ............................ 66
Figura 5.9 - PN della LeafHouse ................................................................ 67
iii
Figura 5.10 - Inserimento vincoli Autoconsumo ..........................................68
Figura 5.11 - Sistema di controllo basato su PN .........................................68
Figura 6.1 - LabVIEW project HAS-Sim 2.8 ................................................71
Figura 6.2 - Dettaglio LabVIEW project HAS-Sim 2.8 ................................72
Figura 6.3 - Front Panel WM .......................................................................75
Figura 6.4 - Struttura BEHAVIOR/PLUG HAS-Sim 2.8 ..............................76
Figura 6.5 - Generic Appliance ....................................................................76
Figura 6.6 - PN dell'intero sistema domotico ..............................................77
Figura 6.7 - POPUP errore marcatura negativa PN...................................78
Figura 6.8 - Apertura PN con PIPE .............................................................79
Figura 6.9 - Front Panel controllore.vi riportata dalla user_interface.vi ...80
Figura 6.10 - Percentuale di taglia consumata nel mese .............................82
Figura 6.11 - Livelli dei serbatoi in percentuale .........................................82
Figura 6.12 - Semaforo di allerta superamento taglia.................................83
Figura 6.13 - AAMM_HOMEx_FAMy_WK1.xls .........................................86
Figura 6.14 - AAMM_HOMEx_FAMy_WK1.txt ..........................................86
Figura 6.15 - Interfaccia utente (user_interface.vi) .....................................88
Figura 6.16 - Interfaccia utente HAS-Sim LeafHouse .................................95
Figura 6.17 - Simulazione con parte di generazione parametrica ..............96
Figura 6.18 - Riprogettazione ricorsiva del sistema domotico ....................96
Figura 7.1 - Interfaccia WM ........................................................................99
Figura 7.2 - Statechart WM ........................................................................100
Figura 7.3 - Firma elettronica WM ............................................................101
Figura 7.4 - WM e DW senza gestione potenza istantanea ........................102
Figura 7.5 - WM e DW con gestione potenza istantanea ...........................104
Figura 7.6 - Energia consumata [Wh] .......................................................107
Figura 7.7 - Serbatoio nbase [Wh] ...............................................................108
Figura 7.8 - Serbatoio n1 [Wh] ..................................................................108
Figura 7.9 - Serbatoio n2 [Wh] ..................................................................109
Figura 7.10 - Semaforo avvertimento esaurimento taglia .........................110
Figura 7.11 - Consumo di potenza istantanea [W] ....................................110
Figura 7.12 - Firma elettronica WM e OVEN............................................111
Figura 7.13 - Produzione solare - Energia venduta - Carica batteria ......114
Figura A.1 - Schermata del software Umbrello UML Modeller ................121
iv
Figura A.2 - Esempio di Icon and Connector Pane .................................. 124
Figura A.3 - Area di lavoro di Endevo UML Modeller ............................. 126
Figura A.4 - Inserimento classi UML in un progetto LabVIEW ............... 127
Figura A.5 - Petri Net sistema LeafHouse ................................................ 128
v
Lista delle Tabelle
Tabella 7-1 ..................................................................................................101
Tabella 7-2 ..................................................................................................101
Tabella 7-3 ..................................................................................................103
Tabella 7-4 ..................................................................................................105
vi
1. Introduzione
La ricerca è rivolta allo sviluppo di sistemi per la gestione delle risorse in ambito
residenziale, tenendo presente la natura delle fonti di energia, gli obiettivi, i requisiti
dell‟utente e il livello tecnologico.
Il seguente lavoro si occupa della modellazione di sistemi domotici basata sulla teoria dei
Multi Agent Systems (MAS) inserendosi nella lavoro sviluppato dal gruppo di ricerca del
LabMACS in [1–5]. Il prodotto del lavoro è la messa a punto di un ambiente di
simulazione/emulazione complesso in grado di contenere al suo interno numerosi
componenti di un sistema domotico (consumatori/produttori di risorse). Il lavoro svolto ha
portato alla collaborazione con diversi Enti di Ricerca ed Aziende del settore (Enel, Bticino,
Indesit Company, Gruppo Loccioni).
Per un corretto processo di modellazione di un sistema domotico è necessario approfondire
gli aspetti che ne caratterizzano la struttura e gli elementi (Agenti) che la popolano. Per
quanto riguarda la struttura del modello, ci si è rifatti all‟approccio MAS che verrà usato
come impostazione preliminare. Questo approccio si presta molto bene alla descrizione di
ambienti domotici perché possiamo pensare agli elementi che li costituiscono come agenti,
ognuno dei quali ha i suoi obbiettivi e le sue necessità. Per quello che riguarda gli agenti
che popolano il modello, essi devono in primo luogo rappresentare i singoli
elettrodomestici. Per raggiungere questo obbiettivo ci si è basati su di un approccio UML,
che ha consentito di andare a concentrare all‟interno delle descrizioni informazioni
eterogenee, quali quelle di Agenti che possono essere anche molto differenti gli uni dagli
altri. Poiché durante il processo di sviluppo dell‟ambiente è necessario confrontarsi con
un‟ampia varietà di strumenti, tecnologie e livelli tecnici dei collaboratori, l‟UML ci
consente di formalizzare rappresentazioni che rimangono valide e significative in contesti
diversi.
Gli agenti che in questo lavoro vengono modellati sono oggetti ibridi, caratterizzati da una
dinamica a stati finiti, che rappresenta il loro comportamento, e una componente descritta
da una Petri Net (PN) che descrive la loro interazione con la fonte energetica.
Successivamente, con un processo di costruzione che coinvolge la componente PN, è
possibile definire una struttura più complessa in grado di definire il modello di utilizzo
della risorsa da parte degli agenti che porterà alla definizione dell‟infrastruttura del sistema
domotico.
Nel dettaglio il lavoro si articola partendo da un approfondimento della teoria dei MAS
applicata agli Home Automation Sytems per poi spostarsi alla teoria dell‟UML, necessaria
per formalizzare il modello comportamentale degli agenti. Si passerà poi alla descrizione
della parte che caratterizza l‟interazione che ogni agente ha con la risorsa utilizzando le PN
(prelevando energia dalla rete nel caso degli elettrodomestici).
Per rendere le simulazioni più aderenti all‟ambiente reale simulato è stato inserito un
completo scheduling di avviamento di elettrodomestici con lo scopo di modellare il
1
comportamento degli abitanti, utilizzatori dei sistemi domotici simulati. Successivamente
verrà descritto il processo di implementazione dell‟ambiente di simulazione attraverso
l‟integrazione di diversi strumenti software (Matlab/LabVIEW).
Il monitoraggio degli andamenti energetici e l‟implementazione di strategie di controllo atte
a rispettare i vincoli del sistema sono il passaggio successivo. I vincoli a cui si fa
riferimento sono la quantità limitata di risorse, quali la massima potenza istantanea (W) e
l‟energia (Wh della taglia mensile) disponibili o ulteriori specifiche che si vuole che il
sistema rispetti.
Per verificare la validità dell‟ambiente verranno portati come esempio di sistemi di
controllo il mantenimento del consumo istantaneo sotto un certa soglia e la
stima/mantenimento della taglia energetica minima necessaria agli abitanti sulla base dei
loro comportamenti.
Il processo di modellazione si conclude con l‟inserimento di provider energetici di diversa
natura: rete elettrica, fotovoltaico e accumulo su batteria. Anche questi Agenti sono
caratterizzata da una componente a stati che descrive il loro comportamento (e.g. storico
dell‟irraggiamento solare nel caso di pannelli) e una parte PN che modella la loro
interazione con la risorsa energetica (immettendo energia nella rete). Viene poi mostrato
come il ruolo della componente PN possa passare da semplice sistema di monitoraggio a
sistema di controllo attivo, attraverso l‟implementazione di una politica di autoconsumo
delle risorse generate (attento design della PN stessa con inibizioni e posti monitor che
vincolino l‟evoluzione della rete da uno stato all‟altro). L‟ambiente costruito è stato in
seguito arricchito permettendo l‟integrazione al suo interno anche di agenti domotici reali
oltre che simulati, per la necessità di trasformarlo in un ambiente di emulazione. Il software
di simulazione/emulazione verrà descritto all‟interno del contesto delle collaborazioni e
consulenze in cui è stato realizzato.
Il lavoro si conclude con la descrizione della sua ultima configurazione, nella quale è stato
possibile utilizzare il sistema di simulazione/emulazione sviluppato anche come strumento
di dimensionamento delle risorse permettendo di scegliere diverse dimensioni del sistema
di accumulo elettrico e del sistema fotovoltaico per rispondere alla richiesta energetica del
sistema.
2
2. Il problema energetico in ambito
residenziale
2.1
Le risorse
In ambito domestico residenziale il problema più diffuso di carattere energetico è quello
relativo alla limitatezza delle fonti energetiche messe a disposizione dei vari provider locali
e nazionali.
Le risorse energetiche si possono dividere in due categorie principali:
 Risorse degradabili
 Risorse non degradabili
Le risorse degradabili sono quelle che non vengono mai a mancare, ma che in caso di
eccesso di richiesta da parte degli utenti della casa, possono variare le loro caratteristiche
degradando e allontanandosi dalla loro condizione ideale. Risorse di questo tipo possono
essere la pressione dell‟acqua, la temperatura dell‟acqua, la pressione del gas. Infatti tutte le
risorse elencate, se soggette ad una richiesta eccessiva da parte dell‟utente, degradano (e.g.
se l‟acqua calda idealmente viene fornita dalla caldaia a 60 °C, sottoposta ed un‟eccessiva
richiesta dell‟utente scende di temperatura, causa l‟incapacità della caldaia di riscaldare alla
temperatura richiesta un flusso d‟acqua troppo elevato).
Le risorse non degradabili sono quelle invece che mantengono intatte le loro qualità anche
all‟aumentare della loro richiesta. Queste risorse però sono soggette ad una diversa
limitazione, cioè se la richiesta da parte dell‟utente è troppo elevata il provider può
interromperne l‟erogazione (e.g. fornitura elettrica).
E‟ proprio questo secondo tipo di risorsa che verrà presa in esame in questa tesi ed in
particolare proprio la risorsa elettrica.
2.2
Utilizzatori energetici
L‟ambiente domotico preso in esame sarà quello domestico residenziale. In questo contesto
i principali utilizzatori della risorsa energetica sono gli elettrodomestici (lavatrice, forno,
lavastoviglie, frigorifero), l‟illuminazione e la diretta utenza degli abitanti (TV, phon,
ecc...).
3
Non verrà incluso tra gli utilizzatori un sistema di riscaldamento/condizionamento elettrico,
ma come verrà mostrato in questo e nei successivi capitoli, l‟estensione dell‟ambiente di
simulazione con l‟inserimento di altri utilizzatori sarà un procedura del tutto identica a
quella che verrà mostrata per modellare ed inserire uno degli elettrodomestici che verranno
tratti.
Ogni utilizzatore energetico è inevitabilmente connesso all‟utente che lo gestisce e lo
utilizza. Per questo motivo verrà data una particolare importanza all‟utente, abitante
dell‟ambiente domestico che verrà analizzato volta per volta.
E‟ per questo motivo infatti che verrà descritto nei successivi capitoli anche uno strumento
in grado di emulare il comportamento di un utente o una famiglia (gruppo di utenti) che
abiti il contesto domotico.
2.3
Produttori e Accumulatori energetici
Dall‟introduzione dei primi sistemi fotovoltaici fino ai più recenti contratti con i provider
energetici per la vendita di energia elettrica prodotta anche in abito residenziale sono
diventati sempre meno rari contesi in cui all‟interno delle abitazioni convivono tra loro non
solo elettrodomestici o apparati che consumano energia, ma anche veri e proprio generatori
energetici in grado anche di soddisfare completamente le necessità energetiche della casa.
Per poter gestire anche produzioni energetiche fotovoltaiche che eccedono le necessità delle
abitazioni, vengono commercializzati dei sistemi di accumulo che permettono di
immagazzinare l‟energia prodotta in eccesso per poterla utilizzare in un secondo momento,
quando la produzione fotovoltaica non è più sufficiente (e.g. la notte).
Entrambi questi sistemi energetici verranno trattati assieme ai più diffusi utilizzatori di
energia e verranno integrati con la stessa filosofia all‟interno del sistema di simulazione che
verrà proposto.
Verrà adesso approfondito il concetto di simulazione e introdotto il suo utilizzo come
strumento di analisi.
2.4
Simulazione come strumento di analisi
Per poter riunire in un unico contesto tutti gli elementi fino ad adesso descritti e poter
osservare le loro interazioni (anche su archi temporali lunghi – mesi) in brevi periodi si è
scelto di creare un ambiente di simulazione che potesse essere modellato allo scopo
prefisso.
4
E‟ stato scelta la simulazione come strumento di analisi poiché permette di prevedere e
mettere in evidenza i comportamenti, anche molto complessi, di un gruppo di sotto sistemi
(singolarmente facilmente modellabili).
Essendo il panorama commerciale degli utilizzatori/generatori/accumulatori di energia
molto vasto e in continua evoluzione, si è voluto creare un ambiente di simulazione in
grado di accogliere (dopo un processo regolamentato di trasposizione da reale a virtuale) un
vasto insieme di componenti elementari (o agenti come vedremo nel capitolo 3), riuscendo
a farli interagire tra loro, simulando gli scenari in cui si possano venire a trovare e potendo
così descrivere l‟evoluzione delle loro interazioni e prevedendo lo stato a cui il sistema
potrebbe giungere a seconda delle condizioni iniziali e ai vincoli imposti.
Sarà infatti possibile, come vedremo nel capitolo 6, simulare intere mensilità di consumi e
generazioni energetiche, in pochi minuti, trasformando la simulazione in uno strumento di
analisi, in grado di fornire risposte su ciò che accadrebbe nello scenario domestico simulato
nel caso in cui le condizioni iniziali, l‟insieme di agenti e i vincoli imposti al sistema,
rimangano gli stessi rispetto a quelli della simulazione.
2.4.1 Descrizione dello scenario
Disponendo di una banca dati di modelli di elettrodomestici o sistemi domotici
formalmente descritti allo stesso modo è possibile descrivere in pochi passi e in modo
generico ambienti domotici anche complessi, il cui comportamento sarà aderente a quelli
reali.
Figura 2.1 - Assemblaggio modelli elementari
5
Lo strumento software, che nei prossimi capitoli verrà descritto, permetterà l‟integrazione
in un unico ambiente di elettrodomestici reali e simulati, facilitando le fasi di progettazione
di una rete domestica. Sarà mostrato come uno strumento così configurato possa essere
d‟ausilio sia all‟integrazione di nuovi elementi all‟interno di una rete domestica già
esistente , sia al monitoraggio, valutazione ed estensione della rete stessa.
6
3. Metodologie di modellazione
Le varie componenti di un sistema complesso come quello dell‟ambiente domestico come l'elettrodomestico, l'audio / video sottosistemi per l'intrattenimento domestico e per la
sicurezza, il sottosistema di illuminazione - richiedono una specifica quantità variabile di
energia durante il loro normale ciclo di lavoro e, in presenza di vincoli che limitano la
disposizione energia, ciascun apparecchio ha bisogno di cooperare con gli altri al fine di
massimizzare l'efficienza. Questa è una struttura che può essere approssimata con un
sistema di controllo parzialmente distribuito, i cui componenti sono autonomi, in possesso
di un certo grado di intelligenza, ma che condividono obiettivi comuni.
Ci riferiamo a tutto il sistema con la sigla HAS (Home Automation System). La casa
viene dotata di intelligenza non perché vi sono installati sistemi intelligenti, ma perché il
sistema intelligente di cui è dotata è capace di controllare e gestire in modo efficace il
funzionamento degli impianti presenti. Di pari passo con le tecnologie si sono sviluppati
sistemi domestici sempre più evoluti, al cui interno i dispositivi sono in grado di cooperare
tra loro, scambiarsi informazioni grazie anche alle nuove tecnologie di comunicazione. In
questo modo si sono creati degli ambienti domotici sempre più evoluti e complessi. Per
riuscire a seguire questa evoluzione ed applicare delle strategie di controllo e gestione della
casa in vari scenari e ambienti, è nata la necessità di definire dei modelli degli
elettrodomestici che li popolano in modo tale da poter essere inseriti in dei simulatori di
ambienti domotici in grado di affrontare tale complessità.
Quando la teoria dei sistemi risulta difficilmente applicabile, o per la crescente
complessità delle strutture o perché servono dei dati di valutazione, tipo i benefici introdotti
e i sacrifici economici da affrontare: una soluzione può essere fornita dalla simulazione al
computer. L‟approccio seguito per la realizzazione del simulatore HAS-Sim è stata quella
di descrivere i fenomeni complessi, presenti in natura, piuttosto che con modelli classici ad
equazioni differenziali, attraverso la trasposizione in moduli software delle regole applicate
ai costituenti del sistema stesso. Si sviluppa secondo queste regole il simulatore HAS-Sim,
il quale si basa su una filosofia di programmazione multitasking. Il simulatore è costituito
da più nuclei software indipendenti che lavorano in maniera concorrente seguendo una
logica di tipo produttore/consumatore. Si può affermare che nel caso particolare del
simulatore HAS-Sim sia composto da nuclei indipendenti, come elettrodomestici o
generatori energetici, che condividono/producono risorse comuni. In questo capitolo
verranno descritte le teorie di modellazione che permetteranno la creazione dei modelli
degli elementi da inserire nell‟ambiente di simulazione.
7
3.1
I sistemi multi agente
Verrà adesso proposto come sia possibile utilizzare la teoria dei sistemi multi agente
(MAS - Multi Agent System) nell‟analisi e studio di un HAS (Home Automation System),
con riferimento al primo approccio svolto [1].
Nelle case moderne, gli apparecchi e dispositivi che possono essere inclusi in un sistema di
automazione domestica sono dotati di sistemi di controllo individuale che, in un modo più o
meno sofisticati, gestiscono il proprio comportamento, possibilmente utilizzando
informazioni e dati che essi acquisiscono esternamente in qualche modo o che scambiano
tra di loro. Oggi, i sistemi di automazione sono concepiti per regolamentare l'uso
contemporaneo di risorse limitate, come l'energia elettrica o acqua calda, e per agevolare la
gestione ottimale delle risorse o in confort dell‟utente, a secondo delle configurazioni. Da
questo punto di vista, un sistema domotico può approssimativamente essere considerato
come un sistema di controllo parzialmente distribuito, le cui componenti sostanzialmente
autonome, in possesso di un certo grado di intelligenza, in grado di condividere risorse e
alcuni obiettivi comuni e comunicare tra di loro. Risulta però ancora difficile determinare le
caratteristiche chiave di un sistema di automazione e definire i criteri generali per la
valutazione delle sue prestazioni, con l‟obbiettivo di migliorarlo. L'idea di base è un
formalismo che deriva dalla teoria Multi Agent System che può, in linea di principio,
rispondere a queste esigenze, fornendo un quadro concettuale potente e una serie di
strumenti metodologici appropriati per far fronte alla complessità.
In un MAS, alcuni agenti autonomi interagiscono per svolgere compiti specifici ed
eventualmente si trovano a competere per le risorse in un ambiente che possono essere
modificate dalla loro azione. In generale, una strategia di coordinamento e collaborazione è
necessaria per risolvere i conflitti e per assicurare delle performance complessive
soddisfacenti.
Queste caratteristiche rendono il paradigma MAS particolarmente adatto per la gestione dei
sistemi la cui complessità è dovuta principalmente dall'interazione tra i vari componenti. Da
questo punto di vista, la descrizione generale di un sistema domotico si sposa bene con il
paradigma MAS. Gli elettrodomestici possono essere visti come agenti autonomi, le cui
singole mansioni consistono nel portare a termine i loro cicli di funzionamento, la
condivisione delle risorse, come l'elettricità, acqua e gas, che sono (tutti o in parte) limitati
e forse non sufficienti a soddisfare tutti gli operatori al momento della richiesta. Le risorse
devono essere ripartite in base alle priorità stabilite, tenendo conto che i ritardi nello
svolgimento di compiti specifici possano incidere sul grado di soddisfazione degli utenti e
sul risparmio delle risorse.
In un HAS, come specificato nel capitolo 2, si considera la presenza di diversi componenti
(gli elettrodomestici) che agiscono come agenti autonomi, di diverse risorse disponibili
(energia elettrica, acqua fredda e gas) e di un numero di obiettivi comuni (risparmio
energetico, la soddisfazione dell'utente, la sicurezza, e così via), ottenendo un quadro
globale che si adatta bene con la trattazione dei Multi Agent Systems (MAS). La teoria dei
8
MAS è ampiamente usata in vari settori dell'informatica, dell'automazione
e della robotica e, sulla base della nostra precedente osservazione, sarà utilizzato
qui per formalizzare la nozione di HAS. Prima di entrare nei dettagli di una definizione
formale, tuttavia, è utile sottolineare alcuni punti. La struttura di un HAS, merita di essere
studiata, almeno, su due livelli:


A livello globale, che riguarda il comportamento generale e le prestazioni del
sistema;
A livello locale, che riguarda il modo in cui i singoli componenti e dispositivi sono
integrati nel sistema.
In altre parole, si mira ad ottenere una collezione di componenti, che possono essere
genericamente chiamato agenti, e un'architettura globale, che definisce l'ambiente in cui
interagiscono gli agenti e le modalità di interazione. Da questo punto di vista, uno HAS
si qualifica come un Multi Agent System.
La teoria dei sistemi multi agente è stata sviluppata per modellare e studiare diverse
situazioni caratterizzate dalla presenza di agenti autonomi che interagiscono e possono
competere in diverso modo e in molte aree dell‟informatica, robotica e automazione. In
questo approccio, gli agenti rappresentato entità virtuali o fisiche che popolano un ambiente
reale domotico. Secondo la teoria multi agente, gli agenti sono caratterizzati in base alle
loro capacità [4], [6]:

Definizione 1: un agente è un‟entità virtuale o fisica che è in grado di:
1.
2.
3.
4.
5.
6.
7.
8.
Svolgere specifiche azioni in un dato ambiente;
Percepire gli elementi dell‟ambiente;
Costruire un modello parziale dell‟ambiente;
Usare risorse personali e ambientali;
Dirigere le proprie azioni verso specifici obiettivi;
Comunicare direttamente con altri agenti all‟interno dell‟ambiente;
Offrire servizi agli altri agenti;
Governare le proprie azioni in accordo con le proprie possibilità, limiti, obiettivi,
conoscenza dell‟ambiente e risorse disponibili.

Definizione 2 : un oggetto domotico è un agente generico, secondo la definizione
1, che possiede almeno le capacità generali 1, 4, 5 e 8, mentre per quanto riguarda
9
la capacità 6, è in grado di comunicare con altri agenti circa le risorse del sistema a
cui appartengono.

Definizione 3: un agente domotico è un oggetto domotico che in aggiunta possiede
la capacità 3 . Un agente domotico cognitivo possiede anche la capacità 3.

Definizione 4: un HAS (Home Automation system) consiste di:
1.
2.
3.
4.
5.
Un set GR di risorse globali;
Un set DO di oggetti domotici;
Un set DA di agenti domotici, sotto gruppo di DO;
Una rete di informazioni che connette gli oggetti e agenti domotici;
Un set R di ruoli, che governano il singolo comportamento, le operazioni
concorrenti degli oggetti domotici e riguarda:
a. L‟uso e trasformazione delle risorse esterne;
b. Comunicazione;
c. Percezione e conoscenza;
6. Un set L di operazioni, chiamate leggi, che descrive l‟evoluzione temporale
dell‟intero sistema in accordo con il comportamento individuale degli oggetti e
degli agenti.
Dalle definizioni precedenti è possibile descrivere i modelli dei dispositivi come un set di
DO e DA e come integrarli all‟interno di una struttura HAS. La simulazione in un tale
ambiente permette inoltre di investigare sugli effetti delle politiche di allocazione delle
risorse sull‟intero sistema e il comportamento dell‟HAS.
L‟evoluzione temporale e il comportamento dell‟ HAS, formalmente descritto dalla
Definizione 1, è completamente determinato dalle leggi L e dipende in particolare dalle
regole che costituiscono l‟ insieme R. È possibile quindi studiare l‟evoluzione globale e il
comportamento del sistema, valutando gli indici di performance e il grado di soddisfazione
dell‟utente.
3.2
Modellazione UML
Quello che si vuole fare con la progettazione ad alto livello è di svincolarsi completamente
(o quasi) dalle caratteristiche del linguaggio di programmazione, cercando un maggiore
distaccamento tra la fase di progettazione e la fase di realizzazione a basso livello di
10
programmazione. Utilizzando invece un linguaggio ad un più alto livello di progettazione si
vuole ottenere un maggiore livello di astrazione ed efficienza, versatile ed aperto verso altri
utenti, ottenendo in questo modo i seguenti benefici:



il linguaggio ad alto livello fornisce dei tempi di sviluppo molto contenuti;
la distanza concettuale fra l‟analisi e l‟implementazione si riduce, con conseguente
riduzione del rischio di un‟ errata traduzione delle specifiche in codice;
gli errori logici si individuano più facilmente, essendo espressi nella logica del
dominio del problema.
Si è così deciso di portare la fase di progettazione, il design del simulatore ad un livello
ancora più alto, in grado di usufruire in questo modo dei benefici che ne conseguono.
È stato così scelto come strumento di analisi e progettazione del software il linguaggio
UML. Nel mondo delle applicazioni Object Oriented in continua evoluzione, diviene
sempre più difficile costruire e gestire applicazioni di alta qualità in tempi brevi.
Come risultato di tale difficoltà e dall‟esigenza di avere un linguaggio universale per
modellare dei sistemi sempre più complessi e poter essere utilizzato da ogni industria
produttrice di software, fu inventato il linguaggio UML, la cui sigla sta per Unified
Modeling Language ([7], [8]).
L'UML è, dunque, un metodo per descrivere l'architettura di un sistema in dettaglio.
La forza dell‟UML consiste nel fatto che il processo di disegno del sistema può essere
eseguito in modo tale che i clienti, gli analisti, i programmatori e qualunque altro utente sia
coinvolto nel sistema di sviluppo possa capire ed esaminare in modo efficiente il sistema e
prendere parte alla sua costruzione in modo attivo.
Elenchiamo, qui di seguito, alcuni dei benefici derivanti dall'utilizzo del linguaggio UML:
1. Il linguaggio UML ci permette di disegnare professionalmente e documentare il
sistema ancor prima che ne sia scritto il relativo codice, da parte degli sviluppatori.
Si sarà così in grado di conoscere in anticipo il risultato finale del progetto su cui
si sta lavorando.
2. Poiché, come detto, la fase di disegno del sistema precede la fase di scrittura del
codice, ne consegue che la scrittura del codice stessa è resa più agevole ed
efficiente oltre al fatto che in tal modo è più facile scrivere del codice riutilizzabile
in futuro. I costi di sviluppo, dunque, si abbassano notevolmente con l'utilizzo del
linguaggio UML.
3. È più facile prevedere e anticipare eventuali bachi nel sistema. Il software che si
scrive, si comporterà esattamente come ci si aspetta.
4. L'utilizzo dei diagrammi UML permette di avere una chiara idea, a chiunque sia
coinvolto nello sviluppo, di tutto l'insieme che costituisce il sistema. In questo
11
modo si potranno sfruttare al meglio anche le risorse hardware in termini di
memoria ed efficienza, senza sprechi inutili o, al contrario, rischi di sottostima dei
requisiti di sistema.
5. Grazie alla documentazione del linguaggio UML diviene ancora più facile
eseguire eventuali modifiche future al codice. Questo, ancora, a tutto beneficio
dei costi di mantenimento del sistema.
La comunicazione e l'interazione tra tutte le risorse umane che prendono parte allo sviluppo
del sistema è molto più efficiente e diretta. Parlare la stessa "lingua" aiuta ad evitare rischi
di incomprensioni e quindi sprechi di tempo.
Il linguaggio UML contiene svariati elementi grafici che sono messi insieme durante la
creazione dei diagrammi. Poiché l'UML è un linguaggio, esso utilizza delle regole per
combinare gli elementi del linguaggio nella creazione dei diagrammi. L'obiettivo dei
diagrammi è così quello di costruire molteplici viste di un sistema, tutte correlate tra di loro.
Il software che è stato utilizzato per le rappresentazioni di diagrammi UML in fase di
progettazione del modello comportamentale degli agenti è Umbrello UML Modeller [9],
tale software è il suo funzionamento verranno brevemente approfonditi in Appendice A.1
Strumenti Software - unendosi ad altri software e tool utilizzati di cui verrà fatta una
panoramica.
Si passano ora in rassegna i diagrammi UML che saranno utilizzati nel seguito per la
modellazione degli oggetti relativi all‟ambiente di simulazione in esame. Nel nostro caso
d‟esame l‟attenzione sarà focalizzata esclusivamente sui diagrammi dei casi d‟uso, delle
classi e di stato, sufficienti per descrivere l‟ambiente e modellare l‟interazione tra gli
oggetti che ne fanno parte.
Riportiamo di seguito una breve descrizione dei diagrammi in esame:
3.2.1 Diagramma delle classi
Come prima cosa si fornisce la definizione di oggetto: indica un dato che può essere
descritto da un insieme di attributi, che può essere manipolato da appropriate operazioni
(metodi) e che è in relazione con altri oggetti. Ogni istanza di un oggetto deve essere
identificato in modo univoco, inoltre istanze dello stesso tipo possono essere raggruppate in
classi.
Una classe definisce gli attributi e i metodi di un insieme di oggetti. Tutti gli oggetti di
questa classe (istanze di questa classe) condividono lo stesso comportamento, e hanno lo
stesso insieme di attributi (ogni oggetto ha il suo insieme).
12
In UML le classi sono rappresentate da rettangoli con il nome della classe, e possono anche
mostrare gli attributi e le operazioni della classe in due altri «scompartimenti» all'interno
del rettangolo.
Figura 3.1 - Classe UML
In UML gli attributi sono mostrati con almeno il loro nome, e possono mostrare anche il
loro tipo, il valore iniziale e altre proprietà. Gli attributi possono anche essere mostrati con
la loro visibilità:
 + sta per attributi pubblici
 # sta per attributi protetti
 - sta per attributi privati
Anche le operazioni (metodi) sono mostrate con almeno il loro nome, e possono mostrare
anche i loro parametri e i tipi restituiti. Le operazioni possono, come gli attributi, mostrare
la loro visibilità:
 + sta per operazioni pubbliche
 # sta per operazioni protette
 - sta per operazioni private
I diagrammi delle classi mostrano le diverse classi che costituiscono un sistema e come si
relazionano una all'altra. I diagrammi di classe sono detti essere diagrammi «statici» perché
mostrano le classi, insieme ai loro metodi e attributi oltre alle relazioni statiche tra loro. Le
relazioni tra le classi, si possono suddividere in:
Generalizzazione
L'ereditarietà è uno dei concetti fondamentali della programmazione a oggetti, in cui una
classe «acquisisce» tutti gli attributi e le operazioni della classe da cui eredita, e può
sostituire o modificare alcuni di loro, oltre ad aggiungere altri attributi e operazioni proprie.
In UML, un'associazione di Generalizzazione tra due classi le mette in una gerarchia
rappresentante il concetto di ereditarietà di una classe derivata da una classe di base.
In UML le generalizzazioni sono rappresentate da una linea che connette le due classi, con
una freccia sul lato della classe di base.
13
Figura 3.2 - Classi: generalizzazione
Associazioni
Un'associazione rappresenta una relazione tra classi, e dà la semantica e la struttura comuni
a molti tipi di «connessioni» tra oggetti.
Le associazioni sono i meccanismi che permettono agli oggetti di comunicare tra loro.
Descrivono la connessione tra diverse classi (la connessione tra gli oggetti reali è chiamata
una connessione tra oggetti, o collegamento).
Le associazioni possono avere un ruolo che specifica lo scopo dell'associazione e possono
essere uni - o bidirezionale (indica se i due oggetti che partecipano alla relazione possono
mandare messaggi all'altro, o se solo uno di loro sa dell'altro). Ogni parte dell'associazione
ha un valore di molteplicità, che detta quanti oggetti su questo lato dell'associazione
possono relazionarsi a un oggetto sull'altro lato.
In UML le associazioni sono rappresentate come linee che connettono le classi che
partecipano alla relazione, e possono anche mostrare il ruolo e la molteplicità di ciascuno
dei partecipanti. La molteplicità è mostrata come un intervallo [minimo..massimo] di valori
non negativi, con un asterisco (*) sul lato massimo per rappresentare l'infinito.
Figura 3.3 - Classi: associazione
Una rappresentazione direttamente ricollegabile alle classe e ai loro diagrammi è resa
disponibile all‟interno dell‟ambiente di programmazione utilizzato per l‟implementazione
dell‟ambiente di simulazione dal tool Endevo UML Modeller è uno strumento di
14
modellazione di sistemi, risulta facile da usare e strettamente integrato con il software
LabVIEW.
Il tool supporta i seguenti diagrammi UML: casi d‟uso, delle sequenza, delle classi, dei
package e di stato.
Nel nostro caso specifico è di interesse il solo diagramma delle classi, che supporta la
generazione di codice partendo da una descrizione visiva. Un esempio di rappresentazione
software mostrato in Figura 3.4
Figura 3.4 - Area di lavoro di Endevo UML Modeller
3.2.2 Diagramma di stato
Uno stato UML descrive lo stato interno di un oggetto di una particolare classe. Non tutti i
cambiamenti negli attributi di un oggetto sono rappresentati da uno stato, ma solo quei
cambiamenti che influenzano significativamente il funzionamento dell'oggetto.
Ci sono due tipi speciali di stati: Inizio e Fine. Sono speciali perché non ci sono eventi che
possono far tornare un oggetto al suo stato di Inizio, allo stesso modo in cui non è possibile
riportare un oggetto dal suo stato di Fine una volta che lo raggiunge. Questi stati sono
rappresentati nel linguaggio UML come in Figura 3.5.
Figura 3.5 - Stati UML
15
Ad un determinato istante, durante il funzionamento del sistema, un oggetto si trova in un
particolare stato. I diagrammi di stato rappresentano tali stati e i loro cambiamenti nel
tempo. Ogni diagramma di stato inizia con un simbolo che identifica lo stato iniziale e
termina con un altro simbolo che rappresenta lo stato finale.
Vedremo nei successivi capitoli come questi strumenti di modellazione della teoria UML
sono stati utilizzati per la realizzazione dell‟ambiente di simulazione. Esiste infatti
nell‟ambiente LabVIEW (che è stato utilizzato per realizzare il simulatore) una
rappresentazione software sia per il diagramma delle classi (e delle classi stesse) sia per il
diagramma a stati. Degli esempi sono riportati in Figura 3.6 e Figura 3.7.
Figura 3.6 - State diagram UML
16
Figura 3.7 - Statechart in LabVIEW
3.3
Elementi a stati finiti e Statechart
Gli automi a stati finiti, o macchine a stati finiti(FSM o Finite State Machines) e le reti di
petri (Petri Nets) sono delle tecniche di modellazione di sistemi dinamici a stati discreti
(DEDS o Discrete Event Dynamic Systems), a cui sono assimilabili la maggior parte dei
processi che abbiamo l‟obbiettivo di modellare come agenti.
Gli Statechart sono una notazione grafica e formale, sviluppata da D.Harel [10] nel 1987
per descrivere il comportamento di sistemi complessi e reattivi a stimoli interni ed esterni.
Lo Statechart Diagram è un diagramma adoperato per descrivere il comportamento
dinamico di entità o di classi in termini di stato (macchina a stati). Esso mostra gli stati che
sono assunti dall'entità o dalla classe in risposta ad eventi esterni.
Negli anni ‟90 l‟UML (Unified Modeling Language, "linguaggio di modellazione
unificato") nasce con l'intento di integrare i principali formalismi in una notazione
universalmente accettabile, realizzando uno standard industriale unificato. Essa definì lo
Statechart diagram come:
“A statechart diagram can be used to describe the behaviour of a model element such as
an object or an interaction. Specifically, it describes possible sequences of states and action
17
through which the element can proceed during its lifetime as a result of reacting to discrete
events (e.g., signals, operation invocations)”.
Gli Statechart sono quindi un formalismo grafico utilizzato per modellare sistemi complessi
guidati dagli eventi.
Il problema con i classici diagrammi di stato, come ad esempio gli automi a stati finiti, era
quello di descrivere la complessità del sistema in modo chiaro e realistico, nonché adatto
per una simulazione computerizzata. Ciò che la mente umana è portata a pensare è di poter
decomporre la complessità di un sistema da una visione globale ad alto livello ad una fatta
da piccole parti, meno complesse, in modo da rendere il tutto più coerente [10]. Questo
approccio non è possibile con i diagrammi a stato, che sono grafi direzionali, formati da
stati e transizioni. Un sistema complesso modellato con questo tipo di diagrammi risulterà
poco economico a causa del numero degli oggetti utilizzati, ad esempio si potrebbe avere
un numero molto grande di stati, i quali dovranno essere inseriti in un diagramma che
risulterà caotico e non ben strutturato.
Un buon approccio stato-eventi dovrà quindi essere modulare, gerarchico, ben strutturato e
dovrà eliminare il problema dell‟incremento esponenziale degli stati durante la
composizione di più macchine. La composizione di più moduli è possibile introducendo
quindi la gerarchia, cioè la possibilità di introdurre degli stati all‟interno di altri stati,
l‟ortogonalità, cioè l‟indipendenza tra due parti del sistema concorrenti, e di conseguenza la
comunicazione tra le varie componenti concorrenti. Una possibile soluzione è l‟utilizzo del
formalismo grafico degli statechart, per :
“la descrizione degli stati e delle transizioni in una grafica modulare, che abiliti il
raggruppamento, l‟ortogonalità, il raffinamento e incoraggi le capacità di „zoom‟ per
muoversi facilmente attraverso diversi livelli si astrazione” [10].
Essendo un‟ estensione dei diagrammi a stato, riprendono da essi i concetti fondamentali di
stato, come un possibile “modo” in cui il sistema si trova e di transizione che permette il
passaggio da uno stato all‟altro.
Se per gli automi a stati finiti si rappresentano gli stati del sistema con dei cerchi e le
transizioni con degli archi orientati, la rappresentazione degli Statechart è formata da
rettangoli arrotondati per rappresentare gli stati, e da archi orientati, che rappresentano le
transizioni, che congiungono uno stato all‟altro.
Per esprimere la gerarchia tra gli stati si usa l‟incapsulamento, ovvero gli stati vengono
inseriti all‟interno di altri stati indicando che essi sono ad un livello gerarchico inferiore
rispetto allo stato che li contiene; introducendo in questa maniera i concetti di sottostati e
superstati. Il raggruppamento (clustering) serve in modo principale per semplificare la
grafica del diagramma, renderla più leggibile e allo stesso tempo adeguata al suo
funzionamento; si nota una netta diminuzione di stati e archi di transizione.
18
3.4
BEHAVIOR: utilizzatori e produttori energetici
Il problema principale legato ai sistemi domotici è quello di gestire i conflitti che sorgono a
causa di un‟eccessiva richiesta di potenza elettrica che comporta il superamento della soglia
fornita. In pratica la potenza verrà distribuita in accordo con le richieste dell‟utente in
termine di economia (il superamento della soglia comporta un costo maggiore) e comfort
(in accordo con la strategia scelta). La strategia è implementata da uno specifico agente, il
controllore, sulla base delle informazioni fornite dai sensori. L‟azione di controllo consiste
nel togliere potenza agli agenti, agendo sulle singole prese connesse. Si descrive di seguito
la struttura degli elettrodomestici come agenti, usando un modello costituito da due
comportamenti: il BEHAVIOR e la presa PLUG.
La componente PLUG è una possibile rappresentazione in ambiente di simulazione di una
smart plug collegata ad un elettrodomestico reale. La sua descrizione verrà affrontata nel
dettaglio nel capitolo 5 dove la costruzione e l‟assemblaggio del sistema saranno il
principale argomento.
Il BEHAVIOR invece può essere direttamente collegato alla rappresentazioni a stati del
sistema e in particolare del comportamento di un singolo agente.
3.4.1 Elettrodomestico
L‟elettrodomestico caratterizzato da due dinamiche time driven, connesse da uno switching.
La prima
rappresenta l‟evoluzione temporale (in un intervallo
) dei consumi di
energia relativi a ciascuna fase di lavoro dell‟elettrodomestico, quando la risorsa energia è
disponibile; mentre la seconda descrive la situazione di inibizione del dispositivo da parte
del controllore, con conseguente cut-off
dell‟energia e un consumo pari a zero
. Quando la potenza è ristabilita in un tempo , il dispositivo ristabilisce la fase di
lavoro che era stata interrotta dal cut-off e il modello passa ad un consumo pari a
. In questo caso il dispositivo finirà il suo lavoro in un tempo
, se non accade un ulteriore cut-off.
Le due dinamiche sono esclusive tra di loro e lo switching avviene quando il controllore
inibisce la presa, dopo una situazione di overload causata dagli elettrodomestici in
funzione. La prima dinamica viene nuovamente riattivata quando il controllore decide di
ripristinare la presa relativa (seguendo le sue strategie di controllo). Si riporta in Figura 3.8
una rappresentazione esplicativa del componente BEHAVIOR di un Elettrodomestico.
19
Figura 3.8 - BEHAVIOR di un Elettrodomestico
3.4.2 Provider energetici
Il BEHAVIOR di un agente che non è un consumatore elettrico, ma è un
produttore/accumulatore può avere un comportamento, che guida i sui livelli di produzione
energetica , modellato in diversi modi. Ad esempio, nel caso di un Agente che rappresenta
un appartato fotovoltaico, il suo andamento di produzione energetica più essere prelevato
da file di dati storicizzati (precedenti mensilità di irraggiamento solare) e espresso come un
comportamento andando a rendere disponibile più o meno energia prodotta dall‟agente e
immessa nella rete elettrica dal sistema domotico (Figura 3.9)
20
Figura 3.9 - BEHAVIOR di un provider energetico
Sarà proprio un agente come quello rappresentato in Figura 3.9 assieme al modello di
carica e scarica di una batteria (accumulatore energetico) ad andare a popolare la struttura
del sistema, estendendo la capacità di modellazione dell‟ambiente simulazione proposto e
permettendo di analizzare ulteriori politiche di controllo. Sarà infatti portata all‟attenzione
la necessità di massimizzare la quantità di energia auto-consumata dal sistema e una
politica di controllo adeguata verrà proposta nel capitolo 5.
21
22
4. Costruzione struttura del sistema
Con tutti gli strumenti che sono stati descritto fino ad esso è stato possibile descrivere in
modo formale e accurato il modello comportamentale degli agenti del sistema, potendo
darne una rappresentazione anche virtuale, integrabile all‟interno di un ambiente di
simulazione.
Nei precedenti capito spesso si è fatto riferimento a sistemi ai stati finiti e la
rappresentazione dei vari agenti che caratterizzano il sistema è stata prevalentemente fatta
con sistemi costituiti da un insieme finito di stati in cui il passaggio da uno stato a quello
successivo è guidato da eventi che coinvolgono il sistema.
E‟ stato analizzato il panorama delle formalizzazione dei sistemi a stati finiti, e da questa
analisi è stata identificata un formalizzazione in grado di venire in contro alle necessità di
rappresentazione, implementazione e formalità richieste dall‟obbiettivo di realizzare un
ambiente di simulazione adeguato a contenere tutti gli agenti ed elementi fino ad adesso
descritti. La rappresentazione che è stata ritenuta in grado di soddisfare tutte le specifiche
richieste sono state le Reti di Petri (Petri Net – PN) [11–13], note per essere una
rappresentazione sintetica di sistemi a stati ed essere fortemente orientate agli eventi che ne
guidano l‟evoluzione dello stato nel tempo.
Nel capitolo 3 è stato introdotto il concetto di BEHAVIOR che però è la rappresentazione
solamente di una parte dell‟Agente descritto nella sezione 3.1 poiché è privo della capicità
di interazione con gli altri agenti. Collegando il BEHAVIOR ad una rappresentazione di
smart plug, otteniamo un agente che può interagire con le risorse del sistema. La
modellazione della smart plug che verrà proposta utilizzerà la teoria delle PN per dare una
rappresentazione dell‟interazione tra gli elettrodomestici e modellare la condivisione di una
risorsa comune.
Andando in seguito a unire tra loro gli agenti così descritti, riusciremo a costruire la
struttura del sistema globale.
4.1
Reti di Petri
Per la costruzione di un agente avente accesso alle risorse del sistema è stato adoperato
anche un altro strumento, le reti di Petri. Esso ci ha permesso di monitorare l‟andamento
dell‟intero sistema, controllando le operazioni imposte dalla strategia di gestione
energetica.
Le Reti di Petri , sono state adoperate come strumento di controllo supplementare per le
decisioni intraprese dalla logica implementata.
Nel simulatore si utilizzano due tipi di controllo:
 Controllo sulla marcatura
 Controllo sulla matrice d‟inibizione
23
Il primo controllo permette di verificare che la marcatura non sia negativa, perché in tal
caso vorrebbe dire che il controllore ha richiesto di effettuare un‟operazione non consentita
dalla rete utilizzata. Un esempio potrebbe essere la restituzione di potenza, da parte di un
elettrodomestico, maggiore di quella consumata. Il secondo controllo, invece, verifica, ad
esempio, che non sia concessa potenza ad un elettrodomestico inibito dalla strategia di
controllo attuata.
Una rete di Petri (conosciuta anche come rete posto/transizione o rete P/T) è una delle varie
rappresentazioni matematiche di un sistema distribuito discreto. Come un linguaggio di
modellazione, esso descrive la struttura di un sistema distribuito come un grafo
bipartito con delle annotazioni. Ovvero, una rete di Petri ha dei nodi posti, dei nodi
transizioni e degli archi diretti che connettono posti e transizioni. Le reti di Petri furono
inventate nel 1962 da Carl Adam Petri durante la sua tesi di dottorato.
Una rete di Petri PT (Place/Transition) consiste di posti, transizioni e archi diretti. Possono
esserci archi tra posti e transizioni - ma non tra posti e posti o transizioni e transizioni. Un
posto da cui un arco parte per finire in una transizione è detto posto di input della
transizione; un posto in cui un arco arriva partendo da una transizione è detto posto di
output della transizione. I posti possono contenere un certo numero di token o marche. Una
distribuzione di token sull'insieme dei posti della rete è detta marcatura. Le transizioni
agiscono sui token in ingresso secondo una regola, detta regola di scatto (in inglese firing).
Una transizione è abilitata se può scattare, cioè se ci sono token in ogni posto di input.
Quando una transizione scatta, essa consuma token dai suoi posti di input, esegue dei task e
posiziona un numero specificato di token in ognuno dei suoi posti di uscita. L'esecuzione
delle reti di Petri è non deterministica. Ciò significa due cose:
1. se più transizioni sono abilitate nello stesso momento, una qualsiasi di esse può
scattare;
2. non è garantito che una transizione abilitata scatti; una transizione abilitata può
scattare immediatamente, dopo un tempo di attesa qualsiasi (a patto che resti
abilitata), o non scattare affatto.
In modo più preciso possiamo dire che una Rete di Petri è un grafo orientato bipartito Grafo
bipartito
dove
è una partizione dell‟insieme dei vertici del grafo ed E
è l‟insieme degli spigoli di G, composto da coppie di vertici rispettivamente di S (i posti) e
di T (le transizioni):
.
Una Rete di Petri può anche essere rappresentata mediante una notazione matriciale, con
due matrici, di ingresso I e di uscita O, definite rispettivamente ponendo
con
spigolo
,
; dove con
e
si indica la capacità dello
24
In altri termini la colonna i-esima della matrice I rappresenta i pesi degli archi entranti nella
transizione
, mentre la riga j-esima di O rappresenta i pesi degli archi uscenti dalla
transizione
. La matrice di incidenza C di una rete è definita ponendo
. Il
vettore di marcatura m di una rete è il vettore
le cui componenti
sono il numero di token presenti nel posto i-esimo. Un‟estensione del formalismo
base delle Reti di Petri è l‟utilizzo dell‟ arco inibitore che a differenza dei tradizionali archi
condiziona l'abilitazione della transizione all'assenza di token nel posto che la precede.
Questa modifica può essere utile in fase di programmazione qualora una possibile
situazione della rete debba inibire l‟esecuzione di certe transizioni e garantire cosi in una
prestabilita evoluzione del sistema modellato.
Le Reti di Petri sono state adoperate per poter modellare l‟intera politica di gestione
energetica in quanto tramite l‟utilizzo di tre matrici (matrice d‟incidenza, Matrice
d‟inibizione, vettore delle marcature) permette di monitorare semplicemente l‟evoluzione
dell‟intero HAS tramite semplici prodotti tra matrici. Questo vantaggio consente
un‟agevole implementazione su un qualsiasi micro-controllore e quindi conferisce
leggerezza e portabilità all‟ HAS-Sim realizzato.
Per l‟apertura delle Reti di Petri che modellano l‟intero sistema, si sono adoperati due
software, Pipe e PM Editeur. Il primo è un progetto open source sviluppato in linguaggio
Java, con un‟ ottima documentazione in formato JavaDoc. L'interfaccia è molto intuitiva e
permette di disegnare diagrammi leggibili in modo semplice e rapido. E' possibile creare
archi spezzati e/o curvi per evitare intersezioni poco chiare, ruotare le transizioni e inserire
annotazioni testuali in ogni punto del diagramma. Tramite un apposito menù si può
facilmente esportare il diagramma in formato grafico (PNG oppure PostScript), che
possiamo stampare oppure includere in altri tipi di documento. La simulazione di base
prevede una modalità "animata" attivabile tramite apposito pulsante, che ci permette di
osservare l'evolversi della rete. Possiamo eseguire un'animazione "step-by-step", andando a
effettuare lo scatto di una transizione tra quelle abilitate, che vengono colorate in rosso.
Alternativamente possiamo lasciare al programma la scelta (casuale) delle transizioni da
attivare, anche in modalità continua (con un periodo di tempo selezionabile). E' sempre
possibile arrestare la simulazione e tornare ai passi precedenti, per ispezionare la rete. Il
programma ha una struttura modulare, grazie alla quale è possibile aggiungere e rimuovere
in modo semplice i componenti che effettuano analisi sulla rete. Sono presenti diversi
moduli che permettono di classificare le proprietà della rete o di effettuare un‟analisi sulle
matrici d‟ incidenza o sulla marcatura.
Il software PM Editeur invece, è un editor grafico per le Reti di Petri, che presenta
un‟interfaccia più semplice ma al tempo stesso più leggera. Esso si interfaccia
perfettamente con il programma Matlab che è in grado di importare correttamente tutte le
caratteristiche della Rete di Petri disegnata e di metterle a disposizione del controllore in
LabVIEW per mezzo di particolari strutture.
25
4.2
Componenti elementari
Utilizzando adesso il concetto di Rete di Petri descritto verrà descritta una soluzione di
modellazione adottata per dare una rappresentazione grafica e matriciale della componente
PLUG relativa ad un elettrodomestico, facendo riferimento a quanto anticipato nella
sezione 3.4.
E‟ infatti presente in ogni elettrodomestico (in questo caso faremo riferimento ai soli
consumatori di energia dal contesto domotico) una collegamento tra la rete elettrica e
l‟elettrodomestico stesso. L‟elettrodomestico e il suo modello comportamentale è già stato
descritto attraverso il concetto di BEHAVIOR e di macchina a stati. Quello che ancora non
è stato affrontato è il come il comportamento modellato possa interagire con la linea
elettrica e come questo comportamento possa influenzare gli altri elettrodomestici e come
possa essere influenzato a sua volta.
Verrà adesso ipotizzato che ogni elettrodomestico modellato sia collegato alla rete elettrica
attraverso una smart plug, in grado di misurare il consumo energetico istantanea e capace di
rispondere a dei comandi di attivazione/disattivazione (switching) provenienti da un
eventuale sistema di controllo, connettendo/disconnettendo l‟elettrodomestico stesso dalla
rete elettrica.
L‟attivazione dello switching dipende da una dinamica event driven definita dalla
componente PLUG. L‟agente quindi, che rappresenta un dispositivo domotico, consiste in
un componente BEHAVIOR collegato con un componente PLUG. Lo switching tra w(t )
e
nel BEHAVIOR dipende dallo stato delle transizioni nella PLUG, mentre la
variazione dei consumi di elettricità nel BEHAVIOR si ripercuote sulla PLUG. L‟
interazione tra il dispositivo e la risorsa potenza, descritto dalla PLUG per mezzo di una
PN, è così strutturato:
A. il consumo di energia; Un numero fisso di token nel posto “P1” rappresentano
l‟ammontare della potenza disponibile all‟agente. Variazioni sul valore
attiva sia la transizione T1 (che aumenta il consumo) che la transizione T2 (che
decrementa il consumo). La marcatura del posto “” rappresenta l‟ attuale consumo
della presa.
B. l‟abilitazione o non della presa a cui è collegato l‟elettrodomestico. L‟assenza di
un token nel posto “P2” denota che l‟elettrodomestico è connesso alla presa e
consuma potenza elettrica e in tal caso il comportamento temporale del
BEHAVIOR evolve come
. La presenza di un token invece in “P2” indica che
il dispositivo è disconnesso dalla sorgente elettrica per tale motivo il
comportamento temporale BEHAVIOR evolve come
. In questa situazione
26
la transizione “T1” che di solito è abilitata, risulta inibita dalla rete di Petri in
quanto l‟elettrodomestico è stato bloccato dal controllore. La variazione della
marcatura del posto “P2” è imposta da un eventuale sistema di controllo (un suo
modello in forma di PN)
La struttura della parte di controllo verrà per adesso mantenuta, in modo da rendere più
generale in discorso di interazione con la risorsa. Nel capitolo 5 verrà presentata una
possibile implementazione di strategia di controllo. Sarà quella l‟occasione per verificare
che la tecnica di modellazione attraverso PN e la sua funzione di strumento di interazione
tra agenti e risorsa risulta essere valido.
La rete di Petri del singolo elettrodomestico si presenta così:
A
B
Figura 4.1 - Rete di Petri della componente PLUG
In riferimento alla Definizione 1 , il modello BEHAVIOR-PLUG incorpora le capacità
1,4,5 e 8 nel primo componente (BEHAVIOR). Le capacità 6 e 2 nel componente PLUG, in
corrispondenza del posto “posto_power” e mostra lo stesso numero di token in tutte le sotto
reti A. Dal punto di vista della definizione 4, il controllore è in grado di monitorare la
marcatura del “posto_power” e di gestire lo scatto delle transizioni di ciascuna PLUG. I
ruoli sono espressi dai componenti BEHAVIOR mentre le leggi sono rappresentate dalla
struttura e dalla dinamica dei componenti PLUG. Ciascun agente presenta quindi un
componente PLUG a cui sono associate la matrice di incidenza, di Inibizione e la
Marcatura iniziale. Indicando con ci l‟ultima riga della matrice d‟incidenza C e con Ci- la
27
matrice costituita dalle prime n-1 righe di C, con i=1,…,n , la matrice d‟incidenza risulta la
seguente:
(4-1)
C1

 ...
0

 c1
... 0 

... ... 
... Cn 

... cn 
La costruzione della matrice d‟inibizione H è analoga. Per la descrizione della marcatura
M0 invece, si denota con mi l‟ultimo elemento della M0i , e con M0i- il vettore costituito
dagli n-1 elementi di M0i con i=1…n. Il valore di mi con i=N indica l‟ammontare della
potenza elettrica che è disponibile per tutti gli agenti del sistema domotico HAS, pertanto la
matrice della marcatura iniziale si presenta nel seguente modo:
(4-2)
M 01
... M 0n
N
La costruzione del BEHAVIOR di ciascun terminale è descritta invece, da una sequenza di
fasi di lavoro, con relativi consumi di energia e tempistiche, per mezzo degli strumenti
Statechart e UML. In Statechart è descritta la sequenza fissa di fasi di lavoro di ciascun
agente domotico, corrispondente ai comportamenti elementari dell‟elettrodomestico reale.
In UML (Unified Modeling Language) sono invece descritte le possibili azioni che il
dispositivo può implementare e il modo in cui esse si inseriscono tra le varie fasi di lavoro.
In pratica si costruisce un diagramma delle classi con i propri attributi e metodi e il
diagramma a stati relativo. Essi lavoreranno in background al vi (sua implementazione in
ambiente LV) del dispositivo, che ne visualizza i risultati sulla propria interfaccia grafica
(Front Panel). Si riporta di seguito un‟immagine riguardante lo Statechart della washing
machine, al cui interno sono richiamati i metodi, della classe relativa, per la scrittura e
lettura degli attributi associati alla potenza consumata e alla fase di lavoro in cui
l‟elettrodomestico opera in relazione con la componente PLUG.
28
Figura 4.2 - Componenti BEHAVIOR e PLUG della washing machine
Si ha un‟ analoga schematizzazione per gli altri elettrodomestici presenti nel sistema
domotico in questione, tranne che per il Generic appliance che presenta un struttura molto
più semplice, in quanto non viene controllato. La sua rete di Petri si riduce alla sola parte
riguardante il consumo di energia.
Figura 4.3 - PN del Generic appliance
29
Ciascun elettrodomestico possiede pertanto una sua struttura BEHAVIOR e una PLUG. La
prima appartiene al comportamento del singolo dispositivo mentre la seconda, viene
utilizzata dal controllore per attuare le strategie di consumo energia. A tal fine, è richiesta
una PN totale con cui è possibile monitorare tutti gli elettrodomestici di cui è costituito il
sistema domotico simulato. Le singole reti possono essere fuse tra loro utilizzando tecniche
di push-out che verranno descritte nei seguenti paragrafi.
Il risultato, al termine delle procedure di fusione dei singoli elementi elementari (le PLUG)
è riportato nella Figura 4.4:
Posto Power
Figura 4.4 - PN totale dell‟impianto domotico
È possibile notare come le singole PN siano state fuse insieme in modo tale da condividere
un posto chiamato Posto Power.
I token presenti nel posto Power della PN totale fusa sono 14000 e rappresentano la soglia
massima di energia a disposizione, ossia la potenza limite Plim di 14 KW, che una volta
superata porterebbe ad un distacco immediato del contatore ENEL (perdita del controllo del
sistema). E‟ infatti un caso non contemplato dal modello, poiché un consumo oltre i 14 KW
porterebbe ad una marcatura negativa della PN.
4.3
Fusione tra Petri Net
Partendo da un insieme di PN elementari che rappresentano i singoli elementi, si è pensato
che avere la possibilità di unire tra loro i modelli elementari sarebbe potuto tornare molto
30
utile. Infatti partendo da elementi semplici, la costruzione dinamica di un ecosistema di
elettrodomestici, ognuno modellato dalla sua PN, si trasforma in processo ripetitivo e di
complessità crescente, che non aggiunge alcun valore a livello di controllo o modellazione.
Avendo invece a disposizione un sistema automatico in grado di unire tra loro un numero
indefinito di PN (anche l‟una diversa dall‟altra) si apre la possibilità di una costruzione
dinamica della PN dell‟intero sistema volta per volta, a seconda del numero di agenti che in
quella particolare situazione devono andare a fare parte del sistema.
Verrà adesso descritta un‟efficiente tecnica di push-out che permetterà di creare PN
complesse a partire dai modelli elementari di PN all‟interno delle quali i vincoli di
funzionamento dei modelli sono già stati inseriti.
Verranno portate come esempio per descrivere il processo di fusione delle PN all‟interno
delle quali sono state inserite tutte le fasi di funzionamento dell‟elettrodomestico (consumo
elettrico in ogni fase). A queste PN verrà inoltre aggiunto un vincolo di funzionamento,
prima di venire unite tra loro, in modo da mostrare come ogni vincolo inserito nelle PN
elementari venga mantenuto in un PN globale dopo la fusione. Per l‟inserimento di vincoli
nel funzionamento verranno utilizzate delle Generalized Mutual Exclusion Constraints
(GMEC) [14].
Il software che permette il processo di unione tra PN è stato realizzato con uno script
Matlab [] in grado di interpretare la rappresentazione grafica come che è stata data agli
elettrodomestici. Le PN vengono caricata in Matlab andando a caricare i file salvati da un
software grafico utilizzato per disegnare le PN (PM Editor [15]).
4.3.1 Inserimento di vincoli locali
Utilizzando PM Editor è possibile costruire graficamente un PN. Questo tool mette a
disposizione una serie di funzioni Matlab in grado di importare le descrizione matriciale
delle PN. Tali funzioni sono state modificate per permettere non solo l‟importazione delle
matrici di incidenza, inibizione e marcatura di un PN, ma anche la sua struttura grafica e la
posizione nello spazio di posti e transizioni. Sono state creata inoltre anche delle funzioni
Matlab in grado di ricreare un file di un PN apribile con PM Editor a partire dalle matrici
che la caratterizzano in ambiente Matlab (ambiente nel quale possono essere elaborate).
31
Figura 4.5 - PM Editor tool
L‟inserimento di vincoli all‟interno di un PN, rappresentati le regole del sistema che si sta
cercando di modellare, è reso possibile dalla teoria delle PN in due modi:
Archi inibitori
All‟interno del tool grafico PM Editor è possibile trasformare un qualsiasi arco della PN in
un arco inibitore. L‟imposizione dei vincoli attraverso archi è rappresentato in forma
matriciale da una matrice di inibizione. Tale matrice verrà anche essa caricata in ambiente
Matlab e potrà contribuire al controllo sull‟evoluzione dello stato della PN.
GMEC
E‟ stata sviluppata in Matlab una funzione in grado di inserire dei nuovi vincoli come
GMEC traducendo ogni disequazione inserita in un posto monitor (in forma grafica e
matriciale).
Possiamo vedere in Figura 4.6 il la modellazione come PN della sequenza delle
fasi di funzionamento di un elettrodomestico.
32
Figura 4.6 - Sequenza delle fasi nel modello PN di un elettrodomestico
Se volessimo imporre il vincolo che l‟elettrodomestico non può stare allo stesso tempo in
più di una fase dovremmo rendere sempre vera la seguente disequazione:
P1 + P2 + P3 + P4 + P5 + P6 + P7 + P9 < 2
Eseguendo lo script di inserimento automatico di vincoli e passandogli come parametro la
diseguaglianza da dover rispettare otteniamo in uscita la PN in Figura 4.7:
Figura 4.7 - Vincolo imposto
4.3.2 Algoritmo di Fusione
Una della motivazioni che ha portato all‟utilizzo delle PN per la modellazione degli
componenti elementari dei sistemi domotici da simulare è la possibilità di utilizzare
l‟algebra alla base della teoria delle PN per semplificare l‟integrazione tra più sottosistemi
semplici e il mantenimento dei vincoli locali inseriti a livello di singolo elettrodomestico.
33
Come abbiamo visto è possibile descrivere ogni elettrodomestico o device domotica con
una semplice PN vincolata. Vediamo adesso come utilizzando un algoritmo implementato
in ambiente Matlab sarà possibile fondere tra loro tutte le sottoreti unendole in una PN in
grado di rappresentare l‟intero ambiente domotico. Una volta creata la PN dell‟intero
sistema sarà anche possibile inserire nuovi vincoli, richiamando in modo ricorsivo la
funzione per l‟inserimento di GMEC o semplicemente inserendo da ambiente grafico (PM
Editor) archi inibitori.
Vengo qui riportati degli i precedenti esempi di modelli in forma di PN della Lavatrice
(WM – Washing Machine) Figura 4.8, della Lavastoviglie (DW – Dishwasher) Figura 4.9
e di una generica presa elettrica Figura 4.10.:tre
Figura 4.8 - PN 1
Figura 4.9 - PN 2
34
Figura 4.10 - PN 3
Prendendo in considerazione un esempio in cui si hanno 3 PN (m=3) per andare a spiegare
come le matrici di incidenza, inibizione e i vettori di marcatura possono essere uniti tra loro
per andare a creare la PN dell‟intero sistema. La trattazione con m=3 potrà poi essere
generalizzata con un m qualsiasi.
Per ogni PN abbiamo una matrice di incidenza diversa Ci ( lavorare con le matrici di
inibizione vedremo sarà del tutto equivalente):
(4-3)
e 3 vettori di marcatura (uno per ogni PN):
(4-4)
Per poter portare a termine il processo di fusione, è necessario da lato utente andare a
definire quali posti delle diverse reti sono dei posti condivisi e con quali posti delle altre reti
devono andare a coincidere. Questa informazione deve può essere formalizzata inserendola
in degli array Cij gli elemente dei quali indicano i posti della PN “i” condividi con PN “j”.
Analizzando il contenuto di questi vettori è possibile andare ad individuare tutti i posti delle
reti che hanno una qualche condivisione con altra rete.
In numero dei vettori Cij è pari al numero “n” di combinazioni di coppie di PN senza
ripetizioni:
35
(4-5)
n
m!
2!(m  2)!
(4-6)
Utilizzando nuovamente l‟informazione contenuta nella matrici Cij verrà costruita la
matrice S nxm dove le righe identificano le PN da fondere e le colonne i posti che sono
condivisi. Ogni elementi sij rappresenta l‟indice del posto della PN “i” (i:[1,m]) che
corrisponde al posto condiviso “j” ( j: [1, n] ).
La matrice S viene utilizzata per rimuovere dalle matrici di incidenza e dai vettori di
marcatura i posti che sono stati identificati come coinvolti in una qualche condivisione. Le
matrici di incidenza Ci e i vettori di marcatura Mi dopo la rimozione dei posti condivisi
prenderanno saranno indicati dalla notazione Ci- e Mi- .
Parallelamente al processo di rimozione dei posti condivisi vengono costruite della sub
matrici di incidenza Ci, r di dimensione nxki (dove ki è il numero di transizioni, relative ad
ogni PN originale “i” da fondere). Tale matrice sintetizza al suo interno il come le
transizioni fossero collegate ai posti condivisi, prima che venissero rimossi dalle matrici di
incidenza originali:
(4-7)
Dopo aver estratto dalle relative PN i posti con qualche condivisione, si pone
immediatamente il problema di quale marcatura assegnare a tali posti una volta che
saranno reinseriti nella rete finale come posti condivisi.
La marcatura dei posti condivisi viene prelevata dalle reti che li condividono e salvata in
dei vettori Mij i quali indicano la marcatura del posto condiviso relativamente alle PN “i”
condiviso con la PN “j”:
36
(4-8)
Utilizzando i vettori Mij viene costruito il vettore Mr 1xn dove gli elementi mr,j (j:[1,n])
indica la marcature del posto condiviso “j”.
Con le matrici e i vettori descritti fino ad adesso è possibile unire tra loro le “m” PN
originali in un'unica rete, rispettando i vincoli di condivisione descritti dall‟utente con le
matrici Cij.
La matrice di incidenza della rete fusa, nominata Cfusion , potrà essere costruita combinando
tra loro le matrici descritte in precedenza come mostrato nella formula (4-9):
(4-9)
La costruzione del vettore di marcatura della rete fusa verrà nominato M fusion e viene
costruito combinando i vettori di marcatura descritti in questo paragrafo come indicato
nella formula (4-10):
(4-10)
Ricostruire la matrice di inibizione della rete fusa è del tutto simile a quanto già fatto per la
matrice di Incidenza ed è descritto dalla formula (4-11):
37
(4-11)
The result of the matrix and graphic elaboration is the follow:
Figura 4.11 - PN1, PN2 e PN3 unite
38
4.4
Agenti generici
La componenti PN portate ad esempio fino ad adesso si sono sempre riferite ad agenti nella
forma di consumatori di risorse energetiche, cioè dove la parte di PN che li caratterizza
descrive il come tale agenti possono prelevare energia dal sistema domotico.
Utilizzando gli stessi strumenti di modellazione proposti è possibile generalizzare la
descrizione della componente PN anche nel caso volessimo modellare agenti più generici,
in grado di accedere bidirezionalmente alla risorsa energetica, e perciò anche in grado di
fornire energia, oltre che prelevarla. E‟ infatti sufficiente che l‟agente abbia una
componente PN per poter interegire con la risorsa energetica insieme agli altri. Nel caso che
esso sia in grado di erogare energia è sufficiente predisporre la sua marcatura iniziale in
modo da rappresentare che una quantità di energia (comunque limitata) può essere
potenzialmente rilasciata dall‟agente, immettendola nel sistema. In Figura 4.12 è mostrato
un esempio di Provider in grado di erogare al massimo “N” watt e che può interagire con la
risorsa e con gli altri agenti attraverso il posto “P1”, che in modo analogo a quanto mostrato
nella sezione precedente, potrà essere unito agli altri agenti in un‟unica PN rappresentate
l‟intero sistema.
Figura 4.12 - PN di un Provider energetico
Ne consegue che in una struttura come quella proposta in questo lavoro, per permettere
l‟interazione di un qualsiasi agente con al risorsa energetica, sarà sufficiente che all‟interno
del suo modello sia presente almeno una componente PN. Come poi la parte BEHAVIOR
sia stata modellata e come l‟evoluzione del suo stato/comportamento sia dipendente dal
tempo o dagli eventi risulterà del tutto indifferente, permettendo il mantenimento di una
completa trasparenza con il livello di interazione con la risorsa. Sarà a questo punto
possibile avere una grande liberta nella definizione del BEHAVIOR degli agenti, che se
composto da almeno una parte PN, potranno essere inseriti nella struttura del sistema
complessivo. Come già anticipato nel capitolo 3 la componente BEHAVIOR può essere
sostituita ad esempio da un dato storicizzato o da un modello costruito i modo differente
39
rispetto alla soluzione proposta in questa tesi (cioè utilizzando sistemi a stati finiti). Ne
consegue che una possibile rappresentazione di un generico agente, a differenza di quella
data in Figura 4.2, potrebbe essere la seguente:
Figura 4.13 - Agente generico
40
5. Ambiente di simulazione proposto
Nei due capitoli precedenti sono state portate all‟attenzione del lettore diverse tecniche di
modellazione di sistemi domotici ed è stato proposto un processo di costruzione del sistema
domotico nel suo complesso che permetta di far integrare tra loro tutti i sottosistemi in un
unico ambiente.
Dopo aver potuto descrivere in modo formale gli oggetti che popolano un contesto
domotico residenziale (elettrodomestici, produttori/accumulatori energetici) passeremo
adesso alla descrizione dell‟ambiente di simulazione che li potrà contenere e all‟interno del
quale potranno coesistere. La teoria aiuta a rappresentare i sistemi domotici per
comprenderne l‟evoluzione e condizionarne il comportamento [16]. In molti casi ci si
riferisce a strutture semplici in cui sono noti i criteri per prevederne il comportamento,
cercare di condizionarne l‟evoluzione verso i nostri fini oppure adottare le scelte migliori,
riuscendo a ridurre eventuali danni. Se il modello è descritto da una mappa più complessa,
la rappresentazione classica mantiene comunque la sua utilità poiché fornisce un quadro
completo delle variabile e delle forze in gioco, ma non sempre consente di effettuare delle
previsioni attendibili sul comportamento del sistema. Inoltre, non è sempre sufficiente
descrivere l‟evoluzione generale della situazione, ma talvolta sono richieste delle previsioni
quantitative che restituiscano delle cifre ben definite.
Ad esempio nel caso in esame, è riduttivo parlare di sistemi domotici e di elettrodomestici
che collaborano, se non si riesce a quantificare i benefici introdotti da tali soluzioni e
confrontarli con i sacrifici economici che si devono affrontare per ottenerli. Quando la
teoria dei sistemi non è sufficiente, o le strutture sono complesse o servono dei dati di
valutazione, la soluzione migliore risulta quindi costituita dalla simulazione al computer.
La simulazione è sempre più usata nella risoluzione di problemi reali in quanto consente di
sperimentare il comportamento del sistema sfruttando i legami fra le variabili, che sono
espressi da relazioni matematiche e i cambiamenti che sono immediati e permettono di
vedere subito cosa accade.
5.1
Progettazione dell‟ambiente di simulazione.
Verrà adesso mostrato da cosa compone la catena di passaggi che partono dalla fase
preliminare di progettazione di alto livello di un sistema domotico, fino alla fase finale
d‟implementazione dello stesso in simulatore a livello di programmazione, con lo sviluppo
del simulatore uomo/macchina. Saranno così richiamati gli strumenti software analizzati nei
precedenti paragrafi, evidenziando l‟interazione tra i vari strumenti e la sequenza temporale
del loro utilizzo.
È così stata sviluppata una struttura generale per il passaggio dalla fase di design fino alla
fase finale d‟implementazione del simulatore, sviluppando un formalismo per la
41
metodologia utilizzata. Il simulatore che verrà descritto verrà denominato HAS-Sim
(Home Automation Systems Simulator) e vi si farà riferimento nel resto del lavoro con
questo nome.
I punti principali della realizzazione metodologica della catena, si possono suddividere
nelle seguenti quattro macro-fasi:
1. In questa prima fase, che prende il nome di Modellazione UML, si va a studiare il
problema ad alto livello, seguendo le linee guida del linguaggio UML definito
inizialmente. Terminata questa fase si avranno così a disposizione le basi per il
passaggio all‟interno del software LabVIEW, ossia i diagrammi delle classi e di
stato, ricavati appunto dall‟applicazione del formalismo del linguaggio UML
mediante l‟utilizzo del software di modellazione Umbrello UML Modeller.
2. La successiva fase riguarda il passaggio all‟interno del software LabVIEW delle
classi e dei diagrammi di stato ricavati mediante lo studio UML della fase
precedente. Entrambi i passaggi sono raggruppati all‟interno di una macro-fase
chiamata Importazione in LabVIEW, che prende appunto il nome dal fatto che si
vogliono passare all‟interno di LabVIEW i risultati ottenuti in precedenza. Questa
macro-fase
può
essere
suddivisa
in
due
punti:
a. L‟importazione delle classi e dei metodi all‟interno del software
LabVIEW, mediante l‟ausilio del tool Endevo UML Modeller.
b. La definizione all‟interno dell‟ambiente LabVIEW del diagramma di stato
ottenuto durante la prima fase mediante l‟ausilio del modulo StateChart.
Questa seconda fase della procedura riguarda la catena di passaggio per generare del codice
riutilizzabile all‟interno dell‟ambiente di programmazione LabVIEW, fase necessaria in
quanto non si avrebbe la possibilità di utilizzare i diagrammi ottenuti mediante il software
Umbrello UML Modeller in alcun modo nel nuovo ambiente di programmazione. Questo
passaggio risulta essere semi-automatico, in quanto sia la trascrizione delle classi (attributi
e metodi) che del diagramma di stato (stati, eventi, guardie) avviene manualmente,
prendendo i diagrammi ottenuti nella fase precedente e riportarli manualmente all‟interno
dei vari software.
3. Un‟ulteriore fase riguarda l‟implementazione della strategia energetica. Questa
strategia vedremo che potrà essere sviluppata con l‟ausilio delle PN (script in
Matlab) o semplicemente attraverso un generico linguaggio di programmazione.
42
Al suo interno sono modellati gli agenti dell‟intero sistema, la risorsa condivisa
disponibile e la gestione energetica realizzata.
4. Infine l‟ultima fase riguarda la realizzazione del programma principale (main
program) su cui dovrà girare il nostro simulatore/emulatore. Saranno in questa
fase definiti l‟interfaccia utente e il codice sorgente (grafico nel nostro caso
LabVIEW) che integra al suo interno il codice ottenuto mediante l‟utilizzo del
software Endevo (classi e metodi), il software Statechart (il Diagram.vi
contenente il diagramma di stato), il software Matlab (i Matlab script che
richiamano e salvano le reti di Petri).
Il processo di creazione dell‟ambiente di simulazione/emulazione può essere sintetizzato
nello schema in Figura 5.1:
Figura 5.1 - Implementazione del simulatore/emulatore HAS-Sim
5.2
Accoppiamento tra elettrodomestici virtuali e smart plug
Gli agenti che fino ad adesso sono stati descritti e modellati si trovano ad un livello logico
molto vicino a quello fisico (livello Hardware), costituito dagli agenti/oggetti cognitivi e
43
reattivi. In questo livello si vanno a collocare i primi mattoni dell‟ambiente di simulazione
che stiamo andando a costruire composto dagli elettrodomestici e i dispositivi reali. A
livello medio presiede l‟Embedded server con cui comunicano il livello più basso e il
livello alto. In esso sono presenti la lavagna condivisa (Shared dashboard) e il Web-service
(per connessioni a livello web/internet) che cono connessi tra loro per scambiarsi
informazioni. A livello più alto c‟è l‟ Intelligenza che si compone di:

Controller devices, il controllore che gestisce i carichi della casa che consumano
energia (implementa una politica di controllo scelta);

Monitoring devices, contatore che monitora i consumi energetici della casa;

Supervision devices, dispositivo che in base ai consumi e alle preferenze
dell‟utente, setta e ottimizza i parametri gestiti dal controller device;

Human machine interface, o interfaccia uomo-macchina
La comunicazione tra i diversi livelli avverrà tramite TCP, tra il livello medio e quello alto,
mentre le tecnologie utilizzabili per la connessione con il livello più basso possono essere
di molte tipologie differenti (e.g. Lon, OpenWebNet, SCS bticino, PowerLine, Wifi,
Bluetooth, Zigbee).
Nella creazione dell‟ambiente di simulazione si è deciso di utilizzare i moduli realizzati
finora, mettendo a disposizione dell‟utente i seguenti elettrodomestici:
 Lavatrice - Washing Machine (WM) ;
 Lavastoviglie – Dish Washer (DW) ;
 Forno – Oven ;
 Frigo – Fridge ;
 Dispositivo generico non controllato - Generic Appliance;
Nella fase finale del lavoro che è descritto in questa tesi sono stati sviluppati anche modelli
di generatori/accumulatori energetici, che vedremo in questo capitolo come verranno
integrati all‟interno del sistema:
 Pennello fotovoltaico (accesso a dato storicizzato)
 Sistema di accumulo su batteria
Gli agenti elencati costituiranno i Simulated Devices dell‟HAS-Sim come riportato nella
Figura 5.2.
44
Figura 5.2 - Livelli della struttura dell'HAS-Sim
In questa fase di simulazione in LabVIEW del comportamento reale di un utente in una
casa, la comunicazione tra il medio e alto livello avverrà tramite la lavagna condivisa.
Quest‟ultima sarà assoggettata alla scrittura e lettura delle sue variabili per poter monitorare
e controllare i carichi in base al comportamento dell‟utente. In essa sono presenti le
variabili globali dei consumi di ciascun dispositivo e le variabili utilizzate dal controllore
per monitorare i dispositivi che consumano e che concorrono quindi alla risorsa comune,
l‟energia elettrica.
Seguendo le linee illustrate nelle sezioni precedenti, è possibile costruire ambiente di
simulazione in forma di HAS, permettendo l'integrazione di agenti simulati e
elettrodomestici reali. Ciò è reso possibile dal collegamento dei dispositivi reali con le
cosiddette prese intelligenti , che sono dotati di un misuratore e di un interruttore di
comando a distanza, come per esempio la presa bticino ® F522 [17].
Implementando e mandando in esecuzione la logica del controllore su un PC, è quindi
possibile rendere disponibile la lettura delle prese al controllore e dare la possibilità di
attuarle. In pratica, l‟elettrodomestico reale costituisce il componente BEHAVIOR, mentre
il componente intelligente costituisce il componente PLUG. Allo scopo di attuare la
strategia descritta in precedenza, il controllore deve sottrarre l‟energia fornita dalle letture
45
del contatore dalla quantità totale di potenza a disposizione, e agire di
conseguenza. L‟implementazione di strategie per la gestione energetica di impianti
domotici reali risulta essere così molto facile da implementare e a basso costo. E 'anche da
notare inoltre che, in questo modo, gli elettrodomestici di diverse marche possono essere
facilmente integrati nel sistema domotico, evitando problemi di compatibilità e di
comunicazione, in una visione plug-and-play.
Un ambiente di emulazione del tipo descritto sopra è illustrato nello schema in Figura 5.3
che rappresenta la struttura hardware del DOMOLab presente all‟interno del Dipartimento
di Ingegneria dell‟Informazione dell‟UNIVPM. In tale schema sono presenti degli
elettrodomestici simulati come la lavatrice e la lavastoviglie (per evitare l'impianto
idraulico), insieme ad un frigo e forno reali con l‟obiettivo di ricostruire un realistico
impianto domotico. Interfaccia tra l‟ambiente delle PLUG reale e l'ambiente di
simulazione (PC) è realizzato da un gateway che tramite un bus locale connette le prese ad
una rete Ethernet / Wi-Fi .
46
Figura 5.3 - Struttura hardware HAS
47
5.3
Strategie di controllo
Nei capitoli e paragrafi precedenti si è fatto riferimento spesso alla possibilità di inserire
sistemi di controllo all‟interno del simulatore/emulatore, in modo da poterne testare il
funzionamento, affinarne l‟algoritmo e validare l‟efficacia. In questa sezione verranno
portati tre esempi di sistemi di controllo che sono stati testati utilizzando l‟HAS-Sim come
piattaforma di test. Il primo sistema di controllo sarà orientato alla gestione della potenza
istantanea (W) consumata dal sistema per poterla tenere all‟interno delle soglie energetiche
e temporali imposte dal provider energetico (contatore dell‟ENEL nel particolare). Il
secondo riguarderà la gestione dell‟energia consumata (Wh) relativa alla taglia energetica
scelta e di conseguenza imposta dal provider energetico (quantità limitati di Wh mensili). Il
terzo ed ultimo sistema di controllo sarà invece inserito in un contesto più ampio, nel quale
sono presenti nel sistema più di un provider energetico. Si vorrà in quest‟ultimo caso
massimizzare il consumo di energia auto-prodotta (e.g. proveniente da pannelli solari o
accumulata su batteria).
L‟implementazione e le interfacce utente relative alle strategie di controllo che verranno qui
di seguito riportate saranno presentate nel capitolo 6 per poi essere validate con alcuni
esperimenti e simulazioni nel capitolo 7.
5.3.1 Gestione potenza istantanea
Partendo dal modello di PLUG anticipato in 4.2 verrà qui portata una particola soluzione
che è stata adottata per il mantenimento della potenza istantaneamente consumata dal
sistema al di sotto di un soglia prestabilita. Il controllore è stato programmato in modo tale
da eseguire una strategia di controllo sulla gestione sovraccarichi all‟interno del sistema
domotico. La politica di controllo si basa su monitoraggio delle priorità assegnate a ciascun
elettrodomestico.
La PN della PLUG è stata costruita appositamente per questo scopo e la parte di Control
action, fino ad adesso lasciata generica, è stata invece definita in modo tale da meglio
adattarsi ad una specifica politica di controllo che si è voluto implementare. Rimane sempre
valido quanto già detto a proposito del modo con cui la PN interagisce con la risorsa,
ipotizzato che ogni elettrodomestico modellato sia collegato alla rete elettrica attraverso una
smart plug, in grado di misurare il consumo energetico istantanea e capace di rispondere a
dei comandi di attivazione/disattivazione (switching) connettendo/disconnettendo
l‟elettrodomestico stesso dalla rete elettrica. Verrà pero adesso inserita anche la politica di
gestione della potenza istantanea all‟interno della PN di ogni PLUG, permettendone
un‟implementazione direttamente al livello di modello matriciale.
L‟ interazione tra il dispositivo e la risorsa, assieme alla politica di controllo che si vuole
implementare, è descritto dalla PLUG per mezzo della PN così strutturata:
48
A. il consumo di energia; Un numero fisso di token nel posto “P8” rappresentano
l‟ammontare della potenza disponibile all‟agente. Variazioni sul valore
attiva
sia la transizione T1 (che aumenta il consumo) che la transizione T2 (che
decrementa il consumo). La marcatura del posto “P1” rappresenta l‟attuale
consumo della presa.
B. l‟abilitazione e non della presa a cui è collegato l‟elettrodomestico. La presenza di
un token nel posto “P2” denota che l‟elettrodomestico è connesso alla presa e
consuma potenza elettrica e in tal caso il comportamento temporale del
BEHAVIOR evolve come
. La presenza di un token invece in “P3” indica che
il dispositivo è disconnesso dalla sorgente elettrica per tale motivo il
comportamento temporale BEHAVIOR evolve come
. In questa situazione la
transizione “T1” che di solito è abilitata, risulta inibita dalla rete di Petri in quanto
l‟elettrodomestico è stato bloccato dal controllore.
C. un contatore per connettere la presa (switch on);
D. un contatore per disconnettere la presa (switch off).
La rete di Petri del singolo elettrodomestico si presenta così:
Figura 5.4 - PN componente PLUG controllata
Il compito del controllore, è perciò quello di monitorare e controllare gli agenti, interagendo
con la componente PLUG di ciascun elettrodomestico. Nella sezione A monitora la potenza
consumata e quella disponibile dalla rete agendo sulle transizioni “T1” e ”T2”, mentre per
disconnettere o connettere l‟agente incide sullo scatto delle transizioni “T3” e “T4”. Per
49
queste ultime transizioni, lo scatto può avvenire solo dopo il reset del countdown del
dispositivo, rappresentato dalle sotto reti D e C. Quando le risorse consumate all‟interno del
sistema eccedono la soglia consentita (situazione di overload), la disconnessione non è
immediata ma dipende dal numero di token ND
. Se nel sistema domotico sono diversi
gli agenti che consumano potenza elettrica, allora concorreranno nello switch off, in
situazione di overload, secondo le priorità stabilite. La disconnessione degli
elettrodomestici con più bassa priorità permette al sistema di uscire dalla situazione di
overload e il countdown per i rimanenti agenti viene terminato e resettato al valore di
default. Per gli agenti disconnessi viene attivato invece il secondo countdown e viene
concessa potenza elettrica all‟elettrodomestico associato quando la priorità di switch on
risulta essere azzerata. Questa strategia implementata dal controllore centralizzato, permette
di evitare grossi picchi e larghe oscillazioni nei consumi dell‟intero sistema. Per ciascun
elettrodomestico i valori delle priorità, sono impostati in termini di token (1 token = 1
minuto).
In situazione di overload, ossia al superamento della soglia contrattuale di potenza (3300 W
nel caso ENEL Italia), il controllore abilita lo scatto della transizione T5 (nella parte D
relativa alla rete di Petri del singolo elettrodomestico) per tutti i dispositivi attivi e controlla
il numero di token nello stato P4 (indicante la priorità di switch off). L‟azzeramento di tale
valore, comporterà l‟inibizione del relativo elettrodomestico da parte del controllore. Se la
situazione di overload risulta non superare un tempo di tolleranza T, le priorità verranno
resettate al valore iniziale. Una volta inibito uno o più elettrodomestici, al fine di riportare i
consumi al di sotto della soglia di overload, il controllore inizia a monitorare le priorità di
switch on (delle sole prese inibite) e a scalarne il valore fino all‟annullamento che comporta
la riattivazione della presa corrispondente e quindi la concessione di potenza
all‟elettrodomestico associato.
Il controllore descritto è stato costruito seguendo le stesse regole di modellazione che sono
state utilizzate per costruire gli altri Agenti, è infatti costituito da un diagramma a stato
successivamente implementato all‟interno dell‟ambiente di programmazione.
Statechart del controllore
Lo statechart del controllore è costituito da due macrostati in composizione ortogonale, i
cui stati e transizioni al loro interno, sono sensibili all‟evento Timeout PN. Si riporta in
Figura 5.5 il Block Diagram degli Statechart in implementato in ambiente LabVIEW.
Viene qui riportata la rappresentazione del controllore realizzata utilizzando solo il
linguaggio di programmazione. Essa è però del tutto identica a quella che potrebbe essere
data con uno State diagram dell‟UML.
50
Figura 5.5 - Statechart del controllore in LabVIEW
Nel macrostato Counter, gli stati sono i seguenti:
 Tick
 Tock
Il macrostato Control presenta invece i seguenti stati:
 Lettura prese
 Scala priorità switch off
 Switch off
 Scala priorità switch on
 Switch on
La transizione in ingresso allo statechart del controllore richiama il metodo PN_Init in cui
vengono inizializzati gli attributi della classe PN tra cui Path PN, Power place, Numero
Prese, Prese bticino e Token Time. Inoltre viene resettato il workspace di Matlab tramite la
funzione clear all e viene resettato il contatore Tick-Tock.
Il macrostato Counter è stato realizzato per sincronizzare lo statechart con la rete di Petri.
Il passaggio dallo stato Tick allo stato Tock, e viceversa, causa l‟incremento di un contatore
che viene confrontato con il TokenTime della Petri net.
Il macrostato Control invece, raccoglie l‟intera anima del controllore in cui vengono lette le
prese attive e monitorato lo stato di potenza totale, consumata dall‟ intero impianto.
Presenta una struttura speculare in cui si oppongono la parte legata allo switch off con
quella di switch on.
51
Il cuore di questo macrostato è lo stato Lettura prese, che come entry action richiama il
metodo omonimo della PN class mentre in uscita esegue la chiamata ai metodi Switch off e
Switch on.
Lettura prese consiste in un MATLABScript in cui sono raccolte le seguenti operazioni:

Caricare le matrici che descrivono lo stato della rete di Petri, ossia le matrici di
Incidenza, d‟ Inibizione e il vettore della Marcatura totale.

Aggiornare la rete di Petri con lo stato delle prese presenti nel sistema.

Analizzare la matrice di Inibizione e il vettore della marcatura totale per
controllare se le operazioni che si vogliono effettuare sulla rete di Petri siano
effettivamente permesse. In caso negativo verrà generato un messaggio popup di
errore, che blocca l‟intera simulazione e visualizza a schermo la rete di Petri, per
analizzare l‟operazione proibita.

Verificare la presenza di overload, o sovraccarico dell‟impianto, e l‟entità dell‟
esubero della potenza consumata rispetto a quella contrattuale
( P max_ disp  Pcontr 1.1  3.3KW P max_ disp  Pcontr 1.1  3.3KW ).
Se
tale
valore
dovesse
superare
la
soglia
di
Px
( Px  P max_ disp) Pcontr  K max  3.3  1.27  4.2KW )
si
anticipa
l‟intervento del controllore, riducendo il TokenTime da 60s a 3s in modo tale da
velocizzare lo Switch off delle prese attive e rientrare al di sotto del 4,2 kW in
massimo 4 minuti. In questo modo sarà possibile evitare lo scatto del contatore.
Figura 5.6 - Algoritmo di intervento del contatore ENEL
52


Leggere i consumi degli elettrodomestici collegati a ciascuna presa e in tal caso
attuarla e aggiornarne lo stato. Lo stato delle prese è infatti discriminabile tra tre
valori come mostrato in Figura 5.7:
o ON, se l‟elettrodomestico ad esso connesso sta consumando potenza;
o STOP, se la presa è stata inibita dall‟intervento del controllore;
o OFF, se l‟elettrodomestico associato alla presa non consuma potenza ma
risulta spento.
Figura 5.7 - Interfaccia grafica relativa al controllore
Verifica il consumo presente nel Power place nella reti di Petri con quello
misurato e in caso di divario, quest‟ultimo viene interpretato come il consumo di
un Generic appliance non controllato ma semplicemente misurato all‟interno del
sistema (ad esempio un phon sotto il controllo dell‟utente).
In uscita dal MATLABScript vengono forniti:



Un vettore contenente lo stato delle prese attive, chiamato preseON;
Un led indicante lo stato di overload dell‟impianto;
Un led errore che visualizza l‟eventuale errore commesso, nel richiedere alla rete
di Petri di effettuare un‟operazione proibita ;
Il metodo Switch off, richiamato invece in uscita dallo stato Lettura prese, si occupa di
analizzare tutto il vettore delle preseON e verificare se si è scalata la priorità di Switch off
ad esse associata. Se tale evento dovesse essere accaduto, verrebbe posta a true la variabile
di switchOFF.
53
Il metodo Switch on, richiamato a seguire Switch off , effettua un‟ operazione analoga al
metodo precedente, con la differenza che analizza la priorità di Switch on. Se tale evento
dovesse accadere, verrebbe posta a true la variabile di switchON.
Lo stato Lettura prese presenta anche una serie di auto anelli le cui transizioni permettono
di richiamare dei metodi specifici della classe PN. Partendo dal basso ci sono:

la prima transizione che richiama il metodo View PN che permette la
visualizzazione della rete di Petri del sistema aggiornata.

La seconda transizione richiama il metodo Reset_SwitchON_2 dopo aver
verificato che ci sia overload e che si sia verificato uno switchON. In uscita da tale
transizione si resetta il contatore del Tick-Tock.

La terza transizione richiama il metodo Reset_priorità_switch_off dopo aver
verificato che non ci sia overload e che si sia verificato uno switchOFF. In uscita
da tale transizione si resetta il contatore del Tick-Tock.

La quarta transizione invece non richiama alcun metodo ma verifica
semplicemente che durante un decremento della priorità di switch on, si sia
verificato un overload. In uscita da tale transizione si resetta il contatore del TickTock.
Il metodo Reset_SwitchON_2, all‟interno di un altro MATLABScript, esegue le seguenti
operazioni:


il ripristino della priorità di switch on per tutte le prese inibite
l‟annullamento della variabile di switchON.
Il metodo Reset_priorità_switch_off, all‟interno di un MathScript, esegue le seguenti
operazioni:


il reset della priorità di switch off sia per le prese attive che per quelle inibite.
l‟annullamento della variabile di switchOFF.
Dallo stato Lettura prese è possibile, per mezzo di due transizioni, giungere negli stati
Scala_prorità_switch_off e Scala_prorità_switch_on. La transizione che da Lettura prese
giunge in Scala_prorità_switch_off verifica che lo stato del contatore Tick-Tock sia non
54
inferiore al Token Time, il cui valore viene letto tramite il metodo omonimo Read
TokenTime. Se tale disuguaglianza fosse verificata in concomitanza con la presenza di
overload, la transizione risulterebbe abilitata. La transizione invece, che da Lettura prese
giunge in Scala_prorità_switch_on verifica che lo stato del contatore Tick-Tock sia non
inferiore al Token Time. Se tale disuguaglianza fosse verificata in concomitanza con
l‟assenza di overload, la transizione risulterebbe abilitata.
Nello stato Scala_priorità_switch_off si richiama il metodo omonimo in cui si analizza
tutto il vettore delle preseON e si scala di un token la priorità di switch off per ciascuna
presa attiva, settata nella rete di Petri. All‟ annullamento della priorità di swicth off, si
prosegue nel considerare la presa in questione, da inibire. Il suo indice verrà posto
all‟interno di una variabile di appoggio definita preseOFF e la presa viene disattivata
forzatamente ponendola pari a -1 nel vettore preseON, in modo che l‟elettrodomestico
associato non è più in grado di assorbire potenza. Dallo stato Scala_priorità_switch_off è
possibile raggiungere lo stato Switch_off oppure tornare nello stato Lettura_prese,
resettando il contatore Tick-Tock. La transizione di passaggio allo stato Switch_off viene
abilitata solo se il vettore preseOFF presenta un valore maggiore di -1 (valore di default),
che indicherebbe in tal caso il numero della presa da inibire.
Lo stato Switch_off richiama al suo interno il metodo Inibizione che inibisce le prese
indicate nel vettore preseOFF e pone a zero il corrispondente valore nel vettore delle
preseON. Ciò indica che la presa in questione è arrestata e sull‟interfaccia utente del
controllore si accenderà il relativo led di stop.
Dallo stato Switch_off si raggiunge Lettura prese per mezzo di un transizione che esegue al
suo interno le seguenti azioni:



Reset del contatore Tick-Tock.
La variabile arrestato è posta a true, ad indicare che è stata arrestata una presa.
Viene richiamato il metodo Reset_priorità_switch_off (spiegato in precedenza).
Nello stato Scala_priorità_switch_on si richiama il metodo omonimo in cui si analizza tutto
il vettore delle preseON e si scala di un token la priorità di Switch on per le sole prese
inibite. All‟ annullamento della priorità di swicth on, si prosegue nel considerare la presa in
questione, da riattivare. Il suo indice viene registrato all‟interno della variabile
presaTimeOUT e inoltre, tutti gli indici delle prese inibite o da riattivare, all‟interno del
vettore preseOFF, vengono ripristinate a -1. Dallo stato Scala_priorità_switch_off è
possibile raggiungere lo stato Switch_off oppure tornare nello stato Lettura_prese,
resettando il contatore Tick-Tock. La transizione di passaggio allo stato Switch_on viene
abilitata solo se la variabile presaTimeOUT presenta un valore diverso da -1 (valore di
default), che indicherebbe in tal caso il numero della presa da riattivare.
Nello stato Switch_on si richiama il metodo Riabilitazione che al suo interno:
55



Riabilita la presa ponendo a -1 il valore corrispondente nel vettore preseON e in
prese OFF.
La presa viene disinibita nella rete di Petri.
Se ci sono ancora delle prese inibite allora la variabile arrestato rimane a true
altrimenti viene resettata a false.
Il passaggio dallo stato Switch_on a Lettura_prese è garantito da una transizione che
all‟abilitazione esegue la chiamata di Reset_priorità_switch_on e resetta il contatore TickTock. Il metodo Reset_priorità_switch_on si occupa di annullare la variabile switchON e
resettare sia la priorità di switch on della sola presa arrestata che la variabile
presaTimeOUT.
La transizione in uscita dallo statechart è sensibile sia all‟ ingresso Stop che alla variabile
errore, terminando così la simulazione.
5.3.2 Stima e gestione delle taglie energetiche
Questa seconda politica di controllo testata è connessa alla collaborazione instauratasi con
il centro di ricerche dell‟ENEL IIR di Pisa, il quale ha richiesto all‟interno della
collaborazione la possibilità di andare a monitorare non il solo consumo istantaneo di tutti
gli elettrodomestici della casa, ma anche di valutare la quantità di energia (Wh) consumata
nelle mensilità delle simulazioni per poter valutare al variare del comportamento degli
abitanti della casa potesse variare il profilo energetico dell‟appartamento. Per soddisfare le
richieste avanzate nel contesto di questa collaborazione è stato necessario mettere appunto
3 strumenti fondamentali:
 Un sistema di stima della taglia minima necessaria in base alla conformazione
della casa e alla abitudini degli abitanti
 Un sistema di stima online della quantità di energia che verrà consumata
durante il mese a seconda del comportamento adottato dagli abitanti durante il
corso della mensilità. Sulla base di questa stima verrà implementato anche un
sistema di allarme in grado di avvisare l‟utente se sta tenendo un comportamento
scorretto che lo porterà ad esaurire la sua taglia
 Un sistema di scheduling in grado di modellare il comportamento degli abitanti di
un appartamento durante un mese di simulazione, permettendo l‟avvio
temporizzato di elettrodomestici (evitando la presenza di un utente che li faccia
avviare manualmente durante le simulazioni)
La strategia per la gestione energetica ha un orizzonte mensile sulla base dei contratti a
taglie.
56
La strategia energetica ha come ipotesi:
HP1:
La taglia durante un mese di 28 giorni mette a disposizione N Wh dove N varia con la
taglia
HP2:
Nel sistema sono presenti:
 Prese attuate e misurate
 Prese non controllare
 Misura del consumo complessivo della casa
HP3:
Per ogni prese attuata/misurata è noto il consumo nominale di un ciclo di funzionamento
dell‟elettrodomestico ad essa collegato
HP4:
I consumi degli elettrodomestici controllati e non verranno organizzati in serbatoi
contenenti gettoni di energia. La somma di tutti i gettoni contenuti nei serbatoi sarà pari al
valore N di Wh relativo alla taglia dell‟utente.
Sulla base di stime di consumi mensili ottenute della descrizione delle abitudini dell‟utente,
verrà stimato il contenuto dei serbatoi di energia con i quali è possibile andare a gestire i
consumi durante i singoli giorni e settimane del mese con l‟obiettivo di informare l‟utente
se il suo andamento dei consumi lo porterà o meno in via previsionale ad uno sforamento
della sua taglia. Le informazioni che l‟utente deve fornire al supervisore sono:
 il numero di volte che un dato elettrodomestico viene utilizzato durante la
settimana
 il numero di inquilini della casa
Riserve di energia (serbatoi)
I serbatoi in cui verrà suddivisa la quantità N di Wh messi a disposizione dalla taglia sono
3:
1. Rbase : contiene la riserva di energia giornaliera che verrà utilizzata per assicurare
l‟alimentazione di carichi non modulabili con prese note (ad es. impianto di
illuminazione …).
57
2. R1 : contiene la riserva di energia settimanale da cui attingere per l‟alimentazione
di carichi modulabili con prese attuabili (ad es. lavatrice, lavastoviglie, forno,
frigorifero …).
3. R2 : riserva mensile utilizzabile per fronteggiare una richiesta energetica
settimanale non copribile con
Rbase e R1
Il contenuto dei 3 serbatoi viene aggiornato ogni 15 minuti dal sistema e a fine giornata
eventuali gettoni residui presenti in
Rbase e a fine di ogni settimana eventuali gettoni residui
R1 confluiranno nel serbatoio R 2 . Questo algoritmo suppone che le linee di
alimentazione dei carichi Rbase siano misurabili almeno come complemento tra l‟energia
presenti in
consumata dai carichi di R1 e la totalità di energia consumata.
Verranno indicati con nbase, n1 , n2 rispettivamente i gettoni energia presenti nei serbatoi
Rbase , R1 , R2 .
Come detto nell‟HP4 la somma dei gettoni contenuta in tutti i serbatoi deve essere pari al
numero N di Wh forniti dalla taglia, perciò tali gettoni sono tra loro legati dalla seguente
relazione:
(5-1)
28
4
j 1
i 1
 nbase( j)   n1 (i)  n2 (i)  N
dove
nbase e considerato giornaliero, mentre n1 , n2 sono settimanali.
Partendo dalla definizione dei serbatoi verrà adesso illustrato l‟algoritmo con il quale il loro
contenuto viene aggiornato, presupponendo che il loro valore di inizializzazione rispetti le
ipotesi date.
Prendendo in considerazione il significato degli indici nbase , n1 , n2 è possibile risalire al
loro valore in modo parametrico.
nbase(j)
58
Rappresenta il consumo energetico giornaliero della casa (giorno “j”) ipotizzato nella
condizione di utilizzo di soli carichi fondamentali e non distaccabili che per questo motivo
sono monitorati e non direttamente coinvolti nell‟azione di controllo.
Il valore stimato per ogni giorno j-esimo verrà indicato come nˆbase e sarà costante per ogni
giorno j.
Mentre il valore per ogni giorno “j” che verrà aggiornato ogni 15 minuti sulla base delle
misure di potenza verrà indicato come nbase,15 ( j ) .
Infine il contenuto del serbatoio di Rbase a fine di ogni giornata j verrà indicato come
nbase( j )
n1(i)
Rappresenta il consumo di energia della settimana “i” ipotizzato sulla base delle abitudini
degli utenti della casa (elettrodomestici con task rimandabili che solitamente vengono fatti
partire con ciclo settimanale). Tale stima rimane costante per ognuna delle 4 settimane dei
28 giorni del mese e viene resettato al valore stimato all‟inizio di ogni nuova settimana.
Il valore stimato per ogni settimana i verrà indicato come nˆ1 ,tale valore sarà costante per
ogni settimana i.
Invece il valore per ogni settimana “i” che verrà aggiornato ogni 15 minuti sulle misure di
potenza degli elettrodomestici sotto controllo verrà indicato come n1,15 (i )
Il contenuto del serbatoio di R1 a fine di ogni settimana i verrà indicato come
n1 (i)
Taglia
La taglia “T” iniziale viene scelta sulla base dei valori stimati di
nˆbase e nˆ1 in modo tale da
rendere disponibile almeno un numero di token energia, pari ad un giorno in più di richiesta
energetica stimata, espressa da
nˆ1 . Si fornirà quindi almeno un
nˆ1
di energia in più ogni
7
settimana, per creare un margine di sicurezza che possa tenere conto del comportamenti
degli abitanti della casa che si discostano dalle abitudini da loro espresse.
Il margine di sicurezza in questione è il magazzino R2 che conterrà un numero di token
energia n2 tale da rispettare il vincolo di fornire un
nˆ1
in più ogni settimana.
7
59
n2(i)
Rappresenta il numero di gettoni di energia che sono resi disponibili ogni settimana “i” del
mese oltre agli nbase e n1. E‟ il contenuto del serbatoio R2 che funge da margine di sicurezza
per tenere conto di eventuali consumi non programmati dall‟utente.
Al valore di n2 verrà poi:
 aggiunta a inizio di ogni giorno “j” la porzione di nbase(j-1) non consumata durante
il giorno “j-1” o sottratta ogni 15 minuti la quantità di energia consumata che ha
superato il valore di

nˆbase stimato;
aggiunta a inizio di ogni settimana “i” la porzione di n 1(i-1) non consumata
durante la settimana
“i-1” o sottratta ogni 15 minuti la quantità di energia
consumata che ha superato il valore di
nˆ1 stimato.
Il valore per ogni settimana “i” e giorno “j” che verrà aggiornato ogni 15 minuti sulle
misure di potenza reali verrà indicato come n2,15 (i, j ) .
Il contenuto del serbatoio di R2 a fine di ogni settimana “i” verrà indicato come n2 (i ) .
Mantenendo parametrica la dimensione della taglia dell‟utente, tenendo presente il
significato e la notazione di nbase e n1 precedentemente descritti e tenendo conto di
eventuali
residui
o
sovra
consumi
dei
giorni
(nbase(i-1)) o delle settimane (n1(j-1)) precedenti dello stesso mese, è possibile calcolarne il
valore di n2 parametricamente a partire da ogni inizio mese (mese di 28 giorni) e aggiornare
il suo valore ogni 15 minuti in caso di consumi che vadano ad esaurire i serbatoi Rbase o R1.
Andremo adesso ad indicare con n2,init(i) il contenuto del serbatoio R2 ad inizio di ogni
settimana i.
(5-2)
nbase(0 )  n1 (0)  0
n2,init (i )  nˆ 2  n2 i  1
n2,15 (i, j )  n2,init (i )  nbase, 2  n1, 2
dove
nbase, 2  nˆbase  nbase,15 ( j ) se
altrimenti
e dove
nˆbase  nbase,15 ( j )  0
nbase, 2  0
n1, 2  nˆ1  n1,15 (i) se nˆ1  n1,15 (i)  0
altrimenti
n1, 2  0
60
Algoritmo Taglie
Strategia
Sulla base di quanto detto, la strategia di gestione energetica si pone l‟obiettivo di :
 Indicare e garantire la disponibilità energetica minima giornaliera e settimanale
( Rbase +

R1 );
Indicare e forzare (distacco prese) il rispetto della taglia.
Questa strategia pone le basi per lo sviluppo di un meccanismo di apprendimento delle
abitudini dell‟utente con lo scopo di aggiornare i gettoni
n1 presenti nella riserva R1 (i).
Monitoraggio
Ogni 15 minuti, sulla base dell‟andamento di nbase , n1 e n2 , verrà fornita all‟utente
un‟informazione sull‟andamento del consumo di energia (% di tagli consumata) e sullo
stato di dei 3 serbatoi Rbase , R1 , R2 .
A fine simulazione (dopo 28 giorni simulati) il simulatore comunicherà la taglia più vicina
ai consumi che sono stati misurati durante il mese.
La quantità di gettoni in eccesso (o che non è stata sufficiente) a fine di ogni mese, n 2(4),
potrà essere usata per comprendere meglio se l‟utente si trova o meno in una taglia che
rispetta le sue abitudini e permetterà di eseguire un tuning del valore di inizializzazione n1
che sintetizza le abitudini espresse dall‟utente.
Infatti il valore di n1 stimato potrebbe non essere corretto se il comportamento reale tenuto
dell‟utente durante il mese non rispecchia le abitudini descritte dallo stesso. Una correzione
di n1 sulla base delle misure di Potenza ed Energia eseguite nel mese potrà portare ad un
miglioramento della sua stima e al suggerimento di una taglia più adeguata alle abitudini
dell‟utente.
Il valore di n2(4) può essere interpretato nel seguente modo:
1. Se
n2 (4)  0 e n2 (4)  n2,init (i)  4 significa che durante il mese sono stati
effettivamente consumati solo i serbatoi Rbase e R1 e il serbatoio R2 (surplus di
energia messo a disposizione per eventuali eccessi di consumo) non è stato
utilizzato;
61
2. Se
n2 (4)  0 e n2 (4)  n2,init (i)  4 significa che durante il mese è stata
consumata effettivamente solo una parte dei serbatoi Rbase e R1 e il serbatoio R2 ,
oltre a non essere stato utilizzato, è stato incrementato;
3. Se
n2 (4)  0 e n2 (4)  n2,init (i)  4 significa che durante il mese è stato
consumato effettivamente tutto il contenuto dei serbatoi Rbase e R1 e il serbatoio R2
è stato in parte intaccato;
4. Se
n2 (4)  0 e n2 (4)  n2,init (i)  4 significa che durante il mese oltre a tutto
il contenuto dei serbatoi Rbase, R1 e R2 è stato consumato effettivamente un
ulteriore quantitativo di energia che ha fatto sforare la taglia scelta.
L‟informazione che il Supervisore dell‟energia darà all‟utente sarà:

nel caso (1), se n2(4) non si discosta molto da n2,init (i )  4 , che la taglia scelta a
inizio simulazione è la più appropriata e che è stata rispettata;

nel caso (2), se la differenza
n2 (4)  n2,init (i)  4 sottratta al valore di n1 stimato
è tale da permettere una riduzione di taglia senza uno sforamento, di ridurre la
taglia alla più piccola che non sarebbe stata sforata;

nel caso (3), se il
n2 (4)  n2,init (i) (cioè ho consumato 3/4 del bonus assegnato
con R2), di aumentare la taglia alla successiva più grande che mi allontana dal
rischio di sforamento;

nel caso (4), se la differenza
n2 (4)  n2,init (i)  4 sottratta con segno al valore di
n1 stimato è tale da necessitare un aumento di taglia per evitare uno sforamento, di
aumentare la taglia alla prima più grande che non avrebbe fatto sforare la taglia.
Stima di nbase , n1 , n2 e della Taglia
Utilizzando le abitudini fornite dall‟utente è possibile andare a stimare un valore iniziale
per il contenuto dei serbatoi Rbase , R1 e R2 .
62
nˆbase, Annuo
Questo valore può essere stimato inizialmente prendendo in considerazione il numero di
abitanti della casa riprendendo la stima di consumo di 1, 2, 3, 4 o più persone in una casa
dal
sito
ENEL
(http://www.enel.it/enelenergia/itIT/casa/offerte/energia_tuttocompreso/simulatore/). Sul sito viene fornito il consumo
stimato annuale che indicheremo come nˆbase, Annuo . Per risalire al valore giornaliero è viene
effettuato il calcolo:
(5-3)
nˆbase 
nˆbase, Annuo
365
nˆ1
Questo valore può essere stimato mantenendo parametrico:
 il numero di volte che ognuno degli “n” elettrodomestici controllati presenti nella
casa viene fatto partire settimanalmente “mp” (valore diverso per ogni tipologia di
elettrodomestico “p”);

il valore del consumo nominale di energia durante l‟esecuzione di un loro ciclo
“XWh,p” (valore diverso per ogni tipologia di elettrodomestico “p”).
è possibile andare a calcolare il valore stimato settimanale di n1:
(5-4)
n
mp
nˆ1   X Wh, p
p 1 b 1
Tale valore sarà costante per ogni settimana i.
Taglia
Come abbiamo detto in precedenza la dimensione della taglia T (numero di N Wh
disponibili) ad inizio simulazione viene scelta sulla base dei valori stimati di nˆbase e nˆ1 in
modo tale da rendere disponibile almeno un numero di token energia, pari ad un giorno in
più di richiesta energetica stimata, espressa da
nˆ1 . Si fornirà quindi almeno un
nˆ1
di
7
energia in più ogni settimana. Per rispettare questo vincolo viene in modo automatico scelta
la taglia con cui inizializzare la simulazione, scegliendo la taglia più piccola tale che:
63
(5-5)
nˆ 

N  nˆbase  28   nˆ1  1   4
7

nˆ 2
Il valore di n2 è inizializzato ad un valore costante ad ogni inizio della settimana i-esima del
mese e tale stima iniziale verrà indicata con nˆ 2 . è possibile andare a calcolare tale valore
stimato settimanale come:
(5-6)
nˆ 

N  nˆbase  28   nˆ1  1   4
7

nˆ 2 
4
Algoritmo ricorsivo
Seguendo i passi dell‟algoritmo che abbiamo ottenuto avremo un‟inizializzazione del
contenuto di R2 pari al solo valore stimato nˆ 2 la prima settimana.
Successivamente durante tutta la prima settimana, ogni 15 minuti viene aggiornato il
contenuto di R2 a seconda che i serbatoi Rbase e R1 siano stati esauriti o meno.
A fine di ogni giornata “j” viene riversato in R2 il residuo del giorno precedente presente in
Rbase, cioè nbase(j-1).
A fine della prima settimana viene reinizializzato il serbatoio R2 al valore stimato di nˆ 2 e
in più viene riversando al suo interno il residuo della prima settimana in R2 , cioè n 2(1).
Questo processo si ripete ricorsivamente per tutte e 4 le settimane dei 28 giorni del mese
come descritto dall‟Algoritmo Taglie.
Intervento del Supervisore Energia
Il sistema di Supervisione dell‟Energia, sulla base dei valori di nbase , n1 e n2 che vengono
aggiornati ogni 15 minuti, potrà decidere di sospendere gli elettrodomestici sotto controllo
(n1) distaccandoli se il loro consumo previsionale per completare il loro ciclo standard di
funzionamento rende negativo il valore di n2(i) .
La previsione sul consumo energetico di un elettrodomestico per terminare un suo ciclo
standard di funzionamento come abbiamo detto può essere ottenuto in diversi modi:
 potrebbe essere inserito il valore in Wh di un ciclo di funzionamento direttamente
dall‟utente/installatore
64


potrebbe essere appresa dal simulatore/emulatore andando a misurare i consumi
della presa a cui e collegato un dato elettrodomestico
si potrebbe utilizzare una tabella dei consumi standard degli elettrodomestici in
base alla loro classe di appartenenze (A, A+ …)
Nel caso particolare di questo simulatore la previsione di consumo per ogni
elettrodomestico è stata ottenuta ipotizzato che gli elettrodomestici siano tutti di classe A:
http://it.wikipedia.org/wiki/Classe_di_consumo_energetico
5.3.3 Massimizzazione autoconsumo
Utilizzando l‟estensione del concetto di agente presentato in 4.4 gli elementi del sistema
domotico possono essere in grado anche di generare loro stessi una parte della risorsa
condivisa con il resto del sistema. Questa maggiore libertà di modellazione permette da un
lato di ampliare gli scenari che l‟ambiente di simulazione è in grado di gestire e apre le
porte verso l‟esplorazione di nuove politiche di controllo che possano raggiungere obiettivi
che prima non potevano essere proposti.
L‟evoluzione del ambiente di simulazione in questa direzione si inserisce in un contesto di
collaborazione che si è instaurato con il Gruppo Loccioni (AEA Srl), il quale all‟interno
della sua settore Green Energy dispone di un complesso sistema domotico (LeafHouse
[18]) dove oltre ad essere monitorati i carichi degli elettrodomestici e degli appartamenti,
sono presenti un sistema fotovoltaico e un sistema di accumulo basato su batterie al Litio.
L‟obiettivo che ci si proposto di raggiungere è stato quello di utilizzare le tecniche di
modellazione affinate con il lavoro pregresso del gruppo di ricerca del LabMACS per
riuscire a modellare un sistema complesso come quello della LeafHouse e testare sul
modello in simulazione un algoritmo di controllo in grado di massimizzare la quantità di
energia autoprodotta dal complesso domotico residenziale in presso LeafHouse.
Costruzione modello della LeafHouse
Il primo passo nel processo di modellazione è stato quello di mettere assieme una struttura,
utilizzando gli strumenti presentati in 4.3, nella quale coesistessero generatori e
consumatori di energia.
La struttura della LeafHouse Loccioni è nel dettaglio composta da:
 2 appartamenti, ognuno con un contatore ENEL e un contratto da 3 KW
 1 sistema a pannelli fotovoltaici della potenza di 5 KW
 1 sistema di accumulo con batterie al Litio di capacità 120 Ah
65
Gli elementi appena elencanti hanno differenti componenti BEHAVIOR. Nel caso degli
appartamento (consumo elettrico) e dei pannelli (generazione elettrica) sono stati modellati
con l‟accesso a dati storicizzati di precedenti mensilità (acquisiti e memorizzati nel 2012).
Nel caso invece della batteria, è stato realizzato in LabVIEW un suo modello approssimato,
in grado di simulare l‟andamento della quantità assorbita/rilasciata dalla batteria stessa
durante i suoi cicli di carica/scarica. Tale modello non verrà direttamente descritto in questa
tesi, poiché parte di un lavoro di ricerca portato avanti parallelamente a quello presentato in
questo lavoro.
La modellazione della componente PLUG degli elementi che compongono la LeafHouse è
stato invece frutto di un accurato processo di design della PN in grado di modellare ogni
Agente, per poi successivamente unire tutti gli agenti tra loro in un'unica rete che
permettesse di modellare l‟interazione con la risorsa da parte di tutti gli elementi coinvolti.
Un primo passo è stato quello di collassare in unico posto i consumi di tutti gli
elettrodomestici, in modo da poter rappresentare il concetto di appartamento all‟interno
della PN dell‟intero sistema Figura 5.8.
Figura 5.8 - Creazione modello PN di un appartamento
66
Il risultato è stato un‟unica PN, capace di fare interagire con la risorsa tutti gli agenti e
contenente al suo interno i vincoli di funzionamento di ogni Agente, permettendo a livello
di evoluzione della marcatura solo scatti che portassero verso azioni fisicamente realizzabili
nel sistema. La struttura della PN complessiva è riportata in Figura 5.9, dove con App1 e
App2 si fa riferimento ai due carichi modellati nel sistema relativi ai 2 appartamenti della
LeafHouse.
Figura 5.9 - PN della LeafHouse
Nella Appendice A.3 viene riportata un immagine dove è possibile identificare nel dettaglio
la funzione di tutte le componenti della PN del sistema complessivo.
Azione di controllo
A livello di singole PN degli agenti sono stati inseriti tutti quei vincoli fisici che erano
propri del funzionamento degli agenti modellati (e.g. massima potenza erogabile dai
pannelli, massima energia accumulabile/erogabile dalla batteria). Sulla PN ottenuta dopo il
processo di fusione tra le PLUG sono successivamente stati inseriti ulteriori vincoli logici,
in grado di condurre l‟evoluzione dello stato della marcatura della PN complessiva verso
una precisa direzione, quella dell‟autoconsumo.
Sono state per questo inserite delle priorità imposte con archi inibitori e posti monitor per
privilegiare il consumo di energia autoprodotta nei confronti di quella acquistata dal
provider nazionale (e.g. ENEL).
Il processo di inserimento dei vincoli ha reso la PN complessiva più ricca di connessioni tra
i posti e le transizioni (Figura 5.10), riducendo le dimensioni dell‟albero di raggiungibilità
della sua marcatura. La riduzione del albero si è spinta al punto tale da permettere in tutte le
67
possibili situazioni una sola azione, lasciando una sola transizione abilita e imponendo in
questo modo un evoluzione forzata della marcatura, in questo particolare caso verso il
massimo autoconsumo.
Figura 5.10 - Inserimento vincoli Autoconsumo
Le caratteristiche della PN nella sua ultima configurazione e la sua capacità di permettere
un evoluzione solo verso soluzioni che massimizzino l‟autoconsumo la rendo un sistema di
controllo vero e proprio. Infatti sulla base di informazioni datele in ingresso, come la
marcatura iniziale e la richiesta di scatto di transizioni collegate ai BEHAVIOR degli
Agenti, la PN è in grado di rispondere con un‟azione di controllo ben precisa lasciando
abilitata la sola transizione che rappresenti un comportamento orientato all‟autoconsumo.
La procedura che permette di utilizzare la PN come sistema di controllo è sintetizzata in
Figura 5.11.
Figura 5.11 - Sistema di controllo basato su PN
Una breve descrizione del software che implementa questa terza sistema di controllo è data
nel capitolo 6.
68
6. Software di Simulazione/Emulazione
In questo capitolo verranno presentate le soluzioni software adottate per implementare
quanto anticipato nei precedenti capitoli e verrà descritto l‟ambiente di
simulazione/emulazione HAS-Sim, punto di arrivo di sviluppi successivi di strumenti per lo
studio, l‟analisi e la sintesi di algoritmi di gestione per ambienti domotici. Assieme
all‟ambiente di simulazione verrà anche mostrato come le strategie di controllo, descritte in
5.3, siano state inserite all‟interno del software per essere validate.
Il simulatore HAS-Sim realizzato, è basato sull‟ idea dell‟interazione continua, seppur
semplice, di molti elementi che genera comportamenti globali molto vari e complessi
caratteristici di quei sistemi difficilmente descrivibili attraverso l‟approccio classico.
Si sviluppa secondo queste regole il simulatore HAS-Sim, che è stato realizzato in
LabVIEW perché efficace nella costruzione di soluzioni personalizzate per sistemi
scientifici ed ingegneristici garantendo buone performance e flessibilità, attraverso un
linguaggio di programmazione che non si presenta né difficile né complesso. Questo
approccio mette a disposizione un ambiente modulare in grado di fornire uno strumento per
la realizzazione di svariati ambiento domotici, all‟intero del quale è possibile aggiungere e
rimuovere vari dispositivi, con l‟aggiunta o la rimozione dei rispettivi moduli.
Si può affermare che nel caso particolare del simulatore HAS-Sim sia composto da moduli
indipendenti che condividono risorse comuni, energia elettrica, attraverso la definizione di
opportune variabili globali che ne stabiliscono le disponibilità.
La gestione delle variabili globali per un elettrodomestico, riesce a fornire servizi come:
comunicare agli altri il proprio assorbimento istantaneo di energia elettrica, il consumo
totale del sistema di potenza elettrica, interrompere o sospendere il proprio funzionamento,
ecc. Ai modelli simulati di elettrodomestici verranno affiancati anche elettrodomestici reali,
il cui BEHAVIOR non è presente all‟interno del software, ma proviene da acquisizioni fatte
da smart plug connesse al software si simulazione/emulazione. Le operazioni di scambio
d‟informazioni attraverso il bus di comunicazione con plug reali si traducono quindi
nell‟ambiente simulato nella scrittura e nella lettura di semplici variabili globali.
La descrizione del software sarà divisa in due parti:
1. la prima sarà relativa al HAS-Sim nella sua versione 2.8, punto di arrivo della
collaborazione con il centro di ricerche ENEL IIR e che integra nel suo software
quanto descritto nelle sezioni 4.2, 5.1, 5.2, 5.3.1 e 5.3.2 relative alla gestione dei
picchi di potenza istantanea e al mantenimento della taglia energetica
2. la seconda sarà relativa ad un‟estensione della versione 2.8 dell‟HAS-Sim,
integrando nel suo software quanto descritto nelle sezioni 4.4 e 5.3.3 relative alla
69
gestione di sistemi con più provider energetici e alla massimizzazione
dell‟autoconsumo dell‟energia prodotta in modo autonomo dal sistema domotico
Per rendere più chiara la descrizione del software e l‟implementazione degli strumenti
presentati nel capitolo 3, verrà portato un esempio di ambiente costruito per ottimizzare le
gestioni di potenza istantanea (W) e dell‟energia (Wh) elettriche all‟interno di una moderna
abitazione nel capitolo 7.
6.1
Gestione potenza istantanea e taglia energetica
Il simulatore HAS-Sim nella sua versione 2.8 è possibile installarlo in un qualsiasi PC
dotato di una versione di LabVIEW 2011, una di Matlab 6.5 e una Java Virtual Machine 6 o
superiori. Tutti i file a cui si fa riferimento in questa sezione possono essere installati da un
setup file “HAS-Sim-v2.8-Installer.exe” sviluppato per un‟agevole distribuzione del
software su molteplici piattaforme hardware.
Il simulatore HAS-Sim 2.8 mette a disposizione le seguenti funzionalità:


Gestione della Potenza istantanea [W]:
o
per evitare il distacco forzato da parte del contatore ENEL GEM GET1
nella seconda, terza e quarta condizione di carico descritte in Figura 5.6
assegnando le priorità di distacco degli elettrodomestici
o
Gestione dei watt come token di una PN, la cui struttura rappresenta le
prese elettriche e le loro dinamiche di distacco in base alle priorità
indicate dell‟utente
o
Disconnessione/Riconnessione elettrodomestici in base alla priorità
assegnate dall‟utente
Gestione dell’Energia [Wh]:
o
Stima della taglia di appartenenza dell‟utente, tenendo conto del numero
di abitanti dell‟appartamento, del tipo di elettrodomestici presenti nella
casa e del numero delle volte che mediamente vengono fatti partire
settimanalmente (informazioni fornite dall‟utente)
70
o
Calcolo del consumo di energia dell‟intera abitazione e degli
elettrodomestici principali (Lavatrice, Lavastoviglie, Forno, Frigorifero)
o
Suggerimenti su come mantenere la taglia stimata utilizzando l‟Algoritmo
Taglie nella sezione 5.3.2
o
Comunicazione all‟utente tramite interfaccia grafica del livello di
consumo della propria taglia e dell‟eventuale previsione di sforamento
della stessa ne caso fossero mantenute le abitudini fino a quel momento
6.1.1 Costruzione dell‟ambiente di simulazione in LabVIEW
Al fine di costruire in LabVIEW un ambiente domotico da prendere come campione per
testare e validare strategie di controllo e gestione è necessario partire dalla costruzione di
un LabVIEW project con i diversi componenti messi a disposizione dal tool HAS-Sim v2.8.
Il progetto LabVIEW contenente il simulatore è contenuto nel file z_HAS_SIM.lvproj,
presente nella cartella dove è stato installato il simulatore, (e.g. “C:\Programmi\HASSim\HAS_SIM_2.8”).
E‟ possibile aprire il progetto anche dal menù Start: “Start  Programmi  HAS-Sim 
HAS-Sim v2.8”
Il progetto una volta aperto si presenta a video con la seguente schermata in cui sono
elencati tutti i vi realizzati:
Figura 6.1 - LabVIEW project HAS-Sim 2.8
71
All‟interno del progetto si trovano diverse directory virtuali che organizzano i diversi
componenti software del simulatore in categorie.
I moduli software (file .VI di LabVIEW) sono così organizzati nelle directory (Figura 6.2):


Appliances: elettrodomestici modellati dal simulatore che possono essere utilizzati
all‟interno dell‟ambiente domotico simulato
Classes: classi UML che descrivono gli attributi e i metodi che caratterizzano gli
elettrodomestici e i sistemi di controllo presenti nel simulatore

Real PLUGs: vi per la gestione delle PLUG reali che possono essere gestite dal
simulatore

Statecharts: sono i diagrammi a stati nel formato fornito da LabVIEW che
implementano operativamente l‟evoluzione a stati del comportamento di
elettrodomestici e sistemi di controlli, rispecchiando la loro formalizzazione UML

Utiltiy e Utility2: insieme di VI che sono stati realizzati per implementare
operazioni fondamentali che vengono richiamate dagli altri VI del progetto
Figura 6.2 - Dettaglio LabVIEW project HAS-Sim 2.8
72
Nel dettaglio abbiamo:

come Appliances la lavastoviglie (DW: DW_PN.vi), il frigorifero (FRIDGE:
FRDIGE_PN.vi), il forno (OVEN: OVEN_PN.vi) e la lavatrice (WM: WM_PN.vi).
L‟acronimo PN sta per Petri Net ed identifica che gli elettrodomestici hanno alla
loro base una modellazione con rete di Petri del loro comportamento elettrico e
che nella loro implementazione sono stati resi reattivi ad eventi collegati
all‟evoluzione della rete di Petri del sistema

come Classes le classi relative agli elettrodomestici (DW_PN.lvclass,
FRDIGE_PN.lvclass, OVEN_PN.lvclass e WM_PN.lvclass) e la classe di gestione
delle reti di Petri (PN.lvclass). La classe PN.lvclass mette a disposizione metodi
per l‟accesso alla rete (lettura marcatura, scatto transizioni) e attributi che la
definiscono (path del file .RDP dove è salvata)

come Real PLUGs dei VI realizzati per inserire nel simulatore un‟interfaccia con
fino a 3 elettrodomestici reali. Per fare ciò per ognuno degli elettrodomestici è
stato fornito:
o un VI dove inserire il codice che vada a spegnere l‟elettrodomestico (e.g.
“APPLIANCE_x_Off.vi”)
o un VI dove inserire il codice che vada ad accendere l‟elettrodomestico
(e.g. “APPLIANCE_x_On.vi”)
o un VI dove inserire il codice che vada a leggere l‟attuale consumo di
potenza dell‟elettrodomestico (e.g. “APPLIANCE_x_Read_Power.vi”)

come Statecharts i diagrammi a stati di tutti gli elettrodomestici (DW_PN.lvsc,
FRDIGE_PN.lvsc, OVEN_PN.lvsc e WM_PN.lvsc) più il diagramma a stati del
controllore della potenza istantanea (controllore.lvsc) dove è implementata la
politica di controllo con cui viene deciso se disconnettere o meno gli
elettrodomestici che stanno consumando energia in caso si verifichi una situazione
di overload.

Come utility principali sono presenti i .VI di controllo:
o controllore.vi: monitorizza e gestisce la potenza istantanea, l‟evoluzione
della rete di Petri del sistema e si occupa dell‟attuazione della
connessione/disconnessione delle prese (PLUG) a cui sono connessi gli
elettrodomestici misurati
o PL_PN.vi: è la componente del simulare che rappresenta il
contatore/limitatore (Power Limiter). Fondamentalmente si occupa di
misurare il consumo energetico dell‟intero sistema e condividere le
73
o

informazioni raccolte su di una lavagna condivisa (Global VI.vi
all‟interno di della directory virtuale Utility). Dalla sua interfaccia grafica
è possibile osservare il consumo di energia istantaneo
supervisor.vi: in questo VI è implementato l‟Algoritmo taglie descritto in
5.3.2. I valori dei serbatoi, che vengono aggiornati ogni 15 minuti,
vengono mandati sulla dashboard rappresentata dal Globa VI.vi nella
directory virtuale Utility
nella directory principale My computer è presente il VI di interfaccia utente che
fornisce l‟accesso alle funzionalità del simulatore:
o user_interface.vi: è il VI con il quale è possibile gestire l‟intero
simulatore. In modo automatico accede alle funzionalità offerte degli altri
componenti software presenti nel progetto e inizializza e porta a termine
la simulazione. Salvando, quando richiesto e a al termine della
simulazione, su file i dati relativi alle grandezze in gioco (consumo di
potenza [W], stato delle prese, energia [Wh], stato dei serbatoi relativi
all‟Algoritmo taglie). Questo VI mette a disposizione anche
un‟interfaccia grafica che permette di monitorare l‟andamento della
simulazione durante la sua esecuzione. La descrizione del suo utilizzo e
interpretazione dei risultati verrà descritta nei seguenti capitoli.
Nell‟attuale versione dell‟HAS-Sim, gli elettrodomestici resi disponibili nella casa virtuale
non possono essere avviati dall‟utente singolarmente attraverso il loro VI, presente nella
directory “Appliances”, ma solo attraverso la schedulazione dell‟attività nel pannello del
“user_interface.vi”, nella implementazione di esempio si è scelto di gestire gli scheduling
mensili attraverso quattro settimane su quattro file separati modellati sugli scenari proposti.
All‟interno di questi file sono riportati gli istanti di avvio di tutti gli elettrodomestici con un
campionamento degli eventi ogni 30 minuti. Inoltre nei file che vengono caricati
(yymm_HOME1_FAM1_Wkx.txt) sono presenti anche le abitudini di comportamento
settimanali espresse dall‟utente, oltre che il numero degli abitanti della casa.
Il modo con cui andare a compilare i file che devono essere dati in ingresso al simulatore al
suo avvio verrà descritto nei prossimi paragrafi.
Elettrodomestici simulati
Come visto dai file che caratterizzano gli elettrodomestici, ogni appliance è caratterizzato
dai seguenti elementi relativamente alla sua componente BEHAVIOR:
 Uno Statechart (file con estensione lvsc);
 Una classe UML (file con estensione lvclass);
 Un VI che richiama lo Statechart e la classe UML relative
74
Il Front Panel del VI relativo ad un elettrodomestico è rappresentato dagli indicatori di
stato dello stesso (Start, Pause) e da un counter che visualizza le fasi di lavoro e il tempo
necessario per il loro completamento. Come esempio si riporta di seguito il VI della
Washing Machine (WM).
Figura 6.3 - Front Panel WM
Come si può osservare dall‟immagine, non è presente sul Front Panel un pulsante di Start
dell‟elettrodomestico, ma soltanto il led che indica lo stato di accensione. Questo perché
come già accennato, l‟avvio degli elettrodomestici è gestito dal pannello principale di
scenario in simulazione che va ha leggere gli istanti ai quali far avviare i diversi appliance
da dei file di testo che vengono richiesti dal simulatore all‟avvio di ogni simulazione.
Ogni elettrodomestico oltre alla componente BEHAVIOR avrà anche una sua componente
PLUG, la quale è stata modellata con un PN. La particolare PN che è dietro ad ogni
elettrodomestico (simulato e reale che sia) è quella introdotta in 5.3.1 (Figura 5.4).
Le priorità associate alle diverse PLUG del sistema domotico vengono caricate dagli stessi
file di testo che vengono richiesti dal simulatore ad inizio di ogni simulazione. In questi
file, come vedremo in seguito, dovrà essere riportato il numero di token da posizionare nei
posti P4 (Switch On) e P6 (Switch Off) relativi ad ogni PLUG. In questo modo il
simulatore avrà l‟informazione necessaria per andare a modificare la rete di Petri che
prende in ingresso (il file “PNFUS.RDP” presente nella directory del progetto LabVIEW
dal simulatore) inserendo in modo automatico il numero di token indicato nei posti relativi
alle priorità di Switch Off e Switch On.
La costruzione del BEHAVIOR di ciascun terminale è descritta da una sequenza di fasi di
lavoro, con relativi consumi di energia e tempistiche, per mezzo degli strumenti Statechart e
UML. Essi lavoreranno in background al vi del dispositivo, che ne visualizza i risultati sul
75
proprio Front Panel. Nella Figura 6.4 viene portato ad esempio lo Statechart della Washing
Machine, al cui interno sono richiamati i metodi, della classe relativa, per la scrittura e
lettura degli attributi associati alla potenza consumata e alla fase di lavoro in cui
l‟elettrodomestico opera in relazione con la componente PLUG.
Figura 6.4 - Struttura BEHAVIOR/PLUG HAS-Sim 2.8
Si ha un‟ analoga schematizzazione per gli altri elettrodomestici presenti nel sistema
domotico in questione, tranne che per il Generic Appliance che presenta un struttura molto
più semplice, in quanto non viene controllato. La sua rete di Petri si riduce alla sola parte
riguardante il consumo di energia.
Figura 6.5 - Generic Appliance
76
Ciascun elettrodomestico possiede pertanto una sua struttura BEHAVIOR e una PLUG. La
prima appartiene al comportamento del singolo dispositivo mentre la seconda, viene
utilizzata dal controllore per attuare le strategie di consumo energia. A tal fine, è richiesta
una rete di Petri totale con cui è possibile monitorare tutti gli elettrodomestici di cui è
costituito il sistema domotico simulato. Le singole reti possono essere fuse tra loro con i
metodi della teoria classica. In questo caso è stato adoperato un tool di fusione descritto
nella sezione 4.3, che permette di ottenere la seguente rete in Figura 6.6.
Figura 6.6 - PN dell'intero sistema domotico
È possibile notare come le singole reti di Petri siano state fuse insieme in modo tale da
condividere un posto chiamato Power Place.
77
I token presenti nel Power Place della PN totale fusa sono 140 (1 token = 100 W) e
rappresentano la Plim (il massimo valore di potenza istantanea che può essere erogato dal
contatore GEM, Figura 5.6), è questa la massima potenza supportata dal sistema prima di
generare un errore, mostrato da un popup, che termina la simulazione. Questo errore
rappresenta l‟eventuale intervento del contatore ENEL o una situazione di
malfunzionamento (eventuale marcatura negativa della PN), rintracciabile poi nella PN
salvata dal programma e apribile con il software Pipe descritto di seguito.
Figura 6.7 - POPUP errore marcatura negativa PN
All‟interno del controllore è già settato il limite contrattuale disponibile di 3300W prima di
un overload. L‟apertura della rete durante la simulazione può avvenire per mezzo del
software PIPE usando gli apposti pulsanti presenti nel Front Panel di “user_interface.vi”
(“Save PN”, “Open PIPE”). Per poter visualizzare la rete di Petri ad un preciso istante è
necessario premere il pulsante “Save PN” (che andrà a fare un‟ istantanea della rete al
momento della richiesta, aggiornando il file della rete che si trova all‟interno della cartella
del progetto sotto il nome PNFUSA.xml) prima di andarla ad aprire con PIPE premendo il
pulsante “Open PIPE”.
Il programma PIPE è già contenuto all‟interno della cartella del progetto al path
“.\pipe25_rc5\pipe.bat”. Se si vuole accedere all‟ultima rete di Petri salvata mentre si è
fuori dalla simulazione è necessario far partire il programma PIPE utilizzando il file .bat
“.\pipe25_rc5\pipe.bat.”, Figura 6.8.
78
Figura 6.8 - Apertura PN con PIPE
6.1.2 Gestione potenza istantanea
All‟interno del progetto incluso come esempio è stato sviluppato un modulo software (che
verrà chiamato Controllore) in grado di eseguire una strategia di controllo per la gestione
dei sovraccarichi all‟interno del sistema domotico. Esso si basa sul controllo delle priorità
assegnate a ciascun elettrodomestico (vedi sezione 5.3.1). In situazione di overload, ossia al
superamento della soglia contrattuale di potenza (3300 W), il controllore fa scattare la
transizione T5 (nella parte D relativa alla PN del singolo elettrodomestico) per tutti i
dispositivi attivi e controlla il numero di token nel posto P4 (indicante la priorità di switch
Off). L‟azzeramento di tale valore, comporterà l‟inibizione del relativo elettrodomestico da
parte del controllore con lo scatto di T3. Se la situazione di overload risulta non superare il
periodo temporale che porterebbe allo Switch Off di qualche elettrodomestico, le priorità di
Switch Off verranno resettate al valore iniziale. Una volta inibito uno o più
elettrodomestici, al fine di riportare i consumi del sistema domotico al di sotto della soglia
di overload, il controllore inizia a monitorare le priorità di Switch On (delle sole prese
inibite) monitorando il posto P6 e a scalandone il valore con lo scatto di T7 fino
all‟azzeramento, che comporta la riattivazione della presa corrispondente (scatto di T4) e
quindi la concessione di potenza all‟elettrodomestico associato. Il popup di errore, in
precedenza descritto, viene gestito sempre dal controllore che monitora continuamente le
prese dell‟intera rete e il consumo totale del sistema.
79
A differenza degli elettrodomestici, il controllore è costituito da:
 Uno Statechart;
 Un vi che richiama lo Statechart.
Il vi del controllore, mostra sul Front Panel le prese del sistema simulato, il loro stato, un
indicatore luminoso di overload e il numero di sovraccarichi avvenuti durante la
simulazione. Lo stato di ciascuna presa è rappresentato per mezzo di tre led, così
posizionati:
 il primo (in alto) è verde e indica lo stato On della presa, in quanto
l‟elettrodomestico a cui essa è associata, sta richiedendo potenza al contatore;
 il secondo è rosso, e visualizza lo stato di inibizione della presa da parte del
controllore, in seguito ad un overload;
 il terzo led è verde, e segna lo stato Off dell‟elettrodomestico a cui è associata.
Di seguito si visualizza una situazione critica in cui è possibile notare che la presa 1 è
inibita (led rosso) e le prese 2 e 3 sono in stato di On e la potenza richiesta al contatore
supera la fascia di energia contrattuale disponibile, causando un overload del sistema, come
si può notare dal led omonimo acceso.
Figura 6.9 - Front Panel controllore.vi riportata dalla user_interface.vi
In questa situazione le prese sono associate agli elettrodomestici come di seguito:
 PLUG 1 – Washing machine;
80






PLUG 2 – Dishwasher;
PLUG 3 – Oven;
PLUG 4 – Fridge;
PLUG 5 – Appliance 1;
PLUG 6 – Appliance 2;
PLUG 7 – Appliance 3.
Dove gli Appliance 1, 2 e 3 rappresentano delle prese lasciate libere dove poter collegare
fino a 3 nuovi elettrodomestici realizzati come quelli collegati alle prese dalla 1 alla 4,
oppure utilizzando i VI della directory “Real PLUGs” è possibile inserire degli
elettrodomestici reali.
L‟informazione fornita dal controllore sullo stato di overload e sullo stato delle PLUG
viene inviata alla dashboard del simulatore (Global VI.vi). Tale informazione viene poi
prelevata dall‟interfaccia utente (user_interface.vi) per essere comunicata all‟utente.
6.1.3 Stima e gestione delle taglie energetiche
Questo modulo software del simulatore implementa l‟algoritmo della gestione taglie
descritto nella sezione 5.3.2. Al suo interno vengono calcolati e gestiti i serbatoi di energia
(Wh) nbase , n1 , n2 e in base al valore che tali serbatoi assumono durante la simulazione
vengono comunicati dei comandi di disconnessione delle PLUG al controllore, il quale si
occuperà della disconnessione effettiva, in concomitanza con la sua politica di controllo
basata sulla gestione della potenza istantanea (W).
Il modulo software dedicato a questi compiti verrà chiamata Supervisore e agisce in
parallelo al Controllore, ed è per questo motivo che non va direttamente lui a disconnettere
le prese, ma rimanda la richiesta al controllore, in modo tale da evitare conflitti tra le due
politiche di controllo. Infatti nel caso una presa fosse in fase di Switch Off, la richiesta di
un comando di disconnessione da parte del Supervisore viene interpretata dal Controllore
come una priorità da soddisfare immediatamente, andando a sospendere il countdown di
switch off (resettando la relativa priorità) e disconnettendo immediatamente la PLUG.
Il Supervisore si occupa anche di interpretare i valori dei serbatoi durante e a fine
simulazione, in modo da poter sintetizzare una serie di informazioni con cui andare ad
avvisare l‟utente sullo stato dei consumi. Gli avvisi forniti dal Supervisore sono:
1. la percentuale di taglia consumata nel mese (aggiornata ogni 15 minuti) - Figura
6.10:
a. valore numerico
b. indicatore grafico
2. La percentuale di energia presente nei serbatoi Rbase, R1 e R2 - Figura 6.11
81
3. la previsione di sforamento o meno della taglia a seconda dello storico di consumi
dei precedenti 3 giorni. Ciò viene fatto analizzando i dati che vengono raccolti nel
VI “print_data.vi” e che poi vengono passati ogni 15 min al VI “stima n2.vi”. Il
risultato fornito da quest‟ultimo VI a fine di ogni giornata viene utilizzato per
selezionare lo stato del semaforo - Figura 6.12
Queste informazioni vengono inviate sulla dashboard del simulatore (Gloabl VI.vi) e
raccolte dalla ”user_interface.vi” per essere comunicate all‟utente.
Figura 6.10 - Percentuale di taglia consumata nel mese
Figura 6.11 - Livelli dei serbatoi in percentuale
Per quanto riguarda il semaforo nel dettaglio:
 il led verde indica che previsionalmente la taglia stimata non verrà oltrepassata

il led arancione indica che previsionalmente la taglia stimata verrà oltrepassata (n 2
della settimana corrente verrà esaurito prima di terminare la settimana)
82

il led rosso indica che la taglia è stata oltrepassata in base allo stato di n2 (n2 della
corrente settimana è stato esaurito)
Figura 6.12 - Semaforo di allerta superamento taglia
Il tasto “Variable scheduling” accanto al semaforo permette di rendere il simulatore
sensibile allo stato del semaforo. In questo modo il simulatore cambierà lo scheduling da
seguire in base al semaforo, andando a selezionare uno scheduling di basso consumo nel
caso che il led sia arancione o rosso. Gli scheduling in questione dovranno essere caricati
ad inizio simulazione e comprendere due diversi scheduling, uno relativo ad un
comportamento standard degli utenti e uno relativo ad un comportamento di basso consumo
energetico. Questo secondo comportamento dovrebbe rispecchiare una eventuale variazione
nelle abitudini energetiche degli abitanti della casa nel caso in cui il sistema allerta
superamento taglia indicasse un comportamento scorretto.
6.1.4 Scheduling comportamento abitanti
All‟avvio di ogni simulazione l‟HAS-Sim 2.8 richiede tramite 2 popup di selezionare 2
directory. Di default il simulatore visualizzerà come cartella da dove caricare gli scheduling
la cartella “SCHEDULING” presente nella stessa cartella del progetto del simulatore:
1. La prima directory che deve essere scelta è quella contenente i 4 file .txt che
descrivono le abitudini degli inquilini e lo scheduling NORMAL degli
elettrodomestici nelle 4 settimana (istante di avviamento programmato per ogni
elettrodomestico, campionato ogni 30 minuti). Con NORMAL si intende lo
scheduling principale, cioè quello che rispecchia il comportamento dell‟utente che
si vuole simulare.
83
2. La seconda directory che deve essere scelta è quella contenente i 4 file .txt che
descrivono le abitudini degli inquilini e lo scheduling LOW degli elettrodomestici
nelle 4 settimana (istante di avviamento programmato per ogni elettrodomestico,
campionato ogni 30 minuti). Con LOW si intende lo scheduling secondario a
basso consumo energetico, cioè quello che rispecchia un comportamento di
risparmio dell‟utente che verrebbe intrapreso nel caso in cui l‟utente stesso fosse
sensibile allo stato del semaforo che stima lo sforamento della taglia.
I file degli scheduling dovranno avere il seguente formato:
AAMM_HOMEx_FAMy_WK1.txt
AAMM_HOMEx_FAMy_WK2.txt
AAMM_HOMEx_FAMy_WK3.txt
AAMM_HOMEx_FAMy_WK4.txt
(e.g. 1107_HOME1_FAM1_WK1.txt)
Per rendere più agevole la compilazione di questi file si è preferito non andare a modificare
direttamente i file .txt, ma sono stati forniti 4 file .xls (EXCEL) che possono essere
utilizzati per inserire i dati della particolare simulazione che si vuole far partire. Una volta
terminata la compilazione, i file EXCEL devono essere salvati come file di “Testo
(delimitato da tabulazioni) (*.txt)” per generare i file che possono essere accettati dal
simulatore.
I valori di “x” e “y” che indicano il tipo di casa ed il tipo di famiglia che abita nella casa
sono scelti a piacimento dall‟operatore che deve andare a compilare i file. Tali valori
saranno utili per poter catalogare i tipi di scenari che verranno creati. Il simulatore non
andrà ad utilizzare direttamente questi valori, ma differenzierà tra di loro i file solo in base
alla settimana che rappresentano, in modo da inserire lo scheduling nella simulazione in
modo cronologico.
Di seguito verrà descritta la procedura di compilazione dei file .xls, la conversione in .txt e
il loro collocamento nella cartella del progetto LabVIEW del simulatore/emulatore HASSim 2.8.
Compilazione file .xls
Per l‟inserimento delle abitudini e dello scheduling vengono forniti all‟interno del progetto
4 file .xls che possono essere editati per inserire le informazioni relative al proprio scenario.
I file si trovano, rispetto al progetto del simulatore, all‟interno della cartella:
“.\SCHEDULING\HOME1_FAM1\XLS”.
Tali file devono essere compilati tutti e 4 per poter andare a definire lo scheduling delle 4
settimane del mese. Per quanto riguarda invece le abitudini di utilizzo degli elettrodomestici
84
e le priorità di disconnessione a loro associate è necessario inserirle nel primo file
(.*WK1.xls). Nei successivi 3 file possono essere ricopiate per completezza, ma il
simulatore andrà a leggere le informazioni sulle abitudini solamente dal primo file.
All‟interno del file devono essere compilate le seguenti sezioni (Figura 6.13):
1. PRIORITY: priorità di Switch Off di WM, DW, OVEN, FRIDGE e APPLIANCE
1,2 e 3. Rappresentano il numero di token ND che andrà posizionato nel posto P4
delle sotto delle PLUG relative agli elettrodomestici.
Il valore di NC verrà calcolato ed inserito automaticamente dal controllore in modo
complementare andando ad associare una priorità di Switch On inversa a quella di
Switch Off scelta dall‟utente.
2. HABITS:
a. TENANTS: è il numero di persone che vive nella casa
b. APPLIANCES WEEKLY FREQUENCY: è il numero di volte che un
elettrodomestico verrà fatto partire durante la settimana. E‟ una
previsione che da l‟utente sulla base delle sue abitudini
c. SCHEDULING: sono gli istanti ai quali l‟utente farà partire i diversi
elettrodomestici. Sulla base di questa informazione il simulatore andrà a
fare partire gli elettrodomestici in modo automatico. E‟ per questo motivo
che gli elettrodomestici non possono essere più avviati manualmente, ma
solamente messi in pausa, infatti la fase di avvio è gestita dal simulatore e
schedulata partendo dalle informazioni fornite da un operatore che ha
compilato il file .xls
La schedulazione è stata campionata ogni 30 minuti e gli elettrodomestici
partiranno in automatico all‟inizio della mezzora in cui è stato indicato
con un “1” che debbano partire. Nel caso viene trovato uno “0” il
simulatore non interviene.
La procedura si ripete identica per i 7 giorni della settimana e per i 4
elettrodomestici schedulati (WM, DW, OVEN, FRIDGE).
Da notare che nel caso del FRIDGE il ciclo di funzionamento non ha
termine, perciò dal primo istante in cui viene avviato rimane sempre
accesso.
85
Figura 6.13 - AAMM_HOMEx_FAMy_WK1.xls
Conversione da .xls a .txt
Una volta compilati, i 4 file .xls devono essere convertiti in .txt per essere accettati dal
simulare.
Per fare ciò è sufficiente per ognuna delle settimane:
 aprire il relativo file .xls
 fare click su “Salva con nome”
 prima di salvare selezionare come “Tipo file” “Testo (delimitato da tabulazione)
(*.txt)”
 dare un nome compatibile con la struttura “AAMM_HOMEx_FAMy_WKz.txt”
 cliccare su Salva
I file TXT salvati, una volta aperti, si presenteranno come in Figura 6.14.
Figura 6.14 - AAMM_HOMEx_FAMy_WK1.txt
86
I 4 file .txt salvati dovranno essere collocati in una stessa cartella. La cartella deve avere un
nome compatibile con quello dei file .txt, cioè con la struttura “AAMM_HOMEx_FAMy”
(per esempio 1107_HOME1_FAM1) e deve essere collocata all‟interno della cartella
SCHEDULING presente nella cartella che contiene il progetto LabVIEW del simulatore
(e.g. “C:\Program Files\HAS-Sim\HAS_SIM_2.8\SCHEDULING”). All‟avvio del
simulatore verrà richiesto di indicare 2 cartelle contenenti questo tipo di file per poter
caricare le abitudini e scheduling NORLAM e LOW.
6.1.5 Interfaccia utente
Una possibile interfaccia utente del simulatore è stata implementata nel modulo software
“user_interface.vi”.Qui si riportano le principali funzioni con un esempio di un possibile
sviluppo
Questo VI si occupa di:
 caricare i file che definiscono lo scheduling dell‟utilizzo degli elettrodomestici e le
abitudini dell‟utente
 inizializzare variabili che vengono condivise con gli altri vi attraverso il “Global
VI.vi”
 avviare:
o PL/PN
o Controllore
o Supervisore
 gestire il tempo della simulazione sincronizzando tutti i moduli chiamati
 gestire il salvataggio dei dati a fine simulazione
 esibire e gestire l‟andamento della simulazione:
o mostrando sul suo Front Panel:
 il grafico della potenza istantanea consumata
 le priorità degli elettrodomestici scelte dall‟utente
 le abitudini di utilizzo degli elettrodomestici scelte dall‟utente
 il numero di abitanti
 la taglia stimata sulla base delle abitudini caricate da file
 l‟avanzamento del tempo della simulazione
 lo stato delle 7 PLUG controllate
 lo stato dei serbatoi
 la percentuale di taglia consumata
 il semaforo che mostra la stima dell‟andamento di n2
comunicando se previsionalmente la teglia sarà sufficiente
o permettendo:
 di controllare la quantità di energia consumata dal Generic
appliance
 di controllare l‟accelerazione temporale della simulazione
87





di rendere il simulatore sensibile allo stato del semaforo
di salvare i dati della simulazione in ogni momento
di salvare lo stato della rete di Petri ad un certo istante
di mostrare la rete di Petri salvata
abilitare o disabilitare le politiche di controllo disponibili
(controllore e supervisore)
Front panel
Aprendo il VI “user_interface.vi” viene aperte l‟interfaccia in Figura 6.15, dove sono
presenti tutti gli indicatori ed i controlli descritti.
Figura 6.15 - Interfaccia utente (user_interface.vi)
88
Sezioni “user_interface.vi”
Il Front Panel del VI user_interface.vi è stato suddiviso in 5 sezioni. Nel dettaglio le sezioni
sono le seguenti:
1. Abitudini utente caricate da file - sono i dati sulle abitudini di consumo normali
degli abitanti della casa, contenute nei file di testo caricati come “NORMAL
SCHEDULING” . Vengono riportati:
a. il numero di inquilini
b. il numero di volte che ogni elettrodomestico viene fatto partire durante
una settimana
c. le priorità di Switch Off degli elettrodomestici
d. la taglia che è stata stimata sulla base delle abitudini
2. Monitoraggio W, Taglia e Serbatoi – sono le informazioni relative ai consumi.
Vengono riportati:
a. il consumo istantaneo di potenza in watt in un grafico
b. la percentuale di energia della taglia che è stata consumata fino a quel
momento
c. la percentuale di gettoni energia presenti nei serbatoi Rbase , R1 , R2
d. un semaforo che indica la previsione sull‟andamento di n2
E‟ inoltre possibile selezionare con il tasto “Variable scheduling” la
sensibilità del simulatore allo stato del semaforo. Se il tasto è premuto il
simulatore selezionerà un profilo di basso consumo a semaforo giallo o
rosso
3. Monitoraggio e gestione del tempo della simulazione – informazione e controllo
sul tempo della simulazione. E‟ possibile:
a. avere informazione sul giorno ora e minuto e secondo si simulazione
attuale (in modo testuale e grafico). Una volta che la barra gialla
raggiunge la fine del 28° giorno la simulazione termina.
b. controllare la velocità di simulazione, accelerando rispetto alla velocità
reale di esecuzione
4. Azioni di controllo permesse all’utente – L‟utente durante la simulazione può:
a. attivare o disattivare le politiche di controllo (contemporaneamente sia il
Supervisore energia che il Controllore potenza) usando il tasto
“Controller & Supervisor ON/OFF”
b. decidere se a fine simulazione (dopo 28 giorni o premendo il tasto STOP)
devono essere salvati i dati sui consumi di energia, potenza e sui serbatoi
premendo il tasto “Save DATA”
89
c. salvare istantaneamente i dati della simulazione senza interromperla
premendo sui tasti “Save Power NOW” (salvataggio dei dati della
potenza istantanea – salvataggio istantaneo) “Save Energy NOW”
(salvataggio dei dati dell‟energia – salvataggio al termine del primo
multipolo successivo di 15 min del tempo di simulazione)
d. fare una fotografia del sistema premendo il tasto “Save PN” andando a
salvare la rete di Petri all‟istante del click
e. aprire il software PIPE presente nella cartella del progetto premendo il
tasto “Open PIPE” per andare ad aprire la rete di Petri salvata facendo
click su “Save PN” precedentemente descritto
f. variare la quantità watt assorbiti da un generico dispositivo, non
controllato, presente nella rete domotica, la cui potenza può essere variata
durante la simulazione muovendo la barra orizzontale “Not controlled
appliance [W]”
g. terminare la simulazione premendo il tasto “STOP”. Nel caso sia stato
attivato il salvataggio dei dati premendo “Save DATA” verranno salvati
dei file .txt contenenti i valori assunti durante la simulazione della
potenza, dall‟energia e da i serbatoi
5. PLUG controllate – mostra lo stato delle prese dell‟ambiente simulato
a. sono presenti 7 prese il cui stato può essere OFF (nessun assorbimento
misurato – led basso verde), ON (la prese assorbe energia – led alto
verde) o STOP (la presa è stata inibita dal controllore – led centrale
rosso)
b. viene indicato lo stato di overload (consumo in potenza istantanea del
sistema > 3300 watt)
6.1.6 Avvio di una simulazione/emulazione
Il simulatore/emulatore “HAS-Sim 2.8” è contenuto nella directory dove è stato installato
con
l‟installer
“HAS-Sim-v2.8-Installer.exe”
(e.g.
“C:\Programmi\HASSim\HAS_SIM_2.8”). Verranno adesso indicati i passi per eseguire una simulazione
completa.
Avvio simulatore
Aprire il progetto LabVIEW facendo click due volte sul file “Z_HAS_SIM.lvproj” presente
nella cartella del simulatore (o andate sotto “Start  Programmi  HAS-Sim  HAS-Sim
v2.8”
1. aprire il vi “user_interface.vi” presente nel progetto
90
2. mandare in Run “user_interface.vi”
3. selezionare la cartella dove sono state descritte le abitudini e lo scheduling
NORMAL degli elettrodomestici indicando come “Current Folder” la cartella
contenente i 4 file TXT descritti in precedenza: raggiungere l‟interno della cartella
contenente i 4 file TXT e fare click su “Current Folder”.
4. Selezionare la cartella dove sono state descritte le abitudini e lo scheduling LOW
allo stesso modo:
Gestione simulazione
Durante la simulazione l‟operatore attraverso il Front Panel della user_interface.vi può
interagire con l‟HAS-Sim 2.8. Le funzioni principali della user_interface sono:

Pulsante “Controller & Supervisor ON/OFF” - Permette di decidere di disattivare il
Controllore e il Supervisore (di default i sistemi di controllo sono attivi, ma
deselezionando il pulsante è possibile far andare il sistema senza controllo, ma con il
solo monitoraggio dell‟Energia e aggiornamento del contenuto dei serbatoi). Una volta
disattivato il controllo non è più possibile andare a riattivarlo poiché vengono persi
degli eventi nell‟evoluzione della rete di Petri che non possono essere recuperati una
volta che la simulazione è in Run.

Pulsante “Save DATA” - Permette di decidere di salvare o meno dei file TXT dove
sono stati riportati i consumi di Potenza, Energia, il contenuto dei serbatoi, lo stato del
semaforo e delle PLUG. Se questo tasto è premuto si ha che:
o Al termine della simulazione vengono salvati tutti i dati di Potenza ed Energia
o Se la simulazione viene arrestata con il pulsante STOP vengono salvati tutti i dati
di Potenza ed Energia
o Se viene premuto il pulsante “Save Power NOW” o “Save Energy NOW” vengono
salvati rispettivamente i dati sulla Potenza e sull‟Energia
Se il pulsante “Save DATA” invece non è premuto, in nessun caso vengono salvati i
dati.

Pulsante “Save Power NOW” - salva istantaneamente tutti i dati relativi alla
potenza senza interrompere la simulazione:
o Consumo di potenza campionato al secondo
o Stato delle 7 plug campionato al secondo
91

Pulsante “Save Energy NOW” – salva, al prossimo multiplo di 15 min del tempo
di simulazione, tutti i dati relativi all‟energia senza interrompere la simulazione:
o Consumo energetico complessivo campionato ogni 15 min
o Serbatoi n1, n2 e nbase campionati ogni 15 min
o Stato del semaforo campionato ogni 15 min

Pulsante “Save PN” - Permettere di salvare la rete di Petri che rappresenta una
fotografica del sistema al momento del click sul pulsante

Pulsante “Open PIPE” - Permette di aprire il programma PIPE con cui andare ad
aprire e visualizzare la rete di Petri salvata con il pulsate “Save PN”

Pointer Slide control “Not controller appliance [W]”- Permette di selezionare il
numero di watt che sono consumati da un elettrodomestico generico non
controllato (per esempio l‟illuminazione della casa)
Pointer Slide control “Acceleration” - Permette di accelerare la velocità della
simulazione rispetto al tempo reale (valore massimo di accelerazione dipendente
dall‟hardware del PC su cui gira il simulatore). Nel caso l‟accelerazione desiderata
non fosse raggiungibile il simulatore accelera fino alla massima velocità che riesce
a raggiungere (Suggerimento non superare un accelerazione di 20x)


Pulsante “Variable scheduling” - rende il simulatore sensibili allo stato del
semaforo passando allo scheduling LOW nel caso in cui il semaforo sia Arancione
o Rosso

Pulsante “STOP” - Termina la simulazione e salva i dati accumulati su file TXT
se al momento del click il pulsante “Save DATA” risulta premuto
Dati salvati
A fine simulazione (terminati i 28 giorni o dopo aver premuto del tasto “STOP”) se il tasto
“Save DATA” risulta premuto, vengono salvati 8 file TXT relativi alla Potenza e 5 file
TXT relativi all‟Energia. Cliccando invece su “Save Power NOW” vengono salvati i soli 8
file relativi alla Potenza, cliccando invece su “Save Energy NOW” vengono salvati i soli 5
file relativi all‟Energia
I file verranno salvati all‟interno della directory “SAVED FILES” presente nella stessa
cartella del progetto del simulatore.
92
Salvataggio della Potenza:
 AAMMGG_HHMMSS_plot_power.txt
o Contiene un campionamento al secondo della potenza istantanea [W]
consumata

AAMMGG_HHMMSS_plot_PLUG1.txt/AAMMGG_HHMMSS_plot_PLUG7.txt
o Vengono salvati 7 file TXT contenenti un campionamento al secondo
dello stato di ogni relativa presa (Stato di ON, OFF o STOP)
Salvataggio dell‟Energia:
 AAMMGG_HHMMSS_plot_energy.txt
o Contiene un campionamento ogni 15 minuti (900 secondi) dell‟energia
[Wh] consumata dall‟intero sistema

AAMMGG_HHMMSS_plot_n_base.txt
o Contiene un campionamento ogni 15 minuti (900 secondi) dell‟energia
[Wh] consumata dalla componente del sistema complementare a quella
sotto controllo. Rappresenta il valore nbase,15 descritto in.

AAMMGG_HHMMSS_plot_n1.txt
o Contiene un campionamento ogni 15 minuti (900 secondi) dell‟energia
[Wh] consumata dalla componente del sistema sotto controllo
(elettrodomestici controllati). Rappresenta il valore n1,15.

AAMMGG_HHMMSS_plot_n2.txt
o Contiene un campionamento ogni 15 minuti (900 secondi) dell‟energia
[Wh] ancora disponibile come energia di riserva. Rappresenta il valore
n2,15.

AAMMGG_HHMMSS_plot_semaphore.txt
o Contiene un campionamento ogni 15 minuti (900 secondi) della stima
della quantità di energia che verrà prelevata/riversata in n2 nei prossimi
giorni. Questa stima si basa sulla media di quantità di energia
prelevata/riversata in n2 nei 3 giorni precedenti. Sulla base di questo
valore varierà lo stato del semaforo mostrato sulla “user_intercafe.vi”
6.2
Massimizzazione autoconsumo
Al simulatore descritto nella precedente sezione (HAS-Sim 2.8) sono state apportate delle
modifiche per poter inserire al posto dei sistemi di controllo Controllore/Supervisore il
93
sistema di gestione basato sulla strategia di controllo di massimizzazione dell‟autoconsumo
descritta in 5.3.3.
Le modifiche hanno permesso la sostituzione della PN in Figura 6.6 con quella in Figura
5.9 (PN di un sistema in cui sono presenti Agenti in grado di erogare energia). E‟ stato per
questo necessario riscrivere il MATLABScript del controllore e ridisegnare lo Statechart del
Controllore in modo da essere compatibile con la nuova PN.
A livello implementativo il codice implementato nel MATLABScript esegue le seguenti
operazioni ogni volta che avviene una variazione nel comportamento dei diversi
BEHAVIOR:
1. Verifica quali posti sono coinvolti nella variazione di consumo energetico (quale
agente ha avuto una variazione del suo carico e della quantità di energia erogata)
2. Individua tutte le transizione che in qualche modo possono essere coinvolte
(scattando) nell‟aggiornamento della marcatura dei posti che hanno avuto una
variazione di consumo/erogazione.
3. Analizzando la struttura della PN (che è stata costruita con l‟obiettivo di evolvere
solo verso stati che massimizzino l‟autoconsumo) individuare l‟unica transizione
attiva che scattando riduce la differenza tra marcatura attuale e stato del sistema,
rispettando la legge di controllo desiderata
Tali operazioni sono state rappresentate in Figura 5.11 e implementate in ambiente
LabVIEW/Matlab.
L‟interfaccia dell‟HAS-Sim è stata modificata per adattarsi alle diverse funzionalità
richiesta dalla nuova politica di controllo. In Figura 6.16 è riportata una parte di tale
interfaccia nella quale è visibile uno solo dei grafici disegnati durante l‟esecuzione dal
software. Infatti durante la sua esecuzione sull‟interfaccia sono visualizzati
contemporaneamente gli andamenti energetici di:
 Produzione fotovoltaica
 Carichi degli appartamenti
 Energia venduta all‟ENEL
 Energia acquistata da ENEL
 Livello di carica della batteria
 Quantità di energia fotovoltaica utilizzata per caricare la batteria
94
Figura 6.16 - Interfaccia utente HAS-Sim LeafHouse
6.2.1 Strumento di dimensionamento
Con in mano uno strumento come quello presentato in 6.2, è stato possibile predisporre
esperimenti con l‟obiettivo non solamente di massimizzare la l‟autoconsumo, ma anche di
identificare quale possa essere la configurazione ideale del sistema.
E‟ infatti un problema diffuso quello del dimensionamento dell‟impianto fotovoltaico e del
sistema di accumulo, poiché essendo sistemi costosi e non ridimensionabili dopo il loro
acquisito, vanno a far parte dei più sensibili problemi di progettazione. Avendo però a
disposizione un ambiente in cui poter andare a simulare intere mensilità di gestione
energetica (coinvolgendo questi sistemi sensibili) in pochi minuti rimane naturale pensare
di andare ad utilizzarlo per poter prendere scelte più accurate in fase di progettazione,
dimensionando correttamente la componente fotovoltaica e di accumulo del sistema.
E‟ per questo motivo che viene proposto un utilizzo in tal senso di questa ultima versione
dello strumento HAS-Sim. E‟ infatti possibile avviare in modo ricorsivo le simulazioni
variando la capacità della batteria o la massima erogazione di energia da parte dei pannelli
fotovoltaici (lasciati parametrici), potendo andare ogni volta a vedere come l‟algoritmo di
massimizzazione si comporta e se le dimensione dei sistemi di generazione/accumulo sono
correttamente dimensionati rispetto alle necessità energetiche dell‟ambiente domotico
(schema in Figura 6.17).
95
Figura 6.17 - Simulazione con parte di generazione parametrica
Avendo a disposizione anche un potente mezzo di simulazione di sistemi domotici, quale
quello proposto nel capitolo 5, è possibile simulare ambienti domotici con configurazioni
varie, con all‟interno scenari differenti (numero e tipo di elettrodomestici, numero di
abitanti e loro abitudini). In questo modo è possibile , attraverso un processo di
riprogettazione (Figura 6.18), trovare la configurazione ideale per il sistema che
massimizzi l‟autoconsumo, adattandosi anche alla struttura di un particolare sistema
domotico simulato.
Figura 6.18 - Riprogettazione ricorsiva del sistema domotico
96
6.3
Integrazione/Comunicazione tra elettrodomestici reali e
simulati
Nella sezione 6.1.1 si è fatto riferimento ad una porzione di software dell‟HAS-Sim
dedicata alla gestione delle prese reali (real plug). Sono stati infatti riservati dei vi (Virtual
Instruments di LabVIEW) per l‟implementazione di codice adibito all‟acquisizione del
consumo elettrico di 3 Smart Plug e alla relativa connessione/disconnessione dalla rete.
In questi VI è perciò possibile inserire del codice in grado di comunicare con delle
periferiche di acquisizione e pilotare un eventuale relè in grado di connettere/disconnette le
prese (e di conseguenza gli agenti a loro connessi) dalla rete elettrica.
Nel capitolo 7 porteremo un esempio in cui le smart plug a cui si fa riferimento sono dei
componenti bticino commerciali installati nel DOMOLab del Dipartimento di Ingegneria
dell‟Informazione dell‟UNIVPM.
L‟ambiente di programmazione LabVIEW è ricco di strumenti che permettono l‟interazione
e comunicazione con componenti esterni al computer che esegue il software. Nel caso
specifico dei componenti bticino, verrà utilizzata una comunicazione con un gateway
TCP/IP che farà da interfaccia con il bus SCS proprietario della bticino, attraverso è il quale
è possibile comunicare con i loro prodotti.
97
98
7. Validazione
In questo capitolo verranno riportati i risultati di alcuni simulazioni che metteranno alla
prova i modelli e le strategie di controllo implementate per poterne verificare la validità.
Per validare la tecnica di modellazione e la relative implementazione in ambiente
LabVIEW verrà presentata la simulazione di un degli elettrodomestici simulate (la lavatrice
–WM). Nella sezione successiva per verificare invece il corretto funzionamento della
politica di controllo adibita alla gestione del consumo di potenza istantanea, una lavatrice e
una lavastoviglie simulate verranno avviate in modo da necessitare in modo concorrente la
risorsa elettrica, che risulterà non sufficiente per il completamento del processo di lavaggio
di entrambe. Come terza simulazione verrà portato il risultato relativo ad una mensilità
virtuale simulata in cui sarà testato il modulo software relativo alla stima e la gestione della
taglia energetica. In fine verrà portato un estratto di una simulazione alla base delle quale è
stato attivato il modulo software (e relativa PN) adibiti alla massimizzazione
dell‟autoconsumo.
7.1
Elettrodomestico simulato
Il modello della lavatrice è stato costruito seguendo il processo di modellazione introdotto
nel capitolo 3, infatti una volta descritto lo State diagram UML della lavatrice esso è stato
replicato in LabVIEW usando lo Statechart module che ha permesso di ridisegnare la
struttura a stati all‟interno di un ambiente software.
Il modulo software che simula un modello di WM presenta un interfaccia come quella in
Figura 7.1 che permette ad esempio di avviare un ciclo di lavaggio o di mettere in pausa
l‟elettrodomestico, mostrando il nome del ciclo in corso e un contatore della fase in corso.
Figura 7.1 - Interfaccia WM
99
L‟evoluzione da uno stato all‟altro del ciclo di lavaggio è stato realizzato in LabVIEW
Statechart (Figura 7.2) ed è composto da 4 stati
 Heating
 Wash
 Rinse
 Centrifuge
Ogni face è caratterizzata da uno specifico consumo energetico e un durata. Tali
informazioni sono memorizzate negli attributi della classe WM.
Figura 7.2 - Statechart WM
Nello Statechart le transizioni tra gli stati scattano interrogando la porzione di PN della
PLUG relativa alla WM richiamando un VI dedicato (Transition PN WM.vi) il quale va a
leggere il file della PN e abilita la transizione solamente se il suo scatto rispetta le regole
descritte dalla PN stessa.
Il risultato di una simulazione in ci viene avviata la sola WM è riportato in Figura 7.3.
100
Figura 7.3 - Firma elettronica WM
Il comportamento mostrato con la firma elettronica si riferisce alle fasi di lavaggio riportate
nella Tabella 7-1.
Tabella 7-1
FASE
Consumo [W]
Durata [s]
HEATING (HE)
2000
420
WASH (WA)
1700
1800
RINSE (RI)
600
840
CENTRIFUGE (CE)
500
120
Viene riportato in Tabella 7-2 la descrizione delle fasi di lavaggio anche della lavastoviglie
in modo da poter meglio comprendere le simulazioni delle sezioni 7.2.1 e 7.2.2.
Tabella 7-2
FASE
Consumo [W]
Durata [s]
COLD WASH 1 (CW1)
200
150
HEATING (HE)
2000
30
PREWASH (PRE)
100
90
HOT WASH 1 (HW1)
2000
1000
COLD WASH 2 (CW2)
200
1600
HOT WASH 2 (HW2)
2000
1200
101
7.2
Gestione potenza istantanea
Per andare a verificare il corretto funzionamento della strategia di controllo dedicata alla
gestione della potenza istantanea descritta in 5.3.1 verranno portati i risultati di 2
simulazioni dove in entrambe una lavatrice (WM) e una lavastoviglie (DW) simulate
verranno avviate contemporaneamente e dovranno concorre per l‟accesso alla stessa risorsa
energetica che risulterà insufficiente per soddisfare le loro richieste contemporanee.
Nella prima simulazione i due elettrodomestici verranno avviati mantenendo disattivato il
sistema di controllo, nella seconda invece verranno riproposte le stesse condizioni
operative, ma con il sistema di controllo attivato.
Nella Tabella 7-3 e nella Tabella 7-4 verrà fatto riferimento ai cicli di
lavaggio della lavastoviglie con degli acronimi che sono riportati in
7.2.1 DW e WM senza sistema di controllo
Il risultato in uscita dal HAS-Sim relativamente ad una simulazione di 7.010 secondi è
riportato in Figura 7.4.
Figura 7.4 - WM e DW senza gestione potenza istantanea
Nella Tabella 7-3 viene riportata una sintesi della sequenza degli eventi accaduti durante la
simulazione che permettono di meglio comprendere il grafico del consumo elettrico.
102
Tabella 7-3
CHI
QUANDO
[s]
COSA
POTENZA
FASE
[W]
DURATA
[s]
POTENZA
TOTALE
[W]
DW
400
CW1
200
150
200
DW
580
HE
2000
30
2000
DW
640
PRE
1000
90
100
DW
760
HW1
2000
1000
2000
WM
840
HE
2000
420
4000
WM
1290
WA
1700
1800
3700
DW
1790
CW2
200
1600
1900
WM
3120
RI
600
840
800
DW
3420
HW2
2000
1200
2600
WM
3990
CE
500
120
2500
WM
4140
OFF
0
-
2000
DW
4650
OFF
0
0
E‟ possibile vedere come senza un controllo attivo il sistema non è in grado di evitare
situazioni in cui il consumo oltrepassa i 3 KW permanendo in una situazione di overload
dal secondo 840 al secondo 1790 (istanti evidenziati in rosso nella Tabella 7-3).
7.2.2 DW e WM con sistema di controllo
Per testare l‟efficacia del sistema di controllo sviluppato per la gestione della potenza
istantanea e verificare che vengano evitate situazioni di overload prolungate, è stata
replicata la stessa situazione della sezione 7.2.1, dovere però il sistema di controllo è stato
attivato, assegnando alla WM una priorità maggiore rispetto alla DW.
Il risultato in uscita dal HAS-Sim relativamente ad una simulazione di 7.010 secondi è
riportato in Figura 7.5.
103
Figura 7.5 - WM e DW con gestione potenza istantanea
Nella Tabella 7-4 viene riportata una sintesi della sequenza degli eventi accaduti durante la
simulazione che permettono di meglio comprendere il grafico del consumo elettrico.
104
Tabella 7-4
CHI
QUANDO
[s]
COSA
POTENZA
FASE
[W]
DURATA
[s]
POTENZA
TOTALE
[W]
DW
450
CW1
200
150
200
WM
570
HE
2000
420
2200
DW
630
PAUSE
0
-
2000
WM
1030
WA
1700
1800
1700
WM
2860
RI
600
840
600
DW
2960
HE
2000
30
2600
DW
3020
PRE
100
90
700
DW
3140
HW1
2000
1000
2600
WM
3730
CE
500
120
2500
WM
3880
OFF
0
-
2000
DW
4170
CW2
200
1600
200
DW
5800
HW2
2000
1200
2000
DW
7030
OFF
0
-
0
In questa simulazione, dove il sistema di controllo è stato attivato, il sistema è stat in grado
di evitare situazioni di overlaod prolungato mettendo in pausa la DW dal secondo 630 al
secondo 2.960 (istante evidenziato in blu nella Tabella 7-4).
7.3
Gestione stima/taglia energetica
In questa sezione vengono riportati gli andamenti dei contenuti dei serbatoi descritti in
5.3.2 durante una simulazione di un particolare scenario. Nel caso particolare di nbase
quando si parla di elettrodomestici non controllati, si fa riferimento a tutti quelli che non
sono stati collegati a prese il cui consumo istantaneo è misurato e che sono attuabili
(possono essere scollegate dalla rete da parte dal sistema di controllo). Nel caso degli
scenari in esame gli elettrodomestici controllati sono la Lavatrice (WM), la Lavastoviglie
(DW), il Forno (OVEN) e il Frigorifero (FRIDGE) e sono questi gli elettrodomestici che
105
varranno monitorati attraverso il serbatoio n1. Tutti gli altri vengono considerati
elettrodomestici non controllati e sono monitorati dal serbatoio n base e ne fanno parte:
l‟illuminazione, TV, phon, eventuali piastre induttive per la cucine, eventuale scaldabagno
elettrico, eventuali pompe di calore elettriche ecc…). La modellazione e definizione delle
firme elettriche di elettrodomestici ad elevato consumo elettrico come lo scaldabagno, le
piastre induttive e le pompe di calore rientra nei possibili sviluppo futuri e in queste analisi
si è ipotizzato fossero assenti all‟interno degli scenari.
Verranno riportati i grafici delle Energia consumata, dei serbatoi e della potenza istantanea
i quali verranno brevemente descritti per interpretarne il significato e le potenziali utilità.
Lo scenario della casa con cui verrò testato il modulo software è composto dai seguenti
elettrodomestici:
 Lavatrice
 Forno
 Frigorifero
Le informazioni sullo scenario verranno passata all‟HAS-Sim compilando un file di
scheduling come quello descritto in 6.1.4.
PRIORITY:
(Minuti dopo i quali gli elettrodomestici vengono distaccati in caso di una situazione di
overload):
WM
40
DW
45
OVEN
50
FRIDGE
60
APP_1
10
APP_2
20
APP_3
30
TENANTS:
1
(numero di inquilini della casa)
APPLIANCES WEEKLY FREQUENCY:
(Numero di volte che ogni settimana ogni elettrodomestico viene fatto partire. Questi valori
sono una stima dell‟utente data a inizio mese):
WM
2
DW
0
OVEN
1
FRIDGE
Sempre
APP_1
0
APP_2
0
APP_3
0
Sintesi dello scheduling:
Qui di seguito viene riassunto lo scheduling di una settimana tipo:
106
DAY1
DAY2
WM
21:00
OVEN
21:30
FRIDGE
DAY3
DAY4
DAY5
21:00
DAY6
DAY7
16:00
11:00
20:00
ON
Gli orari dello scheduling non in grassetto sono quelli relativi allo scheduling NORMAL.
Gli orari dello scheduling evidenziati in grassetto sono quelli che nello scheduling LOW
non vengono fatti partire dall‟utente (semaforo Arancione o Rosso ). Tale scheduling si
ripeterà identico per le 4 le settimana della simulazione.
Grafici:
Vengono adesso riportati i grafici dell‟energia, dei serbatoi descritti in 5.3.2 e alcuni
dettagli della potenza istantanea misurata.
Energia
Questo grafico rappresenta il consumo in Wh totale dell‟abitazione simulata. E‟ infatti il
consumo energetico che sarebbe stato misurato del contatore dell‟appartamento.
Figura 7.6 - Energia consumata [Wh]
La taglia che il simulatore aveva stimato a inizio simulazione era una SMALL, cioè con un
consumo consentito non maggiore di 150 kWh al mese.
Poiché lo scheduling degli elettrodomestici è stato settato in modo tale da rispettare le stime
date a inizio simulazione, si è ottenuto a fine mese un consumo di energia di poco superiore
alla taglia stimata.
nbase
107
Viene riportato in Figura 7.7 il grafico di nbase , serbatoio relativo a tutti quei consumi non
correlati ad elettrodomestici sotto controllo (e.g. luci, TV, phon, ecc…)
Figura 7.7 - Serbatoio nbase [Wh]
Come si può vedere dal grafico, ogni giorno il serbatoio viene ricaricato con una quantità di
kWh costante, stimata in base al numero di inquilini dell‟abitazione (in questo caso 1). Per
testare il funzionamento dell‟Algoritmo taglie in questa simulazione, si è deciso di imporre
un consumo giornaliero di energia costante leggermente superiore alla stima. In questo
modo si è ottenuto un esaurimento di nbase a fine di ogni giornata (valore negativo del
contenuto del serbatoio) meno che dal giorno 16 al giorno 21 dove il consumo è stato
ridotto a 200 W.
La quantità di energia che qui ha un valore negativo, vedremo che verrà sottratta dal
serbatoio di emergenza n2.
n1
Viene riportato in Figura 7.8 il grafico di n1 relativo ai consumi di energia degli
elettrodomestici controllati (misurati e attuati).
Figura 7.8 - Serbatoio n1 [Wh]
L‟andamento dei consumi è qui dipendente dallo scheduling passato al simulatore. Come
possiamo vedere a fine di ogni settimana il serbatoio viene ripristinato a un valore che è
108
stato stimato a inizio simulazione. La quantità di energia che a fine di ogni settimana è in
eccesso/difetto viene aggiunta/sottratta a n2.
Il caso di un esaurimento di n1 si verifica solo a fine della quarta settimana. E possibile
osservare come il controllore del simulatore tenda a risolvere i conflitti spostando verso la
fine del mese l‟esecuzione degli elettrodomestici (ritardandoli). Questo ha l‟obbiettivo di
evitare che si creino situazioni di overload troppo prolungate che possono portare a un
distacco del contattore.
n2
Viene riportato in Figura 7.9 il grafico dell‟andamento del serbatoio n2, rappresentante la
riserva energetica di emergenza disponibile durante il mese:
Figura 7.9 - Serbatoio n2 [Wh]
E‟ possibile vedere come in coincidenza del termine di ogni giornata, parte del serbatoio
venga consumata. Questo è causato dall‟esaurimento giornaliero del serbatoio nbase . Ciò
non accade solamente dal giorno 16 al giorno 21 dove il consumo di n base è inferiore al
valore stimato.
E‟ possibile notare anche come a fine delle prime 3 settimane il serbatoio venga ricaricato
di una quantità notevole di energia. Questo è dovuto all‟avanzo di Wh di n1 sommato alla
nuova porzione di n2 riservata alla settimana successiva. La quantità di energia ricaricata va
decrescendo poiché mano a mano che ci si avvicina a fine mese, il serbatoio n 1 viene eroso
maggiormente ad ogni nuova settimana, fino a diventare negativo alla fine dell‟ultima.
La pendenza di n2 permette di individuare un comportamento dell‟utente che
previsionalmente porterebbe ad uno sforamento della taglio. In questa particolare
simulazione abbiamo questo comportamento a partire dall‟inizio della seconda settimana,
dove la pendenza di n2 porta chiaramente ad un suo esaurimento a fine settimana. Il
semaforo infatti è diventato arancione all‟inizio del giorno 11 come possiamo vedere da un
particolare istante dei grafici generati in Figura 7.10.
109
Figura 7.10 - Semaforo avvertimento esaurimento taglia
Power
Il grafico in Figura 7.11 rappresenta il consumo in W totale dell‟abitazione simulata
campionato al secondo. E‟ infatti il consumo energetico che verrebbe misurato del
contatore dell‟appartamento.
Figura 7.11 - Consumo di potenza istantanea [W]
Come si vede dall‟immagine il consumo di potenza relativo agli elettrodomestici non
controllati è quel valore che rimane pressoché costante durante tutta la simulazione. Infatti
è stato imposto in questa simulazione ad un valore oscillante tra 250 e 350 W rappresentate
il consumo medio di 1 persona nella casa.
I picchi nell‟immagine rappresentano invece gli elettrodomestici che vengono avviati dallo
scheduling caricato ad inizio simulazione. Andando a fare uno zoom nell‟intorno del giorno
2 è possibile anche vedere il profilo della firma elettrica dell‟elettrodomestico che è stato
avviato (Figura 7.12)
110
Figura 7.12 - Firma elettronica WM e OVEN
In questo caso abbiamo un dettaglio dell‟avvio concorrente di WM e OVEN.
Il sistema di simulazione integra al suo interno agenti differenti che possono essere
modellati e gestiti singolarmente, ma interagire tra loro all‟interno dell‟ambiente di
simulazione (elettrodomestici controllati, non controllati, utenti con il relativo scheduling).
L‟utilizzo di tutti questi elementi in diversi scenari ha permesso di valutare le capacità dello
strumento e le sue potenzialità ed eventuali miglioramenti che potrebbero essere apportati.
Alla luce dei risultati sperimentali forniti dai grafici della simulazione è possibile giungere
alle seguenti conclusioni.
1. Il sistema di simulazione calcola correttamente i consumi correlati ai sottosistemi
della casa (elettrodomestici controllati e non) gestendo i serbatoi nbse e n1
 La suddivisione del monitoraggio energetico in serbatoi permette di
comprendere cosa accade nel sistema domotico durante la simulazione,
riuscendo ad interpretare quale sottosistema è causa di eventuali
comportamenti anomali, sui quali è necessario indagare maggiormente.
 La sintesi in n2 di tutti i consumi energetici fornisce un valido strumento di
indagine che in un unico valore numerico mette a disposizione un indice di
andamento del consumo energetico della taglia. Infatti proiettando ed
estrapolando l‟andamento di n2 è possibile individuare in anticipo (fino ad una
settimana prima) un comportamento che potrebbe portare all‟esaurimento
della taglia stimata. Questo permette di utilizzare n2 come sistema di
monitoraggio per prendere decisioni che possano evitare un eventuale
sforamento della taglia stessa.
2. Il sistema riesce correttamente a gestire contemporaneamente 2 tipologie di
scheduling differenti e passando da uno all‟atro a seconda delle necessità permette
in alcuni casi di risolvere situazioni critiche che potrebbero portare
all‟esaurimento della taglia. In pratica lo switch tra i 2 scheduling è reso possibile
da un sistema di stima che proietta nel futuro l‟andamento del serbatoio n 2. Se la
111
proiezione di n2 fino a fine della settimana risulta tale da esaurire tutto il
contenuto di n2 , il sistema di controllo passa automaticamente dallo scheduling
NORMAL a quello LOW riducendo in consumi istantanei ed evitando di esaurire
la taglia in alcuni casi.
3. Analizzando le situazioni in cui, nonostante la presenza di un sistema di
monitoraggio e controllo, la taglia è stata comunque esaurita, si è giunti alla
seguente conclusione:
 Il valore numerico su cui si base il sistema di stima è di controllo è n 2. Il suo
andamento nel tempo è fortemente correlato all‟andamento degli altri due
serbatoi nbase e n1.
 Osservando nbase si può notare che il suo andamento è lineare e facilmente
modellabile dal sistema di stima. Infatti la predizione di n2 nel futuro modella
correttamente l‟andamento di nbase proiettando il suo effetto su n2 come una
pendenza pressoché costante. Per questo motivo nbase è stato scartato come
causa degli errori di stima.
 Osservando n1 invece si è notato il suo andamento fortemente non lineare.
Infatti durante il suo ciclo settimanale n1 presenta spesso dei picchi di
consumo concentrati nella parte finale di ogni settimana. Questi picchi sono
dovuti alle abitudini degli utenti, sintetizzate negli scheduling passai al
simulatore, che spesso concentrano l‟utilizzo degli elettrodomestici durante il
sabato e la domenica. Poiché lo scheduling e la simulazione gestiscono le
settimane partendo sempre da lunedì, a fine di ogni settimana si verifica un
picco di consumo che viene ritrovato nell‟erosione nel contenuto di n2 proprio
nei giorni 6 e 7 di ogni settimana. Questa non linearità nella parte finale del
periodo di stima (la settimana) comporta la generazione di un warning
(semaforo giallo o rosso) solo a fine settimana e in modo più critico a fine
mese (fine dell‟ultima settimana), non fornendo al sistema di controllo il
tempo necessario per prendere decisioni che evitino uno sforamento della
taglia.
 Questa non linearità nell‟andamento di n1 potrebbe essere equilibrata
chiedendo all‟utente di indicare anche in quale giornata della settimana
solitamente concentra l‟utilizzo di un numero maggiore di elettrodomestici. In
questo modo sarebbe possibile suddividere le settimane diversamente (e.g. da
sabato a sabato invece che da lunedì a lunedì, se il giorno di maggiore di
consumo indicato fosse la domenica) dando allo stimatore di n2 il modo di
osservare un sovra consumo già a inizio settimana e poter prendere così per
tempo le giuste decisioni (switch dello scheduling). In questo modo
l‟attivazione dello scheduling LOW avrebbe più di metà settimana per
influenzare l‟andamento dei consumi e variare la pendenza di n2 aumentando
l‟efficacia nel prevenire l‟esaurimento della taglia.
112
7.4
Massimizzazione autoconsumo
Per validare il sistema di controllo adibito alla massimizzazione dell‟autoconsumo di
energia prodotta da fonti energetiche interne all‟ambiente domotico (sezione 5.3.3), verrà
riportato un particolare di una simulazione alla quale sono stati forniti i dati storicizzati
reali di consumi elettrici degli appartamenti e della produzione fotovoltaica della
LeafHouse Loccioni.
In Figura 7.13 sono stati affiancati i grafici di produzione fotovoltaica, energia venduta e
livello di carica della batteria relativamente ad un giorno di simulazione. Si può osservare
come l‟algoritmo di massimizzazione intervenga, deviando la quantità di energia prodotta
dal sorgente fotovoltaica dando priorità alla ricarica della batteria. Una volta che però la
batteria risulta completamente carica (campione 2.347) l‟energia generata dai pannelli
(ipotizzando un consumo nullo da parte degli appartamenti) viene completamente rivenduta
al provider energetico.
113
Figura 7.13 - Produzione solare - Energia venduta - Carica batteria
114
8. Collaborazioni
Lo sviluppo dell‟intero sistema di simulazione è stato inserito all‟interno di una
collaborazione tre l‟UNIPM e il centro di ricerca ENEL IIR di Pisa. Tale collaborazione ha
guidato lo sviluppo di alcune parti del simulatore in modo da venire incontro alle necessità
di ricerca del centro (stima e mantenimento della taglia, scheduling degli elettrodomestici).
La collaborazione con tale centro di ricerca si è conclusa con la consegna di un sistema di
simulazione completo in grado si simulare in 2/3 giorni un mese di andamento dei carichi,
implementando la politica di controllo richiesta, in grado di mantenere i carichi sotto una
soglia massima di consumo e inducendo l‟utente ad un comportamento che incrementasse
la probabilità di mantenere a fine mese la taglia scelta.
Ulteriore contesto di collaborazione è stata l‟interazione con il Gruppo Loccioni che ha
messo a disposizione i dati e l‟infrastruttura della LeafHouse [18]. Nella collaborazione è
stata anche finanziata un‟ulteriore borsa di dottorato con argomento proprio
l‟approfondimento delle questioni affrontate in questo lavoro.
115
116
9. Conclusioni
Questo lavoro ha portato allo sviluppo di uno strumento di simulazione/emulazione
(software HAS-Sim) modulare ed efficacie, in grado di simulare un‟ampia varietà di
situazioni, fornendo uno strumento che permette di costruire rapidamente strutture
domotiche anche complesse, integrando tra loro modelli di elementi domotici elementari.
L‟obiettivo raggiunto è stato quello di permettere la simulazione di intere mensilità in pochi
minuti, dando la possibilità di individuare in breve tempo le configurazioni più adatte alle
necessità degli utenti, testando in anticipo le politiche di gestione energetica che si vogliono
adottare. E‟ stato verificato che gli approcci di modellazioni basati sulla teoria UML e i
sistemi a stati finiti (come le PN) sono risultati funzionali nella caratterizzazione di
elementi come quelli che popolano i sistemi domotici rendendo disponibile al termine del
lavoro svolto uno strumento per poterli studiare.
Il prodotto software sviluppato è risultato anche predisposto alla diffusione sul mercato
industriale da parte dei principali attori del settore dove la realizzazione di sistemi domotici
complessi, che integrano diverse fonti di energia sono diventati sempre più numerosi,
grazie anche agli incentivi che hanno permesso di diffondere la generazione di energia
elettrica da fotovoltaico ormai anche a livello residenziale e di privati cittadini. E‟ infatti al
giorno d‟oggi un problema diffuso quello di dover prendere scelte strategiche sul
dimensionamento dei sistemi fotovoltaici e di accumulo elettrico per permette all‟utenza
finale un ritorno economico. Scelte non ottimali in fase di progettazione di questi sistemi
potrebbero portare ad un mancato guadagno che potrebbe essere evitato utilizzando sistemi
di progettazione e simulazioni come quelli proposti con questo progetto. Si è potuto
ottenere con questo lavoro uno strumento in grado anche di validare le strutture prima di
collegare qualsiasi hardware, portando ad un elevato risparmio in fase di progettazione.
Successivamente ci si vorrà spostare anche in ambito internazionale, adattando il software
alle normative e alle legislazioni estere rilasciando versioni dello stesso in grado di simulare
correttamente i vincoli governativi ed energetici di altre nazioni.
I possibili sviluppi del sistema di simulazione, monitoraggio e controllo che è stato
descritto in questi documenti sono molteplici. Si potrebbe prevedere l‟inserimento di altri
elettrodomestici fornendo un‟estensione dell‟attuale sistema di simulazione, permettendo di
modellare scenari più complessi. In questo modo potrebbero essere tenuti in considerazione
ulteriori elementi domotici ad elevato consumo energetico, come piastre induttive per la
cucina, scaldabagno elettrico e pompa di calore elettrica. Inoltre avendo noto il modello di
un vettore elettrico per il riscaldamento della casa e per la cottura degli alimenti, il sistema
di simulazione e monitoraggio, a termine di una simulazione nella quale non vi è stato un
completo sfruttamento delle risorse (e.g. taglia energetica), potrebbe suggerire di passare a
diversi sistemi di riscaldamento anziché ridurre la taglia. Potrebbe essere inserita anche
117
un‟influenza stagionale nei consumi, infatti a seconda del mese a cui fa riferimento una
simulazione, le abitudini di consumo di un utente potrebbero cambiare, influenzando le
curve di consumo della casa in cui vive. Sviluppando ulteriormente il software potrebbe
essere possibile realizzare un sistema di riconoscimento automatico della firma degli
elettrodomestici, riuscendo ad isolarne il profilo all‟interno dei consumi complessivi della
casa. In questo modo potrebbe essere ridotto il numero di sensori all‟interno della casa
riducendo la complessità e il costo dei sistemi di monitoraggio. Infine si propone
l‟inserimento in una futura implementazione nel simulatore di un sistema di rescheduling
dell‟avvio degli elettrodomestici, sulla base di parametri comportamentali e liste di merito
degli elettrodomestici e dei dispositivi in gioco. Sarebbe possibile in questo modo andare a
ottimizzare l‟avvio degli elettrodomestici (evitando sovraccarichi e esaurimenti della taglia)
rispettando le priorità che l‟utente assegna ad ognuno di essi.
118
Riferimenti
[1]
G. Conte and D. Scaradozzi, “An Approach to Home Automation by means of
MAS Theory,” Chapter 15 of Modeling and Control of Complex Systems, 2007.
[2]
G. Conte, D. Scaradozzi, A. Perdon, and G. Morganti, “Parameter tuning in
distributed home automation systems: towards a tabu search approach,” in MED,
2008.
[3]
G. Morganti, A. Perdon, G. Conte, D. Scaradozzi, and A. Brintrup, “Optimising
home automation systems: a comparative study on tabu search and an evolutionary
multi-objective algorithm,” in MED, 2009.
[4]
G. Morganti, A. Perdon, G. Conte, and D. Scaradozzi, “Multi-Agent System
Theory for Modeling a Home Automation System,” Lecture Notes in Computer
Science, vol. 5517, pp. 585–593, 2009.
[5]
D. Scaradozzi, “Methodologies and techniques for analysis and design of home
automation systems,” 2005.
[6]
G. Conte, D. Scaradozzi, A. Perdon, M. Cesaretti, and G. Morganti, “A Simulation
Environment for the Analysis oh Home Automation Systems,” in MED, 2007.
[7]
J. Arlow and I. Neustadt, UML 2 e Unified Process: analisi e progettazione Objectoriented, 2nd ed. 2006.
[8]
P. R. S., Principi di ingegneria del software, 4th ed. 2004.
[9]
“Umbrello UML Modeller,” in uml.sourceforge.net.
[10]
D. Harel, “Statecharts: A Visual Formalism for Complex Systems,” in Science of
Computer Programming, North-Holland, Ed. 1987, pp. 231 – 274.
[11]
T. Murata, “State equation, controllability, and maximal matchings of petri nets,”
Automatic Control, IEEE Transactions, vol. 22, pp. 412–416, 1977.
119
[12]
C. N. Hadjicostis and G. C. Verghese, “Power system monitoring using Petri net
embeddings,” in Generation Transmission and Distribution, 2000.
[13]
A. Badara, F. Pape, and A. Dimitri, “Petri nets control design for hybrid electrical
energy systems,” in American Control Conference, 2009.
[14]
L. Zhiwu, Y. Mingming, and Z. MengChu, “Synthesis of Structurally Simple
Supervisors Enforcing Generalized Mutual Exclusion Constraints in Petri Nets,”
Systems, Man, and Cybernetics, Part C: Applications and Reviews, vol. 40, pp.
330–340, 2010.
[15]
A. Godon and F. Bousseau, “PM Editor.”
[16]
M. Cotti and G. Casa, “Il „Telegestore‟: una nuova infrastruttura di comunicazione
per i Servizi a Valore aggiunto,” in ANIPLA, 2001.
[17]
“bticino,” in www.international.bticino.com.
[18]
Loccioni, “LeafHouse,” in http://energy.loccioni.com/sustainable-community/leafhouse/.
120
A. Appendice
A.1 Strumenti Software
Il software Umbrello UML Modeller
Il software scelto per la descrizione UML è stato il software Umbrello UML Modeller. Esso
ha un'interfaccia utente molto intuitiva, grazie alla quale si sarà subito operativi nella
modellazione. Tutte le azioni sono accessibili attraverso il menu e le barre degli strumenti,
ma si usano molto anche i menu contestuali, forniti cliccando con il tasto destro del mouse.
La finestra principale di Umbrello UML Modeller è divisa in tre aree che ci aiuteranno a
mantenere una panoramica dell‟intero sistema e ad accedere rapidamente ai diversi
diagrammi mentre si lavora al modello. Grazie all‟ausilio del software in esame si è in
grado di disegnare i diagrammi di interesse, fornendo in questo modo le basi per lo
sviluppo del simulatore al livello successivo relativo all‟ambiente LabVIEW.
Queste aree sono chiamate vista ad albero, area di lavoro e finestra di documentazione,
come indicato nella Figura A.1:
Figura A.1 - Schermata del software Umbrello UML Modeller
121
Si avranno così a diposizione, terminata questa fase di modellazione UML, i seguenti due
diagrammi:

Diagramma delle classi, che ci permetteranno di definire gli oggetti nella loro
completezza, grazie alla definizione degli attributi che li caratterizzano e i metodi
associati. Inoltre all‟interno del diagramma si andranno inoltre a scrivere le varie
associazioni e dipendenze tra le classi.

Diagramma di stato, per modellare l‟evoluzione dell‟oggetto, il cambiamento del
suo stato e il cambiamento degli attributi. Sono inoltre utilizzati i metodi per il
passaggio da uno stato all‟altro, grazie anche all‟utilizzo delle transizioni
caratterizzate da un evento, azione e guardia.
Si utilizzeranno ora i diagrammi delle classi e di stato, prodotti per mezzo del software
Umbrello UML Modeller , per procedere con la successiva fase di programmazione. Si
vogliono ora riportare questi diagrammi all‟interno dell‟ambiente di programmazione
LabVIEW, riuscendo ad ottenendo in questo modo una base di partenza strutturata per la
definizione del simulatore.
Si andranno ora a definire gli strumenti utilizzati per procedere con il passaggio
d‟importazione semi-automatica all‟interno dell‟ambiente di programmazione.
LabVIEW
In questo paragrafo si introdurranno i software utilizzati per il passaggio dal linguaggio
UML, sviluppato mediante l‟utilizzo del software Umbrello UML Modeller, fino alla fase
finale d‟implementazione nell‟ambiente LabVIEW, raffigurante il linguaggio di
programmazione del nostro simulatore.
I punti di partenza saranno i diagrammi delle classi e i diagrammi di stato, grazie ai quali si
riesce a descrivere completamente ed in modo dettagliato il comportamento degli oggetti in
esame e la loro evoluzione.
I software scelti sono il tool Endevo UML Modeller utilizzato per l‟importazione delle
classi, ed il modulo Statechart per il trasferimento del diagramma di stato all‟interno del
software. In entrambi i casi, la fase di trasporto dei diagrammi all‟interno dei nuovi
ambienti software avviene in modo manuale, in quanto si devono riportare i diagrammi
ottenuti con il software Umbrello UML Modeller all‟interno dei nuovi ambienti di sviluppo.
122
LabVIEW (Laboratory Virtual Instrument Engineering Workbench) è un linguaggio di
programmazione grafico in quanto usa icone anziché testo per creare le applicazioni. In
contrasto con i linguaggi di programmazione basati maggiormente sul testo, dove le
istruzioni determinano l‟ordine di esecuzione del programma, LabVIEW usa una
programmazione dataflow, dove il flusso di dati attraverso i nodi del diagramma a blocchi,
determina l‟ordine di esecuzione dei VIs e delle funzioni. VIs, o virtual instruments, sono
dei programmi LabVIEW che imitano gli strumenti fisici nel loro aspetto grafico e nelle
loro funzioni. Ogni VI è in grado di manipolare gli ingressi provenienti dall‟interfaccia
utente o da altre sorgenti e mostrare i risultati sul display.
Un VI contiene le tre seguenti componenti:

Front Panel : è un‟interfaccia utente costruita usando una serie di oggetti, come i
controlli (pulsanti o altri meccanismi per gli ingressi) e gli indicatori (LED, grafici
o altri componenti per le uscite); Essi rappresentano i terminali interattivi di input
ed output del VI. I controlli simulano gli strumenti di input e forniscono i dati al
Block Diagram mentre gli indicatori riproducono i dispositivi di output e
visualizzano le informazioni generate o acquisite da esso. Quindi il primo passo
nella realizzazione del VI è costituito dalla definizione dell‟interfaccia attraverso
la quale l‟utente vi interagisce.

Block Diagram (diagramma a blocchi) : contiene il codice sorgente grafico che
definisce le funzionalità del VI, conosciuto anche come G code o Block diagram
code. Nel codice sono presenti degli oggetti con dei terminali collegati alle
funzioni (nodes) tramite fili.

Pannello delle icone e dei connettori : identifica l‟interfaccia al VI. Questo
permette di adoperarlo anche all‟ interno di altri VIs, assumendo in questo caso il
nome di subVI.
123
Figura A.2 - Esempio di Icon and Connector Pane
Un‟icona costituisce una rappresentazione grafica del programma che può essere utilizzato
come subVI semplicemente inserendo la sua icona nel Block Diagram del programma
principale. Un‟icona può contenere testo, immagini, oppure una combinazione di entrambe
e viene personalizzata attraverso un editor che si apre con un doppio click su di essa. Un
altro metodo per definire un subVI è quello di costruire il suo pannello dei connettori. Tale
pannello altro non è che il set di terminali corrispondenti agli indicatori ed ai controllori del
relativo programma in maniera del tutto simile alla lista di parametri dei linguaggi di
programmazione text-based. Attraverso questo metodo si definiscono gli ingressi e le uscite
che possono essere collegati al modulo, quando viene usato come un subVI. La prima volta
che viene visualizzato, il pannello si presenta come un modello di connessione contenete un
terminale per ogni indicatore e controllore del Front Panel, successivamente però può
essere personalizzato in base alle proprie esigenze. Esso può contenere fino a 28 terminali
ma è buona regola non usarne più di 16 per non ridurre troppo la leggibilità e l‟usabilità
dello stesso.

I terminali rappresentano il tipo di dati associati agli indicatori oppure ai
controllori; possono essere visti come delle porte di ingresso e d‟uscita attraverso
le quali il Front Panel e il Block Diagram si scambiano informazioni.
124
LabVIEW inoltre permette di connettere le proprie applicazioni ad internet usando il suo
web server e protocolli standard come TCP/IP e ActiveX.
Attraverso questo linguaggio di programmazione, inoltre, si possono creare applicazioni
compilate a 32-bit che garantiscono una velocità buona nei processi di acquisizione dati,
test, misure e soluzioni di controllo.
LabVIEW si presta molto per la costruzione di soluzioni personalizzate per sistemi
scientifici ed ingegneristici garantendo buone performance e flessibilità, attraverso un
linguaggio di programmazione che non si presenta né difficile né complesso. Anche se
grafico, LabVIEW rimane un linguaggio strutturato in cui parti di codice possono essere
ripetute o eseguite solo in determinate circostanze, questo è reso possibile grazie alla
presenza di diversi costrutti, anch‟essi grafici, che possono essere inseriti opportunamente
nel Block Diagram.
Endevo UML Modeller
Il tool Endevo UML Modeller è uno strumento di modellazione di sistemi, risulta facile da
usare e strettamente integrato con il software LabVIEW.
Il tool supporta i seguenti diagrammi UML: casi d‟uso, delle sequenza, delle classi, dei
package e di stato.
Nel nostro caso specifico è di interesse il solo diagramma delle classi, che supporta la
generazione di codice partendo da una descrizione visiva. Lo strumento, infatti, si integra
con Symbio GOOP Wizard 3 per la generazione del codice e permette di svolgere il reverse
engineering.
Il supporto avanzato per la generazione di codice, il reverse engineering e la
sincronizzazione garantiscono che la descrizione del sistema realizzato tramite Endevo
UML Modeller sia sempre tenuto in linea con il codice durante lo sviluppo.
Quindi anche se il tool non è stato utilizzato fin dall'inizio è possibile generare i diagrammi
delle classi in qualsiasi momento durante lo sviluppo. Questo è molto utile ai fini della
documentazione o quando sono introdotti nuovi programmatori nel progetto, poiché si
riesce ad ottenere una corretta descrizione del sistema in qualsiasi momento, utilizzando la
funzionalità di reverse engineering. Questo è infatti utile per tutti i membri del team, un
corretto livello elevato visualizzazione grafica del sistema integra piacevolmente il codice
VI, durante la programmazione LabVIEW.
Riportiamo nella Figura A.3 la schermata principale del tool, dove si può notare la
application toolbar grazie alla quale è possibile selezionare i vari oggetti e comandi. Al di
sotto è presente l‟area di lavoro, in cui è riportato un esempio di un diagramma delle classi.
125
Figura A.3 - Area di lavoro di Endevo UML Modeller
Selezionando successivamente dal menù a tendina di Tools  Generate code from UML…
si andranno a creare all‟interno del nostro Project le classi riportate all‟interno del
diagramma, caratterizzate dagli attributi e metodi inseriti al loro interno, come evidenziato
nella Figura A.4
126
Figura A.4 - Inserimento classi UML in un progetto LabVIEW
Si può notare in Figura A.4, come evidenziato di rosso, che all‟interno del nostro Project
sono riportate le stesse classi definite all‟interno di Endevo UML Modeller. Sono create
all‟interno del Project come oggetti lvclass caratterizzati ciascuno dagli attributi e metodi
definiti in precedenza, divisi inoltre tra privati, protetti e pubblici.
127
A.2. Petri Net del sistema LeafHouse
Figura A.5 - Petri Net sistema LeafHouse
128

POF_EL 60335 CEI 2

SIMNOVA Cup 2015

Circ_346 Prove di simulazione Esami di Stato Classe 5

Analisi termica ancora più veloce con la release - ALPHA

Programma - Scuola superiore medico

Circuito RLC serie 1415

Programma Preliminare

4INFA_TECNOLOGIE_2013_14

Problemi di simulazione della seconda prova di Scienze Esami di