Validação de sistemas embebidos: o comportamento do sistema inteiro

A validação de sistemas embebidos verifica se o dispositivo final faz o que os requisitos e os utilizadores precisam, em hardware real e no seu ambiente real.

O Midair executa a suite de validação na sua bancada e guarda cada execução como um registo. Cada resultado aponta para o requisito que verifica.

Iniciar o seu piloto Ver o grafo de rastreabilidade
execução de validação 57 · bench-b · fw 3.1.0 Exemplo 
midair  run 57 · builder.conf.lock 3f9c2e1
te      --tester-req="REQ-UPD-03|REQ-PWR-02"
test    update/wifi_credentials_kept
        REQ-UPD-03  FAILED  expected PASSED
console wpa_supplicant: no network configured
test    power/cut_during_update
        REQ-UPD-03 REQ-PWR-02  PASSED
power   outlet 2: off 2 s, on
test    power/cold_boot_x50
        REQ-PWR-02  PASSED
midair  run 57 saved: 3 tests, 1 unexpected

O que é a validação de sistemas embebidos.E como difere da verificação e dos testes.

A validação faz uma só pergunta: o produto final faz o trabalho para que foi feito? Num sistema embebido, a resposta vem do dispositivo real, em hardware real, com a rede, a alimentação e os outros dispositivos à volta.

A verificação faz outra pergunta: cada parte cumpre a sua especificação? Uma revisão de código, uma análise estática ou um teste unitário verificam. Um cenário próximo do uso real, no dispositivo montado, valida.

Os testes são a forma de obter evidências para as duas. Um teste executa o produto, compara o resultado com um veredicto esperado e regista o que aconteceu.

Verificação

Construímos bem o produto?

Compara com
A especificação e o desenho: interfaces, regras de código, mapas de registos, detalhes do protocolo.
Exemplo num gateway Wi-Fi
O Visao reporta um overflow de inteiro em otp.cpp antes de o código chegar à placa.
Deixa
Ocorrências, notas de revisão e resultados de testes unitários para cada parte.

Validação

Construímos o produto certo?

Compara com
Os requisitos e as condições de uso real: a rede, a alimentação, os dispositivos à volta.
Exemplo num gateway Wi-Fi
O gateway liga-se à rede Wi-Fi em menos de 30 s depois de um corte de energia, na placa de produção.
Deixa
Um registo por requisito: que testes correram, em que build e bancada, e com que resultado.

Testes

O que faz realmente o produto?

Compara com
Um veredicto esperado para cada teste, escrito antes da execução.
Exemplo num gateway Wi-Fi
O wifi/connect_ping associa-se, obtém um endereço por DHCP e envia quatro pings. Qualquer perda faz o teste falhar.
Deixa
Veredictos, logs e mensagens do teste. São as evidências que a verificação e a validação usam.

Requisitos, testes, evidências.Siga um requisito ao longo de uma execução.

Escolha um requisito. O grafo mostra os testes com a sua etiqueta e as evidências que esses testes deixaram no registo da execução.

execução de validação 57 · bench-b · fw 3.1.0Exemplo

Requisitos

Testes e verificações

  • wifi/connect_ping PASSED
  • wifi/reconnect_after_ap_restart PASSED
  • update/wifi_credentials_kept FAILED · esperado PASSED
  • power/cut_during_update PASSED
  • power/cold_boot_x50 PASSED
  • delta/listening_ports PASSED
  • delta/binary_hardening FAILED · esperado PASSED
  • visao/new_findings FAILED · esperado PASSED

Evidências

  • Registo da execuçãoExecução 57: árvore de resultados, veredictos face ao trc.xml, parâmetros
  • Mensagem do teste0% of the packets to 192.168.4.1 were lost
  • Log da consolawpa_supplicant: no network configured, depois da atualização
  • Log de energiaTomada 2 desligada durante 2 s e ligada; traço de corrente de um PPK2
  • DeltaAs portas em escuta coincidem com a linha de base
  • DeltaBinary /usr/bin/agent lacks required mitigation: stack canary
  • Visaootp.cpp:20:20 arithm/integer/overflow (MISRA 12.4)
  • Visaootp.cpp:31:5 cpp/string/no_null_terminator (MISRA 21.17)

REQ-NET-01 Liga-se à rede Wi-Fi configurada em menos de 30 s

Coberto. Todos os resultados são os esperados.

Testes
2
Como esperado
2
Inesperados
0
Evidências
2

wifi/connect_ping PASSED
wifi/reconnect_after_ap_restart PASSED

REQ-UPD-03 Mantém as credenciais Wi-Fi depois de uma atualização do firmware

Coberto. Há resultados diferentes do esperado.

Testes
2
Como esperado
1
Inesperados
1
Evidências
3

update/wifi_credentials_kept FAILED
power/cut_during_update PASSED

REQ-PWR-02 Arranca e volta a ligar-se depois de um corte de energia

Coberto. Todos os resultados são os esperados.

Testes
2
Como esperado
2
Inesperados
0
Evidências
2

power/cut_during_update PASSED
power/cold_boot_x50 PASSED

REQ-SEC-04 Só escuta nas portas documentadas

Coberto. Todos os resultados são os esperados.

Testes
1
Como esperado
1
Inesperados
0
Evidências
1

delta/listening_ports PASSED

REQ-SEC-05 Os binários são compilados com stack canary

Coberto. Há resultados diferentes do esperado.

Testes
1
Como esperado
0
Inesperados
1
Evidências
1

delta/binary_hardening FAILED

REQ-SW-06 O código OTP não tem overflows nem strings sem terminador

Coberto. Há resultados diferentes do esperado.

Testes
1
Como esperado
0
Inesperados
1
Evidências
2

visao/new_findings FAILED

REQ-LOG-07 Regista o motivo de cada reinício

Não coberto. Nenhum teste da suite tem esta etiqueta.

Testes
0
Como esperado
0
Inesperados
0
Evidências
0

De onde vêm as ligações

  1. Cada teste da suite tem os IDs dos requisitos que verifica, como etiqueta no package.xml.
  2. O Test Environment pode executar só os testes de um requisito, por exemplo depois de uma alteração que lhe toca.
  3. O trc.xml guarda o veredicto esperado de cada teste. O registo da execução guarda o veredicto obtido ao lado.
  4. O Bublik, o visualizador de resultados onde o Midair pode publicar, filtra os resultados por requisito.

A lista de requisitos fica com a sua equipa, na ferramenta que já usa. O Midair não substitui uma ferramenta de gestão de requisitos.

tests/update/package.xml<script name="wifi_credentials_kept">
    <req id="REQ-UPD-03"/>
</script>
<script name="cut_during_update">
    <req id="REQ-UPD-03"/>
    <req id="REQ-PWR-02"/>
</script>./run.sh --cfg=bench-b --tester-req=REQ-UPD-03

O que responde uma execução de validação.Seis perguntas de uma revisão de lançamento.

Cada início no Midair cria um novo registo com a sua própria configuração. O Midair nunca escreve por cima de uma execução, por isso as respostas continuam válidas mais tarde.

Que build validámos?
builder.conf.lockO builder.conf.lock fixa o commit exato de cada componente do build.
Em que bancada, com que definições?
env.bench-bOs valores da bancada vêm de env.<bench> e run.conf.<bench>, e a execução guarda-os.
O que esperávamos?
trc.xmlO trc.xml indica o veredicto esperado de cada teste. Assim, uma falha conhecida não esconde uma nova.
O que aconteceu?
árvore de resultadosA árvore de resultados mostra cada teste com os parâmetros, o veredicto obtido, as linhas de erro e as mensagens. O log da consola fica guardado com ela.
O próprio dispositivo mudou?
DeltaO Delta compara o dispositivo com uma linha de base: processos, portas, ficheiros, pacotes e o hardening dos binários.
Que testes existem?
te-docO te-doc gera um catálogo da suite em HTML ou PDF e um relatório dos resultados.

Quando executar uma validação.Cinco momentos comuns.

  1. Antes de um lançamento, depois de os componentes passarem nos seus próprios testes.
  2. Depois de uma grande alteração ao firmware, para ver se o comportamento mudou noutro ponto.
  3. Depois de uma nova revisão da placa ou de uma nova configuração, com a mesma suite.
  4. Antes de uma implementação maior, quando mais dispositivos e locais dependem do resultado.
  5. Quando uma regressão é difícil de explicar, para repetir o registo antigo ao lado do novo.

Perguntas.Respostas curtas.

O que é a validação de sistemas embebidos?

A validação de sistemas embebidos verifica se o dispositivo final cumpre os requisitos e as necessidades dos utilizadores em condições reais. Corre no hardware real, com a rede, a alimentação e os dispositivos que o produto vai encontrar no uso.

Qual é a diferença entre verificação e validação em sistemas embebidos?

A verificação confirma que cada parte cumpre a sua especificação, por exemplo com revisão de código, análise estática ou testes unitários. A validação confirma que o produto montado faz o trabalho certo no seu ambiente real. Os testes produzem as evidências para as duas.

O que são a validação e os testes de programas num sistema embebido?

A validação de programas executa o software embebido no hardware de destino e compara-o com os requisitos. Os testes são o método: cada teste tem um veredicto esperado e a execução regista o que aconteceu de facto.

O Midair faz a rastreabilidade entre requisitos e testes?

Em parte. Os testes de uma suite do Test Environment têm etiquetas de requisitos, e uma execução pode escolher os testes por requisito. O registo da execução guarda os veredictos e as evidências de cada teste. A lista de requisitos fica com a sua equipa, na sua própria ferramenta.

O Midair certifica o meu produto?

Não. O Midair produz evidências: registos de execução, logs, relatórios do Delta e ocorrências do Visao. Um organismo de certificação ou o seu próprio processo decide o que essas evidências provam.

De que preciso para começar?

Um build, uma bancada com o dispositivo e uma lista curta de requisitos que quer verificar antes de um lançamento. O TS Factory pode escrever os primeiros testes a partir de uma descrição curta, e a sua equipa acrescenta as etiquetas dos requisitos.

Comece por um requisito.Depois acrescente o seguinte.

Traga um build, uma bancada e o requisito que mais o preocupa. O Midair regista cada execução, por isso as evidências estão lá no momento do lançamento.

Iniciar o seu piloto