climàtica amb NECADA - upcommons.upc.edu
Transcript of climàtica amb NECADA - upcommons.upc.edu
Modelatge de l’emergència climàtica amb NECADA
Amin El Meziani Anglada
TREBALL FINAL DE GRAU
Director: Pau Fonseca i Casas (EIO)
Titulació: Grau en Enginyeria Informàtica
Especialitat: Tecnologies de la Informació
Data de defensa: 25/01/2021
Modelatge de l’emergència climàtica amb NECADA
i
Agraïments
M’agradaria donar les gràcies a totes les persones que han col·laborat directe o
indirectament en aquest projecte.
Al meu director Pau Fonseca i Casas, professor del Departament d’Estadística i
Investigació Operativa de la Universitat Politècnica de Catalunya i cofundador del
projecte NECADA, per proposar-me aquest treball permetent-me aprendre noves
tecnologies fins ara desconegudes per mi i ajudar-me a entendre millor certs àmbits de
la informàtica relacionats amb la simulació dels edificis. T’agraeixo tot el teu temps invertit
en les reunions telemàtiques en un any difícil per tots i la teva ajuda en moments
complexes del projecte.
A la meva tutora de Gestió de Projectes, l’Olga Pons Peregort, per guiar-me en tot
moment des de l’inici a plantejar correctament el treball i establir les pautes adequades
del projecte.
Al José Luis Pérez, desenvolupador web i assistent d’investigació a NECADA, per donar-
me consells en moments puntuals on m’he encallat durant la fase final del projecte.
Finalment, també agrair als meus pares, amics i companys de la facultat tot el seu suport,
ànims, força i constància que m’han donat durant tota la realització del projecte. Això
m’ha fet tirar endavant amb energia en moments complicats i els hi agraeixo de tot cor.
Modelatge de l’emergència climàtica amb NECADA
ii
Resum La situació d'emergència climàtica que estem vivint implica el desenvolupament d'un
seguit d'accions multi i transdisciplinars que intentaran mitigar els efectes negatius de la
modificació dels patrons climàtics. El projecte, desenvolupat en el marc del grup de treball
d'emergència climàtica de la Universitat Politècnica de Catalunya, busca mitigar aquests
efectes en l'àmbit de l'edificació.
El consum energètic en edificació representa més d'un 40% del total i, sabem que els
edificis actualment no estan preparats per situacions de manca d'energia o de
climatologia adversa. Si a això se li afegeix els canvis en l'ús dels edificis (teletreball,
canvis en la mobilitat amb vehicles que es carreguen a casa, etc.), cal començar a
repensar tota la part edificada per buscar mecanismes de millora.
El projecte que es desenvolupa cerca definir un model comú per poder detallar les
accions a emprendre. El model de simulació ha de permetre establir les bases de
comunicació per tal de poder implementar una solució informàtica que permet optimitzar
l'ús o la definició d'un edifici. El projecte no parteix de zero i es basa en la tasca feta a
través del projecte NECADA.
L’objectiu d’aquest TFG és la integració d’un model de sostenibilitat per l’edificació el
qual és NECADA amb un protocol de comunicació per a l’automatització industrial
anomenat OPC-UA.
Es crearà un client (sensor de CO2) i un servidor OPC-UA simulats els quals la seva
informació es guardarà en una base de dades no relacional (MongoDB). Aquesta
integració amb OPC-UA es farà mitjançant una aplicació web desenvolupada amb un
framework anomenat ASP.NET Core seguint el model MVC (Model-Vista-Controlador) i
que s’hi podrà accedir a través de NECADA.
Modelatge de l’emergència climàtica amb NECADA
iii
Resumen La situación de emergencia climática que estamos viviendo implica el desarrollo de una
serie de acciones multi y transdisciplinares que intentarán mitigar los efectos negativos
de la modificación de los patrones climáticos. El proyecto, desarrollado en el marco del
grupo de trabajo de emergencia climática de la Universidad Politécnica de Cataluña,
busca mitigar estos efectos en el ámbito de la edificación.
El consumo energético en edificación representa más de un 40% del total y, sabemos
que los edificios actualmente no están preparados por situaciones de carencia de energía
o de climatología adversa. Si a esto se le añade los cambios en el uso de los edificios
(teletrabajo, cambios en la movilidad con vehículos que se cargan en casa, etc.), hay que
empezar a repensar toda la parte edificada para buscar mecanismos de mejora.
El proyecto que se desarrolla busca definir un modelo común para poder detallar las
acciones a emprender. El modelo de simulación tiene que permitir establecer las bases
de comunicación para poder implementar una solución informática que permite optimizar
el uso o la definición de un edificio. El proyecto no parte de cero y se basa en la tarea
hecha a través del proyecto NECADA.
El objetivo de este TFG es la integración de un modelo de sostenibilidad por la edificación
el cual es NECADA con un protocolo de comunicación para la automatización industrial
llamado OPC-UA.
Se creará un cliente (sensor de CO2) y un servidor OPC-UA simulados los cuales su
información se guardará en una base de datos no relacional (MongoDB). Esta integración
con OPC-UA se hará mediante una aplicación web desarrollada con un framework
llamado ASP.NET Core siguiendo el modelo MVC (Modelo-Vista-Controlador) y que se
podrá acceder a través de NECADA.
Modelatge de l’emergència climàtica amb NECADA
iv
Abstract The climate emergency we are living through requires the development of a series of
multi and transdisciplinary actions that will try to mitigate the negative effects of the
modification of climatic patterns. The project, developed within the scope of the working
group on climate emergency of the Polytechnic University of Catalonia, attempts to
mitigate these effects in the field of building.
Energy consumption in buildings represents more than 40% of the total and we know that
buildings are currently not prepared for situations of lack of energy or adverse weather
conditions. If we add to this the changes in the use of buildings (teleworking, changes in
mobility with home-charged vehicles, etc.), we have to start reconsidering the entire built
environment in order to find mechanisms for improvement.
The project being developed seeks to define a common model in order to detail the
actions to be undertaken. The simulation model must make it possible to establish the
bases of communication in order to implement an IT solution that makes it possible to
optimise the use or definition of a building. The project does not start from zero and is
based on the task done through the NECADA project.
The objective of this Degree Final Project is the integration of a sustainability model for
the building which is NECADA with a communication protocol for industrial automation
called OPC-UA.
A simulated OPC-UA client (CO2 sensor) and server will be created and its information
will be stored in a non-relational database (MongoDB). This integration with OPC-UA will
be done through a web application developed with a framework called ASP.NET Core
following the MVC model (Model-View-Controller) and that will be accessible through
NECADA.
Modelatge de l’emergència climàtica amb NECADA
1
Índex
Agraïments ..................................................................................................................... i
Resum ........................................................................................................................... ii
Resumen ...................................................................................................................... iii
Abstract ........................................................................................................................ iv
Índex .............................................................................................................................. 1
Índex de figures ............................................................................................................. 4
Índex de taules ............................................................................................................. 6
Acrònims i sigles ............................................................................................................ 7
Glossari de termes ........................................................................................................ 8
1. Introducció i contextualització .................................................................................... 9
1.1. Context ............................................................................................................. 9
1.1.1. Introducció .............................................................................................. 9
1.1.2. Formulació del problema....................................................................... 10
1.1.3. Parts implicades .................................................................................... 11
2. Estat de l’art ............................................................................................................. 12
3. Abast del projecte .................................................................................................... 14
3.1. Objectius ........................................................................................................ 14
3.2. Possibles obstacles ........................................................................................ 15
4. Metodologia i rigor ................................................................................................... 16
4.1. Metodologia .................................................................................................... 16
4.2. Eines de seguiment ........................................................................................ 18
4.3. Validació dels objectius .................................................................................. 19
5. Planificació Temporal .............................................................................................. 20
5.1. Tasques i dependències del projecte ............................................................. 20
5.1.1. Tasques sobre la gestió del projecte .................................................... 20
5.1.2. Tasques del desenvolupament del projecte .......................................... 21
5.1.3. Recursos ............................................................................................... 22
5.1.4. Duració estimada de les tasques .......................................................... 23
5.2. Diagrama de Gantt ......................................................................................... 24
5.3. Gestió del risc: Pla d’acció i valoració d’alternatives ...................................... 24
6. Pressupost ............................................................................................................... 25
6.1. Identificació i estimació dels costos................................................................ 25
6.1.1. Costos de personal per activitat (costos directes) ................................. 25
Modelatge de l’emergència climàtica amb NECADA
2
6.1.2. Costos genèrics o indirectes ................................................................. 27
6.1.3. Costos de contingència ......................................................................... 27
6.1.4. Costos imprevistos ................................................................................ 28
6.1.5. Pressupost total .................................................................................... 28
6.2. Control de gestió ............................................................................................ 28
6.2.1. Desviacions ........................................................................................... 28
7. Sostenibilitat i compromís social .............................................................................. 31
7.1. Dimensió econòmica ...................................................................................... 31
7.2. Dimensió ambiental ........................................................................................ 32
7.3. Dimensió social .............................................................................................. 34
7.4. Matriu de sostenibilitat .................................................................................... 35
8. Tecnologies emprades ............................................................................................ 37
8.1. OPC-UA ......................................................................................................... 37
8.1.1. OPC-UA .NET SDK Client-Servidor ...................................................... 43
8.1.2. UaExpert ............................................................................................... 43
8.2. ASP.NET ........................................................................................................ 44
8.2.1. ASP.NET Core ...................................................................................... 44
8.2.2. ASP.NET MVC Framework ................................................................... 45
8.3. MongoDB ....................................................................................................... 47
8.3.1. MongoDB.Driver ................................................................................... 49
8.3.2. MongoDB Compass .............................................................................. 49
8.4. C# ................................................................................................................... 51
8.5. HTML ............................................................................................................. 51
8.6. Visual Studio .................................................................................................. 52
8.7. Azure DevOps ................................................................................................ 52
8.8. Justificació de les tecnologies ........................................................................ 53
9. Seguiment del projecte ............................................................................................ 53
9.1. Anàlisi del mercat .......................................................................................... 53
9.2. Anàlisi d’alternatives....................................................................................... 54
9.3. Integració de coneixements ........................................................................... 54
9.4. Identificació de lleis i regulacions ................................................................... 55
10. Codificació de l’aplicació web ................................................................................ 57
10.1. Especificació dels requisits .......................................................................... 57
10.2. Codificació de l’aplicació .............................................................................. 59
Modelatge de l’emergència climàtica amb NECADA
3
10.2.1. Creació d’un prototipus amb OPC-UA ................................................ 61
10.2.2. Creació d’un prototipus amb .NET Core ............................................. 69
10.2.3. Connexió amb NECADA ..................................................................... 83
10.3. Validació dels resultats ................................................................................. 87
11. Conclusions ........................................................................................................... 89
12. Valoració personal ................................................................................................. 90
13. Bibliografia ............................................................................................................. 91
Annex .......................................................................................................................... 94
Annex A : Codi de l’aplicació web ......................................................................... 94
Annex B : OPC (Object Linking and Embedding for Process Control) .................. 98
Annex C : ThingsBoard ...................................................................................... 101
Annex D : SignalR ............................................................................................... 103
Modelatge de l’emergència climàtica amb NECADA
4
Índex de figures
Figura 1. Logo de NECADA ........................................................................................... 9
Figura 2. Imatge de l’incendi a Austràlia el 2020 ......................................................... 12
Figura 3. Logo del certificat LEED per a edificis .......................................................... 13
Figura 4. Representació gràfica de la metodologia Scrum .......................................... 18
Figura 5. Diagrama de Gantt ....................................................................................... 24
Figura 6. Logo d’OPC-UA ............................................................................................ 37
Figura 7. Model de capes OPC-UA ............................................................................. 38
Figura 8. Espai de direccions en OPC-UA i relacions entre els Nodes ....................... 39
Figura 9. Model OPC-UA Client-Servidor .................................................................... 40
Figura 10. Flux de comunicació d'una aplicació OPC-UA ............................................ 41
Figura 11. Model OPC-UA Publisher-Subscriber ......................................................... 42
Figura 12. Arquitectura del sistema dels models de comunicació en OPC-UA ........... 42
Figura 13. Logo del OPC-UA .NET SDK ..................................................................... 43
Figura 14. Pantalla inicial d’UaExpert .......................................................................... 43
Figura 15. Logo del llenguatge ASP.NET Core ........................................................... 44
Figura 16. Arquitectura del framework ASP.NET Core ................................................ 45
Figura 17. Arquitectura de les diferents plataformes en la tecnologia .NET ................ 45
Figura 18. Esquema d’un model que segueix el patró MVC ........................................ 46
Figura 19. Logo de MongoDB ...................................................................................... 47
Figura 20. Estructura general de MongoDB ................................................................ 49
Figura 21. Pantalla inicial de MongoDB Compass ....................................................... 50
Figura 22. Logo del llenguatge C# ............................................................................... 51
Figura 23. Logo del llenguatge HTML ......................................................................... 51
Figura 24. Logo de Visual Studio ................................................................................. 52
Figura 25. Logo d’Azure DevOps ................................................................................ 52
Figura 26. Arquitectura general del sistema del projecte ............................................. 60
Figura 27. Arquitectura de la connexió Client-Servidor OPC-UA simulats .................. 61
Figura 28. Resposta del servidor davant l’enviament de mesures del sensor CO2 ..... 62
Figura 29. Finestres (Windows) principals d’UaExpert ................................................ 63
Figura 30. Captura on UaExpert actualitza els valors enviats al servidor OPC-UA ..... 64
Figura 31. Captura del ”Data Access View” d’UaExpert .............................................. 65
Figura 32. Arquitectura de la connexió Client-Servidor OPC-UA amb MongoDB ........ 65
Figura 33. Pantalla inicial de les bases de dades en MongoDB Compass .................. 66
Modelatge de l’emergència climàtica amb NECADA
5
Figura 34. Pantalla de la col·lecció “mesures” en MongoDB Compass ....................... 67
Figura 35. Captura dels valors guardats del Client-Servidor ....................................... 68
Figura 36. Arquitectura de la connexió de l’aplicació amb OPC-UA i MongoDB ......... 69
Figura 37. Exemple dels projectes creats dins del sistema de NECADA .................... 70
Figura 38. Captura de la connexió de l’API amb la base de dades de MongoDB ........ 72
Figura 39. Pantalla d’inici de l’aplicació web NECADA Sensors .................................. 73
Figura 40. Pantalla on es mostren tots els edificis per poder monitoritzar-los ............. 74
Figura 41. Pantalla on es mostren tots els sensors instal·lats en l’Edifici 1 ................. 75
Figura 42. Pantalla on es mostra la informació associada al sensor de CO2 .............. 76
Figura 43. Llistat de tots els fitxers de l’aplicació web NECADA Sensors ................... 77
Figura 44. Codi de la connexió a MongoDB en ASP.NET Core .................................. 79
Figura 45. Codi del controlador que obté totes les mesures en forma de llista ........... 80
Figura 46. Configuració dels serveis de MongoDB en ASP.NET Core ........................ 81
Figura 47. Petició AJAX per accedir a la llista de mesures des de l’aplicació web ...... 82
Figura 48. Pestanya addicional dins NECADA que es connecta a l’aplicació web ...... 83
Figura 49. Llista dels edificis construïts dins NECADA ................................................ 84
Figura 50. Llista de les sales disponibles de l’Edifici 1 dins NECADA ......................... 85
Figura 51. Llista dels sensors de la sala seleccionada de l’Edifici 1 dins NECADA ..... 85
Figura 52. Informació general del sensor de CO2 ........................................................ 86
Figura 53. Validació de les actualitzacions de les mesures en UaExpert .................... 87
Figura 54. Validació de les actualitzacions de les mesures en MongoDB Compass ... 88
Figura 55. Validació de les actualitzacions de les mesures en l’API ........................... 88
Figura 56. Validació de les actualitzacions de les mesures en ASP.NET Core ........... 88
Figura 57. Codi del fitxer appsettings.json ................................................................... 94
Figura 58. Codi del fitxer MongoDBSettings.cs ........................................................... 94
Figura 59. Codi del fitxer Mesura.cs ............................................................................ 95
Figura 60. Codi del fitxer MesuraService.cs ................................................................ 95
Figura 61. Codi del fitxer MesuraController.cs............................................................. 96
Figura 62. Codi del fitxer SensorCO2.cshtml............................................................... 97
Figura 63. Estat inicial sense OPC .............................................................................. 98
Figura 64. Estat inicial amb OPC ................................................................................. 99
Figura 65. Exemple d’una pantalla de ThingsBoard .................................................. 102
Figura 66. Exemple de la visualització de les dades amb ThingsBoard .................... 102
Figura 67. Exemple d’un xat funcional en temps real amb SignalR ........................... 104
Modelatge de l’emergència climàtica amb NECADA
6
Índex de taules
Taula 1. Tasques del projecte amb la seva duració estimada ..................................... 23
Taula 2. Costos de personal per cada tasca (activitat) amb el seu sou brut ............... 25
Taula 3. Costos dels recursos humans del projecte .................................................... 26
Taula 4. Costos dels recursos materials del projecte .................................................. 26
Taula 5. Costos genèrics o indirectes del projecte ...................................................... 27
Taula 6. Costos de contingència del projecte .............................................................. 27
Taula 7. Pressupost total del projecte ......................................................................... 28
Taula 8. Matriu de sostenibilitat del TFG ..................................................................... 35
Modelatge de l’emergència climàtica amb NECADA
7
Acrònims i sigles
AJAX : Asynchronous JavaScript And XML
API : Application Programming Interface
ASP.NET : Active Server Pages.NET
BREEAM : Building Research Establishment Environmental Assessment Methodology
CLR : Common Language Runtime
COVID-19 : COronaVIrus Disease 2019
GDPR : General Data Protection Regulation
HTML : HyperText Markup Language
HTTP : HyperText Transfer Protocol
IDE : Integrated Development Environment
ITU-T : International Telecommunication Union-Telecommunication Standardization Sector
LEED : Leadership in Energy & Environmental Design
LSSICE : Llei de Serveis de la Societat de la Informació i Comerç Electrònic
MQTT : Message Queque Telemetry Transport
MVC Framework : Framework Model-Vista-Controlador
NECADA : No Emissions Computer-Aided Design for Architecture
NoSQL : Non-Structured Query Language
OPC-UA : Open Platform Communications - Unified Architecture
PPM : Parts Per Milió
SCADA : Supervisory Control And Data Acquisition
SDL : Specification and Description Language
SDK : Software Development Kit
Modelatge de l’emergència climàtica amb NECADA
8
Glossari de termes
ASP.NET Core : Framework open-source (codi obert) dissenyat per a la creació
d'aplicacions web o serveis web.
Driver : Programa la finalitat del qual és relacionar el sistema operatiu amb el
dispositiu hardware del nostre equip.
Diagrama de Gantt : Eina de planificació de projectes que proporciona una vista
general de les tasques programades, les seves dates i tot el seu progrés.
Framework : Marc de treball que conté un conjunt d’estàndards i bones pràctiques
que poden servir de base per a l’organització i desenvolupament software.
Model-Vista-Controlador : Patró de disseny utilitzat per a la implementació
d'interfícies d'usuari que separa el model de dades, la interfície d’usuari i la lògica de
control.
MongoDB : Base de dades distribuïda no relacional (NoSQL) orientada a documents
que ofereix una gran escalabilitat i flexibilitat.
NECADA : Programa de simulació i optimització basat en la normativa internacional
de sostenibilitat en l’edificació.
.NET Core : Framework open-source per als sistemes operatius Windows, Linux i
Mac OS. És el successor de .NET Framework.
OPC-UA : Protocol de comunicació orientat als serveis d'intercanvi d’informació per
a la comunicació i automatització industrial.
Scrum : Metodologia àgil en la qual s’apliquen un conjunt de bones pràctiques per
treballar en equip i obtenir el millor resultat possible d’un projecte en el menor temps.
SDK : Conjunt d'eines de desenvolupament de software que permet a un
desenvolupador crear una aplicació informàtica per a un sistema concret.
SDL : Llenguatge d’especificació formal i visual orientat als objectes estandarditzat
per la ITU-T en l’estàndard Z.100.
Modelatge de l’emergència climàtica amb NECADA
9
1. Introducció i contextualització
1.1. Context
1.1.1. Introducció
Aquest projecte forma part d’un projecte de recerca viu de la UPC més gran anomenat
NECADA [1] [2]. Primerament, es definirà què és NECADA i les seves principals
característiques.
NECADA és un acrònim que significa “No Emissions Computer-Aided Design for
Architecture” i neix en el centre d’investigació inLab de la universitat UPC BarcelonaTech.
És un programa de simulació i optimització basat en la normativa internacional de
sostenibilitat en l’edificació. Consisteix en un sistema de co-simulació que defineix els
models basant-se en un llenguatge formal gràfic i que permet integrar diferents motors
de càlcul com motors energètics, motors lumínics o motors acústics.
Donada la complexitat dels sistemes de simulació que es vol analitzar, moltes vegades
es requerirà l’energia i la potència d’un cloud. Això es pot fer amb NECADA i també es
permet l’execució en sistemes distribuïts. NECADA també incorpora bases de dades
d’impactes de sostenibilitat, tant nacionals com internacionals.
En altres paraules, NECADA és una infraestructura híbrida que suporta l'execució d'un
model de simulació en un cloud o en un entorn d'escriptori. L'objectiu d'aquesta
infraestructura és trobar valors òptims per a diversos paràmetres de construcció i els
impactes associats que redueixen la demanda d'energia o el consum de l'edifici.
Un cop s’ha definit el sistema de NECADA, entra a escena aquest Treball Final de Grau
que utilitzarà les dades recollides per NECADA per a la seva realització. En els següents
apartats es definirà amb exactitud els objectius del projecte.
Figura 1. Logo de NECADA
Modelatge de l’emergència climàtica amb NECADA
1 Definició d’OPC-UA : https://opcfoundation.org/faq/what-is-opc-ua 10
1.1.2. Formulació del problema Estem en una societat la qual el món tecnològic va canviant contínuament i no para
d’actualitzar-se. El projecte NECADA vol intentar adaptar-se a les noves tecnologies i vol
explorar diferents vies per millorar el seu sistema.
Una de les tecnologies que no hi ha treballat i que vol tractar és .NET Core (successora
de .NET framework). El problema a resoldre és poder integrar 2 tecnologies com són
ASP.NET Core i OPC-UA1 (s’explicarà més endavant) amb NECADA de manera eficient
i productiva.
El problema en certa manera està resolt perquè precisament el protocol OPC-UA està
escrit amb el framework ASP.NET Core. El que faltaria és veure com es pot comunicar
amb una estructura basada en SDL com NECADA. La solució que cal dissenyar ha de
ser estable i efectiva.
El sistema de NECADA, com bé s’ha dit, està creat amb el llenguatge d’especificació
SDL [3]. L’objectiu d’aquest TFG és la integració d’un model de sostenibilitat per
l’edificació el qual és NECADA amb un protocol de comunicació per a l’automatització
industrial anomenat OPC-UA (Open Platform Communications - Unified Architecture).
Aquesta integració es farà mitjançant una aplicació web desenvolupada, com s’ha dit
anteriorment, amb ASP.NET Core i que estarà connectada a NECADA. L’aplicació web
permetrà rebre informació d’OPC-UA i enviar-la cap al model SDL esmentat abans.
La informació rebuda del client OPC-UA cap al servidor es guardarà en una base de
dades no relacional com és MongoDB. L’estructura de la web és la que executarà/cridarà
el model SDL. L’aplicació web serà una demostració i servirà per fer tota la representació.
Cal destacar que el model SDL de NECADA proporciona informació sobre com es
comporta un edifici.
El producte resultant, és a dir, l’aplicació web, va dirigida a NECADA. Aquesta es
beneficiarà dels seus resultats i podrà utilitzar-los en qualsevol moment sense cap
inconvenient.
Modelatge de l’emergència climàtica amb NECADA
11
1.1.3. Parts implicades
A continuació es defineixen les parts implicades en la realització d’aquest projecte.
1. Desenvolupador: Només hi ha un únic desenvolupador en el projecte que és
l’autor d’aquesta memòria. S’encarregarà d’investigar, implementar i documentar
tot el progrés del projecte fins a la seva finalització.
2. Director del projecte: És el Pau Fonseca. El seu rol serà el de supervisar i guiar
al desenvolupador el projecte perquè es compleixin les diferents tasques i
objectius.
3. NECADA: Es beneficiarà de la integració que es farà amb el protocol OPC-UA
anteriorment esmentat i, en un futur, poder utilitzar aquestes dades en qualsevol
àmbit que hi treballi.
Modelatge de l’emergència climàtica amb NECADA
2 https://www.muyinteresante.es/naturaleza/articulo/incendios-en-australia-por-que-causa 12
2. Estat de l’art El canvi climàtic és un factor molt important per la humanitat i sempre cal tenir-lo en
compte. En les últimes dècades, el concepte d’emergència climàtica ha anat agafant
força a mesura que passa el temps. Tant és així, que s’han produït multitud
d’inundacions, incendis, terratrèmols, augment considerable de les temperatures,
desglaç dels pols, etc.
Figura 2. Imatge de l’incendi a Austràlia al 20202
A causa de l’escalfament global, en els últims vint anys la quantitat de gel que s’ha anat
perdent en els pols ha estat d’unes dimensions enormes. Tant és així, que durant aquest
any 2020, el desglaç a Groenlàndia ha arribat a un punt de no retorn [4]. Això suposa un
factor molt negatiu pel planeta, ja que aquest desglaç contribueix a l’augment del nivell
del mar de manera considerable.
Per intentar minimitzar tots aquests riscs, la Universitat Politècnica de Catalunya va ser
la primera universitat espanyola a declarar l'emergència climàtica aprovada al Claustre
Universitari el maig del 2019 (el compromís de la UPC amb les energies renovables ja
es va materialitzar l'any 2017).
Aquest any 2020, la UPC ha engegat una iniciativa molt interessant anomenada “UPC
Diàlegs: Energia i Emergència Climàtica” en la qual diferents ponents de l’àmbit
universitari o relacionats amb el món del canvi climàtic debaten i posen en comú diverses
solucions per millorar la nostra societat des d’un punt de vista sostenible.
Modelatge de l’emergència climàtica amb NECADA
3 https://ovacen.com/modelo-de-certificacion-leed-modelos-sostenibles 13
Per altra banda, aquest 2020 també ha sigut un any atípic perquè ha estat marcat per la
pandèmia mundial de la COVID-19 que ha afectat a tots els àmbits de la societat, entre
ells l’àmbit educatiu. Com a conseqüència, també ha influït directament en el canvi
climàtic com, per exemple, reduint la contaminació atmosfèrica (reducció de cotxes a
causa del confinament de la població, etc.).
En relació amb el projecte del qual tracta aquest TFG, existeixen alguns models de
sostenibilitat per a edificis. Els dos més famosos que es mencionaran per la seva
important rellevància són el model amb certificació BREEAM (Building Research
Establishment Environmental Assessment Methodology) i el model amb certificació
LEED3 (Leadership in Energy & Environmental Design).
El model amb certificació BREEAM es crea l’any 1990 i és el primer certificat de
construcció sostenible creat a tot el món. Aquest model permet mesurar el grau
sostenibilitat ambiental dels edificis. Anys més tard, el Consell de la Construcció
Ecològica dels Estats Units (USGBC o United States Green Building Council) va crear el
model amb certificació LEED mencionat anteriorment.
El certificat LEED es fonamenta en implantar en diferents projectes aspectes per a
millorar l'eficiència energètica i el seu respecte mediambiental, així com l'ús d'energies
renovables. També es basa a millorar la qualitat de l'ambient interior, el desenvolupament
sostenible respectant la naturalesa d'espais lliures, l'eficiència en el consum d'aigua i, la
selecció de materials i recursos naturals.
En el cas del certificat LEED existeixen moltes similituds amb NECADA. Una d’elles és
que abasta des de la creació de l’edifici fins a la seva demolició, considerant el procés
de la seva execució així com qualsevol altra possible intervenció en el mateix de reforma
o de manteniment.
Figura 3. Logo del certificat LEED per a edificis
Modelatge de l’emergència climàtica amb NECADA
14
3. Abast del projecte L’abast d’aquest projecte se centra en la creació d’una aplicació web partint d’un projecte
més extens com és NECADA per tal d’explorar noves tecnologies com, per exemple,
.NET Core. A continuació es definiran tant els objectius principals com els subobjectius
del projecte.
3.1. Objectius Tal com s’ha esmentat en l’apartat “1.1.2. Formulació del problema”, els principals
objectius del projecte són els següents:
1. Crear una connexió entre un client i un servidor OPC-UA simulats per veure el seu
funcionament.
2. Comprovar que l’SDK (Equip de Desenvolupament de Software) escollit com és
Opc.UaFx.Advanced és el correcte dins de la implementació d’OPC-UA.
3. Guardar la informació d’OPC-UA dins una base de dades no relacional
(MongoDB).
4. Implementar una aplicació web basada en ASP.NET Core per integrar la part
d’OPC-UA amb MongoDB i que farà de comunicadora entre NECADA i el servidor
OPC-UA.
5. Testejar que funcioni correctament l’aplicació web.
6. Integrar NECADA (basat en SDL) amb l’aplicació web creada.
Dins dels objectius principals, hi ha uns subobjectius que també són essencials per a la
realització i la bona organització del projecte:
1. Investigar les diferents tecnologies com OPC-UA, ASP.NET Core, C# i MongoDB
per tenir una bona base.
2. Documentar tota la integració de l’aplicació web amb OPC-UA i MongoDB.
3. Organitzar correctament tots els apartats, tant de la documentació referent a la
Gestió de Projectes (GEP) com de la implementació de l’aplicació.
4. Tenir un control del temps en tot moment. És molt important tenir en compte la
planificació temporal de les tasques amb precisió perquè, d’aquesta manera, hi
haurà molts menys errors que en el cas que no es planifiqués correctament.
Modelatge de l’emergència climàtica amb NECADA
15
Per complir tots aquests objectius, caldrà una sèrie de requisits funcionals per a finalitzar
amb èxit el projecte:
- Requisit 1: L’aplicació web haurà de poder funcionar i executar-se correctament en
qualsevol navegador.
- Requisit 2: L’aplicació web es podrà fer servir lliurement sempre que NECADA ho
permeti.
3.2. Possibles obstacles
En tot projecte, és important saber els possibles problemes o obstacles que poden sorgir
al llarg del desenvolupament d’aquest. Els principals obstacles que poden afectar el
projecte són els següents:
Desconeixement amb les tecnologies emprades Aquest projecte explora tecnologies que l’autor d’aquest TFG mai hi ha treballat, com és
el protocol OPC-UA, el framework ASP.NET Core, la base de dades de MongoDB i el
llenguatge C#. Això pot provocar que el temps real de desenvolupament de l’aplicació es
pugui allargar més del previst.
Integració de les tecnologies Aquest apartat va directament lligat a l’anterior. Com que les tecnologies anteriorment
esmentades s’han d’integrar totes entre elles, sempre hi ha la incertesa de si el resultat
final serà el correcte a causa d’aquest desconeixement que hi ha.
Planificació temporal limitada En qualsevol projecte, cal tenir una bona planificació per no tenir dificultats a l’hora
d’avançar cap a l’objectiu final. En aquest cas, el projecte té un temps limitat de 4 mesos
i, per tant, és essencial tenir en compte el factor temporal. El fet de retardar una tasca
inicialment plantejada, pot afectar negativament el resultat final prèviament establert.
Connexió externa L’aplicació web desenvolupada en aquest projecte depèn en certa manera de NECADA.
Si per alguna raó falla la connexió amb el sistema o alguna situació semblant, és
important tenir-ho en compte.
Modelatge de l’emergència climàtica amb NECADA
16
4. Metodologia i rigor
En qualsevol projecte és essencial una bona metodologia de treball per tal d’obtenir els
millors resultats i aconseguir els objectius establerts inicialment. Per a la realització
d’aquest projecte, s’ha pensat a seguir la metodologia àgil.
Aquesta metodologia és molt utilitzada en moltes empreses, ja que es basa en mètodes
que permeten adaptar la forma de treball a les condicions del projecte, aconseguint una
major flexibilitat i eficiència. Alhora, aquests mètodes se centren principalment en un
desenvolupament iteratiu de les tasques a complir.
En cada iteració del cicle de vida d’una metodologia àgil, s’inclou un seguit de fases com
la planificació de les tasques que s’han de portar a terme (Backlog), l’anàlisi dels
requisits, el disseny, el desenvolupament de les tasques amb les seves millores i la
documentació.
Dins les metodologies àgils, existeixen diferents implementacions a escollir: Scrum,
Kanban, Agile Unified Process (AUP), Extreme Programming (XP), Design Sprint, etc.
En aquest cas, s’ha pensat que la més adequada és Scrum perquè és una de les
implementacions més utilitzades mundialment i fomenta un major feedback entre el
desenvolupador del projecte i el client (director del projecte).
Abans d’entrar en detall sobre les característiques més importants de la metodologia
Scrum, cal puntualitzar que aquesta metodologia està orientada principalment a grups
de més de 3 persones. Llavors, tot i que aquest projecte el realitza una sola persona,
s’ha cregut que es pot treure una bona part aplicable i es pot adaptar a les necessitats
requerides.
4.1. Metodologia
Scrum és una metodologia àgil per desenvolupar productes complexos en la que
s’apliquen de manera regular un conjunt de bones pràctiques per treballar en equip i
obtenir, en el menor temps, el millor resultat possible d’un projecte acceptant en tot
moment qualsevol necessitat o modificació que pugui sorgir.
Modelatge de l’emergència climàtica amb NECADA
17
Els beneficis més importants que ofereix Scrum són els següents:
- Flexibilitat i adaptació a les necessitats dels clients (també canvis al mercat).
- Capacitat d’oferir resultats anticipats abans que el projecte finalitzi.
- Increment de la productivitat i la qualitat.
- Potenciació de la creació d’equips motivats.
Dins de Scrum, existeixen 3 rols principals:
1. Product Owner : Representa el client i determina la visió del producte així com
les prioritats a l’hora d’exercir les tasques. En aquest cas, és el director del TFG,
el Pau Fonseca.
2. Scrum Master : És el facilitador de l’equip, potència la seva productivitat i
supervisa que tots utilitzin Scrum de manera correcta. En aquest cas, també és el
director del TFG, el Pau Fonseca.
3. Equip de desenvolupament : Té la responsabilitat de realitzar i d’entregar el
projecte. En aquest cas, és l’autor del TFG.
En Scrum, els projectes s’executen en blocs temporals curts anomenats sprints o
iteracions. Normalment, solen durar d’1 a 4 setmanes i el seu contingut és fix. Quan
comença un sprint es fa una reunió de planificació on el client presenta una llista de
requisits del projecte (Product Backlog).
El Product Owner ordenarà aquesta llista per prioritats (Sprint Planning Meeting). A
continuació, l’equip de desenvolupament seleccionarà els objectius amb major prioritat i
elaborarà una llista de tasques (Sprint Backlog) amb els requisits que es compromet
desenvolupar en l’sprint.
Seguidament, es farà una reunió diària de sincronització (Daily Scrum) on s’exposarà
què s’ha fet des de l’última reunió, què cal fer a partir d’ara i quins impedients hi ha (o hi
haurà). Durant l’sprint, l’Scrum Master s’encarregarà de supervisar-ho tot perquè es
pugui complir l’objectiu.
Modelatge de l’emergència climàtica amb NECADA
18
L’últim dia de l’sprint es farà una reunió de revisió on s’entregaran els requisits complets
al client i, aquest, farà les modificacions necessàries replanificant el projecte. Per últim,
també es farà una reunió de retrospectiva en la que s’analitzarà la manera de treballar i
quins són els problemes que es poden trobar en un futur millorant de forma contínua la
productivitat. La Figura 4 mostra gràficament tots els passos esmentats anteriorment.
Figura 4. Representació gràfica de la metodologia Scrum [5]
4.2. Eines de seguiment
Trello
És una eina de gestió de projectes que consisteix en diferents taulers on, dins de
cadascú, hi ha diverses llistes que tenen diferents tasques a realitzar. És una
manera molt còmoda d’organitzar un projecte.
En aquest cas, hi ha 1 taulell anomenat “Treball Final de Grau” el qual té 3 llistes:
“Tasques pendents”, “En procés” i “Tasques acabades”. Les tasques estan
ordenades en ordre cronològic. El director del projecte hi té accés en qualsevol
moment per seguir l’evolució.
TeamGantt
És una eina de planificació en línia que permet crear diagrames de Gantt d’una
forma senzilla i eficient. El gran avantatge és que sempre està sincronitzat amb
Trello. D’aquesta manera, és molt còmode afegir o treure tasques i que, aquestes,
es reflecteixin en el diagrama de Gantt automàticament.
Modelatge de l’emergència climàtica amb NECADA
19
Azure DevOps
És un repositori en línia creat per Microsoft on es guardarà el codi generat en el
treball. Proporciona un control de versions molt complet, gestió de requisits,
informes, gestió de projectes per a equips àgils de desenvolupament de software
i construccions automatitzades.
Gmail
S’utilitzarà per tenir una comunicació fluida amb el director del TFG per establir
les dates de les reunions, resoldre petits dubtes o comentar altres aspectes
relacionats amb el projecte.
Google Drive
És un repositori al núvol de Google on hi haurà tota la documentació relacionada
amb el TFG. La carpeta estarà compartida amb el director del TFG i podrà
visualitzar la seva evolució en qualsevol instant.
Skype
Es farà servir per resoldre dubtes més grans i debatre aspectes més extensos del
treball que no s’han pogut aclarir per Gmail amb el director del TFG.
4.3. Validació dels objectius
En aplicar una metodologia àgil com és Scrum, el mètode de validació dels diferents
objectius proposats es testejarà en finalitzar cada sprint per trobar possibles errors. Si el
director del TFG veu que ha sorgit algun problema, es focalitzarà en resoldre’l
immediatament. L’avantatge d’utilitzar aquesta metodologia és que es podran realitzar
els tests de forma paral·lela mentre es desenvoluparà l’aplicació web.
En la fase final del projecte s’han validat amb èxit tots els objectius establerts inicialment.
Aquesta validació s’explica amb més detall a l’apartat “10.3. Validació dels resultats”.
Modelatge de l’emergència climàtica amb NECADA
20
5. Planificació Temporal
El projecte té una duració aproximada de 4 mesos. Començarà el dia 21 de setembre de
2020 i acabarà aproximadament el 18 de gener del 2021. En aquest període es tindrà en
compte la realització del curs de GEP (Gestió de Projectes) el qual té un pes inicial
important per a la bona organització del projecte.
5.1. Tasques i dependències del projecte
En aquest apartat es descriuran totes les tasques (gestió i desenvolupament) que es
realitzaran durant el projecte i les seves respectives dependències entre elles.
5.1.1. Tasques sobre la gestió del projecte
Contextualització i abast
Es definirà el context en el qual es troba el projecte, la seva justificació, els principals
objectius, el seu abast, les parts implicades, els problemes a resoldre i la metodologia
que seguirà el projecte.
Planificació temporal
Es planificarà el desenvolupament de les tasques a realitzar, la seva evolució temporal,
les dependències entre elles i la seva estimació en hores. També es destaca els
possibles plans alternatius i obstacles.
Pressupost i sostenibilitat
S’identificaran i s’estimaran els costos que tindrà el projecte, directament o indirectament.
També s’avalua l’impacte econòmic, ambiental i social en l’apartat de sostenibilitat del
projecte.
Redacció del document final
Es redacta un document final on s’integren totes les tasques anteriors per tenir una bona
base de cara a documentar correctament la memòria final.
Reunions de control
Com s’ha aplicat una metodologia àgil (Scrum), cada cert temps es farà una reunió de
control per a resoldre dubtes i aclarir conceptes amb el director. Les dependències entre
aquestes tasques són de manera seqüencial tal com mostra el diagrama de Gantt de
l’apartat 5.2.
Modelatge de l’emergència climàtica amb NECADA
21
5.1.2. Tasques del desenvolupament del projecte
El projecte es dividirà en 3 tasques principals: especificació dels requisits, codificació de
l’aplicació web i validació dels resultats. Hi haurà una quarta tasca que serà la de la
documentació de les tres tasques anteriors i que es farà de forma paral·lela durant tot el
projecte.
1. Especificació dels requisits
S’especifica quins requisits tindrà el projecte i amb quines tecnologies es treballarà
(OPC-UA, ASP.NET Core, MongoDB, etc.). Es farà una anàlisi del context i determinar
quin disseny serà el més adequat per portar a terme el projecte.
2. Codificació de l’aplicació web
Aquesta segona tasca que serà la de la codificació de l’aplicació web i, per portar-la a
terme de manera més senzilla, es dividirà alhora en 3 subtasques diferents que
s’expliquen a continuació:
Creació d’un prototipus per a la integració amb OPC-UA
Inicialment es farà un primer prototipus independent de tot (inclou les tasques
d’especificació, codificació i validació) per veure com funciona el protocol OPC-UA i com
es guarda la informació en una base de dades no relacional com és MongoDB. També
es mostrarà les llibreries específiques per dur a terme el prototipus.
Creació d’un prototipus per a la integració amb .NET Core
L’objectiu d’aquesta subtasca és el mateix que en l’apartat anterior, però ara tenint com
a fita final la creació d’una aplicació web mitjançant el framework ASP.NET Core que a
dins seu s’hi integrarà el treball realitzat amb OPC-UA (i òbviament, MongoDB).
Connexió amb NECADA
Una vegada s’ha creat i validat tant la integració amb OPC-UA com l’aplicació web,
aquesta última es connectarà directament a NECADA.
Per tant, un cop creat cada prototipus independent, es farà una integració més àmplia de
totes les parts realitzades per acabar unificant-ho tot en un sol prototipus definitiu que és
el que servirà per fer tota la demostració.
Modelatge de l’emergència climàtica amb NECADA
22
3. Validació dels resultats
Es validarà els resultats obtinguts de totes les tasques esmentades anteriorment.
Aquesta validació segurament serà costosa, ja que la codificació pot suposar una
dedicació bastant gran de temps. Per això, s’ha de mirar els possibles obstacles que
podran sorgir dins d’aquesta tasca.
4. Documentació
Totes les tasques anteriors juntament amb les seves corresponents subtasques (si en
tenen) es desenvoluparan de forma paral·lela amb la documentació d’aquestes. A
mesura que la complexitat del tema es vagi incrementant, la documentació tindrà menys
dedicació i la part de codificació costarà més. Com a conseqüència, la part de la validació
encara costarà més temps.
5.1.3. Recursos A continuació se citaran els recursos humans, recursos materials i recursos software que
afecten el projecte:
Recursos humans:
En aquest cas, els recursos humans són 2: el desenvolupador d’aquest Treball Final de
Grau (Amin El Meziani) i el director del mateix (Pau Fonseca).
Recursos materials:
- RH1 = Torre d’ordinador PcCom Basic Elite Essential Intel Core i5-8400
- RH2 = Pantalla BenQ GW2470HL 23.8" LED Eye Care
Recursos software:
- RS1 = Trello : Eina de gestió de projectes per organitzar tasques
- RS2 = TeamGantt : Eina de planificació que permet crear diagrames de Gantt
- RS3 = Visual Studio : Software pel desenvolupament de l’aplicació web
- RS4 = OPC-UA .NET SDK : SDK de client-servidor OPC-UA per a tecnologies .NET
- RS5 = UaExpert : Client OPC-UA de prova gratuït
- RS6 = MongoDB : Base de dades no relacional
- RS7 = MongoDB Compass : Interfície gràfica oficial de MongoDB
- RS8 = Azure DevOps : Repositori en línia pel control de versions del codi
- RS9 = Skype : Software per a la comunicació amb el director
Modelatge de l’emergència climàtica amb NECADA
23
5.1.4. Duració estimada de les tasques
A continuació, havent explicat en el capítol anterior totes les tasques que es realitzaran,
es calcularà la duració estimada que tindrà cada una d’elles [6].
Taula 1. Tasques del projecte amb la seva duració estimada, les seves dependències temporals i recursos utilitzats en cada una d’elles. Font: Creació pròpia.
Modelatge de l’emergència climàtica amb NECADA
24
5.2. Diagrama de Gantt
El diagrama de Gantt [7] corresponent a les tasques descrites en el projecte i que estan
reflectides en l’anterior taula (Taula 1), és el següent:
Figura 5. Diagrama de Gantt
5.3. Gestió del risc: Pla d’acció i valoració d’alternatives Durant la realització del projecte, poden sorgir possibles obstacles que desviïn la
planificació prevista inicialment. Com que s’aplica una metodologia àgil, aquests
obstacles es podran solucionar en finalitzar cada sprint amb reunions de control.
Per una banda, hi ha els obstacles més generals que són el desconeixement de la
majoria de tecnologies utilitzades i la integració entre elles. Per altra banda, hi ha les
tasques que es creu que comportaran més temps a l’hora de desenvolupar-les.
Concretament, són la tasca T2.2: Codificació de l’aplicació web (amb les seves
corresponents subtasques) i la tasca T2.3: Validació dels resultats. Aquestes dues
tasques són les que, degut a la seva complexitat, requerirà més esforç dur-les a terme.
El projecte està preparat per acabar dins el temps establert en planificació inicial. En el
cas que, per motius majors, no es completessin els objectius marcats inicialment, es
valoraria un pla alternatiu que seria el de treballar directament dins del model SDL en
comptes d’utilitzar l’aplicació web (els recursos serien els mateixos i s’acabaria a temps).
Modelatge de l’emergència climàtica amb NECADA
25
6. Pressupost
6.1. Identificació i estimació dels costos
6.1.1. Costos de personal per activitat (costos directes) Havent definit les tasques en la planificació temporal, ara s’estimaran els costos per a
cada una de les tasques del projecte, qui s’encarregarà de cada una i el sou brut de cada
rol.
Taula 2. Costos de personal per cada tasca (activitat) amb el seu sou brut
Modelatge de l’emergència climàtica amb NECADA
4 El sou brut per cada rol s’ha acordat amb el director del TFG, ja que la xifra és molt semblant al sou en una empresa. 26
Pressupost de recursos humans En el projecte, hi haurà 3 rols diferents: cap de projecte, desenvolupador i tester. En
aquest cas, les tres funcions les farà una mateixa persona que serà l’autor d’aquest TFG.
Els sous bruts de cada rol s’han establert d’acord amb el director del projecte4. Al cost
final se li afegeix un cost addicional que és el de la seguretat social [8], és a dir, el sou
brut multiplicat per 1.3 (30%).
Taula 3. Costos dels recursos humans del projecte
Pressupost de recursos materials En el cas dels recursos materials, només es comptabilitza l’ordinador amb el qual es
realitzarà totes les hores dedicades al projecte. En el càlcul de l’amortització del material,
s’ha agafat el preu del material dividit per les hores totals en la vida útil d’aquest [9]:
(550 €) / (250 dies laborables per any * 8 anys de vida útil * 8 hores de jornada laboral)
= 0.034 €/h. Pel que fa a recursos software, no existeix cap cost perquè tots són open-
source (codi obert).
Taula 4. Costos dels recursos materials del projecte
Modelatge de l’emergència climàtica amb NECADA
27
6.1.2. Costos genèrics o indirectes Respecte als costos calculats globalment anomenats costos genèrics o indirectes, es
comptabilitzen els costos de l’Internet i l’electricitat. En el càlcul del cost de l’electricitat i
del consum elèctric de l’ordinador s’ha establert a partir de la factura de llum corresponent
a la casa des d’on es du a terme el projecte.
Taula 5. Costos genèrics o indirectes del projecte
6.1.3. Costos de contingència Els costos de contingència (marge de seguretat) s’han aplicat en un 15% sobre el
pressupost total del projecte [10].
Taula 6. Costos de contingència del projecte
Modelatge de l’emergència climàtica amb NECADA
28
6.1.4. Costos imprevistos En l’apartat “5.3. Gestió del risc” s’han definit els possibles imprevistos els quals són una
dedicació extra de certes tasques que pot comportar un endarreriment en la planificació
inicial (només afecta el desenvolupador). La probabilitat dels imprevistos són del 10%
(molt poca) i s’estimarien en unes 40 hores extres. Per tant, el cost estimat total dels
imprevistos seria: [10 * (30 (€/h) * 40 hores extres)] / 100 = 120 €.
6.1.5. Pressupost total El pressupost total del projecte sumant tots els costos anteriors seria el següent:
Taula 7. Pressupost total del projecte
6.2. Control de gestió
6.2.1. Desviacions
Per tenir una bona gestió del control del pressupost total del projecte i no sobrepassar el
límit estimat inicialment, hi haurà una sèrie d’indicadors que ajudaran a supervisar les
possibles desviacions durant l’execució d’aquest. Els indicadors s’obtindran de veure
quina desviació haurà sorgit en cada tipus de cost definit prèviament en els apartats
anteriors [10].
S’espera que el % màxim de desviació que sorgeixi en qualsevol cost no sigui superior
a 10. Cal destacar que, relacionat amb l’apartat de “5.3. Gestió del risc”, s’estima que les
tasques mencionades les quals podrien requerir més dedicació, hi sorgirien possibles
desviacions que caldria tenir en compte.
Modelatge de l’emergència climàtica amb NECADA
29
Els indicadors de control seran per calcular les desviacions de:
- Hores consumides per cada tasca
- Costos segons les hores consumides per cada tasca
- Costos en recursos humans per cada tasca
- Costos materials
- Costos indirectes
- Costos imprevistos
- Costos de personal
- Hores totals
- Costos totals
Desviació de les hores consumides per cada tasca Es calcula la desviació que hi haurà en les hores consumides totals per a cada tasca
realitzada en el projecte.
Desviació = (Hores estimades – Hores reals) * Cost estimat
Desviació dels costos segons les hores consumides per cada tasca Es calcula la desviació que hi haurà en els costos de les hores consumides totals per a
cada tasca realitzada en el projecte.
Desviació = (Hores estimades – Hores reals) * Cost real
Desviació dels costos en recursos humans per cada tasca Es calcula la desviació que hi haurà en els costos dels diferents recursos humans (rols)
per cada tasca realitzada en el projecte.
Desviació = (Cost estimat – Cost real) * Consum d’hores reals totals
Desviació dels costos materials totals Es calcula la desviació que hi haurà si, durant la realització del projecte, poden aparèixer
nous costos de materials inicialment no previstos.
Desviació = Cost estimat del material – Cost real del material
Modelatge de l’emergència climàtica amb NECADA
30
Desviació dels costos indirectes totals Es calcula la desviació total que hi haurà en els costos indirectes que afectin el projecte.
Desviació = Cost estimat indirecte – Cost real indirecte
Desviació dels costos imprevistos Es calcula la desviació total que hi haurà en els costos d’imprevistos del projecte.
Desviació = Cost estimat d’imprevistos – Cost real d’imprevistos
Desviació dels costos de personal Es calcula la desviació total que hi haurà en els costos de personal del projecte.
Desviació = Cost estimat de personal – Cost real de personal
Desviació de les hores totals Es calcula la desviació total que hi haurà en les hores dedicades en el projecte.
Desviació = Hores estimades totals – Hores reals totals
Desviació dels costos totals Es calcula la desviació que hi haurà en els costos totals del projecte.
Desviació = Cost estimat total – Cost real total
Modelatge de l’emergència climàtica amb NECADA
31
7. Sostenibilitat i compromís social El sector tecnològic conté molts aspectes que cal tenir en compte. Un d’ells és la
sostenibilitat. Quan es crea un projecte és important establir una sèrie de pautes i
requisits per tal que en finalitzar-lo, sigui el màxim aprofitable possible. Dins d’aquestes
pautes, cal destacar els impactes que pot tenir en la societat.
En la sostenibilitat existeixen 3 grans impactes o punts de vista que, si es compleixen
correctament, junts fan que qualsevol projecte sigui totalment sostenible. Aquests
impactes són l’econòmic, l’ambiental i el social, i hi ha molts aspectes a reflexionar sobre
tots ells que poden afectar des d’una persona fins al planeta Terra.
L'informe de sostenibilitat [11] és un requeriment habitual a les empreses informàtiques
i als seus projectes. Prestigioses organitzacions com Global Reporting Initiative (GRI)
mesuren l’impacte sobre la sostenibilitat dels productes i serveis de les empreses
informàtiques.
Per tant, és molt important saber l’impacte econòmic, social i ambiental que té aquest
projecte. D’aquesta manera, es pot tenir una visió molt positiva sobre si el projecte és
realment sostenible en tots els seus sentits.
Des del punt de vista del desenvolupador d’aquest TFG, en moltes ocasions no es para
a pensar si realment el projecte que s’està desenvolupant té un impacte positiu o negatiu
a la societat, si pot provocar efectes i costos ambientals nocius, si contribueix al bé comú
de tothom, etc. És essencial reflexionar sempre en tots aquests aspectes i valorar la
sostenibilitat és una responsabilitat molt important per a tothom.
7.1. Dimensió econòmica
En la dimensió econòmica d’aquest projecte, s’ha estimat prèviament el cost de la
realització del projecte, tant en recursos humans com materials. Es nota clarament que
on més impacte econòmic hi ha és en la utilització dels recursos humans.
Un cop s’ha acabat el projecte, com que la planificació inicial no ha variat en cap moment,
s’ha pogut comprovar que la quantificació final del cost total (apartat “6.1.5. Pressupost
total”) s’ha ajustat a l’estimació econòmica inicial.
Modelatge de l’emergència climàtica amb NECADA
32
És imprescindible que l’estimació que es fa inicialment en qualsevol projecte sigui la
correcta per tal de fer-ne un bon seguiment. Una mesura efectiva per reduir el cost del
projecte seria reduir el temps de dedicació d’aquest. Això s’aconsegueix, per exemple,
amb una dedicació menor en l’aprenentatge de les tecnologies que s’utilitzaran durant el
projecte.
Si s’hagués de quantificar aquest estalvi en el cost del projecte, suposaria un increment
de 2 o 3 punts en la valoració total calculada en la matriu de sostenibilitat (Taula 8 de
l’apartat 7.4.). Precisament, en aquesta matriu és on es quantifica l’impacte econòmic
que ha tingut el projecte (25 punts sobre 30 possibles).
Pel que fa a la vida útil del projecte, inicialment, l’objectiu principal és que les persones
que se’n beneficiïn pugui estalviar el màxim de diners possible i s’espera que millori
econòmicament en molts aspectes.
El cost total estimat que tindrà el projecte durant la seva vida útil s’ha plantejat en l’apartat
“6.1.5. Pressupost total” i es podria reduir si s’apliqués la mesura esmentada en el
paràgraf anterior (reducció del temps) per fer-lo més viable. També s’han tingut en
compte el cost de les possibles actualitzacions que pugui tenir el projecte durant la seva
vida útil.
Respecte als possibles escenaris que podrien perjudicar la viabilitat del projecte hi hauria
el fet que, a causa de la realització d’algunes tasques concretes que requereixen molta
dedicació per la seva complexitat, això afectaria directament al temps de dedicació i, com
a conseqüència, un increment en el cost del projecte.
7.2. Dimensió ambiental La dimensió ambiental d’aquest projecte té un pes específic molt gran. Com que parteix
d’un projecte més gran que és NECADA el qual s’enfoca en la reducció del consum
energètic dels edificis, l’estimació de l’impacte ambiental que tindrà el projecte serà molt
destacable.
Una mesura que s’ha pres per reduir l’impacte ambiental és que només s’utilitzi un
ordinador per dur a terme el projecte i, d’aquesta manera, es gasta menys electricitat que
en el cas que es fes servir més d’un dispositiu.
Modelatge de l’emergència climàtica amb NECADA
33
Si s’hagués de quantificar aquesta reducció en el projecte, igual que en l’impacte
econòmic, també suposaria un increment de 2 o 3 punts en la valoració total calculada
en la matriu de sostenibilitat.
Un cop s’ha acabat el projecte, en la matriu de sostenibilitat (Taula 8) es quantifica
l’impacte ambiental que ha tingut el projecte (26 punts sobre 30 possibles). Tota la
realització d’aquest TFG es farà de manera digital i no hi haurà cap cost en paper.
En el cas que s’hagués de tornar a fer de nou tot el projecte, possiblement s’haurien de
necessitar els mateixos recursos, ja que tots són importants. Si s’hagués d’excloure algun
recurs, aquest seria el Trello (el projecte es podria organitzar sense necessitat d’utilitzar-
lo) o bé el TeamGantt (l’organització de les tasques de manera gràfica es podria fer
directament dins la memòria final).
Pel que fa a la vida útil del projecte, el problema a resoldre és el d’intentar minimitzar el
màxim possible l’impacte ambiental, de manera que sigui positiu pel medi ambient. En
aquest cas, respecte a solucions ja existents, el projecte en millorarà les emissions
mediambientals perjudicials que provoquen els edificis i que poden afectar a la salut de
les persones (igual que el projecte NECADA que és d’on prové aquest).
Els recursos que s'usaran durant la vida útil del projecte són tots els mencionats en
l’apartat “5.1.3. Recursos”. De tota aquesta llista el que té més impacte ambiental és
l’ordinador amb el qual es desenvolupa el TFG perquè és l’únic que gasta electricitat. La
resta de recursos són tots software que no tenen cap cost.
Si el projecte s’allargués en el temps, es podria permetre reduir l’ús d’alguns recursos
com s’ha dit en paràgrafs anteriors. En general, l'ús d’aquest projecte millorarà la petjada
ecològica, ja que com NECADA es dedica a la sostenibilitat en l’edificació, això hi està
directament relacionat de manera positiva.
Respecte als possibles escenaris que podrien fer augmentar la petjada ecològica del
projecte hi hauria el fet que, com el TFG toca l’àmbit dels sensors climàtics (CO2,
temperatura...), en el cas que s’utilitzessin sensors reals, depenent de la zona geogràfica
on es treballés amb aquest projecte, els nivells de CO2 podrien ser més elevats del
normal i, com a conseqüència, fer augmentar la petjada ecològica.
Modelatge de l’emergència climàtica amb NECADA
5 https://sdlps.com/projects/documentation/3 34
7.3. Dimensió social En l‘àmbit personal, la realització d’aquest projecte m’ha aportat a descobrir noves
tecnologies, llenguatges de programació i llibreries que fins ara no coneixia ni hi havia
treballat mai.
Una vegada finalitzat el projecte, he reflexionat significativament tant personalment com
professionalment sobre les persones que hi han intervingut. En aquest cas, m’he adonat
que el treball i els projectes d’investigació que porta a terme el meu director, el Pau
Fonseca, són realment importants per la societat.
Concretament m’agradaria mencionar un d’aquests projectes: el SDL-PAND5. Aquest
projecte col·labora amb l’Institut Català d’Oncologia, amb l’Hospital Clínic de Barcelona i
amb el Centre de Cooperació pel Desenvolupament (CCD) de la Universitat Politècnica
de Catalunya.
SDL-PAND és un prototipus funcional que permet avaluar alternatives de contenció
pandèmica (aquest any amb més rellevància per la COVID-19) basat en una
conceptualització gràfica dels models, que representen les hipòtesis de modelatge.
Per tant, tot i tenir una visió important de què és la sostenibilitat per la societat, en fer
aquest projecte s’ha incrementat encara més la meva curiositat per investigar més a fons
aquest àmbit.
Pel que fa a la resta de la societat, l’objectiu que es pretén amb aquest projecte és que
tot el benefici es plasmi en milers d’edificis, i així, millorar la qualitat de vida de la gent
(necessitat real) creant un món més sostenible per a tothom.
NECADA serà qui es beneficiarà totalment de l'ús del projecte. Referent al projecte, no
hi ha cap col·lectiu que es pugui veure perjudicat, sinó al contrari, qualsevol persona se’n
pot beneficiar.
Aquest projecte ha solucionat en gran manera el problema plantejat inicialment, ja que
l’objectiu principal era explorar la tecnologia .NET Core i integrar-la amb el protocol de
comunicació OPC-UA. Tot això s’ha aconseguit com es veurà en l’apartat “10. Codificació
de l’aplicació web”.
Modelatge de l’emergència climàtica amb NECADA
35
Respecte als possibles escenaris que podrien fer que el projecte fos perjudicial per a
algun segment particular de la població o crear algun tipus de dependència que deixés
als usuaris en posició de debilitat, es contempla la possibilitat que, si en el sector de
l’edificació no es porta de forma correcta les bones pràctiques respecte a la utilització
dels diferents sensors, això pot afectar directament o indirectament a l’edifici (i,
òbviament a la població en general).
7.4. Matriu de sostenibilitat
Per calcular el grau de sostenibilitat d’aquest projecte s’utilitzarà la matriu de sostenibilitat
que conté, per a cadascuna de les dimensions anteriorment descrites, una valoració de
0 a 10 la part de PPP (Projecte Posat en Producció) i de 0 a 20 la part de la vida útil del
projecte.
Aquest rang s’ha creat a partir de la reflexió que s’ha explicat prèviament en els anteriors
apartats (7.1., 7.2. i 7.3.). La valoració total de cada dimensió es farà sobre 30 punts
possibles.
L’objectiu és que el projecte aconsegueixi una valoració de 90 punts, és a dir, ser el
màxim sostenible possible. Per tant, un cop s’ha calculat la valoració per a cada
dimensió, se sumen els 3 valors i s’observa si s’ha aconseguit la fita.
Taula 8. Matriu de sostenibilitat del TFG
Modelatge de l’emergència climàtica amb NECADA
36
En la taula adjunta es mostra de forma gràfica la quantificació de cada impacte.
Primerament s’observa que l’impacte ambiental té una valoració total de 26 punts sobre
30 possibles, el qual és molt positiu perquè és quasi la valoració màxima (aquest és
l’objectiu).
En l’impacte econòmic s’observa un total de 25 punts sobre 30 possibles i és igual que
en l’impacte ambiental, quasi la valoració màxima. Finalment, l’impacte social té una
puntuació total de 28 punts sobre 30 possibles, el qual és l’impacte que té la valoració
més alta de tots tres.
Cal destacar que en aquestes valoracions se les hi ha aplicat els possibles riscos que
poden sorgir en cadascun dels tres impactes. S’ha cregut que aquests riscos (explicats
en els anteriors apartats) no afectarien en consideració al desenvolupament del projecte
i, per això, se’ls hi dóna una puntuació ínfima.
Per tant, s’ha arribat a la conclusió que aquest projecte, mirant les valoracions totals de
cada impacte per separat i, seguidament sumant-les totes, el resultat total és de 79 punts
sobre 90 possibles. Això significa que el projecte és quasi totalment sostenible i és
l’objectiu que es planteja inicialment.
Modelatge de l’emergència climàtica amb NECADA
6 https://opcfoundation.org 37
8. Tecnologies emprades En aquest apartat s’explicaran les tecnologies utilitzades en l’elaboració d’aquest
projecte. És important que es detallin, ja que, d’aquesta manera, és més senzill pel lector
seguir el desenvolupament del treball i les eines que hi actuen.
8.1. OPC-UA Prové de les sigles “Open Platform Communications - Unified Architecture” (o també
Open Protocol Communications - Unified Architecture). És un estàndard obert [12]
d'intercanvi d’informació per a la comunicació i automatització industrial (comunicació de
màquina a màquina o d’ordinador a màquina) creat per la OPC Foundation6.
Les principals especificacions de la OPC Foundation són l’OPC-DA (OPC - Data Access)
que defineix una interfície entre un client i un servidor per a intercanviar dades de procés
actuals, l’OPC-AE (OPC - Alarms & Events) que descriu el comportament d’un servidor
OPC enfocat a alarmes i esdeveniments i, l’OPC-HDA (OPC - Historical Data Access)
que descriu l’accés a dades històriques arxivades.
Aquestes especificacions mencionades utilitzen la tecnologia de COM/DCOM
(Component Object Model/Distributed Component Object Model) de Microsoft per a la
comunicació entre els components de software en una xarxa distribuïda client-servidor.
OPC és una tecnologia dissenyada per a comunicar dades de manera segura i operativa
entre aplicacions tant en la indústria de l'automatització (per exemple, en sistemes
SCADA) com en altres sectors.
A partir d’aquí, la OPC Foundation va crear l’estàndard OPC-UA que, a diferència de les
especificacions esmentades, és un mecanisme més segur, obert i fiable per a transferir
informació entre clients i servidors.
Figura 6. Logo d’OPC-UA
OPC-UA és independent del fabricador o proveïdor del sistema de l'aplicació, del
llenguatge de programació en el qual s'ha programat el programari respectiu i del sistema
operatiu en el qual s'executa l'aplicació.
Modelatge de l’emergència climàtica amb NECADA
7 https://opcfoundation.org/about/opc-technologies/opc-ua 38
En altres paraules, OPC-UA és un protocol de comunicació orientat als serveis que
integra tota la funcionalitat de les especificacions individuals de l’OPC Classic (s’explica
a l’Annex B) en un framework flexible, proporcionant una ruta de migració a una solució
més segura i escalable.
Les característiques més importants d’OPC-UA són les següents:
- Escalabilitat, seguretat i interoperabilitat certificada
- Espai d’adreces flexible i un robust conjunt de serveis
- Transports i codificacions comunes
- Conté un model d'informació sofisticat
- Sofisticada gestió d'alarmes i esdeveniments
- Integració amb models de dades estàndard específiques de la indústria
Figura 7. Model de capes OPC-UA7
Nodes i Espai de Direccions
Un element molt important a l’hora de programar amb OPC-UA és el “Node”. El Node és
l'element més bàsic del protocol OPC-UA. Els Nodes estan relacionats directament entre
si i tenen una semblança als objectes (en el cas de la programació orientada a objectes).
Modelatge de l’emergència climàtica amb NECADA
8 https://docs.traeger.de/en/software/sdk/opc-ua/net/intro 39
Un Node té diferents atributs que poden ser llegits (OPC-DA o OPC-HDA). Els Nodes
s'utilitzen per a dades de procés així com per a tots els altres tipus de metadades que
existeixin. L'espai de direccions d’OPC conté un model de tipus amb el qual
s'especifiquen tots els tipus de dades.
Tots els Nodes proporcionats i processats en OPC-UA són administrats en l'anomenat
Espai de Direccions. Aquest espai representa una espècie d'emmagatzematge lògic i,
dins d’aquest, els Nodes continguts poden referir-se lògicament a un o més Nodes en el
mateix o un altre Espai de Direccions.
L'especificació d’OPC defineix que cada Node pot ser identificat de manera única en
l'Espai de Direccions a través d'un Identificador (NodeId). El NodeId es defineix, ja sigui
per un GUID (Global Unique Identifier), un array de bytes, una expressió numèrica o un
valor de string.
L'Espai de Direccions8 pot estar segmentat lògicament en una o més vistes (views). En
aquest sistema hi ha una vista per defecte, però les vistes personalitzades poden contenir
un o més Nodes.
Figura 8. Espai de Direccions en OPC-UA i relacions entre els Nodes, amb les vistes (vermell)
El “Node Manager” conté un o més Nodes i defineix les relacions entre cadascun d’ells.
Els Node Managers del sistema predefinits són:
- Core Node Manager : Defineix el tipus de cada Node i tots els Nodes del sistema.
- Diagnostics Node Manager : Proporciona diferents Nodes per als diagnòstics.
- Master Node Manager : És l'administrador de tots els Node Managers que hi ha i els hi
va donant permisos per a fer crides concretes dins el sistema.
Modelatge de l’emergència climàtica amb NECADA
9 https://integrationobjects.com/sioth-opc/sioth-opc-unified-architecture/opc-ua-client/ 40
OPC-UA defineix diferents serveis mitjançant els quals el client interactua amb el
servidor. Aquests serveis s'implementen com a mètodes des del costat del servidor i
s'utilitzen per a llegir i escriure atributs/valors, per navegar pels Nodes, per a la crida de
mètodes, per administrar referències de Nodes, i per administrar subscripcions.
Per a intercanviar les dades, OPC-UA té 2 mecanismes/models per a implementar en
diversos escenaris:
Model Client-Servidor
Els clients OPC-UA utilitzen els serveis dedicats del servidor OPC-UA. Aquest
enfocament peer-to-peer (entre parells) proporciona un intercanvi segur d'informació,
però amb limitacions referent al nombre total de connexions.
La comunicació client-servidor en OPC-UA s'utilitza àmpliament en l'automatització
industrial. Amb aquest mecanisme de comunicació cada client OPC-UA obté accés a les
dades del servidor OPC-UA a través d'una comunicació punt a punt. El client OPC-UA
envia una sol·licitud al servidor OPC-UA, de la qual rep una resposta.
Aquesta forma de comunicació permet un intercanvi de dades fiable i segur amb una
amplada de banda reduïda sense cap pèrdua de dades, fins i tot si l'entorn i la qualitat
de la xarxa no són òptims i es produeixen algunes pertorbacions. La comunicació entre
el client i el servidor es basa sempre en el protocol UA TCP (petit conjunt del protocol
definit a la capçalera de TCP) en el port 4840, i per l’accés al navegador web s’utilitza el
protocol HTTP.
Figura 9. Model OPC-UA Client-Servidor9
Modelatge de l’emergència climàtica amb NECADA
10 https://www.incibe-cert.es/blog/estandarizacion-y-seguridad-el-protocolo-opc-ua 41
Figura 10. Flux de comunicació entre el client i el servidor d'una aplicació OPC-UA10
Model Publisher-Subscriber (unidireccional, multicast i cíclic)
El servidor OPC-UA posa a la disposició de qualsevol subscriptor subconjunts
d'informació que són configurables. En el model OPC-UA PubSub (publicar/subscriure),
s'utilitza un mecanisme de comunicació d'un a molts o de molts a un. Un publisher (editor)
posa a la seva disposició dades que poden ser rebudes per qualsevol nombre de
subscriptors de la xarxa. En aquest model, la comunicació pot ser transmesa a través del
protocol UDP (User Datagram Protocol).
Depenent de la tecnologia utilitzada, això pot produir-se en cicles de temps molt curts.
Per tant, OPC-UA PubSub permet la comunicació en temps real a nivell de control i
satisfà les demandes de les aplicacions en les quals el temps és un factor bastant crític.
Modelatge de l’emergència climàtica amb NECADA
11 https://www.iottechexpo.com/europe/wp-content/uploads/2018/06/16.30-Christopher-Anhalt.pdf 42
Amb el model PubSub les aplicacions OPC-UA no intercanvien directament sol·licituds i
respostes. En el seu lloc, els publishers envien missatges a un software intermediari
anomenat MOM (Message-Oriented Middleware o Middleware Orientat a Missatges),
sense saber quins subscriptors pot haver-hi (si és que existeix algun).
De manera similar, els subscriptors expressen el seu interès en tipus específics de dades
i processen els missatges que contenen aquestes dades, sense saber quins editors hi
ha. La Figura 11 il·lustra que els publishers i els subscriptors només interactuen amb
aquest intermediari, que proporciona els mitjans per a enviar les dades a un o més
receptors.
Figura 11. Model OPC-UA Publisher-Subscriber Font: https://reference.opcfoundation.org/v104/Core/docs/Part14/B.3
L’arquitectura general del sistema dels models de comunicació11 en OPC-UA és la
següent:
Figura 12. Arquitectura del sistema dels models de comunicació en OPC-UA
Modelatge de l’emergència climàtica amb NECADA
43
8.1.1. OPC-UA .NET SDK Client-Servidor És un SDK (Equip de Desenvolupament de Software o Software Development Kit) molt
potent de client-servidor OPC-UA per a tecnologies .NET creat per l’empresa alemanya
Traeger que suporta OPC-UA, OPC-DA (Data Access o Accés de Dades), OPC-AE
(Alarmes i Esdeveniments), OPC-HDA (Historical Data Access o Accés a Dades
Històriques) i l’OPC Classic (explicat a l’Annex B).
Quan s’utilitza el SDK [13], ho fa amb el paquet Opc.UaFx.Advanced (llibreria per a
clients i servidors) o amb el paquet Opc.UaFx.Client (llibreria només per a clients).
Aquest SDK permet el desenvolupament ràpid i fàcil d’aplicacions client o servidor en la
majoria de tecnologies .NET (.NET Core, .NET Standard i .NET Framework). L’avantatge
que té és que funciona per a totes les plataformes suportades per Microsoft com són
Windows, Linux, Android, iOS i Mac OS.
Figura 13. Logo del OPC-UA .NET SDK
8.1.2. UaExpert És un client OPC-UA gratuït multiplataforma [14] escrit en C++ que proporciona interfícies
gràfiques d'usuari per a diferents objectius relacionats amb les característiques del
protocol OPC-UA. UaExpert és una aplicació que proporciona una funcionalitat bàsica
reutilitzable utilitzada per diferents plugins (complements) especialitzats.
Figura 14. Pantalla inicial d’UaExpert
Modelatge de l’emergència climàtica amb NECADA
44
8.2. ASP.NET És un framework de codi obert dissenyat per a la creació d'aplicacions i serveis web. Es
va crear l'any 2002 amb la versió 1.0 de .NET Framework com la tecnologia successora
de l’Active Server Pages de Microsoft (ASP) existent des de l’any 1996. ASP.NET utilitza
l’entorn d’execució CLR (Common Language Runtime) on es pot programar amb el codi
d’aquest mateix framework en qualsevol llenguatge .NET acceptat (C#, Visual Basic...).
En aquest projecte, ASP.NET és utilitzat per crear una aplicació web que integra el
protocol OPC-UA i la base de dades de MongoDB (s’explica en l’apartat 8.3.) i, alhora,
es connecta amb NECADA. El llenguatge utilitzat en aquest cas és C#.
8.2.1. ASP.NET Core
És un framework web [15] gratis multiplataforma de codi obert que té un rendiment més
alt que ASP.NET i serveix per desenvolupar tant APIs (Application Programming
Interface) com aplicacions web i mòbils. Aquest framework ofereix característiques per
al desenvolupament senzill del patró MVC (Model-Vista-Controlador) que es veurà a
continuació. A més, s’integra completament amb llibreries com Bootstrap.
Figura 15. Logo del llenguatge ASP.NET Core
Respecte a l’arquitectura general [16] d’ASP.NET Core, cal saber les seves parts
principals. La Figura 16 mostra aquestes parts ben diferenciades com són l’Aplicació
Web (models, vistes, controladors...), la seva infraestructura (memòria caché, serveis...),
altres components principals (interfícies, especificacions, excepcions...), fonts
d’informació (SQL) i serveis de tercers (APIs).
Pel que fa a les llibreries que utilitza la tecnologia .NET i que evidentment .NET Core
també hi està integrada, la Figura 17 mostra de manera clara les diferents plataformes
.NET que existeixen (.NET Framework, .NET Core i Xamarin) per separat, però que amb
un quart model anomenat .NET Standard, vol unificar la resta de plataformes en una de
sola [17].
Modelatge de l’emergència climàtica amb NECADA
45
Figura 16. Arquitectura del framework ASP.NET Core i les tecnologies que la integren
Figura 17. Arquitectura de les diferents plataformes en la tecnologia .NET
8.2.2. ASP.NET MVC Framework
És un framework [18] que es basa en el patró Model-Vista-Controlador (MVC) i ofereix
eines que ajuden a un desenvolupament escalable i estructurat. Està basat en ASP.NET
i separa les aplicacions web en els 3 elements del patró: Model, Vista i Controlador.
Modelatge de l’emergència climàtica amb NECADA
46
El patró MVC ajuda a crear aplicacions que separen els diferents aspectes de l'aplicació
(lògica d'entrada, lògica comercial i lògica de la interfície d'usuari). Aquest patró
especifica la ubicació de cada tipus de lògica en l'aplicació. Per altra banda, la lògica de
la interfície d'usuari pertany a la vista i la lògica d'entrada pertany al controlador.
Les vistes i els controladors depenen directament del model, però el model no depèn ni
de la vista ni del controlador. Això permet que el model es pugui construir i testejar
independentment de la presentació visual de l'aplicació. A més, es poden mostrar
simultàniament diverses vistes de les mateixes dades. El més important en el patró MVC
és que la lògica de l’aplicació ha d’estar completament separada de la interfície.
Figura 18. Esquema d’un model que segueix el patró MVC
En una aplicació MVC, la vista mostra la informació i, el controlador controla i respon tant
la interacció com les dades que introdueix l’usuari. A més a més, el controlador és el punt
d'entrada inicial que s'encarrega de seleccionar amb quins tipus de model es vol treballar
i quines vistes es vol representar (controla la forma en què l'aplicació respon a una
determinada sol·licitud).
Les definicions de cada rol del patró MVC són les següents:
1 - MODEL : És el que encapsula el comportament i les dades corresponents al domini
de l'aplicació. Habitualment es construeix un model de classes del problema amb el qual
s'estigui treballant, independentment de com es vagin a presentar les dades de cara a
l'usuari.
El model també representa l'estat d’un aspecte en particular de l'aplicació i serà
independent per complet de la pàgina ASP.NET Core. En el disseny MVC, el model
representa l'estat de l'aplicació i qualsevol lògica d’operacions que aquesta hagi de
realitzar.
Modelatge de l’emergència climàtica amb NECADA
47
2 - VISTA : Correspon al fitxer HTML que es mostra en el navegador de l'usuari i
s'encarrega de presentar el contingut a través de la interfície d'aquest. En altres paraules,
les vistes són les que consulten l'estat del model per a mostrar-l'hi a l'usuari.
3 - CONTROLADOR : S’encarrega en el servidor de gestionar les sol·licituds HTTP que
van entrant i de permetre que l'usuari realitzi certes accions. Aquestes accions es
traduiran en les respostes que resultin adequades, les quals poden involucrar
simplement a les vistes o incloure la realització d'algunes operacions sobre el model.
El controlador contindrà únicament el codi necessari perquè l'usuari pugui tractar la
pàgina d’ASP.NET Core. Per tant, és el que s’encarrega de les actualitzacions i
interaccions del model per mostrar els canvis d’estat en l'aplicació web. Seguidament,
passa la informació a les vistes per mostrar-la a la interfície d’usuari.
Hi ha 2 tipus de controladors: els de pàgina que són específics per a cada una de les
pàgines de l’aplicació web i els d’aplicació que s’encarreguen de totes les pàgines de
l’aplicació. En resum, els controladors són els elements que controlen la interacció de
l'usuari i treballen amb el model. Finalment, seleccionen una vista per a representar-la.
8.3. MongoDB És una base de dades no relacional distribuïda (NoSQL) orientada a documents que
ofereix una gran flexibilitat i escalabilitat [19]. Té un model de consultes i d’indexació en
temps real molt potent per poder accedir a les dades i analitzar-les.
A diferència de les bases de dades relacionals com MySQL o SQL Server que
emmagatzemen els valors en registres i taules, MongoDB emmagatzema les seves
dades en documents dinàmics similars a JSON (JavaScript Object Notation) anomenats
“BSON Documents” (Binary JSON Documents), per la qual cosa els camps poden variar
entre els documents i l'estructura de dades pot canviar amb el temps.
Figura 19. Logo de MongoDB
Modelatge de l’emergència climàtica amb NECADA
48
BSON és la representació binària de JSON i la seva estructura codifica la informació de
tipus i longitud, la qual cosa permet analitzar-la molt més ràpidament. Els llenguatges
que suporten qualsevol mena de matemàtiques complexes generalment tenen enters de
diferent grandària (ints vs longs) o diferents nivells de precisió decimal (float, double,
etc.).
No només és útil poder representar aquestes diferències en les dades emmagatzemades
en MongoDB, sinó que també permet que els càlculs es realitzin directament sobre les
dades de manera que se simplifiqui el consum del codi de tota l’aplicació.
Estructura de MongoDB L’estructura de MongoDB [20] és jeràrquica i consta dels següents nivells:
- Base de dades (database): Serveix com a contenidor per a les diferents col·leccions
existents. Normalment s'emmagatzemen col·leccions relacionades amb la mateixa
aplicació. Cada base de dades pot contenir diverses col·leccions.
- Col·leccions (collections): Emmagatzemen registres individuals anomenats documents
i permeten agrupar elements que siguin iguals. La nomenclatura típica per a referir-se a
una col·lecció inclou el nom de la base de dades, seguida d'un punt i de la col·lecció
referida (és el namespace o espai de noms).
- Documents (documents): És la forma en què les dades són encapsulades i codificades.
MongoDB usa el format BSON (Binary JSON) per a emmagatzemar la informació, encara
que després la mostra com a JSON. En una base de dades relacional, un document és
una fila.
Cada document conté el nom de la dada i el seu contingut. Un mateix document pot
representar un conjunt sencer de dades de diferent origen. MongoDB també permet que
l'estructura dels documents en una mateixa col·lecció no sigui la mateixa.
D’aquesta manera, certs documents poden tenir més camps que alguns altres. No
obstant això, els documents tenen una limitació màxima de 16 MB. MongoDB permet
crear normes d'accés per a les bases de dades i les col·leccions, però no per a
documents.
Modelatge de l’emergència climàtica amb NECADA
49
Si una base de dades o col·lecció no existeixen, es creen implícitament. MongoDB
permetrà utilitzar-les, encara que no les crearà fins que s'escriguin/insereixin dades en
elles.
- Índexs (indexes): És una estructura de dades que emmagatzema una petita fragment
del conjunt de dades total de les col·leccions. Aquesta estructura es pot recórrer de forma
molt lleugera i ajuda a agilitzar les consultes a la base de dades. Per defecte, MongoDB
indexa el “_id” de cada document.
Figura 20. Estructura general de MongoDB
8.3.1. MongoDB.Driver
És el driver oficial de MongoDB per a C# i .NET. És imprescindible perquè l’aplicació es
comuniqui adequadament amb MongoDB. Per a un determinat llenguatge de
programació, aquest driver permet interactuar amb MongoDB amb una sintaxi similar a
la del llenguatge de programació triat.
8.3.2. MongoDB Compass
És una interfície gràfica [21] que permet la connexió amb els servidors de MongoDB. El
que fa és analitzar els documents i, a través de la seva interfície gràfica, mostra
estructures detallades de les seves col·leccions. D'aquesta manera, es pot visualitzar i
explorar l'esquema per a comprendre la freqüència, tipus i rang de camps del conjunt de
dades.
Modelatge de l’emergència climàtica amb NECADA
50
Gràcies a les estadístiques del servidor en temps real, es pot veure les operacions de la
base de dades i les mètriques clau del servidor. La interfície interactiva permet construir
consultes sofisticades i mostra els resultats gràficament (si cal).
En MongoDB Compass també es pot inserir nous documents i eliminar els existents. En
aquest projecte s’ha utilitzat aquesta interfície perquè és molt senzilla d’utilitzar i molt
potent per a fer les proves de connexió amb OPC-UA.
Figura 21. Pantalla inicial de MongoDB Compass
Modelatge de l’emergència climàtica amb NECADA
51
8.4. C# És un llenguatge de programació orientat a objectes desenvolupat per Microsoft per a
crear programes per a la seva plataforma .NET. Es tracta d'un llenguatge modern,
evolucionat a partir de C i C++, i amb una sintaxi molt similar a la de Java.
Els programes creats amb C# no solen ser tan ràpids com els creats amb C, però a canvi
la productivitat del programador és molt major. En aquest projecte, la part de crear un
client i un servidor OPC-UA simulats s’ha realitzat amb C# i parts del codi de l’aplicació
web que s’utilitzarà per a la integració amb OPC-UA estan creades també amb el
llenguatge C#.
Figura 22. Logo del llenguatge C#
8.5. HTML És el llenguatge amb el qual es defineix el contingut de les pàgines web [22]. Les sigles
corresponen a “HyperText Markup Language” o “Llenguatge de Marques per Hipertext”.
Bàsicament es tracta d'un conjunt d'etiquetes que serveixen per a definir un text i altres
elements que componen una pàgina web (imatges, llistes, vídeos...).
HTML5 és l'última versió d’HTML. És un estàndard que serveix per a definir l’estructura i
el contingut d’una pàgina web. En aquest projecte s’utilitza HTML per a la creació de
l’aplicació web que es connectarà amb OPC-UA i amb NECADA.
Figura 23. Logo del llenguatge HTML
Modelatge de l’emergència climàtica amb NECADA
52
8.6. Visual Studio
És un entorn integrat de desenvolupament (IDE o Integrated Development Environment)
de Microsoft que permet crear aplicacions i serveis web per Windows o Mac OS. És l’eina
principal on s’ha realitzat tot el projecte i també permet integrar diferents tecnologies com
llibreries externes o gestors de paquets (NuGet). La versió que s’ha utilitzat és la de l’any
2019.
Figura 24. Logo de Visual Studio
8.7. Azure DevOps
És un repositori creat per Microsoft [23] que proporciona un control de versions molt
complet ja sigui amb el Team Foundation Version Control (TFVC) o amb Git. També
proporciona gestió de requisits, informes, gestió de projectes per a equips àgils de
desenvolupament de software i construccions automatitzades.
Azure DevOps cobreix tot el cicle de vida de l'aplicació i es pot utilitzar com un backend
per a nombrosos entorns de desenvolupament integrat (IDEs), però està adaptat per a
Microsoft Visual Studio en totes les plataformes.
Azure DevOps anteriorment es coneixia com a Team Foundation Server (TFS) o com a
Visual Studio Team Services (VSTS) en la seva versió cloud. El terme “DevOps”, que és
una combinació dels termes anglesos “Development” (desenvolupament) i “Operations”
(operacions).
En aquest projecte s’ha utilitzat aquest repositori perquè és molt eficaç i còmode
d’utilitzar, a part que també integra moltes funcionalitats interessants. L’avantatge més
important és que sincronitza perfectament amb el codi de Visual Studio.
Figura 25. Logo d’Azure DevOps
Modelatge de l’emergència climàtica amb NECADA
53
8.8. Justificació de les tecnologies L’elecció de les diferents tecnologies esmentades anteriorment és per exigència del
director del TFG, el Pau Fonseca. D’aquesta forma vol beneficiar el projecte NECADA
de l’exploració de noves tecnologies com són OPC-UA i .NET Core.
Respecte als llenguatges definits, que són ASP.NET Core i C#, són molt utilitzats en la
creació d’aplicacions web de tota mena. Pel que fa a la base de dades de MongoDB i al
repositori d’Azure DevOps s’han escollit per la seva flexibilitat i alt rendiment en qualsevol
entorn de desenvolupament software.
9. Seguiment del projecte
9.1. Anàlisi del mercat
Si es focalitza la vista dins el mercat tecnològic i, més en concret, dins l’àmbit que tracta
aquest projecte, existeixen diversos protocols de comunicació en automatització
industrial relacionats amb OPC-UA. A continuació se citaran els més importants que
estan actualment al mercat.
Un d’aquests protocols (i un dels més comuns) és el MQTT (Message Queque Telemetry
Transport) [24]. Consisteix en un protocol de xarxa oberta que transporta missatges entre
dispositius. El protocol sol funcionar sobre TCP/IP. Cal destacar que OPC-UA i MQTT
poden treballar conjuntament.
MQTT es basa en un model de subscripció/publicació (com OPC-UA), en el qual els
publicadors envien missatges a un servidor i aquest és qui reenvia els missatges als
subscriptors evitant les connexions punt a punt entre subscriptors i publicadors. MQTT
està dissenyat per a poder ser implementat en dispositius de baixos recursos, en xarxes
de baixa amplada de banda i d'alta latència.
Un altre protocol de comunicació relacionat amb OPC-UA és Modbus [25]. Aquest
protocol s'utilitza per a establir una comunicació client-servidor entre dispositius. Modbus
té moltes opcions de protocol, però les dues més utilitzades són el Modbus RTU (Remote
Terminal Unit) i el Modbus TCP/IP (Transmission Control Protocol).
Modelatge de l’emergència climàtica amb NECADA
54
També relacionat amb OPC-UA, cal destacar el sistema SCADA (Supervisory Control
And Data Acquisition) [26]. És un sistema de control industrial que té com a finalitat
supervisar i controlar remotament una instal·lació, podent integrar dades recollides en
temps real des de diferents sensors, autòmats (PLCs o Power Line Communication) i
equips mitjançant diferents protocols en un sol lloc.
Dins SCADA, OPC-UA té diferents especificacions. Per exemple, descriu diferents
conceptes de seguretat, com les potencials amenaces en sistemes basats en OPC-UA,
descriu la direcció que segueixen les dades des d'un servidor OPC-UA cap a un client
OPC o indica la forma en la qual es transfereixen en general les dades entre els servidors
i els clients.
Finalment, cal mencionar l'Informe SIRENA [27] que té molta relació amb NECADA en
el camp de la sostenibilitat energètica. Aquest informe té com a objectiu avaluar l’evolució
del consum de subministraments de la UPC i el seu impacte econòmic, alhora, serveix
per a fer el seguiment de la política energètica de la Universitat.
9.2. Anàlisi d’alternatives En aquest projecte s’ha valorat una possible alternativa en el cas que l’aplicació web no
tirés endavant. Aquesta alternativa és treballar directament dins el model SDL de
NECADA. Com que el desenvolupament de l’aplicació web ha sigut satisfactori, l’opció
adoptada ha estat la correcta.
9.3. Integració de coneixements Per dur a terme el desenvolupament del projecte, s’han hagut d’integrar una sèrie de
coneixements els quals s’han adquirit durant el Grau i alguns a base d’autoaprenentatge.
Pel que fa a assignatures del Grau, les següents han tingut una rellevància important
(sobretot les de l’especialitat de Tecnologies de Ia Informació):
Aplicacions Distribuïdes (AD) : Saber el funcionament d'aplicacions i serveis
basats en el protocol HTTP i altres protocols de nivell d'aplicació. També tenir la
capacitat de posar en marxa diferents aplicacions i serveis web en qualsevol
àmbit.
Modelatge de l’emergència climàtica amb NECADA
55
Protocols d’Internet (PI) : Saber definir, planificar i gestionar la instal·lació de
qualsevol infraestructura TIC d’una organització.
Xarxes de Computadors (XC) : Saber com funcionen els diferents protocols de
comunicació existents a Internet i, com s’intercanvia la informació de forma fiable
i eficient.
Projecte de Tecnologies de la Informació (PTI) : Tenir la capacitat de saber
plantejar una proposta de projecte i saber definir-la, crear-la, desenvolupar-la i
gestionar-la.
Base de Dades (BD) : Saber com funciona una base de dades i gestionar-la.
Projecte Aplicat d’Enginyeria (PAE) : Tenir la capacitat de saber desenvolupar
una proposta de projecte d’una empresa de forma innovadora i creativa.
Pel que fa a tecnologies i llenguatges proposats en el projecte, tots/es han sigut a base
d’autoaprenentatge, ja que mai s’hi havia treballat. Serien el protocol OPC-UA, els
llenguatges C# i HTML, la base de dades de MongoDB i la tecnologia ASP.NET Core. A
això si ha d’afegir la capacitat i ganes d’aprendre llenguatges nous per tal d’assolir un
bon nivell en qualsevol projecte relacionat.
9.4. Identificació de lleis i regulacions Com en molts projectes tecnològics, aquest projecte l’afecta la llei GDPR (General Data
Protection Regulation o Reglament General de Protecció de Dades (RGPD)) [28].
Aquesta llei és el nou marc legal de la Unió Europea que reemplaça a la Directiva de
Protecció de Dades.
El que busca la GDPR és protegir les dades personals i la forma en la qual les
organitzacions les processen, emmagatzemen i, finalment, destrueixen, quan aquestes
dades ja no són requerides. La llei proveeix control individual sobre com les companyies
poden usar la informació que està directa i personalment relacionada amb els individus.
Modelatge de l’emergència climàtica amb NECADA
56
Una altra llei que afecta aquest projecte és la llei LSSICE (Llei de Serveis de la Societat
de la Informació i Comerç Electrònic) [29]. Aquesta llei regula l’Internet a Espanya, les
transaccions i comunicacions electròniques (webs, blogs, botigues online...).
La LSSICE regula determinats aspectes jurídics dels Serveis de la Societat de la
Informació. Per tant, conformen aquests serveis les següents activitats: comerç
electrònic, contractació en línia, informació i publicitat i, serveis d’intermediació.
En referència amb aquest projecte, la llei LSSICE té molta relació perquè al crear una
aplicació web sempre es demana el consentiment de l’usuari en l’acceptació de termes i
condicions i la seva lliure distribució a tercers.
Modelatge de l’emergència climàtica amb NECADA
57
10. Codificació de l’aplicació web Com bé s’ha descrit en l’apartat “5. Planificació temporal”, el projecte es dividirà en 3
grans tasques. La primera serà l’especificació de quins requisits necessitarà el projecte,
ja que és essencial saber amb quines tecnologies es treballarà.
La segona tasca, que serà la de la codificació de l’aplicació web, a la vegada es dividirà
en unes altres 3 subtasques que seran la seva integració amb OPC-UA, amb .NET Core
i, amb NECADA (com s’hi connectarà).
Finalment, la tercera i última gran tasca serà la de validar els resultats obtinguts a mesura
que es completin totes les tasques anteriors esmentades. Aquesta validació es farà al
final de la realització de cada tasca per veure que tot funcioni correctament i els resultats
siguin els esperats. Cada tasca i subtasca realitzada es descriurà en detall a continuació
per tal de fer-ne un bon seguiment.
10.1. Especificació dels requisits
La primera fase del projecte serà la de definir els principals requisits que ha de tenir el
projecte per poder realitzar-se de forma correcta. El primer d’ells és que es treballarà
amb la tecnologia OPC-UA (descrita en l’apartat 8.1.).
Per dur a terme el seu estudi, s’implementarà un client i un servidor OPC-UA simulats
dins la IDE de Visual Studio 2019 (versió 16.7.7) per a Windows 10, ja que és molt potent
i permet integrar-ho tot (es crearà una petita aplicació de consola).
En fer servir OPC-UA s’utilitzarà un SDK anomenat “OPC-UA .NET SDK Client+Server”,
el qual facilitarà el desenvolupament per estudiar i veure com es treballa amb OPC-UA.
La versió del SDK serà la més recent, la 2.11.2.
Com bé s’ha explicat en l’apartat 8.1.1., aquest SDK s’usa mitjançant el paquet anomenat
“Opc.UaFx.Advanced” (per a clients i servidors OPC-UA) o el paquet anomenat
“Opc.UaFx.Client” (només per a clients OPC-UA). Més endavant es detallarà com s’han
fet servir aquests paquets per a integrar-ho amb el projecte.
Modelatge de l’emergència climàtica amb NECADA
58
A més, per mostrar de forma gràfica les trames enviades i rebudes entre el client i el
servidor OPC-UA simulat (i actualitzacions de valors), s’utilitzarà un simulador de client
OPC-UA anomenat UaExpert (explicat en l’apartat 8.1.2.). La versió serà la 1.5.1 (versió
estable del 2019).
La base de dades per guardar les mesures enviades pel client OPC-UA serà MongoDB,
ja que en ser una base de dades no relacional és molt més flexible i òptima per aquest
cas. La versió que es farà servir de MongoDB serà la 4.4.2.
Pel que fa als drivers/llibreries utilitzats, s’utilitzarà el driver .NET oficial de MongoDB
anomenat MongoDB.Driver (versió 2.11.4) i que és el més complet. Paral·lelament,
també es farà servir la llibreria Bson oficial de MongoDB anomenada MongoDB.Bson
(versió 2.11.4) que integra totes les funcionalitats necessàries per dur a terme la connexió
amb MongoDB.
Per facilitar la visió de com serà la base de dades de MongoDB de forma gràfica,
s’utilitzarà la seva interfície gràfica anomenada MongoDB Compass (versió 1.23.0) que
és molt senzilla per treballar-hi.
Una vegada definits els requisits tant per OPC-UA com per MongoDB, ara es definiran
els referents a l’aplicació web. Aquesta aplicació també es desenvoluparà en el Visual
Studio 2019 (versió 16.7.7) per Windows 10.
Concretament, es farà servir l’opció “ASP.NET Core Web Application” per poder treballar
amb .NET Core (la tecnologia .NET que es vol utilitzar en aquest cas). La versió serà la
3.1, ja que és una de les més recents i estables.
Respecte al patró de disseny, s’escollirà l’arquitectura MVC (Model-Vista-Controlador).
El principal objectiu d’aquesta arquitectura és separar el model de dades de la interfície
d’usuari i la lògica de control.
Un cop s’han especificat tots els requisits, s’explicarà com es farà la integració de les
tecnologies anteriorment esmentades i quina serà l’arquitectura del sistema final del
projecte.
Modelatge de l’emergència climàtica amb NECADA
59
10.2. Codificació de l’aplicació La segona fase del projecte serà la de codificar l’aplicació web. Abans d’entrar en detall
sobre com es portarà a terme aquesta codificació, cal saber i entendre com funcionarà
tota l’arquitectura general del sistema en la que s’engloba el projecte i quines parts
intervindran en aquest.
Primerament, hi ha un client OPC-UA que és un mesurador de CO2 simulat (pot ser
qualsevol sensor/dispositiu i poden ser molts) i envia les seves mesures a NECADA.
NECADA és un element que està a sobre del servidor OPC-UA que va llegint la
informació que li arriba del client a través de, precisament, el mateix protocol, OPC-UA.
NECADA processa tot aquesta informació i envia les dades cap a un simulador anomenat
SDLPS (en aquest projecte no es farà servir ni s’hi entrarà en detall). Aquest simulador
llegeix aquesta informació, li retorna a NECADA i, aquesta, la mostra.
Per altra banda, NECADA també té una base de dades que permet guardar la informació
dels experiments i dels edificis. Llavors hi ha diferents usuaris que es connecten a
NECADA i veuen en temps real les mesures referents als edificis (emissions de CO2,
temperatura, humitat, etc.).
En altres paraules, NECADA té la seva pròpia infraestructura per fer les simulacions i els
vincles amb bases de dades (per exemple, la del cadastre) que directament permeten
generar models simulats amb el simulador SDLPS. Per tant, cal tenir en compte que en
aquesta arquitectura, hi ha molts elements i tecnologies que estan interconnectats.
L’avantatge és que tota la part d’OPC-UA no té dependències ni cap a NECADA ni cap
al simulador SDLPS i, per tant, aquesta infraestructura es pot muntar directament i mirar
com funciona. Més endavant, ja es podrà fer la integració/connexió amb NECADA.
El servidor OPC-UA necessitarà una base de dades per guardar la informació que rebrà
en temps real (simulat) dels clients. Aquesta base de dades serà NoSQL, és a dir, una
base de dades no relacional.
La més coneguda i la que s’utilitzarà en aquest projecte serà MongoDB. L’elecció
d’utilitzar aquest tipus de base de dades és perquè, d’aquesta manera, no podrà interferir
en les altres bases de dades que s’utilitzin dins de l’arquitectura general.
Modelatge de l’emergència climàtica amb NECADA
60
Com que hi haurà molts clients (sensors de CO2, sensors de temperatura...) que aniran
enviant informació cada pocs segons, això suposarà una quantitat molt gran d’informació
i la millor forma de guardar aquestes mesures és amb una base de dades d’aquestes
característiques.
Una vegada tota la informació del servidor OPC-UA estarà guardada a la base de dades
de MongoDB, cal que hi hagi un element que connecti aquest servidor amb NECADA.
Aquest element serà una aplicació web creada amb ASP.NET Core que farà de “pont”
entre NECADA i OPC-UA.
L’aplicació accedirà a la col·lecció de MongoDB on hi haurà totes les mesures que aniran
entrant des del servidor OPC-UA i les mostrarà en format web. En els següents apartats
es definirà amb exactitud com serà el disseny d’aquesta aplicació. La Figura 26 mostra
de forma gràfica com serà tota aquesta arquitectura general anteriorment mencionada i
les seves parts diferenciades.
Figura 26. Arquitectura general del sistema del projecte
Modelatge de l’emergència climàtica amb NECADA
61
Per portar a terme les tasques de manera més senzilla i entendre millor com funcionen
les tecnologies OPC-UA i .NET Core, s’ha decidit crear per separat 2 prototipus
independents els quals cada un d’ells inclourà les tasques d’especificació, codificació i
validació.
El primer prototipus serà per veure la integració amb OPC-UA, com es connecten un
client i un servidor simulats i, veure com es guarden les mesures dins MongoDB. El segon
prototipus serà basat en .NET Core amb la creació de l’aplicació web i la integració amb
el primer prototipus (OPC-UA i MongoDB).
Finalment, un cop s’hagin creat els dos prototipus i s’hagin validat correctament,
l’aplicació web es connectarà directament a NECADA (hi haurà una pestanya amb un
enllaç directe a l’aplicació). Per tant, aquesta tasca de codificació es dividirà en 3
subtasques (seran els dos prototipus afegint la connexió a NECADA) que s’expliquen a
continuació.
10.2.1. Creació d’un prototipus per a la integració amb OPC-UA
Per veure com funciona OPC-UA, caldrà tenir en compte diferents requisits. L’objectiu és
crear un client OPC-UA simulat que serà un sensor i un servidor OPC-UA (també simulat)
per veure les trames entre ells i com es comuniquen mitjançant el protocol OPC-UA. Es
programarà amb el llenguatge C#.
Com bé s’ha esmentat en l’apartat “10.1. Especificació dels requisits”, l’element essencial
per dur a terme aquesta connexió entre un client i un servidor OPC-UA és el SDK
“Opc.UaFx.Advanced”. S’ha buscat altres SDKs o llibreries semblants, però al final s’ha
decidit per aquest perquè integra moltes funcionalitats. La Figura 27 mostra que, en
aquesta part del projecte, ens centrarem en la connexió client-servidor OPC-UA.
Figura 27. Arquitectura de la connexió Client-Servidor OPC-UA simulats
Modelatge de l’emergència climàtica amb NECADA
62
En aquest cas, el client OPC-UA simula un sensor de CO2 que envia constantment cap
al servidor OPC-UA les mesures del nivell/quantitat de CO2 que hi ha en l’aire (les unitats
són en PPM o Parts Per Milió). Un cop creats el client i el servidor, és hora de veure si
funciona correctament la connexió entre ells.
Per portar a terme aquesta validació, hi haurà dues formes de fer-ho. La primera és que,
com s’ha partit de la base que aquest prototipus s’ha creat en una aplicació de consola
en el Visual Studio, la mateixa consola mostrarà si entre el client i el servidor es
connecten de forma correcta.
La Figura 28 mostra la resposta del servidor comunicant-li al client que els nivells de CO2
rebuts són correctes (estan dins el marge de seguretat: [350 PPM a 450 PPM]).
Figura 28. Resposta del servidor OPC-UA davant l’enviament de mesures del client OPC-UA
(sensor de CO2)
La segona forma de validació és mitjançant el simulador de client OPC-UA anomenat
UaExpert (descrit en l’apartat 8.1.2.) que mostra com els valors enviats pel client
s’actualitzen correctament i mostra altres propietats importants en la connexió OPC-UA.
A continuació, s’explicaran les parts principals d’aquest simulador per entendre millor el
seu funcionament. La Figura 29 mostra les finestres (Windows) que es compon
UaExpert. Entendre-les és la clau per saber com funciona.
En total disposa de 6 finestres que es distribueixen de tal manera que l’usuari li és molt
pràctic fer un seguiment dels valors que s’actualitzen cada cop que s’envia una dada al
servidor OPC-UA.
Modelatge de l’emergència climàtica amb NECADA
63
Figura 29. Finestres (Windows) principals d’UaExpert
Les finestres principals d’UaExpert són les següents: - Finestra de Documents (Document Window): Pot mostrar diferents modes de
visualització. Per defecte, se selecciona la Vista d'Accés a les Dades (Data Access View).
- Finestra del Projecte (Project Window): Es pot utilitzar per a gestionar múltiples
connexions de servidor.
- Finestra d'Espai de Direccions (Address Space Window): Mostra l'espai de direccions
del servidor que està actualment seleccionat en la Finestra del Projecte.
- Finestra d'Atributs (Attributes Window): Mostra els atributs del node que està
actualment seleccionat en la Finestra d'Espai de Direccions.
- Finestra de Referències (References Window): Mostra les referències del node que
està actualment seleccionat en la Finestra d'Espai de Direccions.
- Finestra de Registres (Log Window): Mostra els missatges d'estat i d'error.
Modelatge de l’emergència climàtica amb NECADA
64
Un cop s’han explicat les parts principals d’UaExpert, cal veure si funciona i se sincronitza
correctament amb la visualització de la resposta del servidor en la consola que s’ha
comentat anteriorment.
Les parts o finestres que més interessen són la Finestra de Documents i la Finestra del
Projecte. Sobretot, dins de la Finestra de Documents, interessa la Data Access View
(Vista d'Accés a les Dades) anteriorment mencionada. Aquesta vista es pot usar per a
monitoritzar els canvis de l'atribut de valor de les variables.
Per mostrar aquests canvis, és a dir, les actualitzacions dels valors de la resposta del
servidor, cal seleccionar un o més valors de la Finestra d’Espai de Direccions i
arrossegar-los fins a la Finestra dels Documents.
En aquest punt UaExpert crearà una subscripció que contingui aquests elements i els
mostrarà en una llista. És possible utilitzar elements de diferents servidors en la mateixa
plantilla (es crearia una subscripció separada per a cada servidor que s’estigui utilitzant).
El valor “Value” indica l’atribut de valor d’escriptura d’un node. En aquest cas seria la
mesura del sensor. La Figura 30 mostra el moment en què UaExpert actualitza els valors
enviats al servidor OPC-UA amb la variable “Value” (marcada amb una fletxa vermella).
Figura 30. Captura del moment en què UaExpert actualitza els valors enviats al servidor OPC-
UA amb la variable “Value”
Modelatge de l’emergència climàtica amb NECADA
65
Si s’amplia la captura i es focalitza l’atenció en el Data Access View, es veuran els
diferents camps que la componen. Aquests camps són el tipus de servidor (Server),
l’identificador del Node (NodeId), el nom del valor (Display Name), l’atribut de valor
d’escriptura d’un node (Value), el tipus de dada (Datatype) i la indicació de la duració del
temps que s’està executant el servidor (Server Timestamp).
Figura 31. Captura ampliada del ”Data Access View” d’UaExpert on mostra l’actualització de les
diferents mesures mitjançant la variable “Value”
En qualsevol connexió entre un client i un servidor es necessita una base de dades on
guardar tota la informació enviada i rebuda. Per això, tornant a mirar l’arquitectura
general definida a la Figura 26, ara se centrarà en com guardar totes les mesures que el
servidor OPC-UA ha rebut del client OPC-UA (sensor de CO2).
Com bé s’ha dit anteriorment, al ser una base de dades no relacional, MongoDB és
perfecte perquè com que el servidor OPC-UA rebrà en tan poc temps moltes dades
procedents del sensor de CO2, el millor mètode és guardar-les en documents dins una
col·lecció anomenada “mesures”.
El concepte de “col·lecció” i “document” està explicat amb detall en l’apartat “8.3.
MongoDB”. La Figura 32 mostra la part de l’arquitectura que ara es tractarà utilitzant una
base de dades no relacional com és MongoDB.
Figura 32. Arquitectura de la connexió Client-Servidor OPC-UA amb MongoDB
Modelatge de l’emergència climàtica amb NECADA
12 “URL = localhost:27017”. Més endavant es veurà que aquesta URL canvia i es converteix en una de general 66
Per facilitar el fet de treballar amb MongoDB, s’utilitzarà la interfície gràfica oficial
anomenada MongoDB Compass (descrita en l’apartat 8.3.2.). Aquesta interfície
proporciona un entorn molt pràctic i senzill on es poden crear diferents bases de dades
i, a dins de cadascuna, les col·leccions que vulgui l’usuari amb els seus respectius
documents.
La Figura 33 mostra la pantalla inicial de MongoDB Compass (en mode local12) on s’ha
creat la base de dades anomenada “MesuresCO2” especialment per aquest projecte. La
resta de base de dades que hi ha són predeterminades (“admin”, “config” i “local”).
Quan es clica a la base de dades “MesuresCO2”, es mostren totes les col·leccions
associades a ella. En aquest cas, només n’hi ha una que és “mesures” (Figura 34) la
qual és on es guardaran tots les mesures que el sensor li enviï al servidor OPC-UA.
Figura 33. Pantalla inicial de les diferents bases de dades en MongoDB Compass
Modelatge de l’emergència climàtica amb NECADA
13 Segons transcorreguts des de l’1 de gener de 1970 : https://hardzone.es/reportajes/que-es/tiempo-epoch-pc 67
Figura 34. Pantalla de la col·lecció “mesures” de la base de dades “MesuresCO2” en MongoDB
Compass
Una vegada s’ha creat la base de dades i la col·lecció, ja es pot començar a executar la
connexió entre el sensor i el servidor OPC-UA perquè es mostrin les mesures en forma
de nivell de CO2.
La Figura 35 mostra com es van guardant els valors automàticament a la col·lecció
“mesures” en forma de documents cada cop que el sensor li va enviant informació al
servidor OPC-UA.
En aquest cas, cada document té 3 camps. El primer d’ells és el “_id” o identificador únic
del document. MongoDB és qui assigna automàticament aquest identificador a cada
document inserit en la base de dades i és de tipus ObjectId (4 bytes des de la data epoch
d’UNIX13, 3 bytes de l’ID de la màquina, 2 bytes de l’ID del procés i 3 bytes de comptador
incremental).
El segon camp en la col·lecció és un “id” de tipus string. Aquest identificador s’ha posat
simplement perquè sigui més fàcil de llegir i de referenciar que l’identificador únic que
proporciona MongoDB. En aquest cas, es diu “CO2”.
Modelatge de l’emergència climàtica amb NECADA
68
El tercer i últim camp és el “nivell”. Aquesta variable és la més important, ja que indica
el nivell de CO2 que arriba procedent del sensor cada pocs segons. Més endavant, quan
es crearà l’aplicació web, se li afegirà un quart camp anomenat “timestamp” perquè sigui
més realista i simuli que les mesures s’envien en temps real.
Figura 35. Captura dels valors guardats automàticament a mesura que el sensor li va enviant
informació al servidor OPC-UA
En aquest punt acaba la primera tasca del projecte que és la de treballar amb el protocol
OPC-UA de forma local. Les següents tasques seran la de crear l’aplicació web, com
integrar-la amb OPC-UA i alhora, connectar-la amb NECADA.
Modelatge de l’emergència climàtica amb NECADA
69
10.2.2. Creació d’un prototipus per a la integració amb .NET Core
Com bé s’ha explicat anteriorment en l’apartat “1.1.2. Formulació del problema”, la
integració de les tecnologies OPC-UA i .NET Core es farà mitjançant una aplicació web
anomenada “NECADA Sensors” desenvolupada amb el framework ASP.NET Core.
Aquesta aplicació permetrà rebre informació d’OPC-UA i enviar-la cap al model SDL de
NECADA. El que s’ha aconseguit fins ara és agafar informació d’OPC-UA i, a partir
d’aquesta informació, guardar-la a una base de dades (MongoDB).
Cal destacar que la base de dades de NECADA és relacional (concretament SQL Server)
a diferència de la base de dades que s’ha utilitzat per guardar la informació del sensor
de CO2 (base de dades no relacional). Tal com indica la Figura 36, la part de l’arquitectura
que es treballarà en aquest cas és la pintada en vermell (connexió d’ASP.NET Core amb
OPC-UA i MongoDB).
Figura 36. Arquitectura de la connexió de l’aplicació web amb OPC-UA i MongoDB
A partir d’aquí s’ha d’imaginar com s’ha de definir la interfície per tal que l’usuari pugui
accedir a aquesta informació. Però abans cal posar en context el punt actual de
desenvolupament del projecte.
Modelatge de l’emergència climàtica amb NECADA
70
Primerament, dins NECADA hi haurà la definició de l’edifici en general, però els sensors
estaran situats en una sala concreta de l’edifici. L’ideal seria fer un model 3D de l’edifici
i, a través de la web, veure com estan situats aquests sensors. En aquest cas, però,
aquesta via no s’explorarà (es necessitaria més temps).
El que es farà serà que aquests sensors que es definiran en OPC-UA se’ls hi ha
d’assignar una posició concreta dins l’edifici simplement amb una petita descripció de la
seva ubicació (Edifici X, Planta Y, Secció Z...). Amb això es tindria un llistat dels sensors
amb les ubicacions de cadascun i estarien classificats per la seva tipologia (CO2,
temperatura, humitat...).
En el sistema de NECADA, per a un usuari que pot executar nivells de simulació, es
defineixen els materials de cada edifici, la part del clima (CO2, temperatura, humitat...),
la part de la sostenibilitat de l’edifici i finalment la part de projectes. Tot això està
relacionat amb la definició de com ha de ser l’edifici.
Figura 37. Exemple dels projectes creats dins del sistema de NECADA
L’usuari pot accedir a un “dashboard” o taulell en el qual té tots els seus experiments
amb la respectiva informació de cadascun. Un edifici té 2 conceptes. Un és el de la seva
definició, és a dir, com funcionarà (modelatge d’informació de la construcció,
sostenibilitat...). L’altre concepte és el del seu manteniment (ús de l’edifici).
Si l’edifici s’està utilitzant, llavors les simulacions també s’utilitzen per veure si s’ajusten
al que un usuari està definint. Aquí és on entra la sensòria. Dins l’aplicació web que es
crearà hi haurà una pestanya que serà la monitorització de l’edifici (s’anomenarà
“Buildings”).
Modelatge de l’emergència climàtica amb NECADA
71
Aquesta monitorització ve a través dels projectes. Per exemple, hi ha un projecte
qualsevol que té un conjunt d’experiments que es defineixen. Dins de cada experiment
hi ha els resultats de les execucions dels models de simulació. Un resultat d’aquests pot
donar molts edificis candidats i, a la vegada, un d’aquests edificis és el que finalment
s’estarà monitoritzant.
Dins de la definició de l’estructura de NECADA, hi ha diferents configuracions d’edificis
(independents entre ells) que no existeixen realment i simplement es proven
configuracions per fer-los òptims.
Tots els edificis estan modelats amb una estructura SDL concreta que defineix el procés
de com es comporta l’edifici. El que realment es canvia és la parametrització d’aquest
model de simulació amb SDL. En la part de monitorització no hi ha models SDL. Un cop
l’edifici està construït, s’ha de definir la seva gestió/monitorització.
En aquest punt és on entra l’aplicació web d’aquest projecte. Primerament, per
comprovar la connexió de l’aplicació amb la base de dades de MongoDB, s’ha creat una
API (Application Programming Interface o Interfície de Programació d’Aplicacions)
independent amb els mateixos requisits que l’aplicació web per tal de mostrar la
integració d’ASP.NET Core amb aquest tipus de bases de dades no relacionals.
Una API és un conjunt de definicions i protocols que s'utilitza per a desenvolupar i integrar
el software de les aplicacions. El que s’ha programat és que, cada vegada que una
mesura es guarda a MongoDB, aquesta la recull l’API i la mostra en 4 camps diferents:
“_id”, “tipus”, “nivell” i “timestamp”.
Tots aquests camps tenen les mateixes especificacions que s’han definit anteriorment en
l’apartat “10.2.1. Creació del prototipus amb OPC-UA”. En aquest cas, el camp “tipus” és
igual que el camp “id” creat anteriorment en el prototipus d’OPC-UA (és “CO2”), només
que se li ha canviat el nom per diferenciar-lo del “_id” de MongoDB.
Precisament en l’apartat del prototipus amb OPC-UA, s’ha esmentat que s’afegiria un
quart camp anomenat “timestamp” dins de MongoDB en el moment de crear l’aplicació
web (i òbviament, això també afecta l’API).
Modelatge de l’emergència climàtica amb NECADA
72
El camp “timestamp” retorna exactament la data d’inserció actual de la mesura a
MongoDB en el format “yyyyMMddHHmmss” o cosa que és el mateix: Any (4 dígits), Mes
(2 dígits), Dia (2 dígits), Hora (2 dígits), Minut (2 dígits) i Segon (2 dígits).
La raó per la qual s’ha afegit aquest quart camp és per verificar que els valors que van
entrant a la base de dades són els correctes i són en temps real. En la Figura 38 es pot
observar com, a mesura que es van inserint els valors a MongoDB (nivells de CO2 del
sensor simulat), automàticament aquests es mostren a l’API mitjançant l’URL en local :
https://localhost:5001/api/mesures. Més endavant aquesta URL canviarà i serà general.
Figura 38. Captura de la connexió de l’API amb la base de dades de MongoDB
D’aquesta manera, una vegada ja s’ha validat la connexió amb MongoDB correctament
des de l’API, el codi ja es pot adaptar a l’aplicació web final que servirà per fer la
demostració. El codi per connectar-se a MongoDB i obtenir les mesures del sensor de
CO2 simulat és idèntic que el que hi ha a l’API (evidentment ajustat a les funcionalitats
de l’aplicació web).
Modelatge de l’emergència climàtica amb NECADA
14 https://www.smarterasp.net 73
Pantalles de l’aplicació web L’aplicació web feta amb el framework .NET Core és un element clau en aquest projecte.
És la connexió entre el protocol OPC-UA i el sistema de NECADA. Aquesta aplicació
s’allotja en un servidor web d’aplicacions anomenat SmarterASP14 el qual pot contenir
diferents aplicacions basades en ASP.NET. A continuació, es veurà com serà el disseny
de l’aplicació i les seves respectives pantalles (són 4 en total).
D’entrada, en la Figura 39 es mostra com serà la pantalla inicial de l’aplicació web. Com
es pot observar, a la barra d’administració apareixerà el nom de l’aplicació (en aquest
cas és “NECADA Sensors”) i al seu costat una pestanya anomenada “Buildings” que
seran tots els edificis que es tractaran.
Figura 39. Pantalla d’inici de l’aplicació web NECADA Sensors
Dins el menú d’administració de la pestanya “Buildings” apareixerà una llista amb tots els
edificis construïts prèviament que s’han de gestionar/monitoritzar a partir de cada
experiment simulat fet anteriorment a NECADA. La Figura 40 mostra la llista de tots els
edificis construïts per poder monitoritzar-los.
Modelatge de l’emergència climàtica amb NECADA
74
Figura 40. Pantalla on es mostren tots els edificis per poder monitoritzar-los
Dins de cada edifici escollit s’accedirà a la seva informació corresponent que serà una
llista amb els sensors els quals es treballarà. És a dir, serà un llistat amb el qual l’usuari
pugui introduir una casuística de diferents sensors. En aquest cas, hi ha 5 sensors que
mesuren els nivells de CO2, de temperatura, d’humitat, de pressió atmosfèrica i de la
velocitat del vent.
El fet d’obtenir totes aquestes mesures a partir dels diferents sensors que estan repartits
per tot l’edifici fa que es tingui una visió més detallada de com el clima pot afectar-lo i,
d’aquesta manera, fer-lo el més sostenible possible. La Figura 41 mostra la llista de tots
els sensors associats a l’edifici seleccionat (en aquest cas, és l’Edifici 1).
Modelatge de l’emergència climàtica amb NECADA
75
Figura 41. Pantalla on es mostren tots els sensors instal·lats en l’Edifici 1
Quan es clica sobre un sensor concret, es visualitza la seva informació associada. En la
definició de cada sensor es pot tenir una visió de la seva ubicació dins l’edifici (planta,
àrea, secció...), de si el sensor està funcionant correctament o no (estat actiu o inactiu) i
de la seva última actualització.
Abans d’entrar en detall sobre com s’ha pensat i programat la connexió de l’aplicació web
tant amb el protocol OPC-UA com amb MongoDB, cal dir que aquesta tasca ha estat la
més costosa de realitzar i la que més temps de dedicació ha portat al desenvolupador
del projecte.
La raó per la qual ha sigut complexa la integració amb la base de dades de MongoDB és
perquè, com que aquesta obté els valors a partir d’una altra tecnologia com és OPC-UA,
no ha sigut fàcil la seva integració dins l’aplicació web.
Modelatge de l’emergència climàtica amb NECADA
76
S’han tingut en compte els requisits que comporta utilitzar MongoDB (drivers/llibreries) i
ajustar-los al model MVC (Model-Vista-Controlador) del framework ASP.NET Core no ha
sigut senzill. L’aplicació web en cap moment tracta amb OPC-UA directament, sinó que
sempre ho fa a través de MongoDB.
Com s’ha fet anteriorment amb l’API creada per tal de mostrar les mesures provinents de
MongoDB, la Figura 42 mostra el mateix, però ara dins l’aplicació web (és la següent
pantalla de clicar en el sensor de CO2). Igual que a l’API, es mostren els 4 camps (“_id”,
“tipus”, “nivell” i “timestamp”) per identificar millor cada mesura i que s’han explicat
anteriorment.
Figura 42. Pantalla on es mostra la informació associada al sensor de CO2
Finalment, no s’ha pogut mostrar únicament l’última mesura inserida a MongoDB dins
l’aplicació web per falta de temps.
Modelatge de l’emergència climàtica amb NECADA
77
A continuació s’explicaran cadascun dels fitxers i les classes (no tots sinó els més
importants) que han fet possible la connexió de l’aplicació web amb MongoDB. D’aquesta
manera s’entendrà millor la integració. La Figura 43 mostra tota aquesta llista de fitxers
en el Visual Studio i a l’Annex A hi ha el codi complet corresponent a cadascun dels
fitxers.
Figura 43. Llistat de tots els fitxers de l’aplicació web NECADA Sensors
Modelatge de l’emergència climàtica amb NECADA
78
Fitxers de l’aplicació web NECADA Sensors
appsettings.json Conté totes les propietats referents a la connexió amb MongoDB :
- MongoDBSettings : Nom de la secció que conté els paràmetres necessaris per
connectar-se a MongoDB.
- DatabaseName : Nom de la base de dades. En aquest cas, és MesuresCO2.
- CollectionName : Nom de la col·lecció. En aquest cas, és mesures.
- ConnectionString : String de la connexió a MongoDB. L’URL és :
mongodb+srv://ley3tszuz2:[email protected]
Aquesta URL s’allotja en un servei en el cloud de MongoDB anomenat MongoDB Atlas i
s’hi connecta de manera remota. Com a conseqüència, en el codi del servidor OPC-UA,
es canvia l’antiga URL que hi havia (la que es connectava a MongoDB de forma local)
per aquesta nova URL que es connecta a aquest servei esmentat.
MongoDBSettings.cs És una classe que s'utilitza per a emmagatzemar les mateixes propietats que les del fitxer
appsettings.json que anteriorment s’hi han afegit: MongoDBSettings, DatabaseName,
CollectionName i ConnectionString.
També es crea una interfície anomenada IMongoDBSettings pel sistema d’injecció de
dependències d’ASP.NET Core (en la descripció del fitxer Startup.cs s’explica en què
consisteix).
Mesura.cs És una classe que conté les propietats que es mostren a cada document inserit a la
col·lecció mesures de la base de dades MesuresCO2 de MongoDB. Són 4:
- Id : Identificador únic per defecte que proporciona MongoDB per a cada document.
- Tipus : Identificador que s’ha posat perquè sigui més senzill saber que són mesures de
CO2.
- Nivell : Nivell de CO2 corresponent a cada mesura enviada pel sensor.
- Timestamp : Marca de temps que indica el moment en què el servidor ha rebut la
mesura.
Modelatge de l’emergència climàtica amb NECADA
79
MesuraService.cs És la classe que serveix per connectar MongoDB amb l’aplicació web d’ASP.NET Core.
Dins d’aquesta classe s’instància una altra classe anomenada dbClient (pertany al driver
MongoDB.Driver) amb la classe IMongoDBSettings (interfície que es crida en el fitxer
Startup.cs) que carregarà la configuració establerta en el fitxer appsettings.json descrit
anteriorment.
Després es crea un objecte que accedeix a la base de dades MesuresCO2 de MongoDB
amb la funció GetDatabase i un altre que fa referència a la col·lecció mesures amb la
funció GetCollection.
Aquesta classe MesuraService.cs també té un mètode Get( ) que retorna en forma de
llista les mesures que van entrant a MongoDB. La definició general d’un servei en aquest
tipus d’aplicacions seria la d’un component reutilitzable que proporciona funcionalitats
dins l'aplicació. La Figura 44 mostra tot aquest codi.
Figura 44. Codi de la connexió a MongoDB i l’obtenció de les mesures en ASP.NET Core
MesuraController.cs Aquest controlador és una part molt important de la connexió d’ASP.NET Core amb
MongoDB. Conté una variable anomenada _mesuraServ que fa que s’enllaci directament
amb la classe MesuraService.cs que és la que es connecta a MongoDB.
És el que accedeix a l’URL “http://terrassa40-001-site13.btempurl.com/api/mesures” per
obtenir, dins l’aplicació web, la llista de totes les mesures del sensor de CO2 simulat
inserides dins MongoDB. La part “terrassa40-001-site13.btempurl.com” de l’URL anterior
pertany al servidor SmarterASP (mencionat a la pàgina 73).
Modelatge de l’emergència climàtica amb NECADA
80
Això ho fa a partir del mètode Get( ) de la propietat ActionResult de .NET Core. També
conté un altre mètode Get( ) que en aquest cas busca per identificador (id). La Figura 45
mostra tot aquest codi. La vista que controla aquest controlador és el fitxer
SensorCO2.cshtml.
Figura 45. Codi del controlador que obté directament totes les mesures en forma de llista i pel
seu identificador
Startup.cs És una classe en la qual es configuren tant els serveis com la canalització de sol·licituds
de l'aplicació web. Té 2 mètodes que l’aplicació els crida quan s’inicia:
- Mètode ConfigureServices
Conté les opcions de configuració. Serveix per a configurar els serveis de l'aplicació web
i de MongoDB. En aquest cas, s’està dient que en la classe MongoDBSettings.cs es
carregarà la secció que té el mateix nom (MongoDBSettings) que està dins del fitxer
appsettings.json.
Modelatge de l’emergència climàtica amb NECADA
81
Per al sistema d’injecció de dependències d’ASP.NET Core el qual redueix la unió entre
objectes proporcionant una utilitat per a crear instàncies de la classe, quan es referenciï
a la interfície IMongoDBSettings creada en el fitxer MongoDBSettings.cs, en realitat
estarà fent una instància de la classe MongoDBSettings.
Aquesta interfície és de tipus “singleton” que assegura una única connexió oberta per a
realitzar totes les peticions a la base de dades. La Figura 46 mostra tot aquest codi.
Figura 46. Configuració dels serveis i les connexions a MongoDB en ASP.NET Core
- Mètode Configure
Serveix per a crear la canalització de processament de sol·licituds de l'aplicació, és a dir,
s'usa per a especificar la forma en què l'aplicació respon a les sol·licituds HTTP rebudes.
_Layout.cshtml És la vista per defecte que mostra com està dissenyada l’aplicació web (barra del menú,
disposició dels elements de la pàgina, etc.). Les aplicacions poden definir més d'un
disseny a la vegada tenint altres vistes que especifiquin altres dissenys diferents.
Buildings.cshtml És la vista que mostra la llista de tots els edificis que ja s’han construït de manera
simulada a partir dels experiments. En aquest cas, hi ha 10 edificis construïts (només se
centrarà en un per fer la demostració).
Sensors.cshtml És la vista que mostra la llista de tots els sensors que pertanyen a un edifici en concret
de la llista anterior. En aquest cas, hi ha 5 sensors: CO2, temperatura, humitat, pressió
atmosfèrica i velocitat del vent.
Modelatge de l’emergència climàtica amb NECADA
82
HomeController.cs Aquest controlador determina quines vistes cal mostrar. En aquest cas, crida les vistes:
- Index : Pàgina inicial de l’aplicació web NECADA Sensors.
- Buildings : Llista de tots els edificis construïts prèviament.
- Sensors : Llista de tots els sensors d’un edifici en concret.
- SensorCO2 : Informació referent al sensor de CO2 d’un edifici en concret.
SensorCO2.cshtml És la vista que mostra la informació referent al sensor de CO2 simulat. Per una banda,
es mostra la ubicació dins l’edifici (planta, àrea, secció...), si té un funcionament correcte
o incorrecte (estat actiu o inactiu) i la seva última actualització.
Per altra banda, la informació del nivell de CO2 provinent del client-servidor OPC-UA
simulats es recupera mitjançant una petició AJAX (Asynchronous JavaScript And XML).
Concretament es fa servir l’objecte “XMLHttpRequest” que obté de forma senzilla la
informació d'una URL sense haver de recarregar una altra vegada la pàgina completa.
L’objectiu que s’aconsegueix utilitzant aquesta petició AJAX amb el mètode “GET” és
accedir a l’URL relativa “api/mesures” que és on es van guardant totes les mesures
procedents d’OPC-UA.
És important que aquest URL sigui relativa perquè, d’aquesta manera, tant si es treballa
de manera local com en xarxa, automàticament el mateix navegador afegeix al davant el
“https://localhost:5001” o “http://terrassa40-001-site13.btempurl.com”, respectivament.
La Figura 47 mostra aquest codi.
Figura 47. Petició AJAX per accedir a la llista de mesures des de l’aplicació web
Modelatge de l’emergència climàtica amb NECADA
83
Havent finalitzat la integració de l’aplicació web amb MongoDB (i evidentment, amb el
protocol OPC-UA). En el següent apartat s’explicarà la connexió d’aquesta aplicació amb
el sistema de NECADA.
10.2.3. Connexió amb NECADA
Abans de veure en detall la connexió d’ASP.NET Core amb NECADA, cal recordar un
aspecte que s’ha esmentat en els anteriors apartats i és important tenir-ho en compte.
Inicialment, quan s’ha desenvolupat el client i el servidor OPC-UA simulats, la base de
dades i la seva respectiva col·lecció en MongoDB i, l’API que s’ha fet servir per validar
que les mesures es guarden correctament en .NET Core, s’ha treballat amb totes
aquestes tecnologies de forma local mitjançant l’URL (https://localhost:5001/...).
Llavors s’ha decidit que, com l’aplicació ha d’estar dins NECADA la qual és una web que
ha de ser accessible des de qualsevol lloc, l’URL s’ha canviat per una de general
(http://terrassa40-001-site13.btempurl.com/...) que s’ha adquirit a partir del servidor
SmarterASP (explicat a la pàgina 73) on està allotjada l’aplicació.
A continuació, es mostraran les pantalles de l’accés a l’aplicació web ASP.NET Core a
partir de NECADA. Aquesta integració és un desenvolupament dins un projecte real en
un producte de la UPC. L’URL general anterior correspon a un enllaç de la part de
producció de NECADA.
La Figura 48 mostra com s’ha afegit, dins el sistema de NECADA, una pestanya nova
anomenada Buildings que és la connexió directa amb l’aplicació web d’ASP.NET Core.
Figura 48. Pestanya addicional (en blau) dins NECADA que es connecta a l’aplicació web
Modelatge de l’emergència climàtica amb NECADA
84
Un cop s’ha clicat en la pestanya, es mostra una llista de tots els edificis simulats que
s’han construït a partir d’experiments previs (Figura 49). En aquest cas, se centrarà en
un únic edifici per fer la demostració, l’Edifici 1.
Figura 49. Llista dels edificis construïts dins NECADA
A diferència de l’aplicació original, en el moment que es clicava un edifici es mostraven
tots els sensors instal·lats en ell. En aquest cas, primer s’ha optat per accedir a una llista
on estan totes les sales disponibles de l’Edifici 1 (Figura 50). A cada una d’aquestes
sales, hi ha un nombre determinat de sensors els quals proveeixen molta informació
important relativa a l’edifici en concret.
Per fer la demostració, a un grup de sensors se’ls hi ha assignat la ubicació exacte dins
l’edifici (2n Planta - Àrea B - Secció 4). Una vegada s’ha seleccionat la sala concreta que
es vol observar, es mostra, ara ja sí, una llista amb tots els sensors instal·lats en ella.
La Figura 51 mostra una llista final amb tots els sensors que es poden tractar.
Seleccionant-ne un, es pot visualitzar tota la seva informació referent on s’inclouen
mesures i dades rellevants (Figura 52).
Modelatge de l’emergència climàtica amb NECADA
85
Figura 50. Llista de les sales disponibles de l’Edifici 1 dins NECADA
Figura 51. Llista dels sensors de la sala seleccionada de l’Edifici 1 dins NECADA
Modelatge de l’emergència climàtica amb NECADA
86
Finalment, tal com es mostra en la Figura 52, s’observa la mateixa informació generada
que hi havia en l’aplicació d’ASP.NET Core original: ubicació, estat (actiu o inactiu),
última actualització i les mesures procedents de MongoDB.
Per tant, l’objectiu de connectar NECADA amb l’aplicació web ha estat un èxit. A
diferència de quan s’havia desenvolupat l’aplicació en local, aquí l’URL és general:
“http://terrassa40-001-site13.btempurl.com/Home/SensorCO2”.
Figura 52. Informació general del sensor de CO2
Modelatge de l’emergència climàtica amb NECADA
87
10.3. Validació dels resultats
Com que en aquest projecte s’aplica la metodologia Scrum, fins que una tasca no s’ha
validat correctament no es passa a la següent. Per tant, s’aplicarà aquest mètode per fer
la validació necessària de les diferents tasques que s’han realitzat.
Per una banda, es validaran les tasques referents a la creació i programació del client i
del servidor OPC-UA simulats (amb UaExpert) afegint-li la connexió amb la base de
dades de MongoDB (amb MongoDB Compass). Per altra banda, es validarà la connexió
entre MongoDB i l’aplicació web feta amb el framework ASP.NET Core.
UaExpert i MongoDB Compass Tal com s’ha explicat en l’apartat “10.2.1. Creació d’un prototipus amb OPC-UA”, per
validar la connexió entre el client (sensor de CO2) i el servidor OPC-UA simulats s’ha fet
servir un programa anomenat UaExpert.
Aquest programa simula un client OPC-UA que es connecta a un servidor OPC-UA creat
inicialment. La Figura 53 mostra com, a partir de la variable “Value”, les mesures
procedents del client es van actualitzant al servidor. Per tant, tot correcte.
Figura 53. Validació de les actualitzacions de les mesures amb la variable “Value” en UaExpert
Respecte a la base de dades de MongoDB, s’ha utilitzat un programa extern anomenat
MongoDB Compass (també s’explica el seu funcionament en l’apartat 10.2.1.) que
consisteix en una interfície gràfica que conté les diferents bases de dades i col·leccions
creades.
La Figura 54 mostra la validació de les mesures rebudes pel client OPC-UA cap a
MongoDB en la col·lecció mesures dins la base de dades MesuresCO2. Amb la variable
“timestamp” també es valida que les mesures que s’insereixen a MongoDB són temps
actuals cada certs segons.
Modelatge de l’emergència climàtica amb NECADA
88
Figura 54. Validació de les actualitzacions de les mesures en MongoDB Compass
API i aplicació web NECADA Sensors Tal com s’ha explicat en l’apartat “10.2.2. Creació d’un prototipus amb .NET Core”,
primerament, per validar la connexió entre ASP.NET Core i MongoDB s’ha creat una API
amb els mateixos requisits que l’aplicació web final. La Figura 55 s’hi mostren les
mesures procedents de MongoDB amb els seus 4 camps : _id, tipus, nivell i timestamp.
Figura 55. Validació de les actualitzacions de les mesures en l’API
Un cop s’ha validat la recuperació de les mesures per part de l’API creada, s’ha fet el
mateix amb l’aplicació web final. La Figura 56 mostra una part de la pantalla referent a
tota la informació del sensor de CO2 simulat que són les mesures procedents de
MongoDB (igual que en la connexió amb NECADA, Figura 52).
Figura 56. Validació de les actualitzacions de les mesures en l’aplicació web d’ASP.NET Core
Modelatge de l’emergència climàtica amb NECADA
89
11. Conclusions Un cop finalitzat el projecte és hora d’extreure les conclusions més importants i veure si
s’han aconseguit els objectius plantejats inicialment.
En primer lloc, s’ha arribat a la conclusió que el protocol OPC-UA és molt més complet i
flexible del que es pensava inicialment. La part de la creació del cient i del servidor
simulats s’ha complert satisfactòriament.
S’ha pogut comprovar utilitzant l’SDK Opc.UaFx.Advanced i el simulador UaExpert que
el protocol OPC-UA es pot integrar amb moltes tecnologies diferents (MongoDB,
ASP.NET Core, etc.) i és un avantatge molt important de cara a futurs projectes amb
altres tecnologies.
En segon lloc, la integració d’aquesta connexió client-servidor OPC-UA amb una base
de dades no relacional com és MongoDB també s’ha complert amb èxit. El fet de
connectar aquestes dues tecnologies fa que sigui molt flexible utilitzar-les en altres
àmbits com, per exemple, altres sistemes operatius o també en altres camps com la salut.
Respecte a l’aplicació web NECADA Sensors cal dir que és bàsica a primera vista, però
és molt eficaç perquè s’ha aconseguit integrar-la amb MongoDB i connectar-la amb el
sistema de NECADA. Per tant, s’han complert les especificacions establertes inicialment.
Ja pensant en un treball futur, en comptes d’utilitzar sensors simulats, seria interessant
que, a llarg termini, aquesta aplicació pogués treballar amb sensors reals de CO2 o de
qualsevol altra condició climàtica per poder esprémer al màxim la integració d’OPC-UA
amb .NET Core.
Si es treballés amb sensors reals, suposaria un impacte molt positiu per a la societat i
augmentaria la sostenibilitat de molts edificis. És necessari en l’època en què vivim
intentar ser el màxim sostenible en tots els àmbits de la vida quotidiana.
Finalment, es pot concloure amb satisfacció que la realització d’aquest projecte ha estat
acabada amb èxit i els objectius marcats al principi s’han complert.
Modelatge de l’emergència climàtica amb NECADA
90
12. Valoració personal Des del punt de vista personal, aquest projecte m’ha influenciat d’una forma important en
molts aspectes que a continuació s’explicaran.
Primerament, m’ha ajudat i servit molt per entendre millor nous llenguatges de
programació i noves tecnologies que mai havia treballat. D’aquesta manera,
l’aprenentatge adquirit es pot aplicar perfectament en el món laboral.
En el desenvolupament web hi intervenen desenes de tecnologies. Per aquest motiu, el
fet d’haver après unes quantes d’elles des de zero com són el protocol OPC-UA, el
llenguatge C#, la base de dades de MongoDB i el framework ASP.NET Core, m’ha fet
donar compte de la importància de tenir una bona arquitectura darrere de qualsevol
aplicació web.
També he vist com la programació web pot arribar a tenir moltes aplicacions en molts
terrenys laborals diferents com són l’edificació (amb NECADA), la indústria (amb el
protocol OPC-UA), la salut (amb els sensors d’OPC-UA i la tecnologia .NET Core), etc.
Un concepte molt important del projecte és la sostenibilitat. Haver pogut descobrir
NECADA i les seves investigacions en l’àmbit de l’edificació, ha significat aprendre a
valorar molt més els factors nocius que provoca l’ésser humà (per exemple, contaminació
atmosfèrica) a la sostenibilitat del planeta.
Per acabar, estic molt satisfet amb el resultat final del projecte i espero que aquest sigui
l’inici de, a partir d’utilitzar les tecnologies descrites anteriorment, la base per fer més
sostenibles futurs edificis.
Modelatge de l’emergència climàtica amb NECADA
91
13. Bibliografia
[1] P. Fonseca i Casas and A. Fonseca i Casas, “NECADA. Optimization software for
sustainable architecture,” in Building Simulation Conference, 2015, no. i.
[2] P. Fonseca i Casas, A. Fonseca i Casas, N. Garrido-Soriano, and J. Casanovas,
“Formal simulation model to optimize building sustainability,” Adv. Eng. Softw., vol. 69,
pp. 62–74, Mar. 2014.
[3] R. ITU-T, «Specification and description language (SDL)», Int. Telecommun. Union,
vol. 100, 2000, [En línia]. [Data de consulta: 1 Agost 2020]. Disponible a:
https://www.itu.int/ITU-T/studygroups/com10/languages/Z.100_1199.pdf
[4] Mario Viciosa, «El hielo de Groenlandia, en el punto de no retorno», 2020. [En línia].
[Data de consulta: 3 Setembre 2020]. Disponible a : https://www.newtral.es/hielo-
groenlandia-punto-no-retorno/20200820/
[5] Z. Ceballos de Mariño, «La gestión de proyectos con la metodología SCRUM», 2019.
[En línia]. [Data de consulta: 5 Agost 2020]. Disponible a :
https://zoraidaceballosdemariño.info/scrum/zoraida-ceballos-de-marino-la-gestion-de-
proyectos-con-la-metodologia-scrum/
[6] D. d’Organització d’Empreses, FIB, «Módulo 2.3. Gestión del tiempo», 2020. [Data de
consulta: 30 Setembre 2020].
[7] TeamGantt, «TeamGantt: Online Gantt Chart Software & Project Planning Tool»,
2020. [En línia]. [Data de consulta: 1 Octubre 2020]. Disponible a:
https://www.teamgantt.com/
[8] Facultat d’Informàtica de Barcelona, «Lliurament 3: Pressupost i sostenibilitat:
Feedback a priori (consells de realització)», 2020. [Data de consulta: 6 Octubre 2020].
[9] D. d’Organització d’Empreses, FIB, «Módulo 2.4.1. Costos i sostenibilitat del projecte
informàtic», 2020. [Data de consulta: 7 Octubre 2020].
[10] D. d’Organització d’Empreses, FIB, «Módulo 2.4. Gestión económica», 2020. [Data
de consulta: 7 Octubre 2020].
Modelatge de l’emergència climàtica amb NECADA
92
[11] D. d’Organització d’Empreses, FIB, « L'Informe de sostenibilitat del TFG», 2020. [En
línia]. [Data de consulta: 15 Octubre 2020].
[12] OPC Foundation, «What is OPC-UA?», 2014. [En línia]. [Data de consulta: 2
Novembre 2020]. Disponible a : https://opcfoundation.org/faq/what-is-opc-ua
[13] Traeger Industry Components, «OPC UA SDK for .NET», 2020. [En línia]. [Data de
consulta: 2 Novembre 2020]. Disponible a : https://docs.traeger.de/en/software/sdk/opc-
ua/net/intro
[14] Unified Automation, «UaExpert Documentation», 2019. [En línia]. [Data de consulta:
3 Novembre 2020]. Disponible a : http://documentation.unified-
automation.com/uaexpert/1.4.0/html/index.html
[15] Microsoft .NET, «What is ASP.NET Core?», 2020. [En línia]. [Data de consulta: 5
Novembre 2020]. Disponible a : https://dotnet.microsoft.com/apps/aspnet
[16] Asma Khalid, «ASP.NET Core 2 - Architecture And Design Pattern Ideology», 2020.
[En línia]. [Data de consulta: 5 Novembre 2020]. Disponible a : https://www.c-
sharpcorner.com/article/asp-net-core-2-architecture-design-pattern-ideology
[17] James Newton, «Destinatarios multiplataforma», 2019. [En línia]. [Data de consulta:
5 Novembre 2020]. Disponible a : https://docs.microsoft.com/es-es/dotnet/standard/library-
guidance/cross-platform-targeting
[18] Steve Smith, «Información general de ASP.NET Core MVC», 2020. [En línia]. [Data
de consulta: 5 Novembre 2020]. Disponible a : https://docs.microsoft.com/es-
es/aspnet/core/mvc/overview?view=aspnetcore-3.1
[19] MongoDB, Inc., «¿Qué es MongoDB?», 2020. [En línia]. [Data de consulta: 17
Novembre 2020]. Disponible a : https://www.mongodb.com/es/what-is-mongodb
[20] Ramon Carrasco, «Conceptos generales de MongoDB», 2020. [En línia]. [Data de
consulta: 17 Novembre 2020]. Disponible a :
https://www.ramoncarrasco.es/es/content/es/kb/128/conceptos-generales-de-mongodb
[21] MongoDB, Inc., «MongoDB Compass», 2020. [En línia]. [Data de consulta: 17
Novembre 2020]. Disponible a : https://www.mongodb.com/es/products/compass
Modelatge de l’emergència climàtica amb NECADA
93
[22] Miguel Angel Álvarez, «¿Qué es HTML?», 2001. [En línia]. [Data de consulta: 20
Novembre 2020]. Disponible a : https://desarrolloweb.com/articulos/que-es-html.html
[23] Jamie Cool, «Introducción a Azure DevOps», 2018. [En línia]. [Data de consulta: 23
Novembre 2020]. Disponible a : https://azure.microsoft.com/es-es/blog/introducing-
azure-devops
[24] Muutech Monitoring Solutions S.L, «Comparativa entre MQTT y OPC-UA», 2019.
[En línia]. [Data de consulta: 7 Novembre 2020]. Disponible a :
https://www.muutech.com/comparativa-entre-mqtt-y-opc-ua
[25] Berta Canet, «Comunicaciones y protocolos en la automatización industrial», 2020.
[En línia]. [Data de consulta: 7 Novembre 2020]. Disponible a :
https://www.industrialshields.com/es_ES/blog/arduino-industrial-1/post/comunicaciones-
y-protocolos-en-la-automatizacion-industrial-231
[26] FabianB, « Características y usos del protocolo OPC-UA en SCADA», 2018. [En
línia]. [Data de consulta: 7 Novembre 2020]. Disponible a :
https://vestertraining.com/caracteristicas-opc-ua-scada
[27] Universitat Politècnica de Catalunya, «Informe SIRENA 2019: Avaluació del consum
d’energia i aigua de la UPC.», 2019. [En línia]. [Data de consulta: 7 Novembre 2020].
Disponible a : https://www.upc.edu/energia2020/ca/noticies/informe-sirena-2019-
avaluacio-del-consum-d2019energia-i-aigua-de-la-upc
[28] Donnie MacColl, «¿Qué es RGPD (o GDPR)?», 2019. [En línia]. [Data de consulta:
9 Desembre 2020]. Disponible a : https://www.helpsystems.com/es/recursos/articulo/que-es-
gdpr
[29] Protección de Datos Marca Blanca, «LSSICE», 2020. [En línia]. [Data de consulta: 9
Desembre 2020]. Disponible a : https://protecciondedatosmarcablanca.es/lssice
[30] INCIBE-CERT, «Estandarización y seguridad en el protocolo OPC-UA», 2018. [En
línia]. [Data de consulta: 4 Gener 2020]. Disponible a : https://www.incibe-
cert.es/blog/estandarizacion-y-seguridad-el-protocolo-opc-ua
Modelatge de l’emergència climàtica amb NECADA
94
Annex
Annex A : Codi de l’aplicació web NECADA Sensors
Aquest annex és per mostrar, a partir dels fitxers de Visual Studio, tot el codi restant
referent a la programació de l’aplicació web creada amb el framework ASP.NET Core
que no s’ha visualitzat dins la memòria final.
Figura 57. Codi del fitxer appsettings.json
Figura 58. Codi del fitxer MongoDBSettings.cs
Modelatge de l’emergència climàtica amb NECADA
95
Figura 59. Codi del fitxer Mesura.cs
Figura 60. Codi del fitxer MesuraService.cs
Modelatge de l’emergència climàtica amb NECADA
96
Figura 61. Codi del fitxer MesuraController.cs
Modelatge de l’emergència climàtica amb NECADA
97
Figura 62. Codi del fitxer SensorCO2.cshtml
Modelatge de l’emergència climàtica amb NECADA
98
Annex B : OPC (Object Linking and Embedding for Process Control)
En aquest projecte s’ha tractat a fons el protocol de comunicació OPC-UA (Open Platform
Communications - Unified Architecture) però també és interessant saber quin és el seu
origen. Per això, en aquest Annex B, s’explicarà amb detall el protocol OPC (Object
Linking and Embedding for Process Control) que és com es coneixia anteriorment el
protocol OPC-UA.
El protocol OPC [30] va sorgir de la necessitat de crear una interfície comuna focalitzada
en la comunicació de processos industrials. OPC permetia d'una forma abstracta la
comunicació de diferents elements de la xarxa de processos i utilitzava un plantejament
client-servidor per a la comunicació.
Figura 63. Estat inicial sense OPC
Per una banda, un servidor OPC és el que s’encarregava de l'encapsulament de la
informació i de la disponibilitat d'aquesta a través de la seva interfície. Per altra banda,
un client OPC és el que es connectava al servidor OPC i accedia a la informació
disponible.
Modelatge de l’emergència climàtica amb NECADA
15 https://docs.microsoft.com/en-us/windows/win32/com/component-object-model--com--portal 99
En l’OPC Classic, les interfícies es basaven en la tecnologia COM/DCOM15 de Microsoft
(Component Object Model / Distributed Component Object Model), mentre que en l'última
versió d’OPC-UA s'utilitza un protocol TCP binari d'alt rendiment (OPC-TCP) i un segon
basat en serveis web (HTTP).
Figura 64. Estat inicial amb OPC
Evolució del protocol OPC La primera versió del protocol OPC, anomenada “OPC Classic”, es va adaptar a les
necessitats del moment i plantejava 3 especificacions variades:
OPC-DA (Data Access) : S’utilitza per a l'accés a dades actuals dels processos.
OPC-A&E (Alarms and Events) : S’utilitza per a informació d'esdeveniments i alarmes.
OPC-HDA (Historical Data Access) : S’utilitza per a l'accés a dades històriques ja
emmagatzemades.
La interfície OPC-DA és la més important d’OPC i la utilitzada en la majoria dels
dispositius que implementen aquest protocol. Les interfícies OPC-A&E i OPC-HDA són
menys rellevants i s'utilitzen com un complement d’OPC-DA.
Modelatge de l’emergència climàtica amb NECADA
100
Després de la primera versió d’OPC, va néixer OPC XML-DA com un primer intent d’OPC
de crear una especificació OPC independent de la plataforma. L’objectiu era reemplaçar
la tecnologia COM/DCOM per HTTP/SOA (Service Oriented Architecture), mantenint la
funcionalitat d’OPC-DA.
El problema que va tenir OPC XML-DA va ser el seu baix rendiment i el seu alt consum
de recursos. És per aquests motius que crea el protocol OPC-UA, és a dir, per la
necessitat real d'una eina independent de la plataforma, però mantenint les
característiques i el rendiment de l’OPC Classic.
L'aparició d’OPC-UA ha suposat un canvi molt gran en les infraestructures OPC, ja que
Windows ha deixat de ser un requisit obligatori precisament degut a aquesta
independència de la plataforma.
En crear-se OPC-UA, el seu principal objectiu va ser el d’unificar tota l'arquitectura OPC
en una infraestructura independent de la plataforma, mantenint tota la funcionalitat OPC,
evitant així la dependència dels sistemes de Microsoft.
Respecte al model de dades, OPC-UA defineix les regles i blocs necessaris per a l'accés
a l'espai de direccions. Els serveis en OPC-UA es defineixen de forma abstracta i
s'utilitzen els mecanismes de transport per a intercanviar dades entre el client i el
servidor.
Modelatge de l’emergència climàtica amb NECADA
16 https://thingsboard.io/docs/getting-started-guides/what-is-thingsboard 101
Annex C : ThingsBoard
Dins el projecte, en el moment d’intentar mostrar en l’aplicació web d’ASP.NET Core les
mesures rebudes del sensor de CO2 simulat inserides en la base de dades de MongoDB,
s’havia pensat mostrar-les de forma gràfica mitjançant una plataforma relativament nova
però molt potent anomenada ThingsBoard.
Per falta de temps i, sobretot, per l’alta complexitat que existia poder fer la integració
d’aquesta plataforma amb OPC-UA, no s’ha pogut aconseguir. En aquest Annex C,
s’explica en detall en què consisteix ThingsBoard i les seves principals característiques.
ThingsBoard16 és una plataforma de codi obert que permet controlar i monitoritzar
diferents dispositius IoT (Internet of Things). L’objectiu és proporcionar una
infraestructura del costat del servidor per aplicacions IoT.
Aquesta plataforma també permet desenvolupar i gestionar qualsevol projecte IoT. Es
pot allotjar en el núvol o localment en un portàtil i es pot desplegar en qualsevol sistema
operatiu (Windows, Linux o Mac OS).
Les funcions més importants de ThingsBoard són recopilar i visualitzar dades de
qualsevol dispositiu mitjançant dashboards (taulers dinàmics), analitzar la telemetria
entrant i activar les alarmes amb esdeveniments, controlar qualsevol dispositiu
mitjançant crides de procediment remot (RPC o Remote Procedure Calls) i construir
fluxos de treball basats en un esdeveniment de cicle de vida del dispositiu.
L’arquitectura de ThingsBoard ha estat dissenyada per ser escalable, robusta i eficient,
tolerant a fallades, personalitzable i duradora. Una part important són els protocols de
comunicació. ThingsBoard dóna suport a HTTP i a MQTT (explicat anteriorment).
Totes les dades de ThingsBoard s’emmagatzemen en una base de dades no relacional
anomenada Cassandra (és semblant a MongoDB, però té bastants diferències).
Cassandra ofereix un gran emmagatzematge que fa que sigui molt potent a l’hora de
guardar molta informació a la vegada.
Respecte al protocol OPC-UA i la relació que té amb ThingsBoard cal mencionar alguns
aspectes. La integració d’aquest protocol amb aquesta plataforma permet transmetre
dades d’un servidor OPC-UA a ThingsBoard.
Modelatge de l’emergència climàtica amb NECADA
102
Seguidament, la plataforma converteix les dades útils del dispositiu en qüestió
(sensors...) en un format gràfic en temps real mitjançant dashboards. D’aquesta manera,
l’usuari pot observar els canvis que es produeixen a cada instant i obtenir conclusions
més precises sobre tota la informació rebuda. La Figura 65 mostra tots aquests passos.
Figura 65. Arquitectura de la integració d’OPC-UA amb ThingsBoard. Font: https://thingsboard.io/docs/user-guide/integrations/opc-ua/
ThingsBoard té desenes de tecnologies i elements que hi intervenen, però en aquest
annex només s’ha explicat les característiques bàsiques d’aquesta plataforma per
entendre millor el seu funcionament bàsic. La Figura 66 mostra com es veurien les dades
d’un sensor d’humitat i d’un de temperatura dins aquesta plataforma.
Figura 66. Exemple de la visualització de les dades amb ThingsBoard. Font: https://industruino.com/blog/our-news-1/post/thingsboard-demo-for-industruino-37
Modelatge de l’emergència climàtica amb NECADA
17 https://docs.microsoft.com/es-es/aspnet/signalr/overview/getting-started/introduction-to-signalr 103
Annex D : SignalR
Una forma de simular en temps real les notificacions rebudes des de qualsevol pàgina
web és utilitzant una llibreria molt eficaç anomenada SignalR. Aquesta llibreria té una
relació molt directa en una part d’aquest projecte. Concretament, la part referent a la
connexió de MongoDB amb l’aplicació .NET Core.
Igual que amb la plataforma ThingsBoard, no s’hi ha pogut treballar per falta de temps i
perquè la complexitat de l’aplicació s’elevaria bastant. Com que SignalR és un element
important en el món de les aplicacions web .NET, és interessant conèixer en què
consisteix i quines són les seves principals funcionalitats.
SignalR17 és una llibreria de codi obert i gratuïta bastant moderna que s’utilitza per
implementar funcionalitats en temps real de manera asíncrona en qualsevol aplicació
web .NET (web, mòbil...). L’any 2013 es va crear la primera versió de SignalR (1.0) que
ja mostrava notificacions en temps real.
Més endavant, es van seguir implementant altres versions i algunes millores addicionals,
però sempre amb .NET Framework (versió antiga de .NET Core). L’any 2018 apareix una
versió diferent anomenada SignalR Core on s’implementen moltes millores a la llibreria
original de SignalR.
Actualment, SignalR és una llibreria NuGet (mecanisme compatible amb Microsoft .NET
per compartir tota mena de codi) i això facilitat la integració amb qualsevol aplicació feta
amb ASP.NET Core.
SignalR és ideal en notificacions de qualsevol aplicació web (cas més comú), en taulers
de control (Trello), en aplicacions col·laboratives (Google Docs) o en aplicacions de
monitorització (Uber).
El que proporciona SignalR és una API molt simple per crear Remote Procedure Calls
(RPC) o crides de procediment remot des d’un servidor a un client que alhora aquestes
criden a funcions de Javascript en altres plataformes de tipus client des del codi .NET del
costat del servidor.
Modelatge de l’emergència climàtica amb NECADA
104
Aquestes serien les funcionalitats més bàsiques existents en SignalR. La Figura 67
mostra un exemple d’un xat funcional en una aplicació web fet amb ASP.NET Core que
té agregada una llibreria SignalR. Es pot comprovar que, en el moment en què hi ha una
notificació o un canvi d’estat en qualsevol dels dos navegadors, automàticament i en
temps real aquest canvi es mostra al mateix instant en tots dos.
Figura 67. Exemple d’un xat funcional en temps real amb SignalR. Font: https://docs.microsoft.com/es-es/aspnet/core/tutorials/signalr?view=aspnetcore-3.1&tabs=visual-studio