SYSTEMES TEMPS REELS (annexes)

SYSTEMES TEMPS REELS
(annexes)
Non classifié
Novembre 1999
Systèmes temps réels
2
Table des matières
ANNEXE 1 - CONCEPTS DE BASE DU TEMPS RÉEL.........................................................................................................4
1.
2.
3.
4.
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
QU'EST CE QUE LE TEMPS RÉEL ? ..........................................................................................................................................4
QUELLE EST LA RELATION ENTRE LE SYSTÈME D 'EXPLOITATION ET LE TEMPS RÉEL ?.................................................5
LES EXTENSIONS POSIX TEMPS RÉEL.................................................................................................................................5
LES SERVICES DE BASES D'UN SYSTÈME TEMPS RÉEL ..........................................................................................................7
TÂCHES .................................................................................................................................................................................7
BOÎTES AUX LETTRES..........................................................................................................................................................9
EVÉNEMENTS.......................................................................................................................................................................9
SÉMAPHORES......................................................................................................................................................................10
INTERRUPTIONS .................................................................................................................................................................10
TIMERS OU CHRONOMÈTRE ...............................................................................................................................................10
ANNEXE 2 - PRÉSENTATION DU SYSTÈME TEMPS RÉEL VXWORKS ................................................................ 11
1.
2.
3.
4.
PRÉSENTATION .......................................................................................................................................................................11
CARACTÉRISTIQUES TEMPS RÉEL.........................................................................................................................................12
INTERFACE AVEC UNIX.........................................................................................................................................................15
A UTRES PARTICULARITÉS .....................................................................................................................................................16
ANNEXE 3 - PRÉSENTATION DE RTC.................................................................................................................................. 18
1.
2.
3.
PRÉSENTATION .......................................................................................................................................................................18
PRIMITIVES ET FONCTIONS TEMPS RÉEL ..............................................................................................................................18
A UTRES CARACTÉRISTIQUES ................................................................................................................................................21
SIGLES ET TERMINOLOGIE :.................................................................................................................................................. 22
SIGLES GÉNÉRAUX :.........................................................................................................................................................................22
TERMINOLOGIE :...............................................................................................................................................................................23
BIBLIOGRAPHIE :.......................................................................................................................................................................... 24
SITES INTERNET :..............................................................................................................................................................................24
GLOSSAIRE :.................................................................................................................................................................................... 25
Non classifié
Novembre 1999
Systèmes temps réels
3
Liste des figures
Figure 1 - Interface POSIX d'un système d'exploitation...................................................................... 6
Figure 2 - Round Robin entre tâches de même priorité ....................................................................... 7
Figure 3 - Ordonnancement en tourniquet ........................................................................................... 8
Figure 4 - Exemple de changement de contexte dans un système temps réel...................................... 8
Figure 5 - Etats possibles des tâches .................................................................................................... 9
Figure 6 - Architecture globale de VxWorks..................................................................................... 11
Figure 7 - Structure du noyau WIND................................................................................................. 12
Figure 8 - Diagramme d'états des tâches sous VxWorks ................................................................... 12
Figure 9 - Environnement de communication de VxWorks .............................................................. 15
Figure 10 - L'environnement Tornado ............................................................................................... 17
Figure 11 - Diagramme d'états des tâches sous RTC ......................................................................... 18
Non classifié
Novembre 1999
Systèmes temps réels
4
Annexe 1 - Concepts de base du Temps Réel
1. Qu'est ce que le Temps Réel ?
"Un système Temps Réel est un système d'informations 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" .
Un système temps réel est un système où le temps intervient dans la validité du programme :
ë Possibilité de réagir en un temps adapté aux événements externes ;
ë Possibilité de fonctionnement en continu sans réduire le débit du flot d'informations traitées ;
ë Temps de calcul connus et modélisables pour permettre l'analyse de la réactivité.
D'après cette définition, un système Temps Réel n'a pas besoin d'être rapide. 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 il y a "assez" de temps (en minutes) pour prendre
une décision avant d'agir. Néanmoins, c'est effectivement un système temps réel.
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 exclut toute
utilisation d'un système à temps partagé (Unix, Windows).
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. Finalement, le temps d'exécution de chaque tâche est mesuré et un test de rendezvous 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 au contraire les tests ne sont pas concluants, il
est nécessaire de reprendre la conception depuis le début, en choisissant un processeur plus
rapide (si cela est possible) ou en utilisant d'autres algorithmes pour implémenter les tâches.
En résumé :
Les tâches peuvent être identifiées par trois valeurs de temps :
ë Période de la tâche ;
ë Temps limite pour la tâche ;
ë Temps de calcul maximal pour la tâche.
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.
Non classifié
Novembre 1999
Systèmes temps réels
5
2. 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, la correction
temporelle dépend du système d'exploitation.
Le système doit supporter et organiser l'exécution de toutes les tâches. Le système doit
également 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 systèmes d'exploitation standards, le but d'un système d'exploitation temps
réel est de minimiser la complexité. Il n'est pas nécessaire d'avoir un système d'exploitation
ayant beaucoup de possibilités mais un système capable d'exécuter les tâches telles que prévues
et rapidement.
Il est préférable d'avoir un système d'exploitation 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
système qui en moyenne prend 3 unités de temps mais qui de temps en temps peut aller jusqu'à
20.
On ne sera surpris de découvrir que les systèmes 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ées. La mémoire cache, les
processeurs avec des unités pipelines et les algorithmes de prédiction de sauts sont des ennemis
clairement désignés de la prévisibilité et par conséquent des Systèmes Temps Réel.
3. Les Extensions POSIX Temps Réel.
POSIX sont les initiales de "Portable Operating System Interface" (Interface Portable pour
Systèmes d'Exploitation). C'est un standard qui tend à obtenir la portabilité des logiciels aux
niveau du code source.
En d'autres termes, un programme destiné à un système d'exploitation et respectant le standard
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 le système d'exploitation 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 systèmes d'exploitation (y compris Windows NT) tendent à être
compatibles POSIX aux travers de leurs différentes versions.
Non classifié
Novembre 1999
Systèmes temps réels
6
application 1
application 2
appels systèmes
(POSIX)
Système
d'exploitation
Drivers
Interruptions et Entrées/Sorties
Matériel (Hardware)
Figure 1 - Interface POSIX d'un système d'exploitation
Le travail sur la définition POSIX est divisé en plusieurs groupes de travail qui comptent dans
leur rang des fabricants d'ordinateurs, des éditeurs de logiciel, des fonctionnaires et des
spécialistes en informatique. Chaque groupe se 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 extensions POSIX.4 -- renommées 1003.1b depuis 1993 -- autorisent l'usage d'un système
d'exploitation dans des situations temps réel.
Bien sûr, 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
systèmes d'exploitation.
Non classifié
Novembre 1999
Systèmes temps réels
7
4. Les services de bases d'un système temps réel
Ce paragraphe présente les services de base que fournissent en général les systèmes temps réel.
4.1. Tâches
Une tâche, définie par son identificateur, comporte un contexte permettant à tout instant de
connaître son état et ainsi de pouvoir arrêter/redémarrer son exécution sur le processeur.
Une tâche est représentée par une procédure avec un nom et un ensemble de routines.
procedure task2
begin
loop
traitements
en loop
end;
procedure task2
begin
loop
traitements
end loop
end;
Dans un environnement monoprocesseur, on dit qu'une tâche a le processeur.
Notions de priorités pour les tâches :
Si task1 a une priorité inférieure à task2, s'il y a uniquement ces deux tâches et si ces tâches
n'effectuent aucune opération bloquante, la tâche task2 s'exécutera toujours et la tâche task1
jamais.
Pour un même niveau de priorité, l'exécution des tâches s'effectue selon un partage de
temps (Round Robin, "à tour de rôle" ou en tourniquet 1 ), appelé ordonnancement des
tâches.
task1
task2
temps
Figure 2 - Round Robin entre tâches de même priorité
Chaque tâche s'exécute dans un intervalle de temps et laisse la place à la prochaine tâche
prête.
L'ordonnancement Round Robin est un ordonnancement préemptif.
1
cette technique est également connue sous le nom d'ordonnancement circulaire
Non classifié
Novembre 1999
Systèmes temps réels
8
tâche prête
tâche bloquée
tâche active
Ordonnanceur
PROCESSEUR
Figure 3 - Ordonnancement en tourniquet
Pour la gestion du temps, il existe la notion de ticks d'horloge (souvent représenté par une
interruption de l'horloge du système). Dans la plupart des systèmes temps réel, un tick
représente une période de 10 ms. A l'arrivée d'un tick, le système temps réel effectue un
changement de contexte pour laisser le processeur à une tâche prioritaire en attente
(préemptif) ou à une autre tâche de priorité égale (Round Robin).
quelques µs
Tâche k
Tick horloge
Tâche i
Début tick
Décision switch
Fin tick
Temps
Changement de contexte
Vérification si la tâche en cours a une priorité plus forte par rapport
aux autres tâches en attente (préemptif)
Si priorité égale alors Round Robin
Figure 4 - Exemple de changement de contexte dans un système temps réel
Non classifié
Novembre 1999
Systèmes temps réels
9
File FIFO
Changement
de contexte
Occupation
du processeur
En attente
de processeur
Tâches éligibles
Tâche élue
Insertion au
bon endroit
de la file
Tâches suspendues
Figure 5 - Etats possibles des tâches
4.2. Boîtes aux lettres
Service permettant d'envoyer (send) et de recevoir (receive) des messages.
La tâche en attente d'une lettre est suspendue jusqu'à l'arrivée de cette dernière.
Il faut cependant à veiller à affecter une priorité plus élevée à la tâche qui effectue la
réception, par rapport à la tâche qui réalise l'envoi.
La profondeur de la boîte aux lettres est souvent paramétrable. Certains systèmes temps réel
acceptent un timeout pour les fonctions d'envoi et de réception.
4.3. Evénements
Le principe des événements est similaire à celui des boîtes aux lettres, à la différence près
qu'au lieu de recevoir ou d'envoyer des données (un lettre), un signal est émis ou attendu.
La signalisation entre deux tâches nécessite une opération dans chacune des tâches :
ë attente de l'événement dans l'une,
ë positionnement de l'événement dans l'autre.
Une tâche peut attendre successivement à des instants différents de son exécution des
événements différents. Un événements peut être signalé par plusieurs tâches.
Un événement est spécifique à la tâche susceptible de l'attendre. Tout événement est donc
associé à une tâche.
Non classifié
Novembre 1999
Systèmes temps réels
10
4.4. Sémaphores
Les sémaphores utilisés avec les systèmes temps réel servent à partager une ressource entre
plusieurs tâches (création d'une section critique).
Les sémaphores servent également à synchroniser plusieurs tâches entre elles.
Le sémaphore (Dijkstra) est un objet sur lequel seulement deux opérations sont possibles :
P(s) et V(s), toutes les deux opérations sont atomiques.
Un sémaphore possède une valeur entière, définie entre 2 opérations.
P(s) : si la valeur de s est inférieure ou égale à 0, la tâche appelante est bloquée, sinon la
valeur de s est décrémentée.
V(s) : s'il y a une tâche bloquée sur s, celle-ci est débloquée, sinon la valeur de s est
incrémentée.
P est une barrière et V un laissez-passer2 .
4.5. Interruptions
Les interruptions permettent de prendre en compte des événements au processeur
(asynchrones).
La prise en compte d'une interruption provoque l'arrêt du programme en cours et l'exécution
d'un programme associé à cette interruption.
Certains systèmes temps réel fournissent des fonctions permettant de lier les interruptions
avec une fonction particulière du logiciel (routine d'interruption).
La routine d'interruption ne doit en aucun cas appeler une fonction bloquante.
4.6. Timers ou chronomètre
Ces services permettent de réaliser des traitements cycliques ou de détecter des
dépassements dans les réceptions de données par exemple.
Comme pour les interruptions, il ne faut pas réaliser d'opérations bloquantes dans les
fonctions appelées par les timers.
2
Passeren, Vrygeven (hollandais) = Prendre et libérer.
Non classifié
Novembre 1999
Systèmes temps réels
11
Annexe 2 - Présentation du système temps réel VxWorks
1. Présentation
L'exécutif VxWorks de Wind River Systems est le premier système à intégrer le développement
croisé (cross-development) à partir d'une station UNIX (et depuis peu à partir d'une station sous
Windows).
Le développement sous un environnement de type UNIX offre la richesse d'utilitaires, de
possibilités réseaux et de convivialité de développement.
Les raisons qui permettent de justifier
(VxWorks/UNIX) sont les suivantes :
l'utilisation
deux
systèmes
d'exploitation
ë la première est qu'UNIX n'est pas en mesure d'offrir des outils adaptés au temps réel et en
conséquence de répondre à des critères de performances temps réel ;
ë la deuxième, est que l'architecture fortement optimisée des systèmes d'exploitation temps
réel ne facilite pas forcément leur utilisation en tant que plate-forme de développement.
VxWorks est donc au sens strict un exécutif temps réel, spécialement conçu pour le
développement en environnement UNIX. La figure ci-dessous présente l'architecture globale de
VxWorks.
Outils de développement hôte
Connexion Hôte/Cible
Outils de développement cible
Sous-système réseau
Sous-système Entrées/Sorties
Système d'exploitation
micro-noyau
WIND
Système évolutif
Figure 6 - Architecture globale de VxWorks
Tout comme beaucoup d'autres exécutifs de ce type, UNIX est vu tel un ensemble logiciel de
haut niveau pour le développement des applications, exécutées et mises au point sous VxWorks.
Le noyau (WIND) de ce dernier offre des primitives de base de gestion de processus et de
Non classifié
Novembre 1999
Systèmes temps réels
12
sémaphores sur lesquelles sont construites les fonctions systèmes accessibles par l'intermédiaire
du système d'exploitation.
Traitement des
interruptions
Gestion
des tâches
Horloge
Système
Sémaphores
Communication
Inter-tâches
Gestion
mémoire
Figure 7 - Structure du noyau WIND
VxWorks est compatible de l'interface POSIX 1003.1b (également connu sous le standard
1003.4) défini par l'IEEE (Institute of Electrical and Electronics Engineers). Cela facilite le
portage vers d'autres systèmes conformes à ce standard.
2. Caractéristiques temps réel
L'ordonnancement des tâches est basé sur le principe de priorité (256 niveaux possibles) avec
préemption. Pour des tâches de priorités identiques, c'est la technique du round-robin qui est
mise en œuvre. Le temps de commutation de contexte est indépendant du nombre de tâches
installées dans le système ; à titre indicatif, sur un 68020 à 25 MHz, il est de 17 µ s.
en attente
prête
retardée
suspendue
Figure 8 - Diagramme d'états des tâches sous VxWorks
La synchronisation est assurée par signaux, les fonctionnalités étant basées sur les primitives de
gestion de sémaphores. VxWorks supporte trois types de sémaphores : les sémaphores
Non classifié
Novembre 1999
Systèmes temps réels
13
booléens , à compteur et à priorité. Ces derniers permettent de contourner l'effet subversif des
priorités relatives des tâches. En effet, une tâche de faible priorité sera susceptible d'hériter
momentanément de la priorité de la tâche de plus forte priorité en attente sur le sémaphore. Les
trois types de sémaphores acceptent des attentes avec timeout et autorisent le chaînage des
processus dans les files de type FIFO ou à priorité.
Du point de vue de la communication, l'exécutif intègre des outils de haut niveau bâtis à partir
des primitives de gestion de sémaphores. On dispose de :
-
files de messages, de type FIFO, de longueur variable et accessibles à partir de tout
processus utilisateur ou système, y compris une routine de service d'interruption ;
tubes de communication (pipe), faisant office d'interface entre un processus et une file de
message avec l'avantage d'utiliser des services d'entrées-sorties indépendant du matériel
(fonction de gestion de périphériques virtuels).
Lors de l'arrivée d'une interruption, une routine ISR (Interrupt Service Routine) est invoquée,
l'exécutif n'intervenant pratiquement pas entre l'arrivée du phénomène d'interruption et
l'exécution de la routine ISR. Les routines ISR peuvent, si besoin est, envoyer des signaux,
manipuler des sémaphores, des files de messages ou des pipes.
Par ailleurs, VxWorks dispose de fonctionnalités autorisant la manipulation des vecteurs
d'interruptions directement en langage de haut niveau tel que le langage C ainsi que l'association
d'une routine écrite en C à une source d'interruption matérielle.
A propos du masquage des interruptions et de la préemption, VxWorks minimise les temps de
fonctionnement en "mode système", mode dans lequel généralement tout exécutif est non
préemptible (et au pire, non interruptible) pour assurer l'intégrité de manipulation des ressources
du noyau (files internes, pointeurs, etc…) de telle sorte que le temps de latence en interruption
se réduit à 8 µs.
Le fonctionnement en mode "système" ne concerne que les manipulations vitales de gestion du
multitâche et les opérations de base de synchronisation.
Les fonctionnalités de communication, de gestion mémoire, de gestion multiprocesseurs (par
réseaux) sont essentiellement exécutées en mode "utilisateur" (c'est à dire dans le contexte du
processus concerné), et sont donc préemptible.
Non classifié
Novembre 1999
Systèmes temps réels
14
Le tableau ci-dessous résume les performances temporelles de VxWorks pour un processeur
68020 à 25 MHz.
Mesures
VxWorks
68020 / 25 MHz
Commutation de contexte
17 µs
Commutation de tâches
35 µs
Opérations sur sémaphores
(Prendre/Rendre)
8 µs
Latence à la préemption
11 µs
Latence en interruption
8 µs
Outre les caractéristiques précitées, VxWorks intègre une bibliothèque de gestion du temps
incluant des "chiens de garde" (watchdog), des compteurs de temps (timer) de délai sur
processus, des possibilités de timeout sur opérations du noyau, etc…
De même, l'exécutif dispose d'une agence de gestion mémoire supportant les fonctions
d'allocation et de désallocation compatibles C ANSI et UNIX.
Le tableau ci-dessous présente les principales fonctions ("primitives") de VxWorks :
Nom de la
librairie
taskLib
semLib
intLib
Non classifié
Nom de fonction
Description
taskSpawn
Création d'une tâche
taskSuspend
Suspension d'une tâche
taskResume
Reprise d'une tâche
taskLock
Verrouillage d'une tâche
taskUnLock
Déverrouillage d'une tâche
taskDelete
Destruction d'une tâche
semBCreate
semCCreate
semMCreate
Création d'un sémaphore (binaire, compteur,
exclusion mutuelle)
semTake
Prise d'un sémaphore
semGive
Libération d'un sémaphore
semDelete
Destruction d'un sémaphore
intConnect
Connecter une routine à une interruption
intLevelSet
Positionner le masque d'interruption
intLock
Bloquer les interruptions
intUnLock
Débloquer les interruptions
Novembre 1999
Systèmes temps réels
memLib
msgQLib
15
malloc
Allouer un bloc mémoire
free
Libérer un bloc mémoire
memShow
Afficher la mémoire disponible
msgQCreate
Créer une file de message
msgQSend
Envoyer un message
msgQReceive
Recevoir un message
msgQDelete
Détruire une file de message
3. Interface avec UNIX
L'une des caractéristiques de VxWorks est de s'intégrer pleinement dans un environnement de
développement de type UNIX, et de faire partie de cette nouvelle génération d'exécutifs basés
sur ce quasi standard de développement.
Qui dit environnement UNIX, sous-entend généralement une machine cible, une machine hôte
et un réseau, donc le support de toute une série d'utilitaires standard de communication par
réseaux. Le schéma ci-dessous présente les différents utilitaires de communication réseaux
supportés par VxWorks.
Systèmes de fichiers
Connexion
rlogin
telnet
rsh
X11
ftp
tftp
NFS
Remote
Debug
RPC
Sockets
TCP
UDP
IP
Ethernet
Bus système
SLIP
…
Liaison série
Figure 9 - Environnement de communication de VxWorks
Non classifié
Novembre 1999
Systèmes temps réels
16
Les sockets sont des primitives de communication à la base du développement d'utilitaires
réseau ou d'applications. VxWorks supporte des connexions en mode datagramme (par
l'intermédiaire de UDP/IP) et en mode connecté (grâce à TCP/IP), ce dernier mode autorisant un
contrôle de bout en bout du flot de données transmis.
Le protocole RPC (Remote Procedure Call) assure l'appel par les tâches VxWorks ou les
processus UNIX de routines exécutées indifféremment par la machine cible (VxWorks) ou hôte
(UNIX).
Le rôle des différents process sont :
ë rsh : remote shell, permet aux processus applicatifs sous VxWorks d'accéder par réseau aux
commandes UNIX ;
ë ftp : file transfert protocol, autorise l'accès à partir du système VxWorks aux fichiers du
système UNIX et inversement ;
ë telnet assure la connexion au shell VxWorks à partir de la machine UNIX, de même que
rlogin assure aux utilisateurs de la cible (VxWorks) une connexion au shell de la machine
hôte (UNIX).
4. Autres particularités
Outre les facilités d'accès à l'environnement UNIX, VxWorks dispose d'une bibliothèque de
gestion des entrées/sorties compatible UNIX au niveau source. Les appels "systèmes" bufférisés
ou non, formatés ou non restent les mêmes. Cette bibliothèque constitue une interface
indépendante du matériel, incluant la gestion des circuits séries orientés caractères (terminaux,
lignes de communications), des disques à accès aléatoire, des circuits virtuels (pipe et sockets),
des circuits parallèles (convertisseurs analogique/digital), des circuits "réseau" pour l'accès de
fichier à distance.
L'exécutif VxWorks peut être fourni avec un environnement intégré pour le développement de
logiciel croisé. Cet environnement est appelé Tornado et fournit les outils suivants :
ë laucher : outil intégré de gestion de cibles ;
ë browser : une collection d'outils permettant de consulter la cible ;
ë CrossWind : un outil de "deboguage" graphique ;
ë WindSh : une console permettant de contrôler la cible ;
ë WindConfig : un outil graphique permettant de configurer l'exécutif VxWorks.
Non classifié
Novembre 1999
Systèmes temps réels
17
Tornado
launcher
Ethernet
browser
CrossWind
Serveur
cible
Emulateur
Exécutif
VxWorks
WindSh
WindConfig
Outils hôte
Liaison série
connexion
Système cible
Figure 10 - L'environnement Tornado
L'environnement Tornado peut être complété avec d'autres produits optionnels tels que :
ë VxGDB, un débogueur multi-tâches symbolique fonctionnant avec Ethernet, ligne série ou
dans l'environnement intégré de l'émulateur HP64700 ;
ë VxSim, un simulateur de la cible VxWorks sur une station UNIX ;
ë WindView, un outil de visualisation graphique permettant d'étudier le déroulement d'une
application temps réel par ses événements et leur "timing" associé, dynamiquement ou en
post-mortem ;
ë Stethoscope, un outil de visualisation graphique permettant d'analyser dynamiquement le
déroulement des applications temps réel. L'information sélectionnée peut être enregistrée
dans un fichier au format MATLAB ou MATRIX X.
Non classifié
Novembre 1999
Systèmes temps réels
18
Annexe 3 - Présentation de RTC
1. Présentation
La société Tecsi est devenue depuis plus de 15 ans un spécialiste de référence dans le domaine
des logiciels embarqués. Cette expérience a été en particulier investie dans sa propre gamme de
noyaux temps réel RealTime Craft (RTC).
Le noyau RealTime Craft présente plusieurs avantages : compact, limité aux fonctions de
gestion de tâches, avec des temps de traitement performant.
2. Primitives et fonctions temps réel
Le diagramme d'état des tâches sous RTC ci-dessous permet de distinguer quatre états pour une
tâche :
ë non opérationnelle (ou hors service) ;
ë en attente (de la réalisation d'une condition) ;
ë prête ;
ë en cours
non opérationnelle
Arreter tâche
"StopTask"
Démarrer tâche
"StartTask"
Terminer la tâche
en cours
"Terminate"
Arreter tâche
"StopTask"
prêt
Sélection par
l'ordonnanceur
occurrence
de la condition
Préemption par
l'ordonnanceur
en cours
en attente
attente
d'une condition
Figure 11 - Diagramme d'états des tâches sous RTC
La priorité des tâches est gérée de façon classique : RTC définit 6 niveaux de priorité croissante
de 0 à 5, à chaque niveau étant associé une file de tâches prêtes, le niveau 0 étant réservé à la
tâche de fond. L'aspect déterministe est mesuré par le fait que c'est la tâche de priorité la plus
élevée qui est exécutée (passage à l'état "en cours").
Non classifié
Novembre 1999
Systèmes temps réels
19
RTC fournit 27 primitives de gestion des tâches :
Nom de la primitive
Description
1
InitTask
initialisation d'une tâche
2
StartTask
démarrer une tâche
3
CurrentTask
obtenir l'identification de la tâche en cours
4
TaskState
obtenir l'état d'une tâche
5
StopTask
arrêter une tâche
6
ForceExeptionHandler imposer qu'une tâche soit déroutée vers un traitement particulier
7
Terminate
terminer une tâche : la tâche passe dans l'état non opérationnel
8
EnterRegion
entrée en région critique
9
LeaveRegion
sortie de région critique
10 ChangePriority
changer la priorité d'une tâche
11 TaskPriority
obtenir la priorité d'une tâche
12 InitSemaphore
initialisation d'un sémaphore
13 V
vendre une unité de sémaphore
14 P
prendre une unité de sémaphore
15 TestP
tester et prendre une unité de sémaphore
16 PWithPrio
prendre une unité de sémaphore, mettre la tâche devant les tâches
de priorité plus faible
17 InitMailbox
initialiser une boîte aux lettres
18 Send
envoyer un message dans une boîte aux lettres
19 SendWithPrio
envoyer un message avec priorité
20 Receive
attendre un message dans une boîte aux lettres
21 TestReceive
tester si un message est disponible et l'obtenir
22 SignalEvent
signaler un événement
23 WaitEvents
attendre la réalisation d'un événement
24 EventsOccured
tester si les événements se sont produits
25 ClearEvents
réinitialiser les indicateurs d'événements
26 StartDelay
armer un temporisateur
27 StopDelay
annuler les effets de l'opération StartDelay
RTC fournit quatre primitives de gestion des événements (primitives 22 à 25). Pour les
mécanismes de communications (primitives 17 à 21), il convient de noter la présence d'une
fonction autorisant le test de la disponibilité d'un message avant consommation effective de
celui-ci (TestReceive). Les fonctions de communications sont exclusivement implémentées sous
forme d'un mécanisme classique de boîtes aux lettres.
Non classifié
Novembre 1999
Systèmes temps réels
20
La gestion des exceptions est assurée grâce à la primitive ForceExceptionHandler.
Du côté synchronisation, les cinq fonctions de gestion de sémaphores (primitives 12 à 16)
comportent les traditionnelles opérations P et V (Prendre et Vendre) des sémaphores à
compteur, avec une fonction supplémentaire, PWithPrio, qui permet de mettre en attente les
tâches de priorités plus faible.
Les fonctions de synchronisation entre tâches (au nombre de quatre) correspondent aux
opérations sur sémaphore à compteur ou sur événements (1 parmi 16 possibles).
Malgré les fonctions d'horlogerie réduites (demande d'exécution d'un traitement déterminé après
un délai et annulation du délai), il est important de noter que toutes les fonctions susceptibles de
provoquer une attente (WaitEvents, P, PWithPrio, Receive) peuvent être associées à une
temporisation, afin de prévenir des éventuels problèmes de deadlock.
Le tableau ci-dessous résume les temps d'exécution principaux des primitives pour un
processeur 68000 à 8 MHz sans attehte mémoire. Les mesures sont réalisées sur une application
comportant au moins 8 tâches réparties sur 8 niveaux de priorité [RTC87][DOR91].
Mesures
RTC
sur 68000
StartTask : sans préemption
68 µs
Send : aucune tâche n'attendait le message
56 µs
Send : avec préemption
86 µs
Receive : message disponible
46 µs
Receive : avec mis en attente
78-110 µs
StartDelay
33 µs
EnterRegion
19 µs
SignalEvent : aucune tâche n'attendait l'événement
34 µs
SignalEvent : une tâche en attente
64 µs
SignalEvent : avec préemption
75 µs
WaitEvents : événement déjà arrivé
24 µs
WaitEvents : avec mise en attente de la tâche
63-95 µs
Terminate
55-87 µs
Il est important de noter que ces temps ne sont dépendants que du nombre de niveaux de
priorité et non du nombre de tâches présentes dans le système. Par ailleurs, dans le cas "avec
préemption", l'exécution de la primitive inclut le changement de contexte.
Non classifié
Novembre 1999
Systèmes temps réels
21
3. Autres caractéristiques
A propos du mécanisme de gestion des interruptions, lorsque ces dernières ne sont pas
masquées, il y a exécution d'une séquence de code immédiate. Ces séquences immédiates
s'exécutent dans l'environnement de la tâche en cours comme si cette dernière avait réalisé un
simple appel de procédure. Le résultat de l'exécution d'une séquence immédiate peut concerner
la tâche en cours ou toute autre tâche de l'application. Après exécution de la séquence
d'interruption, la tâche en cours reprend son exécution normalement. Ainsi sous RTC, le
mécanisme d'interruption n'a pas d'effet sur l'ordonnancement des tâches.
D'un point de vue matériel, RTC affecte 27 vecteurs d'interruptions aux interruptions "logiciels".
L'utilisateur est ensuite libre de répartir ces vecteurs entre ceux de RTC et ceux qui
correspondent aux séquences immédiates.
Lors de l'initialisation du système, RTC exécute une séquence dite "d'initialisation" obtenue par
le processeur avec le vecteur "RESET". Cette séquence construit une table de configuration
indiquant le nombre d'objets de chaque type constituant l'application, à savoir : le nombre de
tâches, le nombre de niveaux de priorités (éventuellement inférieur au nombre de tâches), le
nombre de sémaphores, le nombre de boîtes aux lettres, le nombre de messages en attente et le
nombre de délais. Ces notions correspondent aux objets gérés par le moniteur. L'utilisateur se
contente de référencer les objets par leur type et leur numéro d'ordre. Cette "encapsulation" des
objets contribue à augmenter l'indépendance entre les applications et le moniteur.
RTC, livré sous forme d'une EPROM, matérialise parfaitement le concept de composant
logiciel. L'un de ses atouts est son indépendance vis-à-vis des caractéristiques du matériel sur
lequel il s'implante. L'environnement matériel minimum peut être réduit à une carte contenant
un processeur, de la RAM et l'EPROM du noyau. Dans le cas de l'utilisation des fonctions de
temporisation, la présence d'une horloge temps réel est alors obligatoire.
Un autre des atouts de ce noyau réside dans sa remarquable compacité : pas plus de 3 Ko (quel
que soit le processeur utilisé) pour intégrer l'ensemble de ses fonctions, ce qui laisse
évidemment une grande liberté à l'application (en terme de place mémoire occupée).
Non classifié
Novembre 1999
Systèmes temps réels
22
SIGLES ET TERMINOLOGIE :
Sigles généraux :
ANSI
BIT
BSP
CII
EPROM
American National Standards Institute
Entité informatique binaire (0 ou 1)
Board Support Package (la partie logiciel dépendante de l'environnement du
processeur : matériel et mapping mémoire de la carte)
Compagnie Internationale pour l'Informatique
Erasable Programmable Read Only Memory
FAQ
Frequently Asked Questions (Foire Aux Questions ou Questions Fréquemment
posées)
FIFO
First In, First Out (premier arrivé, premier servi)
FTP
File Transfer Protocol
GNU
Gnu is Not Unix
HP
IEEE
I/O
IHM
IMSE
INRIA
IT
ISR
NFS
OS
PROM
Helwet-Packard
Institute of Electrical and Electronics Engineers
Input Output (entrée/sortie)
Interface Homme-Machine
Integrated Manufacturing Systems Engineering
Institut National de Recherche en Informatique et Automatique
interruption logicielle ou matérielle
Interrupt Service Routine ou Routine d'interruption
Network File System
Operating System
Program Read Only Memory
POSIX
Portable Operating System Interface for computer environments
QNAP
RAM
ROM
Queuing Network Analysis Package
Random Access memory (mémoire à accès aléatoire)
Read Only Memory (mémoire morte)
RPC
Remote Procedure Call
RSH
RS232
Remote SHell
liaison série au standard EIA-RS-232 (25 broches), adaptateur pour la transmission
asynchrone de données
Real Time
Structured Analysis for Real Time Systems
Standardisation du Cœur des Exécutifs des Produits Temps Réel Européens
Trivial File Transfer Protocol
RT
SA-RT
SCEPTRE
TFTP
Non classifié
Novembre 1999
Systèmes temps réels
TR
UC
23
Temps réel
Unité Centrale (microprocesseur)
Terminologie :
Cible
Le terme cible est employé pour désigner le support physique des
outillages
Coupleur
Carte d’entrées/sorties permettant de relier un bus externe
(DIGIBUS)
Evolution
L’évolution du logiciel comprend son portage et l’ajout/modification
de ses fonctions
Intégration logicielle
Une des phases du processus de développement logiciel définie par la
GAM-T-17. L’intégration a lieu avant la validation
Maître d'œuvre
Entité chargée du développement du produit
Maître d'ouvrage
Entité donneuse d'ordre de développement d’un produit
Message
Bloc fixe d’informations circulant sur le bus entre les abonnés du
réseau
Méthode
Une méthode impose un langage de modélisation qui oriente le
développement suivant une vision fonctionnelle et/ou dynamique
et/ou statique. Elle impose également un cycle de développement
(spirale, exploratoire, cycle en V...)
Portage
Le portage consiste à modifier et recompiler les fichiers sources d’un
logiciel en vue d’une exécution sur un système d'exploitation ou un
microprocesseur différent. La fonctionnalité du logiciel n’est pas
modifiée
Trame
Ensemble des messages circulant sur le bus à des fréquences
déterminées
Non classifié
Novembre 1999
Systèmes temps réels
24
BIBLIOGRAPHIE :
[DOR91] Dorseuil, Temps réel en milieu industriel, Dunod – janvier 1991
[HER98] Matthieu Herrb, Le système d'exploitation temps réel VxWorks, LASS-CNRS, avril
1998
[WRS01] Wind River Systems, VxWorks Programmer's guide 5.3.1, Edition 1, 4 mar. 1998
[WRS02] Wind River Systems, User's Guide : Tornado 1.0 (UNIX Version), February 1998
[DEI99] Patrick Deiber, Les processus légers (Threads), probatoire CNAM de Versailles,
février 1999
[MOT93] Motorola, M68000 8-/16-/32-Bit Microprocessors User’s Manual, Ninth Edition,
1993
[RTC87] GSI-TECSI, Realtime Craft, le composant logiciel, Description abrégée du
moniteur XEC, Paris, Mars 1987
[RIF93]
J.-M. Rifflet, La programmation sous UNIX, Ediscience, 1993.
Sites Internet :
http://www.realtime-magazine.com/
Magazine dédié au temps réel
http://www.wrs.com
Wind River Systems fournisseur du système temps réel
VxWorks et de son environnement Tornado.
http://www.edtn.com/embedsys
Embedded Developpers Journal
http://www.ec-lille.fr/~rdp/
Groupe Francophone sur les réseaux de pétri
http://www.tecsi.com/rtc/
Le système temps réel RealTime Craft (RTC) de Tecsi
news:comp.realtime
Forum électronique sur le temps réel, ainsi que les réponses
des questions fréquemment posées : Comp.realtime:
Frequently Asked Questions (FAQs)
http://www.faqs.org/faqs/realtimecomputing/faq/
news:comp.os.vxworks
Forum électronique sur le système VxWorks (The VxWorks
real-time operating system)
news:comp.arch.embedded
Forum électronique sur les architectures embarquées et sur
les systèmes à base de processeur Motorola 68000
news:comp.sys.m68k
Non classifié
Novembre 1999
Systèmes temps réels
25
GLOSSAIRE :
Bus : Dispositif destiné à assurer
simultanément
les
transferts
d'informations entre différents sousensembles d'un système informatique
selon des spécifications physiques et
logiques communes.
Cache : mémoire très rapide entre la
mémoire centrale et le processeur.
L'information est d'abord recherchée dans
la cache. L'accès à la mémoire cache est
moins coûteux qu'un accès à la mémoire
centrale.
Changement
de
contexte
(ou
commutation de contexte) : le fait de
passer d'un contexte à un autre. Le
changement de contexte engendre la
sauvegarde du contenu de la mémoire et le
chargement avec d'autres valeurs.
Contexte d'exécution : environnement
d'exécution d'un processus (registres,
zones mémoires…).
Contexte mémorisé : zone mémoire
propre à une tâche dans laquelle est stocké
le contexte d'exécution de la tâche,
lorsqu'elle n'est pas en cours d'exécution.
Deadlock (Interblocage) : phénomène qui
se produit lorsque deux processus
s'empêchent mutuellement d'accéder à une
ressource d'exécution.
Débogueur (debugger) : Programme
d'aide à l'élimination des défauts de
conception ou de réalisation se
manifestant par des anomalies de
fonctionnement.
Donnée (data) : Représentation d'une
information
sous
une
forme
conventionnelle destinée à faciliter son
traitement.
Élément binaire (bit = binary digit) :
Information représentée par un symbole à
Non classifié
deux valeurs généralement notées 0 et 1,
associées aux deux états d'un dispositif.
Exception : ce sont des exceptions du
processeur, qui sont soit des interruptions
matérielles, soit des "traps" logiciels. Les
exceptions provoquent des déroutements
de l'exécution courante du programme
vers des tâches immédiates. Pour une
description plus approfondie se référer à la
documentation du processeur.
Exécutif : Un exécutif regroupe
l'ensemble des traitements nécessaires à
l'exécution des activités opérationnelles
d'un programme.
Evénement : signal qu'une tâche transmet
à une autre tâche pour lui signifier que la
condition qu'elle attend est satisfaite.
Implanter : Installer un logiciel ou un
sous-système donné en réalisant les
adaptations
nécessaires
à
leur
fonctionnement dans un environnement
défini.
Implémenter : Réaliser la phase finale
d'élaboration d'un système qui permet au
matériel, aux logiciels et aux procédures
d'entrer en fonction. Note : Il convient de
ne pas utiliser le terme implémenter
comme synonyme d'implanter appliqué à
un logiciel.
Interruption matérielle : exception
provoquée par l'environnement matériel
(la carte ou le processeur lui-même).
Intervalle de temps (time-slice) :
intervalle de temps pendant lequel la
ressource d'exécution est attribuée à une
entité d'exécution.
Logiciel (software) : Ensemble des
programmes, procédés et règles, et
éventuellement de la documentation,
relatif au fonctionnement d'un ensemble
de traitement de données.
Novembre 1999
Systèmes temps réels
Mémoire morte (ROM, read only
memory) : Mémoire dont le contenu ne
peut être modifié en usage normal.
Mémoire vive (RAM, random access
memory) : Mémoire dont le contenu peut
être modifié en usage normal.
Numérique : Se dit, par opposition à
analogique, de la représentation de
données ou de grandeurs physiques au
moyen de caractères - des chiffres
généralement - et aussi des systèmes,
dispositifs ou procédés employant ce
mode de représentation discrète.
Octet : Ensemble ordonné de huit
éléments binaires traités comme un tout.
Un octet est souvent utilisé pour
représenter un caractère alphanumérique.
Lorsqu'une grandeur est exprimée en
multiples de l'octet, les symboles Ko, Mo
et Go représentent respectivement le
kilooctet, le mégaoctet et le gigaoctet.
Dans ce cas et contrairement à la norme,
on considère généralement que le kilooctet
est égal à 2^10 = 1 024 octets et non 1 000
et le mégaoctet à 2^20 et non 1 000 000.
Ordonnancement
(scheduling)
:
mécanisme de gestion des ressources
d'exécution entre plusieurs entités
exécutables.
Ordonnanceur : logiciel chargé d'assurer
que la tâche en cours d'exécution est
actuellement la tâche prête la plus
prioritaire.
Parallélisme : notion d'exécution de
plusieurs entités exécutables en même
temps.
Pointeur (pointer) : Donnée permettant
de retrouver l'adresse d'un groupe de
données.
Préemptible : "pouvoir" que possède une
entité
d'exécution
d'interrompre
l'exécution d'une entité de priorité plus
Non classifié
26
faible. La préemption est différente de
l'intervalle de temps (time-slice).
POSIX : groupe de travail sur la
définition de standard en matière de
système d'exploitation.
Processus (process) : souvent définit
comme "un programme en exécution",
parfois appelé tâche.
Remote Procedure Calls (RPC) : Les
RPC, appels de procédures à distance,
permettent aux programmes d'appeler des
procédures situées sur d'autres machines.
Le but des RPC est de cacher au client le
fait que l'appel va s'exécuter à distance.
Sémaphore : (Dijkstra) Permet de gérer
l'entrée en section critique. Un sémaphore
(semaphore) est une structure de données
composée d'un compteur entier et d'une
file d'attente gérée en FIFO. L'utilisation
d'un sémaphore se fait par les opérations P
(décrémentant le compteur) et V
(incrémentant le compteur). L'opération P
permet de demander l'accès à un élément
de ressources (demande de ticket).
L'opération V permet de libérer un
élément de ressource (restitution du
ticket).
Sockets : Les sockets permettent à deux
processus de communiquer de manière
bidirectionnelle sur deux machines
différentes. Il existe deux modes
d'utilisation des sockets : le mode non
connecté où l'émetteur doit toujours
spécifier l'adresse du destinataire (la
connexion n'est pas continue), et le mode
connecté où la connexion est tout le temps
établie.
Système
d'exploitation
(operating
system) : Un système d'exploitation définit
un environnement d'exécution comparable
à un exécutif multi-programmes et multiapplications, et un environnement de
production comprenant de interfaces, des
Novembre 1999
Systèmes temps réels
27
utilitaires, des outils de production de
logiciel…
elle s'exécute (contexte mémorisé) et de la
façon dont on la gère (priorité, état).
Système d'exploitation temps réel (real
time operating system) : Un système
d'exploitation est dit temps réel si son
environnement d'exécution est compatible
des besoins des systèmes temps réel. Il
doit pour cela répondre en des temps
bornés fixés pour des hypothèses de
fonctionnement, respecter le principe
édictant que si deux activités pouvant
utiliser les mêmes ressources de calcul et
de traitement sont éligibles pour
exécution, alors l'activité de plus faible
priorité ne peut s'exécuter au détriment de
l'activité de plus forte priorité.
Temps de commutation : temps
nécessaire
à
la
réalisation
d'un
changement de contexte.
Système temps réel : Un système temps
réel est un système dont les spécifications
contiennent des références directes ou
indirectes au temps réel. Les activités d'un
système temps réel sont caractérisées par
des contraintes temporelles (dates ou
délais d'activation, durée d'exécution,
etc…). Le comportement d'un système
temps réel est déterminé de façon à
satisfaire les contraintes temporelles de
ses activités lorsque les hypothèses de
fonctionnement sont observées, et à
minimiser une fonction globale de perte
dans le cas contraire.
Trap logiciel : exception provoquée par
l'exécution d'une instruction logicielle
spécifique du processeur ou par une erreur
d'exécution.
Tâche : agent actif responsable de
l'exécution d'un programme. Une tâche
possède un identificateur et des attributs
caractéristiques de la machine sur laquelle
Non classifié
Temps réel (realtime) : Mode de
traitement qui permet l'admission des
données à un instant quelconque et
l'obtention immédiate des résultats.
Test de performance (benchmark) :
Évaluation des performances d'un système
par simulation des conditions réelles
d'utilisation, à l'aide de programmeséchantillons.
Tubes (pipes) : Les tubes sont un moyen
de faire communiquer deux processus
UNIX situés sur la même machine. Ce
mécanisme crée un espace mémoire
partagée. Les tubes fonctionnent de
manière unidirectionnelle. Le mécanisme
de tube peut être également utilisé avec les
processus légers. L'accès au tube doit être
protégé, si ce dernier est utilisé par
plusieurs processus légers. Dans un
contexte réparti où deux processus sont
sur deux machines différentes, les tubes ne
peuvent pas être utilisés. Les sockets
résolvent ce problème.
Novembre 1999