Se você fizer uma busca por "Teste Hardware-in-the-Loop", frequentemente encontrará exemplos de sistemas complexos e em tempo real. Este artigo da National Instruments, por exemplo, oferece uma boa explicação e contexto sobre o que é hardware-in-the-loop (HIL) e fornece um exemplo de teste de unidades de controle eletrônico dentro de um automóvel. Neste artigo, vamos focar em uma versão menor e mais simplificada dos conceitos de teste HIL.
Para os propósitos deste artigo, vamos definir o teste hardware-in-the-loop de uma maneira um pouco diferente da forma como é apresentado convencionalmente (por exemplo, em aplicações automobilísticas). Vamos observar três diferentes camadas de complexidade quando se trata de testar um produto.
Nesta forma de teste, um engenheiro testará manualmente o dispositivo. Isso pode consistir em sondar pontos de teste em uma placa com um multímetro digital, observar formas de onda em um osciloscópio ou analisar manualmente uma leitura de telemetria em uma tela de computador. O engenheiro testará o produto através de teste de verificação de design manual.
Esta configuração de teste executa as mesmas medições e verificações normalmente feitas por um engenheiro, mas é realizada por um computador de maneira automatizada. O computador anfitrião se comunica diretamente com os instrumentos (por exemplo, multímetros, osciloscópios, etc.), analisa a telemetria do dispositivo e, em seguida, verifica o conjunto de testes com base nos critérios estabelecidos pelo engenheiro.
O teste Hardware-in-the-Loop leva o teste automatizado a um novo nível, adicionando estímulos extras para simular uma aplicação do mundo real. Por exemplo, o dispositivo sob teste (DUT) pode ter uma série de sensores que requerem excitação. O equipamento de teste simularia a outra extremidade desses sensores para excitar o lado do sensor do DUT. Outro exemplo poderia ser algo tão simples quanto dirigir tráfego RS-422 para um receptor RS-422 no DUT. A ideia é que somos capazes de introduzir novos estímulos no DUT, ler de volta a telemetria do computador anfitrião e ajustar nossos testes adequadamente, se necessário (por exemplo, dirigir tráfego RS-422 mais rápido e maior após passar em um teste inicial).
Com base na aplicação, pode ser claro por que alguém escolheria adotar o teste de hardware em loop em vez do teste automatizado (e certamente do teste manual). Se alguém está tentando integrar um sistema complexo ou (sistemas de sistemas), com muitos estímulos externos necessários, um teste básico de verificação automatizada não será suficiente. Considere um carregador de bateria básico. Embora você possa simular uma fonte de alimentação, carga e bateria para testar seu circuito controlador (fisicamente ou por meio de software), seria mais realista usar uma fonte de alimentação real, bateria e carga para testar o design. Além disso, se você puder automatizar esse processo, seus engenheiros agora podem gastar seu tempo no desenvolvimento em vez de testar.
Ao decidir se deve adotar o teste de hardware em loop, deve-se considerar os seguintes fatores:
Uma vez que você tenha considerado estes e outros fatores, você pode começar a tomar uma decisão sobre se deve continuar com testes manuais ou investir em testes automatizados/hardware-in-the-loop.
Baseado em minha experiência, descobri que, sem dúvida, a entrada mais fácil para testes hardware-in-the-loop seria usando uma estrutura de teste completa como a fornecida pela National Instruments (NI). A NI tem uma plataforma de hardware/software completa que é plug and play. Aqui estão alguns prós e contras a considerar ao pensar em uma estrutura completa:
Durante o tempo em que trabalhei com sistemas complexos, o LabVIEW foi minha escolha para testes automatizados — incluindo a construção de um pipeline completo de Integração Contínua e Implantação Contínua para projetos e VIs do LabVIEW. À medida que migrei para sistemas menores que exigiam suporte mais simples em loop real, comecei a migrar para hardware personalizado ou comercial pronto para uso (COTS) e scripts Python (usando o pytest framework). Novamente, tudo depende da aplicação e, como mencionado anteriormente, tempo de teste, recorrência de teste e equipamento de teste são os principais fatores que direcionam essa decisão.
Neste artigo, revisamos o conceito de teste em loop real e como ele difere dos testes manuais e automatizados. Também analisamos os benefícios de adotar o teste em loop real e como avaliar se é realmente o que o usuário precisa. Por fim, discutimos algumas maneiras de começar. Embora o teste em loop real possa não ser para todos, é claro que para a aplicação certa, o investimento trará retornos muito rapidamente.
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.