Denizione e sviluppo di metodologie per la gestione dei ... · Denizione e sviluppo di metodologie...

POLITECNICO DI MILANO

Facoltà di Ingegneria Industriale e dell’informazione

Corso di Laurea Magistrale in Ingegneria Informatica

Definizione e sviluppo di metodologie per la gestione dei

consumi energetici nei dispositivi mobili

Relatore: Prof. Marco D. Santambrogio

Correlatori:Phd. Francesco Trovò

Dott. Ing. Matteo Ferroni

Tesi di Laurea di:

Giulia Rumi

Matricola n. 797753

Anno Accademico 2013-2014

A mia mamma Cinzia e a mia sorella Debora, sempre con me

Giulia

Ringraziamenti

Eccomi giunta alla fine di questo lungo percorso di tesi e di questi anni di Università,

nei quali ho potuto maturare come persona.

In questa pagina vorrei ringraziare tutte le persone che mi hanno sempre sostenuta

e accompagnata durante questi anni. Grazie innanzitutto al mio relatore Marco San-

tambrogio e ai miei correlatori Matteo Ferroni e Francesco Trovò per avermi supportato

durante questa tesi. Grazie al NECST Lab e soprattutto ad Alessandro, Emanuele, John,

Phil e Andrea per i bei momenti trascorsi, le lunghe ore di studio e per le partite a bam-

bam. Grazie a mia mamma Cinzia, a mia sorella Debora e ai miei nonni Giuditta, Ernesto

e Marta per esserci sempre stati sia nei momenti di difficoltà che in quelli di gioia. Grazie

a Gian per il suo supporto costante e per la carica che riesce a darmi. Grazie a Ilaria, Alice

e Axel per tutti gli anni di amicizia che ci uniscono. Grazie a Simone per le lunghe ore di

studio passate insieme e per i bei momenti trascorsi. E in fine grazie a Claudia e Chiara

per essere sempre state due fantastiche compagne di avventura.

Giulia

iii

Abbreviazioni

B.H. Battery Historian. iv, 18, 19

B.I. Batch Identification. iv, 32, 35

B.M. Batch Manipulation. iv, 32, 35

D.M. Data Manipulation. iv, 32, 35

i.i.d. indipendenti, identicamente distribuite. iv

S.M.L. Stima del Modello Lineare. iv, 32, 33, 36, 38, 53

MA Modello attuale. iv, 75, 77–79

M.C. Modello base di carica. iv, 87, 88

M.C.1 Modello di carica a 1 minuto. iv, 87, 88

M.C.5 Modello di carica a 5 minuti. iv, 87, 88

MD Modello dinamico. iv, 75, 77–79

m.e.p. Errore medio puntuale. iv, 74, 77–79, 85, 86, 88, 92

MG Modello giornaliero. iv, 75, 77–79

m.m.e.p. Errore medio puntuale relativo alla pendenza. iv, 74, 77–79, 85, 92

m.m.s.e. Errore quadratico medio relativo alla pendenza. iv, 74, 77–79, 85, 92

MO Modello orario. iv, 75, 77–79

m.s.e. Errore quadratico medio. iv, 74, 77–79, 85, 86, 88, 92

P.F. Punto Finale. iv, 73, 77–79, 85, 86, 88, 92

P.P. PreProcessing. iv, 32, 33

S Simulation. iv, 33, 38

v

vi Abbreviazioni

S.O. sistema operativo. iv, xii, 10, 18, 34, 71, 73, 89

TTC Time To Charge. iv, vii, xiii, 5, 7, 10, 16, 31, 37, 39, 42, 47, 69, 70, 73, 86, 88, 90,

92, 93

TTL Time To Live. iv, vii, xi, xiii, xv, 1, 3, 5–7, 10–18, 31–33, 36–39, 47, 48, 50, 53,

54, 58, 59, 73, 74, 76, 88–93, 95

U.P. User Profile. iv, 33, 36–38

SOMMARIO

Oggi giorno l’utilizzo di dispositivi mobili quali cellulari e tablet è diventato

essenziale nelle attività quotidiane ed è quindi di fondamentale importanza esse-

re in grado di gestirne il tempo di autonomia, detto Time To Live (TTL). Proprio

per l’attualità di questo problema, in letteratura sono presenti numerosi studi che

lo analizzano e anche il Politecnico di Milano ha deciso di affrontarlo attraverso

l’implementazione dell’applicazione MPower.

Lo scopo di MPower è quello di permettere all’utente finale di gestire i con-

sumi energetici del proprio dispositivo mobile. Per raggiungere questo scopo è

stato sviluppato un modello di potenza basato sui valori assunti dalle compo-

nenti hardware del dispositivo. Il modello proposto è quindi un modello deter-

ministico che non tiene in considerazione le abitudini dell’utente nel calcolo del

TTL.

La metodologia presentata in questo elaborato si pone in questo contesto con

l’obiettivo di migliorare la gestione energetica del dispositivo introducendo il

comportamento dell’utente all’interno del modello di potenza per il calcolo del

TTL e completando le informazioni fornite all’utente attraverso l’introduzione

dell’informazione relativa al tempo necessario per ricaricare il proprio dispositivo

mobile, detto Time To Charge (TTC).

Grazie alla metodologia proposta è infatti possibile sfruttare le informazio-

ni disponibili relative al comportamento dell’utente all’interno dell’applicazio-

ne MPower per aumentare l’efficacia in termini di precisione di predizione del

TTL; poiché il comportamento dell’utente non è deterministico è stato necessario

vii

viii Abbreviazioni

sviluppare una metodologia stocastica in grado di adattarsi ai continui cambia-

menti di contesto e di simulare il comportamento dell’utente stesso. Questo ha

permesso di migliorare le prestazioni ottenute da MPower e quindi di fornire

un’informazione più precisa all’utente finale.

La metodologia proposta in questo elaborato è stata poi sviluppata e integrata

all’interno dell’applicazione MPower, scaricabile da Google Play store.

SOMMARIO ESTESO

Nel 2014 la diffusione dei cellulari ha raggiunto più del 63,5% della popo-

lazione globale e si prevede una sempre maggiore crescita del settore in futuro.

Questo trend positivo è fortemente legato alla nascita e alla rapida diffusione de-

gli smartphone. I dispositivi mobili quali cellulari e tablet sono infatti diventati

indispensabili nelle attività quotidiane ed è quindi di fondamentale importanza

essere in grado di gestirne il tempo di autonomia, detto TTL. Proprio per l’attua-

lità di questo tema, in letteratura sono presenti numerosi studi che lo analizza-

no e anche Google ha deciso di affrontare questa tematica attraverso il progetto

Volta, che si è poi sviluppato all’interno del sistema operativo Android Lollipop

nell’applicazione historian table; ovvero una funzionalità in grado di informare

l’utente del tempo di autonomia residuo del dispositivo. Il Politecnico di Milano

e in particolar modo il NECST Lab hanno invece deciso di affrontarlo attraverso

l’implementazione dell’applicazione MPower.

Lo scopo di MPower è quello di permettere all’utente finale di gestire i consu-

mi energetici del proprio dispositivo mobile. Per raggiungere questo scopo è stato

sviluppato un sistema biparte; da un lato un applicazione mobile con lo scopo

di: far visualizzare all’utente l’informazione relativa al TTL, supportare l’uten-

te nella gestione energetica del proprio dispositivo mobile e infine loggare tutte

le informazioni relative ai componenti hardware del dispositivo, senza impatta-

re sul consumo della batteria. Dall’altro un sistema back end che si occupa di

memorizzare i dati raccolti dall’applicazione e di calcolare il modello di potenza

relativo al TTL; quest’ultimo è basato sui valori assunti dalle componenti hard-

ix

x Abbreviazioni

ware del dispositivo. Una delle ipotesi su cui si basa il modello di potenza attuale

è che le impostazioni hardware del dispositivo non vengano modificate durante

l’utilizzo del dispositivo, ovvero per tutto il tempo che trascorre tra una ricarica e

l’altra. In altre parole il modello attuale è un modello deterministico che non tiene

in considerazione le abitudini dell’utente nel calcolo del TTL.

La metodologia presentata in questo elaborato si pone in questo contesto con

l’obiettivo di migliorare l’accuratezza della previsione del TTL introducendo il

comportamento dell’utente all’interno del modello di potenza. Questa scelta im-

plica quindi l’introduzione del concetto di tempo all’interno del modello di po-

tenza; si può infatti ritenere che le abitudini dell’utente cambiano con il tempo,

ovvero si modificano a seconda dell’ora del giorno e di conseguenza dell’attività

che l’utente sta svolgendo. Per raggiungere questo scopo sono stati sviluppati tre

algoritmi basati sul modello della catena di Markov, che sono: modello giorna-

liero, modello orario e modello dinamico. La scelta di sviluppare più algoritmi

nasce dalla necessità di introdurre la variabile tempo in un modello che per sua

stessa definizione ne è indipendente; per questo motivo il concetto di tempo viene

simulato andando a differenziare il numero di modelli prodotti:

• modello giornaliero: implementazione standard dell’algoritmo markovia-

no. In questo caso viene prodotto un unico modello indipendente dal mo-

mento della giornata in cui viene calcolato.

• modello orario: in questo caso si è deciso di implementare 24 modelli di

Markov, uno per ogni ora del giorno. Il modello finale è una concatenazione

dei diversi modelli.

• modello dinamico: in questo caso si è deciso di implementare un numero

di modelli di Markov che dipende fortemente dalle abitudini dell’utente

durante la giornata. Il modello finale è anche in questo una concatenazione

dei diversi modelli creati.

Abbreviazioni xi

L’altro contributo di questo elaborato è quello di completare le informazioni

fornite all’utente attraverso l’introduzione di una nuova metrica detta TTC e defi-

nita come il tempo necessario per ricaricare il proprio dispositivo mobile. Quello

che si è scoperto durante l’analisi è che il tempo di ricarica del dispositivo, a diffe-

renza del TTL, è indipendente dalle abitudini dell’utente ma dipende solamente

dal tipo di caricabatterie utilizzato; si è quindi sviluppato un modello di poten-

za lineare in grado di clusterizzare i dati raccolti al fine di distinguere le diverse

tipologie di ricarica.

L’introduzione della metodologia appena descritta ha portato a un miglio-

ramento nella precisione nel calcolo del TTL e a una maggior completezza del-

le informazioni fornite all’utente per la gestione energetica del proprio dispo-

sitivo grazie all’introduzione del TTC. Viene inoltre fornito un confronto tra le

prestazioni di MPower e quelle dell’historian table di Android Lollipop.

La metodologia proposta in questo elaborato è stata sviluppata e integrata

all’interno dell’applicazione MPower, scaricabile da Google Play store.

Andiamo ora a presentare una descrizione dettagliata della struttura della

tesi.

• Capitolo 1 Introduzione: presenta il contesto che ha determinato l’insorge-

re del problema, il quale verrà successivamente affrontato all’interno dell’e-

laborato.

• Capitolo 2 Stato dell’arte: è suddiviso in due parti; nella prima è presentato

il modello attuale di MPower e le sue limitazioni. La seconda parte, invece,

è dedicata all’esposizione e al confronto con lavori presenti in letteratura.

• Capitolo 3 Metodologia: è suddivisa in due parti; nella prima fornisce una

definizione formale del problema che vogliamo risolvere; nella seconda si

definisce la metodologia formale adottata per risolvere il problema prece-

dentemente esposto.

xii Abbreviazioni

• Capitolo 4 Implementazione: fornisce una prima descrizione sulla struttu-

ra del codice e la sua organizzazione e successivamente descrive, attraver-

so uno pseudo-codice, come l’approccio precedentemente descritto è stato

implementato.

• Capitolo 5 Risultati: presenta i risultati sperimentali ottenuti sia per il cal-

colo del TTL che per il calcolo del TTC e fornisce un confronto con il progetto

Volta di Android L.

• Capitolo 6 Conclusioni: presenta le conclusioni di questo lavoro insieme

ad alcuni spunti su possibili estensioni future.

Indice

1 Introduzione 1

2 Stato dell’arte 9

2.1 Consumi di potenza nei dispositivi mobili . . . . . . . . . . . . . . . 10

2.1.1 MPower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.2 Progetto Volta . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 Modellizzazione del comportamento degli utenti . . . . . . . . . . . 22

2.2.1 Studi sul comportamento degli utenti di dispositivi mobili . 23

2.2.2 Analisi del comportamento degli utenti dei dispositivi mobili 25

2.2.3 Studi sulle serie temporali . . . . . . . . . . . . . . . . . . . . 32

2.2.4 Studi sul comportamento degli utenti attraverso le catene

di Markov in contesti non legati ai dispositivi mobili . . . . 35

3 Metodologia 39

3.1 Definizione del problema . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2 Soluzione proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.3 Il modello di Markov . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.4 Tempo di carica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4 Implementazione 55

4.1 Presentazione degli algoritmi utilizzati per il calcolo del TTL . . . . 55

4.1.1 Definizione delle curve: . . . . . . . . . . . . . . . . . . . . . 56

xiii

xiv INDICE

4.1.2 Identificazione delle configurazioni: . . . . . . . . . . . . . . 58

4.1.3 Calcolo delle matrici di adiacenza: . . . . . . . . . . . . . . . 58

4.1.4 Generazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2 Tempo di scarica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.3 Presentazione degli algoritmi utilizzati per il calcolo del TTC . . . . 76

4.4 Tempo di carica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5 Risultati sperimentali 87

5.1 Valutazione del tempo di autonomia predetto . . . . . . . . . . . . . 89

5.1.1 Figure di merito . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.1.2 Base di dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.1.3 Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.1.4 Confronto tra MPower e Android Lollipop . . . . . . . . . . 103

5.2 Valutazione del tempo di carica . . . . . . . . . . . . . . . . . . . . . 104

6 Conclusioni 107

Elenco delle figure

1.1 Schermata della nuova funzionalità di Google sulla predizione del

tempo di vita del telefono (historian table) . . . . . . . . . . . . . . . 5

1.2 Schermata di MPower . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Schermate dell’applicazione MPower . . . . . . . . . . . . . . . . . 12

2.2 Rappresentazione delle macchine virtuali presenti su Meth . . . . . 14

2.3 Rappresentazione a matrice della funzionalità principali di MPower 15

2.4 Modelizzazione del modello di potenza di MPower ad alto livello . 19

3.1 flusso di dati nel processo di generazione del TTL . . . . . . . . . . 40

3.2 esempio di catena di Markov nel contesto dei MPower . . . . . . . 48

3.3 Rappresentazione di una catena di Markov del primo ordine . . . . 50

3.4 Rappresentazione di una catena di Markov del secondo ordine . . . 51

3.5 Flusso di operazioni per il calcolo del TTC . . . . . . . . . . . . . . . 53

3.6 curva di carica e rispettivi modelli . . . . . . . . . . . . . . . . . . . 54

4.1 flusso di dati nel processo di generazione del TTL . . . . . . . . . . 56

4.2 flusso di dati nel calcolo delle matrici di adiacenza . . . . . . . . . . 57

4.3 flusso di dati nel calcolo delle matrici di adiacenza . . . . . . . . . . 59

4.4 divisione delle curve di ricarica registrate . . . . . . . . . . . . . . . 77

4.5 sequenza ordinata crescente di tutte le pendenze dei modelli delle

curve di carica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.6 clusterizzazione delle pendenze . . . . . . . . . . . . . . . . . . . . . 78

xv

xvi ELENCO DELLE FIGURE

4.7 curve di carica colorate per cluster . . . . . . . . . . . . . . . . . . . 78

4.8 users divided for number of clusters . . . . . . . . . . . . . . . . . . 79

5.1 Rappresentazione dei brand più acquistati dagli utenti di MPower

(febbraio 2015) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.2 Rappresentazione dei dispositivi più acquistati dagli utenti di MPo-

wer (febbraio 2015) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.3 Rappresentazione dei sistema operativo (S.O.) presenti nei dispo-

sitivi monitorati da MPower (febbraio 2015) . . . . . . . . . . . . . . 89

5.4 Indice dei colori utilizzati nella tabella di valutazione dei risultati

ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.5 Errore quadratico medio . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.6 Errore medio puntuale . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.7 Errore quadratico medio della pendenza . . . . . . . . . . . . . . . . 100

5.8 Errore medio puntuale della pendenza . . . . . . . . . . . . . . . . . 101

5.9 Punto finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.10 Indice dei colori utilizzati nella tabella di valutazione dei risultati

ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Elenco delle tabelle

1.1 Evoluzione del tempo di vita medio dei dispositivi mobili dal 2000

ad oggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Esempio di un file Json contenente la tabella dei TTL trasmesso dal

server al dispositivo mobile. In ogni riga sono registra le informa-

zioni relative ai componenti hardware monitorati e il TTL in minuti

rimanente associato a ogni possibile percentuale di batteria (quindi

da 1% a 100%). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Confronto delle componenti hardware monitore da MPower e da

[19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1 File json prodotto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.1 Metriche utilizzate per la valutazione del TTL . . . . . . . . . . . . 91

5.2 Risultati ottenuti confrontando tutte le curve di scarica . . . . . . . 94

5.3 Risultati ottenuti confrontando le curve di scarica di lunghezza

compresa tra 0% e 30% . . . . . . . . . . . . . . . . . . . . . . . . . . 94


compresa tra 30% e 80% . . . . . . . . . . . . . . . . . . . . . . . . . 95


compresa tra 80% e 100% . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.6 Risultati ottenuti confrontando Android Lollipop e MPower . . . . 104

5.7 Figure di merito utilizzate per la valutazione del TTC . . . . . . . . 105

xvii

xviii ELENCO DELLE TABELLE

5.8 Risultati ottenuti relativi al modello del TTC . . . . . . . . . . . . . 106

Elenco degli algoritmi

4.2.1 CreaBande: algoritmo per la creazioni di fasce orarie . . . . . . . . 65

4.2.2 Adiacenza: algoritmo per il calcolo della matrice di adiacenza non

cumulativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.2.3 Produzione: algoritmo per la generazione della catena di Markov . 68

4.2.4 Somiglianza: algoritmo per il calcolo delle matrici di adiacenza . . 72

4.2.5 Algoritmo per la generazione del TTL giornaliero . . . . . . . . . . 73

4.2.6 Algoritmo per la generazione del TTL orario . . . . . . . . . . . . . 74

4.2.7 Algoritmo per la generazione del TTL dinamico . . . . . . . . . . . 75

4.4.8 Tabella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.4.9 Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.4.10Ricerca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

xix

xx ELENCO DEGLI ALGORITMI

Capitolo 1

Introduzione

Questo Capitolo introduce il problema affrontato nel presente elaborato; in

particolare inizia con una descrizione dello scenario in cui questo problema si col-

loca. Successivamente viene fornita una descrizione del punto di partenza da cui

si sviluppa la metodologia presentata nell’elaborato ovvero si presenta il modello

attuale di MPower e le sue limitazioni. Nella parte finale viene proposto il con-

fronto con Android Lollipop in quanto anch’esso presenta come sua funzionalità

nativa, una stima del tempo di autonomia residuo di un dispositivo.

Nel 2014 la diffusione dei cellulari ha raggiunto circa 4.55 miliardi di persone,

ovvero più del 63,5% della popolazione globale. Recenti studi [1] prevedono che,

entro il 2017, il numero di persone che posseggono un cellulare possa aumentare

ulteriormente fino a raggiungere il 69.4% della popolazione globale. Questo trend

positivo è fortemente legato alla nascita e alla rapida diffusione degli smartphone.

In pochissimi anni, infatti, sono riusciti a coprire più di un quarto del mercato,

ovvero a raggiungere 1,75 miliardi di utenti.

Un punto di forza di questi dispositivi sono sicuramente le numerose funzio-

nalità che facilitano la vita di tutti i giorni. Smartphone e tablet infatti possono

essere utilizzati per controllare le email, impostare promemoria, ascoltare musi-

ca, controllare il proprio account sui Social Network, segnare la lista della spesa,

oppure per scopi più tradizionali come messaggistica e chiamate.

1

2 CAPITOLO 1. INTRODUZIONE

Sfortunatamente l’evoluzione di questi dispositivi, sia in termini di funziona-

lità che di potenza di calcolo, ha portato a un aumento dei consumi energetici di

conseguenza a una significativa riduzione del loro tempo di autonomia; anche

detto TTL. Il TTL è definito come il tempo in cui possiamo effettivamente utiliz-

zare il dispositivo: in altre parole, la finestra di tempo che intercorre dall’istante

attuale al momento in cui il dispositivo sia completamente scarico. Per dare un’i-

dea più precisa della riduzione effettiva del TTL negli anni, riportiamo in Tabella

1.1 il tempo medio di autonomia dei cellulari più venduti dal 2000 ad oggi. In

tale tabella si danno i dettagli sul tempo di autonomia in stand-by, chiamata e

riproduzione video dei diversi telefonini (i dati riportati sono relativi alle schede

tecniche fornite dalle case produttrici [2], [3], [4]).

Come si può notare dai dati presenti in Tabella 1.1, i tempi di stand-by e

chiamata sono rimasti fondamentalmente invariati. Ciò nonostante, a causa dei

cambiamenti nelle modalità di utilizzo primario degli smartphone, il tempo di

autonomia reale di una batteria durante l’utilizzo quotidiano è notevolmente ri-

dotto [5]. Basti pensare che, secondo l’esperienza comune, il TTL percepito di

uno smartphone si avvicina molto di più all’autonomia della riproduzione vi-

deo rispetto a quella di stand-by. In base a queste considerazioni, si può quindi

affermare che vi sia stata una riduzione del tempo di autonomia medio di uno

smartphone rispetto a un cellulare tradizione. Un’altra considerazione suggerita

dalla Tabella 1.1, è che il tempo di autonomia medio di un dispositivo è stretta-

mente legato alle modalità di utilizzo del dispositivo stesso e, di conseguenza,

alle abitudini dell’utente nella sua interazione con lo smartphone.

3

Tabella 1.1: Evoluzione del tempo di vita medio dei dispositivi mobili dal 2000 ad oggi

Anno Modello Caratteristica A. chiamata A. stand-by A. video

2000 Nokia 3310 126 milioni di pezzi 270 min 260 h -

2000 Ericsson T39 bluetooth 300 min 660 h -

2002 Nokia 3510(i) GPRS internet 260 min 270 h -

2002 Sony Ericsson P800 a touchscreen 780 min 400 h -

2002 Sanyo SCP-5300 fotocamera integrata 165 min 250 h -

2003 BlackBerry Quark 6210 integrazione phone/PDA 300 min 280 h -

2003 Nokia 7600 3G 360 min 240 h -

2004 Nokia 6630 roaming globale 240 min 180 h -

2005 HTC Universal primo Windows phone 300 min 200 h -

2006 O2 XDA Flame dual processor PDA/phone 300 min 200 h -

2008 iPhone 3G smartphone 300 min 300 h 10 h

2008 Nokia 5800 XpressMusic smartphone 500 min 400 h 5.2 h

2010 iPhone 4 smartphone 400 min 300 h -

2011 HTC Evo 4G smartphone 240 min 150 h -

2012 Galaxy S3 smartphone 660 min 750 h -

2014 iPhone 6 smartphone 840 min 250 h 11 h


Per poter utilizzare il proprio dispositivo mobile per ogni necessità è indispen-

sabile conoscere il tempo reale di autonomia del dispositivo. Questa informazione

può essere ricavata utilizzando un modello, in particolare un modello di potenza.

Lo scopo di un modello è quello di rappresentare il più sinteticamente possibile

un determinato oggetto, un fenomeno reale o un insieme di fenomeni. Un model-

lo matematico è un particolare tipo di modello, spesso costruito con l’intento di

fornire previsioni sullo ’stato’ futuro di un fenomeno o di un sistema. Un modello

di potenza è un particolare modello matematico che permette di fare previsioni

sullo stato futuro della potenza utilizzata in un determinato intervallo di tem-

po e, di conseguenza, sul suo consumo energetico. Nel nostro caso tale sistema è

rappresentato da un dispositivo mobile e conoscere il suo consumo energetico ci

permette di calcolare il TTL.

In letteratura, come trattato più ampiamente nel Capitolo 2, sono stati propo-

sti numerosi modelli di potenza nel tentativo di modellizzare, sempre con mag-

gior precisione, il consumo di batteria in tablet e smartphone. Quello che si è no-

tato è che tali modelli dipendono dai dispositivi considerati, i quali differiscono

sia in termini di componenti hardware che di batteria utilizzata, e dalle abitudini

dell’utente. Non è quindi possibile creare un modello di potenza unico e generale

che garantisca una buona approssimazione del TTL.

Ai diversi studi teorici è seguita la nascita di numerose applicazioni in grado

di monitorare il consumo della batteria nei dispositivi mobili; tra le più diffuse

troviamo Snapdragon BatteryGuru [6], Battery Doctor (Battery Saver) [7], Rispar-

mio Batteria Saver [8] e molte altre. Queste applicazioni, in pochi anni, hanno

raggiunto circa 500 milioni di utenti. Questa diffusione è motivata dal reale bi-

sogno da parte dell’utente di conoscere l’autonomia del proprio dispositivo e di

gestirne e ottimizzarne i consumi.

I temi legati al consumo energetico nei dispositivi sono quindi diventati aspet-

ti fondamentali negli smartphone di ultima generazione. Proprio per l’importan-

za di questi argomenti, anche Google, ha deciso di occuparsi di questo problema

5

con il progetto Volta, che ha poi integrato nella sua ultima release di Android

chiamata Lollipop (rilasciata il 3 novembre 2014). Il team di Google ha deciso di

affrontare il problema della stima dell’autonomia della batteria attraverso due

funzionalità distinte. La prima, denominata Battery Saver, ha il compito di disa-

bilitare le funzionalità più costose del dispositivo in termini di batteria, ad esem-

pio di passare da wi-fi a 3G nel caso il wi-fi non sia utilizzabile, oppure riducendo

il carico della CPU o la luminosità dello schermo. Dichiarazioni ufficiali riporta-

no che questi accorgimenti portino a 90 minuti aggiuntivi di effettivo utilizzo del

dispositivo [9].

Figura 1.1: Schermata della nuova funzionalità di Google sulla predizione del tempo di vita del

telefono (historian table)


La seconda funzionalità introdotta da Google è la historian table (Figure 1.1).

Questa funzionalità presenta all’utente due informazioni molto interessanti: il

tempo di autonomia rimasto al proprio dispositivo e un elenco delle componenti

software che hanno contribuito al consumo di batteria.

Anche il Politecnico di Milano e più in particolare il laboratorio di architetture

dei calcolatori NECST ha sentito la necessità di affrontare il tema della gestione

della potenza nei dispositivi mobili. Per questa ragione, nel 2012 [10], ha iniziato

il progetto MPower e la rispettiva applicazione scaricabile da Google Play Store

[11]. La funzionalità principe di MPower, come si può vedere in Figura 1.2, è quel-

la di informare l’utente del TTL e del TTC del proprio dispositivo, dove il TTC è il

tempo necessario per caricare completamente il proprio dispositivo ed è uno dei

contributi di questa tesi. Si ritiene infatti, che queste informazioni, siano essenziali

Figura 1.2: Schermata di MPower

per aiutare l’utente a gestire il proprio dispositivo in modo da soddisfare i propri

bisogni. Per esempio, poniamo il caso che un utente stia aspettando una chiama-

7

ta importante ma che il suo smartphone abbia solo il 15% di autonomia rimasta.

MPower, rende possibile effettuare una conversione della percentuale di batteria

rimasta in minuti di effettivo utilizzo. In questo modo l’utente, verrà informato

che ad esempio al 15% della batteria corrisponde un autonomia di 30 minuti di

vita dello smartphone. Se questo tempo non fosse sufficiente per garantire la ri-

cezione della chiamata, l’utente può decidere di ricaricare il proprio dispositivo.

MPower lo informa anche del tempo necessario per caricarlo; questa informazio-

ne risulta utile ad esempio nel caso in cui l’utente debba uscire in pochi minuti di

casa, in questo caso infatti potrebbe decidere di portarsi una batteria esterna, che

gli permetterebbe di caricare comodamente il proprio cellulare nella borsa.

MPower fornisce anche delle funzionalità che supportano la gestione dei con-

sumi energetici, in particolare, propone una comoda e intuitiva interfaccia utente

che gli/le permette di cambiare le impostazioni del proprio dispositivo, ad esem-

pio gps, wi-fi, . . . , per aumentarne il tempo di autonomia. L’efficacia di queste

modifiche è misurata da MPower in quanto il modello attuale è calcolato attra-

verso l’analisi di queste componenti hardware e dal tipo di rete rilevata dal di-

spositivo ad esempio edge o gprs. Tornando all’esempio precedente, se l’utente

non avesse a disposizione un carica batterie esterno e se il TTL non fosse suffi-

ciente per garantire la ricezione della chiamata, MPower fornisce informazioni

su come cambierebbe il TTL nel caso l’utente decidesse di modificare il proprio

comportamento, ad esempio spegnendo il wi-fi.

Il presente elaborato si pone l’obiettivo di migliorare la predizione del TTL

effettuata da MPower tenendo in considerazione i comportamenti dell’utente.

Riteniamo infatti che, studiare il comportamento dell’utente, possa portare un

significativo miglioramento anche nella previsione del TTL effettuata da MPower.

In particolare si cercherà di migliorare il modello di potenza alla base di MPo-

wer eliminando una delle assunzioni su cui si basa. Tale assunzione è legata al

fatto che si ipotizza che le componenti controllabili sopra citate restino costanti

durante il tempo di utilizzo effettivo del dispositivo, ovvero per tutto il tempo


che trascorre tra una ricarica e l’altra.

I contributi di questo elaborato al modello attuale di MPower sono quindi i

seguenti:

• adozione di un modello che tenga in considerazione le abitudini dell’utente

e che quindi vari le predizioni con esse. Questo ha permesso di ridurre l’im-

precisione del modello dovuta alla seconda limitazione del modello attuale.

Tra le diverse opzioni disponibili è stato deciso di sfruttare un modello già

ampiamente utilizzato in numerosissimi campi (ad esempio il page rank di

Google [12]), per predire il comportamento degli utenti: le catene di Mar-

kov. Per una descrizione più dettagliata del modello si rimanda al Capitolo

3.

• introduzione di modello di potenza relativo al TTC. Questa informazione è

infatti necessaria per fornire all’utente una visione completa per la gestione

energetica del proprio dispositivo.

Un’ultima importante considerazione è che il modello proposto non è un’alter-

nativa a quello esistente ma una sua estensione. La modellizzazione dell’utente

tramite le catene di Markov permette infatti di predire un insieme di passi che

probabilmente l’utente compirà, ma sarà poi compito del modello attuale deter-

minare la percentuale di batteria consumata ad ogni passo. I risultati legati all’a-

dozione di questa metodologia, presentati nella Sezione 5, mostrano chiaramente

che la scelta di considerare il comportamento dell’utente per il calcolo del TTL

porta a miglioramenti considerevoli rispetto al modello attuale.

Capitolo 2

Stato dell’arte

Studiare il comportamento delle persone per capirne le abitudini e farne pre-

visioni è un campo di ricerca attualmente in espansione. Esistono, infatti, nume-

rosissimi contesti applicativi in cui riuscire a prevedere il comportamento delle

persone potrebbe portare a reali vantaggi, anche economici nel caso delle aziende

e nella vita di tutti i giorni. Per meglio comprendere quanto detto, si consideri

l’esempio di visitatori di musei e mostre [13], [14], [15]. Se i gestori di un museo

fossero in grado di prevedere gli interessi del pubblico rispetto all’allestimento di

una mostra, essi potrebbero ottimizzare i propri profitti predisponendo percorsi

più interessanti che richiamerebbero un numero molto maggiore di persone por-

tando quindi un maggiore guadagno. Anche nell’ambito dei dispositivi mobili la

possibilità di predire il comportamento dell’utente suscita un forte interesse. In

questo caso, il vantaggio originato da una precisa predizione del comportamento

degli utenti potrebbe essere tradotto in termini di miglioramento della user expe-

rience. Si potrebbe, infatti, pensare di forzare il dispositivo a comportamenti che

facilitino l’utente, per esempio precaricando le notizie prima di colazione [16] op-

pure, come nel nostro caso, fornendo una stima sul tempo di autonomia residuo

del dispositivo.

Per dare una visione più precisa di dei concetti appena accennati si è deciso

di organizzare il presente capitolo nel seguente modo:

9

10 CAPITOLO 2. STATO DELL’ARTE

• Sottosezione 2.1: presentazione di due modelli di potenza nel contesto dei

consumi energetici in ambito mobile: MPower e Lollipop.

• Sottosezione 2.2: presentazione di alcuni studi sulla modellizzazione del

comportamento dell’utente nell’ambito dei dispositivi mobili e in altri sce-

nari.

2.1 Consumi di potenza nei dispositivi mobili

In questa Sezione andiamo a presentare due progetti il cui obiettivo è quello

di analizzare i consumi di potenza nei dispositivi mobili. Questa analisi viene

effettuata in entrambi i casi attraverso l’utilizzo di un modello di potenza, ovvero

un particolare modello matematico il cui scopo è quello di definire e predire i

consumi energetici nei cellulari.

Poter gestire i consumi energetici dei propri dispositivi mobili, quali cellulari

e tablet, ha assunto particolare importanza proprio in questa ultima decade in

quanto si è registrata una grande diffusione di questi ultimi. Per questo motivo

il Politecnico di Milano ha iniziato ad occuparsi di questa tematica attraverso il

progetto MPower; anche Google nell’ultimo anno ha lavorato a questa tematica

con il progetto Volta.

Strutturiamo la presente Sezione nel seguente modo:

• Sottosezione 2.1.1: MPower, ovvero il progetto alla base di questa tesi. Si

fornirà sia una descrizione accurata dell’architettura che del modello di

potenza attualmente utilizzato.

• Sottosezione 2.1.2: il progetto Volta, ovvero il progetto intrapreso da Google

al fine di creare un modello di potenza all’interno del S.O. Android.

2.1. CONSUMI DI POTENZA NEI DISPOSITIVI MOBILI 11

2.1.1 MPower

Lo scopo di MPower [17] è quello di calcolare il tempo di autonomia di un

dispositivo mobile e di mostrare all’utente tale informazione. Il sistema operativo

scelto per sviluppare questa applicazione è Android, soprattutto per la sua ampia

diffusione.

Il sistema si compone in due parti:

• Applicazione Android: lo scopo dell’applicazione è quello di raccogliere le

informazioni utili per il calcolo del TTL e del TTC e di visualizzare all’utente

i tempi calcolati. L’applicazione è stata costruita in modo da salvaguardare

la batteria del telefono, mantenendo l’impatto sul consumo della batteria al

minimo.

• Server di calcolo: lo scopo di questo componente è quello di predire il TTL

di ogni singolo utente/dispositivo basandosi sul calcolo di un modello di

potenza. Una volta che i parametri del modello sono stati calcolati è possi-

bile ottenere il TTL corrispondente facendo generare al modello una curva

di scarica dal livello attuale di batteria fino al suo esaurimento. Il tempo

corrispondente a tale curva di scarica coincide con il TTL stimato.

Infrastruttura

Applicazione L’idea alla base di MPower, un sistema capace di gestire la poten-

za di dispositivi mobili, fu presentata per la prima volta nel 2012 [10]. Con tale

lavoro si proponeva di studiare i comportamenti dell’utente al fine di aiutarlo

nella gestione del consumo energetico del proprio dispositivo mobile. A livello

implementativo, l’idea è stata sviluppata in due parti: da un lato si ha un’appli-

cazione capace di monitorare l’utente ed estrarre le informazioni necessarie per

le future analisi mentre dall’altro un server remoto sul quale salvare tutti i dati

raccolti dall’utente effettua il calcolo del modello di potenza vero e proprio.


(a) Schermata di login (b) Fase di apprendimento

(c) Rappresentazione del

TTL

(d) Impostazione del TTL

necessario

(e) Impostazione delle pre-

ferenze durante la ricerca

(f) Visualizzazione dei mo-

delli disponibili

Figura 2.1: Schermate dell’applicazione MPower


Le principali operazioni svolte dall’applicazione sono visibili in Figura 2.1. La

scelta di riportare le schermate relative a ciascuna funzionalità è stata effettuata

per dare un’idea più precisa al lettore dell’organizzazione vera e propria dell’ap-

plicazione. Si vogliono ora descrivere separatamente le operazioni che è possibile

svolgere all’interno dell’applicazione:

a. La prima operazione che incontriamo è quella di registrazione. Una volta

effettuata questa operazione l’utente sarà associato ad un ID univoco.

b. MPower inizia a raccogliere i dati necessari al calcolo del modello. Sono

necessari alcuni giorni di apprendimento per calcolare il modello personale

dell’utente.

c. Raccolta una quantità minima di dati, questi vengono passati al server Me-

th, sul quale vengono memorizzati e utilizzati per il calcolo del modello

di potenza. Appena il numero di dati raccolti dal server raggiungerà una

quantità minima necessaria a calcolare il modello esso verrà ritrasmesso

all’applicazione e il TTL potrà essere visualizzato.

d. Il server compie il calcolo di diversi modelli di potenza, uno per ogni pos-

sibile configurazione di variabili di input disponibili. Con il termine confi-

gurazione si intende l’insieme delle variabili osservate sul dispositivo quali

CPU, Wi-fi, bluetooth ed altre. Questi modelli sono necessari in quanto in

questa versione di MPower non si tiene conto delle abitudini dell’utente, ma

si ipotizza che una volta impostata una configurazione l’utente non la cambi

fino a completa scarica del dispositivo. Risulta quindi necessario calcolare

un modello per ogni possibile impostazione scelta dall’utente. Poiché tutti

questi modelli sono disponibili contemporaneamente sul dispositivo mobi-

le è possibile per l’utente effettuare la ricerca di un altro modello sulla base

delle sue esigenze energetiche. Tramite una slidebar può infatti indicare il

TTL che vorrebbe raggiungere con il proprio dispositivo mobile.


e. Durante la fase di ricerca è possibile impostare alcuni filtri per selezionare i

risultati tenendo conto delle funzionalità che l’utente ritiene necessarie.

f. Una volta individuati tutti i modelli che soddisfano le richieste di tempo

e di configurazione impostate dall’utente, si visualizzano le configurazio-

ni disponibili. L’utente può quindi cambiare configurazione semplicemente

selezionando quella che più si avvicina alle sue esigenze.

Per ragioni di scalabilità rispetto al numero degli utenti si è scelto di svilup-

pare l’architettura del server in un ambiente cloud di cui si vuole ora fornire una

descrizione più accurata.

Figura 2.2: Rappresentazione delle macchine virtuali presenti su Meth

Server host L’architettura del server host è rappresentata in Figura 2.2. Come si

può vedere è presente un unico server sul quale sono state istallate tre macchine

virtuali (VM). Questa scelta di design è stata effettuata per garantire la scalabi-

lità del sistema al crescere del numero di utenti che lo utilizzano e quindi alla

dimensione dei dati memorizzati e processati. Le singole VM che compongono il

sistema sono:

• Web server: il suo compito è quello di interfacciarsi con le applicazioni e i

database. Da una parte, infatti, riceve i file di dati raccolti dall’applicazio-


Figura 2.3: Rappresentazione a matrice della funzionalità principali di MPower

ne da analizzare e li trasmette al database, dall’altra trasmette dei file Json

contenenti i TTL del device all’applicazione.

• Database server: è un database relazionale il cui compito è quello di imma-

gazzinare tutti i dati raccolti sugli utenti registrati ad MPower. Attualmente

si è scelto di utilizzare MySQL Server (version 5.5.31). Il database Server

non è in grado di comunicare con il mondo esterno, può invece comunicare

con la rete di server che costituisce il sistema.

• Data crunching Server: è la VM incaricata di calcolare i TTL degli uten-

ti. I linguaggi utilizzati su questa macchina sono quelli propri del calcolo

scientifico, cioè Numpy e Octave. Il server, con una cadenza giornaliera, ri-

chiede i dati necessari per il calcolo del TTL al database server e, una volta

ottenuti i dati, ricalcola il modello di potenza per ogni utente e ritrasmet-

te i risultati al database server in modo che questi siano pronti per essere

ritrasmessi all’utente. La scelta implementativa fatta prevede di effettuare

il calcolo quotidianamente per garantire un livello di accuratezza elevato.

Anche in questo caso, il data crunching server può comunicare solo con la

rete di macchine che costituisce l’applicazione e non con il mondo esterno.


Componenti principali Una prima descrizione ad alto livello dei componenti

software è rappresentata in Figura 2.3. Come si può facilmente vedere esistono

due chiavi di lettura distinte che permettono di effettuare raggruppamenti diffe-

renti degli stessi componenti. Effettuando una lettura verticale, infatti, essi ven-

gono raggruppati per funzionalità. In particolare possono essere distinte quattro

macroaree:

• Osservazione ed analisi del sistema: si occupa di accedere alle informa-

zioni importanti per l’analisi con una frequenza prestabilita. Per facilitare

questo compito si appoggia a una serie di librerie dette Sense Libraries, le

quali permettono di evitare una continua verifica da parte dell’applicazio-

ne alle API Android, a meno che le impostazioni del dispositivo siano state

modificate.

• Comunicazione e Sicurezza: per garantire la sicurezza del dispositivo si

è scelto di implementare un protocollo di crittografia a chiave simmetrica.

La chiave del dispositivo viene generata e consegnata durante la fase di

registrazione e sarà poi richiesta in tutte le comunicazioni successive con il

server.

• Modello di Potenza: come già precedentemente descritto, il modello di po-

tenza calcola il TTL del dispositivo per ogni possibile configurazione e salva

tale risultato in un file Json. Un esempio del contenuto di tale file è ripor-

tato nella Tabella 2.1. La presenza di diverse configurazioni è necessaria

in quanto l’applicazione supporta l’utente nella scelta della configurazione

che meglio si conforma ai propri bisogni.

• Componenti di servizio: contiene tutti i componenti utilizzati per la gestio-

ne di eventi. Ad esempio, permette di riconoscere i componenti inutilizzati

lasciati attivi o avverte il sistema ogniqualvolta in cui questi abbia raccol-

to abbastanza dati e si siano verificate le condizioni per effettuare la tra-

smissione di tali dati al server. La trasmissione dei dati, infatti, avviene solo


Tabella 2.1: Esempio di un file Json contenente la tabella dei TTL trasmesso dal server al dispositivo

mobile. In ogni riga sono registra le informazioni relative ai componenti hardware monitorati e il

TTL in minuti rimanente associato a ogni possibile percentuale di batteria (quindi da 1% a 100%).

wifi gps screen mobile bluetooth airplane 1% 2% . . . 99% 100%

off off low on off off 4 12 . . . 987 1031

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

on on medium off off off 1 4 . . . 598 632

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

on off medium off off off 1 4 . . . 798 815

quando il telefono è in carica e non è utilizzato, in questo modo si garantisce

di non impattare sul consumo energetico del dispositivo stesso.

Effettuando una lettura orizzontale, invece, i componenti vengono raggruppati

per viste e possono essere catalogati in:

• Livello di presentazione: si occupa dell’iterazione con l’utente; più preci-

samente permette la visualizzazione del TTL.

• Livello della logica applicativa: si occupa di gestire la logica interna legata

ai servizi, agli aspetti comunicativi e alla gestione degli eventi.

• Livello hardware e di accesso ai dati: contiene un insieme di librerie che

vengono utilizzate durante la fase di monitoraggio del dispositivo per ac-

cedere alle impostazioni dell’utente.

Modello di potenza

Come si può vedere dalla Figura 2.1c, MPower fornisce due informazioni fon-

damentali ai propri utenti: il tempo necessario per caricare il proprio dispositivo,


anche detto TTC, e il TTL, ovvero il tempo necessario per far scaricare comple-

tamente il dispositivo mobile partendo dall’istante corrente. Per il TTC daremo

una descrizione dettagliata della metodologia nel Capitolo 3 in quanto è uno

dei contributi di questa tesi ad MPower. Il modello relativo al TTL verrà invece

presentato qui di seguito e ripreso nei capitoli successivi.

TTL Il calcolo del TTL, nella sua primissima versione risale a Settembre 2013,

cioè quando MPower fu rilasciato nel PlayStore di Google [17].

Questo calcolo era effettuato attraverso un ciclo di tipo Osservazione Decisio-

ne Azione (ODA), durante il quale erano necessari essenzialmente tre componen-

ti:

• Un layer di sensori che si occupasse di raccogliere le informazioni relative

a gli stati interni ed esterni del dispositivo.

• Una componente decisionale capace di adattarsi all’ambiente, e quindi ca-

pace di cambiare la propria politica per sorpassare le limitazioni presenti;

• Una componente in grado di cambiare lo stato del sistema o dell’ambiente.

Poiché difficilmente un dispositivo mobile è in grado di modificare significati-

vamente l’ambiente esterno, tutte le politiche sono incentrate sulla gestione de-

gli stati interni del dispositivo. Tali stati interni possono essere modificati dagli

utenti a livello di sistema, in altre parole gli utenti possono gestire i componen-

ti hardware del dispositivo, quali i moduli wi-fi o GPS utilizzando una comoda

interfaccia utente.

Il calcolo del modello di potenza ha come risultato due funzionalità ben di-

stinte. Da un lato fornisce all’utente l’informazione relativa al TTL, che dipende

dagli stati interni del dispositivo mentre dall’altro permette all’utente di gestire

più agevolmente la batteria del proprio dispositivo. La gestione della batteria, in-

fatti, è permessa da un’interfaccia utente molto intuitiva, la quale mostra il TTL


relativo a tutte le possibili variazioni degli stati interni del dispositivo. Gli stati in-

terni considerati sono solo quelli gestibili dall’utente; ad esempio il modulo wifi

o il modulo gps. L’interfaccia mostra quindi il TTL associato alle configurazioni e

l’utente potrà impostare la configurazione che meglio si addice ai propri bisogni,

e questa sarà automaticamente impostata.

S PP M

Figura 2.4: Modelizzazione del modello di potenza di MPower ad alto livello

Se andiamo ad analizzare più nel dettaglio il modello di potenza attuale,

schematizzato in Figura 2.4, ci accorgiamo che esistono tre fasi distinte che lo

compongono:

• Preprocessing:: in questa fase si controlla la coerenza dei dati memorizzati

dall’applicazione MPower e si estraggono le variabili necessarie per la fase

di training del modello.

• Stima del modello: in questa fase si calcolano i parametri del modello re-

gressivo alla base di MPower, in modo da minimizzare l’errore quadratico

medio.

• Simulazione: in questa fase vengono utilizzati i parametri precedentemente

calcolati per generare il TTL del dispositivo mobile.

Una descrizione più dettagliata del modello è fornita nel Capitolo 3.


2.1.2 Progetto Volta

In questa sezione andiamo a presentare il progetto Volta, ovvero il progetto

presentato da Google per il suo nuovo S.O. Android Lollipop. L’obiettivo del

progetto è quello di aumentare la durata della batteria nei dispositivi mobili.

Tra le varie funzionalità presentate di particolare importanza è l’introduzione

di una nuova API JobScheduler per la chiusura delle applicazioni di backgroud,

ovvero tutte quelle applicazioni che pur non essendo utilizzate dall’utente resta-

no attive sul dispositivo e quindi ne determinano un maggiore consumo energe-

tico. Funzionalità minore introdotta dal progetto, ma di maggiore interesse per

la nostra analisi, è il Battery Historian (B.H.), ovvero una funzionalità che, come

MPower, è in grado di predire il consumo energetico del dispositivo [18].

Google aveva già presentato degli studi sul consumo energetico nei dispositi-

vi mobili [19] possiamo supporre che lo sviluppo del B.H. si sia basato sull’analisi

precedentemente effettuata.

Prima di quest’analisi e di altri studi simili, volti cioè a creare dei gestori ener-

getici per qualsiasi tipo di dispositivo, esistevano già dei modelli di potenza co-

struiti ad hoc per particolari dispositivi mobili [11]. Tali modelli permettevano di

gestire e predire perfettamente i consumi energetici dei dispositivi per cui erano

stati creati ma erano del tutto inefficaci per tutti i dispositivi che presentavano

delle differenti componenti hardware.

Nacque quindi la necessità di creare un modello generale in grado di adattarsi

a qualunque dispositivo. Per raggiungere questo obiettivo Google ha sfruttato il

sensore di potenza già presente nella maggioranza dei dispositivi mobili per mo-

nitorare il consumo energetico delle singole componenti hardware, quali modulo

gps e wifi e ha sviluppato un’applicazione per predirne i TTL online. In Tabella

2.2 sono riportate le componenti hardware monitorate; poiché la maggior par-

te di esse coincide con quelle monitorate da MPower si è deciso di fornirne un

confronto.

Una volta collezionate abbastanza osservazioni sulle componenti hardware


Tabella 2.2: Confronto delle componenti hardware monitore da MPower e da [19]

Componente B.H. MPower

CPU ! 7

Frequenza processore ! 7

Luminosità dello schermo ! !

GPS ! !

Wifi ! !

Chiamata ! !

Airplane 7 !

Bluetooth 7 !

Rete ! !

monitorate si è utilizzato il modello regressivo a minimizzazione dell’errore qua-

dratico: P0

P2...

Pn

= β1 ∗

U0,1

U1,1...

Un,1

. . . + βm ∗

U0,m

U1,m...

Un,m

+ c (2.1)

In questa equazione, Ui,j rappresenta la variabile di sistema i allo stato j-

esimo, mentre Pj è il consumo di potenza quando tutte le variabili monitorate si

trovano allo stato j-esimo. La variabile c è invece il consumo di potenza minima

del sistema, ovvero quello registrato durante lo stato di idle.

Le variabili monitorate, come dimostrato in modo sperimentale nell’articolo

[19], sono state scelte per due motivi:

• il loro utilizzo impatta significativamente sul consumo energetico nei di-

spositivi mobili;


• possono essere considerate indipendenti tra loro e quindi i loro contribu-

ti possono essere sommati, come presentato nell’Equazione 2.1. Gli autori

di questo lavoro hanno stimato che il massimo errore introdotto da questa

supposizione è pari al 6,27% del consumo energetico totale.

2.2 Modellizzazione del comportamento degli utenti

Questa Sezione è dedicata alla presentazione della modellizzazione del com-

portamento degli utenti sia per quanto riguarda i dispositivi mobili che in al-

tri scenari, quali previsione del comportamento degli utenti all’interno dei mu-

sei. I numerosi studi incentrati sulle abitudini degli utenti hanno infatti dimo-

strato che comprendere e predire tali comportamenti può portare a significativi

miglioramenti nella vita di tutti i giorni.

Per maggior chiarezza espositiva si è deciso di organizzare la presente Sezione

nel seguente modo:

• Sottosezione 2.2.1: presenta due studi sull’analisi del comportamento degli

utenti con i loro dispositivi mobili. Tali studi sono relativi esclusivamente

all’analisi del consumo energetico nei dispositivi mobili.

• Sottosezione 2.2.2: presenta due studi sul comportamento degli utenti nei

dispositivi mobili. L’importanza di questa Sottosezione è legata alle tecni-

che di modellizzazione presentate che si pongono come alternativa a quella

sviluppata in questa tesi.

• Sottosezione 2.2.3: presenta l’utilizzo si serie temporali per lo studio del

comportamento degli utenti nei dispositivi mobili.

• Sottosezione 2.2.4: presenta l’utilizzo del modello dell’utente descritto in

questa tesi in un altro contesto di utilizzo. Si è deciso di aggiungere que-

st’ultima Sottosezione per sottolineare la generalità del modello proposto

rispetto al contesto in cui viene applicato.

2.2. MODELLIZZAZIONE DEL COMPORTAMENTO DEGLI UTENTI 23

2.2.1 Studi sul comportamento degli utenti di dispositivi mobili

In questa sezione si vogliono presentare due studi incentrati sull’analisi del

comportamento degli utenti nell’uso dei propri dispositivi mobili. Lo scopo di

tali studi è quello di provare l’esistenza di pattern legati al comportamento degli

utenti. Una volta individuati questi pattern, essi vengono utilizzati per predire il

consumo energetico e successivamente il TTL nei dispositivi mobili.

Il primo lavoro qui discusso [20], ha come focus quello di analizzare il com-

portamento degli utenti per mostrare come l’autonomia dei dispositivi non sia

legata esclusivamente ai componenti hardware, ma dipenda anche dagli utenti e

dalle loro abitudini. In particolare, questo studio si è focalizzato sulla quantità di

dati trasmessa su Internet, sulle applicazioni utilizzate e sulla tipologia delle in-

terazioni, in termini di quantità e durata ovvero quante vole al giorno interagisce

con una determinata applicazione e quanto tempo dura ogni sessione registrata

sul proprio dispositivo mobile. Dopo una prima analisi esplorativa è stata indi-

viduata, a sostegno dell’ipotesi, una differenza di uno o più ordini di grandezza

sia nella quantità di dati trasmessa quotidianamente che nei minuti quotidiani di

utilizzo del dispositivo. E’ stato quindi deciso di studiare più approfonditamente

le abitudini degli utenti nel tentativo di migliorare la loro esperienza di utilizzo.

Avendo scelto di focalizzare il modello sull’utente, rispetto che sulle componenti

hardware del dispositivo, le scelte possibili erano due: creare un modello ad per-

sonam o clusterizzare gli utenti costruendo un modello per ogni gruppo. In que-

sto caso si è deciso di esplorare la seconda possibilità, cercando quindi di trovare

gruppi omogenei di utenti in base al loro modo di utilizzare il proprio disposi-

tivo. Il punto di forza di un simile approccio è dato dalla presenza di un tempo

di training molto ridotto. Dopo qualche ora di utilizzo, infatti, l’utente viene già

associato ad un proprio profilo, a scapito però dell’accuratezza.

Lo scopo del articolo analizzato è quello di predire il tempo di autonomia dei

dispositivi mobile, sono state monitorate le attività di 255 utenti su un periodo

di tempo variabile tra le 7 e le 28 settimane. In particolare, le analisi sono state


effettuate sulle seguenti informazioni:

• interazione dell’utente con il proprio dispositivo, sia in termini di durata

che di frequenza;

• applicazioni utilizzate;

• traffico dei dati;

• percentuale di batteria.

Come conclusione del loro lavoro è stato dedotto che la classificazione degli utenti

su un numero ristretto di classi portava a un errore elevato. E’ stato però possibile

dimostrare che il consumo di energia nei dispositivi, e quindi la loro autonomia,

è fortemente legata al comportamento e alle abitudini dell’utente e che questi

aspetti devono essere tenuti in considerazione per costruire un modello di po-

tenza accurato e generale, cioè adottabile da un’ampia gamma di dispositivi, a

prescindere dalle loro caratteristiche hardware. Altro aspetto fondamentale che è

stato evidenziato è quello di utilizzare le informazioni relative ai dati del passato

per aiutarsi nella predizione. Questa scelta è motivata in quanto, nella maggior

parte degli utenti analizzati, il loro comportamento si è dimostrato essere abitudi-

nario e ripetitivo. Ai fini del lavoro di ricerca qui presentato, si ritiene che questo

articolo sia molto interessante e possa essere utilizzato a sostegno del lavoro svol-

to. Un’unica precisazione da fare riguarda componenti hardware del dispositivo

in esame, che si considerano essere una caratteristica fondamentale nel consumo

di energia e che per questo motivo devono essere considerati nella costruzione

del modello.

Il secondo studio analizzato [21] presenta un’analisi della durata di 6 mesi

effettuata su un campione di 25 utenti. Punto di forza di questo lavoro è che le

misurazioni vengono raccolte in un contesto reale di utilizzo e non in laboratorio.

Pertanto si è dovuto tenere in considerazione la presenza di rumore nei dati ed ef-

fettuare un lavoro di pulizia. Un’altra scelta effettuata in questo studio, riguarda


il fatto di focalizzare l’analisi su un solo modello, in quanto l’insieme analizzato è

molto limitato e quindi semplice. Nel caso preso in esame nel presente elaborato,

invece, considerando tutti i dispositivi che supportano il sistema operativo An-

droid, si sono dovute tenere in considerazione le caratteristiche hardware di ogni

dispositivo e non solo le differenze nel comportamento degli utenti. Per effettuare

l’analisi riportata in [21] è stata sviluppata un’applicazione capace di analizzare

e memorizzare sia le attività dell’utente che informazioni raccolte a livello di si-

stema. In MPower [11] si è deciso di implementare un’applicazione capace di

analizzare le informazioni rilevanti all’interno del dispositivo e di visualizzare il

risultato del nostro modello all’utente. La scelta di effettuare una computazione

remota è pertanto essenziale per ridurre al minimo l’impatto di MPower sul di-

spositivo e quindi non impattare sul consumo della batteria. Come modello di

potenza, sia nello studio in esame che in MPower, si è deciso di effettuare una

regressione sui dati raccolti in modo da approssimare il consumo energetico con

buona precisamente. I risultati di questo studio sottolineano che:

• il tempo di autonomia del dispositivo è una componente fondamentale per

l’utente;

• non esistono dei pattern generali che possono essere applicati indistinta-

mente su tutti gli utenti ma esistono dei pattern individuali;

• si potrebbero utilizzare modelli predittivi, ad esempio le catene di Markov,

per modellare le attività dei singoli utenti.

2.2.2 Analisi del comportamento degli utenti dei dispositivi mobili

In questa sezione andiamo a presentare due studi che si focalizzano sull’anali-

si del comportamento degli utenti. Entrambe le ricerche si basano, come nel caso

di MPower, su un applicazione installata nei dispositivi mobili per monitorare le

abitudini dell’utente e raccogliere dati. La diversità rispetto a MPower è legata

allo scopo per cui vengono raccolti tali dati e di conseguenza gli algoritmi utiliz-


zati per analizzarli. In questi casi infatti non si forniscono informazioni utili per

la gestione dei consumi di potenza nei dispositivi mobili ma si cerca di migliorare

l’esperienza di utilizzo degli stessi facilitando l’utente nelle sue attività quotidia-

ne. Un esempio è la creazione di shortcut dinamiche nella schermata principale

del cellulare al fine di poter chiamare direttamente le persone con cui si hanno

maggiori interazioni senza dover cercare il numero nella rubrica telefonica.

Le tecniche che andiamo ora ad analizzare, e che rappresentano la struttura

della presente Sottosezione sono:

• Data mining

• Variante del modello gerarchico e nascosto delle catene di Markov

Data Mining Una tecnica alternativa a quella presentata in questo lavoro, ma

comunque molto interessante per analizzare i comportamenti degli utenti con i

loro dispositivi mobile, è quella adottata in [16].

L’obiettivo dell’analisi sopra citata è quello di utilizzare tecniche del data mi-

ning nel contesto di dispositivi mobili. Più precisamente l’analisi in questione è

mirata ad estrarre una grande quantità di informazioni sulle abitudini degli uten-

ti, in modo da individuare pattern giornalieri o settimanali che possano essere

sfruttati per aumentare la soddisfazione dell’utente. Questi pattern vengono, in-

fatti, trasformati in applicazioni che possono facilitare l’utente nella sua vita di

tutti i giorni.

Aspetto interessante di design è che tutto lo sforzo computazionale, necessa-

rio per la ricerca e l’individuazione di pattern, è lasciato completamente al di-

spositivo mobile e non viene eseguito su un server remoto. Per effettuare questo

calcolo è stato sviluppato MobileMiner, un’infrastruttura general purpose capace

di individuare pattern concorrenti che si presentano con una frequenza elevata e

di indicare in quale contesto questi eventi si presentano contemporaneamente. In

questo caso con contesto si intende il periodo della giornata o della settimana in

cui si è verificato l’evento. Questa scelta è stata effettuata pensando al target di


persone su cui si è effettuata l’analisi, cioè lavoratori i cui ritmi infrasettimanali

variavano significativamente rispetto a quelli del fine settimana.

Una volta raccolta tutta questa mole di informazioni, la si può utilizzare per

estrarre regole associative [22], [23]. Definiamo regola associativa il verificarsi di un

evento in presenza di occorrenze di un altro evento; questi eventi vengono detti

rispettivamente conseguente e antecedente. Una volta individuate le regole è ne-

cessario interpretarle per estrarne informazioni utilizzabili. Questo compito può

essere eseguito da una persona, ad esempio uno sviluppatore o un analista, op-

pure da un classificatore, in modo da automatizzarne e facilitare l’analisi a scapito

dell’accuratezza.

Tutte queste considerazioni sull’analisi computazionale eseguita localmente

sono permesse da due fattori importanti: da una parte l’evoluzione tecnologica

che negli ultimi anni ha investito i dispositivi mobili, quali smartphone e tablet, e

dall’altra la struttura degli algoritmi di mining. Il risultato di tali algoritmi, infat-

ti, può essere calcolato in modo incrementale, dividendo il calcolo vero e proprio

in più giorni. Nel lavoro citato si è quindi scelto, in fase di design, di sfruttare

quest’ultima caratteristica effettuando il calcolo solo nelle ore notturne, quando

il telefono si trovava in carica e il suo livello di batteria aveva già superato l’80%.

Nel caso di MPower si potrebbe pensare di costruire il modello in maniera in-

crementale con aggiornamenti quotidiani, ma questo sarebbe senza dubbio una

scelta discutibile. Infatti, questa scelta non è attuabile nel caso analizzato nel pre-

sente elaborato per due ragioni principali. Da una parte il modello è ricalcolato

con cadenza giornaliera e, se per più giorni non si verificassero le condizioni per

cui il modello potesse essere calcolato, allora la previsione del tempo di auto-

nomia perderebbe velocemente precisione. Altra forte limitazione è la memoria

occupata sul dispositivo. Se, infatti, si lasciassero tutti i dati localmente sul dispo-

sitivo questi occuperebbero uno spazio sempre maggiore. Si è scelto di effettuare

il calcolo remotamente.

Gli aspetti principali dell’approccio adottato in questa analisi possono essere


articolati nei seguenti punti:

• MobileMiner: applicazione per l’identificazione e la memorizzazione di

pattern concorrenti;

• validazione sperimentale della fattibilità dell’approccio su un dataset di

106 utenti per una finestra temporale di 1-3 mesi.

• scoperta di un insieme di pattern comuni che possono essere usati per mi-

gliorare la user experience durante il periodo di analisi dell’utente. Alla fine

di questo periodo infatti si possono utilizzare delle regole più specifiche.

• introduzione di due scorciatoie che possono essere utilizzate per la prossi-

ma chiamata prevista in uscita e per la prossima applicazione da lanciare.

Per la creazione di un modello che permettesse di identificare pattern di even-

ti concorrenti e di effettuare operazioni di mining su di essi, questo studio si è

ispirato a un problema già ampiamente trattato in letteratura, cioè quello dei ce-

stini della spesa al supermercato [24]. Anche in questo caso, infatti, è stata estratta

una sequenza di cestini di timestamp. Con il termine cestino si intende l’insieme

degli eventi che occorrono in una particolare fascia oraria o in un particolare mo-

mento. Una volta ottenuti tutti i cestini si è potuto effettuare una ricerca delle

regole associative all’interno di ciascuno di essi. Tutte le regole identificate sono

state contrassegnate come significative nel caso in cui i loro parametri di bon-

tà superassero delle soglie predefinite. I parametri di bontà considerati erano i

seguenti:

• Supporto: rappresenta la probabilità di co-occorrenza di due eventi indi-

pendenti. Ovvero la probabilità che questi due eventi indipendenti si veri-

fichino contemporaneamente.

• Confidenza: rappresenta la probabilità condizionata di due eventi. Ovvero

la probabilità che si verifichi un particolare evento ogni qual volta se ne è

verificato un altro.


Questi parametri, come già detto, devono essere validati per ogni regola. Tale

operazione è eseguita attraverso un algoritmo pesato di mining, noto con il no-

me di WeMiT [25]. Quest’ultimo è una variante del noto algoritmo Apriori [26],

ampiamente utilizzato nel problema dei cestini della spesa a cui si è fortemente

ispirato questo lavoro.

Sebbene questo lavoro si ponga degli obiettivi differenti da quelli trattati nel

presente elaborato, esso tuttavia presenta alcuni spunti interessanti che possono

essere integrati all’interno di MPower per migliorare la soddisfazione dell’utente

attraverso una maggior precisione nella previsione sui consumi.

Variante del modello gerarchico e nascosto delle catene di Markov Per ana-

lizzare il comportamento degli utenti con i propri dispositivi mobile, può essere

usata una variante del modello gerarchico e nascosto delle catene di Markov [27].

Un possibile esempio di utilizzo di tale approccio può essere trovato in [28] per

aumentare la soddisfazione dell’utente. Il punto cardine di questo lavoro è dato

dal fatto che qui è sempre possibile conoscere e di conseguenza registrare e moni-

torare la posizione esatta e conseguentemente i movimenti di un utente. Queste

informazioni, infatti, possono essere facilmente raccolte dai dati GPS forniti dai

dispositivi mobile degli utenti e possono quindi essere utilizzate per migliorare

la qualità della vita privata e professionale degli utenti stessi.

Oggigiorno esistono numerose applicazioni che sfruttano la posizione e i mo-

vimenti degli utenti per analizzarne abitudini ed estrarre informazioni. Tra le

tante meritano di essere citate per la loro diffusione virale Moves [29] e My-

tracks [30]. Applicazioni come queste utilizzano le informazioni raccolte princi-

palmente per predire pattern sui movimenti futuri dell’utente e per identificarne

comportamenti anomali.

Per effettuare un’analisi di questo tipo è necessario adottare un modello capa-

ce di gestire un numero molto elevato di regole spazio-temporali e dipendenze

nascoste tra i dati. Queste dipendenze, infatti, sono spesso causate da una varia-


zione del contesto, come ad esempio il cambio della frequenza con cui viene ese-

guita una particolare attività o la varianza del tempo di percorrenza tra due pun-

ti specifici. Quest’ultimo fattore, ad esempio, può essere fortemente influenzato

dalle condizioni di traffico presenti, le quali, per ovvie ragioni, non dipendono

dall’utente.

Per affrontare questi problemi si sono tenuti in considerazione diversi aspetti:

• scelta di una variante del modello gerarchico delle catene di Markov na-

scoste (HHSMM) come modello. Tale modello è stato scelto in quanto in

grado di riconoscere pattern di movimento sia nel caso in cui si verifichi-

no con una elevata frequenza sia nel caso si tratti di eventi sporadici. HH-

SMM ha una duplice funzionalità: da una parte può essere utilizzato per

classificare i movimenti degli utenti, dall’altra per predire movimenti futu-

ri. Aspetto interessante di questo approccio è la possibile generalizzazione

dell’algoritmo e il suo facile adattamento in altri campi applicativi, qua-

li pianificazione urbana, identificazione dei possibili disastri e analisi sulla

migrazione degli animali. Mentre gli esempi precedenti sono legati soprat-

tutto a una classificazione del movimento, molto più interessante dal punto

di vista della ricerca effettuata in questa tesi sono invece le applicazioni

pratiche legate alla predizione dei movimenti. Un esempio in questo senso

è dato dalla predizione del movimento di un visitatore di museo, come si

vedrà nella prossima sezione.

• Valutazione delle prestazioni del modello in termini di correttezza di pre-

dizione. Ciò significa che si otterrà una percentuale di errore nulla se non

verrà sbagliato alcun passo di predizione e una predizione dell’errore mas-

sima nel caso non si riuscisse a predire correttamente nessun passo. In que-

sto studio è stato inoltre effettuato un confronto del modello utilizzato con

altri modelli spazio temporali, dimostrando l’effettivo miglioramento di

predizione ottenuto con l’uso di questo approccio.


• Testing della sensibilità del modello proposto in presenza di rumore nei

dati. Il rumore, in questo caso, è inteso sia in termini di mancanza di dati

che in termini di misurazioni errate. Entrambi questi casi, infatti, si possono

presentare nel loro contesto di utilizzo, in quanto, come nel caso presen-

tato in questa tesi utilizzano un dataset raccolto in condizioni reali e non

simulato in laboratorio.

Anche nel caso di MPower si è scelto di utilizzare una catena di Markov, ma a dif-

ferenza di questo esempio non è stato necessario utilizzarne le varianti nascoste e

gerarchiche. In questo caso la variante nascosta risulta essenziale per poter sud-

dividere ogni macro area di analisi in ambienti più piccoli e l’analisi può essere

quindi effettuata con differenti granularità. Questo è reso possibile modificando

il concetto di stato. Nel caso di catena di Markov semplice uno stato indichereb-

be una posizione, mentre in questo caso uno stato coincide con una macroarea

ed è divisibile in una serie di sottostati, ognuno corrispondente a una particolare

condizione o posizione del macro-stato. Questo ovviamente non è necessario nel

caso di MPower in quanto l’unico stato presente è la tipologia di rete, la non è

divisibile per costruzione. L’aspetto gerarchico è invece stato introdotto per sfrut-

tare la variante nascosta. In [28], infatti, l’algoritmo è stato organizzato in modo

che prima effettuasse un’analisi considerando i macro stati come unità inscindi-

bili e poi, solo se necessario, effettuasse un nuovo passo di analisi considerando,

per ogni macro stato, i suoi sottostati. Nel caso di MPower, avendo scelto di non

utilizzare una HMM, risulta superfluo utilizzare la variante gerarchica.

Lo scopo generale di questo lavoro, come di quello proposto nel presente ela-

borato, è quello di studiare i comportamenti e le abitudini degli utenti in modo

da poterli classificare e farne previsioni future. Riteniamo questa sezione molto

interessante per il nostro lavoro in quanto, sebbene cambi il contesto di utilizzo,

viene mostrato che il modello della catena di Markov possa essere utilizzato con

risultati promettenti nel campo dei dispositivi mobili.


2.2.3 Studi sulle serie temporali

L’applicazione MPower è un applicazione di log, il cui scopo è quello di mo-

nitorare e memorizzare il valore delle componenti hardware e software dei di-

spositivi mobili su cui è installata. L’insieme dei valori registrati rappresenta una

serie temporale che può essere interpretata come la traccia delle azioni compiute

dall’utente.

In letteratura sono presenti numerosi studi che utilizzano serie temporali ot-

tenute attraverso applicazioni di logging installate su dispositivi mobili per ana-

lizzare e successivamente prevedere il comportamento dell’utente; tra i più inte-

ressanti e simili al nostro caso di studio troviamo [31]. In questo articolo si pre-

senta lo sviluppo di un’applicazione in grado di prevedere le attività degli utenti

attraverso l’utilizzo dei loro cellulari.

In particolare il processo di analisi presentato si basa sull’utilizzo di due si-

stemi distinti: un cellulare e un computer. Il processo inizia con l’istallazione sul

dispositivo mobile utilizzato per l’esperimento di un’applicazione in grado di re-

gistrare i valori assunti da particolari componenti hardware del dispositivo quali

accelerometro, sensore di rete, microfono e tutto ciò che può dare informazio-

ni sull’ambiente in cui tale dispositivo si trova. Questi valori vengono succes-

sivamente inviati a un computer sul quale è installata una seconda applicazio-

ne per l’analisi dei dati raccolti; in particolare tale applicazione esegue quattro

operazioni distinte:

• Estrazione di informazioni dai dati in ingresso: in questa fase vengono cal-

colati un insieme di metriche statistiche quali media, deviazione standard

e intervallo di confidenza. Questi valori, detti caratteristici, vanno a profi-

lare il tipo di distribuzione seguito dalle serie temporali analizzate e sono

essenziali nella fase successiva.

• Classificazione dei dati: in questa fase vengono classificati i dati registra-

ti dal dispositivo mobile e inviati al computer. Esistono diverse tecniche


per effettuare la classificazione di serie temporali [32] la maggioranza delle

quali, come quella utilizzata in questo studio, si basano sul calcolo di una

funzione di costo per ogni serie temporale analizzata e alla successiva mi-

nimizzazione dei costi calcolati. Le funzioni di costo vengono normalmente

calcolate attraverso l’utilizzo di parametri statistici che, nel caso in esame,

coincidono con i valori caratteristici precedentemente valutati.

• Etichettamento delle informazioni: questa fase è l’unica non automatizza-

ta ma che necessita dell’intervento di un agente esterno. Lo scopo è quello

di associare ogni elemento riconosciuto nella fase di classificazione a un

attività dell’utente finale; per questo motivo ogni volta che la fase di clas-

sificazione identifica un nuovo andamento della serie temporale analizzata

mai registrato l’applicazione chiede all’utente di associarlo a uno stato o

attività ad esempio recarsi al lavoro o andare a correre.

• Previsione: in questa fase i dati etichettati nella fase precedente vengono

riutilizzati per prevedere le azioni future degli utenti monitorati. Per fare

ciò è necessario utilizzare un modello generativo in grado di imparare e

riprodurre le abitudini dell’utente. Tra le possibili soluzioni è stato scelto di

sviluppare questa fase attraverso le catene di Markov.

L’applicazione appena descritta è un esempio molto interessante sul tipo di

analisi che si potrebbe effettuare sugli utenti dell’applicazione MPower. Andiamo

ora a descrivere più nel dettagli come viene effettuata la classificazione.

L’algoritmo scelto per la classificazione deve garantire quattro proprietà:

• apprendimento online: la classificazione deve essere condotta senza l’in-

tervento di un agente esterno e senza un periodo di apprendimento;

• adattabilità: l’apprendimento deve essere continuo e adattarsi alla presenza

di nuovi dati senza mediare su quelli già analizzati;


• classificazione debole: le classi individuate non sono mutuamente esclusi-

ve ma presentano un valore di appartenenza che indica con che grado di

certezza l’insieme classificato appartiene a una particolare classe;

• affidabilità rispetto al rumore: quando si lavora con dati reali è sempre

presente del rumore ovvero esistono delle incoerenze nei dati analizzati do-

vute a problemi di registrazione dei dati stessi. L’algoritmo utilizzato per

l’analisi deve quindi essere in grado di filtrare il rumore.

Esistono diversi lavori in letteratura che presentano tecniche di classificazione per

serie numeriche quali [33], [34], [35] e numerosi altri. Riteniamo particolarmente

significativa per la classificazione di serie temporali l’analisi [36] che andiamo ora

a presentare.

Anche qui lo scopo dello studio è quello di effettuare il riconoscimento delle

abitudini degli utenti di dispositivi mobili attraverso un analisi dei valori assunti

dalle componenti hardware dei dispositivi stessi, quali sensori di accelerazione,

luminosità e umidità. Dopo una prima fase di raccoglimento dati, le serie tem-

porali vengono analizzate con l’obiettivo di individuare degli intervalli di valori

tali per cui i dati al loro interno siano omogenei e non ci sia sovrapposizione tra

un intervallo e un altro. I segmenti individuati vengono classificati con particolari

azioni dell’utente o particolari luoghi di utilizzo del dispositivo quali per esempio

scendere le scale o lavorare in ufficio.

La classificazione o segmentazione dei dati viene effettuata in due fasi: de-

finizione delle funzioni di costo delle serie temporali e successiva applicazione

di un algoritmo per la divisione in classi delle serie temporali volto a minimiz-

zare le funzioni di costo precedentemente identificate. In questo lavoro vengono

presentate due funzioni di costo distinte:

• funzione di costo per il singolo insieme di dati identificato: per ogni insie-

me di dati viene calcolato il valore medio. La funzione di costo si definisce

quindi come somma delle distanze di ogni singolo punto dell’insieme dal

valore medio calcolato ovvero come somma delle varianze dell’insieme;


• funzione di costo per l’intera serie numerica: ogni serie numerica è com-

posta da una sequenza di intervalli di valori, ognuno dei quali è associato a

un costo. Il costo della serie temporale viene quindi definito come il rappor-

to tra la somma dei costi degli insiemi che la compongono e la cardinalità

di tali insiemi.

Definita la funzione di costo, esistono diversi algoritmi per individuare la seg-

mentazione migliore; tra gli algoritmi esatti troviamo la programmazione dina-

mica [37] mentre tra gli algoritmi greedy troviamo ad esempio l’approccio top-

down [38]. La necessità di applicare un algoritmo greedy al posto di un algoritmo

esatto nasce dalla crescente complessità di quest’ultimo la quale cresce in modo

quadratico rispetto al numero di dati disponibili. Lo studio si conclude con un

confronto tra le diverse varianti della tecnica greedy presentata.

2.2.4 Studi sul comportamento degli utenti attraverso le catene di Mar-

kov in contesti non legati ai dispositivi mobili

In questa Sezione si vuole presentare un caso di studio interessante, in cui

il modello markoviano viene utilizzato per analizzare e predire i comportamen-

ti dell’utente in uno scenario di utilizzo completamente differente da quello dei

dispositivi mobili. Si ritiene che questa Sezione sia particolarmente importante

perché sottolinea la generalità dell’approccio seguito nel caso di MPower rispet-

to allo scenario di utilizzo. In particolare si analizzerà qui il comportamento dei

visitatori di musei e mostre, un problema ampiamente trattato in letteratura [13],

[14], [15].

Prevedere i comportamenti dei visitatori nei musei in termini di scelta di mo-

stre da visitare ha un duplice aspetto: se da una parte è estremamente difficile,

specialmente perché in molti casi i visitatori si recano in un museo una sola vol-

ta nella loro vita, dall’altra è fondamentale per aumentare gli incassi di musei e

gallerie.


A differenza del caso applicativo trattato in questo elaborato, in cui l’osserva-

zione dell’utente viene effettuata in maniera non intrusiva dall’applicazione, in

questo caso è molto più complesso tracciare le attività dell’utente in modo che

questi non se ne accorga. Una possibile soluzione potrebbe essere utilizzare una

tecnologia RFID, che permette di collezionare informazioni a basso costo.

Una volta memorizzati, i dati possono essere utilizzati per calcolare le com-

ponenti che definiscono la catena di Markov 〈S,A, λ〉. La catena di Markov è un

modello generativo che predice ad ongni passo dell’algoritmo un nuovo stato in-

dipendentemente dalla storia passata, può essere inoltre utilizzato anche a scopo

predittivo per simulare il fenomeno fisico che si sta studiando. In particolare i

parametri del modello rappresentano:

• S rappresenta l’insieme delle esposizioni disponibili nel museo. Più in ge-

nerale questo parametro potrebbe coincidere con le sale del museo, come

nel caso in cui una esposizione sia sviluppata su più sale.

• A rappresenta la possibilità di spostarsi da un’esposizione all’altra. A diffe-

renza del caso applicativo considerato in questo elaborato, in cui l’utente ha

possibilità di cambiare le impostazioni del proprio telefono in maniera del

tutto autonoma, avendo quindi una potenziale matrice delle adiacenze con

tutte le celle non nulle, in questo caso bisogna considerare che il visitatore

potrà spostarsi solo in sale adiacenti e quindi la matrice della adiacenze sarà

nulla nella maggior parte delle sue celle. Questa semplificazione porta quin-

di a una scelta più limitata sul passo di predizione successivo che compirà

il visitatore. Ultima osservazione è che, proprio per garantire la completa

arbitrarietà della scelta all’utente, è necessario, come già sottolineato prece-

dentemente, che il metodo di raccolta dati, cioè di supervisione delle stanze

visitate, sia non intrusivo.

• λ rappresenta la stanza corrente da cui il visitatore inizia il suo percorso.

In questo caso esistono due possibilità: considerare l’ingresso del museo


come stato iniziale fisso oppure escludere l’ingresso dall’insieme degli stati.

Questa seconda soluzione è molto più interessante in quanto, come nel caso

di MPower, lascia al visitatore la completa libertà di scelta sull’esposizione

da cui partire. Tale scelta, infatti, avrà come unico limite la distribuzione

fisica delle stanze.

La valutazione di questo modello, presentato in [13], [14], [15], mostra che è ef-

fettivamente possibile predire una sequenza di passi, o più precisamente una se-

quenza di stanze, in cui il visitatore si dirigerà. La precisione con cui è possibile

fare questa previsione varia tra il 60% e il 70%.

L’ultimo aspetto importante da sottolineare in questa sezione è la classificazio-

ne degli utenti. E’ infatti possibile raggruppare gli utenti in un numero limitato

di classi a seconda delle loro abitudini. A tal proposito esistono numerosi algo-

ritmi quali k-means e neural network, che possono essere utilizzati per effettuare

la clustering. Nel contesto di musei e gallerie sono stati individuate quattro cate-

gorie di visitatori: il pesce, la farfalla, la cavalletta e la formica. I nomi di queste

classi sono stati scelti per rispecchiare le peculiarità dei comportamenti dei vi-

sitatori stessi. Ad esempio, i visitatori classificati come farfalle sono quelli che

tenteranno di vedere tutte le esposizioni presenti nel museo. Per evidenti limiti

di tempo potranno però fermarsi in ogni postazione solo alcuni minuti e di con-

seguenza assorbire solo i contenuti principali ignorando i dettagli. Considerando

queste classi per il processo di classificazione, allora l’accuratezza degli algoritmi

dipenderà soprattutto dalle caratteristiche della classe considerata. Sempre facen-

do riferimento all’esempio sopracitato vengono infatti riconosciuti tutti gli utenti

di tipo farfalla che cercano di visitare tutta la mastra nel minor tempo possibile,

ma difficilmente si riescono ad individuare quelli di tipo pesce ovvero quei visi-

tatori che vanno girano per tutta la mostra ma si soffermano sui particolari che

ritengono più interessanti.

Una volta effettuata la classificazione è quindi possibile sviluppare un mo-

dello di predizione generale per ogni classe. Questa scelta permette di avere un


insieme di dati maggiore su cui effettuare l’analisi e di conseguenza un accura-

tezza più elevata rispetto al calcolo di un modello per utente. Riduce inoltre lo

sforzo computazionale a soli quattro modelli. Nel caso di MPower, però, difficil-

mente si riesce a classificare un utente. E’ infatti possibile che un utente cambi le

proprie abitudini nel tempo e inoltre il livello di consumo della batteria dipende

strettamente dal modello, e di conseguenza dalle caratteristiche dell’hardware,

dello smartphone o del tablet su cui si effettua l’analisi. Quindi per MPower un

modello generale, ovvero un modello adattabile a una particolare classe di utenti

potrebbe essere utile per sostituire il modello personale nella prima fase di analisi,

ovvero mentre si raccolgono dati per calcolare i parametri del modello. Una volta

ottenuti i parametri il modello personale ha delle prestazioni migliori rispetto al

modello per classe ed è per questo che lo andrebbe a sostituire. Il modello per-

sonale non è applicabile nel caso di musei in quanto un visitatore difficilmente

ritorna a visitare un museo due o più volte; questo rende impossibile il calco-

lo di un modello personale e di conseguenza rende obbligatorio l’utilizzo di un

modello per classe.

Capitolo 3

Metodologia

Prima di descrivere la metodologia presentata in questo elaborato, il presente

Capitolo inizia descrivendo i problemi affrontati nella tesi:

• Introduzione del comportamento dell’utente nel modello: questa necessi-

tà nasce dal fatto che il modello attuale di MPower effettua un analisi sui

dati senza considerare possibili variazioni nei consumi energetici dei di-

spositivi mobili legate all’utilizzo del dispositivo da parte dell’utente. Rite-

niamo quindi che l’introduzione di questa componente nell’analisi del TTL

possa portare un contributo significativo nella precisione del modello.

• Introduzione del concetto di TTC: questa informazione viene aggiunta al

modello attuale in quanto serve a supportare l’utente nella gestione dei

consumi energetici del proprio dispositivo mobile.

Una volta fornita una visione dei problemi affrontati si passerà alla descrizio-

ne formale della metodologia scelta. Si darà inoltre una spiegazione su come la

metodologia descritta venga realmente applicata durante il calcolo del TTL.

Il capitolo sarà quindi organizzato come segue:

• Sezione 3.1: definizione formale del modello attualmente in uso e descri-

zione dei problemi affrontati in questa tesi.

39

40 CAPITOLO 3. METODOLOGIA

PPPPPP

+

Figura 3.1: flusso di dati nel processo di generazione del TTL

• Sezione 3.2: applicazione al caso di studio in esame della metodologia adot-

tata.

• Sezione 3.3: definizione formale del modello basato sulla catene di Markov

•• Sezione 3.4: presentazione dello studio effettuato per il calcolo del tempo

di carica.

3.1 Definizione del problema

L’applicazione MPower nasce con lo scopo di aiutare l’utente nella gestione

del consumo energetico dei propri dispositivi quali smartphone e tablet. Per rag-

giungere questo obiettivo si è sviluppato un modello di potenza che andasse a

modellare tali consumi. Il modello di potenza ideato, schematizzato in Figura 3.1

si sviluppa in quattro macrofasi:

1. preprocessing: fase di pulizia dei dati che si divide a sua volta in PrePro-

cessing (P.P.)

3.1. DEFINIZIONE DEL PROBLEMA 41

2. stima del modello lineare: fase di modellizzazione dei dati attualmente uti-

lizzata che si divide a sua volta in Batch Identification (B.I.), Batch Manipu-

lation (B.M.) e stima del Stima del Modello Lineare (S.M.L.)

3. profilazione utente: il compito di questa fase, detta User Profile (U.P.), è

quello di creare un modello del TTL tenendo in considerazione il compor-

tamento dell’utente.

4. simulazione: in questa fase, detta di Simulation (S), la fase U.P. utilizza i

risultati calcolati da S.M.L. per effettuare il calcolo del TTL vero e proprio.

I moduli che costituiscono il modello attuale di potenza sono quelli relativi al-

la pulizia dei dati e al modello lineare; il modulo di U.P. è invece introdotto in

questa tesi al fine di eliminare le ipotesi restrittive, presentate nel Capitolo 2, e le

approssimazioni presenti nel modulo relativo al modello lineare.

Andiamo ora ad analizzare più nel dettaglio le fasi dei moduli attualmente

presenti in Mpower. Questo ci permette, successivamente, di valutare le proble-

matiche presenti nel modello attuale. Una descrizione dettagliata dei moduli di

U.P. e S sarà invece fornita nella Sezione 3.2.

Prima di descriverle è però necessario fornire alcune definizioni in modo da

chiarire la terminologia utilizzata nel presente Capitolo.

Variabile: caratteristica singola del sistema osservato, quale luminosità

dello schermo, modulo wifi, ecc.

Sample: valore assunto dalle variabili considerate in un particolare istan-

te di tempo, cioè l’insieme delle variabili che presentano il medesimo time-

stamp

Sequenza: insieme di sample ordinati per timestamp crescenti

Configurazione: sottoinsieme di variabili appartenenti ad un sample,

che comprende tutte e sole le variabili di decisione per il modello quali modulo

bluetooth, airplane, ...


Preprocessing: qualunque modifica dei dati legata all’ambiente. Cor-

risponde cioè all’operazione di modificare i valori delle variabili analizzate

quando questi non possano presentarsi durante l’utilizzo reale del dispositivo

mobili su cui sono stati campionati.

P.P. La fase P.P. è suddivisa in quattro operazioni eseguite sequenzialmente. In

particolare prenderà in ingresso tutti i sample registrati nel periodo di osserva-

zione del dispositivo e li restituirà dopo aver eliminato le inconsistenze; poiché le

operazioni effettuate considerando i singoli sample devono essere svolte in paral-

lelo; abbiamo quindi che le operazioni devono seguire un ordine sequenziale ma

possono essere ottimizzate parallelizzando la singola operazione. Le operazioni

eseguite in questa fase sono:

• Mascheramento outlier: tutti i sample che presentano un valore non regi-

strabile per una variabile vengono scartati in modo da non influenzare la

fase di training eseguita nel modulo relativo al modello lineare. Ogni varia-

bile ha infatti un bit, detto di mascheramento, posto di default a 0; quando

la variabile viene mascherata questo bit viene portato a 1 così che è possibile

distinguere le variabili utilizzabili nelle operazioni successive. Ad esempio

quando le informazioni sulla luminosità dello schermo non sono disponibili

viene memorizzato il valore -1 che però non ha alcun significato reale.

• Controllo della coerenza: si controlla la coerenza del valore delle variabili

e si modificano i sample le cui variabili non presentano dei comportamenti

osservabili in un contesto reale in modo da ricondurli a comportamenti re-

gistrabili. Tali anomalie sono, ad esempio, legate a un problema di lettura

delle variabili sul dispositivo: potrebbe infatti essere impossibile accedere a

tutte le informazioni direttamente dai moduli hardware del dispositivo. In

questi casi, le informazioni vengono lette da dei registri che non sono ag-

giornati istantaneamente, portando alla registrazione di dati vecchi e, che

quindi, non corrispondono al reale stato del telefono. Un esempio pratico


è il valore -1 associato al modulo di rete quando il dispositivo mobile ha

attivata la modalità airplane; in questo caso il valore -1 è corretto, ovve-

ro il segnale non può essere rilevato dal telefonino che quindi memorizza

un valore inconsistente. Poiché tale valore può essere ricostruito si procede

nella sostituzione del valore -1 con il valore -99 che secondo la convenzione

stabilita equivale a uno stato di segnale debole.

• Mascheramento delle incoerenze: in questa fase i sample che presentano

un comportamento anomalo, ovvero non riconducibile a un comportamen-

to reale, vengono mascherati in modo da non influenzare la fase di training.

La differenza con il mascheramento degli outlier è che in questo caso il valo-

re presentato dalla variabile sotto analisi ricade nell’insieme di valori possi-

bili per la variabile stessa ma esistono delle condizioni su altre variabili che

non permettono la presenza di quel valore.

• Riduzione della granularità: in questa fase i dati vengono riscalati così da

renderli omogenei tra i diversi dispositivi. Tale operazione viene eseguita

ad esempio per i valori di luminosità dello schermo: questi valori dipendo-

no infatti dal S.O. del dispositivo; in alcuni S.O. varia tra 0 e 12, in altri tra 0

e 255 e in altri ancora tra 0 e 500.

B.I. In questa fase, la prima del modulo relativo al calcolo del modello lineare,

i sample dell’utente vengono divisi in sequenze di batch. Condizioni necessarie e

sufficienti per cui un sample venga assegnata a una sequenza sono:

• Dato un nuovo sample ei campionato all’istante t(ei) e una sequenza S, t.c.

S = (ei−1, . . . , ei−n), avremo che

ei ε S ⇔ |t(ei) − t(ei−1)| < T (3.1)

cioè ei sarà aggiunto alla sequenza S se la sua distanza temporale dall’ulti-

mo sample aggiunto ad S è minore di una particolare soglia detta T . Tale so-


glia è assegnata in modo da minimizzare l’errore introdotto dalla presenza

di dati troppo distanti temporalmente durante il calcolo.

• Dato un nuovo sample ei avente configurazione ci e una sequenza S, t.c.

S = (ei−1, . . . , ei−n) e ek ha configurazione c con i − 1 < k < i − n,

avremo che

ei ε S ⇔ ci = c (3.2)

cioè la configurazione di ei coincide quindi con la configurazione di S.

In altre parole, la configurazione associata ad una sequenza coincide con la con-

figurazione del suo primo sample. Ogni sequenza ha una cardinalità compresa

tra 10 e 100 sample. Questo implica che ogni qualvolta la sequenza considerata

abbia raggiunto la sua cardinalità massima o il sample analizzato non rispetti le

condizioni sopra citate sarà creata una nuova sequenza.

B.M. Nella seconda fase del modulo relativo al calcolo del modello si analizza-

no le singole sequenze; in particolare si rendono cumulative le variabili istantanee

e categoriche che le compongono e si aggiunge l’informazione relativa alla mo-

notonia. Questa operazione è necessaria per preparare le variabili al calcolo del

modello vero e proprio.

S.M.L. In questa fase viene effettuata la stima dei parametri per il seguente

modello:

y(i) = αc[y(i− s), . . . , y(i− 1), x(i− s), . . . , x(i)]T (3.3)

Dove:

• x(i): rappresenta il contributo di scarica delle variabili esogene al tempo

i-esimo. Definiamo variabili esogene tutte le variabili non appartenenti alla

configurazione.


• y(i): rappresenta la percentuale di batteria scaricata dalla configurazione

considerata al tempo i-esimo.

• αc: fissata la configurazione viene calcolato un modello (del tipo 3.1) per

ogni tipo di rete registrata dall’utente (edge, 3g, . . . ). Avremo quindi un

vettore α1,α2, . . . , αn dove il generico elemento αc (1 < c < n) rappresenta

il numero di volte in cui si sono registrati sia la configurazione considerata

che il tipo di rete considerato. Si precisa che in Italia, attualmente, possono

avere al massimo 15 tipi di reti differenti e quindi n <= 15.

Il parametro del modello αc sarà quindi dato dalla media pesata dei para-

metri precedentemente calcolati.

Più precisamente tale modello, equazione 3.1, verrà calcolato per tutte e sole le

configurazioni per cui è stato possibile creare almeno una sequenza.

Definizione del problema Il presente elaborato si pone l’obiettivo di migliorare le

prestazioni del modello appena schematizzato attraverso l’introduzione del modulo di U.P.

ossia un modello che prende in considerazione le abitudini dell’utente per predire il TTL

del dispositivo mobile. La profilazione dell’utente e lo studio delle sue abitudini, infatti,

hanno portato numerosissimi vantaggi in diversi campi di ricerca.

Il modello così descritto ha come forte limitazione l’ipotesi iniziale per cui un

utente, una volta scelta una configurazione, cioè abbia selezionato le impostazioni

relative a gps, airplane, wifi, bluetooth, mobile e luminosità dello schermo non

le modifichi per tutto il periodo di autonomia del proprio smartphone. Questo

ovviamente non rispecchia l’utilizzo comune di un utente del proprio dispositivo

mobile. Studi statistici hanno infatti calcolato che il 58% degli utenti utilizza il

proprio cellulare almeno una volta ogni ora e nel resto del tempo lo lasciano in

uno stato di idle ovvero a schermo spento wifi scollegato. Questo dato sale al

68% per gli utenti con età compresa tra i 18 e i 30 anni [39]. Avendo un numero

così alto di interazioni è pertanto realistico credere che le impostazioni del device


cambino con le esigenze dell’utente durante tutta la giornata; ad esempio facendo

una telefonata o controllando la posta elettronica.

Il secondo problema presente nel modello attuale è relativo all’approssima-

zione utilizzata per il calcolo del parametro αc del modello lineare 3.1. Come già

spiegato tale parametro viene calcolato effettuando una media pesata tra le diver-

se curve generate dal modello a parità di configurazione. Ci si è quindi chiesti se

il calcolo del TTL potesse essere ben approssimato attraverso una media pesata o

fosse necessario introdurre un altro modello che provi a prevedere la configura-

zione più probabile del dispositivo mobile in base alle abitudini dell’utente. Sfrut-

tare le informazioni relative alla ripetitività dell’utente potrebbe portare infatti

un sensibile miglioramento sul reale impatto delle variabili, di configurazione ed

esogene, considerate dal modello.

Il terzo aspetto affrontato in questa tesi è relativo alla facilitazione della ge-

stione dei consumi del proprio device da parte dell’utente. Si è infatti notato che

l’informazione relativa al TTL non era sufficiente per avere una visione completa

del comportamento energetico del proprio dispositivo, si è quindi aggiunto un

nuovo modello di potenza relativo al TTC del dispositivo. Riteniamo infatti che

questa informazione sia utile per programmare quando ricaricare il proprio de-

vice o quando affidarsi a carica batterie esterni. Consideriamo ad esempio il caso

in cui un utente stia aspettando una telefonata importante e veda, utilizzando

MPower, che ha solo 20 minuti di autonomia. Grazie all’informazione fornita dal

nuovo modello di potenza egli si accorge che sono necessarie 7 ore per ricaricare

il dispositivo e può quindi decidere di portarsi un carica batterie esterno nel caso

in cui debba uscire.

3.2 Soluzione proposta

Le soluzioni individuate ai problemi sopra citati sono tre:

• l’introduzione del modulo di U.P., cioè l’adozione di un modello che tenga

3.2. SOLUZIONE PROPOSTA 47

in considerazione le abitudini dell’utente e che quindi vari con esse. Que-

sto ha permesso di eliminare completamente l’ipotesi alla base del modello

attuale ovvero che le impostazioni delle variabili di interesse per la costru-

zioni del modello di MPower non vengano modificate durante il tempo di

utilizzo del dispositivo, ovvero per il tempo che trascorre tra una ricarica

della batteria e l’altra.

Tra le diverse opzioni disponibili è stato deciso di sfruttare un modello già

ampiamente utilizzato in numerosissimi campi quali il page rank di Google

[12], per predire il comportamento degli utenti: le catene di Markov.

Andando a riprendere la soluzione proposta nel primo punto, il modello di

Markov è rappresentabile attraverso la tupla < S,A, λ >. Andiamo ora a descri-

vere il significato che assumono tali valori nel nostro campo applicativo:

• S: rappresenta l’insieme degli stati in cui si può trovare il modello. Nel no-

stro caso coincide con tutte le possibili configurazioni individuate in ogni

utente. Poiché ogni configurazione è composta da 6 variabili (gps, wifi, lu-

minosità dello schermo, mobile, bluetooth, airplane), la maggioranza delle

quali può assumere valore 0 o 1, a meno di luminosità dello schermo che

può assumere quattro valori, la cardinalità massima dello spazio degli stati

sarà 27, mentre la cardinalità minima è 1. Questa soglia superiore non è mai

raggiunta all’interno del nostro test set. Nel caso peggiore arriviamo infatti

a registrare 90 configurazioni.

• A: la matrice delle adiacenze, schematizzata in Figura 3.2, rappresenta

la probabilità che un utente, durante la giornata, cambi le impostazioni

hardware relative ai moduli wi-fi, airplane, bluetooth, mobile, rete, gps e

luminosità del proprio dispositivo. Tale probabilità è stimata tramite:

p(transizione A→ B) =#(transizioni registrate A→ B)

#entry(3.4)

• λ: rappresenta lo stato iniziale da cui parte il calcolo del modello.


Figura 3.2: esempio di catena di Markov nel contesto dei MPower

Tale modello di potenza viene calcolato all’interno del modulo U.P.. A que-

sto punto il modulo S prende le informazioni relative alle catene di Markov e

al modulo S.M.L. e le unisce in modo da fornire l’informazione relativa al TTL.

Il modello proposto, infatti, non è un’alternativa a quello esistente ma una sua

estensione. La catena di Markov permette infatti di predire gli stati in cui si tro-

verà l’utente e si affiderà al modello attuale per calcolare il tempo di scarica as-

sociato ad ogni stato. Avremo quindi un comportamento iterativo: il modello di

Markov calcolerà lo stato successivo in cui si troverà l’utente e il modello attuale

fornirà il tempo di scarica. A questo punto il modello di Markov predirà un nuo-

vo stato e chiamerà il modello attuale e così via fino a predire tutta la scarica. I

risultati legati all’adozione di questa metodologia, presentati nella Sezione 5, mo-

strano chiaramente che la scelta di considerare il comportamento dell’utente per

il calcolo del TTL porta a miglioramenti rispetto al modello attuale.

Le soluzioni proposte per gli altri problemi sono invece:

• il secondo problema viene affrontato durante questo elaborato solo a livello

teorico. Nello studio effettuato ci si pone come obiettivo quello di analiz-

zare le entry registrate per provare il comportamento ripetitivo dell’uten-

3.3. IL MODELLO DI MARKOV 49

te. Se infatti un comportamento ripetitivo fosse dimostrato tale informazio-

ne potrebbe essere sfruttata per migliorare l’approssimazione del modello

attuale.

• l’introduzione di un modello di potenza relativo al calcolo del TTC, cioè

che simuli il comportamento di carica dei dispositivi mobile dell’utente. Lo

studio effettuato per definire la metodologia applicata durante il calcolo di

questo modello verrà descritto della Sottosezione 4.3.

3.3 Il modello di Markov

Ipotizziamo i dati analizzati e descritti nella sezione precedente sono dati se-

quenziali e stazionari. Definiamo sequenziali tutti e soli i dati che vengono rac-

colti attraverso misurazioni di serie temporali generate da processi stazionari ov-

vero sebbene le serie temporali evolvano nel tempo la distribuzione statistica del

fenomeno che li genera rimane costante.

Per affrontare il problema della previsioni future dei TTL è invece necessa-

rio scegliere un modello in grado di prevedere l’evoluzione temporale di tali

dati a partire dai campioni raccolti; la metodologia che meglio si adatta a que-

sto compito è quella delle catene di Markov [27] che andremo ora a definire

formalmente.

Le catene di Markov sono un esempio di processo stocastico, cioè una colle-

zione di variabili aleatorie che evolve nel tempo x0, x1, x2, . . . , xn. Tali variabili,

appartenenti a un insieme finito e discreto, rappresentano gli stati di un sistema

a tempo discreto.


Figura 3.3: Rappresentazione di una catena di Markov del primo ordine

Le catene di Markov di primo ordine, un esempio di cui è rappresentato in

Figura 3.3, si differenziano da un processo stocastico generico in quanto devo-

no soddisfare la proprietà di Markov. Tale proprietà afferma che la probabili-

tà di trovarsi a uno stato j nell’istante n+1, che nel processo stocastico generico

dipenderebbe da tutti gli stati precedenti

P(xn+1 = j|xn = i, xn−1 = in−1, . . . , x0 = i0) (3.5)

dipenda invece solo dallo stato immediatamente precedente

P(xn+1 = j|xn = i) (3.6)

Vale a dire che passato e futuro sono condizionatamente indipendenti una volta

definito il presente. In altre parole, se conosciamo l’informazione relativa allo sta-

to attuale allora le informazioni relative a gli stati precedenti non sono necessarie

per predire lo stato futuro. Possiamo quindi indicare tale probabilità condizionata

come:

P(xn+1 = j|xn = i) = pij (3.7)

Se il processo rispetta tale proprietà allora è detto omogeneo.

3.3. IL MODELLO DI MARKOV 51

Figura 3.4: Rappresentazione di una catena di Markov del secondo ordine

In molte applicazioni le catene di Markov di primo ordine non riescono a de-

scrivere completamente il sistema in quanto l’andamento successivo del processo

può essere determinato da numerose osservazioni successive e in questi casi si

utilizzano delle catene di Markov di ordine maggiore. Se, ad esempio, la predi-

zione dipende sia dal valore presente che da quello precedente ad esso, otteniamo

una catena di Markov di secondo ordine, come quella rappresentata in Figura

3.4. La probabilità di transizione in questo caso diventa quindi:

P(xn+1 = j|xn = i, xn−1 = k) = pijk (3.8)

Ovviamente possiamo riproporre la precedente considerazioni un numero arbi-

trario di volte ed arrivare quindi ad ottere catene di Markov di ordine k.

Le catene di Markov sono un processo stocastico che rispetta la proprietà di

Markov e descrivibile dalla tupla:

< S,A, λ > (3.9)

Analizzando nel dettaglio gli elementi di tale tupla abbiamo:

• S: rappresenta l’insieme di r ∈ N stati in cui il processo si può trovare, S =

{s1, s2, . . . , sr}. In particolare il processo si sposta da uno stato all’altro e ogni


cambiamento di stato è detto passo. Se la catena si trova nello stato si, la

probabilità che al passo successivo si sposti nello stato sj coincide con la

probabilità condizionata pij definita in Eq. 3.7 e, come già sottolineato, tale

probabilità è indipendente dagli stati attraversati dalla catena per arrivare

allo stato corrente. La probabilità pij è detta probabilità di transizione e nel

caso in cui il processo rimanga nello stesso stato verrà indicata come pii;

• λ: rappresenta lo stato iniziale da cui parte il processo. Condizione necessa-

ria è che λεS.

• A: la matrice di adiacenza è una matrice quadrata rxr dove r coincide con

il numero di stati presenti in S. In particolare, tale matrice, rappresenta le

probabilità di transizione tra gli stati S. Proprietà fondamentali di A sono:

∀pijεA,pij > 0 (3.10)

r∑k=1

pkj = 1,∀j, 1 6 j 6 r (3.11)

Nel Capitolo successivo si analizzerà come il modello appena descritto possa

essere utilizzato per la predizione di eventi futuri.

3.4 Tempo di carica

In questa Sezione andiamo a presentare la metodologia ideata per il calcolo

di un modello di potenza che possa descrivere il comportamento del TTC nei

dispositivi mobili.

3.4. TEMPO DI CARICA 53

Figura 3.5: Flusso di operazioni per il calcolo del TTC

La metodologia ideata è presentata in Figura 3.5, ed è suddivisibile in tre

operazioni distinte:

• Pulizia dei dati: questa fase è ideata per eliminare le anomalie nei dati,

ad esempio eliminare tutti i sample raccolti il cui livello di carica supera il

98%. Questa operazione risulta necessaria in quanto l’informazione del li-

vello di batteria [40] viene gestita dal sistema operativo presente sui dispo-

sitivi; quest’ultimo ha un comportamento non deterministico nel mostrare

la percentuale reale di carica della batteria quando questa supera la soglia

indicata precedentemente; si è quindi deciso di considerare durante l’analisi

solo i valori inferiori a tale soglia.

• Clusterizzazione dei dati: questa fase è introdotta per identificare le diver-

se velocità di carica, per questo motivo si è deciso di dividere le cariche

registrate attraverso un algoritmo di clusterizzazione. L’algoritmo scelto è

X-mean ovvero una variante del più famoso algoritmo di k-mean [41]. L’in-

novazione introdotta da X-mean è legata al riconoscimento dinamico del

numero di classi in cui dividere il sistema; una maggior descrizione dell’al-


goritmo verrà fornita nel Capitolo 4. Poiché ogni curva di carica è identifi-

cabile, nel suo tratto iniziale, da un segmento il quale a sua volta è caratte-

rizzato dalla sua pendenza si è deciso di clusterizzare le curve proprio per

questo valore in quanto è evidentemente rappresentativo di una differente

velocità di carica; maggiore è la pendenze del segmento più velocemente

dispositivo mobile sarà carico.

• Calcolo del modello di potenza: in questa ultima fase è possibile utilizzare

due distinti modelli di potenza, un modello lineare e un modello esponen-

ziale rovesciato.

y = α ∗ x (3.12)

Entrambi approssimano una curva di carica ma poiché i dati sono stati fil-

trati in modo da rimanere sotto la soglia del 98% il modello lineare 3.12 è

quello che meglio approssima il comportamento del dispositivo, come si

può vedere in figura 3.6, ed è quindi quello utilizzato nell’analisi.

Figura 3.6: curva di carica e rispettivi modelli

Capitolo 4

Implementazione

Questo Capitolo ha l’obiettivo di descrivere i dettagli implementativi che han-

no portato alla creazione del modello precedentemente descritto. In particolare si

è deciso di presentare gli argomenti trattati nel seguente ordine:

• 4.1: Presentazione generale degli algoritmi utilizzati per lo sviluppo dei

modelli descritti nel Capitolo 3 relativi al calcolo del TTL

• 4.2: Dettagli implementativi relativi alle singole funzione utilizzate nel cal-

colo dei TTL

• 4.3: Presentazione generale degli algoritmi utilizzati per lo sviluppo dei

modelli descritti nel Capitolo 3 relativi al calcolo del TTC

• 4.4: Dettagli implementativi relativi alle singole funzione utilizzate nel cal-

colo dei TTC

4.1 Presentazione degli algoritmi utilizzati per il calcolo

del TTL

In questa Sezione andiamo a chiarire come la metodologia descritta nel Capi-

tolo precedente sia applicata al nostro caso di studio.

55

56 CAPITOLO 4. IMPLEMENTAZIONE

Figura 4.1: flusso di dati nel processo di generazione del TTL

Per far questo ricordiamo, come già specificato nel Capitolo 2 e come pre-

sentato in Figura 4.1, che il modello introdotto per la profilazione utente, detto

modulo di profilazione utente, prende in ingresso i dati prodotti dal modulo di

preprocessamento e utilizza il modello esistente, in modo iterativo, per predire il

tempo di scarica.

Per il modulo profilazione utente sono state implementate tre varianti. Tut-

te le varianti possono essere divise negli stessi macro blocchi, rappresentati in

Figura 4.2, che andiamo ora a definire. La differenza tra le implementazioni sta

nell’approccio utilizzato nel blocco: calcolo delle matrici di adiacenza.

4.1.1 Definizione delle curve:

in questa fase, le variabili in ingresso coincidono con tutti i dati generati dalla

fase di preprocessing relativi ad un unico utente.

Le variabili in uscita sono invece gli stessi dati ri-organizzati in modo da essere

utilizzabili nella fase di training e/o di testing del modello.

4.1. PRESENTAZIONE DEGLI ALGORITMI UTILIZZATI PER IL CALCOLO DEL TTL57

Figura 4.2: flusso di dati nel calcolo delle matrici di adiacenza

Definiamo ri-organizzazione il processo di selezione sulle entry in ingresso,

tale selezione porta alla divisione tra campioni controllabili e campioni esogeni e

relativa l’eliminazione di questi ultimi.

Ricordiamo che il dispositivo viene modellizzato suddividendolo nelle sue

componenti hardware e ad ogni campionamento viene registrato lo stato di tali

componenti. Ogni stato registrato viene detto campione controllato o esogeno

a seconda che l’utente possa o non possa influire sul valore assunto dallo stato

del componente. Quindi ad esempio lo stato relativo al modulo gps rientra nei

campioni controllati mentre lo stato relativo al tipo di rete a cui è connesso il

dispositivo, quali edge o 3G, rientra nei campioni esogeni.

Una volta effettuata questa prima pulizia i dati vengono divisi in sequenze.

Ogni sequenza contiene tutti e soli i dati che:

• rispettano un ordinamento temporale monotono crescente;

• rispettano un ordinamento decrescente relativo ai campioni che identificano


il livello di batteria del dispositivo;

• la differenza tra i campioni che identificano il timestamp sia minore di una

soglia stabilita.

Le sequenze così riorganizzate vengono suddivise tra dati di training, che

costituiscono il 75% di tutti i campioni, e dati di testing, formati dal rimanente

25%.

4.1.2 Identificazione delle configurazioni:

in questa fase ad ogni gruppo dati appartenente al training set viene associata

una configurazione. Per maggior chiarezza ridefiniamo:

Gruppo dati: insieme di tutti i campioni controllabili dall’utente associati

a un particolare istante temporale e a un livello di batteria.

Configurazione: gruppo di dati limitato ai soli campioni controllabili, e

quindi senza considerare l’istante temporale e il livello di batteria.

Per facilitare la fase successiva si è deciso di rappresentare l’insieme delle con-

figurazioni con numeri interi naturali crescenti. Viene quindi a crearsi una corri-

spondenza biunivoca tra gruppo dati e configurazione, ovvero per ogni gruppo

dati corrisponde una e una sola configurazione e viceversa. Due gruppi dati si

considerano uguali se presentano la stessa configurazione.

E’ quindi possibile creare una struttura dati a dizionario per associare ad ogni

configurazione il gruppo dati corrispondente.

4.1.3 Calcolo delle matrici di adiacenza:

La matrice di adiacenza, come spiegato precedentemente, rappresenta la pro-

babilità di transizione tra uno stato ed un altro: nel nostro caso di studio rappre-

senta la probabilità di transizione tra una configurazione ed un altra.


Figura 4.3: flusso di dati nel calcolo delle matrici di adiacenza

Tale probabilità dipende dalle abitudini dell’utente che cambiano con il tempo

ovvero si modificano a seconda dell’ora del giorno e di conseguenza dell’attività

che l’utente sta svolgendo. L’algoritmo delle catene di Markov è però per sua stessa

natura indipendente dal tempo: ritenendo il tempo un elemento importante nel

calcolo del TTL, per il presente modulo sono state sviluppate tre implementazioni

distinte. La principale differenza è il numero di modelli prodotti:

• modello giornaliero: implementazione standard dell’algoritmo. In questo

caso viene prodotto un unico modello indipendente dal momento della

giornata in cui viene calcolato.

• modello orario: in questo caso si è deciso di implementare 24 modelli di

Markov, uno per ogni ora del giorno. Il modello finale è una concatenazione

dei diversi modelli.

• modello dinamico: in questo caso si è deciso di implementare un numero


di modelli di Markov che dipende fortemente dalle abitudini dell’utente

durante la giornata. Il modello finale è anche in questo una concatenazione

dei diversi modelli creati.

Poiché il modello dinamico è un evoluzione del modello giornaliero e di quello

orario, ed è facilmente riconducibile ad entrambi, procediamo con la presentazio-

ne delle motivazioni che ci hanno portato a implementarlo. Un confronto sulle

prestazioni dei diversi modelli sarà presentato nel capitolo successivo.

Modello dinamico: Poiché i dati raccolti presentano caratteri di ciclicità e va-

riano notevolmente durante l’arco della giornata, si è deciso di utilizzare que-

sta informazione dividendo il giorno in 24 fasce, una per ogni ora, e di calcolare

una matrice di adiacenza per ogni fascia. Dopo aver effettuato questa divisione

abbiamo osservato tre distinti casi:

Caso 1: le matrici di adiacenza di due fasce temporalmente adiacenti sono effet-

tivamente molto diverse secondo una metrica definita in seguito. Questo

implica che effettivamente stiamo registrando comportamenti diversi e che

quindi avremo un miglioramento nella modellizzazione del comportamen-

to dell’utente se consideriamo separatamente le fasce temporali.

Caso 2: le matrici di adiacenza di due fasce vicine sono molto simili secondo una

metrica definita in seguito. In questo caso sarebbe più corretto avere un’uni-

ca fascia, in modo da avere un numero di campioni maggiore da analizzare

durante la fase di apprendimento del modello.

Caso 3: abbiamo infine notato che i dati utilizzati per costruire le matrici di adia-

cenza nelle ore notturne sono un ordine di grandezza inferiore rispetto

quelli delle ore diurne.

Questo è spiegabile dalla politica scelta per effettuare il logging dei dati da

parte dell’applicazione: i dati vengono campionati se e solo se il telefono

non si trova in una fase di sonno profondo. Questa situazione si verifica


quando il telefono non viene utilizzato per un certo periodo, come quando

l’utente sta dormendo. Questo ovviamente crea un’imprecisione maggiore

durante il calcolo dei parametri del modello.

Volendo comunque sfruttare i vantaggi della divisione in fasce giornaliere si è

deciso di unire dinamicamente le fasce sufficientemente simili. In quanto questa

scelta costituisce uno degli elementi principali dell’algoritmo ed è inoltre facil-

mente scomponibile in sotto operazioni distinte, ne forniamo una rappresenta-

zione grafica in Figura 4.3. Andiamo quindi a descrizione più nel dettagliato tali

operazioni.

• Calcolo della matrice delle somiglianze: i parametri in ingresso sono le 24

matrici di adiacenza precedentemente calcolate. Il parametro in uscita è inve-

ce la matrice delle somiglianze, ovvero una matrice quadrata e simmetrica.

La matrice delle somiglianze ha dimensione 24 x 24 in quanto rappresenta

la somiglianza tra una fascia e un’altra; per costruzione abbiamo deciso di

creare 24 fasce ovvero una fascia per ogni ora del giorno; è inoltre simmetri-

ca in quanto la proprietà di somiglianza tra una fascia e l’altra è simmetrica.

Tale matrice è inoltre detta binaria in quanto contiene solo i calori 0 e 1. Il

valore 1 viene inserito quando due fasce sono definite simili ovvero quando

la norma di Frobenius tra le corrispondenti matrici di adiacenza è al di sotto

di una particolare soglia scelta sperimentalmente.

• Definizione dei clique: il parametro in ingresso è la matrice delle somiglianze

ottenuta al passaggio precedente. Tale matrice può essere interpretata come

un grafo bidirezionale che connette fasce simili. I parametri in uscita sono

invece tutte le clique presenti nel grafo. Questa operazione si occupa quindi

di identificare tutte le sottocomponenti connesse del grafo rappresentato

dalla matrice delle somiglianze.

• Controllo della vicinanza temporale: i parametri in ingresso sono le clique

precedentemente identificate, in uscita viene restituito un sottoinsieme dei


parametri passati in ingresso. E’ infatti necessario controllare che le clique

identificate rispettino il vincolo di vicinanza temporale, ovvero le fasce tem-

porali rappresentate dalla clique devono essere adiacenti. Questo vincolo

è necessario per garantire il concetto di divisione in fasce della giornata.

Ognuna di queste nuove fasce rappresenterà il comportamento assunto dal-

l’utente in quel periodo rispecchiando al meglio le sue abitudini. Come ver-

rà presentato nella Sezione Sperimentale, molti utenti del dataset presenta-

no un’unica fascia che copre le ore notturne e un’unica fascia che copre le

ore diurne tipiche degli orari d’ufficio.

• Unione delle matrici di adiacenza simili: in ingresso abbiamo le clique

precedentemente calcolate che rispettano il vincolo di vicinanza temporale

e tutte le 24 matrici di adiacenza; in uscita abbiamo un insieme di fasce di

adiacenza, una per ogni fascia contigua individuata. L’obiettivo è quello di

individuare la copertura ottima del grafo individuato attraverso la matrice

delle somiglianze: verranno quindi unite tutte le matrici di adiacenza che la

costituiscono; l’unione viene effettuata ricostruendo i dati iniziali e creando

una nuova matrice, andando a descrivere tale copertura.

4.1.4 Generazione

Quest’ultima fase rappresenta la parte generativa dell’algoritmo. In partico-

lare il suo compito è quello di interagire con il modulo S.M.L. per generare una

sequenza di livelli di batteria: questa sequenza rappresenta la curva di scarica ge-

nerata dall’algoritmo e, più ad alto livello, il possibile comportamento assunto da

una generica futura curva di scarica.

I parametri in ingresso sono il livello di batteria e la configurazione iniziale da

cui iniziare a generare la curva di scarica. Il parametro di uscita è invece un file json

strutturato come rappresentato in Tabella 4.1.

Ad ogni passo dell’algoritmo verrano eseguite due operazioni:


Tabella 4.1: File json prodotto

Percentuale di carica TTL [min]

100 714

99 707

98 699

. . . . . .

3 21

2 14

1 7

• Scelta della configurazione successiva: questa operazione utilizza due va-

riabili: la matrice di adiacenza della fascia oraria corrente e un numero

random generato dinamicamente dal sistema.

In particolare durante questa fase si andrà a creare una nuova matrice che

conterrà per ogni riga le somme parziali delle probabilità riportate dalla

matrice delle adiacenze. Definita questa matrice si andrà a scegliere la confi-

gurazione successiva dalla matrice appena generata utilizzando le seguenti

condizioni: la riga è quella relativa alla configurazione corrente e la colonna

è quella che contiene il numero random generato. Ad esempio se la prima

cella della riga i-esima contiene il valore 0,2 e la seconda il valore 0,4 e il

valore random generato è pari a 0,3 la colonna scelta sarà la seconda.

• Calcolo del livello di carica: in questa fase si prende lo stato generato e si

interroga il modello regressivo. Ottenuta la quantità di batteria consuma-

ta in 10 secondi (in quanto il campionamento dei dati viene effettuato ogni

10 secondi e non ha quindi senso considerare una granularità inferiore) as-

sociata allo stato generato, questa verrà sottratta alla batteria attualmente


calcolata. Si procederà quindi a scegliere nuovamente la configurazione per

il successivo passo di stima della scarica

L’algoritmo termina quando il livello di batteria calcolato raggiunge valore zero,

cioè quando l’ipotetica curva generata si è completamente scaricata.

4.2 Tempo di scarica

La presente Sezione si pone come obiettivo quello di chiarire i dettagli imple-

mentativi dello sviluppo del modello TTL.

Di seguito sono riportati gli algoritmi utilizzati nello sviluppo dei tre modelli

precedentemente presentati, sottolineando che tutti gli algoritmi utilizzati per il

calcolo del modello giornaliero sono utilizzati per il calcolo del modello orario

e, successivamente, tutti quelli utilizzati per il modello orario vengono utilizzati

per il modello dinamico.

Tali algoritmo sono stati sviluppati in python e verrano messi in produzione

con la prossima release di MPower.

CreaBande L’obiettivo dell’algoritmo è quello di dividere i dati in ingresso in

vettori. Ogni vettore di configurazioniCi conterrà tutte e sole le configurazioni re-

gistrate nella fascia oraria i-esima e verranno utilizzati per il training del modello

i-esimo.

L’Algoritmo 4.2.1 richiede in ingresso i parametri:

• n: un numero naturale che indica il numero di fasce giornaliere che si vo-

gliono creare;

• C: un vettore che rappresenta tutte le configurazioni registrate per l’utente

che si sta analizzando;

• T : un vettore di timestamp, t.c. ogni ti ∈ T rappresenta il tempo in cui la

configurazione ci è stata memorizzata.

4.2. TEMPO DI SCARICA 65

Algoritmo 4.2.1 CreaBande: algoritmo per la creazioni di fasce orarie1: Ingresso: n t.c. n ∈ N; un vettore T = {t1, t2, . . . , tk} t.c. ti = timestamp; un

vettore C = {c1, c2, . . . , cl}

2: Uscita: un vettore di vettori Configurazioni ← {C1,C2, . . . ,Ck} t.c. Ci =

{c1, . . . , cm}

3: ore,Configurazioni, limiti← ∅

4: periodo← int( 24n )

5: for all t ∈ T do

6: ore← date.hour(t)

7: end for

8: for all c in 1 : n do

9: limiti[c]← c ∗ periodo

10: end for

11: for all t in 1 : len(T) do

12: Configurazioni[last(limiti 6 ore)]← C[t]

13: end for

14: Return Configurazioni


La variabile in uscita Configurazioni è invece un vettore di vettori Ci, t.c. ogni

Ci contiene tutte e sole le configurazioni registrate nella fascia oraria i-esima.

Passi: alla Riga 3 andiamo a definire i vettori ore, matrice e limiti mentre in

riga 4 andiamo a definire la variabile periodo. Poiché questo algoritmo crea delle

fasce orarie tali che ogni fascia copra un numero di ore uguale e la granularità

minima sia 1 ora, periodo è un intero positivo compreso tra 1 e 24 ed indica la

dimensione di ogni fascia oraria. In particolare la variabile n utilizzata per defi-

nire periodo assume valore 1 per il modello giornaliero in quanto l’algoritmo non

prevede la divisione dei dati mentre negli algoritmi orario e dinamico n assume

valore 24 in quanto si vuole raggiungere la granularità più piccola possibile ovve-

ro creare una fascia oraria per ogni ora del giorno. Alla Riga 6, grazie alla funzione

date di python, estraiamo le ore dalle variabili del vettore T e le memorizziamo

nel vettore ore. Alla Riga 9 al vettore limiti vengono assegnate le ore iniziali di

ogni banda e infine alla Riga 12 le configurazioni presenti in C vengono divise

nei vettori di Configurazione in modo che ogni ci venga associata al vettore Ct

corrispondente, ovvero assegnato alla fascia oraria corretta.

Algoritmo 4.2.2 Adiacenza: algoritmo per il calcolo della matrice di adiacenza

non cumulativa1: Ingresso: un vettore C = {c1, c2, . . . , ck}, n t.c. n ∈ N

2: Uscita: La matrice A = {a1,1, . . . ,a1,n,a2,1, . . . ,an,n} e un vettore S =

{s1, . . . , sn}

3: S,A← ∅

4: for all c in 0 : n do

5: Sc ← Σ(C == c)

6: end for

7: for all iin 0 : C do

8: A[C[i]][C[i− 1]]← A[C[i]][C[i− 1]] + 1S[i]

9: end for

10: Return A,S


Adiacenza L’obiettivo è quello di calcolare la matrice di adiacenza del modello.

Questo valore è fondamentale per il successivo passo dell’algoritmo, ovvero per

la generazione della catena di Markov.

L’algoritmo 4.2.2 richiede in ingresso due parametri:

• C: il vettore di tutte le configurazioni appartenenti all’utente analizzato e

registrate in una particolare fascia oraria

• n: un intero positivo che rappresenta il numero di configurazioni distinte re-

gistrate per l’utente. Questa informazione non è ricostruibile dal vettore C

in quanto, nelle varianti oraria e dinamica dell’algoritmo, quest’ultimo con-

tiene solo un sottoinsieme delle configurazioni registrate; potrebbe quindi

presentarsi il caso in cui una o più configurazioni non sono mai state regi-

strate per una particolare fascia oraria. Ad esempio se un utente abilita il

wi-fi solo nelle ore lavorative le configurazioni che presentano il valore di

wi-fi pari a 1 non possono essere registrate nelle ore notturne.

In uscita l’algoritmo produce:

• A: la matrice delle adiacenze.A è una matrice quadrata n×n t.c. n coincide

con il numero di configurazioni distinte registrate dall’utente.

• S: un vettore di configurazioni formato da n elementi, ognuno dei quali

rappresenta la somma delle occorrenze della configurazione corrispondente

registrate in quella particolare fascia oraria.

Passi: alla Riga 3 vengono inizializzati i vettori A e S, quest’ultimo rappre-

senta la cardinalità delle configurazione; se la configurazione 1 si presenta n volte

allora S[1] varrà n e così via per tutte le altre configurazioni (Riga 5). Alla riga

8 viene invece calcolata la matrice delle adiacenze vera e propria. Ogni elemen-

to A[x,y] sarà uguale al rapporto tra il numero di volte in cui si è verificata la

successione di configurazioni x-y e il numero di volte in cui si è presentata la

configurazione x.


Algoritmo 4.2.3 Produzione: algoritmo per la generazione della catena di Markov

1: Ingresso: bi t.c. bi ∈ N,bi 6 100; bf t.c. bf ∈ N,bf < bi; c ∈ N; una lista

di matrici A; un timestamp ts; una lista L = {l1, . . . , ln} t.c. ln ∈ N, ln < 24;

idUtente

2: Uscita: Sequenza S← {s1, s2, . . . , sk} t.c. si ∈ S, si =< bi, ti,mi, ci >

3: text←MPowerAttuale(idUtente)

4: S← ∅

5: B← cumsum(A)

6: orainiziale ← data.hour(ts)

7: minutoiniziale ← data.minute(ts)

8: attuale← trovaValore(orainiziale,L)

9: while bi > bf do

10: ts← ts+ 10 ∗ 1000

11: if th > orainiziale then

12: attuale← trovaValore(orainiziale,L)

13: end if

14: attuale← th

15: riga← B[attuale][c]

16: random← random()

17: c← trovaValore(random, riga)

18: consumo← parser(text, c)

19: bi ← bi − consumo

20: S.append(bi, th, consumo, c)

21: end while

22: Return S


Produzione L’obiettivo della funzione è quello di generare una possibile futura

curva di scarica di un preciso utente applicando l’algoritmo di Markov.

L’Algoritmo 4.2.3 richiede in ingresso i seguenti parametri:

• bi: un intero positivo minore di 100. Rappresenta il livello di batteria iniziale

da cui iniziare a generare la curva di scarica;

• bf: un intero positivo minore della variabile bi. Rappresenta il livello di

batteria a cui fermarsi durante la generazione della curva di scarica;

• c: un intero positivo che rappresenta la configurazione iniziale da cui ini-

ziare a generare la curva di scarica.

• A: la lista delle matrici di adiacenza. La cardinalità della lista varia tra 1 e

24 a seconda della variante dell’algoritmo adottata.

• ts: il timestamp in cui si inizia a generare la curva di scarica.

• L: la lista dei limiti di ogni fascia oraria. Questa informazione è necessaria

per la variante dinamica dell’algoritmo, in quanto la dimensione di ogni

fascia oraria dipende solamente dalle abitudini dell’utente;

• idUtente: l’identificativo dell’utente per cui si sta generando una curva di

scarica.

La variabile in uscita è la sequenza S. Ogni elemento della sequenza è una

tupla < bk, tk,mk, ck > tale che:

• bk: rappresenta il livello di batteria associato al k-esimo passo;

• tk: rappresenta l’istante di tempo associato al k-esimo passo;

• mk: rappresenta la pendenza associato al k-esimo passo;

• ck: rappresenta la configurazione generata al k-esimo passo;


Passi: alla Riga 3 vengono caricati nella variabile text i modelli generati dal-

l’attuale modello di MPower. Alla Riga 5 viene calcolata la Matrice B come som-

ma cumulativa rispetto le righe della matrice A. Questa operazione è necessaria al

fine di facilitare la scelta dello stato successivo durante l’operazione di generazio-

ne. Alle Righe 6, 7, vengono estratti i valori associati all’ora e al minuto di inizio

generazione dell’algoritmo. Questa informazione è particolarmente rilevante per

le varianti oraria e dinamica dell’algoritmo in quanto va ad indicare il modello

di partenza da cui iniziare a generare la curva di scarica. Alla Riga 8 viene inizia-

lizzata la variabile attuale il cui compito è quello di indicare la fascia temporale

e quindi il modello che si deve considerare per la generazione del passo succes-

sivo. Alla Riga 10 il tempo iniziale viene incrementato di 10 secondi, si è infatti

deciso di far durare ogni passo generativo 10 secondi in quanto questa è la durata

del tempo di campionamento effettuata dall’applicazione MPower sul dispositi-

vo. Alla Riga 12 viene aggiornato il valore di attuale nel caso si sia cambiata fascia

oraria: questo permette di spostarsi tra un modello e l’altro a seconda dell’ora

di generazione memorizzata. L’ultima operazione eseguita dall’algoritmo è quel-

la di selezionare la configurazione successiva. Poiché questa scelta dipende solo

dalle abitudine dell’utente ed è scelta in maniera probabilistica usando un nume-

ro random alla Riga 16, dove viene generato un numero random compreso tra

0 e 1 che andrà ad indicare la probabilità di trovarsi in una particolare configu-

razione in quell’istante. Sarà quindi quella configurazione, scelta casualmente a

rappresentare lo stato successivo raggiunto dal algoritmo.


Somiglianza L’obiettivo della funzione è quello di calcolare delle fasce orarie

che non abbiano una durata pre-determinata e simmetrica ma che dipendano

solamente dalle abitudini dell’utente. Questa funzione viene utilizzata solo nella

variante dinamica del modello.

La Funzione 4.2.4 richiede in ingresso i seguenti parametri:

• A: il vettore delle 24 matrici di adiacenza, ogni matrice rappresenta un

parametro del modello della fascia giornaliera a cui è associata.

• D: il vettore delle occorrenze. Ogni vettore Di ∈ D ha lunghezza pari al

numero di configurazioni registrare per l’utente analizzato e in ogni cella

contiene il numero di occorrenze registrate per la configurazione associata

in quella particolare fascia oraria.

In uscita abbiamo due parametri:

• A: il vettore delle matrici di adiacenza. La differenza con il vettore in in-

gresso è che le matrici di adiacenza del primo, se verificate particolari con-

dizioni, sono state sommate; abbiamo quindi un vettore che potenzialmente

presenta meno matrici del vettore di partenza;

• tempi: un vettore che va indicare le ore coperte dai modelli passati dalla

matrice A

Passi: alla Riga 7 viene calcolata la matrice somiglianza, una matrice quadra-

ta 24 × 24 che rappresenta, come suggerisce il nome, il grado di somiglianza tra

le matrici di adiacenza passate alla funzione. Poichè somiglianza è simmetrica

per costruzione, viene calcolata solo la parte superiore. In particolare la generica

cella x-y sarà posta uguale a 1 se e solo se le matrici Ax e Ay sono simili tra lo-

ro, altrimenti sarà posta uguale a zero. Alla Riga 10 viene utilizzata la funzione

findClique che andiamo ora a definire. Il parametro in ingresso alla funzione è la

matrice appena calcolata somiglianza, che può essere interpretata come un grafo

bidirezionale sparso. Il compito di findClique è di calcolare tutte le clique presenti


Algoritmo 4.2.4 Somiglianza: algoritmo per il calcolo delle matrici di adiacenza

1: Ingresso: un vettore di matrici A = {A1,A2, . . . ,A24} t.c. ∀ Ai ∈ A, Ai =

{a1,1, . . . ,a1,n, . . . ,an,1, . . . ,an,n}; un vettore D = {D1, . . . ,D24} t.c. ∀ Di ∈ D,

Di = {d1, . . . ,dn};

2: Uscita: un vettore di matrici adiacenza = {A1,A2, . . . ,Am} t.c. Ai =

{a1,1, . . . ,a1,n, . . . ,an,1, . . . ,an,n}, t.c.m 6 24; un vettore tempi = {t1, . . . , tm}

3: tempi← [0, 1, . . . , 24]

4: adiacenza, somiglianza← ∅

5: for all i in 0 : 24 do

6: for all j in (i+ 1) : 24 do

7: somiglianza← distanzaEuclidea(A[i],A[j])

8: end for

9: end for

10: clique← findClique(somiglianza)

11: clique← puliziaClique(clique)

12: for all t in tempi do

13: temp← getelement(clique, t)

14: if len(temp) > 1 then

15: for all elemento in temp do

16: elemento← sort(elemento)

17: adiacenza.append(unisciMatrici(A[u[0] : u[−1]],D[u[0] :

u[−1]]))

18: tempi← elimina(tempi,u[1],u[−1])

19: end for

20: else

21: adiacenza.append(A[t])

22: end if

23: end for

24: Return adiacenza, tempi


nel grafo ovvero tutte le sotto componenti completamente connesse del grafo tali

che percorrendole partendo da un qualsiasi nodo si riesca a ri-raggiungerlo. Alla

Riga 11 vengono eliminate tutte le clique che non rispettano i vincoli di vicinanza

temporale e successivamente di copertura massima. Definiamo due matrici vici-

ne temporalmente se appartengono a fasce giornaliere contigue, ovvero se, date

due fasce qualsiasi, non esista una terza fascia tra le due considerate. La copertu-

ra massima viene invece garantita andando a selezionare le clique con il massimo

numero di nodi tali per cui non esistano due clique che coprano gli stessi punti.

A questo punto tutte le matrici appartenenti a una clique vengono unite (Riga 17)

grazie alla funzione unisciMatrici e appese nel vettore adiacenza. Tutte le ore, a

partire dalla seconda, coperte dalla nuova matrice vengono quindi eliminate dal

vettore tempi che andrà quindi a contenere tutti e soli i limiti temporali dei nuovi

modelli appena definiti.

Algoritmo 4.2.5 Algoritmo per la generazione del TTL giornaliero

1: Ingresso: idUtente

2: Uscita: file

3: file← ∅

4: dati, tempi← pulizia(idUtente)

5: configurazioni, elencoConfigurazioni,dizionario ←

trovaConfigurazione(dati)

6: adiacenza← ∅

7: divisione← creaBande(1, tempi, configurazioni)

8: adiacenza← adiacenza(divisione, 1)

9: tempi← [0]

10: stato← generaStatoIniziale(configurazioni, elencoConfigurazioni)

11: ts = sys.time()

12: sequenza = produzione(100, 0,adiacenza, ts, tempi, idUtente)

13: file← Json(sequenza)

14: Return file


Algoritmo 4.2.6 Algoritmo per la generazione del TTL orario


2: Uscita: file

3: file← ∅




6: adiacenza← ∅


8: adiacenza← adiacenza(divisione, 24)

9: tempi← [0, 1, . . . , 24]


11: ts = sys.time()



14: Return file


Algoritmo 4.2.7 Algoritmo per la generazione del TTL dinamico


2: Uscita: file

3: file← ∅




6: adiacenza,denominatori← ∅


8: adiacenza,denominatori← adiacenza(divisione, 24)

9: adiacenza, tempi = somiglianza(adiacenza,denominatori)


11: ts = sys.time()



14: Return file


Generazione L’obiettivo di queste funzioni è di generare una curva di scari-

ca che approssimi l’andamento energetico futuro del dispositivo monitorato da

MPower.

Gli Algoritmi 4.2.5, 4.2.6 e 4.2.7 rappresentano le tre varianti dell’algoritmo

utilizzato nella profilazione utente. Per sottolineare maggiormente le parti comu-

ni e quelli diverse si è scelto di presentare tutte le varianti contemporaneamente.

In ingresso viene passato l’identificativo univoco dell’utente che si vuole analiz-

zare, in uscita invece viene generato un file Json come quello presentato in Tabella

4.1.

Passi: alla Riga 4 vengono estratti i dati dal database relativi all’utente da ana-

lizzare e organizzati in vettori. Dopo questo primo passo che possiamo definire

di preprocessing dei dati è necessario riconosce e convertire le configurazioni. Ad

ogni nuovo vettore < gpsi, wifii, mobilei, airplanei, screeni, bluettothi >

viene associato un intero positivo crescente e la nuova conversione viene memo-

rizzata nella variabile dizionario (Riga 5) Alla Riga 7 viene utilizzata la funzione

creabande sopra definita; questa è la prima istruzione che varia a seconda dell’al-

goritmo in quanto nell’algoritmo giornaliero verrà creata un unica fascia oraria

mentre negli altri due casi verranno create 24 bande. Dovendo ora determinare i

limiti temporali di ogni fascia oraria, necessari per l’utilizzo della funzione produ-

zione, alla Riga 9 viene istanziata la variabile tempi. Dopo aver chiamato la fun-

zione di produzione (Riga 12) e aver salvato il risultato nella variabile sequenza,

questa viene riorganizzata in un file Json e salvata nel database server.

4.3 Presentazione degli algoritmi utilizzati per il calcolo

del TTC

In questa Sezione andiamo a descrivere le analisi effettuate per validare la

metodologia precedentemente descritta e che hanno portato alla definizione degli

algoritmo che andremo successivamente a presentare.

4.3. PRESENTAZIONE DEGLI ALGORITMI UTILIZZATI PER IL CALCOLO DEL TTC77

Analisi del singolo utente: ambiente sperimentale Per validare il modello di

potenza proposto per il calcolo del TTC si è pensato di utilizzare una tecnica in-

duttiva, cioè si è pensato di partire validando un singolo utente e, successivamen-

te, se verificata la metodologia di estenderla su tutto il dataset.

Si è quindi iniziata l’analisi considerando un utente casuale il cui unico prere-

quisito fosse quello di essere registrato al sistema MPower da abbastanza tempo

per aver permesso di collezionare una quantità di dati significativa. Come già

ipotizzato, si è effettivamente notato che il comportamento delle cariche sopra il

98% presentava delle anomalie. Si è quindi deciso di considerare durante l’analisi

solo i valori inferiori a tale soglia. Una volta individuati tutti i dati relativi ai pe-

riodi di carica è necessario dividerli in modo da ottenere singole curve di carica.

Il risultato di questa operazione può essere visto in Figura 4.4 da cui si può inol-

tre notare come venga persa l’informazione relativa al livello di carica iniziale del

dispositivo in quanto tutte le curve di carica vengono traslate nell’origine degli

assi per semplificare l’analisi.

Figura 4.4: divisione delle curve di ricarica registrate

Da queste curve è stato possibile stimare il tempo impiegato dal dispositivo

per essere completamente carico (98%). Si è quindi calcolato il modello lineare

y = λ ∗ t (4.1)

il cui parametro rappresentativo λ è la pendenza del segmento. In Figura 4.5 sono

state rappresentate tutte le pendenze dei modelli precedentemente calcolati. La


scelta di rappresentarli in ordine crescente è stata effettuata per permettere una

più agevole lettura dei risultati.

Figura 4.5: sequenza ordinata crescente di tutte le pendenze dei modelli delle curve di carica

Come ci si aspettava e come si può notare dalla stessa figura esiste una notevo-

le differenza tra questi valori, tra le pendenze più piccole e quelle massime si è re-

gistrato una differenza pari ad un ordine di grandezza. Si è quindi effettuata la di-

visione in classi utilizzando l’algoritmo di X-mean precedentemente descritto. In

questo particolare caso sono state individuate tre classi, come si può vedere in Fi-

gura 4.6. Come ci si aspettava le classi presentano dei pesi differenti, nel senso che

il numero di elementi appartenenti a ciascuna di esse varia significativamente.

Figura 4.6: clusterizzazione delle pendenze

Figura 4.7: curve di carica colorate per cluster

4.3. PRESENTAZIONE DEGLI ALGORITMI UTILIZZATI PER IL CALCOLO DEL TTC79

Osservazioni La Figura 4.7 mostra chiaramente la presenza di tre classi diver-

se. In questa fase si sono potute esplorare le motivazioni che hanno portato alla

presenza di differenti classi che precedentemente si erano solo ipotizzate. Per far-

lo, si è quindi effettuata un’analisi accurata su tutti i dati raccolti e si è dedotto

che la presenza di differenti classi fosse legata ad informazioni esterne che non

potevano essere analizzate, come ad esempio l’utilizzo di diversi carica batterie.

Questa ipotesi è supportata anche dal controllo del voltaggio fornito al telefono

da un carica batterie da muro rispetto a quello della porta USB del computer. Il

primo, infatti, ha una portata pari al doppio della seconda.

Analisi su tutti i dispositivo: ambiente sperimentale Una volta validati i risul-

tati ipotizzati la stessa analisi è stata effettuata su tutti gli utenti del dataset.

Osservazioni Dopo aver effettuato il calcolo delle pendenze e la divisione in

cluster, seguendo gli stessi passi esposti precedentemente, si è potuto osservare

che solo 15 utenti presentavano più di due classi. La Figura 4.8 divide tutti gli

utenti analizzati per il corrispondente numero di classi. In particolare ad ogni

Figura 4.8: users divided for number of clusters

utente sarà associato un numero di modelli pari a numero di classi che presenta

e quindi un utente che appartiene a due classi avrà due modelli. All’applicazione

MPower sono quindi passati i modelli calcolati, ognuno dei quali viene associato

alla probabilità con cui può presentarsi.


Andiamo ora a presentare gli algoritmo utilizzati utilizzati per dividere i dati

e produrre i modelli sopra descritti.

4.4 Tempo di carica

In questa Sezione andiamo a presentare gli algoritmi utilizzati per il calcolo

del TTC.

Funzione: Pulizia dei dati La funzione Pulizia dei dati, utilizzata alla Riga 7 del-

l’algoritmo 4.4.10, ha l’obiettivo di dividereD e Y nelle sequenze di configurazio-

ni c1, c2, . . . , cs tali per cui ogni sequenza associata y1,y2, . . . ,ys è una sequenza

monotona crescente.

Prende in ingresso due vettori D e Y di lunghezza n. Ogni elemento di ∈

D rappresenta la configurazione campionata all’istante i-esimo, similmente ogni

elemento yi ∈ Y rappresenta il livello di batteria campionato all’i-esimo istante

di tempo.

In uscita abbiamo invece due vettori:

• Cs = {c1, . . . , cs}, t.c. ∀ci ∈ Cs, ci = sequenza di configurazioni successive;

• Bs = {b1, . . . ,bs}, t.c. ∀bi ∈ Bs = sequenza dei livelli della batteria.

Gli elementi di C e B sono associati a parità di indice.

Riportiamo solo la descrizione della funzione e non il relativo codice in quan-

to sebbene fondamentale per lo sviluppo dell’algoritmo non presenta particolari

complessità implementative.

Funzione: Tabella La funzione Tabella richiede in ingresso la coppia di vettori

M e X. Il vettoreM include i centroidi identificati dall’algoritmo di k-means sopra

introdotto, mentre il vettore X è costituito da una sequenza di etichette t.c. l’i-

esima etichetta rappresenta l’indice associato al centroide i-esimo del vettoreM.


Algoritmo 4.4.8 Tabella

1: Ingresso: V = (M,X),M = (m1, . . . ,mk),X = (x1, . . . , xh)tcp ∈ Z, x ∈ N

2: Uscita: T = (t1,1, . . . , t3,100) tc. t ∈ R

3: T,P = ∅

4: for all m in M do

5: P[m.index] = count(X)[where x == m]

6: end for

7: I = sortIndex(p)

8: for all i in I do

9: for j=1 to 100 do

10: T[i][j] = jm

11: end for

12: end for

13: Return T

In uscita alla funzione Tabella troviamo il file Json di un array di 3 colonne e

100 righe, dove ogni colonna coincide con un cluster individuato.

L’obiettivo è quello di produrre il file Json che contenga i TTC dell’utente ana-

lizzato. Le colonne della tabella restituita sono necessarie per dividere i vettori in

ordine di probabilità decrescente (vengono considerati solo i tre vettori più proba-

bili), ovvero da quello con probabilità maggiore a quello con probabilità inferiore.

Il vettore inserito nella prima colonna, ovvero quello con probabilità maggiore è

quindi quello associato al centroide che presenta cardinalità maggiore; il vettore

inserito nella seconda colonna invece è quello associato al centroide con la secon-

da cardinalità massima e così via per le altre colonne. Lo scopo di questa funzione

è quello di calcolare il tempo necessario per caricare completamente il dispositivo

mobile, ovviamente tenendo in considerazioni i diversi gruppi identificati. Alla

Linea 5 definiamo un array P per memorizzare il numero di elementi di ogni cen-

troide che verranno passati alla funzione come parametri in ingresso. Dopo di

che si definisce un altro vettore I per memorizzare in ordine crescente gli indici


degli elementi del vettore P (Riga 7). Infine possiamo riempire la lista T seguendo

l’ordine specificato nel vettore I. In particolare per ogni vettore inserito nella lista

T vengono calcolati tutti gli elementi (Riga 10 ) dall’ 1 al 100 come inverso del-

la funzione lineare. Una volta completato il vettore T questo viene restituito alla

funzione principale.

Algoritmo 4.4.9 Warning

1: Ingresso: Cs = {c1, . . . , cs}, Bs = {b1, . . . ,bs}, soglia thr

2: Uscita: C = (c11, . . . , c1n), . . . , (cs1, . . . , csl) and Y =

(y11, . . . ,y1n), . . . , (ys1, . . . ,ysl) tc c ∈ Configurazioni e y = livello di

batteria del device

3: for all ci ∈ C do

4: if |ci| < thr then

5: record dei valori di c

6: delete(c)

7: delete(y[c.index])

8: end if

9: end for

10: for all y in Y do

11: if max(y)- min(y) > soglia then

12: record of c[y.index] values

13: delete(y)

14: delete(c[y.index])

15: end if

16: end for

17: Return C, Y

Funzione: Warning L’obiettivo è quello di notificare eventuali errori, memo-

rizzarli in un file di log ed eliminare i vettori che presentano comportamenti ano-

mali. Un comportamento anomalo si verifica ogni qual volta tutti i vettori ciεCs


presentano una cardinalità inferiore a una soglia prefissata o quando la differen-

za tra il primo e l’ultimo valore del vettore corrispondente alla percentuale di

batteria registrata è minore di una particolare soglia. I vettori di configurazioni e

livello di batteria che non sono eliminati durante questa fase verranno riutilizzati

della fase di apprendimento del modello.

La funzione Warning richiede in ingresso due vettori Cs e Bs. Cs è una se-

quenza di vettori, t.c. ogni elemento rappresenta una configurazione mentre Bs è

una lista di vettori t.c. ogni elemento rappresenta un livello di batteria.

La funzione ha in uscita dei sotto insiemi dei vettori passati in ingresso Cs e

Bs.

Alle Righe 5 e 12 ricoprono rispettivamente la fase di memorizzazione nel file

di log e di notifica dei vettori la cui cardinalità è inferiore a una prefissata soglia.

Nelle Righe 6, 7, 13 e 14 avviene l’eliminazione dei dati che erano stati segnalati

come anomali, questa operazione è eseguita in modo da garantire la consistenza

del modello e quindi per prevenirne l’instabilità. Se questi valori fossero consi-

derati si potrebbe infatti registrare un calo delle prestazioni del modello dovuto

all’utilizzo di valori non significativi per il modello come cariche troppo corte in

cui non si verifica un aumento della percentuale di batteria del dispositivo. L’o-

biettivo di questo ciclo è quello di identificare sequenze anomale nell’accezione

in cui la variazione della variabile b rispetto alla cardinalità della sequenza non è

bilanciata. Una volta completate queste operazioni la funzione Warning restitui-

sce i vettori C e Y. Possiamo notare che, nei casi analizzati nella Sezione 5, solo il

3% degli utenti presi in analisi presenta dei comportamenti anomali.


Algoritmo 4.4.10 Ricerca

1: Ingresso: iduser

2: Uscita: TJSon

3: D = ∅

4: C, Y = ∅

5: S,s = ∅

6: D = DBQuery(iduser)

7: C,Y = puliziaDati(D)

8: C,Y = Warning( C, Y)

9: for all c in C do

10: s = leastSquare(c, y[c.index])

11: S = S ∪ s

12: end for

13: X = XMean(S)

14: T = Table(X)

15: Return JSon(T)


Funzione: K-means Alla Linea 13 dell’Algoritmo 4.4.10, viene chiamata la fun-

zione X-mean la quale a sua volta è basata sul famoso algoritmo di K-mean.

L’obiettivo dell’algoritmo K-mean è di identificare insiemi di dati (nel nostro

caso specifico insiemi di vettori) tali per cui i dati appartenenti a un insieme siano

abbastanza simili tra loro.

X-mean migliora l’algoritmo di K-mean in quanto riesce ad identificare il nu-

mero di insiemi che meglio descrive la base di dati. Questo viene effettuato in ma-

niera graduale ovvero partendo da un solo centroide e aumentando di 1 ad ogni

passo dell’algoritmo il numero di centroidi se l’errore quadratico medio calcola-

to risulta inferiore di una soglia rispetto al passo precedente l’algoritmo termina

individuando il numero di centroidi da passare a k-means.

Look up La Funzione di LookUp prende in ingresso uno o più identificati-

vi di utente registrati all’applicazione MPower. In uscita restituisce un file Json.

L’obiettivo di questa funzione, ovvero la funzione principale di tutto l’algoritmo, è

quello di calcolare il file Json che contenga una lista di vettori che rappresentano

il TTC dell’utente passatogli in ingresso attraverso il corrispondente identificati-

vo. Per raggiungere questo obiettivo vengono utilizzate tutte le funzioni prima

descritte. Alla Linea 3 viene dichiarata la variabile D che verrà utilizzata per me-

morizzare tutte le informazioni appartenenti all’identificativo utente passato in

ingresso presenti nella base dati. Alla Linea 4 si definiscono le variabili C e Y che

verrano utilizzate per memorizzare i valori di ritorno della funzione CleanData.

Queste variabili contengono tutte le informazioni necessarie per produrre il file

Json. L’analisi consiste nell’approssimare gli elementi c,y, t.c. c ∈ C e y ∈ Y, con la

minimizzazione dei quadrati relativa a un modello lineare e memorizzare i risul-

tati di tale operazione nel vettore S. A questo punto viene applicato l’algoritmo

di X-mean ai dati appena memorizzati in S in modo da individuare i centroidi e

i valori a loro associati ( Linea 10). Si può quindi eseguire l’ultimo punto dell’a-

nalisi passando al calcolo della lista di vettori T attraverso la funzione Table, la


quale produrrà in output il file Json.

Capitolo 5

Risultati sperimentali

Questo Capitolo presenta le prestazioni degli algoritmi introdotti nel presente

elaborato e ne fornisce un confronto con il modello attuale di MPower e il modello

stimato attraverso l’historian da Android Lollipop.

Prima di presentare i test effettuati andiamo però ad analizzare il dataset di

utenti utilizzato nella valutazione. L’importanza di questa analisi è legata alla

grande diversità di dispositivi mobili registrati nel dataset considerato; ovvia-

mente la presenza di una così ampia gamma di dispositivi ha introdotto una

certa complessità nell’applicazione MPower in quanto si sono dovuti affrontare

problemi di compatibilità tra le diverse versioni del S.O..

Gli utenti che al momento utilizzano MPower sono circa 600. Si è deciso di

classificarli attraverso le seguenti categorie:

• Brand: questa informazione, rappresentata in Figura 5.1, va ad indicare la

varietà di dispositivi analizzati e quindi di architetture analizzate;

• Modello: questa informazione, rappresentata in Figura 5.2, va ad integrare

il grafico precedente, per ogni brand abbiamo infatti un numero elevato di

dispositivi;

• S.O.: questa informazione, rappresentata in Figura 5.3, va ad indicare la

varietà di S.O. presenti sui dispositivi monitorati.

87

88 CAPITOLO 5. RISULTATI SPERIMENTALI

Figura 5.1: Rappresentazione dei brand più acquistati dagli utenti di MPower (febbraio 2015)

Figura 5.2: Rappresentazione dei dispositivi più acquistati dagli utenti di MPower (febbraio 2015)

5.1. VALUTAZIONE DEL TEMPO DI AUTONOMIA PREDETTO 89

Figura 5.3: Rappresentazione dei S.O. presenti nei dispositivi monitorati da MPower (febbraio 2015)

Tutti i dati raccolti sul dataset appena presentato sono stati divisi in modo da

utilizzare il 75% dei campioni per calcolare i parametri dei modelli e il 25% per

valutarli.

Il presente Capitolo viene quindi strutturato nel seguente modo:

• Sezione 5.1: presenta le metriche utilizzate per la valutazione del TTL e i

risultati ottenuti, fornisce inoltre un confronto con le prestazioni di Android

Lollipop;

• Sezione 5.2: presenta le metriche utilizzate per la valutazione del TTC e i

risultati ottenuti;

5.1 Valutazione del tempo di autonomia predetto

5.1.1 Figure di merito

In questa Sezione andiamo ad analizzare le prestazioni del modello relativo al

TTL rispetto alle metriche presentate in tabella 5.1 e che andiamo ora a descrivere:


• Punto Finale (P.F.): questa metrica rappresenta la differenza dei valori as-

sunti nel punto finale tra le curve predette dal modello MPower attuale e dai

modelli presentati in questa tesi rispetto alla curva reale registrata. Questa

informazione è di particolare importanza per l’utente finale in quanto forni-

re il tempo di autonomia del dispositivo è una delle funzionalità principali

di MPower;

• Errore quadratico medio (m.s.e.): questa metrica indica quanto le curve

predette dai modelli presi in considerazione durante l’analisi si allontanino

mediamente dalla curva reale registrata. Più il valore di questo parametro è

piccolo più la nostra predizione si avvicinerà alla curva reale.

• Errore medio puntuale (m.e.p.): questa metrica rappresenta quanto le curve

predette dai modelli presi in considerazione durante l’analisi si allontanano,

in ogni punto, dalla curva reale. Anche in questo caso più il valore di questo

parametro è piccolo più l’errore introdotto in ogni punto sarà trascurabile.

• Errore quadratico medio relativo alla pendenza (m.m.s.e.): questa metrica

indica quanto la pendenza delle curve predette dai modelli presi in conside-

razione durante l’analisi differisce, mediamente, dalla curva reale. Questa

informazione è di particolare importanza in quanto va ad indicare quanto si

riescano a predire le abitudini dell’utente, focus centrale del presente lavo-

ro. Può infatti capitare il caso che m.s.e. assuma un valore elevato in quanto

è presente un distaccamento dalla curva reale iniziale o finale molto elevato

ma che il m.m.s.e. sia molto basso.

• Errore medio puntuale relativo alla pendenza (m.m.e.p.):questa metrica

indica quanto la pendenza delle curve predette dai modelli presi in consi-

derazione durante l’analisi differisce, in ogni punto, dalla curva reale. Pos-

siamo quindi affermare che questa metrica rappresenti l’errore introdotto

ad ogni punto predetto rispetto le abitudini dell’utente; come per le varia-


bili precedente è necessario ottenere un valore basso per avere delle buone

prestazioni.

Tabella 5.1: Metriche utilizzate per la valutazione del TTL

Metrica Sigla Formula Unità di misura

Punto finale pf |yr,f − ym,f| %

Errore quadratico medio m.s.e. Σi(yr,i − ym,i)2 %2

Errore medio puntuale m.e.p. Σni

|yr,i−ym,i|

n %

Errore quadratico medio della pendenza m.m.s.e. Σiatan(mr,i −mm,i)2 gradi2

Errore medio puntuale della pendenza m.m.e.p. Σni

tg|mr,i−mm,i|

n gradi

5.1.2 Base di dati

Andiamo ora ad analizzare come le figure di merito appena esposte sono state

utilizzate nella base di dati precedentemente citata.

L’analisi è stata condotta a due livelli di dettaglio:

• per utente: questa analisi, condotta su circa 600 utenti, ci permette di ef-

fettuare una prima analisi a grana grossa dell’andamento degli algoritmi

presentati.

• per curva di scarica: questa analisi, condotta su circa cento mila curve, ci

permette di avere una visione dettagliata e puntuale dell’andamento degli

algoritmi presentati.

Il secondo tipo di analisi permette di effettuare un’analisi più accurata in

quanto permette di valutare i singoli andamenti e non mediare sull’andamento

generale dell’utente. Si è quindi deciso di differenziale l’analisi applicando diffe-

renti politiche per la scelta delle curve di scarica da valutare. In particolare si è

scelto di analizzare:

• tutto il dataset: questo test è stato utilizzato per fornire una visione generale

sull’andamento degli algoritmi precedentemente descritti


• tutte le cariche che presentano una differenza in termini di percentuali

batteria compresa tra 0% e 30%: questo test è stato utilizzato per fornire una

visione generale sull’andamento degli algoritmi precedentemente descritti

in un contesto a breve termine

• tutte le cariche che presentano una differenza in termini di percentua-

li batteria compresa tra 30% e 80%: questo test è stato utilizzato per for-

nire una visione generale sull’andamento degli algoritmi precedentemente

descritti in un contesto a medio termine

• tutte le cariche che presentano una differenza in termini di percentuali

batteria compresa tra 80% e 100%: questo test è stato utilizzato per for-

nire una visione generale sull’andamento degli algoritmi precedentemente

descritti in un contesto a lungo termine

5.1.3 Risultati

In questa Sezione andiamo a presentare i risultati ottenuti. Gli esperimenti

condotti sono stati effettuati utilizzando il Modello attuale (MA) di MPower, i

modelli: Modello giornaliero (MG), Modello orario (MO), e Modello dinamico

(MD) di Markov e il modello implementato per l’historian table di Google. Que-

st’ultimo confronto verrà presentato in una Sezione a parte. Per chiarezza espo-

sitiva abbiamo deciso di presentare per ogni dataset una tabella riassuntiva dei

risultati relativi al test sulle curve di scarica e un commento dei risultati. Poichè i

modelli di Markov non sono modelli deterministici andiamo a riportare il valore

medio ottenuto su 10 esecuzioni dell’algoritmo e le relative deviazioni standard.

Riteniamo che 10 sia un numero sufficientemente elevato per avere una buona

approssimazione in quanto la deviazione standard relativa alla maggior parte

dei modelli presentati è molto piccola. Nella tabella dei risultati abbiamo inoltre

inserito tre colonne di confronto che ci permettono di esprimere il miglioramento

percentuale introdotto rispettivamente dagli algoritmi giornaliero, orario e dina-


mico rispetto al modello attuale di MPower. Le celle di queste colonne sono colo-

rate rispecchiando la politica presentata in Figura 5.4; ovvero quando il confronto

tra uno dei modelli presentati in questa tesi e il modello attuale di MPower porta

a un peggioramento delle prestazioni maggiore del 5% la cella viene colorata di

rosso scuro mentre quando il peggioramento è inferiore al 5% la cella è colorata di

rosso chiaro. Quando il confronto porta a un miglioramento sono utilizzati i colori

verde chiaro e verde scuro che rappresentano rispettivamente un miglioramento

inferiore al 5% e un miglioramento superiore al 5%.

Figura 5.4: Indice dei colori utilizzati nella tabella di valutazione dei risultati ottenuti

Risultati: tutte le curve del dataset Questo confronto può essere considerato

il più importante in quanto permette di valutare se la scelta di tenere in consi-

derazione il comportamento dell’utente per il calcolo del TTL ha portato degli

effettivi miglioramenti. Questa scelta, come si può osservare dalla Tabella 5.2,

porta effettivamente un miglioramento per tutte le metriche considerate. Possia-

mo quindi affermare che il comportamento dell’utente e le sue abitudini sono una

componente rilevante nell’analisi del TTL.

Osservando i risultati, si può notare che le prestazioni migliori sono raggiunte

con il modello giornaliero; il quale però presenta una deviazione standard di un

ordine di grandezza maggiore rispetto a gli altri modelli. Questo va ad indicare

che il modello giornaliero ha un comportamento molto più variabile rispetto a

quello degli altri modelli. Il modello dinamico è invece quello che raggiungere

un compromesso migliore tra prestazioni e deviazione standard.


Tabella 5.2: Risultati ottenuti confrontando tutte le curve di scarica

Metrica MA MA vs. media std MA media std MA vs. media std

MG MG MG vs. MO MO MO MD MD MD

m.s.e. 334,5 16,2 % 280 7,73 8,97 % 304,49 0,37 9,25 % 303,54 0,87

m.e.p. 11,1 4,4 % 10,61 0,065 3,42 % 10,72 0,0075 3,6 % 10,7 0,014

m.m.s.e. 126,6 13,7 % 109,2 3,16 4,75 % 120,58 0,15 4,73 % 120,61 0,17

m.m.e.p. 8,1 4 % 7,77 0,078 0,86 % 8,03 0,004 0,74 % 8,04 0,0047

P.F. 15 0,66 % 14,9 0,026 2,6 % 14,61 0,0075 2,4 % 14,64 0,015

Risultati: tutte le cariche con lunghezza compresa tra 0% e 30% L’importan-

za di questa categoria di test è legata alla valutazione della predizione nel breve

periodo. Anche in questo caso, come nell’analisi precedente, il modello giornalie-

ro presenta i miglioramenti più significativi rispetto al modello attuale di MPo-

wer ma a differenza del caso precedente la deviazione standard rimane limitata.

I risultati ottenuti suggeriscono di utilizzare il modello giornaliero per il calco-

lo di curve di scarica nel breve periodo, ovvero che la cui previsione non debba

superare una differenza nella percentuale di batteria pari al 30%.

Tabella 5.3: Risultati ottenuti confrontando le curve di scarica di lunghezza compresa tra 0% e 30%



m.s.e. 187,63 15,12 % 159,25 2,66 10,27 % 168,36 0,54 10,08 % 168,71 0,81

m.e.p. 7,42 2,29 % 7,25 0,023 2,69 % 7,22 0,0082 2,69 % 7,22 0,013

m.m.s.e. 125,33 16,58 % 104,55 3,49 6,7 % 116,93 0,19 6,45 % 117,24 0,25

m.m.e.p. 8,09 5,56 % 7,64 0,086 2,1 % 7,92 0,0073 1,97 % 7,93 0,0066

P.F. 12,23 0,24 % 12,2 0,035 3,02 % 11,86 0,011 2,94 % 11,87 0,021

Risultati: tutte le cariche con lunghezza compresa tra 30% e 80% Questo caso,

come precedentemente esposto, prende in considerazione tutte le curve di media


lunghezza. I risultati, riportati in Tabella 5.4 mostrano che il modello giornaliero

presenta i risultati migliori per tutte le metriche considerate. Dalla stessa tabel-

la di può inoltre notare che la deviazione standard associata a tale modello è di

un ordine di grandezza maggiore rispetto alle deviazioni standard dei modelli

orario e dinamico. Questo va ad indicare che il modello giornaliero ha un com-

portamento molto più variabile rispetto a quello degli altri modelli. In quanto il

modello dinamico approssima la curva (parametro relativo all’errore quadratico

medio) con più precisione rispetto al modello orario e una deviazione standard

comparabile a quest’ultimo si può utilizzare come modello per la predizione di

curve il cui punto iniziale sia compreso tra l’80% e il 30%.

Tabella 5.4: Risultati ottenuti confrontando le curve di scarica di lunghezza compresa tra 30% e 80%



m.s.e. 482,33 19,94 % 386,13 16,12 8,83 % 439,71 1,01 9,53 % 436,35 1,035

m.e.p. 15,04 9,9 % 13,55 0,24 4,58 % 14,35 0,021 4,85 % 14,31 0,021

m.m.s.e. 130,07 11,3 % 115,35 3 2,8 % 126,31 0,22 3 % 126,17 0,22

m.m.e.p. 8,31 4,33 % 7,95 0,07 1,08 % 8,22 0,0049 1,2 % 8,21 0,0064

P.F. 20,23 8,89 % 18,43 0,22 6,12 % 18,99 0,021 5,93 % 19,03 0,02

Risultati: tutte le cariche con lunghezza compresa tra 80% e 100% in questa

sezione si considerano tutte e sole le curve a lungo periodo, ovvero quelle in cui

la predizione del TTL presenti un punto iniziale di scarica pari almeno all’80%.

In questo caso il modello giornaliero presenta un errore quadratico medio molto

basso rispetto al modello attuale di MPower, abbiamo infatti una riduzione del

26% del valore di errore relativo a tale metrica. Per il punto finale invece il mo-

dello giornaliero ha prestazioni inferiori al modello attuale. Questo è spiegabile

dal fatto che le abitudini degli utenti cambiamo durante la giornata. E’ quindi

necessario ridurre la granularità dell’analisi al valore di un ora.


Il modello orario, come nei casi precedenti, ha le prestazioni peggiori e per

questo verrà scartato. Ancora una volta il modello dinamico è quello che permette

una migliore modellazione delle fasce a lungo termine.

Tabella 5.5: Risultati ottenuti confrontando le curve di scarica di lunghezza compresa tra 80% e

100%



m.s.e. 677,6 26 % 500,9 37,48 7,15 % 629,12 1,28 7,41 % 627,35 1,59

m.e.p. 19,2 13,75 % 16,56 0,51 4,375 % 18,36 0,026 5 % 18,24 0,029

m.m.s.e. 120,19 9,79 % 108,42 2,95 0,391 % 119,72 0,12 1,36 % 118,55 0,19

m.m.e.p. 8 3,25 % 7,74 0,05 0,625 % 7,95 0,0053 0,875 % 7,93 0,006

P.F. 14,58 -3,01 % 15,02 0,36 5,82 % 13,73 0,049 5,55 % 13,77 0,04

Risultati: analisi di tutti gli utenti del dataset In questo paragrafo andiamo a

fornire un analisi del dataset prendendo come unità di misura non più la singola

curva di scarica come nei casi precedenti ma l’andamento medio di un utente.

Anche in questo caso sono state utilizzate tutte le figure di merito ( Tabella 5.1)

precedentemente presentate. Per questa analisi si è utilizzata una rappresentazio-

ne grafica attraverso boxplot. Questa scelta permette sia di avere un idea generale

immediata dell’andamento dei modelli introdotti rispetto al modello attuale ma

anche di avere un idea della distribuzione dei dati. Per ogni metrica riportiamo

anche il grafico relativo a tutte le curve di scarica. Questo confronto è di parti-

colare importanza in quanto mostra come i miglioramenti introdotti dai modelli

vengono realmente percepiti dall’utente.

Nelle Figure 5.5, 5.6, 5.7, 5.8, 5.9 abbiamo presentato 10 generazioni differenti

delle curve di scarica fornite dal modello di Markov giornaliero, in quanto la va-

rianza di questo modello è molto elevata, al modello di Markov orario e a quel-

lo dinamico e al modello attuale di MPower. Le Figure rappresentano rispetti-

vamente l’errore quadratico medio, l’errore medio puntuale, l’errore quadratico


medio relativo alla pendenza, l’errore medio puntuale relativo alla pendenza e

il punto finale. Quello che si può immediatamente notare da tutte le figure è la

forma schiacciata verso il basso dei boxplot e la lunghezza del basso destro e la

forte dispersione degli outlier. Questo indica che la distribuzione analizzata non

è gaussiana in quanto non abbiamo un posizionamento simmetrico dei baffi e dei

quartili e che il 75% degli utenti ha un errore inferiore rispetto a quello medio

precedentemente presentato; questo è dovuto al restate 25% dei dati che influisce

sensibilmente nel peggiorare l’andamento medio dei risultati.

Si può inoltre notare che l’andamento rispecchia i risultati precedentemente

presentati per tutte le curve di scarica ovvero il modello giornaliero presenta i mi-

glioramenti maggiori rispetto al modello attuale di MPower, ma la sua varianza

è elevata. Il modello orario e quello dinamico invece forniscono dei piccoli mi-

glioramenti relativi sia alla media che alla distribuzione dei dati: possiamo infatti

notare che i quartili hanno una forma più schiacciata e anche i baffi sono più corti

di quelli del modello attuale. Possiamo quindi affermare che tutti i modelli pre-

sentati hanno dei miglioramenti più o meno accentuati rispetto al modello attuale

di MPower.


M.G.1

M.G.2

M.G.3

M.G.4

M.G.5

M.G.6

M.G.7

M.G.8

M.G.9

M.O.

M.A.

M.D.

M.G.1 M.G.2 M.G.3 M.G.4 M.G.5 M.G.6 M.G.7 M.G.8 M.G.9 M.O. M.A. M.D.

(a) Errore quadratico medio relativo a tutti gli utenti

M.G.1

M.G.2

M.G.3

M.G.4

M.G.5

M.G.6

M.G.7

M.G.8

M.G.9

M.O.

M.A.

M.D.


(b) Errore quadratico medio relativo a tutte le curve

Figura 5.5: Errore quadratico medio


M.G.1

M.G.2

M.G.3

M.G.4

M.G.5

M.G.6

M.G.7

M.G.8

M.G.9

M.O.

M.A.

M.D.


(a) Errore medio puntuale relativo a tutti gli utenti

M.G.1

M.G.2

M.G.3

M.G.4

M.G.5

M.G.6

M.G.7

M.G.8

M.G.9

M.O.

M.A.

M.D.


(b) Errore medio puntuale relativo a tutte le curve

Figura 5.6: Errore medio puntuale


M.G.1

M.G.2

M.G.3

M.G.4

M.G.5

M.G.6

M.G.7

M.G.8

M.G.9

M.O.

M.A.

M.D.


(a) Errore quadratico medio della pendenza relativo a tutti gli utenti

M.G.1

M.G.2

M.G.3

M.G.4

M.G.5

M.G.6

M.G.7

M.G.8

M.G.9

M.O.

M.A.

M.D.


(b) Errore quadratico medio della pendenza relativo a tutte le curve

Figura 5.7: Errore quadratico medio della pendenza


M.G.1

M.G.2

M.G.3

M.G.4

M.G.5

M.G.6

M.G.7

M.G.8

M.G.9

M.O.

M.A.

M.D.


(a) Errore medio puntuale della pendenza relativo a tutti gli utenti

M.G.1

M.G.2

M.G.3

M.G.4

M.G.5

M.G.6

M.G.7

M.G.8

M.G.9

M.O.

M.A.

M.D.


(b) Errore medio puntuale della pendenza relativo a tutte le curve

Figura 5.8: Errore medio puntuale della pendenza


M.G.1

M.G.2

M.G.3

M.G.4

M.G.5

M.G.6

M.G.7

M.G.8

M.G.9

M.O.

M.A.

M.D.


(a) Punto finale relativo a tutti gli utenti

M.G.1

M.G.2

M.G.3

M.G.4

M.G.5

M.G.6

M.G.7

M.G.8

M.G.9

M.O.

M.A.

M.D.


(b) Punto finale relativo a tutte le curve

Figura 5.9: Punto finale


5.1.4 Confronto tra MPower e Android Lollipop

In questa Sezione andiamo a confrontare il tempo di autonomia previsto dalla

funzionalità historian table introdotta da Android Lollipop e il tempo di autono-

mia previsto dall’applicazione MPower.

Poiché non sono state pubblicate delle API ufficiali che permettessero di leg-

gere il dato relativo al tempo di autonomia interrogando il sistema operativo del

dispositivo mobile, è stato implementato un script bash che a cadenza di 10 mi-

nuti si collega a due dispositivi mobili monitorati ed estrae le informazione ne-

cessarie all’analisi. Per far questo lo script apre la schermata relativa al consumo

di batteria e ne trasmette uno screenshot al computer sul quale sta girando lo

script. A questo punto, viene invocato un secondo script Python estrae l’infor-

mazione relativa al tempo di autonomia del dispositivo, effettuando una lettura

OCR dell’immagine.

Il dataset utilizzato per questa analisi, come anticipato, è composto da soli due

dispositivi e da 20 curve di scarica, per questo motivo non è stata effettuata una

divisione delle curve rispetto alla percentuale di scarica registrata.

Anche in questo caso sono state valutate tutte le figure di merito preceden-

temente esposte. In particolare in Tabella 5.6 è riportato l’andamento medio con

relativa deviazione standard della predizione effettuata da MPower e da quel-

la effettuata da Android Lollipop. Come nel caso precedente è anche presente

una colonna aggiuntiva che presenta il miglioramento percentuale ottenuto da

MPower.


Tabella 5.6: Risultati ottenuti confrontando Android Lollipop e MPower

Metrica A.L. std A.L. vs. media std A.L. media std A.L. vs. media std

A.L. MG MG MG vs. MO MO MO MD MD MD

m.s.e. 956.04 1823.68 49.09% 486.68 474.4 48.72% 490.17 522.97 47.54% 501.46 539.89

m.e.p. 118.59 24.22 9.84 % 16.76 10.76 9.89% 16.75 10.69 9.86 % 16.75 11.22

m.m.s.e. 139.18 189.32 59.35% 56.57 37.67 60.20% 55.39 35.19 60.64% 54.77 36.72

m.m.e.p. 7.08 4.89 15.81% 5.96 1.96 16.80% 5.89 1.85 19.49% 5.7 2.08

P.F. 17.06 13.48 -19.92% 20.46 11.88 -23.03% 20.99 12.56 -21.39% 20.71 13.35

Ricordando l’esigua quantità di dati utilizzata per effettuare la valutazione

quello che si può notare dai risultati ottenuti è che il modello attuale di MPower

migliora sensibilmente il modello riportato da Android Lollipop nelle metriche

che vanno ad insistere sull’approssimazione della curva. Questo è spiegabile dal

fatto che il modello Android Lollipop, come il modello attuale di MPower effettua

una regressione sui dati senza cercare di capire l’andamento della curva. Si può

inoltre notare che però, nelle poche curve a disposizione, il modello Android Lol-

lipop riesce a prevedere il punto finale delle curve di scarica con una precisione

superiore rispetto al modello presentato in questa tesi.

5.2 Valutazione del tempo di carica

In questa Sezione andiamo ad analizzare le prestazioni del modello relativo

al TTC.

Figure di merito In Tabella 5.7 sono riportate le figure di merito utilizzate per

la valutazione del TTC

5.2. VALUTAZIONE DEL TEMPO DI CARICA 105

Tabella 5.7: Figure di merito utilizzate per la valutazione del TTC

Metrica Sigla Formula Unità di misura

Punto finale pf |yr,f − ym,f| %

Errore quadratico medio m.s.e. Σi(yr,i − ym,i)2 %2

Errore medio puntuale m.e.p. Σni

|yr,i−ym,i|

n %

Per la validazione delle figure di merito appena presentate abbiamo diviso i

dati raccolti in modo che il 75% venisse utilizzato nel calcolo dei parametri del

modello mentre il restante 25% per la valutazione delle prestazioni.

Risultati : la metodologia presentata, come spiegato nel capitolo 4, produce co-

me risultato più modelli, uno per ogni andamento di carica riconosciuto. Questa

informazione viene passata all’applicazione MPower; la quale ha quindi a dispo-

sizione i dati relativi ai tre modelli più probabili. Per semplicità si è però scelto

scelto di mostrare all’utente finale solo le informazioni legate al modello più pro-

babile, detto Modello base di carica (M.C.). L’unico modo che avrebbe l’applica-

zione di riconoscere, durante la fase di carica, quale modello visualizzare all’uten-

te sarebbe quello di monitorare la curva per i primi istanti. Poiché questa è una

limitazione dell’applicazione e non del modello, si è scelto di valutare anche le

prestazioni che si otterrebbero introducendo la fase di monitoraggio nell’applica-

zione. Andiamo quindi a presentare anche risultati che si ottengono monitorando

l’andamento della curva di carica per 1 minuto e per 5 minuti. In questi casi du-

rante la fase di monitoraggio il modello segue l’andamento più probabile e poi

si sposta sul modello che più si avvicina al comportamento reale; chiameremo

questi due casi rispettivamente Modello di carica a 1 minuto (M.C.1) e Modello

di carica a 5 minuti (M.C.5).

La Tabella dei risultati 5.8 presenta inoltre il miglioramento percentuale intro-

dotto dalla fase di monitoraggio. Per un interpretazione più veloce dei risultati si


sono adottati dei colori di valutazione riportati in Figura 5.10.

Figura 5.10: Indice dei colori utilizzati nella tabella di valutazione dei risultati ottenuti

Tabella 5.8: Risultati ottenuti relativi al modello del TTC

Metrica M.C. std M.C. vs M.C.1 std M.C. vs M.C.5 std

M.C.1 M.C.5

m.s.e. 233,3 749,6 20,0 % 186,8 587,3 32,0 % 157,7 569,6

m.e.p. 6,7 11,2 5,0 % 6,4 9,8 20,0 % 5,4 9,1

P.F. 12,4 18,8 5,7 % 11,7 16,7 16,9 % 10,3 15,8

Come si può vedere dalla Tabella 5.8 il modello M.C. ha le prestazioni peg-

giori. La fase di monitoraggio produce infatti dei miglioramenti in tutte le figure

di merito considerate. Il modello M.C.1 riesce infatti ad abbattere del 20% l’errore

quadratico medio, ovvero quella metrica che va ad indicare quanto il modello sia

aderente alla curva registrata. E’ però il modello M.C.5 a produrre i risultati mi-

gliori; in questo caso infatti è possibile riconoscere con precisione assoluta quale

modello deve essere utilizzato tra quelli disponibili.

Come ultima osservazione possiamo notare che il modello di carica, a pari-

tà di metrica, riesce ad approssimare meglio il comportamento della curva reale

rispetto al modello di scarica. Il motivo di questa maggior precisione è riconduci-

bile al fatto che il comportamento dell’utente, ovvero la componente aleatoria nel

modello relativo al TTL, non influenza il comportamento del dispositivo mobile

durante le operazioni di carica del cellulare.

Capitolo 6

Conclusioni

MPower nasce con l’obiettivo di aiutare gli utenti nella gestione energetica dei

propri dispositivi mobili. Per raggiungere questo obiettivo fornisce all’utente due

tipi di informazione: il tempo di autonomia reale del dispositivo mobile e il tempo

di autonomia ipotetico che si raggiungerebbe se l’utente andasse a modificare

alcune impostazioni del proprio cellulare.

L’informazione relativa al tempo di autonomia viene calcolata utilizzando un

modello di potenza, ovvero un particolare modello matematico che permette di

fare previsioni sullo stato futuro della batteria e, di conseguenza, sul consumo

energetico del dispositivo mobile monitorato. Tali modelli vengono calcolati, do-

po un periodo di osservazione, rispetto ai consumi energetici registrati da alcuni

componenti hardware del dispositivo. Dopo alcune analisi sperimentali si è in-

fatti constatato che i consumi della batteria erano riconducibili quasi totalmente

all’utilizzo dei moduli wi-fi, bluetooth, di rete, di chiamata e alla luminosità dello

schermo. Poichè i consumi di questi componenti variano a seconda del modello

utilizzato e dal S.O. che li gestisce, è stato necessario calcolare un modello per

ogni dispositivo che avesse scaricato l’applicazione.

Questa tesi nasce dalla necessità di rilassare le ipotesi sulle quali era stato fon-

dato il modello attuale di potenza e di completare le informazioni fornite dall’ap-

plicazione MPower all’utente per la gestione energetica del proprio dispositivo.

107

108 CAPITOLO 6. CONCLUSIONI

Si sono quindi affrontato tre punti principali:

Introduzione del comportamento dell’utente nel modello: il modello attua-

le di MPower fornisce una stima del TTL basandosi sull’ipotesi che l’utente non

modifichi mai le impostazioni del proprio dispositivo mobile. Considera quindi

solo i consumi energetici delle componenti hardware monitorate e non tiene in

considerazione possibili variazioni nei consumi energetici legati all’utilizzo del

dispositivo da parte dell’utente. Poiché numerosi studi hanno dimostrato che

il comportamento dell’utente, a parità di dispositivo, è un fattore determinante

nei consumi del dispositivo si è pensato di introdurre questa informazione nel

modello di potenza attuale al fine di migliorare la precisione del modello.

Introduzione del concetto di TTC: questo ultimo punto viene aggiunto per

andare a completare le funzionalità base fornite dall’applicazione MPower. L’o-

biettivo del progetto MPower è infatti quello di fornire all’utente finale uno stru-

mento che faciliti la gestione dei consumi energetici nei dispositivi mobili. Rite-

niamo quindi che per avere una visione completa dei consumi sia necessario co-

noscere, insieme al tempo di autonomia, anche il tempo necessario per ricaricare

completamente il dispositivo; definiamo tale tempo TTC.

In particolare il primo problema è stato affrontato andando ad eliminare l’i-

potesi che l’utente non cambiasse mai le impostazioni del proprio dispositivo.

Questa ipotesi è stata eliminata andando a definire una metodologia che fosse in

grado di adattarsi rispetto alle abitudini dell’utente. Lo scopo di questa metodo-

logia è quindi quello di modellizzare il comportamento dell’utente e, basandosi

sui risultati forniti dal modello attuale di MPower, fornire una stima accurata del

TTL. Tra le diverse opzioni disponibili è stato deciso di sfruttare un modello già

ampiamente utilizzato in numerosissimi campi: le catene di Markov. Poiché le

catene di Markov sono modelli indipendenti dal tempo, si sono sviluppati tre

algoritmi distinti che cercassero di introdurre nell’analisi il concetto di tempo,

fondamentale per lo studio del comportamento dell’utente. I modelli creati sono

quindi:Modello giornaliero, Modello orario e Modello dinamico.

109

Il secondo problema viene invece risolto attraverso l’introduzione di un se-

condo modello di potenza che fornisce informazioni sul tempo di carica dei di-

spositivi mobili. Il modello lineare introdotto è stato scelto dopo un’accurata ana-

lisi dei dati raccolti dall’applicazione MPower. Come nel caso del TTL si è cercato

di identificare le componenti hardware, quali modulo wifi o di rete, che maggior-

mente impattassero durante la carica del dispositivo. Si è ipotizzato che un loro

utilizzo potesse consumare una quantità di energia tale da aumentare il tempo

necessario per ricaricare il proprio dispositivo mobile. Dopo un’analisi sperimen-

tale si è invece scoperto che questa ipotesi non era verificata, il tempo di carica

dei dispositivi mobili è indipendente dall’utilizzo del dispositivo, dipende solo

dalla quantità di corrente che viene fornita in ingresso. Poiché questo parametro

dipende solamente dal caricabatterie utilizzato (ad esempio un caricabatterie da

muro fornisce in ingresso un voltaggio doppio rispetto a una porta usb), si è defi-

nita una metodologia che andasse a costruire un modello per ogni trend di carica

individuato.

Le metodologie appena descritte sono state sviluppate e valutate attraverso 5

figure di merito per il TTL, e 3 figure di merito per il TTC.

Per quanto riguarda il TTL, sono sono ottenuti dei miglioramenti in tutti i

modelli presentati: in particolare si è potuto osservare che il modello giornaliero

ha raggiunto le prestazioni migliori per le curve di lunghezza inferiore al 30%; il

modello dinamico invece ha ottenuto i risultati migliori per le curve di lunghezza

maggiore al 30%. I modelli orario e dinamico inoltre presentano una deviazio-

ne standard molto piccola: questo sta ad indicare che basta un’unica esecuzione

dell’algoritmo per ottenere un risultato significativo per l’utente finale. La dif-

ferenza tra i modelli consigliati per curve medio-lunghe rispetto a curve corte è

legato sopratutto alla variazione delle abitudini dell’utente durante la giornata.

Nei modelli che considerano il tempo infatti questo aspetto ha un peso maggiore.

Per la valutazione del TTC sono stati presi in considerazione tre modelli: il

modello presentato da MPower all’utente finale, il modello che si riconoscerebbe


dopo 1 minuto di campionamento e quello che si riconoscerebbe dopo 5 minuti

di campionamento. Si può notare che il modello più probabile, ovvero quello

presentato all’utente, ha una buona approssimazione delle curve reali di cari-

ca, ma se si introducesse una fase di riconoscimento a 5 minuti, si avrebbe un

miglioramento medio tra il 20% e il 30% in tutte le metriche considerate.

Concludiamo andando ad elencare i possibili lavori futuri, ovvero tutte quelle

migliorie che potrebbero portare dei vantaggi al progetto MPower:

• Sviluppo dell’applicazione MPower per altri sistemi operativi quali iOS8

o WindowsPhone. In questo modo si andrebbe a coprire la quasi totalità dei

dispositivi attualmente disponibili sul mercato mondiale;

• Lo sviluppo di un meccanismo di monitoraggio per il tempo di carica.

In questo modo si potrebbe fornire all’utente un informazione più precisa

rispetto a quella attuale per il TTC

• Il modello attuale di MPower crea, per ogni possibile configurazione con-

trollata dall’utente e quindi wifi, bluetooth, ... diversi modelli di scarica, più

in particolare uno per ogni tipo di rete registrata dal telefono. Questo viene

effettuato in quanto il tipo di rete a cui è connesso il dispositivo è una delle

principali fonti di consumo del dispositivo. Attualmente il modello finale

associato a una configurazione è la media pesata dei modelli prodotti; rite-

niamo che come lavoro futuro si potrebbe sostituire l’attuale calcolo con un

nuovo algoritmo che vada a sfruttare le serie temporali e che questo possa

portare a un miglioramento nella precisione del modello. Tali serie tempora-

li, infatti, rappresentano il comportamento dei componenti controllabili del

dispositivo mobile e di conseguenza le abitudini dell’utente. Si è quindi ef-

fettuato uno studio preliminare al fine di identificare dei pattern di utilizzo

giornalieri e/o settimanali nei dispositivi da parte dell’utente che potessero

fornire un valore più accurato di queste variabili di input. Analizzando il

dataset ci si è accorti che questi pattern esistono realmente. Ad esempio, è

111

stato rilevato che, nelle ore notturne, per la maggior parte degli utenti, il di-

spositivo resta spento o in carica e lo schermo è spento e il modulo wi-fi non

trasmette dati. Si è pertanto deciso di effettuare delle analisi con granulari-

tà al minuto e all’ora dividendo i dati per settimana in modo da garantire

anche l’individuazione dei pattern settimanali. Ciò che è stato individuato

è che il comportamento degli utenti nei weekend è effettivamente diverso,

anche in termine di impostazioni dello smartphone, rispetto al resto del-

la settimana, dove probabilmente sono occupati in attività lavorative o di

studio. I pattern individuati sono caratterizzati da una deviazione standard

massima del 20%. E’ quindi possibile sfruttare questo dato per migliorare il

modello esistente usando come input il valore calcolato che più si avvicina a

quello reale e non più un valore medio della variabile. Questo produrrebbe

un ulteriore miglioramento nelle prestazioni del modello relativo al calcolo

del TTL;

Bibliografia

[1] Smartphone users worldwide will total 1.75 billion

in 2014. http://www.emarketer.com/Article/

Smartphone-Users-Worldwide-Will-Total-175-Billion-2014/

1010536, 16 Jan 2014.

[2] Specifiche tecniche galaxy s3. http://samsung.hdblog.it/

schede-tecniche/samsung-galaxy-s3_i2265/, 2012.

[3] Specifiche tecniche htc evo 4g. http://www.pianetacellulare.it/

Modelli/Htc/Htc_EVO.php, 2011.

[4] Specifiche tecniche iphone 6. https://www.apple.com/it/iphone-6/

specs/, 2014.

[5] Smartphone con la migliore autonomia e durata della batteria, 2014.

[6] Snapdragon batteryguru. https://play.google.com/store/apps/

details?id=com.xiam.snapdragon.app&hl=it, 2014.

[7] Battery doctor (battery saver). https://play.google.com/store/

apps/details?id=com.ijinshan.kbatterydoctor_en&hl=it.

[8] Risparmio batteria saver. https://play.google.com/store/apps/

details?id=apps.ignisamerica.batterysaver&hl=it.

[9] Samsung galaxy s4: Android 5.0 lollipop si mostra a confronto con android

4.4.2 kitkat. http://it.ibtimes.com/articles/72438/20141110/

113

http://www.emarketer.com/Article/Smartphone-Users-Worldwide-Will-Total-175-Billion-2014/1010536



http://samsung.hdblog.it/schede-tecniche/samsung-galaxy-s3_i2265/

http://samsung.hdblog.it/schede-tecniche/samsung-galaxy-s3_i2265/

http://www.pianetacellulare.it/Modelli/Htc/Htc_EVO.php

http://www.pianetacellulare.it/Modelli/Htc/Htc_EVO.php

https://www.apple.com/it/iphone-6/specs/

https://www.apple.com/it/iphone-6/specs/

https://play.google.com/store/apps/details?id=com.xiam.snapdragon.app&hl=it

https://play.google.com/store/apps/details?id=com.xiam.snapdragon.app&hl=it

https://play.google.com/store/apps/details?id=com.ijinshan.kbatterydoctor_en&hl=it

https://play.google.com/store/apps/details?id=com.ijinshan.kbatterydoctor_en&hl=it

https://play.google.com/store/apps/details?id=apps.ignisamerica.batterysaver&hl=it

https://play.google.com/store/apps/details?id=apps.ignisamerica.batterysaver&hl=it

http://it.ibtimes.com/articles/72438/20141110/samsung-galaxy-s4-video-confronto-android-5-0-lollipop-vs- kitkat-differenze-aggiornamento.htm



114 BIBLIOGRAFIA

samsung-galaxy-s4-video-confronto-android-5-0-lollipop-vs-kitkat-differenze-aggiornamento.

htm, 10 Nov 2014.

[10] Alessandra Bonetto, Matteo Ferroni, Domenico Matteo, AA Nacci, M Maz-

zucchelli, Donatella Sciuto, and Marco D Santambrogio. Mpower: towards

an adaptive power management system for mobile devices. In Proceedings

of the 2012 IEEE 15th International Conference on Computational Science and

Engineering, pages 318–325. IEEE Computer Society, 2012.

[11] NECST Lab. Mpower. https://play.google.com/store/apps/

details?id=org.morphone.mpower&hl=it„ 2012.

[12] Kurt Bryan and Tanya Leise. The $25,000,000,000 eigenvector: The linear

algebra behind google. Siam Review, 48(3):569–581, 2006.

[13] Tsvi Kuflik, Zvi Boger, and Massimo Zancanaro. Analysis and predic-

tion of museum visitors behavioral pattern types. In Ubiquitous Display

Environments, pages 161–176. Springer, 2012.

[14] P Solic, N Rozic, and S Marinovic. Rfid-based visitors modeling for galle-

ries using markov model. In Telecommunications, 2009. ConTEL 2009. 10th

International Conference on, pages 105–110. IEEE, 2009.

[15] Fabian Bohnert, Ingrid Zukerman, Shlomo Berkovsky, Timothy Baldwin,

and Liz Sonenberg. Using interest and transition models to predict visitor

locations in museums. AI Communications, 21(2):195–202, 2008.

[16] Vijay Srinivasan, Saeed Moghaddam, Abhishek Mukherji, Kiran K Rachuri,

Chenren Xu, and Emmanuel Munguia Tapia. Mobileminer: Mining your

frequent patterns on your phone. In Proceedings of the 2014 ACM International

Joint Conference on Pervasive and Ubiquitous Computing, pages 389–400. ACM,

2014.

[17] MATTEO FERRONI and ANDREA CAZZOLA. Mpower: on how to

effectively predict the time to live for mobile devices. 2013.





https://play.google.com/store/apps/details?id=org.morphone.mpower&hl=it

https://play.google.com/store/apps/details?id=org.morphone.mpower&hl=it

BIBLIOGRAFIA 115

[18] Power profiles for android. https://source.android.com/devices/

tech/power.html, 2015.

[19] Lide Zhang, Birjodh Tiwana, Zhiyun Qian, Zhaoguang Wang, Robert P Dick,

Zhuoqing Morley Mao, and Lei Yang. Accurate online power estimation

and automatic battery behavior based power model generation for smart-

phones. In Proceedings of the eighth IEEE/ACM/IFIP international conference on

Hardware/software codesign and system synthesis, pages 105–114. ACM, 2010.

[20] Hossein Falaki, Ratul Mahajan, Srikanth Kandula, Dimitrios Lymberopou-

los, Ramesh Govindan, and Deborah Estrin. Diversity in smartphone usage.

In Proceedings of the 8th international conference on Mobile systems, applications,

and services, pages 179–194. ACM, 2010.

[21] Alex Shye, Benjamin Scholbrock, and Gokhan Memik. Into the wild: study-

ing real user activity patterns to guide power optimizations for mobile archi-

tectures. In Proceedings of the 42nd Annual IEEE/ACM International Symposium

on Microarchitecture, pages 168–178. ACM, 2009.

[22] Jiawei Han, Micheline Kamber, and Jian Pei. Data mining, southeast asia

edition: Concepts and techniques. Morgan kaufmann, 2006.

[23] Rakesh Agrawal, Tomasz Imielinski, and Arun Swami. Mining association

rules between sets of items in large databases. In ACM SIGMOD Record,

volume 22, pages 207–216. ACM, 1993.

[24] Rakesh Agrawal, Ramakrishnan Srikant, et al. Fast algorithms for mining

association rules. In Proc. 20th int. conf. very large data bases, VLDB, volume

1215, pages 487–499, 1994.

[25] Mathieu Roche and Oana Mihaela Garbasevschi. Wemit: Web-mining for

translation. In Conference on Prestigious Applications of Intelligent Systems,

pages 993–994, 2012.

https://source.android.com/devices/tech/power.html

https://source.android.com/devices/tech/power.html

116 BIBLIOGRAFIA

[26] Christian Borgelt. An implementation of the fp-growth algorithm. In Pro-

ceedings of the 1st international workshop on open source data mining: frequent

pattern mining implementations, pages 1–5. ACM, 2005.

[27] Christopher M Bishop et al. Pattern recognition and machine learning,

volume 1. springer New York, 2006.

[28] Mitra Baratchi, Nirvana Meratnia, Paul JM Havinga, Andrew K Skidmore,

and Bert AKG Toxopeus. A hierarchical hidden semi-markov model for

modeling mobility data. In Proceedings of the 2014 ACM International Joint

Conference on Pervasive and Ubiquitous Computing, pages 401–412. ACM, 2014.

[29] Moves. http://www.moves-app.com, 2013.

[30] Mistrack, http://www.google.com/mobile/mytracks/. http://www.

google.com/mobile/mytracks/, 23 May 2013.

[31] Rene Mayrhofer, Harald Radi, and Alois Ferscha. Recognizing and predicting

context by learning from user behavior. na, 2003.

[32] T Warren Liao. Clustering of time series data—a survey. Pattern recognition,

38(11):1857–1874, 2005.

[33] Eamonn Keogh, Selina Chu, David Hart, and Michael Pazzani. Segmenting

time series: A survey and novel approach. Data mining in time series databases,

57:1–22, 2004.

[34] Tim Oates, Laura Firoiu, and Paul R Cohen. Clustering time series with hid-

den markov models and dynamic time warping. In Proceedings of the IJCAI-

99 workshop on neural, symbolic and reinforcement learning methods for sequence

learning, pages 17–21. Citeseer, 1999.

[35] Michail Vlachos, Jessica Lin, Eamonn Keogh, and Dimitrios Gunopulos. A

wavelet-based anytime algorithm for k-means clustering of time series. In

http://www.moves-app.com

http://www.google.com/mobile/mytracks/

http://www.google.com/mobile/mytracks/

BIBLIOGRAFIA 117

In Proc. Workshop on Clustering High Dimensionality Data and Its Applications.

Citeseer, 2003.

[36] Johan Himberg, Kalle Korpiaho, Heikki Mannila, Johanna Tikanmaki, and

Hannu TT Toivonen. Time series segmentation for context recognition

in mobile devices. In Data Mining, 2001. ICDM 2001, Proceedings IEEE

International Conference on, pages 203–210. IEEE, 2001.

[37] Richard Bellman. On the approximation of curves by line segments using

dynamic programming. Communications of the ACM, 4(6):284, 1961.

[38] Eamonn Keogh, Selina Chu, David Hart, and Michael Pazzani. An online

algorithm for segmenting time series. In Data Mining, 2001. ICDM 2001,

Proceedings IEEE International Conference on, pages 289–296. IEEE, 2001.

[39] We Are Social. report: Social, digital e mobile in euro-

pa 2014. http://www.slideshare.net/wearesocialit/

social-digital-mobile-in-europa-2014, 2014.

[40] Adel S Sedra and Kenneth Carless Smith. Microelectronic circuits, volume 1.

Oxford university press, 1998.

[41] Anil K Jain. Data clustering: 50 years beyond k-means. Pattern recognition

letters, 31(8):651–666, 2010.

[42] Delbert Hawkins and David Mothersbaugh. Consumer behavior building

marketing strategy. McGraw-Hill, 2009.

[43] Ricardo Cachucho, Marvin Meeng, Ugo Vespier, Siegfried Nijssen, and Ar-

no Knobbe. Mining multivariate time series with mixed sampling rates.

In Proceedings of the 2014 ACM International Joint Conference on Pervasive and

Ubiquitous Computing, pages 413–423. ACM, 2014.

[44] Monsoon power monitor. https://www.msoon.com/LabEquipment/

PowerMonitor/.

http://www.slideshare.net/wearesocialit/social-digital-mobile-in-europa-2014

http://www.slideshare.net/wearesocialit/social-digital-mobile-in-europa-2014

https://www.msoon.com/LabEquipment/PowerMonitor/

https://www.msoon.com/LabEquipment/PowerMonitor/

118 BIBLIOGRAFIA

[45] T Warren Liao. Clustering of time series data—a survey. Pattern recognition,

38(11):1857–1874, 2005.

Denizione e sviluppo di metodologie per la gestione dei ... · Denizione e sviluppo di metodologie...

Documents

Transcript of Denizione e sviluppo di metodologie per la gestione dei ... · Denizione e sviluppo di metodologie...