` DEGLI STUDI DI CATANIA

UNIVERSITA
DIPARTIMENTO DI MATEMATICA E INFORMATICA
CORSO DI LAUREA IN INFORMATICA

GIUSEPPE FERRARA

Realizzazione di unapplicazione web per il monitoraggio remoto di

impianti fotovoltaici in rete

Relazione Progetto Finale

Relatore:
Chiar.mo Prof. Giuseppe Pappalardo
Correlatore:
Dott. Christian Napoli

anno accademico 2013-2014

Indice
1 Introduzione

2 LImpianto
2.1 Limpianto fotovoltaico . . . . . . . . . . . .
2.2 La centralina . . . . . . . . . . . . . . . . .
2.3 Sensoristica ambientale . . . . . . . . . . . .
2.3.1 Anemometro e Banderuola . . . . . .
2.3.2 Termoresistore . . . . . . . . . . . .
2.3.3 Igrometro . . . . . . . . . . . . . . .
2.3.4 Solarimetri . . . . . . . . . . . . . .
2.3.4.1 Il piranometro a fotodiodo .
2.3.4.2 Il piranometro a termopila:
2.4 Il database . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.

3
4
4
5
5
6
6
7
7
8
9

.
.
.
.
.
.
.
.
.

10
11
11
12
13
14
14
15
16
16

.
.
.
.

18
18
23
23
24

3 Tecnologie utilizzate
3.1 HTML5 . . . . . . . . . . . . . . . . .
3.2 PHP . . . . . . . . . . . . . . . . . . .
3.2.1 FlightPHP . . . . . . . . . . . .
3.3 MySql . . . . . . . . . . . . . . . . . .
3.4 JavaScript . . . . . . . . . . . . . . . .
3.4.1 jQuery . . . . . . . . . . . . . .
3.4.2 AngularJS . . . . . . . . . . . .
3.4.2.1 Bootstrap . . . . . . .
3.4.3 ChartJS Vs D3 Vs GoogleChart
4 Analisi e Sviluppo
4.1 LAnalisi . . . .
4.2 Sviluppo . . . .
4.2.1 Frontend
4.2.2 Backend

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 Conclusioni

26

Bibliografia

28
i

Elenco delle figure

2.1
2.2

Localizzazione geografica dellimpianto presso i laboratori IDRILAB del Dipartimento di Ingegneria Elettrica, Elettronica e Informatica (DIEEI) dellUniversit`a degli Studi di Catania . . . . . . . .
Limpianto fotovoltaico . . . . . . . . . . . . . . . . . . . . . . . . .

3.1

Schema delle interazioni fra i componenti di unarchitettura MVC . 16

4.1
4.2

Screen del trend Vento Vs Potenza nella web application . . . . . . 21

Screen del grafico RadarChart nella web application . . . . . . . . . 21

ii

3
4

Capitolo 1
Introduzione
In questo documento verr`a descritto il lavoro danalisi e sviluppo di una web application realizzata per consentire la visualizzazione grafica dei dati di sistemi
distribuiti per il monitoraggio e la gestione di impianti fotovoltaici, generalmente
composti da svariati sensori ambientali e da pannelli solari per la per la produzione di energia elettrica. Il progetto nasce dallesigenza di mostrare lo stato degli
impianti e dei sensori, mediante uninterfaccia dotata di grande immediatezza e
che sia al contempo facilmente comprensibile ed user friendly. Lapplicazione in
oggetto `e stata sviluppata e testata presso il laboratorio IDRILAB messo a
disposizione dal DIEEI (Dipartimento di Ingegneria Elettrica Elettronica e Informatica) delluniversit`a degli Studi di Catania. I requisiti principali del progetto,
possono essere sintetizzati in tre punti fondamentali:
1. Si tratta di un sistema distribuito, composto da parti eterogenee distinte ed
interconnesse tra loro.
2. Pu`o essere utilizzato come strumento di confronto per misurare la bont`a di
modelli predittivi.
3. E indipendente dalla piattaforma da dove viene eseguito, mantendendo al
tempo stesso stabilit`a e reattivit`a.

Capitolo 1. Introduzione

Questultima necessit`a orienta il lavoro allo sviluppo di unapplicazione crossplatform, tuttavia questa caratteristica `e gi`a di per se garantita sviluppando una
web application poiche accessibile da ogni browser (senza che questo ne alteri il
funzionamento) e, pertanto, da ogni piattaforma. Negli ultimi anni, infatti, sempre pi`
u applicazioni migrano verso il web, al fine di eliminare le installazioni in
locale e le conseguenti dipendenze dalle piattaforme di esecuzione, ed aggiungendo
alle proprie qualit`a, le caratteristiche di un sistema distribuito immediatamente
accessibile. Per questo genere di applicazioni, viene solitamente utilizzata unarchitettura client-server. Le applicazioni web eseguono in gran parte elaborazioni lato
server senza stato, e passano il risultato al browser del client. Tutte le interazioni
dellutente con lapplicazione sono costituite da semplici scambi e richieste di dati
con il server. Questo tipo di approccio `e stato storicamente utilizzato per le prime
applicazioni sviluppate su web. Queste applicazioni eseguivano semplici operazioni, atte a servire pagine web statiche. Tuttavia un approccio moderno prevede di
sfruttare le risorse computazionali lato client piuttosto che gravare esclusivamente sul server, pertanto lapplicazione sviluppata delega ai client il maggior onere
computazionale. La compatibilit`a cross-platform e la semplicit`a duso, sono state
ritenute come caratteristiche essenziali di questo lavoro e pertanto hanno determinato una serie di criteri da rispettare per lo sviluppo delle funzionalit`a avanzate.
Alcuni esempi di applicazioni web avanzate, sono le interfaccie web di Gmail,
Dropbox e PayPal, ed includono componenti come Ajax, JavaScript e SVG, che
arricchiscono di ulteriori caratteristiche le web application, raggiungendo livelli
di funzionalit`a e reattivit`a simili alle applicazioni tradizionali, senza per`o i limiti
del dominio locale. Nei capitolo 2, verr`a data una breve descrizione del sistema
oggetto di questo studio, dei sensori da cui `e composto delle relative centraline di
gestione del campionamento, e dal database. Il capitolo 3 tratter`a in breve le tecnologie utilizzate per lo sviluppo della web application, con particolare riferimento
ai motivi che hanno portato al loro utilizzo. Infine nel capitolo 4 sar`a descritto il
processo danalisi e sviluppo condotto a partire dai requisiti, dove verranno esposti
i problemi incontrati in queste fasi e le relative soluzioni che hanno infine permesso
la realizzazione finale del progetto.

Capitolo 2
LImpianto
In questa sezione sono elencati i componenti dellimpianto fotovoltaico ed i relativi
sensori ambientali considerati in questo studio, `e inoltre fornita una breve descrizione del loro funzionamento e della tipologia delle entry dei valori registrati sul
database.
Lo sviluppo ed il testing dellapplicazione in questione si `e basato sugli impianti del
laboratorio IDRILAB messo a disposizione dal Dipartimento di Ingegneria Elettrica, Elettronica ed Infotmatica (DIEEI) dellUniversti`a degli Studi di Catania.

Figura 2.1: Localizzazione geografica dellimpianto presso i laboratori IDRILAB del Dipartimento di Ingegneria Elettrica, Elettronica e Informatica
(DIEEI) dellUniversit`a degli Studi di Catania

Capitolo 2. LImpianto

2.1

Limpianto fotovoltaico

Limpianto fotovoltaico del quale vengono campionati i dati utilizzati in questo

studio, `e formato da due stringhe, ognuna composta da sei moduli fotovoltaici
orientati a sud, che erogano una potenza di picco di 2kW.

Figura 2.2: Limpianto fotovoltaico

2.2

La centralina

Limpianto nel suo complesso prevede anche diversi sensori meterologico-ambientali

e le relative centraline per la gestione e linvio dei dati. La centralina preposta
al controllo dellimpianto di produzione energetica interroga i gli inverter a valle
dei pannelli ad intervalli regolari, e invia i dati di intesit`a di corrente, differenza
di potenziale e potenze erogate. Le centraline di monitoraggio metereologico invece inviano i dati di temperatura, umidit`a relativa, radiazione solare, velocit`a e
direzione del vento. Linvio dei dati avviene mediante wireless utilizzando la suite
di protocolli ZigBee [1], un insieme di protocolli di comunicazione ad alto livello,
basati sullo standard IEEE 802.15.4, e che trasmette dati allinterno di una WPAN
(wireless personal area networks), tramite antenne a bassa potenza [2].

Capitolo 2. LImpianto

2.3

Sensoristica ambientale

Limpianto meteo `e composto dai seguenti sei sensori ambientali:

banderuola, anemometro, termoresistore, igrometro, piranometro a termopila e a
fotodiodo. Ogni sensore, ha lo scopo di trasformare il valore ambientale analogico
misurato in informazione digitale, cos` da poter essere memorizzato e utilizzato
da un calcolatore. Di seguito si riporta una breve descrizione dei sensori, con le
rispettive caratteristiche tecniche e i rispettivi intervalli di campionamento.

2.3.1

Anemometro e Banderuola

Lanemometro `e uno strumento utilizzato per misurare la velocit`a e la pressione

del vento. La banderuola `e un semplice strumento che varia la propria posizione
ed il valore associato, in funzione della direzione del vento. I due sensori utilizzati
nellimpianto del caso studio, hanno le seguenti caratteristiche tecniche:

Velocit`
a del vento:
Tipo Coppe in policarbonato con switch
magnetico
Range da 3 a 241 km/h
Accuratezza 3 km/h oppure 5%
Risoluzione 1 km/h
Acquisizione Campionamento ogni 1 min.

Capitolo 2. LImpianto

Tipo Banderuola in ABS con potenziometro

Range Range: da 0 a 360
Accuratezza 7
Risoluzione 1 (da 0 a 360)
Acquisizione Camp. ogni 1 sec e calcolo
direzione dominante ogni 1 min

2.3.2

Termoresistore

Il termoresistore `e un trasduttore che fornisce un segnale elettrico variabile in

posto sul retro del modulo fotovoltaico, ed ha le
funzione della temperatura. E
seguenti caratteristiche:

Temperatura:
Tipo bandgap con uscita digitale
Range da -40C a 123.8C
Risoluzione 0.01C
Accuratezza 1C da -20C a 50C
Acquisizione Campionamento ogni 1 min

2.3.3

Igrometro

Ligrometro `e il sensore per la misura dellumidit`a relativa dellaria, ovvero la

quantit`a di vapore acqueo presente nellatmosfera in un dato instante, in funzione della quantit`a massima di vapore acqueo. Lumidit`a relativa `e un parametro
adimensionale e si esprime in percentuale. Il sensore utilizzato nellimpianto qui

Capitolo 2. LImpianto

descritto ha le seguenti caratteristiche:

Umidit`
a relativa:
Tipo Polimero capacitivo con uscita digitale
Range da 0% a 100%
Risoluzione 0.03%
Accuratezza 2% da 10% a 90%
Acquisizione Campionamento ogni 1 min

2.3.4

Solarimetri

I solarimetri (detti anche piranometri), sono dispositivi di misura della radiazione

solare. Ne esistono di vari tipi, nel caso di studio analizzato, sono stati utilizzati
due tipi di solarimetri allo scopo di migliorarne la precisione:

2.3.4.1

Il piranometro a fotodiodo

Il piranometro a fotodiodo `e un sensore ad effetto fotovoltaico che converte direttamente in energia elettrica la radiazione solare ricevuta. Lenergia cos` generata
`e direttamente proporzionale allirraggiamento solare, e ne indica il valore.

Capitolo 2. LImpianto

8
Radiazione solare:
Tipo fotodiodo in silicio con uscita in tensione
amplificata
Risposta spettrale (10% di punti): da 400 a
1100 nanometri
Risposta coseno (% su lettura): 3% (da 0 a
70 angolo incidente); 10% (da 70 a
85 angolo incidente)
Risposta coseno (% su range totale): 2% (0
to 90)
Coefficiente di temperatura +0.12% per C
Temperatura di riferimento : 25C
Accuratezza 5% del fondoscala
Riferimento Eppley PSP a 1000 W/m2
Acquisizione Campionamento ogni 1 min

2.3.4.2

Il piranometro a termopila:

Il piranometro a termopila `e un dispositivo utilizzato per la misura combinata di

luce solare diretta e diffusa, e basa la sua misura sulla differenza di temperatura
fra pi`
u superfici esposte a rediazione solare, e vengono campionate attraverso delle
termocoppie. Le misure di questo strumento sono lineari. Inoltre, essendo normalmente dotato di un cupolino trasparente, il piranometro a termopila non risente
delleffetto coseno, cio`e lo scostamento dai valori reali che si verifica quando il sole
non `e perpendicolare allo strumento.

Capitolo 2. LImpianto

2.4

Il database

Ogni volta che il server riceve dati dalle centraline, questi vengono memorizzati
allinterno di un database relazionale che contiene i dati precedentemente acquisiti.
Il database viene popolato dunque in maniera concorrente e distribuita, e si occupa
di gestire tutte le richieste valide inoltrate dalla web application.
Per questa funzione, `e stato utilizzato il DBMS MySql, una piattaforma stabile
ed ampiamente diffusa che, grazie alla documentazione disponibile e alla coesione
con le altre tecnologie utilizzate, si `e ben prestata allo scopo.
Questultimo aspetto verr`a meglio approfondito nel prossimo capitolo.

Capitolo 3
Tecnologie utilizzate
In questa sezione verranno descritte le tecnologie utilizzate per la realizzazione
della web application.
La scelta di sviluppare unapplicazione web anziche unapplicazione tradizionale,
ha consentito la realizzazione di uninterfaccia fruibile da qualsiasi dispositivo e
piattaforma, ivi compresi mobile devices come smartphone e tablet, purche muniti
di browser. Basandosi su tale scelta, il lavoro dimplementazione `e stato suddiviso,
secondo il paradigma Client-Server, in due parti: Front-end e Back-end, dove per
font-end si intendono tutte le tecnologie fronte utente, cio`e che definiscono linterfaccia utente, mentre per back-end ci si refiresce a tutte le tecnologie trasparenti
allutente, che lavorano dietro le quinte, al fine di fornire i dati da visualizzare
dal front-end. Nonostante sia vasta la gamma di tecnologie disponibili per lo sviluppo di web application, la scelta di queste ultime `e stata relativamente semplice
e dettata da compatibilit`a, licenza duso e documentazione disponibile.

10

Chapter 3. Tecnologie Utilizzate

3.1

11

HTML5

Recentemente approvato come W3C Recommendation 1 , HTML5 `e la pi`

u recente versione del linguaggio di markup per antonomasia. Tramite questo linguaggio,
vengono definite le pagine web in termini di struttura e contenuti, secondo il modello DOM (Document Object Model), una forma di rappresentazione dei documenti
strutturati come modello orientato agli oggetti.
DOM `e uno standard utilizzato in tutte le pagine web (conformi agli standard
W3C) per rappresentare la struttura della pagina, restando al tempo stesso neutrale alla piattaforma dutilizzo[3].

La crescente richiesta di contenuti multimediali, supportata dal costante miglioramento in termini di velocit`a e distribuzione delle infrastrutture per laccesso a
internet, hanno portato alla definizione duna nuova versione di HTML che supportasse la memorizzazione locale di grosse quantit`a di dati, al fine di poter garantire
lutilizzo di applicazioni web sempre pi`
u complesse.
Fra le novit`a pi`
u interessanti introdotte da HTML5, vi `e il supporto nativo a
Canvas, unestensione che permette il rendering dinamico di immagini bitmap,
gestibili attraverso un linguaggio di scripting. Questultima feature viene utilizzata dalla web application per la realizzazione dinamica di grafici al variare dei
valori selezionati dallutente.

3.2

PHP

PHP `e un linguaggio di programmazione interpretato che viene utilizzato per la

realizzazione di pagine web dinamiche, ossia pagine capaci di modificare dinamicamente il loro contenuto e/o struttura, in base agli input ricevuti.
1

http://www.w3.org/TR/2014/REC-html5-20141028/

Chapter 3. Tecnologie Utilizzate

12

In costante ed attivo sviluppo dal 1995, PHP (acronimo ricorsivo di PHP: Hypertext Preprocessor), viene utilizzato nell82% dei dei siti web2 , fra cui facebook.com, twitter.com e wikipedia.com.
Viene rilasciato sotto PHP license, una licenza libera, simile a GPL, che ne permette la massima fruizione e sviluppo. PHP `e un linguaggio trasparente dal punto
di vista del client e viene principalmente utilizzato per sviluppare applicazioni web
lato server[4].
Nellapplicazione sviluppata in questo studio, PHP `e stato utilizzato per gestire
i flussi di dati richiesti dal client al server e viceversa, interfacciando browser e
database.

3.2.1

FlightPHP

FlightPHP `e un microframework PHP veloce ed estendibile, generalmente utilizzato per la realizzazione di web application RESTful (full-REpresentational State
Transfer). Tra i vantaggi offerti dallutilizzo di questo microframework, vi `e la
possibilit`a di rendere modulare e assolutamente slegata la parte riguardante il
CRUD, ovvero la creazione, la lettura, la modifica e la cancellazione di dati allinterno di un database. Un ulteriore vantaggio dato dallutilizzo di FlightPHP
sta nella possibilit`a di cambiare tipologia di database (Es.da MySql a SQLite)
in maniera estremamente semplice, trasparente e efficiente. Supporta inoltre la
possibilit`a di istansiare classi PHP tramite SPLAutoloader, nel momento in cui
sono veramente necessarie senza importare sorgenti prima e senza inizializzarle.
Grazie a FlightPHP la web application sviluppata risulta composta da due parti
indipendenti, una parte che si occupa esclusivamente di interfacciarsi e restituire
dati dal database (Backend), mentre laltra di visualizzare i dati(frontend)
2

http://w3techs.com/technologies/details/pl-php/all/all

Chapter 3. Tecnologie Utilizzate

3.3

13

MySql

Preferito ad altri DBMS (Database Management System) come PostgreSQL, DB2

e SQLite, MySql `e il gestore di basi di dati relazionale scelto per lo storage management dei dati utilizzati nella web application oggetto di questo studio.
La scelta di questo DBMS `e stata fatta in funzione della sua integrazione con PHP
e dellottimo tool di amministrazione phpMyAdmin.
Il linguaggio per interagire con MySql `e SQL, un semplice linguaggio di interrogazione, tramite il quale `e possibile creare, modificare e appunto interrogare il
DBMS MySql, riguardo i dati in esso contenuti.
In MySQL, la gestione interna dei dati, viene generalmente affidata a uno dei
seguenti Storage Engine:
MyISAM
InnoDB
Nonostante le query di lettura siano significativamente pi`
u veloci utilizzando lo
storage engine MyISAM rispetto alle stesse operazioni effettuate con InnoDB,
considerando che nel sistema in analisi:
La percentuale in istruzioni di scrittura rispetto a quelle in lettura sono di
gran lunga superiori (si basti pensare alla frequenza di campionamento dei
sensori ambientali)
InnoDB offre un controllo dintegrit`a delle transazioni
Lo sviluppo di MyISAM `e fermo da anni
la scelta dutilizzo come storage engine `e chiaramente ricaduta su InnoDB.
Al momento, il database utilizzato nella web application, occupa circa 140MB di
spazio sul disco, contiene 2 tabelle e 64 campi.

Chapter 3. Tecnologie Utilizzate

3.4

14

JavaScript

JavaScript `e il linguaggio di scripting interpretato pi`

u utilizzato per lo sviluppo
web lato front-end; offre allutente uninterfaccia interattiva e reattiva, poiche viene elaborato localmente dal browser ed `e capace di interagire in maniera asincrona
con il server.
Tutti i browser moderni comprendono un performante3 interprete JavaScript (detto JavaScript engine) che `e considerato dagli sviluppatori parte fondamentale del
software, e viene costantemente ottimizzato in ogni release al fine di rendere lelaborazione del codice JavaScript sempre pi`
u efficiente, migliorando cos` lesperienza
di navigazione dellutente, dal momento che si accorciano i tempi delaborazione
degli script.
Lintroduzione di JavaScript ha rivoluzionato la concezione delle pagine web, dando agli sviluppatori la possibilit`a di creare pagine che eseguissero lato client tutte le
operazioni che non necessitano di dati aggiuntivi dal server e distribuiendo dunque
le computazioni anche sul computer del client.

3.4.1

jQuery

jQuery `e una libreria di funzioni Javascript che si propone come obiettivo quello
di semplificare la programmazione lato client delle pagine HTML. Ogni pagina
che ne faccia uso, deve al suo interno dichiararlo, importando un file (solitamente
minificato per occupare meno spazio possibile) che contiene la dichiarazione
delle funzioni pi`
u importanti ed utilizzate in JavaScript. Una volta importato
jQuery, per utilizzare una comune e complessa funzione, baster`a richiamare la
funzione dichiarata nel file minificato. Ci`o permette di ottenere lo stesso risultato
senza dover riscrivere lunghe funzioni standard ed ottenendo cos` un codice pi`
u
compatto e leggibile che meglio si presta ad operazioni di refactoring.
Da questo il motto di jQuery: write less, do more! che descrive a pieno la sua
funzionalit`a.
3

https://developers.google.com/v8/

Chapter 3. Tecnologie Utilizzate

3.4.2

15

AngularJS

AngularJS[5] `e un framework open source sviluppato e distribuito liberamente da

Google sotto MIT license, principalmente utilizzato per lo sviluppo di single-page
applications.
Luso di questo framework impone strutture secondo il modello MVC (ModelView-Controller), un pattern architetturale in grado di separare la logica di presentazione dei dati dalla parte algoritmica che gestisce lo scambio di informazioni
tra una sorgente dati e linterfaccia utente.
Lidea base di questo pattern sta nel separare il software in tre entit`a distine: gestione dati (Model), logica (Controller) e presentazione dei dati (View).
La View prende i dati da mostrare allutente dal Model e, quando lutente interagisce con la View, solitamente cliccando o scrivendo su di essa, il Controller risponde
cambiando i dati del model che a sua volta notifica alla View che ne aggiorna il
contenuto visualizzato.
Nelle applicazioni web dove viene utilizzato AngularJs, la View `e rappresentata dal
DOM, il Controller da JavaScript e il Modello dai dati memorizzati (solitamente
JSON) provenienti da un database tramite backend oppure elaborati direttamente
dal controller.
La struttura MVC `e di facile utilizzo perche fornisce un modello unico per descrivere qualsiasi cosa, dunque utilizzando framework MVC come AngularJS, il
software risultante verr`a sviluppato fin dal principio con una struttura adatta al
refactoring, agevolandone dunque stabilit`a e sviluppo anche da terze parti.

Chapter 3. Tecnologie Utilizzate

16

Figura 3.1: Schema delle interazioni fra i componenti di unarchitettura MVC

AngularJs `e la tecnologia cuore del progetto e ha reso il codice modulare e di facile

riutilizzo.
AngularJS permette inoltre la possibilit`a di espandere le funzionalit`a native con
estensioni proprie o terze parti, dette directive.

3.4.2.1

Bootstrap

Per la gestione dinamica del layout delle pagine, `e stato utilizzato bootstrap, un
framework che agevola lo sviluppo mettendo a disposizione strumenti come layout
a colonne fluidi, e possibilit`a di utilizzare responsive design e altri elementi come
ad esempio model dialog carosel.
Grazie a bootstrap dunque, lapplicazione tiene conto delle caratteristiche del dispositivo utilizzato dal client e adatta la View cos` da garantire una visualizzazione
sempre ottimale.

3.4.3

ChartJS Vs D3 Vs GoogleChart

Per la creazione dinamica dei grafici, sono state analizzate alcune librerie JavaScript e infine ne sono state utilizzate due sulla base dellintegrazione con lambiente AngularJS.

Chapter 3. Tecnologie Utilizzate

17

Google Charts `e una libreria JavaScript che fa della semplicit`a duso il suo punto
forte. Utilizzata nelle prime versioni del progetto, fu poi abbandonata per alcune
restrizioni che non permettono di rispettare a pieno tutti i requisiti richiesti.
ChartJS `e una potente libreria JavaScript che permette la creazione di grafici
tramite lelemento canvas di HTML5. ChartJS `e stato utilizzato per la gestione
del grafico a stella che verr`a descritto nel prossimo capitolo.
D3 (Data-Driven Document) `e una vasta libreria JavaScript creata per la
manipolazione di documenti tramite dati. La propriet`a principale di questa libreria
consiste nella manipolazione del DOM, ed `e particolarmente utile nella creazione
dinamica di immagini da dati.
Per la creazione del grafico principale, `e stato utilizzata NVD3, una directive per
AngularJS basata su D3, che utilizza JSON come formato dati e supporta grafici
a doppio asse Y.

Capitolo 4
Analisi e Sviluppo
In questo capitolo verr`a descritto lapproccio iniziale, le problematiche affrontate e
le soluzioni infine applicate nellimplementazione del progetto, ponendo particolare
enfasi sulle motivazioni che hanno condotto a determinate scelte piuttosto che ad
altre.

4.1

LAnalisi

Fra le caratteristiche del sistema che hanno avuto pi`

u influenza sullo sviluppo del
progetto, vi `e certamente la quantit`a di dati immagazzinati sul database, mole data
dallalta frequenza di campionamento e dal numero di parametri memorizzati per
ongi intervallo di tempo. Come descritto in precedenza, nel sistema sono presenti
sei sensori ambientali, dai quali viene campionata la misura dalle centraline ad
intervalli regolari di un minuto. Per avere unidea pi`
u chiara, al momento sono
prensenti sul database circa 1.400.000 entry dai soli sensori ambientali.
Uno degli scopi del progetto, `e quello di mostrare la relazione fra ogni singolo
parametro ambientale e la potenza erogata dallimpianto. Per fare questo, si `e fatto
uso di grafici combinati a doppia ordinata, ponendo come variabili dipendenti i
valori del sensore selezionato sullasse di destra e i corrispondenti valori di potenza
sullasse di sinistra, mentre come variabile indipendente comune il tempo.
18

Chapter 4. Analisi del progetto

19

Il risultato ottenuto sovrapponendo i due grafici, sar`a un unico grafico che mostra
nelle 24 ore della giornata presa in considerazione, la variazione della potenza in
funzione di ogni sensore selezionato.
Per quanto riguarda lelaborazione dei dati, il sistema `e stato pensato inizialmente
per elaborare lato server le pagine complete di grafici, dando cos` al client la sola
funzione di visualizzazione della pagina cos` come elaborata dal server. A questo proposito, sono state analizzate alcune librerie PHP, dunque back-end, per la
creazione dinamica dei grafici. La pi`
u interessante fra queste `e stata JpGraph, che
consente la randerizzazione dinamica dei grafici su immagini compresse.
Le immagini generate da librerie come JpGraph, sono di tipo raster, ovvero descrivono limmagine come una matrice, dove ogni elemento contiene informazioni
sul pixel corrispondente, senza sfruttare le propriet`a geometriche dellimmagine.
Per questo motivo, la rappresentazione raster si presta bene alla descrizione di
immagini fotorealistiche (difficilmente esprimibili tramite forme geometriche), ma
non altrettanto per immagini geometricamente semplici, come i grafici del caso in
esame, che possono essere descritte tramite istruzioni geometriche anziche grosse
matrici. Su immagini semplici dunque, il vantaggio delle immagini descritte, dette
vettoriali, su quelle raster, `e fortemente apprezzabile in termini di manipolazioni
e spazio occupato, parametro fondamentale per le applicazioni distribuite. Inoltre, lasciare al server la gestione dei grafici `e un approccio obsoleto, oltre che non
scalabile, ed in caso di numerose richieste, la continua randerizzazione dei grafici,
avrebbe potuto creare seri problemi al server in termini di risorse computazionali.
Da queste considerazioni, si `e deciso di focalizzare lo sviluppo della web application
sul lato frontend, lasciando al server solo la gestione delle richieste dei dati grezzi.
Per scambiare dati fra due diverse tecnologie, `e necessario lutilizzo di uno standard
che indichi ad ogni tecnologia come gestire i dati.
Per rendere meglio lidea, `e necessario utilizzare una serie di regole che specifichi
come impacchettare i dati. Due sono gli standard pi`
u utilizzati per questo scopo:
XML (eXtensible Markup Language) e JSON (JavaScript Object Notation). Entrambe le tecnologie sono facilmente leggibili, dunque non necessitano di parsing

Chapter 4. Analisi del progetto

20

complessi.
XML utilizza una struttura dati ad albero, `e pi`
u flessibile sulla tipologia di dati
supportati ed `e possibile utilizzarlo per inviare file.
JSON invece `e pi`
u rigido su questo aspetto, infatti utilizza strutture dati pi`
u
semplici, quali array e matrici. Per questo motivo consente linvio di soli dati ed
`e pi`
u compatto e sicuro di XML, proprio perche non supporta file.
Poiche in questo caso il genere di dati scambiati fra server e client `e semplice, lo
standard utilizzato nellimplementazione della web application, `e JSON.
Se invece fosse stata utilizzata lelaborazione dei grafici lato server con JpGraph, i
dati da scambiare non sarebbero stati veri e propri file. In quel caso sarebbe stato
necessario lutilizzo di XML al posto di JSON [6].
Considerata la frequenza di campionamento dei sensori, e la scelta di mostrare i
grafici per intera giornata, ogni grafico deve visualizzare
1 campionamento 60 minuti 24 ore = 1440 valori

(4.1)

Rappresentare cos` tanti punti, oltre ad essere particolarmente dispendioso in termini di risorse computazionali, rende il grafico confuso e poco leggibile per lutente.
Per ovviare a questo problema, sono state considerate due soluzioni: il sottocampionamento e la media mobile.
Il sottocampionamento consiste nel selezionare da un segnale campionato un solo
valore su un intervallo periodico. La media mobile, invece, fornisce il valor medio
sullintervallo piuttosto che il valore su un solo punto. A seguito di numerose prove
effettuate, `e stato deciso di utilizzare un periodo di 10 elementi, perche considerato
il migliore compromesso fra risoluzione e leggibilit`a.
Per gli scopi di questo lavoro `e stato scelto di utilizzare il metodo della finestra
mobile a 10 campioni; in questo modo si ottiene il segnale medio sottocampionato
con un periodo di 10 minuti(144 punti per ogni giorno).
In termini computazionali, la media mobile `e chiaramente pi`
u dispendiosa del campionamento perche prevede, per ogni giorno selezionato, 144 volte il calcolo della

Chapter 4. Analisi del progetto

21

` altres` vero che i valori risultanti sono pi`

media di 10 elementi. E
u significativi,
e forniscono un risultato pi`
u leggibile e valori pi`
u veritieri, poiche vengono considerati tutti i valori disponibili. Inoltre, per i calcolatori moderni, loperazione di
media semplice `e computazionalmente irrisoria. In aggiunta al grafico sul trend

Figura 4.1: Screen del trend Vento Vs Potenza nella web application

del valore di potenza in funzione dei singoli parametri ambientali (come definito
sopra), si `e scelto di permettere allutente la visualizzazione compatta di tutti i
dati medi giornalieri. Per fare ci`o si `e deciso di utilizzare un grafico RadarChart
(detto anche grafico spider o a stella), grazie al quale `e possibile visualizzare in
ununica immagine tutti i parametri.

Figura 4.2: Screen del grafico RadarChart nella web application

In questo grafico vengono mostrati i valor medi normalizzati dei parametri ambientali e di potenza: ogni volta che lutente seleziona una nuova data, il browser

Chapter 4. Analisi del progetto

22

riceve tutti i valori relativi alla giornata, ne calcola la media, la normalizza, ed

aggiunge il valore cos` ottenuto al RadarChart, descrivendo a colpo docchio la
situazione globale della giornata.
La normalizzazione in [0,1] si `e resa necessaria poiche i valori misurati dai sensori
sono molto eterogenei e diversi anche in ordine di grandezza.
Per normalizzare i valori, sono stati impostati per ogni parametro dei valori di minimo e di massimo, corrispondenti al range di misura del sensore o dellapparato
strumentale. Poiche il grafico a stella visualizza infatti solo valori non negativi,
per alcune scale `e stata necessaria laggiunta di un valore di bias al fine di ottenere sempre valori maggiori di 0. Per tale motivo, per la normalizzazione dei dati
visualizzati `e stato sufficiente aggiungere la bias suddetta (qualora necessario) e
dividere per la dimensione del range di misura.
Ad esempio nel caso della temperatura, per un sensore il cui range di misura va
da Tmin a Tmax , dovendo aggiungere una bias di positivit`a BT , saranno visualizzati valori di temperatura media hT iD relativa allinsieme D dei dati del giorno,
calcolata come
hT iD =

BT +

Ti

iD

|d|(Tmax Tmin )

dove |D| rappresenta la cardinalit`a dellinsieme |D|, ossia il numero totale dei dati
del giorno.

Chapter 4. Analisi del progetto

4.2

23

Sviluppo

Grazie allutilizzo dei framework AngularJs e FlightPHP, limplementazione del

progetto `e stata nettamente separata in due moduli indipendenti.

4.2.1

Frontend

Il modulo frontend `e contenuto allinterno della cartella principale del progetto e

gestisce interamente la visualizzazione dellapplicativo, il parsing dei dati grezzi
in formati manipolabili dalle librerie per la creazione dei grafici, e la comunicazione con il server. Nella root del progetto, `e inoltre contenuto il file .htaccess che
definisce laccesso ai file fornendo istruzioni al webserver sul redirect dei contenuti.

RewriteEngine On
RewriteRule ( api | backend )( $ |/) - [ L ]
RewriteCond %{ R E Q U E S T _F I L E N A M E } ! - f
RewriteRule (.*) $ index . php [ QSA , L ]

Quando il webserver riceve una richiesta di visualizzazione, questa viene intercettata dal file .htaccess che, ad eccezione dei file contenuti nella cartella api e
backend, passa la richiesta al file index.php presente nella root. Il file index.php
integra un sistema di routing interno che gestisce i contenuti da visualizzare in funzione degli input, contiene il DOM, e importa le seguenti librerie: D3 e ChartJS
per la creazione dei grafici, AngularJS per la gestione dinamica dellinterfaccia e
script.js che contiene il core dellapplicazione.
Dentro il file script.js vengono infatti definiti i Controller che gestiscono la logica
delle singole View, dunque i comportamenti dellinterfaccia. Il pi`
u importante fra
questi, `e datiController che definisce la richiesta di dati al server. Quando questo Controller viene inizializzato, vengono eseguite tre chiamate Ajax:
getData che richiede al server lelenco distinto di tutte le date contenenti valori
getSensori che richiede al server la lista dei sensori ambientali
getDati che definisce la richiesta dei valori per il giorno e il sensore selezionato.

Chapter 4. Analisi del progetto

24

Grazie a questa gestione dinamica dei contenuti, lapplicazione viene costantemente aggiornata e mostra allutente solo i dati effettivamente disponibili.
Per meglio intuire la logica del Controller datiController, viene qui di seguito
riportata parte dellimplementazione con la relativa spiegazione dei passaggi.

app . controller ( datiController , function ( $scope , $http ) {

$scope . getAllDate = function () {
$http ({ method : GET , url : api / get_date }). success ( function ( data ) {
$scope . d at eD is po n ib il i = data . result ;
$scope . actData = $scope . d at eD is po n ib il i [0];
if ( $scope . s e n s o r i D i s p o n i b i l i . length > 0) {
$scope . changeModel ();
}
});
}

In questo codice AngularJS, viene definito il Controller per la gestione dei dati
e lutilizzo degli oggetti globali $scope per i dati globali e $http per le chiamate Ajax. Nella seconda riga viene definita la funzione getAllDate che esegue
una chiamata Ajax allurl api/getDate con lo scopo di ottenere dal server lelenco delle date disponibili. Se la richiesta viene eseguita con successo, il dato
richiesto viene restituito nelloggetto data e la funzione pu`o finalmente popolare
larray $scope.dateDisponibili con i nuovi dati. Quando il Controller riceve
i dati, la View si aggiorna visualizzando i dati appena ricevuti e, ogni volta che
lutente cambia il sensore o la data selezionata, il Controller riesegue la funzione
$scope.changeModel() che riaggiorna la View con il grafico relativo alla nuova
richiesta.

4.2.2

Backend

Il modulo backend `e implementato tramite il microframework FlightPHP contenuto allinterno della cartella /api e gestisce il database e le interazione con
esso.

Chapter 4. Analisi del progetto

25

Il file principale del modulo backend `e /api/index.php che inizializza il framework, configura i parametri di accesso al DB MySql e, tramite un sistema
di routing, decide quali dati considerare in funzione del path passato come parametro.
A titolo esemplificativo, viene qui di seguito riportata parte dellimplementazione
backend, relativa alla funzione get sensori per la richiesta al DB dellelenco dei
sensori presenti nella tabella dati.

Flight :: route ( / get_sensori , function () {

$db = Flight :: db ();
$result = $db - > query (
" SELECT DISTINCT TipoSensore FROM dati ORDER BY TipoSensore ASC ");
echo Flight :: json (
array ( code = > 200 , result = > $result - > fetchAll ( PDO :: FETCH_ASSOC )));
});

Nella prima istruzione, viene richiama la funzione db() che esegue la connessione
al database, viene poi definita ed inviata al DB la query per richiedere lelenco
distinto dei sensori ordinati in senso crescente, e infine eseguito il parsing a JSON
del risultato.
In /api/index.php viene dunque gestito tutto il backend dellaplicazione, e definite tutte le query per ricevere i dati dal database e inviare i dati richiesti al
client.
Come per il frontend, anche il backend, ha il proprio file .htacces situato dentro
/api che definisce i redirect per laccesso ai contenuti.

Capitolo 5
Conclusioni
Il presente lavoro di tesi ha avuto come fine quello di realizzare una web application che permettesse di visualizzare graficamente dati riguardanti sensori
meteorologico-ambientali ed impianti di produzione fotovoltaica distribuiti in unarea geografica anche vasta. Questo applicativo `e stato basato su un database sincronizzato che permette la memorizzazione dei dati provenienti dalla rete di sensori
ed impianti. I dati salvati sono stati utilizzati per scopi di analisi e confronto fra
essi, permettendo infine di ottenere un supporto user-friendly per lo studio delle
relazioni che legano lefficienza dellimpianto con i cambiamenti climatici stagionali e non.
Nello specifico, i grafici mostrati dalla web application hanno evidenziato fattori
importanti come il degrado dei moduli fotovoltaici in funzione del tempo, ed il
grado dinfluenza dei fattori ambientali sulla potenza erogata dallimpianto, ponendo laccento sui valori di temperatura ed irraggiamento.
I risultati ottenuti sono soddisfacenti e rispecchiano i requisiti richiesti descritti
nellintroduzione, dunque cross-platform, scalabile, distribuita e modulare.
Limplementazione modulare ha inoltre permesso creazione di unapplicazione performante e predisposta per facilitare lo sviluppo di successive versione e la relativa
attivit`a di refactoring. Lapplicazione si adatta dinamicamente a dati anche di
diversa natura, infatti, per via della sua scalabilit`a e genericit`a, essa pu`o essere
26

Chapter 5. Conclusioni

27

facimente riconvertita per lutilizzo in contesti di altro genere non essendo in alcun modo legata alla tipologia fisica del dato o alla sua raccolta in situ. Tutto ci`o
mantenendo comunque inalterato il core del software.
Nellimplementazione realizzata per il caso di studio `e possibile visualizzare i dati
ambientali relativi a tutto lo storico e le relative serie temporali confrontandoli con la produzione elettrica reale o con dati esterni interpolati tramite modelli
matematici o algoritmi di vario genere quali soprattutto reti neurali e tecniche di
machine learning. Il parsing dei dati dal database al browser viene svolto secondo
quanto previsto, permettendo ai grafici di visualizzare i dati senza alcun artefatto.
Uno dei possibili sviluppi futuri del lavoro svolto e fin qui descritto, `e limplementazione di unestensione per il confronto fra diversi gruppi di pannelli fotovoltaici
di uno stesso impianto, al fine di monitorare per confronto, anomalie e improvvise
derive dovute a danneggiamenti, ombre o sporco atipico, al fine di indicare tempestivamente lesigenza di interventi di manutenzione non ordinaria che altrimenti
verrebbero ignorati.
Infine, la metodologia applicata nello sviluppo di questa applicazione ha posto le
basi al fine di permettere limplementazione di nuovi software per la comparazione
di modelli predittivi, migliorandone la valutazione e stimolandone lo sviluppo.

Bibliografia
[1] Paolo Baronti, Prashant Pillai, Vince WC Chook, Stefano Chessa, Alberto
Gotta, and Y Fun Hu. Wireless sensor networks: A survey on the state of the
art and the 802.15. 4 and zigbee standards. Computer communications, 30(7):
16551695, 2007.
[2] Jose A Gutierrez, Edgar H Callaway, and Raymond L Barrett. Low-rate wireless personal area networks: enabling wireless sensors with IEEE 802.15. 4.
IEEE Standards Association, 2004.
[3] Joe Marini. Document Object Model. McGraw-Hill, Inc., 2002.
[4] Brian Wright. Php: Hypertext preprocessor.
[5] Brad Green and Shyam Seshadri. AngularJS. 2013.
[6] D. Crockford. The application/json media type for javascript object notation
(json) rfc 4627.
[7] F.Bonanno G.Capizzi, C.Napoli. Innovative second-generation wavelets contruction with recurrent neural networks for solar radiation forecasting. IEEE
Transaction on neural networks and learning system, Vol. 23, No. 11, 2012.
[8] Francesco Bonanno, Giacomo Capizzi, G Graditi, C Napoli, and Giuseppe Marco Tina. A radial basis function neural network based approach for the electrical characteristics estimation of a photovoltaic module. Applied Energy, 97:
956961, 2012.

28

Ringraziamenti
Ringrazio tutti coloro che hanno partecipato alla mia formazione accademica:
amici, colleghi, e Professori.
In particolar modo ringrazio Alice per aver contribuito in maniera determinante
alla ripresa e allevoluzione dun percorso di studi interrotto dalla sovrapposizione
con la carriera lavorativa.
I miei genitori, per i valori e lesempio morale di tenacia che li ha sempre contraddistinti, punto di riferimento e sostegno per questo ed ogni obiettivo.
Il collega ed amico Michel con il quale ho condiviso innumerevoli momenti di crescita personale e professionale, per avermi introdotto alle pi`
u recenti tecnologie di
sviluppo web ed essermi sempre stato a fianco nella risoluzione dei problemi dimplementazione.
Un ulteriore importante ringraziamento va al mio corelatore, il Dott. Christian
Napoli, per la pazienza, la disponibilit`a e le conoscenze messe a disposizione nello
sviluppo di questo documento,
Al mio relatore, il Professore Giuseppe Pappalardo, per avermi dato fiducia nel
sviluppare questo progetto in un tempo relativamente breve.
Al Professore Salvatore Riccobene, per la disponibilit`a e i consigli che hanno sostenuto il mio impegno accademico.

Grazie

29