UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA. GRADO EN INGENIERÍA INFORMÁTICA Ingeniería de Computadores TRABAJO FIN DE GRADO

(1)

GRADO EN INGENIERÍA INFORMÁTICA

Ingeniería de Computadores

TRABAJO FIN DE GRADO

Diseño de un sistema de control de riego automatizado aplicado a la viticultura

Cristina Bolaños Peño

junio, 2019

(2)

(3)

Tecnologías y Sistemas de la Información

Ingeniería de Computadores

TRABAJO FIN DE GRADO

Diseño de un sistema de control de riego automatizado aplicado a la viticultura

Autor(a): Cristina Bolaños Peño

Director(a): Félix Jesús Villanueva Molina

junio, 2019

(4)

Diseño de un sistema de control de riego automatizado

Este documento se distribuye con licencia Creative Commons Atribución Compartir Igual 4.0. El texto completo de la licencia puede obtenerse enhttps://creativecommons.org/licenses/by- sa/4.0/.

La copia y distribución de esta obra está permitida en todo el mundo, sin regalías y por cualquier medio, siempre que esta nota sea preservada. Se concede permiso para copiar y distribuir traducciones de este libro desde el español original a otro idioma, siempre que la traducción sea aprobada por el autor del libro y tanto el aviso de copyright como esta nota de permiso, sean preservados en todas las copias.

(5)

Presidente:

Vocal:

Secretario:

Fecha de defensa:

Calificación:

Presidente Vocal Secretario

Fdo.: Fdo.: Fdo.:

(6)

(7)

(8)

(9)

actualidad, como lo son el calentamiento global, la contaminación o la deforestación. A esto hay que sumarle un mal uso de los recursos hídricos disponibles a nuestro alcance, sobretodo en el caso de grandes áreas de explotación. El clima mediterráneo del que presumía Castilla-La Mancha está al borde de la extinción y, por ello, la forma de cultivo debe volverse más eficiente.

Con este proyecto, se propone una nueva forma inteligente de gestionar el riego de plantaciones de medio o gran tamaño. De esta forma, se ha diseñado un sistema de sensores que colaboran con los servicios en la nube para proporcionar al agricultor un asistente en el empleo de agua.

ix

(10)

(11)

pollution or deforestation. Furthermore, there is a misuse of available water resources, mostly on large production areas. The Mediterranean climate of which Castilla-La Mancha boasted is on the verge of extinction and, therefore, agriculture must become more efficient.

Along this project, we propose a new intelligent way of managing the irrigation of medium or large sized areas. A system of sensors has been designed which collaborates with cloud services to provide the farmer an assistant in the use of water.

xi

(12)

(13)

Echando la mirada atrás, no puedo más que ver todo lo que he avanzado en estos cuatro años, tanto personal como profesionalmente. Podría decirse que no soy la misma persona que entró por las puertas de la facultad comparándola con aquella que ha decidido quedarse dentro de ella un poco más, pues parece que no he tenido suficiente.

Principalmente, y antes que mencionar a nadie más, he de atribuir al menos la mitad de la ilusión y energía para afrontar estos años a mi familia. Gracias aLola, mi madre, por la comprensión, el apoyo incondicional e intentar comprender mis proyectos aunque sólo fuera por la ilusión con la que se lo contaba. Gracias aJesús, mi padre, por su fortaleza contagiosa, tanto física como de espíritu, y por su constante preocupación, aunque a veces no sea justificada. Gracias aDavid, mi hermano, por el compañerismo y la confianza que ha crecido entre nosotros con el paso de los años. Gracias aJusta, Justi y Carmen que, conjunto con mi madre, conforman el grupo de mujeres fuertes y con carácter en las que me inspiro todos los días.

Comoagradecimientos exprés, quisiera que todas las personas que me han acompañado a lo largo de todos estos años y que se han quedado se den por aludidas si alguna vez leyesen estás líneas, pues sería imposible mencionarlas a todas. Gracias por el tiempo compartido, por las risas, por los momentos para apaciguar los nervios y por los "quedémonos a una más".

Por último, pero no menos importante, quisiera agradecer a mis compañeros del laboratorio ARCO el recibimiento, los constantespiques, las conversaciones del tipo que alimenta mi curiosidad, cada vez más, por el mundo que abarca la informática. Podría decirse queCristian, Jose Antonio y Jose Mota tienen el cielo ganado por tratar conmigo todas las mañanas desde que empecé este proyecto, aunque también podría decirse lo contrario, pues juntos son como un terremoto.

Cristina Bolaños Peño

xiii

(14)

(15)

Índice de figuras xvii

Índice de tablas xix

Índice de listados xxi

1. Introducción 1

2. Objetivo 3

2.1. Objetivo general . . . 3

2.2. Objetivos parciales . . . 3

2.2.1. Análisis de las arquitecturas y tecnologías de comunicación a utilizar . . . . 3

2.2.2. Selección de sensores y módulos de comunicaciones de IoT . . . 3

2.2.3. Implementación de software de recolección de datos de los sensores . . . . 4

2.2.4. Implementación de software de comunicación entre los nodos y la pasarela 4 2.2.5. Implementación de software de comunicación entre el servicio en la nube y la pasarela . . . 4

2.2.6. Implementación de software de monitorización de los datos recolectados . . 4

3. Metodología de trabajo 5 3.1. Elección y breve descripción de la metodología . . . 5

3.2. Gestión del proyecto . . . 5

3.2.1. Fases . . . 5

3.2.2. Aplicación . . . 6

3.3. Marco tecnológico . . . 6

3.3.1. Herramientas hardware . . . 6

3.3.2. Herramientas para la gestión de proyectos . . . 7

3.3.3. Herramientas, lenguajes y tecnologías para el modelado de software . . . . 7

3.3.4. Herramientas, lenguajes y tecnologías para el desarrollo de software . . . . 7

3.3.5. Herramientas para la elaboración de la documentación . . . 8 xv

(16)

xvi ÍNDICE GENERAL

4. Resultados 9

4.1. Fase de Inicio. . . 9

4.1.1. Captura de Requisitos . . . 9

4.1.2. Planificación de Iteraciones . . . 10

4.2. Fase de Elaboración . . . 15

4.2.1. Iteración 1 . . . 15

4.2.2. Iteración 2 . . . 18

4.3. Fase de Construcción . . . 21

4.3.1. Iteración 3 . . . 21

4.3.2. Iteración 4 . . . 27

4.3.3. Iteración 5 . . . 30

4.4. Fase de Transición . . . 45

4.4.1. Iteración 6 . . . 45

4.4.2. Iteración 7 . . . 53

4.4.3. Iteración 8 . . . 57

5. Conclusiones 59 5.1. Tiempo empleado y coste . . . 59

5.2. Objetivos alcanzados . . . 61

5.2.1. Análisis de las arquitecturas y tecnologías de comunicación a utilizar . . . . 61

5.2.2. Selección de sensores y módulos de comunicaciones de IoT . . . 61

5.2.3. Implementación de software de recolección de datos de los sensores . . . . 62

5.2.4. Implementación de software de comunicación entre los nodos y la pasarela 62 5.2.5. Implementación de software de comunicación entre el servicio en la nube y la pasarela . . . 62

5.2.6. Implementación de software de monitorización de los datos recolectados . . 62

5.3. Competencias reforzadas . . . 62

5.4. Propuestas de trabajo futuro . . . 63

A. Repositorio del proyecto 65

Bibliografía 67

(17)

4.1. Modelo de Casos de Uso Inicial. . . 10

4.2. Arquitectura inicial . . . 16

4.3. Arquitectura final . . . 18

4.4. Diagrama de diseño . . . 19

4.5. Autenticación en Grafana . . . 22

4.6. Registro de usuarios en Grafana - Invitación del administrador . . . 23

4.7. Registro de usuarios en Grafana - Aceptación de la invitación . . . 24

4.8. Arquitectura de Docker . . . 25

4.9. MySQL Server - Primera autenticación . . . 28

4.10. Arquitectura LoRaWAN . . . 31

4.11. Capas LoRa. . . 31

4.12. Formatos de mensajes de configuración . . . 32

4.13. Formatos de mensajes de envío de datos. . . 32

4.14. Diagrama de secuencia de un nodo con una pasarela. . . 33

4.15. Diagrama de secuencia de dos nodos - Normal . . . 34

4.16. Diagrama de secuencia de dos nodos - Alternativo . . . 34

4.17. Dispositivos empleados para cumplimentar las acciones de nodo y pasarela . . . 35

4.18. Conexionado de los nodos a los sensores . . . 36

4.19. SecciónInstances de EC2 . . . 46

4.20. Lanzamiento de instancias . . . 47

4.21. Selección de la imagen de Ubuntu Server . . . 47

4.22. Selección del tipo de instancia . . . 47

4.23. Creación del nuevo grupo de seguridad y su asignación a la instancia . . . 48

4.24. Configuración del acceso a la instancia por medio de un par de claves . . . 48

4.25. Detalles de la instancia recién creada . . . 49

4.26. Resumen de la última versión del repositorio, ahora almacenado también en la instancia 49 4.27. Resumen de los contenedores ejecutándose en la instancia de EC2 . . . 50

4.28. Conexión con el nodo a través de Atom . . . 50

4.29. Conexión con la pasarela a través de Atom . . . 51

4.30. Colocación de los sensores en una planta común . . . 52 xvii

(18)

xviii ÍNDICE DE FIGURAS

4.31. Comprobación de almacenamiento correcto de datos . . . 55

4.32. Gráfica de la humedad del área . . . 56

4.33. Gráfica de la temperatura del área . . . 56

4.34. Gráfica de la humedad del suelo del área . . . 56

(19)

3.1. Planificación de iteraciones . . . 6

4.1. Trazabilidad de requisitos . . . 10

4.2. Iteración preliminar . . . 11

4.3. Iteración 1 . . . 11

4.4. Iteración 2 . . . 11

4.5. Iteración 3 . . . 11

4.6. Iteración 4 . . . 11

4.7. Iteración 5 . . . 11

4.8. Iteración 6 . . . 12

4.9. Iteración 7 . . . 12

4.10. Iteración 8 . . . 12

4.11. Asignaciones de recursos a las diferentes tareas . . . 14

4.12. Decisión para el sistema de monitorización . . . 17

5.1. Asignaciones de recursos a las diferentes tareas . . . 60

5.2. Costes de recursos de trabajo. Fuentes: [20] . . . 61

5.3. Costes totales . . . 61

5.4. Justificación de las competencias abordadas en el proyecto. . . 63

xix

(20)

(21)

4.1. Base de Datos, código de la tablausuario . . . 19

4.2. Base de Datos, código de la tablaterreno. . . 20

4.3. Base de Datos, código de la tablaunidad . . . 20

4.4. Base de Datos, código de la tablasensor . . . 20

4.5. Base de Datos, código de la tablaárea . . . 21

4.6. Base de Datos, código de la tablaentorno . . . 21

4.7. Dockerfile de Grafana . . . 26

4.8. Makefile de Grafana . . . 27

4.9. MySQL Server - Creación de usuarios . . . 28

4.10. Dockerfile - MySQL . . . 29

4.11. Makefile - MySQL . . . 29

4.12. Código del Nodo, métodosetup. . . 37

4.13. Código del Nodo, clases de sensores . . . 38

4.14. Código del Nodo, lectura de sensores . . . 39

4.15. Código del Nodo, envío . . . 40

4.16. Código de la Pasarela, recepción . . . 41

4.17. Código de la Pasarela, obtención de IP . . . 42

4.18. Código de la Pasarela, envío . . . 42

4.19. Código delBack-end, recepción. . . 43

4.20. Código delBack-end, conexión a la base de datos . . . 44

4.21. Dockerfile delBack-end . . . 44

4.22. Makefile delBack-end . . . 45

4.23. Log del Nodo . . . 53

4.24. Log del Pasarela . . . 54

xxi

(22)

(23)

INTRODUCCIÓN

Los desastres climáticos conforman una realidad sumamente atroz, la cual está presente en los medios de comunicación a día de hoy. Sin ir más lejos, en este 2019 se han organizando numerosas manifestaciones en todo el globo en forma de protesta contra la pasividad ante el cambio climático y concienciar a la población antes de llegar al 2030, el año de no retorno [7].

Si no es uno de los más importantes, el calentamiento global acarreará una de las más catastróficas consecuencias, aunque hay muchas más: la falta de agua potable. Ésta marcará la supervivencia del ser humano, pues no sólo escaseará en el consumo directo, si no en la producción de bienes agrícolas y ganaderos. Acercándonos al campo de la agricultura, sólo en Castilla-La Mancha se emplearon 1.655.033 miles de metros cúbicos de agua en 2016 [21].

Las soluciones a la escasez hídrica radican en el empleo de un sistema de riego adecuado al cultivo y tamaño de este. Nos encontramos, de entre todas ellas, dos destacadas: la aspersión y el goteo. Sin embargo, de entre todas estas alternativas, ninguna aporta una solución eficaz en relación al entorno que rodea al terreno, y si lo hacen, sólo pueden aplicarse a zonas de menor tamaño y con mayor control del sus condiciones, como podrían ser invernaderos.

La tecnología del Internet de las Cosas, referido de ahora en adelante como IoT, permite parametrizar situaciones que vivimos diariamente y nos da la posibilidad de actuar frente a posibles cambios en esos datos en un tiempo mínimo. Algunos ejemplos son las ciudades inteligentes, la agricultura de precisión o la conectividad entre vehículos.

A lo largo de este proyecto se desarrollará la idea de un sistema IoT de agricultura inteligente, el cual recogerá datos del propio cultivo relativos al crecimiento y cuidado del mismo y, posteriormente, se analizarán para su debida reacción en el suministro de agua. Con ella, se podrá optimizar el ciclo de riego de la producción con datos que proporciona el mismo y reaccionar ante ellos de forma casi instantánea.

El objetivo principal del proyecto es la reducción de la cantidad de recursos utilizados, ya sean hídricos y/o eléctricos (consumidos al extraer u obtener los primeros) a la par que se optimiza el ciclo de vida del cultivo proporcionando al cultivo agua únicamente y siempre en el momento en el que lo necesite. Al agricultor se le facilitará una herramienta donde tendrá centralizados todos los terrenos de los que disponga y podrá visualizar el estado de cada uno en tiempo real y desde cualquier plataforma.

(24)

(25)

OBJETIVO

En el siguiente capítulo se detallará al lector la finalidad de este Trabajo de Fin de Carrera, en adelante referido como TFG, así como sus funcionalidades y objetivos más específicos.

2.1. OBJETIVO GENERAL

El objetivo principal es el diseñar e implementar un sistema de monitorización de riego para cul- tivos de tamaño medio/grande que informe al agricultor del estado del mismo, además de poder retroalimentarse de esa información y determinar el riego en función de estos.

2.2. OBJETIVOS PARCIALES

Para cumplir con el objetivo general descrito anteriormente deben completarse los objetivos específi- cos detallados a continuación.

2.2.1. Análisis de las arquitecturas y tecnologías de comunicación a utilizar Una parte importante del desarrollo de este TFG es el diseño de la arquitectura del sistema y, por consiguiente, la determinación de las tecnologías que vaya a emplear para dar soporte a toda la infraestructura.

Para ello se requiere de un sistema de toma de decisiones respecto a la comparación de tecnologías, tras un extenso análisis del mercado en busca de las posibles candidatas, teniendo en cuenta el alcance y requerimientos del proyecto, además de la interoperabilidad de todos los elementos del propio sistema.

2.2.2. Selección de sensores y módulos de comunicaciones de IoT

Es necesario explorar el mercado una vez más para la búsqueda de sensores y módulos de comunicaciones inalámbricas teniendo en cuenta la arquitectura previamente diseñada.

Para ello se analizarán distintas opciones compatibles con nuestra infraestructura y que nos proporcionen los datos necesarios para determinar el riego del terreno. Además, en el caso de los módulos de comunicaciones, se buscarán aquellos que además de ser compatibles cubran las distancias requeridas de la red de comunicaciones diseñada y tengan una óptima funcionalidad en el entorno al que se someterían, exteriores y afrontando distintas condiciones meteorológicas.

(26)

4 2.2. OBJETIVOS PARCIALES 2.2.3. Implementación de software de recolección de datos de los sensores Primeramente, el sistema debe ser capaz de utilizar los sensores elegidos previamente para recoger los datos que nos proporcionen y gestionarlos.

Para ello se utilizarán las librerías pertinentes o se desarrollarán los programas necesarios para poder interpretar la información que recogen los sensores, ya sea en forma analógica o digital.

2.2.4. Implementación de software de comunicación entre los nodos y la pasarela En necesario el desarrollo de una infraestructura de red que facilite la comunicación entre los dispositivos recolectores de información de los sensores con aquellos que tengan salida a Internet.

Para ello se implementará la mencionada infraestructura, basada en comunicaciones inalámbricas, y se facilitará a cada dispositivo un mecanismo de identificación entre sus iguales para la correcta secuencia de mensajes transmitidos por cada uno de ellos.

2.2.5. Implementación de software de comunicación entre el servicio en la nube y la pasarela

A su vez, en imprescindible el desarrollo de una infraestructura de red que permita a los dispositivos encontrados en el terreno, recibiendo los datos del mismo, comunicarse con los servicios de almacenamiento alojados en Internet.

Para ello, se desplegarán servicios de almacenamiento de datos en la nube, así como su correcta configuración para la recepción de datos por los dispositivos del terreno de forma explícita y única- mente accesible por estos. Además, se proveerá de los parámetros necesarios a estos últimos para que tengan los mecanismos requeridos para una segura y correcta comunicación.

2.2.6. Implementación de software de monitorización de los datos recolectados Por último, se necesitará de un sistema de monitorización de datos para que el usuario pueda visualizar el estado del cultivo.

Para ello se diseñará y desarrollará un sistema que cumplimente los requisitos de este objetivo.

(27)

METODOLOGÍA DE TRABAJO

En este capítulo se detalla la metodología de trabajo empleada para lograr los objetivos marcados en el Capítulo2, así como en el desarrollo del proyecto y las herramientas, tanto software como hardware, utilizadas en el mismo.

3.1. ELECCIÓN Y BREVE DESCRIPCIÓN DE LA METODOLOGÍA

Para la elaboración de este TFG se ha empleado el Proceso Unificado de Desarrollo, de ahora en adelante referido como P UD, como metodología de trabajo. Tal y como se define en [8]:

El P UD es un marco genérico que puede especializarse para una gran variedad de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyectos.

Se ha optado por dicha alternativa por su relativa sencillez, generalidad, y la amplitud de control de software que ofrece.

Para diseñar y realizar los modelos de cualquier sistema, P UD hace uso del Lenguaje Unificado de Modelado, en adelante referido como UML, el cual se ha utilizado en este proyecto en sus diferentes etapas. Cabe mencionar que el P UD se caracteriza por:

Ser iterativo e incremental.

Estar basado en la arquitectura.

Estar dirigido por casos de uso.

3.2. GESTIÓN DEL PROYECTO

3.2.1. Fases

Siguiendo la estructura del ciclo de vida de un producto software definido por P UD, se han establecido las siguientes pautas o fases generales a seguir:

1. Inicio: Se llevará a cabo una descripción del producto final que se desea conseguir, estudiando el alcance del proyecto, su viabilidad, y la planificación del desarrollo del proyecto. Se obtienen:

a) Modelo de casos de uso, el cual describe las funcionalidades del sistema.

2. Elaboración: Se desarrollará y trabajará en el modelo obtenido en la fase anterior profundi- zando así en la arquitectura del sistema, consiguiendo la línea base de ésta. Se obtienen:

(28)

6 3.3. MARCO TECNOLÓGICO a) Modelo de análisis, con el que desarrollamos las funcionalidades en procesos, interfaces

o bancos de datos.

b) Modelo de diseño, obteniendo un despliegue mucho más especifico del modelo anterior.

3. Construcción: Se implementará y probará el producto, tanto su despliegue físico como el software de cada uno de sus componentes. Se obtiene:

a) Modelo de implementación, con el que se conseguirá representar la ejecución total del sistema.

b) Modelo de pruebas, el cual contiene el conjunto de casos de pruebas unitarias que se realizan al finalizar cada una de las fases del P UD.

4. Transición: Al llegar a esta etapa, el producto está en su versión beta y se procede a la evaluación del mismo en busca de errores o deficiencias. Se obtiene:

a) Versión del producto final.

b) Documentación del desarrollo.

3.2.2. Aplicación

En este apartado se muestra de qué manera se ha aplicado el P UD para la gestión del proyecto.

Posteriormente, en el Capítulo4se detallarán los artefactos resultantes de dicha aplicación para cada una de las iteraciones.

En la Tabla3.1se puede observar un resumen de la planificación del proyecto y de sus iteraciones.

Para cada una de estas últimas se han aportado los objetivos más relevantes.

Tabla 3.1: Planificación de iteraciones Fase Iteración Objetivos

Inicio Preliminar Planificación del proyecto, realizar el documento del Anteproyecto, captura de requisitos y modelado de casos de uso.

Elaboración

1 Definición de la arquitectura del sistema.

2 Realizar el modelo de análisis y de diseño, prepara- ción del entorno de desarrollo.

Construcción

3 Desarrollo de las funcionalidades que engloba el caso de uso 01, Acceso/Registro.

4 Desarrollo de las funcionalidades que engloba el caso de uso 02, Visualización

5 Desarrollo de las funcionalidades que engloba el caso de uso 03, Recolección de información

Transición

6 Despliegue del sistema

7 Pruebas

8 Documentación del proyecto

3.3. MARCO TECNOLÓGICO

3.3.1. Herramientas hardware

Ordenador de sobremesa [10]: Dell Precision T1650, empleado para el desarrollo y redacción de la documentación del proyecto.

(29)

del proyecto.

LoPy [35]: Placa de desarrollo, empleada para la implementación de los nodos recolectores y pasarelas.

DHT22 [25]: Sensor de humedad relativa y temperatura del aire.

Sensor de humedad de suelo: Sensor que mide la humedad del suelo de forma analógica 3.3.2. Herramientas para la gestión de proyectos

Bitbucket [5]: Bitbucket es un servicio de control de repositorios en la nube que manejan software de control de versiones, como Git o Mercurial.

Mercurial [33]: Mercurial es una herramienta de control de versiones de software libre. Maneja proyectos de cualquier tamaño eficientemente y ofrece una interfaz fácil e intuitiva.

Microsoft Project [28]: Microsoft Project es un software de administración de proyectos que simplifica estos y sus recursos para realizar su seguimiento.

3.3.3. Herramientas, lenguajes y tecnologías para el modelado de software Visual Paradigm [39]: Visual Paradigm es un software de gestión y tratamiento de sistemas de tecnologías de la impormación.

UML [30]: UML (Lenguaje Unificado de Modelado) es un lenguaje que permite especificar, visualizar, diseñar y documentar artefactos generados por los sistemas software.

3.3.4. Herramientas, lenguajes y tecnologías para el desarrollo de software

Atom [16]: Atom es un editor de código fuente de código abierto desarrollado por GitHub.

Pymakr [36]: Pymakr, en forma de paquete para Atom, añade una consola a éste que permite la comunicación con placas de desarrollo de Pycom.

Python [37]: Python es un lenguaje de programación. Se ha empleado su versión 3.7 principalmente en el presente proyecto.

Micropython [15]: Micropython es una implementación de Python 3 optimizada para ejecutarse en microcontroladores.

SQL [22]: SQL es un lenguaje de bases de datos. Se ha utilizado para el almacenaje de los datos recogidos para su posterior monitorización.

Amazon Web Services, EC2 [3]: Amazon Elastic Compute Cloud (Amazon EC2) es un servicio web que proporciona capacidad informática en la nube segura y de tamaño modificable.

Está diseñado para simplificar el uso de la informática en la nube a escala web para los desa- rrolladores.

Docker [11]: Docker es una herramienta que permite la rápida creación, despliegue y ejecución de aplicaciones mediante el uso de contenedores.

Grafana [19]: Grafana es una herramienta de código abierto preparada para el análisis y monitorización de fuentes de datos.

MySQL Server [32]: MySQL Server es un sistema de control de bases de datos de código abierto.

(30)

8 3.3. MARCO TECNOLÓGICO 3.3.5. Herramientas para la elaboración de la documentación

L^ATEX [1]: L^ATEXes un sistema de preparación de documentos que ha sido necesario para la realización de la memoria del proyecto.

Overleaf [34]: Overleaf es un editor online de L^ATEX.

Draw.io [23]: Draw.io es una herramienta online de creación de distintos tipos de diagramas.

circuit-diagram.org [9]: Circuit Diagram es una herramienta online de creación de diagramas de circuitos eléctricos.

(31)

RESULTADOS

En esta sección se describirá la aplicación del método de trabajo presentado en el Capítulo3en este caso concreto, mostrando los elementos (modelos, diagramas, especificaciones, etc.) más importantes.

Este apartado debe explicar cómo la metodología satisface los objetivos planteados en el Capítulo2.

4.1. FASE DE INICIO

En dicha fase tiene lugar una única iteración, como podemos comprobar en la tabla3.1. En esta etapa del ciclo de vida del proyecto se llevará a cabo la captura e identificación de los requisitos y una planificación de sus iteraciones.

4.1.1. Captura de Requisitos

Tras analizar los objetivos a conseguir descritos en el Capítulo2se analizaron las necesidades y funcionalidades que el sistema debía cumplir, además de considerar las posibles restricciones que afecten al proyecto. Hecho esto, se elaboró la siguiente lista de requisitos funcionales:

RF.01 Acceso y/o Registro: El usuario debe poder registrarse en el caso de que lo requiera y, por consiguiente, acceder al resto de funcionalidades del sistema.

RF.02 Monitorización del cultivo: El usuario podrá visualizar los datos de su cultivo en tiempo real.

RF.03 Recolección de información: A través de sensores el sistema obtendrá información sobre el terreno.

RF.04 Envío de información: Se enviará la información recogida a un servicio a través de la red.

RF.05 Análisis y Almacenamiento: La información recogida se analizará para si el riego es o no suficiente en ese instante y se almacenará en una base de datos.

También se identificaron los siguientes requisitos no funcionales:

RNF.01 Alojamiento en la nube: El servicio en la red al que el usuario accederá debe estar alojado en algún servicio de alojamiento en la nube por la independencia de infraestructura y el libre acceso desde cualquier parte del globo, además de proporcionar unos sistemas de seguridad básicos.

(32)

10 4.1. FASE DE INICIO

RNF.02 Comunicaciones de largo alcance: Las comunicaciones que se empleen deben ser de largo alcance, ya sean inalámbricas o no, aunque por ello no debe aumentar excesivamente el coste del proyecto.

RNF.03 División en secciones: El terreno, al ser una superficie grande, puede subdividirse en zonas más pequeñas para su correcta parametrización en el sistema.

RNF.04 Encriptación de mensajes: Todos los datos que se envíen y reciban deben estar encriptados para asegurar la no manipulación de los mismos.

Con estos requisitos definidos, podemos obtener una versión inicial del modelo de casos de uso del sistema tras a aplicar la trazabilidad de requisitos a casos de uso con uso del P UD. Partiendo de los requisitos anteriormente especificados, y de la suposición de que varios requisitos funcionales pueden proyectarse en un caso de uso, obtenemos los siguientes casos de uso:

Tabla 4.1: Trazabilidad de requisitos

Caso de Uso Requisito Funcional CdU.01 Acceso/Registro RF.01 Acceso y/o Registro

CdU.02 Visualización RF.02 Monitorización del cultivo CdU.03 Recolección de información

RF.03 Recolección de información RF.04 Envío de información RF.05 Análisis y Almacenamiento

En la figura4.1podemos observar el diagrama de casos de uso del sistema completo a un alto nivel de abstracción.

Figura 4.1: Versión inicial del Modelo de Casos de Uso

4.1.2. Planificación de Iteraciones

Se ha llevado a cabo una planificación del proyecto con ayuda de la identificación de las distintas iteraciones a completar gracias a la herramienta de Microsoft Project.

Iteraciones

En primer lugar, y teniendo en cuenta la trazabilidad de requisitos a casos de uso dada en el Apartado 4.1.1, se han definido las siguientes iteraciones a cumplir en el desarrollo de este proyecto:

(33)

Tabla 4.2: Iteración preliminar Iteración Preliminar

Fase Inicio

Objetivos Captura de Requisitos

Versión inicial del modelo de casos de uso Planificación del proyecto

Anteproyecto aprobado por la comisión académica encargada de dicha tarea

Artefactos Requisitos funcionales y no funcionales del proyecto Diagrama de casos de uso

Documento del Anteproyecto Tabla 4.3: Iteración 1 Iteración 1

Fase Elaboración

Objetivos Definición de la línea base de la arquitectura Artefactos Diseño de la arquitectura

Tabla 4.4: Iteración 2 Iteración 2

Fase Elaboración

Objetivos Modelo de análisis Modelo de diseño

Artefactos Diagrama de clases de análisis Diagrama de clases de diseño

Fase Construcción

Objetivos Implementación del caso de uso CdU.01 Pruebas de integración

Artefactos Diagrama de secuencia del caso de uso CdU.01 Resultado de las pruebas

Fase Construcción

(34)

Fase Transición

Objetivos Despliegue del sistema completo Artefactos Sistema desplegado y funcional

Fase Transición

Objetivos Realización de pruebas en el sistema desplegado Artefactos Resultados de las pruebas

Fase Transición

Objetivos Documentación del proyecto Artefactos Memoria del TFG

(35)

Diagrama de Gantt

Para conseguir una estimación de la duración del proyecto, se han planificado cada una de las iteraciones anteriormente descritas con ayuda de la herramienta Microsoft Project.

Primero se ha definido el único recurso de trabajo del que dispone el proyecto, el trabajo de la autora, contando con los horarios disponibles de la misma y periodos no laborales. Se han supuesto una media jornada diaria de cuatro horas de Lunes a Jueves, sin incluir los festivos.

Así, el proyecto quedaría con las siguientes asignaciones de tareas y periodos de inicio y fin de cada una de ellas visible en la Tabla4.11.

(36)

Tabla 4.11: Asignaciones de recursos a las diferentes tareas

Nombre de tarea Trabajo Duración Comienzo Fin

Inicio 32 horas 8,38 días lun 04/02/19 jue 14/02/19

Iteración inicial 32 horas 8,38 días lun 04/02/19 jue 14/02/19 Captura de requisitos 16 horas 2 días lun 04/02/19 jue 07/02/19 Cristina Bolaños Peño 16 horas lun 04/02/19 jue 07/02/19 Planificación en iteraciones 16 horas 2 días lun 11/02/19 jue 14/02/19 Cristina Bolaños Peño 16 horas lun 11/02/19 jue 14/02/19

Elaboración 48 horas 13,38 días lun 18/02/19 jue 07/03/19

Iteración 1 24 horas 6,38 días lun 18/02/19 mar 26/02/19

Diseño de la arquitectura 24 horas 3 días lun 18/02/19 mar 26/02/19 Cristina Bolaños Peño 24 horas lun 18/02/19 mar 26/02/19

Iteración 2 24 horas 6,38 días mié 27/02/19 jue 07/03/19

Diagrama de clases de dominio 16 horas 2 días mié 27/02/19 mar 05/03/19 Cristina Bolaños Peño 16 horas mié 27/02/19 mar 05/03/19 Diseño de la base de datos 8 horas 1 día mié 06/03/19 jue 07/03/19

Cristina Bolaños Peño 8 horas mié 06/03/19 jue 07/03/19

Construcción 120 horas 43,38 días lun 11/03/19 jue 09/05/19

Iteración 3 32 horas 8,38 días lun 11/03/19 jue 21/03/19

Implementación CdU.01 24 horas 3 días lun 11/03/19 mar 19/03/19 Cristina Bolaños Peño 24 horas lun 11/03/19 mar 19/03/19

Pruebas CdU.01 8 horas 1 día mié 20/03/19 jue 21/03/19

Transición 64 horas 18,38 días lun 13/05/19 jue 06/06/19

Iteración 6 24 horas 6,38 días lun 13/05/19 mar 21/05/19

Despliegue del sistema 24 horas 3 días lun 13/05/19 mar 21/05/19 Cristina Bolaños Peño 24 horas lun 13/05/19 mar 21/05/19

Iteración 7 16 horas 4,38 días mié 22/05/19 mar 28/05/19

Pruebas del sistema desplegado 16 horas 2 días mié 22/05/19 mar 28/05/19 Cristina Bolaños Peño 16 horas mié 22/05/19 mar 28/05/19

Iteración 8 24 horas 6,38 días mié 29/05/19 jue 06/06/19

Documentación 24 horas 3 días mié 29/05/19 jue 06/06/19

(37)

4.2. FASE DE ELABORACIÓN

Esta fase se centra en las disciplinas de análisis y diseño del propias del P UD. Como podemos observar en la Tabla3.1, dicha fase se ha dividido en dos iteraciones, de las cuales la primera se centra en la definición de la línea base de la arquitectura del sistema, mientras que en la segunda iteración se desarrollarán los modelos de análisis y diseño.

4.2.1. Iteración 1

En esta iteración se han abordado las tareas de revisión de los requisitos del sistema para conseguir la definición de la línea base de la arquitectura del sistema, detallando la elección de herramientas y tecnologías para ello.

Arquitectura del sistema

Basándonos en las especificaciones y objetivos de este proyecto, la arquitectura tendrá dos partes diferenciadas pero que se comunican entre sí, única y exclusivamente:

El entorno IoT elaborado con los dispositivos desplegados en el terreno, diseñando los protocolos de comunicación internos y aquellos con salida a la red.

El entorno Cloud basado en una aplicación web y los servicios desplegados en elback-end de la misma, configurando a su vez las comunicaciones internas entre estos servicios.

Inicialmente, la infraestructura del proyecto cuenta con ciertas restricciones en lo que a su diseño se refiere, más concretamente en el uso de dispositivos o tecnologías con las que se disponía en el momento de planificar el TFG, ya sean facilidades aprovisionadas explícitamente por parte del laboratorio de investigación ARCO como por la Universidad de Castilla-La Mancha o en su defecto la Escuela Superior de Informática.

Aquellos elementos con los que el proyecto cuenta desde sus inicios y que se deben tener en el planteamiento de la arquitectura son los siguientes:

Placas LoPy empleadas para la lectura de sensores y comunicación entre iguales y el servicio cloud.

Amazon Web Services como entornocloud para el debido despliegue de la aplicación web.

Docker para el despliegue de distintos servicios y su debida comunicación entre sí.

A modo de versión inicial o base, la cual incluye todos los elementos anteriormente mencionados y que sirve de modelo a completar en un futuro, tenemos la estructura descrita en la Figura4.3:

(38)

16 4.2. FASE DE ELABORACIÓN

Figura 4.2: Versión inicial de la arquitectura del sistema

Tras tener esta ideabeta de infraestructura, se procede a decidir cómo se van a implementar las funcionalidades del sistema dentro de esa arquitectura inicial.

En el caso de la tecnología de comunicación empleada entre los módulos LoPy, de entre los muchos mecanismos que ofrece esta placa, elegimos utilizar LoRaWAN ya que se requieren comunicaciones de largo alcance, que deben cubrir todo el terreno. En el caso de la tecnología de comunicación empleada entre las pasarelas con el entornocloud elegimos utilizar GPRS [2] o alguna otra alternativa que se base en la comunicación vía satélite, ya que por la ubicación del terreno debería de proporcionarse cobertura en cualquier localización en el globo.

Un caso de conflicto entre ideas surgió al analizar cómo realizar en caso de uso CdU.02, visualiza- ción de los datos, pues se descubrió Grafana, la cual es una herramienta de código abierto preparada para el análisis y la consiguiente monitorización de diferentes fuentes de datos.

Primeramente, se tenía en mente la posibilidad de hacer el desarrollo de la funcionalidad por completo de dicho caso de uso, en este caso a través de Flask [38], una herramienta basada en Python para la creación y desarrollo de aplicaciones web.

Ante estas dos alternativas, utilizamos el método de selección por medio de pesos descrita por Michael S.Bandor en 2006 [6]:

La hoja de análisis de decisiones permite a una organización comparar varios productos empleando una serie de criterios y la asignación de valores o pesos a dichos criterios.

Como bien indica el procedimiento de este método de selección, primero debemos elegir aquellos

(39)

seleccionado los siguientes:

Tiempo de desarrollo o configuración.

Implementación de otras funcionalidades por defecto.

Adaptación al proyecto.

Coste.

Con los criterios definidos previamente obtenemos la siguiente hoja de análisis de decisiones en la Tabla4.12y, por consiguiente, se selecciona la herramienta Grafana para el despliegue del caso de uso CdU.02. Además, ésta permite el acceso y registro de usuarios por defecto, por lo que también se empleará para el despliegue del caso de uso CdU.01.

Tabla 4.12: Decisión para el sistema de monitorización Alternativas

Grafana Flask

Id Factor Peso Valor Aplicado Valor Aplicado

A Tiempo de desarrollo o configu- ración

40 % 0.5 20 % -0.5 -20 %

B Implementa otras funcionalidades por defecto

25 % 0.5 25 % 0.0 0 %

C Adecuación al proyecto 25 % 0.0 0 % 1.0 25 %

D Coste 10 % 1.0 10 % 1.0 10 %

Total 100 % 55 % 15 %

Tras la decisión de emplear Grafana para la implementación del caso de uso CdU.02, la visuali- zación de los datos, tras explorar a fondo la herramienta, se elige a MySQL Server como el sistema idóneo para mantener los datos de todo el sistema, por su complicidad con Grafana como por la sencillez y la idoneidad que las bases de datos relacionales aportan al problema que supone el presente proyecto.

Finalmente, la única pieza que falta es elback-end del entorno cloud, el cual recibirá todos los datos provenientes de las pasarelas y los almacenará en la base de datos. Como las mencionadas pasarelas tendrán que trabajar con tramas TCP, se ha elegido Python para desarrollar unscript que escuche dichos mensajes y que realice las debidas consultas a la base de datos posteriormente.

Con todo ello, tenemos definida la línea base de la arquitectura en la Figura4.3:

(40)

Figura 4.3: Diseño de la arquitectura del sistema

4.2.2. Iteración 2

En esta iteración se han abordado aquellas tareas relacionadas con el modelado de análisis y de diseño del sistema partiendo de la definición de los casos de uso del mismo definidos en la anterior fase.

También se van a desempeñar las tareas del diseño de la base de datos a emplear por el sistema.

Diagrama de clases de dominio

Se han identificado las clases de los objetos de dominio y su interrelación. Tras este proceso, se obtuvo el diagrama de clases de diseño mostrado en a Figura4.4, el cual se ha ido especificando a lo largo del resto de las iteraciones siguientes.

(41)

Figura 4.4: Diagrama de clases de diseño del dominio del sistema

Diseño de la base de datos

A partir de la definición de las clases de diseño del dominio, observables en la Figura4.4, y sus relaciones se fue diseñando la base de datos. Como ya se ha destacado anteriormente en el presente documento, se ha utilizado MySQL Server para sostener la base de datos, la cual debe ser relacional.

Para la declaración de tablas se han mapeado cada clase persistente, es decir, destinada a almacenarse en la base de datos, del modelo de clases de diseño a una tabla, además de algunas modificaciones que se comentarán a continuación.

Listado 4.1: Código de la creación de la tablausuario

1 C R E A T E T A B L E ‘ user ‘ (

2 ‘ email ‘ V A R C H A R( 2 0 ) NOT NULL,

3 ‘ p a s s w o r d ‘ V A R B I N A R Y ( 6 4 ) NOT NULL,

4 ‘ name ‘ V A R C H A R( 2 0 ) NOT NULL,

5 P R I M A R Y KEY ( ‘ email ‘)

6 ) E N G I N E = I n n o D B ;

Como podemos ver en el Listado4.1, el usuario se identificará con la combinación de su dirección de correo electrónico y una contraseña. Además de ello, se almacenará su nombre a efectos de muestra

(42)

en la interfaz con la que interactuará el usuario.

Listado 4.2: Código de la creación de la tablaterreno

1 C R E A T E T A B L E ‘ field ‘ (

2 ‘ id ‘ INT u n s i g n e d NOT NU L L A U T O _ I N C R E M E N T ,

3 ‘ user ‘ V A R C H A R( 2 0 ) NOT N UL L R E F E R E N C E S u se r ( ‘ email ‘) ON ←- ,→ U P D A T E C A S C A D E ON D E L E T E CASCADE,

4 P R I M A R Y KEY ( ‘ id ‘)

5 ) E N G I N E = I n n o D B ;

El el Listado4.2podemos observar la creación de la tabla que se corresponde con la clase terreno de nuestro modelo de clases de diseño de dominio (Figura4.4. El campouser se correspondrá con su respectivo en la tabla de usuarios vista en el Listado4.1.

Listado 4.3: Código de la creación de la tablaunidad

1 C R E A T E T A B L E ‘ unit ‘ (

3 ‘ name ‘ V A R C H A R( 2 0 ) NOT N UL L UNIQUE,

4 ‘ symbol ‘ V A R C H A R( 2 0 ) NOT NULL,

5 ‘ highest ‘ INT,

6 ‘ lowest ‘ INT,

8 ) E N G I N E = I n n o D B ;

Listado 4.4: Código de la creación de la tablasensor

1 C R E A T E T A B L E ‘ sensor ‘ (

3 ‘ model ‘ V A R C H A R( 2 0 ) NOT NULL,

4 ‘ d e s c r i p t i o n ‘ V A R C H A R( 4 0 ) ,

5 ‘ unit ‘ INT NOT N U L L R E F E R E N C E S u n i t ( ‘ id ‘) ON U P D A T E C A S C A D E ←- ,→ ON D E L E T E CASCADE,

7 ) E N G I N E = I n n o D B ;

(43)

Listado 4.5: Código de la creación de la tablaárea

1 C R E A T E T A B L E ‘ area ‘ (

2 ‘ id ‘ INT u n s i g n e d NOT N U L L A U T O _ I N C R E M E N T ,

3 ‘ field ‘ INT NOT N U L L R E F E R E N C E S f i e l d ( ‘ id ‘) ON U P D A T E ←- ,→ C A S C A D E ON D E L E T E CASCADE,

4 ‘ s e n s o r _ h u m ‘ INT NOT N U LL R E F E R E N C E S s e n s o r ( ‘ id ‘) ON U P D A T E ←- ,→ C A S C A D E ON D E L E T E CASCADE,

5 ‘ s e n s o r _ t e m ‘ INT NOT N U LL R E F E R E N C E S s e n s o r ( ‘ id ‘) ON U P D A T E ←- ,→ C A S C A D E ON D E L E T E CASCADE,

6 ‘ s e n s o r _ m o i ‘ INT NOT N U LL R E F E R E N C E S s e n s o r ( ‘ id ‘) ON U P D A T E ←- ,→ C A S C A D E ON D E L E T E CASCADE,

7 ‘ lon ‘ INT,

8 ‘ lat ‘ INT,

10 ) E N G I N E = I n n o D B ;

Para el correcto almacenamiento de la clase de diseño que corresponde a las áreas del terreno, hemos visto necesarios la creación de otras dos tablas adicionales además de la que le corresponde.

Éstas son las tablas deunit, Listado4.3, y la desensor, Listado4.4.

Una misma área tendrá a su disposición distintos sensores con los que trabajar y obtener los resultados que se requieren y, a su vez, estos tienen sus propias unidades de medida. Con todo ello, conseguimos diseñar la tablaarea, pudiéndose ver en el Listado4.5, la cual refleja la relación que tiene con el terreno al que pertenece.

Listado 4.6: Código de la creación de la tablaentorno

1 C R E A T E T A B L E ‘ env ‘ (

2 ‘ id ‘ INT u n s i g n e d NOT N U L L A U T O _ I N C R E M E N T ,

3 ‘ area ‘ INT NOT N U L L R E F E R E N C E S a r e a ( ‘ id ‘) ON U P D A T E C A S C A D E ←- ,→ ON D E L E T E CASCADE,

4 ‘ dat ‘ D A T E T I M E NOT NULL,

5 ‘ h u m i d i t y ‘ F L O A T NOT NULL,

6 ‘ t e m p e r a t u r e ‘ F L O A T NOT NULL,

7 ‘ m o i s t u r e ‘ F L O A T NOT NULL,

9 ) E N G I N E = I n n o D B ;

Por último, tenemos el mapeado de la clase de diseñoentorno, para la cual se ha creado la tabla visible en el Listado4.6. Como puede verse, la tabla dispone de todas las variables a parametrizar del entorno del cultivo y se relaciona directamente con el área al que pertenecen dichas métricas.

4.3. FASE DE CONSTRUCCIÓN

Esta fase se centra en las labores de implementación y pruebas de los diferentes casos de uso definidos con anterioridad. Está compuesta de tres iteraciones, y para cada una de ellas se ha realizado la implementación del caso de uso pertinente y además realizar pruebas de funcionalidad e integración con el resto del sistema.

4.3.1. Iteración 3

En esta iteración se han abordado las tareas de implementación y pruebas del caso de uso CdU.01, Acceso y/o Registro de los distintos usuarios del sistema. Como se ha mencionado en apartados

(44)

22 4.3. FASE DE CONSTRUCCIÓN

anteriores, concretamente en el 4.2.2, estas acciones se llevarán acabo utilizando Grafana como herramienta de monitorización.

Configuración de Grafana

En primer lugar, debemos conocer Grafana y todos los apartados configurables de los que dispone y de los que nuestro sistema depende. Como pueden observarse en [18], hay una gran cantidad de variables de las que depende esta herramienta, pero sin lugar a duda la más importante es la correcta definición del usuario Administrador de la misma.

En el apartado de[security] de [18] vemos que podemos configurar cual será el usuario por defecto de la herramienta y el que será el primero de los que pueden ser muchos administradores. Únicamente estos pueden añadir usuarios a través de invitaciones a participar enviadas a las direcciones de correo electrónico pertinentes.

Una vez realizados los cambios que se requieran en esta configuración, la cual suele almacenarse en las rutas${DIRECTORIO DE TRABAJO}/grafana/grafana.ini tal y como se indica en [18], procederemos a iniciar el servicio y podremos acceder a el mismo a través del puerto configurado para ello, por defecto el 3000, con nuestro navegador.

Figura 4.5: Autenticación de usuarios a través de la interfaz de Grafana

Como puede observarse el la Figura4.5, esta es la primera vista que tenemos de nuestro sistema y la que compartimos con el usuario final, aquí es donde se autenticará proporcionando sus credenciales tras recibir su invitación a través de correo. Primero, entraremos con las credenciales que le hayamos otorgado al usuarioadmin y pasaremos a añadir más usuarios.

(45)

(a) Ver los usuarios de la herramienta de Grafana

(b) Invitar a usuarios a utilizar la herramienta a través de una dirección de correo electrónico

Figura 4.6: Registro de usuarios en Grafana, primera parte: Invitación de un administrador

(46)

(a) Aceptar una invitación de Grafana enviada al usuario

(b) El usuario finalmente puede autenticarse en la herramienta con su contraseña establecida

Figura 4.7: Registro de usuarios en Grafana, segunda parte: Aceptación de la invitación

(47)

Usuarios del submenú lateral de Grafana, Figura

el formulario de invitación de un usuario, Figura4.6(b). Después, el usuario recibirá un enlace a la herramienta para establecer su contraseña, Figura4.7(a), con la que al final podrá autenticarse como un usuario normal y poder acceder a todos sus datos, Figura4.7(b).

Integración con Docker

Como ya se mencionó en el apartado donde se definía la arquitectura del sistema, concretamente en la Figura4.3, se iba a utilizar Docker como herramienta de despliegue y comunicación entre los distintos servicios que se configuren. Tal y como se obtiene de [12]:

Docker otorga la habilidad de empaquetar y ejecutar aplicaciones en un entorno aislado llamado contenedor. El aislamiento y la seguridad permiten ejecutar varios contenedores simultáneamente en un mismo dispositivo. Los contenedores [...] son ligeros ya que se ejecutan directamente en el núcleo de la máquina, lo cual significa que pueden ejecutarse un número mayor de contenedores que si de máquinas virtuales se tratara.

En consideración con lo anterior, necesitamos un contenedor de Grafana para poder desplegarlo.

Para ello, cogeremos una imagen de Grafana ya preparada de unregistry, tal y como se puede ver en la Figura4.8, en nuestro caso será Docker Hub el cual es unregistry público, y la modificaremos para configurarla con nuestros parámetros.

Figura 4.8: Arquitectura de Docker, obtenida de [12]

Se ha creado una versión modificada de dicha imagen, concretamente se ha empleado la imagen grafana/grafana:5.4.3 [17], de la cual puede verse elDockerfile en el Listado4.7.

(48)

Listado 4.7: Dockerfile de Grafana

1 F R O M g r a f a n a / g r a f a n a : 5 . 4 . 3

2 L A B E L l o c a t i o n =" l o c a l "

3

4 C O P Y d a t a s o u r c e - m y s q l . y a m l / etc / g r a f a n a / p r o v i s i o n i n g / d a t a s o u r c e s /

5 C O P Y d a s h b o a r d - t e r r e n o . y a m l / etc / g r a f a n a / p r o v i s i o n i n g / d a s h b o a r d s /

6 C O P Y d a s h b o a r d - terreno - r e a l t i m e . j s o n / var / lib / g r a f a n a / d a s h b o a r d s /

Del listado mostrado anteriormente, las tres últimas líneas que lo conforman son de gran im- portancia, pues están, desde un inicio de la creación del contenedor, aprovisionando el servicio de Grafana con:

Especificación de la base de datos de donde recogerá los datos de la monitorización: credenciales de conexión, dónde se encuentra alojada, etc. Línea 3.

Paneles que mostrará los datos de monitorización de áreas de un terreno específico. Aquí es donde vienen definidos los tipos de consultas que Grafana realizará a las bases de datos pertinentes y de las cuales mostrará los datos en la interfaz. Líneas 4 y 5.

Para crear la imagen y un contenedor con ésta se ha utilizadomake de GNU [14], para una mayor rapidez a la hora de aplicar los comandos pertinentes, con el archivo descrito en el Listado4.8.

(49)

Listado 4.8: Makefile de Grafana

1 P A S S W O R D :=

2

3 %- l a s t e s t : M O N I T O R = g r a f a n a

4 %- l a s t e s t : V E R S I O N = l a s t e s t

5 %- l a s t e s t : . %

6 @ e c h o " D o n e "

7

8 . ask - p a s s w o r d :

9 i f e q ( $ ( P A S S W O R D ) , )

10 $ ( e v a l P A S S W O R D := $ ( s h e l l b a s h - c ’ r e a d - s - p " C o n t r a s e ñ a ␣←- ,→ del ␣ administrador ␣ de ␣ grafana :␣" pwd ; e c h o $$pwd ’) )

11 @ e c h o " "

12 e n d i f

13

14 . b u i l d :

15 @ d o c k e r b u i l d - t = l o c a l / m o n i t o r / $ ( M O N I T O R ) : $ ( V E R S I O N ) .

16

17 . run : . ask - p a s s w o r d

18 i f n e q ( $ ( s h e l l d o c k e r c o n t a i n e r ls | g r e p l o c a l _ $ ( M O N I T O R ) | wc ←- ,→ - l ) , 0)

19 @ d o c k e r s t op l o c a l _ $ ( M O N I T O R )

20 e n d i f

21 i f n e q ( $ ( s h e l l d o c k e r ps - a | g r e p l o c a l _ $ ( M O N I T O R ) | wc - l ) , 0)

22 @ d o c k e r rm l o c a l _ $ ( M O N I T O R )

23 e n d i f

24 @ d o c k e r run - d - p 8 0 : 3 0 0 0 - - n a m e = l o c a l _ $ ( M O N I T O R ) ←- ,→ - - n e t w o r k = $ ( N E T W O R K ) - e ←-

,→ " GF_SECURITY_ADMIN_PASSWORD =$( PASSWORD )" ←- ,→ l o c a l / m o n i t o r / $ ( M O N I T O R ) : $ ( V E R S I O N )

25

26 . log :

27 @ d o c k e r l o gs l o c a l _ $ ( M O N I T O R ) | l e s s

En entre las líneas 14 y 15 del anterior listado se encuentra el objetivobuild, el cual genera la imagen de Grafana a partir del Dockerfile que la define, Listado4.7, y que se encuentra en la misma ruta que el archivo Makefile.

En el caso de la ejecución del contenedor, entre las líneas 17 y 24, una vez generada la imagen, primero se comprueba si existía previamente este contenedor y se elimina, incluso se para si estaba en plena ejecución, para pasar a crearlo y ejecutarlo de nuevo. En el comando final, línea 24, vemos como se pasan ciertos parámetros específicos:

-p 80:3000: El puerto 3000 del contenedor se expone a la máquina anfitriona en el puerto 80.

–network=$(NETWORK): Al contenedor se le añade a una red interna ya creada, la cual conectará todos los servicios que definiremos en este proyecto.

-e "GF_SECURITY_ADMIN_PASSWORD=$(PASSWORD)": Se cambiará la contraseña del usuarioadmin por el valor de la variable PASSWORD, la cual se corresponde por lo que el usuario determine al ejecutarse el objetivoask-password.

4.3.2. Iteración 4

En esta iteración se cumplirán las tareas relacionadas con la implementación y pruebas del caso de uso CdU.02, Monitorización. Como ya se ha mencionado en la definición de la arquitectura del

(50)

sistema, Apartado4.2.2, se va a emplear MySQL Server para este desarrollo por su complicidad con Grafana.

Configuración de MySQL Server

Para que nuestro sistema disponga del almacenamiento necesario para su diseño, realizado y detallado a lo largo del Apartado4.2.2, primero debemos configurar los usuarios que tendrán acceso a la base de datos en cuestión.

MySQL Server dispone de distintas bases de datos por defecto con varias tablas cada una de éstas, sin embargo una de ellas no es si no la más importante en el momento de iniciar este servicio: la tablauser de la base de datos mysql.

Tal y como se indica en [31], según la forma de instalación de MySQL Server, el usuarioroot tendrá una u otra contraseña por defecto. Con este usuario podremos modificar todo el servidor, por lo tanto es un asunto crucial para la correcta configuración del servicio.

Figura 4.9: Autenticación del usuarioroot por primera vez

Una vez dentro, cargaremos el archivo que conforma nuestra base de datos (ver Apartado4.2.2). En este proyecto hemos llamado a dicha base de datosexample, para que conste para futuras referencias en otros listados.

Seguidamente, deberemos añadir distintos usuarios con sus correspondientes permisos para no necesitar del usuarioroot y así consigamos mayor seguridad. Estos usuarios se corresponderán con el número de servicios que se comuniquen con la base de datos, es decir, Grafana y elback-end del entornocloud, el cual se comunicará con las pasarelas y el que detallaremos en la siguiente iteración.

Además, les otorgaremos a cada uno los privilegios en las tablas pertinentes, en el caso de Grafana le otorgaremos realizar consultas del tipo SELECT en la tablaenv y en el caso del back-end o listener le permitiremos realizar consultas del tipo INSERT en la tablaenv. Todo ello puede observarse en el Listado4.9.

Listado 4.9: Creación de usuarios para MySQL Server

1 D R O P U S E R IF E X I S T S ’ g r a f a n a ’@’ %’;

2

3 C R E A T E U SE R ’ g r a f a n a ’@’ %’ I D E N T I F I E D BY ’ s e c r e t ’;

4 G R A N T S E L E C T ON e x a m p l e .* TO ’ g r a f a n a ’@’ %’;

5

6 D R O P U S E R IF E X I S T S ’ l i s t e n e r ’@’ %’;

7

8 C R E A T E U SE R ’ l i s t e n e r ’@’ %’ I D E N T I F I E D BY ’ s e c r e t ’;

9 G R A N T I N S E R T ON e x a m p l e .* TO ’ l i s t e n e r ’@’ %’;

Integración con Docker

Como ya se ha realizado en la iteración anterior, se procederá a su vez al traspaso de la anterior configuración a un contenedor de Docker. En este TFG se ha empleado la imagenmysql/mysql- server:5.7 [29] y se han modificado ciertos parámetros de la misma. Por ejemplo, en su Dockerfile

(51)

example por medio de una variable de entorno pasada con el archivo.

Listado 4.10: Dockerfile de MySQL Server

1 F R O M m y s q l / mysql - s e r v e r : 5 . 7

2 L A B E L l o c a t i o n =" l o c a l "

3

4 ENV M Y S Q L _ D A T A B A S E e x a m p l e

Para crear la imagen y un contenedor con ésta se ha utilizadomake de GNU [14], para una mayor rapidez a la hora de aplicar los comandos pertinentes, con el archivo descrito en el Listado4.11.

Listado 4.11: Makefile de MySQL Server

1 P A S S W O R D :=

2

3 %- l a s t e s t : S T O R A G E = m y s q l

4 %- l a s t e s t : V E R S I O N = l a s t e s t

5 %- l a s t e s t : . %

6 @ e c h o " D o n e "

7

8 . ask - p a s s w o r d :

9 i f e q ( $ ( P A S S W O R D ) , )

10 $ ( e v a l P A S S W O R D := $ ( s h e l l b a s h - c ’ r e a d - s - p " C o n t r a s e ñ a ␣ de ␣←- ,→ la ␣ base ␣ de ␣ datos :␣" pwd ; e c ho $$pwd ’) )

11 @ e c h o " "

12 e n d i f

13

14 . b u i l d :

15 @ d o c k e r b u i l d - t = l o c a l / s t o r a g e / $ ( S T O R A G E ) : $ ( V E R S I O N ) .

16

17 . run : . ask - p a s s w o r d

18 i f n e q ( $ ( s h e l l d o c k e r c o n t a i n e r ls | g r e p l o c a l _ $ ( S T O R A G E ) | wc ←- ,→ - l ) , 0)

19 @ d o c k e r s t op l o c a l _ $ ( S T O R A G E )

20 e n d i f

21 i f n e q ( $ ( s h e l l d o c k e r ps - a | g r e p l o c a l _ $ ( S T O R A G E ) | wc - l ) , 0)

22 @ d o c k e r rm l o c a l _ $ ( S T O R A G E )

23 e n d i f

24 @ d o c k e r run - d - - n a m e = l o c a l _ $ ( S T O R A G E ) - - n e t w o r k = $ ( N E T W O R K ) ←- ,→ - e " M Y S Q L _ R O O T _ P A S S W O R D = $ ( P A S S W O R D ) " ←-

,→ l o c a l / s t o r a g e / $ ( S T O R A G E ) : $ ( V E R S I O N )

25

26 . c r e a t e : . ask - p a s s w o r d

27 @ c a t ./ u s e r s . sql | d o c k e r e x e c - i l o c a l _ m y s q l m y s q l - u r o o t ←- ,→ - p$ ( P A S S W O R D )

28 @ c a t ./ r e s t o r e . sql | d o c k e r e x e c - i l o c a l _ m y s q l m y s q l - u r o o t ←- ,→ - p$ ( P A S S W O R D ) - D e x a m p l e

29

30 . l o a d : . ask - p a s s w o r d

31 @ c a t ./ e x a m p l e . sql | d o c k e r e x e c - i l o c a l _ m y s q l m y s q l - u r o o t ←- ,→ - p$ ( P A S S W O R D ) - D e x a m p l e

32

33 . log :

34 @ d o c k e r l o gs l o c a l _ $ ( S T O R A G E ) | l e s s

En la línea 14 se define el objetivobuild, el cual genera a imagen de MySQL Server a partir del Dockerfile que la define, Listado4.10, y que se encuentra en la misma ruta que este archivo Makefile.

En el caso de la ejecución del contenedor, entre las líneas 17 y 24, una vez generada la imagen, primero se comprueba si existía previamente este contenedor y se elimina, incluso se para si estaba

(52)

en plena ejecución, para pasar a crearlo y ejecutarlo de nuevo. En el comando final, línea 24, vemos como se pasan ciertos parámetros específicos:

–network=$(NETWORK): Al contenedor se le añade a una red interna ya creada, la cual conectará todos los servicios que definiremos en este proyecto.

-e "MYSQL_ROOT_PASSWORD=$(PASSWORD)": Se cambiará la contraseña del usuario root por el valor de la variable PASSWORD, la cual se corresponde por lo que el usuario determine al ejecutarse el objetivoask-password.

Por último, se han definido los objetivoscreate y load con los que se cargan en el servidor las tablas diseñadas en4.2.2y después se insertan valores de ejemplo, respectivamente, y que estos últimos serán los datos que se mostrarán en este documento. Ambos objetivos, en sus reglas, contienen el comando "docker exec -it", con el que se puede ejecutar, de forma interactiva, el comando que se especifique a continuación en el contenedor que a su vez se pase como parámetro.

4.3.3. Iteración 5

En esta iteración se ha realizado la implementación del caso de uso CdU.03, Recolección. Las tareas que se han llevado a cabo tratan el análisis y diseño de la comunicación entre los nodos, las pasarelas y el entornocloud, así como los tipos de mensajes que pueden darse, y el diseño e implementación de todas las funcionalidades de dicho caso de uso (ver Tabla4.1).

Formatos de mensaje

Para la correcta secuencia de mensajes y paso de información se han analizado las necesidades de datos, así como las características propias del protocolo de comunicación elegido, en este caso siendo éste LoRaWAN.

En primer lugar, veamos la topología que ofrece LoRaWAN. Disponemos de una estructura de tres capas, donde la primera de ellas contiene a todos los nodos que leen los datos a monitorizar, la segunda es aquella conformada por las pasarelas que es comunicada con la anterior a través de paquetes RF (radio) de LoRaWAN, y, por último, la tercera capa abarca un servidor de aplicaciones con el cual se conecta la capa previa a través de paquetes IP de LoRaWAN. Todo esto puede observarse en la Figura4.10. Para comunicarse con encriptando los mensajes LoRaWAN utiliza dos claves,Network key y Application key, las cuales están compartidas entre las capas de la topología.