TRABAJO FINAL DE ESTUDIOS
Transcript of TRABAJO FINAL DE ESTUDIOS
TRABAJO FINAL DE ESTUDIOS INGENIERÍA ELECTRICA
Oriol Gumà Bruque
Gestión de los flujos de comunicación de una planta
industrial
Director: Delgado Prieto, Miguel
Codirector: Fernández Sobrino, Ángel
Convocatoria: Enero 2021
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
I declare that,
the work in this Master Thesis / Degree Thesis (choose one) is completely my own work,
no part of this Master Thesis / Degree Thesis (choose one) is taken from other people’s work without giving them credit,
all references have been clearly cited,
I’m authorised to make use of the company’s / research group (choose one) related information I’m providing in this document (select when it applies).
I understand that an infringement of this declaration leaves me subject to the foreseen disciplinary actions by The Universitat Politècnica de Catalunya - BarcelonaTECH.
Student Name Signature Date
Title of the Thesis: Gestión de los flujos de comunicación de una planta industrial
16/01/2021
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
Índice
1. Introducción .......................................................................................................................... 1
1.1. Objetivo ......................................................................................................................... 1
1.2. Motivación .................................................................................................................... 1
1.3. Alcance .......................................................................................................................... 2
1.4. Justificación ................................................................................................................... 2
2. Estado del arte: Contexto de Industria 4.0 ........................................................................... 3
2.1. Internet of Things .......................................................................................................... 4
2.1.1. Arquitectura IoT .................................................................................................... 5
2.1.2. Convergencia IT – OT ............................................................................................. 7
2.1.3. Factores Clave ....................................................................................................... 8
2.2. Protocolos de comunicación ....................................................................................... 12
2.2.1. Bus CAN ............................................................................................................... 13
2.2.2. Profibus ............................................................................................................... 15
2.2.3. Modbus ............................................................................................................... 17
2.2.4. Ethernet ............................................................................................................... 19
2.2.5. HTTP .................................................................................................................... 20
3. Caso de estudio: Planta de producción ............................................................................... 21
3.1. Célula flexible .............................................................................................................. 22
3.2. Sensores ...................................................................................................................... 22
3.2.1. Sensores Fotoeléctricos ...................................................................................... 22
3.2.2. Sensores Inductivos ............................................................................................. 23
3.3. Actuadores .................................................................................................................. 24
3.3.1. Electroválvulas..................................................................................................... 24
3.3.2. Retenedores ........................................................................................................ 25
3.3.3. Plataformas ......................................................................................................... 26
3.4. Pulmón ........................................................................................................................ 26
3.5. Flujo de trabajo ........................................................................................................... 27
3.6. Datos obtenidos de la planta ...................................................................................... 28
4. Diseño e implementación de la arquitectura IoT ................................................................ 30
4.1. Softwares ..................................................................................................................... 31
4.1.1. Node-RED ............................................................................................................ 31
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
4.1.2. InfluxDB ............................................................................................................... 45
4.1.3. Grafana ................................................................................................................ 53
5. Validación ............................................................................................................................ 58
5.1. PLC → Node-RED ........................................................................................................ 58
5.1.1. Descripción del ensayo: Lectura de datos ........................................................... 58
5.1.2. Resultados esperados: Lectura de datos ............................................................. 59
5.1.3. Resultados obtenidos: Lectura de datos ............................................................. 59
5.2. Node-RED → InfluxDB ................................................................................................ 60
5.2.1. Descripción del ensayo: Acondicionamiento de los Datos ................................. 60
5.2.2. Resultados esperados: Acondicionamiento de los Datos ................................... 61
5.2.3. Resultados obtenidos: Acondicionamiento de los Datos .................................... 61
5.3. InfluxDB → Grafana ................................................................................................... 63
5.3.1. Descripción del ensayo: Conexión con InfluxDB ................................................. 63
5.3.2. Resultados esperadores: Conexión con InfluxDB ................................................ 65
5.3.3. Resultados obtenidos: Conexión con InfluxDB ................................................... 65
6. Trabajo futuro ..................................................................................................................... 65
7. Conclusiones........................................................................................................................ 66
8. Bibliografía .......................................................................................................................... 68
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
Sumario de Figuras
Figura 1: diagrama de las revoluciones industriales ..................................................................... 3
Figura 2: modelo de IoT ................................................................................................................ 5
Figura 3: Arquitectura IoT (A: 3 capas, B: 5 capas) ........................................................................ 6
Figura 4: Convergencia OT y IT ...................................................................................................... 8
Figura 5: Volumen de datos vs año ............................................................................................... 9
Figura 6: Cloud computing .......................................................................................................... 10
Figura 7: modelo de servicios de la nube. ................................................................................... 12
Figura 8: Protocolo Bus CAN ....................................................................................................... 14
Figura 9: Señal del protocolo Bus CAN ........................................................................................ 14
Figura 10: Estructura trama Bus CAN .......................................................................................... 15
Figura 11: Trama de Profibus ...................................................................................................... 15
Figura 12: Estructura Profibus DP/PA ......................................................................................... 16
Figura 13: Protocolo Modbus RTU y TCP/IP ................................................................................ 18
Figura 14: Protocolo Ethernet industrial ..................................................................................... 19
Figura 15: Protocolo HTTP ........................................................................................................... 20
Figura 16: Laboratorio de automatización .................................................................................. 21
Figura 17: Funcionamiento Sensor Fotoeletrico de barrera Emisor-Receptor ........................... 23
Figura 18: Funcionamiento sensor Barrera Reflectiva ................................................................ 23
Figura 19: Funcionamiento sensor inductivo .............................................................................. 24
Figura 20: Funcionamiento Electroválvula .................................................................................. 25
Figura 21: Retenedor con sensor inductivo ................................................................................ 25
Figura 22: Plataforma de la celda de trabajo .............................................................................. 26
Figura 23: Pulmón ....................................................................................................................... 27
Figura 24: Diagrama flujo de trabajo .......................................................................................... 28
Figura 25: Diagrama de flujo de información .............................................................................. 30
Figura 26: Logo de Node-RED ...................................................................................................... 32
Figura 27: Versiones soportadas por Node-RED ......................................................................... 32
Figura 28: Ejecución de Node-RED .............................................................................................. 33
Figura 29: pantalla principal Node-RED ...................................................................................... 33
Figura 30: Menú de Node-RED .................................................................................................... 34
Figura 31: Librerías de Node-RED................................................................................................ 35
Figura 32: Mensaje de advertencia de instalación ...................................................................... 35
Figura 33: Documentación librería .............................................................................................. 36
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
Figura 34: Bloque de función ...................................................................................................... 36
Figura 35: Bloque Inject .............................................................................................................. 37
Figura 36: Editor del bloque inject .............................................................................................. 37
Figura 37: Bloque Modbus Flex Getter ....................................................................................... 37
Figura 38: Bloque InfluxDB batch ................................................................................................ 38
Figura 39: Editor bloque InfluxDB batch ..................................................................................... 39
Figura 40: Bloque debug ............................................................................................................. 39
Figura 41: Editor bloque debug ................................................................................................... 40
Figura 42: Bloque Link in/ Link out .............................................................................................. 40
Figura 43: Diagrama petición de datos ....................................................................................... 41
Figura 44: Diagrama tratamiento de datos ................................................................................. 43
Figura 45: Logo InfluxDB ............................................................................................................. 45
Figura 46: Ejecución InfluxDB ...................................................................................................... 46
Figura 47: Base de datos InfluxDB con el comando SHOW DATABASES ..................................... 47
Figura 48: políticas de retención ................................................................................................. 49
Figura 49: Operaciones permitidas en la cláusula WHERE ......................................................... 51
Figura 50: Logo Grafana .............................................................................................................. 53
Figura 51: Web de descarga de Grafana ..................................................................................... 54
Figura 52: Página principal de Grafana ....................................................................................... 54
Figura 53: Pagina de descarga de Plugins ................................................................................... 55
Figura 54: Comando a ejecutar para la instalación del plugin .................................................... 55
Figura 55: Servicio que está ejecutando Grafana. ...................................................................... 56
Figura 56: Pagina creación de un nuevo dashboard ................................................................... 56
Figura 57: Diagrama dibujado para el dashboard ....................................................................... 57
Figura 58: Reglas de mapeo. ....................................................................................................... 57
Figura 59: Diagrama escritura datos en servidor ficticio Node-RED ........................................... 58
Figura 60: Prueba funcional escritura y lectura datos ficticios. .................................................. 59
Figura 61. Resultados obtenidos en la prueba funcional ............................................................ 60
Figura 62: pruebas operacionales del acondicionamiento de los datos. .................................... 60
Figura 63: Resultado agregación datos a InfluxDB ...................................................................... 61
Figura 64: Resultado funcional del detector de nuevos datos .................................................... 62
Figura 65: Prueba Operacional datos retenedores ..................................................................... 62
Figura 66: Añadir una base de datos ........................................................................................... 63
Figura 67: configuración data source .......................................................................................... 64
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
Figura 68: Query montada por Grafana ...................................................................................... 64
Figura 69: Test de conexión correcto .......................................................................................... 65
Figura 70: Prueba conexión a InfluxDB a través del Dashboard ................................................. 65
Figura 71: Desviación anómala de la mediana. ........................................................................... 66
Sumario de Tablas
Tabla 1: Modelo OSI .................................................................................................................... 13
Tabla 2. Perfiles, características y aplicaciones de Profibus. ...................................................... 17
Tabla3: Ejemplo de dialogo HTTP ................................................................................................ 21
Tabla 4: Datos de cada retenedor ............................................................................................... 29
Tabla 5: Parámetros para la petición de datos a Modbus .......................................................... 38
Tabla 6: Función Petición datos 01 ............................................................................................. 41
Tabla 7: Función String1 .............................................................................................................. 41
Tabla 8: Función concatenar ....................................................................................................... 42
Tabla 9: Función Datos retenedores ........................................................................................... 43
Tabla 10: Código Detector nuevos datos .................................................................................... 45
Tabla 11: Ejemplo ALTER RETENTION POLICY ............................................................................. 50
Tabla 12: Ejemplo cláusula SELECT ............................................................................................. 51
Tabla 13: Ejemplo cláusula WHERE ............................................................................................. 51
Tabla 14: Ejemplo clausula GROUP BY ........................................................................................ 52
Tabla 15: Ejemplo función LIMIT ................................................................................................. 52
Tabla 16: Ejemplo function COUNT ............................................................................................. 52
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
GLOSARIO
IoT: Siglas de Internet of Things. Red que interconecta objetos de la vida cuotidiana
para permitirles intercambiar información.
IT: Information Technology. Mayoritariamente aplicaciones que funcionan sobre bases
de datos relacionales.
OT: Operational Technology. Todo hardware y software que detecta o genera un
cambio en procesos industriales.
PLC: Siglas de Programmable Logic Controller. Computadora utilizada en
automatización industrial para controlar procesos secuenciales. Programado por el
usuario, un PLC ejecuta un programa lógico para dar ordenar a periféricos y ejecutar
tareas.[6]
API: En inglés, Application Programming Interface. Conjunto de subrutinas, funciones
y procedimientos que ofrece una librería para ser utilizado por otro software como una
capa de abstracción.[4]
Go: Lenguaje de programación desarrollado por Google inspirado en la sintaxis de C y
su rendimiento, a la vez que intenta ser dinámico como Python.[1]
TCP: Siglas de Transmission Control Protocol. Es un protocolo orientado a la conexión
dentro del nivel de transporte del modelo OSI. Permite la entrega de paquetes de
forma fiable llamados segmentos.
IP: En inglés, Internet Protocol. Protocolo clasificado en la capa de rede del modelo
OSI. A través de distintas redes físicas previamente enlazadas permite el uso
bidireccional en origen o destino de comunicación para transmitir paquetes
conmutados.[3]
HTML: Lenguaje de Marcado de Hypertexto por sus siglas en ingles “HyperText Markup
Language”, es un lenguaje que pertenece a la familia de los “lenguajes de marcado” y
es utilizado para la elaboración de páginas web.
UTC: Son las siglas de Universal Time Coordinated (Tiempo coordinado universal). Es la
zona horaria de referencia respecto de la cual se calculan todas las horas
correspondientes a las otras zonas horarios del mundo.
CSV: Tipo de archivo con un carácter de control que se usa para delimitar columnas.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
1
1. Introducción
1.1. Objetivo
El Objetivo del trabajo final de estudios es la gestión de los flujos de comunicaciones,
creando así una arquitectura IT de una planta industrial, para posteriormente poder
tratar los datos de forma adecuada a las necesidades que se deseen. El propósito de
tener una arquitectura IT es para luego poder crear aplicaciones basadas en la nube para
poder gestionar la cantidad de datos. Las aplicaciones a desarrollar pueden ir desde
monitorización de la planta a detección de umbrales, tanto como predicción de
mantenimiento. En este proyecto se desarrollará una aplicación para monitorización de
la planta.
1.2. Motivación
Debido al aumento en la necesidad de gestión de los flujos de información y el análisis
de gran cantidad de datos en la industria, se ha decidido hacer este trabajo como
formación sobre el mundo de la cuarta revolución industrial o también conocida como
industria 4.0. Cada vez más se están digitalizando los procesos de fabricación y por
consiguiente los puestos de trabajo a día de hoy se están moviendo más a la gestión y
análisis de sistemas de información y reporting.
También al realizar prácticas laborales en Accenture sobre el mantenimiento de un BI,
me ha gustado poder enfocar algo de los conocimientos obtenidos en el mundo de la
información a aspectos más industriales y temas relacionados con la ingeniería e incluso
con la asignatura de automatización de la carrera.
Es una gran oportunidad poder aprender más sobre este aspecto de la industria ya que
mi salida al mundo laboral entra de lleno en la industria 4.0 y se debe tener
conocimientos sobre estos aspectos para lograr a ser un gran ingeniero en el futuro.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
2
1.3. Alcance
El alcance del trabajo se basará en los siguientes puntos:
- Diferenciación de los elementos de la planta
- Entendimiento del funcionamiento de la celda de trabajo
- Estudio de las comunicaciones entre los diferentes softwares
- Estudio de los protocolos de comunicaciones a usar
- Descripción del hardware Edge Node
- Instalación y configuración de Node-RED
- Estudio y desarrollo de una base de datos temporal en InfluxDB
- Configuración y creación de dashboards con el software Grafana
- Documentación de todos los pasos requeridos
1.4. Justificación
Actualmente es una realidad converger los procesos de IoT relacionados con la
información con los procesos OT que son las tecnologías usadas en los procesos
industriales. Interconectar todos los procesos de fabricación (sensores, motores, PLC’s,
etc…) de un producto o varios para crear redes inteligentes capaces de mejorar la
eficiencia de fabricación es a lo que llamamos industria 4.0.
Gracias a Schneider Electric se puede desarrollar una infraestructura de Internet of
things (IoT) para ser capaces de procesar los datos de una celda de trabajo y
posteriormente tratar dichos datos para poder tomar decisiones correctas o incluso
predecir mantenimientos o tiempos de manufacturación de productos. El reto que se
pretende afrontar es unir los procesos de OT con la tecnología de la industria 4.0 a través
del IT.
Con el Edge box de Schneider como Gateway de la línea somos capaces de pedirle a los
PLC’s de una planta industrial que nos extraiga los datos que son de nuestro interés,
para después con Node-RED generar un flujo de información entre los diferentes
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
3
elementos de la planta, los PLC’s y nuestra base de datos con un tag temporal creada a
través de InfluxDB.
Con toda esta infraestructura ya somos capaces de desarrollar una base de datos en la
nube que con la ayuda de Matlab se reorganizara y se crearan programas para tratar
dichos datos a la vez que a través de Grafana se puedes crear tableros (dashboards) para
visualizar la información de una forma sencilla y fácil para tomar las decisiones
adecuadas y no tener que procesar manualmente miles de datos ya que esto puede
llevar a errores humanos como un augmento en el tiempo de procesado exponencial.
2. Estado del arte: Contexto de Industria 4.0
La industria 4.0 es la nueva manera de organizar los medios de producción mediante la continua automatización de les procesos industriales a través de tecnologías modernas. También conocida como la cuarta revolución industrial, su objetivo es mejorar las comunicaciones, el autocontrol y la producción de máquinas inteligentes para que estas puedan analizar y diagnosticar problemas sin la necesidad de la intervención de personas en el proceso. Con la industria 4.0 también aparecen conceptos como Internet of Things, machine learning, Big data, inteligencia artificial, sistemas ciberfísicos, etc.
Figura 1: diagrama de las revoluciones industriales
Se puede decir que la cuarta revolución se basa en la digitalización de la industria que
se empezó a llevar a cabo a principios del siglo XXI. Como principales características de
esta revolución tenemos:
• Interconexión: capacidad de los dispositivos físicos a niveles de procesos,
maquinas que ejecutan dichos procesos, sensores y personas para conectarse
entre ellos e intercambiar información el uno con el otro. El gran termino que
está apareciendo cada vez con más fuerza que hace posible esto es el Internet of
Things.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
4
• Transparencia de la información: Cada vez el volumen de información que se
genera y que se desea analizar es mayor. La interconectividad ayuda a los
operarios a recopilar inmensas cantidades de datos de todos los puntos de los
procesos. Esta información debe ser transparente para poder acceder a ella y
gestionarla de manera precisa.
• Instantaneidad: Los volúmenes de datos que se generan en tiempo real crece y
por ello para una toma de decisiones efectiva y correcta se debe disponer de
dicha información de forma instantánea.
• Descentralización: Se debe descentralizar la toma de decisiones para poder
mejorar la producción de la industria y no disponer de sistemas centralizados y
cerrados en la propia empresa.
• Modularización: Este término hace referencia a dividir en módulos o diferentes
partes los sistemas de producción para una mejor gestión de los procesos y del
análisis.
• Virtualización: Monitorizar los datos constantemente y los modelos de
producción industrial permite al usuario optimizar dichos procesos y evitar
posibles erratas en ellos. Incluso si se aplica el machine learning en dichos datos,
se puede llegar a conseguir modelos de predicción de fabricación o predicción
de mantenimientos.
2.1. Internet of Things
EL termino de Internet of Things (IoT) hace referencia, en términos informáticos, a una
red de objetos físico de la vida cuotidiana interconectado mediante sensores, software
y otras tecnologías para poder intercambiar datos con otros dispositivos y sistemas a
través de internet.
Se pretende unificar los procesos de OT ubicado a nivel de planta con los sistemas IT a
nivel de usuario sin el requerimiento de la interacción humano a humano, o humano a
ordenador.
Una arquitectura de IoT consiste en dispositivos inteligentes con conexión a internet que
comparten los datos recopilados en el nivel de OT, a través de una puerta de enlace (en
inglés, Gateway), son enviados a la nube para ser analizados o para analizarse
localmente. Con sistemas más inteligentes, los dispositivos se comunican con otros
dispositivos a nivel de planta para actuar sobre la base de la información que obtienen
unos de otros. Todo este trabajo se hace de forma remota sin la necesidad de que una
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
5
persona intervenga, aunque pueden intervenir para configurarlos, darles instrucciones
de forma remota o acceder a los datos.[8]
Figura 2: modelo de IoT
Los protocolos de conectividad, redes y comunicación que se utilizan con estos
dispositivos dependen, en gran medida, de las aplicaciones de IoT implementadas.
IoT también puede hacer uso de la inteligencia artificial (IA) y el aprendizaje automático
para ayudar a que los procesos de recopilación de datos sean más fáciles y dinámicos.
2.1.1. Arquitectura IoT
Cuando hablamos de la arquitectura de un modelo informático nos referimos a la
infraestructura para la especificación de una red de componentes físicos y su
configuración y organización funcional, sus principios y procedimiento operacionales, y
los tipos de datos que se intercambian entre ellos.
Para describir la arquitectura de IoT se ha hecho a través de diferentes “capas”, cada
una de las cuales tiene su función específica y dispone de sus propios protocolos. Existen
dos modelos, uno de tres capas y el otro de cinco.
Donde las capas de nivel inferior pertenecen al nivel físico, el de los dispositivos, y a la
adquisición de datos por medio de sensores. A medida que subimos capas, estamos
acercándonos más al nivel de usuario y para él como estén construidas las capas
inferiores es transparente.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
6
Figura 3: Arquitectura IoT (A: 3 capas, B: 5 capas)
Para entender mejor la arquitectura de IoT se explicarán, a continuación, con más
detalle cada capa del modelo.
• Capa de percepción: Se encarga de obtener datos del entorno, de la persona o
del propio proceso o sistema sobre el que se actúa. Los elementos esenciales de
esta capa son los sensores, que muchas veces se integran en nodos de
procesamiento IoT capaz de subir a la nube los datos mediante servicios como
Fiware o Amazon AWS.
• Capa de red: Consta de los protocolos y tipos de comunicación y la
infraestructura de red. La funcionalidad de esta capa es la de conectar los
dispositivos del sistema a dispositivos en la red o servidores. Dispone de las
herramientas necesarias para transmitir datos entre dispositivos, y también para
realizar cierto grado de procesamiento de los mismos.
• Capa de aplicación: O también llamada servicios web. Estos servicios web se
ejecutan bajo demanda, de forma flexible y con poca latencia mediante
computación en la nube. La computación en la nube también suministra
infraestructura como servicios de almacenamiento de datos remoto o
aplicaciones. Cualquier aplicación que haga uso de dispositivos conectados se
incluye en esta capa.
Ya que el modelo de arquitectura de cinco capas consta con dos de las del modelo de
tres capas (capa de percepción y la de aplicación), solo se explicarán las nuevas:
• Capa de transporte: En esta capa se procesan todas las transmisiones de
información de la capa de percepción a la capa de procesamiento (nivel
superior). Resuelve la comunicación entre dispositivos a nivel de red.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
7
• Capa de procesamiento: Aquí se recogen todos los datos transmitidos por los
sensores y transportados por la red (3G, 4G, Wifi, Bluetooth, …) y son procesados
para almacenarlos en una base de datos, cloud computing, Big data o cualquier
otro servicio de procesamiento. Tanto la capa de transporte como la de
procesamiento se engloban en la capa de red del modelo de tres capas.
• Capa de Negocio: En esta capa se gestionan las aplicaciones IoT. Aquí se engloba
todo aquello que sea del nivel más alto de abstracción como modelos de negocio,
privacidad de datos de usuarios, y análisis de datos de forma visual para
posteriores tomas de decisiones.[7]
2.1.2. Convergencia IT – OT
La inevitabilidad de la convergencia entre las tecnologías de la información (IT) y las
tecnologías de la operación (OT) es una realidad. Al principio estas dos tecnologías
tenían poco en común, ya que los sistemas de control industrial funcionaban sobre un
hardware especifico con sistemas operativos en tiempo real. Para entender mejor
porque esta convergencia explicaremos que es cada cosa. Aunque hace ya unos cuantos
años los sistemas IT y OT empezaron a compartir plataformas hardware y software
estándar.
Los sistemas OT se refieren al conjunto de tecnologías que se utilizan en los procesos
industriales y a la gestión de las infraestructuras y utilidades destinadas a realizar
operaciones. Estos sistemas son mayoritariamente aplicaciones SCADA Y MES basadas
en plataformas propietarias de unos pocos fabricantes. Estos sistemas tienen como
objetivo la detección en cambios de procesos físicos mediante monitorización y control
de dispositivos. La infraestructura de la información es algo secundario y mucho más
simple y estática y no existen normativas generales para la regulación de estos sistemas.
Estos sistemas se podrían englobar en capa más baja del modelo de arquitectura IoT.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
8
Figura 4: Convergencia OT y IT
En cambio, los sistemas IT son aplicaciones que funcionan sobre bases de datos
relacionales, basados en servidores de aplicaciones y entornos web. Se aplican a los
equipos de telecomunicaciones y requieren de personal de control. Por su fragilidad,
requieren de entornos controlados con pocos o nulos cambios y cuidados constantes.
Estos sistemas priorizan la confidencialidad y la seguridad de los datos. Podemos asociar
esta tecnología a las capas superiores de la arquitectura IoT, donde se envía y se recibe
grandes cantidades de información por lo que el medio de comunicación debe facilitar
estos grandes movimientos.[5]
2.1.3. Factores Clave
Para la convergencia entre estos dos grandes mundos de la industria moderna se hablará
de los factores clave que hacen que esto sea posible en la industria 4.0. Los tres factores
son IoT, Big Data y Cloud. [10]
2.1.3.1. IoT
Como ya hemos comentado antes IoT es la interconexión de dispositivos a través de
redes, dispositivos a niveles físicos como lo son las industrias y las plantas industriales y
los sistemas de información y almacenamiento de datos. Este concepto, sin duda, es de
los grandes motores del cambio. [9]
2.1.3.2. Big data
Otro concepto clave de la convergencia de IT con OT es el de Big Data. Este concepto
hace referencia al conjunto de datos cuyo tamaño, complejidad y velocidad de
crecimiento dificultan su captura, gestión y procesamiento mediante tecnologías y
herramientas convencionales tales como bases de datos. El volumen de datos que se
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
9
generan ha crecido exponencialmente durante las últimas décadas. La complejidad del
Big data de sebe principalmente a la no estructuración de los datos generados por los
dispositivos de las plantas industriales modernas.[12]
Figura 5: Volumen de datos vs año
La importancia del Big data reside en que, gracias al análisis de los datos, proporcionan
muchas respuestas empresariales que ni siquiera se sabían de su existencia. También se
puede utilizar para detectar anomalías en las respuestas del sistema y conseguir
encontrar la causa de dichas anomalías. Con la visualización de la información de forma
más comprensible se pueden detectar tendencias que llevara a una mayor agilidad a la
hora de tomar decisiones. Otro ejemplo de la utilidad del Big Data es la identificación y
aprovechamiento de oportunidades empresariales para dar una mayor salida a sus
productos. Las características que más se valoran en las empresas de Big data son:
• Reducción de costes: Las grandes tecnologías de datos basados en la nube
aportan importantes ventajas en términos económicos cuando se trata de
almacenar grandes volúmenes de datos. En el mundo laborar siempre se busca
la reducción de costes para obtener el mayor beneficio posible.
• Rapidez de procesamiento: Con el incremento de la velocidad de gestión y
procesamiento en la analítica de los datos, se consigue reducir el tiempo en la
toma de decisiones siendo este un factor muy importante para no perder
oportunidades en el mercado.
• Nuevos servicios: Gracias al análisis que nos aportan los datos podemos
detectar nuevos productos y servicios para abastecer las necesidades de los
clientes y así poder satisfacerlos para generar una relación de confianza con
ellos.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
10
La volatilidad de los datos, el volumen a procesar y la capacidad de desechar información
irrelevante, junto con las diferentes fuentes de información de la que adquirimos los
datos hace que sea un gran reto competir en el sector.
2.1.3.3. Cloud computing
El Cloud computing o la computación en la nube cosiste en la posibilidad de ofrecer
servicios a través de internet. En la actualidad surgen nuevas posibilidades de negocio
ofreciendo servicios a través de internet por su rapidez y comodidad. Estos nuevos tipos
de negocio se les conoce como e-business. En el modelo de nube, no hay necesidad de
instalar aplicaciones localmente en computadoras.
La computación en la nube ofrece a los individuos y a las empresas la capacidad de
solicitar recursos de computación con buen mantenimiento, seguro, de fácil acceso y
bajo demanda.[11]
Figura 6: Cloud computing
También se puede describir como una red mundial de servidores, cada uno con una
función n única. LA nube no es una entidad física, sino una red enrome de servidores
remotos de todo el mundo que están conectados para funcionar como un único
ecosistema. Estos servidores están diseñados para almacenar y administrar datos,
ejecutar aplicaciones o entregar contenido o servicios, como streaming de vídeos,
correo web, software de ofimática o medios sociales. En lugar de acceder a archivos y
datos desde un equipo personal o local, accede a ellos en línea desde cualquier
dispositivo conectado a Internet. Existen diferentes tipos de servicios:
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
11
• SaaS: Son las aplicaciones basadas en la nube, o software como servicio
(Software as a Service). Estas aplicaciones se ejecutan en sistemas distantes en
la nube y pertenecen y son administrados por otros. Están conectados a los
sistemas de usuario a través de internet.
Entre sus ventajas encontramos la disponibilidad y accesibilidad desde
cualquier parte del mundo. No se pierden datos si un sistema falla, es servicio
escala dinámicamente en función de las necesidades del uso y se puede empezar
a trabajar rápidamente solo iniciando sesión en el sitio web.
• PaaS: Son las siglas de Platform as a Service. Este servicio proporciona un
entorno en la nube con todos los requisitos para dar soporte al ciclo de vida de
creación y puesta en marcha de aplicaciones basadas en web, sin el coste la
complejidad de comprar y gestionar el hardware, software, aprovisionamiento
y alojamiento necesario.
Sus principales ventajas con la velocidad de desarrollo y comercialización de
aplicaciones, la capacidad de desplegar en cuestión de minutos nuevas
aplicaciones web y reduce la complejidad con middleware como servicio.
• IaaS: Infraestructure as a Service. Proporciona a las empresas recursos
informáticos, incluyendo servidores, redes, almacenamiento y espacio en centro
de datos con pago en función del uso.
Se puede destacar como ventaja que no es necesario invertir en hardware para
servidores, se ofrece las capacidades de procesamiento y espacio bajo demanda
según las cargas de trabajo y la contratación de servicios flexibles disponibles
bajo demanda.[13]
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
12
Figura 7: modelo de servicios de la nube.
2.2. Protocolos de comunicación
Los protocolos de comunicaciones son sistemas de reglas que permiten que dos o más
entidades de sistemas de telecomunicaciones, tales como ordenadores y teléfonos
móviles, puedan establecer un flujo de intercambio de información entre ellos.
Dentro de estos protocolos está establecido la sintaxis, semántica y sincronización de
las comunicaciones o incluso los posibles métodos de recuperación de errores que
deben seguir ambos sistemas.
Dentro de los protocolos de comunicación existen de varios tipos, como las
comunicaciones industriales o las de red.
En 1980, se presentó un modelo de referencia para la creación de los protocolos de
comunicación llamado “modelo OSI” (en inglés, Open System Interconnection). Este
estándar tiene como objetivo la interconexión de sistemas de procedencia distinta para
que puedan intercambiar información. Este modelo está basado en una arquitectura por
capas, de las cuales no entraremos en detalle.[15]
Capa Unidad de datos de protocolo (PDU)
Función
Host layers
7 Aplicación
APIs de alto nivel, como compartir recursos y acceso remoto a archivos
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
13
Tabla 1: Modelo OSI [16]
Más adelante se explicará los protocolos de comunicación que usan los PLC’s de la celda
de producción y algunas de sus variantes más utilizadas en la industria.
2.2.1. Bus CAN
El protocolo de Bus CAN (Controller Area Network) es un protocolo de comunicaciones
basado en una topología bus para la transmisión de mensajes en entornos distribuidos.
Además, ofrece una solución a la gestión de la comunicación entre múltiples CPU’s.
Permite que los microcontroladores y dispositivos se comuniquen entre sí dentro de un
vehículo sin una computadora host. El bus CAN es un protocolo basado en mensajes,
6 Presentación Datos
Traducción de datos entre un servicio de red y una aplicación, que incluye la codificación de caracteres, la compresión de datos y el cifrado y descifrado de datos
5 Sesión Manejo de sesiones de comunicación, por ejemplo, el continuo intercambio de información en forma de múltiples transmisiones hacia ambos lados entre dos nodos
4 Transporte Segmento, Datagrama Transmisión de segmentos de datos confiable entre puntos de red, incluyendo la segmentación, el acknowledgement y la multiplexación
Media layers
3 Red Paquete Estructura y manejo de una red multinodo. Incluye el direccionamiento, el ruteo y el control de tráfico traffic control
2 Enlace de datos Trama Transmisión de datos confiable entre dos nodos conectados mediante una capa física
1 Física Bit, Baudios Transmisión y recepción de flujos de bits sin procesar por un medio físico
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
14
diseñado específicamente para aplicaciones automotrices, pero ahora también se usa
en otras áreas como aeroespacial, automatización industrial y equipos médicos.
Figura 8: Protocolo Bus CAN
El bus CAN utiliza dos cables dedicados para la comunicación. Los cables se llaman CAN
alto y CAN bajo. El controlador CAN está conectado a todos los componentes de la red
a través de estos dos cables. Cada nodo de red tiene un identificador único. Todas las
ECU en el bus están efectivamente en paralelo y es por eso que todos los nodos ven
todos los datos, todo el tiempo. Un nodo solo responde cuando detecta su propio
identificador. Los nodos individuales se pueden eliminar de la red sin afectar a los otros
nodos.[19]
Figura 9: Señal del protocolo Bus CAN
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
15
Las principales ventajas que ofrece el Protocolo CAN son:
• Alta inmunidad a posibles interferencias de la planta, autodiagnóstico y
reparación de errores de datos.
• Protocolo normalizado. Esto simplifica y abarata los costes de intercomunicar
subsistemas de diferentes fabricantes sobre una red común.
• El host encarga el volumen de comunicaciones a un periférico inteligente, por lo
que este dispone de mayor tiempo para ejecutar sus tareas.
• Reducción considerable del cableado por ser una red multiplexada1
Figura 10: Estructura trama Bus CAN
2.2.2. Profibus
Profibus son las siglas de “Process Field Bus” que es un estándar de red digital de campo
abierto que se encarga de la comunicación entre los sensores de campo y el sistema de
control.
Figura 11: Trama de Profibus
Todas las variantes de PROFIBUS se basan en el modelo de comunicación de red OSI
(Open System Interconnection), de acuerdo con la norma internacional ISO 7498.
1 Forma de enviar múltiples señales o flujos de información a través de un enlace de comunicaciones al mismo tiempo en forma
de una única y compleja señal
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
16
Figura 12: Estructura Profibus DP/PA
Existen tres tipos de protocolos Profibus, pero en este apartado solo explicaremos dos
ya que el protocolo Profibus FMS (Fieldbus Message Specification) era complejo y no se
utiliza en la actualidad.[18]
2.2.2.1. Profibus DP
Este tipo de Profibus se utiliza para Periféricos Descentralizados tal como indica sus
siglas (DP). Fue desarrollado únicamente para las comunicaciones entre los sistemas de
automatización ya que su principal ventaja es la alta velocidad de intercambio de
información.
Es aplicable en sistemas de control donde se enfatiza el acceso a dispositivos distribuidos
de E/S y sustituye a los sistemas convencionales de 4 a 20 mA, HART o en transmisiones
de 24 voltios. Utiliza la interfaz estándar de la capa física de comunicación RS-485 o fibra
óptica y requiere menos de dos minutos para transmitir 1 Kbyte de E/S.
2.2.2.2. Profibus PA
PROFIBUS PA permite la medición y el control a través de una línea y dos cables
individuales. También alimenta los equipos de campo en zonas intrínsecamente seguras.
Permite el mantenimiento y la conexión/desconexión de los equipos incluso durante el
funcionamiento sin interferir en otras estaciones en zonas.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
17
Existen ventajas potenciales para el uso de esta tecnología, que conlleva ventajas
funcionales como la transmisión de información confiable, manejo de estados variables,
sistemas de seguridad de fallas, y la característica de equipo de autodiagnóstico,
medición con alta resolución, integración con control de alta velocidad, etc.
La conexión de los transmisores, convertidores y posicionadores en una red PROFIBUS
DP se realiza mediante un acoplador DP/PA. El cable de par trenzado se utiliza como
fuente de alimentación y comunicación de datos para cada equipo, lo que facilita la
instalación y reduce el coste del hardware, lo que se traduce en un menor tiempo de
puesta en marcha, un mantenimiento sin problemas, un bajo coste de software de
ingeniería y un funcionamiento altamente fiable.
Tabla 2. Perfiles, características y aplicaciones de Profibus.
2.2.3. Modbus
Modbus es un protocolo de comunicaciones situado en los niveles 1, 2 y 7 del Modelo
OSI, basado en la arquitectura maestro/esclavo (RTU) o cliente/servidor (TCP/IP).
Modbus permite el control de una red de dispositivos, por ejemplo, un sistema de
medida de temperatura y humedad, y comunicar los resultados a un ordenador. Modbus
también se usa para la conexión de un ordenador de supervisión con una unidad remota
(RTU) en sistemas de supervisión adquisición de datos (SCADA). Existen versiones del
protocolo Modbus para puerto serie y Ethernet (Modbus/TCP).
Cada comando Modbus contiene la dirección del dispositivo destinatario de la orden.
Todos los dispositivos reciben la trama, pero solo el destinatario la ejecuta (salvo un
modo especial denominado "Broadcast"). Cada uno de los mensajes incluye información
redundante que asegura su integridad en la recepción.
Las principales razones por las cuales el uso de Modbus en el entorno industrial se ha
impuesto por encima de otros protocolos de comunicaciones son:
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
18
• Se diseñó teniendo en cuenta su uso para aplicaciones industriales
• Es público y gratuito
• Es fácil de implementar y requiere poco desarrollo
• Maneja bloques de datos sin suponer restricciones
2.2.3.1. Modbus TCP/IP
También denominado Modbus TCP, Es una variante de Modbus usada para
comunicaciones a través de redes TCP/IP para establecer comunicaciones tipo Maestro-
Esclavo / Cliente-Servidor. Esta variante de Modbus fue desarrollada en 1999 y une la
variante RTU con una interfaz TCP que se ejecuta en Ethernet. Con Ethernet, está
combinando una red física (Ethernet) versátil, escalable y mundial con un estándar de
red universal (TCP / IP) y una representación de datos independiente del proveedor,
Modbus.
Este protocolo proporciona una red verdaderamente abierta y accesible, que permite
intercambiar bloques de datos binarios entre dispositivos. Es fácil de implementar para
cualquier dispositivo que admita puertos TCP / IP, con un interruptor y un cable
disponibles para cada dispositivo. Sigue siendo totalmente compatible con la
infraestructura Ethernet ya instalada que pueda tener cualquier cliente.
La estructura de mensajería Modbus es el protocolo de aplicación que define las normas
para la organización y la interpretación de los datos independiente del medio de
transmisión de datos.[2]
Figura 13: Protocolo Modbus RTU y TCP/IP
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
19
2.2.4. Ethernet
El protocolo Ethernet/IP es un estándar de red de comunicación capaz de manejar
grandes cantidades de datos a velocidades de 10 Mbps o 100 Mbps y hasta 1500 bytes
por paquete. La especificación utiliza un protocolo abierto en la capa de aplicación del
modelo OSI.
En la industria es muy popular para aplicaciones de control debido a su fácil
configuración, operación, es sencillo de mantener y ampliar y es compatible con la
mayoría de los conmutadores Ethernet.
Recientemente este protocolo se ha convertido en el más utilizado en el movimiento de
datos de aplicaciones industriales en plantas de producción y sus especificaciones están
respaldadas por la industrial Ethernet Association (IEA), ControlNet International (CI) y
la Open DeviceNet vendor Association (ODVA).
ODVA es una organización de desarrollo de estándares y una asociación de los miembros
de las principales empresas de automatización industrial del mundo. ODVA trabaja para
promover las tecnologías de la información y la comunicación abiertas e interoperables
en la automatización industrial.
Ethernet/IP es el único protocolo Ethernet industrial que se basa completamente en los
estándares Ethernet y utiliza capas físicas, de enlace de datos, de red y de transporte
estándar de Ethernet. Dado que utiliza conmutación Ethernet estándar, puede soportar
un número ilimitado de nodos. Sin embargo, requiere un alcance limitado para evitar la
latencia y permitir la comunicación en tiempo real.
Figura 14: Protocolo Ethernet industrial
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
20
2.2.5. HTTP
El protocolo HTTP, de sus siglas en inglés “HyperText Transfer Protocol”, es un protocolo
que nos permite realizar peticiones de datos y recursos, como pueden ser documentos
HTML, XHML, etc… en la world wide web. Este protocolo de estructura Cliente-Servidor,
es la base de cualquier intercambio de datos en la web, normalmente un navegador
web.
Una página web completa es el resultado de la unión de distintos subdocumentos
recibidos, como pueden ser un documento que especifique el estilo de maquetación de
la página web (CSS), el texto, las imágenes, vídeos, scripts, etc...
Figura 15: Protocolo HTTP
Clientes y servidores se comunican intercambiando mensajes individuales. Los mensajes
que envía el cliente (navegador) se llaman peticiones, y los mensajes enviados por el
servidor se llaman respuestas.[20]
HTTP define la sintaxis y la semántica que utilizan los elementos de software de la
arquitectura web (clientes, servidores, proxis) para comunicarse. HTTP es un protocolo
sin estado, es decir, no guarda ninguna información sobre conexiones anteriores. El
desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se
usan las cookies, que es información que un servidor puede almacenar en el sistema
cliente. Un ejemplo de dialogo HTTP es el siguiente:
GET /index.html HTTP/1.1
Host: www.example.com
Referer: www.google.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Firefox/45.0
Connection: keep-alive
[Línea en blanco]
Respuesta del servidor
HTTP/1.1 200 OK
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
21
Date: Fri, 31 Dec 2003 23:59:59 GMT
Content-Type: text/html
Content-Length: 1221
<html lang="eo">
<head>
<meta charset="utf-8">
<title>Título del sitio</title>
</head>
<body>
<h1>Página principal de tuHost</h1>
(Contenido)
.
.
.
</body>
</html>
Tabla3: Ejemplo de dialogo HTTP
3. Caso de estudio: Planta de producción
Para entender mejor la finalidad de este proyecto, primero se describirá la planta de
producción que se dispone en el laboratorio, ya que esta es la base de la información
que se debe tratar y el nivel más bajo en la arquitectura IoT.
La celda del laboratorio está compuesta, a primera vista, por dos partes: la célula flexible
y el pulmón. También podemos diferenciar la planta por los tipos de comunicaciones
que usan sus diferentes PLC’s. En la siguiente imagen podemos ver celda que
disponemos en el laboratorio de automatización.
Figura 16: Laboratorio de automatización
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
22
La celda del laboratorio de automatización puede fabricar 3 tipos de productos según
las materias primas que se suministren a las bandejas i el flujo de trabajo que sigue cada
bandeja depende del objeto que se desee fabricar.
3.1. Célula flexible
La célula flexible está formada por diferentes PLC’s con sus diferentes protocolos de
comunicación, cintas transportadoras que se encargan de mover las bandejas de
plataforma a plataformas, motores trifásicos necesarios para mover las cintas o las
cadenas del pulmón, sensores con diferentes tecnologías para detectar materiales,
plataformas que actúan como un retenedor, retenedores para bloquear bandejas entre
plataforma y plataforma, electroválvulas ara accionar los diferentes elementos de
retención, pulsadores para controlar los diferentes ciclos de trabajo de la celda y la seta
de emergencia para parar la celda en caso de que haya un incidente.
3.2. Sensores
Un sensor es todo aquello que tiene una propiedad sensible a una magnitud del medio,
y al variar esa magnitud también varia con cierta intensidad la propiedad. En la industria
hay sensores capaces de variar su propiedad ante magnitudes físicas o químicas, a estas
propiedades se les conoce como variables de instrumentación. El sensor es capaz de
transformar dichas variables de instrumentación en variables eléctricas, tal como voltaje
o intensidad. Existen muchos tipos de sensores que son capaces de detectar variables
de instrumentación tales como: intensidad lumínica, temperatura, distancia,
aceleración, inclinación, presión, desplazamiento, movimiento, etc. Los sensores
también tienen diversas características técnicas como la precisión, la sensibilidad,
resolución, rapidez, etc. Estos pueden ser analógicos o digitales.
Se disponen de varios tipos de sensores en la celda. Cada uno de ellos tiene una función
específica según su tecnología para detectar objetos.
3.2.1. Sensores Fotoeléctricos
Un sensor fotoeléctrico o fotocélula es un dispositivo electrónico que responde al
cambio de intensidad de la luz. Estos sensores requieren de un emisor que es el
encargado de generar el haz de luz, y un componente receptor que recibe y detecta la
luz generada por el emisor. A este tipo de sensores se les conoce como Barrer Emisor-
Receptor.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
23
Figura 17: Funcionamiento Sensor Fotoeléctrico de barrera Emisor-Receptor
Existen otro tipo de sensores llamados de Barrera Reflectiva que unen el receptor y el
emisor en el mismo dispositivo haciendo falta la colocación de un elemento reflector.
Mientras no haya ningún objecto entre el sensor y el reflector este recibirá la luz
reflejada y no detectará. Cuando un objecto se encuentra entre el sensor y el reflector
entonces el receptor dejara de recibir el haz de luz del emisor y entregara la señal
correspondiente.[30]
Figura 18: Funcionamiento sensor Barrera Reflectiva
Los sensores de luz se usan para detectar el nivel de luz (en nuestro caso para detectar
si hay objectos entre el emisor y el receptor) y producir una señal de salida
representativa respecto a la cantidad de luz detectada. Estos tipos de sensores incluyen
un transductor fotoeléctrico para convertir la luz en una señal eléctrica. El sensor de luz
más común es el LDR (Light Dependant Resistor) que cambia su resistencia cuando
cambia la intensidad de la luz.
3.2.2. Sensores Inductivos
Este tipo de sensores son idóneos para detectar objetos metálicos. Estos sensores de
proximidad inductivos tienen un devanado interno que cuando una corriente circula por
el mismo, este genera un campo magnético. Las bobinas del sensor inducen corrientes
de Foucault en el material a detectar debido a la inducción electromagnética. Conforme
el objeto se acerca al sensor, aumenta el flujo de corriente de inducción y esto provoca
un campo magnético que se opone al generado por el sensor. Este campo magnético en
sentido contrario causa una reducción de la inductancia y el sensor emite la señal.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
24
Figura 19: Funcionamiento sensor inductivo
Existen diferentes tipos de sensor de inducción como los blindados y no blindados. Los
blindados tienen un agregado al núcleo que limita el campo magnético al frente del
sensor, mientras que los no blindados no tienen esta capa extra por lo que el área del
campo magnético es mayor.[31]
3.3. Actuadores
Estos elementos son la base del flujo de bandejas en la celda del laboratorio. Sin ellos
las bandejas chocarían o la celda no sería tan eficiente debido a que se debería introducir
bandejas vacías con más retardo. Existen diferentes tipos de actuadores dependiendo
de sus características o de su forma.
3.3.1. Electroválvulas
También llamadas solenoides, este tipo de válvulas de activa mediante una señal
eléctrica. Estas válvulas constan de un cuerpo, un grupo operador con un núcleo móvil
y una bobina. Su funcionamiento se basa en el principio del capo magnético y son
capaces de bloquear líquidos o gases.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
25
Figura 20: Funcionamiento Electroválvula
3.3.2. Retenedores
Estos elementos son cilindros neumáticos de simple efecto con retorno por muelle. Son
capaces de retener una bandeja para impedirle el paso y evitar colisiones con otras
bandejas.
Figura 21: Retenedor con sensor inductivo
Tanto los retenedores como las plataformas, son la base de la celda y de este proyecto
para conseguir el seguimiento de las bandejas y poder visualizarlo en el dashboard de
Grafana. Hay un total de 36 retenedores y cada retenedor contiene tanto la información
de la bandeja que le llega como la información de la bandeja que sale y el estado del
retenedor. Para ello se necesitan un total de 10 espacios de memoria del PLC.
Los retenedores pueden tener dos salidas, una hacia delante y otra hacia el lateral. Estos
llevan asociados los datos en su respectivo espacio de memoria y cada retenedor se
comunica con el que le precede.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
26
3.3.3. Plataformas
Aunque el principio básico de este elemento también es el de retener una bandeja, su
funcionamiento es ligeramente distinto.
Existen de simple efecto, las cuales suben para bloquear una bandeja o vuelven a su
estado de reposo para dejar avanzar la bandeja y también hay de doble efecto que
cuentan con 3 posiciones: subida, reposo y bajada las cuales las dos primeras tienen el
mismo propósito que las de simple efecto. Las plataformas de doble efecto dejan
circular la bandeja bajando la plataforma.
Figura 22: Plataforma de la celda de trabajo
3.4. Pulmón
El pulmón es un almacenador de bandejas que consta de 4 cadenas para retener las
bandejas que llegan. Según el proceso de fabricación puede cargar o descargar bandejas
mediante un actuador lineal (cilindro eléctrico activado por un servomotor). El pulmón
consta de sensores para detectar las aletas de las cadenas y disminuir su velocidad según
si está cargando o descargando bandejas. Al hacer uso del variador de frecuencia el
motor es capaz de reducir su velocidad al detectar la aleta en carga o en descarga.
El variador de frecuencia utiliza 20 HZ para velocidades rápidas y 5 Hz para las
velocidades más lentas. Hay dos motores, el encargado de mover las cadenas del
pulmón y el que se encarga de mover el actuador lineal.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
27
El pulmón tiene su propio PLC con protocolo de comunicación Ethernet encargado de
gobernar las acciones de este cuando está en modo automático.
Figura 23: Pulmón
También cuenta con un cuadro de mando con diferentes pulsadores y pilotos de
señalización para poder realizar las acciones manualmente o automáticamente y
ofrecernos la información de una forma visual del estado del pulmón.
3.5. Flujo de trabajo
Cuando una bandeja vacía entra en por la estación de entrada DIR03 se le asigna un
número identificador a esta. La bandeja avanza hasta la plataforma PT05, entonces si
los retenedores DIR05, DIR06 o PT06 están en el estado de reposo, seguirá avanzando
hasta PT06 para suministrar las materias primas del producto que se vaya a fabricar. En
caso contrario la bandeja se dirigirá hacia la plataforma PT17 que al estar vacía seguirá
el camino de la zona central pasando hacia la línea Profibus y volviendo hacia la
plataforma PT04 e iniciando de nuevo el camino como si se tratara de una bandeja
nueva. Como la bandeja estará vacía no debe ser tratada en ninguna estación de trabajo
y esta seguirá el camino descrito hasta que la plataforma PT06 este libre.
Una vez se haya cargado las materias primas en PT06, la bandeja se dirigirá hacia la
estación de trabajo 1 ubicada en la plataforma PT08 y empezará el proceso de
fabricación. La plataforma PT08 retendrá la bandeja hasta que el proceso haya
finalizado. Al finalizar el proceso de la estación de trabajo 1 la bandeja avanzará hacia
PT09 (siempre y cuando no haya ninguna bandeja) y dependiendo del tipo de producto
seguirá un camino u otro.
Si se trata del producto tipo 1, la bandeja ira hacia el retenedor DIR14 dirección estación
de trabajo 2. Aquí la bandeja será retenida de nuevo para que el producto sea procesado
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
28
por dicha estación. Si el tipo de producto es diferente a 1, la bandeja seguirá recto de
PT09 a PT10. Una vez en PT10, si el producto es tipo 3, la bandeja se desviará hacia la
plataforma PT12 dirección estación de trabajo 3 reteniendo allí la bandeja mediante el
retenedor DIR18. Una vez el temporizador de la estación haya llegado a 0, la bandeja
continuará por PT014 hacia PT16 y PT04 para extraer el producto en DIR04. En PT10, si
el tipo de producto es 2, la bandeja se dirigirá hacia la plataforma PT14 para entran en
la línea CAN de nuevo y proceder a DIR04 para la extracción del producto finalizado.
Figura 24: Diagrama flujo de trabajo
3.6. Datos obtenidos de la planta
Cada retenedor ocupa 10 espacios de memoria en el PLC. Ya que contamos con 36 retenedores
ubicados en diferentes espacios de memoria debemos saber en qué orden nos llega para
asociarlos con el tag correspondiente en InfluxDB.
Cada retenedor tiene el siguiente formato:
Espacio en la memoria Campo Valor
0 ID de bandeja de entrada
-1 →65536
1 Número de serie de la bandeja de
entrada
-1 →65536
2 Estado de la bandeja de entrada
-1 →65536
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
29
3 ID de la bandeja de salida1
-1 →65536
4 ID de la bandeja de salida1
-1 →65536
5 Estado de la bandeja de salida1
-1 →65536
6 ID de la bandeja de salida2
-1 →65536
7 Número de serie de la bandeja de
salida2
-1 →65536
8 Estado de la bandeja de salida2
-1 →65536
9 Estado del retenedor
1→9
Tabla 4: Datos de cada retenedor
Los datos de la memoria del 0 al 8 nos puede llegar cualquier número del -1 que es su estado de
reposo al 65536 que es el número máximo que podemos lograr con 16 bits.
El estado del retenedor puede estar en 9 estados posibles:
• Reposo (1): Indica que el retenedor está en su estado de reposo y puede recibir
una bandeja.
• Petición (2): En este estado, el retenedor indica que está bloqueando una
bandeja.
• Avance (5): Indica que el retenedor ha dejado avanzar una bandeja.
• Avance2 (9): Lo mismo que el estado 5 pero hacia la segunda salida si existe.
Los estados 3,4,6,7 y 8 significan que el retenedor se ha activado para dejar pasar la bandeja y está por delante del retenedor dependiendo de la dirección que tome la bandeja se corresponderá con la salida 1 o 2. Estos son estados que duran alrededor de 300ms y si inyectamos datos a nuestra base cada segundo significa que hay pocas probabilidades de tener este estado almacenado. Cuando un retenedor le envía una bandeja al siguiente retenedor los datos de los espacios 0, 1 y 2 se pasan a los espacios 3, 4 y 5 o 6, 7 y 8 dependiendo si se mueve hacia delante o hacia el lateral. Hay retenedores que solo pueden avanzar hacia delante por lo que la salida 2 siempre será -1. Cuando estos datos pasan a su respectiva salida el retenedor de destino también recibe estos en sus espacios asignados para las entradas. De este modo siempre podemos llevar la trazabilidad de las bandejas y sus datos asociados.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
30
4. Diseño e implementación de la arquitectura IoT
Debemos pensar que el laboratorio es la capa de percepción y la de transporte del
modelo de capas de la arquitectura IoT donde se encuentran todos los elementos
relacionados con la adquisición de datos y el envío a la red a través del hardware
destinado a ello.
Los datos son recopilados y gestionados por las diferentes islas advantys del laboratorio
que a su vez las envían a los PLC’s para la toma de decisiones del software que están
ejecutando. Todo ello se interconecta con diferentes tipos de protocolos para
finalmente recibir la información a través del Edge Box de Schneider por protocolos de
comunicación Ethernet y Modbus TCP/IP.
Figura 25: Diagrama de flujo de información
El Edge Box es el encargado de solicitar la información de las memorias de los PLC’s para
posteriormente enviarla a la nube a través de Node-RED, donde se creará un programa
para gestionar los flujos de información y almacenarlos en InfluxDB que también se
ejecuta en la nube.
Una vez los datos estén guardados y estructurados en la base de datos de InfluxDB,
desde Grafana se accederá a ella para poder consultar dichos datos de forma visual y
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
31
entendible para las personas. Con la herramienta de Grafana ya disponible seremos
capaces de visualizar el flujo de bandejas de la planta del laboratorio desde cualquier
lugar del mundo, incluso desde un dispositivo móvil.
4.1. Softwares
En el siguiente capítulo se describirá las tareas realizadas en los diferentes softwares
utilizados durante la realización del trabajo final de estudios.
Cabe destacar que los programas utilizados son de libre distribución y abiertos al público
(software libre u open source software). Estos programas pueden ser utilizados o incluso
realizar modificaciones en el código fuente2 sin ningún tipo de restricción y ser igual de
potentes que los softwares de pago.
Un software libre debe conceder las siguientes 4 libertades a los usuarios:
• La libertad de ejecutar el programa como se desee, con cualquier propósito
(libertad 0).
• La libertad de estudiar cómo funciona el programa, y cambiarlo para que haga lo
que usted quiera (libertad 1). El acceso al código fuente es una condición
necesaria para ello.
• La libertad de redistribuir copias para ayudar a otros (libertad 2).
• La libertad de distribuir copias de sus versiones modificadas a terceros (libertad
3). Esto le permite ofrecer a toda la comunidad la oportunidad de beneficiarse
de las modificaciones. El acceso al código fuente es una condición necesaria para
ello.
En este capítulo hablaremos de la instalación para ejecutarlo de forma remota, pero
cabe desatacar que también se pueden ejecutar en la nube.[22]
4.1.1. Node-RED
Node-RED es una herramienta de programación basada en flujos, desarrollada por el
equipo de Emerging Technology Services de IBM y construida en Node.js (un entorno de
ejecución para JavaScript de código abierto construido con el motor de JavaScript V8 de
Chrome). Usando la interfaz del navegador permite conectar gráficamente bloques
predefinidos, llamados nodos, para desarrollar una tarea concreta. La conexión de los
2 El código fuente de un software es un conjunto de líneas de texto con los pasos que debe seguir la computadora para ejecutar
un programa[21].
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
32
nodos, habitualmente una combinación de nodos de entrada, nodos de procesamiento
y nodos de salida, forman lo que conocemos como flow.[24]
Con Java como su lenguaje de programación, Node-RED es una herramienta muy
potente que sirve para comunicar hardware y servicios de una forma muy rápida y
sencilla. Simplifica enormemente la tarea de programar del lado del servidor gracias a la
programación visual.[23]
Figura 26: Logo de Node-RED
4.1.1.1. Instalación de Node-RED
Node-RED necesita de la instalación de Node.js y para ello primero debemos consultar
cual es la versión recomendada en la siguiente tabla:
Figura 27: Versiones soportadas por Node-RED
Una vez instalada la versión necesaria de Node.js de 64 bits que la podremos descargar
de la siguiente dirección https://nodejs.org/en/download/, debemos ir al símbolo del
sistema y ejecutarlo como administrador ya que se necesitan hacer cambios en el
sistema que requieren tales permisos. Dentro del símbolo del sistema ejecutaremos el
siguiente comando:
npm install -g --unsafe-perm node-red
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
33
Cuando la instalación haya terminado deberemos acceder al símbolo del sistema e
iniciar Node-RED de la siguiente forma:
Figura 28: Ejecución de Node-RED
Cuando se inicialice Node-RED deberemos ir al navegador e introducir la ruta
http://127.0.0.1:1880/ o lo que es lo mismo http://localhost:1880/ y se nos abrirá el
editor de Node-RED.
Figura 29: pantalla principal Node-RED
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
34
Para empezar a trabajar y poder conectar Node-RED a los PLC’s del laboratorio
deberemos instalar la libraría de modbus/TCP para poder trabajar con los nodos de
conexiones a servidores modbus y poder leer información de él.
Esto se deberá hacer desde el menú, en la pestaña de ajustes marcada en la siguiente
imagen
Figura 30: Menú de Node-RED
Una vez dentro de ajustes, deberemos ir al apartado de “Palette” de la parte izquierda
de la ventana y desde aquí deberemos ir a la pestaña de instalación de las librerías. Una
vez hayamos encontrado la librería que se desea instalar le daremos clic izquierdo en la
parte derecha de la librería donde pone “install”.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
35
Figura 31: Librerías de Node-RED
A continuación, se desplegará una pestaña que nos advierte que algunas librerías tienen
dependencias que no se pueden instalar automáticamente y que revisemos la
documentación del nodo.
Figura 32: Mensaje de advertencia de instalación
En el caso del ejemplo anterior, la documentación nos informa de que esta librería usa
el bloque “Request” para peticiones HTTP y la librería “Async” para poder manejar
secuencias y ejecuciones en paralelo. También nos informa de una forma alternativa de
instalar la librería y de las características de esta.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
36
Figura 33: Documentación librería
Una vez hayamos instalado las librerías que nos indican en los pre-requisitos ya
podremos instalar la librería que deseábamos.
Cuando la instalación de la librería haya finalizado ya seremos capaces de desarrollar
nuestro flujo de información y desarrollar nuestra aplicación IoT.
En el caso de este proyecto se ha escogido la librería de modbus para poder tener los
bloques que conectan a un PLC y así poder realizar peticiones de lectura de espacios de
memoria del PLC.
4.1.1.2. Bloques de Node-RED
Los bloques, como se ha mencionado antes, son el pilar básico de funcionamiento del
software Node-RED. Aunque hay muchos tipos de bloques, se explicará el
funcionamiento de los bloques utilizados en este proyecto:
• Function: Este bloque se utiliza para escribir una función en JavaScript para
ejecutarse una vez el mensaje sea recibido por el bloque. El mensaje se transmite
como un objeto de JavaScript llamado msg. Se espera que la función devuelva
un mensaje, pero se puede escoger no devolver nada para detener el mensaje.
Figura 34: Bloque de función
Dentro del bloque hay una pestaña llamada “Setup” que contienen código que
se ejecutara cuando sea que se ejecute el nodo. La pestaña “Close” contiene
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
37
código que se ejecutara cuando se para de ejecutar la función. Estas dos
pestañas son opcionales y no hace falta añadir código.
• Inject: Este nodo sirve para inyectar un mensaje en el flujo. Puede ser
manualmente o regularmente en intervalos de tiempo. El mensaje que se inyecta
puede ser de diferentes tipos.
Figura 35: Bloque Inject
Puede elegirse diferentes tipos de objetos que se transmitirán como
“msg.payload” por defecto, aunque esto se puede cambiar y añadirle el nombre
que se desee en formato “msg.________”.
Figura 36: Editor del bloque inject
Entre los diferentes objetos que podemos transmitir como mensaje podemos
encontrar una cadena, números, un booleano, un objeto JSON, un buffer, etc.
• Modbus Flex Getter: Este bloque es el utilizado para pedir información a una
dirección de un PLC. Este nodo se configura con los parámetros de entrada de la
conexión tales como el “Host” y el puerto entre otras.
Figura 37: Bloque Modbus Flex Getter
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
38
Este bloque se conecta a un Modbus TCP para leer bucles, entradas, registros a
la velocidad del mensaje entrante. A este bloque tiene que precederle un bloque
de función indicando los parámetros de lectura.
msg.payload = { value: msg.payload, 'fc': 3, 'unitid': 1, 'address': 0 , 'quantity': 10 } return msg
Tabla 5: Parámetros para la petición de datos a Modbus
Donde FC es el código de función que se desea leer:
▪ FC 1: Leer el estado del bucle.
▪ FC 2: Leer estado de entrada. ▪ FC 3: Leer registros de retención. ▪ FC 4: Leer registros de entrada.
• Influx batch: De la librería node-red-contrib-influxdb. Es un bloque de salida que conecta a una base de datos de InfluxDB para escribir registros (campos y etiquetas) en una medida de Influx.
Figura 38: Bloque InfluxDB batch
Como InfluxDB se ejecuta solo en el ordenador de forma local este se deberá especificar el puerto en el que InfluxDB está escuchando que por defecto es el 8086. El ser nosotros el Host que está ejecutando InfluxDB se podrá escribir localhost en vez de la dirección IP.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
39
Figura 39: Editor bloque InfluxDB batch
• Debug: este nodo muestra las propiedades del mensaje seleccionado en la
pestaña de depuración de la barra lateral y opcionalmente el tiempo de
ejecución del mensaje.
Figura 40: Bloque debug
Por defecto mostrara el msg.payload, pero se puede configurar para que la salida
nos muestre las propiedades del mensaje que hayamos definido con
anterioridad. También podemos configurar el bloque para que el mensaje nos
aparezca en la consola de símbolo del sistema.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
40
Figura 41: Editor bloque debug
• Link in/ Link out: Estos bloques solo tienen la funcionalidad de crear cables
virtuales entre flujos de bloques para así no tener cables por todo el diagrama,
que pueden llegar a molestar si hay demasiados.
Figura 42: Bloque Link in/ Link out
Se han usado otros bloques como el de catch error, pero es irrelevante para el
funcionamiento del flujo de información que se ha tratado en el proyecto. Para las
pruebas se ha hecho uso de otro bloque que lee un archivo CSV.
4.1.1.3. Diseño del flujo de información
En el proyecto se ha propuesto gestionar el flujo de bandejas y los posibles estados de
los retenedores de la celda de trabajo. Para lograr este objetivo, primero de todo, se ha
hecho una petición a los PLC’s para recibir los datos.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
41
Figura 43: Diagrama petición de datos
Con un inject cada cierto tiempo, se dará la orden para la petición de datos a Modbus.
Como hay 36 retenedores y cada uno de ellos ocupa 10 memorias del PLC se ha repartido
en 10 dado que cada bloque tiene un límite para la petición de datos de 40 memorias a
la vez.
msg.topic = { value: msg.topic, 'fc': 3, 'unitid': 1, 'address': 0 , 'quantity': 40 } return msg;
Tabla 6: Función Petición datos 01
Se ha distribuido las peticiones según el PLC que gobierna el retenedor. En la zona CAN tenemos
17 retenedores por lo que se necesitan 5 peticiones, en el PLC Profibus hay 16 retenedores y se
necesitan 4 peticiones y, por último, en la línea AS-i solo tenemos 3 retenedores.
Esto nos devolverá un buffer de la cantidad de datos de la petición y en el siguiente
bloque función guardaremos la string en un flow (una variable de entorno que nos
ofrece Node-RED) y el tiempo en el que ha devuelto los datos el bloque Modbus Flex
Getter.
/* guardar los datos en una variable de entorno flow.set*/ flow.set('string1C', msg.payload) flow.set('string1msC', msg.topic) return msg;
Tabla 7: Función String1
El siguiente paso que es la concatenación de las 4 strings que nos llegaran solo si los
cuatro tiempos que hemos guardado antes son iguales. Si alguno de estos tiempos es
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
42
diferente a los demás el mensaje se descarta ya que cabe la posibilidad de que alguno
de estos datos haya cambiado.
var string1C = flow.get ('string1C'); var string2C = flow.get ('string2C'); var string3C = flow.get ('string3C'); var string4C = flow.get ('string4C'); var string5C = flow.get ('string5C'); var string1msC = flow.get ('string1msC'); var string2msC = flow.get ('string2msC'); var string3msC = flow.get ('string3msC'); var string4msC = flow.get ('string4msC'); var string5msC = flow.get ('string5msC'); var string1P = flow.get ('string1P'); var string2P = flow.get ('string2P'); var string3P = flow.get ('string3P'); var string4P = flow.get ('string4P'); var string1msC = flow.get ('string1msP'); var string2msC = flow.get ('string2msP'); var string3msC = flow.get ('string3msP'); var string4msC = flow.get ('string4msP'); var string1A = flow.get ('string1A'); var string1msA = flow.get ('string1msA'); if (string1msC== string2msC == string3msC == string4msC == string5msC == string1msP == string2msP == string3msP == string4msP== string1msA){ msg.topic = string1C + string2C + string3C + string4C + string5C + string1P + string2P + string3P + string4P + string1A; return msg;}
Tabla 8: Función concatenar
Una vez ya contemos con el buffer de todos los datos enteros (en total un buffer de 360 datos
de largo), pasaremos a tratar estos datos y acondicionarlos para insertar los registros en
InfluxDB.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
43
Figura 44: Diagrama tratamiento de datos
Dentro de la función “Datos retenedores” se especificará que field y tag debe llevar cada
posición del buffer de datos que nos llega. También se especificará en que measurement deben
ser añadidos. Con tal de no tener que escribir 360 líneas de código se ha usado la función for
para que con las diferentes iteraciones se añadan en diferentes filas con su tag correspondiente
(el tag corresponde al número de retenedor).
var dato = msg.payload; var retenedores = []; let i=0; let a=10; for (i=0; i<=10*36; i=i+1){ retenedores [i/10]= { measurement: "Retenedores", fields: { InputID: dato[i], InputNum: dato[i+1], InputStatus: dato[i+2], OutputID: dato[i+3], OutputNum: dato[i+4], OutputStatus: dato[i+5], Output2ID: dato[i+6], Output2Num: dato[i+7], Output2Status: dato[i+8], RStatus: dato[i+9] }, tags: { Retenedor: a/10 } } a = a + 1; } msg.payload = retenedores; flow.set('Estadoactual',retenedores); return msg;
Tabla 9: Función Datos retenedores
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
44
Con tal de mejorar la eficiencia de los datos un 95% y ya que la mayoría de registros que se
estarán volcando hacia la base de datos serán iguales. Se ha implementado otra función que
detecta si los registros de la nueva petición son iguales a los que ya se han cargado y descarta
los repetidos. Para ello se ha hecho uso de la función JSON.stringify para convertir un objeto de
java en una JSON string con esto podremos comparar el estado de los retenedores que ya se ha
cargado y el que llega nuevo. Si el valor que ha llegado en campo es el mismo que ya existía este
no se añadirá a la base de datos. El código implementado es el siguiente:
Setup:
// Code added here will be run once
// whenever the node is deployed.
flow.set('Estadoanterior',0)
Function:
var Estadoanterior = flow.get('Estadoanterior')
var Estadoactual = msg.payload;
flow.set('Estadoactual',JSON.parse(JSON.stringify(Estadoactual)))
if(Estadoanterior != 0){
for (let i=0; i <= 35 ; i=i+1){
if(Estadoactual[i].fields.InputID == Estadoanterior[i].fields.InputID) delete Estadoactual[i].fields.InputID;
if(Estadoactual[i].fields.InputNum == Estadoanterior[i].fields.InputNum) delete Estadoactual[i].fields.InputNum;
if(Estadoactual[i].fields.InputStatus == Estadoanterior[i].fields.InputStatus) delete Estadoactual[i].fields.InputStatus;
if(Estadoactual[i].fields.OutputID == Estadoanterior[i].fields.OutputID) delete Estadoactual[i].fields.OutputID;
if(Estadoactual[i].fields.OutputNum == Estadoanterior[i].fields.OutputNum) delete Estadoactual[i].fields.OutputNum;
if(Estadoactual[i].fields.OutputStatus == Estadoanterior[i].fields.OutputStatus) delete Estadoactual[i].fields.OutputStatus;
if(Estadoactual[i].fields.Output2ID == Estadoanterior[i].fields.Output2ID) delete Estadoactual[i].fields.Output2ID;
if(Estadoactual[i].fields.Output2Num == Estadoanterior[i].fields.Output2Num) delete Estadoactual[i].fields.Output2Num;
if(Estadoactual[i].fields.Output2Status == Estadoanterior[i].fields.Output2Status) delete Estadoactual[i].fields.Output2Status;
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
45
if(Estadoactual[i].fields.RStatus == Estadoanterior[i].fields.RStatus) delete Estadoactual[i].fields.RStatus;
}
}
flow.set('Estadoanterior',JSON.parse(JSON.stringify(flow.get('Estadoactual'))))
msg.payload = Estadoactual;
return msg;
Tabla 10: Código Detector nuevos datos
Para inicializar la variable de “Estadoanterior” se ha hecho uso de la pestaña “Setup” que solo
se ejecuta una vez cuando el nodo es desplegado.
4.1.2. InfluxDB
InfluxDB es una base de datos de tipo temporal (añade un tag temporal a los datos que
se almacenan) escrita en Go y optimizada para el almacenamiento y la recuperación
rápida de los datos en campos como monitorización, métricas de aplicaciones y datos
de sensores de IoT.
Figura 45: Logo InfluxDB
InfluxDB distingue entre tags y fields. Mientras que los tags solo contienen metadatos
incluidos en el índice, los fields incluyen valores que pueden evaluarse más adelante.
Esta distinción facilita el manejo de la base de datos y la evaluación de los datos de
medición.
Como ventajas de usar InfluxDB podemos encontrar que son mucho más rápidas que las
bases de datos relacionales a la hora de almacenar y procesar datos de medición con
marcas temporales. Un sistema de gestión de bases de datos (DBMS) dedica parte de su
rendimiento a la organización de un índice complejo, que en este ámbito de aplicación
no se usa. InfluxDB también es capaz de mantener una elevada velocidad de escritura,
ya que usa un índice muy sencillo.
Cabe destacar que este software estaba basado en la nube y no hace falta ningún tipo
de instalación en la maquina local para ejecutarlo.[25]
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
46
4.1.2.1. Instalación de InfluxDB
Para la Instalación del software en el ordenador, ya que InfluxDB también ofrece poder
utilizar su base de datos en la nube, se deberá ir al portal de InfluxDB a la sección de
descargas o a la dirección https://portal.influxdata.com/downloads/ y seleccionaremos
la versión v1.8.3. Se nos abrirá una ventana y deberemos buscar nuestro sistema
operativo y descargaremos el archivo comprimido haciendo clic izquierdo en el link que
nos proporcionan.
Una vez descargado el zip, descomprimiremos dicho archivo dentro de la siguiente ruta:
C:\Program Files.
Para facilitar acceder a la base de datos crearemos un acceso directo en el escritorio del
archivo tipo aplicación influx.exe.
Para empezar a ejecutar InfluxDB iremos al símbolo del sistema y ejecutaremos el
siguiente comando:
Figura 46: Ejecución InfluxDB
Nos aparecerá una serie de información sobre InfluxDB que se puede configurar en el
archivo influxdb.conf abriéndolo con Notepad, como por ejemplo en el puerto que
InfluxDB está escuchando.
Una vez ejecutado este comando en el símbolo del sistema podremos ejecutar el acceso
directo creando anteriormente en el escritorio y se nos abrirá la base de datos lista para
poder usarla:
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
47
Figura 47: Base de datos InfluxDB con el comando SHOW DATABASES
4.1.2.2. Conceptos Clave
Primero de todo, para entender mejor la base de datos tenemos que diferenciar unos
conceptos claves que servirán de ayuda a la hora de moverse por InfluxDB. Esto también
ayudará a entender mejor los próximos capítulos en los que se hará referencia a algunos
de estos conceptos.
• Database: Traducido del inglés Base de datos, es un contenedor lógico para
usuarios, políticas de retención, consultas continuas y datos de series
temporales. Se usa para almacenar gran cantidad de datos, relacionados y
estructurados que pueden ser consultados rápidamente según las características
selectivas deseadas. En InfluxDB podemos crear diferentes Data bases según
nuestras necesidades y dentro de una Database encontraremos diferentes
Measurements.
• Measurement: En ingles quiere decir medición. En InfluxDB, cuando hablamos
de measurement es lo mismo que decir una tabla en otras bases de datos. Es una
parte de la base de datos que contiene los datos estructurador almacenados en
los campos (fields) asociados. Los Measurements son strings.
• Field key: Es la parte clave del par clave-valor que forma un campo. Los Field keys
son strings que almacenan metadatos. Es lo mismo que hablar de la cabecera de
una columna en una tabla. La parte valor no es obligatoria que exista, aunque la
parte clave si lo es. Un valor siempre tiene que ir asociado a su clave mientras
que una clave puede no tener valores asociados.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
48
• Field values: Es la parte del valor del par clave-valor que forma un campo. Los
Field values son los datos reales que almacena nuestra tabla. Estos puedes ser
strings, flotantes, enteros o booleanos. Un Field value siempre está asociado un
timestamp. Los Field values no están indexados, por lo que las consultas sobre
un valor de un campo escanean todos los puntos que coinciden con el rango de
tiempo especificado.
• Tag key: Es la parte clave del par clave-valor de un Tag. Los tags keys son strings
que almacenan metadatos. Al igual que los Field keys también son la cabecera
de la columna tags en una tabla. Es como si habláramos de la descripción de una
fila de datos. Los tags keys, por el contrario, si están indexados, por lo que una
consulta sobre un tag solo mostrará una fila, no un rango de tiempo.
• Tag values: Es la parte valor del par clave-valor que constituye un tag. Es el
mismo concepto que el Field value, pero relacionado con los tags. Un tag value
no puede existir sin un tag key.
• Timestamp: Es la data y la hora asociada con un Field value. Todas las datas del
InfluxDB son UTC y están en formato Unix epoch nanoseconds. Esto es un
sistema para la descripción de instantes de tiempo que se define como la
cantidad de nanosegundos transcurridos desde la medianoche UTC del 1 de
enero del 1970.
• User: Traducido como usuario, es una persona que utiliza un ordenador o un
servicio de red. Este debe contar con nombre de usuario y contraseña. Existen
dos tipos de usuarios en InfluxDB:
▪ Administradores: Son usuarios que tienen todos los privilegios dentro de
una base de datos. Estos incluyen crear databases, measurements tanto
escribir en ellas y permisos de lectura.
▪ No administradores: Pueden tener o no los mismos privilegios que el
administrador, aunque normalmente solo se les da privilegios de lectura.
• Query: Se traduce como consulta. Una query es una petición que se realiza sobre
la base de datos que devuelve los datos especificados en ella.
• Retention Policy: Es un fichero dentro de InfluxDB que especifica el tiempo que
influxDB debe conservar los datos almacenados, cuantas copias de los datos
almacenar en el clúster3. Las políticas de retención son únicas para una base de
datos y una medición. [26]
3 Se aplica a los conjuntos de ordenadores construidos mediante la utilización de hardware comunes y que se comportan como si
fuese una única máquina. Cada uno de estos ordenadores se les conoce como nodos.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
49
4.1.2.3. Comandos
En este apartado se hablará de los comandos básicos para hacer uso de la base de datos
de InfluxDB. Igual que los conceptos clave, hay una gran cantidad de comandos
disponibles para poder ejecutar y administrar las bases de datos de InfluxDB, aunque en
este proyecto solo se hablará de los comandos que apliquen.
• CREATE DATABASE <database_name>: Este comando se utiliza para crear una
base de datos dentro de nuestro ordenador para poder empezar a trabajar. Este
comando no devuelve ninguna información.
• SHOW DATABASES: Se utiliza para mostrar las bases de datos de las que
disponemos actualmente. Por defecto muestra una base de datos llamada
“_internal”.
• DROP DATABASE <database_name>: Borra la base de datos especificada dentro
de los símbolos de mayor y menor.
• USE <database_name>: Selecciona la base de datos deseada para empezar a
trabajar dentro de ella.
• SHOW MEASUREMENTS: Muestra las mediciones que disponemos dentro de
nuestra base de datos. Por defecto no devuelve nada hasta que añadamos datos
y una medición dentro de nuestra base de datos.
• DROP MEASUREMENT <measurement_name>: Elimina tanto las mediciones
como los datos que hay dentro de ellas.
• SHOW RETENTION POLICIES [ON <database_name>]: Muestra las políticas de
retención de la base de datos especificada. InfluxDB genera una política de
retención por defecto con los siguientes valores:
Figura 48: políticas de retención
Donde la duración de cero segundos es el valor por defecto que indica que no se
borraran los datos.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
50
• ALTER RETENTION POLICY <retention_policy_name> ON <database_name>
[DURATION <duration>] [REPLICATION <n>] [SHARD DURATION <duration>]
[DEFAULT]: Comando utilizado para modificar la política de retención de una
base de datos. Un ejemplo de cómo modificar la política de retención para
disminuir su retencion a 10 dias seria:
ALTER RETENTION POLICY "autogen" ON "pruebaTFE" DURATION 10d SHARD DURATION 168h REPLICATION 1 DEFAULT
Tabla 11: Ejemplo ALTER RETENTION POLICY
Cambiando el ALTER por CREATE se generará una nueva política de retención.
• SHOW FIELD KEYS [ON <database_name>] [FROM <measurement_name>]:
Muestra los campos clave de una medición dentro de una base de datos. [ON
<database_name>] es opcional si antes se ha especificado la base de datos con
el comando USE <database_name>.
• SHOW TAG KEYS [ON <database_name>] [FROM <measurement_name>]:
Muestra las etiquetas de una medición. Al igual que con los Fields, la
especificación de la base de datos es opcional si se ha especificado antes con el
comando USE <database_name>.
• SHOW SERIES [FROM <measurement_name>]: devuelve los tags de la medición
deseada. Sino se especifica ninguna medición, devolverá todos los tags de todas
las mediciones con el nombre de la medición delante.
• SHOW USERS: Muestra los usuarios y si es usuario administrador o no. Por
defecto no hay usuarios por lo que este comando no devolvería ningún
resultado.
• CREATE USER <username> WITH PASSWORD '<password>' WITH ALL
PRIVILEGES: Sirve para crear usuarios administradores, aunque por defecto no
hace falta ya que al ejecutarse en el propio ordenador ya seremos
administradores.
Estos comandos están relacionados con la gestión y la exploración de las mediciones y
las bases de datos. Ahora se procederá a explicar los comandos utilizados para la
exploración de los datos:
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
51
[1] SELECT <field_key>[,<field_key>,<tag_key>] FROM
<measurement_name>[,<measurement_name>]: Es el comando básico para
seleccionar varios campos o tags de una o varias mediciones. Si no se especifica
ningún campo, sino que se escribe “SELECT * “esto devolverá todos los campos
y tags de la medición especificada.
Si se desea incluir algún tag se deberá especificar un campo, si solo se desea ver
los tags se usará el comando SHOW SERIES [FROM <measurement_name>]. Un
ejemplo de la sintaxis del SELECT seria:
SELECT InputID, InputNum, InputStatus, Retenedor FROM Retenedores
Tabla 12: Ejemplo cláusula SELECT
[2] SELECT_clause FROM_clause WHERE <conditional_expression> [(AND|OR)
<conditional_expression> [...]]: Esta es la sintaxis del comando para añadir
condiciones a las querys que hagamos. Donde la cláusula del select puede ser un
campo o todos los campos (*) y la cláusula del from uno o más measurements.
Donde la expresión condicional puede hacer referencia a Fields o a Tags con las
siguientes expresiones:
▪ field_key <operator> ['string' | boolean | float | integer]
▪ tag_key <operator> ['tag_value']
Las operaciones soportadas por InfluxDB son las siguientes:
Figura 49: Operaciones permitidas en la cláusula WHERE
Un ejemplo usando el WHERE seria:
SELECT * FROM Retenedores WHERE InputID = 1 AND (Retenedor != ‘10’)
Tabla 13: Ejemplo cláusula WHERE
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
52
[3] SELECT_clause FROM_clause [WHERE_clause] GROUP BY [* |
<tag_key>[,<tag_key]]: EL GROUP BY se utiliza para agrupar los resultados de
una query por uno o más tags. Al igual que con el select si se utiliza el signo “ * “
se agruparan los resultados por todos los tags disponibles. Como ejemplo
agruparemos todos los resultados del retenedor 3.
Si la query incluye la cláusula WHERE con una expresión condicional sobre los
tags, a cláusula GROUP BY debe aparecer después del WHERE con los mismos
tags.
SELECT * FROM Retenedores WHERE Retenedor = 3 GROUP BY Retenedor
Tabla 14: Ejemplo clausula GROUP BY
[4] SELECT_clause [INTO_clause] FROM_clause [WHERE_clause]
[GROUP_BY_clause] ORDER BY time DESC: Con este comando podremos
ordenar los datos de forma descendente por el tag temporal que InfluxDB le
añade a todos los Field values que se le añadan.
[5] SELECT * FROM <measurement_name> LIMIT X: Con este comando limitaremos
los datos que nos devuelve la petición a la cantidad especificada después del
LIMIT. En el ejemplo limitaremos los datos a 10 filas.
SELECT * FROM Retenedores LIMIT 10
Tabla 15: Ejemplo función LIMIT
[6] SELECT COUNT <field_key> FROM <measurement_name>: Este comando se
utiliza para contra las filas que hay rellenadas con datos dentro de un campo. Un
ejemplo para contar los datos de la ID de la segunda salida del retenedor 14 sería
el siguiente:
SELECT COUNT Output2ID FROM Retenedores WHERE Retenedor = ‘14’
Tabla 16: Ejemplo function COUNT
Todas las posibilidades para hacer consultas básicas en la base de datos se han
especificado anteriormente con su sintaxis y ejemplos prácticos sobre este proyecto.
Aunque se debe mencionar una funcionalidad interesante que también nos ofrece
InfluxDB para añadir datos a una base de datos es la siguiente:
[7] influx -import -path=<txt_name> -precision=s -database=<database_name>:
Este comando nos da la posibilidad de añadir datos a una base de datos desde
un archivo de texto (.txt). No se especificarán los detalles del formato del archivo
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
53
ya que no se ha utilizado, pero se pueden encontrar en la documentación de
InfluxDB.[26]
Con todos estos comandos ya seremos capaces de hacer uso de la base de datos de
InfluxDB
4.1.3. Grafana
Grafana es una herramienta para visualizar datos de serie temporales. Es un software
libre basado en licencia de Apache 2.0. Permite crear cuadros de mando y gráficos a
partir de múltiples fuentes.
Figura 50: Logo Grafana
Además de administrar cuadros de mando clásicos, Grafana ofrece compartir un cuadro
de mando actual mediante la creación de un enlace o una instantánea estático a del
mismo. Todos los paneles de control y las fuentes de datos están vinculadas a una
organización y los usuarios se vinculan a estas a través de roles. De este modo, Grafana
es capaz de evitar cambios no deseados en los dashboards.[27]
4.1.3.1. Instalación de Grafana
Para la instalación de Grafana de forma local deberemos ir a la página del software y
hacer clic en la pestaña de “Downloads” que nos llevara al siguiente link:
https://grafana.com/get.
Deberemos seleccionar la opción de “You Run It” para seleccionar la versión que se
ejecuta localmente en nuestro ordenador.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
54
Figura 51: Web de descarga de Grafana
Se nos abrirá la ventana que se muestra arriba y deberemos seleccionar nuestro sistema
operativo y la versión que queremos. También podemos escoger entre la versión Open Source
o Enterprise, pero para este proyecto se ha usado la Open Source.
Debajo de las casillas de los sistemas operativos disponibles, aparecerá el link de descarga del
instalador o la versión Standalone. Descargaremos el instalador y lo ejecutaremos. Una vez
seguidos los pasos del instalador y finalizada la instalación, ya podremos ir al navegador y
escribir http://localhost:3000/ y se nos abrirá la interfaz del software.
Figura 52: Página principal de Grafana
Al contar de instalador no hace falta ir al símbolo del sistema y ejecutar el programa, sino que
nos crea un servicio que siempre lo está ejecutando. [28]
Para este proyecto se ha optado en instalar un Plugin para replicar la celda de trabajo y así ver
el movimiento de las bandejas de forma más gráfica.
4.1.3.2. Plugin
Un Plugin es una aplicación que se relaciona con otra para agregar una funcionalidad
nueva. La aplicación adicional es ejecutada per la aplicación principal e interactúan por
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
55
medio de la interfaz principal. Se tiene que diferenciar entre plugin y complemento, ya
que los plugin son desarrollados por empresas reconocidas y tienen certificador de
seguridad, mientras que los complementos pueden ser desarrollados por cualquiera.
Instalación de Plugins
Para instalar un plugin en Grafana deberemos ir a su página y colocarnos encima de la
pestaña de Grafana, se nos abrirá un desplegable y seleccionar la opción de Plugins. O
también podemos ir directamente a la dirección https://grafana.com/grafana/plugins.
Se nos abrirá la ventana donde deberemos buscar el plugin que se nos adapte mejor a
nuestras necesidades
Figura 53: Pagina de descarga de Plugins
Una vez seleccionado el plugin necesario se nos abrirá la página donde nos dirá las nuevas
funcionalidades que se añadirán y las características del plugin. Al final del todo nos indicará el
manual de instalación que por facilidad se escogerá la instalación del “Grafana-cli”.
Copiaremos el comando que nos indica y deberemos abrir el símbolo del sistema como
administrador y navegaremos a la carpeta bin dentro de GrafanaLabs con el siguiente comando:
Figura 54: Comando a ejecutar para la instalación del plugin
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
56
Para finalizar deberemos abrir el administrador de tareas e ir a la pestaña de servicios y buscar
el servicio con nombre “Grafana”. Haremos clic derecho y reiniciaremos el servicio y también
refrescaremos la página del navegador.
Figura 55: Servicio que está ejecutando Grafana.
Una vez hemos seguido todos los pasos podremos empezar a diseñar nuestro dashboard para
mostrar la información que deseemos.
4.1.3.3. Diseño del Dashboard
Para empezar a diseñar los dashboards iremos al menú de la izquierda de la página principal de
Grafana y seleccionaremos la opción de crear con el icono de una suma. Aquí podremos empezar
a crear nuestros dashboards.
Figura 56: Pagina creación de un nuevo dashboard
En el apartado de visualización escogeremos el modo de visualización que deseemos para
nuestros datos. El plugin que hemos utilizado nos permite crear un diagrama con la herramienta
de app.diagramas.net, de este modo podemos plasmar la celda de trabajo del laboratorio para
ver la trazada que siguen las bandejas.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
57
Figura 57: Diagrama dibujado para el dashboard
Una vez tenemos el diagrama que queremos, para hacer el seguimiento de una bandeja hemos
de crear reglas de mapeo para que plataformas y retenedores cambien de color en función de
los estados posibles que hemos comentado en el apartado 2.6.
Dichas reglas de mapeo nos permiten ligar un objeto del diagrama que hemos creado a una
query llamando a esta por un alias e indicando en la regla de mapeo. Este paso lo repetiremos
36 veces para poder seleccionar los 36 retenedores de los que disponemos.
Figura 58: Reglas de mapeo.
En la imagen podemos ver la query asociada a la regla de mapeo de la plataforma PT02. Una vez
el objeto está ligado, el plugin que hemos instalado nos permite crear animaciones, como
cambiar de color al objeto del diagrama o que aparezca un texto en con los valores que retorna
la query.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
58
Se pueden agregar tantos Plugins como deseemos a Grafana para añadir más funcionalidades,
como, por ejemplo, para crear un mapa geotérmico y que cambie el color según la temperatura
que hace.
5. Validación
En este proyecto se realizarán dos tipos de pruebas: funcionales y operacionales. Durante todo
el montaje de la arquitectura IoT se han realizado pruebas con datos ficticios para comprobar el
funcionamiento del programa desarrollado. Esto nos permitirá asegurarnos que una vez se
configuren los bloques de Node-RED con la dirección IP de los PLC’s correctamente, todo
funcione correctamente sin ningún imprevisto.
Las pruebas funcionales son pruebas basadas en la ejecución, revisión y retroalimentación de
las funcionalidades previamente diseñadas para el software. Dichas pruebas se hacen mediante
el diseño de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta
el modelo informático. Son pruebas específicas, concretas y exhaustivas para validar que el
software hace lo que debe y lo que se ha pedido que realice.
Las pruebas operacionales se realizan para asegurarse que un sistema, subsistema o
componente está en condiciones operativa, que operan correctamente. Estas pruebas se
realizan en diferentes apartados del software, a un nivel más bajo que las funcionales, ya que
permite decir si un bloque de Node-RED, por ejemplo, está funcionando.
5.1. PLC → Node-RED
Para lograr realizar pruebas remotamente sin la necesidad que la celda esté funcionando
durante todo el rato. Se ha ejecutado un pequeño código de Node-RED que permite escribir
datos en un servidor Modbus ficticio.
5.1.1. Descripción del ensayo: Lectura de datos
Esta prueba funcional se basa en la escritura y lectura de datos en el servidor ficticio para que a
la hora de cambiar la dirección IP a la de nuestro PLC este sea capaz de leer datos y concatenarlos
para disponer de un solo array.
Como parte de la prueba operacional se ha añadido un debug en la salida del bloque CSV para
ver si la lectura desde el archivo CSV funciona correctamente.
Figura 59: Diagrama escritura datos en servidor ficticio Node-RED
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
59
Con esta pequeña línea de código nos permite leer datos introducidos desde un archivo CSV a
un servidor Modbus. Igual que el código para la petición de lectura de datos de un PLC se debe
añadir una función para configurar el mensaje que debe introducir los datos al servidor.
La prueba funcional se ha hecho al final de todo el proceso de escritura y lectura de datos una
vez concatenado las arrays para ver que nos llega un solo buffer a lo que es el cuerpo del
programa.
Figura 60: Prueba funcional escritura y lectura datos ficticios.
5.1.2. Resultados esperados: Lectura de datos
Con esta prueba, sobre todo la funcional, se espera que en la ventana de debug se nos muestre
un array de 360 caracteres.
5.1.3. Resultados obtenidos: Lectura de datos
Podemos ver que, una vez insertados los datos, leídos y concatenados las 10 peticiones de datos,
el objeto que nos llega es un buffer de 360 caracteres de largo.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
60
Figura 61. Resultados obtenidos en la prueba funcional
Con esto ya seremos capaces de empezar a tratar los datos para almacenarlos en InfluxDB y
posteriormente leerlos desde Grafana.
5.2. Node-RED → InfluxDB
5.2.1. Descripción del ensayo: Acondicionamiento de los Datos
En este ensayo de desea hacer pruebas sobre el cuerpo de la gestión del flujo de información,
dicho con otras palabras, el acondicionamiento de los datos para añadirlos en la base de datos
y el detector de nuevos datos. Estas pruebas son operacionales, ya que se validará el
funcionamiento de cada bloque por separado
Figura 62: pruebas operacionales del acondicionamiento de los datos.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
61
Las pruebas funcionales consistirán en ver los datos ya añadidos en InfluxDB y que estén
correctamente añadidos o que los datos repetidos no se hayan añadido. El debug de la derecha
del todo también servirá como prueba operacional ya que es el resultado que ve InfluxDB. Para
proceder a esta prueba se usará un inject tipo buffer con un buffer estático.
5.2.2. Resultados esperados: Acondicionamiento de los Datos
En este apartado se espera que los datos se añadan de forma automática asignándose a una
columna según la posición en el array que llega. Cada 10 datos el programa de datos retenedores
añade un tag con el número del retenedor que no obligatoriamente debe coincidir con el
retenedor o plataforma.
Para el bloque que detecta los datos repetidos se espera que estos no sean añadidos en la base
de datos y que los retenedores que lleguen siempre igual tampoco se añada el tag.
5.2.3. Resultados obtenidos: Acondicionamiento de los Datos
Como podemos ver en la foto siguiente, se obtiene un array de 36 objetos con los datos del
buffer distribuido y con el field y el tag asociado correctamente. Esto lo podemos ver mejor
desde la base de datos con la distribución de columnas haciendo un select sobre el
measurement.
Figura 63: Resultado agregación datos a InfluxDB
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
62
Para el funcionamiento del detector de los nuevos datos se ha realizado otro inject cambiando
unos pocos valores del buffer. Así podemos ver que los datos repetidos llegan vacíos y si todos
los datos de un retenedor no han cambiado este no se añade.
Figura 64: Resultado funcional del detector de nuevos datos
Figura 65: Prueba Operacional datos retenedores
En esta imagen se puede apreciar el aspecto del objeto que nos muestra Node-RED y también
podemos validar que está agrupando los datos de la forma correcta.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
63
5.3. InfluxDB → Grafana
5.3.1. Descripción del ensayo: Conexión con InfluxDB
Para comprobar que Grafana conecta con InfluxDB, debemos ir al menú de la izquierda e ir a
configuración, Data source. Una vez estemos aquí le daremos al botón de añadir una base de
datos nuevas y seleccionaremos InfluxDB.
Figura 66: Añadir una base de datos
Configuraremos los datos necesarios para la lectura de nuestra base de datos. Al estar ubicada
en local, solo hará falta que especifiquemos la URL donde InfluxDB está escuchando (puerto
8086) y que indiquemos la base de datos de donde queremos leer. Si deslizamos la pantalla hacia
abajo, Grafana nos dará la opción de realizar una prueba de conexión a la base de datos que
hemos especificado.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
64
Figura 67: configuración data source
Otra prueba que se puede realizar es, una vez montada la query, le damos al icono del lápiz para
que nos muestre la Select que monta y poder lanzarla directamente en InfluxDB. La query de
Grafana es ligeramente diferente a la de InfluxDB ya que la cláusula WHERE donde especifica
$timeFilter no es capaz de leerlo y hay que eliminarlo y ver si devuelve los datos que deseamos.
Figura 68: Query montada por Grafana
Cuando asociemos la plataforma o retenedor a una regla de mapeo según colores, el objeto
debe cambiar según el valor asociado en la regla. Esta prueba es interesante porque, de este
modo, podemos saber si desde Grafana lee la base de datos.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
65
5.3.2. Resultados esperadores: Conexión con InfluxDB
Se espera que el test de conexión desde Grafana a InfluxDB no devuelva ningún error y que
cuando nos pongamos encima de una regla de mapeo el dibujo deseado cambie de color según
los valores establecidos.
5.3.3. Resultados obtenidos: Conexión con InfluxDB
En el test del origen de los datos se ha obtenido que Grafana está leyendo desde nuestro
measurement correctamente.
Figura 69: Test de conexión correcto
También podemos ver que se conecta y pide los datos correctamente a través del dashboard.
En el caso de prueba se ha hecho con la Plataforma PT03 asociándola al retenedor número 3
que en el momento de la prueba su ultimo estado era 1 (reposo).
Se aprecia que la plataforma cambia de color según el estado del último dato añadido en el
campo RStatus del retenedor 3.
Figura 70: Prueba conexión a InfluxDB a través del Dashboard
6. Trabajo futuro
Como unas de las aplicaciones, de las muchas posibles, que se ha querido añadir a este trabajo,
es la detección de anomalías utilizando la desviación de la media absoluta. Esto no deja de ser
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
66
una aproximación sencilla a las herramientas utilizadas para este mismo objetivo. Un ejemplo
de estas herramientas son algoritmos complejos basados en inteligencia artificial.
Cuando quieres reconocer cuando un servidor, sensor o máquina virtual se está comportando
diferente a otras, se puede usar la desviación media absoluta para identificar cuando una serie
de tiempo se ha desviado del funcionamiento “normal”. Esta aproximación es muy utilizada por
su eficiencia y efectividad. La mediana, o el valor del medio, de todos los puntos de una serie
temporal describe el comportamiento normal de un dispositivo. Una desviación importante de
este valor indica que la seria es anómala.
Figura 71: Desviación anómala de la mediana.
La fórmula utilizada para aplicar este algoritmo es:
𝑋𝑖 = 𝑋𝑎𝑛ó𝑚𝑎𝑙𝑎 𝑐𝑢𝑎𝑛𝑑𝑜|𝑋𝑖 − 𝑚𝑒𝑑𝑖𝑋𝑖|
𝑘 𝑚𝑒𝑑𝑖|𝑋𝑖 − 𝑚𝑒𝑑𝑖|> 𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑
El parámetro K es un factor de escala que asume normalmente los datos distribuidos.
El término del denominador es la desviación de la media absoluta.
El “threshold” es un valor normalmente escogido por el usuario que indica el valor a partir del
cual es un valor anómalo.
mediXi es la mediana de la muestra o simplemente el valor medio de un lote de puntos en las
series temporales.
Xi es un punto cualquiera en el tiempo i.
Xanómala es el punto de la anomalía.
Uno de los inconvenientes de la detección de anomalías es reducir el número de falsos positivos
y las alertas de ruido. Afortunadamente, existe una solución simple para este problema durante
la aplicación de la desviación de la media absoluta en datos de series de tiempo. En lugar de
alertar sobre cada punto anómalo, la salida de mad () debe monitorearse en una ventana
específica. Si una serie individual genera un cierto porcentaje de puntos anómalos dentro de esa
ventana, entonces la serie muestra un comportamiento anómalo durante un período
prolongado de tiempo, lo que brinda confianza al clasificar la serie como anómala.[29]
7. Conclusiones
Los objetivos de este proyecto era el estudio y profundización en los aspectos de análisis de
datos, internet of things, las ventajas que esto está aportando a la industria 4.0 y el porqué de
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
67
las necesidades de esta nueva revolución industrial. Se pretendía, como objetivo práctico, crear
un ejemplo de arquitectura IoT basado en la celda de producción del laboratorio de
automatización. Dado a las muchas necesidades de los diferentes sectores de producción este
ejemplo puede variar a una infinidad de posibilidades que solo el sector que demanda esta
aplicación puede conocer.
A lo largo de este trabajo se ha indagado en el concepto de industria 4.0 y los grandes
mecanismos que hacen posible su puesta en práctica, se ha llevado a cabo un estudio de la celda
de trabajo necesario para conocer el medio y las posibilidades para aplicar la arquitectura IoT y
se ha aprendido los protocolos de comunicación que hace posible que el flujo de información
llegue desde el nivel más bajo (sensores y actuadores) hasta el nivel más alto (dashboard de
Grafana). Se han obtenido conocimientos en lenguaje de programación java y en el software de
Node-RED y de las posibilidades que este programa nos ofrece. Se ha aprendido a manejar los
softwares de InfluxDB y sobre todo Grafana que con más tiempo la cantidad de dashboards y su
complejidad puede variar infinitamente.
La aplicación que se ha desarrollado es el seguimiento de las bandejas y poder visualizarlo desde
cualquier dispositivo que se pueda conectar a internet. Se ha gestionado el flujo de información
que nos llega desde la celda del laboratorio para estructurarlo y organizarlo para almacenarlo
en una base de datos. También se ha desarrollado una aplicación que permite detectar si ha
habido algún cambio en el estado de los retenedores y las plataformas que ayuda a la eficiencia
del flujo de información ya que el 90% del tiempo estos no cambian de estado. Por último, se ha
desarrollado un dashboard para realizar el seguimiento de las bandejas y poder tomar
decisiones en el futuro sobre la cantidad de bandejas que puede soportar la celda al mismo
tiempo y así aumentar la producción.
Como se ha comentado antes, hay infinidades de funcionalidades que nos aporta Node-RED y
Grafana e incluso crear aplicaciones con Matlab para detectar anomalías como se ha comentado
en el apartado 6 de este documento. Esto es solo un ejemplo simple de las aplicaciones que se
pueden desarrollar con estas herramientas que son igual de potentes que otras herramientas
de pago. Este documento puede servir de base para alguien que quiera empezar a crear
aplicaciones en los tres softwares utilizados. A partir de esta base, la complejidad de las tres
fases se puede expandir y seguir expandiendo esta aplicación con nuevas funcionalidades.
Estoy contento de haber tenido la oportunidad de realizar este proyecto ya que ello conlleva un
aprendizaje adicional que no se ha visto en ninguna asignatura del grado en ingeniería eléctrica,
ya que este sector en la industria está creciendo exponencialmente igual que el volumen de
datos que se generan.
Doy gracias al director del proyecto Miguel y al codirector Ángel por el apoyo y la ayuda durante
la realización tanto de la parte práctica, como de la estructura y organización de la memoria.
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
68
8. Bibliografía
[1] Go (lenguaje de programación). [En línea] [02/08/2020] Recuperada de:
<https://es.wikipedia.org/wiki/Go_(lenguaje_de_programaci%C3%B3n)>
[2] Transmission Control Protocol. [En línea] [02/08/2020] Recuperada de:
<https://ca.wikipedia.org/wiki/Transmission_Control_Protocol>
[3] Protocol d'Internet, IP. [En línea] [03/08/2020] Recuperada de:
<https://ca.wikipedia.org/wiki/Protocol_d%27Internet>
[4] Interfaz de programación de aplicaciones. [En línea] [03/08/2020] Recuperada de:
<https://es.wikipedia.org/wiki/Interfaz_de_programaci%C3%B3n_de_aplicaciones>
[5] Diferencias entre IT y OT. Convergencia entre las tecnologías de información y
operación. 12 julio 2019. [En línea] [04/08/2020] Recuperada de:
<https://oasys-sw.com/diferencias-entre-it-y-ot>
[6] Controlador lògic programable. [En línea] [06/08/2020] Recuperada de:
<https://ca.wikipedia.org/wiki/Controlador_l%C3%B2gic_programable>
[7] Estas son las capas del internet de las cosas. [En línea] [10/08/2020] Recuperada de:
<https://www.t-systemsblog.es/estas-son-las-capas-del-internet-de-las-cosas/>
[8] Defnition. internet of things (IoT). updated in February 2020 [En línea] [10/08/2020]
Recuperada de:
<https://internetofthingsagenda.techtarget.com/definition/Internet-of-Things-IoT>
[9] IT y OT ¿Cuándo llegarán a converger? 28 octubre 2020. [En línea] [10/08/2020]
Recuperada de:
<https://gblogs.cisco.com/es/2020/10/it-y-ot-cuando-llegaran-a-converger/>
[10] 3 Claves Para La Convergencia IT – OT: Big Data, IoT Y Cloud. 19 abril 2019. [En línea]
[10/08/2020] Recuperada de:
<https://zemsaniaglobalgroup.com/3-claves-para-la-convergencia-it-ot-big-data-iot-y-
cloud/>
[11] ¿Qué es el cloud computing? [En línea] [12/08/2020] Recuperada de:
<https://debitoor.es/glosario/definicion-cloud-computing>
[12] Big Data: ¿En qué consiste? Su importancia, desafíos y gobernabilidad. [En línea]
[12/08/2020] Recuperada de:
<https://www.powerdata.es/big-data>
[13] Definición de IaaS, PaaS y SaaS ¿En qué se diferencian? 9 enero, 2020 [En línea]
[12/08/2020] Recuperada de:
<https://www.ambit-bst.com/blog/definici%C3%B3n-de-iaas-paas-y-saas-en-
qu%C3%A9-se-diferencian>
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
69
[14] Magelis Edge Box - Conéctate a la nube con Magelis Edge Box. 13 octubre 2019 [En
línea] [18/08/2020] Recuperada de:
<https://www.infoplc.net/descargas/174-schneider-electric/comunicaciones/2994-
magelis-edge-box-schneider-electric>
[15] Protocolo de comunicaciones. 9 agosto 2020 [En línea] [15/09/2020] Recuperada de:
<https://es.wikipedia.org/wiki/Protocolo_de_comunicaciones>
[16] Modelo OSI. 5 diciembre 2020 [En línea] [15/09/2020] Recuperada de:
<https://es.wikipedia.org/wiki/Modelo_OSI#Arquitectura_de_capas>
[17] Protocolos de comunicaciones. 30 agosto 2004 [En línea] [15/09/2020] Recuperada
de:
<https://desarrolloweb.com/articulos/1617.php>
[18] PROFIBUS: Qué es y Cómo funciona. 2020 [En línea] [15/09/2020] Recuperada de:
<https://www.cursosaula21.com/que-es-profibus/>
[19] ¿Qué es el CAN BUS y cómo funciona? 17 marzo 2020 [En línea] [17/09/2020]
Recuperada de:
<https://www.ingenieriaymecanicaautomotriz.com/que-es-el-can-bus-y-como-
funciona/>
[20] Generalidades del protocolo HTTP. 7 agosto 2020 [En línea] [17/09/2020] Recuperada
de:
<https://developer.mozilla.org/es/docs/Web/HTTP/Overview>
[21] Código fuente. 30 octubre 2020 [En línea] [02/10/2020] Recuperada de:
<https://es.wikipedia.org/wiki/C%C3%B3digo_fuente>
[22] ¿Qué es el software libre? 15 septiembre 2019. [En línea] [02/10/2020] Recuperada
de: <https://www.gnu.org/philosophy/free-sw.es.html>
[23] About Node-RED [En línea] [12/10/2020] Recuperada de:
<https://nodered.org/about/>
[24] FUNDAMENTOS DE NODE-RED. Node-RED: ''Low-code programming for event-driven
applications''. 20 abril 2020 [En línea] [15/10/2020] Recuperada de:
<https://www.techedgegroup.com/es/blog/fundamenos-node-red>
[25] InfluxDB: explicación, ventajas y primeros pasos. 28 septiembre 2020 [En línea]
[30/10/2020] Recuperada de:
<https://www.ionos.es/digitalguide/hosting/cuestiones-tecnicas/que-es-influxdb/>
[26] Get started with InfluxDB OSS 2.0. [En línea] [30/10/2020] Recuperada de:
<https://docs.influxdata.com/influxdb/v2.0>
Gestión de los flujos de comunicación de una planta industrial Oriol Gumà
70
[27] Qué es Grafana y cómo podemos emplearlo para la monitorización. 19 febrero 2019
[En línea] [8/11/2020] Recuperada de:
<https://pandorafms.com/blog/es/que-es-grafana/>
[28] Get started with Grafana & Observability [En línea] [14/11/2020] Recuperada de:
<https://grafana.com/>
[29] Anomaly Detection with Median Absolute Deviation. [En línea] [02/01/2021]
Recuperada de:
<https://www.influxdata.com/blog/anomaly-detection-with-median-absolute-
deviation/>
[30] Sensor fotoeléctrico. 15 octubre 2020 [En línea] [06/11/2020] Recuperada de:
<https://es.wikipedia.org/wiki/Sensor_fotoel%C3%A9ctrico>
[31] ¿Qué es un sensor de proximidad inductivos? [En línea] [06/11/2020] Recuperada de:
<https://www.keyence.com.mx/ss/products/sensor/sensorbasics/proximity/info/>