MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET          DE LA RECHERCHE SCIENTIFIQUE             Faculté des Ingénieurs         ...
INTRODUCTIONLa décomposition d’un système temps réel résulte en une collection de processus,chacun est responsable d’une p...
1      Le Monde Des Systèmes Temps Réel                                               111PARTIE 1:Système Temps Réel «Conc...
1       Le Monde Des Systèmes Temps Réel                                              222millisecondes, cependant, dans le...
1      Le Monde Des Systèmes Temps Réel                                               333                                 ...
1        Le Monde Des Systèmes Temps Réel                                                 444général, qui sera utilisé pou...
1       Le Monde Des Systèmes Temps Réel                                              555IV-2- Manipulation des nombres ré...
1       Le Monde Des Systèmes Temps Réel                                               666s’assurer que le comportement, a...
1       Le Monde Des Systèmes Temps Réel                                          777logiciel. On peut considérer que le p...
1       Le Monde Des Systèmes Temps Réel                                              888processus assurent l’exclusion mu...
1       Le Monde Des Systèmes Temps Réel                                             9993. Temporel: les éléments du modul...
1       Le Monde Des Systèmes Temps Réel                                              101010Une connexion du vecteur d’éta...
1       Le Monde Des Systèmes Temps Réel                                             111111VIII-Implémentation:       Le l...
1       Le Monde Des Systèmes Temps Réel                                            121212   Cependant, un programme doit ...
1       Le Monde Des Systèmes Temps Réel                                        131313XI- Analyse des Contraintes de Tâche...
1       Le Monde Des Systèmes Temps Réel                                         141414deuxième catégorie ont des échéance...
1       Le Monde Des Systèmes Temps Réel                                          151515synchronisation, de communication,...
1       Le Monde Des Systèmes Temps Réel                                         161616XI-9-Contraintes de tolérance aux f...
1       Le Monde Des Systèmes Temps Réel                                          171717mouvement sans heurts avec des dév...
1      Le Monde Des Systèmes Temps Réel                                      181818fournissant des capacités adéquates de ...
2        Ordonnancement Des TâchesI- Types de tâches temps réel:   Nous utilisons une classification de ces tâches en fonc...
2       Ordonnancement Des Tâches     Un problème d’ordonnancement dans un système temps réel est défini par le modèledu s...
2                     Ordonnancement Des Tâchesmodélisation. Les méthodes spécifiques du temps réel introduisent généralem...
2        Ordonnancement Des Tâches      Dans de tels systèmes, les tâches sont accomplies (exécutées) régulièrement etpéri...
2        Ordonnancement Des Tâchescomportement temporel dans le contexte des tâches composées d’une série de sous-tâches q...
2        Ordonnancement Des Tâchesfois pour toutes, ne sont pas réévaluées au cours du temps. Le terme Rate Monotonic déri...
2        Ordonnancement Des Tâchesdifférentes tâches sont harmoniques, une étude a montré que quelque soit le taux dutilis...
2       Ordonnancement Des Tâchesmise en fonctionnement du système, il faut pour cela connaître les tâches a priori. Un al...
2       Ordonnancement Des Tâches   garantie alors dautres alternatives seront envisagées (tel lenvoi de la nouvelle arriv...
2        Ordonnancement Des Tâchessynchronisation jusquà la protection par exclusion mutuelle sur les ressources non parta...
2           Ordonnancement Des TâchesV-3- Traitements en cas de surcharges transitoires:       (dus au fait que certaines ...
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Restructuration d applications Java Temps réel
Prochain SlideShare
Chargement dans…5
×

Restructuration d applications Java Temps réel

1 708 vues

Publié le

La restructuration de programmes consiste à apporter des modifications sur la structure interne de ces programmes, pour différents buts tels que la facilité de compréhension et de maintenance, l’optimisation, l’ordonnancement de tâches, la facilité de conversion d’un langage à un autre, ou la détermination de modules réutilisables. Dans ce travail, nous avons conçu et implémenté un système de restructuration de programmes Java temps réel, qui permet d’obtenir une sensible amélioration de l’ordonnançabilité de ce type d’applications.
En effet, les programmes associés à des systèmes temps réel doivent être logiquement corrects et doivent s’exécuter sans fautes temporelles. Afin de satisfaire leurs échéances, les tâches de ces systèmes sont ordonnancées par des techniques adéquates. Dans le cas par exemple, où un ensemble de tâches serait non ordonnançable, le programmeur procède à des opérations manuelles de modification, de réglage et de restructuration de l’application, afin de la rendre ordonnançable. De telles opérations sont lentes, coûteuses, et non contrôlables. Les solutions existantes dans ce domaine, sont de nature à améliorer l’ordonnançabilité d’une tâche.
Etant donné que Java est un langage de programmation purement orienté objet, nous avons utilisé les modèles de représentation de dépendances qui tiennent compte des différents aspects des systèmes orientées objets tels que la réutilisation et le polymorphisme.

0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 708
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
29
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Restructuration d applications Java Temps réel

  1. 1. 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 & logicielsRestructuration d’Applications Java Temps-Réel Par KAMEL MOUATS
  2. 2. INTRODUCTIONLa 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 correspondanceentre 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 maintenancedu code. De plus, traiter les systèmes temps réel comme étant des groupes de processuscontraints 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; lesactions 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 sontdes approximations d’activités réellement continues. Dans ces systèmes, les contraintesde temps sont plus naturellement vues comme étant des contraintes de cohérencestemporelles d’information. Par exemple, dans plusieurs systèmes robotiques, l’interfacelogicielle du manipulateur physique entraîne le manipulateur physique à lirepériodiquement son état et à émettre des commandes d’actionneurs. Le logiciel dans untel système, contient une image du manipulateur physique. Cette image doit être tenuecohérente avec l’état courant du manipulateur physique, sinon le planificateur demouvements pourrait générer des plans de mouvements inappropriés. Al’implémentation, cette contrainte de cohérence est transformée en contrainte de tempsde n unités de temps de périodes de scrutation. De plus, dans la plupart des systèmes temps réel, une approximation de laconcurrence doit être faite par l’exécution de plusieurs processus sur des ressourcespartagées. L’ordonnancement de l’exécution de ces processus est souvent basées sur lestemps d’exécution au pire des cas, obtenus au moyen de différentes techniquesd’estimation. Ceci pose le problème de réservation excessive des ressources, lorsque letemps moyen d’utilisation s’éloigne des temps au pire des cas. Le comportement temporel est une caractéristique de base pour les systèmesinformatiques où les programmes doivent être logiquement correct, en s’exécutant sanserreurs de temps.Les erreurs temporelles sont particulièrement produites quand on a un ensemble de tâchesprovoquant 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érationsintensivement manuelles, telles que l’instrumentation, prise de mesure et éventuellement unereconception complète du système. De telles opérations sont coûteuses, lentes etincontrô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 tempsréel qui peut être complexe et contenant une collection de procédures. Dans un deuxièmeniveau, 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éliorerl’ordonnançabilité d’un ensemble de tâches, soit par rendre leurs échéances flexibles, ou bienpar décomposition d’une ou de plusieurs tâches en sous tâches, de telle façon qu’on puisseutiliser les méthodes d’ordonnancement généralisées, de priorités fixes, qui permettentl’augmentation de l’ordonnançabilité d’un ensemble de tâches, à un niveau supérieur de celuifourni par l’algorithme Rate-Monotonic.
  3. 3. 1 Le Monde Des Systèmes Temps Réel 111PARTIE 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 desdifficultés que l’on rencontre lorsque l’on implémente ce genre de système. Un systèmetemps 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 deces systèmes..I- Introduction: Au fur et à mesure que le prix sur le matériel diminue, on intègre des ordinateursdans de plus en plus de systèmes. Ces logiciels interagissent directement avec despé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 lelogiciel, 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 ensembled’entités contrôlées et un sous-système de contrôle. Ce dernier est formé d’un ensemble desystèmes d’ordinateurs, tandis que les entités contrôlées peuvent être un large éventail desystè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 decontrôle pour recevoir des données de l’environnement et/ou pour émettre des commandesaux entités contrôlées [Chung95]. Un système temps réel (STR) est un système dédié à des applications spécifiques, enparticulier, les systèmes de contrôle. Des capteurs recueillent de l’information qu’ilsfournissent au calculateur(ordinateur). Ce dernier s’occupe de réaliser le contrôle désiré etdonne 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ôlede bateaux, de véhicules, de machines à laver, etc. Comme on a besoin de répondre à des événements qui arrivent à n’importe quelmoment, on doit organiser l’architecture d’un système temps réel de manière à pouvoirtransférer le contrôle au composant approprié dès la réception d’un événement. C’estpourquoi, on conçoit le système comme un ensemble de processus parallèles, et quicoopèrent entre eux. Une partie du système temps réel (quelquefois appelée exécutiftemps 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’unSTR; cependant, elles ont tous en commun la notion du «temps de réponse (le tempsné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’estn’importe quel système dans lequel le temps, au bout duquel la sortie est produite, estsignificatif. C’est généralement dû au fait que l’entrée correspond à certains flux dans lemonde physique, et la sortie doit appartenir aux même flux. La différence entre le temps del’entrée et celui de la sortie doit être suffisamment petite pour avoir un temps de réponseacceptable.»Ici, le mot «temps de réponse» est pris dans le contexte du système total. Par exemple, dansun système de contrôle de missiles téléguidées, la sortie est exigée dans quelques 1 1
  4. 4. 1 Le Monde Des Systèmes Temps Réel 222millisecondes, cependant, dans les systèmes de contrôle d’assemblage de voitures, la réponsepeut être exigée seulement dans une seconde.Young[1982] définit un STR comme suit: «C’est tout système ou activité de traitementd’information qui doit répondre à une entrée stimulée, extérieurement générée, dans unepé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ésd’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éralementdé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 êtreconsidérée aussi mauvaise qu’une réponse fausse. Bien entendu, c’est cet aspect qui distingueun 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ésultatsd’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éeldistinguent 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 dansun échéance spécifié.Les STR softs sont ceux où les temps de réponse sont importants mais le système resterafonctionner correctement si les échéances sont occasionnellement perdus.Les systèmes softs peuvent être distingués par eux même des systèmes interactifs danslesquels 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 uncomposant de traitement d’information dans un système d’ingénierie large. Il est pour cetteraison 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èmed’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. Sion détecte une augmentation dans le flux, l’ordinateur doit répondre en alternant l’angle de lavanne; cette réponse doit se produire dans un temps fini si le dispositif de réception en fin dupipe ne se surchargera pas.III-2-La production: L’utilisation des ordinateurs dans la production est devenue essentielle de telle manièrequ’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édicauxpour le suivi automatique des malades et la gestion des comptes bancaires. 2 2
  5. 5. 1 Le Monde Des Systèmes Temps Réel 333 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, desdispositifs de collection d’informations et de procédures administratives permettant desupporter 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éspour 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 detemps 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 interventionmanuelle. Un agent doit rester informé de l’état du système par des unités de visualisation dedifférents types. Les changements d’état du système sont enregistrés dans une base d’information quipeut être interrogée par les opérateurs (agents), ultérieurement, soit pour restaurer le contextedu système, en cas d’un déséquilibre de son état, ou bien afin de fournir des informationspour des besoins administratifs. La structure d’un STR embarqué typique est représentée dans la figure I-2. Le logicielqui contrôle les opérations du système peut être conçu de manière modulaire reflétant lanature physique de l’environnement. Généralement, on fera appel à un module contenant lesalgorithmes nécessaires pour le contrôle physique des dispositifs, un deuxième responsable del’enregistrement des changements d’état, un troisième pour l’extraction et l’affichage de ceschangements 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
  6. 6. 1 Le Monde Des Systèmes Temps Réel 444général, qui sera utilisé pour la programmation effective des STR, doit supporter, etfacilement ces caractéristiques.IV-1-Taille et complexité: Il est souvent constaté que la plupart des problèmes associés au développement deslogiciels sont ceux relatifs à la taille et la complexité. Ecrire de petits programmes présente unproblème non significatif, comme il peut être conçu, codé, maintenu et compris par une seulepersonne. Si cette personne quitte la compagnie ou cette institution qui utilise ce logiciel, uneautre 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 bienl’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 nombred’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 duchangement 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
  7. 7. 1 Le Monde Des Systèmes Temps Réel 555IV-2- Manipulation des nombres réels: Un STR implique le contrôle d’un processus industriel manipulant des données. Cesdernières servent de paramètres de prise de décision et d’intervention en cas de situationsanormales.IV-3- Fiabilité et sécurité: Les STR interviennent dans des situations critiques demandant le contrôle desfonctionnalités. Une panne d’un système, impliquée dans le cas du transfert automatiqued’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 informatiquesdoivent être fiables et protectifs. De ce fait, on a intérêt à concevoir et implémenter dessystèmes dont leur fonctionnement est suivi par un autre système de contrôle. De plus, dans lecas où on exige une interaction avec un agent, on doit être prudent dans la conception de cetteinterface 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, aveclesquels, les programmes de l’ordinateur doivent interagir simultanément. Dans un castypique, le programme doit interagir avec un système d’ingénierie (qui se compose d’élémentsde fonctionnalités parallèles, telles que des robots, capteurs, actionneurs,…etc.) et les unitésd’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 traitementsimultané. 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’estcomment exprimer la concurrence dans la structure des programmes.Une des approche consiste à charger le programmeur pour construire son système quiimplique l’exécution cyclique d’une séquence de programmes manipulant différentes tâchesconcurrentes. Notez que cette approche de développement n’est en aucun cas applicables vules 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 deconcevoir et implémenter un système qui va garantir que la sortie appropriée se générera dansles 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 sontgénéralement construits en utilisant des processeurs ayant des capacités partagées, afin de 5 5
  8. 8. 1 Le Monde Des Systèmes Temps Réel 666s’assurer que le comportement, au pire des cas, ne produise aucun retard défavorable durantles périodes critiques du fonctionnement du système.En fournissant une puissance de traitement adéquate, en exigeant le support d’exécution, onpermettra 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 lemonde extérieur. Ils ont besoin de capteurs et actionneurs pour une large gamme de dispositifsdu monde réel. Ces dispositifs interagissent avec l’ordinateur via des registresd’entrées/sorties. Les dispositifs peuvent générer des interruptions afin de signaler auprocesseur que certaines opérations sont accomplies ou qu’il y avait des erreurs qui se sontproduites.De nos jours, vu la variété des dispositifs et la nature du temps critique de leurs interactionsassociées, leur contrôle doit être direct et non pas à travers les fonctions du systèmed’exploitation.IV-7-Implémentation efficiente: Vu la nécessité du traitement du temps critique dans les STR, l’implémentationefficiente (de haute qualité, efficace …) de ces systèmes devient de plus en plus nécessaire etimportante. Il est intéressant que l’un des bénéfices majeurs de l’utilisation d’un langage dehaut niveau est qu’il permet au programmeur de réaliser une implémentation abstraite loin detout détail, en se concentrant sur la résolution du problème. Le programmeur doit toujours êtreconcerné par le coût de l’utilisation de caractéristiques particulières d’un langage. Parexemple, si la réponse à quelques entrées doit apparaître au bout d’une micro-seconde, cen’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 descriptioninformelle 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écifiquestemps réels», le comportement temporel du système doit être explicite, tout comme lesbesoins en fiabilité et comportementaux du logiciel en cas où une panne d’un composantsurvienne. 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’estune 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 vied’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 desystè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 lamaintenance. Dans un système intégré à grande échelle, l’une des étapes du processus deconception consiste à concevoir les systèmes, et à partager les fonctions entre matériel et 6 6
  9. 9. 1 Le Monde Des Systèmes Temps Réel 777logiciel. On peut considérer que le processus de conception des systèmes intégrés suitune 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érationsComputer97]. Une fois qu’il a établi l’architecture (découpage en processus) et choisi lastratégie d’ordonnancement, le concepteur doit effectuer des estimations et dessimulations 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 comportementdu système. L’architecture, ou l’ordonnancement, ou l’exécutif, ou les trois à la foisdevront être reconçus afin de pouvoir «tenir» les contraintes de temps. Il est difficiled’estimer le temps d’exécution d’un système temps réel. Du fait de la natureimprévisible des événements apériodiques, les concepteurs doivent faire des hypothèsessur la probabilité pour qu’ils apparaissent (et donc demandent un service) à un instantdonné. Ces hypothèses peuvent s’avérer incorrectes et les performances du systèmedélivré ne seront pas suffisantes. Dasarathy [DAS85] traite de la validation des tempsd’exécution. Du fait que les processus d’un système temps réel doivent coopérer, le concepteur doitcoordonner les communications entre processus. Les mécanismes de coordination des 7 7
  10. 10. 1 Le Monde Des Systèmes Temps Réel 888processus assurent l’exclusion mutuelle lors de l’accès à des ressources partagées. Lorsqu’unprocessus est en train de modifier une ressource partagée, les autres processus ne peuvent pasen faire de même. Parmi les mécanismes d’exclusion mutuelle on trouve les sémaphores, lesmoniteurs et les régions critiques. Le langage choisi pour l’implémentation de systèmes temps réel peut avoir lui aussi uneinfluence sur la conception. Ada [Taft92] a été conçu à l’origine, pour implémenter dessystèmes intégrés, et il dispose de caractéristiques comme la gestion des tâches, les exceptionset les clauses de représentation. La notion de rendez-vous représente un bon mécanisme pourla 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 lescontraintes de temps. Parmi les autres langages, on trouve des langages de niveau systèmecomme 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 approchescomplémentaires sont souvent utilisées: décomposition et abstraction. Toutes les deuxforment 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’unsystème complexe en parties plus fines jusqu’à ce qu’on puisse isoler ses composants, afin depouvoir les gérer de manière décentralisée. A chaque niveau de décomposition, on faitcorrespondre un autre niveau de description et une méthode de documentation de cettedescription.L’abstraction permet de considérer les détails et les particularités concernantl’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éveloppementdes 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 etinterfaces non-ambigües. Si la spécification entière du système logiciel peut être vérifiéeseulement en terme de spécification des sous-composants immédiats, alors la décompositionest dite compositionnelle. C’est une propriété importante quand on veut analyserformellement les programmes.Les programmes séquentiels sont particulièrement amenés à des méthodes compositionnelleset 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 ungrand système peut être décomposé en modules? La réponse est liée aux méthodes dedécomposition des logiciels. Cependant, avant de discuter ces méthodes, il est approprié deconsidé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
  11. 11. 1 Le Monde Des Systèmes Temps Réel 9993. 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 duprogrammes. Deux modules ont un couplage fort s’ils échangent entre eux des informationsde contrôle. Par contre, ils perdent le couplage si les modules ne communiquent que desdonnées. Une autre façon de voir le couplage est de considérer la facilité de changer unmodule (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 etconcurrente.VI-3-Approches formelles: Elle consiste à modéliser le comportement des systèmes concurrents par l’utilisation desréseaux Petri [Brauer 1980]. Vue la variété des représentations obtenues, on introduit, dans leprocessus de modélisation, le concept des réseaux de transition prédicatives.La notion CSP (Communicating Sequential Processes) est développée, permettant laspé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énielogiciel pour la mise en œuvre des STR, vu que ces techniques sont applicables à tous lessystèmes de traitement d’information. Ces méthodes ne fournissent pas un support spécifiqueau domaine du temps réel, et ils manquent en richesse voulue quand on épuise toutes lespotentialités des langages d’implémentation utilisés.Typiquement, une méthode de conception structurée utilise un diagramme, dans lequel desarcs orientés schématisent le flux de données à travers le système, et les nœuds désignésrepré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 etPAMELA.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 descriptiondétaillée de la spécification, mais de plus, elle est le résultat de l’application detransformations à 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
  12. 12. 1 Le Monde Des Systèmes Temps Réel 101010Une connexion du vecteur d’état permet à un processus de connaître l’état interne d’un autreprocessus 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 detemps. 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 lacréativité! Ce n’est pas vrai. Ces techniques offrent une notation bien claire et comprise del’expression de la conception, et un moyen pour la vérification du bon placement de l’idéeadoptée, de ce fait, la conception a besoin de la spécification, et le logiciel implémente cetteconception.Le point le plus important dans une conception JSD est le flux de données. Une bonneconception est celle qui intègre ce flux naturel. L’avantage de ce flux de données est qu’ilpermet l’expression des contraintes de temps comme étant des attributs de données circulantdans le système.Une interruption génère un signal de contrôle ; le signal de contrôle est une transformation del’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 êtreordonnancées.Une fois la conception est obtenue, son implémentation doit être effectuée de manièresystématique. Avec un modèle de concurrence basé message, dans le langage del’implémentation, ce sera une tâche relativement facile, tout comme les processus deconception et les flux de données bufferisés qui peuvent être codés sous la forme de processusde programme. Malheureusement, cela peut produire une prolifération des processus et uneimplé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 conceptionpar une procédure avec un seul processus d’ordonnancement, contrôlant l’exécution d’unecollection 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 pluscomplexes.La méthode Mascot a été développée pour la conception, construction et exécution desapplications 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
  13. 13. 1 Le Monde Des Systèmes Temps Réel 111111VIII-Implémentation: Le langage de programmation est une interface importante et primordiale entre laspécification des besoins et l’exécution du code machine. La conception d’un langage reste undomaine de recherche actif. Malgré le passage naturel de la conception des systèmes versl’implémentation, les possibilités expressives des langages récents ne sont pas liées auxméthodologies de conception adoptées. Cette adoption poursuit logiquement l’étape decompréhension prévisible de l’étape d’implémentation.Il est possible d’identifier trois classes de langages de programmation qui sont utilisées dansle développement des systèmes temps réels. Ces langages sont: le langage d’assemblage, leslangages d’implémentation séquentielle des systèmes et les langages concurrents de hautniveau.IX-Critères da base d’un langage de conception: Un langage de programmation des STR peut être conçu seulement pour répondre auxbesoins 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émentationdes systèmes à objectifs généraux, pour des applications spéciales telles que les compilateurset 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
  14. 14. 1 Le Monde Des Systèmes Temps Réel 121212 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 langagede programmation, les facilités et les avantages dont il dispose. On a pu identifier trois classes de langage de programmation utilisés dans ledé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 langaged’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ésmachine, au lieu que ça soit orienté problème. Le programmeur peut être gêné par des détailsqui 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, etles programmes seront difficilement, ou même inefficacement modifiés, et ceci à l’intentionde 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, estexigée pour tous ceux qui sont concernés par l’utilisation et la programmation en langaged’assemblage.X-2-Langages séquentiels d’implémentation des systèmes: L’apparition d’ordinateurs puissants et la progression dans la technologie descompilateurs ont rendu l’écriture des logiciels temps réel plus avantageuse. On a pu constaterle développement de plusieurs langages, spécialement conçus pour la programmation dessystèmes embarqués. Ces langages ont en commun la propriété qu’ils sont séquentiels. Deplus, 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 dequalités pour la programmation et l’exploitation des dispositifs de la machine. Plusieursexpé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 lesapplications 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 dansles applications de télécommunication.Tous ces langages, et autres, sont destinés pour le développement des systèmes temps réelembarqués.Le langage Occam, apparu récemment et ses propriétés diverses, avait un rôle important dansl’apparition du domaine des applications embarquées couplées et distribuées. 12 12
  15. 15. 1 Le Monde Des Systèmes Temps Réel 131313XI- Analyse des Contraintes de Tâches: Un modèle de tâches temps réel permet de spécifier l’architecture fonctionnelled’un système temps réel. Chaque tâche est définie par un ensemble d’attributs décrivantles contraintes auxquelles elle est soumise. Traditionnellement, les applications temps réel étaient souvent décrites par lemodèle des tâches périodiques [Liu73]. Ce modèle décrit une application temps réel parun ensemble fini (appelé aussi configuration) de tâches périodiques. Une variante de cemodèle consiste à prendre en compte les tâches apériodiques. Dans ce modèle, toutes lestâches doivent s’exécuter jusqu’à leurs fins. Cependant, pour des besoins nouveaux dessystèmes temps réel, certaines tâches n’ont pas la contrainte de terminer nécessairementleur exécution. Ce qui a donné naissance à deux nouveaux types de modèles: le modèledes 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 sontle résultat d’intégration des modèles existants. D’autres traitent des contraintes de typeressources ou synchronisation.XI-1-Contraintes de temps: La plupart des contraintes de temps sont celles introduites par les modèles detâches périodiques et apériodiques. Ces deux types de modèles sont souvent utilisés entemps réel. En effet, un système temps réel est souvent concerné par le contrôle d’uncomportement continu (procédé) qui nécessite des actions répétitives (tâchespériodiques) ou aléatoires (apériodiques). Il existe trois types de tâches temps réel qui sont conçues pour superviser etcontrô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 doitcapter régulièrement des informations sur le processus et réagir quand des résultatsappropriés sont obtenus ou des informations spécifiques sont lues. Cet échantillonnagerégulier d’informations est effectué par la tâche périodique par une série continued’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 deces invocation possède un temps d’exécution de C unités qui peut être déterministe oustochastique. C indique souvent la borne maximale (ou le pire des cas) du tempsd’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èsson passage à l’état prêt. Ainsi, la première invocation doit se terminer dans le tempsI+D, la deuxième dans I+T+D, etc. Les tâches périodiques sont habituellement invoquées par les temporisateursinternes avec une périodicité choisie telle qu’elle assure une latence suffisamment courtepour 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’intervalleséparant deux invocations. La tâche apériodique peut s’effectuer avec un intervallealéatoire qui sépare deux invocations. Par ailleurs, un processus est une séquence d’opérations qui doivent être exécutéesdans un ordre prescrit [Xu93]. Les processus peuvent être divisés en deux catégories: lestâches de la première catégorie ont une échéance «stricte» (hard), c’est-à-dire que lasatisfaction de ses échéances est critique pour le fonctionnement du système, celles de la 13 13
  16. 16. 1 Le Monde Des Systèmes Temps Réel 141414deuxième catégorie ont des échéances «relatives» (soft), en ce sens que bien qu’un courttemps de réponse est souhaitable, un dépassement occasionnel de l’échéance peut êtretoléré.XI-2-Contraintes d’importance:Les tâches d’une application temps réel ne sont pas toutes aussi importantes les unes queles autres. En effet, du point de vue du concepteur d’une application, une tâche peut êtreplus importante qu’une autre. Cette caractéristique de la tâche est déterminée par desparamètres (poids, degré d’urgence, priorité externe, tâche critique, etc.). L’échec d’unetâche critique peut entraîner l’arrêt d’exécution du système, situation qui peut êtrecatastrophique. Par exemple, dans un système de contrôle de vol, le concepteur del’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ôlel’enregistreur de vol.XI-3-Contrainte d’interruption Cette contrainte permet d’exprimer si une tâche est interruptible ou non. Parexemple, 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 larecommencer complètement. Une tâche interruptible peut être interrompue par une autretâche prioritaire. Son exécution peut être reprise ultérieurement. Lorsqu’une tâche estinterrompue, elle peut être forcée de libérer temporairement les ressources qu’elle aacquises.XI-4-Contrainte de terminaison Dans des conditions de surcharge, certaines applications temps réel se contententd’exécuter quelques tâches partiellement. De telles applications peuvent se contenter derésultats acceptables. La contrainte de terminaison ont été prises en compte dans lesmodè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. Lesconditions d’activation/terminaison de tâches peuvent être décrites par une combinaisond’opérateurs de la logique temporelle (avant, après, etc.) [Chung95, Sahraoui85] avecdes 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 descontraintes temporelles que des contraintes décrivant son interaction avec d’autrestâches.Comme ces contraintes peuvent exprimer d’autres situations (autres que les contraintesde temps), cela justifie de les considérer indépendamment et dans la partie descontraintes 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 soninteraction avec d’autres tâches. Au cours de leur exécution, les tâches ne sont pasindé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
  17. 17. 1 Le Monde Des Systèmes Temps Réel 151515synchronisation, de communication, etc. Les relations de compétition indiquent lamanière avec laquelle les tâches utilisent des ressources partagées. Généralement, dans les applications informatiques, la mise en œuvre descontraintes de coopération et de compétition est réalisée par des mécanismes desynchronisation (rendez-vous, moniteur,…), d’exclusion mutuelle (sémaphores,…), decommunication (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 lesquelleselles entrent en compétition. La bonne utilisation des ressources partagées se traduit parl’existence de contraintes de ressources. Parmi les contraintes de ressources on peutdistinguer 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 latâche Ti; une ressource est dite consommable (telle qu’un missile dans une applicationmilitaire) si après son utilisation par une tâche, elle est consommée et donc n’existeplus, etc. Parmi les exemples des contraintes liées au fonctionnement des ressources, on peutciter [Liu94]: la durée d’acquisition d’une ressource, la durée de restitution d’uneressource et la durée de commutation de contexte. La durée d’acquisition de ressourcesest la durée maximale qui peut être prise en compte par une tâche afin d’acquérir uneressource oisive due aux propriétés de la ressource elle même. La durée de restitutiond’une ressource est la durée maximale séparant l’instant où une tâche libère la ressourceet l’instant où la ressource n’est plus dans le contexte de la tâche et donc disponible pourd’autres tâches. La durée de commutation de contexte est la durée nécessaire pourcommuter une ressource d’une tâche à une autre, généralement suite à une interruptionde la première tâche par la seconde. Dans plusieurs cas, la durée de commutation decontexte d’une tâche est égale à la somme de durée d’acquisition et de la durée derestitution de ressource. Cependant, ceci n’est pas toujours le cas. En effet, dans le caspar exemple d’un seul processeur, les informations de gestion de ce dernier telles que lescontenus de registres, nécessitant d’être sauvegardées et restaurées durant unecommutation 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âchedésire un accès en exclusion mutuelle sur une ressource à n points d’accès. Enenvironnement temps réel, la connaissance des contraintes de ressources parl’algorithme d’ordonnancement est nécessaire pour qu’il puisse effectuerl’ordonnancement des tâches qui les utilisent et réaliser leur gestion dans le cas où lagestion 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èmescentralisés multiprocesseurs ou répartis. En effet, une tâche peut exiger que sonexécution se fasse sur un certain processeur (pour des raisons de compatibilité du codeexécutable par exemple) ou sur un site donné (parce qu’elle fait des entrées/sorties surun dispositif particulier, par exemple). 15 15
  18. 18. 1 Le Monde Des Systèmes Temps Réel 161616XI-9-Contraintes de tolérance aux fautes: En environnement temps réel, les contraintes de tolérance aux fautes, associées auxtâches, sont capitales pour exiger que le respect de leur contraintes temporelles soitvé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 deprises de décision nous révèle la manière de fonctionnement des architectures. Les rôlesdes différents aspects du problème de contrôle sont souvent partagés à travers lesmodules. Un rôle est constitué d’un ensemble de responsabilités homogènes conçuesdans la perspective d’un objectif déterminé. On affecte à chaque module un ou plusieursrôles. Les modules sont souvent interdépendants dans la perspective de réaliser leurspropres objectifs ou ceux du système global. Ces dépendances sont habituellementétablies à travers des communications clairement définies entre les modules. Le type decommunication entre les modules et les types de rôles affectés aux modules, ont unimpact 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 étroitecoopé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é detraitement, composée d’un ou de plusieurs processeurs se partageant une mémoirecommune. 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égligeabledevant le temps qui s’écoule entre deux transitions d’états (points observables). Cetteunité 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 destâches et les données de l’application. Elle permet de mémoriser instantanément, l’étatglobal du système. De plus, elle représente le mécanisme de base pour la communicationet la synchronisation entre les tâches. Les avantages de cette architecture sont ceux des systèmes centralisés: contextecentralisé, temps cohérent, applications simples à mettre en œuvre. Par contre, lesperspectives 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 modedégradé. Comme exemple de contrôle centralisé, considérons un système de robot dont lasimple hiérarchie de contrôle consiste en un planificateur de mouvement et un contrôleurde mouvement. Le planificateur de mouvement doit acquérir des données del’environnement au moyen des capteurs, construire un modèle interne de la réalité sur labase des données collectées et ensuite, faire le choix de la meilleure action. Le plan del’action sera soumis au contrôleur de mouvement sous la forme d’une trajectoire depoints dans certain cadre cartésien de coordonnées. Le rôle du contrôleur de mouvementest 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 toutau long d’un chemin passant par certains points. Tous les aspects de contraintes detemps au niveau du contrôleur de mouvement sont liés à la capacité d’effectuer un 16 16
  19. 19. 1 Le Monde Des Systèmes Temps Réel 171717mouvement 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 moinssévères, et plus négociables que celles du contrôleur de mouvement. Dans ce type desystè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 quelleunité 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 ouplusieurs sites. En environnements répartis, de nouveaux problèmes se posent et auxquels il fautfaire face: le placement des tâches, la mise à jour des copies multiples de données, lasynchronisation de tâches, etc.Les inconvénients des systèmes répartis sont: difficulté de la gestion répartie desressources, incohérences des horloges locales, prise en compte des pannes, absence decontexte global, etc. Par contre, c’est le schéma qui semble le plus souple par sescapacités d’évolution, par ses possibilités de tolérance aux pannes et de répartition de lacharge ou capacités de réponses aux surcharges. XIII- Conclusion Les systèmes temps réel sont souvent distribués et possèdent différentescontraintes de temps, de sécurité, de fiabilité, et de robustesse, imposées parl’environnement de l’application. Comprendre et contrôler le comportement temporelconstituent un aspect critique pour assurer la sécurité et la fiabilité. La vitesse (vitesses de processeurs par exemple) seule, n’est pas suffisante pour lasatisfaction des contraintes de temps. Des techniques rigoureuses de gestion deressources doivent aussi être utilisées, afin de prévenir des situations dans lesquelles destâches longues et à priorités réduites bloquent d’autres tâches à priorités plus élevées ettemps d’exécution réduits. Le principal guide de gestion des ressources des systèmes temps réel est lacapacité de déterminer si le système peut satisfaire toutes ses contraintes de temps. Cebesoin de prévisibilité nécessitent le développement et l’utilisation de modèlesd’ordonnancement et des techniques analytiques. Leurs applications nécessitentl’intégration de certaines qualités de services, particulièrement en matière depré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. Laprévisibilité dans le contexte temps réel «hard» requiert une importance capitale. Cessystèmes peuvent comprendre des ressources hétérogènes telles que les CPUs, lesré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 detechniques analytiques afin de déterminer si le système temps réel peut ou non satisfaireles contraintes de temps. Les difficultés de spécifications, analyse, et ordonnancements de processus dansles systèmes temps réel à contraintes de temps strictes (hard) sont augmentées par le faitque le système physique contrôlé consiste souvent en plusieurs sous-systèmesindé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
  20. 20. 1 Le Monde Des Systèmes Temps Réel 181818fournissant des capacités adéquates de traitements et de temps de réactions poureffectuer des tâches périodiques avec des ordonnancements serrés et pour le traitementdans le temps requis d’événements arrivant de façon asynchrone. 18 18
  21. 21. 2 Ordonnancement Des TâchesI- 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 leursdates doccurrences. 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 à êtreexécutée à des intervalles de temps fixés (ou périodes) et dont lexécution doit être terminéeavant le début de la période suivante [Bestravos93]. Une autre définition dit quune tâchepériodique demande une allocation du temps processeur à des intervalles réguliers, ces tempsprocesseur devant être alloués de façon à ce que lexécution de la tâche ne dépasse pas ses dateslimites [Howell94] [Gupta94]. apériodiques: [Burns90] Lactivation dune 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 datelimite est fixée par lenvironnement extérieur. Les tâches apériodiques ont également descontraintes de temps qui leurs sont associées, par exemple le démarrage de leur exécution àlintérieur dune période de temps prédéfinie. Souvent les tâches apériodiques sont déclenchéespar les événements critiques de lenvironnement externe du système, cest pour cela que leursdates limites sont souvent contraintes. sporadiques: Une tâche sporadique est comme pour une tâche apériodique souvent déclenchéepar un événement extérieur au système, mais on constate lexistence dune durée minimum entredeux é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’unearchitecture matérielle (une ou plusieurs machines mono ou multiprocesseurs, un ouplusieurs réseaux,…), d’une architecture fonctionnelle, et d’un ensemble d’objectifssouhaités, à trouver un planning d’exécution des tâches de façon à garantir le respect descontraintes de temps. L’ordonnancement joue un rôle important puisque c’est lui qui définit le planningd’exécution de tâches de façon à ce que les contraintes de tâches soient vérifiées. Dans laplupart de ces systèmes, le respect de ces contraintes de temps reste le principal critère àsatisfaire. 19
  22. 22. 2 Ordonnancement Des Tâches Un problème d’ordonnancement dans un système temps réel est défini par le modèledu système, les tâches et leurs natures, ainsi que les objectifs que l’algorithmed’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 del’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 duproblème sont satisfaites, particulièrement les contraintes de temps. L’ordonnanceurproduit un planning d’exécution de tâches, qui assure le respect des contraintes. Unordonnancement (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 tempsest alors un facteur déterminant puisqu’il intervient aussi bien dans la définition descritères de performances (par exemple, appliquer en une millisecondes une commandeexterne à chaque fois qu’un capteur détecte une mesure excédant une certaine valeur) quedans le séquencement interne d’un logiciel (par exemple, lancer une tâche de surveillanceséquentiellement toutes les 100 millisecondes). Les méthodes du génie logiciel concernant les systèmes informatiques usuels fontappel à des modèles fonctionnels. En effet, la dynamique de ces systèmes étant pauvre, unedécomposition fonctionnelle structurée et l’identification des informations circulant entrefonctions sont suffisantes pour spécifier la plupart des problèmes [Vallotton91]. Les approches fonctionnelles ne sont pas satisfaisantes pour traiter la spécificationdes systèmes réactifs, car les aspects émergeant de ces derniers sont essentiellementdynamiques. Un système réactif n’évolue pas seulement en fonction de ces entrées, maisaussi des états internes. Un exemple trivial l’illustre: un logiciel qui doit exécuter uneroutine d’interruption sauf si elle survient alors qu’il est déjà en cours de traitement. Unecomposante de son état est «être en cours de traitement de l’interruption», sa connaissanceest 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 devue du comportement réactif devient primordial. Il doit donc intervenir dans sa 20
  23. 23. 2 Ordonnancement Des Tâchesmodélisation. Les méthodes spécifiques du temps réel introduisent généralement lecontrôle, mais davantage pour assurer la cohérence des modèles fonctionnels que pourintroduire de réels moyens de modéliser le comportement. Dans la pratique, les portions temps critique des systèmes temps réel durs continuentd’être implémentées par des langages de programmation de bas niveau. Elles sontmanuellement réglées afin de satisfaire toutes les contraintes. Les développeurs rencontrentde grandes difficultés dans l’élaboration et l’analyse de codes complexes et ce, enl’absence d’un langage, supportant des outils appropriés de spécification des contraintes detemps [Chung95, Gerber97]. La spécification des contraintes de temps de granularité très fine dans le contexted’un langage de programmation de haut niveau n’est pas encore possible. On établitmanuellement des portions de code en langage assembleur pour exprimer des contraintesstrictes de temps. Ce qui rend ces programmes très difficiles à écrire et à maintenir, et unordonnancement 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écifierentre 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 prescritesest un point critique pour assurer l’intégrité de ces systèmes (systèmes en robotique) et la réussitede 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
  24. 24. 2 Ordonnancement Des Tâches Dans de tels systèmes, les tâches sont accomplies (exécutées) régulièrement etpériodiquement, dans le but de contrôler des processus physiques et le fonctionnement desappareils de contrôle. Elles échantillonnent des informations pour effectuer un traitementspé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ésrespectivement 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 tempsapproprié, ou on marque la présence d’un flux dans la logique du programme, on pourramarquer, par conséquent, des résultats catastrophiques dans les STR hards. On peut en déduireque la rencontre de contraintes de temps est extrêmement importante dans de tels systèmes. Poursatisfaire 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 lestemps d’exécution dans le plus pire des cas sont connus. Un tel système est conçu pour s’assurerque toutes les tâches peuvent s’achever au bout de leurs échéances tant qu’il n’y a pas une tâchedans le système qui s’exécute pendant une durée supérieure au temps d’exécution dans le cas leplus pire. Une tâche qui dépasse le temps d’exécution prévu, peut entraîner une perte d’échéanceet l’échec total du système. Différents modèles et théories ont été développés et utilisés comme une base permettantl’étude et l’analyse du comportement des STR. En particulier, la théorie d’ordonnancement avecpriorités fixes a prouvé sa capacité de développement d’une sorte de découverte théorique pourl’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’ilspeuvent améliorer l’ordonnançabilité en divisant le programme de la tâche en deux fragments. Lepremier dépend d’un événement observable, et le deuxième concerne un calcul interne (local) quipeut être exécuté plus tard. Cependant, cette approche traite seulement des programmes simpleset 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
  25. 25. 2 Ordonnancement Des Tâchescomportement temporel dans le contexte des tâches composées d’une série de sous-tâches quis’exécutent avec des priorités multiples (dynamique). La notion dordonnanceur de tâches prend toute sa signification lorsquon souhaite faireexécuter les tâches par une architecture matérielle. Il faut être capable en cours dexécution dusystème, dallouer du temps CPU dune ressource de larchitecture matérielle à toute tâche quiferait son apparition, et ce avant sa date limite dexécution. Un algorithme qui alloue les tempsprocesseurs pour chaque tâche dans un système de tâches est un algorithme dordonnancement[Burns90] [Howell94]. Ces algorithmes peuvent avoir diverses propriétés. On peut les qualifier : • dalgorithme optimal : [Krithi94] [Di Natal] [Atanas94] [Howell94] Un algorithme dordonnancement est optimal sil peut correctement ordonnancer un système de tâches chaque fois que ce système est ordonnançable ; • dalgorithme 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. Lalgorithme gérant ces problèmes décisions est alors NP-complet ; • dalgorithme 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 quon 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. Lalgorithme 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 lordonnancement temps réel) : le Rate Monotonic et leEarliest Deadline.III-1- Lalgorithme Rate Monotonic: La notion dordonnancement Rate Monotonic a été introduite en premier par Liu etLayland [Liu73] en 1973. Lordonnancement Rate Monotonic est un ordonnancement statique etne sapplique que pour des tâches périodiques. Il sagit dun algorithme dordonnancement àpriorités fixes. Lavantage dune allocation fixe des priorités est que les priorités, allouées une 23
  26. 26. 2 Ordonnancement Des Tâchesfois pour toutes, ne sont pas réévaluées au cours du temps. Le terme Rate Monotonic dérive de lafaçon dont sont allouées les priorités aux différentes tâches, elles sont allouées selon unefonction "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 lapplication du RateMonotonic aux tâches synchronisées, à données partagées, aux systèmes avec des tâchesapériodiques...III-2- Lalgorithme Earliest Deadline: Tout comme pour le Rate Monotonic, la notion dalgorithme Earliest Deadline a étéintroduite en premier par Liu et Layland [Liu73] en 1973. lordonnancement Earliest Deadline estun ordonnancement dynamique. Il peut sappliquer pour lordonnancement de tâches périodiquesainsi quapériodiques car il sagit dun algorithme dordonnancement à priorités dynamiques. Leterme Earliest Deadline vient de la façon dont les priorités sont allouées aux tâches. La tâchedont la date limite qui arrive le plus tôt aura une priorité élevée. Les priorités sont constammentréévaluées au cours du temps (par exemple dans le cas où une nouvelle tâche arrive et que sadate limite est la plus proche).II-3- Critère dordonnançabilité pour chacun de ces algorithmes: Dans le cas de systèmes où seules des tâches périodiques doivent être ordonnancées, destravaux ont été réalisés pour déterminer, connaissant lensemble des tâches, à partir de quelpourcentage dutilisation CPU les dates limites de ces tâches seront sûres dêtre respectées[Liu73]. Le taux dutilisation CPU pour une tâche i est le rapport entre le temps dexécution de cettetâche et sa période . Le taux dutilisation CPU pour un groupe de tâches est la somme de cesrapports. Pour lalgorithme dordonnancement Rate Monotonic le pourcentage dutilisation CPU doitrespecter la relation suivante si on veut être sûr que toutes les dates limites des différentes tâchessoient garanties : (1) Lorsque n devient important, on remarque que pour être sûre de respecter les dateslimites des différentes tâches en utilisant lalgorithme Rate Monotonic pour ordonnancer lestâches, le processeur doit être utilisé à moins de 69 %. Dans le cas particulier où les périodes des 24
  27. 27. 2 Ordonnancement Des Tâchesdifférentes tâches sont harmoniques, une étude a montré que quelque soit le taux dutilisationCPU si lordonnancement est réalisable alors il pourra être réalisé. Pour lalgorithme dordonnancement Earliest Deadline le pourcentage dutilisation CPUdoit respecter la relation suivante si on veut être sûr que toutes les dates limites des différentestâches soient garanties : (2) Même lorsque n devient important, on remarque que quelque soit le taux dutilisationCPU, si lordonnancement est réalisable, il pourra être réalisé.III-4- Les limites des deux algorithmes: Ces algorithmes ne posent pas de problèmes dapplication tant que lon reste dans uneutilisation avec des tâches périodiques (dans le cas du Rate Monotonic seulement, le EarliestDeadline pouvant prendre en compte les tâches apériodiques), pas de protocoles (partage dedonnées entre tâches, ...), pas de surcharges. Des études ont permis lamélioration de ces algorithmes pour prendre en compte lesdifférents cas cités ci-dessus.IV- Modes dordonnancement: Lordonnancement est une fonction centrale dans un système temps réel. En fonction delapparition des entrées en provenance du système contrôlé (entraînant la demande dexécutiondune tâche), il doit réorganiser laffectation des ressources processeur en vue du respect desdates limites de chaque tâche. Lordonnancement peut se faire de deux façons. La première façon dordonnancer estlordonnancement «offline» pour lequel lordonnancement est planifié dès la conception, destables dordonnancement sont créées et vont être utilisées en fonctionnement. Durant lefonctionnement, le système se contente de lancer les tâches aux dates prévues. La deuxièmefaçon est lordonnancement online pour lequel lordonnancement est réalisé à chaque instant dufonctionnement du système. Si les ordonnancements réalisés offline donnent des systèmes trèsrapides à lexécution, et dune grande fiabilité, ils ne peuvent sappliquer quaux systèmes dont onconnaît entièrement a priori le système contrôlé. Dans le cas contraire, un ordonnancementonline est nécessaire pour replannifier les tâches à lapparition dun nouvel événement significatif[Atanas94] [Howell94]. Les algorithmes dordonnancement peuvent également être dits statiques ou dynamiques.Un algorithme dordonnancement est dit statique lorsque lordonnancement est prévisible avant la 25
  28. 28. 2 Ordonnancement Des Tâchesmise en fonctionnement du système, il faut pour cela connaître les tâches a priori. Un algorithmedordonnancement est dit dynamique lorsque lordonnancement est créé au fur et a mesure delarrivée des tâches dont on peut ne rien connaître a priori. Un ordonnancement statique est plusfiable mais moins flexible quun ordonnancement dynamique (pour un ordonnancement statiqueil faut connaître lensemble des tâches à réaliser, alors que pour un ordonnancement dynamiquece nest pas la peine de toutes les connaître) [Atanas94]. A partir de ces différentes propriétés qui sont associées aux algorithmes dordonnancement,une classification de ces algorithmes ressort : • les ordonnanceurs que lon peut qualifier de "tout planifiés". Ces ordonnanceurs sont des ordonnanceurs offline et statiques. En effet, un ordonnancement est créé à partir dune table dordonnancement qui est construite à laide des caractéristiques des différentes tâches. Cet ordonnancement est ensuite appliqué sur le système. Cette approche ne peut sappliquer que pour lordonnancement de tâches périodiques (ou qui ont été transformées en tâches périodiques) puisquil faut connaître à priori lensemble des tâches et de leurs caractéristiques. Cette approche est hautement prédictible mais nest 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 lon peut qualifier dordonnanceurs "à base de priorités". Ces ordonnanceurs sont online mais peuvent être statiques ou dynamiques. Des priorités sont affectées aux tâches, lordonnanceur va ordonnancer les tâches suivant la valeur de la priorité qui leur est affectée. Pour ce type dordonnancement apparaît la notion de préemptivité (si une tâche de basse priorité est en train dêtre exécutée et quune 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 dordonnancement peut être à priorités fixes (statiques) ou dynamiques [Atanas94]. Dans le cas dun 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 dun ordonnancement à priorités dynamiques la valeur de la priorité dune tâche va évoluer au cours du fonctionnement du système ; • les ordonnanceurs que lon 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" lorsquune tâche apparaît vont, avant de lexécuter, créer un plan dexécution de cette tâche et vérifier si ce plan va garantir son exécution. Si lexécution de cette tâche nest pas 26
  29. 29. 2 Ordonnancement Des Tâches garantie alors dautres alternatives seront envisagées (tel lenvoi 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 pasrépondre aux problèmes posés par lapparition à caractère aléatoire des événements issus dusystème contrôlé. En effet il est impossible de planifier, avant la mise en route du système,laffectation des tâches sur le ou les processeurs du système contrôlant car on ne connaît pas lesdates de demande dexécution. Les ordonnanceurs du type "dynamiques" ne peuvent passappliquer dans le domaine de lautomatique car les systèmes que nous étudions sont dessystèmes contraints et que dans le cas de ces ordonnanceurs on ne sait pas a priori si toutes lesdates 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 dordonnanceurs.V- Création dordonnancements plus complexes: Les algorithmes Rate Monotonic et Earliest Deadline sont complétés par dautresalgorithmes ou protocoles dans le but de pouvoir répondre à des spécifications du système pluscompliquées (la prise en compte de tâches apériodiques, des protocoles tels le partage desdonnées ..., le traitement des surcharges transitoires).V-1- Introduction des problèmes "dinversion de priorités" (dus aux partages de donnéespar exemple): Comme nous lavons déjà vu, un algorithme dordonnancement est préemptif lorsquaucours de lordonnancement il peut interrompre lexécution dune tâche et allouer le tempsprocesseur à une autre tâche. Par exemple lorsquune tâche de plus haute priorité arrive, le RateMonotonic ou le Earliest Deadline vont interrompre lexécution de la tâche qui est en cours pourexé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 lexécution dune 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 pluslarges du système. Les formes que prennent ces interactions sont variées, allant de la simple 27
  30. 30. 2 Ordonnancement Des Tâchessynchronisation jusquà la protection par exclusion mutuelle sur les ressources non partageables,et les relations dantériorité. Pour cela, il existe des événements, des langages de programmationconcurrente 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 destâches à haute priorité peuvent être bloquées par des tâches à priorité plus basse. Ce phénomèneest connu sous le nom dinversion de priorité. Quatre approches permettent de résoudre ceproblème : • une approche appelée "prévention dinversion 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 davoir une estimation delordonnançabilité des différentes tâches à ordonnancer.V-2- Traitement des tâches apériodiques ou sporadiques : les algorithmes "bandwithpreserving": Beaucoup de systèmes temps réel doivent traiter des tâches périodiques ainsi que destâches apériodiques. Quand on veut prendre en compte des événements apériodiques, il faututiliser une approche dynamique, telle le Earliest Deadline. Mais malgré cela, lexécution en casde surcharges transitoires pose des problèmes (Les dates limites qui ne sont pas respectées nesont pas forcément celles dont limportance pour le système est la moindre), ce cas est traité dansle paragraphe suivant. Le Rate Monotonic a été adapté pour pouvoir gérer des tâches apériodiques. Pour cela, unetâche périodique aura la fonction de servir une ou plusieurs tâches apériodiques. Différentsalgorithmes permettent de gérer cela : • le "Priority Exchange"[Sha87], • le "Deferrable Server" [Sha87], • le "Sporadic server" [Harbour91] [Sha87], • le "Slack Stealing" [Davis93]. 28
  31. 31. 2 Ordonnancement Des TâchesV-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 surchargestransitoires. Il peut se présenter des situations pour lesquelles il nest pas possible de respecter lesdates limites, le système est alors dit en exécution de surcharge transitoire. Malheureusement, une application directe du Rate Monotonic nest pas appropriée dans lecas de telles surcharges. Par exemple dans lapproche Rate Monotonic, une surcharge transitoireva amener la tâche dont la période est la plus longue à dépasser sa date limite. Cette tâche peutcependant ê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 delimportance de la tâche vis à vis du système. Ce problème peut être résolu en transformant lapériode dans le cas dune tâche importante [Burns90]. Le Earliest Deadline est un algorithme optimal lorsquil ny a pas de surcharge. Lephénomène typique qui se produit en cas de surcharge avec le Earliest Deadline est leffetdomino [Di Natal]. Pour contrôler les retards des tâches sous des conditions de surcharges, onassocie à chaque tâche une valeur reflétant limportance de chaque tâche dans le système. Alorsla gestion des tâches à partir de ces valeurs peut être réalisée par lalgorithme de Smith" [DiNatal]. Malheureusement, les contraintes dantériorité sur les tâches sont souvent générales. Uneheuristique a été proposée dans le projet SPRING, où les dates limites et les algorithmes de coûtont été combinés avec dautres algorithmes pour revoir dynamiquement ces valeurs et accorderles dates limites avec les contraintes dantériorité. Certains algorithmes heuristiques, proposéspour gérer les surcharges, améliorent lexécution du Earliest Deadline [Livny91][Thambidurai89]. 29

×