Guide des essais Hardware-in-the-Loop (HIL) en 2026

Principaux enseignements

• La valeur de la HIL réside dans la boucle fermée, car un contrôleur ne met en évidence l'instabilité de la rétroaction et les défauts de protection que lorsque l'installation simulée réagit à ses propres sorties.
• Les approches « modèle en boucle », « logiciel en boucle » et « processeur en boucle » éliminent chacune une catégorie d’incertitude avant la phase HIL ; ainsi, le fait de sauter une étape ne supprime pas le coût de débogage, mais le reporte simplement à un stade ultérieur.
• La fiabilité d'un résultat HIL dépend du modèle de l'installation et du pas de temps, ce qui confère à la validation du modèle et à la gestion des versions une importance équivalente à celle du matériel utilisé sur le banc d'essai.

Simulation HIL Les tests consistent à placer un équipement réel dans une boucle fermée avec une simulation en temps réel de la machine qu’il commande, de sorte qu’il se comporte exactement comme il le ferait dans le produit fini.

La simulation répond à chaque commande dans les mêmes microsecondes que celles attendues par le matériel, ce qui distingue le HIL d’une configuration qui se contente de rejouer une trace enregistrée. Les autorités de régulation américaines ont recensé 997 rappels de sécurité concernant plus de 31 millions de véhicules en 2025, et les campagnes de cette ampleur coûtent si cher parce que le défaut a atteint le parc automobile. S’il est détecté en laboratoire, cela ne coûte qu’une révision du micrologiciel.

Le HIL correspond au moment dans un programme où les modèles et le matériel physique doivent enfin concordar. Si vous le considérez comme une simple étape de vérification de dernière minute, l'intégration s'en trouve ralentie. Si vous le considérez comme l'étape où le logiciel de contrôle est soumis à ses tests les plus rigoureux, les derniers mois se déroulent alors dans un calme relatif.

Ce que les tests « Simulation HIL » signifient réellement pour les ingénieurs

Simulation HIL Les tests consistent à faire interagir un contrôleur réel avec une simulation de l'ensemble des éléments auxquels il est connecté, les deux côtés se mettant à jour en temps réel. L'unité testée envoie ses commandes au simulateur ; celui-ci calcule la réponse que donnerait la machine physique, et cette réponse est renvoyée via le câblage réel dans un intervalle de temps défini.

Un contrôleur de gestion de batterie concrétise cette idée. Au lieu de le raccorder à un pack sous tension, on le connecte à un simulateur qui reproduit les tensions, les courants et les températures des cellules d’un pack qui n’a pas encore été construit. Le contrôleur interprète ces signaux comme si les cellules se trouvaient devant lui, décide quand ouvrir les contacteurs, et le simulateur recalcule l’état du pack.

C'est justement le principe même de la boucle fermée. Un tracé enregistré confirme qu'un régulateur réagit à une entrée, mais il ne peut pas montrer ce qui se passe lorsque la sortie du régulateur elle-même modifie le système qu'elle mesure. L'instabilité due à la rétroaction et la logique de protection qui s'oppose à elle-même n'apparaissent qu'une fois que l'installation réagit à son tour.

« L'instabilité de la boucle de rétroaction et la logique de protection qui s'oppose à elle-même n'apparaissent qu'une fois que l'installation réagit. »

Ce qui se trouve à l'intérieur de la boucle et ce qui reste dans la simulation

Le matériel physique intégré à la boucle comprend généralement le contrôleur, ses étages d'entrée et de sortie, ainsi que son micrologiciel de production. Tout ce qui est coûteux, dangereux ou non encore construit reste dans la simulation, c'est-à-dire généralement l'installation. Une couche de conditionnement s'intercale entre les deux afin que les niveaux de signal correspondent aux attentes de l'unité.

Un banc d'essai de propulsion électrique permet de visualiser où se situe généralement la ligne. La carte de commande du convertisseur de traction est physique, tandis que l'étage de puissance, le moteur, la charge et la batterie se trouvent dans le simulateur. Le contrôleur continue de commuter les signaux de grille à 10 kHz ou plus, et le simulateur doit répondre à chaque front de commutation.

C'est la manière dont vous tracez cette limite qui détermine ce que le test peut démontrer et son coût. Le HIL au niveau du signal maintient l'ensemble à basse tension et à faible intensité ; le contrôleur perçoit ainsi des représentations en millivolts des grandeurs réelles. Le HIL de puissance repousse cette limite et ajoute un étage amplificateur, ce qui permet d'intégrer dans la boucle un moteur réel ou un convertisseur raccordé au réseau à sa puissance nominale. Cela permet de capturer le comportement thermique, ce que la première option ne permettra jamais de faire.

En quoi le HIL diffère-t-il de la modélisation et test SIL

La principale différence entre l’ Simulation HIL et les étapes qui la précèdent réside dans ce qui est physiquement présent. Les méthodes « Model in the Loop » et « test SIL » s’exécutent entièrement sur un ordinateur ; elles permettent donc de tester la logique par rapport à un système mathématique. L’HIL ajoute le matériel de production, sa synchronisation et ses interfaces électriques.

Ces étapes sont séquentielles et non alternatives. Une stratégie de contrôle de traction commence par un schéma fonctionnel validé par rapport à un modèle de véhicule, passe ensuite au stade du code compilé, puis s'exécute sur le processeur cible. Ce n'est qu'après avoir franchi ces trois étapes que l'unité finale est connectée à un véhicule simulé via ses propres connecteurs.

Sauter des étapes fait perdre des semaines. Un défaut qu’un modèle détecterait en quelques minutes lors d’une exécution en boucle se transforme en une session de débogage de deux jours dès qu’il est soumis au comportement du compilateur, à la variation du planificateur et au conditionnement des signaux.

Comment les ingénieurs construisent et câblent un banc de test « Simulation HIL »

Un banc d'essai HIL se compose de quatre éléments. Un simulateur en temps réel résout le modèle de l'installation à un pas de temps fixe ; une couche d'entrée-sortie assure la conversion entre les valeurs numériques et les signaux physiques ; le câblage et le conditionnement sont adaptés au brochage de l'unité ; et un ordinateur hôte héberge le modèle et les séquences de test.

La préparation du modèle représente l'essentiel du travail. Les équipes construisent l'installation dans Simulink, puis la compilent sur la cible du simulateur à l'aide d'un logiciel tel que RT-LAB d'OPAL-RT, qui gère la répartition entre les cœurs du processeur et le FPGA. Les commutations rapides sont transférées vers le FPGA à des pas de temps inférieurs à la microseconde, tandis que la dynamique mécanique et thermique reste sur le processeur à des pas de 50 à 100 microsecondes. L'échelle de banc d'essai suit celle du modèle : ainsi, un châssis OP4512 convient à un contrôleur unique, tandis qu'un OP5707XG offre la densité de canaux requise par un système à convertisseurs multiples.

L'insertion de défauts est l'étape que la plupart des équipes sous-estiment. Les bancs de relais situés entre le simulateur et l'unité permettent de couper une ligne de capteur, de court-circuiter un signal à la masse et d'observer la réaction du code de diagnostic. Effectuer cette opération sur du matériel réel risque de l'endommager, et sur un véhicule en mouvement, cela n'est pas sans danger. Sur un banc d'essai, il s'agit simplement d'un script qui s'exécute pendant la nuit.

Pourquoi les essais HIL ont toute leur place dans les secteurs de l'ingénierie

La technologie HIL est présente partout où un contrôleur commande un équipement coûteux, long à fabriquer ou dont la défaillance présente un risque. Les groupes motopropulseurs automobiles, les systèmes de commande de vol des avions, la traction ferroviaire, les convertisseurs de réseau et les variateurs industriels s'appuient tous sur cette technologie, et la raison est toujours la même : les prototypes physiques sont rares, tandis que les logiciels de contrôle évoluent chaque semaine.

Cette tendance est particulièrement marquée dans les réseaux électriques. L’énergie solaire, le stockage par batterie et l’éolien représentent 93 % des 86 GW de nouvelle capacité de production prévue aux États-Unis pour 2026, et chacune de ces installations est raccordée au réseau via un onduleur fonctionnant avec son propre code de contrôle. Un défaut de maintien en service ou de protection dans ce code ne peut être détecté en mettant sous tension une ligne d’alimentation en service ; les fabricants testent donc les systèmes de contrôle sur un réseau simulé.

Aérospatial applique la même logique dans le cadre de règles de certification plus strictes. Un calculateur de commandes de vol effectue des simulations à partir de données aérodynamiques et de modèles d'actionneurs, ce qui permet de reproduire des défaillances, telles qu'un volet bloqué, des centaines de fois avant un essai en vol. La campagne d'essais en vol confirme ensuite ce que les essais au banc avaient déjà démontré.

Erreurs courantes qui remettent en cause la fiabilité des résultats HIL

La plupart des résultats décevants issus de la simulation HIL sont dus à des problèmes de modélisation plutôt qu'à des problèmes matériels. Un banc d'essai qui fonctionne parfaitement mais qui ne reproduit pas fidèlement l'installation validera un contrôleur qui se comportera de manière inappropriée en service, et personne ne s'en rendra compte avant la mise en service. Le pas de temps, la fidélité des signaux et la validation du modèle déterminent la fiabilité de l'exercice.

Cinq habitudes sont à l'origine de la plupart des résultats que les ingénieurs doivent par la suite corriger.

• Exécution du modèle de l'installation avec un pas de temps trop grossier par rapport à la fréquence de commutation du régulateur
• Considérer les entrées et sorties du simulateur comme idéales, en faisant abstraction du bruit des capteurs, des décalages et des chemins de masse
• Valider le modèle de l'installation une seule fois et ne plus jamais le comparer aux données mesurées sur le matériel
• Rédaction de cas de test qui ne couvrent que le fonctionnement nominal, de sorte qu’aucun mode dégradé n’est pris en compte
• Laisser le banc d'essai s'écarter de la version de production, afin que l'unité testée ne soit pas celle qui sera commercialisée

Dans les deux cas, la prévention coûte peu cher, tandis que la détection tardive s'avère onéreuse. Comparer votre modèle de système à une machine réelle dès le départ, puis à nouveau après chaque révision matérielle, permet de garantir la fiabilité des tests. Le contrôle de version du modèle et de la suite de tests est tout aussi important que celui du micrologiciel, car un résultat positif n'a de sens que si l'on peut déterminer exactement ce qui a été exécuté.

« Les résultats les plus décevants en HIL sont le plus souvent dus à des problèmes liés au modèle plutôt qu’à des problèmes matériels. »

À quoi ressemble une pratique rigoureuse de la HIL tout au long d'un programme ?

Les équipes qui tirent un bénéfice durable du HIL considèrent le banc d’essai comme un actif permanent plutôt que comme un investissement ponctuel. Le modèle de simulation évolue au rythme du produit, la suite de tests s’enrichit à chaque problème rencontré sur le terrain, et des tests de régression sont effectués à chaque nouvelle version du micrologiciel. Cette couverture cumulative permet d’aborder sereinement les derniers mois d’un programme.

Le résultat, ce n’est pas une seule découverte spectaculaire. C’est l’élimination progressive des imprévus, de sorte que les semaines d’intégration deviennent une phase de validation plutôt que de découverte. Une équipe qui a exécuté des milliers de cas de défaillance automatisés pendant la nuit pendant six mois aborde les essais sur le terrain en sachant comment son logiciel se comporte dans les conditions extrêmes, et les questions qui restent en suspens sont d’ordre physique. Y parvenir dépend moins de la taille du simulateur que de la rigueur avec laquelle il est utilisé. Les ingénieurs travaillant sur un problème de contrôle spécifique peuvent demander une démonstration HIL à OPAL-RT et transposer leur propre modèle sur un banc d’essai.