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

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.

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.