Les exécutifs temps-réel

Les exécutifs temps-réel se différencient des autres noyaux par la prise en compte de contraintes temporelles dont le respect est aussi important que l’exactitude du résultat. Autrement dit, le système ne doit pas simplement délivrer des résultats exacts, il doit les délivrer dans des délais imposés [97]. La plupart des systèmes embarqués nécessitent un noyau pouvant respecter des contraintes sur la durée d’exécution des tâches. Par exemple, un algorithme de décompression d’images numériques doit respecter une fréquence d’affichage correcte.

En pratique, on distingue le temps-réel strict ou souple suivant l’importance accordée aux contraintes temporelles. Le temps-réel strict ne tolère aucun dépassement de ces contraintes pour des questions de sécurité critique. Le concepteur doit être capable, le plus souvent, de prouver que les limites temporelles ne seront jamais franchies quelle que soit la situation. Pour cela, des critères d’ordonnançabilité sont étudiés ou des analyses hors lignes des comporte- ments sont effectuées. A l’inverse, le temps-réel souple tolère des débordements exceptionnels qui seront rattrapés à l’exécution suivante. Une mesure statistique sur un prototype peut se révéler suffisante.

Les systèmes d’exploitation temps-réel pour des architectures multiprocesseurs sont essen- tiellement distribués (Chimera [98], MARS [99]), symétriques (RT-Mach [100], Montavista Linux [101]) ou séparés (OSE [102], VxWorks [103]). Aucune des solutions existantes ne pro- pose une structure asymétrique comme nous le préconisons [104]. Ceci a plusieurs raisons : les structures multiprocesseurs asymétriques sont présentes sur le marché depuis peu de temps et les algorithmes nécessaires à la mise en œuvre du contrôle restent trop complexes, ou inef- ficaces, pour être exécutés sur des processeurs dédiés au calcul. Ainsi, les solutions adoptées

étendent toutes les fonctionnalités utilisées par les monoprocesseurs en intégrant des méca- nismes de communication particuliers. Nous allons malgré tout décrire leur fonctionnement car les propositions que nous ferons par la suite s’appuient sur ces premiers principes.

Définitions et notions générales

Le premier rôle d’un exécutif temps-réel est d’ordonnancer l’exécution des tâches et de protéger l’accès aux ressources partagées. En effet, les mécanismes qui décident de l’ordre d’exécution, ou de l’attribution des ressources, influent considérablement sur la capacité du système à respecter ses contraintes de temps. La classification des ordonnancements temps- réel se révèle être extrêment vaste [105, 106]. Chacune des solutions étudiées dans la littérature répond à un besoin précis en terme de complexité ou de sûreté de fonctionnement. Dans un premier temps, il nous faut définir quelles sont les solutions les mieux adaptées aux futures applications mobiles.

En ligne ou hors ligne Un algorithme d’ordonnancement hors ligne planifie l’exécution des tâches en fonction de tous ses paramètres temporels. Cette séquence ou ce scénario est connu avant l’exécution des tâches et peut être mis en œuvre très efficacement. Néanmoins, cette solution est trop rigide au vu de nos besoins applicatifs. A l’inverse, un algorithme d’ordonnancement en ligne choisit, au cours de l’exécution, la prochaine tâche à exécuter. Il s’adapte aux évènements extérieurs et aux besoins de l’utilisateur. Cette approche dynamique donne des solutions moins bonnes puisqu’on utilise moins d’informations pour prendre les décisions. Par ailleurs, elle est plus complexe à mettre en œuvre et induit un surcoût temporel plus important. Elle est cependant indispensable dans notre cas d’étude.

Préemptif ou non-préemptif Dans le cadre des systèmes temps-réel, la préemption est la seule solution qui permette d’interrompre une tâche moins prioritaire. Elle a donc un rôle très important pour les ordonnancements en ligne si le comportement du système n’est pas prédictible. Ceci est notre cas puisque l’utilisateur peut demander ou interrompre l’exécution d’une tâche à n’importe quel moment.

ET ou TT L’ordonnancement peut être cadencé par les évènements (ET : Event-Triggered ) ou par l’écoulement du temps (TT : Time-Triggered ) [107]. Les systèmes temps-réel ont communément une architecture cadencée par les évènements, donc l’ordonnancement ET est souvent préféré. Pourtant, le fait d’ordonnancer des tâches à des intervalles de temps réguliers permet de mieux prédire le comportement du système. Il devient plus déterministe et plus aisé à valider. En contrepartie, il engendre une sous-occupation des ressources de calcul (figure 2.5).

Niveaux de Priorité ou priorité temporelle La priorité des tâches est définie de deux manières. La première consiste à attribuer un niveau de priorité à chacune des tâches. La tâche ayant le niveau le plus élevé est la tâche en cours d’exécution. L’avantage est de pouvoir exécuter une tâche plus prioritaire quel que soit l’état des autres tâches moins prioritaires. La simplicité de cette solution l’a rendu très populaire dans les noyaux temps-réel commerciaux [108]. A titre d’exemple, µCOS-II est un noyau préemptif capable de gérer 64 tâches possédant un niveau de priorité unique [109]. Néanmoins, ces systèmes ne garantissent pas le respect des contraintes de fin d’exécution qui sont essentielles pour respecter les cadences d’affichage, la périodicité des évènements, ou la fréquence des flux de données ou de contrôles. A moins d’une

T0

temps

T1 T2 T3

T0 _temps

tick tick tick tick

T1 T2 T3

temps défini

temps de prise en compte de l’évènement indéfini a)

b)

Fig. 2.5 – Ordonnancement ET ou TT. L’ordonnancement ET exécute successivement les tâches en fonction d’évènements de fin d’exécution (a). La durée d’ordonnancement ou de prise en compte des interruptions est difficilement prédictible. Au contraire, l’ordonnancement TT prend en compte les évènements à chaque nouveau tick d’ordonnancement (b). L’échelle du temps est mieux maîtrisée.

analyse hors ligne, ces ordonnancements n’assurent pas le respect des contraintes temps-réel. Au contraire, les ordonnancements à priorité temporelle prennent leur décision en fonction de la périodicité ou de l’échéance des tâches et cela au cours de l’exécution. L’échéance d’une tâche est la date de sa fin d’exécution au plus tard permettant de respecter sa contrainte temps-réel.

Priorités statiques ou dynamiques Enfin, l’ordonnancement des tâches fonde ses déci- sions sur des paramètres assignés aux tâches avant leur activation. Ces algorithmes statiques ont l’avantage de minimiser le surcoût de l’ordonnancement, mais ne permettent toujours pas de s’adapter à des conditions d’exécution imprévues ou dont les dates d’arrivée sont variables. Par ailleurs, ils peuvent se révéler parfois moins performants que les approches dynamiques. Cette dernière solution supporte le changement des priorités au cours de l’exécution. Elle permet de rendre compte de l’urgence de l’exécution d’une tâche en fonction de son échéance. Par exemple, une tâche proche de son échéance pourra avoir une priorité différente de celle qu’elle aurait eu si elle disposait d’un temps important pour s’exécuter.

En conclusion, nous devons privilégier une approche en ligne et préemptive. De même, les priorités doivent être évaluées dynamiquement et dépendre pour chacune des tâches de son échéance. Le choix d’un ordonnancement ET ou TT est plus délicat et sera davantage étudié par la suite. Ainsi, les contraintes imposées par les futurs besoins applicatifs nécessitent la mise en œuvre d’un algorithme capable d’adapter son comportement au cours de l’exécution. Les besoins applicatifs varient de manière indéterminée en fonction des envies de l’utilisateur. Par conséquent, seuls les algorithmes en lignes et préemptifs sont adaptés à nos exigences. Pour la même raison, les priorités des tâches doivent pouvoir évoluer au cours de l’exécution en fonction de contraintes temporelles.

Les ordonnancements préemptifs à priorité temporelle dynamique

Les deux algorithmes les plus utilisés respectant ces contraintes d’ordonnancement sont le Earliest Deadline First (EDF) et le Least Laxity First (LLF). L’algorithme d’ordonnancement EDF consiste à assigner la priorité la plus élevée à la tâche dont l’échéance relative courante est la plus proche [110, 111]. L’évaluation des priorités des tâches est effectuée à chaque nouvel ordonnancement. Celui-ci a lieu à la fin de l’exécution d’une tâche, lors de la libération d’une ressource partagée, ou à l’activation d’une nouvelle tâche à ordonnancer. Cet algorithme est optimal dans la classe des algorithmes à priorités dynamiques pour des configurations de tâches périodiques indépendantes avec des échéances inférieures ou égales à leur période. Ainsi, si un ordonnancement existe pour un ensemble de tâches, l’ordonnancement EDF est

possible. De la même façon, si un ordonnancement EDF n’est pas admissible, aucun autre ordonnancement n’est envisageable [112].

L’algorithme LLF consiste, quant à lui, à affecter la priorité des tâches en fonction de leur laxité [110]. Comme le montre la figure 2.6, la laxité est la durée restante à la tâche pour s’exécuter. A un instant donné, la tâche dont la laxité est la plus petite est la tâche la plus prioritaire. Cet algorithme est également optimal, mais induit un nombre plus important de changements de contexte. Par ailleurs, il engendre un surcoût élevé puisque les priorités doivent être évaluées à chaque mise à jour du temps courant. Ce modèle d’ordonnancement TT occasionne également une sous-exploitation des ressources de calcul. Pour toutes ces raisons, il n’a jamais été implémenté dans un noyau temps-réel pour les systèmes embarqués.

Ti Di Ci temps Xi ci(t)

Fig. 2.6 –Définition de la laxité. Soient Cila durée d’exécution maximale sans préemption (WCET :

Worst Case Execution Time) de la tâche Ti, Di son échéance relative et ci le temps déjà passé à

exécuter cette tâche. Comme l’illustre la figure, la laxité Xi est égale à Xi(t) = Di− (t + Ci− ci(t)).

Chacun de ces algorithmes d’ordonnancement peut prendre en compte des tâches apério- diques au cours de l’exécution. Une tâche apériodique est une tâche réveillée par un évènement dont la date d’occurence est inconnue avant l’exécution. Le but est d’assurer le respect des contraintes temporelles des tâches dont l’ordonnancement était prévu, tout en acceptant l’exé- cution de tâches supplémentaires. Il s’agit alors de minimiser le temps de réponse (contrainte relative) ou de maximiser le nombre de tâches qui peuvent être acceptées (contrainte stricte) [113, 114]. L’ordonnancement de tâches apériodiques à contraintes relatives peut avoir lieu lorsque le processeur est au repos (traitement d’arrière plan), ou lors de l’activation d’une tâche périodique particulière appelée serveur de tâches [111, 115, 116, 117]. A l’inverse, l’or- donnancement de tâches apériodiques à contraintes strictes consiste à attribuer aux tâches apériodiques une pseudo-période. Celle-ci peut être équivalente au temps minimal entre deux occurences successives, ou être définie hors ligne de manière à utiliser les temps de repos du processeur [118].

Les tâches de l’application peuvent être indépendantes ou non les unes des autres. Une tâche est dépendante si elle possède une relation de précédence qui conditionne son exécution, ou si elle doit accéder à une ressource partagée. Dans le premier cas, les tâches sont transformées en tâches indépendantes en définissant leurs échéances relatives en fonction de leurs contraintes de précédence [119, 120]. Si la tâche Tj précède la tâche Ti alors l’échéance de Tj est inférieure

à celle de la tâche T_i. Dans le second cas, des algorithmes supplémentaires doivent être utilisés pour interdire les accès simultanés aux ressources et pour éviter les interblocages (figure 2.7). Par exemple, lorsqu’une tâche plus prioritaire souhaite accéder à une ressource utilisée par une tâche moins prioritaire, le protocole de la priorité héritée (PIP : Priority Inversion Protocol) inverse les priorités [121]. La tâche utilisant alors la ressource devient plus prioritaire. Au contraire, le protocole de la priorité plafonnée (PCP : Priority Ceiling Protocol) autorise l’accès à une ressource partagée seulement si la priorité de la tâche est strictement supérieure aux priorités des tâches qui pourraient utiliser la ressource [121]. Enfin, le protocole de la priorité de pile (SRP : Stack Resource Policy) autorise une tâche à démarrer son exécution seulement si toutes les ressources nécessaires sont disponibles [122].

T1 T2 T3 0 10 20 A A A Échéance non respectée a) A T1 T2 T3 0 10 20 A A b) A

Fig. 2.7 –Ordonnancement EDF avec le protocole PIP (a) et avec les protocoles PCP ou SRP (b). La ressource partagée est notée A. L’arrivée d’une tâche est représentée par une flêche montante, son échéance par une flêche descendante.

En ce qui concerne l’ordonnancement en ligne multiprocesseur, les algorithmes d’ordonnan- cement vus précédemment s’appliquent en leur associant un algorithme d’allocation particu- lier. L’allocation choisit par exemple le meilleur processeur disponible pour exécuter la tâche et respecter ses contraintes. Si aucune ressource de calcul n’est disponible, la tâche est assignée à la ressource exécutant la tâche la moins prioritaire. En pratique, aucun de ces algorithmes n’a été mis en œuvre pour des raisons de complexité. En fait, seuls les ordonnancements effec- tués hors ligne permettent d’obtenir un ordonnancement optimal [123, 124, 120]. Un résultat fondamental, présenté par M. Sahni, affirme qu’il n’existe pas d’algorithme en ligne optimal pour un système comportant plus de deux processeurs [125]. Pire, comme nous le verrons dans le chapitre 4, des anomalies d’ordonnancement peuvent avoir lieu. Mais alors, quelles sont les solutions pour respecter des contraintes temps-réel ?