Strumenti ed Applicazioni di Business Intelligence per Dati - e-Lite

POLITECNICO DI TORINO
Tesi di Laurea Specialistica in Ingegneria
Gestionale
Strumenti ed Applicazioni di
Business Intelligence per Dati
Energetici: un caso di studio al
Politecnico di Torino
Relatori:
prof. Fulvio Corno
prof. Dario Bonino
Candidato:
Matteo Paracchino
Dicembre 2013
Indice
1 Introduzione
1
2 Descrizione dello stato dell’arte in tema di sistemi di gestione energetica degli edifici
4
2.1 Energy Management ed Energy Managers . . . . . . . . . . . . . . . 4
2.2 Smart Buildings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Submetering ed Energy Information Systems . . . . . . . . . . . . . . 8
3 Questioni aperte ed opportunità di lavoro
3.1 Gestione dei flussi di dati . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Qualità dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Fruibilità e comunicazione dei dati . . . . . . . . . . . . . . . . . . .
11
12
13
14
4 Ricerca di una soluzione alle problematiche riscontrate
17
4.1 Obiettivi e scelte preliminari . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Metodologia di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Ricerca preliminare
5.1 Ricerca primaria: questionario esplorativo tra gli energy manger italiani
5.1.1 Progettazione del questionario . . . . . . . . . . . . . . . . . .
5.1.2 Analisi dei risultati . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Ricerca secondaria: analisi della letteratura e delle soluzioni accessibili online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Indagine sulle caratteristiche dei cruscotti di visualizzazione
online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
20
21
22
6 Processo di definizione e sviluppo del prototipo
6.1 Requisiti di progettazione . . . . . . . . . . . . .
6.2 Sviluppo del prototipo dimostratore . . . . . . . .
6.2.1 Strumenti ed architettura selezionati . . .
6.2.2 Progettazione dello schema dei dati . . . .
39
39
41
41
43
ii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
36
6.2.3
6.2.4
6.2.5
Implementazione processo ETL . . . . . . . . . . .
Progettazione e sviluppo delle componenti JSP . .
Progettazione e sviluppo delle dashboard dinamiche
dal server di BI . . . . . . . . . . . . . . . . . . . .
. . . . . . 45
. . . . . . 47
generate
. . . . . . 48
7 Conclusioni e spunti per la prosecuzione del lavoro
55
7.1 Punti deboli e punti di forza connessi allo sviluppo del cruscotto
interattivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.2 Considerazioni generali sugli strumenti utilizzati . . . . . . . . . . . . 57
Bibliografia
60
iii
Capitolo 1
Introduzione
Nata negli anni settanta quando le società occidentali hanno iniziato a confrontarsi
con il tema della limitatezza delle risorse energetiche terrestri, e nonostante abbia
di conseguenza una storia piuttosto breve, la disciplina dell’energy management ha
subito un processo di rapida e inesorabile evoluzione che l’ha portata a cambiare più
volte faccia, fino ad assumere la connotazione strategico-gestionale che la caratterizza
oggi. Traducendo il titolo di una ricerca condotta nel 2012 da Acre Resources, “The
Evolution of the Energy Manager: From Boiler Room to Board Room” [1], si può
comprendere l’entità di questo percorso evolutivo, evidente se si confrontano gli skills
di gestione e la visione strategica richiesti oggi per ricoprire efficacemente il ruolo di
energy manager, con le mansioni prettamente tecniche a cui era relegato alle origini.
Al tempo stesso, è sotto gli occhi di tutti la sempre maggiore pervasività della
tecnologia, e in particolare degli strumenti e applicazioni di information and communication technology, all’interno di qualsiasi aspetto delle nostre vite. Il paradigma
smart (smart-phone, smart-city, smart-grid...) sta diventando il punto di riferimento
di chiunque si occupi di innovazione, e le tematiche di gestione dell’energia, nelle
loro varie forme ed implicazioni, si trovano ad essere inserite appieno in questo contesto. In particolare, attraverso la qualità e la quantità di informazioni che hanno
reso disponibili, le tecniche di smart metering stanno aprendo la strada a modalità
di indagine nuove e interessantissime all’interno delle dinamiche di consumo energetico, trovando un terreno di immediata applicazione nella componente dell’energy
management costituita dalla gestione energetica di edifici o complessi di edifici. Il
potenziale informativo reso disponibile dall’innovazione tecnologica è sotto gli occhi
di tutti, ma per trasformarlo in decisioni più efficaci, efficienti e consapevoli è necessario tenere ben presenti tre ordini di problematiche: quelle legate alla gestione dei
flussi di dati generati, quelle legate alla qualità dei dati stessi e infine quelle legate
alla loro fruibilità per il decisore umano.
Se i primi due aspetti appaiono strettamente connessi all’infrastruttura di raccolta e trasporto dei dati, richiedendo quindi investimenti e tempi di intervento di una
1
1 – Introduzione
certa rilevanza, l’ultimo appare invece affrontabile anche con l’utilizzo di soluzioni
low cost poco invasive dal punto di vista organizzativo ed operativo. Considerando solo l’aspetto della fruibilità, le tematiche da affrontare vengono infatti ristrette
alla rielaborazione e presentazione delle informazioni estratte dalle sorgenti di dati disponibili, con uno sforzo non meno importante dal punto di vista concettuale
e metodologico, ma con lo possibilità di trovare soluzioni attraverso l’impiego di
strumenti accessibili anche con risorse economiche e organizzative limitate.
Quest’ultima affermazione nasce dalla considerazione che sia possibile rendere
maggiormente fruibili i dati energetici, raccolti da una qualsiasi infrastruttura di
metering, attraverso la realizzazione di un tool di visualizzazione dei dati di consumo
basato su un motore di business intelligence e un’applicazione web. La verifica
sperimentale di questa idea si pone esattamente al centro della ricerca presentata in
questa monografia.
Tenuto conto dell’esistenza al Politecnico di Torino di una pur limitata infrastruttura di raccolta dei dati di consumo (principalmente riguardanti l’energia elettrica),
si è cosı̀ pensato di esaminare la validità di un’architettura software basata su componenti freeware ed open source per la realizzazione del sopracitato strumento; nel
fare ciò si è deciso di utilizzare Pentaho come piattaforma di business intelligence,
dal momento che è stato considerato la più affidabile soluzione end-to-end in ambito
open [2].
Punto di partenza nell’analisi è stata un’indagine condotta tra gli energy manager certificati italiani, utile per sondarne le aspettative e le opinioni riguardo gli
strumenti di visualizzazione e analisi dei consumi energetici. Allo stesso tempo, la
ricerca ha avuto anche lo scopo di consolidare ed integrare la ricerca secondaria
svolta consultando la letteratura disponibile ed analizzando le soluzioni accessibili
via web in termini di cruscotti di analisi dei dati energetici. L’output di questo
processo di ricerca preliminare sono state una serie di indicazioni circa le preferenze
di un gruppo di potenziali utenti, che hanno spaziato dalle misure aggregate ritenute più importanti, agli aspetti da considerare per calcolare questi aggregati e per
contestualizzare le analisi, fino alle modalità di presentazione dei dati.
Dopo aver rielaborato e conciliato le informazioni provenienti dai vari canali utilizzati, si è proceduto a definire l’architettura generale dello strumento, individuata
in un’applicazione Jsp attraverso la quale “incorniciare” e pubblicare le elaborazioni
sui consumi, a loro volta prodotte dal server di BI Pentaho usando i dati contenuti
in un db relazionale. In seguito sono state progettate e realizzate le dashboard interattive di analisi dei dati da inserire nell’applicazione jsp, ed è stato configurato il
server di business intelligence per fornire funzioni di drill down. In questa fase si è
provveduto a riesaminare di volta in volta le soluzioni implementate, rielaborando
in modo ricorsivo i vari componenti per adattarli alle problematiche via via riscontrate, fino a ottenere un prototipo funzionante con performance ritenute adeguate a
un utilizzo reale.
2
1 – Introduzione
A valle del processo di progettazione e sviluppo si è infine proceduto a riesaminare
in maniera critica il percorso seguito, facendo emergere vantaggi e svantaggi delle
soluzioni implementate e traendo conclusioni generali a proposito degli strumenti
adottati. Questi ultimi, che come già scritto rappresentavano uno dei focus principali
dell’analisi svolta, hanno dimostrato buone performance in relazione agli obiettivi
del progetto, distinguendosi soprattutto per portabilità e adattabilità, ma denotando
limiti riguardo l’aspetto grafico, i tempi e le modalità di apprendimento, ed una certa
difficoltà nell’estrarne tutto il potenziale. In conclusione, si ritiene di aver dimostrato
la fattibilità, con il solo impiego degli accessibili strumenti adottati, di una soluzione
di business intelligence di dati energetici dal basso total cost of ownership e dalle
prestazioni comparabili a quelle di più celebri suite commerciali; senza dimenticare
come, nell’ottica di una sua effettiva implementazione in ambito non accademico,
restino sicuramente questioni aperte e criticità da esaminare.
3
Capitolo 2
Descrizione dello stato dell’arte in
tema di sistemi di gestione
energetica degli edifici
2.1
Energy Management ed Energy Managers
L’uso razionale delle varie fonti di energia e l’efficienza energetica sono da sempre
al centro dell’attenzione per il mondo dell’industria e del commercio, cosı̀ come per
l’economia domestica di ogni famiglia. L’energy management però è una disciplina
che affonda le proprie radici nel passato abbastanza recente rappresentato delle
crisi petrolifere degli anni settanta, durante le quali per la prima volta le economie
industriali occidentali si sono trovate di fronte alla necessità di ripensare i propri
modelli di consumo energetico in risposta alle crisi causate dalle impennate dei prezzi
del petrolio verificatesi nel 1973 e nel 1979.
Da allora numerose iniziative e programmi di stimolo ad un uso efficiente dell’energia si sono susseguiti in tutto il mondo, con modalità più o meno coordinate e
con risultati più o meno soddisfacenti, ma sicuramente con il merito aver diffuso una
coscienza critica e promosso il dibattito riguardo le fonti di energia, il loro impatto
sulle nostre vite e la loro gestione e conservazione. Ad esempio, proprio nel 1973,
ebbe inizio negli Stati Uniti il Federal Energy Management Program (FEMP), che,
dopo essere nato per interessi strategico/militari di riduzione della dipendenza dal
petrolio straniero attraverso attività di sensibilizzazione alla riduzione dei consumi
e coordinamento tra le varie agenzie governative, si è via via evoluto passando ad
occuparsi di promozione e finanziamento delle tecnologie green negli anni novanta e focalizzandosi nei primi anni duemila sul miglioramento delle performance di
efficienza energetica, sulla sua misurazione e sulla sua promozione [3].
Il significato del termine energy management si è evoluto seguendo gli obiettivi
4
2 – Descrizione dello stato dell’arte in tema di sistemi di gestione energetica degli edifici
che le società in cui viviamo si sono poste nel corso degli anni, come si può vedere
osservando le trasformazioni subite dagli obiettivi del FEMP e come è stato sintetizzato da alcune parole chiave proposte all’inizio degli anni duemila [4] per delineare la
successione degli approcci alla gestione dell’energia che si sono susseguiti nel Regno
Unito:
• “save it” (dal 1973 al 1981): quando in risposta all’impennata dei prezzi del
petrolio ci fu la reazione più semplice ed immediata, una massiccia sensibilizzazione delle persone a ridurre i consumi allo stretto necessario;
• “manage it” (dal 1981 al 1993): quando all’idea di conservazione e risparmio
dell’energia si sostituı̀, per la prima volta, il concetto di gestione e monitoraggio delle fonti energetiche, reso possibile dalle nuove capacità di calcolo
e trattamento dei dati fornite dalla prima ondata di diffusione dei personal
computer, negli anni ottanta;
• “purchase it” (dal 1993 al 2000): quando un periodo abbastanza prolungato di stabilità del prezzo del petrolio e di espansione dell’economia globale
avevano spostato la competizione sul piano del prezzo dell’energia, spingendo
le grandi corporations alla ricerca dell’offerta energetica più economicamente
vantaggiosa mettendo in secondo piano le esigenze di risparmio energetico.
Non meno dinamica è stata la parallela evoluzione, subita nel corso degli ultimi
decenni, della figura dell’energy manager, che è evoluta da un ruolo di nicchia, con
un profilo prettamente tecnico basato sul procurement e la gestione dei macchinari
e delle attrezzature, fino a richiedere competenze che vanno dalla finanza alla visione strategica, con obiettivi di lungo periodo e responsabilità sempre più ampie [1].
Oggi le mansioni di un energy manager possono spaziare dal monitoraggio dei consumi tramite audit interni, report o telecontrollo, all’ottimizzazione dei consumi
stessi promuovendo le azioni correttive adeguate, alla contrattazione per l’acquisto
dell’energia nelle sue varie forme, allo studio di programmi di investimento volti al
miglioramento delle performance energetiche [5], e dimostrano quanto possa essere
decisivo l’impatto di quello che in Italia viene definito “Responsabile per la conservazione e l’uso razionale dell’energia”, secondo la dicitura della legge 10/1991 che
ne ha istituzionalizzato la figura dopo che questa era stata introdotta per la prima
volta con la legge 308/1982.
Un panorama cosı̀ dinamico ha subito un nuovo cambiamento di prospettive a
partire dai primi anni duemila, come conseguenza della crescente sensibilità verso
la sostenibilità ambientale e delle oscillazioni dei prezzi delle risorse energetiche che
tutti abbiamo sperimentato. L’energy management come attività di razionalizzazione e gestione dei consumi è quindi diventato nuovamente (forse come mai prima
5
2 – Descrizione dello stato dell’arte in tema di sistemi di gestione energetica degli edifici
d’ora) uno dei punti chiave sull’agenda programmatica di manager e amministratori
pubblici.
La nuova parola d’ordine è diventata “smart”, ovvero intelligente e brillante, un
aggettivo che è stato associato a quasi tutti componenti dei sistemi energetici: dai
meter, alla rete di distribuzione, agli edifici e alle città intere (qualcuno ha usato
anche il termine smart world). È innegabile che le politiche delle maggiori economie
mondiali, insieme alla ricerca scientifica e alla proposta tecnologica presente sul
mercato si stiano muovendo in questa direzione, e in qualsiasi documento che tratti
degli ultimi ritrovati nel campo delle tecnologie energetiche o della loro prossima
generazione questo aggettivo ricorre decine di volte.
È in corso una terza rivoluzione dell’industria della distribuzione di energia, che
sta segnando in maniera definitiva il modo in cui potrà essere declinato l’energy
management nell’immediato futuro e si può comparare, per portata, alla creazione
delle prime reti elettriche da parte di Thomas Edison ed all’invenzione della trasmissione di corrente alternata su lunghe distanze da parte di Tesla e Westinghouse [6].
L’introduzione di tecnologie ICT all’interno della catena di trasporto dell’energia
sta portando alla convergenza degli interessi e degli sforzi di coloro i quali si occupano di utilities, telecomunicazioni, microelettronica, apparecchiature elettriche,
software, sistemi di controllo ed automazione, sistemi di gestione degli edifici e molti
altri ancora. Attraverso l’infusione di information technology si sta infatti producendo un sistema in grado di operare con modalità molto più evolute e complesse di
quello esistito fino a poco più di un decennio fa, rendendo accessibile una miniera
sconfinata di informazioni e aprendo possibilità di interazione bidirezionale tra tutti
gli attori in gioco.
In questo senso, il concetto di smart può essere interpretato proprio come il passaggio da oggetti con un comportamento fisso e capacità di interazione pressochè
nulle, ad apparecchiature in grado di essere parte in qualche modo attiva del processo
di distribuzione dell’energia, con l’evidente opportunità di ottenere numerose ricadute positive. Ci si attende infatti di ottenere guadagni in termini di: gestione dei
consumi sia a livello privato che a livello pubblico, efficienza energetica, gestione dei
programmi di manutenzione, affidabilità delle forniture e capacità di adattamento a
situazioni critiche.
2.2
Smart Buildings
L’ambito di lavoro principale di un energy manager è spesso rappresentato dall’analisi e dalla gestione dei consumi degli edifici più o meno grandi e voraci di energia
all’interno dei quali i collaboratori di un’azienda, o di un ente di qualsiasi altro tipo,
svolgono le mansioni richieste dal loro lavoro, un compito di una rilevanza spesso sottovalutata. È stato infatti calcolato che gli edifici commerciali nelle nazioni
6
2 – Descrizione dello stato dell’arte in tema di sistemi di gestione energetica degli edifici
sviluppate rappresentano il 20% della carbon footprint terrestre [7], pari alla metà
dell’impronta della totalità degli edifici che da da soli sono causa del 40% delle emissioni [8]. Tuttavia, identificare gli sprechi e le opportunità di risparmio può essere
molto difficile all’interno di questi contesti, spesso complessi e molto articolati.
Gli edifici, a destinazione d’uso pubblica/industriale, appaiono di conseguenza come uno degli ambiti più adatti per mettere alla prova concetti e tecnologie
smart, dal momento che rappresentano il punto d’incontro tra gli interessi privati
dei loro proprietari, sensibili alla rilevanza economica delle politiche di miglioramento dell’efficienza energetica e a quella reputazionale delle dinamiche di corporate social responsibility [9], e gli interessi pubblici di abbattimento dei consumi e
dell’inquinamento.
“Gli smart buildings impiegano una vasta gamma di tecnologie che migliorano
l’efficienza e collegano edifici tra loro, cosı̀ come con la rete di distribuzione, utilizzando dispositivi ICT e reti di comunicazione intelligenti. Molte delle tecnologie
necessarie per la qualifica di smart building, come submeter e sistemi di riscaldamento, ventilazione e condizionamento (HVAC) ad alta efficienza energetica, sono
maturi. Altri, come la costruzione di sistemi di gestione dell’energia (BEMS) e il
Building Information Modeling (BIM), sono in rapida evoluzione e offrono alcune
delle innovazioni di maggior impatto che il settore edile abbia visto negli ultimi anni. La sfida che gli integratori devono affrontare oggi, tuttavia, è connettere questi
sistemi in modo da massimizzare la redditività e sfruttare i punti di forza che ogni
fornitore di servizi nell’ecosistema dello smart building porta al tavolo.”
In questo passo, tratto dalla ricerca Smart buildings: ten trends to watch in 2012
and beyond [10], sono sintetizzati in modo molto molto efficace sia i concetti, che le
prospettive collegati all’idea di smart building, ed è evidente come le sfide poste in
essere da questo approccio al rapporto tra energia, edifici e persone che vi lavorano e
vivono dentro, siano quanto mai attuali e interessanti sia dal punto vista tecnologico
che da quello economico.
A testimonianza della maturità delle tecnologie di cui si sta parlando, bisogna
notare come i sistemi smart siano anche più vicini alla nostra esperienza diretta
di quanto non pensino molte persone, dal momento che ormai da diversi anni in
ogni casa sono stati installati dai distributori italiani di energia degli smart meter
in grado di comunicare i dati di consumo energetico in modo evoluto. La tecnologia
è quindi disponibile, ma le sue potenzialità restano ancora poco sfruttate, e in molti
casi, le persone che si occupano a livello professionale della gestione delle forniture
energetiche per le aziende, hanno come unico strumento la lettura a posteriori delle bollette, con possibilità di intervento sui consumi e capacità di analisi dei dati
praticamente nulle.
7
2 – Descrizione dello stato dell’arte in tema di sistemi di gestione energetica degli edifici
2.3
Submetering ed Energy Information Systems
La diffusione di sistemi di metering e submetering intelligenti sta andando di pari
passo con l’assunzione da parte dell’information technology di un ruolo centrale
all’interno del settore delle tecnologie per la gestione dell’energia. Gli strumenti
per rilevare i consumi energetici stanno infatti raggiungendo prezzi accessibili1 e la
loro penetrazione nel mercato appare in rapida ascesa, tanto che da oggi al 2020
si prevede un tasso di crescita complessiva del settore del submetering e dei servizi
collegati pari al 9,4% annuale [11].
Submeter e sistemi di analisi e gestione dei dati sono le due componenti reciprocamente imprescindibili di un’architettura di monitoraggio, nel contesto di un più
ampio sistema di gestione integrata di un edificio. La rete di submeter, gli strumenti
di rilevazione posti a valle dell’allacciamento di un’utenza alla rete di distribuzione
utilizzati per misurare i consumi sui vari rami di un impianto, non serve di per sé
a portare efficienza energetica, e allo stesso modo un building energy management
system per funzionare ha bisogno di conoscere cosa sta succedendo in tempo reale
all’interno dell’edificio o degli edifici che gestisce, come si può verificare attraverso
il diagramma contenuto nella Figura 2.1 che chiarisce il rapporto tra la rete di distribuzione, i meter installati dalla compagnia di utility e i sistemi di submetering
che possono essere posti in essere dai proprietari degli edifici.
In questo contesto, si sta sempre più diffondendo l’idea che una parte della strada che conduce alla riduzione dei consumi energetici globali, almeno nel settore del
management degli edifici, possa essere costituita da una soluzione software capace
di estrarre il potenziale informativo contenuto nei dati resi accessibili dalle tecnologie di advanced metering e consegnarlo in maniera fruibile nelle mani degli energy
manager e dei loro collaboratori, con costi di accesso e tempi di recupero degli investimenti molto più bassi rispetto alle ristrutturazioni green degli interi edifici. Nel
caso di strutture già esistenti, la soluzione più immediata ed efficace per ottenere
miglioramenti sul piano dei consumi e delle emissioni appare infatti assicurarsi che
l’infrastruttura già esistente funzioni al massimo della sua efficienza, ed il raggungimento di questo obiettivo può certamente essere facilitato dalla creazione di un
sistema di analisi dei dati, che rappresenta una soluzione vantaggiosa sia dal punto
di vista dell’investimento upfront che dell’invasività per gli edifici ed il lavoro dei
loro occupanti.
In un primo momento, le tecnologie descritte finora venivano integrate all’interno
di Building Management Systems (BMS) che potessero essere utilizzati per gestire
le mansioni operative (manutenzione di impianti elettrici e meccanici, gestione delle
1
Il dipartimento per l’energia degli Stati Uniti ha lanciato a maggio 2013 un challenge per la
costruzione di un meter wireless che costi meno di 100 dollari (fonte: www4.eere.energy.gov)
8
2 – Descrizione dello stato dell’arte in tema di sistemi di gestione energetica degli edifici
Figura 2.1.
Diagramma di un tipico sistema di submetring
lamentele degli occupanti... ) cosı̀ come l’energia ed il funzionamento di singoli sottosistemi come il riscaldamento o il condizionamento. Negli ultimi anni però è stata
riscontrata nell’offerta sul mercato una tendenza a concentrare l’attenzione dei BMS
sulle funzioni di building management ed a separare le funzioni di gestione dell’energia delegandole agli Energy Information Systems (EIS) [12]. Questa transizione
può essere imputata ad una serie di comuni problematiche riscontrate nell’implementazione dei sistemi più complessi, come le carenze di budget, la difficoltà di
installazione e di utilizzo delle piene funzionalità (che risultano spesso sottoutilizzate) e dalla parallela domanda di soluzioni centralizzate ed integrate, ma al contempo
snelle ed efficaci, per effettuare analisi dei dati energetici rapide e soprattutto pregne
delle informazioni più rilevanti.
Con il termine Energy Information System si intendono i sistemi costituiti da
software di monitoraggio della performance, hardware di acquisizione dati e sistemi
di comunicazione, utilizzati per memorizzare, analizzare ed esporre i dati energetici
di un edificio o di un complesso di edifici [13]. Un EIS raccoglie continuamente i dati
riferibili agli aspetti energetici con lo scopo di fornire feedback agli energy manager
ed agli operatori che si occupano di mantenere elevate le performance energetiche
9
2 – Descrizione dello stato dell’arte in tema di sistemi di gestione energetica degli edifici
attraverso la gestione degli impianti e la promozione dei necessari cambiamenti operazionali, secondo un’architettura che in prima approssimazione è quella presente
nella Figura 2.2.
Figura 2.2.
Tipica architettura di un EIS
Le funzioni per cui questi sistemi sono tipicamente utilizzati sono di tre tipi:
rilevazione e diagnosi dei guasti, gestione degli allarmi ed energy management. Nei
tre ambiti, se implementati in modo corretto e cuciti su misura per l’organizzazione
che li utilizza, sono in grado di fornire un supporto molto importante accelerando
le procedure di intervento in caso di guasti, focalizzando l’attenzione degli ingegneri
sugli eventi più critici che stanno avvenendo in tempo reale, integrando e consolidando flussi di dati provenienti da meter ambientali o energetici e presentando i
risultati delle elaborazioni con modalità fruibili.
In conclusione, bisogna sottolineare come le tecnologie, anche in questo settore,
siano in rapida evoluzione ed è lecito attendersi un significativo cambiamento anche
nelle caratteristiche e nelle funzionalità offerte dagli EIS. In particolare, ci si attende
che le direttrici di sviluppo possano muoversi secondo i seguenti trend: crescente
offerta di servizi in mobilità, flessibilità e personalizzazione delle interfacce utente,
supporto per il demand side energy management, maggiore affidabilità per quanto
riguarda la sicurezza e l’integrità dei dati, capacità confrontare scenari alternativi
ed in generale più ampie funzionalità di previsione dei consumi [14].
10
Capitolo 3
Questioni aperte ed opportunità di
lavoro
La descrizione del panorama tecnologico di riferimento contenuta nella sezione precedente, ha cercato di mettere in luce le caratteristiche dei fenomeni che riguardano il
management dell’energia nella gestione degli edifici e i sistemi che sono stati studiati
per facilitarlo; si è cercato di evidenziare vantaggi e motivazioni che hanno spinto
studiosi e professionisti a occuparsi di sistemi informatici di gestione dell’energia.
A questo proposito, merita particolare attenzione il potenziale di informazione contenuto nei dati di consumo che la tecnologia oggi permette di raccogliere.
Numerose indagini e ricerche condotte con esperti e professionisti della gestione
energetica in tutto il mondo, mostrano come l’accesso e l’analisi ai dati sulla reale
situazione energetica degli edifici sia uno dei punti chiave su cui lavorare per aumentare la consapevolezza con cui vengono prese ogni giorno le decisioni strategiche ed
operative in tema di building energy management. La fruibilità delle informazioni
energetiche può infatti influenzare in modo decisivo sia le scelte di programmazione
strategica di lungo termine, che i comportamenti e le abitudini di tutte le persone che usufruisco di un edificio e degli impianti che contiene, con impatti notevoli
sulla performance energetica complessiva (aumento dell’efficienza energetica anche
intorno al 5-10% [15]). Proprio in questo campo i sistemi informatici attualmente
disponibili mostrano alcune lacune.
Secondo l’indagine condotta dall’istituto di ricerca Aberdeen Group, di cui viene riportato un estratto nella Figura 3.1, tra le quattro maggiori sfide per gestire
efficacemente i programmi energetici due riguardano proprio la gestione dei dati:
rispettivamente il 37% ed il 30% dei rispondenti, ha infatti citato come top challenge “la complessità ed eterogeneità dei data sets che bloccano il processo di decision
making” ed “i processi manuali che rendono difficile trovare le informazioni rilevanti
per prendere decisioni”. Le organizzazioni sono quindi ben consce che ottenere i
dati energetici chiave sia quanto mai importante e sentono di avere la necessità di
11
3 – Questioni aperte ed opportunità di lavoro
una fonte sicura per i loro dati energetici.
Figura 3.1. Top challenges per la gestione efficace di programmi energetici (fonte:
Aberdeen Group, giugno 2011 [15])
Le questioni aperte in questo campo, che costituiscono opportunità di sviluppare
soluzioni e funzionalità nuove sono raggruppabili in tre categorie: la gestione dei
flussi di dati disponibili, la qualità dei dati stessi e la loro fruibilità.
3.1
Gestione dei flussi di dati
I dati che confluiscono all’interno di un energy information system sono caratterizzati da complessità di varia natura, cosa che li rende oggetti potenzialmente molto
difficili da gestire, ma che allo stesso tempo può essere indice dell’elevato contenuto
informativo che portano con loro.
Innanzitutto bisogna considerare che i dati possono essere eterogenei perchè provenienti da fonti molto diverse tra di loro o perchè rappresentativi di grandezze e
fenomeni differenti (le fonti possono essere utility meter piuttosto che sensori che
rilevano grandezze ambientali o fenomeni umani). Non sempre i sistemi attualmente disponibili sono in grado di gestire in modo adeguato le caratteristiche di queste
fonti di dati, e ad esempio l’integrazione dei dati di consumo elettrico con quelli di
altre fonti energetiche come i combustibili o l’acqua non sempre è ben supportata,
cosı̀ come esistono margini di sviluppo per quanto riguarda il supporto all’analisi
della correlazione tra grandezze di consumo e variabili ambientali (molto importante
per normalizzare i dati e non imputare risparmi a condizioni esterne favorevoli).
In secondo luogo, dal momento che praticamente tutti i dati provengono da misurazioni sul campo e devono essere consolidati in un unica struttura dati, sorge il
12
3 – Questioni aperte ed opportunità di lavoro
problema di gestirne il trasporto e garantirne l’integrità. Sorge anche il problema
delle moli di dati da trattare, dato che la maggior parte delle installazioni di EIS è
economicamente vantaggiosa solo nel caso di edifici o complessi di edifici con consumi rilevanti e quindi di dimensioni medio-grandi. Il tema da affrontare è quello dei
cosiddetti big data nella loro più compiuta declinazione, ovvero dati caratterizzati
da un elevato volume, velocità e varietà (dove velocità fa riferimento alle elevate
performance di raccolta e processamento, e varietà all’ampia gamma di differenti
tipi di dato [16]). L’interoperabilità con database noSql (una delle ultime tendenze
per la gestione di grandi quantità di dati in modo efficiente), ad esempio, non è
una caratteristica molto diffusa tra i sistemi di gestione dei dati energetici, anche
se questa, come le altre tecnologie che permettono di lavorare con i big data, potrebbe essere una risorsa molto importante per supportare elaborazioni in real time,
garantendo capacità di analisi puntuale e tempestiva e rifornendo i decisori con le
informazioni più recenti.
3.2
Qualità dei dati
La qualità dei dati resi accessibili da un energy information system è sicuramente
un altro dei settori di ricerca sui quali è importante riflettere. La qualità può essere
intesa dal punto di vista della correttezza ed integrità dei dati dalla fonte all’utente,
ma anche dalla prospettiva dell’aderenza dei dati alle necessità dei decisori e della
loro corretta contestualizzazione.
La prima parte del problema può sembrare di semplice soluzione, dal momento
che fondamentalmente si tratta di una questione di ETL, ma tenendo conto dell’eterogeneità delle fonti già citata nella sezione 3.1 e dell’assenza di specifici modelli
di riferimento, unita alla specificità dei dati raccolti in ciascun contesto applicativo
reale, ci si rende conto che può essere un processo più complicato del previsto [17].
Bisogna aggiungere che non sempre il trasporto dei dati energetici avviene in maniera ideale, dal momento che le reti di comunicazione costruite a questo scopo sono
in molti casi il frutto di compromessi dovuti alla necessità di farle convivere con le
strutture fisiche preesistenti degli edifici che sono oggetto dell’attività di gestione
energetica [18]. Uniformare i dati all’interno di una struttura coerente e funzionale
ai bisogni dell’organizzazione che li dovrà sfruttare, è altresı̀ un requisito indispensabile per le persone e le strutture che basano le loro decisioni su questi dati ed una
questione che dovrà essere affrontata dai progettisti degli EIS.
La seconda parte del ragionamento sulla qualità dei dati ha invece a che fare
sia con la progettazione che con l’implementazione di questi sistemi. Il fatto che i
dati forniti da un EIS siano più o meno adeguati ai processi decisionali che si prefiggono di supportare, dipende infatti sia dalla capacità dello strumento di offrire
profondità e ampiezza di analisi, che dalle competenze di chi ne progetta il deploy
13
3 – Questioni aperte ed opportunità di lavoro
in uno specifico contesto applicativo. Focalizzandosi sulla potenza di analisi degli
strumenti, la questione riguarda il minimo livello di granularità fornito, ed appare
evidente come questo non possa che essere un trade-off tra la complessità del sistema e la numerosità dei “punti di ascolto” (i meters e i sensori) di cui dispone.
Si tratta inevitabilmente di una questione che coinvolge aspetti che riguardano la
scalabilità dei sistemi, la complessità delle strutture dati necessarie e le prestazioni
di elaborazione; l’identificazione del giusto compromesso tra queste tre dimensioni è
sicuramente una delle problematiche più rilevanti da affrontare, e sarà al tempo stesso un equilibrio mobile influenzato dall’evoluzione delle tecnologie che compongono
i sistemi di gestione dell’energia.
3.3
Fruibilità e comunicazione dei dati
Facendo nuovamente riferimento all’indagine svolta da Aberdeen Group (Figura 3.1),
si può affermare che uno dei motivi per cui le aziende best-in-class ottengono performance migliori rispetto alle loro concorrenti (conseguendo in media consumi del 15%
più bassi) sia la capacità di estrapolare e visualizzare in modo efficace le informazioni contenute nei dati di consumo, in modo tempestivo e con possibilità di effettuare
drill down sui dati. L’importanza di questa abilità è rimarcata anche dall’accordo
che si riscontra interrogando le aziende stesse a proposito delle azioni strategiche necessarie per migliorare la performance energetica: come si può verificare dal grafico
presente in Figura 3.2, sia le aziende best-in-class che i competitors meno efficienti
sono concordi nel mettere al secondo posto per importanza nella scala delle azioni
strategiche la “creazione/miglioramento della capacità di leggere i dati energetici
all’interno dell’impresa”.
A sostegno delle valutazioni espresse dai partecipanti al sondaggio sopracitato, ci
sono inoltre ricerche scientifiche che attestano l’importanza del feedback nell’influenzare i comportamenti di consumo ed aumentare la consapevolezza energetica delle
persone. Come verificato da uno studio condotto dall’Università di Oxford [20], che
ha indagato lo specifico impatto della presentazione in varie forme delle informazioni
di consumo energetico sui comportamenti degli utenti domestici, la conoscenza di
dati oggettivi e verificabili può avere infatti un impatto molto rilevante sulla performance energetica. La presentazione regolare di dati di consumo rielaborati (feedback
indiretto) può addirittura condurre a risparmi dell’ordine del 10% (dipendentemente
dalla qualità e quantità delle informazioni fornite), e spinge a considerare in maniera
più approfondita la questione della fruibilità dei dati di consumo energetico ad ogni
livello di un’organizzazione, tenendo conto della natura intrinsecamente sociotecnologica dei fenomeni di consumo energetico in cui tecnologia e comportamento umano
interagiscono ed evolvono l’uno con l’altro nel corso del tempo.
14
3 – Questioni aperte ed opportunità di lavoro
Figura 3.2. Azioni strategiche per migliorare la performance energetica (fonte:
Aberdeen Group, aprile 2009 [19])
Ad influenzare l’utilizzabilità dei dati ricavabili tramite gli attuali sistemi di
energy information, ci sono poi altre due caratteristiche negative che si riscontrano
nel panorama tecnologico attuale: la difficoltà nell’esportazione di dati in formati
non standard e veramente personalizzabili, e le limitate possibilità di benchmarking. Fornire informazioni il più possibile personalizzate è uno degli stratagemmi
per mettere in moto il fenomeno di feedback informativo appena descritto, mentre
poter verificare la bontà della performance energetica rispetto a target progettuali
o best-practices e non solo rispetto al proprio pattern di consumo abituale potrebbe
rivelare a un energy manager le vere inefficienze del contesto che si trova a gestire.
In conclusione si può affermare che in generale l’obiettivo da perseguire nello
sviluppo di nuove tecnologie nell’ambito degli EIS sia la trasformazione dei dati
che la tecnologia è oggi in grado di mettere a disposizione nelle azioni operative e
strategiche più corrette in relazione al contesto di lavoro ambientale e alle dinamiche
sociali che caratterizzano l’edificio o gli edifici che monitorano, come esemplificato
in Figura 3.3.
15
3 – Questioni aperte ed opportunità di lavoro
Figura 3.3.
Trasformazione dei dati in azioni operative
16
Capitolo 4
Ricerca di una soluzione alle
problematiche riscontrate
Considerate le opportunità collegate agli Energy Information System esposte nel
capitolo precedente (gestione dei flussi di dati, qualità dei dati, fruibilità dei dati), la
presente ricerca ha voluto verificare se ci fosse possibilità di fornire risposte concrete
alle problematiche riscontrate.
In particolare è stata presa in esame l’ultima delle questioni poste, quella riguardante la fruibilità dei dati, dal momento che le prime due sono parse strettamente
collegate al processo di raccolta dei dati, su cui sarebbe stato difficile poter lavorare
in maniera diretta. Concentrandosi su questo sotto-ambito infatti, è stato possibile
sperimentare con dati storici di consumo reali del Politecnico di Torino1 , mentre
sarebbe stato molto più difficile poter lavorare in maniera cosı̀ diretta sui processi di
raccolta delle informazioni nella stessa istituzione; l’ambito di lavoro è quindi stato
ristretto alla definizione e validazione di un’architettura di visualizzazione ed analisi
dei dati di consumo energetico degli edifici.
4.1
Obiettivi e scelte preliminari
Dopo aver circoscritto il perimetro entro cui svolgere la ricerca e tenuto conto del
contesto di lavoro, si è passati alla definizione dell’obiettivo generale, ovvero lo sviluppo di uno strumento capace di fornire funzionalità di business intelligence con un
trade-off tra costi e prestazioni ragionevole. I target prestazionali preliminarmente
individuati per il propotipo da sviluppare erano costituiti dall’interattività ed accessibilità remota secondo i paradigmi a cui tutti sono stati abituati dalle tecnologie
1
In particolare con i dati raccolti dall’infrastruttura di meter del Politecnico tra il 1 gennaio
2009 ed il 17 luglio 2013
17
4 – Ricerca di una soluzione alle problematiche riscontrate
web, unite alla capacità di esplorazione dei dati dati tipiche dei sistemi di business
intelligence. Se infatti le metodologie di business intelligence nascono proprio per
rispondere alla questione della trasformazione dei dati in decisioni più efficaci ed
efficienti2 esposta nel capitolo precedente, le modalità di interazione tipiche delle
tecnologie web sono quelle a cui gli utenti di ogni tipo di servizio sono più avvezzi
e con i quali c’è una diffusa dimestichezza. Il connubio di questi due paradigmi è
apparso come una combinazione adatta a elevare il livello di fruibilità dei dati di
consumo in possesso alle organizzazioni.
Sempre a monte del processo di sviluppo vero e proprio, si è inoltre scelto di
affidarsi completamente a software open source, in modo da avere a disposizione
strumenti aggiornati e flessibili ad un costo molto basso. In particolare si è deciso di
adottare per la parte di BI i tool del pacchetto Pentaho, una delle poche soluzioni
completamente open-source citate all’interno del cosiddetto “magic-quadrant” di
Gartner3 [2] ed indicato nella stessa ricerca come uno strumento flessibile e dalla
footprint limitata, scelto dai suoi utenti per il basso TCO4 , le ottime performance
di data access e data integration, e la capacità di connettersi a svariate tipologie di
fonti di dati.
Infine è da sottolineare come si sia scelto di mantenere fuori dallo scopo di questa
ricerca l’implementazione di tecnologie di data mining, per le quali appaiono necessarie tecnologie e competenze ad hoc non del tutto compatibili con le modalità di
lavoro scelte.
4.2
Metodologia di lavoro
Con queste scelte e questi obiettivi in mente, si è proceduto a svolgere un lavoro di
ricerca articolato in cinque macrofasi, logicamente e temporalmente consequenziali.
Punto di partenza sono state la ricerca primaria e secondaria: la prima condotta tramite la somministrazione di un questionario esplorativo agli energy manager
certificati italiani, e la seconda tramite l’analisi dell’as-is tecnologico attraverso le
varie fonti indirette a disposizione (articoli, ricerche di mercato, cruscotti accessibili
online).
2
Business Intelligence (BI) can be defined as the process of turning data into information and
then into knowledge. [...] BI was born within the industrial world in the early 90’s, to satisfy the
managers’ request for efficiently and effectively analyzing the enterprise data in order to better
understand the situation of their business and improving the decision process. [21]
3
Il magic quadrant è un metodo di ricerca utilizzato da Gartner per mappare tecnologie e
mercati, fornendo sinteticamente dati qualitativi sulla loro evoluzione
4
Total Cost of Ownership
18
4 – Ricerca di una soluzione alle problematiche riscontrate
In seguito, ed in parte parallelamente alle prime due attività di ricerca, è stato
necessario prendere confidenza con le tecnologie scelte come base tecnologica per il
prototipo, in particolare con il server e gli altri tool di business intelligence. Si è
trattato di una fase di lavoro rilevante: oltre ad effettuarne l’istallazione, è stato
anche necessario comprenderne il funzionamento, cosa non sempre immediata data
la natura frammentaria della documentazione disponibile (nota dolente che in molti
casi caratterizza i prodotti di tipo open source).
Il passo successivo è stato la progettazione ed implementazione del processo di
ETL5 necessario a far confluire i dati raccolti sul campo dall’infrastruttura di meter
del Politecnico di Torino in una struttura dati coerente con il tipo di analisi che ci
si accingeva ad implementare tramite lo strumento in fase di sviluppo.
L’ultimo step dal punto di vista operativo è stato ovviamente la progettazione
e sviluppo del tool di visualizzazione grafica dei dati oggetto della ricerca; per far
questo è stato necessario tradurre per quanto possibile le indicazioni emerse dalle
fasi di ricerca preliminare in funzionalità pratiche, tenendo in considerazione gli
obiettivi generali di realizzazione di uno strumento interattivo, accessibile online,
con interfaccia grafica, capace di mostrare i dati con livelli di granularità variabili.
A conclusione di questo passo si è cercato di analizzare criticamente il percorso
seguito ed i risultati ottenuti, allo scopo di trarre considerazioni utili ad un eventuale
sviluppo futuro del lavoro.
In conclusione bisogna precisare come, dato l’intento principalmente esplorativo
della ricerca svolta, si sia scelto di non implementare metodologie volte a ottimizzare
il processo di sviluppo quali ad esempio IDEF0 o Quality Function Deployment. Gli
indubbi vantaggi dal punto di vista della qualità del risultato finale sarebbero stati
infatti fuori dal contesto di analisi, ed avrebbero potuto comportare un maggior
dispendio di tempo e risorse incompatibile con le modalità di ricerca scelte.
5
Extract, Transform, Load (ETL) è un’espressione che si riferisce al processo di estrazione,
trasformazione e caricamento dei dati in un sistema di sintesi (data warehouse, data mart...).
19
Capitolo 5
Ricerca preliminare
Come anticipato, prima di iniziare il processo di sviluppo del tool di visualizzazione
grafica dei dati di consumo energetico, si è ritenuto necessario chiarire quali fossero
le caratteristiche e le performance attese per il prototipo di cui ci si apprestava a
verificare la fattibilità. Si è trattato di indagare da un lato le aspettative dei potenziali utenti finali dello strumento, e dall’altro di documentarsi sullo stato attuale
delle tecnologie a disposizione di chi si trova a dover interagire operativamente con
strumenti di analisi dei dati di consumo energetico degli edifici. L’obiettivo finale
della ricerca era infatti verificare la compatibilità degli strumenti presi in esame con
la realizzazione di un tool capace di soddisfare le necessità degli operatori del settore. L’allineamento della prospettiva di indagine con la loro, e in qualche misura con
l’as is tecnologico, è sembrato quindi il primo passo da compiere in questa direzione.
Per soddisfare le necessità appena esposte ci si è mossi lungo due direttrici principali: la ricerca primaria condotta invitando a partecipare ad un questionario online
gli energy manager certificati dalla FIRE in Italia, e parallelamente la ricerca secondaria condotta attingendo alla letteratura ed agli strumenti accessibili via web
in materia.
5.1
Ricerca primaria: questionario esplorativo tra
gli energy manger italiani
Le motivazioni per svolgere un sondaggio o una ricerca di mercato possono essere
molteplici, ma in questo caso quelle che hanno spinto alla redazione del questionario sono state la verifica empirica delle supposizioni riguardo le informazioni che gli
utenti desiderino ricevere sui dati di consumo energetico e la definizione di alcuni
requisiti progettuali. In particolare, l’obiettivo primario che si è cercato di raggiungere fin dalla fase di redazione delle domande è stata l’esplorazione dei requisiti
degli utenti potenziali riguardo granularità, frequenza di campionamento, modalità
20
5 – Ricerca preliminare
e dimensioni di analisi ed aggregazione dei dati. L’output di questa fase di confronto
diretto è stato considerato infatti come punto di partenza per la costruzione dello
schema concettuale dei dati a livello di database e di conseguenza come base di
lavoro per la definizione delle caratteristiche del prototipo.
Per quel che riguarda la popolazione da intervistare, si è scelto di prendere
come target della ricerca la popolazione degli energy manager certificati italiani.
Le motivazioni dietro alla scelta sono state molteplici: a partire dalla familiarità
di questi soggetti con contesti strutturati e di dimensioni sufficientemente grandi
da rendere rilevanti le questioni legate al building management1 , proseguendo con
il fatto che il loro lavoro li porti a confrontarsi ogni giorno con le tematiche legate
all’analisi dei dati di consumo energetico e con il fatto che si tratta di potenziali
utenti finali o comunque stakeholder dello strumento in via di validazione.
5.1.1
Progettazione del questionario
A partire dagli obiettivi e dalle finalità appena esposti è stato redatto il questionario
da sottoporre agli energy manager, la cui realizzazione ha avuto come punto di inizio
il reperimento dei contatti a cui inoltrare l’invito a partecipare al survey online.
Questa operazione è stata possibile grazie all’elenco degli energy manager certificati
in Italia dalla FIRE2 , pubblicato dall’ente stesso sul proprio sito internet, che è stato
usato per reperire via web gli indirizzi di posta elettronica a cui contattare molti di
loro3 .
Il passo successivo è stato redigere il questionario vero e proprio, realizzato tramite la piattaforma online LimeSurvey, capace di fornire un’elevata flessibilità sia
nella costruzione della struttura del sondaggio, che nella scelta delle tipologie di domande e nell’analisi delle risposte alle stesse. È stata scelta una conformazione del
sondaggio a sezioni successive, ciascuna specificamente mirata ad un argomento su
cui si ritenesse importante ottenere delle informazioni dagli intervistati. Ne è quindi
risultata una struttura di questo tipo:
1
La presenza di un energy manager è obbligatoria in tutte le aziende e gli enti dell’industria
caratterizzati da consumi superiori ai 10.000 tep/anno e nelle realtà del settore civile, terziario e
pubblica amministrazione con una soglia di consumo di 1.000 tep/anno
2
La FIRE gestisce dal 1992, su incarico a titolo non oneroso del Ministero dello Sviluppo
Economico, la rete degli energy manager individuati ai sensi della Legge 10/91, recependone le
nomine e promuovendone il ruolo attraverso varie iniziative.
3
Questa modalità di reperimento dei contatti ha fatto sı̀ che sia stato possibile coinvolgere pochi
manager dal settore privato in rapporto a quelli dal settore pubblico, i cui indirizzi email sono molto
più spesso disponibili online.
21
5 – Ricerca preliminare
• Prima sezione costituita da domande di tipo anagrafico volte a raccogliere
informazioni sul profilo dei partecipanti al sondaggio. Conteneva domande
sull’età, settore di lavoro, esperienza e formazione.
• Seconda sezione contenente domande preliminari su campionamento e granularità dei dati. Lo scopo di questa sezione era separare il percorso all’interno
delle sezioni successive tra chi ritenesse di dover differenziare i parametri di
campionamento e granularità in base alla grandezza in esame o meno.
• Terza e quarta sezione contenenti domande riguardo i livelli di granularità e
frequenza minima di campionamento ritenuti ideali.
• Quinta sezione volta ad indagare le caratteristiche degli strumenti attualmente a disposizione dei rispondenti in termini di modalità di visualizzazione e
tipologie di dati ottenibili.
• Sesta sezione incentrata invece sugli aspetti di analisi, sulle misure aggregate
e sulle dimensioni di aggregazione ritenute più adeguate dai partecipanti al
sondaggio, insieme ad alcune domande riguardo le correlazioni eventualmente
prese in considerazione.
La maggior parte delle domande incluse era a risposta chiusa, in modo da poter
avere indicazioni il più possibile confrontabili tra di loro, e si è scelto di ricorrere
a domande aperte solo per chiedere ai partecipanti opinioni circa temi non esplicitamente compresi nel questionario. In un paio di casi è stato anche richiesto di
ordinare un set di alternative, allo scopo di indagare all’interno di un gruppo di
alternative le preferenze relative.
Le varie domande sono state redatte con la collaborazione dei ricercatori del
gruppo e-Lite, ed inoltrate in una prima fase ad alcuni contatti interni al Politecnico per procedere ad una eventuale riscrittura di quelle ambigue o poco efficaci
precedentemente all’inizio del sondaggio vero e proprio. Successivamente si è proceduto all’invio di mail individuali di invito a partecipare al sondaggio a ciascuno
dei soggetti precedentemente individuati, seguito da un remind (utile a far crescere
leggermente il tasso di partecipazione) a distanza di circa quindici giorni dal primo
invio.
5.1.2
Analisi dei risultati
Per prima cosa bisogna considerare che su un totale di 200 email di sollecito a
partecipare inviate, si sono contate 33 risposte complete al questionario (sono giunte
circa altre 30 risposte incomplete), con un tasso di partecipazione che si è attestato di
conseguenza al 16,5%. Tutte le considerazioni che seguiranno sono state ovviamente
22
5 – Ricerca preliminare
tratte sulla base di queste risposte complete, il cui valore statistico non appare
rilevante, ma che, data la somiglianza rilevata tra le caratteristiche dei rispondenti
e quelle dei soggetti contattati, possono costituire una fonte informativa credibile.
L’affermazione precedente riguardo la somiglianza tra partecipanti e contattati,
risulta di difficile verifica, dal momento che i questionari sono stati compilati in
forma anonima, ma può essere supportata dalle considerazioni riguardo le uniche
due caratteristiche note per tutti e due gli insiemi di individui: il sesso ed il macrosettore economico di appartenenza (privato o pubblico). A questo proposito, dal
confronto tra i destinatari delle mail di invito a partecipare alla ricerca, partecipanti
al sondaggio e soggetti che hanno risposto a tutte le domande del questionario, non
emergono sostanziali differenze, come evidente dai dati riportati nelle Tabelle 5.1 e
5.2.
Tabella 5.1. Comparazione tra soggetti contattati, rispondenti e risposte complete
per quanto riguarda l’appartenza al settore pubblico o privato
pubblico
privato
destinatari
168 (84%)
32 (16%)
rispondenti
35 (87,5% di chi ha dato una
risposta a questa domanda)
5 (12,5% di chi ha dato una
risposta a questa domanda)
risposte complete
29 (87,9% di chi ha dato una
risposta a tutte le domande)
4 (12,1% di chi ha dato una
risposta a tutte le domande)
Tabella 5.2. Comparazione tra soggetti contattati, rispondenti e risposte complete
per quanto riguarda il sesso
maschi
femmine
destinatari
186 (93%)
14 (7%)
rispondenti
38 (90,5% di chi ha dato una
risposta a questa domanda)
4 (9,5% di chi ha dato una
risposta a questa domanda)
risposte complete
30 (90,9% di chi ha dato una
risposta a tutte le domande)
3 (9,1% di chi ha dato una
risposta a tutte le domande)
Passando all’analisi dei restanti dati anagrafici, è risultato che chi ha risposto in
maniera completa al sondaggio ha un età equamente suddivisa nelle fasce 36-45, 4655 e 56-65, ed un’esperienza media nell’ambito del settore della gestione energetica
di 11,64 anni. Il 73% ha una formazione di tipo ingegneristico, ma è presente una
quota significativa (15%) di persone non laureate in possesso di diplomi tecnici. Il
23
5 – Ricerca preliminare
90% lavora in aziende medio grandi (con più di 100 dipendenti) e, anche a causa
dello sbilanciamento verso il settore pubblico che caratterizza la popolazione che si è
riuscita a contattare, i settori economici maggiormente rappresentati sono pubblica
amministrazione, ricerca/università e sanità (insieme costituiscono il 75%).
La grande maggioranza dei rispondenti ritiene che il campionamento dei dati
debba essere effettuato con frequenze differenti e specifiche per ciascuna delle tre
grandezze che si è deciso di esaminare (acqua, gas ed elettricità), ed altrettanto si
può dire riguardo la granularità spaziale. Si osserva una tendenza a considerare ideale un monitoraggio più dettagliato dell’energia elettrica, sia in termini di frequenza
di campionamento che di granularità spaziale. Per quanto riguarda il campionamento, emerge come range di intervalli ritenuto più adeguato l’alternativa “< di 1 ora”,
anche se per quanto riguarda il monitoraggio dei consumi di elettricità vi è un interesse significativo anche per intervalli di campionamento più brevi (20,83% per “< di
30 minuti” e 12,50% per “< di 10 minuti”). I livelli di granularità spaziale ritenuti
più interessanti sono stati invece il “singolo edificio” e il “reparto/dipartimento”,
con una prevalenza del primo livello per acqua e gas e una prevalenza del secondo
per l’elettricità, anche se per quest’ultima il 36% dei rispondenti ritiene interessante
anche aver a disposizione dati relativi ai singoli locali o uffici.
Per quanto riguarda modalità di visualizzazione dei dati e funzionalità di alerting
emergono delle tendenze ben definite. La modalità di visualizzazione dei dati più
diffusa è quella per mezzo di tabelle: la maggior parte dei rispondenti (57,6%) ha
dichiarato di aver a disposizione solo questa, e se si considerano anche i casi in cui
viene affiancata dalle altre il 70% dei 33 rispondenti la utilizza. Solo il 12% dei
rispondenti ha dichiarato di aver a disposizione cruscotti di analisi. Il 75% ha a
disposizione solo dati aggregati sui consumi, e all’interno di questi solo la metà circa
ha strumenti che permettono di personalizzare le aggregazioni. Inoltre l’84,9% dei
rispondenti ritiene che sarebbe utile aver a disposizione dati puntuali, ed il 48,5%
definisce questa caratteristica “molto utile”. Il 90,9% dei rispondenti ha definito in
qualche modo utile un sistema che segnali in modo autonomo le anomalie di consumo
ed il 93,9% desidererebbe poter definire allarmi personalizzati.
Infine, riguardo le dimensioni di aggregazione, le misure aggregate e l’analisi di
correlazione, si può notare come l’interesse dei rispondenti appaia rivolto principalmente verso l’associazione tra consumi, locali alimentati e utilizzo che se ne fa. In
testa agli aspetti che vengono considerati nello svolgere analisi dei consumi ci sono
infatti la destinazione d’uso di energia e locali, la dimensione e l’utilizzo di questi
ultimi (in termini di occupazione, frequenza d’uso e calendario lavorativo), citati
da più del 60% dei rispondenti. Le misure ritenute più importanti sono nell’ordine
media, somma e valori massimi e minimi; aggregate preferibilmente lungo la dimensione temporale, spaziale o di destinazione d’uso. In ultima analisi, è da notare come
il 39,4% dei rispondenti dichiari di non effettuare analisi di correlazione tra i dati
di consumo e gli aspetti che potrebbero averli causati, ma di questi la quasi totalità
24
5 – Ricerca preliminare
non lo fa perchè non dispone di dati o strumenti che glielo permettano.
Nei paragrafi che seguono, vengono prese dettagliatamente in esame tutte le voci
precedentemente riassunte.
Dati anagrafici
La sezione anagrafica, oltre a fornire indicazioni per il confronto tra il totale dei soggetti contattati ed il sottoinsieme di coloro i quali hanno risposto a tutte le domande
del questionario, è servita ad avere un’idea sulle caratteristiche degli intervistati (e
di conseguenza del gruppo di potenziali utenti dello strumento in fase di sviluppo).
Tre caratteristiche sono emerse in maniera netta:
• l’età dei partecipanti al sondaggio (Figura 5.1) appare distribuita uniformemente tra le fasce di età 36-45, 46-55 e 56-65, indicando che quella di energy
manager è una posizione ricoperta solo da personale con un livello di seniority
medio-alto;
Figura 5.1.
Età dei partecipanti al sondaggio
• la formazione (Figura 5.2 e Figura 5.3) è di livello universitario in più dell’80%
dei casi, con una decisa prevalenza per persorsi formativi di tipo tecnico (il
72% vanta una laurea in ingegneria ed il 15% pur non essendo in possesso di
una laurea ha frequentato scuole superiori ad indirizzo tecnico), a sottolineare
come le competenze di questo tipo siano ancora considerate importanti per la
professione di energy manager;
25
5 – Ricerca preliminare
Figura 5.2.
Figura 5.3.
Titolo di studio dei partecipanti al sondaggio
Titolo di studio dei partecipanti al sondaggio (aggregato)
• come ci si attendeva, le dimensioni delle aziende o enti publici in cui lavorano
sono medio-grandi, se raffrontate al contesto socio-economico italiano. Ciò
conferma la bontà della scelta del target del sondaggio, con il quale si è potuto
in questo modo esplorare realtà economico-gestionali all’interno delle quali le
scelte di gestione energetica possiedono una significativa rilevanza economica
(Figura 5.4).
Per quanto riguarda il settore economico in cui operano i partecipanti al sondaggio e la loro esperienza nell’ambito della gestione energetica non sono viceversa
emerse indicazioni univoche. Il primo aspetto è stato infatti fortemene influenzato
26
5 – Ricerca preliminare
Figura 5.4. Dimensioni dell’azienda/ente in cui lei ricopre attualmente il ruolo di
responsabile per l’uso dell’energia (n. approssimativo di dipendenti)?
dallo sbilanciamento verso il settore pubblico dell’insieme dei contattati, che ha portato i settori di amministrazione pubblica, ricerca/università e sanità a costituire
da soli il 75% dei rispondenti (Figura 5.5). Dalle risposte riguardo l’esperienza non
è invece emersa una tendenza a causa della forte variabilità delle risposte, che ha
portato ad osservare un valor medio di 11,61 anni di esperienza caratterizzato da
una deviazione standard di 7,84 anni (Figura 5.6).
Figura 5.5. In quale settore economico opera l’azienda/ente in cui lei ricopre
attualmente il ruolo di responsabile per l’uso dell’energia?
27
5 – Ricerca preliminare
Figura 5.6.
Esperienza nell’ambito della gestione energetica da parte dei rispondenti
Campionamento e granularità dei dati
Una delle questioni più importanti da indagare attraverso il sondaggio è stato, come
già anticipato, il livello minimo di granularità spaziale e frequenza di campionamento ritenuto adeguato dai rispondenti. Si tratta infatti di due fattori chiave nella
definizione del design delle strutture dati e dall’impatto potenzialmente elevato sulle
prestazioni del prototipo. Le domande del questionario erano di conseguenza mirate
a chiarire in primo luogo se i rispondenti ritenessero necessario avere a disposizione
livelli diversi di granularità e di frequenza di campionamento per le tre grandezze di
consumo considerate. In seconda battuta è stato ovviamente richiesto di specificare i valori ritenuti più adeguati per le due dimensioni, separatamente per ciascuna
grandezza nel caso si avesse dichiarato di preferire una differenziazione tra le varie
grandezze o in maniera unica nel caso opposto. Infine è stato richiesto di suggerire altre grandezze di consumo ritenute rilevanti oltre o alternativamente alle tre
esplicitamente considerate (elettricità, gas o altri combustibili, acqua potabile).
Le risposte raccolte indicano in maniera decisa (intorno al 75%) la preferenza
per un diverso trattamento dei dati a secondo della grandezza a cui sono riferiti, sia
in termini di frequenza di campionamento che di granularità spaziale (cfr. Tabelle
5.3 e 5.4).
In particolare, i rispondenti ritengono che l’energia elettrica possa essere campionata a frequenze più alte e con maggiore granularità, come si può evincere dai dati
presenti nelle tabelle seguenti. Per quanto riguarda l’elettricità vi è infatti interesse
anche per gli intervalli di campionamento sotto la mezz’ora (20,83%) e sotto i dieci
minuti (12,50%), mentre per acqua e gas ripettivamente l’87,5% e l’85,71% ritiene che un intervallo di campionamento adeguato possa essere inferiore all’ora. Le
granularità spaziali minime presentano tendenze meno nette: anche in questo caso
28
5 – Ricerca preliminare
Tabella 5.3. Ritiene che i dati riferiti a diverse tipologie di consumo (elettrico,
acqua, gas) debbano essere campionati a frequenze diverse?
conteggio
percentuale
sı̀
no
24
72,7%
9
27,3%
Tabella 5.4. Ritiene che il sistema di monitoraggio dovrebbe visualizzare i dati ad
un livello di granularità spaziale differente per ciascuna tipologia di consumo?
conteggio
percentuale
sı̀
no
25
75,8%
8
24,2%
viene ritenuto molto interessante un livello di dettaglio più elevato per l’elettricità
(reparto/dipartimento), mentre per acqua e gas un dato a livello di edificio viene
considerato sufficienemente specifico, ma le indicazioni appaiono più sfumate.
Chi ritiene che i dati possano essere campionati tutti alla stessa frequenza ha
risposto come segue:
Tabella 5.5. Quale tra i seguenti intervalli di campionamento si avvicina di più a
quello che lei ritiene ideale per il monitoraggio dei consumi energetici?
<
<
<
<
<
30
1’
10’
30’
1h
conteggio
percentuale
0
0
0
1
8
0,0%
0,0%
0,0%
11,1%
88,9%
Chi invece ritiene che i dati debbano essere campionati a frequenze diverse ha
risposto in questo modo:
29
5 – Ricerca preliminare
Tabella 5.6. Quale tra i seguenti intervalli di campionamento si avvicina di più a
quello che lei ritiene ideale per il monitoraggio dei consumi energetici?
elettricità
conteggio
perc.
<
<
<
<
<
30”
1’
10’
30’
1h
2
1
3
5
13
8,33%
4,17%
12,50%
20,83%
54,17%
gas o altri combustibili
conteggio
perc.
1
0
1
2
20
4,17%
0,00%
4,17%
8,33%
85,71%
acqua
conteggio
perc.
1
0
1
1
21
4,17%
0,00%
4,17%
4,17%
87,50%
Chi ritiene che i dati possano essere campionati con un livello di granularità
unico, ha risposto come segue:
Tabella 5.7. Quale tra i seguenti intervalli di campionamento si avvicina di più a
quello che lei ritiene ideale per il monitoraggio dei consumi energetici?
gruppo di edifici
singolo edificio
reparto/dipartimento
singolo locale/ufficio
altro
conteggio
percentuale
0
4
5
0
0
0,00%
50,00%
62,50%
0,00%
0,00%
Chi invece ritiene che i dati debbano essere campionati a granularità diverse ha
risposto in questo modo4 :
4
I dati della Tabella 5.8, come quelli della Tabella 5.7, non sommano al 100% perchè le percentuali sono calcolate con riferimento al numero di persone che hanno risposto alle rispettive
domande, dal momento che entrambe prevedevano la possibilità di risposta multipla.
30
5 – Ricerca preliminare
Tabella 5.8. Quale tra i seguenti intervalli di campionamento si avvicina di più a
quello che lei ritiene ideale per il monitoraggio dei consumi energetici?
elettricità
conteggio
perc.
gruppo di edifici
singolo edificio
reparto/dipartimento
singolo locale/ufficio
altro
1
8
15
9
1
gas o altri combustibili
conteggio
perc.
4,00%
32,00%
60,00%
36,00%
4,00%
1
17
10
3
0
4,00%
68,00%
40,00%
12,00%
0,00%
acqua
conteggio
perc.
1
15
12
2
0
4,00%
60,00%
48,00%
8,00%
0,00%
Strumenti di visualizzazione dei dati di consumo attualmente a disposizione
Con questa sezione si è voluto raccogliere informazioni riguardo le caratteristiche
degli strumenti utilizzati dai partecipanti al sondaggio, con l’obiettivo di identificare
possibili aspettative latenti dei partecipanti al sondaggio in merito alle modalità di
visualizzazione dei dati disponibili.
Pertanto sono state poste domande riguardanti le modalità di visualizzazione dei
dati attualmente utilizzate, ottenendo una fotografia in cui gli intervistati dichiarano in grande maggioranza di aver a disposizione dati accessibili solamente tramite
tabelle ed in rari casi tramite cruscotti (Tabella 5.9). È stato poi evidenziato come,
nonostante la maggior parte di loro avrebbe interesse per la possibilità di avere accesso anche ai dati puntuali cosı̀ come vengono campionati (l’84,9% dei partecipanti
definisce questa funzionalità “utile” o “molto utile”, come evidente dai dati in Tabella 5.11), pochi abbiano a disposizione questa opportunità, potendo contare solo
su dati aggregati (Tabella 5.10). Inoltre si è potuto riscontrare un certo interesse
verso la possibilità di avere a disposizione strumenti in grado di offrire funzioni di
alerting tarate su eventuali anomalie dei dati.
Per quel che riguarda lo sviluppo di uno strumento di visualizzazione, è di conseguenza emersa l’opportunità di fornire dati disaggregati insieme a quelli aggregati,
in un ambiente grafico più attraente ed interattivo di una tabella (solo il 15% ha
affermato di avere a disposizione cruscotti di visualizzazione).
31
5 – Ricerca preliminare
Tabella 5.9.
Quali modalità di visualizzazione dei dati utilizza abitualmente?
Solo cruscotti
Solo report
Solo tabelle
Cruscotti e report
Cruscotti e tabelle
Report e tabelle
Cruscotti, report e tabelle
Altro
conteggio
percentuale
1
5
19
0
1
4
3
0
3,0%
15,2%
57,6%
0,0%
3,0%
12,1%
9,1%
0,0%
Tabella 5.10. Utilizzando gli strumenti indicati nella domanda precedente,
di che tipo di dati dispone?
Solo aggregati personalizzabili
Solo aggregati non personalizzabili
Solo dati puntuali
Aggregati personalizzabili e dati puntuali
Aggregati personalizzabili e non
Aggregati non personalizzabili e dati puntuali
Aggregati personalizzabili, non personalizzabili e dati puntuali
Altro
conteggio
percentuale
13
12
4
3
0
0
1
0
39,4%
36,4%
12,1%
9,1%
0,0%
0,0%
3,0%
0,0%
Tabella 5.11. “Quanto riterrebbe utile per il suo lavoro avere a disposizione
degli strumenti in grado di mostrare le singole misure di consumo cosı̀ come
vengono campionate?”
1 (inutile)
2
3
4
5 (molto utile)
32
conteggio
percentuale
1
1
3
12
16
3,0%
3,0%
9,1%
36,4%
48,5%
5 – Ricerca preliminare
Misure aggregate e dimensioni di analisi
Nella sesta ed ultima sezione del questionario si richiedeva ai partecipanti all’indagine di esplicitare preferenze e opinioni riguardo le dimensioni di analisi utilizzate e
desiderate.
La prima domanda chiedeva di scegliere all’interno di un set di alternative gli
aspetti ritenuti rilevanti ai fini dell’analisi dei dati di consumo, mentre le due successive richiedevano di ordinare, secondo le proprie preferenze, misure aggregate e
dimensioni di aggregazione. Le risposte a queste tre domande sono mostrate nel
grafico e nelle tabelle che seguono (Figura 5.7 e Tabelle 5.12 5.13), ed evidenziano
come destinazione d’uso dei locali e dell’energia siano indicati come aspetti chiave,
insieme all’occupazione e alla dimensione spazio temporale, mentre tra le misure
aggregate media, somma e valori minimi e massimi sono ritenute le più importanti. Altre misure aggregate come mediana o moda hanno ricevuto basso interesse,
mentre non sono state proposte uleteriori alternative oltre a quelle proposte.
Figura 5.7. “Nell’impostare un’analisi dei dati di consumo, o un monitoraggio
energetico, quali dei seguenti aspetti riterrebbe utile analizzare/considerare?”
33
5 – Ricerca preliminare
Tabella 5.12. “Quali sono le misure aggregate più significative per le analisi che
svolge nell’ambito del suo lavoro? Ordini le seguenti tipologie di misure aggregate
dalla più importante alla meno importante.”
1°
2°
3°
4°
5°
6°
n. risposte
posizione media
somma
media
max
min
moda
mediana
10
3
4
0
1
2
20
2,25
8
10
4
3
0
1
26
2,23
8
6
10
3
1
0
28
2,39
3
5
6
8
2
0
24
3,04
1
3
3
0
1
5
13
3,92
3
3
1
1
6
1
15
3,47
Tabella 5.13. “Nel valutare le misure aggregate, quale ritiene che siano le dimensioni di aggregazione dei dati più importanti da considerare? Ordini dalla più
importante alla meno importante le alternative proposte di seguito.”
1°
2°
3°
4°
5°
6°
n. risposte
posizione media
spazio
tempo
dest.
d’uso
energia
meteo
occupaz.
locali
produz.
energia
4
7
3
5
2
0
21
2,71
11
7
6
1
1
0
26
2
10
7
8
1
0
0
26
2
0
2
3
2
4
2
13
4,08
5
4
2
5
2
3
21
3,19
3
2
3
2
1
3
14
3,36
Per quanto riguarda la correlazione tra dati (indagata tramite una domanda
aperta), si può notare come i dati meteorologici, poco citati nelle risposte alle precedenti domande, abbiano ricevuto un certo interesse. Bisogna altresı̀ sottolineare
come solo il 60% di coloro i quali hanno risposto completamente al questionario abbia dichiarato di effettuare analisi riguardo la correlazione dei dati di consumo con
altri fenomeni, mentre all’interno di coloro che non la svolgono, la stragrande maggioranza (92%) ha dichiarato di non farlo perchè non in possesso di dati o strumenti
adatti.
34
5 – Ricerca preliminare
Figura 5.8. “Tra quali dati di consumo e quali grandezze/aspetti verifica
l’eventuale correlazione?”
Misure aggregate, dimensioni di analisi e grandezze di consumo da considerare oltre a quelle previste all’interno del questionario
In tre casi inoltre è stato esplicitamente richiesto ai partecipanti all’indagine di elencare alternative ulteriori oltre a quelle coperte dal questionario. Per quanto riguarda
misure aggregate e dimensioni di analisi, non sono emerse indicazioni significative,
mentre relativamente alle grandezze di consumo da considerare, il 48,5% dei rispondenti ha suggerito grandezze aggiuntive. Tra queste le più citate sono risultate
essere i carburanti, la quantita di energia autoprodotta e l’energia trasportata e consumata tramite varie forme di vettori termici (acqua surriscaldata, vapore, acqua
refrigerata).
5.2
Ricerca secondaria: analisi della letteratura e
delle soluzioni accessibili online
La ricerca secondaria svolta è stata finalizzata alla verifica sul campo delle osservazioni tratte dall’analisi delle risposte giunte al questionario rivolto agli energy
manager. Si è cercato in questo modo di mitigare gli effetti di eventuali imprecisioni
dovute alla limitatezza del campione esaminato ed allo stesso tempo di ampliare lo
scopo della ricrca, consultando fonti non specifiche del contesto italiano.
Oltre alla consultazione di svariati articoli accademici, che sono stati di supporto
anche nella redazione dei capitoli precedenti al presente, è stata svolta una ricerca
online tra i cruscotti di visualizzazione dei dati di consumo energetico resi disponibili
liberamente sia da alcune compagnie ed università internazionali che da realtà più
35
5 – Ricerca preliminare
piccole. Questi sono stati confrontati sulla base delle informazioni fornite e delle
modalità di visualizzazione ed interazione con le stesse. Il risultato di questa analisi
è stata una griglia di confronto che tiene in considerazione aspetti quali le tipologie di
grafici utilizzati, le grandezze di consumo considerate, i livelli di granularità spaziale
e temporale disponibili. Ovviamente la valenza statistica di un’analisi del genere
è decisamente limitata, e non permette di inferire praticamente nulla riguardo le
caratteristiche generali di questi tool, ma ha consentito di effettuare una panoramica
conoscitiva e di verificare se i concetti emersi dall’indagine precedentemente svolta
trovino riscontro nella pratica più immediatamente accessibile.
5.2.1
Indagine sulle caratteristiche dei cruscotti di visualizzazione online
Sono stati presi in esame 55 cruscotti, pubblicati da enti di svariate tipologie, che
vanno dal pubblico al privato, dalle università alle aziende multinazionali. A questo proposito la loro distribuzione all’interno delle tre macro-aree scuola ed università, aziende private ed enti istituzionali è quella mostrata nel grafico presente in
Figura 5.95 .
Figura 5.9. Settori di appartenza degli enti a cui fanno riferimento le
dashboard considerate
Per quanto riguarda le grandezze di consumo prese in esame (Figura 5.10), le
informazioni tratte dal questionario tra gli energy manager vengono confermate: al
momento, oltre ai dati sul consumo di energia elettrica6 , le grandezze prese maggiormente in analisi sono infatti l’acqua, considerata esplicitamente dal questionario, e l’energia tramite vettori termici, emersa tra le raccomandazioni su grandezze
agguntive da considerare (oltre alle tre già presenti).
Passando a parlare di granularità spazio-temporale dei dati bisogna sottolineare
come non si sia proceduto a separare le considerazioni in base alle diverse grandezze
di consumo, in modo da non frammentare in maniera eccessiva le informazioni raccolte. All’interno del campione esaminato è emerso che per la dimensione spaziale il
5
scuole ed università rappresentano la fetta maggiore probabilmente perchè tendenzialmente
meno restie ad esporre dati sulla loro performance
6
probabilmente anche per la più facile raccolta di questi dati
36
5 – Ricerca preliminare
Figura 5.10.
Grandezze prese in esame dalle dashboard considerate
massimo livello di dettaglio più frequentemente fornito sia il dipartimento, mentre
per la dimensione temporale si tratti dell’ora. Anche in questo caso l’osservazione
sembra confermare le informazioni raccolte attraverso i questionari.
Figura 5.11.
Minima granularità spaziale dei dati presente nelle dashboard considerate
Figura 5.12. Minima granularità temporale dei dati presente nelle dashboard considerate
A proposito di dimensione temporale, sono stati analizzati anche i livelli di aggregazione dei dati disponibili, da cui è emerso che nel 70% dei casi sia possibile
37
5 – Ricerca preliminare
visualizzare i dati sull’orizzonte di una settimana, un mese o un giorno.
Figura 5.13. Possibilità di aggregazione temporale dei dati presente nelle
dashboard considerate
Infine sono state prese in esame due caratteristiche dei cruscotti funzionali alla
progettazione grafica del prototipo, ovvero le tipologie di grafici disponibili e le
funzionalità aggiuntive disponibili oltre alla semplice visualizzazione grafica dei dati.
Le tipologie di grafici maggiormente presenti sono risultate essere i bar chart (con
orientamento prettamente verticale) ed i line chart o area line chart, secondo le
percentuali esposte nel grafico in Figura 5.14.
Figura 5.14.
Tipologie di grafici presenti nelle dashboard considerate
Viceversa, per quanto riguarda le funzionalità aggiuntive presenti, è stato riscontrato che:
• nell’ 89% dei casi è possibile effettuare qualche tipo di confronto tra dati;
• nell’ 83% dei casi vengono presentati dati sul meteo in tempo reale;
• nel 78% dei casi è possibile effettuare una sorta di contestualizzazione dei dati
esprimendoli in unità di misura equivalenti.
38
Capitolo 6
Processo di definizione e sviluppo
del prototipo
Una volta ottenute preziose indicazioni dal lavoro di ricerca esposto nel capitolo
precedente, si è proceduto a tradurle in requisiti di progettazione, cercando di conciliarle con le possibilità offerte dai dati a disposizione e mediando tra le varie istanze
emerse. Dopo aver formalizzato gli obiettivi in termini di funzionalità potenzialmente realizzabili, si è è proceduto a svilupparle con gli strumenti scelti, creando uno
schema dei dati adeguato, implementando un prototipo di cruscotto e mettendone
a punto le prestazioni. Nel capitolo che segue si vuole delineare il percorso seguito,
focalizzandosi sulle problematiche affrontate e sulle soluzioni individuate.
6.1
Requisiti di progettazione
La definizione dei requisiti è stata la sintesi degli output di tutte le attività di ricerca
preliminare svolte a monte dello sviluppo del prototipo dimostratore. A partire
dalle informazioni tratte dall’analisi delle risposte al questionario e dallo studio
delle caratteristiche dei cruscotti disponibili online, si è proceduto a selezionare le
principali tendenze emerse, nel contesto dell’inquadramento generale fornito dalla
letteratura consultata e dalle scelte preliminari descritte nella Sezione 4.1.
In particolare, dall’analisi delle risposte ai questionari si è registrato l’interesse
da parte degli energy manager per:
• la visualizzazione dei dati puntuali con granularità identica alla frequenza di
campionamento;
• la possibilità di analizzare i dati secondo granularità differenti anche al variare
della grandezza di consumo in esame;
39
6 – Processo di definizione e sviluppo del prototipo
• la possibilità di confrontare i dati di consumo tra diverse destinazioni d’uso,
diversi locali, diversi periodi e anche con grandezze esterne come le condizioni
meteorologiche;
• l’insieme di misure aggregate costituito da media aritmetica, somma, valore
massimo e valore minimo (in questo ordine di preferenza).
Inoltre è emerso come molti dei rispondenti basino le loro decisioni su tabelle o
report statici (solo una piccola minoranza ha a disposizione cruscotti di analisi dei
dati); mentre per quanto riguarda le grandezze da prendere in esame, appare esserci
accordo tra l’attenzione mostrata dai partecipanti al sondaggio per elettricità, acqua ed energia termica trasportata sotto varie forme1 , e l’evidenza empirica delle
grandezze presenti nelle dashboard online esaminate.
Aggiungendo a queste considerazioni l’osservazione che la maggior parte delle
soluzioni online esaminate presenti i dati sotto forma di bar chart orientati verticalmente o line chart, e che spesso vengano mostrati i dati sul meteo real time (uno
dei confronti tra dati di consumo e fattori esterni maggiormente indicato dai rispondenti al sondaggio è stato proprio quello con i dati meteo) si è proceduto a definire
i seguenti requisiti di progettazione2 :
• granularità spazio-temporale variabile per l’analisi dei dati;
• possibilità di visualizzare le singole misure;
• aggregazione dei dati tramite le misure aggregate di somma, media, valore
max e min, secondo la dimensione temporale e spaziale;
• possibilità di effettuare confronti tra dati riferiti a differenti periodi (dimensione temporale);
• possibilità di effettuare confronti tra dati riferiti a differenti meter (dimensione
spaziale - destinazione d’uso);
• presenza di dati meteorologici, con possibilità di metterli a confronto con i dati
di consumo riferiti al medesimo tempo e spazio.
1
vapore o acqua calda, acqua refrigerata...
2
La possibilità di fornire analisi dei dati sulla base della dimensione e dell’occupazione dei locali
è stata esclusa dai requisiti, nonostante fosse stata indicata come importante da una larga fetta
dei partecipanti al sondaggio, per l’impossibilità di estrarre informazioni affidabili su questo punto
tramite i dati a disposizione. Per lo stesso motivo l’analisi per destinazione d’uso potrà essere
implementata solo sommariamente, come verrà esposto nella Sezione 6.2.2.
40
6 – Processo di definizione e sviluppo del prototipo
In sintesi, quale obiettivo delle varie fasi di progettazione e sviluppo, è stato
individuata la creazione di un tool di visualizzazione di dati energetici capace di
trasformare i dati grezzi di consumo in informazioni fruibili nelle sopracitate modalità3 , soprattutto grazie al fatto di essere costruito attorno ad una piattaforma di
business intelligence.
6.2
6.2.1
Sviluppo del prototipo dimostratore
Strumenti ed architettura selezionati
Anche se in parte si è trattato di decisioni prese a monte del processo di progettazione e sviluppo vero e proprio (cfr. Sezione 4.1), si può certamente affermare che
l’effettiva realizzazione del prototipo sia iniziata con la selezione dell’architettura da
implementare e degli strumenti software da utilizzare. Nel far questo, si è ovviamente dovuto tener conto dell’interdipendenza bidirezionale tra le scelte architetturali
e la selezione di paradigmi e tool di sviluppo, con l’obiettivo finale di definire una
soluzione quanto più coerente possibile.
Come anticipato nella Sezione 4.1, una delle scelte cardine iniziali è stata l’adozione della suite Pentaho per la realizzazione delle funzionalità legate a vario titolo
alle tecniche di business intelligence (dall’etl al drill-down sui dati). Si tratta di un
pacchetto software integralmente basato su tecnologia Java, che integra una serie di
sotto-tool per le funzionalità avanzate di ETL, OLAP, reporting, dashboard interattive, data mining e predictive analysis intorno ad un BI server centrale che gestisce
le funzionalità base di autenticazione ed analisi dei dati; tra i punti di forza di questo prodotto vi sono le ottime performance di data access and integration, per le
quali si è classificato al secondo posto assoluto all’interno dell’indagine comparativa
svolta nel 2012 da Gartner tra i più popolari software di business intelligence [2].
Nello specifico, oltre al server di business intelligence (componente indispensabile del
sistema), sono stati installati il componente per l’integrazione dei dati denominato
Spoon, il componente per la preparazione degli schemi di dati a supporto dell’esplorazione OLAP denominato Schema Workbench ed il componente per la creazione
guidata di tabelle aggregate denominato Aggregate Designer. Sono stati inoltre installati i plugin per il server centrale sviluppati da Webdetails4 per il supporto alla
creazione di dashboard interattive integrate nella piattaforma Pentaho, denominati
3
Implementando in questo modo la metà superiore, e più vicina all’utente, del paradigma EIS
esposto in Figura 2.2
4
Webdetails è un’azienda nata con lo scopo di creare soluzioni di Business Analytics appositamente studiate per integrarsi con la piattaforma Pentaho, da qualche mese è stata acquisita
direttamente da Pentaho. http://www.webdetails.pt/
41
6 – Processo di definizione e sviluppo del prototipo
Community Dashboard Editor5 , Community Dashboard Framework6 , Community
Data Access7 e Community Charting Components8 .
Una volta selezionati gli strumenti della suite Pentaho per svolgere i compiti di
BI server e data integration, si è trattato di definire quali tecnologie e quali strumenti
impiegare a monte per lo storage dei dati ed a valle per creare un ambiente dinamico
in cui presentare all’utente finale le dashboard gestite dal server BI:
• per quanto riguarda la selezione del database di riferimento, si è optato per
MySQL, corredato dell’interfaccia grafica MySQL Workbench, il database relazionale libero più diffuso nell’ambiente dello sviluppo web (ad esempio Wikipedia utilizza un database basato su MySQL [22]), che dal 2010 fa parte dei
prodotti della multinazionale leader del settore dei database Oracle;
• in secondo luogo si è deciso di integrare le dashboard interattive risultato delle
elaborazioni svolte dal server di BI all’interno di un’applicazione dinamica
in JSP9 , implementando il paradigma model view controller che permette di
disaccoppiare l’accesso ai dati e le logiche di business dalla presentazione dei
dati ed interazione con l’utente;
• si è infine deciso di ospitare la suddetta applicazione, da realizzarsi con il
supporto del tool di sviluppo Eclipse, sul popolare web server Apache Tomcat,
che insieme a MySQL costituisce uno dei pilastri della diffusissima architettura
per il web LAMP10 .
In questo modo, dall’unione delle componenti descritte finora, si è delineata
un’architettura come quella illustrata in Figura 6.1, completamente basata su tecnologie aperte (in gran parte Java) e in grado di separare le logiche di elaborazione
5
Il Community Dashboard Editor (CDE), integrato nella Pentaho User Console, è uno strumento
grafico per la creazione, l’editing e la visualizzazione in anteprima di dashboard di Pentaho.
6
Il Pentaho Community Dashboard Framework è stato creato per integrare saldamente le
dashboard nl solution repository del server BI.
7
Il plugin Community Data Access (CDA) è stato sviluppato come strumento di astrazione tra
le connessioni al database e CDF (Community Dashboard Framework). Consente ai dati di essere
recuperati da più sorgenti e combinati in un singolo output che può essere facilmente trasmesso ai
componenti delle dashboard.
8
Community Charting Components (CCC) è una libreria per la generazione di grafici costruita
su Protovis un potente kit di strumenti di visualizzazione gratuito e open-source. Consente agli
sviluppatori di inserire in maniera immediata nelle dashboard i più comuni tipi di grafico
9
JavaServer Pages è una tecnologia di programmazione Web in Java per lo sviluppo di
applicazioni Web che forniscono contenuti dinamici in formato HTML o XML.
10
LAMP è l’acronimo che indica una piattaforma software per lo sviluppo di applicazioni web
che prende il nome dalle iniziali dei componenti software con cui è realizzata: sistema operativo
Linux, web server Apache, database MySQL, linguaggi di scripting PHP,Perl o Phyton
42
6 – Processo di definizione e sviluppo del prototipo
dei dati da quelle di presentazione degli stessi: il data warehouse che contiene i
dati necessari a tutte le elaborazioni è ospitato sul server MySQL, che, dopo essere stato alimentato dal tool di data integration Spoon, rende disponibili i dati di
consumo al server BI di Pentaho, il quale soddisfa le richieste dell’utente generando
una dashboard interattiva contenuta in un’applicazione jsp ospitata sul server web
Tomcat.
Figura 6.1.
6.2.2
Schema architetturale del prototipo da sviluppare
Progettazione dello schema dei dati
Le tecniche applicate in questa fase della ricerca sono riconducibili alla teoria del Dimensional Fact Model (DFM) [23], sviluppato per superare le limitazioni dei modelli
entity-relationship nel caso delle applicazioni di data warehousing.
In sintesi, si tratta di una tecnica che, sfruttando la denormalizzazione delle tabelle generate, semplifica il design dei data warehouse e crea un ambiente in cui
le query degli utenti possono essere definite in maniera più intuitiva. I concetti
chiave attorno a cui ruota sono quelli di fatto, che modella gli eventi di interesse,
dimensione, che definisce attraverso un set di attributi le coordinate di analisi di
un fatto, misura, che descrive una proprietà numerica di un fatto, e gerarchia, che
esprime le relazioni di dipendenza funzionale tra gli attributi di una dimensione.
43
6 – Processo di definizione e sviluppo del prototipo
Sfruttando questi quattro elementi concettuali, è possibile esprimere in maniera immediatamente comprensibile gli eventi centrali per le analisi di business intelligence,
articolandone le caratteristiche gerarchicamente e numericamente.
Nel descrivere il processo di integrazione dei dati grezzi di consumo all’interno
del data warehouse bisogna però necessariamente partire dalla descrizione delle caratteristiche di questi dati grezzi. Si è trattato di lavorare con tre tabelle denominate
tab connessioni, albero connessioni e dati consumo, contenenti rispettivamente:
• l’elenco completo dei meter appartenenti alla rete del Politecnico, corredati di
informazioni sul tipo di dato raccolto da ciascuno;
• una parziale rappresentazione gerarchica dei suddetti meter11 ;
• le letture dei meter dal 1 gennaio 2009 al 17 luglio 2013 con intervallo di
campionamento di 15 minuti, corredate di informazioni sui relativi meter e
timestamp.
Bisogna precisare a questo punto, che la rete tramite la quale sono stati raccolti i
dati di consumo elettrico presenta una struttura gerarchica a tre livelli caratterizzata
da un meter che misura i consumi totali della sede centrale, un meter che misura
i consumi in uscita dalle sotto-cabine di distribuzione ed una serie di meter che
misurano i consumi di porzioni più o meno estese della rete a cui si connettono le
apparecchiature di singoli utenti o strutture. Viceversa il consumo di acqua potabile
è misurato solo a livello centralizzato per tutta la sede di corso Duca degli Abruzzi.
Purtroppo, rispetto ai requisiti emersi nella fase di ricerca sul campo, alcune
funzionalità sono quindi state rese irrealizzabili nella loro interezza dalle caratteristiche di questi dati. Se infatti per i dati meteorologici è stato possibile ricorrere a
fonti esterne, per i dati su occupazione, dimensione e destinazione d’uso dei locali monitorati dai vari meter non è stato ovviamente possibile fare altrettanto. Di
conseguenza le funzionalità che si sarebbero potute realizzare avendo a disposizione
queste informazioni non sono state implementate, con l’eccezione della destinazione
d’uso dell’energia, analizzabile in alcuni casi sfruttando il fatto che ci siano meter
dedicati per alcuni degli impianti chiave della struttura del Politecnico, quali ad
esempio le pompe di calore o la galleria del vento.
11
La gerarchizzazione dei meter contenuta nei dati di cui è stato possibile entrare in possesso
era stata realizzata in maniera lacunosa a causa delle difficoltà nell’identificare in maniera univoca
le relazioni tra meter diversi e per le imprecisioni introdotte dall’evoluzione “topografica” delle
strutture del Politecnico asincrona rispetto alla creazione della rete di meter.
44
6 – Processo di definizione e sviluppo del prototipo
Con questi dati a disposizione, e con la necessità di implementare fondamentalmente due prospettive di analisi dei dati, ovvero quella temporale e quella logicospaziale, si è quindi proceduto a definire lo star schema12 relativo agli eventi di
consumo energetico. Il fatto di interesse è stato ovviamente individuato nell’evento
di rilevazione del consumo, con unica misura costituita dall’entità della rilevazione;
le dimensioni di analisi definite sono state invece tre: una per il momento della
giornata, una per la data di rilevazione ed una riguardante il meter autore della
rilevazione. Come si può verificare dall’analisi della Figura 6.2, le due dimensioni
temporali sono le tipiche ed intuitive declinazioni del tempo su scala giornaliera o
annuale, mentre risulta più complessa e ramificata la dimensione che ha come radice i singoli meter, che presenta come ramo principale la gerarchizzazione dei meter
attraverso le cabine di trasformazione a cui fanno riferimento, e come attributi secondari il tipo di meter ed il sottosistema logico a cui può far riferimento all’interno
della struttura del Politecnico.
Figura 6.2.
6.2.3
Star schema del data warehouse
Implementazione processo ETL
A partire da questa struttura concettuale, è stato quindi necessario creare e riempire
con i dati corretti la relativa struttura di tabelle all’interno del server di MySQL installato per ospitare i dati e renderli disponibili per le analisi di business intelligence.
Nello schema presente in Figura 6.3 si può vedere il risultato della transizione da
12
È stato scelto lo star schema e non lo snowflake schema perchè non appariva necessario ottenere
risparmi nelle dimensioni del db e per evitare le problematiche legate al numero maggiore di join
che si sarebbero potuti rendere necessari.
45
6 – Processo di definizione e sviluppo del prototipo
schema concettuale a tabelle sql, dove gli attributi con a sinistra la chiavetta gialla
sono le chiavi primarie, mentre quelle con il rombo rosso sono le chiavi esterne.
Figura 6.3.
Struttura delle tabelle del data warehouse
Per riempire questo schema con i dati ripuliti da duplicati, valori nulli ed altri
tipi di imprecisioni in maniera efficace e veloce, ci si è serviti dello strumento per
l’ETL della piattaforma Pentaho precedentemente installato. Con il supporto di
questo strumento si è proceduto a generare da zero le dimensioni temporali con le
caratteristiche richieste dallo schema concettuale, a trasportare i dati sui meter dal
dataset di partenza al data warehouse, ed infine a travasare anche i dati di consumo
corretti. Tre le principali difficoltà incontrate nello svolgimento di questa attività
vanno citate:
• la ricostruzione delle informazioni da inserire nella tabella rappresentativa della
dimensione di analisi riguardante i meter, svolta “manualmente” a monte della
46
6 – Processo di definizione e sviluppo del prototipo
programmazione del software Spoon confrontando i dati presenti nelle due
tabelle tab connessioni ed albero connessioni con la topografia del Politecnico;
• la progettazione del trasferimento dei dati garantendo il mantenimento dei
corretti riferimenti tra le tabelle, realizzata tramite la definizione della corretta
struttura di chiavi per i dati;
• l’individuazione delle “difettosità” presenti nel dataset di partenza, emerse
tramite un lento processo di analisi fatto di esplorazione dei dati e prove
preliminari di trasformazione con l’aiuto del tool ETL.
L’output di questa fase è stato dunque il data warehouse riempito con i dati di consumo del Politecnico organizzati secondo lo schema a stella necessario a
supportare le analisi per il prototipo del cruscotto di visualizzazione dei dati.
6.2.4
Progettazione e sviluppo delle componenti JSP
Parallelamente allo studio della struttura dati necessaria, si è iniziato a definire la
struttura web in cui incapsulare le elaborazioni fornite dal server di BI.
La scelta è stata quella di implementare il classico pattern logico-grafico che si
trova all’interno delle pagine web, dividendo logicamente la pagina (e quindi l’interfaccia) in quattro aree: una superiore dedicata all’header che come la testata di
un giornale renda riconoscibile l’applicazione, una inferiore dedicata ad informazioni di servizio come i riferimenti su autore e proprietario, un menù di navigazione
laterale che permetta di muoversi all’interno delle varie sezioni ed un grosso spazio
centrale dinamico, all’interno del quale far comparire di volta in volta il contenuto
corrispondente alle scelte dell’utente. In linea con le soluzioni online analizzate e con
le indicazioni fornite dai partecipanti al questionario, si è pensato di far corrispondere le sezioni e quindi le voci del menù di navigazione alle grandezze di consumo
analizzabili, mentre ad integrazione delle informazioni delle varie sezioni si è deciso
di aggiungere anche un widget di visualizzazione dei dati meteorologici real time.
Considerando le funzionalità da realizzare e le possibilità offerte dagli strumenti
selezionati, si è inoltre pensato di sfruttare il menù per implementare una soluzione
a due livelli di analisi: un primo livello, con caratteristica principale l’immediatezza, realizzabile attraverso una serie di dashboard interattive sviluppate con i plugin
per Pentaho di Webdetails, ed un secondo livello, con possiblità di effettuare vero e
proprio drill-down sui dati, realizzato includendo nel prototipo la possibilità di accedere direttamente a tutte le funzionalità del server di Pentaho. La prima parte della
soluzione sarebbe in questo modo pensata per offrire un accesso quanto più ampio
possibile ai dati senza necessità di autenticazione, anche ad esempio nel contesto di
aumentare l’awareness sui consumi tra gli utenti di un edificio, mentre la seconda
richiederebbe autenticazione da parte di personale preposto al monitoraggio delle
47
6 – Processo di definizione e sviluppo del prototipo
performance degli edifici, nel contesto di effettuare richieste più specifiche e quindi
più onerose dal punto di vista dell’elaborazione.
La struttura dell’applicazione è quindi risultata essere composta preliminarmente
da quattro sezioni13 : una introduttiva di presentazione, una relativa ai consumi elettrici, una relativa ai consumi idrici ed una contenente l’interfaccia grafica del server
di BI. Navigando all’interno delle sezioni, l’utente potrebbe cosı̀ passare dall’introduzione alle funzionalità disponibili, all’analisi veloce dei dati di consumo tramite
dashboard pubbliche in grado di fornire una visione di insieme delle caratteristiche
dei dati, per proseguire infine, dopo l’autenticazione, all’analisi di dettaglio tramite
il drill su specifici aspetti di interesse.
Dopo aver definito la struttura generale dell’applicazione Jsp, si è trattato di
riempirla con le componenti necessarie a generare il contenuto richiesto dall’utente.
Secondo il model view controller, dopo che le pagine controller hanno selezionato
la view in grado di implemetare le funzionalità corrette, sono le view a doversi
occupare della generazione del contenuto e quindi è qui che ci si è trovati ad inserire
le chiamate per includere il contenuto generato dal server di bi. L’operazione è stata
realizzata inserendo degli iframe14 contenenti il riferimento alle url a cui vengono
esposte da Pentaho le dashboard realizzate con Community Dashboard Editor e
l’interfaccia operativa della piattaforma denominata Pentaho User Console; in questo
modo è stato possibile inserire l’output delle elaborazioni del server in un contesto
omogeneo generato tramite la tecnologia jsp, preservandone tutte le funzionalità
anche in termine di interazione con l’utente.
6.2.5
Progettazione e sviluppo delle dashboard dinamiche
generate dal server di BI
Una volta definito il perimetro dell’applicazione Jsp, è iniziata la fase di sviluppo
delle dashboard necessarie ad implementare le funzionalità emerse dalla ricerca preliminare, realizzate tramite i sopracitati plugin sviluppati da Webdetails ed installati
insieme al server di BI della piattaforma Pentaho.
Attraverso l’interfaccia grafica di lavoro di questi strumenti, è stato possibile
creare e modificare le dashboard senza dover scrivere direttamente codice, dal momento che è l’editor CDE ad occuparsi di tradurre il design e le funzioni definite
dallo sviluppatore nei file con estensione .cdfde .wcdf e .cda necessari al server di
Pentaho per rendere le dashboard. Si tratta di tre file per ciascuna dashboard redatti
in una sorta di linguaggio .xml con cui il framework CDF definisce rispettivamente: la struttura ed i componenti, le proprietà generali e le funzionalità di accesso
13
Si è potuto avere accesso solamente ai dati relativi al consumo di acqua potabile ed elettricità
14
Iframe è un tag ideato proprio per integrare un documento html all’interno di un altro
48
6 – Processo di definizione e sviluppo del prototipo
ai dati di cui necessita una dashboard, la cui creazione viene in questo modo resa
molto più immediata e rapida, anche grazie alla possibilità di vedere in anteprima i
cambiamenti man mano che li si apportano. Di conseguenza, le uniche parti di vero
e proprio codice scritto manualmente hanno riguardato lo stile di visualizzazione,
definito attraverso una serie di definizioni .css, le query di accesso ai dati, scritte
ovviamente in SQL, ed il comportamento dinamico di alcuni componenti, specificato
attraverso script in Javascript.
Prima di iniziare il processo di sviluppo vero e proprio, è parso però importante
passare attraverso una fase di familiarizzazione con gli strumenti di sviluppo scelti
e di esplorazione delle potenzialità espressive degli stessi. Per fare ciò, si è deciso
di procedere alla realizzazione di alcuni abbozzi dell’interfaccia finale, in una sorta
di brainstorming utile anche a verificare la fattibilità e le performance delle varie
opzioni di sviluppo disponibili. Da un lato sono stati realizzati degli sketch grafici
utili a valutare diverse alternative di impaginazione dei contenuti ed a testare i
pattern di interazione offerti all’utente, e dall’altro si è iniziato ad esplorare quali
fossero i limiti in termini di accesso ai dati oltre i quali la navigazione risultasse
difficoltosa.
In seguito alle criticità emerse durante questa analisi preliminare sia in termini
di performance che di usabilità delle bozze realizzate, è parso evidente che la strada
migliore nello sviluppo fosse la separazione delle funzionalità da implementare all’interno di un sistema di dashboard, piuttosto che l’unione di tutte le funzioni in
una singola dashboard per ogni grandezza in esame (e quindi per ogni view Jsp).
In questo modo sarebbe stato possibile delegare a ciascuna dashboard uno o più
compiti in un ambito ristretto, garantendo di volta in volta all’utente una diversa
profondità di analisi su aspetti complementari e fornendo nel complesso una panoramica più ampia. Per ciascuna grandezza si è quindi pensato di definire, sulla base
delle caratteristiche della struttura dei dati, un sistema di tre dashboard (selezionabili tramite un apposita sezione di navigazione da aggiungere all’interno di ogni
view):
• una per l’analisi dei dati all’interno di diversi periodi temporali, con la possibilità di scegliere sia l’orizzonte di dati da visualizzare (giorno, settimana, mese,
anno) che la granularità temporale degli stessi all’interno della selezione, fino
alla visualizzazione dei singoli campioni;
• una per l’analisi dei dati su base giornaliera, con la possibilità di visualizzare
l’andamento dei consumi aggregati di un certo periodo all’interno dei vari
momenti del giorno e di filtrare i dati sulla base del calendario lavorativo o del
giorno della settimana;
49
6 – Processo di definizione e sviluppo del prototipo
• una per il confronto di una selezione di dati con quelli relativi ad un altro
periodo, ad un altro meter o ai dati meteo15 .
(ovviamente in ciascuna sezione è stata prevista la possibilità di filtrare i dati in
base al meter autore delle rilevazioni, potendo scegliere di visualizzare i dati secondo
ciascun livello della rispettiva dimensione)
Per garantire continuità tra le tre modalità di esplorazione dei dati sono state
definite delle sezioni comuni in cui suddividere lo spazio a disposizione, dando quanto
più risalto possibile ai dati e separando logicamente i blocchi di filtraggio dei dati tra
la dimensione temporale e quella logico-spaziale. Ne è scaturita la scelta di disporre
nella zona centrale i line chart con cui visualizzare l’andamento dei consumi16 e
nella parte inferiore le due aree affiancate di filtraggio dei dati come nel disegno di
Figura 6.4.
Figura 6.4. Bozza della disposizione grafica degli elementi nelle sezioni di
visualizzazione dei dati
A partire da questa struttura logica, e non solo grafica, per ogni dashboard sono
state definite le funzionalità di filtraggio dei dati disponibili (e di conseguenza le
15
Per dati meterologici si intendono le temperture massime, medie e minime
16
È stato scelto quest tipo di grafici in luogo dei bar chart per la maggior capacità di veicolare
le informazioni sull’andamento dei valori nel corso del tempo
50
6 – Processo di definizione e sviluppo del prototipo
componenti da inserire nei form appositi) insieme con le modalità di generazione
delle misure aggregate. In tutte e tre sono stati inseriti i selettori per la scelta del
tipo di periodo di tempo (anno, mese, settimana, giorno), del singolo periodo da
esaminare, del tipo di centro di consumo (totale, sottosistema, cabina, meter) e del
singolo centro di consumo, indispensabili per restringere il campo di lavoro in ognuno
dei tipi di analisi supportato. Per l’analisi per periodo è stato aggiunto il selettore
per la scelta del livello di granularità temporale, con opzioni disponibili generate
dinamicamente in base al tipo di periodo scelto, in modo da non dover rendere
grafici con un numero di punti troppo elevato17 . Per l’analisi nei vari momenti della
giornata, invece, sono stati aggiunti i selettori per restringere l’analisi ad un solo
giorno della settimana e per filtrare tra giorni festivi o lavorativi. Infine, per il
confronto tra dati, si è pensato di inserire un radio-button per la scelta del tipo di
raffronto da effettuare, con possibilità di scegliere alternativamente se confrontrare i
dati relativi ad un periodo e ad un centro di consumo, con quelli relativi ad un altro
periodo, ad un altro centro di consumo o alle temperature medie, massime e minime
giornaliere registrate nello stesso periodo. In quest’ultimo caso si è provveduto anche
a gestire la comparsa e scomparsa in modo dinamico delle sezioni per la definizione
delle caratteristiche dei dati con cui raffrontare quelli della selezione principale.
Per quanto riguarda il secondo punto, invece, si è pensato di sfruttare la possibilità di rendere cliccabili i grafici offerta dal tool Pentaho Community Chart Components, per inserire, nelle due dashboard prettamente di analisi dei dati, un event
handler che generi un popup contenente le misure aggregate calcolate sulla base dei
dati presenti nel punto in cui l’utente abbia cliccato. Inoltre, per fornire contestualizzazione ai dati mostrati nei grafici realizzati tramite le dashboard appena descritte,
si è deciso a posteriori di modificarne leggermente il layout grafico inserendo accanto
ai due blocchi per il filtraggio dei dati un box contenente le caratteristiche dei dati
visualizzati, aggiornate dinamicamente in base alle scelte dell’utente.
Dopo aver sviluppato le componenti delle dashboard, si è trattato di completare
la configurazione dei componenti accessibili tramite l’applicazione Jsp, rendendo
possibile il drill-down sul data warehouse contenente i dati di consumo del Politecnico
all’interno della Pentaho User Console18 . Per fare ciò è stato necessario pubblicare
lo schema del cubo di analisi dei dati sul server, dopo averlo descritto in formato
.xml attraverso l’interfaccia grafica del tool Schema Workbench19 .
17
Ad esempio nel caso si fosse lasciata la possibilità di visualizzare i dati con granularità ai 15
minuti e orizzonte temporale di un mese si sarebbe dovuto generare un grafico con circa 2900 valori
18
La Pentaho User Console (PUC) è l’interfaccia Web per il Pentaho BI Server. Essa consente
di interagire in modo semplice e diretto con le funzioni base di reporting e analisi di Pentaho
19
Schema Workbench è un’interfaccia di design che permette di creare e testare schemi di cubi
OLAP visivamente. Permette di generare in maniera grafica gli schemi di metadati xml utilizzati
51
6 – Processo di definizione e sviluppo del prototipo
A una prima esplorazione dei dati tramite le componenti per l’analitica comprese nella Pentaho User Console, svolta in prima istanza per verificarne il corretto
funzionamento in seguito alla pubblicazione degli schema files, è però emersa con
prepotenza la questione delle performance: l’elaborazione richiesta per l’analisi drilldown sui circa 15 milioni di record contenuti nel data warehouse rendeva impossibile
una user experience soddisfacente. Al contrario di molti server OLAP, Mondrian20
infatti non memorizza dati sul disco, ma lavora solo con i dati del database relazionale e dopo averne letto una certa quantità li memorizza in cache. Questo garantisce
semplificazioni nel processo di installazione di Mondrian, ma ne limita le prestazioni
quando viene utilizzato con grandi moli di dati, costringendo all’utilizzo di tabelle
di aggregati da posizionare accanto alla fact-table principale nel DW e registrare
negli schema files sul server [24].
Fortunatamente tutte queste operazioni sono state semplificate dall’utilizzo del
tool grafico Aggregate Designer, che, a partire dallo schema file già pubblicato sul
server, permette di creare, poopolare e registrare gli aggregati necessari, che saranno
però utilizzabili solo dopo aver modificato le impostazioni del server di Pentaho che
di default non sfrutta queste strutture dati. Al fine di valutarne le prestazioni si
è inoltre scelto di affidarsi, per la definizione degli aggregati necessari, alla funzionalità di autocreazione degli stessi presente in Aggregate Designer21 , che permette
di svolgere tutte le operazioni senza dover interagire direttamente con il database.
In questo modo le performance generali in esplorazione dei dati sono sensibilmente
migliorate, anche se, come ovvia conseguenza dell’approccio seguito, permangono
difficoltà nell’effettuare drill-down su determinate areee del data warehouse non
specificamente supportate dalla struttura dati creata.
Affrontata la questione delle performance della funzione di analytics della Pentaho User Console, restava però aperta quella riguardante le performance delle query
necessarie a fornire i dati alle dashboard, in grado di costituire potenzialmente un
blocco alla qualità della user experience da queste offerta. Al momento della prima definizione delle query per il fetch dei dati necessari al funzionamento delle
dashboard, non ci si era infatti posti direttamente questo problema, convinti della
bontà della soluzione di “spacchettamento” delle funzionalità tra le diverse dashboard accessibili per ogni grandezza di consumo. L’analisi empirica della soluzione
da Mondrian, il motore OLAP interno a Pentaho, per elaborare le richieste ROLAP. In particolare i
modelli di metadati prodotti sono un’emulazione di un cubo basato sulle tabelle di fatti e dimensioni
presenti nel RDBMS, che permette di evitare la costruzione e manutenzone di veri e propri cubi
fisici.
20
Il server OLAP presente all’interno della piattaforma Pentaho.
21
Il software analizza la struttura e la cardinalità delle dimensioni del data warehouse e, in
funzione del massimo tempo di elaborazione e massimo numero di aggregati impostato dall’utente,
suggerisce un set di tabelle aggregate ottimale.
52
6 – Processo di definizione e sviluppo del prototipo
sviluppata a quel punto, ha però messo in evidenza le criticità connesse alle query
per il recupero delle informazioni necessarie per la generazione dei grafici e per il
calcolo delle misure aggregate, in prima analisi derivanti dalla necessità di effettuare
numerosi join tra tabelle a cardinalità elevata. Scartata l’opzione di modificare le
tabelle aggregate per questo scopo, dal momento che la combinazione della sintassi
accettata da mysql e delle modalità di gestione delle query sql all’interno di Pentaho
CDE non lo permetteva22 , si è proceduto all’analisi delle singole query con l’aiuto
di MySQL workbench alla ricerca di soluzioni alternative. Dalla verifica condotta è
emersa come la soluzione più efficace fosse lo sfruttamento dell’indicizzazione delle
chiavi primarie ed esterne, implementata di default da mysql, utilizzando quanto
più possibile le suddette chiavi all’interno dei campi WHERE delle query. I vantaggi più grossi derivanti da questo approccio si sono avuti nel trattare la dimensione
relativa alle date, che data l’elevata cardinalità comportava le difficoltà maggiori.
Aiutati anche grazie al fatto di aver definito gli id dei record della corrispondente
tabella in maniera leggibile (si utilizzato un intero in formato aaaammgg), è stato
infatti possibile selezionare il periodo di interesse all’interno delle query utilizzando
intervalli di key anzichè gli attributi relativi ai vari livelli della gerarchia.
L’ultima questione aperta ha riguardato la gestione dell’autenticazione, da implementare solo su una porzione dello strumento, ovvero quella che permette di
accedere alla Pentaho User Console. Con Pentaho CDE è possibile definire i privilegi dei vari utenti riguardo una dashboard, in modo che questa, dopo essere stata
pubblicata sul server di BI, possa essere accessibile tramite una url e di conseguenza
anche inclusa all’interno di un’altro documento html tramite il tag iframe, come nel
caso dello strumento oggetto di questa ricerca. Non è però nativamente possibile
aprire porzioni dei contenuti pubblicati sul server di bi ad utenti anonimi. Dal momento che l’intera piattaforma Pentaho viene distribuita con codice aperto, è stato
però possibile intervenire direttamente sui file di configurazione di base del server,
modificando le componenti che si occupano della sicurezza e rendendo possibile la
concessione del privilegio di esecutore anche ad un utente anonimo. Si è potuto in
questo modo separare l’accesso pubblico alle dashboard di analisi “veloce” dei dati
che richiedono un carico di elaborazione più basso, da quello riservato agli utenti
registrati alle funzionalità analitiche della PUC potenzialmente molto più pesanti
per il server.
22
La sintassi di MySQL non permette la definizione di strutture di controllo iterative all’interno
del campo FROM, mentre i meccanismi di gestione delle query e di prevenzione della sql-injection
in CDE non consentono il necessario livello di dinamismo nella definizione della query associata ad
un componente.
53
Capitolo 7
Conclusioni e spunti per la
prosecuzione del lavoro
A conclusione del percorso di sviluppo descritto nel capitolo precedente, si è provveduto ad analizzarne criticamente i risultati, cercando di far emergere punti deboli
e punti di forza dell’architettura, ma soprattutto degli strumenti utilizzati; dal momento che l’obiettivo principale della ricerca era costituito proprio da un’analisi
ragionata delle caratteristiche di questi ultimi. Per fare ciò, sono state messe sotto
la lente di ingrandimento tutte le componenti del processo di sviluppo del prototipo,
a vario titolo connesse all’utilizzo dei software prescelti, in modo da individuarne
le criticità ed evidenziarne pregi e potenzialità sulla base dell’esperienza diretta
accumulata.
Analizzando la soluzione sviluppata, si può affermare che i requisiti di progettazione definiti in via preliminare siano stati in buona parte soddisfatti, dal momento
che attraverso l’impiego degli strumenti adottati è stato possibile realizzare, compatibilmente con i dati a disposizione, la maggior parte delle funzionalità identificate
tramite la ricerca preliminare; a questo proposito bisogna notare come, contrariamente alle potenziali tecnologie disponibili e a quello che ci si può aspettare dalla
trasposizione del lavoro svolto all’interno di un contesto di lavoro reale, uno degli
ostacoli principali allo sviluppo delle funzionalità analitiche mancanti sia stato costituito dall’assenza dei dati necessari a costruirle (es. dati su occupazione dei locali,
dimensione locali, associazione univoca tra meter e locali...).
Per quanto riguarda gli strumenti software di lavoro (in particolare la piattaforma
Pentaho, che costituiva il principale punto interrogativo) si può viceversa sottolineare
come abbiano dimostrato notevole flessibilità nell’adattamento allo specifico contesto
di lavoro in cui sono stati impiegati, seppur evidenziando alcune lacune specialmente
in merito alla facilità d’uso.
Ovviamente, per una valutazione più accurata del grado di soddisfazione dei requisiti impliciti ed espliciti, che resta al di fuori del perimetro dell’analisi contenuta
54
7 – Conclusioni e spunti per la prosecuzione del lavoro
in questo documento, sarebbe opportuno procedere ad una fase di test del prototipo
con potenziali utenti, gli unici in grado di esaminare in un contesto realmente operativo la bontà delle soluzioni adottate. Nell’ottica di una prosecuzione del lavoro
svolto, e quindi della realizzazione compiuta di un tool di analisi dei dati, questo potrebbe essere sicuramente uno dei primi passi da intraprendere, seguito da revisione
delle scelte progettuali che si rivelassero eventualmente inadeguate.
In questo capitolo si procederà invece a esporre dapprima punti di forza e criticità
dell’architettura software utilizzata emersi come conseguenza diretta del percorso di
sviluppo seguito, per poi passare ad enunciare una serie di considerazioni più generali
sui tool utilizzati, frutto di riflessioni nate durante lo sviluppo e di documentazione
tramite la letteratura disponibile.
7.1
Punti deboli e punti di forza connessi allo
sviluppo del cruscotto interattivo
In prima istanza, sono stati presi in esame gli aspetti negativi e positivi dell’architettura software emersi in maniera più evidente durante lo sviluppo delle varie
componenti del cruscotto, e quindi ritenuti maggiormente correlati con le dinamiche
e le problematiche con cui ci si è dovuti misurare nel corso della realizzazione dello
stesso. La definizione dei due elenchi puntati che seguono è stata infatti il punto
d’arrivo dell’analisi delle varie problematiche di sviluppo registrate, ed in misura più
o meno soddisfacente superate.
Gli aspetti critici con cui fare i conti sono stati sostanzialmente cinque:
• la limitata flessibilità del componente di sviluppo ed esecuzione delle dashboard
nella gestione dinamica dell’accesso ai dati necessari per la generazione dei
grafici di consumo, che, come esposto nella parte conclusiva della Sezione 6.2.5,
ha comportato la scrittura di complicate query SQL e imposto limitazioni alle
modalità di interazione con l’utente implementabili;
• il mancato supporto nativo per l’esposizione dei contenuti pubblicati sul server
anche a vantaggio di utenti anonimi;
• le difficoltà nell’implementazione di funzionalità di esportazione delle analisi
svolte tramite le dashboard in formati statici quali ad esempio file .pdf o simili;
• il basso livello di supporto offerto dai tool di sviluppo integrati nel server
bi per quanto riguarda la cura degli aspetti grafico/estetici delle dashboard
realizzate;
55
7 – Conclusioni e spunti per la prosecuzione del lavoro
• la necessità di generare, e di conseguenza mantenere aggiornate, una serie di
tabelle aggregate indispensabili per innalzare le performance del drill-down
offerto dal motore OLAP interno a Pentaho.
Parallelamente si sono però potuti apprezzare almeno altrettanti punti di forza,
anch’essi intrinsecamente connessi allo specifico processo di progettazione e sviluppo
condotto:
• l’elevata portabilità dell’architettura software sviluppata, che dopo essere stata
sviluppata in ambiente windows si è dimostrata pienamente funzionante anche
in fase di test in ambiente linux, con la necessità di apportare solo piccoli
aggiustamenti;
• la flessibilità degli strumenti nell’adattarsi a contesti di lavoro specifici, evidenziata dalla possibilità di intervenire direttamente sul codice personalizzando le
dinamiche di autenticazione del server BI Pentaho e soddisfacendo in questo
modo specifiche necessità di sviluppo;
• la possibilità di accedere al patrimonio di risorse online costituito dalla documentazione e dagli spazi di confronto tipici della comunità open source, spesso
in grado di fornire soluzioni immediate a problemi non altrettanto banali;
• la possibilità di sfruttare l’interfaccia web e le funzionalità di pubblicazione
diretta dei contenuti offerti dal server Pentaho, che ha consentito di includere
in maniera immediata l’output generato dal server stesso all’interno di un’applicazione Jsp, creando uno strumento che richiede un bassissimo carico di
elaborazione per le macchine client da cui gli utenti possono fruirne;
• infine la possibilità di delegare integralmente le funzioni di autenticazione necessarie al server bi, che tramite alcune piccole modifiche si è dimostrato in
grado di poter gestire in maniera completa le dinamiche di autenticazione
necessarie.
7.2
Considerazioni generali sugli strumenti utilizzati
Come anticipato, si è voluto dare spazio in questo capitolo anche ad alcune considerazioni di carattere maggiormente generale in merito alle impressioni suscitate
dall’insieme di tool di sviluppo utilizzati (sempre con focus principale sulla piattaforma di Business Intelligence Pentaho). Oltre a estenderne la valutazione al di là
dei confini dell’esperienza diretta maturata, vogliono fungere da base di lavoro in
vista di un’eventuale prosecuzione ed approfondimento delle tematiche trattate.
56
7 – Conclusioni e spunti per la prosecuzione del lavoro
Una delle più evidenti e significative caratteristiche emerse, analizzata anche
all’interno di una ricerca condotta dalla Delft University of Technology [25], è costituita dalla necessità di disporre di un livello minimo di conoscenze in termini
di business intelligence e linguaggi di programmazione per poter utilizzare proficuamente la piattaforma Pentaho, cosa che la differenzia notevolmente da molti
strumenti commerciali che spesso fanno della semplificazione operativa uno dei loro
vanti. È importante precisare che ciò non significa che sia indispensabile essere in
possesso di un bagaglio di conoscenze specialistiche sugli argomenti indicati, anzi
appare più che sufficiente avere dimistichezza con alcuni concetti tecnici di base,
ma questa peculiarità risulta sufficiente ad indurre due effetti secondari di opposto tenore: lo svantaggio di una curva di apprendimento relativa all’utilizzo della
piattaforma dall’andamento piuttosto lento, affiancato dalla stimolo per l’utente a
rimanere focalizzato sugli aspetti chiave e sugli scopi delle proprie analisi, evitando di divagare dietro inutili fronzoli. Appare inoltre molto importante, a questo
proposito, evidenziare il fatto che la piattaforma software appaia dotata del giusto
compromesso di “trasparenza” riguardo i meccanismi che ne consentono il funzionamento agli occhi dell’utente [25]: si distingue per essere in grado di semplificare
il compito di analisi dei dati senza tenere l’utente all’oscuro dei meccanismi che lo
permettono, rendendolo immediatamente consapevole dei punti di forza e debolezza
del lavoro che sta svolgendo e delle potenzialità eventulmente disponibili.
Viceversa, la struttura modulare di Pentaho, all’interno della quale si può scegliere di utilizzare una parte o tutti gli strumenti disponibili implementando in maniera
più o meno ampia lo spettro delle funzionalità di Business Intelligence, appare più
disorientante che non efficace. Pur trattandosi di un risvolto dell’ampio spazio operativo potenzialmente supportato dalla piattaforma (attraverso la quale è possibile
coprire funzioni che vanno dall’ETL al data mining), prevale infatti la sensazione
di difficoltà nel far dialogare ed interagire in maniera fluida le varie componenti,
con un conseguente vincolo sulla capacità per l’utente di sfruttarne fino in fondo le
caratteristiche e potenzialità tecniche.
Tra quest’ultime appare comunque necessario ricordare ancora una volta l’elevato livello di connettività out-of-the-box verso le più disparate fonti di dati, che
contraddistingue la piattaforma e le permette di adattarsi proficuamente a contesti
di lavoro molto ampi, spaziando dai dati quasi grezzi presenti in file .csv, ai vari
formati proprietari di Microsoft, proseguendo i più comuni database relazionali e
concludendo con gli attualissimi database noSQL1 .
1
Nel corso della ricerca è stata positivamente testata la capacità di interagire con il database
Apache Cassandra, sviluppato e utilizzato in ambito big data da Facebook per migliorare le performance della ricerca all’interno della casella di posta disponibile all’interno del social network
stesso [26].
57
7 – Conclusioni e spunti per la prosecuzione del lavoro
In conclusione bisogna considerare le limitazioni poste in essere dalle piccole
dimensioni dell’azienda che sviluppa l’intera piattaforma Pentaho2 . Il processo di
crescita che sta subendo, tramite acquisizioni di società affini al suo business e round
di finanziamento3 , non ha ancora permesso di uscire dal ruolo di player di nicchia
all’interno di un mercato dove competono realtà molto più affermate quali IBM, Microsoft, SAS o Microstrategy, nonostante le relazioni con la comunità open source
le permettano di accedere a risorse molto ampie per un’azienda delle sue dimensioni [2]. Resta ancora qualche dubbio circa le azioni di consolidamento ed innovazione
della piattaforma di BI che l’azienda Pentaho potrà mettere in campo, cosı̀ come
sulla possibilità che riesca a continuare a sostenere la strategia di differenziazione
tecnologica rispetto ai competitors tramite l’integrazione con tecnologie Big Data. A
parziale sostegno delle ipotesi più ottimistiche, mentre si sta ultimando la redazione
di questa monografia4 è imminente il lancio della nuova versione della piattaforma,
che promette di essere caratterizzata da una rinnovata e più curata veste grafica, da
una maggior immediatezza d’uso e da un forte accento proprio sulla compatibilità
con i trend tecnologici del momento in tema di databases.
2
L’azienda, con sede a Orlando in Florida, è stata fondata solo nel 2004 e contava a fine 2011
circa 100 dipendenti [27].
3
Secondo dati di Gartner la società avrebbe ricevuto nel corso del 2012 circa 23 milioni di dollari
di capitali tramite venture funding.
4
La versione 5.0 Enterprise Edition (con funzionalità più ampie e a pagamento) è stata rilasciata
all’inizio di settembre 2013, mentre la versione Community Edition dovrebbe vedere la luce nel
corso del mese di novembre (era prevista per ottobre-novembre).
58
Bibliografia
[1] Acre. The evolution of the energy manager from boiler room to board room.
Technical report, Acre Resources, febbraio 2012.
[2] Kurt Schlegel, Rita L. Sallam, Daniel Yuen, and Joao Tapadinhas. Magic
quadrant for business intelligence and analytics platforms, febbraio 2013.
[3] Jeffrey Harris and Elizabeth Shearer. Evaluation of the market-transforming
effects of the us federal energy management program. aprile 2006.
[4] Steven Fawkes. http://www.vesma.com/thefivep.htm, agosto 2001.
[5] Francesco Belcastro and Dario Di Santo. Dall’energy manager alla certificazione
dell’esperto in gestione dell’energia. Technical report, FIRE Italia, 2012.
[6] Patrick Mazza. The smart energy network: Electricity’s third great revolution.
Technical report, Climate Solutions, 2002.
[7] EPA. Energy star and other climate protection partnerships 2009 report.
Technical report, Environmental Protection Agency, dicembre 2010.
[8] Bill Sisson, Constant van Aerschot, and Roger Cowe. Energy efficiency in buildings. Technical report, World business council for sustainable development,
agosto 2009.
[9] Deloitte. resources 2012 study. Technical report, Deloitte, 2012.
[10] Eric Bloom and Bob Gohn. Smart buildings: Top trends to watch in 2012 and
beyond. Technical report, Pike research, 2012.
[11] Eric Bloom and Bob Gohn. Basic and advanced submeter hardware, submeter
energy management software, and submetering services: Market analysis and
forecasts. Technical report, Pike Research, 2012.
[12] Tom Webster. Trends in energy management technologies - part 5: Effectiveness of energy management systems: What the experts say and case studies
reveal. Technical report, Lawrence Berkeley National Laboratory, novembre
2005.
[13] Jessica Granderson. Building energy information systems: User case studies.
Technical report, Lawrence Berkeley National Laboratory, agosto 2010.
[14] S. Aman, Y. Simmhan, and V.K. Prasanna. Energy management systems: state
of the art and emerging trends. Communications Magazine, IEEE, 55(1):114–
119, gennaio 2013.
59
Bibliografia
[15] Nuris Ismail and Matthew Littlefield. Energy intelligence: Driving optimization
with visibility. Technical report, Aberdeen Group, luglio 2011.
[16] Casey Hogan and Rick Nicholson. Big data and analytics for smart buildings.
Technical report, IDC Energy Insights, settembre 2011.
[17] Luı̀s Luciano and Paulo Carreira. Integrating energy data with etl. In Proceedings of the First International Workshop on Information Technology for
Energy Applications, settembre 2012.
[18] Ict opportunities abound as smart metering data concerns persist, says frost &
sullivan, novembre 2012.
[19] Mehul Shah and Matthew Littlefield. Energy management, driving value in
industrial environments. Technical report, Aberdeen Research, aprile 2009.
[20] Sarah Darby. The effectiveness of feedback on energy consumption a review
for defra of the literature on metering, billing and direct displays. Technical
report, Oxford University Environmental Change Institute, aprile 2006.
[21] Matteo Golfarelli, Stefano Rizzi, and Iuris Cella. Beyond data warehousing: what’s next in business intelligence? In Proceedings of the 7th ACM
international workshop on Data warehousing and OLAP, pages 1–6. ACM,
2004.
[22] Asher Feldman. Wikipedia adopts mariadb, aprile 2013.
[23] Matteo Golfarelli, Dario Maio, and Stefano Rizzi. The dimensional fact model:
A conceptual model for data warehouses. International Journal of Cooperative
Information Systems, 7(02n03):215–247, 1998.
[24] Richard Emberson. Mondrian documentation, marzo 2008.
[25] Orhan Tuncer and Jan van den Berg. Implementing bi concepts with pentaho,
an evaluation. Delft University of Technology, 2010.
[26] Avinash Lakshman and Prashant Malik. Cassandra: a decentralized structured
storage system. ACM SIGOPS Operating Systems Review, 44(2):35–40, 2010.
[27] Steven E.F. Brown. Florida’s pentaho hires quentin gallivan as ceo in san
francisco, ottobre 2011.
60