POLITECNICO DI MILANO
Facoltà di Ingegneria dell’Informazione
Dipartimento di Elettronica e Informazione
UN SISTEMA MULTIAGENTE PER APPLICAZIONI DOMOTICHE
IN CONTESTI REALI
Relatore: Ing. Francesco AMIGONI
Correlatore: Ing. Nicola GATTI
Tesi di Laurea di:
Giovanni GRAUSO Matr. n.632500
[email protected]
Anno Accademico 2003-2004
SOMMARIO
L’ambiente domestico e le relazioni tra l’uomo e le funzionalità offerte dai dispositivi di
una casa costituiscono un ambito molto dinamico, variabile, non totalmente strutturabile e
quindi non programmabile in modo statico. In un’abitazione l’uomo si trova spesso a dover
raggiungere obiettivi complessi il cui conseguimento necessita della cooperazione tra diversi
attori e di una pianificazione complessa e dinamica.
Questa considerazione ha dato lo spunto iniziale per questa tesi, il cui scopo è quello di
validare in un contesto reale le capacità di una piattaforma multiagente (denominata AGENZIA
AMBIENTALE) implementata in un precedente progetto di tesi e testata, finora, solo in ambito
simulato. L’AGENZIA AMBIENTALE è in grado di soddisfare esigenze d’alto livello sfruttando
una cooperazione e una pianificazione dinamica tra diversi agenti. Per verificare in pratica
queste caratteristiche dell’AGENZIA AMBIENTALE è stato scelto di realizzare un’applicazione
reale in un ambito fortemente dinamico e non strutturabile a priori come quello domestico.
Per utilizzare l’AGENZIA AMBIENTALE in un ambito reale e non solo simulato sono state
apportate delle modifiche significative al progetto iniziale. In particolare si è fornita una
soluzione per poter far fronte a possibili malfunzionamenti dei dispositivi e per poter gestire
un’eventuale variabilità delle condizioni nelle quali si trova a operare l’agenzia. Inoltre, per
interfacciare l’AGENZIA AMBIENTALE con differenti tecnologie reali è stata realizzata
un’interfaccia per l’interoperabilità, specializzabile secondo la tecnologia scelta. Per la
realizzazione pratica dell’applicazione domotica è stata fornita un’implementazione per la
tecnologia LONTALK per connettere diversi dispositivi di un’abitazione.
RINGRAZIAMENTI
Desidero ringraziare l’Ing. Francesco Amigoni per aver creduto nelle mie capacità, per
avermi guidato per l’intero progetto di tesi in modo efficace, efficiente e stimolante e per
avermi saputo spiegare concetti importanti con estrema semplicità e precisione.
Ringrazio l’Ing. Nicola Gatti per l’estrema disponibilità, per tutto il materiale bibliografico
che mi ha messo a disposizione e per le piacevoli e costruttive discussioni.
Ringrazio l’azienda TECHSELESTA che mi ha ospitato per un lungo periodo. In particolare
ringrazio l’Ing. Davide Strepparava per l’enorme pazienza e i preziosi consigli, ringrazio
l’Ing. Roberto Loi per avermi sempre fornito tutto il materiale e le informazioni di cui ho
avuto bisogno.
Un grazie al finanziatore dell’intero progetto LAUREA: la mia famiglia, che mi ha permesso e
mi ha incitato in questo lungo, impegnativo e piacevole percorso universitario. In particolare
ringrazio mia madre e mio padre per aver sempre creduto in me e ringrazio mio fratello per il
notevole contributo apportato in tutti questi anni. Ringrazio mio nonno Silvestro e mia nonna
Rosa per aver espresso nei miei confronti sempre parole d’orgoglio e incoraggiamento.
Desidero ringraziare tutti gli amici che in questi anni mi hanno rivolto le domande più
assurde per avermi permesso di approfondire la conoscenza nel campo della “tecnologia”.
Ringrazio anche tutti gli amici architetti (e designer) o aspiranti tali per le preziose
informazioni e i piacevoli dialoghi.
Ringrazio chi mi ha sopportato in tutti i periodi d’esame e nel periodo della tesi.
Un saluto e un grazie a Davide Avigni col quale ho collaborato in questi mesi sempre con
grande armonia e spirito di squadra.
Un ringraziamento sentito e un saluto speciale al Prof. Marco Somalvico.
INDICE
Titolo
1
Sommario
3
Ringraziamenti
5
Indice
7
1. Introduzione
11
2. Stato dell’arte
16
2.1. Ubiquitous computing
17
2.1.1 Introduzione storica
18
2.1.2. Caratteristiche e peculiarità dell’ubiquitous computing
20
2.1.3. Architetture per l’ubiquitous computing
23
2.1.3.1. Interfaccia
24
2.1.3.2. Applicativo
26
2.1.3.3. Middleware
33
2.1.3.4. Comunicazione
41
2.1.3.5. Dispositivi
43
2.2. Domotica e ubiquitous computing
48
2.2.1. Introduzione alla domotica
48
2.2.2. Domotica, ambiti applicativi
49
2.2.3. Domotica: una specializzazione dell’ubiquitous computing, caratteristiche e peculiarità
49
2.3. Standard e tecnologie ad impatto sull’automazione domestica esistenti sul mercato
51
2.3.1. Standard e tecnologie d’interconnessione
51
2.3.2. Protocolli, standard, bus di campo e architetture consolidate sul mercato della domotica
53
2.3.3. I gateway: una soluzione per un unico standard con molti standard
56
2.3.4. Un’altra tecnologia ad impatto sulla domotica: JINI
58
3. Impostazione del problema di ricerca: dalla simulazione alla pratica in ambito domotico
3.1. Inquadramento e introduzione all’architettura preesistente
60
61
3.1.1. Architettura generale della AGENZIA AMBIENTALE
62
3.1.2. Semiagente cooperativo
63
3.1.3. Semiagente operativo
66
3.1.4. Linee guida per la progettazione di un proxy
67
3.1.5. Maggiordomo dell’AGENZIA AMBIENTALE
67
3.1.6. Comportamento dell’AGENZIA AMBIENTALE orientato ai goal
69
3.1.7. Elementi del piano
71
3.1.8. Passaggio di conoscenza fra agenti
79
3.2. Problematiche specifiche per un’applicazione domotica in contesto reale
80
3.2.1. Il contesto per un sistema domotico
81
3.2.2. Ergonomia dell’interazione uomo - ambiente domestico, alcuni aspetti percettivi
83
3.2.3. Necessità di gestire più dispositivi per ogni agente in ambito domotico
85
3.2.4. Problematiche legate alla gestione di più dispositivi per ogni agente
85
3.2.5. Una tecnologia adeguata per la messa in opera del semiagente operativo
88
3.3. Interfaccia proxy - dispositivi
89
3.3.1. Interfaccia proxy - dispositivi: servizi offerti e trasparenza della tecnologia utilizzata
89
3.3.2. Identificazione di servizi efficaci per la comunicazione proxy - dispositivi
91
4. Progetto logico della soluzione del problema
92
4.1. Reingegnerizzazione dell’agente, reattività e stabilità del sistema
92
4.1.1. Un processo per il monitoraggio del semiagente operativo
93
4.1.2. Reattività laterale (verso l’agenzia) comune a tutti gli agenti
94
4.1.3. Reattività superiore (verso l’interfaccia utente) comune a tutti gli agenti
99
4.1.4. Gestione di più dispositivi per ogni agente
101
4.1.5. Reattività specializzata laterale
102
4.1.6. Reattività specializzata superiore
103
4.1.7. Struttura logica complessiva
103
4.2. Progettazione logica dell’interfaccia device controller - dispositivi
106
4.2.1. LON, una tecnologia adeguata per comunicare con i dispositivi
106
4.2.2. Astrazione dalla tecnologia scelta per la comunicazione con i dispositivi
107
4.2.3. Servizi offerti dall’interfaccia di comunicazione device controller - dispositivi
107
4.2.4. Gestione degli eventi
109
4.2.5. Implementazione del BusControllerInterface per il bus LON
109
4.3. Dettagli implementativi attenti ad alcuni aspetti ergonomici in ambito domotico
114
5. Realizzazioni sperimentali e valutazioni
116
5.1. L’applicazione domotica realizzata
117
5.1.1. Servizi e funzioni
117
5.1.2. Interazione superiore: interfaccia uomo - applicazione domotica
119
5.2. Agenti realizzati
122
5.2.1. Una visione d’insieme degli agenti e dei dispositivi
123
5.2.2. Agente LightAg
127
8
5.2.3. Agente HPresenceDetector
130
5.2.4. Agente WindowAg
133
5.2.5. Agente GoalGenerator
136
5.2.6. Agente Heating
139
5.3. Espansioni e goal realizzati
139
5.3.1. Espansioni per ESOn
139
5.3.1.1. Espansioni per HeatingES
142
5.3.1.2. Espansioni per LightES
143
5.3.2. Espansioni per turnOnLight e turnOffLight
5.4. Prove sperimentali e valutazioni
5.4.1. Operatività e reattività degli agenti
145
147
147
5.4.1.1. LightAg
147
5.4.1.2. WindowAg
148
5.4.1.3. HPresenceDetector
149
5.4.1.4. GoalGenerator
150
5.4.2. Pianificazione ed esecuzione
150
5.4.3. Valutazione funzionale dell’applicazione domotica
152
5.4.4. Valutazione di alcuni tempi di risposta
154
6. Conclusioni e sviluppi futuri
155
A. Standard e tecnologie per la domotica
158
A.1. Mercato europeo
158
A.2. Mercato americano
162
A.3. Mercato giapponese (HBS)
167
A.4. Mercato internazionale
167
Bibliografia
173
9
1
INTRODUZIONE
Le discipline nelle quali si colloca questo lavoro di tesi sono l’intelligenza artificiale e la
domotica; particolare attenzione è data allo studio dei sistemi multiagente e ai principi
proposti dall’ubiquitous computing.
Il termine ubiquitous computing è stato coniato da Mark Weiser nel 1988 [1, 8, 27], il quale
immaginava piccoli elaboratori “sparsi ovunque” nell’ambiente: inseriti nei muri, nei tavoli e
in altri oggetti d’uso quotidiano, cooperanti fra loro ed “invisibili” all’uomo. Oggi non è
ancora possibile realizzare un tale scenario con costi limitati; è però possibile sfruttare
dispositivi sempre più performanti. Nell’ultimo decennio si è assistito ad un’evoluzione della
capacità di elaborazione dei tradizionali personal computer e alla nascita di numerosi
dispositivi elettronici di uso comune, come computer portatili, telefoni cellulari e dispositivi
palmari. Si assiste dunque a una decentralizzazione del rapporto tra l’uomo e la tecnologia
che sembra andare verso la direzione immaginata da Weiser.
Il termine domotica deriva dall’importazione di un neologismo francese: domotique,
originato dalla contrazione di domus e di informatique [49]. La domotica è una disciplina che
si occupa dell’integrazione dei dispositivi elettronici, degli elettrodomestici e dei sistemi di
comunicazione e di controllo che si trovano nelle abitazioni. Le nostre case sono ricche di
dispositivi dotati di unità di elaborazione sempre più evolute; la tendenza negli ultimi anni è
di dotare tali dispositivi anche della capacità di comunicare tra di loro e con il mondo
esterno, grazie anche a efficaci sistemi di comunicazione, cablati e non, disponibili a basso
costo. L’evoluzione della capacità di elaborazione e comunicazione dei dispositivi presenti in
una casa ha permesso la progettazione e la realizzazione di sistemi integrati di automazione
domestica sempre più complessi e utili alla vita dell’uomo nella propria abitazione. Grazie
all’evoluzione tecnologica degli ultimi anni, si assiste ad un tentativo di importare nei sistemi
tradizionali domotici alcuni metodi provenienti dall’intelligenza artificiale e dall’ubiquitous
computing. In una abitazione l’uomo si trova spesso a dover raggiungere obiettivi complessi
il cui raggiungimento necessita di tecniche dell’intelligenza artificiale, come la pianificazione
e il ragionamento inferenziale.
La domotica, integrata con l’intelligenza artificiale e influenzata dai principi
dell’ubiquitous computing, può essere vista come una disciplina che si occupa di realizzare il
mondo immaginato da Weiser all’interno di un’abitazione.
In un precedente progetto di tesi era stato realizzato un sistema multiagente, denominato
AGENZIA AMBIENTALE [3], in grado di soddisfare esigenze d’alto livello sfruttando tecniche
d’intelligenza artificiale come la pianificazione dinamica basata su una conoscenza
distribuita tra diversi agenti. L’AGENZIA AMBIENTALE permette a una serie di dispositivi
eterogenei, incapsulati negli agenti, di coesistere cooperativamente all’interno dello stesso
ambiente e di sfruttare le proprie potenzialità per risolvere esigenze d’alto livello. Per poter
far interagire fra loro agenti eterogenei e non noti a priori, ogni agente è stato pensato come
costituito da due semiagenti: il semiagente cooperativo e il semiagente operativo. Il primo,
comune a tutti gli agenti, permette di realizzare un’interazione uniforme fra gli agenti, il
secondo, permette di realizzare le funzioni specifiche di ogni agente.
L’AGENZIA AMBIENTALE era stata validata solo in simulazione e non era mai stata
utilizzata per realizzare applicazioni reali.
L’obiettivo della mia tesi consiste nell’utilizzare l’AGENZIA AMBIENTALE per realizzare
un’applicazione domotica reale che ne validi l’effettiva capacità di soddisfare esigenze d’alto
livello mediante la cooperazione e la pianificazione basata su una conoscenza distribuita.
Le difficoltà principali incontrate sono dipese dalla non adeguatezza di alcuni moduli
dell’AGENZIA AMBIENTALE per ambienti reali non simulati. Per far fronte a tale difficoltà ho
riprogettato alcune parti dell’AGENZIA AMBIENTALE al fine di renderla adeguata per la
realizzazione di un’applicazione domotica reale.
Prima di procedere all’implementazione dell’applicazione domotica ho analizzato i
meccanismi funzionali degli agenti proposti nell’AGENZIA AMBIENTALE. In particolare mi
sono occupato di verificare l’adeguatezza della logica di comunicazione implementata tra il
semiagente cooperativo e il semiagente operativo. Dall’analisi è emerso che non erano stati
presi in considerazione eventuali problemi di comunicazione tra i due semiagenti. Nel caso di
un sistema domotico reale, far fronte ad eventuali disservizi o malfunzionamenti dei
dispositivi in modo adeguato è un requisito imprescindibile.
12
Per poter rendere l’agente reattivo ai malfunzionamenti ho inserito nel semiagente
cooperativo un processo per il monitoraggio del semiagente operativo specializzabile da ogni
agente secondo le esigenze specifiche.
L’abitazione è popolata da numerosi dispositivi il cui controllo non comporta computazioni
complesse e grossi scambi d’informazione. Sviluppare un agente per ogni dispositivo fisico
di un sistema domotico, come nella visione proposta in [3], comporterebbe un decremento
delle prestazioni dell’intera AGENZIA AMBIENTALE. Ogni agente infatti è da considerarsi un
processo residente in memoria ed eseguito su un elaboratore. La soluzione adottata affinché
un agente possa essere associato a più di un dispositivo è stata quella di considerare il
semiagente operativo costituito fisicamente da anche più dispositivi. Per gestire
l’eterogeneità e i diversi comportamenti di ognuno dei dispositivi ho realizzato un modulo
(device controller) deputato a gestire tutti i dispositivi che compongono il semiagente
operativo. Il device controller, specializzando in modo opportuno il processo introdotto nel
semiagente cooperativo per monitorare il semiagente operativo, è in grado di gestire le
reazioni ai malfunzionamenti in modo specifico per ogni singolo dispositivo appartenente al
semiagente operativo.
Per poter realizzare l’applicazione domotica è stata identificata una tecnologia adeguata per
interfacciarsi con i dispositivi (LONTALK [55]). Per scegliere tale tecnologia ne sono state
analizzate molte fra quelle esistenti sul mercato della domotica ed è stata scelta quella che
potenzialmente è in grado di adattarsi al meglio a tutte le peculiarità dell’AGENZIA
AMBIENTALE.
I dispositivi utilizzati per la realizzazione dell’applicazione domotica comunicano
sfruttando i protocolli messi a disposizione da LONTALK; per permettere la comunicazione
tra i device controller e i dispositivi presenti sulla rete LONTALK, ho implementato
un’interfaccia di comunicazione, tra JAVA (tecnologia sulla quale è implementata l’AGENZIA
AMBIENTALE, tutti i semiagenti cooperativi e tutti i device controller) e LONTALK, in grado di
mettere a disposizione tutti i servizi necessari per poter comunicare con dei dispositivi.
Dopo aver adeguato l’AGENZIA AMBIENTALE a esigenze pratiche e aver progettato
un’interfaccia per permettere la comunicazione con dei dispositivi reali, ho realizzato
l’applicazione domotica dimostrativa. Gli agenti implementati per realizzare tale
applicazione sono: LightAg, deputato al controllo e monitoraggio di un punto luce;
WindowAg, deputato al controllo e monitoraggio di una finestra; HPresenceDetector,
deputato alla rilevazione di presenza umana; GoalGenerator, deputato ad acquisire esigenze
13
d’alto livello che l’uomo intende soddisfare. Inoltre è stato utilizzato un agente (Heating)
realizzato nel progetto di tesi [3] deputato al controllo e monitoraggio di un riscaldamento
(simulato). Con gli agenti appena citati è stato possibile realizzare le seguenti funzionalità
esibite dall’applicazione domotica: monitorare e controllare un punto luce; monitorare e
controllare una finestra; monitorare e controllare il riscaldamento simulato; rilevare presenza
umana. Inoltre, fornendo la conoscenza necessaria e sfruttando la capacità di pianificare in
modo dinamico dell’AGENZIA AMBIENTALE, l’applicazione che ho realizzato è in grado di far
cooperare tutti i dispositivi (e gli agenti) realmente disponibili al fine di poter risparmiare
energia.
I risultati raggiunti permettono di affermare che tutte le modifiche da me apportate
all’AGENZIA AMBIENTALE permettono di realizzare un adeguato comportamento nel caso di
malfunzionamenti o di cambiamento delle condizioni operative. Inoltre, l’interfaccia
realizzata per la comunicazione fra il device controller e i dispositivi si è rivelata efficace
anche se non molto efficiente. Infine, l’applicazione domotica realizzata ha validato le
seguenti peculiarità dell’AGENZIA AMBIENTALE: la capacità di far coesistere e cooperare
nello stesso ambiente diversi agenti e dispositivi eterogenei; la capacità di pianificare
dinamicamente delle soluzioni, dipendenti dai servizi presenti in un dato istante nell’agenzia,
per soddisfare delle esigenze d’alto livello. Dalle prove pratiche effettuate sull’applicazione
domotica realizzata è stata riscontrata che, se in fase di pianificazione di una soluzione
avvengono dei cambiamenti delle condizioni operative, l’AGENZIA AMBIENTALE diventa
instabile e non più in grado di funzionare correttamente.
La realizzazione pratica dell’applicazione domotica, con tecnologie e dispositivi reali, è
stata possibile grazie ai mezzi messi a disposizione dall’azienda svizzera TECHSELESTA [77]
nell’ambito di uno stage. Il positivo rapporto di collaborazione con alcuni progettisti della
TECHSELESTA è stato determinante. Mi è stato fornito un supporto significativo per
l’installazione e l’utilizzo della tecnologia LONTALK e l’interconnessione di tutti i dispositivi
utilizzati per la sperimentazione dell’applicazione domotica.
Descrivo ora la struttura della tesi.
Il Capitolo 2 riguarda lo stato dell’arte e tratta di ubiquitous computing, di domotica e della
relazione che intercorre tra le due discipline.
Per ciò che riguarda l’ubiquitous computing sono evidenziati i requisiti non funzionali che
lo caratterizzano come: l’ubiquità, la pervasività, l’interfaccia trasparente e la reattività e
14
pro-attività per l’adattamento al conteso. Sono elencati i campi applicativi che maggiormente
potranno trarre vantaggio dall’ubiquitous computing come: augmented reality [5], wearable
computing [70] e smart room [47], questo ultimo è il campo che più si avvicina alla
domotica. Inoltre è presentata una breve storia del mondo informatico per poter meglio
inquadrare il ruolo che potrà avere in futuro l’ubiquitous computing.
Per la domotica è presentata una breve introduzione, sono elencati gli ambiti applicativi di
tale disciplina ed è evidenziata la stretta relazione tra i requisiti espressi per l’ubiquitous
computing e quelli relativi alla domotica. Inoltre è illustrata una panoramica delle tecnologie
esistenti sul mercato della domotica ed è proposta una trattazione comparativa tra le
caratteristiche principali di tali tecnologie.
Il Capitolo 3 si occupa di impostare il problema di ricerca. In particolare viene fornita una
presentazione della preesistente AGENZIA AMBIENTALE. Successivamente sono illustrate delle
problematiche specifiche per la realizzazione pratica di un applicazione domotica. Infine
sono analizzate le problematiche relative alla progettazione di un’interfaccia di
comunicazione tra le parti degli agenti realizzate in JAVA e quelle realizzate con eventuali
altre tecnologie che sia adeguata per l’AGENZIA AMBIENTALE.
Il Capitolo 4 si occupa di presentare il progetto logico per una soluzione del problema
posto nel Capitolo 3. In particolare sono descritte tutte le modifiche apportate all’AGENZIA
AMBIENTALE al fine di poterla utilizzare per la realizzazione di un’applicazione domotica
reale. Successivamente sono presentate le soluzioni logiche adottate per permettere
un’efficace comunicazione tra il device controller, implementato in Java, e i dispositivi
connessi con tecnologia LONTALK. Relativamente a questa interfaccia sono evidenziate le
scelte progettuali di carattere generale relative all’interoperabilità tra tecnologie differenti e
le scelte progettuali specifiche per l’impiego di LONTALK con l’AGENZIA AMBIENTALE.
Nel Capitolo 5 è descritta la struttura e il funzionamento dell’applicazione domotica
realizzata. Sono descritte le prove sperimentali effettuate e sono evidenziate delle valutazioni
relative all’AGENZIA AMBIENTALE e all’applicazione domotica.
Il Capitolo 6 è costituito dalle conclusioni. Sono valutati i risultati complessivi ottenuti con
l’intero progetto e sono proposti possibili sviluppi futuri.
Nell’Appendice A sono riportati alcuni dettagli tecnologici delle tecnologie presenti sul
mercato della domotica e prese in considerazione nello stato dell’arte.
15
2
STATO DELL’ARTE
L’obiettivo della tesi consiste nella realizzazione pratica di un applicazione d’ubiquitous
computing con tecniche d’intelligenza artificiale in ambito domotico. In questo capitolo
verranno poste le basi teoriche e concettuali che hanno permesso il conseguimento di tale
obiettivo. Verranno esposte le principali caratteristiche dell’ubiquitous computing e verrà
proposto un parallelo con la disciplina della domotica. Saranno elencati gli ambiti applicativi
della domotica e verrà fatta una panoramica delle tecnologie esistenti per tale disciplina.
Infine proporrò una trattazione comparativa tra le caratteristiche principali delle tecnologie
esistenti e realmente utilizzate per la realizzazione di sistemi domotici.
2.1 Ubiquitous computing
Mark Weiser (1952-1999) nel 1988 [1, 8, 27, 28], mentre faceva ricerche in qualità di
direttore del centro di ricerca Xerox Parc a Palo Alto in California, ebbe la visione che nel
XXI secolo la rivoluzione tecnologica sarebbe entrata nel quotidiano, nel piccolo e
nell’invisibile. Fu lui che coniò il termine ubiquitous computing. Il suo motto era: “Attiviamo
il mondo”, nel senso di renderlo attivo ed intelligente. Il computer troppo spesso è il punto
focale della nostra attenzione, secondo Mark Weiser, e questo vale anche per il personal
computing includendo i palmari o altri tipi di terminali. La sfida è dunque quella di eliminare
i computer creando un nuovo rapporto fra persone e computer, progettando dei computer
migliori che se ne possano stare in disparte, in modo che le persone possano seguire il loro
quotidiano, una visione totalmente uomo centrica. Per Weiser la tecnologia, che avrebbe
dovuto stare sullo sfondo in modo invisibile, era in sostanza un puro mezzo per raggiungere
uno scopo, ossia permettere di concentrarsi sui fatti. Weiser spiega come la tecnologia possa
sparire nello sfondo (rimanere in background) scrivendo [8]: “un’officina conteneva un solo
motore elettrico che attraverso cinghie ed alberi azionava decine se non centinaia di
macchine diverse. Motori elettrici economici ed efficienti hanno reso possibile dapprima di
mettere un motore per macchina, successivamente molti piccoli motori in ogni macchina.
Una moderna automobile contiene, spesso senza nemmeno che ce ne accorgiamo, oltre 20
motori elettrici ed altrettanti solenoidi. Oggi quando facciamo partire il motore principale di
un auto, partono, senza neanche che ce ne accorgiamo, anche il motorino per il tergicristalli,
quello per l’apertura e la chiusura delle porte ed altri. Facendo una dovuta attenzione è
possibile sapere quando i diversi motori di un automobile si attivano ma non vi è la necessità
di attivarli in modo esplicito”.
Weiser continua poi con una breve analisi della situazione attuale (1991) scrivendo: “già
ora microprocessori in interruttori, termostati, impianti stereo, forni contribuiscono ad
attivare il mondo. Queste macchine e molte altre saranno interconnesse costituendo una rete
ubiqua "[1]. Con il termine ubiquitous voleva intendere dunque che l’elaborazione non
sarebbe più stata concentrata all’interno di un elaboratore, ma si sarebbe spostata “ovunque”,
in modo pervasivo nell’ambiente. Pervasive computing è infatti un altro dei termini ricorrenti
in letteratura per descrivere ciò che Weiser aveva immaginato [1, 2, 3, 4, 15].
Sebbene il termine ubiquitous computing è frequentemente utilizzato in letteratura,
domande come: cos’è l’ubiquitous computing o come possono essere descritti i sistemi di
ubiquitous computing, trovano difficile risposta. Molti lavori riportano il termine Ubiquitous
Computing ma nessuno, di quelli da me analizzati, si occupa di dare una trattazione teorica o
una tassonomia ben precisa in merito. L’ubiquitous computing non sembra essere
riconducibile a nessun campo di ricerca scientifico particolare, ma sembra rappresentare per
ora solo una sfida o un sogno di diversi ambiti scientifici e non. Parlare in modo preciso,
tecnico e scientifico di ubiquitous computing è molto complicato e aleatorio.
Anche se ubiquitous computing non ha una precisa connotazione nel campo scientifico
tecnologico, in sociologia esiste una precisa idea condivisa sull’ubiquitous computing:
l’uomo interagirà con una quantità di dispositivi sempre maggiore, ubicati ovunque e tutti
interconnessi [15, 29], cambiando il rapporto uomo – macchina, le abitudini individuali e
collettive profondamente [29].
Vista la non esistenza di una teoria precisa e consolidata in letteratura scientifica
tecnologica in merito all’ubiquitous computing, nel seguito della trattazione ho scelto di non
tentare di dare una definizione scientifica unica di cosa sia l’ubiquitous computing. Cercherò
invece di fissare alcuni concetti ricorrenti in letteratura che ci possano far ricondurre
un’applicazione ad una di ubiquitous computing più o meno di altre, senza la pretesa di
fornire quindi una categorizzazione certa e ben delineata. Nello specifico inizierò con
17
un’analisi delle evoluzione storica della tecnologia e del rapporto tra l’uomo e gli elaboratori
negli ultimi decenni contestualizzando l’ubiquitous computing in un’evoluzione storica della
tecnologia (Sezione 2.1.1). Seguirà un’elencazione delle peculiarità e requisiti ricorrenti in
letteratura relativi all’ubiquitous computing (Sezione 2.1.2). Concluderò questa sezione
descrivendo i componenti di un’architettura di ubiquitous computing e come questi possono
essere organizzati (Sezione 2.1.3).
2.1.1 Introduzione storica
Anche se una definizione certa e precisa relativa all’ubiquitous computing non sembra
essere possibile, resta la certezza che l’evolversi del rapporto tra l’uomo e gli elaboratori e il
progresso della tecnologia (su tutti i livelli) stia permettendo la diffusione di un sempre più
crescente numero di elaboratori, sempre più piccoli e sempre più specifici, tutti interconnessi
fra loro [3, 29], così come nella visione di Weiser quando coniò il termine ubiquitous
computing. Inizialmente i mainframe (grossi elaboratori che gestiscono sistemi centralizzati
[65]) rappresentavano l’era di tante persone-un elaboratore; il personal computer l’era di una
persona-un elaboratore. Internet e i sistemi d’interconnessione moderni in genere ci stanno
traghettando verso un’era la cui caratteristica sarà quella dell’elaborazione massicciamente
distribuita, quella dell’ubiquitous computing: l’era di una persona- tanti elaboratori [6, 66].
Mainframe
Molte persone condividono lo stesso elaboratore
Personal computer
Un elaboratore per ogni persona
Internet e reti telematiche
Una persona alcuni elaboratori
Ubiquitous computing
Una persona tanti elaboratori
Tabella 2.1 Evoluzione storia dell’utilizzo degli elaboratori
L’impatto sociale che potrà avere l’ubiquitous computing può essere paragonato a quello
avuto da altre due tecnologie che pervadono il nostro ambiente e sono ubicate ovunque nel
nostro vivere comune. La prima è la scrittura che può essere trovata ovunque, dalle etichette
sui vestiti ai grandi manifesti. La seconda è l’elettricità che scorre invisibile attraverso i muri
d’ogni casa o ufficio e nelle automobili. La scrittura e l’elettricità sono divenute così
18
integrate nella vita di tutti i giorni che spesso ci si dimentica dell’impatto che hanno avuto e
che hanno sulla vita quotidiana di tutti.
Le Fig. 2.1 e la Fig. 2.2 mostrano rispettivamente il numero di dispositivi elettronici
venduti e gli investimenti nella ricerca (in miliardi di dollari) negli ultimi decenni e le
previsioni per il futuro prossimo (negli USA) [3, 6].
Figura 2.1 Numero dei dispositivi elettronici venduti negli USA negli ultimi anni
Figura 2.2 Investimenti nella ricerca (in miliardi di dollari) negli USA negli ultimi
settanta anni
19
2.1.2 Caratteristiche e peculiarità dell’ubiquitous computing
Con l’affermarsi dell’ubiquitous computing, la potenza elaborativa si sposta dal
tradizionale desktop all’ambiente circostante. Questo introduce nuove difficoltà su tutti i
macro livelli di un sistema tecnologico, dall’hardware fino al software. Tali difficoltà
derivano soprattutto dal fatto che un’applicazione di ubiquitous computing, differentemente
da un’applicazione tradizionale, è soggetta ad un utilizzo più intensivo, meno prevedibile,
non sempre fisicamente localizzabile e difficilmente programmabile.
Mark Weiser nelle sue prime trattazioni sull’argomento suggerì anche alcuni criteri che ogni
applicazione di ubiquitous computing deve rispettare.
•
Scalabilità: il sistema costruito deve possedere un concetto di scalabilità, intesa
come capacità di aumentare, col passare del tempo, il numero di entità coinvolte,
lo spazio coperto, la varietà dei dispositivi utilizzati senza compromettere la
funzionalità dell’intero sistema.
•
Uso continuato: il sistema deve essere soggetto ogni giorno ad un utilizzo
intenso. Ciò comporta, in alcuni casi, il sopraggiungere di problematiche tipiche
dei sistemi operanti in tempo reale.
•
Valutabilità: l’uso del sistema deve poter essere valutato per determinare il suo
impatto sulla comunità. Deve essere possibile avere una valutazione da parte degli
utenti del sistema, positiva o negativa che sia.
Nella precedente sezione ho descritto cosa immaginava Weiser e quale sembra essere la
tendenza di crescita dell’ubiquitous computing nei prossimi anni. Di seguito cercherò di
descrivere i requisiti che un sistema di ubiquitous computing deve avere per poter realizzare
il sogno immaginato da Weiser e per poter rispettare i criteri da lui suggeriti relativi a sistemi
di ubiquitous computing.
Quelle che verranno trattate saranno delle linee guida relative ai requisiti per un sistema di
ubiquitous computing. Mi disinteresserò di requisiti specifici di un’applicazione (requisiti
funzionali) ma concentrerò la trattazione su requisiti non funzionali. Questi ultimi
identificano le proprietà che un sistema di ubiquitous computing deve avere o meglio, i
vincoli che dovranno essere presi in considerazione nel processo di sviluppo di un sistema di
ubiquitous computing [32]. In accordo con ciò ho definito un gruppo eterogeneo di requisiti
20
non funzionali (molti di loro possono essere trovati in [31]). Ogni singolo requisito può
coinvolgere diversi aspetti ed il suo raggiungimento può influenzare numerose proprietà del
sistema.
Ho diviso i requisiti non funzionali in due classi, quelli fortemente caratterizzanti e tipici di
un sistema di ubiquitous computing e quelli invece comuni anche ad altri sistemi.
Definizione di requisiti non funzionali specifici dell’ubiquitous computing
Vengono riportati di seguito, in ordine alfabetico, i requisiti non funzionali tipici di un
sistema di ubiquitous computing
•
Adattabile. Deve essere flessibile e autonomo in risposta ai cambiamenti delle
richieste dell’utente e delle condizioni operative [31]. Il sistema deve essere in grado
di adattarsi ad esempio a numerosi cambiamenti relativi a mutamenti della topologia
della rete e del contesto corrente. Il contesto corrente può riguardare informazioni
relative alle risorse fisiche disponibili, informazioni relative all’utente e all’ambiente,
ecc. Per raggiungere il requisito di adattabilità il sistema dovrà essere in grado di
gestire un alto grado di eterogeneità, visto il grande numero di dispositivi, ambienti e
tecnologie differenti che compongono un sistema di ubiquitous computing [15].
•
Eterno. Non deve mai arrestarsi, spegnersi o essere riavviato; l’intero sistema deve
essere disponibile in qualsiasi momento [22]. Inoltre il sistema deve garantire la
persistenza dei dati e tolleranza ai guasti.
•
Integrato (embedded). Deve essere inserito come parte integrante del nostro mondo
sentendo ed agendo [22, 29]. Il sistema deve essere integrato in ogni entità
dell’ambiente.
•
Intenzionale. Le persone devono essere in grado di formulare richieste esprimendo
delle intenzioni e nominando degli oggetti o delle funzioni. Ad esempio la richiesta di
stampa dalla stampante più vicina esprime un’intenzione che il sistema deve essere in
grado di interpretare anche senza un esplicito riferimento all’indirizzo fisico della
stampante.
•
Nomadico. Deve permettere agli utenti e a qualsiasi dispositivo di potersi muovere
liberamente secondo le necessità [31, 80, 81]. La nomadicità è riferita quindi sia
all’utente che alla computazione. La nomadicità riguarda due aspetti: mobilità fisica,
21
consente spostamenti da un posto ad un altro di dispositivi e utenti; mobilità logica,
consente spostamenti da un sottosistema computazionale ad un altro.
•
Pervasivo. Deve essere ovunque [22], i componenti di un sistema di ubiquitous
computing pervadono qualsiasi entità che può interagire con l’uomo, con l’ambiente o
con altre entità. Questo requisito riguarda principalmente la possibilità per gli
utilizzatori (dove per utilizzatori si intende qualsiasi entità che utilizza il sistema e
formula richieste, quindi sia persone che dispositivi) di accedere ovunque al sistema
con consistenza informativa [15].
•
Pro-attivo. Deve avere degli obiettivi o un insieme di obiettivi e deve cercare di
raggiungerli anche senza una guida esplicita da parte del fruitore di tali obiettivi (altri
sottosistemi o gli uomini). Alcuni obiettivi possono essere generati autonomamente
dal sistema di ubiquitous computing o direttamente dagli utilizzatori [57].
•
Reattivo. Deve essere in grado di reagire a specifici eventi. Gli eventi possono essere
di diversi tipi, come il cambiamento di un particolare contesto, variazione delle
risorse disponibili, la terminazione di un compito ecc. [15]. La reattività è un requisito
basilare per permettere l’adattabilità [9].
•
Scalabile. Come espresso in precedenza nei requisiti desiderati per un sistema di
ubiquitous computing secondo Weiser, la scalabilità è intesa come capacità di
aumentare il numero di entità coinvolte, lo spazio coperto, la varietà dei dispositivi
utilizzati senza compromettere la funzionalità dell’intero sistema. Inoltre il sistema
deve essere in grado di supportare un accrescimento dimensionale logico, riferito
all’accrescimento delle applicazioni e delle loro funzioni, aumento quindi della
complessità computazionale e funzionale.
•
Tempo Reale (real time). Un sistema è definito real time se è in grado di elaborare
con un tempo di risposta trascurabile, cioè in tempo utile per non compromettere
eventuali azioni successive dipendenti dai risultati precedentemente elaborati [15]
•
Trasparente. La trasparenza si rifà al concetto espresso da Weiser per cui la
tecnologia deve essere in grado di stare sullo sfondo. In un sistema trasparente gli
utenti finali non percepiscono il mezzo tecnologico che stanno utilizzando per il
conseguimento dei propri obiettivi [6]. Il concetto di trasparenza si riflette soprattutto
sui requisiti delle interfacce di comunicazione di un sistema di ubiquitous computing
come vedremo in seguito nella Sezione 2.1.3.1.
22
Definizione di requisiti non funzionali non specifici dell’ubiquitous computing
Per completezza della trattazione cito soltanto, senza entrare nei dettagli, i requisiti non
funzionali tipici di un sistema di ubiquitous computing ma comuni anche ad altri sistemi
informatici provenienti dalla letteratura di ingegneria del software [42]. Tali requisiti sono:
efficienza [31]; mantenibilità [82]; riusabilità [82]; sicurezza [82]
2.1.3 Architetture per l’ubiquitous computing
Un generico sistema di ubiquitous computing interessa un largo numero di aspetti, sia
hardware che software, che può essere organizzato in un’architettura multistrato. Lo scopo di
questa decomposizione funzionale è di ottenere un numero di livelli architetturali
indipendenti, ognuno dei quali può essere adottato per comporre l’intera architettura di un
sistema di ubiquitous computing. In questa prospettiva cercherò di dare ad ogni livello la sua
natura, proprietà e caratteristica al fine di identificare delle scatole nere (black box) per gli
altri livelli. Tale scopo non sarà possibile ottenerlo completamente, infatti i livelli che andrò a
descrivere sono in parte dipendenti. In particolare alcune tecnologie adottate in un livello
finiscono per influenzare alcune scelte progettuali di altri livelli.
I livelli che sono riuscito ad identificare dall’analisi della letteratura sono cinque e
riguardano discipline di ricerca eterogenee, tale suddivisione può essere utile
all’identificazione della relativa disciplina per ogni livello.
Nella trattazione multi livello che seguirà si porteranno esempi di sistemi, tecnologie e
progetti esistenti in letteratura in relazione al livello trattato.
I livelli identificati sono i seguenti.
•
Interfaccia
•
Applicativo
•
Middleware
•
Comunicazione
•
Dispositivi
23
2.1.3.1 Interfaccia
Il livello dell’interfaccia è rappresentato ed è costituito da tutte le risorse hardware e
software dedite alla comunicazione tra l’uomo ed il sistema di ubiquitous computing [4].
Weiser [1, 2, 4, 8] oltre ad aver ipotizzato una computazione ubiqua e pervasiva aveva
immaginato anche che il rapporto tra uomo e la macchina dovesse cambiare, non solo dal
punto di vista quantitativo ma anche in modo qualitativo. Non è più l’uomo che si deve
adattare all’interfaccia delle macchine ma anzi le macchine devono essere in grado di fornire
un’interfaccia il più vicino possibile ai modi di comunicare dell’essere umano. Immaginare
un interfaccia classica con tastiera, mouse, monitor, scanner ecc. per un numero elevato di
elaboratori sparsi ovunque nell’ambiente è sicuramente un’idea non praticabile e sicuramente
risulterebbe troppo intrusiva ed inaccettabile. Le parole d’ordine in letteratura per
un’interfaccia di un sistema di ubiquitous computing sono dunque trasparenza e non
intrusività [4, 8, 9, 10, 11].
Con il concetto d’interfaccia trasparente si intende un nuovo insieme di tecniche e di
strumenti che permettono di interagire in modo poco intrusivo con l’ambiente circostante.
Una buona interfaccia trasparente è un’interfaccia che non è intrusiva per la nostra coscienza,
un paio di occhiali ad esempio è uno strumento che ci fa guardare il mondo e non gli occhiali
stessi [6]. Le interfacce devono essere progettate dunque adattandosi al modo con cui
tipicamente opera l’uomo. Interagire in modo trasparente significa che la persona, mentre si
trova nell’ambiente, può continuare ad agire come se nessun elaboratore fosse presente; sarà
compito di questi ultimi assecondare nel miglior modo possibile la persona.
In un’interazione uomo - uomo la gran parte delle informazioni è scambiata senza l’ausilio
delle parole, ma utilizzando molteplici mezzi di comunicazione d’altra natura. Questo
insieme di suggerimenti condivisi fra più persone, il contesto, aiuta a migliorare la qualità
dell’interazione fra i partecipanti.
Possiamo quindi identificare come contesto ogni sorta di informazione che permette di
caratterizzare la situazione di un’entità, dove per entità si può intendere una persona, un
luogo, un oggetto fisico o un dispositivo elettronico [12, 33].
Un’interfaccia trasparente dovrà per forza di cose essere sensibile al contesto al fine di
avvicinarsi quanto più possibile allo stile comunicativo umano. Adattarsi al contesto, pur
essendo importante anche nelle applicazioni tradizionali, assume un ruolo fondamentale
quando i sistemi sono distribuiti e mobili, dove gli elaboratori non solo si possono spostare
24
all’interno di un ambiente, ma addirittura possono cambiarlo, modificando di conseuenza
l’intero contesto.
Per fare in modo che un sistema di ubiquitous computing sia in grado di adattare il proprio
comportamento ai cambiamenti di contesto, è necessario in primo luogo che sia in grado di
percepirlo. Un uomo percepisce il contesto utilizzando i propri sensi, con in quali è in grado
di sentire ciò che lo circonda; allo stesso modo un’applicazione, se vuole “sentire” ciò che
c’è nello spazio circostante, deve essere dotata di particolari dispositivi, detti sensori.
Un ‘interfaccia di un sistema di ubiquitous computing deve essere in grado di interagire
con tutti gli strumenti in grado di rilevare il contesto messogli a disposizione dai sotto livelli
dell’intera architettura di un sistema di ubiquitous computing. Questo tipo di comunicazione
contestuale in letteratura va sotto il nome di context-awareness. Si è ancora lontani dal creare
vere e proprie interfacce o applicazioni context-aware, ma analizzando quelle che sono state
realizzate fino ad oggi [34], si nota come le informazioni relative al contesto realmente
utilizzate sono veramente poche rispetto all’enorme quantità di altre informazioni che
potrebbero essere trattate. In genere, l’uso del contesto è limitato solo all’identificazione ed
alla localizzazione. Di notevole interesse sono progetti prototipati, se pur non ancora ben
funzionanti, di interfacce in grado di effettuare un riconoscimento gestuale, cogliendo cioè
dai gesti di una persona l’informazione sottesa come quella rappresentata ad esempio dal
movimento degli arti o dei muscoli facciali [1, 10].
Anche l’analisi della scrittura manuale è sicuramente un tipo d’interfaccia per l’ubiquitous
computing, infatti la scrittura manuale fa perdere la percezione e la coscienza di trovarsi
davanti ad un elaboratore [6, 10].
Sempre nel dominio del riconoscimento dei metodi d’espressione classici dell’uomo, un
ampio campo di ricerca è quello relativo al riconoscimento vocale, poter comunicare con la
voce senza nemmeno vedere l’elaboratore conferisce all’interfaccia le caratteristiche di
trasparenza e facilità d’uso e spontaneità, essenziali per un sistema di ubiquitous computing
[10].
Un’altra strada che si sta percorrendo per far comunicare l’uomo e le macchine in modo più
trasparente possibile è quello di immergere sensori nei dispositivi d’uso comune. Un esempio
di progetto in tal senso è dato da un esperimento dell’università di Karlsruhe: MEDIACUP
(Fig. 2.3) [1], che ha lo scopo di capire le opportunità provenienti dalla presenza di
apparecchi digitali negli oggetti di tutti i giorni.
25
Una tipologia d’interfacce che sta prendendo sempre più piede, nei sistemi di ubiquitous
computing e nei sistemi ad alta interazione con l’uomo, sono le interfacce multimodali e
multicanale. Un’interfaccia multimodale è in grado di percepire la stessa informazione o la
stessa intenzione di dialogo da più sorgenti differenti, un’interfaccia multicanale fornisce
all’utente la possibilità di scegliere tra diversi canali di comunicazione per dialogare con il
sistema [14].
Figura 2.3 MEDIACUP, una tazza di sensori e connessione senza fili.
2.1.3.2 Applicativo
Il livello applicativo è quello che utilizza ed elabora le informazioni provenienti dal livello
superiore (interfaccia del sistema) e dai livelli inferiori (middleware, comunicazione e
dispositivi) al fine di raggiungere lo scopo applicativo per il quale è stato progettato. E’
difficile fare una trattazione generale in merito ai caratteri distintivi del livello applicativo di
un’architettura adeguata ad un sistema di ubiquitous computing, infatti le applicazioni sono
progettate secondo gli obiettivi di volta in volta fissati e possono essere estremamente
eterogenee in natura ed obiettivi.
Non è scopo di questa sezione fare dunque una trattazione completa di tutte le possibili
applicazioni assimilabili al concetto di ubiquitous computing, anche perchè probabilmente
non sarebbe possibile essere esaustivi. Trovo invece interessante descrivere i campi di ricerca
26
e disciplinari sui quali le applicazioni di ubiquitous computing possono assumere
un’importanza rilevante. I campi e le aree interessate maggiormente, secondo me, dal
concetto e l’idea di ubiquitous computing sono:
•
realtà aumentata (augmented reality)
•
smart room
•
computazione indossabile (wearable computing)
Realtà aumentata
La realtà aumentata è un’area in forte crescita nata all’interno del settore della realtà
virtuale (VR). La tendenza attuale è quella di un distaccamento netto tra realtà aumentata e
virtuale, le due aree infatti impiegano spesso concetti e modellizzazioni in antitesi fra loro
[13]. L’ubiquitous computing è messo in relazione con la realtà aumentata e viene
considerato da molti e dal padre fondatore (Weiser) l’esatto opposto della realtà virtuale.
Weiser infatti scrisse : “la realtà virtuale mette le persone nel mondo generato dal computer,
mentre l’ubiquitous computing forza il computer a vivere nel mondo delle persone” [5]. La
tecnologia e la virtualità sono “incarnate” nella realtà (embodied virtuality), gli elaboratori
pervasivi ed ubiqui diventano in un certo qual senso la realtà quotidiana [8]. Alcuni, in linea
con le linee tracciate da Weiser, criticano apertamente la realtà virtuale contestandogli il fatto
che focalizza una enormità di risorse per simulare il mondo invece di migliorare il mondo in
modo invisibile e trasparente come cerca di fare invece l’ubiquitous computing [8]. Nella
Fig. 2.4 [4] si trovano degli schizzi di Weiser che enfatizzano la differenza tra virtual reality
e embodied virtuality (ubiquitous computing).
Il mondo che ci circonda fornisce una moltitudine d’informazioni che sono difficili e
talvolta impossibili da replicare con un computer; è facile rendersene conto, osservando
quanto poco dettagliati sono gli ambienti virtuali creati al computer.
Un sistema basato sull’augmented reality (AR) genera all’utente una vista composita, una
combinazione di percezioni reali osservate dall’utente e di scene e dati virtuali generate al
computer, che quindi “aumentano” la scena reale, la arricchiscono, con informazioni
addizionali. Numerosi sono i possibili campi di utilizzo di applicazioni che permettono agli
utenti di migliorare le loro capacità di percepire il mondo circostante. Il fine ultimo è quello
di creare un sistema che non permetta ai suoi utilizzatori di rendersi conto che stanno
osservando una scena composita.
27
Figura 2.4 Un parallelo schematico di Weiser tra virtual reality ed embodied virtuality
Il computer che genera oggetti virtuali deve essere quindi in grado di calibrarli e proporli
adeguatamente insieme al mondo reale. Errori compiuti in questa fase impediscono all’utente
di percepire la fusione tra reale e virtuale in modo naturale.
Milgram [27, 28] ha proposto una tassonomia (Fig. 2.5) che descrive come la realtà
aumentata e la realtà virtuale possono essere messe in relazione ma come esse stiano agli
antipodi dal punto di vista concettuale.
Il mondo reale e la realtà completamente virtuale sono gli estremi di questo schema, mentre
le regioni di mezzo prendono il nome di mixed reality. La realtà aumentata si pone nelle
vicinanze del mondo reale, con una predominanza di percezioni provenienti dal mondo reale,
aumentata da dati generati dal computer. Augmented virtuality è il duale creato da Milgram
28
per identificare un sistema nel quale si ha una predominanza di scene virtuali con l’aggiunta
di informazioni percepite direttamente dal reale.
Mixed Reality (MR)
Real
Environment
Augmented
Reality (AR)
Augmented
Virtuality (AV)
Virtual
Environment
Figura 2.5 Tassonomia sulla realtà virtuale proposta da Milgram
La realtà aumentata è quella che più fa rimanere nello sfondo la tecnologia, avvicinandosi
all’idea sottesa al concetto di ubiquitous computing, in cui la percezione dell’interazione con
degli elaboratori deve essere il più trasparente possibile, arricchendo l’ambiente senza che
l’utente percepisca cambiamenti. La diffusione quantitativa e qualitativa nell’ambiente di
dispositivi ubiqui può essere sfruttata ad esempio per generare immagini aumentate [36].
Di seguito riporto alcuni possibili campi d’impiego dell’AR.
•
Medico: la medicina negli ultimi anni ha fatto sempre maggiore affidamento alla
computer grafica (Fig. 2.6); non stupisce quindi che uno dei maggiori domini
applicativi della realtà aumentata sia proprio in campo medico.
Figura 2.6 Immagine aumentata per applicazioni mediche
29
Un chirurgo può, ad esempio, sfruttare scansioni fatte precedentemente sul corpo di
un paziente e utilizzarle in sala operatoria durante un intervento [67, 68].
•
Intrattenimento: gli effetti speciali utilizzati nei film impiegano tecniche digitali per
creare illusioni. Un film non può essere considerato realtà dunque secondo me è
improprio parlare di realtà aumentata, ma la scena di un film arricchita con immagini
elaborate al computer viene comunque considerata realtà aumentata, io la chiamerei
finzione aumentata. Lavori a tale riguardo sono stati svolti da Schmidt [69].
•
Militare: i militari utilizzano particolari visori, all’interno degli abitacoli degli aerei o
direttamente indossati dai piloti, che permettono a questi ultimi di avere maggiori
informazioni su ciò che sta avvenendo, senza che siano obbligati a guardare
direttamente la strumentazione di bordo.
•
Progetto tecnico: immaginiamo che un gruppo di progettisti stia lavorando al
modello di un complesso dispositivo per alcuni loro clienti. Sia i progettisti che i
clienti trarrebbero notevoli vantaggi avendo una rappresentazione reale e
tridimensionale di ciò che stanno progettando. Questo diventa possibile se ci si trova
in una stanza equipaggiata con i display della AR. I clienti sarebbero in grado di
visionare il dispositivo estruso in tre dimensioni dagli strumenti di AR e riuscirebbero
a prendere coscienza dei volumi progettati e dei materiali utilizzati. L’AR in questo
caso aumenta la realtà del progetto proponendo un’ulteriore rappresentazione grafica
rispetto a quella bidimensionale proposta dai progettisti con il classico utilizzo di
strumenti rappresentativi come planimetrie, prospetti, sezioni e foto di materiali
possibili.
•
Robotica e telerobotica: nell’ambito della telerobotica un sistema di realtà aumentata
può assistere gli utilizzatori del sistema. L’operatore può utilizzare un’immagine
virtuale dello spazio operativo del robot per guidano più facilmente [70].
Smart room
I computer sono comunemente utilizzati per operazioni prettamente elaborative, come la
lettura di e-mail, la scrittura di testi, ecc. Le persone però utilizzano la maggioranza del loro
tempo in attività che non richiedono l’utilizzo dei classici elaboratori, ad esempio leggono
libri, mangiano e fanno altre attività. Gli uomini trascorrono il loro tempo immersi nel mondo
reale, facendo attività che non richiedono l’uso di un computer. A questo proposito è
possibile riprendere una frase di Coen [8]: “il valore di un computer decresce con il quadrato
30
della distanza dal suo monitor”. Quanto appena detto permette di introdurre l’idea degli
ambienti intelligenti.
Il concetto di smart room è quello che probabilmente maggiormente si affianca a quello
dell’ubiquitous computing e al concetto di domotica come vedremo nelle sezioni successive.
Le moderne interazioni uomo-computer sono implicitamente basate sull’idea di addestrare
l’uomo all’utilizzo delle macchine. Possiamo vederlo nelle tradizionali interfacce WIMP
(window, icon, mouse, pointer) o nelle più immersive applicazioni di realtà virtuale. In
entrambi i casi la persona che vuole usufruire di tali mezzi deve adeguarsi al funzionamento
dell’elaboratore e manipolare oggetti di un mondo artificiale. Il computer non ha
consapevolezza di cosa sia una persona, non ne possiede un modello e non può comprendere
ciò che realmente un uomo vuole fare.
Nelle stanze intelligenti si cerca di invertire questa relazione fra persona e computer. Nelle
smart room, infatti, le persone lavorano insieme o da sole, come se i computer non fossero
presenti: non ci sono tastiere, mouse, monitor o altri dispositivi tradizionali. I computer sono
concepiti al di fuori del mondo delle persone e sono forzati ad operare lì, ascoltando ciò che
la gente dice, osservando ciò che si fa, tenendo traccia di ciò che avviene e cercando di essere
utili quando c’è qualcosa che ritengono di poter fare. Tutto questo è possibile utilizzando
tecniche sviluppate negli ultimi decenni in campo robotico, nel riconoscimento del
linguaggio naturale, nel riconoscimento vocale e nella computer grafica.
L’intento è quello di creare computer “pronti all’uso”, cioè con la capacità di non aver
bisogno d’alcuna interazione umana per poter funzionare.
Per ciò che riguarda l’ambiente in cui le smart room devono essere realizzate, esistono due
diverse correnti di pensiero. La prima prevede ambienti strutturati appositamente per
contenere i vari dispositivi necessari, ciò significa che i vari computer dispongono di
informazioni riguardanti il contesto in cui si trovano: dimensione della stanza, posizione di
oggetti fissi, ecc. La seconda corrente di pensiero prevede invece che i computer debbano
adeguarsi a qualsiasi ambiente ed eventualmente, quando necessario, ricavare direttamente da
esso le informazioni sul contesto che servono. Il secondo approccio è sicuramente più
auspicabile, secondo me, in quanto permette l’installazione di una smart room in un qualsiasi
ambiente. È da sottolineare, però, la maggior complessità realizzativa, che ne limita la
performance rispetto al primo approccio.
Un importante impiego delle smart room che sta sollevando un notevole interesse è
l’adattamento di case per persone disabili [47, 83]. L’utilizzo di dispositivi poco intrusivi e
31
che interagiscono in modo semplice fornisce un importante aiuto a persone con problemi
fisici. Se a questo aggiungiamo la possibilità di far indossare dispositivi studiati
appositamente, è possibile raggiungere risultati insperati.
Lo studio di ambienti intelligenti è sicuramente uno dei campi dell’intelligenza artificiale
maggiormente in fermento, sia per le interessanti sfide tecnologiche che presenta, sia per i
suoi possibili campi di utilizzo, che spaziano dalle stanze intelligenti per uso domestico, ad
altri tipi di ambiente (automobili, spazi aperti, fabbriche, ecc.) che trarrebbero notevoli
vantaggi da questa tecnologia. Ciò ha anche spinto molte aziende ad investire ingenti quantità
di denaro in questo tipo di ricerca.
Computazione indossabile (wearable computing)
Una possibile definizione per il termine wearable computing può essere la seguente: “ogni
cosa che può essere indossata o portata con sé e che permette di migliorare la propria
interazione con il resto del mondo” [71]. Generalmente quando si parla di wearable
computing ci si riferisce a qualsiasi tipo di dispositivo elettronico portatile dotato di una certa
capacità elaborativa (vedi Sezione 2.1.3.5 relativo ai dispositivi per l’ubiquitous computing).
Steve Mann, uno fra i primi ricercatori che si sono interessati a questo settore, ha definito
alcune proprietà che permettono di caratterizzare più rigorosamente un sistema wearable
[72].
•
Eudaemonic criterion: l’intero apparato elaborativo deve essere sistemato in modo
che l’utente lo consideri una parte di sé e non dell’ambiente; la stessa percezione deve
essere avvertita da chiunque altro interagisca con il portatore dei dispositivi wearable.
•
Existential criterion: le capacità elaborative devono essere controllate dagli utenti.
Questa possibilità di controllo non deve rappresentare uno sforzo per chi la utilizza,
ma deve essere esercitata in maniera semplice ed intuitiva. Questo approccio permette
ai dispositivi wearable di comportarsi come se fossero delle estensioni del corpo e
della mente dell’utilizzatore.
Oltre a questi criteri è possibile identificare alcune caratteristiche che accomunano tutti i
wearable computer [84].
32
•
Portabilità: un wearable computer deve operare anche mentre l’utente è in
movimento, adattandosi rapidamente ai cambi di contesto. L’utente può entrare in
ambienti nuovi, con persone diverse ed oggetti diversi.
•
Maneggevolezza: un wearable computer deve essere concepito per poter essere
utilizzato usando minimamente le mani, affidandosi quando possibile al
riconoscimento vocale. L’uso limitato dei tradizionali strumenti di input rende
necessario un miglioramento delle capacità percettive del computer.
•
Percettività: per favorire l’input da parte dell’utente, un wearable computer deve
essere in grado di raccogliere la maggior parte delle informazioni riguardanti l’utente
e l’ambiente in cui è immerso sfruttando i propri sensori. Per migliorare la capacità
percettiva si può anche pensare di far interagire dispositivi immersi nell’ambiente con
sensori posti sul corpo.
•
Attività: un wearable computer deve agire, se necessario, anche quando l’utente non
lo richiede. Ciò può essere fatto analizzando i dati provenienti dai sensori, elaborando
queste informazioni e agendo di conseguenza.
•
Sempre attivo: un wearable computer deve essere sempre attivo. Questo è
fondamentale per permettere un continuo monitoraggio delle informazioni
provenienti dai sensori.
2.1.3.3 Middleware
Il middleware è un livello software che si trova tra il sistema operativo e il livello
applicativo che fornisce dei servizi all’applicazione rendendogli il sistema operativo
trasparente [37].
I componenti di un sistema di ubiquitous computing sono in grado di interagire con le altre
entità, altri componenti di ubiquitous computing o altre macchine, utilizzando i servizi messi
a disposizione dal middlware. Questi servizi provvederanno a garantire comunicazioni
sincrone e asincrone, traduzione delle informazioni scambiate tra piattaforme differenti, o
stabilirsi di connessioni dinamiche client-server ecc.
Diversi criteri possono essere adottati per classificare le tipologie di middleware, come ad
esempio il tipo di dati scambiati (oggetti o messaggi) o altre proprietà come la gestione del
contesto, gestione del real time ecc. In accordo con la letteratura [38] ho distinto i
middleware adottati in sistemi di ubiquitous computing tenendo in considerazione il carico
33
computazionale richiesto per l’esecuzione, i paradigmi di comunicazione supportati, il tipo di
rappresentazione del contesto fornito al livello applicativo.
Carico computazionale
Il carico computazionale dipende da un insieme di requisiti non funzionali che il sistema
vuole soddisfare. Ad esempio, uno dei principali propositi di un middleware è quello di
rendere possibile la comunicazione, permettendo ad esempio all’utilizzatore del middleware,
di richiedere servizi remoti; quello che distingue i diversi middleware è l’efficienza e
l’efficacia con la quale le richieste sono gestite. E’ ad esempio molto più dispendioso
garantire che una richiesta sarà sicuramente eseguita ed esattamente una volta piuttosto che
fornire un’affidabilità di tipo best-effort in cui non vi è la certezza dell’esecuzione di una
richiesta. Come altro esempio possiamo considerare la ridondanza. La replicazione è
largamente utilizzata dai middleware al fine di fornire una tolleranza agli errori sfruttando la
ridondanza. Tenere sincronizzate tutte le informazioni replicate richiede però un grosso
sforzo computazionale oltre che un intenso carico sulla rete di comunicazione. Dal punto di
vista computazionale i middleware possono essere quindi distinti in “pesanti” (heavy
computational load ) e “leggeri” (light computational load).
Diversi carichi computazionali implicano dunque differenti qualità e quantità di servizi
offerti, la richiesta di quantità e qualità dei servizi offerti da un middleware comporta
necessariamente un maggiore uso delle risorse disponibili da parte del middleware, la scelta
del tipo di middleware dovrà essere fatta quindi solo dopo un’attenta analisi delle
caratteristiche del sistema che si intende progettare e delle applicazioni che dovranno essere
implementate.
Paradigma di comunicazione
In letteratura si trovano principalmente due tipi di paradigmi di comunicazione che i
middleware supportano: esplicita o implicita. Nel primo caso, tipico della comunicazione
client-server, si richiede che il trasmettitore delle informazioni e il ricevente si conoscano
esplicitamente, nel secondo caso, tipico del paradigma pubblica-sottoscrivi (publishsubscribe) invece un trasmettitore invia il proprio messaggio senza avere una referenza
diretta del ricevente. Simmetricamente al concetto di esplicita od implicita, la comunicazione
può essere sincrona o asincrona. In una comunicazione sincrona sia il richiedente di un
34
servizio che quello che lo fornirà sono connessi allo stesso momento, in una comunicazione
asincrona la simultaneità della connessione non è necessaria.
Rappresentazione del contesto
Questo ultimo parametro che ho identificato per distinguere diverse classi di middleware si
riferisce ad informazioni possedute e strutturate da un middleware per descrivere il contesto
d’esecuzione e come tali informazioni vengono utilizzate.
Il contesto relativo all’esecuzione può essere passato al livello applicativo superiore
rendendo quindi l’applicazione consapevole (awareness) [16] del contesto oppure tenerlo
nascosto internamente al middleware stesso rendendo il contesto trasparente al livello
applicativo [15]. Il middleware interagisce con il sottostante sistema operativo e colleziona
informazioni relative, ad esempio, all’attuale locazione di un dispositivo, ai valori di
larghezza di banda disponibile in un dato istante, ai valori di latenza, alla disponibilità di
servizi remoti, ecc. Con il termine trasparenza, intendo che tutte le informazioni raccolte per
descrivere il contesto sono usate “privatamente” dal middleware e non vengono mostrate al
livello superiore; ad esempio, il middleware potrebbe accorgersi di una congestione sulla rete
in una porzione del sistema distribuito e prenderà le dovute misure per aggirare l’ostacolo
senza informare il livello superiore. Un middleware considerato di tipo awareness, invece,
passa le informazioni relative al contesto d’esecuzione (o parte di esse) all’applicazione, che
dovrà farsi carico della strategia decisionale da adottare a seconda della situazione
contestuale.
I sistemi di ubiquitous computing sono generalmente composti da diversi tipi di sistemi
distribuiti. La scelta del middleware è strettamente dipendente dal tipo di sistema sul quale
sarà in esecuzione e dall’obiettivo che tale sistema si prefigge. Per tale motivo di seguito
verrà proposta una classificazione relativa ai tipi di sistemi distribuiti seguita da una
trattazione più specifica dei middleware in relazione ad ogni tipo di sistema distribuito.
I sistemi distribuiti sono classificati in letteratura in tre categorie: tradizionali (o fissi);
nomadici; ad-hoc [39].
•
Sistemi tradizionali. Sono una collezione di dispositivi fissi, permanentemente
connessi alla rete con banda larga e con stabili connessioni, in esecuzione in ambienti
statici o con specificate dinamiche (dove la mobilità dei dispositivi è resa possibile
grazie al DHCP). I sistemi tradizionali sono la prima forma di sistemi distribuiti.
35
•
Sistemi nomadici. Sono un compromesso tra sistemi totalmente fissi e totalmente
mobili. I sistemi nomadici sono generalmente composti da un insieme di dispositivi
mobili e da una rete centrale fissa. I dispositivi mobili si spostano da una posizione ad
un’altra mantenendo sempre una connessione con la rete fissa centrale. Il carico
computazionale e i servizi per la connettività sono forniti per lo più dalla rete fissa
definita di backbone. In alcuni dei sistemi nomadici le sconnessioni sono consentite
da servizi trasparenti di riconnessione e risincronizzazione automatica. In un sistema
nomadico per l’ubiquitous computing i servizi possono essere offerti anche dai
dispositivi mobili (che non si limitano quindi ad essere dei client leggeri) in questo
caso sono previsti meccanismi di rilevazione del contesto per valutare la disponibilità
di alcuni dispositivi e dei loro servizi (discovery) [39, 15] .
•
Sistemi ad-hoc. Sono costituiti da dispositivi mobili tutti connessi alla rete tramite
connessioni molto variabili che eseguono operazioni in un ambiente estremamente
dinamico e mutevole. Differiscono dai sistemi nomadici per il fatto che i sistemi adhoc non posseggono un’infrastruttura fissa centrale (di backbone). La connettività
può essere simmetrica a seconda delle condizioni. Per i sistemi ad-hoc vi è la
necessità di definire dei protocolli di instradamento ad-hoc per ottimizzare la
trasmissione dei pacchetti tra i dispositivi mobili, l’utilizzo di protocolli classici per
reti fisse (ad esempio il protocollo IP) o nomadiche (come il mobile IP [30])
renderebbe il lavoro dell’instradamento eccessivamente pesante compromettendo
l’intero sistema [7]. Al contrario dei sistemi nomadici nel caso dei sistemi ad-hoc
ogni servizio è fornito dai dispositivi mobili. Un sistema ad-hoc dovrà essere più che
gli altri adattabile e scalabile.
Un sistema di ubiquitous computing può essere composto da una composizione delle
categorie di sistemi distribuiti appena descritti ed adottare quindi differenti tipi di middleware
in interazione tra di loro. Di seguito descriverò quali sono le caratteristiche di un middleware
adatto ad un sistema distribuito fisso (di tipo tradizionale) e quali invece quelle di
middleware adatti a sistemi distribuiti di tipo nomadico e ad-hoc.
Middleware per sistemi distribuiti tradizionali
I middleware per sistemi distribuiti fissi sono ad alto consumo di risorse e nascondono i
dettagli della distribuzione all’applicazione e in genere supportano comunicazioni sincrone.
36
•
Alto carico computazionale (heavy computational load). I sistemi distribuiti fissi
dispongono generalmente di grosse risorse computazionali distribuite in dispositivi
fissi e di una banda di comunicazione ampia. Per tale motivo si cerca di sfruttare al
massimo tale risorse al fine di avere una migliore qualità dei servizi da offrire al
livello applicativo.
•
Comunicazione esplicita e sincrona. I sistemi distribuiti tradizionali sono spesso
permanentemente connessi su una rete a banda larga e con connessioni stabili. Questo
significa che trasmettitore e ricevitore sono sempre connessi allo stesso tempo.
•
Trasparenza dal contesto. Il contesto d’esecuzione di un sistema distribuito
tradizionale è generalmente statico: la posizione di un dispositivo raramente cambia,
la topologia del sistema e pressoché costante nel tempo, la larghezza di banda rimane
stabile ecc. L’abbondanza di risorse permette di poter fornire efficienti servizi
rendendo il contesto trasparente all’applicazione. Nascondendo il contesto all’interno
del middleware si facilita il compito di chi dovrà implementare le applicazioni che
dovrà preoccuparsi solo dei requisiti funzionali e non di quelli non funzionali (ad
esempio la tolleranza ai guasti) concentrandosi quindi sul problema reale che
l’applicazione si propone di risolvere.
Middleware per sistemi distribuiti nomadici e ad-hoc
Si è scelto di fare una trattazione unica per i sistemi nomadici ed ad-hoc in relazione ai
middleware, infatti questi sistemi pur differendo per alcuni aspetti presentano alcune
caratteristiche comuni che influenzano i requisiti che un middleware adeguato deve
soddisfare.
•
Basso carico computazionale (light computational load). Le applicazioni mobili
sono eseguite da dispositivi con risorse limitate, con poca memoria, cpu lente, e in
genere con limitata potenza dovuta ad una alimenatazione a batterie. A causa delle
risorse limitate, middleware molto pesanti ottimizzati per macchine potenti non
sembrano essere una buona soluzione.
•
Comunicazione implicita ed esplicita. I dispositivi mobili sono connessi alla rete in
modo opportunistico e per piccoli periodi, normalmente giusto per il tempo
37
necessario per accedere a qualche dato o richiedere qualche servizio. Durante la
connessione la banda disponibile è minore di quella di un sistema fisso e può, in
alcuni casi, anche ridursi a zero in aree di non copertura. Per tale motivo il
middleware deve essere in grado di gestire oltre alle comunicazioni sincrone esplicite
anche quelle asincrone, infatti accade spesso in sistemi mobili ed altamente dinamici
che un servizio o delle informazioni vengano richieste anche se non
momentaneamente disponibili. Con una comunicazione asincrona il servitore
risponderà quando sarà in grado fornire le informazioni richieste. Il richiedente a sua
volta potrà accedere alle informazioni fornite in modo asincrono senza dover
attendere una risposta esplicita dal servitore.
•
Contesto dinamico, consapevolezza del contesto. Come detto in precedenza i
sistemi mobili nomadici, ma soprattutto quelli ad-hoc distribuiti, operano in un
contesto fortemente dinamico con una larghezza di banda di comunicazione non
stabile e servizi non sempre disponibili in ogni istante. Questa alta variabilità
associata alle scarse ed incerte risorse disponibili costringe ad impiegare un
middleware che delegherà parte del contesto ai singoli applicativi distribuendo cosi
l’ottimizzazione dei comportamenti ad ogni singola applicazione e alla sua specificità
e criticità funzionale.
Dopo una breve trattazione teorica per l’identificazione delle caratteristiche adeguate a
diversi tipi di sistemi distribuiti di seguito verranno riportati alcuni esempi di middleware
esistenti per il supporto allo sviluppo di sistemi distribuiti e di ubiquitous computing.
Esistono middleware commerciali progettati per reti aziendali, con le relative
standardizzazioni industriali, che possono essere considerati vicini a middleware adeguati per
sistemi di ubiquitous computing se pur non progettati specificamente a tale scopo. Tra questi
troviamo ad esempio CORBA, COM, REAL TIME CORBA, TINA-C [18]. In aggiunta a questi
troviamo altri middleware, provenienti dalla ricerca per reti mobili, come TAO [19] e
DYNAMICTAO [20] studiati e progettati per ambienti real time con limitate risorse e per tale
motivo si prestano ancor meglio ad essere middleware adeguati per l’ubiquitous computing
[18]. Tra i middleware particolarmente adatti a sistemi di ubiquitous computing c’è JINI,
progettato per ambienti dinamici e basato sul paradigma publish-subscribe. Questo ultimo
middleware verrà trattato in modo più approfondito nella Sezione 2.3 relativa alle tecnologie
per la domotica.
38
Ho trovato di maggior interesse, per i propositi dello stato dell’arte relativo all’ubiquitous
computing, riassumere e descrivere un po’ più in dettaglio alcuni middleware progettati per
sistemi distribuiti mobili, sviluppati con particolare attenzione ai concetti provenienti
dall’ubiquitous computing. I middleware che seguiranno sono tutti disponibili come prodotti
di ricerca e non sono prodotti commerciali.
•
MOBIWARE [21]. un progetto della Columbia University in grado di gestire una rete
mobile aperta, attiva, e adattativa. Mobiware per tale gestione si appoggia su
l’architettura CORBA e usa diversi algoritmi adattativi, degli oggetti JAVA, che
vengono distribuiti dinamicamente nei dispositivi mobili, punti d’acceso, in hub e
router mobili e fissi [18]. Prevede anche la gestione del flusso informativo durante la
mobilità e prevede servizi per il QoS (Quality Of Service). MOBIWARE può essere
considerato un soluzione per lo sviluppo di applicazioni per la gestione di
infrastrutture di reti mobili e non come un middleware completo per il supporto allo
sviluppo delle applicazioni finali destinate all’utente.
•
ARCHITECTURE
FOR
LOCATION INDEPENDENT CORBA ENVIRONMENT [22]. Un
middleware progettato al Trinity College che parte dall’architettura CORBA per
garantire l’interoperabilità con altri middleware. E’ in grado di gestire sia client che
server mobili. La comunicazine è basata in parte sulla tecnologia RMI (Remote
Method Invocation). Questa scelta di totale mobilità, dei gateway, router, server e
client, introduce una semantica di comunicazione adatta solo per sistemi distribuiti di
tipo ad-hoc, non prevedendo la possibilità di elementi fissi di supporto.
•
LIME [23]. Sviluppato alla università di Washington e al Politecnico di Milano, è
basato su un modello di spazio di tuple condivise. Il modello di riferimento permette
di vedere la mobilità come un cambiamento trasparente dello spazio delle tuple.
Questo modello facilmente supporta l’interazione tra dispositivi in una rete ad-hoc.
LIME inoltre supporta anche una sensibilità al contesto basato sulla memorizzazione
delle informazioni sempre nello spazio delle tuple. Nonostante ciò ignora lo stato dei
dispositivi e dell’ambiente circostante come parte delle condizioni generali del
contesto. Lo spazio delle tuple, pur portando ad una semplificazione delle
informazioni necessarie al supporto per la comunicazione tra dispositivi mobili,
carica di compiti computazionali, a volte molto gravosi i dispositivi.
39
•
XMIDDLE [24]. E’ un middleware basato sulla condivisione e la replicazione di
documenti in reti mobili ad-hoc. XMIDDLE conta su un modello di coordinate basato
sullo spazio delle tuple e aumenta le proprie capacità sfruttando la struttura gerarchica
dell’XML (eXtensible Markup Language). Fornisce un supporto per effettuare
conversioni e fusioni di documenti tra applicazioni specifiche differenti.
•
QOS-AWARE
OF
MIDDLEWARE [25]. Progettato all’università dell’Illinois Urbana-
Champaign, prevede un struttura di supporto al QoS attraverso livelli diversi
dell’architettura del sistema. I servizi di Qos offerti sono adattativi e contestuali. Le
politiche di adattamento sono basate su controllo di tipo fuzzy (logica sfumata). Il
Middleware supporta la computazione per l’instradamento, la gestione per la
trasmissione e ricezione dei pacchetti, prevede inoltre la comunicazioni di gruppo,
servizi per l’accesso a basi di dati e servizi per la gestione della localizzazione
(discovery).
•
TSPACES [26]. Progetto dell’IBM basato sullo spazio delle tuple. Tutti i meccanismi
di comunicazione sono stati implementati in JAVA. Prevede una comunicazione
basata sugli oggetti e sullo scambio messaggi asincrono. E’ robusto ai guasti di rete e
si occupa di recuperare le informazioni perse. Non prevede un esplicito supporto per
l’identificazione del contesto.
Nonostante l’enorme fermento per la progettazione e l’identificazione di middleware adatti
per applicazioni di ubiquitous computing, fino ad oggi i middleware esistenti, in campo
commerciale e nella ricerca, hanno ancora delle forti limitazioni per supportare reali
applicazioni in ambienti di ubiquitous computing. Di seguito fornirò una lista delle principali
mancanze da me riscontrate in tal senso.
•
I middleware e le standardizzazioni commerciali oggi esistenti spesso partono
dall’assunzione che la rete di comunicazione sia stabile, ipotesi inaccettabile per
ambienti di ubiquitous computing. La maggior parte di essi inoltre utilizzano una
semantica client-server esplicita non sempre utilizzabile in ubiquitous computing.
•
Molti dei middleware progettati appositamente per reti mobili non sono in grado di
utilizzare informazioni contestuali, informazioni che in ubiquitous computing
assumono invece un’importanza rilevante. Anche quando alcune informazioni
40
contestuali vengono prese in considerazione non vi è mai una relazione diretta tra
contesto ed operazioni in tempo reale svolte dalle applicazioni.
•
Molti dei middleware provenienti dalla ricerca scientifica, specifici per applicazioni
di ubiquitous computing, utilizzano architetture e semantiche troppo specifiche e non
eterogenee, questo costituisce una barriera per l’utilizzo di tali middleware nella
pratica reale, infatti diventa difficoltoso perseguire una vera interoperabilità con altre
architetture e middleware.
2.1.3.4 Comunicazione
La rete di comunicazione è quella che connette i dispositivi di un sistema di ubiquitous
computing tra di loro. A seconda delle applicazioni, diverse reti e tecnologie per la
comunicazione possono essere impiegate per sistemi di ubiquitous computing, ognuna con le
sue peculiarità. I fattori maggiormente caratterizzanti di una rete sono: la dimensione
dell’area potenzialmente copribile dalla rete, la tecnica di trasmissione, il mezzo di
trasmissione, il meccanismo per stabilire una connessione [15]. Tra questi fattori io prenderò
in considerazione, per proporre una trattazione sintetica e significativa, la dimensione
dell’area potenzialmente copribile dalla rete. Fattore questo che, come vedremo, finisce
anche per influenzare le altre caratteristiche della rete di comunicazione. In particolar modo
la tecnica e la tecnologia trasmissiva sarà nettamente influenzata dalla dimensione della rete.
Per dimensione dell’area coperta, e quindi dimensione potenziale della rete stessa, si
intende lo spazio fisico coperto da una particolare rete. Secondo tale caratteristica
distinguerò, in accordo con la letteratura [15], le reti in quattro classi: Personal Area Network
(PAN), Local Area Network (LAN), Metropolitan Area Network (MAN) e Wide Area
Network (WAN).
•
Personal Area Network. Una formale specifica di una PAN in merito alle
dimensioni dell’area e al numero dei dispositivi non esiste, una PAN può essere
considerata come una rete composta da tutti i dispositivi personali (di cui si darà una
definizione più precisa nella sezione successiva relativa ai dispositivi) di un singolo
utente [15]. Una specifica più formale, relativa alla dimensione, esiste invece per la
rete chiamata WPAN (wireless personal area network) dalla IEEE [73]. La IEEE
infatti fissa il raggio di azione di una WPAN a circa dieci metri.
41
Dal punto di vista implemetativo una PAN è costituita generalmente da
un’infrastruttura centrale composta da dispositivi fissi (mobili assieme all’utente) e da
un insieme di dispositivi dinamici che possono essere connessi o disconnessi durante
il funzionamento (dispositivi mobili con l’utente o integrati nell’ambiente). In questo
tipo di rete possono essere adottate due tipi di tecnologie di comunicazione. La prima
composta da una rete cablata per connettere i dispositivi personali fissi sull’utente
(normalmente si utilizzano dei bus di comunicazione progettati ad hoc [40]) . La
seconda è composta da un bus di comunicazione wireless a bassa potenza al fine di
connettere l’insieme dei dispositivi personali; BLUETOOTH [42] e l’infrarosso sono le
tecnologie maggiormente in uso. Lo standard attuale è il IEEE 802.15 WPAN [73].
Le reti PAN normalmente fanno parte dei sistemi distribuiti ad-hoc e nomadici.
•
Local Area Network. È formalmente definita nello standard IEEE 802 [42]. La LAN
come dimensione rientra nell’ordine dei cento metri. Tale rete è composta da
dispositivi eterogenei che possono essere sia personali che ambientali. Per la
creazione di una LAN alcuni tipi di standard di comunicazione vengono adottati: lo
standard IEEE 802.11a/b WAVELAN [42] che permette la mobilità dei dispositivi
all’interno della rete con un raggio di azione di circa cento metri. Una rete LAN
generalmente è utilizzata per interconnettere dispositivi di sistemi distribuiti nomadici
e fissi.
•
Metropolitan Area Network. Questo tipo di rete serve per interconnettere dispositivi
eterogenei in dimensione e struttura. La MAN può servire per interconnetere fra loro
diverse LAN o integrare diverse PAN. Dal punto di vista teorico una MAN copre una
area relativa ad una città (metropolitan) o, più in generale una vasta zona urbana. Per
questo tipo di rete diverse tecnologie integrate possono essere utilizzate. Le
tecnologie maggiormente utilizzate sono quelle che fanno riferimento allo standard
IEEE 802.11 WAVELAN [42] e allo standard IEEE 802.16 WAVEMAN [42] per le
trasmissioni senza cavi. Invece per le trasmissioni cablate vengono utilizzate la
ETHERNET, Internet e tecnologie che fanno riferimento allo standard IEEE 802 [42].
La MAN generalmente è utilizzate per sistemi distribuiti fissi.
•
Wide Area Network. Questo tipo di rete è composta da un insieme molto eterogeneo
di dispositivi. Ogni rete descritta fino ad’ora può essere considerata un componente
delle WAN. La comunicazione senza cavi utilizzate in una WAN sono il GSM,
42
GPRS, UMTS. La connessione cablata utilizzata è Internet. La WAN è utilizzata per
sistemi distribuiti fissi e nomadici.
2.1.3.5 Dispositivi
Il livello dei dispositivi è l’ultimo livello, quello in stretta relazione fisica con l’ambiente e
con le persone, di qualsiasi tipo di sistema di ubiquitous computing.
I dispositivi sono gli elementi base per ogni applicazione di ubiquitous computing, ogni
dispositivo rappresenta un singolo mattone da utilizzare per costruire un intero sistema di
ubiquitous computing [15]. I dispositivi costituiscono i componenti hardware e possono
essere ad esempio dei sensori, attuatori, unità di calcolo, antenne ecc. I dispositivi usati per
uno specifico sistema di ubiquitous computing definiscono la capacità d’interazione del
sistema con l’ambiente fisico. Un dispositivo avere sia un’identità computazionale di rete che
una capacità computazionale individuale [15].
Al fine di classificare i dispositivi prenderò in considerazione tre caratteristiche: ruolo e
campo d’azione; mobilità; tipo d’interazione tra il dispositivo e le altre entità fisiche.
Per identificare la dimensione del campo d’azione ed il ruolo dei dispositivi, faccio
riferimento ad una prospettiva antropica nella quale l’uomo è posto al centro del mondo e
della computazione [31], come nella visione proposta nell’ubiquitous computing [1, 4]. In
questa ottica possiamo riconoscere due entità: l’utente e l’ambiente; in relazione a ciò
possiamo distinguere i dispositivi in quelli utilizzati dall’uomo come dispositivi personali e
quelli usati nell’ambiente come dispositivi ambientali.
•
Dispositivi personali (Fig. 2.7, 2.8). Sono dei particolari dispositivi che possono
essere utilizzati dall’uomo in qualsiasi posizione lui si trovi, questo tipo di dispositivi
dovrà quindi essere mobile con l’uomo. I dispositivi personali possono essere distinti
in tre classi: amovibili (per esempio i palmari o i PDA); indossabili (ad esempio
dispositivi inseribili nei vestiti, orologi, occhiali e tutti i dispositivi che compongono
un sistema di wearable computing in genere ecc.); trapiantabili (ad esempio
introducibili in protesi o sottocutanei) [15]. Ogni classe identificata farà riferimento
ad una tecnologia adeguata relativa soprattutto alla parte hardware (ad esempio i
materiali utilizzati per dispositivi trapiantabili saranno diversi da quelli utilizzati per
un dispositivo amovibile).
43
•
Dispositivi ambientali (Fig. 2.9, Fig. 2.10, Fig. 2.11, Fig. 2.12). La definizione del
campo d’azione e del ruolo giocato dai dispositivi ambientali è complementare al
campo d’azione e ruolo dei dispositivi personali. Ogni dispositivo che non è
personale è ambientale. I dispositivi ambientali per sistemi di ubiquitous computing
sono sicuramente pervasivi. Per pervasività dei dispositivi si intende che questi
pervadono l’ambiente. Altri requisiti generali non sono specificabili in quanto
fortemente dipendenti dall’applicazione.
Per identificare una dimensione relativa alla mobilità, considererò la capacità dei
dispositivi di muoversi da una rete computazionale ad un’altra. In questa prospettiva
possiamo distinguere i dispositivi in mobili o fissi.
•
Dispositivi mobili (Fig. 2.7, Fig. 2.8, Fig. 2.9, Fig. 2.10). Possono muoversi da
un’area computazionale ad un’altra. La mobilità può essere indotta o spontanea. I
dispositivi mobili generalmente rispondono ai requisiti di nomadicità (riferito alla
mobilità) e sicurezza, vista la mobilità in diverse aree i dispositivi condividono
diverse informazioni che possono essere riservate, per alcune aree e per alcuni utenti
o pubbliche [15].
•
Dispositivi fissi (figure 2.11, 2.12). In modo complementare ai precedenti i
dispositivi fissi non possono muoversi da un’area computazionale ad un’altra. I
dispositivi fissi sono in genere integrati nell’ambiente ed aggiornabili nel tempo.
Al fine di identificare una dimensione per l’interazione, considererò l’interazione che una
macchina generica può avere con il mondo fisico. Una macchina può essere attiva se può
rilevare ed agire nel mondo fisico, altrimenti è passiva [15].
•
Dispositivi attivi (Fig. 2.7, Fig. 2.8, Fig. 2.9, Fig. 2.11). Posseggono sensori, attuatori
o entrambi. Nel caso siano dotati di sensori si definiscono sensitivi, se posseggono
attuatori si definiscono attuativi. I dispositivi attivi in uno scenario di ubiquitous
computing dovranno possedere i seguenti requisiti: intenzionale, pro-attivo, reattivo.
L’intenzionalità implica che i dispositivi ricevano richieste utilizzando nome. La proattività implica che i dispositivi possono agire per il conseguimento di un obiettivo
44
d’alto livello d’astrazione. La reattività implica la possibilità di reagire a degli eventi
[15]. Altri requisiti sono dipendenti dall’applicazione specifica.
•
Dispositivi passivi (Fig. 2.10, Fig. 2.12). Questi dispositivi non posseggono né
attuatori né sensori e possono svolgere dei ruoli computazionali o di supporto alla
comunicazione.
Figura 2.7 Palmare, dispositivo personale mobile, attivo e amovibile
Figura 2.8 Sulla sinistra un computer portatile con monitor e unità di calcolo indossabili. Sulla destra un insieme
di sensori con un’unità di calcolo indossabili. Dispositivi personali, mobili, attivi, indossabili (wearable)
45
Figura 2.9 Robot della RobotCup (manifestazione internazionale per incontri di calcio tra robot). Dispositivo
ambientale, mobile e attivo
Figura 2.10 Punto d’accesso per reti wireless trasportabile. Dispositivo ambientale, mobile e passivo
46
Figura 2.11 Sensori di rilevazione per i serramenti. Dispositivi ambientali, fissi e attivi
Figura 2.12 Centralina antifurto di controllo. Dispositivo ambientale, fisso e passivo
47
2.2 Domotica e ubiquitous computing
Nella seguente sezione seguirà una breve trattazione introduttiva sulla domotica (Sezione
2.2.1) e sugli ambiti applicativi in cui tale disciplina interviene (Sezione 2.2.2). Cercherò di
mostrare successivamente come, secondo me, la domotica può essere vista come una
specializzazione per uso commerciale del concetto ben più ampio e generalizzato di
ubiquitous computing (Sezione 2.2.3). In particolare la domotica è molto vicina al concetto di
smart room espresso nella Sezione 2.1.3.2.
2.2.1 Introduzione alla domotica
Il termine domotica deriva dall’importazione di un neologismo francese domotique, a sua
volta contrazione della parola greca domus e di informatique e rappresenta la disciplina che si
occupa dell’integrazione dei dispositivi elettronici, degli elettrodomestici e dei sistemi di
comunicazione e di controllo che si trovano nelle nostre abitazioni. Le origini risalgono
intorno agli anni ‘70 quando si vennero a sviluppare i primi progetti concreti di automatismi
legati alla gestione di impianti di allarme o altre funzionalità come l’accensione, lo
spegnimento e la temporizzazione delle luci.
La continua evoluzione delle tecnologie e lo studio più approfondito delle esigenze dei
consumatori permettono di concepire la disciplina della domotica lontano dall’idea della
semplice informatica applicata alla casa. Domotica vuol dire interazione fra la casa e l’uomo,
vuol dire ricerca di una migliore accessibilità e fruibilità dell’abitazione, vuol dire anche
creare nuovi mezzi per condividere gli ambienti domestici con gli altri membri della famiglia
[49]. Si sta creando un nuovo modo di vivere la casa è quello di vedere non più ogni
elettrodomestico o ogni servizio dell’abitazione come unico ed isolato dagli altri, bensì
vedere un ambiente integrato dove coesistenza diventa una parola d’ordine. Grazie all’uso di
nuove tecnologie e nuovi standard potranno nascere anche nuove tipologie di servizi avanzati
per gli utenti. L’utente disporrà di tutti i mezzi necessari per tenere sotto controllo il sistema
abitazione, e saranno i singoli dispositivi a gestire tutto il lavoro e a fornire in modo
automatico i servizi, decidendo tra loro priorità, privilegi, modalità di uso ed eventuali
collaborazioni e cooperazioni.
48
2.2.2 Domotica, ambiti applicativi
Gli ambiti applicativi della domotica oggi sono molteplici e riassumibili in quattro grandi
categorie: risparmio energetico, comfort, sicurezza, safety.
•
Risparmio energetico. Nell’ambito del risparmio energetico rientrano tutte le
tecniche e gli impianti in grado di ottimizzare il consumo energetico. In domotica nel
risparmio energetico rientra anche il risparmio monetario sul costo dell’energia. Il
risparmio monetario ha lo scopo di progettare sistemi in grado di approvvigionarsi
dalla fonte energetica più conveniente.
•
Comfort. Nell’ambito del rientrano tutti i sistemi progettati per la semplificazione del
rapporto uomo – casa e per il miglioramento della qualità della vita privata e
lavorativa. La connessione con la rete Internet, impianti audio e video multi room e
gli elettrodomestici in genere sono alcuni esempi delle tecnologie atte al
raggiungimento di un maggior livello di comfort nell’abitazione.
•
Sicurezza. La sicurezza è intesa come controllo degli accessi indesiderati
dall’esterno, accesi sia fisici che telematici. Il controllo degli accessi fisici è gestito da
impianti antifurto e da sistemi per il controllo degli accessi. Gli attacchi telematici
sono quelli provenienti dalla rete esterna (ad esempio Internet) collegata alla rete
domestica. La protezione da questi tipi di attacchi avviene tramite le tecnologie
classiche dell’informatica, come l’installazione di firewall e il controllo degli accessi
con codici d’identificazione.
•
Safety.
La
safety
è
intesa
come
sicurezza
personale
contro
eventuali
malfunzionamenti d’impianti potenzialmente pericolosi o dannosi per le persone e
l’abitazione. Per la gestione della safety si impiegano ad esempio l’impianto
antincendio, antiallagamento, gestori dei carichi di potenza ecc.
2.2.3 Domotica: una specializzazione dell’ubiquitous computing,
caratteristiche e peculiarità
Nonostante la crescita e lo sviluppo della domotica e dell’ubiquitous computing abbiano
seguito per lo più due strade differenti, le applicazioni domotiche partano da concetti teorici
direttamente riconducibili a quelli espressi per l’ubiquitous computing. Che il legame tra
ubiquitous computing e domotica sia molto stretto e parentale lo si evince anche dalla lettura
49
di numerose trattazioni di ubiquitous computing le quali spesso fanno riferimento al rapporto
uomo-casa per esemplificare trattazioni teoriche generiche relative a sistemi di ubiquitous
computing.
In domotica si assiste ad una vera e propria specializzazione dei concetti e dei requisiti
esposti nelle precedenti sezioni relativamente ai sistemi di ubiquitous computing. Il rapporto
uomo-ambiente è uno degli aspetti centrali nella ricerca in ubiquitous computing, in
domotica tale rapporto si trasforma o meglio si specializza e si restringe al rapporto uomoambiente domestico, dove l’abitazione è quindi un ambiente specializzato a compiti di
dimora. Tutti i requisiti attesi per i sistemi di ubiquitous computing sono auspicabili anche
per i sistemi domotici riferendoli però al rapporto uomo-casa e non più a quello uomoambiente. Tra i requisiti soddisfatti da molti dei sistemi domotici oggi esistenti troviamo:
•
adattabilità, intesa come flessibilità del sistema domotico ai cambiamenti delle
condizioni operative, i cambiamenti operativi in una casa si riferiscono per lo più
all’aggancio e sgancio a caldo di dispositivi ed elettrodomestici;
•
nomadicità, intesa come la capacità di poter gestire e controllare la mobilità dei
dispositivi su una o più reti domotiche;
•
reattività, intesa come reazione del sistema agli eventi fisici percepibili dall’uomo;
•
scalabilità, intesa come la possibilità di accrescere la rete domotica e il numero di
dispositivi che popolano la casa senza compromettere le funzionalità del sistema
domotico;
•
tempo reale, è riferito per lo più all’interazione del sistema con l’uomo che deve
essere la più rapida possibile, l’uomo infatti è abituato ad interagire con gli oggetti e
le funzioni della propria abitazione in tempo reale;
•
trasparenza, la domotica non persegue pienamente tale requisito ma si limita a
realizzare sistemi non troppo intrusivi.
Tutti gli altri requisiti non funzionali (eternità, integrazione totale e intenzionalità)
rimangono, per la maggior parte dei sistemi domotici reali, solo sperati.
50
2.3 Standard e tecnologie ad impatto sull’automazione domestica esistenti
sul mercato
I progettisti e gli sviluppatori di sistemi domotici, per la scelta della tecnologia da
utilizzare, fanno riferimento di norma ad interi “pacchetti” omogenei di sviluppo. Le aziende
produttrici, operanti sul mercato della domotica, infatti, propongono delle specifiche, riunite
in un unico pacchetto standardizzato, che regolamentano quasi tutti i livelli dell’architettura
tecnologica che propongono. Le specifiche riguardano i dispositivi, i linguaggi di
programmazione, i supporti da utilizzare per la comunicazione, i protocolli di
comunicazione, la codifica dei messaggi ecc. Per questo motivo ho scelto di trattare, non solo
le tecnologie trasmissive esistenti per la sola interconnessione tra dispositivi, adeguate a
sistemi domotici (Sezione 2.3.1), ma anche i protocolli e le standardizzazioni di intere
architetture per sistemi domotici consolidate sul mercato (Sezione 2.3.2).
Vista la presenza di numerosi standard differenti e non compatibili tra di loro, nella Sezione
2.3.3 mi occuperò di descrivere brevemente come, tramite l’uso di gateway, OSGI (Open
Services Gateway Iniziative) e l’HES (Home Electronic System) si stia cercando di ovviare ai
problemi d’interoperabilità. Inoltre descriverò quali sono le soluzioni attualmente adottate
per implementare sistemi domotici multipiattaforma.
2.3.1 Standard e tecnologie d’interconnessione
Visto lo stretto legame tra la domotica e l’ubiquitous computing molte delle tecnologie che
verranno citate in questa sezione sono già presenti nella trattazione del livello comunicativo
delle architetture per l’ubiquitous computing.
Sviluppare sistemi che riescono a sfruttare infrastrutture già presenti in una abitazione è
sicuramente uno degli obiettivi prefissati dai produttori di tecnologia per la domotica. Infatti
nella gran parte dei casi l’abitazione è preesistente ad un eventuale sistema domotico. La casa
è dotata di diversi mezzi sui quali possono essere trasmesse informazioni codificate in
segnali elettrici, in particolare ogni casa moderna possiede già una linea telefonica, una linea
di potenza e il cavo per l’antenna tv.
Le linee telefoniche odierne sono state costruite essenzialmente per il segnale vocale e
ottimizzate per tale scopo, per cui non sono adatte per la trasmissione di segnale digitali,
comunque la HOMEPNA (Home Phoneline Networking Alliance) utilizzando una tecnologia
proprietaria di modulazione di impulsi è in grado di ottenere una velocità di trasferimento
dati che arriva fino a 10 Mbit/s.
51
Le linee elettriche sono oramai presenti in ogni abitazione e per questo da diversi anni sono
stati profusi grandi sforzi per far comunicare diverse aree della casa tramite onde
convogliate. Vedremo in seguito come questo sistema sia stato adottato dallo standard X-10 e
CEBUS, largamente diffusi negli Stati Uniti e dallo standard EHS diffuso sul mercato
europeo.
Altre compagnie riunitesi in un'unica organizzazione, HOMEPLUG POWERLINE ALLIANCE,
mediante una tecnologia sviluppata da INTELLION e l’installazione di componenti in ogni
personal computer o dispositivo che si intende interconnettere, permette di condividere
informazioni tra questi su rete elettrica.
Il mercato della domotica non sta investendo invece sulle comuni reti telematiche cablate
per elaboratori, si immagini ad esempio lo sforzo che si dovrebbe compiere per cablare via
ETHERNET un centinaio di dispositivi in un’abitazione non predisposta per tale rete.
La trasmissione wireless è la tecnologia attualmente in fase di maggior sviluppo. La
radiofrequenza risulta sempre più spesso una soluzione conveniente ed economica nella
costruzione di una rete domestica o per reti aziendali o parti di esse.
Fra le tecnologie per implementare il “senza cavi” troviamo l’infrarosso che non riveste
però particolare interesse in domotica. Tale tecnologia, infatti, non permette la
comunicazione se fra i due dispositivi comunicanti viene frapposto un ostacolo fisico non
trasparente, condizione questa molto frequente in un ambiente domestico. Molta attenzione è
posta invece su sistemi che si basano sulla radiofrequenza. La comunicazione con
radiofrequenza è disturbata dalla presenza di ostacoli fisici fra i dispositivi che intendono
comunicare, ma il degrado della comunicazione è spesso trascurabile all’interno di ambienti
relativamente ristretti, come quelli domestici.
Gli standard più importanti presenti oggi sul mercato, con impatto sull’automazione
domestica, per la trasmissione in radiofrequenza sono:
• HOMERF (sostenuto da IBM e MOTOROLA) che permette una banda di trasmissione di
2 Mbit/s;
• WI-FI (Wireless Fidelity), sostenuto da 3COM e CISCO SYSTEM, con una banda di
12Mbit/s (con la prima specifica IEEE802e su 2,4Ghz) e 54Mbit/s (con la specifica
IEEE802a su banda che necessita di licenza statale)
• BLUETOOTH, sostenuto da INTEL, ERICSSON e NOKIA, ha una banda effettiva di circa
1Mbit/s. BLUETOOTH, come si vedrà meglio in seguito, non si limita a dare le
52
specifiche per la sola interconnessione ma stabilisce altre regole d’interoperabilità
che permettono di soddisfare altri requisiti specifici.
2.3.2 Protocolli, standard, bus di campo e architetture consolidate sul
mercato della domotica
La panoramica sulle tecnologie esistenti per la comunicazione tra dispositivi non si deve
limitare ad una elencazione di standard di sola interconnessione, ma particolare attenzione va
data a standardizzazioni che si occupano di fissare le specifiche di quasi tutti livelli di
un’architettura complessiva per un sistema di automazione domestica. Gli standard che
prenderò in considerazione in questa sezione non si limitano a definire solo specifiche per
l’interconnessione, come quelli citati nella sezione precedente, ma si occupano di fissare
regole e specifiche implementative per i dispositivi, i mezzi di comunicazione, il protocollo
di comunicazione, la codifica dei messaggi scambiati e il linguaggio di programmazione per
lo sviluppo delle applicazioni. La standardizzazione di quasi tutti i livelli di un’architettura in
un unico standard (dall’hardware al software) permette di creare degli ambienti di sviluppo
che forniscono built in (già costruiti, pronti all’uso) funzioni e servizi di notevole importanza
in automazione domestica. Tra questi, troviamo ad esempio l’autoconfigurazione della rete,
che permette lo sgancio e l’aggancio a caldo dei dispositivi senza compromettere il
funzionamento globale del sistema; il discovery automatico dei dispositivi agganciati, che
permette, ad esempio, di rendere fin da subito disponibile un nuovo dispositivo agganciato
ecc. Poter disporre di una serie di servizi pronti all’uso facilita il compito del progettista di
sistemi di automazione domestica che viene messo in condizione di poter rispettare la
maggior parte dei requisiti teorici attesi per un sistema domotico descritti in precedenza
(Sezione 2.2.3).
I principali standard da me identificati che si occupano di fornire notevoli servizi e funzioni
pronti all’uso per il progettista sono: EHS, BATIBUS, EIB, KNX (per il mercato Europeo),
LONTALK, HAVI, CEBUS, X-10 (per il mercato Americano), HBS (per il mercato
Giapponese) e BLUETOOTH (per il mercato internazionale. Inoltre nel mercato internazionale
sono presenti altre due standardizzazioni, l’HES e l’OSGI vedi Fig. 2.13. Queste due ultime
non dettano delle specifiche per un sistema tecnologico specifico, ma stabiliscono linee guida
formali per l’interoperabilità tra tecnologie esistenti in domotica. OSGI e HES propongono
una strada per far coesistere diversi standard tecnologici in un unico standard.
53
Figura 2.13 Schematizzazione del mercato degli standard mondiali per la domotica
Una trattazione specifica per ogni standard si trova nell’Appendice A. Tutte le informazioni
di maggior interesse, per gli scopi di questa tesi, saranno riassunte in una tabella comparativa
(Tab. 2.2).
Messaging
Discovery
(plug &
play)
Lookup
service
Gestione
degli
eventi
Configurazione
automatica
della rete
(plug & play)
Multicanalità
digitale
/analogico
Velocità di
trasmissione
X
8 Kbit/s
X
4-1250 Kbit/s
X-10
X
CEBUS
X
X
LONTALK
X
X
X
X
X
HAVI
X
X
X
X
X
EIB
X
BATIBUS
X
EHS
X
X
X
X
X
KNX
X
X
X
X
X
BLUETOOTH
X
X
1000-10000
Kbit/s
9 Kbit/s
X
X
X
4,8 Kbit/s
X
1,2 – 64
Kbit/s *
1,2-64 Kbit/s
*
1000 Kbit/s
* 9,6 Kbit/s se in utilizzata con la configurazione che permette anche la trasmissione del segnale analogico
Tabella 2.2 Riassunto dei servizi, funzioni e caratteristiche tecniche dei principali standard diffusi nei diversi
mercati internazionali per l’automazione domestica
54
Per chiarezza e completezza di seguito riassumo e specifico cosa intendo con i termini
utilizzati nelle colonne della tabella comparativa (Tab. 2.2).
•
Messaging: stabilisce uno schema di indirizzi e il trasferimento di messaggi (senza
perdita d’informazione), garantisce la comunicazione.
•
Discovery: è un meccanismo in grado di individuare quando i dispositivi sono
aggiunti o rimossi dalla rete.
•
Lookup Service: è una particolare scelta progettuale basata su una tabella dei servizi
(lookup table) nella quale ogni dispositivo, nel momento in cui si connetterà alla rete,
dovrà registrarsi inserendo nella tabella tutti i servizi che è in grado di fornire.
Cosicché tutti gli altri dispositivi saranno in grado di vedere quali sono i servizi messi
a disposizione sull’intera rete.
•
Gestione degli eventi: permette la comunicazione ad eventi consentendo il
paradigma di comunicazione di tipo publish-subscribe.
•
Configurazione automatica della rete: la configurazione dei router switcher ed Hub
e degli altri gestori della rete è totalmente automatica e non necessità di lavoro
manuale esplicito ad ogni modifica della topologia. Permette ad esempio l’aggancio e
lo sgancio di un dispositivo senza compromettere il funzionamento dell’intera rete.
•
Multicanalità digitale/analogico: ci dice se lo standard in considerazione è in grado
di trasportare o controllare contemporaneamente sia segnali analogici che digitali.
•
Velocità di trasmissione: indica la velocità di scambio dati, il bit rate della rete
considerata.
•
Plug and play: tale caratteristica è resa possibile dall’azione combinata dei servizi di
discovery e di configurazione automatica della rete e permette l’aggancio di un nuovo
dispositivo senza compromettere il funzionamento del sistema consentendone
l’utilizzo immediato.
Nel corso dell’esposizione del progetto di tesi spiegherò perché ho scelto la tecnologia
LONTALK per realizzare la mia applicazione domotica.
55
2.3.3 I gateway: una soluzione per un unico standard con molti standard
Esistono attualmente numerosi standard legati all’automazione e alla comunicazione
domestica. Purtroppo questo è stato uno dei principali fattori di rallentamento per la crescita
e per lo sviluppo del settore della domotica [60].
Nell’ambiente domestico oggi sono presenti numerosi dispositivi, ognuno dei quali
possiede protocolli di comunicazioni, portanti trasmissive, bit rate che lo rendono molto
spesso non compatibile nè con altre componenti della rete domestica nè con la rete esterna.
Su vari fronti si sta cercando di operare per eliminare questo problema, due esempi di
maggior peso nel settore della ricerca in questo senso sono l’OSGI e l’HES che si occupano,
oltre che dell’interoperabilità interna all’abitazione tra standard differenti, anche
dell’interoperabilità delle reti domestiche con quelle esterne pubbliche (rete elettrica, rete
telefonica ecc.). Entrambi si basano sulla standardizzazione del livello gateway e sulla
formalizzazione delle interfacce di comunicazione tra piattaforme differenti [60].
OSGi [49]
La Open Services Gateway Iniziative nacque nel marzo del 1999 a opera di un gruppo di
oltre sessanta compagnie tra le quali giganti nel settore della comunicazione come SUN
MICROSYSTEMS, ERICSSON, CISCO, NOKIA, SIEMENS, IBM, MOTOROLA, NORTEL, PHILIPS,
ORACLE, ALCATEL, LUCENT, TOSHIBA, TEXAS INSTRUMENTS e altri.
L’idea di base che accompagnò fin dall’inizio il progetto fu quella di standardizzare un
residential gateway capace di connettersi con un vasto spettro di applicazioni per lo scambio
di informazioni, in modo da fornire un’interfaccia sia tra gli apparati domestici che tra questi
e le reti pubbliche. La distribuzione delle specifiche fornite da questo gruppo avviene in
modo libero ed indipendente. L’OSGI cerca di coinvolgere non solo le case produttrici, ma
anche l’utenza finale mediante la pubblicazione di articoli informativi e testi di riferimento o
con attività educative. La ricerca si è concentrata fin da subito su una soluzione end-to-end
fra i dispositivi della rete domestica ed i provider dei servizi. Per i dettagli sullo standard
OSGi si faccia riferimento all’Appendice A.
HES [48]
La Home Electronic System è uno standard che sta per essere sviluppato da un gruppo di
lavoro costituito dall’ISO (Organizzazione Internazionale per la Standardizzazione) e dalla
IEC (Commissione Elettrotecnica Internazionale) di Ginevra, Svizzera.
56
La scrittura dello standard è eseguita da esperti dei paesi membri.
La HES fa parte di una commissione denominata Interconnection of Information Tecnology
Equipment la quale è costituita da venti paesi membri principali e da tredici paesi osservatori.
Sebbene gli standard di ISO e IEC siano volontari, alcuni paesi possono richiedere che i
prodotti commercializzati siano conformi con tali standard; l’Unione Europea ne sta
valutando la possibilità. Quindi affinché uno standard possa diffondersi è necessario che i
costruttori prendano nota delle conformità dettate da queste sorta di standard “d’alto livello”
(o meglio direttive) internazionali.
Esperti tecnici dei seguenti paesi si incontrano due volte l’anno per formulare lo standard
HES: Canada, Francia, Italia, Giappone, Olanda, Norvegia, Svezia, Regno Unito e Stati Uniti.
L’HES non si prefigge lo scopo di essere l’unico standard esistente per la Home
automation, ma, anzi, detta le regole e le specifiche che potranno portare ad una
interoperabilità tra standard differenti. Non si limita però a definire solo delle regole
d’inteoperabilità ma propone anche delle nuove scelte progettuali per i futuri dispositivi per
la home automation. Il fine primo dello standard internazionale HES è quindi di permettere ad
un apparecchio di comunicare su qualunque rete della home automation. Per i dettagli sullo
standard HES si faccia riferimento all’Appendice A. Tutti i tentativi di standardizzazione fatti
fino a oggi per garantire l’interoperabilità non hanno ancora sortito gli effetti voluti sul
mercato.
Tecnologia IP
gateway
gateway
Traduttore dei
messaggi
Traduttore dei
messaggi
Tecnologia 1
Dispositivi
Tecnologia 2
Dispositivi
Figura 2.14 Descrizione schematica di una possibile soluzione, per l’interoperabilità tra tecnologie
diverse, che sfrutta la tecnologia IP
57
Vista la consolidata tecnologia IP e la stabile standardizzazione di questo protocollo, oggi
tutte le case produttrici di tecnologie per la domotica propongono gateway IP per permettere
l’interazione con i personal computer o i web server. La comunicazione avviene codificando
i messaggi in stringhe da trasmettere su rete IP. Oggi è quindi già possibile far coesistere
diverse tecnologie in un unico sistema passando tutta l’informazione d’interscambio
multipiattaforma su rete IP. Questo metodo sicuramente crea gravi problemi di efficienza
visti gli over head e gli sforzi computazionali di traduzione dei messaggi vedi Fig. 2.14. Per
applicazioni non critiche questo sistema viene spesso utilizzato [62]. I gateway IP sono
quindi oggi una soluzione per un unico standard con molti standard.
2.3.4 Un’altra tecnologia ad impatto sulla domotica: JINI
JINI [58] è una tecnologia di rete, sviluppata da SUN e annunciata al pubblico nel gennaio
1999. Si basa su JAVA e su TCP-IP e mediante protocolli di rete rende possibile la
comunicazione di oggetti differenti in unico network, in cui ogni elemento non necessita di
essere installato in un sistema centrale, ma dove ogni dispositivo pubblica dei servizi che
rende disponibili. Tutte le volte che un nuovo dispositivo viene connesso alla rete JINI prima
annuncia il suo arrivo, poi quali sono le sue capacità ed infine come queste possono essere
utilizzate tramite la sua interfaccia.
L’architettura di JINI utilizza cinque concetti di base: lookup service, discovery, leasing,
eventi remoti, e transazioni. Questi concetti sono implementati come un insieme di librerie
JAVA, rese disponibili dalla SUN.
•
Lookup service: viene utilizzato da una persona o un programma per utilizzare un
servizio. Il servizio di lookup agisce come intermediario tra un client richiedente un
servizio e questo servizio. Una volta che è stata eseguita la connessione, il servizio di
lookup non viene più coinvolto, e i dispositivi comunicano direttamente attraverso
JAVA RMI. Il lookup service non è altro che una tabella contenente le interfacce che
descrivono le funzionalità dei servizi presenti nella comunità JINI. Un servizio viene
aggiunto al lookup service attraverso due protocolli: discovery e join. Prima il
servizio individua il lookup service tramite il protocollo di discovery, poi con l’uso di
join si unisce ad esso.
•
Discovery: la comunicazione fra servizi avviene tramite JAVA RMI (Remote Method
Invocation) che permette il trasferimento di dati e oggetti tra un oggetto e l’altro
58
attraverso la rete.
•
Leasing: questo servizio si occupa di assegnare le licenze per l’utilizzo di una risorsa.
I leasing vengono negoziati fra il richiedente e il fornitore del servizio.
•
Eventi remoti: un oggetto può permettere che altri oggetti si registrino a suoi eventi.
Il servizio che gestisce gl eventi remoti manda una notifica a questi oggetti quando
tali eventi si verificano.
•
Transazioni, questo servizio permette ad una rete JINI di rimanere consistente anche
nel caso di impreviste interruzioni di servizi da parti di dispositivi non funzionanti.
JINI può essere vista come una rete plug & play (hot) distribuita per dispositivi e servizi.
JINI è uno standard aperto: per ogni dispositivo non esistono API standard e per il suo utilizzo
in una architettura usata da più produttori è necessario un forte lavoro di standardizzazione.
59
3
IMPOSTAZIONE DEL
PROBLEMA DI RICERCA:
DALLA SIMULAZIONE ALLA
PRATICA IN AMBITO
DOMOTICO
L’obiettivo della tesi è la realizzazione di un’applicazione pratica che utilizzi
un’architettura multiagente con la capacità di effettuare pianificazione distribuita sviluppata
in precedenti progetti di ricerca e denominata AGENZIA AMBIENTALE [3].
Lo scopo della mia ricerca e del mio progetto è quindi anche quello di mettere in luce e
validare le caratteristiche e le funzionalità offerte dall’AGENZIA AMBIENTALE, come la
dinamicità, l’adattamento al conteso e la pianificazione distribuita orientata ai goal,
realizzando un applicazione reale e non solo simulata.
Per provare e verificare, in ambiente non simulato, la forte dinamicità e reattività
dell’AGENZIA AMBIENTALE si è scelto di realizzare un’applicazione concreta in ambiente
domestico con tecnologie opportune e già presenti sul mercato. L’ambiente domestico infatti
si presta bene a essere un ambiente molto dinamico, variabile, non totalmente strutturabile e
quindi non programmabile. In una abitazione l’uomo si trova spesso a dover raggiungere
obiettivi complessi il cui raggiungimento necessita di una pianificazione complessa e
dinamica che richiede l’interazione di più attori. Inoltre è stata scelta l’abitazione come
ambito in cui realizzare un’applicazione reale pratica anche perché il mercato della domotica
offre oggi numerose tecnologie per operare in ambiente domestico facilmente interfacciabili
con altre tecnologie, come introdotto nello stato dell’arte.
L’AGENZIA AMBIENTALE non è stata concepita con scopi specifici per la domotica ma è stata
progettata per applicazioni generiche di ubiquitous computing. Nel corso della trattazione
relativa all’impostazione del problema di ricerca si evidenzieranno le caratteristiche che
rendevano non del tutto adeguata l’AGENZIA AMBIENTALE per la realizzazione pratica di
un’applicazione domotica.
Verrà presentata inizialmente l’intera AGENZIA AMBIENTALE così come era stata progettata
e realizzata (Sezione 3.1) e in un secondo momento verranno evidenziate le problematiche
specifiche riscontrate dall’utilizzo dell’AGENZIA AMBIENTALE per la realizzazione pratica in
ambito domestico (Sezione 3.2). Un inquadramento generale sull’intera AGENZIA
AMBIENTALE preesistente mi permetterà di fissare e definire termini e concetti che verranno
ripresi in tutto il testo della tesi.
L’AGENZIA AMBIENTALE aveva toccato solo dal punto di vista teorico gli aspetti legati
all’interoperabilità tra la agenzia ed eventuali altre tecnologie, prevedendo l’uso di un proxy.
Nella Sezione 3.3 verranno analizzate le problematiche legate alla progettazione e
realizzazione pratica di un’interfaccia per la comunicazione tra il proxy e altre tecnologie.
Molti problemi riscontrati nell’architettura e nei principi di funzionamento dell’AGENZIA
AMBIENTALE sono anche di carattere generale e non specifici per la domotica. L’AGENZIA
AMBIENTALE, infatti, fino al presente progetto non era mai stata testata in nessun ambiente
reale e con tecnologie concrete. La fase dei test simulati non aveva quindi evidenziato alcuni
aspetti importanti che verranno descritti in questo capitolo.
3.1 Inquadramento e introduzione all’architettura preesistente
L’AGENZIA AMBIENTALE è stata ideata con lo scopo di fornire una architettura per la
progettazione di sistemi multiagente adeguata per ambiti non completamente strutturabili e
programmabili, in grado di far fronte ad esigenze la cui soddisfazione è fortemente
dipendente dal contesto, sfruttando una pianificazione e una conoscenza distribuita e
dinamica.
Nelle sezioni che seguono si darà una panoramica concettuale e funzionale precisa
dell’intera AGENZIA AMBIENTALE preesistente. In particolare nella Sezione 3.1.1 si presenta
la struttura generale, le funzioni e i servizi messi a disposizione dall’AGENZIA AMBIENTALE.
Nelle restanti sezioni viene fornita una schematizzazione logica più precisa di ogni singolo
61
componente e modulo ponendo l’attenzione sul meccanismo di cooperazione tra agenti e di
comunicazione dell’agente con le proprie componenti operanti nell’ambiente.
3.1.1 Architettura generale della AGENZIA AMBIENTALE
Il progetto dell’AGENZIA AMBIENTALE si colloca nella categoria delle applicazioni di
intelligenza artificiale distribuita e ubiquitous computing. Mi limiterò a descrivere i criteri
generali di progettazione e le caratteristiche di base di tale agenzia.
Bisogna innanzitutto chiarire che con il termine “ambiente” (termine da cui prende il nome
l’AGENZIA AMBIENTALE) s’intende un qualsiasi luogo delimitato, sia al chiuso come può
essere una stanza, un ufficio, l’interno di un’automobile, il vagone di un treno, la cabina di
pilotaggio di un aereo, sia all’aperto, ad esempio, una piazza od un parco.
Il ruolo dell’ambiente è quello di fornire lo spazio dentro il quale è possibile introdurre una
moltitudine di agenti in grado di cooperare. Come è facile intuire, il primo problema che era
stato affrontato nella realizzazione dell’AGENZIA AMBIENTALE era quello dell’eterogeneità
degli agenti coinvolti; un agente, infatti, può essere un’entità hardware o software e può
essere sviluppata utilizzando diversi linguaggi di programmazione e tecnologie. Tale
eterogeneità è stata gestita suddividendo un agente in due semiagenti, un primo semiagente
esclusivamente di tipo software detto cooperativo (CO), comune a tutti gli agenti e quindi
sviluppato con lo stesso linguaggio di programmazione, e un secondo semiagente di qualsiasi
natura detto operativo (OP) che permette di realizzare tutte le funzioni specifiche operative
dell’agente (cioè tutte le funzioni escluse quelle utili alla cooperazione).
Nel caso i due semiagenti non siano compatibili tra di loro è stato introdotto, solo dal punto
d vista teorico, un terzo componente, chiamato proxy, il cui ruolo è di permettere alla parte
cooperativa di utilizzare la parte operativa e viceversa (Fig. 3.1).
Sfruttando la scomposizione in CO e OP l’AGENZIA AMBIENTALE è in grado, tramite l’uso
di un agente supervisore, denominato maggiordomo, di gestire la pianificazione e la
cooperazione tra agenti per perseguire obiettivi d’alto livello chiamati goal.
Prima di procedere nella descrizione dettagliata dei semiagenti appena esposti è necessario
soffermarsi sul linguaggio di programmazione che è stato scelto per realizzare la parte
cooperativa degli agenti. La scelta era caduta su JAVA, essendo un linguaggio orientato alle
applicazioni distribuite in grado di realizzare programmi portabili, cioè in grado di
funzionare su diverse piattaforme operative: WINDOWS, LINUX, MACOS e altri, e con un
notevole grado di sicurezza, rendendo difficoltoso l’accesso a parti di codice non autorizzate.
62
Tutto ciò permetterebbe di avere diversi dispositivi di differente natura interagenti fra loro.
Agente
Agente
Java
Java
CO
CO
OP
proxy
OP
Altra tecnologia
Hw, Sw
Figura 3.1 Due possibili strutture di un agente
Il vincolo più oneroso introdotto da JAVA è la necessità di installare una JAVA Virtual
Machine (JVM) su ogni dispositivo che si vuole utilizzare come agente. La JVM è
semplicemente un interprete del linguaggio bytecode (prodotto dalla compilazione dei
sorgenti JAVA), ma spesso richiede un’occupazione di memoria non indifferente per piccoli
dispositivi, rimanendo comunque nell’ordine dei MegaByte.
3.1.2 Semiagente cooperativo
Come detto in precedenza, ogni agente è composto da un semiagente chiamato cooperativo
comune a tutti gli agenti del sistema. E’ sviluppato in JAVA e mette a disposizione le
funzionalità basilari per appartenere all’AGENZIA AMBIENTALE.
Per fare in modo che gli agenti possano cooperare fra di loro in modo omogeneo, tutti
dovranno estendere la classe che contiene i metodi necessari per la cooperazione, la
connessione e la gestione degli eventi e dei goal. Tale classe è stata chiamata Cooperative.
63
Vediamo in dettaglio le funzioni e servizi messi a disposizione dalla classe Cooperative.
Connessione: permette all’agente di entrare a far parte dell’agenzia. È la prima
operazione che un agente deve fare quando entra in un ambiente in cui è presente un’agenzia.
Connettendosi può sfruttare le funzionalità dell’agenzia, generare goal, ricevere notifiche di
eventi, inoltre può mettere a disposizione degli altri agenti le proprie funzionalità. Al
momento della connessione è possibile fornire all’agenzia un certo numero di parametri che
permetteranno una sua migliore identificazione. In particolare è possibile fornire un nome
con il quale registrarsi, una breve descrizione che ne riassuma le proprietà, un’immagine che
lo schematizzi, e un insieme di caratteristiche, dette Entry, che permettono di modellare più
dettagliatamente un agente. Il meccanismo con il quale un agente si connette è fondato sulla
tecnologia messa a disposizione da JINI, in particolare sul lookup service di JINI.
Il metodo della classe Cooperative che implementa questo comportamento è il seguente:
•
void connect (String name, Entry[] entry, String host, int port, String image, String
descr).
Sconnessione: è l’operazione duale rispetto alla connessione, l’agente con questa
operazione comunica all’agenzia che ci si vuole sconnettere. Dopo una sconnessione, pur
trovandosi all’interno di un ambiente, non si potrà interagire direttamente con esso. A
proposito della sconnessione, è importante distinguerne i due tipi possibili: sconnessione soft,
quella appena descritta, che non presenta particolari problemi, e la sconnessione hard, che
avviene in caso di brusca interruzione del collegamento, dovuto ad un guasto hardware o ad
un malfunzionamento della rete di collegamento, che introduce alcuni problemi. In
particolare, l’agenzia continuerà a credere che l’agente in questione sia appartenente al
sistema, e quindi potrebbe tentare di utilizzarlo, a quel punto se l’agente non risponde parte
un timeout. Il metodo della classe Cooperative che implementa la sconnessione volontaria è
il seguente:
•
void disconnect().
Gestione eventi: permette all’agente di compiere tre operazioni: generare un evento,
registrarsi ad un evento e ricevere la notifica di un evento. In altre parole, si fornisce
64
all’agente la possibilità di inviare la notifica di un determinato evento a tutti gli agenti che ne
hanno dichiarato l’interesse, inoltre si riceve una comunicazione ogni qualvolta un evento a
cui si è dichiarato l’interesse è generato da un agente dell’agenzia. Non riporterò di seguito i
metodi che implementano questo comportamento in quanto non verranno utilizzati nella mia
tesi.
Generazione goal: fornisce all’agente la possibilità di dichiarare una propria esigenza sotto
forma di goal. Esistono due modi con i quali un agente può chiedere all’agenzia di risolvere
un’esigenza. Il primo lascia la completa libertà nella pianificazione (insieme di operazioni
necessarie alla risoluzione di un goal) all’agenzia, senza che l’agente possa intervenire. Il
secondo prevede un’interazione fra agente e agenzia ogni volta che c’è la necessità di
scegliere fra due possibilità durante la pianificazione. Di fondamentale importanza è
dichiarare ciò che si è in grado di fare (i goal che si è in grado di risolvere autonomamente)
per permettere al pianificatore, come vedremo più avanti, di definire l’esatta strategia di
risoluzione del goal. I metodi della classe
Cooperative che implementano questo
comportamento sono i seguenti:
•
void generaGoal (PoliticaOrdinamento pol, DescrizioneGoal dg, int priorita);
•
void generaGoal (PoliticaOrdinamento poi, DescrizioneGoal dg, int priorita, int
maxEsp, int maxL);
•
boolean addEspansioneFinale (DescrizioneGoal dg, String metodo, Mappa
mappaIn, Mappa mappaOut, float cos, float per, float prob);
•
boolean addEspansioneintermedia (EspansioneIntermedia ei);
•
void eseguiEspansioneFinale (Integer iDPiano, Integer iDEspansioneFinale,
Integer priorita).
Comunicazione fra agenti: sono un insieme di funzionalità che permettono ad un agente
di comunicare con un altro agente e di conoscerne le abilità. Tali funzionalità consistono
nelle capacità di inviare messaggi di tipo testuale, di ricevere tali messaggi, di ottenere una
65
lista di tutti gli agenti attualmente connessi, e nella possibilità di richiamare un metodo di un
altro agente. Tutte queste operazioni, pur essendo interessanti dal punto di vista teorico
poiché aggiungono importanti capacità di comunicazione e di interoperabilità all’agenzia,
sono nella pratica scarsamente utilizzabili poiché partono dal presupposto che un agente
conosca la struttura dell’agente che vuole “utilizzare”. Per questo motivo tali operazioni non
verranno da me utilizzate e dunque non mi addentro nella loro trattazione specifica.
Ogni agente che voglia mettere a disposizione dell’agenzia le proprie funzionalità deve
implementare un’interfaccia remota (Remote). Questa interfaccia deve contenere tutti i
metodi che si vuole rendere disponibili pubblicamente. Oltre a questo è necessario dichiarare
i goal che si è in grado di risolvere. Questa operazione consiste nell’associare ad un goal un
particolare metodo e può essere fatta utilizzando un oggetto chiamato EspansioneFinale,
come sarà descritto più avanti in questa sezione.
3.1.3 Semiagente operativo
Se finora si è parlato delle funzionalità comuni a tutti gli agenti, ora descriverò le
caratteristiche specifiche degli agenti. La parte operativa di un agente può essere realizzata
nei più svariati modi a seconda dei compiti specifici che si vogliono portare a termine con un
agente.
In linea di principio, dovrebbe essere un’entità software che eventualmente s’interfaccia
con un componente hardware e che mette a disposizione alcune procedure e funzioni.
Nella tesi che esponeva l’AGENZIA AMBIENTALE [3] è stato considerato che il caso più
semplice d’implementazione del semiagente operativo si verifica quando anche la parte
operativa è realizzata utilizzando JAVA. In questo modo è possibile interconnettere le due
parti CO e OP, sfruttando la caratteristica dell’ereditarietà del linguaggio, implementando la
parte operativa come una estensione del semiagente CO, tale estensione provvederà ad
aggiungere i metodi necessari per espletare le funzioni operative.
Era stata posta l’attenzione al caso diverso in cui si utilizzi un altro linguaggio o
addirittura altre piattaforme e sistemi operativi, come sarà nel caso della mia tesi, in cui è
stato evidenziato la necessità d’introdurre un nuovo componente, chiamato proxy, il cui
compito è di gestire la comunicazione tra il semiagente CO e quello OP.
66
3.1.4 Linee guida per la progettazione di un proxy
Nella progettazione dell’AGENZIA AMBIENTALE è stata evidenziata la necessità quindi
dell’utilizzo di un proxy se si utilizzano tecnologie differenti per il CO e l’OP e sono state
tracciate delle linee guida per la sua implementazione. Riporto di seguito le considerazioni
che erano state fatte nel precedente progetto di tesi in merito al proxy [3].
Relativamente al proxy si sosteneva che esso dovrà sostituirsi all’OP al fine di rendere
trasparente all’agente la tecnologia utilizzata per l’implementazione del semiagente
operativo. Il proxy sarà quindi l’oggetto che estenderà il semiagente CO. Per fare ciò il
proxy, che è visto dall’agente dunque come se fosse l’OP, dovrà funzionare effettuando un
mapping tra tutte le funzionalità pubbliche messe a disposizione dalla parte operativa e i
metodi JAVA implementati per offrire all’agente i servizi operativi (vedi Fig. 3.2).
L’utilità teorica del proxy è evidente quando si vuole adattare un agente preesistente per il
funzionamento con l’AGENZIA
AMBIENTALE:
è sufficiente crearsi un proxy che lo interfacci
con la parte cooperativa, o quando in un agente si vogliono utilizzare degli OP da sviluppare
con altre tecnologie.
In un ambito di UC, caratterizzato da una elevata eterogeneità, sicuramente il proxy avrà un
ruolo determinante per l’utilizzo dell’AGENZIA AMBIENTALE in ambiente non simulato così
come vedremo nel proseguio della trattazione della tesi (vedi Sezione 3.4). Nel precedente
progetto di tesi [3] nulla si era però detto in merito alla logica di comunicazione tra il proxy
(oggetto JAVA) e l’OP (implementabile su qualsiasi tecnologia).
CO
P
R
O
X
Y
Metodo 1
Procedura
Metodo 2
Funzione
Metodo 3
Routine
Metodo 4
Valore Variabile
OP
Figura 3.2 Funzionamento del proxy
3.1.5 Maggiordomo dell’AGENZIA AMBIENTALE
Il progetto dell’AGENZIA AMBIENTALE prevede un agente, il maggiordomo, il cui compito
è di gestire l’agenzia. Sarà ad esso, ad esempio, che arriveranno tutte le richieste di
67
connessione. L’importanza del maggiordomo diventerà evidente quando si parlerà della
pianificazione per il raggiungimento di un goal. E’ infatti compito del maggiordomo
raccogliere tutte le esigenze provenienti dagli agenti e cercare di soddisfarle (Fig. 3.3).
Genera Goal
Maggiordomo
Solleva evento
Disconnetti
Lookup Service
Connetti
Jini
Figura 3.3 Il maggiordomo raccoglie tutte le esigenze degli agenti e usa il lookup service per gestirle
Il maggiordomo non è altro che un agente come tutti gli altri, quindi composto dalla parte
operativa (Fig. 3.4) e dalla parte cooperativa (comune a tutti gli agenti).
OP Maggiordomo
Interfaccia utente
Gestore eventi
Pianificatore
Esecutore
Figura 3.4 Parte operativa del Maggiordomo
68
Analizzo ora solo l’interfaccia utente di questo agente, gli altri tre moduli del maggiordomo
saranno trattati nelle sezioni successive.
Sono tre le operazioni principali che possono essere eseguite dall’utente tramite
l’interfaccia.
•
Monitoraggio dell’agenzia: permette di visionare in tempo reale quali agenti sono
connessi all’agenzia fornendo per ognuno di essi informazioni riguardanti l’host di
provenienza, il tempo di connessione e altri dettagli specifici di ogni agente. Tali
dettagli sono costituiti da un’immagine e da una descrizione particolareggiata delle
funzionalità dell’agente, ovviamente se fornita come parametro al momento della
connessione dall’agente stesso.
•
Gestione espansioni: le espansioni saranno descritte nelle sezioni seguenti dedicate
alla risoluzione dei goal, per il momento è sufficiente sapere che un’espansione può
essere facilmente creata, modificata o cancellata con semplici e intuitive operazioni.
•
Gestione goal: i goal e la loro gestione saranno descritti accuratamente nelle
successive sezioni; allo stesso modo delle espansioni, possono essere creati con
semplici operazioni.
3.1.6 Comportamento dell’AGENZIA AMBIENTALE orientato ai goal
L’agenzia è in grado di fornire una gestione degli eventi sfruttando il maggiordomo che si
occupa di ricevere e notificare agli interessati gli eventi. La descrizione dettagliata di come
ciò avviene non verrà trattata in quanto l’applicazione domotica da me implementata non ha
fatto uso di tale servizio implementato dall’AGENZIA AMBIENTALE. Dell’esistenza dei servizi
per la gestione degli eventi ho comunque tenuto conto nella progettazione di alcuni
componenti del mio progetto di tesi (come vedremo in seguito). Per la realizzazione della
logica di comunicazione e cooperazione tra agenti ho utilizzato il solo meccanismo di
cooperazione e pianificazione orientato ai goal messo a disposizione dall’AGENZIA
AMBIENTALE. Per tale motivo di seguito descriverò in dettaglio tale meccanismo.
La pianificazione è la tecnica con la quale è possibile trovare soluzioni a esigenze connesse
createsi all’interno dell’agenzia. Ciò significa che quando un agente non è in grado di
69
risolvere autonomamente un problema chiede l’intervento dell’agenzia, e in particolare del
pianificatore presente nel maggiordomo, che tenterà di trovare la soluzione migliore.
Di per sé il pianificatore produce semplicemente un piano, che è un insieme di operazioni
legate da particolari vincoli; serve quindi anche un esecutore che avendo in ingresso il piano
sia capace di realizzarlo, cioè sia in grado di far eseguire a tutti gli agenti i loro compiti
specifici che costituiscono il piano. Come si può intuire, per la risoluzione di un goal è
necessaria la cooperazione di più agenti coordinati correttamente: questo conferisce
all’agenzia un comportamento orientato ai goal, che si contrappone al comportamento
reattivo basato sugli eventi.
Vediamo ora meglio quali sono i componenti all’interno dell’agenzia che permettono
generare un goal, pianificare ed eseguire il piano che porta alla soluzione (se questo viene
trovato dal pianificatore) (Fig. 3.5).
•
Generatore del goal: è uno qualunque degli agenti appartenenti all’agenzia; un
agente quando vuole sollevare un’esigenza che intende soddisfare, genera un goal che
rappresenta tale esigenza. È importante porre l’accento sulla differenza che esiste fra
la generazione di un evento e la generazione di un’esigenza. L’evento, infatti, pur
essendo prodotto da un cambiamento nell’ambiente, serve solo ad informare tutti gli
agenti che è successo qualcosa, dopo di che ognuno reagirà nel modo che ritiene
opportuno. Con la generazione di un’esigenza, invece, l’agente richiede
esplicitamente che sia trovata una soluzione al suo problema.
•
Pianificatore: è il modulo cui pervengono le richieste da parte degli agenti ed è,
come detto in precedenza, una parte del maggiordomo (si veda la Fig. 3.4). Si è
quindi scelto di adottare un pianificatore centralizzato che si faccia carico dell’intero
processo di pianificazione. Come però si vedrà successivamente, nel processo di
pianificazione saranno utilizzati tutti gli agenti appartenenti all’agenzia, perché essi
sono i depositari delle conoscenze distribuite riguardo le azioni che possono essere
eseguite.
•
Esecutore: è il modulo che permette di eseguire il piano che il pianificatore
costruisce; anch’esso è parte integrante del maggiordomo (Fig. 3.4). Il suo compito è
di analizzare il piano e far eseguire ad ogni agente interessato il suo compito,
rispettando i vincoli imposti dal piano stesso. Le difficoltà maggiori sono dovute alla
sincronizzazione dei tempi, al passaggio di parametri fra agenti e alla gestione degli
70
errori durante l’esecuzione.
•
Attuatori: sono gli agenti dell’agenzia in grado di svolgere una qualche operazione
che si ripercuota sull’ambiente o che comunque generi un risultato utile ad altri
agenti. Un agente, per svolgere il ruolo di attuatore, deve dichiarare in qualche modo
ciò che è capace di fare, rendendo pubblici alcuni dei suoi metodi (ricordo che
nell’AGENZIA AMBIENTALE un agente è un oggetto JAVA). E’ utile ricordare inoltre
che lo stesso agente generatore del goal può essere utilizzato anche come attuatore, se
è utile per eseguire una parte del piano. Le prossime sezioni si occuperano appunto
delle varie parti di un piano.
Ambiente
Agente
Generazione esigenza: goal
Pianificatore
Pianificazione
Piano da eseguire
Esecutore
Operazioni da eseguire
Attuatori
Ambiente
Figura 3.5 Schema di risoluzione di un’esigenza (goal)
3.1.7 Elementi del piano
In questa sezione saranno analizzati gli elementi basilari che permettono di costruire un
piano; verrà invece tralasciata la descrizione in merito alla tecnica di pianificazione adottata
in quanto esula dagli scopi descrittivi per questa tesi.
71
Gli elementi del piano, dal punto di vista implementativo, si traducono in oggetti JAVA
realizzati con le seguenti classi.
•
DescrizioneGoal
•
GoalIniziale
•
Goal
•
Espansione (intermedia e finale)
•
PoliticheOrdinamento
•
ModificatoriGoal (Ordinamento, Selezione, IterazioneCiclica,
IterazioneCondizionata)
•
Piano
DescrizioneGoal
Questa è la classe che permette di dare una forma concreta ad un goal, permette cioè di
dare una forma implementativa al concetto astratto di esigenza.
Un goal è descritto mediante i seguenti parametri.
•
Un nome: rappresenta in sintesi l’esigenza desiderata; è una stringa e il suo
significato dovrebbe essere semplice e immediato.
•
Un’ontologia: rappresenta la semantica con la quale è stato definito il nome del goal.
L’ontologia e il nome sono strettamente legati, infatti, uno stesso nome può assumere
diversi significati se sono utilizzate due ontologie diverse. È anch’essa implementata
mediante una stringa.
•
Un vettore di parametri di ingresso: è un array di object e permette di definire degli
ingressi per il goal. Facciamo un esempio: se il goal è “telefonare” il parametro di
ingresso potrebbe essere una stringa rappresentante il nome da chiamare.
•
Un vettore di parametri di uscita: anch’esso è un array di object, permette di definire
gli
eventuali
risultati
forniti
dal
goal.
Esempio:
se
il
goal
è
ad
esempio:“cercaNumeroDiTelefono” l’ingresso potrebbe essere un nome (stringa) e
l’uscita una stringa rappresentante il numero di telefono.
•
Un vettore di tipi in ingresso: array di stringhe nel quale è contenuto il tipo, sotto
forma di stringa, dei parametri di ingresso, che invece sono object. Ovviamente se i
72
parametri di ingresso sono definiti, quest’array contiene i nomi dei tipi di questi
parametri, ma fra breve vedremo che gli oggetti in ingresso possono non essere
definiti. I tipi che possono essere utilizzati sono quelli definiti dal linguaggio di
programmazione JAVA, nonché quelli stabiliti dalle classi create.
•
Un vettore dei tipi in uscita: vale lo stesso discorso fatto sopra per gli ingressi.
•
Una descrizione: è un parametro facoltativo che permette di descrivere in maniera più
dettagliata il significato del goal.
E’ ora importante spiegare una sottile, ma importante differenza fra due possibili modalità
con le quali si può creare DescrizioneGoal. Finora abbiamo assunto che un goal sia generato
da un agente nel preciso momento in cui se ne verifica la necessità. Abbiamo anche
affermato che l’oggetto DescrizioneGoal serve a darne una rappresentazione concreta. E’
ovvio che tale oggetto sia creato utilizzando come parametri di ingresso gli oggetti che
effettivamente rappresentano gli input, in altre parole DescrizioneGoal conterrà un array di
object dove ogni elemento è un oggetto vero e proprio (un file, una stringa, un intero). Quello
che ancora non ho detto è che l’agenzia, e in particolare il pianificatore, ha la necessità di
trattare i goal anche in un contesto più astratto. Deve, infatti, conoscere come un goal può
essere decomposto in altri goal (vedi le espansioni più avanti) dove ognuno di questi nuovi
goal è rappresentato mediante l’oggetto DescrizioneGoal. In questo caso però, non è
possibile assegnare come parametri di input e output degli oggetti reali, in quanto non esiste
l’esigenza e quindi i parametri stessi. La soluzione adottata dall’AGENZIA AMBIENTALE è
stata quella di rappresentare i parametri non mediante l’oggetto vero e proprio ma utilizzando
il suo tipo. Quando poi il maggiordomo dovrà trovare nella sua conoscenza il goal rispettivo
a quello generato da un agente dovrà confrontare il nome del goal, l’ontologia e il tipo dei
parametri.
GoalIniziale
Nella decomposizione di un goal nei suoi sottogoal, GoalIniziale rappresenta il goal da
decomporre. Oltre ad avere tutte le proprietà di DescrizioneGoal possiede anche una lista di
tutte le possibili decomposizioni del goal.
Goal
E’ utilizzato all’interno delle decomposizioni di un GoalIniziale e a differenza di esso può
73
avere associati alcuni modificatori (ordinamento, selezione, iterazione) che ne controllano
l’esecuzione.
Espansione
E’ l’oggetto utilizzato per rappresentare le decomposizioni dei goal. L’idea è che un goal
per essere risolto debba prima essere “espanso” in una forma più semplice. Il primo, e più
intuitivo, modo per espandere un goal è di scomporlo in un insieme di goal più semplici che,
eseguiti con determinati vincoli, sono equivalenti al goal originario. Tale processo di
espansione può ripetersi parecchie volte, ma se si vuole risolvere effettivamente un’esigenza
è necessario che si arrivi a dei goal elementari o primitivi che non hanno bisogno di ulteriori
espansioni. E’ quindi necessario introdurre il secondo modo per espandere un goal; con
questo è possibile associare ad un goal la sua risoluzione vera e propria che consisterà
nell’esecuzione di un particolare metodo di un agente (sarà associata cioè a una
decomposizione finale e non più espandibile).
Riassumendo quanto appena detto è possibile distinguere fra due tipi di espansioni:
intermedie (EspansioniIntermedie) e finali (EspansioniFinali) (Fig. 3.6).
•
EspansioniIntermedie: espandono un goal in un insieme di goal considerati più
semplici.
•
EspansioniFinali: espandono un goal dicendo come risolverlo effettivamente.
Espansione intermedia
Espansione finale
Agente
+
Metodo
Goal
Goal iniziale
Goal iniziale
Figura 3.6 Tipi di espansione: finale e intermedia
Nulla vieta di creare più espansioni per uno stesso goal e addirittura è possibile che esistano
74
sia espansioni finali sia espansioni intermedie associate allo stesso goal.
L’efficienza con la quale il goal è risolto non è però sempre la medesima, anzi è possibile
trovare espansioni migliori di altre. Per valutare la bontà e l’efficacia di un’espansione si è
quindi associato ad ognuna di loro un insieme di tre parametri.
•
Performance: misura la qualità dell’espansione, dove per qualità s’intende, di volta in
volta, la caratteristica che maggiormente permette di identificarne l’efficienza. Se, per
esempio, il goal è “alzaLaTemperatura” l’efficienza potrebbe essere misurata dal
tempo necessario a raggiungere la temperatura richiesta.
•
Costo: misura il dispendio di risorse necessario per portare a termine l’esecuzione del
goal tramite l’espansione. Riprendendo l’esempio di prima, il costo è dato dal valore
economico necessario per ottenere l’innalzamento di temperatura.
•
Probabilità di successo: indica la probabilità che adottando questa espansione si
riesca veramente a risolvere il goal iniziale. Esiste la possibilità, infatti, che in taluni
casi si verifichino errori durante l’esecuzione di un metodo in un agente, che
compromettono l’intera fase di risoluzione.
Performance, costo e probabilità di successo saranno utilizzati dal pianificatore per
scegliere l’espansione migliore (potranno essere adottate diverse politiche, come ad esempio
massimizzare la performance, minimizzare i costi, ecc.), da utilizzare per un determinato
goal. I valori che tali parametri possono assumere sono numeri interi compresi tra zero e
mille.
Per concludere il discorso sulla costruzione delle espansioni bisogna parlare del problema
del mapping dei parametri del goal iniziale sui goal dell’espansione. Come detto, ogni goal
possiede degli input e degli output, quindi, quando espandiamo il goal iniziale, bisogna
specificare come i goal dell’espansione utilizzeranno i suoi input. In altre parole, è necessario
creare una mappa che associ ad ogni ingresso del goal iniziale un ingresso del goal
dell’espansione. Stesso discorso vale per i parametri di output.
PoliticheOrdinamento
E’ un oggetto che permette di definire un ordinamento fra due espansioni; ciò è possibile
definendo fra esse un vincolo di maggioranza. Chiarirò il concetto analizzando le tre
politiche di ordinamento predefinite nell’AGENZIA AMBIENTALE.
75
• Minor costo: un’espansione è maggiore di un’altra se il suo costo è minore.
• Maggiore performance: un’espansione è maggiore di un’altra se la sua performance è
maggiore.
• Maggiore probabilità di successo: un’espansione è maggiore di un’altra se la sua
probabilità di successo è maggiore.
Tutte e tre queste politiche prendono in esame un solo valore singolarmente, è però
possibile creare politiche personalizzate più complesse.
ModificatoriGoal
Un’espansione intermedia permette di decomporre un goal complesso in goal più semplici,
solo questo però non sarebbe sufficiente a raggiungere delle azioni eseguibili. E’ necessario
infatti che i goal dell’espansione siano eseguiti rispettando determinati vincoli. In altre
parole, l’ordine d’esecuzione dei goal semplici non sempre può essere casuale ma spesso
deve essere predeterminato, altre volte invece è necessario introdurre la possibilità di
effettuare scelte in esecuzione per decidere quale goal utilizzare nella decomposizione, infine
è utile introdurre il concetto di iterazione nel caso si desideri che il goal sia ripetuto più volte.
Tutti questi vincoli sono imposti all’espansione associando ad ogni suo goal un opportuno
modificatore. I modificatori possibili sono: ordinamento, selezione, iterazione, che analizzerò
dettagliatamente di seguito.
• Ordinamento, permette di creare un vincolo di sequenzialità fra due goal all’interno
di un’espansione. Quando ad un goal è associato questo modificatore significa che la
sua esecuzione deve avvenire solo dopo l’esecuzione dei goal specificati dal
modificatore stesso. Permette inoltre di specificare come avviene l’eventuale
passaggio di parametri fra i goal. Esiste anche la possibilità di creare sequenze di
ordinamento che comprendono più goal, l’importante è che non si creino dei cicli che
impedirebbero il completamento dell’esecuzione dell’espansione.
•
Selezione, permette di inserire all’interno di un’espansione la possibilità di fare una
scelta fra più goal condizionata a dei valori. Le proprietà del modificatore selezione
sono le seguenti:
o goal della selezione: il goal che fra tutti quelli presenti nell’espansione ha il
ruolo di selettore, nel senso che avrà il compito di produrre i valori per
76
effettuare la selezione condizionata;
o output del confronto: l’output del goal della selezione che genererà il
termine da confrontare;
o termine di confronto: stringa utilizzata per effettuare il confronto con
l’output generato precedentemente.
Il funzionamento è il seguente: un goal è scelto come selettore, scegliendolo fra
tutti i goal presenti nell’espansione; si definisce un suo output da utilizzare per il
confronto e si imposta un termine di confronto. Durante la fase di esecuzione, prima
di eseguire il goal in esame è eseguito il suo selettore (si noti che implicitamente è
definito un vincolo di ordinamento); si confrontano quindi l’output del selettore con
il termine di confronto e in caso corrispondano anche il goal in esame è eseguito. E’
facile, utilizzando questa tecnica, creare diversi tipi di selezione: semplice, doppia,
multipla, associando lo stesso selettore a diversi goal.
•
Iterazione, permette di impostare un comportamento iterativo per i goal
dell’espansione. E’ possibile definire due tipi di iterazione: iterazione ciclica e
iterazione condizionata. La prima consiste nel far ripetere l’esecuzione del goal un
numero prestabilito di volte. La seconda fa ripetere l’esecuzione del goal finché una
condizione è verificata. La verifica della condizione è del tutto simile al controllo
della selezione: s’imposta un selettore, un output da confrontare e un termine di
confronto. Anche nell’iterazione condizionata è implicito un vincolo di
sequenzialità tra selettore e goal in esame, ma questa volta al termine
dell’esecuzione di questo ultimo si ritorna ad eseguire il selettore.
I tre modificatori analizzati, schematizzati in Fig. 3.7, permettono di creare all’interno di
un’espansione intermedia una sorta di algoritmo risolvente in cui si possono trovare i
costrutti di un qualsiasi linguaggio di programmazione di alto livello: sequenza, selezione,
iterazione. Importante caratteristica è la possibilità di utilizzare più modificatori
contemporaneamente sullo stesso goal: ciò comporta l’adozione di alcune regole di
precedenza durante l’esecuzione di un goal con più modificatori.
Prima dell’esecuzione di un goal, se a questo è associato un modificatore, vengono eseguite
le sue precondizioni: selezione ed esecuzione del piano del goal precedente e verifica della
condizione espressa dal modificatore in relazione al risultato prodotto dall’esecuzione; se non
sono specificati vincoli, le precondizioni sono eseguite tutte contemporaneamente; è bene
77
ricordarsi però che ogni precondizione è essa stessa un goal e quindi può aver associati
diversi modificatori.
Ordinamento
Selezione
Iterazione
B
A
true
A
B
L’esecuzione del goal B
deve essere preceduta
dall’esecuzione dal goal
A.
B
A
-out
false
C
L’esecuzione del goal A è seguita:
dall’esecuzione del goal B se l’out,
prodotto dall’esecuzione del goal A, è
uguale a true; dall’esecuzione del goal C
se l’out è uguale a false
Stile for
5
10
-out
stile until
C
L’esecuzione dei goal A e B si ripete
ciclicamente per 5 volte (stile for).
L’esecuzione dei goal A e C si ripete
ciclicamente finché l’out fornito
dall’esecuzione di A non sarà uguale a 10
Figura 3.7 Modificatori dei goal
Piano
L’ultimo componente che analizzo è il piano (Fig. 3.8) che raggruppa tutti gli elementi
finora analizzati.
Ad ogni piano è associato un GoalIniziale cui, durante la fase di pianificazione, sono
associate le espansioni che lo decompongono e, in modo ricorsivo, ad ogni goal delle
espansioni sono associate altre espansioni fino al raggiungimento delle espansioni finali. Si
crea così un albero, chiamato albero di pianificazione, la cui radice è il goal completo,
l’esigenza, che sarà quindi risolvibile quando ogni sua foglia corrisponderà ad un’espansione
finale.
Concludo con una nota teorica che chiarisce su come può essere usata l’AGENZIA
AMBIENTALE. I goal generati dall’uomo o da un agente rappresentano un problema che si
vuole risolvere. Per farlo bisogna portare questo problema in una forma risolvibile da una
78
macchina. Questa fase che permette di passare dal mondo reale, i goal, al mondo delle
conoscenze della realtà, le espansioni (modelli), è realizzata esclusivamente dall’uomo. E’
quindi compito di questo ultimo definire come un goal può essere decomposto. E’ compito
cioè di chi vuole realizzare un’applicazione specifica, sfruttando l’AGENZIA AMBIENTALE,
definire le decomposizioni per risolvere delle esigenze (dei goal). Quando siamo a
conoscenza del problema rappresentato, è possibile passare, mediante processi inferenziali
(deduzione, induzione, che nell’AGENZIA AMBIENTALE sono realizzati) e tramite la
pianificazione, al problema risolto. Il problema risolto rappresenterà una sequenza di azioni
che andranno poi in esecuzione sui vari agenti.
D1
Agente 3
+
Metodo 1
C1
D2
C2
Agente 1
+
Metodo 1
B1
D3
A
B2
C3
C4
D4
Agente 1
+
Metodo 2
C5
D5
D6
Agente 3
+
Metodo 3
Agente 4
+
Metodo 2
Agente 5
+
Metodo 1
Agente 5
+
Metodo 2
Agente 6
+
Metodo 1
I goal A, B1, B2, C1, C3, e C5 possono essere decomposti con le espansioni
intermedie (cioè ulteriormente espandibili). Tutti gli altri hanno associati delle
espansioni finali (cioè non ulteriormente espandibili ma direttamente eseguibili).
Figura 3.8 Un esempio di albero generato dal pianificatore
3.1.8 Passaggio di conoscenza fra agenti
Al termine della pianificazione è presente una fase in cui gli agenti si scambiano le
conoscenze. Un agente, come detto, ha la possibilità di connettersi e disconnettersi a diverse
79
agenzie con estrema facilità: questo significa che potrebbe entrare in contatto con agenti che
dispongono di conoscenze a lui utili in futuro. Nell’AGENZIA AMBIENTALE è stato previsto un
semplice meccanismo per il passaggio della conoscenza che permette di condividere con gli
altri agenti dell’agenzia o delle altre agenzie le eventuali conoscenze acquisite. Non
descriverò come ciò avviene in dettaglio in quanto esula dagli scopi di questa tesi.
3.2 Problematiche specifiche per un’applicazione domotica in contesto
reale
Da questa sezione in poi si inizierà a parlare in modo specifico del mio progetto di tesi.
Nella Sezione 2.2.2 si è visto come la domotica può essere vista come una specializzazione
dell’ubiquitous computing, al contempo l’applicazione concreta che si è sviluppata in questa
tesi in ambito domotico può essere considerata una specializzazione dell’AGENZIA
AMBIENTALE, orientata alla creazione di applicazioni per l’ubiquitous computing. Per tale
motivo nelle prossime sezioni specializzerò, nella concretezza dell’applicazione domotica
realizzata, alcuni dei concetti e funzionalità implementati dall’architettura multiagente per
applicazioni di ubiquitous computing. Visto il carattere di generalità dell’AGENZIA
AMBIENTALE e visto che in concreto non era stata ancora sviluppata alcuna applicazione
pratica
che
sfruttasse
tale
agenzia,
inevitabilmente
nella
progettazione
e
nell’implementazione si erano tralasciati degli aspetti cruciali per il buon funzionamento di
un applicazione reale. Nelle successive sezioni verranno messi in luce le problematiche di
progetto che si sono poste in relazione all’utilizzo in ambito non simulato e nello specifico, in
quello domotico, dell’AGENZIA AMBIENTALE.
Nella Sezione 3.2.1 si spiegherà cosa si intende per contesto in una abitazione e quali sono
i tipi di mutamenti dell’ambiente uomo-casa sensibili al fine del funzionamento di
un’applicazione domotica. Verranno quindi dati dei suggerimenti per la creazione di
un’applicazione domotica che tenga conto delle informazioni contestuali utili in domotica.
Nella Sezione 3.2.2 si analizzeranno in dettaglio alcune delle dinamiche dell’interazione
dell’uomo con l’ambiente domestico al fine di focalizzare il progetto di ricerca su aspetti
tipici di un sistema domotico.
Nella Sezione 3.2.3 verrà sottolineato come la visione di un agente composto da una
componente operativa (OP) costituita da un solo dispositivo fisico sia drasticamente
limitativa nella pratica reale in ambito domotico e come tale limitazione, se non fosse stata
80
eliminata tramite una reingegnerizzazione dell’agente, avrebbe comportato un aumento della
complessità dell’intero progetto, portando ad una drastica diminuzione dell’efficienza
dell’applicazione.
Nella Sezione 3.2.4 verranno evidenziate le problematiche che nascono modificando
l’agente in modo che possa gestire con un solo OP logico anche più di un dispositivo fisico.
Nella Sezione 3.2.5 si porrà il problema della scelta di una tecnologia adeguata per
l’implementazione dei semiagenti operativi, verranno evidenziati i servizi e le caratteristiche
che deve possedere la tecnologia da scegliere.
3.2.1 Il contesto per un sistema domotico
Nello stato dell’arte relativo all’ubiquitous computing il contesto è stato identificato come
ogni sorta di informazione che permette di caratterizzare la situazione di un’entità, dove per
entità si può intendere una persona, un luogo, un oggetto fisico o un dispositivo elettronico.
Per la domotica oggi le entità rilevanti, al fine di rilevare il contesto, sono solo i dispositivi
collegati alla rete domestica, le persone e i parametri fisici ambientali (come la temperatura o
l’intensità luminosa).
Contesto relativo ai dispositivi di un’abitazione
I cambiamenti di contesto sensibili ai fini di un’applicazione domotica sono dovuti: al tipo
di utilizzo che si fa dei dispositivi in una casa, ai possibili malfunzionamenti e al mutamento
dei servizi offerti dai dispositivi.
• Tipo di utilizzo dei dispositivi in una casa. Gli elettrodomestici, particolari tipi di
dispositivi domestici che utilizzano l'energia elettrica per trasformarla in lavoro utile
all’uomo nella casa [76], vengono di continuo spostati, sganciati riagganciati alla rete
domestica, spenti e riaccesi. In una casa l’uomo deve avere la possibilità di
posizionare gli elettrodomestici dove vuole senza vincoli eccessivi. Gli unici vincoli a
cui l’uomo è già abituato sono quelli relativi alle prese di corrente, alla presa
dell’antenna o agli allacciamenti di acqua e gas. La domotica si propone come una
tecnologia che semplifica la tecnologia già esistente in una casa, non dovrà inserire
quindi ulteriori vincoli fisici alla mobilità e alla libertà d’azione in genere. A tal fine
un’applicazione domotica dovrà essere in grado di rilevare autonomamente la
posizione degli elettrodomestici e dei dispositivi, per poterlo fare dovrà essere in
81
grado di percepire il contesto relativo alla posizione fisica e allo stato dei dispositivi
(accesi o spenti, agganciati o sganciati).
• Malfunzionamenti. I dispositivi presenti in un’abitazione sono soggetti spesso a
malfunzionamenti, infatti la casa è ricca di dispositivi di media o breve durata rispetto
alla vita media di un’abitazione, come ad esempio le caldaie autonome (vita media di
circa 10 anni) o i punti luce (con durata spesso inferiore ai due anni). Un sistema
domotico deve essere in grado di rilevare questa informazione contestuale al fine di
prevenire malfunzionamenti a cascata e poter fornire eventuali strumenti di diagnosi.
• Mutamento dei servizi offerti. I dispositivi in una casa sono spesso rimpiazzati da
nuovi dispositivi che potrebbero essere in grado di fornire nuovi servizi o non essere
più in grado di fornire quelli del dispositivo sostituito. Tale mutamento contestuale
deve essere rilevato da un sistema domotico al fine di poter sfruttare i nuovi servizi e
di non incorrere in operazioni incoerenti, tentando ad esempio di far fronte ad
un’esigenza utilizzando funzioni e servizi non più presenti nel sistema domotico.
Conteso relativo agli abitanti della casa.
Nell’analisi del contesto abitativo la rilevazione di presenza dell’utente e l’individuazione
della posizione è un’informazione fondamentale per poter fornire alcuni servizi e funzioni
tipici di un sistema domotico. La posizione dell’utente è ad esempio utile per poter soddisfare
esigenze d’intenzione come, ad esempio, la richiesta di una stampa sulla stampante più vicina
o la richiesta di uno scenario luminoso nella stanza in cui si è senza dover specificare
esplicitamente la stanza in cui ci si trova. La rilevazione della presenza dell’utente in un
ambiente specifico è una informazione necessaria, ad esempio, per poter permettere al
sistema domotico di effettuare un più efficace ed efficiente risparmio energetico. La proattività richiesta per portare a termine un piano di risparmio energetico può essere ottimizzata
sfruttando le informazioni contestuali relative alla rilevazione di presenza. Se il sistema è a
conoscenza della presenza umana o meno in una stanza sarà in grado, ad esempio, di poter
spegnere le luci quando la stanza non è più occupata, almeno che non vi sia stata una
esplicita richiesta da parte dell’uomo di lasciare la luce accesa anche in assenza di rilevazione
di presenza umana.
82
Contesto relativo ai parametri fisici ambientali.
La rilevazione di alcuni parametri fisici, in domotica, diventa fondamentale per poter
svolgere molte funzioni, anche basilari. La rilevazione della temperatura, ad esempio, servirà
per il processo di climatizzazione e per il risparmio energetico. La rilevazione dell’intensità
luminosa può servire, ad esempio, per poter controllare l’intensità luminosa in una stanza al
fine di mantenerla ad un livello richiesto dall’utente mescolando diverse sorgenti luminose
(naturali e non).
Concludo evidenziando che la rilevazione del contesto dei dispositivi è fondamentale per
non compromettere il funzionamento e la stabilità di tutto il sistema. Invece il contesto
relativo agli abitanti della casa e ai parametri fisici ambientali serve per realizzare funzioni
specifiche.
Alla luce di quanto detto un’applicazione domotica dovrà essere in grado di:
•
monitorare lo stato dei suoi dispositivi in ogni momento;
•
comunicare con i dispositivi indipendentemente da dove siano posizionati
fisicamente, purché collegati ovviamente in qualche modo alla rete domotica;
•
percepire il contesto relativo ai dispositivi, sviluppando una reattività immediata alle
variazioni. Tale reattività si dovrà ripercuotere e influenzare sulla logica con cui il
sistema svolgerà le operazioni che gli vengono richieste.
E’ auspicabile, inoltre, che un’applicazione domotica complessiva (in grado di coprire tutti
gli ambiti applicativi della domotica) ed efficace, sia costituita da tutta la tecnologia
necessaria per poter rilevare anche il contesto relativo agli abitanti e ai parametri ambientali.
3.2.2 Ergonomia dell’interazione uomo - ambiente domestico, alcuni aspetti
percettivi
Un sistema domotico deve cercare di avvicinarsi il più possibile alle abitudini degli abitanti
della casa cercando di essere il più trasparente e meno intrusivo possibile.
L’uomo è abituato a comunicare con la propria abitazione e i rispettivi dispositivi in tempo
reale, senza latenze percepite, in cui l’effetto di un’azione è percepito contemporaneamente
all’azione stessa. Come ad esempio l’apertura e chiusura di una schermatura tramite corda
83
avvolgibile produce l’effetto istantaneo di movimento verso l’alto o verso il basso della
schermatura, così come la banale accensione di una luce è l’istantanea conseguenza della
pressione su un interruttore. Per tale motivo un sistema domotico, che si prefigge come scopo
la non intrusività, non potrà prescindere da tale prerogativa. I tempi computazionali e di
trasporto delle informazioni dovranno essere ottimizzati al fine di rispettare le abitudini
d’interazione uomo-casa. Si immagini ad esempio la scomodità e la conseguente
inutilizzabilità di un potenziometro per un punto luce che agisce sull’intensità luminosa con
una latenza percepibile, in cui, non solo l’uomo percepisce qualcosa d’inatteso dalla propria
abitazione, disorientandosi, ma nel caso specifico, si trova in difficoltà nell’attuare un
retroazione percettiva per regolare l’intensità luminosa fino a quella desiderata.
L’uomo è abituato ad essere il controllore ultimo di ogni aspetto tecnico e artistico della
propria abitazione e per tale motivo vuole essere in grado di operare, controllare e monitorare
direttamente qualsiasi dispositivo operante nell’ambiente. La possibilità di poter controllare
direttamente, con mano propria, tutte le funzioni messe a disposizione dai dispositivi operanti
nella casa fornisce all’utente la certezza di trovarsi nella sua casa dove ogni cosa è “sotto
controllo” come testimoniato anche da una ricerca dell’Enea sul rapporto dell’uomo con le
nuove tecnologie [75]. Per tale motivo, qualsiasi sistema domotico che si preoccupi delle
esigenze emozionali degli abitanti di un ambiente domestico dovrà essere in grado di dare il
controllo su qualsiasi dispositivo in modo diretto, in caso di esplicita richiesta, fornendo così
la sensazione che il controllo sulla casa non si basi solo su intermediari tecnologici. Il sistema
domotico dovrà essere additivo e non sottrattivo rispetto alle abitudini funzionali che si
hanno in una casa.
Un’applicazione domotica, ad esempio, oltre a fornire la possibilità di ricreare degli scenari
d’ambiente, impostabili e configurabili dall’utente, agendo sull’illuminazione, riscaldamento,
impianto audio/video ecc. dovrà anche fornire la possibilità, se richiesto, di operare
direttamente sulla singola lampadina, sul singolo termosifone e su ogni funzionalità messa a
disposizione dagli elettrodomestici audio/video. Così come sarebbe stato in assenza di un
sistema tecnologico domotico.
Visti gli aspetti ergonomici evidenziati è importante specificare che la reattività al contesto,
che un’applicazione domotica deve sviluppare, si deve riflettere istantaneamente anche
sull’interfaccia di comunicazione con l’uomo.
84
Affinché l’uomo abbia la sensazione di avere tutto “sotto controllo” deve essere messo
nelle condizioni di poter monitorare e controllare ogni dispositivo presente nel sistema
domotico tramite l’uso dell’interfaccia utente.
3.2.3 Necessità di gestire più dispositivi per ogni agente in ambito domotico
La casa è popolata da numerosi dispositivi il cui controllo non comporta computazioni
complesse e grossi scambi d’informazione, come nel caso ad esempio di una lampadina o di
un sensore di rilevazione di presenza.
Sviluppare un agente per ogni dispositivo fisico presente in un sistema domotico
comporterebbe un decremento delle prestazioni dell’intera AGENZIA AMBIENTALE. Ogni
agente infatti è da considerarsi un processo residente in memoria in esecuzione. Un agente,
come detto, è costituito da un semiagente CO e uno OP, il semiagente CO è uguale per tutti
gli agenti. Le parti CO sono in grado di gestire tutta una serie di servizi per la connessione,
sconnessione, pianificazione e gestione degli eventi e altro, quindi sono dei processi
abbastanza complessi che portano ad una sensibile occupazione di memoria e un certo sforzo
computazionale. Non sarebbe dunque pensabile di mandare in esecuzione un intero processo
CO per ogni dispositivo fisico collegato alla rete domotica. Si pensi ad esempio al caso di un
interruttore o di un punto luce, in cui la maggior parte dei servizi messi a disposizione dal CO
sarebbero del tutto superflui. Si deve quindi allentare il concetto di agente legato ad un
singolo dispositivo fisico prevedendo una soluzione tentacolare. Per tale soluzione ho
ipotizzato la possibilità che il semiagente OP di un agente, implementato per un’applicazione
domotica, possa essere costituito da più di un dispositivo domestico per volta oppure che un
agente sia costituito da più semiagenti OP (ognuno dei quali gestisce un singolo dispositivo).
3.2.4 Problematiche legate alla gestione di più dispositivi per ogni agente
Nel caso in cui il semiagente OP sia costituito da più dispositivi fisici, esso sarà in grado di
metter a disposizione dell’agente la somma dei servizi messi a disposizione da ogni singolo
dispositivo. L’agente percepirà la presenza di un solo OP disinteressandosi dei dispositivi
fisici realmente operanti nell’ambiente. In questo modo si richiede però al semiagente OP di
non essere uno sterile esecutore, ma di essere in grado di impartire i comandi adeguati ai
dispositivi fisici che lo compongono a seconda delle operazioni che l’agente vorrà portare a
termine (Fig. 3.9). Inoltre l’OP dovrà anche essere in grado di comunicare al CO quali sono i
85
servizi che questo potrà o non potrà più mettere a disposizione dell’intera agenzia a seconda
dello stato dei dispositivi fisici rilevato. Anche il flusso d’informazione tra dispositivi e
agente per il monitoraggio dello stato, al fine di tenere traccia del contesto dei dispositivi,
deve essere gestito dall’OP. Per tali operazioni può venirci in soccorso il concetto di proxy,
di cui abbiamo parlato nella Sezione 3.1, che, come era stato proposto dal precedente
progetto di tesi [3], può sostituirsi all’OP nell’estensione del CO per effettuare
un’intermediazione. Il proxy può essere un buon candidato a essere, non solo un
intermediario ma, il modulo deputato a tenere insieme diversi dispositivi costituendo, dal
punto di vista logico, un semiagente OP unico (Fig. 3.9).
Agente
Java
CO
Dispositivo
Altra tecnologia
Hw, Sw
Dispositivo
Proxy
Altra tecnologia
Hw, Sw
(OP)
Dispositivo
Altra tecnologia
Hw, Sw
OP
Dispositivo
Dispositivo
Altra tecnologia
Hw, Sw
Altra tecnologia
Hw, Sw
Figura 3.9 Un proxy in grado di gestire più dispositivi fisici costituendo un unico OP
La soluzione alternativa è quella che prevede che un agente possa essere composto anche
da più di un semiagente OP (Fig. 3.10). In questo caso si dovrebbe prevedere un proxy per
ogni OP esistente e si dovrebbe prevedere la totale reingegnerizzazione del CO, parte
fondante di tutta l’agenzia.
86
Agente
Java
Proxy
OP
Altra tecnologia
Hw, Sw
CO
Proxy
OP
Proxy
Proxy
OP
Altra tecnologia
Hw, Sw
Proxy
Altra tecnologia
Hw, Sw
OP
OP
Altra tecnologia
Hw, Sw
Altra tecnologia
Hw, Sw
Figura 3.10 Un CO in grado di gestire più proxy, ognuno dei quali gestisce un OP costituito da un unico
dispositivo
Indipendentemente dalla soluzione adottata si dovrà fare in modo che l’agente sia in grado
di effettuare un monitoraggio continuo sui vari dispositivi che ingloba al fine di poter
sviluppare una reattività contestuale adeguata verso l’utente e verso l’intera agenzia. Verso
l’utente fornendo informazioni coerenti sullo stato dei dispositivi e verso l’agenzia
pubblicando solo servizi e funzioni realmente eseguibili dall’agente (espansioni finali).
Nessun processo di controllo o monitoraggio per il semiagente OP era però stato preso in
considerazione nell’AGENZIA AMBIENTALE quando si è introdotto il concetto di proxy,
processo fondamentale invece per un’applicazione reale e non simulata. Infatti il proxy
risultava un semplice modulo destinato a mappare dei metodi JAVA sulle funzioni disponibili
sull’OP e si disinteressava se la comunicazione reale CO-OP fosse andata a buon fine o
meno. Senza un processo di controllo dei dispositivi l’intero sistema diventa instabile, non
efficiente e non in grado di gestire adeguatamente le variazioni del contesto. L’agente, non
potendo rendersi conto dello stato effettivo delle proprie parti operanti, non può essere in
87
grado di garantire che la comunicazione con l’OP avverrà con successo introducendo quindi
una forte aleatorietà.
Problematica accentuata in quei casi in cui il semiagente CO e alcune o tutte le componenti
dell’OP sono in esecuzione su macchine con tecnologie differenti, dove quindi la
comunicazione tra CO e OP può non essere sempre garantita.
Il caso in cui CO e OP siano fisicamente residenti su macchine con tecnologie differenti è
molto frequente in domotica. Non si può pretendere ad esempio che un interruttore abbia
sufficiente memoria e capacità di calcolo per ospitare una virtual machine JAVA ed eseguire
l’intero agente.
Per questa tesi si è posto l’obiettivo di realizzare un processo in grado di monitorare il
semiagente OP e di aumentare le capacità del proxy in modo che possa gestire anche più di
un dispositivo (Fig. 3.9) per sviluppare reattività specifiche.
3.2.5 Una tecnologia adeguata per la messa in opera del semiagente
operativo
L’AGENZIA AMBIENTALE si basa su una pianificazione dinamica dipendente dalle funzioni
e i servizi realmente disponibili. Se la tecnologia adottata per l’implementazione dei
semiagenti operativi sarà in grado di fornire il servizio di discovery si eviterà di progettare
manualmente tutta la infrastruttura per poter riconoscere se un dispositivo (e le sue funzioni)
è disponibile o meno. La tecnologia che si andrà ad utilizzare sarà adottata per tutti i
dispositivi domotici presenti. Vista l’elevata mobilità degli elettrodomestici e dei dispositivi
di una casa in genere, sarebbe auspicabile che la tecnologia preveda la possibilità di
configurazione automatica della rete dei dispositivi. Discovery e riconfigurazione automatica
della rete, combinati insieme, permettono di fornire il servizio di plug & play.
E’ utile inoltre che la tecnologia impiegata preveda un servizio di lookup al fine,
eventualmente, di poterlo sincronizzare con la lookup table di JINI (ricordo che è la tabella
che permette a JINI di fornire il servizio di lookup).
L’AGENZIA AMBIENTALE è in grado di gestire gli eventi. Anche se tale gestione non è stata
da me utilizzata per l’implementazione dell’applicazione domotica, una tecnologia adeguata
per poter interagire con l’AGENZIA AMBIENTALE dovrà essere in grado di supportare e gestire
gli eventi o almeno poter gestire degli interrupt. La gestione degli eventi ottimizza la
88
gestione per ottenere un comportamento reattivo di un agente in risposta a un evento
avvenuto sul semiagente OP.
Infine una tecnologia adeguata per la messa in opera del semiagente OP deve essere in
grado di garantire una comunicazione CO - OP stabile e veloce. Vedremo nella Sezione
4.2.1 che la scelta è caduta sulla tecnologia LONTALK (LON) e i motivi di tale scelta.
3.3 Interfaccia proxy - dispositivi
Ci si è posti il problema di progettare un’interfaccia tra il proxy e dispositivi da lui gestiti
per costituire un OP unico al fine di poter prevedere la possibilità d’implementare il
semiagente CO e parti dell’OP con tecnologie differenti. In questa sezione si lascerà da parte
per un momento l’ambito domotico e ci si concentrerà più su aspetti generali al fine di poter
fornire delle soluzioni progettuali non specifiche per la domotica ma utilizzabili in tutti i
campi in cui l’AGENZIA AMBIENTALE può essere impiegata.
3.3.1 Interfaccia proxy - dispositivi: servizi offerti e trasparenza della
tecnologia utilizzata
Per il concetto di proxy contestualizzato nell’AGENZIA
AMBIENTALE
si faccia riferimento
alla Sezione 3.1.4.
Come detto in precedenza l’AGENZIA AMBIENTALE è strutturata come un’architettura
multiagente non specializzata in nessun dominio specifico ma utilizzabile invece per diverse
applicazioni specifiche. Nella progettazione dell’interfaccia proxy – dispositivi mi sono posto
dunque il problema di definire dei servizi d’interfacciamento implementabili per differenti
tecnologie, domotiche e non, rendendo trasparente la tecnologia scelta.
Il proxy dovrà essere in grado d’interfacciarsi con la tecnologia sottostante, utilizzata per
implementare e interconnettere i dispositivi, in modo trasparente, in questo modo il proxy
implementato per un agente può essere utilizzabile con diverse tecnologie. L’agente quindi
non dovrà essere riprogettato nel caso in cui i alcune parti dell’OP venissero trasferite su una
tecnologia differente ma sarà sufficiente rimplementare solo l’interfaccia. Con un’interfaccia
di comunicazione proxy - dispositivi, inoltre, il proxy sarà in grado di comunicare con le
parti dell’OP utilizzando sempre gli stessi servizi messi a disposizione dall’interfaccia proxy
- dispositivi (vedi Fig. 3.11). In questo modo, il progettista che utilizzerà L’AGENZIA
AMBIENTALE in futuro, indipendentemente dagli agenti che andrà ad implementare, avrà a
89
disposizione sempre gli stessi servizi per comunicare con i dispositivi che costituiscono l’OP
e potrà disinteressarsi della tecnologia sulla quale, alcune parti dell’OP, sono realmente in
esecuzione.
Agente
Java
CO
Proxy
(OP)
Interfaccia proxy - dispositivo
Dispositivo
(OP)
Altra tecnologia
Hw, Sw
Figura 3.11 Interfaccia proxy - dispositivo
L’interfaccia dovrà pubblicare tutti i servizi necessari per comunicare le informazioni
relative allo stato dei dispositivi oltre che permettere la comunicazione esplicita con i
dispositivi stessi. Con i servizi offerti dall’interfaccia di comunicazione di Fig. 3.11 si deve
prevedere la possibilità di catturare e gestire gli eventi al fine di poter sfruttare a pieno la
dinamicità e la reattività dell’AGENZIA AMBIENTALE.
L’implementazione dell’interfaccia dovrà essere ottimizzata al fine di poter propagare le
informazioni tra i dispositivi e il proxy con latenze di tempo trascurabili. Il termine
trascurabile dipende dai casi specifici d’utilizzo di un agente, volendo però progettare
un’interfaccia utilizzabile da qualsiasi agente appartenente all’AGENZIA AMBIENTALE si
richiede che l’implementazione curi il più possibile l’ottimizzazione della velocità di
comunicazione, non conoscendo a priori il dominio di applicazione.
90
3.3.2 Identificazione di servizi efficaci per la comunicazione proxy dispositivi
Mi sono posto il problema di definire un’interfaccia semplice ed efficace in grado di
comunicare con i dispositivi operativi, che compongono l’OP, in modo logico, astraendo
dalla fisicità dei dispositivi stessi. A tal fine ho cercato di identificare una standardizzazione
possibile per l’informazione scambiata tra il proxy e i dispositivi che fosse adeguata per
diversi ambiti applicativi in cui l’AGENZIA AMBIENTALE potrà essere impiegata.
Questo problema non è di facile soluzione. I dispositivi esistenti per l’ubiquitous
computing sono di un’enorme eterogeneità fisica e logica. Parlare di standardizzazione o
generalizzazione senza una fase di test e verifica su un buon numero di possibilità d’impiego
delle scelte fatte può essere fallimentare. Nel capitolo successivo si vedrà in dettaglio con
quale logica di progettazione ho tentato di proporre una soluzione al problema.
91
4
PROGETTO LOGICO DELLA
SOLUZIONE DEL PROBLEMA
L’AGENZIA AMBIENTALE del precedente progetto di tesi [3] non era stata concepita con
scopi specifici per la domotica ma era stata progettata per applicazioni generiche di UC,
inoltre era stata testata solo in ambiente simulato. Per tale motivo, come riscontrato nel
Capitolo 3, l’AGENZIA AMBIENTALE presentava dei problemi per una realizzazione pratica di
un’applicazione reale e per la realizzazione specifica in ambito domotico. Per far fronte a tali
deficit ho dovuto riprogettare alcune parti dell’AGENZIA AMBIENTALE e aggiungerne delle
altre. In questo capitolo verranno presentate tutte le scelte progettuali e implementative che
ho adottato per poter utilizzare l’AGENZIA AMBIENTALE per la realizzazione di
un’applicazione domotica dimostrativa. In particolare nella Sezione 4.1 verrà esposto tutto il
processo di reingegnerizzazione dell’agente con le relative motivazioni per le scelte fatte.
Da questo capitolo in poi il modulo denominato proxy, nel precedente progetto di tesi [3],
verrà rinominato device controller per i motivi che vedremo in seguito.
Nella Sezione 4.2 verrà proposta la soluzione adottata per l’implementazione
dell’interfaccia proxy - dispositivi (ridenominata device controller - dispositivi). Nell’ultima
sezione verranno evidenziate le scelte progettuali fatte per andare incontro ad alcuni degli
aspetti ergonomici evidenziati nel Capitolo 3.
4.1 Reingegnerizzazione dell’agente, reattività e stabilità del sistema
In questo capitolo verrà descritto l’intero progetto logico di reingegnerizzazione per
l’agente puntualizzando l’attenzione su scelte progettuali strettamente legate alle funzionalità
generiche dell’AGENZIA AMBIENTALE e scelte progettuali fatte per la risoluzione di esigenze
pratiche implementative in campo domotico, al fine di far fronte ai requisiti relativi alla
stabilità del sistema e alla reattività a tutti i mutamenti sensibili del contesto.
Verrà descritto come l’agente è in grado di avere la maggior parte delle caratteristiche
auspicate con la semplice introduzione di un processo nel CO e di un nuovo metodo
specializzabile nella progettazione specifica di ogni agente.
Nella riprogettazione dell’agente sono state introdotte delle formalizzazioni per lo sviluppo
dei nuovi agenti che mi hanno permesso di sviluppare un prima reattività (standardizzata per
tutti gli agenti) verso l’agenzia (Sezione 4.1.2) e verso l’utente (Sezione 4.1.3) a fronte di
eventuali malfunzionamenti.
Successivamente mostrerò in che modo ho reso possibile la gestione di più dispositivi per
ogni agente (Sezione 4.1.4) e come tale soluzione al problema può permettere all’agente di
sviluppare delle reattività specifiche (e non solo quelle standardizzate), per ogni dispositivo,
verso l’agenzia (Sezione 4.1.5). Introdurrò inoltre la formalizzazione di un’interfaccia utente,
specializzabile da ogni agente, che permette di sviluppare delle reattività specifiche per ogni
dispositivo anche verso l’interfaccia utente (Sezione 4.1.6).
Infine concluderò con una sezione riassuntiva relativa a tutto il processo di
reingegnerizzazione dell’agente (Sezione 4.1.7) e ai nuovi meccanismi d’interazione
progettati per l’intera AGENZIA AMBIENTALE.
4.1.1 Un processo per il monitoraggio del semiagente operativo
Come detto nell’impostazione del problema di ricerca, nella realizzazione pratica di una
applicazione, e quindi non solo simulata, non si può prescindere dall’incertezza introdotta
dall’utilizzo di tecnologie e reti di connessione che potrebbero subire dei disservizi
temporanei introducendo instabilità in tutto il sistema. A tale scopo, in questa sezione,
tratterò le scelte progettuali fatte per poter far fronte ad eventuali problemi di comunicazione
tra il device controller e i dispositivi fisici (e quindi tra il CO e l’OP).
All’interno del semiagente CO, comune per tutti gli agenti, è stato inserito un processo,
chiamato OperativeAgState. Tale processo si occupa di monitorare lo stato dell’OP e viene
istanziato da un opportuno costruttore del CO, che vedremo meglio in seguito. Poiché il
processo è implementato all’interno del semiagente CO, lo stesso processo sarà presente in
tutti gli agenti e quindi non potrà conoscere a priori l’OP dell’agente. Per poter monitorare il
semiagente OP il processo di monitoraggio dovrebbe disporre però delle informazioni e delle
tecniche specifiche che gli permettano di comunicare e controllare lo stato di tutti i
dispositivi che compongono l’OP. Il processo OperativeAgState, per disporre di tali
93
informazioni, farà riferimento ad un metodo (checkOp) che sarà in grado di ritornare lo stato
complessivo dell’OP in qualsiasi momento gli venga richiesto. Tale metodo l’ho definito nel
CO affinché fosse visibile dal processo OperativeAgState ma, per poter svolgere la propria
funzione dovrà essere specializzato opportunamente dall’oggetto che estenderà il CO
(sfruttando l’overriding del linguaggio JAVA).
Nel riprogettare il semiagente CO, oltre ad avere introdotto al suo interno il processo
OperativeAgState, ho creato dei nuovi costruttori, lasciando però anche tutti i costruttori che
erano già presenti prima del mio intervento, sfruttando così la capacità del linguaggio JAVA
di overloading (per garantire la compatibilità con gli agenti già implementati). Uno dei
costruttori che ho aggiunto, che in seguito vedremo in dettaglio, prevede la possibilità di
attivare il processo OperativeAgState; il vecchio costruttore, ovviamente, non sarà invece in
grado di attivare tale processo.
L’oggetto che estenderà il CO potrà essere l’OP o il device controller (il vecchio proxy),
come spiegato nelle sezioni 3.1.3 e 3.1.4.
4.1.2 Reattività laterale (verso l’agenzia) comune a tutti gli agenti
Proporrò una trattazione più precisa del meccanismo appena descritto evidenziando i
meccanismi reattivi verso l’agenzia, formalizzati allo stesso modo per tutti gli agenti, che
possono essere ottenuti grazie a OperativeAgState e la specializzazione del metodo checkOp.
Prima di tale trattazione fornirò alcuni dettagli della classe Cooperative per introdurre alcuni
termini che verranno utilizzati e per evidenziare alcune modifiche da me introdotte in tale
classe.
Classe Cooperative
Attributo da me introdotto:
• protected boolean uiAgentRunning: tale attributo tiene memoria dello stato
d’esecuzione dell’interfaccia utente dell’agente, per i dettagli rimando alla Sezione
4.1.3.
Costruttore preesistente:
• cooperative(): per i dettagli si rimanda a [3]
94
Costruttori da me introdotti:
• (a) cooperative(String agentName, String agentUrl, int agentPort, long checkTime,
AgUserInterface agUI): si occupa di impostare alcuni attributi della classe
Cooperative, che vedremo meglio in seguito e d’istanziare e mandare in esecuzione
il processo OperativeAgState;
• (b) cooperative(String agentName,String agentUrl,int agentPort, AgUserInterface
agUI): simile al precedente solo che non manderà in esecuzione il processo
OperativeAgState.
Un metodo già esistente:
• boolean connected(): restituisce true se l’agente risulta essere connesso all’agenzia,
altrimenti restituirà false.
Un nuovo metodo introdotto:
• public boolean checkOp(){return true;}: possiede un implementazione banale di
default (return true), infatti è un metodo che andrà specializzato dalla classe che
estenderà Cooperative. Questo metodo è utilizzato dal processo OperativeAgState per
monitorare lo stato dell’OP. Tale metodo dovrà essere implementato in modo da
restituire true se esiste almeno uno tra i dispositivi appartenenti all’OP funzionante
altrimenti dovrà restituire false. Vorrei evidenziare che l’implementazione errata di
tale metodo in fase di implementazione di un nuovo agente potrebbe compromettere il
corretto funzionamento dell’intero agente.
All’interno della classe Cooperative inoltre è presente il processo OperativeAgState
(chiamato Thread in JAVA), già citato e da me creato, istanziabili e all’interno della classe
Cooperative:
• class OperativeAgState extends Thread: Questo è il processo che andrà a chiamare
ciclicamente (ogni checkTime millisecondi) il metodo checkOp, eventualmente
specializzato per monitorare lo stato dei dispositivi. Tale processo inoltre è quello
deputato a gestire una prima reattività comune per tutti gli agenti. Infatti
disconnetterà l’agente dall’agenzia quando i dispositivi non saranno più in grado di
funzionare (checkOp restituisce false), cioè quando l’agente non sarà più in grado di
essere utile in nessun modo all’agenzia. In caso contrario (checkOp restituisce true),
se l’agente non è già connesso, tenterà di connetterlo all’agenzia.
95
OP estende il CO
Nel caso semplice in cui sia l’OP ad estendere il CO e cioè nel caso in cui CO e OP siano
entrambi scritti in JAVA e possano essere in esecuzione sullo stesso sistema, il processo
OperativeAgState sarà superfluo, infatti CO e OP saranno in esecuzione come lo stesso
oggetto JAVA e dunque la comunicazione all’interno dello stesso oggetto è sicuramente
garantita. In tal caso si potrà istanziare l’OP (estensione del CO) utilizzando il costruttore
della super classe (Cooperative) da me creato e indicato con (b), (utilizzando il costruttore (a)
tutto funzionerebbe comunque ma si avrebbe un processo inutile in esecuzione) che si
occuperà solo di costruire l’oggetto, con tutti i valori opportuni degli attributi e di connettere
l’agente all’agenzia, se un’agenzia viene trovata, altrimenti rimarrà in attesa finché la
connessione all’agenzia non sarà possibile (vedi Fig. 4.2). Nel caso in cui il processo
OperativeAgState non venga utilizzato il metodo checkOp potrà anche non essere
specializzato lasciando l’implementazione di default presente in Cooperative (CO)
Chiamata al
costruttore
cooperative (b)
Agente connesso?
(connected = true ?)
No
Connetti
all’agenzia
Figura 4.2 Descrizione schematica del comportamento dell’agente nel caso in cui si utilizzi il costruttore (b)
Device controller estende il CO
Nel caso diverso e molto più comune nella pratica reale, in cui il semiagente OP sia
implementato utilizzando una tecnologia differente da quella usata per implementare il CO,
sarà il device controller ad estendere il CO (sostituendosi all’OP). Nel momento
dell’estensione del CO il device controller si dovrà occupare di specializzare il metodo
checkOp con l’implementazione opportuna (si veda Sezione 4.1.4). Per istanziare il device
controller si potrà utilizzare il costruttore della super classe Cooperative indicato con (a), che
manderà in esecuzione il processo OperativeAgState. Tale processo inizierà ad utilizzare il
metodo checkOp ad intervalli regolari definiti in un parametro del costruttore (checkTime).
Se checkOp restituirà il valore true (nel caso almeno uno dei dispositivi sia in grado di
fornire un servizio operativo), il semiagente CO tenterà automaticamente la connessione
96
all’agenzia per mezzo del processo OperativeAgState e rimarrà connesso finché checkOp
restituirà il valore true (Fig. 4.3). In questo modo l’agente verrà sconnesso dall’agenzia
quando non sarà più in grado di fornire alcuna espansione finale diminuendo il carico sul
maggiordomo che dovrà gestire dunque solo gli agenti realmente utilizzabili operativamente.
C’è da precisare che l’agente fin dal momento della creazione tenterà la connessione
all’agenzia nel caso in cui almeno uno dei dispositivi sia disponibile. Con il preesistente
costruttore della classe Cooperative veniva lasciato invece al programmatore degli agenti la
decisione di connettersi in maniera esplicita con la chiamata al metodo opportuno (connetti
[3]) e di gestire le eccezioni e le attese nel caso in cui l’agente non riuscisse a connettersi con
l’agenzia. La soluzione da me proposta è giustificata dal fatto che al momento che un agente
viene creato, vi è la volontà implicita, di chi lo ha eseguito, che l’agente tenti di connettersi
all’agenzia e inizi a funzionare in cooperazione con gli altri agenti (nel caso in cui il device
controller, sia in grado di fornire i servizi necessari affinché l’agente venga utilizzato).
Chiamata al
costruttore
cooperative (a)
Istanza ed
esecuzione di
OperativeAgState
checkOp()
false
true
Agente connesso?
(connected = true ?)
false
Connetti
all’agenzia
true
false
Agente connesso?
(connected = true ?)
true
Disconnetti
dall’agenzia
Figura 4.3 Descrizione schematica del comportamento reattivo laterale dell’agente nel caso in cui si utilizzi il
costruttore (a)
97
Rimane comunque la possibilità per l’agente di mettere a disposizione o no determinati
servizi e informazioni (ad esempio privati) e di decidere eventualmente di sconnettersi
(chiamando il metodo disconnetti [3]) o riconnettersi esplicitamente (metodo connetti [3]).
Ho deciso di seguire la strada descritta per avere una strutturazione più precisa del
comportamento comune a tutti gli agenti. Indipendentemente da altri componenti reattivi
specifici progettati per ogni singolo agente (che vedremo nelle sezioni successive), ho
cercato d’introdurre una omogeneità di reattività minima. La soluzione proposta porterà
anche ad una diminuzione dei tempi di risposta del maggiordomo e un limitato
peggioramento nell’efficacia di pianificazione. Infatti, va evidenziato che la scelta di
sconnettere l’agente quando non è più operativo potrebbe portare ad una penalizzazione
qualitativa e quantitativa della conoscenza distribuita; difatti, sconnettendo l’agente, il
maggiordomo non sarà più in grado di raggiungere la conoscenza acquisita dall’agente
sconnesso. In un sistema domotico non vi è però un grande interscambio di dispositivi che
entrano ed escono dalla rete (dall’agenzia) frequentemente, migrando da un sistema
computazionale ad un altro (da un’agenzia ad un’altra). Raramente accade dunque che un
agente abbia acquisito della conoscenza in più (espansioni intermedie) che il maggiordomo
non abbia già acquisito dall’uomo. Inoltre, come già detto, ad ogni esecuzione di un piano il
maggiordomo distribuisce tutte le espansioni intermedie a tutti gli agenti connessi. In un
sistema domotico si arriverebbe quindi, in brevissimo tempo, ad un alto grado di ridondanza
della conoscenza, dove le espansioni intermedie acquisite da un agente sono con un’altissima
probabilità anche presenti in altri agenti connessi. Sconnettendo un agente non più operativo
la perdita della conoscenza è trascurabile, invece il carico computazionale sostenuto dal
maggiordomo diminuirà. Infatti non dovrà più gestire e interrogare ad ogni pianificazione un
agente che non sarà in grado di fornirgli alcun servizio operativo (espansione finale).
L’agente sconnesso non sarà neanche più in grado di fornire al maggiordomo della
conoscenza che quasi certamente riuscirà però ad acquisire da altri agenti presenti
nell’agenzia.
Sconnettere un agente che non è più operativo è stata quindi una scelta dettata più da aspetti
specifici legati alla domotica che da aspetti generali d’UC. Maggior velocità di risposta a
fronte di una limitatissima minor efficacia. L’ottimizzazione dei tempi di risposta era uno
degli aspetti auspicati dall’impostazione del problema di ricerca.
Per completezza di seguito andrò a descrivere il significato di alcuni termini e parametri
introdotti non ancora trattati.
98
agentName: è il nome con cui l’agente verrà riconosciuto dall’agenzia, tale parametro non
era presente nel vecchio costruttore e il nome dell’agente veniva fornito al momento della
connessione esplicita all’agenzia. Poiché con i nuovi costruttori da me introdotti la
connessione è automatica al momento della creazione dell’agente vi è il bisogno di passare,
fin dalla costruzione dell’oggetto CO, il nome dell’agente. Lo stesso vale anche per agentUrl
e agentPort.
Per quanto riguarda il parametro agUI (di tipo AgUserInterface) si rimanda alla sezione
successiva.
4.1.3 Reattività superiore (verso l’interfaccia utente) comune a tutti gli
agenti
Abbiamo visto, nelle sezioni precedenti, come il processo OperativeAgState del CO,
comune a tutti gli agenti, grazie alla formalizzazione del metodo checkOp, potesse
implementare una semplice ma importante reattività laterale verso l’agenzia, standardizzata
per tutti gli agenti.
Nella versione degli agenti data in [3] la progettazione dell’interfaccia utente non era stata
formalizzata e la si riteneva implicitamente parte del semiagente OP. Io ho preferito
distinguere nettamente l’interfaccia utente dal semiagente OP, in quanto, secondo me, questi
due moduli dell’agente hanno scopi funzionali nettamente diversi. Infatti l’OP è destinato ad
interagire con l’ambiente mentre l’interfaccia utente è destinata all’interazione con l’utente
(che può essere un qualsiasi utilizzatore dell’agente). Inoltre la formalizzazione
dell’interfaccia utente, che descriverò di seguito, mi ha permesso di implementare una
reattività comune a tutti gli agenti anche verso l’utente e non solo verso l’agenzia, sfruttando
il processo OperativeAgState del CO.
La formalizzazione per la progettazione dell’interfaccia utente è stata ottenuta creando un
oggetto astratto (AgUserInterface) che ogni agente dovrà implementare ed estendere per
gestire l’interazione con l’utente.
Di seguito in dettaglio l’oggetto AgUserInterface.
public abstract class AgUserInterface{
public void startUserInterface(){}
public void stopUserInterface(){}
}
99
Sono stati definiti due metodi standard che l’interfaccia utente di ogni agente deve
possedere e implementare: startUserInterface e stopUserInterface.
•
startUserInterface: questo metodo dovrà implementare tutte le operazioni che si
vogliono svolgere al momento dell’inizio dell’esecuzione dell’interfaccia utente
(normalmente operazioni di inzializzazione).
•
stopUserInterface: questo metodo dovrà implementare tutte le operazioni che si
vogliono svolgere al momento della terminazione dell’esecuzione dell’interfaccia
utente.
Chiamata al
costruttore
cooperative (a)
Istanza ed
esecuzione di
OperativeAgState
true
checkOp
Interfaccia utente in
esecuzione?
(uiAgentRunning = true ?)
false
startUserInterface
false
true
false
Interfaccia utente in
esecuzione?
(uiAgentRunning = true ?)
true
stopUserInterface
Figura 4.4 Descrizione schematica del comportamento reattivo superiore dell’agente nel caso in cui si utilizzi
il costruttore (a)
100
Avendo definito nell’interfaccia i due metodi astratti appena descritti, OperativeAgState
può essere a conoscenza della struttura minima dell’interfaccia utente di ogni agente. Infatti
nel costruttore (a) descritto prima, fra i parametri che il device controller deve passare al
costruttore di Cooperative vi è anche un riferimento alla super classe dell’interfaccia utente
specializzata dell’agente (agUI di tipo AgUserInterface). OperativeAgState potrà intervenire
così sui metodi di startUserInterface e stopUserInterface della interfaccia utente
indipendentemente dall’agente che li specializza.
Così come OperativeAgState è in grado di svolgere operazioni reattive verso l’agenzia
(sconnettendo o riconnettendo l’agente a seconda del valore restituito da checkOp), grazie
alla formalizzazione dell’interfaccia utente proposta, è anche in grado di sviluppare una
reattività superiore, interrompendo l’esecuzione o rimettendo in esecuzione l’interfaccia
utente a seconda della capacità (checkOp restituisce true) o non (checkOp restituisce false) di
svolgere compiti operativi. In questo ultimo caso l’interfaccia utente non avrebbe più motivo
di esistere (vedi Fig. 4.4).
La sola reattività esposta in questa sezione non è sufficiente per la gestione adeguata
dell’interfaccia utente. Infatti l’interfaccia utente deve essere reattiva separatamente per ogni
specifico dispositivo e sensibile a diversi tipi di mutamento del contesto (possibilmente a tutti
quelli espressi nella Sezione 3.2.1). Vedremo nelle successive sezioni come ciò può avvenire.
La reattività minima superiore (come quella laterale descritta precedentemente),
standardizzata per tutti gli agenti, contribuisce all’omogeneità della piattaforma multiagente
messa a disposizione dall’AGENZIA AMBIENTALE. Per altri dettagli su come è possibile
utilizzare l’interfaccia utente si veda la Sezione 4.3.
4.1.4 Gestione di più dispositivi per ogni agente
Per far fronte all’esigenza di dover gestire più dispositivi fisici per ogni agente ho pensato
di utilizzare la soluzione proposta in Fig. 3.9, cioè di costruire un device controller in grado
di poter gestire e monitorare lo stato di più dispositivi. Questo è uno dei motivi per cui il
proxy è stato rinominato da me device controller, infatti, tale modulo non si limiterà ad
essere un semplice intermediario per le informazioni scambiate, ma sarà in grado di svolgere
dei compiti reattivi specifici per ogni dispositivo.
Come visto, checkOp è un metodo chiamato ciclicamente dal processo OperativeAgState
del CO a intervalli di tempo personalizzabili, tale metodo, se implementato opportunamente,
può essere sfruttato per implementare un comportamento reattivo come conseguenza di
101
eventuali malfunzionamenti dei dispositivi (implementando ad esempio una sorta di ping sui
dispositivi).
Il checkOp, ogni volta che sarà chiamato dal processo OperativeAgState, oltre ad accertarsi
del buono (o cattivo) stato dei dispositivi e quindi restituire true (o false), potrà ad ogni
chiamata svolgere delle funzioni specifiche per reagire adeguatamente ai malfunzionamenti
di ogni singolo dispositivo. Le reazioni da sviluppare saranno anche in questo caso di due
tipi: reattività superiore e reattività laterale.
4.1.5 Reattività specializzata laterale
Come anticipato nella Sezione 4.1.4, una adeguata specializzazione del metodo checkOp
permette di sviluppare anche reazioni specifiche verso l’agenzia (e verso l’interfaccia utente
come vedremo nella sezione successiva) per ogni dispositivo collegato. Infatti checkOp,
specializzato dal device controller, ha le potenzialità per poter richiedere al CO di pubblicare
o meno, verso l’agenzia (reattività laterale), determinati servizi.
Il CO memorizza i servizi che è in grado di mettere a disposizione (espansioni finali) nella
sua base della conoscenza tramite il metodo addEspansioneFinale.
Il CO notifica al maggiordomo (e quindi all’intera agenzia) i servizi che è in grado di
portare a termine (presenti nella sua base della conoscenza) al momento della connessione
all’agenzia. Implementando il checkOp in modo che elimini le espansioni finali, non
adeguate allo stato operativo dei dispositivi, dalla base di conoscenza dell’agente, è possibile
fare in modo che il maggiordomo veda solo i servizi che realmente l’agente potrà portare a
termine con i dispositivi a disposizione. Si sarà così realizzata un reattività specifica laterale.
Tale reattività sarà dunque totalmente controllata dall’implementazione del metodo checkOp.
Per chiarire il meccanismo reattivo laterale specializzabile dal checkOp riporto un semplice
esempio. Si immagini un agente deputato al controllo di due centraline per la gestione
dell’illuminazione. Inizialmente entrambe le centraline sono disponibili e quindi l’agente, al
momento della connessione, pubblicherà al maggiordomo di essere in grado di accendere e
spegnere le luci appartenenti ad entrambe le centraline. In un secondo momento, checkOp,
chiamato periodicamente da OperativeAgState, si rende conto che una delle due centraline
non è più raggiungibile. Il metodo checkOp, se implementato adeguatamente, farà in modo di
eliminare dalla base di conoscenza dell’agente tutti i servizi resi possibili (espansioni finali)
tramite la centralina non più utilizzabile. Come è stato anticipato prima, il CO comunica al
maggiordomo le proprie espansioni finali all’atto della connessione, quindi, per poter
aggiornare il maggiordomo della nuova base di conoscenza relativa alle espansioni finali, il
102
metodo checkOp dovrà occuparsi di sconnettere e riconnettere l’agente all’agenzia. Questo
metodo artificioso di connettere e sconnettere l’agente dall’agenzia è dovuto al fatto che
nell’AGENZIA AMBIENTALE non era stata prevista la possibilità di variare le espansioni finali
durante l’esecuzione dell’agente. Non prevedendo infatti la possibilità che si verificassero dei
malfunzionamenti tra il CO e l’OP, non era stata evidenziata la necessità di aggiornare le
espansioni finali. L’AGENZIA AMBIENTALE prevede che si possano aggiungere e modificare
solo le espansioni intermedie (che consistono nella nuova conoscenza acquisita dall’agente
durante la sua cooperazione e interazione con l’agenzia).
4.1.6 Reattività specializzata superiore
Allo stesso modo descritto nella sezione precedente è realizzabile dal checkOp anche una
reattività specifica verso l’interfaccia utente.
Il checkOp, specializzato dal device controller, ha le potenzialità per poter effettuare
qualsiasi intervento anche sull’interfaccia utente, sempre che si presti attenzione, durante
l’implementazione del device controller, a mantenere un riferimento verso l’interfaccia
utente implementata.
La reattività verso l’interfaccia utente non dovrà però limitarsi a prendere in considerazione
solo le informazioni contestuali relative ai malfunzionamenti, ma dovrà essere in grado di
tenere aggiornata l’interfaccia su tutti gli eventi sensibili e interessanti per l’utente, come
manifestato nell’impostazione del problema di ricerca nella Sezione 3.2.2.
Questa reattività può essere svolta dal device controller sfruttando i servizi di notifica degli
eventi messi a disposizione dall’interfaccia da me implementata tra il device controller e i
dispositivi, che vedremo in dettaglio nella Sezione 4.2.
4.1.7 Struttura logica complessiva
Nella Fig. 4.5 ho messo in evidenza come nell’AGENZIA AMBIENTALE possono coesistere
sia agenti sviluppati con la struttura proposta in [3] che i nuovi agenti progettati con la
struttura da me proposta. Inoltre ho evidenziato le interazioni superiori e laterali esistenti.
Nella Fig. 4.6 ho riportato lo schema logico di un agente (con parti dell’OP implementate
con tecnologie differenti rispetto a quelle usate per il CO) e delle sue interazioni laterali e
superiori.
103
AGENZIA AMBIENTALE
Maggiordomo
Cooperazione
CO
Cooperazione
Interazione
laterale
OP
Interazione
laterale
Interfaccia
utente
Agente A
Agente C
CO
OP
Interazione
superiore
Interfaccia
utente
CO
OP
Interfaccia
utente
Agente B
Agente D
CO
Interfaccia
utente
Proxy (OP)
Interfaccia
utente
CO
Device controller (OP)
BusControllerInterface
Dispositivi
Dispositivi
OP
(con tecnologie differenti dal CO)
A e B sono sviluppati con la struttura proposta in [3].
C e D sono implementati con la struttura da me proposta.
A e C implementano l’OP con la stessa tecnologia usata per il CO.
B e D implementano l’OP con tecnologie differenti da quella usata per il CO.
Figura 4.5 Visione complessiva dell’AGENZIA AMBIENTALE
104
I moduli BusControllerInterface e OpController verranno descritti nella Sezione 4.2. Per
gli altri moduli implementati precedentemente al mio progetto di tesi si faccia riferimento a
[3].
Agente
java.rmi.Remote
estende
CooperativeInterface
estende
Device controller interface
implementa
implementa
CO (Cooperative)
AgUserInterface
startUserInterface()
stopUserInterface()
connetti ()
disconnetti()
OperativeAgState
estende
checkOp()
estende
Device controller (OP)
Interfaccia utente
connetti()
disconnetti()
startUserInterface()
stopUserInterface()
Altri metodi facoltativi e
specifici per l’agente
implementato
checkOp()
Base della
conoscenza
OperativeAgState
OpController
implementa
BusControllerInterface
Dispositivi (OP)
(qualsiasi tecnologia Hw Sw)
Nuovi elementi rispetto a [3]
Reattività specializzate
Reattività comuni a tutti gli agenti
Figura 4.6 Schema complessivo della struttura di un agente e delle sue possibili reazioni
105
4.2 Progettazione logica dell’interfaccia device controller - dispositivi
Nelle Sezione 3.3, relativa all’impostazione del problema di ricerca, si è posto il problema
di identificare un interfaccia di comunicazione tra il proxy (diventato ora device controller) e
i dispositivi. La soluzione a questo problema verrà data in questa sezione.
In particolare nella Sezione 4.2.1 verrà motivata la scelta fatta relativa alla tecnologia
impiegata per la comunicazione tra il device controller e i dispositivi.
Nella Sezione 4.2.2 verrà descritto come è stato possibile ottenere la trasparenza dalla
tecnologia utilizzata per comunicare con i dispositivi.
Nella Sezione 4.2.3 verranno descritti i servizi offerti dall’interfaccia di comunicazione tra
il device controller e i dispositivi. Verrà descritto come i servizi identificati possano essere in
grado di far comunicare il device controller con un ampia classe di tipologie di dispositivi.
Nella Sezione 4.2.4 descriverò come fra i servizi offerti dall’interfaccia di comunicazione
tra il device controller e i dispositivi vi sia un servizio in grado di gestire gli eventi.
Nella Sezione 4.2.5, infine, si descriverà l’implementazione che ho dato all’interfaccia di
comunicazione tra il device controller e i dispositivi relativa alla tecnologia scelta.
4.2.1 LON, una tecnologia adeguata per comunicare con i dispositivi
Come risulta dalla tabella riassuntiva relativa alle tecnologie per la domotica (Tab. 2.2), sia
LON che HAVI posseggono tutte le caratteristiche auspicate nell’impostazione del problema
di ricerca (plug & play, gestione degli eventi, connessione stabile e veloce, tabella di lookup).
Anche KNX, per il mio progetto, sarebbe una tecnologia adeguata, infatti l’unico servizio non
disponibile rispetto agli altri due è la tabella dei servizi che però non è stata sfruttata nel mio
progetto.
Una differenza sostanziale tra HAVI e LON è la velocità di scambio dati. HAVI infatti
prevede che i segnali audio e video siano scambiati in digitale e dunque supporta un velocità
di comunicazione adeguata per uno streaming audio-video. LON sopperisce alla sua più bassa
velocità di scambio dati prevedendo la possibilità di trasportare l’audio e il video con segnali
analogici con l’ausilio di opportune centraline di comando.
La maggior parte dei dispositivi esistenti sul mercato, necessari in un’abitazione, sono
interfacciabili sia con tecnologia LON che HAVI che KNX. La scelta della tecnologia per la
comunicazione con dei dispositivi reali è caduta su LON in quanto lo sviluppo di tutto il
progetto di questa tesi è stato portato a termine nell’ambito di uno stage presso l’azienda
TECHSELESTA [77] che adotta, per l’implementazione dei propri sistemi, tecnologia LON.
106
4.2.2 Astrazione dalla tecnologia scelta per la comunicazione con i
dispositivi
Nella progettazione dell’interfaccia di comunicazione tra il device controller e i dispositivi
ho cercato di astrarre dalla tecnologia impiegata. Un’interfaccia che rende trasparente al
device controller la tecnologia adottata per la comunicazione con i dispositivi facilita la
portabilità e la riusabilità degli agenti su diverse tecnologie. La riusabilità è uno dei principi
fondamentali provenienti dall’ingegneria del software. Tale principio in domotica assume
una grossa importanza visto il sostanzioso numero di standard e tecnologie differenti presenti
oggi sul mercato per l’automazione domestica. Una formalizzazione di un’interfaccia in
grado di rendere trasparente la tecnologia che verrà impiegata per la comunicazione con i
dispositivi fornisce, inoltre, all’intera AGENZIA AMBIENTALE, una maggiore omogeneità di
progettazione.
Al fine di ottenere la trasparenza descritta, ho costruito un’interfaccia astratta di
comunicazione tra il device controller e i dispositivi astratta (BusControllerInterface) che
dovrà essere implementata da ogni agente a seconda della tecnologia adottata per la
comunicazione con i dispositivi.
Nella sezione successiva mi occuperò di descrivere quali sono i servizi che tale interfaccia
mette a disposizione dell’agente. Tali servizi, come vedremo, ho cercato di renderli il più
generici e plasmabili possibili al fine di poter realmente utilizzare tale interfaccia con tutti gli
agenti e i rispettivi dispositivi specifici.
4.2.3 Servizi offerti dall’interfaccia di comunicazione device controller dispositivi
I dispositivi possono essere costituiti sia da componenti che agiscono direttamente
sull’ambiente (attuatori) che da quelli che rilevano informazioni dall’ambiente (rilevatori).
Gli attuatori e i rilevatori possono essere distinti in due categorie: quelli di tipo acceso/spento
(o rileva/non rileva) che trattano informazioni in modo binario e quelli che vengono chiamati
in domotica di tipo dimmer che attuano una azione (nel caso degli attuatori) o rilevano una
informazione (nel caso dei rilevatori) in relazione a dei valori riferiti ad una precisa scala di
riferimento. I componenti dimmer non si limitano quindi a utilizzare solo un’informazione di
tipo binaria.
Di seguito riporto due esempi che chiariscono la distinzione, da me proposta, in
componenti di tipo acceso/spento e di tipo dimmer.
107
La centralina di gestione di più punti luce può essere provvista di due tipi di attuatori, quelli
di tipo acceso/spento (ad esempio dei relè) per accendere o spegnere dei punti luce e quelli di
tipo dimmer (ad esempio dei potenziometri controllabili elettronicamente) in grado di
regolare l’intensità luminosa. A seconda del tipo di comando che gli si vorrà impartire si
utilizzerà una strategia binaria oppure no.
Un altro esempio è dato dalla centralina che gestisce le schermature in grado di posizionare
su diversi livelli l’apertura di una schermatura (informazione quantitativa riferita ad una scala
di valori) e al contempo di rilevare se una finestra è aperta o meno (informazione binaria).
Da questi due esempi e da molti altri da me incontrati in fase di ricerca in ambito domotico,
mi sento di poter affermare che la suddivisione dei rilevatori e degli attuatori nelle due
tipologie acceso/spento e dimmer, mi ha permesso di progettare un’interfaccia in grado di
gestire la comunicazione con la quasi totalità dei dispositivi presenti in una casa e con buone
probabilità l’interfaccia identificata la si potrà utilizzare anche per la comunicazione con
innumerevoli dispositivi degli altri domini applicativi.
La categorizzazione relativa ai componenti dei dispositivi esposta mi ha portato ad
identificare una possibile standardizzazione relativa allo scambio d’informazioni tra il device
controller e i dispositivi.
Per la comunicazione esplicita dal device controller verso i dispositivi saranno sufficienti
solo due servizi di scrittura (uno per i componenti di tipo acceso/spento e uno per i
componenti di tipo dimmer) e due servizi di lettura.
•
setOnOff (boolean onOff, String deviceName, String onOffName);
onOff=1 (onOff=0) se si desidera mettere a on (acceso) il componente onOffName del
dispositivo deviceName.
•
boolean getOnOff (String deviceName, String onOffName);
restituisce true se il componente onOffName del dispositivo deviceName è nello stato
di on altrimenti restituise false.
•
setDimmer (real value, String deviceName, String dimmerName);
il componente dimmerName del dispositivo deviceName verrà settato con il valore
value.
•
real getDimmer (real value, String deviceName, String dimmerName);
restituisce il valore assunto dal componente dimmerName del dispositivo
deviceName.
108
I servizi con prefisso set servono per impartire dei comandi, mentre i servizi con il prefisso
get servono per acquisire delle informazioni. A seconda che si tratti di una componente di
tipo dimmer o acceso/spento si utilizzeranno i servizi rispettivamente con suffisso Dimmer
oppure OnOff.
Per utilizzare i servizi elencati il device controller dovrà conoscere solo il tipo di
componenti che compongono il dispositivo sul quale vorrà agire (dimmer o acceso/spento) e
dovrà conoscere il nome del dispositivo (l’indirizzo fisico del dispositivo sulla rete è
trasparente al device controller).
4.2.4 Gestione degli eventi
L’architettura delle agenzie è in grado di gestire anche una comunicazione ad eventi fra i
diversi agenti e gli eventi generati dagli agenti corrispondono normalmente ad eventi
accaduti nell’ambiente e quindi captati o generati dai dispositivi. Quindi un’interfaccia
completa e adeguata per la comunicazione con i dispositivi non può prescindere da tale
prerogativa.
Per fornire un servizio di comunicazione basato sulla gestione degli eventi ho pensato di
creare il seguente servizio, unico per qualsiasi tipologia delle componenti.
•
addRawUpdateListener (String deviceName, String componentName, NvListener l)
Questo servizio permette al device controller di sottoscriversi (e fornire il comportamento
desiderato tramite il listener) per la notifica di un evento generato come conseguenza al
cambiamento di stato di un componente (componentName) di uno specifico dispositivo
(deviceName). Se utilizzato in sequenza con uno dei servizi con prefisso get permette di
rilevare il nuovo valore sul componente in caso di cambiamento di stato.
La gestione degli eventi inoltre permette la comunicazione diretta tra dispositivi e il device
controller tramite il paradigma publish-subscribe.
4.2.5 Implementazione del BusControllerInterface per il bus LON
Affinché i servizi messi a disposizione dall’interfaccia device controller - dispositivi
(BusControllerInterface) possano essere implementati per il bus di comunicazione messo a
disposizione dalla tecnologia da me scelta per la comunicazione con i dispositivi (LON), è
necessario fornire un algoritmo in grado di interpretare ed eseguire fisicamente dei comandi
logici (come setOnOff o getDimmer). In questa tesi tale implementazione è stata resa
109
possibile leggendo e scrivendo opportuni valori sulle variabili di rete, pubblicate secondo lo
standard LON, dagli algoritmi implementati su ogni dispositivo presente sul bus (per i dettagli
relativi alla pubblicazione delle variabili di comunicazione tra i dispositivi e il bus LON si
faccia riferimento all’Appendice A nella sezione relativa alla tecnologia LON). C’è da
precisare che gli algoritmi sviluppati su ogni dispositivo sono stati implementati nell’ambito
di un altro progetto di tesi [79] parallelo al mio. Al fine di poter fornire un’implementazione
unica del BusControllerInterface per tutti i dispositivi presenti sulla rete LON utilizzata, io e
l’autore della tesi [79] abbiamo progettato e formalizzato una standardizzazione, che andrò di
seguito a descrivere, relativa all’implementazione degli algoritmi presenti sui singoli
dispositivi LON.
Abbiamo deciso che ogni dispositivo deve pubblicare obbligatoriamente, per poter
funzionare con l’implementazione da me realizzata (in una classe chiamata OpController,
vedi Fig. 4.6) per l’interfaccia di comunicazione tra il device controller e i dispositivi, una
variabile d’interfaccia (nvoInterface). Tale variabile conterrà tutte le informazioni sufficienti
per descrivere con quali, delle variabili di rete pubblicate dal dispositivo, si dovrà
comunicare per impartire fisicamente i comandi logici richiesti dal device controller. La
nvoInterface, presente su ogni dispositivo, dovrà contenere quindi informazioni relative ad
ogni componente di cui il dispositivo è fatto. In particolare per ogni componente dovrà
specificare:
•
nome del componente;
•
tipologia del componente (acceso/spento o dimmer);
•
nome della variabile pubblicata sulla quale scrivere o leggere per poter rilevare
(leggendo da una variabile) o attuare (scrivendo su una variabile).
Nel caso si tratti di un componente di tipo dimmer la nvoInterface dovrà inoltre fornire:
•
il massimo valore che può assumere la variabile (si è scelto per convenzione che il
valore minimo debba essere sempre zero).
Per identificare se il componente è un rilevatore o un attuatore, quindi sapere se utilizzare
rispettivamente i servizi con prefisso get o set (leggere o scrivere una variabile), abbiamo
fatto riferimento alla standardizzazione proposta da ECHELON (proprietario della tecnologia
LON) relativa ai nomi delle variabili da pubblicare. ECHELON stabilisce infatti che le variabili
che possono essere scritte dovranno utilizzare il prefisso nvi (ad esempio nviLight[1]),
mentre quelle che possono essere lette dovranno utilizzare il prefisso nvo (come, ad esempio,
110
la nvoInterface) Con la tecnologia LON non si può pubblicare una variabile che può essere sia
letta che scritta.
Per chiarire e dettagliare meglio il principio di funzionamento di OpController e del ruolo
della variabile nvoInterface, di seguito riporto un semplice esempio.
Si immagini di avere come dispositivo (di nome LightControl) una centralina in grado di
gestire una luce a relè (acceso/spento) e una luce regolabile in intensità (dimmer). La
variabile nvoInterface pubblicata dal dispositivo conterrà la seguente stringa:
•
nvoInterface=”DvState,OnOff,nvoState;light1,OnOff,nviLight[1];light1,OnOff,nvo
Light[1];light2,Dimmer,nviLight[2],200; light2,Dimmer,nvoLight[2],200”.
Tale variabile, se analizzata correttamente, informa che il dispositivo è costituito da due
componenti di nome: light1 e light2, inoltre specifica che light1 è di tipo acceso/spento
(OnOff) mentre light2 è di tipo dimmer. Dalla nvoInterface si evince, ad esempio, che per
poter accendere (mettere a ON) il componente light1 si dovrà agire sulla variabile
nviLight[1] (abbiamo scelto per convenzione che il valore 1 indica acceso e il valore 0 indica
spento). Per poter invece rilevare lo stato di light1 si dovrà leggere il valore della variabile
nvoLight[1] che avrà valore 1 se il componente light1 è acceso o 0 viceversa.
Abbiamo pensato, per permettere al device controller di effettuare il ping sui dispositivi
tramite il metodo checkOp, di considerare ogni dispositivo composto da un componente
(virtuale) che abbiamo chiamato DvState. Lo stato di tale componente sarà settato
dall’algoritmo presente sui dispositivi (settando la rispettiva variabile di rete che fa
riferimento a tale componente nvoState). DvState verrà settato come acceso (nvoState=1) se
il dispositivo sta funzionando correttamente oppure come spento in caso contrario
(nvoState=0). Se DvState risulta acceso (il servizio getOnOff chiamato per DvState restituisce
true) allora significa che il dispositivo sta funzionando correttamente. Se DvState risulta
spento (il servizio getOnOff restituisce false) significa che il dispositivo non è in grado di
funzionare correttamente. Nel caso in cui il dispositivo non sia più raggiungibile sulla rete,
neanche la sua variabile nvoInterface lo sarà più. Ma in tal caso il device controller sarà in
grado di rendersi conto che il dispositivo non è più operativo in quanto non riesce ad
accedere alla sua variabile nvoInterface, quindi, anche senza leggere lo stato del componente
DvState il device controller farà restituire false al servizio getOnOff relativo a DvState.
OpController, leggendo la nvoInterface del dispositivo interessato dalla richiesta di un
servizio con prefisso get o set e sfruttando un apposito algoritmo (dettagliato con
111
pseudocodice in Fig. 4.7), sarà in grado di convertire i comandi logici in comandi fisici
adeguati per la tecnologia LON e per l’algoritmo implementato sul dispositivo.
Si supponga ad esempio che il device controller voglia accendere la luce light1 sul
dispositivo LightControl, di conseguenza chiamerà il metodo:
setOnOff (true, LightControl, light1).
Variabili globali di OpController.
String componentType
// conterrà il tipo di componente: OnOff o dimmer
String nvName // conterrà il nome della variabile sulla quale agire per interagire con componentName
Real valueRef // conterrà il valore massimo della scala di riferimento nel caso di componente tipo dimmer
Algoritmo per l’analisi della nvoInterface in pseudocodice (implementato nel metodo chiamato varRequest).
boolean varRequest (String nvoInterface, String componentName)
{inizio
- Scandisci nvoInterface fino a che non viene trovato una sottostringa uguale a componentName o
fino alla fine della stringa
- se non si è alla fine della stringa allora:
// il componente è stato trovato
- leggi i caratteri successivi a “,” fino al successivo carattere “,”
- memorizza i caratteri letti in componentType
- se componetType=”OnOff” allora:
- leggi i caratteri successivi a “,” fino al successivo carattere “;”
- memorizza i caratteri letti in nvName
- altrimenti
- leggi i caratteri successivi a “,” fino al successivo carattere “,”
- memorizza i caratteri letti in nvName
- leggi i caratteri successivi a “,” fino al successivo carattere “;”
- trasforma i caratteri letti in valore numerico di tipo Real
- memorizza il valore in valueRef
- return true
// il componente è stato trovato
// e i valori interessati memorizzati
- altrimenti
return false
// se si è arrivati alla fine della stringa
// il componente non è stato trovato
} fine
Figura 4.7 Pseudocodice descrittivo dell’algoritmo utile all’OpController per analizzare le variabili nvoIntefrace
112
L’OpController, che contiene l’implementazione del servizio richiesto (setOnOff), andrà
inizialmente a leggere la variabile nvoInterface, presente sul dispositivo LightControl,
successivamente, la analizzerà con l’algoritmo di Fig. 4.7, e sarà così in grado di sapere che
per portare a termine il compito richiesto dovrà agire sulla variabile nviLight[1] e dunque,
per le convenzioni adottate, scriverà il valore 1 sulla variabile nviLight[1]. Se tutto è andato a
buon fine il dispositivo LightControl accenderà la luce (light1).
L’OpController agirà in modo simile anche per gestire il servizio relativo alla gestione
degli eventi (addRawUpdateListener). Dopo aver identificato la variabile sulla quale dovrà
agire, invece di scrivere o leggere dei valori gli assocerà un event listener.
Per svolgere qualsiasi operazione sulle variabili presenti nei dispositivi (leggere, scrivere e
associare degli event listener) ho utilizzato una delle librerie JAVA [74], messe a disposizione
dalla ECHELON, in grado di comunicare con un modulo presente sul bus LON chiamato LNS
SERVER che è in grado d’interfacciarsi con tutte le variabili pubblicate dai dispositivi (vedi
Fig. 4.8)
Interfaccia
utente (JAVA)
CO (JAVA)
Device controller (JAVA)
OpController (JAVA)
Librerie
JAVA
LNS SERVER
Scheda di rete
proprietaria
Bus LON
nvi 1
...
nvi n
Dispositivo 1
(Sw: Neuron C)
nvo 1
...
nvo n
...
nvi 1
...
nvi n
Dispositivo n
(Sw: Neuron C)
nvo 1
...
nvo n
Figura 4.8 Dettaglio dell’infrastruttura multi livello di un agente con i dispositivi comunicanti su bus LON
113
4.3 Dettagli implementativi attenti ad alcuni aspetti ergonomici in ambito
domotico
Ogni agente deve garantire, quando il proprio utilizzatore è l’uomo, l’accesso a tutti i
servizi messi a disposizione dal semiagente OP per i motivi espressi nell’impostazione del
problema di ricerca nella sezione relativa agli aspetti ergonomici d’interazione uomo –
ambiente (Sezione 3.2.2). Quando ho dovuto far fronte, nella realizzazione di un applicazione
domotica dimostrativa realistica, a tale esigenza, per ogni agente, ho deciso di progettare
un’interfaccia utente in grado di essere reattiva (nel modo descritto nella Seziona 4.1.3 e
nella Sezione 4.1.6) e in grado di poter comandare tutti i dispositivi gestiti dall’agente. Visto
che tale interfaccia è presente su tutti gli agenti da me implementati ho pensato, come già
detto, di formalizzare in modo preciso e omogeneo un’interfaccia utente minima,
specializzabile di volta in volta secondo le esigenze specifiche di ogni agente.
Maggiordomo
Esecutore
Interfaccia utente
Interfaccia remota
CO
device controller
Metodi per implementare
comandi locali
lightOff()
Metodi per implementare
comandi remoti
LightOffRem()
OP
Figura 4.9 Una esempio di possibile implementazione del device controller per soddisfare sia esigenze
locali, provenienti dall’interfaccia utente, che esigenze provenienti dal maggiordomo.
Abbiamo visto nella Sezione 4.1 come un’adeguata implementazione del metodo checkOp
può permettere al device controller di intervenite in modo reattivo sull’interfaccia utente
realizzando un efficace monitoraggio dei dispositivi di un agente. Per permettere, non solo il
114
monitoraggio, ma anche un controllo diretto sui dispositivi da parte dell’utente, si devono
implementare l’interfaccia utente e il device controller in modo opportuno da permettere, non
solo il flusso d’informazioni diretto dai dispositivi all’utente (monitoraggio), ma anche quello
inverso. Il device controller oltre ad essere dotato di metodi che implementano servizi remoti
disponibili per l’intera agenzia e comandabili dall’esecutore del maggiordomo (come
descritto in [3]), dovrà essere quindi dotato anche di metodi che servono per implementare
servizi, messi a disposizione dai dispositivi, comandabili direttamente e localmente
dall’interfaccia utente (vedi Fig. 4.9).
Vedremo alcuni esempi di implementazione dell’interfaccia utente e dal device controller
in dettaglio nel capitolo successivo.
La formalizzazione di un’interfaccia utente mi ha permesso inoltre, come vedremo nel
capitolo successivo, di far fronte ad un’ottimizzazione dei tempi di risposta del sistema
domotico.
115
5
REALIZZAZIONI
SPERIMENTALI E
VALUTAZIONI
Uno degli obiettivi di questa tesi è la realizzazione pratica di un’applicazione domotica
dimostrativa in grado di validare la capacità dell’AGENZIA AMBIENTALE di risolvere problemi
d’alto livello d’astrazione utilizzando una pianificazione dinamica. Le realizzazioni
sperimentali, come vedremo, dimostreranno come l’AGENZIA AMBIENTALE sia in grado di
pianificare delle soluzioni per far fronte a delle esigenze d’alto livello d’astrazione (goal), in
modo dinamico, in relazione agli agenti e ai servizi che ha a disposizione al momento della
pianificazione.
Le realizzazioni sperimentali hanno portato a verificare anche che le soluzioni logiche da
me adottate e descritte nel Capitolo 4 possono, nella pratica, realmente essere utilizzate per
permettere ad ogni agente di sviluppare delle reattività laterali e superiori.
Tutte le realizzazioni sperimentali che presenterò in questo capitolo dimostreranno come
l’interfaccia di comunicazione tra il device controller e i dispositivi sia adeguata per
l’applicazione domotica realizzata e come con tale interfaccia sia possibile far fronte ad
eventuali malfunzionamenti o agganci e sganci a caldo dei dispositivi.
Vedremo come la formalizzazione dell’interfaccia utente per ogni agente sia stata utilizzata
per realizzare delle interfacce di comunicazione tra l’uomo e gli agenti.
Preciso che non tutta l’applicazione domotica realizzata è stata progettata da me, alcune
parti, relative ai dispositivi, sono state progettate e realizzate in un altro progetto di tesi
parallelo al mio [79]. Vedremo nelle sezioni successive, in dettaglio, solo ciò che è stato
realmente progettato e realizzato da me e verranno solo citate, per completezza della
trattazione, le realizzazioni fatte nell’ambito della tesi [79].
5.1 L’applicazione domotica realizzata
L’applicazione domotica dimostrativa realizzata si occupa di gestire l’illuminazione, il
riscaldamento, un rilevatore di presenza e una finestra. Uno dei compiti, d’alto livello, che
tale applicazione riesce a portare a termine è la razionalizzazione dell’energia in funzione dei
dispositivi realmente utilizzabili. Come vedremo, al momento della richiesta da parte
dell’utente di attivare il sistema per il risparmio energetico (EnergySaving), l’applicazione
coinvolgerà tutti gli agenti disponibili per realizzare un piano d’azione che permetta di
risparmiare energia. Vedremo nella Sezione 5.3, dedicata alle decomposizioni dei goal (che
costituiscono la conoscenza iniziale del maggiordomo), come funziona in dettaglio
l’EnergySaving.
5.1.1 Servizi e funzioni
L’applicazione realizzata, per poter comunicare con l’uomo, utilizza le interfacce utente
degli agenti e in particolare l’interfaccia utente di un agente specifico (GoalGenerator)
progettato solo per raccogliere le richieste di esigenze d’alto livello, che necessitano cioè
dell’intervento del maggiordomo; si rimanda alla Sezione 5.1.2 per il dettaglio sulla
realizzazione dell’interfacciamento dell’uomo con l’applicazione domotica realizzata. In
particolare l’applicazione realizzata permette all’utente, tramite l’uso di un’interfaccia
grafica, i seguenti servizi (e funzioni).
•
Accensione e spegnimento di una luce.
•
Apertura e chiusura di una finestra motorizzata. L’azienda che mi ha ospitato per
svolgere le realizzazioni sperimentali [75] non mi ha fornito un motore attuatore per
l’apertura e la chiusura della finestra. Quindi è stato progettato solo il controllore per
un eventuale motore d’attuazione. Tale controllore dà il comando al motore (anche se
non collegato) di aprire o chiudere la finestra; vedremo in seguito che è possibile
117
vedere quando il controllore fornisce il comando di apertura o chiusura con l’ausilio
di un led.
•
Accensione, spegnimento e regolazione della potenza del riscaldamento. C’è da
precisare che per il controllo del riscaldamento non è stata fatta una realizzazione
pratica reale (utilizzando cioè un controllore su una pompa di calore) ma è stato
utilizzato un software che simula un riscaldamento. Tale software (denominato
Heating) era già stato sviluppato nel progetto di tesi [3].
•
Attivazione o disattivazione dell’EnergySaving.
Inoltre, l’utente avrà la possibilità di monitorare in ogni istante e in tempo reale (con
qualche latenza che vedremo in seguito) lo stato dei dispositivi appartenenti all’applicazione
domotica. In particolare potrà rendersi conto dei seguenti stati.
•
Luce accesa o spenta.
•
Finestra aperta o chiusa; sia che sia stata aperta manualmente sia che sia stata aperta
sfruttando la motorizzazione.
•
Presenza umana o no nella stanza.
•
EnergySaving in esecuzione o no.
L’applicazione domotica, che ricordo è stata realizzata anche grazie ad un altro progetto di
tesi [79] parallelo al mio, è in grado di fornire tutte le funzionalità descritte anche senza
l’AGENZIA AMBIENTALE connessa sulla rete, ad esclusione della funzione di EnergySaving.
Infatti la rete domotica dei dispositivi è stata progettata in modo che continui a funzionare
anche senza la presenza dell’AGENZIA AMBIENTALE (stand alone). In caso di
malfunzionamento dell’AGENZIA AMBIENTALE o di parte di essa, i dispositivi presenti sulla
rete domotica potranno ancora essere utilizzati. Ovviamente non saranno più possibili i
servizi che, per funzionare, necessitano dell’ausilio dell’AGENZIA AMBIENTALE (come
l’EnergySaving). Tutta la progettazione e la realizzazione stand alone è stata realizzata nel
progetto di tesi [79]. Per tale motivo non descriverò in dettaglio come è possibile ottenere
tutte le funzionalità stand alone senza l’ausilio dell’AGENZIA AMBIENTALE e delle interfacce
utente degli agenti. Per tale trattazione si rimanda quindi a [79].
118
5.1.2 Interazione superiore: interfaccia uomo - applicazione domotica
Nella progettazione di ogni agente, come detto nel Capitolo 4, ho previsto l’esistenza di
un’interfaccia utente in grado di agire direttamente sui dispositivi e sui servizi operativi che
l’agente è in grado di mettere a disposizione. Tale interfaccia, con un’adeguata
implementazione, è in grado di sviluppare una reattività superiore adeguata al contesto.
Per interfacciare l’uomo con l’applicazione domotica ho pensato di far gestire ad ogni
agente implementato un’interazione specifica con l’uomo, creando così una sorta
d’interfaccia complessiva decentralizzata. Per fare ciò ho utilizzato il modulo destinato
all’interfaccia utente (AgUserInterface) di ogni agente specializzandolo per l’interazione con
l’uomo. Ho progettato, per ogni agente presente nel mio sistema, un’interfaccia grafica che
mette a disposizione dell’uomo tutti i servizi operativi dell’agente (come auspicato nella
Sezione 3.2.2). Inoltre, tale interfaccia, sfruttando i meccanismi descritti nel Capitolo 4, è in
grado di garantire una reattività in tempo reale relativa allo stato dei dispositivi e del
contesto.
Il risultato di questa scelta implementativa è un’interfaccia di comunicazione, tra l’uomo e
l’applicazione domotica, composta dalla somma delle singole interfacce di ogni agente,
totalmente decentralizzata e “autocomponibile”. Decentralizzata perché ogni agente gestisce
il proprio rapporto con l’uomo. Autocomponibile in quanto ogni singola interfaccia, come
detto, è reattiva allo stato dei dispositivi, del contesto e dei servizi che l’agente è in grado
realmente di garantire. Dunque, l’interfaccia globale complessiva risulterà essere in continua
evoluzione, dipendente dal contesto e in grado di interfacciare l’uomo solo con i servizi
realmente esistenti.
Per spiegare più concretamente ciò che ho realizzato riporto un esempio pratico. Ho creato,
come vedremo meglio in nella Sezione 5.2.2, un agente deputato alla gestione della luce
(LightAg). L’interfaccia utente di tale agente è stata implementata graficamente in modo che
l’uomo possa accendere e spegnere la luce e al contempo monitorare lo stato attuale della
luce (vedi Fig. 5.1).
Tra gli altri agenti che ho creato vi è anche l’agente deputato alla rilevazione di presenza
umana (HPresenceDetector). L’interfaccia utente di tale agente è stata implementata
graficamente in modo che l’uomo possa rendersi conto se l’agente sta rilevando presenza
umana o meno (vedi Fig. 5.1).
Se entrambi gli agenti sono in esecuzione e i rispettivi OP stanno funzionando
correttamente, allora l’uomo si troverà di fronte sia all’interfaccia di LightAg che a quella di
119
HPresenceDetector. Si sarà così composta un’interfaccia complessiva derivata dalla somma
delle due. Se, ad esempio però, la centralina della luce, gestita da LightAg, viene sganciata
dalla rete (a caldo), LightAg si rende conto che non sarà più in grado di fornire servizi e
sfruttando il meccanismo per la reattività superiore spiegato nel Capitolo 4, chiuderà la
propria interfaccia utente modificando automaticamente l’interfaccia complessiva a
disposizione dell’uomo. Se la centralina dovesse essere successivamente riagganciata, allora
LightAg si renderà conto che potrà di nuovo mettere a disposizione dei servizi e rimetterà a
disposizione
l’interfaccia
utente
(ne
risulta
quindi
un’interfaccia
complessiva
autocomponibile). Vedremo meglio in dettaglio il funzionamento specifico di ogni agente
implementato nella Sezione 5.2.
Delegare ad ogni agente il compito di gestire il rapporto tra l’uomo e i servizi messi a
disposizione dall’agente stesso permette all’intera applicazione domotica di poter soddisfare
le esigenze che non richiedono pianificazione e cooperazione fra agenti in modo rapido ed
efficiente senza coinvolgere il maggiordomo inutilmente.
La scelta progettuale fatta, in cui ogni agente mette a disposizione dell’uomo solo i propri
servizi operativi, non consente però all’uomo di sollevare, nei confronti dell’AGENZIA
AMBIENTALE (del sistema domotico), esigenze d’alto livello (goal) la cui soddisfazione
richiede pianificazione e cooperazione fra diversi agenti e dispositivi. Ho realizzato un
agente specifico (GoalGenerator) deputato alla generazione dei goal. Tale agente fa in modo
che l’uomo possa sollevare tutte le esigenze potenzialmente soddisfabili dal maggiordomo.
Il GoalGenerator rappresenta la componente centralizzata dell’intera interfaccia
dell’applicazione domotica. I servizi operativi che il GoalGenerator “dichiara”, tramite la
propria interfaccia utente, di poter realizzare, sono potenzialmente quindi tutte le esigenze
che il maggiordomo, tramite la pianificazione e la cooperazione, potrebbe essere in grado di
soddisfare. Il GoalGenerator si occupa di raccogliere dunque delle esigenze (goal) e di
trasmetterle al maggiordomo, il quale si occuperà di gestirle. C’è da evidenziare che il
maggiordomo, quando riceve un goal, non è in grado di notificare a chi lo ha generato se
l’obiettivo rappresentato dal goal è stato raggiunto o no (cioè se è stato trovato un piano e se
questo è stato eseguito correttamente). Poiché nella mia tesi non mi sono occupato di
modificare il maggiordomo ma ho utilizzato il preesistente [3], non sono stato in grado di
realizzare una reattività superiore per il GoalGenerator. Tale agente, infatti, invia dei goal al
maggiordomo ma non saprà mai se i goal sono stati soddisfatti e quindi non sarà in grado di
notificarlo all’uomo tramite l’interfaccia utente.
120
Agente: Heating
Interfaccia
utente
Agente: WindowAg
Interfaccia
utente
CO
OP
CO
OP
Agente: GoalGenerator
Interfaccia
utente
CO
OP
Agente: HPresenceDetector
Interfaccia
utente
CO
OP
Agente: LightAg
Interfaccia
utente
CO
OP
Figura 5.1 Interfaccia uomo - applicazione domotica autocomponibile e decentralizzata
121
L’uomo, che ha manifestato l’esigenza tramite il GoalGenerator, nella maggior parte dei
casi sarà in grado comunque di percepire se la propria esigenza è stata soddisfatta o meno,
osservando le reazioni contestuali delle interfacce utente degli altri agenti.
I servizi che il GoalGenerator può mettere a disposizione dell’uomo sono potenzialmente
tutti i tipi di espansioni presenti nella base di conoscenza del maggiordomo e quindi anche
tutti i servizi messi a disposizione singolarmente da ogni agente (espansioni finali). Per
esigenze sperimentali ho implementato il GoalGenerator in modo che questo metta a
disposizione due espansioni finali risolvibili da LightAg (accensione e spegnimento di una
luce, vedi Fig. 5.1). L’utilizzatore dell’applicazione domotica potrà così decidere di
accendere o spegnere la luce sia intervenendo direttamente e localmente sull’interfaccia
utente del LightAg sia agendo sull’interfaccia utente del GoalGenerator (per ulteriori dettagli
si veda la Sezione 5.3.2). Vedremo nelle valutazioni sperimentali come le due strade portano
a tempi di risposta notevolmente differenti.
5.2 Agenti realizzati
Per realizzare l’applicazione domotica, descritta finora solo dal punto di vista funzionale,
ho implementato quattro nuovi agenti (LightAg, HPresenceDetector, WindowAg,
GoalGenerator) e ne ho utilizzato uno realizzato in un precedente progetto di tesi [3]
(Heating).
Gli agenti realizzati sfruttano la maggior parte dei meccanismi da me progettati e descritti
nel Capitolo 4, per permettere i diversi tipi di reattività superiore e laterale. Inoltre gli agenti
comunicano con i dispositivi presenti su una rete LON sfruttando l’interfaccia di
comunicazione descritta nella Sezione 4.2.
Nelle sezioni successive verrà data una panoramica di tutti gli agenti utilizzati per
realizzare l’applicazione domotica e successivamente verranno descritti dettagliatamente i
moduli e la logica di funzionamento di ogni metodo implementato per ogni agente realizzato.
Con un’elencazione dei metodi principali e con la spiegazione puntuale delle rispettive
implementazioni descriverò la logica di funzionamento di tutti gli agenti realizzati.
Per chiarezza specifico che il nome della classe che serve per implementare il device
controller coincide con il nome dato al rispettivo agente, ma non bisogna confondere l’agente
(composto da CO e l’OP gestito dal device controller) con il device controller stesso.
122
5.2.1 Una visione d’insieme degli agenti e dei dispositivi
Di seguito farò una panoramica dell’hardware impiegato presso l’azienda TECHSELESTA
[77] per la realizzazione dell’applicazione domotica.
L’agente deputato al controllo della luce, LightAg, utilizza la centralina LON (IOC306)
rappresentata schematicamente nella Fig. 5.2. Tale centralina ha la possibilità di controllare
sia uscite binarie (relè) che uscite analogiche (potenziometri), inoltre è dotata di led
comandabili. LightAg utilizza, per accendere o spegnere il punto luce, un’uscita relè, e
segnala con un led sulla centralina se la luce è accesa o spenta.
LightAg
CO
e
device
controller
Bus LON
IOC306
Generatore di
tensione 220 Volt
Punto
luce
Figura 5.2 Dispositivi di LightAg
123
L’agente che si occupa di rilevare la presenza umana nell’ambiente utilizza un rilevatore di
presenza interfacciabile su rete LON (HPresenceOp), vedi Fig. 5.3. Tale rilevatore avverte il
device controller quando rileva una presenza nell’ambiente.
HPresenceDetector
CO
e
device
controller
Bus LON
HPresenceOP
Trasformatore
Figura 5.3 Dispositivi di HPresenceDetector
L’agente deputato al controllo della finestra, WindowAg, utilizza un pulsante a pressione
presente su una pulsantiera (TAST) costituita da quattro pulsanti, interfacciabile con la rete
LON (vedi Fig. 5.4). Il pulsante evidenziato in Fig 5.4 è stato utilizzato per simulare l’apertura
124
o chiusura della finestra; finché tale pulsante rimane premuto TAST segnala al device
controller che la finestra è chiusa, altrimenti segnala al device controller che la finestra è
aperta e accende il led presente sul pulsante. Il dispositivo TAST è anche utilizzato per alcune
funzioni stand alone della rete domotica LON, come l’accensione e lo spegnimento del punto
luce, per i dettagli si veda [79].
WindowAg
CO
e
device
controller
Bus LON
Trasformatore
TAST
Figura 5.4 Dispositivi di WindowAg
125
Il GoalGenerator utilizza la stessa centralina di LightAg per segnalare, con un led (vedi
Fig. 5.5), quando l’utente ha richiesto l’accensione dell’EnergySaving.
GoalGenerator
CO
e
device
controller
Bus LON
IOC306
Generatore di
tensione 220 Volt
EnergySaving
acceso
Figura 5.5 Dispositivi del GoalGenerator
126
Di seguito una foto panoramica di tutti i dispositivi utilizzati per la realizzazione
sperimentale (vedi Fig. 5.6) con, in evidenza, un dispositivo non ancora mostrato.
Scheda di rete che permette d’interfacciare la rete LAN alla rete LON
Figura 5.6 Panoramica complessiva dei dispositivi utilizzati per le prove sperimentali
5.2.2 Agente LightAg
Riporto di seguito i moduli di cui è composto LightAg e per ogni modulo tratterò solo i
metodi significativi per il funzionamento logico dell’agente, tralasciando alcuni dettagli
implementativi. Per le interazioni tra i moduli dell’agente e tra l’agente e l’esterno si faccia
riferimento alla Fig. 5.7.
•
public
class
LightAgUserInterface
extends
AgUserInterface:
questa
classe
rappresenta l’interfaccia utente dell’agente e implementa i seguenti metodi.
o public void startUserInterface(): si occupa di rendere visibile l’interfaccia grafica.
127
o public void stopUserInterface(): si occupa di rendere non più visibile l’interfaccia
grafica.
o public void actionExecuted (String actionName): serve al device controller per
notificare all’interfaccia utente quale azione (actionName) è stata attuata o rilevata
(con successo) dal device controller.
LightAg
Esecutore del
maggiordomo
Uomo (utente)
Device controller interface
Interfaccia utente
turnOffLight
turnOnLight
userInterfaceClosed
actionExecuted
lightOffRem
lightOnRem
isLightOn
lightUState
Device controller
setOnOff
getOnOff
addRawUpdateListener
OpController
Dispositivo: IOC306
Ambiente
Figura 5.7 Descrizione schematica delle attività interne ed esterne di LightAg
•
public class LightAg extends Cooperative implements LightAgInterface: questa classe
rappresenta il modulo device controller, estende la classe Cooperative (CO) e
implementa LightAgInterface (che rappresenta il device controller interface) per
l’interfaccia remota (o laterale) specifica dell’agente. La classe implementa i seguenti
metodi.
128
o public LightAg(String agentName, String agentUrl,int agentPort, long checkTime,
LightAgUserInterface agUI, OpController bc) throws RemoteException: è il
costruttore del device controller; agentName, agentUrl, agentPort, checkTime e
agUI sono tutti parametri che servono per poter chiamare il costruttore della super
classe (Cooperative); bc rappresenta il riferimento al modulo OpController che,
come detto, è l’implementazione del BusControllerInterface ed è in grado di
dialogare con il dispositivo IOC306.
o public boolean checkOp(): chiama il metodo getOnOff (“ IOC306”, ”DvState”)
per leggere il valore di DvState del dispositivo IOC306, se getOnOff restituisce
true (DvState=ON, il dispositivo funziona correttamente) allora checkOp
restituisce true altrimenti restituisce false.
o public void lightOn(): memorizza lo stato acceso della luce e notifica
all’interfaccia
utente
che
la
luce
è
accesa,
chiamando
il
metodo
actionExecuted(“lightOn”).
o public void lightOff(): memorizza lo stato spento della luce e notifica
all’interfaccia
utente
che
la
luce
è
spenta,
chiamando
il
metodo
actionExecuted(“lightOff”).
o public void lightBusListener():aggiunge un listener sul relè del dispositivo
IOC306 che gestisce la luce della centralina IOC306 e fornisce, al gestore degli
eventi di OpController, il comportamento desiderato quando avviene un
cambiamento di stato: chiama il metodo lightOn() se la luce risulta accesa
altrimenti chiama lightOff(). Inoltre questo metodo assegna un listener anche al
componente DvState specificando che, nel caso venga notificato un cambio di
stato, si dovrà chiamare checkOp.
o public void turnOffLight(): spegne la luce e lo notifica all’interfaccia utente nel
caso la luce si sia realmente spenta. Questo metodo è chiamato localmente
dall’interfaccia utente quando l’utente comunica di voler spegnere la luce.
o public void turnOnLight(): accende la luce e lo notifica all’interfaccia utente nel
caso la luce si sia realmente accesa. Questo metodo è chiamato localmente
dall’interfaccia utente quando l’utente comunica di voler spegnere la luce.
o public void userInterfaceClosed(): questo metodo è chiamato dall’interfaccia
utente nel caso l’interfaccia grafica venga chiusa espressamente dall’utente
129
(esprimendo quindi la volontà di terminare l’agente). Tale metodo, se chiamato,
sconnette l’agente dall’agenzia e termina tutti i processi in esecuzione.
Di seguito riporto tutti i servizi pubblicati da LightAg verso l’agenzia che possono
essere chiamati in modo remoto dall’esecutore del maggiordomo. Tali metodi saranno
quelli realmente utilizzabili per la costruzione delle espansioni finali relative al
LightAg.
o public String isLightOn() throws RemoteException: restituisce yes se la luce è
accesa.
o public void lightOffRem() throws RemoteException: spegne la luce e lo notifica
all’interfaccia utente solo se la luce si è realmente spenta.
o public void lightOnRem() throws RemoteException: accende la luce e lo notifica
all’interfaccia utente solo se la luce si è realmente accesa.
o public String lightUState() throws RemoteException: restituisce on se nell’ultima
interazione con l’interfaccia utente locale l’uomo aveva acceso la luce; restituisce
off se invece l’utente aveva spento la luce.
•
public interface LightAgInterface extends Remote: questa classe serve al CO per poter
pubblicare verso l’agenzia tutti i metodi chiamabili remotamente appena descritti.
Al momento dell’istanza di LightAg ho deciso di porre:
•
checkTime = 5000 (5 secondi);
•
agentName = “LightAg”;
•
agentUrl = “10.0.0.1” (indirizzo IP di classe A sul quale è indirizzata l’intera
AGENZIA AMBIENTALE);
•
agentPort= “4160” (numero di porta aperta su JINI per comunicare con l’AGENZIA
AMBIENTALE).
5.2.3 Agente HPresenceDetector
Riporto di seguito i moduli di cui è composto HPresenceDetector e per ogni modulo
tratterò solo i metodi significativi per il funzionamento logico dell’agente, tralasciando alcuni
dettagli implementativi. Per le interazioni tra i moduli dell’agente e tra l’agente e l’esterno si
faccia riferimento alla Fig. 5.8.
130
HPresenceDetector
Esecutore del
maggiordomo
Uomo (utente)
Device controller interface
Interfaccia utente
userInterfaceClosed
ishPresence
actionExecuted
Device controller
getOnOff
addRawUpdateListener
OpController
Dispositivo: HPresenceOP
Ambiente
Figura 5.8 Descrizione schematica delle attività interne ed esterne di HPresenceDetector
•
public class HPresenceDetectorUserInterface extends AgUserInterface: questa classe
rappresenta l’interfaccia utente dell’agente e implementa i seguenti metodi:
o public void startUserInterface(): si occupa di rendere visibile l’interfaccia grafica.
o public void stopUserInterface(): si occupa di rendere non più visibile l’interfaccia
grafica.
o public void actionExecuted(String actionName): serve al device controller per
notificare all’interfaccia utente quale azione (actionName) è stata rilevata (con
successo) dal device controller.
•
public
class
HPresenceDetector
extends
Cooperative
implements
HPresenceDetectorInterface: questa classe rappresenta il modulo device controller,
131
estende la classe Cooperative (CO) e implementa HPresenceDetectorInterface (che
rappresenta il device controller interface) per l’interfaccia remota (o laterale)
specifica dell’agente. La classe implementa i seguenti metodi.
o public HPresenceDetector(String agentName, String agentUrl, int agentPort,
long checkTime, HPresenceDetectorUserInterface agUI, OpController bc) throws
RemoteException: è il costruttore del device controller; agentName, agentUrl,
agentPort, checkTime e agUI sono tutti parametri che servono per poter chiamare
il costruttore della super classe (Cooperative); bc rappresenta il riferimento al
modulo OpController (in grado di dialogare con il dispositivo HPresenceOP).
o public boolean checkOp(): chiama il metodo getOnOff (“HPresenceOP”,
”DvState”) per leggere il valore di DvState del dispositivo HPresenceOP, se
getOnOff restituisce true (DvState=ON, il dispositivo funziona correttamente)
allora checkOp restituisce true altrimenti restituisce false.
o public void hPresence(): memorizza lo stato di rilevazione di presenza e notifica
all’interfaccia utente che vi è rilevazione di presenza, chiamando il metodo
actionExecuted(“hPresence”).
o public void noHPresence (): memorizza lo stato di non rilevazione di presenza e
notifica all’interfaccia utente che non vi è rilevazione di presenza, chiamando il
metodo actionExecuted(“noHPresence”).
o public void hPresenceBusListener(): aggiunge un listener sul sensore di
rilevazione di presenza (l’unico componente del dispositivo HPresenceOp) e
fornisce, al gestore degli eventi di OpController, il comportamento desiderato
quando avviene un cambiamento di stato: chiama il metodo hPresence() se vi è
stata una rilevazione di presenza altrimenti chiama windowClose (). Inoltre questo
metodo assegna un listener anche al componente DvState specificando che, nel
caso venga notificato un cambio di stato, si dovrà chiamare checkOp.
o public void userInterfaceClosed(): questo metodo è chiamato dall’interfaccia
utente nel caso l’interfaccia grafica venga chiusa espressamente dall’utente
(esprimendo quindi la volontà di terminare l’agente). Tale metodo, se chiamato,
sconnette l’agente dall’agenzia e termina tutti i processi in esecuzione.
o public String ishPresence() throws RemoteException: restituisce yes se vi è
presenza rilevata altrimenti restituisce no. Questo è un servizio pubblicato da
HPresenceDetector verso l’agenzia e chiamabile remotamente; questo metodo è
132
quello utilizzabile per la costruzione delle espansioni finali relative al
HPresenceDetector ed è quello che può essere chiamato dall’esecutore del
maggiordomo.
•
public interface HPresenceDetectorInterface extends Remote: questa classe serve al
CO per poter pubblicare verso l’agenzia il metodo appena descritto che può essere
chiamato in modo remoto.
Al momento dell’istanza di HPresenceDetector ho deciso di porre:
•
checkTime = 5000 (5 secondi);
•
agentName = “HPresenceDetector”;
•
agentUrl = “10.0.0.1” (indirizzo IP di classe A sul quale è indirizzata l’intera
AGENZIA AMBIENTALE);
•
agentPort= “4160” (numero di porta aperta su JINI per comunicare con l’AGENZIA
AMBIENTALE).
5.2.4 Agente WindowAg
Riporto di seguito i moduli di cui è composto WindowAg e per ogni modulo tratterò solo i
metodi significativi per il funzionamento logico dell’agente, tralasciando alcuni dettagli
implementativi. Per le interazioni tra i moduli dell’agente e tra l’agente e l’esterno si faccia
riferimento alla Fig. 5.9.
•
public class WindowAgUserInterface extends AgUserInterface: questa classe
rappresenta l’interfaccia utente dell’agente e implementa i seguenti metodi:
o public void startUserInterface(): si occupa di rendere visibile l’interfaccia grafica.
o public void stopUserInterface(): si occupa di rendere non più visibile l’interfaccia
grafica.
o public void actionExecuted(String actionName): serve al device controller per
notificare all’interfaccia utente quale azione (actionName) è stata attuata o rilevata
(con successo) dal device controller.
133
WindowAg
Esecutore del
maggiordomo
Uomo (utente)
Device controller interface
Interfaccia utente
closeWindow
openWindow
userInterfaceClosed
isWindowOpen
actionExecuted
Device controller
setOnOff
getOnOff
addRawUpdateListener
OpController
Dispositivo: TAST
Ambiente
Figura 5.9 Descrizione schematica delle attività interne ed esterne di WindowAg
•
public class WindowAg extends Cooperative implements WindowAgInterface: questa
classe rappresenta il modulo device controller, estende la classe Cooperative (CO) e
implementa WindowAgInterface (che rappresenta il device controller interface) per
l’interfaccia remota (o laterale) specifica dell’agente. La classe implementa i seguenti
metodi.
o public WindowAg(String agentName, String agentUrl, int agentPort, long
checkTime,
WindowAgUserInterface
agUI,
OpController
bc)
throws
RemoteException: è il costruttore del device controller; agentName, agentUrl,
agentPort, checkTime e agUI sono tutti parametri che servono per poter chiamare
il costruttore della super classe (Cooperative); bc rappresenta il riferimento al
modulo OpController (in grado di dialogare con il dispositivo TAST).
134
o public boolean checkOp(): chiama il metodo getOnOff (“TAST”, ”DvState”) per
leggere il valore di DvState del dispositivo TAST, se getOnOff restituisce true
(DvState=ON, quindi il dispositivo funziona correttamente) allora checkOp
restituisce true altrimenti restituisce false.
o public void windowOpen(): memorizza lo stato aperto della finestra e notifica
all’interfaccia utente che la finestra è aperta, chiamando il metodo
actionExecuted(“windowOpen”).
o public void windowClose(): memorizza lo stato chiuso della finestra e notifica
all’interfaccia utente che la finestra è chiusa, chiamando il metodo
actionExecuted(“windowClose”).
o public void windowBusListener(): aggiunge un listener sul sensore della finestra
(un pulsante di TAST) e fornisce, al gestore degli eventi di OpController, il
comportamento desiderato quando avviene un cambiamento di stato: chiama il
metodo windowOpen() se la finestra risulta aperta altrimenti chiama
windowClose(). Inoltre questo metodo assegna un listener anche al componente
DvState specificando che, nel caso venga notificato un cambio di stato, si dovrà
chiamare checkOp.
o public void openWindow(): apre la finestra e lo notifica all’interfaccia utente nel
caso la finestra si sia realmente aperta. Questo metodo è chiamato localmente
dall’interfaccia utente quando l’utente comunica di voler aprire la finestra.
o public void closeWindow(): chiude la finestra e lo notifica all’interfaccia utente
nel caso la finestra si sia realmente chiusa. Questo metodo è chiamato localmente
dall’interfaccia utente quando l’utente comunica di voler chiudere la finestra.
o public void userInterfaceClosed(): questo metodo è chiamato dall’interfaccia
utente nel caso l’interfaccia grafica venga chiusa espressamente dall’utente
(esprimendo quindi la volontà di terminare l’agente). Tale metodo, se chiamato,
sconnette l’agente dall’agenzia e termina tutti i processi in esecuzione.
o public String isWindowOpen() throws RemoteException: restituisce yes se la
finestra è aperta altrimenti restituisce no. Questo è un servizio pubblicato da
WindowAg verso l’agenzia e chiamabile remotamente; questo metodo è quello
utilizzabile per la costruzione delle espansioni finali relative al WindowAg ed è
quello che può essere chiamato dall’esecutore del maggiordomo.
135
•
public interface WindowAgInterface extends Remote: questa classe serve al CO per
poter pubblicare verso l’agenzia il metodo appena descritto che può essere chiamato
in modo remoto.
Al momento dell’istanza di WindowAg ho deciso di porre:
•
checkTime = 5000 (5 secondi);
•
agentName = “WindowAg”;
•
agentUrl = “10.0.0.1” (indirizzo IP di classe A sul quale è indirizzata l’intera
AGENZIA AMBIENTALE);
•
agentPort= “4160” (numero di porta aperta su JINI per comunicare con l’AGENZIA
AMBIENTALE).
5.2.5 Agente GoalGenerator
Riporto di seguito i moduli di cui è composto il GoalGenerator e per ogni modulo tratterò
solo i metodi significativi per il funzionamento logico dell’agente, tralasciando alcuni
dettagli implementativi. Per le interazioni tra i moduli dell’agente e tra l’agente e l’esterno si
faccia riferimento alla Fig. 5.10.
•
public class GoalGeneratorUserInterface extends AgUserInterface: questa classe
rappresenta l’interfaccia utente dell’agente e implementa i seguenti metodi:
o public void startUserInterface(): si occupa di rendere visibile l’interfaccia grafica.
o public void stopUserInterface(): si occupa di rendere non più visibile l’interfaccia
grafica.
•
public
class
GoalGenerator
extends
Cooperative
implements
GoalGeneratorInterface: questa classe rappresenta il modulo device controller,
estende la classe Cooperative (CO) e implementa GoalGeneratorInterface (che
rappresenta il device controller interface) per l’interfaccia remota (o laterale)
specifica dell’agente. La classe implementa i seguenti metodi.
o public HPresenceDetector(String agentName, String agentUrl, int agentPort,
long checkTime, HPresenceDetectorUserInterface agUI, OpController bc) throws
RemoteException: è il costruttore del device controller; agentName, agentUrl,
136
agentPort, checkTime e agUI sono tutti parametri che servono per poter chiamare
il costruttore della super classe (Cooperative); bc rappresenta il riferimento al
modulo OpController (in grado di dialogare con il dispositivo IOC306).
GoalGenerator
Uomo (utente)
Interfaccia utente
maggiordomo
Goal generati:
turnOffLight
turnOnLight
ESOn
Esecutore del
maggiordomo
Device controller interface
turnLightOff
turnLightOn
userInterfaceClosed
eSavingOn
Device controller
setOnOff
OpController
Dispositivo: IOC306
Ambiente
Figura 5.10 Descrizione schematica delle attività interne ed esterne di GoalGenerator
o public boolean checkOp(): Non è specializzato (dunque ritorna sempre true) in
quanto l’OP del GoalGenerator non è costituito solo dal dispositivo fisico
(IOC306), sul quale notifica se l’EnergySaving è acceso o spento, ma anche da
altri servizi implementati direttamente in JAVA (senza l’ausilio di altri moduli
esterni) in questa classe (GoalGenerator). Quindi, finché l’agente è in esecuzione,
137
disporrà almeno di tutti i servizi operativi che non fanno riferimento ad altri
moduli esterni al device controller per funzionare.
o public void turnLightOff(): Genera il goal turnOffLight e lo manda al
maggiordomo.
o public void turnLightOn(): Genera il goal turnOnLight e lo manda al
maggiordomo.
o public void turnOnESaving(): Genera il goal ESOn e lo manda al maggiordomo.
o public void userInterfaceClosed(): questo metodo è chiamato dall’interfaccia
utente nel caso l’interfaccia grafica venga chiusa espressamente dall’utente
(esprimendo quindi la volontà di terminare l’agente). Tale metodo, se chiamato,
sconnette l’agente dall’agenzia e termina tutti i processi in esecuzione.
o public String eSavingOn() throws RemoteException: restituisce yes se l’utente,
dopo aver espresso la volontà di accendere il sistema di EnergySaving non ha
ancora chiesto di spegnerlo. Altrimenti, se l’utente o non ha attivato EnergySaving
o ha richiesto di spegnerlo, restituisce no.
o public interface GoalGeneratorInterface extends Remote: questa classe serve al
CO per poter pubblicare verso l’agenzia il metodo appena descritto che può essere
chiamato in modo remoto.
Al momento dell’istanza del GoalGenerator ho deciso di porre:
•
checkTime = 30000 (30 secondi); ho messo un tempo lungo perché per il
GoalGenerator non ho previsto alcuna reattività. GoalGenerator l’ho solo
predisposto per renderlo eventualmente reattivo;
•
agentName = “GoalGenerator”;
•
agentUrl = “10.0.0.1” (indirizzo IP di classe A sul quale è indirizzata l’intera
AGENZIA AMBIENTALE);
•
agentPort= “4160” (numero di porta aperta su JINI per comunicare con l’AGENZIA
AMBIENTALE).
138
5.2.6 Agente Heating
L’agente Heating non verrà dettagliato come gli altri e si rimanda a [3] per una trattazione
più precisa. Di seguito riporto solo i servizi remoti che tale agente è in grado di mettere a
disposizione dell’AGENZIA AMBIENTALE.
•
public void heatingOff() throws RemoteException: spegne il riscaldamento.
•
public void heatingOn() throws RemoteException: accende il riscaldamento.
• public String heatingUState() throws RemoteException: restituisce on se nell’ultima
interazione con l’interfaccia utente locale l’uomo aveva acceso il riscaldamento;
restituisce off se invece l’utente aveva spento il riscaldamento.
5.3 Espansioni e goal realizzati
Ho realizzato delle espansioni per risolvere alcuni goal iniziali, utilizzando l’interfaccia
grafica del maggiordomo, per poter modellizzare delle esigenze d’alto livello da risolvere
(goal iniziali) e la conoscenza (espansioni) necessaria per poter portare i goal iniziali in una
forma risolvibile dagli agenti domotici. Il maggiordomo, grazie alle espansioni create, è in
grado, tramite processi inferenziali e una pianificazione, di passare da un goal iniziale (che
rappresenta un’esigenza) al problema risolto (piano esecutivo), rappresentato da una
sequenza di azioni che saranno eseguite da uno o più agenti.
I goal (e le espansioni) realizzati sono solo a scopo dimostrativo e sono serviti per validare,
in fase sperimentale, alcune peculiarità dell’AGENZIA AMBIENTALE come la pianificazione
dinamica dipendente dalle risorse realmente disponibili.
I goal iniziali creati sono:
•
ESOn, rappresenta l’esigenza di voler risparmiare energia nell’ambiente, questa
esigenza è quella che l’utente esprime chiedendo l’accensione dell’EnergySaving
come detto nella Sezione 5.1;
•
turnOffLight, rappresenta l’esigenza di voler spegnere la luce;
•
turnOnLight; rappresenta l’esigenza di voler accendere la luce.
5.3.1 Espansioni per ESOn
Per soddisfare l’esigenza rappresentata da ESOn ho fornito tre diverse decomposizioni
possibili (tre diverse espansioni intermedie) che potranno essere usate dal pianificatore per
139
trovare un piano d’azione realmente eseguibile. Nel caso il pianificatore riesca a trovare più
di un piano eseguibile sceglierà quello giudicato migliore secondo i criteri esposti nella
Sezione 3.1.7 o con maggiore dettaglio in [78]. Per tutte le espansioni create ho fornito i
medesimi valori per i parametri di performance, costo e probabilità di successo. Vedremo
nelle valutazioni sperimentali quale è l’effetto prodotto da questa scelta.
EsOn, considerato dal maggiordomo come goal iniziale, è stato espanso (con un’espansione
intermedia) nei seguenti goal (vedi Fig. 5.11).
HeatingES
Iterazione
until
ESOn
ESavingOn
GoalGenerator
Iterazione
until
LightES
Figura 5.11 Espansione per il goal ESOn
•
HeatingES: rappresenta l’esigenza di risparmiare energia utilizzando in modo
adeguato il riscaldamento in relazione all’apertura o chiusura della finestra.
•
ESavingOn: è un goal direttamente espandibile con un’espansione finale. Il
GoalGenerator è in fatti in grado di risolvere questo goal. ESavingOn è risolvibile
con una chiamata al metodo eSavingOn() del GoalGenerator.
140
•
LightES: rappresenta l’esigenza di risparmiare energia utilizzando in modo adeguato
la luce in relazione alla rilevazione di presenza.
Per la realizzazione dell’espansione intermedia di Fig. 5.11 sono stati utilizzati modificatori
(dei goal) di iterazione. Per il significato e la logica di funzionamento dei modificatori dei
goal si faccia riferimento alla Sezione 3.1.7 e alla Fig. 3.7.
•
Modificatore iterazione ESavingOn – HeatingES: l’esecutore del maggiordomo
continua a eseguire l’eventuale piano risolutivo per HeatingES e per ESavingOn
finché l’esecuzione del piano risolutivo di ESavingOn non fornirà come valore no.
•
Modificatore iterazione ESavingOn – LightES: l’esecutore del maggiordomo continua
a eseguire l’eventuale piano risolutivo per LightES e per ESavingOn finché
l’esecuzione del piano risolutivo di ESavingOn non fornirà come valore no.
ESavingOn
ESOn
Iterazione
until
LightES
GoalGenerator
Figura 5.12 Espansione per il goal ESOn
Come detto per ESOn ho fornito anche altre due espansioni possibili rappresentate in Fig.
5.12 e in Fig. 5.13. L’espansione rappresentata in Fig. 5.12 si occupa di gestire in modo
adeguato solo la luce in relazione alla rilevazione di presenza nell’ambiente per soddisfare
ESOn (risparmio energetico).
141
L’espansione rappresentata in Fig. 5.13 si occupa di gestire in modo adeguato solo il
riscaldamento in relazione all’apertura o chiusura della finestra per soddisfare ESOn.
HeatingES
ESOn
Iterazione
until
ESavingOn
GoalGenerator
Figura 5.13 Espansione per il goal ESOn
5.3.1.1 Espansioni per HeatingES
HeatingES è espanso nei seguenti goal tutti risolvibili con un’espansione finale (vedi Fig.
5.14).
•
IsWindowOpen: risolvibile da WindowAg tramite il metodo isWindowOpen.
•
HeatingOff: risolvibile da Heating tramite il metodo heatingOff.
•
HeatingOn: risolvibile da Heating tramite il metodo heatingOn.
•
HeatingUState: risolvibile da Heating tramite il metodo heatingUState.
Per la realizzazione dell’espansione di Fig. 5.14 sono stati utilizzati modificatori (dei goal)
di selezione.
•
Modificatore selezione IsWindowOpen – HeatingOff: se il valore fornito
dall’esecuzione del piano risolutivo di IsWindowOpen è yes allora l’esecutore del
maggiordomo esegue il piano risolutivo di HeatingOff .
142
•
Modificatore selezione IsWindowOpen – HeatingUState: se il valore fornito
dall’esecuzione del piano risolutivo di IsWindowOpen è no allora l’esecutore del
maggiordomo esegue il piano risolutivo di HeatingUState.
•
Modificatore selezione HeatingUState – HeatingOn: se il valore fornito
dall’esecuzione del piano risolutivo di HeatingUState è on allora l’esecutore del
maggiordomo esegue il piano risolutivo di HeatingOn.
IsWindowOpen
WindowAg
selezione
HeatingOff
Heating
HeatingES
selezione
HeatingUState
Heating
selezione
HeatingOn
Heating
Figura 5.14 Espansione per il goal HeatingES
5.3.1.2 Espansioni per LightES
LightES è espanso nei seguenti goal tutti risolvibili con un’espansione finale (vedi Fig.
5.15).
•
IsHPresence: risolvibile da HPresenceDetector tramite il metodo ishPresence.
•
LightOff: risolvibile da LightAg tramite il metodo lightOffRem.
143
•
LightOn: risolvibile da LightAg tramite il metodo lightOnRem.
•
LightUState: risolvibile da LightAg tramite il metodo lightUState.
HPresence
Detector
IsHPresence
selezione
LightAg
LightOff
LightES
selezione
LightAg
LightUState
selezione
LightOn
LightAg
Figura 5.15 Espansione per il goal LightES
Per la realizzazione dell’espansione di Fig. 5.15 sono stati utilizzati modificatori (dei goal)
di selezione.
•
Modificatore selezione IsHPresence – LightOff: se il valore fornito dall’esecuzione
del piano risolutivo di IsHPresence è yes allora esegue il piano risolutivo di LightOff.
•
Modificatore
selezione
IsHPresence
–
LightUState:
se
il
valore
fornito
dall’esecuzione del piano risolutivo di IsHPresence è no allora esegue il piano
risolutivo di LightUState.
144
•
Modificatore selezione LightUState – LightOn: se il valore fornito dall’esecuzione del
piano risolutivo di LightUState è on allora esegue il piano risolutivo di LightOn.
Con l’espansioni descritte nelle sezioni 5.3.1.1 e 5.3.1.2 e l’espansione iniziale descritta
nella Sezione 5.3.1, il maggiordomo potrà essere in grado di costruire un piano che termini
con tutte espansioni finali (eseguibili dall’esecutore) se le condizioni in fase di pianificazione
glielo consentiranno.
5.3.2 Espansioni per turnOnLight e turnOffLight
Le esigenze rappresentate dai due goal iniziali turnOnLight e turnOffLight hanno una
decomposizione composta da un solo goal (decomposizione banale). Ho realizzato dei goal
iniziali con una decomposizione banale per poter valutare sperimentalmente la differenza dei
tempi di risposta nel soddisfare un’esigenza coinvolgendo o no il maggiordomo.
turnOnLight
lightOn
turnOffLight
lightOff
LightAg
LightAg
Figura 5.16 Espansioni per i goal turnOnLight e turnOffLight
Grazie alle espansioni di Fig. 5.16 l’utente dell’applicazione domotica può richiedere di
accendere (o spegnere) la luce sia al GoalGenerator che al LightAg. Nel primo caso il
GoalGenerator raccoglie l’esigenza e la trasmette al maggiordomo generando il goal
turnOnLight (o turnOffLight); il maggiordomo (tramite il pianificatore), se LightAg è
145
connesso all’agenzia, riuscirà a realizzare un piano eseguibile che verrà eseguito
dall’esecutore. Questo ultimo, per eseguire il piano, si occuperà di chiamare il metodo
lightOnRem (lightOffRem ) di LightAg che accenderà (o spegnerà) la luce (vedi Fig. 5.17).
GoalGenerator
LightAg
Device controller interface
turnOffLight
turnOnLight
Maggiordomo
Device controller interface
lightOnRem
lightOnRem
turnOnLight
turnOffLight
Pianificatore
Dispositivo IOC306
Esecutore
Figura 5.17 Due modi possibili per accendere la luce
Nel caso in cui l’utente dell’applicazione domotica chieda direttamente a LightAg di
accendere (o spegnere) la luce, utilizzando l’interfaccia utente di LightAg, il maggiordomo
non verrebbe coinvolto e LightAg si occuperebbe direttamente di accendere (o spegnere) la
luce utilizzando il metodo turnOnLight (o turnOffLight), vedi Fig. 5.17.
146
5.4 Prove sperimentali e valutazioni
In questa sezione verranno descritte tutte le prove sperimentali effettuate e le valutazioni
tratte.
Nella Sezione 5.4.1 descriverò le prove fatte per verificare il corretto funzionamento degli
agenti implementati per la realizzazione dell’’applicazione domotica.
Nella Sezione 5.4.2 descriverò le prove realizzate per validare alcune caratteristiche
dell’AGENZIA AMBIENTALE. In particolare vedremo come è stata verificata la capacità
dell’AGENZIA AMBIENTALE di pianificare delle soluzioni per soddisfare esigenze d’alto
livello d’astrazione, in modo dinamico e dipendente dalle reali condizioni operative.
Le prove sperimentali eseguite per testare la rete domotica in assenza dell’AGENZIA
AMBIENTALE (stand alone) non verranno riportate ma le si potranno trovare nel progetto di
tesi [79].
Nella Sezione 5.4.3 verrà fornita una valutazione complessiva sul comportamento
dell’applicazione domotica nel suo complesso.
Nella Sezione 5.4.4 verranno fatte delle valutazioni qualitative e quantitative su alcuni
tempi di risposta dell’applicazione domotica.
5.4.1 Operatività e reattività degli agenti
Verranno fornite delle valutazioni sull’operatività e reattività di ogni singolo agente. Si
rimanda invece alla Sezione 5.4.3 per la valutazione della cooperazione tra gli agenti e quindi
anche per la valutazione dei servizi remoti messi a disposizione.
C’è da evidenziare che tutti i moduli degli agenti implementati in JAVA, durante la fase di
test, erano in esecuzione contemporaneamente sullo stesso PC (2,6 GHz, 512 MB RAM)
5.4.1.1 LightAg
In fase sperimentale è stato possibile sia accendere che spegnere un punto luce utilizzando
l’interfaccia grafica del LightAg. L’interfaccia grafica inoltre ha mostrato correttamente
l’accensione (e spegnimento) effettivo della lampadina.
Dal momento della pressione del bottone preposto all’accensione o spegnimento della luce,
all’avvenuta accensione della lampadina è passato circa ½ secondo. Dall’accensione della
lampadina fino al riscontro sull’interfaccia grafica di LightAg è trascorso circa ½ secondo.
147
Accendendo e spegnendo il punto luce, utilizzando un interruttore sulla rete LON, è stata
riscontrata l’esatta reazione dell’interfaccia grafica al cambiamento dello stato del punto luce.
Il tempo di reazione rilevato è stato di circa ½ secondo.
Chiudendo esplicitamente l’interfaccia utente di LightAg l’agente si disconnetteva
dall’agenzia e terminava tutti i processi ad esso legati in modo corretto come previsto.
Sganciando il dispositivo IOC306 finché LightAg era in esecuzione è stata riscontrata una
corretta reazione: LightAg si è disconnesso dall’agenzia e ha terminato la propria interfaccia
utente. La reazione è da considerarsi corretta: infatti tutti i servizi operativi che LightAg è in
grado di mettere a disposizione dipendono strettamente dal buon funzionamento del
dispositivo IOC306.
Agganciando il dispositivo IOC306 finché LightAg era in esecuzione è stata riscontrata una
corretta reazione: LightAg attiva l’interfaccia utente e si connette all’agenzia. C’è da
evidenziare però che la reazione riscontrata è stata più veloce di quella prevista, infatti
LightAg riesce a rendersi conto che è in grado di essere di nuovo operativo in circa ½
secondo, senza aspettare i 2,5 secondi di media previsti (checkTime = 5000 millisecondi).
Tale comportamento credo sia dovuto al fatto che checkOp non venga chiamato dal processo
OperativeAgState ma dal listener associato a DvState. Ipotizzo dunque che la tecnologia
LON, ogni volta che un dispositivo viene collegato alla rete a caldo, sollevi un evento di
update per tutte le variabili pubblicate dal dispositivo agganciato.
5.4.1.2 WindowAg
Come detto, WindowAg non agisce realmente su un motore di azionamento di una finestra
ma solo su un controllore. Tale controllore, implementato sul dispositivo TAST, quando
riceve il comando di apertura (o chiusura) della finestra accende (o spegne) un led su TAST.
In fase sperimentale è stato possibile simulare sia l’apertura che la chiusura della finestra
(accendendo il led su TAST) utilizzando l’interfaccia grafica di WindowAg. L’interfaccia
grafica inoltre ha mostrato correttamente l’avvenuta apertura (e chiusura) della finestra.
Dal momento della pressione del bottone preposto all’apertura della finestra, all’accensione
del led che simula l’apertura è passato circa ½ secondo. Dall’accensione del led fino al
riscontro sull’interfaccia grafica di WindowAg è trascorso circa ½ secondo.
Come detto, l’apertura e chiusura della finestra è stata simulata tenendo premuto (finestra
chiusa) e rilasciando (finestra aperta) un pulsante su TAST.
148
Tenendo premuto o rilasciando il bottone che simula l’apertura o chiusura di una finestra è
stato riscontrata l’esatta reazione dell’interfaccia grafica al cambiamento dello stato della
finestra. Il tempo di reazione rilevato è stato di circa ½ secondo.
Chiudendo esplicitamente l’interfaccia utente di WindowAg l’agente si disconnetteva
dall’agenzia e terminava tutti i processi ad esso legati in modo corretto come previsto.
Sganciando il dispositivo TAST finché WindowAg era in esecuzione è stata riscontrata una
corretta reazione: WindowAg si è disconnesso dall’agenzia e ha terminato la propria
interfaccia utente. La reazione è da considerarsi corretta poiché tutti i servizi operativi che
WindowAg è in grado di mettere a disposizione dipendono strettamente dal buon
funzionamento del dispositivo TAST.
Agganciando il dispositivo TAST finché WindowAg era in esecuzione è stata riscontrata una
corretta reazione: WindowAg attiva l’interfaccia utente e si connette all’agenzia. C’è da
evidenziare però che la reazione riscontrata è stata anche in questo caso, come per LightAg
più veloce di quella prevista ( circa ½ secondo). Credo che valgano le stesse considerazioni
esposte per LightAg.
5.4.1.3 HPresenceDetector
In fase sperimentale è stato riscontrato che l’interfaccia utente reagisce in modo corretto
alla rilevazione o non rilevazione di presenza che gli perviene dal dispositivo HPresenceOP.
Chiudendo esplicitamente l’interfaccia utente di HPresenceDetector l’agente si disconnette
dall’agenzia e termina tutti i processi ad esso legati in modo corretto come previsto.
Sganciando il dispositivo HPresenceOP finché HPresenceDetector era in esecuzione è
stata riscontrata una corretta reazione: HPresenceDetector si è disconnesso dall’agenzia e ha
terminato la propria interfaccia utente. La reazione è da considerarsi corretta poiché tutti i
servizi operativi che HPresenceDetector è in grado di mettere a disposizione dipendono
strettamente dal buon funzionamento del dispositivo HPresenceOP.
Agganciando il dispositivo HPresenceOP finché HPresenceDetector era in esecuzione è
stata riscontrata una corretta reazione: HPresenceDetector attiva l’interfaccia utente e si
connette all’agenzia. C’è da evidenziare però che la reazione riscontrata è stata anche in
questo caso, come per LightAg e WindowAg, più veloce di quella prevista (circa ½ secondo).
149
5.4.1.4 GoalGenerator
I goal che doveva poter generare il GoalGenerator erano: turnOffLight, turnOnLight e
ESOn.
Il GoalGenerator è risultato in grado di generare tutti i goal quando l’utente sollevava le
rispettive esigenze utilizzando gli appositi pulsanti dell’interfaccia grafica. Inoltre il
GoalGenerator al momento della generazione del goal ESOn accendeva, come previsto, un
led sul dispositivo IOC306.
Agganciando o sganciando il dispositivo IOC306 durante il funzionamento del
GoalGenerator non accadeva nulla sul GoalGenerator come previsto.
5.4.2 Pianificazione ed esecuzione
Per validare la capacità dell’AGENZIA AMBIENTALE di pianificare in relazione alle reali
condizioni operative è stato creato il goal ESOn ed è stato espanso nei tre modi descritti nella
Sezione 5.3.1.
Di seguito descriverò il comportamento, riscontrato in fase sperimentale, dei dispositivi,
degli agenti da me implementati e del maggiordomo.
Successivamente alla pressione del pulsante “Turn On Energy Saving” presente
sull’interfaccia grafica del GoalGenerator, il GoalGenerator ha generato il goal ESOn. Da
un’interfaccia di monitoraggio del maggiordomo si è visto che il goal generato è stato preso
in considerazione. Nel momento in cui il goal è arrivato al maggiordomo (quasi
contemporaneamente all’istante di generazione del goal) il maggiordomo ha iniziato a
pianificare una soluzione possibile per soddisfare l’esigenza rappresentata da ESOn.
Il pianificatore del maggiordomo, durante la pianificazione, ha comunicato con tutti gli
agenti disponibili nell’agenzia per costruire un piano eseguibile.
Questa prova è stata ripetuta più volte con condizioni operative differenti. A seconda delle
condizioni sono stati costruiti dal maggiordomo diversi piani esecutivi per la stessa esigenza.
Di seguito riporto tutti i casi sperimentati.
•
Agenti connessi all’agenzia: LightAg; WindowAg; HPresenceDetector; Heating;
GoalGenerator.
- Piano esecutivo trovato (piano 1): piano di Fig. 5.11 (più i piani correlati di Fig.
5.14 e Fig. 5.15).
150
•
Agenti
connessi
all’agenzia:
LightAg;
WindowAg;
HPresenceDetector;
GoalGenerator.
- Piano esecutivo trovato (piano 2): piano di Fig. 5.12 (più il piano correlato di Fig.
5.15).
•
Agenti connessi all’agenzia: LightAg; HPresenceDetector; Heating; GoalGenerator.
- Piano esecutivo trovato (piano 2): piano di Fig. 5.12 (più il piano correlato di Fig.
5.15).
•
Agenti connessi all’agenzia: LightAg; WindowAg; Heating; GoalGenerator.
- Piano esecutivo trovato (piano 3): piano di Fig. 5.13 (più il piano correlato di Fig.
5.14).
•
Agenti
connessi
all’agenzia:
HPresenceDetector;
WindowAg;
Heating;
GoalGenerator.
- Piano esecutivo trovato (piano 3): piano di Fig. 5.13 (più il piano correlato di Fig.
5.14).
•
Agenti connessi all’agenzia: HPresenceDetector; WindowAg; GoalGenerator.
- Piano esecutivo trovato: nessuno.
•
Agenti connessi all’agenzia: LightAg; Heating; GoalGenerator.
- Piano esecutivo trovato: nessuno.
Ho provato inoltre a generare i goal turnOffLight e turnOnLight. Quando LightAg era
connesso all’agenzia i piani esecutivi per i due goal venivano trovati ed eseguiti, se LightAg
non era invece connesso all’agenzia i piani esecutivi per soddisfare turnOffLight e
turnOnLight non venivano invece trovati.
I piani esecutivi trovati dal maggiordomo sono sempre risultati corretti e adeguati alle
condizioni operative dell’intera agenzia. I piani trovati inoltre sono risultati anche quelli più
efficaci in relazione alle condizioni operative. Infatti, nonostante per tutte le espansioni create
io abbia impostato i medesimi valori per i parametri di performance, costo e probabilità di
successo, dall’analisi dei risultati sperimentali si può evincere che il pianificatore, quando
può scegliere tra più piani qualitativamente uguali, sceglie euristicamente sempre quello che
coinvolge il numero più elevato di espansioni.
Ricordo che il pianificatore una volta che ha trovato un piano eseguibile lo passa
all’esecutore. Quest’ultimo, come detto, si occuperà di utilizzare i servizi utili per
151
l’esecuzione del piano messi a disposizione dagli agenti connessi. In fase di esecuzione del
piano 1 ho provato a sganciare il dispositivo IOC306, l’agente WindowAg di conseguenza si
è sconnesso dall’agenzia in fase di esecuzione. L’esecutore del piano ha iniziato a generare
eccezioni e il piano in esecuzione si è operativamente interrotto. L’esecutore però, non
avendo gestito opportunamente le eccezioni, non è stato in grado di notificare al
maggiordomo che il piano non era più in esecuzione. Difatti nell’interfaccia di monitoraggio
del maggiordomo risultava che il piano era ancora in esecuzione. Ho provato a quel punto a
rigenerare di nuovo il goal ESOn (tramite il GoalGenerator) ma il maggiordomo sospendeva
la pianificazione di tale goal attendendo la terminazione del piano realizzato
precedentemente per il medesimo goal (ESOn). Generando invece un altro goal, ad esempio
turnOffLight, il maggiordomo si comportava invece correttamente pianificando ed eseguendo
il piano trovato.
Ho provato più volte a generare tre o quattro goal a distanza di circa ½ secondo l’uno
dall’altro, nella maggior parte delle volte il maggiordomo andava in errore, generando
eccezioni non gestite e compromettendo il funzionamento dell’intera AGENZIA AMBIENTALE.
Concludendo, l’AGENZIA AMBIENTALE ha dimostrato di essere perfettamente adattabile alle
condizioni operative in modo dinamico ma ha dimostrato una forte instabilità.
5.4.3 Valutazione funzionale dell’applicazione domotica
In questa sezione darò una valutazione funzionale dell’applicazione domotica dal punto di
vista dell’utilizzatore.
L’applicazione domotica da me realizzata è stata in grado di sfruttare tutte le funzioni
esposte nella Sezione 5.1.1 messe a disposizione da ogni singolo agente (compreso il
GoalGenerator) pur dimostrando in molti casi un’instabilità complessiva (dovuta
all’instabilità dell’AGENZIA AMBIENTALE).
E’ stato riscontrato che finché il piano 1 era in esecuzione, osservando le azioni, le reazioni
e le interazioni fisiche tra l’uomo, l’ambiente e i dispositivi, accadeva che:
1)
- Se non vi era più presenza rilevata nell’ambiente
allora:
- veniva segnalato lo stato di non rilevazione di presenza tramite l’interfaccia
utente del HPresenceDetector;
152
- si spegneva la luce e veniva segnalata sull’interfaccia utente di LightAg che la
luce era spenta.
- Se veniva nuovamente rilevata presenza nell’ambiente
allora:
- veniva segnalata la rilevazione di presenza tramite l’interfaccia utente del
HPresenceDetector;
- veniva rimessa la luce nello stesso stato in cui era prima che il sistema
intervenisse per spegnerla;
- l’interfaccia utente di LightAg reagiva all’eventuale nuovo stato della luce.
2)
- Se veniva aperta la finestra
allora:
- veniva segnalata l’apertura della finestra tramite l’interfaccia utente di
WindowAg;
- si spegneva il riscaldamento.
- Se la finestra veniva richiusa il riscaldamento veniva riportato nello stesso stato in cui era
prima dell’apertura della finestra.
Finché il piano 2 era in esecuzione veniva eseguito solo il comportamento descritto al
punto 1.
Finché il piano 3 era in esecuzione veniva eseguito solo il comportamento descritto al
punto 2.
Dalla valutazione funzionale dell’applicazione domotica che ho realizzato posso
concludere che tutti i servizi remoti messi a disposizione per l’agenzia dagli agenti sono stati
implementati correttamente. Inoltre si può concludere che la cooperazione tra gli agenti e il
maggiordomo dell’AGENZIA AMBIENTALE funziona correttamente e grazie a questa
cooperazione l’utente dell’applicazione domotica può beneficiare della funzionalità di
EnergySaving. L’utente è in grado di sfruttare l’EnergySaving anche se alcuni dispositivi
presenti sulla rete domotica non funzionano o non sono presenti grazie all’adattabilità alle
condizioni operative messe a disposizione dall’AGENZIA AMBIENTALE. Sganciando alcuni
dispositivi finché l’EnergySaving era attivo, l’applicazione domotica risultava non essere più
in grado di funzionare correttamente e necessitava di essere riavviata (per i motivi descritti
153
nella Sezione 5.4.2). Nello stato dell’arte relativo alla domotica (Sezione 2.2.3) tra i requisiti
espressi per l’UC e auspicabili anche per un sistema domotico vi era l’eternità; l’applicazione
domotica realizzata non rispetta tale requisito.
Osservando l’interfaccia grafica messa a disposizione dall’applicazione domotica posso
dire che, grazie alla reattività dei singoli agenti, l’utente si trova di fronte ad un’interfaccia
dinamica, reattiva e in grado di mettere a disposizione solo i servizi realmente operativi,
come auspicato nella Sezione 3.2. Fatta eccezione per i servizi messi a disposizione dal
GoalGenerator che saranno invece strettamente legati alla buona riuscita della pianificazione
e per tale motivo non prevedibili a priori.
5.4.4 Valutazione di alcuni tempi di risposta
In questa sezione descriverò le valutazioni relative al confronto tra il tempo impiegato,
agendo direttamente sull’interfaccia utente di LightAg oppure agendo sull’interfaccia del
GoalGenerator, per accendere (o spegnere) una luce (vedi Fig. 5.17). E’ stato riscontrato che
premendo il pulsante “Turn On Light” sull’interfaccia di LightAg ci vuole circa ½ secondo
prima che la lampadina si accenda. Premendo invece il pulsante “Turn On Light”
sull’interfaccia del GoalGenerator ci vogliono circa 2 secondi prima che la lampadina si
accenda. Quest’ultima è una valutazione media su circa dieci prove ripetute. E’ stato
riscontrato che a seconda del numero degli agenti connessi all’agenzia i tempi di risposta per
accendere la lampadina utilizzando il GoalGenerator aumentavano sensibilmente (fino a 4
secondi). Utilizzando il GoalGenerator, come detto, si chiama in causa il maggiordomo che
costruisce un piano esecutivo. Per costruire un piano il maggiordomo si occupa di dialogare
con tutti gli agenti presenti nell’agenzia al fine di recuperare conoscenza utile alla
pianificazione. A causa di questo meccanismo di pianificazione il tempo di risposta del
sistema per accendere la lampadina, utilizzando il GoalGenerator, è fortemente dipendente
dal numero di agenti connessi all’agenzia durante la costruzione del piano.
154
6
CONCLUSIONI E
SVILUPPI FUTURI
Le conclusioni possono essere divise nelle seguenti parti.
•
Valutazione delle modifiche apportate alla struttura di un agente per aumentarne la
reattività ai mutamenti contestuali.
•
Valutazione dell’interfaccia di comunicazione per l’interoperabilità tra il device
controller e i dispositivi realizzati con altre tecnologie.
•
Valutazione dell’AGENZIA AMBIENTALE come architettura per la realizzazione di
applicazioni domotiche.
•
Valutazione complessiva dell’applicazione domotica realizzata.
Valutazione delle modifiche apportate alla struttura di un agente
Le modifiche alla struttura logica dell’agente mi hanno permesso di realizzare degli agenti
indipendenti, in grado di sviluppare una reattività efficace sia verso l’agenzia che verso
l’utente. Infatti, tutte le prove realizzate hanno confermato la capacità degli agenti di reagire
in modo adeguato sia ai cambiamenti di stato che a eventuali malfunzionamenti o disservizi
dei dispositivi che compongono il semiagente operativo.
Valutazione dell’interfaccia di comunicazione per l’interoperabilità tra il device
controller e i dispositivi
I servizi messi a disposizione dall’interfaccia di comunicazione tra il device controller e i
dispositivi hanno consentito una comunicazione efficace con tutti i dispositivi utilizzati per la
realizzazione dell’applicazione domotica. E’ stato possibile gestire sia una comunicazione
dal device controller verso i dispositivi, che una comunicazione dai dispositivi verso il device
controller di tipo publish-subscribe tramite la gestione degli eventi.
Per connettere dei dispositivi reali con il device controller è stata scelta la tecnologia
LONTALK. L’implementazione realizzata dell’interfaccia di comunicazione tra il device
controller e i dispositivi interconnessi con la tecnologia LONTALK si è dimostrata in grado di
rendere operativi tutti i servizi necessari alla comunicazione. Dalla valutazione dei tempi di
risposta del sistema c’è da evidenziare che l’implementazione non si è dimostrata però molto
efficiente. In tal senso, una direzione futura di sviluppo sta proprio nell’ottimizzazione di tale
implementazione al fine di diminuire i tempi di risposta dell’intera applicazione domotica.
Valutazione dell’AGENZIA AMBIENTALE
I meccanismi per la pianificazione ed esecuzione dei piani d’azione messi a disposizione
dall’agente maggiordomo (parte dell’AGENZIA AMBIENTALE) si sono dimostrati dinamici ed
adeguati per la soddisfazione di esigenze d’alto livello in relazione agli agenti e ai servizi
realmente operativi in un dato momento. Per validare tale caratteristica sono state fornite al
maggiordomo tre diverse soluzioni per far fronte all’esigenza di risparmiare energia. Ognuna
delle soluzioni presupponeva l’esistenza, nell’agenzia, di differenti agenti e servizi. La
sperimentazione effettuata ha dimostrato che il maggiordomo è in grado di costruire ed
eseguire il piano di risparmio energetico (e quindi di soddisfare un’esigenza) effettivamente
realizzabile in relazione alle risorse disponibili. In presenza di più di un piano d’azione
realizzabile, il maggiordomo si è dimostrato in grado di scegliere euristicamente il piano più
efficace. In fase di sperimentazione è stato però riscontrato che, se vengono a mancare degli
agenti utili ad un piano durante l’esecuzione dello stesso, l’intera AGENZIA AMBIENTALE non
funziona più correttamente. Questo è dovuto al fatto che l’esecutore dei piani, presente nel
maggiordomo, non è in grado di gestire i cambiamenti delle condizioni operative in fase di
esecuzione di un piano. Una possibile direzione futura di sviluppo è quindi quella di
modificare il maggiordomo in modo tale che, anche in fase di esecuzione di un piano, sia in
grado di intervenire nel caso di cambiamento delle condizioni operative.
Nella realizzazione dell’applicazione domotica, non è stato possibile fornire all’utente la
possibilità di sapere se la richiesta di risparmiare energia fosse stata presa in considerazione e
risolta positivamente dal sistema. Questo perché, nell’AGENZIA AMBIENTALE, non è previsto
che a un agente venga notificato se l’eventuale esigenza che ha sollevato sia stata soddisfatta
positivamente o meno. Un altro degli sviluppi futuri che propongo, è quindi quello di
modificare i meccanismi di comunicazione tra il maggiordomo e gli altri agenti al fine di
poter notificare quando l’esecuzione di un piano per la soddisfazione di un’esigenza è andata
156
a buon fine. E’ stato riscontrato inoltre che il maggiordomo a volte non è stato in grado di
gestire più di quattro o cinque esigenze consecutive a distanza di pochi decimi di secondo
l’una dall’altra. Concludo quindi dicendo che, secondo me, le potenzialità dell’AGENZIA
AMBIENTALE, così come era stata pensata e con le modifiche da me apportate, sono notevoli
ma, in futuro, si dovrà lavorare molto sulla sua stabilità.
Valutazione complessiva dell’applicazione domotica realizzata
L’applicazione domotica realizzata, utilizzando l’AGENZIA AMBIENTALE e le modifiche da
me apportate, è stata in grado di fornire tutte le funzioni per la quale era stata progettata. Un
utente, utilizzando l’interfaccia grafica messa a disposizione dall’applicazione è in grado di:
monitorare e controllare un punto luce; monitorare e controllare una finestra; monitorare e
controllare il riscaldamento simulato; rendersi conto che il sistema ha rilevato presenza
umana. Inoltre, fornendo la conoscenza necessaria e sfruttando la capacità di pianificare in
modo dinamico dell’AGENZIA AMBIENTALE, l’applicazione è in grado di realizzare un piano
di cooperazione, tra tutti gli agenti e i servizi realmente disponibili, al fine di poter
risparmiare energia. C’è da evidenziare che se viene sganciato un dispositivo, finché è attivo
il piano di risparmio energetico messo a punto dal sistema, l’applicazione non è più in grado
di funzionare correttamente ed è necessario riavviarla per renderla nuovamente operativa.
Questo problema è dovuto all’instabilità, in fase di esecuzione di un piano, dell’architettura
(fornita dall’AGENZIA AMBIENTALE) sulla quale è costruita l’applicazione domotica. Una
possibile direzione di sviluppo futuro è quella di rendere l’applicazione più tollerante ai
guasti e ai cambiamenti contestuali intervenendo sull’implementazione dell’applicazione
domotica per aggirare i problemi dell’ AGENZIA AMBIENTALE o intervenendo, come detto in
precedenza, direttamente sull’AGENZIA AMBIENTALE stessa.
157
APPENDICE A
STANDARD E TECNOLOGIE
PER LA DOMOTICA
In questa appendice fornirò ulteriori dettagli relativi alle tecnologie e agli standard (presenti
sul mercato della domotica) presentati nello stato dell’arte (nella Sezione 2.3.1 e nella
Sezione 2.3.2).
A.1 Mercato europeo
Il mercato europeo è caratterizzato dalla presenza di diversi standard proprietari e non che,
per molteplici motivi non sono riusciti ad imporsi nel mercato dell’automazione domestica
singolarmente.
In Europa si sta imponendo un unico protocollo, chiamato KONNEX (o KNX) [50], nato dalla
fusione dei tre standard nati separatamente e inizialmente in concorrenza fra loro (EHS,
BATIBUS, EIB). Nonostante sembra che si stia arrivando ad un unico standard, di seguito
proporrò una trattazione separata dei tre standard; infatti KNX fissa per lo più regole
d’interoperabilità diventando più che uno standard unico un contenitore di standard
differenti.
EHS [51]
EHS (European Home System), e stato sviluppato a partire dal 1987 nell’ambito dei
programmi europei Eureka ed Esprit, con i finanziamenti della Commissione Europea, nel
tentativo comune di interconnettere diversi dispositivi elettrici ed elettronici per l’uso in
ambito domestico. Il progetto è stato nominato EHS nel 1995 quando le compagnie che hanno
portato avanti lo sviluppo hanno dato vita al EHSA (European Home System Association).
Fanno parte di questa associazione circa trentasei compagnie tra le quali PHILIPS
ELECTRONICS, BT e THORN EMI. Nell’ottobre 1995, il CEBUS INDUSTRY COUNCIL (CIC) ha
annunciato un’alleanza con EHS promosso dal EHSA come la tecnologia di rete del futuro
nell’ambito dell’automazione domestica. Essendo una tecnologia aperta che supporta diversi
mezzi trasmessivi, EHS ricerca l’interoperabilità tramite: l’utilizzo di un linguaggio di
comandi orientato agli oggetti e una classificazione dei dispositivi che permette a dispositivi
appartenenti alla stessa classe di poter essere intercambiabili.
EHS supporta plug & play (l’aggancio e sgancio dei dispositivi non necessita di
riconfigurazione del sistema e della rete), generalmente un apparecchio EHS comprende un
micro-controllore e un modem integrato.
Le specifiche EHS sono state rilasciate verso la fine del 1991, e modificate nel corso degli
anni e le ultime sono del 2000 .
E’ uno standard aperto per il quale è prevista una certificazione dei prodotti.
EHS implementa i livelli 1,2,3 e 7 del modello OSI (Open System Interconnection). I mezzi di
trasmissione previsti sono: il doppino telefonico, le onde convogliate, il cavo coassiale, la
radiofrequenza, i raggi infrarossi e la radio frequenza. La topologia è a stella o bus per il cavo
coassiale, solo a bus per il doppino telefonico.
La rete effettua una trasmissione credibile e sicura di informazioni tra i terminali del sistema,
coinvolgendo i più bassi strati del modello di riferimento OSI effettuando il recupero
automatico delle informazioni perse (recovery).
La rete è in grado di autoconfigurarsi e implementa possibilità diagnostiche.
I livelli di destinazione dei segnali di comando sono rappresentati da indirizzi che
collegano gli attuatori con le applicazioni (attuatori e applicazioni possono anche coesistere
sullo stesso dispositivo). La gestione della rete usa un unico codice di destinazione. Ogni
sezione della rete permette di indirizzare fino a 256 terminali. Un sistema implementato con
lo standard EHS può gestire milioni di indirizzi (oltre 1012).
EHS è dotato di un servizio sviluppato per fornire robustezza al sistema contro gli errori di
comunicazione, apparecchi malfunzionanti o rilocazioni casuali. Questo servizio amministra
l’inizializzazione del sistema e la riconfigurazione dopo la perdita di energia o il
riposizionamento delle unità ed è inoltre sfruttato per poter portare a termine la funzione di
plug & play.
159
BATIBUS [52]
E’ uno standard europeo comprendente oltre cento aziende tra cui MERLINGERIN, AIRLEC,
EDF, LANDIS&GIR. L’associazione BATIBUS CLUB INTERNATIONAL nasce a Parigi nel 1989
ed è l’associazione alla quale si deve il merito di aver introdotto sul mercato il primo vero
sistema a bus. L’obbiettivo iniziale di questa associazione è la realizzazione di prodotti basati
sulla rete di comunicazione BATIBUS e di estenderne l’uso nei vari settori del mercato
residenziale e terziario.
I mezzi di trasmissione previsti sono: il doppino, la radiofrequenza e i raggi infrarossi. La
velocità di trasmissione è limitata a 4800baud su qualsiasi tipo di topologia di rete (bus,
stella, albero, loop o combinazioni di questi) distribuiti su di una distanza non superiore ai
2,5 Km.
Prevede l'identificazione di ogni dispositivo (detto punto) con tre codici definiti indirizzo,
tipo ed estensione. Sono disponibili 240 indirizzi per ogni tipo di punto terminale e sono
realizzabili 32 tipi di punto: centrale (00), ingresso binario (05), uscita binaria (04), comando
manuale (0E), trasmettitore telefonico (01), ecc. Ogni punto può avere indirizzo senza
estensione (codice di estensione 00) oppure con estensione (codice di estensione 04) e in tale
caso dispone di altri byte per definire l'indirizzo.
I messaggi possono avere indirizzamenti di diverso tipo.
•
Diretto (punto a punto): da un punto a un altro punto avente indirizzo, tipo ed
estensione specificati nel pacchetto inviato.
•
Di gruppo (multicast): da un punto a più punti, definiti gruppo, aventi la prima cifra
di indirizzo, tipo ed estensione specificati nel messaggio in linea. Ogni gruppo è
costituito da 16 punti e in totale i gruppi sono 15.
•
Generale (broadcast): da un punto a tutti i punti della rete.
•
Esteso (extended): da un punto con codice estensione 04 ad un altro punto con
estensione 04. Le informazioni riguardanti l'indirizzo sono contenute nei byte
denominati TAE (Tipo di indirizzo esteso), Eadr (Estensione dell'indirizzo) e in altri
opzionali che definiscono il gruppo, la zona e lista indirizzi.
EIB [53]
E’ uno standard europeo di proprietà della EIBA (European Installation Bus Association)
cui sono associate o affiliate più di cento aziende europee. Il protocollo EIB è uno standard
disponibile per le aziende affiliate e i prodotti sviluppati sono certificati dagli appositi
160
laboratori.
Per garantire la compatibilità dei prodotti offerti dai numerosi costruttori, EIBA ha
provveduto a mettere a punto una serie di procedure unificate. Eiba si occupa di:
• stabilire le prescrizioni relative al prodotto, lo standard qualitativo e le procedure di
verifica;
• rilasciare le licenze del marchio;
• partecipare alla stesura delle normative nazionali e internazionali;
• contribuire ad emanare le disposizioni sulle certificazioni e sui centri di formazione.
Il risultato di tutto questo è fornire una serie di prodotti che possono garantire,
indipendentemente dal costruttore, un elevato standard qualitativo e una totale compatibilità.
Vi sono circa cinquanta produttori tra cui i più significativi sono ABB, SIEMENS, VIMAR,
GEWISS, PHILIPS. In Italia si è formata l’associazione EIBA Italia, sulla spinta di quella
europea, importante riferimento per lo sviluppo della tecnologia bus negli impianti di
automazione per gli uffici. La commercializzazione, iniziata nei primi anni novanta,
comprende oltre quindicimila sistemi che in prevalenza sono stati installati nell’ambito della
building automation (automazione industriale) con la tendenza a diffondersi nell’home
automation; è uno standard in Francia e Germania oltre che uno standard sperimentale della
Comunità Europea in convergenza con lo standard KNX.
EIB prevede vari mezzi trasmessivi: il doppino telefonico, le onde convogliate, la
radiofrequenza e ETHERNET. Ad una rete EIBus (dorsale di tipo bus dello standard EIB) è
possibile collegare fino a 61.455 dispositivi. La topologia può essere a bus, stella, albero e
soluzioni miste dove comunque la lunghezza totale non deve superare i 1000 metri per
segmento, 700 metri tra i vari dispositivi e 350 metri tra l’alimentatore e il bus. La velocità di
trasmissione è 9600bps.
EIB prevede lo scambio messaggi come paradigma di comunicazione fra i dispositivi.
L’indirizzamento fisico è dato semplicemente dalla posizione del dispositivo nell’impianto.
EIB ha sviluppato inoltre un dispositivo gateway per l’accesso al bus via IP.
161
KNX [54]
Il mercato degli standard per l’automazione domestica negli ultimi anni è stato
caratterizzato da numerosi standard proprietari e da nuovi consorzi che annunciavano la loro
intenzione di sviluppare lo standard del futuro per l’automazione domestica. In Europa è stata
intrapresa la strada della convergenza verso un unico standard. Hanno partecipato alla
convergenza le associazioni BATIBUS, EIBA e EHSA che hanno dato vita inizialmente nel
1998 ad un’unica associazione, TUBA (The Universal Bus Association) e successivamente nel
1999 all’associazione europea KONNEX con sede a Bruxelles.
KONNEX è stata fondata da nove compagnie appartenenti alle associazioni già citate, con lo
scopo di promuovere lo sviluppo di un nuovo standard denominato KNX (BATIBUS, EHS ed
EIB compatibile).
Le compagnie che compongono l’associazione KONNEX provengono da diversi settori:
• produttori di dispositivi elettrici, elettronici e sistemi HVAC;
• sistemi di intrattenimento domestico;
• telecomunicazioni;
• energetico;
• installatori di dispositivi elettrici e HVAC, integratori di sistemi.
KNX utilizza lo stack di comunicazione di EIB con l’ausilio dell’esperienza maturata da
BATIBUS e EHS e prevede tre diverse possibilità di configurazione su quattro diversi mezzi
trasmissivi (ETHERNET wireless e non, doppino telefonico, rete elettrica con onde
convogliate)
In KNX si possono quindi trovare tutte le specifiche e i requisiti elencati nelle descrizioni
precedenti di EIB, EHS e BATIBUS e in particolare sono implemetati i servizi di discovery e
gestione degli eventi (gestione degli eventi distribuiti, dove gli elementi software si possono
sottoscrivere o sollevare un certo tipo di evento).
A.2 Mercato americano
Sembra essere contraddistinto da una maggiore conflittualità tra standard diversi e non è
ancora stata intrapresa una vera e propria strada di convergenza come nel caso del mercato
europeo [50].
162
X-10 [54]
E’ uno standard sviluppato nel 1976 ed è stato il primo ad utilizzare le onde convogliate su
linea elettrica, ottenendo una buona diffusione negli Stati Uniti. E’ un protocollo di
comunicazione per il comando remoto di dispositivi elettrici, progettato per la comunicazione
tra ricevitori e trasmettitori che comunicano in modo standard. In un sistema X-10 i
trasmettitori possono inviare comandi di tipo binario o di tipo intero o reale (integer o real) ai
ricevitori.
La trasmissione dei comandi avviene tramite l’invio d’impulsi da parte di un pannello di
controllo.
Ad ogni ricevitore installato viene associato un ID che serve per permettere uno scambio
messaggi punto a punto con il trasmettitore. Attualmente è disponibile sul mercato qualsiasi
tipo di dispositivo funzionante con tecnologia X-10 e svariati tipi di trasmettitori in grado di
programmare comandi temporizzati.
Le specifiche del protocollo X-10 definiscono 256 indirizzi: 16 classi di codici (A-P) e 16
codici unità (1-15) che risultano più che sufficienti per le esigenze di un’abitazione, visto
anche che più ricevitori possono gestire lo stesso ID (codice di classe e codice unità) e quindi
un singolo comando può essere eseguito da più ricevitori in parallelo.
Il sistema X-10 incontra problemi con l’aumentare del bit rate: interferenze, rumori,
attenuazione, variazioni di impedenza. Sono disponibili dei filtri e dei ripetitori di segnale per
cercare di risolvere questi problemi che risultano più evidenti nei casi in cui la distanza tra il
controllore e il ricevitore supera certi limiti.
CEBUS [64]
E’ un protocollo di comunicazione per l’automazione domestica, divenuto uno standard
negli Stati Uniti. CEBUS è stato sviluppato dalla EIA (Electronic Industries Association)
dopo che nel 1984 ha deciso di standardizzare l’uso dei segnali infrarossi per il controllo
remoto di dispositivi elettrici.
CEBUS (Consumer Electronics Bus) è stato formalizzato nel 1992 mentre il processo per
divenire standard nazionale è iniziato nel 1995.
Un comitato tecnico nato dalla collaborazione dell’IEC (International Electrotechnical
Commission) e dell’ISO (International Organization for Standardization) ha creato un
Working Group per la specifica di standard di automazione domestica HES (Home Electronic
System) al quale si sono unite delegazioni di CEBUS e SMART HOUSE.
163
Oltre 200 compagnie produttrici di dispositivi per l’automazione domestica hanno
partecipato attivamente al processo di definizione del protocollo, influenzando lo standard
con caratteristiche di flessibilità e controllo dei costi nelle applicazioni.
Nelle specifiche di questo standard è previsto l’utilizzo dei seguenti mezzi di trasmissione:
onde convogliate su linea elettrica, doppino, cavo coassiale, infrarossi, radiofrequenza, fibre
ottiche e cavi coassiali specifici per la trasmissione audio-video. Ogni canale di controllo
CEBUS trasmette segnali alla stessa velocità; possono anche trasportare segnali analogici e
digitali a seconda del supporto di comunicazione utilizzato. I comandi e le informazioni
relative allo stato sono trasportati nel canale in forma di pacchetti di byte simili ai
datagrammi.
CEBUS definisce una topologia flessibile, in cui un dispositivo può venire installato ovunque
tramite interfacce CEBUS. I messaggi sono trasmessi nel sistema tra diversi mezzi grazie a a
degli instradatori specifici. Tutte le applicazioni collegate alla rete sono considerate come se
fossero sul bus, quindi ogni componente CEBUS deve rispondere oltre che ai messaggi
individuali, anche ai messaggi che riportano l’indirizzo di broadcast. Il collegamento tra un
dispositivo e la rete CEBUS avviene tramite un circuito chiamato brick.
Ad esempio con l’uso del telecomando del televisore è possibile accendere le luci. Il
televisore riceve il segnale IR da un brick. Il televisore non riconosce il comando che quindi
passa al router il quale invia alla rete elettrica un segnale contenente il comando da
indirizzare all’unità di controllo delle luci. Il controllore del sistema luci riceve il messaggio
ed effettua l’accensione.
CEBUS specifica anche un linguaggio comune per le applicazioni : CAL (Common Language
Application) che permette ai vari dispositivi installati di comunicare. Ogni dispositivo è
definito nel CAL come un contesto (uno stereo o un TV sono possibili contesti), mentre le
proprietà di ogni dispositivo (volume, luminosità, bilanciamento) sono oggetti del contesto.
LONTALK [55]
E’ uno standard nato nel 1990 di proprietà della compagnia americana ECHELON che, con
MOTOROLA e TOSHIBA, si occupa della produzione di un chip neuronale che ne implementa
le specifiche.
ECHELON offre componenti hardware, firmware e software, come completamento di una
struttura di rete denominata LON (Local Operative Network), cioè network operante
localmente. Il protocollo LONTALK è stato sviluppato specificatamente per il funzionamento
164
LON che, quando è completo di hardware e software, viene chiamato LONWORKS. Il principio
di funzionamento del LON si basa su un'unica interfaccia denominata neuron chip che
permette a tutti i dispositivi di interfacciarsi alla rete. Il neuron chip è richiesto da tutti i
dispositivi collegati ad una rete LONWORKS ed è attualmente composto da tre processori ad 8
bit. Due sono ottimizzati per l’esecuzione del protocollo, mentre il terzo per l’applicazione; il
processore si occupa perciò sia della comunicazione che dell’applicazione.
Ciascun nodo di un network LON è programmato in modo da permettere la comunicazione di
specifici dati interni ad uno o più nodi. Le informazioni che uno specifico nodo invia sono
ottenute come risultato di un cambiamento di stato o di eventi programmati. In seguito ad un
cambio di stato in un nodo del network, gli indirizzi dei destinatari di questa informazione
sono codificati dallo strumento di configurazione in un quadro interno del neuron chip.
Le reti LONTALK dispongono di una vasta gamma di mezzi per la trasmissione. I nodi
dotati di hardware o firmware propri (elettrodomestici, interruttori e sensori) possono essere
collegati a qualsiasi mezzo di trasmissione (onde convogliate, doppino, frequenze radio, fibre
ottiche) con una diversa velocità di comunicazione per ognuno di questi.
I segnali tra i vari nodi viaggiano ad una velocità che varia da circa 4000 bit per secondo
(bps) per linee che trasmettono energia elettrica a 1,25 milioni bps per il doppino (con
lunghezza limitata). Ci sono ditte che offrono trasduttori per cavi coassiali e fibre ottiche. Il
network LON è pensato per apparecchi di controllo ma è in grado di supportare, mediante
l’uso di apposite centraline di controllo, la distribuzione di suoni e immagini in modo
analogico. LONTALK fornisce reti separate a seconda che il mezzo di trasmissione sia energia
elettrica o radio. Nel LONTALK ogni rete logica è chiamata domain. LONTALK provvede alla
radio o filo diffusione indirizzata a ciascun nodo presente in un domain o in una rete
subordinata. È ammessa anche una trasmissione di gruppo dove un nodo può essere parte di
gruppi multipli. Attraverso sistemi LONWORKS è possibile controllare il consumo energetico
di ogni singolo apparecchio e gestire scenari di sovraccarico elettrico e blackout.
Particolare attenzione va data al meccanismo di notifica degli eventi che il sistema
LONTALK utilizza dove ciascun nodo di un network LON è programmato in modo da
comunicare specifici dati interni ad uno o più nodi. Questi rapporti sono emanati come
risultato di un cambiamento di stato o di eventi programmati. Gli indirizzi dei destinatari di
un cambio di stato sono codificati in un quadro interno del neuron chip da uno strumento di
configurazione messo a disposizione da LONWORKS. La comunicazione all’interno di
LONWORKS funziona dunque per lo più ad eventi dipendenti da cambi di stato di variabili
165
d’interfaccia pubblicabili sulla rete da ogni dispositivo (nodo). Le variabili d’interfaccia
pubblicate si dividono in variabili d’ingresso e variabili d’uscita. Ogni valore di una variabile
d’uscita di un dispositivo può essere connessa virtualmente a un valore di una variabile
d’ingresso dello stesso tipo di un altro dispositivo. Le variabili di rete e i valori che queste
possono assumere sono definite in uno standard chiamato Standard Network Variable Types
(SNVTS). Questo standard, tra le diverse formalizzazioni, stabilisce che tutte le variabili
pubbliche d’ingresso abbiano il prefisso nvi e tutte quelle d’uscita il prefisso nvo.
HAVI [56]
HAVI (un abbreviazione per Home Audio/Video Interoperability) è un’architettura
sviluppata da un insieme di aziende per facilitare interoperabilità fra dispositivi realizzati da
produttori diversi, in modo da rendere più semplice la realizzazione di applicazioni
distribuite sulla rete domestica.
La definizione di HAVI è avvenuta nel maggio 1998 da un consorzio di cui fanno parte otto
aziende (GRUNDIG, HITACHI, MATSUSHITA, PHILIPS, SHARP, SONY, THOMSON e TOSHIBA) che
possiedono circa l’ottanta per cento del mercato mondiale degli elettrodomestici. La
documentazione prodotta consta di circa 500 pagine e descrive dettagliatamente come i
dispositivi elettronici presenti nell’abitazione devono interagire nella rete domestica del
futuro.
La sua architettura è formata da un insieme di API, da servizi e del protocollo di rete IEEE
1394 (high performance serial bus). HAVI realizza un sistema paritetico dove ogni dispositivo
è in grado di individuare, interrogare e controllare ogni altro dispositivo. E’ possibile inoltre
la cooperazione tra gruppi di dispositivi.
L’architettura di HAVI definisce uno stack per la gestione della comunicazione di base e
l’interazione tra dispositivi sulla rete e, inoltre, un’interfaccia UI (Universal Interface) che
può essere utilizzata indipendentemente dallo stack.
I moduli definiti nello stack HAVI sono:
•
messaging system, responsabile della comunicazione tra dispositivi;
•
registry, che effettua la registrazione di tutti i dispositivi HAVI presenti nella rete;
•
event manager, per la notifica di eventi;
•
stream manager, che realizza il servizio di data stream;
166
•
resource manager, per la gestione della condivisione e dell’allocazione di dispositivi
e risorse;
•
Device Control Module (DCM), il quale controlla un dispositivo HAVI.
HAVI riconosce quattro categorie di apparecchi elettronici: FAV (Full AV), IAV
(Intermediate AV), BAV (Base AV), LAV (Legacy AV). FAV e IAV hanno funzione di
controllo, mentre i dispositivi BAV e LAV possono essere solamente controllati. Ogni
elemento di questa categoria di dispositivi implementa un sottoinsieme dei moduli definiti
nello stack HAVI.
A.3 Mercato giapponese (HBS)
Un consorzio di società giapponesi, con il supporto di agenzie governative, ha definito un
protocollo standard per lo sviluppo di applicazioni per l’automazione domestica denominato
HBS (Home Bus System).
Le applicazioni dell’HBS includono il controllo di dispositivi domestici, audio, video e
accesso a servizi esterni alla casa. Lo sviluppo di HBS è stato promosso da massicci
investimenti di capitali da parte del MITI (Ministry of International Trade and Industry),
REEA (the Radio Engineering and Electronics Association) e EIAJ (Electronics Association
of Japan) Si è inoltre costituito un consorzio di compagnie giapponesi per l’estensione del
sistema HBS. Le compagnie che partecipano a questo sviluppo sono HITALCHI LTD,
MITSUSHITA ELETTRIC INDUSTRIAL CO LTD, MITSUBISHI ELETTRIC CORP e TOSHIBA CORP.
Nella sua versione originale, HBS definiva inizialmente il doppino e il cavo coassiale come
unici mezzi di trasmissione ma oggi è contemplata anche la radio frequenza, è in fase di
sviluppo la possibilità di utilizzo di onde convogliate su linee di potenza. Su questo standard
non ho potuto addentrarmi ulteriormente per la difficoltà di reperire informazioni relative alle
specifiche tecniche.
A.4 Mercato internazionale
Oltre agli standard che si stanno affermando nei diversi continenti, a livello internazionale
si assiste al diffondersi di BLUETOOTH, uno standard che si occupa per lo più
d’interconnessione, ma si occupa anche di fissare regole su diversi livelli della gerarchia OSI
al fine di fornire, built in, numerose funzioni e servizi di supporto alla comunicazione e
167
all’interazione tra dispositivi e servizi. BLUETOOTH è considerato in letteratura uno standard
d’interconnessione wireless evoluto [57].
Il consorzio BLUETOOTH è stato fondato nel 1998 da ERICSSON, IBM, INTEL, NOKIA e
TOSHIBA e comprende attualmente i maggiori produttori di apparecchiature di telefonia,
elettronica e informatica.
BLUETOOTH, che significa dente blu, era il cognome di Harald re vikingo del decimo
secolo, artefice dell’unificazione geografica tra Danimarca e Norvegia. Per la vocazione a
unire mondi diversi, è stato scelto come nome di questa tecnologia che mediante un sistema
radio che opera sui 2,4 GHz consente ad apparecchiature elettroniche e informatiche di
comunicare con una velocità fino ad 1Mb/s nel raggio limitato di una decina di metri. La
tecnologia wireless BLUETOOTH fornisce una connettività voce e dati ad alta capacità e a
basso costo e si propone come standard per i cellulari, personal computer, laptop e moltissimi
altri dispositivi elettronici. La comunicazione avviene tra piccole radio ricetrasmittenti
integrate, altamente performanti, ognuna delle quali ha assegnato un indirizzo unico a 48 bit
proveniente dallo standard IEEE 802. Le specifiche di BLUETOOTH comprendono hardware,
software e requisiti d’interoperabilità.
Ciò che caratterizza la posizione di confine di BLUETOOTH tra una semplice tecnologia
d’interconnessione e una vera e propria architettura per l’automazione domestica sono la sua
capacità di autoconfigurazione dinamica di reti autonome e il suo protocollo di Service
Discovery Protocol (SDP).
Figura A.1 Un esempio di rete wireless formata secondo lo standard BLUETOOTH
168
I dispositivi comunicano tra loro creando e riconfigurando dinamicamente delle reti ad hoc
(dette piconet), composte da un massimo di otto nodi dove uno dei quali funge da master
(gestore della piconet) e gli altri fungono da slave. La configurazione cambia
automaticamente quando si inserisce o si elimina un dispositivo. Più piconet possono a loro
volta interconnettersi (sfruttando il meccanismo master/slave), aumentando le possibilità di
espansione; l’interconnessione tra più piconet forma una rete wireless chiamata scatternet.
Due dispositivi BLUETOOTH vicini tra loro si riconoscono automaticamente e nel caso che
entrambi svolgano un ruolo di master essi realizzano una scatternet su frequenze diverse,
ogni master a sua volta gestisce gli slave della propria piconet (vedi Fig. A.1 [57]).
Il limite dei canali radio disponibili è 79, che rappresenta il numero massimo di master
attivi. Ciò che permette la sincronizzazione dei dati e il giusto scambio semantico e sintattico
delle informazioni tra dispositivi semplicemente avvicinandoli è l’SDP che permette ad un
dispositivo BLUETOOTH di determinare quali sono i servizi che gli altri apparecchi presenti
nella piconet mettono a disposizione. Tale protocollo può fungere sia da server (ossia può
essere interrogato da un altro dispositivo e rispondere con i propri servizi) sia da client
(interrogando gli altri dispositivi) e ogni apparecchio dispone delle informazioni relative ai
servizi di cui è capace e dei protocolli supportati: altri apparati potranno fare uso di queste
informazioni per determinare le possibilità di interazione con i nodi della piconet. Un
esempio concreto, se un telefonino BLUETOOTH vuole trasferire un messaggio di testo a un
PDA, potrà interrogare questo ultimo per sapere se è dotato di funzionalità e-mail, o se è in
grado di ricevere un testo in altro modo. Quando un dispositivo si inserisce per la prima volta
in una piconet, inoltre, effettuerà una scansione di tutti i nodi presenti per capire come può
interagire con essi.
Le principali caratteristiche tecniche di BLUETOOTH sono di seguito riassunte.
•
Utilizzo di banda di 2.4 GHz ISM (Industrial Scientific Medical);
•
Portata massima di 100 metri. Viene definito un campo di trasmissione corto (circa 10
metri) e, alternativamente, medio (circa 100m) per la trasmissione via radio di dati e
voce con una velocità massima di 720 Kb/s per ogni canale;
•
Utilizzo del Frequence Hop (FH) spread spectrum che divide la banda di frequenza in
un numero di sottocanali (79 frequenze ad intervalli di 1 MHz per ottenere migliori
prestazioni in presenza di interferenze);
•
Usa pacchetti corti per massimizzare la capacità in caso di interferenze. Con
169
l’aumentare delle interferenze, la diminuzione delle prestazioni è minima e graduale,
in modo da mantenere la stabilità dei link;
•
Possibilità di saltare da una sottofrequenza all’altra durante la connessione;
•
Sistemi di sicurezza e riservatezza integrati;
•
Trasmissione attraverso muri e oggetti;
•
Omnidirezionale;
•
Supporto del protocollo TCP/IP;
•
La banda di frequenza è regolata per la legge in tutto il mondo. Il consorzio afferma
che le trasmissioni radio BLUETOOTH si conformeranno agli standard nei paesi in cui
tale tecnologia verrà utilizzata.
Quando sono state definite le specifiche è stata posta molta enfasi nel realizzare un design
che permettesse l’implementazione di questa tecnologia in un unico chip (CMOS), riducendo
così costi, consumi e le dimensioni del circuito complessivo (caratteristica necessaria per
l’utilizzo in telefoni cellulari e piccoli dispositivi in genere).
OSGI [49]
Il componente centrale di questa struttura è il service gateway che funziona da piattaforma
per tutti i servizi basati sulla comunicazione multimediale. Il service gateway permette la
gestione di audio, video, dati Internet e multimediali provenienti dalla rete domestica o ad
essa destinati. Può inoltre funzionare come un application server per una vasta serie di servizi
ad alto livello come la gestione dell’energia, della sicurezza, della manutenzione, del
commercio elettronico ecc. Il service gateway rappresenta per i provider il punto focale di
riferimento al quale mirare per fornire tutte le tipologie di servizi avanzati sia innovativi che
già esistenti.
La comunicazione tra provider e abitazione è permessa grazie alla specifica di una API,
messa liberamente a disposizione dai programmatori e scritta in linguaggio JAVA e che
quindi può, almeno in teoria, essere esportata su qualunque tipo di piattaforma. Come si può
ben capire le caratteristiche che rendono forte e universale l’iniziativa dell’OSGI sono
l’indipendenza da ogni tipo di supporto e la standardizzazione degli aspetti legati alla
comunicazione.
170
HES [48]
L’HES formalizza delle regole d’interoperabilità. Per permettere l’interfacciamento tra
diverse tecnologie domotiche, l’HES formalizza i seguenti componenti logici ai quali si deve
far riferimento per conformarsi allo standard HES.
•
Universal Interface: un modulo da incorporare in un apparecchio per comunicare su
varie reti di home automation. Il dispositivo deve essere dotato di una interfaccia
universale (UI) composta da una spina standard. Un linguaggio di comunicazione
standard è in via di sviluppo per tutti i comandi e messaggi di applicazione. Ogni
punto di collegamento alla rete contiene una unità di accesso (Network Access Unit,
NAU) per convertire i segnali e i messaggi di un dispositivo in un particolare
protocollo di comunicazione della home automation (vedi Fig. A.2).
•
Command Language: un linguaggio per la comunicazione tra gli apparecchi
indipendente dalla rete che trasporta i messaggi.
•
Home Gate: un accesso residenziale per collegare la rete domestica con la rete di
servizio degli enti fornitori (ad esempio la rete di distribuzione elettrica).
Figura A.2 Schematizzazione dell’interconnessione tra dispositivi eterogenei su una stessa rete di
automazione domestica prevista dallo standard HES
La strada percorsa dall’IEC nel definire delle standardizzazioni per la domotica sembra
riuscire a mettere d’accordo tutti gli operatori del mercato. In quanto, l’HES non impone uno
standard unico con caratteristiche hardware e software standardizzate, ma cerca di preservare
gli innumerevoli standard esistenti imponendo solo delle regole formali d’interfacciamento
171
alle quali ogni dispositivo, indipendentemente dallo standard a cui appartiene, dovrà
conformarsi.
172