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


Í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


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


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


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


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


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.


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.


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


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.


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


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.


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.


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.


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


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.


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:


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]


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


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


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


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


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.


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:


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


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


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


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


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.


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.


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.


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.


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.


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


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


29

3 ID de la bandeja de salida1

-1 →65536


-1 →65536

5 Estado de la bandeja de salida1

-1 →65536


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


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


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


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

https://nodejs.org/en/download/


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

http://127.0.0.1:1880/

http://localhost:1880/


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


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.


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


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


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.


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.


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.


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


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.


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


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;


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]


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:

https://portal.influxdata.com/downloads/


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.


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.


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.


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:


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


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


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.

https://grafana.com/get


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

http://localhost:3000/


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

https://grafana.com/grafana/plugins


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.


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.


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


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.


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.


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


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.


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.


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.


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


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


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.


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]


<https://www.powerdata.es/big-data>

[13] Definición de IaaS, PaaS y SaaS ¿En qué se diferencian? 9 enero, 2020 [En línea]


<https://www.ambit-bst.com/blog/definici%C3%B3n-de-iaas-paas-y-saas-en-

qu%C3%A9-se-diferencian>

https://es.wikipedia.org/wiki/Go_(lenguaje_de_programaci%C3%B3n)

https://ca.wikipedia.org/wiki/Transmission_Control_Protocol

https://ca.wikipedia.org/wiki/Protocol_d%27Internet

https://es.wikipedia.org/wiki/Interfaz_de_programaci%C3%B3n_de_aplicaciones

https://oasys-sw.com/diferencias-entre-it-y-ot

https://ca.wikipedia.org/wiki/Controlador_l%C3%B2gic_programable

https://www.t-systemsblog.es/estas-son-las-capas-del-internet-de-las-cosas/

https://internetofthingsagenda.techtarget.com/definition/Internet-of-Things-IoT

https://gblogs.cisco.com/es/2020/10/it-y-ot-cuando-llegaran-a-converger/

https://zemsaniaglobalgroup.com/3-claves-para-la-convergencia-it-ot-big-data-iot-y-cloud/

https://zemsaniaglobalgroup.com/3-claves-para-la-convergencia-it-ot-big-data-iot-y-cloud/

https://debitoor.es/glosario/definicion-cloud-computing

https://www.powerdata.es/big-data

https://www.ambit-bst.com/blog/definici%C3%B3n-de-iaas-paas-y-saas-en-qu%C3%A9-se-diferencian

https://www.ambit-bst.com/blog/definici%C3%B3n-de-iaas-paas-y-saas-en-qu%C3%A9-se-diferencian


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]


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

https://www.infoplc.net/descargas/174-schneider-electric/comunicaciones/2994-magelis-edge-box-schneider-electric

https://www.infoplc.net/descargas/174-schneider-electric/comunicaciones/2994-magelis-edge-box-schneider-electric

https://es.wikipedia.org/wiki/Protocolo_de_comunicaciones

https://es.wikipedia.org/wiki/Modelo_OSI#Arquitectura_de_capas

https://desarrolloweb.com/articulos/1617.php

https://www.cursosaula21.com/que-es-profibus/

https://www.ingenieriaymecanicaautomotriz.com/que-es-el-can-bus-y-como-funciona/

https://www.ingenieriaymecanicaautomotriz.com/que-es-el-can-bus-y-como-funciona/

https://developer.mozilla.org/es/docs/Web/HTTP/Overview

https://es.wikipedia.org/wiki/C%C3%B3digo_fuente

https://www.gnu.org/philosophy/free-sw.es.html

https://nodered.org/about/

https://www.techedgegroup.com/es/blog/fundamenos-node-red

https://www.ionos.es/digitalguide/hosting/cuestiones-tecnicas/que-es-influxdb/

https://docs.influxdata.com/influxdb/v2.0


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/>

https://pandorafms.com/blog/es/que-es-grafana/

https://grafana.com/

https://www.influxdata.com/blog/anomaly-detection-with-median-absolute-deviation/

https://www.influxdata.com/blog/anomaly-detection-with-median-absolute-deviation/

https://es.wikipedia.org/wiki/Sensor_fotoel%C3%A9ctrico

https://www.keyence.com.mx/ss/products/sensor/sensorbasics/proximity/info/

TRABAJO FINAL DE ESTUDIOS

Documents

Transcript of TRABAJO FINAL DE ESTUDIOS