Lors du développement de dispositifs embarqués, la vérification et la validation du logiciel nécessitent de bien comprendre à quel moment on peut considérer que les tests à effectuer sont suffisants. Trois concepts clés - tester tôt, réutiliser et automatiser - permettent d'instaurer cette confiance.

Marlene Gebhard (Crédit photo : Vector)

Par Marlene Gebhard, Team Lead R&D Medical Solutions, Vector.

La maitrise des coûts de développement des systèmes embarqués impose des méthodes efficaces concernant les processus de vérification et de validation. Ceux-ci présentent des défis considérables, car les développeurs ne peuvent pas tester indéfiniment leur conception et il est complexe de déterminer à quel moment la sûreté de fonctionnement peut être avérée.

Selon les Principes Généraux de Validation des Logiciels de la FDA, cette validation consiste principalement à établir un "niveau de confiance" selon lequel le dispositif répond à toutes les exigences. Cela ne nécessite pas d'y consacrer un temps et des ressources financières excessifs, mais plutôt de mettre en place un système de test robuste. Ce dernier repose sur trois principes fondamentaux alliés à une maîtrise efficace des coûts et des délais : Tester Tôt, Réutiliser, et Automatiser.

Tester tôt

La "règle du dix" suggère que le coût d'un défaut non détecté est multiplié par dix à chaque étape de la chaîne de valeur. (crédit photo : Vector).

Plus un défaut reste longtemps dans un système, plus il devient coûteux à corriger. Le coût de correction des bogues logiciels augmente même de manière exponentielle avec le temps. Détecter et corriger les bogues lors de la phase d'écriture du code est relativement facile et peu coûteux. Le faire plus tard est nettement plus onéreux mais aussi plus risqué, surtout si le produit est déjà sur le marché. La "règle du dix" suggère que le coût d'un défaut non détecté est multiplié par dix à chaque étape de la chaîne de valeur (figure ci-contre).

Une stratégie efficace pour les tests précoces est l'approche du "shift left". Il s'agit, dans la chronologie du projet, d'avancer les activités de test dans le temps, plutôt que de les prévoir vers la fin du processus de développement.

C'est en simulant l'environnement cible que les développeurs vont pouvoir tester très tôt leurs produits dans les conditions prévues.

Considérons, par exemple, un simple dispositif embarqué comme un thermomètre. Le logiciel qui traite les données du capteur de température et les envoie à l'afficheur peut être testé sans attendre que le matériel final soit connecté. Le capteur et l'afficheur peuvent être simulés, pour permettre un échange de données avec le logiciel afin de tester diverses conditions limites : comment le logiciel réagit-il aux températures à 3 chiffres ? Que se passe-t-il en dessous de 0°C ? Le logiciel peut-il gérer les erreurs d'affichage ?

Réutiliser

Les mêmes simulations environnementales peuvent servir les tests logiciels et matériels grâce aux systèmes HIL et aux adaptateurs SIL (crédit photo : Vector).

La simulation d'environnement développée pour le thermomètre peut servir aux tests logiciels, mais aussi aux tests matériels.

Le challenge est alors de convertir facilement les interfaces logicielles en interfaces matérielles. La solution réside dans l'utilisation de systèmes HIL (Hardware-in-the-Loop) et d'adaptateurs SIL (Software-in-the-Loop). Cela permet d'utiliser la même simulation pour tester le logiciel et le matériel. Seules les interfaces changent (figure ci-contre).

L'adaptateur SIL est un composant qui canalise les signaux de sortie de simulation vers le logiciel à tester, pour qu'il traite ces signaux comme s'ils provenaient de sources réelles. Le logiciel à tester doit être instrumenté pour fonctionner avec l'adaptateur SIL et recevoir ces signaux simulés.

Lors des tests du logiciel sur le matériel final, c'est un système HIL qui est utilisé : les signaux de sortie de la simulation alimentent les entrées du système HIL. Celui-ci convertit ensuite ces signaux de simulation dans des formats analogiques ou numériques que le matériel peut lire directement.

Lors de la transition entre SIL et HIL, la couche intermédiaire peut être ajustée, permettant une approche hybride où certaines interfaces continuent d'utiliser l'adaptateur SIL tandis que d'autres interagissent directement avec le matériel via le système HIL. Cette flexibilité garantit des tests complets sur les composants logiciels et matériels.

Automatiser

L'automatisation est cruciale pour construire l'environnement de test. La plupart des développeurs connaissent les tests unitaires exécutés dans un pipeline CI/CD (Continuous Integration and Continuous Delivery, ou Intégration Continue et Livraison Continue).

Les pipelines de test sont déclenchés à chaque changement de code. Mais techniquement, rien n'empêche de pouvoir également automatiser les tests système mentionnés précédemment. Les simulations peuvent être exécutées sur un serveur, et le logiciel instrumenté avec un adaptateur SIL reste simplement un logiciel. Les tests HIL devraient aussi être automatisés. Un banc de test HIL est nécessaire, déclenché à chaque mise à jour du système.

En conclusion, bien qu'il n'existe pas de règles précises pour déterminer quand les tests sont suffisants, respecter les trois principes (Tester tôt, Réutiliser, Automatiser) offre une base solide pour atteindre le bon niveau de confiance.

www.vector.com