Mantenimiento predictivo en la industria manufacturera con IA

Mantenimiento predictivo en la industria manufacturera: de la telemetría de proceso a acciones priorizadas

Foto de Ant Rozetsky en Unsplash.

Toda planta ya cuenta con los sensores que necesita un programa de mantenimiento predictivo. Los PLC, los historiadores SCADA, las sondas de vibración, los sensores térmicos y los servidores OPC UA generan más telemetría por turno de la que cualquier equipo de fiabilidad puede leer manualmente. La mayor parte de esos datos se queda en el historiador y nunca se convierte en una decisión.

La cobertura de sensores rara vez es el problema. La pieza que falta está entre las etiquetas en bruto y una lista priorizada de lo que hay que arreglar esta semana: leer la analítica de telemetría de proceso que ya existe y convertirla en acciones que un equipo de mantenimiento pueda ejecutar antes de que la línea se detenga.

De dónde viene realmente el tiempo de inactividad

El tiempo de inactividad no planificado rara vez se anuncia. Un rodamiento se degrada durante semanas antes de agarrotarse. La corriente de un motor sube poco a poco durante un mes antes del disparo. Cuando un operador nota que algo va mal, el modo de fallo suele llevar tiempo visible en los datos.

El coste directo de la reparación final suele ser el número más pequeño. La producción perdida, las piezas urgentes, las horas extra y las ventanas de envío incumplidas se suman a su alrededor. Las estimaciones del sector suelen situar la reducción que aporta un programa de mantenimiento predictivo en funcionamiento en un rango del 30-50% para el tiempo de inactividad no planificado, aunque la cifra depende mucho de la madurez del mantenimiento de partida y debe leerse como una estimación orientativa, no como una garantía para ninguna planta concreta.

La mayoría de los programas de mantenimiento de maquinaria ya tienen los sensores para detectar estos fallos antes. Lo que falta es una forma de vigilar cada señal de forma continua sin generar una alarma por cada una de ellas.

De PLC, SCADA y OPC UA a una capa de decisión

Los equipos de fiabilidad ya tienen la telemetría: etiquetas de PLC, puntos SCADA y, cada vez más, un servidor OPC UA estándar que los expone todos en un solo lugar. Añadir una capa de decisión sobre esos datos no significa tocar el bucle de control.

FrostLogic Explore lee la telemetría de proceso en modo solo lectura, a través de OPC UA, Modbus o las API de los fabricantes de PLC. Nunca escribe un punto de consigna ni se sitúa dentro del bucle de control. El motor detrás de esta monitorización de equipos de fábrica, Frostdynamics(tm), ingiere las mismas etiquetas que ya almacena el historiador SCADA y las correlaciona a través de la física que realmente rige el equipo, no solo con umbrales por etiqueta.

Esa distinción importa en una planta de fábrica más que en casi cualquier otro sitio. La vibración de una bomba, la corriente de su motor, la temperatura de su rodamiento y su caudal no son variables independientes. Un umbral en cualquiera de ellas por separado se disparará con demasiada frecuencia o pasará por alto el fallo que se manifiesta como un pequeño desplazamiento simultáneo en las cuatro. Leer las etiquetas de forma conjunta, tal como ya lo hace mentalmente un ingeniero de fiabilidad con experiencia, es lo que diferencia una capa de decisión de otro panel de control.

Anomalías que importan en una línea

No toda desviación merece un ticket. La detección industrial de anomalías realmente útil en una línea busca una forma concreta: desviaciones que se acumulan con el tiempo y afectan a más de una señal.

La deriva de vibración es el ejemplo más claro. La firma de vibración de un rodamiento no da un salto; sube, a menudo durante semanas, mucho antes de superar un umbral de alarma fijo. La fluencia térmica en un motor o un reductor se comporta igual: una subida lenta que una inspección visual por turno pasará por alto por completo.

La incoherencia entre señales detecta fallos que un umbral de un solo canal no puede detectar por su propia naturaleza. Cuando el caudal, la presión y el consumo de potencia dejan de moverse juntos como dicta la física del proceso, algo ha cambiado en algún punto anterior, aunque ninguna etiqueta individual haya superado su límite. La deriva de energía por unidad es el mismo patrón aplicado al coste: una línea que consume más potencia por unidad de producción que su propia base histórica, sin un cambio de producción correspondiente, se está degradando en algún punto aunque nada haya saltado todavía.

Cada una de estas señales es detectable con los sensores ya instalados. Lo que requieren es vigilar la relación entre señales de forma continua, no escanear una sola etiqueta contra un límite fijo una vez por turno.

Filtrado causal en la planta de fábrica

Una anomalía entre señales en una etapa anterior tiende a disparar una decena de etiquetas más abajo. El caudal cae, la presión sube en la siguiente etapa, se dispara una alarma de temperatura en la etapa posterior, y un ingeniero de fiabilidad abre un registro de turno lleno de alertas que en realidad son un único evento.

El filtrado causal traza esa cadena hasta la causa raíz y la reduce a un único ticket: el rodamiento de la bomba, no los once síntomas de su fallo. Esa es la diferencia entre una causa priorizada y explicada, y una tormenta de alarmas que el equipo termina aprendiendo a ignorar.

Para que quede claro: Explore prioriza y explica la causa. No emite ni gestiona órdenes de trabajo, y no es un CMMS.

El resultado es un ticket priorizado, con la traza causal, que le dice a un ingeniero de fiabilidad qué está realmente mal y con qué grado de confianza lo afirma el sistema. Lo que sucede después, ya sea que el ticket termine en un CMMS existente, en un registro en papel o en un canal de Slack, es cosa de la planta. El trabajo de Explore termina en el diagnóstico, entregado de forma temprana y ya filtrado.

Mismo motor, señal distinta

El enfoque que entiende la física y que detecta un fallo de rodamiento en una línea de producción es el mismo motor que detecta una deriva de HVAC en un edificio comercial. Ambos son casos de vigilar múltiples señales correlacionadas en busca de un patrón que un umbral de una sola etiqueta pasaría por alto, y ambos necesitan suprimir el ruido posterior que genera una causa raíz real.

Lo que cambia entre una planta y un edificio es el conjunto de señales, no la lógica subyacente. El climatizador de un edificio produce una forma de telemetría distinta a la de un servomotor de una línea de estampación, pero la pregunta que responde la plataforma, cuál de estas desviaciones es un precursor real de fallo y qué la está causando en realidad, es idéntica. Nuestro artículo complementario sobre mantenimiento predictivo en edificios comerciales cubre el mismo motor aplicado a HVAC, enfriadoras y equipos de edificio.

Para los operadores de fabricación e industria pesada en particular, eso significa que una planta no necesita una implementación analítica a medida para conseguir esto. La misma plataforma que lee el BMS de un edificio lee el servidor OPC UA de una planta, y prioriza el resultado de la misma forma: por cuánto amenaza la continuidad operativa, no por lo fuerte que suena la alarma. Más sobre cómo esto se adapta específicamente a una planta de fabricación en nuestra página del sector de fabricación.

Preguntas frecuentes

¿Qué es el mantenimiento predictivo en la industria manufacturera? Es usar datos de sensores y de proceso, vibración, temperatura, consumo de corriente, caudal y señales similares, para detectar la degradación del equipo antes de que provoque una parada no planificada, en lugar de sustituir piezas según un calendario fijo o esperar a que se produzca el fallo.

¿Cuánto reduce realmente el tiempo de inactividad el mantenimiento predictivo? Las estimaciones varían según la planta y la madurez de partida, pero se suele citar en los estudios del sector una reducción en el rango del 30-50% para el tiempo de inactividad no planificado. Tómalo como una estimación orientativa, no como una cifra sobre la que construir un caso de negocio sin tus propios datos de referencia.

¿Añadir una capa de mantenimiento predictivo requiere sensores nuevos? Normalmente no. La mayoría de las plantas ya tienen las etiquetas de PLC, los puntos SCADA y las etiquetas OPC UA necesarios. La brecha suele estar en correlacionar las señales existentes de forma continua, no en la cobertura de sensores.

¿Qué es OPC UA y por qué importa aquí? OPC UA es un estándar de comunicación industrial neutral respecto al fabricante que expone los datos de proceso de PLC y sistemas SCADA de forma coherente. Es lo que permite que una capa de decisión como Explore lea telemetría de equipos de distintos fabricantes sin una integración a medida por máquina. Consulta nuestra entrada del glosario para el detalle a nivel de protocolo.

¿Es esto lo mismo que un CMMS? No. Un CMMS gestiona las órdenes de trabajo y los calendarios de mantenimiento. Explore prioriza y explica las anomalías en tus datos de proceso. No emite ni gestiona órdenes de trabajo. Ambos son complementarios, no categorías que compiten entre sí.

¿Explore controla algún equipo o escribe en el PLC? No. Explore lee la telemetría de proceso en modo solo lectura, a través de OPC UA, Modbus o la API de un fabricante de PLC. Nunca escribe un punto de consigna ni se sitúa dentro del bucle de control.

¿Qué tipos de fallos se detectan más pronto? Los modos de fallo que se construyen gradualmente a través de señales correlacionadas, el desgaste de rodamientos, la fluencia térmica en motores y reductores, y la incoherencia entre señales, suelen aparecer en los datos semanas antes de que un umbral fijo se dispararía. Los fallos mecánicos súbitos sin una firma gradual son más difíciles de predecir solo a partir de la telemetría.

¿En qué se diferencia esto de un programa estándar de monitorización de vibración? La monitorización de vibración por sí sola vigila una sola clase de señal. Explore correlaciona la vibración junto con el consumo de corriente, la temperatura, el caudal y otras etiquetas de proceso, lo que detecta modos de fallo que un programa basado solo en vibración pasa por alto y suprime la tormenta de alarmas posterior que genera una única causa raíz.

¿Listo para verlo con tus propios datos?

Míralo con una muestra de tus datos de proceso, con un ingeniero senior en la llamada. Trae una exportación de tus etiquetas OPC UA o SCADA y repasaremos cómo se ve una cola priorizada y con traza causal frente a tu equipo real. De 30 a 60 minutos, sin compromiso en ningún sentido. Hablemos de ello.