ensma ecole nationale sup érieure de mécanique et d'a ......ou molles. 13 appro c he sync...

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.

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.

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


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


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


(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


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,


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.


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


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 à


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


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


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.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.


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


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


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.


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


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é.


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)


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%.


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 :


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.


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


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


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)


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.


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.




[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.


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 :


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.


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 :


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 = 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)


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 .


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 = Wj − 1mod(Ti ∧ Tj)

et


...rj,1 − ri,1 = Wi − 1mod(Ti ∧ Tj)

(3.4)


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.


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)


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)


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.


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



τCont3(Contrôle) 0 1 13 14


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


τAcq2(Acquisition) 2 2 7 / 2 32 0 / 0






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


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).


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


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


à 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.


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.


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.


• 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


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


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.


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).


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


τ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


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.


∆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.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)


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.


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


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


τ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.



τ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.



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 :


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


τNR2 1 1 32 32 Tâche de calcul de


τR1 0 3 11 32 Tâche de mesure de la pression dynamique.



τR2 12 2 4 16 Tâche de commande

des organes de vol.

τR3 11 1 1 16 Tâche de d'acquisition




Contexte d'ordonnancement EDF


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.


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.


Tab. 3.10: Nouvelle Conguration de tâche pour le contexte d'ordonnancement

EDF.ri,1 Ci Di Ti Commentaires


τNR2 3 1 32 32 Tâche de calcul de


τR1 2 3 3 32 Tâche de mesure de la pression.



τR2 8 2 4 16 Tâche de commande

des organes de vol.

τR3 7 1 1 16 Tâche de d'acquisition




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.


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


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.


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


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).


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.


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


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.


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.


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.


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.


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).


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.)


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é).


DM (ou Priorités Fixes)/EDF Possible Possible

Contrôle du temps de réponse.

D'une ou plusieurs tâches.



D'une ou plusieurs activités.


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


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-


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.


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


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.


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


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 .


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





DM .


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





EDF .


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.


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.


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.


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


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 :


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.


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


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.


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.


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.


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


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 à


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


(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.


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).


- 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.


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


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 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


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.




[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.


algorithm : exact characterization and average case behavior. Proc. of


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.



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 = Wj − 1mod(Ti ∧ Tj)

et


...rj,1 − ri,1 = Wi − 1mod(Ti ∧ Tj)

(A.1)


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.


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.

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.


• 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)


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 ,


• 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.


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).


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.


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


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.



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



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




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.




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




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.




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




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.




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




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.




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




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




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




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.




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




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.




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




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



sur les tâches régulières. 3 tâches régulières sur 8 tâches au total - DM . . . . 132


du nombre de tâches régulières - DM . . . . . . . . . . . . . . . . . . . . . . 132



sur les tâches régulières. 2 tâches régulières sur 8 tâches au total - EDF . . . 133


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

ensma ecole nationale sup érieure de mécanique et d'a ......ou molles. 13 appro c he sync...

Documents