POLITECNICO DI MILANO
Scuola di Ingegneria Industriale e dell’Informazione
Dipartimento di Elettronica, Informazione e Bioingegneria
STUDIO, PROGETTO E REALIZZAZIONE DI UN
SISTEMA MULTIAGENTE PER LA GESTIONE DEL
COMFORT TERMOIGROMETRICO
Relatore: Prof. Francesco AMIGONI
Tesi di Laurea Magistrale di:
Antonio CAPUTO matr. 755449
Anno Accademico 2013-2014
2013
1
2
SOMMARIO
Il concetto di intelligenza ambientale descrive lo scenario in cui l’uomo ha a disposizione intorno a sé
dispositivi tecnologici con capacità computazionali e di connessione in rete, che lo supportano nella vita
quotidiana svolgendo numerose attività in modo non invadente.
Uno dei paradigmi che ha svolto e continua a svolgere un ruolo importante nell’ambito
dell’automatizzazione degli edifici riguarda l’utilizzo di sistemi distribuiti contrapposto all’approccio
centralizzato: ovvero la ripartizione dell’elaborazione e delle azioni tra più dispositivi, piuttosto che
all’interno di un unico dispositivo. In particolare, i sistemi denominati multiagente (MAS)
rappresentano un importante categoria di sistemi distribuiti che sono impiegati in questo contesto.
Lo scopo di questa tesi è progettare e implementare un sistema multiagente che gestisca all’interno di
un edificio tutti gli aspetti di un particolare settore del comfort ambientale: il comfort termoigrometrico.
Il sistema deve tenere conto di ogni tipo di parametro che riguardi le condizioni di temperatura e
umidità nelle varie stanze dell’edificio, e gestire i dispositivi che le controllano in modo da ottimizzare le
prestazioni.
Per descrivere il problema di calcolare il comportamento ottimo del sistema in un dato istante di tempo
è stata adottata la formulazione DCOP (Distributed Constraint Optimization Problem). Per quanto
riguarda il problema complessivo costituito da una successione di singoli problemi DCOP che
determinano il comportamento del sistema lungo un dato intervallo temporale, sono state poi definite
diverse formulazioni, tra cui quella come successione di DCOP singoli e come DDCOP (Dynamic
DCOP, in cui la soluzione di un DCOP tiene conto di quella del DCOP che lo precede nella sequenza).
Per risolvere i DCOP singoli sono stati utilizzati algoritmi standard, mentre per i DDCOP è stato
esteso l’algoritmo ADOPT implementato in Java.
Infine sono state effettuate varie serie di test che hanno valutato il comportamento del sistema
prendendo in considerazione i singoli DCOP e la serie di DCOP nelle sue varie formulazioni. Sono
stati ottenuti risultati relativi a simulazioni del funzionamento del sistema su istanze realistiche sotto le
ipotesi di mondo deterministico o stocastico, a un confronto tra i tempi di risoluzione dei diversi
algoritmi di FRODO e all’efficacia della modifica implementata all’algoritmo ADOPT.
3
4
INDICE
Sommario ..................................................................................................................................... 3
Indice ........................................................................................................................................... 5
1 Introduzione ............................................................................................................................. 7
2 Stato dell’arte dei sistemi di controllo del comfort termoigrometrico ................................... 10
2.1 Caratteristiche generali ......................................................................................................................... 10
2.2 Settore commerciale ............................................................................................................................. 11
2.3 Settore scientifico ................................................................................................................................. 15
2.3.1 Controllo ottimo, predittivo e adattativo ........................................................................ 15
2.3.2 Intelligenza computazionale ............................................................................................... 15
2.3.3 Sistemi di controllo multiagente ....................................................................................... 16
2.3.3.1 Categorie di sistemi multiagente ....................................................................... 17
2.3.4 Ambient Intelligence .......................................................................................................... 18
2.3.5 Esempi di sistemi di controllo ........................................................................................... 20
2.3.5.1 Hierarchical Fuzzy-Genetic Multi-Agent Architecture for Intelligent Buildings ..... 20
2.3.5.2 Termostato progettato e implementato seguendo un approccio multiagente ......... 22
2.3.5.3 Un sistema multiagente per controllare agenti domestici ...................................... 23
2.3.5.4 Un sistema multiagente per controllare edifici intelligenti .................................... 24
2.3.5.5 MAVHome ...................................................................................................... 24
2.3.5.6 Neural Network House .............................................................................................. 25
3 Impostazione e formulazione del problema ......................................................................... 27
3.1 Parametri significativi ........................................................................................................................ 28
3.1.1. Informazioni sul passato .................................................................................................. 28
3.1.2. Previsioni del futuro ......................................................................................................... 29
3.2 Misure di valutazione del comfort ................................................................................................... 32
3.3 DCOP: Distributed Constraint Optimization Problem ............................................................... 33
3.4 Impostazione del problema .............................................................................................................. 34
3.5 Formulazione del problema come DCOP ..................................................................................... 37
3.6 Formulazione del problema come successione di DCOP o DDCOP ...................................... 41
3.6.1 DCOP unico con variabili vettoriali................................................................................. 41
3.6.2 Successione di DCOP ........................................................................................................ 41
3.6.3 DDCOP ............................................................................................................................... 44
4 Estensione del framework FRODO ..................................................................................... 46
4.1 FRODO .............................................................................................................................................. 46
4.1.1 Architettura di FRODO ..................................................................................................... 51
4.2 ADOPT .............................................................................................................................................. 52
4.2.1 Funzionamento di ADOPT .................................... .......................................................... 53
4.3 Estensione di ADOPT per problemi DDCOP............................................................................. 53
4.3.1 Reuse-Bounds .................................... ................................................................................. 54
4.3.2 Implementazione delle modifiche...................................................................................... 54
4.4 Altri algoritmi di risoluzione ............................................................................................................ 55
5
4.4.1 DPOP .................................... .............................................................................................. 55
4.4.2 MGM ...................................... ............................................................................................. 56
4.4.3 MGM-2 .................................. ............................................................................................. 56
4.4.4 SynchBB ............................................................................................................................... 57
5 Realizzazioni sperimentali e valutazioni ................................................................................ 58
5.1 Struttura degli edifici ......................................................................................................................... 59
5.2 Generatore di problemi .................................................................................................................... 62
5.2.1 Mondo deterministico ......................................................................................................... 65
5.2.2 Mondo stocastico ................................................................................................................. 65
5.3 Test sulla consistenza ........................................................................................................................ 66
5.3.1 Test sui DCOP ..................................................................................................................... 66
5.3.2 Test sulle serie di DCOP .................................................................................................... 74
5.4 Test realistici su mondo deterministico........................................................................................... 81
5.4.1 Edificio A............................................................................................................................... 81
5.4.2 Edificio B............................................................................................................................... 85
5.5 Test realistici su mondo stocastico................................................................................................... 89
5.5.1 Edificio A............................................................................................................................... 89
5.5.2 Edificio B............................................................................................................................... 92
5.6 Test sul funzionamento interno........................................................................................................ 96
5.6.1 Confronto tra gli algoritmi di risoluzione......................................................................... 96
5.6.2 Confronto tra serie di DCOP e DDCOP......................................................................... 98
6 Conclusioni e sviluppi futuri ................................................................................................ 100
Bibliografia .............................................................................................................................. 102
A Esempi di istanze DCOP .................................................................................................... 105
A.1 Problema completo – Edificio A ................................................................................................. 105
A.2 Problema completo – Edificio B ................................................................................................. 109
A.3 Problema ridotto – Edificio A ..................................................................................................... 113
6
CAPITOLO 1
INTRODUZIONE
Il concetto di intelligenza ambientale descrive lo scenario in cui l’uomo ha a disposizione intorno a sé
dispositivi tecnologici con capacità computazionali e di connessione in rete, che lo supportano nella vita
quotidiana svolgendo numerose attività in modo non invadente. Nel corso degli ultimi anni la ricerca
nel campo dell’intelligenza ambientale ha avuto una crescita straordinaria, grazie agli enormi progressi
ottenuti soprattutto nei campi delle reti di sensori, del calcolo distribuito e dell’intelligenza artificiale [1].
Anche se le idee alla base dell’intelligenza ambientale non sono state sviluppate recentemente, per
poterle implementare nella realtà è stato necessario attendere che il progresso tecnologico rendesse
disponibili i sistemi e le tecnologie dotati degli alti requisiti che queste idee richiedevano. Il livello
tecnologico odierno permette una vasta scelta di soluzioni e dispositivi caratterizzati da alta sensibilità,
trasparenza, intelligenza, responsività e interconnessione, rendendo lo sviluppo di soluzioni di
intelligenza ambientale un settore florido sia nel campo della ricerca scientifica che in quello
commerciale [3].
La corsa verso la progettazione di edifici sempre più automatizzati e confortevoli appare inoltre un
processo difficilmente destinato ad avere fine: edifici dotati, ad esempio di termostati automatici o
controllo dell’illuminazione basati su sensori di movimento, oggi diffusi ovunque a prezzi modesti,
sarebbero stati considerati “edifici intelligenti” non più di alcuni decenni fa [1], e l’asticella del livello
tecnologico e della varietà di soluzioni disponibili si alza sempre di più.
Uno dei paradigmi che ha svolto e continua a svolgere un ruolo importante nell’ambito
dell’automatizzazione degli edifici riguarda l’utilizzo di sistemi distribuiti contrapposto all’approccio
centralizzato: ovvero la ripartizione dell’elaborazione e delle azioni tra più dispositivi, piuttosto che
all’interno di un unico dispositivo. In particolare, i sistemi denominati multiagente (MAS)
rappresentano un importante categoria di sistemi distribuiti; un MAS è composto da un insieme di
agenti che agiscono sull’ambiente in maniera autonoma, e possono interagire tra loro, per esempio per
raggiungere un obiettivo comune. Questo approccio si rende particolarmente interessante per
controllare i dispositivi situati all’interno di un unico edificio [7], che possono essere notevolmente
diversificati tra loro, ma che devono generalmente coordinarsi per ottenere degli obiettivi ben precisi e
spesso convergenti.
Lo scopo di questa tesi è progettare e implementare un sistema multiagente che gestisca all’interno di
un edificio tutti gli aspetti di un particolare settore del comfort ambientale: il comfort termoigrometrico.
Il sistema deve tenere conto di ogni tipo di parametro che riguardi le condizioni di temperatura e
umidità nelle varie stanze dell’edificio, e gestire i dispositivi che le controllano, tra cui impianti di
riscaldamento, ventilazione e umidificazione. Il sistema deve agire lungo un arco temporale
significativo, ad esempio quello di 24 ore, agendo sui dispositivi dell’edificio ad istanti di tempo
prefissati e modificando dinamicamente i suoi obiettivi e il suo comportamento a seconda delle
variazioni che le condizioni ambientali possono subire tra un intervento e l’altro del sistema e dei
desideri, comunicati esplicitamente o meno, degli utenti.
7
Per determinare il comportamento del sistema in un dato istante di tempo è stata adottata la
formulazione DCOP (Distributed Constraint Optimization Problem) [2], nella quale i dispositivi
dell’edificio svolgono il ruolo di agenti del sistema, e la soluzione ottima corrisponde alla combinazione
degli stati assunti dai dispositivi che garantisce la minor potenza da essi consumata unitamente alle
migliori condizioni di comfort raggiunte all’interno dell’edificio.
Il problema complessivo, relativo alla gestione del comfort termoigrometrico lungo un arco di tempo
(per esempio 24 ore), è costituito da una successione di singoli problemi DCOP, di cui sono fornite
diverse formulazioni. Tra di esse, è stata maggiormente utilizzata la formulazione del problema
complessivo come una successione di DCOP risolti singolarmente, e per implementarla è stato
sviluppato un software per simulare le condizioni dell’edificio nel corso del tempo a cui sono applicati i
risultati dei DCOP nei relativi istanti di tempo. Inoltre è stata definita la formulazione del problema
come Dynamic DCOP (DDCOP) [38], nella quale i singoli DCOP non sono più risolti separatamente,
ma sono processati come un unico problema, evitando ad esempio di risolvere due volte lo stesso
sotto-problema, se questo non muta nel corso del tempo.
I DCOP sono stati implementati per essere risolti dal framework FRODO [36], che simula un ambiente
multiagente distribuito in una macchina virtuale Java. E’ stato sviluppato un generatore software con lo
scopo di generare singoli DCOP o serie di DCOP a partire dal modello di un edificio e dagli obiettivi
specificati dall’utente. Per risolvere i DDCOP è stato esteso l’algoritmo ADOPT [37] implementato in
Java all’interno di FRODO perché potesse gestire questo tipo di problemi attraverso la procedura
Reuse-Bounds [38].
Sono stati effettuati svariati test sui modelli e sui sistemi software implementati in questo lavoro, in
particolare per valutare la loro consistenza, complessità ed efficacia. Sono state risolte alcune istanze
realistiche del problema basate su edifici verosimili, per valutare il comportamento del sistema. Sono
stati inoltre effettuati alcuni test per valutare il comportamento delle componenti interne dei software
implementati.
La tesi è strutturata nel modo seguente.
Nel Capitolo 2 si mostra una panoramica sullo stato dell’arte dei metodi di controllo termoigrometrico
degli edifici, sia tra i dispositivi in commercio, sia per quanto riguarda la ricerca scientifica, e si
descrivono le origini e l’evoluzione dei sistemi che implementano tali caratteristiche.
Nel Capitolo 3 si descrive l’impostazione del problema riguardante la progettazione del sistema di
gestione del comfort termoigrometrico di un edificio, in particolare si presentano la formulazione del
problema singolo come DCOP, e le varie formulazioni del problema complessivo: la formulazione
basata sulle variabili strutturate come una successioni di valori nel tempo, quella basata sulla successione
di DCOP e quella basata sul DDCOP.
Nel Capitolo 4 si illustra la struttura del framework FRODO, il funzionamento degli algoritmi di
risoluzione utilizzati in questo lavoro e il funzionamento della modifica di ADOPT implementata nella
tesi per risolvere problemi DDCOP.
Nel Capitolo 5 si descrive il funzionamento generale del software che genera i DCOP e di quello che
simula l’edificio e si mostrano i risultati delle varie categorie di test effettuate, insieme a considerazioni
8
sul comportamento, sull’efficacia e sulla complessità del sistema sotto ipotesi di mondo sia
deterministico che stocastico.
Nel Capitolo 6 sono riassunti gli obiettivi di questa tesi, le valutazioni del lavoro svolto e le prospettive
future.
In Appendice A sono mostrati degli esempi di istanze DCOP formulate secondo i modelli presentati.
9
CAPITOLO 2
STATO DELL’ARTE DEI SISTEMI DI CONTROLLO DEL
COMFORT TERMOIGROMETRICO
Lo scopo di questo capitolo è fornire una rassegna dei sistemi più diffusi sul mercato e in ambito
accademico che si occupano di gestire in modo automatizzato o semiautomatizzato il comfort termico
degli edifici e una sintesi della storia e dello sviluppo di questi sistemi, a livello scientifico, nel corso del
tempo. Nella prima parte del documento si dà una definizione del concetto di comfort
termoigrometrico; nella seconda si descrivono i sistemi commerciali; nella terza si approfondiscono la
storia e lo stato dell’arte del controllo termoigrometrico, insieme con vari esempi delle più interessanti e
recenti ricerche svolte in proposito, soprattutto nel campo dei sistemi multiagente.
2.1. CARATTERISTICHE GENERALI
Il comfort termoigrometrico rientra nella definizione di comfort ambientale, che indica la condizione di
benessere di un essere umano in relazione a temperatura, umidità dell’aria, livelli di rumorosità e
luminosità rilevati all’interno dell’ambiente in cui si trova.
In particolare la valutazione del livello di comfort termoigrometrico (o thermal comfort) è influenzata dai
valori di:
Temperatura dell’aria (°C).
Umidità relativa dell’aria interna (%): il rapporto tra la quantità di vapore contenuto in una
massa d'aria e la quantità massima che ne può contenere quella massa d'aria nelle stesse
condizioni di temperatura e pressione.
La norma UNI EN ISO 7730 individua due indici che stabiliscono degli standard per valutare il
benessere termoigrometrico, che tengono conto delle variabili sopra citate e del funzionamento del
corpo umano:
PMV (predicted mean vote): è un indice di valutazione dello stato di benessere di un individuo e
tiene conto di variabili soggettive e ambientali; si tratta di una funzione matematica che dà come
risultato un valore numerico su una scala con range -3 (indice di sensazione di troppo freddo) a
+3 (indice di sensazione di troppo caldo), dove lo zero rappresenta lo stato di benessere
termico.
PPV (predicted percentage of dissatisfied): rappresenta la percentuale prevista di individui insoddisfatti
di una particolare situazione ambientale.
Il modello alla base della creazione di questi due indici è stato sviluppato dal fisico danese P.O. Fanger
che ha utilizzato equazioni di bilancio termico e studi empirici sulla temperatura percepita dai recettori
termici degli individui. La “zona di comfort” che rappresenta le condizioni ambientali di benessere
10
percepite mediamente dagli abitanti di un ambiente al variare di temperatura e umidità, può essere
rappresentata come in Fig. 2.1.
Fig. 2.1 – Due rappresentazioni del comfort termico secondo il metodo PMV/PPV
2.2. SETTORE COMMERCIALE
Attualmente i sistemi commerciali di controllo termoigrometrico all’avanguardia sono principalmente
influenzati dalle tecniche di controllo passivo degli edifici, quindi dall’architettura e dalla scelta dei
materiali degli edifici, e inseguono come obiettivo primario la riduzione dei consumi energetici (per
esempio nel campo delle architetture bioclimatiche, che agiscono su posizionamento e conformazione
degli edifici per sfruttare riscaldamento, raffreddamento e correnti naturali). Dati i costi generalmente
alti di costruzione e altri svantaggi, essi sono comunque abbinati a sistemi di controllo attivo, orientati il
più possibile alla semplicità di utilizzo: cronotermostati on-off, sistemi di controllo ottimo o predittivo
che agiscono tramite controllori PID. Questi sistemi gestiscono separatamente diversi aspetti del
comfort come livello di temperatura e di umidità, e le diverse variabili interagiscono tra loro spesso con
l’unico obiettivo del risparmio energetico. I sistemi più complessi ed elaborati sono rivolti al settore
industriale, mentre edifici commerciali o del settore alberghiero utilizzano sistemi mediamente più
complessi e automatizzati rispetto a quelli residenziali.
Di seguito sono sinteticamente descritte alcune delle soluzioni commerciali più diffuse che riguardano il
controllo domestico del comfort termoigrometrico, tra quelle che offrono maggiore automatizzazione
ed adattabilità di comportamento.
11
Termostato Nest (Fig. 2.2)
[https://nest.com]
Progettato da Tony Fadell, a capo del gruppo che ha progettato il primo iPod.
Termostato programmabile, pone semplici domande agli utenti durante l’installazione per
stabilire uno schedule settimanale.
Trova la configurazione e stabilisce i setpoint ottimali durante i primi giorni di funzionamento,
in cui gli utenti comunicano le condizioni desiderate tramite semplici modifiche su/giù dei
regolatori.
E’ in grado di rilevare e valutare le attività degli abitanti tramite sensori di movimento e
modificare la propria attività (modalità away quando non rivela attività per un paio d’ore).
Sistema di learning per apprendere autonomamente eventuali modifiche nella programmazione
delle attività degli abitanti.
Eventuali modifiche singole per eventi isolati non comportano modifiche a lungo termine del
comportamento e della programmazione.
Suggerisce agli utenti quando piccole modifiche trascurabili per il comfort potrebbero portare a
un risparmio energetico.
Fig. 2.2 – Termostato Nest
Termostato CoastalGreenAir
[http://coastalgreenair.com/energy-savings-systems/programmable-motion-detected-thermostat/]
Utilizza sensori di movimento per rilevare presenza e assenza degli abitanti e risparmiare
energia.
Può essere collegato a un rilevatore di apertura porte per modificare di conseguenza gli obiettivi
di comfort.
Se non rileva movimenti nell’abitazione per un intervallo di 12 ore entra automaticamente in
unoccupied mode puntando al massimo risparmio energetico e mantenendo l’edificio entro
temperature limite.
Presenta interfacce e modalità di utilizzo distinte tra proprietari e inquilini dell’edificio.
12
Smart Temp
[http://www.thermostat.com.au/]
Smart Temp è una compagnia specializzata nella produzione di sistemi di riscaldamento e aria
condizionata all'avanguardia.
I termostati Smart Temp sono dotati di un’interfaccia touch per regolare il comfort e stabilire
degli schedule, ad esempio giornalieri o settimanali, delle condizioni ambientali desiderate.
Il controllo termico può essere gestito in modo avanzato: cioè l’edificio viene diviso in zone che
possono corrispondere a singole stanze o a singole pareti (quando un controllore è posto su
ognuna delle pareti), ogni zona può essere controllata indipendentemente e il sistema si occupa
di coordinare le temperature desiderate nelle varie zone.
Occupancy module: dispositivo per hotel e simili, utilizza sensori che rilevano la presenza degli
abitanti e attivano di conseguenza i dispositivi che controllano il comfort, come termostati, luci
ed elettrodomestici.
Loxone (Fig. 2.3)
[http://www.loxone.com/enuk/smart-home/heating.html]
Controlla e gestisce il riscaldamento/raffreddamento delle varie stanze indipendentemente.
Self-learning heating control: l'utente decide la configurazione termica per le varie stanze e nel
giro di 2-3 settimane il sistema impara e perfeziona la gestione dei tempi di attivazione per far sì
che gli abitanti abbiano le condizioni desiderate senza tempi di attesa.
Minimizza autonomamente gli sprechi energetici.
Sistema controllato tramite applicazioni da dispositivi portatili.
Miniserver domestico, che oltre alla temperatura può controllare apertura di tende e persiane,
allarmi, sveglia e altro.
Fig. 2.3 – Interfaccia del sistema di controllo termico Loxone
13
KNX [22]
Produce sistemi per l’automazione di edifici residenziali e commerciali.
Utilizza l’ABB i-bus KNX intelligent building control system basato su bus, per puntare all’obiettivo
del massimo risparmio energetico.
Controlla illuminazione, ventilazione, ombreggiatura, temperatura, aria condizionata: i diversi
sistemi comunicano tra loro tramite un’architettura a bus.
Il sistema riceve come input: dati meteorologici da weather station, informazioni sull’ambiente
circostante da rilevatori di presenza, sensori di movimento, sensori di illuminazione,
informazioni sulla temperatura desiderata dagli abitanti da termostato e rilevatore di qualità
dell'aria.
Tutti i parametri del sistema possono essere visualizzati, analizzati e modificati tramite una
interfaccia web.
Umidificatori/Deumidificatori
I dispositivi di gestione dell’umidità più diffusi agiscono spesso separatamente da quelli che controllano
la temperatura; oppure interagiscono con questi con lo scopo di ridurre i consumi ottenendo le stesse
condizioni di comfort ma utilizzando, tra le diverse scelte, la risorsa che consuma meno energia.
Controllo deumidificatore Ebac Smart Control
[http://www.ebac.com/dehumidifiers-smart-control.php]
E’ un controllore intelligente per deumidificatori completamente autonomo.
Apprende informazioni dallo stile di vita degli abitanti, dal tempo atmosferico e dal clima
dell’abitazione.
E’ programmato per distinguere le condizioni di umidità richieste durante le varie attività svolte
dagli abitanti dell’edificio e apprende automaticamente gli orari a cui sono abitualmente
eseguite.
E’ presentato come 3 volte più efficiente dei deumidificatori a contollo manuale.
14
2.3. SETTORE SCIENTIFICO
Fin dall’inizio l’obiettivo principale dei sistemi di controllo degli edifici è stata la minimizzazione dei
consumi energetici [16]. I primi termostati usavano un tipo di controllo chiamato bang-bang o on-off,
che sfrutta il meccanismo dell’isteresi per mantenere la temperatura ambientale entro determinati limiti;
ma frequenti problemi nella calibrazione della temperatura desiderata e una gestione non ottimale dei
consumi portarono molto presto all’utilizzo di controllori PID. Questi controllori migliorarono la
situazione, ma piccole variazioni nei guadagni dei controllori potevano rendere i sistemi instabili, perciò,
per ottenere maggiore stabilità nel controllo, si è passati a tecniche di controllo ottimo, predittivo o
adattativo.
2.3.1. CONTROLLO OTTIMO, PREDITTIVO E ADATTATIVO
Nel secolo scorso sono state svolte importanti ricerche nel campo del controllo ottimo [17, 18] e
predittivo [19] nel corso degli anni ’80 e ‘90 dello scorso secolo [8], a cui non seguirono però
applicazioni in campo industriale. Queste tipologie di controllori hanno bisogno di creare un modello
dell’edificio a cui sono applicate, e nel controllo predittivo questo modello include le previsioni degli
stati, delle attività e dei disturbi futuri del sistema. I modelli di comportamento termico di un edificio
hanno caratteristiche non lineari e possono variare considerevolmente a seconda dei casi specifici, e nel
corso del tempo. Un esempio di controllo predittivo è dato dal lavoro in [10], in cui si utilizzano
informazioni fornite da sensori di temperatura e umidità esterne, per gestire al meglio gli attuatori che
regolano il comfort termoigrometrico dell’abitazione.
I controllori adattativi hanno l’abilità di autoregolarsi e adattarsi alle variazioni climatiche dei diversi
edifici: le tecniche da essi più utilizzate sono il controllo adattativo fuzzy e i metodi di stima dei
parametri come la recursive least-square estimation, che hanno nella non-linearità la loro maggiore
limitazione.
In generale questi sistemi di controllo presentano alcuni inconvenienti, come il fatto di non essere userfriendly (l’utente non partecipa alla configurazione del controllo climatico), il bisogno di un modello
dell’edificio con parametri stimati in tempo reale che possono dare luogo a instabilità e la mancanza di
supporto a tecniche di apprendimento automatico.
2.3.2. INTELLIGENZA COMPUTAZIONALE
Negli anni ‘90 del secolo scorso inizia l’applicazione di metodi di intelligenza computazionale [8] ai
sistemi di controllo degli edifici, sia con tecniche di intelligenza artificiale che con l’utilizzo di algoritmi
evolutivi. L’integrazione di reti neurali, logica fuzzy e algoritmi evolutivi inizia ad essere applicata in
questo campo.
15
I risultati derivanti dall’utilizzo di tecniche fuzzy applicate ai Building Intelligent Energy Management Systems
(BIEMS), con gli obiettivi di risparmio energetico e di raggiungimento delle condizioni di comfort, e
dall’utilizzo di reti neurali per il controllo dell’Heating Ventilation and Air Conditioning (HVAC) risultano
superiori a quelli ottenuti con le tecniche di controllo classiche. Queste tecniche non hanno bisogno di
un modello matematico dell’ambiente, e il coinvolgimento degli utenti inizia a diventare parte integrante
della definizione delle condizioni di comfort. Tecniche adattative come gli algoritmi genetici [20] sono
utilizzate per ottimizzare i controllori fuzzy.
Tecniche neuro-fuzzy, in cui sistemi di reti neurali vengono utilizzati su tecnologia fuzzy, come il
sistema ANFIS [24] sono stati impiegati per problemi di gestione energetica e di adattabilità degli
edifici.
I controllori fuzzy possono essere combinati ai controllori closed-loop nei controllori fuzzy P [25, 26]: le
misure del processo vengono usate come input del sistema fuzzy e il suo output stabilisce il
comportamento degli attuatori del sistema.
Altri tipi di controllori come i fuzzy PID controller, gli illuminance controller e gli adaptive fuzzy PID controller
[27] sono utilizzati per controllare vari aspetti dell’edificio come l’illuminazione, mentre specificamente
nel controllo termico e nei sistemi che utilizzano il riscaldamento idronico (in cui cioè l’acqua viene
utilizzata come termovettore per ottenere sia caldo che freddo) sono diffusi i neural network controller
(NNC) [28, 29] diretti, che stabiliscono i vari pesi sinaptici della rete neurale con l’obiettivo di
minimizzare una funzione di costo. Gli input e gli output di questi neural network controller possono
variare a seconda dell’applicazione: ad esempio, in [28] gli input sono costituiti dai valori della
temperatura e dalle quantità delle masse d’acqua presenti in alcune zone dell’edificio, e gli output dai
valori assunti da alcuni dispositivi che controllano il riscaldamento idronico.
2.3.3. SISTEMI DI CONTROLLO MULTIAGENTE
I sistemi in cui il controllo non è gestito da un unico controllore, ma da un insieme di controllori che
devono coordinarsi e agire simultaneamente per il raggiungimento degli obiettivi del sistema, sono
chiamati Multi-Agent Control Systems (MACS) [7, 8, 9, 13, 15].
I sistemi multiagente (Fig. 2.4) sono caratterizzati da una divisione dei compiti e degli obiettivi:
generalmente ogni agente ha un sotto-obiettivo o deve risolvere un sotto-problema, interagisce con una
parte dell’ambiente, deve essere in grado di comunicare con gli altri agenti, e spesso, ma non sempre,
con un coordinatore che regola le attività dei vari agenti e stabilisce i sotto-obiettivi per arrivare a
raggiungere l’obiettivo finale.
Nel campo del controllo degli edifici l’approccio multiagente è stato utilizzato principalmente per
ovviare al problema della scarsa partecipazione dell’utente nei sistemi che minimizzano una funzione di
controllo come nel caso delle reti neurali, e che quindi offrono inevitabilmente qualche difetto nel
grado di comfort percepito. I sistemi di controllo basati sul comportamento (behavior-based systems) [21]
16
combinati con tecniche di intelligenza computazionale, sostituiscono i modelli teorici con modelli reali:
il behavioral system è un controllore fuzzy in cui un algoritmo genetico regola la knowledge basis e la
membership function. In [14] gli autori hanno sviluppato un sistema multiagente basato su controllori e
regole fuzzy e algoritmi genetici, approfondito nella Sezione 2.3.5.1.
2.3.3.1. CATEGORIE DI SISTEMI MULTIAGENTE
I sistemi multiagente possono essere suddivisi in varie categorie ortogonali tra loro, anche se molto
spesso queste vanno a sovrapporsi all’interno di una applicazione specifica. Le principali tipologie di
sistemi multiagente che vengono generalmente definite sono le seguenti:
Complessità del controllo: I sistemi multiagente che non dispongono di una rappresentazione
dell’ambiente tale per cui possano elaborare dei ragionamenti, ma agiscono unicamente
reagendo a particolari stimoli dell’ambiente, sono detti reattivi. Al contrario, i sistemi che
dispongono di un modello e che formulano ragionamenti sono detti cognitivi. Questo modello
può essere predefinito, o stabilito e modificato dall’utente, oppure può essere costruito dal
sistema stesso, tipicamente attraverso tecniche di apprendimento automatico.
Fig. 2.4: Schema generale di un sistema multiagente per il controllo di parametri ambientali
17
Architettura del controllore: I sistemi multiagente in cui le decisioni sulle azioni dei singoli
agenti vengono prese all’interno di una singola unità sono detti centralizzati. Invece i sistemi in
cui non esiste tale unità, e le decisioni vengono prese di volta in volta dagli agenti interessati,
dopo opportune attività di coordinamento e negoziazione, sono detti distribuiti.
In [30] sono effettuate altre interessanti distinzioni tra categorie di sistemi multiagente:
Natura del comportamento: Un’ulteriore distinzione può essere definita per quanto riguarda il
comportamento e la natura delle azioni effettuate dal sistema: nel caso il sistema abbia degli
scopi predefiniti e cerchi attivamente di realizzarli, si parla di comportamento teleonomico, mentre se
le azioni sono legate esclusivamente agli stimoli provenienti dall’ambiente, i sistemi sono detti a
comportamento riflesso.
Interazioni tra gli agenti: In [30] possiamo trovare una suddivisione tra tre categorie di sistemi
multiagente (non necessariamente in ambito informatico) in base al tipo di interazioni che
hanno luogo tra gli agenti del sistema. Nei sistemi NI (No direct Interactions), ogni agente osserva
il comportamento degli altri agenti ed eventualmente modifica di conseguenza il proprio, ma
non interagisce direttamente con essi; i sistemi SI (Simple Interactive) prevedono che il
comportamento degli agenti abbia un’influenza limitata su quello dei loro vicini, mentre nei
sistemi CI (Complex Interactive) le azioni svolte dagli agenti influiscono drasticamente sul
comportamento degli altri.
Il sistema progettato e implementato in questa tesi si colloca nell’ambito dei sistemi multiagente. In
particolare il sistema di gestione del comfort termo igrometrico descritto può essere considerato un
sistema multiagente cognitivo ad architettura distribuita.
2.3.4. AMBIENT INTELLIGENCE
Nell’ambito dell’ambient intelligence, e in particolare delle smart home [1, 2, 3], le ricerche in corso
mirano a progettare e realizzare delle abitazioni sempre più al servizio degli abitanti, in grado di
prevedere le loro attività, anticipare i loro bisogni e ragionare automaticamente attraverso diversi tipi di
tecnologia interconnessa. L’attenzione per quanto riguarda il comfort termoigrometrico è rivolta
soprattutto alla rilevazione e alla previsione della presenza e delle attività degli abitanti, che permettono
ai sistemi di decision making di adattare e modificare le loro attività in modo autonomo, come succede
ad esempio nei progetti MavHome [5, 11, 12] e Neural Network House [6], che utilizzano algoritmi
predittivi, programmazione dinamica e reti neurali.
Nella Tabella 2.1 sono confrontate la varie tecniche di controllo di diversi aspetti degli edifici e sono
indicati i problemi e gli obiettivi a cui le tecniche sono di solito rivolte, in campo sperimentale e
commerciale.
18
Tab. 2.1 : Tabella comparativa dei sistemi di controllo del comfort domestico [8]
19
2.3.5. ESEMPI DI SISTEMI DI CONTROLLO
2.3.5.1.
HIERARCHICAL
FUZZY-GENETIC
ARCHITECTURE FOR INTELLIGENT BUILDINGS
MULTI-AGENT
Nel progetto illustrato in [14] viene utilizzato un approccio innovativo nel campo degli intelligent building,
basato su un architettura multiagente basata su un sistema double hierarchical fuzzy-genetic, composta da
due livelli di controllo: il primo agisce in modo reattivo e restituisce delle semplici regole di
comportamento del sistema, che vengono poi coordinate da un sistema fuzzy che agisce secondo gli
obiettivi di alto livello.
Le condizioni ambientali di un edificio sono soggette a variazioni continue e le preferenze degli utenti
possono differenziarsi sostanzialmente a seconda dello specifico utente, e nel corso del tempo: per
risolvere questi problemi si può ricorrere a tecniche di learning adattative e interattive. La logica fuzzy
offre un modo valido di rappresentare informazioni incerte o imprecise, e aumenta la robustezza del
sistema in cui viene adottata, nei confronti di disturbi e instabilità. Per stabilire le regole fuzzy di un
sistema, si possono utilizzare tecniche di apprendimento tramite algoritmi genetici, che però possono
non essere adatti ad ambienti dinamici e real-time, in cui lo spazio del problema non è completamente
definito dall’inizio.
Il sistema affronta il problema di individuare un metodo di apprendimento automatico adatto al
problema degli intelligent building, seguendo un approccio intelligent embedded-agent basato su sistema
double hierarchical fuzzy-genetic. Il sistema appartiene alla categoria delle behavior-based control
architectures: per evolversi nel tempo e apprendere regole di comportamento, non ha bisogno di una
simulazione a priori dell’ambiente, né dell’intervento diretto di utenti umani nel sistema di specifica
delle regole. L’edificio è diviso in zone: in ogni zona è posizionato un embedded-agent, a cui si
connettono tramite una rete LonWorks i sensori e gli attuatori collegati a quella zona; gli agenti
comunicano tra loro tramite una rete IP.
L’Hierarchical Fuzzy-Logic Controller (Fig. 2.5) si occupa del coordinamento tra i vari “agent-behaviour”:
fornisce un output che garantisce flessibilità: le diverse parti che lo compongono e i sotto-obiettivi
possono essere modificati e riconfigurati separatamente.
Obiettivi come il risparmio energetico sono perlopiù statici nel tempo (possono essere visti come
“vincoli” di alto livello che influenzano il comportamento degli agenti a prescindere dalle particolari
regole adottate), mentre il behaviour che definisce le regole che gestiscono il comfort è stabilito dai dati
ricavati da tecniche di learning basate sulle modifiche di comportamento degli abitanti; il controllore
assegna valori alla reinforcement function a seconda di quanto le azioni intraprese hanno soddisfatto gli
utenti (in base al fatto che questi modifichino o meno le configurazioni dell’ambiente).
Valori come temperatura e illuminazione della stanza vengono fuzzyficati da semplici membership
function delle variabili input, e lo stesso vale per i valori di output dei controllori, che poi vengono
defuzzyficati e ricevuti dagli attuatori. I valori fuzzy sono usati come input nelle context rules stabilite dal
planner di alto livello sulla base dell'obiettivo corrente dell'agente, e sono queste regole che vengono poi
20
Fig. 2.5 : Il sistema di controllo hierarchical-fuzzy [14]
modificate, aggiunte o rimosse a seconda dello stato dell’ambiente e dell’obiettivo del sistema, e che
definiscono quindi i vari comportamenti del sistema.
Per l’apprendimento e l’adattamento della rule base dinamica agli effettivi bisogni e alle richieste degli
abitanti dell’edificio, il sistema utilizza un approccio basato su algoritmi genetici. Viene definito online
learning l’apprendimento basato sull’interazione con l’ambiente e gli utenti, in contrasto all’offline
learning, che avviene internamente al sistema sulla base di dati già disponibili.
Ogni fuzzy logic controller riceve input dai sensori dell’abitazione, ha una propria rule base e delle
membership function, e invia il risultato della combinazione degli input al coordinator, il controllore centrale
che poi controlla gli attuatori. Quando nel sistema viene rilevato un cambiamento o ci si trova in una
situazione che non corrisponde a uno degli antecedenti di una regola tra quelle memorizzate nella rule
base, il sistema entra in modalità interattiva e aggiunge, toglie o modifica regole a seconda delle
necessità. Le regole sono valutate nell'Experience Value, e quelle in cui il valore di fitness (assegnato dal
sistema a ogni regola, e tanto maggiore quanto più una certa regola è utile a soddisfare l’obiettivo) è
minore, vengono eliminate per fare posto alle migliori.
L’Adaptive Genetic Mechanism è un algoritmo che entra in gioco quando nessuna tra le soluzioni
corrispondenti alle esperienze passate soddisfa le richieste dell’utente. L’AGM produce nuove soluzioni,
evitando quelle insoddisfacenti a priori, finché non ne trova una soddisfacente. La valutazione delle
soluzioni ottenute avviene attraverso un fitness evaluator.
21
2.3.5.2. TERMOSTATO PROGETTATO E IMPLEMENTATO SEGUENDO
UN APPROCCIO MULTIAGENTE
Il sistema presentato in [21] è stato progettato con l’obiettivo di applicare l’approccio dei sistemi
multiagente per realizzare un termostato “intelligente” che gestisca il comfort termico di una singola
stanza.
Il problema complessivo è stato quindi scomposto in sotto-obiettivi che, opportunamente coordinati,
contribuiscono a realizzare l’obiettivo finale del sistema. Ogni sotto-obiettivo è gestito da un agente, qui
chiamato controller-agent: i controller-agent sono i blocchi di base che costituiscono il sistema, e possono
essere rimossi o modificati singolarmente.
Gli obiettivi che il sistema si prefigge riguardano il mantenimento dell’ambiente nella zona comfort
stabilita dai setpoint; la possibilità di programmare gli istanti di tempo in cui deve essere raggiunta una
certa temperatura; la minimizzazione degli sbalzi improvvisi (on/off) del riscaldamento; la capacità di
gestire qualsiasi aspetto del controllo termico senza la necessità di regolazione manuale da parte
dell’utente; il raggiungimento delle temperature desiderate nel più breve tempo possibile e senza
overshooting.
L’approccio multiagente viene preferito ai controllori PID (principalmente perché quest’ultimo è
particolarmente soggetto a sbalzi improvvisi) e al controllo predittivo (per la forte dipendenza dei
parametri di quest’ultimo dalla specifica abitazione).
Ogni sottoproblema definisce un task; questi devono essere coordinati da un coordination system che può
essere centralizzato (il coordinatore decide univocamente quando un task deve essere attivo o inattivo)
o decentralizzato (i singoli agenti che gestiscono i task decidono quando è il momento di attivarsi, ma la
decisione finale spetta comunque al coordinatore).
I meccanismi di coordinamento possono variare: tra le possibilità possono essere utilizzati sistemi di
coordinamento a priorità fissa (ogni task ha un grado di priorità fissato, che stabilisce quando deve agire),
priorità dinamica (la priorità dei task può cambiare a seconda della situazione), “first stays active” (i task
vengono attivati seguendo l’ordine in cui hanno richiesto l’attivazione). Ogni agente riceve input
dall’esterno e dagli altri agenti, trasmette output agli altri agenti, elabora gli output attraverso calculation
functions, e stabilisce se diventare attivo o inattivo tramite activation functions.
Molto importante è il concetto di controller-agency, che viene usato quando si devono eseguire sottoobiettivi complessi, e che rappresenta un insieme di agenti che agiscono per lo stesso obiettivo, così
come sono visti da un agente esterno a essi: un controller-agency è trattato, cioè, come un singolo
agente dai meccanismi di coordinamento, come se avesse singole funzioni di input e output.
I due sottoproblemi principali in cui si suddivide il problema sono rappresentati dal setpoint generation
(che stabilisce i setpoint temporali e le rispettive temperature) e dal tracking controller (che si occupa di
fare sì che il sistema giunga alla temperatura desiderata rispettando i setpoint); quest’ultimo si
scompone nel transient control (che si occupa di grandi cambiamenti nei setpoint) e nel regulator (che
entra in gioco quando i setpoint sono costanti, e sono necessarie piccole regolazioni).
22
2.3.5.3. UN SISTEMA MULTIAGENTE PER CONTROLLARE AMBIENTI
DOMESTICI
Nel progetto [13] è stato implementato un sistema di distribuzione delle risorse termiche in un edificio
utilizzando un sistema multiagente market-based, in cui gli agenti partecipano a un'asta in cui vendono e
comprano aria riscaldata o raffreddata.
La divisione dell’ambiente in zone fa sì che ogni agente risponda alle esigenze di una particolare zona
(che nel caso più comune corrisponde a una singola stanza), in cui esso opera. Ogni agente deve essere
in grado di comunicare facilmente e in breve tempo con gli altri agenti per poter partecipare alle
“compravendite” e deve essere sensibile alle variazioni dell'ambiente per formulare la giusta offerta che
corrisponda alla situazione ambientale della sua zona.
Questo sistema è ritenuto molto vantaggioso rispetto ai classici controllori PID: infatti la temperatura
ottenuta nell’edificio si distribuisce in genere più uniformemente rispetto al caso dell’utilizzo di un
controllore classico.
Gli agenti utilizzano una forma di valuta che viene loro assegnata da un coordinatore centrale, e con cui
formulano offerte per vendere o comprare quantità di aria riscaldata o raffreddata da agenti che
controllano altre zone, a seconda dalla temperatura e delle condizioni ambientali della propria zona. Gli
agenti non conoscono le offerte formulate dagli altri agenti, a meno che non siano rivolte a loro stessi;
un coordinatore centrale gestisce gli scambi, e quando un’offerta va a buon fine, vengono modificate le
aperture delle valvole che regolano il passaggio tra le varie zone.
I problemi principali che le aste sono tenute a risolvere derivano dal fatto che gli utenti umani che
regolano i termostati negli uffici non sono a conoscenza delle risorse limitate degli agenti, della loro
possibile “scarsità di valuta” e della distribuzione della temperatura nell’edificio (cioè, gli utenti
cercheranno di ottenere sempre il massimo per loro stessi, mentre il compito degli agenti è quello di
gestire le risorse per coordinare le varie richieste).
23
2.3.5.4. UN SISTEMA MULTIAGENTE PER CONTROLLARE EDIFICI
INTELLIGENTI
Il sistema multiagente di [23] è stato progettato per controllare la temperatura, l’illuminazione e la
ventilazione in un ufficio, e si basa su un sistema di riconoscimento degli utenti tramite badge, da cui
rileva informazioni sulla presenza delle persone e sulla base di esse compie azioni che modificano
l’ambiente autonomamente. Il sistema è specificamente pensato per ambienti lavorativi, in quanto
l’adozione di un sistema di riconoscimento tramite badge in ambito domestico è una soluzione troppo
invadente.
Gli agenti del sistema sono suddivisi in quattro categorie: Personal Comfort agents: ognuno di essi
corrisponde a una singola persona, memorizza le sue abitudini e gestisce le su preferenze; Room agents:
ognuno di essi gestisce una singola stanza e cerca di soddisfare le richieste degli utenti presenti e nel
contempo di risparmiare il più possibile sui costi; Environmental Parameter agents: ognuno di essi controlla
un singolo aspetto del comfort di una stanza (per esempio, l’illuminazione o la ventilazione), hanno
accesso diretto a sensori e attuatori; e un Badge System agent che tiene traccia della posizione degli utenti e
mantiene un database su di essi.
Questo particolare sistema è in grado di prendere decisioni completamente differenti sulla base
dell’identità degli occupanti dell’edificio: per esempio, se in ufficio entra l’effettivo occupante il sistema
provvederà immediatamente a portare le condizioni ambientali al livello desiderato dall’occupante,
mentre si sarebbe comportato in modo diverso se fosse entrato un estraneo.
2.3.5.5. MAVHOME
L’obiettivo del progetto MavHome [5, 11, 12] è la realizzazione di un’abitazione che agisca come un
agente intelligente. L’architettura generale del sistema presenta quattro livelli di controllo: il decision layer
seleziona le azioni che gli agenti dovranno compiere sulla base delle informazioni in possesso
dell’information layer, che si occupa di immagazzinare e generare conoscenza e informazioni utili; il
communication layer permette la comunicazione di informazioni tra i vari componenti del sistema, mentre
il physical layer gestisce direttamente i dispositivi hardware che eseguono fisicamente le azioni stabilite
nell’edificio.
E’ di particolare interesse la funzione del sistema che permette di prevedere la prossima azione di un
abitante, per poter stabilire dei pattern di azioni da compiere in sequenza che coincidano con i bisogni e
le preferenze degli utenti: queste previsioni sono basate sulle interazioni degli utenti con i dispositivi
dell’abitazione, precedenti all’istante in cui si elabora la previsione: per essere efficaci devono essere
generalmente effettuate in tempo reale. Per generare un modello che indichi la prossime azioni attese
degli abitanti possono essere utilizzati vari metodi, come il sequence matching, il compression-based
predicition, il task-based Markov model, che elaborano la sequenza delle azioni che si verificano in
24
determinati momenti e situazioni, per predire quali eventi si verificheranno in futuro e con quali
probabilità; l’episode discovery che fa uso di tecniche di data mining per ricercare regolarità o eventi
particolari nel database degli avvenimenti passati.
L’algoritmo predittivo Active-LeZi utilizza principi di teoria dell’informazione per processare sequenze
di eventi consecutivi: rappresenta le interazioni abitante-ambiente con catene di Markov di eventi; è
intrinsecamente online per via della compressione dei dati usata. La ripetitività degli eventi dell’edificio
(dispositivi usati dagli abitanti) nel corso del tempo può essere modellizzata con un processo stocastico
stazionario. Per effettuare una predizione, l’algoritmo calcola la probabilità che le attività (rappresentate
da terne di simboli, in cui ogni terna indica il dispositivo che è stato usato, il tipo di interazione che si è
svolta con quel dispositivo, e l’istante di tempo in cui si è svolta) compaiano in una sequenza, e
restituisce come output l’attività che la più alta probabilità di verificarsi in quel momento.
La componente decision-making del sistema permette all’abitazione di automatizzare le funzioni basilari,
sulla base dei dati ottenuti dalle predizioni, per ottimizzare l’utilità e il comfort degli abitanti. Le
decisioni che vengono prese dal sistema si basano il meno possibile sulla semplice ripetizione delle
sequenze di azioni svolte in passato dagli abitanti, ma piuttosto sui risultati che gli utenti vogliono
ottenere eseguendo quelle azioni: dà cioè importanza a quelle variabili che rappresentano l’obiettivo
delle azioni, non alle azioni effettuate per ottenerle (che vengono usate come guida per ottimizzare delle
misure predefinite). Per esempio il fatto che un abitante accenda ogni mattina la luce alla stessa ora, non
impedisce al sistema di anticipare il bisogno di luce dell’utente aprendo le persiane invece che
accendendo la luce, se questa si rivela la scelta più conveniente a parità di risultato ottenuto.
Tecniche di reinforcement learning vengono usate per ottenere una policy che ottimizzi il comfort degli
abitanti: il sistema prende eventuali nuove decisioni ogni volta che cambia lo stato di uno dei dispositivi
della casa. La reward function utilizzata tiene conto in particolare della quantità di interazioni di cui gli
utenti hanno bisogno per ottenere le condizioni desiderate (con l’obiettivo di minimizzare queste
interazioni): cioè, il sistema si comporta bene se gli utenti interagiscono con i dispositivi domestici il
meno possibile, e del consumo energetico. La tecnica utilizzata per stimare i reward delle eventuali
azioni effettuate in futuro è il Q-learning.
2.3.5.6. NEURAL NETWORK HOUSE
L’obiettivo alla base del progetto Neural Network House [6] è di progettare e realizzare un’abitazione in
cui strumenti e dispositivi siano in grado di programmarsi da soli, cioè che apprendano con il tempo le
abitudini e le preferenze degli abitanti, e riescano infine ad anticiparli, in modo da ridurre il numero di
occasioni in cui siano necessari interventi umani nel controllo dell’abitazione, nello specifico per quanto
riguarda riscaldamento dell’aria e dell’acqua, illuminazione e ventilazione. Per ottenere ciò è di primaria
importanza che il sistema sia in grado di prevedere le azioni degli utenti: il sistema, chiamato ACHE
(adaptive control of home environments) (Fig. 2.6) ha l’ulteriore obiettivo del raggiungimento del maggiore
risparmio energetico possibile.
Ogni agente che si occupra della predizione di una specifica variabile, viene chiamato predictor. I
predictor sono implementati per mezzo di una feed-forward neural network con backpropagation, in cui il
25
controllo è suddiviso in due livelli: il setpoint generator si occupa di generare le predizioni vere e proprie,
mentre il device regulator si occupa di tradurre le informazioni a livello dei dispositivi fisici.
Fig. 2.6: Architettura del sistema ACHE [6]
Questa rete neurale apprende da input provenienti dall’ambiente (esempio: un utente modifica la
temperatura dal termostato) e costruisce modelli predittivi che comprendono la predizione di scenari a
lungo termine, in cui il verificarsi di un singolo evento anomalo isolato non pregiudica l’esito delle
predizioni in generale. In caso ci sia una scelta tra più di un’azione da compiere per soddisfare le stesso
obiettivo (per esempio, aumentare la ventilazione o raffreddare l’aria in circolo), il sistema sceglie
l’opzione che minimizza il consumo energetico.
26
CAPITOLO 3
IMPOSTAZIONE E FORMULAZIONE DEL PROBLEMA
Il problema della gestione automatica del comfort termoigrometrico in un edificio deve tenere conto di
molteplici parametri e variabili, che possono dipendere dal tipo di edificio in questione, dallo scopo a
cui è predisposto, dalle abitudini degli abitanti, dalle condizioni ambientali, e soprattutto dalla tipologia
dei dispositivi di gestione del comfort presenti nell’edificio e dal loro grado di automatizzazione.
In questa tesi si è cercato di impostare un problema nel modo più generale possibile, adattabile a
qualsiasi tipo di edificio e di situazione. Si fa l’ipotesi che gli abitanti possano o meno comunicare al
sistema preferenze sulle condizioni di comfort desiderate; si sono suddivisi i dispositivi dell’edificio in
quattro categorie principali che rispecchiano la maggioranza degli impianti di gestione della temperatura
e dell’umidità generalmente presenti in abitazioni o edifici lavorativi; il sistema è inoltre facilmente
adattabile a ricevere dati in input sulle preferenze degli utenti da eventuali sistemi basati su data mining
o apprendimento automatico.
Nel lavoro è stato scelto di formulare il progetto come un problema di ottimizzazione vincolata
distribuito. La distribuzione delle funzionalità del sistema è sembrata la scelta più adatta data la natura
stessa del problema: un edificio è diviso in varie zone che necessitano di condizioni climatiche
generalmente diverse tra loro, e in momenti diversi della giornata; inoltre la variazioni delle condizioni
di una zona possono facilmente influenzare quelle delle zone vicine, perciò un sistema che agisca
tramite vari agenti posizionati nella varie zone dell’edifico, che interagiscono e cooperano tra loro rende
naturale la scelta di un approccio distribuito.
I principali vantaggi di un approccio distribuito, rispetto ad uno centralizzato possono essere così
riassunti:
Gli agenti del sistema possono facilmente interfacciarsi con dispositivi eterogenei e molto
diversi tra loro.
Maggiore affidabilità generale del sistema: il fallimento di una parte o di un agente del sistema
non comporta grandi conseguenze per il resto del sistema.
Alleggerimento del carico di lavoro delle singole componenti del sistema: rispetto ad un sistema
centralizzato, i singoli processi che compongono il sistema devono occuparsi solo di una parte
del lavoro.
Vantaggi economici dovuti alla possibilità di scegliere per ogni componente quanto di meglio
(in termini economici e/o qualitativi) offre il mercato.
Maggiori scalabilità e modularità delle componenti hardware e software.
L’approccio distribuito comporta anche alcuni svantaggi:
Maggiore complessità dell’architettura del sistema dovuta alla decentralizzazione del contollo.
Maggiore complessità del software di gestione del sistema.
Possibile nascita di problemi di comunicazione tra le componenti del sistema, o comunque loro
intensificazione rispetto a un approccio centralizzato.
27
Lo
o scopo della tesi è valutare dal punto di vista teorico (riguardo
(riguardo al numero, alla scelta e alle
caratteristiche di agenti, variabili e vincoli del problema)
problema e sperimentale (riguardo
riguardo al tempo di
esecuzione, alla scelta degli algoritmi disponibili e alla calibrazione dei parametri del sistema
sistema) come
diverse formulazioni del problema di ottimizzazione vincolata
vincolata distribuito si comportano nel risolvere
problemi di ottimizzazione del comfort termoigrometrico.
Nella sezione seguente è presentata in modo sintetico la totalità dei parametri di cui si può tenere conto
nella progettazione di un sistema di gestione
gestion del comfort, inoltre sono elencate le possibili misure di
valutazione dei risultati finali ottenuti dal sistema.
sistema Nella sezione successiva viene data una definizione di
distributed constraint optimization problem (DCOP), sono poi presentate l’impostazione generale del
problema trattato dalla tesi e laa sua formulazione, relativamente
rela
all’approccio DCOP. Infine sono
descritte le caratteristiche della varie formulazioni scelta per rappresentare il problema come una
successione di DCOP o come Dynamic DCOP, o DDCOP.
D
3.1. PARAMETRI SIGNIFICATIVI
Nella progettazione di un innovativo manager del comfort termoigrometrico, si può tenere conto de
dei
seguenti parametri, di seguito suddivisi in due categorie: parametri che tengono conto di stati e azioni
passati dell’ambiente e degli abitanti, e parametri basati su previsioni, modellizzazioni o eventi futuri.
3.1.1. INFORMAZIONI SUL PASSATO
Struttura edificio
I sistemi che tengono conto di questo parametro basano le loro scelte sulle caratteristiche specifiche
dell’ambiente, espresse da un modello dell’edificio e da leggi che descrivono l’andamento di
temperatura e umidità nel tempo. Possono essere basati su modelli
modelli che descrivono andamento di
temperatura e umidità negli edifici. Sono implementati da software
s
chee simulano consumi energetici in
un edificio (ad esempio EnergyPlus).
EnergyPlus) Permettono diverse tipologie di controllo, come centrale
(edificio), regionale (ad esempio: piano), locale (stanza)
(stanza).
Preferenze abitanti
I sistemi che tengono conto di questo parametro
parametro devono seguire delle indicazioni e dei vincoli derivanti
dalle specifiche dirette degli abitanti.. Possono essere in grado di pianificare attività in base a orari e
attività specificate dagli utenti. Possono essere integrati a software per la creazione agende
ende e programmi
(esempio: Google Calendar).Nelle
Nelle abitazioni, possono rivolgere semplici questionari
ionari agli abitanti per
stabilire ad esempio uno schedule settimanale.
settimanale
28
Rilevazione attività abitanti
I sistemi che tengono conto di questo parametro modificano la configurazione dell’ambiente in base a
rilevazione di presenza o tipologia di attività svolta dagli abitanti.
abitanti Sono spesso dotati di ssensori di
rilevazione presenza (ad esempio: sensori di movimento); di sensori di rilevazione
ilevazione dell’accensione
luci/elettrodomestici/dispositivi. Sono adatti ad altri
altri tipi di interazioni (esempio: accensione
riscaldamento con il giusto anticipo rispetto all’ora a cui è settata la sveglia).
sveglia) Alcuni sono in grado di
stimare l’affollamento delle stanze e di calcolare di conseguenza
consegue
la temperatura desiderata
desiderata.
Rilevazione caratteristiche ambiente
I sistemi che tengono conto di questo parametro modificano la configurazione dell’ambiente in base a
rilevazione di caratteristiche variabili della stanza o dell’edificio, come l’apertura
l’apertura o la chiusura di una
porta o di una finestra. Comandi elettronici come la chiusura di tende o serrande o l’apertura delle
finestre possono anche essere usate come attuatori, nei sistemi avanzati in ambito smart home, per
modificare le caratteristiche termoigrometriche dell’ambiente.
dell’ambiente
3.1.2. PREVISIONI DEL FUTURO
Previsioni meteorologiche
I sistemi che tengono conto di questo parametro stimano le condizioni ambientali presenti e future
basandosi su valori come temperatura o tempo atmosferico previsti,
previsti, raccolti da servizi esterni, sulla
base dei quali prevedere le condizioni ambientali dell’edificio.
dell’edificio Possono essere integrati con un sservizio
esterno da cui estrapolare dati meteorologici (esempio: WeatherUnderground). I dati
ati maggiormente
utilizzati sono la temperatura dell’aria, umidità relativa, irraggiamento solare globale
globale. Svolgono una
successiva interpolazione dei dati. Eventualmente
Eventual
possono affidarsi a più servizi per compensare le
imprecisioni. Possono inoltre ripianifica
ipianificare gli obiettivi nel caso di previsioni disattese.
Posizione del sole
I sistemi che tengono conto di questo parametro stimano le condizioni ambientali presenti e future
basandosi su particolari valori che derivano dalla posizione solare:
solare radianza,
adianza, irradianza, illuminanza.
Tipicamente questi valori non sono forniti da servizi meteorologici. Possono incidere su temperatura e
umidità nella simulazione dell’edificio.
dell’edificio
29
Predizione attività abitanti
I sistemi che tengono conto di questo parametro raccolgono dati da algoritmi di predizione di presenza
e/o tipologia di attività svolte in futuro dagli abitanti, in base ai quali stabilire una programmazione
ottimale per soddisfare automaticamente gli obiettivi richiesti. Si pongono come obiettivi di prevedere
nel modo più accurato possibile le attività degli abitanti, reagire il più immediatamente a singoli eventi
anomali, soddisfare le richieste di uno o più utenti contemporaneamente minimizzando il consumo
energetico. Di solito tengono conto della maggior parte dei parametri precedenti per effettuare raccolta
dati e eventuali attività di data mining. I sistemi che introducono l’identificazione degli utenti sono di
solito ritenuti troppo invasivi per essere utilizzati nelle abitazioni, ma più adatti ad ambienti lavorativi.
Per implementare questi sistemi sono di solito necessari metodi di controllo predittivo e/o machine
learning: tra i più adatti si citano catene di Markov, controllo ottimo, regole fuzzy.
30
La Tabella 3.1 indica i parametri maggiormente tenuti in considerazione dai vari metodi di controllo del
comfort e dai sistemi multiagente e di ambient intelligence analizzati.
Struttura Posizione Preferenze Rilev
Rilev
Previsioni Predizione
edificio
sole
abitanti
attività ambiente
meteo
attività
Controllo
predittivo [17]
Intelligenza
computazionale
[8]
Behavior based
systems [21]
Controllo multi
agente [7]
Hierarchical
Fuzzy-Genetic
[14]
Termostato
multiagente
[21]
MAS marketbased [13]
MAS basato su
badge [23]
MavHome [5]
Neural
Network
House [6]
Tab. 3.1: Tabella riassuntiva dei metodi di controllo del comfort
La Tabella 3.2 indica i parametri maggiormente tenuti in considerazione dai sistemi commerciali di
controllo del comfort analizzati.
Struttura
edificio
Preferenze
abitanti
Rilev
attività
Previsioni
meteo
Predizione
attività
Termostato
Nest
Termostato
CGA
Smart Temp
Loxone
KNX
Ebac Smart
Control
Tab. 3.2: Tabella riassuntiva dei sistemi commerciali di controllo del comfort [Sez. 2.2]
31
3.2. MISURE DI VALUTAZIONE DEL COMFORT
La progettazione e la realizzazione di un software che controlli il comfort termoigrometrico di un
edificio dovrà raggiungere specifici obiettivi se confrontato con soluzioni esistenti scientifiche o
commerciali, in particolare i risultati potranno essere valutati concretamente misurando una o più delle
seguenti variabili.
Il rapporto tra il tempo in cui le condizioni ambientali dell’edificio sono comprese nella
zona di comfort secondo l’indice PMV, e il tempo in cui si richiede che lo siano, a seconda
della presenza e delle preferenze degli abitanti.
La minimizzazione dell’ indice PPV, che indica la percentuale degli individui insoddisfatti di
una data condizione ambientale.
La differenza tra la temperatura istantanea media ottenuta utilizzando il sistema con quella
ottimale richiesta dagli abitanti in vari momenti e periodi.
La differenza tra l’umidità relativa istantanea media ottenuta utilizzando il sistema con quella
ottimale richiesta dagli abitanti in vari momenti e periodi.
L’intervallo di tempo tra l’istante in cui sono richieste delle particolari condizioni di comfort
e quello in cui il sistema raggiunge tali condizioni.
Il consumo energetico dei sistemi di riscaldamento, condizionamento aria, ventilazione e
simili, per mezzo di opportune simulazioni software.
32
3.3. DCOP: Distributed Constraint Optimization Problem
L’approccio DCOP [2] è utilizzato per modellare una grande varietà di problemi riguardanti il
coordinamento e la cooperazione nei sistemi multiagente, tra cui pianificazione distribuita, allocazione
di risorse distribuita, robotica, reti di sensori e molti altri. Il modello DCOP costituisce un’utile struttura
di base per ricercare soluzioni che permettano agli agenti di coordinare al meglio le loro decisioni in
questi domini.
Un problema DCOP è modellizzato da una tupla <A, V, D, F, α, η>. A = {ai}, 0 ≤ i ≤ n è l’insieme
finito degli agenti. V = {vi}, 0 ≤ i ≤ m è l’insieme finito delle variabili. D = {Di}, 0 ≤ i ≤ m è l’insieme dei
domini finiti, dove Di è l’insieme dei possibili valori per la variabile vi. F = {fi}, 0 ≤ i ≤ p è l’insieme dei
vincoli, in cui ogni vincolo: fi : Di1 x Di2 x … x Dik → ℝ ∪ ±∞, 2 ≤ k ≤ m specifica un costo come
funzione dei valori delle variabili che condividono il vincolo. α è una funzione che associa ogni variabile
all’agente che la controlla: α(vi) → aj. η è un operatore che aggrega, tipicamente sommandoli, tutti i costi
dei singoli vincoli per ogni possibile assegnamento.
Una soluzione del DCOP è costituita da un assegnamento a tutte le variabili del problema. Il costo della
soluzione è dato dall’operatore η, applicato ai costi di tutti i vincoli condivisi dalle variabili della
soluzione. Trovare la soluzione ottima di un DCOP significa trovare la soluzione che minimizza (o
massimizza, a seconda dei casi) il costo complessivo, come espresso dalla funzione obiettivo.
I vincoli del problema esprimono le condizioni che gli assegnamenti alle variabili devono rispettare, per
costituire delle soluzioni accettabili all’interno del dominio rappresentato dall’ambiente del problema.
Nell’ambito di questa tesi possono essere suddivisi in due tipologie.
I vincoli strutturali, che esprimono le limitazioni e le condizioni che devono essere rispettate in
modo che il modello del problema rappresenti in maniera sufficientemente corretta l’ambiente
che vuole rappresentare: sono, cioè, imposti dalla struttura dell’ambiente e del mondo esterno.
I vincoli relativi alle decisioni dell’utente, che sono stabiliti dalle preferenze e dagli obiettivi che gli
utenti comunicano al sistema; non sono imposti dall’ambiente, ma dalla tipologia e dagli
obiettivi del problema che il sistema deve risolvere.
La funzione obiettivo indica la condizione finale che una soluzione del problema deve rispettare per
essere considerata una soluzione ottima, perciò può essere considerata come un vincolo dipendente
dall’utente, in quanto rappresenta il più importante obiettivo che si deve raggiungere per risolvere il
problema nel suo complesso.
33
3.4. IMPOSTAZIONE DEL PROBLEMA
In questa sezione è descritta l’impostazione di un problema generale per la gestione del comfort
termoigrometrico, corrispondente a una successione di DCOP, che possono, in casi limite, ridursi a un
DCOP singolo. Più avanti, in questo capitolo, si tratteranno più nel dettaglio le possibili formulazioni
del problema riguardanti l’insieme dei DCOP che lo costituiscono, tra cui una semplice serie di DCOP
in successione o un Dynamic DCOP.
L’obiettivo del problema è gestire il controllo delle condizioni ambientali di un edificio, nel più grande
numero di situazioni possibile e tenendo conto di tutti i fattori più significativi. L’approccio DCOP è
stato applicato a un sistema che rileva le variazioni di temperatura e umidità nelle varie zone
dell’edificio, e gestisce dispositivi di riscaldamento, di condizionamento dell’aria, di ventilazione e di
(de)umidificazione oltre che l’apertura o la chiusura automatica di tutte le porte e le finestre dell’edificio.
L’edificio è diviso in zone; ogni zona corrisponde a una stanza, un corridoio o una simile area
dell’edificio. Ogni agente del sistema corrisponde esattamente ad un dispositivo che controlla un
attuatore. Per semplicità, nel problema si suppone che ogni zona sia sempre confinante con esattamente
altre due zone, e che abbia sempre due porte e una finestra. Ovviamente questa è solo una
semplificazione utile a presentare il problema in termini generali, in quanto il numero di zone
confinanti, di porte e di finestre varia da zona a zona e da edificio a edificio, e queste caratteristiche
devono essere naturalmente rappresentate nel modello dell’edificio in questione, e di conseguenza
nell’impostazione del problema.
L’utente può interagire con il sistema indicandogli le condizioni ambientali desiderate e le zone e gli
istanti di tempo in cui desidera che queste condizioni siano raggiunte, in due modi.
Prima che abbia inizio un ciclo di problemi DCOP, corrispondente a un problema complessivo,
l’utente può stabilire dei setpoint e comunicarli al sistema attraverso un’apposita interfaccia: per
ogni setpoint, l’utente dovrà indicare la temperatura desiderata (che verrà interpretata dal
sistema come temperatura percepita dagli abitanti, per quanto riguarda il calcolo della
temperatura effettiva dell’ambiente) e l’eventuale umidità desiderata; gli orari di inizio e fine
dell’intervallo di tempo in cui temperatura e umidità dovranno mantenersi su tali valori; e la
zona o le zone dell’edificio che dovranno trovarsi a quella temperatura e umidità. Tipicamente
l’orizzonte temporale del problema corrisponderà a 24 ore, sarà perciò possibile comunicare le
preferenze degli utenti al sistema nella giornata precedente a quella in cui si desidera che siano
ottenute. E’ possibile specificare un giorno preciso, o stabilire degli schedule regolari, validi ad
esempio per uno specifico giorno della settimana o per tutti i giorni della settimana.
L’utente può comunicare al sistema una determinata variazione di temperatura o umidità in
qualunque momento, durante il suo funzionamento: in ogni zona, può configurare un
termostato e i relativi indicatori di temperatura e umidità, o in alternativa può agire su
un’interfaccia di controllo che gestisce contemporaneamente le condizioni di tutte le zone
dell’edificio; il sistema cercherà da quel momento in poi di raggiungere tali condizioni nel più
breve tempo possibile, ma il tempo effettivo che impiegherà dipenderà, oltre che dalle
condizioni attuali dell’edificio, anche dalla durata della validità delle soluzioni dei singoli
34
problemi DCOP: se questa è stata estesa per ridurre la complessità del problema, il sistema
potrebbe reagire in ritardo alle indicazioni dell’utente, mentre maggiore sarà la frequenza dei
singoli DCOP, più velocemente il sistema si adatterà alle modifiche impreviste dei desideri
dell’utente.
Oltre alle informazioni e alle preferenze specificate dagli utenti, il sistema può ricavare le informazioni
di cui ha bisogno per impostare i DCOP, basandosi su altri fattori che non dipendono direttamente
dalle decisioni degli utenti.
Utilizzando indicatori come l’indice PMV descritto nella Sezione 2.1, il sistema può conoscere
le condizioni ambientali ideali per gli abitanti dell’edificio, e quindi cercare di mantenere queste
condizioni nell’ambiente senza che vi sia alcuna richiesta da parte dell’utente; associando questa
caratteristica a funzioni come la rilevazione di presenza o il riconoscimento delle attività svolte
dagli abitanti, si può fare in modo che le condizioni ambientali ideali siano raggiunte solo
quando effettivamente ce ne sia bisogno, ottimizzando così i consumi e le prestazioni del
sistema, inoltre si può permettere al sistema di reagire a eventuali eventi imprevisti come il
rientro a casa inaspettato di un abitante.
Utilizzando tecniche di learning o data mining, il sistema può raccogliere dati da algoritmi di
predizione riguardo gli orari di presenza e/o le attività svolte dagli abitanti, in modo da stabilire
una programmazione ottimale per soddisfare automaticamente il maggior numero di desideri
degli abitanti, senza che questi comunichino i loro obiettivi direttamente al sistema; in questo
modo il sistema agirà sui dispositivi dell’abitazione in base alle attività che si prevede che gli
abitanti svolgeranno con maggiore probabilità. Questo approccio può sostituire del tutto la
programmazione manuale del sistema da parte degli utenti, o può integrarsi con essa.
L’orizzonte temporale è una variabile che indica la lunghezza dell’intervallo di tempo che corrisponde a un
problema complessivo, cioè a una serie di iterazioni di singoli problemi(DCOP) di ottimizzazione: il
sistema può pianificare eventi e previsioni a lungo termine che avverranno lungo questo intervallo, e gli
utenti possono impostare preferenze e schedule predefiniti; l’intervallo di ripianificazione indica invece la
lunghezza dell’intervallo di tempo tra un problema di ripianificazione e il successivo; ad esempio, con
un orizzonte temporale di 24 ore e un intervallo di ripianificazione di 10 minuti, durante un ciclo di
iterazioni lungo 24 ore il sistema dovrà risolvere 144 singoli problemi DCOP di ottimizzazione, uno
ogni 10 minuti per 24 ore. La lunghezza dell’intervallo di ripianificazione influenza la reattività del
sistema: come detto, con un intervallo molto breve, un cambiamento dell’ambiente o il verificarsi di un
evento imprevisto provocheranno un’immediata reazione del sistema, che genererà un nuovo problema
DCOP che tiene conto dei nuovi cambiamenti non appena avrà inizio il prossimo intervallo di
ripianificazione. Un intervallo molto lungo comporterà tempi di reazione più estesi, ma corrisponderà
anche alla generazione di meno problemi DCOP nell’arco dell’orizzonte temporale, diminuendo quindi
la complessità del problema complessivo. E’ così possibile cercare un compromesso adatto tra
efficienza e complessità, modificando questi due parametri temporali. Se si fanno coincidere i due
parametri, cioè se la durata complessiva dell’orizzonte temporale coincide con l’intervallo di
ripianificazione, il problema complessivo si ridurrà a un singolo problema DCOP: cioè il sistema non
terrà conto di alcun cambiamento che avverrà nell’ambiente lungo la durata dell’orizzonte temporale.
35
Il sistema cercherà di ottenere le migliori condizioni possibili, secondo le preferenze degli utenti, o in
base all’eventuale calcolo automatico di condizioni di comfort ideali, minimizzando la potenza totale
richiesta per ottenere tali condizioni, cioè la somma dei costi dei dispositivi attivati in tutte le zone
dell’edificio, per ogni intervallo di ripianificazione dell’orizzonte temporale. Inoltre la somma dei costi
in un dato intervallo non dovrà mai superare il limite massimo di potenza disponibile all’interno della
rete dell’edificio. I dati rilevati in input da ogni agente (supponendo che il dispositivo corrispondente
all’agente sia in grado di riceverli), in ogni istante di tempo, sono:
La temperatura e l’umidità relativa esterne dell’edificio.
La temperatura e l’umidità relativa attuali della sua zona.
La temperatura e l’umidità relativa attuali delle zone confinanti.
La temperatura e umidità relativa desiderate nella sua zona, per tutti gli istanti di tempo futuri
per cui sono specificate, cioè temperatura e umidità ideali che si dovranno raggiungere in quella
zona in specifici istanti di tempo nel corso dell’orizzonte temporale: sono stabilite tenendo
conto di tutti i parametri che le influenzano.
Dalle variabili precedenti ogni agente calcola le velocità di variazione della temperatura e
dell’umidità relativa per il prossimo time step, che indica quanto velocemente dovranno variare
temperatura e umidità nel corso del prossimo intervallo di tempo, per raggiungere gli obiettivi
desiderati, che possono essere immediati o relativamente a lungo termine.
In ogni zona è presente un agente per ognuno dei seguenti attuatori:
Impianto di riscaldamento: Accensione/spegnimento e regolazione.
Impianto di condizionamento: Accensione/spegnimento e regolazione.
Impianto di ventilazione: Accensione/spegnimento e regolazione.
Impianto di umidificazione/deumidificazione: Accensione/spegnimento e regolazione.
Apertura automatica porte.
Apertura automatica finestra.
Nelle Appendici A.1 e A.2 sono mostrati degli esempi di problemi DCOP come descritti in questa
sezione.
36
3.5. FORMULAZIONE DEL PROBLEMA COME DCOP
Possiamo esprimere il problema come segue:
n: numero delle zone dell’edificio.
(aheat1, acond1, avent1, ahumd1, adoor11, adoor21, awind1, aheat2, …, awindn): insieme degli agenti del sistema: ogni
agente controlla esattamente un dispositivo di una singola zona.
P: valore costante che rappresenta la potenza massima disponibile all’interno della rete.
γ: coefficiente compreso tra 0 e 1 che ha la funzione di pesare la componente riguardante il
consumo energetico nella funzione obiettivo; un valore piccolo o prossimo allo 0 significa che il
sistema si occuperà con maggiore priorità di ottenere le condizioni desiderate dagli abitanti
dell’edificio, al contrario un valore alto di γ significa che il consumo energetico avrà maggiore
importanza nella ricerca della soluzione ottima, a discapito delle migliori condizioni di comfort
ottenute. Il valore di default è stato impostato a 0,33 e sarà variato in una delle prove
sperimentali nella Sezione 6.3.1.
(heat1, cond1, vent1, humd1, door11, door21, wind1, heat2, …, windn): insieme delle variabili che
controllano i dispositivi che gestiscono il comfort nell’edificio. Ogni variabile assume un valore
specifico ad ogni intervallo di ripianificazione (che corrisponde a un singolo problema DCOP);
il valore della variabile si riferisce al funzionamento del rispettivo dispositivo per il successivo
intervallo di tempo, fino alla generazione di un nuovo DCOP. Per ogni zona, la variabile heat
gestisce l’intensità del riscaldamento di quella zona, la variabile cond l’intensità del riscaldamento
o raffreddamento dell’aria tramite condizionamento, la variabile vent l’intensità della
ventilazione, la variabile humd l’intensità dell’umidificazione o deumidificazione dell’aria. Le
variabili binarie door1, door2 e wind indicano se le porte e la finestra della zona dovranno essere
chiuse o aperte.
(Dheat1, Dcond1, Dvent1, Dhumd1, Ddoor11, Ddoor21, Dwind1, Dheat2, …, Dwindn): insieme dei domini delle variabili
che controllano i dispositivi; i valori corrispondono a comandi che saranno comunicati ai
dispositivi controllati, indicati da valori discreti che possono essere adattati a qualunque
dispositivo o insieme di dispositivi, per esempio il valore VERY_LOW per la variabile vent1
potrebbe corrispondere a un’intensità pari a “1 su 5” per un particolare dispositivo di
ventilazione, ma potrebbe corrispondere all’intensità “1 su 3” per un altro dispositivo;
ovviamente è possibile modificare cardinalità e tipologia di questi domini, a condizione di
modificare di conseguenza le funzioni di valutazione che elaborano le informazioni ottenute
dalle variabili che gestiscono i dispositivi.
o i domini Dheat possono assumere il valore OFF, che indica che il riscaldamento non è
attivo, o valori discreti che indicano l’intensità del riscaldamento.
Dheat = {OFF, VERY_LOW, LOW, NORMAL, HIGH, VERY_HIGH}
o i domini Dcond possono assumere il valore OFF, che indica che il condizionamento non è
attivo, o valori discreti che indicano se l’aria condizionata sta riscaldando o raffreddando
l’ambiente, e con quale intensità.
Dcond = {OFF, VERY_COLD, COLD, HOT, VERY_HOT}
37
o i domini Dvent possono assumere il valore OFF, che indica che la ventilazione non è
attiva, o valori discreti che indicano l’intensità della ventilazione.
Dvent = {OFF, VERY_LOW, LOW, NORMAL, HIGH, VERY_HIGH}
o i domini Dhumd possono assumere il valore OFF, che indica che l’umidificazione o
deumidificazione non sono attive, o valori discreti che indicano se l’impianto sta
umidificando o deumidificando l’ambiente, e con quale intensità.
Dhumd = {OFF, DEHUM_HIGH, DEHUM_LOW, HUM_LOW, HUM_HIGH}
o i domini Ddoor1, Ddoor2 e Dwind possono assumere i valori {OPEN, CLOSED}.
TH: valore costante, espresso in secondi, che indica la durata dell’orizzonte temporale, cioè del
problema complessivo che comprende l’insieme dei singoli problemi DCOP.
RI: valore costante, espresso in secondi, che indica la durata di un singolo intervallo di
ripianificazione, cioè dell’intervallo in cui, assegnati valori alle variabili del rispettivo problema
DCOP, i dispositivi del sistema cercheranno di mantenere i valori indicati da quelle variabili.
TS: insieme, dipendente dai valori dei parametri TH e RI, che rappresenta i time step (a partire da
1) in cui è suddiviso l’orizzonte temporale: al raggiungimento di ogni time step, il sistema
risolverà un singolo DCOP; l’insieme di tutti i problemi DCOP risolti, uno per ogni elemento
di TS, costituisce il problema complessivo; la cardinalità di TS è uguale alla divisione intera tra
TH e RI, e se l’orizzonte temporale corrisponde all’intervallo di ripianificazione, TS è costituito
da un unico elemento, e il problema si riduce a un unico problema DCOP
Per esempio, se TH = 86400 s (24 ore) e RI = 600 s (10 minuti), TS = {1, 2, …, 144}.
(vt1, vh1, vt2, …, vhn): insieme delle variabili, espresse in °C/h(vt) e %/h(vh), che ad ogni intervallo
di ripianificazione, indicano la velocità con cui, in ogni zona, dovranno variare temperatura e
umidità relativa, per rispettare gli obiettivi prestabiliti di raggiungimento delle condizioni di
comfort desiderate. Questi valori sono calcolati dal sistema tenendo conto di tutti i parametri
significativi (per esempio considerando il fatto che una variazione dell’umidità comporta
direttamente una variazione della temperatura percepita dagli esseri umani), e forniti come input
per il DCOP, al raggiungimento di ogni intervallo di ripianificazione.
(valt1, valh1, valt2, …, valhn): insieme delle funzioni di valutazione associate alle zone dell’edificio:
per ogni assegnamento alle variabili dei dispositivi di una data zona, le funzioni valt e valh di
quella zona restituiscono la velocità con cui, in quella zona, si prevede che varieranno
temperatura e umidità relativa nel prossimo intervallo di tempo; queste funzioni tengono conto
di tutti i parametri significativi che influiscono sulle condizioni ambientali, e possono
differenziarsi tra le varie zone a causa di caratteristiche come la posizione e la dimensione delle
zone. Queste funzioni verranno usate nei vincoli per confrontare gli effetti delle varie
configurazioni dei dispositivi con le velocità desiderate (variabili vt, vh).
(cheat1, ccond1, cvent1, chumd1, cheat2, …, chumdn): insieme delle funzioni di costo associate ai
dispositivi presenti nelle zone dell’edificio: ogni funzione di costo fornisce il valore della
potenza consumata dal rispettivo dispositivo attivo nella relativa zona, che assume il valore
indicato dalla rispettiva variabile del DCOP; si suppone che l’apertura e la chiusura elettroniche
di porte e finestre non consumino potenza, perciò non sono presenti funzioni di costo per
queste variabili, che non sono considerate nel calcolo della potenza totale assorbita dal sistema.
38
Variabili del problema DCOP
(heat1, cond1, vent1, humd1, door1, wind11, wind21, heat2, …, wind2n): insieme delle variabili, ognuna
controllata da un singolo agente, associate ai dispositivi che gestiscono il comfort nell’edificio.
(Dheat1, Dcond1, Dvent1, Dhumd1, Ddoor1, Dwind11, Dwind21, Dheat2, …, Dwind2n): insieme dei domini delle variabili
associate ai dispositivi.
Vincoli del problema DCOP
Funzioni di costo: le funzioni di costo restituiscono, per ogni zona e per ogni intervallo di
ripianificazione, la potenza totale che i dispositivi di quella zona assorbirebbero se fossero attivi
durante il prossimo intervallo, assumendo i valori ottenuti da una data assegnazione alle relative
variabili; è presente una funzione di costo per ogni zona:
cj = cheatj + ccondj + cventj + chumdj, 1 ≤ j ≤ n.
Vincolo di potenza massima: vincolo globale che stabilisce che la somma della potenza
assorbita dagli agenti di tutte le zone, in ogni intervallo di pianificazione, non deve superare il
valore della potenza massima; a quegli assegnamenti che comportano una potenza assorbita
totale superiore al limiti, viene assegnato un costo infinito:
P - ∑ =1 cj < 0 → costo: ∞.
Vincoli di coerenza con gli obiettivi di comfort: questi vincoli associano a ogni assegnamento
alle variabili di ogni zona di un dato intervallo di ripianificazione, la velocità con cui, in quella
zona, si prevede che varieranno temperatura e umidità relativa in quell’intervallo di
ripianificazione; le funzioni valt e valh si occupano di valutare le condizioni ambientali e di
restituire le velocità, sulla base dei valori di un dato assegnamento alle variabili della rispettiva
zona. I valori restituiti da questi vincoli (le variabili vart e varh) verranno utilizzati nella funzione
obiettivo, che sceglierà la soluzione che minimizza loro somma. Le funzioni valt e valh terranno
conto anche delle possibili correlazioni tra le variazioni di temperatura e umidità: ad esempio,
una stessa temperatura percepita può essere raggiunta agendo sulla temperatura effettiva oppure
sull’umidità della zona; in entrambi i casi, il vincolo accetterà gli assegnamenti, poi
successivamente la funzione obiettivo stabilirà quale sia quello che consuma meno energia e che
sarà quindi selezionato come soluzione, per quanto riguarda quella zona dell’edificio.
vartj = valtj(heatj, condj, ventj, humdj, doorj, wind1j, wind2j),
varhj = valhj(heatj, condj, ventj, humdj, doorj, wind1j, wind2j), 1 ≤ j ≤ n
39
Funzione obiettivo
La funzione obiettivo da minimizzare è costituita dalla somma di due componenti X1 e X2:
X1 è la somma dei valori assoluti delle differenze tra le velocità desiderate di temperatura e
umidità, e le velocità ottenute grazie agli assegnamenti delle variabili di tutte le zone dell’edificio.
La sua minimizzazione corrisponde intuitivamente all’avvicinamento agli obiettivi del problema,
essa è infatti tanto minore quanto più le condizioni dell’edificio convergono verso gli obiettivi di
comfort definiti dal problema.
X1 = ∑ =1 [abs(vtj - vartj) + abs(vhj - varhj)]
X2 è la somma delle funzioni di costo di tutte le zone dell’edificio calcolate secondo gli
assegnamenti delle variabili corrispondenti, pesata secondo un parametro γ, con 0 ≤ γ ≤ 1.
X2 = γ ∑ =1 cj
Perciò la funzione complessiva da minimizzare sarà: X* = argmin(X1 + X2).
40
3.6. FORMULAZIONI DEL PROBLEMA COME SUCCESSIONE DI DCOP
O DDCOP
Il problema complessivo, inteso come una successione di singoli problemi DCOP che devono essere
risolti a intervalli regolari nel corso della durata dell’orizzonte temporale, è stato formulato in questa tesi
secondo vari approcci, illustrati in questa sezione.
3.6.1. DCOP UNICO CON VARIABILI VETTORIALI
Inizialmente è stato pensato di rappresentare la successione di DCOP come un unico DCOP, in cui
siano presenti variabili strutturate come una sequenza di valori nel tempo. Le variabili relative ai DCOP
sarebbero così costituite da vettori, di lunghezza pari al numero di time step in cui è suddiviso il
problema complessivo, e conterrebbero i valori della rispettiva variabile in ogni intervallo di
ripianificazione. Questo approccio non si è però rivelato ottimale per rappresentare questo tipo di
problema: innanzitutto esso ha portato a un’esplosione della complessità del problema, che prevede un
grande numero di possibili valori per le variabili e di interazioni tra di esse riguardo a un singolo
DCOP; raggruppare in unico DCOP le variabili e i vincoli di tutta la successione dei DCOP avrebbe
reso ingestibile il problema per gli algoritmi a disposizione di FRODO, il framework utilizzato in
questo lavoro e descritto nella Sezione 4.1. Inoltre, la natura stessa del problema rende inappropriata
questa rappresentazione: gestire le condizioni di comfort di un edificio è un’attività che richiede un
controllo dinamico e reattivo, e in cui i cambiamenti delle condizioni dell’ambiente nel tempo
influenzano direttamente gli obiettivi e possono notevolmente modificare il comportamento desiderato
del sistema. Perciò un approccio in cui tutte le informazioni sull’ambiente e sugli obiettivi sono presenti
fin dall’inizio e non possono subire modifiche nel corso del problema (ambiente statico), avrebbe reso il
sistema poco adatto al suo utilizzo per fini pratici.
3.6.2. SUCCESSIONE DI DCOP
L’approccio che si è scelto di utilizzare per la maggior parte degli scopi previsti in questa tesi è stato
considerare il problema come una successione di DCOP singoli come presentati nella sezione
precedente, che il sistema risolve nel corso della durata dell’orizzonte temporale, ad intervalli prefissati e
uguali tra loro, la cui durata corrisponde a quella dell’intervallo di ripianificazione, e che stabilisce il
numero stesso di DCOP che compongono il problema. I DCOP sono risolti singolarmente uno dopo
l’altro, ma le condizioni dell’ambiente, e conseguentemente gli obiettivi del problema, possono variare
tra un DCOP e il successivo (ambiente dinamico), e i risultati prodotti dalla risoluzione di un DCOP
influenzano direttamente le caratteristiche del successivo, come descritto dettagliatamente nella Sezione
5.2.1. Questa formulazione del problema non influisce sulla modalità di risoluzione dei DCOP, che
vengono comunque risolti da FRODO come una sequenza di DCOP slegati tra loro, ma agisce
41
solamente al momento della loro generazione e della specifica delle loro caratteristiche (come variabili o
vincoli).
Questa formulazione si presta inoltre ad una maggiore adattabilità del problema: modificando i
parametri temporali che definiscono il numero e le caratteristiche dei DCOP della sequenza, si possono
di volta in volta impostare dei problemi strutturati secondo le esigenze particolari di una singola istanza,
e si può cercare il giusto compromesso tra efficienza e complessità nella risoluzione del problema.
In Fig. 3.1 è illustrato il modo schematico il funzionamento del sistema che implementa questa
formulazione. Gli utenti inviano gli obiettivi desiderati come input al sistema, che riceve inoltre i dati
delle condizioni ambientali dai sensori nell’edificio. Il sistema elabora quindi i dati e formula un DCOP
che viene risolte le soluzioni sono inviate agli attuatori dell’edificio sotto forma di comandi che indicano
la configurazione dei dispositivi che gestiscono il comfort. Le azioni compiute dal sistema modificano
le condizioni ambientali dell’edificio, che vengono di nuovo rilevate dal sistema e danno origine ad un
nuovo DCOP, che viene risolto senza tenere conto dei dati ricavati dai problemi precedenti nella
sequenza.
42
Fig. 3.1: Schema che illustra il funzionamento del sistema formulato come successione di
DCOP
43
3.6.3. DDCOP: DYNAMIC DISTRIBUTED CONSTRAINT OPTIMIZATION
PROBLEM
Questa formulazione alternativa prevede di considerare il problema complessivo come un Dynamic
Distributed Constraint Optimization Problem (DDCOP) [38]. Un problema DDCOP è definito da una
sequenza di problemi DCOP statici, in cui ogni problema può essere diverso dal precedente e dal
successivo. Risolvere un problema DDCOP significa trovare le soluzioni che minimizzano(o
massimizzano) i costi per tutti i DCOP nella sequenza. La complessità di un problema DDCOP non è
maggiore di quella dei singoli DCOP che lo compongono.
Il vantaggio nell’utilizzo di un approccio DDCOP, piuttosto che nella risoluzione di singoli DCOP
indipendenti, viene dal fatto che, risolvendo un DCOP nella sequenza, probabilmente la maggior parte
del problema non avrà subito variazioni rispetto al DCOP precedente, perciò si possono riutilizzare le
soluzioni trovate precedentemente senza ricalcolarle. Per ottenere ciò, alcuni algoritmi di risoluzione dei
DCOP possono essere modificati tenendo conto di questi fattori. Per esempio, agli algoritmi ADOPT
(Sezione 4.1) e BnB-ADOPT può essere applicato l’utilizzo della procedura Reuse-Bounds: con questa
procedura, quando si risolve un DCOP della sequenza, vengono identificati gli affected agents, cioè i nodi
dello pseudo-albero del problema che sono influenzati da un cambiamento del problema avvenuto tra il
precedente e il corrente DCOP; e sono memorizzati gli upper bound e i lower bound degli agenti non
influenzati, che potranno essere riutilizzati nel prossimo problema, mentre per tutti i nodi degli agenti
influenzati verranno riutilizzati gli algoritmi ADOPT o BnB-ADOPT per ricercare nuove soluzioni
ottime.
La rappresentazione del problema come DDCOP influenza principalmente la modalità in cui gli
algoritmi di risoluzione processano i singoli DCOP. L’impostazione e le caratteristiche generali del
problema rimangono pressoché invariate rispetto alla formulazione come successione semplice di
DCOP. L’utilizzo di una procedura come Reuse-Bounds ha lo scopo di migliorare le prestazioni
dell’algoritmo che la utilizza, e stabilisce una correlazione diretta tra i DCOP che costituiscono il
problema complessivo, che può essere così considerato un unico problema dinamico (DDCOP) e non
più una semplice successione di DCOP slegati tra loro. Una descrizione più dettagliata della procedura
Reuse-Bounds e di come questa è stata implementata in questo lavoro è data nel capitolo successivo.
In Fig. 3.2 è illustrato il funzionamento del sistema che implementa la formulazione del problema
come DDCOP. Per elaborare e risolvere un DCOP, il sistema, oltre a ricevere in input gli obiettivi degli
utenti e le condizioni ambientali dell’edificio, elabora i dati memorizzati dei DCOP risolti
precedentemente nella sequenza e genera un DCOP la cui complessità può essere ridotta rispetto a
quella della formulazione precedente, a seconda dell’utilità che si ottiene da queste informazioni.
44
Fig. 3.2: Schema che illustra il funzionamento del sistema formulato come un DDCOP
45
CAPITOLO 4
ESTENSIONE DEL FRAMEWORK FRODO
Nel precedente capitolo è stato impostato il problema applicativo affrontato, e sono state descritte varie
tipologie di formulazioni DCOP per la sua risoluzione. Per implementare e risolvere i DCOP veri e
propri, è stata utilizzata una modellazione che fosse coerente con lo standard di FRODO, il framework
utilizzato in questo lavoro per risolvere i problemi.
4.1. FRODO
FRODO (FRamework for Open/Distributed constraint Optimization) [36] è un framework Java opensource per la soluzione di problemi di ottimizzazione vincolata distribuita (DCOP), sviluppato
inizialmente all’Artificial Intelligence Laboratory (LIA) dell’Ecole Polytechnique Fédérale de Lausanne
(EPFL), in Svizzera. La versione utilizzata in questa tesi è FRODO 2.11, una versione riprogettata da
zero rispetto a quella originale.
Utilizzando FRODO si può simulare in una singola macchina virtuale Java un ambiente multiagente, in
cui ogni agente è eseguito in maniera asincrona in un thread dedicato, e comunica con gli altri
attraverso scambi di messaggi. A partire dall’ultima versione di FRODO è anche possibile creare un
ambiente realmente distribuito, in cui ogni agente può essere ospitato su una diversa macchina e può
comunicare con gli altri attraverso la rete tramite protocollo TCP. L’interfaccia di FRODO è adattabile
a varie tipologie di problemi, e permette un’elevata personalizzazione; le librerie interne dispongono
inoltre di un gran numero di algoritmi di ottimizzazione distribuita.
FRODO richiede in input due tipi di file: i file che definiscono il problema di ottimizzazione da
risolvere e i file di configurazione che definiscono l’algoritmo da utilizzare. Il formato del file utilizzato
per descrivere i DCOP è basato su XCSP 2.1 [31], rappresenta reti di vincoli tramite XML e comprende
alcune estensioni necessarie a renderlo adatto ai problemi di ottimizzazione distribuita, poiché XCSP è
stato progettato per rappresentare problemi di soddisfacimento di vincoli centralizzati. Il formato
XCSP risultante è un soprainsieme dello standard XDisCSP 1.0 utilizzato dalla piattaforma
DisCHOCO 2 [32]; questo rende possibile utilizzare tale piattaforma come generatore di problemi
benchmark per FRODO. A seconda del parser utilizzato per la lettura del problema in input, FRODO
supporta rispettivamente o un sottoinsieme, o un sottoinsieme ristretto di XCSP 2.1.
La Fig. 4.1 mostra un esempio di file XCSP per FRODO, utilizzando il sottoinsieme ristretto
supportato dal parser XCSPparser. Il file consta di cinque sezioni principali.
La sezione <agents> definisce gli agenti del DCOP.
La sezione <domains> definisce i domini dei valori delle variabili del DCOP.
La sezione <variables> definisce le variabili del DCOP, con i corrispondenti domini e agenti cui
appartengono. Ogni agente può possedere più di una variabile.
46
La sezione <relations> definisce generiche relazioni sulle variabili. Una relazione ha una
corrispondenza logica con i vincoli analoga alla corrispondenza che intercorre tra i domini e le
variabili: essa descrive una nozione generica su un certo numero di variabili, senza specificarne il
nome; questa nozione può essere poi implementata come un vincolo, specificando le variabili
coinvolte. Il parser XCSPparser supporta solo relazioni di tipo soft (espresso nell’attributo
semantics), che elencano tutti i possibili valori di utilità (o costo, a seconda che l’attributo
maximize del tag presentation sia true o false), e per ogni utilità, gli assegnamenti delle variabili
che la producono. Tuttavia l’utilizzo del valore speciale infinity rende possibile esprimere in
questo modo anche vincoli di tipo hard. Nell’esempio in Fig. 4.1, la relazione NEQ attribuisce
un costo infinito agli assegnamenti nei quali le variabili assumono lo stesso valore, e un costo
nullo a tutti gli altri assegnamenti.
La sezione <constraints> elenca i vincoli veri e propri del DCOP, riferendosi alle relazioni
precedentemente definite, e applicandole a variabili specifiche elencate nell’attributo scope.
<instance>
<presentation name="sampleProblem" maxConstraintArity="2"
maximize="false" format="XCSP 2.1_FRODO" />
<agents nbAgents="3">
<agent name="agentX" />
<agent name="agentY" />
<agent name="agentZ" />
</agents>
<domains nbDomains="1">
<domain name="three_colors" nbValues="3">1..3</domain>
</domains>
<variables nbVariables="3">
<variable name="X" domain="three_colors" agent="agentX" />
<variable name="Y" domain="three_colors" agent="agentY" />
<variable name="Z" domain="three_colors" agent="agentZ" />
</variables>
<relations nbRelations="1">
<relation name="NEQ" arity="2" nbTuples="3" semantics="soft" defaultCost="0">
infinity: 1 1|2 2|3 3
</relation>
</relations>
<constraints nbConstraints="3">
<constraint name="X_and_Y_have_different_colors" arity="2" scope="X Y" reference="NEQ" />
<constraint name="X_and_Z_have_different_colors" arity="2" scope="X Z" reference="NEQ" />
<constraint name="Y_and_Z_have_different_colors" arity="2" scope="Y Z" reference="NEQ" />
</constraints>
</instance>
Fig. 4.1: Un esempio di file di configurazione XCSP (sottoinsieme ristretto di XCSP) [36]
47
Il parser JaCoPxcspParser rende possibile esprimere i vincoli con una sintassi più ricca, includendo
vincoli intensionali basati su predicati, funzioni, oltre che vincoli globali. In Fig. 4.2 è mostrato lo stesso
esempio illustrato in Fig. 4.1, ma con l’utilizzo del sottoinsieme esteso di XCSP. Ci sono due differenze
rispetto alla precedente rappresentazione.
La sezione <predicates> è l’equivalente hard intensionale delle relazioni soft estensionali. Ogni
predicato dichiara una lista di parametri, preceduti dal loro tipo (per il momento è supportato
unicamente il tipo intero). L’espressione funzionale è un’espressione logica dei parametri che
definisce il vincolo. Sono supportate le seguenti operazioni, combinabili ricorsivamente per
comporre espressioni complesse: valore assoluto, valore opposto, somma, sottrazione,
moltiplicazione, divisione intera, modulo, potenza, valore minimo, valore massimo, uguaglianza,
non uguaglianza, disuguaglianza, disuguaglianza stretta, NOT logico, AND logico, OR logico,
XOR logico, equivalenza logica e costrutto if-then-else.
<instance>
<presentation name="sampleProblem" maxConstraintArity="2"
maximize="false" format="XCSP 2.1_FRODO" />
<agents nbAgents="3">
<agent name="agentX" />
<agent name="agentY" />
<agent name="agentZ" />
</agents>
<domains nbDomains="1">
<domain name="three_colors" nbValues="3">1..3</domain>
</domains>
<variables nbVariables="3">
<variable name="X" domain="three_colors" agent="agentX" />
<variable name="Y" domain="three_colors" agent="agentY" />
<variable name="Z" domain="three_colors" agent="agentZ" />
</variables>
<predicates nbPredicates="1">
<predicate name="NEQ">
<parameters> int X1 int X2 </parameters>
<expression>
<functional> ne(X1, X2) </functional>
</expression>
</predicate>
</predicates>
<constraints nbConstraints="3">
<constraint name="X_and_Y_have_different_colors" arity="2" scope="X Y" reference="NEQ" >
<parameters> X Y </parameters>
</constraint>
<constraint name="X_and_Z_have_different_colors" arity="2" scope="X Z" reference="NEQ" >
<parameters> X Z </parameters>
</constraint>
<constraint name="Y_and_Z_have_different_colors" arity="2" scope="Y Z" reference="NEQ" >
<parameters> Y Z </parameters>
</constraint>
</constraints>
</instance>
Fig. 4.2.: Un esempio di file di configurazione XCSP (sottoinsieme esteso di XCSP) [36]
48
Ogni elemento <constraint> deve dichiarare una lista di parametri, che possono essere variabili o
valori costanti, nell’ordine corrispondente in cui sono dichiarati nel predicato corrispondente.
Da notare infine che il parser JaCoPxcspParser supporta ancora le relazioni soft estensionali, così come
supporta le funzioni, che sono l’equivalente soft intensionale delle relazioni soft estensionali.
FRODO necessita in input anche di un file di configurazione degli agenti che definisce l’algoritmo da
utilizzare, oltre che diversi altri parametri (quando applicabili). In Fig. 4.3 è mostrato un esempio di file
di configurazione, che corrisponde all’implementazione classica dell’algoritmo DPOP.
Le prestazioni possono essere valutate misurando seguenti metriche.
Numero e dimensione dei messaggi inviati: il numero totale dei messaggi inviati ordinati per tipo, così
come lo spazio di memoria richiesto dal messaggio più grande, e la somma totale dello spazio
richiesto dalla tutti i messaggi inviati. L’utilizzo di questa metrica è però computazionalmente
molto oneroso, poiché misurare la dimensione dei messaggi richiede serializzazione.
Non-Cuncurrent Constraint Checks (NCCCs) [33]: ogni agente possiede un contatore dei controlli
effettuati localmente sui vincoli. Ogni messaggio inviato agli altri agenti contiene questo valore.
Quando un agente riceve un messaggio, aggiorna il proprio contatore utilizzando il valore
maggiore fra quello indicato dal proprio contatore e quello indicato nel messaggio ricevuto. Il
valore più grande ottenuto alla terminazione dell’algoritmo è utilizzato per ottenere una misura
del lavoro di ricerca concorrente. Tale misura può essere poi utilizzata per contare il numero di
NCCC (questo avviene diversamente per ogni algoritmo, in quanto dipende dalle particolari
operazioni che svolgono gli agenti), e incorpora lo sforzo computazionale locale di ogni agente.
Questa metrica non è supportata dal parser JaCoPxcspParser, ma solo dal parser XCSPparser.
Tempo simulato [34]: quando un agente invia un messaggio, aggiunge a esso un timestamp che
indica il momento in cui il messaggio è stato inviato secondo il proprio orario, rilevato dal
proprio orologio interno. Quando riceve un messaggio, se il timestamp associato riporta un
orario maggiore rispetto all’ora indicata dal proprio orologio interno, l’agente aggiorna il proprio
orario in modo che corrisponda al timestamp del messaggio appena ricevuto. Quando
l’algoritmo termina, il tempo di esecuzione è determinato dall’orario maggiore scelto fra quelli
indicati dagli orologi interni di tutti gli agenti.
Altre statistiche: diversi moduli di algoritmi possono riportare altre informazioni sul problema. Ad
esempio, nel caso di DPOP, il modulo di generazione DFS può riportare in formato DOT [35]
l’albero DFS costruito e utilizzato dall’algoritmo, mentre il modulo di propagazione dei
messaggi VALUE può riportare l’assegnamento ottimo delle variabili del DCOP e la
corrispondente utilità (o costo) totale.
49
<agentDescription className = "frodo2.algorithms.SingleQueueAgent"
measureTime = "true" measureMsgs = "false" >
<parser parserClass = "frodo2.algorithms.XCSPparser"
displayGraph = "false"
utilClass = "frodo2.solutionSpaces.AddableInteger"
countNCCCs = "false" />
<modules>
<module className = "frodo2.algorithms.varOrdering.dfs.DFSgenerationParallel"
reportStats = "true" >
<rootElectionHeuristic
className = "frodo2.algorithms.heuristics.ScoringHeuristicWithTiebreaker" >
<heuristic1
className = "frodo2.algorithms.heuristics.MostConnectedHeuristic" />
<heuristic2
className = "frodo2.algorithms.heuristics.ScoringHeuristicWithTiebreaker" >
<heuristic1
className = "frodo2.algorithms.heuristics.SmallestDomainHeuristic" />
<heuristic2
className = "frodo2.algorithms.heuristics.VarNameHeuristic" />
</heuristic2>
</rootElectionHeuristic>
<dfsGeneration className = "frodo2.algorithms.varOrdering.dfs.DFSgeneration" >
<dfsHeuristic className =
"frodo2.algorithms.varOrdering.dfs.DFSgeneration$ScoreBroadcastingHeuristic">
<scoringHeuristic
className = "frodo2.algorithms.heuristics.ScoringHeuristicWithTiebreaker" >
<heuristic1
className = "frodo2.algorithms.heuristics.MostConnectedHeuristic" />
<heuristic2
className = "frodo2.algorithms.heuristics.SmallestDomainHeuristic" />
</scoringHeuristic>
</dfsHeuristic>
</dfsGeneration>
</module>
<module className = "frodo2.algorithms.dpop.UTILpropagation"
reportStats = "true" />
<module className = "frodo2.algorithms.dpop.VALUEpropagation"
reportStats = "true" />
</modules>
</agentDescription>
Fig. 4.3: Un esempio di file di configurazione di FRODO corrispondente all’algoritmo DPOP
[36]
50
4.1.1.
.1. ARCHITETTURA DI FRODO
La struttura di FRODO è basata su un’architettura multistrato modulare (Fig.
Fig. 4.4
4.4). In particolare,
questa architettura si compone di tre strati: lo strato di comunicazione, lo strato degli spazi delle
soluzioni e lo strato degli algoritmi.
Lo strato di comunicazione,, responsabile dello scambio di informazioni fra gli agenti, è implementato
come una coda di messaggi Java. Tipicamente ogni agente possiede una coda, che utilizza per ricevere e
inviare messaggi. Ogni coda possiede il proprio processo di esecuzione, perciò particolare attenzione è
stata posta nell’evitare che i processi potessero bloccarsi per lungo tempo in attesa di messaggi, in mod
modo
da limitare le implicazioni sulla performance
performanc dovute all’avere un solo thread per agente, nel caso di
problemi dove un grande numero di agenti risiede sulla stessa JVM.
Lo strato degli spazi delle soluzioni fornisce le classi per modellare i problemi di ottimizzazione
combinatoria. Dato uno spazio di possibili assegnamenti ad alcune variabili, uno spazio delle soluzioni è
una rappresentazione di assegnamenti tali che questi corrispondano a delle soluzioni del dato problema.
Nel contesto di problemi di ottimizzazione, gli spazi delle soluzioni sono associati
ssociati alle utilità (o costi), in
modo da poter valutare la qualità di ogni soluzione. Tra le diverse implementazioni degli spazi delle
soluzioni in FRODO, la più semplice è quella ad
a ipercubo,, ossia una rappresentazione estensionale di
uno spazio in cui a ogni combinazione di assegnamenti delle variabili è associata un’utilità (o costo). Gli
assegnamenti non ammissibili possono essere rappresentati tramite uno speciale costo infinito. Gli
spazi delle soluzioni possono essere espressi anche in maniera intensionale,
intensionale, basandosi sui vincoli JaCoP.
Lo strato degli algoritmi,, infine, si occupa dell’implementazione vera e propria degli algoritmi distribuiti
utilizzati per risolvere i DCOP. Ogni algoritmo è implementato come uno o più moduli, i quali sono a
tutti gli effetti delle politiche algoritmiche che descrivono come gli agenti devono comportarsi alla
ricezione dei vari messaggi, e quali messaggi devono inviare agli altri agenti o agli altri
Fig.4.4 : Architettura generale di FRODO [36]
51
moduli. Questa struttura modulare rende possibile un alto grado di personalizzazione degli algoritmi,
oltre che il riutilizzo e la manutenzione del codice. Fra gli algoritmi supportati da FRODO, in questo
lavoro sono stati utilizzati: ADOPT, DPOP, SynchBB, MGM e MGM-2. Inoltre, nella Sezione 4.3 si
descrive la modifica all’algoritmo ADOPT che ha reso possibile la risoluzione della formulazione
DDCOP del problema di gestione del comfort termoigrometrico in FRODO.
4.2. ADOPT
ADOPT (Asynchronous Distributed OPTimization) [37] è un algoritmo che termina sempre producendo un
risultato, e in grado di trovare una soluzione ottimale a un problema DCOP, o almeno una soluzione a
una distanza massima dall’ottimo definita dall’utente, utilizzando comunicazioni locali asincrone e con
complessità spaziale polinomiale per ogni agente. Invece di agire sul grafo dei conflitti (un grafo
costruito facendo corrispondere uno specifico nodo a ogni variabile, e tracciando un arco tra due nodi
se esiste almeno un conflitto fra gli assegnamenti delle variabili corrispondenti), ADOPT costruisce un
albero di ricerca in profondità (Depth First Search) che definisce un ordinamento tra gli agenti attraverso i
rapporti di parentela tra i nodi dell’albero (che rappresentano appunto gli agenti). La comunicazione è
locale giacché un agente non scambia messaggi con tutti gli altri, ma solo con il nodo padre e i nodi
figlio nell’albero DFS.
L’idea principale dietro ADOPT è di agire in modo asincrono permettendo a ogni agente di cambiare il
valore assegnato alla propria variabile quando scorge la possibilità di trovare una soluzione migliore
rispetto a quella attuale. Questa strategia di ricerca permette asincronismo perché un agente non
necessita una conoscenza globale del problema per prendere una decisione riguardo al suo problema
locale. Dato che questa strategia permette di abbandonare soluzioni prima che sia provata la loro
ottimalità locale, è possibile che alcune di esse siano riutilizzate. La seconda idea chiave in ADOPT è
quindi quella di ricostruire in maniera efficiente soluzioni considerate precedentemente (con
complessità spaziale polinomiale) attraverso l’uso di una soglia di backtrack, cioè una tolleranza sul costo
della soluzione che previene l’utilizzo di backtracking indiscriminato. La terza caratteristica principale di
ADOPT consiste nel fornire un meccanismo di individuazione della terminazione all’interno
dell’algoritmo stesso: gli agenti terminano infatti quando trovano una soluzione completa il cui costo è
al di sotto della loro soglia di backtrack.
Lo svantaggio principale di ADOPT è la sua complessità in termini di messaggi scambiati, che cresce
esponenzialmente rispetto al numero degli agenti (mentre lo spazio utilizzato dai messaggi e la memoria
richiesta per ogni agente cresce linearmente). Per questa ragione l’algoritmo degrada significativamente
in prestazioni al crescere del numero degli agenti.
52
4.2.1. FUNZIONAMENTO DI ADOPT
I messaggi scambiati fra gli agenti sono:
messaggi VALUE: inviati da un nodo verso i propri figli, percorrendo quindi l’albero DFS
dall’alto verso il basso. Contengono il valore assegnato dall’agente alla propria variabile
messaggi COST: inviati da un nodo verso il proprio padre, percorrendo quindi l’albero DFS dal
basso verso l’alto. Contengono il valore che rappresenta il costo della scelta effettuata dal nodo
genitore sommato ai costi delle scelte effettuate da tutti i nodi figli. Servono inoltre per calcolare
i limiti inferiori e superiori utilizzati dagli agenti per guidare il backtracking
messaggi THRESHOLD: inviati da un nodo verso i propri figli, percorrendo quindi l’albero DFS
dall’alto verso il basso. Servono per ridurre ridondanze nella ricerca notificando la soglia di
backtrack.
Ogni agente mantiene traccia degli assegnamenti dei vicini con priorità maggiore attraverso un
contesto, ovvero una soluzione parziale contenente gli assegnamenti noti. Tale contesto viene
aggiornato dall’agente ogni qualvolta viene ricevuto un messaggio VALUE dal nodo padre oppure
quando l’agente decide di cambiare il valore della propria variabile in seguito alla ricezione di un
messaggio COST da un nodo figlio. L’algoritmo giunge al termine quando i limiti inferiore e
superiore dell’agente al nodo radice sono uguali, il che significa che è stata trovata la soluzione
ottima.
4.3. ESTENSIONE DI ADOPT PER PROBLEMI DDCOP
In [38] è descritta in forma teorica una possibile modifica all’algoritmo ADOPT, che ha lo scopo di
implementare le caratteristiche di un DDCOP partendo dalla base di una sequenza di DCOP singoli.
Uno degli scopi di questo lavoro è stato analizzare e implementare in un software scritto in Java tale
procedura, in modo da avere a disposizione uno strumento pratico per la risoluzione di DDCOP,
sebbene compatibile con il solo algoritmo ADOPT. L’implementazione di questa procedura, o di una
simile, si rende necessaria per la soluzione di un DDCOP all’interno di FRODO, perché altrimenti non
si avrebbe a disposizione uno strumento o un processo che tenga conto delle informazioni condivise tra
un DCOP e il successivo nella sequenza. In altre parole, per poter risolvere una sequenza di DCOP
come un unico problema considerato un “DCOP dinamico” non sono sufficienti i normali algoritmi di
risoluzione dei DCOP presenti in FRODO, ma abbiamo bisogno di un software aggiuntivo che gestisca
le informazioni condivise tra i problemi della sequenza, e ottimizzi lo svolgimento del problema
utilizzando al meglio queste informazioni. Nel seguito è descritta in dettaglio la procedura ReuseBounds, oltre al funzionamento del relativo software progettato e implementato in questo lavoro.
53
4.3.1. REUSE-BOUNDS
La procedura Reuse-Bounds interagisce con l’esecuzione dell’algoritmo ADOPT, e riduce la
complessità della risoluzione di un DCOP ricavando alcune informazioni dall’iterazione precedente
dell’algoritmo e utilizzandole nel problema successivo.
In particolare, al momento della costruzione dello pseudo-albero di un DCOP, utilizzando ReuseBounds si identificano i nodi dell’albero corrispondenti agli agenti che non sono stati influenzati dal
cambiamento di contesto del DCOP (affected agents), e si fissano i lower bound e gli upper bound
relativi alle variabili di quegli agenti, in modo che vengano mantenute dall’iterazione precedente e non
siano modificate in quella successiva. Dopodiché sono inizializzati tutti bound relativi agli agenti non
influenzati, e il DCOP risultante viene risolto secondo il normale funzionamento di ADOPT, tenendo
conto delle modifiche precedentemente esposte. La scelta degli agenti influenzati avviene secondo i
seguenti criteri:
Un agente condivide un vincolo, un nuovo vincolo o un vincolo cancellato con un altro agente,
e il costo di questo vincolo è cambiato.
L’insieme dei figli dell’agente è cambiato rispetto allo pseudo-albero precedente.
Un discendente dell’agente è un agente influenzato.
Gli agenti influenzati non possono riutilizzare i loro lower bound e upper bound, poiché il loro costo
ottimo può essere diverso dal DCOP precedente, perciò i bound sul costo ottimo possono non essere
più validi.
4.3.2. IMPLEMENTAZIONE DELLE MODIFICHE
Di seguito viene brevemente descritto il funzionamento del software, sviluppato in Java, che
implementa la procedura Reuse-Bounds all’interno dell’algoritmo ADOPT. Queste modifiche sono
state apportate al codice sorgente del framework FRODO, relativamente ai file riguardanti l’algoritmo
ADOPT e ad alcuni file generali di configurazione. Questa versione modificata di FRODO interagisce
con il generatore di DCOP descritto nella Sezione 5.2.
1. Il generatore di DCOP crea una successione di DCOP, in numero maggiore di 1, e li invia
all’interfaccia di FRODO comunicando la scelta della versione modificata di ADOPT come
algoritmo di risoluzione.
2. Il primo DCOP della serie viene processato e risolto normalmente da ADOPT.
3. Il sistema memorizza la struttura dello pseudo-albero e i valori memorizzati di lower bound e
upper bound di tutti gli agenti della prima iterazione dell’algoritmo.
4. E’ avviata l’iterazione di ADOPT che deve risolvere il problema successivo della sequenza.
5. Nella costruzione dello pseudo-albero, ADOPT lo analizza e lo confronta con lo pseudo-albero
precedentemente memorizzato; quindi stabilisce quali sono gli agenti influenzati secondo i
criteri della procedura Reuse-Bound, e li segnala a FRODO con appositi flag.
54
6. Al momento dell’inizializzazione dei lower bound e upper bound degli agenti, quelli segnalati
come non influenzati sono inizializzati con i valori precedentemente memorizzati.
7. Per gli agenti non influenzati vengono ignorate le parti dell’algoritmo che hanno la funzione di
stabilire i bound del costo ottimo.
8. L’iterazione di ADOPT termina, e se è presente un altro DCOP nella sequenza si riparte dal
punto 4.
4.4. ALTRI ALGORITMI DI RISOLUZIONE
In questa sezione si descrivono brevemente gli altri algoritmi di risoluzione di DCOP utilizzati in questa
tesi, che si dividono tra algoritmi ottimi, che trovano la soluzione ottima se ne esiste una, e incompleti,
che non garantiscono di trovare la soluzione ottima ma richiedono generalmente meno complessità di
calcolo.
4.4.1. DPOP
DPOP (Dynamic Programming Optimization Protocol) [39] è un algoritmo ottimo basato sulla
programmazione dinamica. Si avvale di un metodo a propagazione di utilità, ispirato dagli algoritmi
Sum-Product [40] e DTREE [41], i quali però sono corretti solo per reti di vincoli a forma d’albero,
mentre DPOP ne estende l’utilizzo a topologie arbitrarie adoperando un arrangiamento a pseudoalbero possibile a partire da un qualsiasi grafo dei vincoli del problema.
L’algoritmo si divide in tre fasi: la costruzione dello pseudo-albero, la propagazione delle utilità e la
propagazione dei valori. Durante la fase di propagazione delle utilità, gli agenti inviano, partendo dalle
foglie dello pseudo-albero, messaggi UTIL ai propri genitori. Tali messaggi rappresentano un vettore
delle utilità che possono essere ottenute dai sottoalberi con radice nei corrispondenti agenti,
compatibilmente con ogni valore assegnabile dal nodo genitore. Le utilità vengono propagate risalendo
l’albero, fino a quando il nodo radice riceve tutti i messaggi UTIL in arrivo dai propri figli. A questo
punto, in accordo con le informazioni ricevute, il nodo radice assegna alla propria variabile il valore che
massimizza l’utilità del proprio sotto-albero. La sua scelta è poi notificata attraverso l’invio di un
messaggio VALUE ai propri figli, i quali a loro volta, ricevuto il messaggio VALUE dai propri genitori,
scelgono il valore ottimo per la propria variabile e propagano ai figli la propria scelta, fino a raggiungere
le foglie dell’albero. Il punto di forza di DPOP riguarda la complessità in termini di numero di messaggi
scambiati, che cresce linearmente rispetto all’altezza dello pseudo-albero, generando quindi un basso
overhead di comunicazione. Tuttavia le performance possono essere influenzate dalla dimensione dei
messaggi UTIL, che cresce esponenzialmente rispetto alla larghezza dello pseudo-albero.
55
4.4.2. MGM
MGM (Maximum Gain Messages) [42] è un algoritmo che non garantisce di trovare la soluzione ottima, se
esiste. Nasce da una modifica di un altro algoritmo, Distributed Breakout Algorithm (DBA) [43], il quale
però non può essere applicato a sistemi realmente distribuiti, poiché richiede una conoscenza globale
della qualità della soluzione.
MGM prende spunto dalla teoria dei giochi, in quanto i DCOP vengono modellati come giochi in cui i
giocatori sono le variabili controllate dagli agenti, le azioni sono gli assegnamenti di valori, e le
informazioni note sono i valori noti degli agenti vicini. In questo modo, una soluzione corrisponde a un
equilibrio di Nash del problema rappresentato.
L’esecuzione dell’algoritmo è suddivisa in round: a ogni round gli agenti calcolano la propria utilità
locale, cioè il massimo valore di utilità ottenibile cambiando l’assegnamento attuale del proprio contesto
(l’insieme delle variabili appartenenti agli agenti vicini di cui un agente conosce l’assegnamento). Poi, gli
agenti inviano un messaggio a tutti i vicini, indicando se l’assegnamento sortirà un guadagno o no. Un
assegnamento è eseguito solo dall’agente che ne trarrà il maggior guadagno. L’algoritmo termina se non
esiste nessun ulteriore assegnamento che può generare un guadagno. Un aspetto molto importante di
MGM riguarda la monotonicità dell’utilità globale rispetto al numero di round: in qualunque momento
l’algoritmo sia interrotto, la soluzione trovata sino a quel momento sicuramente non è peggiore di una
soluzione trovata in un round precedente.
4.4.3. MGM-2
Come MGM, anche MGM-2 [42] è un algoritmo non ottimo basato sulla teoria dei giochi. Mentre in
MGM gli agenti puntano a massimizzare soltanto la propria utilità, unilateralmente, in MGM-2 ogni
agente è coordinato con un altro. A ogni round, gli agenti vengono divisi casualmente tra offerenti e
riceventi; ogni offerente poi, sceglie casualmente un vicino a cui mandare un’offerta, la quale contiene i
valori consigliati per l’offerente e il ricevente che porterebbero ad un aumento dell’utilità dell’offerente.
Se il messaggio è inviato a un agente ricevente, questo calcola il guadagno in utilità globale per ogni
coppia di valori nell’offerta (se invece l’offerta è ricevuta da un altro offerente, sarà semplicemente
scartata). Se il guadagno globale massimo è positivo, il ricevente accetta l’offerta inviando un messaggio
ACCEPT, ed entrambi assegnano alle proprie variabili i nuovi valori; in caso contrario il ricevente
rifiuta con un messaggio REJECT. Anche MGM-2 rispetta l’importante caratteristica di monotonicità
dell’utilità globale. Rispetto a MGM, il costo in messaggi scambiati con quest’algoritmo è molto
maggiore, ma in generale MGM-2 trova soluzioni qualitativamente migliori.
56
4.4.4. SynchBB
SynchBB (Synchronous Branch and Bound) [44] è un algoritmo ottimo pensato inizialmente per
risolvere problemi di soddisfacimento di vincoli distribuiti (DCSP) caratterizzati da un elevato numero
di vincoli, adottando un approccio per problemi di soddisfacimento parziale di vincoli distribuiti
(DPCSP). Un DPCSP è formulato partendo da un DCSP per il quale non esistono soluzioni
ammissibili. Introducendo una relazione di priorità fra i vincoli, nel caso non sia possibile trovare una
soluzione ammissibile per il problema di partenza, si possono rilassare i vincoli di priorità minore, fino
a trovare una soluzione che soddisfi i vincoli di priorità maggiore.
SynchBB simula il noto approccio Branch and Bound in ambiente distribuito. Gli agenti, che comunicano
attraverso uno schema che riflette il grafo dei conflitti, costruiscono in maniera incrementale un
percorso, cioè un assegnamento di valori per le variabili del problema. A ogni iterazione il percorso (che
contiene anche il numero di vincoli violati) viene valutato ed eventualmente esteso o modificato
attraverso ulteriori assegnamenti. Un percorso di lunghezza n (con n uguale al numero degli agenti)
corrisponde alla soluzione del problema. Dato che SynchBB simula l’approccio Branch and Bound in
ambiente distribuito, appare evidente che si tratti di un algoritmo corretto. Inoltre il controllo
sequenziale degli agenti e l’ordinamento delle variabili permettono di esplorare l’intero spazio delle
soluzioni, garantendo così che l’algoritmo sia completo e ottimo.
Il maggior limite di SynchBB risiede nello schema di comunicazione: è necessario, infatti, che i messaggi
siano ricevuti nello stesso ordine nel quale sono stati inviati, così come anche le fasi computazionali
devono essere eseguite sequenzialmente, perciò l’algoritmo non può trarre vantaggio da alcun tipo di
parallelismo. In [45] questo approccio è stato esteso rendendo SynchBB adatto a risolvere i DCOP.
57
CAPITOLO 5
REALIZZAZIONI SPERIMENTALI E VALUTAZIONI
In questo capitolo sono mostrati i risultati di varie tipologie di test sperimentali che hanno lo scopo di
mostrare il corretto funzionamento del sistema implementato, e di valutare alcune caratteristiche e
prestazioni ottenute risolvendo varie categorie di problemi sotto diverse condizioni di funzionamento.
Nella Sezione 5.1 sono mostrate le caratteristiche dei due edifici su cui sono stati implementati i modelli
dell’ambiente su cui agisce il sistema. Nella Sezione 5.2 viene descritto il funzionamento del software
che genera i DCOP veri e propri a partire dalle istruzioni dell’utente, in modo che siano poi elaborati da
FRODO e dagli algoritmi di risoluzione.
La prima categoria di test, descritto nella Sezione 5.3, valuta il funzionamento del sistema: i test di
questa sezione controllano la correttezza del comportamento del sistema, sottoponendogli problemi
con obiettivi, anche non corrispondenti a situazioni realistiche, diversi di volta in volta, oltre a valutare
alcune caratteristiche generali del sistema, come il peso delle componenti della funzione di costo del
DCOP, o il diverso comportamento del sistema in termini di efficienza e complessità al variare dei
parametri temporali.
La categoria successiva, descritta nelle Sezioni 5.4 e 5.5, sottopone il sistema a due test realistici, ognuno
relativo a uno dei due edifici presi in esame, in cui tutti i parametri ambientali del sistema sono generati
casualmente, e i problemi devono raggiungere degli obiettivi verosimili pensati sulla base di condizioni
ambientali desiderabili nel corso di una giornata.
L’ultima categoria di test, descritta nella Sezione 5.6, si occupa di valutare alcune caratteristiche tecniche
riguardanti il funzionamento interno del sistema, come l’incremento della velocità del sistema quando si
utilizza la versione dell’algoritmo ADOPT in cui è implementata la procedura Reuse-Bounds, descritta
in questa tesi.
58
5.1. STRUTTURA DEGLI EDIFICI
Edificio A
Il primo edificio utilizzato per i test è un piccolo appartamento di un solo piano (Fig. 5.1), composto da
5 stanze, ognuna di esse corrispondente a una zona del modello utilizzato dal sistema: il soggiorno
(zona 1), il bagno (zona 2), due camere da letto (zone 3 e 5) e la cucina (zona 4). Ogni stanza è dotata di
una singola finestra, e il soggiorno è collegato da una porta a tutte le altre stanze, in nessuna delle quali
sono presenti altre porte. Lo schema dei collegamenti tra le stanze si può cioè definire “a stella” in cui il
soggiorno rappresenta il centro e tutte le altre stanze sono collegate esclusivamente ad esso. Il
soggiorno presenta anche un’ulteriore porta, l’ingresso dell’appartamento, che non è stata considerata ai
fini del problema. In Appendice A.1 è mostrato un esempio di DCOP relativo al modello dell’edificio
A.
Fig. 5.1: Piantina dell’edificio A
59
Edificio B
Il secondo edificio ha una struttura più insolita dell’appartamento sopra descritto: si tratta di una
sezione di un museo (Fig. 5.2), composto da 5 stanze, ognuna delle quali corrispondente a una zona del
problema, collegate tra loro “in serie”. Ogni galleria, tranne ovviamente la prima e l’ultima, è collegata
da porte unicamente alla galleria precedente e a quella successiva. Inoltre in ogni galleria è presente
esattamente una finestra. Anche qui la porta di ingresso alla prima zona, presente per motivi di
realismo, non viene considerata ai fini del problema. In Appendice A.2 è mostrato un esempio di
DCOP relativo al modello dell’edificio B.
Fig. 5.2: Piantina dell’edificio B
60
Queste due tipologie di edifici sono state scelte, oltre che per la loro relativa semplicità che le ha rese
adatte ad una valutazione generale del sistema, perché le architetture di molti edifici reali possono essere
viste come una combinazione dei due. Infatti la disposizione delle stanze “a stella” del primo edificio e
quella “in serie” del secondo sono tra quelle più comuni per quanto riguarda la maggior parte degli
edifici, e una valutazione del comportamento del sistema su tali architetture fornisce le basi per poterla
estendere a una grande parte di casi reali.
61
5.2. GENERATORE DI PROBLEMI
Il generatore di problemi DCOP è un software scritto in Java, che si occupa di generare i file XML che
descrivono i DCOP da risolvere, a partire da una serie di dati in parte inseriti dall’utente e in parte
generati casualmente. Inoltre invia i file direttamente a FRODO, riceve le soluzioni e i risultati ottenuti
dopo che i DCOP sono stati processati e risolti, e mostra in output all’utente le soluzioni trovate,
insieme con alcuni dati come i costi delle soluzioni e il tempo impiegato per risolvere i problemi.
Il generatore comprende al suo interno un simulatore ambientale che gestisce i dati che definiscono le
condizioni ambientali dell’edificio. Come illustrato in Fig. 5.3, il generatore riceve informazioni sia dai
dati inseriti dagli utenti che dal simulatore ambientale, e sulla base di questi dati crea uno o più file XML
e li invia a FRODO. Quando FRODO termina l’esecuzione di un DCOP, oltre a presentare l’output
del problema, invia i dati sul problema appena risolto al generatore DCOP, e i dati sulle condizioni
ambientali dell’intervallo di tempo successivo al simulatore ambientale.
I parametri determinabili dall’utente di cui tiene conto il generatore di DCOP (attraverso un semplice
file di testo di configurazione) sono i seguenti:
TIME_HORIZON: Indica la durata complessiva, in secondi, dell’orizzonte temporale su cui si
intende agire: nel caso il problema sia composto da un singolo DCOP è la sua durata, mentre se
si tratta di una serie di DCOP è la somma delle loro durate.
REP_INTERVAL: L’intervallo di ripianificazione, cioè la durata (in secondi) dell’intervallo tra
la risoluzione del DCOP e il successivo; da questo e dalla variabile precedente il generatore
ricava il numero dei DCOP di cui è composto il problema complessivo.
BUILDING: Variabile “flag” che indica se impostare il problema sul modello dell’edifico A o
dell’edificio B.
POWER_FACTOR: Parametro compreso tra 0 e 1 che indica il peso che la componente
riguardante la potenza riveste all’interno della funzione di costo del problema; più è alto, più il
sistema cercherà di minimizzare la potenza utilizzata, a scapito delle condizioni di comfort;
corrisponde al parametro γ descritto nella Sezione 3.5.
THERMO_FACTOR, HUM_FACTOR: Parametri compresi tra 0 e 1 che indicano il peso che
la componenti riguardanti rispettivamente il raggiungimento degli obiettivi termici e igrometrici,
rivestono all’interno della funzione di costo del problema; più sono alti, più il sistema cercherà
di raggiungere quelle condizioni di comfort a scapito della potenza utilizzata.
POWER_LIMIT: Il limite, misurato in Watt, della potenza totale utilizzabile dall’edificio. Nei
test che seguono è sempre impostato a 8000.
TARGET_T: Matrice di interi, in cui ogni riga corrisponde a una zona dell’edificio (quindi
sempre in numero di 5, nei test che seguono) e ogni colonna a uno degli intervalli di
ripianificazione in cui è suddiviso il problema. L’elemento i,j della matrice specifica la
temperatura assoluta che l’utente desidera sia raggiunta nella zona i, all’istante finale
dell’intervallo j. Ad esempio, se la riga 1 della matrice è { 15, 15, 15, 15, null, null } il sistema
dovrà cercare di raggiungere la temperatura di 15 °C alla fine del primo intervallo e di
mantenerla fino alla fine del quarto, dopodiché, durante gli ultimi due, sa che non deve
raggiungere alcun obiettivo specifico.
62
TARGET_H: Matrice di interi, in cui ogni riga corrisponde a una zona dell’edificio (quindi
sempre in numero di 5, nei test che seguono) e ogni colonna a uno degli intervalli di
ripianificazione in cui è suddiviso il problema. L’elemento i,j della matrice specifica l’umidità
relativa che l’utente desidera sia raggiunta nella zona i, all’istante finale dell’intervallo j. Ad
esempio, se la riga 1 della matrice è { 100, 100, 100, 100, null, null } il sistema dovrà cercare di
raggiungere un’umidità del 100% alla fine del primo intervallo e di mantenerla fino alla fine del
quarto, dopodiché, durante gli ultimi due, sa che non deve raggiungere alcun obiettivo specifico.
Fig. 5.3: Schema delle interazioni tra FRODO, il generatore di DCOP e il simulatore
ambientale
63
Il simulatore ambientale in considerazione molti altri parametri, che riguardano principalmente la
struttura e le caratteristiche degli edifici e dei dispositivi di gestione del comfort; questi parametri sono
stati stabiliti sulla base di esperimenti semplificati per valutare in modo empirico il comportamento di
temperatura e umidità all’interno di un edificio, e sono pensati per essere rimpiazzati dai loro
corrispettivi reali che dovranno essere impostati nel caso di una futura applicazione del progetto ad
un’istanza reale. I parametri, implementati da valori costanti all’interno del simulatore, sono
sinteticamente riassunti di seguito:
Coefficienti di potenza: Coefficienti numerici utilizzati dai vincoli e dalla funzione di costo per
calcolare la potenza utilizzata dai dispositivi dell’edificio a seconda della configurazione delle
rispettive variabili.
Coefficienti di variazione termica: Coefficienti numerici utilizzati dai vincoli e dalla funzione di costo
per calcolare la variazione di temperatura e il gradiente termico delle zone dell’edifico a seconda
della configurazione dei dispositivi di controllo termico.
Coefficienti di variazione igrometrica: Coefficienti numerici utilizzati dai vincoli e dalla funzione di
costo per calcolare la variazione di umidità relativa e il gradiente igrometrico delle zone
dell’edifico a seconda della configurazione dei dispositivi di controllo igrometrico.
Coefficienti delle zone confinanti: Coefficienti numerici utilizzati dai vincoli e dalla funzione di costo
per calcolare quanto temperatura e umidità sono influenzate dall’apertura delle porte delle zone
dell’edificio.
Coefficienti dell’ambiente esterno: Coefficienti numerici utilizzati dai vincoli e dalla funzione di costo
per calcolare quanto temperatura e umidità esterne influenzano l’ambiente interno dell’edifico,
quando vengono aperte le finestre delle zone.
Coefficienti di temperatura percepita: Coefficienti numerici utilizzati dai vincoli e della funzione di
costo per calcolare quanto, nelle varie zone dell’edificio, l’umidità dell’ambiente influenza la
temperatura percepita dall’uomo, e quindi modifica le condizioni termiche che il sistema deve
porsi come obiettivo.
Temperature e umidità iniziali: Le condizioni iniziali dell’edificio e dell’ambiente esterno, che
possono essere generate casualmente.
Gradienti di temperatura e umidità iniziali: Le condizioni iniziali dell’edificio e dell’ambiente esterno,
che possono essere generate casualmente.
Le variabili che il sistema restituisce in output sono le seguenti:
DCOP: Un singolo file XML o una serie di file XML, nel formato adatto ad essere processati
dal framework FRODO.
Costi dei DCOP risolti: Una serie di valori numerici che indicano i valori delle funzioni di costo
dei DCOP risolti da FRODO.
Tempi dei DCOP risolti: Una serie di valori numerici che indicano i tempi, in millisecondi,
impiegati da FRODO per risolvere i DCOP, e la somma totale di tali tempi.
Assegnamenti del DCOP: I valori assegnati alle variabili di ogni DCOP, una volta risolti.
Condizioni ambientali dell’edificio: Dati che descrivono le condizioni ambientali dell’edificio alla
fine di ogni intervallo di tempo corrispondente a un DCOP: quelli principali sono i valori di
temperatura assoluta, umidità relativa e gradienti di temperatura e umidità, ognuno di essi in
ogni zona dell’edificio.
64
5.2.1. MONDO DETERMINISITICO
Assumendo l’ipotesi di mondo deterministico per quando riguarda il modello dell’ambiente su cui il
sistema agisce, le modifiche apportate all’ambiente dopo la risoluzione di uno dei DCOP che
compongono il problema, non sono modificate o disturbate da fenomeni casuali; le condizioni
dell’ambiente a un dato intervallo di tempo sono cioè determinate in modo univoco dalle condizioni
ambientali durante l’intervallo precedente e dalle azioni svolte dagli agenti del sistema. Il funzionamento
del generatore di problemi, sotto l’ipotesi di mondo deterministico, è sintetizzato di seguito.
1. Sono stabiliti il numero e la durata dei DCOP che compongono il problema.
2. Sono modificati i parametri dipendenti dall’edificio scelto.
3. Sono generati (casualmente o meno) i valori di temperatura e umidità esterne, interne, e dei
gradienti di temperatura e umidità iniziali.
4. Ha inizio la generazione del DCOP.
5. Sono generati gli obiettivi da raggiungere, sotto forma di gradienti di temperatura e umidità per
ogni singola zona, dipendenti dalle matrici che indicano gli obiettivi desiderati dall’utente.
6. Sono creati agenti, domini, variabili, vincoli e funzioni del DCOP.
7. Il file XML viene creato e inviato all’interfaccia di FRODO.
8. Sono ricevute e memorizzate le variabili di output dall’interfaccia di FRODO.
9. Sono modificati i valori di temperatura e umidità esterne, interne, e dei gradienti di temperatura
e umidità tenendo conto unicamente dell’assegnamento delle variabili del DCOP risolto.
10. Se a questo punto è presente un altro DCOP nella serie, si torna al punto 4.
5.2.2. MONDO STOCASTICO
Assumendo l’ipotesi di mondo stocastico, si aggiunge una dose di imprevedibilità alle condizioni
ambientali e ai risultati prodotti dalle azioni del sistema, per valutare il comportamento del sistema sotto
condizioni che rispecchiano più verosimilmente il mondo reale. Il funzionamento del generatore è
identico a quello descritto sopra, tranne per il punto 9, a cui va aggiunta un’ulteriore procedura: dopo
aver stabilito i valori modificati di temperatura assoluta e umidità relativa delle varie zone a seguito degli
assegnamenti nella soluzione del DCOP presente, a questi si aggiunge una certa quantità di “rumore”
che rappresenta l’imprevedibilità del mondo reale. Questa modifica è stata impostata a un valore
massimo di 2 (o -2) °C per la temperatura, e di 10% (o – 10%) per l’umidità. Gli intervalli [-2, +2] e [10, +10] sono quindi campionati con probabilità uniforme.
65
5.3. TEST SULLA CONSISTENZA
Di seguito sono mostrati i risultati di una serie di esempi riguardanti sia singole istanze di DCOP che
serie di DCOP collegati tra loro. I test appartenenti a questo gruppo sono tutti svolti su istanze
dell’edificio A, con condizioni ambientali variabili secondo gli scopi dei test, specificate di volta in volta
nelle singole descrizioni. L’algoritmo di risoluzione utilizzato per risolvere i DCOP è MGM, in quanto è
quello che utilizza meno risorse computazionali e garantisce la rapida risoluzione di qualsiasi istanza
della versione completa del DCOP. MGM non è un algoritmo completo, ma assicura l’ottenimento di
una soluzione in tempi brevi, se questa esiste.
5.3.1. TEST SUI DCOP
Questa serie di test ha lo scopo di dimostrare che il sistema raggiunge gli obiettivi di comfort e di
minimizzazione della potenza voluti dagli utenti, o si avvicina ad essi, e di mostrare i valori che assegna
alle variabili per raggiungere questi obiettivi. E’ inoltre illustrato il diverso comportamento del sistema a
seconda del valore del parametro che pesa l’importanza delle diverse componenti della funzione di
costo: la minimizzazione della potenza, il raggiungimento delle condizioni termiche desiderate, e delle
condizioni igrometriche desiderate. Le condizioni dell’ambiente rilevate per esaminare i risultati dei test
sono misurate dopo un intervallo di un’ora dall’avvio del DCOP. I parametri ambientali che non
svolgono un ruolo fondamentale ai fini dei test sono generati casualmente dal simulatore Java. Le
considerazioni sui test riguardanti riscaldamento, raffreddamento, umidificazione e deumidificazione
dell’ambiente sono esposte al termine della descrizione dei risultati. I valori Gradiente T e Gradiente Hum,
quando presenti, corrispondono alla velocità con cui stanno variando temperatura e umidità
nell’ambiente, nell’istante di tempo a cui si fa riferimento.
Riscaldamento ambiente
Scopo del test: Dato al sistema un obiettivo che prevede il riscaldamento a varie temperature delle
stanze dell’edificio, a partire da condizioni termiche uniformi e in generale da temperature più basse di
quelle desiderate, dimostrare che il sistema si avvicina effettivamente agli obiettivi, e mostrare i valori
che assegna alle variabili del DCOP. Nella Tab. 5.1 mostrati i risultati ottenuti nell’ambiente
dell’edificio, e confrontati con gli obiettivi del problema; nella Tab. 5.2 gli assegnamenti alle variabili per
mezzo dei quali si sono raggiunti questi obiettivi.
Condizioni iniziali: Temperatura iniziale di tutte le zone: 15 °C.
Obiettivo: Temperature: Zona 1: 21 °C; Zona 2: 22 °C; Zona 3: 23 °C; Zona 4: 24 °C; Zona 5: 25 °C
66
Tab. 5.1
Temperature
Temperatura
obiettivo [°C]
Temperatura
iniziale [°C]
Temperatura
finale [°C]
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
21
22
23
24
25
15
15
15
15
15
21
21
23
23
25
Gradiente
T iniziale
[°C/h]
+2
+2
+2
+2
+2
Gradiente
T finale
[°C/h]
+6
+6
+8
+8
+10
Tab. 5.2
Variabili
DCOP
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Riscaldamento
Condiz.
Ventilazione
Umidificazione
Porte
Finestre
VERY_LOW
VERY_HIGH
OFF
VERY_LOW
NORMAL
OFF
OFF
HOT
HOT
HOT
LOW
NORMAL
VERY_LOW
OFF
OFF
OFF
OFF
OFF
OFF
OFF
O/O/S/O
OPEN
OPEN
SHUT
OPEN
SHUT
OPEN
SHUT
OPEN
OPEN
Raffreddamento ambiente
Obiettivo del test: Dato al sistema un obiettivo che prevede il raffreddamento a varie temperature
delle stanze dell’edificio, a partire da condizioni termiche uniformi e in generale da temperature più alte
di quelle desiderate, dimostrare che il sistema si avvicina effettivamente agli obiettivi, e mostrare i valori
che assegna alle variabili del DCOP (Tab. 5.3 e 5.4).
Condizioni iniziali: Temperatura iniziale di tutte le zone: 20 °C.
Obiettivo: Temperature: Zona 1: 11 °C; Zona 2: 12 °C; Zona 3: 13 °C; Zona 4: 14 °C; Zona 5: 15 °C
Tab. 5.3
Temperature
Temperatura
obiettivo [°C]
Temperatura
iniziale [°C]
Temperatura
finale [°C]
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
11
12
13
14
15
20
20
20
20
20
12
12
12
14
15
67
Gradiente
T iniziale
[°C/h]
0
0
0
0
0
Gradiente
T finale
[°C/h]
-7
-7
-7
-6
-4
Tab. 5.4
Variabili Riscaldamento
Condiz.
Ventilazione Umidificazione
Porte
Finestre
DCOP
VERY_COLD VERY_HIGH
Zona 1
OFF
HUM_HIGH O/O/O/S OPEN
VERY_COLD VERY_HIGH
Zona 2
OFF
OFF
OPEN
SHUT
VERY_COLD
VERY_HIGH
Zona 3
LOW
HUM_LOW
OPEN
OPEN
Zona 4
VERY_LOW VERY_COLD
OFF
OFF
OPEN
SHUT
VERY_HIGH
Zona 5
OFF
COLD
OFF
SHUT
SHUT
Umidificazione ambiente
Scopo del test: Dato al sistema un obiettivo che prevede il raggiungimento di vari livelli di umidità
delle stanze dell’edificio, a partire da condizioni di umidità uniformi con percentuali di umidità più
basse di quelle desiderate, dimostrare che il sistema si avvicina effettivamente agli obiettivi, e mostrare i
valori che assegna alle variabili del DCOP (Tab. 5.5 e 5.6).
Condizioni iniziali: Umidità iniziale di tutte le zone: 30%.
Obiettivo: Umidità: Zona 1: 35%; Zona 2: 40%; Zona 3: 45%; Zona 4: 50%; Zona 5: 55%
Tab. 5.5
Umidità
Umidità
obiettivo [%]
Umidità
iniziale [%]
Umidità finale
[%]
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
35
40
45
50
55
30
30
30
30
30
35
38
44
44
44
Tab. 5.6
Variabili
DCOP
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Umidificazione
Porte
Finestre
OFF
HUM_LOW
HUM_HIGH
HUM_HIGH
HUM_HIGH
S/O/O/O
SHUT
OPEN
OPEN
OPEN
SHUT
OPEN
OPEN
OPEN
OPEN
68
Gradiente
Hum
iniziale
[%/h]
+2
+2
+2
+2
+2
Gradiente
Hum finale
[%/h]
+5
+8
+14
+14
+14
Deumidificazione ambiente
Scopo del test: Dato al sistema un obiettivo che prevede il raggiungimento di vari livelli di umidità
delle stanze dell’edificio, a partire da condizioni di umidità uniformi con percentuali di umidità più alte
di quelle desiderate, dimostrare che il sistema si avvicina effettivamente agli obiettivi, e mostrare i valori
che assegna alle variabili del DCOP (Tab. 5.7 e 5.8).
Condizioni iniziali: Umidità iniziale di tutte le zone: 70%.
Obiettivo: Umidità: Zona 1: 65%; Zona 2: 60%; Zona 3: 55%; Zona 4: 50%; Zona 5: 45%
Tab. 5.7
Umidità
Umidità
obiettivo [%]
Umidità
iniziale [%]
Umidità finale
[%]
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
65
60
55
50
45
70
70
70
70
70
62
59
56
49
46
Gradiente
Hum
iniziale
[%/h]
-7
-7
-7
-7
-7
Gradiente
Hum finale
[%/h]
-7
-10
-14
-20
-24
Tab. 5.8
Variabili
DCOP
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Umidificazione
Porte
HUM_HIGH
O/O/S/O
OFF
OPEN
OFF
OPEN
DEHUM_HIGH
SHUT
DEHUM_HIGH
OPEN
Finestre
SHUT
SHUT
OPEN
OPEN
OPEN
Commento: I risultati ottenuti finora ci mostrano che il sistema si è comportato in maniera coerente,
in ogni caso in linea con gli obiettivi previsti. In molti casi i valori di temperatura e umidità derivanti
dalle soluzioni dei DCOP corrispondono esattamente a quelli specificati negli obiettivi, in altri,
soprattutto nel caso dell’umidità, si discostano moderatamente; le motivazioni per cui ciò avviene
saranno approfondite maggiormente nel corso di questa sezione. Alcune variabili del DCOP, in rari casi
hanno assunto valori in contrasto con l’obiettivo del problema (ad esempio nella Tab. 5.8
l’umidificazione nella Zona 1 assume il valore HUM_HIGH, quando il problema chiedeva di ridurre
l’umidità); ciò è dovuto alla discretizzazione dei valori (nell’esempio, la zona 1 era quella che doveva
diminuire l’umidità di un valore molto piccolo: -5%, perciò era minore la probabilità che esistesse una
soluzione effettiva per avvicinarsi all’obiettivo) e all’utilizzo di un algoritmo non ottimo.
69
Minimizzazione potenza
Scopo del test: Il test è composto da due istanze di un problema DCOP che hanno lo stesso obiettivo:
il riscaldamento di una particolare zona dell’edificio. Nel primo (Tab. 5.9) le condizioni ambientali sono
generate casualmente, mentre nel secondo (Tab. 5.10) la temperatura delle altre zone dell’edificio e
quella dell’ambiente esterno, insieme ai relativi gradienti, sono appositamente fissati in modo che
aprendo le porte e le finestre della zona in questione, questa si avvicinerà alla temperatura obiettivo. Il
sistema, che deve raggiungere l’obiettivo minimizzando la potenza utilizzata, nel secondo caso dovrà
necessariamente raggiungere l’obiettivo aprendo porte e finestre, poiché queste utilizzano meno
potenza di tutti gli altri dispositivi, e la potenza utilizzata sarà verosimilmente molto inferiore a quella
utilizzata nel primo caso. Il gradiente iniziale della temperatura è impostato a 0, dove specificato: in
quelle zone la variazione di temperatura dipenderà cioè esclusivamente dai dispositivi di controllo
termico, e non ci saranno variazioni dovute all’ambiente.
Istanza 1
Condizioni iniziali: Temperatura: Zona 1: 15 °C, gradiente T: 0 °C/h
Obiettivo: Temperatura: Zona 1: 20 °C
Tab. 5.9
Variabili Riscaldamento
DCOP
Zona 1
VERY_LOW
Condiz.
VERY_HOT
Ventilazione Umidificazione
OFF
HUM_HIGH
Porte
Finestre
O/O/S/O
SHUT
Risultati: Temperatura: Zona 1: 20 °C; Potenza utilizzata: 530 W (280 W senza contare
l’umidificazione)
Istanza 2
Condizioni iniziali: Temperatura: Zona 1: 15 °C; tutte le altre zone: 30 °C, gradiente T: tutte le zone:
0 °C/h
Obiettivo: Temperatura: Zona 1: 20 °C
Tab. 5.10
Variabili Riscaldamento
DCOP
Zona 1
OFF
Condiz.
OFF
Ventilazione Umidificazione
OFF
Risultati: Temperatura: Zona 1: 20 °C; Potenza utilizzata: 0 W
70
OFF
Porte
Finestre
O/O/O/S
OPEN
Commento: Il sistema si comporta come previsto, aprendo 3 porte su 4 e la finestra della stanza. A
tutte le altre variabili è assegnato il valore OFF, perciò la potenza utilizzata è nulla, dimostrando che
minimizzando la funzione obiettivo il sistema sceglie la soluzione che minimizza la potenza.
Peso delle componenti della funzione di costo
Scopo del test: A parità di condizioni iniziali e obiettivi del sistema, il test valuta il diverso
comportamento del sistema al variare del peso delle tre componenti della funzione di costo del DCOP.
In particolare, nella prima istanza (Tab. 5.11 e 5.12) i valori dei parametri della funzione di costo sono
quelli standard (corrispondenti al valore di default del parametro γ descritto in 3.5.), nella seconda (Tab.
5.13 e 5.14) è azzerato il coefficiente associato alla minimizzazione della potenza (il sistema cercherà
quindi di raggiungere i suoi obiettivi senza preoccuparsi della potenza utilizzata, inoltre viene eliminato
il limite massimo di potenza utilizzabile) e nella terza (Tab. 5.15 e 5.16) è aumentato il valore del
coefficiente della potenza (il sistema si preoccuperà prima di tutto di utilizzare meno potenza possibile,
a scapito del raggiungimento degli obiettivi del problema).
Istanza 1
Coefficiente minimizzazione potenza: 0.3
Condizioni iniziali: Temperatura iniziale di tutte le zone: 10 °C, umidità iniziale di tutte le zone: 20%.
Obiettivo: Temperatura di tutte le zone: 30 °C, umidità di tutte le zone: 60%.
Tab. 5.11
Comfort
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Temperatura
inziale [°C]
10
10
10
10
10
Temperatura
finale [°C]
11
13
13
12
13
Umidità
iniziale [%]
20
20
20
20
20
Umidità
finale [%]
30
30
30
30
30
Tab. 5.12
Variabili
DCOP
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Riscaldamento
Condiz.
Ventilazione
Umidificazione
Porte
Finestre
NORMAL
VERY_LOW
VERY_LOW
VERY_HIGH
VERY_HIGH
OFF
HOT
HOT
OFF
HOT
OFF
OFF
OFF
OFF
OFF
HUM_HIGH
HUM_HIGH
HUM_HIGH
HUM_HIGH
HUM_HIGH
O/S/S/O
OPEN
SHUT
SHUT
OPEN
SHUT
SHUT
SHUT
SHUT
SHUT
Risultati: Potenza utilizzata: 5000 W
71
Istanza 2
Coefficiente minimizzazione potenza: 0
Condizioni iniziali: Temperatura iniziale di tutte le zone: 10 °C, umidità iniziale di tutte le zone: 20%.
Obiettivo: Temperatura di tutte le zone: 30 °C, umidità di tutte le zone: 60%.
Tab. 5.13
Comfort
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Temperatura
inziale [°C]
10
10
10
10
10
Temperatura
finale [°C]
21
21
21
21
21
Umidità
iniziale [%]
20
20
20
20
20
Umidità
finale [%]
30
30
30
30
30
Tab. 5.14
Variabili
DCOP
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Riscaldamento
Condiz.
Ventilazione
Umidificazione
Porte
Finestre
VERY_HIGH
VERY_HIGH
VERY_HIGH
VERY_HIGH
VERY_HIGH
VERY_HOT
VERY_HOT
VERY_HOT
VERY_HOT
VERY_HOT
OFF
OFF
OFF
OFF
OFF
HUM_HIGH
HUM_HIGH
HUM_HIGH
HUM_HIGH
HUM_HIGH
S/S/S/S
SHUT
SHUT
SHUT
SHUT
OPEN
OPEN
OPEN
OPEN
OPEN
Risultati: Potenza utilizzata: 8750 W
Commento: Il sistema ha assegnato alle variabili del DCOP i valori che massimizzano il riscaldamento
e l’umidificazione dell’edificio, ottenendo in questo modo il massimo incremento possibile con quelle
condizioni ambientali e in quell’intervallo di tempo. La potenza utilizzata è molto elevata, e avrebbe
superato il limite massimo se il relativo vincolo fosse stato presente.
72
Istanza 3
Coefficiente minimizzazione potenza: 100
Condizioni iniziali: Temperatura iniziale di tutte le zone: 10 °C, umidità iniziale di tutte le zone: 20%.
Obiettivo: Temperatura di tutte le zone: 30 °C, umidità di tutte le zone: 60%.
Tab. 5.15
Comfort
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Temperatura
inziale [°C]
10
10
10
10
10
Temperatura
finale [°C]
10
10
10
10
10
Umidità
iniziale [%]
20
20
20
20
20
Umidità
finale [%]
20
20
20
20
20
Tab. 5.16
Variabili
DCOP
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Riscaldamento
Condiz.
OFF
OFF
OFF
OFF
OFF
OFF
OFF
OFF
OFF
OFF
Ventilazione Umidificazione
OFF
OFF
OFF
OFF
OFF
OFF
OFF
OFF
OFF
OFF
Porte
Finestre
O/S/O/S
OPEN
SHUT
OPEN
SHUT
OPEN
OPEN
OPEN
OPEN
OPEN
Risultati: Potenza utilizzata: 0 Wh
Commento: Come previsto il sistema ha agito unicamente sulle variabili corrispondenti alle porte e
finestre dell’edificio, che non utilizzano potenza, senza ottenere alcun risultato per quanto riguarda
l’incremento di temperatura e umidità.
73
5.3.2. TEST SULLE SERIE DI DCOP
In questo gruppo di test si verificherà che il sistema riesce a raggiungere gli stessi obiettivi dei DCOP
singoli, ma utilizzando più DCOP in successione per pianificare un graduale avvicinamento agli
obiettivi tenendo conto delle condizioni dell’ambiente nei vari intervalli di tempo, e del tempo che ha a
disposizione per raggiungere tali obiettivi.
Raggiungimento di un obiettivo tramite DCOP successivi
Scopo del test: In questo esperimento gli obiettivi di comfort da raggiungere saranno gli stessi dei test
sui DCOP singoli che riguardavano il riscaldamento e l’umidificazione dell’edificio, ma questi obiettivi
dovranno essere raggiunti al termine di un orizzonte temporale di 6 ore, con un intervallo di
ripianificazione della durata di 1 ora; cioè dovranno essere risolti 6 DCOP in successione (Tab. 5.17 e
5.18). Il test mostrerà quindi come si comporta il sistema quando deve raggiungere degli obiettivi
risolvendo vari DCOP singoli in successione. Le condizioni ambientali di ogni DCOP, tranne quello
iniziale, sono ricavate esattamente da quelle ottenute tenendo conto del risultato del DCOP precedente,
sotto l’ipotesi di mondo deterministico.
Condizioni iniziali: Temperatura iniziale di tutte le zone: 15 °C, umidità iniziale di tutte le zone: 30%
Obiettivo (al termine di un orizzonte temporale di 6 ore): Temperature: Zona 1: 21 °C; Zona 2: 22
°C; Zona 3: 23 °C; Zona 4: 24 °C; Zona 5: 25 °C; Umidità: Zona 1: 35%; Zona 2: 40%; Zona 3: 45%;
Zona 4: 50%; Zona 5: 55%
Tab. 5.17
Temperatura
Temperatura
iniziale[°C]
Temp T1
[°C]
Temp T2
[°C]
Temp
T3 [°C]
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
15
15
15
15
15
16
16
15
14
17
16
16
17
16
19
17
18
19
18
21
Temp Temp Temperatura
T4
T5
finale [°C]
[°C]
[°C]
19
21
21
20
22
23
21
24
24
21
23
23
23
25
25
Tab. 5.18
Umidità
Umidità
iniziale[%]
Hum T1
[%]
Hum T2
[%]
Hum T3
[%]
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
30
30
30
30
30
31
31
34
34
34
32
32
34
39
39
32
34
35
45
45
74
Hum Hum Umidità
T4
T5
finale
[%]
[%]
[%]
33
35
35
36
38
41
41
45
45
45
50
51
51
55
56
Commento: Il sistema ha raggiunto quasi tutti gli obiettivi del problema, con alcuni valori leggermente
diversi dagli obiettivi. Ciò può dipendere dalle condizioni ambientali e in particolari dai gradienti di
variazione di temperatura e umidità che sono stati generati casualmente in tutti i precedenti casi di test,
oppure dalla discretizzazione dei gradienti di temperatura e umidità dipendenti dalle variabili del
DCOP, come descritto nella Sezione 3.5, che non sono controllabili dal sistema con una granularità che
garantisca abbastanza precisione da raggiungere esattamente i valori voluti.
Efficienza e complessità al variare del numero dei DCOP
Scopo del test: In questo test si considerano tre istanze di un problema con obiettivi identici, tranne
che per il numero di DCOP successivi in cui il sistema deve risolverle, e per le variabili ambientali
(descritte nella Sezione 5.2) che sono generate casualmente, e che possono variare durante la
simulazione. L’obiettivo del sistema è di raggiungere una temperatura di 25 °C in tutte le stanze,
partendo da 15 °C, e un’umidità di 40% in tutte le stanze, partendo da 20%. La durata degli intervalli di
ripianificazione è sempre di un’ora. Nella prima istanza (Tab. 5.19 e 5.20) il sistema ha a disposizione
un solo DCOP; nella seconda (Tab. 5.21 e 5.22) l’orizzonte temporale è scomposto in 5 DCOP, e le
condizioni desiderate devono essere raggiunte entro la fine del terzo intervallo, e mantenute fino alla
fine. Nella terza istanza (Tab. 5.23 e 5.24) l’orizzonte temporale è scomposto in 10 DCOP, e le
condizioni desiderate devono essere raggiunte entro la fine del quinto intervallo, e mantenute fino alla
fine. L’efficienza del sistema è valutata calcolando un indice di efficienza definito come l’inverso della
media della differenza tra le condizioni di comfort desiderate e quelle ottenute (considerando allo stesso
modo temperatura e umidità) al termine di ogni intervallo in cui il sistema abbia un obiettivo da
raggiungere; la complessità è valutata dalla somma dei tempi di risoluzione dei DCOP.
Istanza 1
Numero DCOP: 1
Condizioni iniziali: Temperatura iniziale di tutte le zone: 15 °C, umidità iniziale di tutte le zone: 20%.
Obiettivo: Temperatura di tutte le zone: 25 °C, umidità di tutte le zone: 40%.
Tab. 5.19
Temperatura
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Temperatura
iniziale[°C]
15
15
15
15
15
Temp T1
[°C]
22
15
21
17
17
75
Tab. 5.20
Umidità
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Umidità
iniziale[%]
20
20
20
20
20
Hum T1 [%]
29
29
29
29
29
Risultati: Efficienza: 0.11; Tempo di esecuzione: 530 ms
Istanza 2
Numero DCOP: 5
Condizioni iniziali: Temperatura iniziale di tutte le zone: 15 °C, umidità iniziale di tutte le zone: 20%.
Obiettivo: Temperatura di tutte le zone: 25 °C a partire dall’intervallo 4, umidità di tutte le zone: 40% a
partire dall’intervallo 4.
Tab. 5.21
Temperatura
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Temperatura
iniziale[°C]
15
15
15
15
15
Temp T4
[°C]
25
25
25
25
25
Temp T5
[°C]
24
25
25
25
25
Umidità
iniziale[%]
20
20
20
20
20
Hum T4 [%]
Hum T5 [%]
39
41
40
39
41
40
40
40
39
40
Tab. 5.22
Umidità
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Risultati: Efficienza: 3.33; Tempo di esecuzione: 2309 ms
76
Istanza 3
Numero DCOP: 10
Condizioni iniziali: Temperatura iniziale di tutte le zone: 15 °C, umidità iniziale di tutte le zone: 20%.
Obiettivo: Temperatura di tutte le zone: 25 °C a partire dall’intervallo 6, umidità di tutte le zone: 40% a
partire dall’intervallo 6.
Tab. 5.23
Temperatura
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Temperatura
iniziale[°C]
15
15
15
15
15
Temp T6
[°C]
26
25
26
25
25
Temp T7
[°C]
24
25
25
25
25
Temp T8
[°C]
25
25
25
25
25
Temp T9
[°C]
25
25
25
25
25
Temp T10
[°C]
25
25
24
25
24
Hum T9
[%]
40
40
41
40
40
Hum T10
[%]
41
40
40
40
40
Tab. 5.24
Umidità
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Umidità
iniziale[%]
20
20
20
20
20
Hum T6
[%]
38
41
39
40
39
Hum T7
[%]
40
40
42
42
42
Hum T8
[%]
39
40
42
40
40
Risultati: Efficienza: 2.38; Tempo di esecuzione: 4759 ms
Commento: Basandosi su questi risultati, si può dedurre che per risolvere questo problema il miglior
compromesso tra efficienza e complessità sia costituito dalla seconda istanza, che raggiunge dei risultati
addirittura migliori dell’ultima, utilizzando meno DCOP e quindi ovviamente meno potenza di calcolo.
Effettuando questi test su più vasta scala e su specifici problemi, si possono ricavare conclusioni su
quali siano le caratteristiche più adatte per ogni singolo problema, per quanto riguarda il numero di
DCOP in cui è suddiviso.
77
Efficienza e complessità al variare della durata degli intervalli
Scopo del test: In questo test si considerano tre istanze di un problema con obiettivi identici, tranne
che per la durata dei quattro intervalli di ripianificazione corrispondenti ad altrettanti DCOP in cui il
sistema dovrà risolverle, e per le variabili ambientali che saranno generate casualmente. L’obiettivo del
sistema sarà raggiungere una temperatura di 25 °C in tutte le zone, partendo da 15 °C, e un’umidità di
40% in tutte le stanze, partendo da 20%. Gli intervalli di ripianificazione saranno quattro, in ogni
istanza, e gli obiettivi dovranno essere raggiunti a partire dal terzo intervallo, e mantenuti fino alla fine.
Nella prima istanza (Tab. 5.25 e 5.26) gli intervalli saranno di 1 ora, per un orizzonte totale di 4 ore.
Nelle istanze successive gli intervalli saranno di 2 ore (Tab. 5.27 e 5.28) e 4 ore (Tab. 5.29 e 5.30), per
un totale rispettivamente di 8 ore e 16 ore.
Istanza 1
Durata intervallo: 1 ora
Condizioni iniziali: Temperatura iniziale di tutte le zone: 15 °C, umidità iniziale di tutte le zone: 20%.
Obiettivo: Temperatura di tutte le zone: 25 °C a partire dall’intervallo 3, umidità di tutte le zone: 40% a
partire dall’intervallo 3.
Tab. 5.25
Temperatura
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Temperatura
iniziale[°C]
15
15
15
15
15
Temp T3
[°C]
24
25
25
25
25
Temp T4
[°C]
27
30
26
27
25
Umidità
iniziale[%]
20
20
20
20
20
Hum T4 [%]
Hum T5 [%]
40
40
40
40
40
40
42
42
40
40
Tab. 5.26
Umidità
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Risultati: Efficienza: 1.33; Tempo di esecuzione: 1933 ms
78
Istanza 2
Durata intervallo: 2 ore
Condizioni iniziali: Temperatura iniziale di tutte le zone: 15 °C, umidità iniziale di tutte le zone: 20%.
Obiettivo: Temperatura di tutte le zone: 25 °C a partire dall’intervallo 3, umidità di tutte le zone: 40% a
partire dall’intervallo 3.
Tab. 5.27
Temperatura
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Temperatura
iniziale[°C]
15
15
15
15
15
Temp T3
[°C]
25
25
25
24
25
Temp T4
[°C]
25
25
25
24
25
Umidità
iniziale[%]
20
20
20
20
20
Hum T4 [%]
Hum T5 [%]
35
39
39
40
42
33
39
42
38
46
Tab. 5.28
Umidità
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Risultati: Efficienza: 0.69; Tempo di esecuzione: 1975 ms
Istanza 3
Durata intervallo: 4 ore
Condizioni iniziali: Temperatura iniziale di tutte le zone: 15 °C, umidità iniziale di tutte le zone: 20%.
Obiettivo: Temperatura di tutte le zone: 25 °C a partire dall’intervallo 3, umidità di tutte le zone: 40% a
partire dall’intervallo 3.
Tab. 5.29
Temperatura
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Temperatura
iniziale[°C]
15
15
15
15
15
Temp T3
[°C]
25
24
23
23
23
Temp T4
[°C]
25
23
22
23
23
79
Tab. 5.30
Umidità
Zona 1
Zona 2
Zona 3
Zona 4
Zona 5
Umidità
iniziale[%]
20
20
20
20
20
Hum T4 [%]
Hum T5 [%]
40
36
38
34
48
48
34
38
28
56
Risultati: Efficienza: 0.25; Tempo di esecuzione: 2052 ms
Commento: Il test dimostra che a intervalli di ripianificazione più lunghi corrisponde una graduale
perdita di efficienza, mentre la complessità di calcolo non subisce grandi variazioni. Le condizioni
dell’ambiente variano infatti molto più drasticamente tra un intervallo e l’altro, se aumenta la lunghezza
di quest’ultimo, e diminuisce quindi il controllo che il sistema ha su di esso, visto che le variazioni
imposte dal sistema possono agire sull’ambiente con minore frequenza nel tempo.
80
5.4. TEST REALISTICI SU MONDO DETERMINISTICO
Per ognuno dei seguenti test sono presentati prima i risultati di 5 esecuzioni del problema, in termini di
media e deviazione standard della differenza tra i valori di temperatura e umidità ottenuti e quelli
corrispondenti agli obiettivi di ogni intervallo di ripianificazione. A questi risultati, utili per valutare
l’efficienza generale del sistema per ogni test, segue poi la descrizione in dettaglio dei risultati della
prima delle 5 esecuzioni, in modo da poter mostrare più in dettaglio il funzionamento del sistema dal
punto di vista pratico lungo l’arco di una successione di DCOP, e di valutare le condizioni ambientali
ottenute dopo la risoluzione di ogni DCOP della successione.
5.4.1. EDIFICIO A
Il seguente test è costituito da un unico problema, composto di una serie di DCOP, il cui obiettivo è
gestire le condizioni termoigrometriche di tutte le stanze dell’appartamento raffigurato in Fig. 5.1
(edificio A) nell’arco di 24 ore. L’orizzonte temporale è stato perciò impostato a 24 ore, mentre
l’intervallo di ripianificazione ha una durata di 2 ore. Il funzionamento nell’arco di una giornata
corrisponde perciò alla risoluzione di 12 DCOP, uno ogni 2 ore (per esempio, il primo alle 2, il secondo
alle 4 e così via, fino a mezzanotte).
I parametri ambientali iniziali dell’interno e dell’esterno dell’edificio sono generati in modo
completamente casuale. Gli obiettivi, intesi come temperatura assoluta e umidità relativa che devono
essere raggiunti nelle varie stanze dell’edificio, sono invece stabiliti per essere verosimili e per garantire
condizioni ambientali ottimali agli orari e nei luoghi più adeguati alla vita domestica. Ad esempio, nel
soggiorno saranno desiderabili una temperatura di 20-22 °C e un’umidità del 40-60%, nel tardo
pomeriggio e alla sera, supponendo che questi siano gli orari in cui vi siano presenti abitanti, mentre in
cucina, dove per le attività che vi si svolgono solitamente si ha un’umidità dell’80% e temperature anche
elevate, bisognerebbe far scendere queste ultime tra i 18 e i 19 °C, mentre in camera da letto le
condizioni di comfort devono essere mantenute principalmente in orari notturni e mattinieri.
Lo scopo del test è valutare dettagliatamente, in condizioni realistiche, le prestazioni del sistema
nell’arco di una giornata, mostrando i risultati esatti ottenuti ad ogni intervallo. L’esperimento agisce
sotto l’ipotesi di mondo deterministico: cioè, le condizioni dell’ambiente a un dato intervallo di tempo
sono determinate in modo univoco dalle condizioni ambientali durante l’intervallo precedente e dalle
azioni svolte dagli agenti del sistema, senza alcuna variazione casuale se non per le condizioni
ambientali che naturalmente variano lungo l’arco di una giornata. Le condizioni ambientali all’inizio di
un dato intervallo di tempo sono perciò la diretta conseguenza delle decisioni prese dal sistema
nell’intervallo precedente.
La Fig. 5.4 mostra il grafico della media e della deviazione standard della differenza tra condizioni di
comfort ottenute e obiettivi, ottenuti da 5 esecuzioni del problema, per i valori di temperatura e
umidità.
81
6
5
4
Temperatura
3
Umidità
2
1
0
Differenza media
Deviazione standard
Fig. 5.4: Valutazione delle prestazioni del test dell’edificio A su mondo deterministico
I risultati mostrano valori medi e deviazioni standard intuitivamente accettabili: uno scarto medio di
meno di 1 °C rispetto alla temperatura desiderata, e di poco più del 2 % rispetto all’umidità desiderata.
Questi valori sono stati messi a confronto con quelli ottenuti dai successivi test; nelle seg
seguenti sezioni
sono fatte le relative valutazioni e considerazioni.
Le Tab. 5.31 mostrano le condizioni ottenute dal sistema nelle cinque stanze dell’appartamento, a ogni
intervallo di ripianificazione. I valori in grassetto sono quelli corrispondenti agli intervalli per i quali
sono state espressamente specificate dagli utenti le condizioni desiderate.
Tab. 5.31
Zona 1 - Soggiorno: T iniziale: 15 °C, Hum iniziale: 42%
Zona 1
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
20
20
22
22
-
14
14
14
14
16
16
18
20
20
22
23
23
60
60
40
40
-
47
50
51
52
54
56
60
60
59
39
35
31
82
Zona 2 - Bagno: T iniziale: 22 °C, Hum iniziale: 68%
Zona 2
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
20
22
22
20
18
18
20
20
20
20
20
19
21
22
19
18
19
19
19
19
19
19
60
80
80
60
20
20
60
60
60
60
68
58
68
79
69
33
17
21
46
62
59
59
Zona 3 – Camera da letto: T iniziale: 19 °C, Hum iniziale: 44%
Zona 3
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
15
15
15
15
15
18
14
15
15
15
12
11
11
11
14
15
16
17
100
100
100
100
100
80
64
99
100
100
100
100
100
100
100
100
100
81
Zona 4 - Cucina: T iniziale: 20 °C, Hum iniziale: 68%
Zona 4
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
16
16
16
16
16
16
16
-
20
16
16
16
16
16
16
16
13
11
9
8
40
40
40
40
40
40
40
-
58
48
38
39
39
39
39
39
39
39
39
42
83
Zona 5 – Camera da letto: T iniziale: 18 °C, Hum iniziale: 49%
Zona 5
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
15
15
15
15
15
18
16
16
16
16
16
16
16
16
16
15
17
17
100
100
100
100
100
80
69
99
100
100
100
100
100
100
100
96
84
72
Commento: I risultati ottenuti mostrano che il sistema, in ogni intervallo precedente a quello in cui è
presente un obiettivo specifico, indipendentemente dal numero di intervalli occorrenti per raggiungerlo,
cerca gradualmente di raggiungere l’obiettivo. La conseguenza di ciò è che il sistema raggiungerà più
facilmente le condizioni desiderate se ha a disposizione molto tempo “libero” in cui non ha obiettivi
immediati; ad esempio, nel soggiorno il sistema ha a disposizione il mattino e il primo pomeriggio per
raggiungere gradualmente le perfette condizioni desiderate all’orario voluto. La mancanza di
perturbazioni casuali nell’ambiente rende i risultati ottenuti molto stabili, ma in alcuni casi i valori non
risultano essere esattamente quelli voluti per via delle condizioni ambientali naturali, che di per sé
possono mutare da un intervallo all’altro poiché rappresentano le condizioni ambientali naturali nel
corso di una giornata, e delle intrinseche discretizzazione e limitazione dei valori con cui il sistema può
agire sull’ambiente, che solo in pochi casi gli permettono il controllo completo su di esso. Nello
specifico, il gradiente con cui la temperatura e l’umidità variano nel tempo è sempre il risultato della
combinazione tra quello ottenuto dai dispositivi di comfort dell’edificio, quello ambientale e quello
esterno (condizioni intrinseche dell’ambiente); gli ultimi due possono variare casualmente in ogni
intervallo di tempo. Poiché il sistema acquisisce le informazioni sul nuovo stato dell’ambiente
solamente nello stesso istante in cui comunica gli assegnamenti delle variabili che gestiscono i
dispositivi dell’edificio, può non avere il giusto preavviso per poter modificare in tempo le sue scelte a
lungo termine, dato che nel frattempo gli obiettivi da raggiungere potrebbero essere mutati per via delle
condizioni ambientali.
84
5.4.2. EDIFICIO B
Il seguente test è costituito da un unico problema, composto di una serie di DCOP, il cui obiettivo è
gestire le condizioni termoigrometriche di tutte le stanze della sezione di museo
museo raffigurata in Fig. 5.2
(edificio B)) nell’arco di 24 ore. L’orizzonte temporale
temporale è stato perciò impostato a 24 ore, mentre
l’intervallo di ripianificazione ha una durata di 2 ore. Il funzionamento nell’arco di una giornata
corrisponde perciò alla risoluzione di 12 DCOP, uno ogni 2 ore (per esempio, il primo alle 2, il secondo
alle 4 e così via, fino a mezzanotte).
I parametri ambientali iniziali dell’interno e dell’esterno dell’edificio sono generati in modo
completamente casuale. Gli obiettivi, intesi come temperatura assoluta e umidità relativa che devono
essere raggiunti nelle varie stanze dell’edificio, sono invece stabiliti per essere verosimili e per garantire
condizioni ambientali ottimali nei tipici orari di apertura di un luogo pubblico come un museo. A
differenza del problema precedente le condizioni desiderate di temperatura
temperatura e umidità delle varie gallerie
sono identiche tra loro, sia per quanto riguarda gli orari che i valori, che corrispondono a condizioni
molto confortevoli (simili a quelli del soggiorno dell’edificio A)) per tutta la loro durata.
Lo scopo del test e le condizioni sotto cui è svolto sono identici a quelli descritti per il test precedente
sull’edificio A. La Fig. 5.5 mostra il grafico della media e della deviazione standard della differenza tra
condizioni di comfort ottenute e obiettivi, ottenuti da 5 esecuzioni
cuzioni del problema, per i valori di
temperatura e umidità.
8
7
6
5
4
Temperatura
3
Umidità
2
1
0
Differenza media
Deviazione standard
Fig. 5.5: Valutazione delle prestazioni del test dell’edificio B su mondo deterministico
85
I valori ottenuti si confermano in linea con quelli dell’esperimento precedente: le deviazioni standard e
il valor medio dello scarto dell’umidità sono leggermente aumentati, a causa dei soliti elementi casuali e
non controllabili come l’utilizzo di un algoritmo non ottimo e le condizioni ambientali variabili.
Le Tab. 5.32 mostrano i risultati ottenuti nella prima esecuzione:
Tab. 5.32
Zona 1 – Galleria 1: T iniziale: 20 °C, Hum iniziale: 44%
Zona 1
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
20
20
20
22
22
22
20
-
20
20
20
20
20
22
22
21
20
20
20
20
60
60
60
40
40
40
60
-
47
52
58
60
59
47
41
41
41
62
72
83
Zona 2 - Galleria 2: T iniziale: 19 °C, Hum iniziale: 51%
Zona 2
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
20
20
20
22
22
22
20
-
19
19
20
20
20
22
22
22
21
20
20
20
60
60
60
40
40
40
60
-
54
56
61
61
59
46
38
40
41
64
75
85
86
Zona 3 – Galleria 3: T iniziale: 16 °C, Hum iniziale: 58%
Zona 3
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
20
20
20
22
22
22
20
-
17
18
20
20
20
21
22
21
20
19
17
16
60
60
60
40
40
40
60
-
57
57
61
60
59
47
40
38
47
55
63
71
Zona 4 - Galleria 4: T iniziale: 16 °C, Hum iniziale: 44%
Zona 4
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
20
20
20
22
22
22
20
-
17
18
20
20
20
22
22
22
22
19
18
17
60
60
60
40
40
40
60
-
50
56
62
59
61
52
39
35
42
48
52
57
Zona 5 – Galleria 5: T iniziale: 15 °C, Hum iniziale: 44%
Zona 5
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
20
20
20
22
22
22
20
-
16
18
20
20
20
22
22
22
22
18
16
15
60
60
60
40
40
40
60
-
47
52
57
60
60
49
41
38
45
52
60
68
87
Commento: Restano valide le considerazioni fatte nell’esempio precedente. Rispetto ad esso si può
notare una maggiore difficoltà del sistema nel controllo delle condizioni ambientali delle ultime ore
della giornata: queste è dovuto alla generazione casuale delle condizioni ambientali, che in quegli
intervalli di tempo sono risultate maggiormente avverse agli obiettivi del problema. Lo scarto tra le
condizioni ottenute e quelle desiderate diventa comunque significativo solamente in pochissimi
intervalli di tempo (per esempio nelle zone 4 e 5, alle ore 20).
88
5.5. TEST REALISTICI SU MONDO STOCASTICO
La presentazione dei seguenti test rispetta le stesse modalità descritte nella Sezione 5.4.
5.5.1. EDIFICIO A
Il seguente test è costituito da un unico problema, composto di una serie di DCOP, il cui obiettivo è
gestire le condizioni termoigrometriche di tutte le stanze dell’ap
dell’appartamento
partamento raffigurato in Fig. 5.1
(edificio A) nell’arco di 24 ore, come descritto nella Sezione 5.4.1.
Lo scopo del test e le condizioni sotto cui si svolge sono id
identici
entici a quelli del test descritti nella SSezione
5.4.1,, tranne per il fatto che il sistema agisce sotto l’ipotesi di mondo stocastico. Si aggiunge cioè una
dose di imprevedibilità alle condizioni ambientali, per valutare
valutare il comportamento del sistema sotto
condizioni che rispecchiano più verosimilmente il mon
mondo reale, come descritto nella Sezione
ezione 5.2.2.
La Fig. 5.6 mostra il grafico della media e della deviazione standard della differenza tra condizioni di
comfort ottenute e obiettivi, ottenuti da 5 esecuzioni del problema, per i valori di temperatura e
umidità.
14
12
10
8
Temperatura
6
Umidità
4
2
0
Differenza media
Deviazione standard
Fig. 5.6: Valutazione delle prestazioni del test dell’edificio A su mondo stocastico
La prima serie di test su mondo stocastico mostra valori sensibilmente
sensibilmente più elevati delle deviazioni
standard, ma valori medi solo leggermente più alti rispetto al caso stocastico, mantenendo le soluzioni
trovate in ambito accettabile dal punto di vista pratico, nonostante i significativi disturbi casuali
introdotti in questo esperimento.
Le Tab. 5.33 mostrano i risultati ottenuti nella prima esecuzione:
89
Tab. 5.33
Zona 1 - Soggiorno: T iniziale: 24 °C, Hum iniziale: 39%
Zona 1
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
20
20
22
22
-
24
26
27
29
27
23
19
20
22
20
22
23
60
60
40
40
-
48
53
47
48
43
54
66
50
45
32
24
24
Zona 2 - Bagno: T iniziale: 15 °C, Hum iniziale: 41%
Zona 2
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
20
22
22
20
18
18
20
20
20
20
19
21
21
19
19
21
18
22
18
17
21
24
60
80
80
60
20
20
60
60
60
60
53
51
68
81
75
39
12
22
54
59
68
77
90
Zona 3 – Camera da letto: T iniziale: 24 °C, Hum iniziale: 63%
Zona 3
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
15
15
15
15
15
18
15
12
12
10
10
9
7
11
12
12
18
22
100
100
100
100
100
80
81
100
100
100
100
100
95
100
100
100
70
52
Zona 4 - Cucina: T iniziale: 23 °C, Hum iniziale: 70%
Zona 4
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
16
16
16
16
16
16
16
-
20
20
17
17
17
18
14
18
17
14
13
9
40
40
40
40
40
40
40
-
62
63
27
21
37
37
37
30
37
39
39
43
Zona 5 – Camera da letto: T iniziale: 20 °C, Hum iniziale: 40%
Zona 5
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
15
15
15
15
15
18
17
13
16
15
15
19
21
21
18
18
20
17
100
100
100
100
100
80
68
87
100
97
90
87
86
83
95
99
94
83
91
Commento: Rispetto ai test sul mondo deterministico, si possono subito notare maggiori discrepanze
tra gli obiettivi e i risultati ottenuti. Queste sono ovviamente da attribuire al fatto che temperatura e
umidità possono variare da un intervallo all’altro in modo completamente
completamente imprevedibile dal sistema. Ad
esempio, le variazioni di temperatura possono variare da -22 a +2 °C in un singolo intervallo, e ciò si
riscontra immediatamente nei dati a disposizione. Ciononostante il sistema riesce a mantenere sempre
di ordine accettabile gli scarti con la temperatura e l’umidità desiderate, tranne in rarissimi casi.
5.5.2. EDIFICIO B
Il seguente test è costituito da un unico problema, composto di una serie di DCOP, il cui obiettivo è
gestire le condizioni termoigrometriche di
d tutte le stanze dell’appartamento
ll’appartamento raffigurato in Fig. 5.2
(edificio B) nell’arco di 24 ore, come descritto precedentemente.
Lo scopo del test e le condizioni sotto cui si svolge sono identici
identici a quelli del test della Sezione 55.5.1,
tranne per il fatto chee il sistema agisce sotto l’ipotesi di mondo stocastico. Si aggiunge cioè una dose di
imprevedibilità alle condizioni ambientali, per valutare il comportamento del sistema sotto condizioni
che rispecchiano più verosimilmente il mondo reale,
reale come descritto nella Sezione 5.2.2
.2.2.
La Fig. 5.7 mostra il grafico della media e della deviazione standard della differenza tra condizioni di
comfort ottenute e obiettivi, ottenuti da 5 esecuzioni del problema, per i valori di temperatura e
umidità.
14
12
10
8
Temperatura
6
Umidità
4
2
0
Efficienza media
Deviazione standard
Fig. 5.7: Valutazione delle prestazioni del test dell’edificio B su mondo stocastico
92
I valori medi e le deviazioni standard registrati non presentano grandi discrepanze con quelli ottenuti
dal precedente esperimento sull’edificio A. Dai risultati ottenuti finora si può constatare che in generale
il sistema ottiene prestazioni migliori sull’edificio A. Questo può dipendere da dinamiche dipendenti
dalla disposizione delle stanze, che può rendere più o meno difficile ottenere diversi obiettivi nello
stesso intervallo di tempo; oppure può essere legato alla natura degli obiettivi di comfort stessi, molto
diversi tra i due problemi considerati.
Le Tab. 5.34 mostrano i risultati ottenuti nella prima esecuzione:
Tab. 5.34
Zona 1 – Galleria 1: T iniziale: 21 °C, Hum iniziale: 70%
Zona 1
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
20
20
20
22
22
22
20
-
22
20
20
19
19
20
24
22
22
19
20
22
60
60
60
40
40
40
60
-
76
73
53
43
59
65
57
33
41
57
43
30
Zona 2 - Galleria 2: T iniziale: 19 °C, Hum iniziale: 52%
Zona 2
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
20
20
20
22
22
22
20
-
20
21
19
20
21
23
23
22
22
19
20
20
60
60
60
40
40
40
60
-
50
58
52
52
60
58
48
46
45
45
38
45
93
Zona 3 - Galleria 3: T iniziale: 17 °C, Hum iniziale: 64%
Zona 3
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
20
20
20
22
22
22
20
-
19
17
21
19
18
20
22
20
19
19
19
17
60
60
60
40
40
40
60
-
65
63
71
52
61
61
39
25
19
17
12
20
Zona 4 - Galleria 4: T iniziale: 17 °C, Hum iniziale: 68%
Zona 4
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
20
20
20
22
22
22
20
-
28
20
22
21
20
21
24
21
18
18
20
21
60
60
60
40
40
40
60
-
63
63
51
56
69
70
51
29
30
18
8
0
Zona 5 - Galleria 5: T iniziale: 25 °C, Hum iniziale: 47%
Zona 5
Temperatura
obiettivo [°C]
Temperatura
ottenuta [°C]
Umidità obiettivo
[%]
Umidità ottenuta
[%]
02:00
04:00
06:00
08:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
24:00
20
20
20
22
22
22
20
-
24
24
22
18
19
21
22
20
18
20
20
22
60
60
60
40
40
40
60
-
46
52
63
57
60
58
49
46
41
43
50
48
94
Commento: Questo esperimento, soprattutto per quanto riguarda i dati relativi all’umidità, è quello che
presenta i risultati peggiori, in quanto spesso si hanno scarti anche molto pesanti con gli obiettivi del
problema. Anche per la temperatura i risultati non sono stati eccellenti, ma decisamente più accettabili.
Probabilmente, in presenza di grandi disturbi alle condizioni ambientali come quelli introdotti in questo
test, il sistema potrebbe aver bisogno di ulteriori rifiniture. Ad esempio, si potrebbero progettare
funzioni specifiche per gestire al meglio il raggiungimento graduale delle condizioni volute durante gli
intervalli “liberi”, mentre nel sistema descritto in questa tesi queste funzioni sono solamente
approssimate; oppure si potrebbe agire aumentando la discretizzazione dei valori assumibili dalle
variabili dei dispositivi degli agenti del sistema, o quella dei valori stessi che descrivono le condizioni
dell’ambiente.
95
5.6. TEST SUL FUNZIONAMENTO INTERNO
5.6.1.
.6.1. CONFRONTO TRA GLI ALGORITMI DI RISOLUZIONE
Nel seguente esperimento è stato effettuato un confronto tra i tempi di esecuzione di cinque algoritmi
di risoluzione disponibili del framework
amework FRODO, descritti nella Sezione
S
4.4.
Sono stati effettuati due test: il primo utilizzando un campione di 10 DCOP risolti singolarmente da
tutti gli algoritmi, e il secondo utilizzando, al posto ddei DCOP singoli, cinque serie di 3 DCOP, ognuna
risolta come un unico problema.
Il formato dei DCOP fornito in input a FRODO per questi esperimenti è la versione ridotta del
problema completo, descritto in Appendice A.3,, poiché è l’unica versione del problema
sufficientemente semplificata da poter essere risolta con successo da tutti gli algoritmi in questione.
In Fig. 5.8 sono mostrati i risultati del confronto tra i tempi medi di esecuzione (espressi in
millisecondi) e in Fig. 5.9 quelli delle
le deviazioni
deviazioni standard ottenute con i vari algoritmi, per i DCOP
singoli e per le serie di DCOP.
3000
2500
2000
ADOPT
DPOP
1500
MGM
MGM2
1000
SynchBB
500
0
μ - DCOP
μ - Serie DCOP
Fig. 5.8: Confronto dei tempi medi
edi di esecuzione per DCOP singoli e serie di DCOP
96
700
600
500
ADOPT
400
DPOP
MGM
300
MGM2
SynchBB
200
100
0
σ - DCOP
σ - Serie DCOP
Fig. 5.9: Confronto delle deviazioni standard dei tempi di esecuzione per DCOP singoli e serie
di DCOP
Il confronto tra i tempi di esecuzione conferma ampiamente le caratteristiche conosciute di questi
algoritmi. ADOPT richiede molte risorse computazionali se confrontato con gli altri algoritmi: i tempi
impiegati sono stati elevati ed estremamente disomogenei tra un’iterazione e l’altra. DPOP è nettamente
più rapido e, anche a causa della relativa semplicità della versione del DCOP qui proposta, ha risolto
tutti i problemi con tempi minimi e molto simili tra loro. Anche MGM e SynchBB hanno avuto buone
prestazioni, sebbene non
n paragonabili a quelle di DPOP.
DPOP. MGM2, un altro algoritmo non completo, è
stato però quello che ha impiegato i tempi di esecuzione più elevati, anche se poco più omogenei di
quelli di ADOPT: ciò è dovuto al costo dei
dei messaggi scambiati durante l’esecuzione dell’algoritmo,
notoriamente molto più alto di algoritmi simili come ad esempio MGM, rispetto al quale ha però un
vantaggio generale in termini di qualità delle soluzioni trovate.
97
5.6.1.
.6.1. CONFRONTO TRA SERIE
SERI DI DCOP E DDCOP
Il seguente esperimento ha lo scopo di valutare
va
l’effettivo miglioramento delle prestazioni che si ottiene
con la modifica all’algoritmo ADOPT descritta nella Sezione
S
4.3.2,, costituita dall’implementazione della
procedura Reuse-Bounds. L’algoritmo così modificato permette la risoluzione di una serie di DCOP
traendo vantaggio dal fatto che alcune parti del grafo dei vincoli di un DCOP potrebbero essere
identiche a quelle del DCOP che lo ha preceduto, e che quindi non necessitino di essere ridefinite,
permettendo un notevole decremento della complessità di esecuzione; è il concetto alla base della
definizione
ne di un Dynamic DCOP (Sezione 3.6.3).
3.6.3
L’esperimento è stato effettuato su una successione
s
di dieci DCOP, in cui tutte le variabili e le
condizioni ambientali sono generate casualmente tranne dove specificato. L’esperimento è svolto sul
modello dell’edificio A, con un orizzonte temporale di 10 ore e un intervallo di ripianificazione di 1 ora
ora;
per ogni serie di test sono state effettuate 5 iterazioni dell’algoritmo sulla serie di DCOP
DCOP. Nella prima
serie di test non è stata applicata la modifica all’algoritmo ADOPT: il problema non è stato quindi
risolto come un DDCOP, ma come una semplice serie di DCOP singoli. Nella seconda tutte le
condizioni
oni di partenza, e quelle desiderate, relative a una singola zona dell’edificio non cambiano mai
per tutti i DCOP della serie: l’algoritmo applica cioè la procedura Reuse-Bounds
Bounds per questa singola
zona, per tutta la durata del problema, poiché le variabili di quella zona non saranno mai influenzate dal
cambio di contesto. Nella terza l’immutabilità delle condizioni viene aumentata a due zone. Nella quarta
tutte le zone vengono rese immutabili, ma solo per la durata di uno dei dieci DCOP, mentre nella
quinta la durata si estendee a 4 DCOP. Infine nell’ultima serie di test viene preso in considerazione il
caso estremo dove tutte le zone sono immutabili per tutta la durata del problema. In Fig. 5.10 sono
confrontati i tempi medi di esecuzione di ogni serie.
serie
7000
6000
5000
No RB
1 z infl
4000
2 z infl
1 DCOP
3000
4 DCOP
9 DCOP
2000
1000
0
Fig. 5.10:: Confronto dei tempi medi di esecuzione con utilizzo della procedura Reuse
Reuse-Bounds
98
Dal grafico si nota innanzitutto che il caso estremo corrispondente all’ultima serie di test ha dato l’esito
sperato: un tempo di esecuzione drasticamente inferiore al tempo di esecuzione dello stesso problema
con ADOPT classico (speedup del 18,59), poiché il sistema deve in sostanza risolvere solamente il
primo DCOP, il cui risultato sarà automaticamente assegnato alle variabili dei DCOP successivi, che
sono in sostanza identici al primo. Quando i DCOP ad essere “non influenzati” sono solo alcuni, il
tempo impiegato a risolvere i rispettivi DDCOP diminuisce visibilmente all’aumentare del numero di
questi ultimi: ad esempio, con 1 DCOP “immutato” si ha uno speedup di 1,19, mentre con 4 DCOP
“immutati” di 1,64. La stessa considerazione può essere fatta quando ad aumentare sono le zone “non
influenzate”, perciò si può concludere che il tempo impiegato da questa versione di ADOPT per
risolvere una serie di DCOP dipende direttamente dal numero di DCOP, e di zone in questi DCOP, le
cui condizioni ambientali non variano rispetto al problema precedente.
99
CAPITOLO 6
CONCLUSIONI E SVILUPPI FUTURI
In questo lavoro di tesi sono stati analizzati alcuni tra i più importanti e innovativi metodi di controllo
termoigrometrico degli edifici, sia tra i dispositivi in commercio, sia per quanto riguarda la ricerca
scientifica.
Si è poi applicata all’ambito del controllo del comfort la formulazione di un problema di ottimizzazione
vincolato distribuito (DCOP), in particolare una formulazione costituita da un insieme di DCOP. In
questo modello, ogni DCOP rappresenta la situazione di un edificio in un istante di tempo, e a partire
dalle condizioni ambientali dell’edificio e dagli obiettivi programmati dagli utenti, restituisce i valori che
i dispositivi di comfort dell’edificio assumeranno nell’intervallo successivo per soddisfare tali obiettivi.
Questo modello è stato poi ulteriormente ramificato in due formulazioni: come una successione
ordinata di DCOP che vengono risolti singolarmente uno dopo l’altro; e come DCOP dinamico, in cui
la risoluzione di ogni DCOP dipende strettamente dal problema precedente nella sequenza.
Una sezione importante della tesi è stata riservata all’implementazione della procedura Reuse-Bounds,
descritta a livello teorico in [38], per modificare l’algoritmo ADOPT all’interno del framework
FRODO, con l’obiettivo di ottenere un software capace di risolvere un DDCOP in un caso reale, visto
che non sono state trovate implementazioni alternative.
Sono poi state effettuate varie serie di test che hanno valutato il comportamento del sistema prendendo
in considerazione il DCOP singolo, la serie di DCOP nelle sue varie formulazioni, i risultati pratici
ottenuti da varie simulazioni del funzionamento del sistema su istanze realistiche sotto le ipotesi di
mondo deterministico o stocastico, e infine un confronto tra i tempi di risoluzione dei diversi algoritmi
di FRODO e una valutazione che ha dimostrato l’efficacia della modifica implementata all’algoritmo
ADOPT.
Il lavoro descritto in questa tesi si propone come una base da cui partire per sviluppare sistemi di
controllo del comfort basati sull’approccio DCOP. Le caratteristiche dei problemi e delle istanze su cui
sono state svolte le sperimentazioni sono basate infatti su un modello molto semplificato del
comportamento di un vero edificio, in cui molti aspetti fondamentali sono stati soltanto approssimati:
in particolare, il modello delle leggi della fisica e della termodinamica che governano le variazioni di
temperatura e di umidità in un edificio di una certa forma e caratterizzato da particolari condizioni
ambientali, necessita di numerose informazioni e sperimentazioni per rispecchiare in modo accettabile
la realtà.
A livello sperimentale, la maggiore problematica emersa è stata la mancata possibilità di eseguire la
versione completa del DCOP su tutti gli algoritmi di risoluzione. La complessità del problema,
considerando tutte le variabili e i vincoli esposti nella descrizione del problema applicativo, si è rivelata
infatti tale da poter essere eseguita solamente da pochi algoritmi; ad esempio, l’esecuzione del DCOP su
ADOPT e DPOP, due algoritmi ottimi, generalmente falliva per la sua elevata richiesta di memoria.
Perciò un possibile sviluppo futuro del lavoro potrebbe prevedere una riformulazione del problema per
diminuirne la complessità, o la ricerca di un metodo per poter eseguire lo stesso problema su algoritmi
100
più potenti. Infatti la maggior parte delle sperimentazioni di questo lavoro sono state eseguite con
MGM, un algoritmo non ottimo, rendendo le valutazioni sui risultati ottenuti meno rilevanti sotto il
profilo della correttezza. Potendo invece contare su algoritmi ottimi, sarebbe possibile effettuare
valutazioni sperimentali molto più significativi.
101
BIBLIOGRAFIA
[1] D. J. Cook, J. C. Augusto, V. R. Jakkula. Ambient intelligence: Technologies, applications,
and opportunities. Pervasive and Mobile Computing 5, 2009, p. 277-98
[2] J. M. Vidal. Fundamentals of multiagent systems with NetLogo examples. 2010.
http://jmvidal.cse.sc.edu/papers/mas.pdf
[3] D. J. Cook, S. K. Das. How smart are our environments? An updated look at the state of
the art. Pervasive and Mobile Computing 3 (2007) 53–73
[4] A. Rogers, S. Maleki, S. Ghosh and N. R. Jennings. An Intelligent Agent for Home Heating
Management (Demonstration). Proceedings of the 11th International Conference on
Autonomous Agents and Multiagent Systems (AAMAS 2012) – 2012, 1471-1472
[5] D. J. Cook, M. Youngblood, E. O. Heierman, III, K. Gopalratnam, S. Rao, A. Litvin, and F.
Khawaja. MavHome: An Agent-Based Smart Home. Proceedings of the First IEEE
International Conference on Pervasive Computing and Communications (PerCom’03) – 2003 –
521-524
[6] M. C. Mozer. The Neural Network House: An Environment that Adapts to its Inhabitants.
Proceedings of the American Association for Artificial Intelligence Spring Symposium on
Intelligent Environments (pp. 110-114). Menlo Park, CA: AAAI Press. 1998
[7] D. J. Cook. Multi-agent smart environments, Journal of Ambient Intelligence and Smart
Environments 1, 2009, p. 47-51
[8] A.I. Dounis, C.Caraiscos. Advanced control systems engineering for energy and comfort
management in a building environment. A review, Renewable and Sustainable Energy Reviews
13, 2009, p. 1247-61
[9] V. Lesser, M. Atighetchi, B. Benyo, B. Horling, A. Raja, R. Vincent, T. Wagner, P. Xuan
and S. XQ. Zhang. A Multi-Agent System for Intelligent Environment Control. Umass
Computer Science Technical Report 1998-40
[10] R. Z. Freire, G. H.C. Oliveira, N. Mendes. Predictive controllers for thermal comfort
optimization and energy savings. Energy and Buildings 40 (2008) 1353–1365
[11] D. J. Cook, M. Huber, K. Gopalratnam, and M. Youngblood. Learning to Control a Smart
Home Environment. In Innovative Applications of Artificial Intelligence, 2003
[12] S. K. Das, D. J. Cook, A. Bhattacharya, E. O. Heierman III and T. Lin. The Role of
Prediction Algorithms in the MavHome Smart Home Architecture. IEEE Wireless
Communications Volume 9 Issue 6, December 2002, Page 77-84
[13] B. Huberman and S. H. Clearwater. A Multi-Agent System for Controlling Building
Environments. Proceedings from the First International Conference on MultiAgent Systems,
1995, p. 171-76
[14] H. Hagras , V. Callaghan, M. Colley, G. Clarke. A Hierarchical Fuzzy-Genetic Multi-Agent
Architecture for Intelligent Buildings Online Learning, Architecture and Control. Information
Sciences 150 (2003) 33–57
[15] G. Evans, Director of Engineering, MTI Inc., Portland, OR. Solving Home Automation
Problems using Artificial Intelligence Techniques. Consumer Electronics, IEEE Transactions
on (Volume:37 , Issue: 3 ), 1991, p. 395-400
102
[16] Levermore GJ. Building energy management systems: an application to heating and
control, 2000, Taylor & Francis
[17] Bernard C, Guerrier B, Rasset-Louerant MM. Optimal building energy management. Part
II: Control. ASME Journal of Solar Energy Engineering 1982;114:13
[18] House J, Smith T. A system approach to optimal control for HVAC and building systems.
HVAC&R Research, Vol. 14 No. 1, January 2008
[19] P. S. Curtis, G. Shavit, J. F. Kreider, Neural Networks Applied to Buildings-A Tutorial and
Case Studies in Prediction and Adaptive Control. ASHRAE Transactions part 2, volume 100(1)
1996
[20] Altrock C, Arend HO, Krause B, Steffens C, Behrens-Rommler E. Adaptive fuzzy control
applied to home heating system. Fuzzy Sets and Systems, Fuzzy Sets and Systems, Volume 61
Issue 1, Jan. 10, 1994, Pages 29-35
[21] Breemen AJN, Vries TJA. Design and implementation of a room thermostat using an
agent-based approach, Control Engineering Practice, 9 (3). pp. 233-248
[22] KNX – Flexible, Economical, Reliable. Smart Home and Intelligent Building Control 2012
[23] P. Davidsson and M. Boman. A Multi-Agent System for Controlling Intelligent Buildings.
Proceedings from the Fourth International Conference on MultiAgent Systems, 2000, pp. 377378
[24] Jang JSR, Sun CT, Mizutani E. Neuro-fuzzy and soft computing. Prentice Hall; 1996
[25] Dounis AI, Manolakis DE. Design of a fuzzy system for living space thermalcomfort
regulation. Applied Energy 2001; 69:119–44
[26] Dounis AI, Santamouris M, Lefas CC, Argiriou A. Design of a fuzzy set environment
comfort system. Energy and Buildings 1994; 22:81–7
[27] Kolokotsa D. Design and implementation of an integrated intelligent building indoor
environment management system using fuzzy logic, advanced decision support techniques,
local operating network capabilities and smart card technology. PhD. Technical University of
Crete; 2001
[28] Kanarachos A, Geramanis K. Multivariable control of single zone hydronic heating
systems with neural networks. Energy Conversion Management 1998;13(13): 1317–36
[29] Liang J, Du R. Thermal comfort control based on neural network for HVAC application.
In: Proceedings of the control applications conference, 2005, p. 819–24
[30] M. Ngobye, W. T. de Groot and T. P. van der Weide. Types and priorities of multi-agent
system interactions. Interdisciplinary Description of Complex Systems - scientific journal, 2010,
vol. 8, issue 1, pages 49-58
[31] Organising Committee of the Third International Competition of CSP Solvers. XML
Representation of Constraint Networks – Format XCSP 2.1, January 15 2008.
http://www.cril.univartois.fr/~lecoutre/research/benchmarks/benchmarks.html
[32] M. Wahbi, R. Ezzahir, C. Bessiere, and E. H. Bouyakhf. DisChoco 2: A platform for
distributed constraint reasoning. In Proceedings of the Thirteenth International Workshop on
Distributed Constraint Reasoning (DCR’11), pages 112–121, Barcelona, Spain, July 17 2011 http://www.lirmm.fr/coconut/dischoco/
[33] A. Gershman, R. Zivan, T. Grinshpoun, A. Grubshtein, and A. Meisels. Measuring
distributed constraint optimization algorithms. In Proceedings of the AAMAS’08 Distributed
Constraint Reasoning Workshop (DCR’08), pages 17–24, Estoril, Portugal, May 13 2008
103
[34] E. A. Sultanik, R. N. Lass, and W. C. Regli. DCOPolis: A framework for simulating and
deploying distributed constraint optimization algorithms. In Jonathan P. Pearce, editor,
Proceedings of the Ninth International Workshop on Distributed Constraint Reasoning
(CPDCR’ 07), Providence, RI, USA, September 23 2007
[35] Graphviz - Graph Visualization Software. http://www.graphviz.org/
[36] T. Léauté, B. Ottens, and R. Szymanek. FRODO: ___a FRamework for Open/Distributed
Optimization
–
version
2.11.
http://thomas.leaute.name/frodo/manual/FRODO_User_Manual.html
[37] P. J. Modi, W. Shen, M. Tambe, and M. Yokoo. ADOPT: Asynchronous distributed
constraint optimization with quality guarantees. Artificial Intelligence, 161:149–180, 2005
[38] W. Yeoh, P. Varakantham, X. Sun and S. Koenig. Incremental DCOP Search Algorithms
for Solving Dynamic DCOPs [Extended Abstract]. In Proceedings of the International Joint
Conference on Autonomous Agents and Multiagent Systems (AAMAS), pages 169-170, 2011
[39] A. Petcu, and B. Faltings. A Scalable Method for Multiagent Constraint Optimization. In
Leslie Pack Kaelbling and Alessandro Saffiotti, editors, Proceedings of the Nineteenth
International Joint Conference on Artificial Intelligence (IJCAI’05), pages 266–271, Edinburgh,
Scotland, July 31 – August 5 2005
[40] F. R. Kschischang, B. Frey, and H. A. Loeliger. Factor graphs and the sum-product
algorithm. IEEE Transactions On Information Theory, Vol. 47 No. 2, pages 498–519,
February 2001
[41] A. Petcu, and B. Faltings. A distributed, complete method for multiagent constraint
optimization. In CP 2004. Fifth International Workshop on Distributed Constraint Reasoning
(DCR2004) in Toronto, Canada, September 2004
[42] R. T. Maheswaran, J. P. Pearce, and M. Tambe. Distributed algorithms for DCOP: A
graphical-game-based approach. In David A. Bader and Ashfaq A. Khokhar, editors,
Proceedings of the ISCA Seventeenth International Conference on Parallel and Distributed
Computing Systems (ISCA PDCS’04), pages 432–439, Francisco, California, USA, September
15–17 2004. ISCA
[43] M. Yokoo, and K. Hirayama. Distributed breakout algorithm for solving distributed
constraint satisfaction and optimization problems. In Proc. ICMAS, pages 401–408, 1996
[44] K. Hirayama and M. Yokoo. Distributed partial constraint satisfaction problem. In Gert
Smolka, editor, Proceedings of the Third International Conference on Principles and Practice
of Constraint Programming (CP’97), volume 1330, pages 222–236, Linz, Austria, Oct. 29–Nov.
1 1997
[45] K.Ghedira. A distributed approach to partial constraint satisfaction problems. In J. Perram
and J.-P. Mller, editors, Distributed Software Agents and Applications, volume 1069 of Lecture
Notes in Computer Science, pages 106–122. Springer Berlin / Heidelberg, 1996
[46] V. Ricquebourg, D. Menga, D. Durand, B. Marhic, L. Delahoche, C. Logé – The Smart
Home concept: Our immediate future – E-Learning in Industrial Electronics, 2006 1ST IEEE
International Conference on, p. 23-28
104
APPENDICE A
ESEMPI DI ISTANZE DCOP
A.1. PROBLEMA COMPLETO – EDIFICIO A
In Fig. A.1 è mostrato un esempio di istanza DCOP basata sull’edificio A e sulla versione completa del
problema, usato nella maggior parte dei test sperimentali. Gli elementi presenti nel documento XML
possono essere così suddivisi:
<agent>: gli elementi con questo tag corrispondono agli agenti del sistema
<domain>: gli elementi con questo tag corrispondono ai domini delle variabili
<variable>: gli elementi con questo tag corrispondono alle variabili del problema
powerCostFunction: l’elemento <function> con questo nome è la funzione a valori interi che
definisce la componente della funzione di costo riguardante la potenza
thermoCostFunction: gli elementi <function> con questo nome sono le funzioni a valori interi che
definiscono le componenti della funzione di costo riguardanti il comfort termico; variano a
seconda delle caratteristiche dell’edificio
humCostFunction: l’elemento <function> con questo nome sono le funzioni a valori interi che
definiscono le componenti della funzione di costo riguardanti il comfort igrometrico; variano a
seconda delle caratteristiche dell’edificio
max_power: l’elemento <constraint> con questo nome definisce il vincolo globale sul limite di
potenza utilizzabile
<constraint>: gli elementi con questo tag corrispondono ai vincoli veri e propri del problema
<instance>
<presentation name="ThermoHygrometricComfortProblem1" maxConstraintArity="20"
maximize="false" format="XCSP 2.1_FRODO" />
<agents nbAgents="29">
<agent name="a_heat1" />
<agent name="a_cond1" />
<agent name="a_vent1" />
<agent name="a_humd1" />
<agent name="a_heat2" />
<agent name="a_cond2" />
<agent name="a_vent2" />
<agent name="a_humd2" />
<agent name="a_heat3" />
<agent name="a_cond3" />
<agent name="a_vent3" />
<agent name="a_humd3" />
<agent name="a_heat4" />
<agent name="a_cond4" />
<agent name="a_vent4" />
<agent name="a_humd4" />
<agent name="a_heat5" />
<agent name="a_cond5" />
105
<agent name="a_vent5" />
<agent name="a_humd5" />
<agent name="a_door12" />
<agent name="a_door13" />
<agent name="a_door14" />
<agent name="a_door15" />
<agent name="a_wind1" />
<agent name="a_wind2" />
<agent name="a_wind3" />
<agent name="a_wind4" />
<agent name="a_wind5" />
</agents>
<domains nbDomains="5">
<domain name="d_heat" nbValues="6">0..5</domain>
<domain name="d_cond" nbValues="5">0..4</domain>
<domain name="d_vent" nbValues="6">0..5</domain>
<domain name="d_humd" nbValues="5">0..4</domain>
<domain name="d_door_wind" nbValues="2">0 1</domain>
</domains>
<variables nbVariables="29">
<variable name="HEAT1" domain="d_heat" agent="a_heat1" />
<variable name="COND1" domain="d_cond" agent="a_cond1" />
<variable name="VENT1" domain="d_vent" agent="a_vent1" />
<variable name="HUMD1" domain="d_humd" agent="a_humd1" />
<variable name="HEAT2" domain="d_heat" agent="a_heat2" />
<variable name="COND2" domain="d_cond" agent="a_cond2" />
<variable name="VENT2" domain="d_vent" agent="a_vent2" />
<variable name="HUMD2" domain="d_humd" agent="a_humd2" />
<variable name="HEAT3" domain="d_heat" agent="a_heat3" />
<variable name="COND3" domain="d_cond" agent="a_cond3" />
<variable name="VENT3" domain="d_vent" agent="a_vent3" />
<variable name="HUMD3" domain="d_humd" agent="a_humd3" />
<variable name="HEAT4" domain="d_heat" agent="a_heat4" />
<variable name="COND4" domain="d_cond" agent="a_cond4" />
<variable name="VENT4" domain="d_vent" agent="a_vent4" />
<variable name="HUMD4" domain="d_humd" agent="a_humd4" />
<variable name="HEAT5" domain="d_heat" agent="a_heat5" />
<variable name="COND5" domain="d_cond" agent="a_cond5" />
<variable name="VENT5" domain="d_vent" agent="a_vent5" />
<variable name="HUMD5" domain="d_humd" agent="a_humd5" />
<variable name="DOOR12" domain="d_door_wind" agent="a_door12" />
<variable name="DOOR13" domain="d_door_wind" agent="a_door13" />
<variable name="DOOR14" domain="d_door_wind" agent="a_door14" />
<variable name="DOOR15" domain="d_door_wind" agent="a_door15" />
<variable name="WIND1" domain="d_door_wind" agent="a_wind1" />
<variable name="WIND2" domain="d_door_wind" agent="a_wind2" />
<variable name="WIND3" domain="d_door_wind" agent="a_wind3" />
<variable name="WIND4" domain="d_door_wind" agent="a_wind4" />
<variable name="WIND5" domain="d_door_wind" agent="a_wind5" />
</variables>
<functions nbFunctions="11">
<function name="powerCostFunction" return="int">
<parameters> int heat int cond int vent int humd </parameters>
<expression>
<functional>add(add(add(mul(200,heat),mul(250,abs(sub(cond,2)))),mul(20,vent)),mul(125,abs(su
b(humd,2))))</functional>
</expression>
</function>
<function name="thermoCostFunction1" return="int">
<parameters> int heat int cond int vent int door12 int door13 int door14 int
door15 int wind </parameters>
<expression>
<functional>mul(3,abs(sub(1000,add(add(add(add(add(add(add(add(add(1000,mul(400,heat)),mul(3000,sub(cond,2))),mul(-300,vent)),mul(-1,200)),mul(door12,mul(1,200))),mul(door13,mul(-1,200))),mul(door14,mul(-1,200))),mul(door15,mul(-1,200))),mul(wind,mul(1,200))))))</functional>
</expression>
</function>
<function name="thermoCostFunction2" return="int">
<parameters> int heat int cond int vent int door int wind </parameters>
<expression>
<functional>mul(3,abs(sub(1000,add(add(add(add(add(add(1000,mul(400,heat)),mul(3000,sub(cond,2))),mul(-300,vent)),mul(-1,200)),mul(door,mul(1,200))),mul(wind,mul(-1,200))))))</functional>
</expression>
</function>
106
<function name="thermoCostFunction3" return="int">
<parameters> int heat int cond int vent int door int wind </parameters>
<expression>
<functional>mul(3,abs(sub(1000,add(add(add(add(add(add(1000,mul(400,heat)),mul(3000,sub(cond,2))),mul(-300,vent)),mul(-1,200)),mul(door,mul(1,200))),mul(wind,mul(-1,200))))))</functional>
</expression>
</function>
<function name="thermoCostFunction4" return="int">
<parameters> int heat int cond int vent int door int wind </parameters>
<expression>
<functional>mul(3,abs(sub(1000,add(add(add(add(add(add(1000,mul(400,heat)),mul(3000,sub(cond,2))),mul(-300,vent)),mul(-1,200)),mul(door,mul(1,200))),mul(wind,mul(-1,200))))))</functional>
</expression>
</function>
<function name="thermoCostFunction5" return="int">
<parameters> int heat int cond int vent int door int wind </parameters>
<expression>
<functional>mul(3,abs(sub(1000,add(add(add(add(add(add(1000,mul(400,heat)),mul(3000,sub(cond,2))),mul(-300,vent)),mul(-1,200)),mul(door,mul(1,200))),mul(wind,mul(-1,200))))))</functional>
</expression>
</function>
<function name="humCostFunction1" return="int">
<parameters> int humd int door12 int door13 int door14 int door15 int wind
</parameters>
<expression>
<functional>mul(3,abs(sub(2000,add(add(add(add(add(add(5000,mul(sub(humd,2),2000)),mul(door12,mul(-5,500))),mul(door13,mul(-5,500))),mul(door14,mul(5,500))),mul(door15,mul(-5,500))),mul(wind,mul(-5,500))))))</functional>
</expression>
</function>
<function name="humCostFunction2" return="int">
<parameters> int humd int door int wind </parameters>
<expression>
<functional>mul(3,abs(sub(2000,add(add(add(5000,mul(sub(humd,2),2000)),mul(door,mul(-5,500))),mul(wind,mul(-5,500))))))</functional>
</expression>
</function>
<function name="humCostFunction3" return="int">
<parameters> int humd int door int wind </parameters>
<expression>
<functional>mul(3,abs(sub(2000,add(add(add(5000,mul(sub(humd,2),2000)),mul(door,mul(-5,500))),mul(wind,mul(-5,500))))))</functional>
</expression>
</function>
<function name="humCostFunction4" return="int">
<parameters> int humd int door int wind </parameters>
<expression>
<functional>mul(3,abs(sub(2000,add(add(add(5000,mul(sub(humd,2),2000)),mul(door,mul(-5,500))),mul(wind,mul(-5,500))))))</functional>
</expression>
</function>
<function name="humCostFunction5" return="int">
<parameters> int humd int door int wind </parameters>
<expression>
<functional>mul(3,abs(sub(2000,add(add(add(5000,mul(sub(humd,2),2000)),mul(door,mul(-5,500))),mul(wind,mul(-5,500))))))</functional>
</expression>
</function>
</functions>
<constraints nbConstraints="16">
<constraint name="max_power" arity="20" scope="HEAT1 COND1 VENT1 HUMD1 HEAT2 COND2
VENT2 HUMD2 HEAT3 COND3 VENT3 HUMD3 HEAT4 COND4 VENT4 HUMD4 HEAT5 COND5 VENT5 HUMD5"
reference="global:weightedSum" >
<parameters> [ { 200 HEAT1 } { 250 COND1 } { 20 VENT1 } { 125 HUMD1 } { 200
HEAT2 } { 250 COND2 } { 20 VENT2 } { 125 HUMD2 } { 200 HEAT3 } { 250 COND3 } { 20 VENT3 } { 125
HUMD3 } { 200 HEAT4 } { 250 COND4 } { 20 VENT4 } { 125 HUMD4 } { 200 HEAT5 } { 250 COND5 } { 20
VENT5 } { 125 HUMD5 } ] <le/> 8000 </parameters>
</constraint>
<constraint name="cost_function1" arity="4" scope="HEAT1 COND1 VENT1 HUMD1"
reference="powerCostFunction" >
<parameters>HEAT1 COND1 VENT1 HUMD1</parameters>
</constraint>
107
<constraint name="cost_function2" arity="4" scope="HEAT2 COND2 VENT2 HUMD2"
reference="powerCostFunction" >
<parameters>HEAT2 COND2 VENT2 HUMD2</parameters>
</constraint>
<constraint name="cost_function3" arity="4" scope="HEAT3 COND3 VENT3 HUMD3"
reference="powerCostFunction" >
<parameters>HEAT3 COND3 VENT3 HUMD3</parameters>
</constraint>
<constraint name="cost_function4" arity="4" scope="HEAT4 COND4 VENT4 HUMD4"
reference="powerCostFunction" >
<parameters>HEAT4 COND4 VENT4 HUMD4</parameters>
</constraint>
<constraint name="cost_function5" arity="4" scope="HEAT5 COND5 VENT5 HUMD5"
reference="powerCostFunction" >
<parameters>HEAT5 COND5 VENT5 HUMD5</parameters>
</constraint>
<constraint name="thermo_cost_function1" arity="8" scope="HEAT1 COND1 VENT1 DOOR12
DOOR13 DOOR14 DOOR15 WIND1" reference="thermoCostFunction1" >
<parameters>HEAT1 COND1 VENT1 DOOR12 DOOR13 DOOR14 DOOR15 WIND1</parameters>
</constraint>
<constraint name="thermo_cost_function2" arity="5" scope="HEAT2 COND2 VENT2 DOOR12
WIND2" reference="thermoCostFunction2" >
<parameters>HEAT2 COND2 VENT2 DOOR12 WIND2</parameters>
</constraint>
<constraint name="thermo_cost_function3" arity="5" scope="HEAT3 COND3 VENT3 DOOR13
WIND3" reference="thermoCostFunction3" >
<parameters>HEAT3 COND3 VENT3 DOOR13 WIND3</parameters>
</constraint>
<constraint name="thermo_cost_function4" arity="5" scope="HEAT4 COND4 VENT4 DOOR14
WIND4" reference="thermoCostFunction4" >
<parameters>HEAT4 COND4 VENT4 DOOR14 WIND4</parameters>
</constraint>
<constraint name="thermo_cost_function5" arity="5" scope="HEAT5 COND5 VENT5 DOOR15
WIND5" reference="thermoCostFunction5" >
<parameters>HEAT5 COND5 VENT5 DOOR15 WIND5</parameters>
</constraint>
<constraint name="hum_cost_function1" arity="6" scope="HUMD1 DOOR12 DOOR13 DOOR14
DOOR15 WIND1" reference="humCostFunction1" >
<parameters>HUMD1 DOOR12 DOOR13 DOOR14 DOOR14 WIND1</parameters>
</constraint>
<constraint name="hum_cost_function2" arity="3" scope="HUMD2 DOOR12 WIND2"
reference="humCostFunction2" >
<parameters>HUMD2 DOOR12 WIND2</parameters>
</constraint>
<constraint name="hum_cost_function3" arity="3" scope="HUMD3 DOOR13 WIND3"
reference="humCostFunction3" >
<parameters>HUMD3 DOOR13 WIND3</parameters>
</constraint>
<constraint name="hum_cost_function4" arity="3" scope="HUMD4 DOOR14 WIND4"
reference="humCostFunction4" >
<parameters>HUMD4 DOOR14 WIND4</parameters>
</constraint>
<constraint name="hum_cost_function5" arity="3" scope="HUMD5 DOOR15 WIND5"
reference="humCostFunction5" >
<parameters>HUMD5 DOOR15 WIND5</parameters>
</constraint>
</constraints>
</instance>
Fig.A.1: Esempio di istanza DCOP corrispondente all’edificio A e alla versione completa del
problema
108
A.2. PROBLEMA COMPLETO – EDIFICIO B
In Fig. A.2 è mostrato un esempio di istanza DCOP basata sull’edificio B e sulla versione completa del
problema, usato nella maggior parte dei test sperimentali. Valgono le stesse considerazioni dell’esempio
A.1, rispetto al quale variano le funzioni thermoCostFunction e humCostFunction, che rispecchiano le
caratteristiche dell’edificio B.
<instance>
<presentation name="ThermoHygrometricComfortProblem1" maxConstraintArity="20"
maximize="false" format="XCSP 2.1_FRODO" />
<agents nbAgents="29">
<agent name="a_heat1" />
<agent name="a_cond1" />
<agent name="a_vent1" />
<agent name="a_humd1" />
<agent name="a_heat2" />
<agent name="a_cond2" />
<agent name="a_vent2" />
<agent name="a_humd2" />
<agent name="a_heat3" />
<agent name="a_cond3" />
<agent name="a_vent3" />
<agent name="a_humd3" />
<agent name="a_heat4" />
<agent name="a_cond4" />
<agent name="a_vent4" />
<agent name="a_humd4" />
<agent name="a_heat5" />
<agent name="a_cond5" />
<agent name="a_vent5" />
<agent name="a_humd5" />
<agent name="a_door12" />
<agent name="a_door13" />
<agent name="a_door14" />
<agent name="a_door15" />
<agent name="a_wind1" />
<agent name="a_wind2" />
<agent name="a_wind3" />
<agent name="a_wind4" />
<agent name="a_wind5" />
</agents>
<domains nbDomains="5">
<domain name="d_heat" nbValues="6">0..5</domain>
<domain name="d_cond" nbValues="5">0..4</domain>
<domain name="d_vent" nbValues="6">0..5</domain>
<domain name="d_humd" nbValues="5">0..4</domain>
<domain name="d_door_wind" nbValues="2">0 1</domain>
</domains>
<variables nbVariables="29">
<variable name="HEAT1" domain="d_heat" agent="a_heat1" />
<variable name="COND1" domain="d_cond" agent="a_cond1" />
<variable name="VENT1" domain="d_vent" agent="a_vent1" />
<variable name="HUMD1" domain="d_humd" agent="a_humd1" />
<variable name="HEAT2" domain="d_heat" agent="a_heat2" />
<variable name="COND2" domain="d_cond" agent="a_cond2" />
<variable name="VENT2" domain="d_vent" agent="a_vent2" />
<variable name="HUMD2" domain="d_humd" agent="a_humd2" />
<variable name="HEAT3" domain="d_heat" agent="a_heat3" />
<variable name="COND3" domain="d_cond" agent="a_cond3" />
<variable name="VENT3" domain="d_vent" agent="a_vent3" />
<variable name="HUMD3" domain="d_humd" agent="a_humd3" />
<variable name="HEAT4" domain="d_heat" agent="a_heat4" />
<variable name="COND4" domain="d_cond" agent="a_cond4" />
<variable name="VENT4" domain="d_vent" agent="a_vent4" />
<variable name="HUMD4" domain="d_humd" agent="a_humd4" />
<variable name="HEAT5" domain="d_heat" agent="a_heat5" />
<variable name="COND5" domain="d_cond" agent="a_cond5" />
<variable name="VENT5" domain="d_vent" agent="a_vent5" />
109
<variable
<variable
<variable
<variable
<variable
<variable
<variable
<variable
<variable
<variable
</variables>
name="HUMD5" domain="d_humd" agent="a_humd5" />
name="DOOR12" domain="d_door_wind" agent="a_door12" />
name="DOOR13" domain="d_door_wind" agent="a_door13" />
name="DOOR14" domain="d_door_wind" agent="a_door14" />
name="DOOR15" domain="d_door_wind" agent="a_door15" />
name="WIND1" domain="d_door_wind" agent="a_wind1" />
name="WIND2" domain="d_door_wind" agent="a_wind2" />
name="WIND3" domain="d_door_wind" agent="a_wind3" />
name="WIND4" domain="d_door_wind" agent="a_wind4" />
name="WIND5" domain="d_door_wind" agent="a_wind5" />
<functions nbFunctions="11">
<function name="powerCostFunction" return="int">
<parameters> int heat int cond int vent int humd </parameters>
<expression>
<functional>add(add(add(mul(200,heat),mul(250,abs(sub(cond,2)))),mul(20,vent)),mul(125,abs(su
b(humd,2))))</functional>
</expression>
</function>
<function name="thermoCostFunction1" return="int">
<parameters> int heat int cond int vent int door12 int wind </parameters>
<expression>
<functional>mul(3,abs(sub(1000,add(add(add(add(add(add(1000,mul(400,heat)),mul(3000,sub(cond,2))),mul(-300,vent)),mul(-1,200)),mul(door12,mul(1,200))),mul(wind,mul(-1,200))))))</functional>
</expression>
</function>
<function name="thermoCostFunction2" return="int">
<parameters> int heat int cond int vent int door12 int door13 int wind
</parameters>
<expression>
<functional>mul(3,abs(sub(1000,add(add(add(add(add(add(add(1000,mul(400,heat)),mul(3000,sub(cond,2))),mul(-300,vent)),mul(-1,200)),mul(door12,mul(1,200))),mul(door13,mul(-1,200))),mul(wind,mul(-1,200))))))</functional>
</expression>
</function>
<function name="thermoCostFunction3" return="int">
<parameters> int heat int cond int vent int door13 int door14 int wind
</parameters>
<expression>
<functional>mul(3,abs(sub(1000,add(add(add(add(add(add(add(1000,mul(400,heat)),mul(3000,sub(cond,2))),mul(-300,vent)),mul(-1,200)),mul(door13,mul(1,200))),mul(door14,mul(-1,200))),mul(wind,mul(-1,200))))))</functional>
</expression>
</function>
<function name="thermoCostFunction4" return="int">
<parameters> int heat int cond int vent int door14 int door15 int wind
</parameters>
<expression>
<functional>mul(3,abs(sub(1000,add(add(add(add(add(add(add(1000,mul(400,heat)),mul(3000,sub(cond,2))),mul(-300,vent)),mul(-1,200)),mul(door14,mul(1,200))),mul(door15,mul(-1,200))),mul(wind,mul(-1,200))))))</functional>
</expression>
</function>
<function name="thermoCostFunction5" return="int">
<parameters> int heat int cond int vent int door15 int wind </parameters>
<expression>
<functional>mul(3,abs(sub(1000,add(add(add(add(add(add(1000,mul(400,heat)),mul(3000,sub(cond,2))),mul(-300,vent)),mul(-1,200)),mul(door15,mul(1,200))),mul(wind,mul(-1,200))))))</functional>
</expression>
</function>
<function name="humCostFunction1" return="int">
<parameters> int humd int door12 int wind </parameters>
<expression>
<functional>mul(3,abs(sub(2000,add(add(add(5000,mul(sub(humd,2),2000)),mul(door12,mul(-5,500))),mul(wind,mul(-5,500))))))</functional>
</expression>
</function>
<function name="humCostFunction2" return="int">
<parameters> int humd int door12 int door13 int wind </parameters>
<expression>
<functional>mul(3,abs(sub(2000,add(add(add(add(5000,mul(sub(humd,2),2000)),mul(door12,mul(-5,500))),mul(door13,mul(-5,500))),mul(wind,mul(5,500))))))</functional>
</expression>
110
</function>
<function name="humCostFunction3" return="int">
<parameters> int humd int door13 int door14 int wind </parameters>
<expression>
<functional>mul(3,abs(sub(2000,add(add(add(add(5000,mul(sub(humd,2),2000)),mul(door13,mul(-5,500))),mul(door14,mul(-5,500))),mul(wind,mul(5,500))))))</functional>
</expression>
</function>
<function name="humCostFunction4" return="int">
<parameters> int humd int door14 door15 int wind </parameters>
<expression>
<functional>mul(3,abs(sub(2000,add(add(add(add(5000,mul(sub(humd,2),2000)),mul(door14,mul(-5,500))),mul(door15,mul(-5,500))),mul(wind,mul(5,500))))))</functional>
</expression>
</function>
<function name="humCostFunction5" return="int">
<parameters> int humd int door15 int wind </parameters>
<expression>
<functional>mul(3,abs(sub(2000,add(add(add(5000,mul(sub(humd,2),2000)),mul(door15,mul(-5,500))),mul(wind,mul(-5,500))))))</functional>
</expression>
</function>
</functions>
<constraints nbConstraints="16">
<constraint name="max_power" arity="20" scope="HEAT1 COND1 VENT1 HUMD1 HEAT2 COND2
VENT2 HUMD2 HEAT3 COND3 VENT3 HUMD3 HEAT4 COND4 VENT4 HUMD4 HEAT5 COND5 VENT5 HUMD5"
reference="global:weightedSum" >
<parameters> [ { 200 HEAT1 } { 250 COND1 } { 20 VENT1 } { 125 HUMD1 } { 200
HEAT2 } { 250 COND2 } { 20 VENT2 } { 125 HUMD2 } { 200 HEAT3 } { 250 COND3 } { 20 VENT3 } { 125
HUMD3 } { 200 HEAT4 } { 250 COND4 } { 20 VENT4 } { 125 HUMD4 } { 200 HEAT5 } { 250 COND5 } { 20
VENT5 } { 125 HUMD5 } ] <le/> 8000 </parameters>
</constraint>
<constraint name="cost_function1" arity="4" scope="HEAT1 COND1 VENT1 HUMD1"
reference="powerCostFunction" >
<parameters>HEAT1 COND1 VENT1 HUMD1</parameters>
</constraint>
<constraint name="cost_function2" arity="4" scope="HEAT2 COND2 VENT2 HUMD2"
reference="powerCostFunction" >
<parameters>HEAT2 COND2 VENT2 HUMD2</parameters>
</constraint>
<constraint name="cost_function3" arity="4" scope="HEAT3 COND3 VENT3 HUMD3"
reference="powerCostFunction" >
<parameters>HEAT3 COND3 VENT3 HUMD3</parameters>
</constraint>
<constraint name="cost_function4" arity="4" scope="HEAT4 COND4 VENT4 HUMD4"
reference="powerCostFunction" >
<parameters>HEAT4 COND4 VENT4 HUMD4</parameters>
</constraint>
<constraint name="cost_function5" arity="4" scope="HEAT5 COND5 VENT5 HUMD5"
reference="powerCostFunction" >
<parameters>HEAT5 COND5 VENT5 HUMD5</parameters>
</constraint>
<constraint name="thermo_cost_function1" arity="5" scope="HEAT1 COND1 VENT1
WIND1" reference="thermoCostFunction1" >
<parameters>HEAT1 COND1 VENT1 DOOR12 WIND1</parameters>
</constraint>
<constraint name="thermo_cost_function2" arity="6" scope="HEAT2 COND2 VENT2
DOOR13 WIND2" reference="thermoCostFunction2" >
<parameters>HEAT2 COND2 VENT2 DOOR12 DOOR13 WIND2</parameters>
</constraint>
<constraint name="thermo_cost_function3" arity="6" scope="HEAT3 COND3 VENT3
DOOR14 WIND3" reference="thermoCostFunction3" >
<parameters>HEAT3 COND3 VENT3 DOOR13 DOOR14 WIND3</parameters>
</constraint>
<constraint name="thermo_cost_function4" arity="6" scope="HEAT4 COND4 VENT4
DOOR15 WIND4" reference="thermoCostFunction4" >
<parameters>HEAT4 COND4 VENT4 DOOR14 DOOR15 WIND4</parameters>
</constraint>
<constraint name="thermo_cost_function5" arity="5" scope="HEAT5 COND5 VENT5
WIND5" reference="thermoCostFunction5" >
<parameters>HEAT5 COND5 VENT5 DOOR15 WIND5</parameters>
</constraint>
<constraint name="hum_cost_function1" arity="3" scope="HUMD1 DOOR12 WIND1"
111
DOOR12
DOOR12
DOOR13
DOOR14
DOOR15
reference="humCostFunction1" >
<parameters>HUMD1 DOOR12 WIND1</parameters>
</constraint>
<constraint name="hum_cost_function2" arity="4" scope="HUMD2
reference="humCostFunction2" >
<parameters>HUMD2 DOOR12 DOOR13 WIND2</parameters>
</constraint>
<constraint name="hum_cost_function3" arity="4" scope="HUMD3
reference="humCostFunction3" >
<parameters>HUMD3 DOOR13 DOOR14 WIND3</parameters>
</constraint>
<constraint name="hum_cost_function4" arity="4" scope="HUMD4
reference="humCostFunction4" >
<parameters>HUMD4 DOOR14 DOOR15 WIND4</parameters>
</constraint>
<constraint name="hum_cost_function5" arity="3" scope="HUMD5
reference="humCostFunction5" >
<parameters>HUMD5 DOOR15 WIND5</parameters>
</constraint>
</constraints>
</instance>
DOOR12 DOOR13 WIND2"
DOOR13 DOOR14 WIND3"
DOOR14 DOOR15 WIND4"
DOOR15 WIND5"
Fig.A.2: Esempio di istanza DCOP corrispondente all’edificio B e alla versione completa del
problema
112
A.3. PROBLEMA RIDOTTO – EDIFICIO A
In Fig. A.3 è mostrato un esempio di DCOP formulato secondo la versione ridotta del problema, che è
stata creata per poter eseguire il problema sull’algoritmo ADOPT, quindi riducendo notevolmente la
complessità rispetto al problema completo. In particolare, sono state effettuate le seguenti modifiche:
E’ stato eliminato il vincolo globale sul limite massimo di potenza
Sono stati eliminati gli agenti, il dominio e le variabili riguardanti i dispositivi di ventilazione; e
di conseguenza sono stati ridotti tutti i vincoli e le funzioni in cui queste variabili erano presenti
Le componenti della funzione di costo riguardanti il comfort termico e igrometrico sono state
ulteriormente ridotte; in particolare, sono state eliminati dei vincoli che rappresentavano alcune
correlazioni tra le zone, come ad esempio il ruolo delle porte nel collegamento tra alcune stanze.
In questo modo diminuisce la complessità dello pseudo-albero creato dal problema, poiché
diminuisce il numero delle relazioni tra i nodi
<instance>
<presentation name="ThermoHygrometricComfortProblem2" maxConstraintArity="4" maximize="false"
format="XCSP 2.1_FRODO" />
<agents nbAgents="25">
<agent name="a_heat1" />
<agent name="a_cond1" />
<agent name="a_humd1" />
<agent name="a_heat2" />
<agent name="a_cond2" />
<agent name="a_humd2" />
<agent name="a_heat3" />
<agent name="a_cond3" />
<agent name="a_humd3" />
<agent name="a_heat4" />
<agent name="a_cond4" />
<agent name="a_humd4" />
<agent name="a_heat5" />
<agent name="a_cond5" />
<agent name="a_humd5" />
<agent name="a_door11" />
<agent name="a_door12" />
<agent name="a_door13" />
<agent name="a_door14" />
<agent name="a_door15" />
<agent name="a_wind1" />
<agent name="a_wind2" />
<agent name="a_wind3" />
<agent name="a_wind4" />
<agent name="a_wind5" />
</agents>
<domains nbDomains="4">
<domain name="d_heat" nbValues="6">0..5</domain>
<domain name="d_cond" nbValues="5">0..4</domain>
<domain name="d_humd" nbValues="5">0..4</domain>
<domain name="d_door_wind" nbValues="2">0 1</domain>
</domains>
<variables nbVariables="25">
<variable agent="a_heat1" domain="d_heat" name="HEAT1"/>
<variable name="COND1" domain="d_cond" agent="a_cond1" />
<variable name="HUMD1" domain="d_humd" agent="a_humd1" />
<variable name="HEAT2" domain="d_heat" agent="a_heat2" />
<variable name="COND2" domain="d_cond" agent="a_cond2" />
<variable name="HUMD2" domain="d_humd" agent="a_humd2" />
<variable name="HEAT3" domain="d_heat" agent="a_heat3" />
<variable name="COND3" domain="d_cond" agent="a_cond3" />
<variable name="HUMD3" domain="d_humd" agent="a_humd3" />
<variable name="HEAT4" domain="d_heat" agent="a_heat4" />
113
<variable
<variable
<variable
<variable
<variable
<variable
<variable
<variable
<variable
<variable
<variable
<variable
<variable
<variable
<variable
</variables>
name="COND4" domain="d_cond" agent="a_cond4" />
name="HUMD4" domain="d_humd" agent="a_humd4" />
name="HEAT5" domain="d_heat" agent="a_heat5" />
name="COND5" domain="d_cond" agent="a_cond5" />
name="HUMD5" domain="d_humd" agent="a_humd5" />
name="DOOR11" domain="d_door_wind" agent="a_door11" />
name="DOOR12" domain="d_door_wind" agent="a_door12" />
name="DOOR13" domain="d_door_wind" agent="a_door13" />
name="DOOR14" domain="d_door_wind" agent="a_door14" />
name="DOOR15" domain="d_door_wind" agent="a_door15" />
name="WIND1" domain="d_door_wind" agent="a_wind1" />
name="WIND2" domain="d_door_wind" agent="a_wind2" />
name="WIND3" domain="d_door_wind" agent="a_wind3" />
name="WIND4" domain="d_door_wind" agent="a_wind4" />
name="WIND5" domain="d_door_wind" agent="a_wind5" />
<functions nbFunctions="11">
<function name="powerCostFunction" return="int">
<parameters> int heat int cond int humd </parameters>
<expression>
<functional>add(add(mul(200,heat),mul(250,abs(sub(cond,2)))),mul(125,abs(sub(humd,2))))</func
tional>
</expression>
</function>
<function name="thermoCostFunction1" return="int">
<parameters> int heat int cond int door int wind </parameters>
<expression>
<functional>mul(3,abs(sub(1000,add(add(add(add(add(1000,mul(400,heat)),mul(3000,sub(cond,2))),mul(-1,200)),mul(door,mul(-1,200))),mul(wind,mul(1,200))))))</functional>
</expression>
</function>
<function name="thermoCostFunction2" return="int">
<parameters> int heat int cond int door int wind </parameters>
<expression>
<functional>mul(3,abs(sub(1000,add(add(add(add(add(1000,mul(400,heat)),mul(3000,sub(cond,2))),mul(-1,200)),mul(door,mul(-1,200))),mul(wind,mul(1,200))))))</functional>
</expression>
</function>
<function name="thermoCostFunction3" return="int">
<parameters> int heat int cond int door int wind </parameters>
<expression>
<functional>mul(3,abs(sub(1000,add(add(add(add(add(1000,mul(400,heat)),mul(3000,sub(cond,2))),mul(-1,200)),mul(door,mul(-1,200))),mul(wind,mul(1,200))))))</functional>
</expression>
</function>
<function name="thermoCostFunction4" return="int">
<parameters> int heat int cond int door int wind </parameters>
<expression>
<functional>mul(3,abs(sub(1000,add(add(add(add(add(1000,mul(400,heat)),mul(3000,sub(cond,2))),mul(-1,200)),mul(door,mul(-1,200))),mul(wind,mul(1,200))))))</functional>
</expression>
</function>
<function name="thermoCostFunction5" return="int">
<parameters> int heat int cond int door int wind </parameters>
<expression>
<functional>mul(3,abs(sub(1000,add(add(add(add(add(1000,mul(400,heat)),mul(3000,sub(cond,2))),mul(-1,200)),mul(door,mul(-1,200))),mul(wind,mul(1,200))))))</functional>
</expression>
</function>
<function name="humCostFunction1" return="int">
<parameters> int humd int wind </parameters>
<expression>
<functional>mul(3,abs(sub(2000,add(add(5000,mul(sub(humd,2),2000)),mul(wind,mul(-5,500))))))</functional>
</expression>
</function>
<function name="humCostFunction2" return="int">
<parameters> int humd int wind </parameters>
<expression>
<functional>mul(3,abs(sub(2000,add(add(5000,mul(sub(humd,2),2000)),mul(wind,mul(-5,500))))))</functional>
114
</expression>
</function>
<function name="humCostFunction3" return="int">
<parameters> int humd int wind </parameters>
<expression>
<functional>mul(3,abs(sub(2000,add(add(5000,mul(sub(humd,2),2000)),mul(wind,mul(-5,500))))))</functional>
</expression>
</function>
<function name="humCostFunction4" return="int">
<parameters> int humd int wind </parameters>
<expression>
<functional>mul(3,abs(sub(2000,add(add(5000,mul(sub(humd,2),2000)),mul(wind,mul(-5,500))))))</functional>
</expression>
</function>
<function name="humCostFunction5" return="int">
<parameters> int humd int wind </parameters>
<expression>
<functional>mul(3,abs(sub(2000,add(add(5000,mul(sub(humd,2),2000)),mul(wind,mul(-5,500))))))</functional>
</expression>
</function>
</functions>
<constraints nbConstraints="15">
<constraint name="cost_function1" arity="3" scope="HEAT1 COND1 HUMD1"
reference="powerCostFunction" >
<parameters>HEAT1 COND1 HUMD1</parameters>
</constraint>
<constraint name="cost_function2" arity="3" scope="HEAT2 COND2 HUMD2"
reference="powerCostFunction" >
<parameters>HEAT2 COND2 HUMD2</parameters>
</constraint>
<constraint name="cost_function3" arity="3" scope="HEAT3 COND3 HUMD3"
reference="powerCostFunction" >
<parameters>HEAT3 COND3 HUMD3</parameters>
</constraint>
<constraint name="cost_function4" arity="3" scope="HEAT4 COND4 HUMD4"
reference="powerCostFunction" >
<parameters>HEAT4 COND4 HUMD4</parameters>
</constraint>
<constraint name="cost_function5" arity="3" scope="HEAT5 COND5 HUMD5"
reference="powerCostFunction" >
<parameters>HEAT5 COND5 HUMD5</parameters>
</constraint>
<constraint name="thermo_cost_function1" arity="4" scope="HEAT1 COND1
reference="thermoCostFunction1" >
<parameters>HEAT1 COND1 DOOR11 WIND1</parameters>
</constraint>
<constraint name="thermo_cost_function2" arity="4" scope="HEAT2 COND2
reference="thermoCostFunction2" >
<parameters>HEAT2 COND2 DOOR12 WIND2</parameters>
</constraint>
<constraint name="thermo_cost_function3" arity="4" scope="HEAT3 COND3
reference="thermoCostFunction3" >
<parameters>HEAT3 COND3 DOOR13 WIND3</parameters>
</constraint>
<constraint name="thermo_cost_function4" arity="4" scope="HEAT4 COND4
reference="thermoCostFunction4" >
<parameters>HEAT4 COND4 DOOR14 WIND4</parameters>
</constraint>
<constraint name="thermo_cost_function5" arity="4" scope="HEAT5 COND5
reference="thermoCostFunction5" >
<parameters>HEAT5 COND5 DOOR15 WIND5</parameters>
</constraint>
<constraint name="hum_cost_function1" arity="2" scope="HUMD1 WIND1"
reference="humCostFunction1" >
<parameters>HUMD1 WIND1</parameters>
</constraint>
<constraint name="hum_cost_function2" arity="2" scope="HUMD2 WIND2"
reference="humCostFunction2" >
<parameters>HUMD2 WIND2</parameters>
</constraint>
<constraint name="hum_cost_function3" arity="2" scope="HUMD3 WIND3"
reference="humCostFunction3" >
<parameters>HUMD3 WIND3</parameters>
</constraint>
115
DOOR11 WIND1"
DOOR12 WIND2"
DOOR13 WIND3"
DOOR14 WIND4"
DOOR15 WIND5"
<constraint name="hum_cost_function4" arity="2" scope="HUMD4 WIND4"
reference="humCostFunction4" >
<parameters>HUMD4 WIND4</parameters>
</constraint>
<constraint name="hum_cost_function5" arity="2" scope="HUMD5 WIND5"
reference="humCostFunction5" >
<parameters>HUMD5 WIND5</parameters>
</constraint>
</constraints>
</instance>
Fig.A.3: Esempio di istanza DCOP corrispondente all’edificio A e alla versione ridotta del
problema
116
