Restructuration d applications Java Temps réel

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET
DE LA RECHERCHE SCIENTIFIQUE

Faculté des Ingénieurs
Département d’Informatique

MEMOIRE
d’Ingénieur d’Etat en Informatique
Option Matériels & logiciels

Restructuration d’Applications
Java Temps-Réel
Par

KAMEL MOUATS

INTRODUCTION

La décomposition d’un système temps réel résulte en une collection de processus,
chacun est responsable d’une portion spécifique de la tâche globale. La correspondance
entre les modules du logiciel et les entités du monde réel n’est souvent pas apparente à
partir de la structure du code. Ce qui rend difficile la compréhension et la maintenance
du code. De plus, traiter les systèmes temps réel comme étant des groupes de processus
contraints par le temps, oriente la conception vers une vue «événement - action»: les
événements sont générés par les entités du monde réel ou par les processus logiciel; les
actions doivent être effectuées par les processus logiciels en réponse temporelle à ces
événements.
Malheureusement, dans plusieurs systèmes temps réel, les événements discrets sont
des approximations d’activités réellement continues. Dans ces systèmes, les contraintes
de temps sont plus naturellement vues comme étant des contraintes de cohérences
temporelles d’information. Par exemple, dans plusieurs systèmes robotiques, l’interface
logicielle du manipulateur physique entraîne le manipulateur physique à lire
périodiquement son état et à émettre des commandes d’actionneurs. Le logiciel dans un
tel système, contient une image du manipulateur physique. Cette image doit être tenue
cohérente avec l’état courant du manipulateur physique, sinon le planificateur de
mouvements pourrait générer des plans de mouvements inappropriés. A
l’implémentation, cette contrainte de cohérence est transformée en contrainte de temps
de n unités de temps de périodes de scrutation.
De plus, dans la plupart des systèmes temps réel, une approximation de la
concurrence doit être faite par l’exécution de plusieurs processus sur des ressources
partagées. L’ordonnancement de l’exécution de ces processus est souvent basées sur les
temps d’exécution au pire des cas, obtenus au moyen de différentes techniques
d’estimation. Ceci pose le problème de réservation excessive des ressources, lorsque le
temps moyen d’utilisation s’éloigne des temps au pire des cas.

Le comportement temporel est une caractéristique de base pour les systèmes
informatiques où les programmes doivent être logiquement correct, en s’exécutant sans
erreurs de temps.
Les erreurs temporelles sont particulièrement produites quand on a un ensemble de tâches
provoquant un surcharge et un défaut dans l’ordre d’exécution, ce qui ramène le système à
une phase d’échec. Les développeurs remédient ces anomalies par des opérations
intensivement manuelles, telles que l’instrumentation, prise de mesure et éventuellement une
reconception complète du système. De telles opérations sont coûteuses, lentes et
incontrôlables.
Dans le but d’aider à prévenir une ordonnançabilité complète, une approche est adoptée,
et qui généralise les solutions précédentes à deux niveaux. Dans un premier, elle consiste,
pour la perspective d’ordonnancement, à restructurer une large classe de programmes temps
réel qui peut être complexe et contenant une collection de procédures. Dans un deuxième
niveau, la méthode de restructuration utilise le concept des tranches de programmes
(interprocéduraux) et un modèle de dépendance amélioré, permettant par la suite d’améliorer
l’ordonnançabilité d’un ensemble de tâches, soit par rendre leurs échéances flexibles, ou bien
par décomposition d’une ou de plusieurs tâches en sous tâches, de telle façon qu’on puisse
utiliser les méthodes d’ordonnancement généralisées, de priorités fixes, qui permettent
l’augmentation de l’ordonnançabilité d’un ensemble de tâches, à un niveau supérieur de celui
fourni par l’algorithme Rate-Monotonic.

1 Le Monde Des Systèmes Temps Réel 111

PARTIE 1:Système Temps Réel «Concepts & Conception»:

Objectif:

Ce chapitre a pour but d’introduire les systèmes temps réel. Il illustre certaines des
difficultés que l’on rencontre lorsque l’on implémente ce genre de système. Un système
temps réel est correct en fonction de ses résultats et du moment auwquel il les produit.
Les contraintes de temps et de ressources sont déterminantes pour le fonctionnement de
ces systèmes..

I- Introduction:
Au fur et à mesure que le prix sur le matériel diminue, on intègre des ordinateurs
dans de plus en plus de systèmes. Ces logiciels interagissent directement avec des
périphériques matériels, et leurs logiciels doivent pouvoir réagir suffisamment vite aux
événements dont le système assure le suivi et le contrôle. Du fait de ce besoin, pour le
logiciel, de répondre à des événements «temps réel», le système logiciel de contrôle a
été qualifié de système «temps réel». Un système temps réel consiste en un ensemble
d’entités contrôlées et un sous-système de contrôle. Ce dernier est formé d’un ensemble de
systèmes d’ordinateurs, tandis que les entités contrôlées peuvent être un large éventail de
systèmes à comportement mécanique ou tout dispositif, du simple mélangeur au robot
[Stankovic91]. Typiquement, le sous-système de contrôle exécute des programmes de
contrôle pour recevoir des données de l’environnement et/ou pour émettre des commandes
aux entités contrôlées [Chung95].
Un système temps réel (STR) est un système dédié à des applications spécifiques, en
particulier, les systèmes de contrôle. Des capteurs recueillent de l’information qu’ils
fournissent au calculateur(ordinateur). Ce dernier s’occupe de réaliser le contrôle désiré et
donne les résultats pour d’éventuelles interventions.
Les systèmes embarqués constituent un sous-ensemble de systèmes temps réel,
caractérisés par leur contrôle de systèmes mécaniques tels que les systèmes de contrôle
de bateaux, de véhicules, de machines à laver, etc.
Comme on a besoin de répondre à des événements qui arrivent à n’importe quel
moment, on doit organiser l’architecture d’un système temps réel de manière à pouvoir
transférer le contrôle au composant approprié dès la réception d’un événement. C’est
pourquoi, on conçoit le système comme un ensemble de processus parallèles, et qui
coopèrent entre eux. Une partie du système temps réel (quelquefois appelée exécutif
temps réel) est dédiée à la gestion de ces processus.

II-Définition d’un système temps réel:
Avant d’aller plus loin, il est utile d’essayer de définir la phrase: «Système Temps Réel»
(STR) avec plus de précision. Il y a une multitude d’interprétations de la nature exacte d’un
STR; cependant, elles ont tous en commun la notion du «temps de réponse (le temps
nécessaire pour qu’un système puisse générer des sorties à partir d’entrées associées). Le
«Oxford Dictionary of Computing» donne la définition suivante pour un STR: «C’est
n’importe quel système dans lequel le temps, au bout duquel la sortie est produite, est
significatif. C’est généralement dû au fait que l’entrée correspond à certains flux dans le
monde physique, et la sortie doit appartenir aux même flux. La différence entre le temps de
l’entrée et celui de la sortie doit être suffisamment petite pour avoir un temps de réponse
acceptable.»
Ici, le mot «temps de réponse» est pris dans le contexte du système total. Par exemple, dans
un système de contrôle de missiles téléguidées, la sortie est exigée dans quelques

1
1


millisecondes, cependant, dans les systèmes de contrôle d’assemblage de voitures, la réponse
peut être exigée seulement dans une seconde.
Young[1982] définit un STR comme suit: «C’est tout système ou activité de traitement
d’information qui doit répondre à une entrée stimulée, extérieurement générée, dans une
période finie et bien spécifique.»
Dans le sens le plus général, ces deux définitions couvrent une catégorie plus large d’activités
d’ordinateur. Par exemple, un système d’exploitation comme UNIX peut être considéré
comme un STR dans le cas où un utilisateur introduit une commande et il va attendre pour
(recevoir) une réponse dans quelques secondes. Heureusement, il n’est pas généralement
désastreux si la réponse n’est pas rapide.
Ces types de systèmes peuvent être distingués de ceux où la panne dans la réponse peut être
considérée aussi mauvaise qu’une réponse fausse. Bien entendu, c’est cet aspect qui distingue
un STR de ceux où le temps de réponse est important mais n’est pas crucial.
Par conséquent, la correction d’un STR ne dépend pas seulement de la logique des résultats
d’un calcul, mais de plus, du temps dans lequel les résultats sont produits.
Les praticiens dans le domaine de la conception des systèmes d’ordinateur à temps réel
distinguent généralement entre les STR hards(stricts) et les STR soft(relatifs).
Les STR hards sont ceux où il est absolument impératif que les réponses se produisent dans
un échéance spécifié.
Les STR softs sont ceux où les temps de réponse sont importants mais le système restera
fonctionner correctement si les échéances sont occasionnellement perdus.
Les systèmes softs peuvent être distingués par eux même des systèmes interactifs dans
lesquels il n’y a pas des échéances explicites.
Dans un STR soft ou hard, l’ordinateur a généralement une interface directe avec quelques
équipements physiques et il est orienté à contrôler ou à couvrir l’opération de ces
équipements.
Une caractéristique clé de toutes ces applications est le rôle de l’ordinateur comme un
composant de traitement d’information dans un système d’ingénierie large. Il est pour cette
raison que de telles applications sont reconnues comme des Systèmes Temps Réel.

III-Exemples de systèmes temps réel:

III-1-Contôle de processus:
La première utilisation d’un ordinateur comme un composant dans un système
d’ingénierie s’est faite à la fin de 1960 dans le contrôle des processus industriels.
Considérons l’exemple montré dans la figure I-1, où l’ordinateur effectue une seule activité:
c’est d’assurer le passage d’un flux de liquide donné dans un pipe par le biais d’une vanne. Si
on détecte une augmentation dans le flux, l’ordinateur doit répondre en alternant l’angle de la
vanne; cette réponse doit se produire dans un temps fini si le dispositif de réception en fin du
pipe ne se surchargera pas.

III-2-La production:
L’utilisation des ordinateurs dans la production est devenue essentielle de telle manière
qu’on puisse garder les coûts de la production minimaux avec amélioration de la productivité.
L’ordinateur coordonne entre une variété d’engins tels que des manipulateurs, machines à
outils, …etc.

III-3-Communication, commande et contrôle:
On peut citer comme exemple, la réservation de places sur avion, les centres médicaux
pour le suivi automatique des malades et la gestion des comptes bancaires.

2
2


Fluxmètre

Lecture du flux
d’entrée

Traitement vanne

Angle de la
vanne en sortie

Temps

Fig I-1: Système de contrôle d’un fluide

Tous ces systèmes se composent d’un ensemble d’agents (opérateurs) complexes, des
dispositifs de collection d’informations et de procédures administratives permettant de
supporter les décisions et fournissent la manière par laquelle ils peuvent être implémentés.
Il est évident que les dispositifs de saisie de l’information et les instruments demandés
pour implémenter les décisions sont distribués sur une zone géographique large.

III-4-Systèmes temps réel généralisés:
Dans chacun des exemples précédents, l’ordinateur a une interface directe avec les
équipements physique dans le monde réel. Afin de contrôler ces dispositifs du monde réel,
l’ordinateur aura besoin de consulter des dispositifs de prise de mesures à des intervalles de
temps réguliers, pour cette raison, une horloge de temps réel est exigée.
Généralement, il y a aussi une console d’opérateur permettant toute intervention
manuelle. Un agent doit rester informé de l’état du système par des unités de visualisation de
différents types.
Les changements d’état du système sont enregistrés dans une base d’information qui
peut être interrogée par les opérateurs (agents), ultérieurement, soit pour restaurer le contexte
du système, en cas d’un déséquilibre de son état, ou bien afin de fournir des informations
pour des besoins administratifs.
La structure d’un STR embarqué typique est représentée dans la figure I-2. Le logiciel
qui contrôle les opérations du système peut être conçu de manière modulaire reflétant la
nature physique de l’environnement. Généralement, on fera appel à un module contenant les
algorithmes nécessaires pour le contrôle physique des dispositifs, un deuxième responsable de
l’enregistrement des changements d’état, un troisième pour l’extraction et l’affichage de ces
changements et un dernier pour l’interaction avec l’opérateur.

IV- Caractéristiques des STR:
Un STR possède plusieurs caractéristiques spéciales (soit héritées ou imposées).
Cependant, tous les STR n’ont pas ces mêmes caractéristiques, mais tout langage à objectif

3
3


général, qui sera utilisé pour la programmation effective des STR, doit supporter, et
facilement ces caractéristiques.

IV-1-Taille et complexité:
Il est souvent constaté que la plupart des problèmes associés au développement des
logiciels sont ceux relatifs à la taille et la complexité. Ecrire de petits programmes présente un
problème non significatif, comme il peut être conçu, codé, maintenu et compris par une seule
personne. Si cette personne quitte la compagnie ou cette institution qui utilise ce logiciel, une
autre personne peut apprendre et comprendre ce programme en une durée relativement petite.
Malheureusement, tous les logiciels ne présentent cette caractéristique qu’on veut bien
l’atteindre et l’avoir.

Horloge Algorithmes pour Système
le contrôle digital interface d’ingénierie
Temps réel

Insertion de données Système de
(enrichissement) contrôle distant

Base de
données

Extraction de données Dispositifs
et affichage d’affichage

Console d’un
opérateur Interface opérateur

Real Time computer

Fig I-2:STR typique

Lehman et Belady[1985], dans une tentative de caractérisation des systèmes répandus,
rejettent la notion simple et intuitive, que la taille est simplement proportionnelle au nombre
d’instructions, lignes de code ou modules.
Par définition, les STR doivent répondre aux événements du monde réel. La variété
associée à ces événements doit être traitée attentivement.
Le coût de la reconception ou la réécriture du logiciel répondant aux exigences du
changement continu du monde réel est extrêmement important. De ce fait, les STR doivent
être extensibles pour faciliter leur maintenance et améliorer leur performance.

4
4


IV-2- Manipulation des nombres réels:
Un STR implique le contrôle d’un processus industriel manipulant des données. Ces
dernières servent de paramètres de prise de décision et d’intervention en cas de situations
anormales.

IV-3- Fiabilité et sécurité:
Les STR interviennent dans des situations critiques demandant le contrôle des
fonctionnalités. Une panne d’un système, impliquée dans le cas du transfert automatique
d’argent entre banques mènera à une perte de millions de dollars sans pouvoir les récupérer ;
un composant erroné dans la génération de l’électricité peut exposer la vie, dans une unité
sanitaire, à des dangers irrémédiables…etc.
Ces exemples dramatiques illustrent que l’ensemble du matériels et logiciels informatiques
doivent être fiables et protectifs. De ce fait, on a intérêt à concevoir et implémenter des
systèmes dont leur fonctionnement est suivi par un autre système de contrôle. De plus, dans le
cas où on exige une interaction avec un agent, on doit être prudent dans la conception de cette
interface afin de minimiser les effets de toute erreurs humaines qui peut survenir.

IV-4-Contrôle de la concurrence des composants séparés du système:
Un STR tente de composer des ordinateurs et des éléments externes coexistants, avec
lesquels, les programmes de l’ordinateur doivent interagir simultanément. Dans un cas
typique, le programme doit interagir avec un système d’ingénierie (qui se compose d’éléments
de fonctionnalités parallèles, telles que des robots, capteurs, actionneurs,…etc.) et les unités
d’affichage de l’ordinateur, la console de l’opérateur et l’horloge du temps réel.
Heureusement, la vitesse des ordinateurs nous donne l’impression qu’il s’agit d’un traitement
simultané. Cependant, dans d’autres situations, ce n’est pas le cas, par exemple, dans le cas où
les données doivent être rassemblées, traitées dans des sites géographiquement distribués, où
le temps de réponse d’un composant simple ne peut pas être déduit par un seul ordinateur.
Dans ces cas, il est nécessaire de considérer des STR distribués et multiprocesseurs.
Un problème majeur associé à la production de logiciels qui traitent la concurrence, c’est
comment exprimer la concurrence dans la structure des programmes.
Une des approche consiste à charger le programmeur pour construire son système qui
implique l’exécution cyclique d’une séquence de programmes manipulant différentes tâches
concurrentes. Notez que cette approche de développement n’est en aucun cas applicables vu
les raisons suivantes :
La complication de la tâche de l’utilisateur le met dans des considérations de structures
qui sont inadéquates pour le contrôle des tâches.
Les programmes résultants seront illisibles et non élégants.
Les programmes corrects deviennent difficiles.
La décomposition du problème sera compliquée.
Une réalisation difficile pour faire exécuter des programmes parallèles sur plus d’un seul
processeur.
La correction d’un code ayant des erreurs est plus problématique.

IV-5-Contrôle du temps réel:
Le temps de réponse est crucial dans tout STR. Malheureusement, il est très difficile de
concevoir et implémenter un système qui va garantir que la sortie appropriée se générera dans
les délais prescrits et sous toute condition possible.
La réalisation de tel système, en permettant une utilisation complète de toutes les ressources à
tout moment, est une tâche relativement impossible. Pour cette raison, les STR sont
généralement construits en utilisant des processeurs ayant des capacités partagées, afin de

5
5


s’assurer que le comportement, au pire des cas, ne produise aucun retard défavorable durant
les périodes critiques du fonctionnement du système.
En fournissant une puissance de traitement adéquate, en exigeant le support d’exécution, on
permettra au programmeur de :
Spécifier les temps dans lesquels les actions doivent être accomplies.
Spécifier les temps dans lesquels les actions doivent se terminer.
Répondre à des situations où les exigences temporelles se changent de manière
dynamique.

IV-6-Interaction avec les interfaces du matériel:
La nature des STR exige que les composants de l’ordinateur doivent interagir avec le
monde extérieur. Ils ont besoin de capteurs et actionneurs pour une large gamme de dispositifs
du monde réel. Ces dispositifs interagissent avec l’ordinateur via des registres
d’entrées/sorties. Les dispositifs peuvent générer des interruptions afin de signaler au
processeur que certaines opérations sont accomplies ou qu’il y avait des erreurs qui se sont
produites.
De nos jours, vu la variété des dispositifs et la nature du temps critique de leurs interactions
associées, leur contrôle doit être direct et non pas à travers les fonctions du système
d’exploitation.

IV-7-Implémentation efficiente:
Vu la nécessité du traitement du temps critique dans les STR, l’implémentation
efficiente (de haute qualité, efficace …) de ces systèmes devient de plus en plus nécessaire et
importante. Il est intéressant que l’un des bénéfices majeurs de l’utilisation d’un langage de
haut niveau est qu’il permet au programmeur de réaliser une implémentation abstraite loin de
tout détail, en se concentrant sur la résolution du problème. Le programmeur doit toujours être
concerné par le coût de l’utilisation de caractéristiques particulières d’un langage. Par
exemple, si la réponse à quelques entrées doit apparaître au bout d’une micro-seconde, ce
n’est plus la peine d’aller utiliser un langage dont l’exécution prend une milli-seconde.

V-Spécification des besoins:
Tout projet informatique doit impérativement commencer par une description
informelle des objectifs à atteindre. Cela devra être suivi par une analyse des besoins. C’est à
ce stade que la fonctionnalité du système est définie. Dans le terme de «facteurs spécifiques
temps réels», le comportement temporel du système doit être explicite, tout comme les
besoins en fiabilité et comportementaux du logiciel en cas où une panne d’un composant
survienne. De plus, cette phase définit quels sont les tests d’acceptante à appliquer au logiciel.
Il est de plus nécessaire de construire un modèle de l’environnement de l’application. C’est
une caractéristique des STR qu’ils ont des interactions importantes avec leur environnement.
Après la phase d’analyse vient celle de la concrétisation de la spécification des besoins. C’est
à partir de cette étape qu’apparaît la conception. C’est une phase critique dans le cycle de vie
d’un logiciel passant à un niveau plus élevé dans la mise au point du STR.

VI-Motivations de conception:
Dans cette section, nous synthétisons les différentes étapes de conception de
systèmes temps réel. Ces étapes se basent sur des paramètres de qualité de service
[IEEE97] et elles doivent prendre en compte les besoins d’évolution et donc de la
maintenance.
Dans un système intégré à grande échelle, l’une des étapes du processus de
conception consiste à concevoir les systèmes, et à partager les fonctions entre matériel et

6
6


logiciel. On peut considérer que le processus de conception des systèmes intégrés suit
une série d’étapes:
(1) Identifier les événements que le système doit traiter et les réactions associées.
(2) Identifier les contraintes de temps à appliquer à chaque événement, ainsi qu’à la
réponse qui lui est associée.
(3) Regrouper le traitement des événements et des réactions dans différents processus
parallèles. Un bon modèle d’architecture consiste à associer un processus à chaque
classe d’événement et à chaque classe de réaction, comme dans la figure I-2. Pour
chaque événement et chaque réaction, concevoir les algorithmes qui effectueront le
traitement nécessaire. On doit développer la conception des algorithmes à ce stade
afin d’avoir une idée du temps de traitement nécessaire.
(4) Concevoir un système d’ordonnancement qui permettra de démarrer chaque
processus au moment opportun afin qu’il puisse effectuer son traitement dans des
contraintes de temps données.
(5) Intégrer le système avec un exécutif temps réel.
Naturellement, c’est un processus itératif [William96, gestion des itérations
Computer97]. Une fois qu’il a établi l’architecture (découpage en processus) et choisi la
stratégie d’ordonnancement, le concepteur doit effectuer des estimations et des
simulations complètes du système pour vérifier qu’il respectera ses contraintes de temps.

Contrôleur du
Capteur Capteur

Réponse
Traitement des
Données

Actionneur Contrôle de
l’Actionneur

Fig.I.3 Architecture d’un système de contrôle

Dans beaucoup de cas, ces simulations vont révéler des défauts de comportement
du système. L’architecture, ou l’ordonnancement, ou l’exécutif, ou les trois à la fois
devront être reconçus afin de pouvoir «tenir» les contraintes de temps. Il est difficile
d’estimer le temps d’exécution d’un système temps réel. Du fait de la nature
imprévisible des événements apériodiques, les concepteurs doivent faire des hypothèses
sur la probabilité pour qu’ils apparaissent (et donc demandent un service) à un instant
donné. Ces hypothèses peuvent s’avérer incorrectes et les performances du système
délivré ne seront pas suffisantes. Dasarathy [DAS85] traite de la validation des temps
d’exécution.
Du fait que les processus d’un système temps réel doivent coopérer, le concepteur doit
coordonner les communications entre processus. Les mécanismes de coordination des

7
7


processus assurent l’exclusion mutuelle lors de l’accès à des ressources partagées. Lorsqu’un
processus est en train de modifier une ressource partagée, les autres processus ne peuvent pas
en faire de même. Parmi les mécanismes d’exclusion mutuelle on trouve les sémaphores, les
moniteurs et les régions critiques.
Le langage choisi pour l’implémentation de systèmes temps réel peut avoir lui aussi une
influence sur la conception. Ada [Taft92] a été conçu à l’origine, pour implémenter des
systèmes intégrés, et il dispose de caractéristiques comme la gestion des tâches, les exceptions
et les clauses de représentation. La notion de rendez-vous représente un bon mécanisme pour
la synchronisation des tâches. Malheureusement, ce mécanisme n’est pas adapté à
l’implémentation de systèmes temps réel durs.
Les systèmes temps réel durs sont souvent écrits en assembleur pour pouvoir tenir les
contraintes de temps. Parmi les autres langages, on trouve des langages de niveau système
comme C. Ils nécessitent un noyau d’exécution supplémentaire pour gérer le parallélisme.

Afin de pouvoir gérer le développement des STR complexes, deux approches
complémentaires sont souvent utilisées: décomposition et abstraction. Toutes les deux
forment des concepts de base des méthodes de génie logiciel.
La décomposition, comme son nom l’indique, implique le partitionnement systématique d’un
système complexe en parties plus fines jusqu’à ce qu’on puisse isoler ses composants, afin de
pouvoir les gérer de manière décentralisée. A chaque niveau de décomposition, on fait
correspondre un autre niveau de description et une méthode de documentation de cette
description.
L’abstraction permet de considérer les détails et les particularités concernant
l’implémentation. Cela permet de simplifier la vision en vers le système et les objectifs à
atteindre en gardant ses propriétés et caractéristiques.

VI-1-Encapsulation:
La conception hiérarchique d’un logiciel permet la spécification et le développement
des sous-composants d’un programme. Le besoin à l’abstraction implique que ces sous-
composants doivent être bien définis en terme de rôle, clairs et avoir des interconnexions et
interfaces non-ambigües. Si la spécification entière du système logiciel peut être vérifiée
seulement en terme de spécification des sous-composants immédiats, alors la décomposition
est dite compositionnelle. C’est une propriété importante quand on veut analyser
formellement les programmes.
Les programmes séquentiels sont particulièrement amenés à des méthodes compositionnelles
et un nombre de techniques sont utilisées pour encapsuler et représenter les sous-composants.

VI-2-Cohésion et couplage:
Les deux formes d’encapsulation discutées dans la section précédante nous amène à
l’utilisation de modules avec des interfaces bien définies (et abstraites). Mais comment un
grand système peut être décomposé en modules? La réponse est liée aux méthodes de
décomposition des logiciels. Cependant, avant de discuter ces méthodes, il est approprié de
considérer des principes plus généraux nous permettant une bonne encapsulation.
Cohésion et couplage sont deux parmi les métriques décrivant les relations entre les modules.
La cohésion est liée à la bonne concordance entre les modules.
Allworth & Zobel[1987] donnent six mesures de cohésion:
1. Coïncidence: les éléments du module ne sont pas liés autre que dans un contexte très
superficiel.
2. Logique: les éléments du module appartiennent à la même famille, en terme de vision
globale du système, mais non pas en ce qui concerne l’application (logiciel) en cours.

8
8


3. Temporel: les éléments du module sont exécutés à des temps similaires.
4. Procédural: les éléments du module sont utilisés ensembles dans la même section du
programme.
5. Communication: les éléments du module travaillent sur la même structure de données.
6. Fonctionnel: les éléments du module travaillent en collaboration afin de contribuer à la
performance d’une seule fonction du système.
Le couplage, par comparaison, est une mesure d’interdépendance des modules du
programmes. Deux modules ont un couplage fort s’ils échangent entre eux des informations
de contrôle. Par contre, ils perdent le couplage si les modules ne communiquent que des
données. Une autre façon de voir le couplage est de considérer la facilité de changer un
module (d’un système complet ) et le remplacer par un autre.
Dans toutes les méthodes de conception, la meilleure, et celle ayant une bonne décomposition,
vérifie une forte cohésion et un couplage minimum.
Ce principe est également vrai dans les domaines de la programmation séquentielle et
concurrente.

VI-3-Approches formelles:
Elle consiste à modéliser le comportement des systèmes concurrents par l’utilisation des
réseaux Petri [Brauer 1980]. Vue la variété des représentations obtenues, on introduit, dans le
processus de modélisation, le concept des réseaux de transition prédicatives.
La notion CSP (Communicating Sequential Processes) est développée, permettant la
spécification et l’analyse des systèmes concurrents.
Une logique temporelle (extension de la logique des prédicats et propositionnelle) a été
introduite avec de nouveaux opérateurs afin de pouvoir exprimer les propriétés temporelles.

VII-Méthodes de conception:
L’industrie du temps réel utilise des méthodes structurées et les approches du génie
logiciel pour la mise en œuvre des STR, vu que ces techniques sont applicables à tous les
systèmes de traitement d’information. Ces méthodes ne fournissent pas un support spécifique
au domaine du temps réel, et ils manquent en richesse voulue quand on épuise toutes les
potentialités des langages d’implémentation utilisés.
Typiquement, une méthode de conception structurée utilise un diagramme, dans lequel des
arcs orientés schématisent le flux de données à travers le système, et les nœuds désignés
représentent les sites dans lesquels les données sont transformées et donc traitées.
Dans la littérature, on trouve les méthodes JSD (Jackson’s System Development), Mascot3 et
PAMELA.
Dans la méthode JSD, on utilise une notation pour la spécification et l’implémentation
(conception détaillée). Bien entendu, l’implémentation n’est pas seulement une description
détaillée de la spécification, mais de plus, elle est le résultat de l’application de
transformations à cette dernière afin d’améliorer l’efficience.
La méthode est basée sur un graphe comportant des processus et un réseau de connexions.
Les processus sont de trois catégories:
1. Processus d’entrée: détectant les actions dans l’environnement en les faisant passer au
système.
2. Processus de sorti : passant les réponses du système à l’environnement.
3. Processus internes.
Les processus peuvent être liés de deux manières différentes:
1. Par des connexions asynchrones de blocs de données qui sont sauvegardées.
2. Par des connexions de vecteurs d’état (ou inspection).

9
9


Une connexion du vecteur d’état permet à un processus de connaître l’état interne d’un autre
processus sans avoir besoin de transfert d’information.
Notez que la structure de graphe adoptée vise à représenter l’architecture du système.
Malheureusement, JSD n’a pas une technique standard pour incorporer les contraintes de
temps. De ce fait, on doit rajouter des dénotations aux diagrammes.
Evidemment, JSD fournit une expression de la conception et non pas une conception.
La conception incorpore inévitablement l’expérience et la créativité du concepteur.
Il est souvent dit que les méthodes structurées et formelles sont orientées enrichissement de la
créativité! Ce n’est pas vrai. Ces techniques offrent une notation bien claire et comprise de
l’expression de la conception, et un moyen pour la vérification du bon placement de l’idée
adoptée, de ce fait, la conception a besoin de la spécification, et le logiciel implémente cette
conception.
Le point le plus important dans une conception JSD est le flux de données. Une bonne
conception est celle qui intègre ce flux naturel. L’avantage de ce flux de données est qu’il
permet l’expression des contraintes de temps comme étant des attributs de données circulant
dans le système.
Une interruption génère un signal de contrôle ; le signal de contrôle est une transformation de
l’interruption. Ces transformations sont prises dans des processus en consommant du temps.
Un choix approprié des processus va générer des échéances très visibles qui peuvent être
ordonnancées.
Une fois la conception est obtenue, son implémentation doit être effectuée de manière
systématique. Avec un modèle de concurrence basé message, dans le langage de
l’implémentation, ce sera une tâche relativement facile, tout comme les processus de
conception et les flux de données bufferisés qui peuvent être codés sous la forme de processus
de programme. Malheureusement, cela peut produire une prolifération des processus et une
implémentation anarchique.
Afin de remédier à ces problèmes, on peut procéder de deux manières :
1. Transformation de la conception de telle sorte qu’on aura besoin d’un minimum que
possible de processus.
2. Obtention d’un programme de processus excessif et le transformer afin de réduire le
nombre d’objets concurrents.
La méthode JSD est une transformation qui consiste à remplacer le processus de conception
par une procédure avec un seul processus d’ordonnancement, contrôlant l’exécution d’une
collection de ces procédures. De plus, les contraintes de temps provoque un problème majeur,
qui est la difficulté de préserver les durées.
En dépit de tout cela, la méthode JSD est appliquée avec succès dans les STR les plus
complexes.

La méthode Mascot a été développée pour la conception, construction et exécution des
applications temps réel. Les descriptions de Mascot doivent contenir:
Les sous-systèmes.
IDAs (general Intercommunication Data Areas) .
Les processus.
Des canaux (un IDA se comportant comme un buffer).
Des poules (un IDA véhiculant et repositionnant l’information).
Des serveurs (un élément de conception communicant avec les dispositifs du matériel
externe).

10
10


VIII-Implémentation:
Le langage de programmation est une interface importante et primordiale entre la
spécification des besoins et l’exécution du code machine. La conception d’un langage reste un
domaine de recherche actif. Malgré le passage naturel de la conception des systèmes vers
l’implémentation, les possibilités expressives des langages récents ne sont pas liées aux
méthodologies de conception adoptées. Cette adoption poursuit logiquement l’étape de
compréhension prévisible de l’étape d’implémentation.
Il est possible d’identifier trois classes de langages de programmation qui sont utilisées dans
le développement des systèmes temps réels. Ces langages sont: le langage d’assemblage, les
langages d’implémentation séquentielle des systèmes et les langages concurrents de haut
niveau.

IX-Critères da base d’un langage de conception:
Un langage de programmation des STR peut être conçu seulement pour répondre aux
besoins du système. Cependant, il est rarement limité à cette fin.
La plupart des langages temps réel sont aussi utilisés comme des langages d’implémentation
des systèmes à objectifs généraux, pour des applications spéciales telles que les compilateurs
et les systèmes d’exploitation.
Young[1982] liste les six critères de base d’un langage de conception temps réel:
1. La sécurité: la sécurité, dans la conception d’un langage, mesure la possibilité de détecter
des erreurs de programmation, d’une manière automatique, par le compilateur ou par le
support d’exécution. Evidemment, il y a une limite pour les types et nombres d’erreurs
que le système du langage peut détecter.
L a sécurité implique la possibilité de:
Détecter facilement des erreurs et très tôt durant le développement du programme, et
par conséquent, une réduction dans le coût de la correction et la maintenance.
Avoir une compilation facile ne provoquant aucune extension au temps, donc le
programme peut être exécuté autant de fois qu’on le compile.
L’inconvénient de la sécurité est la complication dans sa mise au point, dans le cas d’un
langage complexe, ce qui implique un surcoût dans le temps de la compilation et
l’exécution.
2. La lisibilité: la lisibilité d’un langage dépend d’une multitude de facteurs concernant le
choix des mots clés appropriés, la possibilité de définir des types et la facilité de
modulariser un programme. De ce fait, on offre un langage avec une clarté suffisante,
permettant d’assimiler les principaux concepts d’opérations d’un programme particulier
par une simple lecture du texte du programme.
Une meilleure lisibilité implique:
La réduction des coûts de la documentation.
Une meilleure sécurité.
Une bonne et parfaite maintenabilité.
3. La flexibilité: un langage doit être suffisamment flexible, permettant au programmeur
d’exprimer toutes les opérations demandées d’une manière cohérente et graphique.
4. La simplicité: la simplicité possède les avantages suivants:
Minimisation de l’effort exigé pour produire les compilateurs.
Réduction du coût associé à l’apprentissage du programmeur.
Diminution de la possibilité de commettre des erreurs de programmation.
5. La portabilité: un programme doit être indépendant du matériel de l’exécution. pour un
STR, cela est difficile à réaliser, car c’est comme si on va remplacer une partie du
programme par une autre, ce qui implique des manipulations de ressources matérielles.

11
11


Cependant, un programme doit être capable d’isoler les parties d’un programme
dépendantes de la machine de celles qui sont indépendantes.
6. L’efficience: dans un STR, les temps de réponse doivent être garantis. De ce fait, le
langage doit être efficient. On doit, par conséquent, éliminer tout mécanisme provoquant
une extension dans le temps.

X-Langages de programmation des systèmes temps réel:
L’implémentation d’une application temps réel est étroitement liée au choix du langage
de programmation, les facilités et les avantages dont il dispose.
On a pu identifier trois classes de langage de programmation utilisés dans le
développement des STR qu’on va les présenter.

X-1-Les langages d’assemblage:
Initialement, la plupart des STR ont été programmés dans le langage d’assemblage, à
cause du manque du support des langages de haut niveau sur les ordinateurs, et le langage
d’assemblage qui semblait être le seul moyen réalisant des implémentations efficaces,
permettant l’accès et la manipulation des ressources matérielles.
Le problème majeur, avec l’utilisation des langages d’assemblage, est qu’ils sont orientés
machine, au lieu que ça soit orienté problème. Le programmeur peut être gêné par des détails
qui n’ont aucun rapport avec la programmation de ses algorithmes, ou même, par l’obscurité
des algorithmes eux même. Par conséquent, les coûts des développements restent élevés, et
les programmes seront difficilement, ou même inefficacement modifiés, et ceci à l’intention
de corriger des erreurs ou améliorer les performances.
D’autre part, l’absence de la portabilité oblige les programmeurs à réécrire tout programme,
en vu de le transférer d’une machine à une autre. De plus, une formation, bien complète, est
exigée pour tous ceux qui sont concernés par l’utilisation et la programmation en langage
d’assemblage.

X-2-Langages séquentiels d’implémentation des systèmes:
L’apparition d’ordinateurs puissants et la progression dans la technologie des
compilateurs ont rendu l’écriture des logiciels temps réel plus avantageuse. On a pu constater
le développement de plusieurs langages, spécialement conçus pour la programmation des
systèmes embarqués. Ces langages ont en commun la propriété qu’ils sont séquentiels. De
plus, ils n’offrent pas aux STR le bon contrôle du temps réel ni la fiabilité adéquate.

X-3-Langages de programmation concurrents de haut niveau:
Le langage de programmation Modula, développé par Wirth, a prouvé beaucoup de
qualités pour la programmation et l’exploitation des dispositifs de la machine. Plusieurs
expériences, basées sur l’implémentation en Modula et son utilisation, sont arrivées à
Modula-2, un langage d’implémentation de systèmes généraux.
De nouveaux langages apparaissent, tels que PERL, utilisés intensivement pour les
applications de contrôle de processus, Mesa (Xerox Corporation 1985), utilisé par Xerox,
dans ses bureaux, et CHILL qui a été développé afin de répondre aux besoins du CCITT dans
les applications de télécommunication.
Tous ces langages, et autres, sont destinés pour le développement des systèmes temps réel
embarqués.
Le langage Occam, apparu récemment et ses propriétés diverses, avait un rôle important dans
l’apparition du domaine des applications embarquées couplées et distribuées.

12
12


XI- Analyse des Contraintes de Tâches:
Un modèle de tâches temps réel permet de spécifier l’architecture fonctionnelle
d’un système temps réel. Chaque tâche est définie par un ensemble d’attributs décrivant
les contraintes auxquelles elle est soumise.
Traditionnellement, les applications temps réel étaient souvent décrites par le
modèle des tâches périodiques [Liu73]. Ce modèle décrit une application temps réel par
un ensemble fini (appelé aussi configuration) de tâches périodiques. Une variante de ce
modèle consiste à prendre en compte les tâches apériodiques. Dans ce modèle, toutes les
tâches doivent s’exécuter jusqu’à leurs fins. Cependant, pour des besoins nouveaux des
systèmes temps réel, certaines tâches n’ont pas la contrainte de terminer nécessairement
leur exécution. Ce qui a donné naissance à deux nouveaux types de modèles: le modèle
des tâches incrémentales et le modèle des tâches à résultats imprécis.
Diverses variantes de ces modèles ont été développées. Certaines d’entre elles sont
le résultat d’intégration des modèles existants. D’autres traitent des contraintes de type
ressources ou synchronisation.

XI-1-Contraintes de temps:
La plupart des contraintes de temps sont celles introduites par les modèles de
tâches périodiques et apériodiques. Ces deux types de modèles sont souvent utilisés en
temps réel. En effet, un système temps réel est souvent concerné par le contrôle d’un
comportement continu (procédé) qui nécessite des actions répétitives (tâches
périodiques) ou aléatoires (apériodiques).
Il existe trois types de tâches temps réel qui sont conçues pour superviser et
contrôler les différentes fonctions: Les tâches périodiques, sporadiques et apériodiques
[Klein94].
Les tâches périodiques sont les plus souvent trouvées dans les systèmes temps réel.
Afin de superviser un système physique ou un processus, le système d’ordinateur doit
capter régulièrement des informations sur le processus et réagir quand des résultats
appropriés sont obtenus ou des informations spécifiques sont lues. Cet échantillonnage
régulier d’informations est effectué par la tâche périodique par une série continue
d’invocations régulières, commençant par une invocation initiale à un certain temps I.
Les invocations se produisent périodiquement toutes les T unités de temps. Chacune de
ces invocation possède un temps d’exécution de C unités qui peut être déterministe ou
stochastique. C indique souvent la borne maximale (ou le pire des cas) du temps
d’exécution.
Chaque invocation de tâche aura une contrainte de temps explicite, appelé
l’échéance qui signifie que l’invocation doit se terminer avant un certain temps D après
son passage à l’état prêt. Ainsi, la première invocation doit se terminer dans le temps
I+D, la deuxième dans I+T+D, etc.
Les tâches périodiques sont habituellement invoquées par les temporisateurs
internes avec une périodicité choisie telle qu’elle assure une latence suffisamment courte
pour réagir aux événements de changement dans l’environnement en question.
Les tâches sporadiques et apériodiques sont invoquées à des intervalles irréguliers.
La tâche sporadique possède une échéance stricte (hard) et une borne sur l’intervalle
séparant deux invocations. La tâche apériodique peut s’effectuer avec un intervalle
aléatoire qui sépare deux invocations.
Par ailleurs, un processus est une séquence d’opérations qui doivent être exécutées
dans un ordre prescrit [Xu93]. Les processus peuvent être divisés en deux catégories: les
tâches de la première catégorie ont une échéance «stricte» (hard), c’est-à-dire que la
satisfaction de ses échéances est critique pour le fonctionnement du système, celles de la

13
13


deuxième catégorie ont des échéances «relatives» (soft), en ce sens que bien qu’un court
temps de réponse est souhaitable, un dépassement occasionnel de l’échéance peut être
toléré.

XI-2-Contraintes d’importance:
Les tâches d’une application temps réel ne sont pas toutes aussi importantes les unes que
les autres. En effet, du point de vue du concepteur d’une application, une tâche peut être
plus importante qu’une autre. Cette caractéristique de la tâche est déterminée par des
paramètres (poids, degré d’urgence, priorité externe, tâche critique, etc.). L’échec d’une
tâche critique peut entraîner l’arrêt d’exécution du système, situation qui peut être
catastrophique. Par exemple, dans un système de contrôle de vol, le concepteur de
l’application peut associer un poids fort à la tâche qui contrôle la stabilité de l’avion,
afin de refléter sa nature critique. Si cette tâche échoue dans le respect de son échéance,
l’avion peut s’écraser. Par contre, il accorde un faible poids à la tâche qui contrôle
l’enregistreur de vol.

XI-3-Contrainte d’interruption
Cette contrainte permet d’exprimer si une tâche est interruptible ou non. Par
exemple, dans un système temps réel réparti, une tâche qui ne fait que du calcul interne,
peut être interrompue. Par contre, la tâche chargée de l’émission d’une trame ne peut
être interrompue et elle doit se terminer. Si son émission est interrompue, elle doit la
recommencer complètement. Une tâche interruptible peut être interrompue par une autre
tâche prioritaire. Son exécution peut être reprise ultérieurement. Lorsqu’une tâche est
interrompue, elle peut être forcée de libérer temporairement les ressources qu’elle a
acquises.

XI-4-Contrainte de terminaison
Dans des conditions de surcharge, certaines applications temps réel se contentent
d’exécuter quelques tâches partiellement. De telles applications peuvent se contenter de
résultats acceptables. La contrainte de terminaison ont été prises en compte dans les
modèles de tâches incrémentales et les modèles de tâches à résultats imprécis.

XI-5-Contraintes événementielles:
Un événement peut démarrer certaines tâches et/ou terminer d’autres. Les
conditions d’activation/terminaison de tâches peuvent être décrites par une combinaison
d’opérateurs de la logique temporelle (avant, après, etc.) [Chung95, Sahraoui85] avec
des arguments qui sont (une date, un changement d’état, une expiration d’un délai, etc.).
Activation/terminaison d’une tâche peut être utilisé aussi bien pour décrire des
contraintes temporelles que des contraintes décrivant son interaction avec d’autres
tâches.
Comme ces contraintes peuvent exprimer d’autres situations (autres que les contraintes
de temps), cela justifie de les considérer indépendamment et dans la partie des
contraintes intrinsèques à une tâche.

XI-6-Les contraintes extrinsèques:
Les contraintes extrinsèques à une tâche décrivant les contraintes résultant de son
interaction avec d’autres tâches. Au cours de leur exécution, les tâches ne sont pas
indépendantes les unes des autres (relations de coopérations, relations de compétition,
etc.). Les relations de coopération indiquent l’existence d’un ordre d’exécution, de

14
14


synchronisation, de communication, etc. Les relations de compétition indiquent la
manière avec laquelle les tâches utilisent des ressources partagées.
Généralement, dans les applications informatiques, la mise en œuvre des
contraintes de coopération et de compétition est réalisée par des mécanismes de
synchronisation (rendez-vous, moniteur,…), d’exclusion mutuelle (sémaphores,…), de
communication (boites aux lettres,…), et bien d’autres.

XI-7-Contraintes d’accès aux ressources:
Les tâches utilisent des ressources disponibles en nombre limité pour lesquelles
elles entrent en compétition. La bonne utilisation des ressources partagées se traduit par
l’existence de contraintes de ressources. Parmi les contraintes de ressources on peut
distinguer les contraintes liées à leur utilisation et celles liées à leur fonctionnement.
Une ressource est dite non préemptible (telle qu’une imprimante) si elle ne peut
être retirée à une tâche Ti au profit d’une autre tâche sans qu’il y ait avortement de la
tâche Ti; une ressource est dite consommable (telle qu’un missile dans une application
militaire) si après son utilisation par une tâche, elle est consommée et donc n’existe
plus, etc.
Parmi les exemples des contraintes liées au fonctionnement des ressources, on peut
citer [Liu94]: la durée d’acquisition d’une ressource, la durée de restitution d’une
ressource et la durée de commutation de contexte. La durée d’acquisition de ressources
est la durée maximale qui peut être prise en compte par une tâche afin d’acquérir une
ressource oisive due aux propriétés de la ressource elle même. La durée de restitution
d’une ressource est la durée maximale séparant l’instant où une tâche libère la ressource
et l’instant où la ressource n’est plus dans le contexte de la tâche et donc disponible pour
d’autres tâches. La durée de commutation de contexte est la durée nécessaire pour
commuter une ressource d’une tâche à une autre, généralement suite à une interruption
de la première tâche par la seconde. Dans plusieurs cas, la durée de commutation de
contexte d’une tâche est égale à la somme de durée d’acquisition et de la durée de
restitution de ressource. Cependant, ceci n’est pas toujours le cas. En effet, dans le cas
par exemple d’un seul processeur, les informations de gestion de ce dernier telles que les
contenus de registres, nécessitant d’être sauvegardées et restaurées durant une
commutation de contexte et pas pendant l’acquisition ou la restitution.
Les contraintes d’accès de ressources associées à une tâche, indiquent, d’une part,
le type de ressources indispensables à son exécution, et d’autres part, le mode d’accès
(exclusif, partagé, etc.) qu’exige la tâche sur les ressources. Pour ce dernier cas,
l’expression de telles contraintes est nécessaire pour décrire les situations où la tâche
désire un accès en exclusion mutuelle sur une ressource à n points d’accès. En
environnement temps réel, la connaissance des contraintes de ressources par
l’algorithme d’ordonnancement est nécessaire pour qu’il puisse effectuer
l’ordonnancement des tâches qui les utilisent et réaliser leur gestion dans le cas où la
gestion de ressources est une fonction de l’ordonnanceur.

XI-8-Contraintes de placement:
Le besoin d’expression de contraintes de placement est spécifique aux systèmes
centralisés multiprocesseurs ou répartis. En effet, une tâche peut exiger que son
exécution se fasse sur un certain processeur (pour des raisons de compatibilité du code
exécutable par exemple) ou sur un site donné (parce qu’elle fait des entrées/sorties sur
un dispositif particulier, par exemple).

15
15


XI-9-Contraintes de tolérance aux fautes:
En environnement temps réel, les contraintes de tolérance aux fautes, associées aux
tâches, sont capitales pour exiger que le respect de leur contraintes temporelles soit
vérifié, ceci même en présence de fautes liées aussi bien au système d’exploitation, à
l’exécution des tâches, qu’au matériel (ordinateur, réseaux de communication, etc.).

XII- Architectures Temps Réel:
Dans la plupart des architectures de contrôle, la façon de partager les rôles de
prises de décision nous révèle la manière de fonctionnement des architectures. Les rôles
des différents aspects du problème de contrôle sont souvent partagés à travers les
modules. Un rôle est constitué d’un ensemble de responsabilités homogènes conçues
dans la perspective d’un objectif déterminé. On affecte à chaque module un ou plusieurs
rôles. Les modules sont souvent interdépendants dans la perspective de réaliser leurs
propres objectifs ou ceux du système global. Ces dépendances sont habituellement
établies à travers des communications clairement définies entre les modules. Le type de
communication entre les modules et les types de rôles affectés aux modules, ont un
impact significatif sur la façon d’interaction du système avec son environnement.
Le rôle de prise de décision dans un système temps réel peut être partagé comme
étant une décomposition soigneusement ordonnée de tâches d’un côté, et une étroite
coopération entre ces tâches d’un autre côté. Le premier cas est souvent considéré
comme une forme de contrôle centralisé, le second est un contrôle décentralisé.

XII-1 Architecture centralisée:
Dans ce type d’architecture, le système est constitué d’une seule unité de
traitement, composée d’un ou de plusieurs processeurs se partageant une mémoire
commune. La principale caractéristique d’une telle installation, par rapport à la suivante,
est que la durée de transmission de l’information d’une tâche à une autre est négligeable
devant le temps qui s’écoule entre deux transitions d’états (points observables). Cette
unité de traitement est reliée par des interfaces à une série de capteurs et d’actionneurs.
La datation se fait par une horloge unique qui est utilisée pour la gestion du temps
(temporisation, chien de garde, etc.). La mémoire commune contient le contexte des
tâches et les données de l’application. Elle permet de mémoriser instantanément, l’état
global du système. De plus, elle représente le mécanisme de base pour la communication
et la synchronisation entre les tâches.
Les avantages de cette architecture sont ceux des systèmes centralisés: contexte
centralisé, temps cohérent, applications simples à mettre en œuvre. Par contre, les
perspectives d’évolution d’un tel système sont limitées par ses possibilités physiques.
De même, le seul traitement à apporter aux surcharges est de fonctionner en mode
dégradé.
Comme exemple de contrôle centralisé, considérons un système de robot dont la
simple hiérarchie de contrôle consiste en un planificateur de mouvement et un contrôleur
de mouvement. Le planificateur de mouvement doit acquérir des données de
l’environnement au moyen des capteurs, construire un modèle interne de la réalité sur la
base des données collectées et ensuite, faire le choix de la meilleure action. Le plan de
l’action sera soumis au contrôleur de mouvement sous la forme d’une trajectoire de
points dans certain cadre cartésien de coordonnées. Le rôle du contrôleur de mouvement
est maintenant de suivre cette trajectoire autant précisément que possible.
Le contrôleur de mouvement a un rôle temps réel critique de conduire le robot tout
au long d’un chemin passant par certains points. Tous les aspects de contraintes de
temps au niveau du contrôleur de mouvement sont liés à la capacité d’effectuer un

16
16


mouvement sans heurts avec des déviations minimales par rapport au chemin spécifié.
La validité de ce chemin incombe au planificateur de mouvement.
Les contraintes de temps du planificateur de mouvement sont quelque peu moins
sévères, et plus négociables que celles du contrôleur de mouvement. Dans ce type de
système, chaque niveau travaille sur un sous problème spécifié par un niveau supérieur.
Dans ce sens, le contrôle est centralisé au sommet de la hiérarchie.

XII-2 Architecture répartie:
Les fonctions de l’application peuvent être prises en compte par n’importe quelle
unité de traitement, grâce aux possibilités de communication du médium. Les capteurs
émettent sur le réseau les données (mesures ou événements) qui sont traitées dans un ou
plusieurs sites.
En environnements répartis, de nouveaux problèmes se posent et auxquels il faut
faire face: le placement des tâches, la mise à jour des copies multiples de données, la
synchronisation de tâches, etc.
Les inconvénients des systèmes répartis sont: difficulté de la gestion répartie des
ressources, incohérences des horloges locales, prise en compte des pannes, absence de
contexte global, etc. Par contre, c’est le schéma qui semble le plus souple par ses
capacités d’évolution, par ses possibilités de tolérance aux pannes et de répartition de la
charge ou capacités de réponses aux surcharges.

XIII- Conclusion
Les systèmes temps réel sont souvent distribués et possèdent différentes
contraintes de temps, de sécurité, de fiabilité, et de robustesse, imposées par
l’environnement de l’application. Comprendre et contrôler le comportement temporel
constituent un aspect critique pour assurer la sécurité et la fiabilité.
La vitesse (vitesses de processeurs par exemple) seule, n’est pas suffisante pour la
satisfaction des contraintes de temps. Des techniques rigoureuses de gestion de
ressources doivent aussi être utilisées, afin de prévenir des situations dans lesquelles des
tâches longues et à priorités réduites bloquent d’autres tâches à priorités plus élevées et
temps d’exécution réduits.
Le principal guide de gestion des ressources des systèmes temps réel est la
capacité de déterminer si le système peut satisfaire toutes ses contraintes de temps. Ce
besoin de prévisibilité nécessitent le développement et l’utilisation de modèles
d’ordonnancement et des techniques analytiques. Leurs applications nécessitent
l’intégration de certaines qualités de services, particulièrement en matière de
prévisibilité des temps d’exécution des tâches, de tolérance aux fautes, de disponibilité
et de performances. Ils doivent présenter des interfaces utilisateurs conviviales. La
prévisibilité dans le contexte temps réel «hard» requiert une importance capitale. Ces
systèmes peuvent comprendre des ressources hétérogènes telles que les CPUs, les
réseaux, et les périphériques d’entrée/sortie qui doivent être ordonnancées de façon à
être prévisibles, flexibles, et faciles à analyser mathématiquement.
La prévisibilité nécessite le développement de modèles d’ordonnancement et de
techniques analytiques afin de déterminer si le système temps réel peut ou non satisfaire
les contraintes de temps.
Les difficultés de spécifications, analyse, et ordonnancements de processus dans
les systèmes temps réel à contraintes de temps strictes (hard) sont augmentées par le fait
que le système physique contrôlé consiste souvent en plusieurs sous-systèmes
indépendants produisant des signaux asynchrones de capteurs et valeurs de contrôle
[Kramer93]. De tels systèmes peuvent avoir besoin de logiciels de contrôle distribué

17
17


fournissant des capacités adéquates de traitements et de temps de réactions pour
effectuer des tâches périodiques avec des ordonnancements serrés et pour le traitement
dans le temps requis d’événements arrivant de façon asynchrone.

18
18

2 Ordonnancement Des Tâches

I- Types de tâches temps réel:
Nous utilisons une classification de ces tâches en fonction des propriétés de la liste de leurs
dates d'occurrences. Trois types de tâches ont été identifiées :
périodiques : Une tâche périodique est définie comme une tâche qui doit être prête à être
exécutée à des intervalles de temps fixés (ou périodes) et dont l'exécution doit être terminée
avant le début de la période suivante [Bestravos93]. Une autre définition dit qu'une tâche
périodique demande une allocation du temps processeur à des intervalles réguliers, ces temps
processeur devant être alloués de façon à ce que l'exécution de la tâche ne dépasse pas ses dates
limites [Howell94] [Gupta94].
apériodiques: [Burns90] L'activation d'une tâche apériodique est essentiellement due à un
événement aléatoire et est déclenchée généralement par une action externe au système. Sa date
limite est fixée par l'environnement extérieur. Les tâches apériodiques ont également des
contraintes de temps qui leurs sont associées, par exemple le démarrage de leur exécution à
l'intérieur d'une période de temps prédéfinie. Souvent les tâches apériodiques sont déclenchées
par les événements critiques de l'environnement externe du système, c'est pour cela que leurs
dates limites sont souvent contraintes.
sporadiques: Une tâche sporadique est comme pour une tâche apériodique souvent déclenchée
par un événement extérieur au système, mais on constate l'existence d'une durée minimum entre
deux événements apériodiques (issus de la même source). La tâche sera alors dite sporadique
[Howell94] [Burns90].

II- Ordonnancement des applications temps réel:
Dans les systèmes temps réel, un problème d’ordonnancement consiste, à partir d’une
architecture matérielle (une ou plusieurs machines mono ou multiprocesseurs, un ou
plusieurs réseaux,…), d’une architecture fonctionnelle, et d’un ensemble d’objectifs
souhaités, à trouver un planning d’exécution des tâches de façon à garantir le respect des
contraintes de temps.
L’ordonnancement joue un rôle important puisque c’est lui qui définit le planning
d’exécution de tâches de façon à ce que les contraintes de tâches soient vérifiées. Dans la
plupart de ces systèmes, le respect de ces contraintes de temps reste le principal critère à
satisfaire.

19


Un problème d’ordonnancement dans un système temps réel est défini par le modèle
du système, les tâches et leurs natures, ainsi que les objectifs que l’algorithme
d’ordonnancement doit réaliser.
Le modèle de système décrit l’architecture matérielle du système disponible
(machine(s), réseau(x), etc.), qu’on appellera services, et les contraintes associées.
Les tâches et leurs natures sont décrites au niveau de la spécification fonctionnelle de
l’application et des contraintes associées. Comme exemple de ces contraintes, on peut citer
[Cardeira94]: les contraintes de temps, les contraintes de ressources, de précédence, etc.
Le challenge de l’ordonnancement est de garantir que toutes les contraintes du
problème sont satisfaites, particulièrement les contraintes de temps. L’ordonnanceur
produit un planning d’exécution de tâches, qui assure le respect des contraintes. Un
ordonnancement (planning) valide est un ordonnancement qui vérifie, sur une durée infinie,
que toutes les contraintes sont satisfaites.
L’intervention du temps fait des systèmes réactifs des systèmes temps réel. Le temps
est alors un facteur déterminant puisqu’il intervient aussi bien dans la définition des
critères de performances (par exemple, appliquer en une millisecondes une commande
externe à chaque fois qu’un capteur détecte une mesure excédant une certaine valeur) que
dans le séquencement interne d’un logiciel (par exemple, lancer une tâche de surveillance
séquentiellement toutes les 100 millisecondes).
Les méthodes du génie logiciel concernant les systèmes informatiques usuels font
appel à des modèles fonctionnels. En effet, la dynamique de ces systèmes étant pauvre, une
décomposition fonctionnelle structurée et l’identification des informations circulant entre
fonctions sont suffisantes pour spécifier la plupart des problèmes [Vallotton91].
Les approches fonctionnelles ne sont pas satisfaisantes pour traiter la spécification
des systèmes réactifs, car les aspects émergeant de ces derniers sont essentiellement
dynamiques. Un système réactif n’évolue pas seulement en fonction de ces entrées, mais
aussi des états internes. Un exemple trivial l’illustre: un logiciel qui doit exécuter une
routine d’interruption sauf si elle survient alors qu’il est déjà en cours de traitement. Une
composante de son état est «être en cours de traitement de l’interruption», sa connaissance
est nécessaire pour prévoir le comportement du système.
Dès que l’on a affaire à un système temps réel d’une certaine complexité, le point de
vue du comportement réactif devient primordial. Il doit donc intervenir dans sa

20


modélisation. Les méthodes spécifiques du temps réel introduisent généralement le
contrôle, mais davantage pour assurer la cohérence des modèles fonctionnels que pour
introduire de réels moyens de modéliser le comportement.
Dans la pratique, les portions temps critique des systèmes temps réel durs continuent
d’être implémentées par des langages de programmation de bas niveau. Elles sont
manuellement réglées afin de satisfaire toutes les contraintes. Les développeurs rencontrent
de grandes difficultés dans l’élaboration et l’analyse de codes complexes et ce, en
l’absence d’un langage, supportant des outils appropriés de spécification des contraintes de
temps [Chung95, Gerber97].
La spécification des contraintes de temps de granularité très fine dans le contexte
d’un langage de programmation de haut niveau n’est pas encore possible. On établit
manuellement des portions de code en langage assembleur pour exprimer des contraintes
strictes de temps. Ce qui rend ces programmes très difficiles à écrire et à maintenir, et un
ordonnancement automatisé devient presque impossible. Les langages tels que Ada
[Taft92] ne permettent de spécifier les contraintes de temps qu’entre les tâches,
lexicographiquement adjacentes dans le code source, et ne permettent pas de les spécifier
entre les instructions. Cette adjacence est aussi artificielle qu’insuffisamment expressive.

III- Etude formelle
Dans les STR, garantir que les tâches s’exécutent en respectant leurs échéances prescrites
est un point critique pour assurer l’intégrité de ces systèmes (systèmes en robotique) et la réussite
de ses missions.

Capteur1 Actionneur1

Capteur2 Actionneur2
Flux d’Information

Echantillonnage

Intervention

Système
Réaction
Capteurs

de Actionneur k
et

Contrôle
Temps Actionneur m
Réel
Capteur n Actionneur n

Fig I-4:Modélisation du fonctionnement d’un système temps réel

21


Dans de tels systèmes, les tâches sont accomplies (exécutées) régulièrement et
périodiquement, dans le but de contrôler des processus physiques et le fonctionnement des
appareils de contrôle. Elles échantillonnent des informations pour effectuer un traitement
spécifique, dans le but de produire des commandes pour les actionneurs.
L’invocation de ces tâches typiques se fait périodiquement, à chaque unité de temps T.
L’exigence la plus commune est qu’une invocation d’une tâche doit être achevée (complétée)
dans D unités de temps après qu’elle ne soit dans l’état Prêt. Les paramètres T et D sont appelés
respectivement la période et l’échéance.
Dans le cas où on confronte un problème de l’accomplissement de la tâche dans le temps
approprié, ou on marque la présence d’un flux dans la logique du programme, on pourra
marquer, par conséquent, des résultats catastrophiques dans les STR hards. On peut en déduire
que la rencontre de contraintes de temps est extrêmement importante dans de tels systèmes. Pour
satisfaire leurs échéances, les tâches doivent être ordonnées d’une manière adéquate.
Les algorithmes d’ordonnancement de tâches des les STR typiques confirment que les
temps d’exécution dans le plus pire des cas sont connus. Un tel système est conçu pour s’assurer
que toutes les tâches peuvent s’achever au bout de leurs échéances tant qu’il n’y a pas une tâche
dans le système qui s’exécute pendant une durée supérieure au temps d’exécution dans le cas le
plus pire. Une tâche qui dépasse le temps d’exécution prévu, peut entraîner une perte d’échéance
et l’échec total du système.
Différents modèles et théories ont été développés et utilisés comme une base permettant
l’étude et l’analyse du comportement des STR. En particulier, la théorie d’ordonnancement avec
priorités fixes a prouvé sa capacité de développement d’une sorte de découverte théorique pour
l’analyse du comportement temporelle des systèmes et de conception de systèmes amenant à
réaliser cette analyse.
Dans un simple ordonnancement Rate-Monotonic, Gerber & Hong ont montré qu’ils
peuvent améliorer l’ordonnançabilité en divisant le programme de la tâche en deux fragments. Le
premier dépend d’un événement observable, et le deuxième concerne un calcul interne (local) qui
peut être exécuté plus tard. Cependant, cette approche traite seulement des programmes simples
et monolitiques.
Dans le but de considérer une classe plus générale de problèmes d’ordonnancement,
Gonzalez, Härbour et al ont réalisé un travail de fond pour le raisonnement à propos du

22


comportement temporel dans le contexte des tâches composées d’une série de sous-tâches qui
s’exécutent avec des priorités multiples (dynamique).
La notion d'ordonnanceur de tâches prend toute sa signification lorsqu'on souhaite faire
exécuter les tâches par une architecture matérielle. Il faut être capable en cours d'exécution du
système, d'allouer du temps CPU d'une ressource de l'architecture matérielle à toute tâche qui
ferait son apparition, et ce avant sa date limite d'exécution. Un algorithme qui alloue les temps
processeurs pour chaque tâche dans un système de tâches est un algorithme d'ordonnancement
[Burns90] [Howell94]. Ces algorithmes peuvent avoir diverses propriétés. On peut les qualifier :
• d'algorithme optimal : [Krithi94] [Di Natal] [Atanas94] [Howell94] Un
algorithme d'ordonnancement est optimal s'il peut correctement ordonnancer un système
de tâches chaque fois que ce système est ordonnançable ;
• d'algorithme NP-complet : [Di Natal] NP est la classe de tous les problèmes de
décision pouvant être résolus dans un temps polynomial par une machine non-
déterministe. Si un problème R appartient à la classe NP et que tous les problèmes de la
classe NP sont polynomialement transformables en R alors le problème R est reconnu
NP-complet. L'algorithme gérant ces problèmes décisions est alors NP-complet ;
• d'algorithme NP-hard : [Di Natal] NP est la classe de tous les problèmes de
décision pouvant être résolus dans un temps polynomial par une machine non-
déterministe. Si tous les problèmes de la classe NP sont polynomialement transformables
en un problème R mais qu'on ne peut pas prouver que ce problème R appartient lui-même
à la classe NP, alors le problème R est dit NP-hard. L'algorithme gérant ce problème de
décision est dit NP-hard.

III- Ordonnancement "à base de priorités":
Nous allons regarder le cas particulier de deux algorithmes (ces deux algorithmes sont très
étudiés au niveau de la recherche sur l'ordonnancement temps réel) : le Rate Monotonic et le
Earliest Deadline.

III-1- L'algorithme Rate Monotonic:
La notion d'ordonnancement Rate Monotonic a été introduite en premier par Liu et
Layland [Liu73] en 1973. L'ordonnancement Rate Monotonic est un ordonnancement statique et
ne s'applique que pour des tâches périodiques. Il s'agit d'un algorithme d'ordonnancement à
priorités fixes. L'avantage d'une allocation fixe des priorités est que les priorités, allouées une

23


fois pour toutes, ne sont pas réévaluées au cours du temps. Le terme Rate Monotonic dérive de la
façon dont sont allouées les priorités aux différentes tâches, elles sont allouées selon une
fonction "Monotonic" du "Rate" (de la période) de la tâche. Plus la tâche a une période courte,
plus la priorité allouée sera importante. De nombreux travaux ont étendu l'application du Rate
Monotonic aux tâches synchronisées, à données partagées, aux systèmes avec des tâches
apériodiques...

III-2- L'algorithme Earliest Deadline:
Tout comme pour le Rate Monotonic, la notion d'algorithme Earliest Deadline a été
introduite en premier par Liu et Layland [Liu73] en 1973. l'ordonnancement Earliest Deadline est
un ordonnancement dynamique. Il peut s'appliquer pour l'ordonnancement de tâches périodiques
ainsi qu'apériodiques car il s'agit d'un algorithme d'ordonnancement à priorités dynamiques. Le
terme Earliest Deadline vient de la façon dont les priorités sont allouées aux tâches. La tâche
dont la date limite qui arrive le plus tôt aura une priorité élevée. Les priorités sont constamment
réévaluées au cours du temps (par exemple dans le cas où une nouvelle tâche arrive et que sa
date limite est la plus proche).

II-3- Critère d'ordonnançabilité pour chacun de ces algorithmes:
Dans le cas de systèmes où seules des tâches périodiques doivent être ordonnancées, des
travaux ont été réalisés pour déterminer, connaissant l'ensemble des tâches, à partir de quel
pourcentage d'utilisation CPU les dates limites de ces tâches seront sûres d'être respectées
[Liu73].
Le taux d'utilisation CPU pour une tâche i est le rapport entre le temps d'exécution de cette
tâche et sa période . Le taux d'utilisation CPU pour un groupe de tâches est la somme de ces
rapports.
Pour l'algorithme d'ordonnancement Rate Monotonic le pourcentage d'utilisation CPU doit
respecter la relation suivante si on veut être sûr que toutes les dates limites des différentes tâches
soient garanties :
(1) Lorsque n devient important, on remarque que pour être sûre de respecter les dates
limites des différentes tâches en utilisant l'algorithme Rate Monotonic pour ordonnancer les
tâches, le processeur doit être utilisé à moins de 69 %. Dans le cas particulier où les périodes des

24


différentes tâches sont harmoniques, une étude a montré que quelque soit le taux d'utilisation
CPU si l'ordonnancement est réalisable alors il pourra être réalisé.
Pour l'algorithme d'ordonnancement Earliest Deadline le pourcentage d'utilisation CPU
doit respecter la relation suivante si on veut être sûr que toutes les dates limites des différentes
tâches soient garanties :
(2) Même lorsque n devient important, on remarque que quelque soit le taux d'utilisation
CPU, si l'ordonnancement est réalisable, il pourra être réalisé.

III-4- Les limites des deux algorithmes:
Ces algorithmes ne posent pas de problèmes d'application tant que l'on reste dans une
utilisation avec des tâches périodiques (dans le cas du Rate Monotonic seulement, le Earliest
Deadline pouvant prendre en compte les tâches apériodiques), pas de protocoles (partage de
données entre tâches, ...), pas de surcharges.
Des études ont permis l'amélioration de ces algorithmes pour prendre en compte les
différents cas cités ci-dessus.

IV- Modes d'ordonnancement:

L'ordonnancement est une fonction centrale dans un système temps réel. En fonction de
l'apparition des entrées en provenance du système contrôlé (entraînant la demande d'exécution
d'une tâche), il doit réorganiser l'affectation des ressources processeur en vue du respect des
dates limites de chaque tâche.
L'ordonnancement peut se faire de deux façons. La première façon d'ordonnancer est
l'ordonnancement «offline» pour lequel l'ordonnancement est planifié dès la conception, des
tables d'ordonnancement sont créées et vont être utilisées en fonctionnement. Durant le
fonctionnement, le système se contente de lancer les tâches aux dates prévues. La deuxième
façon est l'ordonnancement online pour lequel l'ordonnancement est réalisé à chaque instant du
fonctionnement du système. Si les ordonnancements réalisés offline donnent des systèmes très
rapides à l'exécution, et d'une grande fiabilité, ils ne peuvent s'appliquer qu'aux systèmes dont on
connaît entièrement a priori le système contrôlé. Dans le cas contraire, un ordonnancement
online est nécessaire pour replannifier les tâches à l'apparition d'un nouvel événement significatif
[Atanas94] [Howell94].
Les algorithmes d'ordonnancement peuvent également être dits statiques ou dynamiques.
Un algorithme d'ordonnancement est dit statique lorsque l'ordonnancement est prévisible avant la

25


mise en fonctionnement du système, il faut pour cela connaître les tâches a priori. Un algorithme
d'ordonnancement est dit dynamique lorsque l'ordonnancement est créé au fur et a mesure de
l'arrivée des tâches dont on peut ne rien connaître a priori. Un ordonnancement statique est plus
fiable mais moins flexible qu'un ordonnancement dynamique (pour un ordonnancement statique
il faut connaître l'ensemble des tâches à réaliser, alors que pour un ordonnancement dynamique
ce n'est pas la peine de toutes les connaître) [Atanas94].
A partir de ces différentes propriétés qui sont associées aux algorithmes d'ordonnancement,
une classification de ces algorithmes ressort :
• les ordonnanceurs que l'on peut qualifier de "tout planifiés". Ces ordonnanceurs sont
des ordonnanceurs offline et statiques. En effet, un ordonnancement est créé à partir d'une
table d'ordonnancement qui est construite à l'aide des caractéristiques des différentes tâches.
Cet ordonnancement est ensuite appliqué sur le système. Cette approche ne peut s'appliquer
que pour l'ordonnancement de tâches périodiques (ou qui ont été transformées en tâches
périodiques) puisqu'il faut connaître à priori l'ensemble des tâches et de leurs caractéristiques.
Cette approche est hautement prédictible mais n'est pas flexible : un changement sur une des
tâches ou une de ses caractéristiques entraîne la reconstruction totale de la table [Krithi94] ;
• les ordonnanceurs que l'on peut qualifier d'ordonnanceurs "à base de priorités". Ces
ordonnanceurs sont online mais peuvent être statiques ou dynamiques. Des priorités sont
affectées aux tâches, l'ordonnanceur va ordonnancer les tâches suivant la valeur de la priorité
qui leur est affectée. Pour ce type d'ordonnancement apparaît la notion de préemptivité (si une
tâche de basse priorité est en train d'être exécutée et qu'une tâche de priorité plus haute est
déclenchée, la tâche de basse priorité sera interrompue et le processeur sera affecté à la
nouvelle arrivée) [Krithi94]. Un algorithme d'ordonnancement peut être à priorités fixes
(statiques) ou dynamiques [Atanas94]. Dans le cas d'un ordonnancement à priorités fixes, on
va associer à chaque tâche une priorité, cette priorité va rester la même tout au long du
fonctionnement du système. Dans le cas d'un ordonnancement à priorités dynamiques la
valeur de la priorité d'une tâche va évoluer au cours du fonctionnement du système ;
• les ordonnanceurs que l'on peut qualifier de "dynamiques". Ces ordonnanceurs sont
online et dynamiques. Il apparaît deux approches "dynamiques", les approches "Dynamic
Planning-Based" et les approches "Dynamic Best-Effort". Les approches "Dynamic Planning-
Based" lorsqu'une tâche apparaît vont, avant de l'exécuter, créer un plan d'exécution de cette
tâche et vérifier si ce plan va garantir son exécution. Si l'exécution de cette tâche n'est pas

26


garantie alors d'autres alternatives seront envisagées (tel l'envoi de la nouvelle arrivée sur un
autre nœud du système pour un système distribué) [Krithi94]. Pour les approches "Dynamic
Best-Effort", les tâches vont être ordonnancées mais en aucun cas, leurs dates limites ne
seront garanties [Krithi94].
Pour le génie automatique, les ordonnanceurs du type "tout planifiés" ne peuvent pas
répondre aux problèmes posés par l'apparition à caractère aléatoire des événements issus du
système contrôlé. En effet il est impossible de planifier, avant la mise en route du système,
l'affectation des tâches sur le ou les processeurs du système contrôlant car on ne connaît pas les
dates de demande d'exécution. Les ordonnanceurs du type "dynamiques" ne peuvent pas
s'appliquer dans le domaine de l'automatique car les systèmes que nous étudions sont des
systèmes contraints et que dans le cas de ces ordonnanceurs on ne sait pas a priori si toutes les
dates limites pourront être garanties. Par contre les ordonnanceurs du type "à base de priorités"
sont très prisés par les acteurs du Génie Automatique. Nous allons donc dans la suite de notre
étude détailler ce type d'ordonnanceurs.

V- Création d'ordonnancements plus complexes:
Les algorithmes Rate Monotonic et Earliest Deadline sont complétés par d'autres
algorithmes ou protocoles dans le but de pouvoir répondre à des spécifications du système plus
compliquées (la prise en compte de tâches apériodiques, des protocoles tels le partage des
données ..., le traitement des surcharges transitoires).

V-1- Introduction des problèmes "d'inversion de priorités" (dus aux partages de données
par exemple):

Comme nous l'avons déjà vu, un algorithme d'ordonnancement est préemptif lorsqu'au
cours de l'ordonnancement il peut interrompre l'exécution d'une tâche et allouer le temps
processeur à une autre tâche. Par exemple lorsqu'une tâche de plus haute priorité arrive, le Rate
Monotonic ou le Earliest Deadline vont interrompre l'exécution de la tâche qui est en cours pour
exécuter la nouvelle arrivée. Une tâche peut être préemptée plusieurs fois sans aucune pénalité.
Les algorithmes non préemptifs ne peuvent pas interrompre l'exécution d'une tâche de cette façon
[Burns90] [Atanas94] [Sha93].
Dans les systèmes temps réel, les tâches interagissent pour satisfaire des spécifications plus
larges du système. Les formes que prennent ces interactions sont variées, allant de la simple

27


synchronisation jusqu'à la protection par exclusion mutuelle sur les ressources non partageables,
et les relations d'antériorité. Pour cela, il existe des événements, des langages de programmation
concurrente fournissant des primitives de synchronisation (drapeaux, contrôleurs...). La difficulté
principale avec ces drapeaux, contrôleurs ou autres messages de base des systèmes, est que des
tâches à haute priorité peuvent être bloquées par des tâches à priorité plus basse. Ce phénomène
est connu sous le nom d'inversion de priorité. Quatre approches permettent de résoudre ce
problème :
• une approche appelée "prévention d'inversion de priorité"[Howell94],
• une approche appelée "héritage des priorités" [Klein90] dont le "Ceiling
Protocol" est un algorithme particulier [Klein90] [Di Natal]. Le travail de ce protocole lié
avec un ordonnanceur Rate Monotonic a été étudié par Sha et al. [Rajkumar90], et le
même protocole lié avec un ordonnanceur Earliest Deadline a été étudié par Chen et Lin
[Chen90],
• une approche appelée "Stark Ressource" [Di Natal].
L’adjonction de tels protocoles ne nous permet plus d'avoir une estimation de
l'ordonnançabilité des différentes tâches à ordonnancer.

V-2- Traitement des tâches apériodiques ou sporadiques : les algorithmes "bandwith
preserving":

Beaucoup de systèmes temps réel doivent traiter des tâches périodiques ainsi que des
tâches apériodiques. Quand on veut prendre en compte des événements apériodiques, il faut
utiliser une approche dynamique, telle le Earliest Deadline. Mais malgré cela, l'exécution en cas
de surcharges transitoires pose des problèmes (Les dates limites qui ne sont pas respectées ne
sont pas forcément celles dont l'importance pour le système est la moindre), ce cas est traité dans
le paragraphe suivant.
Le Rate Monotonic a été adapté pour pouvoir gérer des tâches apériodiques. Pour cela, une
tâche périodique aura la fonction de servir une ou plusieurs tâches apériodiques. Différents
algorithmes permettent de gérer cela :
• le "Priority Exchange"[Sha87],
• le "Deferrable Server" [Sha87],
• le "Sporadic server" [Harbour91] [Sha87],
• le "Slack Stealing" [Davis93].

28


V-3- Traitements en cas de surcharges transitoires:
(dus au fait que certaines tâches sont apériodiques).
Le fait de devoir gérer des tâches apériodiques peut entraîner un phénomène de surcharges
transitoires. Il peut se présenter des situations pour lesquelles il n'est pas possible de respecter les
dates limites, le système est alors dit en exécution de surcharge transitoire.
Malheureusement, une application directe du Rate Monotonic n'est pas appropriée dans le
cas de telles surcharges. Par exemple dans l'approche Rate Monotonic, une surcharge transitoire
va amener la tâche dont la période est la plus longue à dépasser sa date limite. Cette tâche peut
cependant être plus critique que les autres. La difficulté vient du fait que le concept de priorité
pour le Rate Monotonic est une indication de la période qui peut ne pas être une indication de
l'importance de la tâche vis à vis du système. Ce problème peut être résolu en transformant la
période dans le cas d'une tâche importante [Burns90].
Le Earliest Deadline est un algorithme optimal lorsqu'il n'y a pas de surcharge. Le
phénomène typique qui se produit en cas de surcharge avec le Earliest Deadline est l'effet
domino [Di Natal]. Pour contrôler les retards des tâches sous des conditions de surcharges, on
associe à chaque tâche une valeur reflétant l'importance de chaque tâche dans le système. Alors
la gestion des tâches à partir de ces valeurs peut être réalisée par l'algorithme de Smith" [Di
Natal]. Malheureusement, les contraintes d'antériorité sur les tâches sont souvent générales. Une
heuristique a été proposée dans le projet SPRING, où les dates limites et les algorithmes de coût
ont été combinés avec d'autres algorithmes pour revoir dynamiquement ces valeurs et accorder
les dates limites avec les contraintes d'antériorité. Certains algorithmes heuristiques, proposés
pour gérer les surcharges, améliorent l'exécution du Earliest Deadline [Livny91]
[Thambidurai89].

29

Restructuration d applications Java Temps réel

Restructuration d applications Java Temps réel

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (19)

Similaire à Restructuration d applications Java Temps réel

Similaire à Restructuration d applications Java Temps réel (20)

Plus de Cédric Mouats

Plus de Cédric Mouats (19)

Restructuration d applications Java Temps réel