Quando servomotores encontram microsserviços: uma conversa descontraída sobre arquitetura

Você encontrou algo semelhante? Um motor é confiável, mas quando funciona com dezenas de outros dispositivos, o sistema se torna imprevisível? Em vez de falarmos hoje sobre teoria avançada, vamos falar sobre como repensar a organização do sistema de controle como blocos de construção.

O problema está escondido nos detalhes

Imagine que você é responsável por uma linha de montagem. Seis servo motores são responsáveis ​​pelo posicionamento preciso, três servos completam o ajuste fino do ângulo e o braço robótico transporta as peças em um ritmo fixo. Inicialmente, toda a lógica de controle era escrita em um controlador central – isso era muito comum, como amontoar todos os móveis em uma sala. Parecia legal no início, mas conforme as necessidades mudavam, era necessário remexer sempre que era ajustado.

Um dia, a velocidade da seção de embalagem precisará ser temporariamente aumentada em 20%, mas você descobrirá que o ajuste de um parâmetro afetará, na verdade, a precisão do posicionamento upstream. Ou, quando determinados dados do sensor são anormais, todo o log do sistema fica uma bagunça e é difícil rastrear a origem do problema. Mais comumente, quando você deseja alterar um dos modelos de motor, é necessário reescrever grande parte do código associado.

Estas não são "falhas", mas um sussurro da arquitetura de que é hora de organizar seu sistema de forma diferente.

Microsserviços: dê a cada função uma sala separada

Podemos mudar o nosso pensamento – e se a lógica de controle de cada motor puder funcionar de forma independente? por exemplo:

• O servo motor de posicionamento decide sozinho como responder ao comando alvo e apenas informa ao sistema "Estou em posição" por meio de uma interface clara.
• A unidade de detecção de pressão concentra-se na análise de dados do sensor e emite lembretes em formato padrão quando ocorrem anormalidades.
• O módulo de planejamento de movimento concentra-se no cálculo do caminho ideal e não é afetado por alterações de código em outros módulos.

Essa abordagem tem um nome, chamado arquitetura de microsserviços. Não se deixe intimidar pela terminologia, sua essência é simples: dividir um grande sistema em um conjunto de pequenos serviços que podem ser desenvolvidos, implantados e expandidos de forma independente. Assim como os tijolos Lego, cada peça tem uma função clara, mas o método de união pode ser ajustado de forma flexível.

Alguém pode perguntar: “Isso acrescenta complexidade?” Boa pergunta. No curto prazo, é necessário projetar alguns padrões para comunicação entre serviços (como formatos de dados claramente definidos), mas no longo prazo, isso reduz o acoplamento não intencional do sistema. Quando um módulo precisa de atualização, você não precisa parar toda a linha de produção para testar todas as funcionalidades.

Por que esta ideia é adequada para cenários de controle de hardware?

Servomotores e sistemas mecânicos têm uma característica: tendem a funcionar por muito tempo. A linha de produção poderá continuar funcionando por cinco ou dez anos, período durante o qual haverá inúmeras substituições parciais e de componentes e novas funções. A arquitetura monolítica tradicional é como uma enorme pintura a óleo, e a modificação de qualquer detalhe pode exigir o redesenho de toda a tela.

A arquitetura de microsserviços é como um conjunto de cadernos de desenho, com cada folha registrando funções específicas. Quer modificar a lógica de agarrar do braço robótico? Você só precisa atualizar essa parte do serviço e garantir que ele se comunique normalmente com outros módulos enquanto a interface permanece inalterada.

potênciaAo auxiliar os clientes a implementar este tipo de arquitetura, muitas vezes vemos diversas mudanças interessantes:

• O tempo de solução de problemas é reduzido em média 40% porque os logs são naturalmente separados por serviço
• O ciclo de iteração de hardware tornou-se mais flexível e a mudança de modelos de motores muitas vezes requer apenas o ajuste dos serviços correspondentes.
• O custo de teste de novos recursos é reduzido e módulos específicos podem ser testados em um ambiente isolado sem afetar toda a linha.

Três passos do conceito à prática

Se você achar essa arquitetura interessante, você pode experimentá-la em três etapas:

Etapa 1: desenhe limites funcionais. Pegue um pedaço de papel e particione seu sistema de controle de acordo com as funções físicas. Quais peças estão fortemente acopladas (como acionamento e processamento de feedback do mesmo motor)? Quais peças trocam dados apenas ocasionalmente (por exemplo, mecanismo de alimentação e unidade de inspeção de qualidade)? Os limites físicos naturais costumam ser um bom ponto de partida para o particionamento de microsserviços.

Passo 2: Definir regras de diálogo Os serviços precisam de comunicar, tal como os trabalhadores numa linha de produção precisam de entregar produtos semi-acabados. Combine o formato dos dados – por exemplo, todas as informações de localização incluem carimbo de data/hora, unidade e nível de confiança; todas as instruções possuem números exclusivos para facilitar o rastreamento. Estas regras não têm de ser perfeitas desde o início, mas convenções claras podem evitar confusões mais tarde.

Etapa 3: Refatorar desde o início Não há necessidade de reescrever todo o sistema de uma só vez. Escolha um módulo que precise de melhorias recentemente (como aquele servo motor da seção de embalagem que lhe dá dor de cabeça) e transforme-o primeiro em um serviço independente. Depois de verificar se a operação está estável, expanda gradualmente. Essa mudança gradual é mais amigável ao funcionamento contínuo da linha de produção.

Às vezes a resposta está fora da pergunta

Muitas vezes penso no amigo que mencionei no início. Quando ele começou a reorganizar parte da lógica de controle usando ideias de microsserviços, ele não apenas resolveu o problema de atraso de resposta, mas também descobriu inesperadamente que sua equipe começou a dividir o trabalho com mais naturalidade. O engenheiro responsável pela estrutura mecânica concentra-se nos serviços de planejamento de movimento, e o engenheiro elétrico está profundamente envolvido no módulo de controle do inversor. Os dois colaboram através de interfaces claramente definidas, em vez de anotarem um ao outro no mesmo arquivo de código.

Este pode ser outro presente da arquitetura: ela não apenas organiza o código, mas também a forma como as pessoas colaboram. Quando cada módulo funcional tem limites claros de responsabilidades, a manutenção torna-se algo que pode ser promovido em paralelo.

É claro que nenhuma arquitetura é uma solução mágica. Os microsserviços trarão considerações de comunicação de rede entre serviços e exigirão um design de monitoramento mais detalhado. Mas para os sistemas de controle de hardware que exigem evolução a longo prazo e localização frequente, essa filosofia de “dividir para conquistar” pode muitas vezes trazer uma facilidade inesperada.

No final das contas, a arquitetura técnica é como o layout da sala. Algumas pessoas gostam de colocar tudo num espaço aberto, que é claro à primeira vista, mas difícil de ajustar localmente; algumas pessoas preferem dar a cada função uma sala separada, o que requer mais alguns passos na fase inicial, mas cada espaço pode ser renovado ao seu próprio ritmo.

Com que tipo de sala seu sistema se parece agora?

Fundada em 2005,potênciatem se dedicado a 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,potênciaintegra 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.