Présentation du système de fichiers LiveFile

Dans le document en fr (Page 104-109)

capteurs sans fil

3.1 Présentation du système de fichiers LiveFile

Au départ, le rôle du système LiveFile était d’offrir un gestionnaire de mémoire évolué pour le système d’exploitation LIMOS. Dans un RCSF, le stockage des données n’est qu’une première étape avant la transmission de celles-ci vers un poste distant, la station centrale de collecte (« sink node »). Les besoins observés dans différentes applications ont permis d’établir les principales fonctionnalités dont devait disposer un système de fichiers dédié aux RCSF comme LiveFile.

3.1.1 Les fonctionnalités du système de fichiers LiveFile

La mémoire est une ressource critique des capteurs sans fil au même titre que l’énergie et la puissance de calcul. La première utilisation de la mémoire est plutôt classique et se résume au stockage des variables générées et brassées au sein du système d’exploitation.

Comme mentionné dans le chapitre précédent, la gestion de la mémoire peut impliquer des opérations complexes comme, par exemple, l’allocation dynamique.

La seconde est relative à la communication et à la nécessité de mettre à disposition des modules associés des buffers pour stocker les données reçues ou à transmettre. En outre, la communication est l’une des fonctionnalités illustrant le lien qui existe entre les différentes ressources des capteurs sans fil et de l’équilibre qu’il est indispensable de trouver dans leur gestion et dans leur consommation. En effet, l’énergie consommée est proportionnelle au

CemOA : archive ouverte d'Irstea / Cemagref

nombre de bits transmis. Par conséquent, de manière optimale, seules les données intéressantes doivent être transmises. Or, les autres données auront peut-être un intérêt plus tard soit pour les informations qu’elles contiennent, soit pour contrôler le fonctionnement du capteur sans fil. De plus, l’importance des données n’est pas connue à l’avance et il est parfois difficile de la déterminer avant le déploiement in-situ. Dans tous les cas, cela oblige à stocker une certaine quantité de données temporairement ou de manière prolongée.

La relation entre gestion de la mémoire et de la communication apparaît également lorsque la communication est indisponible ou perturbée. Ainsi, les données qui auraient dû être envoyées doivent être stockées en attendant le rétablissement de la communication. La durée d’indisponibilité étant en général inconnue, il est indispensable de répertorier correctement les données pour qu’elles puissent être récupérées par la suite.

La plupart des capteurs sans fil dispose de microcontrôleurs équipés de mémoires de types SRAM et Flash. Ces dernières autorisent un stockage non volatile des données c’est-à-dire que, même après une coupure d’alimentation, le contenu de la mémoire reste intact. Les mêmes questions que précédemment se posent à savoir quelles données stocker et comment.

De plus, l’écriture ou la programmation de la mémoire Flash implique certaines précautions qui seront présentées plus en détails dans la partie 3.2.

Les applications d’acquisition de données sont les premières ciblées par le développement d’un système de fichiers comme LiveFile. Même dans une application où les données collectées sont directement transmises, suivant la fréquence d’échantillonnage requise, un système tel que LiveFile peut avoir son utilité. Si la fréquence d’acquisition est extrêmement rapide, la disponibilité et les caractéristiques du module de communication peuvent requérir le stockage des données avant envoi. Inversement avec une fréquence d’acquisition lente, le module de communication peut être mis en mode veille pour économiser de l’énergie et être réveillé après la réception d’une certaine quantité de données à envoyer, d’où la nécessité de les stocker entre-temps.

Les applications de substitution de l’infrastructure fixe peuvent également requérir un système comme LiveFile. Si, un fichier volumineux est transféré à travers le réseau, celui-ci peut être découpé et envoyé par morceaux. L’objectif visé est la préservation du fonctionnement du réseau en s’adaptant à sa capacité pour éviter les phénomènes de congestion voire d’écroulement.

Dans une application de RCSF, les trois principales étapes sont :

• l’acquisition des données ;

• le stockage des données ;

• la transmission des données.

Une quatrième étape « l’agrégation des données » peut s’insérer entre les deux premières ou dernières. En effet, l’agrégation peut avoir lieu avant le stockage pour économiser de la mémoire ou juste avant la phase de transmission pour pouvoir envoyer une plus grande quantité d’information à la fois (voir Figure 3.1).

Si le dimensionnement du capteur le permet, l’ensemble des données acquises peuvent être stockées avant leur transmission. Les données intéressantes sont donc choisies au sein de la station centrale de collecte. Cependant, cette situation ne représente pas un cas général, bien au contraire. Une gestion des ressources disponibles est primordiale, voire obligatoire, et passe par la manipulation d’un nombre restreint de données. Ainsi, la mémoire et l’énergie sont préservées par moins de stockage et de transmission. De plus, la puissance de calcul

CemOA : archive ouverte d'Irstea / Cemagref

utilisée pour les opérations d’agrégation et de cryptage de données dépend de la quantité de données traitées.

Figure 3.1 – Principaux traitements effectués au sein d’un capteur sans fil

Par conséquent, une sélection des données doit avoir lieu à chaque étape. A l’acquisition, les données n’ayant pas les critères souhaités ne sont pas retenues. Les principales données sont stockées en mémoire non volatile. Les autres sont disponibles durant une période de temps établie selon l’application ou les ressources en mémoire vive disponible.

Les données anciennes sont remplacées par d’autres plus récentes. Pour réduire la quantité de données transmises à travers le réseau, une sélection doit être faite par l’intermédiaire d’interrogations provenant de la station centrale de collecte. De cette manière, seules les informations requises et donc les plus importantes sont diffusées au sein du réseau. Au regard des ressources disponibles, un capteur sans fil est peu propice à héberger un système de gestion de base de données. Les interrogations ou requêtes effectuées sur les données des capteurs doivent être ciblées et organisées pour être performantes tant au niveau de la précision et de la qualité du résultat qu’au niveau énergétique.

Les deux grandes fonctionnalités du système LiveFile sont :

• la gestion de la mémoire des capteurs sans fil ;

• l’interrogation des données collectées.

3.1.2 L’intégration dans le système d’exploitation LIMOS

Dans le chapitre précédent, le système LIMOS a été présenté en détails. Ces caractéristiques les plus importantes ont été mises en évidence. L’une de ses principales particularités est son architecture hybride basée sur les événements et les processus. L’autre est l’utilisation des concepts dérivés du système LINDA qui apporte un niveau d’abstraction pour la gestion des périphériques et la communication entre les processus et les événements.

Ces différentes gestions s’appuient sur la notion de tuple qui représente un espace mémoire associé à un objet système (événement ou processus) manipulé par le système d’exploitation.

L’accès à un tuple s’effectue à l’aide des primitives In() et Out() pour la lecture et l’écriture.

Tous ces principes offrent un cadre pour la gestion de la mémoire. En dérivant le fonctionnement de la primitive Out(), l’écriture dans la mémoire RAM ou Flash est possible.

De la même manière, l’appel à la fonction In() autorise la lecture d’un emplacement mémoire.

CemOA : archive ouverte d'Irstea / Cemagref

Ces modifications permettent l’intégration du système LiveFile dans le noyau LIMOS. Elles ont l’avantage d’offrir une interface simple et répandue dans les systèmes utilisant le concept LINDA comme, par exemple, les noyaux DREAM et SDREAM.

Le fonctionnement de la primitive Out() ne se résume pas à placer une donnée à une adresse mémoire. Il prend en compte la particularité de la mémoire Flash et la nécessité d’une écriture page par page et de préserver celles qui ont été les plus utilisées. La primitive In() est appelée pour la recherche des données requises suite à une interrogation ou requête. Si le système l’autorise, l’allocation dynamique de mémoire vive est assurée par la fonction In() (voir Figure 3.2).

Figure 3.2 – Extension des fonctionnalités des primitives In() et Out()

L’unification des différents modules de gestion du noyau LIMOS au sein du concept LINDA étendu, constitue un point de départ dans la construction d’un intergiciel ou logiciel médiateur (« middleware ») dédié aux RCSF (voir Figure 3.3). Les intergiciels ont pour fonction principale l’interfaçage entre les dispositifs matériels et les applications d’un capteur sans fil. Plus précisément, leur rôle est d’offrir des services standardisés pour une manipulation efficace et adaptée des ressources matérielles disponibles. Ils viennent en réponse aux nombreux challenges issus des RCSF dont quelques uns ont été énoncés dans le chapitre 1 et où l’on trouve entre autres [Hadim 2006] :

• la gestion des ressources disponibles ;

• la gestion des données ;

• l’hétérogénéité des capteurs ;

• l’administration des capteurs à distance ;

• la reconfiguration des capteurs ;

• la sécurité.

CemOA : archive ouverte d'Irstea / Cemagref

La reconfiguration des capteurs est soit issue d’une demande à distance soit requise par un changement de topologie du réseau, la plupart du temps, subi.

Figure 3.3 – La notion d’intergiciel

L’intérêt d’un intergiciel est de réunir tous les éléments d’un capteur et de concentrer leurs efforts dans un objectif commun qui est d’offrir le support nécessaire à l’application embarquée. Les principaux intergiciels sont TinyDB avec le système d’exploitation TinyOS [Madden 2005] et Cougar [Bonnet 2001]. Ils seront présentés dans la section 3.4.1 de ce chapitre.

CemOA : archive ouverte d'Irstea / Cemagref

Dans le document en fr (Page 104-109)