Notre processus de développement de firmware est basé sur une approche en cinq étapes

Ces dernières années, nous avons mené des consultations et des formations approfondies auprès des équipes de développement logiciel, tout en développant des micrologiciels pour des produits et des gammes de produits performants et durables. Créer une architecture de micrologiciel robuste et repenser l'architecture de logiciels existants peut être un processus complexe et s'étalant sur plusieurs mois. Nous avons donc identifié cinq étapes clés qui constituent une approche progressive, permettant à notre équipe de partir du bon pied.

Étape 1 : Définir les exigences

Avant de concevoir un système embarqué ou son firmware, des exigences claires sont essentielles. Des exigences bien définies précisent ce que le produit apportera à l'utilisateur, sans détailler comment ces objectifs seront atteints. Il est essentiel que chaque énoncé d'exigence soit clair et testable. Un énoncé clair et concis ne nécessite aucune explication supplémentaire.

La testabilité est un facteur clé ; une exigence bien rédigée doit permettre la création simple de tests pour vérifier sa conformité. Un ensemble d'exigences approprié se compose d'énoncés commençant par « le [produit] devrait… », se concentrant sur les besoins plutôt que sur les moyens d'y parvenir, et garantissant clarté et testabilité. Par conséquent, une architecture efficace repose sur des exigences bien définies.

Étape 2 : Différencier l'architecture et le design

D'après notre expérience, de nombreux ingénieurs et leurs responsables ont du mal à distinguer les différents aspects de l'ingénierie des micrologiciels. L'architecture système représente le niveau le plus élevé du « COMMENT », définissant les fonctionnalités durables du produit et rendant sa modification difficile une fois établie. Elle nécessite une analyse minutieuse des utilisations prévues et autorisées du produit pour garantir une mise en œuvre correcte.

La conception d'un système représente la couche intermédiaire du « comment ». Si l'architecture décrit les grandes caractéristiques, elle ne précise pas les noms des fonctions ou des variables. Un document de conception de micrologiciel complète ces détails, notamment les noms et responsabilités des tâches au sein de sous-systèmes ou de pilotes de périphériques spécifiques, le RTOS utilisé (le cas échéant) et les spécificités des interfaces entre les sous-systèmes.

La phase de mise en œuvre représente le niveau le plus bas de la hiérarchie de gestion de projet. Une fois les interfaces clairement définies dès la conception, les ingénieurs peuvent commencer à implémenter les différents composants en parallèle. Si les défis varient selon le secteur, ils se répartissent généralement en trois grandes catégories : le respect des délais en temps réel, les tests et la gestion de la diversité. Ces enjeux sont abordés lors des trois dernières étapes.

Étape 3 : Gestion du temps

Certaines exigences produit précisent des contraintes de temps explicites. Généralement, les produits combinent des exigences non temps réel, temps réel souple et temps réel strict. Parmi celles-ci, les délais souples sont souvent les plus difficiles à définir clairement, à tester et à mettre en œuvre. Une fois les délais identifiés, la première étape du processus d'architecture consiste à transférer autant d'exigences urgentes que possible du logiciel vers le matériel.

La séparation des fonctionnalités temps réel du logiciel principal offre deux avantages majeurs. Premièrement, elle simplifie la conception et l'implémentation des logiciels non temps réel. En supprimant les contraintes de temps sur la majeure partie du code, même les développeurs novices peuvent contribuer sans compromettre la sécurité des utilisateurs. Deuxièmement, la consolidation des fonctionnalités temps réel facilite l'analyse et garantit le respect systématique des délais.

Étape 4 : Concevoir en pensant aux tests

Il est essentiel de tester chaque système embarqué à plusieurs niveaux. Dans de nombreux cas, tester à différents niveaux est non seulement utile, mais aussi obligatoire.

Les niveaux de tests les plus courants comprennent

1. Les tests système ont confirmé que le produit dans son ensemble répond aux exigences spécifiées, voire les dépasse. Il est recommandé que ces tests soient développés en dehors du service d'ingénierie, bien qu'ils puissent être intégrés à un ensemble de tests conçu par les ingénieurs.

2. Des tests d'intégration sont réalisés pour garantir que les sous-ensembles des sous-systèmes, tels que décrits dans les diagrammes d'architecture, interagissent correctement et produisent les résultats escomptés. Ces tests sont généralement développés par une équipe de test ou un membre du département d'ingénierie logicielle.

3. Les tests unitaires garantissent que les composants logiciels individuels, tels que définis lors de la phase de conception intermédiaire, fonctionnent comme prévu. Ces tests se concentrent sur l'API publique (interface de programmation d'application) que le composant met à disposition des autres composants. Généralement, les tests unitaires sont développés par les mêmes personnes qui écrivent le code testé.

Parmi les trois types de tests, les tests système sont les plus simples à développer. Un harnais de test peut être nécessaire pour les tests d'ingénierie et de recette en usine, mais ce processus est généralement plus simple que les tests d'intégration et unitaires, qui nécessitent une meilleure visibilité interne sur le fonctionnement de l'appareil. Pour optimiser le développement, l'utilisation et la maintenance des tests d'intégration et unitaires, il est conseillé de concevoir le firmware conformément à un cadre de tests logiciels. L'approche la plus efficace consiste à structurer les interactions entre tous les composants logiciels aux niveaux que vous souhaitez tester.

Étape 5 : Préparez-vous au changement

Lors de la phase d'architecture du firmware, il est essentiel de prioriser la gestion de la diversité des fonctionnalités et des personnalisations du produit. Pour anticiper efficacement les changements, il est crucial d'identifier d'abord les types de modifications susceptibles d'être apportées à votre produit. Le firmware doit ensuite être conçu pour s'adapter à ces changements de la manière la plus efficace possible. Une architecture bien conçue permet de gérer la diversité des fonctionnalités via une seule build, avec des options de compilation et/ou d'exécution, tout en permettant l'ajout transparent de nouvelles fonctionnalités sans perturber les fonctionnalités existantes.