L’attivazione degli scenari temporizzati e degli scenari personalizzati tem- porizzati `e ovvia; una volta appresi vengono effettuate tutte le azioni che li compongono all’orario stabilito.
Nel caso di scenari personalizzati l’attivazione `e legata ad una azione specifica, ad esempio l’ingresso nell’ambiente; quando l’utente entra nell’am-
CAPITOLO 8. IMPLEMENTAZIONE DEL SISTEMA
biente lo scenario viene attivato, eseguendo tutte le azioni volte a modellare l’ambiente secondo le preferenze apprese.
Nel caso di scenari non temporizzati l’attivazione `e legata all’esecuzione, in sequenza, delle azioni antecedenti; una volta eseguita tale sequenza di azioni lo scenario viene attivato, eseguendo tutte le comandi corrispondenti.
Capitolo 9
Moduli software
Introduciamo adesso i differenti moduli cooperanti che costituiscono il sistema, mostrando l’implementazione dei vari moduli cooperanti che costi- tuiscono il sistema.
9.1
DomoPredictClient
Il client standard domoNet, detto DomoNetClient, esegue il controllo dei dispositivi in remoto indipendentemente dalla loro tecnologia; esso attua la connessione ad uno o pi`u web service contemporaneamente, caricando la lista dei dispositivi connessi alla rete (domoDevice) attraverso il metodo getDeviceList(), e inviando comandi di tipo domoMessage attraverso il me- todo execute(dm). Per qualche dispositivo `e previsto anche un parametro di ritorno. Tutti i domoDevice sono memorizzati nella domoDeviceList. Il domoNetClient gestisce solamente la parte logica del lato client. Per po- ter interagie con essa, `e necessario implementare una user interface tramite un’applicazione web, testuale o grafica.
CAPITOLO 9. MODULI SOFTWARE
9.2
LogManager
Il modulo LogManager ha il compito di memorizzare i messaggi di aggior- namento ricevuti, costruendo ed aggiornando il file di log del sistema; tale file pu`o essere usato sia per finalit`a diagnostiche, utili per individuare eventuali problemi o malfunzionamenti, sia per ricostruire l’insieme degli stati in cui si `e trovato il sistema nel passato.
Il modulo permette di riprodurre le azioni effettuate nel passato dagli utenti, in modo da riportare il sistema in uno stato corretto nei casi in cui questo sia necessario; in tal caso possiamo vedere il file di log come il dataset storico del sistema.
9.3
AssociationRulesManager
Il modulo AssociationRulesManager ha il compito di eseguire la fase di analisi seguendo l’approccio Data Mining, utilizzando la tecnica di apprendi- mento di regole associative per apprendere gli scenari non temporizzati dai dati di utilizzo dei dispositivi; esegue inoltre la fase di esecuzione delle regole, attuando gli scenari appresi in risposta alle azioni effettuate dagli utenti.
Vediamo nel dettaglio il processo di apprendimento degli scenari. Tutti i sistemi di Data Mining necessitano di un dataset, solitamente preesistente, sul quale basare la fase di analisi; nel nostro caso il dataset non esiste al momento dell’installazione del sistema, ma verr`a costruito in tempo reale mediante gli aggiornamenti diffusi da domoNet in caso di aggiornamenti di stato dei dispositivi. Non `e necessario comunque attendere un lungo periodo di tempo, in attesa che sia costruito un dataset abbastanza grande, prima di eseguire la fase di analisi; essa pu`o e viene effettivamente eseguita dal primo istante, in tempo reale, tenendo ovviamente conto del fatto che i pochi dati a disposizione potrebbero portare all’acquisizione di abitudini non corrette.
CAPITOLO 9. MODULI SOFTWARE
il minimo supporto; il valore di supporto minimo `e un parametro variabile del sistema che viene settato all’installazione e modificato durante l’esecu- zione del programma, diminuendolo fino a 0 sul lungo periodo. Essendo il parametro utilizzato per valutare se un gruppo di azioni `e frequente basta aumentarne il valore per rendere pi`u difficile l’apprendimento di scenari in presenza di dataset piccoli, impedendo che siano presi in considerazione item- set poco frequenti; pertanto inizialmente sar`a settato ad un valore piuttosto alto, per poi diminuirlo nel lungo termine in modo da vedere come frequenti praticamente tutti gli itemset, permettendo quindi l’apprendimento anche di abitudini pi`u rare.
Il processo di apprendimento `e invocato ad ogni nuovo messaggio di ag- giornamento dello stato del sistema, dovuto ad una azione di un utente; pos- siamo vedere quindi la fase di apprendimento degli scenari non temporizzati come un ciclo infinito composto dalle seguenti azioni:
• ad ogni messaggio ricevuto da domoNet viene associato un codice uni- voco, in modo da permettere di stabilire comodamente se due messag- gi di aggiornamento sono uguali; ci`o `e necessario per semplificare il confronto tra due messaggi, data la complessa struttura degli stessi; • si controlla se il messaggio ricevuto `e da scartare poich`e frutto di co-
mandi inviati dal manager per l’attivazione di uno scenario, e nel tal caso lo si ignora (aggiornandone per`o il support count ); ricordiamo che in questo contesto per scenario si intende una implicazione A → B tra insiemi di azioni, volta a rappresentare una abitudine;
• si controlla se il messaggio ricevuto rappresenta una risposta ad un comando inviato dal sistema, e pertanto rappresenta un rinforzo al- l’apprendimento; nel tal caso la regola appena eseguita non dovr`a pi`u essere eseguita n`e appresa almeno per qualche giorno;
• si controlla se esiste un itemset attivo, controllando se la distanza tem- porale tra il messaggio ricevuto ed il precedente `e maggiore della fine- stra temporale impostata; se si il messaggio viene aggiunto all’itemset,
CAPITOLO 9. MODULI SOFTWARE
altrimenti ne viene creato uno nuovo e si d`a il via alla fase di analisi per l’itemset precedente;
• si controlla se esiste uno scenario che pu`o essere eseguito in base all’i- temset attivo corrente, e nel caso lo si esegue.
L’analisi di ogni singolo itemset prevede i seguenti passi:
• si aggiorna il support count di tale itemset, e di tutti i suoi sottoinsiemi; • si controlla se esistono scenari precedentemente appresi che non sono
pi`u validi;
• si controlla se esistono nuovi scenari basati sull’itemset in esame.
Approfondiamo alcuni punti chiave del processo. All’arrivo di un nuovo messaggio il primo controllo che viene effettuato `e stabilire se esso `e da scar- tare in quando frutto di comandi inviati dal manager; ci`o `e legato al fatto che ad ogni azione eseguita da un dispositivo all’interno della rete domoNet corrisponde la generazione di un messaggio di aggiornamento di stato, che verr`a ricevuto da ogni DomoNetClient che ne abbia fatto richiesta al server secondo la politica publish/subscribe. Da ci`o segue che i messaggi di aggior- namento di stato ricevuti dopo l’esecuzione di uno scenario potrebbero essere legati ai comandi inviati dal modulo stesso, e pertanto si rende necessario un meccanismo per riconoscere tali messaggi in modo da scartarli; il meccanismo utilizzato `e una semplice discard list, contenente i messaggi di aggiornamento di stato che verranno ricevuti in risposta ad uno scenario eseguito. Ad ogni esecuzione di uno scenario i messaggi di aggiornamento di stato, relativi ai dispositivi ai quali sono stati inviati i comandi, verranno aggiunti alla di- scard list in modo tale che alla loro ricezione essi possano essere ignorati; ovviamente il messaggio corrispondente dovr`a essere eliminato dalla lista.
Il controllo successivo mira a stabilire se l’ultima azione eseguita `e un rin- forzo all’apprendimento, concetto che abbiamo precedentemente introdotto
CAPITOLO 9. MODULI SOFTWARE
nel capitolo 7.1; in caso affermativo lo scenario acquisito non `e corretto, per- tanto `e necessario un meccanismo per tenere a mente le regole non corrette. La soluzione adottata sfrutta una black list contenente le regole apprese er- roneamente dal sistema; tali regole non dovranno pi`u essere apprese per un numero di giorni, variabile ma crescente, dipendente dal numero di volte nelle quali l’utente ha fornito un rinforzo negativo.
Come introdotto in precedenza, le regole associative vengono apprese me- diante l’algoritmo Apriori, introdotto nel capitolo 5.3, con la fase di gene- razione dei candidati implementata secondo il metodo F(k-1) X F(k-1); `e importante sottolineare che i parametri di confidenza e supporto sono cen- trali per il corretto apprendimento delle abitudini degli utenti, e pertanto stabilire il loro corretto valore (iniziale per quanto riguarda il supporto) `e uno dei principali problemi da risolvere per il corretto funzionamento del si- stema. Il processo di stima di questi parametri per valutarne l’ottimalit`a `e presente nel capitolo 10.
9.4
StatisticRulesManager
Il modulo StatisticRulesManager ha il compito di effettuare la fase di analisi seguendo un approccio statistico, in modo da apprendere gli scenari temporizzati e le due diverse tipologie di scenari personalizzati ; il modulo esegue inoltre la fase di esecuzione delle regole, attuando gli scenari appresi al momento opportuno. Vediamo nel dettaglio come viene effettuata la fase di analisi per individuare gli scenari delle tipologie suddette.
Il modulo `e invocato ad ogni messaggio di aggiornamento di stato dei dispositivi facenti parte del sistema AmI, ed utilizza tali messaggi per rico- struirne lo stato attuale; i differenti stati in cui si `e trovato il sistema vengo- no ricostruiti sulla base delle informazioni memorizzate nella struttura dati ServiceUpdates. Questa struttura tiene traccia di ogni messaggio di aggior- namento ricevuto, che viene memorizzato in una lista di coppie <dispositivo,
CAPITOLO 9. MODULI SOFTWARE
informazioni sull’aggiornamento>, e viene utilizzata come base per costruire le tabelle di utilizzo del sistema, chiamate UsageTable, necessarie per indi- viduare quelle abitudini che non sono strettamente legate alle sequenze di azioni effettuate dagli utenti.
La UsageTable `e una struttura dati, anch’essa di tipo lista, che associa ad ogni dispositivo facente parte del sistema AmI una ulteriore struttura dati, chiamata UsageTableEntry, contenente una lista di associazioni <stato dispositivo, percentuale>; la funzione della struttura dati UsageTableEntry `e quella di associare quanto tempo, in percentuale, il dispositivo si `e trovato in un determinato stato nell’intervallo di tempo in esame, per ogni stato possibile.
L’apprendimento degli scenari temporizzati non richiede l’utilizzo delle UsageTable, dato che l’obiettivo `e stabilire se una o pi`u azioni vengono ese- guite abitualmente in un dato orario; il modulo sfrutter`a direttamente le informazioni presenti nella struttura dati ServiceUpdates, sufficienti a stabi- lire se un dato aggiornamento di stato di un dispositivo si ripete abitualmente alla stessa ora per un dato periodo di tempo.
Per permettere l’apprendimento delle due diverse tipologie di scenari per- sonalizzati lo stato dei dispositivi deve essere invece monitorato; per gli sce- nari personalizzati semplici `e necessario monitorare solo l’utilizzo di alcuni dispositivi per l’intero ciclo di vita del sistema, in quanto le abitudini le- gate alla temperatura preferita, all’intensit`a di luce e ai gusti musicali non dipendono particolarmente da fattori esterni, come ad esempio la stagione; per quanto riguarda gli scenari personalizzati temporizzati, dato che vengono monitorati tutti i dispositivi del sistema, la dipendenza da fattori esterni `e no- tevole e pertanto `e sensato considerare solo i dati raccolti nell’ultimo periodo. Esistono pertanto differenti UsageTable, ognuna con uno scopo specifico:
• TimeIntervalUsageTable, costruita con lo scopo di monitorare lo stato di tutti i dispositivi ogni n minuti, sfruttando le informazioni contenute nella struttura ServiceUpdates, ed utilizzata sia per la fase di appren-
CAPITOLO 9. MODULI SOFTWARE
dimento degli scenari personalizzati temporizzati che come base per costruire le DailyUsageTable;
• DailyUsageTable, costruita sulla base della TimeIntervalUsageTable con lo scopo di monitorare lo stato di tutti i dispositivi su scala giornaliera, viene utilizzata come base per la costruzione della TotalUsageTable; • TotalUsageTable, costruita sulla base della DailyUsageTable, dalla qua-
le estrae le informazioni necessarie per costruire i differenti profili uten- te, ed utilizzata per la fase di apprendimento degli scenari personaliz- zati.
Data la natura statistica, il modulo non `e in grado di produrre nuove regole prima di aver accumulato una quantit`a sufficiente di dati, pur ag- giornandosi in tempo reale; per la prima settimana di utilizzo del sistema si limiter`a pertanto a raccogliere dati e tenere aggiornate le varie strutture dati, e solo successivamente a questa fase di startup verr`a avviato il reale pro- cesso di apprendimento degli scenari. Una volta acquisiti i dati, il processo di apprendimento per gli scenari temporizzati sar`a eseguito in tempo reale, mentre quello per gli scenari personalizzati semplici e quello per gli scenari personalizzati temporizzati sar`a eseguito una volta al giorno, e schedulato ad un’ora nel quale gli aggiornamenti di stato dei dispositivi siano improbabili; l’orario di schedulazione `e un parametro del sistema, di default settato a 00:00.
Un altro parametro chiave del modulo `e rappresentato da quanto voglia- mo considerare lungo il periodo di monitoraggio per l’apprendimento degli scenari personalizzati temporizzati ; esso `e un parametro del sistema, chia- mato period, utilizzato anche per l’apprendimento degli scenari temporizzati. Da questo parametro dipende anche la quantit`a di TimeIntervalUsageTa- ble da archiviare per la fase di apprendimento degli scenari personalizzati temporizzati.
Analizziamo i dettagli dei differenti processi di apprendimento. Il pro- cesso di apprendimento per gli scenari temporizzati mira a stabilire se una
CAPITOLO 9. MODULI SOFTWARE
azione eseguita da un utente `e abituale nell’ultimo periodo, corrispondente ad un numero di giorni uguale al parametro period ; questo compito `e ese- guito in tempo reale, all’arrivo di un nuovo messaggio di aggiornamento di stato di un dispositivo. Tramite confronti viene stabilito se l’azione eseguita `e abituale, ed in caso affermativo viene creata una nuova regola che associa l’azione corrispondente all’orario di esecuzione; tale azione verr`a aggiunta tra i task dello scheduler, incaricato di eseguire le regole tutti i giorni all’ora corretta. Oltre ad apprendere nuovi scenari il modulo deve essere in grado di individuare se una abitudine appresa non `e pi`u valida; per fare ci`o ogni giorno, insieme ai processi per apprendere le due tipologie diverse di scenari personalizzati, il modulo esegue il test di validit`a sugli scenari temporizzati appresi, in modo da eliminare quelli non pi`u validi.
Il processo di apprendimento per entrambe le tipologie di scenari perso- nalizzati `e schedulato una volta al giorno; il primo passo `e quello di costruire ed aggiornare le differenti UsageTable. La TimeIntervalUsageTable, conte- nente le informazioni di utilizzo del sistema riferite al giorno passato, viene costruita sulla base delle informazioni contenute nella ServiceUpdates; da questa viene ricostruita la DailyUsageTable utilizzata per aggiornare la To- talUsageTable. Una volta effettuate queste operazioni preliminari vengono eseguiti i processi di apprendimento veri e propri.
Il processo di apprendimento per gli scenari personalizzati semplici pre- vede l’esistenza di un unico scenario personalizzato per ogni utente, che verr`a eseguito al suo ingresso nell’ambiente intelligente; purtroppo per mancanza di sensori idonei non sono stati monitorati i parametri vitali degli utenti, pertan- to la parte di prevenzione ed intervento in situazioni di pericolo rappresenta un possibile sviluppo futuro.
Uno scenario personalizzato semplice `e espresso nella forma A =⇒ B, analoga a quella degli scenari non temporizzati ; A corrisponde all’azione di ingresso dell’utente nell’ambiente e B `e l’insieme di azioni necessarie per impostare le preferenze relative a temperatura, gusti musicali e intensit`a di luce.
CAPITOLO 9. MODULI SOFTWARE
Il processo di apprendimento per gli scenari personalizzati semplici pre- vede i seguenti passi:
• sulla base dei valori aggiornati contenuti nella TotalUsageTable si ag- giornano nei profili utente le informazioni su temperatura preferita, gusti musicali ed intensit`a di luce;
• se non sono ancora stati creati gli scenari personalizzati semplici (ven- gono creati solo dopo period giorni) ne viene creato uno per ogni utente sulla base delle informazioni contenute nel profilo;
• altrimenti si controlla se gli scenari esistenti devono essere a loro volta aggiornati, sulla base degli aggiornamenti ai profili utente.
L’esecuzione dello scenario `e gestita esattamente come per gli scenari non temporizzati ; l’ingresso dell’utente nell’ambiente intelligente corrispon- de alla ricezione del messaggio di aggiornamento di stato del dispositivo di rilevamento impronte digitali, posto all’ingresso della stanza domotica. Il messaggio contiene ovviamente l’identificativo dell’utente appena entrato, e ci`o `e sufficiente per eseguire lo scenario personalizzato semplice costruito sulle sue preferenze.
Il processo di apprendimento per gli scenari personalizzati temporizzati inizia con la costruzione di una singola TimeIntervalUsageTable, contenente le informazioni di utilizzo del sistema nell’ultimo periodo; tale tabella `e otte- nuta tramite l’aggregazione dei dati contenuti nella TimeIntervalUsageTable appena costruita, contenente le informazioni di utilizzo del sistema relative al giorno passato, e dei dati contenuti nelle TimeIntervalUsageTable archiviate negli ultimi Period giorni.
Una volta costruita la TimeIntervalUsageTable il processo di apprendi- mento per gli scenari personalizzati temporizzati prevede i seguenti passi:
• si scansiona la TimeIntervalUsageTable per individuare degli stati abi- tuali dei dispositivi, per ogni intervallo di tempo. Per stati abituali
CAPITOLO 9. MODULI SOFTWARE
dei dispositivi si intende che essi, nell’intervallo temporale di interesse, saranno in un determinato stato con probabilit`a maggiore di un valore di soglia definito come parametro del sistema;
• se vengono individuati, viene appreso un nuovo scenario personalizzato temporizzato, che consiste in una regola temporizzata identica a quelle generate dal processo di apprendimento degli scenari temporizzati. • si controlla se gli scenari personalizzati temporizzati appresi nei giorni
passati sono sempre validi in base alle informazioni aggiornate, ed in caso negativo si eliminano.
L’esecuzione di questi scenari `e identica a quella degli scenari temporiz- zati ; per ogni scenario appreso viene aggiunto un task allo scheduler che si prender`a la briga di eseguire le azioni previste dallo scenario all’orario corretto.
Capitolo 10
Validazione e test
Come detto in precedenza, tutti i sistemi di Apprendimento Automatico necessitano di un insieme di dati di allenamento piuttosto grande per una corretta validazione; nel nostro caso per scelta implementativa il dataset sar`a costruito in tempo reale, partendo da zero. Questa scelta ha il vantaggio di permettere l’apprendimento degli scenari sin da subito, ma espone al rischio di acquisire abitudini non corrette, dovuto principalmente alle limitate di- mensioni iniziali del dataset; ci`o `e particolarmente vero per l’apprendimento degli scenari non temporizzati che, essendo appresi mediante la tecnica di Da- ta Mining nota come apprendimento di regole associative, necessiterebbero di un dataset sufficientemente grande.
Fortunatamente questo problema `e superabile, in quando le abitudini variano molto a seconda dei diversi periodi dell’anno, e pertanto limitare l’a- nalisi all’ultimo periodo permette di ottenere risultati apprezzabili anche in assenza di grandi quantit`a di dati storici; quando questi saranno disponibili il sistema offrir`a ovviamente risultati migliori, ma gi`a con un dataset di di- mensioni limitate dovremmo essere in grado di dare una valutazione accurata delle capacit`a di apprendimento del sistema.
Data questa premessa, per la fase di validazione e test sono stati raccolti dati di utilizzo del sistema per due settimane, arricchiti successivamente con
CAPITOLO 10. VALIDAZIONE E TEST
altri dati frutto di randomizzazione e replicazione, in modo da avere a dispo- sizione dati per quattro settimane di utilizzo del sistema; tali dati sono stati raccolti sia interagendo direttamente con i dispositivi all’interno della stan- za domotica, grazie anche alla disponibilit`a dei ricercatori del Domotics Lab che si sono gentilmente prestati ad eseguire azioni sia richieste che casuali, che tramite l’interfaccia client di domoNet, dalla quale `e possibile eseguire comandi da remoto.
Per quanto riguarda le abitudini riprodotte, si `e cercato di rappresentare, tramite le azioni compiute, delle abitudini credibili, integrate con un grande numero di azioni pseudo-casuali in modo da rendere pi`u verosimili i dati raccolti; sono state rappresentate situazioni abituali, temporizzate o meno, cercando di sfruttare la maggior parte dei sensori disponibili. Gli scenari rappresentati sono i seguenti:
• svegliarsi intorno alle 07:30, corrispondente all’accensione della luce in camera;
• entrare in casa, corrispondente all’apertura della porta di ingresso (con relativa identificazione tramite lettore di impronte) e all’accensione della luce nell’ingresso stesso;
• andare in soggiorno a guardare la TV, corrispondente al rilavamento della presenza, all’accensione della luce e della TV in soggiorno; • farsi una doccia intorno alle 19, corrispondente all’accensione della luce