Soluções de Baixo Custo para Automação de Testes em Hardware em Loop

No mundo acelerado de hoje, onde iterações de eletrônicos são realizadas à velocidade da luz, muitas vezes esquecemos um dos aspectos mais críticos do desenvolvimento: o teste. É sempre fácil negligenciar o teste simplesmente porque é a última etapa que nos impede de lançar nosso produto. No desenvolvimento de produtos, constantemente nos encontramos no dilema entre "bom o suficiente" versus "testado exaustivamente". Essa situação geralmente ocorre porque não temos tempo para testar, retestar e depois testar ainda mais. 

Na melhor das situações, teríamos contratado uma equipe de teste completa que está equipada para realizar testes exaustivos. Mesmo que tenhamos essa equipe de teste sofisticada, realmente conseguimos utilizá-la para cada modificação, cada pequena e insignificante alteração que fazemos em nossos protótipos? Na maioria dos casos, a resposta é não, e neste artigo, gostaria de abordar o problema com uma solução onde você pode ter o bolo e comê-lo também. Neste artigo, vamos revisar um sistema de teste muito barato, mas altamente eficaz e bastante exaustivo, que lhe dará aquele retorno sobre o investimento que você tem procurado.

Teste Manual vs. Teste Automatizado

É bastante comum na indústria ter uma configuração de teste automatizado (principalmente para testes em nível de produção). No entanto, para o desenvolvimento de produtos, isso não é uma prática comum. Como mencionado acima, o custo e o tempo de desenvolvimento para configurar equipamentos de teste automatizados sofisticados requerem um alto nível de esforço. Esse tipo de custo e esforço só se justifica para produção em massas volumosas ou volumes baixos com configurações de teste muito sofisticadas (por exemplo, sistemas de espaçonaves de baixo volume que precisam ser testados ambientalmente muitas vezes). Para o resto do mundo, recorremos a testes manuais básicos e tediosos. Esse tipo de teste pode variar desde a validação de ADC/DAC, verificações de protocolo, testes de consumo de energia, etc. Independentemente do tipo de teste, a esperança é que ele só precise ser feito uma ou duas vezes, e então possa ser passado para o grupo de testes.

Consequências Não Intencionais e Automação

A realidade é que durante nosso desenvolvimento, seja nas fases de design/respin de hardware ou no desenvolvimento de software embarcado, nós involuntariamente causamos algum tipo de falha. Alguns exemplos podem ser uma ponte de solda entre pads ou código de driver interferindo em outros códigos de driver, o que pode causar uma falha. Independentemente do resultado, é claro que os testes não acontecem apenas uma ou duas vezes. Problemas surgem, e testes exaustivos geralmente são demasiadamente cansativos para serem realizados após a décima vez de retrabalho em uma placa. A resposta óbvia para o problema é ter sistemas automatizados realizando testes de regressão exaustivos. Mas qual é a solução para o engenheiro de sistemas embarcados que tem pouco dinheiro e tempo para desenvolver um sistema de teste automatizado exaustivo?

A Solução Econômica

Para sistemas embarcados, existe uma solução de teste automatizado de baixo custo, porém muito escalável e prática. Embora não seja perfeita, ela proporcionará ao engenheiro de design o maior retorno sobre o investimento. O conceito é usar um dispositivo simples que pode gerar sinais analógicos, ler sinais analógicos, gerar diversos fluxos seriais de protocolos e analisar formas de onda. Um exemplo de um dispositivo de baixo custo que possui tais especificações é o Analog Discovery 2. Embora seja um dispositivo de 5V, ainda assim oferece bastante recursos. Considero-o como meu canivete suíço para o desenvolvimento de sistemas embarcados. Existem outros produtos comparáveis no mercado, mas encontrei neste dispositivo um desempenho particularmente bom para as minhas aplicações. Este dispositivo pode ser operado a partir do seu computador de mesa ou até mesmo de um Raspberry Pi. Ele também possui uma biblioteca Python que permite ao usuário montar rapidamente executivos de teste. Para conveniência, eu dockerizei a configuração completa e a construí para todas as arquiteturas.

Exemplo Prático

Vamos considerar um exemplo real que pode ser encontrado neste repositório. Para simplificar, nosso alvo embarcado será um Arduino Duo. Abaixo está como nosso conjunto de teste completo se parece:

A ideia aqui é demonstrar:

• O computador hospedeiro comanda o Analog Discovery 2 para enviar sinais analógicos ao Arduino
• Arduino lê e armazena os valores do ADC
• O computador hospedeiro recebe os valores do ADC via UART (USB)
• O computador hospedeiro valida que o que foi enviado através do Analog Discovery 2 corresponde à telemetria enviada pelo Arduino

Por que iríamos querer automatizar algo assim? Vamos supor que reajustamos uma placa perto do ADC, ou alguém altera os drivers que interagem com o ADC. Estamos 100% confiantes de que uma simples leitura manual do ADC, com alguns ajustes feitos em uma fonte de alimentação, é suficiente para testar nosso hardware/software? Se não, por que não deixar a automação cobrir todas as permutações e todos os casos extremos, para não termos que fazer isso? E, só por garantia, por que não executar a mesma coisa 100 vezes... apenas porque podemos! Isso pode se tornar muito mais sofisticado e complicado (por exemplo, testes de protocolo, testes de filtragem do ADC, etc.), mas este artigo vai se ater apenas ao básico.

O script de teste é bastante básico. Supondo que seu Arduino (ou seja, dispositivo embutido sob teste) tenha sido carregado com os arquivos de programação adequados e tudo tenha sido conectado corretamente, você executaria o script de teste no seu computador assim:

python -m pytest test_arduino_hil.py

Isso acionará o Analog Discovery 2 para varrer a faixa de tensão do ADC do Arduino e validar que a tensão de entrada corresponde à tensão de saída lida do ADC. Em vez de varrer manualmente com uma fonte de bancada, o script fez isso por você com um único comando. Para um exemplo trivial como este, parece desnecessário, mas esse processo traz benefícios quando combinando testes de maneira semelhante a uma regressão.
Aliando isso ao nosso sistema CI/CD, podemos ver as seguintes etapas sendo executadas e aprovadas:

As etapas mencionadas acima são:

1. docker_build: Construir o ambiente. Neste caso, estamos usando imagens docker em PCs Linux e dispositivos baseados em ARM como Raspberry Pis
2. arduino_load_test: Compilar e carregar o código do Arduino e validar se tudo funcionou.
3. arduino_hil_test: Execute o teste de hardware em loop em um Arduino físico.

Se olharmos mais de perto para a seção de Testes, podemos ver que esses testes foram capturados e analisados pelo Gitlab:

Agora temos uma configuração de software que nos permite testar nosso design localmente e remotamente (usando nosso sistema CI/CD). Isso permite que o engenheiro de design continue focando em projetar em vez de testar e depurar posteriormente.

Conclusão

Neste artigo, revisamos o conceito de usar testes automatizados para validar um design de forma concorrente e a posteriori. Seja uma pequena reestruturação ou uma mudança de design monumental, ter testes de regressão automatizados compensa ao eliminar consequências não intencionadas (ou seja, corrigir uma coisa, quebrar outra). O processo encorajado é escrever esses scripts de teste junto com o processo de desenvolvimento do design (similar ao Desenvolvimento Orientado por Testes). Acoplar esses testes automatizados com um sistema CI/CD adiciona um bônus extra para demonstrar que nossas placas estão funcionando em um alvo remoto e podem ser testadas por qualquer pessoa, em qualquer lugar, a qualquer momento.

Gostaria de saber mais sobre como a Altium pode ajudá-lo com o seu próximo projeto de PCB? Fale com um especialista na Altium ou descubra mais sobre os principais problemas de DFM e suas soluções. Você pode baixar uma versão de avaliação gratuita do Altium Designer aqui.