Le système d’exploitation AmbientRT

Le système d’exploitation AmbientRT est un autre exemple de système conçu spécifiquement pour les RCSF [Hofmeijer 2005]. Sa conception s’appuie sur deux grands principes :

• un ordonnancement basé sur la politique EDFI (Earliest Deadline First Inheritance)

• une architecture centrée sur les données (« data centric »).

2.5.1 L’ordonnancement dans le système AmbientRT

Le système AmbientRT utilise la politique d’ordonnancement EDFI [Jansen 2003]

élaborée à partir des algorithmes EDF (Earliest Deadline First ou « échéance la plus proche d’abord ») [Liu 1973] et DI (Deadline Inhéritance ou « héritage d’échéance ») [Sha 1990]. La priorité d’un processus ou d’une tâche sous le système AmbientRT est calculée ou recalculée à partir de sa date d’échéance. L’intérêt principal de ce fonctionnement est de pouvoir favoriser, à un instant donné, un processus de faible priorité pour qu’il puisse s’exécuter avant la date limite de son échéance.

L’utilisation de ces deux algorithmes d’ordonnancement s’explique par la nécessité d’avoir une politique d’ordonnancement dynamique sans les problématiques d’inversion de priorité (voir Figure 2.13). En effet, l’ordonnancement des processus est établi de manière à ce qu’il n’y ait pas, à un instant donné, de concurrence entre les ressources partagées.

L’exclusion mutuelle de ces ressources est effectuée en amont par rapport à d’autres systèmes d’exploitation. Au moment de l’exécution, les risques d’inter-blocages (« dead lock ») sont donc écartés à la source.

Figure 2.13 – Ordonnancement des processus dans le système AmbientRT [Jansen 2003]

CemOA : archive ouverte d'Irstea / Cemagref

Dans l’algorithme EDFI, l’ordonnancement des tâches s’organise autour de trois structures :

• la file des processus prêts ;

• la pile d’exécution ;

• la file des processus exécutés.

Dans la file des processus prêts, les processus sont triés par date d’échéance, le processus à l’échéance la plus proche étant en tête de file. La date d’échéance de ce processus est comparée avec celle du processus en cours d’exécution. Si le résultat est en faveur (c’est-à-dire date d’échéance plus proche) du processus de la file d’attente, celui-ci devient le processus en cours d’exécution et déplace l’autre processus dans la pile d’exécution en tant que processus préempté. Tous ces traitements sont effectués de manière périodique.

Les contextes des processus de la pile d’exécution sont eux-mêmes stockés sous forme de pile. Quand un processus finit son exécution, le processus suivant se trouve soit dans la file des processus prêts, soit dans la pile d’exécution. Par conséquent, pour passer au processus suivant, on dépile le contexte du processus venant de se terminer et, soit on empile le nouveau contexte, soit on descend d’un niveau dans la pile de stockage des contextes. Le passage au processus suivant en est ainsi simplifié.

A la fin de son exécution, un processus est reversé dans la file d’attente des processus exécutés et attend l’arrivée d’un stimulus ou événement pour devenir un processus prêt. Le diagramme d’états et de transitions des processus du système AmbientRT est donné dans la Figure 2.14.

Figure 2.14 – Diagramme d’états et de transitions des processus du système AmbientRT [Hofmeijer 2005]

La description précédente présente la partie relative à l’emploi de l’algorithme EDF.

L’algorithme DI intervient, quant à lui, au moment de la comparaison entre le processus prêt à être exécuté et celui en cours d’exécution. Les ressources nécessaires au processus proche de

CemOA : archive ouverte d'Irstea / Cemagref

l’exécution sont analysées et comparées avec l’ensemble des ressources utilisées par les processus présents dans la pile d’exécution. Si une ressource en commun existe, le processus ne passe pas dans la pile d’exécution et ceci même si sa date d’échéance est plus proche.

En termes de structure, les processus du système AmbientRT possèdent un ensemble d’attributs :

• la date d’échéance ;

• la période ;

• le coût processeur ou CPU ;

• la liste des ressources nécessaires à l’exécution.

Si la période est inconnue comme c’est le cas pour les processus apériodiques, le temps minimal possible entre deux exécutions consécutives est choisi. Comme nous venons de le voir, la liste des ressources revendiquées est importante pour établir l’ordonnancement avec exclusion mutuelle.

On peut rajouter à ceux-ci, deux attributs utilisés pour contenir les informations durant l’exécution du processus :

• la date de sélection pour l’ordonnanceur ;

• la date d’échéance effective.

2.5.2 La gestion des composants dans le système AmbientRT

Dans les RCSF, l’organisation en couches croisées des éléments logiciels est généralement favorisée par rapport à celle en couches superposées classiques. Ainsi, des fonctionnalités portant sur l’ensemble du système comme la gestion de l’énergie peuvent être remplies au sein d’un même et unique composant. Une autre illustration de ce point est l’élaboration d’un module de contrôle d’erreurs commun à l’ensemble des couches de la pile de protocole de communication plutôt qu’à une seule.

Cette approche se retrouve dans le système AmbientRT par l’utilisation de composants ou DCE (Data Centric Entities) pour la construction des applications supportées [Dulman 2004]. La notion de « centré sur les données » (ou « data centric ») qui caractérise le système AmbientRT est présente dans la méthode d’assemblage des composants. Un composant peut être représenté par une boîte noire dont les traitements effectués sont déclenchés par l’arrivée de données. Ces traitements vont eux-mêmes produire des données et demander l’accès à d’autres données globales du système. Le processus de production de données est la fonctionnalité du composant. Plusieurs composants peuvent avoir la même fonctionnalité et pour pouvoir les différencier, la notion de capacité est introduite. Elle correspond au coût associé au composant pour réaliser sa fonctionnalité et intègre le niveau de performance et de qualité observée (voir Figure 2.15).

L'accès aux données est obtenu à l'aide d'un mécanisme de type publication/souscription. On distingue les tâches d'un composant qui vont modifier la donnée et la publier, et celles qui répondent ou souscrivent à ces modifications. Puisque les composants ne vivent qu'à travers les données manipulées, leur politique d'assemblage est, par extension, de type publication/souscription.

Dans ce qui vient d’être mentionné, le terme « donnée » ne se résume pas aux objets en mémoire manipulés par le système. Il inclut également les événements et une « notice » pour permettre leur utilisation par les composants. Les événements considérés sont issus soit de l’environnement observé soit de commandes exécutées par les utilisateurs. Plus généralement, une donnée est composée d’un ensemble d’objets distincts appelé DT (Data

CemOA : archive ouverte d'Irstea / Cemagref

Type). Ces derniers sont de nature variée allant des éléments en mémoire aux interruptions matérielles. Chaque donnée est caractérisée par son nom et son contenu. Des informations comme sa durée de validité peuvent lui être associées. Lors du déclenchement d'une interruption, une donnée DT spécifique est publiée pour être ensuite prise en compte par le composant souscripteur qui en a la charge.

Figure 2.15 – Composant DCE du système AmbientRT [Dulman 2004]

Sous le système AmbientRT, le DCS (Data Centric Scheduler) gère les tâches ou processus qui s'exécutent et les composants (voir Figure 2.16). Il joue donc à la fois le rôle d'un ordonnanceur de tâches et celui d'un gestionnaire des données. Au niveau des composants, il permet d'activer ou de désactiver en direct un composant [Dulman 2004]. Des modules dits DLM (Dynamic Loadable Module) peuvent également être ajoutés dynamiquement après un téléchargement transitant par les liaisons radio ou série.

Figure 2.16 – L’architecture à base de composants du système AmbientRT

CemOA : archive ouverte d'Irstea / Cemagref

Au regard de la Figure 2.16, l’organisation du système AmbientRT s’articule autour de la politique d’ordonnancement, présentée dans la section 2.5.1, appliquée aux tâches issues de différents composants qui sont liés entre eux par l’intermédiaire de données de différentes natures (objets en mémoire, événements, interruptions, etc.).

2.5.3 Les avantages et inconvénients du système AmbientRT

Le noyau AmbientRT se situe à l’intersection des systèmes TinyOS et MANTIS.

Comme ce dernier, il s’agit d’un système multitâche dont la politique d’ordonnancement est basée sur la date d’échéance des processus. Il possède donc les inconvénients relatifs à ce type de système d’exploitation c’est-à-dire le temps et la mémoire consommés par les changements de contexte.

Comme le système TinyOS, le noyau AmbientRT dispose d’une architecture à base de composants. Mais si les composants du système TinyOS regroupés par catégorie sont pratiquement organisés en couches, ce n’est pas le cas pour le noyau AmbientRT. Celui-ci propose une approche différente centrée sur les données plutôt que les traitements. Les composants sont ainsi reliés entre eux plus par les données qu’ils manipulent que par leurs rôles ou fonctions. Les données produites par un composant seront utilisées en entrée par un autre. Cette architecture est bien adaptée à la mise-à-jour, l’ajout ou la suppression, de manière dynamique, de composants du système. En revanche, cette architecture complexifie le portage de programmes, quel que soit le sens, à partir ou vers d’autres systèmes d’exploitation.

CemOA : archive ouverte d'Irstea / Cemagref