Chapitre 3 : Les systèmes Temps Réel III.
Caractéristiques d’un système temps réel
I. Définition
En informatique, on parle d'un système temps réel lorsque ce système est capable de
contrôler ou piloter un procédé physique à une vitesse adaptée à l'évolution du procédé
contrôlé.
Les systèmes informatiques temps réel se différencient des autres systèmes informatiques par
la prise en compte de contraintes temporelles dont le respect est aussi important que
l'exactitude du résultat, autrement dit le système ne doit pas simplement délivrer des résultats
exacts, il doit les délivrer dans des délais imposés.
Les systèmes informatiques temps réel sont aujourd'hui présents dans de nombreux secteurs
d'activités :
1. dans l'industrie de production par exemple, au travers des systèmes de contrôle de
procédé (usines, centrales nucléaires) ;
2. dans l’économie au travers du traitement des données boursières en « temps réel » ;
3. télécommunications (transport de la parole, systèmes de commutation, …),
4. domaine médical (assistance et supervision de malades, …),
5. contrôle de différents équipements dans les voitures, bus, trains, avions, …,
6. contrôle et régulation de trafic en milieu urbain,
7. guidage de véhicules en milieu urbain,
8. domaine militaire (suivi de trajectoires de missiles, …)
9. aérospatial (suivi de satellites, simulation de vols, pilotage automatique, …),
10. multimédia (transport d’images et de voie, téléconférences, …),
11. finance (suivi du cours des devises et actions, ...),
12. loisirs (consoles de jeu, ...),
13. domotique (sécurité d’habitations, …),
14. contrôle/commande d’appareils électroménagers.
Un système temps réel n’est pas un système "qui va vite" mais un système qui satisfait à des
contraintes temporelles.
Le développement de systèmes temps réel nécessite donc que chacun des éléments du
système soit lui-même temps réel, c’est-à-dire permettre de prendre en compte des contraintes
temporelles. Un système d'exploitation conçu pour prendre en compte ces contraintes est
appelé système d'exploitation temps réel.
II. Spécificités
Pour garantir le respect de limites ou contraintes temporelles, il est nécessaire que :
1. les différents services et algorithmes utilisés s'exécutent en temps borné mais peut être
interrompus par un processus plus prioritaire ;
2. Un système d'exploitation temps réel doit ainsi être conçu de manière à ce que les
services qu'il propose (accès hardware, etc.) répondent en un temps borné ;
3. les différents enchaînements possibles des traitements garantissent que chacun de
ceux-ci ne dépassent pas leurs limites temporelles. Ceci est vérifié à l'aide du « test
d'acceptabilité ».
1 2
1. La prévisibilité d’un STR : est un aspect important. Un STR doit être conçu tel
que ses performances soient définies dans le pire cas (alors que dans les
systèmes classiques, les performances sont définies en termes de moyenne).
2. La prévisibilité est le fait de savoir à l’avance si un système va respecter ses
contraintes temporelles (C.T.). Pour cela, il est nécessaire de connaître avec
précision les paramètres des tâches : temps global de calcul de chaque activité,
périodicité, date de réveil, etc.
3. Le déterminisme d’un STR : est le but à atteindre pour assurer la prévisibilité :
Pour qu’un système soit prévisible, il faut qu’il soit déterministe. Donc enlever
toute incertitude sur le comportement des activités (individuelles et mises
ensemble)
4. Découpage en taches
5. Utilisation du temps concret : Le temps réel (ou temps concret) sera utilisé de
plusieurs façons :
– Soit en définissant la date à laquelle une action doit être commencée
– Soit en définissant la date à laquelle une action doit être finie
– Il peut être nécessaire de pouvoir modifier ces paramètres en cours
d'exécution et de pouvoir préciser les actions à prendre en cas de
faute temporelle
6. Ordonnancement
7. Respect des contraintes temporelles
8. La fiabilité
IV. Ordre de grandeur de temps
− nanosecond - O(ns) : Temps d’accès à une RAM (5-80ns), Durée entre deux ticks
d’horloge d’un processeur Pentium (1GHz) Fréquence de 1GHz (109Hz)
− microseconde - O(μs) : Traitement dans un noyau de système d’exploitation
(changement de contexte, interruption matérielle), Systèmes utilisant des radars
(navigation, détection de mouvement, etc.), Transmission sur des bus de terrain,
transmission radio, Fréquence de 1 MHz (106 Hz)
− milliseconde - O(ms) : Temps d’accès à un disque dur SCSI ou IDE (5-20 ms), La
durée d’échantillonnage du son, protocoles de télécommunication, Fréquence de 1
KHz (103 Hz)
− seconde (s) - O(s) : Systèmes de visualisation humain (temps durant lequel l’œil
peut "intégrer" 25 images au plus), Applications multimédia, Temps de réponse
des applications informatiques (accès DB, compilation, etc.), Fréquence de 1 Hz
− L’heure (h) - O(h) : Applications de surveillance de réactions chimiques,
surveillance de données météorologiques
− Le mois, l’année - O(m, a) : Systèmes de navigation de sonde spatiale
V. Classement des systèmes temps réel
Les systèmes temps réel sont classés selon le respect des contraintes temporelles :
− Temps réel dur ou critique (hard real-time) : le non respect des contraintes
temporelles entraîne la faute du système. Ex. : contrôle de trafic aérien, système de
conduite de missile, etc.
− Temps réel souple (soft real-time) : le respect des échéances est important mais le non
respect des échéances ne peut occasionner de graves conséquences. Ex. : projection
 vidéo (décalage entre le son et l’image), Un robot qui capte des infos sur des objets
défilant sur un convoyeur
− Temps réel ferme (firm real-time) : temps réel souple avec le manquement
occasionnel des échéances. Ex. : projection vidéo (perte de quelques trames d’images).
VI. Limites des systèmes classiques pour le temps réel
− Reposent sur un OS qui offre des mécanismes mal adaptés au temps Réel
− politiques d’ordonnancement visent le partage équitable du temps d’exécution. Pas
adaptées à des tâches plus critiques que d’autres.
− les mécanismes d’accès aux ressources partagées sont à adapter pour éliminer les
incertitudes temporelles
− la gestion des E/S engendre de longues attentes (parfois non bornées)
− la gestion des interruptions n’est pas optimisée
− les mécanismes de gestion de la mémoire virtuelle sont à revoir (swapping, ...)
− les temporisateurs qui organisent le temps n’ont pas une résolution assez fine (pour
beaucoup d’applications temps réel)
− On ne dispose pas de moyens pour indiquer à l’OS le degré d’urgence d’une tâche
− le temps de réponse des événements externes n’est pas prévisible : le système
n’indique rien sur la durée de prise en compte d’une interruption
VII. Tâche
Un processus correspond à un fichier exécutable en cours d’exécution sur un processeur. Il est
entre autre 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 fonctionnement, un identifiant
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 fils 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.
Les tâches sont divisées en deux grandes catégories, en fonction de leur périodicité.
− Les tâches périodiques (ou cycliques) sont des tâches qui sont exécutées à intervalles
réguliers. Elles sont entre autre définies 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
configuration, 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.
1. Caractéristiques d’une tâche
− préemptible : tâche élue qui peut être arrêtée et remise à l’état prêt, pour allouer le
processeur à une autre tâche
3 4
− non préemptible : une fois élue, la tâche ne doit plus être interrompue jusqu’à la fin de
la requête (tâches atomiques, à exécution immédiate). Ex : tâche qui s’exécute sous le
contrôle d’une interruption
− tâches indépendantes : lorsqu’elles n’ont pas de relations de précédence, ni ne
partagent des ressources critiques
− tâches dépendantes :
o Par une relation de précédence statique : si elles agissent selon un ordre
prédéterminé, ou induit par la communication par messages ou par une relation
explicite de synchronisation. Elle est statique car connue a priori. On peut
construire le graphe de dépendance.
o Par une relation de précédence dynamique : si elles partagent des ressources
critiques (accès en exclusion mutuelle). La relation est dynamique car
l’utilisation de la ressource dépend de l’ordre d’exécution des tâches du Havre
- UFR ST - LITIS - Équipe STI Sy
2. Etats d’une tâche
− élue : un processeur est alloué à la tâche
− bloquée : la tâche attend une ressource, un message ou un signal de synchronisation
− prête (éligible) : la tâche attend d’être élue
− passive : la tâche n’a pas de requête en cours
− inexistante : la tâche n’est pas créée
VIII. Ordonnancements classiques des tâches
Il s’agit de déterminer quelle tâche prête doit être élue :
1. Premier arrivé, premier servi (les tâches de faible temps d’exécution sont
pénalisées si elles sont précédées dans la file par une tâche de longue durée)
2. Plus court d’abord : remédie à l’inconvénient précédent. Minimise le temps de
réponse moyen. Pénalise les travaux longs. Elle impose d’estimer les durées d’exécution des
tâches (connues difficilement).
3. Temps restant le plus court d’abord : la tâche en exécution restitue le processeur
lorsqu’une nouvelle tâche ayant un temps d’exécution inférieur à son temps d’exécution
restant devient prête.
4. Tourniquet (RoundRobin) : on définit un quantum de temps (10ms à
100ms). Chaque tâche de la file acquiert le processeur pendant au maximum un quantum de
temps, puis le cède à sa suivante dans la file, etc. ! Utilisée souvent dans les systèmes à temps
partagé. Ses performances dépendent du quantum de temps. Si trop grand : augmente les
temps de réponse, si trop petit : multiplication des commutations de contextes.
5. Priorités constantes : des priorités sont affectées aux tâches et à un instant donné, la
tâche élue est celle qui a la plus forte priorité. Les tâches de faible priorité peuvent ne pas
disposer du processeur (famine). Solution : faire “vieillir” la priorité des tâches en attente
(augmenter en fonction du temps d’attente). La priorité devient ainsi variable (et donc non
constante !)
Remarques
Aucune des politiques présentées ne permet de remplir les 2 objectifs d’un ordonnancement
temps réel.
Notamment : pas de prise en compte de l’urgence des tâches (délai critique)

Ordonnancement spécifique aux tâches temps réel
IX. Terminologie pour l’ordonnancement des tâches temps réel
Une tâche possède des paramètres chronologiques (délais) et chronométriques (dates). Les
paramètres de base d’une tâche sont :
− r : sa date de réveil, moment de déclenchement de la 1ere requête d’exécution
− C : sa durée maximale d’exécution (si elle dispose du processeur à elle seule)
− D : son délai critique (délai maximal acceptable pour son exécution)
− P : sa période (si tâche périodique)
− Si tâche à contraintes strictes : l’échéance d = r + D, est la date dont le dépassement
entraîne une faute temporelle.
− s : date de début d’exécution de la tâche
− f : date de fin 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
− L = D − C : sa laxité nominal. Indique le retard maximum que peut prendre la tâche
sans dépasser son échéance
− D(t) = d − t : son délais critique résiduel au temps t
− C(t) : sa durée d’exécution résiduelle au temps t
− L(t) = D(t) − C(t) : sa laxité résiduelle au temps t
− TR = f − r : son temps de réponse. L’échéance est respectée si tr <= D
Remarques
− T (r0, C, D, P) avec 0 ≤ C ≤ D ≤P
− r0 : date de réveil, C : durée max d’exécution, D : délai critique, P : période
− rk : date de réveil de la kème requête de la tâche.
− rk = r0 + k*P, représenté par ↑
5 6
− dk : échéance de la kème requête de la tâche.
− dk = rk + D, représentée par ↓
− tâche à échéance sur requête quand D = P, représentée par |
X. Algorithmes d’ordonnancement temps réel pour tâches périodiques
1. Rate Monotonic
L’algorithme Rate Monotonic est un algorithme statique, applicable à un ensemble de tâches à
échéance sur requête (l’échéance d’une tâche est égale à sa période), où les priorités des
tâches sont fixes et décidée avant le lancement du système.
La priorité des tâches est fixée en fonction de leur période d’activation. Plus une tâche a une
petite période d’activation, plus sa priorité sera haute. Il s’agit d’un algorithme préemptif,
l’activation d’une tâche de petite période devant permettre la préemption d’une tâche de
période plus grande. Cet algorithme est optimal dans le cas des priorités fixes
2. Deadline Monotonic
L’algorithme Rate Monotonic est basé sur l’hypothèse que les tâches sont à échéance sur
requête, c’est-à-dire que l’échéance d’une tâche est égale à sa période. Dans certains systèmes
cette hypothèse ne pourra s’avérer exacte, et les échéances pourront être plus petites que les
périodes. Dans ce cas, l’algorithme Deadline Monotonic est un algorithme optimal dans le cas
des algorithmes à priorité statique avec échéances plus petites que les périodes. Comme RM,
il est préemptif. La priorité d’une tâche est fixée par son échéance. Plus son échéance est
petite, plus sa priorité est grande.
3. Earliest Deadline First
L’algorithme Earliest Deadline First (EDF) donne la priorité à la tâche ayant l’échéance la
plus proche. A chaque fois qu’une tâche est réveillée, l’ordonnanceur réévalue les tâches
prêtes et sélectionne celle ayant l’échéance la plus courte. Cet algorithme est appliqué, ici, à
des tâches périodiques à échéance sur requête où la préemption est autorisée.
4. Least Laxity First
L’algorithme Least Laxity First (LLF) est, à l’instar d’EDF, un algorithme à priorité
dynamique. Il traite des tâches périodiques pour lesquelles la préemption est autorisée.
La règle décrivant l’algorithme est simplement que la tâche dont la laxité est la plus faible est
la plus prioritaire.
Les définitions suivantes permettent d’aborder la notion de laxité :
• L = D − C : sa laxité nominal. Indique le retard maximum que peut prendre la tâche sans
dépasser son échéance
• D(t) = d − t : son délais critique résiduel au temps t
• C(t) : sa durée d’exécution résiduelle au temps t
• L(t) = D(t) − C(t) : sa laxité résiduelle au temps t
XI. Système d’exploitation
Un système temps réel peut être mis en place via un système d’exploitation ou non. Sans
système d’exploitation, il est possible de disposer d’un exécutif (ou moniteur) temps réel, qui
est une sorte de micro-noyau. Cet exécutif est responsable de l’ordonnancement des tâches
(ordre dans lequel elles s’exécutent), les tâches s’occupant de leur traitement propre. Cette
solution peut être adaptée à des systèmes embarqués dont la fonctionnalité est très spécifique
et peu soumise à modification.
Dans des systèmes plus importants, il est agréable de disposer des facilités proposées par un
système d’exploitation, tels qu’une interface utilisateur ou la gestion de fichiers, par exemple.
Un système d’exploitation doit par contre être spécifiquement conçu pour le temps réel. Il est
en effet impossible de faire fonctionner une application temps réel strict sur un système
d’exploitation standard. Ceci est notamment en partie dû aux facteurs d’imprédictibilité cités
précédemment. Il existe plusieurs systèmes d’exploitation temps réel, propriétaires ou open
source.
Quelques de systèmes d’exploitation Temps réel (RTOS)
La norme POSIX (Portable Operating System Interface) définit l’ensemble des services et des
primitives que doit offrir un système d’exploitation dit ouvert pour permettre l’écriture
d’applications portables entre systèmes Unix et même entre des systèmes Unix et d’autres
systèmes.
XII. Exécutifs temps-réel (ETR)
L’exécutif temps réel constitue le support d’exécution des taches de l’application temps réel.
Un exécutif temps réel est l'extension d'un noyau de base. Ce noyau temps réel est la base
minimale du système d'exploitation et gère les tâches et l'interconnexion de ces tâches (multi-
tâches).
Bien que la taille du noyau varie selon les systèmes, souvent celle-ci est réduite à une dizaine
de kilo-octets.
Ainsi, l'exécutif est appelé lors d'un événement, en fonction de l'évolution du temps, ou
encore par des tâches nécessitant un service de l'exécutif.
7 8
Un Exécutif temps réel est un moniteur temps réel (par exemple, RTEMS ou eCos) :
− Il est recompilé avec l'application, se présente sous forme d’une bibliothèque, « linkée
» avec l'application. On recharge l’ensemble [application + système] à chaque fois
qu’on relance l’application.
− Il est de très petite taille, parce que modulable en fonction de l’application.
− gestion mémoire très simple donc efficace en termes de temps.
− pas d'interface utilisateur, le couple écran/clavier n’est plus le périphérique privilégié.
Services d’un ETR:
− un service de gestion des taches qui assure l’ordonnancement sur le processeur et
également toutes les opérations de création, activation, suspension, terminaison des
tâches.
− un service de gestion des interruptions,
− un service de gestion des entrées-sorties
− un service de gestion des exceptions et de reprise d’erreurs
− un service d’outils de communication entre les taches et de synchronisation pour
l’accès aux ressources.
− un service de gestion du temps dont la précision soit compatible avec les exigences
temporelles des applications temps réel.
Exemples
Les exécutifs temps réel du marché peuvent être classés en deux catégories :
− les exécutifs temps réel dérivés du système Unix. Ce sont des exécutifs qui ont été
réalisés par le biais d’une adaptation du système classique Unix et offrent une
interface POSIX. Citons par exemple QNX de QNX Software Systems, LynxOS de
LynuxWorks et bien sûr RTLinux et les autres Linux temps réel ;
− les exécutifs temps réels natifs. Ce sont des exécutifs qui ont été conçus dès le départ
spécifiquement pour le temps réel. Citons par exemple VxWorks de Wind River
Systems.
− Par ailleurs, certains exécutifs présentent des versions dites embarquées. Le noyau est
alors réduit à un ensemble de services minimum de manière à être suffisamment
compact pour être chargé dans une mémoire de petite capacité.
XIII. Langages de programmation utilisés en TR
Plusieurs langages de programmation sont TR natif. Comme par exemple :
− Ada (choix par le gouvernement Américain)
− Pearl (Process and Experiment Automation Real-time Language)
− Occam (transputers)
− Euclid (expérimental)
Cependant d’autres langages nécessitent un certain additif pour qu’ils puissent traiter le temps
réel. Par exemple : C, C++, Java