ORDONNANCEMENT TEMPS REEL - Site d'Isabelle Lanteri ...

ORDONNANCEMENT TEMPS REEL

Lanteri Isabelle Ordonnancement temps réel

Lanteri Isabelle Cnam

Ordonnancement temps réel

1 INTRODUCTION ................................................................................................................................................................. 4

1.1 QUELQUES DÉFINITIONS ........................................................................................................................................................ 4 1.1.1 - SYSTÈMES TEMPS RÉEL ...................................................................................................................................................... 4 1.1.2 ALGORITHME D'ORDONNANCEMENT ...................................................................................................................................... 5 1.1.3 - ENSEMBLE ORDONNANÇABLE ............................................................................................................................................ 5 1.1.4 ORDONNANCEMENT PRÉEMPTIF ........................................................................................................................................... 5 1.1.5 ALGORITHME OPTIMAL ........................................................................................................................................................ 5 1.2 MÉTHODES DE CONCEPTION ................................................................................................................................................. 6 1.2.1 ORDONNANCEMENT STATIQUE .............................................................................................................................................. 6 1.2.2 ORDONNANCEMENT DYNAMIQUE ......................................................................................................................................... 6 1.2.3 ORDONNANCEMENT HORS LIGNE (OFF-LINE) ......................................................................................................................... 6 1.2.4 ORDONNANCEMENT EN LIGNE (ON-LINE) .............................................................................................................................. 7 1.2.5 SYNTHÈSE ........................................................................................................................................................................... 7

2 ORDONNANCEMENT TEMPS RÉEL CENTRALISÉ MONOPROCESSEUR ......................................................... 8

2.1 MODÈLES THÉORIQUES DE TÂCHES ....................................................................................................................................... 8 2.1.1 TÂCHES INDÉPENDANTES .................................................................................................................................................... 8 2.1.1.1 Tâches périodiques ........................................................................................................................................................ 9 2.1.1.2 Tâches apériodiques ...................................................................................................................................................... 9 2.1.2 RELATIONS ENTRE TÂCHES ................................................................................................................................................. 10 2.1.2.1 Contraintes de précédence ........................................................................................................................................... 10 2.1.2.2 Partage de ressources ................................................................................................................................................. 10 2.1.3 CONTRAINTES ÉVENEMENTIELLES ...................................................................................................................................... 10 2.1.4 TÂCHES INCRÉMENTALES ET TÂCHES À RÉSULTATS IMPRÉCIS ............................................................................................... 11 2.1.5 CONCLUSION ..................................................................................................................................................................... 11 2.2 PARAMÈTRES TEMPORELS D'UNE TÂCHE ............................................................................................................................. 12 2.2.1 TÂCHES PÉRIODIQUES ....................................................................................................................................................... 13 2.2.2 TÂCHES APÉRIODIQUES ..................................................................................................................................................... 13 2.2.3 AUTRES PARAMÈTRES ...................................................................................................................................................... 13 2.3 LES ALGORITHMES D'ORDONNANCEMENT .......................................................................................................................... 16 2.3.1 ALGORITHMES À PRIORITÉ STATIQUE ................................................................................................................................. 17 2.3.1.1 - Inverse Deadline ou Deadline Monotonic ................................................................................................................. 17 2.3.1.2 - Rate Monotonic .......................................................................................................................................................... 18 2.3.2 ALGORITHMES À PRIORITÉ DYNAMIQUE .............................................................................................................................. 18 2.3.2.1 Least Laxity .................................................................................................................................................................. 18 2.3.2.2 - Earliest Deadline First ................................................................................................................................................ 18 2.4 ORDONNANCEMENT DES TÂCHES APÉRIODIQUES ............................................................................................................... 22 2.4.1 TÂCHES APÉRIODIQUES À CONTRAINTES FAIBLES ................................................................................................................. 22 2.4.1.1 Traitement d’arrière plan ............................................................................................................................................. 22 2.4.1.2 Les serveurs de tâches ................................................................................................................................................. 22 2.4.1.3 La méthode de l'ordonnancement conjoint ................................................................................................................... 23 2.4.2 TÂCHES APÉRIODIQUES À CONTRAINTES FORTES .................................................................................................................. 24 2.4.2.1 Introduction d’une pseudo-période ............................................................................................................................. 24


2.4.2.2 Routine de garantie ....................................................................................................................................................... 24 2.5 LE RÉGISSEUR .................................................................................................................................................................... 25

3 ORDONNANCEMENT TEMPS RÉEL ET SYSTÈMES RÉPARTIS .......................................................................... 26

3.1 CONTRAINTES LIÉES À LA CONCEPTION D'UN SYSTÈME TEMPS RÉEL RÉPARTI ................................................................... 26 3.2 TEMPS RÉEL ET COMMUNICATIONS ..................................................................................................................................... 27 3.2.1 LES PROTOCOLES DE LA NORME IEEE 802 ......................................................................................................................... 27 3.2.1.1 Le protocole 802.3 D ................................................................................................................................................... 28 3.2.1.2 Le protocole 802.3 DE ................................................................................................................................................ 29 3.2.1.3 Le protocole 802.5 ...................................................................................................................................................... 29 3.2.2 LE PROTOCOLE TDMA .................................................................................................................................................... 29 3.2.3 PERSPECTIVES .................................................................................................................................................................. 29 3.3 CHARGE ET FONCTION DE CHARGE ..................................................................................................................................... 30 3.3.1 LA CHARGE FONCTION DU NOMBRE DE PROCESSUS .............................................................................................................. 30 3.3.2 LA CHARGE FONCTION DE LA DISPONIBILITÉ DU PROCESSEUR ............................................................................................... 31 3.4 ARCHITECTURE GÉNÉRIQUE D’UN ORDONNANCEUR TEMPS RÉEL RÉPARTI ........................................................................ 32 3.4.1 L'ALGORITHME SOUPLE OU ADAPTATIF ................................................................................................................................ 33 3.5 EXEMPLES DE SYSTÈMES RÉPARTIS TEMPS RÉEL ............................................................................................................... 34 3.5.1 MARS (MAINTENABLE REAL-TIME SYSTEM) .................................................................................................................... 34 3.5.2 SPRING .............................................................................................................................................................................. 37

4 IMPLÉMENTATION D’UN ORDONNANCEUR À ECHÉANCES ET DU RÉGISSEUR SUR UN SYSTÈME TEMPS RÉEL RÉPARTI BÂTI AUTOUR DU MICRONOYAU CHORUS .................................................................. 38

4.1 LE MICRONOYAU CHORUS .................................................................................................................................................. 39 4.1.1 LES ENTITÉS DE BASE DU SYSTÈME CHORUS ....................................................................................................................... 39 4.1.2 LES CLASSES D'ORDONNANCEMENT ................................................................................................................................... 39 4.1.3 L'ACTEUR MICRO-NOYAU .................................................................................................................................................. 40 4.2 IMPLÉMENTATION LOCALE DE L'ORDONNANCEUR À ÉCHÉANCES ET DU RÉGISSEUR ......................................................... 43 4.2.1 ARBRE D'HÉRITAGE DE L'ORDONNANCEUR À ÉCHÉANCES .................................................................................................... 43 4.2.2 ETATS DES PROCESSUS TEMPS RÉEL .................................................................................................................................... 44 4.2.3 AUTOMATE D’ÉTATS FINIS RÉGISSANT UN PROCESSUS PÉRIODIQUE ...................................................................................... 44 4.2.4 AUTOMATE D’ÉTATS FINIS RÉGISSANT UN PROCESSUS APÉRIODIQUE ..................................................................................... 46 4.3 LE RÉGISSEUR : ALGORITHMES D'IMPLÉMENTATION ......................................................................................................... 48 4.3.1 ALGORITHME DE LA FONCTION DE GARANTIE .................................................................................................................... 48 4.3.2 LE RÉGISSEUR : ALGORITHME ............................................................................................................................................. 49 4.3.3 UNE OPTIMISATION DU RÉGISSEUR ...................................................................................................................................... 51 4.3.4 LE RÉGISSEUR : NOUVEL ALGORITHME ............................................................................................................................. 52 4.4 ARCHITECTURE RÉPARTIE ................................................................................................................................................. 53 4.4.1 ARCHITECTURE MATÉRIELLE ............................................................................................................................................. 53 4.4.2 ARCHITECTURE LOGIQUE ................................................................................................................................................... 53

5 BIBLIOGRAPHIE « ORDONNANCEMENT TEMPS RÉEL » .................................................................................. 56


1 Introduction

Nous allons présenter dans ce document les principales techniques d'ordonnancement et les modèles utilisés dans le domaine du temps réel .Les domaines d'application du temps réel sont amenés à se diversifier et à se complexifier de plus en plus, ceci dans des secteurs aussi différents que les marchés financiers, les systèmes d'armement ou la supervision de systèmes de production .

Beaucoup des enseignants et chercheurs que j'ai rencontrés lors de mon étude considèrent que les exécutifs ou noyaux temps réel commercialisés ne sont pas véritablement des outils adaptés au temps réel, car ils ne prennent pas vraiment en compte les contraintes de temps mais des niveaux de priorité assignés par le concepteur d'applications .Pourtant, le domaine de la recherche est riche en études théoriques d'algorithmes originaux et en réalisations mettant en oeuvre des ordonnanceurs fixant les priorités en fonction des contraintes de temps des tâches applicatives.Mais, une des principales critiques envers ces études théoriques concerne lasimplification excessive du modèle de tâche employé.C'est ce domaine que nous allons explorer, en ne considérant d'abord que des systèmes centralisés monoprocesseur . Nous étendrons ensuite notre étude aux systèmes temps réel répartis et étudierons un cas concret d'application réalisé au laboratoire de recherche du CNAM.

1.1 Quelques définitions

Nous allons d’ abord définir quelques termes.

1.1.1 - Systèmes temps réel

On qualifie de système temps réel tout système de contrôle de procédé dont la validation dépend non seulement de la correction logique des résultats mais aussi du respect de contraintes de temps associées .Un résultat n'est valide que dans une fenêtre temporelle donnée.


1.1.2 Algorithme d'ordonnancement

L'ordonnancement est la partie centrale d'un système temps réel. C'est là que se joue la décision concernant quelle tâche activer en fonction de l'état du système.De nombreuses configurations architecturales sont possibles pour un système temps réel et l'algorithme d'ordonnancement doit y être adapté.Ordonnancement centralisé mono ou multi processeur : un seul site est concerné et la mission de l'algorithme d'ordonnancement est de planifier l'exécution des différents processus en fonction du nombre de processeurs sur ce site.Ordonnancement réparti sur un réseau de sites mono ou multiprocesseur : l'ordonnancement s'effectue sur plusieurs sites reliés par un médium de communication.L'ordonnanceur répartit la charge engendrée par les processus actifs sur l'ensemble des sites.

1.1.3 - Ensemble ordonnançable

On dit qu’un ensemble de tâches est garanti ou ordonnançable si l’algorithme choisi pourra exécuter cet ensemble de tâches en respectant leurs contraintes de temps.

1.1.4 Ordonnancement préemptif

De façon générale, on distingue l'ordonnancement préemptif et l'ordonnancement non préemptif. Dans le cas d'un ordonnancement préemptif, une tâche ou processus en cours d'exécution peut être interrompue au profit d'une autre tâche si l'ordonnanceur le juge bon.

1.1.5 Algorithme optimal

Un algorithme est dit optimal si en cas d'échec, aucun autre algorithme n'aurait pu réussir ce qui revient à dire que si un quelconque algorithme réussit à ordonnancer correctement un ensemble donné de tâches, alors on est assuré que l'algorithme qualifié d'optimal y réussira également.

1.2 Méthodes de conception

Selon la nature du procédé à contrôler différentes approches sont possibles lors de la conception et de la mise au point d'un système temps réel.


1.2.1 Ordonnancement statique

Dans l'ordonnancement statique, l'algorithme d'ordonnancement a une connaissance à priori complète de l'ensemble des tâches et de leurs caractéristiques comme échéances, durées d'exécution, contraintes de précédence et temps de déclenchement. Présumer de cet ensemble est réalisable pour de nombreux systèmes temps réel peu complexes. L’analyse statique conduit à la construction d’une table donnant les début et fin d’exécution pour l’ensemble des tâches. L'algorithme d'ordonnancement statique opère sur l'ensemble de tâches et produit un schéma d'ordonnancement fixe et invariable. Cette approche n’est valide que pour des systèmes dont on sait qu’ils ne subiront aucune modification ni aucune évolution.

1.2.2 Ordonnancement dynamique

Un algorithme d'ordonnancement dynamique a une complète connaissance des tâches actives en cours mais de nouvelles tâches peuvent être activées de façon imprévu en cours d'exécution. Ainsi, l'ordonnancement varie au cours du temps. Dans ce cas, on ne peut garantir à priori que toutes les contraintes de temps seront respectées. Lorsqu’une nouvelle tâche survient, l’ordonnanceur fait une étude de faisabilité afin de déterminer s’il peut garantir l’ordonnancement correct de l’ensemble. Si oui, il établit un schéma d’ordonnancement et insère la tâche dans l’ensemble des tâches garanties. En cas d’échec, différentes alternatives restent possibles en fonction du temps disponible.

1.2.3 Ordonnancement hors ligne (off-line)

L'ordonnancement hors-ligne est souvent faussement assimilé à l'ordonnancement statique. Lors de la conception d'un système temps réel, l'analyse d'ordonnancement hors-ligne qui consiste à identifier l’ensemble maximum des tâches avec leurs caractéristiques devrait toujours être effectuée sans considérer si l'algorithme d'exécution sera statique ou dynamique. De même,on peut faire hors ligne une analyse statique sans construire aucun schéma d’ordonnancement explicite mais en produisant un ensemble statique de priorités que l’on exécutera en ligne.


1.2.4 Ordonnancement en ligne (on-line)

Si le système temps réel opère dans un environnement plus dynamique, estimer à priori les caractéristiques des tâches est impossible et l’on opère en ligne en fonction des évolutions du système.

1.2.5 Synthèse

Les systèmes temps réel étant de plus en plus complexes et susceptibles d’évolution, on privilégie aujourd’hui l’approche dynamique qui offre plus de perspectives de recherche tout en demandant beaucoup plus de travail au processeur. Par ailleurs, l’approche statique conduit souvent à effectuer des simulations élaborées de scénario typiques très coûteuses. Les deux approches ne sont pas obligatoirement antagonistes mais plutôt complémentaires puisqu’un système temps réel est généralement composé de deux catégories de tâches, les tâches prévisibles, souvent périodiques, assurant le fonctionnement en régime normal et les tâches, plus imprévues, qui peuvent surgir en cas d’anomalie ou de changements dans l’environnement du système et auxquelles le procédé à contrôler doit réagir et s’adapter.

Généralement,un algorithme d'ordonnancement peut être appliqué de façon statique ou dynamique et utilisé en ligne ou hors ligne, indifféremment. Cependant, les performances peuvent être très différentes dans chaque cas. Par exemple, l'algorithme Earliest Deadline First (EDF) est optimal dans de nombreuses situations si on l'applique à un ordonnancement statique monoprocesseur mais il ne l'est pas si on l'applique à un ordonnancement dynamique sur un système multiprocesseur.


2 Ordonnancement temps réel centralisé monoprocesseur

Nous allons d'abord étudier les principales techniques de modélisation et les algorithmes d'ordonnancement utilisés dans le cas d'un système temps réel centralisé monoprocesseur. Les techniques de modélisation concernent les paramètres et caractéristiques décrivant une tâche applicative. L'algorithme d'ordonnancement utilise ces caractéristiques pour établir un schéma d'ordonnancement valide.

2.1 Modèles théoriques de tâches

Le problème de la modélisation des tâches se pose d'une façon différente selon que l'on se trouve dans le domaine temps réel ou non temps réel. L'exécution d'une tâche dans un système non temps réel est vue comme un processus dont l'activation est aléatoire et qui peut se bloquer à des instants également aléatoires pour un temps indéterminé.Dans le cas d'un système temps réel, on a besoin d'un plus grand nombre de connaissances,outre les contraintes temporelles à respecter, on doit pouvoir prévoir et éviter dans certains cas le blocage des tâches.Enfin, comme nous le verrons le modèle de tâche et l’algorithme d’ordonnancement sont intimement liés et interdépendants.Les modèles les plus simples de tâches sont adaptés aux tâches indépendantes et périodiques .Des modèles plus complexes prennent en compte d'autres types de contraintes notamment celles liées aux relations entre tâches et au partage des ressources.

2.1.1 Tâches indépendantes

Dans cette catégorie, toutes les tâches sont considérées comme indépendantes les unes des autres.On distingue principalement les tâches périodiques liées au fonctionnement normal et permanent du système et les tâches apériodiques ou occasionnelles liées à des événements d'exception et survenant da façon aléatoire et imprévisible dans le système. Les seuls critères pris en compte dans ce cas concernent les contraintes et caractéristiques temporelles de la tâche.


2.1.1.1 Tâches périodiques

L'application est considérée comme un ensemble T d'une ou plusieurs tâches périodiques Ti.Chaque tâche Ti est caractérisée par une période Pi et une durée d'exécution Ci .Si on ne peut connaître précisément cette durée d'exécution, on choisit un majorant.On a alors : T = {T1 , T2,.....,Tn} = {(P1,Ci),(P2,C2),.....,(Pn,Cn)}Ce modèle est une des premières références et il a donné naissance aux premiers algorithmes d'ordonnancement dont le Rate Monotonic proposé par Liu et Layland en 1973.Ce modèle très simple est pourtant difficilement applicable dans la réalité surtout si l'on considère la modélisation d'un système complexe et nous impose plusieurs limitations.En effet,on suppose que:.Les tâches sont parfaitement indépendantes les unes des autres..La durée d'exécution de chaque tâche sur un processeur est constante et indépendante du contexte..Toute tâche doit se terminer avant sa prochaine activation..Toutes les tâches sont périodiques ..Toutes les tâches commencent simultanément leur exécution.

Une des limitations de ce modèle est la non prise en compte de la date au plus tard de terminaison de la tâche.En effet, une tâche peut avoir une grande période et demander un temps de réponse très court.Par exemple, la tâche qui envoie un bip sonore pour marquer le début d'une heure est une tâche périodique de période une heure mais le bip doit parvenir à la seconde près.On note D (comme Deadline) l'échéance ou date au plus tard de terminaison de la tâche.D'une façon similaire,une tâche peut avoir une date au plus tôt pour démarrer son exécution (Release time ou date de déclenchement).La prise en compte de ces nouvelles contraintes a conduit à des extensions de l'algorithme Monotonic Rate.

2.1.1.2 Tâches apériodiques

La prise en compte des tâches apériodiques est faite selon plusieurs approches.On distingue souvent les tâches apériodiques à échéances critiques dont il est impératif de respecter les contraintes de temps et les tâches apériodiques à contraintes de temps


relatives dont il est possible de dépasser la date d'échéance sans remettre en cause la survie du système.Le paramètre fixant ce niveau d'urgence est appelé criticité.

Les paramètres temporels caractérisant une tâche apériodique sont :.Sa date d'arrivée ou de disponibilité..Sa durée d'exécution ..Son échéance.On fixe éventuellement un temps minimal d'inter-arrivée entre occurrences de la tâche, ce qui permet de fixer une pseudo-période et de traiter alors la tâche comme une tâche périodique.

2.1.2 Relations entre tâches

On peut également considérer dans notre modèle, les relations et les dépendances entre les tâches.

2.1.2.1 Contraintes de précédence

On dit qu'une tâche Ti précède une tâche Tj si la tâche Ti ne peut commencer son exécution avant que la tâche Tj soit terminée.On peut donc associer à chaque couple orienté de tâches un attribut booléen indiquant si elles sont ou non liées par une contrainte de précédence.Le graphe résultant d'une telle description se présente comme un graphe non cyclique orienté où, à chaque noeud est associée une tâche. Une flèche entre deux noeuds représente une relation de précédence entre les deux tâches.Pour les tâches liées seulement par des contraintes de précédence, on peut résoudre le problème par une modification des dates d'échéances des tâches.

2.1.2.2 Partage de ressources

Les tâches peuvent également être liées par des contraintes de ressources. On cherche alors à éviter les situations d'interblocage et l'inversion de priorité, cas dans lequel une tâche de haute priorité est bloquée parce qu'une tâche de faible priorité monopolise la ressource convoitée.

2.1.3 Contraintes évenementielles

L'activation ou le blocage d'une tâche peuvent résulter de l'occurrence d'un événement significatif d'un changement d'état de l'environnement et auquel le procédé doit


s'adapter. On peut ainsi associer aux tâches des événements liés aux conditions de son exécution.Une tâche périodique peut ainsi avoir toutes les contraintes liées à sa périodicité mais n'être active que si certaines conditions sont remplies. Une condition d'activation peut être une date au plus tôt ou une combinaison logique avec d'autres événements.

2.1.4 Tâches incrémentales et tâches à résultats imprécis

Afin de moduler la qualité du raisonnement en fonction du temps disponible, Intelligence Artificielle et Temps Réel se trouvant de plus en plus souvent impliquées conjointement dans des réalisations complexes, on a défini des modèles de tâches tentant de concilier ces deux aspects.Les tâches incrémentales sont celles dont le résultat devient de plus en plus exact et précis selon le temps attribué à leur exécution. Il n'existe pas une date au plus tard pour la terminaison de l'exécution des tâches mais plutôt une fonction d'erreur décroissante selon le temps alloué à l'exécution de la tâche.Dans d'autres modèles, une tâche est décomposée en une partie obligatoire produisant un résultat acceptable et une partie optionnelle fournissant une solution plus précise. A chacune de ces parties est rattachée une date d' échéance.Le système à bases de connaissances temps réel REAKT présente ce modèle de tâche étendu à trois parties :une partie obligatoire à échéance critique,une partie optionnelle à échéance non critique et une partie action à échéance critique également, ce qui permet de moduler la précision des résultats en fonction du temps disponible.

2.1.5 Conclusion

Les modèles théoriques sont parfois excessivement simplistes et difficilement adaptables à la réalité.Ils sont adaptés pour la modélisation de tâches périodiques parfaitement prévisibles et déterminées et d’un déroulement séquentiel simple.Typiquement,dans une application temps réel, les tâches périodiques sont des tâches applicatives en fonctionnement normal du procédé à contrôler, par exemple acquisition et traitement des données en entrée tandis que les tâches apériodiques correspondent soit à des situations d'urgence déclenchées par des interruptions matérielles ou la détection du dépassement d'un seuil par une tâche périodique de scrutation soit à des tâches expertes à raisonnement complexe et échéances non critiques dans certains systèmes.


Les tâches apériodiques sont un élément non négligeable d’un système temps réel etpour des applications complexes, il est nécessaire de disposer d’un modèle de tâche plus complet que le modèle théorique simpliste.

Par ailleurs, la nécessité de connaître les valeurs exactes et précises des durées d’exécution est une contrainte majeure si on ne dispose pas d’outils pour celà. On se contente souvent d’une estimation. Selon le type de raisonnement de la tâche (boucle conditionnelle,attente événementielle), estimer une durée maximale d’exécution peut conduire à surdimensionner le système.Enfin, pour des applications réelles et non plus seulement théoriques, il faut tenir compte de l’environnement susceptible d’influencer ce paramètre.La durée d’exécution peut être influencée par le matériel, le système d’exploitation, le compilateur et le langage utilisé.De nombreuses caractéristiques du matériel introduites pour améliorer la rapidité des programmes rendent plus difficile le calcul des durées d’exécution, par exemple caches, pipelines, RAM dynamiques et mémoire virtuelle secondaire provoquent un comportement indéterministe du matériel.Les mêmes remarques sont à faire en ce qui concerne les optimisations des compilateurs.Par ailleurs, on remarque que,dans les simulations, on utilise souvent des boucles vides, ce qui laisse mal augurer du comportement d'un système où les tâches effectuent de nombreuses opérations complexes telles qu'appels aux I/O, appels système.Par ailleurs,pour adapter notre modèle à des applications réelles, il faut envisager ce que Melle Delacroix,dans sa thèse, appelle les phases d'une application, c'est à dire les variations et modulations des sous-ensembles de tâches exécutables à un instant donné et travailler avec des paramètres temporels variables .

2.2 Paramètres temporels d'une tâche

Nous allons maintenant détailler les caractéristiques temporelles pouvant décrire une tâche car le fonctionnement d'un système dépend de leur précision et de leur pertinence.Les tâches ou processus participant à la vie d'un système temps réel sont principalement caractérisés par des contraintes ou des caractéristiques temporelles nettement définies.On distingue en premier lieu les tâches périodiques qui s'exécutent à intervalles réguliers et les tâches apériodiques ou occasionnelles qui se déclenchent de façon imprévisible et irrégulière.Ces dernières peuvent être cause de surcharge du système et


entraîner des difficultés ou même impossibilités de respecter les contraintes de temps des précédentes si on n'a pas dimensionné le système en conséquence.

2.2.1 Tâches périodiques

Sachant qu’une tâche étant fixée,on appelle requêtes toutes ses occurrences périodiques suivantes les paramètres temporels d'une tâche périodique Ti (si,Ci,Ri,Pi) sont les suivants :

Pi est la période de la tâche.Elle n'est pas obligatoirement fixe. si est la date de première requête (déclenchement) de la tâche. Les requêtes

suivantes ont lieu à l'instant t = si + (k - 1) Pi lors de la kième occurrence de la tâche.

Ci est la durée d'exécution de la tâche. Si la tâche est susceptible d'avoir plusieurs durées d' exécution différentes,on choisit souvent le pire temps d'exécution, c'est à dire le plus long ,ce qui peut conduire à surdimensionner le système.

Ri est le délai critique de la tâche, c'est à dire la durée maximale après son déclenchement où la tâche doit avoir terminé son exécution.

La date d'échéance (deadline) est alors : Di = si + (k - 1)Pi + Ri lors de la kième occurrence de la tâche.

Si la date d’échéance correspond au début de la période suivante, on parle d’échéance sur requête.

2.2.2 Tâches apériodiques

Les paramètres temporels d'une tâche apériodique Tai (ri,Ci,di) sont les suivants : ri est la date d'arrivée de la tâche. Ci est la durée d'exécution de la tâche. Di est la date d'échéance de la tâche.

2.2.3 Autres paramètres

On peut également définir un autre paramètre nommé laxité et noté L qui représente l'intervalle de temps entre la date d'échéance et la date au plus tard à partir de laquelle elle pourra s'exécuter sans dépasser son échéance, soit :L = R - C


On peut fixer des paramètres dynamiques R(t) ou délai critique dynamique représente le temps restant avant la date d’échéance D à l’instant t et C(t) est la durée d’exécution de la tâche à l’instant t .La laxité dynamique est alors L(t) = R(t) - C(t)On peut également fixer une durée maximale d'exécution à une tâche, ce qui permet de fixer une borne maximale au retard que peut subir une tâche à cause des interruptions ou blocages subies lors de son déroulement et une date au plus tôt avant laquelle la tâche ne peut démarrer son exécution.

Donnons un exemple imagé : si on veut manger une glace tous les après-midi, cette tâche a une période de 24 heures,une durée moyenne d’exécution de 5 minutes, une date au plus tôt (midi) et une date au plus tard (18 heures). La durée maximale d’exécution de la tâche ne doit pas dépasser 15 minutes (en fonction de la température ambiante).


Paramètres temporels d’ une tâche

Dans ce modèle, la tâche possède les caractéristiques suivantes : Période P Durée d’ exécution ou durée d’ occupation du processeur C Date d’ échéance ou date au plus tard d’ exécution D Durée maximale d’ exécution T Date de déclenchement ou de début d’ exécution au plus tôt O Un délai dynamique R(t) et une durée dynamique c(t)

Dans ce modèle, la tâche possède : une période P une date de première requête s une durée d’ exécution C un délai critique R = Dk – (k – 1)(P + s) pour la kième requête une laxité L = R - C


P P

O2 tO1 t

D1

C

R(t

D2

C(t)

R

C K=2

P P

D1 D2

R

S

L

CK=1

2.3 Les algorithmes d'ordonnancement

Généralement, on fixe des priorités aux tâches et l'ordonnanceur élit la tâche de plus haute priorité pour occuper le processeur.Pratiquement, les tâches possèdent toutes un descripteur recensant leurs caractéristiques principales. Ces descripteurs sont organisés dans une file ordonnée selon les priorités croissantes, le descripteur en tête étant celui de la tâche de plus haute priorité.Les algorithmes d'ordonnancement ont pour mission principale d'établir et de calculer ces priorités afin d'organiser la préemption des tâches.On distingue :

.Les algorithmes à priorité empiriqueC'est la méthode utilisée par la plupart des exécutifs commerciaux et propriétaires du domaine industriel.Après moult essais et mises au point hors ligne, le développeur d'applications fixe des ensembles de valeurs aux priorités afin d'obtenir le fonctionnement recherché.

.Les algorithmes à priorité statiqueLa priorité des tâches est fixée au début de la vie du système et n'est plus susceptible de varier.Citons :1) Rate Monotonic (Taux Monotone)2) Inverse Deadline ou Deadline Monotonic (Echéance Monotone)

.Les algorithmes à priorité dynamiqueLa priorité des tâches varie au cours du temps. Ces politiques sont plus flexibles tout en étant plus précises mais aussi beaucoup plus coûteuses en temps de calcul. L'ordonnanceur doit recalculer les priorités et réorganiser les files d'attente en fonction de ces nouveaux éléments. Citons :1) Earliest Deadline First (Echéance au plus tôt ou Relative Urgence)2) Least Laxity

2.3.1 Algorithmes à priorité statique

2.3.1.1 - Inverse Deadline ou Deadline Monotonic

Cet algorithme attribue une priorité fixe inversement proportionnelle au délai critique de la tâche : Priorité Ti=1/Ri.


Les performances de cet algorithme sont équivalentes à celles du Rate Monotonic dans le cas de tâches à échéance sur requête et meilleures dans le cas de configurations arbitraires.Une condition nécessaire et suffisante pour ordonnancer n tâches est : n Ci n (2 1/n - 1) i =1 Ri

2.3.1.2 - Rate Monotonic

Cet algorithme à priorité statique n'est utilisable que pour l'ordonnancement des tâches périodiques.La priorité d'une tâche est l'inverse de sa période : une tâche Ti de période Pi a pour priorité Priorité Ti = 1 PiPlus courte est la période, plus grande est la priorité.Cet algorithme est optimal dans la classe des algorithmes à priorité statique pour des configurations de tâches à échéances sur requêtes.On connaît une condition nécessaire et suffisante pour l'acceptation d'une configuration de n tâches n Ci n (2 1/n - 1) i =1 Pi

Ci est la durée d'exécution de la tâche et Ci/Pi est le taux d'occupation du processeur par Ti.

2.3.2 Algorithmes à priorité dynamique

2.3.2.1 Least Laxity

Dans cet algorithme,la priorité d’une tâche est inversement proportionnelle à sa laxité dynamique Li(t). Cet algorithme est optimal et les conditions d’ordonnançabilité d’une configuration de tâches sont les mêmes que pour Earliest Deadline. Cependant, une étude comparative permet de révéler que cet algorithme présente le défaut de mener à de nombreux changements de contexte et à de nombreuses invocations de l’ordonnanceur.


2.3.2.2 - Earliest Deadline First

La priorité maximale est accordée à la tâche dont la date d’échéance est la plus proche.Cet algorithme prenant en compte la date d’échéance permet théoriquement d’ordonnancer conjointement des tâches périodiques et apériodiques.Il est adaptable pour l’ordonnancement en ligne.Une condition nécessaire et suffisante d’ordonnancement pour un ensemble de n tâches périodiques à échéances sur requêtes de période Pi et de temps d’exécution Ci est : n Ci 1 i = 1 Pi

Pour un ensemble de n tâches quelconques de délai critique Ri, une condition suffisante d’ordonnancement est : n Ci 1 i = 1 Ri

Théoriquement, pour calculer la priorité d'une tâche Ti, on prend le délai critique dynamique Ri(t) = di -t où di est la date d'échéance et t la date courante.L'Earliest Deadline affecte à la tâche Ti, la priorité pi = 1. Ri(t)Cet algorithme est optimal en absence de surcharge.Diverses variantes existent selon si on privilégie les tâches périodiques ou apériodiques.Un algorithme est qualifié de stable si, en cas de surcharge, il garantit l’exécution des tâches indispensables à la survie du système. Or, l’algorithme Earliest Deadline est instable en cas de surcharge et on ne peut prévoir quel sera le comportement des tâches effectuant des fautes temporelles.


Comparaison des algorithmes Earliest Deadline et Inverse Deadline

On donne la configuration des tâches périodiques suivantes :

Inverse DeadlinePriorité tâche 1 = 1/7 et Priorité tâche 2 = ¼

0 1 2 3 4 5 6 7 8 9 10

La tâche T1 commet une faute temporelle

Earkiest Deadline

0 1 2 3 4 5 6 7 8 9 10R1=7 R1=6 R1=3 R1=1 R2=4 R2=4

Les deux tâches T1 et T2 s ‘ exécutent sans faute temporelle


T1 (s =0, C = 4, R = 7, P = 10)

T2 (s =1, C = 3, R = 4, P = 5)

Earliest Deadline : comportement en surcharge

T1(s=0,C=2,R=4,P=5) T2(s=0,C=3,R=10,P=10) T3(C=4,R=5)La tâche T3 est une tâche apériodique se déclenchant inopinément.

0 2 D1 5 D1 D2D1 = s + R1 = 4 puis D1 = s + P + R = 9D2 = s + R2 = 10

0 2 D1 5 D1 D2

0 2 D1 5 D3


Faute temporelle de T2



2.4 Ordonnancement des tâches apériodiques

Une application temps réel est souvent majoritairement composée de tâches périodiques assurant le fonctionnement permanent du système et dont on peut connaître facilement les caractéristiques. Dans de nombreux systèmes, l’ordonnancement des tâches périodiques est fixé au début de la vie du système et n’est ensuite plus susceptible de varier.On privilégie souvent les tâches périodiques aux dépens des apériodiques, ce qui n’est pas toujours justifié car les tâches apériodiques peuvent être provoquées par des situations d’urgence auxquelles le système doit réagir rapidement.Généralement, le problème se pose ainsi :On suppose que l’on dispose d’une configuration T de tâches périodiques garanties. Le problème consiste donc à ordonnancer des tâches apériodiques survenant de façon occasionnelle sans remettre en cause l’ordonnancement des précédentes.Les tâches apériodiques survenant peuvent être de deux natures : à contraintes strictes (il est impératif de respecter leurs échéances) ou à contraintes relatives(l'ordonnanceur fera du mieux possible mais le dépassement d'une échéance n'est pas une catastrophe).

2.4.1 Tâches apériodiques à contraintes faibles

Les contraintes de temps sur les tâches ne sont pas impératives et on cherche à minimiser le temps de réponse.

2.4.1.1 Traitement d’arrière plan

Les tâches apériodiques sont ordonnancées lorsque le processeur est oisif. Si la charge des tâches périodiques est importante, l'ordonnanceur ne pourra pas consacrer beaucoup de temps aux tâches apériodiques et celles-ci risquent d'avoir un temps de réponse long.

2.4.1.2 Les serveurs de tâches

Le serveur est une tâche périodique spécialement créée pour l’ordonnancement des tâches apériodiques.Il a généralement la plus haute priorité parmi l’ensemble des tâches périodiques. La configuration de tâches est composée de tâches périodiques ordonnancées selon le Rate Monotonic.Plusieurs types de serveurs existent et leurs différences résident dans la façon dont ils résolvent la répartition de leur capacité ou temps de traitement.Ce sont : le Serveur de Scrutation, le Serveur Ajournable et le Serveur Sporadique.


II.4.1.2.1- Le Serveur de ScrutationA chacune de ses occurrences, ce serveur traite les tâches apériodiques en suspens depuis son occurrence précédente et ce, soit jusqu'à épuisement de sa capacité soit jusqu'à ce qu'il n'y ait plus de tâches apériodiques à servir. S'il n'y a aucune tâche apériodique en attente, le serveur se suspend et sa capacité est récupérée au profit des tâches périodiques.Les tâches apériodiques peuvent avoir de grands temps de réponse, surtout si elles surviennent juste après la fin de l'exécution de la tâche serveur.On constate que deux cas peuvent se présenter :- le serveur est prêt et il n'y a pas de tâches apériodiques à traiter.- des tâches apériodiques surviennent et le serveur vient d'abandonner sa capacité, ce qui oblige ces tâches à attendre sa prochaine occurrence.

II.4.1.2.2- Le Serveur Ajournable (Deferrable Server)Le Serveur Ajournable est une variante du précédent. Simplement, si aucune tâche apériodique n'est en suspens lors de son occurrence, il conserve entière sa capacité de traitement au lieu de la perdre au profit des tâches périodiques.

II.4.1.2.3- Le Serveur SporadiqueDe façon similaire au précédent, le Serveur Sporadique est une tâche périodique de haute priorité qui conserve sa capacité de traitement. Il diffère cependant dans la façon dont il réinitialise celle-ci : au lieu de le faire périodiquement, il le fait à chaque fois que sa priorité devient active et que sa capacité n'est pas nulle. La date de prochaine réinitialisation prend pour valeur la date courante additionnée de la période du serveur.

2.4.1.3 La méthode de l'ordonnancement conjoint

La configuration T est formée de tâches périodiques quelconques ordonnancées selon l'Earliest Deadline.L'idée de cette méthode est de transformer les tâches apériodiques à contraintes relatives en tâches apériodiques à contraintes strictes par l'ajout à leurs paramètres temporels d'une échéance fictive. Ainsi, les tâches apériodiques pourront être ordonnancées grâce à un algorithme traitant le cas des tâches apériodiques strictes, notamment avec l'algorithme conjoint Earliest Deadline.A chaque fois qu'une tâche apériodique survient, il faut donc calculer son échéance fictive telle qu'elle soit


l'échéance minimale qu'il faut associer à la tâche pour que celle-ci s'exécute avec un temps de réponse minimal.Cette échéance fictive correspond à la date pour laquelle le temps total d'inactivité du processeur ordonnançant les tâches en cours est égal à la durée d'exécution de la tâche.

2.4.2 Tâches apériodiques à contraintes fortes

Les contraintes de temps sur les échéances sont critiques et il est impératif de les respecter. On cherche alors à maximiser le nombre de tâches acceptées tout en respectant les contraintes de temps.

2.4.2.1 Introduction d’une pseudo-période

On introduit une pseudo-période correspondant au temps minimum séparant deux occurrences possibles de la tâche.Ceci permet de ne travailler qu'avec un seul modèle de tâche et de les mettre toutes sur le même plan mais conduit à sous-utiliser le processeur.

2.4.2.2 Routine de garantie

On ne fait aucune supposition sur la fréquence d'arrivée des tâches.Les deux techniques utilisées sont :

2.4.2.2.1Ordonnancement dans les temps creuxLa routine de garantie teste si la nouvelle requête apériodique peut être placée dans les temps creux de la configuration périodique ordonnancée selon Earliest Deadline, ceci dans le respect des échéances temporelles de toutes les tâches.La séquence figée des tâches périodiques est prédominante.

2.4.2.2.2 Ordonnancement conjoint

A chaque arrivée d’une tâche apériodique, on construit une nouvelle séquence Earliest Deadline prenant en compte toutes les tâches.Si cette nouvelle séquence est possible, la requête apériodique est acceptée sinon elle est rejetée. La nouvelle séquence est construite par l’application de l’algorithme Earliest Deadline as Late as Possible (EDL) sur les tâches périodiques.Ceci permet de connaître le temps disponible pour ordonnancer les tâches apériodiques.Cette fonction de garantie est optimale mais coûteuse en temps de calcul.


2.5 Le Régisseur

L'étude théorique précédente nous a montré que l'algorithme d'ordonnancement "Earliest Deadline First" était instable en cas de surcharge, ce qui rend difficile sa mise en oeuvre pour des applications critiques où la sécurité de fonctionnement et le déterminisme sont indispensables . Si, théoriquement, "Earliest Deadline First" est adapté au temps réel, une implémentation pour des applications concrètes soulève de nombreux problèmes, notamment à cause du caractère totalement aléatoire et imprévisible du système en cas de surcharge . Une tâche fautive peut entraîner par cascade, la déroute totale du système si aucun mécanisme de régularisation n'est prévu.C'est pourquoi, Melle Delacroix, dans sa thèse, présente le Régisseur, un organe capable d'effectuer cette fonction de régularisation et de contrôle et qui permettra l'ordonnancement des tâches en fonction de leurs dates d'échéance tout en garantissant un fonctionnement déterministe en cas de surcharge . L’entité appelée Le Régisseur a pour mission principale d'octroyer la qualité de stabilité à l’algorithme Earliest Deadline.Le Régisseur doit savoir faire face aux surcharges afin de les supporter et de les résorber de façon satisfaisante pour l’application.Dans ce bût,on introduit un critère plus subjectif que celui de date d’échéance ou d’urgence, c’est le critère d’Importance permettant au programmeur d’applications de classifier les tâches en fonction de leur importance pour la survie du système.Le critère d’Importance peut être un simple nombre entier ou une fonction dépendant du temps si l’Importance est susceptible de varier au travers des phases de l’application.Le Régisseur n’est actif que lorsqu’une tâche rejoint l’état Prêt et est donc candidate à l’occupation du processeur.En cas de surcharge le régisseur agit par suppression par ordre croissant d’Importance sur les seules requêtes actives (prêtes ou élue) afin de résorber cette surcharge.Une fonction de garantie permet de vérifier si on peut ordonnancer la tâche candidate tout en respectant son échéance ainsi que celles des tâches précédemment garanties.Cette fonction de garantie teste la laxité des processus, un processus susceptible d’une faute temporelle présentera une laxité dynamique négative .Si la totalité des tâches est ordonnançable,la mission du régisseur s’arrête là.Sinon, le régisseur supprime des processus en fonction du critère d’Importance.Pour gérer ces suppressions, on distingue les ajournements et les révocations.Un ajournement consiste à supprimer totalement l’exécution d’une tâche ou d’une de ses occurrences périodiques.


Une révocation permet de stopper une tâche en cours d’exécution.

3 Ordonnancement temps réel et systèmes répartis

Un système temps réel réparti est un système temps réel s'exécutant sur plusieurs sites reliés par un médium de communication.On doit d'abord faire une distinction entre système réparti et système distribué.Dans un système distribué, la répartition des processus sur les différents sites est connue et fixée à l'avance tandis que dans un système réparti, le placement des processus s'effectue en cours d'exécution.Avec l'extension des réseaux et des systèmes complexes, on prévoit que les systèmes temps réel seront de plus en plus souvent associés à la répartition.Le domaine d'application s'élargit ainsi que les possibilités d'ordonnancement mais le travail de l'ordonnanceur devient plus complexe et on doit prendre en considération un certain nombre de nouvelles contraintes comme les communications entre sites, les temps de transmission sur le réseau, la connaissance d'un état global.Différentes théories s'opposent, notamment en ce qui concerne la centralisation autour d'un site maître : un site détenteur de l'état global du système décide du placement des processus sur les autres sites. Cette solution est généralement peu retenue, pour des raisons de tolérance aux fautes notamment et on préfère recourir à des techniques plus souples comme des calculs d'enchères, par exemple, où un site surchargé lance un appel d'offre vers les autres sites.

3.1 Contraintes liées à la conception d'un système temps réel réparti

En résumé, lors de la conception d'un système temps réel réparti, on doit impérativement considérer les points suivants :

. Il est nécessaire de disposer d'un temps global ou universel précis puisque l'on doit gérer des contraintes de temps très strictes. La date d'échéance d'un processus ne peut évidemment pas varier d'un site à un autre .

. Les temps de transmission sur le réseau doivent être bornés et si possible connus.


. Un ordonnanceur global doit gérer dynamiquement la répartition de la charge .

. L'état global concerne principalement la quantité de temps processeur disponible sur chaque site.. Les performances du système ne doivent pas être altérées par l’exécution de l’algorithme de synchronisation.

. On doit prévoir des mécanismes de tolérance aux fautes.

. Un problème important concerne la possibilité de migration des processus, un processus migrant étant un processus déplacé d’un site vers un autre au cours de son exécution. Le plus souvent, on se limite aux déplacements de processus, c’est à dire que le processus est déplacé avant d’avoir commencé son exécution. On peut alors effectuer une activation à distance si chaque site dispose d’une copie dupliquée du code du processus.

3.2 Temps réel et communications

De façon générale, la coexistence du temps réel et des communications n'est pas facile à mettre en oeuvre. Dans le domaine du temps réel, on considère en effet, qu'un message arrivant à destination après un certain délai est perdu.Aussi, le temps nécessaire pour acheminer un message doit-il être connu sinon précisément du moins avec une estimation correcte.

Or, tous les protocoles n'assurent pas ce service.Par exemple, un des protocoles le plus répandu, le protocole Ethernet standard 802.3 n'est pas adapté au temps réel en raison de la technique de résolution probabiliste des collisions.

Deux théories s'affrontent pour résoudre le problème du non-déterminisme des communications :1) L'approche statique illustrée par des protocoles comme TDMA (Time Division Multiple Access) ou FIP(Factory Instrumentation Protocol). 2) L'approche dynamique illustrée par des protocoles comme les standard802.3 D (Déterministe) et 802.3 DE (Déterministe par Echéances).


3.2.1 Les protocoles de la norme IEEE 802

La norme IEEE 802 s'applique uniquement aux deux couches les plus basses du modèle OSI (Open Systems Interconnect) soit les couches physique et liaison de données. Dans ce modèle,la couche liaison de données est divisée en deux sous-couches : la couche LLC (Logical Link Control) et la couche MAC (Medium Access Control).La couche LLC spécifiée dans le standard IEEE 802 est réservée à l'implémentation des fonctions de la couche liaison de données indépendantes du médium telles que contrôle de flux, échange des données entre les noeuds,gestion des erreurs.La couche MAC est, elle, réservée à la gestion de l'accès au canal physique partagé.

L'architecture 802 spécifie plusieurs protocoles standards pour l'accès au médium ,soit :.le protocole CSMA/CD (Carrier Sense Multiple Access/Collision Detection) ou standard 802.3 plus connu sous le nom de protocole Ethernet..le protocole Token Bus ou standard 802.4..le protocole Token Ring ou standard 802.5..le protocole CSMA/DCR (Deterministic Collision Resolution) ou standard 802.3 D..le protocole DOD-CSMA/CD (Deadline Oriented Deterministic) ou standard 802.3 D.

Les protocoles qui nous intéressent sont :

3.2.1.1 Le protocole 802.3 D

Si la charge du réseau est faible et qu'il n'y a pas de collisions, ce protocole se comporte comme le protocole Ethernet normal. Par contre, il assure que le temps nécessaire pour la résolution d'une collision sera limité.L'algorithme de résolution est fondé sur une organisation arborescente des stations qui représentent alors les feuilles d'un arbre binaire. Chaque station possède au moins un index et celui-ci est unique dans l’ensemble du réseau.S'il se produit une collision, une époque de résolution déterministe dont la durée est bornée supérieurement commence. On opère alors une division dichotomique.Les stations dont les index sont dans la partie inférieure de l’arbre vont cesser d’émettre jusqu’à ce que tous les messages appartenant à la partie supérieure soient transmis.Ces stations sont dites perdantes et le mécanisme se répète jusqu’à ce qu’un message passe sans collision. Ensuite, le dernier sous-ensemble perdant est élu pour tenter de transmettre.Ce protocole est adapté pour des systèmes temps réel à contraintes temporelles non strictes.


3.2.1.2 Le protocole 802.3 DE

Dans ce protocole,on prend explicitement en compte les dates d'échéance pour les transmissions de messages. Le principe est analogue à un ordonnancement Earliest Deadline First sans préemption.La connaissance de l’échéance d’un message n’est acquise qu’en ligne,au moment où le message est transmis.Comme nous l’avons vu, des problèmes peuvent se poser en cas de surcharge du réseau.Ce protocole est donc utilisable pour des systèmes dynamiques correctement dimensionnés.

3.2.1.3 Le protocole 802.5

Le protocole 802.5 utilise un mécanisme de résolution par priorité sur un anneau à jeton.

3.2.2 Le protocole TDMA

Ce protocole repose sur une structure en bus ou en anneau dans laquelle les stations ont des tranches ou fenêtres temporelles pré-allouées qu'elles peuvent utiliser ou non.Pour les messages apériodiques,on laisse quelques tranches vides.Ce protocole n’est adaptable que pour des systèmes statiques.

3.2.3 Perspectives

Différents travaux ont été réalisés visant à intégrer des contraintes temporelles aux messages. Dans cet optique, les messages sont considérés comme des tâches et ordonnancés selon des algorithmes classiques.Citons notamment les études de Lehoczky et Sha qui ont appliqué l’algorithme Rate Monotonic au problème d’ordonnancer n messages périodiques sur un bus partagé. Strosnider a ensuite élargi le problème en intégrant le Deferrable Server pour le traîtement des messages apériodiques.

3.3 Charge et fonction de charge

La fonction de charge, encore appelée indicateur de charge, doit permettre d'estimer la charge de chaque site. On peut en donner une définition formelle :Soit :


- S un ensemble de sites - A un ensemble dont les éléments sont totalement ordonnés par la relation <On note : - P un processus temps réel - FSP(t) la proposition :lors de son exécution débutant à l'instant t sur le site s ,P produit une faute temporelle.

Soit la fonction Ch: (R,S) A, Ch est une fonction de charge si elle vérifie la propriété : - t R - s1,s2 S avec s1 s2 ,on a : Ch( t,s1) < Ch( t,s2) FTPS2(t) FTPS1(t)Cette définition signifie simplement que si s1 a une charge inférieure à s2 et si P cause une faute temporelle sur s1, alors il doit en causer une sur s2.

3.3.1 La charge fonction du nombre de processus

Cette méthode est la plus grossière. Elle se fonde sur l'hypothèse suivante :- Si P est un processus temps réel, alors la probabilité que P cause une faute temporelle sur s1 est d'autant plus grande que le nombre de processus existant sur s1 est important.La construction de la fonction de charge est basée sur la longueur de la file d'attente du processeur contenant l'ensemble des processus en cours d'ordonnancement.Comme la longueur de la file du processeur peut varier rapidement dans le temps, ce qui est le cas s'il existe beaucoup de processus de durée de vie courte, on affine l'estimation en prenant la moyenne de la longueur de la file sur un certain intervalle de temps.La mise en oeuvre d'une telle technique mène généralement à une mauvaise fonction de charge, ce que l'on peut vérifier dans l'exemple donné.

.Exemple d'un mauvais calcul de charge

- Sur le site s1 : T1 ( P1= 10,C1=6, r1=0, R1=6 )- Sur le site s2 : T2 ( P2=10, C2=2, r2=0, R2=2 ) s3: T3 ( P3=10, C3=2, r3=4, R3=2 ) s4 : T4 ( P4=10, C4=1, r4=8, R4=1 )


Si,on prend pour fonction de charge d'un site le nombre moyen de processus,on obtient: Ch(t,s1) = 1 et Ch(t,s2) = 3Supposons qu'à la date t=12 survienne un processus apériodique TS de durée d'exécution CS=5,de date d'échéance d =20.On cherche un site capable de garantir TS. D'après la fonction de charge, s1 semble le mieux placé mais on ne peut malheureusement pas éviter la faute temporelle des processus P1 et PS alors qu'il est possible d'ordonnancer correctement T2,T3,T4 et TS sur le site s2.

3.3.2 La charge fonction de la disponibilité du processeur

On définit la disponibilité du processeur comme étant le temps durant lequel le processeur n'exécute pas de processus temps réel.On note : T une période fixe de temps Ts

d (t) la somme du temps disponible sur le site s durant l'intervalle [t - T,t]

On désigne la fonction de charge Ch par Ch (t,s) = T - T s d

TUne propriété évidente est : 0 Ch(t,s) 1

Pour calculer Ch,on se place aux dates T,2T,3T,...Ts

d (kT) est alors le temps disponible cumulé sur l'intervalle [(k - 1) T,kT].Il faut noter que la charge calculée à l'instant t est la charge passée du site et ne préjuge en rien de la charge future.Dans le cas général,il est impossible de démontrer que Ch,ainsi définie,est une vraie fonction de charge conforme à la définition donnée.On doit donc tenir Ch(t,s) ainsi calculé pour un bon estimateur de la charge.

Dans le cas où , sur le site S, ne s'exécutent que des processus périodiques Ti de périodes Pi et de temps d'exécution Ci, on peut estimer précisément la charge :Le facteur d'utilisation du site est : n U = Ci i=1 Pi

On prend P = ppcm(Pi) alors P = kiPi avec ki entier .On a :


n n Ts

d(kT) = T - ki Ci = T - Ci = T(1 - U) i=1 i=1 Ti

Donc Ch (kT,s) = UDans ce cas, U est un estimateur de la charge.

3.4 Architecture générique d’un ordonnanceur temps réel réparti

La fonction d'ordonnancement sur le site est divisée en deux entités : l'ordonnanceur dynamique appelé aussi ordonnanceur global et l'ordonnanceur local.

L'ordonnanceur local est composé d'un ordonnanceur centralisé et d'une fonction de garantie.Son rôle est d'assurer l'ordonnancement des processus se trouvant sur le site.La fonction de garantie est utilisée chaque fois qu'apparaît un nouveau processus afin de savoir si son échéance peut être garantie.

L'ordonnanceur global est composé d'un répartiteur de charge, d'un gestionnaire de l'état global et d'une fonction de calcul d'enchère.Le répartiteur de charge réceptionne les processus provenant d'un autre site surchargé et fait une demande de garantie les concernant à la fonction de garantie. Un processus peut être accepté ou refusé. S'il est accepté il est transmis à l'ordonnanceur local sinon le refus est notifié au répartiteur de charge qui doit alors trouver un autre site d'accueil pour le processus. Il consulte alors l'état global. Le répartiteur de charge peut également être sollicité si un processus local ne peut être garanti il lui cherche alors un site d'accueil.Le gestionnaire de l'état global a pour mission la mise à jour de l'état global et c'est donc à lui qu'incombe toute la gestion des échanges de messages convoyant les valeurs des charges de chaque site.Il assure aussi le calcul de la charge du site.La fonction de calcul d'enchère est utilisée pour l'évaluation d'une enchère pour un processus donné.


3.4.1 L'algorithme souple ou adaptatif

Cet algorithme proposé par K. Ramamritham,J.A. Stankovic et W. Zhao est un algorithme d'ordonnancement dynamique qui met en oeuvre la plupart des fonctionnalités de l'architecture générique. Une de ses variantes a fait l'objet d'une implantation dans le système temps réel réparti Spring.

.Hypothèses et spécifications On dispose de N sites reliés par un réseau disposant d'un ensemble de ressources.- Les processus indépendants sont caractérisés par leurs temps d'exécution et leurs dates d' échéance.- Les processus périodiques sont placés statiquement à l'initialisation de façon à être garantis.- Des processus apériodiques peuvent survenir à tout instant. Eux seuls peuvent faire l'objet d'un placement de processus au cas où ils ne pourraient être garantis. Il n'y a pas dans cet algorithme de possibilité de migration et un processus apériodique ne peut être déplacé vers un autre site que s'il n'a pas encore commencé son exécution.- L'état global est non seulement composé de la charge du processeur de chaque site mais aussi de la charge de chaque ressource-L'algorithme d'ordonnancement local est l'Earliest Deadline non préemptif.

Dans cet algorithme, la localisation de l'état global est décentralisée. Lors d'une surcharge sur un site, l'ordonnanceur dynamique consulte l'état global et choisit le site le moins chargé. Ce site est alors nommé site foyer.De façon à tenir compte de l'incohérence de l'état global, laquelle peut entraîner une erreur de décision concernant le choix du site foyer, l'ordonnanceur initialise une demande d'enchère pour le processus à déplacer et désigne le site foyer devant réceptionner les enchères.

.Site surchargé voulant déplacer un processus P 1.Chercher un site foyer en consultant l'état global. 2.Initialiser une demande d'enchère pour P en désignant le site foyer précédent comme le site auquel il faudra envoyer les propositions d'enchères 3.Déplacer P vers le site foyer.

.Site foyer 1.Réceptionner P


2.Si P est garanti alors garder P sinon 3.Réceptionner les enchères proposées par les autres sites. 4.Choisir le site proposant la meilleure enchère. 5.Déplacer P vers ce site.

.Site proposant la meilleure enchère 1.Réceptionner P 2.Si P est garanti alors garder P sinon abandonner P.

.Site auquel on demande une enchère pour le processus P 1.Réceptionner la demande d'enchère pour P. 2.Calculer l'enchère pour P. 3.Envoyer la valeur de l'enchère au site foyer.

3.5 Exemples de systèmes répartis temps réel

Nous allons maintenant présenter deux systèmes répartis temps réel développés dans le cadre de projets de recherche universitaire. Ces deux systèmes MARS et SPRING sont typiquement représentatifs de deux approches antagonistes dans le domaine de la conception de tels systèmes.

3.5.1 MARS (Maintenable Real-Time System)

MARS est un système temps réel distribué avec mécanismes de tolérance aux fautes développé à l'Université Technique de Vienne.Il est représentatif de ce que l'on appelle un système statique.Une grande quantité de travail doit être effectué hors ligne et chaque tâche dispose d'une quantité de temps processeur fixée.Accès au bus et ordonnancement des tâches sont réalisés de façon cyclique.Les communications et la synchronisation entre tâches sont assurés par des messages .Signaux,sémaphores et mémoire partagée n'existent pas dans MARS.Une seule interruption matérielle est utilisée sur le système:l'interruption horloge qui requiert deux gestionnaires :.Le minor interrupt est activé toutes les ms..Le major interrupt,qui est activé toutes les 8 ms .


Le protocole de synchronisation d'horloge est implémenté par le matériel.Le CSU ou Unité de Synchronisation Horloge est un exemple de circuit VLSI soulageant le réseau de la charge de la mise à jour du temps global.La résolution de l'horloge est de 1 µs.

Ethernet est le service utilisé pour la communication entre les noeuds MARS.MARS n’utilise pas ETHERNET dans le mode CSMA/CD mais associé au protocole TDMA. Les avantages de ce protocole pour MARS sont :.Chaque composant sait à l’avance les moments exacts où il peut envoyer un message..En raison de l’absence de collisions,la fiabilité durant le transfert des messages est élevée..On peut obtenir des temps de réponse très courts en coordonnant l’ordonnancement des tâches et du bus.


3.5.2 Spring

Le système temps réel distribué multiprocesseur Spring est un modèle de recherche développé à l'Université du Massachussets.Il est composé d'un réseau de multiprocesseurs.Un multiprocesseur consiste en un ou plusieurs processeurs d'application exécutant les tâches garanties par l'ordonnanceur ,un processeur système qui exécute l'ordonnanceur et d'autres travaux s'il lui reste du temps et un sous-système gérant les I/O.Le sous-système est une entité séparée du noyau Spring qui gère les I/O non critiques,les périphériques lents et les capteurs,par exemple.Ces noeuds sont connectés par deux réseaux :.Ethernet pour le trafic non temps réel.Un anneau à support fibre optique connecte deux cartes mémoire sur chaque noeud contenant 2 Moctets de mémoire dupliquée.Spring distingue 3 catégories de tâches :les tâches critiques,essentielles et non-essentielles.Les tâches critiques sont exécutées de façon prioritaire.La garantie en ligne est utilisée pour les tâches essentielles,avec des échéances relatives et l'algorithme d'ordonnancement gère également les ressources partagées(mémoire locale).Sur chaque carte,un dispatcher est responsable de la répartition des tâches d'application.Ainsi,scheduler et dispatcher s'exécutent en parallèle.Par ailleurs,Spring peut également ordonnancer des groupes de tâches,c'est à dire un ensemble de tâches ayant des contraintes de précédence et la même date d'échéance.


4 Implémentation d’un Ordonnanceur à Echéances et du Régisseur sur un système temps réel réparti bâti autour du micronoyau Chorus

S’inspirant de la thèse de Melle Delacroix, différents travaux ont été entrepris au CNAM autour de l’algorithme « Earliest Deadline First » et du Régisseur.Une première réalisation est présentée par le travail de Messieurs Gaultier et Métais dans leur mémoire d’ingénieurs CNAM .

Leur étude concerne l’implémentation d’un ordonnanceur à échéances au sein du micronoyau Chorus .Chorus est un système original, aujourd’hui commercialisé mais issu de recherches menées à l’INRIA. L’aspect le plus innovant de Chorus est sa technologie micronoyau pour construire des systèmes répartis. Le micronoyau fournit des services de base et comprend un ordonnanceur classique à priorités.Le système est modulaire, des composants autonomes appelés sous-systèmes coopèrent pour fournir des services homogènes aux applications dans un environnement distribué (serveur de fichiers, gestionnaire de mémoire virtuelle, etc...).

En première approche, Messieurs Gaultier et Métais ont donc implémenté un ordonnanceur à échéances par dessus l’ordonnanceur à priorités de Chorus.Un aspect original de leur travail est que plutôt que d’implémenter des listes ordonnées par échéances croissantes, ils ont choisi comme structure d’accueil pour les blocs de contrôle des tâches un arbre parfait partiellement ordonné, encore appelé « tas », afin d’optimiser les temps d’insertion et de suppression d’un élément dans l’ensemble des tâches prêtes .Cette étude a été menée dans un environnement non réparti et les tests réalisés par les auteurs ont montré des performances faibles, liées peut-être au faît qu’ils ont réalisé leur implémentation avec un couplage trop fort avec l’ordonnanceur de base .

L’étude suivante a été réalisée par Mr Santellani lors de son stage DEA .La classe Echéance a ici été conçue indépendamment de l’ordonnanceur Chorus et les tâches de la classe Echéance sont toujours prioritaires par rapport aux processus Chorus. Le Régisseur et sa Fonction de Garantie ont également été implémentés


localement et l’étude a été étendue à celle d’un système réparti construit autour de quatre PC équipé du micronoyau Chorus .C’est cette étude que nous allons présenter maintenant .

4.1 Le micronoyau Chorus

Le micronoyau Chorus est l'unité de base autour de laquelle on peut construire un système réparti Chorus.

4.1.1 Les entités de base du système Chorus

Les principales entités intervenant dans le système Chorus sont :.Les acteurs qui définissent un espace d'adressage. Un acteur est localisé sur un site..Les activités (threads ou processus légers) qui sont les unités d'exécution du système. Une activité s'exécute dans le contexte d'un acteur qui peut en contenir plusieurs.Toutes ces activités partagent alors le même espace d'adressage. Les activités ont des noms uniques dans le contexte d'un acteur mais pas au niveau de l'ensemble du système..Les portes permettent aux acteurs de communiquer entre eux par l'intermédiaire d'IPC. Les portes sont toujours liées à un acteur et possèdent des identificateurs uniques au sein du système réparti. On ne peut communiquer avec un acteur que si on connait le nom d'une de ses portes.

Chorus supporte deux modes d'exécution pour les acteurs :mode utilisateur et mode système.Les acteurs système peuvent demander le privilège de superviseur.

. Les acteurs utilisateurs s'utilisent en mode utilisateur et dans des espaces d'adressage protégés les uns des autres. Un acteur utilisateur désirant utiliser les services du noyau le fait par un appel système en utilisant le mécanisme de trappe ou interruption logicielle.

. Les acteurs superviseurs partagent un espace d'adressage unique, l'espace système au sein duquel le noyau est implanté, ce qui leur permet de communiquer plus rapidement entre eux par des IPC optimisés et surtout de pouvoir accéder aux services du noyau sans l'intermédiaire de trappe.

4.1.2 Les classes d'ordonnancement


Dans le noyau Chorus, les activités sont dotées de priorités. Le programmeur peut utiliser jusqu'à 256 niveaux de priorité, la priorité de niveau 0 étant la plus haute. Ces priorités peuvent être modifiées dynamiquement par l'utilisateur. Elles sont considérées par l'ordonnanceur qui garantit qu'à tout instant l'activité prête la plus prioritaire s'exécute sur un monoprocesseur (où les n activités prêtes les plus prioritaires sur une machine multiprocesseur à n processeurs).La classe d'ordonnancement par défaut permet de gérer les activités selon deux politiques : . La politique temps partagé : priorités de 128 à 255.Les activités disposent d'un quantum de temps de 100 ms.. La politique temps réel : priorités de 0 à 127.L'ordonnancement s'effectue de façon purement préemptive.La priorité absolue qui est prise en compte par l'ordonnanceur est la priorité de l'acteur additionnée de la priorité relative du thread à l'intérieur de l'acteur.

4.1.3 L'acteur micro-noyau

C'est un acteur superviseur différencié qui assure trois fonctions fondamentales soit : 1) La gestion de la mémoire virtuelle. 2) L'ordonnancement des activités ainsi que la création et la destruction des acteurs. 3) La gestion des IPC, locaux ou intersites.

L'ordonnanceur est chargé de gérer l'allocation du ou des processeurs à partir d'un ensemble d'activités se trouvant dans l'état actif (prêtes ou en train de s'exécuter). L'ordonnanceur gère l'ensemble des activités prêtes dans une liste ordonnée : la RunQueue.Cette liste est composée de sous-listes, une par niveau de priorité appelées les priority lists.La tâche de fond (idleThread) est élue lorsque la RunQueue est vide mais n'y est jamais insérée (solution classique).Il en existe une par processeur.Aussi, une activité est toujours ajoutée à la fin de sa liste de priorité alors que l'activité élue est retirée au début de celle-ci.Afin d'optimiser la gestion de cette structure, c'est à dire assurer l'efficacité du processus de recherche de la première liste non vide, l'objet RunQueue gère un pointeur sur la première sous-liste non vide.Par ailleurs, le noyau utilise les variables suivantes :


. CurrentThread : pointeur sur l'activité en train de s'exécuter (un par processeur).

. NextRunnableThread : pointeur sur l'objet de plus haute priorité actif qui est la prochaine activité à élire.. RunningThread : tableau global des activités courantes maintenu sur les machines multiprocesseurs.. NextPreemptableThread : pointeur sur l'activité courante de plus basse priorité en train de s'exécuter sur une machine multiprocesseurs.


4.2 Implémentation locale de l'ordonnanceur à échéances et du Régisseur

Nous avons vu qu'une implémentation locale d'un ordonnanceur à échéances avait déjà été réalisée autour du micronoyau Chorus par Messieurs Gaultier et Métais mais la nouvelle implémentation effectuée par Mr Santellani l'a été selon des choix différents.L'ordonnanceur à échéances est un module construit au-dessus de l'ordonnanceur natif Chorus, les processus sont organisés en une file d'attente ordonnée selon les échéances croissantes, car la Fonction de Garantie qui teste la laxité des processus rend inadéquate la recherche dans un arbre.Le Régisseur a également été implémenté. C'est une unité de contrôle facultative entièrement contenue dans un acteur superviseur amovible, c'est à dire qui peut être chargé ou déchargé dynamiquement à tout moment.

4.2.1 Arbre d'héritage de l'ordonnanceur à échéances

L'ensemble a été implémenté en C++ selon un arbre de classes ainsi constitué :

.Classe Common : cette classe regroupe l'ensemble des types et constantes utilisés globalement dans les classes dérivées.

.Classe GlobalObject : cette classe définit l'interface de dialogue entre les processus temps réel et le micronoyau.

.Classe BackgroundObject : cette classe permet de définir les tâches de fond.

.Classe RealTimeObject : cette classe regroupe l'ensemble des fonctions spécifiques aux processus temps réel.

.Classe PeriodicObject : elle permet de définir des processus périodiques.

. Classe AperiodicObject : elle permet de définir des processus apériodiques.

. Classe SystemObject : elle permet de définir des processus système à caractère ultra-prioritaire.


4.2.2 Etats des processus temps réel

Les différents états possibles pour les processus temps réel sont les suivants :

.Inexistant : le processus n’existe pas encore, aucune ressource ne lui a encore été allouée.

.Prêt et ajournable : le processus existe, il a dépassé sa date de disponibilité mais le processeur ne lui a pas encore été alloué et il est encore possible de l'ajourner.

.Elu : le processus occupe le processeur, il n’est ni révocable ni ajournable.

.Prêt : le processus est prêt à être exécuté mais il ne possède pas le processeur,il n’est ni révocable ni ajournable.

.Bloqué : le processus est bloqué (lors d’un appel système,par exemple);il n’est ni révocable ni ajournable.

.En attente périodique : le processus,exclusivement périodique,est en attente du début de la période suivante.

.Elu et révocable : le processus,exclusivement apériodique,occupe le processeur et peut être révoqué à tout moment.

.Prêt et révocable : le processus,exclusivement apériodique,est candidat pour l’occupation du processeur et peut être révoqué à tout moment.

.Bloqué et révocable : le processus,exclusivement apériodique, est bloqué (lors d’un appel système,par exemple) et peut être révoqué à tout moment.

4.2.3 Automate d’états finis régissant un processus périodique

La signification des différents événements est :


.Créer : le processus est créé.Cet événement survient lors du dépassement de la première date de disponibilité; une horloge de garde est alors armée pour détecter une faute temporelle.

.Elire : le processeur est alloué à un processus Prêt.Un processus Prêt n’ayant jamais été elu depuis le début de sa période est ajournable mais il perd cette propriété à sa première élection.

.Bloquer : le processus Elu, Prêt ou Prêt et Ajournable est bloqué.Ce blocage peut être engendré par le processus lui-même(cas d’un processus élu) lors d’un appel système,par exemple, ou par un autre processus.

Débloquer.: un processus ayant précédemment subi un événement Bloquer est débloqué. Cet événement peut être suivi des événements Préempter et Elire si le processus débloqué est de plus courte échéance que le processus élu.

.Attendre : cet événement est toujours engendré par le processus lui-même.Il se produit quand le processus périodique a terminé son travail pour la période courante et qu’il désire s’endormir en attente du début de la période suivante. Les actions effectuées lors de l’occurence de cet événement sont les suivantes:

1) Si le processus n’a pas commis de faute temporelle,désarmer l’horloge de garde qui a été créée lors des événements Créer ou Réveiller en vue de détecter des fautes temporelles. 2) Un temporisateur est armé,lequel expirera au bout du délai dt.Le calcul de dt avec :dt = (T + rK) - t où t est la date courante , T la période du processus ,k l'indice de la période en cours et rK la date de disponibilité du processus dans cette période. 3) Une fois le temporisateur armé,le processus est endormi,ce qui générera un événement Elire sur le processus Prêt suivant s’il en existe.

.Réveiller : cet événement est engendré à l’expiration du temporisateur armé lors de l’événement Attendre. Le processus est réveillé afin d’effectuer la requête pour la période venant de débuter. Il est alors placé dans l’état Prêt et Ajournable.Une horloge de garde est alors armée pour détecter une éventuelle faute temporelle.


.Ajourner : cet événement est généré par le Régisseur lors de la détection d’une surcharge. Pour le processus le recevant, il s’apparente à un événement Attendre.

.Dépasser l’échéance : le processus vient de produire une faute temporelle.Si le processus était ajournable,cet événement correspond à un ajournement. Dans le cas contraire, la faute temporelle est seulement signalée mais l’exécution du processus pour la période courante n’est pas interrompue.

4.2.4 Automate d’états finis régissant un processus apériodique

Les événements Créer,Elire,Préempter,Bloquer et Débloquer ont la même définition que précédemment.

.Terminer : le processus a effectué et terminé son travail normalement et peut être détruit.L’horloge de garde initialisée lors de l’événement Créer est désarmée.

.Ajourner ou Révoquer : ces événements sont engendrés par le Régisseur lors de la détection d’une surcharge.Le processus est alors détruit et l ’horloge de garde initialisée lors de l’événement Créer est désarmée.

.Dépasser l’échéance : le processus apériodique vient de produire une faute temporelle, il est donc détruit.


4.3 Le Régisseur : Algorithmes d'implémentation

4.3.1 Algorithme de la Fonction de Garantie

Le test d’acceptation est fait à la demande du régisseur lorsqu’un processus périodique ou apériodique rejoint l’état prêt.Seuls les processus se trouvant dans l’état prêt ou élu interviennent lors de l’évaluation du test.La fonction de garantie est modélisée par la fonction TEST qui reçoit en paramètres d'entrée la liste des processus prêts et le date courante.

La fonction de garantie TEST est définie par : TEST : R x {liste de processus} {processus} x R (t , L) (P , lp)

L = {P0 ,P1 ,...,Pn} est une liste de processus ordonnée telle que : i,j [0 , n] ( i < j dPi dPj ) si dPi est la date d’échéance du processus pi

Soit AL = { k | lPk(t) < 0} où lPk est la laxité du processus Pk : i lPk (t) = dPk - CPk (t) où CPk (t) est le temps d’exécution sans préemption j = 0de Pk à la date t.Si le processus PK est fautif alors lPK <0.L’algorithme de la fonction TEST est le suivant :

SI AL ALORS i = Max AL

P= Pj

l = lPj (t)SINON P = Pn

lP = lPn (t)FINSI


En d’autres termes, AL est la liste des processus de laxité négative et j est l’indice le plus grand dans cette liste si elle est non vide .Si un processus a une laxité négative,il ne pourra s’exécuter dans les délais et est fautif.Soit (P,lP) = TEST (t,L) alors les propositions suivantes sont vraies : 1°) P est le processus de plus longue échéance fautif dans L <=> lP <0. 2°) L est ordonnançable <=> lP 0.

4.3.2 Le Régisseur : algorithme

Le régisseur est modélisé par une fonction nommée REGISSEUR prenant en paramètre d’entrée la date courante t et une liste LE de processus. De plus, la fonction REGISSEUR renvoie une liste LS de processus telle que LS LE.

REGISSEUR : R x {liste de processus} {liste de processus} (t , LE) LS

LS est l’ensemble des processus de LE qui n’ont pas été révoqués ou ajournés par le régisseur.

REGISSEUR (t,LE)

DEBUT L := LE

(P ,lP) := TEST(t , LE)

TANT QUE (lP < 0 ET L )FAIRE (tant que la surcharge n’est pas résorbée et qu’il reste des processus dans la liste) RP := {P’ L | dP’ dP et P’ révocable ou ajournable}

TANT QUE (RP ET lP <0) FAIRE soit P’ RP tel que P ’’ RP (IP’ IP’’ ) (IP est l’importance de P) lP = lP + CP’ (t) (CP' est le temps processeur récupéré) SUPPRIMER(P’) RP := RP \ {P’} L := L \ {P’} FIN TANT QUE


SI lP <0 ALORS la surcharge n’est pas résorbée sortir de la boucle FIN SI

(P,lP) := TEST(t,L) FIN TANT QUE

LS := Lretourner L S

FIN

SUPPRIMER(P)

DEBUT SI P est ajournable ALORS AJOURNER(P) SINON REVOQUER(P) FINSI retournerFIN

AJOURNER(P)

DEBUT SI P est apériodique ALORS P est détruit SINON P est endormi jusqu'au début de la période suivante FINSI retournerFIN


REVOQUER(P)DEBUT P est obligatoirement apériodique,il est alors détruit retournerFIN

4.3.3 Une optimisation du régisseur

On donne la configuration suivante de processus : LE ={P1,P2,P3,P4} avec,en supposant t=0.P1 (C1=1,D1=1,I1=4)P2 (C2=1,D2=2,I2=1)P3 (C3=2,D3=3,I3=2)P4 (C4,D4=4,I4=3)

Calculons la laxité aux différents niveaux :

L1 = 0L2 = -1L3 = -1L4 = -2

La liste Al pour la fonction de garantie est Al ={P4,P3,P2} et on a :TEST(P1,P2,P3,P4) = (4,-2)Le Régisseur va donc effectuer les actions suivantes :lp = -2 Rp = {P1,P2,P3,P4} et P2 de plus petite importance et suppression de P2. lp = -2 + 1 = -1 Rp = {P1,P3,P4} et P3 de plus petite importance et suppression de P3. lp = -1 + 2 = 1 Rp = {P1,P4} L= {P1,P4}

Le Régisseur a supprimé P2 et P3 alors que l’on peut ordonnancer P2 comme on le voit sur le schéma.


Monsieur Santellani a donc établi une nouvelle fonction Résorber qui étend la fonction REGISSEUR afin de corriger les suppressions de processus se révélant finalement ordonnançables.On notera que l’on a supprimé P3, un processus de plus grande importance que P2 mais que l’on optimise l’occupation du processeur.

4.3.4 Le Régisseur : Nouvel Algorithme

La fonction RESORBER étend la fonction REGISSEUR et réintègre dans la liste des processus prêts un processus de plus petite Importance supprimé par le Régisseur au cas où celui-ci se révèle finalement ordonnançable.

RESORBER : R x {liste de processus} {liste de processus} (t , LE) LR

RESORBER(t,LE) DEBUT LS := REGISSEUR(t,LE) L := LS

(P,LP= := TEST(t,L)

SI lP < 0 ALORS LR := LS

SINON S:= LE \ LS (S est la liste des processus supprimés par Le Régisseur)

TANT QUE S FAIRE soit P’ S tel que P’’ S ( IP’’ IP’ ) (P' est le processus supprimé de plus grande importance) (On teste si on peut réintégrer P' dans la liste) (P,lP= := TEST(t,L {P’}) SI (lP 0) ALORS L := L {P’} FINSI


S := S \ [P'} FIN TANT QUE

LR := L FINSI retourner LR

FIN

Si on optimise la fonction Régisseur par rapport à l'occupation maximale du processeur,on ne respecte plus strictement la suppression par ordre croissant d'Importance.

4.4 Architecture répartie

Nous présentons maintenant l'architecture répartie du système.

4.4.1 Architecture matérielle

On dispose de quatre PC reliés par un réseau Ethernet .Au sein de la plate-forme,il existe deux types de sites :

1) le site de suivi d'exécution ou de développement est un site supportant le micro-noyau Chorus et le sous-système Mix compatible Unix .

2) les sites temps réel supportent l'exécution des processus temps réel.Le système d'exploitation les équipant est réduit au strict minimum: le micro-noyau Chorus agrémenté de Earliest Deadline et du Régisseur ainsi que quelques acteurs superviseurs nécessaires au protocole de communication et au déverminage : cnpEther, N_netConf,N_ndm et N_sym.

4.4.2 Architecture logique


.Les processus périodiques sont créés statiquement sur chaque site avant la mise en oeuvre du système. Ils sont ajournables mais non révocables. Si un processus périodique a commencé son exécution et commet une faute temporelle, on le laisse achever son exécution sinon on supprime son occurence.Le modèle pour les décrire a été simplifié au maximum soit P(r,T,C,R,I).

.Il n'y a pas de possibilité de migration, seulement des activations à distance . Processus apériodiques et périodiques sont susceptibles d'être déplacés .

.L'horloge globale est mise à jour toutes les 5 s.Pour compenser les imprécisions et incertitudes dues à Ethernet,on a mis au point un mécanisme de correction approximative consistant à mesurer les écarts dans les délais de transmission.

.L'ordonnanceur dynamique est construit selon le principe de l'ordonnanceur générique vu dans la partie III.

.Il n'y a ni état global ni fonction de charge : c'est l'ordonnanceur global et sa fonction de garantie qui décident du déplacement ou de l'acceptation d'un processus, connaissant son délai critique.En faît, l'état global se limite à la connaissance par tous les sites de la date de disponibilité d'une requête apériodique .

.Le travail du Régisseur est purement local.

.Un protocole de diffusion totalement ordonnée permet d'élire un site parmi ceux qui sont candidats à l'acceptation d'un processus.On utilise pour celà un site répéteur qui réemet les messages d'acceptation en les diffusant sur le cable Ethernet .Le site qui reçoit sa propre demande avant d'avoir réceptionné celle des autres est le site élu.


5 Bibliographie « Ordonnancement temps réel »

. How to Integrate Precedence Constraints and Shared Resources in Real- Time Scheduling

Marco Spuri Scuola Superiore "S.Anna" John A.Stankovic Department of Computer Science -University of Massachusetts

Cet article présente les protocoles PCP ( Priority Ceiling Protocol ) et SRP ( Stack Resource Policy) dont le bût est de limiter les effets du phénomène d'inversion de priorité dans lequel une tâche de plus haute priorité en attente d'une ressource est bloquée par des tâches de plus faible priorité monopolisant cette ressource .Ces deux protocoles peuvent être utilisés avec les deux algorithmes d'ordonnancement les plus connus soit Rate Monotonic et Earliest Deadline.Après une présentation de ces protocoles, les auteurs montrent qu'ils peuvent être utilisés avec un modèle de tâche complexifié dans lequel sont spécifiées conjointement contraintes de précédence et contraintes de partage de ressources.

. Scheduling Algorithms and Operating Systems Support for Real Time Systems

Krithi Ramamritham - John A. Stankovic Départment of Computer Science - Université du Massachusetts - Amherst

Dans cet article, les auteurs résument l’état du temps réel dans les domaines de l’ordonnancement et des noyaux exécutifs. Les auteurs distinguent quatre paradigmes dans le domaine de l’ordonnancement :1) L’ordonnancement statique fondé sur des tables :.2) L’ordonnancement préemptif avec priorité statique.3) L’ordonnancement dynamique avec établissement de plans.4) L’ordonnancement dynamique « du mieux possible » (best effort).Ils explorent ensuite deux problèmes liés : l’ordonnancement avec tolérance aux fautes et l’ordonnancement avec contraintes de ressources.Enfin, ils présentent les caractéristiques des exécutifs temps réel commercialisés du marché puis des systèmes de la recherche (MARS, SPRING, MARUTI, ARTS, CHAOS, HARTOS, DARK).


. Hybrid Online/Offline Scheduling for Hard Real Time Systems

Michael Young - Lih Chyun Shu Technical Report SERC-TR-100-P _ Purdue University

Ce rapport technique propose une méthode hybride pour un ordonnancement mêlant hors-ligne et hors-ligne.

. Implications of Classical Scheduling Results for Real-Time Systems

Article paru dans IEEE Computer Juin 1995

Cet article présente les principaux algorithmes d'ordonnancement pour des systèmes monoprocesseur et multiprocesseur .Il présente la notation de Lawler pour la définition des conditions d'ordonnancement Soit la notation : A | B | C A désigne l'environnement matériel (A = 1 indique un système uniprocesseur )B précise les caractéristiques du processus (préemptif, non-préemptif, indépendant, avec des contraintes de précédence, des contraintes d'échéance,etc...)C précise le critère d'optimisation ( minimiser,maximiser le retard maximal,etc...).L'énoncé du problème ordonnancer n processus indépendants non préemptifs où chaque processus i est décrit par son temps d'exécution Cj et sa date d'échéance dj en minimisant le retard maximum peut s'écrire : 1 | nonpréemptif | L max .Cet article expose également la règle de Jackson, des théorèmes généraux comme le théorème de Liu et Layland, les théorèmes de Mok, les protocoles PCP (Priority Ceiling Protocol) etSRP (Stack Resource Policy) puis traite des performances des algorithmes d’ordonnancement en situation de surcharge.Il expose ensuite les quelques résultats connus concernant les systèmes multiprocesseurs.

.Ordonnancement conjoint de tâches périodiques et apériodiques pour les systèmes temps réel

Joëlle Delacroix - Laboratoire d’Informatique du CNAM

Dans cet article, l'auteur présente une synthèse des méthodes utilisées pour ordonnancer conjointement des tâches périodiques et apériodiques.


Elle présente d’abord les principaux algorithmes d'ordonnancement soit Rate Monotonic et Earliest Deadline puis les différentes méthodes pour ordonnancer conjointement les tâches périodiques et apériodiques, le traitement de ces dernières étant trop souvent approximatif ou négligé.Les méthodes proposées sont les suivantes :1) Pour les tâches apériodiques dont les échéances de temps ne sont pas critiques : . Avec Monotonic Rate : la méthode de la pseudo-période, la méthode d’ordonnancement en arrière-plan, la méthode des serveurs de tâches. . Avec Earliest Deadline et Inverse Deadline : la méthode des échéances fictives.2) Pour les tâches apériodiques dont les échéances de temps sont critiques : . Avec Earliest Deadline : les routines de garantie.Dans toutes les méthodes précédemment exposées, on fait une nette distinction entre les tâches périodiques et apériodiques. Ces dernières ne sont prises en compte que si l’ordonnancement des tâches périodiques n’est pas perturbé par l’adjonction des apériodiques survenant.L’auteur expose ensuite une méthode permettant d’ordonnancer des tâches avec Earliest Deadline sans tenir compte de leur nature, périodique ou apériodique, cette méthode consiste à associer un critère d’importance aux tâches. Ce critère est utilisé pour éliminer les tâches de plus faible importance en cas de surcharge du système.Elle expose également les techniques utilisées en Intelligence Artificielle pour trouver un compromis entre qualité du résultat et temps disponible.L'auteur propose ensuite des techniques permettant de prendre également en compte les contraintes de ressources, soit :. Le protocole de l’héritage de priorité.. Le protocole de la priorité plafonnée.. Le protocole d’allocation de ressources basé sur une pile.Enfin,elle met en corrélation le problème général de l'allocation de ressources avec le problème spécifique qu'est l'accès à un médium de communication .

. Minimisation des temps de réponse des tâches sporadiques en présence de tâches périodiques

H. Chetto I.U.T de Nantes J. Delacroix Laboratoire CEDRIC du CNAM

Comme son tître l’indique, cet article présente les différents résultats obtenus dans le domaine de l’ordonnancement conjoint de tâches périodiques et sporadiques, l’objectif étant de garantir le respect des contraintes temporelles des tâches périodiques tout en minimisant le temps de réponse des tâches apériodiques.Les auteurs distinguent ordonnancement à priorité statique (Monotonic Rate) et ordonnancement à priorité dynamique (Earliest Deadline) puis les approches statique et dynamique pour résoudre le problème de l’ordonnancement conjoint de tâches périodiques et sporadiques. Ils regroupent dans la première catégorie le Traitement en Arrière-Plan et le Serveur de Scrutation.


Ils présentent l’Echange de Priorité (Exchange Priority) et le Serveur Ajournable (Deferrable Serveur) comme des exemples de la seconde approche. Ces deux techniques sont associées à l’algorithme Monotonic Rate.Dans la méthode de l’Echange de Priorité, la tâche serveur a la plus haute priorité. A chaque activation, la priorité du serveur est échangée avec celle de la tâche de plus haute priorité dans le cas où il n’y a pas de tâches sporadiques en attente.Dans la méthode du Serveur Ajournable, une tâche sporadique est prise en compte immédiatement si la capacité de traitement du serveur qui est réinitialisée à sa valeur initiale à chaque activation n’est pas épuisée. Le Serveur Sporadique est une amélioration du précédent en ce qu’il exploite les temps creux durant lequel le processeur n’est pas utilisé pour traiter l’exécution des tâches sporadiques.Les auteurs présentent ensuite les résultats obtenus avec l’algorithme Earliest Deadline as Late as Possible (EDL) associé à la méthode des échéances fictives. Dans cette méthode, une échéance fictive est attribuée à chaque tâche sporadique. Cette échéance est calculée en construisant une séquence sur un intervalle limité tel que l’exécution des tâches périodiques a lieu le plus tard possible.Enfin, les auteurs exposent les différents résultats obtenus lors de simulations afin de présenter une étude comparative des diverses méthodes. Il semble que EDL présente les meilleures performances.

. Distributed Real-Time Computing : The Next Generation

John A.Stankovic Department of Computer Science -University of Massachusetts

Dans cet article assez général, l'auteur cherche à anticiper ce que seront les systèmes temps réel de demain.A son avis, il faudra privilégier le caractère adaptatif et dynamique plutôt que la vitesse pure .Après une description succinte des OS temps réel du marché et des services qu'ils offrent, il nous prédit des noyaux intelligents capables de planifier en ligne allocation des ressources et schéma d'ordonnancement afin que les tâches obtiennent les ressources qui leur sont nécessaires au moment adéquat tout en satisfaisant également leurs contraintes de temps. Ceci faciliterait la conception et l'analyse des applications temps réel.Il suppose que les noyaux temps réel devront de plus en plus opérer dans un environnement réparti et multiprocesseu.La diversité des applications demandant une technologie temps réel sera de plus en plus grande et nécessitera l'usage de bibliothèques regroupant des algorithmes d'ordonnancement, ceci afin de ne pas avoir à adapter de façon rigide l'ordonnanceur à chaque application.L'auteur décrit ensuite les possibles liaisons entre temps réel et des domaines comme Bases de Données et Intelligence Artificielle.


. Real Time Systems : A Tutorial

F.Panzieri R.Davoli

Technical Report UBLCS-93-22 (Octobre 1993) du Département de Mathématiques de l'Université de Bologne

Ce rapport présente les principaux problèmes soulevés lors de la conception d'un système temps réel , soit gestion du temps, ordonnancement et communications des processus sur des réseaux.Les auteurs présentent les différents résultats obtenus lors de la simulation d'algorithmes comme Rate Monotonic, Earliest Deadline First, Least Slack Time First, Priority Exchange , Deferrable Server, Sporadic Server avec et sans préemption ainsi que les protocoles permettant de régulariser l'accès aux ressources comme Priority Ceiling Protocol, Semaphore Control, Priority Limit, Basic Priority Inheritance.Les auteurs présentent ensuite les principaux systèmes temps réel distribués connus soit Spring, Harts, Mars, Maruti et Chaos.

. Calculating the Maximum Execution Time of Real Time Programs

Peter Puschner et Christian Koza - Université Technique de Vienne

Un résumé des techniques permettant de mesurer les temps d'exécution des programmes.

. Analysis of Deadline Scheduled Real Time Systems

Marco Spuri - INRIA- Rapport de recherche N° 2772 - Janvier 1996

Dans ce rapport, l’auteur présente une technique pour analyser la faisabilité de systèmes temps réel à ordonnancement par échéance la plus proche en premier.L’analyse considère des tâches sporadiquement périodiques à échéances arbitraires, à jigues sur les instants d’activation et avec partage de ressources.

. Un contrôleur d’ordonnancement temps réel pour la stabilité de Earliest Deadline en surcharge : le Régisseur

J. Delacroix - Thèse de doctorat de l’Université Pierre et Marie Curie Spécialité Informatique - 1994


Dans sa thèse, l’auteur présente les principaux algorithmes théoriques d’ordonnancement, notamment Earliest Deadline qui permet d’ordonnancer conjointement des tâches apériodiques et apériodiques. Elle présente ensuite les résultats de simulations visant principalement à étudier le comportement d’Earliest Deadline en situation de surcharge du système et à étudier les remèdes possibles. Des deux options étudiées : suppression des requêtes fautives en fonction de leur laxité ou d’un critère d’importance, Melle Dalacroix retient la seconde afin de réaliser un organe de régulation qui octroie la qualité de stabilité à Earliest Deadline.Les spécifications de cet organe appelé le Régisseur sont ensuite décrites ainsi que le modèle de tâche permettant son implémentation. Un exemple d’application concernant un système de contrôle radar est ensuite donné.

. Synthèse sur l’ordonnancement temps réel réparti et implantation d’un ordonnanceur temps réel réparti au sein du micronoyau Chorus

C. Santellani -Rapport de stage DEA - DEA SI - Université Pierre et Marie Curie (juin 1994)

Dans ce rapport de stage DEA, Monsieur Santellani présente l’implémentation d’un ordonnanceur à échéances réparti réalisé au CNAM.L’auteur effectue d’abord une synthèse des techniques d’ordonnancement tempréel centralisé puis réparti. Il présente ensuite le micronoyau Chorus, l’ordonnanceur à échéances construit au-dessus de ce micronoyau ainsi que le Régisseur et sa fonction de garantie qui ont pour mission de régulariser le fonctionnement de l’ordonnanceur.Il décrit l’implémentation locale réalisée ainsi que les travaux déjà réalisés concernant la répartition.

. Developing Software with Predictable Timing Behavior

Peter Puschner et Ralph Zainlinger - Université Technique de Vienne. Mise en place d’une plate-forme Chorus, Conception et implantation d’un ordonnanceur à échéances au sein du noyau Chorus Olivier Gaultier - Yves Olivier Métais Mémoire en vue d’obtenir le diplôme d’ingénieur CNAM en Informatique (1994)

Dans ce mémoire, les auteurs présentent leur travail concernant l’implantation d’un


ordonnanceur à échéances au sein du noyau Chorus. Après une présentation générale du système distribué Chorus et une étude de l’ordonnanceur de base, ils exposent leurs choix concernant l’implémentation du nouvel ordonnanceur : traîtement commun des tâches périodiques et apériodiques avec Earliest Deadline, utilisation d’une structure d’arbre parfait partiellement ordonné pour accueillir les descripteurs des tâches de la classe Echéance prêtes à être exécutées.Les auteurs présentent ensuite les résultats de tests de performances, le benchmark utilisé étant le Rhealstone. D’après ces tests, il semble qu’en comparaison avec l’ordonnanceur original, le temps de préemption double dès la douzaine d’activités.

. Etude de l’efficacité du Régisseur dans le contexte du système Chorus monosite

C. Santellani - CNAM

Ce document présente les résultats obtenus lors de simulations afin d’étudier l’efficacité du Régisseur dans le cas de surcharge d’un système ordonnancé par Earliest Deadline, le système étudié étant l’ordonnanceur à échéances intégré au micronoyau Chorus construit par l’auteur. Pour chaque simulation, les mesures enregistrées concernent :. le nombre de fautes temporelles de chaque tâche.. le nombre de révocations subies par chaque tâche.. le nombre d’ajournements subies par une tâche.. l’efficacité de l’ordonnanceur.Un des principaux résultats obtenus montre que, pour des charges individuelles croissantes avec l’importance des tâches, l’efficacité est de 100 % avec le Régisseur, 70 % sans le Régisseur pour une charge totale de 140%.

.Scheduling in Real-Time Systems : Problems and Algorithms

Ken Chen et Paul MuhlethalerDépartement Réseaux de l’ENST Paris et Projet Reflecs INRIA

Après une présentation des algorithmes théoriques d’ordonnancement les plus connus, les auteurs introduisent, en parallèle de la notion d’échéance celle de Juste-à-Temps (Just_In_Time), cette dernière étant la date optimale d’exécution pour une tâche. Ils citent l’ exemple d’un missile interceptant un objet volant : l’instant de tir doit être aussi proche que possible de l’instant optimal de tir, celui qui permettra au missile d’atteindre sa cible.Ils proposent ensuite un modèle de tâche dans lequel celle-ci est décrite par une fonction du temps (Time Value Fonction) ainsi qu’un algorithme adapté.


. Projet echéance : Interface de Programmation

C. Santellani - CNAM- Laboratoire ASI - Janvier 1996

Dans ce document, l’auteur décrit l’interface de programmation associée à l’ordonnanceur à échéances.

. A test bed for distributed real-time scheduling experimentation based on the Chorus micro-kernel

Joëlle Delacroix - Christian Santellani - CNAM - Département d’Informatique

Ce document très court résume les choix faits pour la plate-forme temps réel CNAM.

. Plate-forme temps réel : état actuel et évolutions

C. Santellani - CNAM - Septembre 1995

Ce document présente l’état de la plate-forme d’expérimentation temps réelreposant sur le micronoyau Chorus. L’ordonnanceur à échéances et le Régisseur ont été intégrés au micronoyau Chorus et l’agencement matérielle de la plate-forme mis en place, soit un site de suivi d’exécution et de développement (site MIX) et trois sites temps réel. La procédure de chargement d’un acteur sur un site temps réel est opérative. Reste à développer le protocole de diffusion totalement ordonné pour implanter le système temps réel réparti projeté.

. Un simulateur d’ordonnancement de tâches temps réel « Approche orientée objets, langage ADA »

Juan Marce-Marondo Mémoire en vue d’obtenir le diplôme d’ingénieur CNAM en Informatique

Dans son mémoire, Monsieur Marondo présente ses travaux concernant la réalisation d’un simulateur conçu pour analyser les performances des algorithmes théoriques d’ordonnancement lorsqu’ils


travaillent avec des tâches dont les paramètres temporels sont variables et lorsque des tâches apériodiques doivent être ordonnancées.Après une description des algorithmes utilisables soit Rate Monotonic, Earliest Deadline, Priorités Empiriques, Traîtement d’Arrière-Plan, Serveur de Scrutation et Serveur Sporadique, l’auteur présente les méthodes utilisées pour la conception du simulateur soit analyse et conception orientées objet, le langage d’implémentation étant le langage ADA.L’auteur présente ensuite les résultats de diverses simulations visant à démontrer que les théories actuelles sont mal adaptées au problème posé : ordonnancer des tâches apériodiques et des tâches à paramètres temporels variables.

. Ordonnancement temps réel par réseaux de neurones

Carlos B.Cardeira - Thèse en vue de l'obtention du titre de Docteur Ingénieur de l'Institut National polytechnique de Lorraine.

Dans cette thèse, l'auteur expose d'abord les spécifications et modèles de tâches possibles pour travailler en temps réel. Il expose ensuite les principaux algorithmes d'ordonnancement et effectue une classification en fonction de divers critères tels que : types des contraintes temporelles, caractère statique ou dynamique des priorités,etc....L'auteur présente ensuite la technique des réseaux de neurones et étudie les possibilités de l'appliquer à l'ordonnancement.Il conclut son étude par une analyse de l'ordonnancement des messages, notamment dans les réseaux de terrain.Cette thèse présente des aspects originaux, tant en ce qui concerne l'application des réseaux de neurones à l'ordonnancement que l'ordonnancement des messages.

. A Local area network architecture for communication in Distributed Real-Time Systems

K. Arvind - Krithi Ramamritham - John A. Stankovic Technical Report 91-04 Department of Computer Science -University of Massachusetts

Pour les auteurs, les systèmes temps réel distribués de demain nécessiteront de nouvelles architectures incorporant de nouvelles classes de services et de protocoles afin de permettre des communications temps réel. Dans cette optique, ils proposent RTLAN (Real Time Local Area Network), une


architecture à quatre couches caractérisée par de nouvelles classes de services prenant en compte les contraintes de temps des messages.Les quatre couches proposées sont les suivantes :1) La couche physique est constituée de canaux physiques et d’interfaces multiples afin de garantir la tolérance aux fautes et les performances.2) La couche MAC ou couche de Contrôle d’Accès au Médium utilise des protocoles temps réel spécialisés.3) La couche LLC ou couche de Contrôle de Liaison incorpore des algorithmes d’ordonnancement traitant les contraintes de temps associées aux messages.4) La couche application implémente des applications où les contraintes de temps sont primordiales.Les auteurs présentent ensuite différents types de réalisations et d’études.Pour des messages périodiques spécifiés de façon statique, on peut dédier un canal physique séparé et utiliser l’algorithme Monotonic Rate particuliérement adapté à ce problème.Cette configuration a été étudiée par Liu et Layland, Lehovsky et Sha. Strosnider a ensuite étendu le résultat en réalisant un serveur périodique utilisant les algorithmes du Serveur Ajournable et d’Echange de Priorité afin d’intégrer les messages apériodiques.Enfin, les auteurs décrivent divers protocoles comme le protocole à résolution de priorité (IEEE 802.5), le protocole IEEE 802.3D fondé sur Earliest Deadline et les protocoles à fenêtre utilisant l’algorithme MLF (Minimum Laxity First).

. Causal Deliveries in Unreliable Networks with Real-Time Delivery Constraints

R. Baldoni - A. Mostefaoui - M. Raynal Rapport de recherche N° 2427 - INRIA (Décembre 1994)

. Gestion de messages temps réel sur Ethernet : un protocole déterministe à échéances

G. Le Lann - N. Rivierre - INRIA

. Failure Mode and failure Characteristics of a TDMA driven Ethernet

J. Reisinger - Université de Vienne (Avril 1991)

. Inside the MARS Operating System


J.Reisinger - Institut de l’Informatique Technique - Université de Vienne

Dans cet article, l’auteur décrit l’architecture du système temps réel réparti MARS (Maintenable Real-Time System). Ce système a été conçu et développé à l’Université de Vienne. Il nous décrit la structure d’un noeud MARS et les concepts généraux de son architecture logicielle fondée sur une approche statique. Il présente ensuite les principes de communication par messages du système, le protocole utilisé étant le protocole TDMA.

. Implementing a Predictable Real time Multiprocessor Kernel - The Spring Kernel

L.D. Molesky - K. Ramamritham - C.Shen - J.A Stankovic - G. ZlokapaDepartment of Computer and Information Science - Université du Massachusetts

. SpringNet : An Architecture for High Performance, Predictable, and Distributed Real Time Computing

John.A Stankovic - Douglas Niehaus - Krithi Ramamritham Department of Computer and Information Science - Université du Massachusetts


ORDONNANCEMENT TEMPS REEL - Site d'Isabelle Lanteri ...

Documents

Transcript of ORDONNANCEMENT TEMPS REEL - Site d'Isabelle Lanteri ...