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

La grande com­plexi­té des fonc­tions de conduite auto­ma­ti­sée et assis­tée (ADAS/AD) entraîne une aug­men­ta­tion spec­ta­cu­laire du nombre d’essais de conduite requis, ce qui rend la vir­tua­li­sa­tion des essais de conduite indis­pen­sable. Par rap­port aux essais de conduite réels, les simu­la­tions pré­sentent une meilleure repro­duc­ti­bi­li­té, elles sont plus faciles à auto­ma­ti­ser et peuvent être réa­li­sées en toute sécu­ri­té. Les erreurs peuvent ain­si être iden­ti­fiées au cours des phases de déve­lop­pe­ment anté­rieures et peuvent donc être éli­mi­nées à moindre coût. Un envi­ron­ne­ment d’essai ouvert et effi­cace est essen­tiel pour le déploie­ment réus­si des simu­la­tions tout au long du pro­ces­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 tes­ter une fonc­tion ADAS/AD est équi­va­lente à celle adop­tée pour les autres fonc­tions de contrôle. Dans les deux cas, le « sys­tème tes­té » doit être sépa­ré et inté­gré dans une simu­la­tion plau­sible du sys­tème res­tant. Dans un pre­mier temps, la fonc­tion peut être déve­lop­pée et tes­tée indé­pen­dam­ment du maté­riel cible. En fonc­tion de l’état de déve­lop­pe­ment dont on parle : 

• Model-in-the-Loop (MiL) pour la concep­tion de fonctions ; 
• Soft­ware-in-the-Loop (SiL) pour tes­ter 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 tes­ter la fonc­tion, la simu­la­tion apporte un sou­tien lors de la concep­tion et de la spé­ci­fi­ca­tion du sys­tème et éga­le­ment lors des ana­lyses des modes de défaillance et de leurs effets (Fai­lure Mode and Effects Ana­lyses : FMEA). Les outils de simu­la­tion CANoe et DYNA4 de Vec­tor assurent un déploie­ment cohé­rent de la simu­la­tion tout au long du pro­ces­sus de déve­lop­pe­ment. Ceci est éga­le­ment vrai pour les tests conti­nus pen­dant la phase de mise en œuvre. La figure 1 illustre cela au moyen du modèle V. 

Dans le cas des appli­ca­tions HiL, la simu­la­tion four­nit tous les signaux d’entrée et de sor­tie numé­riques et ana­lo­giques ain­si que l’ensemble de la com­mu­ni­ca­tion sur dif­fé­rents types de réseaux. Géné­ra­le­ment, les trois phases sont menées pen­dant le pro­ces­sus de déve­lop­pe­ment, il est donc évident de réuti­li­ser autant d’artefacts de simu­la­tion pré­pa­rés que pos­sible tout au long du pro­ces­sus. Cela s’applique en par­ti­cu­lier aux tests qui ont été géné­rés dès le début du déve­lop­pe­ment. Idéa­le­ment, les mêmes étapes de test peuvent être uti­li­sées de manière cohé­rente, en com­men­çant par la phase MiL et en conti­nuant jusqu’aux tests HiL.

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

Des fonc­tions simples peuvent être suf­fi­sam­ment tes­tées par simple sti­mu­la­tion avec des don­nées syn­thé­tiques ou enre­gis­trées. Cepen­dant, si la fonc­tion tes­tée contrôle le com­por­te­ment de conduite du véhi­cule, les effets de ces entrées de contrôle doivent être ren­voyés pour obte­nir un com­por­te­ment en boucle fer­mée. Cela néces­site des modèles qui reflètent le monde phy­sique avec une pré­ci­sion suf­fi­sante. Ce que signi­fie exac­te­ment une pré­ci­sion suf­fi­sante dépend for­te­ment de la fonc­tion tes­tée, comme le montre cet exemple : pour tes­ter une fonc­tion de sta­tion­ne­ment auto­ma­ti­sé, il est impor­tant d’obtenir une réflexion pré­cise de la dyna­mique du véhi­cule, y com­pris la pres­sion exacte des pneus, mal­gré les faibles vitesses. 

En revanche, lors du test d’une fonc­tion ACC concer­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 dyna­mique du véhi­cule qui reflète le com­por­te­ment carac­té­ris­tique en rou­lis 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é­ra­le­ment suf­fi­sants. Si, tou­te­fois, la fusion de cap­teurs pré­cé­dente doit être tes­tée éga­le­ment, moins de don­nées de cap­teurs trai­tées sont néces­saires. Ces détec­tions peuvent être cal­cu­lées par des modèles de cap­teurs plus détaillés. Les modèles uti­li­sés doivent donc être modu­lables en ce qui concerne leur fia­bi­li­té en fonc­tion du cas d’utilisation spé­ci­fique. Cepen­dant, l’augmentation de la com­plexi­té des modèles entraîne une aug­men­ta­tion du nombre de para­mètres et il convient de pré­ci­ser que la per­for­mance du modèle ne peut être qu’aussi bonne que le para­mé­trage cor­res­pon­dant. En par­ti­cu­lier lors de l’essai des fonc­tions ADAS/AD, l’ensemble des para­mètres deviennent de plus en plus impor­tants car non seule­ment le véhi­cule tes­té, mais aus­si les dif­fé­rentes condi­tions d’éclairage, les condi­tions cli­ma­tiques, l’état du revê­te­ment rou­tier et bien sûr les dif­fé­rents acteurs du tra­fic doivent être repré­sen­tés dans des scé­na­rios com­plexes. La figure 2 montre un exemple de ce type de scé­na­rio pour un essai de conduite vir­tuelle. La ges­tion struc­tu­rée des ensembles de para­mètres et des variantes 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 outils dédiés à l’exécution des tests de MiL à HiL, ain­si qu’à la simu­la­tion phy­sique des véhi­cules et de l’environnement. De plus en plus sou­vent, les ques­tions res­pec­tives doivent trou­ver une réponse simul­ta­née et tout au long du pro­ces­sus de déve­lop­pe­ment. C’est pour­quoi les outils spé­ci­fiques de chaque domaine sont cou­plés. CANoe, par exemple, offre des fonc­tion­na­li­tés com­plètes pour l’intégration du logi­ciel de cal­cu­la­teur dans toutes les phases de déve­lop­pe­ment. DYNA4 four­nit des modèles phy­siques du véhi­cule et de l’environnement, mais per­met éga­le­ment la créa­tion et la ges­tion de modèles, de scé­na­rios et de leurs paramètres. 

Pour l’évaluation des résul­tats de la simu­la­tion, un large éven­tail d’options d’analyse des signaux et une visua­li­sa­tion 3D sont inclus. Une fois que les modèles et les scé­na­rios sont pré­pa­rés dans DYNA4, ils peuvent être exé­cu­tés direc­te­ment dans CANoe. Cela per­met aux uti­li­sa­teurs expé­ri­men­tés de CANoe de conser­ver leurs pro­ces­sus habi­tuels et garan­tit éga­le­ment une entrée facile dans les simu­la­tions en boucle fermée. 

Le cou­plage effi­cace des outils hau­te­ment spé­cia­li­sé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 pro­ces­sus cohé­rents dès les pre­mières étapes de déve­lop­pe­ment jusqu’au maté­riel réel. 

---

Articles similaires :

STVA : un acteur de réfé­rence de la logis­tique des véhi­cules auto­mo­biles finis GESTAMP, par­te­naire stra­té­gique des construc­teurs automobiles Pink Mobi­li­ty déve­loppe la mobi­li­té des deux-roues élec­triques en France ! Mer­cedes-Benz Paris, la réfé­rence EQ Le sec­teur auto­mo­bile, moteur de l’innovation