Simulation HIL aux ingénieurs chargés de la validation des systèmes

Principaux enseignements

• Simulation HIL s'avèrent particulièrement utiles lorsque la logique du contrôleur est stable et que les risques liés à l'interface deviennent la principale préoccupation.
• La qualité des résultats HIL dépend d'une synchronisation précise, de modèles adaptés à l'usage prévu et de définitions claires des entrées et sorties.
• Les équipes tirent davantage profit de l'analyse des interfaces lorsque celle-ci se concentre d'abord sur les interfaces ayant le plus d'impact, plutôt que d'essayer de reproduire l'ensemble du système.

Simulation HIL permettent de valider un contrôleur réel par rapport à une installation simulée avant de passer aux essais physiques complets.

Cette évolution est importante car elle permet de détecter les défaillances en laboratoire, où il est moins coûteux et plus sûr de repérer les problèmes de synchronisation, les cas limites des capteurs et les actions de commande dangereuses. Le Canada a enregistré 1 931 décès et 8 851 blessés graves liés à accidents de la route en 2022, ce qui nous rappelle que le comportement des commandes mérite une validation rigoureuse avant toute mise en service sur le terrain. Vous n’utilisez pas le HIL pour remplacer tous les tests ultérieurs. Vous l’utilisez pour détecter les défauts d’intégration suffisamment tôt afin de les corriger avec moins de risques.

Simulation HIL des contrôleurs réels à des simulations

Simulation HIL relie le matériel de contrôleur réel à une installation simulée fonctionnant à un pas de temps fixe. Le contrôleur lit les signaux des capteurs et envoie des commandes comme s'il était connecté au système physique. C'est ce que signifie concrètement HIL. Il s'agit d'une validation en boucle fermée avec du matériel réel et une physique simulée.

Un contrôleur de moteur en est un exemple simple. Le contrôleur reçoit des impulsions d'encodeur simulées, un signal de rétroaction de courant et la tension du bus, puis renvoie des commandes de commutation au simulateur. Si le contrôle de couple atteint sa limite lors d'un changement de charge, vous le constaterez sans avoir à faire tourner une machine physique. Cette même configuration permet de tester les situations de sous-tension, les pertes de signal des capteurs et les séquences de démarrage qui seraient difficiles à mettre en œuvre ou risquées sur un banc d'essai complet.

On a recours à la HIL lorsque la logique logicielle ne constitue plus le seul enjeu. La question qui se pose alors est de savoir si le contrôleur se comporte correctement en présence de contraintes de synchronisation, d'E/S, de mise à l'échelle et de scénarios de défaillance. La HIL est donc bien plus qu'une simple définition. Elle devient un point de contrôle entre des modèles logiciels épurés et une validation physique coûteuse.

La HIL comble les lacunes de validation que les tests logiciels ne parviennent pas à combler

Le HIL est l'outil idéal lorsque les tests logiciels ont démontré que la logique de commande fonctionne, mais qu'il faut encore s'assurer que le matériel se comporte correctement au niveau de ses interfaces. Les vérifications purement logicielles ne permettent pas de détecter tous les dépassements de temps, toutes les erreurs de mise à l'échelle des signaux ou tous les problèmes liés au chien de garde. Le HIL comble cette lacune. Il montre ce qui se passe lorsque le code interagit avec l'électronique.

Un contrôleur de freinage peut réussir les tests logiciels et pourtant tomber en panne dès que la synchronisation des impulsions, des signaux de vitesse de roue parasités ou des broches de défaut entrent en jeu. On peut alors observer un passage tardif en mode de secours, une interruption manquée ou un seuil analogique qui se situe juste en dehors de la tolérance. Ces défauts se situent à la frontière entre le code et le matériel. C'est à cette frontière que la simulation HIL prend tout son sens.

Il ne faut pas se lancer dans le HIL si le modèle de l'installation est encore instable ou si la logique de commande de base n'est pas encore au point. Recourir trop tôt au HIL peut faire perdre du temps en laboratoire, car toute défaillance est alors interprétée comme un problème matériel lorsque le modèle n'est pas encore au point. Les équipes obtiennent de meilleurs résultats lorsqu'elles considèrent le HIL comme la première étape d'intégration sérieuse, et non comme un simple test préliminaire.

«Simulation HIL relient le matériel de contrôleur réel à une installation simulée fonctionnant avec un pas de temps fixe. »

Un banc d'essai HIL exécute des modèles d'installation en temps réel

Un banc d'essai HIL fonctionne parce que le modèle de l'installation s'exécute à une fréquence d'horloge fixe et échange des signaux avec le contrôleur au même rythme. Le contrôleur ne peut pas mettre la simulation en pause ni attendre la réponse d'un système d'exploitation de bureau. La synchronisation reste prévisible. C'est ce qui donne tout son intérêt à l'injection de défauts et à l'analyse du comportement en boucle fermée.

Un banc d'essai type comprend un simulateur en temps réel, des circuits de conditionnement de signaux, des alimentations électriques, des liaisons de communication et le contrôleur soumis aux tests. Une configuration peut par exemple fournir au contrôleur d'un onduleur de traction des signaux de courant analogiques, des entrées de défaut numériques et des messages réseau, tandis que le simulateur met à jour la vitesse du moteur toutes les millisecondes, voire plus rapidement. Les équipes connectent souvent ce système via le matériel OPAL-RT lorsqu'elles ont besoin d'E/S déterministes et d'une exécution en boucle fermée reproductible. Le contrôleur se comporte comme si l'installation était physiquement présente, même si celle-ci n'existe que sous la forme d'un modèle mathématique.

L'avantage réside dans la reproductibilité. Vous pouvez reproduire à l'infini le même événement transitoire de démarrage à froid, la même perturbation du bus ou le même décalage de capteur jusqu'à ce que le comportement soit parfaitement compris. Les bancs d'essais physiques offrent rarement un tel niveau de contrôle. Les bancs HIL le permettent, à condition que le pas de temps, la latence des E/S et le partitionnement du modèle soient définis avec rigueur dès le départ.

Le HIL se distingue du test SIL l'intégration

La principale différence entre test SIL SIL) et le test HIL réside dans le fait que le test HIL évalue le matériel de contrôle réel par rapport à une simulation synchronisée, tandis que le test SIL maintient les deux éléments au niveau virtuel. test SIL idéal pour les vérifications algorithmiques. Le test HIL est utilisé lorsque les interfaces matérielles et la synchronisation sont déterminantes. Ces deux approches répondent à des questions de validation différentes.

test SIL est plus rapide à mettre en place, plus facile à automatiser sur les postes de travail et mieux adapté aux tests de régression à grande échelle. Le test HIL est plus lent à câbler et à calibrer, mais il met en évidence des défauts que les workflows purement logiciels ne peuvent pas détecter. Un contrôleur qui semble parfait dans une simulation compilée peut tout de même manquer une échéance une fois que les interruptions réelles, la conversion analogique et le trafic sur le bus apparaissent. C'est pourquoi les équipes passent du test SIL HIL au lieu de s'en tenir à une seule étape pour toujours.

C'est en utilisant chaque étape conformément à sa vocation première que vous en tirerez le meilleur parti. test SIL détecter les erreurs logiques à moindre coût. Les tests HIL devraient permettre de mettre à l'épreuve les interfaces et la synchronisation avant que des assemblages matériels coûteux ne soient mis en place. Les tests sur le système physique devraient confirmer ce que les tests sur banc n'ont pas pu reproduire et éviter de reproduire des erreurs qu'une étape d'intégration plus poussée aurait détectées.

Les équipes du secteur automobile ont recours à la simulation HIL avant de passer aux essais sur véhicule

Les équipes automobiles ont recours à la simulation HIL après la validation de base des logiciels et avant les essais sur véhicule, car cette technique leur permet de tester les calculateurs dans des conditions de défaillance et de charge reproductibles. Ce timing est crucial pour les systèmes de transmission, de freinage, de direction, de recharge et de contrôle de la carrosserie. Le temps de test sur véhicule est limité. La simulation HIL permet de le préserver en détectant précocement les défauts d'intégration.

Les programmes en faveur des véhicules électriques le montrent clairement. Les ventes mondiales de voitures électriques ont dépassé 17 millions en 2024, ce qui signifie qu'un nombre croissant de logiciels de contrôle des onduleurs, de gestion des batteries, de logique de recharge et de répartition des freins passe par les processus de validation. Une équipe peut tester un contrôleur de gestion de batterie face à un déséquilibre simulé des cellules, des défauts de contacteurs et des chutes de tension du pack bien avant qu'un prototype complet de pack ne soit prêt. Cela réduit la liste des surprises qui attendent les essais sur véhicule.

Le même principe s'applique aux domaines du moteur, de la transmission et du châssis. Un contrôleur de traction qui oscille lors de l'arbitrage du couple peut prendre des jours à résoudre sur une piste d'essai. Le même problème apparaît bien plus rapidement sur un banc HIL, grâce à un trafic de bus et à une synchronisation des actionneurs adaptés. Vous gagnez du temps sur les essais physiques, mais le principal avantage réside dans une identification plus précise des défauts.

La précision du modèle détermine dans quelle mesure les résultats HIL sont fiables

La fiabilité des résultats HIL dépend du niveau de précision du modèle requis pour la question que vous vous posez. Un modèle simple permet de valider les transitions d'état du contrôleur et la gestion des défauts. Il ne peut toutefois pas démontrer le comportement détaillé d'une installation qu'il ne représente pas. Un travail HIL de qualité adapte le niveau de détail du modèle au risque à tester.

Un contrôleur de ventilateur de refroidissement n'a pas besoin d'un modèle de moteur électromagnétique si l'objectif se limite à la logique des relais, aux seuils de température et au comportement de secours. Un contrôleur d'onduleur de traction nécessite quant à lui beaucoup plus de détails, car l'ondulation du courant, le retard des capteurs et la dynamique du bus influencent directement la boucle de contrôle. Si le modèle de moteur ne tient pas compte de ces effets, les résultats sur banc d'essai peuvent sembler corrects alors que le système physique continue de présenter des dysfonctionnements. Cet écart ne constitue pas un échec de la simulation HIL. Il s'agit d'un choix de modélisation.

Vous obtiendrez des résultats plus fiables si vous précisez d'emblée ce que le modèle doit démontrer et ce qu'il ne permettra pas de démontrer. Cela permet de définir clairement le champ d'application et rend les résultats des tests plus faciles à justifier. Les équipes perdent confiance dans la validation HIL lorsqu'elles s'attendent à ce qu'un seul banc de test réponde à toutes les questions de validation. Les bons bancs de test répondent à des questions plus ciblées avec davantage de rigueur.

«« Un bon HIL ne se fait pas avec un grand banc. »

La portée de l'analyse HIL doit commencer par les interfaces présentant les conséquences les plus graves

La portée de l'analyse HIL doit commencer par les interfaces dont la défaillance est susceptible d'entraîner les dommages, les coûts ou les retards les plus importants. Il s'agit généralement des sorties de commande, des systèmes de secours de sécurité, des entrées sensibles au temps et des communications assurant la coordination entre plusieurs contrôleurs. En commençant par là, vous obtenez rapidement une couverture utile. Cela évite également que la conception sur banc ne se transforme en une pâle copie du système complet.

Une commande de lunette de visée pratique se présente souvent comme suit :

• Sorties de couple, de freinage, de commutation ou d'arrêt susceptibles de provoquer un comportement dangereux
• Entrées soumises à des contraintes de synchronisation strictes, telles que les codeurs, les capteurs de courant et les impulsions de synchronisation
• Chemins de défaillance devant déclencher des états de secours dans un délai de réponse défini
• Échangeurs réseau qui coordonnent les contrôleurs et peuvent tomber en panne en cas de trafic intense ou de latence
• Scénarios physiques dont la reproduction précoce sur des bancs d'essai matériels s'avère coûteuse ou risquée

Un programme de convertisseur de traction montre pourquoi cette approche fonctionne. La coupure en cas de surintensité, la perte du résolveur et la séquence des contacteurs sont des éléments bien plus importants qu’un simple message d’alerte sur le tableau de bord. Il est toujours possible d’ajouter par la suite des cas présentant moins de risques, mais la première phase doit cibler les interfaces qui déterminent la sécurité et le calendrier des essais. Cette approche permet de garantir la pertinence de la simulation HIL sans qu’elle ne devienne trop tentaculaire.

Une conception d'interface médiocre peut réduire la couverture HIL

Une conception d'interface médiocre compromet la couverture HIL, car même un bon modèle de système ne peut compenser des définitions de signaux inadéquates, des hypothèses de synchronisation imprécises ou des critères d'acceptation trop vagues. Un banc d'essai ne permet de vérifier que ce que les interfaces testent réellement. Si l'échelle, la polarité, la latence ou le comportement en cas de défaillance ne sont pas clairement définis, le résultat du test sera lui aussi incertain. La précision des interfaces est gage de fiabilité des résultats.

Une défaillance courante peut sembler insignifiante au premier abord. Un signal de pression analogique est mappé avec un décalage erroné, ou un message réseau arrive un cycle plus tard que prévu par la logique de commande. Le contrôleur continue de fonctionner, de sorte que le banc d'essai semble en bon état. Puis, un prototype physique présente un comportement instable que le laboratoire n'avait jamais détecté, et le problème remonte à une hypothèse d'interface que personne n'avait clairement définie.

C'est pourquoi un travail HIL de qualité se caractérise par sa simplicité et sa rigueur. Vous définissez les cartes d'E/S, le timing des défaillances, les tolérances et les critères de réussite avant même le lancement de la première campagne. Les équipes qui utilisent OPAL-RT ou toute autre plateforme de simulation comparable plateforme tirent plateforme parti plateforme lorsque ces bases sont solidement établies. Un bon HIL ne repose pas sur un équipement imposant. Il repose sur des interfaces claires, des modèles fiables et des cas de test qui correspondent aux modes de défaillance qui vous préoccupent réellement.