CONSERVATOIRE NATIONAL DES ARTS ET METIERS PARIS

CONSERVATOIRE NATIONAL DES ARTS ET METIERS PARIS MEMOIRE pour l examen probatoire du CNAM en INFORMATIQUE L ordonnancement temps réel des tâches et des messages Laurent Dehoey Soutenance : mai 2004 JURY : Président : Professeur C. Kaiser

Introduction...3 1 Ordonnancement temps réel (TR)... 4 1.1 Contraintes temporelles... 4 1.2 Modèle de tâche... 4 1.3 Définitions, propriétés... 5 1.3.1 Ordonnanceurs hors ligne / en ligne... 5 1.3.2 Configuration de tâches (CT) («task sets»)... 5 1.3.3 Ordonnançabilité... 6 1.4 Algorithmes de base pour tâches périodiques... 6 1.4.1 Rate Monotonic (RM)... 6 1.4.2 Deadline Monotonic (DM) ou Inverse Deadline (ID)... 7 1.4.3 Earliest Deadline First (EDF)... 7 1.4.4 Least Laxity First (LLF)... 7 1.5 Prise en compte des tâches non périodiques... 7 1.5.1 Tâches sporadiques... 8 1.5.2 Tâches apériodiques... 8 1.6 Ordonnancement de tâches et de messages interdépendants... 9 1.6.1 Contraintes de précédence... 9 1.6.2 Partage de ressources... 11 2 Ordonnancement temps réel distribué... 16 2.1 Placement des tâches et affectation des priorités... 16 2.2 Analyse holistique... 16 2.2.1 Ordonnancement conjoint des tâches et des messages... 17 2.2.2 Analyse holistique : Concepts de base... 18 2.2.3 Analyse holistique : Principes... 20 2.2.4 Cas pire - Pires temps de réponse... 21 2.2.5 Exemple d application : validation d un système TR distribué... 22 2.3 Placement et affectation des priorités : Etude de cas... 23 3 Middleware temps réel : RT-CORBA... 26 3.1 Middleware temps réel... 26 3.2 Introduction à CORBA... 26 3.3 CORBA temps réel (RT-CORBA)... 28 3.3.1 Architecture RT-CORBA... 28 3.3.2 Ordonnancement RT-CORBA... 31 3.3.3 TAO (The Ace ORB)... 33 3.3.4 Micro noyau ZEN... 34 Conclusion... 36 Bibliographie... 37 Glossaire/Abréviations... 38 Tables des illustrations... 39 Probatoire Ordonnancement temps réel des tâches et des messages 2

Introduction Les applications temps réel occupent de plus en plus de place parmi nos systèmes informatiques. Ces applications sont discrètes et ne font pas parler d elles tant qu elles fonctionnent correctement. Mais lorsque survient un problème, il est souvent la cause de conséquences graves ou médiatiques importantes. On pense aux centrales nucléaires, aux cracks boursiers, à la sonde martienne Pathfinder,... Le comportement exact et sûr de ces applications est directement relié à la maîtrise des contraintes temporelles des procédés physiques qu elles pilotent ou surveillent. Cette maîtrise passe par l ordonnancement temps réel des tâches et des messages, éléments de base logiques des applications. Le domaine complexe du temps réel a longtemps été confiné aux systèmes centralisés et monolithiques. Or les applications dans lesquelles l homme dépose sa confiance aujourd hui, sont de plus en plus imposantes et pour continuer à fonctionner correctement doivent se répartir, se distribuer, se délocaliser sur plusieurs sous systèmes. La conception de ces applications passe par des architectures multiprocesseurs au fonctionnement parallèle (fortement couplé) ou réparties à travers un réseau de communication. Le temps réel doit pouvoir utiliser et contrôler ces ressources nouvelles pour lui. Nous allons dans ce rapport étudier les possibilités et les limites des algorithmes classiques d ordonnancement temps réel, afin de comprendre comment il peut être possible d optimiser la conception et le contrôle des applications complexes réparties. Nous introduirons ensuite les problématiques de la validation d un système distribué, grâce à l analyse holistique, et celle de l affectation de priorités dans une architecture répartie. Une étude de cas dans l industrie automobile nous permettra d établir l utilité de méthodes automatiques de validation. Enfin, afin de faciliter le développement de ces nouvelles applications complexes, nous recenserons les plateformes distribuées qui offrent aux développeurs des services d ordonnancement temps réel, en particulier les extensions temps réel de CORBA et du langage java. Probatoire Ordonnancement temps réel des tâches et des messages 3

1 Ordonnancement temps réel (TR) «La validité d un système TR dépend de l exactitude des résultats qu il produit mais aussi de l instant de cette production : un résultat juste mais hors délai est un résultat inutilisable». Afin de comprendre la problématique de l ordonnancement temps réel dans les systèmes distribués et parallèles, nous allons dans cette première partie établir une terminologie, rappeler certains concepts et étudier le fonctionnement des principaux algorithmes classiques d ordonnancement TR de tâches et de messages dans les architectures centralisées. 1.1 Contraintes temporelles Les contraintes temporelles que le système TR doit supporter sont de deux natures : - strictes : les échéances ne doivent sous aucun prétexte êtres dépassées sous peine de conséquences graves pour l être humain ou le système lui même - relatives : les conséquences d un dépassement d échéance sont quantifiables et supportables pour le système dans une certaine mesure Le non respect de ces contraintes est appelé une faute temporelle. 1.2 Modèle de tâche La fonction d un algorithme d ordonnancement TR est de choisir la prochaine tâche à faire exécuter à un processeur. Ce choix se fait en prévoyance du respect dans un futur plus ou moins proche des contraintes temporelles. Pour cela il collecte des informations pertinentes sur les tâches qui composent l application. On distingue deux types de tâches : - Les tâches périodiques qui sont activées à intervalles réguliers - Les tâches non périodiques réparties en deux catégories : o Les tâches sporadiques à contraintes de temps strictes o Les tâches apériodiques à contraintes de temps relatives On définit pour une tâche périodique τ i, quatre paramètres temporels de base (cf. Figure 1.1): - r i : sa date d activation, ou de premier réveil. - C i : sa charge, la durée que le processeur doit lui consacrer pour la mener à terme. - D i : son délai critique, c est le temps qui est accordé à la τ i pour être exécutée. La date qu elle ne doit pas dépasser se nomme l échéance d i = r i +D i. Au-delà la tâche est en faute temporelle. - T i : sa période d activation On dérive de ces paramètres de base : - u i = C i /T i le facteur d utilisation du processeur par la tâche (u 1) - ch = C i /D i le facteur de charge du processeur (ch 1) - L=D i -C i Laxité nominale de la tâche. Le retard maximal pour son début d exécution Les paramètres dynamiques des tâches en fonction du temps t qui s écoule : - s i la date de début d exécution de la tâche (à ne pas confondre avec r i ) - e i la date de fin d exécution de la tâche - D i (t)=d i -t le délai critique résiduel à la date t : 0 D i (t) D i - C i (t) durée d exécution résiduelle à t : 0 C i (t) C i - L i (t)=d i (t)-c i (t) laxité nominale résiduelle. Notons que L i (t)=d i +r i -t-c i (t) - TR i = e i -r i le temps de réponse, on a 0 TR i D i quand la tâche n est pas en faute temporelle. Ce paramètre est important, nous le retrouverons au chapitre 1.6 - CH i (t)=c i (t)/d i (t) la charge résiduelle 0 CH i (t) u i CH(e i )=0 Probatoire Ordonnancement temps réel des tâches et des messages 4

C i + Activation Echéance Réactivation s i TR i e i Temps r i D i T i d i Figure 1.1 Modèle temporel d une tâche périodique Une tâche périodique est définie par sa notation : Tp(r i,c i,d i,t i ) Une tâche non périodique est définie par : Tap(r i,c i,d i ) 1.3 Définitions, propriétés 1.3.1 Ordonnanceurs hors ligne / en ligne - Un ordonnanceur hors ligne établit avant le lancement de l application une séquence fixe d exécution des tâches à partir de tous les paramètres de celles-ci. - Un ordonnanceur en ligne établit dynamiquement, avec ces mêmes paramètres, la séquence d exécution des tâches au fur et à mesure que surgissent les évènements au cours de l application : nouvelle tâche, dépassement d échéance, 1.3.2 Configuration de tâches (CT) («task sets») - On appelle configuration de tâche (CT) l ensemble des n tâches τ i qui constituent l application temps réel (ATR). - Les tâches sont dites à départ simultané si elles ont la même date de réveil r i. A départ échelonné sinon. - Le facteur d utilisation du processeur pour une CT de n tâches périodiques : n Ci U = i= 1 Ti - Le facteur de charge du processeur pour une CT de n tâches périodiques : n Ci CH = i= 1 Di - Laxité du processeur : LP(t) intervalle de temps pendant lequel le processeur peut rester inactif sans perdre le contrôle du respect des échéances. Pour tout t on doit avoir LP(t) 0. - Pour calculer cette laxité on a besoin de calculer la laxité conditionnelle de chaque tâche τ i LC ( t) = D i i 1 i j= 0 C ( t) où la somme en j se fait sur le temps d exécution de j Probatoire Ordonnancement temps réel des tâches et des messages 5

toutes les tâches qui sont devant la tâche i dans la séquence de planification considérée. On alors LP(t)=Min{LC i (t)} - Temps creux («processor idle time») : suite d intervalles de temps, dépendante de la configuration de tâches et de son ordonnancement, pendant laquelle LP(t) reste strictement positive 1.3.3 Ordonnançabilité - Séquence valide ou faisable: une séquence d ordonnancement de tâches calculée par un algorithme d ordonnancement est dite valide si toutes les tâches de la CT respectent leurs contraintes temporelles. - Configuration ordonnançable : une CT est dite ordonnançable si l on est sûr qu il existe au moins un algorithme capable de fournir une séquence valide. - Algorithme optimal / ordonnanceur optimal : les propriétés des CT du paragraphe 1.3.2 ci-dessus peuvent aider à choisir une politique d ordonnancement. Un ordonnanceur est optimal s il produit systématiquement une séquence valide pour toute configuration que l on sait ordonnançable. - Test d ordonnançabilité : ce test permet de vérifier qu une CT périodique pourra être transformée en une séquence valide par un ordonnanceur donné. - Test d acceptabilité ou de garantie : dans un ordonnancement en ligne, une nouvelle tâche pourra être ajoutée à une séquence déjà validée, si la nouvelle séquence est elle-même valide. L ordonnanceur peut pour ce choix se baser encore sur les propriétés des CT du paragraphe 1.3.2 ci-dessus. - Période d étude : pour une configuration de tâches périodiques, la séquence valide se répète de manière cyclique sur cette période o pour une configuration de tâches périodiques à départ simultané elle est égale à [0, PPCM(T i )] o pour une configuration de tâches périodiques i et apériodiques j à départ échelonné elle est égale à [Min(ri0), Max{ri0,(rj0+Dj)}+2*PPCM(Ti)] 1 1.4 Algorithmes de base pour tâches périodiques Il existe quatre grands algorithmes classiques d ordonnancement temps réel. Les deux premiers sont basés sur des priorités fixes, et utilisés dans les analyses d ordonnancement hors-ligne. Les deux suivants utilisent comme critère de priorité des caractéristiques dynamiques du modèle de tâche et sont utilisés pour les calculs d ordonnançabilité en ligne. 1.4.1 Rate Monotonic (RM) Les tâches à échéance sur requête (D i =T i ) aux périodes les plus courtes passent en premières Une condition suffisante pour le test d ordonnançabilité portant sur le facteur d utilisation du n Ci 1 / n) processeur n(2 1) i= 1 Ti Soient les trois tâches τ 1 (0, 20, 100, 100), τ 2 (0,40,150,150) et τ 3 (0,100,350,350) à échéance sur requête (cf Figure 1.2). La période d étude est PPCM(100, 150, 350)=2 2 *3*5 2 *7=2100 3 Ci 1/ 3) On a U 1 =0.2, U 2 =0.267, U 3 =0.286 et = 0.753 3(2 1) = 0. 780. La condition i= 1 Ti suffisante est vérifiée. Une séquence valide existe pour ordonnancer ces 3 tâches en respectant leurs échéances. 1 Plus Petit Commun Multiple Probatoire Ordonnancement temps réel des tâches et des messages 6

Figure 1.2 Exemple d ordonnancement Rate Monotonic Préemptif 1.4.2 Deadline Monotonic (DM) ou Inverse Deadline (ID) Les tâches aux délais critiques les plus courts passent en premières Une condition suffisante pour le test d ordonnançabilité porte sur le facteur de charge du n Ci 1/ n) processeur: n(2 1) i= 1 Di On remarque que si T i =D i on se retrouve à ordonnancer selon RM. 1.4.3 Earliest Deadline First (EDF) Les tâches à la plus proche échéance d i =(D i+ r i ) passent en premières Condition nécessaire et suffisante pour le test d ordonnançabilité de tâches périodiques à n Ci échéance sur requête : 1 i= 1 Ti n Ci Une condition suffisante pour des tâches quelconques (cf. paragraphe 1.5) : 1 D n Ci Une condition nécessaire pour des tâches quelconques (cf. paragraphe 2.2.2) : 1 T i= 1 i= 1 i i Figure 1.3 Exemple d ordonnancement EDF de tâches à échéance sur requête 1.4.4 Least Laxity First (LLF) Les tâches de plus petite laxité résiduelle passent en premières. Les séquences fournies par LLF sont identiques à EDF quand les priorités utilisées sont celles calculées au moment du réveil. L intérêt est alors de calculer pour chaque instant t la priorité des tâches en attente, mais alors on introduit des changements de contexte qui peuvent devenir non négligeables. 1.5 Prise en compte des tâches non périodiques Les applications temps réel peuvent avoir à prendre en compte des évènements non périodiques comme les alarmes ou les interventions de l opérateur. Ces tâches doivent être exécutées sans tarder car elles ont, comme les tâches périodiques, leurs propres échéances strictes ou relatives. Probatoire Ordonnancement temps réel des tâches et des messages 7

1.5.1 Tâches sporadiques Les deux algorithmes dynamiques vus au paragraphe 1.4 ci-dessus (EDF et LLF) peuvent être utilisés pour ordonnancer des combinaisons de tâches périodiques et non périodiques à contraintes strictes, car leur condition suffisante d ordonnançabilité ne fait pas intervenir la période mais le délai critique ou la laxité nominale (qui peut être obtenue à partir du délai critique): - Si l on connaît la borne supérieure d utilisation du processeur (C i ) on préféra LLF, car il favorise les tâches qui ont le moins de marge pour leur exécution. On le préférera donc pour des tâches sporadiques (contraintes strictes) - Si C i n est pas connue, le choix se portera alors sur EDF. Le respect des échéances n est alors plus assuré, en particulier quand le système est en surcharge. On le préférera pour des tâches apériodiques (contraintes relatives) Si les systèmes temps réel garantissent le respect des échéances aux tâches périodiques, ils doivent aussi pouvoir offrir aux tâches apériodiques (contraintes relatives) des temps de réponses minimaux (TR i= e i -r i ). Les algorithmes vus plus haut ne prennent pas en compte ce temps de réponse. 1.5.2 Tâches apériodiques Ce service de «Best Effort» offert aux tâches apériodiques peut être réalisé grâce aux mécanismes suivants : - Traitement d arrière-plan («background scheduling») - Serveurs de tâches : o Traitement par scrutation («polling server») o Serveur différé («deferrable server») o Serveur sporadique («sporadic server») - Slack Stealer («voleur négligent») L idée est d intégrer un processus périodique au système qui va se charger d ordonnancer les tâches apériodiques le plus judicieusement possible entre les tâches périodiques. Nous étudierons dans le cadre de ce mémoire le serveur sporadique (cf. Figure 1.4) Figure 1.4 Exemple d ordonnancement avec un serveur sporadique Probatoire Ordonnancement temps réel des tâches et des messages 8

1- L algorithme «Sporadic Server» créé une tâche périodique τ s, de capacité C s (sa charge dans le modèle de tâche) et de période T s, ordonnançable selon la méthode Rate Monotonic. La valeur de la période est choisie judicieusement pour que les tâches périodiques puissent s exécuter avec un niveau de priorité satisfaisant : T s =5 dans l exemple de la Figure 1.4, cette tâche est la plus prioritaire, les tâches apériodiques aussi, donc. 2- Cette capacité de traitement est utilisée pour traiter les tâches apériodiques qui arrivent dans le système. Au moment où le serveur épuise sa capacité de traitement, qui peut être comparée à la diminution progressive de la charge résiduelle du modèle de tâche C i (t), il calcule sa prochaine date de réveil comme la somme de la date à laquelle il était passé à l état «élu» (t=4, 10 et 15 dans la Figure 1.4, c est le «start time» s i du modèle de tâche,) avec sa période T s : r s,k+1 =s s,k +T s =4+5=9. 3- Au moment de son réveil (r s,k+1 ), il refait le plein de sa capacité C s. Si aucune tâche apériodique n est à ordonnancer, il se met en attente, et laisse sa place aux éventuelles tâches périodiques (t=0, 9). 4- Quand une ou plusieurs tâches apériodiques se présentent, il les exécute pendant l intervalle de temps, la capacité, la charge résiduelle, qui lui reste (t = [4,6] & [10,12]) 5- Si sa capacité est épuisée, alors qu il lui reste des tâches à exécuter, il est préempté, en ayant pris soin d avoir calculé sa prochaine date de réveil comme décrit au point 2. (t=12, r s,k+1 =s s,k +Ts=10+5=15) 6- Si sa capacité n est pas vide et qu il n a plus de tâche à exécuter, il se met en attente (t=16) pour une prochaine tâche apériodique en conservant son niveau de capacité. Nous avons vu que pour prendre en compte les tâches apériodiques on doit soit les transformer en pseudo tâches périodiques pour assurer un respect de leur échéance stricte sans trop se soucier de leur temps de réponse, soit créer une tâche périodique complexe qui se chargera de les exécuter en minimisant leur temps de réponse. On retrouvera cette problématique au chapitre 3.3.3. 1.6 Ordonnancement de tâches et de messages interdépendants Dans les paragraphes précédents, l ordre d exécution des tâches ne dépendait que de contraintes temporelles propres à chacune. Or quand le concepteur d une l ATR a prévu, par exemple, qu une tâche alarme se déclenche, c est pour que l ATR puissent réagir à la situation, c'est-à-dire en exécutant d autres tâches. On imagine mal ces tâches se déclencher avant l alarme, ou l alarme après ces tâches. D autre part le message envoyé par l alarme doit à un moment ou un autre être déposé dans un emplacement mémoire ou envoyé à travers un réseau ou un bus mémoire. Autant d «emplacements» pour lesquels on doit garantir à la tâche ou au message un accès exclusif. C est la problématique complexe, et récurrente dans tous les systèmes d informations évolués, des contraintes de précédence et du partage des ressources en exclusion mutuelle. Les ATR, avec le respect des contraintes temporelles, rajoutent des degrés de complexité croissants à cette problématique selon qu elles s exécutent dans un environnement centralisé, multiprocesseur ou réparti. 1.6.1 Contraintes de précédence On modélise les contraintes de précédence entre tâches par un graphe de précédence. Si une tâche j doit attendre la fin d une tâche i, noté τ i τ j, avant de s exécuter alors on doit avoir r j r i et Priorité i Priorité j en concordance avec l algorithme d ordonnancement utilisé. Nous considérerons dans un premier temps que des tâches liées entre elles s exécutent un même nombre de fois et que si l une est périodique les autres le sont aussi et avec T 0 =T 1 = =T n. Probatoire Ordonnancement temps réel des tâches et des messages 9

1.6.1.1 Ordonnancement RM La tâche prioritaire est celle de période minimale. Le but est alors de transformer, hors ligne, les paramètres des tâches liées par des contraintes de précédence en une configuration de tâches indépendantes pour laquelle on peut vérifier le test d ordonnançabilité. A la Figure 1.5 composée de deux graphes est une configuration de six tâches à départ simultané, on associe les priorités RM du Tableau 1-1 τ 1 τ 2 τ 3 Τ 6 τ 4 τ 5 Figure 1.5 Exemple de graphe de précédence τ 1 τ 2 τ 3 τ 4 τ 5 τ 6 6 5 4 3 2 1 Tableau 1-1 Priorités respectant les contraintes de la Figure 1.6 et celles de RM On modifie ensuite les dates de réveil de sorte que : r j * Max{r j,r i * } (où r i * est la date de réveil modifiée de τ i ). Dans cette configuration de tâches à départ simultané r i,0 n =0 1.6.1.2 Ordonnancement EDF Le but est le même que pour RM. Le paramètre à modifier en plus de r i est l échéance d i. La Figure 1.6 indique le principe des modifications à apporter aux paramètres des tâches : - r j * Max{( r i * +C i ), r j } la date de réveil de la tâche τ j est supérieure à toutes celles de ses prédécesseurs immédiats τ i, augmentées de leur durées d exécution C i. - d i * Min{(d j * -C j ), d i } l échéance de la tâche τ j est inférieure à toutes les échéances de ses successeurs immédiats τ i diminuées de leurs durées d exécution C i. Figure 1.6 Modification des paramètres de tâches dépendantes pour EDF On calcule r j * (r 2 * dans l exemple) en partant des tâches qui n ont pas de prédécesseurs : τ 1 On calcule d j * (d 2 * dans l exemple) en partant des tâches qui n ont pas de successeurs : τ 3 Probatoire Ordonnancement temps réel des tâches et des messages 10

1.6.1.3 Exemple de traitement de contraintes de précédence Soit cinq tâches τ 1, τ 2, τ 3, τ 4, τ 5 de périodes identiques liées entre elles selon le graphe de précédence de la Figure 1.7. Le Tableau 1-2 donne les transformations de leurs paramètres pour être ordonnançables selon RM et EDF τ 1 τ 3 τ 2 τ 4 τ 5 Figure 1.7 Graphe de précédence de cinq tâches d une application temps réel Paramètres des tâches RM EDF Tâche r i C i d i * r i Prio i * r i * d i τ 1 0 1 5 0 3 0 3 τ 2 5 2 7 5 4 5 7 τ 3 0 2 5 0 2 1 5 τ 4 0 1 10 5 1 7 9 τ 5 0 3 12 5 0 8 12 Tableau 1-2 Modifications des paramètres des tâches pour prendre en compte les contraintes de précédence On note que l affectation des priorités (4 est la priorité la plus forte) se fait en observant les précédences : Si on a τ i τ j alors Prio i Prio j S il semble simple à priori de déterminer ces priorités, et donc l ordonnancement quand les tâches ne partagent pas de ressources critiques, il en va tout autrement, quand par exemple, elles doivent s échanger des messages sur un réseau de communication. On peut alors considérer ce réseau comme une ressource critique que se partagent chacune des tâches en exclusion mutuelle, et dans laquelle elles déposent les messages. Cet angle de vue ne va pas sans poser de graves problèmes d ordonnancement. Il en existe un autre que nous étudierons au chapitre 2.2.4. 1.6.2 Partage de ressources Les deux risques encourus dans un système doté d un ordonnancement préemptif classique sont l inversion de priorité et l interblocage. Les ATR rajoute une contrainte : le prédictibilité des temps de réponse (cf. modèle de tâche page 4) 1.6.2.1 Calcul du pire temps de réponse Dans Figure 1.8 la tâche τ 1 de priorité plus faible que τ 2 s exécute en premier, elle demande la ressource R en exclusion mutuelle et l obtient. La tâche τ 2 se lance, et préempte tout de suite τ 1. Elle s exécute jusqu à sa demande de la ressource R, elle ne l obtient pas et se met en attente. τ 1 est élue jusqu à ce qu elle lâche R. τ 2 est à nouveau élue et continu son exécution en ayant obtenu la ressource R enfin libre. Probatoire Ordonnancement temps réel des tâches et des messages 11

Figure 1.8 Problématique de la prédictibilité du temps de réponse La question est, et c est la problématique du partage de ressources dans les systèmes temps réel distribués, que vaut TR 2 le temps de réponse de τ 2, et TR 1? Peut-on en fixer une borne supérieure et la respecter pour chacune des tâches? Si on peut répondre par l affirmative à cette question, alors oui la CT est ordonnançable sous réserve qu il n y a pas de phénomène d inversion de priorité, ni d interblocage. 1.6.2.1.1 Cas d une configuration de tâches indépendantes : Soit τ 0 une tâche dans une CT quelconque, si τ 0 est la plus prioritaire de toutes les tâches alors son pire temps de réponse TR 0 = C 0 son pire temps d exécution. Elle ne peut en effet pas être préemptée par définition. Si elle est par contre d une priorité intermédiaire, notons τ HPT l ensemble des tâches plus prioritaires que τ 0 alors : Pour un ensemble de tâches de même période ou apériodiques on a : TR + [Éq. 1-1] Pour un ensemble de tâches périodiques de périodes différentes on a : TR [Éq. 1-2] 0 C 0 0 C 0 C i i HPT + i HPT T 0 Ci Ti 1.6.2.1.2 Cas d une configuration de tâches partageant des ressources : Dans la Figure 1.8 le temps de réponse de la tâche τ 2, R 2 est la somme de son pire temps d exécution, C 2, et du facteur de blocage B 2 qui correspond au temps d utilisation de la ressource R par τ 1 : R 2 =C 2 +B 2. A partir de l exemple de la Figure 1.8, imaginons une autre combinaison : τ 1 se lance en premier et prend la ressource dès son début d exécution, et elle ne la relâchera qu à la fin de son exécution. τ 2 se lance tout de suite après τ 1 (r 1 +ε), et demande tout de suite aussi la ressource R. R étant déjà verrouillée par τ 1, τ 2 doit se mettre en attente pendant toute la durée d exécution de τ 1. On a B 2 =C 1 et donc TR 2 =C 2 +C 1. On montre d une manière générale que le pire temps de réponse TR 0 d une tâche τ 0, tâche la plus prioritaire d une ATR composée de n+1 tâches et de m ressources partagées avec la tâche τ 0, est donné par la relation : TR 0 C0 + Min(n, m) CR max [Éq. 1-3] On définit CR max comme suit : Soit CR i,q le temps maximal pendant lequel la tâche τ i utilise la ressource R q. CR max,q est le temps maximal pendant lequel la ressource R q est utilisée en exclusion mutuelle par une des tâches τ i et CR i,max le temps maximal qu une tâche τ i a passé en exclusion mutuelle avec une des ressource R q. Probatoire Ordonnancement temps réel des tâches et des messages 12

Prenons le cas maintenant d une tâche τ 0 de priorité intermédiaire. La CT est composée de n 1 tâches plus prioritaires que τ 0 (l ensemble HPT), de n 2 tâches moins prioritaires que τ 0, et toutes partagent m ressources en exclusion mutuelle avec τ 0. On donne un exemple avec n 1 =1, n 2 =2 et m=3 dans la Figure 1.9. Le pire temps de réponse TR 0 pour la tâche τ 0 est déduit des équations [Éq. 1-2] et [Éq. 1-3] : T0 TR 0 C 0 + Min( n2, m) CRmax + Ci i HPT Ti [Éq. 1-4] Figure 1.9 Pire temps de réponse d une tâche en partage de ressources critiques Or ce calcul, qui nous sert à vérifier que le système ne va pas commettre de faute temporelle, peut-être mis en défaut si l ordonnanceur interne à priorité fixe sous jacent ne respecte pas les spécifications implicites de départ : «une tâche τ 0 de priorité donnée, déclenchée à la date r 0, s exécute dès qu aucune tâche de priorité supérieure ne s exécute et dès qu aucune tâche de priorité inférieure n utilise plus une ressource critique dont τ 0 a besoin et que la tâche occupait à la date r 0». Cette mise en défaut à laquelle il faut absolument palier est le fait de l inversion de priorité et/ou de l interblocage 1.6.2.2 L inversion de priorité On rappel que le phénomène d inversion de priorité n est pas propre au temps réel. On en donne néanmoins un exemple Figure 1.10 et une méthode de résolution au paragraphe 1.6.2.4 afin de mettre au jour la problématique de l envoi de message dans un système distribué. Figure 1.10 Exemple d inversion de priorité Soit quatre tâches {τ 1, τ 2, τ 3, τ 4 } de priorité fixe décroissantes. Les tâches τ 2 et τ 4 se partagent en exclusion mutuelle la ressource critique R. On observe le temps de réponse de la tâche τ 2. Probatoire Ordonnancement temps réel des tâches et des messages 13

τ 4 s exécute, demande R et l obtient. τ 2 s exécute. τ 4 passe à l état «prêt» en détenant le verrou sur R. τ 2 ne demande pas tout de suite R. Pendant ce temps la tâche τ 3 lance sa requête d exécution. τ 3 moins prioritaire que τ 2 doit attendre : elle passe à l état «prêt». τ 2 demande alors la ressource R toujours détenue par τ 4. τ 2 doit s arrêter et attendre dans l état «bloqué». τ 3 qui est prête et plus prioritaire que τ 4, prête elle aussi néanmoins, s exécute. τ 1 plus prioritaire que τ 3 s exécute à son tour en préemptant τ 3 qui repasse à l état «prêt». τ 1 se termine. La prochaine tâche prête et prioritaire est τ 3, qui se termine enfin. τ 4 seule tâche prête s exécute et libère R en se terminant. τ 2 est débloquée et peut enfin s exécuter et se terminer. On vérifie bien que le pire temps de réponse de la tâche τ 2 dépend du temps d exécution en section critique des tâches moins prioritaires que τ 2 avec qui elle partage des ressources critiques, τ 4 ici, et du temps d exécution des tâches plus prioritaires que τ 2, τ 1 ici. Mais le temps d exécution de la tâche τ 3 vient ici se rajouter alors qu elle ne partage aucune ressource critique et qu elle est moins prioritaire que τ 2. L équation [Éq. 1-4] est mise en défaut ce qui implique que des fautes temporelles, non prévues, car on pensait avoir vérifié une condition suffisante, peuvent avoir lieu. 2 1.6.2.3 L interblocage L utilisation des ressources du système se fait souvent de manière imbriquée (cf. Figure 1.9). Supposons deux tâches τ 1 et τ 2 chacune ayant besoin de deux ressources critiques R 1 et R 2. τ 1 demande R 1 et l obtient. τ 2 se lance à son tour demande R 2 et l obtient. τ 2 demande ensuite R 1. τ 2 se bloque en attente de R 1 détenue par τ 1. τ 1 demande alors à son tour R 1 détenue par τ 2. τ 1 se bloque en attente de R 2. Les deux tâches sont en attente l une de l autre. C est l interblocage. Deux solutions existent pour prévenir l interblocage : - La méthode des classes ordonnées dans laquelle on programme le même ordre d attribution des ressources à toutes les tâches. C est une méthode statique qui se décide avant l exécution. - L algorithme du banquier est une méthode de prévention dynamique : une tâche avant de s exécuter précise au banquier toute les ressources dont elle aura besoin. Le banquier qui connaît toutes les tâches s exécutant et les ressources utilisables par elles, accepte ou pas les demandes de ressource au fur et à mesure qu elles lui arrivent. Dans notre cas τ 2 est bloquée dès sa demande de R 2 car le banquier sait que τ 1 va la lui demander. 1.6.2.4 Solutions à l inversion de priorité et à l interblocage Le protocole de la priorité plafonnée fournit une solution à l exemple de la Figure 1.10 ainsi qu au problème de l interblocage. Nous en rappelons le principe : - Inversion de priorité : Une tâche τ en section critique hérite de la priorité d une tâche τ souhaitant accéder à la même ressource si la priorité de τ est supérieure à celle de τ. τ récupère la priorité qu elle avait avant quand elle libère la ressource. C est le mécanisme d héritage de priorité simple. - Interblocage : On assigne à une ressource R la priorité la plus élevée des tâches qui en demanderont l accès exclusif. C est une valeur de seuil. On accorde cette ressource à une tâche qui en fait la demande, si la ressource est libre et si la priorité de cette tâche est supérieure à tous les seuils de toutes les ressources détenues par toutes des tâches en cours d exécution à ce moment là. 2 On pourra se référer à la littérature traitant des problèmes rencontrés par la sonde Pathfinder sur le sol martien, système distribué s il en est Probatoire Ordonnancement temps réel des tâches et des messages 14

L implémentation du mécanisme d héritage de priorité dans un système temps réel permet de pouvoir utiliser [Éq. 1-4] pour un test d ordonnançabilité (cf. Figure 1.11), solution qui permet aussi de borner le temps de blocage Bi, sur l attente d une ressource, d une tâche. Figure 1.11 Résolution de l inversion de priorité par le mécanisme de l héritage de priorité Mais ce mécanisme d héritage de priorité plafonnée est mis en échec quand les tâches s exécutent sur un système multiprocesseur : si τ 1, τ 3 et τ 4 s exécutent sur un processeur P 1, et la tâche τ 2 sur un processeur P 2, P 2 ne pourra pas modifier la priorité de τ 4 sans introduire de grave disfonctionnement sur le processeur P 1. Le phénomène d inversion de priorité sur l accès à une ressource critique devra être résolu autrement sur ces architectures parallèles et distribuées. De plus ces mécanismes généraux de protection sont gourmands en temps de calcul : il n est pas toujours possible de les implanter dans des systèmes embarqués aux ressources limitées. C est le cas notamment dans les systèmes temps réel utilisés dans l industrie automobile : les problèmes d inversion de priorité perdurant, les choix des priorités se feront alors à l aide d ordonnanceurs hors ligne. Dans ce premier chapitre nous avons acquis les connaissances préalables à la compréhension d une méthode originale pour ordonnancer les tâches et les messages dans un environnement temps réel distribué : l analyse holistique. Probatoire Ordonnancement temps réel des tâches et des messages 15

2 Ordonnancement temps réel distribué Dans un système temps réel distribué, le réseau est l unique moyen de communiquer entre les processeurs distants. Il devient une ressource que les tâches doivent se partager. On doit alors en plus de l ordonnancement, c'est-à-dire l affectation de priorités aux tâches, résoudre des problèmes non soupçonnés dans les architectures TR monoprocesseurs : - le placement des tâches sur les processeurs - la migration d une tâche vers un autre processeur - la synchronisation des tâches distribuées entre elles - les protocoles d accès aux ressources partagées distribuées Autant de contraintes qui vont fortement influer sur les performances du système. 2.1 Placement des tâches et affectation des priorités Lorsque on conçoit un système distribué temps réel sa structure logicielle est fortement dépendante de sa structure matérielle. A la différence de la problématique étudiée tout au long du chapitre précédent, l ordonnancement des tâches ne dépend plus uniquement des caractéristiques temporelles de ces tâches, mais aussi de leurs répartitions sur les différents processeurs, locaux ou distants, ainsi que des caractéristiques du réseau de communication à travers lequel elles s échangent des messages. Le choix des fonctions, les tâches, attribuées aux différents sous-systèmes va alors totalement «impacter» les procédures de validation temporelle. Or si cette étape de validation échoue, c'est-à-dire qu on ne trouve pas d ordonnancement valide, il faudra repenser l architecture logicielle pour ensuite la revalider Cette procédure itérative est longue et fastidieuse. On pourrait souhaiter qu à partir d une configuration logicielle établie grossièrement, un processus accomplisse cette procédure itérative et, tout en affinant le système, établisse les priorités des tâches et des messages qui garantiront le respect des contraintes temporelles. Ce processus, «branch and bound», existe mais son étude sort du cadre de ce mémoire. Nous donnons néanmoins un exemple de son application dans un système embarqué d une automobile en fin de chapitre Nous présenterons la méthode de validation temporelle utilisée lors des étapes itératives de ce processus. Cette méthode, l analyse holistique, peut être sortie de son cadre et servir à valider tout système temps réel distribué dans lequel les tâches seraient déjà placées et les priorités déjà affectées. C est une analyse hors ligne. 2.2 Analyse holistique 3 Les algorithmes d ordonnancement des systèmes d exploitation temps réel qui supportent les applications de l industrie sont en général des ordonnanceurs en ligne basés sur les 3 relatif à l holisme nom masculin (du gr. holos, entier) [PHILOS. ] En épistémologie ou en sciences humaines, doctrine qui ramène la connaissance du particulier, de l'individuel à celle de l'ensemble, du tout dans lequel il s'inscrit. 3 Probatoire Ordonnancement temps réel des tâches et des messages 16

algorithmes à priorité fixe (RM), ou dynamique selon l échéance la plus proche (EDF). L analyse holistique est capable de valider des ordonnancements sur ces architectures hétérogènes. Il s agit alors de montrer qu un ordonnancement est valide si le temps de réponse de toutes les tâches dont une tâche τ i doit attendre la fin d exécution pour s activer, est inférieur à la date d activation s i maximale de τ i. Ceci pour lui permettre de respecter son échéance d i. Cela correspond à chercher le «pire cas» d exécution de ces tâches et à ne pas lancer τ i avant que ce pire temps d exécution ne soit terminé. Nous l avons vu (cf. chapitre 1.2 ), un ordonnancement est valide si le temps de réponse de chacune des tâches est inférieur à son délai critique (TR i D i ). 2.2.1 Ordonnancement conjoint des tâches et des messages. 2.2.1.1 Réseau, ressource critique Si le réseau du système est vu comme une ressource critique partagé par toutes les tâches, la transmission d un message peut engendrer un phénomène d inversion de priorité comme on l a compris au chapitre 1.6.2.2. La transmission d un message quelconque ne peut en effet être interrompue par l émission d un message prioritaire. 2.2.1.2 Pire temps d exécution On ne connaît pas le temps exact d exécution des tâches, mais seulement le pire temps d exécution (C i ). La Figure 2.1 met en évidence le cas d une tâche qui s exécute plus vite que prévu, bloquant l envoi d un message plus prioritaire ce qui provoque une faute temporelle. τ 1 émet le message m 1 à l attention τ 3 et τ 2 le message m 2 à l attention de τ 4. Figure 2.1 Ordonnancement d une configuration de tâches distribuée Dans le cas a) les tâches s exécutent avec leurs pires temps d exécution et respectent leurs échéances. Dans le cas b) τ 2 s exécute plus vite et envoie son message avant le message de τ 1 qui doit attendre. τ 3 reçoit le message trop tard et provoque une faute temporelle. Probatoire Ordonnancement temps réel des tâches et des messages 17

Pour valider un ordonnancement il faut trouver cette borne supérieure d exécution des tâches pour en déduire la valeur du pire temps de réponse de chacune des tâches. L ordonnanceur pour ces calculs prévoit de n activer une tâche qu après le pire temps d exécution des autres tâches la devançant ou plus prioritaires. L analyse et la validation du «pire scénario» ou «pire cas» d exécution fournit une condition suffisante d ordonnançabilité : si l analyse est négative, cela ne veut pas dire que le système ne sera pas ordonnançable sur la plateforme, mais si l analyse est positive alors le système sera ordonnançable quelque soit son comportement à l exécution. 2.2.2 Analyse holistique : Concepts de base L une des fonctions de l analyse holistique est de déterminer la longueur de la période d activité engendrant le pire temps de réponse de la configuration de tâches étudiée. Le but étant de minimiser cette période, dont nous avons déjà donné une borne supérieure (cf 1.3.3) 2.2.2.1 Période d activité La notion de période d activité caractérise les ordonnancements à priorités fixes et dynamiques en identifiant les périodes d activité du processeur (cf. paragraphe 1.4). Une période d activité est un intervalle de temps pendant lequel le processeur est toujours occupé, c'est-à-dire sans temps creux. 2.2.2.2 Instant critique On rappelle qu il n est pas possible d analyser toutes les combinaisons possibles d interactions des temps de réponse variables d une configuration de tâche (CT) (NPcomplétude). Donc en terme d ordonnançabilité, il faut trouver la plus mauvaise combinaison de ces temps de réponses. On trouve cette combinaison à l instant où toutes les tâches se réveillent en même temps. Cet instant est l instant critique et la date t=0 est un instant critique pour une CT à départ simultané. 2.2.2.3 Période d activité synchrone Une période d activité synchrone est un intervalle de temps [0,L) délimité par un instant critique à la date t=0 et un temps creux à la date L. L est la longueur de la cette période.( t=0 définit la borne inférieure de la période d activité synchrone ) La méthode de calcul des pires temps de réponse est fondée sur l étude et la détermination de cette longueur L. «La plus longue période d activité est la période d activité synchrone de longueur L» 2.2.2.4 Charge induite Un instant critique ayant eu lieu à la date t=0 la charge induite, notée W(t), par les n tâches n t d une CT, est la durée d exécution des n tâches sur l intervalle [0,t[. On a W t 1 ( ) = C i i= 0 Ti t Où est le nombre de réveils de la tâche τ i sur l intervalle. T i La longueur L d une période d activité synchrone est calculée à l aide d une suite récurrente. 2.2.2.5 Equations récurrentes - Point Fixe Considérant un intervalle [0, t[ on compare la charge induite W(t) à la longueur t de l intervalle. Si la charge induite est supérieure à la longueur de l intervalle, alors W(t) constitue une première borne inférieure de la longueur L. Probatoire Ordonnancement temps réel des tâches et des messages 18

On calcule récursivement en comparant les intervalles [0, W(t)[, [0, W(W(t))[, aux charges induites W(W(t)), W(W(W(t))), jusqu à ce que la nouvelle valeur soit égale à la précédente. Cette valeur est la longueur L de la plus longue période d activité pour la CT considérée Formellement, L est défini comme le point fixe du système d équations récurrentes suivant : L (0) n 1 = C i= 0 ( k + 1) L i = W ( L [Éq. 2-1] Le calcul est arrêté lorsque deux valeurs sont égales : L=L (k) =L (k+1) On rappelle que le facteur d utilisation du processeur U est la fraction de temps d utilisation n du processeur nécessaire à l exécution de la CT (cf. paragraphe 1.3.2) : 1 Ci U = et qu une i= 0 Ti condition nécessaire d ordonnançabilité pour une CT donnée est que U 1. Le système d équation [Éq. 2-1] converge en un nombre fini de pas si U 1 La plus longue période d activité est la période d activité synchrone de longueur L. Cette période d activité est la durée d étude nécessaire pour calculer le pire temps de réponse d une tâche. 2.2.2.6 Exemple de charge et de période d activité Tâche C i T i U i PPCM(t 1, t 2,t 3,t 4,t 5 )=300 τ 1 5 20 0.25 τ 2 7 20 0.25 U=0.916 τ 3 8 30 0.14 τ 4 3 100 0.3 Τ 5 2 100 0.94 ( k ) ) Le premier temps creux est trouvé au point fixe 57. Probatoire Ordonnancement temps réel des tâches et des messages 19

2.2.3 Analyse holistique : Principes L analyse holistique introduite en 1994 par KenTindell, permet de modéliser la dépendance entre l ordonnancement des tâches et celui des messages dans les systèmes temps réel distribués : - La date d émission d un message dépend du temps de réponse de la tâche émettrice - La date de réveil de la tâche destinataire dépend du temps de réponse du message à recevoir. L ordonnancement de deux tâches τ i et τ j communicant à travers un réseau, est détaillé dans la Figure 2.2 : l émission du message msg est décalée par l attente de la fin d exécution de τ i. De même, la tâche τ j qui est liée à l arrivée du message est retardée à son tour. Figure 2.2 La gigue d activation est l attente due à la fin de la tâche précédente. Jm et Jj sont les gigues d activation du message et de la tâche réceptrice τ j. Les gigues d activation sont les variables qui permettent de modéliser la dépendance de l ordonnancement conjoint des tâches et des messages. L analyse holistique va permettre de calculer ces gigues par la résolution de systèmes d équations récurrentes en estimant le temps de réponse des tâches et ainsi les valeurs de gigue. Nous obtenons le système d équations : * - Pour les tâches : J i = max( R m ) m pred ( i) * - Pour les messages : J i = max( R j ) j pred ( i) Le même principe de calcul qu au paragraphe 2.2.2 est utilisé pour calculer ces gigues dépendantes des pires temps de réponse, et des pires temps de réponse dépendant des gigues. Le système à résoudre est le suivant : (0) Ri = Ci (0) Ji = 0 1 i n ( k ) ( k 1) Ri = Tempsreponse( Ji ) ( k ) ( k ) Ji = max( Ri ) j pred ( i) n : nombre de tâches et de messages pred(i) : prédécesseurs immédiats de i dans le graphe de précédence Principe de l analyse : - 1 - initialiser les gigues à 0-2 - calculer les temps de réponse processeur par processeur et réseau par réseau Probatoire Ordonnancement temps réel des tâches et des messages 20

- 3 - mettre à jour les gigues avec les temps de réponse - 4 itérer au point 2 jusqu au premier point fixe. Le point fixe est atteint lorsque pour un entier k on vérifie :- R i * =R i (k) =R i (k-1), 1 i n Chaque système (processeur, réseau) possède sa propre fonction de calcul du pire temps de réponse (Tempsreponse) On note que dans le cas d une communication de deux tâches sur le même site on peut modéliser la communication par un délai de transmission nul. Pour améliorer les performances de la résolution du système, on note que ce système d équation initialise la gigue sur activation à 0. Or la gigue modélise la dépendance entre les tâches et les messages de l application : pour les tâches indépendantes la gigue est effectivement nulle. Pour les relations de dépendance le calcul de la gigue correspond à un calcul de date d activation au plus tôt (problème central de l ordonnancement). On utilisera la borne inférieure des gigues LB(J i ) et la borne inférieure des temps réponse LB(TR i ) pour initialiser le système. (0) (0) LB( Ji ) = max( LB ( J j ) + C j ) On doit alors résoudre : j pred ( i) (0) (0) LB( TRi ) = LB( Ji + Ci ) 2.2.4 Cas pire - Pires temps de réponse 2.2.4.1 Calcul du pire temps de réponse des tâches Le pire temps de réponse d une tâche τ i est obtenu lorsque toutes les tâches autre que τ i arrivent simultanément. Il suffit d étudier tous les scénarios, de longueur L au plus, où cela se produit et où τ i est activée à une date t [ 0, Ti ] L analyse de τ i permettant d obtenir son pire temps de réponse TR i, nécessite d examiner au plus T i scénarios, c-à-d T i périodes d activité différentes. 2.2.4.2 Calcul du pire temps de réponse des messages Les algorithmes pour calculer le pire temps de réponse dans les différents types de réseaux utilisés ou utilisables en temps réel sont en cours d élaboration à l heure actuelle. Néanmoins celui des réseaux de type CAN (Controler Area Network) utilisé dans l industrie automobile est utilisable dès aujourd hui. Le réseau CAN est une ressource critique, chaque message possède une priorité fixe arbitrant l accès au canal (CSMA/CA). L ordonnancement du réseau s apparente à un ordonnancement monoprocesseur non préemptif de tâches que sont les messages. Le temps de propagation est utilisé comme pire temps d exécution dans le modèle de tâches. Les résultats obtenus du calcul du pire temps de réponse pour un ordonnancement préemptif peuvent être adapté à l ordonnancement non préemptif. La différence n est liée qu au décalage pouvant être engendré par une tâche moins prioritaire, utilisant le processeur à l instant critique. La tâche ne pouvant être interrompue, l instant critique sera décalé au maximum de la plus longue tâche parmi les moins prioritaires. Le pire cas survient lorsque cette tâche débute à l instant critique t = 0 1 unité de temps. Probatoire Ordonnancement temps réel des tâches et des messages 21

Les algorithmes de calcul des pires temps de réponse existent pour les politiques d ordonnancement à priorité fixe, dynamique, et pour les architectures non préemptives qu on peut utiliser pour les réseaux de communication. 2.2.5 Exemple d application : validation d un système TR distribué L analyse holistique permet de valider des systèmes temps réel distribués hétérogènes. Le Tableau 2-1 fournit les caractéristiques des tâches d une système TR à valider : il est composé d un processeur P 1 qui ordonnance les tâches à priorité fixe, d un processeur P 2 qui ordonnance selon EDF et d un réseau de communication CAN. La Figure 2.3 représente la structure logicielle du système : relations de dépendance et de communication sur ce système. Tâche Processeur C i D i T i τ 1 P 1 52 160 100 τ 2 P 1 52 180 160 τ 3 P 2 10 60 40 τ 4 P 2 20 80 60 τ 5 P 2 20 124 160 τ 6 P 2 20 188 100 m 1 CAN 1 m 2 CAN 1 Tableau 2-1 Caractéristiques des tâches d un système TR distribué hétérogène (Prio(τ 1 )< Prio(τ 2 ) τ 1 τ 6 τ 4 m1 τ 2 m 2 τ 5 τ 3 Figure 2.3 Graphe de précédence des tâches et des messages d un système TR distribué La résolution de ce système se fait en deux itérations de la méthode holistique. Tâches Itération 1 Itération 2 Ri Ji Ri Ji τ 1 104 0 156 0 τ 2 115 63 135 83 τ 3 30 0 50 0 τ 4 50 0 70 0 τ 5 60 0 80 0 τ 6 158 106 178 158 m 1 106 104 158 156 m 2 63 60 83 80 Tableau 2-2 trace des deux itérations de l analyse holistique P1 CAN La Figure 2.4 représente l ordonnancement au «pire cas» validée par la méthode holistique P2 Probatoire Ordonnancement temps réel des tâches et des messages 22

Figure 2.4 Ordonnancement temps réel de tâches et de messages dans un système distribué 2.3 Placement et affectation des priorités : Etude de cas L application étudiée est une version modifiée de celle qu on peut trouver dans les automobiles du fabricant PSA. Elle est composée de neuf sous systèmes interconnectés par deux réseaux de terrain (fieldbus) : un réseau CAN (Controler Area Network) et un réseau VAN (Vehicule Area Network) Tableau 2-3 Structure d un système embarqué dans une automobile La Figure 2.5 est le graphe de précédence du système distribué. Les tâches communiquent par messages à travers les deux réseaux CAN et VAN. La passerelle entre ces réseaux est modélisée par le pool de tâches n 2. Les différents systèmes de contrôle du véhicule sont regroupés dans le pool n 1 (ABS, Moteur, Boite de vitesse, ) le pool n 3 est constitué des écrans de contrôle (Compteur de vitesse, Température, ) et des dispositifs de pilotage (Air conditionné, ). Les pools sont constitués des ECU à qui l on veut assigner l exécution des tâches. Le Tableau 2-4 indique le découpage en pools du système et les paramètres des 44 tâches et des 19 messages composant la structure logicielle de l application. Probatoire Ordonnancement temps réel des tâches et des messages 23

Figure 2.5 Graphe de précédence d un système embarqué Pool Tâche C i D i Pool Tâche C i D i Pool Mess. C i D i T00 1 10 T24 2 50 M1 0.51 10 T01 2 20 T25 2 50 M2 0.32 14 T02 2 100 T26 2 10 M3 0.32 20 T03 2 15 T27 2 100 M4 0.29 15 T04 2 14 T28 2 40 M5 0.39 20 T05 2 50 T29 2 20 M6 0.39 40 T06 2 40 T30 2 100 M7 0.36 15 T07 2 15 T31 2 150 M8 0.39 50 T08 2 50 T32 2 200 M9 0.36 20 T09 2 50 T33 2 50 M10 0.47 100 T10 2 14 T34 2 150 M11 0.39 50 T11 2 20 T35 2 50 M12 0.25 100 T12 2 40 T36 2 50 M13 0.2 50 T13 2 15 T37 2 10 M14 0.5 10 T14 2 100 T38 2 100 M15 0.4 50 T15 2 20 T39 2 150 M16 0.1 150 T16 2 20 T40 2 100 M17 0.5 200 T17 4 14 T41 2 150 M18 0.2 100 T18 4 20 T42 2 200 M19 0.4 150 T19 2 20 T43 2 50 T20 2 20 T21 2 10 T22 2 14 T23 2 15 Pool 1 (ECU 1, 2, 3, 4, 5) Pool 2(ECU6) Pool 3 (ECU 7, 8, 9) Tableau 2-4 Découpage en pool et paramètres des tâches et des messages Pool 4 (CAN) Pool 5 (van) Probatoire Ordonnancement temps réel des tâches et des messages 24

Proc Tâche Pri Temps de Gigue Temps de Gigue Temps de Gigue Proc Tâche Pri Proc Tâche Pri reponse d'activation reponse d'activation reponse d'activation T07 0 2 0 T12 0 2 0 T41 0 2 0 T17 1 6 0 T09 1 14.8 10.8 T32 1 4 0 T18 2 14.02 4.02 T02 2 6 0 T42 2 6 0 T4 3 12 0 T14 3 8 0 T44(sic) 0 1.98 1 T10 4 14 0 T26 0 3.98 1.98 T48 1 6.37 5 T13 0 2 0 T29 1 8.02 4.02 T47 2 3.66 2 T21 1 5.98 1.98 T28 2 10.41 4.41 T52 3 4.02 2 T22 2 6 0 T24 3 8 0 T49 4 4.41 2 T03 3 11.66 3.66 T25 4 25.19 13.19 T51 5 10.8 8 T23 4 14 0 T27 5 23.44 9.44 T54 6 13.19 10 T00 0 1 0 T30 6 29.44 11.44 T53 7 9.44 6 T01 1 3 0 T37 0 6.88 4.88 T55 8 11.44 8 T11 2 5 0 T33 1 4 0 T45 * * * T15 3 7 0 T36 2 34.69 26.69 T46 * * * T16 4 13.02 4.02 T43 3 6 0 M03(sûr) * * * T19 0 2 6.37 T38 4 17.7 5.7 M13 0 4.88 3.98 T20 1 10.37 4.41 T35 0 2 0 M14 1 3.3 2 T06 2 10.41 10.8 T40 1 10 0 M15 2 26.69 25.19 T05 3 18.8 0 T31 2 6 0 M16 3 3.7 2 T08 4 10 0 T34 3 11.7 3.7 M17 4 5.7 4 T39 4 17.7 5.7 M18(sûr) * * * M19(sûr) * * * ECU 1 ECU 2 ECU 3 ECU 4 ECU 5 ECU 6 ECU 7 ECU 8 ECU 9 VAN CAN Tableau 2-5 Placement, priorités et temps de réponse des tâches et des messages 4 Le Tableau 2-5 récapitule le placement des tâches sur les ECU ainsi que leur priorité et leur pire temps de réponse. Les «*» dans les le tableau indiquent que les messages concernés n ont pas à emprunter le réseau car les tâches émettrices et destinataires sont sur le même ECU et communique directement sur le processeur. L algorithme «branch and bound», couplé à l analyseur holistique, a mis 182 secondes sur un ordinateur de type PC pour fournir ces résultats. Nous avons présenté une méthode de validation de configuration de tâches qui s intègre dans le cadre plus général du placement et de l affectation des tâches et des priorités. Cette méthode, l analyse holistique, sert à vérifier que les contraintes temporelles des étapes intermédiaires du processus de placement, sont respectées. Elle peut être sortie de son cadre et servir à valider un système temps réel dans lequel les tâches et les priorités seraient déjà placées. La conception des nouveaux systèmes complexes comme ceux qui ne manqueront pas d être utilisés dans l industrie automobile, aéronautique, spatiale ou nucléaire ne devrait pas pouvoir se passer d une méthode efficace de placement et de validation. Mais on peut dès maintenant utiliser l analyse holistique pour valider des choix qui aurait été faits «à la main». Si ces méthodes et ces algorithmes d ordonnancement ouvrent de nouvelles voies pour la conception d applications temps réel, elles restent toujours difficiles à implémenter efficacement et confortablement. Les programmeurs temps réel qui sont à l origine de ces applications, doivent pouvoir s appuyer, comme les autres programmeurs, sur des outils modernes de conception. Ceci afin de tester et d intégrer facilement, mais de manière rigoureuse, ces nouveaux horizons possibles. 4 Ce tableau est issu de Richard M., Richard P. «Méthode de placement et d affectation des priorités pour les systèmes temps réel distribués» RSTI/TSI Vol.22 n 5/03 Hermes. La non correspondance entre les identifiants des messages et ceux du Tableau 2-4 entrave la compréhension. Il faudrait rétablir cette correspondance. Probatoire Ordonnancement temps réel des tâches et des messages 25

3 Middleware temps réel : RT-CORBA Longtemps les applications temps réel ont été développées en langages «assembleur». Les applications étant fortement couplées au matériel, ce sont ces langages qui permettaient de coller au plus près de la machine. Comme le reste de l industrie liée au développement d application, les concepteurs temps réel ont fini par s intéresser aux possibilités qu offre la programmation orientée objet et les middleware. Nous allons voir comment le middleware RT-CORBA peut aider à concevoir une application temps réel distribuée complexe en en fournissant au programmeur une vision unifiée. 3.1 Middleware temps réel Depuis plusieurs années les technologies orientées objets se sont imposées comme le standard de modèle de programmation. Elles permettent de réduire la complexité de développement, de réutiliser les composants déjà développés et de réduire les coûts de maintenance. Avec l accroissement de la complexité de conception, d analyse, de maintenance et de validation des applications temps réel, la communauté temps réel voudrait elle aussi enfin pouvoir profiter de ces progrès. Mais pour cela la notion de temps réel doit être fortement intégrée à ces outils. Les middleware, comme leur nom l indique, se situent entre les applications et l infrastructure sous-jacente. Ils fournissent une représentation abstraite du système d exploitation ou du réseau à l application qui les utilise. Dans le cas des applications non temps réel ce niveau d abstraction permet de s affranchir des caractéristiques physiques ou particulières de ce qui se passe «en dessous». Or une application temps réel, elle, doit pouvoir prendre le contrôle, ou du moins être tenu au courant de ce qui se passe derrière cette abstraction. Cela va à l encontre de la philosophie des middleware. Pour tenir compte des besoins paradoxaux de la communauté temps réel, l OMG (Object Management Group), s est mis au travail et en même temps qu il tente de standardiser une version temps réel de Java et d UML, l OMG a, avec succès, particulièrement bien définies et spécifiées les extensions temps réel pour CORBA. Ces extensions concernent l ordonnancement, la gestion de la mémoire et des communications, et enfin la concurrence d accès. Avant de détailler les concepts et les mécanismes de CORBA temps réel, nous devons présenter succinctement le fonctionnement d un middleware CORBA. 3.2 Introduction à CORBA CORBA (Common Object Request Broker Architecture) est un standard qui spécifie l interfaçage des interactions entre des clients et des serveurs dans un environnement de programmation orienté objet. CORBA fournit une vue abstraite des objets manipulés par l application, et les objets, dans CORBA, n existent que sous cette forme abstraite : les interfaces. Un objet est une collection de propriétés et de méthodes qui «incarnent» cette abstraction. CORBA définit aussi des «opérations». Ce sont par exemples des services qu un client peut requérir de la part d un serveur. Ce sont les méthodes des objets qui implémentent ces opérations. Chaque objet est Probatoire Ordonnancement temps réel des tâches et des messages 26

identifié par un numéro unique, la référence d objet, qui est utilisé dans les interfaces pour spécifier les opérations utilisables par un client. L accès aux objets distribués se fait au moyen d un ORB (Object Request Broker) dont le but est de cacher l hétérogénéité des langages, des plateformes, des ordinateurs et des réseaux qui constituent l objet lui même. L ORB par là même, assure l interopérabilité entre les différentes implémentations d objets. L invocation d objet se fait grâce au mécanisme classique RPC (Remote Procedure Call). CORBA supporte les interfaces statiques et dynamiques. Les interfaces statiques sont déterminées à la compilation, alors que les dynamiques sont construites et déterminées à l exécution en interrogeant une base de données d interfaces : le dépôt (interface repository). Les principaux composant de l architecture CORBA de la Figure 3.1 sont brièvement détaillés ci-dessous : - IDL (Interface Definition Language) : Langage de définition des interfaces des objets, qui permet d établir la jonction avec les langages de programmation implémentant les objets. Figure 3.1 Architecture CORBA - Architecture d interface: - Coté client : o IDL stubs (souches). Générées à partir des définitions IDL. Ce sont les interfaces statiques du programme RPC client. o Dynamic Invocation : utilisées pour construire les requêtes à l exécution. Probatoire Ordonnancement temps réel des tâches et des messages 27

- Coté serveur o IDL skeleton (squelette) : composant qui aide l «Object Adapter» à implémenter le mécanisme RPC du coté serveur. o Dynamic skeleton: analogues du coté client. o Object Adapter: Les objets accèdent à l ORB par son intermédiaire, pour activer des objets, invoquer les méthodes, interpréter les références d objet. - ORB interface : permet aux clients et aux serveurs d accéder directement à l ORB - ORB Core : Ensemble des fonctionnalités qui assurent le fonctionnement réparti du système. C est le cœur de CORBA : référencement et localisation des objets, «marshalling» des paramètres et des résultats des appels de fonctions. C est grâce à la mise en place d un ORB temps réel (RTORB) que CORBA pourra être adapté au temps réel - Portable Object Adapter (POA) : Composant de l ORB qui assurent le référencement, l activation et la surveillance des objets. On peut avoir autant de POA qu il y a de type d implémentation de CORBA. - Interface repository : Base de donnée utilisée par les clients pour localiser les objets à l exécution et interroger les services offerts par ces objets. - Implementation repository : base de donnée utilisée par l ORB pour localiser les objets. ORB interoperability (GIOP/IIOP) : interopérabilité entre les ORB de différents fournisseurs 3.3 CORBA temps réel (RT-CORBA) C est à partir de 1995 qu un groupe de travail (SIG) s est attaché à produire des spécifications normalisées pour adapter CORBA au temps réel. Avec succès, ce SIG a produit une première spécification RT-CORBA 1.0 en 1998/1999 pour intégrer les notions de priorités fixes et en 2001 RT-CORBA 2.0 pour ce qui concerne les propriétés dynamiques de l ordonnancement temps réel. Des implémentations qui se rapprochent de ces spécifications commencent à voir le jour : TAO en est un exemple particulièrement abouti et ZEN qui s appuie en même temps sur les travaux de TAO et sur les spécifications de Java Temps Réel facilite encore le développement d applications. 3.3.1 Architecture RT-CORBA Afin d offrir une prédictibilité de bout en bout aux applications temps réel réparties, RT- CORBA définit dans ses spécifications les composants qui doivent être présents : - Ordonnancement préemptif dans le système d exploitation (OS) sous-jacent. - Une implémentation d un ORB temps réel. - Des mécanismes de communication qui intègrent les contraintes temporelles. - La possibilité d imposer des contraintes temporelles aux applications. La Figure 3.4 à la page 30, récapitule les éléments de l architecture RT-CORBA que nous allons détailler maintenant. 3.3.1.1 Thread Pool Les threads (processus légers) sont pour RT-CORBA les entités de base ordonnançables. Un modèle de thread est alors défini : il inclut des paramètres temps réel qui sont configurables Probatoire Ordonnancement temps réel des tâches et des messages 28

au moyen d interfaces. Le programmeur peut ainsi se servir des possibilités d ordonnancement préemptif pour contrer les phénomènes d inversion de priorités. Avec un pool de threads déjà configurés et prêts à s exécuter, le programmeur temps réel s assure du contrôle de ses requêtes temps réel et de la mémoire disponible dans le système natif. 3.3.1.2 Mécanismes de priorité Il existe deux types de priorités : les priorités CORBA et les priorités natives de l OS sous jacent. C est le rôle des interfaces PriorityMapping d établir la correspondance entre les deux types (cf..figure 3.2). RT-CORBA définit deux modèles de priorités : les «priorités déclarées par le serveur», et les «priorités propagées par le client» (cf.figure 3.3). Dans le premier cas c est le serveur qui fixe et annonce la priorité des objets ordonnançables, le client à la possibilité de consulter le niveau de priorité des objets qu il va utiliser (il sait à quoi s en tenir) grâce aux interfaces fournies dans les objets. Au risque alors que sa requête «bénéficie» du mécanisme d héritage de priorité implanté dans l OS sous-jacent, et se termine plus vite que prévu. Dans le deuxième cas, c est le client qui fixe les priorités des objets qu il invoque et c est au serveur de les honorer. Le modèle de priorité est choisi et configuré au moyen des interfaces PriorityModelPolicy du RTPOA (Real Time Portable Object Adapter) Figure 3.2 Correspondance des priorités natives et des priorités RT-CORBA Figure 3.3 Modèles de priorités RT-CORBA Probatoire Ordonnancement temps réel des tâches et des messages 29

RTCORBA::Threadpool interfaces pour la gestion des pool de processus légers RTCORBA::Priority Type entier pour définir le niveau de priorité [0 2 15 ] RTCORBA::Current interface d accès aux priorités natives (OS) du thread courent RTCORBA::PriorityMapping interfaces qui établissent les correspondances entre les priorités RTCORBA et celle de l OS sous jacent (native) RTPOA(Real Time Portable Object Adapter) Permet de fixer les priorités à la création des objets. RTCORBA::RTORB permet de configurer l ORB temps réel et de créer les instances des interfaces RTCORBAIDL RTCORBA::Mutex interfaces pour gérer les contentions d accès aux ressources systèmes RTCORBA::ProtocolProperties interfaces pour configurer les protocoles de transport (tailles de buffer, délais, ) Figure 3.4 Architecture CORBA Temps Réel 3.3.1.3 Service d ordonnancement RT-CORBA définit des services d ordonnancements de haut niveau d abstraction et indépendants du système d exploitation sous-jacent. Nous étudierons plus en détails ces services au paragraphe 3.3.2. 3.3.1.4 Services ORB temps réel L ORB RT-CORBA, ou RTORB se charge de contrôler les ressources utilisées par l ORB temps réel. C est aussi lui qui crée les interfaces IDL RT-CORBA et qui permet aux Probatoire Ordonnancement temps réel des tâches et des messages 30

applications d indiquer à l ORB le type et la quantité des ressources dont elles ont besoin : valeur de priorité des threads, type d ordonnancement, tampons de messages, etc. Le contrôle des ressources utilisées par l ORB permet ainsi de créer des applications prédictibles de bout en bout à travers le bus applicatif CORBA. 3.3.1.5 Système d exploitation : RTOS Le système d exploitation, sous jacent à RT-CORBA, le RTOS, doit pouvoir fournir un service temps réel minimum. RT-CORBA ne peut pas en effet accomplir de miracle. Avec un système d exploitation qui n offrirait pas d ordonnancement préemptif par exemple, RT- CORBA serait presque inutilisable. RT-CORBA pour cela doit pouvoir s appuyer au moins sur un système compatible avec les extensions temps réel de POSIX. 1003.1. On peut penser à CHORUS, RT-Linux, mais aussi aux versions Windows de Microsoft depuis NT et en particulier les versions «Windows embarqué». 3.3.1.6 Communication Inter-ORB Contrairement à CORBA, RT-CORBA fournit la possibilité aux applications de contrôler les paramètres du réseau et du système sous-jacent. Ce contrôle strict de la Qualité de Service (QOS) se fait au moyen de deux mécanismes : possibilité de choisir et de configurer les propriétés des moyens de communication (RTCORBA::ProtocolProperties), qui doivent utiliser les techniques d ordonnancement vues au chapitre 1, et liaison explicite aux objets serveurs (pas de multiplexage implicite, pas d établissement de connexion différée, ) par la méthode validate.connection de CORBA::Object. 3.3.2 Ordonnancement RT-CORBA Les systèmes temps réel distribués se répartissent en deux classes : - Les systèmes statiques sont ceux dont on connaît la charge globale et les temps d exécution de chacune des tâches qui les composent, a priori. Ces systèmes peuvent se «contenter» d utiliser des politiques d ordonnancement statiques. - Les systèmes dynamiques ne savent pas quelles applications vont s exécuter et dans quel ordre elles vont s exécuter, soit à cause de leur trop grand nombre, soit à cause de trop grandes variations de leurs besoins de ressources. Ces systèmes doivent pouvoir s adapter à des contraintes temps réel changeantes et utiliser des politiques d ordonnancement dynamiques. RT-CORBA propose des solutions d ordonnancement pour ces deux types de systèmes sous la forme de primitives implémentées directement dans le sous-système RTORB présenté plus haut (cf. paragraphe 3.3.1.4 ci-dessus) ou d interfaces en vue d implémenter des algorithmes plus complexes. Historiquement on distingue RT-CORBA 1.0 qui offre des ordonnancements à priorité fixe comme Rate-Monotonic ou Deadline Monotonic, et RT-CORBA 2.0 pour l ordonnancement à priorité dynamique comme Earliest Deadline First ou Least Laxity First. Une application temps réel doit être assurée d une politique d ordonnancement uniforme à travers tout le système. Le service d ordonnancement, mentionné au paragraphe 3.3.1.3, choisit à cet effet les priorités CORBA, définit les politiques de fonctionnement que les POA mettront en œuvre, et les correspondances de priorités natives/corba afin d assurer un ordonnancement fiable de bout en bout. Probatoire Ordonnancement temps réel des tâches et des messages 31

Car, il faut noter que RT-CORBA, de lui même, n impose pas d ordonnancement particulier, mais spécifie seulement les interfaces à utiliser en fonction des besoins de l application. Même si les primitives que met en place RT-CORBA pour créer un RTORB sont suffisantes pour assurer un ordonnancement temps réel à priorité fixe, la mise en œuvre d un ordonnancement, sans l aide d une implémentation d un service d ordonnancement, reste complexe. Il faut pour cela en effet, à travers tout le système CORBA, être particulièrement vigilant sur la configuration des paramètres et l utilisation des interfaces qui doivent être identiques en tout point du système. 3.3.2.1 RT-CORBA 1.0 : Ordonnancement statique Le service d ordonnancement («Scheduling Service») fournit un niveau d abstraction à la configuration de bout en bout de RT-CORBA, à travers ce qu on nomme une «activité» («activity»). Une «activité» est un enchevêtrement d opérations propres à l application. Par exemple, à la réception d une alarme, la tâche apériodique qui doit se déclencher à sa réception, est modélisée comme une «activité» qui correspond à concrètement envoyer un message sur le réseau, mettre un message en mémoire, dans une file d attente par exemple, et pour le thread de la tâche se mettre en attente d élection sur un processeur. Une fois que le développeur a repéré ce que peut être une «activité» parmi d autres dans son application, il la «nomme» («names, strings») de manière unique à travers tout le système CORBA. Le service d ordonnancement associe ce nom unique à des priorités et des objets CORBA et lui assigne des types d ordonnancement. Ce regroupement par «noms» permet au programmeur, quand son application doit entrer dans une section temps réel, d appeler la primitive schedule_activity avec le «nom» de l «activité» en paramètre. Le service d ordonnancement invoque alors le RTORB et le RTOS avec les priorités souhaitées de bout en bout du bus CORBA. On note que le programmeur reste toujours dans l obligation de faire des choix complexes pour les priorités et les objets à utiliser, mais il n a plus à le faire en tout point du système distribué. On notera que le service d ordonnancement est le seul composant de la Figure 3.4 qui a été déclaré optionnel dans les spécifications de RT-CORBA 1.0. 3.3.2.2 RT-CORBA 2.0 : Ordonnancement dynamique Face aux limites imposées par l ordonnancement statique ou à priorité fixe et le peu de succès rencontré, à notre connaissance, par les «activités» de RT-CORBA 1.0, l OMG a recadré les services que doit pouvoir fournir un middleware temps réel : - Donner la possibilité aux tâches de migrer vers des systèmes hétérogènes - Fournir un moyen de découvrir les systèmes sur lesquels elles peuvent migrer - Faire migrer les paramètres d ordonnancement en même temps que les tâches - Fournir la possibilité d utiliser les algorithmes d ordonnancement ad hoc - Stopper une tâche à distance et la faire repartir - Faire repartir l ordonnanceur local quand une tâche revient de sa migration - Permettre la collaboration des ordonnanceurs locaux distribués pour assurer un ordonnancement global RT-CORBA 2.0 introduit quatre nouveaux concepts 5 qui doivent permettre d atteindre ces objectifs : 5 On propose entre parenthèses une traduction française de ces concepts, non rencontrée dans la littérature. Probatoire Ordonnancement temps réel des tâches et des messages 32

- Scheduling Segment (SSeg) (Segment d ordonnancement) : une séquence de code qui s exécute avec des paramètres fixés d ordonnancement - Distributable Thread (DT) (Processus léger distribuable) : la nouvelle entité d exécution de base ordonnançable o Le DT peut s exécuter sur plusieurs nœuds et s imbriquer dans un ou plusieurs Scheduling Segments. o Il est indentifiable de manière unique à travers le système : GUID o Le contexte temps réel du DT est transmissible au différents GIOP - Pluggable Scheduler (Greffe d Ordonnanceur) : facilite l utilisation, les tests (?), d algorithmes d ordonnancement complexes, et inédits - Scheduling Points (Etapes d Ordonnancement): points d interactions entre l ordonnanceur, l application et l ORB. Par exemple lorsque le DT à besoin d une ressource, quand il doit migrer et que son contexte d ordonnancement doit être interprété sur la machine cible Typiquement une application distribuée dans cette architecture est composée de plusieurs DT, qui s exécutent de manière concurrente. Chaque DT à son tour s exécute dans un SSeg ou une série de SSeg distribués qui peuvent eux même être imbriqués. Le code de l application est ainsi ordonnancé en temps réel et de manière distribuée (cf.figure 3.5) Figure 3.5 Invocation distribuée et imbriquée d un Scheduling Segment Même si ces dernières spécifications sont, à l heure actuelle, encore en phase d étude par la communauté temps réel, on peut néanmoins déjà se procurer sous la forme de projets Open Source, ou de produits commerciaux, des implémentations de middleware temps réel qui s appuient sur les spécifications RT-CORBA que nous venons de survoler. 3.3.3 TAO (The Ace ORB) TAO est le résultat d un projet de longue date, strictement compatible avec les spécifications CORBA non temps réel. Dès 1997, partant du constat que CORBA n était pas adapté au temps réel, les membres de ce groupe actif de recherche, se sont attachés, avant l OMG, à produire des spécifications d un futur RTORB. Cette avance prise sur l organisme de standardisation, et surtout la mise à disposition pour la communauté de code exécutable, font Probatoire Ordonnancement temps réel des tâches et des messages 33

que le groupe TAO est devenu un acteur incontournable dans le domaine du temps réel distribué. Les travaux de TAO ont permis de mettre en évidence les limites logiques des implémentations des ordonnanceurs à priorité fixe comme DM et RM. En effet, pour prendre en compte dans ces ordonnanceurs les tâches non périodiques comme les alarmes, ou les interruptions matérielles (tâches sporadiques et apériodiques, i.e. à contraintes strictes et relatives), une solution consiste à les traiter sous une forme ou une autre comme des tâches périodiques. On s arrange alors pour allouer les ressources temporelles dont elles pourraient avoir besoin, soit en intégrant leur pire cas d exécution dans un ordonnancement DM ou RM (cas des tâches sporadiques), soit grâce à la mise en place d un «serveur sporadique» vu au chapitre 1.5 (cas des tâches apériodiques). Ce gaspillage pessimiste des ressources dans le premier cas, cette complexité dans le deuxième, a poussé l équipe TAO à implémenter des politiques d ordonnancement dynamiques comme EDF et LLF, mais aussi mixtes comme MUF, bien avant que l OMG ne décide de se pencher sur ces problèmes et publie RT- CORBA 2.0. TAO est à l heure actuelle l un des rares RTORB qui respecte les spécifications RT-CORBA 1.0 et une partie de celles de RT-CORBA 2.0. Cependant, le RTORB de TAO hérite d un problème historique de taille : il est développé en C++. La standardisation de l interfaçage (IDL) CORBA/C++, ayant été accouchée dans la douleur 6, son apprentissage rebute nombre de programmeurs, et par voie de conséquence freine l adoption à grande échelle des implémentations C++ du groupe TAO. 3.3.4 Micro noyau ZEN ZEN pour sa part est un ORB CORBA temps réel (RTORB) open source, architecturé autour d un micro noyau implémenté au moyen des spécifications temps réel pour Java (RTSJ), et qui s appuie sur les travaux de TAO. Les avantages attendus sont de pouvoir profiter de la simplicité, de l efficacité et de la portabilité du langage Java. De plus, l utilisation d un micro noyau ORB permet de développer des applications embarquées temps réel distribuées (DRE) modulaires, minimalistes et adaptées (télécommunications sans fil, chirurgie robotique, contrôle de processus industriels, ) tout en conservant la possibilité d utiliser les services des serveurs distants connectés au même bus CORBA (cf. Figure 3.6). Figure 3.6 Architecture modulaire du micro noyau ZEN. 6 On pourra lire à ce sujet «Object Interconnections: The History of the OMG C++ Mapping» http://www.cuj.com/documents/s=8001/cujcexp1811vinoski/ Probatoire Ordonnancement temps réel des tâches et des messages 34

Mais en utilisant Java, ZEN doit s affranchir de deux aspects rédhibitoires pour le temps réel : - le modèle préemptif d ordonnancement de la JVM (Java Virtual Machine) varie d une plateforme à une autre (tourniquet ou préemption par priorité simple) 7 - le ramasse miette (Garbage Collector) de la JVM peut préempter n importe quel autre thread Pour cela ZEN utilise des mécanismes issus des travaux des RTSJ tel que la «scoped memory» et les «no-heap real-time threads», pour améliorer la prédictibilité du middleware. Pour la description de ces mécanismes, sortant du cadre de ce mémoire, on pourra consulter : http://www.cs.wustl.edu/~schmidt/pdf/orbcore.pdf Les nouveaux paradigmes qui se sont mis en place dans les autres secteurs de l industrie du logiciel - tablant sur des ressources mémoires sans limites, des processeurs toujours plus puissants, des réseaux de communication toujours plus rapides et bon marché - n ont pas pu profiter aux développeurs temps réels. Du fait de contraintes rigoureuses dont sont tributaires les applications temps réel distribuées, comme des espaces mémoire restreints, des temps d exécutions strictement prédictibles, des consommations d énergie draconiennes, ces applications ont continué à être développées avec des outils d ascètes. L intégration des spécificités propre au temps réel dans les middleware standards du marché et les langages de développement orientés objet, va permettre à la communauté temps réel de prendre le train en marche de la réutilisation de code, de la conception modulaire et du modèle client serveur. 7 Voir «Java Threads», Oaks & Wong 2 nd édition (version française) page 135 Probatoire Ordonnancement temps réel des tâches et des messages 35

Conclusion Le domaine temps réel est complexe. On ne peut pas comprendre la problématique posée par le temps réel dans les environnements multiprocesseurs et distribués, sans de solides connaissances de base. Avant de se plonger dans l étude de l ordonnancement temps réel des tâches et des messages, les mécanismes d ordonnancement préemptif traditionnels et ceux du temps réel centralisé, doivent absolument être maîtrisés. C est ce que nous avons tenté de faire dans la première partie de ce rapport : «Valider temporellement un système temps réel consiste à prouver a priori que quel soit le flot d événement entrant, le système sera toujours capable de réagir conformément à ses contraintes temporelles». Or les applications temps réel devenant de plus en plus imposantes, comme c est le cas dans l industrie automobile, il devient nécessaire de les paralléliser en les distribuant, en les répartissant à travers un réseau de communication. La validation temporelle de ces systèmes devient alors fortement dépendante de l architecture logicielle adoptée, c'est-à-dire du placement des tâches sur les différents processeurs. L analyse holistique est une méthode efficace de validation de ces systèmes distribués hétérogènes. Intéressante à plus d un titre, elle permet, couplée à la méthode «branch and bound», d aider à concevoir l architecture logicielle elle-même. Cette aide à la conception est alors renforcée par les nouveaux outils de développement qui se standardisent. RT-CORBA, TAO et ZEN ouvrent de nouveaux horizons jusqu alors réservés aux développeurs d applications traditionnelles : POO, bus applicatifs, micronoyaux, réutilisation du code Autant d arguments qui pourront inciter les développeurs et les chercheurs à se joindre à la petite communauté du temps réel. Probatoire Ordonnancement temps réel des tâches et des messages 36

Bibliographie Bonnet C., Demeure I., 1999, Introduction aux systèmes temps réel, Hermes (Chapitre 3) Cottet F., Delacroix J., Kaiser C., Mammeri Z., 2002, Scheduling in real-time systems, Wiley (Chapitres: 1, 2, 3, 6, 8 et 9.4) Decotigny D., 2002, Bibliographie d'introduction à l'ordonnancement dans les systèmes informatiques temps réel http://david.decotigny.free.fr/rt/intro-ordo/intro-ordo.ps.gz (chapitre 3) Delacroix J., Méthodes de Programmation Système 2003/2004, Ordonnancement temps réel http://lionne.cnam.fr/cours/an03/mps03/ordonnancement.pdf (pages 30-48) Grolleau E., Choquet-Geniet A., Ordonnancement de tâches temps réel en environnement multiprocesseur à l aide de réseaux de Pétri, RTS 03/2001 Paris http://www.lisi.ensma.fr/ftp/pub/documents/papers/2001/2001-rts2001-grolleau.pdf (introduction) Kaiser C, ACCOV 2003/2004, Le temps réel http://deptinfo.cnam.fr/enseignement/cyclespecialisation/accov/tr1.presentation.pdf http://deptinfo.cnam.fr/enseignement/cyclespecialisation/accov/tr3.modeles.pdf http://deptinfo.cnam.fr/enseignement/cyclespecialisation/accov/tr4.evolutions.pdf (chapitre 4.3) Krishnmaurthy Y., 2002, Real-time CORBA 2.0: Dynamic Scheduling http://www.cs.wustl.edu/~irfan/oomworks/web/webdocs/dynamic-scheduling.pdf Krishnmaurthy Y.,Pyarali I., 2003, Design and Implementation Issues in the Dynamic Scheduling Real -Time CORBA 2.0 Specification http://www.omg.org/news/meetings/workshops/rt_2003_manual/presentations/5-1_krishnamurthy_etal.pdf Largeteau G., Geniet D., 2002, Validation Temporelle d Applications Temps Réel Distribuées à Contraintes Strictes http://www.lisi.ensma.fr/ftp/pub/documents/papers/2002/rts2002.pdf (introduction) Peyre J.F., Informatique industrielle A7-19571, Systèmes temps réel, Partie I et Partie III http://deptinfo.cnam.fr/enseignement/cyclespecialisation/accov/c1_intro1.pdf http://deptinfo.cnam.fr/enseignement/cyclespecialisation/accov/c3_ordo.pdf Richard P., Richard M., Cottet F., 2000, Analyse holistique des systèmes temps réel distribués http://www.lisi.ensma.fr/ftp/pub/documents/reports/2000/2000-lisi-2000-006_richardm.ps Richard P., Richard M., Cottet F., 2003, Placement et Validation dans les Systèmes Temps Réel Distribués http://www.lisi.ensma.fr/ftp/pub/documents/papers/2003/2003-rts03-richard.pdf Schmidt D.C., Kuhns F., 2000, An Overview of the Real-time CORBA Specification http://www.cs.wustl.edu/~schmidt/pdf/orc.pdf Schmidt D.C., Vinoski S., 2002, Object Interconnections: Real-time CORBA, Part 4: Protocol Selection and Explicit Binding, C/C++ Users Jounal (conclusion) http://www.cuj.com/documents/s=7983/cujcexp2005vinoski/ Probatoire Ordonnancement temps réel des tâches et des messages 37

Glossaire/Abréviations ATR : Application temps réel CAN : Control Area Network CT : Configuration de tâches («task set») CORBA : Common Object Request Broker Architecture DM : Deadline Monotonic DRE : Distributed Real-time and Embedded DT : Distributable Thread ou Processus Léger Distribuable ECU : Electronic Component Unit EDF : Earliest Deadline First (priorité dynamique) GIOP : General Inter-ORB Protocol GUID : Globally Unique IDentifier LLF : Least Laxity First (priorité dynamique) Middleware : Passerelle Applicative MUF : Maximum Urgency First POO : Programmation Orientée Objet OMG : Object Management Group ORB : Object Request Broker RM : Rate Monotonic (priorité statique) RT-CORBA : Real Time CORBA RTORB : Real Time ORB SITR : Système Informatique Temps Réel SSA : Scheduling System Architecture SSeg : Scheduling Segment Tap : Tâche apériodique Thread : Processus léger Tp : Tâche périodique TR : Temps Réel VAN : Vehicle Area Network HL : ordonnanceur «Hors Ligne» EL : ordonnanceur «En Ligne» Probatoire Ordonnancement temps réel des tâches et des messages 38

Tables des illustrations Figure 1.1 Modèle temporel d une tâche périodique... 5 Figure 1.2 Exemple d ordonnancement Rate Monotonic Préemptif... 7 Figure 1.3 Exemple d ordonnancement EDF de tâches à échéance sur requête... 7 Figure 1.4 Exemple d ordonnancement avec un serveur sporadique... 8 Figure 1.5 Exemple de graphe de précédence... 10 Figure 1.6 Modification des paramètres de tâches dépendantes pour EDF... 10 Figure 1.7 Graphe de précédence de cinq tâches d une application temps réel... 11 Figure 1.8 Problématique de la prédictibilité du temps de réponse... 12 Figure 1.9 Pire temps de réponse d une tâche en partage de ressources critiques... 13 Figure 1.10 Exemple d inversion de priorité... 13 Figure 1.11 Résolution de l inversion de priorité par le mécanisme de l héritage de priorité. 15 Figure 2.1 Ordonnancement d une configuration de tâches distribuée... 17 Figure 2.2 La gigue d activation est l attente due à la fin de la tâche précédente.... 20 Figure 2.3 Graphe de précédence des tâches et des messages d un système TR distribué... 22 Figure 2.4 Ordonnancement temps réel de tâches et de messages dans un système distribué. 23 Figure 2.5 Graphe de précédence d un système embarqué... 24 Figure 3.1 Architecture CORBA... 27 Figure 3.2 Correspondance des priorités natives et des priorités RT-CORBA... 29 Figure 3.3 Modèles de priorités RT-CORBA... 29 Figure 3.4 Architecture CORBA Temps Réel... 30 Figure 3.5 Invocation distribuée et imbriquée d un Scheduling Segment... 33 Figure 3.6 Architecture modulaire du micro noyau ZEN.... 34 Probatoire Ordonnancement temps réel des tâches et des messages 39

ERRATUM Page 4, dernière ligne «CH i (t)=c i (t)/d i (t) la charge résiduelle 0 CH i (t) u i CH(e i )=0» Page 5 Figure 1.1 : rajouter TR i C i + Activation Echéance Réactivation s i TR i e i r i D i T i Page 6, 1.3.3 Période d étude [0, PPCM(T i )] & [Min(r i0 ), Max{r i0,(r j0 +D j )}+2*PPCM(T i )] Page 9 «Les ATR, avec le respect des contraintes temporelles, rajoutent des degrés de complexité croissants à cette problématique selon qu elles s exécutent dans un environnement centralisé, multiprocesseur ou réparti.» Page 13 équation [Éq. 1-4] T0 TR 0 C 0 + Min( n2, m) CRmax + Ci i HPT Ti Page 17 avant 2.2.1 «Ceci pour lui permettre de respecter son échéance d i», «un ordonnancement est valide si le temps de réponse de chacune des tâches est inférieur à son délai critique (TR i D i ).» Page 19, 2.2.2.6, remplacer les valeurs du tableau Tâche C i T i U i PPCM(t 1, t 2,t 3,t 4,t 5 )=300 τ 1 5 20 0.25 τ 2 7 20 0.25 U=0.916 τ 3 8 30 0.14 τ 4 3 100 0.3 Τ 5 2 100 0.94 Page 23, 2.3 remplacer «modéliseé «par «modélisée» Page 23, rajouter dans glossaire définition ECU : Electronic Component Unit Page 25, avant dernier paragraphe, dernière phrase, remplacer «holiste» par «holistique» Page 25, dernière phrase, «Ceci afin de tester et d intégrer facilement, mais de manière rigoureuse, ces nouveaux horizons possibles.» Page 26, 3.1, «ou du moins être tenue au courant» Page 29, 3.3.1.2, 8 ème ligne, remplacer «et se se termine» par «et se termine» Page 34, 3.3.3, dernière phrase «freine l adoption à grande échelle des implémentations C++ du groupe TAO.» Page 35, dernière phrase, remplacer le point virgule situé après «code» par une virgule. Page 38 rajouter dans glossaire définition POO : Programmation Orientée Objet d i Temps Probatoire Ordonnancement temps réel des tâches et des messages 40