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 4. Requerimiento funcional número 2. ...................................................... 24
Cuadro 5. Requerimiento funcional número 3. ...................................................... 24
Cuadro 6. Requerimiento funcional número 4. ...................................................... 25
Cuadro 7. Requerimiento funcional número 5. ...................................................... 25
Cuadro 8. Requerimiento funcional número 6. ...................................................... 25
Cuadro 9. Requerimiento no funcional número 1. ................................................. 26
Cuadro 10. Requerimiento no funcional número 2. ............................................... 26
Cuadro 11. Requerimiento no funcional número 3. ............................................... 26
Cuadro 12. Requerimiento no funcional número 4. ............................................... 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.
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.
Elaboración propia.
Identificación del requerimiento:
RF02
Nombre del Requerimiento:
Comunicación.
Características: El prototipo debe ser un nodo sensor, perteneciente a una red de sensores inalámbricos.
Descripción del requerimiento:
El rango de transmisión debe soportar mínimo 100 metros (deseable 1 km).
Cuadro 4. Requerimiento funcional número 2.
Elaboración propia.
Identificación del requerimiento:
RF03
Nombre del Requerimiento:
Alertas.
Características: El prototipo debe avisar al usuario, cuando la variable monitoreada sobrepase los valores de control establecidos.
Descripción del requerimiento:
El sistema permitirá al usuario establecer el valor límite de la variable monitoreada para saber si ha sido sobrepasado.
Cuadro 5. Requerimiento funcional número 3.
Elaboración propia.
25
Identificación del requerimiento:
RF04
Nombre del Requerimiento:
Almacenamiento.
Características: Se debe contar con sistema de almacenamiento de la información obtenida de los nodos sensores.
Descripción del requerimiento:
La información debe estar almacenada en una base de datos.
Cuadro 6. Requerimiento funcional número 4.
Elaboración propia.
Identificación del requerimiento:
RF05
Nombre del Requerimiento:
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.
Descripción del requerimiento:
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.
Cuadro 7. Requerimiento funcional número 5.
Elaboración propia.
Identificación del requerimiento:
RF06
Nombre del Requerimiento:
Consulta.
Características: Consultas de la información almacenada.
Descripción del requerimiento:
El usuario podrá seleccionar el rango de fechas en los que desea consultar la información.
Cuadro 8. Requerimiento funcional número 6.
Elaboración propia.
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.
Identificación del requerimiento:
RNF01
Nombre del Requerimiento:
Carcasa.
Características: El nodo sensor debe contar con carcasa.
Descripción del requerimiento:
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.
Elaboración propia.
Identificación del requerimiento:
RNF02
Nombre del Requerimiento:
Vida útil del nodo sensor.
Características: El nodo sensor debe tener un funcionamiento continuo.
Descripción del requerimiento:
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.
Cuadro 10. Requerimiento no funcional número 2.
Elaboración propia.
Identificación del requerimiento:
RNF03
Nombre del Requerimiento:
Manual de usuario.
Características: Instructivo para uso del prototipo.
Descripción del requerimiento:
Se debe hacer entrega de manual para ayudar al usuario con el manejo del prototipo.
Cuadro 11. Requerimiento no funcional número 3.
Elaboración propia.
Identificación del requerimiento:
RF04
Nombre del Requerimiento:
Reportes.
Características: Generación de reportes de la información consultada.
Descripción del requerimiento:
Se podrán exportar los datos consultados en formato de Excel o CSV.
Cuadro 12. Requerimiento no funcional número 4.
Elaboración propia.
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.
Elaboración propia.
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.
Elaboración propia.
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.
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.
Elaboración propia.
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)
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.
Elaboración propia.
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.
Elaboración propia.
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.
Elaboración propia.
36
Figura 17. Datos de dispositivo final en Interfaz gráfica de Grafana.
Elaboración propia.
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.
Elaboración propia.
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.
Elaboración propia.
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.
Elaboración propia.
41
Figura 22. Motores de inducción monitoreados.
Elaboración propia.
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.
Elaboración propia.
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.
Elaboración propia.
43
Figura 25. Panel individual en Grafana.
Elaboración propia.
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
instalación de buje $ 500.0
7 10 HP Rebobinado de motor $ 1,870.0
8 10 HP Cambio de rodamientos a motor $ 790.0
9 10 HP Recuperación de desgaste, fabricación e
instalación de buje $ 530.0
10 15 HP Rebobinado de motor $ 2,300.0
11 15 HP Cambio de rodamientos a motor $ 864.0
12 15 HP Recuperación de desgaste, fabricación e
instalación de buje $ 868.0
13 20 HP Rebobinado de motor $ 2,900.0
14 20 HP Cambio de rodamientos a motor $ 870.0
15 20 HP Recuperación de desgaste, fabricación e
instalación de buje $ 870.0
16 25 HP Rebobinado de motor $ 3,430.0
17 25 HP Cambio de rodamientos a motor $ 2,600.0
18 25 HP Recuperación de desgaste, fabricación e
instalación de buje $ 1,500.0
19 30 HP Rebobinado de motor $ 5,690.0
20 30 HP Cambio de rodamientos a motor $ 2,600.0
21 30 HP Recuperación de desgaste, fabricación e
instalación de buje $ 1,500.0
47
22 40 HP Rebobinado de motor $ 9,410.0
23 40 HP Cambio de rodamientos a motor $ 4,100.0
24 40 HP Recuperación de desgaste, fabricación e
instalación de buje $ 3,060.0
25 50 HP Rebobinado de motor $ 11,460.0
26 50 HP Cambio de rodamientos a motor $ 4,100.0
27 50 HP Recuperación de desgaste, fabricación e
instalación de buje $ 4,300.0
28 60 HP Rebobinado de motor $ 12,970.0
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.
Elaboración propia.
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.
Elaboración propia.
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].
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);
}
Top Related