Présentation
Ce projet est le premier sur lequel j’ai travaillé dans un contexte professionnel lors de mon stage de six mois chez Thales Avionics. Il avait pour but de monitorer les performances du FMS (Flight Management System).
Contexte
Le FMS (Flight Management System) est un système embarqué à destination des avions. C’est l’ordinateur de bord de l’avion. Sa fonctionnalité principale est le routing (plan de vol) de l’avion.
C’est un projet colossal sur lequel plus d’une centaine de développeurs a travaillé. A savoir également que le nombre de tests réalisés pour faire l’intégration sur un tel outil représente une contrainte énorme. Parmi les essais réalisés, nous avons les tests de performances, et notamment les performances de la mémoire (RAM/ROM) et des temps de réponses du processeur. Ma mission est de développer un outil permettant de faciliter au quotidien la compréhension de l’utilisation de la mémoire et des temps processeurs du FMS dans un processus d’intégration continue.
Avant ce projet, les performances étaient récupérées et étudiées grâce à un système de logs très peu visuel. L’enjeu est donc un gain de temps considérable pour les développeurs du produit afin qu’ils puissent visualiser rapidement les performances du FMS et détecter d’éventuelles erreurs plus facilement.
Dans ce projet, les risques sont essentiellement liés à l’erreur humaine. Si une erreur n’est pas détectée lors de l’intégration continue de mon code, les graphiques pourraient donner des informations erronées aux développeurs du FMS et certaines erreurs de performances pourraient ne pas être corrigées.
Pour considérer la réussite du projet, l’outil doit être fiable, dynamique, maintenable, configurable et surtout intuitif. Les visuels des performances doivent pouvoir être interprétés au premier coup d’œil. Effectivement, le but étant de faire gagner du temps aux ingénieurs, on doit pouvoir trouver l’information facilement et rapidement.
Un serveur ainsi qu’une interface Web ont déjà été très largement commencé. Cet outil a été développé pour monitorer (contrôler/surveiller des données) les tests de non-régressions (tests permettant de contrôler après une modification que ce changement n’a pas entrainé d’effets indésirables). Il sert également à répertorier toutes les corrections qui sont appliquées à chaque version. Néanmoins, aucune fonctionnalité ne permet de monitorer les performances du FMS.
Plan d’action
J’ai tout d’abord travaillé sur de l’extraction de données mémoire. En effet, avant de pouvoir faire du monitoring, il faut déjà disposer de ces données.
Il existe deux types de données représentant la mémoire du module :
Des données statiques qui bougent peu et qui représentent les allocations maximales de RAM & ROM des différents logiciels embarqués;
Des données dynamiques qui proviennent du compilateur et qui correspondent aux allocations réelles : adresse des variables, taille des données, taille du code …
Les données de la mémoire sont enregistrées dans d’énormes fichiers de log ainsi que des fichiers de configurations répertoriant beaucoup d’informations (taille des zones allouées, type de données, adresse mémoire, nom du fichier, …). Je me suis occupé de concevoir un script permettant d’extraire, de trier et de recalculer les données intéressantes (celles que l’on veut monitorer) des différents fichiers concernés. Cela me permet de pouvoir générer deux fichiers JSON. Le premier JSON permet de modéliser la structure mémoire du FMS (partie RAM, partie ROM, …) tandis que le second répertorie les types de données ainsi que leur taille.
A la suite de cela, j’ai proposé les deux visuels ci-dessous car ils permettent de visualiser rapidement la conception mémoire du FMS à différents niveaux. Après concertation avec l’équipe, le visuel 2 a été retenu car il a été jugé plus intuitif. Il est également plus interactif : en effet, on peut également cliquer sur les cases pour faire un zoom sur le contenu.
Visuel 1 Visuel 2
Après le monitoring de la structure mémoire générale du FMS, j’ai dû proposer des visuels pour monitorer l’évolution de la mémoire (selon les versions) de manière plus précise comme le détail des types de données ou encore ou le détail d’un module spécifique. J’ai donc proposé un graphique en aires empilées comme celui-ci :
Graphique en aire empilées
Après la réalisation des graphiques concernant la mémoire, on m’a confié la tâche de monitorer également les données concernant les temps de réponse du processeur. Toujours pour un souci de performance, des tests sont fréquemment réalisés pour mesurer le temps que met le processeur à réaliser des algorithmes. Ces mesures sont réalisées grâce à des sondes présentes dans le FMS, puis décodées et dépouillées pour extraire des mesures au format JSON. Ici aussi, j'ai proposé des graphiques en aires empilés.
Résultats
Structure mémoire de la dernière version du FMS.
Structure mémoire de la dernière version
Grâce à ce graphique, les ingénieurs travaillant sur le FMS ont maintenant un aperçu global de l'utilisation de la mémoire et sont maintenant capables de détecter facilement des erreurs à ce niveau.
Evolution de la mémoire
Après validation de ces graphiques avec l’équipe, j’ai ensuite pu rajouter une fonctionnalité permettant de commenter un point du graphique. Cela peut s’avérer très utile pour savoir à quoi est liée une hausse ou baisse d’utilisation de la mémoire par exemple.
Grâce à ces différents graphiques, les ingénieurs sont maintenant capables de suivre l'évolution de manière précise des différents composants utilisant la mémoire.
Temps de réponse processeur
En implémentant ces graphiques, j'ai également développé deux autres fonctionnalités: l'ajout de commentaires comme sur l'évolution de la mémoire, et le zoom permettant d'accéder aux mesures des "sous-algorithmes".
Ces graphiques permettent aux ingénieurs de garder un œil sur les performances processeurs et de respecter les normes imposées au produit final (FMS).
Les différents travaux que j’ai effectués quant à ces visuels ont été présentés lors d’un forum inter-services et ont eu des retours positifs de la part des différentes équipes (management, validation, …).
Conclusion
Ce projet m'a permis de progresser davantage avec les technologies du Web (HTML, CSS, serveur Python) et de découvrir de nouvelles librairies graphiques comme ChartsJs ou D3, des librairies qui m'ont permis de réaliser ces graphiques. Au delà de cela, j'ai compris l'importance des performances dans le domaine de l'avionique et la nécessité de les monitorer.
Concernant les suites du projet, il est actuellement utilisé quasi quotidiennement par les ingénieurs travaillant sur le FMS. Je ne travaille actuellement plus sur la maintenance, mais j'ai tout de même développé à la suite de ça de nouvelles fonctionnalités comme des alertes automatiques en cas d'erreurs ou encore des outils permettant de comparer les performances entre deux versions.
A mon sens, même si il ne s'agit pas du produit final (FMS), ces outils sont très importants pour développer le FMS de manière efficace et aider les ingénieurs à détecter les erreurs rapidement afin de les corriger le plus vite possible.