Sommaire Indexe Rechercher Liens A Propos
[LinuxFocus Image]
[Barre de Navigation]
  Nouveautés   Archives

Linux Temps Réel (RT- Linux)

par Ismael Ripoll


Qu'est ce que le Temps Réel ?

Les O.S. et le Temps Réel

L'avenir de RT-Linux

Conclusions

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.

DrawObject

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.

DrawObject

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  

 

© 1998 LinuxFocus
Ce site Web est maintenu par Miguel A Sepulveda.