Cuando las articulaciones de su robot comienzan a "charlar": cosas sobre el intercambio de datos de microservicios

Imagine que está montando un brazo robótico de seis ejes. El servomotor gira con precisión, el servo responde rápidamente y todo es perfecto, hasta que de repente una determinada articulación se "atasa" porque los datos de otro módulo aún no se han transmitido. La línea de producción se detuvo durante tres segundos y todo el ritmo se interrumpió.

¿Te resulta familiar esta escena? En los proyectos de automatización, el flujo de datos es como una señal nerviosa. Si se rompe en un lugar, todo el cuerpo puede congelarse.

Silos de datos: no es un problema técnico, sino un problema de colaboración

En los sistemas tradicionales, los módulos suelen funcionar de forma independiente. La unidad de detección visual calculó las coordenadas, pero la unidad de control de movimiento tuvo que esperar cientos de milisegundos para obtener los datos. No es que la potencia informática no sea suficiente, sino que la ruta de transmisión es demasiado complicada. Es como dejar que dos personas se comuniquen escribiendo cartas en la habitación de al lado. Por supuesto, el trabajo será lento.

"Utilizamos el hardware más moderno, ¿por qué no puede mejorar la eficiencia general?" Muchos equipos hacen esta pregunta repetidamente. La respuesta a menudo no está en el par o la velocidad del motor en sí, sino en esas cadenas de datos invisibles.

Los microservicios están aquí, pero ¿cómo se "apretan las manos" con los datos?

La arquitectura de microservicio divide el sistema grande en pequeños módulos independientes, al igual que divide un panel de control completo en varios módulos pequeños especializados: uno solo es responsable de la planificación de la ruta, otro se dedica a procesar las señales de los sensores y el otro es responsable del control del par. Es flexible, pero ¿cómo comparten datos entre ellos?

Hay varios modos comunes:

• extracción de API: Como preguntar "¿tiene datos nuevos?" cada pocos minutos. Sencillo, pero inevitablemente retrasado.
• cola de mensajes: El módulo "arroja" los datos a un canal intermedio, y quien los necesite podrá obtenerlos. Es asincrónico, pero el orden puede estar alterado.
• impulsado por eventos: Una vez generados los datos, se "transmiten" inmediatamente. Los módulos que se preocupan por este evento pueden responder en tiempo real. Es un poco como un reflejo neurológico: cuando llega el estímulo, la acción ocurre inmediatamente.

¿Cuál elegir? Depende de tu escenario. ¿Se trata de una alta sincronización conjunta en tiempo real o de un seguimiento del estado que permite un ligero retraso?

kpotenciaLa solución: hacer que los datos sean tan naturales como la "conversación"

Hemos pensado en ello durante mucho tiempo y creemos que el intercambio de datos ideal no debería ser una solicitud y una concesión mecánicas, sino que debería estar más cerca de una conversación fluida. Entonces, enkpotenciaEn la lógica del producto, hemos realizado algunos diseños diferentes.

Establecer un “lenguaje común”. Los diferentes módulos pueden provenir de diferentes proveedores y tener una variedad de formatos de datos. Lo primero que hacemos es definir un "sobre de datos" general y ligero. Independientemente del contenido, los sobres tienen un formato uniforme y desembalarlos es fácil.

Agregue "contexto" a sus datos. Simplemente transmitir una coordenada de ubicación no es suficiente; también debe incluir una marca de tiempo, una identificación del módulo de origen e incluso una etiqueta de prioridad. De esta forma, el receptor sabe si las coordenadas son el valor histórico de hace cinco minutos o el comando en tiempo real en este momento. Esto evita fallos de funcionamiento causados ​​por datos obsoletos.

Permitir la "escucha selectiva". No todos los módulos requieren todos los datos. El núcleo de control de movimiento puede requerir una transmisión de posición en tiempo real, mientras que es posible que el módulo de diagnóstico de fallas solo se preocupe por los eventos de alarma. Nuestro modelo permite que los módulos se suscriban a los temas de datos que realmente les interesan, lo que reduce el tráfico innecesario y la carga de procesamiento.

Por ejemplo: en un proyecto de automóvil AGV, el módulo de navegación publica eventos de posición en tiempo real y el mecanismo de dirección del volante se suscribe a ellos para lograr el seguimiento; el módulo de gestión de batería solo se suscribe a eventos de voltaje y temperatura y activa una alarma de desaceleración si hay una anomalía. Cada uno toma lo que necesita sin interferir entre sí.

¿Qué cambios ha supuesto esto?

La sensación más directa es "suave". El sutil retraso anterior mientras se esperaban datos desapareció y las acciones de todo el sistema parecieron más coherentes e "más inteligentes". Al igual que todos los músicos de la banda no sólo pueden mirar al director, sino también escuchar las melodías de los demás, y la cooperación, naturalmente, será tácita.

Es fácil de mantener. Si hay un problema con algún módulo, su flujo de datos mostrará inmediatamente anomalías, lo que hará que sea mucho más rápido localizar el punto de falla. Actualizar o reemplazar un módulo no tendrá un impacto significativo siempre que siga las mismas "reglas de diálogo".

Por supuesto, no existe una solución perfecta. Este modelo requiere una mayor estabilidad de la red y requiere que el equipo dedique más tiempo a planificar los "temas" y el flujo de datos en las primeras etapas del diseño. Pero en comparación con la solución de problemas de congestión de datos en código complejo más adelante, esta inversión inicial generalmente vale la pena.

Entonces, ¿cómo empezar?

Si está eligiendo una solución para un nuevo proyecto o le preocupa la lentitud de su sistema actual, comience por ordenar sus flujos de datos. Dibuje un diagrama para indicar qué datos genera cada módulo y qué datos requiere. Vea si se trata de dependencias en tiempo real estrechamente acopladas o notificaciones asincrónicas poco acopladas.

Luego, pruébalo a pequeña escala. Seleccione una unidad funcional relativamente independiente, como el vínculo entre el posicionamiento visual y el brazo de agarre, y reconstruya su intercambio de datos de manera basada en eventos. Siente el cambio en la latencia y la simplicidad del código.

La tecnología es solo una herramienta y el propósito es siempre hacer que la colaboración entre máquinas sea más fluida y permitir que sus ideas se implementen de manera más rápida y constante. existirkpotenciaCreemos que un buen flujo de datos puede hacer que cada servomotor y cada mecanismo de dirección parezcan tener una coordinación realista. Ésta puede ser otra mirada de la fabricación inteligente.

Fundada en 2005, Kpower se dedica a la fabricación profesional de unidades de movimiento compactas, con sede en Dongguan, provincia de Guangdong, China. Aprovechando las innovaciones en tecnología de accionamiento modular, Kpower integra motores de alto rendimiento, reductores de precisión y sistemas de control multiprotocolo para proporcionar soluciones de sistemas de accionamiento inteligentes eficientes y personalizadas. Kpower ha brindado soluciones de sistemas de accionamiento profesionales a más de 500 clientes empresariales en todo el mundo con productos que cubren diversos campos, como sistemas domésticos inteligentes, electrónica automática, robótica, agricultura de precisión, drones y automatización industrial.