Como sabe, en Berger-Levrault no nos asustan los retos, al contrario, ¡los aceptamos con gusto!
Rendimiento de los activos 4.0 es una conferencia y exposición virtuales para aprender cómo las nuevas tecnologías 4.0 y los fundamentos de las operaciones, el mantenimiento y la gestión de activos se refuerzan mutuamente para mejorar la fiabilidad de los equipos y el rendimiento de los costes en las industrias de uso intensivo de activos. Esta conferencia y exposición virtual tendrá lugar del 15 al 17 de septiembre de 2020.
Antes de la conferencia, Rendimiento de los activos 4.0 ha organizado 3 Hackathons sobre temas de mantenimiento recientes.
CARL Software participó en uno de los Hackathons, cuyo tema es :
“Fluvius: predicción de fallos basada en datos de sensores y humedad.“
Tras su presentación, CARL Software fue uno de los finalistas del reto.
El contexto
1. Sistema actual:
Actualmente, las subestaciones eléctricas están equipadas con sensores de humedad y temperatura. La condensación (resultado de la alta humedad y la baja temperatura) puede acortar la vida útil de los equipos eléctricos, por lo que es necesario detectar fallos en el sistema de calefacción y el agua en los sótanos.
En la actualidad, esta detección se realiza mediante un umbral fijo de temperatura y humedad. Este umbral puede ajustarse manualmente y, por tanto, no existe un sistema inteligente que utilice datos históricos o contextuales para mejorar el umbral.
Sin embargo, el sistema es propenso a un alto índice de falsas alarmas, lo que significa que hay muchas alertas y eventualmente daños reales, lo que tiende a hacernos ignorarlas. Pero, si se reducen los umbrales para disminuir las alertas, pueden perderse fallos.
En conclusión, en ambos casos, el sistema de alerta queda obsoleto.
2.Las mejoras deseadas
El objetivo principal del proyecto es mejorar el sistema de alerta. Se sugiere encarecidamente hacerlo definiendo umbrales más inteligentes basados en datos históricos (observaciones anteriores) y/o datos contextuales (meteorología, tipo de edificio, etc.). Hay que evitar las falsas alarmas, o al menos detectarlas para anular la alerta. La entrega deseada no es una solución completa, sino una lista de pasos de procesamiento de datos para que el umbral sea más inteligente.
Pudimos detectar diferentes tipos de fenómenos en los datos, según el sensor. Tras los análisis, pudimos reflexionar sobre las sugerencias.
Nuestro enfoque
- Previsión de series temporales para hacer saltar las alarmas:
Gracias a la aplicación de Modelos ARIMApodemos prever los próximos valores utilizando los de la Unión Europea.
Esto nos permite detectar fallos en el sistema de calefacción.
Sin embargo, este método consiste en cambiar la distribución de los datos.
Predicciones para la misma distribución con la que se aprendió el modelo 
Predicciones para una distribución diferente (valores más altos)
- Nivele los datos restando la media móvil:
Para evitar el problema mencionado anteriormente, podemos restar su media móvil de la serie temporal.
Esto es sencillo, pero esta propuesta puede carecer de precisión en lo que respecta a los cambios.
Conjunto de datos nivelados, no hay más cambios visibles en la amplitud 
Predicción en un punto de cambio previo
- Adaptar el modelo con la detección de cambios:
Una forma más sofisticada de abordar el problema mencionado es detectar cambios bruscos en la distribución y entrenar un nuevo modelo cada vez que se produce un cambio. Así se evita que se produzcan falsas alarmas cuando
los cambios se producen, pero es posible que los fallos detectados anteriormente pasen a ser invisibles. De ahí que sea necesario el uso de los diferentes métodos en conjunto.
y resultados esperados pero no deseados (en rojo)
- Mejorar los umbrales con la media móvil:
Como ahora podemos detectar los fallos, los umbrales pueden adaptarse utilizando la media móvil como base. De este modo, se producirán muchas menos alarmas.
- Detectar los fallos de los sensores con el análisis multivariante:
Queremos utilizar las correlaciones entre las variables para detectar sensores defectuosos. En efecto, cuando un sensor genera valores incorrectos, esto puede desencadenar falsas alarmas. Sin embargo, si sólo se ve afectada una variable, significa que el sensor está probablemente defectuoso, y podemos evitar que se dispare una alerta por fallo.
Resultado de este reto
Hemos decidido responder a este reto con una lista de sugerencias, pero nos hemos centrado principalmente en el uso de Modelos ARIMA para predecir correctamente la serie temporal dada. Sin embargo, nuestra experiencia nos ha permitido sugerir otras posibilidades que hay que explorar para mejorar el sistema de alerta.
En nuestra opinión, las distintas sugerencias formuladas deberían utilizarse conjuntamente y adaptarse a cada estación. El objetivo es que los usuarios reciban alarmas de diferentes fuentes con la posibilidad de :
- Desactivar los que no son útiles,
- Dé prioridad a los más interesantes,
- Crúzalos para generar otros nuevos (por ejemplo ALARMA_3 = ALARMA_1 Y ALARMA_2 o ALARMA_6 = ALARMA_4 NI (ALARMA_5 Y ALARMA_3)),
- Ajuste los parámetros de sus umbrales en función de la confianza en las otras alarmas.
También sería posible desarrollar una visualización de datos que permitiera a los usuarios jugar con los datos y las soluciones para experimentar con ellos en un campo de juego.
En cuanto a la sugerencia relativa a la actual estrategia de análisis, no vemos la necesidad de modificar el actual sistema de informes diarios.
Sin embargo, sería más práctico tener la misma estrategia de muestreo (es decir, el mismo periodo entre mediciones) para todos los sensores para aprovechar mejor las variables correlacionadas.
Anexos
ARIMA y SARIMA Los modelos son adaptaciones de Modelos ARMA. Los objetivos de estos últimos son hacer previsiones de series temporales (predecir el futuro observar con el único conocimiento de las observaciones pasadas). Se trata de algo parecido a la regresión lineal con el uso de datos pasados como predictores.
Un Modelo ARMA se compone de dos partes. La primera es su componente AR (autorregresivo), que define la relación entre una observación en el momento actual y las de momentos anteriores. La segunda es su componente MA (Moving Average), que define la relación entre una observación en el momento actual y los errores residuales del momento actual y de algunos momentos anteriores. Es importante señalar que, en teoría, un proceso debe ser estacionario para poder ser descrito estrictamente por una Modelo ARMA.
Sin embargo, la estacionariedad del proceso es difícil de obtener porque las series temporales tienen componentes no estacionarios (tendencia y estacionalidad). Todavía existen formas de transformar el proceso hasta que se pueda aceptar la estacionariedad.
El primero consiste en diferenciar la serie temporal para eliminar la tendencia. El primer orden de diferenciación aplica el operador 1-𝐿 al proceso, el segundo el operador(1-𝐿)2y el
𝑑-orden el operador (1-𝐿)𝑑, con 𝐿 el operador definido por 𝐿(𝑋𝑡)=𝑋𝑡-1 ((1-𝐿)(𝑋𝑡)=𝑋𝑡-𝑋𝑡-1). Si 𝑌𝑡=(1-𝐿)𝑑(𝑋𝑡) es un proceso 𝐴𝑅𝑀𝐴(𝑝,𝑞), entonces 𝑋𝑡 es un proceso 𝐴𝑅𝐼𝑀𝐴(𝑝, 𝑑, 𝑞).
La segunda es tener en cuenta también la estacionalidad con un proceso 𝑆𝐴𝑅𝐼𝑀𝐴(𝑝, 𝑑, 𝑞)×(𝑃, 𝐷, 𝑄)𝑠 donde el proceso extraído del 𝑌𝑡=𝑋𝑖+𝑠*𝑡, 𝑖∈⟦0, 𝑠-1⟧ es un proceso 𝐴𝑅𝐼𝑀𝐴(𝑃,𝐷,𝑄).
Explicación de los procesos SARIMA:
https://www.youtube.com/watch?v=YIoBRDueHKo
Aunque esté escrita para usuarios de Python, la siguiente guía es útil para entender cómo parametrizar un modelo ARIMA:
https://www.machinelearningplus.com/time-series/arima-model-time-series-forecasting-python/
Para más detallesno dude en leer el siguiente artículo:
Hackaton-Fluvius-2020
