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


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.


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.


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.


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.


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


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


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


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


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


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


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


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.


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


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.

https://opcfoundation.org/faq/what-is-opc-ua


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.


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.

https://www.muyinteresante.es/naturaleza/articulo/incendios-en-australia-por-que-causa


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

https://ovacen.com/modelo-de-certificacion-leed-modelos-sostenibles/


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.


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.


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.


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.


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.


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”.


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.


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ó.


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


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.


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).


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


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


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


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.


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


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


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.


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.


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.


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”.

https://sdlps.com/projects/documentation/3


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


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.


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ó.

https://opcfoundation.org/


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).

https://opcfoundation.org/about/opc-technologies/opc-ua/


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.

https://docs.traeger.de/en/software/sdk/opc-ua/net/intro


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

https://integrationobjects.com/sioth-opc/sioth-opc-unified-architecture/opc-ua-client/


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.

https://www.incibe-cert.es/blog/estandarizacion-y-seguridad-el-protocolo-opc-ua


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

https://www.iottechexpo.com/europe/wp-content/uploads/2018/06/16.30-Christopher-Anhalt.pdf


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


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].


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.


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.


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


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.


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.


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


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


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


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).


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.


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.


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.


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.


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.


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.


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


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


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.


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.


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”


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


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


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”.

https://hardzone.es/reportajes/que-es/tiempo-epoch-pc/


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.


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.


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”).


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).


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).

https://localhost:5001/api/mesures


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.

https://www.smarterasp.net/


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).


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.


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.


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


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.


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).

http://terrassa40-001-site13.btempurl.com/


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.


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.


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


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

http://terrassa40-001-site13.btempurl.com/


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).


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


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


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.


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


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.


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.


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].

https://www.itu.int/ITU-T/studygroups/com10/languages/Z.100_1199.pdf

https://www.newtral.es/hielo-groenlandia-punto-no-retorno/20200820/

https://www.newtral.es/hielo-groenlandia-punto-no-retorno/20200820/

https://zoraidaceballosdemariño.info/scrum/zoraida-ceballos-de-marino-la-gestion-de-proyectos-con-la-metodologia-scrum/

https://zoraidaceballosdemariño.info/scrum/zoraida-ceballos-de-marino-la-gestion-de-proyectos-con-la-metodologia-scrum/

https://www.teamgantt.com/


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

https://opcfoundation.org/faq/what-is-opc-ua



http://documentation.unified-automation.com/uaexpert/1.4.0/html/index.html

http://documentation.unified-automation.com/uaexpert/1.4.0/html/index.html

https://dotnet.microsoft.com/apps/aspnet

https://www.c-sharpcorner.com/article/asp-net-core-2-architecture-design-pattern-ideology

https://www.c-sharpcorner.com/article/asp-net-core-2-architecture-design-pattern-ideology

https://docs.microsoft.com/es-es/dotnet/standard/library-guidance/cross-platform-targeting

https://docs.microsoft.com/es-es/dotnet/standard/library-guidance/cross-platform-targeting

https://docs.microsoft.com/es-es/aspnet/core/mvc/overview?view=aspnetcore-3.1

https://docs.microsoft.com/es-es/aspnet/core/mvc/overview?view=aspnetcore-3.1

https://www.mongodb.com/es/what-is-mongodb

https://www.ramoncarrasco.es/es/content/es/kb/128/conceptos-generales-de-mongodb

https://www.mongodb.com/es/products/compass


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

https://desarrolloweb.com/articulos/que-es-html.html

https://azure.microsoft.com/es-es/blog/introducing-azure-devops

https://azure.microsoft.com/es-es/blog/introducing-azure-devops

https://www.muutech.com/comparativa-entre-mqtt-y-opc-ua

https://www.industrialshields.com/es_ES/blog/arduino-industrial-1/post/comunicaciones-y-protocolos-en-la-automatizacion-industrial-231

https://www.industrialshields.com/es_ES/blog/arduino-industrial-1/post/comunicaciones-y-protocolos-en-la-automatizacion-industrial-231

https://vestertraining.com/caracteristicas-opc-ua-scada

https://www.upc.edu/energia2020/ca/noticies/informe-sirena-2019-avaluacio-del-consum-d2019energia-i-aigua-de-la-upc

https://www.upc.edu/energia2020/ca/noticies/informe-sirena-2019-avaluacio-del-consum-d2019energia-i-aigua-de-la-upc

https://www.helpsystems.com/es/recursos/articulo/que-es-gdpr

https://www.helpsystems.com/es/recursos/articulo/que-es-gdpr

https://protecciondedatosmarcablanca.es/lssice




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


95

Figura 59. Codi del fitxer Mesura.cs

Figura 60. Codi del fitxer MesuraService.cs


96

Figura 61. Codi del fitxer MesuraController.cs


97

Figura 62. Codi del fitxer SensorCO2.cshtml


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.


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.

https://docs.microsoft.com/en-us/windows/win32/com/component-object-model--com--portal


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.


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.

https://thingsboard.io/docs/getting-started-guides/what-is-thingsboard


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


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.

https://docs.microsoft.com/es-es/aspnet/signalr/overview/getting-started/introduction-to-signalr


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

climàtica amb NECADA - upcommons.upc.edu

Documents

Transcript of climàtica amb NECADA - upcommons.upc.edu