Efficacité du logiciel de contrôle sur l’application avionique

L’application que nous évaluons est utilisée dans le contrôle des écrans du cockpit d’un ATR-42. Elle sélectionne les informations à afficher à partir d’entrées issues de différents capteurs et calculateurs. Il s’agit d’une application de taille moyenne, contenant environ 200.000 lignes de code, une partie étant générée. Une fois compilée, cette application a une empreinte mémoire d’environ 600K, répartie à deux tiers pour les instructions et un tiers pour les données. Dans un environnement opérationnel, cette application est exécutée sur des données qui sont lues à travers l’API d’ARINC 653. Dans notre contexte, nous étudions cette application sans système d’exploitation, et en utilisant des données

8.4. Evaluation d’une application avionique fixes. Cette application s’exécute en boucle courte, avec un temps d’exécution de l’ordre de la milli-seconde.

Cette application est un bon exemple de logiciel sur lequel évaluer notre logiciel de contrôle. D’une part, il s’agit d’une boîte noire, dont nous ne connaissons pas le comportement ni la structure. D’autre part, son empreinte mémoire dépasse la taille du cache L2 dans une proportion raisonnable. On peut donc s’attendre à ce que la logique de remplacement soit sollicitée.

Comme illustré sur la figure 8.7, on peut constater que l’impact du logiciel de contrôle sur l’application est élevé. En outre, le temps d’exécution de l’application augmente significativement lorsque l’on met en œuvre des configurations à plusieurs cœurs. On constate également que le logiciel de contrôle élimine la variabilité du temps d’exécution dûe aux interférences, ce qui était son objectif initial.

Nous considérons ici que le logiciel de contrôle a correctement fonctionné, mais qu’il n’a pas été efficace sur cette application. Cependant, étant donné les ratio avec lesquels le temps d’exécution a augmenté, on peut espérer atteindre un niveau d’efficacité correct en introduisant des optimisations sur le logiciel de contrôle vis-à-vis de cette application. Nous présentons ci-après quelques pistes pour effectuer ces optimisations.

8.4.2

Pistes pour l’optimisation du logiciel de contrôle

Nous avons constaté que le logiciel de contrôle n’est pas efficace sur l’application avionique. Toutefois, il reste dans un domaine où l’on peut proposer des optimisations visant à retrouver cette efficacité. Nous proposons à cet effet des optimisations portant sur le logiciel de contrôle, et non sur l’application.

Lors de l’exécution de l’application avionique, nous avons remarqué que la séquence de contrôle a été sollicitée à 220 reprises, ce qui représente un trafic total de 880K, un peu moins de trois fois la taille du cache. Les pistes intéressantes pour l’optimisation de la logique de contrôle portent sur les points suivants :

• L’identification des pages qui sont rechargées dans le cache à de nombreuses reprises. Cette identification est envisageable avec un module de trace associé à la logique de contrôle. Une fois ces pages identifiées, il est possible de les pré- charger et/ou de les verrouiller dans le cache.

• L’identification du nombre d’accès à chaque page contenant des données. Celles qui sont très peu sollicitées par le logiciel peuvent ne pas être chargées, auquel cas le logiciel de contrôle leur affectera une séquence de contrôle par émulation. Pour obtenir ce nombre d’accès, il est possible de rejouer l’exécution du logiciel utile en utilisant systématiquement des séquences de contrôle par émulation, et en comptant leurs occurrences.

• La séparation entre données et instructions dans le cache. Nous avons constaté que lorsqu’un logiciel manipule de grosses quantités de données, ces dernières fi- nissent par entraîner des déchargements d’instructions, ces dernières devant être immédiatement rechargées. On peut aborder ce problème en séparant les voies du cache en deux partitions, le choix de la partition étant effectué en fonction du

Chapitre 8. Efficacité du logiciel de contrôle

type d’accès intercepté, en donnée ou en instruction.

Ces pistes visent à améliorer l’efficacité du logiciel de contrôle sans pour autant chercher à retoucher le logiciel utile. On peut également envisager de rendre ce genre de mécanisme directement utilisable par le logiciel utile. Cela permettrait à un développeur d’application de transmettre au logiciel de contrôle des informations utiles pour que ce dernier puisse adapter sa logique de contrôle.

8.5

Synthèse

Nous avons donné dans ce chapitre une vue d’ensemble du logiciel de contrôle tel qu’il avait été spécifié dans le chapitre précédent. Ce logiciel de contrôle est intégré au sein du noyau d’un hyperviseur de petite taille. Cela nous permet de tirer parti de techniques de virtualisation permettant le déploiement de systèmes d’exploitation dans le logiciel utile. Ce prototype nous permet de déployer du logiciel utile, mais également d’observer la durée des accès effectués vers les ressources communes. Nous avons constaté à cette occasion que lorsque le logiciel de contrôle met en œuvre une stratégie TDMA, la distribution des temps d’accès aux ressource ne montre plus de signes d’interférences.

Nous avons ensuite proposé un ensemble de configurations du logiciel de contrôle sur le processeur. Ces configurations visent à évaluer d’une part la sensibilité du logiciel utile aux mécanismes implémentés dans la logique de contrôle, et d’autre part la sensibilité du logiciel utile à une stratégie d’utilisation TDMA instanciée pour un nombre de cœurs fictifs qui varie. Nous avons constaté les faits suivants :

• Le logiciel de contrôle est efficace lorsqu’une application traite un minimum de quelques kilo-octets de données regroupées dans des pages mémoire proches. • Le logiciel de contrôle est inefficace sur une application qui manipule des données

de manière désordonnée.

• Une application est peu sensible à la politique TDMA lorsqu’elle effectue beau- coup de calculs sur les données qu’elle manipule. En ce sens, nous avons constaté que le temps d’exécution d’une FFT varie très peu en fonction du nombre de cœurs selon le nombre de cœurs associés à la configuration. C’était moins le cas pour l’application AES.

Nous avons enfin testé notre logiciel de contrôle sur une application avionique de taille moyenne. Les résultats que nous avons obtenus sont mitigés. Le logiciel de contrôle n’est pas efficace vis-à-vis de cette application, mais il n’est pas loin de l’être, au moins sur les configurations à peu de cœurs. Pour que notre concept de logiciel de contrôle soit viable, il sera nécessaire d’explorer un certain nombre de pistes visant à améliorer son efficacité.

Cinquième partie

Conclusion générale

Chapitre 9

Conclusion

Sommaire

9.1 Résumé des travaux effectués . . . 147 9.1.1 Existence du logiciel de contrôle . . . 148 9.1.2 Efficacité du logiciel de contrôle . . . 149 9.1.3 Limites de l’approche . . . 150 9.2 Perspectives . . . 150 9.2.1 Perspectives à court terme . . . 151 9.2.2 Perspectives à long terme . . . 152

9.1

Résumé des travaux effectués

Nous avons abordé dans cette thèse le problème de l’évaluation du pire temps d’exé- cution (WCET) d’un ensemble de tâches déployées sur un processeur multi-cœurs COTS. Ce problème est connu comme difficile du fait de la présence d’interférences entre les activités électroniques générées par les différents cœurs. La présence d’interférences en- traîne une augmentation du temps d’exécution du logiciel embarqué, que l’on ne sait pas correctement borner.

Nous avons montré que les approches applicables aux processeurs COTS doivent combiner une stratégie d’utilisation qui rassemble les restrictions d’usage du processeur, et une stratégie de contrôle qui assure la mise en œuvre de la stratégie d’utilisation. La stratégie d’utilisation communément employée est centrée sur une politique d’arbitrage TDMA, selon laquelle chaque cœur dispose d’une fenêtre temporelle dans laquelle il peut accéder à l’intégralité des ressources communes.

Nous nous sommes intéressés à la mise en œuvre de la stratégie de contrôle dans un logiciel dédié, que nous avons appelé logiciel de contrôle. Nous avons abordé dans notre problématique de thèse la question de son existence et celle de son efficacité.

In fine, l’approche que nous avons développée dans cette thèse permet de rendre un processeur multi-cœurs COTS prédictible, et donc d’appliquer correctement des méthodes

Chapitre 9. Conclusion

d’évaluation du WCET en respectant les contraintes que nous nous étions fixées à partir de notre contexte industriel, à savoir :

• Rendre prédictible des processeurs COTS, tout en autorisant des configurations comportant un nombre arbitraire de cœurs. Nous avons mis en place une stra- tégie d’utilisation TDMA, qui assure une isolation temporelle entre l’activité des différents cœurs.

• Pouvoir nous intégrer dans une architecture de systèmes IMA. Nous avons choisi la configuration AMP (Asymetrical Multi-Processing) dans laquelle chaque cœur se comporte d’un point de vue fonctionnel comme un système autonome. Chaque cœur embarque une instance du logiciel de contrôle, un système d’exploitation mono-cœur et un ensemble de partitions ARINC 653.

• Pouvoir réutiliser du logiciel existant. Cela concernait des applications avioniques et dans une moindre mesure le système d’exploitation. Les mécanismes de contrôle sont invisibles du logiciel utile, ce qui assure la rétro-compatibilité vis-à-vis du lo- giciel existant.

Nous abordons dans la suite de cette section un résumé des contributions sur l’étude de l’existence du logiciel de contrôle, puis celle de son efficacité.