INFOTEC CENTRO DE INVESTIGACIÓN E INNOVACIÓN · 2020. 8. 28. · 2.4 Estándar ZigBee ... cuando...

INFOTEC CENTRO DE INVESTIGACIÓN E INNOVACIÓN EN TECNOLOGÍAS DE LA INFORMACIÓN Y

COMUNICACIÓN

DIRECCIÓN ADJUNTA DE INNOVACIÓN Y CONOCIMIENTO GERENCIA DE CAPITAL HUMANO

POSGRADOS

“RED DE SENSORES INALÁMBRICOS PARA MANTENIMIENTO PREDICTIVO

PdM E-2019”

IMPLEMENTACIÓN DE UN PROYECTO LABORAL Que para obtener el grado de MAESTRA EN SISTEMAS EMBEBIDOS

Presenta:

Laura Islas Ortega

Asesor:

Dr. Victor Miguel Hernández Maldonado

Ciudad de México, a 07 de junio de 2020.

Agradecimientos

Principalmente a mis padres y hermana, que siempre han estado a mi lado para

apoyarme incondicionalmente. También me gustaría agradecer todo el apoyo

recibido de mis compañeros de trabajo, ya que innumerables veces y de varias

formas me ayudaron a concluir con éxito mis estudios.

No ha sido sencillo el camino recorrido, pero fue más ameno recorrerlo junto

a mis compañeros y amigos de maestría, que siempre mostraron solidaridad y

camaradería unos con otros y hacia mi persona, sin duda este fue un logro en

equipo.

Tabla de Contenido

Introducción .................................................................................................................. 1

Capítulo 1: Contexto ...................................................................................................... 4

1.1 Breve descripción del problema. ............................................................................... 4 1.1.1 Gestión del mantenimiento industrial. ....................................................................................... 4

1.2 Motivación. .............................................................................................................. 5

1.3 Objetivos. ................................................................................................................. 9 1.3.1 Objetivo general. ........................................................................................................................ 9 1.3.2 Objetivos específicos. ............................................................................................................... 10

1.4 Metodología. .......................................................................................................... 11

Capítulo 2: Estado del arte ........................................................................................... 12

2.1 Incremento de consumo de corriente en motores como síntoma de daño. ............... 12

2.2 Mantenimiento 4.0 aplicado al mantenimiento predictivo. ...................................... 13

2.3 Red de Sensores Inalámbricos para recolección de datos. ........................................ 14

2.4 Estándar ZigBee. ..................................................................................................... 16

2.5 Arquitectura para IoT.............................................................................................. 20

Capítulo 3: Desarrollo del proyecto .............................................................................. 23

3.1 Creación de la arquitectura. .................................................................................... 23 3.1.1 Especificación de requerimientos. ............................................................................................ 23 3.1.2 Requerimientos funcionales. .................................................................................................... 24 3.1.3 Requerimientos no funcionales. ............................................................................................... 25 3.1.4 Arquitecturas desarrolladas. .................................................................................................... 27

3.2 Implementación de la arquitectura. ........................................................................ 28 3.2.1 Descripción de Hardware. ........................................................................................................ 28 3.2.2 Configuración de red de sensores inalámbricos XBee. ............................................................. 30 3.2.3 Construcción del prototipo. ...................................................................................................... 31

3.3 Prueba del sistema. ................................................................................................ 35

Capítulo 4: Instalación del prototipo en la industria y trabajo futuro ............................ 40

4.1 Instalación de prototipo en motores de sistema hidráulico. ..................................... 40

4.2 Trabajo futuro. ....................................................................................................... 43

Capítulo 5: Impacto social y económico ........................................................................ 45

5.1 Impacto social. ....................................................................................................... 45

5.2 Impacto económico. ............................................................................................... 45

Conclusiones ............................................................................................................... 49

Bibliografía ................................................................................................................. 50

Anexos ........................................................................................................................ 57

Anexo I – Código de Arduino para adquisición de datos ....................................................... 57

Índice de figuras

Figura 1. Gráfica de actividades programadas contra fallas emergentes. ............... 6

Figura 2. Arquitectura general del sistema de monitoreo. ....................................... 9

Figura 3. Modelo de Ciclo de vida de diseño y desarrollo de sistemas embebidos.

.............................................................................................................................. 11

Figura 4. Ilustración de motor trabajando con sobrecarga. ................................... 12

Figura 5. Protocolos para Redes de Sensores Inalámbricos. ............................... 15

Figura 6. Pila de protocolos para ZigBee. ............................................................. 16

Figura 7. Topologías para redes ZigBee. .............................................................. 19

Figura 8. Arquitectura general para IoT. ................................................................ 21

Figura 9. Arquitectura para aplicación de monitoreo ambiental. ............................ 22

Figura 10. Arquitectura de sistema de monitoreo de motores. .............................. 27

Figura 11. Arquitectura de Nodo sensor y Gateway. ............................................. 28

Figura 12. Software XCTU. ................................................................................... 30

Figura 13. Estructura de trama API. ...................................................................... 32

Figura 14. Flujo desarrollado en Node-RED.......................................................... 33

Figura 15. Datos de entrada sin procesar / datos de salida procesados. .............. 34

Figura 16. Comparativa de datos de dispositivo final contra datos de amperímetro

de gancho.............................................................................................................. 35

Figura 17. Datos de dispositivo final en Interfaz gráfica de Grafana. .................... 36

Figura 18. Resultado de prueba de alcance. ......................................................... 38

Figura 19. Gráfica de relación de Distancia contra intensidad de señal. ............... 38

Figura 20. Gráfica de relación de Distancia contra porcentaje de éxito. ............... 39

Figura 21. Nodo sensor instalado en líneas de alimentación de motores. ............ 40

Figura 22. Motores de inducción monitoreados. .................................................... 41

Figura 23. Coordinador instalado. ......................................................................... 41

Figura 24. Panel principal en Grafana. .................................................................. 42

Figura 25. Panel individual en Grafana. ................................................................ 43

Índice de cuadros

Cuadro 1. Problemática para la implementación del mantenimiento predictivo. ..... 7

Cuadro 2. Características y funciones de dispositivos ZigBee. ............................. 18

Cuadro 3. Requerimiento funcional número 1. ...................................................... 24






Cuadro 9. Requerimiento no funcional número 1. ................................................. 26

Cuadro 10. Requerimiento no funcional número 2. ............................................... 26



Cuadro 13. Descripción de componentes. ............................................................ 30

Cuadro 14. Resultados de prueba de alcance. ..................................................... 37

Cuadro 15. Costos de reparación de motores de inducción en relación a su potencia.

.............................................................................................................................. 47

Cuadro 16. Costos de componentes de nodo sensor y coordinador. .................... 48

Cuadro 17. Relación costo-beneficio. .................................................................... 48

Siglas y abreviaturas

CBM: Condition Based Maintenance (Mantenimiento Basado en la Condición).

CPS: Cyber Physical Systems (Sistemas Ciber Físicos).

DSL: Digital Subscriber Line (Línea de Suscriptor Digital).

ETSI: European Telecommunications Standards Institute (Instituto Europeo de

Normas de Telecomunicaciones).

FFD: Full Function Device (Dispositivo de Función Completa).

GPRS: General Packet Radio Service (Servicio General de Paquetes Vía Radio).

IEEE: Institute of Electrical and Electronics Engineers (Instituto de Ingeniería

Eléctrica y Electrónica).

IIoT: Industrial Internet of Things (Internet Industrial de las Cosas).

IoT: Internet of Things (Internet de las Cosas).

LAN: Local Area Network (Red de Área Local).

LPWAN: Low Power Wide Area Network (Red de Área Amplia de Baja Potencia).

LR-WPAN: Low Rate Wireless Personal Area Network (Redes de Área Personal

Inalámbrica de Baja Velocidad).

MAC: Media Access Control (Control de Acceso al Medio).

NEMA: National Electrical Manufacturers Association (Asociación Nacional de

Fabricantes Eléctricos).

PAN: Personal Area Network (Red de Área Personal).

PHM: Prognostics and Health Management Systems (Sistemas de Diagnóstico y

Gestión de Salud de Maquinaria).

RFD: Reduced Function Device (Dispositivo de Función Reducida).

RFID: Radio Frequency Identification (Identificación por Radiofrecuencia).

RMS: Root Mean Square (Valor cuadrático medio).

RUL: Remaining Useful Life (Vida Útil Restante).

SOA: Service Oriented Architecture (Arquitectura Orientada al Servicio).

UMTS: Universal Mobile Telecommunications System (Sistema Universal de

Telecomunicaciones Móviles).

WAN: Wide Area Network (red de área amplia).

WiFi: Wireless Fidelity (Fidelidad inalámbrica).

WiMax: Worldwide Interoperability for Microwave Access (Interoperabilidad Mundial

para Acceso por Microondas).

WPAN: Wireless Personal Area Network (Redes inalámbricas de área personal).

WSN: Wireless Sensor Networks (Redes de Sensores Inalámbricos).

3G: Tercera generación de transmisión de voz y datos a través de telefonía

móvil mediante UMTS.

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

https://es.wikipedia.org/wiki/Telefonía_móvil

https://es.wikipedia.org/wiki/Telefonía_móvil

1

Introducción

Con el desarrollo de la tecnología han surgido avances que han impactado el

progreso de la humanidad en diferentes ámbitos, uno de ellos es el sector industrial

que ha pasado por varias revoluciones, desde el uso de mecanismos impulsados a

vapor, hasta lo que hoy en día conocemos como Industria 4.0 que es el actual motor

que satisface la creciente demanda de productos de calidad al optimizar la

producción, la cual integra tecnologías como el Internet de las cosas (IoT, por sus

siglas en ingles), big data, cloud computing, inteligencia artificial y sistemas ciber-

físicos [1], la implementación de estas tecnologías va de la mano con la forma en

que interactuamos con nuestro medio ambiente, teniendo en mente la

sustentabilidad para garantizar que al satisfacer nuestras demandas el impacto

ambiental sea mínimo.

Para lograr cumplir con los crecientes volúmenes de producción originados

por la demanda de productos, es necesario incrementar la disponibilidad de

maquinaria y equipos, para maximizar los tiempos disponibles de producción. Este

objetivo se puede lograr a través del mantenimiento predictivo o mantenimiento

basado en condición de maquinaria apoyado por las tecnologías que soportan a la

Industria 4.0 [2]. El mantenimiento predictivo se sirve de la adquisición de variables

físicas provenientes de maquinaria y equipos, tales como desplazamiento,

velocidad, aceleración, temperatura, sonido y corriente, entre otras, para realizar un

diagnóstico de condición de maquinaria [3]. Hoy en día es difícil imaginar una

industria que no dependa de motores por lo menos en alguno de sus procesos,

haciendo que este tipo de máquina sea de las más importantes, así que cualquier

daño impacta severamente en la producción, pero no solo la producción se vería

afectada sino que también el uso racional de la energía, ya que los motores son los

responsables de consumir el 80% de la energía eléctrica en el sector industrial,

cuando un motor sufre daño y su embobinado debe ser reparado es posible que

pierda entre el 2% y 4% de eficiencia a causa de un proceso de reparación deficiente

[4], la pérdida de eficiencia se refleja como un incremento en el consumo de

corriente por lo tanto el costo de la corriente eléctrica se verá incrementado.

2

La propuesta que aquí se describe pretende adquirir valores de variables que

se consideran importantes y hacer un monitoreo de la corriente consumida por el

motor, de esa manera se poseen datos históricos que ayudan a diagnosticar la

condición del equipo y prever un eventual mantenimiento, así mismo el monitoreo

continuo permite incrementar el tiempo de vida útil del motor para evitar someterlo

a reparaciones que resulten en perdida de eficiencia.

Aquí se hace énfasis en la importancia de los motores eléctricos, debido a la

presencia predominante dentro del sector industrial, se trata de resaltar el uso de

las tecnologías de la industria 4.0, para reforzar las debilidades del mantenimiento

predictivo cuyo enfoque se orienta a evitar daños inesperados e incrementar la vida

útil de los activos, en base al análisis de datos. Concretamente se propone el uso

de tecnologías de código abierto para el desarrollo de un sistema de monitoreo

continuo, cuyo objetivo principal es adquirir datos de los motores de inducción de

forma automática para su análisis por parte del departamento de mantenimiento

predictivo, la integración de esta propuesta en un entorno industrial permitirá la

adquisición automática de datos evitando errores humanos o demoras en la toma

de los mismos. También se proporciona información concreta sobre los elementos

de hardware y software requeridos y se describe paso a paso el proceso de

desarrollo en base a la arquitectura de IoT seleccionada a través de la revisión del

estado del arte.

El documento se organiza de la siguiente forma. En el capítulo 1 se introduce

al lector con los conceptos de mantenimiento, y con los tipos de enfoques existentes

dentro de esta área para explicar cómo la industria 4.0 puede impactar de forma

positiva. Se resalta la estrategia del mantenimiento predictivo como un enfoque

superior debido a su orientación hacia el análisis de datos. También se explican los

objetivos perseguidos por el presente proyecto, así como la metodología seguida.

El capítulo 2 proporciona el estado del arte donde se presenta la información

pertinente al desarrollo del proyecto, donde se resaltan temas relacionados a redes

de sensores inalámbricos e IoT. En el capítulo 3 se describe paso a paso el proceso

de desarrollo del prototipo, se proporciona una arquitectura de IoT y se describe los

elementos que conforman cada capa en términos de software y hardware, así como

3

su relación. También se presentan las pruebas realizadas al prototipo para validar

su funcionamiento. El capítulo 4 aborda la implementación del prototipo para el

monitoreo de 9 motores eléctricos pertenecientes a sistemas hidráulicos de

máquinas moldeadora de aluminio, y se abre camino al tema futuro que ha de

mejorar el sistema propuesto, se describen brevemente sistemas existentes para el

procesamiento de datos. Finalmente, en el capítulo 5, se muestra el impacto de la

implementación del proyecto en la industria, tanto a nivel social como económico.

Capítulo 1

Contexto

4

Capítulo 1: Contexto

1.1 Breve descripción del problema.

Si bien el propósito de este trabajo no es hablar sobre Mantenimiento Industrial, es

importante comenzar por conocer los principales enfoques sobre gestión del

mantenimiento, para entender la importancia de la aplicación de la Industria 4.0 en

el proceso de mantenimiento, específicamente de motores eléctricos.

La industria 4.0 o cuarta revolución industrial refiere a la interconexión de la

maquinaria usada en los procesos de fabricación con tecnologías propias de la era

informática, creando una sociedad colaborativa entre máquinas y sistemas para la

optimización de la cadena de producción, dando paso a una fábrica inteligente con

poca necesidad de operadores humanos [5].

1.1.1 Gestión del mantenimiento industrial.

La maquinaria industrial con el paso del tiempo y el uso periódico va perdiendo su

capacidad para realizar la función para la cual fue creada, por esta razón se requiere

del mantenimiento, que se define como las actividades necesarias para restablecer

su funcionalidad y podemos clasificarlo en 3 tipos de acuerdo a su enfoque [3,6].

1- Mantenimiento Correctivo: “Si la máquina está dañada es reparada”, si no

presenta daño no se ejecuta ninguna acción. Este es un enfoque muy simple,

sin embargo, su implementación conlleva altos costos en cuanto a conceptos

como refaccionamiento, baja producción y tiempo extra para recuperar la

producción perdida ocasionada por la falla.

2- Mantenimiento Preventivo: Este tipo de mantenimiento tiene un enfoque

orientado al tiempo de vida útil de los elementos que componen la

maquinaria, por lo que se lleva acabo de acuerdo con programas de

mantenimiento que consideran estos tiempos. Su principal problemática

5

radica en las variadas condiciones de operación de las diferentes

maquinarias, ya que es probable realizar cambios de partes que, a pesar de

haber cumplido su tiempo de vida útil, aun se encuentren en óptimas

condiciones, lo que significa haber realizado un mantenimiento innecesario.

Por otro lado, también se corre el riesgo de que se presente alguna falla

catastrófica en elementos que aún no cumplen su tiempo de vida útil.

3- Mantenimiento Predictivo: A diferencia del mantenimiento preventivo, el

mantenimiento predictivo tiene un enfoque orientado hacia la condición y está

basado en el regular monitoreo de la maquinaria, mediante el uso de pruebas

no destructivas como monitoreo de vibraciones mecánicas, monitoreo de

variables eléctricas, monitoreo de variables del proceso, termografía, entre

otras, lo que permite la toma de decisiones informadas.

La implementación del Mantenimiento predictivo permite que las actividades

correctivas solo sean realizadas en la maquinaria con mayor deterioro, lo que

optimiza los recursos empleados como tiempo, mano de obra y dinero al no comprar

refacciones innecesarias. A pesar de los beneficios adquiridos a través de una

estrategia predictiva, existen varias dificultades expuestas por [6], que se interponen

en la adopción del mantenimiento predictivo, como por ejemplo; contar con personal

capacitado en el diagnóstico predictivo, la adquisición del equipo correcto de

medición el cual tiene un costo considerable, y la correcta planeación de las rutas

de medición.

1.2 Motivación.

En la Figura 1 podemos ver una gráfica con la cantidad de actividades de

mantenimiento realizadas en una empresa fundidora, la mayoría de las actividades

se realizaron de forma programada, en respuesta a la condición de la maquinaria

obtenida gracias a la actividad de monitoreo realizada por el departamento de

mantenimiento predictivo. Es decir, se detectaron condiciones anormales en las

6

máquinas y se estableció una fecha para su corrección para evitar afectar los

volúmenes de producción de la empresa. Sin embargo, también existen actividades

resultantes de fallas emergentes, las cuales ocurrieron durante el tiempo de

operación de la maquinaria afectando la producción. Del total de fallas emergentes

el 61% corresponden a eventos relacionados con motores y las cargas acopladas a

estos, este porcentaje representó un total de 147 horas de afectación, que se

traducen en cuantiosas pérdidas monetarias. Estos datos fueron obtenidos de una

empresa fundidora del estado de Aguascalientes.

Figura 1. Gráfica de actividades programadas contra fallas emergentes.

Elaboración propia de acuerdo con datos proporcionados por empresa fundidora.

La aplicación del programa predictivo es amplia, pero es evidente que no ha

sido posible eliminar al cien por ciento las fallas emergentes que afectan seriamente

a la eficiencia productiva. En el Cuadro 1 se enlista la problemática que ha evitado

lograr la erradicación total de fallas emergentes a través de la estrategia predictiva.

102 84

174 174

4653

55 49

0

50

100

150

200

250

FY´14 FY´15 FY´16 FY´17

CA

NTI

DA

D D

E A

CTI

VID

AD

ES

AÑO FISCAL

PROGRAMADO EMERGENTE

7

Problemática Descripción

1- Seguridad laboral.

Existe maquinaria de difícil acceso, y ya que la adquisición de datos se realiza de forma manual por personal técnico, mediante el uso de instrumentos de medición. Existe un riesgo considerable de sufrir un accidente laboral y poner en juego la integridad del personal.

2- Disponibilidad de la maquinaria.

El incremento en los niveles de producción dificultan la adquisición de datos, generalmente es necesario detener la operación de la maquinaria para poder realizar la medición.

3- Frecuencia de monitoreo

Debido a la gran cantidad de maquinaria instalada, las frecuencias de monitoreo son demasiado altas, es decir, el monitoreo se realiza una vez cada dos semanas como mínimo, por lo que una falla se puede presentar en el lapso de una medición a otra. Reducir la frecuencia de monitoreo a una vez por semana o de forma diaria implicaría incremento en tiempo y cantidad de personal necesario para realizar las mediciones.

4- Cantidad de datos

Cada técnica predictiva arroja una considerable cantidad de datos a analizar, por lo que el analista debe invertir gran cantidad de tiempo en la labor de diagnóstico de maquinaria, para determinar si existe alguna falla potencial.

Cuadro 1. Problemática para la implementación del mantenimiento predictivo.

Elaboración propia de acuerdo con datos proporcionados por empresa fundidora.

Los datos obtenidos a través de la aplicación de las técnicas predictivas,

permiten observar los patrones de comportamiento de la maquinaria, e identificar

fallas potenciales. Sin embargo, la frecuencia de monitoreo es muy alta, lo que

significa que el tiempo que pasa de una medición a otra es demasiado, y esto se

debe a la cantidad de maquinaria y al tiempo necesario para la aplicación de cada

técnica predictiva. Finalmente, esto deriva en un mantenimiento predictivo poco

acertado, y con alta probabilidad de que existan fallas emergentes.

Por lo anterior, cada vez se buscan opciones que ayuden a la adquisición y

almacenamiento de datos, se desarrollan sistemas y métodos de procesamiento,

8

así como dispositivos y software de los cuales se obtienen resultados que llevan a

una toma de decisiones. En base a la información mostrada, surge la siguiente

cuestión, ¿Cómo eliminar la problemática existente para la implementación del

mantenimiento predictivo? La propuesta planteada a lo largo de este documento

muestra el uso de tecnología ZigBee para formar una Red de Sensores Inalámbricos

o Wireless Sensor Network (WSN, por sus siglas en ingles), a través de la cual se

puede realizar el monitoreo de corriente de motores de inducción a distancia de

forma permanente y autónoma, lo que resuelve la problemática antes planteada. En

cuanto a seguridad, al prescindir del personal para realizar la medición se previenen

accidentes y lesiones. También se evita que la ejecución de la medición esté sujeta

a la disponibilidad de maquinaria, ya que la instalación del sensor inalámbrico solo

se realiza una vez y es dejado de forma permanente en la máquina, esta

permanecía implica que el sensor mida de forma ininterrumpida por tanto la

disminución de la frecuencia de monitoreo ya no representa problema. Además, los

datos obtenidos son almacenados y mostrados al usuario mediante una interfaz

gráfica.

9

1.3 Objetivos.

1.3.1 Objetivo general.

Esta propuesta tiene como finalidad desarrollar un prototipo de un sistema de

monitoreo de motores utilizando plataformas de código abierto como Arduino y

Raspberry Pi, que son de gran utilidad para hacer prototipos de forma rápida y

sencilla [7]. El objetivo es mantener al usuario al tanto del consumo de corriente de

los motores para detectar comportamientos anormales en esta variable y lograr la

temprana detección de fallas incipientes.

La estructura del sistema propuesto se muestra a groso modo en la

arquitectura de la Figura 2, consta de varios nodos sensor, cada uno mide el

consumo de corriente y envía esta información de forma inalámbrica a un dispositivo

coordinador para su gestión, esto se logra gracias a la integración de la tecnología

ZigBee.

Figura 2. Arquitectura general del sistema de monitoreo.

Elaboración propia.

10

1.3.2 Objetivos específicos.

A continuación, se plantean los objetivos específicos que permitirán plantear y llevar

acabo de forma exitosa el desarrollo del sistema de monitoreo que aquí se propone.

1- Medir consumo de corriente de motores, para inferir su estado, a través de

esta variable. El incremento de corriente por encina del valor nominal

indicado, es causa potencial de daño [8], esto se detalla en el capítulo 2,

sección 2.1.

2- Instalar en los motores nodos sensor pertenecientes a una red de Sensores

Inalámbricos o Wireless Sensor Network (WSN, por sus siglas en inglés) para

formar un ecosistema de monitoreo. Si en un futuro existiera la necesidad de

incrementar la cantidad de motores a monitorear debe ser posible agregar

más nodos sensor a la WSN.

3- Enviar información recolectada por los nodos sensores a un sistema de

almacenamiento, para tener información histórica confiable del

comportamiento de los motores.

4- Desplegar la información obtenida en interfaz gráfica de usuario, donde la

información de corriente adquirida será mostrada en forma de indicadores y

gráficos de fácil interpretación para el usuario.

11

1.4 Metodología.

Se propone el uso del modelo de ciclo de vida de diseño y desarrollo de sistemas

embebidos, propuesto Noergaard [9]. Este es un modelo híbrido que se basa en 2

metodologías ampliamente usadas, el modelo espiral y cascada Figura 3. De

acuerdo con la experiencia de Noergaard los proyectos que siguieron esta

metodología concluyeron de forma exitosa [9].

Figura 3. Modelo de Ciclo de vida de diseño y desarrollo de sistemas embebidos.

Fuente: Embedded Systems Architecture A Comprehensive Guide for Engineers

and Programmers By Tammy Noergaard [9].

Capítulo 2

Estado del arte

12

Capítulo 2: Estado del arte

2.1 Incremento de consumo de corriente en motores como

síntoma de daño.

Muchos profesionistas en el área de mantenimiento están conscientes sobre el

riesgo que representa el incremento de temperatura en un motor, incluso fabricantes

de instrumentos de medición lo reafirman, como el caso de Fluke que asevera que

el 30% de daño en motores es causado por sobrecarga, tal como se muestra en la

Figura 4 y esto es acompañado de síntomas tales como consumo de corriente

excesiva, torque insuficiente y sobrecalentamiento [8,10].

Figura 4. Ilustración de motor trabajando con sobrecarga.

Fuente: Revisión de motor con sobrecarga / Fluke [10].

La regla de Montsinger, señala que “por cada 10ºC que el motor sobrepase

su valor límite de elevación de temperatura, su vida útil será reducida

aproximadamente en 50%” [11-14].

Para evitar daños inesperados y disminución de vida útil es indispensable

estar atentos a las señales que nos pueden revelar la existencia de anomalías en

13

los motores, principalmente la corriente consumida por el motor que al presentar un

incremento puede ser indicio de alguna de las problemáticas expuestas por [11].

Voltaje de alimentación inferior al especificado por el fabricante: si el voltaje

disminuye en 10% o más, existirá un peligroso incremento de corriente y

sobrecalentamiento en los devanados del motor.

Sobrecarga por Incremento de trabajo mecánico: el consumo de corriente del

motor se relaciona con el esfuerzo al que es sometido, a “mayor esfuerzo

existe mayor consumo”. El factor de servicio nos indica la capacidad que

tiene un motor de soportar sobre esfuerzo, si el motor se somete a trabajos

en donde se le exija mayor trabajo mecánico, la corriente consumida

sobrepasará la corriente nominal especificada por el fabricante y se

considerará que está trabajando con sobrecarga incrementado la

temperatura en sus devanados causando deterioro irreversible.

Rodamientos con deterioro: un rodamiento con deterioró gira con

sobreesfuerzo debido al incremento de fricción, eventualmente existirá un

atoramiento que impedirá el giro del rotor “rotor trancado”. El incremento de

fricción incrementa la corriente y al llegar a la etapa de atoramiento se

presenta la “corriente a rotor trancado” que supera 6 veces la corriente

nominal dañando por completo el motor.

2.2 Mantenimiento 4.0 aplicado al mantenimiento predictivo.

El mantenimiento predictivo tiene un enfoque orientado por la condición de

maquinaria y depende de la información que tradicionalmente es recolectada de

forma semiautomatizada o manual haciendo uso de gran variedad de instrumentos

de medición. Cuando la recolección es semiautomática la información obtenida con

los instrumentos se registra automáticamente en una base de datos pero debe ser

transferida de forma manual del instrumento al sistema, cuando la recolección es

manual la información se inserta a la base de datos de forma manual por un

trabajador. Por otro lado, la recolección es automática si la información se adquiere

y almacena en la base de datos sin la intervención de ningún trabajador [15]. Para

14

lograr la recolección automática que ha de optimizar la implementación del

mantenimiento predictivo se debe echar mano de las tecnologías propias de la

Industria 4.0, para alcanzar el Mantenimiento 4.0.

La industria 4.0 permite expandir el mundo físico de las máquinas hacia los

sistemas computacionales y convertirlas en organismos ubicuos que crean una

sociedad colaborativa entre máquinas que es posible monitorear al instalar en ellas

sensores [16,17]. Los datos obtenidos gracias a los sensores sirven al

mantenimiento predictivo para realizar el diagnóstico de condición correspondiente

a cada motor que forme parte de esta sociedad de máquinas.

2.3 Red de Sensores Inalámbricos para recolección de datos.

Una Red de Sensores Inalámbricos (WSN, por sus siglas en inglés) está compuesta

por varios nodos sensor que miden continuamente una variable física proveniente

del entorno en donde se encuentran, a través de la WSN se pueden recolectar

remotamente datos gracias a que cada nodo sensor cuenta con tecnología

inalámbrica que los habilita para comunicarse dentro de la WSN. Cada nodo sensor

tiene un procesador para realizar cálculos sencillos, sin embargo, son dispositivos

con limitaciones energéticas, de procesamiento y de memoria, así que la

información que colectan debe ser enviada a un dispositivo central que realice todo

el procesamiento necesario [18,19].

Para la formación de una WSN es necesario seleccionar el protocolo bajo el

cual funcionará. Actualmente se cuentan con una gran diversidad de protocolos que

permiten formar WSN, la importancia de los protocolos radica en que son los

encargados de definir el conjunto de reglas o normas que el transmisor y receptor

seguirán para poder establecer una comunicación entre ellos e intercambiar

información [20], en pocas palabras un protocolo establece el lenguaje en que la

WSN se comunicará. Los protocolos se pueden clasificar de acuerdo a su cobertura

Figura 5, ya que pueden alcanzar desde algunos centímetros hasta varios

kilómetros [18,21-23].

15

Figura 5. Protocolos para Redes de Sensores Inalámbricos.

Fuente: Wireless Sensor Network Prototype to Monitor the Condition of Holding

Furnaces in the Aluminum Casting Plant [23].

Existen características que se deben considerar al momento de implementar

una WSN [19] [24] ya que dé no hacerlo podría no satisfacer la aplicación y ver

limitado su desempeño.

Batería de larga duración: La mayoría de los nodos sensor dependen de una

batería como fuente de alimentación, de aquí la importancia de que tengan

un consumo eficiente que permita alargar la vida de la batería lo más posible.

Amplia cobertura a bajo costo: Una WSN está compuesta de una gran

cantidad de nodos sensores, convirtiendo el costo por nodo una

característica crítica, para poder implementar una red de gran tamaño, que

cubra un área considerable.

Rango de cobertura: Como se mencionó anteriormente las WSN pueden

abarcar áreas de pocos centímetros a varios kilómetros, Por lo que hay que

tener en consideración la aplicación y el entorno en donde será desplegada.

16

2.4 Estándar ZigBee.

ZigBee es un estándar para Redes de Área Personal Inalámbrica de Baja Velocidad

(LR-WPAN, por sus siglas en ingles), opera en las bandas libres de 2.4Ghz, 858Mhz

para Europa y 915Mhz para Estados Unidos. Ofrece características como:

transferencia de datos, bajo costo, bajo consumo de energía y soporte para

diferentes topologías, apropiadas para desarrollar aplicaciones dentro de la

industria. ZigBee está basado en el protocolo IEEE 802.15.4 el cual define las

características de la capa Física (PHY, por sus siglas en inglés) y la capa de Control

de Acceso al Medio (MAC, por sus siglas en inglés) para Redes LR-WPAN. De

acuerdo a la pila de protocolos para ZigBee Figura 6, sobre el protocolo IEEE

802.15.4 se encuentra la capa de red (NWK, por sus siglas en inglés) que se

encarga de organizar y proporcionar el enrutamiento. La capa superior se subdivide

en: Subcapa de Aplicación (APS, por sus siglas en inglés), capa de Dispositivos

ZigBee (ZDO, por sus siglas en inglés) y el Marco de Aplicación compuesto por

Objetos de Aplicación (APO, por sus siglas en inglés) que son objetos definidos por

el usuario y que forman parte de una aplicación ZigBee [25-27].

Figura 6. Pila de protocolos para ZigBee.

Fuente: Wireless sensor networks: A survey on the state of the art and the

802.15.4 and ZigBee standards [27].

17

ZigBee reconoce tres tipos diferentes de dispositivos. 1) Dispositivo final

ZigBee que corresponde a un Dispositivo de Función Reducida (RFD, por sus siglas

en ingles), tiene capacidades limitadas de procesamiento, recopila información de

sensores o interruptores. 2) Enrutador ZigBee es capaz de enrutar los datos desde

su origen hasta su destino. 3) Coordinador ZigBee que sirve como administrador de

la red, configura todos los parámetros de la red y puede funcionar como Gateway

es decir es la puerta de acceso para que el mundo exterior interactúe con la red.

Estos dos últimos son Dispositivos de Función Completa (FFD, por sus siglas en

ingles). Las características de cada uno son mostradas en el Cuadro 2, donde

también se habla de las funciones que ejecuta cada tipo de dispositivo y muestra

cómo se diferencian los tres tipos.

18

Tipo de

dispositivo Características

Dispositivo final

Debe unirse a una PAN ZigBee antes de poder transmitir o

recibir datos.

No puede permitir que otros dispositivos se unan a la red.

Siempre debe transmitir y recibir datos a través de su nodo

padre.

No puede enrutar datos.

Puede ingresar a lo modo de bajo consumo para conservar

energía y puede ser alimentado por batería.

Enrutador

Debe unirse a una PAN ZigBee antes de poder transmitir,

recibir o enrutar datos.

Después de unirse, puede permitir que los enrutadores y

dispositivos finales se unan a la red.

Después de unirse, puede ayudar en el enrutamiento de

datos.

No puede dormir, debe ser alimentado por la red eléctrica.

Puede almacenar paquetes de datos para sus nodos hijo

que se encuentren en suspensión.

Coordinador

Selecciona un canal y PAN ID (tanto de 64 bits como de 16

bits) para iniciar la red.

Permite que los enrutadores y dispositivos finales se unan

a la red.

Puede ayudar en el enrutamiento de datos.

No puede dormir, debe ser alimentado por la red eléctrica.

Puede almacenar paquetes de datos para sus nodos hijo

que se encuentren en suspensión.

Cuadro 2. Características y funciones de dispositivos ZigBee.

Fuente: XBee/XBee-PRO Zigbee RF Modules User Guide [29].

19

En las redes ZigBee el coordinador es el encargado de iniciar la red, como

se menciona en la tabla anterior para tal propósito selecciona un identificador único

para la Red de Área Personal (ID PAN), posterior a esto se comporta como

enrutador. Tanto coordinador como enrutadores permiten que otros dispositivos se

unan a la red por lo que se convierten en padres de estos dispositivos. Otra de las

tareas importantes que realiza el Coordinador es definir la topología bajo la cual se

formará la red [27-29]. Las topologías admitidas se ilustran en la Figura 7.

Figura 7. Topologías para redes ZigBee.

Fuente: Wireless sensor networks: A survey on the state of the art and the

802.15.4 and ZigBee standards [27].

Topología de estrella: El coordinador es la figura central de esta topología,

los dispositivos finales únicamente se pueden comunicar con él y no con

otros de su tipo.

Topología de árbol: El coordinador actúa como nodo raíz, tanto coordinador

como enrutadores se convierten en padres de los dispositivos finales que

estén conectados a ellos. La comunicación entre dispositivos finales solo

puede ocurrir a través de sus padres, por lo que, si alguno de los padres se

deshabilita, sus hijos no podrán comunicarse con otros dispositivos de la red.

Topología de malla: Este tipo de red puede cubrir áreas muy amplias ya que,

si un dispositivo se encuentra fuera del rango de alcance, la información es

enviada a un dispositivo vecino que se encargará de reenviar la información

20

hacia su destino, si existe alguna falla en una ruta se pueden buscar rutas

alternas para transmitir la información.

Gracias a esta variedad de topologías se puede obtener una red conformada

por cientos de dispositivos, una red ZigBee puede tener hasta 254 nodos, no

obstante, es posible crear hasta 255 conjuntos con lo que se puede extender hasta

tener 64770 dispositivo según la agrupación que se haga [25].

2.5 Arquitectura para IoT.

Las WSN comprenden una parte importante de las tecnologías necesarias para

desarrollar aplicaciones dentro del contexto del internet de las cosas. Enfocar el

internet de las cosas hacia el monitoreo continuo de maquinaria requiere de una

arquitectura que nos provea de un marco de referencia para su aplicación, es decir

una guía para facilitar su desarrollo y que nos proporcione las características

necesarias para su implementación [30]. Las arquitecturas mostradas por [31,32]

muestran una estructura general para IoT que es posible usar en cualquier tipo de

dominio, ambas arquitecturas muestran tres capas en su estructura Figura 8.

a. Capa de percepción: la principal tarea de esta capa es recolectar la

información del entorno y proveer un primer procesamiento, se compone de

dos elementos: sensores de diferentes tipos como de temperatura, humedad,

presión y corriente, por mencionar algunos. Y la WSN que es la red

inalámbrica conformada por varios nodos sensor distribuidos en el área de

interés. En esta capa se debe cumplir con las características siguientes: baja

potencia, miniaturización y bajo costo.

b. Capa de red o transmisión: procesa la información proveniente de todos los

nodos sensor de la WSN de la capa de percepción y le da paso a la capa de

aplicación, ya que transmite la información a un destino remoto a través del

uso de tecnologías para la comunicación e internet.

21

c. Capa de aplicación: en esta capa se proporcionan servicios a los usuarios al

presentarles la información procesada, el servicio se desarrolla dependiendo

del tipo de sector al que va dirigida nuestra aplicación de IoT.

Figura 8. Arquitectura general para IoT.

Fuente: IOT Gateway: Bridging Wireless Sensor Networks into Internet of Things

[32].

La arquitectura presentada por [32] centra su atención a la capa intermedia,

al resaltar la importancia del dispositivo de red conocido como IoT Gateway que

funciona como puente entre la capa de percepción y la capa de aplicación. La WSN

está limitada en cuanto a área de cobertura, pero gracias a la IoT Gateway los datos

pueden ser transmitidos a larga distancia al conectar la WSN con las redes de

comunicación tradicionales como internet que se basa en el protocolo TCP / IP.

Las single-board computers o computadoras de placa única (SBCs, por sus

siglas en inglés) se presentan como una solución para la implementación de IoT e

IIoT, por sus características es posible usarlas como Gateway. El articulo

presentado por [33] consiste en un análisis de algunas de las SBCs disponibles, uno

de los dispositivos que sobresalen por sus características es la plataforma

Raspberry Pi, el modelo B+ cuenta con procesador de cuatro núcleos a 1.4 GHz de

64 bits, LAN inalámbrica de doble banda, Bluetooth 4.2 / BLE, Ethernet más rápido,

22

y soporte para ser alimentado a través de Ethernet (PoE, por sus siglas en ingles).

Gracias a la popularidad de Raspberry Pi existen desarrollos para IoT que hacen

uso de esta plataforma, tal es el caso del mostrado por [34] que presenta un sistema

prototipo para una aplicación de monitoreo ambiental, debido a que el sistema está

construido sobre plataformas de código abierto es de bajo costo y fácil de

implementar. La Figura 9 es la arquitectura usada para su desarrollo, como se

observa incluye las 3 capas de la arquitectura general para IoT previamente

mostrada. La capa central la conforma una Raspberry Pi denominada “Estación

Base”, la cual funciona como Gateway y a su vez como servidor de base de datos

y servidor web.

Figura 9. Arquitectura para aplicación de monitoreo ambiental.

Fuente: Wireless Sensor Network System Design using Raspberry Pi and Arduino

for Environmental Monitoring Applications [34].

Capítulo 3

Desarrollo del proyecto

23

Capítulo 3: Desarrollo del proyecto

Como se ha manifestado el mantenimiento predictivo requiere de datos para realizar

un diagnóstico de la salud de la maquinaria, y al hacer uso de una WSN podemos

obtenerlos de forma automática. En el presente capítulo se muestra el desarrollo e

implementación del sistema para monitoreo de motores de inducción, que está

basado en la arquitectura general de 3 capas para aplicaciones de IoT. A

continuación, se presenta el desarrollo de acuerdo con las fases establecidas en la

metodología seleccionada en el Capítulo 1, sección 1.4.

3.1 Creación de la arquitectura.

Etapa de planeación y de diseño de la arquitectura, cuya actividad principal es

establecer los requerimientos, los cuales se definieron a través de un focus group

con 2 expertos en mantenimiento predictivo quienes integran el área de

mantenimiento de una empresa manufacturera del estado de Aguascalientes.

Ambos cuentan con certificaciones en el área de pruebas no destructivas para la

aplicación del mantenimiento predictivo.

3.1.1 Especificación de requerimientos.

Mediante el focus group se trataron temas sobre los instrumentos que se utilizan

para llevar acabo la inspección de maquinaria y equipos, también las dificultades

que se experimentan en la práctica. De lo anterior surgen los requerimientos

funcionales y no funcionales, que son base para el desarrollo del sistema de

monitoreo.

24

3.1.2 Requerimientos funcionales.

La redacción de los requerimientos funcionales se usa para plasmar la descripción

de las funcionalidades y servicios que el sistema debe tener de acuerdo a las

necesidades que manifestaron los usuarios, Cuadros 3-8.

Identificación del requerimiento:

RF01

Nombre del Requerimiento:

Adquisición de datos.

Características: El prototipo debe adquirir la variable de corriente eléctrica proveniente del motor en donde sea instalado dicho dispositivo.

Descripción del requerimiento:

El rango de medición del dispositivo debe estar entre 0 y 100 A.

Cuadro 3. Requerimiento funcional número 1.



RF02


Comunicación.

Características: El prototipo debe ser un nodo sensor, perteneciente a una red de sensores inalámbricos.


El rango de transmisión debe soportar mínimo 100 metros (deseable 1 km).




RF03


Alertas.

Características: El prototipo debe avisar al usuario, cuando la variable monitoreada sobrepase los valores de control establecidos.


El sistema permitirá al usuario establecer el valor límite de la variable monitoreada para saber si ha sido sobrepasado.



25


RF04


Almacenamiento.

Características: Se debe contar con sistema de almacenamiento de la información obtenida de los nodos sensores.


La información debe estar almacenada en una base de datos.




RF05


Interfaz de usuario.

Características: El sistema contará con interfaz de usuario, donde se podrán interactuar con los datos obtenidos por los diferentes dispositivos de adquisición.


Muestra a los usuarios información de los dispositivos de adquisición, cuenta con gráficas de tendencia, así como con indicadores para visualizar los datos obtenidos.




RF06


Consulta.

Características: Consultas de la información almacenada.


El usuario podrá seleccionar el rango de fechas en los que desea consultar la información.



3.1.3 Requerimientos no funcionales.

Este tipo de requerimientos delimitan el sistema, no hacen referencia a las

funcionalidades ya que no se relacionan directamente con los servicios que el

sistema ofrece. Más bien surgen de la necesidad del usuario debido a restricciones

presupuestales, políticas de la organización, necesidad de interoperabilidad con

26

otro software o hardware, entre otros aspectos no relacionados al funcionamiento,

Cuadros 9-12.


RNF01


Carcasa.

Características: El nodo sensor debe contar con carcasa.


La carcasa del nodo sensor debe proteger al prototipo contra polvo y suciedad, para poder ser instalado dentro de un tablero eléctrico.

Cuadro 9. Requerimiento no funcional número 1.



RNF02


Vida útil del nodo sensor.

Características: El nodo sensor debe tener un funcionamiento continuo.


El nodo sensor debe enviar información 24 horas al día los 365 días del año, en caso de daño debe ser reemplazado fácilmente.




RNF03


Manual de usuario.

Características: Instructivo para uso del prototipo.


Se debe hacer entrega de manual para ayudar al usuario con el manejo del prototipo.




RF04


Reportes.

Características: Generación de reportes de la información consultada.


Se podrán exportar los datos consultados en formato de Excel o CSV.



27

3.1.4 Arquitecturas desarrolladas.

La arquitectura de la Figura 10 muestra los elementos que conforman el sistema de

monitoreo y está basada en la arquitectura general de 3 capas para aplicaciones de

IoT. La tecnología inalámbrica ZigBee combinada con la plataforma de código

abierto Arduino ha de usarse para construir la capa de percepción, mientras que la

SBC Raspberry Pi funcionará como Gateway para construir la capa de transmisión,

de igual forma servirá como base para la capa de aplicación ya que tendrá

almacenada la base de datos y la interfaz de usuario. Como la plataforma Raspberry

Pi estará conectada a la red de área local de la empresa los usuarios pueden

visualizar los datos recopilados por la WSN e interactuar con ellos desde cualquier

equipo de cómputo.

Figura 10. Arquitectura de sistema de monitoreo de motores.


El sistema propuesto tiene dos elementos de hardware, el nodo sensor y la

Gateway Figura 11. El nodo sensor es el encargado de medir la corriente eléctrica,

realiza el procesamiento que convierte el voltaje generado por el transformados de

corriente a un valor de intensidad eléctrica que corresponde a la corriente eléctrica

consumida por el motor, el dato procesado es enviado de forma inalámbrica a la

Gateway que identifica de donde proviene y lo almacena en la base de datos que

28

es de donde la interfaz gráfica obtiene la información que mostrara al usuario.

Ambos elementos integran la tecnología XBee de la marca DIGI, para construir la

WSN bajo el protocolo ZigBee.

Figura 11. Arquitectura de Nodo sensor y Gateway.


3.2 Implementación de la arquitectura.

A lo largo de esta sección se muestra como se integran los elementos de hardware

y software que conforman las arquitecturas mostradas, se describe cómo contribuye

cada elemento en la construcción del prototipo, ya que individualmente cada

elemento es capaz de ejecutar una tarea que al trabajar conjuntamente con los

demás elementos logran cumplir la funcionalidad plasmada en los requerimientos.

3.2.1 Descripción de Hardware.

En esta etapa se desarrolla el prototipo, haciendo uso de herramientas open source

para la implementación de la Gateway y los nodos sensores. En el Cuadro 13 se

hace una breve descripción de los componentes de hardware empleados.

29

NO COMPONENTE IMAGEN DESCRIPCIÓN

1 Xbee Pro S2B

Módulo de la marca DIGI, diseñado para comunicarse bajo el protocolo ZigBee, la variante Pro ofrece expandir el rango de alcance, la serie 2B puede alcanzar hasta 90 m en interiores y hasta 3200m en línea de vista. Posee una potencia de transmisión de 63mW (+18 dBm) y una sensibilidad de recepción de -102 dBm. Y cuenta con conector RPSMA para la antena.

2 XBee Explorer

Dongle

Adaptador que permite conectar el módulo Xbee directamente a la SBC, mediante los puertos USB. Cuenta con regulador de voltaje para alimentar al módulo.

3 XBee Shield para Arduino

Shield que permite a la placa de desarrollo Arduino comunicarse fácilmente con los módulos XBee, también cuenta con regulador de voltaje para alimentar al módulo.

4 Arduino Uno

Placa de desarrollo open source con microcontrolador ATmega328P integrado. Características:

Voltaje de operación: 5 V.

Voltaje de entrada (recomendado): 7-12 V.

14 Pines de entrada/salida digital, 6 pueden generar PWM.

6 Pines de entrada analógica.

5 Raspberry Pi

2B Plus

Es una pequeña computadora SBC, por sus siglas en ingles Single Board Computer. Cuenta con un SOC Broadcom BCM2836, un procesador ARM Cortex A7 de cuatro núcleos a 900 MHz y 1Gb de SDRAM. Cuenta con:

100 Base Ethernet.

4 puertos USB.

40 pines GPIO.

Puerto Full HDMI.

https://www.mcielectronics.cl/shop/product/atmega328p-with-arduino-optiboot-uno-10683

30

Entrada para Micro SD card.

VideoCore IV 3D graphics core.

6 Transformador de corriente

Transformador de corriente de núcleo partido, Modelo CCT50-102, marca Dwyer. Puede medir en 3 rangos 100/150/200 A, con salida de 0-5 V. Usa el campo magnético del conductor para determinar la corriente que pasa a través de él.

Cuadro 13. Descripción de componentes.


3.2.2 Configuración de red de sensores inalámbricos XBee.

El primer paso por seguir es configurar la red de sensores inalámbricos a través del

software X-CTU distribuido de forma gratuita por DIGI [35], que permite la

interacción con los módulos ZigBee a través de una interfaz gráfica Figura 12.

Figura 12. Software XCTU.

Fuente: DIGI.com [35].

31

Para formar una WSN de tipo estrella, se requiere configurar dos clases de

dispositivos, un Coordinador único en cada WSN y uno o varios dispositivos finales.

Los parámetros de red incluyen al Identificador de Red de Área Personal (PAN ID,

por sus siglas en ingles) y el canal de operación, por defecto los dispositivos XBee

manejan la selección de canal automáticamente, estos dos parámetros deben ser

los mismos en ambos tipos de dispositivos, de lo contrario no podrán comunicarse

por no pertenecer a la misma red. También se deben configurar los parámetros de

direccionamiento en cada dispositivo final, la dirección de destino indica a cada uno

la dirección del dispositivo Coordinador a donde hay que enviar los datos

recolectados [36].

3.2.3 Construcción del prototipo.

En esta sección se presenta la construcción del prototipo, se muestra el desarrollo

capa por capa y se explican brevemente sus componentes.

Capa 1: Los elementos que componen la capa 1 son los dispositivos finales

que están conformados por 3 transformadores de corriente, un Arduino, un XBee

Shield y por supuesto un módulo XBee Pro S2B previamente configurado, en esta

capa también se encuentra el dispositivo Coordinador. Arduino uno posee un

microcontrolador ATmega328P con un Convertido Analógico Digital (ADC, por sus

siglas en ingles) de 6 canales con resolución de 10 bits entregando valores enteros

de 0 a 1023 [37]. Arduino realiza la adquisición de datos desde el transformador de

corriente el cual entrega una salida de voltaje de 0 a 5 VCD. El código de Arduino

Anexo 1, realiza la lectura del sensor y el procesamiento para convertir la lectura a

valor de corriente RMS. El cálculo de la corriente RMS se realiza aplicando la

Formula (1).

𝑖𝑟𝑚𝑠 = √1

𝑁∑ 𝑖𝑁

2𝑁𝑁=0 (1)

https://www.mcielectronics.cl/shop/product/atmega328p-with-arduino-optiboot-uno-10683

32

Dónde:

N = Número de muestras

i = Lectura de corriente

El módulo Xbee Pro S2B configurado como Coordinador también conforma

la capa de percepción, recibe la información de cada dispositivo final. La estructura

de datos que transfieren los dispositivos XBee se conoce como trama API Figura 13

y se conforma de la siguiente manera [36].

Start Delimiter: Es el primer Byte e indica el inicio de la trama API su valor

siempre es 0x7E.

Length: Indica el número de Bytes del Frame Data, no se toman en cuentas

los Bytes del Start Delimiter, Length y Checksum.

Frame Data: Contiene la información de la trama, incluye el tipo de trama que

se está enviando, la dirección del origen de la trama y los datos recolectados

por el dispositivo final.

Checksum: El último byte de la trama es la suma de comprobación que sirve

para corroborar la integridad de los datos y se calcula sumando todos los

bytes de la trama API, excluyendo los Bytes del Start Delimiter y Length.

Figura 13. Estructura de trama API.

Fuente

: XCTU Configuration and Test Utility Software User Guide [36].

Capa 2: El dispositivo Coordinador se conecta a un puerto USB de la

Raspberry con el dispositivo XBee Explorer Dongle, hasta este punto el Coordinador

únicamente recibe las tramas API de cada dispositivo final, pero esto no es

suficiente, es necesario identificar su origen, así como la fecha y hora en que se

generó. Para tal propósito se hace uso de Node-RED, “que es una herramienta de

33

programación basada en flujo, desarrollada originalmente por el equipo de Servicios

de Tecnología Emergente de IBM y ahora parte de la Fundación JS” [37]. Para

ingresar al editor de flujo donde se realiza la programación, Node-RED apunta a un

navegador web. A través de la interconexión de nodos que ejecutan diferentes

funcionalidades se puede conectar dispositivos de hardware a servicios. Las tramas

API que llegan a la Raspberry son procesados mediante Node-RED con el flujo

mostrado en la Figura 14.

Figura 14. Flujo desarrollado en Node-RED.


El primer nodo configura el puerto serial de Raspberry Pi para leer los datos

que llegan al Coordinador, el segundo extrae la información de interés como el

origen y los datos de la medición de corriente, El tercero confirma que no existan

errores en la información y posteriormente le da formato para ingresarla a la base

de datos, finalmente en el cuarto nodo se configura la conexión con la base de datos

para poder direccionar los datos procesados. La Figura 15 muestra la forma de los

datos de entrada y de salida.

34

Figura 15. Datos de entrada sin procesar / datos de salida procesados.


Capa 3: Esta capa refiere al almacenamiento y proporciona acceso a los

usuarios a la interfaz gráfica, para tal propósito se hace uso de InfluxDB y Grafana,

ambas plataformas de código abierto y compatibles con Raspberry Pi.

En primer lugar, InfluxDB proporciona almacenamiento, es una base de datos

de series temporales. “Puede manejar millones de puntos de datos por segundo.

Trabajar con esa cantidad de datos durante un período prolongado puede generar

problemas de almacenamiento. InfluxDB compacta automáticamente los datos para

minimizar su espacio de almacenamiento” [39]. Por otro lado, Grafana interactúa

con InfluxDB para presentar al usuario los datos de forma gráfica. Se presenta como

una “solución para análisis y monitoreo que permite consultar, visualizar, y

comprender métricas sin importar dónde estén almacenadas” [40]. Raspberry Pi

también funciona como servidor y almacena a Grafana. Para acceder a los tableros

35

de visualización (DashBoards) a través de cualquier otro computador conectado a

la LAN se debe abrir un navegador y poner la IP del servidor en el puerto 3000.

3.3 Prueba del sistema.

El sistema se probó midiendo el consumo de corriente de un motor marca SIEMENS

de 15 kW, controlado por un Variador de Frecuencia PowerFlex de la serie 750, los

datos obtenidos por el dispositivo final se compararon con los obtenidos de forma

manual haciendo uso de un amperímetro de gancho. En las gráficas de la Figura 16

se muestran los resultados obtenidos. La interfaz gráfica generada por Grafana se

muestra en la Figura 17.

Figura 16. Comparativa de datos de dispositivo final contra datos de amperímetro

de gancho.


36

Figura 17. Datos de dispositivo final en Interfaz gráfica de Grafana.


También se ejecutó una prueba de alcance, para ver la calidad de la señal

inalámbrica, debido a que los dispositivos que conforman la WSN se tienen que

instalar en una nave industrial y pueden existir problemas de línea de vista,

ocasionados por las estructuras y maquinas instaladas a su alrededor. XCTU envía

paquetes de datos desde el módulo XBee local (Coordinador) al módulo remoto

(Dispositivo final) y espera a que el eco regrese del módulo remoto al módulo local.

XCTU cuenta el número de paquetes enviados y recibidos por el módulo local y

mide la intensidad de la señal de ambos lados como un valor RSSI (Indicador de

intensidad de señal recibida). Cada paquete enviado desde el XBee local debe ser

recibido nuevamente como un eco por el mismo XBee local [36]. Se coloca un

dispositivo final dentro de un tablero eléctrico y se ejecutan varias pruebas enviando

100 paquetes, colocando a diferentes distancias el dispositivo Coordinador. Los

resultados se plasman en el Cuadro 14.

37

Distancia

en

metros

RSSI

local

dBm

RSSI

remoto

dBm

Paquetes

enviados Errores

Paquetes

perdidos

Paquetes

recibidos

% de

éxito

0.5 -34 -34 100 0 0 100 100

10 -65 -64 100 0 1 99 99

20 -63 -61 100 2 5 93 93

30 -69 -70 100 12 1 87 87

40 -68 -69 100 16 1 83 83

50 -81 -84 100 12 4 84 84

60 -87 -87 100 17 5 78 78

Cuadro 14. Resultados de prueba de alcance.


XCTU muestra los resultados de la prueba de alcance como en la Figura 18,

Los valores de RSSI del dispositivo local y remoto se representan de forma gráfica,

así como el porcentaje de éxito, la gráfica corresponde al total de paquetes

enviados. En la parte inferior se muestra el valor instantáneo de RSSI del dispositivo

local y remoto. En la esquina inferior derecha se presenta el resumen de la prueba,

se muestra el número total de paquetes enviados, recibidos, errores de transmisión

y paquetes perdidos. También se muestra el porcentaje de éxito de la prueba. La

gráfica de la Figura 19 ilustra la relación entre Distancia e intensidad de señal tanto

del módulo local y remoto, observando como disminuye a medida que la distancia

aumenta, debido a la disminución de RSSI el porcentaje de éxito también se ve

disminuido Figura 20, Pese a la disminución de la intensidad de la señal, a 50 metros

aún se cuenta con más de 80% de éxito en la transmisión.

38

Figura 18. Resultado de prueba de alcance.

Fuente: Herramienta proporcionada por Software XCTU

Figura 19. Gráfica de relación de Distancia contra intensidad de señal.


39

Figura 20. Gráfica de relación de Distancia contra porcentaje de éxito.

Elaboración propia

La finalidad de esta prueba fue determinar el área óptima en donde colocar

los dispositivos finales dentro de la nave industrial, para garantizar que no existan

pérdidas significativas de información. A 20 metros de distancia del Coordinador, el

porcentaje de éxito fue del 93%, con 5 errores de transmisión y 2 paquetes perdidos,

aun a 30 metros el porcentaje de éxito fue superior a 85%, por lo que se concluye

que una distancia óptima para colocar los dispositivos finales no debe superar los

30 metros para garantizar que la perdida de datos sea la mínima posible. De

acuerdo a la distribución de las máquinas en la presente aplicación esta distancia

es aceptable.

Capítulo 4

Instalación del prototipo en la

industria y trabajo futuro

40

Capítulo 4: Instalación del prototipo en la industria y

trabajo futuro

Una vez validado el funcionamiento del sistema con un solo sensor de corriente se

procede a realizar la selección de la maquinaria piloto, en donde se va a instalar el

prototipo final para evaluar su funcionamiento en un ambiente industrial.

4.1 Instalación de prototipo en motores de sistema hidráulico.

Se instalan tres nodos sensor con tres transformadores de corriente de núcleo

partido cada uno, en tres máquinas moldeadoras de aluminio Figura 21, cada

máquina está compuesta por tres motores de inducción, dos de 37kW y uno de 45

kW Figura 22, se monitorea una línea de alimentación por cada uno de los nueve

motores. Los motores se encuentran acoplados a bombas de paletas que son

elementos mecánicos cuya función es generar flujo y presión en el sistema

hidráulico de la máquina para poder realizar el trabajo.

Figura 21. Nodo sensor instalado en líneas de alimentación de motores.


41

Figura 22. Motores de inducción monitoreados.


Por otro lado, el coordinador se instala en un punto central entre las tres

máquinas teniendo cuidado de no sobrepasar los 20 metros de distancia, para

disminuir el riesgo de pérdida de datos por falta de comunicación entre los nodos

sensores y el coordinador Figura 23.

Figura 23. Coordinador instalado.


42

A continuación, se muestran los Dashboards generados en Grafana donde

los usuarios conectados a la red de la empresa pueden visualizar los datos, para tal

propósito deben ingresar en un navegador Web la IP fija asignada a la Raspberry

seguida del número de puerto 3000, quedando de la siguiente forma

10.92.34.12:3000. El dato actual de los nueve motores monitoreados se puede

apreciar en el panel principal Figura 24. Mientras que las gráficas con los datos

históricos se pueden ver en los paneles individuales creados para cada máquina

Figura 25, en estos paneles se puede tener acceso a la información por fechas para

poder ver información de días pasados.

Figura 24. Panel principal en Grafana.


43

Figura 25. Panel individual en Grafana.


4.2 Trabajo futuro.

Dada la recolección automática de datos lograda a través de la propuesta planteada

a lo largo de este documento, se presenta otra problemática resultante de la gran

cantidad de datos generados. Un dispositivo final se encuentra adquiriendo

información cada 10 segundos por lo tanto en una hora se generan 1080 datos por

los 3 motores, que se traduce a 25920 datos a evaluar por cada máquina en un día.

Si tomamos en cuenta que el estándar ZigBee puede soportar decenas de

dispositivos finales como se manifiesta en el Capítulo 2, sección 2.4, una WSN con

más de 3 dispositivos finales supone miles de datos generados diariamente. Si bien

contar con una persona que se encuentre observándolos de forma permanente en

busca de variaciones de corriente que puedan revelar algún tipo de problema, suena

factible para una WSN pequeña, esto supone una tarea titánica de análisis a realizar

si nuestra WSN cuenta con más dispositivos finales. Esta gran cantidad de datos

44

generados nos coloca dentro de la definición de “big data” que posee propiedades

como volumen, velocidad, variedad, variabilidad, valor y complejidad, derivando en

nuevos retos y desafíos [41]. En consecuencia, son necesaria herramientas

analíticas que nos ayuden a extraer valor de los datos.

Podemos diferenciar dos tipos de sistemas que nos permiten procesar los

datos obtenidos, Los Sistemas de Diagnóstico y Gestión de Salud de Maquinaria o

Prognostics and Health Management Systems (PHM, por sus siglas en inglés) y los

sistemas de máquinas auto-conscientes y auto-mantenidas o “self-aware and self-

maintained machine systems”. El objetivo que persiguen los sistemas PHM es

predecir la vida útil restante de la maquinaria (RUL, por sus siglas en ingles), existen

dos enfoques para su cálculo, los métodos basados en modelos físicos, que

describen el proceso de degradación de la maquinaria en base a modelos físicos

relacionados con las propiedades de los materiales, estos modelos generalmente

se generan mediante experimentos o análisis de elemento finito entre otras técnicas.

El otro enfoque corresponde a los métodos basados en datos que intentan aprender

de la información obtenida de las máquinas para elaborar un pronóstico en base a

regresión lineal y no lineal, modelos autor regresivos de media móvil (ARMA, por

sus siglas en ingles), redes neuronales artificiales, sistema de lógica difusa, etcétera

[42,43]. Por otro lado, los sistemas de máquinas autoconscientes y auto mantenidas

pretenden dotar de autonomía a las máquinas para que por sí mismas evalúen su

nivel de salud y reaccionen en consecuencia. Al igual que los sistemas PHM se

valen de los métodos basados en datos para realiza su auto diagnosis, más aún son

capaces de retroalimentar esta información al sistema de control para realizar

adaptaciones, también pueden informar de su condición a las personas

responsables de su mantenimiento para que programen acciones correctivas

oportunamente [44].

Por el momento el sistema propuesto carece de análisis de datos, pero en un

futuro trabajo es posible enriquecer el desarrollo al agregar algoritmos que nos

permitan alcanzar la funcionalidad de un sistema PHM, que posteriormente puede

evolucionar a un sistema de máquinas autoconscientes y auto mantenidas.

Capítulo 5

Impacto social y económico

45

Capítulo 5: Impacto social y económico

5.1 Impacto social.

Los instrumentos de medición necesarios para la aplicación del mantenimiento

predictivo tienen un alto costo llegando a representar una fuerte suma de inversión,

alrededor de miles de dólares [6]. Por lo que este tipo de mantenimiento solo es

accesible para las grandes industrias con el capital necesario para hacer una

inversión de este tipo. Este proyecto al ser desarrollado en plataformas open source

es de bajo costo y ofrece los mismos beneficios que algunos de los instrumentos de

diagnóstico que actualmente están en el mercado, por una fracción de su precio. En

consecuencia, hace que el mantenimiento predictivo esté al alcance de cualquier

industria pequeña o mediana. Permitiendo mejorar sus costos de mantenimiento e

impulsando su crecimiento, lo que sin duda le permitirá ser una fuente mayor de

empleos.

Otro aspecto de impacto social, refiere a la seguridad e integridad del usuario,

al evitar que este expuesto a altos voltajes, ya que al realizar una medición de

corriente se corre el riesgo de sufrir un accidente laboral.

5.2 Impacto económico.

A lo largo del presente documento se enfatiza la importancia para la industria

manufacturera de mantener en buenas condiciones los motores de inducción, ya

que un fallo repentino puede generar pérdidas económicas por concepto de

reparación de estos activos, esto sin tomar en cuenta el costo que conlleva perder

horas de producción. Enseguida se muestran algunos costos de reparación de

motores Cuadro 15, el costo varía dependiendo de su potencia. Estos datos fueron

provistos en el año 2018 por un taller de reparación del estado de Aguascalientes.

46

No Potencia

del motor Tipo de reparación Costo MXN

1 5 HP Rebobinado de motor $ 1,820.0

2 5 HP Cambio de rodamientos a motor $ 807.0

3 5 HP Recuperación de desgaste, fabricación e

instalación de buje $ 500.0

4 7.5 HP Rebobinado de motor $ 1,820.0

5 7.5 HP Cambio de rodamientos a motor $ 807.0

6 7.5 HP Recuperación de desgaste, fabricación e















17 25 HP Cambio de rodamientos a motor $ 2,600.0


instalación de buje $ 1,500.0





47










Cuadro 15. Costos de reparación de motores de inducción en relación a su

potencia.

Elaboración propia de acuerdo a datos proporcionados por taller de reparación de

motores.

Para justificar la implementación del prototipo se evaluará la relación costo

beneficio. En el Cuadro 16 se presentan los costos de un nodo sensor y un nodo

coordinador, Debe tomarse en cuenta que en una red ZigBee puede estar formada

hasta por 254 nodos teóricamente. Por lo tanto, el usuario podrá seguir añadiendo

nodos según sea su necesidad y presupuesto.

48

No Componente Cantidad Costo MXN

Total

NO

DO

SE

NS

OR

1 Arduino Uno 1 $ 599.8

$ 3,775.4 2 XBee Shield para Arduino 1 $ 439.8

3 Xbee Pro S2B 1 $ 1,199.8

4 Sensor de corriente Dwyer 3 $ 1,536.0

NO

DO

CO

OR

DIN

AD

OR

5 Raspberry Pi 2B 1 $ 959.8

$ 2,505.3 6 Xbee Pro S2B 1 $ 1,199.8

7 XBee Explorer Dongle 1 $ 345.7

Cuadro 16. Costos de componentes de nodo sensor y coordinador.


Como se muestra en el capítulo 4, el prototipo monitorea de forma continua

y permanente nueve motores, seis de 37KW o 50HP y tres de 45KW o 60HP. Si se

logra evitar por lo menos el daño de un motor de 50HP, se logra justificar la

implementación de 3 nodos sensor y su respectivo coordinador, tal y como se

muestra en el Cuadro 17. Donde el concepto de reparación supera en un 30 % el

costo de los nodos.

No Concepto Cantidad Costo MXN

1 Reparación completa de motor de 50 HP 1 $ 19,860.0

2 Nodo coordinador 1 $ 2,505.3

3 Nodo sensor 3 $ 11,326.2

Costo de reparación - Costo de nodos $ 6,028.5

Cuadro 17. Relación costo-beneficio.


Conclusiones

49

Conclusiones

Debido a que uno de los síntomas que indican una sobrecarga en un motor es la

corriente excesiva, un sistema de monitoreo continuo, de este aspecto, como el que

se presenta en este documento, promete grandes beneficios, mediante la alerta

temprana de fallas iniciales al personal del departamento de mantenimiento, lo que

brinda la oportunidad de planificar las acciones correctivas necesarias para reducir

las pérdidas de producción y consumo excesivo de energía, en la industria e

incrementos innecesarios a los costos de mantenimiento.

Por otra parte, las herramientas de código abierto se han convertido en un

instrumento poderoso para el rápido desarrollo de soluciones basadas en IoT para

todos los campos de aplicación, en este caso se enfatizan los beneficios obtenidos

en la industria manufacturera, al ayudar a evitar pérdidas de producción causadas

por daños a los activos. Es importante mencionar que es posible disminuir el costo

de los nodos sensor, al pasar del uso de plataformas open source a un circuito

impreso, lo que puede convertir este prototipo en un producto final listo para ser

comercializado.

El prototipo desarrollado únicamente se enfoca en la obtención de forma

automática de los datos de consumo de corriente de los motores, por lo que el

análisis de los datos sigue dependiendo del factor humano, en pocas palabras la

experiencia y habilidad del experto en mantenimiento es necesaria para que

interprete los datos obtenidos y defina el estado del motor y si son necesarias o no

acciones preventivas o correctivas. Por otro lado los datos que son la materia prima

para cualquier tipo de análisis ya están disponibles en espera de ser procesados

por algoritmos que puedan arrojar de manera autónoma el estado del motor, que

han de mejorar el desempeño del sistema presente hasta lograr obtener el estatus

de un sistema de máquinas auto-conscientes y auto mantenidas, que de cierta

manera dotara de inteligencia al motor para que emita un autodiagnóstico y genere

solicitudes de mantenimiento de acuerdo a sus necesidades y disponibilidad, por

tanto el analista ya no será necesario.

50

Bibliografía

[1] Y. Yin, K. Stecke and D. Li, "The evolution of production systems from Industry

2.0 through Industry 4.0", International Journal of Production Research, vol. 56,

no. 1-2, pp. 848-861, 2017. Available: 10.1080/00207543.2017.1403664

[Accessed 2 February 2020].

[2] R. Parpala and R. Iacob, "Application of IoT concept on predictive maintenance

of industrial equipment", MATEC Web of Conferences, vol. 121, p. 02008, 2017.

Available: 10.1051/matecconf/201712102008 [Accessed 2 February 2020].

[3] R. Ahmad and S. Kamaruddin, "An overview of time-based and condition-based

maintenance in industrial application",Computers & Industrial Engineering, vol.

63, no. 1, pp. 135-149, 2012. Available: 10.1016/j.cie.2012.02.002 [Accessed 3

July 2019].

[4] E. Quispe Oquena, "Una visión integral para el uso racional de la energía en la

aplicación de motores eléctricos de inducción". Colombia: Corporación

Universitaria Autónoma de Occidente, 2003.

[5] J. Lee, H. Kao and S. Yang, "Service Innovation and Smart Analytics for Industry

4.0 and Big Data Environment", Procedia CIRP, vol. 16, pp. 3-8, 2014. Available:

10.1016/j.procir.2014.02.001 [Accessed 2 February 2020].

[6] M. Carnero, "An evaluation system of the setting up of predictive maintenance

programmes", Reliability Engineering & System Safety, vol. 91, no. 8, pp. 945-

963, 2006. Available: 10.1016/j.ress.2005.09.003 [Accessed 2 February 2020].

[7] L. Herger and M. Bodarky, "Engaging students with open source technologies

and Arduino", 2015 IEEE Integrated STEM Education Conference, 2015.

Available: 10.1109/isecon.2015.7119938 [Accessed 2 February 2020].

51

[8] Determining electric motor load and efficiency [Online]. Available:

https://www.energy.gov/sites/prod/files/2014/04/f15/10097517.pdf [Accessed:

02- Apr- 2019].

[9] T. Noergaard, "Embedded Systems Architecture: A Comprehensive Guide for

Engineers and Programmers", [S.l.]: Newnes, 2005, pp. 5-8.

[10] "Checking for Motor Overload", Fluke.com, 2020. [Online]. Available:

https://www.fluke.com/en-us/learn/best-practices/motors-and-drives/checking-

for-motor-overload. [Accessed: 02- Apr - 2019].

[11] "Protección de motores", Hackm365.com, 2020. [Online]. Available:

https://hackm365.com/x/manuales/reglamontsinger-pagina7-

protecciondelmotor.pdf. [Accessed: 06- Feb- 2020].

[12] J. Bryan, "When it comes to motors, how hot is hot?", Plant Engineering,

2020. [Online]. Available: https://www.plantengineering.com/articles/when-it-

comes-to-motors-how-hot-is-hot/. [Accessed: 06- Feb- 2020].

[13] O. Guerrero Castro, "Prevención de las fallas de los motores trifásicos de

inducción mediante una adecuada selección", Dialnet.unirioja.es, 2020. [Online].

Available: https://dialnet.unirioja.es/descarga/articulo/4835860.pdf. [Accessed:

05- Feb- 2020].

[14] F. Carvajal, J. Ramírez and L. Arcos, "Diagnóstico en línea y fuera de línea

de motores de inducción de baja, mediana y alta tensión", Ineel.mx, 2020.

[Online]. Available: https://www.ineel.mx/elec99/art4.pdf. [Accessed: 02- Apr-

2019].

https://www.energy.gov/sites/prod/files/2014/04/f15/10097517.pdf

52

[15] A. Cachada et al., "Maintenance 4.0: Intelligent and Predictive Maintenance

System Architecture", 2018 IEEE 23rd International Conference on Emerging

Technologies and Factory Automation (ETFA), 2018. Available:

10.1109/etfa.2018.8502489 [Accessed 6 February 2020].

[16] Z. Li, K. Wang and Y. He, “Industry 4.0 – Potentials for Predictive

Maintenance”. International Workshop of Advanced Manufacturing and

Automation, 2016. [Accessed: 02- Apr - 2019].

[17] E. Sezer, D. Romero, F. Guedea, M. Macchi and C. Emmanouilidis, "An

Industry 4.0-Enabled Low Cost Predictive Maintenance Approach for

SMEs", 2018 IEEE International Conference on Engineering, Technology and

Innovation (ICE/ITMC), 2018. Available: 10.1109/ice.2018.8436307 [Accessed 8

February 2020].

[18] J. Yick, B. Mukherjee and D. Ghosal, "Wireless sensor network

survey", Computer Networks, vol. 52, no. 12, pp. 2292-2330, 2008. Available:

10.1016/j.comnet.2008.04.002 [Accessed 8 July 2019].

[19] I. Akyildiz, W. Su, Y. Sankarasubramaniam and E. Cayirci, "Wireless sensor

networks: a survey", Computer Networks, vol. 38, no. 4, pp. 393-422, 2002.

Available: 10.1016/s1389-1286(01)00302-4 [Accessed 8 July 2019].

[20] J. Prieto Blázquez, “Introducción a los sistemas de comunicación

inalámbricos”, Universitat Oberta de Catalunya.

[21] M. Mahmoud and A. Mohamad, "A Study of Efficient Power Consumption

Wireless Communication Techniques/ Modules for Internet of Things (IoT)

Applications", Advances in Internet of Things, vol. 06, no. 02, pp. 19-29, 2016.

Available: 10.4236/ait.2016.62002 [Accessed 8 July 2019].

53

[22] R. Quinnell, "Low power wide-area networking alternatives for the IoT", EDN

Network, 2015. [Online]. Available: https://www.edn.com/design/systems-

design/4440343/1/Low-powerwide-area-networking-alternatives-for-the-IoT.

[Accessed: 12- Apr-2019].

[23] L. Islas, S. Gutierrez and F. Rodriguez, "Wireless Sensor Network Prototype

to Monitor the Condition of Holding Furnaces in the Aluminum Casting

Plant", 2019 IEEE International Conference on Engineering Veracruz (ICEV),

2019. Available: 10.1109/icev.2019.8920457 [Accessed 10 February 2020].

[24] S. Sharma, R. Bansal and S. Bansal, "Issues and Challenges in Wireless

Sensor Networks", 2013 International Conference on Machine Intelligence and

Research Advancement, 2013. Available: 10.1109/icmira.2013.18 [Accessed 8

July 2019].

[25] J. Martín Moreno and D. Ruiz Fernández, "Informe Técnico: Protocolo ZigBee

(IEEE 802.15.4)", studylib.es, 2007. [Online]. Available:

https://studylib.es/doc/5114897/informe-t%C3%A9cnico--protocolo-zigbee--

ieee-802.15.4-. [Accessed: 10- Feb- 2020].

[26] A. Wheeler, "Commercial Applications of Wireless Sensor Networks Using

ZigBee", IEEE Communications Magazine, vol. 45, no. 4, pp. 70-77, 2007.

Available: 10.1109/mcom.2007.343615 [Accessed 8 July 2019].

[27] P. Baronti, P. Pillai, V. Chook, S. Chessa, A. Gotta and Y. Hu, "Wireless

sensor networks: A survey on the state of the art and the 802.15.4 and ZigBee

standards", Computer Communications, vol. 30, no. 7, pp. 1655-1695, 2007.

Available: 10.1016/j.comcom.2006.12.020 [Accessed 8 July 2019].

54

[28] D. Parneet, and H. Sadawarti, "A review paper on Zigbee (IEEE 802.15. 4)

Standard." International Journal of Engineering Research 3.4 (2014). [Accessed:

10- Feb- 2020].

[29] "XBee/XBee-PRO Zigbee RF Modules User Guide", Digi.com. [Online].

Available:https://www.digi.com/resources/documentation/digidocs/pdfs/9000097

6.pdf. [Accessed: 11- Feb- 2020].

[30] M. Weyrich and C. Ebert, "Reference Architectures for the Internet of

Things", IEEE Software, vol. 33, no. 1, pp. 112-116, 2016. Available:

10.1109/ms.2016.20 [Accessed 13 February 2020].

[31] Z. Yang, Y. Yue, Y. Yang, Y. Peng, X. Wang and W. Liu, "Study and

application on the architecture and key technologies for IOT", 2011 International

Conference on Multimedia Technology, 2011. Available:

10.1109/icmt.2011.6002149 [Accessed 16 February 2020].

[32] Q. Zhu, R. Wang, Q. Chen, Y. Liu and W. Qin, "IOT Gateway:

BridgingWireless Sensor Networks into Internet of Things", 2010 IEEE/IFIP

International Conference on Embedded and Ubiquitous Computing, 2010.

Available: 10.1109/euc.2010.58 [Accessed 16 February 2020].

[33] P. Galkin, L. Golovkina and I. Klyuchnyk, "Analysis of Single-Board

Computers for IoT and IIoT Solutions in Embedded Control Systems", 2018

International Scientific-Practical Conference Problems of Infocommunications.

Science and Technology (PIC S&T), 2018. Available:

10.1109/infocommst.2018.8632069 [Accessed 17 February 2020].

55

[34] S. Ferdoush and X. Li, "Wireless Sensor Network System Design Using

Raspberry Pi and Arduino for Environmental Monitoring Applications", Procedia

Computer Science, vol. 34, pp. 103-110, 2014. Available:

10.1016/j.procs.2014.07.059 [Accessed 17 February 2020].

[35] "XCTU - Next Gen Configuration Platform for XBee/RF Solutions | Digi

International", Digi.com. [Online]. Available:

https://www.digi.com/products/embedded-systems/digi-xbee/digi-xbee-

tools/xctu. [Accessed: 19- Feb- 2020].

[36] "XCTU Configuration and Test Utility Software User Guide", Digi.com.

[Online]. Available: https://www.digi.com/support/productdetail?pid=3352.

[Accessed: 19- Feb- 2020].

[37] "Arduino - AnalogInputPins", Arduino.cc. [Online]. Available:

https://www.arduino.cc/en/Tutorial/AnalogInputPins. [Accessed: 20- Feb- 2020].

[38] "About: Node-RED", Nodered.org. [Online]. Available:

https://nodered.org/about/. [Accessed: 21- Feb- 2020].

[39] "InfluxDB 1.X: Open Source Time Series Platform | InfluxData", InfluxData.

[Online]. Available: https://www.influxdata.com/time-series-platform/. [Accessed:

21- Feb- 2020].

[40] "Grafana Features", Grafana Labs. [Online]. Available:

https://grafana.com/grafana/. [Accessed: 21- Feb- 2020].

[41] A. Katal, M. Wazid and R. Goudar, "Big data: Issues, challenges, tools and

Good practices", 2013 Sixth International Conference on Contemporary

Computing (IC3), 2013. Available: 10.1109/ic3.2013.6612229 [Accessed 2

March 2020].

56

[42] Y. Lei, N. Li, L. Guo, N. Li, T. Yan and J. Lin, "Machinery health prognostics:

A systematic review from data acquisition to RUL prediction", Mechanical

Systems and Signal Processing, vol. 104, pp. 799-834, 2018. Available:

10.1016/j.ymssp.2017.11.016 [Accessed 3 March 2020].

[43] L. Yongxiang, S. Jianming, W. Gong and L. Xiaodong, "A data-driven

prognostics approach for RUL based on principle component and instance

learning", 2016 IEEE International Conference on Prognostics and Health

Management (ICPHM), 2016. Available: 10.1109/icphm.2016.7542815

[Accessed 3 March 2020].

[44] J. Lee, H. Kao and S. Yang, "Service Innovation and Smart Analytics for

Industry 4.0 and Big Data Environment", Procedia CIRP, vol. 16, pp. 3-8, 2014.

Available: 10.1016/j.procir.2014.02.001.

Anexos

57

Anexos

Anexo I – Código de Arduino para adquisición de datos

int i,j;

int valor[7];

void setup() {

Serial.begin(9600);

}

void loop() {

j=0;

for (i = 0; i < 3; i++) {

float Irms=get_corriente(i); //Corriente eficaz (A)

int ent = int(Irms);

float deci = Irms - ent;

int de2en = 100 * deci;

valor[j] = ent;

valor[j+1] = de2en;

j=j+2;

}

j=0;

for (j = 0; j < 6; j++) {

Serial.write(byte(valor[j]));

}

// frecuencia de transmisión de datos cada 5 segundos

delay(5000);

}

float get_corriente(int x)

{

float voltajeSensor;

float corriente=0;

float Sumatoria=0;

long tiempo=millis();

int N=0;

58

while(millis()-tiempo<500)//Duración 0.5 segundos(Aprox. 30

ciclos de 60Hz)

{

//voltaje del sensor

voltajeSensor = analogRead(x) * (0.7 / 1023.0);

corriente=voltajeSensor *100.0;

Sumatoria=Sumatoria+sq(corriente);//Sumatoria de

Cuadrados

N=N+1;

delay(1);

}

//Para compensar los cuadrados de los semiciclos negativos.

Sumatoria=Sumatoria*2;

corriente=sqrt((Sumatoria)/N); //calculo corriente RMS

return(corriente);

}

INFOTEC CENTRO DE INVESTIGACIÓN E INNOVACIÓN · 2020. 8. 28. · 2.4 Estándar ZigBee ... cuando...

Documents

Transcript of INFOTEC CENTRO DE INVESTIGACIÓN E INNOVACIÓN · 2020. 8. 28. · 2.4 Estándar ZigBee ... cuando...