Detección de cambios de estado en las cafeteras

Tulip's soporta la conectividad nativa de las máquinas, poniendo los datos de sus máquinas en contexto con los datos de las personas, los dispositivos y los sistemas. Los cambios de estado de las máquinas pueden supervisarse a través de conexiones en red o con sensores y nuestros dispositivos de borde.

En este post, exploraremos cómo nuestro equipo readaptó una máquina heredada, la conectó a la nube y estimó su estado utilizando un sencillo modelo ML y Edge IO. En nuestra sede de Somerville, tenemos una máquina de café expreso y un dispensador de agua que eran candidatos perfectos para medir la utilización.

Si esto le resulta familiar, el día de los inocentes "lanzamos" un nuevo producto a partir de este experimento →

Manteniéndolo lo más simple posible, conectamos un sensor de corriente y vibración utilizando un sensor Edge IO y PhidgetHub. Para la máquina de café espresso, ejecutamos un modelo ML que detecta si la máquina está en marcha, inactiva o parada. Esto nos permite monitorizar el uso de la máquina y optimizar potencialmente su mantenimiento y rendimiento.

Siga leyendo mientras cubrimos los componentes de hardware y software necesarios, así como los pasos para configurar y ejecutar el modelo de aprendizaje automático.

Para supervisar la máquina de café, conectamos un sensor de corriente comercial a una IO Edge. También añadimos un sensor de vibración piezoeléctrico para monitorizar las vibraciones a alta velocidad. El Edge IO admite la monitorización de alta velocidad a través de sus entradas ADC integradas.

Elegimos conectar un PhidgetHub conectado al Edge IO para el sensor de corriente para convertir las señales analógicas del sensor en el Edge IO.

Para recoger los datos procedentes del PhidgetHub en Tulip, utilizamos los nodos estándar Phidgets Node-RED para VoltageInput. El PhidgetHub de la máquina de café exprés se enchufa directamente al Edge IO, mientras que el PhidgetHub del dispensador de agua se conecta mediante WiFi al mismo dispositivo, lo que nos permite realizar un seguimiento de la utilización en ambos dispositivos con un único dispositivo Edge.

Para pasar los datos de Edge IO a la nube, utilizamos el Nodo de Tabla-RED deTulip . Este Nodo permite añadir los datos del dispositivo Edge a una Tabla en Tulip. Configuramos cada registro para almacenar una marca de tiempo, un nombre y un valor numérico del sensor, y reunimos los datos de todos los sensores en una única tabla.

Una vez que los datos estaban en una Tabla, los exportamos a un CSV para cargar los datos utilizando pandas, y empezar a visualizar los datos y crear nuestro modelo de aprendizaje automático.

Primero clasificamos los datos de los sensores de la cafetera espresso e identificamos rápidamente los tres estados de la máquina:

• Fuera de

• Ralentí/espera

• Correr/hacer café

Nuestra primera observación fue bastante interesante, ya que nos dimos cuenta de cuánta corriente utilizaba la máquina durante su estado de reposo. Cada 30 segundos, se produce un breve pico que decae hasta cero - determinamos que esto estaba relacionado con el elemento calefactor que mantiene la cafetera a una temperatura adecuada.

Para modelar los estados, nuestros principales objetivos eran:

• Queremos evitar tener que etiquetar datos extensos.

• Una cafetera tiene una cantidad finita de cosas que hace: moler granos, calentar, preparar un chupito, hacer espuma de leche. Por ello, los datos de nuestros sensores tienen un aspecto diferente para cada paso de trabajo, lo que debería permitir encontrar características genéricas en nuestros datos que nos permitan agrupar estas partes del programa en estados separados.

• A continuación, un operario puede asignar estos estados a Parada/Recorrido/Inactividad utilizando los disparadores estándar de la máquina Tulip .

Para iniciar este proceso, ejecutamos una media móvil para suavizar los ciclos de calentamiento que identificamos. Debido a la duración de los ciclos, elegimos una media móvil de 1 minuto. Los ciclos de calentamiento con esta máquina tendían a durar unos 30 segundos, y el ciclo completo de café dura unos 2-3 minutos, dependiendo de la temperatura de la máquina al principio de su encendido.

Además, incluimos características retardadas: medias móviles de hace uno y dos minutos. Se trata de un método estándar en el análisis de series temporales, que permite al modelo ver patrones ascendentes o descendentes en los datos.

Para el modelo de agrupación, queríamos algo con el menor número posible de parámetros y un método incorporado para estimar la cantidad "correcta" de agrupaciones. Elegimos un modelo bayesiano de mezcla gaussiana.

Esto nos ayudó a estimar que la dimensionalidad de los datos de los sensores de nuestra cafetera es proporcional a los 6 pasos de trabajo diferentes (apagar, moler granos, calentar, preparar un chupito, hacer espuma de leche, manipulación manual), por lo que elegimos 6 para el número de componentes separados en el modelo de conglomerados.

Como se trata de un modelo no supervisado, recopilamos datos durante un día que luego se utilizaron para entrenar el modelo. La validación se realizó visualmente: comprobamos si las agrupaciones que detectaba el modelo coincidían con el estado que se desprendía de los datos de los sensores.

A partir de estos trazados, podemos ver que el estado 1 es Apagado, 4,5 son Ralentí, y 0,2,3 parecen ser varias etapas de la preparación del café (molido, preparación de un chupito y formación/enfriamiento de la espuma de leche).

Después de construir y probar nuestro modelo de aprendizaje automático de agrupación, llegó el momento de desplegar el modelo para su uso. Almacenamos el modelo en S3 utilizando MLflow de la siguiente manera: mlflow.sklearn.save_model(s3://nombre_del_bucket/prefijo_del_registro/nombre_del_modelo/versión).

Para ejecutar el modelo se optó por utilizar una puerta de enlace de AWS y una función Lambda de AWS para obtener el modelo de S3 en formato MLflow. El punto final fue gateway-address.com/inference/{model_name}, donde los datos consisten en las características de media móvil desfasada en el tiempo.

Para ejecutar el modelo en los nuevos datos entrantes, teníamos dos opciones: configurar un conector HTTP y ejecutarlo dentro de un Tulip App , lo que requeriría un dispositivo para ejecutar la aplicación en todo momento, o ejecutar un post HTTP desde dentro de Node-RED y publicar el id del clúster como atributo de la máquina de estado con los nodos estándar Tulip Node-RED. Elegimos esta última opción y desplegamos con éxito el modelo para su uso.

El flujo de Node-RED para calcular los datos de las características y ejecutar el modelo tiene el aspecto que se muestra a continuación:

Ahora la máquina está totalmente configurada y Tulip está recopilando los datos con nuestro modelo para que podamos calcular cuántos cafés se producen al día y cuánto tiempo pasa la máquina en estados de Funcionamiento vs Ralentí vs Apagado.

Como puede ver arriba, el modelo aún necesitaba algo de trabajo, así que instalamos Tulip Player en un iPad junto a la máquina de café espresso que ejecutaba una aplicación Tulip que los usuarios pueden utilizar para dar su opinión sobre la precisión del modelo. Además, recuerda a los usuarios que apaguen la máquina al terminar, para ahorrar energía.

Con los datos del modelo, podríamos construir cuadros de mando para mostrar nuestros resultados y utilización:

Además, analizamos algunos de los datos brutos para calcular el consumo de corriente por estado durante un día de trabajo normal. Descubrimos que la cafetera exprés utiliza el 80% de la corriente (lo que se aproxima al consumo de energía) cuando está inactiva, y sólo el 20% de la corriente se destina a preparar el café. Dado que se trata de una máquina pequeña en un entorno no industrial, la cantidad de desperdicio no es tan grande.

Sin embargo, en las operaciones de fabricación puede haber muchas situaciones en las que se desperdicie una gran cantidad de energía por máquinas al ralentí. La supervisión de la utilización de las máquinas puede ser clave para ayudar a ser alertado de los cambios de estado y responder más rápidamente a una máquina parada, ahorrando tiempo a su equipo y reduciendo el derroche de energía.

Para resumir este post, hemos explorado cómo adaptar máquinas heredadas y conectarlas a la nube para estimar su disponibilidad mediante un sencillo modelo ML.

Utilizamos una máquina de café espresso situada en nuestra oficina de Somerville, Massachusetts. Cubrimos los componentes de hardware y software necesarios, así como los pasos para configurar y ejecutar el modelo ML. El modelo utilizó un modelo bayesiano de mezclas gaussianas para la agrupación (con medias móviles y características retardadas), y se calculó y ejecutó en un Edge IO.

Un App para cafeteras en nuestra oficina proporciona una interfaz para dar información si el modelo no detectaba que se estaba haciendo un café o era demasiado lento para reaccionar.

Además, un cuadro de mandos que controla continuamente los cafés que se hacen en la sede de Tulip . Calculamos la corriente total utilizada por cada estado de la cafetera, y descubrimos que sólo el 20% se utiliza para hacer café, ¡el resto se gasta en ralentí!

Este experimento se enmarca en una serie de experimentos que hemos realizado en torno a la detección de estados para la supervisión de máquinas, incluido un experimento mientras creábamos Edge IO en Autodesk Technology Centers, Boston. Hemos seguido explorando modelos de detección de estado en máquinas CNC utilizadas por los fabricantes, así como en otros dispositivos y equipos domésticos, como una lavadora. Cada equipo requiere unos pequeños retoques en los componentes y las medias móviles del modelo, pero seguimos detectando estados en varios ciclos.

Este trabajo está dando sus frutos, y estamos encantados de poder compartir algunas nuevas ofertas de Tulip que llegarán a finales de este año.