« Les OS temps réel vont profondément évoluer avant 2010 »

Avant de répondre à cette question, il n'est pas inutile de rappeler que deux générations d'OS temps réel sont apparues depuis l'émergence des systèmes d'exploitation enfouis commerciaux à la fin des années soixante–dix. L'utilisation des OS temps réel de première génération, catégorie dans laquelle on classe habituellement VxWorks, pSOS ou VRTX, s'est aujourd'hui banalisée. Mais ils souffrent de plusieurs limitations.

Tout d'abord, ils sont incapables de tirer profit de manière idéale des mécanismes de cloisonnement mémoire offerts par les microprocesseurs. Avec ce type de système d'exploitation, toutes les tâches se partagent en effet un unique espace d'adressage^[1]. Par ailleurs, ils ne sont pas adaptés aux besoins des systèmes temps réel multiprocesseurs distribués que l'on rencontre sur des marchés comme les télécommunications, l'avionique, le médical ou l'automobile. Enfin, ils ne peuvent répondre aux objectifs de haute disponibilité et/ou de sûreté de fonctionnement qu'exigent certaines applications.

Il y a une quinzaine d'années, l'arrivée sur le marché d'une deuxième génération d'OS temps réel commerciaux a permis de lever certaines de ces limitations. Des systèmes d'exploitation comme OSE, QNX ou LynxOS prennent ainsi en charge la gestion de la MMU [Memory Management Unit], propre aux principaux processeurs 32 bits. Ils peuvent alors gérer des applications qui réclament un certain niveau de tolérance aux fautes, puisque, avec la MMU, des tâches différentes peuvent fonctionner dans des espaces mémoire distincts et protégés les uns des autres.

Supportées en standard par OSE ou QNX, les techniques de passage direct de messages entre tâches, qui sont indépendantes de l'emplacement des processeurs et du type de réseau qui les relient, simplifient par ailleurs considérablement l'élaboration d'applications distribuées ou de logiciels à haute disponibilité. A l'avenir, il est clair qu'on fera de moins en moins appel aux mécanismes traditionnels de communication et de synchronisation entre tâches tels que files d'attente, boîtes aux lettres, sémaphores, mutex^[*], etc. Ces mécanismes ne sont guère adaptés aux systèmes distribués et/ou multicœurs dont la part va aller en augmentant dans l'embarqué au cours des prochaines années.

Au centre d'un exécutif temps réel, on trouve l'ordonnanceur. Ce service essentiel et fondamental du noyau doit garantir que les tâches à exécuter respectent les contraintes temporelles qui leur sont attachées. A l'heure actuelle, la quasi–totalité des OS temps réel commerciaux font appel à une politique d'ordonnancement préemptif fondée sur la notion de priorités.

Selon cette approche, la tâche de priorité la plus haute qui est prête à être exécutée est effectivement lancée. Ce principe, qui a fait ses preuves, pose néanmoins problème pour certains développeurs. Il se peut en effet que des tâches de faible priorité ne soient pas exécutées ou le soient dans des délais extrêmement longs.

Or, qui dit temps réel dit forcément échéances (ou deadlines) à respecter. Et force est de constater qu'il n'est pas possible, de façon simple, d'indiquer à un ordonnanceur préemptif fondé sur la notion de priorités statiques quelles sont les contraintes temporelles des différentes tâches d'une application. La grande évolution à attendre dans le domaine des OS temps réel commerciaux est donc le recours à des ordonnanceurs dits “ à échéance ”.

Les ordonnanceurs à échéance connaissent a priori les contraintes temporelles de chaque tâche. Ils peuvent alors optimiser l'utilisation du processeur en changeant temporairement les priorités en cours d'exécution pour que les différentes échéances soient respectées. Leur intérêt est évident pour les applications de traitement du signal numérique, et un système d'exploitation pour DSP comme OSEck fait déjà appel à un tel ordonnanceur.

Cela dit, il y a plusieurs types d'ordonnanceurs à échéance. Par exemple, l'ordonnanceur EDF (Earliest Deadline First) est apte à faire passer au niveau de priorité maximale la tâche dont la date d'échéance est la plus proche et qui s'avère prête à être exécutée^[2]. Plus complexe, l'ordonnanceur LL (Least Laxity) prend en compte à la fois la date d'échéance d'une tâche et la puissance de traitement qu'elle nécessite.

Dans cette situation, c'est en fait la tâche à la laxité la plus faible qui sera lancée en premier, la laxité étant, à un instant donné, la différence entre le laps de temps restant avant la date d'échéance de la tâche et la durée d'exécution effective de celle–ci. Pour ses décisions, l'ordonnanceur MUF (Maximum Urgency First), quant à lui, fait intervenir à la fois la priorité et la criticité d'une tâche.

Non, pas seulement. Car ce type d'ordonnancement, tout comme l'ordonnancement classique à base de priorités, ne résout pas le problème du manque de ressources qui peut éventuellement se poser lorsqu'une tâche ne peut être exécutée, faute de puissance CPU et/ou de mémoire disponible. Les ordonnanceurs par “ partition ” permettent de s'adapter à cette situation.

Avec cette technique, les tâches qui interagissent étroitement ­les tâches liées à l'acquisition de données ou au contrôle de mouvement par exemple­ sont rassemblées dans des “ blocs ”. Et chacun de ces blocs se voit réserver de manière exclusive la puissance CPU – ou une capacité mémoire – pendant une fenêtre temporelle donnée, et ce à intervalles réguliers. Pendant le laps de temps qui est assigné à un bloc, seules les tâches appartenant à ce bloc s'exécutent et profitent des ressources qui leur sont réservées.

Par contre, dans un même bloc, les tâches sont en général ordonnancées de manière traditionnelle. Je tiens d'ailleurs à signaler que l'ordonnancement par partition a déjà commencé à faire son apparition dans des OS temps réel du commerce à travers leurs déclinaisons compatibles avec la norme aéronautique Arinc–653.

L'ordonnanceur idéal, qui, à lui seul, pourrait satisfaire toutes les applications temps réel embarquées, n'existe probablement pas. Par contre, il y a de fortes chances qu'avant la fin de la décennie les systèmes d'exploitation temps réel commerciaux permettent aux développeurs de sélectionner parmi un répertoire d'ordonnanceurs différents celui qui convient le mieux à une application donnée.

Lors de la mise au point, ils pourront alors remplacer l'ordonnanceur de manière dynamique et modulaire, voire même en combiner plusieurs : un ordonnanceur par partition au niveau des blocs de tâches et un ordonnanceur par échéance au niveau des tâches dans un même bloc, par exemple.

Nous ne sommes pas dans le domaine du rêve. Avec le noyau temps réel Osek, dont l'usage se généralise dans l'automobile, le développeur a déjà le choix entre douze options différentes pour la politique d'ordonnancement de l'exécutif !