Application des tests « hardware-in-the-loop » aux systèmes de commande automobiles

Principaux enseignements

• La méthode « Hardware-in-the-Loop » est particulièrement efficace lorsque la synchronisation du contrôleur, les interfaces et la gestion des défaillances constituent les principales inconnues.
• La qualité du modèle de l'installation doit correspondre à la question de contrôle, avec suffisamment de détails pour reproduire la dynamique qui détermine la réponse du régulateur.
• Les essais au banc et sur véhicule doivent se confirmer et se recouper, tandis que les premiers modèles d'usine doivent d'abord éliminer les incertitudes fondamentales.

Les équipes chargées des systèmes de commande automobile obtiennent des réponses plus précises et plus rapides lorsqu'elles ont recours à la méthode « hardware-in-the-loop » après qu'un modèle d'installation a permis de résoudre le problème de commande de base.

Les essais « hardware-in-the-loop » dans le secteur automobile placent le contrôleur de production en boucle fermée avec une installation simulée, ce qui permet de vérifier le comportement du contrôleur avant même que le véhicule complet ou le banc d’essai ne soit prêt. C’est essentiel, car les logiciels de contrôle modernes ont une incidence directe sur la sécurité. Le contrôle électronique de stabilité réduit le risque d’accident mortel impliquant un seul véhicule de 49 % pour les voitures particulières et de 59 % pour les véhicules utilitaires sport. Un essai « hardware-in-the-loop » est utile, mais il donne les meilleurs résultats une fois que le modèle de système a déjà permis de répondre aux questions fondamentales concernant la loi de commande, les limites et la réponse attendue du système.

Les équipes ont souvent tendance à recourir trop tôt à un banc d'essai, car le matériel leur semble plus concret et plus fiable. Cet instinct ralentit le programme alors que la question en suspens porte encore sur le comportement de l'installation plutôt que sur l'interaction avec le matériel. Un bon modèle d'installation permet de procéder à des réglages, de simuler des défaillances et de répéter des scénarios bien plus tôt, avec moins de configuration et une causalité plus claire. L'approche « Hardware-in-the-loop » ne devrait être mise en œuvre qu'au moment où les interfaces du contrôleur, la synchronisation et la gestion des défaillances deviennent les principaux risques.

Les essais « hardware-in-the-loop » dans le secteur automobile permettent de boucler la boucle de contrôle

Les tests « hardware-in-the-loop » dans le secteur automobile consistent à faire fonctionner le contrôleur réel sur un système simulé (véhicule ou sous-système) afin de vérifier les sorties de contrôle, le traitement des entrées et la synchronisation dans des conditions reproductibles. Cette méthode permet de boucler la boucle avec le matériel de série, ce qui la rend plus fiable que la simulation sur ordinateur pour les questions d'intégration.

Un variateur de fréquence pour moteur en est un bon exemple. Le variateur lit les signaux de vitesse, de courant et de température provenant du simulateur, puis renvoie des requêtes d’impulsions et de couple vers l’installation simulée. Cette configuration vous permet de voir si le variateur entre en saturation trop tôt, s’il ne respecte pas une limite ou s’il gère mal un défaut de capteur. Vous n’avez plus à deviner comment le code exécuté sur un ordinateur portable se comportera une fois qu’il sera confronté à de véritables canaux d’entrée/sortie.

Cette différence est importante, car de nombreux problèmes de contrôle ne proviennent pas uniquement de l'algorithme de contrôle. Ils sont liés à la mise à l'échelle, à la quantification, à la latence et à la signalisation des défauts entre les interfaces. Une configuration automobile de type « hardware-in-the-loop » (HIL) offre une reproductibilité sans avoir à attendre la construction d'un véhicule, tout en garantissant la fiabilité du matériel du contrôleur. Elle ne remplacera pas la modélisation de l'installation, mais elle mettra en évidence les problèmes d'intégration que la simulation logicielle pure masque.

Utilisez la méthode « hardware-in-the-loop » lorsque la synchronisation de l'interface est cruciale

La méthode « hardware-in-the-loop » est le choix qui s'impose lorsque l'incertitude principale réside dans la synchronisation du contrôleur, les interfaces de signaux, la planification des tâches ou les échanges réseau. Une fois le comportement de l'installation bien compris, il convient de passer à la méthode « hardware-in-the-loop » afin de vérifier si le contrôleur continue de fonctionner correctement dans des conditions d'exécution réalistes.

Prenons l'exemple d'un contrôleur d'essieu électrique qui génère le couple adéquat lors d'une simulation sur ordinateur, mais qui ne parvient pas à répondre à une demande de réduction de couple lorsque le trafic sur le bus atteint son pic. La loi de commande est correcte, mais l'ordonnanceur et la synchronisation des communications créent un chemin de défaillance. Un test « hardware-in-the-loop » mettra ce problème en évidence, car le contrôleur réel exécute ses tâches, convertit les entrées et publie les sorties dans les mêmes conditions de charge que celles prévues pour la production en série.

C'est là que le travail sur banc d'essai prend tout son sens. Si vous vous demandez encore comment le patinage des pneus, l'inductance du moteur ou la température du liquide de refroidissement influencent la consigne de régulation, continuez à vous appuyer sur le modèle de l'installation. Dès que la question devient « le régulateur atteint-il toujours la consigne avec ce temps de réponse et cette charge d'interface ? », la méthode « hardware-in-the-loop » devient la meilleure option.

La fidélité du modèle de plante détermine la valeur de chaque test

La fidélité du modèle de l'installation détermine ce qu'un test « hardware-in-the-loop » peut réellement démontrer. Il faut disposer d'un niveau de détail suffisant pour reproduire la dynamique de l'installation qui intéresse le contrôleur, mais il n'est pas nécessaire de disposer d'un modèle complet du véhicule pour chaque cas de test.

Prenons l'exemple d'un contrôleur de refroidissement de batterie. Si l'objectif est de vérifier la logique de gestion de l'état des ventilateurs et le traitement des seuils de température, un modèle thermique concentré suffit. Si l'objectif est de valider la réduction du couple à mesure que la température des cellules augmente lors de cycles de conduite intensifs, le modèle doit prendre en compte le décalage thermique, l'emplacement des capteurs et les limites des actionneurs. Une faible fidélité là où elle n'est pas nécessaire donne des graphiques propres mais des résultats peu probants.

Vous devez lier directement la fidélité à la question de contrôle et veiller à ce que la portée du modèle reste en adéquation avec ce besoin. Un niveau de détail trop élevé dans un sous-système non pertinent entraîne un gaspillage d’efforts et ralentit l’exécution des tests. L’absence de dynamique à proximité de la boucle de contrôle engendre une fausse confiance. Un travail de qualité dans le domaine de l’automobile avec la méthode « Hardware-in-the-Loop » commence par un modèle sélectif, transparent et adapté au comportement spécifique que vous devez tester.

« Dès lors que la question devient : “Le contrôleur parvient-il toujours à atteindre la cible avec ce temps de réponse et cette charge d'interface ?”, la simulation “hardware-in-the-loop” s’impose comme la meilleure solution. »

Élaborez le modèle de l'usine en vous appuyant sur des questions de contrôle quantifiables

La préparation d'un modèle de système doit partir des critères de réussite et d'échec, des signaux identifiés et des réponses attendues du régulateur. Vous tirerez davantage profit d'un modèle simple, avec des sorties claires et mesurables, que d'un modèle complexe incapable d'expliquer pourquoi un test a réussi ou échoué.

Une équipe chargée de la conception d'un contrôleur de freinage peut définir l'erreur de vitesse de roue, la valeur cible de glissement, la vitesse de montée en pression et la durée de verrouillage des défauts avant de construire le modèle. Ces paramètres permettent d'identifier les états, les temps de retard et les non-linéarités propres à l'installation. Les équipes qui utilisent SPS SOFTWARE à cette étape tirent généralement parti des équations modifiables et des paramètres visibles, car le modèle de test doit permettre le raisonnement et produire des traces interprétables.

Il est également nécessaire de s'accorder sur les temps d'échantillonnage, la mise à l'échelle des signaux et les points d'insertion des défauts avant de connecter le contrôleur. Cette préparation permet d'éviter de perdre du temps en laboratoire par la suite. Lorsque vous êtes en mesure de formuler la question de contrôle en une seule phrase et de nommer les signaux qui y répondent, votre modèle d'installation est prêt pour les essais « hardware-in-the-loop ».

Un test « hardware-in-the-loop » relie les contrôleurs à des modèles

Un test « hardware-in-the-loop » relie le contrôleur physique, ses interfaces d'entrée/sortie, ses canaux de communication et une installation simulée reproduisant le fonctionnement du sous-système ou la dynamique du véhicule. Il en résulte une boucle fermée qui permet d'observer le comportement du contrôleur dans des conditions de fonctionnement et de défaillance reproductibles.

Une configuration type pour un contrôleur de transmission comprend le mappage des E/S analogiques et numériques, les messages réseau, l’émulation des actionneurs, les points d’injection de défauts et la journalisation synchronisée. Vous injectez une impulsion de capteur manquante, une chute de tension ou une valeur d’étalonnage décalée, puis vous observez la réponse du contrôleur sans risquer d’endommager le matériel. C’est cette répétabilité qui explique concrètement pourquoi les équipes recourent à la méthode « hardware-in-the-loop » plutôt que de passer directement au temps réel du véhicule.

La liste de contrôle ci-dessous permet de classer les questions courantes relatives aux commandes automobiles dans la bonne étape du premier test.

Les scénarios de test doivent tenir compte des risques liés aux contrôles et de l'exposition aux défaillances

Les scénarios de test doivent être sélectionnés en fonction du risque lié au contrôle, de l’exposition aux défaillances et des conséquences en matière de sécurité. La facilité d’automatisation doit venir en second lieu. Les meilleurs plans de simulation « hardware-in-the-loop » mettent l’accent sur les états dans lesquels le contrôleur doit réagir correctement en présence de retard, de bruit, de saturation et de dégradation des capteurs.

Le freinage d'urgence automatique en est un exemple flagrant. Les systèmes de prévention des collisions frontales, dotés d'un freinage automatique en milieu urbain et interurbain , réduisent d'environ 50 % les collisions entre véhicules de l'avant et de l'arrière . Ce type de fonction de contrôle doit faire l'objet d'une couverture complète des scénarios liés à la perte de signal des capteurs, aux fausses cibles, à la réduction du frottement et au retard des actionneurs, car tout cas limite non pris en compte a un coût direct en matière de sécurité.

La sélection basée sur les risques améliore également l’efficacité. Il n’est pas nécessaire de disposer de centaines de cas simples et similaires si cinq cas complexes suffisent déjà à mettre en évidence les points faibles du contrôleur. Une matrice de défauts liée aux objectifs de sécurité, aux états de fonctionnement et à la logique de reprise vous fournira des preuves plus solides qu’une longue liste de tests établie par simple commodité. Un bon test « hardware-in-the-loop » se caractérise par sa sélectivité et sa rigueur.

Les bancs d'essai doivent être intégrés aux modèles une fois que les questions de contrôle ont trouvé une réponse.

Les bancs d'essai s'avèrent particulièrement utiles une fois que les modèles de l'installation ont permis de réduire les incertitudes concernant la stratégie de contrôle et que le « hardware-in-the-loop » a vérifié le comportement en exécution. Si vous intégrez le matériel au banc d'essai trop tôt, vous perdrez du temps à monter des dispositifs de fixation pour répondre à des questions auxquelles un modèle aurait apporté une réponse plus rapidement.

Ces signes indiquent généralement qu'il vaut mieux conserver le modèle de culture actuel encore un peu :

• La réaction attendue des plantes fait encore l'objet de débats.
• Vos signaux de réussite et d'échec n'ont pas été définis.
• La loi de commande doit encore faire l'objet d'un réglage de base du gain ou des limites.
• Les cas de défaillance ne sont pas encore associés à des actions précises du contrôleur.
• La mise en place du banc de mesure demande plus d'efforts que la question posée.

Un contrôleur de boucle de refroidissement met en évidence le coût lié au non-respect de cet ordre. Si la dynamique de la pompe et le décalage des capteurs restent incertains, un banc d’essai produira des résultats ambigus qui feront l’objet de débats pendant des jours. Une fois que le modèle de l’installation aura pris en compte ces effets, le banc d’essai deviendra utile pour vérifier la plomberie, le conditionnement et les tolérances matérielles. Vous passerez moins de temps à rechercher les causes des symptômes et davantage à confirmer les résultats attendus.

« Des modèles de système clairs et fondés sur la physique vous aident à poser plus tôt des questions plus précises ; ainsi, la simulation « hardware-in-the-loop » est utilisée là où elle apporte le plus de valeur ajoutée, et le temps passé sur le véhicule est consacré à la corrélation plutôt qu’au débogage de base des commandes. »

Les essais « Hardware-in-the-Loop » nécessitent encore une corrélation avec le véhicule

Les essais « Hardware-in-the-loop » ont leurs limites, car chaque modèle comporte des omissions, et chaque contrôleur est confronté à du bruit, à des tolérances et à des effets de couplage qu’il est difficile de représenter intégralement. Il reste nécessaire de procéder à une corrélation entre le banc d’essai et le véhicule afin de confirmer que l’installation simulée reflète le comportement mesuré avec une précision suffisante pour étayer l’allégation visée.

Les variations de pression des pneus, la souplesse mécanique, le réchauffement thermique, le bruit de câblage et la dispersion des capteurs de production peuvent tous fausser les résultats, même après une campagne « hardware-in-the-loop » qui semblait concluante. Un contrôleur d’assistance à la direction peut réussir tous les tests en laboratoire, puis présenter une légère oscillation sur une chaussée irrégulière, car le frottement de la crémaillère et le couplage avec les sollicitations de la route avaient été simplifiés dans le simulateur. Cela ne signifie pas que l’étape « hardware-in-the-loop » a échoué. Cela signifie simplement que cette étape a répondu aux questions pour lesquelles elle avait été conçue.

Les meilleures équipes du secteur automobile considèrent les modèles, les systèmes « hardware-in-the-loop », les bancs d'essai et les véhicules comme une succession d'étapes permettant de réduire progressivement l'incertitude. C'est précisément dans cette approche que SPS SOFTWARE trouve naturellement sa place. Des modèles de système clairs et fondés sur la physique vous aident à poser plus tôt des questions plus précises, ce qui permet d'utiliser les systèmes « hardware-in-the-loop » là où ils apportent le plus de valeur ajoutée et de consacrer le temps passé sur le véhicule à la corrélation plutôt qu'au débogage de base des commandes.