Qu'est-ce que le test SIL (SIL) ?

Principaux enseignements

• test SIL constituent une étape de vérification pratique au cours de laquelle le code exécutable démontre qu'il correspond toujours à l'intention du système avant que le matériel n'entre dans la chaîne de test.
• Le SIL permet de réduire les coûts de validation lorsqu'il est utilisé pour détecter précocement les défauts logiciels, automatiser les tests de régression et concentrer les essais HIL sur les questions liées au matériel.
• La fiabilité des résultats d'une simulation SIL dépend de la précision des hypothèses relatives au timing, à l'interface et aux paramètres numériques, car une configuration de simulation trop simplifiée engendre une fausse confiance au lieu de fournir des informations utiles.

test SIL permettent de valider les logiciels embarqués plus tôt, à moindre coût et avec une localisation des défauts plus précise que si l'on attendait la mise à disposition du matériel.

Cela est important car la part logicielle des systèmes de contrôle modernes ne cesse de croître à mesure que les plateformes électriques et automatisées se développent. Les ventes mondiales de voitures électriques ont dépassé les 14 millions d’unités en 2023, portant le parc total à environ 40 millions. De plus en plus de programmes reposent désormais sur du code de contrôle, des modèles d’installation et des tests de régression capables de suivre le rythme des mises à jour logicielles fréquentes. Le SIL constitue le lien idéal entre la vérification des modèles et l’intégration matérielle, car il permet de détecter les erreurs logiques, les défauts d’interface et les écarts par rapport aux exigences avant que le matériel de laboratoire ne ralentisse le travail de l’équipe.

test SIL le code de production en simulation

test SIL exécuter un logiciel sur des capteurs, des actionneurs et un comportement de l'installation simulés, plutôt que sur du matériel physique. Vous testez le code implémenté, et pas seulement le modèle de contrôle ; le SIL vous apporte ainsi la première preuve solide que le comportement du logiciel correspond toujours à l'intention du système après la compilation et l'intégration.

Un contrôleur de moteur en est un exemple simple. Le code de commande lit les valeurs simulées de l'angle de vilebrequin, de la position du papillon et de la température, puis renvoie les commandes d'injection et d'allumage vers le modèle de l'installation. Si les limites de couple, la logique de coupure d'alimentation ou les indicateurs de diagnostic présentent un comportement anormal, vous pouvez examiner les signaux exacts et le cheminement temporel sans avoir à intervenir sur un contrôleur de banc d'essai ou sur le faisceau de câbles du véhicule. Cela facilite considérablement l'isolation des défauts logiciels par rapport à ce qui serait possible ultérieurement dans un environnement de laboratoire partagé.

Le SIL est utile car la génération de code, les paramètres du compilateur, les types de données et les interfaces des modules introduisent tous des comportements qu’un schéma fonctionnel seul peut masquer. Un modèle peut paraître correct alors que le code généré tronque une valeur, interprète mal un facteur d’échelle ou appelle une tâche dans le mauvais ordre. Le SIL détecte ces problèmes d’implémentation à un stade où les corrections sont encore rapides et traçables. C’est à ce stade que le logiciel devient une preuve technique vérifiable, plutôt qu’une simple hypothèse de conception.

La SIL fait suite à la vérification du modèle avant la validation HIL

La phase SIL intervient après la vérification du modèle et avant Simulation HIL . Une fois que la logique de contrôle fonctionne correctement au niveau du modèle, la phase SIL vérifie que le code généré ou écrit manuellement respecte bien cette même intention fonctionnelle. Cette séquence permet d'éviter que des défauts de code ne viennent perturber les tests matériels ultérieurs et ne fassent perdre du temps sur le banc d'essai.

Un contrôleur de freinage illustre clairement cette séquence. La vérification du modèle confirme que le contrôle du glissement, les demandes de pression et les états de repli se comportent correctement en simulation. Le SIL teste ensuite la version finale du logiciel sur les mêmes cas d’installation afin de vérifier que l’implémentation respecte toujours ces règles. Le HIL intervient ensuite, lorsqu’il est nécessaire de vérifier comment le contrôleur gère la synchronisation des E/S cibles, le trafic réseau et les contraintes d’interface matérielle que l’exécution purement logicielle ne reproduit pas intégralement.

Les équipes ont tendance à sauter des étapes lorsque les délais se resserrent, mais ce raccourci se retourne généralement contre elles. Si l’on passe directement de la modélisation aux tests HIL, les défaillances en laboratoire peuvent provenir de la logique logicielle, de la génération de code, de la configuration du planificateur ou du câblage d’E/S, et le laboratoire ne permettra pas de déterminer laquelle de ces causes a échoué en premier. Le SIL réduit le champ de recherche avant que le matériel n’entre en jeu. Il ne remplace pas le HIL, et n’a pas besoin de le faire. Il prépare le HIL afin que les tests matériels apportent des réponses aux questions relatives au matériel.

Utilisez la technologie SIL lorsque l'évolution des logiciels devance la disponibilité du matériel

Le SIL constitue la prochaine étape logique lorsque le rythme de mise à jour des logiciels est plus rapide que celui de la mise au point du matériel. Il offre un environnement stable pour exécuter les versions quotidiennes, tester les scénarios de défaillance et vérifier les contrats d'interface, alors que les bancs d'essai, les prototypes ou les contrôleurs cibles sont encore en retard, partagés ou incomplets.

Plusieurs éléments indiquent que le SIL devrait précéder la poursuite des travaux en laboratoire :

• Votre calendrier de lancement du matériel est en retard par rapport à votre cadence de publication des logiciels.
• Votre modèle d'installation reproduit déjà les états de fonctionnement qui vous intéressent.
• Votre équipe a besoin de tests de régression quotidiens après chaque fusion de code.
• L'injection de défauts est plus sûre en simulation que sur les équipements de laboratoire.
• Les contrats d'interface entre les modules continuent de changer d'une semaine à l'autre.

Une équipe chargée du groupe motopropulseur automobile est souvent confrontée à cette situation précise. Le développement du logiciel de commande de l’onduleur se poursuit, mais la prochaine révision du contrôleur et le prochain créneau d’essai au dynamomètre ne seront disponibles que dans plusieurs semaines. Le SIL permet de poursuivre la validation, car le code peut toujours être testé avec des rampes de vitesse, des paliers de couple, des conditions de « retour à la maison » et des défaillances de capteurs. Ce rythme est essentiel lorsque l’on cherche à maintenir la qualité du logiciel en phase avec un calendrier de développement actif, plutôt que d’attendre que les goulots d’étranglement matériels soient levés.

«test SIL exécuter un logiciel sur des capteurs, des actionneurs et un comportement de l'installation simulés, plutôt que sur du matériel physique. »

SIL réduit les coûts de validation grâce à une détection plus précoce des défauts

La SIL permet de réduire les coûts de développement, car elle permet d'identifier les défauts logiciels avant même que les pièces prototypes, les réservations de laboratoire et les techniciens de banc d'essai n'entrent en jeu. Vous pouvez effectuer des tests de régression à grande échelle pendant la nuit, remonter les défaillances jusqu'aux signaux précis à l'origine de celles-ci et les corriger tant que la modification du code reste peu coûteuse et que l'ingénieur responsable se souvient encore de la modification apportée.

L'enjeu financier dépasse largement le budget d'un seul laboratoire. La mauvaise qualité des logiciels a coûté à l'économie américaine au moins 2,41 billions de dollars en 2022. Le SIL ne résoudra pas ce problème, mais il s'attaque à l'une de ses principales causes : les défauts découverts trop tard, dans des contextes où chaque défaillance mobilise des ressources humaines coûteuses, du matériel et des marges de temps précieuses.

Une suite de tests de régression du contrôle de traction illustre bien ce principe. Vous pouvez exécuter des cas de test sur asphalte sec, sur neige tassée, de biais des capteurs et de réinitialisation du chien de garde en un seul lot automatisé, puis comparer les résultats au comportement attendu avant la mise en production de la prochaine version. Si un filtre de vitesse de roue cesse de fonctionner après une fusion de code, l’équipe le détecte rapidement et le corrige avant que ce défaut ne fasse perdre du temps sur le dynamomètre ou ne déclenche une enquête HIL source de confusion. Une isolation précoce transforme les tests, qui passent ainsi d’un goulot d’étranglement à un filtre.

Le SIL dépend de la précision temporelle au niveau des interfaces logicielles

SIL ne fournit des réponses utiles que lorsque la synchronisation des interfaces, l'échantillonnage, la quantification et la planification des tâches correspondent au contexte logiciel cible. Si ces détails ne sont pas bien définis, le code peut sembler correct en simulation, mais échouer dès lors que la synchronisation des E/S, la charge des interruptions ou les interactions asynchrones entre tâches deviennent plus strictes.

Un contrôleur de couple peut réussir tous les tests nominaux et pourtant présenter des dysfonctionnements si le logiciel utilise des données de rétroaction de courant obsolètes ou envoie sa commande avec un temps de retard. Ce type de problème survient lorsque les temps d’échantillonnage, les mises à jour des tampons et les transitions de vitesse ne sont pas représentés fidèlement. La mise à l’échelle en virgule fixe joue également un rôle important. Un modèle utilisant l’arithmétique en virgule flottante peut masquer des débordements, des saturations ou des pertes de résolution auxquels le logiciel déployé sera immédiatement confronté.

Les équipes qui utilisent OPAL-RT ou tout autre environnement de simulation comparable doivent néanmoins définir ces hypothèses d’interface avec soin, car la vitesse de calcul à elle seule ne suffira pas à pallier un contrat de synchronisation insuffisant. Il est nécessaire d’intégrer explicitement dans le harnais de test le comportement du planificateur, la latence des signaux et les contraintes numériques. Lorsque le SIL reproduit le contexte logiciel de manière suffisamment fidèle, les défaillances prennent tout leur sens. Dans le cas contraire, la réussite des tests peut créer une fausse confiance qui vous coûtera plus cher par la suite.

test SIL Simulation HIL

La principale différence entre test SIL Simulation HIL l'élément testé. Le SIL consiste à exécuter un logiciel avec des entrées et des sorties simulées, tandis que le HIL consiste à connecter le contrôleur à des interfaces physiques d'E/S et matérielles. Le SIL permet de répondre plus tôt aux questions relatives à la logique et à l'intégration logicielle, tandis que le HIL permet de répondre aux questions relatives à l'interaction matérielle à un stade plus proche du déploiement.

Une équipe chargée de la gestion des batteries utilise souvent ces deux boucles dans cet ordre. Le SIL détecte rapidement les défauts de la logique d’équilibrage, les cas limites des estimateurs et les seuils de défaillance, puis le HIL vérifie la synchronisation des E/S cibles, les messages réseau et les interactions avec le matériel de banc d’essai avant la mise en production. Si vous demandez au HIL d’effectuer ces deux tâches, vous passerez plus de temps à diagnostiquer les problèmes logiciels là où leur détection coûte le plus cher.

Un processus SIL dans le secteur automobile relie les exigences à des tests exécutables

Un workflow SIL efficace dans le secteur automobile commence par les exigences et se termine par des résultats automatisés (réussite ou échec) liés à une version du logiciel. La structure de ce workflow est simple : sélectionner l'exigence, définir le scénario, exécuter le code sur le modèle de l'installation, puis comparer les résultats obtenus à des règles d'acceptation mesurables.

Un contrôleur de maintien de voie permet de clarifier le schéma. Une exigence stipule que le contrôleur doit limiter le couple de braquage en cas de perte de signal d’un capteur, tout en garantissant un état de secours sûr. L’équipe transforme cette exigence en un cas de test comprenant une route simulée, un modèle de véhicule, un événement de perte de signal et la réponse logicielle attendue. La version du logiciel s’exécute en SIL, le harnais enregistre les états internes et les sorties, et le résultat est relié à l’exigence d’origine afin que la défaillance puisse faire l’objet de mesures correctives.

Ce processus fonctionne car il préserve l’intégrité de la chaîne de traçabilité. Vous ne vous contentez pas de vérifier que le code s’exécute. Vous vérifiez qu’une exigence spécifique reste valable après l’intégration du code, les mises à jour d’étalonnage et les modifications d’interface. Cette traçabilité est essentielle dans les programmes automobiles où les revues de sécurité, les versions logicielles et la validation des étalonnages dépendent toutes de preuves reproductibles. Lorsque le SIL s’intègre à la régression continue, chaque modification du code répond à la même norme d’exécution, au lieu de reposer sur la mémoire et les habitudes manuelles de test sur banc.

La SIL échoue lorsque les hypothèses de synchronisation masquent des défauts d'intégration

La SIL échoue lorsque les équipes partent du principe que la correction fonctionnelle suffit et négligent la synchronisation, la précision numérique ou le comportement des interfaces. Une suite de tests réussie peut tout de même masquer des interruptions manquées, des erreurs de mise à l'échelle, des conflits de planification et des défaillances asynchrones qui apparaissent ultérieurement sur le banc d'essai ou dans le véhicule.

Une équipe chargée de la commande d’un moteur peut réussir les cas de couple et de vitesse nominaux, puis rencontrer des difficultés dès qu’une tâche de diagnostic prend le pas sur la boucle de commande au mauvais moment. Une autre équipe peut modéliser les données des capteurs comme étant exemptes de bruit et synchrones, puis passer à côté d’un défaut qui n’apparaît qu’avec des messages retardés et des valeurs obsolètes. Ces erreurs ne sont pas dues à la faiblesse du SIL. Elles surviennent parce que le cahier des charges de la simulation était trop restreint par rapport aux risques logiciels testés.

« Une approche SIL rigoureuse permet de mettre en place un HIL afin de poser des questions plus pertinentes et d'utiliser au mieux le temps passé en laboratoire. »

C’est pourquoi, dans le cadre d’OPAL-RT, les discussions avec les équipes d’ingénieurs portent souvent sur la précision du solveur, la synchronisation des interfaces et la reproductibilité automatisation l’on aborde la question du débit. Les bonnes pratiques en matière de SIL permettent de gagner la confiance au fil du temps, car elles remplacent les tests reposant sur de nombreuses hypothèses par des preuves concrètes que l’on peut défendre lorsque les délais se resserrent.