La confusión de los microservicios en el mundo de los servomotores

¿Alguna vez has mirado fijamente ese brazo robótico desobediente y te has preocupado? Evidentemente el programa está escrito correctamente y las instrucciones son correctas, pero cuando se mueve se congela, responde lentamente e incluso en ocasiones "finge ser sordo y mudo". El viejo maestro del taller sacudió la cabeza mientras sostenía un cigarrillo en la boca: "Este sistema es como un ser humano. Una vez que la mente está confundida, las manos y los pies no obedecerán la orden". El problema detrás de esto a menudo no es el motor en sí, sino los datos y la gestión: esas señales invisibles y la coordinación que bloquean el ritmo en un lugar silencioso.

Cuando el hardware encuentra una "isla de información"

Imagínese: hay docenas de servomotores y servos en el taller, cada uno de los cuales parece un trabajador obstinado trabajando duro. Cada uno recibe instrucciones y datos de retroalimentación, pero no hay un "líder de escuadrón" para coordinar. ¿El resultado? El motor A está girando, pero el motor B todavía está leyendo la barra; los datos de posición vuelven a la mitad y se sobrescriben con nuevas instrucciones. El mantenimiento es aún más problemático: si se quiere comprobar la curva de funcionamiento de un determinado equipo el mes pasado, hay que pasar por tres sistemas de registro diferentes y los formatos de datos no se reconocen entre sí.

No es culpa de la máquina. El sistema centralizado tradicional es como utilizar un cuaderno grueso para registrar todo: las palabras se escriben cada vez con más densidad y la búsqueda se vuelve cada vez más lenta. Ni siquiera tú puedes encontrar lo que escribiste ayer. Y cuando las necesidades de producción cambian y el equipo aumenta, tarde o temprano este "cuaderno" dejará de poder abrirse.

Microservicios: Asigne un "asistente dedicado" a cada motor

Por eso, en los últimos años, cada vez más gente ha comenzado a hablar de "microservicios". En pocas palabras, consiste en dividir ese grueso cuaderno en muchas tarjetas pequeñas: cada tarjeta solo puede registrar una cosa, pero la información se puede transferir rápidamente entre tarjetas. Aplicado al sistema motor, significa que cada dispositivo (o cada grupo de dispositivos) tiene un módulo de servicio independiente responsable de su propio control, monitoreo y registro de datos. Los módulos se comunican entre sí de forma ligera, como los trabajadores de un taller que utilizan un walkie-talkie para hablar de forma clara y directa.

Los beneficios de esto se sienten casi de inmediato:

• flexible: ¿Quiere actualizar la lógica de control de un determinado motor? Simplemente actualice los módulos correspondientes sin apagar y reiniciar todo el sistema.
• claro: Al solucionar problemas, puede localizar rápidamente qué "tarjeta de servicio" tiene el problema, en lugar de buscar una aguja en un pajar entre cientos de miles de líneas de código.
• Fácil de ampliar: ¿Se añaden dos nuevos robots a la línea de producción? Simplemente conecte el nuevo módulo de servicio correspondiente directamente y casi no habrá necesidad de modificar el sistema original.

Pero ¿por qué algunos todavía dudan?

Todo el mundo comprende el principio, pero en la práctica el umbral no es bajo. Un amigo que había hecho un intento similar una vez se quejó conmigo: "Los microservicios son buenos, pero tomó dos meses construir el entorno y diseñar el protocolo de comunicación. El mantenimiento posterior es aún más problemático: después de que hay más servicios, el monitoreo, el registro y el seguimiento de fallas se convierten en nuevos problemas".

Este es precisamente el verdadero dilema al que se enfrentan muchos equipos técnicos: los conceptos son avanzados, pero las herramientas no pueden seguir el ritmo. Hasta hace poco estábamos expuestos akpotenciaCon un conjunto de microservicios proporcionados basados ​​en la plataforma Azure, las cosas empiezan a verse diferentes.

Un manual desencadena el cambio

kpotenciaUn cliente compartió originalmente con nosotros la documentación técnica sobre "microservicios con Azure". Funda azul claro, no demasiado gruesa. Antes de abrirlo pensé que era otro manual técnico lleno de código y teoría. Pero después de leer algunas páginas, me sentí completamente diferente.

No le habla de grandes palabras como "nativo de la nube" y "containerización", sino que dibuja directamente una escena: suponga que hay cinco servomotores en su taller, que son responsables de la manipulación, posicionamiento, montaje, inspección y embalaje. El manual describe en lenguaje sencillo cómo establecer un servicio independiente para cada motor, cómo dejarlos "hablar" a través de los servicios básicos de Azure e incluso detalla cómo configurar el formato de datos y cuál es el retraso normal del mensaje.

Aún más raro es que analice con franqueza los posibles problemas que puedan surgir. Por ejemplo: si la red tiembla ocasionalmente, ¿cómo evitar errores de cálculo entre servicios? Si el servicio de un motor se detiene repentinamente, ¿cómo se evita que otros equipos se vean afectados? El manual no evita estas "tareas sucias", sino que proporciona varios conjuntos de estrategias para afrontarlas, desde simples hasta complejas, como un viejo ingeniero experimentado que le habla sobre operaciones prácticas.

Intentos imperfectos y progreso visible

Seguimos las instrucciones del manual y realizamos experimentos a pequeña escala, utilizando tres servos para construir una línea de montaje de agarre sencilla. Los primeros dos días hubo muchos baches: el registro del servicio ocasionalmente caducaba y los registros no estaban ordenados. Pero al tercer día, después de ajustar algunos parámetros, los efectos comenzaron a notarse.

Lo más intuitivo es la velocidad de respuesta. En el pasado, bajo control centralizado, pasaban entre 100 y 150 milisegundos desde la emisión de un comando de acción hasta la respuesta de todos los motores (todavía había fluctuaciones en el medio). ¿Y ahora qué? Cada servo recibe comandos de forma independiente, la respuesta promedio es de 50 milisegundos y la curva es mucho más suave. La visualización de datos también se ha vuelto simple: la temperatura de funcionamiento, la curva de carga y el historial de alarmas de cada dispositivo se pueden ver en tiempo real en una página de monitoreo independiente, lo que elimina la necesidad de examinar manualmente registros mixtos.

Un colega que participó en la prueba dijo con una sonrisa: "Parece como si a cada máquina se le asignara una pequeña secretaria". Aunque la metáfora no es rigurosa, el estado de claridad y organización y de que cada uno realice sus propias tareas es realmente difícil de lograr con la arquitectura tradicional.

¿Por qué Azur? ¿Por qué elegir esta guía?

Existen muchas plataformas en el mercado que admiten microservicios.kpotencia¿Por qué elegir Azure como base? El manual no lo promueve deliberadamente, pero enumera objetivamente algunas consideraciones prácticas: compatibilidad con los sistemas existentes de la empresa (el entorno de TI de muchas fábricas ya se basa parcialmente en los sistemas de Microsoft), los componentes prefabricados relativamente ricos de Azure en el campo del IoT industrial y el costo: para aplicaciones pequeñas y medianas, su método de facturación por niveles suele ser más rentable.

El valor del manual en sí radica en que no es sólo una instrucción operativa, sino también un conjunto de marco de pensamiento. Le enseña cómo "desmontar" un sistema mecánico complejo en unidades de microservicio y cómo mantener la eficiencia general de la colaboración después de la división. Este tipo de pensamiento puede incluso trasladarse a otros proyectos.

Por supuesto, ninguna herramienta es una panacea. La arquitectura de microservicios traerá nuevas complejidades, como una mayor dependencia de la red y una mayor dificultad en el monitoreo distribuido. El manual también recuerda claramente: no todos los escenarios son adecuados para microservicios inmediatos. Para sistemas pequeños con una pequeña cantidad de dispositivos y una lógica simple, la arquitectura tradicional puede resultar más económica; pero para situaciones con muchos dispositivos, lógica compleja y frecuentes expansiones posteriores, las ventajas de este método quedarán realmente destacadas.

Escrito en: La tecnología es un medio, no un fin

Al comunicarse con el equipo técnico de Kpower, enfatizaron repetidamente: "Lo que ofrecemos no es un conjunto fijo, sino un camino probado". Esta afirmación suena modesta, pero es cierta. El mayor temor en el ámbito industrial es hablar sobre papel: por muy elegante que sea la idea, si no se adapta al entorno del taller, todo quedará en palabras vacías.

Volvamos al problema del atascamiento del brazo robótico del principio. Mirando hacia atrás, la razón puede no ser que el motor no sea lo suficientemente potente o que el programa esté escrito incorrectamente, sino que el "método de cooperación" de todo el sistema es antiguo. Al igual que un grupo de personas que trabajan juntas, si todos tienen que esperar a que hable un líder del grupo antes de poder actuar, la eficiencia, naturalmente, no será alta. Lo que quieren hacer los microservicios es permitir que cada miembro actúe de forma autónoma bajo reglas claras mientras se mantiene la sincronización general.

El manual azul claro está ahora sobre el escritorio de nuestro taller y las esquinas de las páginas ya están curvadas. No resuelve todos los problemas, pero abre una puerta: una puerta que hace que el hardware sea más inteligente, los datos más fluidos y el mantenimiento más sencillo. Quizás su taller también necesite esa llave.

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.