Nuestro proceso de desarrollo de firmware se basa en un enfoque de cinco pasos

En los últimos años, hemos realizado amplias consultas y capacitaciones con equipos de desarrollo de software durante el desarrollo de firmware para productos y familias de productos exitosos y duraderos. Si bien crear una arquitectura de firmware robusta y rediseñar software heredado puede ser un proceso complejo que requiere meses de trabajo, hemos identificado cinco pasos clave que conforman un enfoque paso a paso que permite a nuestro equipo comenzar con buen pie.

Paso 1: Definir los requisitos

Antes de diseñar un sistema embebido o su firmware, es fundamental contar con requisitos claros. Unos requisitos bien definidos especifican qué hará el producto por el usuario, sin detallar cómo se alcanzarán estos objetivos. Es fundamental que cada enunciado de requisito sea inequívoco y comprobable. Un enunciado inequívoco es claro y conciso, y no requiere mayor explicación.

La testabilidad es un factor clave; un requisito bien redactado debe permitir la creación de pruebas sencillas para verificar su cumplimiento. Un conjunto adecuado de requisitos consta de declaraciones que comienzan con «el [producto] debería...», centrándose en lo que se necesita en lugar de en cómo se logra, y garantizando la claridad y la testabilidad. Por consiguiente, una arquitectura eficaz se basa en requisitos bien definidos.

Paso 2: Diferenciar entre arquitectura y diseño

Según nuestra experiencia, muchos ingenieros y sus gerentes tienen dificultades para distinguir entre los diversos aspectos de la ingeniería de firmware. La arquitectura del sistema representa el nivel más alto de CÓMO, ya que define las características duraderas del producto y dificulta su modificación una vez establecido. Requiere una cuidadosa consideración de los usos previstos y permitidos del producto para garantizar su correcta ejecución.

El diseño de un sistema representa la capa intermedia de cómo funciona. Si bien la arquitectura describe las características generales, no especifica los nombres de las funciones ni de las variables. Un documento de diseño de firmware completa estos detalles, incluyendo los nombres de las tareas y las responsabilidades dentro de subsistemas o controladores de dispositivos específicos, el sistema operativo en tiempo real (RTOS) utilizado (si lo hay) y las especificaciones de las interfaces entre subsistemas.

La fase de implementación representa el nivel más bajo de la jerarquía de gestión de proyectos. Una vez definidas las interfaces en la etapa de diseño, los ingenieros pueden comenzar a implementar los distintos componentes en paralelo. Si bien los desafíos varían según el sector, suelen clasificarse en tres categorías principales: cumplimiento de plazos, pruebas y gestión de la diversidad. Estos problemas se abordan en los tres pasos finales.

Paso 3: Gestión del tiempo

Algunos requisitos de producto especificarán plazos explícitos. Normalmente, los productos incluyen una combinación de requisitos de tiempo no real, de tiempo real flexible y de tiempo real estricto. De estos, los plazos flexibles suelen ser los más difíciles de definir con claridad, probar e implementar. Una vez identificados los plazos, el primer paso del proceso arquitectónico es transferir al hardware la mayor cantidad posible de requisitos urgentes.

La separación de la funcionalidad en tiempo real del software principal ofrece dos ventajas clave. En primer lugar, simplifica el diseño y la implementación del software no en tiempo real. Al eliminar las limitaciones de tiempo de la mayor parte del código, incluso los desarrolladores principiantes pueden contribuir sin comprometer la seguridad del usuario. En segundo lugar, la consolidación de la funcionalidad en tiempo real facilita el análisis y garantiza el cumplimiento constante de todos los plazos.

Paso 4: Diseñar teniendo en cuenta las pruebas

Es fundamental probar cada sistema embebido en múltiples niveles. En muchos casos, realizar pruebas a distintos niveles no solo es valioso, sino también obligatorio.

Los niveles de prueba más comunes incluyen

:

1. Las pruebas del sistema han confirmado que el producto en su conjunto cumple o supera los requisitos especificados. Se recomienda que estas pruebas se realicen fuera del departamento de ingeniería, aunque pueden incorporarse en un conjunto de pruebas diseñado por ingenieros.

2. Se realizan pruebas de integración para garantizar que los subconjuntos de los subsistemas, tal como se describe en los diagramas de arquitectura, interactúen correctamente y produzcan los resultados esperados. Estas pruebas suelen ser desarrolladas por un equipo de pruebas o por una persona del departamento de ingeniería de software.

3. Las pruebas unitarias garantizan que los componentes de software individuales, definidos en la etapa intermedia de diseño, funcionen según lo previsto. Estas pruebas se centran en la API (Interfaz de Programación de Aplicaciones) pública que el componente ofrece a otros componentes. Normalmente, las pruebas unitarias son desarrolladas por las mismas personas que escriben el código que se prueba.

De los tres tipos de pruebas, las pruebas de sistema son las más sencillas de desarrollar. Puede que se requiera un arnés de pruebas para las pruebas de ingeniería y aceptación en fábrica, pero este proceso suele ser más sencillo que las pruebas de integración y unitarias, que requieren mayor visibilidad interna del funcionamiento del dispositivo. Para optimizar el desarrollo, el uso y el mantenimiento de las pruebas de integración y unitarias, es recomendable diseñar el firmware de forma que se ajuste a un marco de pruebas de software. El enfoque más eficaz es estructurar las interacciones entre todos los componentes de software en los niveles que se pretenden probar.

Paso 5: Prepárese para el cambio

Durante la fase de arquitectura del firmware, es fundamental priorizar la gestión de la diversidad de funciones y las personalizaciones del producto. Para planificar eficazmente los cambios, es crucial identificar primero los tipos de cambios que probablemente se produzcan en el producto. Posteriormente, el firmware debe diseñarse para adaptarse a estos cambios de la manera más eficiente posible. Una arquitectura bien diseñada permite gestionar la diversidad de funciones mediante una única compilación con opciones de tiempo de compilación o de ejecución, a la vez que permite la incorporación fluida de nuevas funciones sin interrumpir la funcionalidad existente.