Nous suivons un processus en cinq étapes dans la conception du firmware

Ces dernières années, nous avons consacré beaucoup de temps à consulter et à former des équipes de développement de logiciels. Nous avons également joué un rôle essentiel dans le développement de micrologiciels pour des produits et des gammes de produits performants et durables.

Maîtriser simultanément la création d’une architecture de micrologiciel robuste et la réarchitecture des logiciels existants peut s’avérer un processus difficile et long.

Cependant, nous avons rationalisé ce parcours en cinq étapes distinctes, servant de base pour guider notre équipe vers un bon départ.

Étape 1 : Déterminez les spécifications nécessaires.

Des exigences claires sont cruciales avant de commencer la conception architecturale d’un système embarqué ou de son firmware. Des exigences précisément définies décrivent les attributs et qualités nécessaires d’un produit.

Qu'est-ce que le produit offre à l'utilisateur ? Il est essentiel de noter qu'une exigence bien conçue se concentre sur le « quoi », évitant les détails sur le « comment » pour réaliser une fonctionnalité particulière dans un contexte plus large.

Chaque énoncé d'exigence doit être clair et testable pour garantir qu'il est facilement compris et vérifiable. Une déclaration claire est concise et directe, ne nécessitant aucune explication supplémentaire.

L’élément clé est la testabilité. Une exigence bien rédigée permet de créer facilement une série de tests pour vérifier que l’exigence a été satisfaite.

Un ensemble complet d'exigences se compose de déclarations écrites commençant par la phrase clé « le [produit] devrait… ».

Ces déclarations évitent de spécifier les détails de mise en œuvre, garantissant qu'elles restent claires, sans ambiguïté et testables. Par conséquent, une architecture robuste dépend d’exigences bien définies.

Étape 2 : Différencier architecture et design

Au fil du temps, nous avons observé que de nombreux ingénieurs et leurs managers ont du mal à différencier les différents composants ou niveaux d'ingénierie du firmware.

L'architecture du système constitue la couche supérieure des fonctionnalités du produit. Cette couche définit des caractéristiques durables, ce qui la rend difficile à modifier. Par conséquent, il est important d’évaluer minutieusement les objectifs ciblés et approuvés du produit.

La conception du système sert de couche intermédiaire de mise en œuvre. Il est important de noter que l’architecture n’inclut pas les spécificités des noms de fonctions ou de variables. Ces détails sont documentés dans le document de conception du micrologiciel.

Des exemples de ces détails incluent les noms de tâches et les responsabilités associées dans les sous-systèmes ou pilotes de périphériques désignés, la marque RTOS sélectionnée (le cas échéant) et les spécifications d'interface entre les sous-systèmes.

La mise en œuvre est l’étape la plus détaillée du processus. Des interfaces claires établies lors de la phase de conception permettent aux ingénieurs d'exécuter simultanément des composants individuels.

L'importance de ces défis peut différer selon les secteurs, mais ils impliquent systématiquement trois obstacles cruciaux qui nécessitent une attention particulière : respecter des délais serrés, effectuer des tests approfondis et gérer efficacement la diversité. Répondre à ces préoccupations représente les trois dernières étapes.

Étape 3 : Gestion du temps

Les spécifications du produit incluront des délais. Habituellement, les produits ont un mélange d'exigences en temps non réel, en temps réel logiciel et en temps réel dur.

Fixer des délais souples peut souvent s’avérer difficile. Une fois les délais fixés, la première étape consiste à faire passer autant d'exigences de rapidité que possible du logiciel au matériel.

Maintenir une distinction claire entre les fonctionnalités en temps réel et le reste du logiciel présente une grande valeur pour deux raisons. Premièrement, cela simplifie la conception et la mise en œuvre du logiciel non temps réel.

La séparation des exigences de rapidité du corps principal du logiciel permet aux implémenteurs moins expérimentés de créer un code qui ne mettra pas en danger la sécurité des utilisateurs.

La combinaison des fonctionnalités en temps réel simplifie également l’analyse requise pour prouver le respect des délais.

Étape 4 : Conception orientée tests

Les tests sont cruciaux pour chaque système embarqué. Effectuer des tests à plusieurs niveaux est obligatoire et très important. Les principaux niveaux de tests comprennent :

1. Les tests du système vérifient si le produit satisfait ou dépasse les exigences spécifiées. En règle générale, les tests doivent être développés en dehors du service d'ingénierie, mais peuvent également être intégrés dans un faisceau de tests créé par les ingénieurs.

2. Les tests d'intégration vérifient qu'un groupe spécifié de sous-systèmes, tel que défini dans les diagrammes architecturaux, interagissent avec précision pour produire des résultats significatifs. L'approche la plus efficace pour développer des tests d'intégration est généralement dirigée par une équipe de tests ou un expert en génie logiciel.

3. Les tests unitaires confirment que les composants logiciels désignés, spécifiés dans la conception intermédiaire, fonctionnent comme prévu par le développeur.

Les tests unitaires évaluent l'API publique (Application Programming Interface) que le composant présente aux autres éléments. Les développeurs devraient idéalement créer des tests unitaires pour leur propre code afin de maximiser leur efficacité.

Parmi les trois, les tests système sont généralement les plus simples à développer. Un test d'ingénierie ou d'acceptation en usine peut nécessiter la création d'un faisceau de tests, mais cela est généralement moins complexe que les tests d'intégration et unitaires, qui nécessitent une compréhension plus approfondie des opérations internes de l'appareil.

Pour simplifier le développement, l'utilisation et la maintenance des tests d'intégration et unitaires, il est avantageux de structurer le micrologiciel en fonction d'un cadre de tests logiciels. La stratégie optimale consiste à concevoir la communication entre tous les éléments logiciels aux niveaux qui doivent être testés.

Étape 5 : Préparez-vous au changement

Pendant la phase d'architecture du micrologiciel, il est crucial de donner la priorité à la gestion de la diversité des fonctionnalités et à la personnalisation des produits. Pour vous préparer aux changements potentiels, il est essentiel de comprendre les types de modifications qui peuvent survenir dans votre produit spécifique.

Structurez le micrologiciel de manière à simplifier la mise en œuvre de ces modifications. Avec une architecture logicielle appropriée, la gestion de la diversité des fonctionnalités peut être obtenue grâce à une seule version logicielle qui utilise des commutateurs de comportement au moment de la compilation et/ou de l'exécution au sein du micrologiciel.

De même, une architecture plus solide facilite l’intégration fluide de nouvelles fonctionnalités sans compromettre la fonctionnalité du produit.