Nosso processo de desenvolvimento de firmware é baseado em uma abordagem de cinco etapas

Nos últimos anos, conduzimos extensas consultas e treinamentos com equipes de desenvolvimento de software enquanto desenvolvíamos firmware para produtos e famílias de produtos bem-sucedidos e duradouros. Embora criar uma arquitetura de firmware robusta e reestruturar software legado possa ser um processo complexo de meses de duração, identificamos cinco etapas principais que formam uma abordagem passo a passo, permitindo que nossa equipe comece no caminho certo.

Etapa 1: Defina os requisitos

Antes que um sistema embarcado ou seu firmware possam ser projetados, requisitos claros são essenciais. Requisitos bem definidos especificam o que o produto fará para o usuário sem detalhar como esses objetivos serão alcançados. É essencial que cada declaração de requisito seja inequívoca e testável. Uma declaração inequívoca é clara e concisa, não exigindo mais explicações.

Testabilidade é um fator-chave; um requisito bem escrito deve permitir a criação direta de testes para verificar seu cumprimento. Um conjunto adequado de requisitos consiste em declarações que começam com 'o [produto] deve ...', focando no que é necessário em vez de como é alcançado, e garantindo clareza e testabilidade. Consequentemente, a arquitetura eficaz depende de requisitos bem definidos.

Etapa 2: Diferencie Arquitetura e Design

Nossa experiência mostra que muitos engenheiros e seus gerentes têm dificuldade em distinguir entre os vários aspectos da engenharia de firmware. A arquitetura do sistema representa o mais alto nível de COMO, definindo os recursos duradouros do produto e tornando desafiador alterá-lo uma vez estabelecido. Requer consideração cuidadosa dos usos pretendidos e permitidos do produto para garantir que seja feito corretamente.

O design de um sistema representa a camada intermediária de como. Enquanto a arquitetura descreve os recursos amplos, ela não especifica nomes de funções ou variáveis. Um documento de design de firmware preenche esses detalhes, incluindo nomes de tarefas e responsabilidades dentro de subsistemas ou drivers de dispositivos específicos, o RTOS usado (se houver) e as especificidades das interfaces entre subsistemas.

A fase de implementação representa o nível mais baixo da hierarquia de gerenciamento de projetos. Quando as interfaces são claramente definidas no estágio de design, os engenheiros podem começar a implementar os vários componentes em paralelo. Embora os desafios possam variar de acordo com o setor, eles normalmente se enquadram em três categorias principais: cumprimento de prazos em tempo real, testes e gerenciamento de diversidade. Essas questões são abordadas nas três etapas finais.

Etapa 3: Gerenciamento de tempo

Alguns requisitos de produto especificarão restrições de tempo explícitas. Normalmente, os produtos incluem uma combinação de requisitos não-real-time, soft-real-time e hard-real-time. Destes, os prazos soft são frequentemente os mais desafiadores para definir claramente, testar e implementar. Uma vez que os prazos são identificados, a etapa inicial no processo arquitetônico é descarregar o máximo possível de requisitos sensíveis ao tempo do software para o hardware.

A separação da funcionalidade em tempo real do software principal fornece dois benefícios principais. Primeiro, simplifica o design e a implementação do software não em tempo real. Ao remover restrições de tempo da maior parte do código, até mesmo desenvolvedores novatos podem contribuir sem comprometer a segurança do usuário. Segundo, consolidar a funcionalidade em tempo real torna mais fácil analisar e garantir que todos os prazos sejam cumpridos de forma consistente.

Etapa 4: Projete com os testes em mente

É essencial testar cada sistema embarcado em vários níveis. Em muitos casos, testar em vários níveis não é apenas valioso, mas também obrigatório.

Os níveis mais comuns de teste incluem

1. Os testes do sistema confirmaram que o produto como um todo atende ou excede os requisitos especificados. É recomendado que esses testes sejam desenvolvidos fora do departamento de engenharia, embora possam ser incorporados a um conjunto de testes projetado por engenheiros.

2. Testes de integração são conduzidos para garantir que subconjuntos dos subsistemas, conforme delineados nos diagramas de arquitetura, interajam adequadamente e produzam os resultados esperados. Esses testes são tipicamente desenvolvidos por uma equipe de teste ou indivíduo dentro do departamento de engenharia de software.

3. Testes unitários garantem que componentes de software individuais, conforme definido no estágio de design intermediário, operem conforme o pretendido. Esses testes se concentram na API (Application Programming Interface) pública que o componente oferece a outros componentes. Normalmente, os testes unitários são desenvolvidos pelos mesmos indivíduos que escrevem o código que está sendo testado.

Dos três tipos de testes, os testes de sistema são os mais simples de desenvolver. Um conjunto de testes pode ser necessário para testes de engenharia e aceitação de fábrica, mas esse processo é geralmente mais simples do que testes de integração e unidade, que exigem mais visibilidade interna na operação do dispositivo. Para agilizar o desenvolvimento, uso e manutenção de testes de integração e unidade, é aconselhável projetar o firmware de uma forma que se alinhe com uma estrutura de teste de software. A abordagem mais eficaz é estruturar as interações entre todos os componentes de software nos níveis que você pretende testar.

Etapa 5: Prepare-se para a mudança

Durante a fase de arquitetura do firmware, é essencial priorizar o gerenciamento da diversidade de recursos e personalizações do produto. Para planejar efetivamente a mudança, é crucial primeiro identificar os tipos de mudanças que provavelmente ocorrerão no seu produto. Então, o firmware deve ser projetado para acomodar essas mudanças da maneira mais eficiente possível. Uma arquitetura bem projetada permite o gerenciamento da diversidade de recursos por meio de uma única construção com switches de tempo de compilação e/ou tempo de execução, ao mesmo tempo em que permite a adição perfeita de novos recursos sem interromper a funcionalidade existente.