Le système d’exploitation MANTIS

Le système d’exploitation MANTIS (MultimodAl system for NeTworks of In-situ wireless Sensors), conçu au sein de l’Université du Colorado à Boulder, est un exemple de système multitâche dédié aux RCSF [Abrach 2003] [Bhatti 2005]. En effet, sa configuration de base adaptée aux applications de réseaux de capteurs comprenant le noyau, l’ordonnanceur et la pile de protocole réseau a une empreinte mémoire inférieure à 1Ko.

Plus précisément, le système MANTIS est un système multitâche préemptif basé sur le partage de temps. Les ressources logicielles et matérielles du système sont ainsi affectées alternativement et pour un temps fixé entre les différents processus légers en cours

CemOA : archive ouverte d'Irstea / Cemagref

d’exécution. Ce fonctionnement fait en sorte qu’un programme ne puisse pas être mis en attente ou bloquer le système indéfiniment. Ainsi, les tâches de longue durée ne peuvent pas accaparer les ressources du système au-delà d’un certain temps au détriment d’une autre dont l’exécution est critique temporellement.

A une taille réduite, le système MANTIS dispose de fonctions absentes des systèmes d’exploitation mentionnés dans la Table 2.1. Par exemple, comparativement avec µCos dont l’empreinte mémoire est relativement faible, le système MANTIS utilise un ordonnanceur prenant en compte la consommation énergétique et comprend un mécanisme de programmation à distance des capteurs sans fil. Il a également la possibilité de passer en phase de veille quand aucun traitement n’est à réaliser.

L’architecture complète (voir Figure 2.7) du système d’exploitation MANTIS intègre différents éléments regroupés de la manière suivante :

• le noyau et l’ordonnanceur ;

• le module de communication (COMM) et la pile de protocole réseau ;

• le gestionnaire de périphériques (DEV) ;

• l’API (Application Programming Interface) du système ;

• l’interpréteur de commande (shell).

Figure 2.7 – Architecture du système d’exploitation MANTIS [Bhatti 2005]

Cette architecture illustre bien la conception en « couches transversales » avec une pile de protocole réseau située sur la même couche que les processus de niveau utilisateur.

Le rôle d’interpréteur de commande (shell) est de fournir un accès à distance à l’utilisateur. Ce dernier peut interagir avec le système par l’intermédiaire de fonctions prédéfinies. Les actions possibles se répartissent entre le changement de configuration, l’inspection et la modification de la mémoire et des opérations sur les processus (démarrage, suppression,…).

CemOA : archive ouverte d'Irstea / Cemagref

L’API du système permet simplement, à l’aide de la primitive thread_new(), de créer de nouveaux processus. La demande de création de ces processus est effectuée par une application donnée de niveau utilisateur ou par la pile de protocole réseau ou le serveur de commande. Les autres modules du système vont être présentés plus en détails dans ce qui suit.

2.3.2.1 Le noyau MANTIS

Le système MANTIS comprend les principales fonctionnalités des systèmes d’exploitation classiques présentées dans le paragraphe 2.1.2. Tout d’abord, tout en incorporant les contraintes de ressources limitées propres aux RCSF, le système MANTIS est basé sur des ordonnanceurs de type UNIX. La politique d’ordonnancement s’appuie sur la notion de priorité. Les processus de priorité la plus élevée s’exécutent avant ceux de plus faible priorité. Pour des processus de même priorité, le principe du tourniquet avec quantum de temps est utilisé. Dans celui-ci, les processus de même priorité s’exécutent alternativement durant un temps fixe et ceci jusqu’à leur terminaison. Pour la gestion des ressources qui pourraient être partagées, des mécanismes tels que les mutex ou les sémaphores peuvent être implémentés dans le système MANTIS.

Une attention toute particulière est portée sur la gestion de la mémoire. Dans MANTIS, la mémoire RAM disponible est répartie entre un espace alloué au moment de la compilation pour les variables locales et le tas réservé aux processus. Chaque processus réserve de la mémoire du tas pour leur pile qui est rendu à la fin de son exécution (voir Figure 2.8). A la base, il n’est pas possible d’augmenter dynamiquement la taille du tas sous MANTIS mais cela peut être ajouté en s’appuyant sur l’API. Toutefois, cette fonctionnalité est techniquement complexe à mettre en place et est plutôt déconseillée. Cette restriction est un choix qui se retrouve dans la plupart des systèmes d’exploitation développés pour les RCSF.

Figure 2.8 – Organisation de la mémoire dans le système MANTIS [Stojmenovic 2005]

CemOA : archive ouverte d'Irstea / Cemagref

Par défaut, la taille du tas spécifié permet un nombre maximum de douze processus.

Les processus sont représentés à l’aide d’une table dont chaque entrée a une taille de dix octets et contient les informations suivantes :

• la dimension de la pile avec sa taille et son pointeur de début ;

• le pointeur courant de pile ;

• le pointeur sur la fonction de démarrage du processus ;

• le niveau de priorité du processus ;

• le pointeur vers le processus suivant.

Ces éléments permettent, à partir de la pile d’un processus suspendu, de sauvegarder et de restaurer son contexte courant (contenus des registres du microprocesseur, etc.). A ce propos, l’ordonnancement du système MANTIS utilisant la politique du tourniquet avec quantum de temps, ce dernier est fixé, par défaut, à 10ms. Les processus de même priorité sont regroupés dans une même liste dont le noyau dispose des pointeurs de début et de fin et sur le processus courant.

Dans les premières versions du système MANTIS, seules les interruptions matérielles sont supportées. Elles sont toutes transmises aux pilotes du dispositif associé sauf celles de type « compteur de temps » (ou « timer ») qui sont gérées par le noyau lui-même. Plus précisément, suite à une interruption, un sémaphore est activé dans le but de réveiller un processus en attente. Sous MANTIS, les sémaphores avec compteur et d’exclusion mutuelle (ou mutex) sont utilisables.

Le dernier élément à considérer est l’existence d’un processus démon de priorité la plus basse. Il s’exécute quand tous les autres processus sont soit endormis ou non activés, soit suspendus en attente d’une ressource ou du déclenchement d’une interruption. Les actions visant à économiser l’énergie consommée peuvent être du ressort d’un tel processus.

2.3.2.2 La communication

Ce système est dédié aux RCSF et comprend des éléments pour la communication.

L’architecture du système MANTIS inclut une pile de protocole réseau qui suit, dans ce cas, un découpage en couches :

• la couche Application ;

• la couche Transport ;

• la couche Réseau ;

• la couche Communication.

Les trois premières couches reprennent, au niveau fonctionnalité, les recommandations fournies par le modèle OSI. La couche Communication est plus singulière car, contrairement aux autres couches, elle est située en dehors du niveau utilisateur et au même niveau logique que le noyau. L’un de ses rôles est le support de la sous-couche MAC associée au protocole de communication utilisé. De base, la sous-couche MAC permet une communication radio par modulation de fréquences sur 30 canaux. D’autres techniques d’accès au médium sans fil telles que le TDMA (Time Division Multiple Access) et CSMA (Carrier Sense Multiple Access) peuvent être utilisées. Une autre fonctionnalité visée est d’essayer d’offrir une interface standard aux pilotes des dispositifs de communication employés.

Cette pile de protocole, à la manière de celle d’autres systèmes, est développée de manière à minimiser le nombre de buffers, et par conséquent la mémoire utilisée, pour l’émission et la réception de messages [Zhou 2004b]. Pour ce faire, la partie « données » du paquet est stockée dans le même emplacement du début à la fin de son parcours dans la pile.

CemOA : archive ouverte d'Irstea / Cemagref

Quatre primitives sont utilisées en pratique pour la communication :

• la fonction com_send() : envoi de paquets ;

• la fonction com_recv() : réception de paquets ;

• la fonction com_mode() : activation ou désactivation du module de communication ;

• la fonction com_iotcl() : action spécifique à chaque module de communication.

La fonction com_send() crée un processus d’envoi niveau utilisateur qui à l’aide d’un pointeur va référencer un emplacement mémoire ou « buffer de communication ». L’entité COMM du système va ensuite prendre le relai de ce processus qui sera mis en attente, et transmettre le message au dispositif de communication. Après l’envoi physique du paquet, le déclenchement d’une interruption viendra débloquer le processus d’envoi précédemment suspendu.

La réception des messages est de l’autorité de l’entité COMM. Cette dernière possède un certain nombre de buffers de communication qu’elle met à disposition du module de communication. Lorsqu’un processus fait appel à la fonction com_recv(), il reste bloqué jusqu’à l’arrivée d’un paquet dans un buffer de communication annoncée par une interruption.

Une rotation est opérée entre les buffers de communication pour éviter la copie de données dans leur cheminement vers les couches hautes du système.

Par ce mode de fonctionnement, l’envoi de message est synchrone au niveau du système mais la réception peut être quasiment gérée en tâche de fond par l’entité COMM. En outre, cette entité est en charge de la gestion des communications asynchrones au niveau du système MANTIS.

2.3.2.3 Les autres périphériques

Les communications synchrones sont du ressort de l’entité DEV. Elle assure donc, en général, la communication avec les dispositifs de collecte de données et des périphériques tels que ceux de stockage externe avec, par exemple, les EEPROM (Electrically Erasable Programmable Read Only Memory) (voir Figure 2.9).

De la même manière que pour l’entité COMM, chaque type de dispositif a une interface associée dans l’entité DEV. Les primitives pour utiliser ces interfaces sont :

• la fonction dev_read() : lecture sur le périphérique ;

• la fonction dev_write() : écriture sur le périphérique ;

• la fonction dev_mode() : activation ou désactivation du périphérique ;

• la fonction dev_ioctl() : action spécifique à chaque périphérique (e.g. configuration).

Figure 2.9 – Support de la couche matérielle dans le système MANTIS

CemOA : archive ouverte d'Irstea / Cemagref

Comme le montrent les primitives utilisées, le mode de fonctionnement de cette entité est quasiment identique à celui de l’entité COMM. Quelques différences existent cependant : chaque élément géré étant répertorié dans une table de taille fixe qui comprend la localisation des fonctions associées à celui-ci et un sémaphore d’exclusion mutuelle.

2.3.2.4 Les avantages et inconvénients du système MANTIS

En se basant sur son architecture et l’organisation des différents composants logiciels qui le constituent, il est possible d’établir quelques uns des avantages et inconvénients propres au noyau MANTIS. Tout d’abord, nous sommes en présence d’un système d’exploitation embarqué multitâche adapté aux applications où plusieurs traitements, chacun associé à un ou plusieurs processus, sont en concurrence pour accéder aux ressources du capteur sans fil. Ce fonctionnement facilite également le portage de programmes provenant d’un système multitâche classique UNIX. Ce type d’opération doit toutefois être réalisé après une étude sur la possibilité, au regard des ressources disponibles, d’effectuer ou non ce portage.

Dans le cadre des RCSF, cette architecte comporte également certains inconvénients.

Dans les systèmes d’exploitation multitâches, en raison du passage d’un processus à un autre, des changements de contexte se produisent. Ceux-ci sont sources à la fois d’une certaine lenteur et d’une consommation de mémoire proportionnelle au nombre de processus, chacun d’entre eux nécessitant un espace de mémoire propre. Or, suivant l’application de RCSF considérée, ces deux critères d’évaluation sont déterminants dans le choix du système d’exploitation utilisé.

CemOA : archive ouverte d'Irstea / Cemagref