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

Dossier : Vie des entreprisesMagazine N°765 Mai 2021Par Loïc NOURYPar Jacob KATHS

La grande complexité des fonctions de conduite automatisée et assistée (ADAS/AD) entraîne une augmentation spectaculaire du nombre d’essais de conduite requis, ce qui rend la virtualisation des essais de conduite indispensable. Par rapport aux essais de conduite réels, les simulations présentent une meilleure reproductibilité, elles sont plus faciles à automatiser et peuvent être réalisées en toute sécurité. Les erreurs peuvent ainsi être identifiées au cours des phases de développement antérieures et peuvent donc être éliminées à moindre coût. Un environnement d’essai ouvert et efficace est essentiel pour le déploiement réussi des simulations tout au long du processus 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 adoptée pour tester une fonction ADAS/AD est équivalente à celle adoptée pour les autres fonctions de contrôle. Dans les deux cas, le « système testé » doit être séparé et intégré dans une simulation plausible du système restant. Dans un premier temps, la fonction peut être développée et testée indépendamment du matériel cible. En fonction de l’état de développement dont on parle  :

  • Model-in-the-Loop (MiL) pour la conception de fonctions ;
  • Software-in-the-Loop (SiL) pour tester le logiciel d’un calculateur (ECU) sans matériel réel ;
  • Hardware-in-the-Loop (HiL), pour l’exécution de la fonction en tant que logiciel embarqué sur un calculateur.

Avant même de tester la fonction, la simulation apporte un soutien lors de la conception et de la spécification du système et également lors des analyses des modes de défaillance et de leurs effets (Failure Mode and Effects Analyses : FMEA). Les outils de simulation CANoe et DYNA4 de Vector assurent un déploiement cohérent de la simulation tout au long du processus de développement. Ceci est également vrai pour les tests continus pendant la phase de mise en œuvre. La figure 1 illustre cela au moyen du modèle V.

Dans le cas des applications HiL, la simulation fournit tous les signaux d’entrée et de sortie numériques et analogiques ainsi que l’ensemble de la communication sur différents types de réseaux. Généralement, les trois phases sont menées pendant le processus de développement, il est donc évident de réutiliser autant d’artefacts de simulation préparés que possible tout au long du processus. Cela s’applique en particulier aux tests qui ont été générés dès le début du développement. Idéalement, les mêmes étapes de test peuvent être utilisées de manière cohérente, en commençant par la phase MiL et en continuant jusqu’aux tests HiL.

Figure 1 : Test de fonctionnement avec CANoe et DYNA4 tout au long du processus de développement.
Figure 1 : Test de fonctionnement avec CANoe et DYNA4 tout au long du processus de développement.

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

Des fonctions simples peuvent être suffisamment testées par simple stimulation avec des données synthétiques ou enregistrées. Cependant, si la fonction testée contrôle le comportement de conduite du véhicule, les effets de ces entrées de contrôle doivent être renvoyés pour obtenir un comportement en boucle fermée. Cela nécessite des modèles qui reflètent le monde physique avec une précision suffisante. Ce que signifie exactement une précision suffisante dépend fortement de la fonction testée, comme le montre cet exemple : pour tester une fonction de stationnement automatisé, il est important d’obtenir une réflexion précise de la dynamique du véhicule, y compris la pression exacte des pneus, malgré les faibles vitesses.

En revanche, lors du test d’une fonction ACC concernant son interprétation correcte des données de capteurs fusionnés, un modèle simplifié de la dynamique du véhicule qui reflète le comportement caractéristique en roulis et en tangage peut suffire. Cela s’applique de la même manière aux modèles de capteurs : si le système ACC attend une liste d’objets comme entrée du capteur d’environnement, les modèles de capteurs basés sur les objets sont généralement suffisants. Si, toutefois, la fusion de capteurs précédente doit être testée également, moins de données de capteurs traitées sont nécessaires. Ces détections peuvent être calculées par des modèles de capteurs plus détaillés. Les modèles utilisés doivent donc être modulables en ce qui concerne leur fiabilité en fonction du cas d’utilisation spécifique. Cependant, l’augmentation de la complexité des modèles entraîne une augmentation du nombre de paramètres et il convient de préciser que la performance du modèle ne peut être qu’aussi bonne que le paramétrage correspondant. En particulier lors de l’essai des fonctions ADAS/AD, l’ensemble des paramètres deviennent de plus en plus importants car non seulement le véhicule testé, mais aussi les différentes conditions d’éclairage, les conditions climatiques, l’état du revêtement routier et bien sûr les différents acteurs du trafic doivent être représentés dans des scénarios complexes. La figure 2 montre un exemple de ce type de scénario pour un essai de conduite virtuelle. La gestion structurée des ensembles de paramètres et des variantes du modèle est donc tout aussi importante que le modèle lui-même.

Figure 2 : Visualisation d’un essai de conduite virtuelle pour tester les fonctions de l’ACC et de l’AEB dans le trafic environnant.
Figure 2 : Visualisation d’un essai de conduite virtuelle pour tester les fonctions de l’ACC
et de l’AEB dans le trafic environnant.

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, ainsi qu’à la simulation physique des véhicules et de l’environnement. De plus en plus souvent, les questions respectives doivent trouver une réponse simultanée et tout au long du processus de développement. C’est pourquoi les outils spécifiques de chaque domaine sont couplés. CANoe, par exemple, offre des fonctionnalités complètes pour l’intégration du logiciel de calculateur dans toutes les phases de développement. DYNA4 fournit des modèles physiques du véhicule et de l’environnement, mais permet également la création et la gestion de modèles, de scénarios et de leurs paramètres.

Pour l’évaluation des résultats de la simulation, un large éventail d’options d’analyse des signaux et une visualisation 3D sont inclus. Une fois que les modèles et les scénarios sont préparés dans DYNA4, ils peuvent être exécutés directement dans CANoe. Cela permet aux utilisateurs expérimentés de CANoe de conserver leurs processus habituels et garantit également une entrée facile dans les simulations en boucle fermée.

Le couplage efficace des outils hautement spécialisés de CANoe et de DYNA4 permet d’obtenir une combinaison idéale pour le test des fonctions ADAS/AD : avec des options complètes pour les tests de systèmes en boucle fermée et des processus cohérents dès les premières étapes de développement jusqu’au matériel réel.

La figure 3 montre un environnement de test en boucle fermée avec CANoe et DYNA4.
La figure 3 montre un environnement de test en boucle fermée avec CANoe et DYNA4.

Poster un commentaire