https://www.acsysteme.com/wp-content/uploads/2021/11/processus-Acsysteme-ADAS-AD-750x422.jpg
Processus de validation

Concevoir et valider des fonctions AD / ADAS en toute sérénité.

« Drôniser », robotiser, automatiser, rendre autonome… autant de termes pour votre nouveau projet : que votre système se déplace seul, sans intervention humaine.

Que vous partiez de la page blanche ou de codes existants, il y a une démarche à respecter pour développer des algorithmes robustes, fiables, maintenables… On vous explique comment.

Pour commencer, voici deux histoires que vous pourriez vivre si vous avez en charge d’intégrer des fonctions AD (autonomous driving) / ADAS (advanced driver assistance systems) dans votre système et les tester.

Histoire n°1

Vendredi 16 h : Doc a enfin reçu la brique logicielle qu’il attendait depuis hier pour pouvoir tester le programme sur son prototype. Il se dit, mieux vaut tard que jamais, j’ai encore deux heures pour pouvoir compiler le programme et faire les premiers tests sur mon prototype avant de partir en weekend à Saint-Malo. Ça devrait le faire ! Mais au bout d’une demi-heure de compilation : « Error : compilation failed ! ». Zut, qu’est-ce que j’ai encore fait comme erreur ? Doc cherche pendant 30 minutes où est-ce qu’il a bien pu commettre une erreur. Mais il ne trouve pas. Il appelle Marty McFly qui lui a livré le modèle mais il est déjà parti en weekend. Il arrive à avoir George qui travaille aussi sur le projet. Il lui dit qu’il ne sait pas trop mais qu’il va essayer de résoudre le problème. Il le rappelle 30 minutes plus tard pour lui dire qu’il y a bien un problème dans le logiciel qu’ils ont livré et qu’il n’y a que Marty qui pourra le régler lundi matin.  Grrr, Doc grince des dents. Il ne partira pas en weekend l’esprit tranquille !

Histoire n°2

Jeudi 12 h : Doc reçoit la brique logicielle qu’il attendait pour cet après-midi afin de pouvoir tester son prototype le lendemain. Il la laisse de côté car il a d’autres choses à traiter et de toute manière il a confiance en Marty, qui lui a livré le logiciel, ça marche à tous les coups. Le lendemain, il arrive à tester son prototype sans perdre de temps à la compilation. Le prototype fait ce qu’on attendait de lui mais ce n’est pas encore parfait. Il y a un comportement un peu bizarre qu’il ne comprend pas bien et il y a deux trois petites choses à régler auxquelles il n’avait pas pensé. Il a encore un peu de temps pour faire des acquisitions et noter les améliorations pour en discuter lors du point hebdomadaire en début de semaine prochaine.

Quelle situation préférez-vous ? La deuxième bien évidemment. Chez Acsystème, c’est aussi ce que nous voulons pour notre client. Nous accordons une grande importance à la qualité et au délai de nos livrables. Pour cela, nous utilisons un processus « vertueux » qui permet d’améliorer la qualité de nos livrables et nous assurer qu’ils sont au niveau d’exigence attendu par le client.

Cet article présente les grandes lignes de notre processus et des outils utilisés. Le processus illustré ci-dessous est utilisé pour le développement de fonctions AD/ADAS où le client attend qu’on lui livre une brique logicielle qu’il se charge d’intégrer sur ses moyens de tests et validations et/ou prototypes. Il peut être utilisé pour d’autres applications.

https://www.acsysteme.com/wp-content/uploads/2021/11/processus-Acsysteme-ADAS-AD-2-750×422.jpg

Processus de travail chez Acsystème

Les données d’entrée

Notre point d’entrée est généralement une liste d’exigences (ou spécifications) qui proviennent du client et le modèle Simulink sur lequel il faut intégrer les nouvelles fonctions.

L’environnement de validation

L’environnement de validation unitaire nous sert à valider, à travers une multitude de scénarios, que la fonction que l’on a développée respecte les exigences du client et à produire des courbes qui permettent de le prouver. De plus, cet environnement permet de réaliser des tests de non-régression, c’est-à-dire de vérifier que l’intégration de la nouvelle fonction ne génère pas de dysfonctionnement au niveau des fonctions intégrées auparavant. Nous le décrirons plus en détail dans la section suivante.

L’environnement est souvent spécifique au type de fonctions développées car on n’y intègre que les briques nécessaires. Si par exemple, nous développons une fonction qui s’intègre dans du contrôle longitudinal, nous utilisons l’environnement de contrôle longitudinal. En interne, nous disposons déjà d’un certain nombre de « briques ». Mais il est souvent nécessaire de développer de nouvelles briques ou de mettre à jour d’anciennes briques afin d’émuler de nouveaux capteurs, de nouvelles cibles ou de nouvelles motorisations.

Les scénarios de validation doivent permettre de tester les exigences. Nous sommes donc régulièrement amenés à créer de nouveaux scénarios qui correspondent aux exigences demandées par le client.

La conception

Nous mettons en œuvre notre expertise dans le domaine du contrôle et de Simulink afin de concevoir les fonctions demandées dans le cahier des charges en respectant les règles de codage imposées par le client ou, à défaut, par nos règles internes définies chez Acsystème.

Les simulations et analyses

Lors du processus de conception, il y a de nombreuses itérations entre simulations et conception afin d’analyser le comportement de notre fonction et de nous assurer qu’elle ne comporte pas de bugs fonctionnels.

Lorsque nous sommes satisfaits du résultat, nous nous assurons à travers une batterie de tests de non-régression que les nouvelles fonctions développées n’ont pas dégradé les fonctionnalités déjà existantes.

La livraison du soft

Enfin, nous livrons le soft au client avec les résultats de validation. S’il dispose d’un logiciel de gestion de version et d’intégration continue comme GitLab par exemple, nous nous intégrons dans cet environnement. Ainsi, nous pouvons nous assurer que le logiciel livré passe les tests d’intégration continue et que le client puisse facilement le récupérer afin qu’il puisse faire ses validations en interne.

Un processus itératif

Lors de la validation du client sur le système complet et/ou dans un environnement réel, il peut éventuellement constater des bugs ou un comportement anormal. Dans ce cas, nous lui demandons de nous faire un retour pour que nous apportions les corrections nécessaires à la fonction. Ce retour est aussi une opportunité pour enrichir la base de scénarios si le bug est lié à un cas d’usage non identifié au départ ou améliorer l’environnement de validation s’il ne permettait pas reproduire les conditions nécessaires à l’apparition du bug.

Ce processus vertueux nous permet aujourd’hui de livrer des modèles sans bugs fonctionnels. Ainsi, les itérations suite à la validation client sont peu nombreuses. Ce qui permet un gain de temps et d’énergie. Le client peut donc concentrer son énergie sur la définition des exigences qui vont permettre de respecter les normes et la prestation client, ainsi que la validation sur ses véhicules.

Un environnement de validation efficace

 

Outre notre expertise dans la conception des systèmes AD/ADAS, l’environnement de validation est un pilier de la réussite de notre engagement de qualité.

Notre environnement de validation se veut efficace pour pouvoir itérer rapidement. L’environnement de validation contient les éléments nécessaires pour alimenter correctement les signaux d’entrée des fonctions développées.

https://www.acsysteme.com/wp-content/uploads/2021/11/environnement-de-validation-750×422.jpg

Environnement de validation

Les briques principales de l’environnement de validation sont :

Modèle de conducteur

Génère des actions que pourrait faire le conducteur, comme :

  • appliquer un couple sur le volant,
  • faire des appuis boutons pour activer/désactiver les fonctions d’aide à la conduite
  • régler la vitesse de consigne
  • accélérer, freiner
  • mettre le clignotant

Modèle d’environnement

Décrit l’environnement extérieur :

  • la pente de la route
  • les lignes (position, courbure, type, qualité…)
  • les cibles et objets environnants
  • les panneaux…

Modèle véhicule

Le modèle véhicule permet de calculer son état (position, vitesse) en fonction des sollicitations du GMP et/ou du volant. Selon l’application, nous adoptons différents niveaux de complexités que nous pouvons combiner :

  • Modèle de dynamique longitudinal
  • Modèle de dynamique latérale (modèle bicyclette) avec modèle de direction assistée

Les paramètres des modèles sont fournis par le client (masses, répartition des masses, empattements, coefficients de dérives, … ). Une étape de recalage peut être effectuée si certains d’entre eux ne sont pas connus.

Le modèle véhicule comprend aussi :

  • une émulation simplifiée de la fusion de capteurs qui détectent les objets environnants
  • une émulation des lignes détectées par la caméra
  • une émulation de traitement des données extérieures qui peuvent être transmises par la caméra ou le système de navigation comme les vitesse limites, les panneaux, les feux …

Bloc « Contrôle »

Bloc contenant la brique logicielle que l’on souhaite valider.

L’environnement de validation permet aussi de simuler en boucle ouverte l’algorithme de contrôle pour faire du débogage. Nous pouvons injecter des signaux issus d’acquisitions afin de rejouer la situation ou le bug a été détecté et analyser les états internes du contrôle.

L’analyse des résultats se fait en traçant les différents signaux. Nous avons, en plus, développé un outil qui permet de visualiser le positionnement du véhicule par rapport aux lignes et aux objets environnants.

Cet environnement de validation, bien que simplifié par rapport à certains environnements du commerce (Amesim, Carmaker, SCANeR…), permet de tester efficacement nos développements. Il présente aussi plusieurs avantages par rapport aux environnements cités précédemment :

Évolutif

Cet environnement (entièrement développé par Acsystème) est régulièrement complété avec de nouveaux composants lorsque ceux-ci sont nécessaires pour valider une nouvelle fonctionnalité.

Économique

Tous les développements sont réalisés dans Matlab/Simulink et son utilisation ne nécessite aucune licence supplémentaire.

 

par Marouane Benaziz.

Rapide à simuler

Les calculs sont relativement rapides à réaliser notamment grâce à l’utilisation des modèles référencés et du mode « Accelerator » de Simulink.

Partager cet article :