Les contraintes les plus fortes perçues sur les projets embarqués

Le monde de l’embarqué nous offre un paysage dynamique où les équipes de développement, propulsées par l’avancée fulgurante des technologies et limitées par les impératifs de l’environnement, font face à de nombreux défis et opportunités.

Pour les comprendre, nous avons approché plusieurs acteurs d’un secteur qui va au-delà du software. Les experts avec qui nous avons échangé proviennent de secteurs d’activité bien variés : banque, médical, industrie, automobile, défense, robotique… et ont une vision de l’embarqué qui est à la fois commune, mais aussi singulière et spécifique à un domaine précis.

Les grands enjeux du monde de l’embarqué est une série d’articles qui reprend une analyse qualitative détaillée d’entretiens avec des acteurs du secteur de l’embarqué. On parle ici de tendances significatives et de problématiques spécifiques rencontrées, nous permettant de visualiser l’avenir qu’offre ce domaine.

Une thématique qui nous plonge au cœur des tendances de l’embarqué, permettant aux entreprises de s’exprimer sur comment surmonter les obstacles et enjeux imposés par ce secteur. Les contraintes les plus fortes perçues sur les projets embarqués est le premier article de cette série.

Les tests de robustesse sont un vrai sujet. Souvent perçus comme une itération et une contrainte, on retrouve une pratique qui est de plus en plus demandée, notamment dans les dispositifs médicaux, mais aussi, dans les secteurs automobile et aérospatial, où de plus en plus de logiciels sont présents dans les systèmes embarqués.

La tâche est perçue comme une contrainte, comme un temps supplémentaire à accorder au développement global du produit. Aussi, la gestion des tests logiciels, qui est assez récente dans ces domaines, soulève une vraie question : comment tester la performance d’un logiciel sur la plateforme matérielle qui doit l’exécuter, et comment apporter de la traçabilité entre les exigences du cahier des charges et l’exigence technique pour le réaliser ? Et pourtant, les tests permettent de déterminer si le logiciel est robuste et fonctionne correctement, ils prouvent la sécurité et la fiabilité du produit.

Il est donc plus que nécessaire de s’assurer que le logiciel en question est fiable afin d’éviter au maximum les bugs, notamment les bugs bloquants, comme les problèmes d’accès concurrents, de variables partagées, de variables sur périphériques externes ou bien l’accès concurrent sur mémoire externe. Pour éviter l’apparition de bugs, la mise en place d’outils de vérification basés sur de l’analyse statique entre en jeu. Bien que la perte de temps puisse ne pas être significative à l’instant T, il est possible que le client final exige la réalisation de tests complémentaires. Et ce cas de figure impose une phase de test complète à prendre en compte.

Tester prend du temps, et est souvent remonté comme une contrainte par les équipes de développement, mais c’est une tâche indispensable qui prouve qu’un logiciel est robuste, fiable et sécurisé.

C’est en échangeant avec ces experts au cœur de l’action, qu’une limite au développement des projets embarqués ressort du lot : le manque d’expertise, le manque de ressource disponible. Le monde de l’embarqué fait face à une diversité de profils aux compétences solides, mais semble parfois ne pas atteindre la demande d’un marché qui recherche des connaissances et pratiques bien spécifiques à un sujet. Ce manque d’expertise sur le marché fait face à une réelle demande côté employabilité et compétences. Les industriels peinent à garder les profils devant une nouvelle génération qui est de plus en plus volatile. Pourtant, la demande est bien présente, et on observe une croissance réelle.

Développer un logiciel embarqué demande des connaissances diverses en firmware, hardware, applicatif, outillage ou outillage de contrôle. Le développement d’un logiciel débarqué, lui, demande une appétence particulière pour les connexions avec les utilisateurs, les mises à jour de versions soft et l’aspect cybersécurité. Ces développements pris en exemple demandent à eux deux des expertises bien spécifiques. Il est pourtant complexe de trouver des profils qui maîtrisent ces domaines avec des connaissances pointues sur l’embarqué.

Face à ce biais, les produits deviennent, eux, de plus en plus complexes, tout comme les systèmes de calcul (dont les microcontrôleurs, microprocesseurs ou encore les FPGAs) qui se révèlent également de plus en plus compliqués à gérer. Mais, il est difficile de trouver les ressources humaines expertes capables de programmer de bout en bout (IHM, capteurs, serveur…).

Et quand la main d’œuvre est présente, c’est la ressource disponible qui fait défaut. Les développeurs manquent de temps, la charge de travail est élevée, et des difficultés de planification des actions s’installent.

Il y a donc un fort potentiel de correction à mettre en place sur cette contrainte qui impacte grandement le développement des projets embarqués. Le manque d’expertise et de compétences sur le marché de l’emploi est un enjeu urgent à traiter, passant par un travail des formations d’ingénieurs par exemple. Le manque d’expertise a même été représenté comme une des premières complexités présentes sur le monde de l’embarqué.

Sans grande surprise, l’évolution fulgurante des nouvelles technologies est un sujet qui alerte un grand nombre d’acteurs sur le marché de l’embarqué.

L’Intelligence Artificielle (IA) est un paramètre à prendre en compte. Beaucoup d’outils et d’algorithmes ont été développés avec des technologies récentes. On retrouve quelques entreprises qui suivent le fil d’évolution de la technologie et intègrent l’IA dans leurs outils, mais, pour la plupart, le souci de récupération de la data par des sociétés tierces s’installe. Les problèmes liés à la cybersécurité ou bien la qualité et la propriété du code généré inquiètent également.

La communication entre les différents sous-systèmes composant des systèmes complexes est aussi une contrainte qui a été remontée, notamment entre les différents hardwares présents sur un véhicule, qui nécessite l’utilisation de plusieurs normes de communication, même si certaines sont déjà utilisées, comme l’ISO 15118, par exemple. On remarque également des défis autour de la création d’une communication sans fil normée, mais qui n’existe pas réellement encore. On peut aussi ajouter les couches liées aux applications spécifiques, comme la communication avec le cloud pour les véhicules qui communiquent avec une plateforme.

Enfin, dans le domaine du transport, ce sont les réseaux embarqués (CAN, Ethernet) qui peuvent, par exemple, rajouter des contraintes à destination de la communication avec le calculateur.

Le besoin de performance des applications peut s’avérer contraignant malgré la puissance disponible dans les appareils conçus, notamment dans le domaine industriel, où la recherche de performance peut donner lieu à une augmentation du coût. Pour répondre au souhait de baisser ces coûts, quand certains vont se tourner vers le choix des composants pour qu’ils reviennent à moins cher, en particulier sur les gammes de grandes séries, d’autres tentent de proposer le maximum de fonctionnalités sur des cibles limitées en termes de capacité de calculs et de mémoire. Adapter le coût en fonction des besoins applicatifs est aussi une pratique répandue.

D’autres facteurs jouant sur la performance des applications ont été identifiés, comme la notion de temps réel, qui est une contrainte puisqu’elle dégage des demandes de performance assez lourdes, par exemple sur les domaines réseau ou les équipements de signalisation, qui ont d’importants flots de données à gérer.

Dans le monde de l’embarqué, les coûts semblent être des limites qui, finalement, retrouvent une logique dans les choix faits par le développeur. Si l’on compare un FPGA et un microcontrôleur, les coûts sont nettement différents.

Enfin, une des principales contraintes évoquées reste de pouvoir déployer des algorithmes potentiellement lourds et coûteux sur des cibles matérielles limitées en ressources, et qu’on cherche à rendre le plus frugales possibles. Pour illustrer ce propos, il s’agit ici d’être capable de sélectionner le cœur le plus adapté aux traitements à réaliser et de ne pas utiliser une architecture x86 pour implémenter un simple filtre FIR par exemple !

L’incomplétude du cahier des charges, lors du développement d’un projet embarqué, se révèle être une contrainte qui génère une vraie perte de temps dans le déroulement du projet. Bien qu’il ne soit pas toujours évident d’avoir un horizon complet de dessiné, avoir un cahier des charges le plus précis possible est essentiel.

Les approvisionnements en électronique peuvent parfois s’avérer être une vraie contrainte.

Le temps de développement des logiciels est souvent conséquent, notamment à cause de la qualité du code écrit. Plus le code est bas niveau, plus cela requiert une maîtrise approfondie pour développer des équipements énergétiquement efficaces.

D’autres contraintes perçues dans les projets embarqués ont été remontées, comme l’autonomie des projets, les contraintes environnementales telles que les problématiques de températures élevées limitant la dissipation thermique.

Des remarques OU SUGGESTIONS à APPORTER ? Discutons-en !

Les contraintes les plus fortes perçues sur les projets embarqués est un article provenant de la série d’articles Les grands enjeux du monde de l’embarqué. Sa rédaction est issue d’une analyse qualitative réalisée auprès d’acteurs du secteur de l’embarqué. Nous les remercions d’avoir remonté des informations qui dessinent les tendances et problématiques spécifiques rencontrées dans le monde de l’embarqué.

• Sources : Florian Tachon, Sébastien Salmon, Olivier Marliac, Thomas Bernard, Julien Caulier, Romaric L’hernault, Alexandre Lanquar, Ghais Fanari, Mathieu Muller, Eric Pages, Dahbia Agher et Pierrick Boissard.