These
These
These
Introduction générale
1. Introduction ________________________________________________________ 7
2. Les systèmes temps réel _______________________________________________ 7
2.1. Présentation générale____________________________________________________7
2.2. Structure d’un système de contrôle ________________________________________8
2.3. Les tâches ____________________________________________________________10
2.4. La problématique de l’ordonnancement ___________________________________10
2.5. Les algorithmes d’ordonnancement _______________________________________11
2.5.1. Préemptif/non Préemptif _____________________________________________________11
2.5.2. Hors ligne/en ligne__________________________________________________________11
2.5.3. Conduits par la priorité ______________________________________________________11
3. Les réseaux de communication temps réel _______________________________ 12
3.1. Architecture __________________________________________________________12
3.2. Les messages temps réel_________________________________________________13
3.3. Ordonnancement des messages temps réel _________________________________13
4. Cadre du travail ____________________________________________________ 14
1. Introduction _______________________________________________________ 17
2. Modélisation des tâches ______________________________________________ 18
3. Représentation d’une séquence ________________________________________ 19
3.1. Durée de validation ____________________________________________________20
3.2. Condition nécessaire de validation ________________________________________20
4. Classification des tâches _____________________________________________ 21
5. Les tâches indépendantes_____________________________________________ 21
5.1. Les tâches périodiques __________________________________________________21
5.1.1. Les algorithmes d’ordonnancement à priorité fixe _________________________________21
5.1.2. Les algorithmes d’ordonnancement à priorité dynamique ____________________________24
5.2. Les tâches apériodiques _________________________________________________27
5.2.1. Le serveur à scrutation _______________________________________________________27
5.2.2. Le serveur ajournable________________________________________________________28
1
5.2.3. Autres méthodes ___________________________________________________________ 28
6. Les tâches dépendantes _______________________________________________29
6.1. Prise en compte des relations de précédence ________________________________29
6.1.1. Précédence avec l’algorithme RM _____________________________________________ 29
6.1.2. Précédence avec l’algorithme DM _____________________________________________ 30
6.1.3. Précédence avec l’algorithme ED ______________________________________________ 30
6.2. La prise en compte du partage de ressources _______________________________32
6.2.1. Le protocole à priorité héritée _________________________________________________ 33
6.2.2. Le protocole à priorité plafond ________________________________________________ 36
6.2.3. Le protocole d’allocation de la pile (PAP) _______________________________________ 38
7. Conclusion _________________________________________________________41
1. Introduction ________________________________________________________43
2. Classification des protocoles MAC ______________________________________45
3. Les techniques d’accès _______________________________________________45
4. Protocoles à accès aléatoire____________________________________________46
4.1. Le protocole CAN______________________________________________________46
4.2. Le protocole CSMA/DCR _______________________________________________49
4.2.1. Principe __________________________________________________________________ 49
4.2.2. Calcul de l’époque _________________________________________________________ 50
5. Protocoles d’accès à contrôle centralisé: exemple de FIP____________________50
6. Protocoles d’accès à contrôle distribué___________________________________53
6.1. Le protocole FDDI _____________________________________________________53
6.2. Le protocole TDMA ____________________________________________________55
7. Conclusion _________________________________________________________56
1. Introduction ________________________________________________________59
2. Quelques exécutifs temps réel répartis ___________________________________59
2.1. Le projet MARS _______________________________________________________59
2.1.1. Architecture matérielle de MARS______________________________________________ 60
2.1.2. Le système d’exploitation de MARS ___________________________________________ 60
2.1.3. Conclusion _______________________________________________________________ 62
2.2. Le projet SPRING _____________________________________________________63
2.2.1. Classification et caractérisation des tâches _______________________________________ 63
2.2.2. Architecture de SPRING: Springnet ____________________________________________ 64
2.2.3. L’ordonnancement des tâches _________________________________________________ 64
2.2.4. Conclusion _______________________________________________________________ 65
1
2.3. Le système CHORUS___________________________________________________66
2.3.1. Les objets dans CHORUS ____________________________________________________66
2.3.2. L’ordonnancement des tâches _________________________________________________67
3. Outils et méthodes de validation _______________________________________ 68
3.1. L’outil PERTS ________________________________________________________69
3.1.1. Editeur de tâches ___________________________________________________________69
3.1.2. Editeur de ressources ________________________________________________________69
3.1.3. L’ordonnanceur ____________________________________________________________70
3.2. Une méthode de validation d’applications temps réel réparties ________________72
3.2.1. Hypothèses générales________________________________________________________72
3.2.2. Description de l’exemple d’application __________________________________________72
3.2.3. Description du réseau utilisé __________________________________________________74
3.2.4. Analyse temporelle _________________________________________________________74
3.2.5. Conclusion ________________________________________________________________75
4. Conclusion ________________________________________________________ 76
1. Introduction _______________________________________________________ 79
2. Le modèle général __________________________________________________ 80
2.1. Modèle structurel ______________________________________________________80
2.2. Le modèle temporel de tâches ____________________________________________81
2.3. Le modèle temporel de messages _________________________________________82
3. Principe de la méthodologie___________________________________________ 83
3.1. Modélisation de l’application ____________________________________________84
3.1.1. Calcul du temps de propagation d’un message ____________________________________84
3.1.2. Calcul du délai de transmission d’un message_____________________________________86
3.1.3. Calcul des dates d’insertion des messages ________________________________________95
3.2. Prise en compte de la précédence _________________________________________99
3.2.1. Mise à jour des dates de réveil des tâches réceptrices _______________________________99
3.2.2. Mise à jour des dates de réveil des tâches successeurs _____________________________100
3.3. Ordonnancement des tâches et des messages ______________________________105
4. Exemples d’applications temps réel réparties ____________________________ 106
4.1. Exemple du producteur/consommateur___________________________________106
4.1.1. Calcul des paramètres temporels des messages ___________________________________107
4.1.2. Prise en compte de la précédence globale _______________________________________108
4.1.3. Ordonnancement des tâches et des messages_____________________________________108
4.2. Exemple de l’ascenseur ________________________________________________109
4.2.1. Cahier des charges _________________________________________________________110
4.2.2. Étude de l’application ______________________________________________________111
4.2.3. Application de la méthodologie d’analyse _______________________________________114
5. Conclusion _______________________________________________________ 118
1
Chapitre 6 : Analyse des Performances
1. Introduction _______________________________________________________121
2. MOSARTS : un outil de validation d’applications temps réel réparties ________121
2.1. Description de l’application_____________________________________________122
2.1.1. Description d’un site _______________________________________________________ 122
2.1.2. Description du réseau ______________________________________________________ 123
2.2. Le noyau fonctionnel de MOSARTS _____________________________________124
3. Les critères de performance mesurés ___________________________________125
3.1. Pour les tâches _______________________________________________________125
3.2. Pour les messages _____________________________________________________130
3.3. Pour l’application globale ______________________________________________132
4. Résultats de simulation ______________________________________________133
4.1. Premier exemple______________________________________________________133
4.2. Deuxième exemple ____________________________________________________138
4.2.1. Analyse temporelle des sites _________________________________________________ 138
4.2.2. Analyse temporelle du réseau ________________________________________________ 142
4.2.3. Analyse temporelle de bout en bout ___________________________________________ 146
5. Conclusion________________________________________________________146
Conclusion Générale
Bibliographie
Annexes
1
Introduction Générale
Notre méthodologie étant basée sur une analyse d’ordonnançabilité, nous avons jugé
important de rappeler les études faites sur l’ordonnancement des tâches et des messages.
Ce mémoire présente six chapitres, les quatre premiers rappellent les bases essentielles à
ce travail et synthétisent les travaux existants en matière d’algorithmes
d’ordonnancement et de protocoles adaptés aux communications temps réel ; les deux
derniers décrivent le travail proprement dit:
♦ le troisième chapitre décrit les principaux réseaux locaux temps réel utilisés
comme support de communication pour les applications temps réel
considérées. Il met l’accent sur les protocoles de communication de la couche
MAC car ils correspondent aux stratégies d’ordonnancement des messages,
1
Introduction générale
21
CHAPITRE 1
1. Introduction
Nous proposons, dans ce chapitre, une introduction aux systèmes informatiques temps
réel ainsi qu’une présentation de la terminologie associée.
31
Procédé
Actionneurs Capteurs
Système de
contrôle
• les systèmes temps réel à contraintes relatives, par opposition, tolèrent les
dépassements des échéances,
• les systèmes temps réel à contraintes mixtes qui comprennent des programmes
à contraintes strictes et d’autres à contraintes relatives.
Selon l’équipement contrôlé, les contraintes de temps peuvent être de divers ordres, de
l’ordre:
41
Introduction aux systèmes informatiques temps réel
Procédé
Actionneurs Capteurs
Système de
contrôle
tâches
1 5
2.3. Les tâches
Les tâches peuvent être indépendantes comme elles peuvent coopérer par des
mécanismes de synchronisation (postage/attente d’un événement) ou de communication
de données (par boîte aux lettres ou par rendez-vous). Dans un cas comme dans l’autre,
ces relations se traduisent, d’un point de vue comportemental, par des contraintes de
précédence définissant ainsi un ordre dans l’exécution des tâches impliquées. De plus,
plusieurs tâches peuvent partager une ou plusieurs ressources dont l’accès est exclusif.
Ce qui veut dire que si plusieurs tâches demandent la même ressource critique,
l’exécutif temps réel autorisera l’exécution d’une seule tâche afin d’assurer l’exclusion
mutuelle. Par conséquent, les autres tâches seront bloquées en attente de cette ressource.
En plus de ces contraintes, les tâches doivent respecter des délais critiques imposés par
les dynamiques de l’environnement à contrôler. D’un point de vue temporel, les
paramètres suivants peuvent caractériser une tâche :
• la période : est l’intervalle de temps fixe qui sépare les arrivées successives
d’une tâche. Ce paramètre concerne les tâches activées par un signal
périodique provenant d’une horloge temps réel interne, c’est le cas par
exemple de l’acquisition de données. Ce type de tâches est appelé tâches
périodiques.
Les tâches dont la date de réveil n’est pas connue avant la mise en exploitation du
système sont dites tâches apériodiques. En général, les tâches périodiques assurent le
déroulement normal des fonctions de commande du procédé alors que les tâches
apériodiques traitent les alarmes et les états d’exception.
671
Introduction aux systèmes informatiques temps réel
2.5.1.Préemptif/non Préemptif
• non préemptif: si toute tâche qui commence son exécution doit être achevée
avant qu’une autre tâche obtienne le processeur,
• préemptif: si une tâche peut être interrompue au profit d’une autre et être
reprise ultérieurement.
Les algorithmes non préemptifs sont faciles à mettre en œuvre ; de plus, ils ont un faible
coût puisque les changements de contexte sont minimisés et il n’y a pas lieu de gérer
l’accès concurrent aux ressources critiques. Cependant les algorithmes préemptifs sont
plus efficaces puisqu’ils offrent une exécution parallèle des tâches en ayant plus de
liberté pour choisir une solution d’ordonnancement.
• hors ligne : lorsque toutes les tâches ainsi que leurs caractéristiques
temporelles sont connues avant le démarrage de l’application. La construction
d’une séquence d’exécution des tâches respectant les contraintes temporelles
est possible et l’ordonnanceur se réduit à une entité appelé répartiteur qui ne
fait que lancer les tâches dans l’ordre dicté par la séquence. Il est évident
qu’une telle approche ne peut prendre en compte des tâches dont la date
d’activation n’est pas connue au départ.
1 66
Une classification de ces algorithmes est basée sur le type de la priorité instaurée entre
les tâches, qui peut être fixe ou dynamique. Un algorithme à priorité fixe affecte, à
chaque tâche, une priorité qui reste constante durant l’exécution de cette dernière. Un
algorithme à priorité dynamique recalcule la priorité des tâches durant leur exécution.
3.1. Architecture
L’architecture la plus générale d’un réseau de communication est une architecture à sept
couches basée sur le modèle ISO [ISO 84]. Néanmoins, dans le cadre des réseaux
locaux temps réel, une architecture de communication limitée à trois couches suffit (voir
figure 1.3): la couche physique, la couche liaison de données elle même décomposée en
deux sous-couches LLC et MAC et la couche application. Seules les deux premières
couches sont normalisées.
La couche physique gère les connexions physiques pour la transmission de bits à travers
le médium de communication. La sous-couche LLC fournit les fonctions de liaison de
données, de gestion des erreurs et de contrôle de flux. La sous-couche MAC gère
l’accès au médium à l’aide d’un protocole de communication. La couche application
fournit les services nécessaires à la gestion des tâches et du contrôle.
Dans un réseau local temps réel, un taux de perte de messages est toujours toléré ; de
plus un message qui n'est pas transmis avec succès au bout d’un temps fixe est
considéré comme étant perdu [ MZ 95]. Le but, dans un système de communication
temps réel, n'est pas de minimiser le délai moyen de transmission des messages comme
dans les réseaux classiques mais de maximiser le pourcentage de messages transmis
dans les délais.
Application
Physique
681
Introduction aux systèmes informatiques temps réel
Les tâches périodiques d'un site émettent le plus souvent des messages synchrones
destinés à des tâches distantes périodiques. De plus, elles peuvent émettre des messages
asynchrones. Par contre les messages émis par des tâches apériodiques sont toujours
asynchrones.
• par multiplexage temporel : chaque site dispose d’une tranche de temps dans
un cycle répétitif (exemple, TDMA),
• par compétition : chaque site émet quand il le désire et doit coopérer avec les
autres sites en vue de résoudre les situations de conflit (collision), exemple
CSMA/DCR,
• par consultation : un site particulier autorise le site qui doit émettre (cas de
FIP) ou bien un message particulier appelé jeton parcourt les sites en
autorisant à émettre celui qui le détient à un moment donné.
1 69
4. Cadre du travail
Dans cette étude, nous considérons l’architecture d’un système réparti composé de
plusieurs sites connectés à un réseau local doté d’un protocole de communication qui
garantit un délai d’accès borné. Le système étant dépourvu de mémoire commune, le
seul moyen de communiquer est l’échange de messages. Nous nous intéresserons aux
applications implantées sur ce type de systèmes c’est-à-dire des applications composées
de tâches réparties sur différents sites communiquant par échange de messages, que
nous appellerons applications temps réel réparties. Ces applications sont bâties autour
d’un réseau temps réel à délai d’accès borné. Le réseau est supposé fiable c’est-à-dire
que tout message émis par une tâche d’un site est reçu, sans erreurs, par la tâche d’un
autre site au bout d’un temps fini. De plus, chaque site dispose d’un ordonnanceur local
classique pour les tâches comme ceux connus dans l’environnement monoprocesseur et
d’un protocole de communication pour la gestion d’accès au réseau. La définition des
caractéristiques temporelles des tâches et des messages suppose l’existence d’une
horloge globale, dans le système, qui permet d’avoir un référentiel temporel global.
Autrement dit, lorsque nous traitons des dates sur des sites différents (par exemple,
dates de réveil de tâches distantes), celles-ci sont exprimées par rapport à une horloge
globale. Nous supposons qu’il n’y a pas de dérive d’horloges locales et que l’horloge
globale reste synchronisée avec le temps réel. Les mécanismes permettant de régler le
problème de synchronisation des horloges ne seront pas considérés ici ; aussi le lecteur
intéressé pourra consulter [Mam 97, FM 96, HMT 94, Lam 78, Ray 92].
La conception de telles applications passe inévitablement par la modélisation et la
validation afin de vérifier qu’elles sont conformes aux exigences spécifiées dans le
cahier des charges. En particulier, le respect des contraintes temporelles globales d’une
application temps réel répartie implique le respect, à la fois, des contraintes temporelles
des tâches et de celles des messages échangés entre ces tâches.
Notre objectif étant de valider temporellement une application temps réel composée de
tâches périodiques à contraintes strictes qui échangent des messages périodiques (ou
synchrones) à contraintes strictes, nous avons développé une méthodologie de
validation basée sur l’ordonnancement des tâches et des messages.
6 1
Introduction aux systèmes informatiques temps réel
Une analyse des performances, faite dans les conditions les plus défavorables, nous
donne un certain nombre de résultats concernant les temps de réponse des tâches et des
messages, les taux d’utilisation des processeurs et du médium, etc. Ces résultats nous
permettent de retenir l’algorithme d’ordonnancement local et le réseau qui donnent les
meilleures performances pour une application donnée.
Vu que la méthodologie proposée est basée sur la notion d’ordonnancement des tâches
et sur les techniques de communication pour le transfert des messages, nous parlerons
dans la suite des techniques d’ordonnancement monoprocesseurs (chapitre 2) ensuite
des protocoles de communication de la couche MAC (chapitre 3) avant de détailler le
principe de cette méthodologie au chapitre 5 et de conclure, au chapitre 6, par une
analyse des performances faite à partir de l’outil MOSARTS qui implante l’analyse
proposée.
1 6
Description des sites Description du réseau
Messages échangés
Tâches, Ressources
Description
de l’application Caractéristiques du réseau
-Algorithme d’ordonnancement
-Protocole d’allocation de
Protocole de communication
ressources
Modélisation
-Caractéristiques temporelles
des tâches et des messages
Ordonnancement
-Ordonnancement des tâches par
Analyse des performances site
selon plusieurs critères -Ordonnancement des messages
(validité, temps de réponse ...) sur le médium
621
CHAPITRE 2
1. Introduction
L’objectif de ce chapitre est de présenter les principaux algorithmes d’ordonnancement
des tâches dans un contexte monoprocesseur. Les tâches peuvent interagir pour
communiquer des données ou prendre en compte des événements. Dans un cas comme
dans l’autre, leur exécution parallèle doit être soumise à des règles de synchronisation.
Celles-ci pourront alors se matérialiser par un ordre dans l’exécution des tâches
impliquées, que nous appellerons précédence entre tâches.
La compétition pour l’accès à une ressource critique est un problème classique et est
connu sous le nom d’exclusion mutuelle, pour lequel il existe une variété de solutions
plus ou moins complexes. Dans le domaine du temps réel, il s’agit non seulement de
garantir l’accès exclusif aux ressources critiques (qui est le rôle de l’exécutif temps réel)
mais aussi et surtout de minimiser le temps d’attente pour l’accès à ces ressources. Il
existe des protocoles dits d’allocation de ressources intégrés aux algorithmes
d’ordonnancement et capables de réduire le temps d’attente des tâches bloquées pour
l’obtention de ressources afin que celles-ci ne dépassent pas leurs échéances.
Avant de détailler toutes ces notions, nous présentons d’abord un modèle de tâches qui
nous servira de base dans la suite de ce mémoire.
631
2. Modélisation des tâches
Sur chaque site, les tâches peuvent être périodiques ou apériodiques. Du point de vue
temporel, une tâche périodique Ti est caractérisée par quatre paramètres (voir figure
2.1):
• Pi: la période qui est l'intervalle de temps maximal séparant deux instances
successives de Ti.
La première exécution d’une telle tâche sera demandée à l’instant ri pour une durée
maximale de Ci unités de temps et doit s’achever avant ri+Di. La kième exécution de
cette tâche sera demandée à l’instant ri+(k-1)Pi pour une durée maximale de Ci et doit se
terminer avant ri+Di+(k-1)Pi. Lorsque la période Pi est égale au délai critique Di, la tâche
est dite à échéance sur requête.
Étant réveillée aléatoirement, une tâche apériodique est caractérisée par le triplet (ri, Ci,
Di) où:
Ci : durée d'exécution
ri ri+Pi
Tops horloge
intervalle du processeur
1ère date de d'exécution
début de temps de réponse 2ème date de début
période de période
Di : délai critique
Pi : période
64 1
Ordonnancement des tâches
En général, les tâches peuvent interagir entre elles. Nous distinguons alors trois types
d'interaction:
Un axe gradué est ajouté pour représenter l’allocation du processeur aux tâches.
Lorsqu’aucune tâche n’est élue, l’intervalle est occupé par un zéro (0) ou par le symbole
vide (∅). De plus, un axe gradué associé à chaque ressource est tracé en vue de mettre
en évidence les différents instants d’utilisation des ressources. Les notations que nous
reprenons et qui sont proposées dans [Bab 96] sont les suivantes (voir l’exemple de la
figure 2.2):
651
tâche A
tâche B
Séquence
A A B ∅ A A B ∅ A A ∅ ∅
d'exécution
0 1 2 3 4 5 6 7 8 9 10 11 12
A/ /* A/ /* A/ /*
Occupation de
la ressource A A A
Figure 2.2: Exemple de séquence d’exécution obtenue pour 2 tâches A et B de caractéristiques: rA=0
DA=4 PA=4 CA=2 ; rB=0 DB=3 PB=6 CB=1; priorité(A)>priorité(B); intervalle de validation
[0,PPCM(4,6)]=[0,12]
Fin correspond à l’instant où l’on trouve un contexte d’exécution, pour l’ensemble des
tâches, identique au contexte à l’instant Début:
ou
Si la séquence est valide sur l’intervalle [Début, Fin], alors elle est valide sur un temps
infini [LM 80].
87 1
Ordonnancement des tâches
Pour de tels algorithmes [LL 73], les priorités sont fixes, attribuées une fois pour toutes.
On affecte une priorité à chaque tâche du système que celle-ci gardera pendant toute la
vie de l’application. Les algorithmes à priorité fixe les plus répandus sont les suivants:
♦ L’algorithme Rate Monotonic (RM): la plus grande priorité est associée à la tâche de
plus petite période. Pour les tâches de même période, l’affectation d’une priorité est
faite de manière aléatoire.
861
Cet algorithme est optimal1 parmi les algorithmes à priorité fixe pour des tâches à
échéance sur requête.
Exemple
Soit l’exemple de deux tâches A et B dont les caractéristiques sont données dans le
tableau 2.1. La priorité de A est supérieure à celle de B car la période de A est
inférieure à celle de B.
Si on déroule la séquence d’exécution sur un intervalle de temps égal à [0,
0+PPCM(6,8)=24], on s’aperçoit que la séquence est bien valide, c’est-à-dire que
l’exécution de chaque tâche est réalisée dans le respect de son échéance comme le
montre la figure 2.3.
Condition d’ordonnançabilité
Une configuration de tâches est ordonnançable s’il existe un algorithme
d’ordonnancement capable de produire un ordonnancement de ces tâches respectant
leurs échéances. De nombreuses études [LL 73] ont pour finalité l’établissement de
conditions nécessaires et/ou suffisantes d’ordonnancement de tâches car elles
permettent de vérifier aisément et a priori une telle politique d’ordonnancement.
Avec RM comme algorithme d’ordonnancement et pour une configuration de n tâches
périodiques indépendantes, une condition suffisante d’ordonnançabilité est donnée par
[LL 73].
Tâches ri Ci Di Pi
A 0 2 6 6
B 0 3 5 8
1
un algorithme est optimal à l’intérieur d’une classe d’algorithmes s’il permet d’ordonnancer toute
application ordonnançable par un autre algorithme de la classe considérée.
88 1
Ordonnancement des tâches
tâche A 0 1 2 3 4 5 6 7 8 9 10 11 12
tâche B 0 1 2 3 4 5 6 7 8 9 10 11 12
A A B B B O A A B B B O
Figure 2.3: Séquence valide obtenue avec RM pour la configuration du tableau 2.1
Exemple
Soient trois tâches indépendantes T1, T2 et T3 dont les caractéristiques temporelles
sont données dans le tableau 2.2.
Calculons Ui=Ci/Pi et U i* = i (2 1/ i −1) .
L'ensemble {T1, T2, T3 } est ordonnancé par RM étant donné que le test
d’ordonnançabilité est vérifié, U3 cumulé=0,50<U3*=0,779.
Supposons que T2 nécessite une plus grande durée d'exécution, par exemple C2=61
comme dans le tableau 2.3. La condition d’ordonnançabilité n'étant pas vérifiée,
on ne peut rien conclure quant à l’ordonnançabilité de cette configuration de
tâches car même dans ce cas l'ordonnancement peut être valide (la condition est
suffisante mais pas nécessaire).
Tâches Pi Ci Di Ui Ui Ui*
cumulé
891
Tâches Pi Ci Di Ui Ui Ui*
cumulé
Condition d’ordonnançabilité
DM est optimal pour des tâches périodiques indépendantes. Une condition suffisante
d’ordonnançabilité pour des tâches quelconques est donnée par: CH = ∑ (Ci / Di )<1 .
Dans l’exemple du tableau 2.1, CH est égal à 0,93 c’est-à-dire plus petite que 1.
Ce qui implique que la configuration de tâches est ordonnançable avec DM. Ceci
se vérifie bien dans la figure 2.4.
La connaissance de CH, dans le cadre de tâches indépendantes, permet de
connaître la validité de la séquence. Cette propriété de DM permet aussi de savoir
simplement et rapidement à tout instant si la configuration peut accepter une
surcharge ou non. Un algorithme d’acceptation de tâche en ligne peut être alors
implanté.
tâche A 0 1 2 3 4 5 6 7 8 9 10 11 12
tâche B 0 1 2 3 4 5 6 7 8 9 10 11 12
B B B A A O A A B B B O
Figure 2.4: Séquence valide obtenue avec DM pour la configuration du tableau 2.1
Exemple
8 1
Ordonnancement des tâches
Condition d’ordonnançabilité
Dans le cas de tâches périodiques et apériodiques indépendantes, une condition
suffisante d’ordonnançabilité est la suivante:
∑ C ≤1.
n
Toute configuration de n tâches quelconques est ordonnancée par ED si: i
D
i=1 i
Tâches ri Ci Di di=Di+ri Pi
A 0 2 4 4 6
B 0 3 8 8 8
C 0 1 3 3 4
0 1 2 3 4 5 6 7 8 9 10
tâche A
tâche B 0 1 2 3 4 5 6 7 8 9 10
tâche C 0 1 2 3 4 5 6 7 8 9 10
C A A B C B B A A O
Figure 2.5: Séquence valide obtenue avec ED pour l’exemple du tableau 2.4
8 1
Si les tâches sont périodiques indépendantes et à échéance sur requête, la condition
suivante [LL73] est nécessaire et suffisante pour ED.
i =1 P
i
♦ L’algorithme Least Laxity (LL): il associe la plus forte priorité à la tâche qui possède
le plus petit temps creux dynamique. Le temps creux dynamique est l’intervalle de
temps qui sépare la fin d’exécution d’une tâche de son échéance c’est-à-dire : δi= di(t)-
Ci(t)-t où di(t) est l’échéance de la tâche Ti à l’instant t, Ci(t) son temps d’exécution
restant au même instant.
Exemple
Soit la configuration de tâches présentées dans le tableau 2.5. Initialement (t=0),
δA= 4-2-0=2, δB=8-3-0=5 et δC=4-1-0=3, ce qui donne A plus prioritaire que C qui
est plus prioritaire que B. A t=2, A se termine. Comme δC=4-2-2=0 et δB =8-3-2=3
C s’exécute avant B. A t= 4, C arrive et B continue de s’exécuter car δB=8-2-4=2
et δC=8-1-4=3 (voir figure 2.6).
A t=6 B se termine, A et C sont prêtes à s’exécuter. Comme δA=10-2-6=2 et δC=8-
1-6=1, c’est C qui prend le processeur. Le même principe s’applique à tout instant
où il y a une demande concurrente du processeur.
Il a été démontré que l’algorithme qui engendre le moins de préemptions parmi les
algorithmes présentés ci-dessus est ED [Hen 75]. C’est donc ED qui utilise le mieux le
temps CPU.
Tâche ri Ci Di Pi
s
A 0 2 4 6
B 0 3 8 8
C 0 1 4 4
821 1
Ordonnancement des tâches
0 1 2 3 4 5 6 7 8 9 10
tâche A
0 1 2 3 4 5 6 7 8 9 10
tâche B
tâche C 0 1 2 3 4 5 6 7 8 9 10
A A C B B B C A A C
Figure 2.6: Séquence valide obtenue avec LL pour l’exemple du tableau 2.5
Une première solution consiste à ordonnancer les tâches apériodiques, en second plan,
au sein de la configuration des tâches périodiques. On commence par ordonnancer
l’ensemble des tâches périodiques afin de déduire les temps creux où seront insérées les
tâches apériodiques.
Une autre solution consiste à ordonnancer les tâches apériodiques sur le même plan que
les tâches périodiques. Une tâche périodique appelée serveur est dédiée à
l’ordonnancement des tâches apériodiques.
Les caractéristiques temporelles du serveur sont celles d’une tâche classique:
• rs: la date de réveil,
• Cs: la durée maximale d'exécution réservée à l’exécution des traitements non
périodiques,
• Ps: la période évaluée de sorte à prendre en compte l’ensemble des requêtes non
périodiques,
calculées en fonction des caractéristiques des tâches apériodiques à servir.
Il existe principalement deux types de serveurs [SSL 89] qui diffèrent dans la manière
de prendre en compte les tâches apériodiques.
8311
Processeur utilisé pour d'autres tâches
Processeur utilisé par le serveur, Ci affecté à un processus aléatoire
initialisation de Ci à 0 initialisation de Ci à 2
(au départ, pas car arrivée d'un
d'appel) apériodique
Si, par contre, une requête a été mémorisée, le serveur utilisera son temps d’exécution
Cs à sa prochaine activation pour exécuter le traitement associé. Si le traitement n’est
pas terminé sur une période, il sera poursuivi pendant la (les) période(s) suivante(s). Le
temps de réponse (temps écoulé entre la date de réveil et la date de fin d’exécution) des
tâches apériodiques peut être important surtout si elles surviennent juste après la fin
d’exécution du serveur. Au niveau de l’analyse de l’ordonnançabilité, ce serveur est
considéré comme une tâche périodique.
5.2.3.Autres méthodes
Il existe une méthode dite de la pseudo période qui s’applique avec l’algorithme
d’ordonnancement RM car elle consiste à associer à chaque tâche apériodique une
pseudo-période correspondant à l’intervalle minimal séparant deux arrivées successives
de la tâche associée. Les tâches apériodiques sont donc ordonnancées au même niveau
que les tâches périodiques. L’inconvénient de cette méthode est la difficulté
d’estimation de la pseudo-période.
initialisation de Ci à 2
841 1
Ordonnancement des tâches
Une autre approche utilise une routine de garantie déclenchée, à chaque arrivée d’une
tâche apériodique, qui vérifie si cette tâche peut être exécutée en respectant son
échéance sans toutefois mettre en péril les échéances des tâches périodiques et des
tâches apériodiques préalablement acceptées. Ce principe est utilisé dans le projet
Spring [SR 91].
Si la routine de garantie ne réussit pas à trouver un tel ordonnancement et si
l’environnement est distribué, un ordonnanceur réparti est lancé afin de trouver un site
moins chargé susceptible de garantir cette tâche.
A précède B ⇒
• rB≥rA
• Priorité(A)>Priorité(B)
Lorsque les tâches sont périodiques et de même période, l’algorithme RM leur affecte
des priorités de manière arbitraire. La prise en compte des relations de précédence dans
ce cas se traduit par:
851
ri*=Max{ri, (r*prédécesseur)} pour Tprédécesseur tâche précédant Ti
Exemple
Soit le graphe de précédence des tâches de la figure 2.9 tel que A précède B et C
et D précèdent E. A et B sont de période 5 ; C, D et E sont de période 6. Les
priorités des tâches doivent respecter les règles de précédence et celles de RM
comme dans le tableau 2.6.
L’idée est de modifier les échéances [Bla 76] de manière à affecter à une tâche un délai
critique Di inférieur à ceux de ses successeurs dans le graphe de précédence. On est
alors sûr que les tâches s’exécuteront dans l’ordre souhaité tout en les considérant
comme tâches indépendantes et sans modification de l’ordre de priorité défini par DM.
La modification des contraintes doit permettre d’aboutir à une configuration qui, lors de
l’ordonnancement, vérifiera les relations de précédence ; c’est-à-dire qui imposera aux
tâches, dans le graphe de précédence, de commencer après leurs prédécesseurs. Les
échéances sont alors modifiées de manière à associer à une tâche une échéance di
(di=ri+Di) strictement inférieure à celles de ses successeurs [CSB 90] étant donné que le
calcul de priorité est basé sur cette échéance.
On obtient alors:
2
La valeur la plus grande est associée à la tâche la plus prioritaire
97 1
Ordonnancement des tâches
A C D
B E
Exemple
Soient les caractéristiques temporelles des tâches (voir tableau 2.7) ainsi que
leurs relations de précédence représentées par le graphe de la figure 2.10. La prise
en compte de la précédence nous donne des tâches indépendantes avec les
nouvelles caractéristiques temporelles du tableau 2.8.
Tableau 2.7: Exemples de contraintes temporelles de tâches avant transformation due à la prise en
compte des relations de précédence présentées figure 2.10
Nom ri Ci Di di=ri+Di Pi
Tâche date de temps délai échéance période
départ d’exécution critique
A 0 1 12 12 12
B 0 2 11 11 12
C 0 1 11 11 12
D 0 2 9 9 12
E 0 1 8 8 8
F 5 4 5 10 -
E C
A B
F D
Figure 2.10: Graphe de précédence des tâches présentées dans le tableau 2.7
961
Nom ri* Ci di * Pi
Tâche date de temps période
départ d’exécution échéance
A 0 1 5 12
B 1 2 7 12
C 3 1 11 12
D 3 2 9 12
E 0 1 8 8
F 5 4 10 -
981 1
Ordonnancement des tâches
T1
temps
priorité
décroissante T2
temps
Tn temps
t1 t2 t3 t4 t5 t6 t7
Tn/ T1/ /* /*
Occupation de la Tn Tn Tn Tn Tn T1
ressource
T2, tout comme les autres tâches comprises entre T1 et Tn qui ne partagent pas la
ressource, pourra s'exécuter jusqu'à la fin avant que Tn ne reprenne son exécution
et libère la section critique pour qu'enfin T1 reprenne l'exécution. Nous assistons,
dans ce cas, à une inversion de priorités car T1 a été bloquée par des tâches moins
prioritaires.
Théorème
991
T1
temps
Pr(T2) < Pr(Tn)
priorité
décroissante T2
temps
Tn hérite de Pr(T1)
Tn temps
t1 t2 t3 t4 t5 t6 t7
Tn/ T1/ /* /*
Occupation de la Tn Tn Tn Tn Tn T1
ressource
En d’autres termes, s'il existe m sémaphores sur lesquels la tâche T peut se bloquer alors
T peut être bloquée pendant la durée d’au plus m sections critiques.
2. Sélectionner celles qui possèdent des ressources communes avec T, soit l ce nombre
4. Prendre Max(l,s)* max (durée des sections critiques pour utiliser la ressource ci)
i=1,s
Fin.
Exemple
9 1
Ordonnancement des tâches
Nous noterons les durées de chaque séquence par Cα(cj), Cβ(cj), Cγ(cj) avec
Cα(cj)+Cβ(cj)+Cγ(cj)=Ci. Pour l’exemple de la figure 2.13, les durées de ces
séquences, en particulier les temps d’utilisation des ressources par chaque
tâche, sont données dans le tableau 2.10. Remarquons que A3 est la seule tâche
qui utilise les deux ressources simultanément puisque Cα(c1)= Cα(c2) d’après le
tableau 2.10.
Tâche Ci Di Pi Pri
A1 10 50 60 5
A2 8 150 200 2
A3 10 100 100 3
A4 9 50 60 4
A5 5 200 200 1
Site
A1
A2
A4
A5
A3
Tableau 2.10 : Les durées des sections critiques pour les tâches de la figure 2.13
A1 3 4 3 10 0 0
A2 2 4 2 8 0 0
A3 4 2 4 4 2 4
A4 9 0 0 3 3 3
A5 5 0 0 1 3 1
9 1
Notons que si Cβ(cj)=0 (pas d’utilisation de ressource), alors Cγ(cj)=0.
Calculons la durée maximale de blocage RA3 pour la tâche A3 par exemple dans
le cas du protocole à priorité héritée. Pour cela, appliquons l’algorithme de
calcul de RA3:
⊗ trouvons les tâches moins prioritaires que A3: A2 et A5 puisqu’elles ont une
période plus grande,
Ce protocole (en anglais, Priority Ceiling Protocol) a été proposé pour limiter la durée
maximale de blocage à la durée d’une section critique et pour prévenir l’interblocage.
Pour éviter les blocages, on définit une nouvelle notion: la priorité plafond d'une
ressource, qui est le maximum des priorités des tâches pouvant accéder à la ressource.
Une tâche ne peut entrer en section critique que si sa priorité est strictement supérieure à
la priorité plafond des ressources alors utilisées.
Exemple
Soit une configuration de trois tâches A, B et C qui utilisent les ressources c1, c2
et c3 comme suit :
- la tâche A utilise les ressources c1 et c3
- la tâche B utilise les ressources c1, c2 et c3 et
- la tâche C utilise les ressources c1 et c2.
On suppose que priorité(A) > priorité(B) > priorité(C). Les priorités plafonds
des ressources notées PP sont alors :
PP(c1)= Max priorités (A, B, C) = priorité(A)
PP(c2) = Max priorités (B, C) = priorité(B)
PP(c3) = Max priorités (A, B) = priorité(A).
921 1
Ordonnancement des tâches
T1
temps
Pr(T2) < Pr(Tn)
priorité
décroissante T2
temps
Tn hérite de PP(s)
Tn temps
t1 t2 t3 t4 t5 t6 t7
Tn/ T1/ /* /*
Occupation de la Tn Tn Tn Tn Tn T1
ressource s
PP(s) = Max(Pr(T1), Pr(Tn))= Pr(T1)
3. Considérer uniquement les ressources dont la priorité plafond est ≥ priorité (T),
soit s ce nombre
4. Prendre max (durée des sections critiques pour l’utilisation de la ressource ci)
i=1,s
Fin.
Si T est la tâche la moins prioritaire, alors le temps de blocage est nul car il n’y a pas de
tâche moins prioritaire qui peut la bloquer.
Exemple
Reprenons l’exemple de la figure 2.13 avec les mêmes caractéristiques décrites
dans l’exemple précédent (§6.2.1). En utilisant le protocole à priorités plafond,
calculons RA3 pour la tâche A3:
Pour cela, supposons que les priorités des tâches respectent les règles de
l’algorithme RM et les contraintes de précédence (voir tableau 2.9) et calculons
les priorités plafond des ressources c1 et c2.
PP(c1)=max priorités(A1, A2, A3)=1,
PP(c2)=max priorités(A3, A4, A5)=2,
931
Appliquons l’algorithme de calcul de la durée maximale de blocage:
⊗ considérons parmi ces tâches, celles qui partagent des ressources avec A3: A2
partage c1 et A5 partage c2,
⊗ RA3=max(Cβ(c1), Cβ(c2))=max(4,3)=4
Si l'algorithme d'ordonnancement utilisé est ED, le protocole à priorité plafond est dit
dynamique car la priorité plafond d'une ressource est réévaluée à chaque instant, étant
donné qu'elle dépend des priorités des tâches qui, elles, changent avec le temps.
Les deux protocoles d’allocation de ressources présentés jusqu’à présent se basent sur la
priorité des tâches, ce qui signifie qu’ils s’adaptent mieux aux algorithmes à priorité
fixe tels que RM ou DM. Le protocole présenté dans le paragraphe suivant s’adapte
aussi aux algorithmes à priorité dynamique.
Ce protocole (en anglais, Stack Resource Policy) a été proposé par Baker [Bak 91]. Il
améliore le protocole à priorité plafond en permettant:
94 1
Ordonnancement des tâches
Caractéristiques principales
• aucune tâche ne peut être bloquée en attente de ressources après son début
d’exécution,
• comme pour le PPP, une tâche peut être bloquée (c’est-à-dire son exécution
retardée) par une tâche moins prioritaire pour la durée d’au plus une section
critique,
• la tâche de plus grande priorité parmi les tâches bloquées (c’est-à-dire dont
l’exécution est retardée) sera débloquée dès l’instant où la tâche active aura
libéré toutes ses ressources. Dans le cas où plusieurs tâches sont bloquées c’est
la tâche qui est bloquée le plus longtemps qui sera débloquée,
• Une différence importante entre les techniques du PPP et du PAP est que le
protocole PPP garantit seulement qu’une tâche bloquée une fois ne le sera plus
jamais. Par opposition, le protocole PAP garantit que si une tâche est bloquée,
elle l’est avant de commencer son exécution.
Exemple
Soient 3 tâches T1,T2 et T3 de priorités respectives 1, 2 et 3 confondues avec leurs
niveaux de préemption.
c v = Max({0} ∪ {π(T) / v<µ(T)}) avec v le nombre d’unités de c disponibles et
µ le nombre d’unités qu’une tâche T peut demander. v et µ sont au plus égaux à
−
1. Π = Max( c1)=0 initialement car toutes les ressources sont disponibles.
Le tableau 2.11 donne les priorités plafond des ressources c1 et c2 et les tableaux
2.12 et 2.13 donnent respectivement les caractéristiques des tâches et les durées
d’exécution de ces ressources. L'influence de ce protocole sur l'ordonnancement
−
des tâches est illustrée dans la figure 2.15. Comme le montre cette figure, Π est
initialement égal à 0. T1 demande et obtient la ressource c1 car la priorité de T1 est
− −
supérieure à Π , Π passe alors à la valeur 2. Lorsque T2 arrive, elle ne peut
−
s’exécuter car sa priorité est égale à Π . Au contraire quand T3 se réveille, elle
−
préempte T1 car sa priorité est plus grande que Π . Mais ce n’est que lorsque T3
− −
demande et obtient c2 que Π passe à la valeur 3 car la mise à jour de Π ne se fait
−
qu’à l’obtention ou à la libération d’une ressource. A la libération de c2 par T3, Π
951
−
reprend sa valeur précédente, c’est-à-dire 2. Π ne repassera à 0 que lorsque c1
sera libérée. Le même principe s’applique pour T2 lors de l’acquisition de c1 et de
c2.
T1 0 6 10 10
T2 1 3 11 11
T3 2 3 12 12
T1 0 5 1 6 0 0
T2 1 1 1 2 1 0
T3 3 0 0 1 1 1
Niveau de priorité
3 T3
temps
2 T2
temps
1
T1
temps
0 1 2 3 4 5 6
0 −
Π
T1/ /* T2/ /*
occupation de c1 T1 T1 T1 T1 T1 T1 T1 T1 T2
T3/ /* T2/ /*
occupation de c2 T3 T2
−
: représente la valeur Π du niveau de préemption du système
71 1
Ordonnancement des tâches
7. Conclusion
A travers ce chapitre, nous avons passé en revue les principaux algorithmes
d’ordonnancement connus dans l’environnement monoprocesseur tout en mettant en
évidence les modifications à opérer sur les contraintes temporelles en vue de prendre en
compte les relations de précédence. De plus, des protocoles d’allocation de ressources
ont été présentés afin d’être intégrés aux algorithmes d’ordonnancement et réduire le
temps de blocage d’une tâche demandant une ressource critique déjà occupée.
Dans ce chapitre, nous avons distingué les tâches indépendantes et les tâches
dépendantes. Selon la nature périodique ou apériodiques des tâches indépendantes, nous
avons présenté les méthodes d’ordonnancement appropriées. Dans notre classification
telle qu’elle est présentée dans le tableau 2.14, les tâches sont dépendantes lorsqu’elles
sont liées par des relations de précédence locale ou bien lorsqu’elles partagent des
ressources critiques. Nous avons, d’une part, montré les règles à suivre en vue de
prendre en compte la précédence locale en fonction de l’algorithme d’ordonnancement
considéré et exposé, d’autre part, le principe des différents protocoles d’allocation de
ressources permettant de réduire le temps de blocage généré dans une situation
d’inversion de priorités. L’environnement qui vient d’être décrit avec :
∗ les différents types de tâches,
∗ les méthodes supposées intégrées dans l’exécutif temps réel pour l’ordonnancement
des tâches et la gestion de l’allocation des ressources
n’est rien d’autre que le contexte de tout site qui accueille les tâches de l’application
temps réel répartie. Que cela soit en utilisant la méthode des pseudo-périodes ou la
méthode des serveurs, les tâches apériodiques sont ordonnancées au même niveau que
les tâches périodiques. A un niveau d’abstraction plus élevé, toutes les tâches de
l’application répartie sont considérées comme périodiques.
PAP avec ED
61
CHAPITRE 3
1. Introduction
Le respect des délais de transfert des messages constitue la principale caractéristique qui
permet de distinguer les communications temps réel des autres types de communication.
Aussi, les applications temps réel utilisent-elles des réseaux qui offrent un mode de
communication permettant de garantir une certaine qualité de service au niveau
temporel pour l’échange des messages entre tâches.
Comme dans [Mam 97], La qualité de service se définit grâce à un certain nombre de
paramètres tels que :
• le taux d’erreur maximal : le taux d’erreurs n’est jamais nul même dans un
réseau qualifié de fiable. Néanmoins pour chaque application, il existe un
seuil que le réseau ne doit pas dépasser si l’on veut garantir la qualité de
service requise.
91
Les messages échangés par les tâches sont spécifiés à l’aide des paramètres suivants :
• la criticité : lorsque les messages doivent respecter des délais de transfert, ils
sont dits à contraintes strictes car le non respect de ces délais mène à la
dégradation du système, voire même à la catastrophe. Les messages sont dits
à contraintes relatives lorsque le système tolère leur dépassement de temps en
temps.
1
Les Principaux Protocoles MAC
Nous nous intéresserons uniquement aux messages périodiques à contraintes temps réel
strictes puisque les tâches qui échangent ces messages sont aussi considérées
périodiques à contraintes strictes. Les messages sont sans contrainte de gigue et sont
caractérisés par des délais critiques confondus avec leurs périodes. Le réseau est
supposé fiable avec un taux d’erreurs minimal.
Dans la suite, les termes paquet et trame seront sciemment confondus, il en sera de
même pour les termes station et site. Dans notre terminologie, un message est l’entité
d’information envoyée par une tâche application, qui peut correspondre alors à un
ensemble de trames au niveau de la couche MAC.
1
Accès
Type d'accès
Aléatoire Contrôlé
Type de
Centralisé Distribué contrôle
L’accès à contrôle centralisé suppose l’existence d’un site de contrôle qui distribue un
droit de parole aux sites. C’est le cas par exemple de FIP où un site de contrôle envoie à
chaque site un message l’autorisant à utiliser le médium.
La technique d’accès à contrôle distribué suppose la coopération des sites en vue de
déterminer celui qui a le droit d’utiliser le médium. La technique du jeton circulant est
un exemple de mécanisme de coopération explicite des sites (cas de FDDI) et la
technique du partage du temps global en intervalles de temps alloués aux différents sites
est un exemple de coopération implicite (cas de TDMA).
Dans les techniques d’accès de la couche MAC, l’ordonnancement de messages peut
nécessiter de définir des priorités aux messages ou bien d’imposer, aux sites, un temps
d’accès borné. En tenant compte de cet aspect, nous obtenons les familles de protocoles
de la figure 3.1. Chacune d’elles est illustrée par un exemple de protocole qui sera décrit
en détails dans la suite du chapitre.
21 1
Les Principaux Protocoles MAC
1Mb/s 40m
250Kb/s 270m
125Kb/s 530m
Comme tout réseau local, CAN est composé de trois couches dont seules les couches
physique et liaison de données sont normalisées [ISO 94]. Chaque paquet peut être
transmis périodiquement, sporadiquement ou à la demande.
Un paquet contient au plus 8 octets d'information utile (voir structure du paquet dans
l’annexe 3) et des champs de contrôle dont notamment un identificateur de 11 bits.
L'identificateur est utilisé d'une part pour filtrer les paquets à la réception et d'autre part
pour assigner une priorité au paquet qui sert à contrôler l'accès au bus lorsque plus d'un
site est émetteur. En effet, si un site parmi un ensemble de sites émetteurs émet un bit 0
alors tous les sites verront 0 (dit bit dominant) sur le bus. Inversement, les sites verront
1 uniquement lorsque tous les sites émetteurs transmettront un bit 1 (dit bit récessif). Le
bus se comportant comme un ET logique, seul le paquet de plus grande priorité (ayant
le plus petit identificateur) sera envoyé car les sites qui émettent des bits récessifs se
retirent de la contention lorsqu'ils détectent un bit dominant sur le bus. On dit que CAN
est fondé sur un accès au médium avec priorité et avec résolution de collisions non
destructive.
CAN utilise un mécanisme de bitstuffing, servant à signaler les erreurs aux différents
sites, qui consiste à insérer un bit dit de bourrage de signe contraire à celui de la
séquence de 5 bits identiques après laquelle il est inséré. Parmi les 47 bits composant les
champs de contrôle, 34 bits peuvent contenir des bits de bourrage en plus des 8 octets de
donnée. Le nombre total de bits de bourrage est alors donné, comme dans [TBW 95],
34 + 8n
par la formule suivante : bits de bourrage avec n égal à 8 octets au maximum.
5
Pour un débit de 1Mb/s lorsque la durée de transmission d’une trame comportant 8
octets de données est égale à 130µs, elle correspond à la taille maximale de la trame
(130bits) c’est-à-dire à un nombre maximal de bits de bourrage (19).
Exemple
Soient trois sites S1, S2 et S3 qui ont des messages de priorités respectives 111,
010 et 011 à émettre.
Durant la première tranche de l'intervalle de temps réservé à l'arbitrage de
priorités, chaque site diffuse le bit le plus significatif (1 pour S1, 0 pour S2 et 0
pour S3). Dans la figure 3.2, S1 est éliminé car il envoie 1 et reçoit 0, ce qui veut
dire qu'il y a au moins un site qui veut émettre un message plus prioritaire. Dans
la figure 3.3, durant la deuxième tranche de temps S2 et S3 envoient 1. Le bit lu
sur le bus étant identique à celui qui est émis, aucun des deux ne se retire et le
processus continue avec les bits suivants. La figure 3.4 représente la troisième
tranche de temps durant laquelle S3 est éliminé et S2 gagne l'accès au bus.
311
Autrement dit, le site qui a envoyé tous ses bits et qui, à chaque fois, a lu la
même valeur de bit sur le bus que celle qu’il a émise déduit qu’il est le
vainqueur. La priorité étant propre à chaque message et chaque site n’émettant
qu’un seul message à la fois, le vainqueur est unique.
Notons que les messages qui arrivent durant une phase d'arbitrage de priorités ne seront
considérés que durant la phase suivante.
Remarque
S1 S2 S3
1 0 0 0 0 0
Bus
S1 S2 S3
1 1 1 1 1
Bus
S1 S2 S3
0 0 0 1 0
Bus
41 1
Les Principaux Protocoles MAC
4.2.1.Principe
Le protocole CSMA/DCR (Carrier Sense Multiple Access/ Deterministic Collision
Resolution) reprend le principe de base de la méthode CSMA/CD normalisée [IEEE 85]
et s’utilise sur un réseau composé de sites connectés sur un bus. Pour un débit de
10Mb/s, la durée de transmission d’un paquet Cp vaut 1228µs pour 1518 octets
d’information utile (voir format de la trame dans l’annexe 3).
Utilisant le principe de compétition, chaque site est libre d’émettre à tout moment
pourvu que le bus soit libre. Lorsqu’un site émet un paquet, il écoute le support en
même temps qu’il émet. S’il ne détecte pas de collision durant la transmission, il
conclut que le paquet est émis avec succès, sinon il attend un temps aléatoire avant de
tenter une autre émission. Ce protocole est dit déterministe car il résout le problème de
collisions en autorisant tous les sites à émettre dans un ordre défini grâce à un
découpage dichotomique basé sur les adresses des sites. Ainsi pendant toute la phase de
résolution de conflit, appelée époque, tous les sites vont pouvoir émettre dans un ordre
fixé et avec un délai maximum connu suivant la position de chacun. Le groupe qui
conserve le droit d'émettre est dit "gagnant" et l'autre "perdant". Le tableau 3.2 et la
figure 3.5 illustrent bien cette situation à travers un exemple de 8 sites dont 5 sont
émetteurs.
Dans le tableau 3.2, les sites 0, 1, 3, 6 et 7 émettent des paquets et détectent la collision.
La résolution de conflit étant basée sur une solution dichotomique, les sites 4 à 7 se
retirent. Les sites restants (0 à 3) sont autorisés à émettre. Les sites 0, 1 et 3 émettent et
la collision persiste. Le découpage se poursuit jusqu’à isoler un seul émetteur qui pourra
émettre. Le processus est répété afin de permettre à chacun des sites en conflit
d’envoyer son paquet.
Tableau 3.2 - Délai d'émission du site 6 : cas quelconque
temps 0 1 2 3 4 5 6 7 8 9 10
N° site
0 C C C E 6 6 6 6 6 6 6
1 C C C 6 E 6 6 6 6 6 6
2 6 6 6 6 6 6 6 6
3 C C 6 6 6 E 6 6 6 6 6
4 6 6 6 6 6 V 6 6 6
5 6 6 6 6 6 V 6 6 6
6 C 6 6 6 6 6 C 6 C 6
7 C 6 6 6 6 6 C 6 C E
Les notations sont : C : collision ; E : émission réussie ; V : pas d'émission ; 6 : pas d'autorisation
d'émettre.
51
m0 m1 m3 m6 m7
Temps
collision
émission
tranche canal vide
4.2.2.Calcul de l’époque
Si les n sites du réseau sont émetteurs, l’époque est égale à nCp + (n-1)Tc avec Cp étant la
durée de transmission d'un paquet et Tc la tranche canal. Si seulement x sites (x<n) sont
émetteurs alors l’époque se réduit à l’expression suivante selon [LR94]:
Tc, la tranche canal, est égale à deux fois le temps de propagation, environ 50 µs. Si un
groupe de sites n’a rien à émettre et a été sélectionné lors du découpage dichotomique
alors le médium sera occupé par une phase canal vide (équivalente à une durée de Tc).
71 1
Les Principaux Protocoles MAC
Exemple
Soient les 6 variables périodiques du tableau 3.4 scrutées par l'arbitre de bus [Let
92] où la somme des temps de transfert des variables est égal à 1,35ms.
Dans le cas d’un trafic périodique, l’arbitre de bus envoie des demandes de
transfert ID_DAT pour chaque variable dans le réseau. Le producteur P (voir
figure 3.7) répondra par la diffusion de cette variable, à l’aide de la trame
RP_DAT qui sera lue par les consommateurs C. Lorsque l’arbitre de bus reçoit
RP_DAT, il diffuse une nouvelle trame ID_DAT afin de permettre la mise à
jour d’une nouvelle variable ; et ainsi de suite pour toutes les variables.
61
Tableau 3.4 : Exemple de table de scrutation
A 5 INT_8 154
B 10 INT_16 162
C 15 OSTR_32 402
D 20 SFPOINT 178
E 20 UNS_32 178
F 30 VSTR_16 274
Après scrutation des variables périodiques, l'arbitre de bus traite des demandes de
transfert apériodique. S'il n'y a pas de demande, il émet des identificateurs de bourrage
jusqu'à la fin du cycle élémentaire pour indiquer aux autres sites que le réseau
fonctionne toujours. Un identificateur de bourrage est un identificateur que ne produit
aucun site. Le trafic apériodique et la messagerie ne font pas l’objet de notre étude. Le
lecteur intéressé pourra consulter [Tho 93, SC95].
[Son 96] modélise la couche MAC du réseau FIP à l'aide de TDMA et montre comment
FIP peut gérer, dans ce cas, non seulement des messages périodiques à contraintes
strictes mais aussi des messages apériodiques à contraintes relatives. Ce résultat peut
être intéressant lorsque nous savons que la configuration commercialisée de FIP
supporte uniquement un trafic périodique hors ligne.
macrocycle
A A A A A A A A A A A A A A
B B B B B B B
C C C C C
D D D D
E E E E
F F F
3
Le temps de transfert d'une variable est la somme du temps d'envoi de la requête, du temps de réception de la
réponse et du temps de retournement multiplié par deux
8 1
Les Principaux Protocoles MAC
ID_DAT_A
Arbitre de
Bus A
C P C
C P C
911
A l’obtention du jeton Arrivée tardive du jeton (détectée)
Si TRT = 0 alors
THT :=TRT AT := 1
Si AT = 0 alors TRT := TTRT
TRT := TTRT Finsi
Finsi
émission synchrone
Si AT = 0 et THT > 0 alors
émission asynchrone pendant THT
Finsi
AT := 0
L’exemple de la figure 3.8 suppose que TTRT=100µs et que le site considéré dispose
d’une bande passante synchrone H=25%TTRT=25µs.
Pour un site donné, seul le trafic synchrone (de durée Ηι =αιTTRT) est certain d'être
transmis et le trafic asynchrone (de durée THT) n'est transmis que si le jeton tourne en
moins de TTRT.
Arrivée du jeton
Compteur TRT
100
(TTRT)
75
50
25
0
50 100 150 200 250 300
Valeur de AT
1
0
50 100 150 200 250 300 temps
Compteur THT
25
: trames synchrones
: trames asynchrones
Figure 3.8 - Exemple de fonctionnement d'un réseau FDDI : trames synchrones et asynchrones
Le protocole, tel qu’il est décrit, maintient un temps entre deux visites consécutives d'un
site par le jeton inférieur à 2*TTRT si le trafic asynchrone est prévu et est inférieur à
TTRT si le mode est uniquement synchrone [SJ 87]. [ACZD 92] généralisent ce résultat
1
Les Principaux Protocoles MAC
à v (v≥2) visites consécutives d'un site bornées par v.TTRT, davantage affiné dans [ZB
95].
Garantir les échéances des messages synchrones dépend principalement d'une allocation
appropriée de la bande passante synchrone. Pour cela, plusieurs schémas d'allocation de
la bande passante ont été décrits dans [ACZD 92]:
TTRT − ∂
• allocation de partitions égales: Hi = avec TTRT: paramètre du
n
système, ∂ le délai de propagation et n le nombre total de sites.
Ci
• allocation proportionnelle: Hi = (TTRT − ∂ ) , la bande synchrone est
Pi
proportionnelle au taux de la longueur sur la période.
Ci
• allocation Hi = (TTRT − ∂ )
Pi
proportionnelle normalisée: avec
Us
n
Ci
Us = ∑ on parle de normalisation par rapport au facteur d'utilisation des
i = 1 Pi
messages synchrones.
Ci
• allocation locale : Hi = , le jeton visitera le site i au moins
−1
Pi
TTRT
1
Il existe trois politiques différentes d’allocation:
7. Conclusion
Une classification des différents réseaux à accès multiple a été présentée et pour chaque
classe, un réseau de communication a été décrit. Les caractéristiques principales des
réseaux étudiés sont récapitulées dans le tableau 3.11. Il n’y a pas d’algorithmes
d’adaptation pour la prise en compte des contraintes de temps des messages. Seuls les
protocoles de communication sont utilisés dans la méthodologie proposée au chapitre 5
qui, dans ce cas, doivent fournir un délai borné pour l’accès au médium ; ce qui a
motivé le choix des réseaux à étudier dans ce chapitre.
Le chapitre suivant présente, d’un côté, quelques exécutifs temps réel répartis à travers
leurs configurations matérielle et logicielle afin de montrer le type d’environnement qui
pourrait supporter les applications temps réel réparties que nous avons décrites. D’un
autre côté, il montre ce qui existe en matière d’outils et de méthodes de validation
temporelle d’applications temps réel réparties.
trames réservées
au site 1
1 1 2 3 .... 1 1 2 3 ....
1er cycle 2ème cycle
21 1
Les Principaux Protocoles MAC
123
la notion de priorité n'est pas intégrée on peut définir des priorités statiques possibilité de définir des priorités un mécanisme de priorités est défini
au départ ayant pour conséquence statiques ou dynamiques pour les pour allouer le support de communication
l'allocation de plus de tranches de stations (ex: CSMA/DCR) aux trames prioritaires (IEEE 802.5)
temps aux stations prioritaires
FIP est statique: pas de retrait ni TDMA est statique l'insertion ou le retrait d'un équipement l'ajout et le retrait de stations se fait à
d'insertion dynamiques de stations n'a aucune incidence sur le l'aide de procédures particulières
protocole (mais la détection de panne et la reconfigu-
-ration de l'anneau sont
automatiques dans FDDI)
se prête bien au trafic périodique et se prête bien au transport de petits CSMA/DCR peut fonctionner en FDDI offre un service de transfert
apériodique messages répétitifs mode général (=CSMA/CD en faible synchrone pour le trafic périodique
charge) et en mode périodique et un service de transfert asynchrone
(=TDMA à forte charge). pour le trafic aléatoire
143 3
CHAPITRE 4
1. Introduction
Ce chapitre se compose de deux parties. Dans la première, nous examinons quelques
exemples d’exécutifs temps réel répartis à travers les concepts de base qu'ils mettent en
oeuvre et leurs stratégies d’ordonnancement et de communication. Cette étude a pour
but de déterminer le type d’applications temps réel réparties, en termes d’architectures
matérielle et logicielle, que nous pouvons analyser temporellement à l'aide de notre
méthodologie. Nous présentons donc les trois systèmes les plus connus : MARS,
SPRING et CHORUS.
La deuxième partie est consacrée, quant à elle, aux outils et méthodes de validation
d’applications temps réel réparties. Nous commençons par la description de PERTS qui
est un outil d’aide à la validation d’applications temps réel (réparties ou non), basé sur
une analyse d’ordonnançabilité. PERTS partage la même philosophie que notre
méthodologie de validation. Nous développons ensuite une méthode d’analyse
d’ordonnançabilité d’applications temps réel réparties, qui utilise FDDI comme réseau
de communication.
123
2.1.1.Architecture matérielle de MARS
L’architecture du système est définie par des éléments de base appelés grappes (en
anglais, clusters). Chaque grappe consiste en un ensemble de composants connectés par
un bus de communication temps réel synchrone appelé bus MARS. Un composant n’est
rien d’autre qu’un ordinateur indépendant sur lequel s’exécutent des tâches temps réel et
une copie du noyau temps réel. Le concept de grappe a été introduit afin de gérer les
réseaux complexes de composants (voir figure 4.1).
Une copie du système d’exploitation est installée sur chaque composant et s’exécute
localement de manière autonome. Le système d’exploitation consiste en un petit noyau
et un ensemble de tâches système (voir figure 4.2).
Trois fonctions principales sont réalisées par le noyau:
∗ l’ordonnancement des tâches à contraintes strictes,
∗ le maintien d’une horloge temps réel globale et
∗ la gestion de messages.
• Les tâches temps réel critiques: qui sont des tâches cycliques pouvant recevoir,
traiter et émettre des messages dans des délais stricts. Elles peuvent être des
tâches système ou des tâches application.
• Les tâches temps réel non critiques: qui sont généralement des tâches
acycliques dont l’exécution est effectuée pendant les périodes où le processeur
n’a pas de tâche critique à exécuter.
composant composant
Cluster
Interface inter-cluster
composant
Capteurs/Actionneurs
453 3
Environnements temps réel répartis
messages
horloge
Ordonnanceur CSU: Clock
Noyau Synchronisation Unit
RAM de 25 Ko
Hardware
Bus MARS
Pour la prise en compte des interruptions, seule l’horloge temps réel peut interrompre le
processeur. Périodiquement, la routine de traitement de l’interruption horloge teste l’état
de tous les périphériques afin de prendre en compte les événements sporadiques. Les
événements détectés durant un cycle d’ordonnancement seront traités durant le prochain
cycle de manière à ce que l’ensemble des tâches à ordonnancer soit statique et connu à
l’avance.
D’un point de vue temporel, toute tâche périodique est caractérisée par une période
d’activation, une durée maximale d’exécution et le composant où elle s’exécute. Le
concepteur doit spécifier tous ces attributs lors de la description de l’application.
Une transaction est une séquence de tâches (généralement réparties sur différents
composants) déclenchée suite à un stimulus et qui produit une réponse. La contrainte
temporelle de bout en bout d’une telle transaction s’exprime par son temps de réponse
maximal (Mart) qui comprend :
• le temps de latence séparant le lancement de la première tâche qui réagit à ce
stimulus,
• les durées d’exécution des tâches impliquées,
• les temps de communication entre ces tâches,
• le temps séparant la fin de la dernière tâche de la réponse.
L’ordonnanceur dispose en entrée des durées maximales d’exécution, du nombre
maximal de ressources nécessaires pour chaque tâche, des tâches critiques de chaque
composant (site) et du temps maximal séparant deux activations successives de chaque
transaction. Le résultat est une séquence d’ordonnancement mettant en évidence les
tâches critiques des différents sites avec leurs instants d’activation, les instants de
préemption et les périodes d’activation de chaque tâche. L’ordonnanceur hors ligne est
basé sur une stratégie de parcours en profondeur [Ric 83]. En effet, une fonction
463
heuristique est utilisée pour construire un arbre en recherchant les délais les plus courts
pour les tâches qui font partie d’une même transaction afin de respecter le temps de
réponse maximal de la transaction. Un chemin, dans l’arbre, correspond à une séquence
d’ordonnancement dont le coût n’excède pas Mart. Chaque nœud N de l’arbre
correspond à une tâche vérifiant la fonction f(N)=g(N)+h(N) où g(N) est le coût du
chemin issu de la racine à N et h(N) est une estimation du coût du chemin « le moins
cher » depuis N jusqu’à une solution. h(N) est la fonction heuristique qui doit tenir
compte des durées maximales des tâches, de leurs durées de communication et de la
période d’inactivité du processeur.
Chaque composant comporte une horloge temps réel de résolution 1 µs appelée CSU
(Clock Synchronisation Unit). La synchronisation d’horloge consiste :
• d’une part, en une synchronisation interne qui consiste à garder les horloges de
tous les composants d’une même grappe décalées au maximum d’une constante
connue (10 µs),
• d’autre part, en une synchronisation externe qui ajuste les horloges de la grappe
avec le temps physique.
La synchronisation interne est un recalage d’horloges qui se fait grâce à des messages
estampillés échangés périodiquement.
2.1.3.Conclusion
473 3
Environnements temps réel répartis
• les tâches critiques correspondent à des tâches qui doivent respecter leurs
échéances. Dès la phase de conception, il y a lieu de vérifier que ces tâches
respectent leurs échéances dans une situation de charge maximale car dans le
cas contraire, une catastrophe peut survenir.
• les tâches non essentielles peuvent avoir ou non des contraintes temporelles.
Elles s’exécutent lorsque les tâches critiques et essentielles n’ont plus besoin
du processeur.
483
date d’activation, le compilateur est supposé capable de déterminer la durée maximale
d’exécution et les besoins en ressources pour chaque tâche du groupe.
Les processeurs application exécutent des tâches application de haut niveau qu’il faut
garantir c’est-à-dire dont il faut respecter les échéances.
Le sous-système d’E/S est une partie du noyau qui gère les E/S non critiques et/ ou
lentes et les capteurs rapides.
E/S
Processeur E/S
système
Réseau
49 3
Environnements temps réel répartis
2.2.4.Conclusion
Garantir les contraintes temporelles est le point central de cette approche qui distingue
deux cas:
♦ il n’y a pas de conflit pour l’obtention de ressources. Les tâches qui demandent
la même ressource sont ordonnancées à des instants différents.
413
♦ Le répartiteur (implanté sur le processeur application) et la routine de garantie
(implantée sur le processeur système) s’exécutent en parallèle. Le répartiteur
travaille sur un ensemble de tâches que l’on sait pouvoir garantir alors que la
routine de garantie travaille sur un ensemble composé de l’ensemble courant de
tâches (que l’on est sûr de garantir) et d’une tâche qui vient d’arriver.
♦ Si la routine de garantie conclut que la tâche qui vient d’être invoquée ne peut
être garantie, celle-ci peut recevoir des cycles oisifs au niveau du processeur et
en parallèle être affectée, grâce à l’ordonnanceur distribué, à un autre site
susceptible de la garantir.
Cette approche est très différente de celle de Mars dans le sens où l’ordonnancement est
dynamique ; toutefois l’utilisation d’un réseau CSMA/CD ne permet pas de borner les
délais de transfert ; ce qui est contraignant pour des applications réparties qui
nécessitent des communications temps réel.
Il se présente sous la forme d’un exécutif de petite taille, écrit en C pour faciliter sa
portabilité et enrichi par un ensemble de serveurs système. Chorus est disponible sur des
architectures multiprocesseurs faiblement couplées (hypercube par exemple) et
récemment sur des architectures fortement couplées (à architecture symétrique).
2.3.1.1. L’acteur
L’acteur (actor) est un processus Unix sans la partie exécution qui, elle, se trouve dans
les sous-processus (processus légers). Il existe deux types d’acteurs: les acteurs
utilisateurs et les acteurs superviseurs. Chaque acteur utilisateur a son propre espace
44 3
Environnements temps réel répartis
2.3.1.2. L’activité
L’activité (thread) est l’unité d’exécution ou processus léger séquentiel. Une activité est
attachée à un acteur qui définit son environnement d’exécution. Les activités d’un
même acteur peuvent partager l’environnement offert par ce dernier, c’est-à-dire le
même espace d’adressage et les mêmes ressources, leur permettant ainsi de se
synchroniser (à l’aide de sémaphores) et de communiquer entre elles.
2.3.1.3. La Porte
Site 1 Site 2
IPC
local
activités IPC intersite
port
Réseau d'interconnexion
L’ordonnanceur associe à chaque activité une priorité fixe qui est un entier compris
entre 0 et 255. Si sa priorité est inférieure à 127, l’activité est considérée comme un
processus temps réel ; si elle est supérieure, c’est un processus non temps réel et donc
sans contrainte temporelle. L’ordonnanceur assure qu’à tout moment la tâche prête
activée sur un processeur est celle de priorité la plus petite.
4 3
Le traitement des demandes d’interruption est réalisé par des gestionnaires
d’interruption qui s’exécutent comme des tâches superviseur. Comme plusieurs
événements peuvent être associés à un même niveau d’interruption, plusieurs
gestionnaires sont rattachés à cette interruption, chacun correspondant à une priorité.
Ainsi, l’ordonnanceur est fondé sur l’emploi de priorités fixes attribuées en général de
manière empirique et ne tient pas compte de l’urgence d’une tâche qui est fonction du
délai critique. Des travaux ont été entrepris sur CHORUS par [KS 98] en vue
d’introduire un nouvel ordonnanceur du type Earliest Deadline et d’un mécanisme de
stabilisation appelé régisseur tel qu’il a été décrit par J. Delacroix dans [Del 94].
L’ordonnanceur à échéance ordonnance les tâches de façon à ce que la tâche élue soit
celle de plus proche échéance parmi l’ensemble des tâches prêtes.
Le régisseur est une unité de contrôle locale au site, qui ne s’exécute que lorsque le
système est surchargé. Il intervient pour privilégier les tâches de plus haute importance
vis à vis de l’application. Un algorithme réparti a été développé sur CHORUS par [KS
98] appelé gestionnaire d’importance réparti (voir figure 4.5) en vue de dialoguer avec
les autres sites et de déterminer le site qui se surcharge le moins en acceptant
l’exécution d’une tâche qui ne peut être acceptée localement.
Site1 Site2
Site3
Gestionnaire d'importance
Gestionnaire d'importance Gestionnaire d'importance
réparti
réparti réparti
désigne un port de
communication
4 3 3
Environnements temps réel répartis
3.1.1.Éditeur de tâches
3.1.2.Éditeur de ressources
423
Figure 4.6: Un exemple de configuration de tâches
3.1.3.L’ordonnanceur
L’utilisateur n’a pas la possibilité de définir le réseau qu’il veut utiliser. Il n’a pas
connaissance du réseau utilisé par défaut car aucune information n’est précisée. L’outil
calcule le taux d’utilisation du réseau qui constitue la seule information fournie.
Il est possible de définir une transaction en choisissant, sur le graphe de précédence des
tâches, une tâche initiale et une tâche finale appartenant au même chemin. Le taux
d’utilisation de toutes les tâches impliquées dans ce chemin est calculé et affiché.
53 3
Environnements temps réel répartis
63
3.2. Une méthode de validation d’applications temps
réel réparties
Dans la méthode proposée par [KLR 94, SRS 94], un système réparti est défini comme
un ensemble de stations reliées par un médium de communication via lequel les tâches
qui résident sur les stations s’échangent des messages. L’ensemble des stations et du
médium de communication est vu comme un ensemble de sous-systèmes. Afin d'étudier
l'ordonnançabilité des tâches dans un environnement réparti, la notion de délai critique
de bout en bout est définie. Elle est égale à la somme des délais critiques des sous-
systèmes constituant le système réparti. Le principe se base sur le fait que : si chaque
sous-système est ordonnançable en appliquant les techniques connues dans
l’environnement monoprocesseur, alors le délai critique de bout en bout est aussi
respecté. Dans ce cas, le système est dit valide du point de vue temporel.
3.2.1.Hypothèses générales
− chaque site utilise RM comme algorithme d’ordonnancement local des tâches,
− le protocole à priorité plafond est intégré à RM afin de minimiser le temps de
blocage dû au partage de ressources locales critiques,
− les tâches Ti sont caractérisées par les paramètres temporels classiques (ri, Ci,
Di, Pi) décrits au chapitre 2,
− la prise en compte de la précédence locale entre tâches est faite en scindant
toutes les tâches de même priorité (c’est-à-dire de même période) en une
seule,
− les tâches sont périodiques et échangent des messages périodiques. Les tâches
apériodiques sont traitées par des serveurs périodiques.
7 3
Environnements temps réel répartis
Tâches Pi Ci Di
A1 40 6 40
A2 50 20 50
A3 100 20 100
A4 200 30 100
A5 400 24 400
A2 de N1 lit des données à partir d’un capteur pendant 50ms et transmet un Mégatbit de
données chaque 50ms, qui sont traitées par N4 pendant 200ms pat la tâche B2. De même,
les tâches B1 et B3 traitent chacune un Mégabit de données reçues respectivement des
tâches A2 de N2 et de N3.
Contrainte de temps
Le délai critique de bout en bout égal à l’intervalle de temps qui sépare l’instant de
lecture, par A2, de la donnée à partir du capteur de la station N1 de l’instant de son
affichage sur la station N4 est de 0,5s.
A1 A1
capteur A2 A2 capteur
A3 A3
A4 A4
A5 A5
FDDI
A1
B1 A2
B2 A3
B3 A4
A5 capteur
83
3.2.3.Description du réseau utilisé
Le réseau local utilisé est le réseau FDDI de débit 100Mb/s qui utilise le protocole à
jeton comme méthode d'accès. Les stations sont connectées autour d'un anneau. Une
station est autorisée à émettre lorsqu'elle obtient le jeton. Le temps que met un jeton
pour parcourir un anneau inactif (aucune station n'émet) est appelé Walk Time (WT). Le
temps maximal que peut mettre le jeton pour faire un tour de l'anneau est un paramètre
du réseau donné par TTRT (Target Token Rotation Time).
Chaque station émet uniquement en synchrone pour un temps maximal autorisé appelé
capacité synchrone à chaque fois que le jeton est obtenu. La capacité synchrone de
chaque station est un pourcentage de (TTRT-WT). Dans un mode synchrone, le
protocole maintient un temps entre deux visites consécutives d'une station par le jeton,
inférieur à TTRT.
Chaque station Ni peut émettre, une fois, chaque TTRT pour une capacité synchrone de
Ui
Hi = ( TTRT − WT ) avec :
U
Ui: la bande pasante effectivement utilisée par Ni et
U= U1 + ...+ Un s'il existe n stations dans le réseau ayant utilisé effectivement des
bandes passantes
(TTRT- WT) : la bande passante totale pour un tour complet de l’anneau.
Données numériques
WT= 1ms, TTRT = 8ms, débit= 100Mb/s
A chacune des stations N1, N2 et N3 est alloué 30% du temps (TTRT- WT), par contre
10% seulement sont alloués à N4.
3.2.4.Analyse temporelle
Afin d’illustrer le principe de cette analyse, on s'intéressera uniquement à la tâche A2 de
N1. Le principe est le même pour les tâches A2 des stations N2 et N3.
Les données lues à partir du capteur de N1 doivent être affichées au bout de 0,5 s (délai
critique de bout en bout). Ces données utilisent trois sous-systèmes: CPU(N1), réseau
FDDI et CPU(N4). Le principe consiste à associer un délai critique D à chaque sous-
système: si la somme des délais critiques des sous-systèmes est inférieure au délai
critique de bout en bout, les contraintes temporelles du système réparti sont respectées
donc il est ordonnançable.
93 3
Environnements temps réel répartis
Le temps non disponible pour N1 sera traité comme le temps réservé à une autre tâche
réseau ϕ2 dont la durée d’exécution C est de 5,9ms et la période P de 8ms.
Les tâches du réseau sont donc :
- ϕ1: C1=5,9 et P1=8 de grande priorité selon l’algorithme RM
- ϕ2: C2 = 10 et P2=50 de faible priorité selon l’algorithme RM
A l’aide du test d’acceptation qui normalement s’utilise dans l’environnement
monoprocesseur, on montre que ces tâches sont ordonnançables sur le réseau.
- A2 de période 50, chargée de capturer les données sur N1, est ordonnançable sur N1
- ϕ2 de période 50, chargée de transférer les données de N1, est ordonnançable sur le
réseau
- B2 de période 100, chargée de traiter les données reçues, est ordonnançable sur N4
Le temps de réponse total est de 300ms (50+50+100), il est inférieur à 500ms qui est le
délai d'affichage (ou encore le délai critique de bout en bout). La contrainte de temps
spécifiée dans le cahier des charges de l’application est bien respectée.
3.2.5.Conclusion
Nous venons de voir, à travers cet exemple, que la technique d'ordonnancement
monoprocesseur RM associée au test d’acceptation comme condition d’ordonnançabilité
peut s’appliquer au réseau. L’idée de partitionner le système en sous-systèmes
indépendants est intéressante car l’étude de l'ordonnancement des tâches est faite alors
de manière séparée. Néanmoins, cette méthode ne tient pas compte de la technique
d’ordonnancement des messages dans le réseau et elle ne peut pas s’appliquer, a priori,
à un algorithme d’ordonnancement à priorité dynamique (ED par exemple). De plus, le
traitement du trafic de messages comme des tâches à ordonnancer sur le réseau en
déduisant leurs périodes à partir du paramètre TTRT est un raisonnement étroitement lié
au comportement du réseau FDDI, qui ne peut s’appliquer à d’autres réseaux
notamment ceux qui sont basés sur le principe de compétition comme CAN et
CSMA/DCR.
133
4. Conclusion
Dans ce chapitre, nous avons décrit trois systèmes d’exploitation répartis d’une part, et
d’autre part, un outil et une méthode qui permettent d’étudier l’ordonnançabilité d’une
application temps réel répartie.
Le premier système (MARS) a été choisi pour son déterminisme total : toutes les tâches
à exécuter doivent être connues au préalable pour construire un ordonnancement valide
et elles utilisent un réseau déterministe pour leurs communications, les tranches de
temps allouées aux différents sites étant connues à l’avance.
Quant à la méthode de validation présentée et proposée par [KLR 94, SRS 94], elle est
très limitée vu qu’elle s’applique uniquement à l’agorithme d’ordonnancement RM et
au réseau FDDI.
43 3
Environnements temps réel répartis
3
CHAPITRE 5
1. Introduction
Nous définissons une application temps réel répartie comme un ensemble de tâches
réparties sur différents sites connectés à un réseau local où le seul moyen de
communication est l’échange de messages. Elle est dite à contraintes strictes lorsque les
tâches et les messages doivent respecter leurs échéances respectivement lors de leur
exécution et leur transfert.
23
3. Ordonnancement des tâches et des messages : les tâches et les messages dont
les caractéristiques temporelles sont obtenues à l’étape 2 sont ordonnancés
respectivement sur chaque site et sur le réseau. Un diagramme de Gantt est
tracé pour chaque site et pour le réseau et montre la séquence
d’ordonnancement obtenue dans la situation dite du pire cas. Il reste alors à
vérifier, dans ce cas, si chaque tâche et chaque message respecte bien son
échéance afin de déduire la validité de l’application et d’analyser ses
performances à travers des critères mesurés.
Après avoir énoncé les hypothèses générales de travail, les différentes étapes citées ci-
dessus sont détaillées dans la suite de ce chapitre.
2. Le modèle général
• l'existence d'une horloge globale, dans le système, qui sert à définir les
paramètres temporels des tâches et des messages par rapport à un même
référentiel temporel,
• l’existence d'un réseau fiable c'est-à-dire que les messages sont transmis, sans
erreurs, au bout d’un temps fini. Toutefois nous pouvons considérer le cas
d'erreurs dans le cas où nous savons borner le temps nécessaire à la détection et
à la guérison de ces erreurs de manière à inclure ce temps dans la durée
maximale de communication,
• que seuls les protocoles de communication à délai d’accès borné sont utilisés
car ils fournissent un délai de transmission connu et borné pour les messages,
5 3
Méthodologie de Validation
• que les tâches sont placées sur les différents sites de manière statique et
qu’aucune migration de tâche n’est permise,
• que chaque site dispose d’un exécutif temps réel, en plus des tâches
application, en particulier d’un ordonnanceur local de tâches et intègre les
fonctions de gestion du réseau,
• qu’il n’y a pas de dérive d’horloges et que l’horloge globale reste toujours
synchronisée avec le temps réel ; par conséquent il n’y a pas de messages de
synchronisation d’horloge,
• Pi: la période qui est l'intervalle de temps maximal séparant deux instances
successives de Ti.
Au niveau de chaque site, les tâches peuvent être liées par une relation de précédence
que l’on qualifiera de locale et partager des ressources critiques. De plus, une relation
de précédence dite globale est définie entre toute paire de tâches distantes dont l’une est
émettrice de message et l’autre en est réceptrice.
63
Les algorithmes d’ordonnancement utilisés sont ceux présentés dans le chapitre 2. Afin
de réduire le temps de blocage en attente de ressources, les protocoles d’allocation de
ressources leur sont associés.
Dans toute la suite, nous parlerons de messages pour désigner les entités d’information
échangées par les tâches application. Ces messages seront décomposés en un ensemble
d’entités plus petites appelées paquets ou trames correspondant aux unités
d’information manipulées par la couche MAC.
Nous supposons ici que seuls les messages synchrones sont utilisés pour la
communication entre tâches périodiques.
Tâches périodiques
Tâches apériodiques
Site i
Messages Messages
Synchrones Asynchrones
Médium de communication
Site j
Figure 5.1: Nature des tâches et messages d'une application temps réel répartie
7 3
Méthodologie de Validation
Le délai de transmission Dm
• Dm: le délai de transmission qui sépare le moment où le message est prêt à être
émis de l'instant de réception de ce message par le site destinataire. Il
correspond au temps de propagation additionné au temps d'attente dans la file
de transmission.
Dans la suite, le nombre de messages émis par une tâche et les destinations des
messages sont supposés connus. Chaque message possède une taille fixe et un délai
critique confondu avec sa période. On associe à chaque message un tampon à une case
pour son émission et un autre pour sa réception. De plus, afin de minimiser la gigue, les
durées g1 et g2 définies dans la figure 5.2 sont supposées nulles.
3. Principe de la méthodologie
Le principe consiste à déterminer les paramètres temporels caractérisant une application
temps réel en vue d'étudier l'ordonnançabilité des tâches et des messages la constituant.
• les tâches et les messages sont définis avec quatre paramètres temporels,
83
dépend étroitement du contexte local d’un site (type d’algorithme d’ordonnancement et
le protocole d'allocation de ressources) et du réseau. Une fois les caractéristiques
temporelles complètement déterminées, nous procédons à l’ordonnancement des tâches
et des messages en vue de vérifier le respect des contraintes temporelles.
Les caractéristiques des tâches que nous considérons, à ce niveau, sont supposées être
celles obtenues après prise en compte des relations de précédence locale (voir chapitre
2).
∗ Cm le temps de propagation de m,
Le but est de calculer les caractéristiques temporelles des messages en supposant que
celles des tâches sont connues au départ c’est-à-dire définies par l’utilisateur ou
déterminées automatiquement à l’aide d’un outil d’évaluation des paramètres.
Comme la période Pm est connue puisqu’elle est égale à celle de la tâche émettrice, il
reste à déterminer les paramètres Cm, Dm et rm. Cm et Dm sont deux paramètres qui
dépendent étroitement du réseau utilisé et de la taille du message. En effet, Cm est le
temps de transmission des paquets constituant le message m et Dm est le délai de
communication entre la tâche émettrice qui insère un message dans la file de
transmission et la tâche réceptrice capable de consommer le message.
9 3
Méthodologie de Validation
Comme les messages dans CAN sont confondus avec les trames de la couche MAC
alors le temps de propagation d’un message est celui du paquet. Autrement dit, un
message CAN ne peut pas transporter plus que 8 octets de données.
34 + 8n
Cm = 47+n*8+ )/De (n≤8)
5
Pour les réseaux FDDI, CSMA/DCR et TDMA, un message émis par une tâche de
l’application peut avoir une taille qui excède le nombre maximal d’octets pouvant être
transporté par une trame. Un découpage en paquets est donc inévitable, il sera fait au
niveau de la couche application avec insertion des paquets dans la file de transmission
dans l’ordre FIFO. Si un message m est constitué de p paquets, la taille d’un paquet
variant d’un réseau à un autre, la transmission de m nécessite p fois Cpi où Cpi correspond
à la durée de transmission d’un paquet i:
p
Cm= ∑ Cpi
i =1
Si le réseau est CSMA/DCR de débit De, le paquet se compose de 144 bits (18 octets)
de contrôle et de 1518 octets d’information utile au maximum (voir trame dans l’annexe
3). 144 est le nombre de bits de contrôle obtenu en supposant que la taille du champ
d’adresse d’une station émettrice ou réceptrice est égale à 2 octets.
Cp = (n*8+144)/De (n≤1518)
Si le réseau est FDDI de débit De, le paquet contient 168 bits (21 octets) de contrôle et
4490 octets d’information utile au maximum (voir trame dans l’annexe 3). 168 est le
13
nombre de bits de contrôle obtenu en supposant que la taille du champ d’adresse d’une
station émettrice ou réceptrice est égale à 2 octets.
Cp = (n*8+168)/De (n≤4490)
Si le réseau est TDMA de débit De, le paquet contient 28 bits de contrôle et 8 octets
d’information utile au maximum (voir trame dans l’annexe 3).
Cp = (n*8+28)/De (n≤8)
Exemple
Une tâche qui veut envoyer 20 octets de données par exemple, devra émettre :
− Un message m dans FIP ne doit pas excéder une taille de 128 octets. Par
conséquent, la quantité de données 20 octets peut correspondre à un seul
message : Cm = 286µs si De=1Mb/s et tr=10µs
− Un seul message est émis par la tâche lorsque les réseaux utilisés sont
FDDI, TDMA et CSMA/DCR quelle que soit la taille du message car, dans ce
cas, la fragmentation du message est possible et le message correspondra à
plusieurs trames au niveau de la couche MAC.
Comme cela est expliqué dans [MZ 95], Dm doit être au moins égal au temps d'attente
dans la file de transmission rajouté au temps de propagation du message via le médium
de communication (voir figure 5.2). Afin de calculer ce délai, nous considérons la
situation la plus défavorable qui suppose une charge maximale du réseau pour inclure
un temps d'attente maximal avec une possibilité de contention. Les protocoles de
communication présentés dans le chapitre 3 serviront d'illustration de ce calcul.
43 3
Méthodologie de Validation
Exemple
Soit l’exemple d’application de la figure 5.3, qui sera traité tout au long de ce
chapitre:
Les caractéristiques temporelles des tâches sont données dans le tableau 5.1.
Concernant les messages, seules les tailles en nombre d’octets sont connues.
Elles correspondent aux valeurs parenthésées accompagnant les messages dans
la figure 5.3. Toutes les valeurs du tableau 5.1 sont exprimées en ms. Les
périodes sont affectées aux tâches de manière à ce qu’elles soient les mêmes
pour les tâches liées par une relation de précédence locale ou globale.
Site1
Site3
A1
A2
C2
A4
m2(5) C3
A5
A3
C1
m3(8)
m1(5)
B2
Site2 B1
B3
3
Site1 A1 10 50 60
A2 8 150 200
A3 10 100 100
A4 9 50 60
A5 5 200 200
Site2 B1 5 50 50
B2 5 80 100
B3 2 100 100
Site3 C1 6 50 50
C2 5 80 100
C3 5 80 100
m3 m1 m1
Pm1
Cas 2: si l’on s’intéresse à m1, on s’aperçoit qu’une seule occurrence (= ) du
Pm3
message m3 est émis avant l’émission de m1.
m1 m3
Maintenant que nous avons montré comment constituer les s paquets d’une file de
transmission précédant les p paquets d’un message m à insérer, on peut calculer le délai
maximal de transmission du message m. Ce calcul varie d’un réseau de communication
à un autre.
3
Méthodologie de Validation
Remarquons que dans ce cas, l’ordonnancement des variables se base sur une priorité
inversement proportionnelle à la période comme pour l’ordonnancement RM. En effet,
comme expliqué dans [Son 96], l'ordonnancement des variables périodiques se fait hors
ligne selon un algorithme RM non préemptif.
Exemple
Construisons la table de scrutation de l’arbitre de bus (voir tableau 5.2) pour
l’exemple d’application de la figure 5.3. Les variables sont m1, m2 et m3 de
périodes respectives, héritées des tâches émettrices, 50, 100 et 100.
Les temps de transfert des variables correspondent, dans notre cas, aux temps
de propagation Cm. L’arbitre de bus provoquera l’émission des variables dans
l’ordre dicté par la table de scrutation (ordre croissant des périodes) c’est-à-dire
m1 ensuite m2 et enfin m3. Le délai de transmission de m1 sera alors confondu
avec Cm1 c’est-à-dire Dm1=Cm1=166µs, celui de m2 sera égal à
Dm2=Cm2+Cm1=166+166=332µs et enfin celui de m3 correspondra à
Dm3=Cm2+Cm1+Cm3=166+166+190=522µs.
Soit la file de transmission, de la figure 5.4, qui contient les p paquets du message m
précédés par s paquets et construite comme décrit précédemment. Posons Cpmax le temps
de propagation d’un paquet de taille maximale. Il est égal à la durée de transmission de
1518 octets dans CSMA/DCR, à celle de l’émission de 4490 octets dans FDDI ou à la
durée de transfert de 8 octets dans TDMA.
Cas favorable:
p paquets s paquets
m1 (5) 50 166
23
m2(5) 100 166
Cas défavorable:
Dans le cas défavorable, l’émission des (p+s) paquets se fait dans une situation de
collision permanente, c’est-à-dire que chaque paquet émis est en conflit avec d’autres
s+ p n −1
sur le réseau. Dans ce cas, Dm= C p max + ∑ (C pi + ∑ C pj + (n − 1)Tc ) où n est le nombre total
i =1 j =1
Notons que la situation la plus fréquente est celle qui suppose que x sites (x<n) au
maximum veulent émettre. Dans ce cas, la durée de résolution des conflits (époque) se
réduit à l’émission de x paquets. Si θ xn =min{n-1, x+[xLog(n/x)]} ([y] est la partie
entière de y) [LR94], Dm s’exprime comme suit :
s+ p x −1
Dm= C p max + ∑ (C pi + ∑ C pj + θ nx Tc )
i =1 j =1
Exemple
m2 est le seul message susceptible d’être émis par le site 1. Il peut rentrer en
conflit pour l’utilisation du médium de communication avec m1 ou m3 du site 3.
Message Cm=p*Cp Dm
m1 50,4µs 1,629 ms
25 3
Méthodologie de Validation
m2 50,4µs 1,428 ms
m3 50,4µs 1,830 ms
m1 m3
m3, par contre, ne sera émis qu’après avoir émis deux fois m1. De plus, m3 et m1
peuvent être en conflit avec m2. Ce qui donne:
Dm3= 2(Cm1+ Cm2+ θ23Tc)+ (Cm3+ Cm2+ θ23Tc)+Cpmax= 1,830µs
Comme les messages ont des priorités distinctes, le message le plus prioritaire du
système est unique ; de plus, tout message n’attend que l’émission des messages plus
prioritaires dans le réseau. A partir des files de transmission locales des sites, le
protocole CAN en choisissant toujours le message le plus prioritaire dans le réseau pour
l’émettre, construit implicitement une file de transmission globale contenant tous les
messages triés selon leurs priorités. On peut donc raisonner par rapport à cette file
globale.
Dm=Cm+Cpmax
Cpmax, comptabilisé dans Dm, correspond à une occupation du réseau par un paquet émis
juste avant que le paquet le plus prioritaire ne soit envoyé. Il correspond à un temps
maximal.
Par contre, si le message est moins prioritaire, il doit attendre la transmission des
messages x plus prioritaires dans le système: Dm= Cm + C p max + ∑ Cx .
x
Comme les périodes des messages sont quelconques, un message prioritaire x de
période Px peut être envoyé plus d'une fois avant l'émission du message m de période Pm.
263
Pm
Dm= Cm + C p max + ∑ ( ) × Cx
x Px
Exemple
Message Cm=p*Cp Dm
m1 101µs 231µs
m2 101µs 433 µs
m3 130µs 563 µs
Cette formule exprime le fait que le délai de transmission correspond au temps d'attente
du jeton, plus le temps de transmission durant la bande passante allouée ainsi que le
temps nécessaire pour atteindre la destination la plus éloignée. Cette destination est
celle qui nécessite le parcours de (n-1) sites à partir de la source. Remarquons que le
27 3
Méthodologie de Validation
s+ p
∑ C pi
Dm = k.TTRT+(n-1)Cpmax avec k = i =1
S × TTRT
[ACZD 92] montrent que le jeton prend k.TTRT-S.TTRT≤k.TTRT pour faire k visites
consécutives (k≥2) du même site.
Exemple
Dans le site 3, m1 peut être précédé par une seule occurrence de m3 dans la file.
s+ p
D’où ∑ C pi = Cm1+Cm3 =4,4µs < S.TTRT ; Dm1 =3,36ms. Par contre, m3 peut être
i =1
précédé par deux occurrences de m1, donc par deux paquets.
s+ p
Dans ce cas, s=2 et p=1; ∑ C pi = 2Cm1+Cm3 =6,48µs qui est plus petit que la
i =1
bande passante allouée (S*TTRT=1ms).
Dm1=Dm2=Dm3=3,36ms.
Message Cm=p*Cp Dm
m1 2,08µs 3,36ms
283
m2 2,08µs 3,36ms
m3 2,32µs 3,36ms
Cas 2
Exemple
Supposons que l’application de la figure 5.3 utilise un réseau TDMA de débit
1Mb/s, d’un cycle de 16 tranches de temps. Le site 1 dispose, par exemple,
d’un nombre de tranches de temps q1 égal à 2, le site 2 de q2 égal à 3 tranches
de temps et le site 3 de q3 égal à 2 tranches de temps. (voir tableau 5.6).
Sur le site 1, seul m2 est émis c’est-à-dire p=1 et s=0. Comme Cm2 est égal à
68µs, il n’excède la durée maximale d’un paquet. Dm2=1 cycle=16 tranches de
temps.
Sur le site 3, m1 peut être précédé par une seule occurrence de m3 ; nous avons :
s=1 et p=1 ; 2≤ q3 ; Dm1= Dm2=1 cycle=16 tranches de temps.
m3, par contre, peut être précédé par deux occurrences de m1, d’où :
s + p
s=2 et p=1 ; 3>q3 ; soit k= =2, Dm3=2 cycles=32 tranches de temps.
qi
Message Cm=p*Cp Dm
29 3
Méthodologie de Validation
Une meilleure assignation des tranches de temps pourra réduire les délais de
transmission.
3.1.2.6. Conclusion
Dans notre méthode d’analyse, nous avons supposé que les périodes des tâches
émettrice et réceptrice sont identiques. Néanmoins, remarquons que la période de la
tâche réceptrice peut être un multiple de celle de la tâche émettrice. Dans ce cas, les
messages émis ne sont pas tous consommés. En effet, si Pr=k*Pe alors une seule
occurrence du message est consommée toutes les k émissions. Le choix de la valeur de
la période pour la tâche réceptrice sera alors motivé par le type d’applications à traiter
car selon la pertinence du message échangé, véhiculant une information, ceci peut
s’avérer suffisant ou dangereux (perte d’information).
Au contraire si la période de la tâche réceptrice est plus petite que celle de la tâche
émettrice, la tâche réceptrice risque de consommer le même message plusieurs fois
avant qu’une nouvelle instance de ce dernier ne soit arrivée.
Selon les hypothèses relatives aux tâches, les messages sont générés en fin d’exécution
des tâches émettrices. Le problème clé est de trouver cet instant puisqu’il correspond à
rm. La fin d’exécution de la tâche émettrice E est re+Ce+Be=rm, Be est un facteur qui
comptabilise tous les retards dus à l'interaction de E avec son contexte local. Il inclut
deux types de retard:
2133
3.1.3.1. Le facteur de blocage dans le cas d’un ordonnancement local à priorité fixe
Calcul de He
• Dans RM, les tâches les plus prioritaires que E sont celles de périodes plus
petites c’est-à-dire toutes les tâches Tx tel que Px<Pe et toutes les tâches Ty de
même période que E mais de plus grande priorité affectée.
De
He = ∑P × Cx + ∑ C ∀ T : P <P ∀ T : P =P et priorité(T )>priorité(E) [TH
y
x x e y y e y
x x y
95]
• Dans DM, les tâches plus prioritaires que E sont celles de délais critiques plus
petits:
D
H e = ∑ e × Cx ∀ Tx : Dx<De.
x Px
Nous passons au calcul du terme Re qui désigne le temps d’attente, par une tâche, d’une
ou de plusieurs ressources critiques partagées avec d’autres tâches sur le même site.
Calcul de Re
Si le protocole d'allocation de ressources utilisé au niveau du site est le protocole à
héritage de priorités, la durée maximale de blocage Re de la tâche E par des tâches moins
prioritaires s’exprime comme suit:
Re= max(l,m) * max {durée de la section critique de Tj}
j=1,n −l
Comme expliqué, au chapitre 2, dans la partie descriptive du protocole, l est le nombre
de tâches moins prioritaires que E, m le nombre de sections critiques qu’elle peut
demander et n est le nombre total de tâches dans le site.
Si le protocole d'allocation de ressources est le protocole à priorités plafond alors:
Re= max {durée de la section critique de Tj}
j=1,l
Exemple
Supposons que l’application de la figure 5.3 utilise des ressources critiques
locales. Soient deux ressources critiques c1 et c2 disponibles sur le site 1 tels que
A1, A2 et A3 partagent la ressource c1 et A3, A4 et A5 la ressource c2.
Sachant que seule la tâche A3 est émettrice, calculer rm1: rm1=rA3+CA3+BA3 revient à
trouver d’abord BA3.
BA3= HA3+RA3.
Calculons HA3:
Si l’algorithme d’ordonnancement utilisé est de type RM, alors A1 et A4 de
période 60 sont plus prioritaires que A3 de période 100.
24 3
Méthodologie de Validation
D D D
H A3 = ∑ A3 × Cx = A3 × C A1 + A3 × C A4 = 38
x Px PA1 PA 4
Calcul de He
Dans ED, nous considérons toutes les tâches du site qui possèdent des échéances plus
petites que celle de E. Comme les échéances varient, il y a lieu de prendre toutes les
tâches susceptibles d’interrompre E c’est-à-dire considérer le cas défavorable. Pour
cela, nous classons toutes les échéances sur une fenêtre temporelle de largeur égale au
PPCM des périodes Pi de toutes les tâches et nous déduisons la situation défavorable.
P
H e = ∑ e × C x ∀Tx : dx<de sur [0, PPCM(Pi)]
x Px
Calcul de Re
Si le protocole d'allocation de ressources est le protocole à pile, alors Re est identique à
l’expression calculée dans le cas du protocole à priorités plafond, c’est-à-dire:
L’inversion de priorités se fait pour la durée d’une seule section critique. La priorité
dans ce cas correspond au niveau de préemption défini par le protocole à pile puisque la
priorité principale est dynamique.
Exemple
2 3
Reprenons les mêmes conditions de l’exemple précédent en considérant les
mêmes ressources c1 et c2 dans le site 1 avec les mêmes durées des sections
critiques pour les différentes tâches. En prenant ED comme algorithme
d’ordonnancement local, il est nécessaire de déterminer d’abord les échéances
initiales des tâches (du site 1) en prenant en compte la précédence locale selon
des règles décrites dans le chapitre 2 et récapitulées dans le tableau 5.8. Dans cet
exemple, nous nous contentons de donner les nouvelles valeurs des échéances
(voir colonne di du tableau 5.7) sans montrer comment se fait le calcul car il a été
expliqué dans le chapitre 2. Le but de cet exemple est de calculer le temps HA3 de
préemption de A3 lorsque l’algorithme d’ordonnancement local est ED.
La fenêtre temporelle est de largeur égale à l’intervalle de temps [0, PPCM(Pi)]
où PPCM(Pi)=PPCM(50, 100, 150, 200)=3000. Dans cette fenêtre, nous classons
les échéances des tâches en notant le nom de la tâche suivie de son échéance
entre parenthèses comme suit :
A1(41), A4(50), A3(100), A1(101), A4(110), A2(150), A1(161), A4(170), A3(200),
A5(200), A1(221), A4(230), A1(281), A4(290), A3(300), A2(350), A5(400), ...
Remarquons que les tâches qui peuvent interrompre A3 sont, dans le pire des cas,
A1, A2 et A4 car à un moment donné elles peuvent avoir des échéances plus petites
que celle de A3. D’où :
P P P
H A3 = A3 × C A1 + A3 × C A2 + A3 × C A4 = 46
PA1 PA2 PA4
Comme l’algorithme d’ordonnancement est dynamique, il est intéressant
d’utiliser le protocole à pile puisqu’il s’adapte bien à ce type d’algorithme.
Supposons que le niveau de préemption est défini en fonction des délais
critiques des tâches, autrement dit π(Ti)> π(Tj) si D(Ti)<D(Tj). Dans ce cas, les
niveaux de préemption des tâches du site 1 sont ceux définis dans le tableau 5.7.
Tâche ri Ci Di di Pi π(Ti)
A1 0 10 50 41 60 5
A4 10 9 50 50 60 4
2 3
Méthodologie de Validation
A1 A4
C2
A2 A5
A3 m1 C3
m3
C1 m2 B1
B2 B3
Dans toute application distribuée composée de tâches périodiques, nous avons toujours
le triplet suivant:
(re, Ce, De, Pe) (rm, Cm, Dm, Pe) (rr, Cr, Dr, Pe)
223
Il est nécessaire de modifier la valeur d’activation rr de la tâche réceptrice si on veut
réveiller cette dernière à un moment où l’on est sûr que m est reçu par le site
destinataire. Si la tâche R attend aussi un message m’ d’une autre tâche, R doit être
réveillée de préférence à un moment où m et m’ sont arrivés à destination. Il est donc
clair que tout triplet (tâche émettrice, message, tâche réceptrice) ne suffit pas seul pour
la mise à jour des dates de réveil des tâches réceptrices. Il est donc nécessaire de
parcourir le graphe de précédence global afin de tenir compte de l’arrivée de tous les
messages au niveau de chaque tâche réceptrice.
Réveiller la tâche réceptrice à un instant où l’on est sûr que le message m attendu est
arrivé à destination signifie que la nouvelle date d’arrivée rr*=max{rr, rm+Dm} car dans le
pire des cas, m est transmis au bout de rm+Dm unités de temps. Si de plus, la tâche
réceptrice attend un autre message m’, d’après le graphe de précédence global, alors:
rr*=max{rr, rm+Dm, rm’+Dm’}. Dans le cas général, nous noterons :
r*r=max{(rr, rm+Dm)}
Sur le graphe de précédence global, on peut avoir des tâches réceptrices qui précèdent
d’autres tâches sur le même site, appelés tâches successeurs (dans la figure 5.3 par
exemple, B3 est la tâche successeur de la tâche B2). Nous venons de voir que la prise en
compte des messages nécessite de retarder les tâches réceptrices en modifiant leurs
dates d’arrivée. Si de plus, elles précèdent d’autres tâches locales, il y a lieu de modifier
les dates d’arrivée de ces tâches pour maintenir les relations de précédence. Cette
modification ne peut s’opérer n’importe comment mais doit tenir compte de
l’algorithme d’ordonnancement local. En effet, la prise en compte des relations de
précédence, comme nous l’avons vu dans le chapitre 2, doit se faire selon les règles du
tableau 5.8 si rs est la date initiale de réveil de la tâche successeur et rs* est sa nouvelle
date de réveil.
Le tableau 5.8 récapitule les transformations à effectuer sur les paramètres temporels
des tâches en vue de prendre en compte la précédence locale. Le principe est de retarder
le réveil des tâches successeurs du graphe de précédence locale (condition 1), ce qui a
pour conséquence de réduire les délais critiques des tâches (condition 2). Toutes les
tâches liées par une relation de précédence possèdent la même période (condition 3) par
hypothèse.
Tableau 5.8: Règles de prise en compte des relations de précédence locale entre toute tâche
Tr=(rr, Cr, Dr, Pr) précédant une tâche Ts=(rs, cs, Ds, Ts)
Algorithme condition 1 condition 2 condition 3
RM rs*=Max{(rs, rr*)} affectation statique des priorités Ps=Pr
avec respect des précédences
DM rs*=Max{(rs, rr*)} Min(Di, Ds*) Ps=Pr
ED rs*=Max{(rs, rr*+ Cr)} dr*=Min{(dr, ds*-Cs)}[CSB90] Ps=Pr
(* signifie valeur mise à jour)
6553 3
Méthodologie de Validation
Les règles du tableau 5.8 doivent s’appliquer, de manière récursive, à chaque portion du
graphe de précédence global relative à un site. En d’autres termes, ces règles concernent
les successeurs directs des tâches réceptrices et les successeurs indirects (successeurs
des successeurs). De plus, si une tâche émettrice est en même temps réceptrice ou
successeur, le parcours du graphe global va provoquer la mise à jour de la date
d’insertion du message émis notée rm* déclenchant ainsi la mise à jour de la date de
réveil de la tâche réceptrice impliquée, c’est-à-dire : rr*=max{(rr, rm*+Dm)}, ainsi de
suite, ...
Le graphe de précédence global doit obligatoirement être acyclique afin que le calcul,
basé sur un parcours récursif du graphe, puisse s’arrêter à un moment donné.
Exemple
Site1
Site3
A1
A2
C2
A4
m2(5)
A5 C3
A3
C1
m3(8) m1(5)
B2 B1
Site2
B3
6563
♦ Soit le triplet (A3, m2, C3). Lorsque les valeurs s’expriment en ms, l’unité de
mesure n’est pas spécifiée.
• les temps Cm2 et Dm2 sont calculés comme dans le paragraphe 3.1.2.3
- Cm2=101µs
- Dm2=433µs
Caractéristiques de m3 :
P P
He= C 3 × CC1 + C 3 × CC 2 =2CC1+CC2=12+5=17
PC1 PC 2
657 3
Méthodologie de Validation
Tableau 5.9 : Nouvelles caractéristiques des tâches et des messages pour l’application de la figure 5.3
dans le cas de RM
Site1 A1 0 10 50 60
A2 0 8 150 200
A3 0 10 100 100
A4 0 9 50 60
A5 0 5 200 200
Site2 B1 6,23 5 50 50
B2 74,99 5 80 100
Site3 C1 0 6 50 50
C2 0 5 80 100
C3 52,43 5 80 100
6583
C2=(r=0, C=5, D=80, P=100) et C3=(rr=0, Cr=5, Dr=80, Pr=100)
- Cm2=101µs
- Dm2=433µs
659 3
Méthodologie de Validation
Tableau 5.10 : Nouvelles caractéristiques des tâches et des messages pour l’application de la figure 5.3
dans le cas de ED
Site1 A1 0 10 50 60
A2 0 8 150 200
A3 0 10 100 100
A4 0 9 50 60
A5 0 5 200 200
Site2 B1 16,23 5 50 50
B2 82,99 5 80 100
Site3 C1 0 6 50 50
C2 0 5 75 100
C3 65,43 5 75 100
65133
Le diagramme de Gantt montre l'utilisation du processeur et l'activité du réseau sur un
cycle de temps qui commence à l’instant min(ri) et finit à l’instant max(ri)+PPCM(Pi)
lorsque Pi sont les périodes des différentes tâches de l'application et ri leurs dates
d’activation. Pour des raisons d'espace, le diagramme de la figure 5.7 ne représente pas
toute la durée de simulation qui est égale à 75690+PPCM(60, 200, 100, 50)=675690µs.
A l’aide du diagramme de Gantt, nous vérifions le respect des échéances pour les tâches
et pour les messages afin de déduire la validité de l’application. Dans une application
temps réel à contraintes strictes, si une tâche ou un message dépasse son échéance,
l'application n'est pas ordonnançable.
A1 A4 A3 A2 A5 A1 A4 A3 A1 A4 Site1 A1
D C
m2 (4000)
6543 3
Méthodologie de Validation
Les caractéristiques temporelles des tâches sont données dans le tableau 5.11.
m1 peut entrer en conflit avec m2 puisque ce dernier est émis par un autre site.
s+ p n −1
Dm1= Cp + ∑ ( Cpi + ∑ Cpj + ( n − 1) Tc ) avec n=2, p=3 et s=0
i =1 j =1
Dm1=8135µs
Au niveau du site 2 :
65 3
Site2 C 400 10000 10000
Au niveau local des sites, il n’y a pas de précédence locale, seule la communication est
à prendre en compte. B et D sont des tâches consommatrices respectivement sur le site 2
et le site 1 :
65 3 3
Méthodologie de Validation
A D
Site1
500 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000
C B
Site2
500 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000
La figure 5.9 montre un cas de préemption de messages. En effet, les tâches A et C qui
sont émettrices de messages s’exécutent simultanément sur des sites différents. Comme
C se termine la première, elle envoie m2 qui commence à être transmis sur le réseau.
Lorsque A se termine, m1 est inséré dans la file de transmission locale en attente de la
libération du réseau. A la fin de la transmission du premier paquet de m2, les paquets de
m1 et les paquets restants de m2 sont émis par leurs sites. Ils rentrent en collision. La
résolution de la collision se fait en autorisant le site le plus prioritaire à émettre c’est-à-
dire le site 1. Les paquets de m1 sont, par conséquent, émis avant les deux paquets
restants de m2 : nous assistons à une préemption.
Si nous augmentons la taille du message émis, par exemple, par A, nous constatons
qu’au delà d’une taille équivalente à trois paquets c’est-à-dire 3*1518=4554 octets, le
système n’est pas ordonnançable. En effet, si par exemple, m1 a une taille de 4700
octets, ce qui équivaut à 4 paquets CSMA, alors le délai de transmission correspondra à
Dm1 égal à 10155µs qui est supérieur à la période de la tâche consommatrice. Dans ce
cas, selon la méthodologie appliquée, cette tâche doit être réveillée après ce délai pour
consommer le message m1. Or, par hypothèse, la période de la tâche consommatrice est
de 10 000µs c’est-à-dire inférieure à ce délai. Nous concluons que ce système reste
ordonnançable jusqu’à une taille des messages n’excédant pas 4554 octets en
garantissant que tout message produit est consommé.
6523
Commande moteur
(monter, descendre, stop)
Voyant
de direction
Niveau p
Voyant - témoin
Niveau 1 d'appel ascenseur
Bouton
d'appel
Capteur
position
porte
Capteur p
position ascenseur
Commande 2
porte Niveau 0
(fermer, ouvrir)
Bouton 1 Voyant - témoin
choix d'appel étage
étage
0
6653 3
Méthodologie de Validation
Contrainte critique
Les signaux provenant de capteurs de position doivent être pris en compte par le
système dans un délai maximum de 50ms.
Contraintes relatives
• L'intervalle minimum entre deux pressions sur un bouton de sélection d'étage à
l'intérieur de l'ascenseur est de 250ms.
• Les appels provenant des boutons d'appel des étages sont au minimum espacés de
200ms.
4.2.2.Étude de l’application
Les entités extérieures avec lesquelles le système est en relation sont (voir figure 5.11):
∗ les capteurs de position
∗ le moteur des ascenseurs
∗ la porte des ascenseurs
∗ les boutons de sélection d’étages des ascenseurs
∗ les voyants associés aux boutons de sélection d’étage
∗ les boutons d’appel
∗ les voyants associés aux boutons d’appel
∗ les voyants de direction
6663
Voyants des
ascenseurs
Boutons des
ascenseurs Sortie voyants Boutons
ascenseur d’appel aux
étages
Entrée boutons
ascenseur Entrées boutons
Système de étage
contrôle des
Commande ascenseurs
Porte des porte Sortie voyants
étage Voyants
ascenseurs d’appel aux
Etats porte étages
Commandes Sortie voyants
moteur de direction
Etats moteur Entrée capteurs
position
Voyants de
Moteur des direction aux
ascenseurs étages
Capteurs de
position
667 3
Méthodologie de Validation
1 contrôleur
Contrôler
état & application
destination
ascenseur
IT n ascenseurs ordre
boutons contrôleur
ascenseur
étage
1.5
boutons demandé
Gérer boutons Gérer ascenseur
ascenseur
cabine
demande :
état montée,
descente,
IT ascenseur
capteur aucune
étage
1.4
capteurs Traiter capteurs Contrôler demande
étage de
étages cabine
numéro service
étage état
ascenseur
IT
boutons
étage
Une étude approfondie des sous-systèmes nous permet d’obtenir les tâches, de la figure
5.12, pour lesquelles nous reprenons les caractéristiques temporelles définies dans la
spécification de Gomaa [Gom 93] (voir tableau 5.13). La tâche GVE du sous-système
étage, donnée dans le tableau 5.13, regroupe les tâches Eteindre boutons appel et Gérer
voyants direction présentées dans le schéma de la figure 5.12. Etat ascenseur est une
donnée partagée par les tâches Gérer ascenseur et Contrôler cabine du sous-système
ascenseur, comme son l’indique, elle désigne l’état de l’ascenseur. De même, état
global application est une donnée, partagée par les tâches du contrôleur, qui mémorise
l’état de tous les ascenseurs qu’il gère.
Les tâches sont synchrones c’est-à-dire activées à l'instant 0. Les priorités des tâches
(voir Pr du tableau 5.13) sont données selon un algorithme à priorité fixe tout en
respectant la précédence locale. Nous supposons une architecture réseau multi-site dans
6683
laquelle chaque étage est sur un site, chaque ascenseur est sur un site et le contrôleur sur
un autre site. Chaque message est composé de 3 octets de données.
Sous-système étage:
- Traiter Boutons Étage: TBE 4 200 2
- Gérer Voyants Étages : GVE 10(5+5) 200 1
Sous-système contrôleur:
- Gérer État Application: GEA 2 50 2
- Contrôler Application: CA 20 200 1
GBC2 GBC1
GA2 GA1 GEA
TCE2 TCE1
CC2 CC1 CA
m1
m5 m1 m2 m2, m4, m5,
m6 m3 m6, m7
m7 m4 m8 m1, m9, m10, m11
m10 m7 m11 m7 m8 m4 m9 m4
669 3
Méthodologie de Validation
6613
En appliquant la méthodologie, nous déterminons d’abord les caractéristiques des
messages. Dans le cas d’un réseau CAN avec un débit de 1Mb/s, les caractéristiques
temporelles présentées au tableau 5.15 sont obtenues pour des priorités de messages
spécifiées dans la colonne Prm.
Dans le cas d’un réseau FDDI, avec TTRT=5000µs et un débit de 100Mb/s, les
caractéristiques des messages sont différentes (voir tableau 5.16). Le calcul est fait en
affectant, aux sites ascenseurs et contrôleur, des bandes passantes plus importantes que
celles des sites étages car ils émettent plus de messages.
Si.TTRT pour les sites contrôleur et ascenseur: 1089µs
Si.TTRT pour les sites étages: 360µs.
En parcourant le graphe de précédence global (voir figure 5.14), les dates d’insertion
des messages sont calculées (voir tableau 5.17) et une mise à jour des dates de réveil des
tâches réceptrices est faite (voir tableau 5.18).
Une dernière étape consiste à ordonnancer les tâches sur les sites propriétaires et les
messages sur le médium. Pour des raisons d’espace, nous ne pouvons tracer le
diagramme de Gantt. Néanmoins, nous montrons, grâce à l’outil qui implémente cette
méthodologie, que cette application est valide, c’est-à-dire les contraintes de temps
spécifiées dans le cahier des charges sont bien respectées.
Le diagramme de Gantt a été tracé pour une durée de simulation égale à [0, 244 948]
dans le cas du réseau CAN et égale à [0, 258 000] dans le cas du réseau FDDI. Les
contraintes de temps spécifiées dans le cahier des charges sont respectées puisque toutes
les tâches respectent leurs échéances.
6643 3
Méthodologie de Validation
m1 32704 37000
m2 44736 53000
m3 5000 5000
m4 16000 16000
m5 44736 53000
m6 5000 5000
m7 16000 16000
m8 4000 4000
m9 4000 4000
m10 4000 4000
m11 4000 4000
Tâches réceptrices ri ri
ou successeurs (CAN) (FDDI)
Site contrôleur
- GEA 44948 58000
- CA 4704 9000
Site ascenseur1
- GA1 33736 42000
Site ascenseur2
- GA2 33736 42000
Site étage
- GVE11 16540 21768
Site étage
- GVE21 16540 21768
Site étage
- GVE12 16540 21768
Site étage
- GVE22 16540 21768
66 3 3
GVE11
m4
m4
TCE1 CC1 GVE21
m3 TBE12
m4
TBE11 m10 TBE21
GBC1 GA1 GEA m8
m2 m9
m1
CA
TBE22
m11
m1
m7 GVE12
m7 Les envois de m1 sont
TCE2 CC2 GVE22 exclusifs
m6 m7
GBC2 m5
GA2 GEA
5. Conclusion
A travers ce chapitre, nous avons développé une méthodologie pour analyser et valider
les applications temps réel distribuées à contraintes strictes. Nous avons défini des
modèles temporels analogues pour les tâches et les messages. Nous avons supposé que
les attributs temporels des tâches étaient définis par le concepteur de l’application, il
restait donc à calculer ceux des messages. Deux paramètres particuliers (le temps de
propagation et le délai de transmission) dépendent étroitement du réseau choisi. A
travers cinq exemples de protocoles de communication, nous avons montré comment
calculer ces paramètres. Les relations de précédence sont ensuite dérivées par
modification des attributs des tâches et des messages conduisant ainsi à une
configuration de tâches et de messages indépendants. La figure 5.15 illustre, dans le
temps, les instants pertinents calculés tout au long de ce chapitre, pour un triplet (tâche
émettrice, message échangé, tâche réceptrice).
re rm rr
Ce temps d'attente dans la file
Ce+Be Cm: temps de transmission
Dm: temps de réponse
P e: période
66 3
Méthodologie de Validation
6623
CHAPITRE 6
1. Introduction
Ce chapitre présente l’outil MOSARTS que nous avons développé et qui implante la
méthodologie de validation décrite dans le chapitre précédent.
2 . M O S A RT S : u n o u t i l d e v a l i d a t i o n
d’applications temps réel réparties
MOSART est un outil d'aide à la validation d’applications temps réel réparties basé
sur la méthodologie que nous avons proposée. J’ai développé, en langage C, tous les
programmes qui implémentent cette méthodologie en incluant les trois types
d’ordonnancement (RM, DM, ED) pour les sites ainsi que les stratégies de
communication (FIP, CSMA/DCR, CAN, FDDI, TDMA) pour le réseau. D’autres
personnes ont contribué au développement de MOSARTS : deux étudiants de
l’université de Clausthal (Allemagne) ont réalisé l’interface en Tcl/Tk (voir annexe1)
et un étudiant de maîtrise informatique de l’université de Poitiers a contribué au calcul
des critères de performance des messages.
6763
servant à la saisie des données et à la visualisation des résultats figurent dans l’annexe
2.
36773
Analyse des performances
• RM avec PHP4
• RM avec PPP5
• DM avec PHP
• DM avec PPP
• ED avec PAP6
2.1.2.Description du réseau
• le protocole de communication.
L’utilisateur définit chaque message en lui associant une tâche émettrice sur un site et
une tâche réceptrice sur un autre site. Il ne fournit que la taille du message en octets
car les caractéristiques temporelles seront calculées automatiquement par MOSARTS.
4
Protocole à héritage de priorités
5
Protocole à priorités plafond
6
Protocole à pile
3 678
Les priorités des messages peuvent être définies selon le protocole de communication
utilisé. En effet, elles sont données explicitement par l'utilisateur dans CAN, elles sont
confondues avec celles des sites dans CSMA/DCR, elles dépendent des bandes
passantes allouées aux sites dans FDDI, ainsi que de la disposition des sites dans
l'anneau et dépendent du nombre de tranches de temps allouées à chaque site et de la
position de chaque site par rapport au générateur de trames dans TDMA. Par contre,
dans FIP, l’utilisateur ne fournit aucune information relative à la priorité car les
messages sont triés, dans la table de scrutation, dans l’ordre croissant de leurs périodes
et sont transmis dans cet ordre.
MOSARTS possède des caractéristiques physiques, par défaut, pour chaque réseau
mais l’utilisateur peut les modifier. Les protocoles MAC implantés sont : CAN, FDDI,
CSMA/DCR, FIP et TDMA.
3679
Analyse des performances
FileNet.CAR
Interface
Description de l'application }Description de
l’application
Application.PRE
- Calcul de Cm , Dm
- Héritage de la période
FileMsg.MES
- Affectation de priorité
selon RM ou DM
- Calcul des ri* et di* pour ED
Application.MET
} Modélisation
Priorités des
messages FileNet.CAR
Methodologie
Calcul de Be, rm, rr, rs
Application.SCH
} Prise en compte
de la communication
Protocole de gestion
FileMsg.REQ de ressources (PHP, PPP, PAP)
Ordonnancement selon
le protocole de comm.
FileMsg.SEQ
Ordonnancement selon
RM, DM ou ED
}
Application_site.SEQ
Ordonnancement
Les trois premières étapes ont été détaillées dans le chapitre précédent. Il reste à
s’intéresser aux critères de performance définis pour les sites et le réseau. En effet,
l’étape concernant l’ordonnancement nous trace le diagramme de Gantt relatif à
chaque site et au réseau en montrant les instants occupés et les instants libres du
processeur ou du réseau comme dans la figure 6.3. Ce diagramme est un résultat brut
qu'il convient d'analyser pour connaître la pertinence des résultats, selon des critères
de performance que nous avons développés.
3 671
Figure 6.3: La séquence d'exécution d’un site
Au delà de l’instant final, le système se retrouve globalement dans le même état qu’au
début.
Les différents critères de performance que fournit l’outil MOSARTS sont présentés
dans la figure 6.4. Ils sont calculés pour les tâches, pour le réseau et pour l’application
globale. Les critères de performance relatifs aux tâches ont été initialement calculés
pour des applications temps réel monoprocesseur [Bab 96] et ont été repris et intégrés
dans MOSARTS.
a. Temps de réponse
On définit le temps de réponse d'une tâche par l’intervalle de temps qui sépare son
instant de réveil de la fin de son exécution (figure 6.5). Sur une séquence d’exécution
relative à un site, on évalue classiquement les temps de réponse minimal (TRmin),
moyen (TRmy) et maximal (TRmax) d’une tâche. Dans une séquence valide, on doit
toujours avoir la relation [KRP 94 et al.] suivante pour une tâche périodique i:
Ci ≤ TRi ≤ Di soit TRmax ≤ Di
Le calcul de ce paramètre a une grande utilité surtout lorsque les tâches périodiques
correspondent à des serveurs qui traitent des tâches apériodiques car, dans ce cas, le
temps de réponse nous informe sur le temps moyen nécessaire pour servir une tâche
apériodique.
3674
Analyse des performances
tâche i
ri: date de départ
Di: délai ( échéance )
fi: date de fin d'exécution
TRi: temps de réponse
TRi TRAi TRA: temps de retard admissible
ri fi ri+Di
b. Taux de réaction
On définit le taux de réaction par le temps de réponse d’une tâche, rapporté à son délai
critique. On s’intéresse aux taux de réaction moyen et maximal.
3 67
Le taux de réaction étant relatif à une tâche, on peut alors déterminer celui des
différentes tâches afin d’en déduire un taux moyen pour le site. Ce paramètre nous
indique si les tâches s'exécutent plus ou moins rapidement ou pas au niveau d’un site.
Ci / Di ≤ taux de réaction ≤ 1
d. Charge dynamique
On représente la charge du processeur par ce paramètre, et ce, à chaque instant de la
durée de la simulation. Elle est définie comme étant la somme des durées restantes des
tâches non terminées rapportées à leurs délais critiques dynamiques:
Cirestan t
charge = ∑
D i (t)
les tâches non ter minées
Le délai critique dynamique Di(t) d’une tache Ti est le temps séparant l'instant courant t
de la prochaine échéance de la tâche non terminée. Elle est égale à l’expression
suivante :
Di(t) = Di+ri-t= di-t
La connaissance de cette charge dynamique sur un site nous permet, à nouveau mais
sous un nouveau point de vue, de mesurer l’aptitude d’une séquence à supporter
l’ajout d’une nouvelle tâche. Tout comme le cas du temps de retard admissible, si la
charge nous permet de dire que la possibilité de l’ajout d’une tâche n’affecterait en
rien la validité du site, il n’en est pas de même au niveau de l’application globale.
367
Analyse des performances
Ce paramètre est calculé pour chaque site et à chaque instant. C'est le nombre
d’instants restants dans la séquence où le processeur n’exécute aucune tâche.
TC = durée _ totale − t courant − ∑C i restant
pour toute tache i du site
g. Nombre de préemptions
Il s’agit du nombre de fois qu’une tâche plus prioritaire a pu préempter une autre de
moindre priorité. Cela entraîne un retard dans l’exécution de cette dernière.
Il peut être intéressant de connaître le nombre de préemptions pour pouvoir limiter
celles-ci par une redéfinition des priorités, afin de minimiser le temps de réponse. Ceci
s’avérant intéressant pour l’ajout de tâches supplémentaires. Mais ce changement de
priorité devrait se faire par le changement des périodes ou des délais critiques dans le
cas d’algorithme comme RM ou DM, ce qui implique le changement du
comportement de la tâche.
3 672
3.2. Pour les messages
De manière similaire aux tâches, nous définissons les critères suivants récapitulés dans
MOSARTS comme dans la figure 6.7.
a. Le temps de réponse
Trois temps de réponse sont calculés pour un message : le temps de réponse minimal
(TRmin), maximal (TRmax) et moyen (TRmy). Comme pour les tâches, le temps de réponse
d’un message est le temps qui sépare l’instant de son insertion dans la file de
transmission de la fin de sa transmission sur le réseau. Ce temps inclut le temps dû à
son attente dans la file et celui qui est dû à sa préemption par d’autres messages
comme le montre la figure 6.8.
b. Le nombre de préemptions
Le nombre de préemptions est le nombre de fois qu’un message prioritaire a préempté
un message moins prioritaire. Rappelons que la préemption d’un message se fait à
l’échelle du paquet. La priorité est associée directement au message dans CAN et
chaque paquet du message hérite de cette priorité. Elle est confondue avec celle du site
émetteur dans CSMA/DCR puisque le conflit se produit entre les messages de sites
distincts et les messages du même site sont émis dans l’ordre de leur insertion. La
notion de priorité n’a pas de sens dans TDMA ni FDDI car les protocoles associés
n’utilisent pas cette notion même s’il arrive qu’un message d’un site i entame sa
transmission avant même qu’un message d’un site j qui a occupé le réseau n’ait fini sa
transmission (seuls les premiers paquets sont émis) parce que, tout simplement, le site
j a consommé toute la bande passante qui lui est allouée (FDDI) ou a épuisé le nombre
de tranches de temps assigné (TDMA). Les paquets restants non encore émis pour le
message du site j seront transmis au prochain passage du jeton (FDDI) ou après un
cycle (TDMA).
T1
en SC
temps
pas de SC
T2 Légende
tâche plus temps
prioritaire que T1 Temps de retard du à l’attente
d’une ressource occupé
T1/ T2/ /* /*
occupation de la T1 T1 T1 T1 T1 T2 T2
ressource R
Figure 6.6: Évaluation du temps de blocage dans une situation d’attente d’une ressource critique
3685
Analyse des performances
Dans ce cas, nous assistons à une sorte de préemption puisque le médium est alloué à
un message avant que le message qui l’occupait n’ait fini sa transmission. MOSARTS
calcule le nombre de préemptions dans tous les réseaux y compris dans le cas de FDDI
et TDMA même si cette notion est interprétée différemment selon le protocole de
communication.
Au contraire, dans FIP, ce paramètre est inopérant puisque le protocole de
communication se comporte comme un séquenceur en se contentant d’inviter le
producteur à émettre et en ne lançant de nouvelle requête que lorsque la variable
précédente est bien consommée.
m1
temps
m1>>m2>>m3
rm3: date d’insertion de m3
m2
temps Dm3: délai de transmission de m3
TRm3: temps de réponse de m3
1 2 3 4
Légende
TRm3
3 686
c. Le nombre d’écrasements
Le nombre d’écrasements est le nombre de messages dont le temps de réponse dépasse
la période sachant que le délai critique d’un message n’est rien d’autre que sa période.
Si un message dépasse son échéance, il sera qualifié de non valide et entraîne la non
validité de l’application si cette dernière est à contraintes strictes.
e. Le taux de réaction
Le taux de réaction est égal au rapport du temps de réponse sur le délai de
transmission : ( Cm/Dm ≤ TRmax/Dm ≤ 1). Si ce taux est proche de 1, cela signifie que le
message est émis très tardivement.
f. La charge dynamique
La charge dynamique nous donne une idée de la charge du médium à chaque instant.
Elle est définie comme étant la somme des durées nécessaires à la transmission des
messages en attente dans la file, rapportées aux délais de transmission dynamiques. Le
délai de transmission dynamique Dm(t) d’un message est le temps séparant l'instant
courant t de la date de son délai de transmission.
C
Charge = ∑ mres tan t pour tout message m en cours ou en attente de transmission.
Dm (t )
charge=0 ⇒ médium libre
charge=1 ⇒ médium totalement chargé
3687
Analyse des performances
4. Résultats de simulation
MOSARTS construit la situation la plus pessimiste du point de vue temporel. Des
mesures ont été faites, dans cette situation, certaines sont relatives aux sites d’autres au
réseau.
MOSARTS peut être utilisé, d’une part, pour faire l’étude des performances
temporelles d’une application donnée et, d’autre part, pour tester l’influence de
certains paramètres, aussi bien associés aux tâches qu’aux messages (réseau), sur les
performances temporelles de l’application ou sur l’ordonnançabilité de celle-ci.
A1 A2 m1
B1 B2
A4
A3 m3 B3 B4
m2
m4
C1 C2
C3 N3
3 688
Tâche Site C (µs) P=D (µs) Pr7
A1 N1 200 10000 3
A2 N1 300 10000 2
A3 N1 100 20000 1
A4 N1 200 5000 4
B1 N2 300 10000 3
B2 N2 400 10000 2
B3 N2 200 5000 4
B4 N2 100 15000 1
C1 N3 300 20000 1
C2 N3 150 15000 2
C3 N3 200 10000 3
Nous avons créé plusieurs situations que nous avons analysées en mesurant les temps
de réponse moyens des messages notés Rm dans la suite.
1er Cas
Nous affectons des tailles identiques à tous les messages en commençant par un
paquet par message dans FDDI et un octet dans CAN et nous essayons de déduire la
taille maximale atteinte sans violation des échéances des tâches et des messages.
7
Priorité selon RM
3689
Analyse des performances
30 Rm1
Temps (ms)
20
Rm2
10
0 Rm3
1 2 3 4 5 6
Rm4
nombre de paquets/message
Figure 6.10: Les temps de réponse variant en fonction du nombre de paquets par message dans FDDI
2ème Cas:
Dans les mêmes conditions que dans le premier cas c’est-à-dire pour les mêmes
caractéristiques physiques des deux réseaux et pour des tailles des messages
initialement égales à un paquet pour FDDI et un octet pour CAN que l’on augmente
respectivement d’un paquet et d’un octet. Nous comparons alors les temps de réponse
Rm mesurés sur le diagramme de Gantt avec les délais de transmission Dm calculés par
la méthodologie. Nous remarquons que ces temps sont plus proches dans le protocole
CAN que dans le protocole FDDI (voir figures 6.12, 6.13). Cette différence entre les
temps Rm et Dm, dans le cas de FDDI, est due au fait que dans le calcul de Dm nous
supposons que les bandes passantes allouées sont complètement consommées par
chaque site à chaque tour du jeton. Mais la simulation se rapproche de la réalité et
donne des temps de réponse plus petits car les sites n'émettent pas à chaque passage du
jeton, c’est-à-dire que chaque site qui n'a pas de message à émettre libère le jeton et le
prochain site émetteur commencera sa transmission plus tôt que prévu. Par exemple, si
un paquet d'un message m est transmis et que la bande passante est consommée parce
qu'elle a été utilisée pour la transmission d'autres paquets et si, de plus, aucun autre
site dans le réseau ne veut émettre alors les paquets de m restants n'attendront que le
temps que mettra le jeton pour parcourir le réseau sans transmission.
Dans le réseau CAN par contre, lorsque la charge du réseau commence à devenir
importante, les temps de réponse (voir figure 6.13) approchent les délais de
transmission car dans le cas de surcharge du réseau, les temps de réponse
correspondent à une situation défavorable exprimée dans le délai Dm.
3ème Cas
Nous considérons, dans ce cas, uniquement le réseau FDDI avec les caractéristiques
physiques suivantes:
Débit=100Mb/s, TTRT=5000µs.
3 681
L'évolution des temps de réponse des messages
avec le nombre d'octets (CAN)
600
temps (µs)
400
200
0 Rm1
1 2 3 4 5 6 7 8 Rm2
nombre d'octets/message Rm3
Rm4
Figure 6.11: Les temps de réponse variant avec le nombre de paquets par message dans CAN
25
20
Temps(ms)
15 Dm
10 Rm
5
0
1 2 3 4 5 6
nombre de paquets/message
Figure 6.12: Comparaison des temps de réponse avec les délais de transmission dans FDDI
3684
Analyse des performances
[2,09±0,36, 3,54±0,36] de H2. Ils sont optimaux car dans cet intervalle, N1 et N2
peuvent envoyer tous leurs messages dans les bandes passantes allouées.
1000
800
temps (µs)
600
400
200
0
1 2 3 4 5 6 7 8 Dm
Rm
nombre d'octets / message
Figure 6.13: Comparaison des temps de réponse avec les délais de transmission dans CAN
30
25
Temps (ms)
Rm1
20
15
Rm2
10
5
Rm3
0
2,9
0,36
0,73
1,08
1,45
1,81
2,17
2,54
Rm4
H1
Figure 6.14: Les temps de réponse des messages lors de l'évolution de H1 dans FDDI
30
25
Temps (ms)
Rm1
20
15
Rm2
10
5
0 Rm3
2,9
0,36
0,73
1,09
1,45
1,81
2,17
2,54
3,26
Rm4
H1
Figure 6.15: Les temps de réponse des messages lorsque H1 varie dans FDDI
3 68
4.2. Deuxième exemple
Considérons l’application répartie schématisée par la figure 6.16 et implantée sur 4
sites. Les caractéristiques temporelles des tâches sont données dans le tableau 6.2 et
s’expriment en µs. Les tailles des messages sont toutes identiques et égales à 8 octets
(voir figure 6.16). Le site 3 et le site 1 disposent respectivement de deux ressources s1
et s2 et d’une ressource s3. Les durées d’utilisation de ces ressources sont données dans
les tableaux 6.3 et 6.4.
Site1
Site3
A1
m1(8) C1
A2
C4
A4
A3
C2
C3
m5(8)
m2(8)
m3(8)
D3 Site2
Site4 B3
m4(8)
B1
D2 D1
B2
368
Analyse des performances
Tableau 6.2 : Les caractéristiques temporelles des tâches de l’application de la figure 6.16
Site Tâche ri Ci Di Pi
Tableau 6.3 : Les durées d’utilisation des ressources par les tâches du site 3
Même si la figure 6.16 distingue cinq messages car la communication est représentée,
dans notre modèle, à l’aide d’un échange de messages entre deux tâches distantes, sur
le médium de communication il n’existe que quatre messages car les messages m2 et
m5 correspondent physiquement à un seul message émis sur le réseau puisqu’ils sont
émis par la même tâche A3 même s’ils sont reçus par deux tâches distinctes B3 et D3.
3 682
Tableau 6.4 : Les durées d’utilisation des ressources par les tâches du site 1
A1 1000 0 0
A2 800 0 0
A3 300 700 0
Les figures 6.17, 6.18, 6.19 et 6.20 représentent les temps de réponse des tâches
respectivement sur les sites 1, 2, 3 et 4. La figure 6.14 donne les temps de réponse des
messages en fonction de l’algorithme d’ordonnancement local.
On pourrait penser que la transmission des messages sur le médium n’a aucune
relation avec l’algorithme d’ordonnancement des sites. Or, comme nous l’avons vu au
chapitre 5, les dates d’insertion des messages sont étroitement liées au contexte des
sites émetteurs. En effet, si avec un algorithme d’ordonnancement les dates d’insertion
des messages sont telles que les messages sont émis séparément sur le réseau alors
avec un autre algorithme les dates peuvent correspondre à d’autres instants provoquant
ainsi des préemptions entre messages et modifiant par conséquent les temps de
réponse obtenus initialement. Dans la figure 6.21, les temps de réponse semblent être
meilleurs avec l’algorithme RM.
Nous constatons que l’algorithme d’ordonnancement qui donne les meilleurs temps de
réponse n’est pas le même pour tous les sites. En effet, RM est meilleur dans le site 1
(figure 6.17) et ED est meilleur dans le site 3 (figure 6.19). Le concepteur pourra opter
pour l’un ou l’autre des algorithmes selon qu’il s’intéresse aux performances d’un site
particulier, ou à celles d’un réseau ou encore à celles de l’ensemble des sites et du
réseau.
36953
Analyse des performances
performances lorsque le réseau utilisé est CAN avec les caractéristiques physiques et
les priorités des messages telles qu’elles sont spécifiées.
1500
tâches du site 2 en
1000
500 fonction de
0 l’algorithme
B1 B2 B3 RM_PPP
d’ordonnancement
local dans le cas
Tâches du site 2 ED_PAP d’un réseau CAN
10000
fonction de
5000
l’algorithme
0 d’ordonnancement
C1 C2 C3 C4 RM_PPP local dans le cas
Tâches du site 3 ED_PAP d’un réseau CAN
3 6963
Le nombre de changement de contexte par site
en fonction de l'algorithme d'ordonnancement Figure 6.22 :
local
Variation du nombre de
100 changement de contexte en
0
fonction de l’algorithme
site1 site2 site3 site4 RM_PPP
d’ordonnancement local
dans le cas d’un réseau
ED_PAP
CAN
4.2.1.4. Conclusion
A travers l’analyse temporelle des sites, nous pouvons conclure que cette application
donne les meilleures performances, au sens des temps de réponse, avec l’algorithme
d’ordonnancement RM lorsque le réseau utilisé est CAN.
Etant donné un réseau de type CAN, il est possible, dans une deuxième étape,
d’étudier l’influence des caractéristiques physiques du réseau, par exemple faire varier
le débit, ou bien changer les priorités des messages toujours dans le souci de trouver
les paramètres qui conviennent le mieux d’un point de vue temporel. Cela dépend des
spécifications faites dans le cahier des charges.
L’objectif peut être aussi de tester l’application sur plusieurs réseaux et d’opter pour
un type de réseau en fonction des résultats d’analyse obtenus.
36973
Analyse des performances
Débit = 1Mb/s ; m1>>m2>>m3>>m4 (si a>>b signifie a plus prioritaire que b).
2. Réseau FDDI
Débit=100Mb/s, TTRT=5000µs ;
3. Réseau CSMA/DCR
Débit=10Mb/s, Tc=50µs ;
Site1>>Site2>>Site3>>Site4.
4. Réseau TDMA
3 698
Les temps de réponse des messages en fonction
du réseau Figure 6.24 :
4000
de réponse des
messages en fonction
2000
du réseau local dans
CAN
0 le cas de l’algorithme
m1 m2 m3 m4 FDDI
RM
CSMA/DCR
TDMA
Dans les figures relatives aux sites 3, 4 et 5 (figures 6.26, 6.27, 6.28) les temps de
réponse ne sont pas identiques pour tous les réseaux. Ceci s’explique par le fait
suivant : comme les messages ont des délais de transmission différents selon le réseau
considéré les instants de réception des messages, par conséquent les dates de réveil des
dates réceptrices sont retardées ou avancées. Ainsi l’ordonnancement des tâches au
niveau d’un site récepteur change car, si dans un cas, deux tâches sont réveillées
séparément et exécutées séparément, la modification d’une date de réveil d’une tâche
(parce qu’elle est réceptrice de message) peut provoquer une préemption ou un
blocage pour une ressource parce que la tâche qui occupe le processeur est moins
prioritaire ou bien parce qu’elle détient la ressource demandée. Ces interactions
peuvent diminuer ou accroître les temps de réponse des tâches et changer la séquence
d’exécution du site qui peut alors générer plus ou moins de changements de contexte
ou de préemptions comme dans la figure 6.29.
4.2.2.2. Conclusion
Comme les variations des temps de réponse pour chaque tâche ne sont pas très
importantes en changeant de réseau, le choix de ce dernier se basera principalement,
pour cette application, sur les temps de réponse des messages qui nous permettent de
classer les protocoles de communication dans l’ordre suivant: FDDI, CAN,
CSMA/DCR et TDMA en supposant un ordonnanceur de tâches de type RM au niveau
des sites.
3699
Analyse des performances
1000
800 local dans le cas de
600
400 l’algorithme RM
200
0
CAN FDDI CSMA/D TDMA D1
CR
D2
Réseaux D3
3 6913
4.2.3.Analyse temporelle de bout en bout
L’analyse temporelle de bout en bout consiste à étudier d’un point de vue temporel un
ensemble de tâches liées par des relations de précédence locale et globale. Dans
l’exemple de la figure 6.9, si A1 est une tâche qui lit un capteur de température,
périodiquement, qui transmet ses données à la tâche A2 qui les traite et les transmet à
C4 sur le site 3 pour afficher les résultats, il serait intéressant d’étudier le temps que
mettrait la séquence de tâches A1, A2 et C4 à partir de la lecture du capteur jusqu’à
l’affichage. Ce temps peut être pertinent pour le concepteur. D’après l’analyse
précédente faite pour les sites et le réseau, l’affichage des résultats sur le site3 obtenus
à partir de données lues sur le site1 se fait dans le meilleur des cas au bout de 4668,7µs
et ceci en utilisant l’algorithme RM avec le réseau CSMA/DCR comme le montre le
tableau 6.5.
5. Conclusion
Dans ce chapitre consacré à l’évaluation des performances temps réel d’une
application répartie, nous nous sommes intéressés à deux exemples d’applications
temps réel réparties.
Le premier exemple a été traité dans le but d’étudier les réseaux CAN et FDDI. Un des
paramètres pertinents à mesurer concerne les temps de réponse des messages. D'abord,
les résultats vérifient bien la propriété classique: CAN est plus approprié lorsque les
messages sont petits alors que FDDI a de meilleures performances avec des messages
de taille importante. Ensuite, la comparaison des délais de transmission et les temps de
réponse observés en simulation montrent bien l'efficacité des différents protocoles
dans le contexte d'une application spécifique.
Finalement, une étude numérique a été présentée concernant l'effet de l'allocation de la
bande passante pour un réseau FDDI, qui montre qu'une application est ordonnançable
sur un grand intervalle de temps lorsque la bande passante est proportionnelle au
nombre d'émissions pour chaque site. Cette approche est particulièrement intéressante
dans les systèmes distribués temps réel à contraintes strictes où les contraintes
d'ordonnançabilité sont clairement définies et où les caractéristiques temporelles sont
d'une importance primordiale.
Le deuxième exemple a été utilisé pour montrer le type d’analyse que l’on peut faire
sur une application à partir de quelques paramètres mesurés sur le diagramme de
Gantt. Cette analyse distingue plusieurs cas:
- l’étude temporelle des sites à travers les temps de réponse des tâches,
- l’étude temporelle du réseau à travers les temps de réponse des messages,
- l’étude temporelle de bout en bout d’une séquence de tâches.
Tableau 6.5 : Les temps de réponse pour la séquence (A1, A2, C4) dans différents cas
Tâche/séquence RM avec CAN ED avec CAN RM avec FDDI RM avec CSMA RM avec TDMA
A1 1000 1000 1000 1000 1000
A2 2700 2700 2700 2700 2700
C4 1071,8 1091,7 1036 968,7 1061,2
(A1, A2, C4) 4771,8 4791 ,8 4736 4668,2 4761,2
3694
Analyse des performances
L’exemple illustre bien le fait que les performances d’une application dépend de
l’algorithme d’ordonnancement des tâches, des caractéristiques physiques du réseau
ainsi que du protocole de communication utilisé.
3 69 3
CONCLUSION GENERALE
Après avoir défini une application temps réel répartie comme étant un ensemble de
tâches réparties sur différents sites pour lesquels le seul moyen de communication est
l’échange de messages reposant sur un réseau local doté d’un protocole de
communication temps réel, nous avons développé notre étude selon trois axes
principaux:
Les messages sont les entités d’information échangées entre les tâches application. Ils
sont décomposés en plusieurs entités d’information de taille fixe appelées paquets ou
trames. Les trames sont les unités d’information connues du réseau et sont
ordonnancées sur le médium de communication à l’aide d’un protocole de
communication MAC. Une classification de ces protocoles est présentée et illustrée par
un exemple réel de protocole pour chaque classe.
6923
En ce qui concerne la méthodologie de validation:
A travers les hypothèses qui sont faites, nous avons défini clairement le type
d’applications temps réel réparties pour lequel nous pouvons appliquer notre analyse, à
savoir les applications constituées de tâches périodiques à contraintes strictes
implantées sur un réseau fiable, muni d’une horloge globale et fournissant un délai de
communication borné.
Nous avons défini un modèle de message analogue à celui des tâches et, comme les
tâches que nous traitons sont périodiques, nous avons restreint notre étude aux messages
synchrones.
Les méthodes et outils qui ont traité le problème de l’ordonnancement des tâches et des
messages ont toujours favorisé un aspect particulier. Dans PERTS [LRD et al.], par
exemple, l’analyse d’ordonnançabilité des tâches est plus approfondie tandis que dans
[TBW 95] et [SSB 97] c'est l’ordonnancement des messages qui est prépondérant. [KLR
94] tente bien une étude de l’ordonnançabilité de l’application répartie dans sa globalité
(ordonnançabilité des tâches et des messages) en appliquant la même technique
d’ordonnancement pour les tâches et pour les messages. Néanmoins, cette méthode est
limitée à un réseau FDDI et ne tient pas compte de la politique d’ordonnancement des
messages. Nous avons donc apporté une solution à ces carences. Notre méthodologie
prend en compte aussi bien l’ordonnancement des tâches au niveau des sites, en
considérant les relations de précédence entre tâches et le partage de ressources, que
l’ordonnancement des messages en tenant compte des caractéristiques physiques du
réseau et du protocole de communication associé. Nous ne faisons pas d'hypothèse
restrictive sur l'algorithme d’ordonnancement des sites ni sur le protocole de
communication du réseau. Notre méthodologie est donc générale et ne se borne pas à un
algorithme d’ordonnancement local ni à un réseau de communication particuliers (voir
tableau 6.6).
La stratégie de la méthodologie consiste à déterminer les paramètres temporels des
messages en altérant ceux des tâches impliquées dans la communication, les
caractéristiques temporelles des tâches étant définies par le concepteur et donc connues
a priori. Une fois les tâches et les messages complètement définis du point de vue
temporel, on opère un ordonnancement des tâches locales selon le même algorithme
d’ordonnancement sur tous les sites et un ordonnancement des messages sur le réseau
selon un protocole de communication.
Conjointement, nous avons développé un outil, appelé MOSARTS, basé sur la
méthodologie proposée, qui offre la possibilité de choisir un algorithme
d’ordonnancement associé à un protocole d’allocation de ressources pour tous les sites
et un protocole de communication pour le réseau caractérisé par des paramètres
physiques. En outre, il intègre un module d’évaluation des critères de performance,
calculés pour les tâches et pour les messages. Ce calcul nous donne une appréciation,
sous les conditions les plus pessimistes, sur les temps de réponse des tâches et des
messages, les taux d’utilisation des processeurs des sites et du médium de
communication, etc. L’outil d’analyse temporelle peut être utilisé, d’une part pour faire
l’étude des performances temporelles d’une application donnée et, d’autre part, pour
tester l’influence de certains paramètres, aussi bien associés aux tâches qu’aux
messages, sur les performances temporelles de l’application ou sur l’ordonnançabilité
de celle-ci.
3615
Conclusion générale
Perspectives:
♦ Cette méthodologie analyse les tâches périodiques qui échangent des messages
synchrones. Les tâches apériodiques peuvent être intégrées si elles sont gérées
par des serveurs périodiques. En d’autres termes, cette méthodologie telle
qu’elle est présentée ne sait pas tenir compte des événements aléatoires qu’il
s’agisse des tâches ou des messages. Il serait donc intéressant d’étendre ce
travail à l’analyse des tâches apériodiques qui échangent des messages
asynchrones en définissant, par exemple, des lois probabilistes d’arrivée des
tâches apériodiques qui produisent par conséquent des messages asynchrones
suivant les mêmes lois.
♦ Nous avons fait l’hypothèse, tout au long de notre étude, d’un réseau fiable
c’est-à-dire présentant un taux d’erreurs négligeable. Une amélioration de notre
travail serait de prendre en compte différents types d’erreurs de transmission,
d’évaluer le surcoût en temps de calcul induit par ces erreurs et concevoir son
intégration dans cette méthodologie. A première vue, les erreurs que nous
pouvons borner dans le temps peuvent être prises en compte facilement en
incluant le temps nécessaire à leur détection et leur traitement dans les délais
de transmission des messages.
3 616
♦ L’ordonnancement des messages a consisté en l’utilisation simplement d’une
technique MAC qui est plus destinée à la gestion d’accès au médium qu’à la
prise en compte des contraintes de temps des messages. L’idée serait d’enrichir
cette technique à l’aide d’un algorithme d’ordonnancement pour les messages
(RM, EDF, etc.) et d’intégrer, dans cette méthodologie par conséquent, un vrai
algorithme d’ordonnancement. La modularité de MOSARTS et la
communication des modules à l’aide de fichiers donnent une certaine souplesse
quant à la modification d’un module. En effet, dans ce cas précis, il suffit de
remplacer le programme actuel qui implante une stratégie d’accès au médium
en un programme qui implante un algorithme d’ordonnancement de messages.
3617
BIBLIOGRAPHIE
[ACZD 92]: G. Agrawal, B. Chen, W. Zhao, S. Davari, " Guaranteeing synchronous message deadlines
in high speed ring networks with the timed token protocol", Proc. of the 12th inter. Conf. on
Distributed Computing Systems, pp. 468-475, Japan, 1992.
[ARS91]: K. Arvind, K. Ramamritham, J.A. Stankovic, " A local area network architecture for
communication in distributed real-time systems", J. of Real-Time Systems, 3(2), pp.115-147,
1991.
[Bab 96]: J. P. Babau, "Etude du comportement temporel des applications temps réel à contraintes
strictes basée sur une analyse d'ordonnançabilité", thèse de doctorat, ENSMA, 1996.
[Bak 91]: T. P. Baker, "Stack-Based Scheduling of Realtime Processes", J. Real-Time Systems, Vol. 3,
N° 1, pp. 67-99, March 1991.
[Bla 76]: J. Blazewicz, « Scheduling Dependant Task with Different Arrival Time to meet Deadlines »,
Modeling and Performance Evaluation Computer Systems, E. Geslenbe ED., pp. 57-65, 1976.
[CM 94] : C. Cardeira, Z. Mammeri, « Ordonnancement des tâches dans les systèmes temps réel et
répartis - Algorithmes et critères de classification », revue APII, Vol. 28, n°4, pp. 353-384,
1994.
[CSB 90]: M. Chetto, M. Silly, T. Bouchentouf, "Dynamic scheduling of real-time tasks under
precedence constraints", J. of Real-Time Systems, 2, pp. 181-194, 1990.
[DRSK 89]: A. Damm, J. Reisinger, W. Schwabl & H. Kopetz, « The Real-Time Operating System of
MARS », ACM Operating Systems Review, 23(3), july 1989, pp. 141-157.
[Ell91]: J.P. Elloy, "Les contraintes de temps réel dans les systèmes industriels répartis", RGE 2, pp. 26-
30, 1991.
[EVC 96]: J. Echague, J. Vila, A. Crespo, "Providing Generalized Rate Monotonic Scheduling Theory
to I/O Abstractions over Timed Token Protocol MAC Networks", Proc. of IEEE Real-Time Syst.
Symp., pp.107-110, Montréal, 1996.
[FM 96] : P. Fonseca, Z. Mammeri, « A Framework for the Analysis of non-deterministic Clock
Synchronisation Algorithms » Distributed Algorithms, LNCS n°1151, pp. 159-174, 1996.
6183
[Gom 93] : H. Gomaa, « Software Design Methods for Concurrent and Real-Time Systems », Ed.
Addison Wesley, 1993.
[Hen 75]: R. Henn, « Deterministic Modelle fur die Prozessorzuteilung in einer harten Realzeit-
Umgebung », Phd Thesis, Technical Univ. Munich, 1975.
[HR 94]: N. Homayoun, P. Ramaritham, " Dynamic Priority Scheduling of Periodic and Aperiodic Tasks
in Hard Real-Time Systems", The Journ. of Real-Time Systems, 6, pp. 207-232, 1994.
[IEEE 85]: Carrier Sense Multiple Access with Collision Detection (CSMA/CD), IEEE std 802.3, 1985.
[IEEE 802.5]: Token Ring Access Method and Physical Layer Specification, IEEE Std 802.5, 1985.
[ISO 84] : ISO 7498, Information Processing Systems, Open System Connection, Basic Reference
Model, 1984.
[ISO 94]: International Standard Organization, "Road Vehicles - Low Speed Serial Data Communication-
Part2:Low-Speed Controller Area Network (CAN)", ISO 11519-2, 1994.
[Kai 82]: C. Kaiser, « Exclusion mutuelle et Ordonnancement par priorités », TSI 1 (1), pp. 59-68,
1982.
[KG 94]: H. Kopetz, G. Grünsteidel, "TTP Protocol for Fault-Tolerant Real-Time Systems", IEEE
Computer, pp. 14-23, jan. 1994.
[KLR 94]: H. Klein, J. Lehoczhy, R. Rajkumar, "Rate monotonic analysis for real-time industrial
computing", Computer 1, pp. 24-33, 1994.
[Kop 86]: H. Kopetz, « Scheduling in Distributed Real-Time Systems », Proc. of Advanced Seminar on
Real-Time Local Area Networks, Bandol, France, Apr. 1986, pp. 105-126.
[KRP 94 et al.]: M. H. Klein, T. Ralya, B. Pollok, R. Oberza, M. G. Harbour, "A Practioner's Handbook
for Real-Time Analysis" Kluwer Academic Publishers 1994.
[KS 98] C. Kaiser, C. Santellani, « Pétrarque. Plate forme d’expérimentation pour l’ordonnancement
adaptatif temps réel strict d’applications réparties », Revue Technique et Science Informatique,
1998, 25 p., (à paraître).
[KSY 84] : J. Kurose, M. Schwartz & Y. Yemini, « Multiple-access protocols and time-constrained
communication », Computing Surveys, 16(1), pp. 43-70, march 1984.
[Lam 78] : L. Lamport, « Time, Clocks and Ordering of Events in Distributed Systems », Comm. of
ACM, vol. 21, n°7, pp. 558-565, 1978.
[Let 92]: P. Leterrier, "Le protocole FIP", Centre de compétence de FIP, Nancy, 1992.
[LL 73]: C. L. Liu, J. W. Layland - Scheduling Algorithms for Multiprogramming in a Hard Real-
Time Environment- Journal of the ACM, Vol. 20, n°1, pp. 46-61, 1973.
[LR 94]: G. Le Lann & N. Rivierre, " Real-time communications over broadcast networks: the CSMA-
DCR and the DOD-CSMA-CD protocols", RTS'94, pp.67-84, 11-14 jan. 1994, Paris (France).
3619
Bibliographie
[Mam 97] : Z. Mammeri, « Réseaux et Temps Réel - Ordonnancement de Messages », Actes de l’Ecole
d’Eté Temps réel, pp. 62-79, 22-26 sept. 1997, Poitiers (France).
[Mar 94]: P. Martineau, "Ordonnancement en ligne dans les systèmes informatiques temps réel", thèse de
doctorat, LAN, Ecole centrale de Nantes, 1994.
[MZ 95]: N. Malcolm, W. Zhao, "Hard real-time communication in multiple-access networks", Real-
Time Systems, Kluwer Academic Publisher, 8(1), 35-77, jan. 1995.
[NFa 90]: FIP bus for exchange of information between transmitters, actuators and programmable
controllers, data link layer, NF C46-603, june 1990.
[Roz 91]: M. Rozier, « Construction des systèmes d’exploitation répartis », INRIA Collection
didactique, chapitre 10, Rocquencourt, France, 1991.
[SC 95]: S. Saad, F. Cottet, " Synthèse bibliographique sur le réseau de terrain FIP, Comparaison avec
les autres réseaux à protocole déterministe", RR. 95003, LISI, ENSMA, 44p., 1995.
[SJ 87]: K.C. Sevcik, M.J. Johnson, "Cycle time properties of the FDDI token ring protocol", IEEE
Trans. on Soft. Eng., 13(3), 376-385, 1987.
[Son 96]: Y. Q. Song, "Performance Analysis of Periodic and Aperiodic Real-Time Message
Transmission in FIP Networks", Proc. of the 9th Inter. Conf. on Parallel and Distributed
Computing Systems, pp. 499-506, sept. 1996, Dijon(France).
[SR 91]: J. A. Stankovic & K. Ramamritham, « The Spring Kernel: A New Paradigm for Real-Time
Systems », IEEE Software, May 1991, pp. 62-72.
[SRL 90]: L. Sha, R. Rajkumar, J. Lehoczky, « Priority inheritance protocols: an approach to real-time
synchronisation », IEEE Transaction Computers, Vol. 39 n°9, pp. 1175-1185, 1990.
[SS 96a]: F. Simonot, Y. Q. Song, "Real-time communicating using TDMA-based multi-access protocol",
Computer Communications (à paraître).
[SS 96b]: Y. Song, F. Simonot, "Messages scheduling in FDDI for real-time communication", RTS'96
actes de conférences, 287-301, Paris, Jan. 1996.
[SSB 97]: Y. Q. Song, F. Simonot-Lion, P. Belissent, "Validation des applications temps réel distribuées
autour du réseau CAN à l'aide de l'évaluation de performances", RTS'97, pp. 243-260, Paris,
jan. 1997.
[SSL 89]: B. Sprunt, L. Sha, J. Lehoczky, « Aperiodic Task Scheduling for Hard Real Time Systems »,
Real Time Systems, Vol. 1, pp. 27-60, 1989.
3 611
[Sta 89] : J. A. Stankovic, « Decentralised Decision Making for Task Reallocation in Hard Real-Time
Systems » , IEEE Trans. On Comp., Vol. C-38, n°3, pp. 341-355, 1989.
[TB 94]: K. Tindell, A. Burns, "Guaranteeing message latencies on Control Area Network (CAN)", 1st
International CAN Conference, Maintz (Germany), sept. 1994.
[TBW 95]: K. Tindell, A. Burns, J. Wellings, " Analysis of real-time communications", J. of Real Time
Systems 9, pp. 147-171, 1995.
[TH 95]: K. Tindell, H. Hansson, "Real-Time Systems and Fixed Priority Scheduling", Report of Uppsala
Univ., oct. 1995.
[Tho 93] : J. P. Thomesse, « Le réseau de terrain FIP », Réseaux et Informatique Répartie, Vol. n°3,
1993, pp. 287-321.
[ZB 95]: S. Zhang, A. Burns, "Guaranteeing synchronous message sets in FDDI networks", DCCS'95,
107-112, Toulouse(France), sept. 1995.
[Zim 81 et al.]: H. Zimmerman, J. S. Banino, A. Caristan, M. Guillemont & G. Morisset, «Basic concepts
of the support of distributed systems: the Chorus approach », Proc. 2nd Conf. Distributed
Computing Systems, apr. 1981, pp. 60-66.
[ZR 87]: W. Zhao & K. Ramamritham, « Virtual Time CSMA Protocols for Hard Real-Time
Communication », IEEE Trans. on Soft. Eng., vol. 13, n° 8, pp.938-952, Aug. 1987.
[ZS 95]: Q. Zheng & K. G. Shin, " Synchronous Bandwidth Allocation in FDDI Networks", IEEE Trans.
on Parallel and Distributed Systems, 6(12), 1332-1338, dec. 1995.
[ZSR 90]: W. Zhao, J.A Stankovic & K. Ramamritham, - A Window Protocol for Transmission of
timed-Constrained Messages -IEEE Trans. on Comp., Vol. 39 n° 9, sept. 1990, pp.1186-1203.
[Ray 92] : M. Raynal, « Synchronisation et Etat global dans les Systèmes Répartis », Collection des
Etudes et Recherches d’Electricité de France, Ed. Eyrolles, 1992.
3614
INDEX
A F
algorithme ....................................................... 10 FDDI
d’ordonnancement ................................ 10; 11 Fiber Distributed Data Interface..53; 116; 133
en ligne ....................................................... 11 file de transmission .................................82; 130
hors ligne .................................................... 11 FIP
non préemptif.............................................. 11 Factory Instrumentation Protocol....50; 84; 88
préemptif..................................................... 11
G
application ...................................................... 11
temps réel.................................................... 14 gigue..........................................................43; 83
temps réel répartie....................................... 41 graphe
asynchrone de précédence local .....................................15
message asynchrone.................................... 44
trafic asynchrone......................................... 53 I
informatique
B
temps réel ......................................................7
bande passante .................................. 45; 92; 123
J
C
jeton...................................................46; 53; 130
CAN
Controller Area Network ............ 91; 102; 116 M
caractéristiques médium de communication .....................12; 139
physiques .................................................... 76 modèle temporel
temporelles...................................... 23; 27; 69 de messages .................................................82
charge dynamique ................................. 128; 132 de tâches ..............................................81; 149
consommateur......................................... 51; 106 monoprocesseur.................................................8
contrainte multiprocesseur .................................................9
de précédence.............................................. 10
de temps .......................................... 8; 44; 152 N
contrôle nombre
centralisé ............................................... 46; 50 de changement de contexte........................129
distribué ................................................ 46; 53 de dépassement..........................................129
critères de performance......................... 121; 124 de préemptions ..........................................129
CSMA/DCR d'écrasements.............................................132
Carrier Sense Multiple Access/Deterministic
Collision Resolution ......................... 49; 90 O
D ordonnanceur...................................................10
date de réveil................................................... 10 P
délai paquet ........................................................48; 49
critique .................................................. 14; 18 période.............................................................10
délai précédence
d'accès......................................................... 80 globale ...............................................106; 108
de transmission ..................................... 80; 84 locale ...........................................98; 100; 104
DM priorité.............................................................11
Deadline Monotonic ................................... 23 procédé ............................................................17
durée d’exécution............................................ 10 producteur ...............................................85; 106
E protocole....................................................33; 36
à accès multiple ...........................................44
échange de messages .......................... 5; 84; 149 à pile............................................................39
échéance............................................................ 8 à priorité héritée ..........................................33
ED à priorité plafond .........................................37
Earliest Deadline......................................... 24 d'allocation de ressources ............................33
époque....................................................... 49; 90 de communication .................................12; 45
exécutif pseudo période ................................................28
temps réel...................................................... 9
61 3
R apériodique ................................................. 10
dépendante.................................................. 21
relations de précédence ................................... 29
émettrice ..................................................... 19
répartiteur........................................................ 11
périodique................................................... 10
réseau
réceptrice ...................................... 19; 95; 118
à accès multiple.....................................45; 57
taux
de terrain ..................................................... 50
de réaction ........................................ 127; 132
fiable ......................................................... 150
d'occupation du médium........................... 132
local.......................................................12; 79
d'occupation du processeur....................... 132
ressource
d'utilisation ............................................... 132
critique ........................................................ 19
TDMA
RM
Time Division Multiple Access13; 55; 94; 124
Rate Monotonic........................................... 22
technique
S de compétition ............................................ 44
temps
séquence creux dynamique ...................................... 129
d’ordonnancement....................................... 61
de propagation ...................................... 50; 83
d'exécution .................................................. 11
de réponse d'un message........................... 130
serveur ............................................................ 27
de réponse d'une tâche .............................. 126
à scrutation .................................................. 27
de réponse maximal .................................. 126
ajournable.................................................... 28 de réponse minimal........................... 126; 130
site................................................................... 45 de réponse moyen ............................. 126; 130
station........................................................45; 57
de retard.................................................... 129
synchrone
de retard admissible .......................... 128; 132
message synchrone...................................... 44
de transfert ............................................ 51; 89
trafic synchrone........................................... 53 temps réel
synchronisation application temps réel................................. 14
globale......................................................... 19
exécutif temps réel................................ 10; 32
locale........................................................... 19
message temps réel ..................................... 13
système
système temps réel.................................... 7; 8
réparti .......................................................... 76
trame......................................................... 45; 47
T tranche canal............................................. 50; 90
tâche V
émettrice..............................................84; 100
validité .................................................. 129; 133
indépendante ............................................... 21
tâche
à échéance sur requête................................. 18
361