TFG Alejandro Cantero Casares

ESCUELA TÉCNICA SUPERIOR DE
INGENIERÍA Y SISTEMAS DE
TELECOMUNICACIÓN
PROYECTO FIN DE GRADO
TÍTULO: Arquitectura Big Data para el procesamiento de señales en

industria 4.0
AUTOR: Alejandro Cantero Casares
TITULACIÓN: Ingeniería Telemática
TUTOR: Gregorio Rubio Cifuentes
DEPARTAMENTO: Ingeniería Telemática y Electrónica (DTE)
VºBº
Miembros del Tribunal Calificador:
PRESIDENTE: Antonio Pérez Yuste
TUTOR: Gregorio Rubio Cifuentes
SECRETARIO: Carlos Ramos Nespereira
Fecha de lectura: 26 de junio de 2019
Calificación:
El Secretario,
1
Agradecimientos
En primer lugar, me gustaría agradecer a mis padres el esfuerzo que han realizado durante
todos estos años para que yo pueda estar aquí escribiendo estas líneas, gracias por vuestros
consejos, por vuestra preocupación y por aguantarme cuando, durante este largo camino, los
resultados no eran los esperados, por fin lo conseguimos.
A mi hermana por su apoyo, por su ayuda en la asignatura de inglés y por sacarme unas
sonrisas en los momentos difíciles.
A mis abuelos gracias por vuestra preocupación durante toda mi carrera, gracias por todos
esos rezos que habéis realizado en cada examen para que consiguiese aprobarlos, parece que
han funcionado.
A Nerea, ya que ha sido un pilar en el que apoyarme durante todos estos años, gracias por tu
ayuda, por las tardes de estudio, por haber aguantado los enfados cuándo los exámenes no
me salían como esperaba y por siempre confiar en mí.
A Álvaro y Carlos gracias por los consejos, por las charlas cerveza en mano y, en definitiva,
gracias por el día a día, no sé si sin vosotros hubiese acabado antes la carrera o la hubiese
abandonado, pero de lo que si estoy seguro es que hubiese sido mucho más aburrida.
Y por último agradecer a Gregorio por el interés mostrado durante todo el proyecto y por su
ayuda durante este tiempo.
Todos vosotros formáis parte de esta carrera.
¡Gracias!
2
3
Resumen
Este proyecto se centra en el diseño e implementación de una arquitectura Big Data dirigida
hacia las industrias que se encuentran inmersas en la modernización de sus fábricas debido
a la cuarta revolución industrial. Esta cuarta revolución industrial viene dada por la
aplicación de las tecnologías más innovadoras en las fábricas con el objetivo de modernizar
la monitorización de los procesos industriales.
Para el diseño de dicha arquitectura se han investigado diferentes tecnologías punteras
dedicadas a las funciones necesarias dentro del tratamiento de datos en Big Data: ingesta de
datos, transporte, procesamiento, almacenamiento y representación.
Asociado al desarrollo de la arquitectura y con el objetivo de verificar su correcto
funcionamiento se ha diseñado una simulación visual que representa la generación de datos
que produciría una fábrica real.
Se ha realizado la simulación de un proceso industrial dentro de una fábrica embotelladora
que se encarga de empaquetar diferentes tipos de botellas diferenciando las que estén en
buen estado y descartando las que sufren alguna tara. Dentro de este proceso se tiene la
posibilidad de manejar datos como las velocidades de producción, los pesos de botellas y
cajas, los indicadores de cada tipo de botella o el número de botellas empaquetadas.
Gracias a esta arquitectura y a su correspondiente simulación se ha podido comprobar la
posibilidad real de manejar una gran cantidad de datos con tiempos de refresco del orden de
los milisegundos, procesarlos y representarlos.
Este proyecto dotaría de una nueva herramienta a las industrias. Quienes la poseyeran
tendrían un valor diferencial frente a las empresas que no contaran con ella, ya que
conocerían a tiempo real el estado de su fábrica y podrían comprobar la evolución de sus
procesos industriales a lo largo del tiempo. Estos indicadores se traducirían en reducción de
costes ya que el empresario podría anticiparse a los fallos de la maquinaria y en caso de
producirse se indicaría en tiempo real cual ha sido el fallo y su causa, por otro lado, también
implicaría un incremento de la productividad ya que el empresario podría analizar los datos
históricos y comprobar en que época y porqué disminuye la producción.
4
5
Abstract
This project focuses on designing and implementing a Big Data architecture aimed at
industries that are immersed in the modernization of their factories because of the fourth
industrial revolution. This fourth industrial revolution is due to the application of the most
innovative technologies in the factories in order to modernizing the monitoring of industrial
processes.
For the design of this architecture, different leading technologies dedicated to the necessary
functions in the data processing in Big Data have been investigated: data ingestion, transport,
processing, storage and representation.
Associated with the development of the architecture and with the objective of verifies correct
functioning, a visual simulation has been designed that represents the generation of data that
could be produced by a real factory
The simulation of an industrial process has been developed which is responsible for
packaging different types of bottles, differentiating between the ones that are in good
condition and discarding those that presents any defect. During the process you have the
possibility of handling data such as production speeds, the weights of bottles and boxes, the
indicators of each type of bottle or the number of bottles packaged.
With this architecture and its corresponding simulation, it has been possible to verify the real
possibility of managing a large amount of data with minimal refresh times, process and
represent them.
This project would provide a new tool to industries. Those who owned it, would have a
differential value compared to companies that did not have it, because they would know in
real time the state of their factory and could check the evolution of their industrial processes
over time. These indicators would translate into cost reduction because the businessman
could anticipate the failures of the machinery and in case of occurrence it would be indicated
in real time which has been the failure and its cause, on the other hand would also imply an
increase in the productivity since the entrepreneur could analyze the historical data and check
when and why production decreases.
6
7
Índice de contenidos
1. Introducción ................................................................................................................. 16
2. Marco Tecnológico ...................................................................................................... 18
2.1 Arquitecturas Big Data .......................................................................................... 18
2.1.1 Arquitectura Lambda ..................................................................................... 18
2.1.2 Arquitectura Kappa ........................................................................................ 19
2.2 Tecnologías Big Data ............................................................................................ 21
2.2.1 Simuladores industriales ................................................................................ 22
2.2.2 Servidores OPC.............................................................................................. 23
2.2.3 Ingesta/Acceso datos...................................................................................... 24
2.2.4 Plataforma de Streaming ................................................................................ 27
2.2.5 Procesado en tiempo real ............................................................................... 29
2.2.6 Persistencia de datos ...................................................................................... 30
2.2.7 Representación de datos................................................................................. 31
3. Especificaciones y restricciones de diseño .................................................................. 36
3.1 Simuladores industriales ....................................................................................... 36
3.2 Servidor OPC ........................................................................................................ 36
3.3 Ingesta/Acceso datos ............................................................................................. 37
3.4 Plataforma de Streaming ....................................................................................... 37
3.5 Procesado en tiempo real ...................................................................................... 37
3.6 Persistencia de datos ............................................................................................. 38
3.7 Representación de datos ........................................................................................ 39
4. Descripción de la solución propuesta .......................................................................... 42
4.1 Anylogic ................................................................................................................ 42
4.1.1 Descarga y configuración .............................................................................. 42
4.2 KEPServerEX ....................................................................................................... 45
4.3 Apache Nifi ........................................................................................................... 50
4.4 Apache Kafka ........................................................................................................ 52
4.5 Implementación Prototipo 0 .................................................................................. 54
4.5.1 Anylogic......................................................................................................... 54
4.5.2 KEPServerEX ................................................................................................ 59
4.5.3 Apache Nifi .................................................................................................... 59
4.5.4 Apache Kafka ................................................................................................ 68
8
4.6 Apache Flink ......................................................................................................... 68
4.6.1 Descarga y configuración............................................................................... 69
4.7 InfluxDB................................................................................................................ 71
4.8 Implementación Prototipo 1 .................................................................................. 71
4.8.1 Apache Flink .................................................................................................. 71
4.8.2 InfluxDB ........................................................................................................ 73
4.9 Grafana .................................................................................................................. 74
4.10 Implementación Versión definitiva ................................................................... 77
4.10.1 Dashboard TFGCajas ................................................................................. 77
4.10.2 Dashboard TFGBotellas ............................................................................. 80
5. Conclusiones ................................................................................................................ 86
6. Trabajos futuros ........................................................................................................... 88
7. Presupuesto .................................................................................................................. 90
7.1 Costes ......................................................................................................................... 90
7.1.1 Costes software .............................................................................................. 90
7.1.2 Costes mano de obra ...................................................................................... 90
7.2 Presupuesto total.................................................................................................... 91
8. Referencias ................................................................................................................... 92
9
Índice de figuras
Figura 1. Arquitectura Lambda.................................................................................. 19

Figura 2. Arquitectura Kappa .................................................................................... 20
Figura 3. Elementos Arquitectura TFG....................................................................... 21
Figura 4. Aspecto visual Anylogic ............................................................................. 22
Figura 5. Interfaz gráfico Vijeo Citect ........................................................................ 23
Figura 6. Representación editor programación Node-Red ............................................. 25
Figura 7. Interfaz visual StreamSets ........................................................................... 26
Figura 8. Editor web Apache NIFI ............................................................................. 27
Figura 9. Precios Google Pub/Sub ............................................................................. 28
Figura 10. Esquema Publicador/Suscriptor ................................................................. 29
Figura 11. Representación de datos con Apache Zeppelin ............................................ 32
Figura 12. Representación de datos en Kibana ............................................................ 33
Figura 13 Interfaz visual Grafana .............................................................................. 34
Figura 14. Comparación velocidad InfluxDB vs Cassandra .......................................... 38
Figura 15. Comparación compresión InfluxDB vs Cassandra ....................................... 39
Figura 16. Tecnologías definidas en la Arquitectura .................................................... 40
Figura 17. Elementos principales ventana Anylogic ..................................................... 42
Figura 18. Ventana de configuración de un agente ....................................................... 43
Figura 19. Ventana de configuración Simulation ......................................................... 44
Figura 20. Ventana principal KEPServerEX ............................................................... 45
Figura 21. Configuración canal TFG .......................................................................... 46
Figura 22. Configuración PLC_Fábrica ...................................................................... 47
Figura 23. Configuración Tags .................................................................................. 48
Figura 24. Configuración dirección del servidor OPCUA ............................................. 49
Figura 25. Configuración dirección OPCUA ............................................................... 50
Figura 26. Arquitectura Apache Nifi .......................................................................... 51
Figura 27. Fichero configuración Apache Nifi ............................................................ 51
Figura 28. Fichero configuración Kafka ..................................................................... 53
Figura 29. Comandos para la creación de los topics ..................................................... 53
Figura 30. Parte visual simulación industria ................................................................ 55
Figura 31. Parte lógica simulación industria ............................................................... 56
Figura 32. Instancia productor Kafka ......................................................................... 56
Figura 33. Envío de una señal en el proceso moveTo1 ................................................. 57
Figura 34. Creación cliente KEPServerEX ................................................................. 57
Figura 35. Fichero propiedades consumidor kafka ....................................................... 58
Figura 36. Codificación escritura en KEPServerEX ..................................................... 58
Figura 37. Señales creadas en KEPServerEX .............................................................. 59
Figura 38. Interfaz web Apache Nifi .......................................................................... 60
Figura 39. Ventana de selección de procesos .............................................................. 60
Figura 40. Ventana de configuración publish Kafka..................................................... 61
Figura 41. Configuración nifi-processor-archetype ...................................................... 62
Figura 42. Diagrama clases nifi-anylogic-processor ..................................................... 63
Figura 43. Inicialización proceso nifi ........................................................................ 64
Figura 44. Definición función OnEnabled .................................................................. 65
Figura 45. Acciones función onSubscriptionValue ...................................................... 66
Figura 46. Codificación función onTrigger ................................................................. 66
Figura 47. Propiedades Opc Subscriptor ..................................................................... 67
10
Figura 48. Propiedades Opc Subscriptor .................................................................... 67
Figura 49. Valores obtenidos en Kafka de la simulación de Anylogic ............................ 68
Figura 50. Arquitectura Flink.................................................................................... 69
Figura 51. Fichero configuración flink-conf.yaml ....................................................... 70
Figura 52. Interfaz Web Apache Flink ....................................................................... 70
Figura 53. Diagrama de clases job Flink .................................................................... 72
Figura 54. Definición clase principal Flink ................................................................. 72
Figura 55. consumerConfig.properties ....................................................................... 73
Figura 56. influxConfig.properties ............................................................................ 73
Figura 57. Configuración InfluxDB ........................................................................... 74
Figura 58. Query señal botellasATotales .................................................................... 74
Figura 59. Fichero configuración grafana (Seguridad) ................................................. 75
Figura 60. Fichero de configuración grafana(Dirección ip) .......................................... 75
Figura 61. Representación visual Grafana .................................................................. 75
Figura 62. Configuración InfluxDB en Grafana .......................................................... 76
Figura 63. Configuración plugin D3Gauge ................................................................. 77
Figura 64. Configuración Plugin Table ...................................................................... 78
Figura 65. Configuración Plugin Pie Chart TFGCajas ................................................. 79
Figura 66. Dashboard TFGCajas ............................................................................... 80
Figura 67. Selector de tiempo Grafana ....................................................................... 80
Figura 68. Configuración PieChart TFGBotellas ......................................................... 81
Figura 69. Configuración plugin Graph ...................................................................... 82
Figura 70. Configuración Plugin Singlestat ................................................................ 83
Figura 71. Dashboard TFGBotellas ........................................................................... 83
Figura 72. Estimación fases del proyecto ................................................................... 90
11
Índice de tablas
Tabla 1. Costes asociados al software necesario para el desarrollo del proyecto .............. 90
Tabla 2. Estimación fases del proyecto (horas) ........................................................... 90
Tabla 3. Costes asociados a la mano de obra ............................................................... 91
Tabla 4. Presupuesto total proyecto ........................................................................... 91
12
13
Lista de acrónimos
• CEO: Chief Executive Officer

• OLE: Object Linking and Embedding
• OPC: OLE for Process Control
• PLC: Programmable Logic Control
• NOSQL: No Structured Query Language
• SQL: Structured Query Language
• GO: Open Source Programming Language
• OPC DA: OPC Data Access
• OPC HDA: OPC Historical Data Access
• OPC A&E: OPC Alarms and Events
• MQTT: Message Queue Telemetry Transport
• SSL: Secure Sockets Layer
• HTTP: Hypertext Transfer Protocol
• LDAP: Lightweight Directory Access Protocol
• HDFS: Hadoop Distributed File System
• API: Application Programming Interface
• RDD: Resilent Distributed Dataset
• YARN: Yet Another Resource Negotiator
• CQL: Cassandra Query Language
14
15
INTRODUCCIÓN
1. Introducción
En la actualidad estamos inmersos en la cuarta revolución industrial también conocida como

industria 4.0, esta revolución consiste en la introducción del mundo digital en las fábricas.
Para poder llevar a cabo esta digitalización los ingenieros se tienen que apoyar en tecnologías
punteras como el IoT, Big Data, Cloud Computing y robótica con el objetivo de que las
fábricas sean capaces de generar un flujo regular de información que pueda ser tratado
posteriormente.
Tradicionalmente las empresas habían dado mucha importancia a conseguir perfeccionar sus
procesos de fabricación, tener las mejores máquinas, los mejores materiales y de esa manera
reducir costes y mejorar la calidad de sus productos, sin embargo, la entrada de las nuevas
tecnologías en la última década ha supuesto un cambio de mentalidad para este sector.
En la actualidad los CEO (Chief Executive Officer) han comenzado a entender la importancia
no solo de su proceso de fabricación, sino de los datos que generan dichos procesos y están
apostando por invertir dinero en conseguir mejores maneras de obtener, procesar y usar
dichos datos para mejorar la calidad de sus fábricas.
El problema que ha intentado resolver la tecnología en este sentido es la manera de obtener
dicho flujo de datos de manera eficiente. Habitualmente los datos se obtenían para conseguir
estadísticas de la fábrica. Para este uso podían permitirse que el flujo de datos tuviese alta
latencia, sin embargo, en la actualidad para poder monitorizar una fábrica con el objetivo de
saber lo que está ocurriendo en tiempo real en ella se necesitan procesar un gran número de
señales con tiempos de refresco muy cortos.
Este proyecto fin de grado se enmarca en dicha situación y se centra en el diseño y la
implementación de una arquitectura Big Data que permita obtener datos de diversas fuentes
y procesarlos para su posterior representación.
Para el desarrollo de la arquitectura hay que tener en cuenta los siguientes aspectos:
• Ingesta de datos: para lo que hay que seleccionar y configurar un servidor
OPC (OLE (Object Linking and Embedding) for Process Control) y
conectarlo con el sistema del cual recibirá los datos.
• Transporte de datos: esta parte es clave, ya que hay que manejar una cantidad
grande de datos con tiempos de refresco muy bajos, es decir, para esta función
hay que estar siempre preparado para recibir datos.
• Almacenamiento: una base de datos que permita unos tiempos de lectura y
escritura muy rápidos.
• Visualización de resultados: utilización de una interfaz amigable que de
manera simple presente los resultados del procesado de los datos a los
operarios.
Para terminar el desarrollo del proyecto la arquitectura se acompañará de la implementación
de un simulador industrial para que podamos comprobar el funcionamiento de la arquitectura
y no solo quedarnos en un estudio meramente teórico. Se debe buscar un simulador industrial
que pueda conectarse a un servidor OPC y simular el funcionamiento de los PLCs
(Programmable Logic Control) así como una interfaz visual que permita distinguir
perfectamente las diferentes partes de un proceso industrial.
16
INTRODUCCIÓN
El primer capítulo de este proyecto estará centrado en el estado del arte, en este capítulo se
estudiarán las diferentes arquitecturas Big Data existentes y se definirá el diseño que tendrá
la arquitectura a definir en este proyecto. Una vez decidida se pasará al estudio de las
diferentes tecnologías que la compondrán haciendo un estudio de las diferentes tecnologías
existentes para cada función dentro de la arquitectura.
El segundo capítulo será el de las especificaciones y restricciones del diseño, es decir, una
vez comparadas las tecnologías estudiadas en el capítulo anterior se decidirá cuál es la que
mejor se adecúa a nuestra arquitectura y por qué.
El tercer capítulo se compondrá de la descripción de la solución propuesta, para documentar
y desarrollar la arquitectura se irán definiendo diferentes prototipos del sistema en los que
se irán aumentando la cantidad de componentes y funcionalidades hasta llegar a la solución
final. En cada apartado de este capítulo se definirá la configuración de las tecnologías que
componen cada prototipo, una vez configuradas se pasará a la implementación necesaria
para su posterior comunicación dentro de cada prototipo.
En el cuarto y quinto capítulo se expondrán las conclusiones a las que se han llegado una
vez desarrollado todo el proyecto, así como unos posibles futuros pasos para mejorar la
arquitectura.
Y por último el sexto capítulo servirá para definir el presupuesto necesario en el caso de
proceder a la implementación de dicho sistema.
17
MARCO TECNOLÓGICO
2. Marco Tecnológico
En este capítulo se va a realizar un repaso a las arquitecturas y tecnologías que se están

utilizando actualmente en el mundo de la industria y del Big Data. Estas tecnologías se
compararán para buscar sus puntos fuertes y débiles hasta encontrar las que más se adapten
a la arquitectura a definir.
2.1 Arquitecturas Big Data
Como respuesta a la necesidad de recoger un gran volumen de datos de las empresas y

procesarlos para obtener información valiosa de ellos lo antes posible se comenzaron a
desarrollar diferentes arquitecturas Big Data.
En la actualidad las arquitecturas más comunes en los proyectos Big Data son la arquitectura
Lambda y la arquitectura Kappa.
2.1.1 Arquitectura Lambda
[1] [2] En abril de 2015 Nathan Marz escribió el libro [3] en él explica en profundidad la
arquitectura Lambda que fue definida en 2012. Fue creada gracias a la experiencia de Nathan
en sistemas de tratamiento de datos distribuidos durante su estancia como empleado en las
empresas Backtype y Twitter.
Dicha arquitectura es la primera que define como, usando juntos el procesamiento batch que
es el procesamiento de datos haciendo agrupaciones temporales y streaming que es el
procesado de un flujo continuo de datos en tiempo real se pueden resolver un gran número
de casos de uso. El objetivo era obtener un sistema robusto tolerante a fallos, escalable y que
permitiese realizar escrituras y lecturas con baja latencia. El modo batch nos aporta acceso
a históricos de datos lo que consigue la integridad de los mismos, mientras que, el modo
stream nos da los datos en línea para decisiones instantáneas. [4]
Como se puede observar en la Figura 1 la arquitectura Lambda se basa en la descomposición
del problema en tres capas: batch layer, serving layer y speed layer [5] [6] .
18
MARCO TECNOLÓGICO
Figura 1. Arquitectura Lambda

Fuente: https://docplayer.es/65157889-Arquitectura-lambda-vs-arquitectura-kappa.html
Las características de dicha arquitectura son las siguientes:

• La nueva información que entra en el sistema se envía simultáneamente a speed
layer y a batch layer.
• En batch layer se gestiona la información sin procesar, esta información se agrega
a la ya existente. Posteriormente se realiza un tratamiento para crear vistas
indexadas de datos con el objetivo de poder acceder a datos históricos de manera
más eficiente ya que están organizados en subconjuntos más pequeños.
• La capa de serving layer indexa las vistas de batch generadas en el paso anterior
para que puedan ser consultadas con baja latencia. Debido a que esta capa no recibe
escrituras aleatorias, sino que las vistas son sobreescritas. Gracias a este método
de indexación se obtiene una capa robusta, predecible, fácil de configurar y operar.
• La capa de streaming compensa la latencia de las escrituras de la serving layer y
solo tiene en cuenta los datos nuevos, es decir, que actúa con actualizaciones
incrementales, solo obtienen como nuevo lo necesario para ofrecer al usuario una
vista de tiempo real.
• Las respuestas a las consultas se obtienen de una combinación de las vistas en
batch de la capa de serving y las vistas en streaming de la speed layer.
2.1.2 Arquitectura Kappa
[5] [6] [7] [8] Fue introducida por Jay Kreps en el año 2014 en su artículo [9] en él señala
los puntos débiles de la arquitectura Lambda entre ellos se encontraba la necesidad de
realizar un mantenimiento a dos sistemas separados (batch layer y speed layer) y como
solucionarlos.
19
MARCO TECNOLÓGICO
La idea principal era administrar ambas capas con un único motor de procesamiento en línea,
es decir, poder prescindir de la capa de batch. En la Figura 2 se observa la arquitectura
Kappa.
Figura 2. Arquitectura Kappa

Fuente: https://docplayer.es/65157889-Arquitectura-lambda-vs-arquitectura-kappa.html
La capa de real-time ejecuta las actividades de procesamiento en línea y las actualizaciones

de código que permiten reprocesar los datos y visualizar los cambios en los resultados.
Si se desea reprocesar se inicia una segunda instancia de la tarea que se encuentra ejecutando
el procesado en línea comenzando a procesar la información almacenada en la base de datos.
Las características principales de esta arquitectura son las siguientes:
• Todo el proceso se realiza con un único stream.

• Los datos iniciales son almacenados sin modificación ninguna para que sean
consumidos en tiempo real, si se quiere realizar algún procesado será en base a
estos datos.
• El código del flujo de datos será siempre el mismo y no existirán dos diferenciados
como en la arquitectura Lambda
• Uno de los requisitos que deben cumplir los datos es que se reciban en el orden en
el que se han generado para poder representar un flujo continuo.
Al comparar las arquitecturas Lambda y Kappa se observa que la arquitectura Kappa es una
simplificación de la arquitectura Lambda ya que desaparece la capa de batch. Gracias a la
desaparición de dicha capa cambia el método de escritura de datos ya que se realiza
únicamente a través de la capa de streaming. Debido a que dicho método es mucho más
eficiente el flujo de información que se intercambia a través de la arquitectura Kappa se
transmite de una manera mucho más rápida.
Como una de las necesidades principales del sistema que se quiere definir es la de transmitir
señales en tiempo real se ha decidido basarse en la arquitectura Kappa para desarrollar la
arquitectura necesaria para este sistema.
En la Figura 3 se representan los elementos que componen la arquitectura que se va a definir,
en los que iremos profundizando posteriormente.
20
MARCO TECNOLÓGICO
Figura 3. Elementos Arquitectura TFG
Esta arquitectura se compone de una única capa de velocidad. El procesamiento de los datos
se realiza en base a los datos en tiempo real.
Uno de los requisitos que tienen este tipo de arquitecturas es que los datos deben seguir el
orden en el cual fueron generados, para conseguirlo necesitamos que la tecnología que se
encargue de la ingesta de datos y la plataforma de streaming aseguren el orden de entrega.
En la primera parte de la arquitectura se encuentra el PLC que es el que se encarga de
controlar las máquinas de la fábrica y generar sus datos, en el proyecto utilizaremos un
simulador virtual conectado con un servidor OPC para que realice la función de un PLC
virtual.
El servidor OPC mapeara las señales generadas por el PLC virtual para que la tecnología
encargada de la ingesta de datos implemente un cliente OPC que sea capaz de consumir estas
señales.
Una vez consumidas será necesario una plataforma de streaming para el transporte de estos
datos que asegure la persistencia, el orden de entrega y la velocidad de las señales
consumidas.
Utilizando una tecnología para el procesado de datos en tiempo real se consumirán los datos
de la plataforma de streaming con el fin de indexarlos en una base de datos NoSQL (No
Structured Query Language) y de generar cálculos en tiempo real. De esta forma se consigue
la persistencia de los datos, poder realizar un histórico de la fábrica y generar cálculos que
aporten valor al proceso de fabricación.
Por último, es necesario un componente que se encargue de la visualización de los datos de
la fábrica, esta tecnología hará consultas a la base de datos y representará los resultados en
un dashboard. Así las personas encargadas de interpretar dichos valores podrán hacerlo de
una manera mucho más cómoda e intuitiva.
2.2 Tecnologías Big Data
Una vez definida la arquitectura que se va a utilizar se van a estudiar las diferentes
tecnologías que se podrían usar para la implementación de los diferentes elementos que la
componen.
21
MARCO TECNOLÓGICO
2.2.1 Simuladores industriales
Para simular las industrias que generen las señales que se procesen en la arquitectura
diseñada se utilizara un software de simulación industrial, los más utilizados en la actualidad
son Anylogic y Vijeo Citect.
2.2.1.1 Anylogic
Anylogic es un software de simulación creado por la empresa estadounidense Anylogic en

el año 2000. [10] [11] Esta desarrollado en Java y sus características principales son:
• Relación entre modelos: El entorno de anylogic está compuesto por modelos
organizados jerárquicamente, estos modelos a su vez se componen por agentes los
cuáles pueden ser intercambiados entre los modelos.
• Interoperabilidad: Los usuarios pueden extender la funcionalidad del modelo
añadiendo código java o creando clases java personalizadas.
• Aspecto visual: Con el paso de los años se han ido añadiendo librerías visuales y en
la actualidad es uno de los mejores programas en este aspecto. Es capaz de simular
desde entornos industriales hasta financieros con un potente motor visual 3d.
En la Figura 4 podemos observar el aspecto visual Anylogic.
Figura 4. Aspecto visual Anylogic

Fuente: https://www.anylogic.com
22
MARCO TECNOLÓGICO
2.2.1.2 Vijeo Citect
Vijeo Citect es un programa que se centra en la simulación visual de sistemas industriales

controlados por PLCs. Fue desarrollado por Schneider Electric aunque en la actualidad está
gestionado por la empresa Aveva.
Este programa permite desarrollar procesos industriales a través de su editor gráfico y con
la ayuda de su lenguaje de programación propio llamado Cicode. Su principal ventaja es la
posibilidad de configurar el funcionamiento de los PLCs a través del programa sin tener que
ayudarte de un simulador de PLC externo y su punto débil es el aspecto visual el cuál como
podemos comprobar en la Figura 5 es demasiado básico [12] [13].
Figura 5. Interfaz gráfico Vijeo Citect

Fuente: https://www.indiamart.com/proddetail/scada-system-8792436373.html
2.2.2 Servidores OPC
Se necesita una tecnología capaz tanto de simular el funcionamiento de un PLC como de

poder conectarse a través de un protocolo de comunicación industrial con la tecnología de
ingesta de datos ya que esta es la manera en la que se reciben señales de las máquinas en las
fábricas actuales. Para realizar dicha función existen dos programas MatrikonOPC
Simulation Server y KEPServerEX.
23
MARCO TECNOLÓGICO
2.2.2.1 MatrikonOPC Simulation Server
Es un programa gratuito desarrollado por la empresa Matrikon está enfocado en el desarrollo

de pruebas para resolver futuros problemas en la conexión de PLC reales. Está enfocado para
entornos no productivos, con esta versión gratuita es posible conectarse con múltiples
clientes OPC. Los protocolos industriales de comunicación que se pueden utilizar con dicho
simulador son OPC DA (OPC Data Access), OPC HDA (OPC Historical Data Access) y
OPC A&E (OPC Alarms and Events) [14].
2.2.2.2 KEPServerEX
Es una plataforma desarrollada por la empresa Kepware que permite conectar múltiples
señales provenientes de dispositivos de automatización, a su vez ofrece la posibilidad de si
no se disponen de ellos poder simularlos. En este proyecto esta es la funcionalidad que se
necesita, ya que se simulan las señales que provienen del simulador industrial [15] [16].
Este programa permite el uso de diferentes protocolos de comunicación industriales como
OPC UA, OPC DA, MQTT (Message Queue Telemetry Transport).
Posee una versión de prueba gratuita con la limitación de solo poder conectar dispositivos
reales durante un máximo de 2 horas.
2.2.3 Ingesta/Acceso datos
Se trata de la parte de la arquitectura en la que se obtienen y enrutan los datos que provienen
de los PLC. Para ello se utilizan herramientas para programación de flujo de datos, las
tecnologías más utilizadas para dicha función son: Node-Red, Apache Nifi, Streamsets.
2.2.3.1 Node-Red
Es una herramienta para la programación basada en el flujo de datos desarrollada por IBM
y en la actualidad es parte de JS Foundation. Se trata de un runtime programado sobre
Node.js [17].
El acceso al editor de programación se realiza a través del navegador. Para programar con
dicha aplicación se arrastran nodos de la paleta del workspace, cuando se tiene programado
el flujo de datos se puede ejecutar de una manera muy simple. En la Figura 6 podemos
observar cómo se representa el editor de programación de Node-Red.
24
MARCO TECNOLÓGICO
Figura 6. Representación editor programación Node-Red

Fuente: https://aprendiendoarduino.wordpress.com/category/node-red/
Node-Red se puede desplegar tanto en Linux como en Windows, en arquitecturas Big Data
se suele usar conectado con Kafka para enrutar los datos.
Es una tecnología enfocada en su uso sin clusterizar (división de las tareas que tiene que
realizar una tecnología entre varios ordenadores), es decir, se utilizará en un único equipo
por lo que no es escalable.
La seguridad de la aplicación se implementa con el protocolo SSL (Secure Sockets Layer)
pero y la autenticación con el protocolo HTTP (Hypertext Transfer Protocol).
2.2.3.2 Streamsets Data Collector
Streamsets Data Collector fué desarrollado en California en 2014 cómo un proyecto de

código abierto en Java disponible en GitHub, su primera versión fue lanzada en 2014.
Los procesos en StreamSets intercambian records que son entidades propias de dicho
programa, es decir, que todos los datos que consume esta tecnología los transforma en dichos
objetos [18].
Para utilizar su editor visual se accede a través de la interfaz web, en esta interfaz se
programa por medio de “cajas”, se puede observar en el editor el proceso a seguir por los
datos, pero no se puede visualizar como se intercambian entre las diferentes cajas. Para suplir
dicha función se pueden incluir dashboards que son representaciones gráficas de los
diferentes datos que se intercambian para poder depurar y recoger estadísticas de los datos
que se intercambian. En la Figura 7 se observa dicha interfaz visual.
25
MARCO TECNOLÓGICO
Figura 7. Interfaz visual StreamSets

Fuente: https://www.datasciencecentral.com/profiles/blogs/open-source-etl-apache-nifi-vs-streamsets
Una de sus ventajas es que puede procesar datos binarios, lo que hace que no se tenga que
parsear los datos para cumplir el formato que necesite cada tecnología a la que se conecta.
2.2.3.3 Apache Nifi
La tecnología Apache Nifi fue donada por la agencia de seguridad nacional estadounidense
a la fundación Apache en 2014 y su desarrollo y soporte ha sido dado por la empresa
Hortonworks, está desarrollado en Java [18] [19].
La arquitectura de Nifi se basa en FlowFiles, que es una entidad propia de Apache Nifi. Este
tipo de objeto son los datos originales que consumirá Nifi que pueden ser desde sencillos
csv a datos binarios o videos.
Su estilo de programación es por cajas, las cuales se pueden arrastrar desde una paleta. Estas
cajas son llamados procesos, los datos intercambiados se observan durante la ejecución y el
acceso al editor visual se realiza a través del navegador. En la Figura 8 se observa el aspecto
de dicho editor y un ejemplo de un proceso.
26
MARCO TECNOLÓGICO
Figura 8. Editor web Apache NIFI

Fuente: https://statsbot.co/blog/open-source-etl/
Esta tecnología se puede ejecutar tanto en Linux como Windows, pero necesita consumir un
gran número de recursos de la máquina en la que se ejecuta. Es una tecnología que garantiza
la entrega de datos, y se puede escalar gracias a la posibilidad de clusterizarla. Tiene
integrados conectores con varias tecnologías Big Data como Kafka.
Para implementar la seguridad dentro de la arquitectura han usado SSL te permite la
posibilidad de personalizar la seguridad que quieres que posea el Dataflow, la autenticación
se realiza con LDAP (Lightweight Directory Access Protocol).
2.2.4 Plataforma de Streaming
Una vez ingestados los datos se procederá a su conexión con una plataforma de streaming
que se encargará de transportarlos desde la herramienta de ingesta hasta la herramienta de
procesamiento en tiempo real. Para realizar dicha función existen tres tecnologías Google
Pub/Sub, Apache Kafka y Apache Flume [20] [21].
27
MARCO TECNOLÓGICO
2.2.4.1 Apache Flume
Apache Flume es un sistema distribuido escrito en java para recoger y mover grandes
cantidades de datos desde diferentes orígenes a un almacén centralizado. Comenzó a
desarrollarse en 2010 a manos de la empresa Cloudera y en la actualidad se puede utilizar
en sistemas Linux o Mac [22].
Su arquitectura se basa en el manejo de flujos de streaming de datos ofreciendo mecanismos
para garantizar la entrega de estos mismos. Dentro de Flume se encuentran agentes, que son
procesos java que alojan los componentes a través de los cuales los eventos fluyen de una
fuente externa a un destino. En cada agente los eventos se alojan en un canal, después se
entregan al siguiente agente o a un repositorio central, este repositorio central suele ser
HDFS (Hadoop Distributed File System) [23].
Los eventos son borrados del canal una vez guardados en el canal del siguiente agente o en
un repositorio final.
2.2.4.2 Google Pub/Sub
Google Pub/Sub es una solución dentro del ecosistema de Google para el intercambio de
mensajes, a diferencia de Kafka y Flume esta tecnología se encuentra en la nube. Las
aplicaciones publicadoras (Publisher) envían mensajes a un topic que es la entidad por la
que se transfieren los mensajes y las consumidoras se suscriben a él.
Los mensajes son persistidos en la nube hasta que se recibe respuesta de los consumidores,
estas aplicaciones se pueden programar con la tecnología Google API (Application
Programming Interface) HTTPS.
Esta solución ofrece una persistencia máxima de 7 días y está más enfocada al intercambio
de mensajes más grandes de 1 megabyte. Al no ser software libre, el precio se calcula a partir
de la cantidad de datos intercambiados. En la Figura 9 se puede observar los precios de dicha
tecnología [24].
Figura 9. Precios Google Pub/Sub

Fuente: https://cloud.google.com/pubsub/pricing?hl=es
2.2.4.3 Apache Kafka
Apache Kafka es un software de código abierto, comenzó en 2009 a cargo de la empresa

LinkedIn, en el 2011 fue donado a Apache pasando a formar parte de sus proyectos Top
Level. En noviembre de 2012 varios miembros de los que comenzaron el desarrollo en 2009
decidieron crear una empresa llamada Confluent basada en gran parte en el desarrollo de
Kafka [25] [26].
28
MARCO TECNOLÓGICO
Está programado en Scala que es un lenguaje de programación orientado a objetos, dispone

de conectores con varias tecnologías Big Data y permite la implementación de consumidores
y productores en Java.
Kafka es una tecnología distribuida para el servicio de streaming, por el método de
publicador/suscriptor, en esta forma de intercambiar información el publicador (Kafka en
este caso) al generar un dato no lo envía a la dirección del suscriptor, sino que lo publica en
un topic que es el lugar donde se intercambian los datos entre los publicadores y suscriptores,
luego los suscriptores se conectan a este topic para consumir estos datos. En la figura 10 se
muestra un esquema del método publicador/suscriptor [27] [28].
Figura 10. Esquema Publicador/Suscriptor

Fuente: https://enmilocalfunciona.io/aprendiendo-apache-kafka-parte-1/
Esta tecnología se puede lanzar en un cluster de brokers con particiones a través de los
diferentes nodos, es decir, se pueden definir varios intercambios de datos mediante el
esquema publicador/suscriptor en ordenadores diferentes por lo que es altamente escalable
y tolerante a fallos. Se apoya en la tecnología Zookeeper (herramienta que orquesta el
funcionamiento de tecnologías distribuidas) para almacenar el estado de los nodos.
Esta especialmente diseñado para el intercambio de un gran número de datos con una latencia
muy baja y no posee un tiempo máximo de persistencia.
2.2.5 Procesado en tiempo real
Una vez que los datos son transportados desde la ingesta se introducirá la parte de procesado,
que consumirá de la plataforma de streaming, generará los datos agregados en tiempo real y
los indexará a la base de datos junto a los datos originales. Existen dos tecnologías
principales para el procesamiento en tiempo real: Apache Flink y Apache Spark.
29
MARCO TECNOLÓGICO
2.2.5.1 Apache Spark
Apache Spark fue desarrollado en 2009 en la universidad de Berkeley, está escrito en Scala,
aunque tiene numerosas APIs para usar Java o Python, paso a ser uno de los proyectos top-
level de Apache en febrero de 2014.
Principalmente se basa en la idea de dividir o paralelizar el procesado de datos. Normalmente
se instala en un cluster de máquinas, cada una de ellas tendrá una instancia de Apache Spark
que procesara una parte de los datos para luego juntarlos, esto proporcionara una mayor
velocidad, lo que es clave en el mundo BigData.
Esta tecnología está orientada a sistemas en batch, estos batch son llamados RDDs (Resilent
Distributed Dataset) que son objetos formados por parte de los datos.
Spark posee un gran número de conectores como HDFS o bases de datos NoSQL [29] [30]
[31].
2.2.5.2 Apache Flink
Apache Flink comenzó como un proyecto de investigación surgido de la colaboración de

varias universidades europeas, este proyecto se llamaba Stratosphere: Information
Management on the Cloud. En marzo de 2014 pasó a formar parte de Apache y nueve meses
después fue aceptado como uno de los proyectos top-level de Apache. En la actualidad esta
soportado y desarrollado por la start-up Data Artisans [32] [33].
Es una plataforma de código abierto en Java y Scala para el procesamiento en streaming de
datos escalables y procesamiento por lotes. Flink fue desarrollado basándose en MapReduce
que era un modelo de programación orientado a la computación paralela de grandes
cantidades de datos, pero intentando ser una alternativa a su uso, puede ejecutarse de manera
independiente de tecnologías existentes como Hadoop sobre HDFS y YARN (Yet Another
Resource Negotiator) [34].
Las características principales de Flink son:

• Baja latencia y alta cantidad de datos consumidos.
• Tolerancia a fallos debido a que puede distribuirse en varias máquinas con
facilidad.
• Procesamiento de eventos en base a tiempo asociado
• Procesamiento por ventanas de tiempo
2.2.6 Persistencia de datos
Para realizar la función de la persistencia en la arquitectura necesitaríamos utilizar una base

de datos enfocada en el tiempo real con tiempos de lectura y escritura muy bajos. Las dos
bases de datos más utilizadas para dicha función en este momento son: Cassandra y
InfluxDB.
30
MARCO TECNOLÓGICO
2.2.6.1 Cassandra
Cassandra es una base de datos NoSQL desarrollada por Facebook para potenciar la
funcionalidad de sus búsquedas. En 2008 fue liberado como proyecto open source con
licencia Apache y en 2010 se convirtió en un proyecto top-level. Hoy en día esta mantenido
y desarrollado por la compañía Datastax [35] [36].
Cassandra proporciona tolerancia a particiones y disponibilidad, es una base de datos
distribuida, es decir la información está repartida en nodos de un clúster. Una de sus
características más importantes es la capacidad de escalar linealmente, es decir, si con 2
nodos soportamos 100000 operaciones por segundo con 4 nodos soportaremos 200000.
Para acceder a los datos se utiliza un lenguaje propio basado en SQL (Structured Query
Language) llamado Cassandra Query Language (CQL).
2.2.6.2 InfluxDB
InfluxDB es una base de datos NoSQL escrita en Go (Open Source Programming Language)
que se centra en guardar series de datos indexadas por tiempo, lo que lo hace una herramienta
muy acertada en el caso que quieras controlar lo que sucede a tus datos a lo largo del tiempo
o aplicaciones en tiempo real.
Posee una API que permite realizar consultas con una interfaz Rest y una librería para
codificar clientes en Go, Java o Javascript. Estas consultas se realizan en un lenguaje propio
de InfluxDB pero similar a SQL llamado InfluxQL.
InfluxDB permite consumir millones de data points por segundo, comprime
automáticamente los datos para minimizar el espacio de almacenamiento y se pueden definir
políticas de retención para controlar cuando se necesita que los datos antiguos expiren [36]
[37] [38].
2.2.7 Representación de datos
Una vez almacenados los datos se necesita una tecnología para acceder a ellos y
representarlos en un dashboard (representación gráficas de los datos de una fábrica) con el
objetivo de que en la fábrica se puedan monitorizar en tiempo real. Existen 3 tecnologías
para realizar dicha función: Apache Zeppelin, Grafana, Kibana.
2.2.7.1 Apache Zeppelin
Zeppelin es un web notebook que se centra en representar los datos en tiempo real. Fue
desarrollado por la empresa ZEPL en 2013, en 2014 paso a Apache hasta que en 2016 llegó
a ser un proyecto top level de apache [39] [40].
Destaca por las siguientes características:
31
MARCO TECNOLÓGICO
• Simplicidad: dentro de Zeppelin se puede codificar en diferentes lenguajes ya que

posee una arquitectura de intérpretes.
• Es una tecnología actual y en constante evolución.
• Interfaz: tiene una interfaz simple sobre Bootstrap y AngularJS (frameworks para la
creación de páginas web)
En la Figura 11 podemos observar cómo se representan con esta tecnología unos datos de
prueba.
Figura 11. Representación de datos con Apache Zeppelin
2.2.7.2 Kibana
Kibana es una herramienta de libre acceso desarrollada por Elastic en octubre de 2015 que
nos permite visualizar y acceder a los datos indexados en ElasticSearch.
Kibana está desarrollado para ser usado junto a ElasticSearch y Logstash para la agregación
de datos, visualización y analisis.
Es una herramienta en continua evolución su última versión es del 29 de enero de 2019 [41]
[42]. En la Figura 12 se observa cómo se representarían los datos en esta herramienta.
32
MARCO TECNOLÓGICO
Figura 12. Representación de datos en Kibana

Fuente: https://www.elastic.co/es/products/kibana
2.2.7.3 Grafana
Grafana es una herramienta open source para la visualización de datos temporales indexados
en bases de datos. Está codificado en Go y su lanzamiento fue el 21 de enero de 2014 [43].
Posee numerosos tipos de gráficos y tiene un aspecto visual que le diferencia de sus
competidores, ofrece la posibilidad de definir alarmas que indiquen el valor anómalo de una
señal. Otro de sus puntos fuertes son los conectores que tiene implementados para diferentes
fuentes de datos como InfluxDB, Graphite ElasticSearch.
En la Figura 13 se observa el aspecto visual de dicha herramienta.
33
MARCO TECNOLÓGICO
Figura 13 Interfaz visual Grafana

Fuente:https://medium.com/@ashish_fagna/influxdb-to-grafana-visualizing-time-series-data-in-real-time-
2174940a894d
34
MARCO TECNOLÓGICO
35
ESPECIFICACIONES Y RESTRICCIONES DE DISEÑO
3. Especificaciones y restricciones de diseño
En este apartado se compararán las tecnologías estudiadas en el punto 2 y se decidirán las

que más se adecuen a esta arquitectura.
3.1 Simuladores industriales
Comparando los simuladores industriales definidos en el punto 2.1 se encuentran varias

características diferenciales entre ellos [44]:
• Aspecto visual: Anylogic tiene un aspecto visual mucho más realista ya que tiene la
capacidad de visualizar la simulación en 3d, posee gran cantidad de objetos que se
pueden añadir al proyecto desde una paleta de una forma muy simple.
• Lenguaje de programación: Mientras que Anylogic permite desarrollar clases
personalizadas que se pueden incluir al proyecto en un lenguaje tan extendido como
java, Vijeo Citect sólo permite añadir partes de código en un lenguaje propio de la
empresa desarrolladora de Vijeo llamado Cicode.
• Documentación: Existe una gran documentación y tutoriales en internet para
aprender a usar esta herramienta frente a la poca información que se ha podido
encontrar de Vijeo Citect.
Debido a todas estas ventajas se ha decidido usar Anylogic como simulador virtual para
representar la fábrica.
3.2 Servidor OPC
Para realizar la función de servidor OPC se valorará:

• La capacidad del servidor para conectarse a un mayor número de protocolos de
comunicación, en esta comparación KEPServerEX es un servidor capaz de utilizar
mayor número de protocolos.
• La preparación del servidor para el envío masivo y seguro de datos, en este caso
KEPServerEX es el servidor más preparado para esta función gracias a que
implementa tecnologías como [16]:
o Redundancia de rutas para poder usar una ruta diferente en caso de fallo.
o Balance de carga con el fin de poder programar la frecuencia con la que se
efectúan las comunicaciones.
o Optimización de comunicaciones, se agrupan múltiples solicitudes de datos
en una única petición conjunta.
Por todas estas características se ha decidido usar KepServerEX, ya que como se ha
comparado es una mejor opción para esta arquitectura frente a MatrikonOPC.
36
3.3 Ingesta/Acceso datos
Se han comparado las tres tecnologías con el objetivo de encontrar la que más se ajuste a
nuestro caso de uso, para ello debe cumplir estas tres características principales:
• Facilidad para desarrollar plugin externos (de esta manera se podrá desarrollar un
plugin personalizado para consumir datos de OPC).
• Escalabilidad, esta herramienta nos debe proporcionar la escalabilidad necesaria en
una fábrica.
• Posibilidad de ver el flujo de datos en tiempo real a partir de su interfaz gráfico.
Comparando estas tres tecnologías se ha decidido usar Apache Nifi debido a de las tres
posibilidades que conformaban el estado del arte es la que aúna todas estas propiedades.
3.4 Plataforma de Streaming
La característica principal que define a esta arquitectura es la capacidad de intercambiar un

gran número de señales en tiempo real. Para cumplir esta función una de las piezas más
importantes será la plataforma de streaming ya que será la encargada de transportar las
señales entre las distintas tecnologías.
Por esta razón se elegirá la tecnología que aporte:
• Rendimiento: debe estar especialmente desarrollada para el manejo de datos en
tiempo real, ya que la fábrica genera señales con una latencia muy baja.
• Alta disponibilidad: muchas de esas señales son críticas, por lo que debe ser un
software tolerante a fallos.
• Escalabilidad: debe ser capaz de distribuirse por si en un futuro fuese necesario
ampliar esta arquitectura.
Comparando las tres tecnologías se ha optado por usar la tecnología Apache Kafka debido
a que está desarrollada para manejar datos en tiempo real, posee una alta disponibilidad
gracias a la replicación de los topics en diferentes máquinas y es escalable debido a la
posibilidad de crear particiones de un topic en diferentes máquinas.
3.5 Procesado en tiempo real
• La diferencia principal entre Flink y Spark se centra en cómo se procesan los flujos
debido a que Spark utiliza microbatching, es decir, procesa los datos en pequeñas
ventanas para poder asemejarse al tiempo real, sin embargo, Flink procesa en streaming,
va procesando cada dato según llega.
• Esto provoca que Flink sea una mejor opción en el caso de uso del tiempo real, otra
diferencia es la rapidez con la que Flink procesa los datos gracias a que consume registro
a registro mientras que Spark lo hace mediante RDDs que son objetos propios que tiene
que generar Spark con cada conjunto de datos.
37
• Como última ventaja Flink posee una Api propia para realizar funciones de machine
learning lo que en un futuro nos podría interesar si quisiéramos añadirle esta
funcionalidad a nuestra arquitectura
Debido a estas diferencias entre Flink y Spark se ha optado por la utilización de Apache
Flink
3.6 Persistencia de datos
Para realizar la comparación entre las dos bases de datos se ha ulitlizado la herramienta
online db-engines [36] [45]. Y se ha llegado a las siguientes conclusiones:
• InfluxDB se encuentra en el primer puesto del ranking de bases de datos basadas en
series temporales. Realizando comparaciones de escritura y compresión de datos se
puede observar que InfluxDB escribe 4 veces más rápido que Cassandra y reduce a
la mitad el espacio ocupado en disco.
Figura 14. Comparación velocidad InfluxDB vs Cassandra

Fuente: https://www.influxdata.com/blog/influxdb-vs-cassandra-time-series/
38
Figura 15. Comparación compresión InfluxDB vs Cassandra

Fuente: https://www.influxdata.com/blog/influxdb-vs-cassandra-time-series/
Debido a estas conclusiones y a la capacidad que posee InfluxDB de conectarse con varias
herramientas de visualización de datos se ha optado por la utilización de dicha tecnología.
3.7 Representación de datos

La representación de datos aporta un gran valor para el caso de uso de una fábrica ya que el
aspecto visual es esencial para que los trabajadores puedan comprender los datos generados
por la maquinaria y la capacidad de definir alertas ofrece grandes posibilidades en caso de
que ocurra alguna anomalía en el proceso industrial.
Se han comparado varios aspectos de las tres tecnologías principales:
• Aspecto visual: comparada con las otras dos tecnologías Grafana posee una interfaz
moderna e intuitiva, existen numerosos tipos de gráficos para poder representar los
datos generados por la fábrica con exactitud.
• Conectividad: Grafana y Kibana implementan conectores con bases de datos como
InfluxDB, Graphite o Prometheus ofreciendo la posibilidad de representar datos de
diferentes fuentes en un mismo gráfico.
• Alertas: la única tecnología que permite la definición de alarmas en el caso que los
datos que reciba cumplan unas determinadas condiciones es Grafana, estas alarmas
se podrían transmitir por telegram y correo electrónico.
Todas estas características diferenciales provocan que se haya elegido Grafana frente a las
otras tecnologías.
Una vez elegidas las tecnologías para cada parte de la arquitectura en la figura 16
observamos como se representaría esta arquitectura con las tecnologías ya definidas.
39
Figura 16. Tecnologías definidas en la Arquitectura
40
41
DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA
4. Descripción de la solución propuesta
Para describir cómo se ha definido la arquitectura se va a seguir la misma organización que

en la elección de las tecnologías, es decir, se va a profundizar en cada parte de la arquitectura
de manera incremental hasta observar toda ella en conjunto.
Para poder realizar un seguimiento del desarrollo se han implementado 2 prototipos de
prueba en los que se puede comprobar el correcto desarrollo de la arquitectura.
4.1 Anylogic
En Anylogic se crea una simulación 3d de un proceso industrial para que se pueda seguir de
manera visual el proceso de fabricación de una pieza. También se implementa el
funcionamiento de un PLC que se encarga de generar las señales asociadas a dicho proceso.
4.1.1 Descarga y configuración
Para comenzar a desarrollar la simulación de Anylogic se descarga de su página oficial

https://www.anylogic.com/downloads/, su última versión fue lanzada el 28 de febrero de
2019 y es la 8.4.0. Existen varias posibilidades para la descarga, la que se utiliza es la de
estudiante ya que es gratuita, esta versión tiene algunas limitaciones cómo el límite de
creación de diez agentes. Una vez descargado se procede a su instalación y se ejecuta el
programa. En la figura 17 se puede observar la ventana principal de Anylogic.
Figura 17. Elementos principales ventana Anylogic
42
El botón número 1 se utiliza para crear desde cero un nuevo modelo, el número 2 permite
abrir un modelo previamente creado, la pestaña tres llamada projects muestra un árbol de
navegación para visualizar los diferentes modelos creados, la pestaña cuatro es la paleta de
elementos que se pueden utilizar para implementar el modelo. Una vez desarrollado, el
modelo se ejecutará pulsando el botón número cinco.
En este caso el primer paso será crear un nuevo modelo, para crearlo es necesario indicar su
nombre, su ubicación en el ordenador y las unidades temporales que lo van a definir
(segundos, minutos, horas). Una vez creado el modelo se puede observar su estructura en la
pestaña projects.
Cualquier modelo está compuesto por su agente principal llamado Main, este agente equivale
al Main en un programa Java, en la ventana de propiedades de dicho agente se pueden indicar
acciones que ocurren al comienzo de su creación, dentro de la pestaña Advanced Java se
pueden importar librerías y añadir código adicional para esta clase. De esta manera se podrá
utilizar cualquier librería externa de java dentro de Anylogic e inicializar todas las variables
globales que sean necesarias.
En la figura 18 se representa dicha ventana.
Figura 18. Ventana de configuración de un agente
43
Dentro del modelo también se encuentra un componente llamado simulation, en él se indican

propiedades sobre cómo se va a realizar la ejecución de dicha simulación, se puede indicar
la fecha de inicio de dicha simulación, la forma de generar números aleatorios o las
características de la ventana de ejecución.
En la figura 19 se observa dicha ventana de configuración.
Figura 19. Ventana de configuración Simulation
Los últimos componentes que se pueden definir dentro del modelo son la posibilidad de
actualizarlo en la nube y la creación de una base de datos propia para este modelo.
44
4.2 KEPServerEX
KEPServerEX se encarga de mapear en el servidor OPC las señales que genera Anylogic.

El primero paso para utilizar dicho programa es descargarlo de su página web oficial
https://www.kepware.com/en-us/kepserverex-6-6-release/, la licencia de este software es de
pago, pero para la simulación de la arquitectura se puede utilizar una versión de prueba en
la que la única limitación que existe es el tiempo durante el cual puedes usar dicho servidor.
Este límite es de dos horas, pero existe la posibilidad de reiniciar dicho servidor para poder
seguir utilizándolo. Una vez descargado se procede a instalar y a acceder al programa.
En la figura 20 observamos la ventana principal de KEPServerEX.
Figura 20. Ventana principal KEPServerEX
Sobre dicha imagen se explican los elementos más relevantes para la arquitectura propuesta
En el número 1 se encuentra un cliente OPC integrado en el propio servidor, en este cliente
se puede comprobar el correcto funcionamiento de este servidor, así como observar la
variación del valor de las señales que se hayan configurado.
En el número 2 se encuentra el árbol de navegación de KEPServerEX, en él se encuentran
tres elementos principales: el canal, el dispositivo y el tag.
En el número 3 se encuentra el registro de logs para saber en qué estado se encuentra el
servidor y en caso de fallo saber cuál es el problema.
El número 4 indica el número de tags activos, así como el número de clientes conectados
simultáneamente a el servidor OPC
45
4.2.1.1 Canal
Representa el canal de comunicación que se va a utilizar para comunise con el PLC, los
canales representan una comunicación media entre los dispositivos y el ordenador. Para
crearlos se pulsa con el botón derecho en la etiqueta Connectivity→New Channel, se entra
en la ventana de configuración del canal y lo primero que se pide es el protocolo de
comunicación, en este caso como no existe un PLC físico el protocolo es Simulator, luego
en el nombre del canal se llamara TFG.
En la figura 21 se observa cómo queda la configuración de dicho canal.
Figura 21. Configuración canal TFG
En esta ventana se observan varias características importantes:

• El nombre y el driver de comunicación utilizado por el canal.
• El método de escritura indica que en caso de existir una señal a la que le hayan
llegados varias escrituras concurrentemente sólo escribirá el último valor recibido y
el tiempo de ciclo quiere decir que por cada 10 operaciones de escritura ocurrirá una
de lectura.
• El método de actuación con valores anómalos en este caso se sustituye por un cero
• Indica si se desea habilitar la persistencia de las señales de este canal en la máquina
en la que se encuentra Kepserver.
46
4.2.1.2 Dispositivo
El dispositivo representa el PLC con el que se comunica el servidor.

Para crear uno nuevo se pulsa con el botón derecho en el canal creado TFG→New Device,
al hacerlo se abre la configuración pidiendo el nombre del dispositivo, en este caso se le
indica PLC_Fabrica.
En la Figura 22 se muestra la configuración de dicho dispositivo.
Figura 22. Configuración PLC_Fábrica
En la configuración se indican varios aspectos importantes del dispositivo:

• El driver, que viene definido por el tipo de canal al que está asociado.
• El identificador del dispositivo, este tiene que ser único para todos los dispositivos
del mismo canal.
• La recolección de datos, si esta desactivada se podrán manejar las señales de
KEPServerEX externamente pero no se recibirán valores.
• El modo de escaneo en el cuál existen varias posibilidades:
o La primera es respetar la tasa de escaneado del cliente, se ha decidido utilizar
este modo debido a que con el cliente OPC se puede establecer esta tasa de
manera mucho más flexible, es decir con este modo el cliente decide cada
cuanto consulta al canal por el valor de la señal.
o Otro de los modos posibles es dejar establecer la tasa al cliente siempre que
se establezca una tasa máxima.
47
o El modo contrario a estos dos es la decisión de marcar la tasa de refresco por

parte del servidor.
o No usar tasa de refresco sino obligar a que el dispositivo haga una petición
de la señal que quiera obtener la información.
o Respetar la tasa de refresco que posea la propia señal
4.2.1.3 Tag
Un tag representa las direcciones a las señales del PLC.

Para crearla se pulsa con el botón derecho sobre el dispositivo previamente creado y se
selecciona nuevo tag.
En la figura 23 se ven los parámetros a rellenar durante su configuración.
Figura 23. Configuración Tags
El primer parámetro a rellenar es el nombre de la señal que se quiera representar, después se

indica la dirección, esto indica el modo de creación de los datos, al ser un PLC simulado
existen distintos tipos de señales simuladas: senos, aleatorias, rampas.
Una vez elegido el tipo se tiene que indicar la tasa con la cual se actualizarán los valores, el
valor más bajo dentro de la señal, el valor más alto, el incremento entre valores en caso de
ser una rampa y la frecuencia en caso de ser un seno.
Como en este caso no se va a querer que se generen señales simuladas (salvo para comprobar
el correcto funcionamiento del servidor) se van a declarar tags constantes los cuales se van
a asociar con las señales generadas de anylogic para que vaya actualizando sus valores. Al
declarar estas variables es necesario introducir una dirección física dentro del PLC entre los
números 0000 y 9999, estas direcciones son únicas y no pueden repetirse entre las señales
de un mismo canal.
48
El tipo de dato dependerá del valor de la señal que provenga de anylogic pero estarán dentro
de String, Word, Double y Boolean
El acceso del cliente será de lectura y escritura ya que se necesita que anylogic escriba en
este tag y el cliente OPC lo lea. El scan rate es el tiempo que pasa entre los refrescos del
valor de la señal.
Otro de los aspectos más importantes para la configuración del servidor es saber en qué red
está ubicado nuestro servidor OPC. Para realizar esta función se entra dentro de la barra de
herramientas de Windows y en el icono de Kepserver se pulsa botón derecho y OPC UA
Configuration.
En la figura 24 se muestra la ventana de configuración del servidor OPC UA.
Figura 24. Configuración dirección del servidor OPCUA
En esta ventana se muestran las dos direcciones por las cuales se puede acceder al servidor
OPC, la primera la dirección de la máquina donde esta lanzado y la segunda la de localhost
existe la posibilidad de añadir más interfaces de red en direcciones ip diferentes usando el
botón add y marcando el CheckBox llamado enabled.
En este caso cuando se quiera conectar con el servidor OPC se va a utilizar la dirección
opc.tcp://DESKTOP-R0A3HF0:49320, si se pulsa dos veces sobre esta dirección se
pueden comprobar más parámetros como los protocolos de seguridad que debe implementar
el cliente para poder acceder a dicho servidor y el puerto en el que se accede a dicho servidor.
En la figura 6 se muestra dicha ventana de configuración.
49
Figura 25. Configuración dirección OPCUA
4.3 Apache Nifi

Apache Nifi es la tecnología encargada de recoger los datos generados por KEPServerEX.
Debido a la complejidad de esta herramienta es necesario profundizar en su funcionamiento
antes de introducirnos en su implementación dentro de esta arquitectura.
La arquitectura de esta tecnología está compuesta por tres elementos principales: el web
server, el flow controller y los repositories [46] [47].
• El web server es el encargado de alojar la interfaz web y controlar la API.
• El flow controller se encarga de distribuir la ejecución del programa, es decir, es el
encargado de gestionar la planificación de los hilos que ejecuta cada proceso y del
orden en el que lo hacen.
• Existen tres repositories encargados de almacenar el estado de la aplicación con el
objetivo de preservar los datos en caso de ocurrir algún fallo en el host que la aloje:
o FlowFile Repository: realiza un seguimiento del estado de un Flow file activo
en el flujo.
o Content Repository: en él se encuentra el contenido real de un Flow file
determinado. Este repositorio se puede particionar con el objetivo de reducir
el espacio ocupado para una sola máquina.
o Provenance Repository: Se encarga de almacenar los datos de los eventos de
proveniencia, estos eventos se activan mientras el Flow file va recorriendo
los diferentes procesos, por ejemplo, cuando el Flow file abandona un
proceso se guarda el evento llamado SEND.
En la figura 26 se observa visualmente dicha arquitectura.
50
Figura 26. Arquitectura Apache Nifi

Fuente: https://nifi.apache.org/docs.html
Una vez analizada la arquitectura se procederá a la implementación del grupo de procesos

que permita conectarse a KEPServerEX y escribir los datos en Kafka. Para ello el primer
paso será descargarnos Apache nifi de su página oficial
https://nifi.apache.org/download.html en este caso se descarga la versión nifi 1.8.0.
Para ejecutar nifi primero se ha de configurar en qué dirección ip y puerto se alojará, en este
caso será localhost:8080, esta opción se encuentra en el fichero de propiedades de la carpeta
conf llamado nifi.properties. A parte de esta configuración en este fichero se pueden editar
otras opciones como la ubicación y el tamaño de los repositorios de nifi.
En la figura 27 se muestra la configuración de este fichero.
Figura 27. Fichero configuración Apache Nifi
Una vez configurado se lanza nifi ejecutando el script que se encuentra en la carpeta bin de
nifi 1.8.0.
51
4.4 Apache Kafka
Apache Kafka se utiliza para recoger los datos generados por Apache Nifi y ofrecerlos a
Apache Flink mediante la suscripción a uno de sus topics.
La inclusión de esta tecnología en esta arquitectura proporciona las siguientes características:
• Rapidez en el encaminamiento de datos entre Nifi y Flink, gracias a ser una
herramienta desarrollada para el manejo de datos en tiempo real.
• Para la simulación se ejecutará Kafka en una única máquina, pero es una herramienta
que se puede escalar y distribuir con una gran facilidad.
• Persistencia de los datos, si Nifi o Flink fallan Kafka tiene la capacidad de poder
persistir sus datos en la máquina en la que se esté ejecutando.
• En caso de ejecutar Apache Kafka en dos o más máquinas permite replicar los topics
con el fin de evitar la pérdida de datos.
El primer paso para lanzar Kafka en una máquina es descargarlo de su página web
https://kafka.apache.org/downloads, en este momento su última versión estable es del 15 de
febrero de 2019 y corresponde a la versión 2.1.1. En la misma carpeta en la que se encuentra
Kafka también se descarga una versión de Zookeeper, esta es una herramienta para la
coordinación de procesos distribuidos, debido a la implementación de Kafka es necesario
tener Zookeeper ejecutado para poder lanzarla.
Una vez descargado se procede a la configuración de sus ficheros de propiedades, se
accederá a kafka 2.12-2.1.1\config\server.properties para indicarle en qué dirección ip se
quiere lanzar Kafka, en este caso será la del ordenador.
En este fichero se encuentran otros aspectos configurables como la dirección en la que se
lanza Zookeeper, la ubicación donde se quieren guardar los logs generados por Kafka y
Zookeeper o el número de hilos que se quiere que ejecute Kafka para procesar peticiones de
datos.
En la Figura 28 se observa el fichero de configuración de Kafka.
52
Figura 28. Fichero configuración Kafka
Una vez realizada dicha configuración se procede a ejecutar zookeeper en la terminal, desde
la carpeta Kafka 2.12-2.1.1 se escribe el siguiente comando:
• .\bin\windows\zookeeper-server-start.bat
.\config\zookeeper.properties
Después se abre otra terminal en ella se ejecuta el siguiente comando para lanzar Kafka:
• .\bin\windows\kafka-server-start.bat
.\config\server.properties
Al lanzar estos dos comandos se consigue ejecutar Zookeeper y Kafka en la dirección que
le hayamos indicado en el fichero de propiedades.
Posteriormente se procede a la creación de los topics necesarios en Kafka, para esta
arquitectura se ha decidido usar tres: uno llamado topicAnylogic (en él se escriben las
señales creadas por Anylogic), topicPLC (en el que nifi escribe las señales que lleguen desde
el servidor OPC generadas por el PLC) y otro llamado topicProcesado (en el que Flink
escribe los datos una vez procesados).
En la figura 29 se muestra cómo se realizaría la creación de estos dos topics.
Figura 29. Comandos para la creación de los topics
53
El comando usado es
.\bin\windows\kafka-topics.bat --zookeeper localhost:2181 --
create -topic <nombre Topic> --partitions 1 --replication-
factor 1
El primer parámetro indica la dirección en la que se encuentra Zookeeper que es la tecnología
encargada de manejar la creación y el borrado de topics, el segundo parámetro indica el
nombre del topic.
Los parámetros partitions y replication-factor se utilizan en caso de querer distribuir Kafka
en varias máquinas, el primero indica en cuantas particiones se divide el topic, esto quiere
decir que la carga de trabajo de lecturas y escrituras que se produzca en dicho topic se divide
entre el número de máquinas que se le indique en ese parámetro. El parámetro replication-
factor indica en cuantas máquinas se replicará el topic, esto es útil en el caso de que alguna
máquina falle ya que siempre habrá una réplica de la información en otra de las máquinas.
Otros de los comandos útiles para esta tecnología son:
• .\bin\windows\kafka-console-consumer.bat --bootstrap-
server <dirección ip donde esta lanzado kafka> --topic
<nombre topic>
Con este comando se abrirá un consumidor, en él se podrá ver todos los datos que pasen por
el topic que le hayas indicado.
• .\bin\windows\kafka-console-producer.bat –broker-list
<dirección ip donde esta lanzado kafka> --topic <nombre
topic>
Este otro comando se utiliza para poder escribir manualmente datos en un topic concreto.
Con esta configuración ya se tendría listo Kafka para la comunicación con Nifi y Flink.
4.5 Implementación Prototipo 0
Una vez configuradas las tecnologías necesarias para el desarrollo del primer prototipo se
procede a su implementación.
El objetivo de este primer prototipo es conseguir enviar las señales desde Anylogic a Apache
Kafka pasando por KEPServerEX y Apache Nifi. Se profundizará en la implementación de
cada tecnología que interviene en este prototipo.
4.5.1 Anylogic
Para realizar la simulación de un proceso industrial se ha decidido desarrollar una simulación

de una industria que produce botellas de vino. Para ello se usa la paleta de diseño que se
encuentra en Anylogic, los objetos visuales que se utilizarán serán cintas transportadoras,
cajas, botellas y un camión.
En la figura 30 se muestra la parte visual en 2d de dicha simulación indicando las diferentes
zonas de las que se compone.
54
Figura 30. Parte visual simulación industria
La zona de generación de cajas vacías es donde se instancia el objeto caja, existen tres tipos
de cajas los cuales serán generados aleatoriamente: rojas, azules y amarillas. Las cajas se
generan cada vez que una caja abandone el proceso. Una vez que la caja llegue a la
bifurcación se pesan y van a una de las zonas de llenado de botellas según su tipo, las azules
van a la zona de la izquierda, las amarillas en la central y las rojas a la derecha.
En la zona de generación de botellas se instancian las del tipo correspondiente según su zona,
antes de entrar en la caja se comprueba por medio de un robot si dichas botellas son
defectuosas, en ese caso se descartan y se encaminan a la zona de botellas defectuosas. Si no
son defectuosas se cargan en la caja hasta llegar a su capacidad máxima (diez en este caso),
una vez terminado el proceso la caja llena se desplaza hasta la zona de transporte.
En la zona de transporte se realiza un chequeo del estado de las cajas y se calcula su peso
junto con las botellas, en caso de que exista algún defecto en la caja se descartará, sino se
carga en el camión para proceder a su transporte.
Toda esta lógica está controlada por una librería para modelar dichos procesos.
En la figura 31 se observa la definición de dicha lógica organizada en las mismas zonas que
la parte visual.
55
Figura 31. Parte lógica simulación industria
Dentro de cada proceso se puede definir código adicional de Java aparte de su propia
codificación. Como Anylogic no posee ninguna manera de simular un PLC se ha utilizado
dicha funcionalidad para simular el comportamiento del PLC encargado de obtener la
información de las máquinas de la fábrica.
Para ello se ha utilizado una librería de Java llamada Kafka-clients
(https://kafka.apache.org/documentation/#producerapi), con esta librería se definen las
señales que se generan durante el proceso de fabricación de una caja llena de botellas. Se
instancia un productor en la zona de código adicional java que escriba en un topic de Kafka
llamado topicAnylogic todas las señales generadas por la simulación.
En la figura 32 se muestra la parte del código en la que se instancia dicho productor.
Figura 32. Instancia productor Kafka
Una vez instanciado el productor, se van enviando las señales según va avanzando el
proceso.
En la figura 33 se muestra como ejemplo la señal que se envía cuando la caja llega al
componente moveTo1.
56
Figura 33. Envío de una señal en el proceso moveTo1
Al enviar la señal se deben indicar tres parámetros, el primero es el topic al que quiere se
quiere enviar la señal, el segundo la clave del topic (en nuestro caso será la marca de tiempo
en la que se ha generado) y el tercero el mensaje que se quiere enviar que seguirá el formato
timestamp,identificador señal,valor.
De la misma manera que Anylogic no puede generar las señales del PLC tampoco puede
conectarse con KEPServerEX que es el programa encargado de mapear dichas señales, por
lo tanto, se ha tenido que definir un programa en eclipse que escriba las señales generadas
por Anylogic en KEPServerEX.
Para desarrollar dicho programa se ha utilizado la librería Java OPC Milo
(https://github.com/eclipse/milo), con esta librería se instancia el cliente que se conecta a
KEPServerEX.
En la figura 34 se muestra la creación del cliente de KepServer.
Figura 34. Creación cliente KEPServerEX
57
Para recoger las señales generadas por Anylogic se ha instanciado un consumidor de Kafka
que se conecte al topicAnylogic.
En la Figura 35 se muestra el fichero de propiedades necesario para la instanciación de dicho
consumidor.
Figura 35. Fichero propiedades consumidor kafka
Una vez consumidas las señales generadas por Anylogic se procede a su escritura en
KEPServerEX.
En la Figura la 36 se muestra la codificación de dicho proceso.
Figura 36. Codificación escritura en KEPServerEX
58
4.5.2 KEPServerEX
Para que KEPServerEX sea capaz de mapear las señales generadas por Anylogic se definen
siguiendo el proceso indicado en el punto 4.2.1 en un PLC de tipo simulador.
En la figura 37 se observa cómo queda el contenido de dicho PLC una vez creadas todas sus
señales.
Figura 37. Señales creadas en KEPServerEX
4.5.3 Apache Nifi
Tras la ejecución de Nifi se accede a través del navegador en localhost:8080 y se crea un

grupo de procesos que cumpla la función necesaria para esta arquitectura, para crear el grupo
de procesos se utiliza la barra de navegación ubicada en la parte superior.
En la figura 38 se observa como se ve la interfaz web después de crear el grupo de procesos
tfg.
59
Figura 38. Interfaz web Apache Nifi
En esta ventana se muestra la barra de navegación en dónde se encuentran botones como la

creación de procesos o grupo de procesos, también se indican otros parámetros como los
datos intercambiados y el estado de ejecución de los diferentes procesos. Pinchando en el
grupo de procesos se comienza a editar los que lo componen.
Apache Nifi tiene implementados numerosos procesos para conectarse con distintas
tecnologías Big Data, uno de ellos es el publicador de Kafka el cuál se utiliza en esta
implementación.
En la figura 39 se observa la selección de dicho proceso.
Figura 39. Ventana de selección de procesos
60
Cada proceso tiene su propia ventana de configuración, se accede a ella pulsando con el
botón derecho sobre el proceso, accediendo a configure/properties.
En la figura 40 se puede observar dicha ventana para el proceso PublishKafka_0_11.
Figura 40. Ventana de configuración publish Kafka
En esta ventana se encuentran varios parámetros importantes:

• Kafka Brokers: En este parámetro se indica la dirección ip donde se encuentra
lanzado apache Kafka.
• Security Protocol: Es el protocolo de seguridad que se ha configurado en Kafka.
• Topic Name: El topic en el que se quiere escribir los Flow files que salgan de este
proceso.
• Delivery Guarantee:
o Best Effort: Los Flow files son escritos en Kafka sin esperar la confirmación
de que se ha recibido bien el Flow file anterior. Esta es la opción que
usaremos en nuestro caso ya qué es la que asegura una mayor velocidad.
o Guarantee Single Node Delivery: Espera a escribir los Flow files
cuando reciba confirmación de recepción del Flow file anterior de un nodo
de Kafka.
o Guarantee Replicated Delivery: Solo tiene sentido en caso de usar Apache
Kafka de manera distribuida, espera a recibir confirmación de recepción del
Flow file de todas las réplicas de Kafka.
• Max Request Size: Se puede definir el tamaño máximo de las escrituras que se
realizan en Kafka.
En la pestaña settings se debe marcar la opción success, esto se debe a qué los Flow files que
se consigan escribir en Kafka deben abandonar el flujo de Nifi.
Es necesario incluir un proceso que se encargue de los Flow files en caso de que Kafka falle,
este proceso se llama log attribute y guarda en un fichero los Flow files que no se hayan
61
conseguido escribir en Kafka. Este caso solo sería posible en el caso de que Kafka no esté
distribuido y ocurra un error en la máquina que lo aloje.
Una vez creados estos dos procesos se deben unir pinchando sobre el proceso publish Kafka
y luego sobre el proceso log attribute para indicar el sentido del flujo. Una vez asociados se
indica que relación les une, en este caso será la de failure, es decir, que los Flow files que se
encaminen desde publish Kafka a log attribute son los que fallan.
El tercer y último proceso que se crea es el cliente OPC que se encarga de conectarse a
KEPServerEX y crear los Flow files a partir de sus señales. Al contrario que el proceso
publish Kafka esté proceso no está implementado en Nifi por lo que se debe codificar.
Para su codificación se sigue el tutorial disponible en
(https://medium.com/hashmapinc/creating-custom-processors-and-controllers-in-apache-
nifi-e14148740ea).
El primer paso es generar el proyecto con la herramienta apache Maven, esta es una
herramienta open-source que se creó en el 2001 con el objetivo de simplificar el proceso de
generación de proyectos [48]. Esta herramienta se descarga de su página principal
(https://maven.apache.org/) y se inicia su generador de proyectos interactivo ejecutando el
comando mvn archetype:generate.
Este comando lista los diferentes esqueletos de proyectos que contiene Maven, estos se
filtran con la palabra nifi y se selecciona nifi-bundle-processor-archetype. Una vez
seleccionado se indica que se introduzcan varias propiedades.
En la figura 42 se pueden observar las diferentes propiedades seleccionadas.
Figura 41. Configuración nifi-processor-archetype
Una vez creado se genera un proyecto Maven llamado nifi-opc-subscriptor que contiene
dos carpetas, una de ellas es nifi-anylogic-processor, dicha carpeta es el proyecto que se
modifica para realizar las acciones que necesita este proceso y la otra es nifi-anylogic-nar,
en ella una vez compilado el proyecto se generará el archivo que se incluye en nifi. Para su
62
mejor comprensión en la figura 42 se muestra el diagrama de clases del proyecto nifi-

anylogic-processor.
Figura 42. Diagrama clases nifi-anylogic-processor
Se profundizará en la codificación del fichero java que se encuentra en el paquete

es.nifi.tfg.processor.anylogic de la carpeta nifi-anylogic-processor llamado
MyProcessor.java ya que es el que se ha modificado para que se conecte a KEPServerEX,
se suscriba a sus señales y encamine los valores al proceso publishKafka.
La primera parte de dicho fichero se puede observar en la figura 43 en ella se definen los
parámetros que se tienen que rellenar antes de poder ejecutar el proceso y las relaciones que
se quieren definir con los demás procesos, toda esta configuración se ejecutará nada más
iniciar el proceso.
63
Figura 43. Inicialización proceso nifi
La segunda parte de fichero es la función que se ejecuta una vez que se indica al proceso que
arranque, para configurar dicha acción se rellena la función onEnabled del proceso. Para
64
realizar la conexión con KEPServerEX se utilizará la librería java vista anteriormente

llamada OPC MILO.
En la figura 44 se observa las acciones que ha de realizar el proceso al ejecutarse.
Figura 44. Definición función OnEnabled
En la figura 45 se observan cuáles son las acciones que se realizan con cada valor obtenido
de las suscripciones en la función onSubscriptionValue.
65
Figura 45. Acciones función onSubscriptionValue
La siguiente parte del proceso es la función onTrigger la cual se va ejecutando continuamente

y es la que va enviando las señales al proceso publishKafka.
En la figura 46 se puede observar su codificación.
Figura 46. Codificación función onTrigger
Una vez codificado todo el proceso se ejecuta el comando mvn clean install en la
carpeta raíz del proyecto. Este comando compila el proyecto y genera un archivo .nar en la
carpeta nifi-anylogic-nar/target.
Este archivo se incluye en la carpeta lib de nifi, cuando se ha incluido se reinicia nifi.
66
Después de reiniciarlo el proceso personalizado se habrá incluido en los procesos

predefinidos por nifi.
En la figura 47 se pueden ver definidas las propiedades personalizadas del proceso generado,
la url de KEPServerEX y el json con el namespaceindex y tag necesarios para conectarse a
cada señal.
Figura 47. Propiedades Opc Subscriptor
Una vez finalizada la configuración de este último proceso se puede observar en la figura 48
el grupo de procesos que se conecta a KEPServerEX, se suscribe a sus señales y envía los
valores a Kafka.
Figura 48. Propiedades Opc Subscriptor
67
4.5.4 Apache Kafka
En este punto iniciando Kafka y usando el comando mencionado anteriormente para abrir
un consumidor se pueden recibir en tiempo real las señales generadas por la fábrica simulada
en Anylogic por lo que se ha conseguido completar la implementación del Prototipo 0.
En la Figura 31 se observa los valores recibidos al iniciar la simulación.
Figura 49. Valores obtenidos en Kafka de la simulación de Anylogic
4.6 Apache Flink
Flink es la tecnología que se utiliza para el procesado de los datos en tiempo real.
Apache Flink se organiza en torno a la figura de los Jobs, estas son las funciones que tiene
que realizar Flink, es decir, serán los programas que se implementan para que escriban en
InfluxDB y calculen los datos agregados.
La arquitectura de Flink está formada por un JobManager que se encarga de coordinar los
Jobs y por varios TaskManager que realizan las tareas que les ordene el JobManager y
ejecutan los programas que se hayan codificado [49].
En la Figura 50 se observa dicha organización.
68
Figura 50. Arquitectura Flink

Fuente: https://www.adictosaltrabajo.com/2015/11/20/introduccion-a-apache-flink/
Cómo ocurría en el caso de Apache Kafka esta arquitectura está pensada para distribuirla en
varias máquinas con el fin de reducir la carga de trabajo en cada una de ellas. El JobManager
se encontraría en la máquina más potente y se distribuirían los TaskManager entre otras
máquinas para paralelizar el trabajo.
El primer paso para comenzar a utilizar Apache Flink es su descarga de la página oficial
(https://flink.apache.org/downloads.html), la última versión estable fue lanzada el 15 de
febrero de 2019 y corresponde con la versión 1.7.2.
Una vez descargado se procede a acceder a los ficheros de configuración, dentro de la carpeta
flink-1.7.2\conf existen ficheros para personalizar como se producen los logs y donde se
guardan, aunque los más importantes son flink-conf.yaml, masters y slaves.
En el primero se pueden configurar parámetros como la dirección ip y el puerto dónde se
lanzan el JobManager y la interfaz web, en este caso será en localhost y los puertos 6123
para el JobManager y 8081 para la interfaz web. En este fichero también se encuentran
opciones de configuración para ofrecer alta disponibilidad en el caso de que se ejecuten dos
instancias de Flink en dos máquinas diferentes.
En la figura 51 se indican los parámetros que se configurarán.
69
Figura 51. Fichero configuración flink-conf.yaml
Los ficheros masters y slaves se utilizan en el caso de distribuir la arquitectura, en el fichero

masters se indica la dirección ip de la máquina donde se ejecuta el JobManager, mientras
que, en el fichero slaves se indican las direcciones ip donde posteriormente se quieran
ejecutar los TaskManager. Cómo en este caso no distribuiremos la arquitectura estos ficheros
no serán configurados.
Una vez realizada la configuración necesaria se accede a través del terminal a la carpeta de
Flink y se ejecuta el siguiente comando para lanzarlo:
• .\bin\start-cluster.bat
Con la ejecución de este comando se lanza la interfaz web, un job manager y un task manager
en las direcciones que le hemos indicado en el fichero de configuración. Accediendo a través
del navegador en la dirección localhost:8081 se observa la interfaz web como podemos
comprobar en la figura 52.
Figura 52. Interfaz Web Apache Flink
70
En la interfaz se observan los TaskManagers que están disponibles y el estado de los Jobs
que se están ejecutando. En la ventana de navegación de la parte izquierda se puede
profundizar en toda esta información y entrando en el último enlace llamado submit new job
se pueden ejecutar los Jobs que se hayan implementado. En este caso se agregará un job que
consuma del topicPLC y calcule datos agregados para posteriormente escribirlos en el
topicProcesado. Estos datos junto con las señales en tiempo real se escriben en InfluxDB.
4.7 InfluxDB
InfluxDB es la base de datos en la que el job de Flink escribe las señales, es una base de
datos NoSQL basada en series temporales, es decir, todos los datos que se escriban deben
tener asociado un timestamp.
A su vez estas señales tienen asociado un parámetro llamado measurement dentro de
influxdb, este parámetro indica como se llama el grupo de medidas al que está asociado el
dato que se quiere escribir.

Para comenzar a usar InfluxDB se tiene que descargar desde
(https://portal.influxdata.com/downloads/) la última versión estable es la 1.7.3.
Una vez descargado se accede al fichero de configuración dentro de la carpeta influxdb-
1.7.3-1\influxdb.conf en él se pueden configurar aspectos como en que ubicación se guardan
los datos y los logs y las direcciones ip para el intercambio de datos por el protocolo udp y
http. En este caso interesa el protocolo http que se configurará en localhost y el puerto 8086.
4.8 Implementación Prototipo 1
Una vez configuradas las tecnologías necesarias para el desarrollo del segundo prototipo se
procede a su implementación.
El objetivo de este primer prototipo es conseguir implementar un job de flink que por un
lado consuma las señales del topicPLC y las escriba en InfluxDB y por otro lado que calcule
datos agregados y los escriba en el topicProcesado e InfluxDB. A continuación, se
profundizará en la implementación de cada tecnología que interviene en este prototipo.
4.8.1 Apache Flink
Se ha utilizado la librería flink-java-1.3.2 para realizar la implementación de los jobs

definidos en el punto 4.6.1.
El job codificado se encarga de consumir del topicPLC, calcula datos agregados y los
escribe en el topicProcesado una vez escrito escribe estos datos juntos con los datos realeso
en InfluxDB, para ello se hace uso de la librería java flink-connector-kafka-0.8 e influxdb-
java-1.8.
En la figura 53 se muestra el diagrama de clases del job.
71
Figura 53. Diagrama de clases job Flink
Debido a la complejidad y buscando su mejor comprensión en la figura 54 se muestra la

definición de la clase principal de Flink.
Figura 54. Definición clase principal Flink
Como se puede observar en la imagen anterior el proceso para recibir los datos de Kafka es
el siguiente:
• Creación del consumidor del topic necesario
• Creación del flujo de datos al que se van realizando diferentes acciones según la
naturaleza de estos mismos en la clase mfInfluxDBPoints. En esta clase se definen
que datos se escriben en tiempo real y cuales se utilizan para calcular datos
agregados.
• Una vez definidos se asocian al flujo de salida un lugar al que desembocar todos
estos datos, en este caso será un conector de InfluxDB en la cuál será escrito dicho
flujo.
72
Todos los parámetros necesarios para la configuración del consumidor de Kafka y el

conector InfluxDB se encuentran en dos ficheros .properties. En la figura 55 y 56
observamos su contenido.
Figura 56. influxConfig.properties
Figura 55. consumerConfig.properties
4.8.2 InfluxDB
Una vez realizada la configuración de InfluxDB se lanza con el archivo ejecutable llamado
influxd.exe. Después de haberlo ejecutado es posible utilizar el ejecutable influx.exe para
acceder a la consola de comandos propia de InfluxDB, en esta consola se procede a realizar
la configuración necesaria para este caso de uso.
Primero se crea la base de datos llamada industriaBBDD con el siguiente comando:
• CREATE DATABASE <nombre base de datos> REPLICATION
<número de réplicas>
En el caso de querer distribuir la base de datos habría que indicar un número mayor que uno
en el parámetro replication.
También es necesario crear una política de retención de datos y asociarla a la base de datos,
para este caso se crea una retención de tres meses, para poder ver la evolución de los datos
en este tiempo. Para realizar estas acciones se ejecuta el siguiente comando:
• CREATE RETENTION POLICY <nombre de la política de
retención> ON <nombre base de datos a la que se le
asocia> DURATION <duración para los datos con esta
política de retención> REPLICATION <número de réplicas>
En la figura 57 se observa el proceso completo de la configuración de InfluxDB.
73
Figura 57. Configuración InfluxDB
A través de la consola de InfluxDB se pueden realizar más acciones como el borrado de

bases de datos, políticas de retención y la exploración de datos por medio del lenguaje propio
de InfluxDB llamado InfluxQL. Todos estos parámetros se encuentran en la documentación
oficial de InfluxDB:
(https://docs.influxdata.com/influxdb/v1.7/query_language/database_management/#create
-retention-policies-with-create-retention-policy)
Una vez realizadas las configuraciones de Flink e InfluxDB se puede completar la
implementación del prototipo 1 y 2 ya que se podrá de observar en InfluxDB las señales
generadas por Anylogic en tiempo real.
En la figura 58 se muestra el valor de una de las señales creadas en tiempo real en la base de
datos tfg.
Figura 58. Query señal botellasATotales
4.9 Grafana
Grafana es la tecnología que se va a utilizar para visualizar los datos generados por los PLCs.

El primer paso para ejecutarlo es descargarlo de su página web oficial, la última versión
estable es la 6.0.2 en (https://grafana.com/get). Una vez descargado, en la carpeta de
grafana-6.0.2\conf\defaults.ini se puede configurar en qué dirección ip y puerto se ejecuta,
74
en este caso será localhost:3000, también se puede configurar el usuario y contraseña para
acceder a su interfaz web, en este caso admin/admin.
En la figura 59 y 60 se observa cómo queda el fichero de configuración.
Figura 60. Fichero de configuración grafana(Dirección ip)
Figura 59. Fichero configuración grafana (Seguridad)
Una vez configurado se ejecuta el archivo de la carpeta bin llamado grafana-server.exe. Se

accede a su interfaz web a través de la dirección ip proporcionada en el fichero de
configuración, en la página inicial se pide el usuario y contraseña previamente configurados.
La figura 61 representa la página principal de grafana una vez registrado.
Figura 61. Representación visual Grafana
En la parte izquierda se encuentra el panel de navegación con cuatro botones que permiten
manejar la aplicación:
75
• El número 1 permite acceder a la ventana dónde se pueden crear los diferentes

dashboards para representar visualmente las señales, estos se pueden agrupar y
guardar para posteriores usos.
• El segundo ayuda a manejar los dashboards guardados previamente, así como a
poder crear listas de estos mismos para que vayan rotando cada cierto tiempo.
• Con el tercer botón se accede al editor de alarmas en el cual se pueden definir
avisos que dependan del valor de algunas de las señales. Estas alarmas se pueden
notificar a través de telegram o correo electrónico.
• Por último, el botón número cuatro permite configurar las fuentes de datos, existen
varios tipos de conectores a bases de datos cómo InfluxDB, ElasticSearch,
Graphite, en este caso se usa la de InfluxDB.
En la figura 62 se representa la configuración de la base de datos de esta
arquitectura.
Figura 62. Configuración InfluxDB en Grafana
En este formulario se rellena el nombre de la base de datos, y el usuario y contraseña para

acceder a ella.
Una vez configurada la fuente de datos a la que se realizan las consultas se pasa a
implementar los dashboards.
76
4.10 Implementación Versión definitiva
Una vez definida la descarga y configuración de todas las tecnologías que componen esta
arquitectura y continuando con la implementación del prototipo 1 se ha procedido a la
implementación de dos dashboards, uno enfocado en el seguimiento de las cajas llamado
TFGCajas y otro en el seguimiento de las botellas llamado TFGBotellas.
Una vez realizada esta última implementación se cumplirá con el objetivo de poder visualizar
en tiempo real las señales generadas por Anylogic.
4.10.1 Dashboard TFGCajas
El dashboard TFGCajas está compuesto por distintos tipos de plugins, en este apartado se va
profundizando en cadauno de ellos en detalle, así como en las señales que consumen.
4.10.1.1 D3 Gauge
Este plugin es el utilizado para representar las velocidades de los elementos de la simulación,
en este caso se representa la velocidad que tiene una caja durante todo el flujo.
Figura 63. Configuración plugin D3Gauge
En la figura 63 se observa dicho plugin, así como las consultas que se ejecutan para obtener
dichos datos.En las pestañas de opciones se pueden configurar detalles como el aspecto y el
diseño de dicho plugin.
77
4.10.1.2 Table
En dicho plugin se pueden representar en formato tabla los valores de las señales que llegan
a la base de datos asociados a su timestamp. En este caso se utiliza para representar los
distintos pesos que tienen las cajas cuando están vacías y más tarde al llenarse.
En la figura 64 se observa la configuración de dicho plugin, así como las consultas que se
ejecutan para obtener dichos datos.
Figura 64. Configuración Plugin Table
En este plugin en las pestañas de opciones se puede cambiar su nombre, cambiar el estilo de
las columnas y el número de entradas por página.
4.10.1.3 Pie Chart
El plugin de tartas se utiliza para visualizar de forma clara una serie de datos
complementarios, en este caso se utiliza para representar las cajas fabricadas correctamente
y las fabricadas con errores. Existe uno de estos plugins para las cajas pequeñas otro para las
grandes y un último para las rojas.
78
Figura 65. Configuración Plugin Pie Chart TFGCajas
Las opciones adicionales de este plugin son las de cambiar el estilo entre donut o tarta,
indicar los colores para los datos o la posición de la leyenda.
En la figura 66 se muestra cómo se representa el dashboard completo.
79
Figura 66. Dashboard TFGCajas
Dentro de los dashboards existen varias opciones a configurar como el nombre del dashboard
la opción de guardarlos para su uso posterior o la posibilidad de compartirlo a través de una
url o un fichero, pero la opción más crítica es el selector de tiempo que se muestra recuadrado
en la figura 66 y más en detalle en la figura 67, en él se define el intervalo temporal que se
representa en el dashboard y el tiempo de refresco de los datos.
Figura 67. Selector de tiempo Grafana
4.10.2 Dashboard TFGBotellas
El dashboard TFGBotellas muestra los distintos datos relevantes de la producción de las

botellas ayudándose de distintos plugins de grafana que se definen a continuación.
4.10.2.1 Pie Chart
Este plugin sigue el mismo funcionamiento que el definido en el punto 4.10.1.3, en este caso
existen tres plugins de este tipo que ayudan a representar las botellasA, B y C que se fabrican
correcta o erróneamente.
80
Figura 68. Configuración PieChart TFGBotellas
4.10.2.2 Graph
Este plugin se utiliza para representar los datos de InfluxDB en un plano XY, el eje X es el
eje temporal y el Y tiene el valor de la señal seleccionada en la consulta. En este caso se ha
utilizado para representar las señales que indican que el detector de botellas A, B o C está
siendo utilizado.
81
Figura 69. Configuración plugin Graph
Las opciones adicionales de este plugin son la posibilidad de ajustar las unidades de los ejes,
cambiar el estilo de las líneas entre puntos o barras, cambiar los colores de las señales o
definir alertas en caso de que se supere un valor determinado.
4.10.2.3 Singlestat
Este plugin es utilizado para representar un valor en formato texto plano. En este caso se ha
utilizado para mostrar el porcentaje de botellas correctas en comparación con las botellas
totales generadas. Si el porcentaje es menor que un 40% se indicará en color rojo en señal
de que algo está fallando, entre 40% y 70% se indicará en amarillo y mayor del 70% en
verde.
82
Figura 70. Configuración Plugin Singlestat
Las opciones adicionales que tiene este plugin son de estilo, se puede personalizar la forma
en la que se representa el dato, así como los valores necesarios para activar los distintos
intervalos de color.
Una vez profundizado en los tres tipos de plugin que componen este dashboard en la figura
55 se muestra cómo se visualiza el dashboard completo.
Figura 71. Dashboard TFGBotellas
83
Una vez implementados los dos dashboards se completa la versión definitiva de la

arquitectura propuesta, es decir, somos capaces de extraer los datos de la simulación
desarrollada en Anylogic a través de KEPServerEX, encaminarlos a Apache Kafka a
través de Apache Nifi, con Apache Flink calcular datos agregados e indexar dichos cálculos
junto con los datos originales en InfluxDB y por último visualizar dichos datos en los
dashboards de Grafana. Todo este proceso se realiza con tiempos de refresco de menores
de 500ms sin pérdida de datos, lo que permite realizar una visualización en tiempo real de
lo que ocurre en la fábrica simulada, así como realizar consultas históricas en InfluxDB.
84
85
CONCLUSIONES
5. Conclusiones
Una vez finalizado el proyecto

• Se ha desarrollado una arquitectura Big Data orientada para las industrias que quieran
modernizarse y no quedarse obsoletas dentro de la cuarta revolución industrial en la
que estamos inmersos.
• Se ha logrado dotar a la arquitectura de las características que se pretendan:
seguridad, escalabilidad, velocidad y persistencia. Lo que implica que la elección de
los componentes de la arquitectura ha sido correcta.
o La simulación con Anylogic ha aportado una interfaz visual 3d moderna y la
capacidad de modelar procesos industriales, mientras que, con
KEPServerEX se ha conseguido simular todas las señales que generaría un
PLC en una industria.
o Apache Nifi ha permitido realizar una conexión segura, muy configurable y
escalable con KEPServerEX y Apache Kafka.
o Apache Kafka ha permitido crear un flujo de datos con una velocidad de
transmisión muy baja, así como tener una tecnología de transferencia de
señales escalable, persistente y segura.
o Apache Flink ha permitido desarrollar diferentes aplicaciones para tratar el
flujo de datos de Kafka lo que aporta una gran versatilidad a nuestra
arquitectura.
• En cuanto a la visualización y almacenaje de las señales se ha conseguido, utilizado
InfluxDB, almacenar grandes cantidades de datos ordenados a través de su
timestamp. Mediante este tipo de organización se ha conseguido que los tiempos de
acceso a la base de datos se reduzca. Por último, Grafana ha aportado la
representación visual de estas señales con diferentes gráficos originales y con un
diseño moderno.
• Debido a que muchas de estas tecnologías son muy recientes ha habido problemas a
la hora de desarrollar la arquitectura ya que alguno de los componentes como
Anylogic o Apache Nifi no poseían los conectores necesarios para conectarse con los
demás elementos de la arquitectura. Debido a que estos problemas eran intrínsecos a
dichas tecnologías (por tanto, con escasa documentación) la dificultad de su solución
se ha incrementado y se ha logrado subsanar mediante el desarrollo de nuevas
características:
o Anylogic es un simulador industrial que permite modelar numerosos
procesos industriales, pero no posee un simulador de PLC. Por ese motivo se
ha tenido que simular el funcionamiento de dicho elemento, mediante código
adicional que se ha podido incluir en Anylogic.
o Otro de los problemas que se ha encontrado ha sido en Apache Nifi ya que
esta tecnología tiene definidos numerosos conectores a otras tecnologías Big
Data, pero no han desarrollado ninguno que se conecte a un servidor OPC,
por lo que ha habido que desarrollar dicho conector.
• La elección de tecnologías que pertenecen al mismo ecosistema ha sido un acierto ya
que proporcionan una mayor facilidad para su configuración y conexión. Tanto
tecnologías como Apache Nifi, Apache Kafka y Apache Flink en el lado del
86
CONCLUSIONES
tratamiento de datos e InfluxDB y Grafana en el lado de la persistencia y

representación de datos están desarrolladas con el objetivo de trabajar juntas.
• Por último, los resultados obtenidos gracias a la simulación han sido muy positivos
ya que se ha conseguido representar más de 30 señales con tiempos de refresco
menores de 500ms en tiempo real, así como almacenarlas en una base de datos con
una persistencia de 3 meses. Esto aporta a las industrias una gran capacidad de
reacción gracias a que saben lo que está sucediendo en su proceso industrial en
tiempo real, y junto con la capacidad de analizar los datos históricos se pueden
deducir tendencias.
87
TRABAJOS FUTUROS
6. Trabajos futuros
Se proponen unas posibles líneas de trabajo con el objetivo de perfeccionar, mejorar y añadir
posibles funcionalidades a la arquitectura:
• Desarrollo de una API en Apache Nifi personalizada para un cliente con el objetivo
de monitorizar el estado de KEPServerEX y poder realizar cambios en él. En Apache
Nifi al igual que se ha podido desarrollar el proceso que se conecta a KEPServerEX
se pueden implementar otros posibles procesos para, ayudándonos de una Api propia
que ha desarrollado KEPServerEX (https://www.kepware.com/en-
us/products/kepserverex/features/configuration-api/) monitorizar el estado del
servidor y poder realizar cambios en él desde Apache Nifi.
• Estudio de diferentes algoritmos de machine learning y mantenimiento predictivo en
Flink con el objetivo de poder desarrollar Jobs en Flink que analizando los valores
almacenados en InfluxDB puedan deducir tendencias para anticiparse a los fallos de
las máquinas de la industria.
• Desarrollar gráficos personalizados en Grafana utilizando el tutorial
(https://grafana.com/docs/plugins/developing/development/) de esta manera se
tendrá mucha más libertad a la hora de mostrar los diferentes datos de InfluxDB ya
que se desarrollaría desde cero el gráfico que se necesitase.
• Investigar el funcionamiento de la programación de alarmas en Grafana para poder
notificar por bots de telegram y/o correo las alarmas que se produzcan a los usuarios
con permisos.
88
TRABAJOS FUTUROS
89
PRESUPUESTO
7. Presupuesto
En este apartado se van a definir los costes asociados para la empresa que quisiese desarrollar
la arquitectura y su correspondiente simulación.
7.1 Costes
7.1.1 Costes software
Tabla 1. Costes asociados al software necesario para el desarrollo del proyecto
7.1.2 Costes mano de obra
Para definir el coste asociado a la mano de obra necesaria para el desarrollo de la arquitectura
y simulación se deben estimar las horas necesarias para finalizar dicho proyecto.
Tabla 2. Estimación fases del proyecto (horas)
Figura 72. Estimación fases del proyecto
Una vez definida la estimación de horas de trabajo que en total será de 464 horas hace falta
definir el coste de la mano de obra necesaria para finalizar el proyecto, el número de personas
que compondrán el equipo y las horas que le dedicarán. En la tabla 3 se definen dichos
parámetros y se calcula el coste total de la mano de obra. Los salarios definidos según el
puesto del trabajador son estimaciones basadas en el siguiente estudio de remuneración
(https://www.michaelpage.es/prensa-estudios/estudios/estudios-de-remuneracion)
90
PRESUPUESTO
Tabla 3. Costes asociados a la mano de obra
7.2 Presupuesto total
El presupuesto total que habría que gastar en el proyecto se define en la tabla 4.
Tabla 4. Presupuesto total proyecto
91
REFERENCIAS
8. Referencias
[1] A. Rayón, «Arquitectura Lambda para sistemas Big Data (y III) - Deusto Data,» 9 Octubre
2016. [En línea]. Available: https://blogs.deusto.es/bigdata/arquitectura-lambda-para-
sistemas-big-data-y-iii/. [Último acceso: 12 Febrero 2019].
[2] M. Hausenblas y N. Bijnens, «Lambda Architecture » λ lambda-architecture.net,» 2017.
[En línea]. Available: http://lambda-architecture.net/. [Último acceso: 12 Febrero 2019].
[3] N. Marz y J. Wrren, Big Data, Principles and best practices of scalable real-time data
systems, Estados Unidos: Manning Publications, 2015.
[4] B. Vera-Tudela, «Arquitectura Lambda: Combinando lo mejor de dos mundos,» SG -
Software Guru, nº 52, p. 27, 2016.
[5] J. Domínguez, «De Lambda a Kappa: evolución de las arquitecturas Big Data -
Paradigma,» 16 Abril 2018. [En línea]. Available:
https://www.paradigmadigital.com/techbiz/de-lambda-a-kappa-evolucion-de-las-
arquitecturas-big-data/. [Último acceso: 12 Febrero 2019].
[6] M. Zorrilla, «tema 3.2 Arquitecturas y tecnologías para el big data,» Enero 2017. [En
línea]. Available:
https://ocw.unican.es/pluginfile.php/2396/course/section/2473/tema%203.2%20Arquite
cturas%20y%20tecnologi%CC%81as%20para%20el%20big%20data.pdf. [Último
acceso: 12 Febrero 2019].
[7] J. Careaga, «Arquitectura Lambda vs Arquitectura Kappa - PDF,» 2017. [En línea].
Available: https://docplayer.es/65157889-Arquitectura-lambda-vs-arquitectura-
kappa.html. [Último acceso: 12 Febrero 2019].
[8] M. Pathirage, «Kappa Architecture - Where Every Thing Is A Stream,» [En línea].
Available: http://milinda.pathirage.org/kappa-architecture.com/. [Último acceso: 12
Febrero 2019].
[9] J. Kreps, «Questioning the Lambda Architecture - O'Reilly Media,» 2 Julio 2014. [En
línea]. Available: https://www.oreilly.com/ideas/questioning-the-lambda-architecture.
[Último acceso: 14 Febrero 2019].
[10] «AnyLogic: Software de Simulación - Opiniones y precios,» [En línea]. Available:
https://www.appvizer.es/it/simulacion/anylogic. [Último acceso: 14 Febrero 2019].
[11] «AnyLogic Timeline,» Anylogic Simulation Software, [En línea]. Available:
https://www.anylogic.com/company/timeline/. [Último acceso: 14 Febrero 2019].
[12] «Vijeo Citect Sistema de supervisión SCADA - PDF,» Schneider Electric, 2016. [En
línea]. Available: https://docplayer.es/2716282-Vijeo-citect-sistema-de-supervision-
scada.html. [Último acceso: 14 Febrero 2019].
[13] «Citect SCADA - High Performance SCADA Software,» [En línea]. Available:
https://sw.aveva.com/monitor-and-control/hmi-supervisory-and-control/citect-
scada?option=com_content&view=article&id=1629&Itemid=1647. [Último acceso: 15
Febrero 2019].
[14] «Simulate OPC Data with the free MatrikonOPC Simulation Server,» Marikon, [En
línea]. Available: https://www.matrikonopc.es/products/opc-drivers/opc-simulation-
server.aspx. [Último acceso: 16 Febrero 2019].
92
REFERENCIAS
[15] «Demo Download Content Gate,» kepware, [En línea]. Available:

https://www.kepware.com/en-us/content-gates/ex-demo-download-content-
gate/?product=d2239b8c-36f2-4d07-8fbd-e223d0e26bbf&gate=636586d4-cffb-42f0-
add1-efa5504e6043. [Último acceso: 16 Febrero 2019].
[16] «KEPServerEX Connectivity Platform | OPC Server | Kepware,» Kepware, [En línea].
Available: https://www.kepware.com/en-us/products/kepserverex/. [Último acceso: 16
Febrero 2019].
[17] «Node-RED : About,» Node-RED, [En línea]. Available: https://nodered.org/about/.
[18] D. Dorofeev, «Open Source ETL: Apache NiFi vs Streamsets | Statsbot Blog,» statsbot
blog, 25 Abril 2018. [En línea]. Available: https://statsbot.co/blog/open-source-etl/.
[19] «Apache Nifi,» [En línea]. Available: https://nifi.apache.org/index.html. [Último acceso:
18 Febrero 2019].
[20] A. Carr, «Comparing Apache Kafka, Amazon Kinesis, Microsoft Event Hubs and Google
Pub/Sub,» Scott Logic, 17 Abril 2018. [En línea]. Available:
https://blog.scottlogic.com/2018/04/17/comparing-big-data-messaging.html. [Último
[21] «5 Most Important Difference Between Apache Kafka vs Flume,» EDUCBA, [En línea].
Available: https://www.educba.com/apache-kafka-vs-flume/. [Último acceso: 19 Febrero
2019].
[22] L. Gracia, «¿Qué es Apache Flume?,» Un poco de Java y +, 25 Octubre 2012. [En línea].
Available: https://unpocodejava.com/2012/10/25/que-es-apache-flume/. [Último acceso:
19 Febrero 2019].
[23] «Apache Flume,» Big Data Dummy, 7 Febrero 2017. [En línea]. Available:
https://bigdatadummy.com/2017/02/07/apache-flume/. [Último acceso: 19 Febrero
2019].
[24] «What Is Cloud Pub/Sub?,» Google Cloud, [En línea]. Available:
https://cloud.google.com/pubsub/docs/overview. [Último acceso: 19 Febrero 2019].
[25] D. Calvo, «Apache Kafka,» 27 Junio 2018. [En línea]. Available:
http://www.diegocalvo.es/kafka/. [Último acceso: 20 Febrero 2019].
[26] V. Madrid, «Aprendiendo Apache Kafka (Parte 1): Introducción,» En mi local funciona,
27 Septiembre 2018. [En línea]. Available: https://enmilocalfunciona.io/aprendiendo-
apache-kafka-parte-1/. [Último acceso: 20 Febrero 2019].
[27] «Apache Kafka,» Big Data Dummy, 1 Febrero 2017. [En línea]. Available:
https://bigdatadummy.com/2017/02/01/apache-kafka/. [Último acceso: 20 Febrero 2019].
[28] «Apache Kafka,» [En línea]. Available: https://kafka.apache.org/intro. [Último acceso:
20 Febrero 2019].
[29] A. Requena, «Qué es Apache Spark,» OpenWebinars, 2 Julio 2018. [En línea]. Available:
https://openwebinars.net/blog/que-es-apache-spark/. [Último acceso: 22 Febrero 2019].
[30] «Apache Spark: las ventajas de usar el nuevo 'rey' de Big Data,» BBVAOPEN4U, 25
Septiembre 2015. [En línea]. Available: https://bbvaopen4u.com/es/actualidad/apache-
spark-las-ventajas-de-usar-al-nuevo-rey-de-big-data. [Último acceso: 22 Febrero 2019].
93
REFERENCIAS
[31] M. Roues, «What is Apache Spark?,» TechTarget, Junio 2017. [En línea]. Available:
https://searchdatamanagement.techtarget.com/definition/Apache-Spark. [Último acceso:
22 Febrero 2019].
[32] J. I. Díez y M. Zaforas, «Vuela con tus datos usando Apache Flink,» Paradigma Digital,
16 Febrero 2017. [En línea]. Available: https://www.paradigmadigital.com/dev/vuela-
tus-datos-usando-apache-flink/. [Último acceso: 22 Febrero 2019].
[33] A. Handler, «Introducción a Apache Flink,» Adictos al trabajo, 20 Noviembre 2015. [En
línea]. Available: https://www.adictosaltrabajo.com/2015/11/20/introduccion-a-apache-
flink/. [Último acceso: 22 Febrero 2019].
[34] «Apache Flink: What is Apache Flink?,» [En línea]. Available:
https://flink.apache.org/flink-architecture.html. [Último acceso: 22 Febrero 2019].
[35] M. Zaforas, «Cassandra, la dama de las bases de datos NoSQL - Paradigma,» 17 Marzo
2016. [En línea]. Available: https://www.paradigmadigital.com/dev/cassandra-la-dama-
de-las-bases-de-datos-nosql/. [Último acceso: 25 Febrero 2019].
[36] C. Churilo, «InfluxDB vs Cassandra | Time Series Metrics and Events,» 18 Diciembre
2018. [En línea]. Available: https://www.influxdata.com/blog/influxdb-vs-cassandra-
time-series/. [Último acceso: 25 Febrero 2019].
[37] C. Peñas, «Análisis de datos de monitorización en InfluxDB con Python,» 27 Diciembre
2016. [En línea]. Available: https://thecocktail.engineering/analisis-de-datos-de-
monitorizacion-en-influxdb-con-python-9e1f727a90a4. [Último acceso: 25 Febrero
2019].
[38] «Understanding InfluxDB & the TICK Stack | InfluxData,» InfluxData, [En línea].
Available: https://www.influxdata.com/time-series-platform/influxdb/. [Último acceso:
25 Febrero 2019].
[39] «Zeppelin,» zeppelin-project, [En línea]. Available: http://zeppelin-project.org/. [Último
[40] L. Gracia, «¿Qué es Zeppelin? (el Notebook BigData) – Un poco de Java y +,» 8 Febrero
2016. [En línea]. Available: https://unpocodejava.com/2016/02/08/que-es-zeppelin-el-
notebook-bigdata/. [Último acceso: 26 Febrero 2019].
[41] C. Atrahouch Echarrouti, «Introducción a Kibana - Adictos al trabajo,» 27 Diciembre
2015. [En línea]. Available: https://www.adictosaltrabajo.com/2015/12/27/introduccion-
a-kibana/. [Último acceso: 26 Febrero 2019].
[42] «Kibana: Explore, Visualize, Discover Data | Elastic,» Elastic, [En línea]. Available:
https://www.elastic.co/es/products/kibana/. [Último acceso: 26 Febrero 2019].
[43] «Grafana: sistema de monitorización - 𝗮𝗰𝗸storm,» ackstorm, 7 Febrero 2018. [En línea].
Available: https://ackstorm.com/grafana-sistema-monitorizacion/. [Último acceso: 26
Febrero 2019].
[44] «AnyLogic Reviews and Pricing - 2019,» Capterra, [En línea]. Available:
https://www.capterra.com/p/95940/AnyLogic/. [Último acceso: 28 Febrero 2019].
[45] «Cassandra vs. InfluxDB Comparison,» DB-Engines, [En línea]. Available: https://db-
engines.com/en/system/Cassandra%3BInfluxDB. [Último acceso: 1 Marzo 2019].
[46] «Apache NiFi Documentation,» Apache Nifi Team, [En línea]. Available:
https://nifi.apache.org/docs.html. [Último acceso: 10 Marzo 2019].
94
REFERENCIAS
[47] D. Calvo, «Apache Nifi - Diego Calvo,» 27 Junio 2018. [En línea]. Available:
http://www.diegocalvo.es/nifi/. [Último acceso: 10 Marzo 2019].
[48] A. M. d. C. García Oterino, «Simple y rápido. Entiende qué es Maven en menos de 10
min. - Javier Garzás,» 6 Junio 2014. [En línea]. Available:
https://www.javiergarzas.com/2014/06/maven-en-10-min.html. [Último acceso: 19
Marzo 2009].
[49] A. Handler Gamboa, «Introducción a Apache Flink - Adictos al trabajo,» 20 Noviembre
2015. [En línea]. Available: https://www.adictosaltrabajo.com/2015/11/20/introduccion-
a-apache-flink. [Último acceso: 29 Marzo 2019].
95

TFG Alejandro Cantero Casares

Cargado por

Copyright:

Formatos disponibles

TFG Alejandro Cantero Casares

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TFG Alejandro Cantero Casares

Cargado por

Copyright:

Formatos disponibles

ESCUELA TÉCNICA SUPERIOR DE

PROYECTO FIN DE GRADO

TÍTULO: Arquitectura Big Data para el procesamiento de señales en

AUTOR: Alejandro Cantero Casares

TITULACIÓN: Ingeniería Telemática

TUTOR: Gregorio Rubio Cifuentes

DEPARTAMENTO: Ingeniería Telemática y Electrónica (DTE)

Miembros del Tribunal Calificador:

PRESIDENTE: Antonio Pérez Yuste

TUTOR: Gregorio Rubio Cifuentes

SECRETARIO: Carlos Ramos Nespereira

Fecha de lectura: 26 de junio de 2019

Figura 1. Arquitectura Lambda.................................................................................. 19

• CEO: Chief Executive Officer

En la actualidad estamos inmersos en la cuarta revolución industrial también conocida como

En este capítulo se va a realizar un repaso a las arquitecturas y tecnologías que se están

2.1 Arquitecturas Big Data

Como respuesta a la necesidad de recoger un gran volumen de datos de las empresas y

2.1.1 Arquitectura Lambda

Figura 1. Arquitectura Lambda

Las características de dicha arquitectura son las siguientes:

Figura 2. Arquitectura Kappa

La capa de real-time ejecuta las actividades de procesamiento en línea y las actualizaciones

• Todo el proceso se realiza con un único stream.

Figura 3. Elementos Arquitectura TFG

2.2 Tecnologías Big Data

2.2.1 Simuladores industriales

Anylogic es un software de simulación creado por la empresa estadounidense Anylogic en

Figura 4. Aspecto visual Anylogic

2.2.1.2 Vijeo Citect

Vijeo Citect es un programa que se centra en la simulación visual de sistemas industriales

Figura 5. Interfaz gráfico Vijeo Citect

2.2.2 Servidores OPC

Se necesita una tecnología capaz tanto de simular el funcionamiento de un PLC como de

2.2.2.1 MatrikonOPC Simulation Server

Es un programa gratuito desarrollado por la empresa Matrikon está enfocado en el desarrollo

2.2.3 Ingesta/Acceso datos

Figura 6. Representación editor programación Node-Red

2.2.3.2 Streamsets Data Collector

Streamsets Data Collector fué desarrollado en California en 2014 cómo un proyecto de

Figura 7. Interfaz visual StreamSets

2.2.3.3 Apache Nifi

Figura 8. Editor web Apache NIFI

2.2.4 Plataforma de Streaming

2.2.4.1 Apache Flume

2.2.4.2 Google Pub/Sub

Figura 9. Precios Google Pub/Sub

2.2.4.3 Apache Kafka

Apache Kafka es un software de código abierto, comenzó en 2009 a cargo de la empresa

Está programado en Scala que es un lenguaje de programación orientado a objetos, dispone

Figura 10. Esquema Publicador/Suscriptor

2.2.5 Procesado en tiempo real

2.2.5.1 Apache Spark

2.2.5.2 Apache Flink

Apache Flink comenzó como un proyecto de investigación surgido de la colaboración de

Las características principales de Flink son:

2.2.6 Persistencia de datos

Para realizar la función de la persistencia en la arquitectura necesitaríamos utilizar una base

2.2.7 Representación de datos