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

Nos últimos anos, realizamos extensas consultas e treinamentos com equipes de desenvolvimento de software durante o desenvolvimento de 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, que leva meses, identificamos cinco etapas principais que formam uma abordagem passo a passo, permitindo que nossa equipe comece no caminho certo.

Etapa 1: Definir 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, dispensando explicações adicionais.

A 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 isso será alcançado, e garantindo clareza e testabilidade. Consequentemente, uma arquitetura eficaz depende de requisitos bem definidos.

Etapa 2: Diferencie Arquitetura de Design

Em nossa experiência, 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 nível mais alto do COMO, definindo os recursos duradouros do produto e tornando-o desafiador para alterações após sua implementação. Ela exige uma análise cuidadosa dos usos pretendidos e permitidos do produto para garantir que seja feita corretamente.

O design de um sistema representa a camada intermediária do como. Embora a arquitetura descreva os recursos gerais, 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 dispositivo específicos, o RTOS utilizado (se houver) e as especificações das interfaces entre os 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 na fase de design, os engenheiros podem começar a implementar os diversos componentes em paralelo. Embora os desafios possam variar de acordo com o setor, eles geralmente se enquadram em três categorias principais: cumprimento de prazos em tempo real, testes e gerenciamento da 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 de tempo não real, tempo real flexível e tempo real rígido. Destes, os prazos flexíveis costumam ser os mais difíceis de definir, testar e implementar com clareza. Uma vez identificados os prazos, a etapa inicial do processo de arquitetura é transferir 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 oferece dois benefícios principais. Primeiro, simplifica o design e a implementação do software não em tempo real. Ao remover as restrições de tempo da maior parte do código, até mesmo desenvolvedores iniciantes podem contribuir sem comprometer a segurança do usuário. Segundo, a consolidação da funcionalidade em tempo real facilita a análise e garante que todos os prazos sejam cumpridos de forma consistente.

Etapa 4: Projete com os testes em mente

É essencial testar todos os sistemas embarcados 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 de sistema confirmaram que o produto como um todo atende ou excede os requisitos especificados. Recomenda-se 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 realizados para garantir que subconjuntos dos subsistemas, conforme descritos nos diagramas de arquitetura, interajam adequadamente e produzam os resultados esperados. Esses testes são normalmente desenvolvidos por uma equipe de testes ou por um indivíduo do departamento de engenharia de software.

3. Os testes unitários garantem que os componentes individuais do software, conforme definidos na fase intermediária de projeto, operem conforme o esperado. Esses testes concentram-se na API (Interface de Programação de Aplicativos) pública que o componente oferece a outros componentes. Normalmente, os testes unitários são desenvolvidos pelas mesmas pessoas que escrevem o código a ser 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 de aceitação de fábrica, mas esse processo geralmente é mais simples do que os testes de integração e unitários, que exigem maior visibilidade interna da operação do dispositivo. Para agilizar o desenvolvimento, o uso e a manutenção de testes de integração e unitários, é aconselhável projetar o firmware de forma alinhada a 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 a personalização do produto. Para planejar mudanças de forma eficaz, é crucial identificar primeiro os tipos de alterações que provavelmente ocorrerão no seu produto. Em seguida, o firmware deve ser projetado para acomodar essas alterações da maneira mais eficiente possível. Uma arquitetura bem projetada permite o gerenciamento da diversidade de recursos por meio de uma única compilação com alternâncias em tempo de compilação e/ou execução, além de permitir a adição contínua de novos recursos sem interromper a funcionalidade existente.