Quando as articulações do seu robô começam a "conversar": coisas sobre o compartilhamento de dados de microsserviços

Imagine que você está montando um braço robótico de seis eixos. O servo motor gira com precisão, o servo responde prontamente e tudo está perfeito – até que uma determinada junta “trava” repentinamente porque os dados de outro módulo ainda não foram transmitidos. A linha de produção parou por três segundos e todo o ritmo foi interrompido.

Esta cena é familiar? Em projetos de automação, o fluxo de dados é como um sinal nervoso. Se quebrar em um lugar, todo o corpo pode congelar.

Silos de dados: não é um problema técnico, mas um problema de colaboração

Em sistemas tradicionais, os módulos geralmente funcionam de forma independente. A unidade de detecção visual calculou as coordenadas, mas a unidade de controle de movimento teve que esperar centenas de milissegundos para obter os dados. Não é que o poder de computação não seja suficiente, mas o caminho de transmissão é muito complicado. É como permitir que duas pessoas se comuniquem escrevendo cartas na sala ao lado. Claro, o trabalho será feito lentamente.

"Usamos o hardware mais recente, por que a eficiência geral não pode melhorar?" Muitas equipes fazem essa pergunta repetidamente. A resposta muitas vezes não está no torque ou na velocidade do motor em si, mas nessas cadeias de dados invisíveis.

Os microsserviços estão aqui, mas como você “aperta a mão” dos dados?

A arquitetura de microsserviços divide o grande sistema em pequenos módulos independentes, assim como divide um painel de controle inteiro em vários pequenos módulos especializados: um é responsável apenas pelo planejamento do caminho, um é dedicado ao processamento de sinais de sensores e o outro é responsável pelo controle de torque. É flexível, mas como eles compartilham dados entre eles?

Existem vários modos comuns:

• Extração de API: Como perguntar "você tem novos dados?" a cada poucos minutos. Simples, mas inevitavelmente atrasado.
• fila de mensagens: O módulo “joga” os dados em um canal intermediário, e quem precisar pode obtê-los. É assíncrono, mas a ordem pode estar confusa.
• orientado a eventos: Depois que os dados são gerados, eles são "transmitidos" imediatamente. Os módulos que se preocupam com este evento podem responder em tempo real. É um pouco como um reflexo neurológico – quando o estímulo chega, a ação acontece imediatamente.

Qual escolher? Depende do seu cenário. É uma alta sincronização conjunta em tempo real ou um monitoramento de status que permite um pequeno atraso?

potênciaA solução: tornar os dados tão naturais quanto uma “conversa”

Pensamos nisso há muito tempo e sentimos que o compartilhamento de dados ideal não deveria ser uma solicitação e entrega mecânica, mas deveria estar mais próximo de uma conversa tranquila. Então, empotênciaNa lógica do produto, fizemos alguns designs diferentes.

Estabeleça uma “linguagem comum”. Módulos diferentes podem vir de fornecedores diferentes e ter vários formatos de dados. A primeira coisa que fazemos é definir um "envelope de dados" geral e leve. Independentemente do conteúdo, os envelopes são formatados de forma consistente e é fácil desembalá-los.

Adicione "contexto" aos dados. Simplesmente transmitir uma coordenada de localização não é suficiente, você também deve incluir um carimbo de data/hora, ID do módulo de origem e até mesmo um rótulo de prioridade. Desta forma, o receptor sabe se as coordenadas são o valor histórico de cinco minutos atrás ou o comando em tempo real neste momento. Isso evita mau funcionamento causado por dados obsoletos.

Permitir "escuta seletiva". Nem todos os módulos requerem todos os dados. O núcleo de controle de movimento pode exigir transmissão de posição em tempo real, enquanto o módulo de diagnóstico de falhas pode se preocupar apenas com eventos de alarme. Nosso modelo permite que os módulos assinem os tópicos de dados que realmente lhes interessam, reduzindo o tráfego desnecessário e a carga de processamento.

Por exemplo: Em um projeto de carro AGV, o módulo de navegação publica eventos de posição em tempo real e o volante do volante os inscreve para obter o rastreamento; o módulo de gerenciamento de bateria apenas assina eventos de tensão e temperatura e aciona um alarme de desaceleração se houver uma anormalidade. Cada um pega o que precisa sem interferir um no outro.

Que mudanças isso trouxe?

O sentimento mais direto é “evitar”. O sutil atraso anterior durante a espera pelos dados desapareceu e as ações de todo o sistema pareciam mais coerentes e “mais inteligentes”. Assim como todos os músicos da banda podem não apenas olhar para o maestro, mas também ouvir as melodias uns dos outros, e a cooperação será naturalmente tácita.

É fácil de manter. Se houver algum problema com algum módulo, seu fluxo de dados mostrará imediatamente anormalidades, tornando muito mais rápida a localização do ponto de falha. A atualização ou substituição de um módulo não terá impacto significativo, desde que siga as mesmas “regras de diálogo”.

É claro que não existe uma solução perfeita. Este modelo exige maior estabilidade da rede e exige que a equipe gaste mais tempo planejando os “tópicos” e o fluxo de dados nos estágios iniciais do projeto. Mas, em comparação com a solução de problemas de congestionamento de dados em códigos complexos posteriormente, esse investimento inicial geralmente vale a pena.

Então, como começar?

Se você estiver escolhendo uma solução para um novo projeto ou estiver preocupado com a lentidão do seu sistema existente, comece classificando seus fluxos de dados. Desenhe um diagrama para indicar quais dados cada módulo gera e quais dados ele requer. Veja se são dependências em tempo real fortemente acopladas ou notificações assíncronas fracamente acopladas.

Então, experimente em pequena escala. Selecione uma unidade funcional relativamente independente, como a ligação entre o posicionamento visual e o braço de preensão, e reconstrua seu compartilhamento de dados de maneira orientada a eventos. Sinta a mudança na latência e a simplicidade do código.

A tecnologia é apenas uma ferramenta, e o objetivo é sempre tornar a colaboração entre máquinas mais fácil e permitir que suas ideias sejam implementadas de forma mais rápida e constante. existirpotência, acreditamos que um bom fluxo de dados pode fazer com que cada servo motor e cada mecanismo de direção pareçam ter uma coordenação realista. Esta pode ser outra visão da manufatura inteligente.

Fundada em 2005, a Kpower tem se dedicado a ser um fabricante profissional de unidades de movimento compacto, com sede em Dongguan, província de Guangdong, China. Aproveitando inovações em tecnologia de acionamento modular, a Kpower integra motores de alto desempenho, redutores de precisão e sistemas de controle multiprotocolo para fornecer soluções de sistemas de acionamento inteligentes eficientes e personalizadas. A Kpower forneceu soluções profissionais de sistemas de acionamento para mais de 500 clientes empresariais em todo o mundo, com produtos que abrangem vários campos, como sistemas domésticos inteligentes, eletrônica automática, robótica, agricultura de precisão, drones e automação industrial.