Ordonnancement temps réel

Transcription

1 Ordonnancement temps réel Ordonnancement centralisé par Francis COTTET Professeur d université (ENSMA, Poitiers Futuroscope) Ingénieur de l Institut national polytechnique de Grenoble Docteur ès sciences Joëlle DELACROIX Maître de conférences (Conservatoire national des arts et métiers, Paris) Docteur en informatique de l université Pierre-et-Marie-Curie Claude KAISER Professeur (Conservatoire national des arts et métiers, Paris) Ingénieur de l École polytechnique, ingénieur du génie maritime Docteur ès sciences et Zoubir MAMMERI Professeur d université (université Paul-Sabatier, Toulouse) Ingénieur, docteur en informatique Habilité à diriger des recherches 1. Contexte Applications temps réel Contraintes temps réel pour l ordonnancement des tâches et des messages Définitions et notions générales Architecture des applications temps réel Caractéristiques des tâches Ordonnancement temps réel Ordonnancement monoprocesseur Approches et techniques classiques pour l ordonnancement de tâches Ordonnancement pour la résolution des contraintes temporelles État de la technologie Ordonnancement multiprocesseur Position et formulation du problème Premiers résultats et comparaison avec l ordonnancement monoprocesseur Anomalies de l ordonnancement multiprocesseur Conditions d ordonnançabilité Heuristiques en ligne Conclusion Références bibliographiques L es applications temps réel sont celles où le facteur temps est la principale contrainte à respecter et où ce facteur est prépondérant pour évaluer la qualité du service. Elles concernent un large spectre d activités et se rencontrent dans la commande de procédés, les systèmes embarqués, le guidage de mobiles, la surveillance des centrales nucléaires, la conduite d expériences scientifiques, la robotique, la fourniture d images et de son pour le multimédia, le suivi opératoire en milieu médical et, même, le suivi d informations boursières. Dans un système informatique temps réel dont le fonctionnement est assujetti à l évolution dynamique d un procédé à contrôler, l ordonnancement des tâches chargées de la surveillance et de la commande de ce procédé joue un rôle capital. C est cet ordonnancement qui fait l objet de cet article. Techniques de l Ingénieur, traité Informatique industrielle S

2 ORDONNANCEMENT TEMPS RÉEL 1. Contexte 1.1 Applications temps réel La nature des contraintes temporelles des applications temps réel conduit à distinguer les contraintes strictes et les contraintes relatives. Le temps réel est à contraintes strictes quand une faute temporelle (non-respect d une échéance, arrivée d un message après les délais, irrégularité d une période d échantillonnage, dispersion temporelle trop grande dans un lot de mesures «simultanées») est intolérable parce qu elle peut entraîner une catastrophe humaine, économique ou écologique. Le temps réel est à contraintes relatives lorsque des fautes temporelles sont tolérables dans une certaine mesure. Les applications déclenchent des événements à occurrence périodique ou aléatoire et imposent au système informatique qui leur est associé de réagir avant un délai fixé ou à une date donnée. De plus, cette réaction n est créditée que d une faible marge temporelle, parce qu il faut recueillir des données fugaces, lancer ou clore rapidement des actions, envoyer ponctuellement des réponses ou des commandes. L échelle du temps peut varier selon les applications : la microseconde dans un radar, la seconde dans une interface hommemachine, une minute dans une chaîne de fabrication, une heure pour une réaction chimique. Le temps réel est un défi important pour les systèmes informatiques et est souvent mal connu. Les systèmes temps réel, quelle que soit leur taille, sont d abord caractérisés par la présence de contraintes temporelles. Leur gestion est l aspect fondamental et spécifique qui les distingue des systèmes classiques. La validité des réactions ne dépend pas seulement de la justesse des calculs, mais aussi de l instant de production des résultats. Pour une application temps réel, un résultat juste mais hors délai est un résultat faux [38] [62]. Un système informatique temps réel peut être construit : comme un générateur cyclique d actions qui captent la dynamique du procédé par échantillonnage périodique et qui lui envoient des commandes au même rythme (on parle aussi de système synchrone) ; comme un système réactif qui répond instantanément aux stimulus provenant du procédé selon la dynamique de celui-ci ; comme une organisation qui couvre ces deux aspects en ordonnançant l exécution de tâches périodiques ou apériodiques ; on parle alors de système asynchrone. 1.2 Contraintes temps réel pour l ordonnancement des tâches et des messages On qualifie de temps réel tout système informatique dont le fonctionnement est assujetti à l évolution dynamique de l état de l application temps réel. On distingue dès lors deux parties dans l application : le système informatique temps réel et le procédé auquel ce système informatique est connecté et dont il doit commander et contrôler le comportement (figure 1). Dans un système asynchrone, l ordonnancement des tâches devient un élément majeur, chargé de faire respecter les échéances des requêtes du procédé, mais aussi de résorber les surcharges ou les conséquences des pannes. Dans ce cas, il doit protéger, en priorité, contre les fautes temporelles, les tâches primordiales pour le procédé. Observations Système informatique de contrôle Calculateur Interfaces de communications (série, parallèle) Interface d'entrées / sorties numériques et analogiques Mesures Événements Commandes Affichages Procédé à contrôler Capteurs passifs ou actifs Commandes directes Actionneurs passifs ou actifs Systèmes d'affichage Procédé physique externe Affichage Consignes Sauvegarde de l'état du procédé Actions Organe de dialogue Base de données Réseaux Opérateur Figure 1 Application temps réel S Techniques de l Ingénieur, traité Informatique industrielle

3 ORDONNANCEMENT TEMPS RÉEL Exemple 1 : l ordonnancement des tâches doit faire respecter les échéances Le robot mobile déposé sur la planète Mars en juillet 1997 par la mission Pathfinder a rempli avec succès sa mission, en particulier l envoi de vues panoramiques de la planète. Mais, au bout de quelques jours, au moment d envoyer des données météorologiques, le calculateur embarqué est tombé en panne et s est entièrement réinitialisé à plusieurs reprises. La presse a rendu compte de ces pannes en rapportant que le calculateur essayait de faire trop de choses à la fois. En fait, l analyse détaillée de ces ennuis a montré qu ils provenaient d une erreur d ordonnancement causée par un phénomène connu, l inversion de priorité, que l exécutif temps réel utilisé possédait le mécanisme qui permettait de le circonscrire, à savoir l héritage de priorité, mais que les ingénieurs chargés de la mission ne l avaient pas utilisé par crainte du surcoût temporel entraîné par ce mécanisme. Le scénario exact fut le suivant. La tâche préparant les données météorologiques à envoyer se déroulait à faible priorité et utilisait en exclusion mutuelle la voie d accès aux données stockées ; pendant son exécution, la tâche d acquisition de nouvelles données, très prioritaire, s est déclenchée et a pris la main jusqu au moment où elle a buté sur la voie d accès aux données stockées, déjà utilisée et non réquisitionnable ; elle s est donc bloquée en attente de libération de cette voie d accès. Ce comportement était prévu, mais la suite n avait pas été rencontrée lors de tests et avait été jugée improbable. En effet, c est une troisième tâche déclenchée, de priorité moyenne car consacrée à l enregistrement de données météorologiques, que l ordonnancement a activée pour une longue durée, et non pas la tâche qui occupait la voie d accès. Comme, en conséquence, l échéance de la tâche d acquisition, très prioritaire et très importante pour la mission, n a pas été respectée, une alerte s est déclenchée ; le module de contrôle a cru déceler une panne grave et a lancé la réinitialisation du système. Cet exemple montre que l objectif d un ordonnancement temps réel n est pas de gagner du temps mais de savoir faire respecter par les tâches les échéances posées par le problème. On verra plus loin ce que sont l inversion de priorité et le mécanisme d héritage de priorité Exemple 2 : l ordonnancement des tâches doit tenir compte de l importance des tâches en cas de surcharge L aide aux décisions prises par des pompiers relève du même besoin de spécifier dynamiquement l importance des interventions. En général, il est moins urgent de délivrer une personne bloquée dans un ascenseur que de dégager une route coupée par des arbres qui viennent d être abattus par un orage et qui empêchent le passage des ambulances ou des véhicules de secours. C est vrai tant que la personne n est pas bloquée au sous-sol d un immeuble qui est envahi par les eaux d un torrent gonflées par l orage Exemple 3 : l ordonnancement des tâches doit, en cas de panne, contrôler la dégradation de performances Le pilotage d un mobile se fait par quatre moteurs commandés par asservissement échantillonné. Le système temps réel est composé de quatre tâches périodiques qui ont des échéances strictes et qui tournent sur quatre processeurs en utilisant chacune 60 % du temps de chaque processeur. En cas de panne d un processeur, on ne peut ni faire tourner deux tâches sur un même processeur ni changer la fréquence d échantillonnage. La seule solution, dans ce cas, consiste à supprimer un échantillon sur quatre pour chacune des quatre tâches à tour de rôle et à faire migrer l une des tâches d un processeur à un autre pour y exécuter ses échantillons dans le temps libéré. Le mobile reste pilotable, même si le confort des passagers est moins bon parce que le mobile est moins manœuvrable Exemple 4 : l ordonnancement des tâches doit pouvoir résorber les surcharges Une gestion de trafic urbain repose sur trois processeurs qui déroulent périodiquement, toutes les 0,3 secondes, trois tâches d analyse occupant chacune jusqu à 60 % du temps de chaque processeur. Devant le succès de cette gestion du régime permanent et la charge raisonnable des processeurs, on souhaite l étendre à la gestion de situations de surcharge causées par des cas urgents (police, pompiers, officiels) ou par des pointes de trafic. Pour cela, il faut ajouter une tâche de recherche d itinéraire, une tâche de commande des feux et une tâche de suivi des voitures de pompiers. Ces tâches ajoutées font passer la charge totale à 275 % (pour trois processeurs, on est au-dessous de 300 %), mais les contraintes de période et d échéance sont telles qu on ne peut trouver un placement statique des tâches et qu on ne peut s en sortir qu en plaçant dynamiquement sur des processeurs différents les requêtes successives des tâches ajoutées. Cette adaptation aux surcharges n est possible que si l on dispose d un exécutif qui sache gérer le placement dynamique des requêtes. La manœuvre automatisée de mobiles, que ce soit un bateau arrivant à quai ou un train devant s arrêter avant un butoir, est rendue difficile par l existence d une forte inertie à vaincre avant de pouvoir arrêter le mobile. La tâche chargée du freinage doit avoir alors une grande importance, plus grande que toute autre, y compris la tâche de blocage de la fermeture des portes. Cependant en haute mer ou entre deux gares, il est plus vital de maintenir les portes fermées. On doit pouvoir spécifier des priorités d actions en fonction du contexte observé Exemple 5 : l ordonnancement des messages doit prendre en compte les contraintes de temps Le mélange de scènes actuelles et de scènes d archives dans une émission de télévision interactive entraîne l appel, à la demande des auditeurs, d images vidéo stockées dans une médiathèque. Cette banque d images est située sur un site serveur qui doit envoyer au site pilote de l émission un flux régulier d images accompagnées par leur son bien synchronisé. Les flux de messages pour le son et l image ont des contraintes de délai, de régularité et de synchronisme qui doivent être prises en considération par l ordonnancement temps réel des messages. Techniques de l Ingénieur, traité Informatique industrielle S

4 ORDONNANCEMENT TEMPS RÉEL 2. Définitions et notions générales 2.1 Architecture des applications temps réel Démarche d analyse et de construction Il est habituel de dégager des étapes pour analyser et construire une application. On distingue souvent : l établissement du cahier des charges et des spécifications fonctionnelles et temporelles qui sont à l origine d une organisation fonctionnelle (on essaie de répondre à la question : que faire?) ; l analyse opérationnelle accompagnée du choix des unités logiques, ce qui aboutit à une architecture logique (c est la question : comment faire?) ; l analyse organique et le choix des matériels qui débouchent sur une architecture physique (la question : avec quels moyens?). Une fois définies les architectures logique et matérielle se pose alors la politique de répartition du logiciel sur le matériel, ce qu on appelle le placement. Dans les systèmes temps réel répartis, nous serons concernés par le placement des tâches et par leur éventuelle migration. L analyse opérationnelle doit déterminer des entités logiques de base pour traduire le découpage des charges et, ce qui nous concerne ici, pour exprimer la concurrence entre les actions réalisant les fonctions demandées. Le comportement opérationnel de l application résulte de leur exécution concurrente. Les principales entités informatiques de base sont souvent classées en : objets passifs : ressources physiques (matériels informatiques, capteurs, commandes des actionneurs) et ressources logiques (zones de mémoire, fichiers, logiciels de base) ; objets de communication : messages ou variables partagées, porte («port»), canaux, réseaux ; objets de synchronisation : événements, sémaphores, conditions, moniteurs (Modula), rendez-vous et objets protégés (Ada) ; objets actifs : processus (process), activités (thread), tâches (task) ; objets de structuration, de composition ou de regroupement d entités : module, paquetage (Ada), acteur (Chorus), processus (Unix, Mach). Le terme de tâche est le plus souvent utilisé dans le domaine du temps réel comme unité de représentation des activités concurrentes de l architecture logique. Pour découper une application en tâches concurrentes, on examine habituellement le parallélisme physique présent dans l architecture support et le parallélisme logique de l application. On peut ainsi associer une tâche à chaque processeur et à chaque organe d entrée ou sortie : lecteur de disque, imprimante, clavier, écran, actionneur, capteur. On peut encore associer une tâche à chaque activité de fonctionnalité différente : calcul, acquisition, présentation, client, serveur, gestionnaire d objets, ou à chaque activité de comportement différent : périodique, apériodique, réactive, cyclique, selon échéance ou importance. Caméra Radio Module satellisé autour de MARS Processeur Mémoires Interface 1 Interface 2 Interface bus Bus VME Bus Coupleur Interface 1 Interface 2 Interface 3 Interface 4 Moteurs Vannes Capteur solaire Analyseur étoiles Module posé sur MARS Bus Coupleur Interface 5 Interface 6 Interface 7 Accéléromètre Altimètre Enregistreur météo (ASI/MET) Figure 2 Architecture physique monoprocesseur de Mars Pathfinder S Techniques de l Ingénieur, traité Informatique industrielle

5 ORDONNANCEMENT TEMPS RÉEL Architecture physique Les architectures matérielles pour le temps réel sont caractérisées par l importance des entrées-sorties pour le temps réel (par exemple, le bus VME sur les figures 2 et 3). Nous avons cité au paragraphe 1.2 le cas du robot mobile de la mission Pathfinder. Le calculateur embarqué avait la configuration donnée sur la figure 2. La figure 3 représente une architecture multiprocesseur à mémoire commune [3]. Les architectures distribuées en réseau se développent de plus en plus. L article [S 8 056] Ordonnancement temps réel réparti de ce traité les prend en compte. On utilise le terme de sites interconnectés. La figure 4 donne le schéma d une architecture de plusieurs sites interconnectés par un réseau local Architecture logique et systèmes informatiques temps réel Systèmes informatiques Afin de situer les systèmes temps réel, nous faisons un très bref rappel sur les systèmes informatiques que l on peut classer, comme dans l encadré 1, en systèmes transformationnels, interactifs et réactifs, ces derniers incluant le temps réel asynchrone. Activation processeur Interruptions VME BUS VME C P U 1... C P U 4 M E M 1... M E M 6 I N T E R V M E B D V M E B D I / O B D BUS MÉMOIRE CPU1...CPU4 : processeurs MEM1...MEM6 : mémoires partagées VMEBD, I/OBD : coupleurs INTER : centrale d'interruption Figure 3 Architecture multiprocesseur Dune 3000 Camions de livraison Machines-outils Machines-outils Site de calculs Site procédé Site produits Site procédé Réseau local Site réseau Site archivage Site stocks Site procédé Base de données techniques Manipulateur et convoyeur Machines-outils Postes opérateurs pour présentation synoptique Figure 4 Architecture répartie pour temps réel Techniques de l Ingénieur, traité Informatique industrielle S

6 ORDONNANCEMENT TEMPS RÉEL Programmes et tâches de l'application Plate-forme professionnelle Bibliothèques de programmes Base de données API spécifiques plate-forme Messagerie Gestion des tâches Interfaces Homme-machine Service de noms Services du système d'exploitation Gestion de mémoire Gestion de fichiers Gestion d'objets Noyau exécutif API systèmes spécifiques API systèmes standardisées (POSIX...) Sémaphores Ordonnancement des processeurs Gestion des interruptions Gestion de l'horloge Gestion MMU Pilotes périphériques Pilotes réseaux MMU : Memory Management Unit Matériel API : Application Programming Interface Figure 5 Architecture d un système informatique Encadré 1 Classes de systèmes informatiques Systèmes transformationnels Ils gèrent des programmes dont : les résultats sont calculés à partir de données disponibles dès l initialisation du programme ; les instants de production des résultats ne sont pas contraints. Systèmes interactifs Ils gèrent des programmes dont : les résultats sont fonction de données produites par l environnement du programmeur ; les instants de production des résultats ne sont pas contraints : temps partagé : assurer un temps de réponse court pour des demandes indépendantes (édition, compilation, calcul, consultation multimédia), transactionnel : garantir le contrôle et la cohérence d accès à des «fichiers» partagés (bases de données) en consultation et mise à jour. Systèmes réactifs Ils gèrent des programmes dont : les résultats sont fonction de données produites par l environnement (le procédé à contrôler) ; les instants de production des résultats sont contraints par la dynamique du procédé contrôlé : temps réel : contrôle de processus industriels, de trafic, de production. On dira qu un système est centralisé lorsque les décisions, la gestion des ressources, l algorithmique et la cohérence des données sont déterminées par l existence d informations dans une mémoire commune accessible à toutes les tâches du système. Cette définition est indépendante de l architecture matérielle support. Cela s applique à une architecture monoprocesseur ou multiprocesseur à mémoire commune, mais aussi à une architecture répartie où toutes les décisions sont prises sur un seul site. On dira qu un système est réparti lorsque les décisions sont prises après concertation par envoi de messages entre sites. L algorithmique répartie doit s adapter à un univers incertain qui n a ni mémoire ni horloge communes à tous les sites, où le délai de propagation des messages est variable d un site à un autre et d un message à un autre, où le risque de défaillance est important. Les sites n ont jamais les mêmes informations disponibles simultanément, et, comme la date est une de ces informations, ils ne sont pas capables de déterminer instantanément, en consultant une horloge, s ils sont «à la même date». On retrouvera plus en détail ces points dans l article [S 8 056] sur l ordonnancement réparti de ce traité. Les systèmes informatiques sont structurés en couches de manière à faciliter leur évolution. Ils comportent tous un noyau exécutif comme le montre la figure 5. Ce noyau comprend les mécanismes pour la gestion de base du processeur, de la mémoire virtuelle, des interruptions et des communications. Les politiques de gestion plus élaborées pour l allocation globale de ces ressources, la gestion des autres ressources, se retrouvent dans les couches supérieures. Les systèmes informatiques classiques prennent des décisions d allocation de ressource et, en particulier, d ordonnancement des tâches, en appliquant des politiques globales en vue d optimiser l utilisation des ressources ou de favoriser le temps de réponse de certaines catégories de tâches, comme les tâches interactives. Toutes les tâches sont considérées comme apériodiques ; ni leurs dates d arrivées, ni leurs durées ne sont connues et elles n ont pas d échéances. Dans un système classique, les ressources partagées allouées dynamiquement aux tâches sont principalement la mémoire principale et le processeur. Les études de comportement de programme ont montré que la ressource sensible était la mémoire centrale (c est encore plus sensible dans un système paginé avec va-et-vient entre mémoire principale et disque). Aussi alloue-t-on d abord la mémoire selon des algorithmes d allocation souvent compliqués ; le processeur est alloué en dernier. Cet ordre d allocation entraîne la relative simplicité de l ordonnancement du processeur qui ne porte que sur le petit nombre de tâches déjà servies en mémoire [5] [64] Les exécutifs temps réel Dans un système temps réel, les ressources, autres que le processeur, sont souvent attribuées statiquement aux tâches, au moment de leur création. En particulier, on ne peut accepter la perte de temps que cause l allocation dynamique de la mémoire. Les fichiers temps réel et les bases de données temps réel sont en mémoire centrale. Le principal paramètre d allocation est le temps processeur, ce qui explique que le noyau prend une grande importance dans les schémas de présentation et que l on utilise plutôt le terme d exécutif temps réel (figure 6). S Techniques de l Ingénieur, traité Informatique industrielle

7 ORDONNANCEMENT TEMPS RÉEL Ses échéances successives sont : d k = r k + R Actionneurs Procédé Tâches Exécutif temps réel Gestion des tâches, des interruptions, des messages, ordonnanceur Système informatique temps réel Système de contrôle Figure 6 Application temps réel 2.2 Caractéristiques des tâches Modèle canonique des tâches temps réel Les tâches sont les entités de base de l ordonnancement temps réel et elles sont périodiques ou apériodiques, à contraintes temporelles strictes ou relatives. Aussi a-t-on défini un modèle canonique qui regroupe les principaux paramètres temporels qui peuvent caractériser les tâches temps réel et guider l ordonnancement temps réel. Dans ce modèle, une tâche (figure 7) est définie par des paramètres chronologiques qui dénotent des délais et des paramètres chronométriques qui indiquent des dates, soit : r, sa date de réveil, c est-à-dire le moment de déclenchement de la requête d exécution ; C, sa durée d exécution maximale quand elle dispose du processeur pour elle seule ; R, son délai critique, c est-à-dire le délai maximal acceptable pour son exécution ; P, sa période lorsqu il s agit d une tâche périodique. Pour une tâche à contraintes strictes, le délai critique permet de calculer l échéance d = r + R ; c est la date dont le dépassement entraîne une faute temporelle. Quand la tâche est à contrainte relative, le délai critique R est parfois omis. Pour une tâche apériodique, le paramètre P n est pas donné. Lorsque la tâche est périodique, les quatre paramètres sont présents. Chaque réveil déclenche une requête de la tâche périodique. Ses dates de réveil successives, celles de chaque requête, sont : r k = r 0 + kp avec r 0 premier réveil, r k k e réveil. Capteurs Si R = P, la tâche périodique est à échéance sur requête. Une tâche est bien formée quand : 0 B C B R B P La qualité de l ordonnancement sera d autant meilleure que les valeurs de ces paramètres seront exactes ; aussi la détermination de ces paramètres est-elle souvent un aspect important de l analyse et de la conception d une application temps réel. En particulier, il faut savoir si l on néglige ou non les temps de commutation de tâches, les durées d utilisation des primitives du système d exploitation, les durées de prise en compte des interruptions et les durées d exécution de l ordonnanceur. Si l on ne peut les négliger, l analyse conceptuelle doit les estimer et les inclure dans la durée d exécution de la tâche. C est pourquoi on demande à un noyau exécutif temps réel d avoir un comportement prédictible, ce qui se traduit en exigence de valeurs maximales garanties pour le temps de commutation de tâches, le temps de prise en compte d une interruption et le temps d exécution des services du système (les primitives ou les API). D autres paramètres, dérivés des paramètres de base, servent à suivre l exécution de la tâche : u = C/P est le facteur d utilisation du processeur pendant la période ; on doit avoir u B 1 ; ch = C/R est le facteur de charge du processeur ; on doit avoir ch B 1 ; s est la date du début de l exécution de la tâche ; e est la date de la fin de l exécution de la tâche ; on a e b s + C ; R(t) = d t est le délai critique résiduel ou délai critique dynamique à la date t ; on a 0 B R() t B R ; C(t) est la durée d exécution résiduelle à la date t ; on a 0 B C() t B C ; LN = R C est la laxité nominale de la tâche et indique le retard maximal pour son début d exécution s quand la tâche s exécute seule ; LN(t) = R(t) C(t) est la laxité nominale résiduelle ou laxité dynamique ; c est le retard maximal pour reprendre l exécution quand la tâche s exécute seule ; on a encore LN(t) = R + r t C(t) ; TR = e r est le temps de réponse de la tâche ; on a C B TR B R ; CH(t) = C(t)/R(t) est la charge résiduelle ; on a (par définition si e = d, CH(e) = 0). r P R Figure 7 Modèle canonique des tâches C r + P 0 B CH() t B u Temps Une tâche est définie par : r Date de déclenchement de la requête Déclenchement C Durée d'exécution R Délai critique Échéance r + R P Période de la tâche 0 < C < R < P Techniques de l Ingénieur, traité Informatique industrielle S

8 ORDONNANCEMENT TEMPS RÉEL Prête Figure 8 États d une tâche f Inexistante Passive Élue Bloquée f : cas où la requête est interrompue à son échéance Les tâches périodiques sont déclenchées à la date de réveil des requêtes successives et redeviennent passives une fois la requête terminée. Les tâches apériodiques peuvent avoir le même comportement si elles peuvent se déclencher plusieurs fois ; elles peuvent aussi plus rarement être créées au moment du réveil. Une tâche créée évolue entre deux états : passive et déclenchée. Le partage du processeur et des ressources introduit plusieurs états pour une tâche déclenchée (figure 8) : élue : un processeur est alloué à la tâche et elle exécute son programme ; C(t) diminue ; bloquée : la tâche attend une ressource, un message ou un signal de synchronisation ; prête : la tâche attend d être élue Autres caractéristiques des tâches En dehors des paramètres temporels du modèle canonique, d autres caractéristiques des tâches permettent de les distinguer. Tâche préemptible ou non préemptible Certaines tâches, une fois élues, ne doivent plus être arrêtées avant la fin de la requête. Elles sont non préemptibles. C est le cas de tâches qui s exécutent sous le contrôle du mécanisme d interruption ou de tâches qui effectuent des entrées et sorties directement sur un bus sans passer par un organe intermédiaire appelé DMA. Ce sont des tâches, souvent appelées immédiates, dont l exécution doit être atomique. Au contraire, quand la tâche élue peut être arrêtée et remise à l état prêt pour réquisitionner le processeur au profit d une autre tâche, on dit que la tâche est préemptible. Dépendance et indépendance des tâches Les tâches peuvent interagir selon un ordre partiel prédéterminé ou induit par la communication de message ou par une relation explicite de synchronisation. Il peut alors en résulter une relation de précédence entre tâches. Cette relation est dite statique, car elle est connue a priori et n évolue pas. Elle est représentée par un graphe de dépendance. Les tâches peuvent partager d autres ressources que le processeur et certaines ressources, dites exclusives ou critiques, imposent aux tâches de les utiliser en exclusion mutuelle. La suite des instructions d une tâche pendant laquelle cette exclusion mutuelle doit être respectée est appelée une section critique. Une seule tâche peut se f trouver en section critique pour une ressource donnée. Ce partage de ressources induit une relation dynamique lorsque l ordre d utilisation de la ressource dépend de l ordre d exécution des diverses tâches. La relation peut être représentée par un graphe d allocation. Lorsque des tâches ont des dépendances statiques ou dynamiques qui les sérialisent, on introduit la notion de temps de réponse global, appelé aussi délai de bout en bout dans le cas des messages. Il correspond au délai écoulé entre le date de réveil de la tâche qui reçoit le stimulus envoyé par le procédé et la fin de la dernière tâche de la série qui envoie la commande en réaction à ce stimulus. Les tâches sont dites indépendantes lorsqu elles n ont entre elles ni relation de précédence ni partage de ressource critique. Priorité externe On introduit parfois à la conception une priorité fixe dite priorité externe. C est une forme primitive d ordonnancement temps réel où tout est déterminé dès la conception par un ordonnancement hors ligne ou par des règles qui imposent un ordre a priori (par exemple, la tâche de gestion d horloge ou la tâche de sauvegarde en cas de chute de courant sont à exécuter toutes affaires cessantes). Gigue maximale L exécution de tâches périodique est parfois soumise à des contraintes de régularité pour le début de leur exécution. C est le cas dans l acquisition de données par échantillonnage périodique, ou dans une régulation par PID ou dans l envoi continu de son et d images pour le multimédia. La variation entre le début d exécution de deux requêtes successives est appelée gigue et on définit pour ces applications une gigue maximale à ne pas dépasser : Ð max B ( s i + 1 Ð ( s i + P) ) B max Nota : PID : Proportionnel Intégral Dérivé. Importance Lorsque qu on veut introduire, pour un ensemble de tâches, la capacité de résister aux fautes temporelles de certaines d entre elles, en évitant, en particulier, que les fautes temporelles ne se propagent, le système de contrôle doit pouvoir supprimer l exécution de certaines tâches. Il faut lui indiquer quelles tâches il peut supprimer en premier ou, au contraire, quelles sont les tâches, primordiales pour l application, à ne pas supprimer. On introduit un paramètre d importance qui traduit la gravité ou la priorité opérationnelle de la tâche. Ainsi deux tâches de même échéance peuvent être distinguées par des importances différentes Modèles de tâches pour la tolérance aux fautes temporelles Plusieurs modèles de tâches ont été introduits pour éviter qu en cas de faute temporelle tout le travail réalisé par la tâche avant la panne ne soit perdu. Dans le plus ancien modèle proposé [9], chaque tâche a deux versions, une version primaire qui fournit le service demandé mais dont l exécution peut entraîner une faute temporelle parce que la durée d exécution peut varier considérablement, et une version secondaire qui fournit un service dégradé mais acceptable et sans faute temporelle. Selon les politiques d ordonnancement, on essaie d abord l une ou l autre version mais, dans tous les cas, il faut que la version secondaire s exécute sans faute. Une autre approche est celle du calcul imprécis (ou progressif ou par contrat) où chaque tâche est décomposée en deux parties, la partie mandataire et la partie optionnelle. La partie mandataire doit obligatoirement s exécuter dans le respect de son échéance et elle fournit un résultat approché. La partie optionnelle affine ce premier résultat et est exécutée pendant le temps restant avant l échéance. S Techniques de l Ingénieur, traité Informatique industrielle

9 ORDONNANCEMENT TEMPS RÉEL Dans une approche récente, une tâche présente plusieurs modes de fonctionnement, un mode normal et un mode de survie qui est exécuté quand une requête est supprimée, soit parce que son échéance est arrivée, soit parce qu elle a été sacrifiée au profit d une autre tâche plus importante. Le mode de survie a une durée très courte mais il permet à la tâche de rendre une ressource partagée ou de terminer un calcul dans un état exploitable. L échéance de la tâche est fixée pour permettre l exécution du mode normal et du mode de survie [23]. 2.3 Ordonnancement temps réel Configuration de tâches L application met en jeu un ensemble de n tâches qu on appelle une configuration de tâches. Départ simultané ou échelonné Les tâches d une configuration sont dites à départ simultané si elles ont toutes la même première date de réveil, sinon elles sont à départ échelonné. Facteur d utilisation du processeur Le facteur d utilisation du processeur par une configuration est : U = Σ(u i ), pour tout i Facteur de charge du processeur Le facteur de charge du processeur par une configuration est : CH = Σ(ch i ), pour tout i Laxité du processeur pour une configuration donnée À cause des contraintes d échéances, ni le facteur d utilisation, ni le facteur de charge ne sont suffisants pour connaître l incidence d une surcharge sur le respect des contraintes. On introduit LP(t), la laxité du processeur à l instant t comme l intervalle de temps maximal pendant lequel le processeur peut rester inactif à partir de la date t, sans perdre le respect des échéances des tâches de la configuration. LP(t) varie en fonction de t. Il faut que l on ait : LP () t b 0, pour tout t Pour calculer cette laxité, il faut connaître la séquence de planification des tâches et, dans le contexte de cette séquence, calculer la laxité conditionnelle LC i (t) de chaque tâche i ; LC i (t) = R i ΣC j (t) où la somme en j se fait sur toutes les tâches qui sont déclenchées à la date t et qui sont devant la tâche i dans la séquence de planification, et prendre LP(t) comme la plus petite des laxités conditionnelles LC i (t). Temps creux du processeur On dénote la suite des intervalles de temps où la laxité du système reste strictement positive comme la suite des temps creux. Cette suite dépend de la configuration de tâches et de son ordonnancement Définition du problème d ordonnancement des tâches Le système de conduite d une application temps réel doit piloter le procédé en ordonnançant les tâches avec deux objectifs majeurs : en fonctionnement nominal, assurer le respect des contraintes temporelles spécifiées ; en fonctionnement anormal dû à des pannes matérielles ou à d autres événements imprévus, atténuer les effets des surcharges temporelles et maintenir le procédé dans un état cohérent et sécuritaire. Ordonnancer les tâches d une application temps réel consiste alors à planifier l exécution de requêtes de façon que soient respectées les contraintes de temps : de toutes les requêtes en fonctionnement nominal ; d au moins les requêtes les plus importantes, c est-à-dire celles qui sont nécessaires à la sécurité du procédé, en fonctionnement anormal. Selon les applications, on cherche en plus à satisfaire certains critères de performance comme minimiser le temps de réponse ou réduire la gigue de certaines tâches, équilibrer la charge des sites, minimiser la charge de communication, minimiser le nombre ou le retard cumulé des tâches ou des messages tardifs. Cette planification est faite par un algorithme d ordonnancement qui fournit une description de la séquence à effectuer par les tâches, appelée séquence de planification Nature des algorithmes d ordonnancement En ligne ou hors ligne On distingue les algorithmes hors ligne et les algorithmes en ligne. Un algorithme d ordonnancement hors ligne construit une séquence complète de planification sur la base de tous les paramètres temporels de tâches. Cette séquence est connue avant l exécution des tâches et peut être mise en œuvre très efficacement. Toutefois, cette approche statique est très rigide ; elle suppose que tous les paramètres, y compris les dates de réveil, soient figés et ne peut s adapter aux changements de l environnement. Un algorithme d ordonnancement en ligne est capable, à tout instant de l exécution de l application, de choisir la prochaine tâche à ordonnancer et il utilise comme informations les paramètres temporels des tâches déclenchées à cet instant. Ce choix peut être remis en cause lors de l occurrence d un événement nouveau sans que la date de cette occurrence n ait à être connue à l avance. Cette approche dynamique donne des solutions qui sont moins bonnes que celles de l approche statique puisqu on utilise moins d information et les surcoûts de mise en œuvre sont plus importants. Mais elle permet l arrivée imprévisible de tâches et elle autorise la création progressive de la séquence d ordonnancement. Pour pouvoir traiter les tâches apériodiques et les surcharges anormales, l ordonnancement temps réel se fait en ligne le plus souvent. Préemptif ou non préemptif Un algorithme d ordonnancement est soit préemptif soit non préemptif. Dans le premier cas, une tâche élue peut perdre le processeur au profit d une autre tâche jugée plus urgente ou plus prioritaire ; elle passe à l état prêt pour attendre d être élue ultérieurement sur le même processeur ou sur un autre. Un algorithme préemptif n est utilisable que si toutes les tâches sont préemptives. Les ordonnanceurs non préemptifs n arrêtent pas l exécution des tâches élues. Il peut en résulter des temps de réponse plus longs qu avec un ordonnancement préemptif. En architecture monoprocesseur, la gestion des ressources critiques est simplifiée car elle ne nécessite plus de mécanisme de gestion de concurrence d accès aux ressources (mécanismes d exclusion mutuelle et de file d attente) ; toutefois cette simplification n est plus vraie en architecture multiprocesseur. Techniques de l Ingénieur, traité Informatique industrielle S

10 ORDONNANCEMENT TEMPS RÉEL Meilleur effort ou inclémence aux fautes temporelles Pour une application à contraintes temporelles relatives, on dit que la stratégie d ordonnancement est celle du meilleur effort : elle essaie de faire au mieux avec les processeurs disponibles. L application a des facultés de tolérance aux fautes temporelles. Pour une application à contraintes strictes, la stratégie d ordonnancement doit garantir le respect des contraintes. Il y a obligation de réussite et inclémence aux fautes temporelles. Centralisé ou réparti L ordonnancement est centralisé s il s exécute sur une architecture centralisée ou sur un site privilégié de l architecture distribuée qui contient l ensemble des paramètres des tâches. L ordonnancement est réparti lorsque des décisions d ordonnancement sont prises sur chaque site par un ordonnancement local après une éventuelle coopération pour effectuer un ordonnancement global. Dans ce dernier cas peut intervenir le placement des tâches sur un site et leur migration d un site à un autre Propriétés des algorithmes Séquence valide Un algorithme d ordonnancement délivre une séquence d ordonnancement pour une configuration de tâches données. Cette séquence est valide si toutes les tâches de la configuration respectent leurs contraintes. Configuration ordonnançable Une configuration de tâches est ordonnançable dès qu il existe un algorithme au moins capable de fournir une séquence valide pour cette configuration. Algorithme optimal Un algorithme est optimal s il est capable de produire une séquence valide pour toute configuration de tâche ordonnançable. Test d acceptabilité Un algorithme en ligne crée ou modifie la séquence dynamiquement à l arrivée de nouvelles tâches ou à la suite de dépassement d échéance. Une tâche nouvelle peut être ajoutée à la séquence déjà formée, ou en cours de modification à la suite de suppression, et être acceptée s il existe au moins une séquence pour laquelle toutes les tâches précédemment acceptées et cette tâche nouvelle peuvent terminer leur exécution avant leur échéance. L ensemble des conditions à satisfaire est appelé test d acceptabilité. On dit parfois test de garantie car, si les tâches ne dépassent pas leurs durées d exécution (auxquelles s ajoutent les durées d attente pour obtenir les ressources critiques), on peut garantir alors que les tâches ne font pas de faute temporelle. Dans un ordonnancement réparti, le rejet d une tâche par un test d ordonnançabilité sur un site peut avoir comme conséquence d essayer de faire migrer la tâche. Période d étude L étude pour valider une configuration de tâches périodiques et apériodiques conduit à faire une analyse temporelle de l exécution de cette configuration. Quand les tâches sont périodiques, cette exécution dure indéfiniment. En fait, le comportement de la configuration est périodique et il suffit d en analyser une période dite période d étude, ou pseudo-période ou période de validation [40]. La période d étude commence à la première date de réveil d une tâche de la configuration : min(r 0i ) pour toutes les tâches i de la configuration. Elle se termine à une date qui est fonction du plus petit commun multiple des périodes P i : pour une configuration de tâches périodiques, c est la date : max(r 0i ) + PPCM(P i ) pour toutes les tâches i de la configuration ; pour une configuration de tâches périodiques et apériodiques, c est la date : max(r 0i, r 0j + R j ) + 2 PPCM(P i ) pour toutes les tâches périodiques i et apériodiques j Typologie des techniques d ordonnancement La mise en œuvre de l ordonnancement fait appel aux structures de données classiques en informatique. Table d élection Lorsque la séquence de planification est fixée avant le démarrage de la configuration, cas de l ordonnancement hors ligne, cette séquence définitive peut être inscrite dans une table que l ordonnanceur consulte pour élire la prochaine tâche. Liste d attente avec priorité L ordonnancement en ligne crée dynamiquement une séquence de planification dont le premier élément indique la tâche élue (dans une architecture à n processeurs, ce sont les n premiers éléments qui sont élus). Cette séquence est une liste ordonnée par une relation d ordre sur des clés où la recherche (et la suppression) se fait sur l élément de clé minimal et où l ajout d un élément se fait par insertion dans la liste triée selon les clés. Cette structure est classiquement appelée un tas ou une liste d attente avec priorité [12]. Priorité constante ou variable La clé d un élément, appelée priorité dans le cas des tâches, est un paramètre temporel du modèle de tâches ou une combinaison de paramètres. Elle reste constante si l on prend un paramètre fixe comme la durée d exécution, le délai critique, la période ou une priorité externe. Elle est variable si l on prend un paramètre qui varie au cours de l exécution d une tâche comme le délai critique résiduel, la durée d exécution résiduelle ou la laxité résiduelle, ou encore un paramètre qui varie d une requête à une autre comme la date de réveil ou l échéance. La priorité ou clé de classement peut être la valeur du paramètre retenu ou, si l ensemble des valeurs est trop grand, une fonction injective de cette valeur. C est cela qu on appelle usuellement la priorité. L ensemble des valeurs de la priorité peut être fixé a priori dans une architecture matérielle ou dans un noyau d exécutif temps réel. Cela permet d accélérer la gestion des files d attente en codant cette priorité avec un mot de taille fixée (de type octet ou entier) ou en utilisant des instructions machine spéciales. Ordonnancement à deux niveaux Dans les ordonnanceurs complexes, l ordonnancement est découpé en deux parties, l une qui élabore la politique (décisions de haut niveau ou à long terme, choix de suppression de tâches en cas de surcharge, volonté de favoriser momentanément certaines tâches dans un ordonnancement hiérarchique), l autre qui exécute les mécanismes finaux (élection d une tâche dans le sous-ensemble défini par l ordonnanceur de haut niveau, réorganisation de ce sousensemble par des choix à court terme). Un cas particulier de découpage est celui de l ordonnancement réparti où l on distingue l ordonnancement local qui traite les tâches présentes sur un site et l ordonnancement global qui décide du placement et de la migration des tâches. Dans ce cadre se pose encore le choix de l ordre entre ordonnancement global et ordonnancement local et le coût de chaque choix : faut-il placer les tâches a priori puis les faire migrer si le site de placement est surchargé, S Techniques de l Ingénieur, traité Informatique industrielle

11 ORDONNANCEMENT TEMPS RÉEL Niveau de priorité croissant Tâche T1 Tâche T2 Délai ajouté par l'inversion de priorité Faute temporelle Tâche T3 Tâche T4 Tâche élue Tâche élue occupant la ressource Tâche terminée Déclenchement de tâche Échéance Tâche demandant la ressource Figure 9 Inversion de priorité ou faut-il interroger les sites sur leur capacité d accueil avant de placer une tâche (ou une requête) déclenchée? Inversion de priorité Dans un ordonnancement préemptif, la présence simultanée de priorités fixes et de ressources à accès exclusif peut entraîner un phénomène appelé inversion de priorité (figure 9) [36] [56]. Exemple : soit quatre tâches de priorité décroissantes, T1, T2, T3 et T4. À un instant donné seule T4 est déclenchée et a obtenu une ressource critique. Puis T1, T2 et T3 sont réveillées par un événement externe. L ordonnanceur préemptif à priorités élit T1. Supposons que T1 réclame la ressource critique déjà allouée à T4. Comme cette ressource ne peut être réquisitionnée pour T1, cette tâche doit attendre que T4 la libère. L ordonnanceur à priorité élit donc T2, puis T3, qui s exécutent. Ce n est qu après leur exécution que l ordonnanceur peut élire T4 qui peut alors finir d utiliser la ressource critique et, enfin, la libérer. Et seulement alors, T1, la tâche la plus prioritaire, peut s exécuter. Le temps de réponse de T1 s est rallongé du temps d exécution de T2 et T3, moins prioritaires qu elle. Cela peut parfois entraîner un dépassement d échéance, comme on l a vu dans l exemple de Pathfinder dans le paragraphe 1.2. Comme les utilisations de ressources critiques sont souvent imbriquées, toute solution à ce problème doit en tenir compte Interblocage Supposons que les deux tâches T1 et T2 ont besoin chacune de deux ressources exclusives r1 et r2 et que ces ressources ne peuvent pas être retirées à une tâche qui les utilise en section critique. Si T1 demande successivement r1 et r2 et si T2, au contraire, demande r2 puis r1, les deux tâches peuvent parfois s attendre mutuellement indéfiniment comme dans le cas décrit sur la figure 10 a. C est une situation d interblocage, qui peut se généraliser à tous les cas d attente circulaire entre plusieurs tâches, et dont on ne peut sortir qu en détruisant une ou plusieurs tâches. Pour une application temps réel, c est une situation inacceptable. Une méthode, appelée la méthode des classes ordonnées, permet d éviter que l interblocage puisse se produire, en programmant la demande des ressources selon le même ordre pour toutes les tâches [29]. Elle n est applicable que si l on connaît, dès la programmation, toutes les ressources que les tâches vont appeler. C est pourquoi on dit que c est une méthode de prévention statique. Dans l exemple de la figure 10 b, l interblocage ne peut jamais se produire si les deux tâches demandent r1 puis r2. 3. Ordonnancement monoprocesseur 3.1 Approches et techniques classiques pour l ordonnancement de tâches Objectifs de l ordonnancement dans un système classique Dans un système multiprogrammé classique, les principaux rôles de l ordonnancement sont au nombre de deux. Ce sont : maximiser le taux d occupation du processeur, c est-à-dire le rapport entre le temps où le processeur est actif et le temps total. En théorie, ce taux peut varier entre 0 % et 100 % ; dans la pratique, on peut observer un taux d occupation variant entre 40 % et 95 % ; minimiser le temps de réponse des tâches, c est-à-dire la durée séparant l instant de soumission de la tâche au système de la fin d exécution de la tâche. Au mieux, le temps de réponse peut être exactement égal au temps d exécution de la tâche, lorsque la tâche a immédiatement été élue et s est exécutée sans être préemptée. L obtention de ces deux résultats par une politique d ordonnancement donnée peut être directement évaluée par le calcul du taux d occupation et par le calcul des temps de réponse, mais il existe d autres critères d évaluation qui s y rapportent également. Nous en citons quelques-uns ci-dessous : Techniques de l Ingénieur, traité Informatique industrielle S

12 ORDONNANCEMENT TEMPS RÉEL Tâche T1 Tâche T2 Tâche T1 Tâche T2 1 1 Tâche élue Figure 10 Interblocage évaluation du temps d attente des tâches, c est-à-dire du temps passé dans l état prêt ; évaluation de la capacité de traitement ou du débit du processeur, c est-à-dire du nombre moyen de tâches traitées par unité de temps ; temps de traitement total d un ensemble de tâches donné ; temps de réponse moyen d un ensemble de tâches donné, c est-à-dire la moyenne des temps de réponse de chacune des tâches de l ensemble Principales politiques b 2 a 1 Tâche élue utilisant 1 Tâche élue utilisant 2 1 interblocage 2 La politique d ordonnancement du processeur détermine quelle tâche présente dans la file des tâches prêtes est élue. Nous allons décrire ci-dessous les principales politiques mises en œuvre dans les systèmes classiques. Politique d ordonnancement «premier arrivé, premier servi» C est une politique à l ancienneté, sans réquisition ; l unité centrale est allouée selon l ordre de soumission des tâches. Dans cette politique, des tâches de faible temps d exécution peuvent être pénalisées parce qu une tâche de longue durée les précède dans la file. Politique d ordonnancement «plus court d abord» Cette politique tente de remédier à l inconvénient mentionné pour la politique précédente. Maintenant, l unité centrale est allouée à la tâche de plus petit temps d exécution. Cette politique est également une politique sans réquisition. Elle a la propriété de minimiser le temps de réponse moyen pour l ensemble des algorithmes d ordonnancement sans réquisition. Elle pénalise les travaux longs. Elle impose également d estimer la durée des tâches, ce que l on ne connaît pas habituellement. Il existe une version avec réquisition de cette politique, appelée «temps restant le plus court d abord» : dans ce cas, la tâche en exécution restitue le processeur lorsqu une nouvelle tâche de temps d exécution inférieur à son temps d exécution restant devient prête. 2 classes ordonnées Tâche élue utilisant 1 et 2 2 Interblocage Tâche terminée Politique d ordonnancement par tourniquet (Round Robin) On définit une tranche de temps appelée quantum qui peut varier de 10 ms à 100 ms. Chaque tâche présente dans la file des tâches prêtes acquiert le processeur à tour de rôle, et ce pour au maximum un temps égal au quantum de temps. Si la tâche a terminé son exécution avant la fin du quantum, elle libère le processeur et la tâche suivante dans la file des tâches prêtes est élue. Si la tâche n a pas terminé son exécution avant la fin du quantum, elle perd le processeur et est réinsérée en fin de file des tâches prêtes. Cette politique du tourniquet est usuellement utilisée dans les systèmes en temps partagé. Sa performance dépend largement de la taille du quantum. Un quantum trop grand augmente les temps de réponse alors qu un quantum trop petit multiplie les commutations de contexte jusqu à les rendre non négligeables. Politique d ordonnancement par priorités constantes Un niveau de priorité constant est affecté à chaque tâche et, à un instant donné, la tâche élue est toujours celle de plus forte priorité. Cet algorithme présente une version sans réquisition et une version avec réquisition. Le défaut de cette politique est le risque de «famine» encouru par les tâches de faible priorité. Une solution à ce problème est de faire «vieillir» la priorité des tâches en attente, c est-à-dire d augmenter celle-ci en fonction du temps d attente. La priorité des tâches devient ainsi variable. Politique d ordonnancement par files de priorités constantes multiniveaux avec ou sans extinction de priorité Les politiques présentées jusqu à présent utilisent une seule file d attente des tâches prêtes. On choisit ici de définir plusieurs files de tâches prêtes, chaque file correspondant à un niveau de priorité ; on peut alors avoir n files de priorités différentes variant de 0 à n 1. Dans une file donnée, toutes les tâches ont la même priorité et sont servies soit selon une politique à l ancienneté sans préemption, soit selon une politique de tourniquet. Le quantum peut être différent selon le niveau de priorité de la file. L ordonnanceur sert d abord toutes les tâches de la file de priorité n, puis ceux de priorité n 1 dès que la file de niveau n est vide et ainsi de suite... On peut définir deux variantes de l algorithme, fonctions de l évolution de la priorité des tâches : les priorités des tâches sont constantes tout au long de leur exécution. À ce moment-là, une tâche en fin de quantum est toujours réinsérée dans la même file d attente, celle correspondant à son niveau de priorité ; les priorités des tâches évoluent dynamiquement en fonction du temps de service dont a bénéficié la tâche. Ainsi une tâche de priorité n, à la fin du quantum de la file n, si elle n a pas terminé son exécution, n est pas réinsérée dans la file de priorité n, mais dans la file de priorité n 1. Et ainsi de suite... On cherche ici à minimiser les risques de «famine» pour les tâches de faible priorité, en faisant petit à petit baisser la priorité des tâches de plus forte priorité Objectifs de l ordonnancement dans un système temps réel Dans un système temps réel, les tâches sont soumises à des contraintes temporelles plus ou moins fortes, c est-à-dire que leur exécution est assujettie à un délai maximal qui doit être respecté impérativement ou le plus souvent possible. Le but principal de l ordonnancement est alors de permettre le respect de ces contraintes temporelles, lorsque l application s exécute dans un mode courant. L ordonnancement, de plus, doit être certifiable, c est-à-dire qu il doit être possible de prouver a priori le respect des contraintes temporelles des tâches de l application dans le régime «courant». Par suite d incidents, des anomalies au sein du procédé contrôlé peuvent entraîner des réveils de tâches d alarme ou des variations de temps d exécution qui font basculer l application dans un régime de surcharge, marqué par l occurrence de fautes temporelles. Dans ce régime de surcharge, le but de S Techniques de l Ingénieur, traité Informatique industrielle

13 ORDONNANCEMENT TEMPS RÉEL l ordonnancement est alors d offrir une certaine tolérance aux surcharges, c est-à-dire de permettre une exécution des tâches garantissant un suivi dégradé mais sécuritaire du procédé. Il est clair qu aucune des politiques présentées précédemment ne permet de remplir les deux objectifs d un ordonnancement temps réel, notamment parce qu aucune de ces politiques n intègre la notion d urgence de la tâche, notion représentée par le délai critique dans le modèle canonique des tâches temps réel. 3.2 Ordonnancement pour la résolution des contraintes temporelles Les tâches de l application peuvent être indépendantes ou non les unes des autres. Lorsque les tâches ne sont pas indépendantes, nous considérons deux types de relations : les relations de précédence qui conditionnent des débuts d exécution de tâches par rapport à des fins d exécution d autres tâches et des relations de partage de ressources critiques qui sérialisent les exécutions sur le code des sections critiques Ordonnancement de tâches périodiques indépendantes Les algorithmes d ordonnancement temps réel sont classés selon la somme des informations qu ils requièrent pour effectuer la planification des tâches. On distingue ainsi les algorithmes hors ligne et les algorithmes en ligne. Un algorithme hors ligne, sur la base de tous les paramètres des tâches à ordonnancer, construit une séquence de planification rigide qui vérifie les contraintes temporelles associées. Un algorithme en ligne, au contraire, choisit, au cours de la vie du système, la prochaine tâche à ordonnancer. Ce choix se fait sur la base d une priorité, qui peut avoir été définie soit par le concepteur de l application (priorité empirique ou externe), soit à partir d un paramètre temporel de la tâche tel que la période ou le délai critique. Dans ce dernier cas, la priorité peut être constante ou variable, c est-à-dire évoluant en fonction du temps Algorithmes en ligne à priorité constante Une priorité constante est une priorité qui ne varie pas au cours de la vie de la tâche. Ce principe est simple mais il réduit les possibilités d adaptation de la politique d ordonnancement à l évolution du système contrôlé. Les algorithmes les plus courants sont Rate Monotonic [41] et Inverse Deadline [40]. Rate Monotonic Cet algorithme attribue une priorité constante fonction de la période de la tâche, de telle sorte que la tâche de plus petite période est la tâche la plus prioritaire. Cet algorithme est optimal dans la classe des algorithmes à priorité constante pour les configurations de tâches à échéance sur requête et, dans ce cas, on connaît une borne minimale pour l acceptation d une configuration de n tâches (condition suffisante) : n i = 1 C ---- i B n 2 P i -- 1 n Ð 1 Cette borne théorique correspond au pire des cas et tend vers ln 2 (69 %) lorsque n est grand. Elle peut souvent être dépassée et une étude montre qu en moyenne la borne supérieure avoisine 88 %. L exploitation comme critère d ordonnancement de la période, paramètre évidemment non défini pour les tâches apériodiques, limite l utilisation de Rate Monotonic aux seules tâches à échéance sur requête. La figure 11 donne l exemple d un ordonnancement Rate Monotonic pour deux tâches périodiques à échéance sur requête, Tp1 (r 0 = 0, C = 1, P = 10) et Tp2 (r 0 = 0, C = 3, P = 5). La tâche la plus prioritaire est la tâche Tp2. La séquence est étudiée sur la période d étude, soit l intervalle [0, 10]. Les deux tâches respectent leurs contraintes temporelles. La condition suffisante est vérifiée ; on a : 1/10 + 3/5 = 0,7 < 0,82 Inverse Deadline Cet algorithme attribue une priorité constante, fonction du délai critique de la tâche, telle que la tâche de plus petit délai critique est la tâche la plus prioritaire. Les performances de cet algorithme sont équivalentes à celles de Rate Monotonic dans le cas de tâches à échéance sur requête et meilleures dans le cas de configurations arbitraires. Une condition suffisante d acceptabilité de tâches est la suivante : n C i B n 1 2n Ð 1 i = 1 R i La figure 12 donne l exemple d un ordonnancement Inverse Deadline pour deux tâches périodiques Tp1 (r 0 = 0, C = 4, R = 7, P = 10) et Tp2 (r 0 = 1, C = 3, R = 4, P = 5). La condition suffisante n est pas vérifiée ; on trouve : 4/7 + 3/4 = 37/28 > 0,82. La tâche la plus prioritaire est la tâche Tp2. On remarque qu à l instant t = 7, la tâche Tp1 commet une faute temporelle Tp1 (r 0 = 0, C = 1, P = 10) Tp2 (r 0 = 0, C = 3, P = 5) Temps creux Réveil Échéance sur requête Figure 11 Ordonnancement Rate Monotonic Tp1 (r 0 = 0, C = 4, R = 7, P = 10) Tp2 (r 0 = 1, C = 3, R = 4, P = 5) Réveil Échéance Figure 12 Ordonnancement Inverse Deadline Techniques de l Ingénieur, traité Informatique industrielle S

14 ORDONNANCEMENT TEMPS RÉEL Algorithmes en ligne à priorité variable Une priorité variable évolue dans le temps. Les deux algorithmes les plus courants sont Earliest Deadline [14] [41] et Least Laxity [25] [60]. Earliest Deadline La priorité maximale à t est accordée à la tâche dont l échéance est la plus proche. Cet algorithme permet d accepter un plus grand nombre de configurations que Rate Monotonic et Inverse Deadline, parce que, au lieu de prendre en compte dans la priorité de chaque tâche l écart fixe entre la date de réveil de la tâche et l échéance de la tâche (ou période, si les tâches sont à échéance sur requête), il prend pour critère dynamique de priorité le temps restant jusqu à l échéance. Pour des tâches à échéance sur requête, une condition nécessaire et suffisante d ordonnancement est : Tp1 (r 0 = 0, C = 4, R = 7, P = 10) Tp2 (r 0 = 1, C = 3, R = 4, P = 5) d (Tp2) = 5 d (Tp1) = 7 Réveil Échéance d (Tp2) = 10 d (Tp1) = 7 Figure 13 Ordonnancement Earliest Deadline n C ---- i B 1 i = 1 P i Pour des tâches quelconques, une condition suffisante d ordonnancement est : et une condition nécessaire est : n C ---- i B 1 i = 1 R i n C ---- i B 1 i = 1 P i La figure 13 donne l exemple d un ordonnancement Earliest Deadline pour deux tâches périodiques Tp1 (r 0 = 0, C = 4, R = 7, P = 10) et Tp2 (r 0 = 1, C = 3, R = 4, P = 5), qui sont les mêmes tâches que pour l exemple Inverse Deadline. La condition suffisante donne : 4/7 + 3/4 = 37/28 > 1 et la condition nécessaire donne : 4/10 + 3/5 = 1 À l instant 0, seule la tâche Tp1 est réveillée ; elle est donc ordonnancée. À l instant 1, la tâche Tp2 se réveille. Les priorités de Tp1 et Tp2 sont évaluées en fonction de leurs échéances, qui sont respectivement égales à 7 et 5. La tâche Tp2 étant celle de plus proche échéance, elle préempte la tâche Tp1 et s exécute. À l instant 6, la tâche Tp2 se réveille de nouveau. Les priorités de Tp1 et Tp2 sont évaluées en fonction de leurs échéances, qui sont respectivement égales à 7 et 10. La tâche Tp1 étant, cette fois, la tâche de plus proche échéance, elle poursuit son exécution et s achève dans le respect de son échéance. La tâche Tp2 s exécute ensuite et respecte elle aussi sa contrainte temporelle. La faute temporelle produite par l ordonnancement Inverse Deadline ne réapparaît pas. Earliest Deadline est une politique attrayante pour plusieurs raisons : son faible coût, son optimalité mais surtout, et avant tout, l exploitation comme critère d ordonnancement de l échéance, paramètre commun aux tâches périodiques et apériodiques, ce qui autorise un ordonnancement au même plan des deux types de tâches. Least Laxity La priorité d une tâche est inversement proportionnelle à sa laxité résiduelle LN i (t), la laxité résiduelle d une tâche représentant le temps restant avant l occurrence de sa date d exécution au plus tard. Cet algorithme est optimal et les conditions d ordonnançabilité d une configuration de tâches sont les mêmes que pour Earliest Deadline Tp1 (r 0 = 0, C = 4, R = 7, P = 10) Tp2 (r 0 = 1, C = 3, R = 4, P = 5) LN(Tp2) = 1 LN(Tp1) = 3 Réveil Échéance Figure 14 Ordonnancement Least Laxity LN(Tp2) = 1 LN(Tp1) = 0 La figure 14 donne l exemple d un ordonnancement Least Laxity pour les deux tâches périodiques Tp1 (r 0 = 0, C = 4, R = 7, P = 10) et Tp2 (r 0 = 1, C = 3, R = 4, P = 5). À l instant 0, seule la tâche Tp1 est réveillée ; elle est donc ordonnancée. À l instant 1, la tâche Tp2 se réveille. Les priorités de Tp1 et Tp2 sont évaluées en fonction de leur laxité résiduelle, qui sont respectivement égales à 3 et 1. La tâche Tp2 étant de plus petite laxité résiduelle, elle préempte la tâche Tp1 et s exécute. À l instant 4, Tp2 se termine et Tp1 reprend le processeur. À l instant 6, la tâche Tp2 se réveille de nouveau. Les priorités de Tp1 et Tp2 sont évaluées en fonction de leur laxité résiduelle, qui sont respectivement égales à 0 et 1. La tâche Tp1 étant cette fois la tâche de plus petite laxité résiduelle (en fait, celle-ci est nulle, ce qui signifie que la tâche Tp1 doit immédiatement poursuivre son exécution si elle ne veut pas commettre de faute temporelle), elle poursuit son exécution et s achève dans le respect de son échéance. La tâche Tp2 s exécute ensuite et respecte elle aussi sa contrainte temporelle. On peut remarquer qu ici la séquence obtenue avec Least Laxity est identique à celle obtenue avec Earliest Deadline. Le plus souvent Least Laxity occasionne plus de commutations de contexte que Earliest Deadline Ordonnancement de tâches apériodiques indépendantes On dispose d un ensemble de tâches périodiques ordonnancé par l un des quatre algorithmes présentés au paragraphe précédent et dont les contraintes temporelles sont respectées. Le problème consiste donc à ordonnancer des tâches apériodiques sans remettre en cause l ordonnançabilité des tâches périodiques. Le but recherché S Techniques de l Ingénieur, traité Informatique industrielle

15 ORDONNANCEMENT TEMPS RÉEL pour les tâches apériodiques à contraintes relatives est de minimiser leur temps de réponse (politique du meilleur effort ou Best Effort) ; pour les tâches apériodiques à contraintes strictes, on désire maximiser le nombre de tâches acceptées dans le respect de leurs contraintes Cas des tâches apériodiques à contraintes relatives Plusieurs approches existent : la première dont nous parlerons, le traitement d arrière-plan, est la plus simple mais la moins performante. Nous aborderons ensuite le principe des serveurs de tâches [61], puis la méthode de l ordonnancement conjoint [19] [54] [58]. Traitement d arrière-plan (background processing) Les tâches apériodiques sont ordonnancées lorsque le processeur est oisif, c est-à-dire lorsqu il n y a plus de tâches périodiques ou apériodiques acceptées précédemment à ordonnancer. Si la charge des tâches périodiques est importante, l ordonnanceur ne pourra pas consacrer beaucoup de temps aux tâches apériodiques et celles-ci risquent d avoir un temps de réponse assez long. La figure 15 présente un exemple d un tel ordonnancement sur un espace de temps égal à la période d étude de la configuration périodique. Deux tâches périodiques à échéance sur requête Tp1 (r 0 = 0, C = 1, P = 10) et Tp2 (r 0 = 0, C = 3, P = 5) sont ordonnancées selon Rate Monotonic laissant le processeur oisif sur les intervalles de temps [4,5] et [8,10]. Ainsi la tâche apériodique Tap1 (r = 4, C = 0,2) survenant à l instant 4 peut immédiatement s exécuter tandis que la tâche apériodique Tap2 (r = 5,5, C =1) doit attendre l instant 8 pour s exécuter à son tour ; elle s achève à l instant 9, ce qui lui donne un temps de réponse égal à 9 5,5 = 3,5. Serveurs de tâches L ensemble des tâches périodiques est à échéance sur requête et est ordonnancé selon l algorithme Rate Monotonic. Le serveur est une tâche périodique, créée spécialement pour veiller à l ordonnancement des tâches apériodiques. Cette tâche est généralement la tâche périodique de plus haute priorité. Plusieurs types de serveurs ont été proposés : ils diffèrent par la manière dont ils répondent aux arrivées des tâches apériodiques. Traitement par scrutation (Polling) Ce serveur de tâches apériodiques travaille comme suit : à chacune de ses activations, il traite les tâches apériodiques en suspens depuis son activation précédente et ce, soit jusqu à épuisement du temps processeur qui lui est octroyé et qu on appelle sa capacité, soit jusqu à ce qu il n y ait plus de tâches apériodiques à servir. Si, lorsque le serveur commence son exécution, il n y a aucune tâche apériodique en attente, le serveur se suspend jusqu à sa prochaine occurrence et sa capacité est récupérée au profit des tâches périodiques. On se rend compte facilement qu ici, également, des tâches apériodiques peuvent avoir de grand temps de réponse, surtout si elles surviennent juste après la fin de l exécution de la tâche serveur Tp1 (r 0 = 0, C = 1, P = 10) Tp2 (r 0 = 0, C = 3, P = 5) Tap1 (r = 4, C = 0,2) Tap2 (r = 5,5, C = 1) Figure 15 Ordonnancement en arrière-plan En fait, le problème principal de cette méthode est l incompatibilité entre la nature des arrivées des tâches apériodiques (par avalanche et de manière aléatoire) et la nature périodique du serveur. D une part, lorsque le serveur est prêt, il se peut qu il n y ait pas de tâches apériodiques à traiter ; d autre part, lorsque des tâches apériodiques surviennent sur le site, il se peut que le serveur se soit déjà suspendu, contraignant ainsi les tâches apériodiques à attendre sa prochaine occurrence pour être servies. La figure 16 donne un exemple de fonctionnement du serveur de scrutation sur le même ensemble de tâches périodiques et apériodiques que celui utilisé pour le traitement d arrière-plan. Tpsc(r 0 = 0, C = 0,5, P = 2) est la tâche serveur ; elle est la tâche de plus petite période et donc de plus grande priorité. On vérifie sur le premier chronogramme de la figure 16 que les deux tâches périodiques Tp1 et Tp2, plus la tâche serveur Tpsc s exécutent dans le respect de leurs contraintes temporelles selon Rate Monotonic. Le deuxième chronogramme présente le déroulement en ligne de l ordonnancement et le troisième chronogramme l évolution de la capacité du serveur. Lors des deux premiers réveils du serveur (t = 0 et t = 2), aucune tâche apériodique n est en attente de service, aussi la tâche serveur se suspend immédiatement. À l instant 4, la tâche serveur se réveille et sert la tâche apériodique Tap1 pour 0,2 unité de temps, puis perd le reste de sa capacité. Ses deux prochaines occurrences sont totalement utilisées pour le service de Tap2. Le temps de réponse de Tap1 est 0,2 et celui de Tap2 est 3. Serveur ajournable (Ajournable Server) Le serveur ajournable découle directement du serveur utilisé pour réaliser la scrutation. Simplement, si aucune tâche apériodique n est en suspens lors de son occurrence, il conserve entière sa capacité de traitement au lieu de la perdre au profit des tâches périodiques. Ainsi, une tâche apériodique survenant juste après l occurrence du serveur peut être immédiatement servie et n a plus à attendre l occurrence suivante. Le problème essentiel posé par le serveur ajournable est qu il ne respecte pas une des règles principales de l ordonnancement selon le Rate Monotonic des tâches périodiques, à savoir que la tâche prête de plus haute priorité doit immédiatement s exécuter ; le recul de son exécution pouvant entraîner la violation des échéances des tâches de priorité inférieure. En effet, lorsque le serveur est élu pour s exécuter et qu il n y a pas de tâche apériodique en suspens, il réserve sa capacité et abandonne son tour aux tâches périodiques prêtes de priorité inférieure à la sienne et s exécute plus tard, dès que survient une requête apériodique. Serveur sporadique (Sporadic Server) De façon similaire au serveur ajournable, le serveur sporadique est une tâche périodique de haute priorité qui conserve sa capacité de traitement. Il diffère cependant dans la façon dont il réinitialise celle-ci : au lieu de le faire périodiquement (à chacune de ses occurrences), il le fait à chaque fois que sa priorité devient active (c est-àdire une tâche de priorité supérieure s exécute ou le serveur s exécute lui-même), et que sa capacité n est pas nulle. La date de prochaine réinitialisation, prend pour valeur la date courante additionnée de la période du serveur. La valeur de réinitialisation est égale à la totalité de la capacité du serveur consommée. Cette méthode permet de toujours garantir le respect des échéances des tâches périodiques selon Rate Monotonic. En effet, lorsque le serveur sporadique diffère son exécution d une façon similaire à celle du serveur ajournable, il diffère également la date de réinitialisation de sa capacité d une durée égale à sa période, lorsque celleci est épuisée, laissant ainsi du temps disponible pour l exécution des tâches périodiques de priorité moindre. La figure 17 donne, toujours sur le même ensemble de tâches, un exemple du fonctionnement du serveur sporadique. Techniques de l Ingénieur, traité Informatique industrielle S

16 ORDONNANCEMENT TEMPS RÉEL Tap1 (r = 4, C = 0,2) Tap2 (r = 5,5, C = 1) Perte de capacité Tpsc Tp1 (r 0 = 0, C = 1, P = 10) Tp2 (r 0 = 0, C = 3, P = 5) Figure 16 Ordonnancement avec un serveur de scrutation Tpsc Ordonnancement Tpsc (r 0 = 0, C = 0,5, P = 2) Service Tap1 Service Tap ,5 6 7, Capacité 0,5 0,3 0,2 0,3 0, ,5 6 7, Tp1 (r 0 = 0, C = 1, P = 10) Tp2 (r 0 = 0, C = 3, P = 5) Tpsp (r 0 = 0, C = 0,5, P = 2) Tap1 (r = 4, C = 0,2) Tap2 (r = 5,5, C = 1) Figure 17 Ordonnancement avec un serveur sporadique Tpsp Le premier chronogramme représente l ordonnancement des tâches et le second chronogramme l évolution de la capacité du serveur. À l instant t = 0 et t = 2, le serveur se réveille sans qu il y ait de tâches apériodiques en attente de service. Cependant, le serveur ne perd pas sa capacité. À l instant 4, la tâche Tap1 survient et elle est immédiatement servie par le serveur qui s exécute donc entre les instants 4 et 4,2 et consomme 0,2 unité de sa capacité. La capacité restante, soit 0,3 unité, est conservée et une date de réinitialisation de la capacité est calculée : ce sera l instant = 6 et la valeur de réinitialisation est 0,2. À l instant 5,5 survient la tâche Tap2 qui peut être immédiatement servie avec la capacité restante du serveur. Elle s exécute donc durant 0,3 unité de temps et se suspend, puisque la capacité du serveur est épuisée. De nouveau, une date de réinitialisation de la capacité du serveur est calculée : c est l instant 5,5 + 2, soit 7,5. La tâche Tap2 poursuit son exécution lorsque le serveur récupère de la capacité, soit entre les instants 6 et 6,2 ; 7,5 et 7,8 ; puis 8 et 8,2. Le temps de réponse de Tap1 est toujours 0,2. Celui de Tap2 est maintenant de 2,7. Méthode de l ordonnancement conjoint [19] L ensemble de tâches périodiques est quelconque et est ordonnancé selon Earliest Deadline. L idée de cette méthode est de transformer les tâches apériodiques à contraintes relatives en tâches apériodiques à contraintes strictes par l ajout à leurs paramètres temporels d une échéance fictive. Ainsi, les tâches apériodiques peuvent être également ordonnancées avec la politique Earliest Deadline. À chaque fois qu une tâche apériodique survient, il faut donc calculer son échéance fictive df telle qu elle soit l échéance minimale qu il faut associer à la tâche pour que celle-ci s exécute avec un temps de réponse minimal. df correspond alors à la première date pour laquelle le temps total d inactivité du processeur ordonnançant, dans le respect de leurs échéances, les tâches périodiques et les tâches apériodiques précédemment déclenchées et non encore achevées est égal au temps d exécution de la tâche. Concrètement, les tâches apériodiques sont gérées à l ancienneté ; cependant, cette méthode présente plusieurs avantages par rapport à un simple ordonnancement basé sur une file FIFO (First In First Out) et une utilisation des temps creux : un avantage d optimalité : les tâches apériodiques sont mises sur le même plan que les tâches périodiques et leur temps de réponse est alors minimal ; un avantage de simplification par l utilisation d un même ordonnanceur Earliest Deadline pour les tâches périodiques et les tâches apériodiques (pas de gestion spéciale contrairement aux serveurs). On peut rapprocher de cette méthode celle développée par Lehoczky [37], basée, elle, sur Inverse Deadline. L algorithme, nommé le «voleur de temps creux» (Slack Stealer), récupère, au profit des tâches apériodiques, tout le temps disponible de manière que les tâches périodiques restent garanties. Cette méthode assure également un temps de réponse optimal pour les tâches apériodiques. La figure 18 présente un exemple d application de la méthode de l échéance fictive. La configuration périodique est constituée des deux tâches Tp1(r 0 = 0, C = 1, R = 7, P = 10) et Tp2(r 0 = 0, C = 3, R = 4, P = 5). Le premier chronogramme montre l ordonnancement selon Earliest Deadline de ces deux tâches. On considère l occurrence de trois tâches apériodiques Tap1(r = 4, C = 0,2), Tap2(r = 5,5, C = 1) et Tap3(r = 7, C = 0,5). À l instant 4 survient donc la tâche apériodique Tap1 ; cette tâche peut immédiatement s exécuter sans remettre en cause les contraintes temporelles de Tp1 et Tp2 (on est dans un temps creux du processeur) : on lui assigne donc l échéance fictive df = 4,2. La tâche apériodique Tap2 se réveille à l instant 5,5. On remarque que la poursuite de l exécution de la tâche Tp2 commencée à l instant 5 peut être reculée de manière à venir juste se terminer à la date d échéance de Tp2, soit 9. Cela libère le processeur entre les instants 5,5 et 6,5, soit une unité d exécution ou encore le temps d exécution de Tap2. On affecte donc à la tâche Tap2 une échéance fictive égale à 6,5 ; la tâche Tap2 préempte la tâche Tp2, qui reprend son exécution à partir de l instant 6,5. La tâche Tap3 survient à l instant 7 ; il n est plus possible cette fois de reculer l exécution de Tp2 sans mettre en péril le respect de son échéance. La tâche Tap3 doit donc s exécuter après la tâche Tp2 ; on lui assigne donc l échéance fictive 9,5. Le temps de réponse de Tap1 est 0,2, celui de Tap2 est égal à 1 et celui de Tap3 à 2, Cas des tâches apériodiques à contraintes strictes Il existe deux méthodes : la première consiste à rapprocher le modèle des tâches apériodiques de celui des tâches périodiques en dotant celles-ci d une pseudo-période, représentant l intervalle minimal entre deux occurrences successives d une tâche apériodique [49] [61]. La seconde [14] [52] traite les tâches apériodiques sans faire aucune supposition sur le rythme de leurs arrivées : à chaque occurrence de tâches apériodiques, un algorithme appelé «routine de garantie» teste si la nouvelle tâche pourra être garantie sans mettre en péril les tâches périodiques et les tâches apériodiques précédemment acceptées. Sinon, elle est rejetée. Première approche : introduction d une pseudo-période Π Le modèle des tâches apériodiques est rapproché de celui des tâches périodiques par le biais d une pseudo-période Π qui repré- S Techniques de l Ingénieur, traité Informatique industrielle

17 ORDONNANCEMENT TEMPS RÉEL Tap1 (r = 4, C = 0,2, df = 4,2) Tap3 (r = 7, C = 0,5, df = 9,5) Tap2 (r = 5,5, C = 1, df = 6,5) Tp1 (r 0 = 0, C = 1, R = 7, P = 10) Tp2 (r 0 = 0, C = 3, R = 4, P = 5) Figure 18 Méthode de l échéance fictive Tap1 (r = 4, C = 0,2) Tap2 (r = 5,5, C = 1) Tap3 (r = 7, C = 0,5) sente l intervalle de temps minimal séparant deux occurrences successives de la tâche. Une tâche apériodique Tap i est alors représentée par le quadruplet (r i, C i, R i, Π i ) et, dans le pire des cas, elle arrive sur un site à toutes les dates r i + k Π i. Sur le plan théorique, on a donc éliminé tout caractère aléatoire et on ne travaille plus qu avec un seul modèle de tâches, celui des tâches périodiques. Le principal défaut de ces méthodes est justement constitué par cette obligation de calquer le modèle des tâches apériodiques sur celui des tâches périodiques. La pseudo-période peut être difficilement évaluable, car rien ne permet à l initialisation du système de savoir quand les tâches apériodiques vont s exécuter, ni de quel intervalle de temps deux hypothétiques alarmes seront séparées. De plus, cette méthode infère automatiquement une sous-utilisation du processeur, puisque la configuration initiale, bâtie et testée en prenant compte de l exécution «périodique» des tâches apériodiques, va rarement se dérouler dans son entier. Deuxième approche : routine de garantie La deuxième approche ne fait aucune supposition sur la fréquence d arrivée des tâches ; celles-ci peuvent donc survenir à tout instant. L équipe de Stankovic [52] a défini un test d acceptation pour des tâches non préemptibles. La séquence est construite en ordonnançant les tâches au plus tard, de façon non préemptive et en fonction de leurs échéances respectives. On vérifie alors, pour chacune d elles, que sa date de début d exécution est postérieure à sa date de réveil. Chetto [14] présente plusieurs politiques dynamiques d acceptation de tâches apériodiques pour un ordonnancement Earliest Deadline préemptif. Ces politiques diffèrent selon un critère d optimalité et selon le mode de prise en compte des tâches apériodiques. Ordonnancement dans les temps creux d une séquence rigide de tâches périodiques Earliest Deadline L ensemble des tâches périodiques est ordonnancé selon Earliest Deadline, ce qui produit une séquence présentant des temps d inactivité du processeur, temps encore appelés temps creux. À chaque réveil de tâches apériodiques, une routine de garantie teste si la nouvelle requête apériodique peut être placée dans les temps creux de la configuration périodique et ce dans le respect des échéances des tâches périodiques et des tâches apériodiques précédemment acceptées. Si la tâche apériodique peut être acceptée, elle est alors ajoutée à l ensemble des tâches apériodiques acceptées, cet ensemble étant ordonnancé selon Earliest Deadline, mais dans le temps creux de la configuration périodique. Sinon, la tâche apériodique est rejetée. On voit que l ordonnancement s effectue dans une disjonction complète entre les tâches périodiques et les tâches apériodiques. La séquence périodique Earliest Deadline figée et garantie est prédominante ; les tâches apériodiques, ordonnancées également selon Earliest Deadline, sont en second plan. On peut rapprocher cette politique du traitement d arrière-plan de Sprunt [61], où Rate Monotonic est remplacé par Earliest Deadline et où la préoccupation pour les tâches apériodiques n est plus seulement d offrir un meilleur temps de réponse possible mais d en garantir un maximum, d où le remplacement de la stratégie FIFO par une stratégie Earliest Deadline pour la gestion de la file des tâches apériodiques en attente de service. La figure 19 donne un exemple d application de l algorithme sur une configuration périodique constituée de deux tâches Tp1(r 0 = 0, C = 1, R = 7, P = 10) et Tp2(r 0 = 0, C = 3, R = 4, P = 5) et un même ensemble de quatre tâches apériodiques Tap1(r = 4, C = 0,2, d = 5), Tap2(r = 5,5, C = 1, d = 10), Tap3(r = 6, C = 1, d = 8) et Tap4(r = 7, C = 1,5, d = 9,5). La configuration périodique Earliest Deadline est notamment caractérisée sur la période d étude par deux intervalles de temps creux, [4,5] et [8,10]. Les tâches apériodiques Tap1 et Tap2 peuvent être acceptées dans les temps creux de la configuration périodique Earliest Deadline, mais les tâches Tap3 et Tap4 sont rejetées. En effet, les tâches Tap1 et Tap2 disposent toutes les deux de temps creux suffisants entre leur date de réveil et leur date d échéance, soit les temps creux [4,5] et [8,10]. Au contraire, la tâche Tap3 ne dispose pas de temps creux entre sa date de réveil et sa date d échéance et elle est donc rejetée. La tâche Tap4 dispose de temps creux suffisant entre sa date de réveil et sa date d échéance mais son acceptation remet en cause la garantie de la tâche Tap2 qui, selon Earliest Deadline, doit s exécuter après elle dans le temps creux [8,10]. Tap4, en conséquence, est refusée. Ordonnancement conjoint Earliest Deadline avec recherche d une nouvelle séquence pour les deux types de tâches À chaque arrivée d une nouvelle tâche apériodique, il y a construction d une nouvelle séquence Earliest Deadline comprenant à la fois les requêtes périodiques, les requêtes apériodiques précédemment acceptées et non achevées et la nouvelle tâche. Si cette nouvelle séquence peut être construite, la requête apériodique est acceptée sinon elle est rejetée. La nouvelle séquence est construite par l application sur les tâches de la configuration périodique de l algorithme EDL (Earliest Deadline as Late as possible), qui consiste à ordonnancer les requêtes au plus tard. Cela permet alors de connaître le temps disponible pour ordonnancer les requêtes apériodiques. La deuxième routine de garantie est, contrairement à la première, optimale et présente également l avantage d ordonnancer au même niveau les requêtes périodiques et les tâches apériodiques acceptées. Cependant, elle est plus coûteuse en temps de calcul Tap1 (r = 4, C = 0,2, d = 5) Tap4 (r = 7, C = 1,5, d = 9,5) Tap2 (r = 5,5, C = 1, d = 10) Tap3 (r = 6, C = 1, d = 8) Temps creux [4,5] = 1 > 0,2; Tap1 acceptée Temps creux [5,5, 10] = 2 > 1; Tap2 acceptée Temps creux [6,8] = 0, Tap3 refusée Ft Temps creux [7, 9,5] = 1,5; mais Tap2 doit rester garantie, Tap 4 refusée Figure 19 Ordonnancement avec routine de garantie : premier algorithme Techniques de l Ingénieur, traité Informatique industrielle S

18 ORDONNANCEMENT TEMPS RÉEL Tap1 (r = 4, C = 0,2, d = 5) Tap2 (r = 5,5, C = 1, d = 10) Tap3 (r = 6, C = 1, d = 8) Contraintes de précédence et ordonnancement selon Rate Monotonic On transforme hors ligne l ensemble de tâches liées par des contraintes de précédence en un ensemble de tâches indépendantes pour lequel le test d acceptabilité de Rate Monotonic est valide. Cette transformation s opère sur les paramètres date de réveil r pour donner : r* i = max {(r i, ( r* j prédécesseur)} Si T i précède T j, Priorité (T i ) > Priorité (T j ) dans le respect de Rate Monotonic. Tap4 (r = 7, C = 1,5, d = 9,5) Figure 20 Ordonnancement avec routine de garantie : second algorithme La figure 20 donne un exemple d application de l algorithme sur la configuration de tâches utilisées précédemment. Les tâches apériodiques Tap1, Tap2 et Tap3 peuvent être ordonnancées conjointement aux tâches périodiques, mais Tap4 doit être rejetée. À l instant 5,5, date de réveil de Tap2, on constate que Tap2 et la tâche périodique Tp2 peuvent être ordonnancées ensemble selon Earliest Deadline, dans le respect de leur contrainte de temps. Il en est de même lors du réveil de Tap3, mais on constate alors que l ordonnancement jusqu à la date t = 10 ne comprend plus aucune laxité. Tap4 ne peut donc pas être ordonnancée Ordonnancement de tâches liées par des contraintes de précédence Un premier type de contraintes entre les tâches d une application temps réel est représenté par la notion de précédence. On dit qu il existe une contrainte de précédence entre la tâche T i et la tâche T j ou T i précède T j, si T j doit attendre la fin d exécution de T i pour commencer sa propre exécution. Les précédences entre tâches d une application peuvent être modélisées sous forme d un graphe de précédence (figure 21) tel qu il existe un arc entre T i et T j si T i précède T j. L objectif des algorithmes de prise en compte des relations de précédence est de transformer l ensemble de tâches avec relations de précédence en un ensemble de tâches indépendantes, en intégrant explicitement ou implicitement les relations de précédence dans l affectation de priorité. Ainsi, on obtient les règles de précédence suivantes : si T i précède T j, alors r j b r i ; si l une des deux tâches est périodique, l autre l est obligatoirement et on a P i = P j ; priorité (T i ) > priorité (T j ) dans le respect de la politique d ordonnancement utilisée. Figure 21 Graphe de précédence Tap1, Tap2 et Tap3 sont acceptées Tap4 est refusée Contraintes de précédence et ordonnancement selon Earliest Deadline On transforme hors ligne l ensemble de tâches liées par des contraintes de précédence en un ensemble de tâches indépendantes pour lequel le test d acceptabilité d Earliest Deadline est valide. Cette transformation s opère sur les paramètres date de réveil r et échéance d des tâches de l ensemble pour donner : d* i = min (d i, min ( d* j Ð C j, T j précède T i ) r* i = max (r i, max r* j + C j, T j précède T i ) Exemple du traitement des contraintes de précédence selon Rate Monotonic et Earliest Deadline On considère les cinq tâches T1, T2, T3, T4 et T5 liées par le graphe de précédence donné à la figure 21. Le tableau 1 donne les paramètres des tâches et leurs transformations soit pour un ordonnancement Rate Monotonic, soit pour un ordonnancement Earliest Deadline. Tableau 1 Prise en compte des contraintes de précédence Paramètres Nom de tâche des tâches Rate Monotonic Earliest Deadline r i C i d i r* i Priorité r* i d* i T T T T T Ordonnancement de tâches liées par des contraintes de ressources L ordonnancement de tâches avec contraintes de ressources pose différents problèmes dans tout type de systèmes informatiques : des problèmes de synchronisation entre tâches et, notamment, d inversion de priorité pour les ressources accédées en exclusion mutuelle ; des problèmes d interblocage. Dans un système temps réel, la réservation et la préallocation des ressources sont des méthodes simples pour éviter ces problèmes, méthodes par lesquelles une tâche dispose dès le début de son exécution de toutes les ressources qui lui seront nécessaires au cours de celle-ci. Cependant, ces méthodes engendrent généralement un très faible taux d utilisation des ressources ; aussi des protocoles spécifiques ont été développés pour permettre d effectuer une allocation dynamique des ressources. S Techniques de l Ingénieur, traité Informatique industrielle

19 ORDONNANCEMENT TEMPS RÉEL T1 T3 T2 Demande ( 1) Demande ( 1) blocage T1 retardée par T3 Libération ( 1) Figure 22 Inversion de priorité : T1 et T2, respectivement la tâche de plus haute priorité et de plus faible priorité partagent la ressource r1 T1 T3 T2 Demande ( 1) Demande ( 1) T2 hérite de Prio (T1) blocage Prio (T3) < Prio (T2) = Prio (T1) en attente Libération ( 1) T2 retrouve sa priorité Figure 23 Inversion de priorité : application du protocole de l héritage de priorité Lorsqu une ressource est accédée en exclusion mutuelle, il peut se produire le phénomène qualifié d inversion de priorité, phénomène au cours duquel une tâche de haute priorité voulant accéder à la section critique associée à la ressource est retardée par des tâches de moindre priorité dont une au moins possédant la section critique. Ce phénomène est inhérent à tout système informatique, mais il devient problématique dès que des contraintes temporelles sont associées aux tâches, car il induit des retards non maîtrisés. La figure 22 donne un exemple de ce phénomène pour trois tâches T1, T2, T3 telles que la tâche T1 est la tâche la plus prioritaire et T2 la tâche la moins prioritaire ; T1, T2 partageant la section critique r1 et T3 n utilisant pas la ressource r1. À l instant 0, seule la tâche T2 est réveillée et donc elle s exécute. Au bout d un certain temps d exécution, la tâche T2 demande la ressource r1 et comme celleci est disponible, la tâche T2 obtient la ressource. T2 poursuit son exécution jusqu au réveil de T1 qui est plus prioritaire et donc préempte T2. T1 s exécute jusqu à l instant où elle demande à accéder à la ressource r1. Comme r1 est déjà allouée à T2, la tâche T1 est bloquée et T2 reprend son exécution. Lorsque la tâche T3 se réveille à son tour, elle préempte la tâche T2 et s exécute entièrement, retardant d autant la tâche T2 et, en conséquence, la tâche T1. On voit ainsi que T1 est retardée par T3 et éventuellement par toute autre tâche de priorité intermédiaire n accédant pas à r1. Plusieurs protocoles ont été définis pour pallier ce problème d inversion de priorité, les tâches étant ordonnancées soit par l algorithme Rate Monotonic, soit par l algorithme Earliest Deadline. Chacun de ces protocoles permet de définir, pour chaque tâche, des temps de blocage maximaux B i induits par l accès aux sections critiques. Ces temps de blocage maximaux sont ensuite intégrés aux tests d acceptabilité des algorithmes Rate Monotonic et Earliest Deadline, en considérant qu une tâche possède un temps d exécution allongé de cette durée maximale de blocage, soit C i + B i. Par ailleurs, ces protocoles tentent également de prévenir la formation des interblocages. Protocole de l héritage de priorité [32] [56] Dans ce protocole, la tâche T qui possède la section critique prend la priorité de la tâche T en attente sur la section critique, si la priorité de T est supérieure à la sienne, ce jusqu à libérer la section critique. Ainsi, la tâche T est ordonnancée à un niveau plus élevé que son niveau initial, afin de libérer au plus vite la section critique et, donc, afin de minimiser l attente de la tâche T. Le protocole de l héritage de priorité ne prévient ni les interblocages, à moins qu un ordre total ait été imposé sur l accès aux sections critiques, ni la possibilité que des demandes successives à des sections critiques différentes soient toutes successivement bloquantes (blocages en chaîne). L intégration de ce protocole de manière récursive, s il y a des demandes d accès emboîtées, a été réalisée dans le système DUNE-IX [3]. La figure 23 donne un exemple de l application de ce protocole pour les trois mêmes tâches T1, T2, T3. Comme précédemment, la tâche T2, réveillée à l instant 0, commence son exécution, demande la ressource r1 et l obtient. Un peu plus tard, la tâche T1 se réveille et préempte la tâche T2. Lorsque T1 demande la ressource r1, la tâche T1 se bloque puisque r1 est allouée à T2 mais, dans le même temps, la tâche T2 hérite de la priorité de T1 et poursuit son exécution avec cette nouvelle priorité. Ainsi, lorsque la tâche T3 se réveille, elle se trouve maintenant être de priorité inférieure à T2 et ne peut plus préempter T2. La tâche T2 poursuit donc son exécution, libère la ressource r1 et retrouve sa priorité initiale. La tâche T1 débloquée prend alors la main. On montre que, pour une tâche T i, le temps de blocage maximal B i sur l attente d une ressource est égal au plus à la somme des durées des sections critiques partagées avec des tâches de plus faible priorité. Ainsi, on peut voir sur l exemple de la figure 23, que l exécution de la tâche T1 est au plus retardée d une durée égale à la section critique de T2. Protocole de la priorité plafonnée [13] [56] Dans ce protocole, chaque ressource critique possède initialement une priorité qui est celle de la tâche de plus haute priorité pouvant demander son accès. Cette priorité se comporte comme un seuil. Dès qu une tâche T accède à la ressource, elle prend comme priorité d ordonnancement la priorité de la ressource, et ce jusqu à la libération de celle-ci. Par ailleurs, afin de prévenir les interblocages et les chaînes de blocage, la tâche T ne peut accéder à une ressource que si la priorité de la ressource est supérieure à celles de toutes les ressources déjà possédées par d autres tâches T i. Chen et Lin [13] présentent une adaptation du protocole initialement conçu pour des algorithmes à priorités constantes tels que Rate Monotonic aux ordonnancements à priorités variables tels que Earliest Deadline. Dans ce cas, le seuil de chaque ressource est recalculé à chaque fois que l ensemble des tâches actives du système est modifié, ce qui correspond aux instants de terminaison et de réveil de tâches. L intégration de ce protocole dans sa version statique a été réalisée dans le système Mach par l équipe de Carnegie Mellon [48] [66]. Il faut, par ailleurs, noter que les propriétés de ce protocole ne sont vraies que pour un système monoprocesseur. On montre que, pour une tâche T i, le temps de blocage maximal B i sur l attente d une ressource est égal à la durée de la plus grande des sections critiques d une tâche moins prioritaire dont la priorité plafond d une de ses ressources est au moins aussi grande que la priorité de la tâche. La figure 24 donne un exemple de l application de ce protocole pour les trois mêmes tâches T1, T2, T3. La ressource critique r1 reçoit comme priorité la priorité de T1. Comme précédemment, la tâche T2, réveillée à l instant 0, commence son exécution, demande la ressource r1 et l obtient. Elle prend alors, comme nouvelle priorité d exécution, la priorité de r1. Un peu plus tard, la tâche T1 se réveille ; sa priorité est égale à celle de T2 et donc T2 poursuit son Techniques de l Ingénieur, traité Informatique industrielle S

20 ORDONNANCEMENT TEMPS RÉEL T1 T3 T2 Demande ( 1) Demande ( 1) T2 hérite de Prio( 1) = Prio(T1) Libération ( 1) Prio (T3) < Prio (T2) = Prio (T1) en attente Libération ( 1) T2 retrouve sa priorité Figure 24 Inversion de priorité : application du protocole de la priorité plafonnée exécution. Lorsque la tâche T3 se réveille, elle est mise en attente puisque sa priorité est plus petite que celle de T2. T2 poursuit donc son exécution, libère la ressource r1 et retrouve sa priorité initiale. La tâche T1, qui est à présent la tâche de plus haute priorité, prend alors la main. Protocole d allocation de ressources basé sur une pile [2] Ce protocole est une évolution du protocole à priorité plafonnée statique et dynamique, notamment vers le cas de ressources à plusieurs instances. En plus de sa priorité, chaque tâche dispose d un paramètre π entier, appelé niveau de préemption, qui est fonction du temps dont dispose la tâche pour s exécuter, soit inversement proportionnel à son délai critique R. Ce niveau de préemption est tel que la tâche T ne peut préempter la tâche T à moins que π(t) < π(t ). Un niveau courant du système est déterminé en fonction de la disponibilité des ressources. Une tâche ne peut être élue que si son niveau de préemption π est supérieur au niveau du système, ce qui assure alors que les ressources qu elle demandera au cours de son exécution sont déjà disponibles. Des études comparatives de ces protocoles ont été effectuées [44] [59] ; nous résumons dans le tableau 2 les principales caractéristiques de ceux-ci. Tous ces protocoles sont des protocoles qui ne cherchent pas à éviter le phénomène de l inversion de priorité, mais tentent, lorsque ce phénomène se produit, de minimiser le temps d attente des tâches de haute priorité qui en sont victimes. Des bornes à ces temps d attente existent et peuvent ensuite être prises en compte dans le test d ordonnançabilité des tâches. Les deux premiers protocoles inversion de priorité et priorité plafonnée et le troisième protocole sur pile se différencient sur deux points importants : les deux premiers protocoles ne sont définis que dans le cas des tâches périodiques, notamment la condition d ordonnançabilité prenant en compte les temps de blocage ne s appliquent qu à des configurations de tâches périodiques. Au contraire, le protocole sur pile fournit un test applicable à un ensemble quelconque de tâches ; dans le protocole sur pile, le blocage d une tâche ne peut se produire qu au moment où elle est élue, seul instant où le test de vérification de la disponibilité des ressources par comparaison entre le seuil de préemption courant et celui de la nouvelle tâche est effectué. Une fois la tâche démarrée, ses allocations de ressources sont forcément passantes, au contraire de ce qui arrive pour les deux autres protocoles où chaque demande d accès peut être bloquante. Le nombre de préemption résultant est donc plus faible Ordonnancement de tâches périodiques et apériodiques avec prise en compte des surcharges Une faute temporelle est générée lorsqu une tâche dépasse son échéance. On dit alors que le système est en situation de surcharge. Une faute temporelle peut être générée, par exemple, par suite d une transmission défectueuse de communications, et donc de la réception tardive d un signal nécessaire à la poursuite de l exécution d une tâche ou encore par suite d une contention sur une ressource critique entraînant un allongement du temps d exécution de la tâche. Une faute temporelle peut encore être générée par des réveils de tâches apériodiques, dus à une situation d alarme sur le procédé contrôlé. Par ailleurs, lors d une faute temporelle, il est souhaitable de supprimer la tâche fautive, sinon la faute risquerait de se propager à d autres tâches. Tableau 2 Protocoles pour l inversion de priorité et interblocage Protocole Ordonnancement Principe Propriétés Héritage de priorité Priorité plafonnée Priorité plafonnée dynamique Protocole sur pile Rate Monotonic Rate Monotonic Earliest Deadline Rate Monotonic Earliest Deadline T prend la priorité de T en attente sur la ressource si Prio (T) > Prio (T ) Seuil (ressource) = max (prio T i ), T i accédant à la ressource T accède à la ressource, si et seulement si Prio(T) > Prio(T j ) et T j accède à une ressource Seuil (ressource) = max (prio T i ), T i actives accédant à la ressource T accède à la ressource, si et seulement si Prio(T) > Prio(T j ) et T j accède à une ressource Seuil de préemption π(t) T ne s exécute que si π(t) > π(système) Test d ordonnançabilité Ne prévient pas les interblocages Ne prévient pas les blocages en chaîne Pas de modification de programme Test d ordonnançabilité Prévient les interblocages Prévient les blocages en chaîne Le programme doit fournir la liste des ressources utilisées par chaque tâche ou alors la valeur de plafond Test d ordonnançabilité Prévient les interblocages Prévient les blocages en chaîne Le programme doit fournir la liste des ressources utilisées par chaque tâche ou alors la valeur de plafond Test d ordonnançabilité Prévient les interblocages Le programme doit fournir la liste des ressources utilisées par chaque tâche S Techniques de l Ingénieur, traité Informatique industrielle