SensoCAT. Sistema de monitorización de datos de sensores de calidad del aire

Treball de Fi de Grau Grau en Enginyeria Inform` atica (GEI) SensoCAT Sistema de monitoritzaci´o de dades de sensors de qualitat de l’aire Autora: Isis Rodr´ıguez Gonz´alez Director: Pau Ferrer Cid Codirector: Jose Maria Barcel´o Ordinas Tutor GEP: Joan Subirats Soler Especialitat: Tecnologies de la Informaci´o (TI) Convocat`oria: Juny 2022 1 Abstract Resum El grup d’investigaci´o SANS t´e desenvolupada una xarxa de sensors de baix cost que mesuren par`ametres atmosf`erics entre els quals es poden trobar sensors de; O3 MOX (metall- `oxid), O3 EQ (electro-qu´ımic), NO2 EQ (electro-qu´ımic), NO EQ (electro-qu´ımic), temperatura, i humitat relativa. Les dades d’aquests sensors es guarden actualment a una base de dades del departament i es poden descarregar en arxius csv. A partir d’una tesi doctoral, actualment encara vigent, s’han desenvolupat uns m`etodes per als sensors de la xarxa. Entre els m`etodes implementats es poden trobar els seg¨uents: m`etode de calibratge, creaci´o de grafs, i reconstrucci´o de senyal. L’aplicaci´o es preparar`a per tal de poder integrar en un futur aquests m`etodes. La idea del projecte ´es desenvolupar un sistema de monitoritzaci´o de dades de sensors de qualitat de l’aire a partir de la xarxa de sensors del grup SANS i que permeti la integraci´o dels m`etodes proporcionats per la tesi doctoral. Aquest sistema es desenvolupar`a en una aplicaci´o web que permetr`a visualitzar les estacions a un pl`anol i accedir a la informaci´o dels sensors d’aquestes. Tamb´e permetr`a crear estacions i pujar arxius csv en els que es troben la informaci´o de les estacions i els informes de les estacions, tant de refer`encia com captors. Resumen El grupo de investigaci´on SANS tiene desarrollada una red de sensores de bajo coste que miden par´ametros atmosf´ericos entre los cuales se pueden encontrar sensores de; O3 MOX (metal-oxido), O3 EQ (electroqu´ımico), NO2 EQ (electroqu´ımico), NO EQ (electroqu´ımico), temperatura, y humedad relativa. Los datos de estos sensores se guardan actualmente en una base de datos el departamento y se pueden descargar en archivos csv. A partir de una tesis doctoral, actualmente en curso, se han desarrollado unos m´etodos para los sensores de la red. Entre los m´etodos implementados se pueden encontrar los siguientes: m´etodo de calibraci´on, creaci´on de gr´aficos, y reconstrucci´on de se˜nal. La aplicaci´on se preparar´a por tal de poder integrar en un futuro estos m´etodos. 2 La idea del proyecto es desarrollar un sistema de monitorizaci´on de datos de sensores de calidad del aire a partir de la red de sensores del grupo SANS y que permita la integraci´on de los m´etodos proporcionados por la tesis doctoral. Este sistema se desarrollar´a en una aplicaci´on web que permitir´a visualizar las estaciones en un mapa y acceder a la informaci´on de los sensores de estas. Tambi´en permitir´a crear estaciones y subir archivos csv en los que se encuentra la informaci´on de las estaciones y los informes de las estaciones, tanto de referencia como captor. Abstract The SANS investigation group has developed a network of low-cost sensors that measure atmospheric parameters, among which sensors can be found; O3 MOX (metal-oxide), O3 EQ (electrochemical), NO2 EQ (electrochemical), NO EQ (electrochemical), temperature, and relative humidity. The data from these sensors is currently stored in a database owned by the department and can be downloaded as csv files. From a doctoral thesis, currently in progress, some methods have been developed for the network’s sensors. Among the methods implemented, the following can be found: calibration method, creation of graphs, and signal reconstruction. The application will be prepared in order to be able to integrate these methods in the future. The idea of the project is to develop an air quality sensor data monitoring system based on the SANS group sensor network that allows the integration of the methods provided by the doctoral thesis. This system will be developed in a web application that will allow the stations to be viewed on a map and access to the information from their sensors. It will also allow the creation of stations and uploading csv files containing station’s information and station’s reports, from both reference and captor stations. 3 ´ Index de continguts 1 Introducci´o 9 1.1 Identificaci´o del problema . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2 Definicions................................... 10 1.3 Actors ..................................... 10 1.4 Justificaci´o................................... 11 1.5 Abast ..................................... 12 1.6 Objectiu.................................... 12 1.6.1 Subobjectius ............................. 12 1.7 Requisits.................................... 12 1.7.1 Requisits funcionals . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.7.2 Requisits no funcionals . . . . . . . . . . . . . . . . . . . . . . . . 13 1.8 Riscos ..................................... 13 2 Metodologia i rigor 15 2.1 Metodologia de treball . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Controldeversions.............................. 15 2.3 Desviaci´o sobre la planificaci´o original . . . . . . . . . . . . . . . . . . . . 16 2.4 Planificaci´o temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.1 Descripci´o de les tasques . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.2 Tasques de gesti´o de projecte . . . . . . . . . . . . . . . . . . . . 17 2.4.3 Tasques de desenvolupament . . . . . . . . . . . . . . . . . . . . . 18 2.4.4 Tasques de comprovaci´o del funcionament . . . . . . . . . . . . . 19 2.5 Recursos.................................... 19 2.5.1 Humans ................................ 19 2.5.2 Materials ............................... 20 2.6 Desviaci´o sobre la planificaci´o original . . . . . . . . . . . . . . . . . . . . 20 2.7 EstimacionsiGantt.............................. 22 2.8 Desviaci´o sobre la planificaci´o original . . . . . . . . . . . . . . . . . . . . 24 4 2.9 Gesti´o del risc: Plans alternatius i obstacles . . . . . . . . . . . . . . . . 27 2.10Pressupost................................... 28 2.11 Identificaci´o i estimaci´o dels costos . . . . . . . . . . . . . . . . . . . . . 28 2.11.1Recursoshumans ........................... 28 2.11.2 Hardware ............................... 29 2.11.3 Software ................................ 29 2.11.4 Despeses generals . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.11.5 Conting`encies i imprevistos . . . . . . . . . . . . . . . . . . . . . 30 2.11.6 Balan¸c de despeses . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.12Controldegesti´o ............................... 33 2.13 Informe de sostenibilitat . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.13.1 Dimensi´o econ`omica . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.13.2 Dimensi´o ambiental . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.13.3Dimensi´osocial............................ 35 2.14 Integraci´o de coneixements . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.15Lleisiregulacions............................... 38 3 Arquitectura i tecnologies 39 4 Desenvolupament: Backend 42 4.1 SSR (Server Side Rendering) ........................ 42 4.2 Base de dades: DynamoDB ......................... 44 4.3 Framework: Flask ............................... 48 4.3.1 /home ................................. 49 4.3.2 /home/chart table/<station name>/<sensor>/<initial date>/<final date>51 4.3.3 /newstation.............................. 52 4.3.4 /new station/submit station . . . . . . . . . . . . . . . . . . . . . 52 4.3.5 /upload ................................ 52 4.3.6 /upload/submit csv . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.3.7 /about................................. 53 5 Desenvolupament: Templates 54 5 5.1 home.html................................... 57 5.2 charttable.html................................ 65 5.3 newstation.html ............................... 70 5.4 submitstation.html.............................. 72 5.5 upload.html .................................. 73 5.6 submitcsv.html................................ 74 5.7 about.html................................... 76 6 Conclusions 77 ´ Index de figures 1Workflow amb branques en GitHub [font [9]]. ............... 16 2 Diagrama de Gantt de la divisi´o de tasques en el temps. . . . . . . . . . 23 3 Nou diagrama de Gantt de la divisi´o de tasques en el temps. . . . . . . . 26 4 Diagrama de l’arquitectura de l’aplicaci´o: petici´o de l’usuari d’una p`agina web al servidor Flask en cas de ser necessari aquest ´es el qui es connecta mitjan¸cant m`etodes en python a la base de dades d’AWS per fer operacions. 41 5 Diagrama del funcionament del SSR: 1. Sol·licitud de p`agina, 2. Operacions pertinents i preparaci´o del document HTML per renderitzar, 3. El navegador renderitza l’arxiu, 4. El navegador es descarrega el Javascript, 5. Les interaccions amb la p`agina ara son possibles, 6. El navegador executa el framework de Javascript, 7. P`agina funcional. . . . . . . . . . 42 6 Codi de la creaci´o de la taula estacions. . . . . . . . . . . . . . . . . . . . 44 7 Codi de la creaci´o de la taula informes. . . . . . . . . . . . . . . . . . . . 46 8 Codi de la petici´o dels timestamps m´ınims i m`axims de cada estaci´o. . . 49 9 Codi, per a estacions amb informes, de l’inicialitzaci´o de les variables initial date ifinal date amb els timestamps m´ınims i m`axims de l’estaci´o, query per aconseguir les ´ultimes lectures de cada sensor per als timestamps m´ınims i m`axims de l’estaci´o, inicialitzaci´o de la variable last readings, i bucle pel formatat de last readings. ..................... 50 10 Codi, per a estacions sense informes, de l’inicialitzaci´o de les variables initial date,final date ilast readings a’nan’................. 50 6 11 Codi de l’actualitzaci´o els timestamps m´ınims i m`axims, i l’´ultima lectura de cada sensor, de l’estaci´o per la qual s’itera. . . . . . . . . . . . . . . . 51 12 Codi de la petici´o de les tuples existents donat el nom d’un sensor i un rangdedates.................................. 51 13 Model UX de les pantalles ’Inici’ i’GraficaTaula’.............. 55 14 Model UX de les pantalles ’CrearEstacio’,’NovaEstacioCreada’,’PujarArxiu’ i’ArxiuPujat’. .............................. 56 15 P`aginad’inici.................................. 57 16 Spiderfier: desplegable per a pins d’estacions amb la mateixa latitud i longitud..................................... 58 17 Desplegable al pr´emer el pin. . . . . . . . . . . . . . . . . . . . . . . . . . 59 18 Finestra modal d’una estaci´o sense informes associats. . . . . . . . . . . . 59 19 Finestra modal d’una estaci´o amb informes associats. . . . . . . . . . . . 60 20 Finestra modal d’una estaci´o amb informes associats i l’opci´o de visualitzaci´o d’ultima lectura activada. . . . . . . . . . . . . . . . . . . . . . . . 61 21 Men´u desplegable amb els sensors de l’estaci´o en la finestra modal d’una estaci´o amb informes associats. . . . . . . . . . . . . . . . . . . . . . . . 62 22 Desplegable data en la finestra modal d’una estaci´o amb informes associats. 62 23 Desplegable hora en la finestra modal d’una estaci´o amb informes associats. 63 24 Codi de la creaci´o de la URL ahome.html per a fer la petici´o a /chart table. 64 25 Gr`afica de les lectures d’un sensor entre dues dates. . . . . . . . . . . . . 65 26 Punt de la gr`afica de les lectures d’un sensor entre dues dates. . . . . . . 66 27 Codi de la creaci´o de la gr`afica. . . . . . . . . . . . . . . . . . . . . . . . 67 28 Taula de les lectures d’un sensor entre dues dates. . . . . . . . . . . . . . 68 29 Codi de la creaci´o de la taula. . . . . . . . . . . . . . . . . . . . . . . . . 68 30 Formulari per crear una nova estaci´o. . . . . . . . . . . . . . . . . . . . . 70 31 Formulari per crear una nova estaci´o amb camps de sensors afegits. . . . 71 32 Missatge per informar a l’usuari de que l’estaci´o s’ha creat correctament. 72 33 Formulari per pujar un arxiu. . . . . . . . . . . . . . . . . . . . . . . . . 73 34 Men´u desplegable de les opcions dels arxius a pujar. . . . . . . . . . . . . 74 35 Missatge per informar a l’usuari de que s’han pujat les dades correctament. 75 36 P`agina ’Sobre nosaltres’. . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 7 ´ Index de taules 1 Distribuci´o d’hores de les tasques amb les seves depend`encies. . . . . . . 22 2 Nova distribuci´o d’hores de les tasques amb les seves depend`encies. . . . 24 3 Impacte, probabilitat, i pla alternatiu de cada risc. . . . . . . . . . . . . 27 4 Cost per hora segons el rol. . . . . . . . . . . . . . . . . . . . . . . . . . 28 5 Cost del hardware iamortitzaci´o. ...................... 29 6 Cost del software iamortitzaci´o........................ 29 7 Despeses generals en euros (al mes i al finalitzar el projecte). . . . . . . . 30 8 Cost de conting`encies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9 Riscos associats al projecte i el seu cost brut. . . . . . . . . . . . . . . . . 30 10 Costos associats al projecte. . . . . . . . . . . . . . . . . . . . . . . . . . 32 11 Resum de les tecnologies emprades al projecte. . . . . . . . . . . . . . . . 40 12 Format de la taula d’estacions. . . . . . . . . . . . . . . . . . . . . . . . . 45 13 Format de la taula d’informes. . . . . . . . . . . . . . . . . . . . . . . . . 46 14 Descripci´o de les rutes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 15 Diferents formats dels Timestamps segons l’estaci´o. . . . . . . . . . . . . 53 16 Funcionalitats de les templates. ....................... 54 8 2 Metodologia i rigor 2.1 Metodologia de treball En aquest projecte s’utilitzar`a la metodologia en cascada, que consisteix en una metodologia lineal, per lo que per tal d’iniciar una nova etapa cal acabar l’anterior. La metodologia es podria dividir en les seg¨uents tasques: •An`alisi dels requisits dels usuaris finals. •Disseny del sistema agafant els requisits dels usuaris finals i dividint-los en grups de treball i relacionant-los entre s´ı definint una arquitectura. •Escollir les eines pel desenvolupament del projecte. •Implementaci´o del codi font. •Probes i soluci´o d’errors o bugs. •Test final del projecte per veure que tot funciona segons lo esperat. 2.2 Control de versions Per tal de poder realitzar un control de versions i poder guardar el codi font s’utilitzar`a Github. Dins de Github ens permet tenir diverses branques. S’utilitzaran tres tipus de branques; la master, la dev, i la feature. La branca principal master es la branca que cont´e la versi´o del codi que funciona correctament. La branca dev odevelopment ens permet comprovar que tot funcioni correctament abans d’enviar els canvis a la branca master. Finalment, la branca feature es sobre la que es treballar`a i provar`a abans d’enviar els canvis a la branca dev. D’aquesta manera es pot accedir a les versions anteriors en cas de tenir un error en la que estem treballant i es pot diferenciar quines son les versions sense errors i que fan correctament una funcionalitat de les que estan en fase de desenvolupament i en mode esborrany. 15 Figura 1: Workflow amb branques en GitHub [font [9]]. 2.3 Desviaci´o sobre la planificaci´o original Respecte la metodologia i rigor s’ha seguit el pla original establert. S’ha seguit la metodologia en cascada proposada inicialment i la divisi´o de tasques proposada ´es la utilitzada. En vers al control de versions ha hagut un lleuger canvi. S’ha utilitzat Github per tenir un control de versions, com es va mencionar originalment, per`o no s’ha fet us de les branques. Al ser una sola persona la que desenvolupa el projecte i al no ser un projecte de grans dimensions, amb una sola branca, la master en aquest cas, es pot mantenir un correcte historial de versions. A l’hora de prendre aquesta decisi´o tamb´e va influir el fet de que s’han anat implementant les funcionalitats en blocs petits per lo que a l’hora de fer push s’anaven afegint noves funcionalitats completes donant aix´ı la possibilitat d’anar enrere a alguna versi´o sense tenir problemes. 16 2.4 Planificaci´o temporal 2.4.1 Descripci´o de les tasques El projecte es divideix en tres tipus de tasques; les tasques de gesti´o de projecte (TG), les tasques de desenvolupament (TD), i les tasques de comprovaci´o de funcionament (TC). Les tasques de gesti´o de projecte s´on les tasques encarregades a gestionar i a documentar el treball. Entre elles estaria inclosa la documentaci´o de GEP, la documentaci´o del seguiment del projecte, i la presentaci´o final. Les tasques de desenvolupament s´on les tasques que cobreixen el desenvolupament de la part pr`actica del projecte. Aquestes tasques van des de la preparaci´o del projecte fins el desenvolupament de cada una de les parts de les que es composa el projecte en s´ı. Finalment, les tasques de comprovaci´o de funcionament s´on les que serviran per a verificar el correcte funcionament de l’aplicaci´o creada en aquest treball i en les que s’arregla el codi en cas de trobar-se errors o bugs a l’aplicaci´o. 2.4.2 Tasques de gesti´o de projecte •[TG1] Context i abast: primer lliurament de GEP en el que es defineix el context, la justificaci´o, l’abast, i la metodologia i rigor del projecte. –Durada aproximada: 25h –Depend`encies: sense depend`encies •[TG2] Planificaci´o temporal: segon lliurament de GEP en el que es fa la descripci´o de tasques, estimacions i Gantt, i gesti´o del risc. –Durada aproximada: 15h –Depend`encies: sense depend`encies •[TG3] Pressupost i sostenibilitat: tercer lliurament de GEP en el que s’identifiquen i s’estimen els costos, es fa control de gesti´o, i informe de sostenibilitat. –Durada aproximada: 25h –Depend`encies: sense depend`encies •[TG4] Document final GEP: quart i ´ultim lliurament de GEP que cont´e totes les entregues anteriors amb les correccions pertinents indicades pel tutor de GEP. 17 –Durada aproximada: 15h –Depend`encies: TG1, TG2, TG3 •[TG5] Documentaci´o del projecte: document que cont´e el seguiment del projecte i que s’amplia amb aquest. –Durada aproximada: 30h –Depend`encies: sense depend`encies •[TG6] Document final: document final resultant del projecte, que ´es la part escrita del TFG. –Durada aproximada: 15h –Depend`encies: TG4, TG5 •[TG7] Presentaci´o final: document que cont´e la presentaci´o del treball fet en aquest TFG. –Durada aproximada: 10h –Depend`encies: TG6 2.4.3 Tasques de desenvolupament •[TD1] Preparaci´o del projecte: concreci´o de l’estructura b`asica del programa, divisi´o de tasques amb el director del TFG i preparaci´o del repositori Github. –Durada aproximada: 20h –Depend`encies: sense depend`encies •[TD2] Disseny i creaci´o de la base de dades: concreci´o de l’estructura b`asica de la base de dades segons les caracter´ıstiques dels sensors que es volen emmagatzemar. Creaci´o de la base de dades segons l’estructura definida. –Durada aproximada: 60h –Depend`encies: sense depend`encies •[TD3] Creaci´o d’una llibreria de m`etodes: creaci´o d’una llibreria de m`etodes, ja desenvolupats, per tal de poder utilitzar-los en el sistema de monitoritzaci´o. –Durada aproximada: 60h –Depend`encies: sense depend`encies 18 •[TD4] Programaci´o de les plantilles: creaci´o d’un visor que mostri els resultats recollits pels sensors i emmagatzemats a la base de dades. Tamb´e cal que doni la possibilitat a l’usuari de fer operacions CRUD a la base de dades i utilitzar els m`etodes de la llibreria de m`etodes. –Durada aproximada: 110h –Depend`encies: TD1, TD2, TD3 •[TD5] Reunions de seguiment: reunions setmanals o bisetmanals amb el director i codirector del projecte. –Durada aproximada: 25h –Depend`encies: sense depend`encies 2.4.4 Tasques de comprovaci´o del funcionament •[TC1] Creaci´o de jocs de prova: creaci´o de tests per tal de verificar que l’aplicaci´o funciona correctament. –Durada aproximada: 20h –Depend`encies: TD4 •[TC2] Eliminaci´o de bugs o errors: temps dedicat a arreglar els bugs o errors trobats a l’aplicaci´o. –Durada aproximada: 30h –Depend`encies: TC1 2.5 Recursos 2.5.1 Humans •Manager de projecte: encarregat de supervisar i guiar el projecte, assegurant-se que s’est`a desenvolupant correctament. •Desenvolupador: encarregat del disseny i implementaci´o del projecte. •Tester:responsable de fer les probes pertinents per garantir el correcte funcionament i la robustesa del projecte. 19 2.5.2 Materials •Ubuntu: sistema operatiu en el que es desenvolupar`a el projecte. •Sensors: dispositius emprats per a la captura de dades. •Amazon DynamoDB: base de dades no relacional en la que es guardaran les dades capturades pels sensors. •Flask: framework de desenvolupament de codi obert sobre el qual es desenvolupar`a l’aplicaci´o. •Python: llenguatge de programaci´o amb el qual es desenvoluparan els m`etodes de l’aplicaci´o. •Github: programa espec´ıfic per utilitzar GIT, que es un sistema dissenyat per controlar versions en un entorn Linux. •Google Meet: aplicaci´o per la qual es faran les reunions de seguiment amb director i co-director del projecte. 2.6 Desviaci´o sobre la planificaci´o original El projecte, com es pot veure als apartats anteriors, s’ha desglossat en tres tipus de tasques; les tasques de gesti´o del projecte (TG), les tasques de desenvolupament (TD), i les tasques de comprovaci´o o de funcionalitat (TC). Les tasques de gesti´o s’estan complint acord a la planificaci´o original. Aix`o es deu a que la majoria de les tasques d’aquest tipus son tasques de documentaci´o, les quals una part ja s’han dut a terme en GEP, i la resta que queden s’estenen sobre la durada de tot el projecte. En quant a les tasques de desenvolupament si que ha hagut un canvi respecte lo plantejat inicialment. Per una banda, la tasca [TD3], que consistia en la creaci´o d’una llibreria de m`etodes, ha sigut cancel·lada degut a que aquests m`etodes ja son actualment a una llibreria i no cal crear-la per tal de poder utilitzar-los. Per altre banda, s’hauria d’afegir una nova tasca en el seu lloc que tindria a veure amb la creaci´o dels m`etodes de les rutes, ja que ha sigut una part bastant important del projecte que ha consumit una quantitat d’hores considerables. Cal tenir en compte que aquesta nova tasca tindria com a depend`encia la tasca [TD2], degut a que, els m`etodes que s’han creat, en major part, necessiten fer operacions CRUD a la base de dades, per lo que cal que aquesta estigui 20 ben dissenyada. Les tasques de comprovaci´o del funcionament es compliran segons lo planejat, per`o cal recalcar que son tasques que encara que en la planificaci´o [apartat 2.7] es posin al final de tot del projecte es duen a terme durant tot el seu desenvolupament. Per lo que un cop fetes aquestes observacions, els canvis respecte la planificaci´o original quedarien de la seg¨uent manera: •[TD1] Preparaci´o del projecte: concreci´o de l’estructura b`asica del programa, divisi´o de tasques amb el director del TFG i preparaci´o del repositori Github. –Durada aproximada: 20h –Depend`encies: sense depend`encies •[TD2] Disseny i creaci´o de la base de dades: concreci´o de l’estructura b`asica de la base de dades segons les caracter´ıstiques dels sensors que es volen emmagatzemar. Creaci´o de la base de dades segons l’estructura definida. –Durada aproximada: 60h –Depend`encies: sense depend`encies •[TD3] Programaci´o dels m`etodes de les rutes: creaci´o de m`etodes que permetin fer les funcionalitats establertes a les templates, com les operacions CRUD a la base de dades –Durada aproximada: 60h –Depend`encies: TD2 •[TD4] Programaci´o de les plantilles: creaci´o d’un visor que mostri els resultats recollits pels sensors i emmagatzemats a la base de dades. Tamb´e cal que doni la possibilitat a l’usuari de fer operacions CRUD a la base de dades mitjan¸cant l’emplenament de formularis, les dades dels quals seran tractades internament per fer les operacions CRUD esmentades. –Durada aproximada: 110h –Depend`encies: TD1, TD2, TD3 •[TD5] Reunions de seguiment: reunions setmanals o bisetmanals amb el director i codirector del projecte. –Durada aproximada: 25h –Depend`encies: sense depend`encies 21 2.7 Estimacions i Gantt En la seg¨uent taula es mostren les tasques establertes pel projecte amb les seves respectives hores a dedicar i les tasques de les que depenen cadascuna d’elles. Tasca Hores Depend`encies TG1 25 - TG2 15 - TG3 25 - TG4 15 TG1, TG2, TG3 TG5 30 - TG6 15 TG4, TG5 TG7 10 TG6 TD1 20 - TD2 60 - TD3 60 - TD4 110 TD1, TD2, TD3 TD5 25 - TC1 20 TD4 TC1 30 TC1 Total 460 - Taula 1: Distribuci´o d’hores de les tasques amb les seves depend`encies. Per tal de veure les tasques millor distribu¨ıdes en el temps s’han distribu¨ıt temporalment en un diagrama de Gantt [figura 3]. 22 Figura 2: Diagrama de Gantt de la divisi´o de tasques en el temps. 23 2.8 Desviaci´o sobre la planificaci´o original En aquest apartat s’actualitzaran tant la taula de distribuci´o d’hores de les tasques amb les seves depend`encies [taula 1], com les tasques distribu¨ıdes en el temps que podem trobar en el diagrama de Gannt [figura 3]. Com podem veure a la taula [taula 2] l’´unic canvi que hi ha hagut ha sigut la nova depend`encia que ara [TD3] t´e sobre [TD2]. Tasca Hores Depend`encies TG1 25 - TG2 15 - TG3 25 - TG4 15 TG1, TG2, TG3 TG5 30 - TG6 15 TG4, TG5 TG7 10 TG6 TD1 20 - TD2 60 - TD3 60 TD2 TD4 110 TD1, TD2, TD3 TD5 25 - TC1 20 TD4 TC1 30 TC1 Total 460 - Taula 2: Nova distribuci´o d’hores de les tasques amb les seves depend`encies. Respecte la planificaci´o temporal establerta al diagrama de Gantt original [figura 3] hi ha hagut una alteraci´o en la duraci´o de les tasques. Durant el desenvolupament del projecte han sortit errors que han fet necess`aria la modificaci´o de tasques anteriors. Un cop iniciada una nova tasca, en m´es d’una ocasi´o, ha calgut modificar tasques anteriors de desenvolupament degut a que l’elecci´o en el moment de desenvolupament mancava de funcionalitats que posteriorment serien necess`aries, havent de tornar enrere per millorar el disseny i implementaci´o de la tasca per donar suport a aquestes funcionalitats. Com s’ha mencionat a l’apartat de desviaci´o sobre la planificaci´o original de l’apartat anterior [apartat 2.5.2], les tasques de comprovaci´o del funcionament son tasques que encara que en la planificaci´o [apartat 2.7] es posin al final de tot del projecte es duen a terme durant tot el seu desenvolupament. S’ha decidit ficar-les al final del projecte ja que durant el desenvolupament del projecte formarien part del propi desenvolupament i no 24 2.11.6 Balan¸c de despeses El balan¸c de despeses es calcula sumant tots els costos calculats anteriorment; recursos humans, hardware,software, despeses generals, conting`encies i imprevistos. 31 T´ıtol Hores Responsable Cost en euros (brut) TG1 25 Manager del projecte 731,975 TG2 15 Manager del projecte 439,185 TG3 25 Manager del projecte 731,975 TG4 15 Manager del projecte 439,185 TG5 30 Manager del projecte 878,37 TG6 15 Manager del projecte 439,185 TG7 10 Manager del projecte 292,79 TD1 20 Desenvolupador 372,12 TD2 60 Desenvolupador 1.116,36 TD3 60 Desenvolupador 1.116,36 TD4 110 Desenvolupador 2.046,66 TD5 25 Desenvolupador 465,15 TC1 20 Tester 376,02 TC1 30 Desenvolupador 558,18 Total 460 - 10.003,515 Ordinador - - 92,422 Monitor - - 15,68 Ubuntu - - 0 AWS DynamoDB - - 34,35 Flask - - 0 Github - - 0 Google Meet - - 0 Total - - 142,45 Internet - - 160 Llum - - 532 Total - - 692 Conting`encia recursos humans - - 1.500,527 Conting`encia Hardware - - 16,215 Conting`encia Software - - 5,15 Conting`encia despeses generals - - 103,8 Total - - 1.625,692 Limitaci´o de temps 10 Manager del projecte 292,79 Errors o bugs 20 Desenvolupador 372,12 Inexperi`encia 10 Desenvolupador 186,06 Total 40 - 851,01 Total final - - 12.622,667 Taula 10: Costos associats al projecte. 32 2.12 Control de gesti´o El control de gesti´o permet tenir un control sobre les possibles desviacions del pressupost. Per realitzar aquests c`alculs es dividiran les despeses en sis grups com en els apartats anteriors; recursos humans, hardware,software, despeses generals, conting`encies i incid`encies. Per comen¸car, es calcular`a la desviaci´o de les tasques dutes a terme pel personal participant al projecte. Mitjan¸cant la seg¨uent f´ormula tamb´e es calcular`a la desviaci´o per imprevistos ja que t´e en compte al personal de la mateixa manera. •Desviaci´o recursos humans i imprevistos = (cost estimat per hora * total d’hores de la tasca) – (cost real per hora * total d’hores reals de la tasca) Seguidament, es calcularan les desviacions dels costos del hardware,software, despeses generals, i conting`encies, ja que al no dependre de les hores es calcula de la mateixa forma en totes elles. •Desviaci´o costos hardware = cost estimat – cost real •Desviaci´o costos software = cost estimat – cost real •Desviaci´o despeses generals = cost estimat – cost real •Desviaci´o conting`encies = cost estimat – cost real Finalment, es realitzar`a el c`alcul de la desviaci´o total del projecte. •Desviaci´o = cost estimat – cost total 33 2.13 Informe de sostenibilitat Aquest informe t´e molta import`ancia a l’hora de fer un projecte ja que fa que es plantegin preguntes que poden millorar el treball tant en l’`ambit econ`omic, com en el social i en l’ambiental. Despr´es de fer l’enquesta he pogut veure que no sempre es dona la mateixa import`ancia a tots els `ambits, ja que es sol fer especial atenci´o a l’`ambit econ`omic que ´es lo que m´es pot impactar negativament en un projecte, des del meu punt de vista. Pel que fa a l’`ambit social lo que generalment es sol preguntar ´es qu`e es vol aconseguir, com es vol millorar la qualitat de vida fent aquest projecte, per`o potser no ens fixem tant en qu`e ens pot aportar a nosaltres a nivell personal o si ´es realment necessari. Des del meu punt de vista, a vegades no hi ha una necessitat real en tots els projectes, ja que no tots van m´es enll`a del guany econ`omic. L’impacte ambiental es pot veure augmentat per culpa d’alguns projectes que no s´on realment necessaris per lo que ´es un punt a tenir en compte. Per ´ultim, l’`ambit ambiental ´es un factor que com a inform`atica no solc pensar gaire ja que sol ser m´ınim. Penso que sempre s’hauria d’aprofitar el hardware fins que aquests deixi de funcionar correctament (i que no es puguin arreglar) ja que els materials dels quals estan composats solen ser escassos, i a vegades es canvia sense necessitat real. En altres `ambits penso que la inform`atica no t´e gaire impacte, per`o sempre que hi hagi una millora ambientalment ´es important analitzar on ´es pot millorar per tal de tenir el menor impacte possible. A continuaci´o s’analitzaran les preguntes de l’enquesta realitzada separant-les en el tres `ambits diferents dels que hem parlat; dimensi´o econ`omica, ambiental, i social. 2.13.1 Dimensi´o econ`omica Per poder realitzat una aproximaci´o del cost del projecte s’han intentat tenir en compte tots els components necessaris per el desenvolupament d’aquest. Al no tenir acc´es a informaci´o real s’ha fet una aproximaci´o basant-se en costos trobats per Internet que es poden apropar a la realitat. El cost estimat t´e en compte a un ´unic desenvolupador, per`o per agilitzar el proc´es seria millor poder contractar a m´es d’un ja que ´es el rol que m´es hores de treball t´e al projecte. Els investigadors del grup SANS, actualment tenen emmagatzemades les dades dels nodes 34 captor a una base de dades del departament de la que descarreguen les dades en arxius csv per tal d’aplicar els m`etodes programats, per`o no tenen una aplicaci´o que els hi permeti integrar-ho tot i que afegeixi m´es funcionalitats de manera senzilla. El grup d’investigaci´o ja t´e actualment serveis d’AWS per lo que invertint una quantitat molt redu¨ıda al mes poden tenir acc´es a una base de dades (DynamoDB) en la qual poden emmagatzemar el que actualment tenen en arxius csv i les dades de les estacions de refer`encia. Amb l’aplicaci´o, i gr`acies en part a poder utilitzar aquesta base de dades, es dona als investigadors una facilitat per poder manegar, consultar, i modificar les dades dels sensors emprats al projecte de manera m´es senzilla i gr`afica i sense necessitat d’invertir grans quantitats de diners per aconseguir-ho. Facilitar`a aix´ı la interacci´o amb les dades ja que ser`a m´es c`omode i pr`actic que fer-ho manualment. Comparant-lo amb l’aplicaci´o de qualitat de l’aire de la Generalitat, aquesta soluci´o permet utilitzar sensors de menys qualitat i dona la possibilitat en un futur d’emprar uns m`etodes dissenyats espec´ıficament per fer operacions (calibratge, creaci´o de grafs, reconstrucci´o de senyals, ...) amb les dades recollides pels sensors per lo que per un preu molt menys elevat obtenint un resultat similar incloent tamb´e les estacions oficials de la Generalitat. Tamb´e pot ajudar a que es desenvolupin noves funcionalitats a partir d’aquesta aplicaci´o per lo que aix`o repercutir`a positivament al grup d’investigaci´o fent que es puguin centrar en altres aspectes. 2.13.2 Dimensi´o ambiental No s’ha estimat l’impacte ambiental del projecte ja que no ´es molt elevat. Per dur a terme el projecte nom´es ´es necessari un ordinador amb els seus respectius perif`erics, que en aquest cas eren els de ´us personal. Els recursos emprats s´on d’´us personal per lo que no ha calgut adquirir cap material nou i es poden utilitzar despr´es de que el projecte estigui finalitzat. En quant a la millora mediambiental, aquesta aplicaci´o no millora respecte altres ja que totes tenen un impacte similar sent aquest molt baix. 2.13.3 Dimensi´o social La realitzaci´o d’aquest projecte a nivell personal m’aportar`a coneixement. Mai havia treballat amb les eines que es fan servir a aquest projecte per lo que estar´e aprenent tant un nou llenguatge com nous softwares. Tamb´e m’ajudar`a a tenir una millor organitzaci´o del temps ja que d’aquesta manera ´es com es podr`a arribar al estat final del projecte desitjat. A nivell laboral tamb´e em pot ajudar per la experi`encia que em pot aportar amb el llenguatge de programaci´o i les eines emprades. 35 La soluci´o proposada no pret´en millorar respecte a alguna similar ja existent, si no que es vol adaptar a unes caracter´ıstiques concretes. D’aquesta manera es millorar`a la qualitat de vida dels investigadors de SANS ja que en comptes d’aplicar els m`etodes manualment poden integrar-los a l’aplicaci´o i fer-los servir des d’aquesta, tamb´e podran tenir una visi´o de la ubicaci´o dels sensors aix´ı com altre informaci´o rellevant de manera m´es c`omode. Existeix una necessitat real del projecte ja que, encara que puguin existir solucions similars, no s´on solucions aplicables. Aix`o ´es degut a que, per exemple, tant l’aplicaci´o de la Generalitat com l’aplicaci´o de Lobelia estan dissenyades espec´ıficament pels seus sensors i no s´on d’´us comercial, per lo que no es poden fer servir en el projecte que duen a terme SANS. Aquesta soluci´o s’adapta a una necessitat espec´ıfica amb uns requeriments espec´ıfics per lo que ´es necessari per SANS el desenvolupament d’una aplicaci´o que s’adapti al seu sistema ja que ´es part del seu projecte. 36 2.14 Integraci´o de coneixements En aquest projecte s’apliquen coneixements que escauen dins de diverses especialitats dins la carrera d’enginyeria inform`atica, adquirits tant a la carrera com de manera aut`onoma. En la creaci´o de la base de dades s’han aplicat alguns conceptes, relacionats amb el disseny, de l’assignatura de base de dades (BD). En aquesta assignatura s’aprenen conceptes de bases de dades relacionals, per`o part del coneixement que s’ha adquirit d’aquesta assignatura s’ha adaptat per tal de poder aplicar-lo al projecte, on s’utilitza una base de dades no relacional. S’han dissenyat les taules de la base de dades com si de relacionals es tract´es, per`o s’ha adaptat a l’hora de la seva implementaci´o. Al haver treballat anteriorment amb bases de dades no relacionals, a l’assignatura de projectes de tecnologies de la informaci´o (PTI), es tenen coneixements previs d’aquestes, per lo que tenir una base sobre ambdues ha facilitat poder seleccionar quina seria l’adequada per aquest projecte. En l’especialitat de tecnologies de la informaci´o (TI), hi ha una optativa d’aplicacions distribu¨ıdes (AD), la qual ha donat una base relacionada amb la creaci´o d´APIs i tamb´e d’HTML. El haver desenvolupat una aplicaci´o web, encara sent amb tecnologies bastant diferents de les del projecte, ha facilitat la comprensi´o de components importants que es poden trobar en una, com son els fitxers html o el servidor web, i la seva interacci´o. L’assignatura de projectes de tecnologies de la informaci´o (PTI), tamb´e ha aportat coneixements sobre Openstreet maps iLeaflet, un software lliure i una llibreria emprats per mostrar els mapes a l’aplicaci´o, aix´ı com tamb´e el funcionament d’una aplicaci´o que utilitza SSR (Server Side Rendering), amb tecnologies bastant semblants a les d’aquest projecte. Per poder portar a terme aquest projecte tamb´e s’han utilitzat coneixements adquirits durant en el desenvolupament del projecte. Al no haver tingut cap base d’aquests coneixements s’ha hagut de buscar informaci´o i tutorials per adquirir el coneixement necessari per poder implementar el projecte. Aquests han sigut sobretot coneixements de llenguatges com python ijavascript, i de funcionament de eines com el framework de flask i la base de dades no relacional d’Amazon, DyanmoDB. Per acabar, en l’assignatura de m`arqueting a internet (MI) s’han apr`es conceptes relacionats amb la gesti´o d’un projecte; metodologia, planificaci´o, riscos, plans alternatius, i pressupostos. Aquests coneixements s’han pogut posar en pr`actica en les tasques de gesti´o de projectes, sobretot a l’apartat de GEP. 37 2.15 Lleis i regulacions Per tal de desenvolupar aquest projecte no ha calgut tenir en compte cap llei ni regulaci´o. El principal perill a tenir en compte en aquest tipus de projectes ´es el tractament i ´us de les dades, per`o al ser aquestes, en aquest cas, mesures de sensors, per lo que no s´on dades sensibles, i de car`acter p´ublic no s’aplica cap llei ni regulaci´o sobre aquestes. 38 3 Arquitectura i tecnologies Per poder dur a terme el projecte s’ha hagut de fer una investigaci´o per determinar quines serien les millors opcions de software sobre el qual es correria el sistema de monitoritzaci´o. Una de les primeres decisions que es van haver de prendre va ser l’elecci´o d’una base de dades. Per poder prendre una decisi´o entre una base de dades relacional i una no relacional cal mirar el tipus de dades que entren a l’aplicaci´o. Per una part est`a la informaci´o de les estacions de refer`encia. Tota la informaci´o d’aquest tipus segueix un format establert, per lo que no ens interessa tenir diferents atributs per a cada tupla. Per l’altre part tenim els informes de les estacions de refer`encia. La informaci´o que s’emmagatzema de cada informe varia segons l’estaci´o a la que fa refer`encia, ja que el nombre de columnes variar`a depenent del nombre de sensors que tingui l’estaci´o. Amb aquest an`alisi de la informaci´o ja s’ha pogut veure quina opci´o seria la que millor s’adaptaria a l’aplicaci´o. El factor clau que ho determina ´es la variabilitat de les dades de la taula dels informes de les estacions. La principal difer`encia que es pot trobar entre les bases de dades relacionals i no relacionals ´es que les bases de dades no relacionals, al contrari de les relacionals, permeten estructures de dades variables, per lo que si requerim de diferents atributs depenent de l’estaci´o a la que fa refer`encia la tupla nom´es es pot aconseguir mitjan¸cant les bases de dades no relacionals. S’ha escollit DynamoDB ja que, a part de ser una base de dades no relacional, ´es una base de dades que ja tenia contractada el grup d’investigaci´o, per lo que per augmentant lleugerament la quota mensual a Amazon Web Services han pogut afegir les taules d’aquest projecte juntament amb les seves. Un cop establerta l’estructura de les dades a emmagatzemar i la base de dades en la que ho faran, es va comen¸car a plantejar diverses opcions pel desenvolupament de l’aplicaci´o. Un dels requeriments d’aquest projecte va ser que es desenvolup´es en python. Aix`o ´es degut a que python ´es un llenguatge amb el que els investigadors de SANS estan familiaritzats, per lo que en cas de voler implementar noves funcionalitats o modificar alguna funcionalitat ja implementada no cal que aprenguin un nou llenguatge per tal de fer-ho. Per lo que un cop establert el llenguatge cal buscar el framework. Per a la part del servidor s’utiliza Flask. Al principi es van considerar dues opcions; Flask iDjango. 39 Django ´es un framework m´es feixuc ja que incorpora tots els m`oduls, caracter´ıstica que potser no ens interessa depenent el projecte. Tamb´e porta gesti´o de tokens, per lo que si volem tenir usuaris no ens cal implementar aquesta funcionalitat a m`a. Flask, per altre banda, es un framework senzill i lleuger, ja que no ve amb tots els m`oduls i les depend`encies s’han d’instal·lar independentment. Al contrari que passa en Django, la gesti´o de tokens ´es m´es complexa, ja que al no incorporar-la s’ha de fer manualment. Aquestes s´on les principals difer`encies entre ambd´os frameworks. Tenint aquestes caracter´ıstiques en compte ja es pot fer una decisi´o del framework. Com el sistema no necessitar`a un gran nombre de depend`encies prioritzarem la lleugeresa que ens proporciona Flask envers la comoditat de tenir tots els m`oduls que ens proporciona Django. Com no cal tenir una gesti´o d’usuaris, ja que ser`a sistema de monitoritzaci´o emprat pels investigadors de grup SANS, ja va b´e utilitzar Flask, que tamb´e ens proporcionar`a la possibilitat de tenir gesti´o de tokens en un futur. Cal tenir en compte que Flask no es un framework orientat principalment a producci´o ja que no t´e la capacitat de manegar moltes peticions a la vegada. Si en un futur es volguessin rebre peticions online de manera endre¸cada s’hauria d’aplicar un filtre i buscar opcions de manegar-lo eficientment. Tecnologia Nom Base de dades DynamoDB Llenguatge Python Framework Flask Servidor Flask Taula 11: Resum de les tecnologies emprades al projecte. En la taula anterior [taula 11] es pot veure un resum de les tecnologies emprades al projecte. Per a la base de dades es fa servir DynamoDB, i pel framework/servidor es fa servir Flask, que utilitza Python com a llenguatge. 40 A l’hora de pensar en la futura integraci´o dels m`etodes de la tesi es van tenir en compte quins m`etodes serien els que haurien de guardar valors a la base de dades. Els tres m`etodes esmentats (m`etode de calibratge, m`etode de creaci´o de grafs, i m`etode de reconstrucci´o de senyal) requerien d’aquesta funcionalitat per lo que pel format de les dades que es reben dels m`etodes s’ha decidit en quina emmagatzemar-los. El m`etode de calibratge retorna les dades calibrades d’un sensor, per lo que al tenir flexibilitat a la base de dades d’informes l’´unic que caldria es afegir aquest nou valor com a una columna nova, degut a que tamb´e es vol conservar el valor pres pel sensor originalment. D’aquesta maner a l’hora de voler fer una consulta per un sensor i un rang de dates es podria escollir com a sensor les dades calibrades del sensor, ´es a dir, si es te l’opci´o que faria refer`encia a les dades calibrades d’O3 MOX en el men´u desplegable del formulari contingut al modal de la p`agina d’inici com a O3 MOX CAL, permetria veure ´unicament les dades calibrades d’aquest sensor. El m`etode de creaci´o de grafs retorna una matriu de valors reals de mida MxM, com a la base de dades d’informes cada atribut (excepte el nom i el timestamp) forma tamb´e part del vector d’´ultima lectura no interessa que aquesta matriu es guardi a la base de dades d’informes. El valor retornat no fa refer`encia a una ´unica tupla, per lo que s’ha vist millor opci´o tenir aquests valors en una base de dades separada. Per ´ultim, el valor retornat pel m`etode de reconstrucci´o de senyal tamb´e es podria emmagatzemar a la base de dades d’informes pel mateix motiu que el m`etode de calibraci´o. 47 4.3 Framework: Flask Com s’ha explicat a l’apartat anterior [apartat 3], Flask ´es el framework i servidor que s’empra en aquesta aplicaci´o. Flask permet manegar les peticions HTTP que arriben a l’aplicaci´o utilitzant les rutes (o endpoints). Aquest mecanisme, a part de facilitar la navegaci´o, permet assignar a una URL una funci´o espec´ıfica que gestionar`a la l`ogica d’aquesta. Les funcions implementades estan escrites utilitzant Python com a llenguatge donat que ´es el llenguatge que ent´en Flask. En l’aplicaci´o existeix una ruta per a cada pantalla de l’aplicaci´o. URL M`etode d’acc´es Funcionalitat /home Ruta per defecte (/), barra de navegaci´o Actualitzar Data-inici,Data-fi, i Ultima-lectura per a cada tupla de la taula estacions /home/chart table/ <station name>/<sensor>/ <initial date>/<final date> Modal de la p`agina d’inici (a home.html) Consultar a la base de dades el valor del sensor (especificat per l’usuari en el formulari) per cada tupla d’una estaci´o que tingui informes entre un rang de dates (especificat per l’usuari en el formulari), prepara per a renderitzar chart table.html /new station Barra de navegaci´o, /new station/ submit station Prepara per a renderitzar new station.html /new station/submit station new station.html Prepara per a renderitzar submit station.html /upload Barra de navegaci´o, /upload Prepara per a renderitzar upload.html /upload/submit csv upload.html Prepara per a renderitzar submit csv.html /about Barra de navegaci´o Prepara per a renderitzar about.html Taula 14: Descripci´o de les rutes. Per a implementar les funcionalitats de les rutes explicades a la taula anterior [taula 14] es faran ´us de dues llibreries principalment: pandas [font [1]] i boto3 [font [3]]. pandas ´es una llibreria que permet el tractament de dades, per lo que pemet manipular les dades rebudes tant de les consultes fetes a la base de dades, com dels arxius csv rebuts de l’usuari. boto3 permet fer operacions a la base de dades (DynamoDB) des del framework emprat de Python. 48 4.3.1 /home En aquesta ruta s’actualitzen els valors dels atributs data-inici,data-fi, i ultima-lectura de la taula estacions. Figura 8: Codi de la petici´o dels timestamps m´ınims i m`axims de cada estaci´o. Al codi anterior [figura 8] es pot veure com es fan dues consultes a la base de dades d’informes amb l’operaci´o query per a obtenir el rang de dates, per a cada estaci´o, pel que hi ha informes. Per fer les operacions s’han especificat tres par`ametres; limit,ScanIndexForward,KeyConditionExpression.Limit indica el nombre de tuples que vol que retorni l’operaci´o. ScanIndexForward indica l’ordre d’ordenaci´o, ´es a dir, si l’ordenaci´o es ascendent o descendent, indicant els valors ‘TRUE’ ordenaci´o ascendent, i ‘FALSE’ ordenaci´o descendent. Per ´ultim tenim KeyConditionExpression on s’especifica els requeriments que ha de complir la tupla per a sortir a la cerca, en aquest cas per ambdues cerques, la condici´o ´es que el nom de l’estaci´o sigui igual a station name que indica el nom de l’estaci´o per a cada estaci´o a la taula estacions. La petici´o retornar`a un objecte JSON. Per a accedir a la tupla resultant cal accedir a l’objecte ‘Item’ dins l’objecte JSON retornat al fer la consulta. 49 Figura 9: Codi, per a estacions amb informes, de l’inicialitzaci´o de les variables initial date ifinal date amb els timestamps m´ınims i m`axims de l’estaci´o, query per aconseguir les ´ultimes lectures de cada sensor per als timestamps m´ınims i m`axims de l’estaci´o, inicialitzaci´o de la variable last readings, i bucle pel formatat de last readings. Un cop fetes aquestes dues consultes es mirar`a que tant la variable initial date com la variable final date no estiguin buides, ´es a dir, que l’estaci´o per la que s’est`a iterant tinguin informes. En cas de no estar-ho s’accedir`a al primer i ´unic element i s’agafar`a el valor que tingui el camp Timestamp. Seguidament es fa una consulta mitjan¸cant query a la base de dades d’informes, la qual retornar`a una ´unica tupla ja que Limit, que indica les tuples a retornar per la consulta, val ‘1’. Aquesta consulta ha de complir que el nom de la tupla sigui igual a l’indicat, que en aquest cas ´es l’estaci´o per la qual s’itera, i que el timestamp sigui igual al valor de final date, ´es a dir, s’agafar`a l’´ultima lectura de l’estaci´o. Al bucle s’agafen tots els valors dels atributs que no siguin ni el nom ni el timestamp, ´es a dir, tots els atributs referents als sensors de l’estaci´o, i es guarden els valors en un string en format JSON com mostra el codi anterior [figura 9]. Figura 10: Codi, per a estacions sense informes, de l’inicialitzaci´o de les variables initial date,final date ilast readings a ’nan’. En cas de que initial date ifinal date a la query inicial [figura 8] estiguin buides, ´es a dir, no hi hagin informes per a l’estaci´o per la qual s’est`a iterant, s’inicialitzen les variables initial date,final date, i data json a‘nan’ com es mostra a la imatge [figura 10]. 50 Figura 11: Codi de l’actualitzaci´o els timestamps m´ınims i m`axims, i l’´ultima lectura de cada sensor, de l’estaci´o per la qual s’itera. En el codi anterior [figura 11] s’actualitzen els valors de Data-inici,Data-fi, i Ultimalectura de cada sensor, de l’estaci´o per la qual s’itera, per les estacions amb i sense informes. Es procedeix a fer un update item dels l’atributs data-inici,data-fi, i ultimalectura, de la tupla seleccionada, que contindran strings amb els valors de la data inicial, la data final, i l’´ultima mesura de cada sensor. Per ´ultim es prepara per a renderitzar home.html i s’adjunten les variables items data, name index,latitude index, i longitude index. items data ´es la taula d’estacions pasada a llista. name index,latitude index, i longitude index son les posicions en les que es troben el nom, la latitud, i la longitud respectivament, dins de cada tupla de la taula estacions. 4.3.2 /home/chart table/<station name>/<sensor>/<initial date>/<final date> Figura 12: Codi de la petici´o de les tuples existents donat el nom d’un sensor i un rang de dates. Al entrar a la ruta ´es el tipus de petici´o. En cas de ser una petici´o ‘POST’ redirecciona a l’usuari a la p`agina d’inici, en cas de ser ‘GET’ s’agafen els par`ametres de la url, que 51 son el nom de l’estaci´o, el nom d’un dels seus sensors, la data inicial, i la data final. Amb aquests par`ametres es fa una petici´o a la base de dades d’informes de tipus query, com es pot veure a la imatge [figura 12], de les tuples que compleixin la condici´o de que el nom sigui igual a l’indicat, i que el timestamp estigui entre les dates especificades. station name,initial date, i final date son variables que guarden els valors dels par`ametres indicats a la url. La variable reports cont´e les tuples retornades per la query.labels idata son dos vectors que contenen els timestamps, en el cas de labels, i les lectures del sensor, en el cas de data, per a cada tupla retornada a la query. Per ´ultim la ruta prepara per a renderitzar la plantilla chart table.html adjuntant les variables station name,sensor,initial date,final date,labels, i data per tal de poder accedir-hi amb Jinja des de la plantilla. 4.3.3 /new station Aquesta ruta prepara per a renderitzar la plantilla new station.html i adjunta el formulari a mostrar en la plantilla. 4.3.4 /new station/submit station En aquesta ruta lo primer que es verifica ´es amb quin m`etode s’accedeix. Si el m`etode ´es un ‘GET’ es redirecciona a l’usuari a la ruta /new station, ja que si no s’estaria fent una petici´o ‘POST’ a la ruta amb par`ametres buits. Si el m`etode ´es un ‘POST’ es procedeix al tractament de les dades recollides al formulari. Primer es fa una petici´o a la base de dades per agafar els valors dels atributs de la taula estacions, i saber el seu nombre per tal de formatar les dades rebudes. Seguidament es crea un string i un bucle amb la funci´o de formatar les dades rebudes del formulari seguint l’estructura de la taula i els seus atributs en format JSON dins del string creat. Un cop emplenat el string es converteix a JSON mitjan¸cant la funci´o json.loads i es crida a la funci´o put item de boto3 que fa la inserci´o de la tupla passant-li el JSON. Per ´ultim la ruta prepara per a renderitzar la plantilla submit station.html adjuntant el formulari, amb els valors introdu¨ıt pr`eviament per l’usuari, rebut de new station.html per tal de poder accedir-hi als valors amb Jinja des de la plantilla submit station.html. 4.3.5 /upload Aquesta ruta prepara per a renderitzar la plantilla upload.html i adjunta el formulari a mostrar en la plantilla. 52 4.3.6 /upload/submit csv En aquesta ruta lo primer que es verifica ´es amb quin m`etode s’accedeix. Si el m`etode ´es un ‘GET’ es redirecciona a l’usuari a la ruta /upload, ja que si no s’estaria fent una petici´o ‘POST’ a la ruta amb par`ametres buits. Si el m`etode ´es un ‘POST’ es procedeix al tractament de les dades recollides al formulari. Primer es mira el tipus d’arxiu que es vol pujar mirant les dades rebudes del formulari, els tipus d’arxius poden ser: informaci´o d’estacions, informes de estacions de refer`encia, i informes d’estacions captor. En cas de que l’arxiu sigui informaci´o d’estacions es selecciona la taula estacions, i en el cas de que l’arxiu sigui un informe, tant d’estacions de refer`encia com d’estacions captor, es selecciona la taula informes i s’agrega una columna “Nom” amb el nom de l’estaci´o, estret pel nom de l’arxiu. Despr´es es fa un bucle per tal de formatar la informaci´o de les tuples en format JSON. A l’hora de formatar, en el cas dels informes, s’ha de tenir en compte el tipus d’estaci´o de la que es volen inserir les dades ja que tenen diferents formats pel Timestamp. Tipus d’estaci´o Format del Timestamp Captor: captor200xx YYYY-mm-dd HH:MM:SS Captor: captor17013, captor17016, captor17017 dd/mm/YYYY HH:MM Captor: resta dels captor170xx dd/mm/YYYY HH:MM:SS Refer`encia YYYY-mm-ddTHH:MM Taula 15: Diferents formats dels Timestamps segons l’estaci´o. A la taula anterior [taula 15] es poden veure els diferents formats que tenen les estacions. Per tal de tenir la taula d’informes amb tots els Timestamps amb el mateix format s’ha decidit canviar-los tots al format est`andard, “YYYY-mm-ddTHH:MM”, el mateix que el dels informes de les estacions de refer`encia. Un cop emplenat el string, on es guarda el formatat de les dades de la tupla, es converteix aJSON mitjan¸cant la funci´o json.loads i es crida a la funci´o put item de boto3 que fa la inserci´o de la tupla passant-li el JSON. Per ´ultim la ruta prepara per a renderitzar la plantilla submit csv.html. 4.3.7 /about Aquesta ruta prepara per a renderitzar la plantilla about.html. 53 5 Desenvolupament: Templates Les aplicacions web necessiten plantilles (o templates) per a generar din`amicament p`agines HTML. Les plantilles son arxius html amb contingut est`atic, i si escau, una s’aplica una sintaxi especial per a inserir dades din`amicament. Aquestes dades inserides din`amicament es carreguen quan el servidor prepara la plantilla per a renderitzar donada una petici´o HTTP. Template Funcionalitat home.html Mostrar un mapa amb estacions, veure l’´ultima lectura per a cada sensor de l’estaci´o en cas de ternir l’estaci´o lectures, i fer peticions a /chart table chart table.html Visualitzar les mesures d’un sensor d’una estaci´o entre un rang de dates en format de gr`afica i taula new station.html Crear una nova estaci´o mitjan¸cant un formulari submit station.html Mostrar a l’usuari que l’estaci´o s’ha creat correctament, mostrant tamb´e les dades de l’estaci´o creada, donant l’opci´o a l’usuari de tornar a la p`agina de crear nova estaci´o o de redireccionar-lo a la de pujar un arxiu upload.html Pujar un arxiu mitjan¸cant un formulari submit csv.html Mostrar a l’usuari que les dades s’han pujat a la base de dades correctament donant l’opci´o a l’usuari de tornar a la p`agina de pujar un arxiu about.html Informar breument sobre el projecte al que pertany l’aplicaci´o Taula 16: Funcionalitats de les templates. En la taula anterior [taula 16] es poden veure totes les plantilles html de l’aplicaci´o amb una breu descripci´o de les seves funcionalitats. 54 Figura 13: Model UX de les pantalles ’Inici’ i’GraficaTaula’. En la imatge anterior [figura 13] es mostra un model UX per a les pantalles Inici i GraficaTaula. La pantalla Inici fa refer`encia a home.html, i GraficaTaula fa referencia achart table.html. En el model tamb´e es pot veure la pantalla de ModalEstaci´o, que representa al modal dins de home.html. 55 Figura 14: Model UX de les pantalles ’CrearEstacio’,’NovaEstacioCreada’, ’PujarArxiu’ i’ArxiuPujat’. En la imatge anterior [figura 14] es mostra un model UX per a les pantalles CrearEstacio, NovaEstacioCreada,PujarArxiu, i ArxiuPujat. La pantalla CrearEstacio fa refer`encia a new station.html,NovaEstacioCreada asubmit station.html,PujarArxiu aupload.html, i ArxiuPujat asubmit csv.html. 56 Figura 23: Desplegable hora en la finestra modal d’una estaci´o amb informes associats. La finestra modal permet a l’usuari escollir un sensor mitjan¸cant un men´u desplegable que cont´e tots els sensors de l’estaci´o seleccionada [figura 21] i un rang de dates per tal de mostrar les lectures dels sensors. Per tal de seleccionar un rang de dates s’haur`a de seleccionar un camp, o la data inicial o la final, i pr´emer la icona de calendari la qual desplegar`a un calendari [figura 22], amb la data actual seleccionada per defecte. Aquest calendari ´es molt intu¨ıtiu [font [16]] per lo que l’usuari navegar`a per ell per tal de poder seleccionar la data desitjada de forma senzilla. Al pr´emer la icona de calendari i desplegar-se aquest, a sota es pot veure una icona d’un rellotge. La icona del rellotge, un cop premuda, permet a l’usuari canviar l’hora i seleccionar entre “a.m.” i “p.m.” [figura 23]. Les dates tamb´e es poden inserir en el camp de text seguint el format “dd/mm/yyyy hh:mm”, sent la hora “h” en cas de ser menor a “10”, seguit de “a.m.” o “p.m.”. Un cop seleccionades les dades, si l’usuari prem el bot´o de veure dades se li enviar`a a la p`agina de chart table que s’explicar`a a continuaci´o. Per`o abans d’enviar les dades es comprovaran que les dates siguin correctes. Es comprovar`a que els camps de dates no estiguin buits, per lo que en cas d’estar-ho s’establir`a el rang amb la data de la primera lectura de l’estaci´o i l’´ultima. Si les data inicial seleccionada per l’usuari ´es menor que la data de la primera lectura de l’estaci´o aquesta ser`a canviada per la data de la primera lectura de l’estaci´o. Es procedeix de la mateixa manera per a la data final per`o en el cas contrari, ´es a dir, en cas de que la data final seleccionada per l’usuari sigui major que la data de l’´ultima lectura de l’estaci´o. Tamb´e es comprova que les dates segueixin una l`ogica, ´es a dir, que la data inicial no sigui major que la final. 63 Figura 24: Codi de la creaci´o de la URL ahome.html per a fer la petici´o a /chart table. A la imatge anterior [figura 24] es mostra la part del codi de la p`agina inicial que permet a l’usuari redirigir-se a la ruta /chart table. Aquesta part del codi s’ha definit en el home.html a un script que s’executa cada cop que l’usuari prem el bot´o de ‘veure dades’ en el modal seleccionat. Es defineix una url nova cada cop que l’usuari prem el bot´o de ‘veure dades’ ja que al ser una url din`amica cal redefinir els par`ametres cada cop que es vulgui fer un GET a la ruta /chart table. Per definir la ruta s’ha definit una arrow function anomenada template que defineix la url donats els seg¨uents par`ametres; nom de l’estaci´o, sensor, data inicial, i data final. El nom de l’estaci´o ve donat en el modal obert per l’usuari, i tant el sensor, i la data inicial i final l’especifica l’usuari en el formulari que es troba un cop obert el modal. 64 5.2 chart table.html Un cop l’usuari premi el bot´o ‘veure dades’, ubicat al modal de la ruta explicada a l’apartat anterior [apartat 5.1], arribar`a a la ruta /chart table [apartat 4.3.2]. En aquesta p`agina es mostraran les lectures fetes per un sensor determinat donat un sensor i un per´ıode temporal. Figura 25: Gr`afica de les lectures d’un sensor entre dues dates. 65 Figura 26: Punt de la gr`afica de les lectures d’un sensor entre dues dates. L’opci´o que est`a activada per defecte ´es visualitzar la gr`afica [figura 25]. Aquesta gr`afica cont´e tots els valors presos pels sensor entre les dates especificades, i representa aquests valors amb punts, podent ser consultats posant el cursor a sobre d’aquests 26]. Per a poder crear la gr`afica s’ha utilitzat Chart.js [font [6]], una llibreria Javascript gratu¨ıta i de codi obert per visualitzar dades en forma de gr`afica. Aquesta llibreria dona diverses opcions del format de la gr`afica, els quals son: barres, l´ınies, `area, circular, bombolla, radar, polar, i dispersi´o. L’objectiu de la mostra de dades en forma de gr`afica ´es poder mostrar els canvis entre les mesures en un rang de temps determinat per lo que la millor opci´o en quant el format ´es la gr`afica de l´ınies. 66 Figura 27: Codi de la creaci´o de la gr`afica. A la imatge anterior [figura 27] es pot veure la creaci´o de la gr`afica. Primerament s’ha creat al html una l’etiqueta canvas amb un identificador associat, en aquest cas line chart. Des del script s’agafa l’element i es guarda a ‘ctx’. En ‘myChart’ es crea la gr`afica que anir`a a ‘ctx’, ´es a dir, a l’element ‘line chart’. Dins de ‘myChart’ s’especifiquen les dades i caracter´ıstiques que tindr`a la gr`afica. Ens interessen principalment tres opcions; type, labels, i data. A type s’indica el format de gr`afica escollit, en aquest cas de l´ınies, a labels s’especifiquen les etiquetes que tindran les nostres dades, ´es a dir les etiquetes per a cada dada a l’eix de les X, i a data s’especifiquen les dades de les quals es vol fer una gr`afica. {{ labels |safe }} i{{ data |safe }} accedeixen, amb Jinja2, a les variables labels idata, que son dos vectors passats mitjan¸cant render template des de la ruta /chart table, es pot veure la seva definici´o a la primera imatge d’aquest apartat [figura 12]. S’afegeix el filtre safe per a que es pugui interpretar correctament aquestes variables, declarades en python, al script, en javascript. 67 Figura 28: Taula de les lectures d’un sensor entre dues dates. Tamb´e es dona altre opci´o de visualitzaci´o de les dades, la vista en taula [figura 28]. Per tal d’activar-la es facilita un bot´o a la dreta de la informaci´o de les mesures (sensor seleccionat i rang de dates) que permet canviar la vista de gr`afica a taula i de taula a gr`afica. La informaci´o de la taula es visualitza en dues columnes. La primera indica la data de la mesura en format universal, i la segona dona el valor de la lectura per a la data en q¨uesti´o del sensor seleccionat. Figura 29: Codi de la creaci´o de la taula. A la imatge anterior [figura 29] es pot veure la creaci´o de la taula mitjan¸cant les dades de la gr`afica. Al html s’ha creat un element amb l’etiqueta table amb un tbody amb 68 identificador ‘table data’. Al script del html de chart table s’agafa l’element ‘table data’ i es guarda a la variable ‘table data’. Per a cada element dins del vector labels es crear`a una fila, tr otable row, amb dues columnes, td otable data content. Primer es declara la fila a la variable table data tr, i despr´es les dues columnes a les variables table data td dt itable data td sm. A continuaci´o es declara date time, una variable que cont´e el valor de labels en la posici´o i, i sensor measure, una variable que cont´e el valor de les mesures dels sensors, ubicades a data en la posici´o i. Per ´ultim es dona valor a les columnes mencionades anteriorment amb aquestes dues variables, i es fiquen dins de la fila creada inicialment. 69 5.3 new station.html La p`agina de crear estaci´o permet a l’usuari crear una nova estaci´o. A aquesta p`agina s’arriba mitjan¸cant un ‘GET’ a la ruta /new station [apartat 4.3.3]. Figura 30: Formulari per crear una nova estaci´o. Per tal de crear una nova estaci´o es facilita un formulari on cal indicar el seu nom, les seves coordenades, i els sensors que t´e associats. Si l’estaci´o t´e m´es d’un sensor es facilita un bot´o per tal d’afegir un nou camp de sensor on poder especificar el nom d’aquest com es pot veure a la imatge anterior [figura 30]. 70 Figura 31: Formulari per crear una nova estaci´o amb camps de sensors afegits. En cas de que l’usuari s’hagi equivocat i vulgui eliminar un sensor s’ha proporcionat un bot´o per eliminar el sensor que es desitgi [figura 31], per`o sempre deixant un sensor com a m´ınim. Un cop tots els camps estiguin emplenats, si l’usuari prem el bot´o de ‘guardar estaci´o’ s’enviaran les dades mitjan¸cant un m`etode ‘POST’ del formulari a la ruta /new station /submit station [apartat 4.3.4]. 71 5.4 submit station.html Figura 32: Missatge per informar a l’usuari de que l’estaci´o s’ha creat correctament. Quan l’estaci´o s’insereixi a la base de dades es redirecciona a l’usuari de new station.html a new station/submit station.html on mostrar`a a l’usuari un missatge indicant que l’estaci´o s’ha creat correctament i mostrant les dades de la nova estaci´o inserida, com es pot veure a la imatge anterior [figura 32]. Tamb´e dona l’opci´o de redireccionar a l’usuari a la ruta /new station mitjan¸cant el bot´o ‘Crear altre estaci´o’, o a la ruta /upload mitjan¸cant el bot´o ‘Pujar Arxiu’. 72 Refer`encies [1] “About pandas”. A: Pandas (). url:https://pandas.pydata.org/about/. [2] “AWS Pricing Calculator”. A: Amazon (). url:https://calculator.aws/#/ addService. [3] “AWS SDK para Python (Boto3)”. A: Amazon (). url:https://aws.amazon. com/es/sdk-for-python/. [4] “BenQ GW2780 27L.LED IPS FullHD Eye-Care”. A: PCcomponentes (). url: https://www.pccomponentes.com/benq-gw2780-27ledips-fullhd-eyecare. [5] “Creating a Web Application using Python Flask with Server Side Rendering”. A: Medium (febr. de 2020). url:https : / / medium . com / @simranjitkamboj / creatingawebapplicationusingpythonflaskwithserversiderendering-9ebea8204193. [6] “Chart.js”. A: Chart.js (). url:https://www.chartjs.org/. [7] “El recibo de la luz alcanza los 133 euros en enero, el segundo m´as caro de la historia pese al respiro del precio de la electricidad”. A: La Raz´on (febr. de 2022). url: https://www.larazon.es/economia/20220201/yeesbpzxpvdifkudcuelgty6ye. html. [8] SANS Research Group. “Statistical Analysis of Networks and Systems (SANS) Research Group”. A: UPC (). url:http://sans.ac.upc.edu. [9] Antonio Ossa-Guerra. “C´omo trabajar con git branches”. A: Github (oct. de 2017). url:https://gist.github.com/aaossa/7db152babead60ab097ba2c898d379a6. [10] “Overlapping Marker Spiderfier for Google Maps API v3”. A: Github (gen. de 2019). url:https://github.com/jawj/OverlappingMarkerSpiderfier. [11] “PcCom Silver Pro Intel Core i5-10400F/16GB/1TB + 500GB SSD/GTX1660 SUPER”. A: PCcomponentes (). url:https://www.pccomponentes.com/pccomsilver-pro-intel-core-i5-10400f-16gb-1tb-500gb-ssd-gtx1660-super. [12] “pervasive computing (ubiquitous computing)”. A: techtarget (oct. de 2019). url: https://www.techtarget.com/iotagenda/definition/pervasive-computingubiquitous-computing. [13] “Sueldos para desarrolladores Web”. A: Glassdor (mar¸c de 2022). url:https: //www.glassdoor.es/Sueldos/desarrollador-web-sueldo-SRCH_KO0,17.htm. [14] “Sueldos para Project Manager”. A: Glassdor (mar¸c de 2022). url:https://www. glassdoor.es/Salaries/project-manager-salary-SRCH_KO0,15.htm. 79 [15] “Sueldos para Tester”. A: Glassdor (mar¸c de 2022). url:https://www.glassdoor. es/Sueldos/tester-sueldo-SRCH_KO0,6.htm. [16] “Tempus Dominus”. A: getdatepicker (). url:https://getdatepicker.com/. 80