Peux-tu te présenter en quelques mots ?
Je m’appelle Gregory Rousseau, je suis Product Owner depuis 3 ans chez AVSimulation. Je m’occupe de définir la Roadmap, de suivre l’avancement des développements, tout en anticipant ou écoutant les besoins présents ou futurs des clients. D’autre part, je fais le suivi de certains projets comme par exemple SERKET, destiné à RUAG Défense France qui développe un simulateur pour la DGA et dans lequel nous allons intégrer des interfaces logicielles développées par notre équipe.
Que veut dire l’acronyme HIL?
L’acronyme HiL signifie Hardware in the Loop. Un dispositif HIL – on parle en général de banc HIL – consiste à faire fonctionner un élément physique (capteur ou actionneur) dans une boucle de simulation.
Aujourd’hui, tous les véhicules contiennent des calculateurs qui sont des systèmes définis par des entrées et des sorties, et qui intègrent des lois de commande chargées de contrôler des systèmes (tels que les ADAS, la climatisation, les systèmes d’éclairages, etc.).
L’exemple concret est de pouvoir tester un calculateur sur table, avant de le mettre en place sur un véhicule. Pour cela, il est nécessaire d’alimenter les entrées du calculateur pour lui donner des mesures virtuelles (issues d’une boucle de simulation) et ainsi, voir les évolutions de ses grandeurs en sortie. Autrement dit, le calculateur va réceptionner les informations de capteurs émulés et va agir sur des actionneurs, ou bien il donnera des consignes destinées à d’autres calculateurs.
Un exemple simple réside dans le cas d’un levier de vitesse d’une boite pilotée, actionné par une personne : un capteur va récupérer la position du levier de vitesse, et transmettre les informations au calculateur (demande de changement de rapport du conducteur). En retour, et si les conditions de validité sont vérifiées, ce dernier va actionner un système de changement de rapport. Pour un tel système, le banc HIL peut être utilisé pour tester et valider au choix le capteur du changement de rapport, et / ou l’actionneur de boite.
Les exemples liés aux ADAS sont souvent plus complexes, faisant intervenir différents capteurs (réels ou simulés) et un calculateur qui procédera éventuellement à de la fusion de données multi-capteurs pour valider le choix d’une consigne.
Peux–tu rapidement revenir sur les MIL, SIL, DIL.
MiL : Model in the Loop. C’est un modèle de test qui n’est pas compilé. Il ne répond pas encore à toutes les contraintes d’utilisation et d’intégration d’un logiciel embarqué (fréquence de fonctionnement définie, couches bas niveau, etc.). En d’autres termes, c’est un peu un produit brut qui permet de mettre au point la loi de commande, et de faire des premiers tests : seul l’algorithme du système embarqué est évalué.
SiL : Software in the Loop. Pour ce type de test, ce sont des lois de commandes compilées qui sont utilisées, donc homogènes à ce qu’il y aura dans le calculateur. Ces lois de commande constituent le logiciel embarqué. Le reste de l’environnement, y compris la partie matérielle du logiciel embarqué, reste simulé.
DiL : Driver in the Loop. Ici, c’est un test utilisé lorsqu’un simulateur conduit par un conducteur se trouve dans la boucle de simulation. A partir du moment où un une personne physique va contrôler quelque chose lors de la simulation, nous pouvons parler de DiL.
L’objectif de ce type de banc est d’évaluer les réactions du conducteur face à un évènement qui survient (affichage d’une information, émission sonore d’un signal de prévention ou d’avertissement, etc.)
Existe-il une alternative aux bancs de test HiL ? Comment faisaient les ingénieurs quand les bancs HiL n’existaient pas ?
Les bancs HiL permettent de tester des ECU (Electronic Control Unit) intégrant des lois de commande, ou des capteurs. Cela est entièrement lié à l’apparition de l’électronique dans le domaine de l’automobile : auparavant, des tests mécaniques étaient suffisants. L’industrie automobile était beaucoup moins mûre qu’aujourd’hui.
Les constructeurs automobiles concevaient donc des prototypes de véhicules et les testaient sur piste, à travers un nombre d’essais limité ne serait-ce que par le faible nombre de prototypes.
Lorsque l’électronique a commencé à faire son apparition, des bancs de test ou des tests en laboratoire étaient menés, constituant l’alternative aux bancs HiL. Les bancs de tests permettent d’isoler une partie du véhicule pour la tester de façon unitaire en alimentant le calculateur avec des données virtuelles.
Quels types de problèmes les bancs de tests HIL permettent-ils de résoudre ?
Les bancs de tests HiL permettent de résoudre différents problèmes.
Premièrement, ceux liés au coût : les essais sur piste sont particulièrement onéreux. Les bancs HIL constituent un certain investissement initial, mais ils sont ensuite peu couteux à maintenir, et peuvent s’interfacer avec différent produits à tester ou à valider. Ils sont de ce fait très rapidement rentables au regards des économies qu’ils permettent de faire.
Par ailleurs, ils apportent un gain de temps non négligeable. Par exemple, si l’on veut tester des lois de commande sur un capteur qui n’est pas encore développé ou en cours de développement. Ce dernier qui n’est pas encore sorti pourra être tester en avance de phase à l’aide de la simulation.
Enfin, les problèmes de répétabilité sont évités. En effet, il est possible de répéter un même scénario infiniment, sans subir les variations (humaines ou matérielles) inhérentes à un essai réel.
A quel endroit du cycle en V retrouve-t-on les bancs HiL ?
Dans le cycle en V, il y a tout d’abord, en phase de conception, le MiL. Ce dernier consiste à avoir des modèles qui ne sont pas encore bien structurés ni capables d’être compilés. C’est davantage la qualité des algorithmes qu’on teste à ce stade. Petit à petit, les modèles vont être améliorés, puis industrialisés pour être compilés afin d’être utilisés en SiL, tels qu’ils sont lorsqu’ils sont intégrés dans un ECU.
Lorsque l’on remonte le cycle en V pour la phase de tests et de validations, le HIL intervient, pour connecter un système réel à une boucle de simulation, afin de le tester.
Enfin, le ViL qui sera utilisé pour tester en temps-réel le véhicule et ses capteurs, en partie alimentés par un environnement simulé.
Quelles sont les caractéristiques qui permettent d’utiliser SCANeR dans un banc de test HIL ?
Nous avons le module RTGateway qui permet de connecter SCANeR à une cible temps réel et de récupérer toutes les informations (capteurs par exemple) qui transitent sur le réseau SCANeR.
D’autre part, chez AVSimulation nous avons développé un modèle de dynamique véhicule, nommé CALLAS RT, qui est aussi capable de fonctionner sur une cible temps réel, donc sur un banc HiL.
Aujourd’hui, ce sont les produits qui sont intégrés dans le pack Real Time Targets, qui permettent d’utiliser SCANeR connecté à une cible temps réel, sur laquelle peut s’exécuter le modèle de dynamique véhicule CALLAS RT, afin de l’interfacer avec différents systèmes (capteurs ou actionneurs). Cet ensemble constitue le banc HIL, avec SCANeR en tant que boucle de simulation.
Peux-tu nous donner des exemples de capteurs que l’on intègre dans des bancs HiL et des exemples de bancs que vous avez réalisés ou sur lesquels vous êtes en train de travailler ?
Un exemple de banc HIL capteur peut se concevoir avec une caméra.
Le principe est de projeter le visuel SCANeR sur un écran, qui est ensuite filmé avec une caméra. Cette dernière est installée dans un caisson (sorte de boîte d’environ 1 à 2 m3) et réglée de manière à filmer l’écran. L’idée est donc d’émuler une scène réelle, via le visuel de SCANeR, et de filmer celle-ci avec la caméra comme si elle était installée sur un parebrise de voiture.
Ces caméras sont capables de faire de la détection de cibles (présence d’un véhicule, vitesse, distance inter-véhicule) afin d’être utilisé pour des fonctions comme de l’ACC (adaptative Cruise Contrôle).
Connectée à un banc temps-réel lui-même connecté à SCANeR, la caméra transmet les cibles détectées et leur vitesse : ce banc HIL devient un banc de test et de validation de fonctions ADAS, grâce à la simulation.
Une autre exploitation d’un banc HIL consiste à l’utiliser avec un radar. De la même façon qu’on émule une image du monde réel via un écran, l’idée est d’émuler les ondes d’un radar qui sont réfléchies par une scène réelle : cela se fait à l’aide d’un banc radar. Alimenté par un modèle capteur radar tel que le modèle radar L2 de SCANeR, le banc radar peut envoyer des ondes qui sont ensuite reçues par un vrai capteur radar. A l’aide d’une couche de traitement des échos doppler, le radar fournit les cibles qu’il détecte à un système ADAS. Dans un banc HIL complètement bouclé, le système ADAS est connecté à un véhicule SCANeR, et peut être testé pour valider son fonctionnement sur des scénarios menant à des situations accidentogènes.
Dans l’un de nos projets, nous avons travaillé avec notre partenaire Conrad pour connecter le banc de test caméra avec SCANeR. Sur ce dernier, la connexion HiL est mise en œuvre avec une caméra Mobileye connectée à une cible temps réel qui fait l’acquisition du flux vidéo et des différentes informations qui sont envoyées par la caméra.
Plus récemment avec Keysight Technologies et le support d’OKTAL SE, nous travaillons sur un projet pour démontrer l’utilisation d’un radar L2 dans le cas d’une application banc radar.
Un mot pour la fin ?
Le ViL et le HiL sont des éléments clés dans notre Roadmap SCANeR, c’est pourquoi nous nous employons depuis plusieurs années à être compatibles à un certain nombre de fournisseurs de cibles temps réel comme par exemple National Instrument, dSpace, et bien d’autres.
Le fonctionnement de notre modèle véhicule CALLAS tel que nous l’utilisons en simulation massive, sera le même que lorsque nous l’utilisons sur une cible temps réel : on s’emploie à converger au mieux vers la Digital Continuity.