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

En los últimos años, hemos llevado a cabo consultas y capacitaciones exhaustivas con equipos de desarrollo de software mientras desarrollamos firmware para productos y familias de productos exitosos y duraderos. Si bien crear una arquitectura de firmware sólida y rediseñar el software heredado puede ser un proceso complejo que lleva meses, hemos identificado cinco pasos clave que forman un enfoque paso a paso que permite a nuestro equipo comenzar con el pie derecho.

Paso 1: Definir los requisitos

Antes de diseñar un sistema integrado o su firmware, es esencial contar con requisitos claros. Unos requisitos bien definidos especifican lo que el producto hará por el usuario sin detallar cómo se lograrán esos objetivos. Es esencial que cada enunciado de requisito sea inequívoco y comprobable. Un enunciado inequívoco es claro y conciso y no requiere más explicaciones.

La capacidad de prueba 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 enunciados que comienzan con "el [producto] debería...", se centran en lo que se necesita en lugar de en cómo se logra y garantizan la claridad y la capacidad de prueba. En consecuencia, 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 distintos 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 establecida. Requiere una consideración cuidadosa de los usos previstos y permitidos del producto para garantizar que se realice correctamente.

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 o las variables. Un documento de diseño de firmware completa estos detalles, incluidos los nombres de las tareas y las responsabilidades dentro de subsistemas específicos o controladores de dispositivos, el sistema operativo en tiempo real (RTOS) utilizado (si lo hay) y los detalles 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. Cuando las interfaces están claramente definidas en la etapa de diseño, los ingenieros pueden comenzar a implementar los distintos componentes en paralelo. Si bien los desafíos pueden variar según la industria, por lo general se dividen en tres categorías principales: cumplir con los plazos en tiempo real, realizar pruebas y gestionar la diversidad. Estas cuestiones se abordan en los tres pasos finales.

Paso 3: Gestión del tiempo

Algunos requisitos de productos especificarán limitaciones de tiempo explícitas. 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 que se identifican los plazos, el paso inicial en el proceso arquitectónico es transferir del software al hardware tantos requisitos sensibles al tiempo como sea posible.

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 que no es en tiempo real. Al eliminar las limitaciones de tiempo de la mayor parte del código, incluso los desarrolladores novatos 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 que se cumplan todos los plazos de forma sistemática.

Paso 4: Diseñar teniendo en cuenta las pruebas

Es esencial probar cada sistema integrado en varios niveles. En muchos casos, realizar pruebas en varios 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 desarrollen 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 describen en los diagramas de arquitectura, interactúen correctamente y produzcan los resultados esperados. Estas pruebas suelen estar a cargo de un equipo de pruebas o de una persona dentro del departamento de ingeniería de software.

3. Las pruebas unitarias garantizan que los componentes individuales del software, tal como se definen en la etapa intermedia de diseño, funcionen según lo previsto. Estas pruebas se concentran en la API (interfaz de programación de aplicaciones) pública que el componente ofrece a otros componentes. Por lo general, las pruebas unitarias las desarrollan las mismas personas que escriben el código que se está probando.

De los tres tipos de pruebas, las pruebas de sistema son las más sencillas de desarrollar. Puede que se requiera un conjunto de pruebas para las pruebas de ingeniería y aceptación de fábrica, pero este proceso suele ser más sencillo que las pruebas de integración y unitarias, que requieren una mayor visibilidad interna del funcionamiento del dispositivo. Para agilizar 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 alinee con 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 esencial priorizar la gestión de la diversidad de funciones y las personalizaciones del producto. Para planificar eficazmente los cambios, es fundamental identificar primero los tipos de cambios que es probable que se produzcan en el producto. A continuación, el firmware debe diseñarse para adaptarse a estos cambios de la forma más eficiente posible. Una arquitectura bien diseñada permite la gestión de la diversidad de funciones a través de una única compilación con opciones de tiempo de compilación o de ejecución, al tiempo que permite la incorporación fluida de nuevas funciones sin interrumpir la funcionalidad existente.