Cours Temps Rel

TABLE DES MATIERES

I . Introduction aux Systmes Temps Rel

1
2
3
4
4
4
4
4
4
4
4
4

.
.
.
.
.
.
.
.
.
.
.
.

Dfinition du Temps Rel

Caractristiques des STR
Domaine d'applications
Notions de base
1 . Temps de rponse
2 . Le dterminisme
3 . La premption
4 . Les interruptions
5 . Le multitche
6 . Tches priodiques et apriodiques
7 . Horloge temps rel
7 . Caractristiques et performances temporelles

II . Prsentation de LynxOs
1 . LynxOs et Lynx RTS
2 . LynxOs : un noyau temps rel nouveau
3 . LynxOs et POSIX
III . Prsentation de RTAI - Linux
1 . Introduction
2 . Architecture RTAI
3 . Caractristiques
IV . Exercices
1 . Ordonnancement
2 . Niveau de priorit et temps de rponse
3 . Dterminisme et temps rel

LT LA SALLE

Page 1 / 22

TV.BTSii.2001

Cours Temps Rel

I . Introduction aux Systmes Temps Rel

1 . Dfinitions du Temps Rel
L'introduction du multitche avec la technique de partage du temps (time-sharing) date
de 1967. La premire apparition du terme temps rel se situe en 1970 et concide avec
lapparition des microprocesseurs dans lenvironnement industriel.
Un systme fonctionne en Temps Rel sil est capable dabsorber toutes les
informations en entre avant quelles soient trop vielles pour lintrt quelles
prsentent et de ragir celles-ci suffisamment vite pour que cette raction est
un sens
(ABRIAL BOURGNE).
Un rsultat juste, mais hors dlai, est un rsultat faux .
Les systmes temps rel (hard real time) ne peuvent en aucun cas tolrer une rponse
tardive, les consquences d'une telle rponse peuvent tre catastrophiques (ex : systme
de pilotage automatique d'avion).

2 . Caractristiques des Systmes Temps Rel

Pour commander un environnement industriel, il faudra respecter les contraintes de
temps.
Le temps dexcution dune tche doit tre connu et non soumis des variations lies
la charge du systme.
Au niveau matriel, la dcomposition la plus courante est la suivante :

Oprateu
r

Infos

Messages

STR
C

A
Donnes / Event
(IT)

Processus
Infos Signal

Action
Signal

De nos jours, un calculateur embarqu signifie implicitement calculateur temps rel

embarqu.

LT LA SALLE

Page 2 / 22

TV.BTSii.2001

Cours Temps Rel

Au niveau logiciel, on distingue : lexcutif Temps Rel (le noyau) et lapplication Temps
Rel (les tches).
tche
s
LANGAGE TR
Gestion
IT

Attrib.
UC

Synchro

MATERIEL

Exemples dOS Temps Rel :

LynxOs, OS9, MTR86, RT- RTAI LINUX, pSOS, VRTX,

3 . Domaines d'application
systme de commande et de contrle de processus industriels ;
systme de contrle ariens ;
systmes embarqus dans les avions, navettes spatiales, fuses ;
gestion des stations spatiales ;
systme de dfense ;
surveillance mdicale intensive ;
coordination des collectivits mixtes robots-humains ;
gestion automatique du trafic et du transport urbain ;
le multimdia ;
les systmes de tlcommunication,
... etc ...

LT LA SALLE

Page 3 / 22

TV.BTSii.2001

Cours Temps Rel

4 . Notions de base
4 . 1 . Temps de rponse
Pour fournir une rponse, un systme doit reconnatre, traiter et sortir un rsultat. Le
temps de rponse TR est le suivant :

TR = Tcalcul + TE/S
L'apparition d'un phnomne implique l'excution d'une action effective au plus tard dans
un dlai TR appel temps de rponse. Il convient de considrer :
les valeurs ou les ordres de grandeur de TR ;
la possibilit ou non de choisir TR ;
les rpercussions sur le systme du non respect de la contrainte T R.
Il faut relativiser la notion temps rel car tous les systmes n'ont pas les mmes
exigences. Le temps de rponse des STR peut aller de quelques dizaines de s pour les
systmes radars quelques heures pour des systmes de surveillance de ractions
chimiques (voire plusieurs annes dans des systmes utiliss en astronomie).
Il existe globalement deux situations :
les systmes transactionnels o l'on a une tolrance statistique (pour le non
respect des contraintes de temps) ;
la commande de processus o les respect d'un dlai de rponse TR doit tre garanti
dans tous les cas sous peine de voir une dgradation ou un effondrement du systme.
4 . 2 . Le dterminisme
Un systme sera dit "dterministe" lorsque le temps maximal qu'il mettra pour traiter
une tche quelconque sera connu et dtermin l'avance.
Il convient de considrer les diffrents niveaux constituant le systme :
au niveau processeur : le dterminisme est total.
au niveau de l'excutif : il sera dterministe si son temps de rponse est
indpendant de sa charge.
au niveau du systme : il sera dterministe s'il est capable de rpondre une
requte et la traiter en un temps maximum indpendant de l'environnement
extrieur.
4 . 3 . La premption
La premption est un des outils mis en uvre pour assurer l'aspect dterministe d'un
systme. La premption se dfinit comme la rquisition du processeur pour
l'excution d'une tche et d'une seule pendant un temps dtermin.

LT LA SALLE

Page 4 / 22

TV.BTSii.2001

Cours Temps Rel

Un ordonnancement statique base de priorits peut se drouler de deux faons

distinctes :
ordonnancement sans premption : lorsque le processeur est inactif, la tche prte
de plus haute priorit sera choisie pour tre excute. Une fois choisie, elle s'excute
jusqu' ce qu'elle soit termine.
ordonnancement avec premption : lorsque le processeur est inactif, la tche prte
de plus haute priorit sera choisie pour tre excute. A chaque instant cette tche
peut tre prempte (remplace) par n'importe quelle tche plus prioritaire qui
serait devenue prte.
Dans les systmes temps rel, il existe une convention qui consiste prendre la valeur 0
comme tant la priorit absolue. Donc, une tche de priorit 1 est plus prioritaire (plus
urgente) qu'une tche de priorit 2, ...
La premption intervient au niveau processeur.
4 . 4 . Les interruptions
Une IT est provoque par la validation dune ligne nomme gnralement IRQ (Interrupt
ReQuest).
Le traitement gnral dune IT :
-

fin du traitement en cours

prise en compte de lIT
traitement de lIT
retour au traitement interrompu.

La gestion des IT est une caractristique essentielle dun excutif TR.

Le masquage des interruptions est un autre moyen propre assurer un certain
dterminisme et intervient au niveau processeur. Ce moyen est donc totalement
indpendant de la premption.
On distingue alors :
Dans un ordonnancement non premptif, les interruptions ne sont pas masques.
Par contre, lors du masquage des IT, le systme est, par la force des choses, dans un
mode non premptif.
Le masquage des IT peut tre provoque de deux manires :
soit par l'arrive d'une IT o le masquage est ralis par le processeur lui-mme.
soit la demande de l'excutif, auquel cas il s'agit d'une section de code
critique (souvent rduite quelques instructions)..

LT LA SALLE

Page 5 / 22

TV.BTSii.2001

Cours Temps Rel

4 . 5 . Le multitche (voir cours "programmation systme sous Unix")

Un excutif temps rel reprend tout ce qui caractrise un systme multitche :
excution concurrente de tches ;
synchronisation et communication entre tches, ... etc ...
La qualification "temps rel" n'implique pas forcment l'ajout de fonctionnalits
logicielles supplmentaires par rapport un systme multitche, mais plutt l'adoption
de stratgies diffrentes : le dterminisme et la premption.
4 . 6 . Tches priodiques et apriodiques
Une tche priodique peut donc tre excute une fois par priode T et elle peut tre
synchrone avec une horloge temps rel. Une tche priodique sera hors-dlai si sa
priodicit n'est pas respecte.
Une tche apriodique est en gnral associe un vnement asynchrone (une
interruption) et doit tre traite dans un dlai maximum ne pas dpasser.
4 . 7 . Horloge temps rel
L'horloge temps rel est utilise prcisment pour :
dclencher priodiquement des tches quand celles-ci ont t mises en place ;
grer le temps partag entre les tches (round robin) ;
connatre le temps coul depuis une certaine action ;
grer les timeout des primitives RT.
A chaque TIC de l'horloge, l'ordonnanceur est invoqu, il appelle une tche horloge de
plus haute priorit qui effectue les actions suivantes :
dcrmentation d'une unit compteur pour chaque tche suspendue sur un
timeout
mise en file des tches prtes si le compteur de la tche est arrive zro
lancement des tches attaches un mode priodiques
La notion de temps peut tre exprime en TIC d'horloge (ou ventuellement en ns).
4 . 8 . Caractristiques et performances temporelles d'un noyau temps rel
Pour rduire les surcharges de fonctionnement et afin d'acclrer le systme, le noyau
d'un STR doit avoir les caractristiques suivantes :
une rapide commutation de contexte ;
une petite taille (avec des fonctionnalits minimales) ;

LT LA SALLE

Page 6 / 22

TV.BTSii.2001

Cours Temps Rel

temps de rponse rapide aux interruptions ;

un temps rduit o les IT sont inhibes ;
grer les partitions de mmoire (pas de mmoire virtuelles) ;
avoir la possibilit de verrouiller dans la mmoire des donnes ou du code ;
Afin de satisfaire les exigences de temps, le noyau doit :
disposer d'une horloge temps rel ;
tre dot d'un ordonnanceur de tches par priorit ;
disposer des fonctions de blocage de tches sur un dlai et de dblocage la fin
du dlai (temporisation) ;
En gnral, le noyau intgre :
le multitche
la communication et synchronisation inter tches (smaphores, etc ...).
Les performances temporelles d'un RTOS dpendent videmment des performances
du RTOS lui mme mais aussi de la plate-forme matrielle sur lequel il fonctionne et des
procdures de tests et de mesures (trs difficile raliser ce qui implique qu'il est
toujours trs difficile de comparer deux RTOS).
On retrouve gnralement les deux critres suivants :
la rponse une interruption : correspond l'intervalle de temps entre l'instant
d'arrive de l'IT et l'atteinte de la premire instruction de la routine de traitement
de l'IT;
la commutation de tche : correspond au temps mis par l'ordonnanceur pour
choisir la tche active de plus haute priorit en ensuite effectuer le remplacement
du contexte de la tche courante par celui de la nouvelle tche.
D'autres facteurs temps influent galement sur les performances de l'excutif :
temps maximum de masquage des IT dans l'excution des primitives
(temps de latence) ;
temps de rarmement. d'une interruption ;
temps d'excution de certaines primitives.
Il convient de noter qu'un excutif temps rel n'est pas seulement caractris par son
aspect dterministe mais aussi par ses outils de dveloppement, des librairies, de la
portabilit, ...

LT LA SALLE

Page 7 / 22

TV.BTSii.2001

Cours Temps Rel

Il faut tout de mme considrer que les performances d'un STR ou d'une application
temps rel sont souvent inversement proportionnelles leur convivialit et leur
portabilit.

II . Prsentation de LynxOs
(d'aprs une documentation Lynx)
1 . LynxOS et LYNX RTS
Lynx RTS, install San Jos en Californie, au coeur de la Silicon Valley, est une socit
dont le dmarrage a pris vritablement son envol grce au projet de la Station Freedom
de la NASA. L'ensemble du projet reprsente 500 600 systmes, tant en systmes
embarqus qu'en systmes de dveloppement ou stations au sol...
Produit et socit voient le jour, au Texas, en 1985, avec comme objectif la conception
d'un systme d'exploitation Temps Rel qui soit utilisable sur de nombreuses platesformes offrant des performances Temps Rel de Haut Niveau et disposant d'un
environnement de dveloppement confortable. Ceci permettait dj l'poque,
d'envisager dveloppement et exploitation sur le mme systme. Le cur du systme
dvelopp tait dj constitu d'un noyau Temps Rel, et l'environnement de
dveloppement, d'outils proches du concept UNIX, avec comme objectifs :

Dlivrer des performances Temps Rel de trs haut niveau.

Disposer d'une offre multi plates-formes la plus large possible.
Etre conforme aux spcifications POSIX.

Aujourd'hui LynxOS est un systme Temps Rel compatible aux standards UNIX et POSIX
1003.1a, 1003.1b et 1003.1c ( ISO9945-1).
2 . LynxOS : UN NOYAU TEMPS REEL ENTIEREMENT NOUVEAU
Lynx Real-Time Systems, Inc, livre depuis Mars 1997 LynxOS version 2.5.0 qui est le
premier systme d'exploitation Temps Rel intgrer l'ensemble des extensions Temps
Rel dcrites dans la norme ISO9945. La norme POSIX offre pour la premire fois la
probabilit d'une application Temps Rel pouvant s'excuter sur n'importe quelle plateforme conforme cette norme.
LynxOS est un systme multitche offrant un temps de rponse garanti mme
en prsence d'interruptions gnres par de multiples units. Il dispose de 256
niveaux de priorits, d'un noyau 100% premptif et est disponible sur la plupart
des processeurs du commerce.
LynxOS est certifi POSIX 1003.1 et comporte les extensions temps Rel
dfinies dans le standard POSIX.lb et POSIX.1c pour les threads, LynxOS est
compatible avec AT&T UNIX V3.2 et UNIX BSD 4.3.
En matire de communication, LynxOS offre en standard TCP/IP, NFS, STREAMS
et SNMP ainsi que les interfaces graphiques populaires XWINDOW et MOTIF.
LynxOS permet le dveloppement d applications temps Rel en excluant l'usage d'appels
systmes propritaires non standards. Sa compacit (250k octet en ROM avec un

LT LA SALLE

Page 8 / 22

TV.BTSii.2001

Cours Temps Rel

systme de fichiers) permet l'utilisation de LynxOS pour des applications embarques l

ou l'usage d'un disque ou d'un rseau est impossible.

LT LA SALLE

Page 9 / 22

TV.BTSii.2001

Cours Temps Rel

LynxOS est disponible sur la plupart des processeurs et systmes et est "Romable" afin
de permettre son "embarquement" sur systmes devant oprer dans des conditions
extrmes, qu'il est multi plates-formes puisqu'il est disponible sur un grand nombre de
matriels :
Intel 386/486/Pentium, Motorola 68030/68040/68060, microSPARC1 et microSPARC2
PowerPc 601/603/604 et sur de nombreuses cartes VME et systmes du commerce.
L'usage d'un porting kit permet l'utilisation de LynxOS sur n'importe quel type
d'architecture utilisant l'un des processeurs cits ci-dessus.
La chane des outils GNU, aujourd'hui une rfrence dans l'industrie, comporte les
compilateurs gcc et g++ ainsi qu'une version tendue du "debugger" gdb permettant la
mise au point d'applications multi-threads.
Documentation, prix et services : cfi@saem-ales.fr
Plus dinformations : www.lynx.com
3 . LynxOS et POSIX
LynxOS, conforme POSIX : Les extensions Temps Rel dveloppes par le groupe de
travail P1003.1b dfinissent une interface standard pour utiliser les mcanismes
couramment utiliss dans des applications Temps Rel. Pour chacun de ces mcanismes,
le standard spcifie la syntaxe et la smantique d'un ensemble de fonctions devant tre
supportes afin d'tre conformes. Ces recommandations ne prcisent pas la manire
d'implmenter les mcanismes mais allant au-del de POSIX, spcifie des chelles de
performances.
LynxOS supporte la totalit des extensions POSIX 1003.1b :
Smaphores, mcanismes de synchronisation entre plusieurs "process" partageant
une ressource commune.
Memory Locking, permet un process de stopper le systme de mmoire virtuelle et
d'interdire de "swapper out" une partie critique du "process" de faon lui permettre de
rpondre immdiatement toute sollicitation.
Shared Memory, permet le partage d'un mme espace mmoire entre plusieurs
"process".
Priority Scheduling, offre un mcanisme d'administration des tches sur une base
dterministe et base sur la notion de priorit, il permet la mise en oeuvre de plusieurs
mcanismes d'administration incluant FIFO et ROUND ROBIN.
RealTime Signals, mcanisme fiable et efficace permettant plusieurs fonctions Temps
Rel de notifier un "process" l'apparition d'un vnement asynchrone tel que
l'expiration d'un timer, la fin d'une Entre/Sortie ou l'arrive d'un message.
Timers, qui vont au-del du timer UNIX afin de supporter une plus grande rsolution
(exprim en nanoseconde), et ce sur plusieurs timers, en temps absolu ou relatif.
Message queues, supportent la communication d'une taille quelconque de donnes
entre plusieurs "process", et ce de faon fiable et particulirement efficace.
LT LA SALLE

Page 10 / 22

TV.BTSii.2001

Cours Temps Rel

Asynchronous I/O, permet un process d'initialiser de multiples Entres/Sorties sans

avoir attendre la fin de celles-ci.
Synchronized I/O, permet de garantir qu'une Entre/Sortie a bien t physiquement
ralise. Ceci est un lment essentiel dans le cas d'application mettant en jeu une base
de donnes partage par plusieurs utilisateurs.
Les "Threads" Ada POSIX 1003.1c et LynxOS :
La notion de "tche lgre" est trs intressante dans le cadre d'application
temps Rel, car elle permet la mise en oeuvre de mcanismes plus performants
pour l'excution concurrente de plusieurs activits. Les "threads" d'un
"process" partagent le mme espace adresse, les mmes ressources que le
"process" et est gnral manipulent moins d'information de contexte que le
"process" lui-mme. Ils sont donc plus performants car prenant moins de
ressource unit centrale et mmoire pour la cration, la fin et le basculement
entre "threads".
0utre l'norme avantage qu'offre les "threads" pour exploiter le paralllisme de certaines
architectures de machines, ils procurent une approche toute nouvelle pour prendre en
compte le "multi-tasking" de Ada et deviennent des "citoyens de premire classe pour le
noyau" LynxOS (!!!).

III . Prsentation de RTAI - Linux

(d'aprs un article de Linux+ mai 2000)
Le terme temps rel peut prendre des significations trs diffrentes, dpendant de
laudience et de la nature de lapplication en question. Cependant, la littrature
informatique dfinit gnralement uniquement deux types :
des systmes temps rel soft et hard.
Un systme temps rel soft se caractrise par la possibilit daccomplir une tche qui,
en moyenne, est excute selon un planning prdtermin. Laffichage vido est un bon
exemple, o la perte occasionnelle de frames ne causera pas de dgradation perceptible
du systme, dlivrant une performance moyenne demeurant acceptable. Bien que des
techniques comme linterpolation puissent tre employes pour compenser les frames
manquants, le systme demeure temps rel soft , car les donnes relles sont
manquantes et les frames issus de linterpolation sont des drivs et non les donnes
relles.
Lincorporation de temps rel hard garantit le timing, ne peut pas manquer les dlais
limites et doit avoir des temps de latence lis. Comme les deadlines ne sont jamais
manqus, un systme temps rel hard ne peut pas utiliser le cas moyen des
performances pour compenser le pire. Un exemple de systme temps rel hard est fourni
par la gestion des transducteurs dun racteur nuclaire, lequel doit utiliser un systme
de contrle numrique complexe, afin dviter les dsastres.

LT LA SALLE

Page 11 / 22

TV.BTSii.2001

Cours Temps Rel

1 . Introduction
Dans le but de rendre Linux utilisable dans des applications temps rel pures, les
membres du dpartement dingnierie spatiale de lInstitut Polytechnique de Milan
(DIAPM) ont envisag une couche d'abstraction matrielle temps rel (RTHAL : Real
Time Abstraction Layer) sur laquelle une interface pour les applications temps rel
(RTAI) pourrait tre charge.
Vers 1996, un groupe de chercheurs du New Mexico Institute Technology (NMT) prsenta
Linux Temps Rel (RT Linux), ce qui permit l'quipe de DIAPM dapprofondir son tude
du noyau Linux, du matriel et des modifications ncessaires pour fournir une
planification premptive et dterministe. Une nouvelle tape fut franchie en 1998 avec
les amliorations importantes du noyau 2.2, notamment les modifications darchitecture
dans linterfaage de Linux avec le matriel. Ces modifications, combines avec
lexprience acquise par lquipe DIAPM lorsquelle travaillait sur sa propre volution du
noyau Linux NMT-RT, et les concepts de 1996, aboutirent RTAI.
RTAI fournit une planification temps rel pure, tout en conservant toutes les fonctions et
services de Linux Standard. En plus, RTAI fournit le support de UP et SMP (avec la
possibilit dassigner les tches et les IRQs des CPU spcifiques), x486 et Pentium, des
schedulers one-shot et priodiques, la mmoire partage inter-linux ou intra-linux, la
compatibilit POSIX, le support de FPU, la synchronisation inter-tches, des smaphores,
mutexs, message queues, messages, la possibilit dutiliser les appels systmes RTAI
lintrieur de l'espace utilisateur standard et ...
2 . Larchitecture RTAI
Larchitecture de RT Linux et RTAI est sensiblement similaire.
Pour chaque implmentation, le systme dexploitation Linux est excut comme la tche
plus faible priorit du systme dexploitation temps. En consquence, Linux ne
rencontre pas de changement fonctionnel du point de vue de lutilisateur ou du noyau
Linux, except le fait que son excution est permise simplement quand il nexiste pas de
tches temps rel en cours dexcution.
Fonctionnellement, les deux architectures offrent la possibilit dexcuter des tches
temps rel spciales et des gestionnaires dinterruption qui sexcutent la demande,
indpendamment des autres tches que Linux pourrait faire fonctionner.
Les deux implmentations tendent lenvironnement de programmation standard de
Linux aux problmes du temps rel en autorisant que les tches temps rel et les
gestionnaires dinterruption communiquent avec les traitements Linux au travers dune
interface de priphrique (FIFOS) ou de mmoire partage.
La diffrence primaire darchitecture entre les deux implmentations rside dans la
manire dont les fonctions temps rel sont ajoutes Linux. RT Linux et RTAI tirent tous
deux parti des modules tlchargeables lors de limplmentation des services temps rel.
Cependant, une des diffrences cls entre les deux rside dans la manire dajouter les
extensions temps rel au noyau standard de Linux.
RT Linux applique la plupart des changements directement aux fichiers sources du noyau,
avec pour rsultat des modifications et des additions dans de nombreux fichiers source
Linux. En consquence, il accrot lintrusion dans les fichiers source Linux, ce qui peut
LT LA SALLE

Page 12 / 22

TV.BTSii.2001

Cours Temps Rel

entraner une maintenance accrue du code. Il rend galement plus difficile le traage des
modifications et mises jour du noyau ainsi que la recherche de bogues.
RTAI limite les changements du noyau standard en ajoutant une couche d'abstraction
matrielle (HAL) comprenant une structure de pointeurs vers les vecteurs dinterruption,
ainsi que les fonctions dactivation/dsactivation des interruptions. HAL est implment
en modifiant moins de 20 lignes du code existant, et en ajoutant environ 50 lignes de
nouveau code. Cette approche minimise lintrusion dans le code standard de Linux et
localise la gestion dinterruption et le code dmulation, ce qui constitue une approche
beaucoup plus lgante.
Un autre avantage de la technique HAL est quil est possible de faire revenir Linux dans
son mode de fonctionnement standard en changeant les pointeurs dans la structure
RTHAL et en leur redonnant leurs valeurs originales. Ceci savre utile lorsque les
oprations temps rel sont inactives ou lorsque lon cherche reprer des bogues.
L'impact de HAL sur les performances du noyau est ngligeable, refltant grandement la
maturit et la conception du noyau Linux et de ceux qui ont contribu son
dveloppement.
HAL supporte cinq modules tlchargeables qui apportent les capacits temps rel
requises la demande :
rtai, lenvironnement de travail de base ;
rtai_sched, la planification priodique ou one-shot ;
rtai_mups, planification priodiques ou one-shot simultans ou encore deux
planificateurs priodiques, chacun travaillant sur une horloge diffrente ;
rtai_shm, partage de mmoire inter-linux, entre les tches temps rel et les
traitements Linux, et galement intra-Linux comme remplacement de UNIX V IPC ;
et rtai_fifos, une adaptation du FIFO (Files In, Files Out) de NMT de RTLinux.
Comme tous les modules du noyau, ils peuvent tre chargs ou dchargs ( laide des
commandes standard Linux insmod et rmmod) mesure que leurs possibilits
respectives sont requises ou non.
Par exemple, si vous souhaitez installer uniquement les gestionnaires dinterruption, vous
devez charger le module rtai. Si vous voulez galement communiquer avec les
traitements standards de Linux en utilisant FIFO, alors vous devrez charger les modules
rtai et rtai_fifos.
Cette architecture modulaire et non intruse permet FIFO de sexcuter sur nimporte
quelle queue et dutiliser les rveils immdiats lorsque ncessaire.
3 . Caractristiques
La tche temps rel est implmente de faon similaire RTAI. Elle est crite et compile
comme un module du noyau, charg dans le noyau aprs, que le ou les modules RTAI
requis aient t chargs.

LT LA SALLE

Page 13 / 22

TV.BTSii.2001

Cours Temps Rel

Planificateur de tches
Le planificateur de tches de RTAI permet la planification entirement premptive, temps
rel hard base sur un schma de priorit fixe. Tous les plans peuvent tre grs par
des fonctions de temps ou des vnements temps rel comme : lacquisition de
smaphores, les fonctions dhorloge ou de temps, les gestionnaires dvnements
asynchrones ... et comprennent la synchronisation inter-tches.
Planification priodique et one-shot
RTAI supporte la foi les timers priodiques ou one-shot sur des CPU de type 486 ou
Pentium. Bien que des timers priodiques ou one-shot soient tous deux supports, ils ne
peuvent tre instancis de manire simultane. Les tches one-shot et priodiques ne
peuvent tre charges dans le noyau comme modules au mme moment.
En utilisant ces timers (instancis par rtai_sched), les taux priodiques en dpassement
de 90 KHz sont supports, ceci dpendant : de la CPU, la vitesse du bus et la
performance de la puce.
Sur les processeurs Pentium, les taux de tches one-shot en dpassement de 30 KHz
sont supports (Pentium II 233 MHz), et sur des machines 486, limplmentation
one-shot offre des taux de lordre de 10 KHz, tout en conservant suffisamment de temps
CPU pour servir le noyau standard Linux.
La limitation de rtai_sched supporter simultanment des timers priodiques et one-shot
est mitige par le planificateur temps rel rtai_mups : Multi Uni Processor (MUP), qui
offre la possibilit simultane : des deux types de timers ou encore deux timers
priodiques avec des priodes diffrentes, une performance quivalente celles
rencontre avec rtai_sched. Il faut noter que, comme le MUP utilise le timer APIC
(Advanced Programmable Interrupt Controller), il ne peut oprer sous SMP et requiert
que chaque tche planifie pour MUP soit bloque dans une CPU spcifique (do
lappellation Multi Uni Processor) ; cependant, MUP conserve toute la coordination et les
services IPX, en consquence de quoi aucune des autres capacits nest perdue.
Opration en virgule flottante
Les oprations en virgule flottante lintrieur des tches/ISR (Interrupt Service
Routines) temps rel sont possibles, elles sont marques, lors du chargement, comme
des tches requrant la FPU. Cette mthode fournit laccs des tches temps rel au FPU
tout en permettant laccs FPU aux tches standards de Linux.
Gestion des interruptions
RTAI propose un accs immdiat et efficace au matriel en autorisant, si lon choisit cette
option, une interaction directe avec le matriel bas niveau du PC, sans passer en premier
lieu au travers des couches de gestion des interruptions du noyau standard de Linux. La
possibilit dassigner de manire individuelle des IRQ spcifiques des CPU spcifiques,
garantit un interfaage immdiat avec le matriel.
Communications inter-process
Le terme communication inter-process (IPC) dcrit diffrents moyens de passer des
messages entre les traitements ou tches, et dcrit galement les multiples formes de
synchronisation pour le transfert des donnes.
LT LA SALLE

Page 14 / 22

TV.BTSii.2001

Cours Temps Rel

Linux fournit un IPC standard Systme V sous la forme de mmoire partage, FIFOs,
smaphores, mutexes, variables conditionnelles et pipes qui peuvent tre utilises par les
traitements utilisateurs standards pour transfrer et partager les donnes. Bien que ces
mcanismes IPC Linux ne soient pas disponibles pour accomplir des tches temps rel,
RTAI fournit un jeu supplmentaire de mcanismes IPC qui comprennent la mmoire
partage, les files de messages, les FIFO temps rel, mutexes, smaphores et variables
conditionnelles. Ces instructions sont utilises pour transfrer et partager les donnes
entre les tches et les traitements la fois dans les domaines Linux temps rel et
lespace utilisateur.
Le mcanisme dappel de procdures distantes (RPC) de RTAI est similaire en
fonctionnement aux messages QNX disponibles aux tches temps rel et les transfrent
soit sous la forme dun int non sign soit sous la forme dun pointeur vers la tche de
destination.
Limplmentation de la bote de messagerie de RTAI offre la possibilit denvoyer
nimporte quel message depuis lespace utilisateur vers les tches temps rel, et tches
utilisateur vers tches utilisateur (en utilisant LXRT) via nimporte quelle taille de buffer
de bote de messagerie pouvant tre dfinie. De multiples expditeurs et rcepteurs sont
autoriss, pour lequel chacun est servi en fonction de ses priorits.
Interface proc
Depuis la version 0.9, RTAI comprend une interface proc qui fournit des informations
utiles sur le statut courant de RTAI, y compris les planificateurs chargs, les activits
temps rel, la priorit et la priode, et les FIFO en utilisation avec leurs tailles de buffer
associes. On peut visualiser l'cran avec la commande cat les fichiers suivants :
/proc/rtai/scheduler
/proc/rtai/rtai
/proc/rtai/fifos
...
Support SMP
RTAI fournit un vritable support de larchitecture SMP (Symmetric Multi-Processing) au
travers de sa gestion des tches et des IRQ. Par dfaut, toutes les tches sont assignes
pour fonctionner sur nimporte quelle CPU (dune plate-forme SMP). Chaque tche,
cependant, peut tre individuellement assigne nimporte quel sous-ensemble CPU,
voire une simple CPU. En plus, il est possible dassigner nimporte quel service
dinterruption temps rel nimporte quelle CPU spcifique. Parce que la possibilit de
forcer une interruption vers une CPU spcifique nest pas lie au planificateur SMP, RTAI
conserve la souplesse deffectuer ces deux oprations de faon indpendante.
Ces capacits fournissent une mthode pour optimiser lapplication temps rel, si la
distribution manuelle des tches gre la tche de faon plus efficace que les services de
distribution automatique SMP fournis par Linux.
LXRT
Comme les tches temps rel de Linux sont implmentes comme des modules
tlchargeables, elles sont parties intgrantes du noyau. Ainsi, ces tches ne sont pas
lies aux services de protection de la mmoire de Linux et elles ont la possibilit dcrire
par dessus les zones critiques de la mmoire, qui peuvent provoquer une interruption du
LT LA SALLE

Page 15 / 22

TV.BTSii.2001

Cours Temps Rel

systme. Cette limitation sest avre trs frustrante pour ceux dentre nous qui ont err
durant le dveloppement de tches temps rel.
LXRT de RTAI rsout ce problme en autorisant le dveloppement de tches temps rel,
utilisant tous les appels systmes temps rel hard de RTAI lintrieur de lespace
mmoire protg de Linux et sous un service temps rel firm . Lorsque le
dveloppeur est satisfait des performances dune tche au sein de LXRT, la tche est
simplement recompile comme un module et insre dans le noyau (avec les modules
associs qui fournissent les fonctions temps rel de RTAI) afin deffectuer la transition. Le
service temps rel de LXRT, similaire au patch temps rel propos par luniversit du
Kansas (KURT) fournit du temps rel soft.
Les performances sous LXRT sont plutt bonnes, produisant des dlais de latence pas
plus importants que pour un appel systme standard Linux destin basculer une tche.
Bien quil sagisse dun outil de valeur pour les dveloppements, nous ne devons pas
perdre de vue le fait que limplmentation temps rel firm de RTAI peut savrer
particulirement utile pour des tches qui ne requirent pas le temps rel hard, mais ne
sont pas encore accomplies par Linux standard.
API de compatibilit POSIX
RTAI implmente un sous-ensemble compatible de POSIX 1003.1.c au travers dun seul
module tlchargeable. Ces appels supportent la cration et la suppression, le contrle
dattributs, le contrle denvironnement pour les threads, mutexes et variables
conditionnelles. Le support POSIX rsultant est similaire celui offert pour les threads
Linux Standard (librairie pthread).
Performances
Les performances d'un RTOS dpendant videmment des performances du RTOS lui
mme mais aussi de la plateforme matrielle sur lequel il fonctionne et des procdures
de tests et de mesures (trs difficile raliser ce qui implique qu'il est toujours trs
difficile de comparer deux RTOS).
Les chiffres ci-dessous ont t obtenus sur un Pentium II 233 Mhz avec un Linux
lourdement charg :
Taux d'itration priodique maximum : 125 KHz
Jittler au taux maximum d'itration :
0-13 s (UP)
Taux d'interruption one-shot :
30 KHz
Temps de changement de contexte :
environ 4 s
Sites
RTAI :
Linux temps rel :
Ethernet IP RTnet :

www.rtai.org
RT Linux :
www.realtimelinux.org
Trace Toolkit :
opensource.lineo.com/rtai.html

www.rtlinux.org
www.opersys.com

Un excellent site sur les systmes embarqus et les diffrents RTOS existants :
www.enseirb.fr/~kadionik/embedded/embedded.html
On trouvera sur le site RTAI des liens vers le support de cartes d'acquisition avec l'API
COMEDI et l'API rt_com pour les liaisons sries.
LT LA SALLE

Page 16 / 22

TV.BTSii.2001

Cours Temps Rel

IV . Exercices
1 . Soit le programme temps rel avec les 3 tches dfinies dans le tableau suivant :
Tches
T1
T2
T3

Priorit
1
2
3

Priode
7
16
31

Temps de calcul
2
4
7

Nous supposons que le dlai pour chaque tche est gal sa priode.
On se limitera une quarantaine de priodes.
a . Dans le cas d'un ordonnancement base de priorit sans premption, donner le
diagramme de temps correspondant et indiquer si toutes les tches s'excutent "en
dlai".
T1
t
T2
t
T3
t
1

10

14

15

16

20

21

25

28

30

31

32

35

38

b . Mme question dans le cas d'un ordonnancement base priorit avec premption.
T1
t
T2
t
T3
t
1

10

14

15

16

20

21

25

28

30

31

32

35

Cet exercice est disponible sur le serveur bigbrother pour le systme RTAI.
2 . Dterminer une allocation adquate des priorits pour que tous les temps de rponse
limites de toutes les tches soient respectes :
Tches
T1
T2
T3
T4

LT LA SALLE

Temps de rponse limite

10
12
40
30

Priode
10
12
40
600

Page 17 / 22

Temps de calcul
1
2
8
20

Priorit

TV.BTSii.2001

38

Cours Temps Rel

T1
t
T2
t
T3
t
T4
t
1

10

20

30

40

50

60

70

Pour le respect des temps de rponse, le problme se pose autour de la priode 600, et il
existe deux possibilits d'affectation de priorit :
cas n 1 :
T1
t
T2
t
T3
t
T4
t
x10

59

60

61

62

63

64

65

cas n 2 :
T1
t
T2
t
T3
t
T4
t
x10

59

60

61

62

63

64

65

Conclusion :

LT LA SALLE

Page 18 / 22

TV.BTSii.2001

Cours Temps Rel

3 . Dterminisme et temps rel

L'aspect important d'une application temps rel est de pouvoir priori faire un bilan des
diffrents temps. On va aborder cet aspect au travers un exemple simple.
3 . 1 . Principe
On considre deux tches TFiltre et TMoteur dont les rles sont les suivants:
TFiltre: Excuter en permanence les activits suivantes:
Attendre sur une bote aux lettres une donne issue dune opration dacquisition.
Effectuer lopration de filtrage: Y(n) = (1/16).X(n) + (15/16).Y(n-1).
Restituer dans le registre AdCNA (botier CNA), la valeur filtre Y(n).
TMoteur: Excuter en permanence la rgulation du moteur.
Lacquisition seffectue sous interruption :
Chaque fois quune donne est disponible aprs conversion, un signal dinterruption
dclenche lexcution du service ITCAN. Ce dernier lit la donne dans le registre AdCAN
et la transmet dans la bote aux lettres BalCAN.
Lchantillonnage du signal seffectue cadence fixe, sachant que la frquence la plus
haute contenue dans le signal est 2,5 KHz.
a . En utilisant le thorme de Shannon, calculer la frquence et la priode
d'chantillonnage.
Rponse :

Entre deux IT, l'acquisition et le traitement ne doivent pas dpasser la priode

d'chantillonnage.
LT LA SALLE

Page 19 / 22

TV.BTSii.2001

Cours Temps Rel

b . Proposer et justifier les niveaux de priorit affecter aux tches TFiltre et

TMoteur.
Rponse :

Pour approcher mieux laspect temps rel, on crira les programmes en assembleur
68000 dont on connat les temps de cycle de chacune des instructions. Les primitives
multitche du noyau RTC seront utilises partir du mme assembleur.

LT LA SALLE

Page 20 / 22

TV.BTSii.2001

Cours Temps Rel

On utilise un microprocesseur 68000 de frquence 10 MHz.

En consquence, le nombre de cycles horloge pour chacune des primitives Send et
Receive donn par les concepteurs de RTC sont les suivants :
- Send: Message transmis une tche en attente avec premption: 738 cycles
(le nombre de cycles de rordonnancement est inclus)
- Receive: La tche attend la donne: 676 cycles
(le nombre de cycles de rordonnancement est inclus)
On donne ci-dessous, pour chacune des instructions, le nombre de cycles machine
indiqus par la documentation du microprocesseur 68000 :
movem.w
: 28 cy
move.w #Id, ... : 8 cy
move.b
: 16 cy
move.l
: 4 cy
move.b (sp), .. :8 cy
move.b .., (sp) :9 cy
move.b .., AdCNA:17 cy
clr.l
: 6 cy
lsr.b
: 14 cy
sub.b
: 12 cy
add.b
: 8 cy
rte
: 20 cy
bra
: 10 cy
trap Kernel
: 37 cy
Send
: 738 cy
Receive
: 676 cy
etc ...
En outre, la documentation du 68000 indique 47 cycles horloge pour la prise en compte
de linterruption lectronique.
c . Dterminer le temps dexcution de la tche TFiltre et du service
dinterruption ITCAN.
Rponses :
ITCAN

TOTAL :

movem.w d0-d3, -(sp)

clr.l d2
move.b AdCAN, d2
move.w OIdsend, d0
move.w #Idbalcan, d1
move.l d2, d3
trap Kernel //pour Send
movem.w (sp)+, d0-d3
rte

cycles

Temps dexcution du service dinterruption (en s) :

LT LA SALLE

Page 21 / 22

TV.BTSii.2001

Cours Temps Rel

Temps de prise en compte de l'IT (en s) :

TFiltre

move.w #IdReceive, dO
move.w #IdBalCan, dl
clr.l d2
trap Kernel //pour Receive
lsr.b #4, d3
move.b (sp), d4
lsr.b #4, d4
sub.b (sp), d4
add.b d3, d4
move.b d4, (sp)
move.b d4, AdCNA
bra TFiltre

TOTAL :

cycles

Temps dexcution de la tche TFiltre :

d . Reporter sur le graphe temporel, lenchanement des traitements partir

dune interruption signalant la disponibilit dune donne convertie et calculer
le temps total.
Que faut-il maintenir pour viter un filtrage dgrad. Conclure.
Rponses :

Temps total (en s) :

Conclusions :

LT LA SALLE

Page 22 / 22

TV.BTSii.2001