Manuscrit

Université Tunis El Manar
Institut Supérieur d'Informatique
Cours
Conception des Systèmes Temps

Réel
Ridha Ghayoula, Ph.D,Ing
Maître de conférences
A.U 2020-2021
i
Plan de Cours
Objectif général
Le cours Conception des Systèmes Temps Réel CSTR vise à développer chez
l'étudiant(e) une connaissance appliquée de la conception (et du développement)
d'un STR. Conséquemment, ce cours mettra à la fois l'accent sur les connaissances
permettant de comprendre ce qu'est (et ce que n'est pas) un STR, sur les techniques
et concepts propres au développement d'un tel système, et sur le développement du
savoir-faire requis pour mettre la main à la pâte ou pour encadrer une équipe de
développement faisant face aux problèmes caractéristiques d'un STR.
Objectifs spéciques
Acquérir les bases pour la conception des systèmes embarqués qui satisfont des
contraintes matérielles et logicielles associées au traitement des évènements en
temps réel. Comprendre la structure et l'opération des microcontrôleurs utilisés
dans les systèmes embarqués. Se familiariser avec les spécicités des systèmes
d'exploitation temps réel et savoir utiliser leurs services dans le développement de
systèmes en temps réel. Acquérir les bases et les techniques de conception sécuri-
taire pour les systèmes en temps réel. Concepts de base de traitement en temps
réel, de temps de réponse et de systèmes embarqués. Études des caractéristiques
matérielles et fonctionnelles des microcontrôleurs et de leurs interactions avec le
code d'application. Notions et catégories d'événements, mécanismes de réponse aux
événements en temps réel. Analyse de temps de réponse et de facteur de charge
du système. Études des noyaux (kernel) en temps réel. Méthodes d'analyse des
systèmes en temps réel et notions de base de abilité.
Au terme du cours, l'étudiant(e) sera capable :
1. de distinguer un STR d'un système qui ne l'est pas
2. d'expliquer les caractéristiques inhérentes à un STR ;
3. de dénir la spécication de contraintes TR ;
4. de mesurer le respect de contraintes TR ;
5. de développer un module d'un STR ;
6. d'utiliser des primitives d'un système d'exploitation lors de la programmation de
STR.
Plusieurs objectifs plus contextuels seront rencontrés en chemin : penser un

programme dans un contexte de ressources limitées (les systèmes embarqués, par
exemple, qui sont sujets à être soumis à des contraintes TR) ; modier un moteur
de collecte d'ordures (typique des STR sur plateforme prise en charge) ; appliquer
des techniques d'optimisation locales et systémiques ; développer des systèmes dans
une optique de résilience et de tolérance aux pannes ; etc.
Table des matières
Liste d'abréviations ix
1 Spécicités des Systèmes en Temps Réel 1

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Analyse d'une tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Avantages du multi-tâche . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Tâches dans un contexte temps réel . . . . . . . . . . . . . . . . . . . 4
1.4.1 Cycle de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Taxonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.3 Paramètres d'une tâche . . . . . . . . . . . . . . . . . . . . . 7
1.5 Ordonnancement non temps réel . . . . . . . . . . . . . . . . . . . . 8
1.5.1 Taxonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Ordonnancement des Processus 13

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Types d'ordonnanceurs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Objectifs de l'ordonnanceur d'un système multi-utilisateur . . . . . 15
2.4 Ordonnanceurs non préemptifs . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Premier arrivé premier servi . . . . . . . . . . . . . . . . . . . 19
2.4.2 Shortest job rst . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.3 Round robin/tourniquet . . . . . . . . . . . . . . . . . . . . . 19
2.5 Ordonnanceurs préemptifs . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.1 Ordonnancement du plus petit temps de séjour . . . . . . . . 22
2.5.2 Ordonnancement circulaire . . . . . . . . . . . . . . . . . . . 22
2.5.3 Ordonnancement avec priorité . . . . . . . . . . . . . . . . . . 26
2.5.4 Files multiples (quantum variable) . . . . . . . . . . . . . . . 27
2.6 Ordonnancement à deux niveaux . . . . . . . . . . . . . . . . . . . . 27
2.7 Cas d'étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.7.1 MS-DOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.7.2 Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.7.3 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.8 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.9 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.9.1 Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.9.2 Exercice 1 : Algorithmes non préemptifs . . . . . . . . . . . . 35
2.9.3 Exercice 2 : Algorithmes préemptifs . . . . . . . . . . . . . . 36

iv Table des matières
3 Ordonnancement de Tâches Périodiques Préemptif à Priorités

Fixes 39
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Ordonnancements A priorité Fixe . . . . . . . . . . . . . . . . . . . 40
3.2.1 Rate-Monotonic = RM . . . . . . . . . . . . . . . . . . . . 40
3.2.2 Deadline Monotonic = DM . . . . . . . . . . . . . . . . . . 44
3.3 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 Ordonnancement de Tâches Périodiques Préemptif à Priorités Dy-

namiques 51
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Earliest Deadline First (EDF) . . . . . . . . . . . . . . . . . . . . . . 51
4.2.1 Exemple 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Least Laxity First (LLF) . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.1 Exemple 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.2 Avantage et inconvénient . . . . . . . . . . . . . . . . . . . . 54
4.4 Ordonnancement en situations de surcharge . . . . . . . . . . . . . . 54
4.5 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5 Analyse du Temps de Réponse 61

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2 Principaux tests d'ordonnançabilité . . . . . . . . . . . . . . . . . . . 61
5.2.1 Analyse du facteur d'utilisation . . . . . . . . . . . . . . . . 61
5.2.2 Analyse du temps de réponse . . . . . . . . . . . . . . . . . . 62
5.3 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6 Ordonnancement des Tâches Indépendantes Apériodiques 69

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2 Traitement en arrière plan des tâches apériodiques à contraintes re-

latives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.3 Traitement par serveur périodique des tâches apériodiques en envi-

ronnement à priorité xe . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.3.1 Serveur à scrutation . . . . . . . . . . . . . . . . . . . . . . . 72
6.3.2 Serveur ajournable . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3.3 Serveur sporadique . . . . . . . . . . . . . . . . . . . . . . . . 77
6.4 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7 Noyau Temps Réel 83

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2 Système d'exploitation et noyau . . . . . . . . . . . . . . . . . . . . . 84
7.2.1 Boucle d'interrogation . . . . . . . . . . . . . . . . . . . . . . 85
7.2.2 Tâche pilotée par état/phase et Co-routines . . . . . . . . . . 86
7.3 Le noyau temps réel µC/OS − II . . . . . . . . . . . . . . . . . . . . 88
7.3.1 Les chiers source de MicroC/OS-II . . . . . . . . . . . . . . 89

Table des matières v
7.3.2 Comparaison entre uC/OS et uC/OS-II . . . . . . . . . . . . 92
7.3.3 Services du noyau (1) . . . . . . . . . . . . . . . . . . . . . . 92
7.4 Le noyau temps réel RTLinux . . . . . . . . . . . . . . . . . . . . . . 94
7.5 Le noyau temps réel VXWorks . . . . . . . . . . . . . . . . . . . . . 95
7.6 Le noyau temps réel pSOS . . . . . . . . . . . . . . . . . . . . . . . . 95
8 Méthode SA-RT 97
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.2 Spécication selon la méthode SA-RT . . . . . . . . . . . . . . . . . 98
8.3 Présentation de la syntaxe graphique de la méthode SA-RT . . . . . 100
8.3.1 Syntaxe graphique pour l'aspect fonctionnel . . . . . . . . . 100
8.3.2 Syntaxe graphique du ot de données . . . . . . . . . . . . . 101
8.3.3 Syntaxe graphique du stockage de données . . . . . . . . . . 101
8.3.4 Syntaxe graphique de la Terminaison . . . . . . . . . . . . . 104
8.4 Les diagrammes ot de données . . . . . . . . . . . . . . . . . . . . . 106
8.4.1 Présentation d'un exemple simple d'application de contrôle-

commande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
8.4.2 Diagramme de contexte d'une application . . . . . . . . . . . 107
8.4.3 Diagramme préliminaire et diagrammes de décomposition . . 108
9 Conception Selon La Méthode DARTS 113

9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.2 Conception selon la méthode DARTS . . . . . . . . . . . . . . . . . . 114
9.2.1 Les besoins d'une méthode de conception . . . . . . . . . . . 114
9.2.2 Relations entre les tâches . . . . . . . . . . . . . . . . . . . . 115
9.3 Présentation de la méthode DARTS . . . . . . . . . . . . . . . . . . 116
9.3.1 Syntaxe graphique de la méthode DARTS . . . . . . . . . . . 118
10 FreeRTOS 131
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
10.2 Tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
10.2.1 Tâche FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . . 134
10.2.2 Etat d'une tâche . . . . . . . . . . . . . . . . . . . . . . . . . 134
10.2.3 Task Control Block (TCB) . . . . . . . . . . . . . . . . . . . 135
10.2.4 Ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . . 135
10.2.5 Priorité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
10.2.6 Round robin . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
10.2.7 Gestion des tâches . . . . . . . . . . . . . . . . . . . . . . . . 138
10.2.8 Contrôle des tâches . . . . . . . . . . . . . . . . . . . . . . . 141
10.2.9 Contrôle du noyau . . . . . . . . . . . . . . . . . . . . . . . . 144
10.2.10 Gestion de la queue . . . . . . . . . . . . . . . . . . . . . . . 144
10.3 Gestion des ressources . . . . . . . . . . . . . . . . . . . . . . . . . . 145
10.3.1 Les Sémaphores . . . . . . . . . . . . . . . . . . . . . . . . . . 145

vi Table des matières
10.3.2 Mutex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
10.3.3 Problème d'inversion de priorité . . . . . . . . . . . . . . . . 150
10.3.4 La gestion des interruptions . . . . . . . . . . . . . . . . . . 150
10.3.5 La gestion de la mémoire . . . . . . . . . . . . . . . . . . . . 153
10.4 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
10.4.1 Exemple 1-Communication inter-tâches (utilisation de Mas-

sage Queue) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
10.4.2 Exemple 2-Synchronisation par Sémaphore . . . . . . . . . . 155
10.4.3 Exemple 3- Protection des ressources partagées par Mutex. . 155
10.5 Architectures matérielles supportées . . . . . . . . . . . . . . . . . . 155
Travaux Pratiques 163
A FreeRTOS 165
A.1 Nucleo-FR411RE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
A.1.1 Caractéristiques du microcontrôleur . . . . . . . . . . . . . . 165
A.1.2 Fonctionnalités Nucleo . . . . . . . . . . . . . . . . . . . . . . 166
A.1.3 STM32Cube . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
B TP2 173
B.1 Objectifs : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
B.2 Congurer PA5 en tant que sortie GPIO avec le label LED_GREEN 173
B.2.1 Créer un nouveau projet STM32 . . . . . . . . . . . . . . . . 173
B.2.2 Sélectionner MCU ou la carte souhaitée . . . . . . . . . . . 173
B.3 Ajouter 2 tâches et un sémaphore binaire . . . . . . . . . . . . . . . 174
B.4 Congurer le PC13 comme GPIO_EXTI13 avec le label

BLUE_BUTTON . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
B.5 Semaphore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
C TP3 187
C.1 Objectifs : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
C.2 Créer un nouveau projet STM32 . . . . . . . . . . . . . . . . . . . . 187
C.3 Conguration de RTOS avec CubeMX . . . . . . . . . . . . . . . . . 187
C.4 Création deux tâches Blink01 et Blink02 avec CubeMX . . . . . . . 190
D TP4 197
D.1 Objectifs : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
D.2 Conguration du CubeMX . . . . . . . . . . . . . . . . . . . . . . . . 197
D.3 Conguration RTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
D.4 Avantage d'utiliser un RTOS . . . . . . . . . . . . . . . . . . . . . . 200
D.5 Créer une tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
D.6 Gestion des priorités dans RTOS . . . . . . . . . . . . . . . . . . . . 203

Table des matières vii
E TP5 205
E.1 Objectifs : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
E.2 Conguration de RTOS avec CubeMX . . . . . . . . . . . . . . . . . 205
E.2.1 Téléchargement de logiciel docklight . . . . . . . . . . . . . 205
E.2.2 Créer un nouveau projet STM32 . . . . . . . . . . . . . . . . 205
F TP6 217
F.1 Objectifs : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
F.1.1 Créer un nouveau projet STM32 . . . . . . . . . . . . . . . . 217
F.2 Conguration de RTOS avec CubeMX . . . . . . . . . . . . . . . . . 217
F.2.1 Verication avec logiciel docklight. . . . . . . . . . . . . . . . 221
G TP7 227
G.1 Objectifs : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
G.2 Comment utiliser FreeRTOS avec Arduino ? . . . . . . . . . . . . . . 227
G.3 Téléchargez et installez FreeRTOS dans Arduino IDE . . . . . . . . . 227
G.4 Gestion des tâches FreeRTOS . . . . . . . . . . . . . . . . . . . . . . 228
G.4.1 LED clignotante avec FreeRTOS et Arduino Uno . . . . . . . 230
G.4.2 Esquisse Arduino . . . . . . . . . . . . . . . . . . . . . . . . . 230
G.4.3 Sortie du moniteur série . . . . . . . . . . . . . . . . . . . . . 230
H TP8 235
H.1 Objectifs : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
H.2 Arduino FreeRTOS Queue Management . . . . . . . . . . . . . . . . 235
H.2.1 Introduction aux les d'attente . . . . . . . . . . . . . . . . . 235
H.2.2 Blocage sur les lectures de le d'attente . . . . . . . . . . . . 236
H.2.3 Blocage sur les écritures en le d'attente . . . . . . . . . . . . 236
H.2.4 Utiliser l'API FreeRTOS Queue . . . . . . . . . . . . . . . . . 236
H.2.5 Créer une le d'attente avec FreeRTOS . . . . . . . . . . . . 240
H.2.6 FreeRTOS Envoi de données à la le d'attente . . . . . . . . . 241
H.2.7 FreeRTOS Recevoir des données de la le d'attente . . . . . . 241
H.2.8 Exemple - données de lecture / écriture de le d'attente Ar-
duino FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . . 242
H.3 Esquisse complète Arduino . . . . . . . . . . . . . . . . . . . . . . . . 243
H.4 Exemple d'achage LCD et ADC de le d'attente Arduino FreeRTOS 246
H.4.1 Comment fonctionne le code ? . . . . . . . . . . . . . . . . . . 246
I TP9 251
I.1 Objectifs : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
I.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
I.2.1 Pourquoi utilisons-nous la structure des les d'attente ? . . . 251
I.2.2 Exemple de le d'attente de structure pour recevoir des don-
nées de plusieurs ressources . . . . . . . . . . . . . . . . . . . 251
I.2.3 Implémentation de la structure FreeRTOS Queue dans Arduino252
Liste d'abréviations
Ti : Tâche i
Ci : Temps d'exécution de la tâche i
Pi : Période de la tâche i
Di : Délai critique de la tâche i
Bi : Temps de blocage de la tâche i
L(t) : Laxité résiduelle
D(t) : Délai critique résiduelle
RTi : Temps de réponse
U : facteur d'utilisation. Pour toutes les politiques d'ordonnancement
RM : Rate Monotonic
DM : Deadline Monotonic
EDF : Earliest First Deadline
LLF : Least Laxity First
FPP : Fixed Priority First
NPFP : Non Preemptive Fixed Priority
HPF : Highest Priority First
ABS : (Anti-blocking Brake System).
FIFO : First In Fisrt Out
ADARTS : Ada Based Design Approach for Real-Time Systems
CODARTS : Concurrent Design Approach for Real-Time Systems
FreeRTOS : est un système d'exploitation temps réel (RTOS)
PAPS : Premier Arrivé est le Premier Servi
FCFS : First-Come First Served
SJF : Plus court d'abord (Short Job First )
RM : Rate Monotonic
CS : condition susante
DM : Deadline Monotonic
STM32 : STMicroelectronics 32bits MCU
UART : Universal Asynchronous Receiver Transmitter
RS232 : Norme standardisant un protocole de communication série asynchrone
POSIX : Portable Operating System Interface, héritage d'UNIX (norme IEEE
1003)
RTOS : Real Time Operating System
API : Application Programming Interface
SDK : Software Development Kit
ARM : société anglaise proposant des architectures CPU RISC 32bits
ASCII : American Standar Code for Information Interchange
Kernel Information and Control
osKernelGetInfo : Get RTOS Kernel Information.
x Table des matières
osKernelGetState : Get the current RTOS Kernel state.

osKernelGetSysTimerCount : Get the RTOS kernel system timer count.
osKernelGetSysTimerFreq : Get the RTOS kernel system timer frequency.
osKernelInitialize : Initialize the RTOS Kernel.
osKernelLock : Lock the RTOS Kernel scheduler.
osKernelUnlock : Unlock the RTOS Kernel scheduler.
osKernelRestoreLock : Restore the RTOS Kernel scheduler lock state.
osKernelResume : Resume the RTOS Kernel scheduler.
osKernelStart : Start the RTOS Kernel scheduler.
osKernelSuspend : Suspend the RTOS Kernel scheduler.
osKernelGetTickCount : Get the RTOS kernel tick count.
osKernelGetTickFreq : Get the RTOS kernel tick frequency.
Thread Management
osThreadDetach : Detach a thread (thread storage can be reclaimed when thread
terminates).
osThreadEnumerate : Enumerate active threads.
osThreadExit : Terminate execution of current running thread.
osThreadGetCount : Get number of active threads.
osThreadGetId : Return the thread ID of the current running thread.
osThreadGetName : Get name of a thread.
osThreadGetPriority : Get current priority of a thread.
osThreadGetStackSize : Get stack size of a thread.
osThreadGetStackSpace : Get available stack space of a thread based on stack
watermark recording during execution.
osThreadGetState : Get current thread state of a thread.
osThreadJoin : Wait for specied thread to terminate.
osThreadNew : Create a thread and add it to Active Threads.
osThreadResume : Resume execution of a thread.
osThreadSetPriority : Change priority of a thread.
osThreadSuspend : Suspend execution of a thread.
osThreadTerminate : Terminate execution of a thread.
osThreadYield : Pass control to next thread that is in state READY.
Thread Flags
osThreadFlagsSet : Set the specied Thread Flags of a thread.
osThreadFlagsClear : Clear the specied Thread Flags of current running thread.
osThreadFlagsGet : Get the current Thread Flags of current running thread.
osThreadFlagsWait : Wait for one or more Thread Flags of the current running
thread to become signaled.
Event Flags
osEventFlagsGetName : Get name of an Event Flags object.
osEventFlagsNew : Create and Initialize an Event Flags object.
osEventFlagsDelete : Delete an Event Flags object.
osEventFlagsSet : Set the specied Event Flags.
osEventFlagsClear : Clear the specied Event Flags.
Table des matières xi
osEventFlagsGet : Get the current Event Flags.

osEventFlagsWait : Wait for one or more Event Flags to become signaled.
Generic Wait Functions
osDelay : Wait for Timeout (Time Delay).
osDelayUntil : Wait until specied time.
Timer Management
osTimerDelete : Delete a timer.
osTimerGetName : Get name of a timer.
osTimerIsRunning : Check if a timer is running.
osTimerNew : Create and Initialize a timer.
osTimerStart : Start or restart a timer.
osTimerStop : Stop a timer.
Mutex Management
osMutexAcquire : Acquire a Mutex or timeout if it is locked.
osMutexDelete : Delete a Mutex object.
osMutexGetName : Get name of a Mutex object.
osMutexGetOwner : Get Thread which owns a Mutex object.
osMutexNew : Create and Initialize a Mutex object.
osMutexRelease : Release a Mutex that was acquired by osMutexAcquire.
Semaphores
osSemaphoreAcquire : Acquire a Semaphore token or timeout if no tokens are
available.
osSemaphoreDelete : Delete a Semaphore object.
osSemaphoreGetCount : Get current Semaphore token count.
osSemaphoreGetName : Get name of a Semaphore object.
osSemaphoreNew : Create and Initialize a Semaphore object.
osSemaphoreRelease : Release a Semaphore token up to the initial maximum
count.
Memory Pool
osMemoryPoolAlloc : Allocate a memory block from a Memory Pool.
osMemoryPoolDelete : Delete a Memory Pool object.
osMemoryPoolFree : Return an allocated memory block back to a Memory Pool.
osMemoryPoolGetBlockSize : Get memory block size in a Memory Pool.
osMemoryPoolGetCapacity : Get maximum number of memory blocks in a
Memory Pool.
osMemoryPoolGetCount : Get number of memory blocks used in a Memory
Pool.
osMemoryPoolGetName : Get name of a Memory Pool object.
osMemoryPoolGetSpace : Get number of memory blocks available in a Memory
Pool.
osMemoryPoolNew : Create and Initialize a Memory Pool object.
Message Queue
osMessageQueueDelete : Delete a Message Queue object.
osMessageQueueGet : Get a Message from a Queue or timeout if Queue is
xii Table des matières
empty.
osMessageQueueGetCapacity : Get maximum number of messages in a Message
Queue.
osMessageQueueGetCount : Get number of queued messages in a Message
Queue.
osMessageQueueGetMsgSize : Get maximum message size in a Memory Pool.
osMessageQueueGetName : Get name of a Message Queue object.
osMessageQueueGetSpace : Get number of available slots for messages in a
Message Queue.
osMessageQueueNew : Create and Initialize a Message Queue object.
osMessageQueuePut : Put a Message into a Queue or timeout if Queue is full.
osMessageQueueReset : Reset a Message Queue to initial empty state.
Chapitre 1
Spécicités des Systèmes en

Temps Réel
Contents
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Analyse d'une tâche . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Avantages du multi-tâche . . . . . . . . . . . . . . . . . . . . . 3
1.4 Tâches dans un contexte temps réel . . . . . . . . . . . . . . 4
1.4.1 Cycle de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Taxonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.3 Paramètres d'une tâche . . . . . . . . . . . . . . . . . . . . . 7
1.5 Ordonnancement non temps réel . . . . . . . . . . . . . . . . 8

1.5.1 Taxonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1 Introduction
En programmation séquentielle, un programme est décomposé en sous-
programmes (procédures ou fonctions). Chaque sous-programme correspond à une
suite d'instructions, et l'exécution du programme voit ces instructions être exécutées
les unes à la suite des autres. Il est en général possible de réaliser une application en
une seule tâche, mais la scrutation de périphériques risque d'y être délicate et coû-
teuse en temps processeur. Un système temps réel est toujours décomposé en tâches,
chacune ayant des fonctionnalités, des temps d'exécution et des échéances diérentes.
Il serait parfois possible de les combiner en une seule tâche, mais cet exercice n'est
pas souhaité, notamment à cause du contrôle plus délicat sur les parties d'exécu-
tion que ceci impliquerait. Considérons un simple système composé de deux entrées
(un port série et un clavier), d'une partie de traitement, et d'une sortie. Dans un
contexte temps réel, le port série doit être scanné régulièrement an d'éviter qu'un
octet ne soit perdu. Si la tâche de traitement est conséquente, il faudrait, en milieu
de traitement, aller vérier l'état du port série, sans oublier la gestion du clavier. Il
faudrait également faire de même si la transmission vers la sortie est lente. Dans un
tel cas, la décomposition du système en tâches distinctes permet d'éviter ces incon-
vénients. Nous pouvons imaginer une tâche responsable de lire les données venant
du port série, et ce à une cadence garantissant le respect des échéances visant à ne
pas perdre d'octet. Une autre tâche serait responsable de la gestion du clavier, une
2 Chapitre 1. Spécicités des Systèmes en Temps Réel
autre du traitement, et enn une dernière de la gestion de la sortie. Des mécanismes

de communication peuvent être mis en ÷uvre pour permettre aux diérentes tâches
de s'échanger des données, et des priorités peuvent être assignées, notamment pour
garantir que le port série est bien géré. Les systèmes temps réel étant généralement
basés sur une architecture relativement semblable à cet exemple, nous traiterons
donc de systèmes multi-tâches. A l'heure actuelle, les systèmes informatiques sont
multi-tâches, et supportent l'exécution pseudo-parallèle de plusieurs tâches. Ceci a
été rendu possible par la mise au point de systèmes d'exploitation nettement plus
complexes. Un processeur peut donc voir plusieurs tâches en cours d'exécution se
partager le temps de traitement. Dans le cadre d'une application particulière, il est
dès lors possible d'avoir, par exemple, une tâche responsable d'exécuter un calcul
lourd pendant qu'un autre gère les interactions avec l'utilisateur. Il est intéressant
de noter que le concept de programmation multi-tâches est autant valable sur un
processeur simple c÷ur que sur un multi-c÷ur. Sur un simple c÷ur, les parties de
tâches s'exécutent tour à tour de manière transparente, et sur un multi-c÷ur, un
réel parallélisme peut être observé, chaque c÷ur pouvant exécuter un ensemble de
tâches.
1.2 Analyse d'une tâche

Un processus correspond à un chier exécutable en cours d'exécution sur un
processeur. Il est entre autres caractérisé par un code (le programme à exécuter),
une pile et un tas qui permettent de stocker les données nécessaires à son bon fonc-
tionnement, un identiant unique, et une priorité. La priorité permet au système
d'exploitation de gérer plusieurs processus en cours d'exécution sur un processeur,
un processus à plus haute priorité se voyant attribuer un temps d'utilisation
processeur plus important. Un processus peut également être décomposé en tâches
(threads ou ls d'exécution), chaque tâche étant une sorte de processus léger. Dans
ce cours, nous utiliserons le terme de tâche pour désigner une suite d'instructions
séquentielles correspondant à une tâche. Toutefois, les notions d'ordonnancement
introduites dans le chapitre correspondant peuvent être aussi bien appliquées à
des processus. La Figure 1.1 illustre la décomposition de l'espace d'adressage d'un
processus en trois parties principales :
Le code contenant les instructions du programme (text segment en anglais).
Les variables globales et les variables allouées dynamiquement (data segment en
anglais).
La pile, où les variables locales de ses sous-programmes, ainsi que diverses
informations temporaires ayant une durée de vie égale au sous-programme sont
stockées (stack segment en anglais).
Un processus, dans un cadre multi-tâche, est décomposé en deux parties :

La première contenant les ressources globales, telles que les instructions du
programme et les variables globales. Cette partie correspond au processus. Il s'agit
1.3. Avantages du multi-tâche 3
Figure 1.1 Espace d'adressage d'un processus
des deux premiers points de l'espace d'adressage.

La deuxième contenant des informations liées à l'état d'exécution, telles que le
compteur de programme (aussi appelé compteur ordinal) et la pile d'exécution.
Cette partie correspond à une tâche. Il est à noter que chaque tâche possède un
compteur de programme et une pile. Il s'agit de la partie liée à la tâche.
Etant donné que les tâches d'un même processus partagent le même espace
d'adressage, une tâche peut facilement corrompre les données utilisées par une autre
tâche. Des outils de synchronisation permettent toutefois d'éliminer les risques de
ces corruptions, s'ils sont utilisés de manière appropriée.
Toujours lié au partage de l'espace d'adressage, si une tâche eectue un accès
mémoire erroné fatal, le processus entier risque de se terminer. Ce n'est évidemment
pas le cas pour un système à plusieurs processus.
Une tâche est lié à un programme particulier, et ne peut donc pas être lancé par
un autre programme. Les processus peuvent en revanche être lancé par un autre
processus, et donc être plus aisément réutilisés.
1.3 Avantages du multi-tâche

En comparaison d'un programme ne contenant qu'une seule tâche, un pro-
gramme décomposé en tâches permet de mieux gérer les entrées/sorties et le calcul.
Une tâche peut s'occuper du calcul, tandis que d'autres gèrent les entrées/sorties. De
ce fait, l'usage d'un GUI (Graphical User Interface) est plus ergonomique et convi-
vial. Prenons l'exemple d'une application visant à acher la courbe de Mandelbrot.
Pour chaque point de l'image, une grande quantité de calcul doit être eectuée.
Supposons que l'utilisateur peut cliquer sur des boutons pour zoomer. Si nous ne
disposons pas de multi-tâche, une clique sur le bouton va ensuite voir l'application
se bloquer pendant que la nouvelle image est calculée. Si par contre nous dispo-
sons de plusieurs tâches, une tâche peut s'occuper du calcul pendant que l'autre
gère l'interface graphique. Dès lors l'utilisateur a encore la possibilité d'interagir
avec l'application sans devoir sourir de l'accaparement du processeur pour le cal-
cul. Dans le cas d'un processeur multi-c÷ur, un autre avantage du multi-tâche peut
s'exploiter. En eet, chaque c÷ur peut prendre en charge un ou plusieurs tâches.
En reprenant l'exemple de Mandelbrot, si nous supposons que nous sommes en pré-
sence d'un dual-core, alors nous pouvons décomposer notre calcul en deux tâches,
chacune étant responsable de la génération de la moitié de l'image. Lorsque l'uti-
lisateur clique sur le bouton, la nouvelle image pourra donc s'acher en un temps
réduit de moitié. Il s'agit là d'un parallélisme réel, rendu possible par l'améliora-
tion des plateformes matérielles proposées sur le marché. Nous pouvons toutefois
noter que l'accélération d'un facteur n pour un n-core reste théorique, la probable
communication inter-tâche imposant une perte en performance.
1.4 Tâches dans un contexte temps réel

Nous pouvons dénir deux grandes catégories de tâches : les tâches matérielles
et les tâches logicielles.
Les tâches matérielles (ou tâches immédiates) sont associées à des événements
matériels externes au programme. L'activation de ces tâches se fait donc par une
interruption provenant soit du procédé externe, soit du système de contrôle lui même
(horloge temps réel, temporisateur chien de garde . . . ). Dans cette catégorie de
tâches, nous trouvons en particulier toutes les tâches d'acquisitions qui sont de type
régulier, c'est-à-dire une acquisition par scrutation (polling task) du capteur. Nous
avons aussi les tâches d'acquisition qui sont déclenchées par une interruption externe
comme une alerte générée par un dépassement de paramètre.
Les tâches logicielles (ou tâches diérées) sont celles dont l'activation est demandée
par une autre tâche, tâche appelante, qui peut être de type matériel ou logiciel.
Dans le cas des tâches logicielles, les caractéristiques temporelles de la tâche appelée
sont déterminées d'une part à partir des attributs temporels de la tâche appelante et
d'autre part en fonction des relations temporelles spéciques entre la tâche appelante
et la tâche appelée. Ces tâches doivent obligatoirement être liées avec une autre
tâche.
En ce qui concerne les tâches matérielles, les spécications de l'application vont

en particulier décrire les caractéristiques temporelles des signaux d'interruptions
internes ou externes associés à ces tâches matérielles.
Les principaux types de signaux sont :
1.4. Tâches dans un contexte temps réel 5
Figure 1.2 Exemple des tâches matérielles et logicielles
les signaux périodiques qui peuvent être caractérisés par une première date
d'occurrence et une période. Ces signaux proviennent en général d'une horloge
interne HTR Horloge Temps Réel . ;
les signaux apériodiques qui se produisent de façon répétitive mais sans
période xée. Pour déterminer les caractéristiques des tâches associées à ces
signaux apériodiques, il est nécessaire de posséder des informations temporelles les
concernant, par exemple la durée minimale entre deux occurrences ;
les signaux sporadiques qui se produisent une seule fois, comme les signaux
d'alarme provenant du procédé.
1.4.1 Cycle de vie
La Figure 1.4 illustre les diérentes étapes de la vie d'une tâche, dans un contexte
temps réel. L'état initial d'une tâche est inexistant. Après sa création, elle passe à
l'état passive lorsque toutes les ressources à son bon fonctionnement ont été ré-
quisitionnées. Elle reste dans cet état jusqu'à être réveillée, ce qui peut n'est fait
qu'une seule fois pour une tâche apériodique, ou de manière répétée pour une tâche
périodique. Après le réveil, elle se trouve dans l'état prête, où elle se retrouve en
compétition avec les autres tâches disposées à être exécutées. L'ordonnanceur a alors
la charge de choisir les tâches à activer. De l'état prête, le système d'exploitation
peut ensuite la faire passer dans l'état élue, état dans lequel la tâche s'exécute.
Ce passage n'est pas du ressort de la tâche, mais bien de l'ordonnanceur, qui s'oc-
cupe d'allouer le processeur aux diérentes tâches concurrentes, et ce en suivant la
politique d'ordonnancement choisie. A tout instant l'ordonnanceur peut replacer la
tâche dans l'état prête, pour laisser une autre tâche s'exécuter. Il s'agit de la pré-
emption d'une tâche, qui se fait sans que la tâche préemptée n'en soit consciente.
Depuis l'état élue, la tâche peut aussi se retrouver dans l'état bloquée, lors de l'at-
Figure 1.3 Les diérents types d'activation des tâches matérielles. Interactions
du logiciel temps réel avec des événements externes :

(1) interruptions internes provenant d'une horloge temps réel
(2) interruptions externes provenant du procédé à contrôler.
tente d'un événement ou du relâchement d'un mutex, par exemple. La tâche ressort
de cet état par son réveil suite au relâchement d'un mutex ou au fait qu'un événe-
ment sur lequel la tâche attend a été déclenché. Dans ce cas, la tâche passe à l'état
prête, prête à continuer son exécution.
Figure 1.4 Etats et transitions d'une tâche dans un contexte temps réel
1.4. Tâches dans un contexte temps réel 7
Lorsque la tâche s'exécute, elle peut se terminer, et se retrouver dans l'état

de terminaison. Elle peut également terminer une occurrence, et passer dans l'état
passive, si elle est périodique. Il est intéressant de noter que des fautes temporelles
peuvent survenir, la tâche n'ayant pas terminé son traitement à temps. Ceci peut
faire passer la tâche de l'état élue ou prête à l'état passive. Elle y restera ensuite
jusqu'à une nouvelle requête, pour le cas où elle est périodique.
1.4.2 Taxonomie
Les tâches sont divisées en deux grandes catégories, en fonction de leur périodi-
cité.
Les tâches périodiques (ou cycliques) sont des tâches qui sont exécutées à
intervalles réguliers.
Elles sont entre autres dénies par la période avec laquelle elles sont censées
s'exécuter, ce qui est géré par l'ordonnanceur. Une tâche périodique peut par
exemple être responsable de l'observation d'un capteur à intervalles réguliers, de la
régulation de moteurs, de monitoring, etc.
Les tâches apériodiques sont, quant à elles, exécutées à intervalles irréguliers,

et peuvent donc survenir à n'importe quel instant. Il s'agira typiquement de tâches
de conguration, et de tâches activées par une alarme, ou par une entrée de
l'utilisateur. Les interruptions jouent un rôle important, étant le principal vecteur
d'activation. Une tâche est dite sporadique si elle est apériodique et que l'intervalle
minimal entre deux activations est connu.
Au niveau de l'interaction entre tâches, nous pouvons distinguer :
Les tâches indépendantes, dont l'ordre d'exécution peut être quelconque.
Les tâches dépendantes, pour lesquelles il existe des contraintes de précédence.

Il s'agit de cas où une tâche doit attendre qu'une autre ait terminé son traitement
pour pouvoir commencer le sien. Au niveau des politiques d'ordonnancement, il est
clair que les dépendances entre tâches auront un rôle crucial et devront être prises
en compte de manière judicieuse.
1.4.3 Paramètres d'une tâche
La dénition d'une tâche est évidemment fortement liée au programme décrivant

son exécution. Toutefois, dans le cadre de l'ordonnancement de systèmes temps
réel, diérents paramètres sont également nécessaires à la mise au point de solutions
correctes.
Les paramètres d'une tâche T sont :
r : la date de réveil de la tâche (ou date de demande d'activation)
C : sa durée d'exécution, calculée en temps processeur. Il s'agit du pire temps
d'exécution.
D : son délai critique, au-delà duquel le résultat est jugé comme étant non
pertinent
P : sa période, pour le cas d'une tâche périodique
d : pour une tâche à contraintes strictes, son échéance, calculée comme étant
d=r+D
s : date de début d'exécution de la tâche
f : date de n d'exécution de la tâche
u = C/P : son facteur d'utilisation du processeur
ch = C/D : son facteur de charge du processeur
.......
La Figure 1.5 illustre ces diérents paramètres. Dans les diagrammes temporels
utilisés, nous noterons l'occurrence d'un réveil de tâche à l'aide d'une èche pointant
vers le haut, l'échéance de la tâche étant représentée par une èche pointant vers le
bas.
Figure 1.5 Paramètres typiques d'une tâche Ti
La Figure 1.6 montre les paramètres d'une tâche périodique, et la Figure 1.7
illustre les caractéristiques d'une tâche périodique à échéance sur requête, où la
période est égale au délai critique.
Figure 1.6 Paramètres typiques d'une tâche Ti
1.5 Ordonnancement non temps réel

Tout système d'exploitation dispose d'un ordonnanceur, qui a pour fonction de
répartir l'utilisation du processeur entre les diérentes tâches demandeuses. Diverses
1.5. Ordonnancement non temps réel 9
Figure 1.7 Paramètres typiques d'une tâche périodique à échéance sur requête
Ti
solutions existent, et peuvent être classées en fonction de diérents paramètres. La

section suivante propose une taxonomie des algorithmes d'ordonnancement.
Dénition 1.1. (Faisabilité)

Un ensemble de tâches est dit faisable s'il est possible d'en proposer un ordonnan-
cement respectant l'ensemble des contraintes de temps imposées.
1.5.1 Taxonomie
Les algorithmes d'ordonnancement peuvent être catégorisés selon les critères

suivants :
Monoprocesseur/multiprocesseur
L'architecture physique du système a une inuence sur la manière d'agencer les
tâches. Certains algorithmes ne peuvent être appliqués qu'au des systèmes mono-
processeur (ordonnancement monoprocesseur), alors que d'autres se destinent à des
systèmes multi-processeur (ordonnancement multiprocesseur). Dans le cadre de ce
cours, nous ne traiterons que les algorithmes monoprocesseur.
Préemptif/non-préemptif
La préemption consiste en le fait qu'une tâche peut être interrompue à son insu
pour céder sa place à une autre tâche. Les algorithmes préemptifs traitent donc des
systèmes où les tâches peuvent être préemptées, tandis que les algorithmes non-
préemptifs traitent de ceux dont une tâche ayant commencé son traitement doit
obligatoirement le terminer avant qu'une autre ne s'exécute.
Figure 1.8 Exemple d'ordonnancement sans préemption

Figure 1.9 Exemple d'ordonnancement avec préemption
La possibilité de préemption permet notamment d'éviter que le processeur ne

soit occupé trop longtemps par une tâche, ce qui pourrait empêcher une autre tâche
de se terminer à temps. Cette exibilité a toutefois un coût lié au temps nécessaire
pour le changement de contexte d'une tâche à l'autre. Ce coût peut être intolérable
suivant l'application, et donc un choix doit être fait, pour un système particulier,
de partir sur une solution avec ou sans préemption.
En-ligne/hors-ligne (online/oine) Un ordonnancement hors-ligne est ef-

fectué avant le lancement du système. Ceci implique que tous les paramètres des
tâches soient connus a priori, et notamment les dates d'activation. L'implémenta-
tion du système est alors très simple : il sut de stocker l'identiant de la tâche à
eectuer à chaque moment d'ordonnancement dans une table, l'ordonnanceur ex-
ploitant ensuite cette information pour sélectionner la tâche à exécuter. Le désa-
vantage de cette approche est la grande dépendance au système cible, par contre
l'analyse hors-ligne permet une meilleure prédiction de la satisfaction ou non des
contraintes temporelles. De même, la puissance de calcul disponible hors-ligne per-
met de calculer un ordonnancement optimal, ce qui est un problème NP-complet,
tâche impossible à réaliser dans un système embarqué. Un ordonnancement en-ligne
est eectué durant le fonctionnement du système. L'ordonnanceur recalcule un nou-
vel ordonnancement à chaque fois qu'une nouvelle tâche est activée. L'avantage de
cette approche est la exibilité, et l'adaptabilité à l'environnement que procure le
calcul en-ligne. Par contre, ce calcul devant être exécuté par le système, qui est
temps réel, il doit être le plus simple et rapide possible, rendant impossible une so-
lution dite optimale. Diérents algorithmes permettent de résoudre ceci, notamment
en utilisant des heuristiques.
Statique/dynamique Un ordonnancement est dit statique s'il est uniquement

basé sur les propriétés des tâches avant le lancement du système. Un ordonnancement
est dynamique s'il est capable de réagir à la modication des propriétés des tâches
durant le fonctionnement du système (typiquement un changement de priorité).
Optimal/non optimal Un algorithme d'ordonnancement est dit optimal s'il

est capable de fournir un ordonnancement qui respecte toutes les contraintes de
temps si un tel ordonnancement existe. Si un algorithme optimal n'est pas capable
de trouver un ordonnancement correct, aucun autre algorithme ne le pourra. Un
algorithme non optimal (ou best eort) n'a pas la prétention d'être optimal, mais
1.5. Ordonnancement non temps réel 11
doit faire de son mieux pour fournir un ordonnancement le plus proche possible de
l'optimal.
Ce qu'il faut retenir

Qu'est ce que le temps réel ?
Dénition (1) :
Le comportement d'un système informatique est qualié de temps réel lorsqu'il
est assujetti à l'évolution d'un procédé qui lui est connecté et qu'il doit piloter ou
suivre en réagissant à tous ses changements d'états.
Dénition (2) :
Un système temps réel est déni comme un système dont le comportement dépend :
¬ De l'exactitude des traitements eectuées ¬ Du temps où les résultats sont
produits Un retard = le fait de rater une échéance = erreur du système
Temps réel dur et lâche :

Si le retard d'un traitement = exception (traitement spécique en cas d'erreur) :
on parle d'échéance dure, et il s'agit d'une défaillance
Si le retard ne provoque pas d'exception : échéance lâche
Un système dont aucune échéance ne doit être dépassée : Temps réel dur (hard
real time)
Si un dépassement occasionnel ne met pas en danger le système : temps réel lâche,
ou mou (soft real time)
Temps réel critique :

Terminologie qui met l'accent sur les conséquences d'une défaillance du système
et concerne la sûreté de fonctionnement
Le système est critique si :
* Il y a des conséquences humaines en cas de défaillance (contrôle aérien, centrales
nucléaires, etc...)
* Le coût nancier d'une défaillance du système est d'ordre supérieur à celui du
système. (Exploration spatiale, etc...)
Limites des systèmes classiques :

Ordonnancement : temps partagé
Gestion des entrées sorties et des interruptions sous optimales
Gestion de la mémoire virtuelle très souple : engendre des uctuations des temps
d'exécution des activités d'un système
Résolution temporelle pas assez ne
Latence :
Délai global de bout en bout entre le changement d'état dans un environnent et la
réaction correspondante en sortie du système
Chapitre 2
Ordonnancement des Processus
Contents
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Types d'ordonnanceurs . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Objectifs de l'ordonnanceur d'un système multi-utilisateur 15
2.4 Ordonnanceurs non préemptifs . . . . . . . . . . . . . . . . . 15
2.4.1 Premier arrivé premier servi . . . . . . . . . . . . . . . . . . . 19
2.4.2 Shortest job rst . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.3 Round robin/tourniquet . . . . . . . . . . . . . . . . . . . . . 19
2.5 Ordonnanceurs préemptifs . . . . . . . . . . . . . . . . . . . . 20

2.5.1 Ordonnancement du plus petit temps de séjour . . . . . . . . 22
2.5.2 Ordonnancement circulaire . . . . . . . . . . . . . . . . . . . 22
2.5.3 Ordonnancement avec priorité . . . . . . . . . . . . . . . . . 26
2.5.4 Files multiples (quantum variable) . . . . . . . . . . . . . . . 27
2.6 Ordonnancement à deux niveaux . . . . . . . . . . . . . . . . 27

2.7 Cas d'étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.7.1 MS-DOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.7.2 Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.7.3 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.8 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.9 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.9.1 Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.9.2 Exercice 1 : Algorithmes non préemptifs . . . . . . . . . . . . 35
2.9.3 Exercice 2 : Algorithmes préemptifs . . . . . . . . . . . . . . 36
2.1 Introduction
Tout le logiciel d'un ordinateur peut être vu comme un ensemble de processus
dont l'exécution est gérée par un processus particulier : l'ordonnanceur (Scheduler
en anglais). Un ordonnanceur fait face à deux problèmes principaux :
le choix du processus à exécuter, et
le temps d'allocation du processeur au processus choisi.
Un système d'exploitation multitâche est préemptif lorsque celui-ci peut arrêter
(réquisition) à tout moment n'importe quelle application pour passer la main à
la suivante. Dans les systèmes d'exploitation préemptifs on peut lancer plusieurs
14 Chapitre 2. Ordonnancement des Processus
applications à la fois et passer de l'une à l'autre, voire lancer une application pen-
dant qu'une autre eectue un travail. Il y a aussi des systèmes d'exploitation dits
multitâches, qui sont en fait des multi-tâches coopératifs . Quelle est la dié-
rence ? Un multitâche coopératif permet à plusieurs applications de fonctionner et
d'occuper des plages mémoire, laissant le soin à ces applications de gérer cette oc-
cupation, au risque de bloquer tout le système. Par contre, avec un multi-tâche
préemptif , le noyau garde toujours le contrôle (qui fait quoi, quand et comment),
et se réserve le droit de fermer les applications qui monopolisent les ressources du
système. Ainsi les blocages du système sont inexistants. Un problème d'ordonnan-
cement consiste à organiser dans le temps la réalisation de tâches, compte tenu de
contraintes temporelles (délais, contraintes d'enchaînement) et de contraintes por-
tant sur la disponibilité des ressources requises. En production (manufacturière, de
biens, de service), on peut le présenter comme un problème où il faut réaliser le
déclenchement et le contrôle de l'avancement d'un ensemble de commandes à tra-
vers les diérents centres composant le système. Un ordonnancement constitue une
solution au problème d'ordonnancement. Il est déni par le planning d'exécution des
tâches ( ordre et calendrier ) et d'allocation des ressources et vise à satisfaire
un ou plusieurs objectifs.
2.2 Types d'ordonnanceurs

Il est possible de distinguer trois types d'ordonnanceurs : à long terme, à moyen
terme et à court terme.
Leurs principales fonctions sont les suivantes :
À long terme : L'ordonnanceur fait la sélection de programmes à admettre

dans le système pour leur exécution. Les programmes admis deviennent des
processus à l'état prêt. L'admission dépend de la capacité du système (degré de
multiprogrammation) et du niveau de performance requis.
À moyen terme À moyen terme : Il fait la sélection de processus déjà admis

à débarquer ou rembarquer sur la mémoire. Il eectue ses tâches de gestion en
fonction du degré de multiprogrammation du système, et aussi des requêtes d'E/S
des périphériques.
À cout terme e : L'ordonnanceur à court terme a comme tâche la gestion de

la le des processus prêts. Il sélectionne en fonction d'une certaine politique
le prochain processus à exécuter. Il eectue aussi le changement de contexte
des processus. Il peut implanter un ordonnancement préemptif, non préemptif,
ou coopératif. L'ordonnanceur est activé par un événement : interruption du
temporisateur, interruption d'un périphérique, appel système ou signal
2.3. Objectifs de l'ordonnanceur d'un système multi-utilisateur 15
2.3 Objectifs de l'ordonnanceur d'un système multi-

utilisateur
Les objectifs d'un ordonnanceur d'un système multi-utilisateur sont, entre
autres :
S'assurer que chaque processus en attente d'exécution reçoive sa part de temps
processeur.
Minimiser le temps de réponse.
Utiliser le processeur à 100 Utilisation équilibrée des ressources.
Prendre en compte des priorités.
Être prédictibles.
Ces objectifs sont parfois complémentaires, parfois contradictoires : augmenter

la performance par rapport à l'un d'entre eux peut se faire en détriment d'un autre.
Il est impossible de créer un algorithme qui optimise tous les critères de façon
simultanée.
2.4 Ordonnanceurs non préemptifs

Dans un système à ordonnancement non préemptif ou sans réquisition, le
système d'exploitation choisit le prochain processus à exécuter, en général, le
Premier Arrivé est le Premier Servi PAPS (ou First-Come First Served FCFS) ou
le plus court d'abord (Short Job First SJF). Il lui alloue le processeur jusqu'à ce
qu'il se termine ou qu'il se bloque (en attente d'un événement). Il n'y a pas de
réquisition. Si l'ordonnanceur fonctionne selon la stratégie SJF, il choisit, parmi
le lot de processus à exécuter, le plus court (plus petit temps d'exécution). Cette
stratégie est bien adaptée au traitement par lots de processus dont les temps
maximaux d'exécution sont connus ou xés par les utilisateurs car elle ore un
meilleur temps moyen de séjour. Le temps de séjour d'un processus (temps de
rotation ou de virement) est l'intervalle de temps entre la soumission du processus
et son achèvement.
Considérons par exemple un lot de quatre processus dont les temps respectifs
d'exécution sont a, b, c et d.
Le premier processus se termine au bout du temps a.
Le deuxième processus se termine au bout du temps a+b.
Le troisième processus se termine au bout du temps a+b+c
Le quatrième processus se termine au bout du temps a+b+c+d .
Le temps moyen de séjour :
4a + 3b + 2c + d
< t >= (2.1)
4
On obtient un meilleur temps de séjour pour a≤b≤c≤d
Table 2.1 Données d'ordonnancement

Processus Temps d'exécution Temps d'arrivage
A 3 0
B 6 1
C 4 4
D 2 6
E 1 7
Toutefois, l'ordonnancement du plus court d'abord est optimal que si les travaux
sont disponibles simultanément
Exemple 1
Considérons cinq travaux A, B, C, D et E, dont les temps d'exécution et leurs
arrivages respectifs sont donnés dans la Table 2.1. Faire un schéma qui illustre son
exécution et calculer le temps de séjour de chaque processus, le temps moyen de
séjour, le temps d'attente et le temps moyen d'attente en utilisant :
1. Premier arrivé premier servi (PAPS)
2. Le plus court d'abord (SJF)
Solution 1
Figure 2.1 PAPS. Schéma d'exécution
Au temps 0, seulement le processus A est dans le système et il s'exécute.

Au temps 1 le processus B arrive mais il doit attendre qu'A termine car il a encore
2 unités de temps.
Ensuite B s'exécute pendant 4 unités de temps.
Au temps 4, 6, et7 les processus C, D et E arrivent mais B a encore 2 unités de
temps.
Une fois que B a terminé, C, D et E entrent au système dans l'ordre 1.
Le temps moyen de séjour est :

3+8+9+9+9 38
< t >= = = 7.6 (2.2)
5 5
Le temps d'attente est calculé soustrayant le temps d'exécution du temps de
séjour :
2.4. Ordonnanceurs non préemptifs 17
Table 2.2 Temps de séjour

Processus Temps de séjour
A 3-0=3
B 9-1=8
C 13-4=9
D 15-6=9
E 16-7=9
Table 2.3 Temps d'attente

Processus Temps d'attente
A 3-3=0
B 8-6=2
C 9-4=5
D 9-2=7
E 9-1=8
Le temps moyen d'attente est :
0+2+5+7+8 22
= = 4.4 (2.3)
5 5
Il y a cinq tâches exécutées dans 16 unités de temps, alors :
16
= 3.2 unités de temps par processus. (2.4)
5
2. Le plus court d'abord. Schéma d'exécution :
Figure 2.2 Le plus court d'abord
Pour la stratégie SJF nous aurons la séquence d'exécution A, B, E, D, C, et le

temps de séjour est :
3 + 8 + 2 + 6 + 12 32
< t >= = = 6.4 (2.5)
5 5
Le temps moyen d'attenter est :

A 3-0=3
B 9-1=8
C 10-7=3
D 12-6=6
E 16-4=12

A 3-3=0
B 8-6=2
C 3-1=2
D 6-2=4
E 12-4=8
0+2+2+4+8 16
= = 3.2 (2.6)
5 5
Il y a cinq tâches exécutées dans 16 unités de temps, alors :
16
= 3.2 unités de temps par processus. (2.7)
5
Comment appliquer cette technique aux processus interactifs ? Chaque processus
se comporte comme suit : il attend une commande, l'exécute, attend la commande
suivante, et ainsi de suite. Alors parmi les processus prêts, le processus élu est celui
dont la commande à exécuter est la plus courte en temps. Le temps d'exécution
de la prochaine commande de chaque processus est estimé en se basant sur le
comportement passé du processus : Si T0 est le temps d'exécution estimé pour la
première commande et Ti le temps d'exécution mesuré pour la iime commande, les
estimations successives sont :
T0 pour la première ;
T0 /2 + T1 /2 pour la seconde ;
T0 /4+T1 /4+ T2 /2 pour la troisième ;
T0 /8+ T1 /8+ T2 /4+T3 /2,....
Les ordonnanceurs non préemptifs ne sont pas intéressants pour les systèmes
multi-utilisateurs car les temps de réponse ne sont pas toujours acceptables. Les
algorithmes non préemptifs sont appliqués lorsque les tâches ne peuvent être pré-
emptées, c'est-à-dire où une tâche ayant commencé son exécution doit forcément la
terminer avant qu'une autre tâche ne puisse débuter.
2.4. Ordonnanceurs non préemptifs 19
Table 2.6 Premier arrivé premier servi

Tâche Coût Arrivée
T1 8 1
T2 2 2
T3 4 4
2.4.1 Premier arrivé premier servi
Cet algorithme fonctionne de la manière la plus simple qui soit. Les tâches sont
stockées dans une structure de type FIFO, la première tâche est exécutée, et lors-
qu'elle termine, la suivante est lancée. Les tâches nouvellement activées sont stockées
à la n de la le d'attente. La Figure 2.3 illustre le concept de cet ordonnancement.
Nous pouvons noter que les tâches T1 et T2 doivent attendre un temps important
que la tâche T0 se termine.
Figure 2.3 Exemple d'ordonnancement premier arrivé premier servi
2.4.2 Shortest job rst
An d'éviter que des tâches courtes ne doivent attendre trop longtemps sur des
tâches longues, il est possible d'appliquer un algorithme où la tâche la plus courte est
servie en premier. De ce fait, les tâches courtes sont favorisées, et le temps d'attente
moyen est minimisé. Un des problèmes de cette approche est le risque de famine
des tâches longues. Si de nouvelles tâches courtes son régulièrement réveillées, il se
peut qu'elles passent toujours devant une tâche longue, empêchant ainsi celle-ci de
s'exécuter. La Figure 2.4 illustre le fonctionnement de cet algorithme.
2.4.3 Round robin/tourniquet
L'algorithme du tourniquet (round robin en anglais) vise à traiter les tâches avec
le plus d'équité possible, en allouant un quantum de temps identique à toutes les
Table 2.7 Shortest job rst

T1 8 0
T2 2 0
T3 4 0
Figure 2.4 Exemple d'ordonnancement plus court d'abord
tâches, et à les traiter dans un ordre FIFO. Les tâches sont placées dans une le
d'attente, et la première de la le est exécutée pendant un quantum de temps. A la
n de ce quantum, si la tâche n'est pas terminée, elle est replacée à la n de la le
et une nouvelle tâche est sélectionnée depuis le début de la le. Si la le est vide,
la tâche peut continuer son exécution. La Figure 2.5 illustre cet algorithme, avec un
quantum de temps égal à 2. Nous pouvons noter que la tâche T1 , la plus prioritaire,
est exécutée au départ, puis un tourniquet est eectué pour les deux autres tâches.
Cette technique de tourniquet à priorité correspond à la politique standard observée
dans les systèmes d'exploitation, car elle permet à toutes les tâches de s'exécuter
sans risque de famine.
2.5 Ordonnanceurs préemptifs

Dans un schéma d'ordonnanceur préemptif, ou avec réquisition, pour s'assurer
qu'aucun processus ne s'exécute pendant trop de temps, les ordinateurs ont une hor-
Table 2.8 round robin t

T1 8 0
T2 2 1
T3 4 3
2.5. Ordonnanceurs préemptifs 21
Figure 2.5 Exemple d'ordonnancement tourniquet
Table 2.9 Round robin

Tâche Coût Priorité Arrivée
T1 6 1 0
T2 6 2 0
T3 4 1 0
Figure 2.6 Exemple d'ordonnancement tourniquet avec priorité

loge électronique qui génère périodiquement une interruption. A chaque interruption

d'horloge, le système d'exploitation reprend la main et décide si le processus cou-
rant doit poursuivre son exécution ou s'il doit être suspendu pour laisser place à un
autre. S'il décide de suspendre son exécution au prot d'un autre, il doit d'abord
sauvegarder l'état des registres du processeur avant de charger dans les registres
les données du processus à lancer. C'est qu'on appelle la commutation de contexte
ou le changement de contexte. Cette sauvegarde est nécessaire pour pouvoir pour-
suivre ultérieurement l'exécution du processus suspendu. Le processeur passe donc
d'un processus à un autre en exécutant chaque processus pendant quelques dizaines
ou centaines de millisecondes. Le temps d'allocation du processeur au processus
est appelé quantum. Cette commutation entre processus doit être rapide, c'est-à-
dire, exiger un temps nettement inférieur au quantum. Le processeur, à un instant
donné, n'exécute réellement qu'un seul processus, mais pendant une seconde, le pro-
cesseur peut exécuter plusieurs processus et donne ainsi l'impression de parallélisme
(pseudo-parallélisme).
Problèmes :
Choix de la valeur du quantum.

Choix du prochain processus à exécuter dans chacune des situations suivantes :
1. Le processus en cours se bloque (passe à l'état Attente).
2. Le processus en cours passe à l'état Prêt (n du quantum...).
3. Un processus passe de l'état Attente à l'état Prêt (n d'une E/S).
4. Le processus en cours se termine.
2.5.1 Ordonnancement du plus petit temps de séjour
L'ordonnancement du plus petit temps de séjour ou Shortest Remaining Time

est la version préemptive de l'algorithme SJF. Un processus arrive dans la le de
processus, l'ordonnanceur compare la valeur espérée pour ce processus contre la
valeur du processus actuellement en exécution. Si le temps du nouveau processus
est plus petit, il rentre en exécution immédiatement
2.5.2 Ordonnancement circulaire
L'algorithme du tourniquet, circulaire ou round robin montré sur la Figure 2.7

est un algorithme ancien, simple, able et très utilisé. Il mémorise dans une le du
type FIFO (First In First Out) la liste des processus prêts, c'est-à-dire en attente
d'exécution.
Choix du processus à exécuter

Il alloue le processeur au processus en tête de le, pendant un quantum de temps. Si
le processus se bloque ou se termine avant la n de son quantum, le processeur est
immédiatement alloué à un autre processus (celui en tête de le). Si le processus ne
se termine pas au bout de son quantum, son exécution est suspendue. Le processeur
Figure 2.7 Ordonnancement circulaire
est alloué à un autre processus (celui en tête de le). Le processus suspendu est
inséré en queue de le. Les processus qui arrivent ou qui passent de l'état bloqué à
l'état prêt sont insérés en queue de le.
Choix de la valeur du quantum
Un quantum trop petit provoque trop de commutations de processus et abaisse
l'ecacité du processeur. Un quantum trop élevé augmente le temps de réponse des
courtes commandes en mode interactif. Un quantum entre 20 et 50 ms est souvent
un compromis raisonnable
Exemple 2 :
Soient deux processus A et B prêts tels que A est arrivé en premier suivi de B, 2
unités de temps après. Les temps de UCT nécessaires pour l'exécution des processus
A et B sont respectivement 15 et 4 unités de temps. Le temps de commutation
est supposé nul. Calculer le temps de séjour de chaque processus A et B, le temps
moyen de séjour, le temps d'attente, le temps moyen d'attente, et le nombre de
changements de contexte pour :
SRT
Round robin (quantum = 10 unités de temps)
Round robin (quantum = 3 unités de temps)
Solution SRT :
Figure 2.8 Exemple 2


A 19-0=19
B 6-2=4

A 19-15=4
B 4-4=0
19 + 4 23
< t >= = = 11.5 (2.8)
2 5
4+0 4
= =2 (2.9)
2 2
Il y a 3 changements de contexte
Figure 2.9 Round robin
19 + 12 31
< t >= = = 15.5 (2.10)
2 2
4+8 12
= =6 (2.11)
2 2
Il y a 3 changements de contexte
19 + 8
< t >= = 13.5 (2.12)
2

A 19-0=19
B 14-2=12

A 19-15=4
B 12-4=8=12

A 19-15=4
B 8-4=4
4+4 8
= =4 (2.13)
2 2
Il y a 5 changements de contexte Dans le trois solutions (SRT, RR Qt=10 et RR
Qt =3), il y a 2 tâches exécutées dans 19 unités de temps, alors 19/2=9.5 unités de
temps par processus.
2.5.3 Ordonnancement avec priorité
L'algorithme round robin permet une répartition équitable du processeur. Ce-

pendant il n'est pas intéressant si certains processus sont plus importants ou urgents
que d'autres. L'ordonnanceur à priorité attribue à chaque processus une priorité. Le
choix du processus à élire dépend des priorités des processus prêts. Les processus de
même priorité sont regroupés dans une le du type FIFO. Il y a autant de les qu'il
y a de niveaux de priorité. L'ordonnanceur choisit le processus le plus prioritaire qui
se trouve en tête de le. En général, les processus de même priorité sont ordonnancés
selon l'algorithme du tourniquet.
Figure 2.11 Ordonnancement avec priorité
Exemple 3 :
Les processus qui font beaucoup d'E/S (qui sont souvent en attente) doivent
acquérir le processeur dès qu'ils le demandent, an de leur permettre de lancer leur
requête suivante d'E/S. Lorsqu'un processus passe de l'état élu à l'état bloqué, sa
priorité est recalculée. Sa nouvelle valeur est le rapport : quantum/temps réellement
utilisé par le processus.
Les processus qui ont le plus grand rapport sont les plus prioritaires :
. Si le quantum = 100 ms et le temps utilisé = 2 ms, la nouvelle priorité est 50.
. Si le quantum = 100 ms et le temps utilisé = 50 ms, la nouvelle priorité est 2.
2.6. Ordonnancement à deux niveaux 27
2.5.4 Files multiples (quantum variable)
Pour éviter qu'il y ait beaucoup de commutations pour les processus consom-
mateurs de temps UCT, il est préférable d'allouer un plus grand quantum à ces
processus. Lorsqu'un processus passe à l'état élu : Pour la première fois, le proces-
seur lui est alloué pendant un quantum. Pour la seconde fois, le processeur lui est
alloué pendant 2 quantums. Pour la nime fois, le processeur lui est alloué pendant
2n−1 quantum. Chaque processus a une priorité. Cette dernière dépend du nombre
de quantum qui lui sera alloué lors de sa prochaine activation. Les processus dont le
nombre de quantum est le plus petit sont les plus prioritaires. Les processus prêts
sont répartis selon leur priorité dans des les (FIFO). D'abord on fait l'élection du
processus le plus prioritaire qui se trouve en tête de le. Lorsque l'exécution d'un
processus est suspendue pour la n-ième fois, sa priorité est recalculée 2n puis il est
inséré à la queue de la le appropriée.
Exemple 4 :
Considérons un processus qui doit eectuer des calculs pendant 100 quantums. Ce
processus obtient successivement 1, 2, 4, 8, 16, 32 et 64 quantums. Mais il utilisera
37 des 64 derniers quantums. Le nombre de changements de contexte passe de 100
(cas du tourniquet) à 7. Le processeur passe moins de temps à commuter et a donc
un meilleur temps de réponse. Surtout dans le cas où la commutation nécessite des
transferts sur disque.
Un processus qui descend de plus en plus dans les les à priorité s'exécute de
moins en moins fréquemment et favorise ainsi les processus courts en mode interactif.
Pour ne pas défavoriser un processus qui s'était exécuté pendant assez longtemps
avant de devenir interactif, on peut lui attribuer la plus haute priorité dès qu'un
retour chariot est tapé sur le terminal associé au processus (les premières versions
d'Unix utilisaient cette solution).
2.6 Ordonnancement à deux niveaux
Lors d'une commutation, si le processus élu n'est pas en mémoire, il faut le char-
ger en mémoire. Le temps de commutation est deux à trois fois plus élevé que celui
des processus qui se trouvent en mémoire centrale. Pour éviter ces va-et-vient entre
le disque et la mémoire lors d'une commutation, l'ordonnanceur à deux niveaux dé-
place les processus entre le disque et la mémoire (haut niveau) et choisit le processus
à exécuter parmi ceux qui sont en mémoire (bas niveau). Périodiquement, l'ordon-
nanceur de haut niveau retire de la mémoire les processus qui y sont restés assez
longtemps et les remplace par des processus qui sont restés sur le disque pendant
trop de temps. Pour élire un processus, l'ordonnanceur de bas niveau se restreint au
processus en mémoire.
2.7 Cas d'étude

2.7.1 MS-DOS
MS-DOS est un système mono-utilisateur, et il n'est non plus un système mul-

tiprogrammé. Il peut y avoir, à un moment donné, plusieurs processus en mémoire
mais un seul est à l'état prêt, tous les autres étant en attente de la n d'un ls.
L'ordonnanceur des processus du système MSDOS est très simple : il exécute un
processus jusqu'à ce qu'il se termine ou crée un ls. Le processus créateur est sus-
pendu jusqu'à ce que le processus créé se termine.
2.7.2 Unix
C'est un ordonnanceur à deux niveaux. L'ordonnanceur de bas niveau se charge

d'élire un processus parmi ceux qui résident en mémoire. L'ordonnanceur de haut
niveau se charge des transferts de processus entre la mémoire centrale et le disque.
L'ordonnanceur de bas niveau utilise plusieurs les, une priorité est associée à chaque
le (plusieurs niveaux de priorité). Les processus prêts qui sont en mémoire sont ré-
partis dans les les selon leur priorité. Les priorités des processus s'exécutant en
mode utilisateur sont positives ou nulles, alors que celles des processus s'exécutant
en mode noyau sont négatives. Les priorités négatives sont les plus élevées. L'or-
donnanceur de bas niveau choisit le processus le plus prioritaire qui se trouve en
tête de le. Le processus élu est alors exécuté pendant au maximum un quantum
(100 ms). S'il ne se termine pas ou ne se bloque pas au bout de ce quantum, il est
suspendu. Le processus suspendu est inséré en queue de sa le. La priorité initiale
d'un processus utilisateur est en général égale à 0. La commande nice permet d'at-
tribuer une priorité plus basse à un processus (>0). Les priorités des processus prêts
en mémoire sont recalculées périodiquement toutes les secondes. La priorité d'un
processus est recalculée, dans certaines versions, en ajoutant à sa valeur de base (en
général 0 pour les processus utilisateurs), la moitié du temps UCT utilisé (temps en
nombre de pulsations d'horloge) et la valeur de nice. Lorsqu'un processus passe de
l'état bloqué à l'état prêt, il se voit attribuer une forte priorité (négative). Après le
calcul des priorités, les processus sont déplacés vers les les d'attente correspondant
à leurs nouvelles priorités.
2.7.3 Linux
Linux ore trois politiques d'ordonnancement. Deux d'entre elles sont des po-
litiques d'ordonnancement en temps réel "soft", c'est-à-dire qu'elles accordent aux
processus une très haute priorité par rapport aux autres processus, mais ne garan-
tissent pas une réponse dans un temps spécié. La troisième politique d'ordonnan-
cement utilise un algorithme de temps partagé basé sur des valeurs de priorité. Par
défaut, un processus est associé à la politique de temps partagé. Seul root peut as-
socier un processus à une des classes d'ordonnancement en temps réel.
En Linux, chaque processus se voit attribuer une politique d'ordonnancement. Dans
2.7. Cas d'étude 29
Figure 2.12 Ordonnancement sous Unix
tous les cas, le processus possède aussi une valeur de priorité, variant de 1 à 40. Plus
la valeur est élevée, plus la priorité est haute. Par défaut, un processus utilisateur
a une valeur de priorité de 20. Il est possible, pour un processus, de modier sa
priorité, en utilisant l'appel système nice(valeur), où valeur est un nombre compris
entre -20 et 20. Si la valeur est positive, on diminue d'autant la priorité du processus.
Réciproquement, si la valeur est négative, on augmente la priorité. À noter que seul
root peut augmenter la priorité d'un processus.
Temps réel
Une première politique d'ordonnancement, dénommée SCHED_F IF O, garantit
au processus une utilisation illimitée du processeur. Il ne sera interrompu que dans
une des circonstances suivantes :
Le processus bloque sur un appel système ou se termine.
Un autre processus de la classe SCHED_F IF O de priorité plus élevée est prêt.
Dans ce cas le processus actuel est remplacé par celui-ci.
Le processus libère lui-même le processeur, en exécutant l'appel système
sched_yield().
Rien n'est plus prioritaire qu'un processus de la classe SCHEDF IF O, à

l'exception d'un autre processus de la même classe qui possède une valeur de
priorité supérieure.
L'autre politique d'ordonnancement en temps réel, dénommée SCHED_RR,
est, contrairement à la première, préemptive. Chaque processus de cette classe se
voit attribuer un quantum (temps limite d'exécution). Lorsque ce quantum sera
écoulé, le contrôle sera donné à un autre processus de même priorité de la classe
SCHED_RR, s'il y en a un, en appliquant l'algorithme du tourniquet. À noter
que le tourniquet ne se fait qu'avec des processus de même priorité. Un processus
temps réel de plus haute priorité a toujours préséance. Ainsi, si deux processus de la
classe SCHED_RR avec priorité 20 s'exécutent, ils alterneront dans le processeur.
Si entretemps apparaît un processus de la même classe, mais de priorité 25, c'est
ce dernier qui prend le contrôle du processeur et ne le redonnera que lorsqu'il se
SCHED_RR de
terminera. À moins, bien sûr, que n'apparaisse un autre processus
priorité supérieure ou égale, ou encore un processus SCHED_F IF O. Le quantum
attribué à un processus de la classe SCHED_RR est variable et établi selon les
mêmes principes que ceux appliqués aux processus à temps partagé, décrits à la
section suivante.
Temps partagé
Nous avons vu, à la section précédente, les deux politiques d'ordonnancement en
temps réel oertes par Linux. Il nous reste maintenant à voir la dernière politique
d'ordonnancement, qui regroupe tous les processus de la classe OTHER. Les
processus de cette classe se partagent le processeur de manière inégale, selon leur
priorité et leur usage du processeur. Premièrement, comme nous l'avons déjà dit,
chaque processus possède une valeur de priorité qui lui est attribuée au moment de
sa création. C'est ce que nous appellerons la priorité statique.
Initialement, on attribue à chaque processus un quantum dont la valeur utilise une
unité de temps qui correspond normalement à 10ms. La valeur initiale du quantum
est égale à la valeur de priorité. Ainsi, un processus de priorité 25 aura un quantum
de 25 unités, ce qui correspond à 250 ms. Ce quantum est le temps alloué au
processus. À chaque 10 ms, on diminue de 1 la valeur du quantum du processus en
cours d'exécution dans le processeur.
Chaque fois que l'ordonnanceur est appelé, une note est attribuée à tous les
processus. Cette note, comme nous le verrons à la section suivante, dépend à la fois
de la priorité du processus et de la valeur actuelle de son quantum. C'est cette note
qui permettra de déterminer quel processus prendra le contrôle du processeur.
Éventuellement, on peut arriver à une situation où tous les processus sont dans une
des deux situations suivantes :
. Son quantum est 0. Il a écoulé tout le temps qui lui était alloué.
. Il est bloqué. Il n'a pas nécessairement épuisé son quantum.
Dans ce cas, tous les quanta (y compris les quanta des processus en attente qui ont
encore une valeur non nulle) sont réajustés selon la formule suivante :
Quantum
Quantum ← + P riorite (2.14)
2
Ceci a pour eet de favoriser les processus qui n'ont pas utilisé tout le temps qui
leur est alloué. En eet, un processus qui n'a pas épuisé son quantum se retrouve
avec un nouveau quantum plus élevé que l'ancien.
On peut facilement vérier que la valeur maximale du quantum est deux fois la
priorité.
Comme nous le verrons dans la prochaine section, un processus qui voit son
2.7. Cas d'étude 31
quantum augmenter peut se retrouver avec une meilleure note lorsque vient le
moment de choisir un processus à exécuter.
Ceci a pour eet de favoriser les processus qui n'ont pas utilisé tout le temps qui
leur est alloué. En eet, un processus qui n'a pas épuisé son quantum se retrouve
avec un nouveau quantum plus élevé que l'ancien. On peut facilement vérier que
la valeur maximale du quantum est deux fois la priorité. Comme nous le verrons
dans la prochaine section, un processus qui voit son quantum augmenter peut se
retrouver avec une meilleure note lorsque vient le moment de choisir un processus
à exécuter.
Algorithme d'ordonnancement
Lorsque l'ordonnanceur est appelé, Linux attribue une note à chaque processus,
en utilisant la méthode suivante :
Si le processus est de la classe SCHED_F IF O ou SCHED_RR

Note = 1000 + priorité
Sinon
Si Quantum >0
Note = Quantum + Priorité
Sinon
Note = 0
On remarquera qu'un processus membre d'une des deux classes de temps réel
aura toujours priorité sur les autres. En eet, puisque le quantum ne peut dépasser
le double de la priorité du processus, et que la valeur maximale de la priorité d'un
processus est 40, on n'aura jamais une note supérieure à 120 pour un processus
de la classe OTHER, ce qui est nettement inférieur au minimum de 1000 pour un
processus en temps réel.
On remarquera aussi qu'un processus qui a écoulé tout son quantum reste en attente
tant qu'il y a des processus qui peuvent s'exécuter. Comme nous l'avons déjà dit,
il ne se verra attribuer un nouveau quantum que lorsque tous les autres processus
auront épuisé leur quantum ou seront bloqués.
Exemple 5 :
Supposons trois processus A, B et C, tous de la classe OTHER, et dont les

priorités sont les suivantes
Supposons qu'ils arrivent tous dans le système au même moment et qu'ils sont
seuls. A et B sont des processus qui s'interrompent pour faire des appels système
bloquant, alors que C ne bloque jamais. Initialement, c'est évidemment le processus
A qui a la meilleure note.
Table 2.15 Exemple 5 (1)
Processus A B C
Priorité 20 18 10
Table 2.16 Exemple 5(2)

Processus A B C
Nouveau quantum 4/2 + 20 = 22 14/2 + 18 = 25 0/2 + 10 = 10
C'est donc lui qui est exécuté, ayant droit à 200 ms. Supposons maintenant qu'il
s'interrompt après 160 ms pour exécuter un appel système bloquant.
Le système doit maintenant choisir entre B et C. B est élu et s'exécute pendant 40
ms (lui aussi bloque sur un appel système). À ce moment, le processus C prend
le contrôle et utilise toute la 100 ms qui lui sont accordées. On se retrouve alors
dans la situation suivante : A et B sont toujours bloqués, et C a un quantum nul.
Le système réalisera donc un réajustement des quanta. Les processus se verront
attribuer les nouvelles valeurs suivantes (rappelons qu'il reste 40 ms à A et 140 ms
à B) :
Comme A et B sont toujours bloqués, C s'exécute à nouveau. Supposons

maintenant que A et B redeviennent prêts durant ce temps. Après 100 ms, C a
épuisé son quantum. Il aura une note égale à zéro. Le système choisira alors entre
A et B. Voici les notes qui sont attribuées aux processus :
C'est donc B qui sera choisi, malgré sa priorité statique plus basse. Il est favorisé
parce qu'il a utilisé une proportion plus petite du temps qui lui avait été alloué.
2.8 Windows
L'algorithme d'ordonnancement de Windows est semblable à celui du
VAX/VMS : il est basé sur une priorité qui peut changer au cours de l'exé-
cution des processus. Windows ordonne des threads, sans se préoccuper de savoir à
quel processus ils appartiennent. On n'utilise pas un ordonnanceur autonome :
quand un thread ne peut plus continuer à s'exécuter, il se met en mode superviseur
pour exécuter la routine d'ordonnancement. S'il signale un objet (UP sur un séma-
phore, par exemple), il vérie s'il n'a pas ainsi réveillé un thread plus prioritaire
auquel il doit céder sa place.
Si le quantum est expiré et que le thread est sélectionné à nouveau, on lui attribue
Table 2.17 Exemple 5(3)

Processus A B C
Nouveau quantum 22 + 20 = 42 25 + 18 = 43 0
2.8. Windows 33
un nouveau quantum. Deux autres situations exigent l'exécution de la routine

d'ordonnancement :
Une entrée/sortie vient d'être complétée
Un timeout vient d'expirer (ce qui va en général réveiller un thread)
Un appel SetPriorityClass xe la priorité de base pour tous les threads

d'un processus. Les valeurs possibles sont (en ordre décroissant de priorité) :
realtime, high, above normal, normal, below normal et idle. Un appel
SetThreadPriority permet de xer la priorité d'un thread par rapport aux autres
du même processus. Les valeurs permises sont : time critical, highest, above
normal, normal, below normal, lowest et idle. Selon la combinaison de ces
deux attributs, on attribue à un thread une valeur de priorité entre 0 et 31, qu'on
appelle priorité de base. En plus, chaque thread a une priorité courante qui varie
dynamiquement : elle peut être plus haute que la priorité de base.
À chaque valeur de priorité une le d'attente est associée et Windows parcourt ces
les de manière classique. Chaque le est traitée par l'algorithme du tourniquet.
L'ordonnancement des threads se fait sans tenir compte du processus auquel il
appartient. Le tableau des priorités est divisé en trois segments :
Temps réel (16 à 31)
Utilisateur (1 à 15)
Thread 0 (0)
Seul le SE peut manipuler le segment temps réel. Le thread 0 n'est exécuté que
lorsqu'il n'y a aucun autre thread : il initialise à zéro les pages de mémoire. S'il
n'y a vraiment rien à faire, un thread idle s'exécute. C'est la priorité courante
d'un thread qui est considérée pour l'ordonnancement. La priorité courante d'un
thread utilisateur, qui est initialement la priorité de base, peut être augmentée
dans certaines circonstances :
Le thread vient d'être libéré d'une attente d'entrée/sortie (ex. +1 pour disque,
+6 pour clavier, +8 pour carte son)
Le thread vient d'être libéré d'une attente sur un sémaphore (+2 pour thread
d'un processus en premier plan et +1 pour les autres)
Lorsqu'un thread a expiré son quantum, sa priorité descend de 1 jusqu' à ce qu'il
revienne à sa priorité de base.
Pour éviter les inversions de priorité, Windows utilise la technique suivante :
Quand un thread n'a pas été exécuté depuis un temps qui dépasse un seuil pré
spécié, il passe à la priorité 15 pour deux quanta
Un thread non prioritaire mais qui détient un sémaphore aura donc la chance de
le débloquer pour redonner le contrôle à un thread plus prioritaire en attente sur
ce sémaphore Finalement, un thread associé à une fenêtre qui vient d'être activée
reçoit un plus gros quantum (typiquement 3 X quantum normal).

L'ordonnanceur (planicateur, scheduler) est la partie (un programme) du système
d'exploitation responsable de régler les états des processus (Prêt, Actif,...etc.) et de
gérer les transitions entre ces états. C'est l'allocateur du processeur aux diérent
processus.
Ordonnancement oine : La séquence d'ordonnancement est pré-calculée

avant l'exécution eective. On parle de timedriven scheduling . A l'exécution,
l'ordonnanceur est un simple séquenceur ( cyclic scheduler ).
Ordonnancement online : Les décisions d'ordonnancement sont prises au

cours de l'exécution. A l'exécution, l'ordonnanceur exécute un algorithme d'ordon-
nancement permettant de savoir à tout instant quelle tâche exécuter. Généralement,
ces ordonnancements sont conduits par la priorité des tâches.
Ordonnancement non préemptif :

On n'interrompt jamais une tâche au prot d'une autre tâche, même de priorité
plus forte.
Ordonnancement préemptif :
La tâche en cours peut perdre le processeur au prot d'une autre tâche jugée plus
urgente.
2.9 Exercices
2.9.1 Questions
1. Citez quatre événements qui provoquent l'interruption de l'exécution d'un

processus en cours, dans le système Unix.
2. Quel est le rôle de l'ordonnanceur ?
3. Décrire brièvement l'ordonnanceur du système Unix. Favorise-t-il les processus
interactifs ?
4. Expliquez une raison pour laquelle certains systèmes (tel Unix) assignent des
priorités internes plutôt qu'externes aux processus.
5. Identiez l'algorithme d'ordonnancement qui est le plus utilisé, et spéciez la
raison.
6. Identiez l'algorithme d'ordonnancement sans réquisition qui fournit la meilleure
performance. Pourquoi ?
7. Expliquez la diérence fondamentale entre un algorithme d'ordonnancement à
réquisition et sans réquisition. Lequel fournit la meilleure performance ?
8. Quel sera l'eet sur la performance du système d'un temps de quantum trop
long et trop petit.
9. Expliquez la diérence fondamentale existant entre un ordonnanceur de bas-
niveau et un ordonnanceur de haut-niveau. Existe-il des systèmes d'exploitation
qui utilisent un seul ordonnanceur ? Expliquez aussi.
10. Expliquez quel mécanisme permet à un processus d'eectuer un partage volon-
2.9. Exercices 35
Table 2.18 Exercice 1 : Algorithmes non préemptifs-Tableau1

Tâche Durée d'exécution Arrivée
T1 8 1
T2 2 2
T3 4 4
Table 2.19 Exercice 1 : Algorithmes non préemptifs-Tableau2

Tâche Durée d'exécution
T1 24
T2 3
T3 3
taire de l'UCT. Quels sont les avantages et désavantages du partage volontaire ?

11. Expliquez comment le système détermine le moment d'eectuer un changement
de contexte entre deux processus. Durant un changement de contexte, quels sont
les processus (utilisateur ou système) qui sont chargés et déchargés ?
2.9.2 Exercice 1 : Algorithmes non préemptifs
Les algorithmes non préemptifs sont appliqués lorsque les tâches ne peuvent
être préemptées, c'est-à- dire où une tâche ayant commencé son exécution doit
forcément la terminer avant qu'une autre tâche ne puisse débuter.
1. Premier arrivé premier servi
a- Soit une application composée de trois tâches périodiques T1 , T2 et T3 dont on
connaît les durées d'exécution C1 C2 et C3
En utilisant l'algorithme d'ordonnancement Premier arrivé premier servi :

Donnez un schéma illustrant l'ordonnancement de trois taches T1 , T2 et T3 .
b-Donnez un schéma illustrant l'ordonnancement de trois taches T1 , T2 et T3 si

l'ordre d'arrivée est T1 , T2 et T3 et donnez le temps d'attente moyen.
2. Shortest job rst

An d'éviter que des tâches courtes ne doivent attendre trop longtemps sur des
tâches longues, il est possible d'appliquer un algorithme où la tâche la plus courte
est servie en premier.
a- Soit une application composée de trois tâches périodiques T1 , T2 et T3 dont

on connaît les durées d'exécution C1 , C2 et C3 .
En utilisant l'algorithme d'ordonnancement Shortest job, donner un schéma illus-

trant l'ordonnancement de trois taches T1 , T2 et T3 .
Table 2.20 Exercice 1 : -Tableau3

T1 8 0
T2 2 0
T3 4 0

Tâche Durée d'exécution Ci Arrivée
T1 6 0
T2 8 0
T3 7 0
T4 3 0
b- Soit une application composée de quatre tâches périodiques T1 , T2 , T3 et T4

dont on connaît les durées d'exécution C1 , C2 , C3 et C4 .
Dessinez le chronogramme et donnez le temps d'attente moyen pour la politique
plus courte d'abord.
c- Soit 3 processus,
Dessinez le chronogramme et donnez le temps d'attente moyen pour la politique
plus courte d'abord.
2.9.3 Exercice 2 : Algorithmes préemptifs
Dans le cadre préemptif, une tâche peut être temporairement interrompue par
l'ordonnanceur an de laisser une autre tâche s'exécuter. De ce fait, une tâche très
longue n'a plus de risque de bloquer des tâches plus courtes trop longtemps.
1. Round robin/tourniquet
L'algorithme du tourniquet (round robin en anglais) vise à traiter les tâches avec
le plus d'équité possible, en allouant un quantum de temps identique à toutes les
tâches, et à les traiter dans un ordre FIFO. Les tâches sont placées dans une le
d'attente, et la première de la le est exécutée pendant un quantum de temps. A la
n de ce quantum, si la tâche n'est pas terminée, elle est replacée à la n de la le
et une nouvelle tâche est sélectionnée depuis le début de la le. Si la le est vide,
la tâche peut continuer son exécution.

Tâche Durée en ms
P1 5
P2 3
P3 2
2.9. Exercices 37
Table 2.23 Exercice 2- Round robin/tourniquet

T1 8 0
T2 2 1
T3 4 3
En utilisant l'algorithme d'ordonnancement Round robin/tourniquet, donner un

schéma illustrant l'ordonnancement de trois taches T1 , T2 et T3 avec un quantum
de temps égal à 2.
Chapitre 3
Ordonnancement de Tâches
Périodiques Préemptif à Priorités
Fixes
Contents
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Ordonnancements A priorité Fixe . . . . . . . . . . . . . . . 40
3.2.1 Rate-Monotonic = RM . . . . . . . . . . . . . . . . . . . . 40
3.2.2 Deadline Monotonic = DM . . . . . . . . . . . . . . . . . . 44
3.3 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1 Introduction
Dans la littérature, le terme tâche est souvent préféré pour signier, la pé-
riodicité ou la manière cyclique d'exécution, que ce, du processus dont l'aspect
est attaché plutôt, au sens de l'unicité de la demande d'exécution. Cependant, la
tâche obéit parfaitement, aux principes du multitâche préalablement énoncés le cas
échéant. Les tâches doivent entre autres respecter des délais critiques imposés par
les dynamiques de l'environnement à contrôler. D'un point de vue temporel, les
paramètres suivants peuvent caractériser une tâche :
La date de réveil : qui correspond à l'instant à partir duquel la tâche peut
commencer son exécution,
La durée d'exécution : égale à la borne supérieure du temps processeur nécessaire
à l'exécution de la tâche,
Le délai critique : qui est l'intervalle de temps, à partir de la date de réveil, durant
lequel la tâche doit s'exécuter. En dehors de cet intervalle, son exécution devient
inutile.
La période : est l'intervalle de temps xe qui sépare les arrivées successives
d'une tâche. Ce paramètre concerne les tâches activées par un signal périodique
provenant d'une horloge temps réel interne, c'est le cas par exemple de l'acquisition
de données. Ce type de tâches est appelé tâches périodiques
Chapitre 3. Ordonnancement de Tâches Périodiques Préemptif à
40 Priorités Fixes
3.2 Ordonnancements A priorité Fixe

Cette sous-partie présente les algorithmes qui appartiennent à la famille des
algorithmes d'ordonnancement à priorité xe. Chaque tache a une certaine priorité,
dont héritent ses travaux, et qui est dénie avant l'exécution du systeme et qui
ne varie pas au cours de la vie du système. Généralement, l'ordonnancement est
préemptif, mais ce n'est pas une obligation. En l'absence de précision, l'ordonnanceur
présenté sera considéré comme préemptif.
3.2.1 Rate-Monotonic = RM
L'ordonnanceur Rate Monotonic (RM) est un ordonnanceur à priorité xe. La

priorité des taches est fonction de leur période. Plus précisément, plus la période est
petite et plus la tache est prioritaire.
3.2.1.1 RM préemptif
On peut dire que Rate Monotonic (RM) est un algorithme qui est basé sur des
priorités statiques et qui est optimal. Une tâche dispose d'une priorité xe qui est
inversement proportionnelle à la période. Nous présentons les tests de faisabilité
dans le cas préemptif et non préemptif. Dans [Liu et Layland 1973], les auteurs dé-
terminent une condition susante d'ordonnancabilite pour des systèmes de n tâches
à échéance implicite, sporadiques et à départ simultané. Cette condition susante
est donnée par l'équation 3.1. La preuve donnée par Liu et Layland est contestée
par Devillers et Goossens et est corrigée et complétée par ces derniers [Devillers et
Goossens 2000].
Une condition susante a été dénie par [LL 73]. L'ordonnancement Rate Mo-
notonic d'un ensemble de n tâches périodiques est faisable si le facteur d'utilisation
U vérie la relation suivante :
n
X Ci
U (τ ) = ≤ n 21/n − 1 (3.1)
Ti
i=1
Pour avoir un meilleur ordre de grandeur, il est intéressant de calculer la limite
de cette fonction pour n qui devient grand (Equation 3.1). On trouve que pourn > 5,
la valeur obtenue est déjà très proche de la limite, à savoir environ 0.7.

lim n 21/n − 1 = ln2 ≈ 0.69 (3.2)
n→∞
Enn, si les périodes des taches sont harmoniques, alors la condition susante
d'ordonnancabilité de RM devient :
n
X Ci
U (τ ) = ≤1 (3.3)
Ti
i=1

Ordonnancement RM (Rate-Monotonic : Ordonnancement à taux monotone)
3.2. Ordonnancements A priorité Fixe 41
Table 3.1 U pour un nombre de tâches de 1 à 10

n U
1 100.0
2 82.8
3 78.0
4 75.7
5 74.3
10 71.0
Caractéristiques du RM
Le Rate monotonic a été introduit par Liu and Layland en 1973.
- Basé sur les priorités
- Priorités xes
- Les tâches sont périodiques :
o pas de communication,
o temps de commutation négligeable
- L'échéance correspond à la période (Di =Pei )
- Complexité faible et implémentation facile dans un OS
- Algorithme optimal dans la classe des algorithmes à priorité xe Si la(les) condi-
tion(s) d'ordonnançabilité sont satisfaites : - On calcule la priorité de chaque tâche
comme suit :
Ci
Pri = (Inverse de la priode) (3.4)
Pei
Puis l'ordonnanceur sélectionne le processus avec la plus haute priorité.
Conditions d'ordonnançabilité - Pour qu'un ensemble de tâches soit ordonnançable
pour le Rate-Monotonic, il sut que :
n
X Ci
U= ≤ n 21/n − 1 (3.5)
Pei
i=1
Le tableau suivant donne les valeurs de U pour un nombre de tâches de 1 à 10 :

Cette équation exprime que lorsque : n → ∞ , l'utilisation du processeur doit
rester inférieur à 69.3%. C'est une condition susante (mais non nécessaire)
Rate Monotonic fait partie de la famille des algorithmes à priorité xe. Le
principe consiste à aecter aux tâches des priorités qui sont inversement proportion-
nelles à leurs périodes. Au moment du choix d'une tâche à exécuter, la prochaine
tâche élue est celle ayant la plus forte priorité. Les tâches à ordonnancer doivent
être périodique et à échéance sur requête.
Conditions de faisabilité :
- Condition nécessaire :
42 Priorités Fixes
Table 3.2 Exemple (1) d'ordonnancement RM

Tache Ci Pei Pri
A 3 10 1/10=0.1
B 4 15 1/15=0.06
C 2 20 1/20=0.05
n
X Ci
U= ≤1 (3.6)
Ti
i=1
- Condition susante :
n
X Ci
U= ≤ n 21/n − 1 (3.7)
Ti
i=1
U (1) = 1 ; U (2) = 0.828 ; U (3) = 0.779 ; U (∞) = ln2 ≈ 0.693

L'exemple suivant présente un ordonnancement Rate Monotonic pour trois
tâches périodiques.
3.2.1.2 Exemple (1) d'ordonnancement RM
1 4 2 1/3
U= + + = 0.666 6 3 2 − 1 = 0.779 ⇒ (0.666 ≤ 0.779) (3.8)
10 15 20
test respecté
Les trois tâches respectent leur échéance temporelle. La condition de faisabilité

est vériée. Condition d'ordonnancabilité RM satisfaite
Figure 3.1 Exemple (1) d'ordonnancement RM

3.2. Ordonnancements A priorité Fixe 43

Tache Ci Pei Pri
A 5 10 1/10=0.1
B 8 20 1/20=0.05
C 2 30 1/30=0.033

Tache ri Ci Di Ti Priorité selon RM
T1 0 20 100 100 3
T2 0 40 150 150 2
T3 0 100 350 350 1
15 8 2 1/3
U= + + = 0.966 > 3 2 − 1 = 0.779 (3.9)
10 20 30
- Condition d'ordonnançabilité non satisfaite
- Ordonnançable néanmoins
Figure 3.2 Exemple (2) d'ordonnancement RM
Prenons l'exemple de la conguration à trois tâches décrite dans le Tableau

suivant. Nous vérions que nous sommes en présence d'une conguration de tâches
indépendantes, périodiques, à échéance sur requête et à départ simultané.
Les priorités ont été aectées selon l'algorithme d'ordonnancement RM. Le fac-
teur d'utilisation U de cette conguration est donné par :
44 Priorités Fixes
n
X Ci 20 40 100
U= = + + ≈ 0.75 ≤ 3 21/3 − 1 ≈ 0.779 (3.10)
Ti 100 150 350
i=1
Par conséquent, nous pouvons en déduire que cette conguration de tâches est
ordonnançable. Nous pouvons construire une partie de la séquence qui aura pour
période H :
H = P P CM {Ti }i∈[1,3] = P P CM {100, 150, 350} = 2100 (3.11)
Cette séquence, représentée sur la Figure 3.3., montre en particulier les trois
préemptions de la tâche de plus faible priorité T3 alors que la tâche de plus forte
priorité T1 s'exécute dés sa demand0e (dates de réveil).
Figure 3.3 Exemple d'une partie de la séquence d'exécution d'une conguration
de trois tâches traitées avec l'algorithme RM
Nous pouvons noter aussi la présence de temps libres du processeur qui sur
l'ensemble de la période d'étude sont :
Tlibre = (1 − 0.75238) × 2100 = 520 (3.12)
3.2.2 Deadline Monotonic = DM
L'ordonnanceur Deadline Monotonic est un ordonnanceur à priorité xe avec

pour priorité l'échéance relative de la tâche. Plus l'échéance est petite et plus la
tache est prioritaire. L'aectation des priorités est optimale pour des systèmes de
taches synchrones à échéance contrainte. Dans le cas des systèmes à échéances impli-
cites, Deadline Monotonic et Rate Monotonic se confondent. La condition susante
pour DM pour des systèmes de taches à échéance contrainte, donnée par l'équation
suivante, est similaire à celle de RM.
3.3. Exercices 45
n
X Ci
6 n 21/n − 1 (3.13)
Di
i=1

Deadline Monotonic est un algorithme à priorité xe proche de Rate Monotonic à
ceci près qu'il aecte à une tâche une priorité inversement proportionnelle au délai
critique.
Conditions de faisabilité :
- Condition nécessaire :
n
X Ci
U= 61 (3.14)
Ti
i=1
n
X Ci
U= 6 n 21/n − 1 (3.15)
Di
i=1
U (1) = 1 ; U (2) = 0.828 ; U (3) = 0.779 ; U (∞) = ln2 ≈ 0.693

L'ordonnancement à priorités xes
Intérêts :
- Mécanisme simple
- S'implante naturellement dans les OS du marché
Inconvénients :
- Hypothèses restrictives
- Indépendance des tâches impérative pour l'utilisation des conditions de faisabilité
- Borne supérieure pour le facteur d'utilisation du processeur
3.3 Exercices
Exercice 1 : Rate Monotonic
Rate-Monotonic = plus petite période, plus grande la priorité
Soit une application composée de trois tâches périodiques P1 , P2 et P3 dont on

connaît les durées d'exécution C1 , C2 et C3 et les périodes d'activations T1 , T2 et
T3 .
T1 = 100, T2 = 150, T3 = 350 ,C1 = 20, C2 = 40, C3 = 100
En utilisant l'analyse de Rate Monotonic
- Donner un schéma illustrant l'ordonnancement de P1 , P2 etP3 ?

Un système d'arrosage automatique doit arroser trois types de plantes :
46 Priorités Fixes
Table 3.5 Exercice 4 -(a) : Deadline Monotonic

Tache r0 Ci Di Pi
Tp1 0 1 3 3
Tp2 0 1 4 4
Tp3 0 2 3 6
les plus fragiles qui doivent être arrosées pendant 10 minutes, toutes les 40 minutes,
une deuxième catégorie qui doit recevoir de l'eau pendant 20 minutes, toutes les 60
minutes.
enn, des plantes d'un troisième type qu'il faut arroser toutes les 80 minutes,
pendant 10 minutes.
L'arrosage peut se faire de façon fractionnée, c'est-à-dire s'interrompre et reprendre.
On cherche une solution pour le partage de l'eau entre ces diérentes variétés
de plantes :
Dénir la liste des tâches à accomplir,
Puis, par la stratégie RM :
Calculer l'ordonnançabilité de ces tâches,
Donner un schéma d'utilisation du système d'arrosage à partir du temps 0.

On considère une conguration T de trois (3) tâches T1 , T2 , T3 dénies par :
- T1 (r0 = 0, C = 1, D = 3, P = 3)
- T2 (r0 = 0, C = 1, D = 4, P = 4)
- T3 (r0 = 0, C = 2, D = 3, P = 6)
a) Donner le facteur d'utilisation et la valeur de la période d'étude.
b) Décrire graphiquement les séquences d'exécution obtenues dans le cas de RM
pour cette conguration.
Exercice 4 : Deadline Monotonic

Pour les trois cas (a, b et c) décrire graphiquement les séquences obtenues dans le
cas de l'ordonnancement Deadline Monotonic DM pour cette conguration T et
donner la valeur de la période d'étude.
On considère une conguration T de trois tâches Tp1 , Tp2 , Tp3 dénies par :
a-
b-
c-
On considère un système embarqué muni d'un microprocesseur séquentiel gérant

deux taches indépendantes et périodiques :
3.3. Exercices 47
Table 3.6 Exercice 4 -(b) : Deadline Monotonic

Tache r0 Ci Di Pi
Tp1 0 3 14 20
Tp2 0 2 5 14
Tp3 0 2 15 15
Table 3.7 Exercice 4 -(c) : Deadline Monotonic

Tache r0 Ci Di Pi
Tp1 0 3 7 20
Tp2 0 2 4 5
Tp3 0 2 9 10
Tache 1 : pire temps d'exécution C1 = 2, période(=échéance) D1 = P1 = 6.

Première date d'activation : 2.
Tache 2 : C2 = 3, D2 = T2 = 10. Première date d'activation 0.
1. Calculer le taux d'occupation du CPU et déduire quelque chose sur l'ordon-

nancabilité RM (Rate Monotonic) de ce jeu de taches.
2. Tracer un ordonnancement RM en précisant le choix des priorités des deux

taches.
Sur quelle période est-il susant de dessiner ? pourquoi ?
Exercice 6 :Rate Monotonic
Écrire un programme Arduino qui réalise la tache périodique (de fréquence

100Hz) suivante : lire une entrée sur analog0 et la reproduire sur la sortie analog1
avec un retard de 1s. Le programme aura la forme suivante :
Vous écrirez init et le corps de la boucle innie. On demande d'utiliser la

librairie Arduino de bas niveau (PORT, calcul booléen), dont on fournit une
documentation en annexe.
Ce programme sera évidemment accompagné d'une analyse.
Solution : (Exercice 6)
La fréquence étant 100Hz, et les opérations que nous allons faire pouvant être
considérées comme instantanées, le délai de la boucle sera 10 millisecondes. Passons
à la fonctionnalité.
Pour pouvoir reproduire avec une seconde de délai, il faut stocker 100 valeurs
48 Priorités Fixes
Figure 3.4 Exercice 6 :Rate Monotonic-Code1
successives de l'entrée, et donc l'algorithme consistera en :
Le reste est du calcul booléen avec la syntaxe de C-arduino.

3.3. Exercices 49

Chapitre 4
Ordonnancement de Tâches
Périodiques Préemptif à Priorités
Dynamiques
Contents
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Earliest Deadline First (EDF) . . . . . . . . . . . . . . . . . . 51
4.2.1 Exemple 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Least Laxity First (LLF) . . . . . . . . . . . . . . . . . . . . . 53

4.3.1 Exemple 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.2 Avantage et inconvénient . . . . . . . . . . . . . . . . . . . . 54
4.4 Ordonnancement en situations de surcharge . . . . . . . . . 54

4.5 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.1 Introduction
Nous avons jusqu'à présent considéré que la priorité aectée à une tâche restait
constante pendant toute la durée de l'application. Nous allons nous intéresser à
une autre catégorie d'algorithme d'ordonnancement pour laquelle la priorité des
tâches varie au cours de l'exécution d'une tâche. Cette priorité est fonction d'une
caractéristique temporelle dynamique de la tâche.
4.2 Earliest Deadline First (EDF)

L'algorithme d'ordonnancement EDF a été introduit par Lui et Layland en 1973.
C'est un algorithme d'ordonnancement qui peut être préemptif ou non préemptif et
qui s'applique à des tâches périodiques indépendantes à échéance sur requête (Ti =
Di ). La plus grande priorité à la date t est allouée à la tâche dont l'échéance absolue
est la plus proche. EDF est optimal pour les tâches indépendantes préemptibles.
Une condition d'ordonnançabilité nécessaire et susante de EDF pour un ensemble
de tâches périodiques à échéance sur requête noté Γn est donnée par :
n
X Ci
∀τi ∈ Γi , 61 (4.1)
Ti
i=1
52 Priorités Dynamiques
Earliest deadline rst scheduling ("échéance proche = préparation en premier")

est un algorithme d'ordonnancement préemptif, à priorité dynamique, utilisé dans
les systèmes temps réel. Il attribue une priorité à chaque requête en fonction de
l'échéance de cette dernière selon la règle : Plus l'échéance d'une tâche est proche,
plus sa priorité est grande. De cette manière, au plus vite le travail doit être réalisé,
au plus il a de chances d'être exécuté.
La priorité des tâches est variable au cours de leur exécution et fonction de la
prochaine échéance. Pour une instance k d'une tâche Ti , la priorité est liée à la
prochaine échéance di,k de cette tâche. À un instant t, la priorité peut être calculée
à partir du délai critique dynamique Di (t) qui s'exprime sous la forme :
Di (t) = di,k − t = ri,k + Di − t (4.2)
Nous pouvons faire les deux remarques suivantes :

la priorité est variable, elle change au cours de l'exécution ;
la priorité augmente si le délai critique dynamique de la tâche diminue.
4.2.1 Exemple 1
Figure 4.1 Earliest Deadline First (EDF) -Exemple 1
4.2.2. Avantage et inconvénient Cet algorithme est optimal pour tous types de
système de tâches, cependant, il est assez dicile à mettre en ÷uvre et est donc peu
utilisé. De plus, il ne prévoit aucun compromis "satisfaisant" en cas de surcharge
du système (taux d'utilisation supérieur à 100 %) ; son implémentation est donc un
peu dangereuse dans les systèmes temps réel industriels.

- Principe : à chaque instant, la tâche la plus prioritaire est celle dont
l'échéance absolue di est la plus proche
- Propriété : EDF est optimal dans la classe des algorithmes préemptifs pour des
4.3. Least Laxity First (LLF) 53
tâches périodiques indépendantes telles que Di 6 Ti
- Condition de faisabilité :
Si Di = Ti :
n
X Ci
U= ≤1 (4.3)
Ti
i=1
- Condition nécessaire et susante :

S iDi ≤ Ti :
n
X Ci
U= ≤1 (4.4)
Di
i=1
4.3 Least Laxity First (LLF)

L'algorithme d'ordonnancement LLF se base sur la laxité. La tâche dont la
laxité est la plus faible comparée à toutes les tâches prêtes aura la plus grande
priorité. Cet algorithme est optimal pour les tâches indépendantes pré- emptibles.
D'après, la condition d'ordonnançabilité de LLF et celle de EDF sont les mêmes.
C'est-à-dire que la condition d'ordonnançabilité nécessaire et susante de LLF
pour un ensemble de tâches périodiques à échéance sur requête Γn est donnée par :
n
X Ci
∀τi ∈ Γi , 61 (4.5)
Ti
i=1
Lorsque plusieurs tâches possèdent la même laxité, l'algorithme LLF a l'inconvénient

d'engendrer un grand nombre de préemption ce qui explique qu'il soit aussi peu
utilisé dans le cas monoprocesseur.
- Principe : à chaque instant, la tâche la plus prioritaire est celle dont la laxité
L(t) = ri + Di − (t + Ci (t)) (4.6)
Marge = échéance - durée restante de traitement-temps courant

Marge la plus courte d'abord
- Propriété : LLF est optimal dans la classe des algorithmes préemptifs pour
des tâches périodiques indépendantes telles queDi 6 Ti
4.3.1 Exemple 2

Figure 4.2 Least Laxity First (LLF)-Exemple 2
- Condition de faisabilité :
Si Di = Ti :
n
X Ci
U= ≤1 (4.7)
Ti
i=1
- Condition nécessaire et susante :

Si Di ≤ Ti :
n
X Ci
U= ≤1 (4.8)
Di
i=1
4.3.2 Avantage et inconvénient
- Intérêts :
- Simplicité de mise en ÷uvre
- Optimisation de l'usage des ressources
- Bien adapté aux tâches périodiques à courtes échéances
Inconvénients :
- Indépendance des tâches impératives pour l'utilisation des conditions de faisabilité
- Instabilité en cas de surcharge (EDF)
- Nombreux changements de contexte dans certains cas (LLF)
- Dicilement implantable dans les OS actuels
4.4 Ordonnancement en situations de surcharge

* Quand la charge du processeur est telle qu'il est impossible de respecter toutes
les échéances.
* Origines possibles multiples
4.4. Ordonnancement en situations de surcharge 55
matériel, par exemple une transmission défectueuse qui fait qu'un signal ar-
rive en retard (réseau surchargé)
contention sur une ressource critique
réveil de tâches apériodiques suite à des alarmes
* Les algorithmes à priorités classiques (du type EDF ou RMA) orent des
performances souvent médiocre en cas de surcharge
* Eet "domino" dû à l'arrivée d'une tâche supplémentaire dans un ordonnancement
EDF
Figure 4.3 Notion de surcharge
Figure 4.4 Notion de surcharge
* Dans un contexte temps réel préemptible de n tâches périodiques indépen-

dantes à échéance sur requête, la charge est équivalente au facteur d'utilisation U :
n
X Ci
U= (4.9)
Ti
i=1
Table 4.1 Earliest Deadline First- Exercice 1

Tache Pi Ci Di
T1 20 1 8
T2 5 2 4
T3 10 4 10
* Cas général
basée sur le fait que pour une tâche unique de capacité Ci et de délai critique
Ci
Di , la charge dans l'intervalle [ri , di ] est ρi = Di et (di = ri + Di )
Calculée au réveil des tâches (date t =ri )
P
dk ≤di Ck (t)
ρi (t) = (4.10)
(di − t)
ρ = max (ρi (t))
Exemple
J1 : (C1 = 2, r1 = 3, d1 = 6)
J2 : (C2 = 3, r2 = 1, d2 = 7)
J3 : (C3 = 1, r3 = 2, d3 = 9)
A t=3
ρ1 (3) = 2/3 , ρ2 (3) = 3/4 et ρ1 (3) = 4/6
Figure 4.5 Notion de surcharge-Exemple
4.5 Exercices
Exercice 1 : La conguration suivante est ordonnançable selon l'algorithme
Earliest Deadline First . Si oui, donner la séquence produite par cet algorithme.
4.5. Exercices 57

Tache P riode Dured0 excution
T1 5 1
T2 6 2
T3 15 4
Exercice 2 : Soient 3 tâches T1 ,T2 et T3 , périodiques, indépendantes, à

échéance sur requête et à départ simultané. La politique est préemptive :
a) On peut armer que cette conguration est ordonnançable suivant la

stratégie Earliest Deadline First (EDF). Pourquoi ?
b) Donnez le diagramme modélisant l'occupation du CPU sur une durée susante.
Faites apparaître sur ce diagramme les instants et les raisons de l'appel de l'algo-
rithme de choix dans le cas d'un ordonnancement de ces tâches suivant EDF.
c) Peut-on dire si cette conguration est ou non ordonnançable suivant la stratégie
Rate Monotonic ?
Exercice 3 : Un système d'arrosage automatique doit arroser trois types de

plantes :
Les plus fragiles qui doivent être arrosées pendant 10 minutes, toutes les 40
minutes,
Une deuxième catégorie qui doit recevoir de l'eau pendant 20 minutes, toutes les
heures (60 minutes).
Enn, des plantes d'un troisième type qu'il faut arroser toutes les 80 minutes,
pendant 10 minutes.
L'arrosage peut se faire de façon fractionnée, c'est-à-dire s'interrompre et reprendre.
On cherche une solution pour le partage de l'eau entre ces diérentes variétés de
plantes :
1. Dénir la liste des tâches à accomplir,
2. Puis, pour les stratégies RM et EDF :
o Calculer l'ordonnançabilité de ces tâches,
Donner un schéma d'utilisation du système d'arrosage à partir du temps 0.
Exercice 4 : La conguration suivante est ordonnançable selon l'algorithme

d'aectation de priorité Earliest Deadline First ; pourquoi ? Donner la séquence
produite par cet algorithme.
Est-elle ordonnançable selon la politique Rate Monotonic ? Si oui, donner la
séquence construite et identier les diérences avec la politique précédente. Les
tâches sont à départ simultané.
Dans les deux cas, on considère une politique préemptive.
Exercice 5 : Soit les trois tâches indépendantes et préemptives, toutes prêtes

à la date t=0 :

Tache P riode Dured0 excution Echance
T1 3 2 3
T2 7 2 6
Table 4.4 EDF et LLF Exercice 5

Tache Pi Ci Di
T1 5 2 5
T2 4 1 4
T3 20 2 20
1. Calculer U, le facteur d'utilisation du processeur et la valeur de la période

d'étude.
2. Pour chacune des politiques d'ordonnancement EDF et LLF : Donner un schéma
du séquencement des tâches.
Exercice 6 : Soit les trois tâches indépendantes et préemptives, toutes prêtes

à la date t=0 :
1. Calculer U, le facteur d'utilisation du processeur et la valeur de la période

d'étude.
2.Pour chacune des politiques d'ordonnancement EDF et LLF : Donner un schéma
du séquencement des tâches.
Exercice 7 : On considère une conguration T de trois (3) tâches T1 , T2 , T3

dénies par :

b) Décrire graphiquement les séquences d'exécution obtenues dans le cas des quatre
(4) ordonnancements RM, DM, EDF et LLF pour cette conguration.
Indiquer les cas où les échéances ne sont pas respectées.
Exercice 8 :
On considère les quatre (4) types d'ordonnancement préemptifs suivants :
- Ordonnancement à priorité xe selon la période (à taux monotone), noté RM.
- Ordonnancement à priorité xe selon le délai critique (à échéance monotone),
noté DM.
Table 4.5 EDF et LLF - Exercice 6

Tache Pi Ci Di
T1 6 2 6
T2 8 2 8
T3 12 3 12
4.5. Exercices 59
Table 4.6 EDF et LLF - Exercice 7

Tache Pi Ci Di
T1 3 1 3
T2 4 1 4
T3 6 2 3
Table 4.7 RM, DM, EDF et LLF - Exercice 8

Tache ri Ci Di Di
T1 0 1 3 3
T2 0 1 4 4
T3 0 2 3 6
- Ordonnancement à priorité dynamique selon l'échéance (à échéance la plus

proche), noté EDF.
- Ordonnancement à priorité dynamique selon la laxité dynamique (laxité minimum
), noté LLF.
On considère une conguration T de trois (3) tâches T1 , T2 , T3 dénies par :

b) Décrire graphiquement les séquences d'exécution obtenues dans le cas des quatre
(4) ordonnancements RM, DM, EDF et LLF pour cette conguration. Indiquer les
cas où les échéances ne sont pas respectées.
Chapitre 5
Analyse du Temps de Réponse
Contents
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2 Principaux tests d'ordonnançabilité . . . . . . . . . . . . . . 61
5.2.1 Analyse du facteur d'utilisation . . . . . . . . . . . . . . . . 61
5.2.2 Analyse du temps de réponse . . . . . . . . . . . . . . . . . . 62
5.3 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1 Introduction
La validation des systèmes temps réel impose de vérier que les tâches respectent
leurs contraintes temporelles. Des techniques analytiques spéciques aux systèmes
temps réel ont été conçues pour répondre à cet objectif. Les trois principales ap-
proches sont fondées sur l'analyse du facteur d'utilisation du processeur, l'analyse
de la demande processeur et l'analyse du temps de réponse.
5.2 Principaux tests d'ordonnançabilité

5.2.1 Analyse du facteur d'utilisation
5.2.1.1 Condition susante de Liu and Layland
Contexte : Soit T une conguration de n tâches périodiques indépendantes

à échéance sur requête et à départ simultané. Test : le système T est ordonnancé
faiblement par RM si :

U = n 21/n − 1 (5.1)
Analyse :

lim n × 21/n − 1 = ln2 ≈ 0.69 (5.2)
n→∞
Il en résulte que tout système de tâches indépendantes à échéance sur requête

de charge inférieure à 69% est ordonnancé faiblement par RM.
La complexité du test est linéaire. Ce test a été amélioré, où le système T est
62 Chapitre 5. Analyse du Temps de Réponse
prouvé ablement ordonnancé par RM si :
n
Y
U6 (1 + ui ) (5.3)
i=1
Toutefois, même cette borne hyperbolique domine la borne de Liu et Layland,

la limite de facteur d'utilisation reste la même dans le pire cas (c'est-à-dire,ln2).
Lorsque les périodes des tâches sont des multiples 2 à 2, alors une condition
nécessaire et susante peut être établie à l'aide du facteur d'utilisation du système
de tâche :U ≤ 1.
5.2.2 Analyse du temps de réponse
5.2.2.1 Cas des tâches à échéance contrainte
Contexte : Tâches indépendantes à échéance.

Résultats :
Soit hp (i) l'ensemble des indices de tâches de priorité supérieure (ou égale) à la
priorité de taui , en excluant i .
Par exemple, soient τ = {τ1 , τ2 , τ3 , τ4 } de priorité décroissante , hp (3) = {1, 2}
Le temps de réponse de taui est donné par la charge à traiter plus l'interférence
des tâches de priorité supérieure, en démarrant à l'instant critique, car le pire
temps de réponse de taui intervient dans la plus longue période d'activité de niveau
de priorité prio(i) , et celle-ci démarre (y compris pour les tâches à échéances
arbitraires) à l'instant critique.
Test d'ordonnançabilité :
Le pire temps de réponse de taui est le plus petit point xe de la suite :
Ri0 = Ci (5.4)
& (m)
'
(m+1)
X Ri
Ri = Ci + Cj (5.5)
Tj
j∈hp(i)
Où
- hp (i) est l'ensemble des tâches de plus forte priorité que i;

- dxe est l'entier directement plus grand que x.
(∗)
Si l'on note Ri la valeur du point xe, la condition nécessaire et susante
pour qu'un système soit ordonnançable par une aectation de priorité (RM ou
autre) est que :
(∗)
∀i ∈ [1, n] , Ri 6 Di (5.6)
5.2. Principaux tests d'ordonnançabilité 63
Analyse :
La suite converge si et seulement si U 61
Ce test est de complexité pseudo-polynomiale.
Ordonnancement à priorité xe :

Technique de calcul : on évalue de façon itérative par Rin
& (m)
'
(m+1)
X Ri
Ri = Ci + Cj (5.7)
Tj
j∈hp(i)
On démarre avec Ri0 = Ci
Conditions d'arrêt :
- Échec si Rim > Ti

- Réussite si Rim+1 = wim
Exemple :
T1 =7 ; C1 =3 ; T2 =12 ; C2 =2 ; T3 =20 ; C3 =5
R10 = 3 ⇒ r1 = 3 (5.8)
R20 = 2 (5.9)

1 2
R2 = 2 + 3=5 (5.10)
7

2 5
R2 = 2 + 3 = 5 ⇒ R2 = 5 (5.11)
7
R30 = 5 (5.12)

5 5
R31
=5+ 3+ 2 = 10 (5.13)
7 12

2 10 10
R3 = 5 + 3+ 2 = 13 (5.14)
7 12

13 13
R33 = 5 + 3+ 2 = 15 (5.15)
7 12

4 15 15
R3 = 5 + 3+ 2 = 18 (5.16)
7 12

5 18 18
R3 = 5 + 3+ 2 = 18 ⇒ R3 = 18 (5.17)
7 12
5.2.2.2 Cas des tâches à échéance arbitraire
Contexte : Tâches indépendantes à échéance arbitraire

Résultats : La formule de calcul ne peut pas s'appliquer telle qu'elle est dénie,
car elle ne prend pas en compte la possibilité pour une instance τi,j de la tâche τi
d'interférer avec les instances suivantes de τi . Cependant le résultat suivant reste
valide :
Le temps de réponse de τi est donné par la charge à traiter plus l'interférence des
tâches de priorité supérieure, en démarrant à l'instant critique, car le pire temps de
réponse de τi intervient dans la plus longue période d'activité de niveau de priorité
prio(i), et celle-ci démarre (y compris pour les tâches à échéances arbitraires) à
l'instant critique.
Il faut donc aller jusqu'à la n de la période d'activité initiée par l'instant critique
et regarder dans cette période d'activité quelle est l'instance de la tâche τi avec le
plus long temps de réponse.
Test d'ordonnançabilité :
L'idée est qu'il faut tester toutes les échéances des instances situées dans
la première période d'activité. On évalue ainsi l'activité cumulée des tâches de
priorités supérieures ou égales à τi :
(0)
Wi (k) = kCi (5.18)
(m+1)
X Wm
i
Wi (k) = kCi Cj (5.19)
Tj
j∈hp(i)
(∗)
Ri (k) = Wi (k) − (k − 1) Ti donne le temps de réponse de τi,k (i.e. k ieme
instance de τi ). On applique cette formule de la façon suivante : on commence à
k = 1(on a alors le même fonctionnement que).
(∗)
Si Ri (1) > Di , il y a violation d'échéance (on peut tout de même continuer
si l'on souhaite obtenir le pire temps de réponse).
(∗)
Si Ri (1) > Ti , la deuxième instance fait partie de la première période d'activité,
on termine donc pour k=1 , mais on sait qu'il faudra tester aussi k=2 .
(∗)
De même si Ri (2) > 2Ti , il faudra tester k = 3, etc. tant que on teste k + 1.
Le processus converge si et seulement si U 61 .
Chaque date de n d'instance τi,k est comparée à di,k .
def def
Si nous dénissons ki = min {k | Ri∗ (k) ≤ kTi } et Ri = maxk≤ki Ri∗ (k)
alors Ri∗ est le pire temps de réponse de la tâche τi . Donc, la condition nécessaire
et susante pour qu'un système soit ordonnançable par une aectation de priorité
5.3. Exercices 65
Table 5.1 Analyse du temps de réponse - Exercice 1

Tache Pi Ci Di
T1 20 2 20
T2 20 2 20
T3 10 1 5
T4 10 3 10
(RM ou autre) est que :
(∗)
∀i ∈ [1, n] , Ri 6 Di (5.20)
Analyse :
Ce test est de complexité pseudo-polynomiale.
5.3 Exercices
Exercice 1
En utilisant l'analyse du temps de réponse, vériez si les tâches suivantes peuvent
être ordonnancées :
Prio(T1 ) < P rio(T2 ) < P rio(T3 ) < P rio(T4 )
Solution
Ordonnancement graphique :
Figure 5.1 Analyse du temps de réponse - Exercice 1
Analyse du temps de réponse :
w10 = C1 = 2 (5.21)
X w0
2

2

2
w11 = C1 + 1
Cj = 2 + 2+ 1+ 3=9 (5.22)
Pj 20 5 10
j∈hp(1)
X w0
8

8

8
w12 = C1 + 1
Cj = 2 + 2+ 1+ 3=9 (5.23)
Pj 20 5 10
j∈hp(1)
X w0
9

9

9
w13 = C1 + 1
Cj = 2 + 2+ 1+ 3=9 (5.24)
Pj 20 5 10
j∈hp(1)
R1 = 9 6 P1 = 20 (5.25)
w20 = C2 = 2 (5.26)
X w0
2

2

2
w11 = C1 + 1
Cj = 2 + 2+ 1+ 3=9 (5.27)
Pj 20 5 10
j∈hp(1)
X w0
2

2
w21 = C2 + 2
Cj = 2 + 1+ 3=6 (5.28)
Pj 5 10
j∈hp(2)
X w1
6

6
w22 = C2 + 2
Cj = 2 + 1+ 3=7 (5.29)
Pj 5 10
j∈hp(2)
X w2
7

7
w23 = C2 + 2
Cj = 2 + 1+ 3=7 (5.30)
Pj 5 10
j∈hp(2)
R2 = 7 6 P2 = 20 (5.31)
w30 = C3 = 1 (5.32)
X w0
1
w31 = C3 + 3
Cj = 1 + 3=4 (5.33)
Pj 10
j∈hp(3)
X w0
4
w32 = C3 + 3
Cj = 1 + 3=4 (5.34)
Pj 10
j∈hp(3)
R3 = 4 ≤ P3 = 5 (5.35)
R4 = 43 ≤ P4 = 10 (5.36)
5.3. Exercices 67
Table 5.2 Analyse du temps de réponse - Exercice 2

Tache Pi Ci P rioi Ui
T1 80 40 1 0.50
T2 40 10 2 0.25
T3 20 5 3 0.25
⇒ Ordonnançable
Exercice 2
En utilisant l'analyse du temps de réponse, vériez si les tâches suivantes peuvent
être ordonnancées :
Solution
3
X
Ui = 1 > 0.78 (5.37)
i=1
⇒ On ne peut rien dire
R1 = 80 = P1 (5.38)
R2 = 15 6 P2 = 40 (5.39)
R3 = 5 6 P3 = 20 (5.40)
⇒ Ordonnançable
Chapitre 6
Ordonnancement des Tâches

Indépendantes Apériodiques
Contents
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2 Traitement en arrière plan des tâches apériodiques à
contraintes relatives . . . . . . . . . . . . . . . . . . . . . . . . 70
6.3 Traitement par serveur périodique des tâches apériodiques
en environnement à priorité xe . . . . . . . . . . . . . . . . 71
6.3.1 Serveur à scrutation . . . . . . . . . . . . . . . . . . . . . . . 72
6.3.2 Serveur ajournable . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3.3 Serveur sporadique . . . . . . . . . . . . . . . . . . . . . . . . 77
6.4 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.1 Introduction
L'ordonnancement des tâches apériodiques est traité dans le cas des tâches
périodiques à contraintes strictes et des tâches apériodiques à contraintes relatives
ou à contraintes strictes (tâches sporadiques). Nous supposons que l'ordonnance-
ment des tâches périodiques se fait suivant les algorithmes RM, DM ou EDF. Pour
répondre à la demande d'événements déclenchant des tâches apériodiques, nous
pouvons considérer trois méthodes :
Traitement en arrière plan : les tâches apériodiques sont traitées pendant

les temps d'oisiveté du processeur.
Traitement par utilisation d'un serveur périodique des tâches apério-
diques en environnement à priorité xe pour les tâches périodiques (RM) : en
plus de toutes les tâches périodiques, on insère une tâche, appelée serveur, qui est
destinée à traiter les tâches apériodiques et qui possède diérentes caractéristiques
selon le modèle du serveur :
serveur à scrutation,
serveur ajournable,
serveur à échange de priorité,
serveur sporadique,
serveur à vol de temps creux,
70
Chapitre 6. Ordonnancement des Tâches Indépendantes Apériodiques
serveur à échange de priorité étendu.
Traitement par utilisation d'un serveur périodique des tâches apé-

riodiques en environnement à priorité variable pour les tâches périodiques
(EDF) : en plus de toutes les tâches périodiques, on insère une tâche, appelée
serveur, qui est destinée à traiter les tâches apériodiques et qui possède diérentes
caractéristiques : serveur dynamique à échange de priorité,
serveur dynamique sporadique,
serveur à largeur de bande maximale,
serveur Earliest Deadline Last (EDL),
serveur à échange de priorité amélioré.
L'objet de cet ouvrage n'est pas de faire une description exhaustive de l'ensemble
de ces techniques de prise en compte des tâches apériodiques, mais de donner les
principes généraux de ces diérents traitements en choisissant dans chacune des
catégories les plus représentatifs.
6.2 Traitement en arrière plan des tâches apériodiques

à contraintes relatives
Les tâches périodiques étant ordonnancées par un algorithme à priorité xe
comme RM ou DM (ou éventuellement à priorité variable comme EDF), les tâches
apériodiques sont traitées pendant les temps d'oisiveté du processeur, méthode ap-
pelée aussi vol de temps creux . L'ordonnançabilité de la conguration n'est
nullement remise en cause puisque les tâches apériodiques sont stockées dans une
le d'attente gérée en FIFO ou par priorité et traitée dans le temps libre processeur.
Figure 6.1 Ordonnancement des tâches périodiques et apériodiques dans un

traitement en arrière plan
Cette méthode ne permet pas de traiter les tâches apériodiques strictes car le
temps de réponse de ces tâches traitées en arrière plan n'est pas borné. Aussi, cette
6.3. Traitement par serveur périodique des tâches apériodiques en
environnement à priorité xe 71
Table 6.1 Exemple d'une conguration de deux tâches périodiques indépendantes
à ordonnancer avec l'arrivée de trois tâches apériodiques à contraintes relatives

Tache ri Ci Di Ti
τ1 0 1 4 4
τ2 0 2 6 6
τ3 0 1 x x
τ4 4 4 x x
τ5 13 1 x x
méthode fonctionne correctement si le processeur a un taux de charge pas trop

élevé.
Prenons l'exemple de deux tâches périodiques, indépendantes, à échéance sur
requête et à départ simultané (Tableau 6.1). Le facteur d'utilisation de la con-
guration est U = 0, 75, valeur inférieure à la condition d'ordonnançabilité pour
l'algorithme d'ordonnancement RM. Nous allons étudier le traitement de trois
tâches apériodiques à contraintes relatives dont les paramètres ri et Ci sont donnés
dans le Tableau 6.1.
Nous obtenons des temps de réponse qui sont fonction de la charge processeur
due aux tâches périodiques, des dates d'arrivée des tâches apériodiques et des durées
des traitements de ces tâches apériodiques. En connaissant la charge du système
par les tâches périodiques, il est possible d'évaluer le temps de réponse d'une tâche
apériodique en supposant connues sa date d'arrivée et sa durée d'exécution. Ainsi,
par dénition les ri des tâches apériodiques n'étant pas connus, il est nécessaire
de faire cette évaluation pour toute la séquence d'exécution de la conguration
(période d'étude H). Nous pouvons donc conclure que cette méthode de prise en
compte des tâches apériodiques ne peut concerner que les tâches à contraintes non
strictes, c'est-à-dire acceptant un temps de réponse non borné.
6.3 Traitement par serveur périodique des tâches apé-

riodiques en environnement à priorité xe
An de pouvoir limiter le temps de réponse associé aux requêtes apériodiques,
une tâche périodique spécique, appelé serveur, va être dédiée aux traitements de
ces requêtes apériodiques. Ce serveur ou ces serveurs s'ajoutent à la conguration
de base des tâches périodiques ; il est évident que cet ajout ne doit pas remettre en
cause l'ordonnançabilité de la conguration qui est supposée en absence de tâches
apériodiques.
Ainsi, ces serveurs traitent les tâches apériodiques au moment où ils possèdent
le processeur. Nous allons considérer qu'une tâche apériodique τap,i à contrainte
stricte est caractérisée par les trois paramètres suivants :
72
Figure 6.2 Traitement en arrière-plan des tâches apériodiques à contraintes

relatives
Ci : durée d'exécution maximale ;

Di : délai critique, c'est-à-dire le délai au bout duquel la tâche doit être terminée
par rapport à la date de réveil ;
∆min : distance minimum entre deux occurrences successives de la requête
apériodique.
Un ou plusieurs serveurs périodiques à scrutation sont aectés à une ou plu-

sieurs requêtes apériodiques. La dénition des paramètres temporels de ces serveurs
dépend d'une part des besoins de l'application et d'autre part des caractéristiques
du serveur en termes de paramètres temporels et mode d'exécution (priorité,
conservation de sa capacité de traitement. . . ).
6.3.1 Serveur à scrutation
Le premier type de serveur le plus simple est le serveur à scrutation. Ce serveur à

scrutation est une tâche périodique τs possédant les paramètres temporels classiques
(rs , Cs ,Ds , Ts ). Ce serveur traite les tâches apériodiques qu'il trouve en attente lors
de son activation ; s'il n'y a pas de tâches en attente, le serveur se suspend et attend
la prochaine période d'activation. Le point crucial est donc de déterminer les para-
mètres du serveur par rapport aux paramètres temporels de la requête apériodique
stricte à servir.
Nous allons nous placer dans le cas où un serveur est aecté à une requête apério-
dique stricte donnée ; par conséquent il est naturel de xer la durée d'exécution du
serveur égale à la durée de la tâche apériodiqueCs = Cap . Dans le cas où nous avons
requête apériodique stricte, caractérisée par une échéanceDap et une distance mi-
nimum entre deux occurrences successives de ∆min , les caractéristiques du serveur
(Ds , Ts ) peuvent être élaborées dans le cas le plus défavorable où l'activation du
serveur a été demandée mais annulée car l'événement n'était pas présent à l'instant
de l'activation et l'occurrence eective de l'événement se produit immédiatement
après avec un décalage très faible ∆t = ε. Dans ce cas extrême pour satisfaire les
contraintes temporelles attachées à cette requête, nous devons résoudre l'inéquation
suivante :
Ts + Ds ≤ Dap ≤ ∆min (6.1)
Si nous considérons le serveur comme une tâche périodique à échéance sur requête
(Ds =Ts ), nous avons la relation simpliée de l'équation précédente :
Dap
Ts ≤ (6.2)
2
Il est important de noter que cette dénition des paramètres temporels du serveur à
scrutation permet de borner le temps de réponse du service de la tâche apériodique
quel que soit sa date d'occurrence dans la séquence d'exécution. Le temps de réponse
est donc égal à :
T Rap ≤ Ts + Ds ≤ Dap (6.3)
Dans ce cadre la dénition des paramètres du serveur en fonction des paramètres

de tâche apériodique stricte est donnée dans le Tableau 6.2. De la même façon que
pour les tâches périodiques, nous pouvons représenter graphiquement le domaine des
valeurs possibles pour ce serveur en fonction des paramètres de la tâche apériodique.
Dans cette représentation, il est possible de lire directement sur le graphique le temps
de réponse maximum du serveur. Prenons l'exemple de deux tâches périodiques,
indépendantes et à départ simultané. En considérant une troisième tâche τs , serveur
à scrutation, avec la valeur maximale de sa période égale à 12, le facteur d'utilisation
de la conguration estU = 0, 7. Avec un facteur d'utilisation du processeur à 100%,
la période minimale de la tâche τs est T = 6. Nous allons tester les deux algorithmes
d'ordonnancement DM et EDF sur cette conguration composée de deux tâches
périodiques et d'un serveur périodique. Les résultats au niveau des deux paramètres
D et T de la tâche τs , présentés respectivement sur les gures suivantes, montrent
que le concepteur peut choisir parmi 20 points possibles pour l'ordonnancement DM
et 23 points pour l'ordonnancement EDF.
De même que dans le cas des tâches périodiques gérées selon l'algorithme Rate
Monotonic, il est possible d'avoir une autre condition susante d'ordonnançabilité.
Soit un ensemble de n tâches périodiques T (τ1 ,τ2 , τ3 , . . . ,τi , . . . , τn ) dénies par
les paramètres temporels (ri , Ci , Di , Ti ) et un ensemble de p serveurs périodiques
(τs1 , τs2 , τs3 , . . . , τsi , . . . , τsn ) dénies par les paramètres temporels (rsi , Csi ,
Dsi , Tsi ), la conguration est ordonnançable si
74
Table 6.2 Schéma d'adaptation d'un serveur à scrutation pour répondre à une
requête apériodique.
T ache apriodique Serveur scrutation
ri ? → 0
Ci Cap → Cs = Dap
Di Dap & Ds
Ti ∆ap Ts + Ds ≤ Dap
Figure 6.3 Analyse temporelle de l'adaptation d'un serveur à scrutation pour

répondre à une requête apériodique
n p
X Ci X Cap,j 1
Utotal = U + Us = + 6 (n + p) 2 (n+p) − 1 (6.4)
Ti Tap,j
i=1 j=1
Considérons l'exemple de deux tâches périodiques, indépendantes, à échéance

sur requête et à départ simultané. Une troisième tâche périodique est ajoutée à la
conguration pour traiter les arrivées de tâches apériodiques. La capacité de trai-
tement des requêtes apériodiques de ce serveur est : une durée d'exécution de 1
(Cs = 1) et un temps de réponse maximum de 10 (2Ts ). Le facteur d'utilisation de
la conguration complète est U = 1, valeur supérieure à la condition d'ordonnança-
bilité pour l'algorithme d'ordonnancement RM. La période d'étude étant H = 20,
il sut de tester l'ordonnançabilité de la conguration sur cette durée. Il est aisé de
vérier que la conguration de ces trois tâches périodiques est ordonnançable avec
l'algorithme RM.
Étant donné que la troisième tâche est un serveur à scrutation de tâches apé-
riodiques, celle-ci ne s'exécute pas à chaque réveil si aucune requête de traitement
apériodique n'est arrivée. La Figure 6.4 représente la séquence d'exécution avec l'ar-
rivée de deux requêtes apériodiques strictes τap,1 (durée Cap,1 = 1) et tap,2 (durée
Cap,2 = 2) aux instants respectifs r1 =5 et r2 =12. La première tâche apériodique
stricte a une échéance de 10 par rapport à son réveil, ce qui explique les para-
mètres du serveur (2τs = 10 ≤ Dap,1 ). La deuxième tâche apériodique stricte a
une échéance de 15 étant donné que son temps d'exécution est le double de celui du
serveur ; il sera nécessaire d'avoir deux exécutions du serveur pour traiter complè-
Table 6.3 Exemple d'une conguration de trois tâches périodiques indépendantes,
la troisième tâche, serveur à scrutation de tâches apériodiques.

Tache ri Ci Di Ti
τ1 0 4 10 10
τ2 0 8 20 20
τs 0 1 5 5
τap,1 5 1 10 x
τap,2 2 2 15 x
tement cette requête (2τs + τs = 15 ≤ Dap,2 ). Le temps de réponse du traitement

de ces deux requêtes apériodiques strictes, respectivement 1 et 9, montre que les
bornes maximales sont respectées. En revanche, dans le cas de la deuxième tâche
apériodique stricte, le réveil inutile du serveur au temps 10, puis l'arrivée de cette
requête apériodique stricte au temps 12 conduit à allonger le temps de réponse.
Figure 6.4 Exemple de l'exécution de la conguration de tâches donnée dans le
Tableau 6.2 : ordonnancement avec l'algorithme RM.
6.3.2 Serveur ajournable
Par rapport à la méthode précédente, la méthode du serveur ajournable

autorise le serveur à conserver sa capacité de traitement pendant toute la
période, c'est-à-dire qu'une tâche apériodique peut arriver pendant cette durée et
être servie. En début de période, la charge du serveur est remise dans son état initial
76
quelle que soit la capacité utilisée. En donnant généralement une priorité forte au
serveur (tâche de période faible), cela permet de réduire le temps de réponse
moyen. Ainsi, l'exemple de la Figure 6.5 montre le principe du serveur ajournable
(évolution de sa capacité de traitement en fonction du temps) et son application
sur l'arrivée de requête apériodique stricte. Pour un serveur de caractéristiques tem-
porelles (0,Cs = 2, Ds = 4, τs = 4), seule la dernière tâche apériodique n'est pas
traitée immédiatement. Par rapport au serveur à scrutation, le temps de réponse à
la requête apériodique est réduit à son minimum puisque le serveur peut prendre
en compte cette tâche apériodique à tout instant de l'exécution. La seule condition
requise est que la capacité du serveur soit en adéquation avec la durée d'exécution
de la tâche apériodique. Considérons l'exemple de deux tâches périodiques, indé-
pendantes, à échéance sur requête et à départ simultané (Tableau 6.4).
Figure 6.5 Serveur ajournable
Une troisième tâche périodique est ajoutée à la conguration pour traiter les
arrivées de tâches apériodiques strictes. La capacité de traitement des requêtes apé-
riodiques strictes de ce serveur ajournable est : une durée d'exécution de 2 (Cs =2).
Le facteur d'utilisation de la conguration complète est U = 0, 87, valeur supérieure
à la condition d'ordonnançabilité pour l'algorithme d'ordonnancement RM. La pé-
riode d'étude étant H = 168, il est nécessaire de tester l'ordonnançabilité de la
conguration sur cette durée. Il est aisé de vérier que la conguration de ces trois
tâches périodiques est ordonnançable avec l'algorithme RM. Dans ce test d'ordon-
nançabilité, il est important de remarquer que le serveur s'exécute à chaque réveil et
dès l'instant de son réveil étant donné sa priorité supérieure aux deux autres tâches.
Pour analyser la réponse de ce serveur ajournable à des requêtes apériodiques

strictes, nous considérons trois demandes d'exécution de tâches apériodiques strictes
dénies par : τap,1 (rap,1 = 1, Cap,1 = 2), τap,2 (rap,2 = 12, Cap,2 = 2) et τap,3 (rap,3 =
18, Cap,3 = 1) . La Figure 6.6 montre l'acceptation immédiate de ces requêtes apé-
riodiques strictes par le serveur ajournable avec un temps de réponse minimum
Table 6.4 Exemple d'une conguration de trois tâches périodiques indépendantes,
la troisième tâche, serveur ajournable de tâches apériodiques.

Tache ri Ci Di Ti
τ1 0 2 7 7
τ2 0 8 8 8
τs 0 2 6 6
égal aux durées de traitements des tâches apériodiques strictes. Le serveur s'exé-
cute donc à des instants non prévisibles de sa période. En conséquence, le serveur
ayant une priorité forte et conservant sa capacité d'exécution au cours de sa pé-
riode, il y a contradiction avec l'algorithme d'ordonnancement : une tâche de
priorité forte activable doit s'exécuter . Ce problème peut conduire à des dépasse-
ments d'échéance. Ainsi, considérons trois requêtes d'exécution tâches apériodiques
strictes dénies par : τap,1 (rap,1 = 1, Cap,1 = 2), τap,2 (rap,2 = 7, Cap,2 = 2) et
τap,3 (rap,3 = 12, Cap,3 = 2). La Figure 6.7 montre l'acceptation immédiate de ces
requêtes apériodiques par le serveur ajournable. Cette acceptation à n'importe quel
instant de la séquence d'exécution conduit la tâche périodique τ2 à dépasser son
échéance. De même que dans le cas des tâches périodiques gérées selon l'algorithme
Rate Monotonic, il est possible d'avoir une autre condition susante d'ordonnança-
bilité dans le cas de l'algorithme RM associé au serveur ajournable. Soit un ensemble
de n tâches périodiques (τ1 , τ2 , τ3 , . . . , τi , . . . , τn ) dénies par les paramètres tempo-
rels (ri , Ci , Di , Ti ) et un serveur périodique ts dénie par les paramètres temporels
(rs , Cs , Ds , Ts ) avec Us = C s
Ts , la conguration est ordonnançable si :
n
X Ci Us + 2
U= ≤ ln (6.5)
Ti 2Us + 1
i=1
Avec
Cs
Us = (6.6)
Ts
Donc le facteur de charge total est donné par :
n
X Ci Us + 2
Utotal =≤ U + Us = + ln (6.7)
Ti 2Us + 1
i=1
6.3.3 Serveur sporadique
Pour améliorer les performances du serveur précédent, serveur ajournable,

il faut diminuer cette possibilité totale à conserver la capacité pendant toute la
période, ce problème pouvant conduire à des dépassements d'échéance pour les
tâches périodiques. Deux méthodes peuvent être utilisées pour cela :
Le serveur à échange de priorité : le serveur ne conserve pas sa forte priorité
pendant toute sa séquence. Mais si aucune requête apériodique ne survient, il
prend la priorité de la dernière tâche en exécution. Cette diminution de priorité
78
Figure 6.6 Exemple de l'exécution de la conguration de tâches donnée dans le
tableau 6.4 : ordonnancement avec l'algorithme RM.
Figure 6.7 Exemple de l'exécution non valide de la conguration de tâches donnée
dans le Tableau 6.3 avec l'arrivée de trois requêtes apériodiques strictes

conduit à préserver l'exécution de tâches périodiques moins prioritaires initialement.
Le serveur sporadique : la méthode est basée sur le fait que sa capacité ne se

recharge qu'à l'instant de sa consommation augmenté de sa période. Ainsi, l'exemple
de la Figure 6.8 montre le principe du serveur sporadique (évolution de sa capacité
de traitement en fonction du temps) et son application sur l'arrivée de requête
apériodique stricte. Pour un serveur de caractéristiques temporelles (0, Cs = 2, Ds =
4, Ts = 4), seules les deux dernières tâches apériodiques strictes n'ont pas été traitées
immédiatement, résultat meilleur que le serveur à scrutation, mais moins bon que
le serveur ajournable. Comparons le fonctionnement de ce serveur sporadique avec
le serveur ajournable pour le même exemple décrit dans le Tableau 6.3 et la Figure
6.8 intégrant trois requêtes d'exécution de tâches apériodiques strictes dénies par :
τap,1 (rap,1 = 1, Cap,1 = 2), τap,2 (rap,2 = 7, Cap,2 = 2) et τap,3 (rap,3 = 12, Cap,3 = 2).
La séquence d'exécution, présentée sur la gure Figure 6.9, est valide en comparaison
de celle obtenue avec le serveur ajournable. Cette ordonnançabilité est obtenue grâce
au décalage du serveur et conduit donc à un temps de réponse augmenté de la
troisième tâche apériodique stricte.
Figure 6.8 Représentation du principe de fonctionnement du serveur sporadique
avec la visualisation de sa capacité de traitements
Il est possible d'avoir une autre condition susante d'ordonnançabilité dans

le cas de l'algorithme RM associé au serveur ajournable. Soit un ensemble de
n tâches périodiques (τ1 , τ2 , τ3 , . . . , τi , . . . , τn ) dénies par les paramètres tempo-
rels (ri , Ci , Di , Ti ) et un serveur périodiqueτs dénie par les paramètres temporels
(rs , Cs , Ds , Ts ) avec Us = C s
Ts , la conguration est ordonnançable si :
n
X Ci 2
U= ≤ ln (6.8)
Ti Us + 1
i=1
Donc, le facteur de charge total est donné par :
n
X Ci 2
Utotal =≤ U + Us = + ln (6.9)
Ti Us + 1
i=1
Il est intéressant de comparer cette limite du serveur sporadique et du serveur

ajournable. La Figure 6.10 montre que la courbe associée au serveur ajournable
80
Figure 6.9 Exemple de l'exécution valide de la conguration de tâches donnée
dans le Tableau 6.3 avec l'arrivée de trois requêtes apériodiques strictes
passe en dessous de la limite de l'algorithme RM, alors que la courbe associée au

serveur sporadique reste au-dessus de cette limite. En conclusion, dans le contexte
d'algorithme à priorité xe (RM ou DM), le serveur sporadique permet de répondre
aux requêtes apériodiques et de traiter la tâche apériodique associée avec un temps
de réponse minimum en conservant l'ordonnançabilité de la conguration initiale,
serveur inclus.
Figure 6.10 Exemple de l'exécution valide de la conguration de tâches donnée
avec l'arrivée de trois requêtes apériodiques strictes
6.4 Exercices
Exercice 1
Exemple de serveur par scrutation (ordonnancement RM)
3
X Ci 3 2 2
= + + = 0.75 6 n 21/n − 1 (6.10)
Pi 20 5 10
i=1
6.4. Exercices 81
Table 6.5 serveur par scrutation-Exercice 1

Tache ri Ci Di Ti
τ1 0 3 20 20
τ2 0 2 10 10
τs 0 2 5 5
Figure 6.11 Exemple de serveur par scrutation (ordonnancement RM)-Exercice
Tâches apériodiques : Ta3 (r = 4, C = 2), Ta4 (r = 10, C = 1), Ta5 (r = 11, C = 2)
Figure 6.12 Exemple de serveur par scrutation-Exercice 1
Exercice 2
Exemple de serveur sporadique à haute priorité.

-2 tâches périodiques : τ1 et τ2
-Serveur : τs
-Tâches apériodiques : τa3 ,τa4 et τa5
82
Table 6.6 serveur sporadique-Exercice 2

Tache ri Ci Di Ti
τ1 0 3 20 20
τ2 0 2 10 10
τs 0 2 5 5
τa3 4 2 x x
τa4 10 1 x x
τa5 11 2 x x
Figure 6.13 serveur sporadique-Exercice 2

Chapitre 7
Noyau Temps Réel
Contents
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2 Système d'exploitation et noyau . . . . . . . . . . . . . . . . 84
7.2.1 Boucle d'interrogation . . . . . . . . . . . . . . . . . . . . . . 85
7.2.2 Tâche pilotée par état/phase et Co-routines . . . . . . . . . . 86
7.3 Le noyau temps réel µC/OS − II . . . . . . . . . . . . . . . . 88

7.3.1 Les chiers source de MicroC/OS-II . . . . . . . . . . . . . . 89
7.3.2 Comparaison entre uC/OS et uC/OS-II . . . . . . . . . . . . 92
7.3.3 Services du noyau (1) . . . . . . . . . . . . . . . . . . . . . . 92
7.4 Le noyau temps réel RTLinux . . . . . . . . . . . . . . . . . . 94

7.5 Le noyau temps réel VXWorks . . . . . . . . . . . . . . . . . 95
7.6 Le noyau temps réel pSOS . . . . . . . . . . . . . . . . . . . . 95
7.1 Introduction
Un système d'exploitation temps réel, en anglais RTOS pour real-time opera-
ting system (prononcé Are-toss) est un système d'exploitation multitâche destiné
aux applications temps réel. Ces applications comprennent les systèmes embarqués
(thermostats programmables, contrôleurs électroménagers, téléphones mobiles), des
robots industriels, les vaisseaux spatiaux, les systèmes de contrôle commande in-
dustriel, et le matériel de recherche scientique. Un RTOS facilite la création d'un
système temps réel, mais ne garantit pas que le résultat nal respecte les contraintes
temps réel, ce qui exige le développement correct du logiciel.
Un RTOS n'a pas nécessairement pour but d'être performant et rapide, mais un
RTOS fournit des services et des primitives qui, si elles sont utilisées correctement,
peuvent garantir les délais souhaités. Un RTOS utilise des ordonnanceurs spécialisées
an de fournir aux développeurs des systèmes temps réel les outils et les primitives
nécessaires pour produire un comportement temps réel souhaité dans le système
nal.
Un système d'exploitation temps-réel est une catégorie de sys. d'exploitation per-
mettant la programmation et l'exécution de tâches temps-réel. - Il ne dière pas
fondamentalement d'un OS standard "non" temps-réel.
- Il est généralement plus simple, plus petit (car destiné à être embarqué) et ore
moins de confort au niveau du développement. Un OS temps-réel permet de gérer
84 Chapitre 7. Noyau Temps Réel
le temps de manière "stricte" (temps-réel strict) ou non (temps-réel souple).

- Ordonnancement spécique des tâches temps-réel
- Structures de données "temps-réel"
- Accès direct au matériel
7.2 Système d'exploitation et noyau

Les deux principaux services oerts par le noyau temps réel sont le contexte
switching et le scheduler :
Context switching : Charger l'état CPU du nouveau Process et rendre
accessible ses diérentes zones mémoires.
Scheduler : Planier l'usage du CPU en déterminant quelle tâche sera la
prochaine à en obtenir le contrôle. Pour cela, la plupart des noyaux se basent sur
un système de priorité attribué à chaque tâche, de telle manière que ce soit toujours
la plus prioritaire qui soit choisie.
- Un noyau est la partie la plus petite partie du système d'exploitation.

- Le noyau fournit 3 fonctionnalités :
Figure 7.1 Hiérarchie de noyau
Systèmes embarqués temps réel :

- Les systèmes d'exploitation génériques commerciaux sont souvent trop lourd et
trop tout usage pour les systèmes en temps réel (ex. : Windows, Unix, Linux,
. . . ).
- Les développeurs de systèmes en temps réel doivent concevoir leur propre
squelette de système d'exploitation ou utiliser un système d'exploitation spécialisé
commercial (ex. : µC/OS − II , RT-Linux, QNX, VXworks, IRIX, RT-UNIX).
- Pour les systèmes embarqués sur mesure, il n'existe pas de systèmes d'exploita-
7.2. Système d'exploitation et noyau 85
Table 7.1 Système d'exploitation et noyau

Système d'exploitation Exécutif + interface usager généra-
lisée,sécurité et gestion du système
de chier.
Exécutif Noyau + privatisation des blocs de

mémoire, services d'I/O et autres
fonctions complexes.
Noyau Micro-noyau + communication

inter-tâches et Synchronisation (sé-
maphores, boîtes à lettres, Mutex,
. . . )..
Micro-noyau Nano-noyau + ordonnanceur.
Nano-noyau Gestion simple des tâches (threads).

Fournit seulement la fonction de ré-
partition.
tion commerciaux.
Pourquoi utiliser/concevoir un OS en temps réel ?
- Permet de mieux utiliser les ressources
Traitement parallèle / Programmation concurrente
- Facilite le développement Programmation par tâche (thread) / Diviser pour
régner
- Plus robuste
Gestion des accès aux ressources / Gestion des tâches
Figure 7.2 Hiérarchie de noyau
7.2.1 Boucle d'interrogation
Caractéristiques :
- Noyau temps réel le plus simple.
- L'ordonnancement est codé directement et est xe (séquence de l'interrogation).
- Le répartiteur est codé directement et est xe (boucle d'interrogation → liste des
tâches, appel des tâches → sauvegarde du contexte).
- Communication inter-tâche par passage de paramètres et/ou variables globales.
Temps de réponse :
- Rapide pour une seule tâche

- Augmente avec le nombre de tâche
- Tâches exécutées au complet.
Figure 7.3 Boucle d'interrogation
Avantages :
- est simple à concevoir et à déverminer.
- est robuste.
- est excellente pour traiter des canaux de communication de grande vitesse.
Désavantages :
- ne permet pas de traiter les rafales d'évènements.
- n'est pas adaptés aux systèmes compliqués.
- gaspille beaucoup de temps de processeurs (facteur d'utilisation du CPU faible).
- ne permet pas la superposition d'évènements.
- lorsque plusieurs tâches à gérer, le temps de réponse devient rapidement exagéré.
7.2.2 Tâche pilotée par état/phase et Co-routines
Tâche pilotée par état/phase :

- La tâche est représentée sous la forme :
- d'une série de phases.
- d'une série d'états (machine à états nis).
L'exécution des phases/états est déterminé par :
- des Si. . . alors imbriqués.
- des Switch. . . case.
- une table de transition d'états.
7.2. Système d'exploitation et noyau 87
- Le processeur est libéré après chaque phase/état.

- Facilite les traitements multitâches coopératif tel que la méthode des coroutines
- Approprié pour le traitement de tâches modélisées par états/phases.

- Le séquenceur est de type Round-Robin :
- chaque phase s'exécute jusqu'à la n.
- le contrôle est rendu au séquenceur à la n de chaque phase.
- le séquenceur choisit la prochaine tâche de la liste.
- Le répartiteur contient la liste des tâches et leur contexte.
- La communication inter-tâche et intratâche est réalisée par variables globales.
Figure 7.4 Tâche pilotée par état/phase et Co-routines
Avantages :
- Simplie la conception du système en divisant le travail en une série de tâches
indépendantes ou quasi-indépendantes.
- Le nombre de tâche ne doit pas être obligatoirement connu à l'avance.
- Temps de réponse assez bon et facile à déterminer.
Désavantages :
- Exige de diviser les tâches en phases/états, ce qui n'est pas toujours possible ou
facile à faire.
- Les tâches doivent être divisé en morceaux de taille uniforme.
- Le temps de réponse dépend directement de la phase la plus longue.
- Chaque tâche/phase/état sont de priorité égale.
Figure 7.5 Séquenceur/ Répartiteur
- Approprié pour le traitement de tâches modélisées par états/phases.

- Le séquenceur est de type Round-Robin :
- chaque phase s'exécute jusqu'à la n.
- le contrôle est rendu au séquenceur à la n de chaque phase.
- le séquenceur choisit la prochaine tâche de la liste.
- Le répartiteur contient la liste des tâches et leur contexte.
- La communication inter-tâche et intra-tâche est réalisée par variables globales.
7.3 Le noyau temps réel µC/OS − II

µC/OS-II est un noyau temps réel de type préemptif développé par Jean J. La-
brosse capable de gérer jusqu'à 64 tâches simultanément.
Ses principaux avantages sont :
- Ouvert, code source disponible
- Portable
- Multitâches et préemptif
- Interruptible
- Fiable et robuste
7.3. Le noyau temps réel µC/OS − II 89
Figure 7.6 Taches
Table 7.2 Le chier OS_CFG.H

#dene OS_ TASK_ STAT_ EN 1
#dene OS_ TASK_ STAT_ STK_ SIZE 512
Comme principal défaut par rapport aux noyaux commerciaux, précisons que
mCOS-II ne gère pas l'algorithme de Round-Robin permettant à deux tâches de
même priorité de partager l'usage du CPU. On est ici obligé de ne permettre qu'une
seule tâche par niveau de priorité.
MicroC/OS-II est une bibliothèque qui est liée avec l'application à développer
Les services de MicroC/OS-II sont appelés depuis l'application comme des
fonctions
Le code source est divisé en 2 sections :
Indépendant du processeur
Dépendant du processeur
7.3.1 Les chiers source de MicroC/OS-II
Le chier OS_ CFG.H

C'est un chier de conguration du noyau.
Il initialise des constantes globales .
Voici un exemple :
La première constante sert à activer ou désactiver la tâche de statistiques

La deuxième est utilisée pour déterminer la taille de la pile de la tâche de statistiques
Le chier INCLUDES.H
C'est un chier qui fait appel à tous les autres chiers bibliothèques de µC
et de BC
Voici un exemple :
Figure 7.7 Les chiers source de MicroC/OS-II
Figure 7.8 Le chier INCLUDES.H

Le chier UCOS_II.H
C'est un chier qui dénit les prototypes des fonctions, les codes erreur, les
constantes, les structures de données pour les ags, les mailboxes,. . .
Voici un exemple :
Figure 7.9 Le chier UCOS-II.H
Le chier UCOS_II.C
C'est un chier qui contient les include des autres chiers .c tels que
OS_TASK.C ou OS_MEM.C dans le répertoire SOFTWARE
Voici un exemple :
Figure 7.10 Le chier UCOS-II.C
Les chiers reliés au CPU
Ce sont les chiers OS_CPU.H , OS_CPU_C.C et

OS_CPU_A.ASM
Ces chiers dépendent du type du CPU utilisé avec le noyau microC/OS-II,
et plus particulièrement la taille de la mémoire
Les chiers de services :
Ce sont les chiers contenant les services du noyau comme OS_FLAG.C,

OS_MBOX.C,. . . .
Chacun de ces chiers concerne la gestion des ensembles de services reliés
aux tâches, à la mémoire,
7.3.2 Comparaison entre uC/OS et uC/OS-II
7.3.2.1 Les chiers sources :
Dans uC/OS :
Le chier ucos.c contient tous les services du noyau.

Le chier ucos.h contient la dénition des types et des constantes.
Le chier os_cfg.h contient la conguration du noyau.
Le chier ix86_c.c contient la fonction de création de tâches.
Le chier INCLUDES.H qui fait appel à tous les autres chiers biblio-
thèques de uC et de BC : "IX86S.H, "OS_CFG.H et "UCOS.H.
Dans uC/OS-II :
Les services sont divisés en plusieurs chiers .c .

Le chier ucos_ii.c fait appel à ces chiers . c .
Le chier os_cfg.h est similaire à celui dans uC/OS mais il est beaucoup
plus grand.
On n'a plus de chier ix86_c.c dans le noyau OS-II.
Le chier INCLUDES.H qui fait appel à tous les autres chiers biblio-
thèques de uC et de BC :
Ce sont les chiers OS_CPU.H , OS_CPU_C.C et
OS_CPU_A.ASM
Ces chiers dépendent du type du CPU utilisé avec le noyau microC/OS-
II, et plus particulièrement la taille de la mémoire
7.3.2.2 Les processeurs supportés :
7.3.3 Services du noyau (1)
Les fonctions Hooks :

Ce sont des fonctions de rattachement appelées par µc/OSII quand l'événement
correspondant à lieu.
Exemple :
OSTaskSwHook() est appelée à chaque fois où un changement de contexte

arrive quand on veut avoir des informations concernant le changement de contexte.
Les hooks sont spéciés lors de la compilation du noyau.
à Les Flags :
Les drapeaux sont utilisés quand une tâche veut se synchroniser avec l'occurrence
d'événements multiples.
Figure 7.11 Les processeurs supportés
Les événements sont utilisés pour signaler des tâches multiples, et sont généralement
groupés. On parle alors de groupe de event ag
Une tâche est reprise quand tous les événements (les bits du event ag) la concernant
sont satisfaits. Lorsqu'un nouvel ensemble d'événements à lieu (par exemple pendant
une opération de post), la tâche qui va être reprise sera alors choisie.
Figure 7.12 Services du noyau

7.4 Le noyau temps réel RTLinux

RTLinux est un noyau Temps Réel considérant Linux comme tâche de plus faible
priorité. RTLinux est un système d'exploitation dans lequel cohabitent un micro-
noyau temps réel et le noyau Linux. L'intention des concepteurs est de continuer
d'utiliser les services de haut niveau du système à temps partagé, tout en permet-
tant de fournir un comportement déterministe dans un environnement où le temps
de latence est extrêmement faible. En eet, les systèmes temps réel ont souvent
besoin d'un support réseau, d'une interface graphique, d'un système de chier et
éventuellement d'un accès à une base de données. Ceci peut être fourni par un sys-
tème d'exploitation monobloc où tout service est intégré dans un environnement
temps réel, comme LynxOs. Une autre solution est de consacrer une machine aux
applications temps réel et la faire communiquer avec d'autres gérant les services non
temps réel. La troisième voie adoptée par RTLinux est celle qui permet à un micro-
noyau d'exécuter le véritable noyau Linux comme sa tâche de plus faible priorité.
RTLinux implémente en fait une sorte de machine virtuelle pour que le noyau Linux
standard soit complètement préemptif. Dans cet environnement, toutes les interrup-
tions sont initialement prises en compte par le noyau temps réel et sont passées à
Linux seulement s'il n'y a pas de tâche temps réel à exécuter.
Figure 7.13 Les diérentes couches d'abstraction : RTLinux comme machine

virtuelle pour Linux
Pour minimiser les changements dans le noyau Linux, les concepteurs ont émulé
le contrôleur d'interruptions matériel. Ainsi, quand Linux masque une interruption,
celle-ci est quand même prise en compte par RTLinux et aiguillée vers une le
d'attente si elle n'est pas utile au niveau du micro-noyau. Lorsque Linux rétablit la
possibilité de traiter les interruptions, celles arrivées entre temps sont disponibles et
peuvent être traitées par la routine de gestion d'interruptions de Linux. Les codes
assembleurs des processeurs i486 cli, sti et iret sont remplacés dans le noyau Linux
7.5. Le noyau temps réel VXWorks 95
par des macro-instructions S_CLI, S_STI et S_IRET. Toutes les interruptions

matérielles sont attrapées par l'émulateur qui distribue des interruptions logicielles
(soft interrupts).
Les tâches temps réel suivent les spécications de la norme POSIX.1c décrivant
les threads. Elles peuvent êtres application utilisateur, service fourni par l'environ-
nement RTLinux ou pilote de périphérique. Chargées comme module noyau, elles
s'exécutent en suivant les ordres dictés par le scheduler. Le temps CPU est fourni à
la tâche de plus haute priorité (scheduler de base RTLinux).
Ces kernel threads disposent des droits entiers sur la machine et peuvent accéder
à toutes les ressources. Ils occupent tous le même espace d'adressage (celui du
noyau !) et se chargent dynamiquement. Il résulte de ces trois points qu'il est délicat
de développer un tel module. En eet, la moindre erreur de programmation, vite
advenue en C du fait de la manipulation de pointeurs, est fatale au système. En
revanche, cette architecture permet d'augmenter les performances en éliminant les
temps de changement de niveau de protection et en raccourcissant le temps de
changement de contexte. Toutes les ressources d'une tâche RTLinux sont allouées
statiquement (exemples : mémoire, fo).
7.5 Le noyau temps réel VXWorks

VxWorks de la société Wind River est un noyau Temps Réel moderne qui a été
le premier à intégrer les couches réseau IP et l'API socket. Il intègre un shell et
autorise l'édition de liens dynamique. Une plate-forme de cross développement est
nécessaire. C'est un excellent RTOS. Son principal défaut est son prix et les royalties
à verser pour chaque cible développée.
7.6 Le noyau temps réel pSOS

pSOS de la société Wind River est un noyau Temps Réel compact et rapide.
pSOS est en cours d'intégration dans les produits Wind River (Tornado). C'est un
très bon RTOS. Son principal défaut est son prix et les royalties à verser pour chaque
cible développée.
Chapitre 8
Méthode SA-RT
Contents
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.2 Spécication selon la méthode SA-RT . . . . . . . . . . . . . 98
8.3 Présentation de la syntaxe graphique de la méthode SA-RT 100
8.3.1 Syntaxe graphique pour l'aspect fonctionnel . . . . . . . . . 100
8.3.2 Syntaxe graphique du ot de données . . . . . . . . . . . . . 101
8.3.4 Syntaxe graphique de la Terminaison . . . . . . . . . . . . . 104
8.4 Les diagrammes ot de données . . . . . . . . . . . . . . . . . 106

commande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
8.4.2 Diagramme de contexte d'une application . . . . . . . . . . . 107
8.4.3 Diagramme préliminaire et diagrammes de décomposition . . 108
8.1 Introduction
La méthode SA-RT est une méthode d'analyse fonctionnelle et opérationnelle
des applications de contrôle-commande. Cette méthode permet de réaliser une des-
cription graphique et textuelle de l'application en termes de besoins, c'est-à-dire
de ce que l'on a à faire ou le quoi ( What ?). Cette mise en forme du
cahier des charges de l'application est formelle dans le sens où la méthodologie
(ensemble des documents à élaborer) et l'expression (syntaxe graphique) sont dé-
nies. En revanche, elle ne permet pas d'eectuer une vérication de propriétés de
l'application à partir des seules descriptions SA-RT. Des études ont été menées pour
associer à la méthode SA-RT des méthodes formelles an d'apporter des possibilités
de simulation et de vérication. Une de ces méthodes est présentée à la n du cha-
pitre. Aucune règle ocielle ou normalisation n'a été mise en place pour la méthode
SA-RT et son utilisation. Par conséquent, il existe de nombreuses mises en ÷uvre
de la méthode SA-RT avec des diérences plus ou moins importantes et aussi des
extensions spéciques de la méthode. Ceci fera l'objet du dernier point traité dans
ce chapitre.
98 Chapitre 8. Méthode SA-RT
8.2 Spécication selon la méthode SA-RT

L'analyse structurée SA est une méthode descendante par anages successifs
des traitements, appelés process . Les diérents diagrammes sont donc ordonnés
hiérarchiquement en faisant apparaître pour les derniers niveaux des fonctions
élémentaires, appelées primitives élémentaires ou process primitifs. Les diérents
outils composant cette méthode sont :
Diagrammes de transformations de données ou diagramme de ots de données

(DFD) ;
Dictionnaire de données ;
Spécications des process primitifs.
Les diagrammes de ots de données sont construits à partir de quatre éléments
graphiques : traitement (cercle), ot de données (èche), unité de stockage (traits pa-
rallèles) et entité externe (rectangle) (Tableau 8.1). À partir de ces éléments de base,
il est possible de décrire l'aspect fonctionnel d'une application par un diagramme
ots de données. Un exemple, présenté sur la Figure 8.1, montre l'analyse d'une ap-
plication très simple de régulation de température avec trois entités externes, deux
process et une unité de stockage.
Figure 8.1 Positionnement chronologique de la méthode SA-RT.
Pour exprimer complètement le comportement de l'application, le diagramme

ots de données de SA manquait d'un moyen permettant de spécier l'aspect opé-
rationnel.
8.2. Spécication selon la méthode SA-RT 99
Figure 8.2 Les diérents éléments graphiques de la méthode SA.
Figure 8.3 Exemple simple du diagramme ot de données de la méthode SA
correspondant à une application de régulation de température

C'est-à-dire la description de l'enchaînement des diérents process. Cette lacune

fut comblée par la création de méthode SA-RT (Structured Analysis-Real Time).
Deux groupes élaborèrent la méthode SA-RT avec des diérences notables en
termes de représentation : d'une part, la méthode établie par Ward et Mellor en
1985 qui associe le fonctionnel et le contrôle dans un même diagramme et, d'autre
part, la méthode proposée par Hatley et Pirbhai en 1986 qui sépare le fonctionnel
et le contrôle. Mais ces deux vues de la même méthode restent très similaires
en termes de capacité d'expression de la spécication. Nous présentons dans cet
ouvrage la méthode SA-RT établie par Ward et Mellor en 1985.
Comme le montre la Figure 8.3, la méthode SA-RT a continué à évoluer au sein des
entreprises en intégrant des besoins spéciques à un domaine d'applications. Ainsi,
nous trouvons une méthode SA-RT, appelée ESML et utilisée dans l'avionique, qui
a été enrichie d'un point de vue ot de contrôle.
La méthode SA-RT intègre les trois aspects fondamentaux d'une méthode de

spécication en mettant l'accent sur les deux premiers qui sont des points essentiels
dans les applications de contrôle-commande :
Aspect fonctionnel (Ou transformation de données) : représentation de

la transformation que le système opère sur les données et spécication des
processus qui transforment les données ;
Aspect événementiel (Piloté par les événements) : représentation des évé-
nements qui conditionnent l'évolution d'un système et spécication de la
logique de contrôle qui produit des actions et des événements en fonction
d'événements en entrée et fait changer le système d'état ;
Aspect informationnel (Données) : spécication des données sur les ots
ou dans les stockages. Ce dernier aspect qui est en général assez négligé dans
ce type d'application peut faire l'objet d'une description spécique choisie
au sein d'une entreprise.
8.3 Présentation de la syntaxe graphique de la méthode

SA-RT
Nous allons présenter la syntaxe graphique complète de SA-RT permettant d'éla-
borer les diérents diagrammes de la méthode. Cette syntaxe graphique très simple
peut être scindée en deux parties : la syntaxe graphique aérente à l'aspect fonc-
tionnel et la syntaxe dédiée à l'aspect contrôle ou événementiel.
8.3.1 Syntaxe graphique pour l'aspect fonctionnel
En premier lieu, nous trouvons le Processus fonctionnel ou Processus

qui représente une transformation de données. Un ou plusieurs ux de données
en entrées sont traités pour donner un ou plusieurs ux de données en sortie. Le
8.3. Présentation de la syntaxe graphique de la méthode SA-RT 101
Table 8.1 Syntaxe graphique du processus fonctionnel

Étiquette_Processus= verbe (+ un ou plusieurs compléments d'objets) + numéro
Table 8.2 Syntaxe graphique du ot de données

Étiquette_Flot_de_Données = nom (+ qualiant)
Processus est représenté par un cercle avec une étiquette ou label explicite formé de :
8.3.2 Syntaxe graphique du ot de données
Puis, nous avons le Flot de Données qui supporte ou transporte les valeurs
d'une certaine information à diérents instants. Ce concept représente le chemine-
ment des données. Le ot de données est représenté par un arc orienté avec une
étiquette ou label explicite formé de (Figure 8.4) :
Les valeurs de ce ot de données sont supposées disponibles pendant tout le

temps où le processus producteur de ce ot est en mesure de les générer. Le ot de
données peut représenter aussi bien une donnée de type continu, codée par un entier
ou un réel (Température) qu'une donnée discrète codée par un booléen,exemple
Position_interrupteur . Un ot de données peut décrire aussi bien une donnée
élémentaire ou unique, exemple Température qu'une donnée structurée intégrant
plusieurs données élémentaires, exemple la donnée Pressions qui est composée
de Pression_huile et Pression_air . Il est alors possible de faire apparaître
l'étiquette du ot de données sous la forme suivante :
Une spécication détaillée de cette donnée, véhiculée par le ot de données, est
faite dans le Dictionnaire de données (voir ci-après).
Ces ots de données peuvent se décomposer ou au contraire se regrouper lors
des liaisons entre les processus fonctionnels dans le diagramme ot de données.
8.3.3 Syntaxe graphique du stockage de données
Le troisième élément graphique est le Stockage de Données qui modélise le besoin

de mémorisation d'une donnée de telle façon que sa valeur puisse être relue plusieurs
fois. Comme le ot de données auquel il est étroitement associé, il est nommé par
une étiquette ou label explicite formé de :
Le stockage de données est représenté par deux traits horizontaux encadrant

l'étiquette dénie ci-avant. Les arcs ots de données arrivant ou partant de
l'unité de stockage ne sont pas étiquetés s'ils transportent les données mémorisées
Table 8.3 Étiquette_Donnée_Structurée

Étiquette_Donnée_Structurée = Étiquette_Donnée_1, Étiquette_Donnée_2
Figure 8.4 Processus fonctionnel de la méthode SA-RT.
Figure 8.5 Exemples simples de ots de données de la méthode SA-RT.
Table 8.4 Syntaxe graphique du stockage de données

Étiquette_Stockage_de_Données= nom (+ qualiant)
Figure 8.6 Décomposition et regroupement des ots de données de la méthode
SA-RT.
complètes. Si une partie de la donnée est écrite ou lue, l'arc transportant de façon
partielle la donnée doit être étiqueté avec le nom de cette donnée.
Figure 8.7 Unité de stockage de la méthode SA-RT
Un exemple de diagramme ot de données intégrant ces trois éléments graphiques

de la méthode SA-RT (processus fonctionnel, ot de données et unité de stockage)
est présenté sur la Figure 8.8.
Il est important de noter que l'utilisation de l'élément stockage de données

peut correspondre à deux cas :
Mémorisation ou représentation des constantes du système ;

Mémorisation de valeurs de données partagées entre deux ou plusieurs proces-
sus désynchronisés (consommation et production des données à des instants
ou des rythmes diérents).
Spécications des process primitifs.
Figure 8.8 Exemple d'un diagramme ot de données de la méthode SA-RT.

Étiquette _Terminaison = nom (+ qualiant)
8.3.4 Syntaxe graphique de la Terminaison
Enn, le dernier élément graphique, utilisé dans cet aspect fonctionnel, est la
Terminaison , ou encore appelée bord de modèle , qui représente une en-
tité extérieure échangeant des données avec le système modélisé. Une terminaison
peut donc être une entité logicielle (programme, base de données. . . ) ou matérielle
(capteurs, actionneurs, console opérateur. . . ).
Figure 8.9 Terminaison ou bord de modèle de la méthode SA-RT.

8.3.5 Syntaxe graphique du stockage de données
Dans les diagrammes ot de données, le déclenchement de l'exécution des proces-

sus de transformation de données peut être lié au rythme d'apparition des données
entrantes (diagramme piloté par les données : data-driven ). Mais, dans le cas de la
spécication des applications temps réel, il est préférable d'avoir un contrôle de ces
transformations de données piloté par des conditions externes comme l'occurrence
d'événements ( event-driven ). Cette vue dynamique du modèle impose la mise en
place de la partie contrôle : processus de contrôle et ot de contrôle.
Figure 8.10 Pilotage de l'exécution d'un processus fonctionnel : (a) piloté par
les données et (b) piloté par les événements
8.3.5.1 Syntaxe graphique du processus de contrôle
Le Processus de contrôle représente la logique du pilotage des processus

fonctionnels. Il génère l'ensemble des événements qui vont activer ou désactiver les
processus fonctionnels.
En retour, les processus fonctionnels fournissent au processus de contrôle tous les
événements nécessaires aux prises de décision. Le processus de contrôle ne peut en
aucun cas gérer des données.
Le Processus de contrôle est représenté par un cercle en pointillé avec une étiquette
ou label explicite formé de (Figure 8.11) :
Figure 8.11 Processus de contrôle de la méthode SA-RT


Étiquette_Flot_de_Contrôle=nom (+ qualiant)
8.3.5.2 Syntaxe graphique du Flot de contrôle
Le Flot de Contrôle transporte les événements ou informations qui condi-

tionnent directement ou indirectement l'exécution des processus de transformations
de données. Le ot de contrôle est représenté par un arc orienté pointillé avec une
étiquette ou label explicite formé de (Figure 8.12) :
Figure 8.12 Exemple simple d'une partie contrôle liée à une partie fonctionnelle
de la méthode SA-RT
Les événements, fournis par le processus de contrôle, sont généralement liés à

l'activation ou à la désactivation des processus fonctionnels. Aussi, ces événements
spéciques ont été formalisés et prédénis :
E pour Enable (activation) ;

D pour Disable (désactivation) ;
T pour Trigger (déclenchement).
Les deux premiers événements sont utilisés ensemble E/D pour piloter un
processus fonctionnel de type boucle sans n ou périodique, c'est-à-dire que le
processus de contrôle doit lancer l'exécution de ce processus avec l'événement E
et ensuite peut l'arrêter avec l'événement D . L'événement T est utilisé pour
activer un processus fonctionnel de type début-n ou sporadique, c'est-à-dire
que le processus de contrôle doit lancer l'exécution de ce processus avec l'événement
T et ensuite le processus s'arrête à la n de son exécution sans intervention du
contrôle.
8.4 Les diagrammes ot de données

commande
An d'illustrer la méthodologie au fur et à mesure de la présentation, nous allons

présenter un exemple simple qui va être décliné en détail au cours de ce chapitre.
8.4. Les diagrammes ot de données 107
Considérons un système de freinage automobile qui est constitué d'une part d'un
ensemble classique composé d'une pédale de frein (demande de freinage) et d'un frein
(actionneur de freinage) et d'autre part d'un système ABS (Anti-blocking Brake
System).
Un capteur de glissement de roues est associé à ce système ABS. Pour simplier,
le fonctionnement de l'ABS est basé sur un arrêt du freinage dès qu'un glissement
est détecté sur les roues, et cela même si la demande du conducteur est toujours
eective.
Le conducteur a la possibilité d'activer ou non ce système ABS à l'aide d'un bouton
spécique (bouton à deux positions stables : interrupteur). Un voyant permet de lui
indiquer l'activation du système ABS. En revanche, il n'est pas possible de désactiver
le système ABS en cours de freinage, c'est-à-dire pendant l'appui sur la pédale de
frein.
La spécication fonctionnelle de cette application à l'aide de la méthode SA-RT va
s'eectuer en plusieurs étapes :
Diagramme de contexte ;
Diagramme préliminaire ;
Diagrammes de décomposition.
8.4.2 Diagramme de contexte d'une application
Le diagramme de contexte est une première étape extrêmement importante

puisqu'elle va dénir le contexte et l'environnement extérieur du système piloté.
Nous pouvons la considérer comme le contrat de réalisation entre le concepteur et
son client. Les bords de modèle ou terminaisons vont apparaître uniquement dans
ce diagramme. Les descriptions précises de ces terminaisons, ainsi que des données
ou éventuellement des événements entrants ou sortants de ceux-ci, sont à la charge
du donneur d'ordre. Un exemple générique d'un diagramme de contexte est donné
sur la Figure 9.13.
Nous trouvons un et un seul processus fonctionnel, numéroté 0 , qui traduit
l'application à réaliser eectivement par le concepteur. Autour de ce processus
fonctionnel, un ensemble de bords de modèles fournit ou consomme les données
ou événements de cette application. Ces bords de modèles peuvent donc être les
éléments physiques suivants :
capteurs (thermocouples, dynamomètres, etc.) ;

actionneurs (résistances chauantes, vannes, etc.) ;
opérateur(s) lié(s) à des capteurs (interrupteurs, potentiomètres, etc.) ;
systèmes d'achage (lampes, diodes, écran d'ordinateur, etc.) ;
système de stockage ou de sauvegarde externe (disque, bande magnétique,
etc.) ;
système d'impression (imprimante, dérouleur papier, etc.) ;
L'ensemble des données ou événements échangés avec l'extérieur du processus

fonctionnel , qui représente l'application, constitue les spécications d'entrées et
Figure 8.13 Diagramme de contexte générique de la méthode de spécication
SA-RT.
de sorties de l'application. La description de ces entrées/sorties sera faite dans le

dictionnaire de données. Dans l'exemple simple d'un système de freinage automobile,
le diagramme de contexte est constitué du processus fonctionnel Contrôler système
freinage 0 et de cinq bords de modèles :
terminaison Pédale de frein fournissant la donnée Demande_freinage

;
terminaison Bouton d'activation de l'ABS fournissant la donnée Acti-
vation_ABS ;
terminaison Capteur de glissement fournissant la donnée Glisse-
ment_roue ;
terminaison Système de freinage consommant la donnée Com-
mande_freinage ;
terminaison Voyant ABS consommant la donnée Achage_ABS .
Ce diagramme de contexte dénit parfaitement l'interface entre le concepteur et

le client, c'est-à-dire les données à fournir ou à générer. La suite du travail d'analyse
va donc se situer dans l'expression du processus fonctionnel à réaliser : Contrôler
système freinage 0 .
8.4.3 Diagramme préliminaire et diagrammes de décomposition
Le premier niveau d'analyse est représenté par le diagramme préliminaire.

Ce diagramme préliminaire est la première décomposition du processus à réaliser
présenter dans le diagramme de contexte. À ce niveau, le diagramme représente
la liste graphique des processus fonctionnels nécessaires à l'application sans se
soucier de l'enchaînement (séquence d'exécution).
Le nombre de processus fonctionnels, composant ce diagramme préliminaire, doit
être limité pour avoir une meilleure lisibilité : 5 à 9 maximum. Dans ce cadre, nous
Figure 8.14 Diagramme de contexte de l'application système de freinage au-
tomobile .
pouvons aussi trouver un motif générique permettant de décrire une fonction simple
ou complexe de contrôle-commande en la divisant selon les trois éléments de base,
soit :
un processus d'acquisition ;
un processus de traitement (loi de régulation) ;
un processus de commande.
Selon l'application, tout ou partie de ce diagramme ot de données générique peut

être présent pour chaque chaîne de contrôle-commande impliquée dans le niveau
d'analyse en cours d'élaboration. Ce diagramme ot de données générique peut être
utilisé au niveau du diagramme préliminaire ainsi que dans les niveaux d'analyse
suivant des diagrammes de décomposition.
Figure 8.15 Décomposition fonctionnelle générique

Le passage des données entre les processus fonctionnels peut être réalisé selon
les besoins avec les deux méthodes de base : ots de données direct (exemple entre
les processus 2 et 3) ou unité de stockage (cas des processus 1 et 2).
Ainsi, dans l'exemple simple d'un système de freinage automobile, le diagramme
préliminaire est constitué de cinq processus fonctionnels. Au niveau de cet exemple
simple, nous n'avons pas une décomposition fonctionnelle aussi complexe que
l'exemple générique présenté précédemment : seules les parties acquisition et
commande sont présentes dans le cas du contrôle-commande du freinage et du
bouton ABS. Nous pouvons souligner immédiatement la cohérence obligatoire entre
le diagramme de contexte et ce diagramme préliminaire au niveau des ots de
donnéesentrants et sortants.
Le passage des données entre les processus fonctionnels est eectué de façon directe.
Il est important de noter que la donnée Niveau_freinage est de type entier ou
réel alors que les données Etat_glissement et Etat_bouton_ABS sont de
type booléen. Cela va entraîner dans la suite de cette analyse une modication de
ce diagramme préliminaire.
Cette décomposition fonctionnelle en diagrammes ots de données peut se pour-
suivre en ranant de plus en plus la description des processus fonctionnels. Chaque
diagramme de décomposition, associé à un processus fonctionnel numéroté
N
du diagramme hiérarchiquement supérieur, est référencé au niveau des processus
fonctionnels par des numéros N.x . L'exemple simple système de freinage
automobile choisi pour illustrer la méthodologie n'est pas assez complexe pour
justier la décomposition d'un des processus fonctionnels. Donc tous les processus
fonctionnels du diagramme préliminaire de la Figure 8.16 sont des processus
primitifs. Lorsqu'il n'y a plus d'intérêt à décomposer un processus, celui-ci est
appelé processus primitif et doit être décrit par une spécication sous forme
textuelle, tabulaire ou graphique (voir ci-après). Nous pouvons énoncer les deux
premières règles de cohérence de cette décomposition hiérarchique :
l'ensemble des ots entrants et sortants du processus décomposé doit se retrouver
dans le diagramme de décomposition de ce processus avec les mêmes typages
(données ou événements) ;
la numérotation des diérents processus fonctionnels doit intégrer le numéro

du processus fonctionnel analysé N sous la forme N.x ;
les stockages doivent apparaître dans tous les diagrammes où les processus
les utilisent.
Figure 8.16 Diagramme ot de données préliminaire de l'application système
de freinage automobile .
Chapitre 9
Conception Selon La Méthode

DARTS
Contents
9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.2 Conception selon la méthode DARTS . . . . . . . . . . . . . 114
9.2.1 Les besoins d'une méthode de conception . . . . . . . . . . . 114
9.2.2 Relations entre les tâches . . . . . . . . . . . . . . . . . . . . 115
9.3 Présentation de la méthode DARTS . . . . . . . . . . . . . . 116

9.3.1 Syntaxe graphique de la méthode DARTS . . . . . . . . . . . 118
9.1 Introduction
La méthode de conception va permettre de passer d'un modèle de spécication
aux programmes codés dans un langage exécutable. Étant donné l'analyse de type
fonctionnel et structuré qui a été réalisée avec la méthode SA-RT, nous pourrions
être tentés de traduire directement ces modules fonctionnels (processus fonctionnels
des diagrammes ots de données de SA-RT) en des entités de programmes. Cette
approche serait très néfaste pour deux raisons :
d'une part, le découpage modulaire de l'application a été fait en se préoccu-
pant essentiellement des fonctions à réaliser et non pas de la structuration
ecace en termes de réalisation et d'exécution, c'est-à-dire que le nombre
de tâches de l'application ne correspond pas obligatoirement au nombre de
processus fonctionnels des diagrammes SA-RT ;
d'autre part, les relations entre les processus fonctionnels des diagrammes
ots de données sont décrites de manière très abstraite (zone mémoire, pas-
sage de données) sans se préoccuper de leurs implémentations possibles avec
ou sans synchronisation. La question qui se pose concerne le choix de cette
méthode. En eet, il serait tout à fait envisageable, comme nous l'avons vu
dans les exemples industriels du paragraphe 1.3.4, d'associer une méthode
d'analyse de type ot de données à une méthode de conception de type
orienté objets . En revanche, le choix de l'une ou l'autre voie amène quasi
obligatoirement un choix de langage. Ainsi, la Figure 9.1 représente les choix
possibles selon les deux groupes de méthodes de conception. La méthode
DARTS (Design Approach for Real-Time Systems
114 Chapitre 9. Conception Selon La Méthode DARTS
H. Gomaa, 1984) trouve naturellement sa place entre la méthode d'analyse

SA-RT et une implémentation avec un langage de programmation de haut
niveau exécuté dans un environnement de type noyau temps réel, ou avec un
langage multitâche (Ada) ou un langage ots de données (LabVIEW).
9.2 Conception selon la méthode DARTS

9.2.1 Les besoins d'une méthode de conception
La méthode de conception doit orir tous les moyens d'expression à l'utilisateur

pour décrire son application multitâche. Ainsi, la conception doit pouvoir exprimer
Figure 9.1 Les choix d'une méthode de conception et du langage d'implémenta-
tion suite à une analyse de type SA-RT
L'architecture donnée sur la Figure 9.2, c'est-à-dire les diérentes tâches, les
relations entre les tâches et la possibilité d'accès à des ressources critiques. Ainsi,
nous pouvons donc décliner les diérentes caractéristiques à représenter avec la
méthode DARTS :
les tâches : type d'activation, paramètres ou données en entrées ou en sorties ;
les relations entre les tâches : synchronisation de type asynchrone ou
synchrone (rendez-vous),
9.2. Conception selon la méthode DARTS 115
communication avec des données qui transitent entre deux tâches ;
le partage de ressources critiques.
Figure 9.2 Architecture multitâche à décrire avec la méthode de conception
DARTS
9.2.2 Relations entre les tâches
Le point le plus complexe est la traduction des diérentes relations entre les
tâches. En eet, cette relation traduit un lien de dépendance entre les tâches ,
c'est-à-dire qu'une ou plusieurs tâches ne commencent leur exécution uniquement
que lorsqu'une autre tâche s'est exécutée en partie ou en totalité. Cette synchro-
nisation ou communication peut être unilatérale ou asynchrone (seule la tâche en
attente est bloquée), ou bilatérale ou synchrone (les deux tâches ont un rendez-vous,
exemple du langage Ada). La Figure 9.2 montre cette diérence de relations de syn-
chronisation entre deux tâches. Dans le premier cas I de la relation asynchrone, la
tâche 1 bloque la tâche 2 qui doit attendre l'exécution d'une partie de la tâche 1
en un certain point de son code ; en revanche, dans le second cas, les deux tâches
doivent s'attendre mutuellement.
Attachée à cette synchronisation de deux ou plusieurs tâches, un transfert de don-
nées peut être associé, nous parlons alors de communication. Une communication
est caractérisée par la taille de cette zone d'échange de données (une ou plusieurs
données) et le mode de gestion de cette zone de données (FIFO First In Fisrt Out,
à priorité). Le critère principal, lié à cet échange de données, est l'aspect bloquant ou
non de l'interaction entre les tâches. Si la production et la consommation de données
sont synchronisées, c'est-à-dire que, si la zone de données est vide, la tâche consom-
matrice ne peut s'exécuter et réciproquement, si la zone de données est pleine, la
tâche productrice ne peut s'exécuter. Nous avons dans ce cas une communication
mettant en jeu une vraie synchronisation entre les tâches. Dans le cas contraire, la
zone de données est dite à écrasement et nous avons un blocage uniquement en

lecture des données.
Figure 9.3 Relations de synchronisation entre les tâches- (1)
9.3 Présentation de la méthode DARTS

La méthode de conception DARTS constitue le lien entre la méthode d'analyse
SA-RT et l'implémentation de l'application. Nous allons étudier la méthode DARTS
dans sa forme la plus simple, c'est-à-dire s'appliquant à des applications de contrôle
commande générales. Il est intéressant de noter que des versions enrichies de cette
méthode de conception ont été créées an de répondre à des besoins spéciques.
Nous trouvons ainsi :
9.3. Présentation de la méthode DARTS 117
Figure 9.4 Relations de synchronisation entre les tâches- (1)
méthode DARTS adaptée à une implémentation avec le langage Ada :

ADARTS : Ada Based Design Approach for Real-Time Systems (GOMAA,
1987) ;
méthode DARTS adaptée à une application distribuée : CODARTS :
Concurrent Design Approach for Real-Time Systems (GOMAA, 1987).
Pour s'harmoniser de façon complète avec la méthode d'analyse SA-RT, la mé-

thode de conception DARTS est de type ots de données. Ainsi, les diagrammes
ots de données de la méthode SA-RT (diagrammes préliminaires ou diagrammes
de décomposition) sont traduits en diagramme ots de données DARTS représen-
tant l'architecture multitâche de l'application. D'autre part, la méthode DARTS
que nous présentons dans cet ouvrage permet de décrire de nombreuses applications
de type contrôle-commande. Mais an d'obtenir des applications dont le test ou la
vérication peuvent être conduits de façon able, nous avons volontairement limité
la possibilité d'expression en se donnant des règles de bonne conception . Ces
règles correspondent en partie à un prol de programmation adopté dans le cadre de
la programmation en langage Ada d'applications à haut niveau de sécurité. La pré-
sentation détaillée de ce prol de programmation, appelé Ravenscar prole (1997),
est eectuée dans le chapitre 5. Dans ce contexte, nous pouvons ainsi dénir les
règles suivantes :
Nombre xé de tâches au démarrage de l'application.

Un seul événement de déclenchement par tâche : signal temporel, synchroni-
sation avec une autre tâche.
Possibilité d'analyse fonctionnelle des tâches de façon individuelle.
Table 9.1 Modélisation des tâches et modules

Étiquette_Tâche= verbe (+ un ou plusieurs compléments d'objets)
Possibilité d'analyse fonctionnelle des tâches de façon individuelle.
Il est à noter que d'autres règles concernant plus la partie implémentation et

l'aspect ordonnancement sont étudiées dans les chapitres concernés.
9.3.1 Syntaxe graphique de la méthode DARTS
Nous allons présenter dans cette section les diérents éléments de la bibliothèque
graphique de la méthode DARTS correspondant à la phase de conception.
9.3.1.1 Syntaxe graphique de la méthode DARTS
En premier lieu, nous trouvons la tâche qui représente l'entité de base de l'archi-
tecture multitâche. Nous pouvons avoir un ou plusieurs ots de données en entrées
et un ou plusieurs ots de données en sortie. Les tâches sont modélisées par un
parallélogramme qui comporte une étiquette ou label explicite formé de :
SA-RT s'il y a, par exemple, une correspondance entre une tâche et un processus
fonctionnel comme nous allons l'étudier dans la suite de ce chapitre. Nous avons aussi
un signal d'activation qui a une provenance et un type diérents selon que nous mo-
délisons une tâche matérielle (activation de type événement externe au programme)
ou une tâche logicielle (activation de type événement interne au programme : syn-
chronisation ou communication). Ce signal d'activation doit obligatoirement exister
et doit être unique pour répondre au prol de conception xé.
Figure 9.5 Représentations des tâches et des modules
Cette étiquette peut correspondre à celle donnée dans le cadre d'un diagramme
ots de données Nous avons aussi le module de traitement qui correspond à des
programmes spéciques appelés par les tâches pour eectuer des calculs particuliers.
Nous pouvons avoir un ou plusieurs ots de données en entrées et un ou plusieurs
Table 9.2 Modélisation des tâches et modules

Étiquette_Module =verbe (+ un ou plusieurs compléments d'objets)
Table 9.3 Modélisation des synchronisations et des communications

Étiquette_Synchronisation=nom (+ qualiant)
ots de données en sortie (Figure 9.6). Les modules de traitement sont modélisés
par un rectangle qui comporte une étiquette ou label explicite formé de :
Ces modules ne peuvent pas émettre ou recevoir des éléments de type multitâche :
synchronisation ou communication. Ils peuvent être considérés comme réentrants,
c'est-à-dire partagés par plusieurs tâches sans mettre en ÷uvre une gestion spéciale
de l'accès. Ces modules concernent généralement des calculs de type traitement du
signal, traitement d'images, loi de régulation de l'automatique. . . Cette séparation
des unités de traitement permet de ne pas alourdir les tâches en termes de code et
d'y conserver uniquement l'aspect dynamique et comportemental.
9.3.1.2 Modélisation des synchronisations et des communications
En ce qui concerne les synchronisations, nous avons les modèles correspondant

aux deux synchronisations précédemment citées, c'est-à-dire la synchronisation de
type asynchrone et la synchronisation de type synchrone, c'est-à-dire le rendez-vous.
Le modèle synchronisation de type asynchrone est généralement le plus utilisé
car il permet une validation plus aisée de l'application. Ces modèles représentent le
cheminement des dépendances entre les tâches en termes d'exécution. Les synchro-
nisations sont donc représentées par un symbole orienté avec une étiquette ou label
explicite formé de :
Cette synchronisation peut relier plusieurs tâches en amont d'une tâche syn-
chronisée en considérant une opération OU entre toutes les synchronisations en
provenance des tâches en amont. Rappelons qu'il n'est pas souhaitable d'avoir deux
synchronisations à l'entrée d'une tâche ; cela correspondrait alors à deux activations
de la tâche, ce qui est contraire au prol de programmation énoncé.
Pour les communications, nous avons plusieurs modèles correspondant d'une

part à la taille de la zone de communication et d'autre part à la gestion de cette
zone de stockage des données (Figure 9.7). D'une manière générale, ces modèles
boîtes aux lettres BAL représentent le cheminement des données entre les
tâches avec un aspect relation de précédence pour certaines communications. Les
communications sont donc représentées par un symbole orienté avec une étiquette
ou label explicite formé de :

Étiquette_Communication=nom (+ qualiant)
Figure 9.6 Représentations des synchronisations entre les tâches
Nous pouvons ainsi distinguer deux types de gestion de la zone de stockage des
données d'un point de vue dépendance (relation synchrone ou non) :
les boîtes aux lettres bloquantes qui se déclinent en trois modèles : boîtes
aux lettres bloquantes pouvant contenir n messages gérés selon une le
FIFO,
boîtes aux lettres bloquantes ne pouvant contenir qu'un seul message,
boîtes aux lettres bloquantes pouvant contenir n messages gérés selon une
le FIFO, classés par priorités correspondantes généralement à celle de la
tâche émettrice de la donnée ;
les boîtes aux lettres non bloquantes en écriture ou BAL à écrasement qui se
déclinent en deux modèles : boîtes aux lettres non bloquantes en écriture
pouvant contenir n messages gérés selon une le FIFO,
boîtes aux lettres non bloquantes en écriture ne pouvant contenir qu'un
seul message.
Les communications, dites à écrasement, fonctionnent en éliminant la donnée la

plus vieille dans le cas d'une le FIFO ou la donnée stockée dans le cas de la boîte
aux lettres à une place. Il est important de noter que ces communications sont non
bloquantes en écriture uniquement et représentent donc une synchronisation et une
activation d'une tâche comme les autres types de communications. Comme pour les
synchronisations, ces communications peuvent posséder plusieurs tâches en amont
en considérant une opération OU entre toutes les communications en provenance
des tâches en amont. En revanche, il est déconseillé d'avoir plusieurs tâches en aval
car cela nuit au déterminisme du programme. Comme nous l'avons présenté dans
les paragraphes précédents, il existe deux types de tâches : tâches matérielles et
tâches logicielles. Dans les deux cas, l'activation est très diérente. Ainsi, pour les
tâches matérielles qui sont déclenchées par des événements ou signaux externes, nous
distinguons trois types de signaux :
Signal Horloge temps réel HTR . Ce signal, qui provient d'une hor-
loge matérielle interne à l'ordinateur, correspond à un signal rigoureusement
Figure 9.7 Représentations des communications entre les tâches
périodique.
Signal Interruption IT . Ce signal qui provient du procédé externe doit
toujours être considéré comme apériodique du fait de l'asynchronisme du
monde extérieur par rapport au cadencement de l'ordinateur.
Signal Chien de garde CG . Ce signal provient d'une horloge interne
utilisée comme un réveil. Son utilisation et son fonctionnement sont décrits
de façon détaillée dans la suite de cet ouvrage. En termes de signal, il est
identique à l'horloge temps réel (signal interne) ; mais il se produit de façon
apériodique.
Les activations sont donc représentées par un symbole orienté (ligne brisée) avec
une étiquette ou label explicite formé de (Figure 9.9) :
Figure 9.8 Représentations des communications entre les tâches avec entrées
multiples de type OU .
9.3.1.3 Modélisation de l'activation des tâches
Comme nous l'avons déjà explicité, les tâches logicielles sont déclenchées par
d'autres tâches (matérielles ou logicielles) avec les mécanismes de synchronisation

Étiquette_Activation_HTR= HTR (durée en ms)
Étiquette_Activation_IT IT= (+ nom interruption)
Étiquette_Activation_CG =CG (+ nom chien de garde)
ou de communication de type bloquant. Ainsi, le signal d'activation de ces tâches

peut être l'action des éléments suivants (Figure 9.10) :
boîtes aux lettres à écrasement ou non gérées selon une le FIFO ou FIFO à
priorité ;
boîtes aux lettres à écrasement ou non à une seule place ;
boîtes aux lettres à n places gérées selon la priorité.
Figure 9.9 Représentations de l'activation des tâches matérielles
Ainsi, nous pouvons noter qu'une tâche logicielle ne peut pas être activée par
un élément de synchronisation et en même temps être connectée à une autre tâche
en amont par une boîte aux lettres à écrasement, c'est-à-dire bloquante en lecture
(Figure 9.11). Ainsi, la tâche Commander vanne doit être synchronisée soit par
la tâche matérielle Attendre mesures qui est activée par une interruption, soit
par l'autre tâche matérielle Acquérir niveau , dite à scrutation, qui est périodique
et activée par l'horloge temps réel dont la période est de 350 ms.
Figure 9.10 Représentations de l'activation des tâches logicielles
Figure 9.11 Exemple de dysfonctionnement de synchronisation d'une tâche lo-
gicielle par deux tâches matérielles


Étiquette_module_données=nom (+ qualiant)
9.3.1.4 Modélisation des stockages de données
Le dernier élément à modéliser est le module de données qui permet une

protection des accès à une unité de gestion de données en exclusion mutuelle par
deux ou plusieurs tâches. Les modules de données sont représentés par un rectangle
associé à des entrées permettant de réaliser une action sur les données : LIRE,
ÉCRIRE, etc. Ce symbole du module de données est représenté avec une étiquette
ou label explicite formé de (Figure 9.12) :
Figure 9.12 Représentations d'un module de données partagés par plusieurs
tâches.
Si l'action met en jeu un transfert de donnée entre la tâche et le module de

données (LIRE, ÉCRIRE, etc.), la èche est orientée dans le sens de ce transfert de
données.
Si ce n'est pas le cas (INITIALISER, TRIER, etc.), la èche est orientée de la tâche
vers le module de données an de montrer la demande qu'eectue la tâche sur ce
module de données (Figure 9.13). Il est important de noter que plusieurs tâches
peuvent accéder à un module de données puisque ce module de données est géré en
exclusion mutuelle.
Il est important de noter que cet élément module de données ne peut en aucun
cas être utilisé comme un élément de synchronisation. Les deux tâches 1 et 2 de la
Figure 9.12 sont totalement asynchrones et doivent posséder leur propre mécanisme
d'activation. Nous pourrions dénir le module de données comme une boîte aux
lettres à écrasement en écriture et à lecture non destructive avec un message par
défaut à l'initialisation.
Figure 9.13 Représentations de diérents modules de données partagés par plu-
sieurs tâches
9.3.1.5 Mise en ÷uvre de la méthode DARTS
Cette section décrit le passage de la spécication SA-RT à la conception DARTS.

Après quelques règles de base permettant de donner un guide méthodologique à ce
passage SA-RT/DARTS, des exemples simples sont décrits et nous nissons par
l'exemple du système de freinage automobile déjà spécié.
9.3.1.6 Règles générales
Pour cette méthode de conception non formelle, nous allons dénir des règles
générales permettant de passer d'un diagramme ots de données de la méthode SA-
RT à un diagramme multitâche DARTS. Pour cela, nous devons réaliser la traduction
selon les quatre phases suivantes :
Phase 1 : Création des tâches. Cela correspond à la traduction des processus

fonctionnels ou de contrôle en tâches.
Phase 2 : Détermination du typage et de l'activation des tâches. Les tâches
sont déclarées matérielles ou logicielles. Dans le cas des tâches matérielles,
le signal d'activation doit être déni précisément (HTR, IT, CG). Pour les
autres tâches logicielles, il est nécessaire d'identier les synchronisations per-
mettant de les activer. Celles-ci sont souvent déjà déclarées comme des évé-
nements traités par le processus de contrôle.
Phase 3 : Mise en place des synchronisations et des transferts de données.
Les relations par communications sont traduites par des boîtes aux lettres
ou par des modules de données.
Phase 4 : Regroupement ou rassemblement des tâches. An d'améliorer
et de simplier la première conception réalisée de façon semi-automatique
en suivant les trois règles de base que nous allons décrire, le diagramme
multitâche est de nouveau analysé, et les tâches sont regroupées selon un

ensemble de critères qui sont exposés dans la suite.
Pour la première phase de création des tâches, nous pouvons dénir trois
règles de base qui servent de guide à cette traduction semi-automatisée :
Règle 1.1 : Une tâche du modèle DARTS est créée pour chaque processus
fonctionnel du diagramme SA-RT.
Règle 1.2 : Une tâche supplémentaire du modèle DARTS est associée au
processus de contrôle du diagramme SA-RT si le diagramme état/transition,
associé à ce processus de contrôle, est complexe, c'est-à-dire qu'il possède au
moins une structure conditionnelle. En ce qui concerne le typage et l'activa-
tion des tâches, nous pouvons énoncer les règles suivantes :
Règle 2.1 : Une tâche en entrée (acquisition de données) est obligatoire-
ment de type matériel déclenchée soit par l'horloge temps réel (ex. : tâche de
scrutation d'un paramètre physique), soit par une interruption provenant du
procédé (ex. : tâche d'alarme).
Règle 2.2 : Les autres tâches sont déclarées soit logicielles (activation par
synchronisation ou communication avec les tâches matérielles), soit maté-
rielles déclenchée par un événement interne (horloge temps réel, chien de
garde. . . ).
Règle 2.3 : Les événements importants du diagramme ots de données de
SA-RT peuvent être traduits par des synchronisations qui sont utilisées pour
activer des tâches logicielles. Enn, les communications entre les tâches de
DARTS sont établies en se basant sur les deux règles suivantes :
Règle 3.1 : Les communications directes entre les processus fonctionnels
(ot de données d'un processus fonctionnel à un autre) sont traduites préfé-
rentiellement par des boîtes aux lettres.
Règle 3.2 : Les communications par une zone de stockage entre les processus
fonctionnels sont traduites préférentiellement par des modules de données,
en particulier si cette zone de stockage se trouve partagée par plus de deux
tâches. Les règles (ou critères de regroupement des tâches) concernant la
dernière phase sont étudiées dans la suite de cette section sur un exemple
précis. Cet ensemble de règles ne constitue pas une traduction automatique
et formelle de la spécication SA-RT en des diagrammes multitâches DARTS.
En eet, la règle, qui concerne les regroupements ou les scissions éventuelles
des tâches créées en se basant sur les deux premières règles 1.1 et 1.2, laisse
un libre choix de la conguration multitâche. De même les deux règles 3.1 et
3.2, concernant les communications entre les tâches, ne dénissent en rien la
gestion de ces boîtes aux lettres (FIFO ou priorité, à écrasement ou non, à
une ou plusieurs places). Ainsi, en partant d'une même spécication SA-RT
(diagramme ots de données), cette phase de conception, basée sur DARTS,
donne naturellement plusieurs solutions selon le concepteur qui eectue la
traduction.
9.3.1.7 Exemples simples de traduction de SA-RT vers DARTS
Nous allons appliquer quelques règles énoncées précédemment en les illustrant

d'exemples simples. Soit la Figure 9.14, considérons le processus fonctionnel corres-
pondant à l'acquisition de données provenant de deux capteurs (thermocouple et
capteur rotatif ). D'après la règle 2.1, ce processus fonctionnel se transforme en une
tâche matérielle d'entrée qui va être activée périodiquement (période de 2 ms).
Figure 9.14 Traduction d'un processus fonctionnel d'acquisition de donnéesen
une tâche périodique
Figure 9.15 Traduction d'un processus fonctionnel d'acquisition de données en
une tâche apériodique
Nous pouvons noter les noms des diérents éléments qui sont conservés autant
que possible. Cette tâche matérielle est donc une tâche d'acquisition de données dite
à scrutation. La transmission de la donnée Commande_moteur est traduite par
une boîte aux lettres à n places conformément à la préconisation de la règle 3.1.
Dans l'exemple de la Figure 9.15, nous avons aussi un processus fonctionnel cor-
respondant à l'acquisition de données provenant de deux capteurs (thermocouple
et capteur rotatif ). D'après la règle 2.1, ce processus fonctionnel se transforme en
une tâche matérielle d'entrée qui va être activée par une interruption (Dépasse-
ment_température) qui est issue de la mesure du capteur de température. La tâche
Figure 9.16 Traduction d'un ot de données direct entre deux processus fonc-
tionnels par une boîte aux lettres
ainsi créée est donc apériodique et s'active au rythme de l'interruption. Le processus

fonctionnel émet un événement Acher_alarme vers le processus de contrôle
supposé. Dans ce cas, en appliquant la règle 3.2, nous traduisons cet événement par
une synchronisation nommée Alarme .
De la même manière que pour la création des tâches à partir des diagrammes ots
de données de SA-RT, la traduction des transferts de données peut suivre les règles
achées. Ainsi, la Figure 10.16, qui présente un ot de données direct entre deux
processus fonctionnels, montre la traduction par un élément de communication de
type boîte aux lettres conformément à la règle 3.1. Nous pouvons remarquer que la
première tâche est de type matériel, déclenchée par une horloge temps réel, et la
deuxième tâche de type logiciel est activée par la synchronisation de la communica-
tion par boîte aux lettres.
Le deuxième cas traité, illustré sur la Figure 9.17, est celui du transfert de don-
nées par une unité de stockage au niveau du diagramme ots de données SA-RT.
Selon la règle 3.2, il est naturel de traduire ce ot de données par un module de
données ; toutefois ce transfert étant limité à deux processus fonctionnels, aurait pu
aussi être traduit par un élément de type boîte aux lettres comme dans le cas de la
Figure 9.16.
En revanche, la première traduction par un module de données, qui n'est pas une
synchronisation, oblige à synchroniser aussi la deuxième tâche par une autre hor-
loge temps réel par exemple. Les tâches sont alors indépendantes au niveau de leur
cadence d'exécution.
Figure 9.17 Traduction d'une unité de stockage entre deux processus fonctionnels
par un module de données

Chapitre 10
FreeRTOS
Contents
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
10.2 Tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
10.2.1 Tâche FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . . 134
10.2.2 Etat d'une tâche . . . . . . . . . . . . . . . . . . . . . . . . . 134
10.2.3 Task Control Block (TCB) . . . . . . . . . . . . . . . . . . . 135
10.2.4 Ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . . 135
10.2.5 Priorité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
10.2.6 Round robin . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
10.2.7 Gestion des tâches . . . . . . . . . . . . . . . . . . . . . . . . 138
10.2.8 Contrôle des tâches . . . . . . . . . . . . . . . . . . . . . . . 141
10.2.9 Contrôle du noyau . . . . . . . . . . . . . . . . . . . . . . . . 144
10.2.10 Gestion de la queue . . . . . . . . . . . . . . . . . . . . . . . 144
10.3 Gestion des ressources . . . . . . . . . . . . . . . . . . . . . . 145

10.3.1 Les Sémaphores . . . . . . . . . . . . . . . . . . . . . . . . . . 145
10.3.2 Mutex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
10.3.3 Problème d'inversion de priorité . . . . . . . . . . . . . . . . 150
10.3.4 La gestion des interruptions . . . . . . . . . . . . . . . . . . 150
10.3.5 La gestion de la mémoire . . . . . . . . . . . . . . . . . . . . 153
10.4 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

sage Queue) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
10.4.2 Exemple 2-Synchronisation par Sémaphore . . . . . . . . . . 155
10.4.3 Exemple 3- Protection des ressources partagées par Mutex. . 155
10.5 Architectures matérielles supportées . . . . . . . . . . . . . 155
10.1 Introduction
Le FreeRTOS est un système d'exploitation temps réel (RTOS) pour les
microcontrôleur. Développé en partenariat avec les principaux fabricants de puces
au monde sur une période de 15 ans, et maintenant téléchargé toutes les 175
secondes, FreeRTOS est un système d'exploitation en temps réel (RTOS) leader
du marché pour les microcontrôleurs et les petits microprocesseurs. Distribué
gratuitement sous la licence open source du MIT, FreeRTOS comprend un noyau et
132 Chapitre 10. FreeRTOS
un ensemble croissant de bibliothèques IoT adaptées à une utilisation dans tous les
secteurs industriels. FreeRTOS est construit en mettant l'accent sur la abilité et
la facilité d'utilisation. FreeRTOS est un système d'exploitation temps réel (RTOS)
faible empreinte, portable, préemptif et Open source pour microcontrôleur. Il a
été porté sur 33 architectures diérentes. Créé en 2003 par Richard Barry et
la FreeRTOS Team, il est aujourd'hui parmi les plus utilisés dans le marché des
systèmes d'exploitation temps réel.
FreeRTOS est disponible gratuitement sous une licence MIT depuis le 29 novembre
2017. Les versions précédentes étaient disponibles sous licence GPL modiée et
utilisable sans paiement de redevances, cette licence n'oblige pas les développeurs
à publier le code de leurs logiciels applicatifs mais impose de garder le noyau
de FreeRTOS Open Source. Une licence commerciale avec le support ad hoc
(OpenRTOS) est également proposée par la société High Integrity Systems. Le
nombre de tâches exécutées simultanément et leur priorité ne sont limités que
par le matériel. L'ordonnancement est un système de le d'attente basé sur les
Sémaphores et les Mutex. Il est basé sur le modèle Round-Robin avec gestion des
priorités. Conçu pour être très compact, il n'est composé que de quelques chiers
en langage C, et n'implémente aucun pilote matériel.
Les domaines d'applications sont assez larges, car les principaux avantages de
FreeRTOS sont l'exécution temps réel, un code source ouvert et une taille très
faible. Il est donc utilisé principalement pour les systèmes embarqués qui ont des
contraintes d'espace pour le code, mais aussi pour des systèmes de traitement vidéo
et des applications réseau qui ont des contraintes "temps réel".
FreeRTOS un système d'exploitation temps réel libre et open source3 originellement
développé par Real Time Engineers Ltd. FreeRTOS est un système d'exploitation
embarqué multitâches temps réel préemptif supporte actuellement 35 architectures.
Nous allons utiliser un RTOS conforme à la spécication RTOS de la norme
CMSIS (Cortex Microcontroller Interface Standard). Cette spécication dénit
une API RTOS standard à utiliser avec les microcontrôleurs basés sur Cortex-M.
CMSIS-RTOS est une API commune aux systèmes d'exploitation temps réel, elle
fournit toutes les fonctionnalités dont nous aurons besoin pour développer un
application temps réel.
10.2 Tâche
Dans FreeRTOS, chaque tâche est décrite par un TCB (Task Control Block)
qui contient toutes les informations nécessaires an de spécier et de représenter
une tâche. Les tâches sous FreeRTOS peuvent exister sous 5 états : "supprimé",
"suspendu", "prêt", "bloqué" ou "en exécution" Dans FreeRTOS, il n'y a au-
cune variable pour spécier explicitement l'état d'une tâche, en contrepartie FreeR-
TOS utilise des listes d'états. La présence de la tâche dans un type de listes d'états
détermine son état (prêt, bloqué ou suspendu). Les tâches changeant souvent d'état,
10.2. Tâche 133
Figure 10.1 CMSIS RTOS Architecture
l'ordonnanceur n'aura alors qu'à déplacer la tâche (l'élément (xListItem) apparte-

nant à cette même tâche) d'une liste d'états à une autre.
À la création d'une tâche, FreeRTOS crée et remplit la TCB correspondant à la
tâche, puis il insère directement la tâche dans une "Ready List" (Liste contenant
une référence vers toutes les tâches étant dans l'état "Prêt"). FreeRTOS maintient
plusieurs "Ready List", une liste existe pour chaque niveau de priorité. Lors du
choix de la prochaine tâche à exécuter, l'ordonnanceur analyse les "Ready list" de
la plus haute priorité à la plus basse. Plutôt que de dénir explicitement un état "en
exécution" ou une liste associée à cet état, le noyau FreeRTOS décrit une variable
"pxCurrentTCB" qui identie le processus en exécution. Cette variable pointe vers
la TCB correspondant au processus se trouvant dans l'une des 'Ready list'.
Une tâche peut se retrouver dans l'état "bloqué" lors de l'accès à une le en lec-
ture/écriture dans le cas où la le est vide/pleine. Chaque opération d'accès à une
le est paramétrée avec un timeout(xTicksToWait), Si ce timeout vaut 0 alors la
tâche ne se bloque pas et l'opération d'accès à la le est considérée comme échouée.
Dans le cas où le timeout n'est pas nul, la tâche se met dans l'état 'bloqué' jusqu'à
ce qu'il y ait une modication de la le (par une autre tâche par exemple). Une fois
l'opération d'accès à la le possible, la tâche vérie que son timeout n'est pas expiré
et termine avec succès son opération.
Une tâche peut être volontairement placée dans l'état "textbf suspendu", elle sera
alors totalement ignorée par l'ordonnanceur et ne consommera plus aucune ressource
jusqu'à ce qu'elle soit retirée de l'état et remise dans un état "prêt".
Le dernier état que peut prendre une tâche est l'état "supprimé", cet état est né-
cessaire car une tâche supprimée ne libère pas ses ressources instantanément. Une
fois dans l'état "supprimé", la tâche est ignorée par l'ordonnanceur et une autre
tâche nommée " IDLE" est chargée de libérer les ressources allouées par les tâches
étant en état "supprimé".
Table 10.1 FreeRTOS- TCB (Task Control Block)
Variables Description
pxTopOfStacks Pointeur vers le dernier élément placé en haut de la pile
xGenericListItem Élément (xListItem) de la liste utilisé pour placer la TCB dans une liste
d'états (Prêt, bloqué ou suspendu).
xEventListItem Élément (xListItem) de la liste utilisée pour placer la TCB dans une liste
d'évènements.
uxPriority Priorité de la tâche
pxStack Pointeur vers le début de la pile du processus
pxEndOfStack Pointeur vers la n de la pile du processus
uxTCBNumber Taille de la pile en nombre de variables
pcTaskName Nombre s'incrémentant à chaque fois qu'une TCB est créée (utilisé pour
le débogage)
uxBasePriority La dernière priorité assignée à la tâche
ulRunTimeCounter Calculer le temps passé par la tâche dans un état d'exécution
pxTaskTag Permet d'ajouter un Tag à une tâche. Le Tag s'utilise pour réaliser des
Log via les sorties analogique ou digitales grâce à la fonction traceSWIT-
CHED _IN().
uxCriticalNesting Permet de sauvegarder la profondeur d'imbrication des sections critiques

de cette tâche. À chaque fois que la tâche entre dans une section critique,
la variable est incrémentée, elle est décrémentée dès que la tâche sort
d'une section critique. Cette variable est nécessaire, car il est possible
que la tâche rende la main pendant qu'elle est en section critique
La tâche 'IDLE' est créée lors du démarrage de l'ordonnanceur et se voit assigner la

plus petite priorité possible ce qui conduit à une libération retardée des ressources
lorsque aucune autre tâche est en exécution.
10.2.1 Tâche FreeRTOS
Pour développer une application basée sur un OS, on décompose l'application

en un ensemble de tâches. Nous déclarons chaque tâche en tant que fonction C
contenant une boucle innie et ne renvoie pas un résultat.
10.2.2 Etat d'une tâche
État d'une tâche Une tâche FreeRTOS peut se trouver dans l'un des états sui-
vants : Prête (Ready) : une tâche qui possède toutes les ressources nécessaires à son
exécution. Elle lui manque seulement le processeur. Active (Running) : Tâche en
cours d'exécution, elle est actuellement en possession du processeur. Attente (Blo-
cked) : Tâche en attente d'un événement (queue de messages, sémaphores, timeout
...). Une A l'arrivé de l'événement, la tâche concernée repasse alors à l'état prêt.
Suspendu (Suspend) : tâche à l'état dormant ; elle ne fait pas partie de l'ensemble
10.2. Tâche 135
Figure 10.2 Tâche FreeRTOS
des tâches ordonnançables.
Figure 10.3 États d'une tâche
10.2.3 Task Control Block (TCB)
Le TCB est une structure de données contenant les informations nécessaires à

la gestion des tâches. Une fois la tâche est créée, FreeRTOS lui assigne un TCB.
10.2.4 Ordonnancement
L'ordonnanceur de FreeRTOS est basé sur la priorité des tâches. En cas où

plusieurs tâches partagent le même niveau de priorité, c'est le round-robin qui est
utilisé.
L'ordonnancement des tâches a pour but principal de décider parmi les tâches qui
sont dans l'état prêt , laquelle exécuter. Pour faire ce choix, l'ordonnanceur de
FreeRTOS se base uniquement sur la priorité des tâches.
Les tâches en FreeRTOS se voient assigner à leur création, un niveau de

priorité représenté par un nombre entier. Le niveau le plus bas vaut zéro et il
doit être strictement réservé pour la tâche Idle. L'utilisateur a la possibilité de
surcharger ce niveau avec une priorité personnalisée en modiant la constante :
tskIDLE_PRIORITY. Le nombre maximum de niveaux de priorités est déni par
la constante : tskMAX_PRIORITIES. Plusieurs tâches peuvent appartenir à un
même niveau de priorité.
Dans FreeRTOS Il n'y a aucun mécanisme automatique de gestion des priorités.
La priorité d'une tâche ne pourra être changée qu'à la demande explicite du
développeur.
Les tâches sont de simples fonctions qui généralement s'exécutent en boucle

innie et qui suivent la structure générique suivante :
Figure 10.4 void vATaskFunction
Dans le cas d'un micro-contrôleur possédant un seul c÷ur, il y aura à tout mo-
ment une seule tâche en exécution. L'ordonnanceur garantira toujours que la tâche
de plus haute priorité pouvant s'exécuter sera sélectionnée pour entrer dans l'état
d'exécution. Si deux tâches partagent le même niveau de priorité et sont toutes les
deux capables de s'exécuter, alors les deux tâches s'exécuteront en alternance par
rapport aux réveils de l'ordonnanceur (round robin).
An de choisir la tâche à exécuter, l'ordonnanceur doit lui-même s'exécuter et pré-
empter la tâche en état d'exécution. An d'assurer le réveil de l'ordonnanceur,
FreeRTOS dénit une interruption périodique nommé la "tick interrupt". Cette
interruption s'exécute inniment selon une certaine fréquence qui est dénie dans le
chier FreeRTOSCong.h par la constante :
Cette constante décrit alors la période de temps allouée au minimum pour chaque
tâche ou expliqué autrement, l'intervalle séparant deux réveils de l'ordonnanceur.
Comme décrit dans cette section, FreeRTOS est donc un RTOS qui utilise un or-
donnancement préemptif pour gérer les tâches. Néanmoins il peut aussi utiliser op-
tionnellement (si la directive lui est donnée) l'ordonnancement coopératif. Dans ce
mode d'ordonnancement, un changement de contexte d'exécution a lieu uniquement
10.2. Tâche 137
si la tâche en exécution permet explicitement à une autre tâche de s'exécuter (en

appelant un Yield() par exemple) ou alors en entrant dans un état de blocage.
Les tâches ne sont donc jamais préemptées. Ce mode d'ordonnancement simplie
beaucoup la gestion des tâches malheureusement il peut mener à un système moins
ecace et moins sûr. FreeRTOS peut aussi utiliser un ordonnancement hybride, uti-
lisant l'ordonnancement préemptif et l'ordonnancement coopératif. Dans ce mode,
un changement de contexte d'exécution peut aussi avoir lieu lors de l'évènement
d'une interruption.
Figure 10.5 Tick interrupt
10.2.5 Priorité
La priorité est un nombre donné à une tâche lorsqu'elle est créée ou modiée
manuellement à l'aide de primitive osThreadSetPriority. Le nombre maximum de
priorités est déni par CMSIS RTOS à osPriorityRealtime.
Figure 10.6 Priorité
10.2.6 Round robin
Les tâches d'égale priorité sont traitées de manière égale par l'ordonnanceur ; il
choisit à chaque quantum de temps une tâche selon l'algorithme round robin.
10.2.7 Gestion des tâches
10.2.7.1 Déclaration d'une tâche
Pour développer une application basée sur un OS, on décompose l'application

en un ensemble de tâches. Dans FreeRTOS une tâche est fonction C contenant
une boucle innie et ne renvoie pas un résultat. On dénit pour chaque tâche un
identicateur (Handle)
Figure 10.8 OsThreadId
On dénit aussi les paramètres de structure da la tâche.
Figure 10.9 OsThreadIdDef
Une tâche est une fonction dont le traitement se trouve dans une boucle innie.
10.2.7.2 Déclaration d'une tâche
Une tâche est créée par l'intermédiaire de la fonction osThreadCreate().

Le pointeur NULL indique qu'il n'y a pas d'argument à passer à la tâche.
Exemple de création de tâche :
10.2. Tâche 139
Table 10.2 Les paramètres de structure da la tâche.

Name Nom de la tâche
pthread Adresse de départ de la Tâche.
pthread Dénit la priorité à laquelle la tâche sera exécutée. CMSIS RTOS dénie
les priorités suivantes :
- osPriorityNormal = 0
- osPriorityAboveNormal = +1
- osPriorityHigh = +2
- osPriorityRealtime = +3
Instances Nombre maximum d'instances
stacksize Le noyau attribue à chaque tâche lors de sa création sa propre pile. La

valeur stacksize indique au noyau la taille de la pile.
Figure 10.10 void StartTask1
Figure 10.11 void StartTask2

10.2.7.3 Suppression d'une tâche
Une tâche créée peut être supprimé par la primitive :
Figure 10.12 Suppression
Exemple :
Obtenir l'identicateur de la tâche en cours d'exécution
Figure 10.13 Exemple
On peut obtenir l'identicateur de la tâche en cours d'exécution par la primitive :
Exemple :
10.2.7.4 Suspendre une tâche
Figure 10.16 Suspendre une tâche

10.2. Tâche 141
Le noyau peut être suspendu en invoquant la fonction osStatus osThread-

SuspendAll (void). Cette fonction suspend toute activité du noyau sauf les in-
terruptions. Le noyau peut reprendre son activité par la fonction osStatus os-
ThreadResumeAll( void ) .
10.2.7.5 Suspendre une tâche
Figure 10.17 Redémarrer une tâche suspendue
10.2.7.6 Redémarrer une tâche suspendue
La primitive osThreadResume permet de redémarrer une tâche déjà suspen-

due.
10.2.8 Contrôle des tâches
10.2.8.1 osDelay
Spécie le temps (en millisecondes) pendant lequel la tâche reste bloquer, ce

nombre est passé comme paramètre
Figure 10.18 osDelay

10.2.8.2 osDelayUntil
La fonction osDelay n'est pas précise. Si on veut bloquer une tâche à des
intervalles de temps réguliers, il vaut mieux utiliser la primitive osDelayUntil.
Cette fonction spécie le temps absolu pendant lequel la tâche va se débloquer.
Figure 10.19 osDelayUntil
pxPreviousWakeTime : valeur du compteur juste avant le blocage de la tâche,

elle est initialisée par la valeur courent du compteur des ticks de l'ordonnaceur en
invoquant la primitive osKernelSysTick().
millisec : temps en milliseconce pendant lequel la tâche reste bloquer.
Figure 10.20 osDelayUntil
10.2.8.3 osThreadSetPriority
Change la priorité d'une tâche
10.2.8.4 osThreadGetPriority
Renvoie la priorité d'une tâche.

10.2. Tâche 143
Figure 10.21 osThreadSetPriority
Figure 10.22 osThreadGetPriority
Figure 10.23 osKernelStart

10.2.9 Contrôle du noyau
10.2.9.1 osKernelStart
10.2.10 Gestion de la queue
Les les d'attente sont la principale forme de communication Inter-tâches. Ils

peuvent être utilisés pour envoyer des messages entre les tâches ou entre les inter-
ruptions et les tâches. Dans la plupart des cas, ils sont utilisés comme des les FIFO.
Les données à transmettre peuvent être de type entier ou pointeur.
Figure 10.24 Gestion de la queue
Pour créer un Message Queue, il faut suivre les étapes suivantes :
1. déclarer l'identicateur du Message Queue

osMessageQId myQueue01Handle ;
2. allouer de la mémoire au message

osMessageQDef(name, queue_sz, type) ;
Paramètres :
name : nom du message
Queue_sz : nombre maximum de message à placer dans la Queue
Type : type de message : entier, structure. . .
Exemple : osMessageQDef(myQueue01, 10, uint16_t) ;
Il reste maintenant de créer le Message Queue :
myQueue01Handle = osMessageCreate(osMessageQ(myQueue01),NULL) ;
Cette fonction retourne l'identicateur du Message Queue ou NULL en cas d'erreur.
10.2.10.1 osMessagePut
Une fois le Message Queue est créé, il est possible déposer des informations
dans la le de massage :
osStatus osMessagePut (osMessageQId queue_id, uint32_t info,
uint32_t millisec)
10.3. Gestion des ressources 145
queue_id : l'indicateur retourné par la fonction osMessageCreate.

info : information à poster ; peut-être un entier ou un pointeur.
millisec : temps en milliseconde maximal pendant lequel la tâche reste blo-
quer en attendant un espace disponible dans la le d'attente. osWaitForever
pour une attente innie.
Figure 10.25 osMessagePut
10.2.10.2 osMessageGet
La tâche réceptrice du message utilise la primitive osMassageGet.

osEvent osMessageGet (osMessageQId queue_id, uint32_t milli-
sec) ;
queue_id : l'indicateur retourné par la fonction osMessageCreate.
millisec : temps en milliseconde maximal pendant lequel la tâche reste blo-
quer en attendant la présence d'un élément dans la le d'attente. Si millisec
= 0, la fonction retourne immédiatement si la le est vide. La valeur osWait-
Forever permet une attente innie.
osEvent : est une structure contenant les événements renvoyés par la fonc-
tion CMSIS-RTOS :
On s'intéresse à l'union value , qui contient une valeur (v ) ou un pointeur (p).
10.3 Gestion des ressources

10.3.1 Les Sémaphores
FreeRTOS permet la création et l'utilisation de Sémaphores à plusieurs

éléments. Les sémaphores sont implémentés sous forme de le tel que le nombre
d'éléments du sémaphore représente le nombre d'éléments maximum que la le
peut contenir. La le représentant le sémaphore ne sauvegarde aucune donnée, elle
s'occupe uniquement d'enregistrer le nombre de ses entrées actuellement occupées.
La taille des éléments de la le est donc nulle (uxItemSize=0). Un accès au
Sémaphore ne fait qu'augmenter ou diminuer le nombre d'entrées occupées dans la
le et aucune copie d'élément n'est eectuée.
L'API oerte par FreeRTOS pour la gestion des sémaphores fait une diérence
entre les sémaphores à N éléments et les sémaphores binaires. Les Sémaphores
binaires peuvent être vus comme des les ne pouvant contenir qu'un seul élément.
Un Sémaphore binaire ne pourra donc être pris qu'une seule fois avant qu'il ne
devienne indisponible contrairement au Sémaphore à n éléments qui pourra être pris
à plusieurs reprises ce qui permet par exemple, de dénir un nombre de ressources
disponibles ou alors de compter le nombre d'événements qui doit être encore exécuté.
Figure 10.26 Schéma basique d'utilisation d'un sémaphore binaire
Le sémaphore est la méthode la plus utilisée pour restreindre l'accès à des res-
sources partagées ou synchroniser les processus dans un environnement de program-
mation concurrente. Un sémaphore est un conteneur de jetons ; une tâche peut
acquérir un jeton à travers une primitive système ; si le sémaphore contient un ou
plusieurs jetons, les tâches continues sont exécution et le nombre de jetons se décré-
mente. S'il n'y a aucun jeton dans le sémaphore, la tâche se met à l'état d'attente
jusqu'à la libération (remise) d'un jeton par une autre tâche. À tout moment, une
tâche peut remettre (ajouter) un jeton au sémaphore, ce qui entraine l'incrémenta-
tion de son compte.
10.3.1.1 osSemaphoreCreate
Pour utiliser un sémaphore, vous devez commencer par déclarer l'identicateur

et la variable sémaphore
10.3.1.2 osSemaphoreWait
Primitive de demande de ressource. Cette opération est équivalente à une opé-

ration P (). Si la ressource n'est pas disponible, la tâche sera bloquée jusqu'à la
Figure 10.27 osSemaphoreCreate
disponibilité de la ressource ou l'écoulement du délai.
Figure 10.28 osSemaphoreWait
Semaphore_id : l'identicateur de la sémaphore (handle)

millisec : temps d'attente de la disponibilité de la ressource en milliseconde.
La valeur osWaitForever : permet d'avoir une attente innie. Elle re-
tourne le numéro du jeton.
Figure 10.29 Exemple-osSemaphoreWait
10.3.1.3 osSemaphoreRelease
10.3.2 Mutex
L'exclusion mutuelle (communément appelée Mutex) est utilisée dans divers

systèmes d'exploitation pour la gestion des ressources. De nombreuses ressources
d'un microcontrôleur peuvent être utilisées de manière partagée, mais uniquement
par un thread à la fois (par exemple : des canaux de communication, de la mémoire
et des chiers). Les mutex sont utilisés pour protéger l'accès à une ressource
Figure 10.30 osSemaphoreRelease
partagée. Les sémaphores binaires et les mutex sont très similaires ; les Mutex
incluent un mécanisme d'héritage de prioritaire, les sémaphores binaires ne le
font pas. Cela fait des sémaphores binaires le meilleur choix pour implémenter
la synchronisation entre les tâches, et les mutex pour implémenter une simple
exclusion mutuelle.
Un Mutex est utilisé an de protéger une ressource partagée.
Figure 10.31 Schéma d'utilisation d'un Mutex pour assurer l'exclusion mutuelle
L'implémentation des Mutex dans FreeRTOS est similaire à celle des Séma-
phores binaires (sous la forme d'une le) sauf que la tâche qui prend le Mutex doit
obligatoirement le rendre. Cela peut être vu comme l'association d'un jeton à une
ressource, une tâche prend le jeton et utilise la ressource puis rend le jeton à la
n, au même moment aucun autre jeton supplémentaire ne pourra être associé à la
tâche.
Une autre diérence majeure entre les Mutex et les Sémaphores binaires dans
FreeRTOS est le système d'héritage de priorité. Quand plusieurs tâches demandent
à prendre un Mutex, la priorité du détenteur du Mutex est xée momentanément à
la valeur de la plus haute priorité parmi les tâches qui attendent sa libération. Cette
technique a pour eet de prévenir les phénomènes à risques d'inversion de priorité
même si cela ne garantit pas une sécurité infaillible face à ces phénomènes.
Pour utiliser les mutex, il faut déclarer la variable mutex et l'initialiser :
Figure 10.32 mutex
10.3.2.1 osMutexCreate
Crée un mutex
Figure 10.33 osMutexCreate
10.3.2.2 osMutexWait
Demande d'accès à la ressource partagée
Figure 10.34 osMutexWait
mutex_id : l'identicateur du mutex (handle)

millisec : temps d'attente de la disponibilité de la ressource en milliseconde.
La valeur osWaitForever permet d'avoir une attente innie.

Exemple :
La tâche reste bloquée jusqu'à la disponibilité de la ressource.
10.3.2.3 osMutexRelease
Primitive de libération de ressource
Figure 10.36 osMutexRelease
10.3.3 Problème d'inversion de priorité
Soient trois tâches TaskA (haute priorité), TaskB et TaskC (Basse priorité) et
R une ressource partagée par les trois tâches. Supposons que TaskC est en possession
de la ressource R ; TaskC est préemptée par TaskA plus prioritaire, lorsque TaskA
souhaite prendre la ressource R elle sera bloquée à cause de la non disponibilité de
R (déjà pris par TaskC), dans ce cas TaskB peut être exécutée si elle est prête. Ce
phénomène est appelé inversion de priorité.
Pour pallier ce défaut, on attribue à la tâche en possession de ressource (TaskC),
la priorité de la tâche la plus prioritaire des tâches demandant la ressource (héritage
de priorité). Dans ce cas, lorsque TaskA est bloquée, c'est la TaskC qui reprend son
exécution et non pas TaskB (TaskC à la même priorité que TaskA). TaskC revient
à sa priorité ordinaire quand elle sort de la section critique (libère la ressource).
10.3.4 La gestion des interruptions
FreeRTOS n'impose aux développeurs aucune stratégie spécique pour la ges-

tion des interruptions mais il ore plusieurs moyens pour que la stratégie choisie
puisse être implémentée et maintenue facilement.
Figure 10.37 Problème d'inversion de priorité(1)
Figure 10.38 Problème d'inversion de priorité(2)

Les routines d'interruptions (ISR) sont des fonctions exécutées par le micro-
contrôleur lui-même et qui ne peuvent être gérées par FreeRTOS, ce qui peut po-
ser certains problèmes. Pour ces raisons, les routines d'interruptions ne peuvent pas
utiliser les fonctions habituelles de l'API FreeRTOS que toute autre tâche basique
peut utiliser. Néanmoins FreeRTOS dénit un groupe de fonctions spécialement
conçues pour les ISR, par exemple, une ISR utilisera la fonction xSemaphoreGi-
veFromISR() plutôt que xSemaphoreGive(), de la même manière, elle utilisera
la fonction xQueueReceiveFromISR() plutôt que xQueueReceive().
An de spécier une politique de gestion des interruptions et de gérer l'accès aux
fonctions du noyau spéciques aux ISR, FreeRTOS dénit des constantes dans le
chier de conguration FreeRTOSCong.h :
congKERNEL_INTERRUPT_PRIORITY : Dénit le niveau de

priorité de l'interruption temporelle (ang. Tick interrupt) qui est une in-
terruption périodique utilisée pour lancer l'ordonnanceur à chaque intervalle
de temps.
congMAX_SYSCALL_INTERRUPT_PRIORITY : Dénit le
plus haut niveau de priorité pour lequel les fonctions spéciques aux ISR
de FreeRTOS peuvent être utilisées.
La dénition de ces deux constantes permet de spécier une politique de gestion des
ISR selon leur niveau de priorités :
Une ISR ayant un niveau de priorité compris entre

congKERNEL_INTERRUPT_PRIORITY et cong-
MAX_SYSCALL_INTERRUPT_PRIORITY pourra utiliser
les fonctions de l'API spécique aux ISR, pourra préempter une tâche, mais
pas le noyau ni une tâche exécutant une section critique. Elle ne pourra pas
être préemptée par l'ordonnanceur car l'interruption du tick timer a une
priorité plus basse.
Une ISR ayant un niveau de priorité strictement supérieur à cong-
MAX_SYSCALL_INTERRUPT_PRIORITY pourra préempter
l'ordonnanceur, même lors de l'exécution de sections de code critique. En
contrepartie elle n'aura plus accès à aucune des fonctions de l'API de
FreeRTOS.
Une ISR n'utilisant aucune des fonctions de l'API de FreeRTOS peut utiliser
n'importe quel niveau de priorité.
La dénition des deux constantes précédentes ajoute aussi aux ISR la particula-
rité d'imbrication d'interruptions (ang. Interrupt Nesting). L'imbrication d'interrup-
tions est la possibilité qu'une deuxième interruption ait lieu au même moment que le
traitement d'une autre interruption par une ISR. Cette deuxième interruption peut
préempter la première si elle dispose d'une priorité plus élevée. Il est à noter que les
priorités des interruptions sont dénies par l'architecture du micro-contrôleur. Ce
sont des priorités matérielles qui n'ont aucune relation avec les priorités logicielles
que l'on peut attribuer aux tâches grâce à FreeRTOS.
Figure 10.39 Gestion d'interruptions matérielles par FreeRTOS selon leurs ni-
veaux de priorité
10.3.5 La gestion de la mémoire
Le noyau FreeRTOS doit allouer dynamiquement la mémoire RAM à chaque

fois qu'une tâche, une le ou un Sémaphore est créé. L'utilisation des traditionnelles
méthodes Malloc() et Free() est toujours possible mais elle peut poser quelques
problèmes car elles ne sont pas déterministes et elles peuvent sourir d'une mé-
moire trop fragmentée. De ce fait, deux méthodes reprenant les mêmes prototypes
existent dans FreeRTOS : pvPortMalloc() et vPortFree(). Chacune d'elles
est implémentée de trois manières diérentes décrites dans les chiers Heap_1.c,
Heap_2.c et Heap_3.c mais l'utilisateur est libre de dénir ses propres fonctions.
La constante congTOTAL_HEAP_SIZE dénie dans le chier de congura-
tion FreeRTOSCong.h
10.3.5.1 La première implémentation
Cette version ne dénit pas de méthode pour libérer de l'espace mémoire RAM.
La mémoire est divisée en un tableau de taille congTOTAL_HEAP_SIZE
(en octets) nommé "la pile FreeRtos". Lorsque le noyau a besoin d'allouer de
la mémoire, il réserve deux espaces libres pour une même tâche. Le premier est
utilisé pour la TCB alors que le second représente la le. Dans la mesure où l'espace
mémoire des tâches n'est jamais libéré, la pile se remplit jusqu'à épuisement de
l'espace disponible.
10.3.5.2 La deuxième implémentation
Cette représentation se diérencie de la première par le fait qu'elle dispose d'une

méthode vPortFree() qui libère la mémoire allouée pour une tâche et peut l'allouer
de nouveau à une autre tâche. Il faut que la taille du bloc mémoire de la nouvelle
Figure 10.40 Schéma explicatif de la première implémentation de l'allocation de
la mémoire dans FreeRTOS
tâche soit au maximum égale à la taille du bloc de l'ancienne tâche.
Figure 10.41 Schéma explicatif de la seconde implémentation de l'allocation de
la mémoire dans FreeRTOS
10.3.5.3 La troisième implémentation
Il ne s'agit ici que d'une redénition de Malloc() et Free() mais où la sécurité

a été augmentée en suspendant toutes les tâches pendant la durée de l'opération sur
la mémoire.
10.4. Exemples 155
10.4 Exemples
sage Queue)
EXP1 : communication inter-tâches (utilisation de Massage Queue)

myTask01 : envoie un pointeur sur une structure nommée dataa dans la le
des messages toutes les secondes,
Interruption TIM10 : envoie une valeur entière Val dans la le des mes-
sages toutes les secondes,
myTask02 : consomme le message envoyé par myTask01 et l'ache sur le
terminal via la fonction printf,
myTask03 : consomme le message envoyé par l'interruption TIM10 et l'af-
che sur le terminal via la fonction printf,
10.4.2 Exemple 2-Synchronisation par Sémaphore
EXP2 : Synchronisation par Sémaphore Par défaut l'ordonnanceur exécute

myTask01 avant myTask02, les sémaphores permettent de synchroniser les tâches
an d'inverser l'ordre de leur exécution (myTask02 précède myTask01).
10.4.3 Exemple 3- Protection des ressources partagées par Mutex.
EXP3 : Protection des ressources partagées par Mutex. La fonction

printf de debug viewer est considérée comme ressource partagée. Nous utilisons les
Mutex pour acher les messages convenablement (sans chevauchement).
10.5 Architectures matérielles supportées

Altera : Nios II
ARM architecture : ARM7, ARM9, ARM Cortex-M0, ARM Cortex-M3,
ARM Cortex-M4, ARM Cortex-M7
Atmel : Atmel AVR, AVR32, SAM3, SAM7, SAM9
Cortus : APS3
Espressif Systems : ESP32, ESP8266
Fujitsu : MB91460 series, MB96340
Freescale : Coldre V1, Coldre V2, HCS12, Kinetis
Intel : x86, 8052
Microcontrôleur PIC : PIC18, PIC24, dsPIC, PIC32
Renesas : 78K0R, RL78, H8/S, RX600, RX200, SuperH, V850
STMicroelectronics : STM32, STR7
Texas Instruments : MSP430, Stellaris, Tiva C
Xilinx : MicroBlaze
IBM : PPC405, PPC404
NXP : LPC2000, LPC1000, LPC4300
Figure 10.42 EXP1 : communication inter-tâches (utilisation de Massage

Queue(1)
10.5. Architectures matérielles supportées 157

Queue(2)

Queue(3)

Queue(4)
Figure 10.46 EXP2 : Synchronisation par Sémaphore
Figure 10.47 Avant la synchronization

Figure 10.48 Après synchronization

Figure 10.49 EXP3 : Protection des ressources partagées par Mutex.

Figure 10.50 Avant la protection de la ressource : les messages se chevauchent
Figure 10.51 Après protection de ressource
Inneon : TriCore, XMC4000

Microsemi : SmartFusion
Cypress : PSoC
Energy Micro : EFM32
Travaux Pratiques
Annexe A
FreeRTOS
A.1 Nucleo-FR411RE
La carte STM32 Nucleo ore aux utilisateurs un moyen abordable et exible
d'essayer de nouvelles idées et de construire des prototypes avec n'importe quelle
gamme de microcontrôleurs STM32, en choisissant parmi les diverses combinaisons
de performances, de consommation d'énergie et de fonctionnalités. La prise en charge
de la connectivité Arduino et les en-têtes ST Morpho facilitent l'extension des
fonctionnalités de la plate-forme de développement ouverte STM32 Nucleo avec un
large choix de blindages spécialisés. La carte STM32 Nucleo ne nécessite aucune
sonde séparée car elle intègre le débogueur / programmeur ST-LINK / V2-1.
Figure A.1 La carte STM32 NucleFR11RE
A.1.1 Caractéristiques du microcontrôleur
STM32F411RET6 dans le package LQFP64

Processeur ARM® 32 bits Cortex®-M4 avec FPU
Fréquence CPU maximale de 100 MHz
VDD de 1,7 V à 3,6 V
166 Annexe A. FreeRTOS
Flash de 512 Ko
128 Ko de SRAM
GPIO (50) avec capacité d'interruption externe
ADC 12 bits avec 16 canaux
RTC
Minuteries (8)
I2C (3)
USART (3)
SPI (5)
USB OTG pleine vitesse
SDIO
A.1.2 Fonctionnalités Nucleo
Deux types de ressources d'extension

Connectivité Arduino Uno Revision 3
En-têtes de broches d'extension Morpho STMicroelectronics pour un ac-
cès complet à toutes les E / S STM32
Débogueur / programmeur ST-LINK / V2-1 intégré avec connecteur SWD
Commutateur de mode de sélection pour utiliser le kit en tant que ST-
LINK / V2-1 autonome
Alimentation électrique exible
USB VBUS ou source externe (3,3 V, 5 V, 7 - 12 V)
Point d'accès à la gestion de l'alimentationd
LED utilisateur (LD2)
Deux boutons poussoirs : USER et RESET
Capacité de ré-énumération USB : trois interfaces diérentes prises en charge
sur USB
Port de communication virtuelle
Stockage de masse (clé USB) pour la programmation par glisser-déposer
Port de débogage
Figure A.2 Fonctionnalités Nucleo

A.1. Nucleo-FR411RE 167
Vous pouvez trouver plus de détails sur les broches et étiquettes disponibles
dans les chiers PeripheralPins.c et PinNames.h.
Ces chiers peuvent être trouvés dans :
Dépôt ARMmbed / mbed-os sur GitHub (version à jour, utilisée avec les
commandes CLI mbed )
https ://github.com/ARMmbed/mbed-os/blob/master/targets
/TARGET_STM/TARGET_STM32F4/ TAR-
GET_STM32F411xE/TARGET_NUCLEO_F411RE/
bibliothèque mbed-dev dans developer.mbed.org (chiers source de la
bibliothèque mbed utilisée sur l' IDE du compilateur mbed )
https ://developer.mbed.org/users/mbed_ocial/code/mbed-
dev/le/default/targets/TARGET_STM/TARGET_STM32F4/
TARGET_STM32F411xE/TARGET_NUCLEO_F411RE/
A.1.3 STM32Cube
STM32Cube est un logiciel embarqué gratuit de ST qui fournit tous les pilotes
et composants middlewares nécessaires pour être rapidement opérationnel sur les
microcontrôleurs STM32 ARM Cortex-M. STM32Cube inclut FreeRTOS.
Figure A.3 STM32Cube
A.1.3.1 Points forts
Prise en charge complète du conducteur

Intergiciels graphiques, USB, TCP / IP et FAT
Exemples de projets à construire pour démontrer l'utilisation
Projets de démonstration de carte d'évaluation complète utilisant FreeRTOS
Outil de conguration graphique STM32CubeMX

Portabilité entre les familles STM32 ARM Cortex-M
Téléchargements par famille d'appareils
Qualité vériée avec l'outil d'analyse statique Code Sonar de Grammatech
A.1.3.2 Distributions STM32Cube
STM32Cube est distribué par famille d'appareils. Chaque famille prise en charge
dispose d'un seul téléchargement STM32Cube qui regroupe tous les composants lo-
giciels embarqués génériques nécessaires au développement d'une application pour
cette famille. Par exemple, il existe un seul téléchargement qui fournit tout le né-
cessaire pour les pièces STM32F4, et un seul téléchargement séparé qui fournit tout
ce dont vous avez besoin pour les pièces STM32F0. La prise en charge des appareils
est activement étendue et les futures familles STM32 seront lancées avec la prise en
charge de STM32Cube. Une couche d'abstraction commune est utilisée pour assurer
une portabilité maximale entre les familles STM32.
A.1.3.3 Blocs de construction STM32Cube
Comme on pouvait s'y attendre, le logiciel intégré STM32Cube est structuré

en un ensemble de couches d'abstraction croissante : le code de démarrage et les
interfaces matérielles de bas niveau se trouvent dans la couche inférieure, et des
exemples précongurés se trouvent dans la couche supérieure - avec des pilotes de
périphériques , les pilotes de composants et les intergiciels trouvés dans les couches
intermédiaires. Chaque couche utilise les interfaces fournies par la couche en dessous
- la couche d'abstraction assurant la portabilité entre les familles d'appareils STM32
ARM Cortex-M.
A.1.3.4 Exemples, applications et démonstrations du STM32Cube
Les exemples, applications et démonstrations sont des projets précongurés, mo-

diables et exécutables qui facilitent à la fois l'apprentissage en démontrant com-
ment utiliser les pilotes et accélèrent le développement en fournissant un bon point
de départ connu à partir duquel les applications peuvent être développées.
Exemples
Des exemples sont fournis au niveau du pilote de périphérique. Ce sont des projets
simples qui montrent comment utiliser un pilote.
Applications
Les applications sont fournies au niveau du middleware. Ils sont plus volumineux
que les projets fournis au niveau du pilote et montrent comment utiliser des compo-
sants middleware simultanément avec plusieurs pilotes de périphériques diérents.
Démonstrations
Des démonstrations sont proposées au niveau du tableau d'évaluation et de décou-
verte. Ce sont des projets très complets qui utilisent toutes les installations dis-
ponibles sur leur plate-forme matérielle cible. Cela signie qu'ils utilisent plusieurs
composants et pilotes middlewares diérents dans un même projet. Les projets de
démonstration sont exécutés sous le contrôle de FreeRTOS.
- En savoir plus sur les projets de démonstration -
Des exemples, des chiers d'application et de projet de démonstration sont fournis
pour les outils de développement IAR , Atollic (qui utilise le compilateur ARM GCC
) et Keil, et ciblent une gamme de cartes STM32 d'évaluation, de découverte, de
STM32 Nucleo et dédiées.
A.1.3.5 Exemples, applications et démonstrations du STM32Cube
FreeRTOS est conçu pour être simple et facile à utiliser : seuls 3 chiers source
communs à tous les ports RTOS et un chier source spécique au microcontrôleur
sont nécessaires, et son API est conçue pour être simple et intuitive.
FreeRTOS est porté sur de nombreuses architectures de microcontrôleurs diérentes
et sur de nombreux compilateurs diérents. Chaque port ociel est accompagné
d'une démo ocielle qui (au moins au moment de sa création) se compile et s'exé-
cute sur la plate-forme matérielle sur laquelle il a été développé sans aucune modi-
cation.
Les projets de démonstration sont fournis pour s'assurer que les nouveaux utili-
sateurs peuvent démarrer avec FreeRTOS le plus rapidement possible et avec le
minimum de tracas.
Chaque architecture prise en charge par FreeRTOS est utilisée dans de nombreux
microcontrôleurs diérents, ce qui signie que FreeRTOS peut être utilisé avec des
milliers de références de microcontrôleurs diérents. En multipliant ce nombre par le
nombre de compilateurs pris en charge, puis en multipliant à nouveau par le nombre
toujours croissant de kits de démarrage et de cartes d'évaluation qui sont mis sur le
marché, et il est évident que, malgré nos meilleurs eorts, nous ne pouvons fournir
qu'une démo ocielle des projets qui correspondent exactement à une inme frac-
tion des combinaisons possibles.
Il est toujours recommandé de créer un nouveau projet FreeRTOS en commençant
par, puis en adaptant, l'une des démos précongurées fournies . Cela garantit que le
nouveau projet inclut tous les chiers source et d'en-tête nécessaires et installe les
routines de service d'interruption nécessaires, sans eort de la part du créateur du
projet. Certains utilisateurs de FreeRTOS veulent également savoir comment créer
des projets FreeRTOS autrement qu'en adaptant un projet existant. La procédure
pour cela est documentée ci-dessous.
A.1.3.6 Anatomie d'un projet FreeRTOS
Une application FreeRTOS démarrera et s'exécutera comme une application non

RTOS jusqu'à ce que vTaskStartScheduler () soit appelée. vTaskStartSche-
duler () est normalement appelé à partir de la fonction main () de l'application. Le
RTOS contrôle uniquement le séquençage de l'exécution après l'appel de vTaskS-
tartScheduler () .
Il est fortement recommandé de s'assurer que le code s'exécute correctement (code
de démarrage correct, conguration correcte de l'éditeur de liens, etc.) sur la cible
choisie avant d'essayer d'utiliser une fonctionnalité RTOS.
A.1.3.7 Fichiers source
FreeRTOS est fourni sous forme de chiers source C standard qui sont construits
avec tous les autres chiers C de votre projet. Les chiers source FreeRTOS sont
distribués dans un chier zip. La page d' organisation du code source RTOS décrit
la structure des chiers dans le chier zip.
Au minimum, les chiers source suivants doivent être inclus dans votre projet :
FreeRTOS / Source / tasks.c

FreeRTOS / Source / queue.c
FreeRTOS / Source / list.c
FreeRTOS / Source / portable / [compilateur] / [architecture] /port.c .
FreeRTOS / Source / portable / MemMang / heap_x.c où 'x' vaut 1, 2, 3,
4 ou 5.
Si le répertoire qui contient le chier port.c contient également un chier de langage

d'assemblage, le chier de langage d'assemblage doit également être utilisé.
A.1.3.8 Fichiers source facultatifs
Si vous avez besoin d' une fonction de minuterie logicielle , ajoutez FreeRTOS
/ Source / timers.c à votre projet.
Si vous avez besoin de la fonctionnalité de groupe d'événements , ajoutez
FreeRTOS / Source / event_groups.c à votre projet.
Si vous avez besoin d' une fonctionnalité de tampon de ux ou de tampon
de messages , ajoutez FreeRTOS / Source / stream_buer.c à votre projet.
Si vous avez besoin d'une fonctionnalité de co-routine, ajoutez FreeRTOS /
Source / croutine.c à votre projet (notez que les co-routines sont obsolètes et
non recommandées pour les nouvelles conceptions).
A.1.3.9 Fichiers d'en-tête
Les répertoires suivants doivent être dans le chemin d'inclusion du compilateur

(le compilateur doit être invité à rechercher ces répertoires pour les chiers d'en-
tête) :
FreeRTOS / Source / inclure

FreeRTOS / Source / portable / [compilateur] / [architecture].
Quel que soit le répertoire contenant le chier FreeRTOSCong.h à utiliser
- voir le paragraphe Fichier de conguration ci-dessous.
Selon le port, il peut également être nécessaire que les mêmes répertoires se
trouvent dans le chemin d'inclusion de l'assembleur.
A.1.3.10 Fichier de conguration
Chaque projet nécessite également un chier appelé FreeRTOSCong.h

adapte le noyau RTOS à l'application en cours de construction. Il est donc spé-
cique à l'application, pas au RTOS, et doit être situé dans un répertoire d'appli-
cation, pas dans l'un des répertoires de code source du noyau RTOS. Si heap_1,
heap_2, heap_4 ou heap_5 est inclus dans votre projet, la dénition cong-
TOTAL_HEAP_SIZE dimensionnera le tas FreeRTOS. Votre application ne
sera pas liée si congTOTAL_HEAP_SIZE est déni trop haut. La dénition
congMINIMAL_STACK_SIZE dénit la taille de la pile utilisée par la tâche
inactive. Si congMINIMAL_STACK_SIZE est déni trop bas, la tâche inactive
générera des débordements de pile. Il est conseillé de copier le paramètre congMI-
NIMAL_STACK_SIZE à partir d'une démo ocielle FreeRTOS fournie pour
la même architecture de microcontrôleur. Les projets de démonstration FreeRTOS
sont stockés dans des sous-répertoires du répertoire FreeRTOS / Demo. Notez que
certains projets de démonstration sont anciens et ne contiennent donc pas toutes les
options de conguration disponibles.
A.1.3.11 Vecteurs d'interruption
[Utilisateurs de Cortex-M : des informations sur l'installation des

gestionnaires d'interruptions sont fournies dans la FAQ L'application
que j'ai créée se compile, mais ne s'exécute pas ]
Chaque port RTOS utilise une minuterie pour générer une interruption de gra-
duation périodique. De nombreux ports utilisent des interruptions supplémentaires
pour gérer la commutation de contexte. Les interruptions requises par un port
RTOS sont traitées par les chiers source du port RTOS fournis.
La méthode utilisée pour installer les gestionnaires d'interruption fournis par
le port RTOS dépend du port et du compilateur utilisés. Reportez-vous et, si
nécessaire, copiez l'application de démonstration ocielle fournie pour le port utilisé.
Annexe B
TP2
B.1 Objectifs :
Congurer PA5 en tant que sortie GPIO avec le label LED_GREEN
Congurer le PC13 comme GPIO_EXTI13 avec le label BLUE_BUTTON
Ajouter le middleware FreeRTOS au projet avec CMSIS_OS
Ajoutez 2 tâches et un sémaphore binaire et utilisez-les pour réagir à
l'appui sur un bouton (interruption) et au contrôle des LED (ON/OFF).
B.2 Congurer PA5 en tant que sortie GPIO avec le

label LED_GREEN
B.2.1 Créer un nouveau projet STM32
Pour démarrer un nouveau projet, allez dans [File]> [New]> [STM32Project]

comme indiqué dans la Figure suivante.
Figure B.1 Créer un nouveau projet STM32
B.2.2 Sélectionner MCU ou la carte souhaitée
Sélectionner MCU ou la carte souhaitée. Dans l'exemple illustré à la Figure C.2,

la carte sélectionnée est la STM32F411RE . Cliquer sur [Next> ].
174 Annexe B. TP2
Figure B.2 Sélectionner MCU ou la carte souhaitée
Après la sélection de la cible vient l'étape de conguration du projet illustrée à

la Figure C.3. Le paramètre Type de projet ciblé détermine si le projet est généré
par STM32CubeMX ou non. Un projet vide est un squelette d'un projet sur lequel
s'appuyer tandis que STM32Cube indique un projet géré par STM32CubeMX.
B.3 Ajouter 2 tâches et un sémaphore binaire

Ajoutez 2 tâches et un sémaphore binaire et utilisez-les pour réagir à l'appui sur
un bouton (interruption) et au contrôle des LED (ON/OFF)
B.4 Congurer le PC13 comme GPIO_EXTI13 avec le

label BLUE_BUTTON
B.5 Semaphore
Ajouter la fonction void HAL_GPIO_EXTI_Falling_Callback à la
main.c
B.5. Semaphore 175
Figure B.3 Conguration du projet

176 Annexe B. TP2

B.5. Semaphore 177
Figure B.8 Ajouter 2 tâches

178 Annexe B. TP2

B.5. Semaphore 179
Figure B.11 sémaphore binaire
Figure B.12 Timers

180 Annexe B. TP2
Figure B.13 Conguration
Figure B.14 Timers
Figure B.15 Générer le code

B.5. Semaphore 181

182 Annexe B. TP2

B.5. Semaphore 183
Figure B.21 Congurer le PC13 comme GPIO

184 Annexe B. TP2
Figure B.22 Congurer le PC13 comme GPIO
Figure B.23 Semaphore

B.5. Semaphore 185

186 Annexe B. TP2
Figure B.27 Programmer

Annexe C
TP3
C.1 Objectifs :
Conguration de RTOS avec CubeMX
Création deux tâches Blink01 et Blink02 avec CubeMX
Utilisation des priorités pour résoudre certains problèmes courants
Implémentation et vérication sur la carte NUCLEO-F411RE
C.2 Créer un nouveau projet STM32

Pour démarrer un nouveau projet, allez dans [File]> [New]> [Projet STM32]
comme indiqué dans la Figure suivante.
Figure C.1 Créer un nouveau projet STM32
Cliquer sur Next puis Finish
C.3 Conguration de RTOS avec CubeMX

Cliquer sur Pinout et Conguration puis CMSIS_V2
188 Annexe C. TP3

C.3. Conguration de RTOS avec CubeMX 189

190 Annexe C. TP3
Figure C.6 Les Taches
C.4 Création deux tâches Blink01 et Blink02 avec Cu-

beMX
Cliquer sur Conguration puis sur Tasks and Queues
Add Tache Blink01
Add Tache Blink02
Figure C.7 Conguration-Blink01
Cliquez sur SYS puis sur SYS Mode and Conguration puis sélectionnez
C.4. Création deux tâches Blink01 et Blink02 avec CubeMX 191
Figure C.8 Conguration-Blink02
Figure C.9 Conguration

192 Annexe C. TP3
TIM5
Figure C.10 Conguration
Cliquez sur SYS puis Device Conguration Tool Code Generation
Figure C.11 Les taches Blink01 et Blink02
Ajoutez les lignes suivants pour les taches Blink01 et Blink02 :

Compilez le code :
Générez le projet et démarrez une session de débogage. Appuyez sur le bouton
Reprise pour commencer à exécuter le programme sur votre carte Nucleo. Vous
Figure C.12 Code

194 Annexe C. TP3
Figure C.13 Code
Figure C.14 Code

devriez voir le voyant LD2 clignoter, mais à un cycle de service variable qui augmente
ou diminue par étapes distinctes. C'est le résultat des deux threads avec des temps
d'attente diérents.
Figure C.15 Programmation

Annexe D
TP4
D.1 Objectifs :
Conguration de RTOS gratuite avec CubeMX
Bénécier de l'utilisation d'un RTOS.
Création de tâches avec ou sans CubeMX
Commençons par congurer le CubeMX
D.2 Conguration du CubeMX

Après avoir sélectionné le contrôleur, le CubeMX ouvrira la page par défaut
pour vous. Sélectionnez maintenant le FREERTOS et suivez la capture d'écran
ci-dessous.
Figure D.1 Conguration du CubeMX

198 Annexe D. TP4
D.3 Conguration RTOS
Je choisis la version 1, car elle est prise en charge par la majorité des appareils
STM32. Ensuite, allez dans l'onglet Tâches et les d'attente et vous verrez ici
une tâche par défaut, déjà créée pour vous. Double-cliquez dessus et vous pouvez
voir les informations suivantes.
Figure D.2 Conguration RTOS
Pour l'instant, vous devez vous concentrer uniquement sur le nom de la tâche,
la priorité et la fonction d'entrée. Maintenant, nous allons créer une tâche ici, et
ci-dessous sont les propriétés de cette tâche.
Je l'appelle donc tâche 2, avec une priorité normale, et la fonction d'entrée est
Task2_init. Vous en aurez une meilleure idée une fois que nous aurons écrit le
programme.
Une autre chose importante à propos de l'utilisation de RTOS est que nous ne
pouvons pas utiliser systick comme base de temps. Alors allez sur sys et choisissez
une autre base de temps comme indiqué ci-dessous.
En dehors de ceux-ci, j'utilise UART 2 pour transmettre des données et les

broches PA0 et PA1 comme sortie. Une fois le code généré, ouvrez le chier main.c
et il est temps de connaître l'importance d'utiliser RTOS.
D.3. Conguration RTOS 199

200 Annexe D. TP4
D.4 Avantage d'utiliser un RTOS

Supposons une situation, où je veux basculer 2 broches, et chacune à des dé-
lais respectifs. Donc, fondamentalement, je veux que les deux broches basculent en
même temps. Bien sûr, ce n'est pas possible avec une programmation simple, car
le microcontrôleur exécutera 1 instruction en premier et en seconde. Et le premier
doit attendre la n de la deuxième exécution, même dans une boucle while. Pour
surmonter ce problème, nous utiliserons le RTOS. Donc, nous avons créé 2 tâches,
et si vous faites déler le chier main.c, vous verrez que les fonctions d'entrée pour
les tâches y sont dénies.
Nous allons basculer la broche PA0 dans la tâche par défaut et la broche PA1
dans la tâche 2. De cette façon, l'ordonnanceur planiera le temps pour ces deux
tâches, an qu'elles aient susamment de temps pour être exécutées. Vous pouvez
vérier ci-dessous la lecture de l'oscilloscope, quand le code ci-dessus a été exécuté.
D.5 Créer une tâche

An de créer une nouvelle tâche, nous devons suivre un ensemble d'étapes, et
elles sont les suivantes : -
1.) Dénissez un ThreadID pour la tâche. Cette variable stockera l'ID unique de
la tâche, une fois créée. Plus tard, toutes les opérations nécessiteront cet identiant.
D.5. Créer une tâche 201
Figure D.6 DS0138
Figure D.7 DS0138+STM32

202 Annexe D. TP4
Figure D.8 DS0138
osThreadId Task3Handle ;
2.) Dénissez la fonction de saisie pour la tâche. C'est la fonction principale de la
tâche. Votre programme y sera écrit. N'oubliez pas que les tâches du Free RTOS
ne sont pas conçues pour gérer une valeur de retour. Ainsi, la fonction d'entrée doit
toujours avoir une boucle innie à l'intérieur de laquelle tout votre programme doit
être écrit.
Figure D.9 Task3_init
3.) Dans notre fonction principale, nous devons d'abord dénir la tâche, puis la
créer.
Figure D.10 osThreadDef
osThreadDef prend les paramètres comme le nom de la tâche, la fonction

D.6. Gestion des priorités dans RTOS 203
d'entrée, la priorité, l'instance et la taille de la pile.

Une fois la tâche dénie, nous pouvons la créer en utilisant osThreadCreateet attri-
buer l'ID au Task3Handle.
D.6 Gestion des priorités dans RTOS

Jusqu'à présent, nous avons vu comment eectuer plusieurs tâches en utilisant
RTOS. Mais il y a certains problèmes qui l'accompagnent. Par exemple, supposons
que nous souhaitons envoyer des données via l'UART, via les trois tâches, en même
temps. Lorsque nous écrivons un programme pour ce faire, le résultat ne sera pas
exactement le même. Au lieu de cela, la transmission aura lieu de telle sorte qu'une
seule tâche enverra les données en 1 seconde, qu'une autre tâche pendant une autre
seconde et ainsi de suite.
Cela se produit lorsque nous essayons d'utiliser les ressources partagées entre les
tâches avec les mêmes priorités. La deuxième tâche doit attendre que la première
termine son exécution, et que seul le contrôle y parvient. Et de même, la troisième
tâche attendra la n de la deuxième. Pour éviter ces situations, nous utilisons des
priorités diérentes pour diérentes tâches. Cela signie que nous devons redénir
nos priorités de tâches dans la fonction principale.
Figure D.11 osThreadDef
Désormais, les TAsk2 ont la priorité la plus élevée, que la tâche par défaut et
la tâche3 la plus basse. Lorsque le programme s'exécute, la tâche2 s'exécutera
en premier, la tâche par défaut et enn le TAsk3. Et les trois tâches enverront les
données en même temps.
Annexe E
TP5
E.1 Objectifs :
Les objectifs sont :
Utiliser un UART et docklight.
Création des tâches avec CubeMX
E.2 Conguration de RTOS avec CubeMX

E.2.1 Téléchargement de logiciel docklight
https ://docklight.de/downloads/
Figure E.1 docklight
E.2.2 Créer un nouveau projet STM32
comme indiqué dans les Figures suivantes.
Cliquez sur Finish
Cliquez sur Yes
Conguration des entrées/sorties.
Conguration RTOS
Sélectionnez FREERTOS et dans l'interface FREERTOS Mode and
Conguration choisissez CMSIS_V1
206 Annexe E. TP5
Figure E.2 Projet STM32

E.2. Conguration de RTOS avec CubeMX 207

208 Annexe E. TP5
Conguration UART
Sélectionnez UART2 et dans l'interface UART2 Mode and Conguration

choisissez Asynchrone et dans Hardware Flow Control (RS232) choi-
sissez Disable.

Conguration SYS
Figure E.8 Conguration SYS
Ajouter des Taches

Sélectionnez Tasks and Queues et ajoutez myTask02 et myTask03 avec
Priority osPriorityNormal
UART
Sélectionnez UART2 puis Parameter Setting et modiez Baud Rate à
115200 .
Sélectionnez RCC puis NVIC Settings et cochez RCC global interrupt
Enabled
Sélectionnez Yes
Ajoutez les lignes suivants :
Compilez le code :
Debug main.c :
Programmez la carte :
Docklight
Changer le code :
210 Annexe E. TP5
Figure E.9 Ajouter des Taches
Figure E.10 UART conguration

Figure E.12 RCC global interrupt

212 Annexe E. TP5
Figure E.14 Taches
Figure E.15 Compilez le code

Figure E.16 Debug main.c
Figure E.17 Programmez la carte

214 Annexe E. TP5
Figure E.18 Docklight

Figure E.20 Changer le code

216 Annexe E. TP5
Figure E.23 Carte STM32

Annexe F
TP6
F.1 Objectifs :
Utiliser un UART et docklight.
Création deux tâches avec CubeMX (Tache 1 et 2)
Test et vérication
F.1.1 Créer un nouveau projet STM32
comme indiqué dans les Figures suivantes.
Figure F.1 Projet STM32
- Cliquer sur Next puis Finish

Sélectionner Clear Pinouts puis PA5 (GPIO_Output)
Sélectionner PC13 (GPIO_input)
F.2 Conguration de RTOS avec CubeMX

Conguration UART
Sélectionnez UART2 et dans l'interface UART2 Mode and Conguration

choisissez Asynchrone et dans Hardware Flow Control (RS232) choisissez
Disable.
Conguration SYS
UART
218 Annexe F. TP6

F.2. Conguration de RTOS avec CubeMX 219

220 Annexe F. TP6

Sélectionnez UART2 puis Parameter Settinget modiez Baud Rate à

115200
F.2.1 Verication avec logiciel docklight.
Vérication : - Si on appuis sur le Bouton (Blue) : Tache 2 - Si on : Tache 1

222 Annexe F. TP6


224 Annexe F. TP6

Figure F.15 docklight.

226 Annexe F. TP6

Annexe G
TP7
G.1 Objectifs :
Comment utiliser FreeRTOS avec Arduino ?
Téléchargez et installez FreeRTOS dans Arduino IE
G.2 Comment utiliser FreeRTOS avec Arduino ?

Le RTOS utilisé dans ce projet est FreeRTOS. FreeRTOS est développé par
Real Time Engineers Ltd. Il s'agit d'un noyau open-source populaire de système
d'exploitation en temps réel. De plus, il est utilisé pour les appareils embarqués qui
comme microcontrôleurs, Arduino. Il est principalement écrit en C mais certaines
fonctions sont écrites en assemblage. Il existe également SafeRTOS et OpenRTOS
disponibles en ligne qui sont similaires à FreeRTOS.
G.3 Téléchargez et installez FreeRTOS dans Arduino

IDE
Tout d'abord, vous devez télécharger et installer FreeRTOS dans Arduino IDE.
Mais si vous n'avez pas utilisé Arduino IDE auparavant, vous devriez suivre le
didacticiel suivant :
https ://microcontrollerslab.com/introduction-arduino-ide/
Après cela, accédez à ce lien github et téléchargez la bibliothèque FreeRTOS :
Figure G.1 Bibliothèque FreeRTOS
Après avoir téléchargé la bibliothèque FreeRTOS, extrayez le dossier et collez

ce dossier extrait dans le dossier des bibliothèques Arduino IDE comme indiqué
ci-dessous.
La bibliothèque FreeRTOS peut également être installée directement via le

gestionnaire de bibliothèque Arduino. Pour cela, ouvrez Arduino IDE et allez dans
228 Annexe G. TP7
Sketch "Inclure la bibliothèque" et cliquez sur Gérer les bibliothèques.
G.4 Gestion des tâches FreeRTOS

Dans un système multitâche, une application peut être constituée de nom-
breuses tâches. Si nous utilisons un processeur à un seul c÷ur, une seule tâche peut
G.4. Gestion des tâches FreeRTOS 229
s'exécuter sur le processeur à un moment donné. Par conséquent, une seule tâche
sera en état d'exécution et toutes les autres tâches seront en état non en cours
d'exécution. Cela signie que dans les applications basées sur RTOS, les tâches
peuvent être en état d'exécution ou non en cours d'exécution.
L'état d'exécution d'une tâche peut être divisé en trois sous-états tels que l'état
bloqué, l'état prêt et l'état suspendu. La gure ci-dessous montre la durée de vie
de transition d'une tâche dans un système multitâche.
Figure G.5 FreeRTOS Task Management

230 Annexe G. TP7
G.4.1 LED clignotante avec FreeRTOS et Arduino Uno
Ce code montre un exemple simple où nous contrôlons trois LED avec trois
tâches diérentes. Chaque tâche s'exécute après un certain temps. Ce programme
est similaire au code Arduino typique sauf que nous incluons le chier de bibliothèque
de FreeRTOS.
G.4.2 Esquisse Arduino
FreeRTOS suit à la fois la planication préventive et la planication coopérative.

Mais par défaut, cette API implémente une planication préventive par tranches de
temps. Cela signie que les tâches à haute priorité préviennent les tâches à faible
priorité et que les tâches à priorité égale utilisent une politique de temps partagé pour
obtenir des ressources CPU. Ce code crée quatre tâches avec des priorités diérentes.
Mais les trois tâches sont périodiques. En raison de la fonction vTaskDelay (), chaque
tâche passe à un état de blocage pendant une durée spéciée.
G.4.3 Sortie du moniteur série
Comme vous pouvez le voir sur la sortie du moniteur série, la tâche de priorité
la plus basse (tâche inactive) ne s'exécute que lorsque le processeur est libre et
qu'aucune autre tâche n'est disponible à exécuter.
T1 : La Tâche3 commence à s'exécuter en premier étant la tâche de priorité la

plus élevée qui est de trois. Après cela, il entre dans l'état de blocage pendant
120 ms.
T2 : Après cela, Task2 commence à s'exécuter car il atteint maintenant la
priorité la plus élevée car Task3 est en état de blocage. De même, il termine
également son exécution et passe dans un état bloqué et y reste pendant 110
ms.
T3 : Actuellement, Task3 et Task2 attendent la n du temps bloqué. Par
conséquent, Task1 commence à s'exécuter car sa priorité est supérieure à la
tâche inactive. Par conséquent, il entre également dans l'état de fonction-
nement et termine son exécution et passe en mode de blocage pendant 120
ms.
T4 : Maintenant, toutes les tâches de haute priorité ont terminé leur exécution
et ils sont dans un état bloqué en attendant que leur temps de blocage se
termine. Par conséquent, le processeur continue d'exécuter, idle_task jusqu'à
ce qu'une tâche de haute priorité sorte d'un état de blocage. De plus, le
temps de blocage le plus court est utilisé pour la tâche 1, soit 100 ms. Par
conséquent, il entrera dans l'état d'exécution avant les autres tâches de haute
priorité et de même pour Task2 et Task3.
Après cela, tous les threads continuent à s'exécuter en fonction de leur priorité
et de leur temps de blocage.
Figure G.6 LED blinking with FreeRTOS and Arduino Uno

232 Annexe G. TP7


234 Annexe G. TP7
Figure G.12 Docklight

Annexe H
TP8
H.1 Objectifs :

Arduino FreeRTOS Queue Management - Comment utiliser les les d'attente
Comment créer une le d'attente
Comment écrire et lire des données / messages
H.2 Arduino FreeRTOS Queue Management

Dans le dernier TP, nous avons vu le processus de gestion des tâches de
FreeRTOS avec Arduino Uno. Mais aujourd'hui, nous allons apprendre à créer
des les d'attente à l'aide de l'API FreeRTOS. Dans le dernier article, nous avons
vu comment créer des tâches. Mais les tâches individuelles ne peuvent pas créer
une application ecace et complète. Parce que ces tâches indépendantes sont
des programmes plus petits ayant leurs propres tâches de pile, de mémoire et
d'exécution. Par conséquent, il est évident que nous avons besoin d'un mécanisme
pour que ces tâches autonomes puissent communiquer entre elles. Pour qu'ils
puissent partager des données ou des messages entre eux.
Comme les autres noyaux RTOS modernes, FreeRTOS Kernel fournit également
un processus de communication de données entre les tâches. Celles-ci sont appelées
les d'attente de messages. Ils sont la primitive sous-jacente utilisée par tous les
mécanismes de communication et de synchronisation FreeRTOS. Ils sont utilisés
pour envoyer et recevoir des messages entre les tâches.
H.2.1 Introduction aux les d'attente
Une le d'attente de messages est une sorte de tampon FIFO qui contient des
éléments de données de taille xe. De plus, le nombre d'éléments qu'une le d'attente
peut contenir est également xe, après son initialisation. Habituellement, les tâches
écrivent des données à la n de la mémoire tampon et lisent à partir du frontal
de la mémoire tampon. Mais il est également possible d'écrire en frontal. Plusieurs
écrivains et lecteurs peuvent écrire et lire à partir du tampon.
236 Annexe H. TP8
Mais un seul write/ read peut accéder à la mémoire tampon à la fois et les
autres tâches restent bloquées. Par conséquent, le blocage est possible à la fois sur
les lectures et les écritures dans la mémoire tampon.
H.2.2 Blocage sur les lectures de le d'attente
Blocage des lectures possible dans les scénarios suivants :

Si plusieurs tâches sont prêtes à recevoir des données de la le d'attente de
messages, alors la tâche de priorité la plus élevée lit les données en premier et
la priorité la plus basse une lit les données à la n. Pendant ce temps, d'autres
tâches restent bloquées. On peut également spécier le temps maximum de
blocage d'une tâche lors de l'envoi d'une requête de lecture. Mais diérentes
tâches peuvent également avoir des temps de blocage diérents.
L'autre cas possible est lorsqu'une le d'attente est vide. Dans un tel cas,
toutes les demandes de lecture passent à un état de blocage. Une fois que les
données sont disponibles dans la le d'attente de messages (lorsqu'une autre
tâche place des données dans la le d'attente prête), tous les lecteurs sont
passés à l'état prêt en fonction de leur priorité.
H.2.3 Blocage sur les écritures en le d'attente
Tout comme lors de la lecture à partir d'une le d'attente, une tâche peut
éventuellement spécier un temps de blocage lors de l'écriture dans une le
d'attente. Dans ce cas, la durée de blocage est la durée maximale pendant laquelle
la tâche doit être maintenue dans l'état Bloqué pour attendre que de l'espace
devienne disponible dans la le d'attente si la le d'attente est déjà pleine.
Les les d'attente peuvent avoir plusieurs rédacteurs. Il est donc possible qu'une
le d'attente pleine ait plus d'une tâche bloquée sur elle en attente de terminer une
opération d'envoi. Dans ce cas, une seule tâche sera débloquée lorsque de l'espace
dans la le d'attente deviendra disponible.
La tâche qui est débloquée sera toujours la tâche de priorité la plus élevée qui
attendait de l'espace. Si les tâches bloquées ont la même priorité, alors ce sera la
tâche qui attend depuis le plus longtemps de l'espace qui est débloquée.
Cette simulation montre la séquence des lectures / écritures :
H.2.4 Utiliser l'API FreeRTOS Queue
Jusqu'à présent, nous avons couvert les bases du processus d'écriture et de lecture
des les d'attente. Commençons maintenant par la partie principale de ce TP. Cette
section couvre le contenu suivant de l'API de le d'attente FreeRTOS (FreeRTOS
queue API) :
H.2. Arduino FreeRTOS Queue Management 237
Figure H.1 Queues
Figure H.2 Queues
Figure H.3 Queues
Figure H.4 Queues

238 Annexe H. TP8
Figure H.5 Queues
Figure H.6 Queues
Figure H.7 Queues
Figure H.8 Queues

Figure H.9 Queues
Figure H.10 Queues
Figure H.11 Queues
Figure H.12 Queues

240 Annexe H. TP8
Figure H.13 Queues
Table H.1 Créer une le d'attente avec FreeRTOS

Argument Description
Return Value Le gestionnaire renvoie une valeur NULL, si susamment de mémoire
n'est pas disponible sur le tas pour créer une le d'attente, sinon il renvoie
une valeur non nulle
Queue_Length La longueur de la le d'attente qui correspond au nombre total d'élé-

ments qu'elle peut contenir
Item_Size Taille de chaque élément en octets
Comment créer une le d'attente

Comment écrire et lire des données / messages
H.2.5 Créer une le d'attente avec FreeRTOS
La fonction API xQueueCreate () est utilisée pour créer une le d'attente
avec le nombre requis d'éléments de tampon et la taille de chaque élément.
QueueHandle_t xQueueCreate( UBaseType_t Queue_Length, UBaseType_t

Item_Size ) ;
xQueueCreate () alloue de la mémoire en fonction de la longueur de la le

d'attente et de la taille des données. La mémoire aectée contient également la
structure de données requise pour une le d'attente. Par conséquent, soyez prudent
lorsque vous l'utilisez avec Arduino car Arduino est livré avec une mémoire limitée.
Cette fonction utilise la référence par des handles avec une variable de type de
retour QueueHandle_t. Ce gestionnaire décide si susamment de mémoire est
disponible sur Arduino pour créer une le d'attente non.
Par exemple, pour créer une le d'attente , créez une variable de type xQueue-
Handle. Ceci est utilisé pour stocker le handle de la variable de retour de le
d'attente.
xQueueHandle long_queue ;
La le d'attente est créée pour contenir un maximum de 5 valeurs, chacune

étant susamment grande pour contenir une variable de type long.
Long_queue = xQueueCreate (5, sizeof (long)) ;
Avant de créer des tâches qui lisent et écrivent des données dans la le d'attente,
vous devez vérier la valeur de retour du gestionnaire long_queue :
Figure H.14 Queues
H.2.6 FreeRTOS Envoi de données à la le d'attente
L'API FreeRTOS fournit ces deux fonctions pour lire et écrire des messages dans
/ depuis la le d'attente.
xQueueSendToBack () ou xQueueSendToFront () (les deux ont la même fonc-

tionnalité)
xQueueSendToFront ()
Comme leur nom l'indique, ces fonctions écrivent des données à l'avant ou à
l'arrière d'un tampon. Cette fonction prend trois arguments comme entrée et renvoie
une valeur qui est le succès ou l'échec de l'écriture du message.
Figure H.15 FreeRTOS Envoi de données à la le d'attente
H.2.7 FreeRTOS Recevoir des données de la le d'attente
Semblable à l'écriture de fonctions API, xQueueReceive () est utilisé pour

lire les messages / données à partir d'une le d'attente.
Remarque : Une fois que vous avez lu les données à l'aide de xQueueReceive
(), elles seront supprimées de la le d'attente.
242 Annexe H. TP8
Table H.2 FreeRTOS Envoi de données à la le d'attente

Argument Description
xQueue Cela fournit la référence de la le d'attente dans laquelle
nous voulons écrire des données. C'est la même variable de
handle que nous avons utilisée lors de la création de la le
d'attente avec xQueueCreate ()
pvItemToQueue Une variable de pointeur vers le message que nous voulons
envoyer à la le d'attente
TickType_t xTicksToWait Dans le cas, si la le d'attente est pleine, il spécie le temps
de blocage maximal d'une tâche jusqu'à ce que l'espace de-
vienne disponible. Passer la valeur zéro forcera la tâche à
retourner sans écrire, si la le d'attente est pleine. De même,
en passant portMAX_DELAY à function, la tâche res-
tera indéniment en état de blocage
Valeur de retour Il renvoie deux valeurs telles que pdPASS (si les données
sont écrites avec succès) et errQUEUE_FUL (si les don-
nées n'ont pas pu être écrites)
BaseType_t xQueueReceive (QueueHandle_t xQueue, void * const pvBuer,

TickType_t xTicksToWait) ;
Tous les arguments d'entrée et la valeur de retour de xQueueReceive () ont

le même fonctionnement que l'API d'écriture, sauf le deuxième argument const
pvBuer. C'est un pointeur vers une variable vers laquelle nous voulons stocker les
données reçues.
H.2.8 Exemple - données de lecture / écriture de le d'attente

Arduino FreeRTOS
Cet exemple Arduino illustre une le d'attente en cours de création , des données
envoyées à la le d'attente à partir de plusieurs tâches et des données reçues du
tampon.
La le d'attente est créée pour contenir des éléments de données de type long.
Les tâches qui envoient des données ne spécient pas d'heure de blocage,
contrairement à la tâche qui reçoit de la le d'attente.
La priorité des tâches envoyées à la le d'attente est inférieure à la priorité
de la tâche reçue de la le d'attente.
Cela signie que la le d'attente ne doit jamais contenir plus d'un élément
car dès que les données sont envoyées à la le d'attente, la tâche de réception
se débloque, anticipe la tâche d'envoi et supprime les données en laissant à
nouveau la le vide.
H.3. Esquisse complète Arduino 243
H.2.8.1 Tâche d'écriture dans la le d'attente
Ce code montre l'implémentation de la tâche qui écrit dans la le d'attente. Deux
instances de cette tâche sont créées, une qui écrit en continu la valeur 100 dans la le
d'attente et une autre qui écrit en continu la valeur 200 dans la même le d'attente.
Le paramètre de tâche est utilisé pour transmettre ces valeurs à chaque instance de
tâche.
Figure H.16 Tâche d'écriture dans la le d'attente
H.2.8.2 Lecture à partir d'une tâche de le d'attente
Ce code Arduino montre l'implémentation de la tâche qui reçoit les données de la

le d'attente. La tâche de réception spécie un temps de blocage de 100 millisecondes
et passera donc à l'état Bloqué pour attendre que les données deviennent disponibles.
Il quittera l'état Bloqué lorsque les données seront disponibles dans la le d'attente
ou que 100 millisecondes s'écouleront sans que les données ne deviennent disponibles.
Dans cet exemple, le délai d'expiration de 100 millisecondes ne doit jamais expirer
car deux tâches écrivent en permanence dans la le d'attente.
H.2.8.3 Créer une liste de les d'attente
Ce code contient la dénition de la fonction Arduino setup (). Cela crée sim-
plement la le d'attente et les trois tâches avant de démarrer le planicateur. La
le d'attente est créée pour contenir un maximum de 5 valeurs longues même si les
priorités des tâches sont dénies de sorte que la le d'attente ne contiendra jamais
plus d'un élément à la fois.
H.3 Esquisse complète Arduino

Il s'agit d'un croquis Arduino complet pour lire / écrire un message dans / depuis
la le d'attente.
244 Annexe H. TP8
Figure H.17 Lecture à partir d'une tâche de le d'attente
Figure H.18 Créer une liste de les d'attente

H.3. Esquisse complète Arduino 245
Figure H.19 lire / écrire un message dans / depuis la le d'attente
Figure H.20 lire / écrire un message dans / depuis la le d'attente

246 Annexe H. TP8
Les tâches qui envoient à la le d'attente appellent taskYIELD () à chaque

itération de leur boucle innie. taskYIELD () informe le planicateur qu'un
basculement vers une autre tâche doit se produire maintenant plutôt que de
maintenir la tâche en cours d'exécution dans l'état Running jusqu'à la n de la
tranche de temps actuelle. Une tâche qui appelle taskYIELD () est en eet
volontaire pour être supprimée de l'état En cours d'exécution.
Comme les deux tâches envoyées à la le d'attente ont une priorité identique à
chaque fois que l'une appelle taskYIELD (), l'autre commence à s'exécuter - la
tâche qui appelle taskYIELD () passe à l'état Prêt lorsque l'autre tâche d'envoi
passe à l'état En cours d'exécution. Cela amène les deux tâches d'envoi à envoyer
des données à la le d'attente à tour de rôle. La sortie produite par l'exemple 10
est illustrée dans la gure ci-dessous :
H.4 Exemple d'achage LCD et ADC de le d'attente

Arduino FreeRTOS
Dans cet exemple, nous allons créer deux tâches :
AdcTask : Il écrit la valeur ADC dans la le d'attente.

LcdTask : Il lit les données de la le d'attente et ache sa valeur sur un
écran LCD 16 Ö 2
Ce circuit lit la valeur de tension analogique avec le canal analogique A4 et

imprime la valeur sur un écran LCD 16 Ö 2 à l'aide d'Arduino
H.4.1 Comment fonctionne le code ?
Tout d'abord, nous incluons les chiers d'en-tête de FreeRTOS, de la le d'at-
tente et de l'écran LCD.
H.4.1.1 Fonction de conguration
Déclarez une variable de type QueueHandle_t. Ceci est utilisé pour stocker
le handle dans la le d'attente à laquelle accèdent tous les AdcTask et LcdTask.v
QueueHandle_t xQueue ;
Vous devez activer les bibliothèques LCD et série.
H.4.1.2 Creare Integer Queue
Créez une instance de AdcTask qui sera envoyée à la le d'attente (expédi-
teur). Créez également la tâche LcdTask qui lira à partir de la le d'attente. La
H.4. Exemple d'achage LCD et ADC de le d'attente Arduino
FreeRTOS 247
Figure H.21 Exemple d'achage LCD et ADC de le d'attente Arduino FreeR-
TOS
TOS
TOS
248 Annexe H. TP8
tâche est créée avec la priorité 2, donc au-dessus de la priorité de la tâche de l'expé-
diteur. Après cela, démarrez le planicateur pour que les tâches créées commencent
à s'exécuter.
TOS
H.4.1.3 Créer une tâche d'expéditeur
Cette fonction dénit la tâche de l'expéditeur qui est AdcTasv. Tout d'abord,
lisez la valeur ADC et stockez-la dans la variable adc_value. Après cela, utilisez
xQueueSend () pour écrire la valeur mesurée dans la le d'attente.
Le premier paramètre est la le d'attente à laquelle les données sont envoyées.
La le d'attente a été créée avant le démarrage du planicateur, donc avant
que cette tâche ne commence à s'exécuter.
Le deuxième paramètre est l'adresse des données à envoyer, dans ce cas
l'adresse de adc_value.
Le troisième paramètre est le temps de blocage - le temps pendant lequel la
tâche doit être maintenue dans l'état Bloqué pour attendre que de l'espace
devienne disponible dans la le d'attente si la le d'attente est déjà pleine.
Dans ce cas, le temps de bloc est portMAX_DELAY qui attend un temps
indéni.
H.4.1.4 Tâche du récepteur
Cette tâche LCD lit la valeur de la le d'attente et ache sa valeur sur l'écran
LCD.
Dans ce TP, nous utilisons juste une résistance variable pour l'entrée du canal
analogique. Mais vous pouvez également utiliser des capteurs tels que la tempéra-
ture, le capteur de lumière.
H.4. Exemple d'achage LCD et ADC de le d'attente Arduino
FreeRTOS 249
TOS
TOS
Annexe I
TP9
I.1 Objectifs :

Comment utiliser la le d'attente de structure FreeRTOS pour recevoir des
données à partir de plusieurs tâches
I.2 Introduction
Ce TP explique comment utiliser la le d'attente structurée FreeRTOS pour
recevoir des données de plusieurs ressources. Dans le dernier tutoriel, nous avons
appris à utiliser les les d'attente de messages avec l'API FreeRTOS et Arduino .
Mais dans cet exemple, nous avons utilisé une seule le d'attente pour recevoir et
envoyer des données à partir de tâches uniques. Mais dans les systèmes d'exploitation
en temps réel , il est également possible qu'une seule tâche reçoive des données de
plusieurs ressources en utilisant une seule le d'attente. Cependant, les tâches de
plusieurs expéditeurs peuvent écrire des données dans une seule le d'attente, mais
le problème est que la tâche de réception doit savoir d'où proviennent les données
de tâche.
I.2.1 Pourquoi utilisons-nous la structure des les d'attente ?
Pourquoi est-il nécessaire pour la tâche du récepteur de connaître la source des

données ?
Parce que sinon, il n'y a pas d'autre moyen, le récepteur peut diérencier les res-
sources de données et peut eectuer une opération signicative sur ces données. La
solution la plus simple consiste à utiliser le type de données structures pour écrire
et lire des données à partir d'une seule le d'attente. La structure doit contenir une
source de données et la valeur réelle que nous voulons communiquer avec la tâche
destinataire.
I.2.2 Exemple de le d'attente de structure pour recevoir des don-

nées de plusieurs ressources
Ce schéma de principe illustre un exemple de transfert de structure vers une

seule le d'attente.
252 Annexe I. TP9
Figure I.1 Exemple de le d'attente de structure pour recevoir des données de
plusieurs ressources
Nous créons un exemple avec Arduino qui mesure la température et la valeur du

capteur de lumière à partir des canaux A0 et A1 d'Arduino, respectivement. Après
cela, imprime la valeur des capteurs sur un écran LCD 16 Ö 2.
Tout d'abord, nous créons une le d'attente qui peut contenir la structure.
Ces éléments de structure se composent de la valeur de données et de l'éti-
quette de la ressource (comme le numéro de canal analogique)
Dans cet exemple, nous créons deux tâches d'expéditeur telles que Tempéra-
ture et LDR.
Le transmetteur de température lit la valeur du capteur LM35 à partir du
canal analogique A0 d'Arduino IDE. Après cela, il écrit la structure dans la
le d'attente qui contient la valeur ADC et le numéro de canal (A0)..
De même, une tâche de résistance dépendant de la lumière mesure l'inten-
sité lumineuse avec le canal ADC (A1) et écrit les données dans un format
structuré.
La tâche LCD (récepteur) lit également ces données de structure et traite les
données pour acher la valeur du capteur après avoir identié la source.
I.2.3 Implémentation de la structure FreeRTOS Queue dans Ar-

duino
Pour démonstration, nous implémentons un exemple utilisant Arduino. Créons

une démonstration avec deux capteurs analogiques et un écran LCD comme indiqué
dans le schéma de circuit ci-dessous :
I.2. Introduction 253
I.2.3.1 Schéma
Connectez le LM35 et le LDR aux canaux ADC A0 et A1 respectivement. De

plus, connectez également un écran LCD 16 Ö 2 avec des broches numériques Ar-
duino de D-D7.
Figure I.2 Schéma
I.2.3.2 Code de le d'attente de structure FreeRTOS
Incluez d'abord les chiers d'en-tête FreeRTOS, Queue et LCD.
Figure I.3 Code
Après cela, dénissez le nom de la broche qui se connecte à l'écran LCD.
Figure I.4 Code

254 Annexe I. TP9
Nous dénissons une structure qui se compose de deux éléments tels que la valeur
du capteur et le numéro de broche. Cette structure sera transmise à la le d'attente
pour écrire et lire les valeurs de sortie du capteur.
Figure I.5 Code
Cette ligne dénit le hanlder pour structQueue pour y accéder pour la référence
des tâches.
Figure I.6 Code
Ces deux fonctions initialisent la bibliothèque de communication LCD et Uart.
Figure I.7 Code
Créez une le d'attente de structure avec l'API xQueueCreate () et passez la

structure dénie ci-dessus dans l'argument sizeof ().
Figure I.8 Code
Dans la fonction de conguration, nous créons trois tâches qui utilisent struc-
ture_queue pour écrire et lire des données. Tout d'abord, TaskLCD est créé pour
lire les éléments de structure de la le d'attente et il a la priorité la plus élevée. In-
versement, les broches TaskTempReadPin0 () et TaskLightReadPin0 () sont créées
avec une priorité égale et inférieure à la tâche du récepteur. J'expliquerai la raison
plus tard.
Figure I.9 Code
I.2.3.3 Tâche du récepteur
TaskLcd est une tâche réceptrice qui lit les données de structure depuis
struct_queue. La tâche de réception a la priorité la plus élevée. Par conséquent,
au début de l'exécution du programme, il s'exécutera en premier, mais il entrera
dans l'état de blocage. Parce que la le d'attente sera vide. Par conséquent, il s'exé-
cutera dès que l'un des expéditeurs écrira des données dans la le d'attente. Cette
tâche s'attend toujours à recevoir des données, par conséquent, nous spécions le
temps de blocage à la valeur maximale qui est portMAX_DELAY.
I.2.3.4 Tâches de l'expéditeur
Ce sont les dénitions de deux tâches de l'expéditeur. Comme nous l'avons men-
tionné précédemment, les tâches d'écriture ont une priorité égale mais inférieure
aux tâches de réception. Par conséquent, lorsqu'une tâche à haute priorité sera dans
l'état de blocage, alors l'une des tâches à faible priorité s'exécutera en suivant un
algorithme de planication de partage de temps ou de découpage de temps. Parce
que FreeRTOS est basé sur la planication préventive prioritaire avec découpage
temporel.
256 Annexe I. TP9
Figure I.10 Code-Tâche du récepteur

Figure I.11 Code-Tâches de l'expéditeur

Résumé : Le cours de Conception des Systèmes Temps Réel s'adresse particuliè-
rement aux étudiants en Licences professionnelles et recherches, en Masters et aux
élèves ingénieurs. Les systèmes temps réel sont, en général, constitués de deux par-
ties : le système contrôlé, processus physique qui évolue avec le temps, appelé aussi
procédé ou partie opérative, et le système contrôlant appelé aussi partie commande
qui est un système informatique qui interagit avec le premier. Le système contrô-
lant prend régulièrement connaissance de l'état du procédé par le biais de capteurs,
calcule la prochaine action à réaliser sur la base des dernières mesures puis applique
une consigne au processus commandé par le biais d'actionneurs. Un système est
qualié de temps réel si sa correction ou sa validité ne dépend pas uniquement de la
justesse des résultats obtenus mais aussi des instants de production de ces résultats,
car les diérentes activités d'un tel système doivent nécessairement s'exécuter dans
des laps de temps limités appelé échéances. Le respect des contraintes temporelles
est un aspect fondamental et spécique aux systèmes temps réel, constituant la ca-
ractéristique principale qui les distingue des systèmes informatiques classiques (non
temps réel). D'une manière générale, nous distinguons trois types de systèmes temps
réel :
Les systèmes temps réel à contraintes strictes qui sont des systèmes pour
lesquels le non respect d'une échéance ne peut être toléré (exemple : la com-
mande du moteur d'un avion) car cela peut engendrer une catastrophe ;
Les systèmes temps réel à contraintes relatives.
Les systèmes temps réel à contraintes mixtes qui comprennent des pro-
grammes à contraintes strictes et d'autres à contraintes relatives.
Selon l'équipement contrôlé, les contraintes de temps peuvent être de divers ordres,
de l'ordre :
de la milliseconde : système radar,...
de la seconde : système de visualisation,...
de quelques minutes : chaîne de fabrication,...
Mots clés : Tremps réel ,Ordonnancement,Tache,
rate monotonic, EDF,LLF, Taches Indépendate apério-
diques, Serveur scrutation, ajournable, sporadique, FreeRTOS

Manuscrit

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Manuscrit

Transféré par

Droits d'auteur :

Formats disponibles

Université Tunis El Manar

Institut Supérieur d'Informatique

Conception des Systèmes Temps

Plusieurs objectifs plus contextuels seront rencontrés en chemin : penser un

1 Spécicités des Systèmes en Temps Réel 1

1.2 Analyse d'une tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Avantages du multi-tâche . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Tâches dans un contexte temps réel . . . . . . . . . . . . . . . . . . . 4

1.4.1 Cycle de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.3 Paramètres d'une tâche . . . . . . . . . . . . . . . . . . . . . 7

1.5 Ordonnancement non temps réel . . . . . . . . . . . . . . . . . . . . 8

2 Ordonnancement des Processus 13

2.2 Types d'ordonnanceurs . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Objectifs de l'ordonnanceur d'un système multi-utilisateur . . . . . 15

2.4 Ordonnanceurs non préemptifs . . . . . . . . . . . . . . . . . . . . . 15

2.4.1 Premier arrivé premier servi . . . . . . . . . . . . . . . . . . . 19

2.4.2 Shortest job rst . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4.3 Round robin/tourniquet . . . . . . . . . . . . . . . . . . . . . 19

2.5 Ordonnanceurs préemptifs . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5.1 Ordonnancement du plus petit temps de séjour . . . . . . . . 22

2.5.2 Ordonnancement circulaire . . . . . . . . . . . . . . . . . . . 22

2.5.3 Ordonnancement avec priorité . . . . . . . . . . . . . . . . . . 26

2.5.4 Files multiples (quantum variable) . . . . . . . . . . . . . . . 27

2.6 Ordonnancement à deux niveaux . . . . . . . . . . . . . . . . . . . . 27

2.7 Cas d'étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.9.2 Exercice 1 : Algorithmes non préemptifs . . . . . . . . . . . . 35

2.9.3 Exercice 2 : Algorithmes préemptifs . . . . . . . . . . . . . . 36

3 Ordonnancement de Tâches Périodiques Préemptif à Priorités

3.2 Ordonnancements A priorité Fixe . . . . . . . . . . . . . . . . . . . 40

3.2.1 Rate-Monotonic = RM  . . . . . . . . . . . . . . . . . . . . 40

3.2.2 Deadline Monotonic = DM  . . . . . . . . . . . . . . . . . . 44

4 Ordonnancement de Tâches Périodiques Préemptif à Priorités Dy-

4.2 Earliest Deadline First (EDF) . . . . . . . . . . . . . . . . . . . . . . 51

4.3 Least Laxity First (LLF) . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.3.2 Avantage et inconvénient . . . . . . . . . . . . . . . . . . . . 54

4.4 Ordonnancement en situations de surcharge . . . . . . . . . . . . . . 54

5 Analyse du Temps de Réponse 61

5.2 Principaux tests d'ordonnançabilité . . . . . . . . . . . . . . . . . . . 61

5.2.1 Analyse du facteur d'utilisation . . . . . . . . . . . . . . . . 61

5.2.2 Analyse du temps de réponse . . . . . . . . . . . . . . . . . . 62

6 Ordonnancement des Tâches Indépendantes Apériodiques 69

6.2 Traitement en arrière plan des tâches apériodiques à contraintes re-

6.3 Traitement par serveur périodique des tâches apériodiques en envi-

6.3.1 Serveur à scrutation . . . . . . . . . . . . . . . . . . . . . . . 72

6.3.2 Serveur ajournable . . . . . . . . . . . . . . . . . . . . . . . . 75

6.3.3 Serveur sporadique . . . . . . . . . . . . . . . . . . . . . . . . 77

7 Noyau Temps Réel 83

7.2 Système d'exploitation et noyau . . . . . . . . . . . . . . . . . . . . . 84

7.2.1 Boucle d'interrogation . . . . . . . . . . . . . . . . . . . . . . 85

7.2.2 Tâche pilotée par état/phase et Co-routines . . . . . . . . . . 86

7.3 Le noyau temps réel µC/OS − II . . . . . . . . . . . . . . . . . . . . 88

7.3.1 Les chiers source de MicroC/OS-II . . . . . . . . . . . . . . 89

7.3.2 Comparaison entre uC/OS et uC/OS-II . . . . . . . . . . . . 92

7.3.3 Services du noyau (1) . . . . . . . . . . . . . . . . . . . . . . 92

7.4 Le noyau temps réel RTLinux . . . . . . . . . . . . . . . . . . . . . . 94

7.5 Le noyau temps réel VXWorks . . . . . . . . . . . . . . . . . . . . . 95

7.6 Le noyau temps réel pSOS . . . . . . . . . . . . . . . . . . . . . . . . 95

8.2 Spécication selon la méthode SA-RT . . . . . . . . . . . . . . . . . 98

8.3 Présentation de la syntaxe graphique de la méthode SA-RT . . . . . 100

8.3.1 Syntaxe graphique pour l'aspect fonctionnel . . . . . . . . . 100

8.3.2 Syntaxe graphique du ot de données . . . . . . . . . . . . . 101

8.3.3 Syntaxe graphique du stockage de données . . . . . . . . . . 101

8.3.4 Syntaxe graphique de la Terminaison . . . . . . . . . . . . . 104

8.3.5 Syntaxe graphique du stockage de données . . . . . . . . . . 105

1 Spécicités des Systèmes en Temps Réel 1

2.4.2 Shortest job rst . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.1 Rate-Monotonic = RM . . . . . . . . . . . . . . . . . . . . 40

3.2.2 Deadline Monotonic = DM . . . . . . . . . . . . . . . . . . 44

7.3.1 Les chiers source de MicroC/OS-II . . . . . . . . . . . . . . 89

8.2 Spécication selon la méthode SA-RT . . . . . . . . . . . . . . . . . 98

8.3.2 Syntaxe graphique du ot de données . . . . . . . . . . . . . 101

8.4 Les diagrammes ot de données . . . . . . . . . . . . . . . . . . . . . 106

B.4 Congurer le PC13 comme GPIO_EXTI13 avec le label

C.3 Conguration de RTOS avec CubeMX . . . . . . . . . . . . . . . . . 187

D.2 Conguration du CubeMX . . . . . . . . . . . . . . . . . . . . . . . . 197

D.3 Conguration RTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Spécicités des Systèmes en

autre du traitement, et enn une dernière de la gestion de la sortie. Des mécanismes

Figure 1.1 Espace d'adressage d'un processus

En ce qui concerne les tâches matérielles, les spécications de l'application vont

Figure 1.2 Exemple des tâches matérielles et logicielles

Les tâches apériodiques sont, quant à elles, exécutées à intervalles irréguliers,

Les tâches indépendantes, dont l'ordre d'exécution peut être quelconque.

Les tâches dépendantes, pour lesquelles il existe des contraintes de précédence.