Essais virtuels pour des tests continus tout au long du processus de développement des ADAS/AD

La grande com­plex­ité des fonc­tions de con­duite automa­tisée et assistée (ADAS/AD) entraîne une aug­men­ta­tion spec­tac­u­laire du nom­bre d’essais de con­duite req­uis, ce qui rend la vir­tu­al­i­sa­tion des essais de con­duite indis­pens­able. Par rap­port aux essais de con­duite réels, les sim­u­la­tions présen­tent une meilleure repro­ductibil­ité, elles sont plus faciles à automa­tis­er et peu­vent être réal­isées en toute sécu­rité. Les erreurs peu­vent ain­si être iden­ti­fiées au cours des phas­es de développe­ment antérieures et peu­vent donc être élim­inées à moin­dre coût. Un envi­ron­nement d’essai ouvert et effi­cace est essen­tiel pour le déploiement réus­si des sim­u­la­tions tout au long du proces­sus de développement.

Utilisation cohérente des simulations : de la conception des fonctions pour ADAS/AD jusqu’au matériel réel de l’unité de contrôle 

L’approche adop­tée pour tester une fonc­tion ADAS/AD est équiv­a­lente à celle adop­tée pour les autres fonc­tions de con­trôle. Dans les deux cas, le « sys­tème testé » doit être séparé et inté­gré dans une sim­u­la­tion plau­si­ble du sys­tème restant. Dans un pre­mier temps, la fonc­tion peut être dévelop­pée et testée indépen­dam­ment du matériel cible. En fonc­tion de l’état de développe­ment dont on parle : 

• Mod­el-in-the-Loop (MiL) pour la con­cep­tion de fonctions ; 
• Soft­ware-in-the-Loop (SiL) pour tester le logi­ciel d’un cal­cu­la­teur (ECU) sans matériel réel ;
• Hard­ware-in-the-Loop (HiL), pour l’exécution de la fonc­tion en tant que logi­ciel embar­qué sur un calculateur.

Avant même de tester la fonc­tion, la sim­u­la­tion apporte un sou­tien lors de la con­cep­tion et de la spé­ci­fi­ca­tion du sys­tème et égale­ment lors des analy­ses des modes de défail­lance et de leurs effets (Fail­ure Mode and Effects Analy­ses : FMEA). Les out­ils de sim­u­la­tion CANoe et DYNA4 de Vec­tor assurent un déploiement cohérent de la sim­u­la­tion tout au long du proces­sus de développe­ment. Ceci est égale­ment vrai pour les tests con­ti­nus pen­dant la phase de mise en œuvre. La fig­ure 1 illus­tre cela au moyen du mod­èle V. 

Dans le cas des appli­ca­tions HiL, la sim­u­la­tion four­nit tous les sig­naux d’entrée et de sor­tie numériques et analogiques ain­si que l’ensemble de la com­mu­ni­ca­tion sur dif­férents types de réseaux. Générale­ment, les trois phas­es sont menées pen­dant le proces­sus de développe­ment, il est donc évi­dent de réu­tilis­er autant d’artefacts de sim­u­la­tion pré­parés que pos­si­ble tout au long du proces­sus. Cela s’applique en par­ti­c­uli­er aux tests qui ont été générés dès le début du développe­ment. Idéale­ment, les mêmes étapes de test peu­vent être util­isées de manière cohérente, en com­mençant par la phase MiL et en con­tin­u­ant jusqu’aux tests HiL.

De la stimulation à la simulation en boucle fermée : des modèles physiques pour des essais virtuels

Des fonc­tions sim­ples peu­vent être suff­isam­ment testées par sim­ple stim­u­la­tion avec des don­nées syn­thé­tiques ou enreg­istrées. Cepen­dant, si la fonc­tion testée con­trôle le com­porte­ment de con­duite du véhicule, les effets de ces entrées de con­trôle doivent être ren­voyés pour obtenir un com­porte­ment en boucle fer­mée. Cela néces­site des mod­èles qui reflè­tent le monde physique avec une pré­ci­sion suff­isante. Ce que sig­ni­fie exacte­ment une pré­ci­sion suff­isante dépend forte­ment de la fonc­tion testée, comme le mon­tre cet exem­ple : pour tester une fonc­tion de sta­tion­nement automa­tisé, il est impor­tant d’obtenir une réflex­ion pré­cise de la dynamique du véhicule, y com­pris la pres­sion exacte des pneus, mal­gré les faibles vitesses. 

En revanche, lors du test d’une fonc­tion ACC con­cer­nant son inter­pré­ta­tion cor­recte des don­nées de cap­teurs fusion­nés, un mod­èle sim­pli­fié de la dynamique du véhicule qui reflète le com­porte­ment car­ac­téris­tique en roulis et en tan­gage peut suf­fire. Cela s’applique de la même manière aux mod­èles de cap­teurs : si le sys­tème ACC attend une liste d’objets comme entrée du cap­teur d’environnement, les mod­èles de cap­teurs basés sur les objets sont générale­ment suff­isants. Si, toute­fois, la fusion de cap­teurs précé­dente doit être testée égale­ment, moins de don­nées de cap­teurs traitées sont néces­saires. Ces détec­tions peu­vent être cal­culées par des mod­èles de cap­teurs plus détail­lés. Les mod­èles util­isés doivent donc être mod­u­la­bles en ce qui con­cerne leur fia­bil­ité en fonc­tion du cas d’utilisation spé­ci­fique. Cepen­dant, l’augmentation de la com­plex­ité des mod­èles entraîne une aug­men­ta­tion du nom­bre de paramètres et il con­vient de pré­cis­er que la per­for­mance du mod­èle ne peut être qu’aussi bonne que le paramé­trage cor­re­spon­dant. En par­ti­c­uli­er lors de l’essai des fonc­tions ADAS/AD, l’ensemble des paramètres devi­en­nent de plus en plus impor­tants car non seule­ment le véhicule testé, mais aus­si les dif­férentes con­di­tions d’éclairage, les con­di­tions cli­ma­tiques, l’état du revête­ment routi­er et bien sûr les dif­férents acteurs du traf­ic doivent être représen­tés dans des scé­nar­ios com­plex­es. La fig­ure 2 mon­tre un exem­ple de ce type de scé­nario pour un essai de con­duite virtuelle. La ges­tion struc­turée des ensem­bles de paramètres et des vari­antes du mod­èle est donc tout aus­si impor­tante que le mod­èle lui-même.

Des tests efficaces de MiL à HiL avec CANoe et DYNA4. 

Il existe des out­ils dédiés à l’exécution des tests de MiL à HiL, ain­si qu’à la sim­u­la­tion physique des véhicules et de l’environnement. De plus en plus sou­vent, les ques­tions respec­tives doivent trou­ver une réponse simul­tanée et tout au long du proces­sus de développe­ment. C’est pourquoi les out­ils spé­ci­fiques de chaque domaine sont cou­plés. CANoe, par exem­ple, offre des fonc­tion­nal­ités com­plètes pour l’intégration du logi­ciel de cal­cu­la­teur dans toutes les phas­es de développe­ment. DYNA4 four­nit des mod­èles physiques du véhicule et de l’environnement, mais per­met égale­ment la créa­tion et la ges­tion de mod­èles, de scé­nar­ios et de leurs paramètres. 

Pour l’évaluation des résul­tats de la sim­u­la­tion, un large éven­tail d’options d’analyse des sig­naux et une visu­al­i­sa­tion 3D sont inclus. Une fois que les mod­èles et les scé­nar­ios sont pré­parés dans DYNA4, ils peu­vent être exé­cutés directe­ment dans CANoe. Cela per­met aux util­isa­teurs expéri­men­tés de CANoe de con­serv­er leurs proces­sus habituels et garan­tit égale­ment une entrée facile dans les sim­u­la­tions en boucle fermée. 

Le cou­plage effi­cace des out­ils haute­ment spé­cial­isés de CANoe et de DYNA4 per­met d’obtenir une com­bi­nai­son idéale pour le test des fonc­tions ADAS/AD : avec des options com­plètes pour les tests de sys­tèmes en boucle fer­mée et des proces­sus cohérents dès les pre­mières étapes de développe­ment jusqu’au matériel réel. 

---

Articles similaires :

Auto­mo­bile con­nec­tée : les défis de la coopéra­tion compétitive GESTAMP, parte­naire stratégique des con­struc­teurs automobiles Pink Mobil­i­ty développe la mobil­ité des deux-roues élec­triques en France ! High-end engi­neer­ing for bet­ter mobility La sim­u­la­tion au cœur du développe­ment des véhicules de demain Mer­cedes-Benz Paris, la référence EQ