PAUL SABATIER U.F.R. MATHÉMATIQUES INFORMATIQUE GESTION THESE. en vue de l'obtention du

Transcription

1 UNIVERSITÉ DE TOULOUSE III PAUL SABATIER U.F.R. MATHÉMATIQUES INFORMATIQUE GESTION THESE en vue de l'obtention du DOCTORAT DE L'UNIVERSITÉ DE TOULOUSE délivré par l'université Toulouse III Paul Sabatier Discipline: Informatique présentée et soutenue par Fadia NEMER le 27 Février 2008 Titre OPTIMISATION DE L'ESTIMATION DU WCET PAR ANALYSE INTER-TACHE DU CACHE D'INSTRUCTIONS Directeurs de thèse Jean-Paul Bahsoun, professeur, Université de Toulouse III Hugues Cassé, maître de conférence, Université de Toulouse III JURY M. Pascal Sainrat, professeur, Université de Toulouse III, Examinateur M. Ali Awada, maître de conférence, Université Libanaise, Examinateur M. François Bodin, professeur, Université de Rennes I, Rapporteur M. Philippe Clauss, professeur, Université Louis Pasteur Strasbourg, Rapporteur

2

3 À ma mère qui m'a soutenue, encouragée et tout simplement aimée À mon père qui n'est plus, je t'aime papa... je ne t'oublie pas...

4 «Fais de ta vie un rêve, et d'un rêve une réalité» Antoine de Saint-Exupéry

5 REMERCIEMENTS Je tiens à remercier Jean-Paul Bahsoun mon directeur de thèse. Ma reconnaissance va également à Hugues Cassé, pour son encadrement, son soutien et la disponibilité dont il a fait preuve. Je remercie aussi Pascal Sainrat, directeur de l'équipe TRACES, pour ses conseils, et Ali Awada pour son aide pendant mon séjour au Liban. Je tiens aussi à remercier vivement Monsieur François Bodin et Monsieur Philippe Clauss pour m avoir fait l honneur d être les rapporteurs de cette thèse. Un grand merci à tous les membres de l'équipe TRACES pour la bonne ambiance de travail. Je remercie ma famille et tous mes amis pour leur support qui m'a permis de continuer mes études dans les meilleures conditions. Je remercie particulièrement mon fiancé, Hani Kanaan, pour son soutien tout le long de cette thèse et pour la compréhension et la patience dont il a fait preuve.

6 AUTEUR FADIA NEMER TITRE «Optimisation de l'estimation du WCET par analyse inter-tâche du cache d'instructions» DIRECTEURS DE THÈSE Jean-Paul Bahsoun, Hugues Cassé DATE ET LIEU DE LA SOUTENANCE 27 Février 2008, Université Paul Sabatier RÉSUMÉ Les systèmes temps réel se distinguent des autres systèmes informatiques par la prise en compte de contraintes temporelles dont le respect est aussi important que l'exactitude du résultat. On distingue le temps-réel strict ou dur (de l'anglais hard real-time) et le temps-réel souple ou mou (soft real-time) suivant l'importance accordée aux contraintes temporelles. Théoriquement, le concepteur d'un système temps réel strict doit être capable de prouver que les limites temporelles ne sont jamais dépassées quelle que soit la situation. Cette vérification, appelée analyse de faisabilité, fait appel à la théorie de l'ordonnancement. Elle requiert une connaissance du pire comportement temporel du système. Il est donc nécessaire de connaître en particulier les pires instants d'arrivées des tâches, et les temps d'exécution dans le pire des cas des tâches. C'est sur l'obtention de cette dernière information que porte notre étude. Le temps d'exécution pire cas d'un programme peut être estimé en mesurant son temps d'exécution dans un environnement de test ou par analyse statique du code. Les approches par analyse statique ont l'avantage d'être sûres mais fournissent des estimations parfois pessimistes. Or ces méthodes calculent le WCET d une tâche seule et non dans le cadre d une application complète ainsi elles ignorent plusieurs facteurs des systèmes temps-réel multi-tâches, essentiellement l'enchaînement des tâches, qui affectent naturellement la précision du WCET estimé. Nous proposons une nouvelle approche, qui s applique aux systèmes temps-réel stricts, multitâches. Cette méthode étudie le comportement d un ordonnancement statique des tâches d une application temps-réel, s'exécutant sur un processeur, pour analyser le comportement inter- et intra- tâche de la mémoire cache. Le but est de remplacer les hypothèses conservatrices qui supposent un état vide ou indéfini du cache par un état bien défini avant l exécution de chaque tâche de l ordonnancement. Ceci va nous permettre d améliorer la précision de l estimation du WCET de ces tâches en utilisant la trace de l exécution d autres tâches dans le cache. Cette thèse propose aussi un benchmark temps-réel, PapaBench, décrivant une application temps-réel complète et réelle pour le pilotage d'un UAV (Unmanned Aerial Vehicle). Ce benchmark a été conçu afin de constituer une base utile pour les expérimentations de calcul de WCET par méthodes statiques ou dynamiques, il peut être aussi utile pour les analyses d'ordonnancement. MOTS CLÉS WCET, analyse statique, benchmark temps-réel, analyse de flot de données, interprétation abstraite Discipline Informatique INTITULÉ ET ADRESSE DU LABORATOIRE D'ACCUEIL Institut de Recherche en Informatique de Toulouse Université Paul Sabatier 118 route de Narbonne F Toulouse Cedex 9

7 TABLE DES MATIÈRES Introduction...15 Chapitre 1 Systèmes embarqués et temps-réel Définitions Système Réactif Système distribué et Système embarqué Spécification des systèmes réactifs embarqués La boucle de contrôle L'architecture matérielle Les contraintes temporelles et matérielles Ordonnancement temps-réel Stratégies d'ordonnancement Modèle de tâche Ordonnancement préemptif, non-préemptif Ordonnancement en ligne, hors ligne Ordonnanceur à priorités statiques, dynamiques Algorithmes d'ordonnancement classiques Rate Monotonic (RM) Earliest Deadline First (EDF) Deadline Monotonic (DM) Least Laxity First (LLF) Modélisation en AADL Choix d'aadl AADL : Vue Générale Types de composants Composants Matériels Composants Logiciels Composants Composites Les modes Les propriétés Conclusion...36 Chapitre 2 - PapaBench : un benchmark temps-réel Le projet Paparazzi Historique Les composants du système Paparazzi...39 vii

8 1.2.1.Fonctionnement du microcontrôleur MCU1 (Fly by wire) Fonctionnement du microcontroleur MCU0 (Autopilote) Papabench Modèle aadl Lien avec le modèle AADL Complexité des variables Représentation graphique de Paparazzi Limitations de Papabench Genèse de Papabench Le modèle AADL Les règles de précédences Le benchmark Détails de la compilation Comparaison avec les benchmarks temps-réel Les Benchmarks temps-réel Caractéristiques du code Complexité des boucles Papabench1 vs Papabench Outils utilisés Résultats Conseils de conception des applications temps-réel Conclusion...64 Chapitre 3 Calcul standard du temps d'exécution pire cas Estimation du WCET Méthodes dynamiques Caractéristiques Techniques de calcul du wcet par analyse dynamiques Méthodes statiques Analyse de flot de contrôle Représentations logiques Blocs de base Ligne Bloc ou L-bloc Graphe de flot de contrôle Arbre Syntaxique Dépliage des appels de fonctions Influence de la compilation sur la représentation logique du programme Informations supplémentaires de flot de contrôle Analyse des propriétés temporelles Le pipeline Simulation plus Delta Graphe d'exécution Les mémoires caches Découpage du cache en blocs...88 viii

9 Les types de caches Les stratégies de remplacement sur un défaut de cache Techniques intra-tâche de calcul du WCET Techniques utilisant les algorithmes de graphes Techniques IPET Techniques basées sur les arbres syntaxiques Analyse Symbolique du WCET Analyses des systèmes multi-tâches Analyse Edgar & Burns Analyse Diaz, Garcia & al Analyse Tan & Mooney Analyse Staschulat & Ernst Conclusion Chapitre 4 Analyse d'une application multi-tâches Définition du problème Contexte Comportement du cache intra-tâche Comportement inter-tâche du cache Les interférences possibles des L-blocs Analyse de flot de données (dfa) Analyses du cache à accès direct Analyse Exit Construction des états du cache Analyse Entry Amélioration du WCET des tâches Analyse du cache associatif Architecture d'un cache associatif Stratégie de remplacement LRU Sémantiques du cache Analyse Exit Calcul du Damage Analyse Inter-Tâche Analyse Entry Injection d'un état du cache et calcul du wcet Choix du meilleur Ordonnancement Conclusion Chapitre 5 Expérimentations Benchmarks Outils Résultats ix

10 3.1.Variation des paramètres du cache Variation de la taille de bloc Variation de la taille du cache Variation du degré d'associativité Variation de l'ordonnancement Comparaison Réinjection Entry Amélioration des WCET des tâches et du WCET global Conclusion Conclusion x

11 INDEX DES FIGURES Figure Modèle d'un système réactif...20 Figure Exemple d'un système réactif...20 Figure Exemple d'ordonnancement RM...28 Figure Exemple d'ordonnancement EDF...29 Figure Calcul de la laxité d'une tâche Ti...30 Figure Type de ports...33 Figure Représentation graphique des composants AADL...33 Figure Le système Paparazzi...40 Figure Axes de roulis et de tangage...41 Figure Fonctionnement de MCU0 en pilotage manuel assisté et automatique...42 Figure Tâches et interruptions de MCU1 (a) et MCU0(b)...43 Figure Graphe de dépendances Mode Manuel...44 Figure Dépendances du Mode Automatique...44 Figure PCG de Fly_by_wire (a) et de l'autopilot (b)...45 Figure Le système embarqué de Paparazzi...46 Figure Représentation graphique du système MCU Figure Représentation graphique du système MCU Figure 2.11: Exemple d'ordonnancement...48 Figure Règles de précédences des tâches de PapaBench Figure PCG de MCU0 dans PapaBench Figure Répartition des Instructions...57 Figure Analyse de la complexité des boucles...58 Figure Statistiques du temps d'inactivité...62 Figure Comparaison des ordonnancements...62 Figure Code Source d'un programme C...70 Figure Construction des L-blocs...71 Figure Graphes de flot de contrôle...71 Figure T-Graphs du programme analysé...72 Figure Arbre syntaxique du programme analysé...73 Figure Dépliage des appels de fonction dans l'arbre syntaxique (a) et dans le CFG (b)...74 Figure Les schémas logiques de deux compilations d'une même structure de boucle...75 Figure Occupation du pipeline d'un processeur MicroSPARC...77 Figure Exemple de LTE...79 Figure Modèle de contraintes de l'exécution dans le pipeline...80 Figure Processeur à exécution ordonnée ayant deux pipelines parallèles...81 Figure Modèle de contraintes pour un processeur multi-pipeline...81 Figure Effets temporels calculés par simulation...83 Figure Exemple d'un processeur...84 Figure Exemple d'un graphe d'exécution (pipeline scalaire à exécution ordonnée)...84 Figure Graphe d'exécution (pipeline superscalaire à exécution non-ordonnée)...85 Figure Le découpage d'une adresse d'un bloc mémoire...89 Figure Cet exemple utilise un cache à 8 blocs et une mémoire de 32 blocs...90 Figure Traduction d'un graphe de flot de contrôle en un système de contraintes...94 Figure (a)graphe de dépendances inter-modulaires, (b) appel de procédures...97 Figure Concaténation () de deux représentations wa et wb du pipeline Figure Exemple Figure Sous arbre test d'une structure conditionnelle xi

12 Figure Arbre Syntaxique et l'arbre de Portée équivalent de la fonction impaire Figure Préemption directe et préemption indirecte Figure Scénario de Préemption Figure Exemple d'un ordonnancement statique Figure Caractéristiques de la tâche Figure Comportement des L-blocs d'une tâche T sachant l'état du cache IN Figure Algorithme itératif de DFA Figure Formules GEN, KILL Figure Algorithme MUSTEXIT Figure Analyse MAYEXIT Figure Exemple d'un CFG d'une tâche Figure Transformation d'un ordonnancement en graphe de flot de contrôle Figure Formules GEN, KILL analyse inter-tâche Figure Analyse inter-tâche MUST Figure Analyse inter-tâche MAY Figure Algorithme MUSTENTRY Figure Analyse MAYEXIT Figure Calcul du nombre de hit minimal et maximal Figure Algorithme MUSTEXIT Figure Algorithme MAYEXIT Figure Algorithme DAMAGEMUST Figure Algorithme DAMAGEMAY Figure Analyse Inter-tâches MUST Figure Analyse Inter-tâches MAY Figure Analyse MUSTENTRY Figure Analyse MAYENTRY Figure Exemple Figure Exemple Figure mcu0 (PapaBench1), nombre de hits total (cache 16 Ko) Figure mcu0 (PapaBench2), nombre de hits total (cache 16 Ko) Figure mcu1, nombre de hits total (cache 16 Ko) Figure mcu0(papabench1), nombre de hits total (taille bloc 8 octets) Figure mcu0(papabench2), nombre de hits total (taille bloc 8octets) Figure mcu1, nombre de hits total (taille de bloc 8octets) Figure mcu0 (PapaBench1), variation du nombre de hits total en fonction de A Figure mcu0 (PapaBench2), variation du nombre de hits total en fonction de A Figure mcu1, variation du nombre de hits total en fonction de A Figure mcu0 (PapaBench1), impact de la variation de l'ordonnancement Figure mcu0 (PapaBench2), impact de la variation de l'ordonnancement Figure mcu1, impact de la variation de l'ordonnancement Figure mcu0 (PapaBench1), réinjection / ENTRY Figure mcu0 (PapaBench2), réinjection / ENTRY Figure mcu1, réinjection / ENTRY Figure mcu1, amélioration des WCET des tâches Figure mcu0 (PapaBench1), amélioration des WCET des tâches Figure mcu0 (PapaBench2), amélioration des WCET des tâches Figure mcu0 (PapaBench1), Pourcentage de réduction du WCET global Figure mcu0 (PapaBench2), Pourcentage de réduction du WCET global Figure mcu1, Pourcentage de réduction du WCET global xii

13 INDEX DES TABLES Tableau Tâches et interruptions de MCU Tableau Statistiques sur les Benchmarks temps-réel...56 Tableau Caractéristiques générales des deux versions...60 Tableau Les différentes catégories des références mémoires...93 Tableau Formules de calcul de WCET de [30]...99 Tableau Extension du schéma temporel pour prendre en compte les caches et le pipeline Tableau Calcul du WCET d'une structure sachant son niveau d'imbrication dans une boucle Tableau Expressions par défaut pour chaque type de portée INDEX DES FORMULES Formule Expression de calcul du WCET...95 Formule Évaluation du WCET en tenant compte du cache d'instructions...96 Formule distribution de Gumbel Formule estimation statistique du WCET Formule relation entre ω et ε Formule Calcul récursif du WCRT d'une tâche Ti Formule estimation conservatrice du WCRT Formule Estimation améliorée du WCRT Formule Formule générale de DFA itératif Formule Amélioration du WCET initial xiii

14 xiv

15 INTRODUCTION PROBLÉMATIQUE Du métro sans conducteur au pilote automatique dans les avions, les systèmes temps-réel envahissent notre vie quotidienne. Ce monde du temps-réel est si vaste que ses technologies s'appliquent à divers secteurs tels que le contrôle d une centrale nucléaire, les systèmes d aide au pilotage des avions, les téléphones portables, le transport, la télécommunication,. Les progrès accomplis en électronique et en informatique ont apporté beaucoup à l augmentation de la puissance de calcul des machines et à l amélioration de la performance de ces systèmes. Les systèmes temps-réel se distinguent des autres systèmes informatiques par la prise en compte de contraintes de temps dont le respect est aussi important que l'exactitude du résultat. Autrement dit, le système ne doit pas simplement délivrer des résultats exacts mais il doit les délivrer dans des délais imposés, c'est-à-dire que le système doit réagir à chaque événement de l'environnement externe avant l'échéance imposée par l'environnement pour le prochain événement. On distingue le temps-réel strict ou dur (de l'anglais hard real-time) et le temps-réel souple ou mou (soft real-time) suivant l'importance accordée aux contraintes temporelles. Les systèmes temps-réel stricts ne tolèrent aucun dépassement de ces contraintes, ce qui est nécessaire si de tels dépassements peuvent conduire à des situations critiques, voire catastrophiques : pilote automatique d'avion, système de surveillance de centrale nucléaire, etc. À l'inverse, le temps-réel souple s'accommode des dépassements de contraintes de temps dans certaines limites au-delà desquelles le système devient inutilisable : visioconférence, jeux en réseau, etc. On peut ainsi considérer qu'un système temps-réel strict doit respecter des limites temporelles données même dans la pire des situations d'exécution possibles. En revanche un système temps-réel souple doit respecter ses limites pour une moyenne de ses exécutions. On tolère un dépassement exceptionnel, qui sera peut être rattrapé à l'exécution suivante. Théoriquement, le concepteur d'un système temps-réel strict devrait être capable de prouver que les limites temporelles ne sont jamais dépassées quelle que soit la situation. Cette vérification est appelée test d'acceptabilité, analyse de faisabilité ou encore contrôle d'admission ; elle fait appel à la théorie de l'ordonnancement et sa vérification dépend de l'ordonnanceur utilisé et des caractéristiques des tâches du système. 15

16 Cette analyse requiert une connaissance du pire comportement temporel du système. Il est nécessaire de connaître en particulier les pires instants d'arrivées des tâches, et les temps d'exécution dans le pire des cas des tâches. C'est sur l'obtention de cette dernière information que porte notre étude. Le temps d'exécution pire cas d'un programme peut être estimé en mesurant son temps d'exécution dans un environnement de test qui peut être un système réel ou un simulateur. Les mesures doivent être réalisées pour tous les jeux d'entrée possibles ou alors il faut être capable de définir un jeu d'entrée qui conduit certainement au temps d'exécution le plus long. Il existe un autre moyen de mesure du WCET en utilisant des méthodes d'analyse statique de son code sans avoir à l exécuter sur le matériel cible. En théorie, le test dynamique est approprié pour l'analyse du WCET du code. En effet, le temps d'exécution du programme est mesuré pour une exécution avec un jeu d'entrée particulier. Un outil de test idéal exécuterait le programme pour chaque ensemble possible de valeurs en entrée et mesurerait le temps d'exécution. Mais ceci n'est pas toujours possible en pratique car la complexité des programmes à analyser conduit à un nombre extrêmement grand de tests possibles. Si pour un programme donné, on a pu définir le jeu d'entrée pire cas, alors ces méthodes permettent d'obtenir une valeur précise du WCET notée «WCET réel». En revanche, les approches par analyse statique ont l'avantage d'être sûres. Cette sûreté des estimations a une contrepartie, les estimations obtenues sont parfois pessimistes. Ce pessimisme induit une surestimation des moyens matériels nécessaires au fonctionnement du système. Ces méthodes fournissent alors une borne supérieure du WCET appelée aussi «WCET estimé». Nous proposons dans ce manuscrit une méthode qui permet de réduire ce pessimisme. APPROCHE Les propositions de cette thèse sont classées dans la catégorie des méthodes par analyse statique du code. La plupart des méthodes d'évaluation du WCET par analyse statique, proposées dans la littérature, calculent le WCET d'une seule tâche en considérant des hypothèses conservatrices sur l état du matériel qui garantissent la condition nécessaire et suffisante, le WCET estimé est supérieur ou égal au WCET réel, pour qu'il n'y ait pas un risque de violation des contraintes temps-réel. Bien que ces méthodes produisent des approximations sûres sous réserve de certaines hypothèses sur le processeur, elles ignorent plusieurs facteurs des systèmes temps-réel multi-tâches, essentiellement l'enchaînement des tâches qui affectent naturellement la précision du WCET estimé. Nous proposons une nouvelle approche, qui s applique aux systèmes temps-réel stricts, multi-tâches. Cette méthode étudie le comportement d un ordonnancement statique des tâches d une application temps-réel, s'exécutant sur un processeur, pour analyser le comportement 16

17 inter- et intra tâche de la mémoire cache. Le but est de remplacer les hypothèses conservatrices qui supposent un état vide ou indéfini du cache par un état bien défini avant l exécution de chaque tâche de l ordonnancement. Ceci va nous permettre d optimiser l estimation du WCET de ces tâches en utilisant la trace de l exécution d autres tâches dans le cache. Comme tout logiciel, le calcul du WCET nécessite des expérimentations, des évaluations et des comparaisons d où la nécessité des benchmarks qui représentent les fonctionnalités des applications temps-réel. Cependant, il est très difficile de se procurer une application réelle pour tester le système avant de le mettre en utilisation vu les critères de confidentialité dont s'entourent les industriels. En même temps, les benchmarks temps-réel sont très rares et sont constitués généralement d'un ensemble d'algorithmes de base utilisés dans les applications temps-réel. Ces benchmarks sont déconnectés des particularités des applications embarquées telles que la gestion des capteurs et actionneurs. Les fonctions qu'ils fournissent sont exécutées seules et non dans le contexte d'une application complète. Il est ainsi impossible de les utiliser pour expérimenter l impact de l enchaînement des tâches sur l estimation du WCET. Comme solution à ce problème, nous avons conçu un benchmark temps-réel, PapaBench, décrivant une application temps-réel complète pour le pilotage d'un UAV (Unmanned Aerial Vehicle). Il a été conçu afin de constituer une base utile pour les expérimentations de calcul de WCET par méthodes statiques ou dynamiques mais il peut être aussi utile pour les analyses d'ordonnancement. PLAN L organisation du document est la suivante. Le premier chapitre présente les caractéristiques des systèmes temps-réel embarqués à contraintes temps-réel stricts, l'ordonnancement temps-réel et les politiques d'ordonnancement les plus utilisées, et pour terminer, il explique notre choix de la norme AADL pour modéliser les applications temps-réel. Nous présentons au deuxième chapitre, les deux versions de notre benchmark temps-réel PapaBench1 et 2, leur intérêt, leurs différences et leur utilité pour les expérimentations des approches de calcul de WCET et pour l'étude des ordonnancements. Le troisième chapitre passe en revue les principales méthodes d'estimation du temps d'exécution pire cas, statiques et dynamiques, intra-tâche et multi-tâches. Le quatrième chapitre décrit notre approche qui permet d'optimiser l'estimation du WCET des tâches en étudiant leurs contextes d'exécution. Nous nous intéressons surtout à l'analyse du comportement de l'ordonnancement de ces tâches sur le cache d'instructions pour construire les états du cache à l'entrée de chaque tâche. Ces états remplacent les hypothèses conservatrices utilisées par les méthodes d'analyse statique usuelles pour fournir des estimations sûres mais pessimistes du temps d'exécution pire cas. Ainsi chaque tâche 17

18 bénéficie des traces d'exécutions des tâches précédentes, ce qui va nous permettre de détecter les faux défauts de cache induits par les hypothèses conservatrices, et ainsi d'optimiser l'estimation du WCET de la tâche. Nous introduisons à la fin de ce chapitre un algorithme itératif basé sur notre approche qui permet de choisir le meilleur ordonnancement des tâches d'une application temps-réel pour une politique d'ordonnancement fixée au départ. Les résultats expérimentaux présentés au cinquième chapitre prouvent l'intérêt de notre approche. Ces expérimentations sont effectuées sur les deux versions de PapaBench pour plusieurs configurations du cache et pour plusieurs ordonnancements. Nous montrons la variation du WCET global de l'application en fonction de la taille du cache, de la taille du bloc de cache, du degré d'associativité et de la politique d'ordonnancement. Enfin nous concluons cette étude en mettant en avant les apports de notre travail et les perspectives ouvertes par ce dernier. 18

19 CHAPITRE 1 SYSTÈMES EMBARQUÉS ET TEMPS-RÉEL Les systèmes temps-réel sont de plus en plus présents dans de nombreux secteurs d'activités comme l'aéronautique, l'automobile, l'énergie, les télécommunications, le contrôle de processus industriel et le secteur militaire. Ces systèmes réalisent souvent des tâches complexes qui sont souvent critiques. Ils sont soumis aux contraintes temporelles de l'environnement qu'ils doivent respecter. En effet, pour qu'une application temps-réel soit valide, elle doit non seulement fournir un résultat correct, mais elle doit le délivrer en respectant certaines contraintes temporelles qui sont le plus souvent des échéances de terminaison au plus tard. En d'autres termes un système temps-réel se distingue d'un système traditionnel par sa capacité à garantir l'exécution des tâches en respectant certaines échéances. Un système temps-réel est un système réactif qui réagit avec son environnement à un rythme imposé par cet environnement. Il peut être distribué ou embarqué ou embarqué/distribué. Comme notre étude s'intéresse essentiellement au systèmes embarqués temps-réel qui sont le plus souvent distribués, ce chapitre présente la particularité de chacune de ces catégories. Nous définissons aussi l'ordonnancement temps-réel et nous présenterons une vue générale des politiques d'ordonnancement utilisées par la suite. 1. DÉFINITIONS 1.1. SYSTÈME RÉACTIF Le concept de système réactif a été défini dans la littérature, par plusieurs travaux. La définition suivante est donnée par [1]: Définition 1 (Système réactif) Un système réactif est un système qui réagit continûment avec son environnement à un rythme imposé par cet environnement. Il reçoit, par l'intermédiaire de capteurs, des entrées provenant de l'environnement, appelées stimuli, réagit à tous ces stimuli en effectuant un certains nombre d'opérations et produit, grâce à des actionneurs, des sorties utilisables par l'environnement, appelées réactions ou commandes 19

20 Chapitre 1 - Systèmes embarqués et temps-réel 1.Définitions (voir figure 1.1). Dans un système réactif, la validité d'une commande ne dépend pas uniquement de la validité de la valeur de son résultat, mais aussi de son instant de délivrance. Parfois, dans la littérature, le système réactif est appelé système de contrôle, et l'environnement système contrôlé [2]. Figure Modèle d'un système réactif Un exemple très simple d'un système réactif est celui de la régulation de niveau d'eau dans un réservoir (figure 1.2). Dans cet exemple, l'environnement est constitué d'un réservoir d'eau, d'une vanne et de deux capteurs sensibles à la présence d'eau. Supposons qu'à l'instant t=0 le niveau d'eau dans le réservoir soit le niveau du capteur 1 et que la vanne soit ouverte. Le rôle de ce système est de maintenir le niveau d'eau entre les deux capteurs 1 et 2: si le capteur 2 est mouillé le système doit envoyer une commande de fermeture de la vanne avant que le réservoir déborde, et si le capteur 1 est sec le système doit envoyer une commande d'ouverture de la vanne. Figure Exemple d'un système réactif Les exigences fonctionnelles et temporelles sont donc deux caractéristiques essentielles des 20

21 Chapitre 1- Systèmes embarqués et temps-réel 1.Définitions systèmes réactifs. D'une part, Les exigences fonctionnelles imposent au système de produire des résultats corrects du point de vue des valeurs du domaine. D'autre part, les exigences temporelles imposent au système de produire ces résultats à temps, c'est-à-dire que le système doit réagir à chaque événement de l'environnement externe avant l'échéance imposée par l'environnement pour le prochain événement. Suivant les exigences temporelles d'un système réactif, nous distinguons deux classes de systèmes: Systèmes réactifs temps-réel stricts ces systèmes doivent impérativement garantir le respect des contraintes de temps imposées par l'environnement. Ces contraintes sont cruciales pour de tels systèmes car une erreur temporelle peut avoir des conséquences catastrophiques (humaines, matérielles, financières, écologiques, etc.). Les systèmes de contrôle de trafic aérien et de conduite de missile sont deux exemples de ces systèmes. Systèmes réactifs temps-réel souples - les contraintes temporelles de ces systèmes sont définies pour assurer une qualité de service mais peuvent exceptionnellement être violées sans mettre en cause la sécurité du matériel et des personnes impliquées. Il s'agit d'exécuter les fonctions dans les meilleurs délais. Par exemple, le traitement vidéo d'un système multimédia peut omettre quelques images sans que la qualité visuelle ne soit détériorée SYSTÈME DISTRIBUÉ ET SYSTÈME EMBARQUÉ Notre étude porte essentiellement sur les systèmes temps-réel embarqués. Comme ces systèmes possèdent le plus souvent une architecture distribuée surtout pour des raisons de sécurités et de performance, ce paragraphe fournit la définition d'un système distribué et d'un système embarqué. Définition 2 (Système distribué) Un système distribué est tel que son architecture matérielle est composée de plusieurs machines multiprocesseurs ou monoprocesseur reliées entre elles par un ensemble de moyens de communication (mémoire partagée, bus, liaisons point-àpoint...). En général, cette architecture distribuée est hétérogène les processeurs respectivement moyens de communication ont des caractéristiques physiques différentes. Définition 3 (Système embarqué) Lorsqu'un système temps-réel est physiquement intégré à l'environnement qu'il contrôle et qu'il est soumis aux mêmes contraintes physiques (température, pression,...) que son environnement, il est dit embarqué. Un système embarqué est un système réactif ayant des ressources limitées, telles que la mémoire, la consommation d'énergie, la taille, le poids, la puissance de calcul... Un système temps-réel intégré dans un robot mobile est un système embarqué, alors qu'un système de contrôle de bras de robot n'en est pas un. Dans le premier cas, le système temps-réel fait partie intégrante du robot, il se déplace avec lui et il est ainsi soumis aux mêmes contraintes physiques externes. Dans le deuxième cas, le système peut être dans une 21

22 Chapitre 1 - Systèmes embarqués et temps-réel 1.Définitions armoire électrique placée dans une pièce différente de celle où se situe le robot. Ce système temps-réel est donc indépendant du bras manipulateur, il n'est pas intégré à son environnement (bras + objets manipulés). Les systèmes embarqués sont généralement soumis à des contraintes spécifiques de coûts pris au sens large du terme. Ces contraintes sont dues, d'une part, au type d'applications couvertes par ce type de système et, d'autre part, à l'intégration du système à son environnement. Ces contraintes particulières de coût sont de plusieurs types : encombrement, consommation d'énergie, prix, etc. Un système possède souvent des ressources limitées, telles que sa taille (un avion, PDA Personal Digital Assistant) SPÉCIFICATION DES SYSTÈMES RÉACTIFS EMBARQUÉS Nous nous intéressons dans la suite de ce document aux systèmes réactifs embarqués à contraintes temps-réel strictes. Pour des raisons de lisibilité, nous écrivons «système temps-réel strict» au lieu de «système réactif embarqué à contraintes temps-réel strictes». La spécification de ces systèmes est réalisée en trois phases complémentaires et dépendantes : La spécification fonctionnelle consiste à définir la boucle de contrôle avec ses exigences fonctionnelles La spécification architecturale consiste à définir l'architecture matérielle qui doit implanter cette spécification La spécification des contraintes consiste à attribuer des propriétés temporelles et matérielles à l'exécution de la boucle de contrôle sur l'architecture La boucle de contrôle La boucle de contrôle d'un système réactif représente les fonctions nécessaires au contrôle et à la commande de l'environnement. Elle est composée d'un ensemble de composants logiciels, que nous appelons tâches. Chacun assure une fonctionnalité spécifique du système telle que la commande d'une vanne de régulation. Définition 4 (Tâche) On définit une tâche comme une séquence ordonnée indivisible d'instructions à laquelle on peut associer des propriétés temporelles devant être respectées à l'exécution. La boucle de contrôle peut être modélisée par un graphe de dépendances. Les sommets représentent les tâches et les arcs représentent les dépendances de données et de contrôle entre ces tâches. Une dépendance de données entre deux tâches T1 et T2, est telle que T1 apparaît avant T2 dans le graphe de dépendances, signifie que T 2 commencera son exécution après avoir reçu les données de sortie de T1. Tandis qu'une dépendance de contrôle, signifie que T1 s'exécute avant T2 suite à une contrainte imposée par l'environnement sans qu'il y ait un 22

23 Chapitre 1- Systèmes embarqués et temps-réel 1.Définitions échange de données entre ces deux tâches. Nous utilisons la notation T1 < T2 pour représenter cette dépendance de donnée, ainsi T2 dépendant des résultats de T L'architecture matérielle Cette étape consiste à caractériser tous les composants de l'architecture et à choisir la topologie du réseau de communication: Processeurs la spécification de la boucle de contrôle ne peut être complètement indépendante de l'architecture, puisque les attributs temporels des tâches sont en relation directe avec le type de processeurs utilisé. Ainsi la durée d'exécution d'une tâche est différente d'un processeur à un autre dans le cas d'une architecture hétérogène. Capteurs et actionneurs les systèmes réactifs utilisent des capteurs et des actionneurs pour interagir avec l'environnement extérieur qu'ils contrôlent. Dans le cas d'une architecture distribuée, le choix de l'emplacement physique de ces capteurs / actionneurs sur l'architecture est important dans la conception de ces systèmes. Moyen de communication les processeurs de l'architecture distribuée communiquent en utilisant deux types de communication : envoi de messages ou partage de données. Pour gérer les communications inter-processeurs entre des tâches dépendantes, placées sur des processeurs distincts, il est donc nécessaire de connaître le type des communications et le type de média de communication (mémoire partagée, bus, lien point-à-point,...) Les contraintes temporelles et matérielles Les contraintes temporelles s'expriment, pour chaque tâche de la boucle de contrôle, en termes de sa date début d'exécution, sa période, et sa date d'échéance. La date de début d'exécution est liée à l'occurrence de certains événements ou à la satisfaction de certaines conditions (i.e. la réception de données), tandis que l'échéance est liée au comportement exigé par l'environnement. La spécification de la boucle de contrôle n'est pas complètement indépendante de l'architecture : par exemple, afin de réduire le câblage, certains capteurs et actionneurs doivent être gérés par des processeurs spécifiques de l'application. Il est donc nécessaire de spécifier des contraintes matérielles pour chaque composant de cette boucle de contrôle. Cela conduit à attribuer à chacun, un ou plusieurs processeurs de l'architecture matérielle qui peuvent l'exécuter. 2. ORDONNANCEMENT TEMPS-RÉEL Lors de la conception d'un système temps-réel, la phase d'implantation est la plus délicate : 23

24 Chapitre 1 - Systèmes embarqués et temps-réel 2.Ordonnancement temps-réel elle consiste à distribuer et à ordonnancer les tâches sur l'ensemble des composants de l'architecture matérielle (processeurs, bus,...). La distribution est une allocation spatiale d'une tâche à une ressource, alors que l'ordonnancement est une allocation temporelle d'une tâche sur une ressource. Le but est de distribuer et d'ordonnancer toutes les tâches pour former un programme. Ces questions d'ordonnancement ont donné lieu à de nombreux travaux [3 à 12]. Définition 5 (Ordonnancement temps-réel) L'ordonnancement est le terme informatique désignant le mécanisme permettant de réaliser la sélection, parmi plusieurs composants de la boucle de contrôle, de celui qui va obtenir l'utilisation d'un composant de l'architecture pour s'exécuter de manière à optimiser un ou plusieurs critères. L'ordonnancement temps-réel a une particularité qui nécessite de respecter des contraintes temps-réel. Le processus qui réalise une telle sélection, et donc qui définit un ordre d'exécution entre les composants de la boucle de contrôle, est appelé algorithme d'ordonnancement. Il existe, pour une architecture donnée, un grand nombre de possibilités d'ordonnancement et de distribution mais seulement un certain nombre d'entre elles permet de satisfaire à la fois aux contraintes liées à la boucle de contrôle (dépendances de données) et aux contraintes temps-réel (aspect temporel) mais aussi aux contraintes de l'architecture (aspect matériel). Cet espace de solutions valides est d'autant plus restreint que les contraintes sont fortes. C'est le cas des systèmes temps-réel embarqués qui sont des applications souvent complexes et dont les contraintes de coût se traduisent généralement par de fortes contraintes matérielles STRATÉGIES D'ORDONNANCEMENT Un système temps-réel strict doit impérativement garantir le respect des échéances fixées pour l'exécution des tâches. Le dépassement de l'échéance par au moins une tâche temps-réel stricte peut conduire à une défaillance générale du système. Pour cette raison, on cherche à avoir la certitude absolue, avant exécution, que toutes les échéances seront toujours respectées lors de l'exécution de l'application. Une politique d'ordonnancement est appliquée pour vérifier le respect des échéances des tâches, des contraintes matérielles et des dépendances de données. Cette politique est constituée d'une part de l'algorithme d'ordonnancement et d'autre part du test d'ordonnançabilité. L'algorithme d'ordonnancement est chargé de décider de l'ordre d'exécution des tâches. Tandis que, le test d'ordonnançabilité (appelé aussi analyse d'ordonnançabilité, ou analyse de faisabilité) permet de vérifier que l'algorithme choisi permettra à toutes les tâches de respecter toutes le contraintes énumérées ci-dessus en toutes circonstances (voir 2.2) Modèle de tâche La majorité des stratégies d ordonnancement fait appel à la notion de tâche. On trouve dans la littérature les définitions de plusieurs modèles de tâche [3], [4], [5]. Les tâches sont 24

25 Chapitre 1- Systèmes embarqués et temps-réel 2.Ordonnancement temps-réel indépendantes mais elles peuvent partager des variables globales. Définition 6 (Tâche périodique) Une tâche périodique, comme son nom l indique, doit être exécutée à des intervalles de temps fixés (ou périodes). Dans sa version la plus générale, une tâche périodique est définie par le quadruplet Ti (Φi; Ci ; Pi ;Di) où Φi 0, Ci > 0 et Ci min(pi, Di), Pi > 0, et Di > 0. La phase Φi de la tâche dénote la date de son premier réveil, Ci son temps d exécution pire cas ou WCET(Worst Case Execution Time), Pi sa période d exécution, et Di son échéance relative, c est-à-dire le temps maximal dont on dispose pour exécuter la tâche. La période d exécution de la tâche correspond à la contrainte de cadence qui est imposée à la tâche [4], [5]. Définition 7 (Tâche apériodique, sporadique) Les tâches apériodiques et sporadiques sont des tâches exécutées à des instants à priori non connus. L exécution de ces tâches est généralement déclenchée par un événement provoqué par le processus contrôlé. Les tâches apériodiques ont aussi des contraintes temporelles, par exemple après le déclenchement de son exécution, une tâche apériodique doit se terminer dans un temps prédéfini. Cependant les tâches apériodiques n'ont pas d'échéance stricte, elles ont des échéances particulièrement importantes pour tenir compte des événements critiques du système [4]. La période d exécution n intervient donc pas dans le modèle de ces tâches. On distingue une tâche sporadique d une tâche apériodique par la connaissance d un intervalle de temps minimum entre deux exécutions de la tâche sporadique Ordonnancement préemptif, non-préemptif Lorsque l exécution d une tâche active peut être interrompue à tout moment pour allouer le processeur à une autre tâche jugée plus prioritaire, l ordonnancement est dit préemptif. Un ordonnancement est non-préemptif si chaque tâche s'exécute de son démarrage à sa terminaison sans interruption [6]. Un ordonnancement préemptif apporte un sur-coût sur le temps de calcul. En effet, au moment de la préemption, le contexte de la tâche préemptée doit être sauvegardé. Ce contexte doit être restauré lorsque la préemption s achève, c est-à-dire au moment où l exécution de la tâche préemptée doit reprendre. Par contre, un ordonnancement préemptif permet, dans certains cas, de garantir des contraintes temporelles impossibles à garantir avec un ordonnancement non-préemptif. On peut distinguer deux types de préemption, celle déclenchée par des interruptions matérielles (événement extérieur) et celle déclenchée par les algorithmes d ordonnancement (tâche prioritaire, synchronisation). Dans le cadre d un ordonnancement préemptif, il est nécessaire de garantir qu une ressource n est accédée que par une seule tâche à la fois. L accès en exclusion mutuelle à une ressource peut engendrer un phénomène d inversion de priorité au cours duquel l exécution d une tâche de haute priorité voulant accéder à une ressource est retardée par l exécution de tâches de plus basse priorité, dont l une est rendue non-préemptible pendant l accès à cette même ressource [7], [8]. 25

26 Chapitre 1 - Systèmes embarqués et temps-réel 2.Ordonnancement temps-réel Ordonnancement en ligne, hors ligne L ordonnancement peut être calculé lors de la conception du logiciel, dans ce cas, l ordonnancement est dit hors ligne. Il consiste à analyser la boucle de contrôle du système et ses contraintes temporelles afin de définir la séquence d exécution des tâches qui permet de respecter ses contraintes, temporelles et matérielles (cf. 2.2). Dans ce cas, l exécutable qui gère l application est simple car le code à exécuter est composé d une séquence d opérations insérées dans une boucle principale qui représente la boucle de contrôle. Cette approche de l ordonnancement nécessite une spécification rigoureuse de la boucle de contrôle afin de le calculer automatiquement par des outils logiciels. C est généralement celle qui est utilisée quand cette boucle est spécifiée avec des langages synchrones car la réalisation d une séquence d exécution des opérations a l avantage de permettre de facilement conserver et de s assurer que l ordre des événements, défini par la spécification, est conservé à l exécution et donc que les propriétés mises en évidence par la vérification sont conservées par l implantation. Lorsque l ordonnancement est calculé pendant l exécution, on parle d ordonnancement en ligne. Dans ce type d approche, l exécutable est construit autour d un ordonnanceur chargé de gérer l activation, la mise en attente et l arrêt des tâches [8], [9]. Un ordonnancement en ligne est plus coûteux à l exécution qu un ordonnancement hors ligne car, en plus des calculs liés la boucle de contrôle de l application, le calculateur doit aussi réaliser les calculs liés à l ordonnanceur. De plus, un ordonnancement hors ligne est prédictible car la séquence de calcul est connue avant l exécution alors que dans un ordonnancement en ligne, l ordre d exécution est déterminé par l ordonnanceur, il n est donc pas toujours possible de connaître à l avance l ordre précis d exécution des tâches. Un ordonnancement en ligne sera par contre plus flexible qu un ordonnancement hors ligne, en ce sens qu il pourra plus facilement prendre en compte les événements dont l occurrence est imprévisible (tâches apériodiques ou sporadiques). D'une manière générale, un ordonnancement est dit statique s'il possède les caractéristiques suivantes : Construction hors ligne d'une séquence complète de planification sur la base de tous les paramètres temporels des tâches. Cette séquence est un procédé défini par l'utilisateur Régularité temporelle du monde externe les événements asynchrones sont observés à des dates précises. L'ordonnancement des tâches est régi par un calendrier. C'est une table spécifiant la liste des différents processus à activer qui est exploitée cycliquement. L'ordonnancement est ainsi périodique. Le temps est découpé en unité de base insécable appelé cycle de base. D'autre part un ordonnancement est dit dynamique s'il est caractérisé par : 26

27 Chapitre 1- Systèmes embarqués et temps-réel 2.Ordonnancement temps-réel Un ordonnanceur en ligne qui ré-évalue à chaque nouvelle demande la tâche qui doit être exécutée. Il permet de tenir compte des tâches apériodiques et sporadiques Ordonnanceur à priorités statiques, dynamiques L ordonnanceur est la fonction de l exécutable chargée de choisir l ordre d exécution des tâches dans un ordonnancement en ligne. Différentes hypothèses simplificatrices sont généralement faites : les propriétés temporelles d une tâche sont constantes tout au long de la durée de vie de l application ; les tâches sont indépendantes, le découpage de l application en un ensemble de tâches doit donc être judicieux. Le choix de l ordonnancement est basé sur des priorités affectées aux tâches. A des intervalles de temps réguliers, l ordonnanceur détermine la tâche à exécuter parmi une liste. Ce choix est réalisé en comparant la priorité d exécution de la tâche en cours à la priorité de chacune des tâches de la liste. Généralement les priorités des tâches sont déterminées à la compilation et sont invariantes pendant l exécution de l application, on parle d'ordonnancement à priorités statiques. Dans certains exécutables, les priorités peuvent varier pendant l exécution. Dans ce cas l ordonnancement est dit ordonnancement à priorités dynamiques. L assignation des priorités aux tâches est parfois empirique, elle repose sur le savoir-faire des programmeurs de l application. Généralement, elle repose sur des règles définies par la politique d ordonnancement (cf 2.2) ALGORITHMES D'ORDONNANCEMENT CLASSIQUES Dans cette section, nous donnons une idée générale de quelques politiques d'ordonnancements que nous avons utilisées pour effectuer nos expérimentations Rate Monotonic (RM) Dans cette approche, l'échéance D de la tâche est toujours égale à sa période P et la priorité associée à l'exécution de la tâche est inversement proportionnelle à sa période d'exécution P. C'est un ordonnancement à priorités statiques. Les tâches sont périodiques et indépendantes. Il a été démontré qu'avec ce type d'ordonnancement pour qu'une implantation soit acceptable (pour que les échéances de toutes les tâches soient satisfaites), il suffit que l'ensemble des tâches respecte la condition suivante (test d'ordonnançabilité) [10], [11]: n U = C Pi i=1 n 21 /n 1, U étant le taux d'utilisation du processeur. i 27

28 Chapitre 1 - Systèmes embarqués et temps-réel 2.Ordonnancement temps-réel La limite de ce test d'ordonnançabilité est fonction du nombre de tâches du système. Notons que : lim n 21 /n 1 =ln n Ceci implique qu'un ensemble de tâches est ordonnançable si U 0.69, mais il se peut qu'il ne soit pas ordonnançable si 0.69 < U 1. Cette politique d'ordonnancement est beaucoup utilisée étant donné qu'elle utilise des priorités fixes et qu'elle est donc simple à mettre en œuvre. Figure Exemple d'ordonnancement RM La figure 1.3 montre l'ordonnancement de trois tâches périodiques T1, T2 et T3 d'un système temps-réel, caractérisées par une phase = 0 et, des WCET, des échéances et des périodes spécifiques. L'ordonnancement Rate Monotonic autorise la préemption des tâches. La jième activation d'une tâche Ti est notée par Ti,j. Comme la tâche T2 possède la plus grande priorité, elle est exécutée en premier. Elle est suivie par les tâches T3 puis T1. Comme T2 possède une priorité supérieure à celle de T1, elle interrompt l'exécution de celle-ci à l'instant t = 5 correspondant à sa période d'exécution. Les flèches vertes correspondent au temps d'activation des tâches la tâche est prête à être exécutée (comme la phase est nulle, ces flèches sont marquées à la fin de la période des tâches sauf pour la première activation car on suppose que toutes les tâches sont prête à t = 0) Earliest Deadline First (EDF) La priorité est ici déterminée en fonction de l'échéance relative D de la tâche et c'est la tâche qui a la plus petite échéance absolue di = npi + Di qui est la plus prioritaire, où n est le nombre d'exécutions antérieures de la tâche [12]. Dans le cas où il existe deux tâches qui ont la même échéance absolue, l'une d'elles est choisie d'une manière arbitraire. Comme les échéances relatives des instances de tâches changent, EDF est un ordonnancement à priorités 28

29 Chapitre 1- Systèmes embarqués et temps-réel 2.Ordonnancement temps-réel dynamiques. Quand les tâches sont à échéances sur requête (Pi = Di), on dispose de la condition n Ci 1. Pour des tâches à échéances nécessaire et suffisante d'ordonnançabilité U = i=1 P i quelconques, cette condition est seulement nécessaire et une condition suffisante est alors n C Di 1. i=1 i Cette politique d'ordonnancement est plus difficile à mettre en oeuvre que celle du Rate Monotonic, car il est parfois difficile de fixer les échéances des tâches. Par contre, grâce à l'exploitation de l'échéance, paramètre commun à tous les types de tâches, la prise en compte des tâches sporadiques et apériodiques est facilitée [11]. EDF est plus avantageux que RM vu qu'on n'a pas besoin d'attribuer des priorités aux tâches. De plus, c'est un algorithme optimal car si un ensemble de tâches est ordonnançable, U 1, donc il est sûrement ordonnançable par EDF, ce n'est pas un cas général pour RM (voir 2.5.1). Ensuite, EDF peut ordonnancer n'importe quel ensemble de tâches ordonnançables par RM mais la réciproque n'est pas correcte. Enfin, EDF utilise le processeur avec un temps d'inactivité inférieur ou égal à celui fournit par RM [13]. La figure 1.4 montre l'ordonnancement EDF des tâches T1(0,3,7,20), T2(0,2,4,5) et T3(0,1,8,10). T2 est la tâche prioritaire car elle possède la plus petite échéance relative. Elle est ensuite suivie de T1 puis de T3. Notons que les flèches vertes indiquent la date d'activation de la tâche tandis que les rouges montrent la date d'échéance relative de chaque tâche. On peut également remarquer que si on garde les mêmes échéances que dans l'exemple de la figure 1.3, nous obtiendrons le même ordonnancement avec EDF. Figure Exemple d'ordonnancement EDF Deadline Monotonic (DM) C'est un algorithme d'ordonnancement à priorité fixe tel que la priorité d'une tâche est 29

30 Chapitre 1 - Systèmes embarqués et temps-réel 2.Ordonnancement temps-réel inversement proportionnelle à son échéance relative. Pour cet algorithme, l'échéance relative d'une tâche peut être inférieure ou égale à sa période D P [11]. Si l'échéance des tâches est égale à leur période, l'algorithme est équivalent au Rate Monotonic. Si nous considérons l'ensemble des tâches de la figure 1.4, nous obtiendrons le même ordonnancement qu'avec EDF Least Laxity First (LLF) Cet algorithme est une variante d'edf, il est donc basé sur le calcul dynamique des priorités des tâches. A chaque décision d'ordonnancement, on augmente la priorité de chaque tâche en fonction de leur marge temporelle (Laxity). Celle dont la laxité est la plus petite sera alors la plus prioritaire. La laxité li d'une tâche T (Pi, Ci, Di) est définie comme suit: ' l i = Di t c i où t, temps courant et c'i, temps de calcul restant (cf figure 1.5). Figure Calcul de la laxité d'une tâche Ti 3. MODÉLISATION EN AADL Les systèmes temps-réel offrent de plus en plus de fonctionnalités et ont des domaines d'application toujours plus nombreux que ce soit dans le monde industriel, ou sous forme embarquée dans l'automobile et l'aviation. Les langages de conception doivent permettre de maîtriser la complexité de tels systèmes, d'améliorer leur qualité et de minimiser les coûts de développement. Ces langages de description d'architecture sont très utiles car ils permettent l'introduction des méthodes formelles et des modèles de technologie dans l'analyse des architectures de logiciel et de système [14]. 30

31 Chapitre 1- Systèmes embarqués et temps-réel 3.Modélisation en AADL La norme AADL, Architecture Analysis & Design Language a été développée pour les systèmes embarqués temps-réel de sûreté critique. Ces systèmes supportent l'utilisation de diverses approches formelles pour analyser l'impact de la composition des systèmes matériels et logiciels et pour réaliser la génération du code de système répondant aux normes de qualités et de performance prévues. AADL, est basée sur le langage MetaH [15]. Il inclut des profils UML utilisés pour l'avionique, l'espace, les véhicules à moteur, la robotique et d'autres domaines en temps-réel de traitements concurrents comprenant des applications de sûreté critique. Le standard international d'aadl a été développé par la SAE (Society of Automotive Engineers) depuis La version 1.0 a paru en Le comité de standardisation comporte les principaux acteurs de l'industrie avionique et aérospatiale, en Europe comme aux USA (Honeywell, ESA, Airbus, Rockwell Collins, EADS, AMCOM, NIST, Boeing, etc) CHOIX D'AADL Le modèle AADL [16], [17] décrit entièrement un système embarqué. Comme AADL possède une description graphique et textuelle, il permet de comprendre plus facilement le fonctionnement de l'application. De plus, le langage AADL peut être utilisé pour réaliser des traitements automatiques. Par exemple, on peut générer plusieurs ordonnancements à partir de la description. Nous utilisons CHEDDAR [18] pour accomplir cette tâche. CHEDDAR est un outil qui permet de générer des ordonnancements d'une liste de tâches bien définie. Il est développé et maintenu au LISYC de l'université de Brest. Nous allons utiliser cet outil pour expérimenter notre approche de calcul du WCET sur l'application complète Dans le cadre de l'analyse statique, bien que le modèle AADL soit basé sur une application réelle et vu que nous ne réalisons pas de simulations fonctionnelles, nous pouvons le changer librement selon nos besoins expérimentaux. Nous pouvons ajouter / supprimer des composants, changer des propriétés et / ou ajouter de nouvelles propriétés pour évaluer les paramètres de l'application. Comme nous sommes spécifiquement intéressés par les contraintes temporelles pour le calcul du WCET et pour l'analyse d'ordonnancement, AADL peut être très utile pour évaluer ces propriétés sans avoir à changer la structure de l'application AADL : VUE GÉNÉRALE Le SAE-AADL a été développé pour les systèmes temps-réel embarqués qui ont des contraintes critiques de ressources (taille, poids, puissance), des contraintes de réponse en temps-réel, de tolérance des fautes, et de matériel spécialisé d'entrée-sortie, et qui doivent être certifiés à des niveaux élevés de fiabilité. AADL a été conçu pour servir de base à l'analyse et à la génération des systèmes embarqués basés sur des modèles. La notation a été conçue 31

32 Chapitre 1 - Systèmes embarqués et temps-réel 3.Modélisation en AADL comme un noyau de langage extensible avec des sémantiques bien définies et des présentations graphiques et textuelles. Le langage est employé pour décrire la structure d'un système temps-réel embarqué comme un ensemble de composants logiciels et matériels. Il supporte les spécifications des interfaces fonctionnelles (tels que des entrées et des sorties de données) et les aspects non fonctionnels (tels que la synchronisation des composants). AADL décrit la composition et l'interaction entre les composants de l'application, et comment ces composants sont assignés aux processeurs dans la plate-forme d'exécution. Les mécanismes d extension permettent d introduire des propriétés spécifiques aux analyses supplémentaires d'architecture comme des attributs de qualité tels que la fiabilité, la sécurité, etc. AADL peut être employé de deux manières : analyse légère des patrons d'architecture identifiés dans les systèmes temps-réel pour découvrir les enjeux systémiques potentiels ( sécurité, sûreté, inversion de priorité, connexions requises,etc.), et l'analyse complète d'un modèle complet de systèmes avec des valeurs quantifiées de ses propriétés TYPES DE COMPOSANTS Le but d'aadl est de modéliser l'architecture des systèmes logiciels qui sont des systèmes d'application liés à une plate-forme d'exécution. L'architecture est modélisée en hiérarchie de composants, dont l'interaction est représentée par des connexions. Un composant possède un type de composant et une ou plusieurs implémentation(s) de composant. Définition 8 (Type de Composant) décrit une interface fonctionnelle en termes de caractéristiques, spécification de flot, et propriétés. Il représente la spécification du composant avec laquelle d'autres composants peuvent fonctionner, c-à-d son interface extérieure visible. Des implémentations du composant sont exigées pour satisfaire ces spécifications. Définition 9 (Implémentation de Composant) spécifie une structure interne en termes de sous-composants, de connexions entre les dispositifs de ces sous-composants, de flots à travers un ordonnancement des sous-composants, de modes (cf. 2.4) pour représenter les états opérationnels, et des propriétés. À la différence de beaucoup d'autres langages, AADL permet la déclaration de multiples implémentations avec la même interface fonctionnelle (type). La généralisation des composants est possible du fait que les types de composants et les composants d implémentation peuvent être exprimés comme des prolongements d'autres types de composants et implémentations de composants [14]. 32

33 Chapitre 1- Systèmes embarqués et temps-réel 3.Modélisation en AADL Figure Type de ports L'interface d'un composant est formée de ports de connexions représentant : le flot directionnel de données et/ou de contrôle à partir des données, des événements, et des données d'événement (figure1.6), des appels synchrones de sous-programme entre les threads, potentiellement situés sur différents processeurs et des accès concurrents aux données. Des connexions de ports de données peuvent être indiquées pour exécuter des communications immédiates au cours de la même période d'activation, ou des communications retardées pour que les données soient disponibles après la date limite du thread initial. Ces sémantiques assurent le transfert déterministe des flux de données entre les threads périodiques : c est une caractéristique importante pour les systèmes de contrôle embarqués. Le transfert déterministe signifie qu'un thread reçoit toujours des données avec le même temps de retard [14]. Cette norme définit les types de composants suivants : données, sous-programmes, threads, groupe de threads, processus, paquets, mémoires, bus, processeurs, dispositifs, et système. Ces types sont répartis en trois sous-catégories : Logicielle, Matérielle et Composite (figure1.7). Ils forment le noyau du vocabulaire de modélisation d'aadl. Figure Représentation graphique des composants AADL. 33

34 Chapitre 1 - Systèmes embarqués et temps-réel 3.Modélisation en AADL Composants Matériels Pour modéliser les plate-formes d'exécution, quatre catégories de composants sont proposées : processeur : abstraction du matériel et du logiciel qui est responsable d ordonnancer et d'exécuter des unités d'exécution concurrentes (thread) selon un protocole d ordonnancement spécifique et peut permettre la partition de l espace par des espaces d adresse protégés. mémoire : une abstraction du stockage physique accessible aléatoirement (RAM, ROM) qui peut contenir des données et / ou du code. bus : une abstraction de connecteur entre les composants de la plate-forme d exécution. dispositif (device) : une abstraction d'un composant actif (tels que capteur, actionneur, caméra,...) avec lequel un système d'application peut interagir et auquel un processeur peut accéder via un bus. Les composants de la plate-forme d'exécution peuvent représenter des composants de matériel ou des composants abstraits de plate-forme d'exécution, dont l implantation peut être réalisée par des machines virtuelles qui sont représentées par d'autres plate-formes d'exécution, avec des liens au matériel réel. Chaque catégorie de plate-forme d'exécution a un certain nombre de propriétés prédéfinies telles que le temps de changement de thread et de processus ou le protocole d ordonnancement des processeurs. Le noyau AADL prédéfinit de telles propriétés et un ensemble initial de valeurs de propriétés acceptables qui peut être étendu. Par exemple, de nouveaux protocoles d ordonnancement peuvent être présentés par un mécanisme d extension de propriété Composants Logiciels La modélisation du système d'application est réalisée à partir de deux groupes de catégories de composants. Le premier groupe se concentre sur le comportement de l'exécution d'un système et est composé de : 34 threads : unité de base d'exécution concurrente. groupes de threads : groupement structurel des threads dans un processus. Un groupe de threads peut contenir des données, des threads, et des sous-composants de groupe de threads. Il peut exiger et permettre d'accéder aux sous-composants de données. processus : unité d'espace d'adresse protégée. Il modélise des partitions de l'espace en termes d'espaces d adresses virtuelles contenant le texte source qui forme le programme complet comme défini dans un langage de programmation standard.

35 Chapitre 1- Systèmes embarqués et temps-réel 3.Modélisation en AADL Des threads sont contenus dans les processus et ont un ensemble de valeurs de propriétés prédéfinies de protocole d'activation ou un ensemble présenté par le mécanisme d extension de propriété. Les protocoles prédéfinis incluent des comportements périodiques, apériodiques, sporadiques, serveurs, et arrière-plan. Le deuxième groupe se concentre sur le texte source d'un système et se compose de: paquets : ils fournissent une structure de bibliothèque, un espace de nommage, pour organiser les composants d'implémentation et de type en espaces de noms séparés et les combiner dans des spécifications du système. En dehors de son paquet, un composant doit être qualifié par le nom du paquet qui le contient. composant données : données passives d'application qui représentent des types de données et les abstractions de classe dans le texte source nécessaire pour des modèles d'architecture. Le type de données est employé pour typer les ports, pour indiquer les types des paramètres des sous-programmes, et pour typer des instances de composants données. Le mécanisme d extension du type de composant peut modéliser le type héritage. Les caractéristiques des sous-programmes dans les types de composants peuvent représenter des méthodes de classe et ceux qui accèdent aux composants données déclarés partagés par un protocole spécifique de gestion des conflits. Les points d entrée d un sousprogramme sont définis dans l'interface du composant en tant que points d entrée «requis» ou «fourni» Composants Composites Une dernière catégorie de composant permet la composition hiérarchique et se compose de : système, unité dont les implémentations peuvent contenir des composants des plateformes d'exécution, des composants logiciels et d'autres instances de système LES MODES Les modes représentent des configurations alternatives de l implémentation du composant avec seulement un mode actif à la fois. Au niveau du système et du processus, un mode représente les recouvrements probables des (sous)-ensembles des threads actifs et des ports de connexions et des configurations alternatives des composants de la plate-forme d'exécution, aussi bien que les liens alternatifs des composants d'application aux composants de plateforme d'exécution. Le comportement du changement de mode est représenté par un diagramme d état / transition dont les états sont les modes et les transitions sont déclenchées par des événements. Ainsi, AADL peut modéliser le comportement changeant dynamiquement des topologies statiquement connues, des ports de communication et des threads, liées aux topologies statiquement connues des plate-formes d'exécution. 35

36 Chapitre 1 - Systèmes embarqués et temps-réel 3.Modélisation en AADL Des modes peuvent également être déclarés pour des composants de texte source. Ceci permet à des valeurs de propriétés spécifiques à des modes d'être déclarées dans les situations où l'architecture de thread et de raccordement ne change pas, mais le comportement interne du thread change. Par exemple, il peut y avoir des différents temps d'exécution pour le pire cas sous différents modes. Une modélisation plus détaillée des systèmes d'application permet des analyses moins conservatrices telle que l'analyse de l ordonnancement [14] LES PROPRIÉTÉS Les composants, les modes, et les connexions peuvent avoir des propriétés. Une propriété a un nom, un type et une valeur. Des propriétés sont employées pour représenter des attributs et d'autres caractéristiques, telles que la période et la date limite des threads. Quand des propriétés sont associées aux déclarations des types de composants, des composants d implémentation, des sous-composants, des connexions, des flots, et des modes, elles s'appliquent à toutes les instances respectives dans une instance système. Les propriétés peuvent avoir des valeurs spécifiques mode et spécifiques lien. Cette norme définit un ensemble de propriétés pré-déclarées et des types de propriétés. Des propriétés et des types de propriétés supplémentaires peuvent être introduits à travers les ensembles de propriétés pour soutenir de nouvelles formes d'analyse du système. Des valeurs de propriétés peuvent être associées aux types de composants, aux composants d implémentation, aux sous-composants, aux flots, aux connexions, aux modes, et aux appels de sous-programme. Par exemple, une propriété est employée pour identifier les fichiers de code source liés à un composant logiciel. Des propriétés sont également employées pour indiquer le nombre et la taille des endroits de stockage accessibles dans un composant mémoire. 4. CONCLUSION Nous avons défini dans ce chapitre un système temps-réel embarqué et nous avons expliqué ses différentes caractéristiques. Nous avons aussi introduit la notion d'ordonnancement temps-réel et la génération d'ordonnancement suivant les algorithmes d'ordonnancements les plus utilisés. Pour mieux comprendre ces notions nous, présenterons dans le chapitre suivant une application temps-réel embarquée et les différentes caractéristiques temps-réel de ces tâches qui vont nous permettre de la modéliser en AADL et utiliser ce modèle pour générer des ordonnancements de ces tâches. 36

37 CHAPITRE 2 PAPABENCH : UN BENCHMARK TEMPS-RÉEL Les systèmes temps-réel embarqués sont largement utilisés dans la société moderne. Ces systèmes sont formés essentiellement de tâches temps-réel qui doivent respecter des contraintes temporelles. Pour évaluer le respect des contraintes temporelles, il est nécessaire de connaître le WCET d'un programme s'exécutant sur un système matériel donné. La connaissance du WCET des tâches peut être utile dans la conception d un système temps-réel que ce soit au niveau matériel ou au niveau de l application. Comme tout logiciel, le calcul du WCET nécessite des expérimentations, des évaluations et des comparaisons. Pour réaliser cet objectif, nous introduisons dans ce chapitre un benchmark temps-réel, PapaBench, décrivant une application temps-réel complète pour le pilotage d'un drone ou UAV (Unmanned Aerial Vehicles). Il a été conçu afin de constituer une base utile pour les expérimentations de calcul de WCET par méthodes statiques ou dynamiques, il peut être aussi utile pour les analyses d'ordonnancement. Ce benchmark fournit des tâches et des interruptions concrètes avec des contraintes temporelles et des règles de précédence. L'utilisation de ce benchmark va contribuer à l'obtention de résultats expérimentaux plus réalistes que ceux obtenus avec les benchmarks courants [19], [20], [21] vu que les tâches à analyser sont proches de celles s'exécutant dans les systèmes-réels de l'avionique. Nous commençons ce chapitre par une brève description du projet de drone léger Paparazzi où nous présentons l'architecture et le fonctionnement de ces différents composants. Nous introduisons dans la deuxième section la première version PapaBench1, créée en gardant la même liste de tâches que Paparazzi. Nous fournissons une description AADL de PapaBench1 qui énumère les différentes tâches, leurs contraintes temps-réel et leurs règles de précédence. Les limitations de cette version sont expliquées à la section 3 et la deuxième version PapaBench2 est présentée à la section 4. Nous comparons notre benchmark aux autres benchmark temps-réel et nous fournissons des indications pour son utilisation dans les sections restantes. 37

38 Chapitre 2 - Papabench : un benchmark temps-réel 1.Le projet Paparazzi 1. LE PROJET PAPARAZZI Le terme "drone" est aujourd'hui largement utilisé pour désigner un "aéronef sans pilote", quelles que soient sa taille, sa forme, sa fonction et ses caractéristiques. Les engins non récupérables comme les fusées et les missiles ne sont pas, en général, classés parmi les drones. Définition 14 (Drone) On retiendra la définition anglo-saxonne qui désigne par drone un aéronef sans pilote opéré par radio-commande. On peut ainsi noter qu'un drone est contrôlé et donc pas complètement autonome, il n'est pas nécessairement contrôlé du sol et peut transporter des passagers. Le projet Paparazzi [22], conçu en 2003 par P. Brisset et A. Drouin, est une tentative de réalisation d'un mini-drone à bas coût, avec les objectifs principaux suivants : utilisation des technologies d'aéromodélisme, en particulier en utilisant du matériel grand public ; développement d'un pilote automatique, logiciel et matériel, permettant au drone d'être complètement autonome, pour se maintenir en vol et pour effectuer une «mission» prédéterminée ; réalisation d'un environnement de développement complet permettant d'installer simplement le système sur des aéronefs variés ; développement d'une station sol de contrôle et de suivi de vol. Ce projet propose du code ouvert. L'ensemble des travaux est livré avec la licence GNU qui permet la réutilisation tout en protégeant les auteurs originaux HISTORIQUE L objectif initial du système Paparazzi était de participer au concours de vol autonome des journées Micro-Drones Supaéro / Ensica. L épreuve consistait à réaliser une mission: «repérer une cible au sol et en donner la position». La fonction initiale d un drone est le vol. Le premier objectif était de choisir un aéronef qui vole bien, naturellement stable et facile à piloter. Le choix s est porté sur le Twinstar Multiplex, un bimoteur à ailes hautes, de vitesse 10m /s et de poids 1.4 Kg, destiné aux débutants en aéromodélisme. Le contrôle du drone nécessite un lien bidirectionnel avec le pilote. Le lien descendant est donc très important pour assurer la surveillance des systèmes embarqués. La mise au point de ce lien descendant était l une des premières tâches du projet. Le lien montant est constitué de la radio-commande. 38

39 Chapitre 2- Papabench : un benchmark temps-réel 1.Le projet Paparazzi La première idée était d utiliser un GPS, avec le Twinstar, comme unique capteur pour naviguer et d un module de stabilisation qui permet de conserver l avion dans le plan de l horizon grâce à des capteurs infrarouges. Pour simplifier au maximum le système embarqué, l idée était de transmettre les informations de positions au sol, d effectuer les calculs de navigation dans le calculateur (ordinateur portable) au sol et piloter en connectant cet ordinateur à la radio-commande. Une deuxième étape a consisté à développer le matériel embarqué pour le pilotage embarqué. Une architecture à deux processeurs a été adoptée pour séparer la partie gérant la réception de la radio-commande de la partie pilote automatique. En implémentant différents processus de contrôle, les trajectoires obtenues étaient autonomes et correctes tout en conservant un décollage et un atterrissage manuels. Une mini caméra vidéo couleur a été ajoutée et le Twinstar ainsi équipé a remporté en septembre 2003 le trophée vol autonome des Journées MicroDrones. Des outils de configuration ont été développés. Le logiciel, de la station au sol et la radio-commande ont été largement ré-écrits pour les rendre paramétrables. Les configurations ont été simplifiées à travers l usage d interfaces graphiques. Ces efforts ont été faits pour des utilisateurs sans connaissance importante en informatique. L étape suivante du projet était de choisir un drone plus petit tout en respectant les contraintes : facilité de mise en œuvre et qualité de vol. Le Microjet de Multiplex a été choisi et, à cette occasion, la carte de contrôle a été aussi miniaturisée. Cette configuration a remportée en juillet 2004 l épreuve de vol autonome d'emav en Aujourd hui la fiabilité du système Paparazzi permet de réaliser des missions de plusieurs kilomètres complètement automatiquement, la mission étant spécifiée par un langage de haut niveau. Le décollage est dorénavant entièrement automatique LES COMPOSANTS DU SYSTÈME PAPARAZZI Le système Paparazzi actuel permet de développer un système complet, matériel et logiciel, qui peut être embarqué sur plusieurs aéronefs. Un tel système a une autonomie limitée de 2 à 5 Kg de poids total, une distance de vol maximale de 25 km, une durée de vol d'une heure, une vitesse maximale de 50 Km/h et 500g maximum de charge utile. Paparazzi est constitué d un système embarqué et d une station de contrôle (voir figure2.1). Le système embarqué comporte, en plus des éléments classiques d'un aéro-modèle (récepteur, servo-commandes et batterie), une carte de contrôle avec son alimentation, un récepteur GPS, un quadruple capteur infrarouge et un émetteur radio. La carte de contrôle regroupe deux microcontrôleur RISC ATMEL AVR [23]. MCU1 (microcontrôleur ATMega8, appelé Fly_by_wire) est caractérisé par un processeur à 16 Mhz / 16 MIPS, d'une RAM statique de 1 KO, d'une mémoire flash de 8KO et d'une mémoire EEPROM de 512 octets. Il 39

40 Chapitre 2 - Papabench : un benchmark temps-réel 1.Le projet Paparazzi gère la radio-commande et les commandes de vols. MCU0 (microcontrôleur ATMega128, appelé Autopilot) est doté d'un processeur 16 MHz / 16 MIPS, d'une RAM statique de 4 KO, d'une mémoire flash de 128 KO et d'une EEPROM de 4 KO. Il gère la stabilisation, la navigation, le lien descendant, et un modem connecté au canal radio de l'émetteur pour le lien descendant. Les deux microcontrôleurs communiquent via un lien SPI série dans un mode Maître (MCU0) / Esclave (MCU1). MCU0 demande à MCU1 les informations reçues de la radio-commande et envoie en retour les commandes de vol stabilisées. Figure Le système Paparazzi. La station de contrôle est constituée d'une radio-commande traditionnelle, d'un récepteur radio et d'un ordinateur. Les canaux audio et vidéo du récepteur sont respectivement connectés à l'ordinateur (via un modem) et à un magnétoscope. L'ordinateur reçoit les informations du lien descendant et diverses interfaces permettent de les afficher. Tous les messages envoyés par le drone sont stockés dans un journal qui peut être rejoué ultérieurement Fonctionnement du microcontrôleur MCU1 (Fly by wire) Le code de MCU1 est très réduit et évolue très peu. MCU1 a trois modes de fonctionnement : Manuel : les ordres reçus de la radio-commande sont interprétés directement comme des commandes de vol. C'est le fonctionnement d'un aéro-modèle standard. 40

41 Chapitre 2- Papabench : un benchmark temps-réel 1.Le projet Paparazzi Automatique : Les commandes de vol sont envoyées par MCU0. Ce mode est enclenché sur ordre de la radio-commande et persiste uniquement si MCU0 envoie régulièrement des consignes. Il y a également passage du mode Manuel au mode Automatique si la réception de la radio-commande est rompue. Failsafe : MCU1 commute dans ce mode si aucun ordre n'est reçu ni de la radio-commande, ni de MCU0. Les gouvernes sont alors mises au neutre (pour planer) et le moteur arrêté Fonctionnement du microcontroleur MCU0 (Autopilote) Le cœur du pilote automatique réside dans le microcontrôleur MCU0. Celui-ci gère trois modes de fonctionnement principaux (figure 2.3) : Manuel : les ordres reçus de la radio-commande sont utilisés comme entrées pour la boucle de stabilisation. Ainsi le pilote ne commande pas les ailerons et la gouverne de profondeur mais les angles de roulis et de tangage. Ce mode permet de tester le contrôleur d attitude seul, l'attitude étant l'orientation autour du centre de gravité autrement dit ses coordonnées. Le contrôleur assure que l avion reste dans son domaine de vol. Figure Axes de roulis et de tangage La figure 2.2 montre les trois axes de repère pour le pilotage d'un avion qui se coupent en son centre de gravité (axe de roulis en rouge, axe de tangage en bleu et l'axe de lacet en vert). Le tangage est le mouvement de rotation autour de l'axe de tangage et le roulis représente l'oscillation autour de l'axe de roulis. Automatique : les consignes envoyées au contrôleur d attitude et à la propulsion sont calculées à partir de la route et de l altitude voulues. La route et l altitude sont 41

42 Chapitre 2 - Papabench : un benchmark temps-réel 1.Le projet Paparazzi elles mêmes calculées pour suivre la mission (essentiellement une suite de points de report). Dans ce mode, trois boucles de contrôle sont donc empilées. La stabilisation est réalisée à 20Hz et la navigation à la fréquence des informations délivrées par le GPS (4Hz). La mission est également contrôlée à 20Hz car elle doit pouvoir prendre en compte des événements exceptionnels (ordre de la radio-commande, temps de vol, tension de la batterie,...) Home (retour à la maison) : il s agit d un mode de navigation basique où l avion doit revenir à la balise HOME de la mission (son point de départ sauf exception) en visant une altitude de sécurité. Ce mode est enclenché si le lien montant est rompu en mode Manuel ou dans tous les cas si une distance de sécurité au point de route HOME est dépassée. Figure Fonctionnement de MCU0 en pilotage manuel assisté et automatique La stabilisation est assurée grâce aux capteurs infrarouges. Le contrôle de la trajectoire repose uniquement sur les informations fournies par le GPS, en taux de montée et en route. Pour le contrôle latéral, une consigne d'inclinaison est calculée à partir de l'erreur de route. La même solution est utilisée pour le contrôle longitudinal, avec une consigne constante. Le contrôle du taux de montée s'effectue uniquement avec le gaz. 2. PAPABENCH1 Cette section introduit la première version du benchmark [24]. Elle décrit la liste des tâches du modèle ainsi que leurs contraintes temporelles et fournit un graphe d'appel de fonctions pour lier le modèle aux sources C. 42

43 Chapitre 2- Papabench : un benchmark temps-réel 2.Papabench MODÈLE AADL Le document [22] contient un rapport complet du projet paparazzi décrivant plusieurs niveaux de contrôle et les contraintes temporelles correspondantes. En se basant sur cette référence et, après avoir analysé les sources C, nous avons identifié une liste de tâches ainsi que leurs règles de précédences. Nous avons aussi défini une liste d'interruptions générées par les transmissions d'information entre les différents dispositifs du système. Les tables (a) et (b) de la figure 2.4 affichent les tâches et les interruptions exécutées par MCU1 et MCU0 respectivement. Elles fournissent, pour chaque tâche, un identificateur utilisé dans les paragraphes suivants, une description et la fréquence d'exécution. ID Description Fréquence T6 Gestion des Ordres de la Radio 40Hz ID Description Fréquence T7 Stabilisation 20Hz T1 Réception Ordres de la Radio-Commande 40Hz T8 Envoi Données à MCU1 20Hz T2 Envoi Données à MCU0 40Hz T9 Réception Données GPS 4Hz T3 Reception Données de MCU0 20Hz T10 Navigation 4Hz T4 Transmission Servos 20Hz T11 Contrôle Altitude 4Hz T5 Check Failsafe 20Hz T12 Contrôle de Montée 4Hz I1 Interruption Servos 20Hz T13 Envoi Rapport au sol 10Hz I2 Interruption SPI 20Hz I4 Interruption SPI 20Hz I3 Interruption Radio 40Hz I5 Interruption Modem 10Hz I6 Interruption GPS 4Hz Figure Tâches et interruptions de MCU1 (a) et MCU0(b) Les graphes des figures 2.5 et 2.6 montrent les règles de précédence qui induisent un certain ordre d'exécution entre les tâches pour le mode manuel et le mode automatique respectivement. Cet ordre est dû à des dépendances de données (flèches marquées 1) ou à des dépendances de contrôle (flèches marquées 2). Ces règles de précédences sont les contraintes minimales pour la génération d'un ordonnancement correct de l'application. Ces règles sont dues au fait que les tâches s'exécutent à la même fréquence. Il faut noter que les sources C originales introduisent un ensemble de dépendances de contrôles trop fortes par rapport aux besoins réels de l'application. Nous avons pu supprimer les fausses dépendances de contrôle grâce à une fructueuse collaboration avec les auteurs de Paparazzi. Dans chaque graphe, est indiqué pour chaque microcontrôleur la liste des tâches qui s'exécutent dans chaque mode de fonctionnement. L'ajout et la suppression des règles de précédence est possible en AADL car nous pouvons ainsi redéfinir ces ensembles de règles selon nos besoins expérimentaux. 43

44 Chapitre 2 - Papabench : un benchmark temps-réel 2.Papabench1 Alors que MCU1 reçoit les ordres de la radio et transmet ces données à MCU0, nous pouvons par exemple imaginer un scénario en mode manuel où nous ajoutons les dépendances suivantes à celles indiquées dans le graphe 2.5 pour les couples de tâches [(I3, T1), (T2, I2), (T4, I1)]. D'autre part, pour MCU0 nous ajoutons d'autres dépendances pour les couples [(T6, T7),(T7, T8)]. Le mode automatique est activé sur ordre de la radio-commande ou quand cette dernière n'est plus accessible. AADL fournit les «modes» pour décrire le mode opérationnel du système. La variation du mode opérationnel est déclenchée par l'arrivée d'un événement. D'autre part, comme en mode automatique, T9, T10, T11 et T12 s'exécutent à la même fréquence et accèdent aux mêmes variables globales du code, ces tâches s'exécutent avec les dépendances fournies dans le graphe 2.6. Nous pouvons aussi ajouter une dépendance de contrôle entre I6 et T9 pour la même raison. Nous pouvons même changer l'ordre des dépendances et avoir ainsi plusieurs cas possibles [T9,T11, T12, T10], [T11, T12, T10, T9]... Figure Graphe de dépendances Mode Manuel Figure Dépendances du Mode Automatique Au niveau matériel, le système Paparazzi possède deux sous-systèmes, un pour chaque microcontrôleur. Chaque sous-système décrit le processus d'exécution comme un ensemble de threads et de dispositifs ainsi que leurs interactions. 44

45 Chapitre 2- Papabench : un benchmark temps-réel 2.Papabench LIEN AVEC LE MODÈLE AADL Dans le cadre du projet OTAWA [25], [26], un framework pour expérimenter le calcul du WCET et les analyses statiques du code binaire, nous avons développé un programme permettant de générer le graphe d'appel (Program Call Graph ou PCG) d'un fichier exécutable et d'autres statistiques du binaire. Le PCG fournit une idée générale de la complexité de l'application et permet de connaître l'enchaînement des appels de fonctions sans se référer aux sources. Il fournit aussi un lien entre les tâches de l'analyse et le code correspondant dans les sources. Le PCG de Fly_By_Wire et d'autopilot sont présentés dans les figures 2.7.a et 2.7.b respectivement. Les ellipses colorées représentent les implantations des tâches dans le code source. Le nom de la tâche est marqué dans les étiquettes noires. Dans Autopilot, T7 est formée de la fonction course_pid_run et de nav_home si le système est en mode failsafe, ou bien course_pid_run et nav_update s'il est en mode automatique. Les ellipses pointillées indiquent les interruptions se produisant lors de l'exécution des tâches. On peut remarquer des sous programmes n'appartenant à aucune tâche : en effet, ils sont exécutés au démarrage et ils n'interviennent plus dans le fonctionnement du système pendant toute la durée du vol. Figure PCG de Fly_by_wire (a) et de l'autopilot (b) COMPLEXITÉ DES VARIABLES En AADL, chaque type de composant peut être détaillé par un ensemble de propriétés. Pour inclure les contraintes temporelles dans notre modèle, nous avons ajouté pour chaque thread les propriétés period et Dispatch_Protocol qui peuvent être périodique, apériodique ou 45

46 Chapitre 2 - Papabench : un benchmark temps-réel 2.Papabench1 sporadique. Une tâche apériodique survient à des intervalles de temps arbitraires et peut être retardée pour un laps de temps limité. Au contraire, une tâche sporadique s'exécute à des intervalles de temps arbitraires mais avec une période minimum ou maximum entre deux exécutions consécutives. Pour Paparazzi, les entrées / sorties sont gérées comme des interruptions apériodiques. Généralement, les logiciels avioniques ne supportent pas des interruptions car leur WCET ne peut être calculé de manière précise avec les techniques actuelles. Toutefois, nous ne sommes pas obligés de suivre l'ordonnancement statique fourni par le code C de Paparazzi. On peut considérer le modèle AADL, ses tâches (y compris les interruptions) et le code correspondant dans les sources C, mais plusieurs ordonnancements et contraintes temporelles peuvent être expérimentées selon nos besoins. Ceci permet de définir plusieurs modèles AADL du plus simple au plus réaliste. On peut commencer l'analyse du WCET du système en considérant que les tâches et les interruptions sont périodiques, ce qui est le cas le plus simple pour le calcul du WCET. On peut ensuite considérer toutes les valeurs possibles de la propriété Dispatch_Protocol pour considérer des cas plus complexes et peut-être même analyser le cas de l'application réelle où les interruptions sont apériodiques et les tâches ne sont pas forcément périodiques. Il est également possible d'étudier la préemption entre les tâches. Pour cela, nous avons ajouté une nouvelle propriété Preemption applicable seulement aux threads qui précise la nature de la préemption qui peut être «System_Preemption» ou «Time_Sharing_Preemption». On dispose aussi de la valeur «Non_Preemptive» pour distinguer les tâches préemptives des non préemptives. Avec cette propriété, il est encore possible d'augmenter la complexité du modèle à analyser REPRÉSENTATION GRAPHIQUE DE PAPARAZZI Dans ce paragraphe, nous montrons la représentation graphique de Paparazzi, suivant la notation graphique d'aadl. Figure Le système embarqué de Paparazzi. Ce modèle graphique contient toutes les tâches et les interruptions, définies par des 46

47 Chapitre 2- Papabench : un benchmark temps-réel 2.Papabench1 threads, ainsi que les composants matériels du système. Les ports et leurs connexions sont visibles sur les schémas avec distinction des connexions spécifiques caractérisant certains modes de fonctionnement du système. Le système embarqué Paparazzi est formé de deux sous-systèmes Fly_By_Wire (MCU1) et Autopilot (MCU0) reliés par un lien série SPI et communiquant à travers des ports données événements (figure 2.8). Les composants des systèmes MCU1 et MCU0, ainsi que leurs connexions sont indiqués dans les figures 2.9 et 2.10 respectivement. Figure Représentation graphique du système MCU1 Figure Représentation graphique du système MCU0 47