nueva página del texto (beta)
Español (pdf)
Artículo en XML
Referencias del artículo
Traducción automática
Enviar artículo por email
Citado por SciELO 
Similares en
SciELO 
Permalink
1. Introducción
La fabricación de productos a gran escala requiere una infraestructura y medios técnicos específicos que permitan el montaje en serie, dividido en distintas etapas o fases, conocidas como líneas de producción. Cada una de estas etapas representa un conjunto de actividades interrelacionadas que transforman elementos de entrada en elementos de salida [1].
En entornos industriales, muchos de estos procesos de manufactura son repetitivos y/o automáticos, y están dirigidos por Controladores Lógicos Programables (PLCs), los cuales gestionan cambios en el producto final en cada uno de ellos. Estos procesos se encargan de transformar materia prima en algún producto final que pueda ser útil para la sociedad y con ello convertir a una empresa en un negocio rentable, para lo cual es necesario producir al menor costo posible y este es el objetivo de cualquier mejora del proceso [2].
La medición de la eficiencia en una planta de producción se basa comúnmente en la productividad, que indica la cantidad producida por el sistema [3].
Es en este contexto donde la detección y gestión de fallos adquieren una importancia crucial. Una falla se define como la incapacidad de un bien para cumplir con las funciones esperadas por el usuario [4]. Esta puede manifestarse como una falla total o parcial [5]. El tipo de paro puede ser por falla del equipo, de rutina o imprevisible [6] y el tiempo durante el cual se detiene la operación de un proceso o sistema se conoce como tiempo de paro.
Un alto porcentaje de las horas disponibles del personal de mantenimiento se dedica a la solución de fallos. Esta proporción varía considerablemente entre empresas, desde aquellas en las que el 100% del mantenimiento es correctivo, hasta aquellas en las que todas las intervenciones son programadas. Se estima que, en promedio, más del 70% del tiempo total dedicado al mantenimiento se emplea en la solución de fallos no programados [7].
Los tiempos de paro para este caso se dividen en dos grupos:
En la figura 1 se presenta una clasificación de los tiempos de paro y algunas de las causas más comunes.
2. Planteamiento del problema y solución propuesta
2.1 Planteamiento del problema
El desarrollo y la implementación de este proyecto se llevó a cabo en una empresa del giro automotriz, en donde México se colocó en el séptimo lugar en el mundo dentro del ranking de los países productores de automóviles, con poco más de 3 millones de unidades producidas en el año 2021. [8]
Esta investigación se centra en los paros no planeados, específicamente en aquellos que resultan de averías en la maquinaria que forma parte de un proceso de producción en una empresa de manufactura, y propone un método automático para su monitoreo.
Dentro de la empresa se cuenta con un sistema manual para conocer los tiempos de paro no planeados debido a fallas de maquinaria.
En la figura 2 se muestra el proceso tradicional que se sigue para reportar una falla de máquina para que ésta sea reparada.
En el proceso mostrado en la figura 2 se cree que se pasan por alto muchas fallas que no son reportadas al departamento de Ingeniería, estas suelen ser resueltas por la experiencia de los operadores o simplemente no son reportadas. Como resultado, estas fallas no se registran ni se archivan adecuadamente. Además, la duración de estos tiempos de paro es desconocida.
Inicialmente se implementaron formularios de seguimiento para detallar los paros no programados en la línea de producción. Estos formularios intentaron recopilar información más específica, como el nombre de la falla, la hora de inicio y la hora de finalización. Sin embargo, estos formularios agregaron una carga adicional de trabajo a los operadores, lo que resultó en un descuido del proceso en lugar de mejorarlo. La compañía se compone de varias líneas de producción, para lo cual se seleccionó una de estas líneas como área de enfoque para identificar áreas de oportunidad y determinar la mejor manera de aumentar la producción sin adquirir nueva maquinaria.
2.2 Solución propuesta
En la actualidad la tecnología ha crecido enormemente y es posible aprovechar técnicas de la industria 4.0 para obtener datos de la maquinaria de manera eficiente. Esta tecnología permite implementar una solución novedosa y automatizada, que reduce el uso de papel, elimina la necesidad de un archivo físico para almacenar datos y facilita el acceso rápido a la información. Además, esta solución es capaz de monitorear datos en tiempo real, liberar al personal de tareas administrativas como completar formularios y permitir análisis estadísticos de los datos [9].
Los conceptos de la industria 4.0, que incluyen tecnologías digitales como el Internet de las cosas, el cómputo en la nube, los macrodatos, las redes de sensores inalámbricos, los sistemas embebidos y los dispositivos móviles, entre otros, son esenciales en este contexto [10].
Existen investigaciones dedicadas a la detección y diagnóstico de fallas mediante sistemas de monitoreo continuo mientras la máquina está en operación. El propósito principal de esos trabajos es prevenir paros de emergencia y prolongar la vida útil del equipo para reducir los costos de producción [11].
Dentro del estado del arte se encuentran la siguientes investigaciones que abordan el tema de los tiempos de paro de maquinaria, se afronta la problemática a Través de un software estadístico [12], a través de una combinación de Manufactura ajustada e industria 4.0 [13], a través del monitoreo de variables como, corriente y voltaje por medio de sensores inalámbricos [14], técnicas de análisis de alarmas usando sistema SCADA [15], a través de software de detección de error lógico en terminales remotas [16].
También se han creado invenciones para abordar el tema, invenciones como el método de alarmas dinámicas [17], el Sistema de Alarma de Computadora Superior [18], el Sistema Global de Alarma Basado en la Nube Para Sistemas Industriales [19], el Sistema de alarma Centralizado Remoto [20], Sistema de Alarma de Fallos Basado en PLC [21], Sistema de Interfaz Hombre Máquina que tiene elementos con alarmas agregadas [22], Sistema de Alarma Inteligente Basado en Sistema SCADA [23] y el Dispositivo de reciclaje Automático para Piezas Pequeñas de Placas delgadas Anidadas [24].
A diferencia de las anteriores investigaciones e invenciones, en este trabajo se propone un método de recolección y monitoreo de códigos de fallo donde el control del proceso este guiado por PLCs, creando así un sistema especializado en códigos de falla y no en modificar variables de control o modificar paramétrica del equipo ya que es útil el monitoreo de un activo desde la operación hasta el modo de falla especifico [25]. De tal manera que, para mejorar el proceso, el sistema de recolección y monitoreo nos refleja el estado de “salud” en tiempo real y su comportamiento pasado, esto permite destinar recursos de manera efectiva para aumentar su disponibilidad y otorga los beneficios del uso inteligente de los datos obtenidos.
En este trabajo se presenta un método de recolección y monitoreo automático de códigos de falla y muestra su funcionalidad a través de su implementación en un caso real.
3. El método de recolección y monitoreo de códigos de fallo
En esta sección se presenta el método de recolección de códigos de falla, el cual puede ser aplicable a cualquier proceso guiado por PLC capaz de comunicarse con otro dispositivo a través de algún protocolo de comunicación como ethernet, serial, inalámbrica entre otros. Primero se muestra el diagrama de flujo de los pasos a seguir para implementarlo, después describe el método en 12 pasos consecutivos y se explica en que consiste cada paso.
4. Aplicación práctica
La implementación del método de recolección se llevó a cabo en una línea de producción dividida en 5 subprocesos, cada uno guiado por un controlador. Antes de poder implementar el método, fue necesario establecer la comunicación entre los controladores, lo cual se logró mediante una red Ethernet con Acceso Múltiple por Detección de Portadora con Detección de Colisiones (CSMA/CD) [26], agregando un módulo de comunicación a cada dispositivo y creando así una red industrial como base para la recolección de datos. Además, se designó a uno de los nodos de la red como el controlador de recolección, dejando todo listo para la implementación.
A continuación, se describe la implementación del método de recolección definido en la Tabla 1, detallando cada paso e incluyendo evidencia en cada uno.
Tabla 1 Pasos del Método de recolección y monitoreo de códigos de fallo.
| PASO | ACTIVIDAD |
| 1 | Crear una base de datos con información correspondiente a cada código de fallo posible por cada PLC dentro de la red, donde cada código de fallo esta referenciado a un mensaje único y especifico por cada código. |
| 2 | Tomar solo la memoria destinada a los fallos del sistema en la memoria del PLC que está guiando algún proceso en el nivel más bajo. |
| 3 | Organizar los datos dentro de la memoria en una estructura continua de memorias. |
| 4 | Enviar el bloque de memoria del PLC ya organizada y con un código de identificación del PLC de origen a un PLC de recolección. |
| 5 | Organizar la información por PLC de origen en la memoria del PLC de recolección. |
| 6 | Comparar los códigos de fallo activos en el PLC de recolección con la base de datos creada en el paso de crear una base de datos con información correspondiente a cada código de fallo. Si el código está en 1 lógico continúa al siguiente paso, si es 0 salta al siguiente código. |
| 7 | Agregar la información que está en la base de datos al código que está en el PLC de recolección siempre y cuando el código de fallo este activo con el fin de que pueda interpretarlo el usuario. |
| 8 | Asignar contadores incrementales para capturar la ocurrencia de cada código de falla, uno por contador. |
| 9 | Comparar el límite de ocurrencia de fallo creado en el paso de crear una base de datos, con el número de ocurrencia de fallo de asignar un contador a cada código de fallo. Si el límite de ocurrencia es menor o igual el sistema sigue al paso 10 de lo contrario salta al paso 11. |
| 10 | Habilitar el mensaje de advertencia de posible fallo del sistema en el PLC de recolección, si el límite de ocurrencia del fallo es menor que el número de ocurrencia del fallo, si no se da ese caso no se habilita el mensaje. |
| 11 | Enviar a un dispositivo de visualización, la información guardada en la base de datos, más la información que agrega el PLC de recolección. |
| 12 | Recibir la información organizada mostrada por el dispositivo de visualización. |
Paso 1
En la figura 4 se muestra la creación de la base de datos de los códigos de falla, los cuales se realizaron siguiendo atributos de los datos estructurados de la tecnología de macrodatos, con campos fijos [9], en esta lista están incluidos todos los posibles códigos de los 5 controladores de la red. La base de datos se creó con 640 alarmas posibles, las cuales son el total de códigos de falla que tienen los 5 procesos. Cada número de dispositivo le corresponde un mensaje en la base de datos de código de fallo. Para la creación de la base de datos se utilizó el software VT-Studio ya que la interfaz de visualización correrá sobre este software basándose en el manual de usuario [27].
Paso 2
En este paso es necesario ubicar dentro del programa del controlador, las memorias que se usan para disparar los códigos de fallo, el orden de estos códigos depende del controlador, así que en esta parte es necesario ubicar todas las memorias de fallas para después organizarlas.
Paso 3
En la figura 5 se muestran los códigos de fallo organizados de manera continua a excepción de algunos espacios como el de la memoria M418, el cual fue dejado en blanco a propósito, esto debido a la intención de crear un nuevo código en ese espacio.
Para organizar la memoria de este controlador fue necesario utilizar el software GX Works 3 de Mitsubishi para entrar en el controlador y separar la memoria de códigos de falla del resto de los datos del proceso y organizarla en bloques para su fácil manejo, la configuración se basó en el manual de usuario del software [28]. Ahora la memoria está organizada en bloques y lista para manipularse más fácil.
Paso 4
En la figura 6 ya organizada la memoria de los códigos de fallo, esta se envía a la memoria del controlador que recolecta la información de todos los nodos en la red. En este caso se utilizó la instrucción “MOVE” en el lenguaje de programación en escalera según la norma IEC 61131 [29] para mover los bloques de memoria de un controlador a otro.
Paso 5
En la figura 7 se muestra cómo es que en el controlador de recolección se unen todas las memorias de códigos de fallo de todos los controladores en la red. En este caso hay 5 controladores en la red por lo tanto se crean 5 estaciones donde el controlador de recolección es el nodo número 0 el cual aparece como estación maestra, para la configuración de la estructura fue necesaria la utilización del software GX Works2 de Mitsubishi Electric y el manual de operación [30].
Paso 6
En la figura 8 se observa solo una parte de la memoria del controlador de recolección, específicamente la parte correspondiente a la estación 1. En esta área de memoria un 1 lógico equivale a una alarma activa, esta memoria es comparada con la base de datos creada con los mensajes correspondientes a cada bit.
Paso 7
Dentro del sistema se revisan los códigos de falla en estado lógico 1 y en consecuencia se agrega el mensaje correspondiente siguiendo la siguiente nomenclatura:
Inicio-fin-controlador de origen-Mensaje del error-bit de activación-ocurrencia
Donde cada indicador tiene el siguiente significado:
El indicador de inicio nos dice cuando se activó el código de falla
El indicador de fin nos dice cuando fue resuelto el código de falla.
El indicador de controlador de origen nos indica de controlador de subproceso se originó el código de falla.
El mensaje de error ayuda al personal de diagnóstico a tener una idea más clara del problema
El bit de activación le indicara al programador cual es el bit de memoria de activación para poder rastrear la falla por software.
El indicador de ocurrencia es en número de veces que se ha disparado el código de fallo desde la última vez que se reinició el contador.
Un ejemplo de un código de falla es el siguiente:
03/05_06:40_06:51_HC_Work_confirmation_4 OP0BB_1
Donde se lee de la siguiente manera:
Fue una alarma que ocurrió el 03 de mayo a las 06:40 horas, fue resuelta a las 06:51 horas, el mensaje de alarma fue HC_work_ confirmation, el código de falla en el programa es 4OP0BB y es la primera vez en el periodo que ocurre esa falla.
Paso 8
En la figura 9 se muestra la configuración para hacer un conteo de los códigos de fallos activos cada vez que se detecte un flanco positivo ascendente, el cual se configuró dentro de la interfaz gráfica con el software VT-studio [31].
Paso 9
En el paso 9 se realiza una comparación entre el contador de ocurrencia del código de fallo y el límite definido para cada código. En la figura 10 se muestran las líneas de código que se agregaron con el fin de realizar la comparación.
Paso 10
Cuando el límite de advertencia sea alcanzado, se agregará un mensaje extra de error, de tal manera que se mostraría algo como:
03/05-06:40-06:51-HC_Work_confirmation-limite_de_ocurrencia-revasado-4OP0BB-16
Paso 11
En las figuras 11 y 12 se muestran las configuraciones de comunicación entre la interfaz gráfica y el controlador de recolección. Se puede observar cómo es que en la interfaz gráfica se da de alta la dirección IP del controlador, para que esto sea posible, las dos direcciones IP deben estar dentro del mismo rango para que pueda existir la comunicación [32], también se observa cómo es que en los dos dispositivos se abre el puerto 8502 para crear el canal de comunicación entre ellos, si no se da de alta el mismo puerto en los dos dispositivos no podrá efectuarse el intercambio de información.
Donde a diferencia del mensaje mostrado en el paso 7, se agrega un mensaje de límite de ocurrencia.
Este mensaje es importante ya que permite encontrar una falla que ha rebasado el límite de lo considerado normal, convirtiéndose así en una falla potencialmente grave en los próximos even
Para el envío de información de un controlador a otro, es necesario cumplir con el protocolo de comunicación y la compatibilidad, eso dependerá del controlador y el protocolo de comunicación elegidos.
Paso 12
En la figura 13 se muestra la aplicación final con los códigos de falla siguiendo las nomenclaturas propuestas, mientras que en la figura 14 se muestra la aplicación ya implementada en un panel de visualización y funcionando en tiempo real.
Paso 13 (recomendación)
Hasta este punto se ha terminado con la implementación del método de recolección y monitoreo en un proceso de producción, logrando rastrear hasta 2000 códigos de fallo históricos.
Para mejorar los resultados y eliminar el límite de los 2000 posibles códigos guardados, se propone implementar la tecnología de computación en la nube la cual se utiliza para proporcionar servicios de almacenamiento de datos [33] haciendo una comunicación entre el sistema de monitoreo y un servidor con el fin de poder monitorear el proceso desde uno o varios puntos remotos.
Para la implementación del último paso sugerido en el caso ya mostrado, se utilizó la red interna de la empresa, escogiendo el cable de red Ethernet CAT-6 SFTP como medio físico de comunicación, también se utilizó el servidor de la empresa, separando un espacio para el almacenamiento de los datos obtenidos del sistema de recolección y monitoreo.
En la figura 15 se muestra un ejemplo de un archivo de recolección guardado automáticamente en el servidor por el sistema de monitoreo el cual se genera cada 24hr.
En la figura 16 se muestra una pantalla de 42 pulgadas utilizado como estación de monitoreo remota, la cual se instaló en las oficinas de operaciones de la empresa.
5. Resultados
El resultado fue un Sistema de Control en Red [34] automático de recolección y monitoreo de códigos de fallo con la capacidad de monitorear códigos de error de forma local y remota, esto gracias a la conexión entre el sistema y la nube de almacenamiento.
Primeramente, se realizó una investigación de las fallas reportadas en el año anterior 2022 solo de la línea de producción donde se llevó a cabo la implementación, las cuales están reportadas y archivadas de forma manual, dando como resultado un total de 116 fallas reportadas en el periodo anterior.
Por otro lado, las fallas reportadas en el periodo pasado fueron fallas graves que provocaron interrupciones de producción de más de 1 hora y que no fueron planeadas.
En la figura 17 se muestra el número de fallas registradas en el año 2022 solo del proceso donde se implementó este proyecto.
Para validar los datos del nuevo sistema de monitoreo, se tomó un tiempo de 1 semana para depurar y corregir algunos errores en los mensajes de los códigos de falla y otros problemas en la comunicación, una vez superado el tiempo de arranque y depurado, se monitoreo la línea de producción durante un periodo de 4 semanas antes de realizar un análisis de los datos. Después de ese periodo se extrajeron los datos del último mes y se pudo encontrar lo siguiente:
En la figura 18 se muestra el principal resultado de la implementación y del análisis de Pareto el cual es conocido como la ley 80-20 [35] del último mes de datos. El sistema detecto un total de 1499 códigos de falla en 4 semanas de monitoreo, contrastando enormemente con las 116 reportadas el año pasado.
Esto puso en evidencia que en este proceso hay micro paros de menos de 5 minutos que no estaban reflejados en los reportes de producción o de ingeniería.
También mostró paros que se volvieron habituales en la operación ya que hay fallos que son resueltos en el momento y no son reportados a ingeniería, causando que no fueran atendidas las causa raíz del fallo y volviéndose a presentar en corto tiempo, evitando de forma no intencional que fueran atendidos y siendo ignorados en el indicador de tiempos perdidos del proceso.
El total de códigos de fallo registrados fueron filtrados, de modo que en la figura 19 se muestra el diagrama de Pareto de las fallas más repetitivas encontradas por el sistema de recolección y monitoreo, mostrando así que las 3 fallas más comunes se presentaron 372 veces en el periodo de un mes.
Otro dato que arrojó el sistema es que el nodo número 1 es el que más códigos de falla generó.
En la figura 20 se muestran las fallas totales por fase del proceso, cada una tiene un nombre, un controlador y un nodo en la red, esto nos permite visualizar que el nodo con el nombre “HC” es el que más fallos presenta en el proceso y es la que más atención necesita.
En la figura 21 se muestra otro dato importante arrojado por el sistema y es que, de los 640 posibles códigos de falla registrados en la base de datos, se presentaron 119 en el último periodo, lo que representa el 18.5% del total de posibles fallas.
Con base en los datos obtenidos por el sistema de recolección y monitoreo, se diseñan estrategias para reducir el número de fallas en el proceso, las cuales se llevarán a cabo por el área de Ingeniería con el fin de mejorar la productividad del proceso y abriendo la puerta para extender el sistema a toda la planta de producción.
6. Conclusiones
La principal contribución de este trabajo es la propuesta de un método automático de recolección y monitoreo de códigos de falla, con la intención de crear un sistema especializado en monitoreo de fallas de procesos de manufactura, quedando su uso abierto al criterio de cualquier persona.
Con la implementación del método propuesto se obtienen las siguientes conclusiones:
Es posible la implementación del método de recolección en un ambiente industrial.
Para hacer la implementación es necesario contar con una red de comunicación entre los dispositivos que se requiere monitorear, sin esta no es posible comenzar.
El tiempo de instalación de este sistema y con las condiciones aquí descritas fue de 2 meses una vez teniendo todos los componentes.
Para conseguir los resultados aquí mostrados es necesario realizar el paso 13.
El sistema es capaz de detectar códigos de fallo de corta duración.
El método de recolección funciona para todos los nodos agregados en la red y solo está limitado por las restricciones del protocolo de comunicación que sea seleccionado.
El sistema logro detectar más de 1200% de códigos de falla que los que se tenían registrados manualmente.
La estación remota redujo el tiempo de respuesta ante una falla grave, en promedio se atendía en 10min y se redujo a 5min.
Al revisar los resultados del análisis de los datos proporcionados por el sistema de monitoreo, se evidenció un problema que no se había considerado previamente, la gran cantidad de paros debido a fallas de corta duración. Estas fallas generan micro paros de menos de 5 minutos y se acumulan durante la jornada de producción y por su rapidez no se reflejan en los informes diarios, estos paros representan un área de oportunidad de un 4.8% en el aumento de la producción mensual si son evitados.
También se emiten las siguientes recomendaciones para los trabajos futuros.
Se recomienda agregar una función de apagado de máquina para que el sistema no registre el tiempo en el que la máquina no esté en operación como tiempo de falla.
Se recomienda agregar una condición de paro de proceso si se excede el límite de ocurrencia de la falla.
Para implementar el método de recolección en un PLC es importante la sincronización de reloj interno para no generar conflicto en los tiempos detectados.
Se recomienda el uso de un bit de ida y vuelta para el monitoreo del funcionamiento de la comunicación de los nodos.
El análisis de estos datos permite desarrollar estrategias más efectivas para reducir los tiempos de paro en la producción debido a fallos en la maquinaria, así como adaptar las técnicas de mantenimiento con un enfoque más preciso en los síntomas de los fallos, lo que aumenta la disponibilidad de la maquinaria para la producción diaria.
