Concepts de base du Temps Réel (RT). Le Temps Réel au sens strict avec
RT-Linux
Qu'est ce que le Temps Réel ?
Avant d'introduire RT-Linux il est nécessaire de préciser plusieurs points en rapport avec le temps réel.
On dira que:
" Un système Temps Réel est un système d'information dont les corrections ne dépendent pas uniquement du résultat
logique des algorithmes mais aussi de l'instant où ces résultats ont été produits."
Il ne suffit pas que le résutat soit correct, il doit être obtenu en un temps spécifié.
Remarquez que d'après cette définition, un sytème Temps Réel n'a pas besoin d'être rapide,
comme on pourrait être amené à le croire. Par exemple: le système de guidage d'un navire
peut apparaître comme n'étant pas un système Temps Réel, à cause de sa faible vitesse et qu'habituellement
on a "assez" de temps (en minutes) pour prendre une décision avant d'agir. Néanmoins, d'après notre définition c'est
effectivement un système RT.
Remarque : nous avons definit un "Système Temps Réel" et non un Système en Temps Réel. Les
"Système en Temps Réel" sont généralement des sytèmes rapides capables de donner
l'illusion de la réalité. Typiquement ce sont les simulations et les jeux
intercatifs qui ont besoin de donner à l'utilisateur l'apparence de la
continuité du temps et un maximums. Plus il y a d'images générées par unité
de temps, meilleur c'est.
Considerons plus en détail le concept de "restriction temporelle". Supposons
que l'on cherche à contrôler la vitesse d'un moteur soumis à une charge variable,
et que l'on souhaite le réguler avec un PID (Proportionel-Intégral-Dérivé).
La régulation PID est, selon nos critères, une fonction qui prend un certain
nombre de paramètres -- dans cet exemple, la vitesse du moteur -- et fournit
la valeur du signal de commande à appliquer au moteur -- la tension
d'alimentation du moteur. La théorie qui repose derrière l'algorithme PID,
qui d'ailleurs est générale, considère que le temps de calcul est négligeable,
c'est à dire que le temps qui s'écoule entre la lecture de la vitesse du moteur
et l'envoi de la commande est très court. Dans des circonstances normales,
les sytèmes prennent un peu de temps. Une autre caractéristique de ce type de
régulations est qu'elles doivent être exécutées périodiquement, en d'autre termes,
l'algorithme PID doit être exécutés régulièrement. Si le temps entre deux appels
consécutifs de la fonction PID est trop grand, le moteur peut atteindre une vitesse
indésirable. Pour résumer :La fonction PID peut être vue comme un programme
qui doit être exécutés périodiquement (Pi); depuis le temps écoulé entre le démarrage
et l'achèvement ne doit pas dépasser un interval de temps maximal spécifié par
la conception du PID (Di) et en fonction de la vitesse du processeur,
le code du PID nécessite un certain temps (Ci).
Pi: Période de la tâche i.
Di: Temps limite pour la tâche i.
Ci: Temps de calcul maximal pour la tâche i.
Si le système consiste en une seule tâche, alors, il n'y a pas de problèmes de Temps Réel:
soit le processeur peut exécuter la tâche dans le temps impartis soit il ne le peut pas.
Au cas où le processeur n'est pas assez rapide, on le remplace par un autre plus véloce.
Le problème de Temps Réel apparaît quand le système est constitués de plusieurs tâches
et qu'il est nécessaire de diviser la puissance du ou des processeurs entre elles.
Ceci exclu toute utilisation d'un système à temps partagé classique comme Linux.
Bien sur, faut-il préciser qu'il est inutile d' essayer
d'écrire des programmes faisant appel au temps réel sous Windows...? Un conseil bien meilleur
est de n'écrire aucune sorte de programmes pour cette plateforme.
Tous les Système Temps Réel ne sont pas identiques, ce n'est pas la même chose de commander un
système de freinage ABS d'une voiture, le système d'injection de combustible d'un moteur d'avion
ou la décompression et la visualisation d'un fichier mpeg. Dans le premier et le second cas, un petit surcroit
de temps d'exécution peut couter des vies humaine ou de graves pertes de matériel; dans le trosième,
il y a simplement dégradation de la qualité du système (l'image pourra rester figée et quelques
portions perdues). Le premier type de système est appelé Système Temps Réel physique (Hard Real-Time Systems),
et le second Système Temps Réel logique (Soft Real-Time System). Nous concentrerons notre propos sur le premier type.
La conception d'un Système Temps Réel passe par plusieurs phases:
Premièrement, on identifie la tâche à réaliser et les contraintes temporelles qui doivent être satisfaites.
Deuxièmement le code est écrit.L Finallement le temps d'exécution de chaque tâche est mesuré et un test de
rendez vous horaire est réalisé pour vérifier qu'aucune tâche ne dépassera son temps
limite pendant le fonctionnement du système. Le test de rendez vous horaire consiste
à appliquer un certain nombre de tests à l'ensemble des tâches. Si elles passent
ces tests, il sera alors possible de garantir qu'aucun temps limite ne sera dépassé.
Si aucontraire les tests ne sont pas concluants, il est nécessaire de reprendre la conception
depuis le début, en choisissant un processeur plus rapide ou en utilisant
d'autres algorithmes pour implémenter les tâches.
En résumé: Les tâches sont identifiées par trois valeurs de temps : P , D et C.
La raison d'être du système est de garantir que toutes les tâches (dans toutes
leurs configurations d'exécution) satisferont les temps limites. Pour garantir les
temps d'exécution, le système doit être prévisible. Dire qu'un système
est Temps Réel ou que ce système est prévisible est pratiquement la même chose.
Quelle est la relation entre le système d'exploitation et le Temps Réel ?
LA correction sémantique de la réponse est de la responsabilité du programmeur
ettandis que la correction temporelle dépend du système d'exploitation (OS Pour
Operating System en anglais. NDT).
L' O.S. doit supporter et organiser l'exécution de toutes les tâches. C'est aussi
l'affaire de l'O.S. de gérer toutes les interruptions. Il doit offrir:
- L'algorithme de prévision
- Les mécanismes de communication inter-processus (sémaphores, messages, etc.)
- Gérer les interruptions.
- Activer tâches à chacune de leur période.
Contrairement aux O.S. normaux, le but d'un Système d'Explotation Temps Réel est de minimiser
la complexité. IL n'est pas nécessaire d'avoir un système d'exploitation qui fait beaucoup
de choses, ce qui est vraiment important est d'exécuter les tâches telles que prévues
et rapidement.
Il vaut mieux un O.S. qui prend normalement 10 unités de temps pour accomplir un
changement de contexte et qui en prend 12 dans les pires cas, qu'un autre OS qui en moyenne
prend 3 unites de temps mais qui peu de temps en temps aller j'usqu'à 20.
On ne sera surpris de découvrir que les O.S. Temps Réel sont "plus lents" que
les normaux. Dans certain cas, afin d'avoir des comportements prévisibles,
il pourra même être nécessaire de désactiver la mémoire cache avec la
perte de performances associée. La mémore cache, les processeurs avec des
unités pipelines et les algorithme de prédiction de sauts sont des ennemis
clairement désignés de la prévisibilité et par conséquent des Système Temps Réel.
Les Extensions POSIX Temps Réel.
POSIX sont les initiales de "Portable Operating System Interface"
(Interface Portable pour Systèmes d'Exploitation) (Quel peut être un O.S.
sans X à la fin ?). C'est un standard qui tend à obtenir la poratbilité des
logiciels aux niveau du code source. En d'autres termes, un programme qui estdestiné à
un système d'exploitation qui respecte POSIX devrait se compiler et s'exécuter
sous n'importe quel système POSIX, même s'il provient d'un fabricant différent.
Le standard POSIX définit l'interface que l'O.S. doit offrir aux applications:
le jeux d'appels système. POSIX est développé par l'IEEE (Institute of Electrical
and Electronic Engineering) et standardisé par ANSI (American National Standards Institute)
et ISO (International Standards Organisation). Evidemment POSIX est basé sur UNIX.
La majorité des O.S. (y compris Windows NT) tendent à être compatibles POSIX aux
travers de leur différentes versions.
Le travail sur la définition POSIX est divisé en plusieurs groupes
de travail qui comptent dans leur rang des fabricants d'ordinateurs,
des sociétés de logiciel, des fonctionnaires et des gourous en
informatique. Chaque groupe sse charge de concevoir un aspect du système
d'exploitation. Par exemple, le groupe nommé POSIX.4 s'occupe des aspects
Temps Réel.
Les extension POSIX.4 -- renommées 1003.1b depuis 1993 -- autorisent l'usage
d'un O.S. dans des situations Temps Réel. Bien sur la grande majorité de ces
extensions traitent de la gestion du temps et des priorités des processus. Il
existe aussi des appels systèmes pour faciliter la communication inter-processus.
Les extensions POSIX sont conçues pour améliorer le contrôle de la
gestion des ressources de l'O.S..
Linux 2.0 implante beaucoup des extensions POSIX pour le Temps Réel... mais cet
aspect de LInux est quelque chose que nous traiterons dans un prochain
article. La Version 2.2, sera très probablement compatible POSIX
1003.1b à 100%.
Linux Temps Réel
RT-Linux a été développé au Département d'Informatique de l'Institut des Mines
et de Technologie de New Mexico par Victor Yodaiken et
Michael Barabanov. Il fait partie du travail fourni par Michael pour son Master
en informatique. La dernière version disponible est la 0.6. Pour l'instant il n'est
disponible que pour les architectures Intel.
RT-Linux résoud le problème d'une façon radicallement différente. Au lieu de modifier
le noyau de Linux, pour le rendre prévisible, il construit directement sur le processeur
(i386) un petit noyau -- indépendant de celui de Linux -- avec un gestionnaire de tâches.
Le noyau de Linux tourne au dessus de lui partageant le processeur avec les autres tâches
Temps Réel. Linux partage alors le noyau avec d'autres tâches. Plus précisement, Linux ets une tâche
en arrière plan et ne tourne que lorqu'aucune autre tâche Temps Réel n'est active.
Je pense que beaucoup de lecteurs seront perturbés à ce point, peut être que
beaucoup pensent que l'O.S. est tout puissant et qu'il n'est pas possible de
le manipuler.
Il est même encore plus surprenant de savoir qu'il est possible d'installer ou de
désinstaller le gestionnaire de tâches dynamiquement, car il est compilé comme un module.
Le code du noyau Linux (comme tout O.S.) désactive généralement les interruptions
comme moyen de synchronisation ou pour implanter des sections critiques. S'il y a une
inturruption de l'horloge pendant que Linux désactive les interruptions, elle reste bloquée et
il y a par conséquent il y a une grande imprécision temporelle. RT-Linux implante une
solution élégante: tous les appels à cli,sti et iret (appels asssemleur qui modifient
l'état des interruptions) sont remplacés par S_CLI, S_STI et S_IRET qui les émulent. De la
sorte, Linux ne peut jamais désactiver les interruptions.
Le gestionnaire de tâche par défaut qui est livré avec RT-Linux est préemptif, à priorités
fixes et considère la tâche Linux comme celle de plus basse priorité. Si les tâches Temps Réel
consommes tout le temps du processeur, alors la tâche Linux n'aura plus de temps CPU
affecté et pourra donner l'impression que le système set arrêté.
Avec RT-Linux nous n'avons pas seulement un Système Temps Réel mais aussi un O.S. classique. On
peut surfer sur le web en même temps que l'on interroge et commande un système physique.
Installation de RT-Linux
Les fichiers de la distribution peuvent être trouvé à:
http://luz.cs.nt.edu/~rtlinux.
Pour "transformer" un système Linux en RT-Linux, il faut appliquer un patch aux
sources du noyau et le recompiler. Voici la recette. Assumons que le fichier
rtlinux-0.6-2.0.33.tgz est dans le répertoire /usr/src et qu'il a été extrait dans
/usr/src/rtlinux-0.6. Assumons aussi que toutes les options pour le noyau ont été
configurée (make config), alors
# cd /usr/src/linux
# patch -p1 <../rtlinux-0.6-2.0.33/kernel_path
# make dep; make clean; make zlilo; make modules; make modules_install
# reboot
Le nouveau noyau apparaît identique au noyau normal, toutefois il est déjà
prêt à se transformer en Système Temps Réel. Dans le répertoire /usr/src/rtlinux-0.6-2.0.33/testing
on trouvera divers programmes de démonstration.
En plus des exemples qui sont fournis avec la distribution (dans le répertoire testing),
on peut télécharger un autre exemple préparé par Oleg qui permet de créer un chronogramme
d'exécution des tâches. Un fichier de cette démo est un gestionnaire de tâches avec des
modifications qui permettent nons seulement de gérer les tâches, mais aussi d'envoyer des
informations concernant les décisions qu'il prend. Cette information est récupérée et
stockée dans un fichier qui peut être affichée graphiquement après. Le résultat montre
dans quel ordre les diverses tâches ont été exécutées et comment celles de plus hautes
priorités prévalent sur celles de plus basse priorité. La tâche Linux n'est pas représentée.
Chaque tâche est représentée par un axe horizontal. Les rectangles représentent
les moments où les tâches utilisent le processeur (à un instant donné, seule une
tâche peut être exécutée car nôtre système est mono-processeur).Dans cet exemple,
le temps limite de chaque tâche est égal à leur période. Cette dernière est représentée
par un interval temporel représenté par: )
pendant lequel la tâche doit être exécutée. Les tâches de la partie supérieure ont les
plus hautes priorités et sont capables de prendre la main sur d'autres comme cela arrive
par exemple à l'instant 600.
L'avenir de RT-Linux
Il existe déjà une version multi-processeurs de RT-Linux. Les services offerts
sont intentionnellement minimaux, il n'est pas nécessaire d'inclure des fonctions
non strictement nécessaires afin de garder un système aussi prévisible que possible.
Néanmoins, il existe déjà certaines extension qui permettent de travailler avec
des sémaphores et de contrôler les tâches Temps Réel des processus Linux au travers de
/proc/sys.
La crétion du manuel didacticiel pour RT-Linux a commencé il y a quelques
semaines.
Conclusions
Avant l'arrivée de RT-Linux, beaucoup d'ingénieurs qui voulaient utiliser
les Système Temps Réel étaient forcés d'utiliser MS-DOS et de concevoir tous les pilotes nécessaires,
ou d'acheter un Système Temps Réel (à des prix trés prohibitifs). Maintenant les développeurs ont un
système d'exploitation complet pour les applications Temps Réel sur le même système que celui
qu'ils vont utiliser. En fait, on peut même avoir plusieurs applications Temps Réel qui tournent
en même temps que l'on surf sur le web sans problèmes.
Notre prochain article de cette série examinera plusieurs exemples d'applications
Temps Réel et comment écrire nos propres applications Temps Réel.
Traduit par Jonh Perr
|