Une machine à états est définie par un ensemble S de n états et

un ensemble E de m transitions tel que :

S= {s₁, . . . , s_n} et |S|= n (4.2)

E = {e1, . . . , em} et |E|= m (4.3)

Les machines à états portent toutes les fonctions et algorithmes des tâches. Ces fonctions utilisent du temps processeur et ce modèle de tâche permet d’utiliser la structure des machines à états pour déterminer le pire temps de réponse des tâches.

Pour une machine à états SMi, deux cycles d’exécution sont possibles par itération : — la machine à états reste dans le même état si pour l’itération suivante : les

méthodes runi et handlei sont exécutées ;

— la machine à états passe de l’état si à l’état sj : les méthodes runi, exiti puis entry_j sont exécutées.

Les quatre méthodes n’ont pas besoin d’être définies pour chaque état selon l’application mais runi doit l’être.

t

iteration 1 iteration2

si si sj

run_{i handlei} run_{i exiti} entry_j

Figure 4.1 – Protocole de transition d’une machine à états

Deux itérations successives de l’exécution d’une machine à états sont montrées sur la figure4.1. Cette machine à états contient les méthodes entryi, runi, handlei et exitj. Lors de la première itération, la machine à états reste dans l’état si et exécute donc les méthodes runi et handlei. Lors du passage de l’état si à l’état sj de la seconde itération, les méthodes runi, exiti et entryj sont exécutées.

4.2 Calcul du pire temps d’exécution des tâches

Les tâches exécutant les fonctions et les machines à états des composants utilisent les ressources de calcul fournies par le processeur. Le temps passé par le processeur à calculer

4.2. Calcul du pire temps d’exécution des tâches

une fonction est appelé temps d’exécution. Cependant le temps d’exécution d’une fonction varie selon les conditions dans lesquelles elle s’exécute. Le pire temps d’exécution d’une fonction est défini comme une borne supérieure du temps d’exécution : il correspond au temps passé par le processeur à calculer cette fonction dans les conditions les plus défavorables à l’exécution.

Afin d’exploiter la précision apportée par les machines à états, nous devons déterminer les pires temps d’exécution des fonctions appelées par les machines à états, et plus précisément les pires temps d’exécution des méthodes entry, run, handle et exit des états des machines à états périodiques. Pour cela, nous utilisons deux méthodes : soit une analyse statique, soit une analyse probabiliste.

4.2.1 Analyse statique

Les méthodes d’analyse statique [Wilhelm et al. 2008] calculent de manière détermi-niste le pire temps d’exécution de fonctions à partir de deux éléments : un modèle du processeur sur lequel va s’exécuter la fonction et un exécutable compilé de la fonction.

Au cours de nos expérimentations, nous avons utilisé l’outil Otawa [Ballabriga et al. 2010] pour collecter les pires temps d’exécution d’une architecture robotique similaire à celle présentée dans le chapitre8. Le principe de fonctionnement de Otawa se base sur deux éléments principaux : des abstractions et des analyses. Les niveaux d’abstraction permettent de formaliser les spécifications de l’architecture matérielle du processeur cible et de fournir une représentation structurelle du programme exécuté sur ce processeur. Les méthodes d’analyse collectent les informations fournies par les couches d’abstraction afin de déterminer le pire temps d’exécution du programme sur le processeur cible.

Dans ces expérimentations, nous avons utilisé des cartes de développement Gumstix® Overo® Water à base de processeur ARM®Cortex™A8. Le modèle de processeur de cette carte de développement est disponible pour les outils d’abstraction matérielle de Otawa. Les modèles de processeur contiennent des informations détaillées des trois éléments principaux, à savoir le calculateur en lui même, les différents niveaux de cache et la mémoire principale :

— le modèle du calculateur fournit des informations sur la taille du pipeline, le nombre d’unités de calcul et leur latences, les catégories d’instructions associées aux unités de calcul ou encore les spécifications des files d’instruction ;

— le modèle de cache indique sa capacité, son organisation et ses diverses politiques de remplacement ou d’écriture ;

— le modèle de mémoire permet de représenter les temps d’accès aux données ainsi que le fonctionnement de la mémoire tampon.

Chapitre 4. Développement d’un modèle d’exécution de tâches

Pour déterminer le pire temps d’exécution d’un programme, les méthodes d’analyse nécessitent une représentation binaire du programme. Otawa effectue en premier lieu une recherche de boucles au sein du programme et essaye de déterminer une borne supérieure du nombre d’itérations de ces boucles. Afin de simplifier cette recherche, le code du programme peut être annoté en indiquant directement le nombre maximal d’itérations des boucles. Ensuite l’exécution du programme est simulée sur le modèle du processeur pour déterminer l’utilisation des caches, les contraintes liées à la taille des caches et une estimation du temps de calcul de blocs d’instructions. Enfin ces informations sont regroupées pour calculer le pire temps d’exécution du programme complet.

4.2.2 Analyse probabiliste

Les variations des temps d’exécution réels sont liées à la variabilité intrinsèque du matériel [Borkar 2005], à la complexité des fonctions [Burns et Littlewood 2010] et des interférences entre les éléments logiciels impliquant des dépendances complexes.

Les techniques d’analyse probabiliste à base de mesures permettent d’estimer le pire temps d’exécution de fonctions à partir de mesures d’exécutions réelles [Cucu-Grosjean

et al. 2012; Hansen, Hissam et Moreno 2009]. L’utilisation de méthodes probabilistes

induit la notion de pire temps de réponse probabiliste X qui représente une distribution de pire temps d’exécution.

La distribution de pire temps d’exécution probabiliste X d’une fonction correspond à la borne supérieure du temps d’exécution Xi dans toutes les conditions possibles d’exécution i. Xi est une distribution empirique des temps d’exécution mesurés dans des conditions spécifiques. Par conséquent, pour toute condition i, la distribution X est supérieure ou égale au temps d’exécution Xi. Le pire temps d’exécution probabiliste X est toujours supérieur ou égal à tous les temps d’exécution possibles par le système.

Les mesures Xi permettent d’extraire des comportements moyens ou des tendances lors de l’exécution des fonctions. Cependant, les mesures de temps d’exécution ne sont pas suffisantes pour obtenir le pire temps d’exécution probabiliste : une exécution réelle d’une fonction ne garantit pas que toutes les conditions possibles d’exécution puissent être observées.

Afin de palier à ce manque de complétude, nous utilisons la théorie des valeurs extrêmes [Santinelli et al. 2014]. Cela permet d’obtenir une borne non optimiste de l’estimation du pire temps d’exécution probabiliste X , c’est à dire que X est supérieur ou égal à X . La théorie des valeurs extrêmes permet de « prédire » le pire temps d’exécution, même si celui-ci n’est pas observable lors d’une expérimentation. La figure 4.2montre une distribution de probabilité d’occurrence de temps d’exécution mesurés ainsi que la

4.2. Calcul du pire temps d’exécution des tâches

distribution prédite par la théorie des valeurs extrêmes. La prédiction calcule un pire temps d’exécution sûr supérieur au pire temps exact.

probabilité temps d’exécution possible mesures exact sûr

Figure 4.2 – Comparaison entre les temps d’exécution mesurés et estimés par la théorie des valeurs extrêmes

Ensuite nous estimons les pires temps d’exécution C à partir des pires temps d’exécu-tion probabilistes X des foncd’exécu-tions et en les limitant à une borne de confiance p. Le couple hX , pi représente l’estimation du pire temps d’exécution pour une fonction donnée.

En pratique, les mesures nécessaires au calcul de pire temps d’exécution probabiliste sont collectées par l’intermédiaire d’un traceur. Ce traceur enregistre les dates d’exécution d’un ensemble de points dans le code des composants. Pour chaque composant, le générateur de code présenté dans le chapitre7instrumente le code exécutable en différents endroits. Un point d’enregistrement est ajouté autour de chaque élément des composants : — autour du core du composant afin de mesurer le délai entre le début et la fin d’exécution du composant, en prenant en compte les délais induits par le middleware;

— autour du update ou de la machine à états pour collecter le temps d’exécution du composant sans prendre en compte le middlware ;

— autour de chaque fonctions et de chaque état de la machine à états dans le but de mesurer le temps nécessaire au calcul des codels.

Pour cela nous utilisons le traceur Linux Trace Toolkit : next generation [Brown 2006], plus communément appelé LTTng, pour enregistrer des mesures d’exécution, comme présenté dans l’exemple 4.1. Les mesures collectées concernent à la fois les fonctions des composants ainsi que les tâches auxquelles ils sont attachés. Dans les deux cas, les mesures permettent d’obtenir la durée réelle d’exécution ce ces éléments. Chaque mesure est constituée de plusieurs éléments :

— une date absolue en secondes ;

— la différence entre la date courante et la date précédente en secondes ; — le nom de la session utilisateur ;

Chapitre 4. Développement d’un modèle d’exécution de tâches

— le type de mesure. Dans le cas de Mauve, deux types de mesures existent : Mauve:component:et Mauve:codel: qui représentent respectivement une mesure concernant un composant et un codel ;

— le numéro du cœur de processeur sur lequel s’est exécutée la mesure ;

— des informations dépendantes du type de mesure. Pour une mesure de type Mauve:component:, ces informations sont : l’identifiant de la tâche exécutant le composant (thread_id), la position de la mesure (state) pouvant être soit au début (begin) soit à la fin (end) de l’exécution du composant et le nom du composant (component). Pour une mesure de type Mauve:codel:, les informations contenues dans la mesure sont : l’identifiant de la tâche exécutant le composant (thread_id), la position de la mesure (state) et le nom du codel exécuté (codel).