Contenido
Detección de anomalías de vibración en el borde: cómo funciona
Detección de anomalías de vibración en el borde: aprender lo normal, autoencoders y features, umbrales y falsas alarmas, y qué cambia en el dispositivo.
Una bomba en una planta de Monterrey trabaja dos años sin fallar, lo cual es bueno para la planta y malo para quien quiere entrenar un clasificador de fallas: no hay ejemplos de la falla. Por eso casi todo el monitoreo de vibración con aprendizaje automático se plantea como detección de anomalías y no como clasificación. El modelo aprende cómo es la vibración normal de esa máquina, y cualquier cosa lo bastante distinta levanta una bandera. Hacer detección de anomalías de vibración en el borde, en un microcontrolador junto al sensor, le suma límites de memoria, energía y ancho de banda al problema. Aquí te explico cómo funciona el enfoque, qué muestran los benchmarks públicos sobre su exactitud y dónde falla en la práctica.
Puntos clave
- La detección de anomalías se entrena solo con datos normales, lo que encaja con máquinas que casi no fallan. Marca “distinto”, no “descompuesto”.
- Una base común es un autoencoder entrenado para reconstruir features normales; un error de reconstrucción alto es el puntaje de anomalía.
- Los benchmarks públicos muestran que el problema es difícil: el autoencoder base de DCASE 2020 obtuvo entre 66 y 85 % de AUC en seis tipos de máquina.
- Los umbrales deciden las falsas alarmas. Con una decisión cada 10 s, una tasa de falsos positivos por ventana de 0.1 % da unas 8.6 falsas alarmas al día por sensor, a menos que se combinen decisiones.
- Los cambios de velocidad, carga o montaje parecen anomalías. El modelo tiene que ver todo el rango normal de operación de la máquina, o recibir la condición como entrada.
El problema: no hay fallas de las cuales aprender
Los clasificadores supervisados necesitan ejemplos etiquetados de cada falla: defecto en pista interior, en pista exterior, desbalance, desalineación. Las máquinas industriales casi nunca los dan, y los conjuntos de datos de fallas de laboratorio no se transfieren fácil. El estudio de referencia de Smith y Randall de 2015 en Mechanical Systems and Signal Processing aplicó tres técnicas de diagnóstico establecidas a todo el conjunto de datos de rodamientos de la Universidad Case Western Reserve, uno de los más usados para probar diagnósticos de rodamientos, e hizo recomendaciones sobre cómo usar esos datos y cómo generar futuros datos de referencia. Un modelo que aprende muy bien ese conjunto aprendió un banco de pruebas en particular.
La detección de anomalías esquiva esa escasez. La revisión de Chandola, Banerjee y Kumar en ACM Computing Surveys define el problema general como encontrar patrones que no se ajustan al comportamiento esperado, y ordena los métodos según si necesitan anomalías etiquetadas. El caso semisupervisado, con etiquetas solo para lo normal, es el que corresponde a una máquina en operación.
Cómo funciona la detección de anomalías en el borde
Primero las features: descripciones compactas de una ventana
La vibración cruda a varios kilohertz es demasiado dato para alimentar directo a un modelo pequeño. Las features típicas resumen una ventana: RMS por bandas de frecuencia, magnitudes de FFT agrupadas en escala logarítmica o mel, espectros de envolvente alrededor de una banda de resonancia del rodamiento, curtosis o factor de cresta para lo impulsivo. La tarea de condición de máquinas de DCASE 2020, construida sobre los conjuntos de sonido ToyADMOS y MIMII, usó espectrogramas log-mel con 128 bandas y cuadros de 64 ms, concatenando cinco cuadros en una entrada de 640 valores. Los sistemas de vibración usan la misma idea con features adecuadas a la mecánica de la máquina.
Un modelo de lo normal: el autoencoder base
Un autoencoder es una red que comprime su entrada a través de un cuello de botella estrecho y trata de reconstruirla. Entrenado solo con ventanas normales, aprende a reconstruir bien lo normal y mal todo lo desconocido. El error de reconstrucción se vuelve el puntaje de anomalía.
El sistema base de DCASE 2020 es una referencia útil y documentada: capas totalmente conectadas de 128 unidades alrededor de un cuello de botella de 8, entrenadas solo con sonidos normales, que califican cada clip por su error cuadrático medio de reconstrucción. El benchmark MLPerf Tiny adoptó después el mismo tipo de autoencoder totalmente conectado para su tarea de detección de anomalías, con un modelo de referencia de unos 270 KB, porque corre en microcontroladores.
Lo que muestran los benchmarks
La descripción de la tarea 2 de DCASE 2020 de Koizumi y sus colegas reporta que el reto recibió 117 envíos de 40 equipos, y los resultados del sistema base muestran qué tan difícil es el problema. Promediado en diez corridas sobre el conjunto de desarrollo, el AUC del autoencoder fue de cerca de 66 % (ventilador) a cerca de 85 % (riel deslizante), con un AUC parcial a tasas bajas de falsos positivos de entre 51 y 68 %. Muchos envíos superaron por mucho a la base, pero lo importante es la dispersión entre tipos de máquina: un método que funciona en una máquina puede ser mediocre en otra.
Los autores del conjunto MIMII, Purohit y sus colegas, grabaron sonidos normales y anómalos de válvulas, bombas, ventiladores y rieles deslizantes en ambientes reales de fábrica, con anomalías como contaminación, fugas, desbalance rotatorio y daño en el riel. El ruido real de fábrica es parte del problema, no una molestia que se filtra.
Umbrales y falsas alarmas
Un puntaje de anomalía necesita un umbral, y el umbral fija la tasa de falsas alarmas. La aritmética no perdona. Un ejemplo ilustrativo: un sensor que toma una decisión cada 10 segundos toma 8,640 decisiones al día. Si el umbral está en el percentil 99.9 de los puntajes normales, cada ventana tiene 0.1 % de probabilidad de dar un falso positivo, y el sensor levanta unas 8.6 falsas alarmas al día. Con 50 sensores son más de 400.
Combinar decisiones ayuda muchísimo. Pedir tres ventanas seguidas arriba del umbral, y suponer que los errores de las ventanas son independientes (en la realidad están correlacionados, así que el beneficio real es menor), baja la probabilidad de falso positivo a una en mil millones y las falsas alarmas esperadas a cerca de una cada 300 años por sensor. Por eso el AUC parcial a tasas bajas de falsos positivos, que DCASE reporta junto al AUC, le importa más a mantenimiento que el AUC total.
Las condiciones de operación parecen fallas
Una bomba a otra velocidad, un ventilador de una torre de enfriamiento en Hermosillo con otra carga o un sensor que se volvió a montar en otro tornillo producen una firma de vibración distinta. Para un detector entrenado con una sola condición, eso es una anomalía. Ediciones posteriores de DCASE atacaron explícitamente este tipo de cambio de dominio. En la práctica, los datos de entrenamiento tienen que cubrir el rango normal de operación de la máquina, o hay que darle al modelo la condición de operación (velocidad, carga) como entrada, o tener un modelo por condición.
Qué cambia en el dispositivo
En el borde, el pipeline es el mismo pero los presupuestos son estrechos. Las features se calculan en punto fijo o con una FFT pequeña en el microcontrolador. El autoencoder se cuantiza a int8 y corre con un runtime embebido. Solo se transmiten puntajes, o alarmas con un fragmento de los datos crudos, lo que ahorra ancho de banda y energía frente a mandar la vibración cruda. Muchas veces el umbral se aprende en el propio dispositivo durante un periodo de puesta en marcha con operación que se sabe normal, lo que adapta el modelo al montaje y al ambiente de esa máquina.
Enfoques de detección de anomalías de vibración, comparados
| Enfoque | ¿Necesita ejemplos de fallas? | Fortaleza | Debilidad | Costo en el borde |
|---|---|---|---|---|
| Umbral sobre RMS o velocidad global | No | Sencillo, se relaciona con normas de severidad | No ve fallas incipientes; sensible a la carga | Muy bajo |
| Energías por banda o features de envolvente + límites estadísticos | No | Interpretable; bueno para frecuencias de rodamiento conocidas | Requiere conocimiento mecánico de cada máquina | Bajo |
| Autoencoder sobre features espectrales | No (solo normales) | Aprende patrones normales complejos | Umbral y cambio de dominio; necesita datos normales de todas las condiciones | Moderado (modelo int8) |
| Clasificador supervisado de fallas | Sí | Le pone nombre a la falla | Pocos datos de fallas; se transfiere mal entre máquinas | Moderado |
| Híbrido: anomalías en el dispositivo, diagnóstico por un experto o en la nube | En parte | Llegan menos falsas alarmas a las personas; fragmentos crudos para diagnosticar | Sistema más complejo | Moderado |
Qué hacer
Junta datos normales de todo el rango de operación
Graba la máquina en cada velocidad, carga y temporada normal que puedas antes de entrenar. Los huecos en los datos normales se vuelven falsas alarmas.
Empieza con features interpretables
El RMS por bandas, la energía de envolvente alrededor de la resonancia del rodamiento y la curtosis son baratos en un microcontrolador y fáciles de revisar para un ingeniero de mantenimiento. Agrega un modelo aprendido cuando no alcancen.
Fija los umbrales a partir del presupuesto de falsas alarmas
Decide cuántas falsas alarmas al mes tolera el equipo de mantenimiento, conviértelo a una tasa por ventana según tu intervalo de decisión y ajusta el umbral y la regla de persistencia (k de n ventanas) para cumplirla.
Dale al modelo la condición de operación
Si la velocidad o la carga varían, mídelas y agrégalas como entrada del modelo o entrena modelos separados por condición.
Valida con las anomalías que puedas conseguir
Fallas sembradas en un banco de pruebas, fallas históricas o cambios deliberados (una masa de desbalance agregada) son mejores que no validar nada. Reporta el AUC y la tasa de falsos positivos con el umbral elegido.
Qué no hacer
No reportes un AUC alto de una máquina como prueba de que el método funciona en otra. Y no fijes el umbral con el conjunto de prueba; fíjalo con datos normales y el presupuesto de falsas alarmas.
Cómo ponerlo en práctica
Si tienes una hora
Toma una semana de puntajes normales de un sensor, calcula el umbral en el percentil que elegiste y cuenta cuántas ventanas habrían dado alarma. Multiplica por tu número de sensores.
Si tienes un sprint
Graba la operación normal en todo el rango de velocidad y carga de la máquina, entrena un autoencoder pequeño con features por banda, cuantízalo y córrelo en el dispositivo una semana. Registra cada alarma y revisa cada una con un ingeniero de mantenimiento.
Si quieres que dure toda la vida del producto
Vuelve a aprender la línea base normal después de cada mantenimiento, remontaje o cambio de proceso, y guarda un registro de cada anomalía confirmada con sus datos crudos. Con el tiempo, esos registros se convierten en los datos de fallas etiquetados que el sistema no tenía al principio.
La pregunta que debes hacerte: “¿Cuántas falsas alarmas al mes va a levantar este sistema con todos mis sensores, y el equipo de mantenimiento todavía le va a creer después del primer mes?”
Preguntas frecuentes
¿Qué es la detección de anomalías de vibración?
Es monitorear la vibración de una máquina con un modelo de su comportamiento normal y marcar las ventanas que se alejan bastante de lo normal. A diferencia de la clasificación de fallas, no necesita ejemplos de fallas, así que sirve para máquinas que casi no fallan.
¿Cómo detecta anomalías un autoencoder?
Un autoencoder se entrena para comprimir y reconstruir datos normales. Reconstruye bien las entradas normales y mal las desconocidas, así que el error de reconstrucción sirve como puntaje de anomalía. Un umbral sobre ese puntaje decide si se levanta una alarma.
¿Por qué mi detector de anomalías da tantas falsas alarmas?
Normalmente porque el umbral es demasiado bajo para el número de decisiones al día, porque una sola ventana dispara la alarma sin una regla de persistencia, o porque los cambios normales de operación (velocidad, carga, remontaje) no estaban en los datos de entrenamiento.
¿La detección de anomalías puede correr en un microcontrolador?
Sí. Las features compactas y un autoencoder int8 pequeño caben en muchos microcontroladores; el benchmark MLPerf Tiny incluye una tarea de detección de anomalías con un autoencoder totalmente conectado como modelo de referencia. Correr en el borde significa que solo hay que transmitir puntajes o alarmas.
¿Cómo se evalúa un detector de anomalías sin datos de fallas?
Usa las anomalías disponibles (fallas sembradas, fallas históricas, cambios deliberados como una masa de desbalance), reporta el AUC y la tasa de falsos positivos con el umbral de operación, y corre el sistema en operación normal el tiempo suficiente para medir la tasa real de falsas alarmas.
Lecturas relacionadas: especificaciones de acelerómetros para vibración, datos de vibración para mantenimiento predictivo y del sensor a la inferencia embebida.
Fuentes
- Koizumi, Y., Kawaguchi, Y., Imoto, K., et al. (2020). “Description and Discussion on DCASE2020 Challenge Task 2: Unsupervised Anomalous Sound Detection for Machine Condition Monitoring.” Proceedings of the DCASE 2020 Workshop. arXiv:2006.05822. https://arxiv.org/abs/2006.05822
- DCASE Community (2020). “Unsupervised Detection of Anomalous Sounds for Machine Condition Monitoring” (descripción de la tarea 2 y sistema base). https://dcase.community/challenge2020/task-unsupervised-detection-of-anomalous-sounds
- Purohit, H., Tanabe, R., Ichige, K., Endo, T., Nikaido, Y., Suefusa, K., y Kawaguchi, Y. (2019). “MIMII Dataset: Sound Dataset for Malfunctioning Industrial Machine Investigation and Inspection.” arXiv:1909.09347. https://arxiv.org/abs/1909.09347
- Chandola, V., Banerjee, A., y Kumar, V. (2009). “Anomaly Detection: A Survey.” ACM Computing Surveys, 41(3), 1–58. https://doi.org/10.1145/1541880.1541882
- Smith, W. A., y Randall, R. B. (2015). “Rolling Element Bearing Diagnostics Using the Case Western Reserve University Data: A Benchmark Study.” Mechanical Systems and Signal Processing, 64–65, 100–131. https://doi.org/10.1016/j.ymssp.2015.04.021
- Banbury, C., Reddi, V. J., Torelli, P., Holleman, J., et al. (2021). “MLPerf Tiny Benchmark.” Proceedings of the Neural Information Processing Systems Track on Datasets and Benchmarks. arXiv:2106.07597. https://arxiv.org/abs/2106.07597



