Ordonnancement temps rel

Ordonnancement rparti
par Francis COTTET
Professeur duniversit (ENSMA, Poitiers Futuroscope)
Ingnieur de lInstitut national polytechnique de Grenoble
Docteur s sciences
Jolle DELACROIX
Matre de confrences (Conservatoire national des arts et mtiers, Paris)
Docteur en informatique de luniversit Pierre-et-Marie-Curie
Claude KAISER
Professeur (Conservatoire national des arts et mtiers, Paris)
Ingnieur de lcole polytechnique, ingnieur du gnie maritime
Docteur s sciences
et Zoubir MAMMERI
Professeur duniversit (universit Paul-Sabatier, Toulouse)
Ingnieur, docteur en informatique
Habilit diriger des recherches

1. Introduction aux systmes temps rel et rpartis ......................... S 8 056 - 3

1.1 Systmes rpartis gnraux : caractristiques et problmes
de conception............................................................................................... 3
1.2 Rpartition matrielle et logique................................................................ 4
1.3 Problmes lis aux systmes temps rel et rpartis ................................ 4
2. Placement et migration de tches ...................................................... 5
2.1 Ordonnancement local et ordonnancement global.................................. 5
2.2 Placement de tches.................................................................................... 5
2.3 Placement dynamique de tches ............................................................... 6
2.4 Migration de tches..................................................................................... 8
3. Ordonnancement de messages ............................................................ 9
3.1 Introduction.................................................................................................. 9
3.2 Communication et rseaux temps rel...................................................... 10
3.3 Caractristiques des messages et qualit de service ............................... 11
3.4 Protocoles de niveau MAC (Medium Access Control).............................. 12
3.5 Ordonnancement de messages : principes gnraux et proprits ....... 14
3.6 Ordonnancement de messages priodiques ............................................ 15
3.7 Ordonnancement de messages apriodiques .......................................... 18
3.8 Tableau rcapitulatif .................................................................................... 20
4. Produits et exemples de ralisations ................................................. 20
4.1 Exemples de systmes dexploitation temps rel et rpartis .................. 20
4.2 Mthodes et outils de validation dapplications temps rel .................... 23
5. Conclusion ................................................................................................. 24
Rfrences bibliographiques ......................................................................... 25

L a complexit des procds commander ou superviser, le nombre lev

de donnes et dvnements traiter, la rpartition gographique des proc-
ds, dune part, et larrive depuis plusieurs annes, sur le march, de rseaux
locaux industriels, dautre part, sont tous des facteurs qui ont conduit repenser
les applications temps rel centralises. Aujourdhui, la notion darchitectures

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Informatique industrielle S 8 056 1
ORDONNANCEMENT TEMPS REL _________________________________________________________________________________________________________

temps rel et rparties est communment accepte dans le milieu industriel.

titre indicatif, les domaines dapplications qui font couramment appel aux syst-
mes temps rel et rpartis sont :
les tlcommunications (systmes de commutation) ;
le domaine mdical (assistance et contrle de malades) ;
le contrle dquipements (moteur, freins, suspension...) dans les
vhicules ;
le contrle et la rgulation de trafic en milieu urbain ;
les industries (contrle/commande de procds) ;
le domaine militaire (suivi de trajectoires de missiles) ;
le domaine arospatial (suivi de satellites, pilotage automatique) ;
le multimedia (tlconfrences, tlachat...) ;
la domotique (scurit dhabitations).
Un systme informatique destin commander ou superviser des opra-
tions est compos, le plus souvent, de plusieurs units de traitement (des ordi-
nateurs ou des automates programmables), des capteurs, des actionneurs, des
priphriques de visualisation et de dialogue avec les oprateurs. Lensemble de
ces lments est interconnect par un rseau ou toute une pliade de rseaux
interconnects entre eux (des rseaux industriels, des rseaux bureautiques, des
bus de terrain, etc.), comme le montre la figure A. Ce type de systme est quali-
fi de systme temps rel et rparti (ou distribu ou encore dcentralis).
Dans ce type de systme, lordonnancement de tches et de messages joue un
rle fondamental. Lordonnancement centralis de tches est trait dans larticle
Ordonnancement temps rel. Ordonnancement centralis de ce trait. Cest
lordonnancement de messages qui fait lobjet de cet article.

Calculateur Calculateur Calculateur

CFAO GPAO de gestion

Rseau d'usine

Passerelle
Contrleur Gestion de
de qualit Superviseur maintenance

Rseau de cellule

Automate Commande Commande

programmable numrique de robot

C C Capteurs C C
Bus de Bus de
terrain terrain
A A Actionneurs A A A

Figure A Exemple de systme temps rel et rparti

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 056 2 Techniques de lIngnieur, trait Informatique industrielle
________________________________________________________________________________________________________ ORDONNANCEMENT TEMPS REL
1. Introduction aux systmes
temps rel et rpartis
On appelle systme temps rel et rparti tout systme compos
de plusieurs entits interconnectes par un sous-systme de com-
munication et qui cooprent la ralisation dun ensemble de fonc-
tions sujettes des contraintes de temps (ces contraintes pouvant
tre strictes ou non selon la nature de lapplication laquelle est
associ le systme) [9] [28] [56]. Les systmes temps rel et rpartis
sont des cas particuliers des systmes rpartis. Cest la raison pour
laquelle nous commenons par nous intresser aux systmes rpar-
tis qui ne prennent pas en compte explicitement des contraintes
temporelles, pour voir les principaux problmes poss par ces sys-
tmes et nous verrons ensuite les difficults considrer pour tenir
compte des contraintes de temps.
1.1 Systmes rpartis gnraux :
caractristiques et problmes
de conception
Un systme rparti est constitu dun ensemble de processeurs
relis entre eux par un sous-systme de communication qui leur
permet dchanger des informations. Selon la nature du sous-sys-
tme de communication, on distingue les multiprocesseurs o la
communication peut se passer avec ou sans mmoire commune et
les rseaux dordinateurs o la communication se passe obligatoire-
ment sans mmoire commune (cest--dire, avec change de mes-
sages). Les machines parallles sont constitues de plusieurs
processeurs, en gnral identiques, fortement coupls. Les rseaux
dordinateurs sont forms de machines autonomes, gnralement
htrognes, faiblement couples. Les distances entre les proces-
seurs dun rseau dordinateurs peuvent tre courtes (quelques
dizaines de mtres, voire moins) ou trs importantes (des milliers de
kilomtres, voire plus, pour les rseaux de satellites). Les distances
entre les processeurs dune machine multiprocesseur sont infini-
ment plus petites (quelques centimtres, voire moins).
On dit quun systme rparti est constitu dun ensemble de pro-
cesseurs, de sites ou de nuds interconnects entre eux (figure 1).
Par la suite, nous utiliserons indiffremment, lorsquil ny a pas
dambigut, les termes nud, site et processeur et nous ne ferons
pas de distinction entre les systmes rpartis construits autour
darchitectures multiprocesseurs et ceux construits autour de
rseaux dordinateurs.
Site
Site Rseau Site
de
Site communication Site
Site
Figure 1 Architecture gnrale dun systme rparti
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Informatique industrielle
Le dveloppement des systmes rpartis est motiv par plusieurs
raisons, notamment :
la demande dinterconnecter le plus possible les applications
existantes, en particulier pour les services multimdias (tlconf-
rence, tl-enseignement, tlmdecine, ingnierie cooprative...) ;
la volont daugmenter la disponibilit dun systme informa-
tique pour permettre le remplacement dun composant du systme
par un autre sans dgradation significative (voire sans aucune
dgradation) du service rendu. Cet aspect est primordial dans les
applications temps rel et rparties pour lesquelles les situations
darrt doivent tre les plus rares possibles. Dans les systmes auto-
matiss de production, larrt du systme temps rel est synonyme
dun arrt de production ;
le souci de faciliter lvolution matrielle ou fonctionnelle dun
systme en remplaant ou en ajoutant certains lments sans avoir
arrter les autres lments du systme ;
le partage de ressources matrielles (des imprimantes, des
units de sauvegarde massive...) ou logicielles (des bases de don-
nes, des logiciels...) ;
la demande de plus de puissance de calcul au moindre cot
(par exemple, plusieurs PC en rseau cotent moins cher quun gros
ordinateur) ;
enfin, les besoins dadaptation du systme informatique son
environnement : aujourdhui, que ce soit dans les applications
bureautiques ou dans les applications industrielles, les ordinateurs
participant une application se rpartissent sur des tendues go-
graphiques plus ou moins importantes sur plusieurs tages dun
immeuble, ou sur des dizaines de kilomtres carrs dans le cas de
raffineries de ptrole, par exemple. Il est donc important, pour le
systme informatique, de tenir compte de cette rpartition gogra-
phique.
Les systmes rpartis ont des caractristiques qui les distinguent
des systmes centraliss :
les dlais de communication entre sites varient dun message
lautre et aussi selon les protocoles du rseau de communication
utiliss ;
ils nont pas dhorloge commune. Chaque site a sa propre per-
ception du temps et, comme les horloges physiques drivent par
rapport au temps de rfrence, les diffrents temps lus sur les sites
peuvent tre diffrents une mme heure universelle ;
labsence dune mmoire commune a pour consquence
limpossibilit de dfinir un tat global laide de variables commu-
nes. Encore plus important, lexistence de dlais de communication
variables et labsence dun rfrentiel temporel commun ont pour
consquence que chaque site a sa propre vue qui peut tre diff-
rente de celles des autres sites un mme instant du temps
universel ;
comme le nombre dquipements dun systme rparti est
plus lev que celui dun systme centralis, les risques de
dfaillances y sont plus importants. Des mcanismes de tolrance
aux fautes doivent tre intgrs pour rpondre lexigence de ne
pas dgrader la sret de fonctionnement et, en particulier, la dispo-
nibilit de ces systmes [27] ;
lexistence dinterfaces de communication avec lextrieur
rend les systmes rpartis plus vulnrables aux intrusions ;
les applications rparties sont plus complexes spcifier,
concevoir, implanter, tester et valider.
Limpossibilit de disposer instantanment dun tat global iden-
tique sur tous les sites pose beaucoup de problmes pour la prise de
dcisions relatives la gestion et au partage de ressources, la vali-
dation dactions atomiques faisant intervenir plusieurs sites, lta-
blissement dune vue dun groupe participant une application
S 8 056 3
ORDONNANCEMENT TEMPS REL _________________________________________________________________________________________________________
cooprative, etc. Cest aussi lune des principales sources de com-
plexit des algorithmes de placement de tches (cf. 2).
Exemple : un site i diffuse, linstant t, un message pour informer
les autres sites quil a une charge faible et quil est prt accueillir des
tches en provenance des autres sites. Juste aprs linstant t, une ava-
lanche dvnements locaux se produit et le site i est oblig dexcuter
un nombre important dactions pour rpondre aux vnements surve-
nus, ce qui conduit une saturation momentane de ce site. Les
autres sites recevant le message du site i dcident de lui envoyer des
tches excuter. la rception des tches, le site i les rejette, car il
est en situation de surcharge.
On remarque, travers cet exemple, que les dlais de communi-
cation donnent une image qui peut tre dpasse et qui conduit
entreprendre des oprations (de transfert de tches, par exemple)
qui seront annules.
Beaucoup de travaux ont t dvelopps depuis plus dune quin-
zaine dannes sur les diffrents problmes poss par les systmes
rpartis. Nous conseillons au lecteur dsireux dapprofondir ses
connaissances sur les systmes rpartis de consulter des ouvrages
tels que [4] [14] [25] [39] [45] [60].
1.2 Rpartition matrielle et logique
Les termes dcentralis, rparti et distribu sont souvent utiliss
de manire ambigu. Pour les prciser, il faut tout dabord distin-
guer la rpartition matrielle et la rpartition logique.
La rpartition matrielle (ou encore dcentralisation physique)
est obtenue en utilisant plusieurs units de traitement qui sont inter-
connectes par un sous-systme de communication. Par exemple,
un systme de contrle/commande constitu de capteurs et
dactionneurs en contact direct avec le procd physique, dautoma-
tes programmables dans les salles de commande et de stations de
travail dans les salles de CAO, est un systme avec une architecture
matrielle rpartie (ou dcentralise).
La taxinomie est plus complexe lorsquil sagit du logiciel. En
effet, il faut distinguer :
la rpartition des donnes (ou rpartition de linformation) ;
la rpartition des traitements ;
la rpartition du contrle.
Lensemble des informations (variables simples, fichiers...) qui
sont partages entre des tches distantes peut tre stock sur un
seul site (on parle, dans ce cas, de stockage centralis de linforma-
tion) ou clat sur plusieurs sites (on parle, dans ce cas, de stockage
dcentralis de linformation). Cette rpartition ne prjuge en rien
sur la faon dont le contrle de laccs aux informations partages
sera gr.
La rpartition des traitements conduit affecter les program-
mes (ou tches) des sites pour y tre excuts. Cette rpartition ne
prjuge en rien de la faon dont lexcution des programmes sera
gre, cest--dire, de la faon dont sera effectu le contrle de
lexcution des tches.
Le contrle concerne le dclenchement et larrt des tches, le
transfert des tches dun site vers un autre, laccs aux ressources
partages, la validation doprations faisant intervenir plusieurs
sites, etc. Il peut tre la charge dun seul site (il sagit dun contrle
compltement centralis), dune partie des sites (il sagit dun con-
trle partiellement rparti) ou de tous les sites (il sagit dun contrle
compltement rparti). Lorsque le contrle est distribu, la prise de
dcision (par exemple, pour valider une opration sur une base de
donnes, pour lancer la production dun ensemble de pices ou,
encore, pour sortir le train datterrissage dun avion) peut tre prise
par chaque site sparment, par tous les sites (dans ce cas, si un
seul site manque, la dcision ne peut tre prise) ou la majorit des
sites (on parle, dans ce cas, de dcision par consensus).
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 056 4 Techniques de lIngnieur, trait Informatique industrielle
Il est important de signaler que la rpartition (ou dcentralisation)
doit tre considre sparment pour chaque fonction du systme.
Selon les spcificits dun systme, on peut avoir des fonctions cen-
tralises, dautres partiellement rparties et dautres compltement
rparties. Par exemple, on peut avoir dans un mme systme : une
fonction compltement rpartie pour la synchronisation dhorloges,
une base de donnes clates sur plusieurs sites, mais toutes les
transactions sur la base sont contrles par un seul site et une ges-
tion centralise des fichiers. Tout nest pas rparti dans un systme
rparti ! Il est clair quil ne peut y avoir de rpartition logicielle sans
rpartition matrielle, mais la rciproque nest pas vraie. La dcen-
tralisation matrielle peut aider ou inciter la rpartition logicielle.
1.3 Problmes lis aux systmes temps
rel et rpartis
Dans le cas des systmes temps rel, la rpartition est parfois
indispensable : le procd physique est fortement rparti, les traite-
ments, les contraintes temporelles dpassent les capacits dun seul
processeur, larrt du systme est inacceptable
La rpartition des systmes temps rel introduit de nouveaux pro-
blmes, notamment :
les calculs fonds sur les contraintes temporelles qui font rf-
rence au temps chronomtrique ou une date absolue risquent de
comporter des erreurs de calcul trop importantes et, partant, de ne
pas tre crdibles, cause de drives trop grandes entre les horlo-
ges des diffrents sites ;
lobservation de lvolution des diffrents constituants du pro-
cd est retarde et diffrente dun site un autre cause des dlais
de communication variables ;
les tests dordonnanabilit et les calculs de garantie des con-
traintes de temps de tches communicantes, donc lordonnance-
ment temps rel rparti, sont tributaires de ces drives dhorloges et
de ces dlais de communication ;
la tolrance aux fautes est beaucoup plus complexe, ce qui
rend encore plus difficile de tolrer des fautes tout en respectant les
contraintes de temps.
Dans le cas de lordonnancement temps rel qui nous intresse
ici, la rpartition implique lordonnancement conjoint de tches et
de messages.
Le respect ou non des contraintes temporelles des messages se
rpercute de manire directe sur celui des tches, car lattente de
rception dun message par une tche est quivalente lattente
dacquisition dune ressource ; si le message narrive pas temps,
les contraintes temporelles de la tche ne peuvent tre garanties.
Lordonnancement de tches dans un systme rparti se rgle
deux niveaux : au niveau de chaque processeur (ordonnancement
local) et au niveau du placement de tches sur les processeurs. Le
problme dordonnancement local a t prsent dans larticle
[S 8 055] de ce trait ; le problme de placement sera tudi dans le
paragraphe suivant.
La conception et limplantation des systmes temps rel et rpar-
tis ncessitent des protocoles de communication qui garantissent
aux tches communicantes de recevoir, dans les dlais, les messa-
ges qui leur sont destins. Pour les messages avec des chances
strictes de dlivrance, il faut que les protocoles donnent des garan-
ties et, pour les messages non critiques du point de vue temporel, la
stratgie du protocole est le meilleur effort (cest--dire, minimiser
le retard des messages et le nombre des messages tardifs). Toute-
fois, la notion de meilleur effort doit tre utilise avec certaines
prcautions dans le cas de systmes temps rel. Par exemple, per-
dre une image sur dix dans le cas dune animation vido dans une
salle de commande est souvent sans consquence, par contre per-
dre neuf images sur dix rend le systme de supervision inutile aux
yeux des oprateurs. La garantie des contraintes temporelles de
messages passe par un ordonnancement adquat des messages.
________________________________________________________________________________________________________ ORDONNANCEMENT TEMPS REL
Le paragraphe 3 est rserv ltude du problme de lordonnance-
ment de messages et de ses solutions.
Dans un systme temps rel et rparti, les tches sont synchroni-
ses en utilisant le temps chronomtrique (par exemple, activation
de tches des instants prcis ou de manire priodique). Il en est
de mme pour la datation de donnes et dvnements apparais-
sant sur les diffrents sites. Le bon fonctionnement dun systme
rparti ncessite le plus souvent lexistence dun temps global
accessible tous les sites. La solution la plus couramment utilise
pour tablir un temps global est la synchronisation dhorloges phy-
siques. Dautres solutions fondes sur lutilisation de rcepteur dun
temps diffus par une station de radio ou un satellite commencent
tre envisages. Beaucoup dalgorithmes ont t proposs pour
rgler le problme de synchronisation dhorloges. Le lecteur dsi-
reux dapprofondir ses connaissances sur ce sujet peut consulter les
rfrences [19] [21].
2. Placement et migration
de tches
2.1 Ordonnancement local
et ordonnancement global
Dans les systmes rpartis, on distingue deux types
dordonnancement : lordonnancement local et lordonnancement
global.
Lordonnancement local consiste allouer un processeur aux
tches affectes ce processeur, en tenant compte de leur urgence
et de leur importance.
Lordonnancement global a, quant lui, pour mission dessayer
de garantir les contraintes de tches en exploitant les capacits de
traitement des diffrents processeurs composant le systme rparti
considr (en procdant, ventuellement, des migrations de
tches).
Ainsi, un ordonnanceur local a pour objectif de rpondre la
question quand excuter une tche sur le processeur local, de
manire respecter les contraintes imposes cette tche ? . Un
ordonnanceur global, quant lui, cherche rpondre la question
quel est le site le mieux adapt pour excuter une tche donne,
de manire respecter ses contraintes ? .
Le placement et lordonnancement sont indissociables dans le cas
des applications temps rel : il faut placer les tches sur lensemble
des processeurs de telle sorte que lordonnancement local conduise
imprativement au respect des contraintes de temps des tches cri-
tiques du point de vue temporel. Lordonnancement local utilise des
algorithmes comme ceux prsents dans larticle [S 8 055]. Nous
nous intressons ici aux diffrents aspects de lordonnancement
global, cest--dire, les aspects lis au placement et la migration
des tches.
2.2 Placement de tches
2.2.1 Problme de placement de tches
premire vue et de manire simplifie, on peut considrer que
le problme de placement (ou allocation, en anglais noter aussi
que certains utilisent le terme allocation de tches au lieu de
placement de tches ) de n tches sur p processeurs conduit
tudier pn cas de placements possibles (en supposant videmment
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Informatique industrielle
quune tche ne requiert quun seul processeur la fois pour son
excution). On remarque aisment que si les paramtres n et p ont
des valeurs leves, lobtention dune solution au bout dun temps
raisonnable devient vite impossible. Sauf pour des cas trs simples,
le problme de placement de tches est un problme NP-complet
[20] (cest--dire, un problme qui ne se rsout pas avec un algo-
rithme qui donne un rsultat au bout dun temps polynomial). Cest
la raison pour laquelle la quasi-totalit des travaux qui ont trait le
problme de placement de tches utilisent des techniques approxi-
matives et des heuristiques.
Le problme de placement consiste souvent rechercher dabord
une solution qui respecte le plus possible les contraintes initiales
puis choisir le meilleur placement, si plusieurs placements ont t
trouvs. La recherche dun placement doit tenir compte des con-
traintes initiales des tches, de lenvironnement support ainsi que
des critres optimiser.
Les contraintes initiales peuvent tre diverses :
existence ou non de tches contraintes strictes pour lesquel-
les la garantie des chances est une ncessit quelle que soit la
charge du systme ;
obligation pour certaines tches de rsider sur un processeur
prcis disposant de ressources matrielles ou logicielles spcifiques
(par exemple, une tche dacquisition de mesures doit se trouver
sur la machine en contact direct avec le procd physique) ;
limitation du nombre de tches sexcutant sur chaque
processeur ;
interdiction deux tches donnes de sexcuter sur un mme
site (par exemple, pour des raisons de tolrance aux fautes, on
exige quune tche et sa copie ne sexcutent pas sur un mme
site) ;
regroupement de tches utilisant certaines ressources ;
etc.
Afin de chercher un bon placement, il est important de prciser
les critres (ou fonctions de cots) optimiser. Dans les systmes
temps rel, le critre le plus important est videmment le respect
des contraintes temporelles : (1) garantir le respect des contraintes
temporelles des tches contraintes strictes et (2) minimiser le
nombre de tches contraintes relatives qui dpassent leurs
chances. Dautres critres peuvent tre envisags ensuite. Beau-
coup de travaux ont t dvelopps dans le contexte de lordonnan-
cement non temps rel (cest--dire, dans des problmes
doptimisation concernant, par exemple, la gestion de production
ou des emplois du temps, le transport, lintelligence artificielle, etc.)
montrant comment on peut optimiser un ou plusieurs critres. Dans
le cas de lordonnancement dans des systmes rpartis, on peut
avoir comme critre doptimisation :
la minimisation de la dure totale dexcution de lensemble
des tches ;
la minimisation du nombre de processeurs utiliss ;
la minimisation de la charge de communication ;
lquilibrage de charge des processeurs.
Selon la nature de lapplication et le systme support de lapplica-
tion, on est amen privilgier certains critres. Par exemple, si le
rseau de communication utilis est un rseau Ethernet un rseau
qui ne garantit pas de temps de rponse born et dont le rendement
scroule si les demandes de transmission dpassent un certain
seuil il est souvent conseill de chercher particulirement mini-
miser les communications pour permettre aux tches places sur
des machines distantes de recevoir leurs messages temps et donc
de se terminer temps.
Les critres optimiser sont parfois en contradiction les uns avec
les autres. Par exemple, rduire la charge de communication con-
duit regrouper les tches sur un nombre rduit de processeurs, ce
qui aboutit donc des processeurs plus chargs que dautres.
S 8 056 5
ORDONNANCEMENT TEMPS REL _________________________________________________________________________________________________________
2.2.2 Classes dalgorithmes et techniques
de rsolution du problme de placement
Selon le nombre de processeurs, le nombre de tches placer et
les contraintes temporelles, les contraintes de prcdence et les
contraintes de ressources, deux familles dalgorithmes peuvent tre
utilises :
les algorithmes exacts (ou optimaux) qui procdent par nu-
mration pour trouver la solution optimale. De tels algorithmes
deviennent trs vite irralistes lorsque la taille du problme est
importante, cause de lexplosion combinatoire de cette
numration ;
les algorithmes approchs (ou non optimaux) qui permettent
de trouver une solution qui ne respecte pas ncessairement toutes
les contraintes. Parfois, la solution obtenue peut tre la solution
optimale.
Les mthodes utilises par les algorithmes de placement de
tches sont notamment :
la technique du branch-and-bound, la programmation dynami-
que et la thorie des graphes, pour les algorithmes optimaux (la
thorie des graphes tant la technique la plus utilise). Une des
mthodes utilises dans les algorithmes de placement fonds sur la
thorie des graphes consiste dterminer des coupes minimales
dun graphe contenant les tches, les processeurs et les liens de
communication, pour dterminer des solutions de placement. Les
algorithmes fonds sur la programmation dynamique reprsentent
le problme de placement sous forme dun problme doptimisation
avec minimisation dune fonction de cot sous contraintes ;
les mthodes approximatives et heuristiques (telles que le
recuit simul, le tabou, les algorithmes gntiques, les rseaux de
neurones et les algorithmes gloutons) pour les algorithmes non
optimaux. Les mthodes itratives (algorithmes gntiques,
rseaux de neurones, recuit simul et tabou) partent dune solution
et tentent de lamliorer par des itrations successives. Les algorith-
mes gloutons tentent datteindre la solution sans remettre en ques-
tion les choix dj effectus. Ils fournissent en gnral des solutions
moins bonnes que les autres mthodes.
Dans les applications non temps rel, lexception des applica-
tions de petites tailles, les algorithmes non optimaux sont quasi-
ment les seuls tre utiliss dans la pratique. Pour des applications
temps rel contraintes temporelles strictes, les algorithmes non
optimaux sont inadquats, car ils ne donnent aucune garantie quant
au respect des contraintes temporelles des tches. Par consquent,
des algorithmes optimaux doivent tre utiliss. Pour viter les pro-
blmes dexplosion combinatoire, on impose souvent des contrain-
tes initiales restrictives permettant de trouver, au bout dun temps
raisonnable, une solution garantissant le respect des contraintes
temporelles strictes des tches. Par exemple, on impose que toute
tche critique du point de vue temporel doit tre priodique, ou
encore que toutes les ressources doivent tre affectes une tche
avant de dmarrer son excution.
2.2.3 Placement statique et placement dynamique
Les tches constituant une application rpartie peuvent tre affec-
tes de manire statique ou dynamique aux sites. Dans le premier
cas, on parle de placement statique, dans le deuxime, de place-
ment dynamique. Dans le premier cas, il ne peut plus y avoir de pla-
cement des tches pendant lexcution de lapplication, le
placement des tches est donc fig la configuration du systme.
Dans le deuxime cas, lalgorithme dordonnancement choisit de
placer chaque tche sur le site le plus apte respecter ses contrain-
tes temporelles, au moment o elle est dclenche.
Le placement statique utilise une connaissance statique : le nom-
bre de tches, les cots de communication, la charge du rseau, les
bornes des temps de transfert de messages, les temps dexcution
sur les processeurs, etc. sont dtermins une fois pour toutes. Le
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 056 6 Techniques de lIngnieur, trait Informatique industrielle
placement statique est la solution utilise aujourdhui dans les
applications temps rel rparties industrielles. Il y a deux principales
raisons cela :
le placement dynamique est complexe, encore peu tudi, et
donne rarement une garantie absolue quant au respect des con-
traintes temporelles ;
le choix dune architecture matrielle et logicielle (nombre et
types de processeurs, type de rseau, types de systmes dexploita-
tion...) est souvent dict par les spcificits de lapplication et on
construit, par consquent, une architecture sur mesure pour per-
mettre aux tches de respecter leurs chances tout en tant pla-
ces de manire statique.
On a dpass aujourdhui le stade des applications temps rel et
rparties composes uniquement de tches cycliques de rgulation
avec un nombre dentres et de sorties parfaitement connu et o
lon prvoit un arrt durgence ds quun vnement survient. Impo-
ser une connaissance fige sur une application temps rel et rpar-
tie complexe est synonyme dun surdimensionnement parfois
excessif de larchitecture. Cest ainsi que des travaux sont effectus
pour viter ce surdimensionnement et proposer des mcanismes
plus dynamiques [13] [52] [54] [56] [57] [74]. On soriente la fois
vers un ordonnancement local dynamique et un placement dynami-
que.
La technique idale du placement serait celle qui permettrait de
trouver instantanment le meilleur site pour accueillir une tche qui
est dclenche ou qui doit reprendre son excution aprs une inter-
ruption. Le transfert dune tche dun site vers un autre ne doit
remettre en cause aucune des tches plus prioritaires en cours
dexcution sur le systme rparti et ne doit pas affecter les perfor-
mances globales du systme. Ce rsultat est impossible atteindre
dans la pratique cause du dlai ncessaire pour obtenir un tat
exact et valide de lensemble des sites dun systme rparti (parce
que lobtention de cet tat demande de nombreux messages avec
des dlais de transfert variables). Par ailleurs, les transferts nces-
saires pour la migration de tches peuvent compromettre le respect
des contraintes temporelles de tches et les performances globales
du systme.
2.3 Placement dynamique de tches
On distingue deux grandes classes dalgorithmes de placement
dynamique :
le placement sans coopration (ou placement aveugle) : au
moment o une requte dexcution de tche est cre, un site est
choisi de manire alatoire pour excuter la tche considre ;
le placement avec coopration : les sites schangent des
informations pour dterminer le site sur lequel sera place la tche
dont la requte dexcution vient dtre cre.
Les techniques de placement sans coopration sont simples
mettre en uvre. Comme elles ne tiennent pas compte des charges
des sites, elles peuvent conduire des surcharges de certains sites,
donc des chances de tches qui ne seront pas respectes.
Les techniques de placement avec coopration tiennent compte
de la charge dexcution de chaque site avant de lui affecter de nou-
velles tches. Quand le surcot en temps quelles introduisent est
acceptable, elles sont alors plus efficaces pour lquilibrage de
charge et le respect des chances de tches, mais elles sont plus
complexes mettre en uvre.
Un algorithme de placement avec coopration est compos dune
fonction de contrle et, ventuellement, dune fonction de collecte
dinformations [17], [59]. Cette dernire fonction, quand elle est pr-
sente, a pour objectif de recueillir et de maintenir des informations
concernant ltat et la charge des sites du systme rparti. La fonc-
tion de contrle permet de dterminer les sites de placement des
tches.
________________________________________________________________________________________________________ ORDONNANCEMENT TEMPS REL
2.3.1 Collecte dinformations de charge
Les changes dtat entre sites peuvent se faire de manire prio-
dique ou la demande. Il est vident que plus les changes dinfor-
mations dtat des sites sont frquents, plus la vue de ltat global
du systme est prcise. En contrepartie, plus la charge du rseau est
leve, plus la probabilit dchec du respect des contraintes tem-
porelles de tches distantes communicantes est leve, car les mes-
sages changs entre tches peuvent ne plus arriver temps. Il faut
essayer de trouver un compromis entre le vieillissement des infor-
mations de charge et le cot de communication engendr par leur
collecte.
Au lieu de raisonner sur une charge exacte des processeurs, on
utilise comme indicateur de charge la notion de seuil de charge, et
on parle alors de site ayant une charge normale, de site sous-charg
(ou faiblement charg) et de site surcharg (ou avec une charge le-
ve).
Limpossibilit davoir instantanment un tat global fait que la
plupart des algorithmes de placement dynamique proposs ne don-
nent pas de solution optimale. On soriente donc vers lutilisation de
techniques approches et dheuristiques.
2.3.2 Contrle de transfert
Deux aspects sont souvent distingus dans la fonction de contrle
de transfert : la politique de transfert et la politique de localisation.
La politique de transfert dcide du choix de la tche transfrer. La
politique de localisation dcide du choix du processeur vers lequel
sera transfre la tche slectionne.
Pour la politique de transfert, on distingue deux approches :
celle des seuils de charge : lorsque la charge dexcution sur
un processeur dpasse un seuil fix, les tches nouvellement
dclenches doivent tre places sur dautres sites. Et inversement,
lorsque la charge du processeur est au-dessous de ce seuil, celui-ci
excute les tches dclenches localement et peut aussi accepter
des tches provenant dautres sites ;
celle du placement systmatique : une procdure de recherche
dun site de placement est lance pour chaque nouvelle requte
dexcution de tche, et cela indpendamment de la charge du site
sur lequel cette requte a t faite.
Le choix dune politique de localisation dpend de lexistence ou
non dune fonction de collecte dinformations de charge. Si cette
dernire fonction existe, le site prsentant la charge la plus faible est
choisi pour accueillir la tche placer. Si elle nexiste pas, le choix
du site de localisation peut se faire principalement de deux
manires :
tous les sites sont interrogs pour trouver un site faiblement
charg. Si un seul site faiblement charg est trouv, la tche placer
est transfre vers ce site. Si plusieurs sites faiblement chargs sont
trouvs, le site qui engendre le cot de transfert le plus faible est
retenu. Si aucun site faiblement charg nest trouv, la tche doit
tre excute localement ;
la demande de placement est envoye tous les sites. Par un
protocole daccord avec consensus, lensemble des sites se met
daccord sur le site de placement [24].
Le cot de transfert dune tche dpend principalement du rseau
utilis. Si tous les sites sont relis par rseau local en bus diffu-
sion, le cot de transfert est quasiment le mme quels que soient les
sites concerns ; par contre, si les sites sont interconnects par un
rseau en structure maille, le cot de transfert dpend de chaque
couple de sites (car entre deux sites, on peut trouver plusieurs sites
intermdiaires qui relayent les messages et qui conduisent donc
un accroissement du dlai de communication). Pour rduire le cot
de transfert de tches, certains prconisent, lorsque cest possible,
de prvoir une copie du code et du contexte initial de chaque tche
sur tous les sites sur lesquels cette tche peut sexcuter. Ainsi, ds
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Informatique industrielle
quun site de placement est trouv, la tche placer peut directe-
ment commencer son excution.
2.3.3 Placement dynamique centralis
et placement dynamique rparti
Pour la collecte dinformations relatives la charge des sites, cha-
que site peut avoir sa propre vue de ltat du systme (il sagit dune
solution rpartie) ou bien toutes les informations dtat peuvent tre
stockes sur un seul site (il sagit dune solution centralise). Dans le
cas dune fonction de collecte centralise, chaque processeur peut
envoyer sa charge au site central, soit priodiquement, soit quand
elle a chang de faon significative, ou encore la demande du site
central. Dans le cas dune fonction de collecte rpartie, chaque site
peut collecter les informations concernant les autres sites de
manire priodique ou bien quand il a besoin de transfrer une
tche.
Les dcisions de transfert peuvent tre prises par un seul site pri-
vilgi (il sagit dune solution centralise), ou bien chaque site peut
dcider sparment de transfrer des tches (il sagit dune solution
rpartie). De la mme manire, la fonction de localisation peut tre
centralise (dans ce cas, tout site qui veut transfrer une tche
demande au site central de lui trouver un site de placement) ou bien
rpartie (dans ce cas, le choix du site de placement est effectu par
chaque site qui souhaite transfrer une tche ou par consensus
entre les sites du systme).
Il y a donc plusieurs faons de concevoir des algorithmes de pla-
cement dynamique avec coopration. On peut avoir des algorith-
mes avec ou sans collecte dinformations de charge. On peut avoir
des algorithmes compltement centraliss (toutes les fonctions sont
centralises), des algorithmes partiellement rpartis (certaines fonc-
tions sont centralises et dautres rparties) ou des algorithmes
compltement rpartis (toutes les fonctions sont rparties).
Les solutions centralises sont simples mettre en uvre, mais
prsentent deux inconvnients majeurs :
elles ne sont pas tolrantes aux fautes. La panne du site sur
lequel est implante une fonction de lalgorithme de placement
entrane limmobilisation du placement, si aucun mcanisme de
redondance na t prvu. Cela conduit ajouter un mcanisme
dlection, coteux en messages et en temps, qui permet de choisir
un site parmi un ensemble de sites de secours explicitement conus
pour reprendre le contrle lorsque le site central courant tombe en
panne ;
elles conduisent la cration dun goulet dtranglement au
niveau du processeur qui gre la fonction, ce qui peut avoir comme
consquence le ralentissement de tout le systme.
Les solutions rparties demandent la participation de tous les
sites la ralisation de lalgorithme de placement, ce qui donne plus
de capacits de tolrance aux fautes. Linconvnient de ces solu-
tions est leur complexit. Comme, dans les applications temps rel,
la tolrance aux fautes est souvent une exigence de base, les solu-
tions rparties sont plus adaptes.
Pour trouver un compromis entre la simplicit des solutions cen-
tralises et la robustesse des solutions rparties, certains prconi-
sent lutilisation dapproches hybrides [74] : grer le placement de
manire hirarchique. Par exemple, si le systme rparti est com-
pos de plusieurs machines multiprocesseurs, le placement de
tches peut tre gr de la manire suivante : sur chaque machine,
on fixe un processeur privilgi qui gre, de manire centralise, les
informations de charge des processeurs de cette machine. Les pro-
cesseurs privilgis des diffrentes machines schangent leurs
informations de charge. Si la charge des processeurs locaux le per-
met, le processeur privilgi associ une machine donne dcide
de placer les tches dclenches localement sur des processeurs
locaux. Sinon il utilise les informations de charge des autres machi-
nes, pour leur demander daccepter de recevoir des tches.
S 8 056 7
ORDONNANCEMENT TEMPS REL _________________________________________________________________________________________________________

2.4 Migration de tches Politique linitiative de loffreur

Quand un site se considre comme sous-charg, il informe les
autres de sa capacit (dite information de surplus) daccepter des
Les algorithmes de placement dynamique permettent de trouver tches. Lorsquun site dcide de migrer une tche, il choisit le site
un site o sera excute une tche qui vient dtre cre ou dclen- ayant diffus rcemment le plus de capacits (ou de surplus)
che. Si une tche place sur un site doit sexcuter entirement sur accueillir des tches (figure 2 b).
le site qui lui a t choisi, on parle de systme rparti sans
migration ; si une tche peut changer de site pendant son excu- Politique mixte
tion, on parle de systme rparti avec migration . Cest une politique qui combine les avantages des deux politiques
La migration dune tche en cours dexcution consiste transf- prcdentes. Lide est danticiper le plus possible sur le transfert de
rer son contexte (cest--dire, ses donnes, les registres du proces- tche en envoyant la tche migrer sur un site foyer (si celui-ci
seur) qui volue au fur et mesure que la tche sexcute et existe) qui est suppos avoir une charge lui permettant daccepter la
transfrer ventuellement son code (cest--dire, les instructions et tche migrer, et en diffusant, en mme temps, une requte
les constantes qui composent le programme de la tche) qui est denchres (requte qui contient les adresses des sites demandeur
fixe. Pour minimiser le temps de migration dune tche, le code des et foyer). Cest le site foyer (sil existe) qui reoit les rponses aux
tches susceptibles de migrer est dupliqu sur les sites sur lesquels enchres et qui dcide soit dexcuter localement la tche qui lui a
ces tches peuvent sexcuter. Ainsi, en cas de migration, seul le t transfre soit de procder une migration en fonction des
contexte de la tche est transfr. offres reues. Si aucun site foyer na t choisi, le site demandeur
La migration des tches est une fonction importante dans un procde comme dans le cas de la premire politique (cf. figure 2 c).
algorithme dordonnancement global. Elle permet de tenir compte La politique linitiative du demandeur engendre trois types de
des volutions du systme en rpartissant, de manire dynamique, messages pour chaque demande de migration (message de requte
la charge dexcution des tches sur lensemble des processeurs. denchres, message de rponse et message de transfert de tche).
Par ailleurs, le changement dynamique du site dexcution dune La politique linitiative de loffreur engendre deux types de mes-
tche constitue un moyen daccrotre la tolrance aux fautes du sys- sage (message dacceptation de tche et message de transfert de
tme. tche). Si la charge des sites est leve, la plupart des tentatives
Plusieurs politiques de migration ont t tudies. Ces politiques pour trouver un site daccueil pour faire migrer une tche restent
se distinguent selon que le site demandeur (celui qui souhaite sans succs. Do un accroissement inutile de la charge du rseau.
migrer une tche) prend linitiative ou non du transfert de tche. Dans ce cas, la politique linitiative de loffreur est plus efficace (car
elle minimise la charge du rseau). Cependant, si la charge des sites
Politique linitiative du demandeur est faible, la politique linitiative de loffreur nest pas efficace, car
Cette technique, dite technique des enchres , est bien connue elle conduit des messages mis par des sites pour offrir leur ser-
dans les algorithmes de rpartition de charge. Lorsquun site est en vice, mais comme les autres sites ne sont pas chargs, leurs offres
surcharge, il diffuse une requte denchres tous les autres sites restent sans rponse. Dans ce cas, la politique linitiative du
(figure 2 a). la rception dune requte denchres, un site envoie demandeur est plus efficace. Le seuil de charge partir duquel une
son cot dexcution au site ayant mis la requte. Quand le site politique est plus efficace quune autre est difficile dterminer
demandeur a reu les cots attendus, le site avec le cot le plus fai- dans le cas gnral. titre indicatif, des simulations faites sur la
ble est retenu. moyenne des retards et le pourcentage des tches qui terminent
leur excution en respectant les contraintes ainsi que sur la migra-
tion des tches montrent que ce seuil est de lordre de 75 % [2].
Une proprit importante exige pour les mthodes de migration
Site Site Site Site Site Site est la transparence. Un mcanisme de migration est transparent, si
offreur demandeur offreur offreur demandeur offreur toutes les tches qui communiquent avec une tche sexcutent de
la mme manire que cette tche ait migr ou non. Par ailleurs, la
migration ne doit pas apparatre explicitement dans le programme
RED de la tche : le problme de migration de tches se pose au systme
DM M OA
RE T T et non au programmeur.
OA
OR Le choix dune tche migrer doit tenir compte de plusieurs
ED DM
M E paramtres : charge du rseau, charge des sites, caractristiques
OR TT
M des tches et localisation des ressources quelles utilisent, etc. Le
surcot de migration (cest--dire le temps ncessaire pour dtecter
M la surcharge, dterminer le site rcepteur, transfrer le contexte de
TT
la tche et transfrer la tche elle-mme, avertir ventuellement
a politique sur initiative b politique sur initiative dautres sites sur lesquels sont places des tches qui communi-
du demandeur de l'offreur quent avec la tche migrer, etc.) peut tre incompatible avec le res-
pect des contraintes de temps imposes la tche. La migration
Site Site Site Site dune tche qui a une faible dure dexcution, dune tche qui a
offreur demandeur offreur foyer beaucoup de liens de communication avec dautres tches situes
sur le mme site quelle, ou dune tche qui utilise beaucoup de res-
TTM c politique mixte sources situes sur son site de placement actuel conduit souvent
RED des baisses de performances globales. Ainsi, les mcanismes de
DM M
RE REDM : requte d'enchres migration, sils ne sont pas utiliss avec prcaution, peuvent con-
ORED OR de demande de migration duire des situations dinstabilit, voire dcroulement du systme.
M ED OREDM : offre une requte
M En effet, les migrations peuvent conduire des surcharges des sites
d'enchres de demande
de migration et du rseau, puis les sites surchargs vont demander faire migrer
TTM TTM : transfert de la tche certaines tches, et le systme peut se trouver compltement satur
migrer par des oprations de migration. Cest pour ces raisons, surcot
OAT : offre d'accueil de tches individuel et baisse globale des performances, que beaucoup
dalgorithmes de migration de tches ne concernent encore que des
Figure 2 Politiques de migration applications non temps rel.

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 056 8 Techniques de lIngnieur, trait Informatique industrielle
________________________________________________________________________________________________________ ORDONNANCEMENT TEMPS REL

Des tudes danalyse et dexprimentation de techniques de

migration ont t menes depuis de nombreuses annes. Mme sil Placement de tches
est difficile de comparer les rsultats des modles analytiques, de
simulation ou probabilistes faits avec des hypothses diffrentes,
certaines conclusions gnrales semblent apparatre [6].
Placement dynamique Placement statique
Lorsquon ne considre, lors de la slection de tches migrer,
que des tches qui ncessitent des temps dexcution longs, la plu-
part des algorithmes de migration apportent une amlioration du
Non optimal Optimal
temps de rponse moyen. Non optimal Optimal
Plus la charge des sites est dsquilibre, plus lutilisation
dalgorithmes de migration est efficace.
Les meilleurs rsultats sont obtenus avec les algorithmes de
migration exploitant des informations de charge globales sur le sys-
tme, condition que le surcot engendr par lacquisition de ces Algorithmes Algorithmes
informations ne soit pas un frein la migration. non coopratifs coopratifs
Le type de rseau et, en particulier, le protocole daccs au
mdium dtermine lefficacit de la migration. Par exemple, sur un
rseau de type Ethernet, la migration conduit une surcharge du Avec collecte
d'informations de charge Sans collecte
rseau, donc une baisse du rendement qui peut aller jusqu la
d'informations
saturation complte du rseau par des trames en collision, alors de charge
que, sur un rseau en bus jeton, la migration ne conduit pas
lcroulement du rseau. Laugmentation de la charge sur le rseau
conduit des temps de transfert plus importants et peut augmenter Centralise Distribue Hybride
le nombre de tches qui ne reoivent pas leurs messages temps.
On peut se demander alors si la migration peut apporter un rel
bnfice par rapport au placement statique. La rponse cette ques-
tion nest pas simple. Elle dpend du type de lapplication et du sys- Politique de transfert
tme support. Si lapplication est dynamique de nature
(dclenchement de tches de manire alatoire), une approche par
placement fixe (partant des connaissances minimales) nest pas effi-
cace. Dans une application temps rel et rpartie, si lon considre Centralise Distribue Hybride
que lensemble des sites doit excuter en priorit les tches urgen-
tes ou importantes, la migration de tches peut apporter des solu-
tions la minimisation des tches tardives.
Politique de localisation
Signalons enfin que de nombreuses synthses sur le problme de
placement, dans le cas non temps rel, dans des architectures paral-
lles ou rparties, ont t proposes dans la littrature. Nous con-
seillons le lecteur de se rfrer notamment aux rfrences suivantes Centralise Distribue Hybride
[2] [3] [6] [7] [10] [13] [17] [59] [74]. En revanche, peu de travaux ont
tudi le placement dans le cas des systmes temps rel et rpartis.
Le lecteur pourra trouver des exemples danalyse et dexprimenta-
tion de certaines des mthodes de placement prsentes prcdem-
ment dans les rfrences [5] [11] [22] [24] [52] [54] [57] [62] [63]. Ces Avec migration Sans migration
derniers travaux ont trait principalement des tches priodiques.
La figure 3 rsume les principales alternatives concernant les
mthodes de placement de tches dans les systmes rpartis.
Sur initiative Mixte Sur initiative
de l'offreur du demandeur

Figure 3 Principales alternatives de conception des algorithmes

3. Ordonnancement
de messages
3.1 Introduction
Comme nous lavons dj soulign, les applications temps rel et
rparties imposent des contraintes temporelles sur lexcution des
tches ; ces contraintes se rpercutent directement sur les messa-
ges changs entre les tches lorsque celles-ci sont places sur des
processeurs diffrents.
Dans une application temps rel, certaines tches peuvent avoir
des contraintes temporelles strictes et dautres non. De la mme
manire, les messages changs entre ces tches peuvent avoir des
contraintes strictes ou non. Par exemple, un message dalarme doit
tre transmis et reu avec des contraintes strictes sous peine de ne
de placement de tches
pas pouvoir traiter la cause du dclenchement de lalarme avant
quelle nengendre une dfaillance, alors quun transfert de fichier
ne ncessite pas en gnral un respect de contraintes temporelles
strictes. Si un message arrive au-del du dlai fix, il est alors consi-
dr comme perdu. Un message doit tre correct du point de vue
contenu, mais aussi du point de vue temporel. Par exemple, une
mesure de temprature qui est prleve par un capteur correct,
mais qui arrive deux secondes plus tard un automate de rgula-
tion ayant un cycle dune seconde, est considre comme obsolte,
donc incorrecte.
Ainsi, la principale caractristique qui permet de distinguer les
communications temps rel des autres types de communications
rside dans cette ncessit de respecter les dlais de transfert de
messages. Les systmes de communication doivent permettre
dexprimer les contraintes de temps des messages et doivent int-

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Informatique industrielle S 8 056 9
ORDONNANCEMENT TEMPS REL _________________________________________________________________________________________________________
grer des protocoles qui garantissent le respect des contraintes de
temps spcifies dans les services.
Diffrents travaux ont t consacrs la prise en compte des con-
traintes de temps sur les messages dans les rseaux commutation
de paquets et dans les rseaux locaux accs multiple. Dans la pre-
mire catgorie de rseaux, les travaux ont t essentiellement con-
sacrs ATM (Asynchronous Transfer Mode) pour la prise en
compte des contraintes de temps dans les applications multimdias
[26] [51] [66] [67] [69] [73]. Dans la seconde catgorie de rseaux, les
travaux ont port essentiellement sur des rseaux de type [CSMA
(Carrier Sense Multiple Access) avec ses diffrentes variantes
CSMA/CD (with Collision Detection), CSMA/CA (with Collision
Advoidance), CSMA/DCR (with Deterministic Collision Resolution)],
bus jeton, boucle jeton, FDDI (Fiber Distributed Data Interface) et
FIP (Flux dInformation Processus) [1] [31] [36] [58] [68] (cf. 3.4).
Quand on sintresse lordonnancement de messages temps
rel, ces deux catgories de rseaux prsentent des diffrences
significatives.
Rseaux commutation de paquets
Chaque station relie au rseau est considre comme un
abonn et ne connat pas les protocoles utiliss lintrieur du
rseau de commutation.
Pour transmettre ses donnes, chaque abonn tablit une con-
nexion selon un contrat lui garantissant une certaine qualit de ser-
vice (taux de perte, dlai maximal pour le transfert, etc.). Les
stations (ou abonns du rseau) ne peuvent ni rentrer en compti-
tion les unes avec les autres, ni se consulter pour savoir laquelle doit
mettre des donnes. Tout abonn sadresse au nud du rseau (un
commutateur ATM, par exemple) auquel il est directement raccord,
et ce nud se charge du transfert du message.
Les contraintes de temps sont entirement assumes par le
rseau, condition que chaque station ngocie une qualit de ser-
vice suffisante pour tenir compte des caractristiques des messages
quelle souhaite transmettre. Par consquent, les mcanismes utili-
ss sont implants dans les nuds de commutation du rseau et
non dans les stations.
Rseaux accs multiple
Les stations connectes au rseau contrlent laccs au
mdium via une technique MAC (Medium Access Control) implan-
te sur chacune des stations. Chaque station accde au mdium
partag principalement soit par comptition, soit par consultation
(en utilisant un jeton, par exemple) selon le type de technique MAC
utilise par le rseau.
Une fois quune station a mis une trame sur le mdium, cette
trame est directement reue par son destinataire (sauf, videm-
ment, en cas de collision ou de rseau utilisant des quipements
dinterconnexion tels que ponts et routeurs).
Les stations doivent tre configures (en particulier en dtermi-
nant les priorits des messages ou des stations, les temps dutilisa-
tion des jetons, etc.) pour pouvoir garantir les contraintes de temps
imposes aux messages. Par consquent, les mcanismes associs
sont implants dans les stations.
Les techniques de prise en compte des contraintes de temps,
quelles soient intgres au-dessus de la sous-couche MAC, dans le
cas des rseaux accs multiple, ou dans les commutateurs, dans
le cas des rseaux commutation de paquets, sont similaires. Elles
sont fondes sur ladaptation dalgorithmes dordonnancement de
tches pour monoprocesseur (comme Earliest Deadline First ou
Rate Monotonic). Dans la suite, nous allons nous intresser seule-
ment lordonnancement des messages dans le cadre des rseaux
accs multiple.
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 056 10 Techniques de lIngnieur, trait Informatique industrielle
3.2 Communication et rseaux temps rel
Une communication temps rel est dfinie par des contraintes de
temps explicites, cest--dire quelle doit commencer ou se terminer
dans un intervalle de temps dtermin. En gnral, les contraintes
temporelles associes un message temps rel sont de deux types :
un dlai de transfert born et une gigue borne. Les rseaux qui dis-
posent des mcanismes adquats pour garantir le respect de ces
contraintes sont appels rseaux temps rel. Les industriels les
dsignent aussi comme des rseaux locaux industriels.
Beaucoup de travaux ont recens les proprits que doivent pos-
sder les rseaux temps rel [18] [41] [43] [44] [50] [58] [72] :
prdiction des temps de rponse des messages contraintes
strictes ;
borne maximale connue pour le dlai de transfert ;
faible gigue ;
haut degr dordonnanabilit, cest--dire garantie a priori du
respect des contraintes temporelles dun nombre lev de
messages ;
possibilit dchanges priodiques ou apriodiques de
messages ;
possibilit dchanges de messages avec des contraintes de
temps strictes ou non ;
robustesse des protocoles, cest--dire aptitude continuer
fonctionner correctement en prsence de variations du trafic et de
surcharges ;
bonnes performances et surcot peu important ;
tolrance aux fautes ;
fiabilit des transferts ;
fonctionnement dans des conditions environnementales pou-
vant tre svres ;
niveau lev de validation et de testabilit.
Dans les rseaux classiques commutation de paquets, les per-
formances sont mesures essentiellement en termes de temps de
rponse moyen et de rendement du rseau. Dans les rseaux temps
rel, la notion de temps de rponse moyen est inadapte, voire
dangereuse ; il faut pouvoir garantir des dlais de rponse borns et
connus lavance pour des messages individuels. On rappelle que
le temps rel ne signifie pas rpondre rapidement, mais suffisam-
ment rapidement pour tenir compte de lvolution du phnomne
physique contrl. Donc, un rseau haut dbit nest pas ncessai-
rement un rseau temps rel. Cest plus particulirement par sa stra-
tgie dallocation du mdium, et non spcialement par son dbit,
quun rseau peut tre capable de garantir le respect des contraintes
temporelles des messages. Un rseau doit cependant possder des
performances minimales, pour envisager son utilisation dans un
systme temps rel.
Les protocoles de communication jouent un rle important dans
limplantation des applications temps rel et rparties. Les protoco-
les fonds sur le modle OSI (Open Systems Interconnection) ont
montr leur efficacit pour les systmes non temps rel. Beaucoup
de travaux actuels portent sur la manire de modifier ou dtendre
ces protocoles pour les adapter au temps rel. Lintroduction de con-
traintes de temps impose lintgration de mcanismes nouveaux,
notamment lordonnancement de messages.
Actuellement, les tudes sur les contraintes temporelles se
situent essentiellement au-dessus du protocole MAC dans la couche
liaison de donnes qui gre laccs au support de communication.
La prise en compte des contraintes de temps par le protocole MAC
est ncessaire, mais elle nest pas suffisante. En effet, il faut rper-
cuter les contraintes de temps sur toutes les couches pour parvenir
rellement les respecter dans lapplication temps rel. On parle
alors de profil de communication temps rel, pour dsigner une
architecture de communication o les contraintes de temps sont pri-
ses en compte par toutes les couches.
Des dtudes ont montr que des rseaux existants peuvent
garantir le respect de contraintes de temps, sils sont bien configu-
________________________________________________________________________________________________________ ORDONNANCEMENT TEMPS REL

rs [1] [31] [43] [44] [47] [72]. On utilise tantt des techniques centra-
lises, comme celle de FIP, tantt des techniques jeton, tantt
encore des techniques daccs fondes sur le protocole CSMA [23]
[29]. Ces dernires techniques sont intrinsquement tolrantes aux
fautes.
Malcolm et Zhao [36] ont fait une synthse des travaux mens
depuis plus dune dizaine dannes sur ladaptation des techniques
MAC existantes au problme de communication temps rel. Nous
nous appuyons sur cette synthse. Nous ne cherchons pas rpon-
dre la question quel est le rseau le plus adapt au temps rel ?
mais plutt comment adapter un rseau donn pour quil puisse
prendre en compte des contraintes de temps ? . En effet, mme si
certains protocoles MAC sont plus dterministes que dautres,
chaque rseau peut traiter certaines contraintes de temps. Le choix
du rseau et de la technique dordonnancement dpend des con-
traintes et des spcificits des applications cibles et il est inutile de
surdimensionner le rseau utilis.
contraintes strictes, lintervalle minimal entre deux demandes suc-
cessives de transmission du message suffit.
Longueur
Cest la longueur du message en bits.
Relations entre messages
Les messages gnrs par une mme source ont, de ce fait, une
relation de prcdence. Les messages gnrs par des sources dif-
frentes appartenant une mme station ou des stations diffren-
tes peuvent tre indpendants ou bien avoir des relations de
dpendance. Par exemple, les applications multimdias doivent
synchroniser le son et limage et spcifient que les messages issus
de ces deux sources soient transmis dans une mme fentre tempo-
relle.
Destinataires
Un message mis par une source peut tre destin une seule
station, un groupe de stations ou toutes les stations.

3.3 Caractristiques des messages

et qualit de service 3.3.2 Qualit de service

Une application temps rel exige du sous-systme de communi-

3.3.1 Caractristiques de messages cation une certaine qualit de service qui sexprime notamment par
les paramtres suivants.
Les paramtres les plus utiliss pour spcifier les caractristiques Dlai maximal de transfert (ou dlai critique)
des sources de messages changs dans une application temps rel
et rpartie sont les suivants. Cest le dlai maximal pour transmettre un message dune station
une autre. Comme lindique la figure 4, le dlai de transfert dun
Criticit message est compos de plusieurs dlais intermdiaires : le dlai
Les tches rparties peuvent changer : de traverse des couches suprieures chez lmetteur, le dlai
dattente au niveau MAC de lmetteur avant transmission, le dlai
des messages avec des contraintes temps rel strictes (hard
de transmission et de propagation du message sur le mdium, le
real-time messages). Tout manquement au respect des contraintes
dlai dattente au niveau MAC du rcepteur et le dlai de traverse
temporelles peut conduire une dtrioration du service, voire
des couches suprieures chez le rcepteur.
des catastrophes. Le respect de ces contraintes doit tre garanti ;
des messages avec des contraintes temps rel relatives (soft
real-time messages) caractriss par des contraintes temporelles
dont le dpassement occasionnel ne conduit pas la dgradation
du service ;
des messages ne prsentant aucune spcification de contrain-
tes de temps. Par consquent aucune disposition particulire nest Tche 1 Tche 2
exige pour prendre en compte ce type de messages.
En considrant que les messages sans contraintes temporelles
sont des messages avec des dlais de transfert et des gigues infinis,
les deuxime et troisime classes de messages peuvent tre regrou-
pes en une seule, lorsque lon considre laspect ordonnancement
de messages. En effet, dans les applications temps rel et rparties, Dlai Dlai
les deuxime et troisime classes de messages sont traites par les de traverse Couches Couches de traverse
des couches suprieures suprieures des couches
mmes stratgies, en affectant la priorit la plus faible la troisime suprieures suprieures
classe de messages.
Type
Un message peut tre priodique (dit aussi synchrone) ou aprio-
dique (dit aussi asynchrone) :
la priode dun message priodique dsigne lintervalle de Dlai Dlai de
temps sparant deux demandes dmission successives du mes- d'mission rception
sage par sa source ; Sous-couche Sous-couche
MAC MAC
un message apriodique peut demander tre transmis
nimporte quel moment. Cependant, pour pouvoir garantir, dans
certains cas, ou optimiser, dans dautres, le respect des contraintes
Mdium
de temps associes un message apriodique, un certain nombre
dinformations concernant les instants de demande de transmission
du message doivent tre connues, savoir : lintervalle de temps Dlai de transmission
minimal sparant deux demandes successives de transmission du et propagation
message, les dures des avalanches du message, lintervalle de
temps minimal sparant deux avalanches successives, etc. Toutes
ces informations ne sont pas toujours ncessaires. Ainsi, pour le
respect des contraintes de temps des messages apriodiques avec Figure 4 Dlais intervenant dans une communication temps rel

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Informatique industrielle S 8 056 11
ORDONNANCEMENT TEMPS REL _________________________________________________________________________________________________________
Gigue maximale
Les messages mis par une source peuvent avoir des dlais de
transfert variables selon la charge du rseau. La variation maximale
du dlai de transfert est appele la gigue. Certaines applications
comme les applications multimdias (o la prsentation des infor-
mations ncessite une synchronisation) spcifient une limitation de
la gigue.
Taux de perte maximal
Pour certaines applications, comme les applications vido ou
audio, la perte de quelques messages est acceptable. Lorsque la
charge est leve, le rseau peut alors, de temps en temps, sans
avertir lutilisateur, carter certains messages, afin de mieux servir
dautres sources de messages. Dautres applications, comme les
systmes de contrle/commande de procds, tolrent difficilement
la perte de messages.
Taux derreur maximal
Les moyens de communication tant imparfaits, des erreurs de
transmission peuvent apparatre nimporte quel moment. Cepen-
dant, le bon fonctionnement dune application peut imposer un taux
derreur maximal au-del duquel lapplication est considre
comme srieusement compromise.
Hypothses pour la suite de larticle
Le respect du dlai de transfert dun message ncessite de
dterminer les dlais intermdiaires, de disposer de services
permettant dexprimer ces dlais et de disposer de mcanismes
permettant de garantir ces dlais. Les contraintes de temps doi-
vent tre prises en compte tous les niveaux de communica-
tion. Dans la suite de cet article, comme nous lavons soulign,
nous focaliserons notre tude sur les techniques dordonnance-
ment intgrer au-dessus de la sous-couche MAC.
3.4 Protocoles de niveau MAC (Medium
Access Control)
3.4.1 Prsentation de protocoles de niveau MAC
Nous limitons notre prsentation des protocoles MAC aux mca-
nismes sur lesquels sarticulent les techniques dordonnancement
de messages.
Un rseau accs multiple est compos dun ensemble de sta-
tions interconnectes par un support de transmission. Laccs au
mdium par une station peut tre gr de plusieurs manires [37],
notamment :
par multiplexage frquentiel : chaque station met sur une
bande de frquences qui lui est rserve ;
par multiplexage temporel : chaque station dispose, de
manire cyclique, dun quantum de temps ;
par comptition : chaque station met ds quelle le souhaite
et doit grer les situations de collisions ;
par consultation : chaque station met quand elle a obtenu le
jeton ou quand la station arbitre lui a donn le droit dmettre ;
dans le premier cas on parle de techniques MAC dcentralises,
dans le second de techniques MAC centralises.
Nous nous intressons six techniques MAC qui reprsentent les
principales techniques utilises pour assurer des communications
temps rel.
Technique CSMA/CD (norme IEEE 802.3)
CSMA/CD (Carrier Sense Multiple Access with Collision Detec-
tion) fonctionne sur des topologies de rseaux en bus ou en toile.
Cette technique est utilise par le rseau local le plus rpandu :
Ethernet. CSMA/CD est fonde sur la comptition : toute station
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 056 12 Techniques de lIngnieur, trait Informatique industrielle
peut mettre ds quelle le souhaite, condition quelle ait dtect
que le bus tait libre avant de commencer sa transmission.
Lorsquune station met une trame, elle coute le support en mme
temps quelle met. Si deux ou plusieurs stations tentent dmettre
en mme temps, leurs trames entrent en conflit : on dit quil y a une
collision sur le bus. Si, pendant sa transmission, la station ne
dtecte pas de collision, elle considre que sa tentative dmission a
russi ; sinon elle attend un temps alatoire avant de tenter une
nouvelle fois sa transmission.
Cette technique est rarement utilise dans le monde du temps
rel. Cependant, comme nous le verrons par la suite, CSMA/CD peut
tre adapte pour la communication temps rel.
Technique du bus jeton (norme IEEE 802.4)
Dans la mthode daccs du bus jeton, lensemble des stations
actives est organis sous la forme dun anneau logique (ou anneau
virtuel). La mise en place dun anneau logique consiste dtermi-
ner, pour chaque station active, ladresse de la station qui lui suc-
cde sur lanneau logique. Par exemple, dans la figure 5, lanneau
logique est form de trois stations (2, 4 et 6).
Une fois lanneau logique configur, le droit daccs au bus, pour
mettre des donnes, est rserv, un moment donn, une seule
station : on dit que cette station a le droit dmettre. Ce droit est
symbolis par la possession dune trame spciale dite jeton. Le
jeton est transmis de station en station tant quil y a au moins deux
stations dans lanneau logique.
la configuration du rseau, un temps dutilisation du bus est
affect chaque station. On dfinit aussi le temps maximal de rota-
tion du jeton (TTRT, Target Token Rotation Time). Le TTRT dsigne le
temps maximal entre deux passages successifs du jeton dans une
station. Quand une station reoit le jeton, elle met ses trames
jusqu puisement de son temps dutilisation et transmet ensuite le
jeton son successeur sur lanneau. Si une station na plus de don-
nes transmettre, elle libre le jeton.
Des priorits locales sont dfinies permettant chaque station
dordonner localement ses trames selon leur importance ou leur
urgence locale. Cette technique fait partie des techniques dites
jeton temporis.
Pour faire face aux diverses anomalies et pannes, comme la dupli-
cation ou la perte du jeton, la panne dune station qui fait partie de
lanneau logique, etc., la norme IEEE 802.4 intgre un ensemble de
mcanismes permettant de dtecter ces anomalies et pannes et de
ramener lanneau logique dans un tat de fonctionnement normal.
Le protocole du bus jeton est la base de certains rseaux
locaux industriels comme MAP (Manufacturing Automation Proto-
col) [38] et PROFIBUS (PROcess FIeldBUS) [16].
Anneau logique
1 2 3 4
Support de transmission (Bus)
8 7 6 5
Figure 5 Exemple danneau logique
________________________________________________________________________________________________________ ORDONNANCEMENT TEMPS REL
1 Producteur
8 2
Sens de passage
du jeton
7 3
6 4
5
Figure 6 Exemple de boucle jeton
Technique du rseau FDDI
FDDI (Fiber Distributed Data Interface) est un protocole permet-
tant de connecter des stations autour dune boucle en fibre optique
(figure 6). Les stations accdent la boucle en utilisant un jeton cir-
culant. Dans le cas de FDDI, le successeur physique dune station
sur la boucle est aussi son successeur logique (par exemple, la sta-
tion 2 succde la station 1, sur la figure 6). Le jeton passe de sta-
tion en station selon lordre physique des stations sur la boucle. Il
ny a pas besoin de procdures spciales de cration de lanneau,
dinsertion de stations et de retrait de stations, comme dans le cas
de lanneau logique du bus jeton. Le principe daccs au mdium
de FDDI est similaire celui du bus jeton. FDDI fait partie des tech-
niques dites jeton temporis.
la configuration du rseau, on affecte, pour chaque station, un
temps pour transmettre ses messages priodiques (ou synchrones).
Un TTRT est donc dfini, comme dans le cas du bus jeton.
Un mcanisme de priorits locales est disponible dans FDDI per-
mettant chaque station dordonner localement ses messages ap-
riodiques. Lorsque le jeton tourne plus vite que prvu ou quune
station na pas de messages priodiques transmettre, elle peut
transmettre des messages apriodiques. Les niveaux de priorits
des messages apriodiques sont servis en tenant compte des ins-
tants darrive du jeton.
Technique de la boucle jeton (norme IEEE 802.5)
Une boucle jeton (token ring) comporte un ensemble de stations
connectes en srie par des lignes point point unidirectionnelles.
Laccs au mdium peut tre gr soit avec un seul jeton, soit avec
plusieurs jetons. Par la suite, nous nous intressons uniquement
la boucle avec des jetons multiples. Avec un mcanisme de priorits
globales, la boucle IEEE 802.5 privilgie les trames ayant les plus
hautes priorits sur lensemble du rseau ; elle fonctionne selon le
principe suivant.
Huit niveaux de priorits sont dfinis dans la version de base de
la boucle jeton.
La priorit dun jeton ou dune trame est indique par trois bits
dits champ de priorit . Chaque niveau de priorit a son propre
jeton.
un instant donn, la boucle fonctionne un seul niveau de
priorit, dit priorit courante . Le jeton de priorit courante est
alors soit en circulation, soit bloqu dans une station qui est en train
dmettre ses donnes.
Lorsquune station dtecte le passage dun jeton, elle le pige,
si elle a des donnes mettre dont la priorit est suprieure ou
gale celle du jeton reu.
Chaque trame de donnes contient un champ dit bits de
rservation qui permet de slectionner la priorit la plus leve du
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Informatique industrielle
Consommateur
1 4
Arbitre de bus
Table
d'arbitre
2 2 3 2 3
BUS
1 Production d'une valeur
2 Envoi d'une trame d'identificateur et reconnaissance
de l'identificateur par le producteur et les consommateurs
3 Transfert de la valeur du producteur vers les consommateurs
4 Consommation de la valeur
Figure 7 Phases dchange dobjet dans FIP
jeton demand, un instant donn, par lensemble des stations. Ce
champ est employ de la manire suivante : lorsquune trame de
donnes T traverse une station, cette station peut rserver le pro-
chain jeton, en modifiant les bits de rservation de la trame T,
par la priorit de ses donnes, si elle a des donnes mettre avec
une priorit plus leve que celle demande par les autres stations
qui ont dj vu passer la trame T.
Lorsque la trame mise par la station qui dtient le jeton revient
sa station source, cette station teste les bits de rservation . Si
la priorit demande est infrieure ou gale celle du jeton courant,
la station continue dmettre ses donnes, sinon elle cesse dmet-
tre ses donnes et met en circulation un jeton avec la priorit
demande. Une station qui cre un jeton avec une priorit plus le-
ve que celle du jeton quelle a pig est responsable de ce jeton et
doit lliminer lorsquil nest plus utilis.
linitialisation de la boucle, un jeton ayant la priorit la plus
basse est mis en circulation.
Technique du rseau FIP
FIP (Flux dInformation Processus ou Factory Instrumentation Pro-
tocol) est un rseau pour linterconnexion de capteurs, daction-
neurs et dautomates [61] via un bus. Le rseau FIP est fond sur une
structure centralise dans laquelle une station, dite arbitre de bus,
donne le droit dmettre aux autres stations. Il est bas sur le
modle producteur/distributeur/consommateurs dans lequel les
objets (des variables ou des messages) changs sur le rseau sont
produits par des stations dites producteurs et consomms par
dautres dites consommateurs. Chaque objet a un identificateur uni-
que. Les objets peuvent tre changs, entre producteurs et con-
sommateurs, de manire priodique ou apriodique sous le
contrle de larbitre de bus. En fonction des priodes de consomma-
tion des objets, on dfinit une table statique dite table darbitre de
bus qui permet dindiquer lordre fixe dans lequel les objets doivent
tre changs sur le bus. En utilisant sa table, larbitre de bus diffuse
un identificateur dobjet changer ; ensuite le producteur met la
valeur de lobjet qui sera copie par tous les consommateurs con-
cerns. La figure 7 rsume les phases dun change de donnes
dans le rseau FIP.
FIP permet lchange dobjets apriodiques seulement quand il
reste du temps libre aprs lchange des objets priodiques.
Technique du rseau CAN
Le rseau CAN (Controller Area Network) a t introduit pour
assurer la communication dans les vhicules [23]. Dans la pratique,
S 8 056 13
ORDONNANCEMENT TEMPS REL _________________________________________________________________________________________________________
CAN est utilis aujourdhui aussi bien dans les vhicules que dans
les systmes de contrle/commande. CAN est un bus diffusion.
Les stations ne possdent pas dadresses propres et elles accdent
au bus via la technique CSMA/CA (CSMA with Collision Avoidance).
Tout objet chang sur le bus a un identificateur propre. Lidentifica-
teur contenu dans une trame dfinit le niveau de priorit de la
trame : plus lidentificateur est petit, plus la trame est prioritaire.
Lorsque deux stations tentent dmettre simultanment, cest la sta-
tion qui met lobjet dont lidentificateur est le plus petit qui
simpose et qui russit sa transmission. On dit que CAN est fond
sur un accs au mdium avec priorit et avec rsolution de colli-
sions non destructive. Les objets peuvent tre changs de manire
priodique, de manire sporadique ou sur demande dun consom-
mateur.
3.4.2 Fonctions de la sous-couche MAC du point
de vue ordonnancement
Nous pouvons remarquer, travers la prsentation succincte de
quelques techniques MAC, que certains MAC sont plus aptes que
dautres prendre en compte de manire efficace des contraintes de
temps. Par exemple, il est difficile davoir un temps de rponse
born avec CSMA/CD, alors que la rservation de bande passante
pour les messages priodiques est la base mme de la conception
de FIP ou de FDDI.
Malcolm et Zhao [36] ont propos une approche de dcomposi-
tion de la sous-couche MAC afin didentifier les mcanismes de
niveau MAC qui peuvent tre exploits pour ordonnancer des mes-
sages temps rel. Cette approche permet de distinguer deux aspects
dans laccs au rseau par une station :
larbitrage daccs : cette fonction dtermine le moment o
une station a le droit dutiliser le support de communication ;
le contrle de transmission : cette fonction dtermine le temps
pendant lequel une station peut utiliser le support pour transmettre
la totalit ou une partie de ses donnes.
Exemple : prenons deux exemples de MAC, pour comprendre
quoi correspondent ces deux fonctions.
Dans la technique du bus jeton, la fonction darbitrage repose sur
le droit daccs au mdium qui passe de station en station, selon
lordre de lanneau logique, sans tenir compte de lurgence des messa-
ges. La fonction de contrle de transmission dcoule du quantum de
temps affect chaque station la configuration du rseau. Dans ce
cas, le contrle de transmission est bien adapt la prise en compte de
contraintes de temps.
Dans la technique CSMA/CD, la fonction darbitrage daccs utilise le
fait que toute station peut utiliser le support si elle dtecte quil est
libre. La fonction de contrle de transmission est fonde sur le fait
quune station peut mettre des donnes, sans restriction, tant quelle
dtecte que le bus est libre. Aucune des deux fonctions nest donc
directement adapte la prise en compte de contraintes de temps.
La conception dun algorithme dordonnancement de messages
intgrer au-dessus dun MAC donn consiste exploiter les capaci-
ts offertes par chacune des deux fonctions de ce MAC, pour met-
tre de manire efficace les messages temps rel.
3.5 Ordonnancement de messages :
principes gnraux et proprits
3.5.1 Principes et stratgies dordonnancement
de messages
Lordonnancement de messages temps rel a pour objectif
dallouer le mdium partag entre plusieurs stations de telle sorte
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 056 14 Techniques de lIngnieur, trait Informatique industrielle
que les contraintes temporelles des messages soient respectes.
Lordonnancement de messages constitue donc une fonction de
base de tout systme temps rel et rparti. Comme nous lavons
soulign dans le paragraphe 3.3, tous les messages gnrs dans
une application temps rel et rpartie ne sont pas critiques du point
de vue temporel. Ainsi, selon les contraintes temporelles associes
aux messages, deux stratgies dordonnancement sont employes.
Stratgie avec garantie
Si des messages sont ordonnancs selon cette stratgie, tout
message accept pour transmission est transmis en respectant ses
contraintes temporelles (sauf, videmment, en cas de dfaillance du
systme de communication). Cette stratgie est gnralement
rserve aux messages avec contraintes de temps strictes.
Stratgie avec meilleur effort
Un message accept pour transmission avec cette stratgie nest
pas ncessairement transmis en respectant ses contraintes tempo-
relles. Cette stratgie est employe pour traiter les messages avec
contraintes de temps relatives ou sans contraintes de temps.
Dans un systme temps rel et rparti, les deux stratgies peu-
vent cohabiter, pour pouvoir rpondre aux besoins de communica-
tion des diverses applications.
Avec lmergence des systmes temps rel et rpartis, de nou-
veaux besoins dordonnancement sont apparus : il faut, la fois,
garantir le respect des contraintes temporelles des tches et celles
des messages. Comme lordonnancement de messages tient
compte de contraintes analogues, principalement les chances et
les dlais, celles des tches, lordonnancement de messages
temps rel utilise les mmes algorithmes que lordonnancement de
tches. Ainsi, comme nous le verrons dans les paragraphes 3.6
et 3.7, beaucoup dalgorithmes dordonnancement de messages
emploient les politiques Rate Monotonic et Earliest Deadline First
[33].
Alors que les tches peuvent, en gnral, accepter la premption
sans remettre en cause la cohrence des rsultats quelles labo-
rent, la transmission dun message nadmet pas de premption. Si
la transmission dun message commence, il faut transmettre tous
les bits du message jusquau dernier, sinon la transmission choue.
Ainsi, certaines prcautions doivent tre prises pour appliquer les
algorithmes dordonnancement de tches aux messages :
ne considrer que les algorithmes non premptifs ;
utiliser les algorithmes premptifs condition davoir des
messages dont la dure de transmission est infrieure ou gale
lunit de temps de base dallocation du mdium ;
utiliser les algorithmes premptifs condition deffectuer une
fragmentation des messages longs en petits paquets et de rassem-
bler les paquets la rception. Mme si, traditionnellement, la fonc-
tion de fragmentation et de rassemblage relve de la couche
transport, elle peut tre pratique au-dessus du MAC, pour pouvoir
effectuer lordonnancement de messages en utilisant des algorith-
mes premptifs.
notre connaissance, peu dalgorithmes dordonnancement de
tches non premptifs sont utiliss dans lordonnancement de mes-
sages au-dessus de la sous-couche MAC. Rappelons, par ailleurs,
que certains algorithmes premptifs possdent des proprits trs
intressantes quon aimerait exploiter dans le cas des messages,
telles que loptimalit et lexistence de test simple pour sassurer a
priori de la garantie des contraintes temporelles.
3.5.2 Modle canonique des messages temps rel
De mme quon sest donn un modle canonique des tches
temps rel, on utilise, pour leur ordonnancement, un modle cano-
nique des messages temps rel avec :
________________________________________________________________________________________________________ ORDONNANCEMENT TEMPS REL
ri : date o le message i est soumis pour tre transmis,
Ci : dure de transmission et de propagation du message i sur le
mdium,
Ri : dlai critique du message i,
Gi : gigue maximale du dlai de transfert du message i,
Pi : priode du message i, lorsquil sagit dun message priodi-
que.
Comme pour une tche, le dlai critique permet de calculer Di ,
lchance dun message i :
D i = ri + R i
Ce modle sert aussi bien au niveau MAC quau niveau suprieur
(cf. figure 4), pour ordonner lmission des messages et leur rcep-
tion par une station ou un ensemble de stations.
Nous nous intresserons ici des messages priodiques ou ap-
riodiques, indpendants et sans contraintes de gigue. Les chan-
ces des messages priodiques sont implicitement supposes gales
aux priodes (on parle, dans ce cas, de messages chance sur
requte).
3.5.3 Proprits dun algorithme
dordonnancement de messages
Dans le domaine de la communication temps rel, les principales
proprits attendues dun algorithme dordonnancement de messa-
ges sont les suivantes.
Taux dutilisation potentielle (TUP ) lev
Un algorithme a un TUP gal W sil permet dordonnancer des
messages priodiques tant que le taux dutilisation des messages
priodiques, Up , est infrieur W. On dfinit Up par :
i = n
Ci
Up = ----- (n : nombre de messages priodiques)
Pi
i = 1
Lexistence dun TUP pour un algorithme est une condition suffi-
sante pour ordonnancer un ensemble de messages, car il permet de
tester a priori lordonnanabilit dun ensemble de messages. Un
TUP lev est donc toujours souhait pour satisfaire les contraintes
dun maximum de messages. Gnralement, on ne sait pas calculer
le TUP [36]. Cependant, pour certains algorithmes, on peut calculer
la plus petite borne suprieure du TUP que nous noterons PCTUP
(pire cas du TUP).
Robustesse face des variations de trafic
Les sources de messages priodiques peuvent fluctuer de temps
en temps, en augmentant ou en diminuant les priodes ou les lon-
gueurs de messages. Un algorithme dordonnancement est consi-
dr comme robuste sil accepte des variations de trafic sans
affecter lordonnanabilit de lensemble des messages, condition
videmment que son TUP ne soit pas dpass lors dune augmenta-
tion de trafic.
Pas de propagation de fautes temporelles
Lorsquune station, la suite dune anomalie, diminue les prio-
des ou augmente les tailles de certains messages, elle peut remettre
en cause le respect des contraintes temporelles des messages des
autres stations. Un algorithme dordonnancement de messages doit
pouvoir limiter la propagation des fautes temporelles en dehors des
stations fautives.
Possibilit de transfert des messages sans contraintes strictes
Une partie de la bande passante du rseau doit rester utilisable
pour mettre des messages avec contraintes temporelles relatives
ou sans contraintes temporelles.
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Informatique industrielle
Surcot minimal
Lordonnancement de messages temps rel est fond sur la con-
naissance des charges des stations. Si cette connaissance est labo-
re en ligne, un surcot est introduit pour dterminer la station qui
a la priorit pour mettre ses donnes. Il est important que le sur-
cot (temps de traitement et nombre de messages) engendr par
lalgorithme dordonnancement soit minimal. Nous appellerons
messages de service (ou trames de service) les messages ncessai-
res au fonctionnement dun algorithme dordonnancement de mes-
sages.
En gnral, on se contente dun compromis entre les proprits
prcdentes pour choisir un algorithme dordonnancement de mes-
sages pour une application donne.
3.6 Ordonnancement de messages
priodiques
Pour les messages priodiques, les informations ncessaires
lordonnancement sont connues lavance, savoir les tailles des
messages (donc les dures de transmission des messages), les ins-
tants de demande de transmission (grce la connaissance des
priodes), les chances et les gigues. Dans cette tude, nous ne
considrons que des messages priodiques dont lchance est
gale la priode et sans contraintes de gigue.
Par un test fond sur le taux dutilisation du rseau par les messa-
ges priodiques, Up , on peut savoir si un ensemble de messages est
ordonnanable ou pas. En particulier, si Up est suprieur 100 %,
lensemble des messages priodiques ne peut tre ordonnanc par
aucun algorithme. Selon lalgorithme dordonnancement et le pro-
tocole MAC choisis, il peut exister un TUP. Dans ce cas, si
U p < TUP , alors on peut affirmer a priori quun ensemble des mes-
sages priodiques est ordonnanable. Les messages priodiques
sont gnralement considrs comme critiques et sont traits par
une stratgie de garantie.
3.6.1 Ordonnancement avec des MAC contrle
daccs dcentralis
3.6.1.1 Approche fonde sur larbitrage daccs
Principe dordonnancement
Le principe dordonnancement retenu dans cette approche prend
son origine dans lordonnancement de tches priodiques sur
monoprocesseurs. En particulier, cest lalgorithme RM (Rate Mono-
tonic) [33] qui est utilis de la manire suivante :
1 associer des priorits aux messages en fonction de leurs
priodes : les messages ayant les priodes les plus petites sont les
plus prioritaires ;
2 dcouper ( cause du caractre premptif de RM) chaque mes-
sage en trames ;
3 implanter RM en tenant compte du protocole MAC utilis.
Avec quels MAC utiliser Rate Monotonic ?
RM semploie de manire efficace avec des rseaux qui disposent
dun mcanisme de priorits globales, comme la boucle jeton
IEEE 802.5 ou CAN. Lutilisation de RM est inefficace avec des
rseaux qui ne disposent pas de mcanismes de priorits globales,
comme CSMA/CD ou FDDI, car il faut que les stations schangent
des donnes pour savoir celle qui a le message le plus prioritaire, ce
qui conduit videmment une surcharge du rseau.
Utilisation de Rate Monotonic avec une boucle jeton IEEE 802.5
Lutilisation de RM avec la boucle jeton consiste affecter des
priorits aux messages en fonction de leurs priodes. Le mca-
S 8 056 15
ORDONNANCEMENT TEMPS REL _________________________________________________________________________________________________________
nisme des priorits globales de la boucle jeton garantit alors aux
stations que leurs messages seront transmis en tenant compte de
leurs priorits. Les proprits de lordonnancement de messages
laide de RM sur la boucle IEEE 802.5 sont les suivantes.
PCTUP (pire des cas du taux utilisation potentielle)
Dans la rfrence [58], on dmontre que RM avec IEEE 802.5 a un
PCTUP gal :
0,69 Bmax /Pmin
avec Bmax temps maximal de blocage dun message par un
autre de plus faible priorit,
Pmin minimum des priodes des messages.
Robustesse face des variations de trafic
On peut changer les priodes ou les tailles des messages et
lensemble reste ordonnanable tant que le taux dutilisation des
messages priodiques ne dpasse pas le PCTUP.
Propagation de fautes temporelles
Si lon diminue la priode, ou bien si lon augmente la taille dun
message, tous les messages dont les priodes sont plus grandes
que la priode de ce message risquent de ne plus voir leurs chan-
ces respectes. Les fautes dune station se propagent donc aux
autres stations.
change de messages sans contraintes strictes
Les messages sans contraintes strictes peuvent tre transmis, en
leur affectant des priorits en fonction de leurs chances.
Surcot
La fonction darbitrage des priorits prend un temps qui dpend
de la longueur du rseau et de son dbit, puisquil faut faire un tour
complet de la boucle avant de connatre le message le plus priori-
taire. Le surcot engendr est plus lev que celui associ lappro-
che fonde sur le contrle de transmission que nous verrons par la
suite.
Lutilisation de Rate Monotonic avec une boucle jeton soulve
quelques problmes, notamment :
une connaissance approximative : la slection du message de
plus haute priorit ne se fait, un instant donn, quaprs un tour de
la boucle. Les stations rservent la boucle en fonction de la priorit
de leurs messages, en changeant les bits de rservation des trames
de donnes lorsque celles-ci passent par les stations. Si un message
de priorit lev est soumis au niveau MAC dune station mettrice,
juste aprs le passage de la dernire trame de donnes, la station
concerne par ce message est oblige dattendre la prochaine trame
pour effectuer sa rservation. Par consquent, le message en circu-
lation sur la boucle nest pas ncessairement celui qui a la plus
haute priorit ;
un nombre de niveaux de priorits limit : le nombre de priori-
ts est limit dans un rseau. Or le nombre de priodes des messa-
ges est inconnu a priori et peut tre plus lev que le nombre de
priorits du rseau. Par consquent, deux messages avec des prio-
des diffrentes peuvent se retrouver avec la mme priorit ;
une taille maximale des trames : RM est fond sur la premp-
tion de tches. Lapplication de RM lordonnancement de messa-
ges implique quil faut choisir une taille maximale des trames (taille
qui correspond lunit de base dallocation du mdium) de
manire trouver un compromis entre le respect des chances des
messages, la minimisation du surcot et laugmentation du rende-
ment du rseau.
Utilisation de Rate Monotonic avec CAN
Dans le rseau CAN, les identificateurs des objets dterminent les
priorits de transmission des messages. Lapplication de RM
lordonnancement dobjets priodiques peut se faire de la manire
simple : on associe les identificateurs dobjets en fonction de leurs
priodes. Si deux objets ont la mme priode, on leur associe deux
identificateurs diffrents, en privilgiant de manire alatoire un des
deux objets, ou en se basant sur limportance des objets pour
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 056 16 Techniques de lIngnieur, trait Informatique industrielle
lapplication. Comme les valeurs des identificateurs sont directe-
ment utilises comme priorits des messages par le protocole CAN,
lapplication de RM est directe.
Les proprits de lordonnancement de messages laide de RM
sur CAN sont les suivantes.
PCTUP
Il dcoule de celui de RM qui est de lordre de 69 %.
Robustesse face des variations de trafic
On peut changer les priodes ou les tailles des messages et
lensemble reste ordonnanable tant que le taux dutilisation des
messages priodiques ne dpasse pas le PCTUP.
Propagation de fautes temporelles
Si lon diminue la priode, ou bien si lon augmente la taille dun
message, tous les messages dont les identificateurs sont plus
grands que celui dont on a modifi des caractristiques risquent de
ne plus voir leurs chances respectes. Les fautes dune station se
propagent donc aux autres stations.
change de messages sans contraintes strictes
Les messages sans contraintes strictes peuvent tre transmis, en
leur affectant des identificateurs (donc des priorits) de manire
dynamique.
Surcot
RM sur CAN prsente un surcot ngligeable, puisque la fonction
darbitrage se fait pendant que les messages sont transmis et sans
dtruire le message qui finit par simposer sur le bus.
Lutilisation de RM sur CAN ne souffre pas des mmes insuffisan-
ces que celles inhrentes la boucle jeton. En effet :
comme les identificateurs sont affects de manire statique, la
connaissance du message le plus prioritaire, un instant donn, est
exacte ;
les identificateurs sont cods sur 11 bits (voire 29 dans la ver-
sion tendue de CAN), par consquent, les priorits associes aux
objets refltent bien leurs priodes ;
dans une application construite autour du rseau CAN, la
valeur dun objet identifi de niveau application est achemine par
un seul message de niveau MAC. Par consquent, les messages ne
sont pas fragments pour les adapter au MAC de CAN.
3.6.1.2 Approche fonde sur le contrle de transmission
Principe dordonnancement
Les travaux utilisant lapproche fonde sur le contrle de trans-
mission ont principalement port sur le jeton temporis utilis dans
les rseaux FDDI et le bus jeton IEEE 802.4. Le respect des con-
traintes de temps dpend de la manire dont on affecte les temps
dallocation du mdium aux stations. chaque tour du jeton, on
alloue un temps, not Qi , chaque station i pour quelle puisse
transmettre ses messages. Les principales techniques dallocation
du mdium aux messages priodiques sont prsentes dans [1]
[70]. Il sagit des techniques suivantes :
1 Allocation pour un message complet :
Qi = C i
2 Allocation quitable :
Qi = (TTRT )/n
avec TTRT temps de rotation du jeton dfini la
configuration du rseau,
temps rserv explicitement aux messages
apriodiques et au passage du jeton,
n nombre de stations.
________________________________________________________________________________________________________ ORDONNANCEMENT TEMPS REL

3 Allocation proportionnelle :
A B C D E
Ci 0 100 ms
Q i = ( TTRT ) -----
Pi A C
4 Allocation proportionnelle normalise : 100 ms 200 ms

i=n
A B C
C Ci
Q i = ( TTRT ) -----i
Pi
-----
Pi
200 ms 300 ms
i=1
A C E
5 Allocation locale :
300 ms 400 ms
Ci A C B
Q i = ----------------------------------------
-
P i TTRT 1 400 ms 500 ms

avec x partie entire de x. A C

6 Allocation locale amliore : 500 ms 600 ms

Ci X change de la variable priodique X

Q i = ----------------------------------------------------------------
-
max ( P i TTRT 1,1 ) changes ventuels de variables apriodiques

La premire technique dallocation nest pas utilisable dans le cas Variable Priode
de messages longs. En effet, si une station transmet un message
long, mais avec une grande priode, elle monopolise le support A 100 ms
pendant un temps qui peut conduire au non-respect des contraintes B 200 ms
des autres messages. La deuxime technique dallocation ralise un C 100 ms
partage quitable du mdium. Or, dans la plupart des cas, les sta- D 600 ms
tions transmettent des messages priodiques avec des tailles et des E 300 ms
priodes diffrentes et ont des besoins diffrents en bande syn-
chrone. Cette technique nest pas efficace dans ce cas. Figure 8 Exemple de table darbitre de bus de FIP

Proprits de lordonnancement avec jeton temporis

PCTUP
Il est gal zro pour la premire et la troisime techniques dallo-
cation. Il est de lordre de 33 % pour les deuxime, quatrime, cin-
quime et sixime techniques [1] [36] [70].
Robustesse face des variations de trafic
On peut changer les priodes ou les tailles des messages et
lensemble reste ordonnanable condition que le taux dutilisation
des messages priodiques ne dpasse pas le PCTUP. Dans le cas de
la quatrime technique dallocation, si on change une seule caract-
ristique (priode ou taille) dun message, on est oblig de recalculer
tous les temps dallocation des diffrentes stations.
Propagation de fautes temporelles
Si une station diminue sa priode ou augmente la taille de son
message, ses contraintes temporelles risquent de ne plus tre res-
pectes. Mais, comme la station doit garder le mme temps dallo-
cation du mdium qui lui a t attribu linitialisation du rseau
(on suppose, videmment, que le rseau nintroduit pas de fautes),
les contraintes des autres stations ne sont pas affectes. Par cons-
quent, lapproche fonde sur le contrle de transmission vite la
propagation des fautes temporelles.
change de messages sans contraintes strictes
Les messages sans contraintes strictes peuvent tre transmis,
mais sans les favoriser en fonction de leur urgence au niveau global
comme ctait le cas avec lapproche fonde sur larbitrage daccs.
3.6.2 Ordonnancement avec MAC contrle
daccs centralis
Lexemple de MAC que nous avons retenu pour illustrer le cas de
structures de contrle daccs centralises est celui de FIP.
Ordonnancement de messages dans FIP
Dans FIP, on distingue deux types de trafic : les objets identifis,
dits aussi variables (par exemple, la vitesse dun moteur), et les
messages au sens classique du terme qui peuvent correspondre
nimporte quelle information. Les priodes et types de variables et
les priodes de messages sont dfinis une fois pour toutes la con-
figuration du rseau. La taille maximale des messages est limite.
Les stations nont pas la possibilit de les modifier pendant lexcu-
tion de lapplication. partir des priodes de consommation des
variables (et des messages), on construit, hors ligne, une table de
scrutation qui sera suivie, en ligne, par larbitre de bus pour dtermi-
ner tout instant la variable (ou le message) pour laquelle il faut
rserver le support. Chaque station productrice de variable (ou de
message) attend que larbitre de bus diffuse lidentificateur de la
variable ou du message quelle produit, avant de pouvoir diffuser sa
valeur sur le bus. Lordonnancement de variables (ou de messages)
priodiques est donc effectu hors ligne en se basant sur la fonction
darbitrage daccs au bus. La figure 8 montre un exemple de table
darbitre de bus construite pour cinq variables priodiques.
Proprits de lordonnancement avec FIP
PCTUP

Surcot En thorie, le rseau FIP permet lchange dun ensemble de n

variables (messages) priodiques condition que :
Il est plus faible que celui engendr par lapproche fonde sur
larbitrage daccs. Par ailleurs, seule la premire technique dallo- i=n
cation ne ncessite pas de fragmentation et de rassemblage de Xi Pi < 1
messages ; son surcot est donc le plus faible. i=1

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Informatique industrielle S 8 056 17
ORDONNANCEMENT TEMPS REL _________________________________________________________________________________________________________
Xi est le temps ncessaire lchange dune variable (un mes-
sage) priodique i. Ce temps comprend, notamment, le temps de
transmission et de propagation de la trame contenant lidentifi-
cateur et le temps de transmission et de propagation de la trame
contenant la valeur de la variable (le message) dont lidentificateur
a t diffus.
Pi est la priode de la variable (message) i
La table de larbitre de bus est constitue dune liste ordonne
reprsentant toutes les variables (messages) priodiques chan-
ges durant un temps gal au plus petit commun multiple (PPCM)
des priodes. Par consquent, si la valeur du PPCM des priodes est
grande, la table de larbitre de bus peut avoir une taille suprieure
i=n
la taille de la mmoire alloue FIP. Donc, mme si Xi Pi < 1 ,
i=1
FIP peut refuser un ensemble de variables (messages) priodiques.
Dans la pratique, cette contrainte conduit effectuer des ajuste-
ments de priodes pour limiter la taille de larbitre de bus, rduisant
ainsi le PCTUP.
Robustesse face des variations de trafic
Rappelons que, dans FIP, on distingue les variables et les messa-
ges. Les tailles et les priodes des variables et les priodes des mes-
sages sont fixes la configuration du rseau et ne peuvent pas tre
modifies en ligne. Toute modification de ces caractristiques
ncessite une reconfiguration du rseau. Les tailles des messages
peuvent varier, mais sans dpasser une taille maximale connue
lavance. La table darbitre de bus tient compte de cette taille maxi-
male. FIP manque donc totalement de robustesse, du point de vue
ordonnancement.
Propagation de fautes temporelles
Les stations ne peuvent pas modifier en ligne les caractristiques
de variables (messages), par consquent, le problme de fautes
lies aux stations ne se pose pas. Par contre, comme dans toute
structure centralise, les fautes de larbitre de bus peuvent compro-
mettre toute lapplication.
change de messages sans contraintes strictes
Les variables (messages) apriodiques sont considres comme
nayant pas de contraintes de temps. Elles peuvent tre transmises
pendant les temps laisss libres aprs change des variables (et
messages) priodiques.
Surcot
Pour obtenir la valeur dune variable (un message), une trame
pralable contenant lidentificateur de variable (message) doit tre
diffuse par larbitre de bus. FIP a donc un surcot important en ce
qui concerne les trames de service. Par contre, le surcot li aux trai-
tements est ngligeable, car les calculs concernant les variables
(messages) priodiques sont effectus hors ligne.
3.7 Ordonnancement de messages
apriodiques
Un message apriodique, comme son nom lindique, est transmis
de manire alatoire. La connaissance complte des caractristi-
ques des messages apriodiques ne peut tre obtenue que pendant
lexcution effective des tches. Cependant, si lon veut augmenter
la probabilit de succs de transfert des messages apriodiques,
certaines informations doivent tre connues lavance. En particu-
lier, on doit connatre les tailles minimales, moyennes et maximales,
les lois darrive et les chances des messages apriodiques consi-
drs comme critiques du point de vue temporel. Sans la connais-
sance a priori de ces informations, les ressources ncessaires au
transfert des messages apriodiques ne peuvent tre values, con-
duisant ainsi une probabilit forte de lchec du transfert des mes-
sages apriodiques. Si les informations prcdentes sont connues,
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 056 18 Techniques de lIngnieur, trait Informatique industrielle
on peut calculer le taux moyen dutilisation du rseau par les mes-
sages apriodiques, Ua :
Ua = m x m
avec m taux moyen darrive des messages,
m dure moyenne de transmission de message.
Le succs de transfert de messages apriodiques dpend de la
valeur de Ua et de Up (le taux dutilisation des messages priodi-
ques). Comme le taux dutilisation Ua est fond sur le taux moyen
darrive et la moyenne des temps de transmission, si le taux duti-
lisation rel est suprieur au taux Ua demand, certaines chances
de messages apriodiques ne sont pas respectes.
Lordonnancement de messages apriodiques soulve plus de
problmes que lordonnancement de messages priodiques. Une
pratique courante consiste considrer que seuls les messages
priodiques sont critiques et vice versa, ce qui conduit transformer
les messages apriodiques en messages priodiques, conduisant
un surdimensionnement du rseau. Quand les messages ne sont
pas critiques du point de vue temporel, lutilisation de la stratgie du
meilleur effort est donc conseiller. Rappelons que lobjectif des
algorithmes dordonnancement de messages fonds sur lapproche
du meilleur effort est dessayer de minimiser le nombre de messa-
ges apriodiques qui dpassent leurs chances. Il est donc impor-
tant pour les applications qui utilisent cette stratgie
dordonnancement de prvoir des mcanismes de dtection et de
traitement des dpassements des chances de messages.
3.7.1 Ordonnancement avec MAC contrle
daccs dcentralis
3.7.1.1 Stratgie de garantie fonde sur larbitrage daccs
Deux mthodes principales ont t proposes pour la prise en
compte de messages apriodiques avec des contraintes strictes : la
mthode de rservation dynamique et la mthode destimation avec
conservation [36].
Mthode de rservation dynamique
Cette mthode procde selon le principe suivant : lorsquun mes-
sage apriodique demande tre transmis, on effectue une rserva-
tion du canal pour transmettre ce message. Cette rservation se fait
en demandant aux autres stations, par envoi explicite dun message
de rservation, de ne pas utiliser le canal pendant un intervalle de
temps donn et de permettre ainsi dy transmettre le message ap-
riodique. Si la rservation russit, le message apriodique est
accept, sinon il est rejet. Cette mthode conduit un surcot
important cause des messages de rservation, mais pas toujours
un surdimensionnement comme pour la mthode du serveur
priodique (cf. 3.7.1.2). cause du surcot, cette mthode est mal
adapte aux situations de surcharge.
Mthode destimation avec conservation
Le principe de cette mthode est le suivant : ds quun message
apriodique demande tre transmis, on calcule x, le pire des dlais
pour transmettre ce message, en fonction de la file dattente des
messages dj accepts par la station et de lattente la plus longue
avant davoir accs au support. Si x est infrieur ou gal
lchance du message, alors les contraintes temporelles du mes-
sage peuvent tre garanties et le message est accept. Sinon, le
message est rejet et la couche suprieure est avertie.
Cette mthode est fonde sur une estimation pessimiste, car le
calcul du temps x utilise le pire des cas (on suppose que la station
ne reoit le droit daccs quune fois que toutes les autres stations
ont utilis tout le temps qui leur est imparti). Elle ne fonctionne
quau-dessus dun MAC avec un temps daccs born (comme FDDI
ou le bus jeton). Elle ne ncessite pas de trames de service. Son
surcot est donc limit.
________________________________________________________________________________________________________ ORDONNANCEMENT TEMPS REL
3.7.1.2 Stratgie de garantie fonde sur le contrle
de transmission
On utilise principalement la mthode du serveur priodique qui
consiste affecter priodiquement un temps chaque station en
fonction de lintervalle de temps minimal de demande de transmis-
sion du message apriodique (dans ce cas, le message est parfois
qualifi de sporadique). Lorsque la station a le droit daccs, elle
teste si le message apriodique est en attente, auquel cas il est
transmis ; sinon, la station monopolise le droit daccs, sans trans-
mettre, pendant toute la dure de temps qui lui est alloue. Des
amliorations de cette technique ont t proposes pour obliger la
station qui na pas de message apriodique en attente librer le
droit daccs et laisser ainsi les autres stations transmettre leurs
messages apriodiques. Les techniques dallocation du temps
au serveur priodique sont celles prsentes dans le paragra-
phe 3.6.1.2.
On peut considrer quavec cette technique un message apriodi-
que est trait quasiment de la mme manire quun message prio-
dique. Cette technique est simple mettre en uvre et ne ncessite
ni trames de service, ni traitement spcifique comme les deux tech-
niques prcdentes, mais elle conduit un surdimensionnement du
rseau.
3.7.1.3 Stratgie du meilleur effort fonde sur larbitrage
daccs
Les principaux algorithmes de cette catgorie sont inspirs des
algorithmes dordonnancement de tches EDF (Earliest Deadline
First) [33] et LLF (Least Laxity First) [40] qui sont tous les deux opti-
maux. Voyons brivement comment des algorithmes comme EDF et
LLF peuvent tre appliqus lordonnancement de messages ap-
riodiques dans le cas de quatre rseaux.
Utilisation de EDF avec le rseau CAN
Une mthode simple permettant dadapter EDF CAN et dordon-
nancer des messages apriodiques consiste dfinir les identifica-
teurs des objets transmis sur le bus de la manire suivante : une
premire partie des bits de lidentificateur correspond lidentifica-
teur de lobjet connu au niveau application, puis une seconde partie
de lidentificateur est calcule partir du dlai du message. Le mes-
sage apriodique le plus urgent a lidentificateur le plus petit, il est
donc transmis en priorit. Le rcepteur se fonde sur la premire par-
tie des identificateurs pour reconnatre les objets qui lintressent
[53].
Utilisation de LLF avec la boucle jeton IEEE 802.5
LLF, comme son nom lindique, est fond sur lutilisation de la
laxit des messages. Lorsque lon se place au-dessus de la sous-
couche MAC, la laxit dun message m linstant t, L(t,m), est dfi-
nie par :
L(t,m) = TAMAC(m) + DMAC(m) DEP (m) t
avec TAMAC(m) instant o le message est soumis la sous-
couche MAC de lmetteur,
DMAC(m) dlai maximal acceptable pour le transfert du
message m au niveau MAC,
DEP (m) dlai dmission et de propagation sur le
support physique du message m.
Lapplication de LLF, dans le cas de la boucle jeton IEEE 802.5,
consiste assigner la priorit la plus leve au message dont la
laxit est la plus petite [68]. Chaque fois quune station reoit le
jeton, elle transmet le message dont la laxit est la plus petite. Les
problmes dapplication de LLF au rseau IEEE 802.5, pour prendre
en compte des messages apriodiques, sont les mmes que ceux
poss par lapplication de RM pour les messages priodiques
(cf. 3.6.1.1).
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Informatique industrielle
Utilisation de LLF avec CSMA/CD
Zhao et Ramamritham [71] ont propos lalgorithme dordonnan-
cement suivant qui permet dordonnancer des messages apriodi-
ques sur un rseau CSMA/CD.
1 Lorsque le bus est libre, toute station qui a un message
transmettre attend pendant une dure proportionnelle la laxit de
son message.
2 Aprs avoir attendu :
si le bus est libre, alors :
la station met son message ;
sil ny a pas de collision durant la transmission, le message
est mis en respectant ses contraintes temporelles ;
sinon un mcanisme de rsolution de collision est mis en
place pour dterminer le temps dattente (attente en fonction de la
laxit et de ladresse de la station, par exemple). Aller en 2 ;
sinon aller en 1, car il y a un message plus urgent mis par une
autre station.
Si une station tente dmettre son message quand la charge du
rseau est importante, le risque dchec de la tentative devient
lev. Par ailleurs, cette technique conduit une certaine oisivet du
rseau, cause des attentes avant de transmettre. Tous ces inconv-
nients sont dus aux problmes de collisions inhrents la technique
CSMA/CD. Cette technique est donc viter en cas de charges
moyennes ou leves.
Utilisation de LLF avec fentre temporelle sur boucle jeton
FDDI ou autre
Lalgorithme propos par Lim et al [31] permet dordonnancer des
messages apriodiques sur des rseaux en boucle jeton (FDDI ou
autre), selon le principe suivant.
1 Le jeton circulant contient trois champs : la borne infrieure et
la borne suprieure dune fentre temporelle et un compteur.
2 Quand le jeton arrive devant une station, celle-ci incrmente le
compteur si elle a un message transmettre dans la fentre tempo-
relle spcifie dans le jeton.
3 Aprs un tour complet de la boucle, le jeton revient la station
source qui procde alors de la manire suivante :
si le compteur est nul, alors la fentre temporelle est agrandie
et un jeton est mis avec la nouvelle fentre ;
si le compteur est gal un, alors le jeton est transmis la sta-
tion qui a le message le plus urgent transmettre (la station qui a
incrment le compteur se reconnat comme destinataire du jeton) ;
si le compteur est suprieur un, alors la fentre est rtrcie et
un jeton avec la nouvelle fentre est mis en circulation.
4 Quand une station transmet son message, elle met juste
aprs un jeton avec une nouvelle fentre temporelle dont la borne
infrieure est gale linstant courant et la borne suprieure est
dtermine de la manire suivante :
si cette station a un autre message transmettre, alors la
borne suprieure est gale lchance de ce message ;
sinon la borne suprieure est dtermine partir de la borne
infrieure et dune constante fixe linitialisation du rseau.
La mise en uvre de cet algorithme conduit soit modifier le
jeton de base, soit utiliser une trame de donnes qui joue le rle
du jeton voulu, mais cela conduit un surcot important. cause de
son surcot, cet algorithme est, en gnral, conseill dans le cas o
les messages apriodiques sont rares ou bien dans le cas o la
charge moyenne du rseau est faible.
3.7.1.4 Stratgie du meilleur effort fonde sur le contrle
de transmission
Les algorithmes avec stratgie du meilleur effort fonde sur le
contrle de transmission sont surtout utiliss dans le domaine du
multimdia pour le transfert dimages et de sons. Celui propos par
Vetterli and Garret [67] fonctionne selon une ide simple mieux
vaut transmettre une information approximative que rien du tout .
S 8 056 19
ORDONNANCEMENT TEMPS REL _________________________________________________________________________________________________________

Cette ide, si elle est adapte beaucoup dapplications multim- rpartie. Le lecteur pourra se rfrer aux rfrences [8] et [41], pour
dias, lest trs peu pour les applications de contrle/commande. Le dautres synthses sur ces systmes dexploitation.
principe de cette technique est le suivant.
chaque message (par exemple, une image) sont associes plu-
sieurs versions avec des quantits dinformations diffrentes (des Tableau 1 Adquation dune technique MAC
quantits qui dpendent de la qualit de limage, par exemple). On une stratgie dordonnancement de messages
transmet la version du message qui tient compte de la charge du
rseau. La slection de la version de message peut se faire de plu- Stratgie de meilleur
sieurs manires, entre autres en utilisant une information locale Stratgie de garantie
effort
seulement (chaque station mesure la charge du rseau en tenant (pour messages
(pour messages
compte du nombre de messages dans sa file dattente et choisit la priodiques)
apriodiques)
version envoyer en fonction de la charge mesure) ou en utilisant Technique
un historique rcent (chaque station compte le nombre de ses mes- MAC
Avec Avec
sages qui nont pas respect leurs chances, le nombre global de Avec Avec
contrle contrle
collisions dtectes, etc. et choisit la version mettre en fonction arbitrage arbitrage
de de
de cet historique). daccs daccs
transmission transmission
La technique utilise dans cet algorithme sapparente celle utili-
se pour lordonnancement de tches rsultats imprcis [12], [34]. Boucle
jeton Oui (1) Non (2) Oui (1) Non (2)
Cet algorithme peut prsenter un surcot important si ltat du
rseau est obtenu par change de messages entre stations. Bus jeton Non (3) Oui (4) Non (3) Oui (5)
FDDI Non (3) Oui (4) Non (3) Oui (5)
3.7.2 Ordonnancement avec MAC contrle FIP Oui (6) Non (7) Oui (8) Non (7)
daccs centralis CAN Oui (9) Non (10) Oui (9) Non (10)

Comme pour les messages priodiques, nous nous intressons
ici au cas du rseau FIP seulement. Dans FIP, tout message ou toute
variable apriodique est considr comme non critique du point de
vue temporel. Aucune contrainte de temps ne peut tre spcifie
pour les variables (messages) apriodiques. FIP gre les changes
de variables (messages) apriodiques laide de deux files dattente
FIFO (First In First Out). Les demandes de transfert de variables
(messages) apriodiques arrivent larbitre de bus suite la diffu-
sion didentificateurs priodiques rservs aux variables (messa-
ges) apriodiques et sont mises en files dattente. Ces demandes
sont servies lorsquil ny a pas de variables (messages) priodiques
changer. Ainsi FIP permet la prise en compte de variables (mes-
sages) apriodiques avec une stratgie de meilleur effort (avec deux
niveaux de priorits seulement) fonde sur larbitrage daccs.
3.8 Tableau rcapitulatif
Le tableau 1 montre avec quelles techniques MAC une stratgie
dordonnancement peut tre mise en uvre pour prendre en
compte des contraintes de temps.
4. Produits et exemples
CSMA/CD Non (11) Non (12) Oui (11) Non (12)
(1) Grce au mcanisme de priorits globales, le droit daccs est attribu
la station qui a le message le plus urgent parmi lensemble des messa-
ges en attente dans toutes les stations.
(2) Quand elle est utilise avec le mcanisme de priorits globales, la tech-
nique de la boucle jeton ne permet pas de garantir, chaque tour du
jeton, un temps dutilisation du mdium pour chaque station.
(3) Cette stratgie est inadapte, car le bus jeton et FDDI ne disposent pas
de mcanisme de priorits globales. La mise en place dun protocole qui
permet de dterminer le message le plus urgent sur un bus jeton ou
FDDI et passer le jeton la station qui a ce message conduit un sur-
cot important.
(4) En utilisant des techniques dallocation de bande synchrone
(cf. 3.6.1.2).
(5) En augmentant le temps dallocation du mdium pour une station don-
ne, on augmente les chances de garantie de respect des contraintes
temporelles de ses messages apriodiques, mais pas de celles des mes-
sages des autres stations. La notion de meilleur effort convient des
stations individuelles et non lensemble du rseau.
(6) Larbitre de bus donne le droit daccs aux stations selon un ordre pr-
dtermin, ce qui permet de garantir facilement les contraintes de varia-
bles et messages priodiques.
(7) Dans FIP, on nattribue le mdium une station que pour transmettre
une seule variable (message). La stratgie base sur le contrle de
transmission est donc inadapte dans le cas de FIP.
(8) FIP gre les changes de variables et messages apriodiques en utili-
sant deux files dattente FIFO avec deux niveaux de priorit, qui sont
servies aprs change des variables et messages priodiques.

de ralisations (9) En associant des identificateurs aux messages en fonction de leur

4.1 Exemples de systmes dexploitation
temps rel et rpartis
Plusieurs systmes dexploitation prototypes ont t proposs
pour des applications temps rel et rparties. Nous en donnons les
grands principes. Parmi ceux que nous prsentons, seul SPRING
intgre des mcanismes de placement dynamique de tches. Tous
ces systmes font dun systme de communication garantissant des
dlais borns pour le transfert de messages une condition nces-
saire pour le bon fonctionnement de toute application temps rel et
priode ou de leur chance, le message le plus urgent obtient, en prio-
rit, le droit daccs au mdium.
(10) CAN est fond sur une technique daccs comptition, on ne peut pas
garantir une station davoir le droit daccs de manire rgulire pen-
dant un intervalle de temps et un ordre fixs lavance.
(11) CSMA/CD ne permet pas daffecter le mdium aux stations sur la base
des priodes ou des chances de leurs messages. Mais, en implantant
un protocole de rservation du mdium, on peut garantir certaines con-
traintes temporelles. Cependant, tout protocole au-dessus de CSMA/CD
qui permet de connatre le message le plus urgent pour toutes les sta-
tions conduit un surcot important. Un tel protocole est adapt uni-
quement quand le taux dutilisation du rseau est faible.
(12) La fonction de contrle de transmission de CSMA/CD nest pas adapte
la prise en compte de contraintes de temps, car elle ne permet pas de
garantir une station dutiliser le mdium pendant un temps dalloca-
tion et un ordre fixs lavance.

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 056 20 Techniques de lIngnieur, trait Informatique industrielle
________________________________________________________________________________________________________ ORDONNANCEMENT TEMPS REL
Unit de traitement Unit de traitement
P P
P P
P P
Bus Ethernet
Bus Ethernet
P processeur
Figure 9 Exemple dun sous-systme MARS
4.1.1 Systme MARS
Le projet MARS (MAintainable Real-time System) [15] a dbut
luniversit de Berlin, puis continu luniversit de Vienne. Lobjec-
tif de MARS est de proposer une architecture de systme temps
rel, rparti et tolrant les fautes destine des applications criti-
ques du point de vue temporel. Lune des principales proprits de
MARS est donc naturellement la vrification, de manire analytique,
de la garantie des contraintes temporelles des tches. Cet objectif
limite videmment le champ dapplication de MARS, puisque lon
ne peut vrifier analytiquement que des tches dont le comporte-
ment est connu lavance (cest--dire des tches priodiques ou
qui apparaissent des instants connus lavance).
Une application, selon lapproche MARS, peut tre dcompose
en un ensemble de sous-systmes (clusters) autonomes. Un temps
global commun est disponible sur tous les sous-systmes. Un sous-
systme est compos dunits de traitement tolrantes aux fautes
(figure 9). Une unit de traitement tolrante aux fautes est une agr-
gation de trois processeurs fonctionnant en redondance active pour
fournir un service fiable au sous-systme. Ces units sont intercon-
nectes par un bus Ethernet dupliqu et gr par le protocole TDMA
(Time Division Multiple Access) qui garantit des temps de transmis-
sion connus lavance pour les messages. Les messages sont le
seul moyen de communication entre units de traitement. Les mes-
sages sont dats lmission et la rception, ce qui permet de syn-
chroniser les horloges.
Les tches sont excutes de manire cyclique ou des instants
fixs a priori. Toutes les donnes dune tche doivent tre prtes
avant de lancer la tche. Une tche sexcute sans interaction avec
lenvironnement et sans synchronisation avec les autres tches. la
fin de son excution, la tche diffuse son rsultat aux autres entits
du sous-systme par des messages dtat. Ce modle dexcution
de tches, qui est restrictif, a comme avantage la possibilit de cal-
culer hors ligne le temps dexcution de chaque tche. Comme les
priodes des tches sont connues, les instants de communication
sont connus lavance et les rservations de temps daccs au
rseau TDMA sont effectues a priori. Ainsi, MARS opte pour un
ordonnancement fixe de tches et de messages. Pour tenir compte
de certains aspects dynamiques (apparition dalarmes, par exem-
ple), MARS impose une conception dapplication avec plusieurs
modes de marche et un ordonnancement fixe doit tre tabli pour
chaque mode de marche. Lorsquun vnement important (et prvu
davance) apparat, le systme change de table dordonnancement.
4.1.2 Systme SPRING
SPRING est un systme dexploitation temps rel et rparti dve-
lopp luniversit du Massachusetts [55]. Cest un systme pour
des applications dynamiques, complexes et de grande taille. Tous
les types de tches sont considrs : des tches priodiques ou ap-
riodiques, des tches avec des degrs dimportance variables (dans
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Informatique industrielle
Site Site Site Site
Rseau
Site Site Site
Processeur Processeur Sous-systme
systme systme d'entres/sorties
Processeur Processeur Processeur
d'application d'application d'application
Figure 10 Composants dun systme SPRING
SPRING, on parle de tches critiques, de tches essentielles et de
tches non essentielles), avec ou sans contraintes de ressources ou
de prcdence. SPRING permet aussi de garantir une chance sp-
cifie pour un groupe de tches (dans ce cas, on sintresse lins-
tant de terminaison de la dernire tche du groupe et non pas
seulement aux instants de terminaison de chaque tche).
Chaque site dun systme SPRING est compos dune machine
multiprocesseur qui est constitue, son tour, dun (ou plusieurs)
processeur(s) dapplication, dun (ou plusieurs) processeur(s) sys-
tme et dun sous-systme dentres/sorties (figure 10). Les proces-
seurs systme excutent les oprations systme (comme
lalgorithme dordonnancement, lallocation de mmoire, etc.), ce
qui permet de ne pas imputer le surcot du systme dexploitation
aux tches dapplication. Ainsi, lorsquon calcule le temps dexcu-
tion dune tche, on ne sintresse quau traitement propre la
tche et on vite donc toutes les incertitudes sur les temps dexcu-
tion des primitives systme. Il est signaler que le surcot engendr
par le systme dexploitation est souvent un point crucial dans la
dtermination du temps dexcution allouer de manire efficace
une tche temps rel. Dans la pratique, on a lhabitude, selon le cas,
soit de considrer ce temps comme ngligeable, soit dutiliser une
valeur maximale pour viter tous les dsagrments aux tches
applicatives. SPRING apporte donc une solution efficace (mais on-
reuse) ce problme.
Les tches dapplication sexcutent gnralement sur les proces-
seurs dapplication, mais peuvent aussi rserver du temps sur les
processeurs systme. Un algorithme dynamique est utilis pour
garantir les contraintes des tches critiques ou essentielles. Lorsque
les processeurs locaux sont trop chargs pour garantir les contrain-
tes de toutes les tches locales critiques ou essentielles, un algo-
rithme dordonnancement rparti est lanc pour dterminer des
sites daccueil pour certaines tches. Pour minimiser les temps de
transfert de tches lors des oprations de migration, SPRING opte
pour la duplication de tches sur les sites du rseau. SPRING utilise
donc un placement dynamique avec migration de tches. Linforma-
tion sur la charge des diffrents sites est recueillie et maintenue par
chaque site (il sagit donc dune gestion rpartie de linformation de
charge).
Contrairement MARS, SPRING opte pour une combinaison flexi-
ble des techniques en ligne et hors ligne : les tches priodiques
(qui sont critiques ou essentielles) sont traites hors ligne et les
tches sporadiques sont traites en ligne. Ainsi, SPRING dispose
dune grande varit de techniques pour ordonnancer des applica-
S 8 056 21
ORDONNANCEMENT TEMPS REL _________________________________________________________________________________________________________
Site Site Site Site
Bus Ethernet
Site Site Site
Objet systme Application
Ordonnanceur
en ligne
Serveur de
Calendrier
communication
Objet inactif Objet en excution
Objet actif redondant
Figure 11 lments de base dun systme MARUTI
tions temps rel et rparties, mais avec des architectures matrielles
complexes.
4.1.3 Systme MARUTI
Le systme dexploitation MARUTI a t dvelopp luniversit
du Maryland et a t conu pour des applications temps rel et
rparties [30]. Le noyau de MARUTI est construit selon lapproche
oriente objet (le systme est constitu donc dun ensemble de ser-
veur dobjets). Les travaux (ou tches) sont des invocations dobjets
excutables. MARUTI dispose de mcanismes de redondance qui
permettent lutilisateur de demander dexcuter plusieurs fois un
mme objet ou davoir des objets redondants qui sexcutent en
parallle (figure 11). En plus des chances, MARUTI permet de
prendre en compte les instants exacts de dbut et de fin des excu-
tions dobjets, ce qui permet de limiter la gigue en cas de besoin.
MARUTI maintient un calendrier des excutions dobjets. Au
moment de la demande dexcution dun objet, un test dordonnan-
abilit est effectu, en tenant compte des demandes dexcution
dj acceptes. Si le test est positif, la demande est accepte, sinon
elle est rejete. Si une requte est accepte par le systme, ses
chances seront respectes. Ainsi, MARUTI opte pour une strat-
gie de garantie en ligne mais, avec cette stratgie, des demandes
dexcution dobjets (mme les objets critiques) peuvent tre reje-
tes.
Des objets distants peuvent changer des messages. Les ressour-
ces de communication sont gres comme des objets en tenant
compte des dlais des messages changs entre objets distants. Les
ressources de communication ncessaires lexcution dun travail
accept sont rserves au moment de lacceptation du travail ; cela
permet aux travaux accepts de recevoir temps les messages dont
ils ont besoin. Les machines composant une plate-forme MARUTI
sont interconnectes par un rseau Ethernet gr par le protocole
TDMA. Le placement des objets seffectue de manire statique.
4.1.4 Systme Delta-4 XPA
Delta-4 est un projet ESPRIT dont lobjectif est la proposition dun
systme rparti tolrant les fautes destin des applications exi-
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 056 22 Techniques de lIngnieur, trait Informatique industrielle
geant un haut degr de sret de fonctionnement [42]. Delta-4 XPA
(eXtra Performance Architecture) est une extension de Delta-4 pour
prendre en compte les aspects temps rel [65]. La thse de Delta-4
XPA est que la prdiction, de manire statique, de tous les compor-
tements dun systme complexe, comme le fait MARS, conduit au
mieux un surdimensionnement excessif du systme, au pire une
impossibilit, tant donn le nombre de situations prendre en
compte dans certains cas. Pour les systmes complexes, il faut rai-
sonner la fois en termes de garantie absolue, pour les situations
prvues , et en termes de meilleur effort pour les situations non
prvues (en ralit, des situations juges trs peu probables). Les
systmes conus selon lapproche Delta-4 sont des systmes prvus
pour fonctionner en mode dgrad progressif. Cela signifie que, en
cas dextrme gravit davalanche dvnements, un systme peut
devenir compltement inoprant ; cest ce qui arrive, heureusement
rarement, des navettes spatiales ou autres engins, par exemple.
Pour assurer un fonctionnement en mode dgrad progressif,
Delta-4 XPA intgre la notion de dlai et dimportance de tches et
utilise un ordonnancement premptif combinant lapproche EDF et
limportance de tches. Le placement de tches est effectu de
manire statique.
Le service de communication contient des primitives pour la plu-
part des problmes de communication dans les systmes rpartis,
notamment, communication de groupe, diffusion atomique et, sur-
tout, dlais de transfert borns. Le rseau utilis pour limplantation
de larchitecture Delta-4 XPA est un rseau local avec dlai de trans-
fert born (comme FDDI, le bus jeton ou la boucle jeton) et avec
redondance. Par ailleurs, les processeurs accdent deux sources
de temps global : un temps global interne fourni par un algorithme
de synchronisation dhorloges et un temps global externe donn
fourni par un rcepteur GPS (Global Positioning System).
4.1.5 Autres systmes
En plus des projets prsents prcdemment qui ont eu pour
objectif de proposer des systmes temps rel et rpartis complets,
dautres projets se sont principalement limits la proposition de
noyaux de systmes offrant des facilits pour implanter des applica-
tions temps rel et rparties. Il sagit notamment de ARTS, CHAOS
et DARK.
ARTS (Advanced Real-time Technology System) est un systme
rparti dvelopp luniversit de Carnegie Mellon [64]. ARTS est
conu selon lapproche oriente objet et fonctionne avec un ordon-
nanceur priorits statiques. Lordonnancement de messages uti-
lise une extension Rate Monotonic qui permet davoir un
ordonnancement homogne pour les tches et les messages. Seu-
les les requtes dont le systme peut garantir les chances sont
acceptes. Des implantations de ARTS ont t faites sur des rseaux
de type Token ring (IEEE 802.5) et FDDI.
CHAOS (Concurrent Hierarchical Adaptable Object System)
est une famille de noyaux de systme (CHAOSarc, CHAOSbase,
CHAOSmin...) pour des architectures multiprocesseurs et qui fonc-
tionnent, comme MARUTI, selon lapproche objet [48].
Le systme DARK (Distributed Ada Real-time Kernel ) a t dve-
lopp pour des applications temps rel et rparties crites en Ada
[49]. Lordonnanceur est dynamique et de type meilleur effort ; il
faut excuter dabord les tches les plus prioritaires, sans garantie
absolue du respect des chances.
________________________________________________________________________________________________________ ORDONNANCEMENT TEMPS REL

4.2 Mthodes et outils de validation Cahier des charges Code source

dapplications temps rel
Conception
4.2.1 Besoin doutils de validation dapplications d'application Compilateur

Les applications temps rel sont complexes et comportent des

lments nombreux et varis, comme les tches, les vnements,
les contraintes des tches, les protocoles de communication utili-
ss, etc. Ces applications abordent des domaines sensibles, comme
le nuclaire, le suivi de malades, le transport et les industries pol-
luantes, et leurs dysfonctionnements peuvent savrer catastrophi-
ques. Nous avons tous encore en mmoire lchec de la fuse
Ariane 5 qui, daprs les rapports des experts, est imput des
erreurs du logiciel de bord qui a t mal test [32]. Aussi est-il
important pour lutilisateur de savoir valider lapplication avant sa
mise en exploitation. La preuve formelle est la voie la plus sre pour
cela. Mais on ne sait pas prouver aujourdhui toutes les proprits,
ni valider tous les comportements. Par ailleurs, la validation elle-
mme est complexe et ncessite une dmarche progressive et
structure, tout comme la construction de lapplication. Par bou-
tade, on en vient dire quune application bien construite est une
application dont la validation est simple raliser. Cest une
manire dexprimer que lon na rellement compris un problme
ou une application que lorsquon a fait apparatre au premier plan
ses structures fondamentales ; prouver alors la validit de celles-ci
est la base de la preuve de toute application. Construire une applica-
tion de faon mthodique et accompagner cette approche par une
validation progressive, quelle soit formelle ou quelle fasse de la
simulation, ncessite des outils.
Une application temps rel prsente deux aspects : un aspect
fonctionnel et un aspect temporel. Les deux aspects doivent tre
valids. Un nombre relativement important de travaux ont t dve-
lopps ces quinze dernires annes sur les mthodes formelles
pour la vrification des applications temps rel. Malheureusement,
les outils nont pas suivi. On ne trouve aujourdhui que quelques
prototypes dvelopps par la communaut universitaire [35], [46].
Loutil PERTS que nous vous prsentons en fait partie.
4.2.2 Outil PERTS
PERTS (Prototyping Environment for Real-Time Systems) est un
outil permettant daider la validation des applications temps rel
implantes sur des architectures multiprocesseurs ou rparties [35].
Tous les modules de PERTS sont programms en C++ et fonction-
nent sous X-Window. Llment central de PERTS est sans doute son
analyseur dordonnanabilit (figure 12). PERTS permet de prendre
en compte la plupart des types de tches tudis dans la littrature
(tches priodiques ou apriodiques, tches rsultat imprcis,
tches avec ou sans contraintes de prcdence et de ressources,
tches premptibles ou non). PERTS offre un ensemble de fonctions
qui permet de prendre en compte la quasi-totalit des algorithmes
et protocoles connus en ce qui concerne :
les algorithmes dordonnancement priorits (Earliest Dead-
line First, Rate Monotonic...) ;
les serveurs pour tches apriodiques ;
les algorithmes dordonnancement des tches rsultat
imprcis ;
les protocoles de contrle daccs aux ressources (protocole
plafond de priorit, protocole hritage de priorit...).
Chaque fois quil est possible, PERTS utilise des techniques analy-
tiques fondes sur des rsultats thoriques prouvs (comme ceux
prsents dans larticle S 8 055 de ce trait).
Description des entres
PERTS fournit lutilisateur des interfaces qui lui permettent de
dcrire lapplication valider. Une description dapplication temps
Outil d'analyse
Description Description
abstraite concrte des paramtres
des tches des tches temporels
Description
de ressources
Gnrateur
de charge
Analyseur
d'ordonnanabilit
Outil de mesure
Plate-forme
du temps d'excution
Figure 12 Constituants de loutil PERTS
rel est compose de trois parties : description des tches, descrip-
tion des ressources utilises et description des algorithmes dordon-
nancement et des protocoles de contrle daccs aux ressources.
ces trois parties il faut ajouter la description du rseau qui se
rsume un dlai maximal de communication.
Une tche est dcrite principalement par les paramtres suivants :
attributs fonctionnels (nom, premption autorise ou non,
importance et fonction de laxit qui dcrit, pour les tches rsultat
imprcis seulement, le cot engendr par la terminaison de la tche
un instant donn) ;
attributs temporels (temps maximal dexcution, temps
moyen dexcution, date au plus tt, priode, chance, probabilits
de distribution des paramtres des tches apriodiques) ;
ressources utilises (nombre dexemplaires pour chaque res-
source utilise, intervalles de temps durant lesquels la tche peut
utiliser chaque ressource).
Les relations de prcdence et de communication entre tches
sont dcrites laide dun graphe. En particulier, ce graphe dcrit la
taille et la frquence des donnes changes entre tches.
Les tches apriodiques peuvent tre dclenches de manire
alatoire et les communications peuvent tre indterministes selon
le rseau utilis. Pour valider ces aspects alatoires, PERTS intgre
un environnement de simulation orient objet qui permet lutilisa-
teur de construire le modle associ au comportement dynamique
de son application.
Chaque ressource utilise est dcrite principalement laide des
paramtres suivants :
type de ressource (imprimante, processeur, fichier...) ;
nombre dexemplaires de la ressource ;
caractre consommable ou non de la ressource ;

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Informatique industrielle S 8 056 23
ORDONNANCEMENT TEMPS REL _________________________________________________________________________________________________________
ressource premptible ou non ;
temps dattente pour acqurir la ressource lorsque celle-ci est
libre (ce temps dpend de la nature de la ressource ; par exemple,
pour acqurir un canal de communication, il faut attendre le temps
ncessaire ltablissement de connexion) ;
temps de libration de la ressource (temps entre le moment o
une tche libre la ressource et le moment o cette ressource
devient rellement disponible pour une nouvelle acquisition).
La troisime partie de la description dapplication concerne le
choix dun algorithme dordonnancement de tches (Rate Monoto-
nic, Earliest Deadline First, etc.) et dun protocole de contrle
daccs aux ressources (protocole hritage de priorit, protocole
priorit plafond, etc.).
Rsultats fournis
Lanalyseur dordonnanabilit qui constitue llment central de
loutil PERTS fournit diffrentes dures (temps dexcution des
tches, temps doccupation des ressources...) en fonction des
charges, des algorithmes dordonnancement et des protocoles de
contrle daccs aux ressources considrs, pour les pires cas de
fonctionnement. Lanalyseur dordonnanabilit peut tre utilis
plusieurs fins :
tester si lensemble des ressources spcifies est suffisant
pour les tches ;
slectionner les algorithmes de calcul pour les tches rsul-
tats imprcis ;
suggrer des valeurs de paramtres tels que les priodes des
serveurs des tches apriodiques.
Dans le cas multiprocesseur ou rparti, PERTS permet dobtenir
des placements de tches valides. Lorsquil ny a pas de placement
possible, loutil peut suggrer des modifications faire pour obtenir
un placement valide.
Pour rpondre divers niveaux de validation, PERTS distingue
trois types danalyse : analyse du systme, analyse dun site et ana-
lyse de bout en bout.
Lanalyse du systme a principalement deux objectifs :
aider lutilisateur placer les tches sur les sites du systme ;
donner diffrents rsultats de lanalyse dordonnanabilit.
Lanalyse de site concerne lanalyse dordonnanabilit des
tches affectes un processeur. Elle fournit lutilisateur toute une
varit de rsultats, parmi lesquels :
lordonnanabilit des tches affectes au site (le rsultat est
donn sous forme graphique pour aider, dans le cas o lensemble
des tches nest pas ordonnanable, lutilisateur comprendre
pourquoi certaines contraintes ne sont pas garanties) ;
le taux dutilisation du processeur ;
le temps dattente et de rponse moyen concernant lutilisa-
tion des ressources.
Lutilisateur peut alors agir sur certains aspects. Par exemple,
pour amliorer les temps de rponse des tches apriodiques, il
peut changer de type de serveur. Il peut aussi lancer une simulation
des tches apriodiques et visualiser les rsultats de la simulation.
Lanalyse de bout en bout concerne un systme rparti dans sa
globalit. Lanalyse de bout en bout permet danalyser des temps
dexcution, dans le pire des cas, selon les processeurs sur lesquels
chaque tche peut sexcuter. PERTS considre que les tches ne
migrent pas durant leur excution.
Enfin, lenvironnement de simulation permet de spcifier le sys-
tme sur lequel sera implante lapplication avec diffrents niveaux
de dtails. On peut spcifier les processeurs, le rseau de communi-
cation, les units de disques, les priphriques, etc., de manire
obtenir une description dtaille (dite aussi description concrte) de
lapplication et la valider un niveau plus fin.
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 056 24 Techniques de lIngnieur, trait Informatique industrielle
5. Conclusion
La rpartition est souvent indispensable pour matriser et garantir
les contraintes temporelles dans les systmes temps rel comple-
xes. Mais une telle rpartition conduit de nouveaux problmes
quil faut rsoudre. Parmi ces problmes, on trouve celui de lordon-
nancement temps rel. En effet, le respect des contraintes temporel-
les globales dune application temps rel et rpartie implique le
respect, la fois, des contraintes temporelles des tches et de celles
des messages changs entre ces tches. Nous avons synthtis les
diffrentes techniques qui permettent le placement et la migration
de tches temps rel et la communication de messages changs
entre ces tches dans des architectures rparties.
Nous avons soulign que le placement peut se faire de manire
statique ou dynamique. Le placement statique est simple mettre
en uvre et facilite le test dordonnanabilit. Malheureusement, il
noffre pas de souplesse pour ragir aux surcharges des sites, pour
prendre en compte certains aspects dynamiques. Le placement
dynamique, avec la migration de tches, permet de mieux tenir
compte des charges de lensemble des sites et de privilgier lexcu-
tion des tches les plus importantes dans le systme. Cependant, le
placement dynamique engendre des surcots de traitement et de
communication non ngligeables et rend difficile voire impossible
le test a priori de lordonnanabilit des tches. Entre le tout statique
et le tout dynamique, une tendance qui tend simposer est celle
qui consiste choisir un placement statique pour des tches impor-
tantes, priodiques et connues lavance et un placement dynami-
que, avec ventuellement des migrations, pour les autres.
La prise en compte des contraintes temporelles de messages doit
se faire tous les niveaux de la communication. Par consquent, les
profils de communication temps rel sont dune importance capitale
pour garantir le bon fonctionnement des applications temps rel et
rparties. Nous avons trait un des aspects de la communication
temps rel, et non des moindres, savoir la prise en compte des
contraintes de temps au-dessus du niveau MAC. En effet, cest au
niveau MAC quapparat le problme de partage du mdium entre
les stations o sexcutent les tches communicantes. Un ordon-
nancement adquat au-dessus du niveau MAC est une clef indispen-
sable pour garantir les chances des messages. Les principales
techniques MAC et techniques dordonnancement de messages qui
leur conviennent ont t prsentes, montrant ainsi que beaucoup
de techniques MAC peuvent tre utilises pour vhiculer des messa-
ges temps rel.
Notre tude des messages priodiques sest appuye sur une
hypothse courante dans les applications temps rel et rparties,
savoir, les dlais sont gaux aux priodes. Cependant, pour rpon-
dre aux besoins dautres applications, dautres contraintes doivent
tre prises en compte, notamment : des messages avec des chan-
ces diffrentes des priodes, des contraintes de gigue, des contrain-
tes concernant le taux derreur ou le taux de perte. Les travaux sur
ces problmes, dans le contexte des rseaux accs multiple, sont
encore rares aujourdhui. Cependant, ces problmes sont tudis
depuis quelques annes dans le contexte des rseaux commuta-
tion de paquets, comme ATM, pour des applications multimdias o
les contraintes de gigue, de taux derreur et de taux de perte sont
trs rpandues. Il y a donc des rapprochements effectuer entre les
deux catgories de rseaux pour concevoir les rseaux temps rel
de demain.
Enfin, il faut souligner que lordonnancement rparti est actuelle-
ment un stade embryonnaire et que beaucoup reste faire pour
obtenir des rsultats thoriques, comme on en a pour lordonnance-
ment monoprocesseur, qui permettent de sassurer de la garantie
des contraintes temporelles, et de guider le test et la validation des
applications rparties et des rseaux.
________________________________________________________________________________________________________ ORDONNANCEMENT TEMPS REL
[1] AGRAWAL (G.) et al. Local synchronous
capacity allocation schemes for guaran-
teeing messages deadlines with the timed
token protocol. In Proceed. of INFOCOM93,
San Francisco, p. 186-193 (1993).
[2] ALABAU (M.) et DECHAIZE (T.). Ordonnan-
cement temps rel par chance. Technique
et Science Informatiques, vol. 11, n 3, p. 59-
123 (1992).
[3] ANDR (F.) et PAZAT (J.-L.). Le placement
de tches sur des architectures parallles.
Technique et Science Informatiques, vol. 7,
n 4, p. 385-401, (1988).
[4] BALTER (R.), BANTRE (J.P.) et KRAKOWIAK
(S.) (d.). Construction des systmes
dexploitation rpartis. Collection didactique
dite par lINRIA (1991).
[5] BANNISTER (J.) et TRIVEDI (K.). Task allo-
cation in fault-tolerant distributed systems.
Acta Informatica, 20, p. 261-281 (1983).
[6] BERNARD (G.), STVE (D.) et SIMATIC (M.).
Placement et migration de processus dans
les systmes rpartis faiblement coupls.
Technique et Science Informatiques, vol. 10,
n 5, p. 375-392 (1991).
[7] BLAZEWICZ (J.), HECKER (K.H.), PESCH (E.),
SCHMIDT (G.) et WEGLARZ (J.). Schedu-
ling computer and manufacturing processes.
Springer -Verlag editions (1996).
[8] BODHISATTWA (M.), KARSTEN (S.) et
KAUSHIK (G.). A survey of real-time opera-
ting systems. Research report N GIT-CC-93-
18, College of computing, Georgia institute
of technology, Atlanta (mars 1993).
[9] BURNS (A.) et WELLINGS (A.J.). Real-time
systems and their programming languages.
Addison Wesley editions (1991).
[10] CARDEIRA (C.) et MAMMERI (Z.). Ordon-
nancement de tches dans les systmes
temps rel et rpartis. Revue RAIRO Automa-
tique, Productique, Informatique Industrielle,
vol. 28, n 4, p. 353-384 (1994).
[11] CHU (W.W.) et LAN (L.M.T.). Task allocation
and precedence relations for distributed real-
time systems. IEEE Transactions on Compu-
ters, C-36(6), p. 667-679 (1987).
[12] CHUNG (J.), LIU (J.) et LIN (K.). Scheduling
periodic jobs that allow imprecise results.
IEEE Transactions on Computers, 39(9),
p. 1156-1174 (1990).
[13] CHUNG (Y.-C.), LIU (C.-C.) et LIU (J.-S.).
Applications and performance analysis of an
optimization approach for list scheduling
algorithms on distributed memory multipro-
cessors. Journal of Information Science and
Engineering 11, p. 155-181 (1995).
[14] CORNAFION. Systmes informatiques
rpartis : concepts et techniques. ditions
Dunod (1981).
[15] DAMM (A.), REISINGER (J.), SCHNAKEL (W.)
et KOPETZ (H.). The real-time operating
system of Mars. Operating Systems Review,
23 (3), p. 141-157 (juill. 1989).
[16] Deutsche Institut fr Normung. PROFIBUS
standard part 1 and 2. DIN 19245-1 (04-91) :
Messen, Steuern, Regeln ; PROFIBUS ; Pro-
cess Field Bus ; bertragungstechnik, Buszu-
griffs-und bertragungs protokoll,
Dienstschnittstelle zur Anwendungs-Schicht,
Management (Measurement and control ;
PROFIBUS Field Bus ; data transmission
technic, medium access methods and trans-
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Informatique industrielle
Rfrences bibliographiques
mission protocol, service interface to the
application layer, management). DIN 19245-2
(04-91) : Messen Steuern, Regeln ; PROFI-
BUS. Process Field Bus ; Kemmunikations-
Modell, Dienste fr die Anwendung, Proto-
koll, Syntax, Codierung, Schmittstelle zur
Schicht 2, Management (Measurement and
control ; PROFIBUS ; Process Field Bus com-
munication-model, services for user applica-
tion, protocol, specification, coding, data
layer interface, management).
[17] EAGER (D.L.), LAZOWSKA (E.D.) et ZAHOR-
JAN (J.). Load sharing in distributed sys-
tems. IEEE Transactions on Software
Engineering vol. SE-12, p. 662-675 (may
1986).
[18] ELLOY (J.-P.). Les contraintes du temps rel
dans les systmes industriels rpartis. RGE
(Revue gnrale dlectricit) N 2/1991,
p. 26-34.
[19] FONSECA (P.) et MAMMERI (Z.). A fra-
mework for the analysis of non-deterministic
clock synchronisation algorithms. In LNCS
n 1151, p. 159-174, Springer-Verlag (1996).
[20] GAREY (M.) et JOHNSON (D.). Complexity
results for multiprocessor scheduling under
resources constraints. SIAM Journal of Com-
puting, 4, p. 397-411 (1975).
[21] HE (J.), MAMMERI (Z.) et THOMESSE (J.-P.).
Modlisation des techniques de synchroni-
sation dhorloges. Technique et Science
Informatiques, vol. 13, n 2, p. 185-221
(1994).
[22] HOU (C.J.) et SHIN (K.G.). Allocation of
periodic task modules with precedence and
deadline constraints in distributed real-time
systems. Proc. Real-time Systems Sympo-
sium, Phoenix, AZ, p. 146-155 (dc. 1992).
[23] ISO. Road vehicles - Low-speed serial data
communication, Part 2: low-speed controller
area network (CAN). International Standard
ISO 11519-2 (1994) : vhicules routiers. Com-
munication en srie de donnes basse
vitesse. Partie 2 : rseau local commande
basse vitesse (CAN) (Publie actuellement en
anglais seulement). Amendement 1 : 1995
ISO 11519-2 : 1994 (Publi actuellement en
anglais seulement).
[24] KAISER (C.) et SANTELLANI (Ch.). Ptrar-
que Plate-forme dexprimentation pour
lordonnancement adaptatif temps rel strict
dapplications rparties. Technique et
Science Informatiques, vol. 17, n 1 (1998).
[25] KRAKOWIAK (S.). Les systmes dexploita-
tion rpartis : volution rcente et tendance
de la recherche. Technique et Science Infor-
matiques, vol. 6, n 2, p. 151-161 (1987).
[26] KWEON (S.-K.) et SHIN (K.G.). Traffic-con-
trolled rate monotonic priority scheduling of
ATM cells. In Proceed. of 15th IEEE INFO-
COM (mars 1996).
[27] LAPRIE (J.-C.). Dependability: basic con-
cepts and terminology. Springer-Verlag di-
tions (1992).
[28] LE LANN (G.). Designing real-time depen-
dable distributed systems. Computer Com-
munications, vol. 15, n 4, p. 225-234 (mai
1992).
[29] LE LANN (G.) et RIVIRE (N.). Real-time
communications over broadcast networks :
the CSMA-DCR and the DOD/CSMA-CD pro-
tocols. INRIA Research Report n 1863 (mars
1993).
[30] LEVI (S.T.), TRIPATHI (S.K.), CARSON (S.D.) et
AGRAWALA (A.K.). The MARUTI hard real-
time operating system. ACM Operating Sys-
tems Review, 23 (3), p. 90-105 (juil. 1989).
[31] LIM (C.), YAO (L.) et ZHAO (W.). A compara-
tive study of three token ring protocols for
real-time communications. 11th IEEE Int.
Conference on Distributed Computing Sys-
tems, p. 308-317 (mai 1991).
[32] LIONS (J.L.). ARIANE 5 - Flight 501 failure.
http://andrea.it.dtu.dk/~hra/ariane5rep.html
(19 juil. 1996).
[33] LIU (C.L.) et LAYLAND (J.W.). Scheduling
algorithms for multiprogramming in a hard-
real-time environment. Journal of ACM,
vol. 20, n 1, p. 46-61 (jan. 1973).
[34] LIU (J.W.S.), LIN (K.J.), SHIH (W.K.), YU
(A.C.), CHUNG (J.Y.) et ZHAO (W.). Algo-
rithm for scheduling imprecise computation.
IEEE Transactions on Computer, p. 58-68
(1991).
[35] LIU (J.W.S.), RENDONDO (J.L.), DENG (Z.),
TIA (T.S.), BETTATI (R.), SILBERMAN (A.),
STORCH (M.), HA (R.) et SHIH (W.K.).
PERTS : A prototyping environment for real-
time systems. Technical report UIUCDCS-R-
93-1802, Department of Computer Science,
University of Illinois (mai 1993).
[36] MALCOLM (N.) et ZHAO (W.). Hard real-
time communication in multiple-access
networks. Journal of Real-Time Systems (8)
p. 35-77 (1995).
[37] MAMMERI (Z.) et THOMESSE (J.-P.).
Rseaux locaux. Couches physiques et
liaison de donnes. Normes ISO 8802 et IEEE
802. Editions Teknea (1991).
[38] Manufacturing Automation Protocol. MAP :
3.0 Implementation release. MAP Users
Group (1987).
[39] MULLENDER (S.). Distributed systems.
Second edition, Addison-Wesley (1995).
[40] PANWAR (S.S.), TOWSLEY (D.) et WOLF
(J.K.). Optimal scheduling policies for a
class of queues with customer deadlines to
the beginning of service. Journal of ACM
35(4) p. 832-844 (1988).
[41] PANZIERI (F.) et DAVOLI (R.). Real-time sys-
tems: a tutorial. In Performance evaluation of
computer and communication systems,
LNCS n 729, p. 435-462 (1993).
[42] POWELL (D.) (d.). Delta-4 - A generic
approach for dependable distributed compu-
ting. ESPRIT Research report, Springer-Ver-
lag (1991).
[43] RAMAMRITHAM (K.). Channel characteris-
tics in local area hard real-time systems.
Computer Networks and ISDN Systems, p. 3-
13 (1987).
[44] RAMAMRITHAM (K.) et STANKOVIC (J.A.).
Timed-constrained communication protocols
for hard real-time systems. 6th IEEE Work-
shop on Real-Time Operating Systems and
Software, Pittsburg (mai 1989).
[45] RAYNAL (M.). La communication et le
temps dans les rseaux et les systmes
rpartis. ditions Eyrolles (1991).
[46] SAAD-BOUZEFRANE (S.) et COTTET (F.). A
performance analysis of distributed hard
real-time applications. Proceedings of 2nd
IEEE International Workshop on Factory
Communication system, Borcelona, Spain,
p. 167-176 (1-3 oct. 1997).
S 8 056 25
ORDONNANCEMENT TEMPS REL _________________________________________________________________________________________________________
[47] SATHAYE (S.) et STROSNIDER (J.K.). Con-
ventional and early token release scheduling
models for the IEEE 802.5 token ring. Journal
of Real-Time Systems, (7) p. 5-32 (juil. 1994).
[48] SCHWAN (K.), GOPINATH (P.) et BO (W.).
CHAOS - Kernel support for objects in the
real-time domain. IEEE Transactions on Com-
puters, vol. C-36, n 8, p. 904-916 (aot 1987).
[49] SCOY (R.), BAMBERGER (J.) et FIRTH (R.).
An overview of DARK. In Mission critical ope-
rating systems. Agrawala (A.), Gordon (K.),
and Hwang (P.) (edit.), IOS Press (1992).
[50] SHA (L.), SATHAYE (S.) et STROSNIDER
(J.K.). Scheduling real-time communication
on dual link networks. Proceed. of 13th IEEE
Real-Time Systems Symposium, Phoenix,
p. 188-197 (2-4 dc. 1992).
[51] SHEN (C.). On ATM support for distributed
real-time applications. In Proceed. of IEEE
Real-Time Technology and Applications
Symposium (10-12 juin 1996).
[52] SHIN (K.) et CHANG (Y.). Load sharing in
distributed real-time systems with state
change broadcasts. IEEE Transactions on
Computers, 38 (8), p. 1124-1142 (aot 1989).
[53] SHIN (K.G.). Real-time communications in a
computer-controlled workcell. IEEE Transac-
tions on Robotics and Automation, vol. 7,
n 1, p. 105-113 (fvr. 1991).
[54] STANKOVIC (J.), RAMAMRITHAM (K.) et
CHENG (S.). Evaluation of a flexible task
scheduling algorithm for distributed hard
real-time systems. IEEE Transactions on
Computers, 34 (12), p. 1130-1143 (dc. 1985).
[55] STANKOVIC (J.A.) et RAMAMRITHAM (K.).
The Spring Kernel: a new paradigm for real-
time operating systems. ACM Operating Sys-
tems Review, 23 (3), p. 54-71 (juil. 1989).
[56] STANKOVIC (J.A.). Distributed real-time
computing: the next generation. Technical
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 056 26 Techniques de lIngnieur, trait Informatique industrielle
report TR92-01, Dept. of Computer Science,
University of Massachusetts (1992).
[57] STORCH (M.F.) et LIU (J.W.S.). Heuristic
algorithms for periodic job assignment. In
Proceedings of Workshop on Parallel and
Distributed Real-Time Systems, Newport
Beach, CA, p. 245-251 (avr. 1993).
[58] STROSNIDER (J.K.). Highly responsive
real-time token rings. PhD Thesis, Pittsburgh
University (aot 1988).
[59] TALBI (E.). Allocation dynamique de pro-
cessus dans les systmes distribus et paral-
lles. Rapport interne, LIFL Lille [ftp.lifl.fr/
pub/reports/AS-publi/an95/as-162] (1995).
[60] TANNENBAUM (A.S.). Distributed opera-
ting systems. Prentice-Hall (1995).
[61] THOMESSE (J.-P.). Le rseau de terrain FIP.
Rseaux et Informatique Rpartie, vol. 3,
n 3, p. 287-321 (1993).
[62] TIA (T.S.) et LIU (J.W.-S.). Assigning real-
time tasks and resources to distributed sys-
tems. International Journal of Mini and
Microcomputers, vol. 17, n 1, p. 18-25
(1995).
[63] TINDELL (K.), BURNS (A.) et WELLINGS (A.).
Allocating hard real-time tasks: an NP-hard
problem made easy. Journal of Real-Time
Systems (4) p. 145-65 (1992).
[64] TOKUDA (H.) et MERCER (C.). ARTS : A dis-
tributed real-time kernel. ACM Operating
Systems Review 23 (3) (juil. 1989).
[65] VERISSIMO (P.), BARRET (P.), BOND (P.), HIL-
BORNE (A.), RODRIGUES (L.) et SEATON
(D.). The extra Performance Architecture
(XPA) in DELTA-4. In A generic architecture
for dependable distributed computing,
Powell (D.) (ed.), Springer-Verlag (1991).
[66] VERMA (D.C.), ZHANG (H.) et FERRARI (D.).
Delay jitter control for real-time communica-
tions in a packet-switched network. In Pro-
ceed. of IEEE TRICOM91, p. 35-43 (avril
1991).
[67] VETTERLI (M.) et GARRET (M.W.). Joint
source channel coding for real-time packet
service. In Proceed. of Australien Video Com-
munications Workshop, p. 136-145 (1990).
[68] YAO (L.-J.). Real-time communication in
token ring networks. PhD Thesis, University
of Adelaide (1994).
[69] ZHANG (H.) et FERRARI (D.). Rate-control-
led static-priority queueing. In Proceed. of
IEEE INFOCOM, San Francisco, p. 227-236
(1993).
[70] ZHANG (S.) et BURNS (A.). Guaranteeing
synchronous message sets in FDDI
networks. Proceed. of 13th Workshop on Dis-
tributed Computer Control Systems, Tou-
louse, p. 107-112 (27-29 sept. 1995).
[71] ZHAO (W.) et RAMAMRITHAM (K.). Virtual
time CSMA protocols for hard real-time com-
munication. IEEE Transactions on Software
Engineering, SE-13 (8), p. 938-952 (aot
1987).
[72] ZHENG (Q.) et SHIN (K.G.). Fault-tolerant
real-time communication in distributed com-
puting systems. 22nd Intern. Symposium on
Fault-tolerant Computing, Boston, p. 86-93
(oct. 1992).
[73] ZHENG (Q.), SHIN (K.) et SHEN (C.). Real-
time communication in ATM networks. In
Proceed. of 19th Annual Local Computer
Network Conference, Minneapolis, Minne-
sota, p. 156-165 (1994).
[74] ZHOU (S.), WANG (J.), ZHANG (X.) et
DELISLE (P.). Utopia: A load sharing facility
for large, heterogeneous distributed compu-
ter systems. Technical report CSRI-257, Uni-
versity of Toronto (avril 1992).