test SIL Simulation HIL test SIL à l'intention des ingénieurs

Principaux enseignements

• test SIL Elle convient à la validation précoce des contrôles, car elle permet de détecter rapidement les problèmes de logique et facilite la réalisation de tests de régression à grande échelle avec un faible coût de mise en place.
• Simulation HIL Cela devient nécessaire dès lors que la synchronisation, les E/S et les interfaces embarquées peuvent modifier le comportement du contrôleur.
• Les équipes bénéficient d'un processus de validation optimal lorsque les phases SIL, PIL et HIL partagent les mêmes modèles, les mêmes objectifs de test et les mêmes critères de réussite d'une étape à l'autre.

Optez pour test SIL lorsque votre prochain défi concerne la logique de commande, et choisissez Simulation HIL lorsque votre prochain défi porte sur la synchronisation, les E/S et l'intégration embarquée.

Les équipes perdent du temps à débattre des appellations au lieu d'adapter la phase de test au défaut qu'elles doivent mettre en évidence. La mauvaise qualité des logiciels a coûté aux États-Unis au moins 2 080 milliards de dollars en 2020. Ce chiffre est important ici, car la détection tardive de défauts entraîne généralement des retouches sur banc d’essai, des retards dans le calendrier et des étalonnages répétés. Une validation rigoureuse passe des modèles logiciels au code compilé, puis à la synchronisation matérielle, dans l’ordre qui élimine le risque suivant avec le moins de frictions possible.

SIL valide le comportement des commandes avant que les E/S physiques n'existent

test SIL permet de vérifier la logique du contrôleur par rapport à une installation simulée avant qu'un contrôleur cible ou un étage de puissance n'arrive sur votre banc d'essai. Vous exécutez le système de contrôle sous forme de code de modélisation ou de logiciel hôte. Les défauts restent visibles et faciles à tracer. Le SIL convient aux phases précoces de conception, d'étalonnage et de tests de régression.

Une équipe chargée de la commande des moteurs peut utiliser le SIL pour tester les limites de courant, les rampes de couple et la récupération après défaut bien avant le câblage du matériel du variateur. Il en va de même pour une loi de commande de vol qui doit rejeter le bruit des capteurs sans provoquer d'oscillations. Chaque cas d'échec renvoie à des équations, des gains ou une logique d'état que vous pouvez examiner grâce à un accès complet aux signaux. Cette visibilité réduit le temps passé à deviner où le comportement s'est écarté de la cible.

Le SIL vous permet également d'effectuer des itérations à moindre coût. Vous pouvez exécuter des milliers de scénarios pendant la nuit, modifier un paramètre et comparer les résultats avant même l'heure du déjeuner. Cette rapidité est d'autant plus cruciale que les exigences sont encore en cours de définition et que le code évolue quotidiennement. Un matériel de test classique ralentirait ce cycle, car chaque nouveau test nécessite la programmation des périphériques, la vérification du câblage et l'accès au laboratoire.

HIL valide les interfaces embarquées dans des conditions de temps réel

Simulation HIL relie le contrôleur réel à un modèle de l'installation fonctionnant en temps réel, ce qui permet de vérifier le comportement du logiciel dans les mêmes conditions de synchronisation et d'E/S que celles qu'il rencontrera en service. L'accent n'est plus mis sur l'intention de l'algorithme, mais sur la réalité de son exécution. La simulation HIL met en évidence les délais non respectés, les erreurs de conditionnement des signaux et les défaillances d'interface.

Un contrôleur de freinage en est un exemple frappant. Le modèle de l’installation transmet à l’ECU la vitesse des roues, la position de la pédale et les états du système hydraulique, puis reçoit en retour des commandes de soupapes avec une synchronisation rigoureuse des cycles. Les accidents de la route ont coûté la vie à 42 514 personnes aux États-Unis en 2022. Les fonctions de sécurité doivent faire l’objet d’une validation au banc d’essai permettant de détecter les défaillances de synchronisation et d’interface avant le début des essais sur véhicule ou sur piste.

Le HIL prend toute son importance dès lors que votre principale inconnue se situe à la frontière entre le logiciel et le matériel. La mise à l’échelle de l’ADC, la latence PWM, la gestion des messages CAN et les réponses des broches de défaut semblent souvent correctes dans un modèle de bureau, mais échouent lors des essais sur banc. C’est cette différence qui explique pourquoi les équipes considèrent le HIL comme un filtre d’intégration, et non simplement comme un simulateur plus performant. Il vous apporte la preuve que le contrôleur continue de se comporter correctement lorsque la synchronisation est stricte et que les signaux sont physiques.

La fidélité temporelle marque la frontière entre le SIL et le HIL

« La principale différence entre test SIL et Simulation HIL réside dans la synchronisation déterministe et l'interaction électrique. »

Le SIL vérifie la logique avec une exécution flexible sur une machine hôte. Le HIL vérifie l'exécution avec des temps d'échantillonnage fixes et des interfaces physiques. Cette distinction détermine les défauts que vous détecterez et ceux qui vous échapperont.

Un contrôleur de gestion de batterie illustre clairement ce principe. La logique d’équilibrage des cellules peut sembler parfaite en SIL, mais le module embarqué peut tout de même mal gérer la synchronisation des interruptions ou la mise à l’échelle du frontal analogique lors des essais HIL. C’est pourquoi la fidélité temporelle est le facteur déterminant, et non le nom du modèle ou les préférences de l’équipe. Dès lors que la précision de l’horloge et les interfaces physiques influencent la réussite ou l’échec des tests, vous entrez dans le domaine des essais HIL.

La technologie SIL fonctionne mieux lorsque les évolutions du code devancent celles de l'accès au matériel

Le SIL est la solution idéale lorsque les mises à jour logicielles se succèdent à un rythme trop rapide pour que votre banc d'essai puisse les intégrer. Vous pouvez valider le comportement fonctionnel, ajuster les paramètres et étendre la couverture des tests de régression sans avoir à attendre la mise à disposition de cartes, de faisceaux de câbles ou de créneaux en laboratoire. Le SIL s'impose donc comme le choix le plus judicieux en période de changements fréquents dans la conception. Il permet aux ingénieurs de se concentrer sur la logique plutôt que sur les tâches administratives liées à la mise en place.

Une équipe de contrôle du stockage d'Énergie s peut tester les limites de charge, les seuils thermiques et la commutation de mode à l'aide d'un modèle de système représentant le bloc-batterie et le convertisseur. Une nouvelle branche de contrôle peut être vérifiée le jour même de son intégration dans le système de gestion de versions. Les cas de test peuvent également être associés aux exigences, de sorte qu'une mise à jour ayant échoué indique directement le chemin logique concerné. Ce type de cycle est difficile à reproduire dès lors qu'un banc d'essai matériel partagé est intégré au planning.

SIL convient également aux campagnes de tests de défaillance qu’il serait difficile, voire dangereux, de réaliser sur du matériel physique. Il est ainsi possible d’injecter des pics de capteurs impossibles, des estimations d’état erronées ou des transitions de charge extrêmes sans risquer d’endommager le matériel. Ces cas permettent d’affiner le contrôleur avant même que le travail sur l’interface ne commence. Les équipes qui sautent cette étape repoussent généralement les défaillances logiques de base vers des bancs d’essai ultérieurs, où leur isolation prendra davantage de temps.

L'architecture HIL s'avère payante lorsque le risque lié à l'intégration se déplace vers les interfaces

Le test HIL prend tout son sens lorsque votre principale incertitude ne porte plus sur la logique logicielle, mais sur la synchronisation, le câblage, les bus et les E/S embarquées. Le banc d'essai permettra de vérifier si le contrôleur continue de fonctionner correctement lorsque les planificateurs, les interruptions, les convertisseurs et les communications interviennent tous simultanément. Cela répond à une question différente de celle posée par le test SIL. Il s'agit ici de tester l'exécution en conditions de contrainte.

Un contrôleur de puissance électronique illustre bien ce principe. Les commandes de grille, les signaux de déclenchement et le retour de courant peuvent tous sembler corrects dans un modèle hôte, mais les essais au banc peuvent révéler des plages écrêtées, un échantillonnage tardif ou une gestion incorrecte du temps mort. L'émulation de capteurs permet également d'injecter des défauts de ligne, des impulsions manquantes ou des mesures bruitées sans mettre en danger un dispositif à haute puissance. Ces tests sont essentiels, car les défaillances d'interface passent souvent inaperçues jusqu'à ce que le contrôleur interagit avec les chemins de signaux physiques.

La méthode HIL facilite également les discussions de validation, bien plus qu’une simple simulation sur banc d’essai. Elle permet de présenter les temps de réponse exacts, les charges de bus et la récupération après défaillance au niveau des broches du contrôleur. Ces données aident les responsables techniques à déterminer si un système est prêt pour les essais au banc, sur banc d’essai ou sur site. Cette méthode coûte plus cher que la méthode SIL, mais elle s’avère rentable lorsque les problèmes d’intégration constituent la principale source de retard.

PIL vérifie le code compilé avant l'intégration complète au matériel

La méthode « Processor-in-the-Loop » (PIL) se situe à mi-chemin entre les modèles logiciels et les bancs d’essai matériels complets. Elle exécute le code compilé du contrôleur sur le processeur cible ou sur une carte représentative de ce processeur, tandis que l’installation reste dans l’environnement logiciel. Cela permet de mettre en évidence les problèmes de génération de code, les écarts numériques et les effets de synchronisation fondamentaux. La méthode PIL permet de vérifier si le code compilé correspond toujours à l’intention du modèle.

Une routine de contrôle en virgule fixe constitue un cas courant. Le modèle peut fonctionner correctement en virgule flottante, puis présenter des problèmes de débordement, de quantification ou de gigue du planificateur dès que le code compilé s'exécute sur le processeur. PIL détecte ce décalage avant même que vous ne passiez du temps à mettre en place un banc d'essai HIL complet. Cela s'avère particulièrement utile pour les contrôleurs générés automatiquement, où le modèle semble correct mais où l'implémentation générée doit encore être validée.

Le PIL ne remplacera pas le HIL, car il ne couvre pas l'intégralité des E/S électriques ni le comportement des interfaces au niveau du banc d'essai. Il permettra toutefois d'éliminer une couche intermédiaire d'incertitude coûteuse. Les équipes qui utilisent efficacement le PIL abordent le HIL avec moins de surprises liées à la génération de code et des références de synchronisation plus claires. Cela réduit l'ampleur des travaux d'intégration ultérieurs et facilite le débogage.

La continuité du flux de travail est plus importante que n'importe quelle étape de test prise isolément

Un transfert défaillant entre les phases SIL, PIL et HIL fait perdre plus de temps qu'un résultat médiocre à l'une de ces étapes. Il faut disposer de modèles cohérents, de cas de test reproductibles et de critères de réussite comparables afin que chaque étape apporte des éléments probants au lieu d'imposer des retouches. Les workflows les plus performants préservent l'intention initiale, de la simulation sur ordinateur à l'exécution sur banc d'essai. C'est de cette continuité que découle le respect du calendrier.

Une équipe de contrôle peut conserver un seul modèle d’installation, une seule bibliothèque de scénarios et une seule convention de nommage à toutes les étapes. Un test de limite de couple qui échoue en SIL doit pouvoir être identifié en PIL et en HIL sans qu’il soit nécessaire de réécrire la logique d’acceptation. OPAL-RT répond à ce besoin d’exécution, car les équipes peuvent transférer le travail de simulation issu de la validation basée sur des modèles vers des bancs d’essai en temps réel sans avoir à reconstruire l’intégralité du flux de travail à chaque fois. Cette continuité réduit les boucles de débogage et garantit la cohérence des preuves de défaillance entre les outils et les laboratoires.

Vous préservez également la confiance des ingénieurs lorsque la chaîne reste intacte. Si chaque étape repose sur des hypothèses différentes, l'équipe passe son temps de révision à débattre de la configuration plutôt que du comportement. Une continuité claire facilite la remontée des problèmes, car chaque défaillance dispose d'un historique traçable. C'est important pour les responsables de laboratoire et les chefs de projet techniques, qui ont besoin de preuves, et pas seulement d'un historique des tests effectués.

Choisissez la méthode de test qui permet d'éliminer le risque suivant

« La méthode qui mérite que vous y consacriez votre prochaine heure est celle qui permettra de mettre en évidence le prochain échec avec un minimum de préparation. »

La bonne décision est simple : utilisez la SIL pour la logique et l'étalonnage, la PIL pour les vérifications du code compilé et la HIL pour la vérification des temps de réponse et des interfaces. Les équipes obtiennent de meilleurs résultats lorsqu'elles choisissent l'étape suivante en fonction du mode de défaillance, et non par habitude. Cette approche permet de maintenir un équilibre entre les coûts, le temps passé en laboratoire et les efforts de débogage.

• Optez pour SIL lorsque l'accès au modèle et le volume des scénarios sont des facteurs déterminants.
• Optez pour le PIL lorsque le code généré nécessite une vérification au niveau du processeur.
• Optez pour le mode HIL lorsque la fréquence d'échantillonnage et les E/S physiques peuvent influencer le résultat.
• Ne passez à l'étape suivante qu'une fois que l'étape en cours aura permis de lever son principal point d'incertitude.
• Veillez à ce que l'objectif du test reste le même à toutes les étapes afin que les résultats restent comparables.

Un plan de validation rigoureux peut paraître simple sur le papier, mais c’est lui qui permet de gagner le plus de temps dans la pratique. On ne gagne pas en effectuant tous les tests sur un banc de mesure matériel trop tôt, pas plus qu’en restant au stade du logiciel une fois que le respect des délais devient le principal risque. OPAL-RT prend tout son sens dans ce contexte, car certaines équipes ont besoin de combiner ces deux approches au sein d’un même flux d’exécution, depuis les vérifications précoces du modèle jusqu’aux tests rigoureux en temps réel sur banc de mesure.