Por qué sus alertas de umbral omiten el 60 % de los fallos — y qué puede hacer al respecto

La llamada de las 3 de la madrugada

Son las 3:14 cuando suena su teléfono. La bomba 7A del circuito de refrigeración acaba de bloquearse. La línea de producción 3 está parada. El equipo de mantenimiento se moviliza. Alguien abre el panel de monitorización — y todas las alarmas estaban en verde justo hasta el fallo catastrófico.

¿Cómo es posible? Usted invirtió meses en configurar la monitorización de condición. Tiene sensores de vibración, sondas de temperatura y transformadores de corriente. Estableció umbrales según ISO 10816. Todo parecía estar bien.

Pero no lo estaba. La bomba llevaba tres semanas degradándose lentamente. Sus umbrales simplemente no podían verlo.

El problema de los umbrales: reglas estáticas en un mundo dinámico

El escenario típico: instala usted un sensor de vibración en el rodamiento de una bomba y configura una alarma a 4,5 mm/s RMS basándose en la norma ISO o en el manual del fabricante. Si la vibración supera ese valor, recibe una alerta.

Esto funciona — a veces. Detecta los fallos repentinos en los que un rodamiento pasa de normal a catastrófico en pocas horas. Pero la mayoría de los fallos industriales no se producen de esa manera.

Considere este patrón real: el rodamiento de una bomba comienza con una vibración de referencia de 1,8 mm/s. A lo largo de seis semanas, asciende a 2,1, luego a 2,4, después a 2,9. Al mismo tiempo, la temperatura del rodamiento sube 3 grados Celsius y la corriente del motor se vuelve ligeramente irregular durante el arranque. Cada señal está bien dentro de su umbral individual. No se activa ninguna alarma. Luego, un martes, algo cambia: la vibración salta a 6,2 mm/s y el rodamiento falla en cuestión de horas.

El fallo era predecible. Los umbrales no lo detectaron porque miraban lo que no debían: valores absolutos en lugar de patrones.

Segundo escenario: el ventilador controlado por variador de frecuencia

He aquí otro patrón que los umbrales pasan por alto de forma sistemática. Un variador de frecuencia (VFD) controla un ventilador de tratamiento de aire, variando la velocidad entre 600 y 1.800 RPM según la demanda del proceso. El rodamiento del ventilador está desarrollando un defecto en la pista exterior.

El reto: la amplitud de vibración es directamente proporcional al cuadrado de la velocidad. A 1.800 RPM, el rodamiento muestra 3,2 mm/s — dentro de la zona «satisfactoria» de ISO 10816. A 600 RPM, el mismo rodamiento muestra 0,4 mm/s — apenas por encima del nivel de ruido. Un umbral fijo configurado para velocidad máxima nunca se activará a velocidad parcial, y un umbral configurado para velocidad parcial generará falsas alarmas constantemente a velocidad máxima.

Mientras tanto, el defecto avanza. La vibración del rodamiento a una velocidad determinada aumenta 0,1 mm/s por semana. Pero dado que la velocidad de operación cambia cada pocos minutos, la tendencia es invisible en la serie temporal sin procesar. Solo un modelo que normalice la vibración por velocidad de operación — que aprenda que «2,1 mm/s a 900 RPM es anormal aunque 3,0 mm/s a 1.800 RPM sea normal» — puede detectar esto.

Los equipos controlados por variadores de frecuencia representan una proporción creciente de los activos industriales (se estima que entre el 30 y el 40 % de los motores en instalaciones modernas), y todos ellos presentan el mismo problema de referencia dependiente de la velocidad que los umbrales estáticos no pueden resolver.

Comparativa de métodos de detección

No todos los enfoques de detección son igual de eficaces ante todos los tipos de fallo. A continuación se muestra el rendimiento de los métodos más habituales:

| Método de detección | Fallo repentino | Desgaste gradual de rodamiento | Degradación dependiente de velocidad | Patrón multisensor | Tiempo de anticipación típico | |---|---|---|---|---|---| | Umbral estático | 70 % de detección | 20-30 % de detección | < 10 % de detección | No aplicable | Horas | | Análisis de envolvente | 50 % de detección | 60-70 % de detección | 40 % de detección | No aplicable | Días a semanas | | LSTM Autoencoder | 85 % de detección | 85-90 % de detección | 80-85 % de detección | > 90 % de detección | 2-4 semanas | | TranAD (Transformer) | 90 % de detección | 90-95 % de detección | 90 % de detección | > 95 % de detección | 2-6 semanas |

La conclusión clave: los métodos basados en umbrales tienen un techo impuesto por su arquitectura de sensor único y referencia fija. Los métodos de ML mejoran con el volumen de datos y capturan los patrones multisensor y dependientes de la velocidad que representan la mayoría de los fallos reales.

Por qué las máquinas no fallan según las reglas

Los equipos industriales son complejos. Tres factores hacen que los umbrales estáticos sean fundamentalmente inadecuados para detectar la mayoría de los fallos:

El desgaste gradual es invisible para los límites fijos. Un rodamiento no pasa de «bien» a «roto». Se degrada a lo largo de semanas o meses. Las primeras señales son mínimas — un aumento de 0,3 mm/s en la vibración, un desplazamiento de medio grado en la temperatura, un cambio sutil en los armónicos espectrales. Cada señal por separado es ruido. Juntas, forman una señal clara.

Los patrones de fallo abarcan múltiples sensores. Una bomba no falla en una sola dimensión. Un defecto en la pista exterior se manifiesta en vibración, temperatura, consumo de corriente y, en ocasiones, caudal — de forma simultánea, pero sutil. Ningún umbral individual captura un patrón multidimensional. Sería necesario escribir cientos de reglas cruzadas entre sensores, y aun así se pasarían por alto las que no se habían contemplado.

Lo «normal» cambia con las condiciones. Un motor funcionando a 1.800 RPM un frío lunes por la mañana tiene un «normal» distinto al del mismo motor a 3.600 RPM una tarde de viernes calurosa bajo carga máxima. Las variaciones estacionales de temperatura, los cambios de producto y las variaciones de carga desplazan la referencia. Un umbral fijo genera falsas alarmas constantemente o está configurado tan alto que deja pasar los problemas reales.

Los datos del sector lo confirman: estudios de McKinsey y diversas encuestas de ingeniería de fiabilidad sugieren que la monitorización tradicional basada en umbrales detecta menos de la mitad de los fallos evitables — muchas estimaciones sitúan la cifra en torno al 40 %. El resto aparece como una sorpresa o lo detecta un técnico que casualmente nota que algo no funcionaba bien.

Qué detecta realmente la detección basada en IA

La alternativa no consiste en añadir más reglas. Es un sistema que aprende cómo es lo «normal» para cada máquina, bajo sus condiciones de operación específicas, y señala cuándo la realidad empieza a desviarse de esa referencia aprendida.

Esto es exactamente lo que hacen los LSTM Autoencoder. Una red LSTM (Long Short-Term Memory) es un tipo de modelo de IA especialmente eficaz para aprender patrones en datos de series temporales — el tipo de datos que producen sus sensores. Un autoencoder se entrena para reconstruir el comportamiento normal. Cuando la máquina está en buen estado, la reconstrucción del modelo se ajusta estrechamente a la realidad. Cuando algo empieza a ir mal, el error de reconstrucción se dispara — incluso si todos los sensores individuales siguen dentro de su umbral.

Piénselo así: usted conoce el sonido del motor de su automóvil. No puede escribir el espectro de frecuencias exacto que define lo «normal», pero nota de inmediato cuando algo suena diferente. Un LSTM Autoencoder hace lo mismo con los datos de los sensores — pero a través de 10 o 20 sensores simultáneamente, las 24 horas del día, sin cansarse.

El modelo aprende por máquina. El «normal» de la bomba 7A es diferente al «normal» de la bomba 7B, aunque sean del mismo modelo. Se adapta a la carga, la velocidad y las condiciones ambientales. Y detecta el tipo de degradación lenta y multisensor que los umbrales sencillamente no pueden capturar.

La brecha de explicabilidad

Aquí es donde la mayoría de las soluciones de IA fracasan. El modelo detecta una anomalía y lanza una alerta: «Bomba 7A — anomalía detectada, confianza 94 %».

Muy bien. ¿Y ahora qué?

Su ingeniero de fiabilidad recibe esa alerta y formula la pregunta obvia: ¿por qué? ¿Qué sensor? ¿Qué ha cambiado? ¿Es un problema de rodamiento o de sello? ¿Debo programar una parada o simplemente vigilarlo?

Si la respuesta es «el modelo lo ha dicho», esa alerta va a la papelera. Y con razón — ningún ingeniero con experiencia va a detener una bomba crítica de producción basándose en un número proveniente de una caja negra.

Aquí es donde la atribución de características cambia las reglas del juego. Los modelos de Prevly informan exactamente cuánto contribuyó cada característica de entrada (cada lectura de sensor, cada métrica calculada) a la decisión — qué señales impulsaron la alerta y en qué medida. (Para el modelo RUL de gradiente potenciado se emplea SHAP; para los modelos de aprendizaje profundo de anomalías y fallos se emplea Integrated Gradients — ambos producen el mismo tipo de desglose de contribución por característica.)

14 días de advertencia — con evidencia

He aquí un ejemplo concreto de detección de un defecto en la pista exterior de un rodamiento. El sistema basado en IA detecta una anomalía en una bomba centrífuga 14 días antes de que el rodamiento hubiera fallado. La alerta no se limita a decir «anomalía» — incluye la atribución de características:

• vibration_x_rms: +0,34 — el contribuyente dominante, vibración elevada en la dirección radial
• temperature_delta: +0,21 — la temperatura del rodamiento sube más rápido que la temperatura de la carcasa
• current_kurtosis: +0,12 — picos sutiles en la corriente del motor que indican resistencia mecánica intermitente

El ingeniero lee esto y de inmediato tiene una hipótesis: vibración radial elevada más aumento de temperatura más picos de corriente — es un patrón clásico de defecto en la pista exterior. Programa una inspección durante la próxima parada planificada, confirma el defecto con ultrasonidos y sustituye el rodamiento en una ventana de 2 horas, en lugar de tener que afrontar un fallo catastrófico y 18 horas de tiempo de inactividad no planificado.

¿El sistema de umbrales? Todavía en verde. Habría permanecido en verde 12 días más.

De reactivo a predictivo

El paso de las alertas de umbral a la detección de anomalías basada en IA no implica reemplazar su infraestructura de monitorización. Sus sensores, sistemas historian y SCADA permanecen exactamente donde están. La diferencia está en lo que se superpone: en lugar de reglas estáticas, dispone de un sistema que aprende, se adapta y explica.

La transición no se produce de la noche a la mañana, y no tiene por qué ser así. La mayoría de las plantas comienzan aplicando la detección basada en ML a sus 10-20 activos más críticos — aquellos en los que el tiempo de inactividad no planificado tiene mayor coste. Las alertas de umbral existentes permanecen como red de seguridad. En 2-4 semanas, el modelo de ML aprende los patrones de operación normales de cada máquina. En 2-3 meses, dispone de suficientes datos para comparar las tasas de detección: ¿cuántas anomalías detectó el modelo de ML que los umbrales pasaron por alto? En nuestra experiencia, la respuesta es sistemáticamente 3-5 veces más detecciones con un 60-80 % menos de falsas alarmas.

La economía es clara. Una sola parada no planificada evitada en una línea de producción crítica — detectada 2 semanas antes en lugar de a las 3 de la madrugada — suele pagar un año de monitorización predictiva en toda la instalación. La pregunta no es si la detección basada en IA funciona mejor que los umbrales. La pregunta es cuántos fallos está usted dispuesto a pasar por alto mientras toma la decisión.

Para los responsables de planta, esto se traduce directamente en cifras: menos paradas no planificadas, menor inventario de repuestos (porque usted sabe qué va a fallar antes de que falle) y una planificación del mantenimiento más eficiente. Para los ingenieros de fiabilidad, significa dedicar menos tiempo a perseguir falsas alarmas y más tiempo a los fallos que realmente importan — con los datos que respaldan cada decisión.

Compruébelo con sus propios datos

Prevly lleva la detección de anomalías basada en IA con explicabilidad por atribución de características integrada a los equipos industriales — sin necesidad de un equipo de ciencia de datos. Conecte sus datos de sensores y en pocos días verá lo que las alertas de umbral están omitiendo.

Comience su prueba gratuita en prevly.org y descubra lo que sus máquinas llevan tiempo intentando comunicarle.

Lecturas relacionadas: Cómo SHAP explica una predicción · La predicción de RUL explicada · De los sensores a las predicciones