Testes de integração hardware-software para sistemas embebidos

O que são testes de integração hardware-software.Software verificado na placa real.

Os testes de integração hardware-software verificam se o firmware, os drivers e as aplicações funcionam com o hardware à sua volta. Isto inclui a placa, os barramentos, os sensores e a alimentação.

Os testes hardware-in-the-loop (HIL) são a forma habitual de o fazer. Uma máquina de teste faz o papel do mundo exterior, muda as condições de propósito e regista como o dispositivo reage.

A maioria das falhas de integração depende da temporização, da ordem e do estado. Por isso, uma execução útil guarda o build, a bancada e a saída da consola junto a cada veredicto.

Testes hardware-in-the-loop.Injete uma falha e siga o sinal.

Escolha uma falha. O diagrama mostra o caminho do sinal entre a máquina de teste, a bancada e o dispositivo. O painel mostra o que o teste regista.

Corte de energia

A máquina faz: O agente power-ctl desliga a tomada a meio de uma escrita na flash. Dois segundos depois, volta a ligá-la.
Caminho do sinal: agente power-ctl
tomada da PDU
dispositivo
consola série
máquina de teste

O teste regista

bench hil-1 · run 518 · Exemplopower    outlet 3: off during flash write
power    outlet 3: on after 2.0 s
console  U-Boot 2024.01
console  ubifs: recovery needed, replaying journal
test     power/cut_during_write    PASSED  expected PASSED

Erro no barramento

A máquina faz: O agente unix envia 500 tramas inesperadas para o barramento CAN num segundo. O dispositivo tem de continuar a enviar o seu heartbeat.
Caminho do sinal: agente unix
barramento CAN
dispositivo
consola série
máquina de teste

O teste regista

bench hil-1 · run 518 · Exemplocan      can0: 500 frames, id 0x0F0, in 1.0 s
can      heartbeat 0x701: gap of 1.8 s, limit 0.5 s
console  canbridge: rx queue full, frames dropped
test     can/burst_keeps_heartbeat FAILED  expected PASSED

Sensor atrasado

A máquina faz: A máquina mantém em baixo a linha data-ready do sensor e só a sobe 250 ms depois. O dispositivo tem de reportar o timeout.
Caminho do sinal: agente unix
linha GPIO
dispositivo
consola série
máquina de teste

O teste regista

bench hil-1 · run 518 · Exemplogpio     line 17 (DRDY): low, raised after 250 ms
console  sensor: read 0x0000, value accepted
test     sensor/late_ready_reported FAILED  expected PASSED
         no timeout reported by the device

Reset

A máquina faz: A máquina põe a linha de reset em baixo durante 100 ms. O teste mede quanto tempo o serviço demora a voltar.
Caminho do sinal: agente unix
linha de reset
dispositivo
consola série
máquina de teste

O teste regista

bench hil-1 · run 518 · Exemplogpio     line 5 (nRESET): low for 100 ms, then high
console  U-Boot 2024.01
console  Starting kernel ...
test     reset/service_back_in_10s  PASSED  7.4 s

A sequência de arranque.Seis etapas, cinco passagens.

As falhas de integração concentram-se onde uma etapa passa o controlo à seguinte. Escolha um ponto na linha do tempo para ver o que falha ali e como um teste o deteta.

Ligar · 0,0 s

Tensão que sobe devagar

O que falha: A alimentação sobe devagar e o processador arranca antes de o controlador de energia estar pronto. Alguns arranques bloqueiam e outros não.
O que a consola mostra: (nada: a consola fica em silêncio)
Como o teste o deteta: O agente power-ctl desliga e liga a tomada 50 vezes. Em cada ciclo, o banner do U-Boot tem de aparecer na consola em menos de dois segundos.

Bootloader · 0,6 s

Device tree errado

O que falha: O bootloader carrega o device tree de outra revisão da placa. O kernel procura então os periféricos nos endereços errados.
O que a consola mostra: Loading fdt: board-rev-a.dtb
Como o teste o deteta: O teste compara o nome do device tree na consola com a revisão da placa indicada na configuração da bancada.

Kernel · 2,4 s

Sistema de ficheiros raiz em falta

O que falha: Depois de uma atualização, o kernel não consegue montar a nova partição raiz e para.
O que a consola mostra: Kernel panic - not syncing: VFS: Unable to mount root fs
Como o teste o deteta: O Test Environment vigia a consola à procura do padrão de panic. Para o teste, guarda o log da consola e desliga e volta a ligar a placa.

Drivers · 3,8 s

Driver antes do regulador

O que falha: O driver de um sensor arranca antes de o regulador de tensão do sensor estar ligado. O sensor fica em falta até ao próximo reinício.
O que a consola mostra: tmp102 1-0048: error -110 reading temperature
Como o teste o deteta: O teste lista os dispositivos esperados depois de cada um de 20 arranques a frio. Basta faltar um sensor num arranque para o teste falhar.

Serviços · 5,1 s

Serviço que arranca cedo demais

O que falha: Um serviço arranca antes de a interface CAN estar ativa. Termina com erro e não volta a arrancar.
O que a consola mostra: canbridge.service: Failed with result exit-code
Como o teste o deteta: O teste verifica o estado de cada serviço depois do arranque e guarda o log do serviço que falhou.

Aplicação · 8,0 s

Reset pelo watchdog

O que falha: A aplicação demora mais a arrancar do que o timeout do watchdog. A placa reinicia e volta a arrancar, em ciclo.
O que a consola mostra: Reset cause: WDOG
Como o teste o deteta: Depois do arranque, o teste lê o estado de arranque do watchdog. Um reset pelo watchdog no último arranque faz o teste falhar.

O que uma execução guarda.A bancada faz parte do resultado.

O Test Environment lê a bancada a partir de ficheiros de configuração da suite. O Midair guarda cada arranque como um novo registo e nunca escreve por cima de um registo antigo.

conf/rcf.conf: Os agentes de teste e as máquinas onde correm, incluindo o agente power-ctl.
conf/env.<bench>: Os valores de uma bancada: endereços, portas série e números das tomadas. Vêm de variáveis de ambiente.
conf/run.conf.<bench>: Que testes e parâmetros correm nessa bancada.
conf/cs.conf.*: A configuração das máquinas e das interfaces para o Configurator, em YAML.
conf/trc.xml: O veredicto esperado de cada teste, para que uma regressão salte à vista.
conf/builder.conf.lock: Os commits exatos da suite e das suas bibliotecas.

Além destes ficheiros, o registo guarda o log da consola, o log do kernel, a árvore de resultados e a lista de falhas.

Perguntas.Respostas curtas.

O que são testes de integração hardware-software?

Os testes de integração hardware-software verificam se o firmware e o software funcionam com o hardware físico à sua volta. Cobrem barramentos, sensores, alimentação, temporização e a sequência de arranque.

O que são testes hardware-in-the-loop?

Nos testes hardware-in-the-loop (HIL), o dispositivo real corre num ciclo com uma máquina de teste. A máquina controla as entradas do dispositivo, muda a alimentação e os barramentos e regista como ele responde.

Em que difere o HIL dos testes de integração em geral?

Os testes de integração são a prática mais ampla. O HIL é uma forma de os fazer, com a placa real numa bancada. Os testes num emulador como o QEMU e os testes com vários dispositivos numa rede são outras formas.

O dispositivo precisa de um agente de teste?

Não. Os agentes de teste correm numa máquina ao lado do dispositivo. Essa máquina chega ao dispositivo através da alimentação comutada, da consola série, de GPIO, I2C, SPI, CAN, JTAG ou da rede.

Que falhas pode um teste injetar?

Um teste pode cortar a energia em tomadas de PDU, relés ou hubs USB. Pode controlar linhas GPIO, fazer transferências I2C e SPI, enviar tramas CAN e reiniciar a placa. A consola série mostra como o dispositivo reage.

Podemos começar antes de a placa estar pronta?

Sim, em parte. A mesma suite pode correr no QEMU com snapshots, e o Visao analisa o código-fonte do firmware sem o executar. Os testes dos periféricos reais esperam pela placa.

Páginas relacionadas.Capacidades e leituras.

Um build de firmwareTestes de firmwareGravação, arranque, cortes de energia e a bancada sob o controlo do teste. Todos os níveis de testeTestes de sistemas embebidosDe um posto de trabalho a uma frota, com um registo por execução. Dispositivos ligadosTestes de dispositivos IoTFrotas, versões de firmware e as condições de rede de um dia real. Vários dispositivosTestes de hardware de redeRouters, gateways e testes que precisam de muitas máquinas. SegurançaTestes de segurança de sistemas embebidosComportamento sensível para a segurança no firmware, nos dispositivos e nas suas interfaces. Antes da placaAnálise estática para sistemas embebidosO Visao em C e C++ embebido, antes de o código chegar a um dispositivo. Diário de testes embebidosTestes reproduzíveisComo os reinícios, o estado do dispositivo, o isolamento da rede e as impressões digitais das execuções tornam duas execuções comparáveis.

Comece por uma placa e uma falha.Depois junte o resto da bancada.

Traga um build de firmware e uma falha de integração difícil de reproduzir. Compare os planos na página de preços. Os preços são mensais, em euros.

Entrar na lista de espera