Machine Learning a máxima velocidad: Mantenimiento Predictivo por cuatro meses

11 julio
Lyudmila Dezhkina, Solution Architect, DataArt
Machine Learning a máxima velocidad:  Mantenimiento Predictivo por cuatro meses
Durante los últimos meses, nuestro equipo estuvo trabajando en una Plataforma de Mantenimiento Predictivo, un sistema para predecir posibles errores y fallas en los equipos que utiliza #IoT y #MachineLearning (ML), además de trabajar con hardware y software. En este artículo contaré en detalle cómo construimos Serverless ML con la biblioteca Scikit-learn en AWS, cuáles fueron las dificultades que enfrentamos y qué herramientas nos ayudaron a ahorrar algo de tiempo. 

Antes, déjenme contarles un poco sobre mí mismo: llevo más de 12 años programando y, durante ese tiempo, participé en varios proyectos que incluyeron juegos, comercio electrónico, HighLoad y Big Data. En los últimos tres años, estuve involucrado puntualmente en proyectos relacionados con Machine Learning y Deep Learning.

Así es como se veían los requisitos del cliente en el comienzo.

Ahora, volviendo al proyecto: la entrevista con el cliente no fue fácil. Básicamente, hablamos sobre el aprendizaje automático y nos hicieron muchas preguntas sobre algoritmos y sobre nuestra experiencia personal específica en el tema. Siendo honesto, allí apareció el primer obstáculo: yo no tenía tanto conocimiento sobre una pieza de hardware que contenía el sistema, desafortunadamente.

El cliente nos dijo: "Miren, tenemos un transportador". Inmediatamente pensé en una cinta transportadora en la caja del supermercado y supuse que no era apta para un proyecto de ML. Pero rápidamente nos aclaró que se trataba de todo un centro de clasificación, con un área de 300 a 400 metros cuadrados, y muchas cintas. Lo que necesitaban era conectar los equipos entre sí: sensores, robots, etc. Esta es la ilustración clásica del concepto de "Revolución Industrial 4.0", en el que IoT y ML se unen.

Estoy convencido de que el Mantenimiento Predictivo crecerá durante al menos otros dos o tres años. Cada transportador se descompone en elementos: desde un robot o un motor que conduce la cinta, hasta un rodamiento separado. Si alguna de estas partes falla todo el sistema se detiene y, en algunos casos, ese tiempo de inactividad puede costar un millón y medio de dólares (¡sin exagerar!).

Uno de nuestros clientes se dedica al transporte de carga y logística; en su base, los robots descargan 40 camiones en 8 minutos. No puede haber demora: los autos deben ir y venir según un horario muy ajustado, y nadie puede reparar nada durante la descarga. Generalmente, en esta base, solo hay dos o tres personas con tablets. Pero también existe un mundo diferente, donde la mecánica se trabaja directamente a mano y sin computadoras.

Nuestro primer proyecto de prototipo fue pequeño y consistió en instalar unos 90 sensores. Todo salió bien… hasta que hubo que escalarlo. Para equipar la parte más chica del centro de clasificación real, se necesitaban al menos unos 550 sensores más.

PLC y sensores

El Controlador Lógico Programable (PLC, por sus siglas en inglés) es una pequeña computadora con un programa cíclico incorporado que se usa con más frecuencia para automatizar procesos. En realidad, ayuda a tomar lecturas de los sensores, como aceleración y velocidad, nivel de voltaje, vibración a lo largo de los ejes, temperatura (17 indicadores en nuestro caso), ente otros. Habiendo dicho todo esto, les aclaro que los sensores suelen estar equivocados. Aunque nuestro proyecto hoy tiene más de 8 meses, todavía tenemos nuestro propio laboratorio donde experimentamos con sensores, seleccionando los modelos más adecuados. Ahora, por ejemplo, estamos considerando la posibilidad de utilizar sensores ultrasónicos.

Personalmente, recién vi por primera vez el PLC cuando llegué a ver al cliente. Como desarrollador, nunca los había encontrado antes y fue bastante incómodo: en cuanto entablamos una conversación sobre motores de dos, tres y cuatro fases, comencé a perder el hilo de la charla. Aproximadamente el 80% de las palabras eran comprensibles, pero el significado general me esquivó obstinadamente. En general, este es un problema grave cuyas raíces se encuentran en un umbral bastante alto para ingresar a la programación del PLC –por ejemplo, un microordenador en el cual se pueda realmente hacer algo, cuesta al menos USD 200-300-. La programación en sí es simple, y los problemas comienzan solo cuando el sensor está conectado a un transportador o motor real.

Un set standard de sensores "37 en 1".

Los sensores, como ustedes saben, son diferentes. Los más simples que logramos encontrar costaron alrededor de USD 18. Su característica principal era su "ancho de banda y resolución", es decir, cuántos datos transmitía el sensor por minuto. Desde mi propia experiencia puedo decir que, si un fabricante asegura -por ejemplo- 30 puntos de datos por minuto, es en realidad muy poco probable que su número sea en realidad más de 15. Y esto también tiene un problema grave: el tema está de moda y algunas empresas están tratando de capitalizarlo. Probamos sensores de USD 158, cuyo ancho de banda teóricamente nos permitiría simplemente tirar una parte de nuestro código, pero en la realidad resultaron ser un análogo absoluto de esos dispositivos de USD 18 cada uno.

Primera etapa: arreglar los sensores, recoger datos

En realidad, la primera fase del proyecto fue instalar el hardware, lo cual fue un proceso largo y tedioso. Esto también es una ciencia completa: según cómo se acople el sensor a un motor o una caja, los datos que finalmente recopile podrán ser diferentes. Tuvimos un caso en el que dos sensores idénticos estaban conectados uno dentro de la caja y el otro fuera. La lógica sugiere que, adentro, la temperatura debería ser más alta, pero los datos recopilados arrojaron lo contrario. Cuando el desarrollador llegó a la fábrica, vio que el sensor no estaba solo dentro la caja, sino que estaba ubicado directamente en el ventilador.

Esta ilustración muestra cómo los primeros datos ingresaron al sistema. Tenemos una pasarela, hay PLC y sensores asociados. El equipo de efectivo generalmente funciona en tarjetas móviles y todos los datos se transmiten a través de Internet móvil. Dado que uno de los centros de clasificación del cliente está ubicado en un área donde ocurren huracanes con frecuencia y la conexión podría perderse, acumulamos datos en la puerta de enlace hasta que se restaure.

Luego, utilizamos el servicio Greengrass de Amazon, que almacena datos en la nube (AWS). Una vez que los datos están allí, se activan varios eventos. Por ejemplo, tenemos uno para los datos sin procesar, que lo que hace es guardarlos en el sistema de archivos. Hay un "latido" para indicar el funcionamiento normal del sistema; hay un " submuestreo" que se utiliza para mostrar en la interfaz de usuario y para el procesamiento (el valor promedio, por ejemplo, por minuto para un indicador en particular). Es decir, además de los datos sin procesar, tenemos datos muestreados que se ven en las pantallas de los usuarios que monitorean el sistema.

Los datos sin procesar se almacenan en formato Parquet. Al principio elegimos JSON, luego probamos CSV, pero finalmente llegamos a la conclusión de que Parquet era el que satisfacía tanto al equipo de análisis como al equipo de desarrollo. La primera versión del sistema fue construida en DynamoDB. No quiero decir nada malo sobre esta base de datos, simplemente -tan pronto como tuvimos analistas (matemáticos que deben trabajar con datos), resultó que el lenguaje de consulta para DynamoDB era demasiado complicado para ellos. Por lo tanto, nos detuvimos en Athena, que es el editor de consultas en AWS. Para nosotros, sus ventajas son que le permite leer datos Parquet, escribir SQL y recopilar los resultados en un archivo CSV. Justo lo que necesita el equipo de analistas.

Segunda etapa: ¿Qué analizamos?

Entonces, de un pequeño objeto recolectamos aproximadamente 3 GB de datos en bruto; ahora sabemos mucho sobre temperatura, vibración y aceleración a lo largo de los ejes. Eso significa que llegó el momento de que nuestros matemáticos se unan para comprender cómo y qué intentamos predecir en base a esta información. El objetivo es minimizar el downtime del equipo.

La gente ingresa a esta planta de Coca-Cola solo cuando recibe una alerta de rotura, fuga de aceite o un charco en el piso. El costo de un robot comienza en USD 30.000, pero prácticamente toda la producción depende de ellos.

Unas 10.000 personas trabajan en seis fábricas de Tesla. Para una producción de tal escala, el equipo es bastante pequeño. Curiosamente, las plantas de Mercedes están automatizadas incluso en mayor medida. Está claro que todos los robots involucrados necesitan un control constante. Cuanto más caro es el robot, menos vibra su parte de trabajo. Con acciones simples, esto puede no ser decisivo, pero una operación más sutil con un cuello de botella requiere que se mantenga al mínimo. Por supuesto, el nivel de vibración de los autos caros debe ser monitoreado constantemente.

Servicios de ahorro de tiempo

Lanzamos la primera instalación en poco más de tres meses y, sinceramente, creo que fue bastante rápido.

Estos fueron los cinco puntos principales que nos permitieron ahorrar esfuerzos de los desarrolladores. Lo primero que nos permitió reducir el tiempo fue que la mayoría del sistema se basa en AWS, que se escala por sí solo. Tan pronto como el número de usuarios supera un determinado umbral, la escala automática se activa sin que nadie del equipo tenga que dedicarle tiempo.

Me gustaría recalcar algo: trabajamos con grandes cantidades de datos y, en la primera versión del sistema, teníamos pipelines para hacer copias de seguridad. Después de algún tiempo, la cantidad de datos se volvió demasiado grande y mantener copias de ellos se volvió demasiado costoso. Entonces, simplemente dejamos los datos sin procesar en el contenedor con acceso de solo lectura, prohibiendo su eliminación y rechazando hacer copias de seguridad.

Nuestro sistema implica una integración continua, por lo que el soporte del nuevo sitio y la nueva instalación no lleva mucho tiempo. Además, está claro que el tiempo real se basa en eventos, aunque existen dificultades debido a que algunos se activan dos veces o el sistema pierde el contacto, por ejemplo. debido a las condiciones climáticas. Finalmente, el cifrado de datos, requerido por el cliente, se realiza automáticamente en AWS, no lo hacemos nosotros.

Reunión con analistas

Recibimos el primer código en PDF junto con la solicitud de implementar este o aquel modelo. El momento en el que comenzamos a recibir código en un formato diferente a .ipynb fue alarmante. Pero el hecho es que los analistas son matemáticos que están lejos de la programación. Todas nuestras operaciones se realizan en la nube y no permitimos la descarga de datos. Eso nos empujó a probar la plataforma SageMaker.

SageMaker permite usar cerca de 80 algoritmos diferentes e incluye los siguientes frameworks: Caffe2, Mxnet, Gluon, TensorFlow, Pytorch, el kit de herramientas cognitivas de Microsoft. Actualmente utilizamos Keras + TensorFlow. Una cobertura tan amplia nos permite evitar limitar nuestro propio equipo analítico.

Durante los primeros tres o cuatro meses, todo el trabajo fue realizado por personas que usaban matemáticas simples; todavía no existía realmente ML. Parte del sistema se basa en leyes puramente matemáticas y está diseñado para datos estadísticos. Es decir, monitoreamos el nivel de temperatura promedio, y si vemos que se sale de la escala, se activarán las alertas.

Luego siguió el modelo de entrenamiento. Todo parecía fácil y simple… antes del inicio de la implementación.

Construir, entrenar, desplegar

Les contaré brevemente cómo salimos de la situación. Si miran la segunda columna, verán: recopilación de datos, procesamiento, limpieza, uso de bucket S3 y Glue para lanzar eventos y crear “particiones”. Tenemos todos los datos descompuestos en particiones para Atenea. Este también es un matiz importante, ya que Athena se construye sobre S3. En sí es muy barata, pero pagamos por leer los datos y obtenerlos desde S3, es decir que cada solicitud puede ser muy costosa. Por lo tanto, tenemos un gran sistema de particiones.

Tenemos un downsampler y Amazon EMR, que le permite recopilar datos rápidamente. Para la ingeniería de funciones en nuestra nube, todos los analistas pueden acceder a Jupyter Notebook y trabajar directamente en la nube.

Gracias a SageMaker, pudimos saltear la etapa de Training Clusters. Si no utilizáramos esta plataforma, tendríamos que crear clusters en Amazon, y algunos de los ingenieros de DevOps tendrían que vigilarlos. SageMaker, en cambio, nos permitió crear un clúster utilizando los parámetros del método en la imagen de Docker, solo especificando el número de instancias en el parámetro que deseábamos usar.

Luego, no tuvimos que escalarlo. Si queremos procesar un algoritmo grande o necesitamos calcular algo con urgencia, activamos la escala automática (todo depende de si quiere usar una CPU o una GPU). Además, todos nuestros modelos están encriptados. Los binarios que están en S3 también salen de la caja en SageMaker.

Despliegue del modelo

Estamos llegando al primer modelo, desplegado en el entorno. SageMaker permite guardar artefactos de modelo, pero en esta etapa tuvimos mucha controversia porque tiene su propio formato. Queríamos deshacernos de él y sus restricciones. Es por eso que nuestros modelos se almacenan en formato de pickle, de modo que si queremos podemos usar Keras, TensorFlow u otra cosa. De todas formas, utilizamos el primer modelo de SageMaker, tal como es, a través de la API nativa.

SageMaker facilita el trabajo en tres pasos más. Cada vez que intenta predecir algo, inicia algún proceso, proporciona los datos y obtiene los valores de predicción. Con esto, todo fue bien hasta que comenzamos a necesitar algoritmos personalizados.

Los analistas saben que tienen un CI y un repositorio. Allí hay una carpeta en donde deberían subirse tres archivos: Serve.py es un archivo que le permite a SageMaker elevar el servicio de Flask y comunicarse con SageMaker; Train.py es una clase con el método de tren, en el que tienen que poner todo lo que necesitan para un modelo; y Predict.py -con su ayuda elevan esta clase, dentro de la cual hay un método. Tener acceso a él les permite abrir todo tipo de recursos desde S3. Dentro de SageMaker aparece una imagen que le permite ejecutar cualquier cosa utilizando la interfaz de usuario o trabajando dentro del código (no los limitamos).

Desde SageMaker, tenemos acceso a Predict.py, que es solo una aplicación en Flask que permite predecir o entrenar con ciertos parámetros. Todo esto está vinculado a S3 y, además, tienen la capacidad de guardar modelos de Jupyter Notebook. Es decir, en Jupyter Notebook, los analistas tienen acceso a todos los datos y pueden hacer algún tipo de experimento.

Entonces todo va a producción. Tenemos usuarios y hay un punto final de valores predictivos. Los datos se encuentran en S3 y pueden ser extraídos por Athena. Cada dos horas, se lanza un algoritmo que calcula la predicción para las próximas dos horas. Esta franja de tiempo se debe al hecho de que, en nuestro caso, aproximadamente 6 horas de análisis son suficientes para decir que algo está mal con el motor. Incluso en el momento de la conexión, el motor se calienta durante 5 a 10 minutos y no hay saltos bruscos.

En los sistemas de importancia crítica, es decir, cuando Air France comprueba las turbinas de una aeronave, la predicción se realiza a una velocidad de 10 minutos. En este caso, la precisión es del 96.5%.

Si vemos que algo va mal, se activa el sistema de alerta. Luego, alguien del grupo de usuarios en el reloj u otro dispositivo recibe una notificación de que un motor en particular se comporta de manera anormal; van y comprueban su estado.

Gestionar instancias de Notebook

Es todo muy simple. Lo primero que hace el analista cuando entran a trabajar es ejecutar la instancia en la computadora portátil Jupiter. Obtienen el rol y la sesión, por lo que dos personas no pueden editar el mismo archivo. De hecho, ahora tenemos una instancia para cada analista.

Crear trabajo de entrenamiento

SageMaker entiende los trabajos de capacitación. Su resultado, si se utiliza solo una API, es un binario que se almacena en S3. Su modelo se obtiene a partir de los parámetros proporcionados.

Ejemplo de parámetros de entrenamiento

Parámetros. El primero es el rol, es decir, debe especificar a qué tiene acceso su instancia de SageMaker. En nuestro caso, si el analista trabaja con dos producciones diferentes, debería ver un bucket y no el otro. La configuración de salida es donde se guardan todos los metadatos del modelo.

Nos saltamos la escala automática y podemos indicar la cantidad de instancias en las que desea ejecutar este trabajo de capacitación. Al principio, generalmente usábamos instancias medias sin TensorFlow o Keras, y eso era suficiente.

Hiperparámetros. Se especifica la imagen de Docker en la que se desea ejecutar. En general, Amazon proporciona una lista de algoritmos e imágenes con ellos, es decir, debe especificar los hiperparámetros, los parámetros del algoritmo en sí.

Crear un modelo

Crear un modelo es el resultado de un trabajo de capacitación. Se guarda en S3 después de que se complete el último, y se puede monitorear y utilizar.

Así es como se ve desde el punto de vista de los analistas. Ellos van a ver páginas de modelos y dicen "Quiero lanzar este, en esta imagen". Simplemente apuntan a la carpeta S3, Imagen, e ingresan los parámetros en la GUI. Pero hay matices y dificultades, por lo que cambiamos a algoritmos personalizados.

Crear un Punto de Enlace

Se necesita mucho código para crear un Punto de Enlace que se tire desde cualquier Lambda y desde el exterior. Cada dos horas, tenemos un evento que tira un Punto de Enlace.

Vista de Punto de Enlace

Así es como lo ven los analistas. Simplemente indican el algoritmo, el tiempo y el trabajo solo a través de la interfaz de usuario.

Invocar un Punto de Enlace

Y así es como se hace desde Lambda. Es decir, tenemos un Punto de Enlace en el interior y cada dos horas enviamos una carga útil para hacer una predicción.

Enlaces útiles de SageMaker: links a github

Estos son enlaces muy importantes. Honestamente, después de que comenzáramos a usar la interfaz gráfica de usuario de Sagemaker, todos comprendieron que tarde o temprano llegaríamos a un algoritmo personalizado y que todo esto se ensamblaría a mano. Estos enlaces proporcionan información sobre el uso de algoritmos y el ensamblaje de imágenes personalizadas:

https://github.com/awslabs/amazon-sagemaker-examples

https://github.com/aws-samples/aws-ml-vision-end2end

https://github.com/juliensimon

https://github.com/aws/sagemaker-spark

 ¿Cuáles son los próximos pasos?

Hemos llegado a la cuarta producción y ahora, aparte de la analítica, tenemos dos formas de desarrollo. Primero, estamos tratando de obtener registros de los mecánicos, es decir, estamos tratando de llegar al entrenamiento con soporte. Los primeros registros de mantenimiento que recibimos se parecían a esto: "Algo se rompió el lunes, fui el miércoles y comencé a repararlo el viernes". Ahora estamos tratando de entregar un CMS al cliente, un sistema de administración de contenido que permitirá el registro de eventos.

¿Cómo se hace? Como regla general, tan pronto como ocurre una avería, el mecánico entra y cambia la pieza rápidamente, pero puede completar todos los formularios en papel, por ejemplo, en una semana. Para ese entonces, la persona puede haber olvidado lo que sucedió exactamente. El CMS, por supuesto, nos lleva a un nuevo nivel de interacción con la mecánica. En segundo lugar, vamos a instalar sensores ultrasónicos en los motores, que leen el sonido y se dedican al análisis espectral.

Es posible que Athena se rinda, porque usar S3 en datos grandes es costoso. Al mismo tiempo, Microsoft anunció recientemente sus propios servicios, y uno de nuestros clientes quiere intentar hacer lo mismo pero en Azure. De hecho, una de las ventajas de nuestro sistema es que se puede desarmar y ensamblar en otro lugar, como si estuviera hecho de cubos.