Trabajo Fin de Grado -...

Equation Chapter 1 Section 1

Trabajo Fin de Grado

Grado en Ingeniería de las Tecnologías de

Telecomunicación

Sistema de ayuda al análisis de datos distribuido para

el mantenimiento predictivo de flotas de vehículos

Autor: Mónica Pérez Hernández

Tutor: Juan Manuel Vozmediano Torres

Dep. Ingeniería Telemática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2017

iii

Trabajo Fin de Grado

Grado en Ingeniería de las Tecnologías de Telecomunicación

Sistema de ayuda al análisis de datos distribuido

para el mantenimiento predictivo de flotas de

vehículos

Autor:

Mónica Pérez Hernández

Tutor:

Juan Manuel Vozmediano Torres

Profesor titular

Dep. de Ingeniería Telemática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2017

v

Trabajo Fin de Grado: Sistema de ayuda al análisis de datos distribuido para el mantenimiento predictivo de

flotas de vehículos

Autor: Mónica Pérez Hernández

Tutor: Juan Manuel Vozmediano Torres

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2017

El Secretario del Tribunal

vii

A mi familia

A mis amigos

A mis profesores

ix

Agradecimientos

En primer lugar, agradecer a mis padres el haberme dado la posibilidad de estudiar y su apoyo incondicional.

En segundo lugar, a mis amigos, tanto a los anteriores a esta etapa que cierro como a los que he hecho en su

transcurso; en especial a Fran y Álvaro, compañeros de risas y agobios desde segundo, y a Ana y Auxi,

compañeras de vida en este último año. También a Tito, Curro, Andrés, Ferrera , Flor, y el resto de amigos y

compañeros con los que he tenido la suerte de compartir estos años, ya que sin ellos no habría sido lo mismo.

Además, me gustaría darle las gracias a mis profesores por todo lo que he aprendido (o al menos, intentado

aprender) de ellos, especialmente al Departamento de Telemática y, evidentemente, a mi tutor del proyecto.

Por último, a Agustín Walabonso, por haber compartido conmigo innumerables momentos de risas, llantos y

estudio, por conocerme mejor que yo misma y por saber estar, escucharme y aconsejarme incluso cuando ni

yo misma sabía que lo necesitaba. ¡Gracias!

Mónica Pérez Hernández

Sevilla, 2017

xi

Resumen

En este proyecto se desarrollará un sistema que permita llevar a cabo el mantenimiento predictivo de

una flota de vehículos. Esto será posible gracias a una serie de sensores situados en los vehículos, que

registrarán continuamente los valores que van tomando los parámetros influyentes.

A medida que se vayan consiguiendo datos, la herramienta debe enviarlos a un sistema de mensajería

distribuido, en cuyo otro extremo se recibirán y se analizarán para buscar tendencias en su evolución

(ya sea de forma individual o dependiendo del valor de otro parámetro), correlaciones entre pares de

parámetros, etc. que faciliten el estudio del comportamiento de los vehículos y el descubrimiento de

patrones.

La información resultante se almacenará en una base de datos, y podrá ser consultada desde una web

que se desarrollará para ese propósito.

xiii

Abstract

The present project aims to develop a system that allows to carry out the predictive maintenance of

vehicles. This will be possible thanks to a series of sensors located in the vehicles, which will be

continuously recording the values that take the influencing parameters.

As data is obtained, the tool must send it to a distributed messaging system. The data will be received

at the side of the syste, where it will be analyzed in order to look for trends in its evolution (either

individually or depending on the value of another parameter), correlations between pairs of parameters,

etc. that may help to study the behavior of the vehicles and to discovery patterns of behavior.

The resulting information will be stored in a database, and it can be consulted from a web that will be

developed for that purpose.

xv

Índice

Agradecimientos ix

Resumen xi

Abstract xiii

Índice xv

Índice de Tablas xvii

Índice de Figuras xix

1 Introducción 1 1.1 Motivación 1 1.2 Objetivos 2 1.3 Alcance 2

2 Estado del arte 3 2.1 Antecedentes 3 2.2 Situación actual 3

3 Descripción del problema 5

4 Diseño de la solución 7 4.1 Sistema de mensajería distribuido 7

4.1.1 Patrón publicador-suscriptor 7 4.1.2 Apache Kafka 8 4.1.3 Zookeeper 9 4.1.4 Análisis de alternativas 10

4.2 Diseño de los componentes 11 4.2.1 Diseño del productor 12 4.2.2 Diseño del Consumidor 17

4.3 Diseño de la Base de Datos 29 4.4 Diseño de la web de consulta de los resultados 31

5 Implementación 33 5.1 Implementación del Productor 33

5.1.1 Fichero de configuración Producer.config 33 5.1.2 MainProducer 34 5.1.3 Producer 35

5.2 Implementación del consumidor 35 5.2.1 Fichero de configuración Consumer.config 35 5.2.2 MainConsumer 37 5.2.3 Ficheros de configuración [Topic].cfg 37 5.2.4 Consumer 39 5.2.5 Database 39

5.3 Base de datos 39 5.3.1 Estructura general 40 5.3.2 Tabla de correlación 40 5.3.3 Tabla de derivada 41

5.3.4 Tabla evolucion 41 5.3.5 Tabla evolucion_cond 41 5.3.6 Tabla alarma 42 5.3.7 Tabla logs 42

5.4 Implementación de la web de consulta de los resultados 43 5.4.1 Formulario 43 5.4.2 Tabla de resultados 46

6 Pruebas y validación 49 6.1 Puesta en marcha del escenario 49 6.2 Prueba 01: Modificación del fichero de configuración Producer.config 50 6.3 Prueba 02: Archivo csv inválido 52 6.4 Prueba 03: Modificación del fichero de configuración Consumer.config 52 6.5 Prueba 04: Modificación fichero de configuración de topic 54 6.6 Prueba 05: Procesamiento de datos correctos que no cumplen las condiciones 55 6.7 Prueba 06: Procesamiento de datos incorrectos 55 6.8 Resultados 56

6.8.1 Alarma 56 6.8.2 Correlación 56 6.8.3 Derivada 58 6.8.4 Evolución temporal 59 6.8.5 Evolución temporal condicionada 59

7 Conclusiones y posibles líneas de futuro 61 7.1 Conclusiones 61 7.2 Posibles líneas futuras 62

Referencias 63

Anexo A: Instalación y configuración del escenario 65

Anexo B: Manual de Usuario 71

xvii

ÍNDICE DE TABLAS

Tabla 1: Comparativa plataformas de mensajería distribuida 11

Tabla 2: Modelo tabla de requisitos 11

Tabla 3: Requisito general productor 01 "Fichero de configuración" 12

Tabla 4: Requisito general productor 02 "Número de topics activos" 12

Tabla 5: Requisito general productor 03 "Número de Productores activos" 12

Tabla 6: Requisito general productor 04 "Escalabilidad" 13

Tabla 7: Requisito general productor 05 "Paralelismo" 13

Tabla 8: Requisito general productor 06 "Lectura y envío de datos" 13

Tabla 9: Requisito general productor 07 "Identificador de mensaje" 13

Tabla 10: Requisito general productor 08 "Comprobación de fecha y hora" 13

Tabla 11: Requisito general productor 09 "Ficheros leídos" 14

Tabla 12: Caso de uso productor 01 "Recarga del fichero de configuración" 14

Tabla 13 : Requisito general consumidor 01 "Fichero de configuración Global" 18

Tabla 14 : Requisito general consumidor 02 "Número de consumidores activos" 18

Tabla 15 : Requisito general consumidor 03 "Paralelismo" 18

Tabla 16 : Requisito general consumidor 04 "Fichero de configuración del topic" 19

Tabla 17 : Requisito general consumidor 05 "Procesamiento de datos" 19

Tabla 18: Requisito general consumidor 06 "Intervalos de estudio variables" 19

Tabla 19 : Requisito general consumidor 07 "Recarga de la configuración de cada topic" 19

Tabla 20 : Requisito general consumidor 08 "Operación Derivada" 20

Tabla 21 : Requisito general consumidor 09 "Operación Correlación" 20

Tabla 22 : Requisito general consumidor 10 "Operación Evolución temporal" 21

Tabla 23 : Requisito general consumidor 10 "Operación Evolución temporal condicionada" 21

Tabla 24: Requisito general consumidor 11 "Operación Alarma" 22

Tabla 25 : Requisito general consumidor 12 "Logs" 22

Tabla 26: Caso de Uso consumidor 01 "Modificación de la configuración global” 22

Tabla 27: Caso de Uso consumidor 02 "Modificación de la configuración de un topic” 23

Tabla 28: Diagrama de flujo "Alarma" 28

Tabla 29: Contenido del fichero de configuración Producer.config 34

Tabla 30: Contenido del fichero de configuración "Consumer.config" 36

Tabla 31: Fichero de configuración asociado a un topic 38

Tabla 32: Estructura de la base de datos 40

Tabla 33: Estructura tabla "Correlacion" 40

Tabla 34: Estructura tabla "Derivada" 41

Tabla 35: Estructura tabla "Evolucion" 41

Tabla 36: Estructura tabla "Evolucion_cond” 42

Tabla 37: Estructura de la tabla de logs 42

Tabla 38: Prueba 04 "Modificación parámetros del análisis de evolución" 54

Tabla 39: Prueba 04 "Modificación parámetros del análisis de correlación" 54

Tabla 40: Prueba 05 "Procesamiento de datos correctos" 55

Tabla 41: Prueba 06 "Procesamiento de datos incorrectos" 56

xix

ÍNDICE DE FIGURAS

Ilustración 1: Componentes básicos de Apache Kafka 8

Ilustración 2: Funcionamiento de Kafka 9

Ilustración 3: Arquitectura completa de Kafka 10

Ilustración 4: Diagrama de flujo "Coordinación productores" 15

Ilustración 5: Diagrama de flujo “Ejecución proceso productor simple” 16

Ilustración 6: Diagrama de secuencia "Ejecución productor" 17

Ilustración 7: Diagrama d flujo "Coordinación de consumidores" 24

Ilustración 8: Diagrama de flujo "Ejecución consumidor simple" 25

Ilustración 9: Diagrama de flujo "Derivada" 26

Ilustración 10: Diagrama de flujo "Correlación" 26

Ilustración 11: Diagrama de flujo "Evolución temporal" 27

Ilustración 12: Diagrama de flujo "Evolución temporal condicionada” 27

Ilustración 13: Diagrama de secuencia "Ejecución consumidor" 29

Ilustración 14: Estructura tabla "Alarma" 42

Ilustración 15: Formulario Alarma / Derivada 43

Ilustración 16: Formulario correlación 44

Ilustración 17: Formulario evolución 44

Ilustración 18: Formulario evolución condicionada 45

Ilustración 19: Formulario logs 45

Ilustración 20: Consulta evolución I 46

Ilustración 21: Consulta evolución II 46

Ilustración 22: Consulta tabla de logs 47

Ilustración 23: Prueba 01 "Procesos iniciales I" 50

Ilustración 24: Prueba 01 "Procesos iniciales II" 50

Ilustración 25: Prueba 01 "Topics iniciales" 50

Ilustración 26: Pueba 01 "Procesos tras primera recarga de configuración I" 51

Ilustración 27: Prueba 01 "Procesos tras primera recarga de configuración II" 51

Ilustración 28: Prueba 01 "topics tras primera recarga de configuración" 51

Ilustración 29: Prueba 01 "Procesos tras la segunda recarga de configuración I" 51

Ilustración 30: Prueba 01 "Procesos tras la segunda recarga de configuración II" 52

Ilustración 31: Prueba 01 "Topics tras la segunda recarga de configuración" 52

Ilustración 32: Prueba 02 "Archivo csv inválido" 52

Ilustración 33: Prueba 03 "Procesos iniciales I" 53

Ilustración 34: Prueba 03 "Procesos iniciales II" 53

Ilustración 35: Prueba 03 "Procesos tras primer cambio de configuración I" 53

Ilustración 36: Prueba 03 "Procesos tras primer cambio de configuración II" 53

Ilustración 37: Prueba 03 "Procesos tras segundo cambio de configuración" 53

Ilustración 38: Prueba 04 "Modificación parámetros del análisis de derivada" 55

Ilustración 39: Resultados Alarma 01 56

Ilustración 40: Resultados Correlación 01 57

Ilustración 41: Resultados Correlación 02 57

Ilustración 42: Resultado Derivada 01 58

Ilustración 43: Resultado Derivada 02 58

Ilustración 44: Resultado Evolución temporal 01 59

Ilustración 45: Resultado evolución temporal condicionada 01 59

1

1 INTRODUCCIÓN

a EFNMS [1] define el término mantenimiento como “el conjunto de actividades técnicas y

administrativas cuya finalidad es conservar o restituir un sistema, subsistema, instalación,

planta, máquina, equipo, estructura, edificio, conjunto, componente o pieza a la condición que

le permita desarrollar su función”.

Distinguimos entre tres tipos básicos de mantenimiento: el correctivo, el preventivo y el predictivo. El

presente proyecto se centrará en el tercero de ellos.

1.1 Motivación

Entendemos por mantenimiento predictivo [2] el conjunto de técnicas instrumentadas de medida y

análisis de variables que se realiza para caracterizar, en términos de fallos potenciales, la condición

operativa de los equipos productivos. Su misión principal es optimizar la fiabilidad y disponibilidad

de los equipos con el mínimo coste posible.

Dicha práctica comporta una serie de ventajas entre las que destacan:

Permite preveer o detectar los posibles fallos en sus etapas inicales, con lo cual se dispone de

tiempo suficiente para planificar y programar las acciones correctivas necesarias, permitiendo

llevarlas a cabo bajo condiciones controladas, buscando minimizar los tiempos muertos y

garantizando reparaciones de mayor calidad.

Proporciona un aumento de la fiabilidad, en términos globales.

Reduce el índice de intervenciones al año en los equipos hasta a la quinta parte, lo que conlleva

asimismo una reducción del gasto en repuestos y en mano de obra.

Todo esto se consigue estudiando la tendencia de los valores, que es la que permitirá calcular o prever,

con cierto margen de error, cuando un equipo fallará; he ahí el motivo por el que se denominan técnicas

de mantenimiento predictivo.

El concepto de mantenimiento predictivo está ampliamente relacionado con el campo de las soluciones

IoT (Internet of Things), que se encuentra en auge en una amplia gama de sectores: salud, hogar,

ciudades inteligentes, procesos de fabricación e industria del automóvil, entre otros.

La motivación de este proyecto es, por tanto, la actualidad de los conceptos arriba descritos y su

creciente demanda.

L

“Engineers like to solve problems. If there are no

problems handily available, they will create their

own problems.”

- Scott Adams -

Introducción

2

1.2 Objetivos

El objetivo principal de este proyecto será el desarrollo de un sistema que permita realizar o facilitar

el mantenimiento predictivo de una flota de vehículos.

Se estudiarán y analizarán una serie de parámetros gracias a unos dispositivos con sensores que irán

registrando los valores que van tomando en el tiempo. A partir de ahora nos referiremos a estos

dispositivos con el nombre de unidades de a bordo.

Se colocará una unidad de a bordo en cada uno de los vehículos de la flota. Se debe tener en cuenta

que las unidades son intercambiables, es decir, la toma de medidas en un vehículo en intervalos de

tiempo sucesivos puede ser realizada por unidades de a bordo diferentes.

Los análisis a realizar buscarán encontrar tanto tendencias en la evolución de ciertos parámetros como

correlaciones entre pares de parámetros que indiquen aumento de la probabilidad de fallo o de avería

del vehículo.

El software resultante debe tener en cuenta todas estas consideraciones y debe permitir estudiar cada

vehículo por separado.

1.3 Alcance

Este proyecto se divide en varias partes.

Se comenzará detallando la situación actual, aportando una pequeña introducción sobre los

antecedentes.

Después se describirá en profundidad el problema que se aborda.

A continuación, se hará un planteamiento del diseño del software, introduciendo las herramientas

utilizadas y comparándolas con otras similares.

Seguidamente, se detallará la implementación desarrollada para materializar el diseño planteado en

el punto anterior.

En el siguiente punto se comentarán las pruebas de ejecución y validación realizadas para corroborar

el buen funcionamiento de la aplicación y su comportamiento en diferentes situaciones de

funcionamiento.

Por último, se expondrán las conclusiones y se describirán posibles líneas de futuro y algunas vías

para la continuación del proyecto.

Además, al final del documento se incluirán anexos que ilustren la configuración del software

desarrollado y las herramientas asociadas así como manuales de usuario.

3

2 ESTADO DEL ARTE

n este apartado se realiza una introducción al tema desarrollado en el proyecto, describiendo la

situación actual y los últimos avances pero añadiendo, además, algunas pinceladas sobre su

historia y cómo se ha llegado al punto en que se encuentra actualmente.

2.1 Antecedentes

El mantenimiento predictivo [3] se describe como una técnica para pronosticar cada posible punto de

fallo de los componentes de una máquina con la suficiente antelación como para que pueda evitarse,

minimizando los tiempos muertos y maximizando el tiempo de vida útil del equipo.

Las primeras labores de ingeniería de mantenimiento surgieron de la mano de la revolución industrial,

ya que comenzó a ser necesaria la realización de tareas de mantenimiento correctivo (para reaprar

averías) y, años más tarde, preventivo (siguiendo lo más fielmente posible las recomendaciones de los

fabricantes con el objetivo de alargar la vida útil de la maquinaria); pero no fue hasta mediados-finales

del siglo XX cuando nació el concepto de mantenimiento predictivo como tal, dando lugar a la

formación de entidades reguladoras como la EFNMS [1] en 1970.

Aunque comenzó siendo aplicable únicamente a la maquinaria industrial, con el vertiginoso ritmo de

los avances de las nuevas tecnologías apoyado por la creciente popularidad del IOT [4] y, más

recientemente, del IOE [4], su uso se ha ido extendiendo a otros campos como la aeronáutica, la

automoción, el transporte, la gestión de las ciudades y el soporte energético, entre otros.

2.2 Situación actual

Actualmente, existen numerosas técnicas aplicables a la realización del mantenimiento predictivo.

Puesto que este proyecto está enfocado en el mantenimiento predictivo de vehículos, en lo que resta

de apartado nos centraremos en ese punto.

Los análisis realizados en las labores de mantenimiento predictivo de vehículos son muy variados,

E

Your first projects aren’t the greatest things in the

world and they may have no money value, they

may go nowhere, but that is how you learn – you

put so much effort into making something right if it

is for yourself.

- Steve Wozniak -

Read more at:

http://www.scotsman.com/news/interview-steve-

wozniak-co-founder-of-apple-computers-1-2479194 -

Estado del arte

4

4

pues en los posibles riesgos influyen numerosos parámetros, ya sean de forma directa o indirecta.

Algunos de estos análisis incluyen la monitorización de la cantidad de combustible, la temperatura del

aceite o del líquido refrigerante, la carga del alternador, la presión del sistema de aire comprimido,

entre otros.

Cada vez son más las empresas dedicadas al sector que se unen a este tipo de proyectos desarrollando

sus propias soluciones: Dynafleet de Volvo Truks [6], la solución OnCommandTM Connection [7] de

Navistar, Proactive Solutions de Goodyear [8], y muchas otras más.

Así, en vista de las tendencias actuales en el análisis de parámetros para el fin que nos ocupa,

seguiremos en esa línea a la hora de desarrollar el software objeto de este proyecto.

5

3 DESCRIPCIÓN DEL PROBLEMA

ste proyecto pretende proporcionar una herramienta que permita estudiar el comportamiento de

una flota de vehículos basándose en el análisis de los valores que van tomando en el tiempo

una serie de parámetros.

Cada uno de los vehículos de la flota se encuentra equipado con una unidad de a bordo, que será la

encargada de recopilar los datos objeto de nuestro estudio. Estas unidades de a bordo no están

asignadas a un vehículo en particular; son extraíbles e intercambiables, por lo que se deberá indicar a

qué vehículo corresponde cada toma de datos.

Con respecto a la recopilación de datos, esta se lleva a cabo en intervalos de tres minutos separados

por pausas de veinte segundos. La información recabada se almacena en ficheros de extensión “csv”

con una nomenclatura que permite identificar tanto a la unidad de a bordo que ha recogido el conjunto

de datos como la fecha y hora de inicio de la recogida.

La nomenclatura empleada para identificar los archivos de datos que se generan es la siguiente:

UUUU- ANDDHHMM.csv

Donde:

UUUU son cuatro dígitos que identifican a la unidad de a bordo que ha tomado las medidas.

A es un dígito que identifica el año, contando a partir de 2010.

N es una letra entre la “A” y la “L” que representa el mes del año, sabiendo que la A

corresponde a enero, la B a febrero, etc.

DD son dos dígitos que identifican el día del mes.

HH, dos dígitos que representan la hora.

MM, dos dígitos que corresponden a los minutos.

E

Be less curious about people and more curious

about ideas.

- Marie Curie -

Descripción del problema

6

6

Así, por ejemplo, para una medición de datos tomada por la unidad de a bordo con identificador 1495

el día 1 de marzo de 2017 a las 20:42, el nombre del fichero sería 1495-7C012042.csv .

En el interior de cada uno de estos ficheros, los datos se estructuran siguiendo siempre el formato

“Time”; “SPN”; “ECU”; “Value”. La columna “Time” representa, con una precisión de 10 -4

segundos, el instante de tiempo en que se ha tomado la medida (relativo a la hora dada en la

nomenclatura descrita anteriormente), “SPN” corresponde al identificador del parámetro en cuestión

y “Value” al valor que toma dicho parámetro en el instante indicado. Por último, el valor del campo

“ECU” muestra la dirección de enlance de la ECU 1 origen del mensaje. No puede haber dos ECU con

la misma dirección en el bus CAN.

Dado el gran volumen de información que se genera, no es conveniente guardar los datos al completo;

resulta más eficiente almacenar únicamente los resultados de su análisis.

Las operaciones a realizar sobre los datos recogidos tendrán como finalidad principal hallar patrones

de comportamiento que permitan, entre otras cosas, la detección de averías o la realización de un

mantenimiento predictivo de los vehículos.

1 La ECU (Electronic Control Unit) es el dispositivo que controla uno o más sistemas eléctricos en un vehículo.

7

4 DISEÑO DE LA SOLUCIÓN

n este capítulo se va a describir el diseño del software encargado de dar solución al problema

planteado en el punto anterior.

Se decidió desarrollar el sistema sobre una plataforma de mensajería distribuida, de forma que ésta

hiciera de nexo entre las entidades que envían la información y las que deben procesarla.

A continuación se detallarán las características de la herramienta escogida para ese fin y se mostrará un estudio

comparativo con otras herramientas similares. Posteriormente, se describirán los demás componentes

involucrados en la herramienta diseñada.

4.1 Sistema de mensajería distribuido

Un sistema de mensajería es responsable de la transferencia de datos entre dos aplicaciones, de forma

que éstas sólo tengan que preocuparse de los datos pero no de cómo compartirlos.

Un sistema de mensajería distribuido se basa en el concepto de gestión de colas de mensajes fiable.

Los mensajes se encolan de forma asíncrona entre las aplicaciones cliente y sistema de mensajería:

una vez que el mensaje ha sido publicado por el emisor, los suscriptores pueden recibir el mensaje

seleccionado.

Los dos patrones más seguidos son el punto a punto y el de publicación-suscripción.La diferencia es

que con el primero cada mensaje llega a un solo consumidor y posteriormente desaparece, mientras

que con el segundo un mismo mensaje puede llegar a distintos consumidores.

4.1.1 Patrón publicador-suscriptor

El patrón publicador-suscriptor [9], también conocido como patrón observador, define una

dependencia de uno a muchos entre objetos, de modo que cuando un objeto cambie de estado se

notifique y se actualicen automáticamente todos los que dependen de él.

Este patrón modela pasos de mensajes donde:

El emisor no envía directamente a los suscriptores y no tiene por qué conocerlos.

Los mensajes se clasifican, permitiendo a los suscriptores recibir únicamente mensajes de su interés.

E

Experiments are intended to teach, and not to

mystify.

- William Sturgeon -

Diseño de la solución

8

8

4.1.2 Apache Kafka

La herramienta diseñada se sustenta sobre Apache Kafka [10], un sistema distribuido de mensajería

que sigue el modelo publicador-suscriptor. Kafka, que fue desarrollado por LinkedIn y posteriormente

adoptado por Apache Software Foundation, es una herramienta ampliamente usada como sistema de

almacenamiento en proyectos relacionados con Big Data. Las características que han hecho de ella la

mejor opción para este proyecto son:

Elevado nivel de disponibilidad y persistencia: al ofrecer replicación a través del clúster,

previene la pérdida de datos

Escalabilidad: el número de topics, publicadores y suscriptores puede modificar sin que el

rendimiento de la herramienta se vea afectado.

Gran rendimiento tanto para los publicadores como para los suscriptores, siendo capaz de

manejar hasta terabytes de datos sin presentar caídas en el sistema.

Tolerancia a fallos: gracias al balanceo de carga, a la existencia de particiones y a la replicación.

Aunque no es objeto de este proyecto el estudio en profundidad de este sistema, se van a detallar

algunos conceptos relacionados con su estructura y su funcionamiento en pro de comprender más

fácilmente otros elementos que se presentarán en los puntos sucesivos.

Los principales elementos que conforman la estructura de Kafka son:

Kafka Cluster: Almacena los flujos de datos en sus nodos o brokers, clasificándolos en

categorías llamadas topics.

Producers: Son las entidades que envían el flujo de mensajes al clúster de Kafka.

Consumers: Son los elementos que se suscriben a los topics de Kafka para extraer los

mensajes.

La siguiente imagen presenta a grandes rasgos la organización de los elementos anteriores:

Ilustración 1: Componentes básicos de Apache Kafka

9

9 Sistema de ayuda al análisis de datos distribuido para el mantenimiento predictivo de flotas de vehículos

Como se ha mencionado anteriormente, los productores (Producers) asocian a un topic cada mensaje

que envían al clúster y los consumidores deben suscribirse a un topic determinado en función del flujo

de mensajes que desee recibir. Cada mensaje es enviado como un array de bytes y puede asociarse a

él una clave que permitiría identificar y diferenciar ciertos mensajes o grupos de mensajes.

A continuación se presentan gráficamente los conceptos presentados en el párrafo anterior, mostrando

cómo los productores envían mensajes a distintos topics, cómo estos mensajes se replican a lo largo

de las distintas particiones y cómo los consumidores se suscriben a los topics para recibir determinados

flujos de mensajes:

Ilustración 2: Funcionamiento de Kafka

Cabe destacar que es posible crear grupos de consumidores para conseguir balanceo de carga, de forma

que el flujo de mensajes de un determinado topic se distribuye entre los consumidores que formen

parte del grupo suscrito sin que dos de ellos reciban el mismo mensaje.

4.1.3 Zookeeper

Zookeeper [11] es quien hace posible el funcionamiento del clúster de Kafka, ya que es un servicio

que permite la coordinación de procesos en grandes sistemas distribuidos e implementa gestión de

grupos y protocolos de elección de líder. Zookeeper gestiona los brokers y guarda los topics

pertenecientes a cada bróker y el offset de cada combinación “Consumer/topic/partición” en un espacio

jerárquico de nombres.


10

10

El funcionamiento conjunto de Zookeeper y Kafka sería el siguiente:

Ilustración 3: Arquitectura completa de Kafka

Como se puede observar, Zookeeper es quien coordina los brokers: cuando se añade o se

produce la caída de algún bróker, tanto productores reciben una notificación del evento y

Zookeeper reestructura el sistema de forma transparente al resto de componentes sin que el

servicio se vea afectado lo más mínimo.

4.1.4 Análisis de alternativas

La elección de una herramienta frente a las demás se basa en el objetivo principal del proyecto. En este

caso, buscamos una herramienta flexible, rápida y capaz de soportar grandes flujos de datos

simultáneos sin pérdida de información. En la siguiente tabla se muestra una comparativa entre Apache

Kafka, RabbitMq y Redis.

11


Apache Kafka RabbitMQ Redis

Utilidad Bus de mensajes

optimizado para

flujos de datos de

alto ingreso y

reproducción

Plataforma de mensajería

sólida y de propósito

general que soporta

varios protocolos

estandarizados como

AMQP

Almacén de

estructuras de datos

en memoria,

utilizado como base

de datos, caché y

agente de mensajes.

Licencia Open Source:

Apache License 2.0

Open Source: Mozilla

Public License

Open Source:

three clause BSD

license

Paralelismo Si No No

Persistencia Si Si No

Escrito en Scala (JVM) Erlang ANSI C

APIs para

cliente

Ruby, Python,

Node.js y Java

Ruby, Python, Node.js,

Clojure, Go, Java y C

Bash, C, C++,

Erlang, Java, Pascal,

Perl, PHP, Python,

Ruby, Scala, y

muchos más

Tabla 1: Comparativa plataformas de mensajería distribuida

4.2 Diseño de los componentes

Una vez explicado el funcionamiento de la plataforma de mensajería, en este apartado se

describirán los requisitos de diseño que corresponden a los componentes que interactuarán con

dicha plataforma: el productor y el consumidor.

Para empezar, se plantearán los requisitos generales asociados al componente. Dichos requisitos

irán encapsulados en tablas con el siguiente formato:

IDENTIFICADOR Nombre del requisito

Dependencias Identificadores de otros requisitos de los que depende o con los que

está directamente relacionado.

Descripción Explicación de en qué consiste el requisito

Tabla 2: Modelo tabla de requisitos

Posteriormente se detallarán las distintas acciones asociadas a dicho componente mediante

diagramas de flujo.

Para finalizar, se ilustrará el funcionamiento global del segmento de software en cuestión gracias

a un diagrama de secuencia.


12

12

4.2.1 Diseño del productor

Como se ha explicado anteriormente, los productores de Apache Kafka son los componentes

encargados de enviar información a los topics.

A continuación se detallarán los requisitos o condiciones que debe respetar la implementación de

este componente del software.

4.2.1.1 Requisitos generales

RGEN_PROD_01 Fichero de configuración

Dependencias RGEN_PROD_02

Descripción Debe haber un fichero de configuración, Producer.config, que

proporcione los siguientes parámetros a la aplicación encargada de

coordinar a los productores:

Apache Kafka

o IP del servidor

o Puerto asociado

Zookeeper

o IP del servidor

o Puerto asociado

Topics

o Un par “topic = ruta_ficheros_de_Datos” por cada

unidad de a bordo operativa.

Tabla 3: Requisito general productor 01 "Fichero de configuración"

RGEN_PROD_02 Número de Topics activos

Dependencias RGEN_PROD_01, RGEN_PROD_03

Descripción Debe haber un topic por cada unidad de a bordo operativa, siendo el

nombre del topic el identificador de dicha unidad.

Tabla 4: Requisito general productor 02 "Número de topics activos"

RGEN_PROD_03 Número de Productores activos


Descripción Debe existir una relación uno-uno entre el número de productores

activos y el número topics existentes.

Tabla 5: Requisito general productor 03 "Número de Productores activos"

RGEN_PROD_04 Escalabilidad

13



Descripción El aumento o disminución de la necesidad de productores activos no

afectará al rendimiento de la aplicación.

Tabla 6: Requisito general productor 04 "Escalabilidad"

RGEN_PROD_05 Paralelismo


Descripción Debe crearse un proceso para cada productor, de forma que se ejecuten

en paralelo.

Tabla 7: Requisito general productor 05 "Paralelismo"

RGEN_PROD_06 Lectura y envío de datos


Descripción La lectura de datos de los ficheros csv debe realizarse en bloques de 1Mb

para su posterior envío al topic correspondiente

Tabla 8: Requisito general productor 06 "Lectura y envío de datos"

RGEN_PROD_07 Identificador de mensaje


Descripción El identificador de cada mensaje enviado al topic (campo ‘key’) debe

corresponderse con la fecha de toma de datos del fichero leído, de

forma que el consumidor pueda identificar el set de datos al que

corresponden los valores recibidos.

Tabla 9: Requisito general productor 07 "Identificador de mensaje"

RGEN_PROD_08 Comprobación de fecha y hora


Descripción Antes de proceder a la lectura y envío de los datos de un fichero se

debe comprobar que la marca de tiempo correspondiente a su toma de

datos no presenta valores incoherentes.

Tabla 10: Requisito general productor 08 "Comprobación de fecha y hora"

RGEN_PROD_09 Ficheros leídos


Descripción Los ficheros leídos, tanto los válidos como los no válidos, se moverán

a un subdirectorio “Sent_Files” para evitar que sean procesados de

nuevo.


14

14

Tabla 11: Requisito general productor 09 "Ficheros leídos"

4.2.1.2 Casos de uso

CU_PROD_01 Recarga del fichero de configuración


Descripción Cuando se modifique el fichero de configuración se debe enviar una

señal de aviso al proceso principal para que regargue la configuración

y actúe en consecuencia.

Tabla 12: Caso de uso productor 01 "Recarga del fichero de configuración"

4.2.1.3 Detalle del comportamiento

Este subapartado contiene una serie de diagramas de flujo que que describirán en detalle los

componentes del diseño elegido para el productor, finalizando con un diagrama de secuencia que

aúne la interacción global entre dichos componentes.

Para empezar, el siguiente diagrama ilustra el funcionamiento del módulo encargado de coordinar

a los productores del escenario:

15


Ilustración 4: Diagrama de flujo "Coordinación productores"


16

16

A continuación se ilustrará el funcionamiento de los procesos “productor” a los que hace alusión

el diagrama de flujo anterior:

Ilustración 5: Diagrama de flujo “Ejecución proceso productor simple”

17


Por último, el siguiente diagrama de secuencia describe el funcionamiento conjunto del componente:

Ilustración 6: Diagrama de secuencia "Ejecución productor"

4.2.2 Diseño del Consumidor

En cuanto al consumidor, que será el componente encargado de extraer la información del topic y

de procesarla posteriormente, se pueden especificar una serie de requisitos o restricciones que debe

cumplir el software.


18

18

4.2.2.1 Requisitos generales

RGEN_CONS_01 Fichero de configuración global

Dependencias RGEN_CONS_02, RGEN_CONS_10,

Descripción La herramienta debe poseer un fichero de configuración que

proporcione los siguientes datos:

Apache Kafka

o IP del servidor

o Puerto asociado

Base de datos

o IP del servidor

o Nombre de la base de datos

o Nombre de usuario

o Contraseña

Topics

o Tantos pares “topic = ruta_fichero_config_topic”

como sean necesarios.

Tabla 13 : Requisito general consumidor 01 "Fichero de configuración Global"

RGEN_CONS_02 Número de consumidores activos

Dependencias RGEN_CONS_01, RGEN_CONS_03, RGEN_CONS_05

Descripción El número de consumidores en ejecución, que deberá coincidir con

el número de topics activos, vendrá determinado por el fichero de

configuración Consumer.config

Tabla 14 : Requisito general consumidor 02 "Número de consumidores activos"

RGEN_CONS_03 Paralelismo

Dependencias RGEN_CONS_02

Descripción Debe crearse un proceso para cada consumidor, de forma que se

permita su ejecución en paralelo.

Tabla 15 : Requisito general consumidor 03 "Paralelismo"

19


RGEN_CONS_04 Fichero de configuración del topic

Dependencias RGEN_CONS_05, RGEN_CONS_07, RGEN_CONS_08,

RGEN_CONS_09, RGEN_CONS_10, RGEN_CONS_11

Descripción Cada topic tendrá asociado su propio fichero de configuración, que

contendrá las distintas operaciones a realizar sobre los datos leídos

así como los parámetros que caractericen estas operaciones. Si se

produce algún error en una operación, se guardará la descripción de

la incidencia en una tabla de logs

Tabla 16 : Requisito general consumidor 04 "Fichero de configuración del topic"

RGEN_CONS_05 Procesamiento de datos



Descripción Se añadirá una columna a cada set de datos con el objetivo de

identificar la fecha en que fueron tomados. Dicho valor se obtendrá

del identificador (campo key) de los mensajes recibidos.

Tabla 17 : Requisito general consumidor 05 "Procesamiento de datos"

RGEN_CONS_06 Intervalos de estudio variables



Descripción Los intervalos de tiempo de estudios no estarán limitados a la duración de

cada set de datos sino que se podrá establacer su amplitud en minutos,

indicándolo en el fichero de configuración del topic.

Tabla 18: Requisito general consumidor 06 "Intervalos de estudio variables"

RGEN_CONS_07 Recarga de la configuración de cada topic

Dependencias RGEN_CONS_04, RGEN_CONS_05

Descripción Las operaciones asociadas a cada topic, además de sus parámetros

correspondientes, se recargarán al recibir la señal SIGHUP una vez

se completen las operaciones en ejecución en ese instante, antes de

proceder a la siguiente lectura de datos.

Tabla 19 : Requisito general consumidor 07 "Recarga de la configuración de cada topic"


20

20

RGEN_CONS_08 Operación Derivada


Descripción El resultado será la derivada respecto al tiempo de un parámetro. Esta

operación estará caracterizada por los siguientes parámetros:

ID del vehículo del que se han tomado los datos

ID de la unidad de a bordo que ha recogido los datos

ID del parámetro sobre el que se va a realizar la operación

Fecha de inicio de la toma de datos

Duración del intervalo de análisis (en minutos)

Umbral de referencia para el estudio del parámetro

Criterio (exceso o defecto) de superación del umbral

Tabla 20 : Requisito general consumidor 08 "Operación Derivada"

RGEN_CONS_09 Operación Correlación


Descripción La operación de correlación, que dará como resultado el coeficiente de

correlación de dos parámetros y su diagrama de dispersión, vendrá

caracterizada por los siguientes parámetros:



ID de los dos parámetros sobre los que se va a realizar la operación



Umbral mínimo de aceptación para el coeficiente de correlación

Coeficiente para el descarte de valores

Tabla 21 : Requisito general consumidor 09 "Operación Correlación"

21


RGEN_CONS_10 Operación Evolución temporal


Descripción La operación de evolución temporal consistirá en representar los valores que

toma el parámetro frente a la escala de tiempo cuando cumpla la condición

establacida por el umbral y el criterio, es decir, cuando supere por exceso o

por defecto el umbral mencionado. Esta operación tomará los siguientes

parámetros:



ID del parámetro a estudiar



Normalización o no del resultado

Tabla 22 : Requisito general consumidor 10 "Operación Evolución temporal"

RGEN_CONS_10 Operación Evolución temporal condicionada


Descripción El resultado de esta operación será el diagrama de evolución temporal de un

parámetro condicionado a que otro parámetro supere o no un cierto umbral.

Tomará los siguientes parámetros:



ID de los dos parámetros involucrados



Normalización o no del resultado

Umbral de referencia para el segundo parámetro

Criterio (exceso o defecto) de superación del umbral

Tabla 23 : Requisito general consumidor 10 "Operación Evolución temporal condicionada"


22

22

RGEN_CONS_11 Operación Alarma


Descripción El resultado de esta operación será un registro en la tabla de alarmas si el

parámetro cumple una cierta condición.

Toma los siguientes parámetros:

ID de la unidad de a bordo que ha recogido los datos.




ID del parámetro estudiado

Descripción del suceso

Tabla 24: Requisito general consumidor 11 "Operación Alarma"

RGEN_CONS_12 Logs


Descripción Debe llevarse un registro en una tabla de logs que documente las operaciones

fallidas, ya sea por incumplimiento de las condiciones o por valores inválidos

en los datos.

Estos logs deberán incluir:

Marca de tiempo en la que se ha registrado el log.


ID de la unidad de a bordo que ha recogido los datos.

Marca de tiempo del inicio de la toma de datos.

Identificadores de los parámetros involucrados

Descripción del suceso.

Tabla 25 : Requisito general consumidor 12 "Logs"

4.2.2.2 Casos de uso

CU_CONS_01 Modificación de la configuración global


Descripción Cuando se modifique el fichero de configuración global, se debe enviar al

proceso principal la señal de aviso para que recargue los parámetros y actúe

en consecuencia.

Tabla 26: Caso de Uso consumidor 01 "Modificación de la configuración global”

23


CU_CONS_02 Modificación de la configuración de un topic


Descripción Cuando se modifique el fichero de configuración asociado a un

determinado topic se deberá enviar al proceso correspondiente a ese

topic una señal de aviso para que actualice los parámetros de

análisis.

Tabla 27: Caso de Uso consumidor 02 "Modificación de la configuración de un topic”

4.2.2.3 Detalle del comportamiento

En este subapartado se incluirán varios diagramas de flujo que ayuden a terminar de presentar cada

componente que forma parte diseño elegido para el consumidor, además de un diagrama de

secuencia que aúne la interacción global entre dichos componentes.

Para empezar, el siguiente diagrama ilustra el funcionamiento del módulo encargado de coordinar

a los consumidores del escenario:


24

24

Ilustración 7: Diagrama d flujo "Coordinación de consumidores"

25


El diagrama que sigue refleja el funcionamiento de los procesos “consumidor” a los que se hace

referencia en la figura anterior:

Ilustración 8: Diagrama de flujo "Ejecución consumidor simple"


26

26

Para finalizar este punto, se incluirán diagramas explicativos de las cinco operaciones de análisis

que se realizan sobre los datos:

Operación Derivada:

Ilustración 9: Diagrama de flujo "Derivada"

Operación Correlación

Ilustración 10: Diagrama de flujo "Correlación"

27


Operación Evolución temporal

Ilustración 11: Diagrama de flujo "Evolución temporal"

Operación Evolución temporal

condicionada

Ilustración 12: Diagrama de flujo "Evolución temporal

condicionada”


28

28

Operación Alarma:

Tabla 28: Diagrama de flujo "Alarma"

29

Con todo esto, el funcionamiento completo del software correspondiente al consumidor

queda reflejado en el siguiente diagrama de secuencia:

Ilustración 13: Diagrama de secuencia "Ejecución consumidor"

4.3 Diseño de la Base de Datos

En puntos anteriores se ha mencionado la necesidad de disponer de una base de datos donde

almacenar los resultados de las operaciones que se van realizando. La herramienta escogida para

desempeñar esta función es MySQL [9], una de las bases de datos relacionales de código abierto

más populares del mundo.

Las entidades que deberá almacenar esta base de datos serán los resultados de las operaciones

realizadas sobre los sets de datos recibidos por los consumidores, así como un registro de logs que

recoja los fallos que se produzcan.

Las tablas necesarias serán:


30

30

Derivada:

o Sus atributos serán el identificador del vehículo, el identificador de la unidad de a

bordo, la marca de tiempo (fecha y hora) de inicio de la toma de datos, la longitud

del intervalo de tiempo analizado (en minutos), el identificador del parámetro a

derivar, el umbral y el criterio aplicados (exceso o defecto) como condición para

realizar la operación, y una imagen que represente gráficamente la derivada.

o La clave primaria estará formada por el id del vehículo, la marca de tiempo, el

intervalo, y el identificador del parámetro.

Correlación:

o Los atributos de esta tabla serán el identificador del vehículo, el identificador de la

unidad de a bordo, la marca de tiempo (fecha y hora) de inicio de la toma de datos,

la longitud del intervalo de tiempo analizado (en minutos), el identificador de cada

uno de los dos parámetros involucrados, el coeficiente de correlación de Pearson y

la imagen que represente su diagrama de dispersión.

o La clave primaria estará formada por el id del vehículo, la marca de tiempo, el

intervalo y los identificadores de ambos parámetros.

Evolución:

o Sus atributos serán el identificador del vehículo, el identificador de la unidad de a

bordo, la marca de tiempo (fecha y hora) de inicio de la toma de datos, la longitud

del intervalo de tiempo analizado (en minutos), el identificador del parámetro, y la

imagen que represente gráficamente la evolución temporal.

o La clave primaria de esta tabla la formarán el id del vehículo, la marca de tiempo,

el intervalo y el identificador del parámetro.

Evolución_cond:

o Los atributos de esta tabla van a ser el identificador del vehículo, el identificador

de la unidad de a bordo, la marca de tiempo (fecha y hora) de inicio de la toma de

datos, la longitud del intervalo de tiempo analizado (en minutos), el identificador

del parámetro condicionado y el del condicionante, un indicador de si los valores

representados están normalizad os o no, el umbral y el criterio aplicados (exceso o

defecto), además de la imagen que represente gráficamente la evolución temporal.

o La clave primaria de esta tabla la formarán el id del vehículo, la marca de tiempo,

el intervalo, y los identificadores de ambos parámetro.

Alarma:

o Esta tabla estará compuesta pro los siguientes atributos: el identificador del

vehículo, el identificador de la unidad de a bordo, la marca de tiempo (fecha y hora)

de inicio de la toma de datos, la longitud del intervalo de tiempo analizado (en

minutos), el identificador del parámetro analizado y, por último, la descripción del

suceso.

o La clave primaria estará compuesta por el id del vehículo, la marca de tiempo, la

duración del intervalo y el identificador del parámetro en cuestión.

Logs:

o Los atributos de esta tabla serán un identificador autoincrementabla, la marca de

tiempo (fecha y hora) en la que se ha registrado el evento, el id de la unidad de a

31


bordo, la fecha de la toma de datos y un campo de texto que contenga la descripción

de dicho evento.

o La clave primaria estará compuesta únicamente por el identificador

autoincrementabla.

4.4 Diseño de la web de consulta de los resultados

Para facilitar y simplificar el filtrado y la visualización de los resultados obtenidos se ha optado por

una página web. Esta decision ha estado motivada por la versatilidad, facilidad de diseño y de

implementación de este tipo de herramientas.

La necesidad de una herramienta que permita la consulta de los datos se debe a que en la base de datos

las imágenes se guardan como arrays de bits, con lo cual no es possible su correcta visualización

directamente, sino que es necesario procesar estos arrays para volver a construir las imágenes.

La web presentará inicialmente un formulario donde se podrán seleccionar las opciones de filtrado,

como por ejemplo la operación cuyos datos deseamos consultar o las fechas de las tomas de datos.

Una vez se rellenen los campos deseados y se proceda al envío del formulario, se mostrará una tabla

con los resultados obtenidos, incluyendo las imágenes (si procede).

33

5 IMPLEMENTACIÓN

l objetivo de este capítulo será analizar la implementación del software. Se detallarán la

organización y funcionalidad de cada una de las distintas partes del código y se describirán

las tablas de la base de datos.

Python [13] es el lenguaje de programación escogido para llevar a cabo la implementación de

todos y cada uno de los componentes.

Como se mencionó en el punto de diseño, para el sistema de mensajería distribuido se utilizará la

API en Python de Apache Kafka, Kafka-python [13].

Al igual que en capítulos anteriores, dividiremos el contenido en varios apartados donde cada uno

de ellos corresponderá a un componente del software. Comenzaremos por el módulo del productor,

luego se detallará el código del consumidor y, por último, la implementación de la base de datos

y sus correspondientes tablas.

5.1 Implementación del Productor

Este apartado se dividirá en varios subapartados, donde cada uno de ellos detallará la

implementación de uno de los componentes pertenecientes al módulo que desempeña la función

de productor de Apache Kafka. La implementación del código se estructura de la siguiente forma:

Producer.config: Archivo de configuración.

MainProducer.py: Orquesta el escenario.

Producer.py: Contiene las funciones necesarias para implementar un productor simple.

5.1.1 Fichero de configuración Producer.config

El módulo encargado de coordinar el escenario a este lado de Apache Kafka necesita conocer

ciertos parámetros para asociar correctamente los procesos productores a la plataforma distribuida.

Estos datos los conseguirá a partir del fichero de configuración Producer.config, dividido en tres

secciones (entre corchetes), cuyo contenido será, a modo de ejemplo:

E

The science of today is the technology of tomorrow.

- Edward Teller -

Implementación

34

34

Como se puede observar, hay tres secciones claramente diferenciadas: Kafka-Server, Zookeeper y

Topics.

En cuanto a las propiedades de la sección Kakfa-Server:

Host: dirección del host que aloja el servidor de Kafka

Port: puerto asociado

La sección Zookeeper tiene las mismas propiedades que la anterior:

Host: dirección del host que aloja el servidor de Zookeeper


La última sección, Topics, contiene tantos pares “identificador=ruta” como unidades de a bordo haya

en funcionamiento donde el primer campo corresponde al identificador de la unidad de a bordo y el

sgundo a la ruta hacia el directorio donde se encuentran los ficheros de datos recogidos por esa unidad.

5.1.2 MainProducer

Es el motor del módulo productor. Su misión es coordinar y controlar todos los procesos encargados

de enviar información a los topics de Kafka, además de gestionar los topics activos, gracias a la

información obtenida del fichero de configuración detallado en la sección anterior. Debe encargarse

también de capturar la señal “SIGHUP” y, cuando esto suceda, cargar de nuevo la configuración

releyendo el fichero Producer.config.

Una vez ha recargado la configuración, debe:

Gestionar los topics existentes cerrando los que correspondan a unidades de a bordo inactivas

y creando uno por cada nueva unidad de a bordo en activo.

Ocuparse de los productores simples. Esta tarea consiste en mantener vivos los procesos

asociados a los productores vinculados a topics activos, matar los procesos asociados a topics

que han sido eliminados y crear un nuevo proceso de productor por cada topic que haya sido

creado tras la última recarga de configuración.

[Kafka-Server] host = localhost port = 9092 [Zookeeper] host = localhost port = 2181 [Topics] id_unidad_de_a_bordo_1 = ruta_ficheros_1 id_unidad_de_a_bordo_2 = ruta_ficheros_2 id…

Tabla 29: Contenido del fichero de configuración Producer.config

35


5.1.3 Producer

Este componente es el encargado de:

Crear y asociar un productor simple al servidor de Kafka especificado en el fichero de

configuración.

Comprobar validez de los ficheros de datos.

Leer datos de los ficheros y enviarlos al topic correspondiente utilizando la fecha de la toma

de datos, seguida del número de mensaje asociado a ese fichero entre paréntesis) como

identificador o key del mensaje. Por ejemplo, para envíos sucesivos de fragmentos del fichero

con fecha 7C011245, los identificadores serían 7C011245(0), 7C011245(1), etc.

Mover los ficheros leídos a la carpeta “Sent_Files”.

Además, cuenta con un manejador para la recepción de la señal de terminación de proceso (SIGTERM)

de forma que cuando esta sea recibida no termine de forma abrupta sino que lo haga cuando concluya

la lectura del fichero en curso, consiguiendo que no se trunque ni se pierda información.

5.2 Implementación del consumidor

Siguiendo en la línea del apartado anterior, a continuación se describirá la implementación del

consumidor diseñado. El contenido se dividirá en diversos subapartados según los módulos en los que

está dividido el código, los cuales son:

Consumer.config: Fichero de configuración principal

MainConsumer.py: Gestiona y coordina todos los módulos involucrados tanto en el proceso

de consumición de datos del servidor de Kafka como los encargados de procesar dichos datos.

[Topic].cfg: Fichero de configuración asociado al topic [Topic].

Consumer.py: Contiene las funciones necesarias para implementar un consumidor de Kafka,

suscribirlo a un topic y recibir datos de él.

Funciones.py: En este fichero se encuentran las funciones que se encargan de analizar los

datos.

Utiles.py: Este fichero incluye las funciones utilizadas por el software del consumidor que no

están orientadas al estudio de los datos.

Database.py: Facilita el acceso a la base de datos.

5.2.1 Fichero de configuración Consumer.config

Al igual que en el caso del módulo de gestión de los productores, el módulo encargado de coordinar

el escenario en el lado de los consumidores necesita conocer ciertos parámetros para poder hacerlo.

Estos datos los los consigue gracias al fichero de configuración Consumer.config, dividido en tres

secciones (entre corchetes).

A continuación se enuentra el contenido de este fichero, relleno con valores ficticios a modo de

ejemplo:

Implementación

36

36

Se distinguen tres secciones: Kafka-Server. Database y Topic.

Los atributos de la primera sección son:

Host: dirección del host que aloja el servidor de Kafka


En la sección Database los atributos corresponden a:

Host: dirección del host donde se encuentra la base de datos

Database: nombre de la base de datos

User: usuario propietario de la base de datos

Pass: contraseña del usuario

Por último, en las secciones TopicX, los parámetros serán:

Vehículo: matrícula del vehículo del que se han tomado los datos.

Path: ruta hacia el fichero de configuración asociado al topic.

[Kafka-Server]

host = localhost

port = 9092

[Database]

host = localhost

database = tfg

user = dit

pass = dit

[Topic1]

vehiculo = JVT2017

path = Topic1.cfg

[Topic2]

vehiculo = MPH1995

path = Topic2.cfg

[Topic..]

Tabla 30: Contenido del fichero de configuración "Consumer.config"

37


5.2.2 MainConsumer

Es núcleo del módulo del consumidor. Su misión es gestionar tanto los procesos encargados de extraer

y analizar la información de los topics de Kafka como el objeto encargado del acceso y manipulación

de la base de datos, ayudándose de los datos extraídos del fichero de configuración que se ha descrito

en la sección anterior. Debe encargarse también de recargar la configuración releyendo el fichero

Consumer.config cuando se reciba la señal “SIGHUP”.

Una vez se haya cargado la configuración, se ocupará de:

Actualizar la configuración relativa al acceso a la base de datos.

Cerrar aquellos procesos activos en los que el consumidor esté suscrito a un topic en desuso.

Mantener vivos los procesos vinculados a los topics que continúan activos.

Crear un proceso de consumidor por cada nuevo topic creado.

5.2.3 Ficheros de configuración [Topic].cfg

Estos ficheros contienen se dividen en tantas secciones, identificadas por un id independiente de la

implementacion, como operaciones distintas se desean realizar sobre los datos. Cada sección tendrá

un set de atributos personalizado en función de la operación a la que esté dedicada.

A continuación se presenta un fichero de ejemplo que muestra los distintos parámetros de las secciones

según el tipo de operación que se realiza. Los valores que rellenan los campos se han escogido a modo

de ejemplo:

Implementación

38

38

[ID_Operacion_1]

function = Derivada

SPNs = [92]

intervalo = 3

umbral = 60

criterio = False

[ID_Operacion_2]

function = Evolucion

SPNs = [1099,1100,1102]

normalizada = True

intervalo = 9

[ID_Operacion_3]

function = Correlacion

SPNs = [[90, 190],[183, 513],[190, 1717],[91, 512],[91, 513],[92, 183],[92, 512],[92, 513]]

umbral = 0.90

limite = 0.1

intervalo = 3

[ID_Operacion_4]

function = Evolucion_cond

SPNs = [[100, 190]]

umbral = 1000

criterio = True

normalizada = False

intervalo = 9

[ID_Operacion_5]

function = Alarma

SPNs = [168]

umbral = 27

criterio = False

intervalo = 3

Tabla 31: Fichero de configuración asociado a un topic

39


5.2.4 Consumer

Esta parte de la implementación es la encargada de interactuar con los topics de Kafka.

Comienza creando un consumidor y suscribiéndolo al topic cuyo identificador ha recibido como

parámetro.

Seguidamente, toma del fichero de configuración las operaciones que debe realizar sobre os datos que

reciba del topic al que se ha suscrito.

Por último, comienza un bucle infinito que consiste en:

1. Recibir mensajes de datos del topic hasta recomponer un set completo (mismo valor del campo

‘key’)

2. Comprobar que se ha recibido un set de datos completo, incluyendo las cabeceras.

3. Comprobar que se cumple alguno de los intervalos de estudio.

4. Operar sobre los datos, si el intervalo es válido.

5. Guardar los resultados en la base de datos haciendo uso de la clase Database, si el intervalo es

válido.

Este bucle se repite infinitamente a no ser que el topic de desactive, en cuyo caso se cerrará el

consumidor finalizando el proceso.

Debe encargarse también de recargar las condiciones de análisis releyendo su fichero de configuración

asociado cuando se reciba la señal “SIGHUP”.

Como la mayor parte de las operaciones tienen un resultado gráfico, se deben almacenar imágenes en

la base de datos. Para ello, ante la imposibilidad de almacenar las imágenes construidas, el resultado

de cada scatter plot (en el caso de la operación de derivada) o del plot (en el resto de operaciones) se

almacenará en un archivo png temporal que se destruirá automáticamente una vez se haya convertido

esa imagen png a un array de bits, que si es un formato apto. Para reconstruir la imagen a partir de una

consulta a la base de datos únicamente habría que invertir el proceso.

5.2.5 Database

La clase Database permite implementar objetos que se comuniquen con una base de datos, proporcionando

métodos capaces de interactuar con ella para:

Crear y borrar todas las tablas utilizadas por nuestro software para almacenar los resultados de los

análisis realizados sobre los datos, cuyos nombres son Logs, Derivada, Correlacion, Evolucion y

Evolucion_cond.

Insertar y guardar información en dichas tablas.

5.3 Base de datos

La base de datos, tal como se especificó anteriormente, contendrá las cuatro tablas necesarias para el

almacenamiento de los resultados del análisis de los datos: Alarma, Derivada, Correlación, Evolución

y Evolución_cond. Por otro lado, existirá también una tabla llamada Logs destinada al almacenamiento

de los avisos del programa, tales como sets de datos incompletos o incumplimiento de las condiciones

de alguna operación.

A continuación se describe la estructura de la base de datos, comenzando a grandes rasgos para luego

profundizar en cada uno de sus elementos.

Implementación

40

40

5.3.1 Estructura general

En cuanto a la estructura general de la base de datos, las relaciones de las que se hace usoen el

software desarrollado serán “alarma”, “correlación”, “derivada”, “evolución”, “evolución_cond” y

“logs”. Cada una de ellas almacena la información resultante de la operación de análisis de datos con

el mismo nombre.

Las relaciones mencionadas se presentan en la siguiente imagen:

Tabla 32: Estructura de la base de datos

Todas ellas comparten una serie de atributos: vehiculo, u_a_bordo,fecha_i, intervalo e imagen, los

cuales se corresponden, respectivamente, con el vehículo del que se han extraído los datos, la unidad

de abordo encagada de hacerlo, la fecha de inicio de la toma de datos, la duración del intervalo de

estudio, y la imagen que representa el resultado del análisis.

5.3.2 Tabla de correlación

La tabla de nombre “correlación” es, como su propio nombre indica, la encargada de almacenar los

datos resultants del análisis de correlación.

Sus atributos son vehículo, u_a_bordo, fecha_i, intervalo, SPN_1, SPN_2, umbral, corr_coef e imagen,

donde SPN_1, SPN_2, umbral y corr_coef corresponden respectivamente al identificador del primer

parámetro involucrado, el identificador del Segundo parámetro, el umbral mínimo que debe supercar

el coeficiente de correlación y el coeficiente de correlación.

Tabla 33: Estructura tabla "Correlacion"

41


5.3.3 Tabla de derivada

Esta tabla, que contiene los resultados del análisis de derivada, está compuesta por los siguientes

atributos: vehículo, u_a_bordo, fecha_i, intervalo, SPN, umbral, criterio e imagen. Los atributos SPN,

umbral y criterio representan el identificador del parámetro estudiado, el valor crítico para su estudio

y el criterio de superación a aplicar a ese valor (exceso o defecto) para la realización del análisis,

respectivamente.

Tabla 34: Estructura tabla "Derivada"

5.3.4 Tabla evolucion

La tabla evolucion contiene los atributos SPN y normalizado, que son el identificador del parámetro

estudiado y un indicador de si el resultado gráfico está normalizado o no.

Tabla 35: Estructura tabla "Evolucion"

5.3.5 Tabla evolucion_cond

Esta tabla corresponde al análisis de evolución condicionada.

Los atributos SPN_1 y SPN_2 hacen referencia, respectivamente, al parámetro a estudiar y al

parámetro que condiciona la realización o no de ese estudio. Por otro lado, los atributos normalizado,

criterio y umbral corresponden a si el resultado está normalizado o no, el criterio (exceso o defecto)

aplicado a la superación del umbral, y, por ultimo, el umbral crítico aplicado al parámetro

condicionante.

Implementación

42

42

Tabla 36: Estructura tabla "Evolucion_cond”

5.3.6 Tabla alarma

La siguiente relación se encarga de almacenar las alertas generadas por la operación de alarma. El

atributo SPN identifica al parámetro estudiado y descripción contiene la incidencia registrada.

Ilustración 14: Estructura tabla "Alarma"

5.3.7 Tabla logs

La última de las tablas, logs, almacena las incidencias registradas a lo largo de la realización de las operaciones

de análisis mencionadas anteriormente.

Sus atributos difieren de los que poseían las relaciones anteriores. El atributo id comienza en 0 y se va

autoincrementando con cada nuevo log registrado, fecha_log es la marca de tiempo en la que se registra el log,

funcion identifica a la operación con la que se relaciona la incidencia y descripcion contiene una breve

explicación del suceso.

Tabla 37: Estructura de la tabla de logs

43


5.4 Implementación de la web de consulta de los resultados

Como se mencionó en el apartado de diseño, se ha optado por una web para la visualización y filtrado

de los resultados.

Esta web tendrá dos componentes principales:

Formulario (Index.jsp): será la página inicial. Presentará una serie de opciones para filtrar los

contenidos.

Tabla de resultados (Consulta.py): esta página mostrará los resultados de la búsqueda.

Además, habrá un tercer fichero involucrado llamado spnslist.txt, que contiene todos los pares {id :

nombre} correspondientes a los parámetros que se estudian.

5.4.1 Formulario

El formulario será la página inicial de la web. Presenta una serie de campos que permitirán al usuario filtrar los

resultados. Dichos campos varían dinámicamente en función de la tabla elegida en la lista desplegable; por

ejemplo:

Tanto si la tabla elegida es “alarma” como si es “derivada”, se mostrarán como opciones de filtrado la

fecha, la hora, el nombre del vehículo, la unidad de a bordo, el intervalo, el umbral y el criterio aplicados,

y el identificador del parámetro estudiado.

Ilustración 15: Formulario Alarma / Derivada

Implementación

44

44

Si se escoge “correlación”, los campos que se mostrarán son la fecha, la hora, el nombre del vehículo,

la unidad de a bordo, el intervalo, el umbral aplicado, y los identificadores de los parámetros estudiados.

Ilustración 16: Formulario correlación

Para la opción de “evolución”, las opciones disponibles son la fecha, la hora, el nombre del vehículo, la

unidad de a bordo, el intervalo, si el resultado está normalizado o no, y el identificador del parámetro

estudiado.

Ilustración 17: Formulario evolución

45


En “evolución condicionada”, aparecen las opciones de filtrado de la fecha, la hora, el nombre del

vehículo, la unidad de a bordo, el intervalo, el criterio y el umbral aplicados, si está normalizado o no

el resultado, y los identificadores de los parámetros estudiados.

Ilustración 18: Formulario evolución condicionada

Por ultimo, si la opción elegida es “logs”, los campos que aparecen son: la fecha, la hora, el nombre del

vehículo, la unidad de a bordo, la función, y el identificador del parámetro estudiado.

Ilustración 19: Formulario logs

Implementación

46

46

5.4.2 Tabla de resultados

El formulario anterior redirige hacia esta segunda página, que se encarga de conectar con la base de

datos para realizar la consulta, teniendo en cuenta las condiciones seleccionadas, y de presentar los

resultados.

Como se comentó en puntos anteriores, las imágenes se guardan en la base de datos en formato de

arrays de bits, lo cual añade otra tarea a esta web, que consiste en restaurar dichas imágenes a su forma

original.

Los resultados se presentan en formato de tabla, incluyendo las imágenes, que aparecerán en miniatura

y se ampliarán al pulsar sobre ellas. Para devolverlas al tamaño en miniature habrá que pulsar sobre

ellas de nuevo.

Por ejemplo, si se realiza una consulta sobre la tabla de correlación, los resultados se muestran en una

tabla como la siguiente:

Ilustración 20: Consulta evolución I

Como se ha comentado, si se pulsa sobre la imagen, esta se amplía:

Ilustración 21: Consulta evolución II

47


Para finalizer, otro ejemplo sería realizar una consulta sobre la tabla de logs:

Ilustración 22: Consulta tabla de logs

49

6 PRUEBAS Y VALIDACIÓN

ste capítulo se centra en la descripción de las pruebas realizadas para simular escenarios reales,

cuyo objetivo es verificar la validez del diseño y la implementación realizadas. Estas pruebas se

realizarán en una máquina virtual Linux con Ubuntu instalado.

La versión de MySQL utilizada será la 14.14 Distrib 5.7.18.

Para Apache Kafka se usará la versión 2.10.

La instalación y configuración detallada de los componentes involucrados aparece documentada en el

Anexo A.

6.1 Puesta en marcha del escenario

Para poner en marcha el software, lo primero que se debe hacer es arrancar el servidor de Zookeeper

y el servidor de Apache Kafka, en este orden. Ambos se ejecutarán en la propia máquina.

Para arrancar Zookeeper se debe ejecutar el siguiente commando en una terminal, donde “/opt/kafka/”

es la ruta en la que se encuentra instalado Apache Kafka:

/opt/kafka/bin/zookeeper-server-start.sh /opt/kafka/config/zookeeper.properties

Para arrancar el servidor de Kafka, el commando a ejecutar es:

/opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/server.properties

El segundo paso es cumplimentar los ficheros de configuración, tanto Producer.config como

Consumer.config y los propios de cada topic ( [Topic].cfg). Además, debemos crear un usuario en

MySQL y una base de datos, que serán los utilizados por el software. Para las pruebas usaremos un

usuario dit con contraseña dit, y una base de datos cuyo nombre será tfg.

El siguiente paso a seguir será iniciar el productor principal:

python MainProducer.py

Por último, ejecugaremos el consumidor principal, MainConsumer.py:

python MainConsumer.py

E

Science is about knowing;

engineering is about doing.

- Henry Petroski -

Pruebas y validación

50

50

Una vez seguidos estos pasos, se tiene el escenario completo en funcionamiento por lo que se puede

proceder a la realización de pruebas. Estas pruebas consistirán en:

Modificación del fichero de configuración Producer.config

Detección de archivo inválido

Modificación del fichero de configuración Consumer.config

Modificación del fichero de configuración de un topic.

Procesamiento de datos correctos

Procesamiento de datos erróneos

Consulta de los resultados

6.2 Prueba 01: Modificación del fichero de configuración Producer.config

Esta prueba tiene el objetivo de comprobar el correcto funcionamiento de la recarga de configuración

en el productor principal, MainProducer.

Se comenzará arrancando MainProducer para que inicie tres procesos paralelos, uno para cada

productor, asociados a los topics 1495, 1496 y 1497. Como se puede observar en la siguiente imagen,

existe un proceso principal de MainProducer y de él nacen 3 subprocesos, que corresponderían a los

antes mencionados.

Ilustración 23: Prueba 01 "Procesos iniciales I"

El propio MainProducer imprime también la información relativa a estos subprocesos, incluyendo

además la del propio proceso principal:

Ilustración 24: Prueba 01 "Procesos iniciales II"

Cada uno de estos subprocesos está asociado a uno de los topics mencionados anteriormente. La existencia de

dichos topics se comprueba fácilmente:

Ilustración 25: Prueba 01 "Topics iniciales"

Una vez que se encuentra el escenario en funcionamiento, se modificará el número de topics añadiendo

uno nuevo con identificador 1498, y a continuación se enviará al proceso la señal SIGHUP para que

recargue la configuración.

51


En las siguientes imágenes se presenta el resultado: al recibir la señal, MainProducer crea un nuevo

proceso de Producer asociado al topic 1498.

Ilustración 26: Pueba 01 "Procesos tras primera recarga de configuración I"

Este evento también se notifica en la salida del proceso principal:

Ilustración 27: Prueba 01 "Procesos tras primera recarga de configuración II"

Se puede comprobar, además, la existencia del nuevo topic:

Ilustración 28: Prueba 01 "topics tras primera recarga de configuración"

Por último, se realizará el proceso inverso: se eliminarán del fichero de configuración los topics 1495

y 1497 y se enviará de nuevo una señal SIGHUP al proceso principal. Se comprobará que los procesos

asociados a los topics eliminados de la configuración desaparecen, al igual que los topics

correspondientes de Apache Kafka se destruyen.

. Ilustración 29: Prueba 01 "Procesos tras la segunda recarga de configuración I"

El proceso principal también realiza notificaciones sobre los procesos terminados y los topics que han sido

eliminados:


52

52

Ilustración 30: Prueba 01 "Procesos tras la segunda recarga de configuración II"

Por último se comprueba que los topics asociados a los productores finalizados han sido eliminados:

Ilustración 31: Prueba 01 "Topics tras la segunda recarga de configuración"

6.3 Prueba 02: Archivo csv inválido

Esta prueba es simple: entre los archivos a procesar por el productor asociado al topic 1496,

incluiremos uno con un título inválido. El productor deberá detectar la anomalía y notificar la

incidencia por pantalla. Como se puede observar, el fichero no pasa la comprobación de fecha, con lo

cual es movido a la carpeta Sent_Files sin ser procesado:

Ilustración 32: Prueba 02 "Archivo csv inválido"

6.4 Prueba 03: Modificación del fichero de configuración Consumer.config

La prueba que se va a realizar a continuación es muy similar a la primera prueba: se va a comprobar

el buen funcionamiento de la recarga del fichero de configuración de MainConsumer,

Consumer.config.

Inicialmente se arrancará el programa principal para que despliegue tres consumidores asociados a los

topics 1495, 1496 y 1497, respectivamente.

53


Ilustración 33: Prueba 03 "Procesos iniciales I"

Al igual que como ocurría con MainProducer, el proceso principal del Consumidor también informa

sobre la creación y destrucción de procesos:

Ilustración 34: Prueba 03 "Procesos iniciales II"

A continuación, se va a eliminar el consumidor asociado al topic 1495 del fichero de configuración

Consumer.config, y se va a enviar la señal de recarga al programa principal.

Ilustración 35: Prueba 03 "Procesos tras primer cambio de configuración I"

Ilustración 36: Prueba 03 "Procesos tras primer cambio de configuración II"

Por último, se van a añadir dos consumidores más al fichero de configuración, recuperando el

eliminado en el punto anterior y añadiendo uno nuevo suscrito al topic 1498.

Ilustración 37: Prueba 03 "Procesos tras segundo cambio de configuración"


54

54

6.5 Prueba 04: Modificación fichero de configuración de topic

En esta prueba se van a introducir cambios en el fichero de configuración de un topic durante el

funcionamiento del consumidor para verificar que en la primera iteración tras la recepción de la señal

de recarga se aplican automáticamente los cambios.

El resultado se comprobará mostrando el contenido de las tablas, listando todas las columnas excepto

la encargada de almacenar la imagen en forma de array de bits.

En la operación de evolución temporal se van a realizar modificaciones en dos parámetros: el intervalo

y la normalización; en cuanto al primero, se modificará pasando de valer 6 minutos a 3 minutos, y en

cuanto al segundo, pasará de no pedir la normalización de los resultados a hacerlo.

Tabla 38: Prueba 04 "Modificación parámetros del análisis de evolución"

En la operación de correlación se va a modificar el umbral mínimo de aceptación para el coeficiente,

pasando de 0.70 a 0.90. Como se puede observar el cambio se aplica inmediatamente en el análisis del

segundo set de datos:

Tabla 39: Prueba 04 "Modificación parámetros del análisis de correlación"

55


Por último, en la operación derivada se modificará el umbral crítico para la realización del análisis, que pasará

de 40 a 60:

Ilustración 38: Prueba 04 "Modificación parámetros del análisis de derivada"

6.6 Prueba 05: Procesamiento de datos correctos que no cumplen las condiciones

En este apartado de pruebas se van a procesar normalmente datos de diversos topics. Serán datos

correctos pero habrá casos en los que el par escogido para la operación de correlación no cumpla con

el umbral mínimo establacido. En ese caso, deberá añadirse una tupla a la tabla de logs describiendo

la incidencia.

Tabla 40: Prueba 05 "Procesamiento de datos correctos"

6.7 Prueba 06: Procesamiento de datos incorrectos

Esta última prueba consistirá en procesar un set de datos incompleto, donde alguno de los parámetros

que se quieren procesar no tiene datos asociados. En caso de que esto ocurra, debe insertarse una tupla

en la tabla de logs describiendo la irregularidad encontrada.

Para esta prueba se ha escogido un set de datos donde no existen valores para el parámetro 190.


56

56

Tabla 41: Prueba 06 "Procesamiento de datos incorrectos"

6.8 Resultados

Para finalizar este apartado de pruebas y validación, se van a mostrar algunos de los resultados y

gráficos obtenidos de los análisis y pruebas descritos anteriormente.

Estos resultados se visualizarán con la ayuda de la web desarrollada para este propósito.

6.8.1 Alarma

Un ejemplo de análisis de este tipo sería guardar un aviso cuando el valor del parámetro 168 desciende de 30.

Ilustración 39: Resultados Alarma 01

6.8.2 Correlación

A continuación se van a presentar algunos de los gráficos resultantes del análisis de correlación

efectuado sobre los parámetros.

En primer lugar, se muestra el diagrama de dispersión [15] entre los parámetros 191 y 904, quen tiene

un coeficiente de correlación de 0.999718, lo que indica que están altamente relacionados entre sí. Este

grado de relación se manifiesta gráficamente en que es directamente proporcional a la cercanía entre

los puntos y a la rectitud de de la línea que dibujan.

57


Ilustración 40: Resultados Correlación 01

Para contrastar, se incluye ahora el resultado de una correlación de coeficiente 0.705569, realizada

entre los parámetros 92 y 513.

Ilustración 41: Resultados Correlación 02


58

58

6.8.3 Derivada

La representación gráfica de la derivada o pendiente del parámetro es otro de los resultados que se

obtienen.

Por ejemplo, la gráfica de la derivada del parámetro 92 respecto al tiempo en un intervalo de tres

minutos cuando supera el valor 60:

Ilustración 42: Resultado Derivada 01

Para el mismo parámetro y con el análisis sujeto a las mismas condiciones, en el intervalo siguiente la

gráfica quedaría de la siguiente forma:

Ilustración 43: Resultado Derivada 02

59


6.8.4 Evolución temporal

A continuación se presenta la evolución temporal normalizada del parámetro 1099 durante 6 minutos

sería.

Ilustración 44: Resultado Evolución temporal 01

6.8.5 Evolución temporal condicionada

Para finalizar, la siguiente imagen representa la evolución temporal del parámetro 100 en los instantes

en que el 190 supera el valor 1000.

Ilustración 45: Resultado evolución temporal condicionada 01


60

60

61

7 CONCLUSIONES Y POSIBLES LÍNEAS DE

FUTURO

ras haber investigado y recabado información acerca del objeto de nuestro estudio para poder

llevar a cabo el desarrollo del presente proyecto software, el siguiente paso es estudiar el

resultado y expresar las conclusiones obtenidas, aportando además ideas o propuestas de mejora

así como posibles líneas futuras de investigación.

7.1 Conclusiones

Una vez se han realizado la exposición y el análisis de los resultados obtenidos, comenzaremos por

fijarnos en los objetivos iniciales para sacar unas primeras conclusiones. Por tanto, podemos afirmar

que se han cumplido los principales objetivos del proyecto:

Se ha desarrollado un sistema ágil, capaz de procesar grandes volúmenes de datos en paralelo

a muy alta velocidad.

El software es configurable y reconfigurable a lo largo de todo su ciclo de vida, de manera al

modificar sus parámetros se adapta y actualiza su comportamiento para satisfacer las nuevas

restricciones.

A partir de los resultados del estudio de los datos se pueden obtener patrones de

comportamiento, dependencias entre parámetros, tendencias, etc. que permitan, tras estudios

posteriores, parametrizar el comportamiento de un vehículo y utilizarlo para realizar un

mantenimiento predictivo.

La satisfacción de estos objetivos nos lleva a plantear nuevas conclusiones. Gracias a este proyecto

deja de ser imprescindible almacenar en la base de datos todos los valores de las tomas de medidas,

ya que únicamente se almacenan los parámetros del análisis y sus resultados. Esto supone un gran

ahorro tanto en tiempo como en recursos, reduciendo notablamente la carga de la base de datos.

T

Sometimes when you innovate, you make mistakes.

It is best to admit them quickly, and get on with

improving your other innovations.

- Steve Jobs -

Conclusiones y posibles líneas de futuro

62

62

7.2 Posibles líneas futuras

Es evidente que, al igual que cualquier otro software, este proyecto irá sufriendo modificaciones a lo

largo del tiempo en pro de optimizarlo y de mejorarlo, añadiendo nuevos métodos de análisis, por

ejemplo.

En cuanto a posibles líneas de futuro, existen diversas posibilidades.

Una posible alternativa consiste en que, aunque este proyecto ha sido desarrollado y enfocado al

estudio de una flota de autobuses, con mínimas modificaciones podría ser aplicable a otros conjuntos

de vehículos o máquinas.

Otro camino de continuación sería continuar con el procesamiento de los datos. Los resultados

obtenidos a partir de los análisis realizados por este software podrían ser estudiados para hallar

patrones de comportamiento que permitan realizar el mantenimiento predictivo sobre los elementos

en cuestión.

Por último, otra posible vía de mejora sería el uso de versiones más actualizadas de Apache Kafka o

la adaptación del software a otros motores de bases de datos.

63

REFERENCIAS

[1] «European Federation of National Maintenance Societies,» [En línea]. Available:

http://www.efnms.eu/about-us/what-does-efnms-stand-for/.

[2] «Preditec - conceptos Mantenimiento predictivo,» [En línea]. Available:

http://www.preditec.com/mantenimiento-predictivo/.

[3] K. H. Adjallah, Advances in Degradations Monitoring and Predictive Maintenance, 2007.

[4] «IOT,» [En línea]. Available: https://www.t-systemsblog.es/revolucion-iot-empresas/.

[5] «IOE,» [En línea]. Available: https://www.t-systemsblog.es/iot-ioe/.

[6] «Volvo Truks,» [En línea]. Available: http://www.volvotrucks.es/es-es/services/fleet-management.html.

[7] « Navistar IOT,» [En línea]. Available: http://www.ciospain.es/industria-y-utilities/navistar-acelera-sus-

proyectos-de-iot-y-vehiculos-conectados.

[8] «Proactive Solutions,» [En línea]. Available: http://www.ciospain.es/industria-y-utilities/goodyear-

disena-una-solucion-para-gestionar-flotas-basada-en-el-analisis-de-big-data.

[9] «Patrón publicador-suscriptor,» [En línea]. Available:

https://es.wikipedia.org/wiki/Observer_(patr%C3%B3n_de_dise%C3%B1o).

[10] «Apache Kafka Distributed Streaming Platform,» [En línea]. Available:

https://kafka.apache.org/documentation/.

[11] «Apache Zookeeper,» [En línea]. Available: https://zookeeper.apache.org/.

[12] «MySQL,» [En línea]. Available: https://www.mysql.com/.

[13] «Python doc,» [En línea]. Available: http://docs.python.org.ar/tutorial/3/real-index.html.

[14] «Kafka-python,» [En línea]. Available: https://github.com/dpkp/kafka-python.

[15] «Diagrama de dispersión,» [En línea]. Available: https://prezi.com/5eypa4mnrlz7/diagrama-de-

dispersion-scatter-plot/.

Referencias

64

64

65

ANEXO A: INSTALACIÓN Y CONFIGURACIÓN DEL

ESCENARIO

En este anexo se detallan los pasos a seguir para la instalación y configuración de los distintos

elementos que participan en el escenario escogido para desarrollar y probar el software.

PYTHON

Lo primero será instalar Python. Para el desarrollo de esta herramienta se ha usado la versión 2.7.

Una vez hecho esto, deberán instalarse las librerías necesarias:

APACHE KAFKA Y ZOOKEEPER

Para seguir, se debe instalar el software de Apache Kafka. Para ello se ejecutarán los siguientes

comandos:

# Se descarga la versión de Apache Kafka a instalar

wget http://apache.uvigo.es/kafka/0.10.2.0/kafka_2.10-0.10.2.0.tgz

# Se descomprime, se renombra el directorio resultante y se mueve a /opt

tar -xvf kafka_2.10-0.10.2.0.tgz

mv kafka_2.10-0.10.2.0 kafka

mv kafka /opt

sudo apt-get install Python

sudo pip install mysql-connector==2.1.4

sudo pip install matplotlib

sudo pip install protobuf

sudo pip install MySQL-python

sudo apt-get install –y python-tk

http://apache.uvigo.es/kafka/0.10.2.0/kafka_2.10-0.10.2.0.tgz

Anexo A: Instalación y configuración del escenario

66

66

A continuación, para permitir la eliminación de topics y para aumentar el tamaño máximo de los

mensajes que puede recibir Kafka, se añadirán las siguientes líneas al fichero

config/server.properties:

Para arrancar el servidor, suponiendo que Kafka está instalado en /opt, los comandos a utilizar

serán (situándonos en el directorio /opt/kafka ):

bin/zookeeper-server-start.sh config/zookeeper.properties

bin/kafka-server-start.sh config/server.properties

Para parar el servidor, suponiendo que Kafka está instalado en /opt, los comandos a utilizar

serán (situándonos en el directorio /opt/kafka ):

bin/kafka-server-stop.sh

bin/zookeeper-server-stop.sh

MYSQL

En este apartado se detallará la instalación del motor de base de datos utilizado, MySQL.

Para comenzar, se instala el servidor de mysql:

A continuación se crearán un usuario y una base de datos, que serán los que utilizará el software.

sudo apt-get update

sudo apt-get install mysql-server –y

delete.topic.enable=true

message.max.bytes=104857600

replica.fetch.max.bytes=107374182

max.message.bytes=104857600

git clone https://github.com/mumrah/kafka-python

pip install ./kafka-python

67


SERVIDOR WEB

Para poder desplegar la web será necesario un servidor. En este caso se ha utilizado Tomcat en su

versión 7.0.

Para la instalación del servidor, debe ejecutarse:

En cuanto a la configuración del servidor, por un lado debe modificarse el archivo server.xml,

añadiendo un contexto (dentro de la etiqueta Host) para la aplicación a desplegar. En este caso, el

nombre del directorio que contiene la aplicación web a servir es TFG_Monica, que se encuentra

dentro del directorio /tmp/, y se accederá a ella con el alias “/Appweb”:

mysql

# Se crea el usuario ‘dit’ con contraseña ‘dit’

CREATE USER 'dit'@'localhost' IDENTIFIED BY 'dit';

# Se crea la base de datos ‘tfg’

CREATE DATABASE tfg;

# Se conceden permisos al usuario sobre la base de datos

GRANT ALL ON tfg.* TO 'dit'@'localhost';

# Para acceder con el usuario creado

mysql –u dit –p

# Para acceder a la base de datos creada

USE tfg;

sudo apt-get install tomcat7

<Host name="localhost" appBase="webapps"

unpackWARs="true" autoDeploy="true">

...

<Context path="/AppWeb"

docBase="/tmp/TFG_Monica/"

debug="0"

reloadable="true"

privileged="true"/>

</Host>

Anexo A: Instalación y configuración del escenario

68

68

Por otro lado debe modificarse el archivo web.xml permitiendo el uso de CGI y especificando un

alias para acceder a la ruta “/WEB-INF/cgi”, que en este caso ha sido “cgi-bin”. Las líneas a

añadir a dicho archivo son:

:

Los archivos que componen la web estarán situados en la jerarquía del directorio web de la

siguiente forma:

Una vez realizadas todas estas configuraciones, se incia el servidor:

sudo service tomcat7 start

/TFG_Monica

\_ index.jsp

\_ spnlist.txt

\_ /META-INF

\_ /WEB-INF

\_ /cgi

\_ consulta.py

<servlet>

<servlet-name>cgi</servlet-name>

<servlet-class>org.apache.catalina.servlets.CGIServlet</servlet-class>

<init-param>

<param-name>cgiPathPrefix</param-name>

<param-value>WEB-INF/cgi</param-value>

</init-param>

<init-param>

<param-name>executable</param-name>

<param-value></param-value>

</init-param>

<load-on-startup>5</load-on-startup>

</servlet>

<servlet-mapping>

<servlet-name>cgi</servlet-name>

<url-pattern>/cgi-bin/*</url-pattern>

</servlet-mapping>

69


Para acceder a la aplicación web, debe introducirse la siguiente url en el navegador, suponiendo

que la app se despliega en la propia máquina, localhost:

http://localhost:8080/AppWeb/index.jsp

En caso de que se desplegara en otra máquina, habría que sustituir ‘localhost’ por la dirección IP

de la máquina en cuestión.

71

ANEXO B: MANUAL DE USUARIO

Este anexo pretende explicar cómo utilizar la herramienta desarrollada.

Se divide en dos categorías principales: el Productor y el Consumidor.

PRODUCTOR

En este apartado se detalla la configuración y uso del componente asociado al productor de Kafka.

o Fichero de configuración

Este componente de la herramienta posee un único fichero de configuración:

Producer.config. El esquema de este fichero es el siguiente, donde los valores entre

paréntesis deben sustituirse por los valores deseados:

o Ejecución

Para arrancar el Productor se debe usar el siguiente comando:

python MainProducer.py

[Kafka-Server]

host = (DireccionServidorDeKafka)

port = (PuertoAsociadoAlServidorDeKafka)

[Zookeeper]

host = (DireccionServidorDeZookeeper)

port = (PuertoAsociadoAlServidorDeZookeeper)

[Topics]

(IdTopic1) = (RutaHaciaFicherosTopic1)

(IdTopic2) = (RutaHaciaFicherosTopic2)

(…) = (…)

Anexo B: Manual de Usuario

72

72

o Recargar configuración

Para que se recargue la configuración asociada al Productor se debe usar el siguiente

comando, donde PID es el identificador del proceso principal asociado a

MainProducer.py:

kill –s HUP PID

CONSUMIDOR

En este apartado se detalla la configuración y uso del componente asociado al consumidor de

Kafka.

o Fichero de configuración general

A continuación se presenta la estructura del fichero de configuración general,

Consumer.config. Los valores entre paréntesis deben sustituirse por los valores que

desee el usuario.

[Kafka-Server]

host = (DireccionServidorDeKafka)

port = (PuertoAsociadoAlServidorDeKafka)

[Database]

host = (DireccionServidorBaseDeDatos)

database = (NombreBaseDeDatos)

user = (NombreUsuario)

pass = (Contraseña)

[(IdTopic1)]

vehiculo = (MatrículaVehículo1)

path = (RutaFicheroConfiguracionTopic1)

[(IdTopic2)]

vehiculo = (MatrículaVehículo2)

path = (RutaFicheroConfiguracionTopic2)

73


o Fichero de configuración de topic

El fichero de configuración asociado a cada topic está formado por tantas secciones

como se quiera, cuyo nombre es indiferente a la ejecución del programa, donde cada

una de ellas representa un análisis a realizar sobre los parámetros.

A continuación se presentan los distintos tipos de análisis que se pueden realizar, y las

opciones asociadas a ellos:

[id1]

function = Derivada

SPNs = [(spn1), (spn2), ...]

intervalo = (Periodo de tiempo de duracion del analisis (minutos))

umbral = (Valor limite para el estudio del parámetro)

criterio = (El umbral se debe superar por exceso/defecto (True/False))

[id2]

function = Evolucion

SPNs = [(spn1), (spn2),...]


normalizada = (Devolver resultado con valores normalizados o no (True/False))

[id3]

function = Evolucion_cond

SPNs = [[(spn1),(spn_condicion)],[(otro par)], ..]


umbral = (Valor limite del segundo parametro utilizado como condición)

criterio = (Superar umbral por exceso/defecto (True/False))

normalizada = (Devolver resultado con valores normalizados o no (True/False))

[id4]

function = Correlacion

SPNs = [[(spn1),(spn2)],[(otro par)], ..]


umbral = (Valor minimo de aceptacion par el coeficiente de correlación)

limite = (valor entre 0 y 1 que marca el porcentaje de valores a descartar en relacion al valor máximo)

[id5]

function = Alarma

SPNs = [(spn1), (spn2), ...]


umbral = (Valor critico para el estudio del parámetro)

criterio = (El umbral se debe superar por exceso/defecto (True/False))

Anexo B: Manual de Usuario

74

74

o Ejecución

Antes de arrancar el Consumidor, se debe preparar el entorno de ejecución:

export MPLBACKEND="Agg"

Para arrancar el Consumidor principal se debe usar el siguiente comando:

python MainConsumer.py

o Recargar configuración

Tanto para recargar la configuración asociada al Consumidor principal como la

configuración asociada a un topic se debe usar el siguiente comando, donde PID es el

identificador del proceso principal asociado a MainConsumer.py o del proceso

encargado de recibir mensajes de ese topic, respectivamente:

kill –s HUP PID

Trabajo Fin de Grado -...

Documents

Transcript of Trabajo Fin de Grado -...