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

Au cours des dernières années, nous avons mené des consultations et des formations approfondies auprès des équipes de développement de logiciels tout en développant des micrologiciels pour des produits et des familles de produits performants et durables. Bien que la création d'une architecture de micrologiciel robuste et la réarchitecture de logiciels existants puissent être un processus complexe qui peut durer des mois, nous avons identifié cinq étapes clés qui constituent une approche étape par étape, permettant à notre équipe de démarrer sur la bonne voie.

Étape 1 : Définir les exigences

Avant de concevoir un système embarqué ou son micrologiciel, il est essentiel de définir clairement les exigences. Des exigences bien définies précisent ce que le produit fera pour l'utilisateur sans détailler comment ces objectifs seront atteints. Il est essentiel que chaque énoncé d'exigence soit sans ambiguïté et testable. Un énoncé sans ambiguïté est clair et concis, ne nécessitant aucune explication supplémentaire.

La testabilité est un facteur clé. Une exigence bien rédigée doit permettre la création de tests simples pour vérifier sa réalisation. Un ensemble d'exigences approprié se compose d'énoncés commençant par « le [produit] devrait ... », se concentrant sur ce qui est nécessaire plutôt que sur la manière d'y parvenir, et garantissant clarté et testabilité. Par conséquent, une architecture efficace repose sur des exigences bien définies.

Étape 2 : Faire la différence entre l’architecture et le design

D'après notre expérience, de nombreux ingénieurs et leurs responsables ont du mal à faire la distinction entre 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 caractéristiques durables du produit et rendant difficile toute modification une fois établie. Elle nécessite une réflexion approfondie sur les 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 de la manière dont il fonctionne. Bien que l'architecture décrive 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 des tâches et les responsabilités 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. Lorsque les interfaces sont clairement définies au stade de la conception, les ingénieurs peuvent commencer à mettre en œuvre les différents composants en parallèle. Bien que les défis puissent varier selon le secteur, ils se répartissent généralement en trois catégories principales : le respect des délais en temps réel, les tests et la gestion de la diversité. Ces problèmes sont abordés dans les trois dernières étapes.

Étape 3 : Gestion du temps

Certaines exigences de produit précisent des contraintes de temps explicites. En général, les produits incluent une combinaison d'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 à décharger autant d'exigences urgentes que possible du logiciel vers le matériel.

La séparation des fonctionnalités en temps réel du logiciel principal présente deux avantages majeurs. Tout d'abord, elle simplifie la conception et la mise en œuvre du logiciel non temps réel. En supprimant les contraintes de temps de la majeure partie du code, même les développeurs novices peuvent contribuer sans compromettre la sécurité des utilisateurs. Ensuite, la consolidation des fonctionnalités en temps réel facilite l'analyse et garantit que tous les délais sont systématiquement respectés.

Étape 4 : Concevoir en tenant compte des tests

Il est essentiel de tester chaque système embarqué à plusieurs niveaux. Dans de nombreux cas, les tests à différents niveaux sont non seulement utiles mais également obligatoires.

Les niveaux de tests les plus courants incluent

1. Les tests du système ont confirmé que le produit dans son ensemble répond aux exigences spécifiées ou 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 dans un ensemble de tests conçu par des ingénieurs.

2. Des tests d'intégration sont effectué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 attendus. Ces tests sont généralement développés par une équipe de test ou par un individu au sein du département d'ingénierie logicielle.

3. Les tests unitaires garantissent que les composants logiciels individuels, tels que définis au stade de la conception intermédiaire, fonctionnent comme prévu. Ces tests se concentrent sur l'API publique (Application Programming Interface) que le composant offre aux autres composants. En règle générale, 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 d'acceptation en usine, mais ce processus est généralement plus simple que les tests d'intégration et les tests unitaires, qui nécessitent une meilleure visibilité interne sur le fonctionnement de l'appareil. Pour rationaliser le développement, l'utilisation et la maintenance des tests d'intégration et des tests unitaires, il est conseillé de concevoir le micrologiciel d'une manière qui s'aligne sur un cadre de test logiciel. 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

Au cours de la phase d'architecture du micrologiciel, il est essentiel de donner la priorité à la gestion de la diversité des fonctionnalités et des personnalisations du produit. Pour planifier efficacement les changements, il est essentiel d'identifier d'abord les types de modifications susceptibles de se produire dans votre produit. Ensuite, le micrologiciel doit ê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 commutateurs de compilation et/ou d'exécution, tout en permettant l'ajout transparent de nouvelles fonctionnalités sans perturber les fonctionnalités existantes.