L’évaluation du système LIMOS

Pour répondre aux contraintes associées aux RCSF, un système d’exploitation doit posséder une faible empreinte mémoire adaptée aux fonctionnements des RCSF. Par conséquent, l’évaluation du système LIMOS va, dans un premier temps, consister à comparer sa taille mémoire avec celle des autres systèmes d’exploitation dédiés aux RCSF présentés dans ce chapitre.

Le système LIMOS a été conçu à partir des noyaux SDREAM et TinyOS. En comparant ces 3 systèmes, il est intéressant de voir où se situe le système LIMOS en terme de performance pure. Cette évaluation permettra de déterminer les autres apports de l’utilisation d’une architecture hybride au-delà d’une forte modularité du noyau.

2.7.5.1 L’empreinte mémoire

Dans cette section, l’empreinte mémoire du noyau LIMOS va être comparée à celle des différents systèmes d’exploitation dédiés aux RCSF présentés dans ce chapitre :

• Le système multitâche MANTIS ;

• Le système basé sur les événements TinyOS ;

• Le système centré sur les données AmbientRT ;

• Le système hybride Contiki.

CemOA : archive ouverte d'Irstea / Cemagref

Des informations plus ou moins détaillées selon les systèmes sont fournies sur la taille de leurs principaux composants et permettent d’introduire les configurations choisies lors de la comparaison (voir Table 2.3).

La partie gestion de processus du système MANTIS consomme 144 octets pour l’ordonnanceur, 120 octets pour une table de 12 processus à laquelle il faut ajouter 10 octets par entrée. Le système MANTIS offre la possibilité de configurer la taille de la pile associée à un processus avec une valeur minimale de 128 octets recommandée. Pour l’accès aux ressources partagées, chaque sémaphore utilise 5 octets.

La partie communication est un autre élément consommateur de mémoire. La taille des messages envoyés est variable et peut atteindre les 64 octets. Par conséquent, chaque buffer de communication doit avoir une taille supérieure à 64 octets qui est, en réalité, de 67 octets. Dans la configuration de base, 5 buffers sont réservés pour un total de 335 octets.

L’entité COMM comprenant les couches physiques, MAC et, les interfaces radio, liaison série et de bouclage (« loopback ») représente 64 octets. Enfin, un module pour l’utilisation de l’inondation simple (« flooding ») ou bornée (« Broadcast ») de 30 octets peut être ajouté [Abrach 2003]. La taille du système varie de 831 octets pour 1 processus à 2349 octets pour 12 processus.

A la base, le système TinyOS a une empreinte mémoire de 478 octets répartie entre 432 octets pour le code et 46 pour les données. Le module de communication implique un ajout d’un peu moins de 1,5Koctets. Une configuration complète représente environ 3Koctets pour le code et 230 octets pour les données [Hill 2000].

Le système AmbientRT utilise 3800 octets soit environ 3.7Koctets de mémoire Flash pour une configuration comprenant l’ordonnanceur, le gestionnaire de données, un module d’allocation dynamique de mémoire et une couche d’abstraction du matériel. En terme de mémoire RAM, le système nécessite un minimum de 58 octets dont 26 octets sont dédiés à l’utilisation de la pile. De plus, chaque tâche requiert un supplément de 10 octets [Dulman 2004].

Le système d’exploitation Contiki a été implémenté sur deux architectures : l’une à base d’un microcontrôleur MSP430 de la société Texas Instruments et l’autre s’appuyant sur microcontrôleur AVR de la société Atmel Corporation. Le noyau du système a une taille de 810 et 1044 octets respectivement pour le MSP430 [MSP 2008] et l’AVR [AVR 2008]. Un système complet incluant la bibliothèque de gestion des processus a une empreinte mémoire de 1562 octets pour le MSP430 et de 1940 octets pour l’AVR mais, dans ce cas, sans le chargeur de programme. Pour une configuration hébergeant une application simple, la taille du système Contiki avoisine les 3800 octets [Dunkels 2004].

Pour le système LIMOS, nous nous sommes arrêtés sur une configuration complète de 3 événements, 5 processus et 8 tuples. L’empreinte mémoire de l’ensemble du code est de 3752 octets et 2228 octets pour les données.

Alors que tous les systèmes ont des empreintes mémoires comparables autour des 3,5Ko, le noyau MANTIS en utilise, en théorie, un tiers de moins. Toutefois, pour certaines applications, le système MANTIS a semblé plus volumineux que TinyOS [Dunkels 2004]

[Wanner 2005] [Duffy 2006].

CemOA : archive ouverte d'Irstea / Cemagref

LIMOS MANTIS TinyOS AmbientRT Contiki

Empreinte mémoire du

code

3752 octets

2349 octets + 5 octets par

sémaphore

~3Ko

3800 octets + 10 octets par

processus

~3800 octets

Configuration

-5 événements -5 processus -8 tuples

-12 processus - - -Sans

application

Table 2.3 – Taille mémoire de différents systèmes dédiés aux réseaux de capteurs sans fil En conclusion, le fait que le noyau LIMOS dispose d’une organisation structurelle plus complexe de par son architecture hybride ne le pénalise pas au niveau de la mémoire consommée par rapport aux autres systèmes dédiés aux RCSF.

2.7.5.2 Les performances générales du système

Le système LIMOS a été implémenté sur un microcontrôleur Atmel ARM7TDMI AT91SAM7S256 [ARM7 2007] dont les principales caractéristiques sont (voir Figure 2.36) :

• 1 microprocesseur de type RISC 32 bits de fréquence maximale de 55 MHz pour 0,9MIPS/MHz ;

• 2 ports USART ;

• 1 port USB 2.0 ;

• 1 interface SPI ;

• 1 convertisseur analogique-digital comportant 8 canaux (« chanel »), chaque canal ayant une précision de 10 bits ;

• 64Ko de mémoire SRAM ;

• 256Ko de mémoire Flash répartie dans 1024 pages de 256 octets.

Figure 2.36 – Architecture du microcontrôleur AT91SAM7S256 d’Atmel Corporation

CemOA : archive ouverte d'Irstea / Cemagref

Au niveau de ses caractéristiques, ce microcontrôleur pourrait héberger un système d’exploitation embarqué temps réel classique mais l’utilisation qui en est faite est volontairement orientée vers les RCSF. Le choix s’est porté vers ce microcontrôleur de par les interfaces disponibles (USART, SPI, USB) et de par la possibilité de moduler la fréquence de fonctionnement du processeur de 5MHz à 55MHz. Cette dernière caractéristique permet d’adapter l’énergie consommée par le processeur en fonction de l’application

Le système LIMOS a été élaboré à partir des noyaux SDREAM et TinyOS. Comparer ces 3 systèmes permet de déterminer la place en termes de performance de l’utilisation d’une architecture hybride. Cette dernière autorise une plus grande flexibilité et adaptabilité aux applications au détriment de traitements plus complexes au niveau de l’ordonnancement.

Partant de ce constat, une comparaison par couple système/architecture de capteurs a été choisie plutôt que sur des systèmes seuls (voir Table 2.4).

LIMOS SDREAM TinyOS

ARM7TDMI MSP430F149 ATmega128

Ordonnancement

Temps (en µs) Temps (en µs) Temps (en µs)

Evénements Processus

13,86

15,72 14

11,5

Table 2.4 – Comparaison entre les systèmes LIMOS, SDREAM et TinyOS

Le noyau TinyOS a été installé dans des capteurs de type « Mica Motes » abritant un microcontrôleur ATmega128. Le noyau SDREAM a équipé des capteurs évolués dédiés à la télémédecine [Zhou 2004a] utilisant un microcontrôleur MSP430F149. Les capteurs sans fil

« LiveNodes » qui seront présentés plus en détails dans le chapitre 4 utilisent des microcontrôleurs AT91SAM7S256 de la société Atmel Corporation contrôlés par le système LIMOS.

Cette évaluation porte sur les temps moyen d’exécution au niveau de l’ordonnancement. Ainsi, le gestionnaire d’événements et l’ordonnanceur de processus du système d’exploitation LIMOS sont respectivement comparées avec ceux des noyaux TinyOS et SDREAM. Les performances affichées par le système LIMOS sont très proches de celles des deux autres systèmes.

CemOA : archive ouverte d'Irstea / Cemagref