5 étapes pour concevoir une architecture logicielle embarquée, étape 1 – Embedded.com

Certains pensent qu’une architecture logicielle propre peut simplement émerger des efforts de codage, mais c’est comme croire que verser un paquet de spaghettis dans de l’eau bouillante se traduira par des lasagnes cuites.

L’architecture logicielle est l’organisation fondamentale d’un système incarnée dans ses composants, leurs relations entre eux et avec l’environnement, et les principes guider sa conception et son évolution [1]. L’architecture logicielle n’est pas destinée à être créée une fois pour toutes et gravée dans le marbre. Au lieu de cela, l’architecture logicielle doit évoluer et changer tout au long de la durée de vie d’un produit. Au fil des ans, j’ai entendu des ingénieurs et des managers discuter du fait que l’architecture logicielle devrait émerger des efforts de codage, comme par magie. Croire en une architecture propre et émergente, c’est comme croire que verser un paquet de spaghettis dans de l’eau bouillante donnera des lasagnes cuites.

Une architecture logicielle réfléchie puis évolutive au cours de la mise en œuvre présente de nombreux avantages, tels que :

• Agir comme une feuille de route pour ce qui est en train d’être construit
• Fournir une image du logiciel qui peut être utilisée pour former des ingénieurs et expliquer le logiciel à la direction et aux parties prenantes
• Minimiser les retouches inutiles
• Réduction des coûts de développement

Un problème courant que je vois souvent est que les équipes ont du mal à comprendre comment définir leur architecture logicielle. Les équipes peuvent suivre cinq étapes pour développer et faire évoluer leur architecture logicielle :

• Séparer l’architecture logicielle
• Identifier et tracer les actifs de données
• Décomposer le système
• Conception d’interfaces et de composants
• Simuler, itérer et mettre à l’échelle

Alors, explorons quelques étapes que vous pouvez suivre pour concevoir votre architecture logicielle embarquée.

Étape #1 Séparer l’architecture logicielle

De nombreuses équipes de logiciels embarqués considèrent leur architecture logicielle comme une architecture cohérente unique qui inclut à la fois le code d’application et les interactions matérielles. Voir l’architecture de cette façon n’est pas surprenant car les ingénieurs en logiciels embarqués regardent souvent leur système à partir du matériel. Le logiciel embarqué est unique car il doit interagir avec le matériel, ce qui est différent de tous les autres domaines du génie logiciel. Bien que cela soit vrai, un architecte logiciel moderne séparera et devrait séparer les logiciels dépendants du matériel et indépendants du matériel, comme le montre la figure 1.

Figure 1 Une architecture logicielle embarquée est séparée en architectures dépendantes du matériel et indépendantes qui interagissent via une couche d’abstraction. (Source de l’image : conception de logiciels intégrés [2]).

J’appelle cette séparation un conte de deux architectures. Traditionnellement, les développeurs concevront et implémenteront leur architecture de manière à ce que les couches indépendantes et dépendantes du matériel soient étroitement couplées. Mais malheureusement, il y a pas mal de problèmes avec une architecture étroitement couplée.

Problèmes avec les architectures étroitement couplées

Premièrement, ils ne sont pas très portables. Par exemple, que se passe-t-il si un microcontrôleur devient soudainement indisponible ? (Pénurie de puces, quelqu’un?). Si le code est étroitement couplé, tenter de déplacer le code d’application pour qu’il s’exécute sur un nouveau microcontrôleur devient un effort herculéen. Le code d’application est étroitement couplé aux appels matériels de bas niveau sur le microcontrôleur ! Je connais beaucoup d’entreprises qui ont souffert de cela récemment. S’ils ne mettaient pas à jour leur architecture, ils devaient revoir tout leur code et modifier chaque ligne qui interagissait avec le matériel. Les entreprises qui ont mis à jour leur architecture ont rompu leur couplage d’architecture grâce à des abstractions et à l’injection de dépendances.

Deuxièmement, les tests unitaires de l’application dans un environnement de développement plutôt que sur le matériel cible sont presque impossibles. Si le code d’application effectue des appels directs au matériel, beaucoup de travail sera consacré au harnais de test pour exécuter ce test avec succès, ou les tests devront être effectués sur le matériel. Les tests sur le matériel sont lents et sont souvent un processus manuel plutôt qu’automatisé. Le résultat que j’ai vu est que le logiciel n’est pas bien testé et que la qualité globale du système en souffre. De plus, la livraison du logiciel peut prendre plus de temps.

Enfin, une architecture étroitement couplée aura des problèmes d’évolutivité. Les systèmes étroitement couplés partagent souvent des données. Au fur et à mesure que le système logiciel essaie de se développer et d’ajouter de nouvelles fonctionnalités, il devient plus difficile à chaque nouvelle fonctionnalité d’ajouter un nouveau code. Les interactions entre les composants, la possibilité d’accéder aux données partagées et les risques de défauts gênants augmentent considérablement. En conséquence, le développement de fonctionnalités peut s’arrêter même si les développeurs travaillent d’arrache-pied pour faire le travail.

Comment la séparation de l’architecture résout le problème

Séparer l’architecture logicielle en architectures dépendantes du matériel et indépendantes résout tous les problèmes avec une architecture étroitement couplée. Par exemple, la création d’une couche d’abstraction entre les architectures dépendantes du matériel et indépendantes permet de déplacer le code d’application d’un microcontrôleur à l’autre. La couche d’abstraction rompt les dépendances matérielles ; en d’autres termes, l’application ne connaît pas ou ne se soucie pas du matériel. Au lieu de cela, l’application dépend de l’interface. Les nouveaux composants dépendants du matériel doivent simplement répondre aux exigences de l’interface. Cela signifie que si nous changeons de matériel, seuls les modules matériels changent ! Pas toute la base de code.

L’ajout d’une couche d’abstraction entre les deux architectures résout également de nombreux problèmes liés aux tests unitaires. Avec la couche d’abstraction en place, il est plus facile de créer des doubles de test et des simulations qui renvoient des données attendues et inattendues au code de l’application. On peut écrire tout le code de l’application sans même avoir le matériel ! Je sais que cela semble absurde pour de nombreux développeurs de logiciels embarqués. Cependant, au cours de la semaine dernière, j’ai ajouté plusieurs nouvelles fonctionnalités à un produit sur lequel je travaille et je n’ai allumé le matériel qu’une seule fois. Tout mon développement a été fait à l’aide de tests unitaires sur un ordinateur hôte !

Lorsque nous gardons nos architectures séparées et que nous nous concentrons sur la minimisation du couplage, il devient beaucoup plus facile de faire évoluer le logiciel. Cependant, ce n’est pas parce que nous avons divisé l’architecture que nous ne pouvons pas créer de problèmes de couplage et de cohésion dans chaque architecture. Nous devons encore nous assurer que nous suivons les principes SOLID dans les deux architectures. La bonne nouvelle est que cela nous permet de nous concentrer sur chaque architecture indépendamment, ce qui signifie que les problèmes de temps réel et de contraintes matérielles ne se retrouvent pas dans la logique de base de l’application.

Le dernier avantage que je veux mentionner est qu’en séparant les architectures dépendantes du matériel et indépendantes, nous pouvons nous concentrer sur le développement et la livraison de l’application avant même que le matériel ne soit disponible. L’avantage ici est que les clients et la direction peuvent bénéficier d’un accès anticipé à l’application et fournir des commentaires. La possibilité de parcourir ensuite l’application et de s’assurer qu’elle répond aux besoins réels devient beaucoup plus gérable. Aujourd’hui, trop d’équipes se concentrent d’abord sur la préparation du matériel, et l’application principale est une réflexion après coup. Ce n’est pas une façon de concevoir et de construire un système.

Conception de l’architecture logicielle Étape #1 Conclusions

L’architecture logicielle peut aider les équipes à contrôler leurs logiciels. Les architectures logicielles émergentes se traduisent souvent par un code de grande boule de boue et de spaghetti. Cela ne signifie pas qu’ils ont été obligés d’utiliser une méthodologie en cascade. Une architecture logicielle réussie est souvent créée par itération et évolution. La première étape de la conception d’une architecture logicielle consiste à reconnaître que les systèmes embarqués n’ont pas qu’une seule architecture. Au lieu de cela, il existe deux architectures : une architecture dépendante du matériel et une architecture indépendante. La séparation délibérée de ces architectures permet aux développeurs de tirer parti des techniques et méthodologies logicielles modernes pour améliorer les délais de mise sur le marché, la qualité et les coûts de développement.

Remarques

[1] https://en.wikipedia.org/wiki/IEEE_1471. IEEE 1471 a été remplacé par IEEE42010. (J’aime juste la définition IEEE 1471).

[2] Béningo, Jacob. Conception de logiciels embarqués. Presse, 2022

Jacob Beningo est un consultant en logiciels embarqués spécialisé dans les systèmes en temps réel basés sur des microcontrôleurs. Il promeut activement les meilleures pratiques logicielles à travers de nombreux articles, blogs et webinaires sur des sujets tels que la conception d’architecture logicielle, le DevOps intégré et les techniques de mise en œuvre. Jacob a 20 ans d’expérience dans le domaine et détient trois diplômes, dont une maîtrise en ingénierie de l’Université du Michigan.

Contenu connexe :

Pour en savoir plus sur Embedded, abonnez-vous à la newsletter hebdomadaire par e-mail d’Embedded.