Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
ENSMA : Ecole Nationale Supérieure de Mécanique et d'Aérotechnique
LISI : Laboratoire d'Informatique Scientique et Industrielle
THESEPour l'obtention du Grade de
Docteur de l'Université de PoitiersECOLE NATIONALE SUPERIEURE de MECANIQUE et d'AEROTECHNIQUE
&
Faculté des Sciences Fondamentales et Appliquées(Diplôme National - Arrêté du 30 mars 1992)
Ecole Doctorale : Sciences Pour l'Ingénieur
Secteur de Recherche : Informatique
Présentée par
Laurent DAVID
Contribution à la gestion de la régularité d'exécution
des tâches d'une application temps réel à contraintes
strictes, dans un contexte d'ordonnancement en ligne.
Directeur de thèse
Pr. Francis COTTET
Soutenue en public le lundi 16 décembre 2002.
Membres du Jury
Rapporteurs : Pr. Claude KAISER, Laboratoire CEDRIC, CNAM, Paris, France.
: MdC. HdR. Isabelle PUAUT, IRISA, Insa de Rennes, France.
Examinateurs : Pr. Francis COTTET, LISI, ENSMA, Poitiers, France.
: Pr. Guy JUANOLE, LAAS, Université Paul Sabatier, Toulouse, France.
: Pr. Nimal NISSANKE, CAFM, South Bank University, Londres, Royaume-Uni.
: MdC. Patrick MARTINEAU, Ecole Polytechnique de l'Université de Tours, France.
2
3
Remerciements
La réalisation d'une thèse est toujours une expérience exigeante. Sa qualité et la moti-
vation avec laquelle on mène cette réalisation dépend pour beaucoup de l'environnement
professionnel et social que l'on côtoie pendant ces trois années. J'ai trouvé au LISI ces
deux aspects, un environnement professionnel de qualité avec du personnel compétent et
disponible, et un environnement social qui permet très vite de tisser des liens de conance,
et d'amitié.
Je tiens avant tout à exprimer mes plus sincères remerciements à mon directeur de thèse,
Francis COTTET, qui m'a permis d'une part de découvrir le monde de la recherche lors de
mon stage de DEA, et qui m'a ré-exprimé d'autre part sa conance pour ces trois années
de thèse. Francis a été pour moi le directeur de thèse idéal : à la fois disponible et attentif
à mes travaux, il a su me donner une liberté d'orientation que j'ai beaucoup apprécié. Je
me suis également beaucoup enrichi de nos nombreuses conversations tant professionnelles
qu'amicales.
Je tiens en second lieu à remercier très chaleureusement le professeur Nimal NISSANKE
de l'Université de South Bank qui m'a accueilli à Londres pendant un peu plus d'un mois
et avec lequel j'ai là encore tissé des liens qui vont au delà du cadre professionnel. Il m'a
permis d'une part de découvrir une autre approche de mes travaux de thèse, et d'autre
part de découvrir le monde de la recherche anglo-saxonne. Je tiens également à remercier
sa famille pour son accueil si chaleureux pendant mon périple britannique.
Je souhaiterais remercier Claude KAISER et Isabelle PUAUT qui ont eu la lourde tâche
de rapporter ma thèse, ainsi que les autres membres du jury, Guy JUANOLE, et Patrick
MARTINEAU qui m'ont fait l'honneur d'accepter d'être examinateurs.
Je voudrais également remercier le directeur de LISI, Guy PIERRA, pour m'avoir ac-
cepté au sein de son laboratoire. Enn, et c'est à mon sens ce qui fait le LISI, je tiens
à exprimer mes plus sincères remerciements aux membres de ce laboratoire. Qu'ils soient
permanents, doctorants, ex-doctorants, ou stagiaires, je les remercie de l'ambiance qu'ils
font régner dans ces murs. Que Yamine, Stéphane, Pascal, Ladjel, Mourad, Micky R., Mi-
cky B., Manu Nicolas, Jéjé, JCP, Gaëlle, Francis J., Fab, Eric, Dago et Christophe soient
particulièrement remerciés pour tous les bons moments passés ensemble.
Mes derniers remerciements et non les moindres, iront à mes proches, et en particulier
à Corinne, qui m'ont toujours apporté leur soutien sans faille. Je les remercie de toute
l'aection et tout l'amour qu'ils m'ont témoignés. J'ai enn une dernière pensée pour mon
grand-père André, à qui je dédie ce mémoire de Doctorat.
4
Table des matières
Notations et Abréviations 11
De l'explication du titre 13
Les contraintes strictes ou molles . . . . . . . . . . . . . . . . . . . . 13
Approche synchrone ou asynchrone . . . . . . . . . . . . . . . . . . . 14
Ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Organisation de ce mémoire . . . . . . . . . . . . . . . . . . . . . . . 16
1 Le contexte de l'étude 17
1.1 Dénitions - Vocabulaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Procédé, système temps réel, capteurs, actionneurs . . . . . . . . . . 17
Interactions périodiques, apériodiques et sporadiques . . . . . . . . . 18
Tâches, conguration de tâches, priorité et préemption, instance . . . 18
Ressources critiques, exclusion mutuelle . . . . . . . . . . . . . . . . . 18
Ordonnancement en ligne, hors ligne, priorité statique ou dynamique 19
Gestion des ressources, interblocage, inversion de priorité . . . . . . . 19
Communications, boîtes aux lettres, rendez-vous . . . . . . . . . . . . 19
Exécutif temps réel, tâches actives et inactives, chien de garde . . . . 20
Sémaphore, routines systèmes, ordonnanceur, granularité, séquenceur 21
Contrainte temporelle, conguration ordonnançable, faute temporelle 22
Période d'étude ou de simulation, séquence d'exécution valide, Gantt 22
Tâche régulière, tâche à contrainte de régularité . . . . . . . . . . . . 22
1.2 Les contraintes temporelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.3 Modèle de tâche périodique & Ordonnancement . . . . . . . . . . . . . . . . 24
1.3.1 Description et dénitions . . . . . . . . . . . . . . . . . . . . . . . . . 24
Durée d'exécution des tâches . . . . . . . . . . . . . . . . . . . . . . . 24
Fenêtre d'exécution, échéance sur requête, départ simultané ou diéré 25
Charge processeur - Critère nécessaire d'ordonnançabilité . . . . . . . 25
1.3.2 Expression des contraintes . . . . . . . . . . . . . . . . . . . . . . . . 26
1.3.3 Ordonnancement des tâches . . . . . . . . . . . . . . . . . . . . . . . 26
1.3.3.1 Algorithme à priorité xe . . . . . . . . . . . . . . . . . . . 27
RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.3.3.2 Algorithme à priorité variable . . . . . . . . . . . . . . . . . 28
6 TABLE DES MATIÈRES
EDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
LL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.3.4 Gestion des contraintes de précédence . . . . . . . . . . . . . . . . . . 29
1.3.5 Gestion des ressources . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.3.5.1 Protocole à héritage de priorité (PHP) . . . . . . . . . . . . 31
1.3.5.2 Protocole à priorité plafond (PPP) . . . . . . . . . . . . . . 31
1.3.5.3 Protocole d'allocation de pile (PAP) . . . . . . . . . . . . . 33
1.4 Dénition de la gigue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.4.1 Gigue de régularité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.4.2 Gigue de bout en bout et gigue de cohésion . . . . . . . . . . . . . . 36
1.5 Les dénitions connues de la gigue . . . . . . . . . . . . . . . . . . . . . . . . 40
1.5.1 La gigue selon Buttazzo . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.5.2 La gigue selon Dinatale, Stankovic & Baruah . . . . . . . . . . . . . . 42
1.5.3 La gigue liée aux incertitudes temporelles matérielles . . . . . . . . . 43
1.5.4 Remarques sur les diérentes dénitions de la gigue . . . . . . . . . . 45
1.6 La gigue : critère d'apparition et conséquences . . . . . . . . . . . . . . . . . 45
1.6.1 Critères favorables à l'apparition de gigue . . . . . . . . . . . . . . . 45
1.6.2 Conséquences de la gigue dans les applications temps réel . . . . . . . 46
1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2 État-de-l'Art 53
2.1 Approche en ligne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.1.1 Ordonnancement à priorité xe . . . . . . . . . . . . . . . . . . . . . 54
2.1.2 Ordonnancement à priorité variable . . . . . . . . . . . . . . . . . . . 56
2.2 Approche hors ligne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.2.1 Méthode du recuit simulé [DiNatale 95] . . . . . . . . . . . . . . . . . 59
2.2.2 Méthodes génétiques [Coutinho 00a, Coutinho 00b] . . . . . . . . . . 60
2.2.3 Méthodes exactes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.3 Modèles de tâches spéciques . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.3.1 Modèle de tâche à distances temporelles contraintes DCTS . . . . . . 61
2.3.2 Modèle de tâche périodique enrichi . . . . . . . . . . . . . . . . . . . 65
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3 Technique de Traitement de la Gigue dans les Systèmes Temps Réel 71
3.1 Méthodologie de traitement de la gigue . . . . . . . . . . . . . . . . . . . . . 72
3.1.1 Principe de désynchronisation . . . . . . . . . . . . . . . . . . . . . . 73
3.1.1.1 Désynchronisation par l'exemple . . . . . . . . . . . . . . . 73
3.1.1.2 Le problème de désynchronisation . . . . . . . . . . . . . . . 73
3.1.1.3 Technique de résolution . . . . . . . . . . . . . . . . . . . . 77
3.1.2 Maintien des relations de précédences . . . . . . . . . . . . . . . . . . 78
Sous DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Sous EDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.1.3 Modication des priorités . . . . . . . . . . . . . . . . . . . . . . . . 79
TABLE DES MATIÈRES 7
En RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
En DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
En EDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.1.4 Test d'ordonnançabilité . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.2 Annulation de la gigue de régularité . . . . . . . . . . . . . . . . . . . . . . . 80
3.2.1 Principe en quatre étapes . . . . . . . . . . . . . . . . . . . . . . . . 80
3.2.2 Cas des tâches indépendantes . . . . . . . . . . . . . . . . . . . . . . 81
3.2.3 Cas des tâches dépendantes . . . . . . . . . . . . . . . . . . . . . . . 82
3.2.3.1 Les diérents types de relation de précédence et les do-
maines d'applications des quatre étapes. . . . . . . . . . . . 82
3.2.3.2 Description détaillée de la technique . . . . . . . . . . . . . 84
3.2.4 Exemple simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.2.5 Exemple complet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Etape 1 : Désynchronisation des dates de première activation . . . . . 90
Etape 2-1 : Prise en compte des précédences pour les ri,1 . . . . . . . 91
Etape 2-2 : Prise en compte des précédences pour les Di . . . . . . . 92
Etape 3 : Changement de priorité des tâches régulières . . . . . . . . 92
Etape 4 : Nouvelles congurations - Test d'ordonnançabilité . . . . . 92
3.2.6 Conclusion : vers une méthode plus exible . . . . . . . . . . . . . . . 93
3.3 Encadrement de la gigue de régularité . . . . . . . . . . . . . . . . . . . . . . 94
3.3.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.3.2 Conséquence sur la gigue de régularité . . . . . . . . . . . . . . . . . 95
3.3.3 Description détaillée de la technique . . . . . . . . . . . . . . . . . . 97
3.3.4 Exemples illustratifs . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Contexte d'ordonnancement DM . . . . . . . . . . . . . . . . . . . . 99
Etape 1 : Désynchronisation des dates de première activation . 99
Etape 2-1 : Prise en compte des précédences pour les ri,1 . . . 99
Etape 2-2 : Prise en compte des précédences pour les Di . . . . 100
Etape 3 : Redénition des délais critiques pour les tâches ré-
gulières . . . . . . . . . . . . . . . . . . . . . . . . 100
Etape 4 : Nouvelle conguration - Test d'ordonnançabilité . . 101
Contexte d'ordonnancement EDF . . . . . . . . . . . . . . . . . . . . 101
Etape 1 : Désynchronisation des dates de première activation . 101
Etape 2-1 : Prise en compte des précédences pour les ri,1 . . . 102
Etape 2-2 : Prise en compte des précédences pour les Di . . . . 102
Etape 3 : Redénition des délais critiques pour les tâches ré-
gulières . . . . . . . . . . . . . . . . . . . . . . . . 103
Etape 4 : Nouvelle conguration - Test d'ordonnançabilité . . 103
3.3.5 Automatisation de la méthode . . . . . . . . . . . . . . . . . . . . . . 103
3.3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.4 Prise en compte de ressources partagées . . . . . . . . . . . . . . . . . . . . . 105
3.4.1 Ressource partagée par deux tâches . . . . . . . . . . . . . . . . . . . 106
Deux tâches régulières R . . . . . . . . . . . . . . . . . . . . . . . . . 106
Deux tâches non-régulières NR . . . . . . . . . . . . . . . . . . . . . 106
Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8 TABLE DES MATIÈRES
Une tâche régulière R et une tâche non-régulière NR . . . . . . . . . 107
3.4.2 Ressource partagée par plusieurs tâches . . . . . . . . . . . . . . . . . 108
Entre plusieurs tâches régulières R . . . . . . . . . . . . . . . . . . . 108
Entre plusieurs tâches non-régulières NR . . . . . . . . . . . . . . . . 108
Entre p tâches régulières R et q tâches non-régulières NR . . . . . . . 108
3.4.3 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.5 Application au contrôle d'autres paramètres . . . . . . . . . . . . . . . . . . 109
3.5.1 Traitement de la gigue de bout en bout . . . . . . . . . . . . . . . . . 110
3.5.1.1 Annulation de la gigue de bout en bout . . . . . . . . . . . 110
3.5.1.2 Encadrement de la gigue de bout en bout . . . . . . . . . . 112
3.5.2 Traitement du temps de réponse . . . . . . . . . . . . . . . . . . . . . 113
Pour une tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Pour une activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Cas DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Cas EDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4 Expérimentations Numériques 121
4.1 Présentation de l'outil de simulations . . . . . . . . . . . . . . . . . . . . . . 121
4.1.1 Module de génération de congurations de tâches . . . . . . . . . . . 121
4.1.1.1 Procédure de génération de congurations . . . . . . . . . . 122
4.1.1.2 Critères favorables à l'obtention de gigue - Observations . . 123
4.1.1.3 Analyse de la gigue obtenue . . . . . . . . . . . . . . . . . . 124
4.1.2 Module de traitement de la gigue . . . . . . . . . . . . . . . . . . . . 126
4.2 Tests d'ecacité de la méthode . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.2.1 Inuence de la charge processeur et de la gigue . . . . . . . . . . . . . 129
4.2.2 Inuence du nombre de tâches régulières . . . . . . . . . . . . . . . . 131
4.2.3 Inuence de l'algorithme d'ordonnancement utilisé . . . . . . . . . . . 131
4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5 Application à l'Expérience du Pendule Inversé 135
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.2 Modélisation du banc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.2.1 Description de la boucle d'asservissement . . . . . . . . . . . . . . . . 138
5.2.2 Détermination de la loi de commande . . . . . . . . . . . . . . . . . . 139
Etude théorique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Développement-Tests dans l'environnement LabviewTM . . . . . . . . 141
5.3 L'application temps réel de contrôle du pendule . . . . . . . . . . . . . . . . 142
5.3.1 Spécications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Généralités sur la méthode SART . . . . . . . . . . . . . . . . . . . . 142
Illustration sur l'application de contrôle du pendule . . . . . . . . . . 142
5.3.2 Méthode de conception DARTS [Gomaa 84] . . . . . . . . . . . . . . 144
5.4 L'ordonnancement des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . 145
TABLE DES MATIÈRES 9
5.4.1 Détermination des paramètres temporels . . . . . . . . . . . . . . . . 146
La durée d'exécution des tâches . . . . . . . . . . . . . . . . . . . . . 146
Les dates de première activation, les délais critiques et les périodes . 149
5.4.2 Contrôle de la gigue . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.4.2.1 Interprétation des chronogrammes WindView . . . . . . . . 152
5.4.2.2 Calcul de la gigue des tâches . . . . . . . . . . . . . . . . . 153
5.4.2.3 Technique de contrôle de la gigue . . . . . . . . . . . . . . . 154
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Conclusion générale 159
Références bibliographiques 169
Publications liées à ce mémoire de thèse 171
A Résolution du problème de désynchronisation 173
B Etude mécanique du pendule inversé 177
B.1 Détermination des équations selon le principe des puissances virtuelles et des
équations de Lagrange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
B.2 Détermination des contraintes de temps à respecter . . . . . . . . . . . . . . 180
Contrainte temporelle liée aux butées . . . . . . . . . . . . . . . . . . 180
Contrainte temporelle liée à la chute du pendule . . . . . . . . . . . . 181
C Présentation de VxWorksTM et de son EDI TornadoTM 183
C.1 Caractéristiques de VxWorksTM . . . . . . . . . . . . . . . . . . . . . . . . . 183
Gestion des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Gestion du temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Gestion des interruptions . . . . . . . . . . . . . . . . . . . . . . . . . 186
Détails de quelques primitives utilisées . . . . . . . . . . . . . . . . . 187
Implémentation d'une boîte aux lettres sous VxWorksTM avec syn-
chronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
C.2 Le développement d'applications temps réel avec Tornado/VxWorksTM . . . 189
C.2.1 Les communications cible-serveur : généralités . . . . . . . . . . . . . 190
Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Principe général de mise en place . . . . . . . . . . . . . . . . . . . . 190
C.2.2 Création d'un noyau VxWorksTM et mise en place des communica-
tions cible-serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Création d'une disquette de boot . . . . . . . . . . . . . . . . . . . . 191
Création d'un noyau VxWorksTM - Démarrage du Target Server . . . 193
C.2.3 Exemples d'outils bien utiles . . . . . . . . . . . . . . . . . . . . . . . 194
10 TABLE DES MATIÈRES
D Résumé en langue anglaise.
A l'attention du membre du Jury anglophone. 195
D.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
D.2 Denitions of Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
D.2.1 Regularity Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
D.2.2 End-to-End Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
D.3 Approach to Controlling Regularity Jitter . . . . . . . . . . . . . . . . . . . 199
D.3.1 General scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
D.3.2 Release date desynchronization . . . . . . . . . . . . . . . . . . . . . 201
D.3.3 Precedence Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
D.3.4 Priority Redenition . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
D.4 Elimination of Regularity Jitter . . . . . . . . . . . . . . . . . . . . . . . . . 203
D.4.1 The Case of Independent Tasks . . . . . . . . . . . . . . . . . . . . . 203
D.4.2 The Case of Dependent Tasks . . . . . . . . . . . . . . . . . . . . . . 204
D.4.3 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
D.4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
D.5 Regularity jitter bounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
D.5.1 Result on Regularity Jitter . . . . . . . . . . . . . . . . . . . . . . . . 210
D.5.2 The technique through an example . . . . . . . . . . . . . . . . . . . 210
D.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Liste des tableaux 213
Liste des gures 219
Index 223
Notations et Abréviations
- et : représentent les opérateurs partie entière supérieure et partie entière infé-
rieure,
- [|ri,k, ei,k|] (intervalle d'entiers) : kième fenêtre d'exécution de la tâche τi,
- ∆si,k = si,k+1 − si,k,- ∆ei,k = ei,k+1 − ei,k,- τi, avec i ∈ 1, 2, ... : désigne une tâche temps réel,
- τNR : désigne une tâche non régulière (elle ne possède pas de contrainte de régularité
d'exécution),
- τR : désigne une tâche régulière (elle possède des contraintes de régularité d'exécution),
- ∧ : a ∧ b : opérateur donnant le plus grand diviseur commun entre l'entier a et l'entierb (pgcd(a, b)),
- N : l'ensemble des entiers naturels positifs ou nul,
- N∗ : l'ensemble des entiers naturels positifs non nuls,
- Z/pZ avec p entier positif non nul : l'ensemble des p classes d'équivalence distinctes,
généralement notées−0, ...,
−p, pour qui
−k avec k ∈ 0, ..., p représente l'ensemble des
entiers multiples de k,
- a : désigne une activité, séquence de tâches toutes supposées (dans ce mémoire) de
même période,
- Ci : durée d'exécution de la tâche τi,
- Di : délai critique de la tâche τi,
- di,1 = di = ri,1 +Di : date de première échéance de la tâche τi,
- di,k, avec k ∈ 1, 2, ... : date de la kième échéance de la tâche τi,
- ei,k, avec k ∈ 1, 2, ... : date de la kième n d'exécution de la tâche τi,
- E1 : ensemble des tâches de R qui ne sont pas impliquées dans une relation de précédence
(cf. gure 3.10 en page 84),
- E2 : ensemble des tâches de NR qui ne sont pas impliquées dans une relation de précé-
dence (cf. gure 3.10 en page 84),
- E3 : ensemble des tâches de R qui sont impliquées dans une relation de précédence (cf.
gure 3.10 en page 84),
- E4 : ensemble des tâches de NR qui sont impliquées dans une relation de précédence
(cf. gure 3.10 en page 84),
- jsi,k(jei,k
) : pourcentage de gigue de régularité locale entre l'instance k et l'instance
k + 1 de la tâche τi, basée sur les débuts d'exécution (les ns d'exécution),
12 Notations et Abréviations
- JMoy(τi) : pourcentage moyen de gigue de régularité de la tâche τi,
- Jmax(τi) : pourcentage maximum de gigue de régularité de la tâche τi,
- JMoy(a) : pourcentage moyen de gigue de bout en bout de l'activité a,
- JMoy,c(τi) : pourcentage moyen de gigue de cohésion de la tâche τi,
- H = ppcm(Ti) : période d'étude en régime stationnaire (motif indéniment répété lors
de la phase d'exploitation de l'application temps réel, constituée de n tâches périodiques),
- mod : l'opérateur mathématique modulo,
- NR : l'ensemble des tâches dont l'exécution strictement régulière n'est pas nécessaire
(tâches non régulières),
- nE = card(E) : cardinal d'un ensemble E quelconque,
- PEPS : abréviation désignant la politique de gestion d'une le d'attente de type "pre-
mier entré, premier sorti" (FIFO),
- ppcm(Ti) = ppcmT1, ..., Tn : plus petit commun multiple des entiers T1, ..., Tn,- Prioi : priorité xe de la tâche τi,
- P1 : τR → τNR, P2 : τR → τR, P3 : τNR → τNR, P4 : τNR → τR : relations de
précédence liant des tâches de R et des tâches de NR,
- ri,1 ou ri : date de première activation de la tâche τi,
- ri,k, avec k ∈ 1, 2, ... : kième date d'activation de la tâche τi,
- R : l'ensemble des tâches à contraintes de régularité d'exécution (tâches régulières),
- si,k, avec k ∈ 1, 2, ... : date du kième début d'exécution de la tâche τi,
- Ti : période de la tâche τi,
- TRk(a) : kième temps de réponse d'une activité a, déni comme la durée séparant le
début d'exécution de la kième instance de la première tâche, et la n d'exécution de
la kième instance de la dernière tâche formant l'activité (les périodes des tâches sont
supposées identiques : TRk(a) = ei,k−sj,k avec i et j désignant la première et la dernière
tâches de l'activité),
- TRTh(a) : temps de réponse théorique d'une activité a, donné par exemple par des
considérations d'automatique,
- trk(τi) = si,k − ri,k : kième temps de réponse de la tâche τi,
- ui : charge processeur de la tâche τi,
- U : somme des charges processeur de toutes les tâches formant l'application,
- Wi : largeur maximum des fenêtres d'exécution de la tâche τi,
De l'explication du titre
Les systèmes informatiques temps réel sont aujourd'hui présents dans de nombreux
secteurs d'activités : dans l'industrie de production par exemple, au travers des systèmes
de contrôle de procédé, dans les salles de marché au travers du traitement des données
boursières en "temps réel", dans l'industrie du transport au travers des systèmes de pilotage
embarqués, ou encore dans le secteur de la nouvelle économie au travers du besoin, toujours
croissant, du traitement et de l'acheminement de l'information (vidéo, données, pilotage à
distance, réalité virtuelle, etc.). Ces systèmes informatiques temps réel se diérencient des
autres systèmes informatiques par la prise en compte de contraintes temporelles qui, si elles
ne sont pas respectées, peuvent conduire à des situations critiques, voire catastrophiques.
C'est en partie pour cela que dans le cycle de développement d'une application temps réel,
un important travail de vérication et de validation, est nécessaire pour armer qu'aucune
situation critique grave ne se produira pendant la phase d'exploitation.
Les contraintes strictes ou molles
Dans le vaste ensemble des applications de tels systèmes, on distingue les applications
temps réel à contraintes strictes, considérées comme critiques, et les applications temps réel
à contraintes molles.
Dans le premier cas, les contraintes doivent absolument être respectées pour éviter une
catastrophe. Citons comme domaine d'exploitation pour ces applications, les applications
temps réel embarquées (transports aérien, ferroviaire et automobile), les applications de
contrôle des réacteurs nucléaires, les applications de robotique en environnement sensible,
etc.. Un dysfonctionnement lors de l'exploitation de telles applications peut avoir des consé-
quences terribles en terme de coût, ou pire, en terme de vies humaines.
Dans le second cas, on raisonne plus en terme de qualité de service : le fonctionnement
de l'application temps réel peut se dégrader dans une certaine mesure, en ne provoquant
qu'une diminution de la qualité de fonctionnement de l'application. Citons comme exemples
les applications multimédia, avec notamment le traitement et l'acheminement de l'image :
une dégradation temporaire de l'image ne se traduit que par une baisse du confort de
l'utilisateur. Citons comme autres exemples les systèmes de type radar, pour lesquels le
nombre d'objet à observer et à pister à chaque instant, peut varier en grande proportion et
donc faire varier d'autant la charge processeur. Dans une telle situation, une dégradation
temporaire de la position des objets peut être envisagée an de pouvoir traiter un plus
grand nombre d'objets.
Dans ces travaux de thèse, nous nous intéressons aux systèmes à contraintes strictes.
14 De l'explication du titre
Approche synchrone ou asynchrone
Une autre classication des systèmes temps réel se situe au niveau de l'implémentation
même de l'application. On distingue ainsi les systèmes synchrones, basés sur les événements,
et les systèmes asynchrones, basés sur une horloge.
Les systèmes synchrones répondent à des événements extérieurs par la traduction dans
un premier temps de ces événements en interruptions systèmes, et génèrent dans un second
temps un signal de commande ou une action, approprié(e). Dans cette démarche, on fait
l'hypothèse que pendant le traitement d'un événement, on écarte toute éventualité d'oc-
currence d'un autre événement : en d'autres termes, on ne peut suspendre le traitement en
cours. Il est alors nécessaire que les durées de traitement soient les plus petites possibles an
d'éviter qu'un traitement lent et peu important n'accapare la ressource processeur. C'est
la seconde hypothèse relative à ces systèmes, à savoir l'instantanéité des exécutions. Enn,
comme le système ne prend en compte l'arrivée d'un événement qu'à la n du traitement
en cours, on considère que les événements qui sont arrivés pendant le traitement, si court
soit-il, sont tous simultanés. Il s'agit alors d'un événement à part entière dont le traitement
est spécique.
Cette démarche synchrone est intéressante dans la mesure où les traitements n'ont pas
d'inuence mutuelle. Ainsi, le problème d'accès à des ressources partagées ne se pose pas.
Cette démarche a cependant ses limites, notamment dans la validation des hypothèses.
L'instantanéité des exécutions n'est pas toujours possible, puisque le découpage de l'appli-
cation de contrôle du procédé ne peut pas toujours conduire à des traitements de durée
d'exécution inme. En outre, dans un cadre multiprocesseur, les hypothèses sont dici-
lement applicables sauf à utiliser un mécanisme non trivial de synchronisation entre les
processeurs.
Pour répondre aux applications temps réel pour lesquelles ces hypothèses ne peuvent
être formulées, il existe les systèmes asynchrones dont l'architecture se base sur les pulsa-
tions régulières d'une horloge, caractérisant en fait les points d'interaction possibles sur le
traitement en cours. Au lieu d'employer le terme traitement, on utilisera dans la suite de
ce mémoire le terme de tâche temps réel, ou plus simplement de tâche. Ces tâches dans
l'hypothèse asynchrone sont d'une durée non nulle, et des mécanismes de préemption de la
tâche en cours d'exécution peuvent être mis en place. En eet, l'importance ou la priorité
de la tâche nouvellement arrivée, peut nécessiter son exécution immédiate de la part du
système pour assurer un bon fonctionnement (en terme de stabilité, ou en terme de réponse
adéquate à la dynamique du procédé contrôlé).
Ces deux types d'architecture peuvent en pratique coexister et on parle alors de systèmes
hybrides. Ces systèmes ont chacun leurs avantages et leurs inconvénients. Dans un contexte
de système temps réel complexe, réparti ou non, on préfère généralement l'approche asyn-
chrone à l'approche synchrone en raison de ses hypothèses restrictives. Néanmoins, dans
d'autres contextes, la simplicité de mise en ÷uvre de l'approche synchrone peut être un
atout. Dans le contexte toujours de système complexe, l'approche asynchrone est cepen-
dant reconnue comme étant plus robuste. En eet, dans la phase de conception intervient
la phase dite d'ordonnancement des tâches au terme de laquelle on valide a priori la phase
d'exploitation de l'application.
Dans ces travaux de thèse, nous nous situons dans l'hypothèse asynchrone.
De l'explication du titre 15
Ordonnancement
Une application temps réel asynchrone est donc classiquement découpée en un ensemble
de tâches qui doivent être exécutées par un ou des processeur(s). Ce "parallélisme de concep-
tion" exprime en fait l'idée qu'un système temps réel contrôle le plus souvent un procédé,
qui par essence, possède des comportements (ou évolutions) qui interviennent de manière
parallèle. Ces tâches, qui concourent au contrôle du procédé, ont une exécution éminemment
concurrente, et donc donnent lieu au choix d'une méthode d'ordonnancement, au cours de
laquelle, on dénit l'ordre d'exécution des tâches sur le ou les processeur(s).
Deux grands types de méthodes sont distingués : les méthodes d'ordonnancement en
ligne, et les méthodes d'ordonnancement hors ligne. Dans les premières, un algorithme
d'ordonnancement désigne à chaque instant pendant la phase d'exploitation, la tâche la
plus prioritaire à exécuter. Dans les secondes, l'ordre d'exécution des tâches est calculé
avant la phase d'exploitation et cet ordre est restitué tel quel pendant l'exécution de l'ap-
plication temps réel. Le mécanisme d'aectation des priorités se base le plus souvent sur
les paramètres temporels des tâches, qui modélisent en partie les spécications temporelles,
comportementales et structurelles du système temps réel. L'algorithme d'ordonnancement
dans le cas en ligne, ou la séquence d'exécution dans le cas hors ligne, doit conduire au
respect de l'ensemble de ces spécications, souvent évoquées sous le terme de contraintes
temporelles.
Les résultats de ces travaux de thèse s'appliquent au contexte de l'ordonnancement
en ligne en environnement mono-processeur.
Problématique
Plusieurs types de contraintes temporelles peuvent être distingués : les contraintes de
respect des échéances, à rapprocher avec la notion de temps de réponse, les contraintes de
précédences qui dénissent le plus souvent le passage d'une donnée d'une tâche à l'autre,
ou encore les contraintes de régularité d'exécution d'une tâche. Ces dernières contraintes
sont présentes généralement dans les tâches d'interfaçage entre le système numérique et
l'environnement qu'il contrôle (procédé). Ces tâches peuvent être par exemple des tâches
d'acquisition de données, ou des tâches de commande (PID, régulation, asservissement,
etc...). Selon les principes généraux du traitement des signaux, ces tâches doivent être
exécutées de manière périodique, voire strictement périodique, ceci an d'avoir une bonne
transmission de l'information entre le système numérique (à temps discret) et le procédé
physique (à temps continu). Dans un contexte d'exécutions concurrentes comme le temps
réel, ceci n'est pas toujours le cas, on parle alors de gigue temporelle.
Les techniques d'ordonnancement pouvant gérer les contraintes temporelles du type
échéance et du type régularité d'exécution, sont principalement des techniques hors lignes.
Il en existe très peu pour le contexte en ligne, surtout si on doit prendre en considération
des tâches temps réel dépendantes des unes des autres (communications, synchronisations,
etc.). En outre, les méthodes d'ordonnancement en ligne (RM, DM, EDF) sont aujourd'hui
principalement orientées "respect des échéances", laissant de côté, par exemple, le respect
des contraintes de régularité d'exécution.
Le but de cette thèse est donc de proposer une technique d'ordonnancement dans le
contexte en ligne permettant le respect à la fois des échéances temporelles, mais aussi des
16 De l'explication du titre
contraintes de régularité d'exécution. Ces travaux prennent en compte un cadre général
d'application temps réel, dans lequel les communications se traduisent par des relations
de dépendance entre les tâches. La technique d'ordonnancement proposée va de la simple
annulation de la gigue temporelle (strict respect des contraintes de régularité) jusqu'à l'en-
cadrement de celle-ci (qualité de service).
Organisation de ce mémoire
Dans le chapitre suivant, nous présentons plus en détail le contexte de ces travaux,
et nous introduisons formellement la notion de gigue temporelle. Nous comparons égale-
ment notre dénition de la gigue à celles déjà connues, en soulignant leur limite ou leur
équivalence.
Dans le chapitre 2 "État-de-l'Art", nous répertorions les principales méthodes d'ordon-
nancement existantes permettant la prise en compte des contraintes de régularité d'exécu-
tion. Nous en soulignons les limites pour le contexte de nos travaux.
Dans le chapitre 3, nous présentons en détail notre technique d'ordonnancement permet-
tant dans le contexte en ligne, de maîtriser les problèmes de gigue des tâches périodiques
possédant des contraintes de régularité d'exécution, tâches qui seront désignées par la suite
par le terme de "tâches régulières". Après la présentation d'une méthodologie de traitement
de la gigue, nous appliquons ces outils au cas d'applications temps réel simples, puis étape
par étape, nous prenons en compte des descriptions plus générales pour nous rapprocher
d'une application temps réel plus complexe.
Dans le quatrième chapitre, nous montrons au travers de simulations numériques l'intérêt
et l'ecacité de notre technique pour divers contextes d'utilisation.
Enn, dans le chapitre précédent la conclusion de ces travaux, nous présentons la mise
en ÷uvre pratique et complète de notre technique au travers de la réalisation d'une appli-
cation temps réel de contrôle d'un pendule en position inversée, sur l'exécutif temps réel
VxWorksTM . Ce banc d'essai a en eet l'avantage de présenter à la fois des contraintes
d'échéances mais aussi des contraintes de régularité d'exécution.
Les trois premières annexes viennent compléter ce mémoire : une annexe présente en
détail un des outils utilisés dans la technique de traitement de la gigue ; une autre présente
une étude de mécanique du pendule inversé, et une dernière enn, propose une présentation
plus complète du noyau temps réel VxWorksTM et de son environnement de programmation
associé TornadoTM . Une quatrième annexe, en langue anglaise, intègre l'article présenté à
la conférence RTSS'01.
Chapitre 1
Le contexte de l'étude
Ce chapitre présente dans un premier temps les dénitions et le vocabulaire utilisés dans
ce mémoire. Nous décrivons dans un deuxième temps, les diérents types de contraintes tem-
porelles que nous pouvons rencontrer dans la réalisation d'une application temps réel. Puis
nous introduisons le modèle de tâche périodique et les techniques d'ordonnancement en ligne
associées, qui peuvent être utilisés pour exprimer en partie les spécications comportemen-
tales et structurelles de l'application. En marge de ces techniques, nous présentons aussi les
mécanismes classiques permettant de gérer les contraintes de précédence et le partage de
ressources critiques. Nous dénissons ensuite la notion de gigue temporelle, en comparant
nos dénitions à celles déjà connues. Enn, nous donnons quelques critères favorables à
l'apparition de gigue et nous présentons des conséquences possibles de la gigue pour une
application temps réel.
1.1 Dénitions - Vocabulaire
Procédé, système temps réel, capteurs, actionneurs
Une application temps réel communique classiquement avec un procédé [CNRS 88]. Ce
procédé peut être un avion, un réacteur de centrale nucléaire, ou encore pour le domaine
du multimédia, un lm en cours de lecture, avec notamment les problèmes de détérioration
des signaux dès lors que le réseau est trop sollicité. Un système temps réel peut alors être
considéré comme un ensemble constitué d'un système informatique contrôlant et d'un pro-
cédé contrôlé, communiquant entre eux par l'intermédiaire de capteurs et d'actionneurs.
Les capteurs renseignent le système informatique sur l'état statique et dynamique du pro-
cédé, et les actionneurs transforment en actions (physiques) les commandes numériques du
système informatique (cf. gure 1.1). Le système temps réel se distingue d'un système in-
formatique de contrôle par la nécessité d'avoir une vitesse de prise de décisions adaptée à
la vitesse d'évolution du procédé. En d'autres termes, et contrairement à la première idée
qu'on se fait d'un système temps réel, un tel système n'est pas nécessaire rapide, il doit en
fait pouvoir réagir, observer et prendre une décision relativement à la vitesse d'évolution
du procédé, le temps réel devient alors un temps relatif.
18 Le contexte de l'étude
Fig. 1.1: Un système temps réel. Les actionneurs agissent sur le procédé, les cap-
teurs renseignent sur le procédé. La vitesse de prise de décisions par le système
informatique doit être adaptée à la vitesse d'évolution du procédé.
Interactions périodiques, apériodiques et sporadiques
L'interaction entre le système informatique et le procédé peut se faire de manière pério-
dique, apériodique ou sporadique. L'acquisition d'une donnée physique nécessite par exemple
un échantillonnage périodique du signal analogique. La gestion d'une situation d'alarme va
plutôt faire appel à des interactions apériodiques. Enn, dans le dernier type d'interac-
tion, sporadique, la durée entre deux interactions est bornée par un minimum. Comme
exemple d'applications, citons les interactions liées à des capteurs qui ne se déclenchent que
sous certaines conditions "anormales" (enregistrement vidéo, sismographe, etc.). Sous ces
conditions, on peut supposer que le capteur ne peut être sollicité au delà d'une certaine
fréquence : la durée entre deux interactions est donc bornée par un minimum.
Tâches, conguration de tâches, priorité et préemption d'une tâche, instance
Tout procédé possède par essence des comportements (ou évolutions) qui interviennent
de manière parallèle. En se basant sur cette observation, une application temps réel (asyn-
chrone) est classiquement découpée en un ensemble de tâches informatiques qui représentent
chacune un ensemble d'instructions devant être exécutées par une ou des ressource(s) pro-
cesseur(s). On emploie d'ailleurs souvent le terme de conguration de tâches pour désigner
une application temps réel. S'agissant de contrôler un procédé qui est dynamique, il faut que
les ressources processeurs soient en priorité destinées aux tâches les plus importantes à l'ins-
tant considéré. On parle alors de priorité entre les tâches. Une tâche en cours d'exécution
peut ainsi se voir écartée de la ressource processeur pour une autre tâche plus prioritaire :
on parle dans ce cas de préemption de la tâche par la tâche plus prioritaire. L'exécution de
la tâche préemptée peut néanmoins reprendre lorsqu'aucune tâche de plus grande priorité
ne requiert la ressource processeur.
Dans le cadre de tâche périodique, l'exécution de la tâche devant intervenir plusieurs
fois, on désigne une exécution de la tâche, par le terme instance. Ainsi pour désigner la
kième exécution de la tâche, on préfère utiliser l'expression "la kième instance" de la tâche.
Ressources critiques, exclusion mutuelle
Notons également qu'outre la ressource processeur, certaines tâches partagent des res-
sources dites critiques, dont l'accès n'est autorisé qu'à une seule tâche à la fois. On parle
alors d'accès en exclusion mutuelle. Une ressource peut être par exemple un module de
données dans lequel, pour des raisons de cohérence de données, l'accès en écriture est en
exclusion mutuelle.
1.1 Dénitions - Vocabulaire 19
Ordonnancement hors ligne, en ligne, paramètres temporels, priorité statique
ou dynamique
L'exécution concurrente des tâches peut conduire aux non respect de certaines contrain-
tes xées dans le cahier des charges. C'est pourquoi avant la phase d'exploitation de l'ap-
plication temps réel un travail de validation en terme d'ordonnancement des tâches est
eectué. L'ordonnancement consiste à dénir l'ordre d'exécution des tâches pendant la
phase d'exploitation de l'application. Cet ordre peut être préétabli et xe, on parle alors
de méthode d'ordonnancement hors ligne car l'ensemble des calculs d'ordonnancement est
mené avant l'exécution. Cet ordre peut être déterminé également pendant l'exécution, via
l'utilisation d'un algorithme d'ordonnancement . Cet algorithme désigne à chaque instant
la tâche la plus prioritaire en fonction de paramètres temporels caractérisant les tâches.
On parle dans ce cas de méthode d'ordonnancement en ligne. Dans ces deux stratégies, les
priorités des tâches peuvent être xes, c'est-à-dire constantes au cours de la vie de la tâche,
ou bien variables et elles évoluent au cours du temps.
Gestion des ressources, interblocage, inversion de priorité
Pour la gestion des ressources, un certain nombre de protocoles existent pour éviter
le phénomène dit d'interblocage. En eet, dans le cadre des méthodes d'ordonnancement
préemptif, si deux tâches partagent les mêmes ressources critiques, l'ordre de prise et de
libération de ces ressources doit faire l'objet d'une validation, sans quoi, on peut aboutir
au blocage de l'exécution des deux tâches, l'une demandant la ressource que la seconde
possède et qu'elle n'a pas encore libérée.
Un autre phénomène connu qui va souvent de pair avec la gestion de ressources est le
phénomène d'inversion de priorité, dont le principal inconvénient est d'apporter de l'indé-
terminisme dans le temps de réponse d'une tâche, avec un éventuel dépassement d'échéance.
Il y a inversion de priorité lorsqu'une tâche de grande priorité requérant une ressource, est
obligée d'attendre qu'une tâche de priorité moyenne termine son exécution, an qu'une tâche
de faible priorité, préemptée par la tâche de priorité moyenne, puisse, par son exécution,
libérer la ressource critique, qui est alors attribuée à la tâche de grande priorité. La mission
du robot d'exploration de la surface martienne en 1997 a d'ailleurs subi un incident logiciel
(redémarrage du système) à cause d'une inversion de priorité [Wilner 97, Cottet 99, Sha 90].
Communications asynchrones, synchrones, boîtes aux lettres, rendez-vous
L'ensemble des contraintes du cahier des charges peut requérir des communications entre
les tâches. On distingue ainsi les communications asynchrones et synchrones.
Pour les communications asynchrones, on utilise une zone de mémoire partagée qu'on
qualie de boîte aux lettres. Une tâche émettrice place en eet dans cette mémoire une
donnée, qui sera ensuite récupérée par une tâche réceptrice. L'ordre d'arrivée et l'ordre de
sortie des données se fait suivant la règle "premier entré, premier sorti" (PEPS - First In
First Out : FIFO). Une boîte aux lettres peut être bloquante ou non bloquante. Pour le
premier cas, comme la taille de la mémoire partagée est bornée et comme chaque donnée
déposée dans la boîte aux lettres doit être récupérée, on peut rencontrer une situation de
boîte aux lettres pleine, mettant alors la tâche émettrice en attente : elle est dite bloquée
20 Le contexte de l'étude
(cf. gure 1.2). A contrario, dans le cas d'une boîte aux lettres non bloquante, on va perdre
la donnée entrée le plus tôt, libérant une place en entrée pour la nouvelle donnée. On parle
dans ce cas de boîte aux lettres à écrasement (cf. gure 1.2).
Les communications synchrones entre les tâches, souvent désignées par les communica-
tions sur rendez-vous, peuvent en fait être implémentées via l'utilisation de deux boîtes aux
lettres. Ce type de communication consiste en une synchronisation des deux tâches pour
par exemple, l'échange d'une donnée.
Fig. 1.2: Les deux types de boîtes aux lettres (BAL) : bloquante ou à écrasement.
Exécutif temps réel, tâches actives et inactives, chien de garde
L'exécutif temps réel désigne le système d'exploitation temps réel qui doit gérer :
• l'ensemble des tâches,
• les ressources partagées par les tâches (processeur, ressources critiques, etc.),
• les communications entre les tâches,
• l'ensemble des événements matériels (interruptions systèmes) et logiciels (synchronisa-
tion).
La gestion des tâches s'eectue suivant la politique d'ordonnancement retenue qu'elle
soit hors ligne ou en ligne. Pendant la phase d'exploitation du système temps réel, les tâches
temps réel formant l'application passent ainsi par divers états. On distingue les tâches
actives, qui ont été activées, des tâches endormies ou inactives en attente d'activation,
on parle également de tâches suspendues. A noter que pour une tâche dite périodique, ces
activations interviennent de manière périodique. Parmi les tâches actives on distingue un
certain nombre d'états. Prenons par exemple le cas de l'exécutif temps réel VxWorksTM de
la société WindRiver [WindRiver 99]. Pendant la phase d'exploitation de l'application, une
tâche peut être :
• prête à être exécutée, elle n'attend que la ressource processeur,
1.1 Dénitions - Vocabulaire 21
• retardée pour une certaine durée,
• bloquée pour cause de non disponibilité d'une ressource,
• ou en cours d'exécution.
L'enchaînement de ces états et l'action associée au passage d'un état à l'autre sont reportés
dans la gure 1.3. Dans cette gure, les transitions désignées par "Abandon" et par les
èches en pointillés, représentent des routines spéciques à VxWorksTM , qui peuvent être
appelées par des tâches de plus grande priorité (par exemple, une tâche d'ordonnancement)
ou qui peuvent être appelées après le réveil d'un chien de garde (watchdog) dont le délai
(timeout) aurait expiré. Ces chiens de garde représentent des compteurs (watchdog timers)
qui sont initialisés à une certaine date, et qui, lorsqu'ils atteignent une date échéance, font
appel à une fonction pour suspendre généralement une tâche bloquée. Soulignons néan-
moins que du point de vue théorique, ces transitions doivent faire l'objet d'une attention
particulière, car elles sont en dehors des schémas classiques de l'ordonnancement des tâches,
et rendent plus dicile la phase de validation. D'ailleurs, l'utilisation sous VxWorksTM de
ces compteurs requiert une programmation spécique (cf. annexe C).
Fig. 1.3: Les états possibles des tâches et les transitions entre ces états.
Sémaphore, routines systèmes, ordonnanceur, granularité, séquenceur
Pour la gestion des ressources, l'exécutif temps réel s'appuie généralement sur la notion
de sémaphore. Un sémaphore fonctionne sur le principe d'un distributeur de jetons : s'il
reste des jetons, on peut accéder à la ressource, sinon on se met en attente jusqu'au moment
où un jeton est rapporté, permettant alors l'accès à la ressource. Le sémaphore binaire est
22 Le contexte de l'étude
un cas particulier de sémaphores : il possède un seul jeton. Le sémaphore permet également
la gestion des boîtes aux lettres et donc des communications entre les tâches.
L'exécutif temps réel doit par ailleurs gérer un ensemble de routines systèmes, qui sont
des tâches à part entière mais dont la priorité est généralement très grande par rapport aux
tâches de l'application temps réel. Se basant sur les pulsations régulières d'une horloge, un
exécutif temps réel doit par exemple gérer le temps : généralement, il fait appel à intervalle
régulier à un ordonnanceur qui choisit alors la tâche la plus prioritaire à exécuter, selon la
méthode d'ordonnancement choisie. La durée séparant deux appels consécutifs de l'ordon-
nanceur est désignée par le terme granularité de l'ordonnanceur ou par le terme quantum de
temps. Les points de préemption éventuelle des tâches sont alors séparés de la même durée.
A noter que pour certains noyaux, l'ordonnanceur peut ne prendre le contrôle qu'au début
ou à la n des tâches, et dans ce cas, la granularité de l'ordonnanceur dépend de leur durée
d'exécution. Suivant la politique d'ordonnancement retenue, l'ordonnanceur, pour indiquer
la tâche la plus prioritaire, ira ensuite de la simple consultation d'une mémoire, appelée
séquenceur , jusqu'au calcul de la priorité basé sur les paramètres temporels des tâches.
Contrainte temporelle, conguration de tâches ordonnançable, faute temporelle
Ces paramètres temporels représentent en partie l'expression de contraintes compor-
tementales et structurelles provenant de la phase de spécications, qui sont généralement
désignées par le terme de contraintes temporelles. Nous décrirons ces paramètres temporels
dans la section suivante. Lors de la phase d'ordonnancement, une conguration de tâches
est dite ordonnançable, s'il existe une disposition des tâches en terme d'exécution, condui-
sant au respect de l'ensemble des contraintes temporelles. Si une tâche ne respecte pas
une de ses contraintes, on parle alors de faute temporelle : la validation temporelle a alors
échoué. A noter qu'on suppose toujours dans cette étude que l'application temps réel a été
validée d'un point de vue fonctionnel (c'est-à-dire que le code est juste par rapport aux
spécications, et qu'il est sans bogue).
Période d'étude ou de simulation, séquence d'exécution valide, diagramme de
Gantt
Lorsqu'une politique d'ordonnancement en ligne ou hors ligne arrive à ordonnancer
une conguration de tâches (au sens respect des échéances), on dit alors qu'elle fournit
une séquence d'exécution valide de l'ensemble des instances des tâches. En outre, dans le
cadre de tâches périodiques, cette séquence peut être considérée comme un motif répété
indéniment pendant toute la phase d'exploitation. La durée de ce motif a fait l'objet de
nombreux travaux et peut s'exprimer en fonction des périodes des tâches (cf. section 1.4.1
pour détails). Cette durée est appelée période d'étude ou période de simulation, durée sur
laquelle on mène l'étude d'ordonnançabilité. La représentation de cette séquence sur la
période d'étude sous forme d'un chronogramme est appelée un diagramme de Gantt .
Tâche régulière, non régulière, tâche à contrainte de régularité
Les tâches d'une application temps réel, sur lesquelles des contraintes de régularité
d'exécution sont spéciées, seront désignées par la suite par le terme de tâches régulières,
1.2 Les contraintes temporelles 23
ou par le terme de tâches à contrainte de régularité. A contrario, les tâches qui ne possèdent
pas de telles contraintes seront nommées tâches non régulières. Notons que le terme "tâche
régulière" peut prêter à confusion car du point de vue sémantique, ou pourrait considérer
une tâche dont l'exécution est régulière tout en ne possédant pas de contrainte de régularité
d'exécution. Le contexte des paragraphes dans lesquels ce terme sera employé, permettra
par la suite de lever l'ambiguïté.
1.2 Les contraintes temporelles
Un des aspects des systèmes informatiques qui est souvent occulté, mais qui doit dans
certains cas, faire l'objet d'une attention particulière, concerne le problème de l'identica-
tion de l'échelle de temps continue, à l'échelle de temps discrète de l'horloge du système
numérique. Dans son article [Törngren 98], Törngren met ainsi en exergue les problèmes des
systèmes numériques de contrôle. Il observe alors que la communauté "temps réel" a souvent
privilégié une approche événementielle (synchrone) avec la prise en compte d'échéances, ou
encore de contraintes de temps de réponses. Depuis le début des années 90 cependant, des
contraintes temporelles autres que celles du temps de réponse, font l'objet de nombreux
travaux. Travaux qui conduisent peu à peu à la mise en place d'une théorie de l'ordon-
nancement des tâches temps réel qui s'avère très intéressante du point de vue de l'analyse
temporelle. Törngren [Törngren 98] souligne cependant que les signaux traités par les sys-
tèmes numériques de contrôle sont inévitablement entachés de phénomène de latence ou de
gigue. Quand la latence mesure le temps écoulé entre l'arrivée d'un événement extérieur et
sa prise en compte par le système, la gigue quant à elle, apprécie la variation de la périodicité
d'une tâche répétitive. Dans la dénition de [IEEE Editions 92], les auteurs considèrent la
gigue comme des "time-related, abrupt, spurious variations in the duration of any specied
related interval", à savoir des variations temporelles brusques et non prévues dans la durée
d'un intervalle quelconque. Aussi, pouvons-nous également considérer la gigue comme une
mesure de la variation de la latence. Törngren distingue au nal trois types de contraintes
temporelles : la période d'une tâche périodique, son temps de réponse, et l'intervalle de
uctuation possible de l'exécution, en d'autres termes, la gigue.
Bate et Burns [Bate 99] ont récemment rassemblé l'ensemble des contraintes de temps
possibles d'un système temps réel. Il se distingue ainsi deux types de contraintes, les unes
s'appliquant sur une tâche, et les autres s'appliquant sur ce qu'on appelle une activité, qui
est en fait dénie comme l'enchaînement de plusieurs tâches, type contrôle - traitement
- commande par exemple. Ainsi, pour une tâche temps réel, nous avons un ensemble de
quatre contraintes temporelles :
la période, qui caractérise le temps minimum pour la tâche entre deux demandes
successives du processeur,
le délai critique, qui caractérise à partir du réveil de la tâche, le délai au terme duquel
l'exécution de la tâche doit être terminée (ceci dans le cadre du temps réel à contraintes
strictes),
la gigue, qui caractérise les variations d'exécution possibles de la tâche par rapport à
sa périodicité,
et enn la contrainte de séparation qui spécie la durée minimum séparant les débuts,
24 Le contexte de l'étude
ou les ns d'exécution de deux instances successives d'une même tâche.
Concernant les activités, séquence de tâches exécutées dans un ordre xé, Bate et al.
[Bate 99] identient trois contraintes temporelles :
la période, qui peut être identique à celles de l'ensemble des tâches formant l'activité :
dans ce cas elles sont dépendantes les unes des autres ; ou bien, la période peut être
dénie comme le ppcm1 des périodes de ces mêmes tâches,
le délai critique de bout en bout de l'activité, que nous pouvons également considérer
comme le temps de réponse de l'activité,
et enn, la gigue de bout en bout , souvent spéciée lorsque les tâches de l'activité
participent à des acquisitions ou des commandes. Cette gigue joue un rôle important
dans la caractérisation du temps de réponse de bout en bout du système.
Une autre contrainte qui est implicite avec la notion d'activité, concerne la notion de
précédence. Cette contrainte peut être qualiée de simple, et dans ce cas les périodes des
tâches de l'activité sont identiques. Elle peut aussi être qualiée de généralisée quand ces
mêmes périodes sont diérentes les unes des autres [Richard 00].
Ces contraintes de temps identiées, il faut maintenant dénir un modèle de tâche dans
lequel les attributs de ce modèle pourront traduire l'ensemble de ces contraintes. C'est le
modèle de tâche périodique que nous utilisons dans ce mémoire.
1.3 Modèle de tâche périodique & Ordonnancement
1.3.1 Description et dénitions
C'est le modèle de tâche le plus classique, basé sur l'article de Liu et Layland [Liu 73],
il décrit une tâche τi au travers de quatre paramètres temporels que sont :
• sa première date d'activation notée ri,1 (ou ri), que nous appelons aussi, par simplica-
tion, date d'activation de la tâche τi,
• sa durée d'exécution maximale notée Ci,
• son délai critique noté Di, délai au terme duquel l'exécution de la tâche doit être
terminée pour qu'elle respecte son échéance, sans quoi on parle de faute temporelle,
• et enn sa période Ti, qui caractérise la période avec laquelle les instances de la tâche
sont activées.
On dénit en outre la première échéance notée di,1, par di,1 = ri,1 +Di (cf. gure 1.4),
qu'on peut également désignée par le terme d'échéance et qu'on note alors di. A noter que
pour la kième instance de la tâche τi, on dénit sa date d'activation par ri,k = ri,1 + kTi etson échéance par di,k = di,1 + kTi.
On décrit de plus par si,j et par ei,j , les dates eectives de début et de n d'exécution
de la jième instance de τi.
Durée d'exécution des tâches
La détermination de la durée d'exécution d'une tâche est cruciale pour la validation
temporelle de l'application. Cette détermination est pour autant une étape très délicate,
1ppcm représente le plus petit commum multiple.
1.3 Modèle de tâche périodique & Ordonnancement 25
tant à cause de l'aspect matériel que de l'aspect logiciel [Puschner 00]. Le matériel actuel
apporte en eet bien souvent des mécanismes d'accélération du traitement informatique,
et ce, au détriment du déterminisme temporel : citons par exemple les mémoires caches
[White 97], les processeurs avec pipelines [Zhang 93] et les processeurs à prédiction de
branchement [Colin 00]. L'aspect logiciel concerne quant à lui le code même des tâches :
des boucles ou des branches conditionnelles à l'intérieur de ce code peuvent en eet donner
des durées d'exécutions non identiques d'une exécution d'une instance à l'autre.
Ces deux aspects conduisent nalement les concepteurs d'application temps réel à consi-
dérer des situations de pire cas, et c'est donc la pire durée d'exécution Ci des tâches qui est
prise en compte dans la phase de l'analyse de l'ordonnancement. Si la durée d'exécution de
la tâche s'avère plus courte pendant la phase d'exploitation, un mécanisme d'attente peut
être mis en place pour considérer toujours une durée d'exécution constante de la tâche.
Cette solution a néanmoins le désavantage de ne pas optimiser l'utilisation de la ressource
processeur, mais elle permet de valider formellement l'ordonnancement, étape essentielle-
ment pour des applications temps réel critiques, celles à contraintes strictes.
Fenêtre d'exécution, tâches à échéance sur requête, à départ simultané ou diéré
En se basant sur l'ensemble des paramètres des tâches, on peut introduire quelques dé-
nitions. On désigne par exemple les fenêtres d'exécution de τi par les intervalles [|ri,k; ei,k|]avec k ∈ N
∗. Lorsqu'on parle d'une tâche τi à échéance sur requête, on suppose que Ti = Di.
Les tâches sont à départ simultané si pour l'ensemble des tâches τi, on a ri,1 = 0. Dans lecas où une tâche ne respecte pas cette dénition, on parle de tâches à départ diéré.
Fig. 1.4: Le modèle de tâche périodique.
Charge processeur - Critère nécessaire d'ordonnançabilité
La charge processeur U requise par un ensemble de n tâches formant une application
temps réel est dénie par la relation :
U =
n∑k=1
uk =
n∑k=1
Ck
Tk. (1.1)
Cette dénition conduit immédiatement à une condition nécessaire pour l'ordonnancement
des tâches, il faut que U ≤ 1 dans le contexte d'un système à un seul processeur, hypothèse
dans laquelle nous nous plaçons dans ce mémoire.
26 Le contexte de l'étude
1.3.2 Expression des contraintes
Après la période et le délai critique qui sont des contraintes explicites du système (Ti etDi), nous pouvons dénir des contraintes supplémentaires. Les contraintes de gigue portent
sur la régularité de l'écart entre les débuts ou les ns d'exécution de deux instances succes-
sives d'une tâche. On compare ainsi le rapport entre si,k+1 − si,k et Ti, ou entre ei,k+1 − ei,ket Ti. La contrainte de séparation impose quant à elle une borne minimum à respecter pour
si,k+1 − si,k ou pour ei,k+1 − ei,k.Pour l'expression des contraintes sur les activités, considérons une activité de type ac-
quisition, traitement, commande, dénie par 3 tâches : τa, τt et τc, de période respective
Ta, Tt et Tc. La période de l'activité est soit T = Ta = Tt = Tc (tâches dépendantes), ousoit T = ppcm(Ta, Tt, Tc). Le délai critique de bout en bout d'une activité n'est dénie
que dans le cas de tâches dépendantes, et toujours avec notre exemple, le délai critique Da
doit être tel que : ∀k ∈ N, ec,k − ra,k ≤ Da. En d'autres termes, la durée séparant la n
d'exécution de la tâche τc et l'activation de la tâche τa, doit être bornée par un maximum.
Sur le même principe que la gigue d'une tâche, la gigue d'une activité porte sur l'écart entre
ec,k − sa,k et une valeur de référence ec,ref − sa,ref , qui peut être dénie par des contraintesde maintien de la stabilité du procédé.
Les contraintes de précédence ne sont pas directement liées aux paramètres temporels
des tâches. En revanche, les précédences peuvent se traduire par le choix d'une combinaison
particulière sur les paramètres temporels. Pour chaque algorithme d'ordonnancement, le
respect de certaines relations de type "inéquation" appliquées aux dates d'activation et
aux délais critiques des tâches, permettent en eet le respect des précédences. Les auteurs
de [Blazewicz 76] et [Chetto 90] ont d'ailleurs présenté une technique de modication des
paramètres des tâches aboutissant au respect de ces contraintes.
1.3.3 Ordonnancement des tâches
Comme nous l'avons souligné dans l'introduction, il existe deux approches pour l'or-
donnancement des tâches. On distingue ainsi l'approche en ligne, basée sur une attribution
xe [Liu 73, Leung 82, Audsley 91] ou variable des priorités des tâches du système [Dertou-
zos 74, Labetoulle 74, Dertouzos 89]. A chaque instant, c'est à la tâche de plus forte priorité
qu'est attribué le processeur. On distingue aussi l'approche hors ligne qui se base sur une
construction a priori d'une séquence d'ordonnancement valide [Xu 92, Grolleau 99a].
Chaque approche présente des avantages et des inconvénients :
• Il existe ainsi des algorithmes d'ordonnancement en ligne optimaux dans certains con-
textes lorsque les tâches sont indépendantes (pas de contraintes de précédence) [Der-
touzos 74, Labetoulle 74, Dertouzos 89]. Des tests analytiques simples permettent ainsi
de conclure à l'ordonnançabilité de tels systèmes lorsque les tâches sont à départ simul-
tané [Liu 73, Baruah 90, Audsley 91]. A noter que dans le cadre des tâches à départ diéré
à priorité xe, seule l'aectation des priorités suivant l'algorithme d'Audsley [Audsley 91]
permet de donner une condition nécessaire et susante d'ordonnançabilité (aectation
cependant réalisée en temps exponentiel). L'introduction de protocoles de gestion de
ressources par les auteurs de [Sha 90, Chen 90, Baker 91], a également permis de préci-
ser des conditions susantes d'ordonnançabilité dans le cadre des tâches partageant des
1.3 Modèle de tâche périodique & Ordonnancement 27
ressources.
• Lorsqu'aucun des critères susants d'ordonnançabilité n'est respecté, on peut alors
faire appel à des techniques d'ordonnancement hors ligne. Les auteurs de [Choquet-
Geniet 96, Grolleau 99b] proposent par exemple une recherche exhaustive de toutes les
séquences d'exécution possibles, permettant alors de choisir celle qui correspond le mieux
au respect de telle ou telle contrainte temporelle.
Dans notre étude, nous nous plaçons dans l'approche en ligne, et nous décrivons dans
cette section les diérents algorithmes d'ordonnancement qui seront utilisés par la suite.
En fonction des paramètres temporels des tâches actives, ces algorithmes attribuent le
processeur à la tâche la plus prioritaire an de produire une séquence d'exécution valide
(respect de la contrainte "échéance").
1.3.3.1 Algorithme à priorité xe
Les priorités des tâches sont xes au cours de la phase d'exploitation. En fonction de
ces priorités, l'ordonnanceur attribue le processeur à telle ou telle tâche. Dans le cas d'une
égalité entre les priorités, il est d'usage de dénir pour chaque tâche, en plus de leurs
paramètres temporels, une priorité xe qui est unique parmi l'ensemble des tâches.
Priorité donnée par la période de la tâche : RM. L'algorithme d'ordonnancement
RM, pour rate monotonic est présenté dans [Liu 73]. L'aectation des priorités est dénie
selon la règle suivante : la priorité de la tâche est d'autant plus forte que sa période est
petite.
Dans le cadre de n tâches indépendantes à échéance sur requête et à départ simultané,
il existe un critère susant d'ordonnançabilité [Liu 73] : il sut que la charge processeur Usoit strictement inférieure au seuil déni par n(21/n − 1), seuil qui tend vers ln(2) lorsquen tend vers l'inni. Toujours avec les mêmes hypothèses, les auteurs de [Lehoczky 89]
proposent également un critère nécessaire et susant d'ordonnançabilité.
Cet algorithme RM a été prouvé optimal [Liu 73] pour des tâches périodiques indépen-
dantes à échéance sur requête et à départ simultané. Ainsi, si une conguration de tâches
est ordonnançable suivant des priorités xes, elle est alors ordonnançable avec RM.
RM peut être très intéressant dans le cadre de conguration de tâches dont le nombre
évolue au cours de la phase d'exploitation. En eet, disposant d'un critère nécessaire et
susant d'ordonnançabilité, la question de l'ordonnançabilité après l'ajout ou le retrait
d'une tâche peut être traitée rapidement.
Priorité donnée par le délai critique de la tâche : DM. L'algorithme d'ordonnance-
ment DM, pour deadline monotonic est présenté dans [Leung 82]. L'aectation des priorités
est dénie selon la règle suivante : la priorité de la tâche est d'autant plus forte que son
délai critique est petit. Dans le cadre de tâches à échéance sur requête (Ti = Di), DM et
RM sont donc équivalents.
Il existe également pour DM une condition nécessaire et susante d'ordonnançabilité
dans le cadre de tâches périodiques indépendantes et à départ simultané [Lehoczky 91]. DM
est par ailleurs optimal dans le cadre d'aectation statique de priorités pour des tâches à
28 Le contexte de l'étude
départ simultané [Leung 82]. Dans le cas de tâches à départ diéré, Audsley dans [Aud-
sley 91] a complété ce résultat en proposant un algorithme d'aectation optimal de priorité
statique, qu'on peut étendre d'ailleurs au cas Di > Ti (cas écarté dans ce mémoire).
De la même façon que pour RM, disposant d'un critère d'ordonnançabilité, il est rela-
tivement simple d'implémenter un algorithme d'acceptation ou de suppression d'une tâche
conservant l'ordonnançabilité de la conguration.
1.3.3.2 Algorithme à priorité variable
Les priorités des tâches évoluent ici au cours de la phase d'exploitation. Dans le cas
d'une égalité entre les priorités, on peut se rapporter aux priorités xes dénies de manière
unique pour l'ensemble des tâches, mais il est d'usage de continuer d'abord, si elles existent,
les tâches suspendues.
Priorité donnée par l'échéance de la tâche : EDF. EDF, pour earliest deadline rst,
qui signie "l'échéance la plus proche en premier" est un algorithme qui attribue la priorité
la plus grande à la tâche dont l'échéance est la plus proche de l'instant considéré.
[Dertouzos 74, Labetoulle 74] ont montré que cet algorithme est optimal dans le contexte
de tâches indépendantes. Un critère nécessaire et susant pour l'ordonnançabilité est connu
pour des tâches à départ simultané [Liu 73] et à échéance sur requête. Ce critère est très
simple puisqu'il s'agit de vérier que la charge processeur U soit inférieure ou égale à 1.La puissance d'ordonnançabilité d'EDF est plus grande que RM et DM. Cet algorithme
a néanmoins quelques inconvénients : il est très peu robuste dans le cas du dépassement
d'échéance d'une tâche. En eet dans une telle hypothèse, beaucoup de tâches vont dépasser
leur échéances par un eet en chaîne. Dans notre contexte néanmoins, celle du temps réel
stricte, cette hypothèse est écartée : toutes les tâches doivent respecter leurs échéances.
L'implémentation de EDF est plus coûteuse que les algorithmes d'ordonnancement à priorité
xe mais reste raisonnable : l'ordonnanceur ne doit en eet recalculer la priorité des tâches
dans la le d'attente que lors d'une nouvelle arrivée de tâche et non à chaque instant. Il
existe enn un résultat sur le nombre total de préemption sous EDF, il est en eet inférieur
au double du nombre total d'instances [Baruah 99, Liu 73].
Priorité donnée par la laxité de la tâche : LL. La laxité L est dénie comme la
durée séparant l'échéance de l'instant considéré, mais en soustrayant la durée d'exécution
restante de l'instance de la tâche. Plus formellement, si t désigne l'instant considéré, on
a : Li,k(t) = di,k − Ci(t) − t. Cette durée correspond en fait au temps libre restant avant
d'exécuter la tâche sans faute temporelle. L'algorithme LL, pour "Least Laxity", la plus
petite laxité, attribue la priorité la plus grande à la tâche de plus petite laxité.
Dans le cas de tâche à échéance sur requête et à départs simultanés, le critère nécessaire
et susant pour l'ordonnançabilité est le même que pour EDF : U ≤ 1.Cet algorithme est optimal dans le contexte de tâches indépendantes [Mok 83, Dertou-
zos 89]. EDF et LL ont donc la même puissance d'ordonnançabilité dans ce contexte. Cet
algorithme se distingue de EDF par la production de séquences dans lesquelles le nombre
de changement de contexte est plus élevé, et par une implémentation plus coûteuse, car les
laxités des tâches doivent être recalculées à chaque instant. Les temps de réponse moyens de
1.3 Modèle de tâche périodique & Ordonnancement 29
tâches ordonnancées avec LL, sont également plus grands que les temps de réponse moyens
de tâches ordonnancées avec EDF [Grolleau 99a].
1.3.4 Gestion des contraintes de précédence
La contrainte de base d'une activité consiste en l'exécution d'une séquence de tâches dans
un ordre prédéni, ordre qui est respecté par l'application de contraintes de précédence. En
général, les tâches mises en jeu sont dépendantes les unes des autres et ont donc toutes une
même période T qui est alors aussi celle de l'activité : on parle de contraintes de précédence
simple. Cependant, on peut aussi considérer des activités dont les tâches s'exécutent à
des périodes diérentes, ce sont alors des contraintes de précédence généralisée. L'échange
de données entre les tâches peut alors faire appel à des mémoires tampons dimensionnées
par rapport à la diérence des périodes et par rapport à la quantité de donnée qui doit
transiter [Gerber 94]. La période de l'activité correspond dans ce cas au ppcm des périodes
de ces tâches. Dans cette étude, nous faisons l'hypothèse de tâches dépendantes dont les
périodes sont toutes identiques.
Le modèle de tâche périodique ne permet pas directement de modéliser les diérents
type de communications entre les tâches. Rappelons que les communications synchrones
peuvent être modélisées par des communications asynchrones, et que celles-ci sont généra-
lement réalisées via l'utilisation de boîtes aux lettres. Le principe permettant de gérer les
communications entre les tâches, est basé sur le principe du découpage en forme normale.
On considère pour cela une tâche dont le code associé fait appel à des boîtes aux lettres
pour des échanges de données. On découpe alors (cf. gure 1.5) cette tâche en un ensemble
de sous-tâches reliées par des contraintes de précédence. C'est en fait ces "sous"-tâches que
nous considérons par la suite : on ne fera d'ailleurs plus la distinction, c'est-à-dire qu'on se
placera dans une phase d'ordonnancement où l'on considérera un ensemble de tâches dont
certaines seront liées par des relations de précédence.
Fig. 1.5: Découpage d'une tâche qui dépose un message dans une boîte aux
lettres, en deux sous-tâches reliées par une contrainte de précédence.
Dans un contexte en ligne, les contraintes de précédence sont gérées par une redénition
des attributs temporels des tâches. Cette redénition peut se faire de deux façons : soit on
recherche les conditions minimales à vérier pour que les contraintes de précédence soient
respectées [Blazewicz 76], soit on ane ces conditions pour caractériser en fait les plus petits
intervalles d'exécution possibles les tâches [Chetto 90]. Dans ce dernier cas, Chetto et al.
montrent l'équivalence en terme d'ordonnançabilité entre la conguration initiale de tâches
sur lesquelles des contraintes de précédence sont spéciées, et la conguration nale où les
30 Le contexte de l'étude
nouveaux attributs temporels des tâches respectent les conditions décrites dans [Chetto 90],
conditions qui portent sur les délais critiques et les dates d'activation.
Avec l'algorithme d'ordonnancement EDF par exemple, si trois tâches τ1, τ2 et τ3 sont
liées par une relation de précédence du type τ1 → τ2 → τ3, Chetto et al. restreignent alors
l'intervalle d'exécution des tâches, en dénissant de nouvelles dates d'activation r∗2 et r∗3, et
de nouvelles échéances d∗2 et d∗1. Ces paramètres temporels sont tels que :
r∗2 = max(r2, r1 + C1)
r∗3 = max(r3, r∗2 + C2)
d∗2 = min(d2, d3 − C3)
D∗1 = min(d1, d
∗2 − C2)
de sorte que τ1 (respectivement τ2), le prédécesseur de τ2 (respectivement τ3) ait le temps
de s'exécuter entièrement avant le début d'exécution de τ2 (respectivement τ3), et que τ3(respectivement τ2), le successeur de τ2 (respectivement τ1), ait le temps de s'exécuter avant
son échéance (cf. gure 1.6). L'ordre de dénitions des paramètres a son importance : pour
les dates d'activation, on commence par les tâches qui n'ont pas de prédécesseur et on
remonte la chaîne ; pour les délais critiques, on part des tâches qui n'ont pas de successeur,
et on descend la chaîne. Cette approche n'a en fait d'intérêt que dans un contexte de
validation pour déterminer l'intervalle minimal d'exécution possible des tâches.
Fig. 1.6: Illustration des formules de redénition des paramètres "date d'ac-
tivation" et "échéance" dans le cadre des conditions de Chetto appliquées au
contexte EDF.
Les formules générales dans le contexte EDF, permettant de gérer les précédences sont
les suivantes :
r∗i = max(ri,maxτj→τi
(r∗j + Cj))
d∗i = min(di, minτi→τj
(d∗j − Cj))
Dans le cadre de notre étude , nous allons choisir les conditions contraignant le moins les
attributs temporels, ainsi, selon [Blazewicz 76], pour que τi précède τj , il sut que :ri,1 ≤ rj,1
Prioi > Prioj(1.2)
où Prioi et Prioj représentent les priorités des tâches τi et τj à l'instant considéré. La
deuxième condition sur les priorités dépend de l'algorithme d'ordonnancement choisi. Cette
condition est triviale dans les cas de RM et DM, et devient dicile à caractériser pour EDF,
nous verrons néanmoins qu'il est possible de la satisfaire dans une objectif de conditions
susantes.
1.3 Modèle de tâche périodique & Ordonnancement 31
1.3.5 Gestion des ressources
Outre les communications entre les tâches, modélisées par des contraintes de précé-
dence, la plupart des applications temps réel utilisent des ressources critiques. Le partage
de ces ressources critiques parmi les tâches formant l'application, doit faire l'objet d'une
attention particulière lors de la phase d'ordonnancement, ceci pour éviter les phénomènes
d'inversion de priorité avec des temps de blocages des tâches non bornés, et les phéno-
mènes d'interblocage. A noter que ces deux phénomènes n'interviennent que dans le cadre
d'ordonnancements préemptifs puisque dans le cadre d'ordonnancements non préemptifs,
l'exclusion mutuelle ne pose pas de problème. Cependant pour améliorer le temps de réponse
des tâches ou pour garantir plus simplement les échéances de certaines tâches, l'hypothèse
de l'ordonnancement préemptif est souvent formulée, ce qui est le cas dans cette étude.
Il existe des méthodes de réservation ou de pré-allocation des ressources critiques pour
éviter ces deux phénomènes. Mais pour gérer de manière ecace le partage des ressources
critiques (taux d'utilisation des ressources acceptable), et pour éviter ces deux phénomènes,
trois protocoles principaux sont connus : nous distinguons le protocole à héritage de priorité,
le protocole à priorité plafond [Sha 90], et le protocole d'allocation de pile [Baker 90,
Baker 91].
1.3.5.1 Protocole à héritage de priorité (PHP)
Dans le protocole PHP, on aecte à la tâche détenant une ressource, la priorité la plus
grande prise parmi les priorités des tâches demandant également cette ressource et qui sont
alors bloquées. Sur l'illustration de la gure 1.7 où les tâches sont ordonnancées suivant
des priorités xes, le premier diagramme de Gantt (a) illustre le cas d'une inversion de
priorité : en eet, la tâche τ2 est retardée dans son exécution par la tâche τ3 de priorité
plus faible. En généralisant cette observation à un nombre plus important de tâche de
priorité intermédiaire, on illustre le problème du temps de réponse non borné avec comme
conséquence un éventuel dépassement d'échéance : c'est ce qui s'est d'ailleurs passé sur le
robot d'exploration PathFinder [Wilner 97, Cottet 99]. Dans le second diagramme (b) de
cette gure, on reprend ces mêmes tâches mais en utilisant le protocole PHP : la tâche τ2n'est plus retardée. La tâche τ4 détenant la ressource, hérite en eet de la priorité de la
tâche τ2 bloquée lors de sa demande de ressource.
Stankovic et al. ont par ailleurs généralisé ce protocole au contexte des priorités variables
[Stankovic 98]. Ce protocole ne prévient pas cependant les interblocages sauf à utiliser un
ordre spécique des prises et des libérations de ressources (méthode des classes ordonnées
ou méthode des demandes emboîtées de ressources, etc.). Lorsque les interblocages sont
évités, les temps de blocage des tâches peuvent en outre être déterminés [Buttazzo 97].
1.3.5.2 Protocole à priorité plafond (PPP)
Ce protocole permet en fait d'éliminer les interblocages sans employer d'ordre spécique
dans les prises et les libérations de ressources. L'idée est d'aecter une priorité plafond à
chaque ressource critique, correspondant à la priorité la plus grande prise parmi les priorités
des tâches devant requérir la ressource.
32 Le contexte de l'étude
Fig. 1.7: (a) : Le phénomène d'inversion de priorité : τ2 est retardée par τ3. (b) :Utilisation du protocole PHP : τ3 ne vient plus retardée τ2.
Ensuite, dans le cas d'un accès à une ressource par une tâche τ quelconque, on va
vérier que la priorité de la tâche est bien supérieure strictement au maximum des priorités
plafonds des ressources qui ont été demandées ou qui sont en cours d'utilisation par des
tâches autres que τ . Dans le cas contraire, la tâche sera bloquée, et la tâche possédant
la ressource va hériter de la priorité de la tâche bloquée. On agit ici en fait de manière
préventive pour éviter les inversions de priorités, en bloquant l'accès aux tâches de faible
priorité par rapport aux priorités plafonds.
Dans l'illustration de la gure 1.8, nous avons d'abord reporté le cas de l'interblocage
(partie (a)) : la tâche τ1 demande en deux instants la ressource R1 et la ressource R2,il en est de même pour la tâche τ2. Quand τ2 demande R2, elle la reçoit. Ensuite τ1 est
activée, de priorité supérieure, donc préempte τ2. Lorsqu'à son tour τ1 demande R1, parl'héritage de priorité, τ3 termine son exécution avec R1, τ3 reprend alors son exécution
jusqu'à sa demande de R2. τ2 par héritage de priorité continue alors son exécution mais
demande nalement R1, qui ne sera libre que si τ1 la libère, ce qui n'est pas possible pourle moment puisque τ1 demande R2 : les deux tâches se bloquent mutuellement et on parle
d'interblocage.
Dans la partie (b) de cette illustration, nous avons mis en place le protocole PPP.
Lorsque que τ2 requiert R2, elle lui est refusée, car la priorité de la tâche τ2 n'est pas
strictement supérieure à la priorité plafond de R1. Lorsque que τ1 requiert R1, elle lui estrefusée, car la priorité de la tâche τ1 n'est pas strictement supérieure à la priorité plafond
1.3 Modèle de tâche périodique & Ordonnancement 33
de R2 (la ressource R1 a été libérée par τ3). L'ordonnancement peut être mené à terme et
le phénomène d'interblocage est éliminé.
Fig. 1.8: (a) : Illustration de l'interblocage. (b) : Utilisation du protocole PPP :
la demande de la ressource R1 par τ1 est refusée car sa priorité n'est pas stric-
tement supérieure à la priorité plafond de R1.
A l'origine, le protocole PPP se restreint aux ordonnancements à priorité xe, mais il
a été étendu à l'algorithme d'ordonnancement EDF, et est appelé dans ce cas protocole
à priorité plafond dynamique PPPD, dans lequel les priorités plafonds sont recalculées
dynamiquement. Il existe par ailleurs des résultats sur les temps de blocage maximum des
tâches partageant des ressources [Sha 90]. Pour EDF, ce calcul dynamique des priorités
plafond n'est pas négligeable, et dans ce cas on lui préfère le protocole d'allocation de pile
PAP présenté succinctement dans le paragraphe suivant.
1.3.5.3 Protocole d'allocation de pile (PAP)
Dans ce protocole [Baker 90, Baker 91], outre la priorité de la tâche, on associe à chaque
tâche un niveau de préemption représenté par un entier π, qui est fonction du temps dont
dispose la tâche pour s'exécuter. On attribue alors à une tâche la ressource demandée si
son niveau de préemption est supérieur au niveau courant du système, niveau qui est en
fait calculé en fonction des disponibilités des ressources du système à l'instant considéré.
Ce qui diérencie les protocoles PPP et PAP, c'est d'abord leur domaine d'application :
PPP ne s'applique qu'à des congurations de tâches périodiques, alors que PAP ne formule
34 Le contexte de l'étude
aucune hypothèse restrictive. Le nombre de préemptions est également diérent : il est plus
important dans le cas PPP que dans le cas PAP, cela à cause du fait qu'une fois l'exécution
de la tâche démarrée sous PAP, les ressources demandées sont toutes attribuées (niveau
de préemption plus important que le niveau courant du système), a contrario sous PPP,
chaque demande d'accès peut être bloquante [Cottet 99].
1.4 Dénition de la gigue
Beaucoup d'exemples de systèmes temps réel comportent des contraintes de régularité
d'exécution : le maintien de la stabilité d'un système de pilotage d'un procédé passe par
une commande stable (au sens période de restitution) des actionneurs, les trames vidéos
des systèmes multimédia doivent être transmises dans des intervalles bornés [Han 96], enn
la manipulation de matières dangereuses par des robots nécessite une bonne transmission
de l'information entre le procédé et le système temps réel [Lin 96]. Un système dont la
régularité d'exécution des tâches le composant, est bien respectée, aura par ailleurs une
tolérance aux fautes plus importante qu'un système supportant les irrégularités d'exécution
[Lin 96]. Les périodes d'échantillonnage et/ou de restitution se doivent donc, sous certaines
conditions et pour des besoins particuliers, d'être précisément respectées. Dans un contexte
d'exécutions concurrentes comme le temps réel, ceci n'est pas toujours le cas. En eet, les
politiques d'ordonnancement, c'est-à-dire les mécanismes avec lesquels on désigne la tâche
qui doit être exécutée par le processeur à un instant quelconque, ne prennent pas en compte
cette contrainte temporelle. Dans la littérature, il existe de nombreux qualicatifs pour
nommer l'irrégularité d'exécution qui en découle. On parle de gigue, de gigue temporelle,
de délais imprévisibles entre deux exécutions, de distances temporelles non constantes,
etc. [Buttazzo 97, DiNatale 95, Lin 96].
Comme nous l'avons souligné précédemment, l'irrégularité d'exécution dans un système
temps réel peut être appréciée au niveau d'une tâche mais aussi au niveau du temps de
réponse d'une activité comportant plusieurs tâches. Dans cette section, nous présentons
donc les deux types de gigues : la gigue de régularité d'une tâche, et la gigue de bout en
bout qui peut se dénir sur un ensemble de tâches formant une activité, ou simplement se
dénir sur une seule tâche, désignant dans ce cas une gigue de cohésion. Dans la gure 1.9,
nous illustrons ces trois types de gigue. Notons en outre que les dénitions de gigue que
nous présentons dans ce mémoire, ne concernent que les aspects de l'ordonnancement : on
ne prend pas en compte par exemple les problèmes d'indéterminisme temporel liés à des
aspects matériels (caches, pipelines, etc.).
1.4.1 Gigue de régularité
Nous allons dans cette section formaliser progressivement la notion de gigue de régula-
rité dont plusieurs appellations sont en outre possibles : gigue de tâche périodique, gigue
d'exécution régulière, etc. La grandeur appréciant la gigue de régularité doit mesurer l'ir-
régularité d'exécution de la tâche considérée (cf gure 1.9-(a)). Considérons pour cela la
durée séparant les débuts d'exécution (respectivement les ns d'exécution) de deux ins-
tances successives d'une même tâche. Cette durée est dénie par la diérence :
1.4 Dénition de la gigue 35
∆si,k = si,k+1 − si,k (resp.∆ei,k = ei,k+1 − ei,k) (1.3)
où k désigne la kième instance. ∆si,k et ∆ei,k tendent vers 0 ou vers 2Ti dans le cas de
tâches à échéance sur requête avec des durées d'exécution négligeables.
Introduisons ensuite :
jsi,k=
|∆si,k − Ti|Ti
100 % (1.4)
qui mesure, en pourcentage par rapport à Ti, l'irrégularité des débuts d'exécution entre la
kième instance et la (k + 1)ième instance :
si la diérence vaut Ti (tâche régulière), alors : jsi,k= 0 %,
si la diérence tend vers 0 ou vers 2Ti (maximum d'irrégularité dans l'exécution),
alors : jsi,k= 100 %.
Nous obtenons bien sûr les mêmes expressions et les mêmes remarques en utilisant ei,k.
Dénition 1.1 Pour la tâche τi, jsi,k(resp. jei,k
) est appelé le pourcentage de gigue
de régularité locale entre l'instance k et l'instance k + 1, basée sur les débuts d'exé-cution (resp. les ns d'exécution).
On peut ensuite dénir la gigue de régularité sur l'ensemble des instances des tâches. In-
troduisons pour cela la période d'ordonnancement, ou période d'étude, qui est donnée pour
une conguration de tâches périodiques à départ simultané par :
H = ppcm(Ti) (1.5)
et, pour des tâches à départ diéré, par :
H ′ ≤ maxi
(ri,1) + 2ppcm(Ti) (1.6)
[Leung 80], [Grolleau 00a], [Grolleau 00b]. Cette période d'étude représente en fait la durée
nécessaire à une simulation d'ordonnancement, en vue de valider temporellement, avant
l'exploitation, l'application temps réel développée. En phase stationnaire toute durée de
Fig. 1.9: Illustration des diérentes types de gigue : (a) Gigue de régularité
dénie pour une tâche - (b) Gigue de bout en bout dénie pour une activité
formée de deux tâches - (c) Gigue de cohésion dénie sur une tâche.
36 Le contexte de l'étude
largeur (H = ppcm(Ti)) est un motif indéniment répété dans la séquence d'ordonnance-
ment.
En rassemblant alors l'ensemble des instances de la tâche τi considérée sur un motif de
durée H , on peut introduire la dénition suivante :
Dénition 1.2 Soit une tâche τi(ri,1, Ci, Di, Ti) dont les débuts d'exécution sont
repérés par si,k (k entier supérieur à 1). Le pourcentage moyen de gigue de régularité
de la tâche τi est caractérisé par :
JMoy(τi) =1
Ni
Ni∑k=1
|∆si,k − Ti|Ti
100 %, (1.7)
où Ni est le nombre de ∆si,k (resp. ∆ei,k) dénis dans une durée de H (cf. l'exemple
de la gure 1.10, Ni = 3).
Partant de la variable jsi,k, plusieurs analyses de la gigue peuvent par ailleurs être
réalisées : par exemple, le pourcentage de gigue maximum, minimum, etc... De plus, les
conventions adoptées dans ce paragraphe peuvent ne pas être adaptées à certains types
d'application : par exemple, les applications où l'on privilégie plus l'arrivée de l'instance
d'une tâche, au plus près de sa date d'activation (faible décalage à l'exécution). Buttazzo
[Buttazzo 97] dénit d'ailleurs la gigue sur ces données (cf. section 1.5.1). Quand notre
gigue de régularité apprécie la régularité d'exécution d'une tâche, d'autres privilégient ainsi
le décalage à l'exécution des instances de cette tâche. Dans des applications de type réseau
par exemple, on utilise plus souvent le critère de pourcentage maximum de gigue. Le choix
entre la gigue moyenne ou la gigue maximum dépend également de l'application : pour une
application critique par exemple, il est généralement décidé de se placer dans une situation
de pire cas avec la gigue maximum de régularité ; pour une application non critique, la gigue
moyenne avec la connaissance de l'écart type peut également sure.
Au travers nos dénitions et l'approche qui leur est associée, nous proposons donc une
solution, parmi d'autres, pour mesurer l'irrégularité moyenne d'exécution d'une tâche, et
ce, sur une durée correspondant à la période d'étude H , représentative d'un motif de réfé-
rence pour la simulation. En outre, dans un contexte d'ordonnancement non préemptif, les
dénitions de gigues de régularité se basant sur si,k ou sur ei,k sont strictement identiques.
Au contraire, dans un contexte préemptif, l'une et l'autre sont distinctes et sont reliées par
la gigue de cohésion d'une tâche que nous allons dénir dans la section suivante. Enn,
dans les chapitres suivants, lorsque nous parlerons de gigue, sauf mention spéciale, nous
entendrons pourcentage moyen de gigue avec la convention des dates de début d'exécution
(équation 1.7, avec ∆si,k au lieu de ∆ei,k).
1.4.2 Gigue de bout en bout et gigue de cohésion
La gigue de bout en bout d'un système temps réel est souvent perçue comme la variance
du temps de réponse du système à un événement. Ce temps de réponse dans notre étude
va concerner le temps qui sépare la prise en compte par une tâche d'un événement, et la n
1.4 Dénition de la gigue 37
du traitement de cet événement par éventuellement, une autre tâche. Tout ce qui concerne
les temps d'acquisition des capteurs, ou les temps de restitution des actionneurs ou encore
les temps d'inertie du procédé contrôlé (inertie thermique, réduction couple moteur, etc.),
n'est pas étudié dans ces travaux et fait appel soit aux caractéristiques du matériel, soit
aux spécialistes du domaine.
Suivant le même principe que celui de la section précédente, il s'agit de dénir la gigue
de bout en bout, qui va apprécier la divergence du temps de réponse par rapport à un temps
de réponse idéal. Elle pourra se dénir sur un ensemble de tâches formant une activité, ou
se dénir sur une tâche, et on parlera dans ce cas de gigue de cohésion. Pour ce qui concerne
la gigue d'activité, on pourra étendre la dénition qui suit à un contexte distribué.
Comparée à la section précédente, pour en arriver à une formule caractérisant la gigue, on
ne va pas mesurer des durées entre deux instances successives d'une même tâche périodique,
mais on va mesurer des durées entre le début d'exécution d'une instance et la n d'exécution
d'une autre instance, instances qui n'appartiennent pas nécessairement à la même tâche.
Ces durées seront par ailleurs notées TRk(a) où a désigne l'activité considérée et k désignele numéro de la durée considérée dans une période d'étude (H). On emploie la notation TRcar ces durées s'apparentent à des temps de réponse. Le temps de réponse d'une instance kd'une tâche τi est en eet communément déni par la diérence tr(τi) = ei,k−ri,k. Dans nosdénitions des temps de réponse pour une activité, nous nous sommes en fait basés sur la
durée qui sépare le début de la prise en compte d'un événement (début de l'exécution d'une
tâche), de la n du traitement de cet événement (n d'exécution d'une tâche). Ce temps de
réponse lié au contexte de l'activité est noté TRk(a), et si l'activité est formée de plusieurs
tâches de même période, on a : TRk(a) = ei,k − sj,k (avec i et j désignant la première et la
dernière tâches de l'activité). Si au contraire, l'activité n'est formée que d'une seule tâche,
on utilise la notation TRk(τi) = ei,k − si,k, qui est à bien diérencier du temps de réponse
classique retenu dans le contexte du temps réel (tr(τi) = ei,k − ri,k).Considérons maintenant une activité a =< τi, τj > constituée pour l'exemple de deux
tâches, dans laquelle les données de sortie de τi peuvent être des données d'entrée de τj . Onveut alors analyser les durées séparant le début d'exécution d'une instance de τi et la n
d'exécution de l'instance de τj qui lui est associée. En eet, il n'est pas nécessaire que τi etτj aient la même période [Bate 99], sauf si les deux tâches sont dépendantes. Dans la gure
1.11-a, nous avons donc pour l'exemple deux périodes diérentes, et pour être le plus à jour
Fig. 1.10: La gigue de régularité.
38 Le contexte de l'étude
possible dans notre traitement des données de τi, on choisit l'instance de τi qui est la plusrécente pour dénir la dernière valeur TR3(a). En résumé, les mesures à rassembler sur une
période d'étude, sont les durées entre le début d'exécution de l'instance la plus récente en
terme d'exécution (avec τi) et la n d'exécution de l'instance qui lui correspond (avec τj)(cf. TRk(a) avec 1 ≤ k ≤ 3 sur la gure 1.11-a).
Fig. 1.11: (a) : Gigue de bout en bout d'une activité a =< τi, τj > (b) : La gigue
de cohésion d'une tâche. Les numéros d'instance de la tâche τi sont précisés.
Concernant maintenant la gigue de cohésion, on se place toujours sur une période d'étude
H , et on rassemble l'ensemble des durées séparant le début d'exécution d'une instance et
sa n d'exécution (cf. TRk(τi) avec 1 ≤ k ≤ 4 sur la gure 1.11-b). Cette gigue de cohésion
revient donc à une gigue d'activité qui n'aurait qu'une tâche.
Nous devons ensuite comparer ces TRk(a) à une valeur de "référence" (théorique), qui
peut être en fait la moyenne arithmétique des TRk(a) mais qui peut aussi être une donnée
provenant du domaine de l'automatique, à savoir, le temps de réponse moyen qui correspond
à un système de commande stable. Notons TRTh(a) cette référence, et considérons alors
l'ensemble des diérences suivantes :
∆k(a) =|TRk(a) − TRTh(a)|
TRTh(a)100 % (1.8)
qui sont en fait les pendants des jsi,kdénis par l'équation 1.4 de la section précédente. On
applique alors le même principe de formalisation et on en vient à la dénition suivante :
Dénition 1.3 Soit une activité notée a =< τ1, ..., τn >. On repère par TRk(a) (kentier supérieur à 1) les durées séparant la n d'exécution d'une instance k de τnet le début d'exécution de l'instance de τ1 la plus récente en terme d'exécution (par
rapport à l'instance k de τn). Le pourcentage moyen de gigue de bout en bout de
l'activité a est caractérisé par :
JMoy(a) =1
Na
Na∑k=1
|TRk(a) − TRTh(a)|TRTh(a)
100 %, (1.9)
où Na est le nombre de durées pouvant être considérées sur une durée de H (cf.
gure 1.11-a, Na = 3)
1.4 Dénition de la gigue 39
Explicitons les bornes minimum et maximum que peut prendre le terme TRk(a) dans lecas de n tâches dépendantes, formant une activité a avec (∀i ∈ 1, ..., n) Ti = T = constante.Le temps de réponse minimum est tel que : TRmin(a) =
∑ni=1Ci (cf. gure 1.12-a avec
n = 3). Le temps de réponse maximum est plus délicat à préciser puisqu'il faut distinguer
le cas de tâches à départ simultané et le cas de tâches à départ diéré (cf. gure 1.12-b avec
n = 3) :
• si les tâches sont à départ simultané, le temps de réponse maximum est alors donné
par : TRmax(a) = T ,
• en revanche, si les tâches sont à départ diéré, le temps de réponse maximum est donné
par une étude de pire cas. On suppose pour cela un début d'exécution de la kième instance
de τ1 dès son activation, et une n d'exécution de la kième instance de τn correspondanten fait à la date r1,k+2 − C1 (cf. gure 1.12-b). Au nal, le temps de réponse maximum
est donné par : TRmax(a) = 2T − C1.
Fig. 1.12: (a) : Temps de réponse minimum pour une activité formée de 3 tâches(b) : Temps de réponse maximum dans le cas de 3 tâches dépendantes.
Dans le cas de la gigue de cohésion, le terme TRTh(a) correspond à la durée Ci et nous
avons la dénition suivante :
Dénition 1.4 Soit une tâche τi, dont les durées séparant le début d'exécution et
la n d'exécution d'une instance k, sont repérées par TRk(τi). On dénit alors le
pourcentage moyen de gigue de cohésion de la tâche τi par :
JMoy,c(τi) =1
Ni
Ni∑k=1
|TRk(τi) − Ci|Ti − Ci
100 % (1.10)
où nous supposons que Ci < Ti. (cf. gure 1.11-b, Ni = 4)
Dans le cas où l'exécution de la tâche τi n'est pas préemptée, c'est-à-dire quand TRk(τi) =Ci, on a alors un pourcentage de 0%. A contrario, quand l'exécution "s'étale" sur toute la
période, on a un pourcentage de 100%.
40 Le contexte de l'étude
On peut en outre faire les mêmes remarques que celles de la section précédente, qui
évoquaient le grand nombre de dénitions possibles pour la gigue et qui précisaient que par
cette présentation, nous voulions donner une approche générale, pouvant être adaptée à des
contextes d'applications temps réel particuliers. Une application temps réel présentant des
tâches devant s'exécuter rapidement dès lors qu'elles débutent leur exécution, favorisera par
exemple le critère de gigue de cohésion (la limite étant le cas d'une tâche non préemptée).
1.5 Les dénitions connues de la gigue
1.5.1 La gigue selon Buttazzo
Buttazzo dans [Buttazzo 97] dénit la gigue relative de début d'exécution d'une tâche
τi (relative release jitter) par l'expression suivante :
JBut−r(τi) = maxk(|(si,k − ri,k) − (si,k−1 − ri,k−1)|) (1.11)
qui représente en fait le maximum de la diérence entre deux décalages2 successifs à l'exé-
cution d'une même tâche τi. Rapprochons cette expression du pourcentage maximum de
gigue de régularité d'une tâche τi déni dans la section 1.4.1, nous avons pour cette gigue
l'expression :
JMax(τi) = maxk(|∆si,k − Ti|
Ti)100 %. (1.12)
Or ∆si,k = si,k+1−si,k = si,k+1−si,k +(ri,k +Ti−ri,k+1) = (si,k+1−ri,k+1)− (si,k−ri,k)+Ti,ce qui conduit à écrire :
JMax(τi) =JBut−r(τi)
Ti100 %. (1.13)
Notre dénition de la gigue maximum de régularité est donc équivalente, à un facteur
multiplicatif près, à celle de Buttazzo. En fait, notre dénition de la gigue se rapporte à un
pourcentage de sorte que si il n'y a pas de gigue, JMax(τi) = 0%, et de sorte que si il y en a :
JMax(τi) ≈ 100%. En outre, d'une manière générale, il est préférable d'éviter de se cantonner
uniquement à des expressions de la gigue sous forme de maximum ou de minimum. Pour
apprécier l'irrégularité d'exécution des instances d'une tâche, une étude statistique, même
simple, procure en eet des conclusions beaucoup plus précises (moyenne, écarts types,
etc.). Imaginons par exemple, une distribution uniforme des irrégularités sur une période
d'étude, sauf en un point particulier : la gigue basée uniquement sur le maximum apportera
dans ce cas une conclusion de grande irrégularité d'exécution, alors que la conduite d'une
étude statistique apportera une conclusion nuancée.
Buttazzo dénit aussi la gigue absolue de début d'exécution d'une tâche τi (absoluterelease jitter) par :
JBut−a(τi) = maxk(si,k − ri,k) −mink(si,k − ri,k), (1.14)
2Le décalage à l'exécution d'une instance k d'une tâche τi est ici déni par la diérence : si,k − ri,k.
1.5 Les dénitions connues de la gigue 41
qui caractérise en fait la diérence entre la durée du plus grand décalage à l'exécution et
la durée du plus petit décalage à l'exécution de la tâche τi. Sur ce même principe, nous
pourrions tenter de dénir une gigue de régularité JMaxMin(τi) par l'expression suivante :
JMaxMin(τi) = Jmax(τi) − Jmin(τi), (1.15)
qui mesurait la diérence, à un coecient multiplicatif près, entre la plus grande durée
et la plus petite durée séparant les débuts d'exécution d'instances successives. Cependant,
analysons en détail cette dénition : les irrégularités mesurées dans JMaxMin(τi) sont en
fait basées sur les quantités jsi,kde l'équation 1.4 qui sont des fonctions croissantes puis
décroissantes de la variable ∆si,k avec une annulation en ∆si,k = Ti (cf. gure 1.13-a).
Ceci doit être comparé à JBut−a(τi) qui se base en fait sur des quantités si,k − ri,k, fonctioncroissante de la variable si,k−ri,k (cf. gure 1.13-b). Quand une diérence entre le maximum
et le minimum, rencontrés dans une distribution de si,k− ri,k est tout à fait justiable, celal'est moins lorsqu'on considère la diérence entre le maximum et le minimum rencontrés
dans une distribution de jsi,k. En eet, on peut imaginer une séquence ayant un même jsi,k
avec des ∆si,k diérents (symétriques par rapport à la droite d'équation ∆si,k = Ti surla gure 1.13-a), conduisant alors à un JMaxMin(τi) nulle alors que l'irrégularité est forte.JMaxMin(τi) est donc nalement une dénition de la gigue de régularité à écarter. An de
comparer JBut−a(τi) à nos dénitions de gigue, revenons aux quantités jsi,kde l'équation 1.4.
Elles sont en fait construites autour de ∆si,k − Ti qui peut s'écrire :
∆si,k − Ti = (si,k+1 − ri,k+1) − (si,k − ri,k), (1.16)
expression à comparer avec JBut−a(τi) (expression 1.14).
Fig. 1.13: Les durées retenues pour les dénitions de la gigue. (a) : jsi,ken
fonction de ∆si,k. (b) : si,k − ri,k en fonction de si,k − ri,k.
Ces deux expressions mettent en relief le caractère absolu de la gigue (JBut−a(τi)), com-
parée au caractère relatif de nos dénitions qui se base sur ∆si,k − Ti. On peut néanmoins
donner quelques limites communes :
42 Le contexte de l'étude
Fig. 1.14: (a) : exécution régulière. (b) : exécution irrégulière.
• si l'exécution de la tâche τi est strictement régulière, alors JBut−a(τi) = 0, ainsi quetoutes les formes de gigue de régularité mentionnées dans la section 1.4.1, puisque pour
tout k, ∆si,k − Ti = 0 (cf. gure 1.14-a).
• si l'exécution de la tâche τi est très irrégulière (cf. cas de la gure 1.14-b), alors
JBut−a(τi) = Ti − Ci et |∆si,k − Ti| = Ti − Ci, conduisant alors à un pourcentage de
gigue maximum de régularité de Ti−Ci
Ti100 %, identique à JBut−a(τi) à un coecient
multiplicatif près.
Il existe donc des corrélations entre ces deux notions (dénitions 1.14 et expression 1.16) :
si les décalages à l'exécution varient d'une instance à l'autre, notre gigue de régularité en
sera aectée, a contrario, si les durées entre les débuts d'exécution d'instances successives
varient, alors les décalages à l'exécution en seront également aectés. Il existe néanmoins
un cas où la gigue de Buttazzo, par son caractère absolu, conduit à une conclusion non
pertinente. Imaginons une séquence d'ordonnancement d'une tâche où les durées entre les
débuts d'exécution d'instances successives augmentent progressivement de la plus petite
à la plus grande durée possible (cf. gure 1.15). Dans le cas de la gigue JBut−a(τi), laconclusion sera une grande irrégularité dans l'exécution. Au contraire, avec nos dénitions
de la gigue de régularité (moyenne, maximum, minimum), on conclura à une irrégularité
faible, ce qui traduit en fait correctement l'ordonnancement de la séquence. A noter que
dans le domaine du contrôle utilisant des asservissements échantillonnés, il est important
de savoir si les durées entre deux instances successives de la tâche s'écartent ponctuellement
d'une moyenne ou si elles contribuent à un glissement progressif comme celui de la gure
1.15. Nous reviendrons d'ailleurs sur cette remarque dans le paragraphe 1.5.4.
Buttazzo dénit de même la gigue relative de n d'exécution et la gigue absolue de n
d'exécution qui se basent sur le paramètre ei,k et qui appellent les mêmes remarques que
ci-dessus.
1.5.2 La gigue selon Dinatale, Stankovic & Baruah
Les auteurs de [DiNatale 95] dénissent la gigue de manière locale entre deux instances
successives d'une tâche. La gigue J(Din−Sta)k(τi) de la kieme instance de la tâche τi est ainsi
1.5 Les dénitions connues de la gigue 43
dénie par :
J(Din−Sta)k(τi) = |si,k+1 − si,k − Ti| pour k = 1, 2, ..., Ni − 1J(Din−Sta)N (τi) = |si,Ni+1 − Ti − si,Ni
| avec si,Ni+1 = si,1 +H.(1.17)
où H est le ppcm des périodes et Ni, le nombre d'instances exécutées dans une période
d'étude. Ces quantités sont à relier à jsi,kde l'équation 1.4, à la nuance près que nous
rapportons notre dénition de la gigue à un pourcentage. Au nal donc, si on fait la moyenne
de ces J(Din−Sta)k(τi) et si on se rapporte à un pourcentage, on obtient alors la dénition
du pourcentage moyen de gigue de régularité introduite dans le paragraphe 1.4.1.
Baruah et al. dans [Baruah 99] dénissent également la gigue avec les écarts entre deux
débuts ou deux ns d'exécution d'instances successives, mais ils ne la rapportent pas en
revanche à la période de la tâche. Ils introduisent ainsi une "période" minimum Tmin et
une "période" maximum Tmax dénies par :
Tmin = mink
(ei,k+1 − ei,k) (1.18)
Tmax = maxk
(ei,k+1 − ei,k)
expressions qui, lorsque la gigue est nulle, sont telles que Tmin = Tmax = Ti, et qui, lorsquela gigue est grande sont telles que Tmin = Ci + (Ti −Di) et T
max = (Ti +Di) − Ci. Dans
l'hypothèse de durées d'exécution négligeables, et de tâches à échéance sur requête, on a :
Tmin → 0, et Tmax → 2Ti, limites qui sont les mêmes que celles du paragraphe 1.4.1.
Cette dénition est nalement très proche de la dénition donnée pour la gigue locale de
régularité (équation 1.4) et les auteurs de [Baruah 99] dénissent de même un ensemble de
gigues (maximum, relative, etc.) qui rejoignent celles déjà présentées (cf. paragraphe 1.4.1).
1.5.3 La gigue liée aux incertitudes temporelles matérielles
Une représentation [Baruah 97, Cheng 96] qui est souvent adoptée pour modéliser la
gigue consiste à ajouter deux paramètres supplémentaires au modèle de tâche périodique
(cf. paragraphe 1.3.1), un paramètre noté λi (λi ≥ 0) qui est appelé gigue basse, et un
paramètre noté ηi (ηi ≥ 0) qui est appelé gigue haute. Ces paramètres caractérisent en fait
la durée des intervalles dans lesquels les débuts d'exécution des instances des tâches doivent
Fig. 1.15: Exécution faiblement irrégulière : la période eective de la tâche τivarie dans une limite d'une unité de temps processeur à chaque instance.
44 Le contexte de l'étude
arriver (cf. gure 1.16). Ces intervalles sont dénis plus formellement par : [ri,k−λi; ri,k+ηi]avec k ≥ 1. Cette gigue est désignée par le terme input jitter, à savoir la gigue d'entrée. Elle
caractérise en eet les incertitudes temporelles liées au matériel que nous rencontrons sur
les ordinateurs actuels qui sont plus réalisés dans un souci du toujours plus vite, que dans
un souci de déterminisme temporel [Törngren 98]. La gigue à laquelle nous nous intéressons
dans cette thèse correspond en fait à la gigue de sortie (output jitter), c'est-à-dire une fois
les tâches ordonnancées.
Fig. 1.16: Les intervalles dans lesquels les instances doivent débuter leurs exé-
cutions.
Bien que diérente sur le fond, on peut relier cette gigue d'entrée à la gigue de sortie,
présentée depuis le début de ce mémoire. Les paramètres λi et ηi peuvent en eet être reliés
à nos dénitions de gigues temporelles. Nous allons pour cela travailler avec le pourcentage
maximum de gigue de régularité. Supposons que dans le modèle proposé dans ce paragraphe,
et sur une période d'étude, on obtienne, au moins une fois, la pire conguration pour
la gigue, soit celle présentée dans la gure 1.17. Le pourcentage maximum de gigue de
régularité peut alors s'exprimer par la relation :
Jmax(τi) =|λi + ηi − Ci|
Ti100 %. (1.19)
Ainsi, dans l'hypothèse d'une durée d'exécution inme, si λi et ηi tendent vers zéro, la giguetend vers zéro, et si λi et ηi tendent vers un maximum de Ti/2, cela conduit alors à une
gigue maximum de 100%.
Fig. 1.17: Les deux congurations pour lesquelles la gigue est maximum.
1.6 La gigue : critère d'apparition et conséquences 45
1.5.4 Remarques sur les diérentes dénitions de la gigue
L'ensemble, non exhaustif, des dénitions de gigue que nous avons présentées dans cette
section peuvent toutes se rapprocher des dénitions retenues dans la section 1.4. C'est
d'ailleurs l'idée principale qu'il faut retenir de cette section : bien que nos dénitions et
celles proposées dans la littérature ne soient pas tout à fait identiques sur la forme, elles
restent le plus souvent identiques sur le fond. Il s'agit en eet de mesurer les durées séparant
les instances successives d'une tâche et d'observer l'écart que font ces durées par rapport à
une valeur de référence qui n'est autre que la période de la tâche.
En pratique cependant, le choix de la dénition de la gigue employée, revêt une impor-
tance particulière et dépend essentiellement du type d'application rencontrée, et de ce qui
est nécessaire de mettre en relief. Dans des applications de type réseau, la gigue basée sur
le maximum est souvent retenue. A contrario pour une tâche d'acquisition de donnée, on
préférera une gigue basée sur la moyenne avec un écart-type faible, de sorte que la régula-
rité d'exécution soit respectée pendant toute la phase d'échantillonnage [Cottet 97]. D'une
manière générale, il est intéressant de mener une étude statistique sur les durées séparant
les instances successives. Dans le contexte du contrôle par asservissement échantillonné, il
est par exemple important de savoir si les écarts des durées par rapport à T , la période dela tâche, sont ponctuels, ou si ces écarts évoluent progressivement, au travers par exemple
d'un glissement (cas de la gure 1.15 de la page 42). Illustrons cela au travers d'une suite
(Xi) nie de signaux, dénie par :
Xi = X0 + i(T − ε) pour i ∈ 1, ..., N (1.20)
Xj = X0 + j(T + ε) pour j ∈ N + 1, ..., 2Navec ε un réel et N un entier. La moyenne des écarts entre les durées séparant 2 signaux
successifs et leur période T est nulle, pour autant l'écart type de ces écarts est ε, ce qui
implique alors des irrégularités fréquentes par rapport à la période du signal. Dans le cas
d'un asservissement échantillonné, ces irrégularités se traduisent généralement par des oscil-
lations dans la commande, favorisant alors les régimes transitoires, qui peuvent ainsi nuire
à la stabilité du système asservi. La gigue de régularité telle que nous l'avons dénie est
proche de cette notion d'écart type, puisqu'il s'agit de comparer en valeur absolue les durées
séparant les instances successives, de la période de la tâche.
Nous avons vu enn une nuance sur la notion de gigue. Elle peut en eet être mesurée
en amont de l'ordonnancement, et elle constitue alors la gigue d'entrée liée aux incertitudes
temporelles du matériel, ou elle peut être mesurée en aval de l'ordonnancement, et elle
constitue alors une gigue de sortie (ou d'ordonnancement). C'est cette dernière gigue que
nous étudions dans ces travaux et nous nous plaçons dans l'hypothèse d'une gigue d'entrée
nulle (la périodicité des dates d'activation est toujours bien respectée).
1.6 La gigue : critère d'apparition et conséquences
1.6.1 Critères favorables à l'apparition de gigue
Dans le contexte de l'étude de la gigue liée à l'ordonnancement, il est dicile de déter-
miner des critères spéciques à l'obtention de gigue. Tout au plus, pouvons-nous énoncer
46 Le contexte de l'étude
quelques règles simples qui sont assez intuitives :
• Lorsque la charge processeur U est forte (proche de 1), la gigue est alors plus importante.
Ceci sera d'ailleurs conrmé dans le chapitre "Expérimentations Numériques" (chapitre
4) où des essais ont été menés pour diérentes charges processeur.
• Lorsque les tâches ont des périodes multiples les unes des autres, leur activation peut
intervenir en même temps, provoquant alors des perturbations au réveil : il y a apparition
de gigue.
• Rappelons que dans cette étude, nous nous plaçons dans l'hypothèse de tâches pério-
diques, mais que dans un contexte plus général où des tâches apériodiques ou sporadiques
seraient considérées, l'arrivée de telles tâches est un facteur favorisant l'apparition de
gigue.
1.6.2 Conséquences de la gigue dans les applications temps réel
La littérature traitant de la théorie du contrôle numérique [Aström 99, Törngren 98]
souligne l'impérieuse nécessité d'avoir une certaine régularité dans l'envoi de signaux im-
pliqués dans une boucle d'asservissement. Aujourd'hui, pour réaliser une application temps
réel de contrôle, deux étapes sont distinguées : on décrit d'abord le système du point de
vue automatique, puis on passe à une modélisation temps réel du système. Cette approche
conduit la plupart du temps à des solutions non optimales avec une non optimisation de
l'utilisation des ressources. Une approche intéressante consisterait à prendre en compte dès
le début de la conception, les contraintes de performance en terme d'automatique, et les
contraintes temporelles : c'est cette approche qui fait l'objet de travaux de la part de Cervin
et al dans [Cervin 99, Cervin 02]. Il a été ainsi montré que l'irrégularité dans l'envoi d'un
signal impliqué dans une boucle d'asservissement pouvait entraîner le système hors de son
domaine de stabilité. S'agissant alors d'applications temps réel critiques, les conséquences
d'une telle variation peuvent être très graves.
- Pour illustrer par l'exemple un eet de la gigue de régularité, considérons une tâche d'ac-
quisition de données. Dans l'idéal, cette acquisition devrait se faire de manière discrète à
intervalle de temps régulier, caractérisé par ce qu'on appelle la période d'échantillonnage.
Shannon et Nyquist ont montré [Shannon 49] que le nombre de périodes d'échantillon-
nage par seconde, soit encore la fréquence d'échantillonnage, devait être au minimum le
double de la fréquence maximale du signal échantillonné, ceci pour éviter le phénomène
de repliement spectral (aliasing). Dans le cas d'une irrégularité dans le respect de cette
période d'échantillonnage, il y a alors perte d'information, se traduisant en fait par l'at-
ténuation du spectre du signal échantillonné (le rapport signal/bruit diminue car le bruit
augmente).
L'atténuation de ce spectre en dB a été estimée [Balakrishnan 62] en fonction du type
d'irrégularité, qui est le plus souvent modélisé par une distribution statistique. Donnons
par exemple, l'eet d'une gigue uniformément répartie sur des intervalles centrés au-
tour des "points d'acquisition" du signal à échantillonner (cf. gure 1.18). Considérons
pour cela un échantillonnage réparti de manière uniforme entre −γTe et γTe, où γ est
une constante positive inférieure à 0,5. [Balakrishnan 62] a montré que le coecient
d'atténuation normalisé F du signal échantillonné pouvait s'écrire :
1.6 La gigue : critère d'apparition et conséquences 47
F = |sin(2πγfTe)
2πγfTe|. (1.21)
où Te est la période d'échantillonnage et f , la fréquence du signal échantillonné. Notons
que si f augmente, le coecient d'atténuation tend vers 0 et l'eet d'atténuation est
alors important.
Fig. 1.18: Échantillonnage oscillant réparti sur 2γTe.
On peut relier la gigue de régularité moyenne donnée par l'expression 1.7 à ce facteur d'at-
ténuation. Supposons pour cela que les écarts ∆si,k se répartissent de manière uniforme
sur l'ensemble de l'intervalle de variation possible (dans l'espace des réels). Ceci est une
approximation dans le sens où les séquences d'exécution des tâches se rapportent toujours
à des échelles de temps discrètes. La variation des ∆si,k étant uniforme et équirépartie
sur l'intervalle [Te − 2γTe; Te + 2γTe], il en résulte que |Te − ∆si,k| varie uniformément
et continûment sur l'intervalle [0; 2γTe]. On a alors l'approximation suivante :
JMoy × Te100%
=
∑Nk=1 |Te − ∆si,k|
N 2
∑E(N/2)k=0 2γTe × k
N
N γTe
∫ t=1
t=0
t dt. (1.22)
qui nous permet alors de relier la gigue de régularité moyenne avec le facteur d'atténua-
tion (on suppose que nous sommes dans les conditions de Shannon f = 1/(2Te)) :
F = |sin(πJMoy
50%)
πJMoy
50%
| (1.23)
On constate que ce facteur d'atténuation diminue lorsque la gigue de régularité moyenne
augmente. Soulignons cependant que nous avons formulé des hypothèses de répartition
uniforme de la gigue, qui représente un cas "idéal" de modélisation. Cette approche nous
conrme juste que la gigue peut entraîner une dégradation du signal, et donc une perte
d'information.
- Une autre conséquence de la gigue, mais indirecte cette fois-ci, se traduit par une sur-
charge processeur : en eet, pour diminuer les pertes d'information pour les tâches d'ac-
quisition ou de restitution de données, il est classique d'augmenter les périodes de traite-
ment, c'est ce qu'on appelle le principe du suréchantillonnage. La conséquence immédiate
48 BIBLIOGRAPHIE
d'une diminution des périodes est caractérisée par une augmentation de la charge pro-
cesseur, charge qui est donc perdue pour les autres tâches.
- Enn, dans [Lin 96], les auteurs soulignent les problèmes de tolérances aux fautes face
aux systèmes supportant l'irrégularité d'exécution de ses tâches : en eet, sur ce genre de
système, on doit attendre plus longtemps, comparé à un système à exécutions régulières,
avant d'être sûr de l'occurrence d'un événement. Cette détection moins rapide de la
faute, et son traitement, peuvent ainsi diminuer la tolérance aux fautes du système.
1.7 Conclusion
Après avoir énuméré l'ensemble du vocabulaire utilisé dans ce mémoire, nous avons pré-
senté le modèle de tâche périodique, ainsi que les algorithmes d'ordonnancement en ligne
associés. Nous avons en outre présenté les conditions sur les paramètres des tâches à res-
pecter pour satisfaire les contraintes de précédence. Les protocoles de gestion de ressources
critiques partagées ont également été introduits.
L'ensemble de ces mécanismes d'ordonnancement attribue au nal les priorités aux
tâches dans un souci de respect de la contrainte "échéance", avec éventuellement le respect
des contraintes de précédence. Les contraintes de type "régularité d'exécution" ne sont
cependant pas prises en compte et les dénitions de gigue introduites dans ce chapitre
permettent de mesurer dans quelles proportions nous nous en sommes éloignés. Nous avons
distingué en outre trois grands types de gigue : la gigue de régularité, appliquée à une tâche,
qui mesure en fait l'écart des exécutions de la tâche par rapport à sa période, la gigue de bout
en bout, appliquée à une activité, qui mesure l'écart du temps de réponse de l'activité par
rapport à un temps de réponse idéal, et enn, la gigue de cohésion, appliquée à une tâche,
et qui mesure la cohésion dans l'exécution de la tâche. En d'autres termes, cette dernière
gigue mesure la dispersion de l'exécution par rapport à une exécution non préemptée. Ces
dénitions de gigues ont été alors comparées à celles déjà connues par la communauté
temps réel. Les dénitions apparaissent ainsi généralement identiques sur le fond, et on
pourra favoriser telle ou telle dénition suivant les conventions utilisées ou suivant ce que
le concepteur veut mettre en relief (gigue maximum, gigue moyenne, basée sur les débuts
ou ns d'exécution des instances, relative à la période ou à leur date d'activation, etc.).
Dans une dernière section, nous avons présenté quelques critères favorables à l'appari-
tion de gigue, et nous avons illustré par une approche type "traitement du signal" certaines
conséquences de la gigue, dans la perte ou la dégradation d'informations lors du passage
du procédé vers le système numérique. Nous avons également évoqué le problème du sur-
échantillonnage, et la position des systèmes ayant de la gigue face à la tolérance aux fautes.
Dans le chapitre suivant, nous présentons les techniques connues de traitement de la
gigue permettant de la minimiser, voire de l'annuler.
Bibliographie
[Aström 99] Aström K.J. et Wittenmark B. Computer-controlled Systems :
Theory and design. Prentice Hall, Information and System, Sciences
Series, 1999.
BIBLIOGRAPHIE 49
[Audsley 91] Audsley N.C. Optimal priority assignment and feasibility of static
priority tasks with arbitrary start times. Rapport technique YCS-164,
University of York, nov. 1991.
[Baker 90] Baker T.P. Stack-based scheduling of real-time processes. Proc. of
the 11th IEEE Real-Time Systems Symposium, RTSS'90. Dec 1990, p
191200.
[Baker 91] Baker T.P. Stack-based scheduling of real-time processes. Real-
Time Systems, 1991, vol 3, p 6799.
[Balakrishnan 62] Balakrishnan A.V. On the problem of time jitter in sampling.
I.R.E. Trans. on Inf. Theory, 1962, vol IT8, p 226236.
[Baruah 90] Baruah S.K., Howell R.R. et Rosier L.E. Algorithms and com-
plexity concerning the preemptive scheduling of periodic, real-time
tasks on one processor. Real-Time Systems, 1990, vol 2, p 301324.
[Baruah 97] Baruah S.K., Chen D. et Mok A.K. Jitter concerns in periodic
task systems. Proc. of the 18th IEEE Real-Time Systems Symposium,
RTSS'97. Burlington, VT, USA, Dec. 1997. p 6877.
[Baruah 99] Baruah S. K., Buttazzo G., Gorinsky S. et Lipari G. Schedu-
ling periodic task systems to minimize output jitter. Proc. of the In-
ter. Conf. on Real-Time Computing Systems and Applications. Hong-
Kong, Dec. 1999. IEEE Computer Society Press, p 6269.
[Bate 99] Bate I. et Burns A. An approach to task attribute assignment
for uniprocessor systems. Proc. of the 11th EuroMicro on Real-time
Systems. York, UK, 1999. p 4653.
[Blazewicz 76] Blazewicz J. Modelling and performance evolution of computers
systems, chapitre Scheduling dependent tasks with dierent arrival
times to meet deadlines. North-Holland Publishing Company, 1976.
[Buttazzo 97] Buttazzo G.C. Hard real-time computing systems, chapitre Perio-
dic task scheduling, p 77108. Kluwer Academic Publishers, 1997.
[Cervin 99] Cervin A. Improved scheduling of control tasks. Proc. of the 11th
IEEE Euromicro Conference. York, UK, June 1999. p 410.
[Cervin 02] Cervin A., Eker J.,Bernhardsson B. etArzén K.-E. Feedback-
feedforward scheduling of control tasks. To appear in Real-Time Sys-
tems - Special Issue on Control - Theoritical Approaches to Real-Time
Computing, 2002.
[Chen 90] Chen M. et Lin K. Dynamic priority ceilings : a concurrency protocol
for real-time systems. Real-Time Systems, 1990, vol 2(4), p 325346.
[Cheng 96] Cheng S.-T. et Chen C.-M. A cyclic scheduling approach for rela-
tive timing requirements. Proc. of the 3rd IEEE Real-Time Application
Workshop. Québec, Canada, 1996. p 160163.
[Chetto 90] Chetto H., Silly M. et Bouchentouf T. Dynamic scheduling
of real-time task under precedence constraints. Real-Time Systems,
1990, vol 2, p 181194.
50 BIBLIOGRAPHIE
[Choquet-Geniet 96] Choquet-Geniet A., Geniet D. et Cottet F. Exhaustive com-
putation of the scheduled task execution sequences of a real-time ap-
plication. Proc. of the 4th International Symposium on Formal Tech-
niques in Real-Time and Fault-Tolerant Systems. Uppsala, Sweden,
1996. p 246262.
[CNRS 88] CNRS Groupe de réflexion temps-réel du CNRS. Le temps-
réel. Technique et Science Informatiques - TSI, 1988, vol 7(5), p
493500.
[Colin 00] Colin A. et Puaut I. Worst case execution time analysis for a
processor with branch prediction. Real-Time Systems, May 2000,
vol 18(2), p 249274.
[Cottet 97] Cottet F. Traitement des signaux et acquisition de données. Dunod,
1997.
[Cottet 99] Cottet F., Delacroix J., Kaiser C. etMammeri Z. Ordonnan-
cement temps réel. HERMES, 1999.
[Dertouzos 74] Dertouzos M.L. Control robotics : the procedural control of phy-
sical processors. Proc. of IFIP Congress. 1974, p 807813.
[Dertouzos 89] Dertouzos M.L. et Mok A.K. Multiprocessor on-line scheduling
of hard real-time tasks. IEEE Transactions on Software Engineering,
Dec. 1989, vol 15(12), p 14971506.
[DiNatale 95] DiNatale M. et Stankovic A. Applicability of simulated annealing
methods to real-time scheduling and jitter control. Proc. of Real-Time
Systems Symposium, RTSS'95. Pisa, 1995. p 190199.
[Gerber 94] Gerber R., Hong S. et Saksena M. Guaranteeing end-to-end
timing constraints by calibrating intermediate processes. Proc. of
the 15nd IEEE Real-Time Systems Symposium, RTSS'94. San Juan,
Puerto Rico, December 1994. p 192203.
[Grolleau 99a] Grolleau E. Ordonnancement temps-réel hors-ligne optimal à l'aide
de réseaux de Pétri en environnement mono-processeur et multipro-
cesseur. Thèse : ENSMA - Université de Poitiers, nov. 1999.
[Grolleau 99b] Grolleau E., Choquet-Geniet A. et Cottet F. Modélisation
de systèmes temps réel par réseaux de petri autonomes en vue de
leur analyse hors-ligne. Modélisation des Systèmes Réactifs, MSR'99.
Cachan, France, 1999. p 1726.
[Grolleau 00a] Grolleau E. et Choquet-Geniet A. Cyclicité des ordonnance-
ments de systèmes de tâches périodiques diérées. Proc. of RTS'2000.
Paris, France, 2000. p 216228.
[Grolleau 00b] Grolleau E. et Choquet-Geniet A. Scheduling real-time sys-
tems by means of petri nets. Proc. of 25th Workshop on Real-Time
Programming, WRTP'00. Palma de Mallorca, Spain, 2000. p 95100.
[Han 96] Han C.-C., Lin K.-J. et Hou C.-J. Distance-constrained schedu-
ling and its applications to real-time systems. IEEE Transactions on
Computers, 1996, vol 45(7), p 814826.
BIBLIOGRAPHIE 51
[IEEE Editions 92] IEEE Editions . The new IEEE Standard Dictionary of Electrical
and Electronics. 1992.
[Labetoulle 74] Labetoulle J. Un algorithme optimal pour la gestion des proces-
sus en temps réel. Revue Française d'Automatique, Informatique et
Recherche Opérationnelle, Fév. 1974, p 1117.
[Lehoczky 89] Lehoczky J.P., Sha L. et Ding Y. The rate monotonic scheduling
algorithm : exact characterization and average case behavior. Proc. of
the 10th IEEE Real-Time Systems Symposium, RTSS'89. Dec 1989, p
166171.
[Lehoczky 91] Lehoczky J.P., Sha L., Strosnider J.K. et Tokuda H. Fixed
priority scheduling theory for hard real time systems. Foundations of
Real-Time Computing : Scheduling and resource management, 1991,
p 130.
[Leung 80] Leung J. et Merrill M. A note on preemptive scheduling of per-
iodic real-time tasks. Information Processing Letters, 1980, vol 11(7),
p 115118.
[Leung 82] Leung J. et Whitehead J. On the complexity of xed-priority
scheduling of periodic, real-time tasks. Performance Evaluation (Ne-
therland), 1982, vol 2(4), p p. 237250.
[Lin 96] Lin K.-J. et Herkert A. Jitter control in time-triggered systems.
Proc. of the 29th International Conf. on System Sciences. Hawaiï,
U.S.A., 1996. p 451459.
[Liu 73] Liu C.L. et Layland J.W. Scheduling algorithms for mutltipro-
gramming in real-time environnement. Journal of the ACM, 1973,
vol 20(1), p 4661.
[Mok 83] Mok A.K. Fundamental design problems for the hard real-time envi-
ronments. Thèse : MIT, May 1983.
[Puschner 00] Puschner P. et Burns A. Guest editorial : A review of worst-case
execution-time analysis. Real-Time Systems, 2000, vol 18, p 115128.
[Richard 00] Richard P., Cottet F. et Kaiser C. Validation temporelle d'un
logiciel temps réel : application à un laminoir industriel. Acte de
la Conf. IEEE Inter. Francophone d'Automatique, CIFA'00. Lille,
France, 2000. p 687692.
[Sha 90] Sha L., Rajkumar R. et Lehoczky J.P. Priority inheritance pro-
tocols : an approach to real-time synchronisation. IEEE Transactions
on Computers, 1990, vol 39(9), p 11751185.
[Shannon 49] Shannon C.E. Communication in presence of noise. Proc. IRE.
volume 37, 1949, p 1021.
[Stankovic 98] Stankovic J., Spuri M., Ramamritham K. et Buttazzo G.
Deadline Scheduling For Real-Time Systems : EDF and Related Algo-
rithms, volume 460. Kluwer Academic Publishers, Boston, 1998.
52 BIBLIOGRAPHIE
[Törngren 98] Törngren M. Fundamentals of implementing real-time control ap-
plications in distributed computer systems. Real-Time Systems, 1998,
vol 14, p 219250.
[White 97] White R., Mueller F., Healy C., Whalley D. et Harmon
M. Timing analysis for data caches and set-associative caches. Proc.
IEEE Real-Time Technology and Applications Symposium. June 1997,
p 192202.
[Wilner 97] Wilner D. Vx-Files : What Really Happened on Mars ? Key-
note Speech, during the 18th IEEE Real-Time Systems Symposium,
RTSS'97, 1997. D. Wilner is the Chief Technical Ocer of Wind River
Systems.
[WindRiver 99] WindRiver . VxWorksTM : Programmer's Guide. 5.4. WindRiver,
1999.
[Xu 92] Xu J. et Parnas D.L. Pre-run-time scheduling of processes with
exclusion relations on nested or overlapping critical sections. Phoenix
Conference on Computers and Communications. Phoenix, USA, Apr.
1992. p 64716479.
[Zhang 93] Zhang N., Burns A. et Nicholson M. Pipelined processors and
worst case execution times. Real-Time Systems, 1993, vol 5(4), p
319343.
Chapitre 2
État-de-l'Art
La gigue est un sujet interdisciplinaire sur lequel de nombreux travaux ont été écrits.
Le domaine de l'automatique fut le premier, de par son antériorité, à s'intéresser au pro-
blème de gigue pour les interactions périodiques entre le système de contrôle et le procédé.
Les systèmes distribués (bus ou réseau) forment aussi un domaine où la gigue peut poser
problème, notamment dans le transport de données multimédia avec la restitution du son.
D'ailleurs, dans ce domaine d'application, un certain nombre de normes ont été établies avec
par exemple, des critères de qualité de service (dont la gigue peut faire partie). Comme nous
l'avons souligné dans le chapitre précédent, nous ne nous intéressons dans ces travaux qu'à
la gigue liée à l'ordonnancement des tâches. La gigue liée aux incertitudes temporelles du
matériel (gigue d'entrée qui fait par exemple uctuer la périodicité d'activation des tâches)
est écartée. Rappelons également que nous nous intéressons soit à la gigue de régularité des
tâches, soit à la gigue de bout en bout, et que dans ces deux cas, il s'agit d'un indicateur
qui mesure l'écart existant entre une durée réelle et une durée théorique.
Dans ce contexte, on distingue des méthodes de contrôle de la gigue basées sur une
approche en ligne, et celles basées sur une approche hors ligne. Ce sont ces deux approches
que nous verrons dans les deux premières sections de ce chapitre. Dans la troisième section,
nous présentons un modèle spécique au contrôle de la gigue, développé par [Han 92], et
qui a fait l'objet de nombreuses extensions, c'est le modèle de tâche à distance temporelle
contrainte (DCTS pour distance constraint task system). Dans le cadre de l'approche hors
ligne, nous distinguons les méthodes génétiques (non optimales) permettant la maîtrise
de la gigue sous certaines conditions, et les méthodes exactes de recherche exhaustive de
séquences d'ordonnancement valides, dans lesquelles certains critères temporels doivent être
respectés.
Pour chaque technique présentée, nous confrontons ses hypothèses et son domaine d'ap-
plication, à notre contexte d'étude : nous verrons que nos travaux apportent une contribu-
tion appréciable au contexte en ligne où certains problèmes sont restés ouverts.
2.1 Approche en ligne
Dans cette section, nous présentons les principales techniques liées à l'approche en ligne,
et qui permettent de minimiser la gigue. On distingue dans cette approche deux catégories :
54 État-de-l'Art
celle où les priorités des tâches sont xes au cours de l'exploitation de l'application, et celle
où les priorités sont variables.
2.1.1 Ordonnancement à priorité xe
Gerber et al. dans [Gerber 94] propose une technique de maîtrise des contraintes tempo-
relles de bout en bout, dans le cadre des ordonnancements à priorité xe. Cette technique
se base sur une méthode de conception itérative du système de tâches, au cours de laquelle
l'aectation des paramètres temporels fait l'objet d'une attention particulière. Trois étapes
sont distinguées :
• une première étape transforme les contraintes de bout en bout en un ensemble de
contraintes linéaires sur les paramètres des tâches, et en un ensemble de contraintes de
multiplicité sur les périodes des tâches1. Par exemple, une contrainte de bout en bout
peut stipuler qu'une tâche de commande τi doit avoir une cadence comprise entre un
minimum m et un maximum M . Cette condition se traduit alors par les deux inégalités
suivantes :
Ti −Di + Ci ≥ mTi +Di − Ci ≤M
formant ainsi des contraintes linéaires sur les paramètres des tâches (cf. gure 2.1 pour
illustration de la première équation).
Fig. 2.1: Détermination d'une contrainte linéaire : on souhaite que la durée
Ti−Di +Ci qui représente la durée qui sépare deux début d'exécutions de deux
instances successives, soit inférieure ou égale à un entier m.
Un autre exemple concerne les contraintes de délai critique de bout en bout. Dans les
activités de la gure 2.2, on peut avoir par exemple une contrainte selon laquelle Y doit
être produit sur la base d'une acquisition de X1, ayant eu lieu au pire D unités de temps
avant la production de Y . Cette contrainte est d'autant moins triviale que les périodes
de τ1, τ2 et τ3 peuvent être diérentes. Pour pouvoir alors raisonner en terme de délai
critique de bout en bout sur l'activité τ1 → τ3, les auteurs proposent d'imposer une
contrainte de multiplicité (par exemple T1 divise T3).
• La deuxième étape est un problème de minimisation. On doit résoudre l'ensemble des
contraintes linéaires et l'ensemble des contraintes de multiplicité en minimisant la charge
processeur. On obtient alors un ensemble de périodes pour les tâches.
1Une contrainte de multiplicité est par exemple exprimée par la condition suivante : Ti doit être un
multiple de Tj, avec i et j désignant deux tâches distinctes.
2.1 Approche en ligne 55
• Dans une troisième étape, ces périodes sont reportées dans les contraintes linéaires
basées sur les paramètres des tâches, et cela permet de donner une solution en terme
de délais critiques et de dates d'activation. Dans cette étape, on veille par ailleurs à
maximiser l'ordonnançabilité, en favorisant des intervalles d'exécution plus grands.
Fig. 2.2: Trois tâches formant deux activités avec passage de données (d1 et d2),
et avec deux données d'entrée (X1 et X2) et une donnée de sortie (Y ).
Lorsque la troisième étape ne peut conduire à une solution, on reconsidère dans l'étape 1
le choix des périodes en modiant les contraintes de multiplicité (on fait en sorte par exemple
de réduire la charge processeur). Cette modication des contraintes de multiplicité peut en
outre être réalisée en dénissant un autre schéma d'acquisition (ajout de tâches spécialisées
dans l'acquisition par exemple). On procède ainsi étape par étape jusqu'à obtenir dans
l'étape 3 une solution en terme de délai critique et de dates d'activation.
Dans une toute dernière étape enn, la gestion des précédences entre les tâches avec
passage de données, est réalisée par l'emploi de mémoires tampons, dont la taille dépend
des périodes des tâches consommatrices et de la période de la tâche productrice, dont
l'accès en lecture peut se faire de manière aléatoire (une tâche consommatrice peut par
exemple lire la donnée placée en nième position) et dont l'accès en écriture se fait sur le
principe des les d'attente. Soient par exemple une tâche productrice τp et deux tâches
consommatrices τc1 et τc2 telles que τpd1→ τc1, et τp
d2→ τc2 , avec Tc1 = 2, Tc2 = 4 et Tp = 2.On a ppcm(Tc1, Tc2)/Tp = 2 qui donne la taille nécessaire à la mémoire : τc1 lira ainsi dansla mémoire la donnée la plus récente (stockée en première position), et τc2 lira la donnée
stockée en seconde position.
Supposer que tous les attributs temporels sont modiables et notamment les périodes,
peut réduire considérablement le domaine d'utilisation de cette technique. La période est
en eet souvent donnée, et provient par exemple, d'impératifs de traitement des signaux
venant du procédé. Dans notre étude, l'approche est diérente : nous supposons d'abord que
les périodes sont données, et nous utilisons explicitement les algorithmes d'ordonnancement
connus. De plus, les relations de précédences de cette étude s'appliquent à des tâches de
même période, et ne nécessitent pas de mémoires tampons.
Bate et al. dans [Bate 99] décrivent de même un mécanisme d'aectation des paramètres
temporels des tâches, pouvant prendre en compte des contraintes temporelles, incluant la
gigue. Les auteurs soulignent en eet que dans la plupart des articles, les paramètres des
tâches tels que les échéances ou les dates d'activation sont généralement données. Un choix
judicieux de ces paramètres peut cependant fournir, une fois l'analyse d'ordonnançabilité
eectuée, des séquences dans lesquelles non seulement les échéances sont respectées, mais
56 État-de-l'Art
encore les temps de réponses de certaines activités, ou encore les gigues de certaines tâches,
ou enn les contraintes de séparation entre deux tâches.
La gigue traitée dans ces travaux fait référence à la gigue à l'activation (cf. gigue de
Buttazzo dénie dans la sous section 1.5.1), c'est-à-dire à la distance séparant le début
d'exécution eectif de la tâche, de son activation. Le principe réside dans la dénition d'un
délai critique tel que :
Di = Ji +BCRTi, (2.1)
où Ji représente la gigue à l'activation de la tâche τi , et BCRTi, son meilleur temps de
réponse (best case response time of task). Ce temps de réponse peut dans un premier temps
être considéré comme nul, puis au cours de l'analyse temporelle, être calculé plus nement
via des techniques connues [Redell 02, Gutiérrez 97].
Avec cette dénition des délais critiques, si plusieurs tâches possèdent des contraintes
de gigue, elles devront alors s'exécuter peu de temps après leur activation an d'éviter les
fautes temporelles : leurs fenêtres d'exécution seront donc réduites. Cela va inévitablement
conduire à des congurations de tâches non ordonnançables. Bate et al. proposent dans ce
cas une redénition des dates d'activation des tâches à contraintes de gigue, an de décaler
les fenêtres d'exécution et d'éviter les perturbations. Dans le cadre de la gestion d'activités,
si la dernière tâche d'une activité possède une contrainte de gigue, la technique proposée
pour la gestion des temps de réponse, combinée à la redénition du délai critique, conduit
également à des fenêtres d'exécution très étroites, et là encore, la solution envisagée consiste
à décaler la fenêtre d'exécution de la dernière tâche pour obtenir une conguration de tâches
dont les chances d'ordonnançabilité sont augmentées.
Cette méthode d'aectation des paramètres du type délai critique et date d'activation,
est proche des idées que nous allons développer dans le chapitre 3, puisqu'il va s'agir de
généraliser cette approche en gérant systématiquement les problèmes de dates communes
d'activation pour les tâches à contraintes de gigue, et en désynchronisant leurs fenêtres
d'exécution. Les contraintes de précédence feront également l'objet d'un travail plus appro-
fondi.
2.1.2 Ordonnancement à priorité variable
Les travaux concernant l'ordonnancement de tâches à priorité variable dans le souci de
la maîtrise de la gigue, utilisent généralement l'algorithme d'ordonnancement EDF, qui a
fait l'objet de nombreuses études et qui a l'avantage d'être optimal dans le contexte de
tâches indépendantes [Labetoulle 74, Dertouzos 74].
Baruah et al. dans [Baruah 97] proposent ainsi dans le cadre EDF, une méthode s'ap-
pliquant aux systèmes de tâches pour lesquelles les dates d'activation de chaque instance
ne peuvent être déterminées a priori. Ceci dans l'optique de modéliser ce qui se passe bien
souvent dans les systèmes d'exploitation temps réel, à savoir des dates d'activation qui
sourent d'une certaine incertitude temporelle [Zhou 98]. Dans ces travaux, le but est donc
de maîtriser la gigue d'entrée provenant des incertitudes temporelles du matériel (cache,
pipeline, processeur à prédiction de branchement, etc.).
Ces travaux seront présentés dans la section 2.3 car ils utilisent un modèle de tâche
diérent du modèle de tâche périodique.
2.1 Approche en ligne 57
Dans [Baruah 99], Baruah et al. présentent une technique d'aectation des délais critiques
pour réduire la gigue de régularité d'un ensemble de tâches. Dans un premier temps, ils
montrent que dans les hypothèses d'un ordonnancement sous EDF, avec départ synchrone
des tâches, la gigue maximum de régularité est bornée :
Jmax(τi)
100%= max
k(∆ei,k − TiTi
) ≤ Ci
Ti(U
Ui− 1) (2.2)
avec un facteur de tolérance à la gigue de Ti [Baruah 99]. En prenant ensuite le maximum
parmi l'ensemble des tâches, il est alors possible d'obtenir une borne sur cet ensemble. Cette
borne n'est malheureusement pas assez ne et Baruah et al. proposent alors de l'aner en
modiant soit la fraction de charge processeur réservée pour les tâches, soit leur délai
critique.
• Dans la première approche, où seuls sont pris en compte les paramètres Ci et Ti, lesauteurs augmentent la fraction θi de charge processeur réservée pour τi de sorte qu'ellerespecte les relations suivantes : θi ≥ Ui(= Ci/Ti) et
∑τiθi ≤ 1. Cette dernière condition
nous assure [Liu 73] l'ordonnançabilité de la conguration de tâches (Ci(θi/Ui);Ti)i=1..n
avec n désignant le nombre de tâches. Sur l'intervalle [kTi; kTi + Ci/θi], on a Ci/θiintervalles supposés unitaires dans chacun desquels, est demandée la fraction de charge
processeur θi, soit une charge processeur de (Ci/θi) × θi = Ci (cf. gure 2.3). Pour
l'instance k, la date kTi+Ci/θi représente donc un "délai critique" virtuel (cf. gure 2.3).La technique de maîtrise de la gigue va consister alors à trouver les θi qui minimiseront
la quantité Ci
Ti( θθi− 1) de l'équation 2.2, et qui minimiseront donc la gigue. La technique
peut en outre s'intéresser au traitement de la gigue de l'ensemble des tâches, ou bien à
un nombre réduit d'entre elles.
• Dans la seconde approche, les auteurs proposent de modier les délais critiques des
tâches, en utilisant la relation suivante : Di = Ci + J × Ti avec J ∈ [0; (Ti − Ci)/Ti],qui réduit alors le délai critique par rapport à une conguration de tâches à échéance
sur requête. Dans ce cas, le critère d'ordonnançabilité n'est plus aussi simple que pré-
cédemment. En eet dans cet article, pour vérier l'ordonnançabilité les auteurs font
appel à la méthode développée par Baruah et al. dans [Baruah 90]. Si la conguration
est ordonnançable, les auteurs conseillent alors d'utiliser cette conguration modiée an
d'obtenir une séquence de tâches où pour chacune d'entres elles le pourcentage de gigue
maximum Jmax(τi) est bornée par J × 100%.
La première technique conduit à une solution en un temps polynomial, alors que la
seconde, plus intéressante du point de vue de la gigue, apporte une solution en un temps
pseudo-polynomial.
Dans ces travaux, n'est pas prise en compte la possibilité d'avoir des tâches à départ
non simultané. Cette prise en compte, et nous le verrons dans le chapitre suivant, permet
aussi dans certains cas de maîtriser la gigue, ou du moins, permet d'y contribuer. Dans
ces travaux également, il n'a pas été question de tâches dépendantes qui seraient liées par
des relations de précédences. Le chapitre suivant permettra de gérer non seulement les
contraintes de gigues, mais aussi les précédences entre les tâches.
La technique proposée dans le paragraphe précédent est une technique qui reste lourde à
mettre en place d'un point de vue calculatoire surtout dans le deuxième cas et qui s'adresse
58 État-de-l'Art
en pratique à un nombre réduit de tâches. Dans les travaux de [Kim 00], les auteurs pro-
posent une technique de réduction de la gigue basée également sur une aectation particu-
lière des délais critiques. Le principe consiste à se ramener à un problème d'optimisation
constitué d'un ensemble de contraintes linéaires avec une fonction objectif à minimiser.
• Les contraintes linéaires se déduisent des conditions d'ordonnançabilité des tâches dé-
crites dans [Baruah 90, Ripoll 96], et s'écrivent :
∀i ∈ 1 . . . n, H(t) =∑
∀j, Cj≤Ci
(Di + Tj −Dj
Tj)Cj ≤ Di. (2.3)
où n représente le nombre de tâches de la conguration, Di et Ti, le délai critique et lapériode de la tâche τi.
• La fonction objectif Z à minimiser est quant à elle déduite de la dénition de la gigue
locale de régularité dans le pire cas (jsi= (Di−Ci)/Ti). En eet, une fonction intéressante
à minimiser pourrait être [Kim 00] :
Z =
n∑i=1
Di
Ti−
n∑i=1
Ci
Ti(2.4)
où Di est variable et Ci, Ti sont connues et xées. Cependant, comme le deuxième
terme du membre de droite est constant, il sut de minimiser la fonction :
Z =n∑
i=1
Di
Ti. (2.5)
En appliquant la technique à une conguration de deux tâches τ1 et τ2 dénies par (C1;C2) =(1; 3) et par (T1;T2) = (3; 5), la résolution du problème d'optimisation conduit à la solution
(D1;D2) = (2; 5), et réduit, comparée à une conguration de tâches à échéance sur requête,
la gigue locale maximum de τ2 de 20% à 0%, sans pour autant réduire la gigue locale
maximum de τ1.Nous verrons là encore dans le chapitre suivant que la combinaison d'une redénition
des délais critiques, mais aussi des dates d'activation peut conduire à un contrôle plus précis
de la gigue.
Fig. 2.3: (a) : La tâche τi non transformée avec une durée d'exécution Ci. (b) : La
même tâche avec une fraction de charge processeur augmentée (partie hachurée) :
dans le pire des cas, les Ci premières unités de temps processeur sont placées
avant la date kTi + (Ci/θi).
2.2 Approche hors ligne 59
2.2 Approche hors ligne
Dans le contexte d'ordonnancement hors ligne, on distingue les méthodes génétiques
accompagnées d'heuristiques plus ou moins sophistiquées, et les méthodes exactes basées
principalement sur des techniques d'énumération. Parmi les premières méthodes, nous ver-
rons l'application de la technique du recuit simulé à l'ordonnancement de tâches, et nous
verrons également une application des algorithmes génétiques.
2.2.1 Méthode du recuit simulé [DiNatale 95]
DiNatale & Stankovic dans [DiNatale 95] proposent d'appliquer la méthode du recuit si-
mulé à l'ordonnancement de tâches temps réel, avec une gestion de la gigue, des précédences
et des accès à des ressources critiques ou à un réseau. La méthode du recuit simulé est une
méthode empruntée à la thermodynamique [Kirkpatrick 83], et consiste à trouver d'une
manière stochastique une solution à un problème d'optimisation combinatoire. Comparée à
des méthodes déterministes d'optimisation, cette méthode permet par exemple d'éviter de
bloquer le processus de recherche d'une solution, sur un optimum local, et permet également
d'aborder des problèmes de taille plus importante.
Dans cet article [DiNatale 95], un certain nombre d'hypothèses sont formulées : on consi-
dère un environnement multiprocesseurs auxquels sont associées n tâches périodiques (pas
de migration de tâche entre les processeurs). Ces n tâches, qu'on suppose non préemptives,
sont caractérisées par un délai critiqueDi, une date d'activation ri,1, une période Ti, une du-rée d'exécution Ci et un ensemble de p ressources à accès exclusif Ri,1, . . . Ri,p. Les tâchespeuvent avoir des relations de précédence, ou des contraintes d'exclusion. Les contraintes
d'exclusion expriment la propriété selon laquelle des tâches ne peuvent être exécutées en
même temps ; cette hypothèse n'a en fait de sens que dans le contexte multiprocesseur. La
gigue traitée dans cet article est celle présentée dans le paragraphe 1.4.1, et fait référence à
la gigue locale de régularité.
Le problème de l'ordonnancement sous ces hypothèses, se rapporte en fait à un problème
d'optimisation, dans lequel la fonction objectif est soit le nombre de tâches dépassant leur
échéance, soit le maximum des gigues locales sur l'ensemble des tâches. Le problème consiste
alors à minimiser cette fonction objectif, en respectant les relations de précédence, les
contraintes d'exclusion, les délais critiques, et les contraintes implicites comme obtenir par
exemple le début d'exécution de la kième instance après la kième activation.
Après une phase d'initialisation dans laquelle on propose un ordonnancement des tâches
où les contraintes ne sont pas nécessairement toutes respectées, la méthode du recuit simulée
consiste, en partant de cette conguration, à choisir aléatoirement et étape après étape une
solution voisine dans l'ensemble des transitions possibles. Si la solution désignée permet
de diminuer la fonction objectif, on considère alors cette solution comme la conguration
courante. Si par contre, la fonction objectif n'est pas diminuée, cette solution n'est acceptée
qu'avec une probabilité dépendant d'un paramètre de contrôle T . Ce paramètre de contrôle
(qui correspond à une température dans le cadre de la thermodynamique) fait l'objet d'une
attention particulière : il faut d'abord le préciser pour l'état initial (généralement, il est
élevé), et sa diminution (linéaire, discrète ou exponentielle) est réalisée lorsqu'au cours du
processus, on détecte un équilibre statistique (ou un état de quasi-équilibre). La recherche
60 État-de-l'Art
de cet état se base sur les propriétés des chaînes de Markov (le nombre d'itération est par
exemple déterminée par la longueur de la chaîne).
L'algorithme présenté dans [DiNatale 95] reste cependant assez lourd à mettre en place,
et les auteurs soulignent qu'il peut être intéressant de l'utiliser lorsque les autres techniques
ne donnent pas de solution. En outre, l'hypothèse de tâches non préemptives ne s'inscrit
pas dans le contexte de nos travaux.
2.2.2 Méthodes génétiques [Coutinho 00a, Coutinho 00b]
Coutinho et al. dans [Coutinho 00a, Coutinho 00b] proposent une méthode de minimi-
sation de la gigue d'émission de messages, utilisant des algorithmes génétiques. L'article se
place dans le contexte distribué pour des applications temps réel de contrôle. Les auteurs
soulignent qu'un choix judicieux des dates d'émission des messages circulant d'un site à
l'autre, permet de réduire, voire d'annuler, la gigue du système. Dans cet article, la gigue
prise en considération est celle liée à l'envoi de messages périodiques par des instances de
tâches, mais le principe reste le même que dans le cadre de la gigue des tâches en envi-
ronnement mono-processeur : il s'agit de contrôler la variation de la périodicité d'envoi des
messages.
La fonction objectif du problème d'optimisation est dénie par une gigue globale qui est
représentée par la somme des gigues sur l'ensemble des messages du système. Le principe
de la technique repose sur l'adaptation des algorithmes génétiques au problème suivant :
déterminer un ensemble de dates d'activation pour la première émission de sorte que les
émissions répétitives des messages réduisent la gigue globale, tout en conservant la cohé-
rence de l'enchaînement des messages. L'enchaînement des messages est ici une propriété
particulière : il s'agit en eet de vérier que l'émission du kième message se fasse dans
l'intervalle [ri,k; ri,k +Ti−1] où ri,k représente la date d'activation pour l'émission du kième
message de la tâche τi, et Ti représente la période de cette tâche. Aucune vérication n'est
par ailleurs conduite pour la réception du message, et les considérations de durées d'exécu-
tion ou d'échéances sont donc écartées.
Dans cette approche, le génome est un vecteur dont la dimension est le nombre de
messages, et dont le contenu représente les décalages à l'activation des émissions de messages
(ri,1). Chaque élément de ce vecteur correspond donc à un allèle et représente un entier
compris entre 0 (inclus) et Ti (exclus). Les meilleurs individus sont ceux qui ont une faible
gigue globale sur l'ensemble des messages. Les opérateurs génétiques sont basés sur un
croisement des éléments du génome (qui représente alors le mécanisme de la reproduction
sexuelle), ou sur une mutation d'un élément du génome. Les croisements sont appliquées
avec une probabilité proche de 1 (systématique dans l'évolution de la population) alors que
les mutations sont appliquées avec une faible probabilité 0,03. L'algorithme génétique qui
automatise ces opérations se termine lorsque le génome est stable pour un nombre donné
d'itérations.
Ces travaux s'adressent cependant à un contexte diérent de celui de ce mémoire, mais
soulignent encore l'importance de la maîtrise de la gigue dans les applications temps réel
embarquées où le contexte distribué est un domaine croissant. Ils soulignent enn que
le choix particulier des dates d'activation pour la première émission permet également le
contrôle de la régularité d'émission des messages. Dans nos travaux, le choix des dates
2.3 Modèles de tâches spéciques 61
d'activation pour les tâches fait l'objet d'une attention toute particulière.
2.2.3 Méthodes exactes
Ces techniques sont généralement basées sur des techniques d'énumération, comme par
exemple les techniques de séparation et d'évaluation (branch and bound). Elles peuvent aussi
être basées sur la programmation linéaire, mais la diculté réside dans la modélisation du
problème d'ordonnancement notamment pour la modélisation des contraintes.
Dans [Grolleau 99b], Grolleau et al. proposent une méthode d'énumération exhaustive
des séquences d'ordonnancement possibles d'une conguration de tâches. Cette méthode uti-
lise le modèle des réseaux de Pétri, et les ordonnancements sont obtenus par la construction
du graphe de marquage. Le temps est quant à lui modélisé non pas par des temporisations
(type réseaux de Pétri temporisés), mais par un fonctionnement du réseau de Pétri à vitesse
maximale (règle du tir maximal).
Un des avantages signicatif de cette méthode, c'est qu'elle prend en compte tout type de
contrainte temporelle. Cette approche est cependant exponentielle en temps, et en espace,
et l'énumération va donc de pair avec une élimination au plus tôt de certaines branches du
graphe. En explorant le graphe de marquage, il est également possible de déterminer une
séquence d'ordonnancement optimale par rapport à certains critères.
Grolleau dans [Grolleau 99a] a présenté un outil appelé "PENSMARTS" implémentant
cette technique. Cet outil permet dans un premier temps de saisir une conguration de
tâches quelconque et de préciser un certain nombre de contraintes temporelles, comme la
gigue d'une tâche, le temps de réponse, ou encore la prise et la libération de ressources
critiques, etc.. Après une phase de calcul dont la durée dépend de la complexité du pro-
blème, l'outil fournit un ensemble de séquences valides respectant à la fois les contraintes
d'échéances, mais aussi les contraintes temporelles saisies en entrée. Une de ces séquences
peut nalement être reportée par exemple dans un séquenceur qui restituera alors l'ordre
d'exécution des tâches sur le processeur, dans le respect des gigues maximum des tâches,
spéciées dans le cahier des charges.
La recherche étant exhaustive, le nombre de séquences obtenues peut être très élevé.
Nous avons par exemple utilisé une application temps réel de contrôle que nous verrons
en détail dans le chapitre 5, pour laquelle nous disposons de 8 tâches temps réel et qui
mènent à une charge processeur de 70%. Le nombre de séquences possibles donné par l'outil
"PENSMARTS" est de l'ordre de 1097 séquences ! En rajoutant alors un critère sur une ou
plusieurs tâches, on peut réduire ce nombre et nalement obtenir un nombre raisonnable
de séquences, voire une seule séquence. Par exemple, en minimisant les temps de réponse
moyens de toutes les tâches, il ne reste plus que deux séquences possibles, et on peut alors
choisir celle qui possède le nombre de changements de contexte le plus faible.
2.3 Modèles de tâches spéciques
2.3.1 Modèle de tâche à distances temporelles contraintes DCTS
Han et Lin dans [Han 92] ont déni un modèle de tâche à distance temporelle contrainte
(distance-constrained task systems DCTS ) dans lequel la distance entre les ns d'exécution
62 État-de-l'Art
de deux instances successives d'une même tâche doit être inférieure ou égale à une certaine
valeur. Plus formellement, une tâche τi de ce modèle, est dénie par une séquence innie
d'instances (jobs) notée : Ji1, Ji2, Ji3, .... On dénit aussi pour la tâche τi une durée d'exécu-tion Ci et une contrainte de distance temporelle, notée ∆i. La n d'exécution d'une instance
j est repérée par eij (cf. gure 2.4) et la distance temporelle contrainte se traduit par les
relations : ei1 ≤ ∆i et ei,j+1 − eij ≤ ∆i pour j ≥ 1. Une hypothèse du modèle suppose
qu'une instance Jij ne peut commencer son exécution que si l'instance Ji,j−1 a terminé la
sienne. En outre, la date d'activation de Ji,j+1 est dénie dès la n d'exécution de Jij etla préemption des instances est autorisée. On dénit enn la densité de la tâche τi par :ρ(τi) = Ci
∆i, et la densité totale de la conguration par : ρ =
∑τiρ(τi).
Fig. 2.4: Le modèle de tâche à distances temporelles contraintes (DCTS).
L'ordonnancement des tâches de ce modèle peut être réalisé de plusieurs façons :
• Soit on suppose que les instances peuvent être préemptées arbitrairement (sur une
échelle des temps continue) et alors les auteurs de [Han 92] et [Han 96] montrent que
EDF ordonnance la conguration en posant Ti = ∆i.
• Soit on suppose, et c'est le cas le plus réaliste, que les instances ne peuvent être pré-
emptées que sur les points multiples de la granularité de l'ordonnanceur, et alors, dans
le cadre classique des ordonnancements préemptifs basés sur la priorité, on dénit pour
la tâche τi une période Ti telle que [Han 92, Han 96] :
Ti ≤ ∆i + Ci
2, (2.6)
construite de sorte que la plus grande durée entre les ns d'exécution de deux instances
successives (2Ti −Ci) soit inférieure à la contrainte de distance temporelle ∆i (cf. gure
2.5).
Le critère d'ordonnancement pour EDF dans ce dernier cas s'écrit alors par :
∑τi
Ci
Ti=∑τi
2Ci
Ci + ∆i≤ 1. (2.7)
où on suppose des tâches à échéances sur requêtes. Ce résultat est en fait vérié [Han 92,
Han 96] si la densité totale de la conguration ne dépasse pas la limite de 0,5, soit :
∑τi
Ci
∆i≤ 0,5. (2.8)
2.3 Modèles de tâches spéciques 63
Le problème qui apparaît avec cette démarche, se traduit par des exécutions plus fré-
quentes des tâches de la conguration, induisant alors une charge processeur plus impor-
tante, et rejoignant le principe du suréchantillonnage. Une autre technique d'ordonnance-
ment a donc été trouvée, elle fait appel à une transformation du problème d'ordonnancement
en un problème dont la résolution a été largement étudiée : c'est le problème du "pinwheel"
(the pinwheel problem) dont voici l'énoncé [Han 92, Han 96] :
Soit un n-uplet d'entiers positifs A = a1, a2, ..., an, le problème consiste à
trouver une séquence (S) de nombre pris parmi 1, 2, 3, ..., n de sorte qu'il y
ait toujours au moins un nombre i contenu dans toute sous-séquence de S de
longueur ai avec i choisi dans 1, 2, 3, ..., n.Par exemple, étant donné A = a1 = 2, a2 = 4, a3 = 4, une solution S à ce problème est
la séquence S = (1, 2, 1, 3, 1, 2, 1, 3, ...) où (1, 2, 1, 3) est répétée à l'inni. En eet i = 1 se
retrouve dans cette séquence tous les a1 = 2 nombres, i = 2 se retrouve dans cette séquencetous les a2 = 4 nombres, et i = 3 se retrouve dans cette séquence tous les a3 = 4 nombres.
Ce problème, largement étudié [Holte 89, Holte 92] a donné lieu à plusieurs algorithmes
d'ordonnancement [Chan 93, Chan 92] qui se diérencient les uns des autres par leur critère
d'ordonnançabilité basée sur la densité totale de la conguration de tâche considérée. A no-
ter que ces algorithmes mettent toujours en jeu un mécanisme d'ordonnancement préemptif
basé sur la priorité des instances.
Souhaitant donc se ramener au problème du "pinwheel", les auteurs de [Han 92, Han 96]
ont transposé les paramètres du modèle DCTS en posant2 ai = ∆i/Ci, qui ramène en
fait chaque tâche τi à une tâche de durée d'exécution unitaire, dont la contrainte de distancetemporelle est ai. Le problème du "pinwheel" revient alors à trouver une séquence où
chaque tâche τi (considérée comme unitaire) possède des instances séparées d'une distance
temporelle ai. Dans l'exemple ci-dessus, ai=1 = 2 représente la distance dans la séquence
séparant les instances de la tâche τ1 représentée par l'entier i = 1.Illustrons cette transformation au travers d'un exemple [Han 92], soit une tâche τi de
durée d'exécution Ci = 3,2 et de contrainte de distance temporelle ∆i = 9,5, on a ai =9,5/3,2 = 2. En supposant qu'on puisse résoudre le problème du "pinwheel", et que
les tâches soient nalement ordonnançables, deux instances successives quelconques de τidoivent donc avoir une contrainte maximum de distance temporelle de 2 (cf. gure 2.6-a).
En regroupant alors les 3,2 = 4 unités de temps successives attribuées à τi, on constate
que le critère de contrainte de distance temporelle est satisfait pour la tâche τi (cf. gure2.6-b : 8 < 9,5).
2 et représentent les opérateurs partie entière supérieure et partie entière inférieure.
Fig. 2.5: La plus grande distance temporelle entre les ns d'exécution de deux
instances successives.
64 État-de-l'Art
En passant par une phase de spécialisation de la conguration [Han 92, Han 96] qui
permet une adaptation plus ne des ai, les auteurs ont nalement montré qu'il existait un
algorithme d'ordonnancement (noté Sr) qui pouvait ordonnancer le système de tâches, dès
lors que le critère d'ordonnançabilité suivant était vérié :
Proposition 2.1 Dans le modèle DCTS, si la condition suivante est respectée,
ρ =∑τi
Ci
∆i
≤ n(2 1n − 1), (2.9)
alors, les n tâches (τi) sont ordonnançables.
Condition qui rejoint en fait le critère d'ordonnançabilité dans le contexte RM [Liu 73, Le-
hoczky 89] (même borne pour la charge processeur). La réciproque est néanmoins fausse,
puisque si ρ > n(21n − 1), cela ne signie pas nécessairement qu'il soit impossible d'ordon-
nancer avec (Sr) l'ensemble des n tâches. D'ailleurs les auteurs de [Han 96], rappellent que
le critère précédant provient d'un critère plus n, lié à la phase de spécialisation. Ce critère,
très spécique au modèle DCTS, montre que ce modèle est supérieur au modèle de tâche
périodique en terme de critère d'ordonnançabilité.
Ce modèle reste cependant lourd à utiliser lorsqu'il s'agit de mettre en ÷uvre les algo-
rithmes spéciques d'ordonnancement [Han 96]. De plus, ces algorithmes supposent que les
périodes des tâches peuvent être diminuées, ce qui, pour certaines applications temps réel,
peut poser quelques problèmes. Ce modèle a cependant l'avantage de garantir que la dis-
tance temporelle entre deux exécutions consécutives sera inférieure, ou égale à une certaine
limite, ce que ne garantissent pas les algorithmes RM, DM ou EDF avec le modèle de tâche
périodique.
Dans [Lin 96], Lin et Herkert mettent en exergue des situations dans lesquelles la gigue
peut apparaître dans le modèle DCTS et proposent alors des solutions pour la réduire.
En pratique dans les systèmes temps réel, les tâches partagent des ressources en exclusion
mutuelle. De plus, certaines d'entres elles, de par le cahier des charges, peuvent se voir
imposer des périodes non modiables. Enn, certaines tâches de la conguration initiale
Fig. 2.6: Passage de la conguration de tâches adaptée au problème du "pinw-
heel" (a), à la conguration de tâche réelle (b) : les contraintes de distance
temporelle sont satisfaites.
2.3 Modèles de tâches spéciques 65
peuvent être apériodiques. Autant de propriétés qui ne sont pas prises en compte dans
[Han 92, Han 96]. Lin et Herkert dans [Lin 96] proposent alors des solutions pour lesquelles
la gigue peut être réduite dans des proportions xées ou peut être annulée (cas du partage
de ressources).
D'une manière générale cependant, les auteurs soulignent qu'il restera inévitablement
de la gigue sur certaines tâches (celles liées par exemple aux apériodiques dans le modèle
DCTS) mais cette gigue reste mieux contrôlée avec l'approche du modèle DCTS, comparé
au modèle classique de tâches périodiques. Dans nos travaux, nous verrons que la maîtrise
de la gigue avec le modèle périodique est possible.
2.3.2 Modèle de tâche périodique enrichi
Cheng et Chen dans [Cheng 96] proposent de décrire une tâche τi par quatre paramètres
que sont la période (Ti), la durée d'exécution (Ci), la gigue minimum (λi) et la gigue
maximum (ηi). Dans ce modèle, les débuts d'exécution de deux instances successives d'une
tâche τi sont alors séparées d'au moins Ti−λi et d'au plus Ti + ηi (cf. gure 2.7). En outre,
l'exécution des tâches est supposée non préemptive et on désigne par si,j et ei,j les débutset les ns d'exécution de la jième instance d'une tâche τi. Comme dans le modèle DCTS,
l'activation d'une instance d'une tâche τi est eective lorsque son instance précédente a
terminé son exécution.
Fig. 2.7: Les débuts d'exécution de deux instances successives sont séparés d'au
moins Ti − λi et d'au plus Ti + ηi.
Cheng et al. décrivent alors sur ce modèle une technique permettant d'obtenir une
séquence d'ordonnancement dans laquelle les contraintes de gigues et les contraintes de
précédence entre les tâches sont respectées, ceci dans un contexte mono-processeur. La
technique est basée sur l'obtention d'une liste, chaînée par des pointeurs, et qui contient en
fait l'agencement des diérentes instances des tâches sur une période d'étude. La technique
est basée d'une part sur la détermination des intervalles d'exécution possibles des instances,
et d'autre part, sur l'utilisation d'algorithmes d'ordonnancement spéciques.
Une tâche τi prise dans une conguration à n tâches est dite ordonnançable dans ce
modèle si les équations suivantes sont respectées :
ei,j = si,j + Ci
s1,ni+1 = si,1 + ppcm(T1, ...Tn)si,j ≥ si,j−1 + Ti − λisi,j ≤ si,j−1 + Ti + ηi
66 État-de-l'Art
avec j ∈ (2, ..., ni + 1) et ni = ppcm(T1, ...Tn)/Ti. Ces équations forment des contraintes
temporelles relatives. Les auteurs transforment alors ces conditions en des conditions d'ap-
partenance de si,j à un intervalle [est(τ ji ), lst(τji )] où les bornes est(τ
ji ) et lst(τ
ji ) sont dénies
par :
est(τ ji ) = max (si,j−1 + Ti − λi, si,1 + (j − 1)Ti − (ni − (j − 1))ηi)
lst(τ ji ) = min (si,j−1 + Ti + ηi, si,1 + (j − 1)Ti − (ni − (j − 1))θi)
qui représentent respectivement le début d'exécution le plus tôt et le début d'exécution le
plus tard3. On distingue ensuite l'algorithme SLsF4, où la priorité la plus grande est donnée
à la tâche dont l'instance a le plus petit lst(τ ji ), on distingue aussi les algorithmes SFP5 et
SJF6 qui attribuent la priorité la plus grande suivant la période ou suivant la gigue.
Les algorithmes et la technique proposée sont là encore, assez délicats à mettre en
place, d'autant plus délicats qu'ils font appel à des algorithmes de recuit simulé lorsque les
communications considérées sont asynchrones, c'est-à-dire lorsque les tâches mises en jeu
dans les communications n'ont pas la même période.
Baruah et al. dans [Baruah 97] présentent une extension du modèle de tâche périodique
de Liu et Layland en ajoutant de la même façon que [Cheng 96] deux paramètres : la gigue
au plus tôt (λi) et la gigue au plus tard (ηi). Par dénition donc, la date d'activation de la
jième instance d'une tâche τi doit arriver dans l'intervalle du type [ri,1 +(j−1)Ti−λi; ri,1 +(j − 1)Ti + ηi] avec j ≥ 1. Deux modèles de gigue sont ensuite décrits par les auteurs :
• le modèle de gigue en cascade (cascading jitter model) dans lequel l'échéance de chaque
instance est exactement Di unités de temps processeur après le début d'exécution de
l'instance,
• et le modèle de gigue sans cascade (non-cascading jitter model) dans lequel l'échéance
de la jième instance d'une tâche τi se situe à la date : ri,1 + (j − 1)Ti + Di, et ce,
indépendamment du début réel d'exécution de l'instance.
Dans leur article, Baruah et al. ne cherchent pas à minimiser la gigue, mais plutôt à
s'en accommoder et à déterminer des résultats d'ordonnançabilité des systèmes à priorité
variable, sur lesquels EDF a été prouvé optimal. Ils dénissent ainsi la notion de gigue de
tolérance d'une tâche τi qui est en fait la gigue maximum tolérée sur la tâche, au delà de
laquelle la conguration n'est plus ordonnançable.
• Dans le cadre de la gigue sans cascade, ils proposent une transformation des attributs
des tâches an d'obtenir une conguration sans gigue, dont l'ordonnançabilité est assurée
si et seulement si l'ordonnançabilité de la conguration de départ est assurée. Dès lors,
en considérant l'algorithme de Leung et Merrill [Leung 80] qui montrent que l'analyse
d'ordonnançabilité d'un système de tâches périodiques peut être réalisé en un temps
O(Hln(n)) où H = ppcm(Ti) et n = nombre de tâches à ordonnancer, Baruah et al.
montrent que ce même algorithme peut réaliser l'analyse d'ordonnançabilité du modèle
prenant en compte la gigue dans le même temps.
3est est l'abréviation de earliest start time, et lst de latest start time.4SLsF pour Smallest Last-start-time (lst) First5SFP pour smallest period rst6SJF pour smallest jitter rst
2.4 Conclusion 67
• Pour le cas de la gigue en cascade, Baruah et al. obtiennent les mêmes résultats à ceci
près que la preuve est plus dicile que dans le cas de la gigue sans cascade [Baruah 97].
On peut faire cependant quelques remarques sur ce modèle : d'une part, on s'intéresse
seulement à la gigue qui mesure les durées entre deux instances successives d'une même
tâche, et d'autre part, on suppose que les paramètres λi et ηi sont facilement déterminés,
ce qui, en pratique n'est pas aussi simple [Zhou 98]. Ces résultats sont cependant très
intéressants du point de vue des critères d'ordonnançabilité en présence de gigue d'entrée
(incertitudes temporelles liées au matériel).
2.4 Conclusion
Dans ce chapitre, nous avons présenté les diérentes approches connues permettant de
maîtriser la gigue d'ordonnancement. Dans l'ensemble des études traitant de la gigue, nous
avons distingué l'approche en ligne et l'approche hors ligne.
Dans la première approche, la plupart des contributions sur le sujet préconisent de
modier les dates d'activations et/ou les délais critiques. Nous verrons dans le chapitre
suivant que nous avons généralisé cette idée en proposant dans le cadre des algorithmes
d'ordonnancement en ligne, un choix particulier de ces paramètres temporels, de sorte que
non seulement les contraintes d'échéances soient respectées, mais aussi les contraintes de
tâches régulières et les contraintes de précédence.
Dans la seconde approche, nous avons présenté succinctement des méthodes de recherche
approchée comme le recuit simulé ou les algorithmes génétiques. Ces méthodes permettent
de fournir une séquence d'ordonnancement dans laquelle les contraintes temporelles spéci-
ées dans le cahier des charges sont d'autant plus respectées que le temps de résolution est
important. Nous avons également évoqué les techniques de recherche exacte, basées sur une
énumération exhaustive des séquences valides.
Enn, dans une dernière section, nous nous sommes d'abord intéressés à un modèle
spécique à la maîtrise de la gigue : le modèle de tâche à distances temporelles contraintes.
Il permet de maîtriser la distance séparant les ns d'exécution de deux instances successives.
Ce modèle utilise cependant des algorithmes d'ordonnancement particuliers. Nous avons
ensuite évoqué un autre modèle de tâche, dont la caractéristique principale est de pouvoir
modéliser la gigue en entrée, c'est-à-dire celle liée aux incertitudes temporelles du matériel.
Bien que ne traitant pas directement de la gigue d'ordonnancement, cette contribution
apporte des résultats intéressants en terme d'ordonnançabilité de congurations en présence
d'incertitudes temporelles liées au matériel.
Dans le chapitre suivant, nous allons proposer une technique de traitement de la gigue
dans le contexte en ligne, basée sur un choix particulier des dates d'activation et des délais
critiques.
Bibliographie
[Baruah 90] Baruah S.K.,Howell R.R. etRosier L.E. Algorithms and complexity
concerning the preemptive scheduling of periodic, real-time tasks on one
processor. Real-Time Systems, 1990, vol 2, p 301324.
68 BIBLIOGRAPHIE
[Baruah 97] Baruah S.K., Chen D. et Mok A.K. Jitter concerns in periodic task
systems. Proc. of the 18th IEEE Real-Time Systems Symposium, RTSS'97.
Burlington, VT, USA, Dec. 1997. p 6877.
[Baruah 99] Baruah S. K., Buttazzo G., Gorinsky S. et Lipari G. Scheduling
periodic task systems to minimize output jitter. Proc. of the Inter. Conf.
on Real-Time Computing Systems and Applications. Hong-Kong, Dec.
1999. IEEE Computer Society Press, p 6269.
[Bate 99] Bate I. et Burns A. An approach to task attribute assignment for
uniprocessor systems. Proc. of the 11th EuroMicro on Real-time Systems.
York, UK, 1999. p 4653.
[Chan 92] Chan M.Y. et Chin F. General schedulers for the pinwheel problem
based on double-integer reduction., volume 41(6), chapitre Transactions
On Computers, p 755768. IEEE, June 1992.
[Chan 93] Chan M.Y. et Chin F. Algorithmica, volume 9, chapitre Schedulers for
Larger Classes of Pinwheel Instances, p 425462. 1993.
[Cheng 96] Cheng S.-T. et Chen C.-M. A cyclic scheduling approach for relative
timing requirements. Proc. of the 3rd IEEE Real-Time Application Work-
shop. Québec, Canada, 1996. p 160163.
[Coutinho 00a] Coutinho F., Fonseca J. A., Barreiros J. et Costa E. Jitter mi-
nimization with genetic algorithms. Proc. of the 3rd IEEE International
Workshop on Factory Communication Systems, WFCS'2000. Porto, Por-
tugal, 2000.
[Coutinho 00b] Coutinho F., Fonseca J. A., Barreiros J. etCosta E. Using genetic
algorithms to reduce jitter in control variables transmitted over can. Proc.
of the 7th International CAN Conference, ICC'2000. Amsterdam, The
Netherlands, Oct. 2000.
[Dertouzos 74] Dertouzos M.L. Control robotics : the procedural control of physical
processors. Proc. of IFIP Congress. 1974, p 807813.
[DiNatale 95] DiNatale M. et Stankovic A. Applicability of simulated annealing
methods to real-time scheduling and jitter control. Proc. of Real-Time
Systems Symposium, RTSS'95. Pisa, 1995. p 190199.
[Gerber 94] Gerber R., Hong S. et Saksena M. Guaranteeing end-to-end timing
constraints by calibrating intermediate processes. Proc. of the 15nd IEEEReal-Time Systems Symposium, RTSS'94. San Juan, Puerto Rico, Decem-
ber 1994. p 192203.
[Grolleau 99a] Grolleau E. Ordonnancement temps-réel hors-ligne optimal à l'aide de
réseaux de Pétri en environnement mono-processeur et multiprocesseur.
Thèse : ENSMA - Université de Poitiers, nov. 1999.
[Grolleau 99b] Grolleau E., Choquet-Geniet A. et Cottet F. Modélisation de
systèmes temps réel par réseaux de petri autonomes en vue de leur analyse
hors-ligne. Modélisation des Systèmes Réactifs, MSR'99. Cachan, France,
1999. p 1726.
BIBLIOGRAPHIE 69
[Gutiérrez 97] Gutiérrez J., Garcia J. et Harbour M. On the schedulability ana-
lysis for distributed real-time systems. Proc. of the 9th IEEE Euromicro
Conference. Toledo, Spain, June 1997. p 136143.
[Han 92] Han Ching-Chih et Lin Kwei-Jay. Scheduling distance-constrained
real-time tasks. Proc. of 13th IEEE Real-Time Systems Symposium. Phoe-
nix, AZ, U.S.A., Dec. 1992. p 300308.
[Han 96] Han C.-C., Lin K.-J. et Hou C.-J. Distance-constrained scheduling and
its applications to real-time systems. IEEE Transactions on Computers,
1996, vol 45(7), p 814826.
[Holte 89] Holte R., Mok A., Rosier L., Tulchinsky I. et Varvel D. The
pinwheel : A real-time scheduling problem. Proc. of the 22nd Hawaii In-
ternational Conference on System Science. Hawaii, U.S.A., Jan. 1989. p
693702.
[Holte 92] Holte R., Rosier L., Tulchinsky I. et Varvel D. Pinwheel sche-
duling with two distinct numbers. Theoritical Computer Science, volume
100, p 105135. June 1992.
[Kim 00] Kim T., Shin H. et Chang N. Deadline assignment to reduce output jit-
ter of real-time tasks. Proc. of the 16th Workshop on Distributed Computer
Control Systems, DCCS'00. Sydney, Australia, Nov. 2000. p 6772.
[Kirkpatrick 83] Kirkpatrick S., Gellatt C. D. et Vecchi M.P. Optimization by
simulated annealing. Science, 1983, vol 220, p 671680.
[Labetoulle 74] Labetoulle J. Un algorithme optimal pour la gestion des processus en
temps réel. Revue Française d'Automatique, Informatique et Recherche
Opérationnelle, Fév. 1974, p 1117.
[Lehoczky 89] Lehoczky J.P., Sha L. et Ding Y. The rate monotonic scheduling
algorithm : exact characterization and average case behavior. Proc. of the
10th IEEE Real-Time Systems Symposium, RTSS'89. Dec 1989, p 166171.
[Leung 80] Leung J. et Merrill M. A note on preemptive scheduling of periodic
real-time tasks. Information Processing Letters, 1980, vol 11(7), p 115118.
[Lin 96] Lin K.-J. et Herkert A. Jitter control in time-triggered systems. Proc.
of the 29th International Conf. on System Sciences. Hawaiï, U.S.A., 1996.
p 451459.
[Liu 73] Liu C.L. et Layland J.W. Scheduling algorithms for mutltiprogramming
in real-time environnement. Journal of the ACM, 1973, vol 20(1), p 4661.
[Redell 02] Redell O. et Sanfridson M. Exact best-case response time analy-
sis of xed priority scheduled tasks. Proc. of the 14th IEEE Euromicro
Conference. Vienna, Austria, June 2002.
[Ripoll 96] Ripoll I., Crespo A. et Mok A.K. Improvement in feasibility testing
for real-time tasks. Real-Time Systems, 1996, vol 11(1), p 1939.
[Zhou 98] Zhou L., Shin K.G. et Rundensteiner E.A. Rate-monotonic sche-
duling in the presence of timing unpredictability. Proc. of the 4th IEEE
70 BIBLIOGRAPHIE
Real-Time Technology and Applications Symposium. Denver CO, USA,
1998. p 2227.
Chapitre 3
Technique de Traitement de la Gigue
dans les Systèmes Temps Réel
Dans ce chapitre contributif, nous introduisons la technique de contrôle de la gigue
d'ordonnancement pour le contexte en ligne. Après avoir décrit dans la première section, les
diérents outils mis en ÷uvre dans notre technique de traitement de la gigue, nous verrons
d'abord comment annuler la gigue des tâches régulières1, puis nous verrons comment il
est possible de borner la gigue de ces tâches. Dans la section suivante, nous étudions la
compatibilité de notre technique avec le cas de tâches partageant des ressources critiques.
Dans une dernière section, nous étendons le domaine d'application de notre technique à
d'autres paramètres temporels que sont la gigue de bout en bout d'une activité et les temps
de réponse maximum d'une tâche, et d'une activité. Des exemples d'application temps réel
constituée de tâches régulières et/ou d'activités jalonneront l'ensemble de ces sections.
Décrivons tout d'abord les notations et les conventions utilisées dans ce chapitre. On
considère deux ensembles de tâches disjoints, notés R et NR, dont l'union décrit l'ensembledes tâches d'une application temps réel. Le premier ensemble R correspond aux tâches
que nous voulons régulières en terme d'exécution, quant au second, il décrit les tâches non
nécessairement régulières. Soient nR et nNR deux entiers positifs tels que nR = card(R) etnNR = card(NR) : ces entiers permettent de décrire les ensembles R et NR du point de
vue de leurs tâches : R = τ1R, ..., τnR
et NR = τ1NR, ..., τnNR
. On a en outre la relation
suivante : nR + nNR = card(R ∪NR).Rappelons que l'ensemble des tâches considérées dans ce mémoire sont supposées pé-
riodiques, les précédences entre les tâches ne sont que des précédences simples, et les or-
donnancements sont de type en ligne, et nous utiliserons principalement les algorithmes
DM, EDF, et ceux basés sur l'aectation d'une priorité xe. On suppose par ailleurs que
le paramètre période des tâches considérées n'est pas modiable : il est en eet souvent
conditionné par la dynamique du procédé et fait donc partie des contraintes temporelles
de base du cahier des charges. Enn, on suppose que la redénition éventuelle d'une date
d'activation initiale n'entraîne pas une redénition du délai critique : les échéances absolues
de la conguration initiale ne sont donc pas nécessairement respectées pour les tâches dont
1Rappelons que nous entendons par tâche régulière, une tâche qui possède des contraintes de régularité
d'exécution (cf. dénitions dans la section 1.1).
72 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
on redénit les dates d'activation (on parle de systèmes à date d'activation libre, oset free
systems).
Le traitement de la gigue des tâches régulières dans le contexte des algorithmes d'ordon-
nancement en ligne repose sur 2 observations essentielles :
• Si deux tâches régulières ont des fenêtres d'exécution2 à intersection non nulle, alors
l'une d'entre elle peut présenter de la gigue de régularité, ou de la gigue de cohésion
(d'autant plus si les périodes des deux tâches sont diérentes l'une de l'autre).
• Si une tâche non nécessairement régulière a une priorité plus grande qu'une tâche ré-
gulière, et si leurs fenêtres d'exécution se chevauchent, cela peut conduire également à
de la gigue.
Ces deux observations nous indiquent des conditions susantes d'annulation de la gigue
de régularité : d'une part désynchroniser les fenêtres d'exécutions des tâches de R, etd'autres part imposer des priorités plus grandes aux tâches de R, comparées à celles des
tâches de NR. Ces conditions ne sont cependant pas nécessaires : en eet, dans le cadre de
tâches régulières de même période, il est possible d'avoir des fenêtres d'exécution décalées
avec une gigue de régularité nulle. Par exemple, dans la séquence de la gure 3.1, les fenêtres
d'exécution se chevauchent mais la gigue de régularité reste nulle. Ces conditions restent
néanmoins très intéressantes, car leur mise en ÷uvre, et nous le verrons dans ce chapitre,
fait appel à des redénitions simples des paramètres temporels des tâches. Le principe du
traitement de la gigue va consister à satisfaire ou à se rapprocher de ces deux conditions.
Fig. 3.1: Non chevauchement des fenêtres d'exécution : condition susante mais
non nécessaire pour l'annulation de la gigue.
Dans le souci de pouvoir maîtriser la gigue, ces deux idées nous ont amenés à dénir un
ensemble d'outils qui seront utilisés dans ce chapitre. Ces outils sont au nombre de quatre
et sont présentés dans la section suivante dans leur version générique.
3.1 Méthodologie de traitement de la gigue
Les outils introduits dans cette section sont les "briques de base" nécessaires à l'applica-
tion de la technique de traitement de la gigue. Le premier outil présenté dans cette section
s'intéresse au décalage des fenêtres d'exécution d'un ensemble de tâches, ceci au travers
d'une redénition des dates de première activation. Le deuxième outil prend en compte, si
nécessaire, les contraintes de précédences parmi les tâches de la conguration. Le troisième
2Rappel : les fenêtres d'exécution d'une tâches τi retenues dans ce rapport sont représentées par les
intervalles [|ri,k; ei,k|] avec k ∈ N∗ (cf. section 1.3 en page 24).
3.1 Méthodologie de traitement de la gigue 73
s'intéresse à la redénition des priorités d'un ensemble de tâches par rapport aux autres
tâches de la conguration. Le quatrième outil enn, vérie si la nouvelle conguration de
tâche proposée est bien ordonnançable à l'aide de tests analytiques ou d'une simulation.
3.1.1 Principe de désynchronisation
3.1.1.1 Désynchronisation par l'exemple
Soit une conguration de tâches (τ1, τ2, τ3) décrite dans le tableau 3.1. Ordonnançons
cette conguration selon les priorités xes qui sont telles que : Prio1 > Prio2 > Prio3. Lerésultat est donné dans la séquence de la gure 3.2. Dans cette séquence, τ2 est perturbée
dans son exécution par τ1, et τ3 l'est aussi par τ1 puis τ2. S'ensuit alors de la gigue sur
les tâches τ2 et τ3. Une solution intéressante proposée par la désynchronisation des dates
de début d'exécution des tâches τ1, τ2 et τ3, est illustrée sur la gure 3.3. A noter que
la période d'étude vaut 16 dans la conguration initiale et se trouve portée à 38 dans la
seconde conguration, où la nouvelle distribution des ri,1, à savoir (r1,1, r2,1, r3,1) = (1, 0, 6)annule la gigue de τ2 et τ3 (exécutions régulières). Plus généralement, dans la suite de cette
sous-section, nous allons chercher pour un ensemble de tâches, des ri,1 de sorte que leurs
fenêtres d'exécutions ne se perturbent pas entre elles.
Tab. 3.1: Exemple de conguration de tâches avec gigue.ri,1 Ci Di Ti Prioi
τ1 0 3 16 16 3
τ2 0 1 4 4 2
τ3 0 2 8 8 1
Fig. 3.2: Perturbation de τ2 par τ1, de τ3 par τ1 puis τ2 : gigue sur τ2 et τ3. Lesfenêtres d'exécution des 3 tâches se chevauchent - Prio1 > Prio2 > Prio3.
3.1.1.2 Le problème de désynchronisation
Soit (τ1, ..., τn) un ensemble de tâches avec comme paramètre : ri,1, la date de première
activation de la tâche τi, Wi, un paramètre qui dénit la largeur maximum demandée pour
les fenêtres d'exécution, et enn Ti la période de la tâche (cf gure 3.4). Ces paramètres
doivent vérier la relation ∀i ∈ [|1;n|] 0 < Ci ≤ Wi ≤ Di. Pour établir le problème général
de désynchronisation des tâches, nous avons besoin au préalable de la proposition suivante :
74 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
Proposition 3.1 Soient deux tâches τi et τj, dont les largeurs de fenêtre d'exécutionsont unitaires, c'est-à-dire Wi = Ci = 1. On suppose que Ti et Tj, les périodes de cesdeux tâches, ne sont par premières entre elles, c'est-à-dire Ti ∧ Tj > 1. Ces tâchesne s'activent pas en même temps si et seulement si :
ri,1 − rj,1 = 0mod(Ti ∧ Tj) (3.1)
où ∧ représente le symbole mathématique du pgcd et, mod, le symbole modulo.
Démo: Ce résultat provient directement de l'application du theorème du reste chinois
généralisé [Goossens 03, Knuth 69, Cottet 99]. Dès lors que ri,1 − rj,1 = 0mod(Ti ∧ Tj),avec Ti ∧ Tj > 1, ce théorème assure l'existence d'un instant t tel que t = ri,1mod(Ti) ett = rj,1mod(Tj), et réciproquement. La non activation des deux tâches à un même instant,
c'est-à-dire la non existence de t tel que t = ri,1mod(Ti) et t = rj,1mod(Tj), est donc
équivalente à la vérication de l'expression ri,1 − rj,1 = 0mod(Ti ∧ Tj). Si les conditions de la proposition sont réunies, l'état de la gure 3.5-a est évité. Soit
maintenant une tâche τi de fenêtre d'exécution de largeur unitaire (Wi = Ci = 1) et soit unetâche τj de fenêtre d'exécution de largeur Wj . Nous allons alors montrer, selon le principe
du raisonnement par récurrence, que la propriété décrite par :
Fig. 3.3: Séquence d'ordonnancement sans gigue : les fenêtres d'exécution des 3tâches ne se chevauchent plus - Prio1 > Prio2 > Prio3.
Fig. 3.4: Dénition des paramètres pour le problème de désynchronisation. Wi
représente la largeur maximale pour les fenêtres d'exécution des instances de τi.
3.1 Méthodologie de traitement de la gigue 75
L'activation de la tâche τi n'intervient pas pendant une durée de Wj faisant suite à
l'activation de τj si et seulement si
ri,1 − rj,1 = 0mod(Ti ∧ Tj)ri,1 − rj,1 = 1mod(Ti ∧ Tj)
...ri,1 − rj,1 = Wj − 1mod(Ti ∧ Tj)
où Ti et Tj sont nécessairement non premiers entre eux.
est vraie pour tout Wj entier naturel non nul.
• Cette propriété est vraie pour le cas Wj = 1 (cf. proposition 3.1 ci-dessus).
• Pour le cas Wj = 2, nous voulons éviter l'état illustré sur la gure 3.5-b. En d'autres
termes, nous imposons à la date d'activation de τi de ne pas se trouver dans la largeur dela fenêtre d'exécution de τj , soit dans une largeur deWj = 2. De la proposition ci-dessus,on déduit qu'il faut trouver un couple d'entiers naturels (ri,1, rj,1) vériant :
ri,1 − rj,1 = 0mod(Ti ∧ Tj)ri,1 − (rj,1 + 1) = 0mod(Ti ∧ Tj) (3.2)
où Ti et Tj sont nécessairement non premiers entre eux. La propriété est donc vraie aussi
pour ce cas.
• Supposons cette propriété vraie pour le cas Wj = n − 1, et démontrons qu'elle l'est
toujours pour le cas Wj = n. Prenons donc une fenêtre d'exécution de largeur Wj = npour la tâche τj. On sait par hypothèse que τi ne vient pas s'activer pendant les (n− 1)unités de temps processeur qui font suite à l'activation de τj (cf. gure 3.5-c), c'est-
à-dire que les dates d'activation de τi ne sont pas dénies dans les intervalles du type
[rj,k; rj,k + (n− 2)] avec k entier naturel non nul. D'après la proposition ci-dessus, pour
qu'en plus, τi ne vienne pas s'activer n unités de temps processeur après l'activation de
τj , il sut que :
ri,1 − (rj,1 + n− 1) = 0 mod(Ti ∧ Tj),
qui montre alors que la propriété est vraie pour Wj = n et qui donc est vraie pour tout
Wj de N.
Ce problème est symétrique et nalement, on obtient la proposition suivante :
76 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
Proposition 3.2 Soient deux tâches τi et τj dont les exécutions sont prévues dansdes intervalles de largeur Wi et Wj, intervalles démarrant aux dates d'activation de
leurs instances respectives. La tâche τi ne s'active pas pendant la durée de la fenêtre
d'exécution de τj (et réciproquement), si et seulement si :
ri,1 − rj,1 = 0mod(Ti ∧ Tj)et
ri,1 − rj,1 = 1mod(Ti ∧ Tj)ri,1 − rj,1 = 2mod(Ti ∧ Tj)
...ri,1 − rj,1 = Wj − 1mod(Ti ∧ Tj)
et
rj,1 − ri,1 = 1mod(Ti ∧ Tj)rj,1 − ri,1 = 2mod(Ti ∧ Tj)
...rj,1 − ri,1 = Wi − 1mod(Ti ∧ Tj)
(3.3)
où Ti et Tj sont nécessairement non premiers entre eux.
La généralisation de ce problème à un ensemble de tâches de cardinal n conduit alors
au problème de désynchronisation suivant :
Fig. 3.5: Les diérents états à éviter de sorte que la tâche τi ne perturbe pas
l'exécution de la tâche τj .
3.1 Méthodologie de traitement de la gigue 77
Problème de désynchronisation.
Soit (τ1, ..., τn) un ensemble de tâches à désynchroniser. Pour toutes les tâches τi, ondénit le paramètre Wi qui caractérise depuis les dates d'activation des instances de
τi, le délai au terme duquel, il est prévu que l'exécution de l'instance de la tâche soit
terminée. Le principe de désynchronisation des tâches revient à chercher un n-uplet
(r1,1, ..., rn,1) qui vérie :
∀(i, j) ∈ [|1;n|] i < j
ri,1 − rj,1 = 0mod(Ti ∧ Tj)et
ri,1 − rj,1 = 1mod(Ti ∧ Tj)ri,1 − rj,1 = 2mod(Ti ∧ Tj)
...ri,1 − rj,1 = Wj − 1mod(Ti ∧ Tj)
et
rj,1 − ri,1 = 1mod(Ti ∧ Tj)rj,1 − ri,1 = 2mod(Ti ∧ Tj)
...rj,1 − ri,1 = Wi − 1mod(Ti ∧ Tj)
(3.4)
où Ti et Tj sont nécessairement non premiers entre eux.
3.1.1.3 Technique de résolution
Le problème précédent est quelque peu complexe surtout lorsque le nombre n augmente,
cependant, nous pouvons illustrer de manière simple les équations qui le constituent. En
eet, sur de telles équations, on travaille sur Z/pZ, avec p = Ti ∧ Tj , et on peut illustrer
les valeurs interdites de rj,1 − ri,1 sur un cercle de périmètre p (cf. gure 3.6 : la partie
grisée correspond aux valeurs interdites de rj,1 − ri,1). Il existe cependant quelques outils
analytiques qui, dans des conditions très particulières, peuvent donner des réponses à ce
problème de désynchronisation. Nous avons par exemple la proposition suivante :
Proposition 3.3 Soit un ensemble de tâches (τ1, ..., τn) à désynchroniser, dont les
intervalles d'exécution prévus (au sens de Wi) sont unitaires, c'est-à-dire que Wi =Ci = 1. Si min
i,j(Ti ∧ Tj) ≥ n, alors il existe des solutions au problème posé. Dans
ce cas, le n-uplet (r1,1, r2,1, ..., rn,1) = (0, 1, 2, ..., n− 1) est solution au problème de
désynchronisation ainsi que toute permutation de ses n nombres.
Démo: Posons m = mini,j
(Ti ∧ Tj), et di,j = Ti ∧ Tj , et montrons que (r1,1, r2,1, ..., rn,1) =
(0, 1, 2, ..., n− 1) est solution du problème de désynchronisation avec pour chaque i, Wi =Ci = 1. Pour qu'un n-uplet soit solution de ce problème, il sut que tous les ri,k soient
compris entre 0 et (m− 1), et qu'ils soient tous distincts, car alors, leurs classes respectivesmodulo di,j seront toutes distinctes. Le n-uplet proposé vérie ces critères ainsi que toutespermutations de ses n nombres.
78 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
Ce problème d'arithmétique est cependant complexe, et lorsque les outils analytiques
démontrent l'existence d'une solution sans pouvoir la préciser, nous faisons appel à des
techniques d'énumération avec une recherche systématique de tous les ri,1 possibles. Si de
plus l'existence n'est pas certaine, on peut utiliser directement ce genre de technique en se
xant une durée de recherche maximum. Un algorithme de recherche systématique de toutes
les solutions est d'ailleurs proposé dans l'annexe A. Sa complexité en temps, calculée dans
le pire cas est en Θ(n2(maxk(Tk −Wk))n maxk(Wk)). La durée de l'algorithme augmente
donc de manière exponentielle en fonction de maxk(Tk −Wk) et de manière polynomiale
en fonction de maxk(Wk) et du nombre de tâches. Notons par ailleurs que d'une part, les
périodes des tâches doivent nécessairement être non premières entre elles deux à deux pour
avoir une solution, et que d'autre part, on favorise d'autant mieux l'obtention de solutions,
si p = Ti ∧ Tj est grand, ce qui revient à dire que les périodes des tâches doivent être
multiples entre elles (par exemple Ti = 5 × Tj). Enn, une remarque à faire avant de clore
ce paragraphe, concerne le nombre de solutions à ce problème de désynchronisation : comme
on travaille dans des ensembles du type Z/pZ, il n'est pas rare d'avoir plusieurs solutionsau problème et non une unique solution.
Fig. 3.6: En grisé, les valeurs de rj,1−ri,1 interdites dans Z/pZ avec p = Ti∧Tj .
3.1.2 Maintien des relations de précédences
Les conditions susantes sur les attributs temporels de deux tâches τi et τj , permettant
de modéliser une relation de précédence du type τi → τj , sont décrites dans l'expression 1.2
(page 30) : la deuxième condition dépend alors explicitement de l'algorithme d'ordonnan-
cement choisi.
Les conditions deviennent avec DM : ri,1 ≤ rj,1Di < Dj
(3.5)
Avec EDF, les conditions de la relation (1.2), se traduisent par les conditions :ri,1 < rj,1Di = Ci
(3.6)
3.1 Méthodologie de traitement de la gigue 79
de sorte que lorsque la tâche τi demande le processeur, ceci avant la tâche τj , elle l'obtientde suite, sans quoi il y a faute temporelle et la conguration n'est pas ordonnançable.
Ces conditions sont eectivement moins contraignantes que celles de Chetto [Chetto 90],
mais l'ordonnançabilité du nouveau système de tâches qui en découle n'est pas automati-
quement réalisé, ceci contrairement aux conditions de Chetto où l'on montre, sous certaines
conditions, qu'il y a équivalence en terme d'ordonnançabilité entre les deux systèmes de
tâches. Le choix des conditions de Blazewicz plutôt que celles de Chetto découle en fait
de la façon dont sont choisis les nouveaux paramètres temporels des tâches. Nous verrons
que le principe de traitement de la gigue implique une première étape qui conduit à un
ensemble de solutions en terme de dates d'activation ri,k. Ces dates d'activations sont doncdéterminées et les conditions de Chetto sont plus diciles à appliquer que celles de Blaze-
wicz : en eet dans le premier cas, il faudrait re-modier les dates d'activation, hypothèse
que l'on écarte, alors que dans le second cas, il sut d'éliminer certaines dates d'activation
ne respectant pas les conditions.
3.1.3 Modication des priorités
Dans cette sous-section, on souhaite redénir les priorités d'un ensemble de tâches,
appelé R, an de les rendre plus prioritaires que les tâches d'un autre ensemble, appelé
NR. On suppose bien évidemment que ces deux ensembles sont disjoints. Cette redénition
des priorités dépend de l'algorithme d'ordonnancement choisi.
RM : Les priorités sont aectées en fonction de la période : plus la valeur de la période
est petite, plus la priorité est grande. Ainsi, la condition à respecter pour notre redénition
est :
(∀τi ∈ R) Di ≤ Ti < minτj∈NR
(Tj). (3.7)
Le changement des priorités nécessitant une modication des périodes des tâches, contraire à
l'hypothèse formulée dans ces travaux, l'algorithme RM ne pourra donc pas être directement
utilisé pour le traitement de la gigue, sauf dans le cas rare où les périodes des tâches
respectent déjà cet ordre des priorités.
DM : Les priorités sont aectées selon le délai critique : plus sa valeur est faible, plus
la priorité de la tâche qui lui est attachée est grande. La condition à respecter pour notre
redénition des priorités est alors :
(∀τi ∈ R) Ci ≤ Di < minτj∈NR
(Dj). (3.8)
EDF : Dans ce contexte, les priorités sont variables, c'est-à-dire qu'elles évoluent en
fonction du temps. Il est donc dicile de prévoir a priori quelle sera la priorité d'une tâche
τi de R face à une tâche τj de NR à un instant t, sauf si une simulation d'ordonnancement
est adoptée. Il existe cependant une condition, certes forte, mais permettant d'imposer a
priori cette redénition des priorités. Il sut pour cela d'imposer :
(∀τi ∈ R) Di = Ci, (3.9)
80 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
ainsi, lorsqu'une tâche τi de R demandera le processeur elle devra nécessairement l'obtenir
sans quoi il y aura faute temporelle et la conguration ne sera pas ordonnançable.
3.1.4 Test d'ordonnançabilité
Le test d'ordonnançabilité se fait principalement à l'aide d'outil de simulation. Cepen-
dant, quelques outils analytiques peuvent être utilisés. Par exemple, comme nous n'avons
pas pris les conditions les plus restrictives (celles de Chetto), dans le paragraphe traitant
des relations de précédence, nous pouvons vérier dans un premier temps si les durées d'exé-
cution des tâches τi et τj tiennent bien dans les nouveaux intervalles d'exécution possible
de τi et τj . Soit par exemple, une activité formée de deux tâches, qui vérient : τi → τj .Supposons les diérents paramètres des tâches redénis selon les trois premiers outils dé-
crits dans cette section. Soient donc r∗i,1 la nouvelle date de première activation de τi et dj,1l'échéance absolue de la tâche τj. Un critère analytique nécessaire à respecter est alors :
dj,1 − r∗i,1 ≥ Ci + Cj . Si le critère est faux, nous pouvons armer que la nouvelle congu-
ration n'est pas ordonnançable. A contrario, si le critère est vrai, nous devons continuer
notre étude d'ordonnançabilité. D'autres critères analytiques basés sur des analyses du pire
temps de réponse des tâches, peuvent répondre à cette question d'ordonnançabilité, mais ce
ne sont que des critères susants (analyse holistique par exemple [Richard 02, Tindell 94]).
Finalement, puisqu'il n'existe pas de critère simple de validation de l'ordonnançabilité
pour le cas de tâches à départ diéré dont les échéances ne sont pas sur les requêtes, nous
aurons recours par la suite à des outils de simulation d'ordonnancement. Notons que ce
problème de la recherche de l'ordonnançabilité d'une telle conguration de tâches est un
problème co-NP-complet [Baruah 90].
3.2 Annulation de la gigue de régularité
3.2.1 Principe en quatre étapes
La technique de suppression de la gigue de régularité repose sur les quatre outils présen-
tés dans la section précédente et qu'il faut adapter aux particularités des tâches régulières.
Le principe de cette technique reprend les deux observations mentionnées au début de ce
chapitre : le non chevauchement des fenêtres d'exécution, et une priorité plus grande aux
tâches régulières, assurent une maîtrise de la gigue. De ces deux observations, on peut dé-
duire des conditions susantes à respecter par les paramètres des tâches, pour que la gigue
soit annulée. La mise en ÷uvre de ces conditions se fait en quatre étapes :
Etape 1 Désynchronisation des fenêtres d'exécution des tâches régulières de sorte qu'elles
ne se chevauchent pas entre elles,
Etape 2 Prise en compte des contraintes de précédence par modication des attributs
des tâches,
Etape 3 Rendre les tâches régulières (R) plus prioritaires que les tâches non nécessaire-
ment régulières (NR) an que ces dernières ne viennent pas perturber l'exécution des
premières,
Etape 4 Vérication de l'ordonnançabilité des nouvelles congurations.
3.2 Annulation de la gigue de régularité 81
Pour une conguration de tâches indépendantes, la deuxième étape n'est pas réalisée.
Dans cette section, nous allons dans un premier temps donner les résultats pour une
conguration de tâches indépendantes dont les durées d'exécution des tâches régulières sont
plus grandes que la granularité du processeur. Puis, nous verrons le cas de congurations de
tâches dépendantes. Enn, des exemples viendront illustrer cette technique pour en faciliter
la compréhension.
3.2.2 Cas des tâches indépendantes
Comme DiNatale et Stankovic l'ont souligné dans [DiNatale 95], le contrôle de la gigue
est très délicat dans le cadre de tâches pouvant être préemptées pendant leur exécution.
Aussi, avons-nous construit dans un premier temps, notre technique en imposant aux tâches
régulières de s'exécuter sans préemption : la durée de la fenêtre d'exécution désirée est donc
égale à Ci. En outre, on impose le début d'exécution des diérentes instances de ces tâches
dès leurs activations : le paramètre Wi déni dans le paragraphe 3.1.1.2 est donc aussi égal
à Ci. Au nal, on obtient un ordonnancement des tâches régulières du type de celui de
la gure 3.7. Pour en arriver à ce type d'ordonnancement, nous procédons en fait à une
modication de certains attributs des tâches régulières : les délais critiques et les dates
d'activation. Cette modication met en jeu les étapes 1, 3 et 4 décrites ci-dessus et utilise
les outils présentés dans la section précédente.
Fig. 3.7: Exécution régulière et sans préemption d'une tâche de R.
Illustrons cette technique au travers d'un exemple. Soit une conguration de tâches dont
deux sont à contraintes de régularité stricte (τAcq1, τAcq2) (cf. tableau 3.2 pour description).
L'ordonnancement de ces tâches selon DM ou EDF conduit à des gigues sur les tâches
régulières qui ne sont pas négligeables (cf. tableau 3.2). On modie alors étape par étape
les attributs temporels de ces tâches :
Etape 1 On considère le problème de désynchronisation de la section 3.1.1.2 pour les
deux tâches régulières avec Wi = Ci. A l'aide de l'algorithme de l'annexe A, on obtient
alors un ensemble de 377 couples (rAcq1,1, rAcq2,1) solutions à ce problème. Le couple
(rAcq1,1, rAcq2,1) = (0, 2) est par exemple une solution.
Etape 3 Pour garantir une exécution sans préemption des tâches régulières, il sut de
les rendre plus prioritaires que les tâches sans contrainte de régularité (NR). On appliquealors les relations décrites dans le paragraphe 3.1.3 : en DM, l'équation 3.8 donne dans
les conditions les moins restrictives, des délais critiques tels que : (D1, D2) = (7, 7). EnEDF, on obtient de l'équation 3.9 les délais critiques suivants : (D1, D2) = (2, 2).
Etape 4 On choisit parmi les nouvelles congurations possibles, celles qui conduisent à
des congurations ordonnançables. Pour cela, on utilise un outil de simulation d'ordon-
nancement mono-processeur.
82 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
Par exemple, le couple solution proposé dans l'étape 1 conduit nalement à une congura-
tion ordonnançable en DM et en EDF, avec le résultat prévu sur les tâches régulières : les
gigues sont annulées. Nous avons reporté dans le tableau 3.3 la nouvelle conguration de
tâches, dont la séquence d'exécution pour DM est donnée dans la gure 3.8.
Tab. 3.2: Exemple de conguration de tâches, avec de la gigue sur deux tâches
régulières dans le contexte d'ordonnancement DM ou EDF.Tâches ri,1 Ci Di Ti Gigues (%) DM / EDF
τAcq1(Acquisition) 0 2 16 16 11,5 / 7,7
τTrait1(Traitement) 0 1 16 16
τAcq2(Acquisition) 0 2 32 32 12,5 / 8,9
τTrait2−1(Traitement) 0 4 31 32
τTrait2−2(Traitement) 0 1 32 32
τTrait3(Traitement) 0 4 14 14
τCont3(Contrôle) 0 1 13 14
τCont4(Contrôle) 0 1 8 8
Tab. 3.3: Nouvelle conguration de tâches après application de la technique
d'annulation de la gigue.Tâches ri,1 Ci Di DM / EDF Ti Gigues (%) DM / EDF
τAcq1(Acquisition) 0 2 7 / 2 16 0 / 0
τTrait1(Traitement) 0 1 16 16
τAcq2(Acquisition) 2 2 7 / 2 32 0 / 0
τTrait2−1(Traitement) 0 4 31 32
τTrait2−2(Traitement) 0 1 32 32
τTrait3(Traitement) 0 4 14 14
τCont3(Contrôle) 0 1 13 14
τCont4(Contrôle) 0 1 8 8
3.2.3 Cas des tâches dépendantes
Dans notre technique de traitement de la gigue de régularité, nous allons prendre en
compte des tâches dépendantes les unes des autres. Cependant, avant de présenter la tech-
nique proposée, nous allons caractériser les diérents types de relations de précédence que
nous pouvons rencontrer dans ce contexte.
3.2.3.1 Les diérents types de relation de précédence et les domaines d'appli-
cations des quatre étapes.
Considérons les deux ensembles de tâches R et NR, et identions par τR, une tâche del'ensemble R et par τNR, une tâche de l'ensemble NR. Dans la gure 3.9, nous avons alors
3.2 Annulation de la gigue de régularité 83
considéré une application temps réel quelconque constituée d'un ensemble de tâches, sur
lesquelles nous avons reporté les relations de précédence qui pourraient intervenir entre les
tâches de ces deux ensembles.
Dans cette gure, les diérents types de précédences sont numérotés de P1 à P4 et sont
telles que :
P1 : τR → τNR
P2 : τR → τRP3 : τNR → τNR
P4 : τNR → τR
(3.10)
Dans la suite, on désignera par k le nombre de tâches mises en jeu dans les précédences
(dans la gure 3.9, k = 12). A noter cependant, et nous le verrons dans les paragraphes
qui suivent, que la relation de précédence typée P4 est impossible dans le cadre d'une
annulation de la gigue. En revanche, on pourra la considérer lorsque nous passerons à la
section concernant l'encadrement de la gigue.
A l'aide de cette illustration (gure 3.9), décrivons maintenant les diérents domaines
d'application des quatre étapes décrites dans le début de cette section, ainsi que leur mé-
Fig. 3.8: Une partie de la séquence d'exécution de la nouvelle conguration de
tâches ordonnancées suivant DM : les tâches τAcq1 et τAcq2 sont régulièrement
exécutées.
Fig. 3.9: Une application temps réel avec les diérentes types possibles de pré-
cédences (τR : tâche régulière, τNR : tâche non nécessairement régulière).
84 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
canisme de base. Le problème de désynchronisation de l'étape 1 s'applique d'abord à l'en-
semble des tâches régulières (τR) de l'application (celle de la région E1 ∪ E3 de la gure
3.10). Dans l'ensemble des nR-uplets du type r1,1, ..., rnR,1, solutions de ce problème, nous
choisissons ensuite ceux dont les dates d'activation vérient les contraintes de précédence
(c'est le début de l'étape 2). Nous disposons alors d'un ensemble de nR-uplets solutions duproblème de désynchronisation, et respectant les contraintes de précédence. Parallèlement
à ces solutions, nous aurons un ensemble de conditions de précédence s'appliquant d'une
part, aux dates d'activation de certaines tâches de NR (celles de la région E4 de la gure
3.10), et s'appliquant, d'autre part, aux délais critiques des k tâches mises en jeu dans une
relation de précédence (celles de la région E3 ∪ E4 de la gure 3.10). Parmi les diérentes
possibilités oertes à ces délais critiques, il nous faut alors choisir au cours de l'étape 3, ceux
qui répondent à notre besoin d'imposer une plus grande priorité aux tâches de R (E1 ∪E3)
comparées à celles de NR (E2 ∪E4). Au nal, on choisit une solution en terme de ri,1 etDi pour la région E1 ∪ E3, et en terme de ri,1 et Di pour la région E4, ceci parmi
l'ensemble des solutions qui répondent au problème de désynchronisation, au problème des
précédences, et au problème de gestion des priorités. Cette solution prise au hasard parmi
l'ensemble des congurations possibles de tâches, dénit en fait des nouveaux attributs
temporels pour la conguration de tâches, dont il faut alors vérier l'ordonnançabilité.
Fig. 3.10: Les ensembles - disjoints - de tâches formant une application temps
réel : E1 ∪ E3 = R, E2 ∪ E4 = NR, E3 ∪ E4 = tâches mises en jeu dans une
relation de précédence, E3 = tâches de R mises en jeu dans une relation de
précédence, E4 = tâches de NR mises en jeu dans une relation de précédence.
3.2.3.2 Description détaillée de la technique
Rappelons que les périodes des tâches mises en jeu dans une relation de précédence
sont identiques (relation de précédence simple) et décrivons les 4 étapes à eectuer sur une
3.2 Annulation de la gigue de régularité 85
conguration de tâches pour que celles à contraintes de régularité (τR) aient nalement une
gigue de régularité nulle.
Etape 1 Souhaitant toujours un ordonnancement des tâches régulières du type de celui
de la gure 3.7, garant d'une gigue de régularité nulle, on applique alors la technique
de désynchronisation des dates d'activation avec Wi = Ci (cf. paragraphe 3.1.1.2) On
obtient ainsi, si elles existent, de nouvelles dates d'activations pour les tâches régulières.
Notons ainsi l'ensemble de ces solutions par (r1,1, ..., rnR,1)j j ∈ 1...p où p est le
nombre de solutions à ce problème de désynchronisation des tâches de R (E1 ∪ E3 dans
la gure 3.10).
Etape 2 Il faut maintenant prendre en compte les éventuelles relations de précédence
présentes dans la conguration de tâches. Considérons alors un graphe de précédence Gquelconque, constitué d'un ensemble de noeuds τi et d'un ensemble de relations entre
ces noeuds τi → τj (cf. gure 3.9 et 3.10 pour illustration). Pour chaque relation de
précédence, les conditions évoquées dans la section 3.1.2 doivent être appliquées :
• rappelons que pour RM, la modication des priorités ne peut être réalisée que par
la modication des périodes, ce qui est contraire à l'hypothèse que nous avons for-
mulée dans ces travaux : les périodes sont considérées comme xes et connues et cet
algorithme d'ordonnancement est écarté.
• en DM et en EDF, la première condition concerne les dates de première activation :
pour une relation τi → τj , il faut que ri,1 ≤ rj,1 ou que ri,1 < rj,1. Avec l'ensemble desrelations de G, on obtient alors des conditions sur les dates de première activation :
(∀(i, j) ∈ N2|τi → τj) ri,1 ≤ rj,1 (3.11)
pour DM, ou :
(∀(i, j) ∈ N2|τi → τj) ri,1 < rj,1. (3.12)
pour EDF. Parmi les p nR-uplets de l'étape 1, soit ceux de (r1,1, ..., rnR,1)jj ∈ [|1; p|],on choisit ceux qui vérient également ces conditions. A noter que, comme les durées
d'exécution des tâches ne sont pas nulles, ces nouvelles dates de première activation
ne sont pas identiques entre elles.
Il reste ensuite les conditions qui concernent les dates d'activation non incluses dans
les nR-uplets, à savoir celles des tâches de NR qui participent à une relation de
précédence (région E4 de la gure 3.10) : ces conditions permettent alors de dénir à
leur tour un ensemble de dates d'activation possibles sur les tâches de NR incluses
dans une précédence (région E4 de la gure 3.10).
Distinguons maintenant les deux algorithmes d'ordonnancement possibles pour parler
des conditions sur les délais critiques :
• en DM, nous devons choisir des délais critiques de sorte que :
(∀(i; j) ∈ N2|τi → τj) Di < Dj. (3.13)
Ces conditions sont en fait inutiles dans le cas de deux tâches régulières reliées par une
relation de précédence. En eet, les choix des dates de première activation, combinés
86 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
à la propriété selon laquelle nous garantissons des intervalles d'exécutions des tâches
régulières sans chevauchement, susent en fait à assurer la précédence. Toujours en
notant le nombre de tâches mises en jeu dans les relations de précédence par k (régionE3 ∪ E4 de la gure 3.10), on peut alors désigner par un ensemble de k-uplets lessolutions à ces conditions : (D1, ..., Dk)j j ∈ [|1; q|] avec q le nombre de solutionspossibles.
• Avec EDF, les seules conditions à respecter sont les suivantes :
(∀(i; j) ∈ N2|τi → τj) Di = Ci, (3.14)
ce qui dénit de manière unique les nouveaux délais critiques des tâches mises en jeu
dans les relations de précédence. Une remarque va cependant s'imposer pour EDF :
Remarque 3.1 Restreindre les délais critiques des tâches τi à Ci (c'est-à-dire : Di = Ci)
va indubitablement diminuer les chances d'ordonnançabilité de la nouvelle conguration
(nous le verrons en pratique dans les exemples qui suivent). Une suggestion pour diminuer
ce risque pourrait être de désynchroniser les tâches mises en jeu dans une relation de
précédence, de sorte qu'il existe un intervalle entre les dates d'activation de deux tâches
se succédant, qui permette au moins d'insérer l'exécution de la tâche qui précède. Cette
suggestion est néanmoins écartée dans cette étude pour la clarté de cette description.
Etape 3 Nous nous intéressons ici à la redénition des priorités selon le paragraphe 3.1.3.
Les périodes n'étant pas modiables, seuls les résultats sur DM et EDF sont applicables.
En outre, il est nécessaire de faire une remarque importante avant de détailler la technique
de modication des délais critiques : en eet, des problèmes d'incompatibilité entre les
conditions des équations (3.13) et celles des équations (3.8), peuvent se manifester et
induire des cas de précédences incompatibles avec l'annulation de la gigue. Examinons
donc les nouvelles priorités en gardant cette remarque à l'esprit :
• dans le cas DM, la section 3.1.3 impose le choix d'un nouveau délai critique D∗i pour
les tâches de R selon la condition :
(∀τi ∈ R) Ci ≤ D∗i ≤ min
τj∈NR(Di;Dj − 1). (3.15)
Ainsi, la tâche τi obtient un nouveau délai critique qui est strictement inférieur aux
délais critiques des tâches NR. Cette redénition appelle cependant la remarque sui-
vante :
Remarque 3.2 Imposer D∗i = min
τj∈NR(Di;Dj−1) ou imposer D∗
i = Ci revient exactement
au même problème d'ordonnancement. En eet, les diérentes exécutions des tâches Rsont toujours désynchronisées les unes par rapport aux autres selon les résultats de la
première étape, donc, les seules fautes temporelles qui pourraient apparaître sont celles
mettant en jeu une tâche régulière et une tâche non nécessairement régulière : le fait alors
d'imposer avec l'équation ci-dessus la borne maximale ou la borne minimale implique
dans les deux cas des priorités plus grandes pour les tâches R qui susent alors à lever
cette éventualité. Il est néanmoins intéressant de dénir l'ensemble des nouveaux délais
critiques possibles, de sorte qu'un éventuel critère analytique d'ordonnançabilité puisse
par exemple être vérié dans le cas le moins contraint.
3.2 Annulation de la gigue de régularité 87
Examinons maintenant les problèmes d'incompatibilité :
• Dans l'hypothèse DM, l'équation 3.15 impose en fait que le délai critique des tâches
régulières τR soit strictement inférieur à celui des tâches non nécessairement régulières
τNR. En d'autres termes, elle impose : DτR< DτNR
qui peut être contradictoire avec
les équations 3.13. La seule façon d'être sûr qu'il n'y a pas contradiction dans les
deux redénitions, c'est d'interdire les relations de précédence du type τNR → τR, quitypiquement nécessiterait une condition DτNR
< DτR. Ce type de relation est celle
typée P4 dans la gure 3.10 et si donc on l'interdit, il n'y aura pas incompatibilité
entre les deux redénitions. L'élimination du traitement de ce type de précédence
(P4) n'est pas réellement une restriction car il apparaît conceptuellement dicile de
faire précéder une tâche que l'on veut régulière, par une tâche dont l'exécution est
uctuante en terme d'occurrence. Cette restriction, nécessaire à l'application de notre
technique, peut néanmoins être discutable dans le cas d'une activité du type contrôle
commande, où l'on rencontre classiquement le schéma suivant : tâche acquisition →tâche de calcul → tâche de commande (actionneur), et sur lequel la régularité est
imposée seulement sur les tâches d'acquisition et de commande, laissant donc une
certaine latitude de choix pour l'ordonnancement des tâches de calcul. Ce problème
sera abordé plus en détail dans la section 3.5, et cette restriction sera levée dans la
section suivante, celle où nous traitons le cas de l'encadrement de la gigue. Une fois
cette précédence mise de côté, les mécanismes de choix des délais critiques se font
comme dans le cas de la précédence : parmi les nR-uplets solutions des équations 3.15,c'est-à-dire parmi un ensemble du type (D1, ..., DnR
)jj ∈ [|1; q|] où q est le nombrede solutions, on choisit ceux qui répondent également aux conditions des contraintes
de précédence (équations 3.13).
• En EDF, on rajoute aux conditions de l'étape 2, les conditions :
(∀τi ∈ R) D∗i = Ci. (3.16)
Ces conditions sont entachées de la même remarque faite dans le paragraphe précédent
(étape 2, cas EDF, remarque 3.1) où l'on a évoqué leur caractère très restrictif et leurs
conséquences sur l'ordonnançabilité de la conguration.
Etape 4 Au nal, on rassemble l'ensemble des nouveaux attributs temporels possibles
pour les tâches régulières et pour les tâches mises en jeu dans une relation de précé-
dence, et parmi les diérentes conguration de tâches possibles, on choisit celles qui sont
ordonnançables (cf. paragraphe 3.1.4).
Remarque 3.3 La description de la technique dans le contexte d'ordonnancement DMpeut être directement appliquée à un autre contexte, celui de l'ordonnancement des tâches
suivant leur priorité xe. La seule diérence de forme se situe au niveau de l'expression
des priorités. Pour deux tâches τi et τj dont les délais critiques doivent vérier Di < Dj
sous DM , il sut au niveau des priorités xes que Prioi > Prioj. Les conclusions et lesproblèmes d'incompatibilité restent cependant les mêmes.
Après cette description détaillée de la technique de traitement de la gigue de régularité,
nous allons la mettre en pratique au travers de deux exemples.
88 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
3.2.4 Exemple simple
An d'illustrer cette méthodologie, prenons l'exemple d'une conguration à 6 tâches
dont deux sont des tâches à contraintes de régularité, de durée d'exécution unitaire, (cf.
tableau 3.4 pour commentaires). Dans le cahier des charges, ajoutons deux activités dénies
par : A1 : τAcq1 → τTrait1 → τCont1 et par : A2 : τAcq2 → τTrait2 . Ces diérents paramètres
conduisent à une période d'étude de 72 unités de temps processeur, un taux d'utilisation
processeur de 94,5 %, et des gigues temporelles que nous présentons aussi dans le tableau
3.4, gigues calculées sur un ordonnancement n'ayant pas encore pris en compte les relations
de précédence. Notons en outre que si les tâches d'acquisition ou de commande devaient
suréchantillonner3 le signal, la conguration ne serait pas ordonnançable.
Tab. 3.4: Exemple de conguration à 6 tâches dont deux sont de type régulière
à durée d'exécution unitaire : Acquisition 1 et Acquisition 2.Tâches ri,1 Ci Di Ti Gigues (%) Commentaires
RM / DM / EDF
Acquisition1(τR) 0 1 8 8 9,8 / 9,8 / 10,9 Contrôle rapide
Traitement1 0 2 8 8 (ex. contrôle d'ouvert-
Contrôle1 0 1 7 8 ure d'une vanne)
Acquisition2(τR) 0 1 18 18 18,5 / 18,5 / 11,1 Mesure lente (ex. acqui-
Traitement2 0 4 17 18 sition température)
Contrôle3 0 1 6 6 Tâche de contrôle rapide
(ex. alarme)
On déroule alors les quatre étapes décrites dans la sous section précédente :
Etape 1 L'application de l'algorithme de recherche systématique de toutes les solutions
au problème de désynchronisation conduit à caractériser 72 couples (rAcq1,1, rAcq2,1) dif-férents.
Etape 2 Explicitons tout d'abord les contraintes sur les dates de première activation
des tâches mises en jeu dans une relation de précédence. Nécessairement, elles doivent
vérier : rAcq1,1 ≤ rTrait1,1 ≤ rCont1,1 et rAcq2,1 ≤ rTrait2,1. Dans les couples de l'étape
1, on ne garde que les couples qui répondent à ces conditions (par exemple le couple
(rAcq1,1, rAcq2,1) = (0, 1) et les dates d'activation suivantes : rTrait1,1 = 1, rCont1,1 = 2et rTrait2,1 = 2 respectent ces conditions). Il reste ensuite les contraintes sur les délais
critiques :
• en DM : DAcq1 < DTrait1 < DCont1 et DAcq2 < DTrait2
• et en EDF : DAcq1 = CAcq1, DTrait1 = CTrait1 , DCont1 = CCont1 , DAcq2 = CAcq2 et
DTrait2 = CTrait2 .
Etape 3 On en vient à la redénition des priorités des tâches régulières par rapport à
celles des tâches non nécessairement régulières.
3Principe selon lequel la période dite d'échantillonnage (acquisition) ou la période dite de restitution
(commande) est diminuée an de compenser les problèmes de bruit, d'interférence ou de gigue qui inter-
viennent communément dans la mesure d'un signal ou dans la commande d'un actionneur.
3.2 Annulation de la gigue de régularité 89
• La condition exprimée par l'équation 3.15 donne pour DM, dans le cas le moins
restrictif, des délais critiques égaux à 5 unités de temps processeur (DAcq1 = DAcq2 =5). Ces délais nous permettent ensuite, de dénir, à l'aide des conditions de l'étape 2,
un ensemble de délais critiques possibles pour les tâches impliquées dans une relation
de précédence (par exemple, on peut choisir les délais critiques suivants : DTrait1 = 6,DCont1 = 7 (inchangé) et DTrait2 = 17 (inchangé également)).
• Avec EDF, les conditions reprennent celles décrites dans l'étape 2, il n'y a donc rien
à changer pour les délais critiques.
On peut ensuite rassembler l'ensemble des nouveaux attributs temporels possibles, et
pour chaque conguration ainsi dénie on doit en vérier l'ordonnançabilité.
Etape 4 Dans la dernière étape, étant données les diérentes congurations de tâches
possibles, nous allons garder celles dont l'ordonnançabilité est assurée, ceci à l'aide d'un
outil de simulation d'ordonnancement mono-processeur. Dans le cadre des paramètres
mentionnés dans l'exemple (cf. tableau 3.5), on obtient en DM une nouvelle conguration
de tâche ordonnançable avec le résultat escompté : les gigues des tâches τAcq1 et τAcq2sont annulées et les contraintes de précédence sont respectées (cf. séquence de la gure
3.11). Pour illustrer l'idée exprimée dans la remarque 3.1, nous avons vérié si, avec les
mêmes choix pour les dates de première activation, la technique décrite dans le contexte
EDF, conduirait encore à une conguration ordonnançable. En fait, elle n'est pas ordon-
nançable avec ces choix particuliers, mais rien ne dit par contre qu'il n'existe pas dans les
diérentes congurations de tâches possibles, une conguration qui soit ordonnançable.
Pour en être sûr, il faut alors vérier l'ordonnançabilité de toutes les congurations -
nales précisées à l'issue de l'étape 3. Avec ce choix de paramètres temporels, nous voulons
simplement souligner que notre technique pour EDF, a plus de dicultés pour obtenir
des congurations ordonnançables que notre technique en DM. L'exemple souligne ainsi
le caractère restrictif de la technique dans le cadre de EDF, comparée à une utilisation
dans le cadre de DM où les modications des paramètres sont moins contraignantes.
Tab. 3.5: Nouveaux attributs temporels qui conduisent à une gigue nulle sur les
tâches régulières et qui conduisent au respect des contraintes de précédence.Tâches ri,1 Ci Di (DM/ EDF) Ti
Acquisition1(τR) 0 1 5 / 1 8
Traitement1 1 2 6 / 2 8
Contrôle1 2 1 7 8
Acquisition2(τR) 1 1 5 / 1 18
Traitement2 2 4 17 18
Contrôle3 0 1 6 6
3.2.5 Exemple complet
Considérons une application temps réel simpliée qui piloterait en partie un aéronef.
Cette application est décrite dans la gure 3.12 et les diérents paramètres temporels des
90 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
Fig. 3.11: Séquence d'ordonnancement en DM de la nouvelle conguration ob-
tenue (séquence donnée sur [0; 60]) : les tâches τAcq1 et τAcq2 sont régulières - lesèches correspondent à des relations de précédence.
tâches sont présentés dans le tableau 3.6 : cette application présente par ailleurs tous les
types autorisés de précédence. Dans ce tableau 3.6, nous avons également reporté les gigues
temporelles des tâches régulières, obtenues en ordonnançant directement la conguration.
A noter que sans aucune modication des paramètres temporels, les précédences entre les
tâches ne sont pas respectées. Nous allons alors dans cet exemple dérouler les diérentes
étapes qui vont conduire à annuler la gigue sur les tâches régulières, soit ici les tâches τR1 ,
τR2 et τR3 , et qui vont conduire à respecter les contraintes de précédence.
Tab. 3.6: Description des paramètres de tâches d'une application temps réel.ri,1 Ci Di Ti Gigues (%) Commentaires
DM / EDF
τNR1 0 2 32 32 Tâche de mesure de la température.
τNR2 0 1 32 32 Tâche de calcul de la vitesse de l'aéronef.
τR1 0 3 32 32 2,6 / 2,6 Tâche de mesure de la pression dynamique.
τNR3 0 1 16 16 Tâches pour piloter la température
et la pression cabine.
τR2 0 2 16 16 4,9 / 4,9 Tâche de commande des organes de vol.
τR3 0 1 16 16 10 / 10 Tâche d'acquisition des
ordres de pilotage.
τNR4 0 2 10 10 Tâche d'alarme (rapide).
τNR5 0 3 56 56 Tâche d'achage.
Etape 1 Désynchronisation des dates de première activation
Comme décrit dans le paragraphe 3.1.1.2, nous allons dans un premier temps décaler les
dates de première activation les unes par rapport aux autres de sorte qu'aucune exécution
d'une tâche régulière ne vienne perturber une exécution, non préemptée, d'une autre tâche
3.2 Annulation de la gigue de régularité 91
régulière. En conservant les conventions de ce chapitre, nous avons n = 3, et nous cherchonsles triplets (rR1,1, rR2,1, rR3,1) de sorte que :
rR1,1 − rR2,1 = 0mod(TR1 ∧ TR2)rR1,1 − rR2,1 = 1mod(TR1 ∧ TR2)
etrR1,1 − rR3,1 = 0mod(TR1 ∧ TR3)
etrR2,1 − rR3,1 = 0mod(TR2 ∧ TR3)rR3,1 − rR2,1 = 1mod(TR2 ∧ TR3).
(3.17)
La recherche de tous les triplets possibles à l'aide de l'algorithme de l'annexe A, conduit
à trouver 3696 solutions diérentes. Par ex : (rR1,1, rR2,1, rR3,1) = (0, 3, 5) ou encore (rR1,1,rR2,1, rR3,1) = (0, 4, 3), etc.
Etape 2-1 Prise en compte des précédences pour les ri,1
Cas DM. Pour respecter les relations typées P1 et celle typée P2, on doit choisir parmi
les diérentes dates de première activation possible établies dans le paragraphe précédent,
des rRi,1 qui vérient les relations suivantes :
rR1,1 ≤ rNR2,1
rR3,1 ≤ rR2,1
rR3,1 ≤ rNR3,1
(3.18)
où rNR2,1et rNR3,1 sont à ajuster également. La relation typée P3 impose de plus :
rNR1,1 ≤ rNR2,1 (3.19)
Ces conditions conduisent alors à un ensemble de solutions possibles pour les dates
d'activation (par exemple, on peut choisir le triplet : (rR1,1, rR2,1, rR3,1) = (0, 4, 3) pourles tâches régulières, quant aux dates de premières activations des tâches NR, on peut
choisir : rNR2,1 = 1, rNR3,1 = 4, et rNR1,1 = 0).
Cas EDF. Ce sont les mêmes relations qui interviennent, à ceci près que nous avons à
faire à des inégalités strictes.
Fig. 3.12: Un exemple d'application temps réel.
92 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
Etape 2-2 Prise en compte des précédences pour les Di
Cas DM. Les relations à satisfaire pour les priorités sont les suivantes :
DR1 < DNR2 et DNR1 < DNR2
DR3 < DNR3
(3.20)
de sorte qu'en cas de demande commune du processeur, les tâches précédant soient
prioritaires. La condition DR3 < DR2 est en fait inutile dans le cas de deux tâches
régulières (cf. explications dans la section 3.2.3.2, étape 2)
Cas EDF. Les conditions à satisfaire pour les tâches impliquées dans une relation de
précédence sont :
Pour toute relation du type τi → τj alors Di = Ci (3.21)
Ces conditions établies, nous allons dans le paragraphe suivant prendre en compte les
autres conditions sur les délais critiques pour dénir les nouvelles valeurs des Di.
Etape 3 Changement de priorité des tâches régulières
Cas DM. La relation 3.15 impose que le délai critique d'une tâche R doit être inférieur
strictement au délai critique de toutes les autres tâches NR. Ce qui consiste à imposer
que :
DR1 < DNRj
DR2 < DNRj
DR3 < DNRj
(3.22)
pour j indicant toutes les tâches NR. Un ensemble de solutions en terme de délai critique
est donc caractérisé. Nous pouvons proposer, par exemple, les solutions suivantes pour
les nouvelles valeurs des Di, solutions qui vérient les deux ensembles de conditions 3.20
et 3.22 : DR1 = 9, DR2 = 9, DR3 = 9, DNR1 = 31, DNR2 = 32 (inchangé) et DNR3 = 16(inchangé également).
Cas EDF. Les conditions à imposer sur les délais critiques reviennent en fait à imposer :
Pour toutes les tâches régulieres, Di = Ci (3.23)
Etape 4 Nouvelles congurations - Test d'ordonnançabilité
Il s'agit maintenant de conserver les nouvelles congurations de tâches qui sont ordon-
nançables. Avec les paramètres temporels proposés au cours de cet exemple, nous obtenons
la conguration de tâches reportée dans le tableau 3.7 (période de simulation H = 2244),et après vérication à l'aide d'un outil de simulation, la conguration n'est ordonnançable
qu'avec les changements liés au contexte de DM : on rejoint en fait la remarque évoquée à la
n de l'exemple précédent dans le contexte EDF, ou l'on évoquait le caractère restrictif de
notre méthode dans le cadre de ce contexte. En DM par contre, nous obtenons le résultat
escompté : les gigues sur les tâches régulières sont annulées et les précédences sont bien
respectées (cf. séquence dans la gure 3.13).
3.2 Annulation de la gigue de régularité 93
Tab. 3.7: Nouvelle Conguration de tâche.ri,1 Ci Di (DM / EDF) Ti Commentaires
τNR1 0 2 31 / 2 32 Tâche de mesure de la température.
τNR2 1 1 32 / 32 32 Tâche de calcul de
la vitesse de l'aéronef.
τR1 0 3 9/ 3 32 Tâche de mesure de la pression dynamique.
τNR3 4 1 16 / 16 16 Tâches pour piloter la température
et la pression cabine.
τR2 4 2 9 / 2 16 Tâche de commande
des organes de vol.
τR3 3 1 9 / 1 16 Tâche de d'acquisition
des ordres de pilotage.
τNR4 0 2 10/ 10 10 Tâche d'alarme (rapide).
τNR5 0 3 56 / 56 56 Tâche d'achage.
Fig. 3.13: Séquence d'ordonnancement après la modication des paramètres
dans le contexte de DM : les exécutions des tâches R sont régulières et les pré-
cédences sont respectées - les èches représentent des relations de précédence.
3.2.6 Conclusion : vers une méthode plus exible
Le problème de recherche des ri,1 pour la phase de désynchronisation n'est pas un pro-blème trivial. De plus, la nouvelle conguration de tâches, surtout pour le cas EDF, présente
des attributs temporels très contraints pour répondre à notre technique. Ces contraintes,
nous l'avons vu au travers des deux exemples précédents, peuvent nous conduire à des
congurations non ordonnançables surtout lorsque le nombre de tâches régulières augmente.
D'un point de vue pratique, il n'est en fait pas très réaliste d'imposer aux tâches régulières
une gigue totalement nulle. En eet, le plus souvent, dans la spécication des gigues d'une
application temps réel, seul un intervalle de uctuation dans l'exécution de la tâche, est
précisé (cf. l'étude de cas de Bate dans [Bate 98]). Ainsi au lieu de certier l'annulation de
la gigue des tâches régulières, il serait intéressant de pouvoir certier que ces tâches régu-
lières ne vont uctuer pendant la phase d'exploitation, que dans des intervalles d'exécution
94 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
donnés. C'est ce que nous allons développer dans la section suivante.
3.3 Encadrement de la gigue de régularité
3.3.1 Principe
La technique décrite dans cette section est sensiblement similaire à celle de la section
précédente : en fait, nous avons besoin d'être moins restrictif sur la redénition des pa-
ramètres, de sorte que plus de congurations de tâches soient ordonnançables et de sorte
que les gigues soient non plus annulées mais bornées. La principale raison pour laquelle
notre technique précédente conduit à des congurations trop contraintes, peut être justiée
par notre idée d'imposer une exécution des tâches régulières en bloc, soit sans préemption.
L'objectif dans cette section va donc être de pouvoir combiner une maîtrise de la gigue et
une exécution des tâches de R, qui peut être préemptée. Nous verrons que cette préemption
ne proviendra que des tâches de NR, celles non nécessairement régulières.
Pour dimensionner le niveau de préemptions des tâches régulières, il serait intéressant
d'obtenir une spécication sur le paramètre Wi qui, pour une tâche τi, représente le délaiaprès l'activation, au terme duquel l'instance considérée doit être pleinement exécutée. Wi
représente en fait la largeur maximum pour les fenêtres d'exécution des instances de τi (cf.paragraphe 3.1.1.2). Le temps de réponse maximum pour la tâche τi, à savoir trmax(τi) =max
k(ei,k − ri,k), peut être un bon choix puisqu'il représente aussi la durée maximum après
l'activation, au terme de laquelle, on souhaite que les instances soient terminées. A l'intérieur
de ces intervalles de largeur trmax(τi), la quantité trmax(τi)−Ci dénit alors la durée pendant
laquelle le processeur n'est pas alloué à τi (cf. gure 3.14).
Fig. 3.14: Le temps de réponse maximum d'une tâche trmax(τi) permet de spé-
cier le paramètre Wi.
De la même façon que dans la section précédente, nous allons imposer à chaque tâche
τi de R de s'exécuter dans des intervalles commençant à ses dates d'activation (ri,k, j ≥ 1)et pouvant se terminer au pire Wi unités de temps processeur plus tard. Cette idée peut
néanmoins soulever une remarque :
Remarque 3.4 Une redénition simple des délais critiques des tâches régulières pourrait
répondre aisément à ce problème d'encadrement des uctuactions des exécutions. Ainsi,
en posant : (∀τi ∈ R), D∗i = trmax(τi), la préemption ne serait autorisée que dans des
intervalles de largeur trmax(τi), et la gigue de ces tâches serait alors encadrée. Cependant,
la nouvelle conguration doit toujours être ordonnançable, ce qui est d'autant moins sûr
3.3 Encadrement de la gigue de régularité 95
dans un contexte où les tâches de R ne sont pas désynchronisées les unes par rapport aux
autres.
En outre, si on applique directement la redénition des délais critiques mentionnée
dans cette remarque, on va non seulement autoriser la préemption d'une tâche régulière
par une tâche non nécessairement régulière, mais aussi par une autre tâche régulière, ce
qui est discutable d'un point de vue conception. En eet, si nous autorisons les tâches
régulières à se préempter entre elles, il sera alors impossible de gérer correctement les
activités pour lesquelles des données en sortie d'une tâche peuvent être les données en entrée
d'une autre tâche. Ainsi, les activités du type contrôle-traitement-commande, mettant en
jeu deux tâches régulières pour l'acquisition et la commande, ne pourraient être traitées.
Nous avons donc écarté cette idée.
Dans cette section donc, nous allons faire en sorte que les tâches régulières ne se pré-
emptent pas entre elles. Nous pouvons en fait produire des séquences de tâches respectant
ces propriétés en adaptant simplement la technique de la section précédente. Nous procé-
dons pour cela toujours suivant quatre étapes :
Etape 1 Pour chaque tâche τi de R, au lieu de dénir des fenêtres d'exécution à l'activa-
tion telles que Wi = Ci, nous allons dénir des fenêtres d'exécution à l'activation telles
que Wi = trmax(τi), qui ne se chevaucheront pas entre elles. Le problème de désynchroni-
sation reste exactement le même et utilise les mêmes outils de résolution présentés dans
la section 3.1.1.2.
Etape 2 Prise en compte des contraintes de précédence au travers des contraintes sur
les attributs temporels des tâches selon les principes évoquées dans le paragraphe 3.1.2.
Etape 3 Redénition des priorités des tâches de R, pour assurer une exécution dans des
fenêtres de largeur Wi = trmax(τi).
Etape 4 Test d'ordonnançabilité de la nouvelle conguration de tâches selon les outils
évoqués dans le paragraphe 3.1.4.
Avant de décrire ces quatre étapes dans le détail, après quoi nous verrons une application
de la technique au travers d'un exemple, étudions l'encadrement de la gigue temporelle
moyenne d'une tâche R, supposée avoir subie ces quatre étapes.
3.3.2 Conséquence sur la gigue de régularité
A l'issue de l'étape 4, chaque tâche τi de R s'exécute dans un intervalle de largeur
Wi = trmax(τi), et on a pour toute instance k considérée : ei,j ≤ ri,j + trmax(τi). Considéronsmaintenant une telle tâche τi. Sur ces intervalles d'exécution, le pire cas pour la gigue est
déni par l'obtention de la plus petite durée puis de la plus longue durée séparant les ns
d'exécution de deux instances successives4(cf. gure 3.15).
Selon les conventions adoptées dans le chapitre 1, nommons par ∆emin et par ∆emax ces
deux durées (cf. gure 3.15). Nous avons alors les relations suivantes :
4On privilégie ici la gigue de régularité de n d'exécution car elle est plus simple à dénir dans ce
contexte, et on peut remonter à la gigue de régularité de début d'exécution via la donnée des gigues de
cohésion.
96 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
∆emax = Ti +Wi − Ci,
∆emin = Ti + Ci −Wi, (3.24)
relations qui vont nous permettent d'encadrer le pourcentage moyen de gigue de régularité.
Pour cela, supposons que sur une période d'étude H , il y ait autant de durées ∆emin, que
de durées ∆emax. Soit N ce nombre. Nous avons alors selon l'équation 1.7, un pourcentage
moyen de gigue de régularité tel que :
JMoy(τi) =1
2N
N |∆emin − Ti|+N |∆emax − Ti|Ti
100 %, (3.25)
qui conduit à :
Jmoy(τi) =Wi − Ci
Ti100 %, (3.26)
soit :
JMoy(τi) =trmax(τi) − Ci
Ti100 %. (3.27)
En résumé, nous imposons aux tâches régulières de s'exécuter dans des intervalles de
largeur Wi = trmax(τi), démarrant aux diérentes dates d'activation des tâches τi, et nousobtenons alors deux résultats sur des critères de qualité de service pour les tâches τi de R :
• le temps de réponse (tr) spécié ne sera eectivement jamais dépassé pendant l'exécu-
tion,
• et le pourcentage moyen de gigue de régularité sera borné par la valeur JMoy(τi) décriteci-dessus.
Avant de passer à la description détaillée de la technique, il est intéressant de souligner
que cette spécication sur les temps de réponse qui permet de borner la gigue de régularité,
rejoint l'observation que nous avions mentionnée dans le chapitre 1 à propos de la gigue de
Buttazzo (cf. paragraphe 1.5.1). Cette gigue est en eet basée sur les temps de réponse de
chaque instance de la tâche, et se révèle être équivalente, à un facteur multiplicatif près,
au pourcentage moyen de gigue de régularité. La forte corrélation entre ces deux concepts,
temps de réponse et gigue de régularité, permet alors de mieux comprendre ce résultat : le
contrôle du temps de réponse maximum permet le contrôle de la gigue.
Fig. 3.15: Le cas du maximum de gigue dans l'exécution de la tâche τi. ∆emin =la plus petite durée séparant les ns d'exécution de deux instances successives,
∆emax = la plus grande durée séparant les ns d'exécution de deux instances
successives.
3.3 Encadrement de la gigue de régularité 97
3.3.3 Description détaillée de la technique
Rappelons que les périodes des tâches participant à une relation de précédence sont
identiques, et que nous conservons les notations décrites dans la section précédente (cf.
paragraphe 3.2.3), à savoir que pour une tâche τR désignant une tâche de R et que pour
une tâche τNR désignant une tâche de NR, on peut avoir les relations de précédences
suivantes :P1 : τR → τNR
P2 : τR → τRP3 : τNR → τNR
P4 : τNR → τR
. (3.28)
La relation P4 est en eet de nouveau prise en compte, contrairement à la section 3.2
où elle avait été nalement écartée. Contrairement à cette section, nous autorisons ici les
préemptions des tâches régulières par des tâches non régulières : les fenêtres d'exécution
sont donc plus larges. Cette largeur va en fait nous permettre d'insérer l'exécution d'une
tâche non régulière avant l'exécution d'une tâche régulière.
Décrivons plus en détail cette technique de maîtrise de la gigue des tâches régulières :
Etape 1 Il s'agit dans un premier temps de résoudre le problème de désynchronisation
avec Wi = trmax(τi). Cela donne alors un ensemble de nR-uplet du type : (r1,1, ...,rnR,1)j j ∈ [|1; p|], où p est le nombre de solutions au problème pour les tâches de R. Lesnouveaux intervalles démarrant aux dates d'activation des instances des tâches régulières
et se terminant Wi unités de temps processeur plus tard, vont alors être construits de
telle sorte qu'aucun chevauchement ne soit possible.
Etape 2 Ce sont les mêmes considérations que celles développées dans la section précé-
dente (Etape 2, paragraphe 3.2.3.2) pour ce qui concerne le choix des dates d'activation
des tâches mises en jeu dans une relation de précédence (région E3∪E4 de la gure 3.10,
page 84) : parmi les p nR-uplets de l'étape 1, on choisit ainsi ceux qui vérient les condi-
tions 3.11 et 3.12, puis on choisit un ensemble de solutions pour les dates d'activation
des tâches de NR participant à une relation de précédence (la région E4 de la gure
3.10).
Pour le choix des nouveaux délais critiques, on doit distinguer l'algorithme d'ordonnan-
cement utilisé :
• en DM, nous cherchons les délais critiques qui vérient les conditions :
(∀(i; j) ∈ N2|τi → τj) Di < Dj, (3.29)
là encore, les précédences mettant en jeu deux tâches régulières, peuvent s'aranchir
de ces conditions : nous le verrons dans l'étape 3. En désignant ensuite par k, lenombre de tâches mises en jeu dans une relation de précédence (région E3 ∪ E4 de
la gure 3.10), on peut alors désigner par un ensemble de k-uplets les solutions à cesconditions : (D1, ..., Dk)j j ∈ [|1; q|] avec q le nombre de solutions possibles.• en EDF, les seules conditions à respecter sont :
(∀(i; j) ∈ N2|τi → τj) Di = Ci, (3.30)
98 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
qui impliquent alors que l'exécution de la tâche τi se fasse sans préemption et ce,
dès son activation. Ainsi, dans le contexte EDF, pour toutes les tâches précédant une
autre tâche, la largeur d'exécution est réduite àWi = Ci. Dans ce contexte, il est alors
nécessaire de refaire l'étape 1 en prenant en compte cette restriction pour le problème
de désynchronisation. Le début de l'étape 2, celui qui concerne les dates d'activation,
doit alors aussi être reconduit. A noter également que la remarque 3.1, page 86, faite
dans le paragraphe 3.2.3.2 peut être réitérée.
Etape 3 Dans cette étape, nous devons redénir les priorités des tâches régulières de
sorte qu'elles s'exécutent dans les intervalles de largeur Wi = trmax(τi). Ceci peut êtreréalisé par la redénition des délais critiques des tâches de R :
(∀τi ∈ R) D∗i = Wi = trmax(τi). (3.31)
Ainsi, τi ne sera préemptée (par une tâche de NR) que pendant une durée maximum de
trmax(τi) − Ci, sans quoi il y aura faute temporelle. Une remarque peut néanmoins être
faite sur le contexte d'ordonnancement DM :
Remarque 3.5 Supposons dans cette remarque que le nouveau délai critique D∗i d'une
tâche τi de R dans le contexte de DM, soit choisi de telle sorte que : (∀τi ∈ R) trmax(τi)≤ D∗
i ≤ minτj∈NR(Di;Dj − 1), sur le même principe que celui de la section précédente.
Dans ce cas, la tâche τi aurait une contrainte plus forte puisque ce principe d'aectationconduirait à des exécutions non-préemptées de τi : pas de préemption de la part des tâchesde NR, puisque Priorité(τi) > Priorité(τj), avec τj ∈ NR, et pas non plus de préemption
de la part des tâches de R, puisque, par construction, les intervalles d'exécution sont à
intersection nulle. En fait, pour que la tâche soit moins contrainte en terme d'ordonnan-
cement, on peut se satisfaire de la condition suivante : trmax(τi) ≥ minτj∈NR(Di;Dj−1),autorisant alors la préemption de τi par une tâche de NR, ce qui augmente les chancesd'ordonnançabilité.
Pour nir l'étape 3, examinons les éventuels conits possibles entre cette redénition
(équation 3.31) et les conditions 3.29 et 3.30 de l'étape 2.
Cas DM. Dans l'étape 2, au travers des diérentes propositions pour les dates d'acti-
vation et les délais critiques, nous souhaitons en fait que la nouvelle conguration de
tâches respecte ses contraintes de précédence. Or, pour le cas des tâches de R parti-
cipant à une relation de précédence (région E3, gure 3.10, page 84), les propositions
faites sur les dates d'activation et la condition 3.31 susent. En eet, le problème de
désynchronisation permet de construire des intervalles d'exécution qui, s'ils sont de
largeur Wi, sont alors assurés de ne pas se chevaucher. Or le fait d'imposer D∗i = Wi
implique précisément que leur largeur sera de Wi, sans quoi il y aura faute temporelle.
Les conditions dans l'équation 3.29 mettant en jeu deux tâches régulières peuvent
donc être écartées.
Pour ce qui concerne par contre les tâches de NR incluses dans les relations de précé-
dence (région E4, gure 3.10, page 84), il faut garder les délais critiques proposés par
les solutions du système d'inégalités 3.29, c'est-à-dire, les p-uplets (D1, ..., Dp) avec
p = card(E4), qui représentent en fait la restriction de l'ensemble des k-uplets de(D1, ..., Dk)j j ∈ [|1; q|] aux délais critiques des tâches de E4.
3.3 Encadrement de la gigue de régularité 99
Cas EDF. Dans ce contexte, cette redénition 3.31 des délais critiques peut être rem-
placée par une redénition plus stricte. En eet, si une tâche τi de R participe à une
relation de précédence (c'est-à-dire, qu'elle appartienne à la région E3 de la gure
3.10), alors selon la condition 3.30, si elle précède n'importe quelle type de tâche, son
nouveau délai critique doit être tel que : D∗i = Ci. Au nal en EDF, si il existe des
tâches de R qui précédent n'importe quelle autre type de tâche, alors, le paramètre
Wi sera réduit à Ci et on répondra aux contraintes, et de l'étape 2, et de l'étape 3.
Etape 4 Dans cette dernière étape on rassemble l'ensemble des nouveaux attributs tem-
porels possibles pour les tâches régulières et pour les tâches mises en jeu dans une relation
de précédence, et on choisit alors les congurations de tâches qui restent ordonnançables
(cf. paragraphe 3.1.4).
Nous pouvons là encore reformuler la remarque 3.3 de la page 87 où nous évoquions la
généralisation de l'approche présentée sous DM, au cas des ordonnancements basés sur la
priorité xe.
3.3.4 Exemples illustratifs
Reprenons l'exemple de l'application temps réel de la section précédente (paragraphe
3.2.5) dont les attributs temporels des tâches sont reportés dans le tableau 3.8. Nous avons
également reporté les gigues des tâches régulières, en écartant pour le calcul, le problème
des précédences qui, dans l'état des paramètres temporels, ne sont pas respectées. Dans cet
exemple, nous supposons par ailleurs que les temps réponse maximum spéciés pour les
tâches régulières (tr), sont les suivants :
trmax(τR1) = 11 avec CR1 = 3trmax(τR2) = 4 avec CR2 = 2trmax(τR3) = 1 = CR3
. (3.32)
La préemption n'est donc pas autorisée pour la tâche τR3 . Pour appliquer notre technique
à cet exemple de conguration de tâches, nous allons par ailleurs distinguer l'algorithme
d'ordonnancement choisi puisque, nous l'avons vu dans les paragraphes précédents, la ma-
nipulation des paramètres temporels est sensiblement diérente suivant que l'on choisit DM
ou EDF.
Contexte d'ordonnancement DM
Etape 1 : Désynchronisation des dates de première activation
On applique le principe de désynchronisation (cf. paragraphe 3.1.1.2) aux tâches régulières :
τR1 , τR2 et τR3 avec les paramètres :WR1 = trmax(τR1) = 11,WR2 = trmax(τR2) = 4 etWR3 =trmax(τR3) = 1. La recherche de tous les triplets possibles à l'aide de l'algorithme de l'annexe
A, conduit alors à caractériser 32 triplets solutions diérents (Par ex : (rR1,1, rR2,1, rR3,1) =(0, 11, 15) ou encore (rR1,1, rR2,1, rR3,1) = (0, 12, 11), etc.).
Etape 2-1 : Prise en compte des précédences pour les ri,1Pour respecter les relations de l'application temps réel τR1 → τNR2, τR3 → τR2, τR3 → τNR3
100 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
Tab. 3.8: Description des paramètres de tâches d'une application temps réel.ri,1 Ci Di Ti Gigues (%) Commentaires
DM / EDF
τNR1 0 2 32 32 Tâche de mesure de la température.
τNR2 0 1 32 32 Tâche de calcul de la vitesse de l'aéronef.
τR1 0 3 32 32 2,6 / 2,6 Tâche de mesure de la pression dynamique.
τNR3 0 1 16 16 Tâches pour piloter la température
et la pression cabine.
τR2 0 2 16 16 4,9 / 4,9 Tâche de commande des organes de vol.
τR3 0 1 16 16 10 / 10 Tâche de d'acquisition des
ordres de pilotage.
τNR4 0 2 10 10 Tâche d'alarme (rapide).
τNR5 0 3 56 56 Tâche d'achage.
et τNR1 → τNR2 (cf. gure 3.12), on doit choisir parmi les diérentes dates de première
activation possibles établies dans le paragraphe précédent, des ri,1 qui vérient les relationssuivantes :
rR1,1 ≤ rNR2,1
rR3,1 ≤ rR2,1
rR3,1 ≤ rNR3,1
rNR1,1 ≤ rNR2,1
(3.33)
(cf. paragraphe 3.1.2 pour détail). Cela conduit à un ensemble de dates possibles de première
activation. (Par exemple le triplet : (rR1,1, rR2,1, rR3,1) = (0, 12, 11) pour les tâches régulières,et rNR2,1 = 1, rNR3,1 = 12, rNR1,1 = 0 pour les tâches non nécessairement régulières).
Etape 2-2 : Prise en compte des précédences pour les Di
Les relations à satisfaire pour les priorités sont les suivantes :
DR1 < DNR2 et DNR1 < DNR2
DR3 < DNR3
(3.34)
de sorte qu'en cas de demande commune du processeur, les tâches précédant soient prio-
ritaires. A noter cependant, que la dernière condition DR3 < DR2 n'est pas utile dans la
mesure où les tâches τR1 et τR2 sont à la fois désynchronisées par l'étape 1, et vont avoir
des intervalles d'exécution de largeur WR1 et WR2 , assurant la relation de précédence (cf.
paragraphe 3.3.3, étape 2 et 3 pour détail). Ces conditions établies, nous allons dans le
paragraphe suivant prendre en compte les autres conditions sur les délais critiques pour
dénir les nouvelles valeurs des Di.
Etape 3 : Redénition des délais critiques pour les tâches régulières
La relation 3.31 impose que les délais critiques des tâches de R soient tels que :
3.3 Encadrement de la gigue de régularité 101
DR1 = trmax(τR1) = 11DR2 = trmax(τR2) = 4DR3 = trmax(τR3) = 1
(3.35)
Au nal, on rassemble l'ensemble des attributs temporels possibles caractérisant alors un
ensemble de congurations. (Par exemple, en plus des paramètres précisés dans cette ap-
plication, nous pouvons prendre pour les valeurs des Di des tâches de NR, les solutionssuivantes DNR1 = 31, DNR2 = 32 (inchangé) et DNR3 = 16 (inchangé également) qui
vérient les conditions 3.34).
Etape 4 : Nouvelle conguration - Test d'ordonnançabilité
Dans l'ensemble des congurations possibles, on doit garder alors celles qui sont ordonnan-
çables. Avec la conguration que nous avons reportée dans le tableau 3.9, nous vérions
eectivement, à l'aide d'un outil de simulation, qu'elle reste ordonnançable (cf. une partie
de la séquence dans la gure 3.16). Les précédences sont par ailleurs bien respectées, et
outre le fait que les temps de réponse maximum des tâches régulières le sont aussi, on vé-
rie également que les pourcentages moyens de gigue de régularité sont bornés. On obtient
en eet après calcul sur la séquence :
JMoy(τR1) = 2,54 %JMoy(τR2) = 0 %JMoy(τR3) = 0 %
(3.36)
Tab. 3.9: Nouvelle Conguration de tâche pour le contexte d'ordonnancement
DM.ri,1 Ci Di Ti Commentaires
τNR1 0 2 31 32 Tâche de mesure de la température.
τNR2 1 1 32 32 Tâche de calcul de
la vitesse de l'aéronef.
τR1 0 3 11 32 Tâche de mesure de la pression dynamique.
τNR3 12 1 16 16 Tâches pour piloter la température
et la pression cabine.
τR2 12 2 4 16 Tâche de commande
des organes de vol.
τR3 11 1 1 16 Tâche de d'acquisition
des ordres de pilotage.
τNR4 0 2 10 10 Tâche d'alarme (rapide).
τNR5 0 3 56 56 Tâche d'achage.
Contexte d'ordonnancement EDF
102 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
Etape 1 : Désynchronisation des dates de première activation
Dans les relations de précédence de cette application, il y a deux tâches régulières qui pré-
cèdent d'autres tâches, appartenant à R ou à NR. Aussi, selon les considérations évoquées
dans l'étape 3 du paragraphe 3.3.3, l'exécution de ces tâches régulières va se faire sans
préemption. On applique alors le principe de désynchronisation (cf. paragraphe 3.1.1.2)
aux tâches régulières : τR1 , τR2 et τR3 avec les paramètres suivants : WR1 = CR1 = 3,WR2 = trmax(τR2) = 4 et WR3 = CR3 = 1. La recherche de tous les triplets possibles à l'aidede l'algorithme de l'annexe A, conduit à caractériser 2160 triplets solutions diérents (Par
ex : (rR1,1, rR2,1, rR3,1) = (0, 3, 7) ou encore (rR1,1, rR2,1, rR3,1) = (2, 8, 7), etc).
Etape 2-1 : Prise en compte des précédences pour les ri,1Pour respecter les relations de l'application temps réel (cf. gure 3.12), on doit choisir parmi
les diérentes dates de première activation possibles établies dans l'étape 1, des rRi,1 qui
vérient les relations suivantes :
rR1,1 ≤ rNR2,1
rR3,1 ≤ rR2,1
rR3,1 ≤ rNR3,1
rNR1,1 ≤ rNR2,1
(3.37)
On obtient alors un ensemble de dates de première activation possibles. (Le triplet :
(rR1,1, rR2,1, rR3,1) = (2, 8, 7) pour les tâches régulières, et rNR2,1 = 3, rNR3,1 = 8, rNR1,1 = 0pour les tâches non nécessairement régulières répondent par exemple à ces conditions).
Etape 2-2 : Prise en compte des précédences pour les Di
Les relations à satisfaire pour les priorités sont les suivantes :
DR1 = CR1 , DNR1 = CNR1 , DR3 = CR3 (3.38)
Fig. 3.16: Une partie de la séquence obtenue en DM : les précédences sont
respectées et les gigues encadrées - les èches représentent des relations de pré-
cédence.
3.3 Encadrement de la gigue de régularité 103
de sorte qu'en cas de demande commune du processeur, les tâches précédant soient priori-
taires. Ces conditions établies, nous devons prendre en compte les autres conditions restantes
sur les délais critiques.
Etape 3 : Redénition des délais critiques pour les tâches régulières
Pour EDF, il reste le nouveau délai critique de la tâche τR2 à dénir selon la relation 3.31 :
DR2 = trmax(τR2) = 4 (3.39)
Au nal, pour les valeurs des Di qui changent par rapport à la conguration initiale, nous
proposons : DNR1 = 2 et (DR1 , DR2, DR3) = (3, 4, 1).
Etape 4 : Nouvelle conguration - Test d'ordonnançabilité
Parmi les congurations possibles qui restent ordonnançables, nous avons celle reportée dans
le tableau 3.10. Dans le cadre de cette conguration, les précédences sont bien respectées
et les gigues moyennes de régularité des tâches de R sont mêmes annulées.
Il est important de souligner ici que les délais critiques sont choisis de manière univoque,
alors que nous pouvons obtenir plusieurs solutions en terme de dates d'activation. Goosens
dans [Goossens 03], soulignent qu'une conguration de tâches à départ synchrone non ordon-
nançable sous DM ou EDF, peut très bien se révéler ordonnançable avec un choix particulier
des dates d'activation. Aussi, est il important d'explorer l'ordonnançabilité de l'ensemble
de congurations de tâches résultantes. Dans le choix des dates d'activation reportées dans
le tableau 3.10, le lecteur pourra remarquer que nous avons choisi un triplet correspondant
à des dates d'activation pour les tâches de R (rτR1,1,rτR2
,1,rτR3,1), désynchronisées avec les
dates d'activation des autres tâches, impliquées dans une relation de précédence (rτNR1,1).
On augmente ainsi nos chances d'ordonnançabilité en désynchronisant des tâches devant
s'exécuter sans préemption du fait des précédences (le triplet (rτR1,1,rτR2
,1,rτR3,1) = (0, 3, 7)
conduit par exemple à une conguration non ordonnançable).
3.3.5 Automatisation de la méthode
Cette technique de traitement de la gigue de régularité peut être programmée assez
simplement. Nous reviendrons d'ailleurs sur le programme dans le chapitre suivant "Expé-
rimentations Numériques", mais donnons pour l'instant l'algorithme générique permettant
d'implémenter les 4 étapes (cf. algorithme 1 en page 105). Dans cet algorithme nous dési-
gnerons par NTR5 et NT 6 deux entiers non nuls tels que NT > NTR et tels que chaque
élément de l'ensemble des tâches régulières soit repéré par un indice variant de 1 à NTR,et tels que chaque élément de l'ensemble des tâches non nécessairement régulières soit re-
péré par un indice variant de NTR + 1 à NT . Dans cet algorithme, R désigne un vecteur
d'élément de type rk,1. Sa dimension est initialement de NTR, correspondant aux nombresde tâches régulières, et elle devient à l'étape 4 NT .
5NTR pour Nombre de Tâches Régulières.6NT pour Nombre de Tâches.
104 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
Tab. 3.10: Nouvelle Conguration de tâche pour le contexte d'ordonnancement
EDF.ri,1 Ci Di Ti Commentaires
τNR1 0 2 2 32 Tâche de mesure de la température.
τNR2 3 1 32 32 Tâche de calcul de
la vitesse de l'aéronef.
τR1 2 3 3 32 Tâche de mesure de la pression.
τNR3 8 1 16 16 Tâches pour piloter la température
et la pression cabine.
τR2 8 2 4 16 Tâche de commande
des organes de vol.
τR3 7 1 1 16 Tâche de d'acquisition
des ordres de pilotage.
τNR4 0 2 10 10 Tâche d'alarme (rapide).
τNR5 0 3 56 56 Tâche d'achage.
3.3.6 Conclusion
Nous avons vu au travers de ces exemples qu'il était possible d'ordonnancer une congu-
ration de tâches en respectant les contraintes de régularité d'exécution de certaines tâches,
et ce, en utilisant les algorithmes d'ordonnancement basés sur les échéances (DM ou EDF)
ou sur les priorités xes, et en modiant les dates d'activation et les délais critiques. En
pratique cependant, la technique proposée reste délicate dans le cas de EDF : en eet,
comme nous l'avons souligné dans la remarque 3.1, page 86, le respect des contraintes de
précédence impliquent des exécutions sans préemption avec des délais critiques tels que :
Di = Ci. Ce qui réduit en fait considérablement les chances d'ordonnançabilité de la nou-
velle conguration sauf si une phase de désynchronisation est appliquée à ces tâches. C'est
d'ailleurs ce qui a été implicitement fait dans le dernier exemple sous EDF avec un choix
particulier pour le triplet solution au problème de désynchronisation (ce choix favorisait les
chances d'ordonnançabilité). Goosens dans [Goossens 03] a d'ailleurs montré à ce propos
qu'une conguration de tâches non ordonnançable avec des tâches à départ synchrone, peut
se révéler ordonnançable avec des tâches à départ diéré.
De plus, il faut souligner la plus grande exibilité de l'algorithme d'ordonnancement
DM (et de celui basé sur les priorités xes) lorsqu'il s'agit de maîtriser la gigue de certaines
tâches mises en jeu éventuellement dans des relations de précédence. Cette méthode reste
cependant non optimale, mais permet de proposer dans le contexte en ligne une solution à
la maîtrise des contraintes de régularité.
L'approche que nous proposons pour contrôler la gigue des tâches, comporte en outre
des algorithmes exponentiels (désynchronisation, tests d'ordonnançabilité), mais nous nous
sommes toujours placés dans l'hypothèse d'un nombre faible de tâches régulières. C'est
une hypothèse acceptable pour des applications temps réel classiques où le nombre de
tâches régulières est petit par rapport au nombre de tâches non nécessairement régulières.
Le problème de désynchronisation est également un problème exponentiel par rapport au
3.4 Prise en compte de ressources partagées 105
Algorithme 1 L'algorithme permettant de contrôler la gigue de régularité des tâches de
R dans le contexte DM ou EDF.
1. R ← ri1,11≤i1≤NTR , ri2,11≤i2≤NTR , ... | (∀j ∈ 1, 2, 3, ...rij ,11≤ij≤NTRsatisfait le
critère de désynchronisation.2. Retenir dans R les vecteurs qui satisfont les contraintes de précédence entre deux tâches
régulières.
3. Pour chaque vecteur Rj dans R faire
4. Rj ←Rj ∪ rk,1NTR+1≤k≤NT , de sorte que le nouveau vecteur Rj
4. respecte les conditions liées aux contraintes de précédence.
5. n faire.
6. D ← Wi1≤i≤NTR (Wi est supposé donné pour chaque tâche de R).7. D ← D∪DkNTR+1≤k≤NT , de tel sorte que le nouveau vecteur D respecte les conditions
liées aux contraintes de précédence.
8. Pour chaque vecteur Rj dans R faire
9. Vérier l'ordonnançabilité de ((Rj)i, Ci,Di, Ti)1≤i≤NT .
10. n faire.
paramètreWi, mais là encore en pratique, nous supposons de faibles valeurs deWi. En eet,
le paramètreWi est déni pour une tâche régulière qui est en général une tâche d'acquisition
où la durée d'exécution Ci est très faible devant la période Ti de la tâche. Le paramètre Wi
mesurant le niveau de gigue souhaité, il est donc généralement proche de Ci, donc faible.
Finalement, la durée des temps de calcul auxquels nous avons fait face dans les diérents
exemples, était toujours en deçà de la minute (Pentium III, 450Mhz ).
An d'obtenir des ordres de grandeur et d'observer l'évolution de ces temps de calcul,
nous avons mené des simulations avec une conguration de 10 tâches, pour lesquelles les
tâches régulières possédaient un maximum sur les périodes de 18 et un maximum sur les
Wi de 3. Pour un nombre de tâches régulières inférieur ou égal à 5, les temps de calcul
obtenus sont en dessous de la minute. Pour 6 tâches, il faut 8 minutes environ, et pour 7tâches, il faut compter 1 heure 30 : les temps de calcul sont donc en pratique clairement
exponentiels.
3.4 Prise en compte de ressources partagées
Dans cette section, nous décrivons la démarche d'ordonnancement d'un système de
tâches, dans lequel on doit respecter à la fois des contraintes de régularité d'exécution,
mais aussi des contraintes de gestion de ressources partagées. Nous donnons pour cela les
conséquences des diérents mécanismes de gestion de ressources sur notre technique de
traitement de la gigue, puis nous donnons les nécessaires adaptations pour rendre ces deux
objectifs compatibles. Nous débutons par le cas d'une ressource partagée par deux tâches
temps réel, puis nous terminons par le cas plus général d'une ressource partagée par ntâches.
106 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
3.4.1 Ressource partagée par deux tâches
Deux tâches régulières R
Que ce soit dans le cas de l'annulation ou de l'encadrement de la gigue, la technique de
désynchronisation donne, lorsqu'elle existe, une ou des séquence(s) d'ordonnancement dans
laquelle ou lesquelles, les tâches régulières R sont désynchronisées les unes par rapport aux
autres : le partage de ressources entre ce type de tâches n'entraîne donc pas de demandes
concurrentes de la ressource critique. La situation obtenue conduit à un contexte non pré-
emptif de ces deux tâches. Il n'y a donc pas d'incompatibilité entre ces deux objectifs, et
nous pouvons même dans ce cas, nous aranchir des protocoles classiques de gestion de
ressources critiques.
Deux tâches non-régulières NR
Cas de l'annulation de la gigue. Si on se place dans ce cas, alors les tâches de R sont
toutes de priorité plus grande que celle de NR. Cette propriété, combinée à la phase dedésynchronisation assure une exécution sans préemption et strictement périodique des
tâches de R. Les mécanismes classiques de gestion des ressources critiques (héritage de
priorité, priorité plafonnée, etc...) vont modier ponctuellement les priorités de certaines
tâches demandant une ressource, héritant en fait des priorités d'autres tâches demandant
ces mêmes ressources. Comme ces mécanismes sont appliqués ici aux seules tâches deNR,qui sont toutes de priorité strictement inférieure aux tâches de R, la seule conséquence
de ces changements de priorités se traduira par un ordonnancement diérent pour les
tâches de NR, ordonnancement qui pourra entraîner une faute temporelle et rendre la
conguration de tâches non ordonnançable. La propriété de régularité d'exécution des
tâches obtenue par notre technique n'est cependant pas altérée. Dans ce cas, on peut
donc utiliser les protocoles classiques de gestion de ressources critiques.
Cas de l'encadrement de la gigue. Dans ce cas, les tâches NR peuvent venir pré-
empter des tâches de R dans une certaine limite ; cette limite étant xée par la gigue
maximum autorisée pour une tâche. Supposons donc que c'est le cas : une tâche R est
préemptée par une tâche de NR, notée τj qui possède une section critique de durée SCj.
• Si les mécanismes de gestion de ressources ne sont pas utilisés, que ce soit implicite-
ment au travers d'une spécication particulière au niveau de l'ordonnanceur, ou que
ce soit explicitement au travers de l'application d'un protocole, alors notre propriété
de gigue maîtrisée n'est plus assurée. En eet, le moindre partage de ressources entre
τi et une autre tâche de NR pourra se traduire par un allongement de la fenêtre
d'exécution de la tâche τi, et au delà, de celle de la tâche régulière. En outre, les
phénomènes d'inversion de priorité et d'interblocage peuvent intervenir.
• Si au contraire, nous utilisons les mécanismes de gestion de ressources (héritage,
etc...), ces deux phénomènes peuvent être évités. Par contre, on doit relâcher nos
contraintes d'encadrement sur la gigue. En eet, si on note τj la tâche de NR parta-
geant la ressource avec τi, et si on désigne sa durée de section critique par SCj, il sera
alors nécessaire d'ajouter à la largeur de la fenêtre d'exécution de la tâche régulière,
une durée supplémentaire correspondant au temps de blocage maximum de la tâche
3.4 Prise en compte de ressources partagées 107
τj [Sha 90, Buttazzo 97]. Cette durée allongera d'autant la durée de préemption de la
tâche τi par la tâche τj .
Pour la technique d'encadrement de la gigue, l'utilisation des protocoles de gestion
de ressources critiques entre deux tâches NR peut donc induire une augmentation de
la durée de la fenêtre d'exécution de certaines tâches de R, et augmenter ainsi leur
gigue. Il s'agit donc d'identier les interactions éventuelles des tâches de R et des
tâches de NR, dû à un partage de ressources critiques. Ces interactions désignées, il
sut alors d'augmenter pour chaque interaction (et donc préemption), la durée de la
fenêtre d'exécution de ces tâches R, en ajoutant la durée de blocage maximum des
tâches de NR provoquant l'héritage de priorité. Les contraintes d'encadrement de la
gigue devront donc être moins sévères.
Illustration. Illustrons ce principe au travers d'un exemple. Soit τi une tâche régulière etsoit τj une tâche non nécessairement régulière. On note Bj le temps de blocage maximum
de la tâche τj (il dépend du protocole utilisé [Buttazzo 97]). On suppose que la tâche τjpréempte la tâche τi. Dans une situation idéale, on peut supposer qu'il n'y a pas de blocage
de τj et que la durée de la section critique SCj de τj est incluse dans la durée de préemption
(cf gure 3.17-a). Si maintenant la tâche τj se bloque pendant Bj à cause d'une autre tâche
quelconque non régulière, le principe de notre technique de maîtrise de la gigue n'est plus
assurée. Il convient alors d'élargir la fenêtre d'exécution d'une longueur correspondant à
Bj−SCj (cf. gure 3.17-b). La démarche consiste donc au niveau de l'étape 1, à considérer
des largeurs de fenêtre d'exécution pour le problème de désynchronisation, qui puissent
contenir le temps de blocage maximum des tâches venant préempter les tâches régulières.
Fig. 3.17: (a) : exécution de la tâche régulière τi avec préemption par la tâche
non régulière τj (présence de la section critique SCj) - (b) : durée de préemption
allongée pour faire face au temps de blocage éventuel de τj .
Une tâche régulière R et une tâche non-régulière NR
Cas de l'annulation de la gigue. Dans ce cas, la tâche de R devant s'exécuter en bloc
et sans préemption, on doit nécessairement éviter un héritage de priorité entre une tâche
de R et une tâche de NR. Rappelons que dans notre technique, les priorités des tâches de
108 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
R sont plus grandes que celles de NR. La gestion de ressources critiques partagées entre
ces deux types de tâche est donc impossible dans ce cas, puisque le moindre héritage de
priorité, provoquant une préemption, est incompatible avec une exécution en bloc des
tâches de R.
Cas de l'encadrement de la gigue. Contrairement au cas précédent, la préemption
peut ici avoir lieu, dans la limite de la gigue maximum désirée. Nous pouvons en eet
faire la même remarque que dans la section ci-avant, et ajouter à la durée de la fenêtre
d'exécution de la tâche R, la durée du temps de blocage maximum de la tâche NRprovoquant l'héritage de priorité. La nouvelle gigue sera alors plus importante que dans
le cas sans partage de ressources.
3.4.2 Ressource partagée par plusieurs tâches
Entre plusieurs tâches régulières R
Il sut de généraliser la remarque faite pour le cas de deux tâches R, et il n'y a alors
aucun problème de demande concurrente d'une ressource critique.
Entre plusieurs tâches non-régulières NR
La généralisation du cas de deux tâches de NR partageant une ressource critique amène
à distinguer les deux approches : annulation de la gigue ou encadrement.
Cas de l'annulation de la gigue. La gestion des ressources critiques entre plusieurs
tâches de NR va se traduire ici par un ordonnancement diérent des tâches de NR,laissant de côté les tâches de R qui sont par construction, de priorité strictement plus
grande que les tâches de NR. Si la propriété d'ordonnançabilité de la conguration de
tâches est conservée après la prise en compte des protocoles de gestion de ressources
critiques, les gigues des tâches régulières seront alors toujours nulles.
Cas de l'encadrement de la gigue. A contrario pour l'encadrement, il s'agit de repé-
rer toutes préemptions des tâches de R par des tâches de NR, puis d'ajouter une certainedurée à la fenêtre d'exécution de chacune de ces tâches R. Les durées à rajouter sont
fonction du protocole de gestion de ressources choisi. En eet [Buttazzo 97], avec le proto-
cole d'héritage de priorité (PHP), pour une tâche τi de NR la durée d'attente maximum
d'une ressource est égale à la somme des durées des sections critiques des tâches moins
prioritaires partageant les mêmes ressources. Quant au protocole de la priorité plafonnée
(PPP), la durée d'attente maximum pour une tâche τi de NR est donnée par la plus
grande des durées des sections critiques des tâches moins prioritaires dont les ressources
ont une priorité plafond supérieure ou égale à celle de la tâche τi. Les contraintes degigues sur ces tâches devront nalement être moins sévères.
Entre p tâches régulières R et q tâches non-régulières NR
Cas de l'annulation de la gigue. Le terme d'héritage de priorité n'a de sens que lors-
qu'une tâche de NR hérite d'une priorité plus grande qu'une tâche de R : dans ce cas,
l'exécution sans préemption de la tâche de R n'est plus assurée, et annuler la gigue de
cette tâche devient impossible.
3.5 Application au contrôle d'autres paramètres 109
Cas de l'encadrement de la gigue. Il s'agit ici comme dans le paragraphe ci-dessus,
d'identier les tâches de R qui sont préemptées par des tâches de NR, et qui partagent lesmêmes ressources critiques. Ensuite, on ajoute à chaque durée de la fenêtre d'exécution
de ces tâches de R, les durées maximum d'attente de ressources des tâches de NR qui
préemptent ces tâches de R. On retrouve alors les durées décrites dans le paragraphe
précédent suivant le protocole retenu. Les contraintes de gigues des tâches régulières
devront ainsi être moins sévères.
3.4.3 Résumé
Nous avons reporté dans le tableau 3.11 les diérents cas distingués dans cette section.
Ce tableau permet ainsi de mieux cibler les contextes d'utilisation qui mènent à des cas
impossibles. A noter cependant que les cas où la technique peut être appliquée ne conduit
pas nécessairement à une solution : il se peut qu'au nal qu'aucune conguration ne soit
ordonnançable (approche non optimale).
Tab. 3.11: Tableau récapitulatif distinguant les cas possibles des cas impossibles
lorsqu'on applique la technique de traitement de la gigue avec des tâches parta-
geant des ressources critiques.Ressources partagées entre
plusieurs tâches de R plusieurs tâches de NR p tâches de R
et q tâches de NR
Annulation de la gigue Oui Oui Impossible
Encadrement de la gigue Oui Oui mais peut être Oui mais peut être
nécessaire de relâcher nécessaire de relâcher
les contraintes de gigue. les contraintes de gigue.
3.5 Application au contrôle d'autres paramètres
La technique de contrôle de la gigue présentée dans les sections précédentes, ne traite
pas du cas de la gigue de bout en bout. Nous savons cependant gérer les contraintes de
précédence, qui sont à la base de la dénition d'une activité. Dans la première partie de
cette section, nous verrons donc comment adapter la technique de traitement de la gigue
de régularité au traitement de la gigue de bout en bout.
Nous avons vu par ailleurs dans le chapitre 1 que la gigue de régularité telle que nous
l'avons dénie, pouvait se rapporter à la diérence des temps de réponse entre deux instances
successives d'une tâche (cf. gigue de Buttazzo But−r(τi) dans paragraphe 1.5.1). Nous verronsalors dans la seconde partie de cette section, comment notre technique de traitement de la
gigue de régularité peut servir au contrôle du temps de réponse des tâches ou des activités.
110 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
3.5.1 Traitement de la gigue de bout en bout
La plupart des activités sur lesquelles on étudie la gigue de bout en bout comportent
des tâches d'acquisition de données ou des tâches liées à des actionneurs. Pour ces tâches,
le phénomène de gigue de régularité doit être évité ou du moins encadré dans une certaine
proportion. En revanche, les tâches de calcul, qui peuvent aussi faire parties de l'activité,
peuvent ne pas avoir les mêmes besoins en terme de régularité d'exécution. Aussi dans cette
section, les techniques qui vont être présentées, devront combiner les contraintes de gigue
de bout en bout sur des activités à l'intérieur desquelles, des tâches n'auront pas forcément
des contraintes de gigue de régularité.
Rappelons tout d'abord que la gigue de bout en bout est construite sur les termes
TRk, avec k désignant l'instance considérée pour l'activité. Pour une activité a formée de
n tâches τ1, ..., τn, TRk représente la distance séparant le début d'exécution de la kième
instance de τ1, et la n d'exécution de la kième instance de τn (on suppose les périodes
Ti des tâches identiques et égales à une constante Ta). La gigue de bout en bout mesure
alors les uctuations des temps de réponses TRk d'une activité par rapport au temps de
réponse théorique (TRTh) (donné par les spécications du problème, par exemple une loi
de commande (automatique)) (cf. paragraphe 1.4.2 et annexe B). Les bornes minimum
et maximum ont été données dans le paragraphe 1.4.2, on a : TRmin(a) =∑n
i=1Ci, et
pour la borne maximum, on a : TRmax(a) = Ta si les tâches sont à départ simultané, ou
TRmax(a) = 2Ta − C1 si les tâches sont à départ diéré.
L'application de notre technique de traitement de la gigue de régularité peut donner en
fait des résultats intéressants pour l'encadrement de la gigue, car dans cette approche, nous
pouvons gérer tous les types de précédence et donc tout type d'activité. En revanche, dans
l'approche qui consiste à annuler les gigues, nous verrons que l'hypothèse selon laquelle on
doit écarter les précédences du type τNR → τR (cf. paragraphe 3.2.3.2, étape 3), restreint en
fait le domaine d'application de la technique. Dans le premier paragraphe de cette section
nous verrons d'abord la technique proposée pour annuler, si c'est possible, la gigue de bout
en bout. Puis, dans un second paragraphe, nous proposerons une technique pour borner
la gigue de bout en bout. Rappelons par ailleurs l'hypothèse selon laquelle les tâches que
nous considérons dans une activité quelconque ont toutes la même période Ta (cas des
précédences simples).
3.5.1.1 Annulation de la gigue de bout en bout
Dans ce paragraphe, nous souhaitons que les durées écoulées entre le début d'exécution
d'une instance de τ1, celle démarrant l'activité, et la n d'exécution de l'instance de τn lui
correspondant, celle terminant l'activité, soient identiques au temps de réponse théorique
TRTh. A l'intérieur de cette activité et conformément à la description faite dans le para-
graphe 3.2, étape 2, nous ne pouvons pas gérer des relations de précédence mettant en jeu
une tâche régulière τR qui serait précédée par une tâche non nécessairement régulière τNR
(relation P4 : τNR → τR de la gure 3.10, page 84). Cette hypothèse est cependant très
restrictive vis-à-vis de l'activité, puisque la tâche τn qui termine l'activité est généralement
une tâche régulière qui envoie une commande strictement périodique vers un actionneur.
Partant du principe que la dernière tâche τn est nécessairement régulière, on va supposer
que toutes les tâches de l'activité sont des tâches régulières, ceci an de pouvoir appliquer
3.5 Application au contrôle d'autres paramètres 111
directement la technique d'annulation de la gigue développée dans la section 3.2. L'appli-
cation de la technique sur toutes les tâches régulières formant l'activité conduit alors à un
ensemble d'exécutions régulières et non préemptées, des tâches τi (i ∈ [|1;n|]), exécutionsqui démarrent aux diérentes dates d'activation (ri,j, i ∈ [|1;n|], j ≥ 1) et qui se terminent
Ci unités de temps processeur plus tard. L'illustration de ces exécutions est reportée dans
la gure 3.18. A noter que les dates d'activations de τn sont nécessairement en dehors des
fenêtres d'exécution de chaque tâche formant l'activité. Pour tout entier k non nul, le temps
de réponse TRk est alors
TRk = rn,k − r1,k + Cn. (3.40)
An d'annuler ou de réduire la gigue de bout en bout, il s'agit alors, si cela est possible, de
choisir parmi les diérentes dates d'activation résultant du problème de désynchronisation
et du problème du respect des contraintes de précédence, les dates d'activation qui seront
telles que rn,k − r1,k + Cn = TRTh, où TRTh représente le temps de réponse théorique (cf.
paragraphe 1.4.2). Si on ne peut pas trouver la valeur exacte pour l'annulation, on pourra
se contenter d'une valeur approchée, auquel cas, le temps de réponse sera constant mais
ne sera pas celui prévu en théorie (TRTH). Néanmoins pour le domaine de l'automatique,
quand le retard ou l'avance est constant et connu, il existe des méthodes pour maintenir la
stabilité du procédé contrôlé.
Cette technique de traitement de la gigue de bout en bout n'est en outre qu'une condi-
tion susante pour obtenir des temps de réponse (TRk) constants avec éventuellement
l'annulation complète de la gigue. Il faudra cependant par la suite trouver une technique
qui n'impose la régularité d'exécution que sur les tâches de l'activité liées à des actionneurs
ou à des acquisitions, et non aux tâches de calcul qui n'ont pas de contrainte d'exécution
strictement régulière.
Fig. 3.18: Le temps de réponse de bout en bout après l'application de la tech-
nique de traitement de la gigue de régularité sur les tâches formant l'activité.
Exemple. Soit une activité a =< τ1, τ2, τ3 > contenant trois tâches régulières. On ap-
plique alors, selon la description ci-dessus, la technique décrite dans le paragraphe 3.2.3.2
sur les tâches de l'activité. Leurs exécutions sont alors régulières et sans préemption (cf.
gure 3.19). Les temps de réponse TRa,i (i ≥ 1) de l'activité sont alors les mêmes, et s'ils
correspondent aux temps de réponse théorique, la gigue de bout en bout est annulée. Dans
le cas contraire, le temps de réponse est constant et le domaine de l'automatique sait gérer
les problèmes d'avance ou de retard constant(e).
112 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
Fig. 3.19: Les temps de réponse d'une activité a =< τ1, τ2, τ3 > une fois le
traitement de la gigue de bout en bout appliquée : les TRa,i (1 ≤ i ≤ 7) sontidentiques et sont choisis de telle sorte qu'ils soient aussi proches que possible
de TRTh.
3.5.1.2 Encadrement de la gigue de bout en bout
Pour l'encadrement simple de la gigue de bout en bout, les hypothèses sont moins
restrictives : on va en eet appliquer la technique d'encadrement de la gigue de régularité
sur la tâche τ1, débutant l'activité et sur la tâche τn, terminant l'activité, an de maîtriser
seulement les uctuations de l'exécution de τ1 et de τn. L'avantage dans cette approche,
c'est que tout type de précédence est autorisé, ce qui élargit le domaine d'application de
la technique. Après avoir mené les trois premières étapes de la technique de traitement de
la gigue de régularité sur τ1 et τn, comme nous l'avons fait dans le paragraphe précédent,
on va choisir parmi les solutions aux problèmes de désynchronisation et de précédences, les
dates d'activations r1,k et rn,k de telle sorte que les temps de réponse TRk de l'activité se
rapprochent le plus possible du temps de réponse théorique idéal TRTh.
Déterminons plus en détail les conditions régissant le choix des dates d'activation. Sup-
posons pour cela avoir mené la technique de traitement de la gigue régulière sur τ1 et τn,avec comme paramètre respectif pour la largeur maximum des fenêtres d'exécution : W1 et
Wn. Calculons alors les temps de réponse minimum et maximum possibles (cf. gure 3.20).
Soient TRmin et TRmax ces temps de réponse respectifs. Pour les kième instances, on a les
relations suivantes :
TRmin = rn,k + Cn − (r1,k +W1 − C1) (3.41)
TRmax = rn,k +Wn − (r1,k).
Pour réduire la gigue de bout en bout, il faut que TRmin et TRmax se rapprochent le plus
possible du temps de réponse théorique TRTh, supposé donné. Le problème consiste alors à
choisir W1 et Wn7 puis r1,1 et r1,n, de tels sorte que TRTh−TRmin et TRmax−TRTh soient
minimisés. Pour résoudre ce problème de minimisation, qui est alors plus complexe que le
"simple" problème de minimisation de la gigue, on peut ajouter à l'algorithme de traitement
de la gigue, une étape en amont qui xe des valeurs pourW1 etWn, et une étape en aval qui
évalue les résultats possibles sur les quantités TRTh − TRmin et TRmax − TRTh, résultats
7Pour W1 et Wn, il faut par ailleurs que Wi ≥ Ci.
3.5 Application au contrôle d'autres paramètres 113
qui dépendent directement des solutions en terme de date d'activation. Si les résultats ne
sont pas probants, on peut alors mener une recherche exhaustive sur l'ensemble des W1 et
Wn possibles et voir quels sont les minimums que nous pouvons obtenir pour TRTh−TRmin
et TRmax − TRTh. Dans le cas où il serait impossible de minimiser totalement ces deux
quantités, le simple fait de connaître l'intervalle de uctuation des temps de réponse permet
pour l'automaticien d'envisager dans un premier temps une modélisation probabiliste du
temps de réponse dans l'intervalle connu, et dans une second temps un meilleur contrôle de
stabilité.
Fig. 3.20: Les temps de réponse minimum (a) et maximum (b) d'une activité
a =< τ1, ..., τn > une fois la technique de traitement de la gigue de bout en bout
appliquée sur τ1 et τn.
3.5.2 Traitement du temps de réponse
Nous allons voir dans ce paragraphe que le contrôle du temps de réponse d'une tâche
(tr) ou d'une activité (TR) peut être réalisé avec la technique de traitement de la gigue.
Rappelons que la gigue de régularité que nous avons introduite dans le chapitre 1 peut être
rapportée dans sa version de type "moyenne" à une gigue basée sur les temps de réponse.
• Pour le contrôle du temps de réponse d'une seule tâche τi, il sut en fait d'appliquer
directement, soit la technique d'annulation de la gigue sur τi pour obtenir un temps
de réponse (tr) constant (égal à Ci), soit la technique d'encadrement de la gigue sur τipour obtenir un temps de réponse maximum borné (par Wi). Dans ce dernier cas, on
pourra appliquer la technique d'encadrement avec le temps de réponse maximum désiré
et vérier si l'on peut mener à terme la technique (c'est-à-dire qu'il existe encore des
congurations ordonnançables au terme de l'étape 4).
• Pour le contrôle du temps de réponse d'une activité a, il faut identier parmi les tâches
formant l'activité celles qui sont dans R et celles de NR. Indubitablement pour les tâches
114 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
de NR, nous devons avoir accès à la largeur maximum de leur intervalle d'exécution, sans
quoi il serait dicile de maîtriser le temps de réponse de l'activité. Une solution consiste
alors à considérer que l'ensemble des tâches formant l'activité doivent se voir appliquer
la technique d'encadrement de la gigue. En outre, formant une activité, l'exécution de
ces tâches doit se faire dans le respect des relations de précédence8 (cf. gure 3.21).
Fig. 3.21: Le temps de réponse maximum (TRmax(a)) de bout en bout de a,face aux tâches de NR faisant partie intégrante de l'activité.
Pour contrôler le temps de réponse (TR) d'une activité a, on va donc considérer l'en-
semble des tâches formant l'activité comme des tâches régulières, sur lesquelles nous
allons appliquer la technique d'encadrement de la gigue. En outre, an de contrôler le
mieux possible le temps de réponse, on va faire en sorte que les fenêtres d'exécution
soient contiguës ; en d'autres termes, on va appliquer pour toute instance k de l'activité,les relations suivantes :
∀i ∈ 1, ..., n ri,1 − ri−1,1 =Wi−1 (3.42)
Dans l'ensemble des Wi, il faut distinguer les Wi liés aux tâches régulières R, et ceuxliés aux tâches de NR. Pour les premiers, les Wi peuvent être spéciés par trmax(τi)supposés connus, et pour les seconds nous allons devoir les préciser. L'application de
la technique d'encadrement de la gigue passe en outre par la distinction de l'algorithme
d'ordonnancement utilisé. Lorsqu'il y a des relations de précédences, ce choix conditionne
en eet une dénition particulière des Wi pour le problème de désynchronisation (cf.
section 3.3.3, étape 2, cas EDF).
Cas DM. An de répondre aux conditions décrites ci-dessus, il faut dénir pour toutes
les tâches de l'activité les paramètres Wi. Deux cas se présentent alors :
A) soit tous les paramètres Wi sont à préciser,
B) soit au contraire, les paramètres Wi des tâches τi de R sont déjà spéciés par le
cahier des charges et il ne reste alors que celles des tâches de NR à choisir.
Cas A Posons pour chaque tâche τj de l'activité :
Wj =Cj × TRMax(a)∑n
i=1Ci, (3.43)
8Rappelons que dans le cadre de l'encadrement de la gigue, tout type de relation de précédence peut
être pris en compte.
3.5 Application au contrôle d'autres paramètres 115
où TRMax(a) est le temps de réponse maximum désiré pour l'activité a. Wj est
construit de sorte que l'espace réservé pour les tâches τj soit proportionnel à l'es-
pace qu'elles auraient demandé si on avait exécuté les tâches en bloc et de manière
contiguë, et de sorte que :∑n
j=1Wj = TRMax(a). L'inconvénient avec cette déni-tion, c'est que Wj n'est pas entier ; on préfère donc poser :
Wj =
⌊Cj × TRMax(a)∑n
i=1 Ci
⌋, (3.44)
de sorte que∑n
j=1Wj ≤ TRMax(a) et que Wj soit bien entier.
Cas B Désignons par τj , j ∈ [|1; q|] les tâches incluses dans NR (avec q ≤ n et q =nombre de tâches de NR dans l'activité considérée), on choisit pour ces tâches un
paramètre Wj tel que :
Wj =
⌊Cj∑qi=1 Ci
(TRMax(a) −n∑
i=q+1
Wi)
⌋, (3.45)
où Wi concerne les tâches R, et de sorte queq∑
j=1
Wj ≤ TRMax(a) −n∑
j=q+1
Wj , (3.46)
pour qu'au nal, on ait :n∑
j=1
Wj ≤ TRMax(a). (3.47)
A noter que nous supposons en pratique que TRmax(a) >∑n
j=q+1Wj , soit encore
que le temps de réponse maximum est supérieur strictement à la somme des largeurs
de fenêtre d'exécution des tâches de R.
On déroule ensuite les quatre étapes présentées dans la section 3.3.3, partie DM,
mais dans le choix des uplets solutions au problème de désynchronisation (début
de l'étape 2), on sélectionne ceux qui répondent aussi à la contrainte 3.42 ci-dessus.
Cas EDF. C'est en fait toujours le même principe à la diérence près que le paramètre
Wi d'une tâche τi, précédant n'importe quel autre type de tâche, est déjà prédétermi-
née par les conditions de la section 3.3.3 étape 3, qui précise que Wi = Ci. Les tâches
sur lesquelles on pourra faire varier la gigue de cohésion sont donc celles qui terminent
une activité. Ainsi pour obtenir le temps de réponse maximum TRMax(a), il sura dedénir un paramètre Wn pour la tâche τn qui termine les activités, selon l'expression :
Wn = TRMax(a) −n−1∑i=1
Ci (3.48)
où Ci, 1 ≤ i ≤ n − 1, sont les durées d'exécution des tâches de l'activité qui sont
toujours suivies d'un successeur. Les quatre étapes décrites dans la section 3.3.3, cas
EDF, sont alors à réaliser, à ceci près que dans le choix des dates d'activation solutions
du problème de désynchronisation (début de l'étape 2), on choisit, quand elles existent,
celles qui vérient également la contrainte 3.42 ci-dessus.
116 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
Illustrons maintenant cette technique dans le cas DM au travers d'un exemple.
Exemple
Prenons pour cela une conguration de tâches constituée d'une activité a =< τ1, τ2, τ3 >type contrôle-traitement-commande et constituée d'autres tâches non inter-dépendantes
(cf. gure 3.22 et tableau 3.12). Appliquons alors les principes d'encadrement de la gigue
d'activité pour le contexte DM. Dans cette conguration, sont considérées comme régulières
les tâches τ1, τ3 et τ4. τ2 faisant de plus partie de l'activité a, on la considère aussi comme une
tâche de R. Supposons en outre que τ1, τ3 et τ4 possèdent chacune une spécication sur les
temps de réponse maximum des tâches : trmax(τ1) = 3, trmax(τ3) = 3 et trmax(τ4) = 2. Onsuppose par ailleurs vouloir un temps de réponse maximum de l'activité de : TRMax(a) = 10.On est typiquement ici dans le contexte B) du paragraphe précédent, et il nous faut donc
spécier le paramètre Wi nécessaire à τ2, pour respecter la gigue maximum de l'activité.
D'après l'équation (3.45), on a :
Wτ2 =3
3(10 − (3 + 3)) = 4. (3.49)
Tab. 3.12: Les paramètres temporels des tâches de l'application temps réel.ri,1 Ci Di Ti
τR1 - Acquisition 0 2 32 32
τNR2 - Traitement 0 3 32 32
τR3 - Contrôle 0 2 32 32
τR4 - Acquisition 0 1 16 16
τNR5 - Alarme 0 1 5 5
τNR6 - Achage 0 4 48 48
Fig. 3.22: Exemple d'application temps réel comportant une activité.
On applique alors tour à tour les 4 étapes en considérant dans l'ensemble R, les tâchesτ1, τ2, τ3 et τ4.
Etape 1 Le problème de désynchronisation avec W1 = 3, W2 = 4, W3 = 3 et W4 = 2donne alors une palette de 67344 quadruplets solutions diérents.
3.5 Application au contrôle d'autres paramètres 117
Etape 2 Dans ces solutions, on va garder celles qui vérient les conditions de précédence :
r1,1 ≤ r2,1 ≤ r3,1 (3.50)
et les conditions 3.45 décrites dans le paragraphe précédent, à savoir :
r2,1 − r1,1 = W1 = 3r3,1 − r2,1 = W2 = 4
, (3.51)
Parmi ces solutions, il y a par exemple le quadruplet : (r1,1, r2,1, r3,1, r4,1) = (0, 3, 7, 10).Pour ce qui est des délais critiques des tâches mises en jeu dans l'activité, il sut de
prendre juste les conditions de l'étape 3 (cf. paragraphe 3.3.3, Etape 2 et 3, pour justi-
cation).
Etape 3 Dans cet étape on redénit les délais critiques des tâches de R selon les relations :
D1 = W1 = 3D2 = W2 = 4D3 = W3 = 3D4 = W4 = 2
, (3.52)
qui garantissent alors des exécutions dans des intervalles de largeur Wi, et qui susent
alors avec les dates d'activation choisies dans l'étape 2, de respecter les relations de
précédence et les contraintes de désynchronisation.
Etape 4 On recherche parmi l'ensemble des congurations de tâches possibles, celles qui
sont ordonnançables. En prenant par exemple les attributs temporels précisés pendant
cette illustration, nous obtenons une conguration ordonnançable (cf. gure 3.23) dont
la séquence des tâches de l'activité a est bien respectée et dont le temps de réponse
maximum de l'activité est borné par 10, ce que nous souhaitions obtenir.
Fig. 3.23: Une partie de la séquence ordonnancée par DM après avoir modier
les attributs temporels des tâches suivant notre technique de traitement de la
gigue de bout en bout.
118 Technique de Traitement de la Gigue dans les Systèmes Temps Réel
3.6 Conclusion
Nous avons introduit dans un premier temps les outils nécessaires pour la mise en place
de notre technique de traitement de la gigue.
• Le premier outil permet de désynchroniser au travers d'un décalage des dates d'activa-
tion, les fenêtres d'exécutions d'un nombre donné de tâches.
• Le deuxième outil rappelle les conditions à respecter pour maintenir les relations de
précédence entre les tâches.
• Le troisième outil donne les conditions à respecter par les paramètres des tâches pour
dénir des priorités plus grandes pour les tâches régulières par rapport aux priorités des
tâches de NR.
• Le quatrième outil enn évoque le principe des tests d'ordonnançabilité.
Ces outils ont ensuite été utilisés dans les deux sections suivantes et ont permis au tra-
vers de quatre étapes, l'annulation ou l'encadrement de la gigue de régularité des tâches
considérées comme régulières. Ces quatre étapes sont : la désynchronisation des fenêtres
d'exécution, le maintien des relations de précédence, le changement de priorités des tâches
régulières par rapport aux tâches non nécessairement régulières, et les tests d'ordonnança-
bilité sur les nouvelles congurations de tâches obtenues.
La mise en place de ces quatre étapes est apparue plus simple à mettre en ÷uvre
dans le contexte d'ordonnancement DM, que dans le contexte d'ordonnancement EDF,
où en fait, il est dicile de maîtriser les priorités des tâches pour gérer principalement les
relations de précédence. La technique proposée n'est évidemment pas optimale et peut nous
conduire à des congurations de tâches non ordonnançables. Cette technique contribue ainsi
dans certains cas à des "zones" d'ordonnancement de fortes contraintes, et une démarche
naturelle consisterait à chercher des conditions nécessaires et susantes pour l'annulation
ou l'encadrement de la gigue dans ce contexte en ligne. Pour accéder à cette démarche,
il faudrait enlever la condition de non chevauchement des fenêtres d'exécution des tâches
de R, puisqu'il est en eet possible de trouver une séquence d'exécution de tâches de Rqui se préemptent entre elles, et pour laquelle la gigue est nulle : on se rapprocherait
alors des technique d'annulation de la gigue dans le cadre hors ligne, hypothèse que nous
écartons. Au travers de conditions susantes simples, cette technique permet néanmoins
à un concepteur d'application temps réel de dénir en amont les paramètres des tâches de
sorte que non seulement les contraintes de précédence et d'échéance soient vériées, mais
aussi les contraintes de régularité d'exécution de certaines tâches.
Pour clore ce chapitre, nous avons d'une part vérié la compatibilité de notre technique
avec les principaux protocoles de gestion des ressources critiques. Nous avons alors distingué
un seul cas impossible (annulation de la gigue avec des ressources partagées à la fois par
des tâches de R et des tâches de NR). Nous avons pu adapter d'autre part notre technique
de traitement de la gigue à d'autres paramètres temporels comme la gigue de bout en bout
et le temps de réponse. Pour la gigue de bout en bout, nous avons distingué le cas de
l'annulation du cas de l'encadrement. Enn, pour le temps de réponse, nous proposons une
technique pour le gérer au niveau d'une tâche et au niveau d'une activité.
Dans le tableau 3.13 de la page 120, nous avons rassemblé l'ensemble des résultats
donnés dans ce chapitre. Il permet ainsi de voir que pour tel ou tel contexte d'utilisation,
3.6 Bibliographie 119
la technique de traitement de la gigue proposée, peut donner des réponses à la maîtrise de
la régularité d'exécution.
Pour mesurer plus nement l'intérêt de cette technique pour des applications temps réel
quelconques, nous allons proposer dans le chapitre suivant une expérimentation numérique
an de vérier le comportement de notre technique pour divers contextes d'utilisation.
Bibliographie
[Baruah 90] Baruah S.K., Howell R.R. et Rosier L.E. Algorithms and complexity
concerning the preemptive scheduling of periodic, real-time tasks on one
processor. Real-Time Systems, 1990, vol 2, p 301324.
[Bate 98] Bate I. J. Scheduling and Timing Analysis for Safety Critical Real-Time
Systems. Thèse : Department of Computer Science, University of York, nov.
1998.
[Buttazzo 97] Buttazzo G.C. Hard real-time computing systems, chapitre Periodic task
scheduling, p 77108. Kluwer Academic Publishers, 1997.
[Chetto 90] Chetto H., Silly M. et Bouchentouf T. Dynamic scheduling of real-
time task under precedence constraints. Real-Time Systems, 1990, vol 2, p
181194.
[Cottet 99] Cottet F. et David L. A solution to the time jitter removal in deadline
based scheduling of real-time applications. 5th IEEE Real-Time Technology
and Applications Symposium - WIP. Vancouver, Canada, 1999. p 3338.
[DiNatale 95] DiNatale M. et Stankovic A. Applicability of simulated annealing me-
thods to real-time scheduling and jitter control. Proc. of Real-Time Systems
Symposium, RTSS'95. Pisa, 1995. p 190199.
[Goossens 03] Goossens J. Scheduling of oset free systems. Real-Time Systems, 2003,
vol 24(2), p 239258.
[Knuth 69] Knuth D. E. The art of Computer Programming, volume 2 of Seminume-
rical Algorithms. Addison-Wesley, 1969.
[Richard 02] Richard P., Richard M. et Cottet F. Ordonnancement dans les sys-
tèmes distribués, chapitre Analyse holistique des systèmes temps réel distri-
bués : principes et algorithmes. Hermès (A paraître), 29p, 2002.
[Sha 90] Sha L., Rajkumar R. et Lehoczky J.P. Priority inheritance protocols :
an approach to real-time synchronisation. IEEE Transactions on Computers,
1990, vol 39(9), p 11751185.
[Tindell 94] Tindell K. et Clark J. Holistic schedulability analysis for distributed
hard real-time systems. Microprocessing and Microprogramming - Euromi-
cro Journal (Special Issue on Parallel Embedded Real-Time Systems), 1994,
vol 40, p 117134.
120 BIBLIOGRAPHIE
Tab. 3.13: Tableau récapitulatif des domaines possibles d'application de la tech-
nique de traitement de la gigue.Contrôle de la gigue de régularité.
Tâches indépendantes.
Annulation Encadrement
DM (ou Priorités Fixes) Possible Possible
EDF Possible Possible
Tâches dépendantes (relations de précédence).
Annulation Encadrement
DM (ou Priorités Fixes) Possible en écartant les Possible
relations du type τR → τNR
EDF Possible en écartant les Possible
relations du type τR → τNR
Tâches dépendantes & Partages de ressources.
Utilisation des protocoles classiques (PHP, PPP, PAP.)
Annulation Encadrement
Ressources partagées entre Possible Possible
plusieurs tâches de R
Ressources partagées entre Possible Possible mais peut être
plusieurs tâches de NR nécessaire de relâcher les
contraintes de gigues.
Ressources partagées entre Impossible Possible mais peut être
p tâches de R nécessaire de relâcher les
et q tâches de NR contraintes de gigues.
Contrôle de la gigue d'une activité.
Tâches dépendantes (activité).
Annulation Encadrement
DM (ou Priorités Fixes)/EDF Possible Possible
Contrôle du temps de réponse.
D'une ou plusieurs tâches.
Annulation Encadrement
DM (ou Priorités Fixes)/EDF Possible Possible
D'une ou plusieurs activités.
DM (ou Priorités Fixes)/EDF Possible Possible
Chapitre 4
Expérimentations Numériques
An de confronter la pertinence et l'ecacité de notre technique à la diversité des
congurations de tâches rencontrées dans le contexte temps réel, nous faisons appel à des
outils de simulations numériques. Ces outils devront dans un premier temps, générer des
congurations de tâches de manière aléatoire, sur lesquelles dans un second temps, devra
être appliquée la technique de traitement de la gigue. En dénissant correctement le ca-
ractère aléatoire de la génération et en mesurant ensuite la faisabilité de notre technique,
nous pourrons apporter des conclusions sur l'intérêt de celle-ci dans diérents contextes
d'ordonnancement (DM , EDF , charge processeur élevée, faible, etc).Dans une première partie, nous présentons l'outil que nous utilisons pour les simulations
numériques. Nous verrons en outre qu'il permet de caractériser les conditions favorables à
l'obtention de gigue pour des congurations quelconques de tâches. Dans une deuxième par-
tie, nous nous intéressons à mesurer l'ecacité de notre technique pour diérents contextes
d'utilisation, puis dans une dernière partie, nous faisons la synthèse des principaux résultats
de ces simulations.
4.1 Présentation de l'outil de simulations
Le programme de simulations numériques montrant l'intérêt de notre technique a été
développé en Ada95. Il comporte deux grands modules : un module de génération aléatoire
de congurations de tâches, et un module dans lequel la technique de traitement de la gigue
est implémentée.
Les algorithmes d'ordonnancement utilisés et implémentés dans ces deux modules sont
DM et EDF. Pour DM, le critère déterminant les priorités parmi les tâches se base d'abord
sur les délais critiques Di, puis sur les priorités xes que nous supposons uniques pour
l'ensemble des tâches considérées. Pour EDF, le critère se base sur l'échéance dynamique et
lorsqu'un cas d'égalité d'échéances intervient, avant d'en venir aux priorités xes, on assure
d'abord la continuation des tâches suspendues.
4.1.1 Module de génération de congurations de tâches
En utilisant une fonction du module générique Ada.Numerics.Discrete_Random qui
permet le tirage aléatoire de nombres discrets, nous avons réalisé une procédure de généra-
122 Expérimentations Numériques
tion aléatoire de congurations de tâches. Deux contraintes principales sont intégrées dans
cette génération : l'ordonnançabilité et l'obtention de gigue. En eet, s'agissant par la suite
de mettre en place notre technique de traitement de la gigue, il est intéressant de prendre en
compte de tels critères dans notre génération. Par ailleurs, dans un souci de simplication
et sachant que la technique de traitement de la gigue n'intervient qu'au niveau des para-
mètres ri,1 et Di, nous avons restreint le caractère aléatoire de la génération aux paramètres
Ci et Ti. On suppose pour cela que les tâches générées sont à départ simultané (ri,1 = 0)et à échéance sur requête (Di = Ti). Le développement de cette procédure de génération
a par ailleurs permis de préciser certains critères favorables à l'obtention de gigue pour
une conguration quelconque de tâches. Enn, une fois cette procédure réalisée, nous avons
analysé le type de répartition de gigue obtenue après la phase de génération aléatoire.
4.1.1.1 Procédure de génération de congurations
Le tirage aléatoire des paramètres temporels (Ci et Ti) est réalisé suivant une loi sta-tistique équiprobable (loi uniforme). Ci est ainsi choisie de manière équiprobable parmi un
ensemble d'entiers 1, ..., CiMax où CiMax est un entier donné supérieur ou égal à 1. Il enest de même pour le paramètre Ti. En utilisant plusieurs tirages pour ces deux paramètres
temporels, nous construisons par récurrence une conguration de tâches. A chaque étape nde la récurrence, on ajoute ainsi une tâche générée aléatoirement, et qui respecte certaines
contraintes de génération. La récurrence est alors terminée lorsque les paramètres de la
conguration correspondent aux contraintes nales souhaitées.
Voici plus en détail l'ensemble des paramètres d'entrées et de sorties de notre procédure
de génération, qui est désignée par Parameter_Generation. Décrivons dans un premier
temps les paramètres d'entrées, nous distinguons :
• le nombre désiré de tâches pour la conguration (MaxTask_Number),
• la durée d'exécution maximale autorisée pour les tâches (CiMax ),
• la période maximale autorisée pour les tâches (TiMax ),
• le ppcm maximum autorisé pour l'ensemble des périodes des tâches (MaxLCM ),
• les bornes minimale et maximale autorisées pour la charge processeur de la conguration
(Umin & Umax ),
• l'algorithme d'ordonnancement en ligne qui ordonnance la conguration de tâches gé-
nérée (DM, EDF ),
• le type de gigue désiré (Mean_RJ_S 1, Max_RJ_E, etc.),
• le seuil de gigue minimum souhaité (MinJitter),
• le nombre de tâches dans la conguration (TaskNumberSpeciedWithAtLeastTheMin-
Jitter) ayant une gigue supérieure ou égale au seuil de gigue minimum (MinJitter).
Ci-dessous sont décrits les paramètres de sorties de la procédure de génération. Nous
avons :
• la conguration de tâches générée (Cong),
• le ppcm des périodes des tâches de la conguration générée (LCM_of_Task_Periods),
1Pour 'Mean Regularity Jitter between 2 successive Start dates', etc. Cf. section 1.4.1, pages 34
4.1 Présentation de l'outil de simulations 123
• l'ensemble des gigues de chaque tâche (TaskJitters), le calcul des gigues étant basé sur
le type de gigue saisi en entrée,
• le nombre eectif de tâches dans la conguration (TaskNumberObtainedWithAtLeast-
ThisMinJitter), ayant au moins pour gigue, la gigue minimum donnée par le paramètre
d'entrée MinJitter.
4.1.1.2 Critères favorables à l'obtention de gigue - Observations
Souhaitant préciser sous quelles conditions la gigue est susceptible d'apparaître, nous
avons procédé à des tirages aléatoires de congurations. En plaçant la procédure de généra-
tion dans une boucle, nous avons déterminé la durée moyenne de génération nécessaire pour
obtenir une conguration de tâches respectant diérents critères de gigue (5%, 10%, 15%et 20%), et respectant diérents critères de charge processeur. Les paramètres d'entrées de
la procédure de génération sont xés comme suit dans ce paragraphe : le nombre minimum
de tâches devant au moins avoir la gigue minimum est de 3, le nombre de tâches total estde 8, le ppcm maximum des périodes des tâches a une valeur de 1500 et les paramètres
CiMax et TiMax sont respectivement 10 et 200. L'algorithme d'ordonnancement choisi est
d'abord DM et nous utilisons la gigue de régularité moyenne, basée sur les dates de début
d'exécution des tâches régulières.
Partant de l'intervalle [95%, 100%] pour la charge processeur souhaitée, nous avons
progressivement décrémenté cet intervalle par pas de 5%. Nous ne sommes cependant pas
allés jusqu'à l'intervalle [0%, 5%], puisqu'en eet, au fur et à mesure que la charge processeur
diminue, le temps de génération des congurations augmente fortement. Pour obtenir les 3tâches avec la gigue voulue, il est ainsi dicile d'atteindre l'intervalle [0%, 5%] en un temps
acceptable (la diminution de la charge entraîne moins d'interférences entre les tâches).
Nous avons reporté dans la gure 4.1 les résultats de ces simulations. A chaque point
du graphique est associée une durée moyenne eectuée sur un échantillon de 50 générations
de congurations. Chaque courbe représente l'évolution pour une gigue donnée de la durée
moyenne de génération en fonction de la charge processeur. Remarquons que pour une
charge processeur très forte [95%, 100%], la durée de génération est plus grande que pour unecharge processeur immédiatement inférieure. En eet, pour une très forte charge processeur,
le critère d'ordonnançabilité est plus dicile à obtenir, écartant de facto un certain nombre
de congurations. Nous observons ensuite une hausse exponentielle de cette durée. Ainsi,
plus la charge processeur est faible, plus la durée de génération s'allonge, et donc plus il
devient dicile de trouver des congurations de tâches avec gigue, d'autant plus dicile si la
gigue souhaitée est importante. Cette observation est intéressante dans la mesure où dans un
contexte industriel les applications temps réel ont généralement une charge processeur faible
et sont donc généralement peu aectées par le phénomène de gigue. En outre parallèlement
à cette charge processeur faible, on utilise souvent le principe du suréchantillonnage, qui
minimise l'inuence éventuelle de la gigue et qui mobilise dans une plus grande proportion
la ressource processeur.
Pour résumer, il apparaît que la non maîtrise de la gigue entraîne clairement une sous
exploitation du ou des processeur(s). De plus, l'outil de simulation permet de conrmer
qu'une charge processeur forte est propice à l'apparition de la gigue. Cet outil de simulation
ne permet pas cependant d'être exhaustif sur la liste des critères favorables à l'obtention de
124 Expérimentations Numériques
Fig. 4.1: Durée moyenne de génération d'une conguration de tâches en fonction
de la charge processeur requise et en fonction de la gigue minimum souhaitée -
PpcmMax = 1500 - 3 tâches régulières sur 8 tâches au total - DM .
gigue. Remarquons alors que d'un point de vue arithmétique, les tâches, dont les périodes
sont multiples les unes des autres, ont des dates d'activations communes et peuvent induire
des perturbations dans leur régularité d'exécution. D'ailleurs, les résultats des générations
conrment cette remarque puisque les tâches avec gigue ont généralement des périodes qui
sont multiples de la période minimum prise parmi les périodes des tâches régulières.
Nous avons réalisé la même simulation mais en utilisant l'algorithme d'ordonnancement
EDF . On retrouve alors les mêmes observations (cf. gure 4.2) à ceci près qu'il faut remar-
quer que pour une charge processeur décroissante (et élevée), il y a toujours augmentation
de la durée de génération. Cette observation s'explique par le critère d'ordonnançabilité sous
EDF qui est satisfait : U ≤ 1, tâches indépendantes à départ simultané et à échéance sur
requête. Ainsi dans ce contexte particulier, seul le critère de gigue apporte une contrainte à
la génération de tâches. Les valeurs des durées de générations sont cependant plus élevées
avec EDF car en vue de préciser les gigues, nous devons construire la séquence d'exécution.
Cette construction se basant sur des paramètres dynamiques, plus lourds à manipuler que
dans le cas DM , on observe alors une plus grande durée de génération.
4.1.1.3 Analyse de la gigue obtenue
Dans ce paragraphe, nous décrivons la répartition de la gigue obtenue après la généra-
tion. Nous réalisons une génération de 8 tâches dont 2 sont régulières suivant les critères de
génération utilisés dans le paragraphe précédent. La gigue demandée est de 20% et l'algo-
4.1 Présentation de l'outil de simulations 125
Fig. 4.2: Durée moyenne de génération d'une conguration de tâches en fonction
de la charge processeur requise et en fonction de la gigue minimum souhaitée -
PpcmMax = 1500 - 3 tâches régulières sur 8 tâches au total - EDF .
rithme d'ordonnancement choisi est DM . Le résultat de cette génération est reporté dans
la gure 4.3 : pour chaque intervalle de charge processeur, 1000 tirages sont réalisés, et on
reporte en ordonnée la fréquence d'apparition des congurations obtenues en fonction de
leur gigue réelle. Pour cette génération, les résultats sont sensiblement stables si on aug-
mente le nombre de tirages, qu'on xe alors à 1000. En outre, pour une génération avec
EDF ou en considérant un nombre de tâches plus important, on retrouve le même ordre
de répartition des gigues.
On observe deux caractéristiques essentielles sur ce graphe. La première concerne l'évo-
lution de la répartition de la gigue en fonction de la charge processeur. Plus cette charge
diminue, et plus les gigues obtenues sont proches du critère demandé 20% (cf. gure 4.3,
charge processeur 70 − 75%). A contrario, les gigues obtenues pour une charge processeur
élevée sont réparties d'une manière relativement neutre sur l'intervalle [20% − 35%] (cf.gure 4.3, charge processeur 95−100%). La deuxième caractéristique est en rapport avec le
test de faisabilité que nous allons mettre en place dans la suite. Les gigues observées et non
négligeables sont situées dans un intervalle [20% − 30%]. Considérant par la suite que les
tâches régulières seront générées sur une base de 20% de gigue, nous considérerons en fait
des gigues allant jusqu'à 30%. C'est le seuil maximum que nous prendrons en considération
pour notre critère d'encadrement de la gigue lors de ces simulations.
126 Expérimentations Numériques
Fig. 4.3: Répartition des congurations de tâches obtenues en fonction du maxi-
mum des gigues des tâches régulières et en fonction de la charge processeur -
Gigue demandée ≥ 20% - PpcmMax = 1500 - 2 tâches régulières sur 8 tâches
au total - DM (pour chaque courbe, 1000 congurations ont été générées).
4.1.2 Module de traitement de la gigue
La mise en ÷uvre de ce module se fonde sur l'algorithme présenté dans le paragraphe
3.3.5. Il a été implémenté pour les algorithmes d'ordonnancement DM et EDF . En outre,
conformément au paragraphe 3.3.3, étape 3, nous nous basons pour la modication des
délais critiques sur une dénition du type Di = Wi. Dans ce module de traitement de la
gigue, on retrouve alors les quatre étapes décrites dans la section 3.3, avec cependant des
étapes intermédiaires nécessaires à l'implémentation :
• une procédure de désynchronisation des dates d'activation des tâches régulières permet
de récupérer un ensemble de vecteurs solutions en ri,1 dont les dimensions correspondent
au nombre de tâches régulières ;
• une deuxième procédure écarte les vecteurs de cet ensemble qui ne respectent pas les
contraintes de précédence entre les tâches régulières ;
• une troisième procédure réalise la complétion des vecteurs solutions, c'est-à-dire qu'on
complète chaque vecteur solution avec les dates initiales de première activation des tâches
4.1 Présentation de l'outil de simulations 127
non régulières. La dimension de ces vecteurs solutions correspond alors au nombre total
de tâches dans la conguration ;
• avec la quatrième procédure, on modie dans chacun des vecteurs solutions les dates
de première activation des tâches non régulières, de sorte que les contraintes de précé-
dence entre une tâche régulière et une tâche non régulière soient respectées ; dans cette
modication, on prend soin de s'éloigner le moins possible de la conguration de départ
(les nouveaux ri,1 seront les plus proches possibles des ri,1 initiaux) ;
• dans la cinquième étape, on eectue le même traitement mais pour des précédences
entre deux tâches non régulières ; à noter que le traitement d'une précédence impliquant
une tâche non régulière suivie d'une tâche régulière ne sera pas prise en compte si on
souhaite annuler la gigue (Wi = Ci) conformément au paragraphe 3.2.3.2, étape 3 ;
• en se basant sur les largeurs souhaitées pour lesWi, la sixième procédure dénit les délais
critiques des tâches régulières, formant ainsi un vecteur solution en Di, de dimension
correspondant au nombre de tâches régulières ;
• la septième procédure complète le vecteur solution en Di en respectant les règles de
précédences entre une tâche régulière et une tâche non régulière ; là encore, on prend
soin de s'éloigner le moins possible de la conguration de départ (les nouveaux Di seront
le plus proche possible des Di initiaux),
• la huitième procédure vérie et adapte le cas échéant, les délais critiques des tâches non
régulières an de respecter les précédences entre deux tâches non régulières,
• dans la dernière procédure, on vérie quelles sont les combinaisons (vecteurs en ri,1 etle vecteur en Di) qui restent ordonnançables, et qui respectent alors par construction les
critères de gigues demandés.
Dans la procédure générale de traitement de la gigue qui utilise l'ensemble de ces 9procédures, les paramètres d'entrées considérés sont : la conguration de tâche initiale avec
la distinction entre tâches régulières et non régulières, la matrice de représentation des
précédences entre les tâches, et les paramètres Wi souhaités pour les tâches régulières. En
sortie, on récupère, lorsqu'il y a des solutions, un ensemble de congurations dont la gigue
moyenne de régularité des tâches régulières est encadrée suivant le critère présenté dans le
paragraphe 3.3.2. An d'illustrer très succinctement par un exemple, les conséquences de
cette procédure, nous avons généré dans un premier temps un ensemble de congurations
de tâches ayant des gigues d'environ 25% pour les tâches régulières. Puis dans un second
temps, nous avons utilisé la procédure de traitement de la gigue et constaté la diminution
de celle-ci. Sur la gure 4.4, pour une charge processeur donnée, nous avons ainsi représenté
par des croix les moyennes des gigues de 5 congurations de tâches générées aléatoirement.
On distingue pour chaque tranche de charge processeur 5 croix réparties autour des 25%,
et qui représentent les moyennes des gigues de régularité juste après la génération, et on
distingue par ailleurs 5 autres croix qui sont au dessous des 5% et qui représentent ces mêmes
moyennes une fois la procédure de traitement de la gigue appliquée. Notez également que
nous avons reporté la moyenne de répartition des deux groupes de croix. La diminution de
la gigue est ici très appréciable et conrme que la technique de traitement de la gigue est
fonctionnelle pour diérentes charges processeur.
Avec l'aide de ces outils, abordons maintenant la question de la faisabilité de cette
technique pour des contextes d'ordonnancement divers.
128 Expérimentations Numériques
4.2 Tests d'ecacité de la méthode
Les deux modules présentés dans la section précédente vont nous permettre de faire
des simulations numériques et de préciser l'intérêt de notre technique pour divers contextes
d'utilisation. Seul le contexte des tâches indépendantes est exploré. En eet, d'une part
il est dicile de créer de manière aléatoire une matrice de représentation des précédences
qui soit cohérente, et d'autre part, dans le système de tâches avec précédence qui pourrait
être généré, on ne peut pas caractériser simplement le niveau de contrainte du système.
Ainsi, ajouter dans la simulation des contraintes de précédence ne fera qu'apporter des
observations sur un système contraint dont le niveau est dicilement appréciable.
Le principe d'évaluation de la technique se décrit comme suit : on procède d'abord à une
génération aléatoire de 100 congurations de tâches, comportant des tâches ayant de la gigue
(au moins 20%) et qu'on souhaite rendre plus régulières en terme d'exécution. On utilise
ensuite la procédure de traitement de la gigue sur chacune de ces 100 congurations, et on
comptabilise sur ces 100 essais, le nombre d'essais qui ont nalement conduit au succès de
la technique. Dans un souci de s'approcher d'un échantillon statistique représentatif, nous
avons réalisé une dizaine de tests, conduisant à la détermination du pourcentage moyen de
réussite basée sur 1000 tirages.
Dans cette évaluation, seul le choix du paramètre W est délicat. En eet il est plus
intéressant d'avoir un critère de gigue plutôt qu'un critère lié à la largeur des fenêtres
d'exécution. Pour cela, nous avons relié le paramètre W à la gigue maximum autorisée
Fig. 4.4: Réduction de la gigue des tâches régulières pour des congurations
générées aléatoirement. Après utilisation du module de traitement de la gigue,
les gigues sont inférieures à 5% - DM .
4.2 Tests d'ecacité de la méthode 129
pour chacune des tâches régulières. Soit Jmax une telle gigue exprimée en %, supposons que
la génération et le traitement de la gigue s'eectuent sur nR tâches régulières. Dénissons
pour chaque tâche régulière une largeur de fenêtre d'exécutionW par l'expression suivante :
W = Jmaxmin(Ti|1 ≤ i ≤ nR)
100. (4.1)
Dans cette hypothèse, et dans une situation du pire cas (cf. gure 1.14-b, de la page 42) ,
déterminons alors le terme2 jsi,k. Pour les deux cas, on a :
jsi,k= |Ti +Wi − Ci − Ti| ou jsi,k = |Ti −Wi + Ci − Ti|
Ce qui implique nécessairement que jsi,k≤ |Wi| car 0 ≤ Ci ≤Wi (et ce pour tout k ∈ N).
Or la gigue maximum basée sur les dénitions du paragraphe 1.4.1 est telle que :
Jmax(τi) =100×max(jsi,k
|k ∈ N)
Ti
donc
Jmax(τi) ≤ 100 ×Wi
Ti
En identiant Wi avec le paramètre W ci-dessus (équation 4.1), il vient
Jmax(τi) ≤ Jmaxmin(Ti|1 ≤ i ≤ nR)
T i≤ Jmax
Chaque tâche régulière possède alors une gigue inférieure à Jmax, ce qui nous rapproche d'un
critère de gigue plus intéressant. En eet, nous allons pouvoir comparer des congurations
de tâches, à fortes ou à faibles régularités d'exécution, c'est-à-dire à faible ou à forte gigue.
4.2.1 Inuence de la charge processeur et de la gigue
Procédons maintenant à la mise en ÷uvre de cette simulation numérique en eectuant
notre première évaluation avec des congurations comportant 2 tâches régulières sur 8tâches au total. Les paramètres de génération sont ceux utilisés dans la section précédente,
en particulier CiMax = 10 permet pour le casWi = Ci (annulation de la gigue) d'éviter des
temps de résolution du problème de désynchronisation trop importants. Les résultats ont
été reportés sur la gure 4.5 où apparaissent le pourcentage de réussite de notre technique
en fonction de la charge processeur souhaitée et en fonction de la gigue maximum autorisée
sur les tâches régulières. Remarquez que nous n'explorons pas toute l'échelle de charge
processeur, puisqu'en eet, pour 100 congurations, lorsque la demande en gigue est forte
alors que la charge processeur est faible, nous assistons à une hausse très sensible des temps
de génération aléatoire des congurations : les éventuelles perturbations entre les tâches se
font en eet plus rares. Par exemple, pour une charge de 45%−50%, la durée de génération
est supérieure à une heure de calcul pour 100 congurations (pentium III à 450 MHz).
2Cf. dénition en section 1.4.1, pages 34
130 Expérimentations Numériques
Pour un rapport diérent, nombre de tâches régulières sur nombre total de tâches dans
la conguration, on retrouve les mêmes tendances (cf. paragraphe suivant). Ainsi observe-
t-on une ecacité plus grande de la technique lorsque la charge processeur diminue, et
cette ecacité est d'autant plus prononcée que la gigue maximum autorisée est plus faible.
L'évolution de l'ecacité de la technique en fonction de la charge processeur est assez in-
tuitive puisqu'à charge processeur élevée, la probabilité d'obtenir des fenêtres d'exécution
d'une largeur donnée est plus faible que dans le cas d'une charge processeur plus petite où
les perturbations entre les tâches sont moins présentes. En revanche, l'évolution de l'e-
cacité de la technique en fonction de la gigue maximum autorisée est moins intuitive. En
eet, dans la technique de traitement de la gigue, il y a deux eets qui sont particulière-
ment antagonistes. Le premier eet concerne le paramètre W . Avec son introduction, on
souhaite réduire les contraintes sur les tâches régulières en leur permettant de se faire pré-
empter dans une certaine mesure par des tâches non régulières. Cependant, le fait même
d'augmenter la valeur de ce paramètre W diminue d'autant le nombre de solutions pour le
problème de désynchronisation entre les tâches régulières, et donc diminue les chances de
réussite de la technique. En eet, lorsque W augmente, le nombre d'équations du problème
de désynchronisation augmente (cf. paragraphe 3.1.1.2), et diminue ainsi la dimension de
l'espace solution des vecteurs ri,1i. Entre ces deux eets, l'augmentation des largeurs Wpour favoriser les préemptions, et l'augmentation du nombre d'équations au problème de
désynchronisation, la tendance se traduit par une diminution du pourcentage de réussite
de la technique : plus les gigues maximums sur les congurations nales sont grandes, et
moins la technique de traitement de celle-ci est performante.
D'un point de vue quantitatif, remarquons que pour cette simulation, le pourcentage de
réussite est toujours au dessus de 40% et qu'il augmente progressivement pour atteindre des
Fig. 4.5: Pourcentage de réussite de la technique de traitement de la gigue en
fonction de la charge processeur requise et en fonction de la gigue maximum
autorisée sur les tâches régulières. 2 tâches régulières sur 8 tâches au total -
DM .
4.2 Tests d'ecacité de la méthode 131
pourcentages de réussite élevés pour des charges processeur inférieures à 80%. A noter que
pour une gigue supérieure à 50%, le pourcentage de réussite s'eondre et tombe à 0% car la
largeur réservée en W devient trop importante pour faire coexister les fenêtres d'exécution
des 2 tâches régulières.
Explicitons en détail cette dernière observation. Lors de la phase de génération, la né-
cessité d'obtenir des congurations avec gigue, donne des tâches régulières dont les périodes
sont des multiples du minimum des pgcd des périodes des tâches régulières prises deux à
deux, provoquant ainsi des dates d'activation communes, et donc de la gigue. Au regard
des résultats des générations aléatoires, ce minimum des pgcd est en général le minimum
des périodes des tâches régulières, minimum sur lequel nous nous sommes également basés
pour le choix de W dans la mise en ÷uvre de notre technique. Désignons ce minimum par
Tmin. Pour 2 tâches régulières, choisir une gigue maximum de 50%, revient à choisir un
paramètre W de Tmin/2. Or Tmin représente également la largeur minimum dans laquelle
on peut insérer les fenêtres d'exécution des tâches régulières. Autorisant les deux tâches
régulières à avoir de la gigue dans les mêmes proportions, le chevauchement des intervalles
n'interviendra que pour un choix W supérieure à Tmin/2, et dans ce cas, le problème de
désynchronisation échoue (cf. gure 3.6, page 78). Dans la section suivante, on retrouve
cette observation avec la simulation sur 3 tâches : le paramètre W critique est en eet
théoriquement Tmin/3 et la simulation le conrme : au delà de 33% de gigue, il n'y a plus
de solution.
4.2.2 Inuence du nombre de tâches régulières
Dans cette section, nous changeons le rapport nombre de tâches régulières sur nombre
total de tâches. Le résultat est reporté sur le graphe de la gure 4.6, sur lequel nous observons
les mêmes évolutions que pour le paragraphe précédent : augmentation du pourcentage de
réussite au fur et à mesure que la charge processeur décroît, et niveau de réussite d'autant
plus faible que la gigue autorisée est élevée. D'un point de vue quantitatif, observons que
les pourcentages de réussite sont plus faibles que dans le cas précédent. An de mettre en
évidence cette observation, nous avons reporté dans les graphes de la gure 4.7, l'évolution
du pourcentage de réussite pour trois charges processeur diérentes, exprimée en fonction
du nombre de tâches régulières sur le nombre de tâches non régulières : la diminution
est nette. En augmentant en eet la proportion de tâches régulières, nous augmentons les
contraintes sur notre système, ce qui diminue les chances de solutions. Néanmoins, avec la
hausse du pourcentage de réussite lorsque la charge processeur augmente, nous pouvons
relever des pourcentages de réussite intéressants (supérieurs à 70%).
4.2.3 Inuence de l'algorithme d'ordonnancement utilisé
Dans ce paragraphe, nous avons utilisé l'algorithme d'ordonnancement EDF pour les
simulations. Nous avons en outre repris les caractéristiques de génération retenues dans les
paragraphes précédents. Les résultats de ces simulations sont reportées dans la gure 4.8.
Dans la mise en ÷uvre de ces simulations, rappelons que seul le cas des tâches indé-
pendantes est considéré. Ainsi les étapes de la technique de traitement de la gigue gérant
les précédences n'interviennent pas dans ces simulations. L'application de la technique soit
132 Expérimentations Numériques
Fig. 4.6: Pourcentage de réussite de la technique de traitement de la gigue en
fonction de la charge processeur requise et en fonction de la gigue maximum
autorisée sur les tâches régulières. 3 tâches régulières sur 8 tâches au total -
DM .
Fig. 4.7: Pourcentage de réussite de la technique de traitement de la gigue en
fonction du nombre de tâches régulières - DM .
dans le contexte EDF , soit dans le contexte DM , ne se diérencie alors qu'au niveau
du critère d'ordonnançabilité qui est par ailleurs plus avantageux pour EDF . Au nal,
on retrouve cette remarque dans l'observation des deux graphes (cf. gures 4.5 et 4.8) :
le pourcentage de réussite pour EDF est plus élevé que pour DM . Une synthèse de ces
deux graphes est proposée dans les graphes de la gure 4.9 : le contexte EDF conduit à
un résultat meilleur que pour le contexte DM . Rappelons en revanche qu'en considérant
4.2 Tests d'ecacité de la méthode 133
Fig. 4.8: Pourcentage de réussite de la technique de traitement de la gigue en
fonction de la charge processeur requise et en fonction de la gigue maximum
autorisée sur les tâches régulières. 2 tâches régulières sur 8 tâches au total -
EDF .
Fig. 4.9: Pourcentage de réussite de la technique de traitement de la gigue en
fonction de l'algorithme d'ordonnancement utilisé.
les inter-dépendances entre les tâches, la technique de traitement de la gigue devient plus
délicate à mettre en ÷uvre dans le contexte EDF , comparé au contexte DM ou comparé
au contexte des ordonnancements basés sur les priorités xes.
Nous avons par ailleurs conduit la même simulation en augmentant le rapport nombre
de tâches régulières sur nombre total de tâches, et nous avons obtenu en EDF les mêmes
conclusions qu'en DM : le pourcentage de réussite de la technique diminue sensiblement.
134 Expérimentations Numériques
4.3 Conclusion
Dans ce chapitre nous avons évalué, au travers de simulations numériques, l'ecacité de
la technique pour diérents contextes d'ordonnancement, mais dans l'hypothèse de tâches
indépendantes. L'ajout de contrainte de précédence dans ces simulations n'aurait en eet
conduit qu'à des conclusions sur des systèmes déjà contraints dont le niveau est dicilement
quantiable.
Dans cette hypothèse, nous avons identié certains contextes favorables à l'application
de cette technique. Les simulations ont montré que celle-ci était plus ecace pour des
charges processeur qui ne sont pas extrêmes (≤ 80%), et qu'il était préférable d'avoir
un rapport nombre de tâches régulières sur nombre total de tâches faible. Par ailleurs,
cette technique s'est révélé d'autant plus ecace que la gigue maximum autorisée était
faible. Enn, écartant dans ces simulations la gestion des précédences, nous avons observé
un meilleur pourcentage de réussite de la technique dans le contexte EDF comparé au
contexte DM . Ce dernier point est cependant à nuancer, puisque dans le cas de la gestion
des précédences, la technique est plus délicate à mettre en place dans le contexte EDF (cf.
sections 3.2.3.2 & 3.3.3).
Les outils destinés à la simulation ont également permis de conrmer qu'une charge pro-
cesseur forte conduisait à l'apparition de gigue sur les tâches, et que la gigue n'apparaissait
qu'exceptionnellement dans le cas de congurations à charge processeur faible (inférieure à
50%).
Au regard des résultats de ces simulations numériques, il est intéressant de souligner
que l'outil mis en ÷uvre, conduit à des congurations de tâches qui sont généralement
réceptives à la technique de traitement de la gigue. En eet, dans la phase de génération,
la nécessité d'obtenir des congurations de tâches avec gigue nous conduit généralement à
des tâches régulières dont les périodes sont multiples entre elles. Dans ce cas et nous l'avons
évoqué dans le paragraphe 3.1.1.33, des conditions favorables à l'obtention de solutions pour
le problème de désynchronisation sont réunies. Les conditions qui provoquent l'apparition
de gigue (périodes des tâches multiples entre elles, départs simultanés, etc.) sont donc
compatibles avec le principe de désynchronisation des tâches et expliquent donc en partie
le taux de réussite élevé de la technique de traitement de la gigue de tâches indépendantes.
3Il fallait par exemple que p = Ti ∧ Tj soit le plus grand possible (cf. gure 3.6, page 78), donc que les
périodes des tâches soient multiples entre elles.
Chapitre 5
Application à l'Expérience du Pendule
Inversé
Dans ce chapitre, nous allons étudier l'application de notre technique de traitement de
la gigue à une application temps réel test. Cette application temps réel est une application
de contrôle d'un pendule en position inversée. Les diérentes étapes de spécication, de
conception, et de validation de l'application seront abordées dans ce chapitre, avec un accent
particulier sur la phase d'ordonnancement. L'implémentation est réalisée sur le système
d'exploitation temps réel VxWorksTM de la société WindRiverTM , et permet d'aborder le
problème de la mise en place d'une technique d'ordonnancement, notamment au niveau
de la durée du quantum de temps de l'ordonnanceur (la granularité), qui est souvent très
grande comparée à la durée du quantum de temps des processeurs récents.
5.1 Introduction
La plate-forme de test utilisée pour mettre en pratique la technique de traitement de
la gigue, est basée sur l'expérience du pendule inversée. Celle-ci consiste à piloter un cha-
riot pouvant se mouvoir sur un rail, de sorte qu'une tige métallique - le pendule -, montée
en rotation libre sur le chariot, puisse être maintenue en position verticale inversée (cf.
gure 5.1). Cette position étant instable, une réaction trop tardive dans la correction du
mouvement du chariot provoque la chute du pendule, avec l'impossibilité de corriger sa
trajectoire (moteur à puissance nie, inertie, etc.). Les principes généraux du traitement du
signal, ainsi que la nécessité d'obtenir un système stable au sens "automatique" du terme,
imposent en outre une contrainte de régularité d'exécution pour les processus d'interfaçage
entre le procédé et le système numérique. Ces diérentes contraintes de temps (échéances et
régularité d'exécution) font de ce procédé un support d'étude intéressant pour notre tech-
nique de traitement de la gigue et plus généralement pour des techniques d'ordonnancement
temps réel.
Plusieurs phases de fonctionnement du pendule peuvent par ailleurs être distinguées :
une phase d'initialisation, pendant laquelle le chariot est amené au centre du rail et pendant
laquelle on attend que le pendule se soit immobilisé en position verticale descendante ; une
phase d'oscillations du chariot, au cours de laquelle, par des mouvements de va-et-vient du
136 Application à l'Expérience du Pendule Inversé
chariot, on amène le pendule dans une position verticale ascendante ; et enn, une phase
de maintien du pendule en position inversée. Dans un souci de simplication, seule cette
dernière phase est étudiée dans ce mémoire. En outre, pour maintenir cette position, nous
utilisons la notion de boucle d'asservissement, en reliant le mouvement à impulser au chariot
avec l'angle que fait le pendule avec la verticale (loi de commande).
Description matérielle.
Le mouvement du chariot est obtenu par un moteur à courant continu qui constitue le
seul actionneur de cette plate-forme. Les capteurs sont, quant à eux, au nombre de 4. Uncodeur incrémental situé sur l'axe de rotation libre du pendule détermine l'angle θ que faitce dernier avec la verticale. Deux capteurs de n de course situés de part et d'autre du rail
indiquent si le chariot est en butée. Enn, un potentiomètre rotatif permet de donner la
position du chariot sur le rail (cf. gure 5.2).
Description logicielle.
Le système d'exploitation temps réel utilisé est VxWorksTM . Ce système est conforme
à la norme POSIX, mais toutes les fonctions implémentées selon POSIX [Gallmeister 95]
sont doublées par des fonctions propriétaires annoncées par WindRiverTM comme étant
plus ecaces et plus souples d'utilisation. Dans ce projet, nous avons nalement choisi
Fig. 5.1: Diérentes photos du banc d'essai avec le pendule en "position inver-
sée" sur son chariot.
5.2 Modélisation du banc 137
d'utiliser les primitivesWindRiverTM an d'accéder à certaines fonctionnalités qui facilitent
la validation (par exemple, comparé aux sémaphores POSIX, les sémaphores WindRiverTM
gèrent l'héritage de priorité). Associé à ce système d'exploitation, WindRiverTM fournit
aussi un Environnement de Développement Intégré (EDI), appelé TornadoTM , qui bénécie
de nombreuses fonctions de débogage, spéciques pour certaines, aux applications temps
réel. An de pouvoir les utiliser pleinement, nous avons fait le choix d'une architecture de
développement de type client-serveur1.
Après une phase d'initialisation, l'ordinateur cible (ou client) télécharge le noyau temps
réel complet et le code de l'application de contrôle du pendule (cf. gure 5.3). Une fois
lancée, les tâches de l'application dialoguent avec le procédé par des appels aux routines du
pilote développé pour la carte d'entrée/sortie. Cette carte constitue alors l'interface entre
l'ordinateur et la partie électronique de la plate-forme. Dans la phase de développement
et avec ce type d'architecture, TornadoTM ore un certain nombre d'avantages : on a par
exemple la possibilité de charger en ligne de nouvelles tâches qu'on souhaiterait tester, on a
aussi la possibilité d'avoir le Shell du noyau temps réel sur la machine hôte (clavier azerty,
copier coller, etc...), on peut encore par exemple construire le chronogramme des tâches,
facilitant alors la phase de validation temporelle.
5.2 Modélisation du banc
Dans cette section, nous décrivons d'un point de vue automatique notre système, en
le modélisant sous forme de diagramme fonctionnel, et en utilisant la notion de boucle
d'asservissement. Dans cette boucle d'asservissement, nous faisons intervenir un correcteur
de type PID - correction de type proportionnelle, intégrale et dérivée. Ce correcteur est en
fait implémenté sur un ordinateur de type PC et donne à chaque instant la loi de commande
à respecter pour maintenir le pendule en position inversée.
1On pourra néanmoins à terme, rendre l'application temps réel totalement indépendante de Tornado,
et se diriger vers une application de type embarqué.
Fig. 5.2: Description schématique du banc.
138 Application à l'Expérience du Pendule Inversé
5.2.1 Description de la boucle d'asservissement
Débutons par une description informelle des processus mis en jeux. Dans les baies d'ex-
tension de l'ordinateur, nous disposons d'une carte d'entrée sortie analogique/numérique
(Lab-PC 1200 de National InstrumentTM), qui joue l'interface entre la partie procédé (le
banc du pendule), et la partie numérique (l'ordinateur). L'enchaînement des communica-
tions se fait alors comme suit :
-1- la tension u de sortie (analogique) de cette carte est appliquée à l'entrée de la partieélectronique de commande du banc,
-2- via cette électronique (et celle de puissance), cette tension est transmise au moteur à
courant continue (±24V),
-3- le moteur entraîne ensuite via un système de courroie et de poulie, le chariot,
-4- ce mouvement provoque alors la rotation du pendule autour de son axe.
-5- Un codeur incrémental à 2000 positions (précision de 0,18 radian) restitue ensuite, via
l'électronique du banc, la valeur de l'angle θ, qui est alors transmise à l'une des entrées
numériques de la carte d'acquisition. La nouvelle position du chariot peut être également
transmise via le potentiomètre vers la carte d'acquisition.
-6- Cette valeur de l'angle, la dynamique de son évolution et éventuellement la position
du chariot ainsi que sa vitesse, servent enn à élaborer une tension particulière u en
sortie analogique de la carte d'acquisition, et ce, selon une loi de commande qu'il faut
établir.
Cette dernière étape termine cette description, puisqu'elle retourne à l'étape -1-.
Dans la littérature liée au domaine de l'automatique, il existe de nombreux travaux qui se
sont intéressés à l'asservissement d'un pendule inversé. Il en existe même pour l'expérience
Fig. 5.3: Initialisation et architecture du système temps-réel.
5.2 Modélisation du banc 139
du double pendule inversé qui place, en rotation libre, un deuxième pendule au dessus
du premier, avec un capteur d'angle, et qui consiste à maintenir les deux pendules en
position verticale inversée. Dans le cadre de la commande d'un simple pendule inversé,
nous pouvons citer les travaux de Jacob [Jacob 95] basés sur la théorie des moments, ou
les travaux de Wang basés sur la logique oue [Wang 96] ou bien encore l'application des
réseaux neuronaux avec les auteurs de [Anderson 89], etc..
Dans notre approche et dans un souci de simplication, nous avons fait le choix d'une
modélisation du système par fonction de transfert, avec l'introduction au niveau de l'ap-
plicatif d'un correcteur de type PID, correcteur qui envoie une tension u vers le moteur,
en fonction de l'angle θ que fait le pendule avec la verticale. Une correction plus ne du
pendule consisterait à non seulement prendre en considération l'angle θ, mais aussi la po-
sition et la vitesse du chariot, données par le potentiomètre. Pour gagner du temps dans
la mise en ÷uvre de la technique de traitement de la gigue, nous n'avons eectué qu'un
asservissement sur l'angle, en ne prenant pas en compte la position et la vitesse du chariot.
Le principe reste néanmoins le même du point de vue temps réel, et lorsque le projet du
point de vue automatique sera plus abouti, nous pourrons modier la tâche temps réel qui
est dédiée au calcul de la loi de commande.
5.2.2 Détermination de la loi de commande
Rappelons que la fonction de transfert d'un système est une représentation mathéma-
tique caractérisant dans le domaine fréquentiel, la réponse du système à un signal de type
impulsionnel. Cette réponse, encore appelée réponse impulsionnelle, représente la "carte
d'identité" du système : en ayant connaissance en eet de la réponse impulsionnelle d'un
système, on peut déterminer le signal de sortie du système pour tout signal d'entrée quel-
conque. Cette réponse est généralement donnée dans l'espace temporel, et par une transfor-
mée de Fourier ou de Laplace, on obtient la notion de fonction de transfert. Les fonctions
de transfert que nous présentons par la suite sont exprimées dans l'espace de Laplace en
fonction du paramètre de Laplace p qui est à relier avec la fréquence f par la relation
p = jω = j2πf .
Le schéma fonctionnel retenu pour modéliser la plate-forme est celui reporté dans la
gure 5.4 où HS représente la fonction de transfert du système prenant en entrée la tension
de commande du moteur et en sortie l'angle θ que fait le pendule avec la verticale. La
régulation du procédé à l'aide du correcteur PID est une approche classique en automatique.
En fonction de la diérence entre la consigne θc et de l'angle réel θ, le correcteur va réagir
de manière proportionnelle, intégrale et dérivée.
Dans ce diagramme fonctionnel, deux parties sont à distinguer, la partie calculateur (en
pointillé), gérée dans un premier temps sous LabviewTM , et la partie analogique, représen-
tée par le procédé. Le module ADC (convertisseur analogique numérique) fait intervenir
un échantillonneur qui acquiert périodiquement une variable continue, en l'occurrence ici,
l'angle θ. De même, le module DAC (convertisseur numérique analogique) fait intervenir
un bloqueur d'ordre zéro dont le rôle est de maintenir la valeur de sortie constante entre
deux instants d'échantillonnage. Ce bloqueur d'ordre zéro a généralement une inuence sur
le comportement dynamique du système, et on peut modéliser son action par la fonction
140 Application à l'Expérience du Pendule Inversé
de transfert suivante :
B(p) =1− exp(−Tep)
p(5.1)
où Te représente la période de restitution du signal [Guyenot 89]. Pour notre approche,
son inuence sera néanmoins négligée : en eet, celle-ci est d'autant plus faible que Te estfaible devant les constantes de temps du processus contrôlé, hypothèse que nous formulons
dans cette étude pour une première estimation. En ce qui concerne l'échantillonneur, la
conguration est diérente : nous utilisons en eet un codeur incrémental qui restitue
directement une valeur numérique à la carte d'entrée/sortie du PC : il n'y a donc pas
d'inuence sur le comportement dynamique, du moins dans la gamme de fréquence dans
laquelle nous évoluons où nous supposons que le codeur ne rate jamais de position. En
résumé, nous nous plaçons donc dans l'approximation d'une commande continue [Borne 93].
Etude théorique
Dans le cadre des hypothèses ci-dessus, et en rappelant par ailleurs que nous ne souhai-
tons asservir le pendule que dans sa phase de régime permanent (maintien du pendule en
position verticale inversée), la fonction de transfert HS peut alors s'écrire sous la forme [Ja-
cob 95] :
HM(p) =Kαp
2
−1 + 2mpω0
+ p2
ω02
(5.2)
où Kα, m et ω0 sont des paramètres que nous pouvons identier en étudiant la réponse de
l'angle θ à des échelons de déplacement. Le critère algébrique de Routh-Hurwitz [Rivoire 96]
indique que le système est instable car un des coecients du dénominateur est négatif. La
détermination des coecients de basera donc sur la fonction de transfert obtenue dans le
cadre du pendule direct qui lui, est stable. Les deux fonctions de transfert, celle du pendule
inverse et celle du pendule direct, sont en fait très proches l'une de l'autre, seuls deux signes
sont inversés [Jacob 95]. Dans la détermination de ces 3 paramètres, on veille par ailleurs à
moyenner les résultats sur plusieurs essais.
Fig. 5.4: Diagramme fonctionnel initial.
Le correcteur que nous implémentons ensuite sous LabviewTM est un correcteur du type
PIDf, "f" pour ltrage et qui permet d'atténuer ainsi les hautes fréquences provenant de
l'eet "dérivation". Ce correcteur a l'expression suivante :
5.2 Modélisation du banc 141
C(p) =C0 + C1p+ C2p
2
p(1 + pωf
). (5.3)
On réalise alors l'équivalence entre le système en boucle fermé modélisé par l'expression :
H(p) =C(p)HS(p)
1 + C(p)HS(p)(5.4)
et le système "idéal" qu'on souhaiterait obtenir pour la boucle fermé (avoir un faible dépas-
sement et un bon temps de réponse). Ce système peut prendre ainsi la forme d'un modèle
du troisième ordre, dont l'expression est :
HId(p) =1 + α p
ωm
1 + α pωm
+ α p2
Gωm2 + α p3
Gαωm3
(5.5)
avec les diérents coecients qui sont déterminés sur des abaques en fonction des critères
voulus pour notre système [Jacob 95].
Une identication terme à terme permet alors de récupérer les valeurs des coecients
C0, C1 et C2, la pulsation ωf étant généralement déterminée expérimentalement.
Développement-Test dans l'environnement LabviewTM
La réalisation de l'asservissement a été menée dans un premier temps sur un sys-
tème Windows avec l'environnement de programmation LabviewTM de la société Natio-
nal InstrumentTM . Cet environnement de programmation graphique possède en eet un
module optionnel (PID Control Toolkit [NI 98]) qui permet de régler des correcteurs de
type P (Proportionnel), PI (Proportionnel - Intégrale) ou PID (Proportionnel - Intégrale
- Dérivation). La forme du correcteur PID est légèrement diérente de celle retenue dans
l'étude théorique (le ltrage par exemple intervient sous forme d'une linéarisation [NI 98]).
Diérents essais nous ont nalement permis de déterminer empiriquement les diérents
coecients du correcteur PID de LabviewTM , assurant le maintien du pendule en position
verticale inversée.
Pour gagner du temps par rapport à l'objectif que nous nous sommes xés dans ce cha-
pitre (l'illustration de notre technique), nous avons utilisé le correcteur PID de LabviewTM ,
qui constitue donc la loi de commande retenue pour ce projet. Lorsqu'à terme, celui-ci sera
plus abouti du point de vue de l'automatique, nous pourrons envisager d'implémenter le
correcteur PID déterminé dans le paragraphe précédent. Notons également que la période
de restitution (ou de commande) que nous avons imposée expérimentalement au système
est de 4 à 5 ms. Par la suite, nous pourrons diminuer dans la mesure du possible cette
période.
L'application temps réel de contrôle du pendule, que nous allons décrire précisément dans
la section suivante, va comporter une tâche de commande dans laquelle nous implémenterons
en langage C, la loi de commande retenue. Dans notre cas, nous prenons le correcteur PID
de LabviewTM , avec les coecients du correcteur déterminés expérimentalement.
142 Application à l'Expérience du Pendule Inversé
5.3 L'application temps réel de contrôle du pendule
L'application de contrôle du pendule a été spéciée via l'utilisation de la méthode SART.
Nous avons ensuite utilisé la méthode de conception DARTS pour raner nos spécications
et pour commencer à découper notre application en un ensemble de tâches temps réel. Dans
cette section, nous décrivons ces deux étapes.
5.3.1 Spécications
Généralités sur la méthode SART [Ward 86, Goldsmith 93, Gaudel 96]
Les méthodes de spécication sont des outils de communication pour les concepteurs
et les utilisateurs d'une application. Ils permettent en eet d'exprimer les souhaits et les
besoins de l'utilisateur en levant les ambiguïtés du langage courant. SART est une évolution
de la méthode de spécication statique SA (pour Structured Analysis, analyse structurée)
vers une méthode de spécication dynamique. SART peut ainsi être caractérisée par trois
aspects :
• Un aspect fonctionnel qui est réalisé via l'utilisation de diagrammes de ots de données.
Ils permettent de montrer comment les processus fonctionnels transforment leurs entrées
(ots de données entrant) en sorties (ots de données sortant). Ils permettent également
de faire la distinction entre les types de données discrets ou continus, et de représenter
le stockage de données pouvant être utilisées par plusieurs processus.
• Un aspect événementiel représentant la dynamique du modèle, et qui est décrit par des
conditions ou des occurrences d'événements. Deux éléments sont pour cela introduits :
- Le processus de contrôle, qui pilote les processus fonctionnels en générant des événe-
ments d'activation ou de désactivation.
- Les ots de contrôle, qui représentent l'occurrence des événements générés par les
diérents processus (fonctionnels ou de contrôle). Là encore, nous pourrons faire la
distinction entre les événements consommables (discrets) et permanents (continus).
Le fonctionnement d'un processus de contrôle est décrit par l'intermédiaire d'un dia-
gramme d'état-transition qui modélise le cycle de vie du processus. Ce diagramme permet
ainsi de matérialiser l'incidence d'un événement (ou d'une combinaison d'événements)
sur l'état du système en indiquant les actions à eectuer lors de son arrivée.
• Le troisième aspect enn caractérisant SART est un aspect informationnel. Un diction-
naire de données peut en eet être utilisé pour dénir les données et les événements de
chaque étape du modèle.
Illustration sur l'application de contrôle du pendule
Il est tout d'abord nécessaire de réaliser le diagramme de contexte de l'application (cf.
gure 5.5), qui représente d'une part l'ensemble des capteurs et des actionneurs de notre
banc de test, et d'autre part les ots de données entrants et sortants de l'application. Le
processus fonctionnel Maintenir Pendule reçoit ainsi des ots de données de la part du
capteur d'angle et du capteur de position (potentiomètre). Il reçoit aussi un ot de données
provenant des capteurs de butées. Puis en sortie, le processus fonctionnel envoie des ots
5.3 L'application temps réel de contrôle du pendule 143
de données vers un écran, et principalement vers le moteur. Deux ots de contrôle portant
les événements Marche et Arrêt ont été ajoutés en provenance d'une console.
Fig. 5.5: Diagramme de contexte de l'application.
Dans la démarche de la spécication SART, nous construisons ensuite un diagramme
plus complet (cf. gure 5.6) qui représente le ranement du processus fonctionnelMaintenir
Pendule. Les ots de données entrants et sortants du diagramme de contexte sont repris
dans ce diagramme (Angle, Butées, Marche, Arrêt, etc.). On distingue également les ots
de données (èches pleines) et les zones de stockage (Angle mesuré, Position Lue), ainsi
que les ots de contrôle (èches pointillées) avec les événements Marche, Arrêt, En butée,
A/D (pour Activer/Désactiver) et Déclencher. On peut remarquer également le processus
de contrôle Contrôler Pendule, et les processus fonctionnels Acquérir Angle, Acquérir Butée,
etc..
Les processus fonctionnels Acquérir Angle et Acquérir Position ont un comportement
identique : ils reçoivent un ot de donnée et le traitent. Les résultats sont ensuite envoyés
dans des zones de stockage, respectivement Angle mesuré et Position lue. Les événements
A/D envoyés par le processus de contrôle Contrôler Pendule servent à activer ou à désacti-
ver ces deux processus, et dans le cas d'un processus activé, il y a alors exécution périodique.
Le processus fonctionnel Acquérir Butée, qui constitue le troisième type d'acquisition, re-
çoit également un ot de données du procédé, mais ne le stocke pas. Lorsqu'il est activé,
il analyse périodiquement le ot de donnée, et si il y a détection d'une butée, il envoie un
événement En butée au processus de contrôle Contrôler Pendule. Celui-ci demande alors,
par l'intermédiaire de l'événement Déclencher, l'exécution du processus Alarme. Lorsqu'ils
sont activés, les processus fonctionnels Calculer PID et Acher Résultats lisent périodi-
quement leurs zones de stockage et génèrent en réponse un ot de données, respectivement
vers le processus fonctionnel Alimenter Moteur et vers un écran. Le processus fonctionnel
Alimenter Moteur génère quant à lui une tension directement vers le procédé.
An d'expliquer le fonctionnement du processus de contrôle, la méthode SART prévoit
d'ajouter un diagramme état-transition. Celui du pendule reste cependant très simple à
décrire, puisque le processus de contrôle Contrôler Pendule ne reçoit que trois événements
(Marche, Arrêt, En butée). Le signal Marche active ainsi toutes les tâches pilotées par les
événements A/D et lorsque le pendule est en fonctionnement le signal Arrêt peut désactiver
toutes les tâches du système. Il peut aussi recevoir le signal En butée qui active alors la tâche
144 Application à l'Expérience du Pendule Inversé
d'alarme avant de désactiver toutes les autres tâches du système, sauf la tâche Alimenter
Moteur, qui enverra d'abord une tension nulle vers le moteur, avant d'être désactivée.
5.3.2 Méthode de conception DARTS [Gomaa 84]
DARTS est une méthode de conception qui permet de faciliter la transition entre SART
et l'implémentation. Une fois l'application spéciée, il permet de la concevoir et de dénir
les relations entre les tâches et les données partagées. DARTS permet en eet de représen-
ter le partage de ressources vis-à-vis des tâches formant l'application (utilisation de boîte
aux lettres, de synchronisation, etc.). Avec DARTS, nous initions en fait le découpage de
l'application en tâches logicielles, en précisant également leur mode d'activation (horloge
temps-réel pour les tâches périodiques, interruptions, événements, etc.).
Dans le diagramme de la gure 5.7, nous distinguons ainsi 7 tâches temps réel : 5sont directement périodiques (èche HTR pour horloge temps réel) et 2 sont synchronisées
par l'intermédiaire de boîte aux lettres (tâches Moteur et Alarme avec les tâches PID et
Contrôle butées). Dans ce diagramme, nous distinguons également deux zones de mémoires
partagées en lecture/écriture (unité de stockage), qui sont protégées par des sémaphores
binaires. Nous retrouvons sur le diagramme DARTS les mêmes entrées et les même sorties
que sur le diagramme SART.
Fig. 5.6: Diagramme SART de l'application, et ses notations.
5.4 L'ordonnancement des tâches 145
Ce diagramme DARTS reste proche du diagramme SART de la section précédente.
Toutefois SART n'est qu'une spécication de l'application qui a pour but de lever toute
ambiguïté sur son fonctionnement, sans pour cela s'intéresser à sa réalisation proprement
dite. Il est donc possible de faire des diagrammes DARTS assez éloignés du diagramme
SART (nous aurions pu regrouper par exemple les tâches PID et Moteur, car synchroni-
sées entre elles). Dans notre découpage de l'application temps réel en tâches, nous avons
cependant privilégié une conguration intéressante du point de vue académique (nombre
de tâches, partage de ressources). En vue de rendre l'expérience plus complexe encore, nous
pouvons ajouter une tâche d'achage, dont la durée d'exécution est importante par nature,
et qui permettra de visualiser les diérentes valeurs du système.
Les tâches temps réel ainsi déterminées, l'application est implémentée en C dans l'en-
vironnement de développement Tornado. En supposant avoir mené la phase de validation
fonctionnelle, nous devons ensuite prendre en compte l'aspect comportemental de l'appli-
cation au travers l'expression de contraintes temporelles (échéances, précédences, régularité
d'exécution). Dans la section suivante, nous dénissons les paramètres temporels des tâches
qui permettront de respecter les contraintes temporelles de l'application.
5.4 L'ordonnancement des tâches
Dans le modèle de tâche de Liu et Layland, les paramètres temporels à dénir se rap-
portent à une échelle des temps discrétisée, dont la plus petite durée correspond à la granula-
Fig. 5.7: Diagramme DARTS.
146 Application à l'Expérience du Pendule Inversé
rité de l'ordonnanceur. Bien que les contraintes temporelles déduites du procédé s'inscrivent
dans une échelle de temps continue, elles doivent être exprimées dans une échelle discréti-
sée an de pouvoir conduire l'étude d'ordonnancement. Sous VxWorksTM , la granularité de
l'ordonnanceur est dénie par la durée séparant deux ticks2 successifs, qui représentent des
instants particuliers générés régulièrement par le noyau temps réel. La norme POSIX [Gall-
meister 95] recommande une granularité comprise dans l'intervalle 10 ∼ 20ms ; la société
WindRiverTM va au delà de cette norme mais conseille de ne pas descendre en dessous
d'un quantum de temps de 1ms, sans quoi le processeur passerait plus de temps à gérer
les interruptions qu'à exécuter le code de l'application. Au travers de notre plate-forme de
test, nous verrons cependant que la fréquence de ces ticks reste bien faible au regard de la
fréquence d'un processeur.
L'ordonnancement par défaut sous VxWorksTM est préemptif, et basé sur les priorités
des tâches. Le noyau de VxWorksTM , appeléWind peut gérer jusqu'à 256 niveaux de priori-
tés, qui sont dénies lors de la création de la tâche. Elles peuvent cependant être modiées
pendant l'exécution de l'application, et permet par exemple de réaliser une méthode d'or-
donnancement à priorités variables. Si plusieurs tâches sont de même niveau de priorité, et
demandent à être exécutées de manière concurrente, elles sont alors placées dans une le
dans laquelle elles attendent leur aectation au processeur, et ce suivant une politique d'af-
fectation qui peut être du type PEPS (premier entrée, premier sortie, FIFO) (politique par
défaut), ou du type tourniquet (round-robin). Cette dernière politique permettant d'éviter
qu'une tâche de durée d'exécution longue n'accapare totalement le processeur alors qu'une
tâche de durée d'exécution courte est en attente dans la même le. Dans notre approche,
nous choisissons des priorités distinctes pour les tâches.
5.4.1 Détermination des paramètres temporels
La durée d'exécution des tâches
Principe. Pour eectuer des mesures temporelles sous VxWorksTM , il y a deux approches
possibles : la première dépend du processeur utilisé, qui peut posséder un compteur s'incré-
mentant à chaque cycle processeur, la seconde utilise la bibliothèque de fonctions timexLib
qui permet de mesurer la durée d'exécution d'une routine. Pour des routines de durées
d'exécution très courtes, il est même possible d'obtenir par itération un résultat accompa-
gné d'un intervalle de précision (par exemple 100µs à ±2µs).
Pour le processeur Intel Pentium III sur lequel nous menons notre expérience, nous
pouvons utiliser la première approche basée sur un compteur de cycles. Ce processeur
possède en eet un compteur 64 bits incrémenté à chaque cycle processeur, et que nous
pouvons lire à l'aide des outils fournis par la bibliothèque de fonctions pentiumALib. Les
fonctions de lecture du compteur nous permettent ainsi d'encadrer des instructions, nous
conduisant alors à deux valeurs entières, qu'il sut de soustraire pour obtenir la durée
d'exécution de la tâche en cycle processeur. An d'obtenir une valeur able, la mesure peut
être eectuée plusieurs fois (plusieurs centaines de millions de mesures) en utilisant une
2On pourrait employer en français le terme de top ordonnanceur, par analogie avec l'expression "le top
d'horloge", cependant, nous préférons utiliser le terme technique anglais qui est d'ailleurs souvent francisé
et employé dans les articles francophones.
5.4 L'ordonnancement des tâches 147
boucle. Il s'agit ensuite de convertir ces durées exprimées en cycle CPU, dans l'unité de
temps choisie.
Problèmes fréquents. L'ordinateur cible utilisé est un ordinateur grand public de type
Intel Pentium III, les mécanismes d'accélération des traitements des processeurs modernes
(pipeline, caches), doivent donc être contournés. En eet, ces mécanismes peuvent induire
une diérence de durée d'exécution entre un traitement eectué à deux instants diérents.
Nous désactivons ainsi les mémoires caches du processeur, puis nous plaçons une tempori-
sation de plusieurs millisecondes juste avant la portion de code, dont on souhaite mesurer
le temps d'exécution. En eet, en voulant eectuer plusieurs mesures de la durée d'exécu-
tion en un cycle, nous nous plaçons précisément dans une situation où les pipelines sont
les plus ecaces. Cette temporisation permet alors de "remplir" les pipelines d'instruction
autres que celles que nous voulons mesurer, puisque la durée du cycle processeur est de
l'ordre de quelques nanosecondes, à comparer avec la durée de quelques millisecondes de la
temporisation.
Un autre problème, d'ordre logiciel cette fois-ci, concerne les routines systèmes de très
grande priorité, qui peuvent venir perturber les mesures eectuées pendant une boucle. Ces
routines sont appelées via des interruptions systèmes, qu'il faut masquer le temps de la
mesure. C'est le cas notamment de l'interruption qui génère le tick ordonnanceur. Cette
méthode de masquage des interruptions reste cependant inecace dans le cas d'une portion
de code contenant des sémaphores. En eet, le fonctionnement des sémaphores est basé pré-
cisément sur le principe de masquage/démasquage des interruptions : lors de la libération
d'un sémaphore, le démasquage des interruptions démasque non seulement les interrup-
tions masqués par la prise du sémaphore, mais aussi celles déjà masquées auparavant. La
solution que nous proposons dans ce cas est l'utilisation de l'instruction TaskDelay(1) de
VxWorksTM qui permet de suspendre une tâche en cours de traitement jusqu'au prochain
tick ordonnanceur. Ainsi, dans le cas de la mesure de la durée d'exécution d'une prise ou
d'une libération de sémaphore, nous utilisons cette technique pour contourner les interrup-
tions régulières liées aux ticks. Il est à noter que ce genre de mesure conduit à un ordre de
grandeur de quelques nanosecondes, à comparer avec la durée entre deux ticks, de l'ordre
de la milliseconde. D'autres interruptions systèmes peuvent avoir lieu, mais nous savons
les détecter puisqu'elles génèrent des durées d'exécution dix à vingt fois supérieures à la
durée moyenne mesurée. Cette détection a été facilitée par l'outilWindViewTM , fourni avec
l'environnement de développement Tornado/VxWorksTM , qui permet la construction de
chronogrammes (Diagramme de Gantt).
D'un point de vue général, la détermination de la durée d'exécution d'une tâche n'est
pas un problème trivial, et de nombreux travaux traitent de ce sujet notamment pour gérer
les problèmes de mémoires caches [White 97], de pipelines [Zhang 93], et de processeurs à
prédiction de branchement [Colin 00]. Les auteurs de [Puschner 00] ont d'ailleurs répertorié
l'ensemble des méthodes disponibles permettant de calculer les pires temps d'exécution des
tâches. Pour notre application, nous verrons qu'une détermination ne des durées d'exé-
cutions des tâches n'est nalement pas nécessaire puisque nous allons introduire, dans un
souci de simplication, des temporisations dont les durées sont grandes comparées aux
durées réelles des tâches.
148 Application à l'Expérience du Pendule Inversé
Résultats provisoires. Nous devons maintenant rapporter ces durées à la granularité de
l'ordonnanceur, en prenant en compte également les interruptions systèmes pouvant avoir
lieu entre deux ticks successifs. Nous avons en fait réglé la distance inter-tick à 1ms. Endeçà de cette limite, WindRiverTM n'assure plus la stabilité de son système. D'ailleurs,
nous avons tenté de descendre en dessous de cette limite, et le contrôle de notre procédé
fut alors impossible (contrôle instable). Finalement, l'outil WindViewTM nous a permis
d'observer la répartition de la charge processeur (cf. gure 5.8). A noter que dans un souci
de simplication, nous n'avons pas pris en compte de tâche d'achage. En réactivant les
tâches à chaque tick ordonnanceur (symboles intO de la gure 5.8), nous constatons sur
ce diagramme que l'ensemble des tâches formant notre application temps réel peuvent être
exécutées entre deux ticks successifs de l'ordonnanceur VxWorksTM . La charge processeur
requise par notre application représente ainsi moins de 15% de la charge processeur totale.
La ligne du chronogramme correspondant à Int0 représente l'interruption système qui gé-
nère le tick de l'ordonnanceur de VxWorksTM . Les symboles graphiques que nous observons
dans ce graphe ont tous une sémantique particulière que nous verrons plus en détail par la
suite.
Fig. 5.8: La durée d'exécution des tâches est telle qu'elles sont toutes exécutées
entre deux ticks de l'ordonnanceur de VxWorksTM .
Ne pouvant pas réduire la fréquence des ticks ordonnanceur, le fait de prendre pour
chaque tâche une durée unitaire correspondant à la distance inter-tick, minimiserait −1−l'étude d'ordonnancement (pas de préemption), −2− sous exploiterait grandement la res-
source processeur, et −3− augmenterait sensiblement les temps de réponses du système
pour le contrôle du procédé.
Solution retenue : ajout de temporisations et d'une tâche ordonnanceur. Nous
avons nalement décidé, pour l'intérêt de l'illustration de notre technique de traitement de
la gigue, d'ajouter des temporisations pour chaque tâche formant l'application en faisant en
sorte de se ramener à une granularité pour l'ordonnanceur virtuel, égale à 1/10ième du quan-
tum de temps de l'ordonnanceur de VxWorksTM , soit donc 100µs. Une tâche ordonnanceur,dont la priorité est plus grande que les tâches de l'application, assura l'ordonnancement des
tâches en utilisant les fonctions d'activation, et de suspension des tâches de VxWorksTM .
Les temporisations utilisées, à la fois dans le code des tâches de l'application, et à la fois
5.4 L'ordonnancement des tâches 149
dans le code de la tâche ordonnanceur, permettent dans le premier cas de caler la durée
d'exécution sur un multiple de la granularité retenue (100µs), et permet dans le second cas
d'attendre le bon instant pour l'occurrence du tick virtuel (multiple de 100µs), pour parexemple, réactiver une tâche. Notons que ces temporisations, introduites dans le code des
tâches, sont de durées très grandes comparées à la durée réelle des tâches (100µs à comparer
avec quelques µs). Nous avons nalement retenu pour les tâches de l'application, les durées
d'exécutions reportés dans le tableau 5.1.
Tab. 5.1: Durées d'exécution des tâches rapportées à la granularité virtuelle
retenue (1 unité = 100µs).t_Butée t_Alarme t_Angle t_Position t_PID t_Moteur
Ci 1 1 3 2 1 1
Fonctionnement de l'ordonnanceur. La tâche ordonnanceur que nous implémentons,
est en fait chargée d'ordonnancer les tâches entre deux ticks successifs de l'ordonnanceur
de VxWorksTM , soit donc au niveau des ticks virtuels que nous avons dénis. Elle ne se
substitue pas au mécanisme préemptif d'attribution du processeur : il suit en fait toujours
l'ordre des priorités des tâches actives. Elle permettra en revanche de retarder le départ
d'une tâche d'une durée correspondant à un multiple de 100µs (= 1/10ième du quantum
de temps de l'ordonnanceur de VxWorksTM). Cette caractéristique sera très intéressante
pour notre technique de traitement de la gigue qui dénit des dates de première activation
particulières.
Lors de l'implémentation de la tâche ordonnanceur, on veillera à mesurer le temps
d'exécution des instructions de cette tâche, an d'éventuellement répercuter dans les tâches
de notre application, une modication de la temporisation, de sorte qu'au nal, les du-
rées d'exécution des tâches correspondent toujours à un multiple de la granularité retenue
(100µs).
Les dates de première activation, les délais critiques et les périodes
Nous considérons dans un premier temps, des tâches à départ simultané, ce qui revient à
poser pour chaque date de première activation, ri,1 = 0. Nous supposons également dans un
premier temps que l'ensemble des tâches sont à échéance sur requête, ce qui se traduit sur
les paramètres temporels par : Ti = Di. Les périodes des tâches sont ensuite déterminées
en exprimant les contraintes temporelles retenues dans l'espace des temps continu, rappor-
tées à l'espace des temps discrétisé choisi. Deux contraintes de bout en bout sont au nal
distinguées pour le pilotage du procédé. La première est liée au temps maximum donné au
système pour arrêter le moteur si une butée est franchie à pleine vitesse par le chariot, cette
durée ne doit pas dépasser 25ms (cf. annexe B). La seconde concerne la chute du pendule à
partir de la verticale : si le temps de réponse du système est supérieure à 10ms, nous avonsalors déterminé que le système ne pouvait plus rattraper le chariot (cf. annexe B).
Rappelons deux points essentiels dans la détection d'un événement par une tâche :
si un événement apparaît juste après l'exécution d'une tâche qu'on suppose intervenir à
150 Application à l'Expérience du Pendule Inversé
l'activation, et si la n de son traitement n'intervient qu'à la n de l'échéance suivante, on
considère alors que la détection, et son traitement sont intervenus au pire après une durée
de Di + Ti unités de temps. Si par contre, comme dans le cas de la tâche t_Butée et de la
tâche t_Alarme, il y a une synchronisation, la détection pour la tâche qui suit, c'est-à-dire
t_Alarme, se fera avec une durée au pire de Di. En notant respectivement par TBut et TAl,les périodes de ces deux tâches, et on notant TMot la période de la tâche moteur, la première
contrainte temporelle (cf. gure 5.9-a) se traduit alors par :
2TBut + 2TMot + TAl ≤ 25ms, (5.6)
en outre, du fait de la synchronisation, on a la relation : TBut = TAl. En notant respec-
tivement TAng, TPos et TPID, les périodes de la tâche d'acquisition de l'angle, de la tâche
d'acquisition de la position, et de la tâche PID, l'expression de la seconde contrainte tem-
porelle est donnée (cf. gure 5.9-b) par :
max(2TAng; 2TPos) + 2TPID + TMot ≤ 10ms, (5.7)
avec toujours la relation : TPID = TMot. Ces deux conditions (5.6 et 5.7) forment les princi-
pales contraintes temporelles déduites du procédé dans le cadre de ce projet. Nous pouvons
au nal rajouter des contraintes de régularité d'exécution pour la tâche de commande
t_Moteur, ainsi que les tâches d'acquisition t_Angle et t_Position.
Nous avons nalement reporté dans le tableau 5.2 et dans le graphe de la gure 5.10 la
conguration de tâches retenue, les contraintes de précédence, et les contraintes de régu-
larité. Nous avons également reporté le paramètre "Priorité Fixe" qui dénit une priorité
unique sur l'ensemble des tâches. C'est ce paramètre qui est consulté en dernier ressort
lorsqu'il y a égalité de priorités entre deux tâches, c'est le cas par exemple sous DMlorsqu'elles ont même délai critique. Ces priorités xes ont été choisies dans le souci de
faire respecter les conditions de précédence : par exemple, pour t_PID → t_Moteur, on a
PrioPID > PrioMot, et on a également PrioBut > PrioAl. A noter que nous avons adopté
la convention de WindRiverTM , selon laquelle on accorde la plus grande priorité à la tâche
qui a la plus faible valeur pour le paramètre "Priorité Fixe". Nous avons par ailleurs choisi
la priorité la plus grande pour la tâche t_Angle, de sorte que du point de vue du procédé,
la mesure de l'angle se fasse rapidement (faible temps de réponse), dès l'activation de la
tâche, an de pouvoir réagir le cas échéance, avec la loi de commande. Quant à la tâche
t_Position, l'inertie du chariot ne demandant pas la même contrainte, nous l'avons placé
après les 3 premières tâches.
5.4.2 Contrôle de la gigue
L'ordonnancement des tâches selon les priorités xes, données dans le tableau 5.2,
conduit au chronogramme de la gure 5.11, où est représentée l'exécution des tâches de
l'application sur une durée de 4 ticks VxWorksTM , soit une durée de 40 ticks par rapport
à notre découpage du temps. A noter que les tâches sont ordonnées suivant leur priorité,
de la tâche t_Angle la plus prioritaire à la tâche t_Alarme, la moins prioritaire. La fenêtre
d'observation est calée sur une partie du chronogramme dans laquelle les tâches systèmes
nécessaires par exemple à la gestion du réseau, ou encore à la gestion du Target Agent
5.4 L'ordonnancement des tâches 151
(cf. annexe C) ne demandent pas à être exécutées. La fenêtre d'observation est donc une
vue idéalisée de notre application en fonctionnement : aucune routine système permettant
d'espionner cette exécution n'est représentée. Dans une phase nale de développement,
l'ensemble de ces routines systèmes qui ne sont pas directement nécessaires à l'application
temps réel, peuvent en revanche être écartées du noyau VxWorksTM .
Ce problème de l'espionnage de la phase d'exploitation de l'application est d'ailleurs
un problème courant pour la validation temporelle des systèmes temps réel : lorsqu'on ne
valide pas a priori l'application, ce qui est le cas dans beaucoup d'approches industriels
[Puschner 02, Hillary 02] - le matériel ne s'y prêtant d'ailleurs pas aisément - la validation
temporelle n'intervient alors qu'au travers de tests, qu'on espère les plus exhaustifs possibles
Fig. 5.9: (a) : Détermination du pire temps mis par le système pour réagir à
une détection de butée - (b) : Détermination du pire temps mis par le système
pour réagir à une chute du pendule depuis la position verticale inversée.
Fig. 5.10: Le graphe des précédences de l'application.
152 Application à l'Expérience du Pendule Inversé
Tab. 5.2: Paramètres temporels retenus pour les tâches, rapportés à la granula-
rité virtuelle choisie (1 unité = 100µs).Tâches ri Ci Di Ti Régulière Priorité Fixe
t_Angle - τ1 0 3 20 20 Oui 1
t_PID - τ2 0 1 10 10 Non 2
t_Moteur - τ3 0 1 10 10 Oui 3
t_Position - τ4 0 2 20 20 Oui 4
t_Butée - τ5 0 1 70 70 Non 5
t_Alarme - τ6 0 1 70 70 Non 6
(cf. la mission PathFinder dans [Wilner 97]). Ces tests viennent cependant interagir avec
l'application et sont donc faussés dans une certaine mesure. Une approche plus coûteuse
consiste alors à mener ces tests directement au niveau du matériel en espionnant par exemple
le bus et en évitant ainsi d'ajouter dans l'application des tâches d'espionnage qui perturbent
le contrôle du procédé.
5.4.2.1 Interprétation des chronogrammes WindView
Dans les chronogrammes de l'outil WindView, appelé aussi diagrammes de Gantt, à
chaque symbole graphique est associé un événement (ou un état), l'objectif étant de repré-
senter les diérents états, par lesquels passent les tâches pendant la phase d'exploitation
de l'application temps réel. La couleur de ces symboles porte par ailleurs une sémantique
particulière. Dans la liste ci-dessous, nous avons énuméré les principaux symboles utilisés
dans les chronogrammes WindView de cette section.
- La tâche est prête à être exécutée. Elle est en attente du processeur.
- La tâche est en cours d'exécution.
Fig. 5.11: Séquence d'ordonnancement de la conguration de tâches sans mé-
canisme de contrôle de la gigue : la tâche t_Moteur présente de la gigue (les
exécutions ne sont pas régulières).
5.4 L'ordonnancement des tâches 153
- La tâche est retardée jusqu'à l'occurrence d'un tick ordonnanceur, qui n'est pas
nécessairement le tick suivant immédiat. En fait, une tâche passe dans ce mode lors-
qu'on utilise dans son code l'instruction taskDelay(n) où n représente le nombre de ticks
VxWorksTM que la tâche considérée devra laisser passer avant de se réactiver.
- La tâche est bloquée en attente d'une ressource. Dans nos exemples de chro-
nogrammes, les tâches t_Moteur et t_Alarme passent par cet état lorsqu'elles doivent
se synchroniser avec respectivement les tâches t_PID et t_Butée. Cette synchronisa-
tion passe par l'utilisation de boîte aux lettres qui sont implémentées en utilisant des
sémaphores (cf. section 1.1, paragraphe sur les communications et les sémaphores).
- La tâche sort de son mode retardée : il y a réactivation de la tâche. Le tick sur
lequel la tâche est réactivée correspond à celui qui est implicitement mentionné dans
l'instruction taskDelay(n) (cf. ci-dessus).
- Dans le code d'une tâche, ce symbole représente un appel à la fonction de réacti-
vation d'une tâche (fonction taskResume("IdentiantDeLaTâche")).
- Ce symbole représente l'utilisation de l'instruction taskDelay(n), qui réactive la
tâche lorsque n ticks se sont écoulés.
- Ce symbole représente la prise d'un sémaphore. Dans nos diagrammes, il est
utilisé pour les boîtes aux lettres gérant les communications et la synchronisation entre
les tâches t_Moteur et t_PID et les tâches t_Alarme et t_Butée.
- Ce symbole représente la libération d'un sémaphore.
5.4.2.2 Calcul de la gigue des tâches
Sur le diagramme de la gure 5.11, on peut déterminer le pourcentage de gigue de
régularité locale des tâches régulières. La tâche t_Angle est exécutée toutes les 20 unités
de temps, et ne présente pas de gigue : elle est en fait exécutée dès son activation. La tâche
t_Position ne présente pas elle aussi de gigue. En revanche, la régularité d'exécution de la
tâche t_Moteur n'est pas vériée : en eet, entre les deux premières instances visibles du
chronogramme, la gigue de régularité vaut :
jst_Moteur=
|13− 10|10
× 100% = 30%, (5.8)
et entre les deux instances suivantes, la gigue vaut :
jst_Moteur=
|7 − 10|10
× 100% = 30%. (5.9)
et ainsi de suite. Ces valeurs de gigue ne sont donc pas négligeables, et il est alors intéressant
d'appliquer notre technique de contrôle de la gigue sur cette conguration de tâches.
154 Application à l'Expérience du Pendule Inversé
5.4.2.3 Technique de contrôle de la gigue
Parmi les relations de précédence de la conguration de tâches considérée, nous avons
une relation mettant en jeu une tâche non régulière t_PID suivi d'une tâche régulière
t_Moteur. Ne souhaitant pas être gênés par cette relation qui empêche l'application directe
de notre technique d'annulation de la gigue dans le cadre de DM , ou dans le cadre de
l'ordonnancement selon les "priorités xes" (cf. paragraphe 3.2.3.2 & remarque 3.3), nous
avons considéré la tâche t_PID comme régulière. D'ailleurs, étant synchronisée avec la
tâche t_Moteur qui doit, du point de vue du procédé, être régulière, il est intéressant de
rendre également la tâche t_PID régulière, de sorte que le résultat du calcul de la loi de
commande arrive régulièrement vers la tâche t_Moteur.
Nous déroulons alors les 4 étapes de notre méthode en considérant les 4 premières
tâches comme régulières. Pour utiliser directement les mécanismes d'ordonnancement de
VxWorksTM , nous adoptons pour la méthode d'ordonnancement, celle basée sur les priorités
xes.
Etape 1 Le problème de désynchronisation appliquée aux quatre premières tâches conduit
à un ensemble de 3264 quadruplets solutions. On a par exemple le quadruplet suivant :
(r1,1, r2,1, r3,1, r4,1) =(0, 3, 4, 5).
Etape 2 Les deux relations de précédence de l'application imposent d'une part que :
r2,1 ≤ r3,1, ce qui est le cas avec le quadruplet pris en exemple, et imposent d'autre part
que r5,1 ≤ r6,1 ce qui est le cas avec les dates d'activation initiales de t_Butée (τ5) ett_Alarme (τ6).
Ces relations de précédence imposent également deux conditions au niveau des priorités :
Prio2 > Prio3, et Prio5 > Prio6, ce qui est encore le cas avec les paramètres "Priorité
Fixes" initiaux.
Etape 3 L'ensemble des tâches régulières du tableau 5.2 sont ordonnées suivant leur
priorité xe : les quatre premières tâches du tableau ont donc des priorités plus grandes
que les deux tâches non régulières : il n'y a donc pas lieu de modier les priorités.
Etape 4 On vérie ensuite par simulation que la nouvelle conguration de tâches rete-
nues (celle reportée dans le tableau 5.3) est bien ordonnançable, ce qui est le cas.
Tab. 5.3: Nouveaux paramètres temporels de l'application.Tâches ri Ci Di Ti Régulière Priorité Fixe
t_Angle - τ1 0 3 20 20 Oui 1
t_PID - τ2 3 1 10 10 Oui 2
t_Moteur - τ3 4 1 10 10 Oui 3
t_Position - τ4 5 2 20 20 Oui 4
t_Butée - τ5 0 1 70 70 Non 5
t_Alarme - τ6 0 1 70 70 Non 6
Il s'agit maintenant de mettre en place les décalages des dates d'activation, sachant
que sous VxWorksTM , les seuls retards à l'activation réalisables simplement se font via
5.4 L'ordonnancement des tâches 155
l'utilisation de la fonction taskDelay(n) ce qui ne conduit qu'à des décalages minimums de
10 quanta (en se référant à notre découpage du temps). Nous avons donc nalement adopté
la solution d'une tâche ordonnanceur de très grande priorité, devant gérer les retards à
l'activation des tâches régulières, retards pouvant être en deçà de 10 unités de temps.
L'implémentation de cette tâche ordonnanceur est réalisée dans le souci de faire respecter
un quantum de temps virtuel de 100µs. Les points de préemption éventuel doivent donc
avoir lieu à des dates multiples de 100µs. Cette caractéristique est facilitée par la présencede temporisations dans le code de nos tâches, permettant ainsi d'adapter leur durée pour
respecter ce découpage temporel.
Le résultat de l'ordonnancement de la nouvelle conguration de tâches est reportée dans
la gure 5.12. Dans ce chronogramme, on observe que la tâche ordonnanceur fait de l'attente
active toutes les 20 unités de temps, an de retarder de 3 unités de temps l'activation de
la tâche t_PID par rapport aux ticks de l'ordonnanceur VxWorksTM . Lorsque la tâche
ordonnanceur ne fait pas de l'attente active, la tâche t_Angle s'exécute. L'ensemble des
tâches considérées comme régulières (t_Angle, t_PID, t_Moteur, t_Position) ne présente
aucune irrégularité d'exécution : la distance séparant deux débuts d'exécution successifs
correspond toujours à la période de la tâche : la gigue des tâches est donc inexistante.
D'un point de vue automatique, il serait malhonnête de dire qu'une nette amélioration
est perceptive dans le maintien du pendule en position verticale inversée. Soulignons ce-
pendant que d'un point de vue théorique, la régularité de la tâche de contrôle permet une
meilleur application des principes d'automatique, notamment dans l'élargissement du do-
maine de stabilité du procédé asservi. C'est d'ailleurs l'une des principales critique que nous
pouvons formuler à l'égard de ce banc de test, à savoir sa trop forte orientation temps réel
au détriment de l'automatique. D'une part, la régulation ne se fait que par rapport à l'angle
(cf. paragraphe 5.2.1), et d'autre part, le moteur et le capteur de position ne permettent
pas un asservissement de position assez précis. C'est donc ces derniers points qu'il faudra
améliorer par la suite, pour donner à ce banc de test, son côté "spectacle"...
Fig. 5.12: Séquence d'ordonnancement de la conguration de tâches avec mé-
canisme de contrôle de la gigue : la tâche t_Moteur ne présente plus de gigue
(exécutions régulières), ainsi que les tâches t_Angle et t_Position.
156 BIBLIOGRAPHIE
5.5 Conclusion
Nous avons présenté à travers un exemple d'application temps réel, à savoir le contrôle
d'un pendule en position inversée, la faisabilité de la technique de contrôle de la gigue dans
le cadre des ordonnancements en ligne. L'exemple présenté suit le cycle de développement
typique d'une application temps réel : méthode de spécication SART, méthode de concep-
tion DARTS, détermination des paramètres temporels des tâches et ordonnancement.
La principale diculté résidait dans le fait que l'ordonnanceur fourni avec les noyaux
temps réel du commerce possède un quantum de temps tellement grand comparé à la
puissance des processeurs actuels, qu'il est dicile de mener une démarche de validation
basée sur l'ordonnancement. Un ordonnanceur virtuel a alors été mis en ÷uvre, an de
diminuer le quantum de temps ordonnanceur, et rendre possible l'application de notre
technique d'ordonnancement permettant la maîtrise de la gigue de régularité. En gardant
à l'esprit l'objectif de ce chapitre, l'illustration de la technique de contrôle de la gigue,
nous avons introduit des temporisations dans le code des tâches de sorte que le quantum de
temps virtuel retenu corresponde au 1/10ième du quantum de temps minimum conseillé par
WindRiverTM . Une tâche ordonnanceur a permis alors de gérer les tâches de l'application
en deçà du quantum de temps de VxWorksTM .
Cette tâche ordonnanceur était par ailleurs nécessaire pour l'application de la technique
de traitement de la gigue, puisque dans l'étape 1, le problème de désynchronisation conduit
à des retards à l'exécution qui sont plus faibles que 10 quanta de temps. La gestion des
relations de précédence et des priorités a été facilitée par le choix adopté pour la méthode
d'ordonnancement, à savoir celle basée sur les priorités xes. Finalement, la conguration
de départ issue de la conception et de la phase de détermination des paramètres temporels,
conduit à une exécution des tâches présentant de la gigue sur une des tâches (30%). La
mise en ÷uvre de la technique de traitement de la gigue a conduit alors à l'annulation de
la gigue sur l'ensemble des tâches régulières.
Cette plate-forme de test qui a illustré notre technique de maîtrise de la gigue, pourra
par ailleurs être utilisée pour mettre en pratique d'autres techniques d'ordonnancement.
Bibliographie
[Anderson 89] Anderson C.W. Learning to control an inverted pendulum using neural
networks. IEEE Controls Systems Magazine, 1989, vol 9, p 3137.
[Borne 93] Borne P., Dauphin-Tanguy G., Richard J.P., Rotella F. et Zam-
bettakis I. Automatique : Analyse et Régulation des Processus Indus-
triels, Tome 2, Régulation Numérique. TECHNIP : Méthodes et Pratiques
de l'Ingénieur, 1993.
[Colin 00] Colin A. et Puaut I. Worst case execution time analysis for a processor
with branch prediction. Real-Time Systems, May 2000, vol 18(2), p 249
274.
[Gallmeister 95] Gallmeister B.O. POSIX.4 : Programming for the Real World. O'Reilly
and Associates, 1995.
BIBLIOGRAPHIE 157
[Gaudel 96] Gaudel M.C., Marre B., Schlienger F. et Bernot G. Précis de
Génie Logiciel. Editions Masson, 1996.
[Goldsmith 93] Goldsmith S. A practical guide to real-time systems development. Pren-
tice Hall Editions, 1993.
[Gomaa 84] Gomaa H. A software design method for real-time systems. Communi-
cations of the ACM, 1984, vol 27(9), p 938949.
[Guyenot 89] Guyenot P. et Hans T. Régulation et asservissement : Eléments de
cours, Problèmes résolues. Ed. EYROLLES, 1989.
[Hillary 02] Hillary N. etMadsen Ken. You Can't Control what you Can't Measure
OR Why it's Close to Impossible to Guarantee Real-Time Software Per-
formance on a CPU with on-chip cache. 2nd International Workshop on
Worst Case Execution Time Analysis - Satellite Event of 14th Euromicro
Conference on Real-Time Systems, June 2002.
[Jacob 95] Jacob D. Calcul des correcteurs pid par la méthode des moments pour
les systèmes instables en boucle ouverte : Application au contrôle d'un
pendule inversé. Revue d'Automatique et de Productique Appliquées, 1995,
vol 8(4), p 585608.
[NI 98] NI . National Instrument : BridgeVIEW And Labview : PID control Toolkit
for G. Reference Manual. National Instrument, 1998.
[Puschner 00] Puschner P. et Burns A. Guest editorial : A review of worst-case
execution-time analysis. Real-Time Systems, 2000, vol 18, p 115128.
[Puschner 02] Puschner P. Is Worst-Case Execution-Time Analysis a Non-Problem ?
Towards New Software and Hardware Architectures. 2nd International
Workshop on Worst Case Execution Time Analysis - Satellite Event of
14th Euromicro Conference on Real-Time Systems, June 2002.
[Rivoire 96] Rivoire M et Ferrier Jean-Louis. Cours d'Automatique, Tome 2 :
Asservissement, Régulation et Commande Analogique. Ed. EYROLLES,
1996.
[Wang 96] Wang H.O., Tanaka K. et Griffin M. An approach to fuzzy control
of non linear systems : Stability and design issues. IEEE Transactions on
Fuzzy Systems, 1996, vol 4(1), p 1423.
[Ward 86] Ward P.T. et Mellor S.J. Structured Development for Real-Time Sys-
tems, volume volume 3 : Implementation Modeling Techniques. Yourdon,
Inc., Englewood Clis, New Jersey, 1986.
[White 97] White R., Mueller F., Healy C., Whalley D. et Harmon M. Ti-
ming analysis for data caches and set-associative caches. Proc. IEEE Real-
Time Technology and Applications Symposium. June 1997, p 192202.
[Wilner 97] Wilner D. Vx-Files : What Really Happened on Mars ? Keynote Speech,
during the 18th IEEE Real-Time Systems Symposium, RTSS'97, 1997. D.
Wilner is the Chief Technical Ocer of Wind River Systems.
[Zhang 93] Zhang N., Burns A. et Nicholson M. Pipelined processors and worst
case execution times. Real-Time Systems, 1993, vol 5(4), p 319343.
158 BIBLIOGRAPHIE
Conclusion générale
Dans les deux premiers chapitres de ce mémoire, nous avons présenté la problématique et
le contexte de ces travaux. Nous sommes partis du constat que dans le cadre des applications
temps réel à contraintes strictes ordonnancées suivant les algorithmes d'ordonnancement
en ligne, seules les contraintes d'échéances et éventuellement les contraintes de précédence,
étaient respectées. Il nous est alors apparu intéressant de proposer une technique d'ordon-
nancement permettant non seulement de gérer ces deux types de contraintes temporelles
mais aussi les contraintes de régularité d'exécution de certaines tâches, appelées tâches ré-
gulières. Ces contraintes sont en eet présentes dans les processus d'interfaçage entre le
procédé, évoluant généralement dans un espace continu, et le système informatique, évo-
luant dans un espace discret. Ces tâches représentent typiquement des tâches d'acquisition
ou de commande.
L'exécution concurrente des tâches dans les systèmes temps réel conduit au non respect
de ces contraintes, on parle alors d'irrégularités d'exécution ou de gigue. De manière géné-
rale, ces contraintes sont souvent passées sous silence dans la phase d'ordonnancement car
on impose aux tâches d'acquisition ou de commande une période très petite par rapport
à la période théorique minimum (on parle de sur-échantillonnage par rapport à la période
de Shannon). Il n'y a alors pas de détérioration notable de l'information à communiquer,
et l'apparition de gigue n'est donc pas considérée comme rédhibitoire. Cette solution a ce-
pendant pour inconvénient de créer une surcharge au niveau du processeur et n'optimise en
rien sa gestion.
La technique d'ordonnancement que nous proposons résout ce problème puisqu'il permet
de prendre en compte dans la phase d'ordonnancement cette contrainte de régularité d'exé-
cution imposée par exemple par les domaines de l'automatique et du traitement du signal
(maintien d'un procédé dans son domaine de stabilité, échantillonnage, ...). Cette technique
intervient dans le contexte des algorithmes d'ordonnancement en ligne basés sur les priori-
tés xes ou les échéances (DM ou EDF), et se caractérise en fait par un choix particulier
des paramètres temporels des tâches formant l'application temps réel. Lorsque ce choix
est eectué selon notre technique, l'ordonnancement des tâches conduit à des séquences
d'exécution dans lesquelles les contraintes d'échéances, de précédence, et de régularité sont
toutes respectées.
La technique proposée permet soit d'annuler totalement la gigue de certaines tâches dites
régulières, soit de l'encadrer. Elle s'articule autour de quatre étapes. Une première étape
dans laquelle les tâches régulières sont désynchronisées les unes par rapport aux autres an
d'obtenir des fenêtres d'exécution qui ne se chevauchent pas. Une deuxième étape impose
en fonction des précédences, des conditions sur les paramètres "date d'activation" et "délai
critique" (ou "priorités xes"). Une troisième étape impose aux tâches régulières soit une
160 Conclusion générale
priorité plus grande que les tâches non régulières (cas de l'annulation), soit un délai critique
compatible avec les conditions de l'étape 2, et compatible avec les largeurs des fenêtres
d'exécution retenues dans l'étape 1. Si dans une quatrième étape l'ordonnancement des
tâches est encore assuré, la séquence obtenue respecte alors les trois contraintes temporelles
évoquées ci-dessus. Dans la mise en ÷uvre de la technique, soulignons qu'il est plus facile
de la mener à terme dans le cadre des ordonnancement DM ou ceux basés sur la priorité,
que dans le cadre des ordonnancements EDF, pour lequel la gestion de la priorité est plus
délicate. A noter que ce sont surtout les conditions liées aux interdépendances entre les
tâches qui rendent la technique plus dicile à appliquer sous EDF.
D'un point de vue général, rappelons que cette méthode n'est pas optimale mais qu'elle
permet à un concepteur d'application temps réel de dénir en amont de la phase d'ordon-
nancement des paramètres de tâches qui assureront avec la politique d'ordonnancement
choisi, non seulement le respect des contraintes de précédence et d'échéance, mais aussi
le respect des contraintes de régularité d'exécution de certaines tâches. La technique pro-
posée est par ailleurs exponentielle en nombre de tâches ; mais généralement le nombre de
tâches régulières pour une application temps réel classique est faible. Les diérents exemples
illustrant ce mémoire ont d'ailleurs demandé des durées de temps de calcul faibles.
La compatibilité de la technique avec les protocoles de gestion de ressources a ensuite
été étudiée, et il est apparu que dans la plupart des situations, la gestion de ressources peut
être menée de manière parallèle (cf. tableau 3.11 en page 109).
Cette technique basée sur la modication des paramètres des tâches formant l'applica-
tion a ensuite été généralisée au contrôle d'autres contraintes temporelles, comme la gigue
de bout en bout, le temps de réponse d'une tâche ou d'une activité. Finalement, nous avons
reporté dans le tableau 3.13 en page 120, les diérents contextes d'utilisation compatibles
avec notre technique.
Dans le quatrième chapitre, nous avons confronté cette technique à des expérimentations
numériques qui nous ont permis de montrer l'intérêt de la technique pour divers contextes
d'utilisation (forte charge processeur, DM, EDF, etc.). Le taux de réussite de la technique
pour des congurations de tâches indépendantes varie en fonction de ces diérents contextes.
Par exemple, plus le nombre de tâches régulières sur le nombre de tâches non régulières est
grand ou, plus la charge processeur est forte, moins la technique est ecace. D'un point
de vue général cependant, les taux de réussite de la technique sont intéressants, puisque
pour des contextes d'utilisation "moyens" (charge processeur comprise entre 75% et 90%,
gigue initiale comprise entre 0% et 20%, 2 tâches régulières pour 8 tâches non régulières),
on obtient des pourcentages de réussite compris entre 60% et 90%.
Le dernier chapitre de ces travaux propose un exemple concret d'application temps réel
sur laquelle nous avons appliqué au niveau de la phase d'ordonnancement, la technique d'an-
nulation de la gigue. Cette dernière a permis d'annuler totalement la gigue sur une tâche
régulière alors que l'emploi d'une technique traditionnelle de l'ordonnancement conduisait
cette même tâche à une gigue de 30%.
Dans de futurs travaux, il conviendra d'étudier en détail le contrôle de la gigue de bout
en bout et le contrôle du temps de réponse, car les solutions proposées dans ce mémoire se
situent dans la continuité de la technique de contrôle de la gigue de régularité, qui induit
donc une démarche spécique.
Conclusion générale 161
Il sera en outre intéressant de mesurer la perte de robustesse de la conguration de tâches
modiée par rapport à la conguration de tâches initiale. Le calcul de la laxité minimale
du système de tâches avant et après l'application de la technique de traitement de la gigue
permettrait par exemple de donner une mesure de la sensibilité des congurations aux
surcharges (non respect d'une ou plusieurs échéance(s)). Dans un objectif de nalisation
de l'outil de simulation numérique, il conviendra également de caractériser plus nement
encore l'outil de génération automatique au travers d'une étude statistique plus exhaustive
(répartition de la charge processeur réellement obtenue par exemple en fonction de la gigue
souhaitée).
Il conviendra également de vérier s'il est possible d'adapter cette méthodologie au
contexte des applications temps réel distribuées. Nous avons d'ailleurs évoqué dans le cha-
pitre "Etat-de-l'art", une technique de contrôle de la gigue qui était appliquée au contrôle
de la régularité d'émission des messages sur un réseau. Le domaine du temps réel distribué
est en eet un domaine de recherche très actif, et agencer l'émission des messages pour
optimiser l'utilisation du réseau peut être un objectif important, voire majeur.
Le principe de désynchronisation exposé dans ce mémoire de Doctorat pourrait éga-
lement servir à maîtriser les changements de mode de fonctionnement de certaines appli-
cations temps réel. En eet, les conditions d'activation des tâches dans le domaine des
asservissements échantillonnés inuent directement sur la durée du régime transitoire, et
donc sur la stabilité du système. Maîtriser la durée du régime transitoire au travers l'or-
donnancement des dates d'activation des tâches participant à l'asservissement, permettrait
de gérer plus nement la stabilité des applications temps réel qui ont plusieurs modes de
fonctionnement. Dans le cadre du pendule par exemple, on peut distinguer une phase de
fonctionnement mettant en jeu un nombre réduit de tâches pour amener le pendule de sa
position stable directe à sa position instable inversée, et une autre phase de fonctionnement
mettant en jeu d'autres tâches et qui consiste à maintenir le pendule dans cette position
instable inversée.
Parmi les travaux en cours, une approche probabiliste très diérente de l'approche dé-
terministe présentée dans ce mémoire de thèse, a été abordée en collaboration avec le
Professeur N.Nissanke de l'université de South Bank de Londres. Nous avons ainsi mis en
place une approche probabiliste de l'ordonnancement des tâches ; et ce, dans le souci de faire
face à l'indéterminisme temporel croissant des matériels informatiques, et pour un contexte
d'applications temps réel à contraintes molles (applications en forte croissance comme le
multimédia). Les premiers résultats sont encourageants. Par exemple, dans le cadre d'or-
donnancements basés sur les priorités xes, avec une modélisation des durées d'exécution
sous forme de loi de probabilité, ces travaux ont permis de déterminer la loi de probabilité
de la gigue d'une tâche. Au delà de ces résultats, nous espérons obtenir des lois de proba-
bilité pour des critères généraux de qualité de service (dont la gigue fait partie). En outre,
cette approche probabiliste pourrait recevoir un bon accueil de la part de l'industrie car
les notions de loi d'évolution statistique d'une variable, la notion d'intervalle de conance,
etc. sont des notions que les industriels côtoient au quotidien au travers du département
qualité : la maîtrise statistique des procédés (MSP) est par exemple incontournable dans la
fabrication de produits en grande série.
162 BIBLIOGRAPHIE
Bibliographie
[Anderson 89] Anderson C.W. Learning to control an inverted pendulum using
neural networks. IEEE Controls Systems Magazine, 1989, vol 9, p
3137.
[Aström 99] Aström K.J. et Wittenmark B. Computer-controlled Systems :
Theory and design. Prentice Hall, Information and System, Sciences
Series, 1999.
[Audsley 91] Audsley N.C. Optimal priority assignment and feasibility of static
priority tasks with arbitrary start times. Rapport technique YCS-164,
University of York, nov. 1991.
[Baker 90] Baker T.P. Stack-based scheduling of real-time processes. Proc. of
the 11th IEEE Real-Time Systems Symposium, RTSS'90. Dec 1990, p
191200.
[Baker 91] Baker T.P. Stack-based scheduling of real-time processes. Real-
Time Systems, 1991, vol 3, p 6799.
[Balakrishnan 62] Balakrishnan A.V. On the problem of time jitter in sampling.
I.R.E. Trans. on Inf. Theory, 1962, vol IT8, p 226236.
[Baruah 90] Baruah S.K., Howell R.R. et Rosier L.E. Algorithms and com-
plexity concerning the preemptive scheduling of periodic, real-time
tasks on one processor. Real-Time Systems, 1990, vol 2, p 301324.
[Baruah 97] Baruah S.K., Chen D. et Mok A.K. Jitter concerns in periodic
task systems. Proc. of the 18th IEEE Real-Time Systems Symposium,
RTSS'97. Burlington, VT, USA, Dec. 1997. p 6877.
[Baruah 99] Baruah S. K., Buttazzo G., Gorinsky S. et Lipari G. Schedu-
ling periodic task systems to minimize output jitter. Proc. of the In-
ter. Conf. on Real-Time Computing Systems and Applications. Hong-
Kong, Dec. 1999. IEEE Computer Society Press, p 6269.
[Bate 98] Bate I. J. Scheduling and Timing Analysis for Safety Critical Real-
Time Systems. Thèse : Department of Computer Science, University
of York, nov. 1998.
[Bate 99] Bate I. et Burns A. An approach to task attribute assignment
for uniprocessor systems. Proc. of the 11th EuroMicro on Real-time
Systems. York, UK, 1999. p 4653.
164 BIBLIOGRAPHIE
[Blazewicz 76] Blazewicz J. Modelling and performance evolution of computers
systems, chapitre Scheduling dependent tasks with dierent arrival
times to meet deadlines. North-Holland Publishing Company, 1976.
[BÔNE 94] BÔNE J.C., MOREL J. et BOUCHER M. Mécanique générale,
Cours et Applications. Edition DUNOD, 1994.
[Borne 93] Borne P., Dauphin-Tanguy G., Richard J.P., Rotella F. et
Zambettakis I. Automatique : Analyse et Régulation des Processus
Industriels, Tome 2, Régulation Numérique. TECHNIP : Méthodes et
Pratiques de l'Ingénieur, 1993.
[Buttazzo 97] Buttazzo G.C. Hard real-time computing systems, chapitre Perio-
dic task scheduling, p 77108. Kluwer Academic Publishers, 1997.
[Cervin 99] Cervin A. Improved scheduling of control tasks. Proc. of the 11th
IEEE Euromicro Conference. York, UK, June 1999. p 410.
[Cervin 02] Cervin A., Eker J.,Bernhardsson B. etArzén K.-E. Feedback-
feedforward scheduling of control tasks. To appear in Real-Time Sys-
tems - Special Issue on Control - Theoritical Approaches to Real-Time
Computing, 2002.
[Chan 92] Chan M.Y. et Chin F. General schedulers for the pinwheel problem
based on double-integer reduction., volume 41(6), chapitre Transac-
tions On Computers, p 755768. IEEE, June 1992.
[Chan 93] Chan M.Y. et Chin F. Algorithmica, volume 9, chapitre Schedulers
for Larger Classes of Pinwheel Instances, p 425462. 1993.
[Chen 90] Chen M. et Lin K. Dynamic priority ceilings : a concurrency protocol
for real-time systems. Real-Time Systems, 1990, vol 2(4), p 325346.
[Cheng 96] Cheng S.-T. et Chen C.-M. A cyclic scheduling approach for rela-
tive timing requirements. Proc. of the 3rd IEEE Real-Time Application
Workshop. Québec, Canada, 1996. p 160163.
[Chetto 90] Chetto H., Silly M. et Bouchentouf T. Dynamic scheduling
of real-time task under precedence constraints. Real-Time Systems,
1990, vol 2, p 181194.
[Choquet-Geniet 96] Choquet-Geniet A., Geniet D. et Cottet F. Exhaustive com-
putation of the scheduled task execution sequences of a real-time ap-
plication. Proc. of the 4th International Symposium on Formal Tech-
niques in Real-Time and Fault-Tolerant Systems. Uppsala, Sweden,
1996. p 246262.
[CNRS 88] CNRS Groupe de réflexion temps-réel du CNRS. Le temps-
réel. Technique et Science Informatiques - TSI, 1988, vol 7(5), p
493500.
[Colin 00] Colin A. et Puaut I. Worst case execution time analysis for a
processor with branch prediction. Real-Time Systems, May 2000,
vol 18(2), p 249274.
BIBLIOGRAPHIE 165
[Cottet 97] Cottet F. Traitement des signaux et acquisition de données. Dunod,
1997.
[Cottet 99a] Cottet F. et David L. A solution to the time jitter removal in
deadline based scheduling of real-time applications. 5th IEEE Real-
Time Technology and Applications Symposium - WIP. Vancouver,
Canada, 1999. p 3338.
[Cottet 99b] Cottet F., Delacroix J., Kaiser C. etMammeri Z. Ordonnan-
cement temps réel. HERMES, 1999.
[Coutinho 00a] Coutinho F., Fonseca J. A., Barreiros J. et Costa E. Jitter
minimization with genetic algorithms. Proc. of the 3rd IEEE Inter-
national Workshop on Factory Communication Systems, WFCS'2000.
Porto, Portugal, 2000.
[Coutinho 00b] Coutinho F., Fonseca J. A., Barreiros J. et Costa E. Using
genetic algorithms to reduce jitter in control variables transmitted
over can. Proc. of the 7th International CAN Conference, ICC'2000.
Amsterdam, The Netherlands, Oct. 2000.
[David 00] David L., Cottet F. et Grolleau E. Gigue temporelle et ordon-
nancement par échéance dans les applications temps réel. Proc. of
the IEEE Conf. Inter. Francophone d'Automatique, CIFA'00. Lille,
France, 2000. p 681686.
[Dertouzos 74] Dertouzos M.L. Control robotics : the procedural control of phy-
sical processors. Proc. of IFIP Congress. 1974, p 807813.
[Dertouzos 89] Dertouzos M.L. et Mok A.K. Multiprocessor on-line scheduling
of hard real-time tasks. IEEE Transactions on Software Engineering,
Dec. 1989, vol 15(12), p 14971506.
[DiNatale 95] DiNatale M. et Stankovic A. Applicability of simulated annealing
methods to real-time scheduling and jitter control. Proc. of Real-Time
Systems Symposium, RTSS'95. Pisa, 1995. p 190199.
[Elsaadany 94] Elsaadany A. Priority communication schemes on local computer
networks for multimedia trac. Proc. of the 19th IEEE Conf. of Local
Computer Networks. 1994, p 372379.
[Gallmeister 95] Gallmeister B.O. POSIX.4 : Programming for the Real World.
O'Reilly and Associates, 1995.
[Gaudel 96] Gaudel M.C., Marre B., Schlienger F. et Bernot G. Précis
de Génie Logiciel. Editions Masson, 1996.
[Gerber 94] Gerber R., Hong S. et Saksena M. Guaranteeing end-to-end
timing constraints by calibrating intermediate processes. Proc. of
the 15nd IEEE Real-Time Systems Symposium, RTSS'94. San Juan,
Puerto Rico, December 1994. p 192203.
[Goldsmith 93] Goldsmith S. A practical guide to real-time systems development.
Prentice Hall Editions, 1993.
166 BIBLIOGRAPHIE
[Gomaa 84] Gomaa H. A software design method for real-time systems. Com-
munications of the ACM, 1984, vol 27(9), p 938949.
[Goossens 03] Goossens J. Scheduling of oset free systems. Real-Time Systems,
2003, vol 24(2), p 239258.
[Grolleau 99a] Grolleau E. Ordonnancement temps-réel hors-ligne optimal à l'aide
de réseaux de Pétri en environnement mono-processeur et multipro-
cesseur. Thèse : ENSMA - Université de Poitiers, nov. 1999.
[Grolleau 99b] Grolleau E., Choquet-Geniet A. et Cottet F. Modélisation
de systèmes temps réel par réseaux de petri autonomes en vue de
leur analyse hors-ligne. Modélisation des Systèmes Réactifs, MSR'99.
Cachan, France, 1999. p 1726.
[Grolleau 00a] Grolleau E. et Choquet-Geniet A. Cyclicité des ordonnance-
ments de systèmes de tâches périodiques diérées. Proc. of RTS'2000.
Paris, France, 2000. p 216228.
[Grolleau 00b] Grolleau E. et Choquet-Geniet A. Scheduling real-time sys-
tems by means of petri nets. Proc. of 25th Workshop on Real-Time
Programming, WRTP'00. Palma de Mallorca, Spain, 2000. p 95100.
[Gutiérrez 97] Gutiérrez J., Garcia J. et Harbour M. On the schedulability
analysis for distributed real-time systems. Proc. of the 9th IEEE Eu-
romicro Conference. Toledo, Spain, June 1997. p 136143.
[Guyenot 89] Guyenot P. et Hans T. Régulation et asservissement : Eléments
de cours, Problèmes résolues. Ed. EYROLLES, 1989.
[Han 92] Han Ching-Chih et Lin Kwei-Jay. Scheduling distance-
constrained real-time tasks. Proc. of 13th IEEE Real-Time Systems
Symposium. Phoenix, AZ, U.S.A., Dec. 1992. p 300308.
[Han 96] Han C.-C., Lin K.-J. et Hou C.-J. Distance-constrained schedu-
ling and its applications to real-time systems. IEEE Transactions on
Computers, 1996, vol 45(7), p 814826.
[Hillary 02] Hillary N. et Madsen Ken. You Can't Control what you Can't
Measure OR Why it's Close to Impossible to Guarantee Real-Time
Software Performance on a CPU with on-chip cache. 2nd International
Workshop on Worst Case Execution Time Analysis - Satellite Event
of 14th Euromicro Conference on Real-Time Systems, June 2002.
[Holte 89] Holte R.,Mok A., Rosier L., Tulchinsky I. et Varvel D. The
pinwheel : A real-time scheduling problem. Proc. of the 22nd Hawaii
International Conference on System Science. Hawaii, U.S.A., Jan.
1989. p 693702.
[Holte 92] Holte R., Rosier L., Tulchinsky I. et Varvel D. Pinwheel
scheduling with two distinct numbers. Theoritical Computer Science,
volume 100, p 105135. June 1992.
[IEEE Editions 92] IEEE Editions . The new IEEE Standard Dictionary of Electrical
and Electronics. 1992.
BIBLIOGRAPHIE 167
[Jacob 95] Jacob D. Calcul des correcteurs pid par la méthode des moments
pour les systèmes instables en boucle ouverte : Application au contrôle
d'un pendule inversé. Revue d'Automatique et de Productique Appli-
quées, 1995, vol 8(4), p 585608.
[Kim 00] Kim T., Shin H. et Chang N. Deadline assignment to reduce output
jitter of real-time tasks. Proc. of the 16th Workshop on Distributed
Computer Control Systems, DCCS'00. Sydney, Australia, Nov. 2000.
p 6772.
[Kirkpatrick 83] Kirkpatrick S., Gellatt C. D. et Vecchi M.P. Optimization
by simulated annealing. Science, 1983, vol 220, p 671680.
[Knuth 69] Knuth D. E. The art of Computer Programming, volume 2 of Se-
minumerical Algorithms. Addison-Wesley, 1969.
[Labetoulle 74] Labetoulle J. Un algorithme optimal pour la gestion des proces-
sus en temps réel. Revue Française d'Automatique, Informatique et
Recherche Opérationnelle, Fév. 1974, p 1117.
[Lehoczky 89] Lehoczky J.P., Sha L. et Ding Y. The rate monotonic scheduling
algorithm : exact characterization and average case behavior. Proc. of
the 10th IEEE Real-Time Systems Symposium, RTSS'89. Dec 1989, p
166171.
[Lehoczky 91] Lehoczky J.P., Sha L., Strosnider J.K. et Tokuda H. Fixed
priority scheduling theory for hard real time systems. Foundations of
Real-Time Computing : Scheduling and resource management, 1991,
p 130.
[Leung 80] Leung J. et Merrill M. A note on preemptive scheduling of per-
iodic real-time tasks. Information Processing Letters, 1980, vol 11(7),
p 115118.
[Leung 82] Leung J. et Whitehead J. On the complexity of xed-priority
scheduling of periodic, real-time tasks. Performance Evaluation (Ne-
therland), 1982, vol 2(4), p p. 237250.
[Lin 96] Lin K.-J. et Herkert A. Jitter control in time-triggered systems.
Proc. of the 29th International Conf. on System Sciences. Hawaiï,
U.S.A., 1996. p 451459.
[Liu 73] Liu C.L. et Layland J.W. Scheduling algorithms for mutltipro-
gramming in real-time environnement. Journal of the ACM, 1973,
vol 20(1), p 4661.
[Mok 83] Mok A.K. Fundamental design problems for the hard real-time envi-
ronments. Thèse : MIT, May 1983.
[NI 98] NI . National Instrument : BridgeVIEW And Labview : PID control
Toolkit for G. Reference Manual. National Instrument, 1998.
[Puschner 00] Puschner P. et Burns A. Guest editorial : A review of worst-case
execution-time analysis. Real-Time Systems, 2000, vol 18, p 115128.
168 BIBLIOGRAPHIE
[Puschner 02] Puschner P. Is Worst-Case Execution-Time Analysis a Non-
Problem ? Towards New Software and Hardware Architectures. 2nd
International Workshop on Worst Case Execution Time Analysis -
Satellite Event of 14th Euromicro Conference on Real-Time Systems,
June 2002.
[Redell 02] Redell O. et Sanfridson M. Exact best-case response time analy-
sis of xed priority scheduled tasks. Proc. of the 14th IEEE Euromicro
Conference. Vienna, Austria, June 2002.
[Richard 00] Richard P., Cottet F. et Kaiser C. Validation temporelle d'un
logiciel temps réel : application à un laminoir industriel. Acte de
la Conf. IEEE Inter. Francophone d'Automatique, CIFA'00. Lille,
France, 2000. p 687692.
[Richard 02] Richard P., Richard M. et Cottet F. Ordonnancement dans les
systèmes distribués, chapitre Analyse holistique des systèmes temps
réel distribués : principes et algorithmes. Hermès (A paraître), 29p,
2002.
[Ripoll 96] Ripoll I., Crespo A. et Mok A.K. Improvement in feasibility
testing for real-time tasks. Real-Time Systems, 1996, vol 11(1), p
1939.
[Rivoire 96] Rivoire M et Ferrier Jean-Louis. Cours d'Automatique, Tome
2 : Asservissement, Régulation et Commande Analogique. Ed. EY-
ROLLES, 1996.
[Sha 90] Sha L., Rajkumar R. et Lehoczky J.P. Priority inheritance pro-
tocols : an approach to real-time synchronisation. IEEE Transactions
on Computers, 1990, vol 39(9), p 11751185.
[Shannon 49] Shannon C.E. Communication in presence of noise. Proc. IRE.
volume 37, 1949, p 1021.
[Stankovic 98] Stankovic J., Spuri M., Ramamritham K. et Buttazzo G.
Deadline Scheduling For Real-Time Systems : EDF and Related Algo-
rithms, volume 460. Kluwer Academic Publishers, Boston, 1998.
[Tindell 94] Tindell K. et Clark J. Holistic schedulability analysis for distribu-
ted hard real-time systems. Microprocessing and Microprogramming
- Euromicro Journal (Special Issue on Parallel Embedded Real-Time
Systems), 1994, vol 40, p 117134.
[Törngren 98] Törngren M. Fundamentals of implementing real-time control ap-
plications in distributed computer systems. Real-Time Systems, 1998,
vol 14, p 219250.
[Wang 96] Wang H.O., Tanaka K. et Griffin M. An approach to fuzzy
control of non linear systems : Stability and design issues. IEEE
Transactions on Fuzzy Systems, 1996, vol 4(1), p 1423.
[Ward 86] Ward P.T. et Mellor S.J. Structured Development for Real-Time
Systems, volume volume 3 : Implementation Modeling Techniques.
Yourdon, Inc., Englewood Clis, New Jersey, 1986.
BIBLIOGRAPHIE 169
[White 97] White R., Mueller F., Healy C., Whalley D. et Harmon
M. Timing analysis for data caches and set-associative caches. Proc.
IEEE Real-Time Technology and Applications Symposium. June 1997,
p 192202.
[Wilner 97] Wilner D. Vx-Files : What Really Happened on Mars ? Key-
note Speech, during the 18th IEEE Real-Time Systems Symposium,
RTSS'97, 1997. D. Wilner is the Chief Technical Ocer of Wind River
Systems.
[WindRiver 99] WindRiver . VxWorksTM : Programmer's Guide. 5.4. WindRiver,
1999.
[Xu 92] Xu J. et Parnas D.L. Pre-run-time scheduling of processes with
exclusion relations on nested or overlapping critical sections. Phoenix
Conference on Computers and Communications. Phoenix, USA, Apr.
1992. p 64716479.
[Zhang 93] Zhang N., Burns A. et Nicholson M. Pipelined processors and
worst case execution times. Real-Time Systems, 1993, vol 5(4), p
319343.
[Zhou 98] Zhou L., Shin K.G. etRundensteiner E.A. Rate-monotonic sche-
duling in the presence of timing unpredictability. Proc. of the 4th
IEEE Real-Time Technology and Applications Symposium. Denver
CO, USA, 1998. p 2227.
170 BIBLIOGRAPHIE
Publications liées à ce mémoire de thèse
- David L., Grolleau E. et Constantin S. Plate-forme d'expérimentation pour l'or-
donnancement des applications temps réel à contraintes strictes, Acte de la Conf. Real
Time Systems (RTS'02), Ed. Teknea, Paris, France, 2002, p 33-46.
- David L., Cottet F. and Nissanke N. Jitter Control in On-line Scheduling of
Dependent Real-Time Tasks. Proc. of the 22nd IEEE Real-Time Systems Symposium,
RTSS'01, London, UK, December 2001, p 49-58.
- David L. et Cottet F. Traitement de la gigue de tâches dépendantes dans un
contexte d'ordonnancement temps réel en ligne, Acte de la Conf. Real Time Systems
(RTS'01), Ed. Teknea, Paris, France, 2001, p 167-187.
- David L., Cottet F. et Grolleau E. Gigue temporelle et ordonnancement par
échéance dans les applications temps réel, Acte de la Conf. IEEE Inter. Francophone
d'Automatique, CIFA'00, Lille, France, 2000, p 681-686.
- David L. et Cottet F. Traitement de la gigue temporelle de tâches périodiques dans
un contexte d'ordonnancement temps réel en ligne, Rapport Technique Numéro 00 009,
LISI-ENSMA, Futuroscope, France, 2000.
- David L. and Cottet F. A Solution to the Time Jitter Removal in Deadline Based
Scheduling of Real-Time Applications, Proc. of the Summer School MOVEP'2k, Nantes,
France, 2000, p 165-169.
- David L., Cottet F. et Grolleau E. Maîtrise de la gigue temporelle avec les
algorithmes d'ordonnancement DM et ED, Rapport Technique Numéro 00 004, LISI-
ENSMA, Futuroscope, France, 2000.
- Cottet F. and David L. A solution to the time jitter removal in deadline based
scheduling of real-time applications, 5th IEEE Real-Time Technology and Applications
Symposium - WIP, Vancouver, Canada, 1999, pp. 33-38.
172 BIBLIOGRAPHIE
Annexe A
Résolution du problème de
désynchronisation
Rappel du problème de désynchronisation
Rappelons le problème de désynchronisation, décrit dans la section 3.1.1.2, page 73 :
Soit (τ1, ..., τn) un ensemble de tâches à désynchroniser. Pour toutes les tâches τi, ondénit le paramètre Wi qui caractérise depuis les dates d'activation des instances de
τi, le délai au terme duquel, il est prévu que l'exécution de l'instance de la tâche soit
terminée. Le principe de désynchronisation des tâches revient à chercher un n-uplet
(r1,1, ..., rn,1) qui vérie :
∀(i, j) ∈ [|1;n|] i < j
ri,1 − rj,1 = 0mod(Ti ∧ Tj)et
ri,1 − rj,1 = 1mod(Ti ∧ Tj)ri,1 − rj,1 = 2mod(Ti ∧ Tj)
...ri,1 − rj,1 = Wj − 1mod(Ti ∧ Tj)
et
rj,1 − ri,1 = 1mod(Ti ∧ Tj)rj,1 − ri,1 = 2mod(Ti ∧ Tj)
...rj,1 − ri,1 = Wi − 1mod(Ti ∧ Tj)
(A.1)
où Ti et Tj sont nécessairement non premiers entre eux.
La recherche de solution à ce problème d'arithmétique peut être réalisée par l'algorithme
suivant, où tous les n-uplets, classés dans un ordre lexicographique, sont un à un vériés.
L'avantage de cette implémentation, c'est que dès lors qu'une inégalité n'est pas respectée,
le n-uplet en question est rejeté, et on examine alors le suivant dans la liste, ce qui donne
un gain de temps appréciable pour la recherche de solutions.
174 Résolution du problème de désynchronisation
Algorithme de recherche des ri,1
Pour r1,1 ∈ [|0;T1 −W1|] faire ...
Pour rn,1 ∈ [|0;Tn −Wn|]Faire:
UneInégalitéEstVraie ←− Faux
i ←− 1Tant que (i ∈ [|1;n|]) et UneInégalitéEstVraie = Faux
Faire:
j ←− i+ 1Tant que (j ∈ [|i+ 1;n|]) et UneInégalitéEstVraie = Faux
Faire:
ρi,j ←− −(Wi − 1)Tant que ρi,j ∈ [| − (Wi − 1);Wj − 1|]) et UneInégalitéEstVraie = Faux
Faire:
Si (ri,1− rj,1) = ρi,j mod(Ti ∧ Tj) Alors UneInégalitéEstVraie = Vrai
ρi,j ←− ρi,j + 1Fin Faire.
j ←− j + 1Fin Faire.
i ←− i+ 1Fin Faire.
Si UneInégalitéEstVraie = Faux Alors Retourner valeur de r1,1, r2,1, ..., rn,1Fin Faire.
...
Fin Faire.
Les n premières boucles Pour servent à faire l'énumération des diérents n-uplets(r1,1, ..., rn,1) possibles (énumération de n chires compris entre 0 et Ti−Wi avec 1 ≤ i ≤ n).La complexité résultante dans le pire cas de cette énumération est donc en Θ((maxk(Tk −Wk))
n). Le reste de l'algorithme peut ensuite se rapporter à un schéma du type :
Pour i de 1 à nPour j de i+ 1 à n
Pour ρ de −(Wi − 1) à Wj − 1...Instructions...
Fin Pour
Fin Pour
Fin Pour
où ...Instructions... est réalisée en temps constant. La complexité résultante dans le pire cas
de ce schéma est en :
n∑i=1
n∑j=i+1
2maxk(Wk)∑ρ=0
Θ(1) maxk(Wk)n∑
i=1
n∑j=i+1
Θ(1)
n2
2maxk(Wk)
175
La complexité résultante dans le pire cas pour l'algorithme de recherche proposé est donc
en :
Θ(n2(maxk(Tk −Wk))
n)maxk(Wk)). (A.2)
Le temps de résolution de l'algorithme dans le pire cas dépend de manière exponentielle de
la quantité maxk(Tk −Wk), et dépend de manière polynomiale de n et de maxk(Wk).
176 Résolution du problème de désynchronisation
Annexe B
Etude mécanique du pendule inversé
Dans cette étude, nous désignons par Sc le solide correspondant au chariot et nous
appelons Gc son centre de gravité. Le pendule est quant à lui désigné par Sp, et son centre degravité par Gp. La masselotte, xée sur le pendule, est désignée par Sm, ou plus simplement
par m, qui représente aussi la masse, et que nous considérons comme ponctuelle (Gm m).On désigne par mc la masse du chariot, par mp la masse du pendule (la tige) et par m, lamasse de la masselotte. On suppose que le pendule est de longueur L, et on désigne par
l, la distance séparant la masselotte du point de libre rotation du pendule. On dénit par
ailleurs un repère de référence T0(0, x0, y0, z0) dans lequel le chariot peut se mouvoir suivant
l'axe (Oy0) (cf. gure B.1). Le solide Sc peut se mouvoir en eet suivant une liaison linéaire
(rail), tandis que le solide Sp est en liaison pivot par rapport à Sc.
Fig. B.1: Description schématique du système à étudier.
On introduit enn les repères T1(Gc, x0, y0, z0) et T2(Gc, x0, y1, z1), liés respectivement
aux solides Sc et Sp. Le repère T2 est en fait l'image du repère T1 par la rotation d'angle
θ autour de l'axe (Gc; x0) (cf. gure B.2). A noter que nous avons implicitement introduit
le repère T0(G0, x0, y0, z0) qui forme le repère absolu dans lequel nous allons exprimer la
cinématique des solides Sc, Sp et Sm.Cette rotation peut en outre être dénie plus formellement par les relations suivantes :
−→y0 = cosθ−→y1 − sinθ−→z1
178 Etude mécanique du pendule inversé
Fig. B.2: Repères T1 et T2 liés aux solides Sc et Sp.
−→z0 = sinθ−→y1 + cosθ−→z1
B.1 Détermination des équations selon le principe des
puissances virtuelles et des équations de Lagrange
Pour déterminer les équations régissant le pendule, nous allons utiliser le principe des
puissances virtuelles et les équations de Lagrange [BÔNE 94]. Les équations de Lagrange
relient l'énergie cinétique du système à la puissance des actions extérieures exercées sur
le système et à la puissance des actions mutuelles exercées entre les solides constituant
le système. Les puissances de chaque eort exercées sur et dans le système sont calculées
suivant le principe des puissances virtuelles, qui dénit une puissance sur la base d'un
paramètre du mouvement du système (ici y et θ). Dans une première étape, il s'agit de
dénir la cinématique des trois solides Sc, Sp etm. En désignant par y la distance algébrique
entre le point 0 et le centre de gravité Gc du solide Sc, on a :−−→OGc = y−→y0 , la cinématique
de Sc est donc :
Sc
∣∣∣∣ V0(Gc) = y′−→y0Ω0(Sc) =
−→0
S'agissant de la cinématique de Sp, il convient juste de remarquer la rotation de Sp par
rapport Sc, il vient alors : V0(Gp) = V0(Gc) + Ω0(Sp)ΛGcGp, ce qui conduit à V0(Gp) =y′−→y0 + θ′−→x0Λ
L2−→z1 , puisque Ω0(Sp) = θ
′−→x0. Finalement, on obtient la cinématique suivante
pour le solide Sp :
Sp
∣∣∣∣ V0(Gp) = y′−→y0 − L2θ′−→y1
Ω0(Sp) = θ′−→x0
(En théorie pour les calculs, nous devrions prendre en compte l'écart qui peut exister
entre le point de libre rotation du solide Sp, et le centre de gravité du solide Sc, mais les
cinématiques étant les mêmes pour ces deux points, et le produit vectoriel combiné avec une
rotation de Sp suivant l'axe (Gc; 0x0), nous conduisent nalement aux mêmes résultats.)
Pour la masselotte, nous obtenons sur le même principe :
Sm
∣∣∣∣ V0(Sm) = y′−→y0 − lθ′−→y1
Ω0(Sm) =−→0
B.1 Détermination des équations selon le principe des puissances virtuelles et
des équations de Lagrange 179
L'énergie cinétique K0(S = Sc ∪ Sp ∪ Sm) qui se décompose en trois termes :
2K0(Sc ∪ Sp ∪ Sm) = 2K0(Sc) + 2K0(Sp) + 2K0(Sm)
peut alors être décrite par :
2K0(Sc) = mcy′2
2K0(Sp) = mp(V0(Gc))2 + Ω0(Sp).
=
I (Sp, Gp)Ω0(Sp)
2K0(Sm) = m(V0(m))2
où=
I (Sp, Gp) est le tenseur d'inertie du solide Sp, qu'on exprime dans le repère (Gp, x0, y1, z1).On a ainsi :
=
I (Sp, Gp) =
mp
L2
30 0
0 mpL2
30
0 0 0
(x0,y1,z1)
On obtient nalement l'expression suivante pour l'énergie cinétique :
2K0(S) = mcy′2 +mp
[(y′cosθ − L
2θ′)2 + (y′sinθ)2
]+[
mpL2
3
]θ′2 +
m[(y′cosθ − lθ′)2 + (y′sinθ)2
]soit,
2K0(S) = (mc +mp +m)y′2 +
[mp
7L2
12+ml2
]θ′2 − [mpL+ 2ml] cosθy′θ′
Après utilisation du principe des puissances virtuelles, les deux équations de Lagrange sont
données par :
Ly :d
dt
∂K0(S)
∂y′− ∂K0(S)
∂y= Qy
Lθ :d
dt
∂K0(S)
∂θ′− ∂K0(S)
∂θ= Qθ
où Qy et Qθ représentent les puissances virtuelles des actions exercées sur le système S,selon les paramètres de Lagrange y et θ. Elles valent respectivement Qy = λ(t) (force fourniepar le moteur au système (seule action considérée, on néglige en eet les frottements)), et
Qθ =[mp
L2
+ml]g sinθ (action de la pesanteur sur Sp et Sm, pas de frottements). On
pourrait pour information, modéliser les frottements rail-chariot par les 3 termes classiques
suivants : −kvy′ + kssgn(y′) + kdsgn(y′)exp(−|y′|/δ), où le premier terme correspond à des
frottements visqueux, le deuxième terme correspond à des frottements secs1, et le troisième
1sgn(y′) est une fonction qui vaut 0 quand y′ = 0, −1 quand y′ < 0, et 1 quand y′ > 0.
180 Etude mécanique du pendule inversé
terme à la force de décollement (qui représente la diérence entre les frottements statiques
et dynamiques, c'est-à-dire la force initiale qu'il faut donner au chariot en position statique,
pour qu'il ait un mouvement). On pourrait également sur le même principe modéliser les
frottements au niveau de l'axe de rotation par une relation mettant en jeu ces 3 termes. En
écartant au nal tous ces frottements et en menant le calcul à son terme, on obtient :
Ly : (mc +mp +m)y′′ +[mpL
2+ml
](sinθ θ′2 − cosθ θ′′) = λ(t) (B.1)
Lθ :
[mp
7L2
12+ml2
]θ′′ −
[mpL
2+ml
]cosθ y′′ =
[mpL
2+ml
]g sinθ (B.2)
D'un point de vue pratique, on peut distinguer deux phases dans l'utilisation du pendule
inversé, une phase transitoire durant laquelle le mouvement du chariot conduira à l'envoi
du pendule dans la position inversé avec une vitesse angulaire minimum, et une phase
permanente pendant laquelle le pendule restera en équilibre (instable) autour de sa position
inversée. Dans cette dernière phase, on pourra se mettre dans l'hypothèse des "petits angles"
(|θ| 1).A noter que dans le cadre de cette hypothèse, si on se met dans la situation du pendule
en position directe (changement de variable θ→ θ+π), et si on supprime les mouvements du
chariot suivant (0y0), on retrouve la formule classique du pendule d'Euler, qui représente desoscillations du pendule autour de sa position d'équilibre, la position verticale descendante.
B.2 Détermination des contraintes de temps à respecter
Contrainte temporelle liée aux butées
Pour cette contrainte, on souhaite que le chariot arrivant sur les butées physiques à
vitesse maximale, ne soit plus entraîné par le moteur (seule son inertie (et celle des rotors
du moteur...) pourra entraîner un "choc" avec les butées). On dispose pour cela de capteurs
de butées mécaniques disposées aux deux extrémités du rail, et qui sont distantes de 8cmdes butées physiques. La vitesse maximale du chariot déterminée expérimentalement est de
2 ∼ 3m/s (le rail supporte au maximum, des vitesses de l'ordre de 10m/s). En ce plaçant
dans une fourchette haute, le temps de parcours d'une distance de 8cm, par le chariot animé
d'une vitesse de ∼ 3m/s est de :
T =distance
vitesse=
8.10−2
3 26ms (B.3)
Soulignons cependant le caractère expérimental, et donc approximatif, de la détermination,
qui dépend par exemple de la raideur de la courroie (température, durée d'utilisation dans
la journée, etc.), mais qui permet d'obtenir un ordre de grandeur. Nous avons au nal choisi
de prendre une durée T de 25ms.
Lorsqu'il y a détection par une butée mécanique du chariot, il faut qu'au pire 25msplus tard, le moteur ne soit plus alimenté.
B.2 Détermination des contraintes de temps à respecter 181
Contrainte temporelle liée à la chute du pendule par rapport à la
puissance nie du moteur et de son inertie
Nous souhaitons déterminer le temps critique tc au delà duquel, la chute du pendule ne
peut pas être rattrapée par le moteur. Nous nous plaçons pour cela dans les hypothèses
d'une accélération quasiment nulle du chariot (y′′ 0), et d'un angle "critique" θc faible, cequi nous permet de formuler l'hypothèse des "petits angles". L'équation B.2 nous conduit
alors à l'expression suivante :
Aθ′′ −Bgθ = 0
où A = cste =[mp
7L2
12+ml2
], et B = cste =
[mp
L2
+ml]. La résolution de cette équation
diérentielle nous conduit à l'expression de θ suivante :
θ(t) = exp(−t/τ)
avec τ =√A/(Bg) qui vaut 0,12s, calculée grâce aux données demp = m = 20g, L = 15cm,
l = 2cm, et g = 9,8m/s2.
Dans le cadre de ces hypothèses, l'équation B.1 nous conduit à :
B
τ 2exp
(− tτ
)[exp
(−2t
τ
)− 1
]= λ
Expérimentalement, on peut déterminer la force maximale λmax qui va être exercée sur le
chariot par le moteur. Nous supposons enn que cette force maximale coïncidera également
avec l'angle critique θc (ce qui est le cas si la régulation est bien réalisée : à l'angle critique,
la loi de commande demandera "son" maximum au moteur pour redresser le pendule). La
valeur de tc est alors donnée par la résolution de l'équation en tc suivante :
B
τ 2exp
(−tcτ
)[exp
(−2tcτ
)− 1
]= λmax
ce qui conduit à étudier la fonction f dénie par : f(x) = Bτ2 exp(x)(exp(2x)−1)−λmax . Après
étude et applications numériques, on trouve une valeur de 16ms. A titre de comparaison,
lors des essais sous LabviewTM , nous avions une cadence sur la commande en sortie de carte
de 5 ∼ 6ms. On est donc dans le même ordre de grandeur et nous avons nalement choisi
de prendre une constante de temps de 10ms.
Lorsqu'à accélération quasi nulle, le pendule chute dans un sens ou dans un autre,
il faut que le moteur donne son accélération maximum 10ms au plus tard, après le
début de sa chute.
182 Etude mécanique du pendule inversé
Annexe C
Présentation de VxWorksTM et de son
EDI TornadoTM
Les principaux systèmes d'exploitation du marché (UNIX, Windows, etc.) sont bien
adaptés aux développement de programmes et à de nombreuses applications interactives.
Cependant, lorsqu'il s'agit d'exécuter des applications temps réel où la correction tempo-
relle s'ajoute à la correction algorithmique, ils s'avèrent beaucoup moins ecaces, voire
inadaptés. Les sociétés commercialisant des OS temps réel fournissent alors en général un
environnement de développement (EDI), tournant sur les systèmes d'exploitation classiques
(Windows, UNIX, etc...), et permettant de développer des applications temps réel pour leur
propre OS temps réel. C'est ce que propose la société WindRiverTM avec son ensemble
Tornado/VxWorksTM qui est composé d'une part de l'environnement de développement
(EDI) TornadoTM et d'autre part du système d'exploitation temps réel VxWorksTM . On
utilise ainsi les avantages des deux types de système d'exploitation en permettant de fournir
un puissant et convivial outil de développement, et en permettant la maîtrise des aspects
grâce à l'OS temps réel.
Dans cette annexe, nous décrivons dans un premier temps les caractéristiques de l'OS
temps réel VxWorksTM , puis dans un deuxième temps, nous donnons une description du
principe de développement d'une application temps réel sous Tornado/VxWorksTM .
C.1 Caractéristiques de VxWorksTM
VxWorksTM , comme la majorité des systèmes d'exploitation temps réel du marché, est
certié POSIX (Portable Operating System Interface, le X représentant UNIX), assurant
alors l'implémentation dans son noyau de bibliothèques standardisées, en vue de faciliter le
portage d'application d'un système d'exploitation à l'autre. Dans la pratique, il faut cepen-
dant explicitement déclarer les composants comme répondant à la norme POSIX. En outre,
cette certication ne garantissant pas un fonctionnement eectivement temps réel (Linux,
NT, Mac OS X,...), WindRiver fournit des temps de réponses étalons (BenchMark) qui
sont garantis dans des conditions matérielles et logicielles spéciques, permettant ainsi de
valider a priori les applications temps réel. Les primitives POSIX proposées parWindRiver
sont nalement toujours doublées par des primitives VxWorksTM , qui sont en général plus
184 Présentation de VxWorksTM et de son EDI TornadoTM
souples d'utilisation car orant plus de paramètres de conguration (par exemple, pour les
sémaphores, la gestion de PHP est possible).
Ces certications et ces garanties s'accompagnent d'une grande modularité : les fonc-
tionnalités du noyau temps réel sont en eet congurables à loisir via l'outil appelé BSP
(board support package), fournissant alors une large palette de possibilités pour la gestion
de la cible (commandes Shell, drivers, etc...).
Gestion des tâches. VxWorksTM est un noyau temps réel qui permet l'exécution concur-
rente de plusieurs tâches suivant un algorithme d'ordonnancement préemptif basé sur les
priorités. Chaque tâche de l'application et du noyau temps réel peut passer par cinq états
diérents, elle peut être
• endormie, ou inactive (on parle aussi de tâche suspendue) : elle attend alors son acti-
vation,
• prête à être exécutée, elle n'attend alors que la ressource processeur,
• retardée pour une certaine durée,
• bloquée pour cause de non disponibilité d'une ressource,
• ou en cours d'exécution.
L'enchaînement de ces états et l'action associée au passage d'un état à l'autre sont reportés
dans la gure C.1. Dans cette gure, les transitions désignées par "Abandon" et par les
èches en pointillés, sont spéciques à VxWorksTM , et sont accessibles via les routines
taskSuspend() et taskResume(). Ces routines peuvent être appelées par une tâche de plus
grande priorité (une tâche d'ordonnancement par exemple) ou peuvent être appelées après le
réveil d'un chien de garde dont le délai (timeout) aurait expiré. Ces transitions particulières
doivent faire l'objet d'une grande attention, car elles sont en dehors des schémas classiques
de l'ordonnancement des tâches, rendant plus dicile la phase de validation.
Sous VxWorksTM , quand une tâche est créée, elle est dans l'état endormie. Lorsqu'elle
est activée, elle passe alors dans l'état prête, et attend son aectation au processeur. L'ins-
truction VxWorksTM taskSpawn() permet de créer une tâche et de l'activer. Lorsque les
ressources demandées par une tâche sont indisponibles, la tâche passe alors par l'état blo-
quée. L'état retardée est quant à lui obtenu avec l'instruction taskDelay(n) où n représente
le nombre de ticks VxWorksTM que la tâche considérée devra laisser passer avant de se
réveiller. VxWorksTM permet également certaine combinaison pour ces états : une tâche
peut par exemple être bloquée et endormie, etc. A noter que les temps de changement de
contexte mettant en jeu 2 états dont celui "en cours d'exécution" sont généralement en
deçà de la micro seconde.
L'algorithme d'ordonnancement par défaut utilisé par VxWorksTM est un algorithme
préemptif basé sur les priorités aectées à chaque tâche : c'est la tâche de plus forte priorité
à qui est attribué le processeur. 256 niveaux diérents de priorité sont possibles et doivent
par défaut être précisés lors de la création de la tâche. L'ordre d'aectation des priorités
est par contre l'inverse de celui de la norme POSIX : plus le nombre est faible, plus la
priorité est grande. La priorité d'une tâche peut par ailleurs être changée pendant la phase
d'exploitation an d'implémenter par exemple une méthode d'ordonnancement à priorité
variable. Enn, plusieurs tâches de même priorité peuvent être dans l'état prête en même
temps. Dans ce cas, elles sont placées dans une le d'attente dont la gestion est du type
C.1 Caractéristiques de VxWorksTM 185
PEPS (FIFO) ou tourniquet (Round-Robin), cette dernière gestion permettant ainsi d'éviter
que le processeur ne soit accaparé que par une tâche de longue durée, au détriment d'une
tâche de courte durée. Pour vérier quelle politique est utilisée dans les les d'attente, on
peut utiliser la primitive sched_getscheduler() de la bibliothèque de fonction sched.
Communications. Le mécanisme de préemption des tâches peut être désactivé en uti-
lisant l'instruction taskLock(), permettant par exemple de gérer les problèmes d'exclusion
mutuelle. Cette instruction empêche une autre tâche de venir préempter la tâche en cours
d'exécution, mais n'interdit pas à des routines d'interruption de s'exécuter. Il est également
possible d'interdire ces routines d'interruption en les masquant : c'est alors la méthode la
plus puissante pour assurer un accès exclusif. Il faut cependant éviter cette méthode dans
le développement d'une application temps réel, car elle empêche le système de répondre à
des événements extérieurs.
Les sémaphores restent les outils privilégiés pour la gestion d'accès à des ressources en
exclusion mutuelle, et pour la synchronisation entre les tâches. Trois types de sémaphores
sont proposés dans VxWorksTM :
• les sémaphores binaires qui permettent de gérer simplement l'exclusion mutuelle ou la
synchronisation entre les tâches (SemBCreate()),
• les sémaphores d'exclusion mutuelle (SemMCreate())1 qui permettent par exemple la
gestion de PHP (protocole à héritage de priorités) et la gestion de la suppression d'une
tâche lorsqu'elle est dans sa section critique (suppression diérée),
1C'est d'ailleurs la non utilisation de ce sémaphore qui a conduit à un incident sur la mission PathFinder .
Fig. C.1: Les états possibles des tâches et les transitions entre ces états.
186 Présentation de VxWorksTM et de son EDI TornadoTM
• et les sémaphores "à mémoires" (counting semaphores : SemCCreate()) qui généralisent
les sémaphores binaires, en gardant en mémoire le nombre de fois où le sémaphore a été
pris.
Outre l'utilisation de mémoires partagées protégées par des sémaphores, VxWorksTM
permet de gérer les communications inter-tâches par boîte aux lettres. La gestion des mes-
sages dans la boîte peut se faire suivant une politique PEPS (FIFO) ou suivant des priorités.
Des délais critiques peuvent en outre être dénis (timeout). La primitivemsgQCreate() crée
une boîte aux lettres de taille à dénir, la primitive msgQSend() permet l'émission d'un
message dans la boîte aux lettres2, et enn la primitive bloquante msgQReceive() permet
le blocage de la tâche appelante jusqu'à réception d'un message dans la boîte aux lettres.
Gestion du temps. Pour la gestion du temps, VxWorksTM se réfère à l'horloge de l'or-
donnanceur qui génère régulièrement un tick ordonnanceur selon une période qui ne doit
pas descendre en dessous de 1ms, sans quoiWindRiverTM ne garantit plus la stabilité de son
système. En eet, en deçà de cette limite, on considère que le système passe plus de temps
à exécuter les interruptions systèmes (par exemple, celle qui génère le tick), qu'à exécuter
le code des tâches. De manière générale, la norme POSIX préconise d'avoir une période
de tick de 10 à 20 ms. Les primitives de consultation ou de modication de la fréquence
des ticks sont sysClkRateGet() et sysClkRateGSet()3. Les primitives sysTimestampFreq()
et sysTimestampPeriod() permettent quant à elles d'indiquer respectivement la fréquence
processeur en nombre de cycles processeurs en une seconde et d'indiquer le nombre de cycles
processeurs existant entre deux ticks successifs de l'ordonnanceur VxWorksTM .
Basée sur cette référence temporelle, l'instruction taskDelay(n)4 déjà évoquée ci-dessus
est une instruction VxWorksTM qui est incluse dans les tâches lorsqu'on souhaite la rendre
périodique : la tâche est en eet réactivée au nième ticks après l'invocation de l'instruction.
VxWorksTM fournit également des "chiens de gardes" (watchdogs) qui permettent de
générer une interruption lorsqu'il y a expiration d'un délai critique (timeout). Les routines
de gestion des chiens de garde sont les suivantes : wdCreate(), wdStart(), wdCancel() et
wdDelete().
Il existe enn des outils permettant de mesurer la durée d'exécution d'une fonction ou
d'une suite d'instructions. Il y a par exemple les fonctions de la bibliothèque TimexLib()
qui peuvent donner les durées d'exécution avec un pourcentage d'erreur. Pour certains
processeurs, dont l'Intel pentium III que nous avons utilisé, il existe aussi un compteur qui
s'incrémente à chaque top d'horloge, permettant ainsi de déterminer la durée en cycles CPU,
d'une suite d'instructions. Dans le cas du processeur Intel pentium III, ce compteur est de 64
bits. On a accès à ce compteur via les fonctions pentiumTscGet64() ou pentiumTscGet32()
de la bibliothèque de fonctions pentiumALib.
Gestion des interruptions. Les mécanismes d'interruption matériels de VxWorksTM
permettent au système de répondre rapidement à des événements extérieurs. VxWorksTM
autorise pour cela l'association d'une routine de service à une interruption (ISR : interrupt
2L'émission peut être bloquante si la boîte aux lettre est pleine (cf. [WindRiver 99]).3La fonction POSIX équivalente est la primitive clock_setres().4La fonction POSIX équivalente est la primitive nanosleep().
C.1 Caractéristiques de VxWorksTM 187
service routine). Cette routine de service fait appel au code d'une fonction, dont la pro-
grammation doit respecter certaines règles (éviter par exemple de générer un blocage dans
l'exécution, en préférant libérer un sémaphore, plutôt que de le prendre). De retour de la
fonction, le contexte d'avant l'interruption est ensuite repris (conguration précédente des
piles et des registres). La gestion par exemple du tick ordonnanceur est réalisée par une
interruption.
Une seule pile est dénie pour toutes les interruptions, il faut donc porter une atten-
tion particulière aux interruptions imbriquées. D'un point de vue pratique, la primitive
intContext() permet de déterminer si nous sommes dans un contexte de gestion d'une in-
terruption, ou non, et les primitives intLock(), intUnLock() permettent d'autoriser ou non
les interruptions (principe du masquage et du démasquage d'interruptions).
Détails de quelques primitives utilisées.
• La primitive de création d'une tâche et de son activation est décrite par :
int taskSpawn(char * name, int priority, int options, int stackSize, FUNCPTR
entryPt, int arg1, int arg2, int arg3, int arg4, int arg5, int arg6, int arg7, int
arg8, int arg9, int arg10)
où name est le nom donné à la tâche, priority sa priorité, options, les options d'exécution
(par exemple VX_FP_TASK (0x0008) exécute la tâche avec le support du co-processeur
à virgule ottante, VX_UNBREAKABLE (0x0002) interdit les points d'arrêt lors du
débogage, etc.), stackSize est la taille de la pile nécessaire à la tâche et au stockage de
son nom, entryPt est le nom de la fonction (le code de la tâche) associée à la tâche, et
enn, arg1...arg10 sont les paramètres possibles pour la fonction associée.
• La primitive de création et d'initialisation d'un sémaphore en exclusion mutuelle est
décrite par :
SEM_ID semMCreate ( int options )
où SEM_ID est un identiant pour le sémaphore, et options les options proposées par
WindRiverTM pour ce type de sémaphore :
- SEM_Q_PRIORITY (0x1) ordonne les tâches en attente selon leur priorité,
- SEM_Q_FIFO (0x0) ordonne les tâches en attente selon une politique PEPS (FIFO),
- SEM_DELETE_SAFE (0x4) protège la tâche d'une suppression non attendue (sup-
pression alors diérée),
- SEM_INVERSION_SAFE (0x8) protège le système d'une inversion de priorité (à
utiliser avec l'option SEM_Q_PRIORITY (0x1))
• La primitive de création et d'initialisation d'un sémaphore binaire est décrite par :
SEM_ID semBCreate( int options, SEM_B_STATE initialState )
où SEM_ID est un identiant pour le sémaphore, et options représente les options de
gestion de la le suivant les priorités (SEM_Q_PRIORITY (0x1)) ou suivant l'ordre
d'arrivée (SEM_Q_FIFO (0x0)), et enn, où initialState représente l'état initial du
sémaphore, soit pris (SEM_FULL (1)) soit libre (SEM_EMPTY (0)).
• La primitive de prise d'un sémaphore est décrite par :
STATUS semTake(SEM_ID semId, int timeout)
188 Présentation de VxWorksTM et de son EDI TornadoTM
où SEM_ID est l'identiant du sémaphore, et où timeout représente un nombre de ticks
à attendre ou représente soit l'option WAIT_FOREVER (-1) ou l'option NO_WAIT
(0), qui permettent respectivement d'attendre indéniment ou non le sémaphore.
Implémentation d'une boîte aux lettres sous VxWorksTM avec synchronisation
Illustrons dans ce paragraphe, la mise en place d'une boîte aux lettres utilisée pour trans-
mettre un message d'une tâche à une autre. Nous nous servons pour cela de l'exemple
développé dans le chapitre 5, qui concerne une application temps réel de contrôle d'une
pendule en position inversée. Dans cette application, on utilise une boîte aux lettres pour
transférer la donnée "tension calculée" de la tâche t_PID vers la tâche t_Moteur, il y a
par ailleurs synchronisation entre les deux tâches à l'aide d'un sémaphore privé.
Structure de données Nous devons d'abord dénir une structure de données, qui modé-
lisera la boîte aux lettres contenant un ottant (double). Cette structure de données est
dénie par (langage C) :
typedef struct _d_bal
SEM_ID mutex ;
SEM_ID libere ;
unsigned char plein ;
double val ;
d_bal ;
où mutex sera un sémaphore en exclusion mutuelle, libere un sémaphore binaire qui
permettra la synchronisation (sémaphore privé), plein un booléen qui précisera si la boite
aux lettres est pleine (en fait qui précisera, si le sémaphore binaire est pris ou non), et val
sera le message à transférer (ottant, double précision). A noter que le principe d'utiliser
la variable pleine pour connaître l'état du sémaphore binaire représente la solution que
nous avons adoptée, car à notre connaissance, l'état d'un sémaphore peut être aché à
l'écran (semShow())5, mais pas exploité directement en tant que variable (c'est le cas
du moins avec la bibliothèque semLib des sémaphores de VxWorksTM . Nota Bene : une
possibilité consisterait à lire la donnée associée au pointeur vers l'objet sémaphore, mais
ceci n'est pas conseillé, SEM_ID doit en eet être vu comme un objet et non comme
un pointeur vers un objet sémaphore (WindRiverTM pourrait par contre fournir une
méthode (un sélecteur) permettant la lecture de l'objet privé correspondant à l'état du
sémaphore).
Initialisation Cette boîte aux lettres doit ensuite être initialisée, ce sera réalisée par la
fonction suivante :
void init_d_bal(d_bal * b)
b->mutex = semMCreate(SEM_Q_PRIORITY | SEM_INVERSION_SAFE) ;
b->libere = semBCreate(SEM_Q_PRIORITY, SEM_EMPTY) ;
b->plein = 0 ;
5Attention cependant, les sémaphores étant des objets dynamiques, l'information achée peut être déjà
fausse...
C.2 Le développement d'applications temps réel avec Tornado/VxWorksTM189
où le sémaphore binaire, d'exclusion mutuelle et la boîte aux lettres sont par défaut
positionnés sur vide.
Envoi d'un message La tâche t_PID enverra un message dans la boîte aux lettres via
la fonction suivante :
void envoyer_d_bal(d_bal * b, double v)
semTake(b->mutex,WAIT_FOREVER) ;
if (b->plein == 0)
b->val = v ;
b->plein = 1 ;
semGive(b->libere) ;
semGive(b->mutex) ;
où la primitive semTake() prend possession du sémaphore d'exclusion mutuelle, b->val
= v ; envoie la valeur de v passée en paramètre vers la case mémoire du sémaphore d'ex-
clusion mutuelle. La condition if permet quant à elle de préciser que la boîte aux lettres
devient pleine et que nous pouvons alors libérer le sémaphore libere pour la synchroni-
sation.
Réception d'un message La primitive d'attente et de réception du ottant par la tâche
t_Moteur est quant à elle décrite par :
void attendre_d_bal(d_bal * b, double * v)
semTake(b->libere,WAIT_FOREVER) ;
semTake(b->mutex,WAIT_FOREVER) ;
v = b->val ;
b->plein = 0 ;
semGive(b->mutex) ;
où les deux primitives semTake() prennent possession des sémaphores libere et mutex, le
premier servant à la synchronisation, et le second à l'accès à la variable val. Une fois la
variable récupérée, on indique que la boîte aux lettres est vide et on rend le sémaphore
de synchronisation.
C.2 Le développement d'applications temps réel avec
Tornado/VxWorksTM
TornadoTM permet de développer sur une machine dite hôte ou serveur, une application
temps réel fonctionnant sur une machine cible et s'exécutant sur le système d'exploitation
VxWorksTM . Le développement d'applications temps réel passe ainsi par trois étapes :
• une phase de conguration du noyau temps réel VxWorksTM qu'il faut adapter aux
spécicités du matériel retenu,
• une phase d'implémentation de l'application temps réel en C ou en C++ dans l'envi-
ronnement TornadoTM ,
190 Présentation de VxWorksTM et de son EDI TornadoTM
• et enn, une phase de test et de débogage de l'application temps réel mettant en jeu
les communications entre la cible et le serveur.
Ces communications entre la cible et le serveur sont très importantes dans ce type de
développement (cross-development). Elles permettent en eet de fournir des outils très puis-
sants en terme de validation et de débogage. Cette validation est d'autant plus importante
que les programmes temps réel gèrent le plus souvent des procédés sensibles pour lesquels
la correction algorithmique et temporelle sont des paramètres primordiaux.
Nous verrons donc dans les paragraphes suivants une description des avantages de ces
communications et leur principe général de mise en place, puis nous verrons les diérentes
étapes à suivre pour créer un noyau VxWorksTM , dialoguant avec le serveur pour faciliter
la phase de validation.
C.2.1 Les communications cible-serveur : généralités
Avantages
Outre la facilité de transfert, vers la machine cible, des programmes développés sous
TornadoTM , les communications cible-serveur permettent de disposer d'un ensemble d'ou-
tils d'assistance au développement : possibilité d'avoir le Shell du noyau temps réel sur la
machine hôte (clavier azerty, copier coller, etc.), possibilité de chargement en ligne de nou-
velles tâches temps réel qu'on aurait à rajouter à l'application, possibilité de construction
de chronogrammes pour plusieurs tâches via l'outilWindView (validation temporelle), outil
facilitant le débogage (validation algorithmique), etc.
Principe général de mise en place
Pour établir les communications cible-serveur, un certain nombre de caractéristiques
doivent être précisées. En outre, diérents outils, propre à TornadoTM ou à VxWorksTM
doivent être mise en route. Décrivons le principe de ces communications.
Les communications cible-serveur sont en fait réalisées par l'intermédiaire de deux in-
terfaces que sont le Target Agent et le Target Server qui, d'une part, dialoguent entre eux,
et qui, d'autre part, dialoguent respectivement avec le noyau et l'environnement de déve-
loppement TornadoTM (cf. gure C.2). Dans une première étape, la machine cible va se
connecter sous protocole FTP à un serveur FTP préalablement démarré sur la machine
hôte. Le noyau temps réel complet, et éventuellement l'application temps réel réalisée, se-
ront alors chargés sur la machine cible. Le noyau chargé, il sera exécuté (boot). L'exécution
s'accompagnera alors (si congurée comme telle) par la mise en route de ce qui est appelé le
Target Agent et qui a donc pour rôle de gérer les communications cible-serveur, côté cible.
Son pendant, côté serveur, s'appelle le Target Server qui doit être conguré pour la cible
et être mis en route avant que les outils de l'hôte n'interagissent avec la cible.
Cette conguration est aussi réalisable en remplaçant la cible par un outil de simulation
disponible sur la machine hôte (présence d'un shell et d'un Target Agent spéciques6...).
6A noter que cet outil de simulation n'est disponible que sous NT, et qu'il faut disposer, lorsque l'ap-
plication est conséquente, d'une machine puissante.
C.2 Le développement d'applications temps réel avec Tornado/VxWorksTM191
Cela permet alors de développer l'application temps réel et de voir plus vite le résultat
d'une modication d'une ligne de code (pas de chargements, parfois longs...).
Ce principe de communication via le Target Agent et le Target Server peut n'être utilisé
qu'en phase de développement car il prend bien sûr des ressources processeurs sur la cible.
Aussi, la mise en route du noyau temps réel et de son application peut s'eectuer sans cette
communication. Dans ce cas, l'ensemble du noyau et l'application seront téléchargés sur
la cible et l'exécution sera alors autonome. Ces communications peuvent néanmoins être
réglées plus nement en choisissant la façon dont le Target Agent dialogue avec son noyau
temps réel (au travers d'une simple tâche par exemple de faible priorité...).
Fig. C.2: Communications cible-serveur.
C.2.2 Création d'un noyau VxWorksTM et mise en place des com-
munications cible-serveur
Plusieurs solutions sont possibles pour le chargement du noyau temps réel sur la ma-
chine cible (boot réseau, boot total sur disquette, disque dur, etc...). Nous avons adopté
l'approche suivante : création dans un premier temps d'une version légère du noyau temps
réel incluant un outil de téléchargement (appelé VxLoader et gérant le protocole FTP) que
nous implantons sur la machine cible à l'aide d'une disquette d'amorçage, puis dans un se-
cond temps, téléchargement via le réseau d'un noyau temps réel complet et de l'application
développée.
Nous allons voir dans les deux prochains paragraphes, une description des étapes à
réaliser pour charger le noyau complet et préparer la communication cible-serveur.
Création d'une disquette de bootVxLoader
Nous rassemblons tout d'abord les caractéristiques matérielles de la cible qui vont servir
à congurer les chiers à compiler. Les chiers les plus importants sont les chiers cong.h
qui sont présents dans les répertoires \Tornado\target\cong\<type cible>\ où<type cible>
est le type de processeur pour l'ordinateur cible (pcPentiumPro dans notre cas).
192 Présentation de VxWorksTM et de son EDI TornadoTM
ETAPE 1 Dans les chiers cong.h, un certain nombre de modications sont à eectuer
pour s'adapter à la cible prévue. En l'occurrence, nous utilisons comme cible un processeur
considéré comme un pentiumPro avec une carte réseau ISA 3Com Etherlink III. Décrivons
alors brièvement les lignes à modier dans le chier cong.h correspondant. Dans le début
de ce chier, on trouve la ligne de commande qui sera par défaut lancée lors du démarrage
par disquette. Elle permettra de venir télécharger sous protocole FTP, le noyau complet
VxWorksTM , ainsi que l'application temps réel développée. Cette ligne de commande peut
être décrite par 7 :
"<support de boot du noyau complet> (<numéro du périphérique>, <nombre processeur>)
<adresse IP de l'hote> : <chemin d'accès au répertoire de compilation du noyau du pro-
jet>/<nom du noyau> h=<adresse IP de l'hote> e=<adresse IP de la cible> :00 8 g=
<adresse IP de la passerelle> u=<nom de login> pw=<password> f=<option de boot>
tn=<nom de la cible>"
Voici un exemple de ligne de commande issu du projet du pendule :
"elt(0,0)193.55.163.116 : d : /Pendule/default /vxWorks h= 193.55.163.116 e= 193.55.163.123 :
00 g= 193.55.163.254 u= pc-cible pw= pc-cible f= 0x0 tn= pc-cible"
elt correspondant en fait à la désignation de la carte réseau 3COM. Dans la partie /* Net-
work driver options */ du chier cong.h, il faut également préciser les caractéristiques
réseaux (ne pas charger par exemple les drivers pour les entrées/sorties séries, ni ceux pour
les entrées/sorties parallèles, etc.). Ceci est réalisé par les instructions #dene et #undef,
et par un choix particulier des paramètres. Par exemple, dans notre projet, nous avons une
carte réseau dont l'adresse de base est en 0x300, et dont l'interruption est sur int10 (infor-
mations qui peuvent être gées et obtenues sous MS-DOS par l'utilitaire 3c5x9cfg.exe, des
cartes 3COM, ou qui peuvent être obtenues par les primitives VxWorksTM pciDeviceShow()
ou pciFindDevice() de la librairie sysLib). Ces caractéristiques de la carte réseau conduisent
aux lignes suivantes :
#dene IO_ADRS_ELT 0x300
#dene INT_LVL_ELT 0x0a
#dene NRF_ELT 0x00
#dene CONFIG_ELT 3 /* 0=EEPROM 1=AUI 2=BNC 3=RJ45 */
ETAPE 2 Il faut ensuite construire la version légère du VxLoader, ce qui est réalisé par
la commande Build Boot_Rom du menu Build. En choisissant alors le type de cible et le type
de noyau désiré (compressé , non compressé bootrom_uncmp, etc.)9, nous procédons à la
compilation et l'édition des liens. Un chier bootrom_uncmp est alors créé dans le répertoire
(\Tornado\ target\cong\<type cible>\) et il sut d'utiliser la commande mkboot pour
créer la disquette.
Au nal, nous disposons d'une disquette de Boot qui, si elle est bien congurée, per-
mettra le boot de la cible et permettra d'aller charger sous protocole FTP, le noyau et
l'application. A noter que ce chargement est automatique après quelques secondes (option
7Dans la description des chemins d'accés au noyau, on utilise des slashs (type arborescence UNIX ).8Masque de sous réseau.9Cela correspond à une mémoire de boot (ou de démarrage) non compressée.
C.2 Le développement d'applications temps réel avec Tornado/VxWorksTM193
f=0x0 de la ligne de commande) mais qu'on peut l'éviter en tapant sur une touche à l'invite
du VxLoader. On se trouve alors dans un shell autonome qui comporte un certain nombre
de commandes dont voici les principales :
sysReboot qui reboote totalement la machine (Attention à la casse du mot).
help ça peut servir...
p qui liste les caractéristiques implémentées dans le VxLoader pour le téléchargement
du noyau complet (IP, données compte utilisateur, chemin d'accès, etc...).
l liste aussi ces caractéristiques, mais il s'ensuit un chargement automatique du noyau.
c liste également ces caractéristiques, mais propose une modication si nécessaire de
chaque caractéristique. En outre, le chargement du noyau une fois la liste parcourue,
n'est pas automatique.
@ lance le chargement. @ est obtenue avec la combinaison de touche : Shift + 2.
Création d'un noyau VxWorksTM - Démarrage du Target Server
En démarrant un nouveau projet, nous choisissons dans la fenêtre de dialogue initiale,
l'option : Create a bootable VxWorks Image. D'autres fenêtres de dialogue apparaissent alors
dans lesquelles sont demandées successivement : le nom du projet, son emplacement puis le
nom d'un environnement de travail particulier. Dans la dernière fenêtre enn, est demandé
un BSP particulier (board support package), fonction du type de la machine cible et qui
fournira un code spécique pour le noyau en fonction de la cible et des options formulées
par l'utilisateur.
Une fois le projet lancé, on trouve alors sur la gauche de l'écran le détail du projet
avec 3 onglets particuliers (cf. gure C.3) : le premier onglet (Files) décrit l'ensemble des
chiers du projet, le suivant décrit la conguration du BSP et enn, le troisième, décrit
les informations sur l'exécutable obtenu après l'édition de liens du noyau VxWorks. La
diculté en fait repose dans le 2ème onglet qui va congurer le noyau temps réel en terme
de fonctionnalité à ajouter ou à retirer (on parle de noyau sur étagère). Partant de la
conguration par défaut donnée par l'assistant de création de projet, on peut décrire les
changements à eectuer pour établir des communications cible-serveur.
Dans notre projet, une condition nécessaire à l'établissement des communications cible-
serveur est d'inclure l'option ELT netif driver correspondant à la carte réseau 3COM utili-
sée, option qui est située dans le chemin Networks components -> Networks devices -> BSD
Ethernet devices. Les paramètres de l'option (adresse carte réseau, interruption, etc.) sont
également à préciser dans la boîte de dialogue. Cet ajout conditionne en outre l'inclusion
automatique des options BSD attach interface et BSD interface support. Les autres options
du BSP sont à inclure ou non suivant les fonctionnalités que vous voulez donner à votre
noyau (par exemple ajouter l'option Target Shell située en development tool components ->
target shell components pour disposer du shell sur la cible).
Après la conguration du BSP, on passe à l'édition des liens pour le noyau VxWorksTM
(build). L'édition des liens eectuée, on peut faire télécharger par le VxLoader le noyau
VxWorksTM (s'assurer que le serveur FTP est démarré sur la machine hôte (WFTPD),
et dénir un compte utilisateur qui devra être en adéquation avec celui spécié pour le
VxLoader). Il reste une dernière étape à eectuer avant d'établir des communications cible-
serveur, c'est la mise en route et la conguration d'un Target Server (menu : Tools) (préciser
194 Présentation de VxWorksTM et de son EDI TornadoTM
les adresses IP, et dénir le protocole de communication).
Au nal, une fois le noyau VxWorksTM téléchargé sur la cible, son exécution mettra
en route le target agent qui va alors communiquer avec le target server, donnant alors
de nombreuses possibilités au développeur d'application temps réel, comme par exemple,
l'outil d'espionnage de l'exécution, appelé Windview, qui sert à tracer des chronogrammes
(cf. chapitre 5, paragraphe 5.4.2.1).
C.2.3 Exemples d'outils bien utiles
Divers outils d'aide au développement sont disponibles sous Tornado/VxWorksTM , et
la liste complète peut être trouvée dans les manuels d'utilisation. Citons simplement d'une
manière générale les outils de compilation, les outils de débogage, les outils de communi-
cation machine hôte/machine cible, l'outil permettant de faire des simulations VxWorksTM
sur la machine hôte, et enn, des outils de conguration, pour la création de disquette de
boot par exemple, mais aussi pour la création du noyau complet avec prise en compte de
telle ou telle fonctionnalité suivant l'application prévue.
Une fois la communication target agent - target server établie, nous avons par exemple,
la possibilité via l'outil Browser du menu Tools d'explorer un grand nombre d'informations
sur la cible et sur les tâches temps réel du noyau ou de l'application développée. La table des
symboles (option module information) peut être parcourue. On peut vérier l'occupation
de la mémoire, on peut consulter l'état des tâches, obtenir des informations générales sur
la cible, etc.. Un ensemble d'informations qui se révèlent particulièrement intéressantes
lorsqu'il s'agit de faire du débogage ou lorsqu'il s'agit de faire de la validation.
L'outil Shell (menu Tools) permet de bénécier d'un Shell sur l'hôte et donc de dis-
poser du confort du clavier azerty, des copier-coller, etc. Dans ce Shell, que ce soit celui
de l'hôte ou celui de la cible (si celle-ci a été congurée pour avoir la table des symboles
de VxWorksTM (initialisation nécessaire)), il existe également un certain nombres de com-
mandes intéressantes : la liste des tâches et leur état (i), la consultation et la modication
du contenu d'une adresse mémoire (très utile lors du développement de driver...), etc..
Fig. C.3: Les trois onglets gérant un projet VxWorks : le premier gère les chiers
de l'application, le deuxième gère la conguration du noyau, et le troisième gère
les diérents noyaux créés.
Annexe D
Résumé en langue anglaise.A l'attention du membre du Jury anglophone.
Jitter Control in On-line Scheduling
of Dependent Real-Time Tasks
L. David, F. Cottet et N. Nissanke
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001.
Abstract : A typical characteristic of real-time systems is concurrent processing of tasks
under strict timing requirements. These timing requirements may impose not only direct
constraints, such as deadlines, but also indirect timing constraints in terms of intertask
dependencies. However, scheduling policies which can deal with some of these constraints
eectively are limited, especially for the on-line context, and are not widely known wi-
thin the real-time community. In this context, this paper presents a technique to control
execution irregularities, namely, jitter. The technique is based on the modication of task
temporal parameters in the paradigm of the well known Deadline Monotonic (DM) and
Earliest Deadline First (EDF) algorithms. The technique presents a way either to remove
jitter completely (in the case of regularity constrained tasks) or to bound jitter releases.
Moreover, the approach takes into account temporal dependencies of tasks on one ano-
ther.
Keywords : Real-time, on-line scheduling, jitter, dependent periodic tasks.
D.1 Introduction
A real-time system, controlling a physical device or a physical process, invariably per-
forms two basic functions : sampling sensor readings and responding to dierent situations
by sending control signals to actuators. With respect to process requirements, these tasks
(sampling data systems, control systems, etc.) must often be periodic. However, this is rarely
the case in practice since periodicity cannot be achieved in an absolute sense. Indeed there
are often timing requirements on the design in the form of permissible jitter [Bate 99] or
196
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001.
timing tolerances. Basically, jitter arises due to the way algorithms, such as Rate Monotonic
(RM), Deadline Monotonic (DM) and Earliest Deadline First (EDF) [Liu 73] algorithms,
schedule multiple tasks for concurrent execution. These algorithms do not consider jitter
requirements. Indeed, in the periodic task model of Liu and Layland [Liu 73], each ins-
tance of a task (an execution of a task within a given period) is considered completely
independent from other instances. However, most real-time applications (e.g. multimedia
data transmission [Elsaadany 94], fault-tolerant systems, precision robotics [Lin 96], etc.)
have regularity constraints on various tasks. Besides, jitter can arise due to dierent reasons
at the implementation level, an example being the unpredictability in the actual timing of
periodic events as generated by the RTOS [Zhou 98]. However, this paper addresses only
the jitter induced by scheduling at the application level.
Scheduling algorithms for controlling jitter are limited. An o-line scheduling technique
based on simulated annealing methods due to Di Natale et al. [DiNatale 95] deals with
end-to-end jitters in a distributed context. In this context, Coutinho et al. [Coutinho 00a]
propose a jitter minimization technique based on a genetic algorithm. Another o-line so-
lution due to [Cheng 96, Choquet-Geniet 96] consists of an exhaustive search of all valid
sequences. Han and Lin [Han 96] also suggest a distance constraint task system model
(DCTS) in which execution regularity constraints are taken into account in some specic
scheduling algorithms. In xed priority scheduled systems, Bate et al. [Bate 99] describe
a task attribute handling mechanism which can deal with timing requirements, including
jitter. Baruah et al. [Baruah 99] propose an interesting technique for minimizing maxi-
mum jitter of a relatively small number of task in the EDF context, but without taking
advantage of the possibility to set osets in order to reduce jitter and to handle systems
of interdependent tasks. Based on a deadline assignment technique, Kim et al. [Kim 00]
present a technique to reduce jitter in a set of independent tasks. In our work, we study in
greater depth a) the issue of jitter control in the general on-line scheduling context, and b)
congurations of interdependent tasks in the deadline based scheduling context, both in a
uniprocessor context.
Our discussion on jitter control proceeds as follows. Section 2 introduces dierent types
of jitter. Section 3 introduces a set of task parameter handling tools to be used in Sections 4
and 5 in describing a complete jitter cancellation technique and a jitter bounding technique.
D.2 Denitions of Jitter
Our work uses the periodic task model [Liu 73]. Each ith task is characterized by four
parameters : ri,1 (the rst request time or oset), Ci (maximum execution time),Di (relative
deadline) and Ti (task period), each being, as appropriate, a nonnegative or a positive
integer ; see Figure D.1.
We consider two types of jitter : regularity jitter (execution irregularity within one
task) and end-to-end jitter (response time irregularity, either within a set of two or more
tasks forming an activity or within the same task in a repetitive sense). Both the above
types of jitter can be dened over a scheduling period, or a major cycle (H) a reference
pattern used for scheduling simulation. Authors of [Grolleau 00b] generalize the results
of [Leung 80] such that in every case H is bounded by maxi(ri,1) + 2LCMi(Ti). A common
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001. 197
approach to jitter denition is to use the maximum duration between successive activation
times and completion times [Baruah 99, Buttazzo 97]. It is not unusual, however, to come
across sequences of task instances where the intervals between successive completion times
are more or less identical, resulting in a less accurate estimate of jitter. An advantage of
using H is that in dening jitter it allows the use of statistical concepts, such as the mean,
covering a range of completion times spread over H .
Fig. D.1: Task model.
D.2.1 Regularity Jitter
Let si,k and ei,k be, respectively, the kth execution start date and the kth execution end
date of task τi ; see Figures D.1 and D.2. The length of time between two successive start
dates of task τi within the kth scheduling period is denoted by ∆si,k, i.e. ∆si,k = si,k+1 −si,k. Analogously, ∆ei,k = ei,k+1 − ei,k denotes the length of time between two successive
end dates. Both ∆si,k and ∆ei,k vary from 0 to 2Ti, the two extremities corresponding to
negligibly small execution times. Let us also introduce
jsi,k=
|∆si,k − Ti|Ti
100 % (D.1)
as a percentage relative measure of the execution start date irregularity between the kth
and the (k+ 1)th instances. Note that jsi,k= 0 % when the dierence si,k equals Ti (i.e. the
case of regular tasks) and jsi,k= 100 % when it equals 0 or 2Ti (i.e. the case of maximum
irregularity in execution). Analogous expressions apply for ei,k. Let us now introduce the
denition :
Denition 1 : Given a task τi with characteristics (ri,1, Ci, Di, Ti), the mean regu-
larity jitter of τi is dened by : JMean(τi) = 1Ni
∑Ni
k=1 jsi,k, Ni being the number of
instances of task τi during H, and si,k and jsi,kbeing as dened above.
See Figure D.2 for an illustration of the above for Ni = 4.Similarly, other statistics can be dened on jitter based on jsi,k
, for example, the maxi-
mum jitter, the minimum jitter, etc. Note that if preemption is not permitted then regularity
jitter based on si,k or ei,k will be identical. Otherwise, they are linked through the cohesion
jitter a topic to be introduced in the next section.
198
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001.
D.2.2 End-to-End Jitter
This subsection denes end-to-end jitter for an activity such as a control activity. An
activity may consist of just one periodic task or, alternatively, of several periodic tasks. In
the former case, the end-to-end jitter measures the cohesion jitter and, in the latter, the
response time irregularities. Thus, the end-to-end jitter is the irregularity in the elapsed
time between the execution start date of one instance of a task and the execution end
date of another instance of a task, with the two task instances not necessarily belonging
to the same task. The corresponding response times are denoted by RTk(a), a being a
given activity and k being an index ranging over the instances of a over a given scheduling
interval.
Let a be an activity consisting of, for example, two tasks τi and τj , with outputs of
τi serving as inputs for τj . In this case, a is a pair 〈τi, τj〉. Note that τi and τj may not
necessarily have the same rate [Bate 99], except when they are dependent. In Figure D.3-a,
τi and τj have two dierent rates and, in order to be more up-to-date when executing τj ,we choose the most recent instance of τi for the last value RT3(a). What is of interest then
is the elapsed time, within a given scheduling period, between the most recent execution
start date of an instance of τi and the execution end date of its succeeding instance of τj ;see RTk(a) for 1 ≤ k ≤ 3 in Figure D.3-a. On the other hand, with respect to cohesion
jitter, what is of interest is the elapsed time between the start and end dates of execution
of a given task instance ; see RTk(τi) for 1 ≤ k ≤ 4 in Figure D.3-b.
In dening end-to-end jitter, it is necessary to compare RTk values dened above againsta mean value, which could be computed either from RTk values themselves or, alternati-
vely, using the data collected by monitoring the automation, for example, using a tted
response time curve which makes the system stable. Let us denote whatever the chosen
value by RT . The end-to-end jitter can then be considered in terms of the dierence :
∆k =|RTk−RT |
RT100 %. The latter is similar to (D.1) and leads to the following denition :
Fig. D.2: Regularity jitter.
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001. 199
Denition 2 : Given the response times RTk(a) and RTk(τi) as introduced
above, the mean end-to-end jitter is dened as a percentage by : JMean(a) =
1Na
∑Na
k=1
|RTk(a)−RT |RT
100%, Na being the the number of instances of the activity a.Analogously, the mean cohesion jitter as a percentage is dened by JMean,c(τi) =1Ni
∑Ni
k=1|RTk(τi)−Ci|
Ci100%, Ni being the number of instances of the task τi executed
during H.
The above are illustrated in Figures D.3-a and D.3-b for Na = 3 and Ni = 4. Our focus inSection 3 and 4 is on regularity jitter.
D.3 Approach to Controlling Regularity Jitter
Let R and NR be two sets of periodic tasks with nR and nNR elements respectively and
let their union characterize a real-time task conguration. The tasks τR in the rst set are
required to be regular in term of execution, whereas the tasks τNR in the second set are
not subject to such a requirement. Thus, the distinction between the two task sets is based
on whether or not the periodicity is to be observed strictly. As was mentioned earlier, task
execution irregularities arise due to the way scheduling algorithms work and do not aect
other constraints such as deadlines. Task regularity constraints may be required in the case
of sampling tasks and control tasks.
Execution windows of a task τi correspond to intervals of the form [|ri,j; ei,j|](j ∈ N∗).
We assume that the periods are not alterable, since they usually come from process re-
quirements. We also assume that the worst case execution characteristics of each task is
known and xed, and that redenition of release dates ri,1 would not lead to redenition of
any relative deadlines (Di) (oset free systems [Goossens 03]). Obviously, even where it is
permitted, any redenition of Di must result in a smaller value than its original value.
D.3.1 General scheme
The jitter control technique presented here is based on the idea that if two regular
tasks have a non empty intersection of their execution windows, then one of them will be
Fig. D.3: (a) : End-to-end jitter for an activity (a =< τi, τj >) - (b) : cohesionjitter for a task.
200
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001.
exposed to regularity or cohesion jitter. Let us illustrate this idea with an example involving
a conguration of three tasks (τ1, τ2, τ3), which are to be scheduled with external priority
(Prioi) ; see table D.1. Figure D.4 shows the scheduling sequence where it can be noted thatτ2 is preempted by τ1, and τ3 is preempted by both τ1 and τ2. Equivalently, the intersectionof task execution windows are eectively not empty, resulting in jitter on τ2 and τ3. Aninteresting solution would be to cancel jitter by desynchronizing the release dates. Indeed,
the triplet (r1,1, r2,1, r3,1) = (1, 0, 6) results in an empty intersection of execution windows,
eliminating the jitter completely ; see Figure D.5.
Tab. D.1: Example : Task characteristics.ri,1 Ci Di Ti Prioi
τ1 0 3 16 16 3
τ2 0 1 4 4 2
τ3 0 2 8 8 1
Fig. D.4: τ2 preemption by τ1, τ3 preemption by τ1 and τ2 : jitter on τ2 and τ3- Prio1 > Prio2 > Prio3.
Fig. D.5: Scheduling sequence with no jitter - Prio1 > Prio2 > Prio3.
Our technique is a generalization of the above idea and consists basically of adjusting
execution windows of regular tasks through redenition of release dates and relative dead-
lines, but always maintaining the required interrelationships between tasks. Thus, the
approach to jitter cancellation and jitter bounding can be summarized in four steps :
Step 1 : release date desynchronization,
Step 2 : maintenance of the precedence relation,
Step 3 : restriction of execution windows to a certain bound,
Step 4 : verication of schedulability through tests.
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001. 201
This above strategy can be accomplished with two dierent eects : either by completely
eliminating regularity jitter (i.e. by forbidding preemption of R tasks by any NR task) or by
bounding regularity jitter (i.e. by permitting preemption to a certain extent). This relies on
three separate tools. The rst tool searches for release dates for regular tasks so that each
one of the tasks completes after a certain amount of time following its activation without
causing an execution overlap. The second tool veries the maintenance of the precedence
constraints on tasks. The third tool performs the redenition of relative deadlines in order
to achieve the required task priorities.
D.3.2 Release date desynchronization
Let τ1, ..., τn be a set of task to be desynchronized. For every task τi, we dene a time
value Wi, Wi ∈ N∗ and 0 < Ci ≤ Wi ≤ Di, such that by Wi the execution of the correspon-
ding instance of τi is fully completed ; see Figure D.6. The problem of desynchronization of
execution windows [David 00] consists then of a constraint satisfaction problem, namely, of
nding a solution (r1,1, . . . , rn,1) satisfying the inequalities :
(∀ i, j ∈ 1 · · ·n; i < j)ri,1 − rj,1 = 0mod (Ti ∧ Tj)
ri,1 − rj,1 = 1mod (Ti ∧ Tj)ri,1 − rj,1 = 2mod (Ti ∧ Tj)
......
ri,1 − rj,1 = (Wj − 1)mod (Ti ∧ Tj)
and
rj,1 − ri,1 = 1mod (Ti ∧ Tj)rj,1 − ri,1 = 2mod (Ti ∧ Tj)
......
rj,1 − ri,1 = (Wi − 1)mod (Ti ∧ Tj)
(D.2)
where ∧ denotes the greatest common divisor (GCD) of its operands, and mod the
modulo symbol. These inequalities follow from the Generalized Chinese Remainder Theorem
[Knuth 69, Goossens 03]. This is illustrated in the gure D.7, where ri,k (k ∈ N∗) is xed
and rj,k is to be dened at a location such that it would cause no overlap with other jobs
from R tasks.
A necessary condition for a solution to (D.2) is that the periods are not pairwise rela-
tively prime. Let us attempt a proof of this claim by contradiction, assuming its negation
and showing that this would make the rst inequality inconsistent :
proof : Suppose that : (∀ i, j ∈ 1 · · ·n; i < j)(∃ ri,1, rj,1 ∈ N∗) ri,1−rj,1 = 0mod (Ti∧Tj)
with periods pairwise relatively prime. For p, q and m in N∗, the denition of congruence
is given by p = q mod(m) ⇔ (∃ k ∈ Z∗) p− q = k ·m. In others words, p = q mod(m) ⇔
(∀ k ∈ Z∗) p−q = k ·m. In the rst inequality of (D.2), pairs such as 〈ri,1, rj,1〉 are supposed
to be known. Let dij denote the dierence ri,1 − rj,1. It is necessarily the case that dij is in
202
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001.
Z∗. The fact that ri,1−rj,1 = dij ensures the existence of k in Z
∗, such that ri,1−rj,1 = k ·1.Hence, ri,1 = rj,1mod(1) is false, leading to a contradiction. As a consequence we concludethat our original assumption is false, resulting in the following condition : periods Ti andTj must not be pairwise relatively prime.
If it is possible to nd (r1,1, ..., rn,1) subject to above conditions, and if the execution
window of every task τi (1 ≤ i ≤ n) is equal to Wi, then the execution windows are
guaranteed not to overlap. For the task conguration of Figure D.5, the above conditions
are satised for W1 = 3, W2 = 1 and W3 = 2. In this case, for i = 1 and j = 2 the
inequalities (D.2) take the form :
r1,1 − r2,1 = 0mod (4)
and
(r2,1 − r1,1 = 1mod (4)r2,1 − r1,1 = 2mod (4)
) (D.3)
Solving the problem stated in (D.2) can be quite complex, more so as n increases. Any
precise analytical technique is likely to be of limited value and restricted to a particular set of
conditions. Therefore, generally numerical techniques [David 00] are to be preferred. Though
it is exponential, the problem complexity is not a critical factor in real time applications
with a relatively small number of regular tasks, and with a relatively narrow time interval
(Wi). Indeed, the regular tasks involved in this problem are mostly inputoutput tasks,
usually with a maximum execution time (Ci) much smaller than the period (Ti) and with a
choice of Wi parameter close to Ci in order to reduce jitter. As with other task parameters,
ri,1s are assumed to be non-negative integers [Goossens 03]. Characteristics of applications
dealt with by the authors comply with these assumptions.
Fig. D.6: The Wi parameter used in task desynchronization.
Fig. D.7: Illustrative diagram for task desynchonisation.
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001. 203
D.3.3 Precedence Relation
One of the important constraints on an activity is the right execution order. Generally,
tasks involved in an activity are dependent on one another and have the same period T ,which also happens to be the activity period. In this work we rely on this as an assump-
tion, and choose conditions that impose minimal restrictions on task temporal attributes.
According to [Blazewicz 76], in order to ensure precedence of τi over τj , it is necessary to
impose thatri,1 ≤ rj,1 Prioi > Prioj
or ri,1 < rj,1 Prioi ≥ Prioj . (D.4)
Obviously, these conditions depend on the choice of the scheduling algorithm. For example,
in DM the priority ordering Prioi > Prioj corresponds to Di < Dj .
D.3.4 Priority Redenition
Let us examine here how to redene relative deadlines so that tasks in R will always
enjoy higher priorities compared to those in NR. Again, this would depend on the cho-
sen scheduling algorithm. In DM, where tasks with the shorter deadlines will have higher
priorities, the condition that needs to be veried is
(∀τi ∈ R) Ci ≤ D∗i ≤ min
τj∈NR(Di;Dj − 1), (D.5)
where D∗i denotes the new relative deadline to be considered for task τi. In EDF, priorities
are dynamic and, therefore, it is dicult to foresee the actual runtime priorities of tasks.
However, there is a condition which enables the imposition of the required priority a priori,
namely
(∀τi ∈ R) D∗i = Ci, (D.6)
according to which every task τi will have the highest priority whenever it requires, and
acquires, the processor.
D.4 Elimination of Regularity Jitter
This section examines rst the results obtained for independent task congurations and
then, using an illustrative example, the case of dependent task congurations.
D.4.1 The Case of Independent Tasks
As the authors of [DiNatale 95] underline, controlling jitter is quite a complex problem
in the presence of task preemptions. Thus, our approach is to ensure that no regular task is
ever preempted, thus achieving the kind of scheduling sequence illustrated in Figure D.8. Let
us study the approach using an example [David 00]. Consider the task conguration with
characteristics given in Table D.2 and with two of them 〈τAcq1, τAcq2〉 having an execution
regularity constraint. Scheduling using DM, as well as EDF, leads to a sequence with non
negligible jitter on regular tasks (see table D.2).
204
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001.
Tab. D.2: Task conguration used in the illustrative example.Tasks ri,1 Ci Di Ti Jitters (%)
DM /EDF
τAcq1(Acquisition) 0 2 16 16 11.5 / 7.7
τTrait1(Treatment) 0 1 16 16
τAcq2(Acquisition) 0 2 32 32 12.5 / 8.9
τTrait2−1(Treatment) 0 4 31 32
τTrait2−2(Treatment) 0 1 32 32
τTrait3(Treatment) 0 4 14 14
τCont3(Control) 0 1 13 14
τCont4(Control) 0 1 8 8
Now let us modify the task temporal attributes.
Step 1 : Apply the desynchronization scheme described in Section D.3.2 on both regular
tasks withWi = Ci. According to an enumeration solution technique, we obtain a set of 377pairs tting this requirement. For example, one solution is the pair (rAcq1,1, rAcq2,1) = (0, 2).
Step 3 : To guaranty execution of regular tasks in R with no preemption, it is necessary
to make tasks in R have higher priorities compared to those in NR. Therefore, let us impose
the conditions described in Section D.3.4. In the less restrictive conditions, equation (D.5)
leads to the relative deadlines (DAcq1, DAcq2) = (7, 7) in DM. In EDF we obtain from (D.6)
the relative deadlines (DAcq1, DAcq2) = (2, 2).Step 4 : Check the schedulability of the modied task conguration using a uni-
processor scheduling simulation tool. Thus, nally we obtain some schedulable congu-
rations in DM and in EDF with the desired result on regular tasks : their jitter has been
eliminated.
D.4.2 The Case of Dependent Tasks
Figure D.9 illustrates four dierent kinds of possible precedence relationships (depen-
dencies) between tasks. They have been labelled as P1, P2, P3 and P4 and relate the tasks
in R and NR as : P1 : τR → τNR, P2 : τR → τR, P3 : τNR → τNR and P4 : τNR → τR. Letus describe the four steps required to eliminate jitter on regular tasks τR.
Step 1 : Since the aim is to achieve a schedule similar to the one described in Figure D.8,
which guarantees the elimination of regularity jitter, let us apply the desynchronization
technique on tasks inR withWi = Ci ; see Section D.3.2. This gives a set of new release dates
for regular tasks (E1 ∪ E3) ; see Figure D.9. Let us denote by (r1,1, ..., rnR,1)j , j ∈ [|1; p|]the set of solutions to this problem, p being the number of solutions.
Fig. D.8: Steady execution with no preemption of R tasks.
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001. 205
Step 2 : Now, we have to take into account the possible relationships between tasks.
For every relation, conditions (D.4) must be satised :
• in DM and EDF, the rst condition concerns the release dates :
(∀(i, j) ∈ N2)(τi → τj) ri,1 ≤ rj,1 (D.7)
Among the p solutions resulting from Step 1, let us retain only those ones which satisfy
the above conditions. Note that, as the execution duration of regular tasks is not empty,
these new release dates are denitely not identical. Then, only the conditions on tasks in
NR remain to be satised and these are involved in relationships in E4 area of Figure D.9.
These conditions lead to a set of possible release dates for tasks in E4.
Now, let us attend to the conditions on relative deadline.
• In DM we must choose the relative deadlines such that :
(∀(i; j) ∈ N2)(τi → τj) Di < Dj. (D.8)
However, in the case of two regular tasks related by precedence, these conditions are of no
use. Indeed, the release date choices made above, in conjunction with the property (to be
established) that will guaranty no overlapping of execution intervals, are sucient to ensure
precedence.
In EDF, higher priority of task τi is assured by the condition :
(∀(i; j) ∈ N2)(τi → τj) Di = Ci. (D.9)
The above denes new relative deadlines for tasks involved in a precedence constraint.
However, it is necessary to make the following remark in the EDF context :
Fig. D.9: A real-time application : E1 ∪ E3 = R, E2 ∪ E4 = NR, E3 ∪ E4 =tasks involved in a relationship, E3 = tasks in R involved in a relationship, E4 =tasks in NR involved in a relationship.
206
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001.
Remark 1. Restriction of relative deadlines Dis to Cis will undoubtedly reduce the schedu-
lability of the new task conguration. One way to deal with this problem is to desynchronize
the tasks involved in such a relationship, so that there is an interval of time between two
successive release dates wide enough to insert an execution of the task which precedes.
However, we do not follow this avenue any further in this paper.
Step 3 : In order to guaranty that no preemptions of tasks in R take place, we just
have to give the highest priority to those tasks. Indeed, during an execution of a task τi inR it will not be possible for a task in NR to preempt τi because of the new priorities and
for other tasks in R to preempt τi because of the desynchronization.• In DM, according to section D.3.4, condition (D.5) must be satised : it means that
the new relative deadline must be strictly lower than those of the tasks in NR. However,this redenition calls for a remark :
Remark 2. In DM, from the point of view of priorities, setting Di to D∗i =
minτj∈NR(Di;Dj − 1) or D∗i = Ci (see condition (D.5)) leads us to the same scheduling
problem. Indeed, as long as the priorities of tasks in R are greater than the priorities of
tasks in NR, a dierence in priorities within R will not trigger any preemptions since the
tasks in R are desynchronized. However, it is useful to indicate the whole set of possibilities
so that an analytical criterion, if exists, could claim whether the new task conguration is
schedulable.
This redenition must also be performed carefully because of the possibility of incon-
sistent cases resulting from equation (D.8) :
• Indeed, in DM equation (D.5) enforces : DτR< DτNR
, which may come into conict
with equation (D.8). One way to avoid an inconsistency between the two conditions is to
forbid relationships of the form P4 : τNR → τR, which could typically impose a condition
such as DτNR< DτR
. Such an assumption can be made without loss of generality since,
from a design point of view, it is not relevant to make a task in NR precedes a task in
R. Leaving this kind of precedence constraint aside, choices of relative deadlines are made
following the same scheme as in the case of precedence. Among the solutions of equations
(D.5), namely, among a set of solutions of the form (D1, ..., DnR)jj ∈ [|1; q|] , q being
the number of solutions, we retain only those which satisfy precedence conditions, that is,
equation (D.8).
• In EDF, according to equation (D.6), tasks in R will have higher priority compared
to tasks in NR if (∀τi ∈ R) D∗i = Ci. This leads again to Remark 1, where we noted the
consequence of such conditions on the schedulability.
Step 4 : Given the possible temporal attributes of tasks in R and E4, it is necessary
to use a schedulability analysis tool to verify the schedulability of the task congurations,
if any. Task congurations so veried will satisfy the deadlines and the requirement of our
technique : elimination of any regularity jitter experienced by regular tasks.
D.4.3 Algorithm
The four steps described above can be expressed in the form of Algorithm 2, which
is applicable to both DM and EDF contexts. In this algorithm, both RTN and TN are
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001. 207
numbers, RTN and TN ∈ N, such that TN > RTN . The regular tasks range from 1to RTN , while non regular tasks range from RTN + 1 to TN . R denotes a vector, its
dimension being RTN in the initial part of the algorithm and TN subsequent to line 4.
Algorithme 2 The proposed algorithm to cancel regularity jitter of R tasks in DM or EDF
context.
1. R ← ri1,11≤i1≤RTN , ri2,11≤i2≤RTN , ... | (∀j ∈ 1, 2, 3, ...rij ,11≤ij≤RTNsatisfy de-
synchronisation criterion. 2. Retain in R the vectors that satisfy precedence constraints between two regular tasks.
3. for each vector Rj in R do
4. Rj ←Rj ∪ rk,1RTN+1≤k≤TN , such that the new
vector Rj satises precedence constraints.
5. end do.
6. D ← Ci1≤i≤RTN
7. D ← D ∪ DkRTN+1≤k≤TN , such that the new vector D satises the precedence
constraints.
8. for each vector Rj in R do
9. Check the schedulability
of ((Rj)i, Ci,Di, Ti)1≤i≤TN .
10. end do.
D.4.4 Example
Let us illustrate now the above technique using a simple real-time application drawn
partly from an aircraft control system ; see Figure D.10 and Table D.3. All types of pre-
cedence relations are represented, as well as the two types of tasks : R and NR. In this
example, the dierent steps described above are illustrated. Note that the initial regularity
jitters for regular tasks are not negligible : JMean(τR1) = 2.6 %, JMean(τR2) = 5.05 % and
JMean(τR3) = 10 %.
Tab. D.3: Parameters used in the illustrative real-time application.ri,1 Ci Di Ti Description
τNR1 0 2 32 32 (NR) Temperature sensor
τNR2 0 1 32 32 (NR) Aircraft Speed Control
τR1 0 3 32 32 (R) Pressure sensor
τNR3 0 1 16 16 (NR) Cabin temp. and pressure
τR2 0 2 16 16 (R) Flying gears
τR3 0 1 16 16 (R) Pilot instruction
τNR4 0 2 10 10 (NR) Alarm (fast)
τNR5 0 3 56 56 (NR) Human Computer Interf.
Step 1 : Release date desynchronization. First we shift the release dates so that
the execution of any regular task will not disturb the execution of other regular tasks. We
seek then triples of the form (rR1,1, rR2,1, rR3,1) satisfying the desynchronization criterion
208
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001.
with WR1 = 3, WR2 = 2 and WR3 = 1. It leads us to a set of 3696 dierent solutions, two
of them being, for example, (rR1,1, rR2,1, rR3,1) = (0, 3, 5) and (rR1,1, rR2,1, rR3,1) = (0, 4, 3).Step 2 : Consideration of precedence relation. In DM, in order to observe P1
and P2 relationships, we must choose among the rRi,1 (1 ≤ i ≤ 3) from step 1, the ones
that satisfy the following conditions : rR1,1 ≤ rNR2,1, rR3,1 ≤ rR2,1 and rR3,1 ≤ rNR3,1,
where rNR2,1 and rNR3,1 are yet to be determined. It is also necessary to verify P3 relation :
rNR1,1 ≤ rNR2,1. The above restrictions and conditions lead us to a set of possible new
release dates. To be more specic, with an implementation of the algorithm 2, we get 1848dierent ri,1 solution vectors. For example, the following release dates are a possible solution
to these conditions : (rR1,1, rR2,1, rR3,1) = (0, 4, 3), rNR2,1 = 1, rNR3,1 = 4, rNR1,1 = 0. Theabove conditions remain the same for EDF, except that we now have strict inequalities.
The conditions on relative deadlines to be satised are : DR1 < DNR2 , DNR1 < DNR2
and DR3 < DNR3 . The condition DR3 < DR2 is actually not necessary for regular tasks ; see
explanation in Section D.4.2, Step 2. In EDF, the tasks involved in a precedence relation
must satisfy Di = Ci, for every relation τi → τj.Step 3 : Regular task priorities. In DM, the relation (D.5) enforces that : DR1 <
DNRj, DR2 < DNRj
and DR3 < DNRj, j ranging over tasks in NR. Possible new relative
deadlines, satisfying the above conditions, are then dened. For example, one of the solutions
is : DR1 = 9, DR2 = 9, DR3 = 9, DNR1 = 31, DNR2 = 32 (unchanged) and DNR3 = 16(unchanged)). In EDF, the conditions to be enforced concern just the regular tasks and are
expressed by : Di = Ci.
Step 4 : Schedulability Test. With the new parameters proposed in this example,
we eectively obtain a schedulable conguration in DM, with the expected results : jitter
releases of τAcq1 and τAcq2 are canceled and precedence constraints are met ; see Figure D.11.
Algorithm 2, implemented for the time being only for the DM context, results in 1848dierent schedulable task congurations satisfying both constraints. It is possible to choose
from among them an optimal conguration satisfying other secondary criteria, for example,
the minimum number of preemptions or the shortest response time, for a task or a task
group.
To illustrate now the point made in Remark 1, we check in the EDF context whether
or not the task conguration is schedulable with the rst choice of release dates. In fact,
Fig. D.10: Illustrative real-time application.
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001. 209
the task conguration is not schedulable with these particular choices, but it is uncertain
whether or not there is a schedulable conguration for EDF. In order to be sure of that
we must check whether all possible task congurations are eectively not schedulable in
EDF. It is to be noted, however, that our technique is less likely to give a schedulable
conguration in EDF than in DM, primarily because of the manner in which the priorities
are handled.
Fig.D.11: Scheduling sequence in DM : Steady execution of tasks in R satisfying
precedence requirements.
D.5 Regularity jitter bounding
From an industrial point of view, it is unrealistic to enforce certain tasks to cancel
their jitter. Indeed it would be more appropriate to relax any relevant constraint and set
bounds on jitter releases. Besides, such requirements are not unusual in real-time speci-
cations [Bate 98]. In fact, in the technique described above, we need to be less restrictive
on parameter redenition so that more task congurations become schedulable afterwards.
The main reason why our technique results in too constrained problems is due to the enfor-
cement of nonpreemptability as a policy with respect to tasks in R. Hence, in this section,
we intend to allow preemption of tasks in R by tasks in NR within a certain extent. What
would be of interest here is a specication on the parameter Wi, by which time the exe-
cution of the corresponding instance of τi must be fully completed ; see Section D.3.2 and
Figure D.6. The maximum response time of task τi (RTmax(τi)) is a good choice, since
RTmax(τi) is identical to the maximum duration allowed for any instance of τi.This section uses the same scheme as the one described in the previous section. Thus, the
scheme enforces the execution of every task τi in R within an interval starting at its release
date ri,j, j ≥ 1, and ending Wi = RTmax(τi) processor time units later. In addition, the
pairwise intersection of intervals of tasks in R must be empty, meaning that any preemption
of tasks in R will be exclusively by tasks in NR. This makes sense from a design point of
view because, for any activity, regular tasks are usually executed in a xed order in order
to guaranty the temporal consistency of the data.
210
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001.
D.5.1 Result on Regularity Jitter
Following the application of our bounding technique, the maximum width of the exe-
cution window of a task τi in R becomes equal to RTmax(τi). Given such a task τi, theworst case for regularity jitter corresponds to the situation when a shortest elapsed time
(∆emin) is followed immediately by a longest elapsed time (∆emax) between the end points
of execution of two successive instances of τi ; see Figure D.12.
Fig. D.12: Maximum jitter release.
It is the applicability of relations ∆emax = Ti+Wi−Ci and ∆emin = Ti+Ci−Wi which
enable us to bound mean regularity jitter. Let us assume that over the scheduling period Hthere are as many durations of length ∆emin as the number of durations of length ∆emax
and let N be that number. Then, according to Denition 1, the mean regularity jitter of τiis
JMean(τi) = N |∆emin−Ti|+N |∆emax−Ti|2NTi
100%
= RTmax(τi)−Ci
Ti100 %
In short, the approach consists of enforcing the execution of each regular task in an interval
of length Wi = RTmax(τi) starting at τi's release date with the following results :
maximum response time requirement will be satised during the execution,
mean regularity jitter will be bounded by the limit JMean(τi) described above.
D.5.2 The technique through an example
Let us revisit the example in Section D.4.4 in order to illustrate the proposed technique.
For the jitter bounding context, the technique continues to be described by four steps as
before, the only change being in step 3, where the new relative deadlines D∗i are to be
dened as follows :
(∀τi ∈ R)D∗i = Wi = RTmax(τi)
Note that in EDF context, the condition above is replaced by :
(∀τi ∈ R)D∗i =Wi = Ci
for every regular task (R) preceding another task.
Let us assume that the maximum response time specied for regular tasks are :RTmax(τR1) =11, RTmax(τR2) = 4, RTmax(τR3) = 1 = CR3 (i.e. without preemption of τR3). In applying
our technique to this set of tasks, it is necessary to distinguish between DM and EDF
because of the dierences of our technique which depend on the choice of the scheduling
algorithm. Let us therefore illustrate the technique in the EDF context.
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001. 211
Step 1 : According to the precedence relation of the application, two regular tasks
precede tasks of other type (R or NR). Thus, following the conditions above, execution
of the two regular tasks will take place without preemption. Desynchronization of regular
tasks τR1 , τR2 and τR3 with the parameters : WR1 = CR1 = 3, WR2 = Jmax,c(τR2) = 4 and
WR3 = CR3 = 1 leads to 2160 dierent solutions, including, for example, (rR1,1, rR2,1, rR3,1) =(0, 3, 7) and (rR1,1, rR2,1, rR3,1) = (2, 8, 7).
Step 2 : With respect to precedence constraints of the application (see Figure D.10),
the solutions to be retained among the ones given above are only those which satisfy the
conditions : rR1,1 < rNR2,1, rR3,1 < rR2,1, rR3,1 < rNR3,1 and rNR1,1 < rNR2,1. This allows the
determination of possible release dates. For example, the following are two such solutions :
(rR1,1, rR2,1, rR3,1) = (2, 8, 7) and rNR2,1 = 3, rNR3,1 = 8, rNR1,1 = 0).As for the conditions on Di, it is necessary to check whether : DR1 = CR1 , DNR1 = CNR1
and DR3 = CR3 so that, in the case of a concurrent processor requirement, the preceding
tasks have higher priority.
Step 3 : There is a new relative deadline of τR2 as dened by DR2 = Jmax,c(τR2) = 4.As a result, the only solutions for relative deadlines are : DNR1 = 2 and (DR1 , DR2, DR3) =(3, 4, 1)
Step 4 : Finally, this step results in a set of possible task congurations for the para-
meters mentioned above. Each such task conguration is schedulable in EDF and the jitter
releases are bounded, or are even completely eliminated. Algorithm 2 results in 16 dierent
schedulable congurations for the DM context. All of them satisfy the bounded mean regu-
larity criterion, with the following results for the worst among them : JMean(τR1) = 2.56 %,
JMean(τR2) = JMean(τR3) = 0 %, to be compared to the mean regularity jitter of initial task
conguration : JMean(τR1) = 2.6 %, JMean(τR2) = 5.05 %, JMean(τR3) = 10 %.
D.6 Conclusion
This paper has demonstrated that in the deadline based scheduling context it is pos-
sible to schedule a task conguration not only under usual constraints such as timing
requirements, deadlines and precedence relations but, more importantly, also under jitter
requirements. The approach to handling jitter requirements involves four steps : release date
desynchronization, maintenance of precedence relation, execution window restriction to a
specied bound and, nally, schedulability tests. Various stages of task parameter handling,
either eliminating jitter or bounding jitter in the process, have been investigated in detail
and step-by-step. With respect to schedulability of newly dened task congurations, it has
been found that this is more dicult in the EDF context than in the DM context.
Current and future work aims at a more general treatment of end-to-end jitter by
generalizing the above scheme and investigation of task congurations involving shared
resources in an exclusive manner and nonperiodic tasks.
212
David L., Cottet F. et Nissanke N. Jitter Control in On-line Scheduling of Dependent Real-Time Tasks.
Acte du 22ième Symposium RTSS, RTSS'01, pages 49-58,
Londres, Royaume-Uni, Déc. 2001.
Liste des tableaux
3.1 Exemple de conguration de tâches avec gigue. . . . . . . . . . . . . . . . . . 73
3.2 Exemple de conguration de tâches, avec de la gigue sur deux tâches régu-
lières dans le contexte d'ordonnancement DM ou EDF. . . . . . . . . . . . . 82
3.3 Nouvelle conguration de tâches après application de la technique d'annula-
tion de la gigue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.4 Exemple de conguration à 6 tâches dont deux sont de type régulière à durée
d'exécution unitaire : Acquisition 1 et Acquisition 2. . . . . . . . . . . . . . 88
3.5 Nouveaux attributs temporels qui conduisent à une gigue nulle sur les tâches
régulières et qui conduisent au respect des contraintes de précédence. . . . . 89
3.6 Description des paramètres de tâches d'une application temps réel. . . . . . . 90
3.7 Nouvelle Conguration de tâche. . . . . . . . . . . . . . . . . . . . . . . . . 93
3.8 Description des paramètres de tâches d'une application temps réel. . . . . . . 100
3.9 Nouvelle Conguration de tâche pour le contexte d'ordonnancement DM. . . 101
3.10 Nouvelle Conguration de tâche pour le contexte d'ordonnancement EDF. . 104
3.11 Tableau récapitulatif distinguant les cas possibles des cas impossibles lors-
qu'on applique la technique de traitement de la gigue avec des tâches parta-
geant des ressources critiques. . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.12 Les paramètres temporels des tâches de l'application temps réel. . . . . . . . 116
3.13 Tableau récapitulatif des domaines possibles d'application de la technique de
traitement de la gigue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.1 Durées d'exécution des tâches rapportées à la granularité virtuelle retenue
(1 unité = 100µs). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.2 Paramètres temporels retenus pour les tâches, rapportés à la granularité
virtuelle choisie (1 unité = 100µs). . . . . . . . . . . . . . . . . . . . . . . . 152
5.3 Nouveaux paramètres temporels de l'application. . . . . . . . . . . . . . . . . 154
D.1 Example : Task characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . 200
D.2 Task conguration used in the illustrative example. . . . . . . . . . . . . . . 204
D.3 Parameters used in the illustrative real-time application. . . . . . . . . . . . 207
214 LISTE DES TABLEAUX
Table des gures
1.1 Un système temps réel. Les actionneurs agissent sur le procédé, les capteurs
renseignent sur le procédé. La vitesse de prise de décisions par le système
informatique doit être adaptée à la vitesse d'évolution du procédé. . . . . . . 18
1.2 Les deux types de boîtes aux lettres (BAL) : bloquante ou à écrasement. . . 20
1.3 Les états possibles des tâches et les transitions entre ces états. . . . . . . . . 21
1.4 Le modèle de tâche périodique. . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.5 Découpage d'une tâche qui dépose un message dans une boîte aux lettres, en
deux sous-tâches reliées par une contrainte de précédence. . . . . . . . . . . 29
1.6 Illustration des formules de redénition des paramètres "date d'activation"
et "échéance" dans le cadre des conditions de Chetto appliquées au contexte
EDF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.7 (a) : Le phénomène d'inversion de priorité : τ2 est retardée par τ3. (b) :
Utilisation du protocole PHP : τ3 ne vient plus retardée τ2. . . . . . . . . . 32
1.8 (a) : Illustration de l'interblocage. (b) : Utilisation du protocole PPP : la
demande de la ressource R1 par τ1 est refusée car sa priorité n'est pas stric-tement supérieure à la priorité plafond de R1. . . . . . . . . . . . . . . . . . 33
1.9 Illustration des diérentes types de gigue : (a) Gigue de régularité dénie
pour une tâche - (b) Gigue de bout en bout dénie pour une activité formée
de deux tâches - (c) Gigue de cohésion dénie sur une tâche. . . . . . . . . . 35
1.10 La gigue de régularité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.11 (a) : Gigue de bout en bout d'une activité a =< τi, τj > (b) : La gigue de
cohésion d'une tâche. Les numéros d'instance de la tâche τi sont précisés. . . 38
1.12 (a) : Temps de réponse minimum pour une activité formée de 3 tâches (b) :
Temps de réponse maximum dans le cas de 3 tâches dépendantes. . . . . . . 39
1.13 Les durées retenues pour les dénitions de la gigue. (a) : jsi,ken fonction de
∆si,k. (b) : si,k − ri,k en fonction de si,k − ri,k. . . . . . . . . . . . . . . . . . 41
1.14 (a) : exécution régulière. (b) : exécution irrégulière. . . . . . . . . . . . . . . 42
1.15 Exécution faiblement irrégulière : la période eective de la tâche τi varie dansune limite d'une unité de temps processeur à chaque instance. . . . . . . . . 43
1.16 Les intervalles dans lesquels les instances doivent débuter leurs exécutions. . 44
1.17 Les deux congurations pour lesquelles la gigue est maximum. . . . . . . . . 44
1.18 Échantillonnage oscillant réparti sur 2γTe. . . . . . . . . . . . . . . . . . . . 47
216 TABLE DES FIGURES
2.1 Détermination d'une contrainte linéaire : on souhaite que la durée Ti−Di+Ci
qui représente la durée qui sépare deux début d'exécutions de deux instances
successives, soit inférieure ou égale à un entier m. . . . . . . . . . . . . . . . 54
2.2 Trois tâches formant deux activités avec passage de données (d1 et d2), et
avec deux données d'entrée (X1 et X2) et une donnée de sortie (Y ). . . . . . 55
2.3 (a) : La tâche τi non transformée avec une durée d'exécution Ci. (b) : La
même tâche avec une fraction de charge processeur augmentée (partie ha-
churée) : dans le pire des cas, les Ci premières unités de temps processeur
sont placées avant la date kTi + (Ci/θi). . . . . . . . . . . . . . . . . . . . . 58
2.4 Le modèle de tâche à distances temporelles contraintes (DCTS). . . . . . . . 62
2.5 La plus grande distance temporelle entre les ns d'exécution de deux ins-
tances successives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.6 Passage de la conguration de tâches adaptée au problème du "pinwheel" (a),
à la conguration de tâche réelle (b) : les contraintes de distance temporelle
sont satisfaites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.7 Les débuts d'exécution de deux instances successives sont séparés d'au moins
Ti − λi et d'au plus Ti + ηi. . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.1 Non chevauchement des fenêtres d'exécution : condition susante mais non
nécessaire pour l'annulation de la gigue. . . . . . . . . . . . . . . . . . . . . 72
3.2 Perturbation de τ2 par τ1, de τ3 par τ1 puis τ2 : gigue sur τ2 et τ3. Les fenêtresd'exécution des 3 tâches se chevauchent - Prio1 > Prio2 > Prio3. . . . . . . 73
3.3 Séquence d'ordonnancement sans gigue : les fenêtres d'exécution des 3 tâchesne se chevauchent plus - Prio1 > Prio2 > Prio3. . . . . . . . . . . . . . . . 74
3.4 Dénition des paramètres pour le problème de désynchronisation. Wi repré-
sente la largeur maximale pour les fenêtres d'exécution des instances de τi. . 74
3.5 Les diérents états à éviter de sorte que la tâche τi ne perturbe pas l'exécutionde la tâche τj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.6 En grisé, les valeurs de rj,1 − ri,1 interdites dans Z/pZ avec p = Ti ∧ Tj . . . . 78
3.7 Exécution régulière et sans préemption d'une tâche de R. . . . . . . . . . . 81
3.8 Une partie de la séquence d'exécution de la nouvelle conguration de tâches
ordonnancées suivant DM : les tâches τAcq1 et τAcq2 sont régulièrement exé-
cutées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.9 Une application temps réel avec les diérentes types possibles de précédences
(τR : tâche régulière, τNR : tâche non nécessairement régulière). . . . . . . . 83
3.10 Les ensembles - disjoints - de tâches formant une application temps réel :
E1 ∪ E3 = R, E2 ∪ E4 = NR, E3 ∪ E4 = tâches mises en jeu dans une
relation de précédence, E3 = tâches de R mises en jeu dans une relation de
précédence, E4 = tâches de NR mises en jeu dans une relation de précédence. 84
3.11 Séquence d'ordonnancement en DM de la nouvelle conguration obtenue
(séquence donnée sur [0; 60]) : les tâches τAcq1 et τAcq2 sont régulières - les
èches correspondent à des relations de précédence. . . . . . . . . . . . . . . 90
3.12 Un exemple d'application temps réel. . . . . . . . . . . . . . . . . . . . . . . 91
TABLE DES FIGURES 217
3.13 Séquence d'ordonnancement après la modication des paramètres dans le
contexte de DM : les exécutions des tâches R sont régulières et les précédences
sont respectées - les èches représentent des relations de précédence. . . . . . 93
3.14 Le temps de réponse maximum d'une tâche trmax(τi) permet de spécier le
paramètre Wi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.15 Le cas du maximum de gigue dans l'exécution de la tâche τi. ∆emin = la
plus petite durée séparant les ns d'exécution de deux instances successives,
∆emax = la plus grande durée séparant les ns d'exécution de deux instances
successives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.16 Une partie de la séquence obtenue en DM : les précédences sont respectées
et les gigues encadrées - les èches représentent des relations de précédence. . 102
3.17 (a) : exécution de la tâche régulière τi avec préemption par la tâche non
régulière τj (présence de la section critique SCj) - (b) : durée de préemption
allongée pour faire face au temps de blocage éventuel de τj. . . . . . . . . . . 107
3.18 Le temps de réponse de bout en bout après l'application de la technique de
traitement de la gigue de régularité sur les tâches formant l'activité. . . . . 111
3.19 Les temps de réponse d'une activité a =< τ1, τ2, τ3 > une fois le traitement
de la gigue de bout en bout appliquée : les TRa,i (1 ≤ i ≤ 7) sont identiqueset sont choisis de telle sorte qu'ils soient aussi proches que possible de TRTh. 112
3.20 Les temps de réponse minimum (a) et maximum (b) d'une activité a =<τ1, ..., τn > une fois la technique de traitement de la gigue de bout en bout
appliquée sur τ1 et τn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.21 Le temps de réponse maximum (TRmax(a)) de bout en bout de a, face auxtâches de NR faisant partie intégrante de l'activité. . . . . . . . . . . . . . . 114
3.22 Exemple d'application temps réel comportant une activité. . . . . . . . . . . 116
3.23 Une partie de la séquence ordonnancée par DM après avoir modier les attri-
buts temporels des tâches suivant notre technique de traitement de la gigue
de bout en bout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.1 Durée moyenne de génération d'une conguration de tâches en fonction de
la charge processeur requise et en fonction de la gigue minimum souhaitée -
PpcmMax = 1500 - 3 tâches régulières sur 8 tâches au total - DM . . . . . . 124
4.2 Durée moyenne de génération d'une conguration de tâches en fonction de
la charge processeur requise et en fonction de la gigue minimum souhaitée -
PpcmMax = 1500 - 3 tâches régulières sur 8 tâches au total - EDF . . . . . . 125
4.3 Répartition des congurations de tâches obtenues en fonction du maximum
des gigues des tâches régulières et en fonction de la charge processeur - Gigue
demandée ≥ 20% - PpcmMax = 1500 - 2 tâches régulières sur 8 tâches au
total - DM (pour chaque courbe, 1000 congurations ont été générées). . . . 126
4.4 Réduction de la gigue des tâches régulières pour des congurations générées
aléatoirement. Après utilisation du module de traitement de la gigue, les
gigues sont inférieures à 5% - DM . . . . . . . . . . . . . . . . . . . . . . . . 128
4.5 Pourcentage de réussite de la technique de traitement de la gigue en fonction
de la charge processeur requise et en fonction de la gigue maximum autorisée
sur les tâches régulières. 2 tâches régulières sur 8 tâches au total - DM . . . . 130
218 TABLE DES FIGURES
4.6 Pourcentage de réussite de la technique de traitement de la gigue en fonction
de la charge processeur requise et en fonction de la gigue maximum autorisée
sur les tâches régulières. 3 tâches régulières sur 8 tâches au total - DM . . . . 132
4.7 Pourcentage de réussite de la technique de traitement de la gigue en fonction
du nombre de tâches régulières - DM . . . . . . . . . . . . . . . . . . . . . . 132
4.8 Pourcentage de réussite de la technique de traitement de la gigue en fonction
de la charge processeur requise et en fonction de la gigue maximum autorisée
sur les tâches régulières. 2 tâches régulières sur 8 tâches au total - EDF . . . 133
4.9 Pourcentage de réussite de la technique de traitement de la gigue en fonction
de l'algorithme d'ordonnancement utilisé. . . . . . . . . . . . . . . . . . . . . 133
5.1 Diérentes photos du banc d'essai avec le pendule en "position inversée" sur
son chariot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.2 Description schématique du banc. . . . . . . . . . . . . . . . . . . . . . . . . 137
5.3 Initialisation et architecture du système temps-réel. . . . . . . . . . . . . . . 138
5.4 Diagramme fonctionnel initial. . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.5 Diagramme de contexte de l'application. . . . . . . . . . . . . . . . . . . . . 143
5.6 Diagramme SART de l'application, et ses notations. . . . . . . . . . . . . . 144
5.7 Diagramme DARTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
5.8 La durée d'exécution des tâches est telle qu'elles sont toutes exécutées entre
deux ticks de l'ordonnanceur de VxWorksTM . . . . . . . . . . . . . . . . . . 148
5.9 (a) : Détermination du pire temps mis par le système pour réagir à une
détection de butée - (b) : Détermination du pire temps mis par le système
pour réagir à une chute du pendule depuis la position verticale inversée. . . 151
5.10 Le graphe des précédences de l'application. . . . . . . . . . . . . . . . . . . 151
5.11 Séquence d'ordonnancement de la conguration de tâches sans mécanisme de
contrôle de la gigue : la tâche t_Moteur présente de la gigue (les exécutions
ne sont pas régulières). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
5.12 Séquence d'ordonnancement de la conguration de tâches avec mécanisme de
contrôle de la gigue : la tâche t_Moteur ne présente plus de gigue (exécutions
régulières), ainsi que les tâches t_Angle et t_Position. . . . . . . . . . . . . 155
B.1 Description schématique du système à étudier. . . . . . . . . . . . . . . . . . 177
B.2 Repères T1 et T2 liés aux solides Sc et Sp. . . . . . . . . . . . . . . . . . . . . 178
C.1 Les états possibles des tâches et les transitions entre ces états. . . . . . . . . 185
C.2 Communications cible-serveur. . . . . . . . . . . . . . . . . . . . . . . . . . . 191
C.3 Les trois onglets gérant un projet VxWorks : le premier gère les chiers de
l'application, le deuxième gère la conguration du noyau, et le troisième gère
les diérents noyaux créés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
D.1 Task model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
D.2 Regularity jitter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
D.3 (a) : End-to-end jitter for an activity (a =< τi, τj >) - (b) : cohesion jitter
for a task. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
TABLE DES FIGURES 219
D.4 τ2 preemption by τ1, τ3 preemption by τ1 and τ2 : jitter on τ2 and τ3 - Prio1> Prio2 > Prio3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
D.5 Scheduling sequence with no jitter - Prio1 > Prio2 > Prio3. . . . . . . . . 200
D.6 The Wi parameter used in task desynchronization. . . . . . . . . . . . . . . 202
D.7 Illustrative diagram for task desynchonisation. . . . . . . . . . . . . . . . . . 202
D.8 Steady execution with no preemption of R tasks. . . . . . . . . . . . . . . . 204
D.9 A real-time application : E1 ∪ E3 = R, E2 ∪ E4 = NR, E3 ∪ E4 = tasks
involved in a relationship, E3 = tasks in R involved in a relationship, E4 =tasks in NR involved in a relationship. . . . . . . . . . . . . . . . . . . . . . 205
D.10 Illustrative real-time application. . . . . . . . . . . . . . . . . . . . . . . . . 208
D.11 Scheduling sequence in DM : Steady execution of tasks in R satisfying pre-
cedence requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
D.12 Maximum jitter release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Index
A
actionneur . . . . . . . . . . . . . . . . . . . . . . . 17, 136
activité . . . . . . . . . . . . . . . . . . . . . . . . . . . .24, 29
délai critique de bout en bout . 24, 26
gigue de bout en bout . . . . . . . . . 24, 26
période . . . . . . . . . . . . . . . . . . . . . . . . 24, 26
algorithme d'ordonnancement . . . . . . . . . 19
DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
EDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
LL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
à priorité xe . . . . . . . . . . . . . . . . . . . . . 27
à priorité variable . . . . . . . . . . . . . . . . . 28
annulation de la gigue de régularité . . . 80
avec ressources partagées . . . . . . . . . 105
cas des priorités xes . . . . . . . . . . . . . . 87
conditions incompatibles . . . . . . .86, 87
désynchronisation des tâches . . . . . . 85
exemple complet . . . . . . . . . . . . . . . . . . 89
exemple simple . . . . . . . . . . . . . . . . . . . . 88
gestion des priorités . . . . . . . . . . . . . . . 86
gestion des précédences. . . . . . . . . . . .85
tâches dépendantes . . . . . . . . . . . . . . . .82
tâches indépendantes . . . . . . . . . . . . . . 81
B
boîte aux lettres . . . . . . . . . . . . . 19, 186, 188
C
cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
capteur . . . . . . . . . . . . . . . . . . . . . . . . . . 17, 136
chien de garde. . . . . . . . . . . . . . . . . . . .21, 186
communication. . . . . . . . . . . . . . . . . . . . . . . .19
asynchrone . . . . . . . . . . . . . . . . . . . . . . . . 19
bloquante . . . . . . . . . . . . . . . . . . . . . . . . . 19
non bloquante . . . . . . . . . . . . . . . . . . . . .19
sur rendez-vous (synchronisation) . 20,
188
synchrone . . . . . . . . . . . . . . . . . . . . . . . . . 19
conguration de tâches . . . . . . . . . . . . . . . . 18
charge processeur . . . . . . . . . . . . . . . . . 25
ordonnançable . . . . . . . . . . . . . . . . . . . . 22
conguration de tâches : génération . . 121
contrainte molle . . . . . . . . . . . . . . . . . . . . . . . 13
contrainte stricte . . . . . . . . . . . . . . . . . . . . . . 13
contrainte temporelle .15, 22, 23, 180, 181
de séparation . . . . . . . . . . . . . . . . . . 23, 26
gigue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
précédence . . . . . . . . . . . . . . . . . . . . 24, 29
régularité d'exécution . . . . . . . . . . . . . 15
D
diagramme de Gantt . . . . . . . . 22, 147, 152
E
encadrement de la gigue de régularité . 94
automatisation . . . . . . . . . . . . . . . . . . . 103
avec ressources partagées . . . . . . . . . 105
désynchronisation des tâches . . . . . . 97
exemples . . . . . . . . . . . . . . . . . . . . . . . . . . 99
gestion des priorités . . . . . . . . . . . . . . . 98
gestion des précédences. . . . . . . . . . . .97
exclusion mutuelle . . . . . . . . . . . . . . . . . 18, 31
expérimentations numériques. . . . . . . . .121
inuence de la charge processeur . 129
inuence de la gigue initiale . . . . . . 129
inuence du l'algorithme d'ordonnan-
cement . . . . . . . . . . . . . . . . . . . . . . . 131
inuence du nombre de tâches régu-
lières . . . . . . . . . . . . . . . . . . . . . . . . . 131
exécutif temps réel . . . . . . . . . . . . . . . . . . . . 20
VxWorksTM . . . . . . . . . . . . . . . . . . . . . . 136
F
faute temporelle . . . . . . . . . . . . . . . . . . . 22, 24
le, le d'attente . . . . . . . . . . . . . . . . 146, 184
gestion de type PEPS . . . . . . . 146, 185
INDEX 221
gestion de type tourniquet . . .146, 185
fonction de transfert . . . . . . . . . . . . . . . . . 139
fréquence d' échantillonnage . . . . . . . . . . .88
fréquence d'échantillonnage . . . . . . . . . . . 46
G
gigue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34, 40
critères favorables à son apparition45,
123
de bout en bout . . . . . . . . . . . . . . . 36, 38
annulation . . . . . . . . . . . . . . . . . . . . . 110
encadrement . . . . . . . . . . . . . . . . . . . 112
de cohésion . . . . . . . . . . . . . . . . 34, 36, 39
de régularité . . . . . . . . . . . . . . . . . . .34, 36
de régularité locale . . . . . . . . . . . . . . . . 35
granularité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
I
interblocage . . . . . . . . . . . . . . . . . . . . . . . 19, 31
inversion de priorité . . . . . . . . . . . . . . . 19, 31
L
LabviewTM . . . . . . . . . . . . . . . . . . . . . . . . . . 141
M
modèle de tâche . . . . . . . . . . . . . . . . . . . . . . .24
DCTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
périodique . . . . . . . . . . . . . . . . . . . . . . . . 24
méthode DARTS. . . . . . . . . . . . . . . . . . . . .144
méthode SART . . . . . . . . . . . . . . . . . . . . . . 142
O
Ordonnancement
Test d'ordonnançabilité . . . . . . . . . . . 80
ordonnancement . . . . . . . . . . . . . . . . . . . 15, 19
algorithme d'ordonnancement . . . . . 19
en ligne . . . . . . . . . . . . . . . . . . . . 15, 19, 26
hors ligne . . . . . . . . . . . . . . . . . . 15, 19, 26
séquence d'exécution valide . . . . 22, 27
étude d'ordonnançabilité . . . . . . . . . . 22
ordonnanceur. . . . . . . . . . . . . . . . . . . . . .22, 27
P
pathFinder . . . . . . . . . . . . . . . . . . 31, 152, 185
pendule
ordonnanceur . . . . . . . . . . . . . . . . . . . . 149
pendule inversé . . . . . . . . . . . . . . . . . 135, 177
boucle d'asservissement . . . . . . . . . . 138
loi de commande . . . . . . . . . . . . . . . . . 139
étude mécanique . . . . . . . . . . . . . . . . . 135
pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
priorité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14, 18
xe . . . . . . . . . . . . . . . . . . . . . . . . 19, 27, 28
variable . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
problème de désynchronisation73, 77, 173
procédé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
protocole de gestion de ressources . . . . . 31
PAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
PPPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
précédence
découpage en forme normale . . . . . . 29
gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
généralisée. . . . . . . . . . . . . . . . . . . . .24, 29
simple . . . . . . . . . . . . . . . . . . . . . . . . . 24, 29
préemption . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
période d'échantillonnage . . . . . . . . . . 46, 47
période d'étude . . . . . . . . . . . . . . . . . . . . . . . 22
période de simulation . . . . . . . . . . . . . . . . . 22
Q
quantum de temps . 22, 135, 146, 148, 156
R
ressource critique . . . . . . . . . . . . . . . . . . . . . 18
exclusion mutuelle . . . . . . . . . . . . . 18, 31
gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
interblocage . . . . . . . . . . . . . . . . . . . 19, 31
inversion de priorité . . . . . . . . . . . 19, 31
module de données . . . . . . . . . . . . . . . . 18
routines systèmes . . . . . . . . . . . . . . . . . . . . . 22
S
suréchantillonnage. . . . . . . . . . . . . . . .47, 159
système asynchrone . . . . . . . . . . . . . . . . . . . 14
système hybride . . . . . . . . . . . . . . . . . . . . . . . 14
système synchrone . . . . . . . . . . . . . . . . . . . . 14
système temps réel . . . . . . . . . . . . . . . . . . . . 17
sémaphore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
binaire . . . . . . . . . . . . . . . . . . . . . . . 21, 185
d'exclusion mutuelle . . . . . . . . . . . . . 185
séquence d'exécution valide . . . . . . . . 22, 27
222 INDEX
séquenceur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
T
temps de réponse . . . . . . . . . . . . 15, 148, 183
contrôle du temps de réponse. . . . .113
tâche . . . . . . . . . . . . . . . . . . . . . . . . . . 14, 18, 23
active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
bloquée . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
départ diéré (à) . . . . . . . . . . . . . . . . . . 25
départ simultané (à) . . . . . . . . . . . . . . 25
en cours d'exécution. . . . . . . . . . . . . . .21
endormie . . . . . . . . . . . . . . . . . . . . . . . . . . 20
fenêtre d'exécution . . . . . . . . . . . . 25, 73
gigue . . . . . . . . . . . . . . . . . . . . . . 23, 34, 36
inactive . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
instance . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
non régulière . . . . . . . . . . . . . . . . . . . . . . 23
paramètres temporels . . . . . . . . . . . . . 24
date d'activation . . . . . . . . . . . . . . . . 24
durée d'exécution maximale 24, 146
délai critique . . . . . . . . . . . . . . . . 23, 24
période . . . . . . . . . . . . . . . . . . . . . . 23, 24
prête . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
périodique, apériodique . . . . . . . . . . . 18
retardée . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
régulière . . . . . . . . . . . . . . . . . . . . . . . . . . 22
sporadique . . . . . . . . . . . . . . . . . . . . . . . . 18
suspendue. . . . . . . . . . . . . . . . . . . . . . . . .20
échéance sur requête (à) . . . . . . . . . . . 25
V
VxWorksTM . . . . . . . . . . . . . . . . . . . . . . 20, 183
gestion des communications . . . . . . 185
gestion des interruptions . . . . . . . . . 186
gestion des tâches . . . . . . . . . . . . . . . . 184
gestion du temps . . . . . . . . . . . . . . . . . 186
ordonnancement. . . . . . . . . . . . .146, 184
sémaphores . . . . . . . . . . . . . . . . . . . . . . 185
SemBCreate . . . . . . . . . . . . . . . . . . . 185
SemCCreate . . . . . . . . . . . . . . . . . . . 186
SemMCreate . . . . . . . . . . . . . . . . . . . 185
TaskDelay() . . . . . . . . . . . . . . . . . 147, 186
tick . . . . . . . . . . . . . . . . . . . . 146, 148, 186
Contribution à la gestion de la régularité d'exécution
des tâches d'une application temps réel à contraintes
strictes, dans un contexte d'ordonnancement en ligne.
Résumé : Dans le contexte des applications temps réel à contraintes strictes, les méthodes
d'ordonnancement en ligne permettent d'obtenir des séquences d'exécution des tâches,
dans lesquelles les échéances et les précédences sont respectées. En revanche, elles ne
permettent pas explicitement le respect de la régularité d'exécution de certaines tâches,
provoquant alors l'apparition du phénomène de gigue. Au travers d'un choix particulier
des paramètres temporels des tâches, nous proposons une technique de maîtrise de la
gigue utilisant les algorithmes d'ordonnancement basés sur l'échéance (DM, EDF). La
technique présentée est en outre compatible avec des contextes d'utilisation variés (partage
de ressources, temps de réponse maîtrisé, etc.). Un volet applicatif vient compléter cette
étude théorique au travers l'étude de l'ordonnancement d'une application de contrôle dun
pendule inversé.
Mots-Clés : temps-réel, ordonnancement en ligne, gigue, tâches dépendantes.
An approach to task jitter control of hard real time
applications with an on line scheduling strategy.
Abstract : Timing requirements of real time systems may impose not only direct
constraints, such as deadlines and precedences, but also indirect timing constraints such as
execution regularities between task instances. Classical on line scheduling policies can only
deal with deadline and indirectly with precedence. In this context, this work presents a
technique which permits to control not only these constraints, but also the execution irre-
gularities, namely, the jitter. The technique is based on the modication of task temporal
parameters in deadline based scheduling algorithm context (DM or EDF). The technique
presents a way either to remove jitter completely or to bound jitter releases. Moreover,
the approach takes into account temporal dependencies of tasks on one another. Several
execution contexts are also scrutinized (shared resources, response time control, etc.). Fi-
nally, the technique is used to schedule a genuine real time application : the control of an
inverted pendulum.
Keywords : real-time, on-line scheduling, jitter, dependent periodic tasks.
Secteur de Recherche : Informatique.
LISI-ENSMA
Téléport 2,
1, Av. Clément Ader,
BP 40109
86961 Futuroscope Chasseneuil Cedex