Processo de desenvolvimento para um projeto embarcado com alterações significativas de hardware

Question

Tenho uma boa ideia sobre o processo de desenvolvimento Agile, mas não tenho ideia de como mapeá-lo para um projeto incorporado com alterações significativas de hardware.

Descreverei abaixo o que estamos fazendo atualmente (forma Ad-hoc, ainda sem processo definido).As alterações são divididas em três categorias e processos diferentes são utilizados para cada uma delas:

1. mudança completa de hardware

   exemplo :use um IP de codec de vídeo diferente

   a) Estude o novo IP

   b) Simulação RTL/FPGA

   c) Implemente a interface legada - vá para b)

   d) Aguarde até que o hardware (tape out) esteja pronto

   f) Teste no hardware real

2. melhoria de hardware

   exemplo :melhorar a qualidade de exibição da imagem, melhorando o algoritmo subjacente

   a) Simulação RTL/FPGA

   b) Espere até que o hardware e teste no hardware

3. Pequena alteração

   exemplo :alterar apenas o mapeamento de registro de hardware

   a) Aguarde até o hardware e teste no hardware

A preocupação é que parece que não temos muito controle e confiança sobre a maturidade do software para as alterações de hardware.Essa confiança é fundamental para o sucesso do projeto, pois o cronograma de atualização é sempre muito apertado e o cliente desejava uma mudança contínua ao atualizar para uma nova versão de hardware.

Como você gerenciou esse tipo de mudança de hardware?Você resolveu isso com uma Camada de Abstração de Hardware (HAL)?Você fez um teste automático para a camada HAL?HAL funciona para um produto maduro, mas pode não funcionar bem para um produto de consumo que muda rapidamente.Como você testou quando a plataforma de hardware nem estava pronta?Você tem processos bem documentados para esse tipo de mudança?

Answer 1

Adicionar uma Camada de Abstração de Hardware (HAL) é essencial se você espera que o hardware subjacente mude durante a vida útil do produto.Se feito corretamente, você poderá criar testes unitários para ambos os lados do HAL.

Por exemplo, o HAL é simplesmente uma API da sua GUI para o hardware de exibição real.Você pode escrever um driver de hardware falso que não acione um dispositivo físico, mas responda de maneiras diferentes para verificar se as camadas superiores da API lidam com todos os códigos de resposta possíveis do HAL.Talvez ele crie um bitmap na memória (em vez de direcionar E/S externa) que você pode comparar com um bitmap esperado para ver se está sendo renderizado corretamente.

Da mesma forma, você pode escrever um teste de unidade que forneça uma boa cobertura do HAL das camadas superiores, para poder verificar se o seu novo driver de hardware está respondendo corretamente.Usando o exemplo de exibição, você percorre todos os modos de tela possíveis, elementos de interface, métodos de rolagem, etc.Infelizmente, para esse teste, você precisará observar fisicamente a tela, mas poderá executar lado a lado com hardware antigo para ver melhorias de velocidade ou desvios de comportamento.

Mas voltando ao seu exemplo.Quão diferente é mudar para outro codec de vídeo?Você ainda está apenas empurrando bytes nas camadas superiores.Se você estiver implementando um codec conhecido, seria útil ter arquivos de origem que atuem como um teste de unidade (cobrindo uma gama completa de formatos de dados possíveis) para garantir que seu codec os decodifique e os exiba corretamente (sem travar!).A decodificação para um bitmap na memória é um bom teste de unidade - você pode simplesmente comparar a memória com um quadro descompactado bruto.

Espero que isso ajude.Se não, faça mais perguntas.