Qu'est-ce que le test SIL dans l'automobile ?

Principaux enseignements

• Le SIL offre un maximum de valeur ajoutée lorsqu'on l'utilise pour valider le comportement d'un logiciel destiné à la production avant que le matériel ne vienne introduire des variables supplémentaires.
• Une configuration SIL adéquate doit refléter les interfaces cibles, les hypothèses du planificateur et les seuils de réussite ou d'échec, afin que les résultats restent exploitables par la suite.
• Les approches SIL et HIL donnent les meilleurs résultats lorsqu'elles sont mises en œuvre comme des étapes enchaînées : la SIL permet de détecter précocement les défauts logiques, tandis que la HIL confirme la synchronisation et l'intégration matérielle.

Les tests SIL dans le secteur automobile permettent de vérifier le logiciel de production à l'aide d'une simulation du véhicule et de l'usine, ce qui permet de détecter les erreurs logiques avant que le matériel ne vienne ralentir le processus.

Les équipes ont recours test SIL le logiciel de commande est suffisamment stable pour fonctionner en boucle fermée, mais que l’unité de commande électronique, les capteurs ou le banc d’essai ne sont pas encore disponibles ou que leur utilisation s’avère trop coûteuse. Ce moment est crucial, car il est bien moins onéreux de corriger les défauts logiciels avant qu’ils ne se transforment en problèmes de synchronisation ou d’interface. Démontrer qu’un véhicule automatisé est 20 % plus sûr qu’un conducteur humain pourrait nécessiter environ 11 milliards de miles de conduite si l’on se basait uniquement sur le kilométrage routier, selon une analyse de RAND.

La SIL prend tout son sens lorsque vous la considérez comme une étape de validation sérieuse plutôt que comme une simple vérification rapide du modèle. Vous démontrez ainsi que le logiciel embarqué, ses interfaces et sa logique de contrôle sont capables de résister à des cas limites avant même de consacrer du temps en laboratoire au matériel. Cette approche raccourcit les boucles de rétroaction et offre un point de départ plus solide Simulation HIL ultérieurs Simulation HIL . Si vous menez la SIL avec rigueur, vous avancerez plus vite et aurez davantage confiance dans les résultats.

Les tests SIL permettent de vérifier le bon fonctionnement du logiciel embarqué par rapport à un modèle de l'installation

« Vous exécutez le code du contrôleur sous forme de logiciel sur un ordinateur hôte et vous vérifiez comment il réagit aux états simulés du véhicule, aux défauts et aux actions du conducteur avant que le matériel cible n'entre dans la chaîne de test. »

Les tests SIL permettent de vérifier un logiciel embarqué compilé ou généré automatiquement en boucle fermée à l'aide d'un modèle mathématique de l'installation. Un contrôleur de couple de freinage illustre clairement ce principe. Le logiciel reçoit les vitesses des roues, la demande sur la pédale et les estimations de frottement routier provenant du modèle de l’installation, puis renvoie des commandes de couple vers cette même simulation. Si le contrôleur entre en saturation, oscille ou manque une transition d’état lors d’un arrêt sur une chaussée verglacée, les tests SIL mettent en évidence ce comportement alors que le code est encore facile à inspecter. Les équipes utilisent cette étape pour vérifier la logique de contrôle, les règles d’étalonnage, les chemins de diagnostic et la gestion des défauts. Vous obtenez un retour rapide sur l'intention du logiciel, ce qui correspond exactement aux besoins des tests au banc ultérieurs, avant que les questions de synchronisation matérielle n’entrent en ligne de compte.

La vérification SIL intervient après la conception du modèle et avant l'intégration matérielle

La phase SIL intervient une fois que la conception de l'algorithme est stabilisée et avant que l'intégration matérielle ne commence à peser sur le calendrier. Il convient de la mettre en œuvre lorsque la structure logicielle reflète suffisamment fidèlement le comportement cible pour permettre de tester les interfaces, le flux d'états et les réactions en cas de défaillance, mais que l'unité de contrôle électronique ou le banc d'essai ne sont pas encore prêts. Ce moment est celui qui offre le meilleur rapport effort/résultat.

Le contrôleur du circuit d’admission d’air d’un moteur en est un exemple courant. L’équipe de contrôle s’est déjà mise d’accord sur la logique d’estimation, les cadences des tâches et les points de calibrage, mais l’équipe matériel est encore en train de finaliser le mappage des entrées/sorties et la disponibilité des cartes. Lancer des tests SIL à ce stade permettra de mettre en évidence une logique d’état instable, des valeurs par défaut inadaptées ou une récupération en cas de défaillance insuffisante, sans avoir à attendre qu’un créneau de test sur banc se libère. Les équipes qui sautent cette étape sont souvent confrontées à ces mêmes problèmes par la suite, alors que chaque défaillance prend plus de temps à reproduire. Il est préférable d'obtenir des réponses aux questions relatives au logiciel avant que le matériel n'ajoute des variables supplémentaires.

Une architecture SIL doit refléter les limites du logiciel cible

Un cadre SIL solide reflète les limites logicielles qui existeront sur le contrôleur cible. Le modèle, les hypothèses relatives au planificateur, la mise à l'échelle des signaux, les diagnostics et les critères de réussite ou d'échec doivent refléter suffisamment fidèlement l'intention de production pour que vos résultats conservent toute leur pertinence une fois le code déployé sur le matériel. Si ces limites s'écartent, la confiance s'effrite rapidement. C'est pourquoi la conception du cadre est tout aussi importante que le nombre de tests.

Prenons l’exemple d’un contrôleur de direction assistée électrique comportant des modules distincts pour la demande de couple, la logique d’assistance et les diagnostics. Une configuration SIL efficace maintient ces modules isolés, les alimente via les mêmes contrats d’interface que ceux prévus ultérieurement, et enregistre les sorties à des fréquences adaptées aux tâches. Les équipes utilisant des plateformes telles qu’OPAL-RT veillent souvent à ce que les définitions de scénarios et les hypothèses d’interface restent cohérentes, de l’exécution sur ordinateur jusqu’aux étapes de laboratoire ultérieures, ce qui réduit les retouches lorsque le contrôleur est implémenté sur le matériel. Vous mettez en place un parcours de validation, et non une simulation ponctuelle. Des limites clairement définies facilitent le traçage des défaillances et renforcent la fiabilité des résultats.

Les scénarios en boucle fermée permettent de détecter plus rapidement les défauts logiques

Les scénarios en boucle fermée permettent de détecter plus rapidement les défauts logiques, car le logiciel doit réagir en permanence aux conséquences de ses propres sorties. Les vérifications en boucle ouverte permettent de valider une fonction isolée, mais seuls les tests en boucle fermée révèlent comment les transitions d'état, les hypothèses de synchronisation et les réponses aux défauts se comportent lorsque la physique du véhicule exerce une contre-pression. Cette différence est cruciale lorsque les cas limites s'accumulent. Elle permet de mettre en évidence l'intention de contrôle en situation de contrainte.

Un contrôleur de gestion de batterie en est un bon exemple. Un scénario peut combiner une variation rapide de la charge, un capteur de température déréglé et un événement de basse tension, tandis que le modèle de l’installation met à jour le comportement des cellules à chaque étape. Cette configuration permettra de mettre en évidence une logique de déclassement thermique instable ou un verrouillage de défaut retardé bien avant qu’un essai au banc ne soit programmé. L’échelle de simulation a également son importance. Les accidents de la route causent environ 1,19 million de décès chaque année, ce qui explique pourquoi les équipes ont besoin d’une couverture de scénarios plus large que ne peut l’offrir le seul kilométrage physique. Le SIL en boucle fermée vous permet de condenser la couverture des scénarios en un cycle de validation pratique.

Le choix entre SIL et HIL dépend de l'objectif de validation

La principale différence entre le SIL et le HIL réside dans l'emplacement du code du contrôleur et le type de données dont vous avez besoin. Le SIL exécute le contrôleur sous forme de logiciel sur un modèle, tandis que le HIL relie l'unité de contrôle réelle au comportement simulé de l'installation et à la synchronisation physique des E/S. Chaque méthode répond à une question de validation différente. Choisir la mauvaise méthode fait perdre du temps.

Un contrôleur de motorisation électrique illustre clairement cette distinction. Le SIL est l'environnement idéal pour tester l'arbitrage de couple, les règles de fonctionnement en mode « limp-home » et les transitions de mode sur des milliers de combinaisons de vitesse et de charge. Le HIL devient indispensable dès lors qu'il faut vérifier que la synchronisation cible, le conditionnement des entrées analogiques et les broches de diagnostic fonctionnent correctement sur l'unité de commande réelle. Il convient de choisir la méthode la mieux adaptée au problème à résoudre.

La vitesse d'exécution des tests n'a d'importance que lorsque la fiabilité du modèle est avérée

La vitesse des tests n'a d'importance que si le modèle de l'installation est suffisamment fiable pour mettre le logiciel à l'épreuve de la même manière que le ferait le véhicule. Les simulations rapides semblent productives, mais elles induisent en erreur si le décalage des capteurs, les limites des actionneurs, le bruit et la dynamique des défaillances sont simplifiés au point de perdre toute pertinence. Il vous faut un modèle qui reflète fidèlement le comportement que vous validez. La vitesse sans fidélité ne fait qu'avancer le moment où les erreurs apparaissent.

« Un modèle de gestion de batterie qui ne tient pas compte du déséquilibre entre les cellules ou du décalage des capteurs conduira à la validation d'un logiciel qui tombera en panne dès que le matériel introduira ces effets. »

Le même problème se pose dans le contrôle de la transmission lorsque la dynamique de remplissage de l'embrayage est trop simplifiée et que la logique de changement de vitesse ne détecte jamais de transitions brusques. Les bons modèles SIL se concentrent sur la dynamique qui détermine le comportement du logiciel, et non sur des détails superflus. Il n'est pas nécessaire d'avoir une physique parfaite pour chaque composant du véhicule. Il faut en revanche une fidélité suffisante dans la chaîne de contrôle pour que les résultats « réussi » ou « échoué » aient un sens une fois que l'on sort de l'environnement de simulation.

Des interfaces médiocres nuisent aux résultats du SIL avant même que les équipes ne s'en rendent compte

Des interfaces de mauvaise qualité compromettent les résultats du SIL avant même que les équipes ne s'en rendent compte, car le logiciel semble stable tandis que le dispositif de test masque discrètement les défauts d'intégration. Une mise à l'échelle incorrecte des signaux, des hypothèses manquantes concernant le planificateur, des paramètres par défaut trop « conviviaux » ou un timing imprécis des défauts peuvent donner l'impression qu'un contrôleur défaillant fonctionne correctement. C'est la rigueur en matière d'interfaces qui permet au SIL de passer d'un simple exercice théorique à une validation logicielle utile. De petits décalages créent d'importants angles morts.

C’est souvent un programme de commande de moteur qui met ce problème en évidence en premier. Les limites de demande de courant semblent correctes en SIL, mais les essais au banc révèlent par la suite un comportement instable, car la période du planificateur, le filtrage des capteurs ou la logique de suppression des rebonds ne correspondaient jamais aux hypothèses de la cible. Les équipes qui examinent les détails de l’interface dès le début évitent ce piège. Ces vérifications méritent généralement qu’on s’y attarde avant d’ajouter de nouveaux scénarios ou d’élargir la couverture des tests de régression.

• La mise à l'échelle du signal correspond exactement aux spécifications du logiciel.
• Les fréquences d'exécution des tâches dépendent du planificateur utilisé sur le contrôleur cible.
• Les valeurs par défaut ne masquent jamais les données manquantes des capteurs.
• Les indicateurs de défaut utilisent la même synchronisation que les diagnostics en production.
• Les seuils de réussite ou d'échec correspondent aux exigences applicables aux véhicules.

Le SIL doit passer le relais de manière transparente à l'exécution HIL

Le SIL doit assurer une transition en douceur vers l'exécution HIL grâce à des scénarios partagés, des contrats d'interface stables et des règles de réussite ou d'échec qui restent valables lors du passage au matériel cible. Les équipes obtiennent les meilleurs résultats lorsque le SIL élimine rapidement les défauts logiques et que le HIL se concentre sur la synchronisation des contrôleurs, les E/S physiques et la validation de l'intégration. Cette séquence permet de maintenir la pertinence de la validation. Elle garantit également une utilisation optimale du temps passé en laboratoire.

Un programme d’onduleur de traction illustre bien ce point. Les mêmes scénarios d’accélération, d’injection de défauts et de protection thermique qui ont été validés en SIL devraient pouvoir être reproduits en HIL en ne modifiant que le contexte d’exécution du contrôleur. Lorsque les équipes reconstruisent tout entre chaque étape, elles perdent en traçabilité et refont un travail pour lequel elles ont déjà payé. OPAL-RT répond à cette exigence lorsque les ingénieurs ont besoin de la même logique de validation pour passer de l’exécution logicielle à des tests couplés au matériel sans avoir à reconstruire l’ensemble du dispositif. Une bonne validation SIL est précieuse car elle fournit des preuves solides par la suite, et non parce qu’elle crée une étape de test isolée supplémentaire.