Découvrez GoogleTest certifié TÜV avec Agentic AI pour les tests C/C++ !
Plus de détails »
Aller à la section
Blog Parasoft
L'IA transforme les capacités des robots et complexifie les logiciels qui les pilotent. Découvrez comment vérifier ces logiciels bien avant que le matériel ne soit prêt et rapprochez progressivement les tests du robot final.
Aller à la section
Les robots modernes deviennent extraordinairement sophistiqués. L'intelligence artificielle et la vision par ordinateur leur permettent de percevoir leur environnement, de reconnaître des objets, de se déplacer dans des environnements changeants et de prendre des décisions qui auraient été difficiles à automatiser il y a encore quelques années.
Mais derrière ces capacités se cache une quantité considérable de logiciels embarqués que les équipes doivent encore développer, tester et vérifier. Et un problème très pratique se pose : comment tester le logiciel à l’intérieur d’un robot lorsqu’on ne l’a pas toujours sous la main ?
Une entreprise de développement robotique peut compter des centaines d'ingénieurs logiciels, mais seulement un nombre limité de robots physiques, de systèmes prototypes, de bancs d'essai matériels ou de processeurs cibles. Au début du développement, le matériel final peut même ne pas exister. Par la suite, son accès peut devenir un goulot d'étranglement.
Certains tests sont également difficiles, coûteux, voire potentiellement dangereux à réaliser de manière répétée sur la machine complète. Attendre que le robot soit disponible pour commencer des tests logiciels robotiques approfondis n'est pas une stratégie viable.
La meilleure approche consiste à commencer la vérification bien avant que le robot complet n'existe, et à rapprocher progressivement les tests du système réel au fur et à mesure de l'avancement du développement.
L'IA transforme la robotique de deux manières importantes.
Premièrement, cela change ce que les robots peuvent faire. La perception, la planification, la reconnaissance d'objets, l'interaction en langage naturel et la prise de décision de plus en plus autonome élargissent l'éventail des tâches que les robots peuvent accomplir.
Deuxièmement, l'IA accroît la complexité des systèmes logiciels qui sous-tendent ces capacités. Un modèle d'IA ne fait pas fonctionner un robot de manière autonome. Les systèmes robotiques modernes dépendent toujours de logiciels embarqués pour des fonctions telles que le contrôle des mouvements, le traitement des données des capteurs, la commande des actionneurs, les communications, les diagnostics, la gestion des états, la gestion des pannes et les mécanismes de sécurité. Une grande partie de ces logiciels est développée en C et C++.
L'IA soulève également de nouvelles questions de sécurité, ce qui se reflète dans l'évolution du paysage normatif. La norme ISO/IEC TR 5469:2024 fournit actuellement des recommandations générales sur la sécurité fonctionnelle des systèmes d'IA. La série de normes ISO/IEC TS 22440, en cours d'élaboration, lui succédera et proposera des exigences et des recommandations plus concrètes en matière de sécurité fonctionnelle des systèmes d'IA.
La série prévue comprend :
La série est encore en développement, mais son orientation souligne un point important pour l'ingénierie robotique : à mesure que l'IA prend une place de plus en plus importante dans les systèmes physiques, la vérification des logiciels et des mécanismes de sécurité qui l'entourent devient cruciale. Heureusement, une grande partie de cette vérification ne nécessite pas d'attendre la réalisation d'un robot complet.
Prenons l'exemple d'un développeur qui implémente un logiciel de commande de moteurs, de traitement de données de capteurs, de communication ou de machine à états. Son poste de travail peut constituer un premier environnement de test pertinent. Grâce aux tests sur hôte, les développeurs peuvent tester le logiciel sur leur propre poste de travail avant de l'exécuter sur le matériel embarqué du robot.
L'analyse statique peut commencer dès qu'un code compilable est disponible. Les développeurs peuvent ainsi identifier les défauts potentiels, les comportements indéfinis, les failles de sécurité et les violations des normes de codage sans avoir à exécuter le logiciel sur un robot physique.
Des normes telles que MISRA C/C++ peuvent fournir des garde-fous pour un développement axé sur la sécurité et la fiabilité, tandis que les analyses CERT C/C++ et CWE peuvent aider à identifier les faiblesses de sécurité potentielles.
Les tests unitaires peuvent commencer très tôt. Un développeur n'a pas forcément besoin d'un moteur pour tester la logique qui détermine une commande motrice. De même, il n'est pas nécessaire de connecter le capteur pour vérifier comment le logiciel traite les valeurs de ce dernier.
Les dépendances peuvent être isolées ou simulées, ce qui permet de tester chaque composant logiciel indépendamment. Cela confère aux équipes de robotique un avantage considérable : la vérification du logiciel peut commencer pendant que le développement du matériel est encore en cours.
Tester le système sans le système complet présente un autre avantage qu'il est facile de négliger.
Certains des tests logiciels les plus précieux impliquent des conditions que vous ne souhaiteriez peut-être pas reproduire physiquement.
Recréer certaines de ces conditions sur un robot réel peut s'avérer complexe. D'autres peuvent nécessiter un équipement spécialisé. Certaines pourraient potentiellement exposer le matériel ou le personnel à des risques inutiles.
Au niveau unitaire, les ingénieurs peuvent injecter délibérément des entrées et simuler des dépendances afin de tester ces comportements dans un environnement contrôlé. Ceci est particulièrement important pour les logiciels de défense.
Un robot fonctionnant normalement peut exécuter les mêmes parcours réussis des milliers de fois tout en exerçant rarement la logique de gestion des erreurs, de récupération des pannes et de gestion des conditions anormales destinée à le protéger en cas de problème.
L'exécution d'un grand nombre de tests ne signifie pas nécessairement que le logiciel a été testé de manière exhaustive. C'est là que la couverture de code structurelle prend toute son importance.
La couverture des instructions et des branches peut révéler des portions de l'implémentation jamais testées. Pour les logiciels exigeant une vérification plus rigoureuse, MC/DC peut fournir des preuves supplémentaires concernant l'effet indépendant des conditions au sein des décisions. Les lacunes de couverture peuvent également révéler des informations plus intéressantes qu'un simple pourcentage.
Supposons que le code non exécuté gère une panne de capteur, un délai d'attente de communication, une commande invalide ou une transition vers un état sécurisé. Cet écart indique précisément à l'équipe d'ingénierie où des tests supplémentaires pourraient s'avérer nécessaires. Au lieu de se demander uniquement : « Nos tests ont-ils réussi ? », les équipes peuvent se demander : « Qu'est-ce que nos tests n'ont pas couvert ? »
Pour les logiciels de robotique comportant un grand nombre d'états, d'entrées, de conditions de panne et d'interactions matérielles, cette dernière question est beaucoup plus pertinente.
Les tests réalisés par les développeurs ne sont que le point de départ. À mesure que plusieurs ingénieurs contribuent au logiciel, la vérification automatisée doit évoluer vers une intégration continue.
Grâce aux tests continus, chaque modification logicielle peut déclencher une analyse statique, des tests unitaires, des tests de régression et une analyse de couverture. Les problèmes peuvent ainsi être identifiés au plus près de la modification qui les a introduits, plutôt que des semaines plus tard lors de l'intégration du système.
Cela devient particulièrement important à mesure que l'IA accélère le développement logiciel lui-même.
L'IA générative peut aider les ingénieurs :
Cela peut accélérer considérablement le développement. Cependant, une accélération du développement implique également une augmentation de la fréquence à laquelle le logiciel doit être vérifié. Que le code ait été écrit manuellement ou généré à l'aide d'une IA, l'exigence d'ingénierie reste la même : les équipes ont besoin de preuves objectives que le logiciel satisfait aux exigences et fonctionne correctement.
L'IA peut également accélérer le processus de vérification, en facilitant des tâches telles que la correction des anomalies relevées lors de l'analyse statique, la création de tests unitaires et la réduction des écarts de couverture de code. L'IA ne remplace donc pas la vérification, mais la rend encore plus essentielle.
Les tests sur système hôte offrent rapidité et évolutivité, mais les logiciels embarqués doivent à terme être testés dans des conditions représentatives de leur environnement d'exécution. C'est là qu'une stratégie de tests progressifs prend tout son sens. Les tests peuvent ainsi s'effectuer dans des environnements de plus en plus réalistes :
Poste de travail du développeur → Intégration continue → Simulateur → Matériel cible → Système robotique complet
Il n'est pas nécessaire d'exécuter tous les tests à chaque étape.
Un test unitaire validant un algorithme peut fonctionner parfaitement sur une machine de développement et s'exécuter des milliers de fois en intégration continue. D'autres tests peuvent nécessiter un simulateur.
Les tests impliquant le comportement du compilateur, l'architecture du processeur, le comportement du système d'exploitation, les interfaces matérielles ou les conditions spécifiques à la cible nécessitent des tests sur cible, où les tests s'exécutent sur le matériel embarqué réel.
Enfin, les tests au niveau du système permettent de vérifier comment les logiciels intégrés, l'électronique, les capteurs, les actionneurs, les composants d'IA et le système mécanique se comportent ensemble.
Chaque environnement répond à des questions différentes. L'essentiel est de ne pas reporter la vérification jusqu'à la disponibilité de l'environnement final.
C’est également là que le choix du flux de travail de test a son importance.
Les entreprises de robotique utilisent de plus en plus des frameworks de test open source en C et C++ tels que GoogleTest. Les développeurs apprécient ces frameworks familiers car les tests peuvent être créés naturellement dans le cadre du développement logiciel classique. Ces tests prennent encore plus de valeur lorsqu'ils sont intégrés au logiciel.
Un test développé en amont sur une machine hôte ne doit pas nécessairement devenir obsolète lors de l'intégration du projet. Le cas échéant, les équipes doivent pouvoir exécuter ou adapter ces mêmes tests au sein des environnements d'intégration continue, des simulateurs et des environnements cibles, tout en recueillant des résultats et des informations de couverture cohérents.
Cela transforme les tests en un processus continu plutôt qu'en une suite d'activités isolées. La question n'est plus tant de savoir où le test a été créé, mais plutôt où il doit être exécuté pour fournir les preuves requises.
Un autre problème surgit à mesure que les projets de robotique prennent de l'ampleur. Une équipe peut finir par réaliser des milliers de tests. Réussir des milliers de tests est rassurant, certes, mais cela ne répond pas forcément à une question d'ingénierie essentielle : avons-nous vérifié les exigences qui comptent ?
La traçabilité des exigences permet de relier les exigences logicielles aux tests destinés à les vérifier et aux résultats indiquant leur réussite. Pour les fonctionnalités liées à la sécurité, cela peut s'avérer particulièrement précieux.
Prenons l'exemple d'une exigence précisant comment le robot doit réagir lorsqu'un capteur devient défaillant. Les éléments techniques justifiant cette réaction pourraient inclure :
La vérification ne se limite plus à une simple collecte de résultats de tests positifs ; elle devient une chaîne de preuves traçable.
Les solutions de test embarquées de Parasoft prennent en charge cette approche progressive de la vérification des logiciels robotiques. Parasoft C/C++test permet aux développeurs de :
Ces activités peuvent commencer tôt, avant même que le matériel robotique complet ne soit disponible.
C/C++test prend également en charge les flux de travail pour le développement embarqué critique en matière de sécurité et est certifié TÜV SÜD pour les normes de sécurité fonctionnelle, notamment la norme IEC 61508.
Avec l'intégration continue et le déploiement continu (CI/CD) des tests, Parasoft C/C++test CT propose une approche indépendante de tout framework pour les tests continus. Les équipes peuvent ainsi utiliser leurs frameworks de test C et C++ existants, comme Google Test, tout en collectant les résultats des tests et la couverture structurelle (instructions, branches et MC/DC).
Ceci est particulièrement utile en robotique, car les tests ne sont plus limités à un seul environnement d'exécution. Ils peuvent être intégrés à des pipelines de compilation automatisés et exécutés dans des environnements adaptés au logiciel vérifié, y compris des cibles embarquées représentatives.
De plus, les capacités d'assistance à l'IA de Parasoft accélèrent encore la vérification en aidant les ingénieurs à traiter les résultats de l'analyse statique et les lacunes de couverture, tout en leur permettant de garder le contrôle des modifications qui en résultent.
Enfin, Parasoft DTP centralise les informations de vérification tout au long du processus de développement. Les résultats des tests, la couverture, les conclusions de l'analyse statique, la traçabilité des exigences et les informations de conformité peuvent être présentés via des tableaux de bord et des rapports centralisés.
Cette visibilité prend toute son importance lorsque les tests sont répartis entre les développeurs, les pipelines d'intégration continue, différents environnements de test et les systèmes cibles. L'objectif est de privilégier un flux de travail de vérification continu plutôt que des activités de test isolées.
Le système robotique final nécessitera toujours des tests. Aucun environnement hôte ni simulateur ne peut reproduire parfaitement toutes les interactions entre les processeurs, l'électronique, les capteurs, les actionneurs, les réseaux, les modèles d'IA, les composants mécaniques, les personnes et l'environnement physique.
Mais cela ne signifie pas que la vérification doive attendre la machine terminée. Bien au contraire.
Lorsque le robot complet sera disponible, l'objectif ne devrait pas être de vérifier le bon fonctionnement de son logiciel embarqué. Une grande partie de ce travail devrait déjà avoir été effectuée. Le robot devrait servir aux équipes à confirmer les hypothèses qui ne pourraient être vérifiées que sur le système complet, et non pas constituer le point de départ de la vérification logicielle.
À mesure que l'IA rend les robots plus performants et les logiciels robotiques plus complexes, cette distinction deviendra de plus en plus importante. Il n'est pas nécessaire d'avoir le robot pour commencer les tests. Plus tôt vous commencerez, plus vous aurez confiance lorsque la machine sera enfin opérationnelle.
Découvrez comment mettre ces méthodes en pratique grâce aux vidéos de démonstration de C/C++test et C/C++test CT , qui couvrent les tests unitaires, la couverture de code et les flux de travail CI/CD.
Découvrez comment un flux de travail de vérification robotique continue fonctionne en pratique pour votre logiciel de robotique embarquée.
