Une seconde solution consiste à prédéfinir un ensemble de comportement type susceptibles d’être rencontré dans le cadre d’une communication entre véhicules. Un ensemble de décisions concernant le matériel, le protocole (version 4/6, TCP, UDP, FTP, HTTP, . . . ), le type de liaison (client/serveur, point à point, . . . ) et les service disponibles (multicast, broadcast, geocast, . . . ) permet de définir différentes stratégies.
Chacune de ces stratégies est ensuite concrétisée sous la forme d’un capteur virtuel au sein de la plateformeSiVICet sous la forme d’un scenario complet dans le simulateurNS3.
Un ensemble d’objet interface est également défini pour les applications tierces.
Cette stratégies est envisageable et peut convenir pour un certain nombre de besoins élémentaires. Cependant plus le nombre d’usage définis augmente, plus le nombre de capteurs virtuels augmente également ainsi que le nombre d’interface. Il peut devenir compliqué de mélanger plusieurs stratégies pour une application complexe nécessitant de tels spécifications.
Cette solution peut permettre à partir des tests réalisés de facilement menée à des modèles exploitables.
Le routeur NS3
La dernière option envisagée enfin, la plus pertinente mais également la plus coûteuse à mettre en oeuvre consiste à utiliser le simulateurNS3comme un routeur.
L’utilisation de routeur au sein des plateformes embarquées dans les véhicules terrestres est une ten-dance confirmée par les différents projets européens menés sur le sujet, cela correspond donc en plus à une réalité matérielle.
L’intérêt de cette solution repose sur le fait que la simulation est alors complètement transparente vis à vis du prototype d’ADAS, celui-ci communique avec l’extérieur par l’intermédiaire d’un routeur comme il le ferait dans un contexte de prototype réel.
Les possibilités offertes par NS3 de pouvoir également communiquer à travers un réseau physique pourraient également aboutir à l’utilisation d’un réseau éthernet de haute capacité (1000 MBps) comme vecteur d’échange entre les différentes plateformes.
Un nombre incalculable de possibilité est alors offerte à la plateforme de simulation, les stratégies de communications évoluant en même temps que la définition du routeur tout en offrant vis à vis du système d’aide à la conduite prototypé un support complètement transparent du média de télécom-munication avec un modèle de matériel entièrement paramétrable.
Cette stratégie implique la définition d’un routeur complet sous NS3, divers travaux ont déjà été mené dans cette optique[105].
Ces solutions n’ont pas été testées dans le cadre de ces travaux, principalement orientée sur la modéli-sation physique des phénomènes de propagation et la modélimodéli-sation des capteur de type radars, néan-moins l’hybridation entre la plateforme virtuelle et la plateforme de communication est démontrée et fonctionnelle et les tests préliminaires effectués ainsi que les solutions évoquées ci-dessus permettent d’envisager une issue favorable à la mise en oeuvre d’un simulateur de télécommunications utilisables dans une plateforme de prototypage temps réel. La mise en oeuvre d’un tel routeur représente toutefois un travail conséquent nécessitant la mise en oeuvre d’une ApplicationNS3 complète (sans compter le ou les scenarios) et requérant une étude plus approfondie du fonctionnement d’un routeur et de sa modélisation au sein d’une plateforme de simulation de télécommunications.
SiVIC master ADAS SRV
NS3 Router
Réseau d’échange entre les modèles
SiVIC ego vehicle 1 ADAS ego 1 eth1 eth0 SiVIC ego vehicle 2 ADAS ego 2 eth0 eth1 SiVIC sensor 1 eth1 eth0 SiVIC sensor 2 eth0 eth1 Tierce Appl 1 eth1 eth0 Tierce Appl 2 eth0 eth1
Réseau d’échange entre les plateformes
Figure V.8 – Plateforme de prototypage de capteur intégrant un router NS3
Une telle solution conduirait à la définition possible d’une plateforme de prototypage comme sur la figureV.8.
Deux réseaux de communications coexistent. Le premier en vert permet l’échange d’information entre les différentes plateforme de simulation et les applications tierces. Le second en bleu, correspondant à un réseau de communications sans fils dans l’environnement virtuel et hébergé sur un autre réseau ethernet permet les communications entre les entités virtuelles présentes dans le scenario.
VI. Conclusion
Résultats
A
u terme de ces travaux, un modèle de capteur électromagnétique générique a pu être défini. Celui-ci dispose tant pour la partie génération et traitement du signal électrique que pour la partie propagation des ondes électromagnétiques dans un environnement virtuel de plusieurs modes de résolution en fonction des capacités disponibles sur le poste de travail (nombre de coeurs dans le microprocesseur central, carte graphique programmable) permettant de maximiser les per-formances des modèles et pour certains cas d’obtenir des résultats en temps réel. Plusieurs modèles complets de radars sont disponibles et un début de solution entièrement fonctionnelle envisagée pour les modèles de télécommunications.* * *
Différents canaux de propagation permettent en fonction des exigences du scenario d’adapter le niveau de bruit de l’environnement et les interactions prises en compte.
Pour des environnements routiers, sans relief ni protection latérale susceptible d’interférer avec le radar, une propagation utilisant comme caractérisation des objets, des SER paramétriques (méthodes des lobes), peut s’avérer amplement suffisante et fournir d’excellentes performances pour les capteurs rencontrés ici.
C’est notamment la modélisation rencontrée dans les simulateurs existant traitant de cette probléma-tique.
Pour des situations particulières où une étude plus détaillée de la réponse du capteur est nécessaire et requière une meilleure caractérisation des effets de l’environnement sur la réponse du capteur, l’utili-sation des autres représentations du monde fondées sur une caractéril’utili-sation plus détaillée des objets, prenant en compte leur géométrie et les propriétés des matériaux, comme le canal de propagation type caméra électromagnétique ou le modèle par lancer de faisceau dans un environnement 3D peut s’avérer nécessaire pour permettre aux systèmes d’aides à la conduite prototypés d’intégrer ces fausses alarmes dans les traitements. Cela est d’autant plus vraie pour le domaine d’étude concerné où la réponse d’un véhicule, est fortement corrélée à sa proximité vis à vis du capteur.
La prise en compte de la réponse volumique de l’objet (surface apparente de la cible vis à vis du capteur) vis à vis de la réponse électrique du capteur, notamment dans le cadre des radars, permet avec un traitement adapté de pouvoir cataloguer l’objet détecté (piéton, véhicule, . . . ) et de renforcer l’information offerte par le capteur.
Ces représentations du phénomène de propagation permettent contrairement à la modélisation ren-contrée jusque maintenant pour des problématiques approchantes de caractériser davantage le bruit de l’environnement et ses effets sur les traitements du signal associés à une technologie.
Ces modèles plus raffinés et ses nouvelles perturbations sur le signal peuvent également être l’occasion d’étudier la définition de nouveaux types de capteur fondés sur les propriétés des ondes électromagné-tiques. Une récente étude montre comment à partir d’un équipement WiFi domestique, il est possible d’obtenir un détecteur de mouvement sophistiqué[13]. Cette fonction reposant principalement sur l’ef-fet doppler et les autres phénomènes caractérisés dans ce modèle, une étude plus approfondie du protocole mis en oeuvre pourrait permettre une mise en oeuvre virtuelle de ce nouveau capteur.
Ils permettent également d’améliorer la pertinence des modèles de capteurs en offrant la possibilité d’étudier ces bruits de manière maîtrisée, dans un environnement entièrement paramétrable.
Cependant, pour parvenir à des résultats exploitables dans des temps raisonnables, il est encore néces-saire de limiter le domaine d’étude. Un modèle utilisant l’ensemble des données de la scène, bien que porté sur une architecture permettant un traitement massivement parallèle (GPGPU), n’est toujours pas en mesure d’offrir les performances requises pour la problématique étudiée. Mais limiter l’étude de ce phénomène sur une zone particulière de la scène et rediscrétiser celle-ci suivant la visibilité du capteur (travail en espace image), permet en revanche d’obtenir une grande partie des phénomènes que l’on souhaitait observer tout en offrant, cette fois-ci, des performances compatibles avec la mise en oeuvre d’une plateforme de simulation pour le prototypage d’ADAS.
La combinaison entre la représentation virtuelle de l’environnement et des objets de la scène fournie par la plateformeSiVICet les modèles de propagations électromagnétiques définis dans ce manuscrit propose une approche de la propagation électromagnétique pour le domaine de l’automobile différente des visions étudiées dans les simulateurs présentés en introduction.
Non seulement, il semble que les performances associées à ce modèle soient meilleures1
que les per-formances des simulateurs existants pour ce domaine d’étude. Mais il fournit également une solution innovante et performante en matière de prise en compte du bruit d’environnement à travers les deux approches utilisant les capacités graphiques du poste de travail, où des résultats peuvent être obtenus en temps réel en fonction des paramètres de la simulation.
Ces modèles offrent une meilleure représentation des entités de la scène en ne recourant pas à la carac-térisation sous forme de SER des objets et en lui préférant une représentation géométrique combinée aux propriétés de la matière qui le compose.
Au final, les capacités offertes par cette solution pourraient également être appréciées par d’autres domaines de recherche, pour la conception ou l’étude de nouveaux capteurs radars notamment, ou d’autre type de capteurs électromagnétiques manipulant des signaux électriques.
Ces résultats sont principalement dû à l’utilisation de la carte graphique comme unité de calcul et à l’utilisation des capacités multi-thread de la plateforme centrale à travers tout le modèle, de la généra-tion du signal électrique, en passant par sa propagagénéra-tion dans l’environnement jusqu’à la reconstrucgénéra-tion du signal reçu.
Sans la contrainte temps réel, et avec un temps de traitement raisonnable (inférieure à la seconde), la ré-solution du signal peut alors dépasser le million de composantes ou le nombre de trajets retours pris en compte avoisinné 10000 pour un signal encore composé de plus de 75000 composantes, correspondant à un signal radarFMCWen dent de scie, caractéristique des modèles de radars automobiles.
La carte graphique ne permet cependant pas tout. Le modèle 3D ainsi définit reposant sur une défi-nition géométrique de la scène et prenant en compte l’ensemble des interactions sur l’ensemble des faces élémentaires composant l’environnement n’est pas en mesure d’offrir une solution satisfaisante à l’heure actuelle.
Sa mise en oeuvre au sein d’une scène complexe amène le drivers de la carte graphique à interrompre le traitement qui dépasse allègrement la seconde. Une sécurité empèche pour l’heure les cartes graphiques d’utiliser leur capacité de programmation au-delà d’une seconde afin d’éviter tout disfonctionnement du système.
Il est toutefois possible ici aussi de décomposer une fois de plus le traitement réalisé, non plus suivant les différentes étapes comme cela a été le cas lors de la mise en oeuvre de ce modèle mais en décou-pant cette fois l’ensemble des faisceaux parcourant la scène en plusieurs sous ensemble, au temps de traitement réduit, et s’exécutant séquentiellement. Cette solution n’a pas encore été testée, les temps de calcul resteront de toute façon très supérieur aux temps requis pour la problématique étudiée. Pour un autre usage cependant, il peut être intéressant de mettre en oeuvre cette solution afin de déterminer les éventuels usages possibles pour un autre domaine que celui étudié ici.
Il est également possible de dégrader son usage en appliquant les traitements non plus sur la géométrie fine de l’objet mais sur la boite englobante de celui-ci.
Même si ce mode de fonctionnement peut amener certains résultats, il reste aujourd’hui à trouver une définition pertinente de cette représentation des objets au regard des phénomènes étudiées.
Pour conclure concernant l’utilisation de la carte graphique. Les travaux menés dans le cadre de cette thèse amène à conseiller l’utilisation de celle-ci pour des problèmes dont la complexité reste suffisam-ment constante quelque soit les conditions de celui-ci, comme dans le cas de la reconstruction d’un signal électrique ou le travail en espace-image.
Les essais réalisés, relatifs à la définition du modèle 3D dont les temps de traitements sont très variables en fonction de la complexité instantanée de la scène mène à une forte instabilité du système, les temps de calculs disponibles sur cette architecture restant limitées à la seconde. La redéfinition des kernels par répartition des traitements au sein de plusieurs sous-kernels exécutés séquentiellement permet en fonction de la problématique de contourner ce problème.
Nombre d’itération Comple xité d’une itér ation barriere minimum ΩGPU GPU Optimum ΩCPU CPU Optimum
Figure VI.1 – Domaine d’application du CPU et du GPU
La figureVI.1présente les domaines d’applications respectifs observés duCPUet duGPUen fonction de la complexité des traitements et du nombre d’itérations à opérer. Le CPU est l’unité de calcul par défaut, elle est donc adaptée pour traiter n’importe quelle problématique. Cependant, entre les deux types d’unité de calculs présentées, l’utilisation optimale de celui-ci concerne le traitement de problèmes complexes en faible nombre, au contraire du GPU qui lui est plus performant pour les traitements simples et en très grands nombres. Il apparaît également que contrairement auCPUqui peut traiter n’importe quelle type de problématique, le domaine d’utilisation duGPU est limité par deux aspects. Contrairement auCPUqui peut exécuter des applications limitées virtuellement en taille par la mémoire vive disponible, les cartes graphiques ne stockent pas les kernels dans la mémoire vidéo mais dans une autre zones de taille beaucoup plus modeste, de l’ordre de quelques dizaines de kilo-octets. Cette limitation est symbolisée par la barrière sur la figureVI.1. Il reste cependant possible, de porter un code conséquent surGPU, en scindant celui-ci en plusieurs sous-kernels comme énoncé plus tôt. La seconde limitation concerne le coût de mise en oeuvre d’une telle solution. Elle ne doit être envisagée que lorsqu’il est certain que le nombre de traitements à réaliser sera très important, comme c’est le cas pour le traitement d’image ou de vidéo, ou des systèmes comme le lancer de rayons ou de faisceaux.
Un dernier point enfin concerne les évolutions futures des plateformes. Si pour le moment, il ne semble pas se profiler une grande évolution au niveau des architectures centrales, la tendance actuelle du mar-ché se portant davantage sur les petits équipements informatiques type tablette ou téléphone portable pour l’amélioration des performances (nombre de coeurs embarqués dans des équipements à faible consommation), une prochaine génération de microprocesseurs à usage domestique composé de 16 ou 32 coeurs pourraient peut-être réinverser la tendance à court terme, en fonction de l’évolution des performances des cartes graphiques. La tendance actuelle tend cependant à privilégier une solution sur carte graphique pour bénéficier des évolutions d’un marché très dynamique depuis son apparition (voir figureIII.19, p.72).
* * *
Concernant les capteurs radars, un ensemble de modèles rencontrés dans le domaine automobile a été intégré.
Un mécanisme de suivi de cibles pour la partie logicielle du capteur est également défini, fournissant un premier modèle utilisable dans le cadre du prototypage de système d’aide à la conduite sur une plateforme de simulation de réalité virtuelle.
Le modèle offre au final une excellente plateforme d’étude des signaux radars, en permettant de confi-gurer à la fois le capteur et ces caractéristiques.
L’étude de ces capteurs aura également été l’occasion de prendre conscience du travail très conséquent restant à réaliser en aval des données brutes issues d’un capteur tel que le radar. Celles-ci sont en effet loin d’être utilisable directement pour une problématique comme l’est le prototypage d’ADAS et à fortiori avec l’ajout de bruit d’environnement.
La mise en oeuvre de ces modèles a nécessité la définition de séquences de traitement pour le signal recu dans le but d’extraire les informations relatives aux cibles. Ces différents traitements appliqués aux signaux (méthodes de lissage, niveau des seuils de détections définis, . . . ) l’ont été de façon arbitraire, afin de garantir le meilleur résultat au vue des expériences réalisées.
Cet aspect du problème est à relever et mérite une explication.
Le modèle présenté ici se contente d’offrir le minimum nécessaire à la production de données et s’ap-puie essentiellement sur des modèles académiques.
Dans le cadre de la mise en oeuvre d’un systèmeADASreposant sur l’utilisation d’un capteur élec-tromagnétique, les caractéristiques virtuelles du modèle doivent correspondre aux caractéristiques du modèle commercial utilisé. Celles-ci incluent notamment le type de modulation, faisant souvent l’ob-jet d’un brevet, ainsi que les traitements associés et la partie logicielle (validation des cibles, . . . ) là aussi du domaine exclusif de la société exploitante. Dans un soucis de réalisme des modèles, il est donc maintenant nécessaire d’étudier le fonctionnement d’un capteur commercial de manière à re-produire son comportement dans la plateforme de simulation, les résultats obtenus sur ces modèles académiques permettant de valider l’approche mise en oeuvre ici. Aussi seul un partenariat avec un équipementier commercialisant ce type de capteur peut aboutir à une solution réellement pertinente quant à l’utilisation de ces modèles dans le cadre du prototypage d’un système ADAS. Il n’en reste pas moins que les modèles définis dans le cadre de ces travaux peuvent parfaitement s’appliquer à l’utilisation de capteurs radars génériques.
En terme de performances, celles-ci sont parfaitement compatibles avec un fonctionnement temps réel de la plateforme.
A noter toutefois, qu’en fonction des modèles définis, de la granulométrie choisie, et du nombre de capteurs simulés dans un même scenario, il peut être nécessaire de répartir la plateforme virtuelle au sein d’un ensemble de machines, afin de maintenir le niveau de performance; ce qui implique l’utilisation du BUS de partage.
Il est également parfois impossible de maintenir un fonctionnement temps réel de la plateforme. Les mécanismes internes àSiVICet à la plateforme de prototypage d’ADASReal Time, Multisensor, Ad-vanced Prototyping Software (RtMapsTM) permettent alors d’exécuter l’ensemble des traitements en temps différé.
Concernant l’intégration d’un capteur de télécommunications, les résultats sont plus partagés.
D’un côté, il a été démontré que la solution est envisageable. L’intégration des résultats du canal de propagation définie pour la plateforme de simulation de capteurSiVICsont bien pris en compte par le Channel du simulateur NS3, un trafic ethernet est également correctement généré par rapport à ces résultats. Lorsqu’une cible est à portée et que les conditions de réception sont favorables, les messages sont correctement émis, lorsque la situation est dégradée et la réception perturbée par l’environnement (masquage et atténuation), aucun trafic n’est émis. Les différents tests réalisés dans la plateformeNS3
ainsi que la littérature existante relative aux utilisations de ce simulateur confirme la possibilité de pou-voir utiliser le simulateurNS3comme un routeur et de pouvoir définir la plateforme de prototypage comme illustrée en figureV.8. Cette dernière étape n’a cependant pas été réalisée lors de ces travaux, laissant la problématique toujours ouverte.
La concrétisation de cette approche permettrait très certainement d’obtenir l’un des meilleurs modèles de systèmes de télécommunication pouvant être mis en oeuvre pour le prototypage de systèmes d’aide à la conduite dans le cadre de la simulation.
Concernant la solution de transfert de données pour la répartition des traitements.
Celle-ci fournit une solution très simple et très performante pour la répartition des traitements au sein d’un cluster de machine.
Elle s’intègre naturellement dans la définition des objets de la plateforme virtuelle.